Меню

Vmware site recovery manager настройка



Для системного администратора

VMware Site Recovery Manager

VMware Site Recovery Manager – продукт автоматизирующий процессы аварийного восстановления, создания и тестирования планов восстановления после катастроф. Site Recovery Manager разработан компанией VMware как логическое продолжение развития виртуальной ИТ-инфраструктуры на базе платформы VMware Virtual Infrastructure 3.

Site Recovery Manager помогает организациям решить проблемы традиционного аварийного восстановления в соответствии с задачами времени восстановления (RTO), допустимого уровня потери данных (RPO) и иными нормами. Использование Site Recovery Manager обеспечивает управление аварийным переключением производственных ЦОД на удаленные резервные центры данных. Это решение также позволяет управлять аварийным переключением между двумя загруженными центрами, выполняющими функцию резервных площадок друг для друга. Site Recovery Manager можно также использовать при запланированном аварийном переключении ЦОД (например, при миграции ЦОД), автоматизируя и упрощая процесс перехода на новый центр данных.

Структурная схема системы аварийного восстановления на базе VMware Site Recovery Manager

Катастрофоустойчивая система состоит из основного и резервного сайтов (ЦОДов). Оба cайта имеют типовую виртуальную ИТ-инфраструктуру VMware: виртуальные машины запущены на серверах ESX централизованно управляемых сервером VirtualCenter. Администрирование производится с АРМ’а администратора с установленным VI Client.

В каждый сайт добавляется сервер Site Recovery Manager, управляющий процессами аварийного восстановления и реализующий функционал создания, тестирования и выполнения планов восстановления. Кроме того, сервер SRM интегрируется с серверами VirtualCenter основного и резервного сайта, что обеспечивает централизованное управление процессами аварийного восстановления, мониторинг их состояния, а также оповещение операторов в случае возникновения аварийных ситуаций.
Работа SRM основывается на репликации блоков данных уровня дисковых массивов. Репликация обеспечивается средствами ПО производителей систем хранения. Для интеграции с дисковыми массивами SRM использует программные адаптеры репликации (SRA, Storage Replication Adapter), которые поставляются производителями дисковых массивов. Используя адаптер репликации, SRM проверяет наличие репликации LUN, на которых хранятся файлы защищаемых виртуальных машин, а также инициирует выполнение различных команд дисковыми массивами, таких как создание снапшотов, переключение режимов работы и т.п.
Site Recovery Manager может быть запущен как на одном сервере с VirtualCenter так и на разных, но в любом случае он использует отдельную базу данных.
Пользовательский интерфейс для работы с функционалом SRM реализуется с помощью плагина к VI Client.

Настройка инфраструктуры восстановления

Site Recovery Manager обеспечивает простой процесс подключения основного сайта к резервному и к используемому ПО репликации хранилища, а также конфигурации основного сайта. Предварительная настройка в общем случае включает в себя следующие шаги:

  • Настройка репликации LUN средствами ПО репликации системы хранения.
  • Установка сетевого соединения между серверами VirtualCenter и серверами SRM основного и резервного сайтов.
  • Установка соединения SRM с адаптерами SRA на основном и резервном сайтах. Проверка репликации LUN между сайтами.
  • Сопоставление порт-групп виртуальных машин, ресурсных пулов, серверов ESX и датацентров основного и резервного сайтов.
  • Создание защищаемых групп (Protection Group) на основном сайте. Protection Group – основной объект, используемый при создании планов восстановления. По сути это группа виртуальных машин, файлы которых хранятся в одной группе хранилищ (Datastore Group). Datastore Groups – объекты автоматически генерируемые на основании взаимосвязей реплицируемых LUNов, VMFS-томов и виртуальных машин по определенным правилам. Для простоты можно считать что, если LUN содержит один VMFS-том и все виртуальные машины имеющие файлы на этом VMFS-томе не имеют файлов хранящихся на других томах, то все это является одной группой хранилищ и соответствует одной защищаемой группе.
  • Для Protection Group необходимо определить Datastore for Placeholder VMs – VMFS-том на резервном сайте, в котором будут храниться метаданные для виртуальных машин (.vmsd, .vmx и .vmxf – файлы). Эти файлы сразу же копируются на резервный сайт и позволяют зарегистрировать защищаемые виртуальные машины в местном VirtualCenter.
  • Для каждой виртуальной машины в созданных защищаемых группах можно задать особые параметры восстановления на резервном сайте, такие как:
    • Датацентр;
    • Ресурсный пул;
    • Сетевая порт-группа;
    • Хранилище метаданных;
    • Customization Specification – предопределенная конфигурация виртуальной машины, включающая IP-адрес, пароль администратора и т.п.
    • Приоритет восстановления виртуальных машин;
    • Сообщения для администратора выполняющего резервное восстановление, которые будут выведены до и после включения виртуальной машины;
    • Скрипты, которые будут выполнены до и после включения виртуальной машины.

Для работы с SRM необходимо иметь соответствующие права доступа, которые задаются довольно гибко для всего функционала.

Создание планов восстановления

Site Recovery Manager позволяет создавать планы восстановления для разных сценариев аварийного переключения и различных частей инфраструктуры. План восстановления создается на резервном сайте из последовательно выполняемых типовых шагов:

  • Остановка виртуальных машин на основном сайте в порядке соответствующем их приоритетам.
  • Остановка виртуальных машин на резервном сайте при необходимости освобождения дополнительных ресурсов для восстанавливаемых ВМ.
  • Последовательное восстановление групп виртуальных машин, ранжированных по приоритетам восстановления.
  • Выполнение заранее определяемых сценариев восстановления виртуальных машин: выполнение команд и скриптов до и после восстановления.


Для каждой восстанавливаемой виртуальной машины можно задать приоритет на использование процессора и памяти с помощью механизмов ресурсных пулов и параметров приоритета ресурсов самих виртуальных машин.
При создании плана восстановления используются определенные на основном сайте защищаемые группы (Protection Group).
Информация о созданных планах может быть экспортирована в XML, .doc, XLW, HTML и CSV форматы.

Аварийное восстановление

В нормальном режиме функционирования основного и резервного сайтов серверы SRM с обеих сторон реализуют мониторинг состояния резервируемого сайта и обеспечивают с помощью специальных программных адаптеров репликацию файлов защищаемых виртуальных машин. Список защищаемых виртуальных машин и детальные планы их аварийного восстановления определяются заранее с помощью специального функционала SRM.

На рисунке выше представлена схема функционирования основного и резервного сайтов, работающих в системе аварийного восстановления под управлением SRM. Часть виртуальных машин основного сайта включены в защищаемые группы и для них разработан план аварийного восстановления. SRM со стороны основного сайта посредством адаптера SRA определяет, какие LUN реплицируются, и позволяет создавать защищаемые группы (Protection Group) только для тех виртуальных машин, которые хранятся на реплицируемых LUN. При этом реплицируемый LUN основного сайта находится в режиме «чтение-запись», а соответствующий LUN резервного сайта в режиме «только чтение». Оператор резервного сайта следит за состоянием основного сайта в реальном времени помощью подсистемы мониторинга SRM, которая позволяет задавать различные тревоги и оповещения.
В случае возникновения экстренной ситуации на основном сайте, требующей немедленного аварийного восстановления защищаемых виртуальных машин, оператор инициирует исполнение плана восстановления нажатием одной кнопки.

SRM прерывает репликацию, переводит резервный LUN в режим «чтение-запись» и выполняет все предопределенные шаги восстановления. Администратор контролирует выполнение шагов плана восстановления через VirtualCenter и может в любой момент приостановить этот процесс. В результате все защищаемые виртуальные машины восстанавливаются даже при полном уничтожении основного сайта.
SRM позволяет защищать виртуальные машины каждого сайта, в котором он работает. Каждый сайт может являться и резервным и резервируемым одновременно.

Читайте также:  Настройки эквалайзера для винамп

Тестирование аварийного восстановления

Для тестирования созданных планов восстановления SRM создает изолированное тестовое окружение на резервном сайте, не затрагивая при этом работу производственных систем. На системе хранения создается инкрементальный снапшот реплицируемого LUN (если система хранения умеет делать инкрементальные снапшоты), который используется для тестового запуска защищаемых виртуальных машин. Для избежания конфликтов с основными системами используется специальная изолированная сеть VLAN.

После успешного прохождения теста SRM удаляет все временные объекты и приводит резервный сайт в исходное состояние. Результаты тестирования сохраняются для дальнейшего просмотра и экспортирования.

Постовой

Компания Евровидео специализируется на услугах по оцифровке и видеомонтажу видеокассет, тиражированию DVD, CD дисков в Москве и области.

Этот пост September 29, 2008 at 9:57 pm опубликовал molse в категории Виртуализация. Желающие могут оформить RSS подписку на комменты. Both comments and trackbacks are currently closed.

Источник

Как организовать катастрофоустойчивую инфраструктура на базе VMware SRM-1 часть

Как организовать катастрофоустойчивую инфраструктура на базе VMware SRM-1 часть

Сегодня я планирую начать серию статей, посвященных продукту VMware vCenter Site Recovery Manager (SRM). VMware SRM является основой для организации катастрофоустойчивых решений и предоставляет возможность автоматизации процедуры восстановления виртуальной инфраструктуры при авариях, повлекших за собой недоступность серверов, систем хранения данных (СХД) или целого сайта, а также позволяет проводить плановую миграцию инфраструктуры на резервный сайт и тестировать корректность работы резервной инфраструктуры.

В этих статьях я хотел бы рассказать об актуальной 5-й версии продукта, а также описать процедуру его установки и настройки и работу в связке с СХД NetApp.

Но если вы думаете, что я начну первую статью с хвалебных од в честь SRM или с примера конфигурирования СХД, то спешу Вас разочаровать. В первой части я хотел бы рассказать о некоторых базовых вещах, без которых будет сложно описать все преимущества, недостатки и особенности работы SRM.

Вступление
Сразу же хочется ответить на главный вопрос — зачем защищаться от катастроф? Почему не использовать обычный порошок средства обеспечения отказоустойчивости?

При работе любой системы всегда существует риск, что-то пойдет не так, и система перестанет выполнять возложенные на нее функции, т.е. произойдет сбой. В некоторых случаях сбой может быть настолько разрушителен по своему воздействию, что даже отказоустойчивая система выйдет из строя. Вот это и будет катастрофой. И чтобы ей противостоять нам, как ни странно, следует спроектировать и развернуть катастрофоустойчивое решение.

Конечно, можно положиться на русский авось. А можно оценить риски, величину потерь в случае возникновения того или иного сбоя и сравнить со стоимостью внедрения катастрофоустойчивого решения, написать технико-экономическое обоснование, подсчитать ROI, TCO. и решиться на внедрение SRM.

Проницательный читатель, немного знакомый с SRM, возможно скажет: “ — Зачем мне покупать отдельный продукт, который, по существу, не обеспечивает никакого дополнительного функционала, если я могу практически все то же самое сделать вручную или с помощью скриптов?” — и будет по-своему прав. Однако в критической ситуации, коей, безусловно, является падение виртуальной инфраструктуры и всех сервисов, запущенных в ней, человек имеет свойство паниковать и совершать ошибки. В некоторых случаях цена такой ошибки может многократно превысить стоимость и SRM, резервного ЦОДа и всей виртуальной инфраструктуры.

С другой стороны следует понимать, что SRM не является волшебной палочкой, его покупка совершенно не означает, что Ваша инфраструктура автоматически станет защищенной от всевозможных катастроф. Установка, настройка и тестирование SRM составляет лишь малую часть работ в общем проекте по созданию надежной катастрофоустойчивой инфраструктуры, потому что еще требуется провести аудит существующей инфраструктуры, оценить возможные риски, спланировать архитектуру будущего решения, написать пару десятков различных документов (планов, регламентов, инструкций и пр.), наконец, построить резервный ЦОД (если его нет).

Но перед тем, как начать говорить о самом SRM, я хотел бы сказать несколько слов о том, как можно противодействовать сбоям в работе виртуальной инфраструктуры, чтобы понимать от чего использование SRM поможет защититься, а от чего — нет, и как обеспечить защиту данных.

Сбои можно классифицировать в зависимости от причины возникновения:

  • Аппаратные сбои. К ним можно отнести, например, выход из строя каких-либо отдельных компонентов серверов или СХД (дисков, вентиляторов, блоков питания, плат расширения, портов). От таких сбоев защититься можно, устранив единую точку отказа (дублирование по схеме N+N или N+1). Однако следует помнить, что следует дублировать не только внутренние компоненты, про отдельные узлы системы, например, Ethernet и Fibre Channel коммутаторы, серверы или контроллеры СХД также не следует забывать.
  • Программные сбои, которые могут возникать из-за ошибок в коде или программной несовместимости компонентов. Обычно такие сбои не приводят к прекращению работы всей инфраструктуры, если не брать в расчет масштабных вирусных эпидемий или массовую установку проблемного драйвера или обновления. Защититься от программных сбоев можно, разворачивая поддерживаемые и рекомендованные производителями конфигурации, ставя только проверенное ПО, и тестируя обновления перед их установкой в производственную среду.
  • Человеческий фактор не ограничивается только злобной уборщицей, попавшей по недосмотру в серверную, или проделками пьяных администраторов. Зачастую обычная невнимательность или банальная некомпетентность сотрудников могут привести к печальным последствиям. Гораздо хуже, если сбой вызван из-за предумышленных действий (саботажа) компетентного сотрудника, имеющего доступ к системе.
  • Форс-мажоры. Практически непредсказуемы по причине возникновения и степени воздействия. Обычно затрагивают все компоненты инфраструктуры сразу, Среди примеров: пожары, наводнения, ураганы, либо более частые — такие как отключение электроэнергии, поломка системы кондиционирования, люди в черных масках с автоматами.
Читайте также:  Где можно найти настройки принтера

Приведенный перечень является далеко неполным, но позволит администратору определиться с наиболее вероятными причинами сбоев и подготовить таблицу возможных рисков и потерь, к которым они могут привести, а также методами противодействия.

Помимо причины возникновения, сбои можно классифицировать по тому, приводят ли они к потере данных или нет.

Понятно, что наиболее болезненными для организации являются сбои, приводящие к потере данных, так как зачастую эти данные могут стоить гораздо дороже, чем оборудование, используемое для их хранения и обработки. Каким образом от этого можно защититься?

Во-первых, многие приложения и службы имеют встроенные механизмы защиты данных. Так, например, файловые серверы на базе Windows могут реплицировать файлы и папки, используя протокол DFS, контроллеры домена реплицуруют объекты службы каталога, для баз данных Exchange или SQL можно настроить зеркалирование.

Во-вторых можно использовать универсальные методы защиты данных, такие как:

  • Резервное копирование.
  • Кластеризация СХД.
  • Репликация данных.

Рассмотрим каждый из них подробнее.

Резервное копирование
Как известно администраторы делятся на тех, кто еще не делает резервные копии, и на тех, кто уже делает.

К плюсам резервного копирования относятся:

  • Распространённость решений.
  • Создание копий данных, актуальных на определенный момент времени.
  • Возможность длительного хранения копий данных (архивирование).
  • Поддержка различных носителей для хранения копий: магнитные, ленточные, оптические накопители.
  • Возможность резервировать и восстанавливать только те данные, которые требуются (выборочное резервное копирование/восстановление).
  • Применение разных политик по частоте резервного копирования и длительности хранения для разного типа данных.

Недостатки большинства систем резервного копирования в полной мере характеризуются двумя терминами: RTO и RPO.

(RTO — Recovery Time Objective — это время на восстановление системы после сбоя). Перед тем, как данные снова станут доступны для использования, их требуется восстановить из резервной копии.

В теории — это время, требуемое на копирование данных с резервного хранилища на исходное, однако в реальности восстановление может затянутся, например, из-за отсутствия исходного хранилища. Но даже в случае, когда поставщик или сервисная компания сможет быстро предоставить замену, восстановление всех данных из резервной копии может потребовать нескольких десятков часов.

Этот недостаток присущ для большинства систем резервного копирования, хотя существуют и исключения, компания Veeam предоставляет продукт для резервного копирования Veeam Backup & Replication, который позволяет монтировать резервные копии в виде NFS хранилища, и напрямую запускать с них ВМ, а после переносить их на основное хранилище с помощью Storage vMotion.

RPO (Recovery Point Objective или точка восстановления) характеризуется временем, прошедшим с момента последнего резервного копирования данных, и также тем объемом данных, которые были изменены, и соответственно, могут быть потеряны из-за сбоя.

Например, если резервная копия базы была сделана в час дня, в два часа дня в базу были внесены изменения, а в три часа на ЦОД упала бомба, то при восстановлении будут получены данные актуальные на час дня и потеряются все изменения сделанные после.

Таким образом, чем чаще наша система выполняет резервное копирование, тем меньше показатель RPO, большинство СРК позволяют создавать резервные копии хоть каждые 15 минут. Проблемы начинаются в тех случаях, когда для особо критичных сервисов этого может быть недостаточно.

Отдельным пунктом можно выделить мгновенные снимки (snapshots), поддерживаемые большинством СХД, которые хотя и не в полной мере являются резервными копиями, но также позволяют сохранить копию данных на определенный момент времени. Мгновенные снимки могут создаваться администратором вручную или по расписанию, а также использоваться для создания полноценных резервных копий или репликации данных.

Кластеризация СХД
Другой метод защиты данных основан на кластеризации СХД. У разных вендоров технологии обеспечивающие кластеризацию могут называться по разному, у кого-то это синхронизация, у кого-то зеркалирование, но идея одна. Несколько узлов СХД объединяются, и представляются для всех потребителей дисковых ресурсов единым логическим хранилищем (как правило, узлов два, но в некоторых решения их может быть и больше). Внутри хранилища обеспечивается избыточность хранения LUN’ов, таким образом, что отказ одного из узлов не приводит к потере доступа к LUN’у с данными для клиента.

Читайте также:  Не открываются настройки принтера

В качестве примеров кластерных СХД можно привести:

  • HP P4000 (Lefthand).
  • NetApp MetroCluster.
  • EMC VPLEX Metro.
  • Falconstor Network Storage Server.
  • Другие..

При желании можно сделать кластеризованное хранилище из серверов, используя Linux + DRBD + HA + iSCSI Target/NFS Export + пару-другую скриптов.

Даже у VMware есть собственный продукт (vSphere Storage Appliance), позволяющий объединить локальные хранилища серверов виртуализации, однако у него есть ряд серьезных ограничений.

Преимущества кластеризации СХД:

  • Нулевое время простоя в случае отказа одного из узлов.
  • Прозрачная работа для клиентов. Не требуют ручного переключения с одного узла на другой.
  • Возможность организации территориально распределенной СХД (Metro или многосайтового кластера). В этом случае, один из узлов СХД может находиться в одном ЦОДе, второй — в другом ЦОДе расположенном в десятках или даже сотнях километров от первого.

Недостатки кластеризации СХД:

  • Стоимость. Как правило, такие решения представляют собой отдельные линейки СХД midrange или enterprise уровня, или же требуют покупки дополнительных весьма недешевых лицензий.
  • Требование наличия высокоскоростных каналов передачи данных между узлами СХД.
  • В случае распределенной СХД, вероятность возникновения Split Brain.

Что такое Split Brain и почему его следует опасаться? Допустим, у вас есть распределенное двухузловое хранилище, каждый из узлов предоставляет доступ к своему набору LUN’ов. В какой-то момент времени между двумя ЦОДами пропал канал связи. Например экскаватор порвал оптоволокно. В данной ситуации для любого из узлов нет однозначной возможности определить — по какой причине недоступен партнер (т.е. с узлом партнером действительно произошел сбой и оставшемуся узлу следует брать на себя управлением доступом ко всем LUN’ам или же это проблема из-за недоступности канала связи).

В этом случае возможна такая ситуация, когда оба узла посчитают себя активными и станут предоставлять доступ к LUN’у для своей части клиентов. В этом случае может произойти рассинхронизация копий LUN’а, и часть актуальных данных может оказаться в копии, принадлежащей одному узлу, а часть — другому.

Бороться с этим можно различными способами: использовать несколько независимых маршрутов, или организовать третий ЦОД с узлом-арбитром, который будет доступен для узлов кластера по независимым каналам связи и позволит определить, какому из узлов СХД должен принадлежать тот или иной LUN.

Еще один негативный момент использование кластеризации заключается в том, что данные защищаются на уровне физического оборудования, но не на логическом. Любые изменения внутри LUN’а мгновенно синхронизируются, если какой-либо файл или виртуальная машина будет удалена, то это мгновенно отразится на всех копиях. Для того, чтобы иметь возможность «отменить» сделанные изменения следует использовать резервное копирование, мгновенные снимки или асинхронную репликацию.

Репликация
Репликация позволяет настроить копирование по заданному расписанию данных с основного хранилища на резервное. При необходимости, администратор может приостановить репликацию и переключить клиентов на резервное хранилище. Репликация между СХД выполняется на блочном уровне и передает только измененные блоки данных, а не все файлы или LUN’ы целиком.

Функционал репликации есть у большинства вендоров СХД, если не брать в расчет Home Office NAS’ы, где репликация выполняется с помощью какого-нибудь rsync, то, например, в СХД entry уровня HP StorageWorks P2000 G3 появилась такая возможность.

  • Поддержка большим количеством СХД.
  • Меньшие требования к каналам передачи данных.
  • Возможность реплицировать данные одного источника на несколько целевых хранилищ.
  • Реплики данных могут использоваться для создания резервных копий или тестирования.
  • Прежде всего надо понимать, что исходное хранилище и целевое хранилище — это два разных хранилища с точки зрения клиентов (у реплицированного и исходного LUN’а различается идентификатор и серийный номер, у контроллеров, участвующих в репликации разные WWN’ы, IP адреса, IQN имена).
  • Переключение между хранилищами и презентование реплицированного LUN’а занимает определенное время и обычно выполняется администратором вручную.
  • Кроме того, для асинхронной репликации возможна потеря части данных (в зависимости от частоты репликации).

Условной можно разделить репликацию на два типа:

Синхронная репликация очень похожа на синхронизацию данных в кластеризованных СХД, подтверждение операции записи на исходное хранилище отправляется клиенту только после того, как данные будут записаны на резервное хранилище.

К недостаткам синхронной репликации можно отнести высокие требования к каналам связи (фактически такие же как у кластеризованных хранилищ).

Кроме того, при использовании синхронной репликации, у администратора нет возможности «отменить» изменения, сделанные на исходном хранилище (если какие-либо данные удаляются на исходном хранилище, то измененные блоки сразу же копируются, и данные удаляются с резервного хранилища). Для восстановления данных в этом случае потребуется использовать резервные копии или мгновенные снимки.

В свою очередь асинхронная репликация позволяет копировать данные по расписанию (раз в день, раз в час, раз в 5 минут).
Преимущества:

  • Меньшие требования к каналам связи (зачастую для асинхронной репликации применяется также сжатие передаваемых данных, что позволяет еще больше снизить требования к каналам).
  • Обычно реплицированный LUN содержит несколько точек восстановления (мгновенных снимков), необходимых для корректной работы репликации и на случай, если администратор решить вернуться к одной из них.
  • В случае отказа основного хранилища возможна потеря данных, которые не успели реплицироваться на резервное хранилище.

Рассмотренные выше варианты защиты данных не исключают друг-друга и в ряде случаев могут применяться совместно. Если говорить непосредственно о VMware SRM, то весь функционал продукта строится как раз вокруг возможности репликации данных средствами СХД (хотя стоит отметить, что в последней на сегодня 5-й версии появилась возможность организовать репликацию средствами SRM). Но об этом в следующий раз.

Источник

Adblock
detector