Разворот и базовая настройка Site Recovery Manager 8.3.1

Site Recovery Manager – это служба восстановления виртуальных машин, автоматизирующая аварийное переключение между защищаемым сайтом и сайтом восстановления и возврат в основную среду данных для систем виртуализации VMware. Благодаря ему обеспечивается непрерывность функционирования бизнес-критических служб дата-центров и осуществляется процесс защиты информации ВМ.

На данный момент актуальной его версией является 8.3.1 и о том, как до нее проапгрейдится, а также что нового в ней появилось, по сравнению с предыдущей, рассказывалось здесь и здесь.

Так как, по сути, SRM является надстройкой над существующей виртуальной средой, последняя должна соответствовать ряду требований к совместимости и настройке. Кроме того, следует предварительно осуществить некоторые важные подготовительные мероприятия. Подробно все это описывалось в статье «Обновление VMware Site Recovery Manager до версии 8.3.1», а на минимальных требованиях к системе и организации сети, а также операционных ограничениях для службы в деталях остановимся ниже.

Все это рекомендуется заранее изучить, чтобы понимать, как строить архитектуру решения в целом и на что она способна. И только потом непосредственно приступать к развороту и настройке VMware Site Recovery Manager 8.3.1. А для начала огласим некоторые важные для решения определения и механизмы его работы.

Немного теории

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

Упрощая, можно сказать, что SRM налаживает связь и функционал взаимодействия между защищаемым сайтом и сайтом восстановления – так называемую миграцию. Автоматизируя и оптимизируя все задействованные процессы.

Виды миграции

Миграция, в свою очередь, бывает нескольких видов:

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

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

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

Гетерогенность конфигураций

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

Исходя из гетерогенности конфигураций, доступны такие возможности:

На одном из сайтов работает vCenter Server Appliance, тогда как на другом – стандартный инстанс vCenter Server;
На защищаемом сайте и на сайте восстановления могут быть разные версии массивов хранилищ при основанной на массивах репликации;
Тип базы данных SRM на обоих сайтах может быть разным;
Операционная система хоста SRM на защищенном сайте и сайте восстановления может отличаться. Аналогично для vCenter Server.

Требования к защищаемому сайту и сайту восстановления

Часть требований к версионности и наличию компонентов описана в статье «Обновление VMware Site Recovery Manager до версии 8.3.1». Кроме того:

У каждого сайта на борту – минимум один дата-центр;
Ресурсы железа, сети и хранилища сайта восстановления должны поддерживать такие же рабочие процессы и виртуальные машины, что и защищаемый сайт. Возможности сайта восстановления можно расширить, запустив там дополнительные незащищенные ВМ. Однако в процессе восстановления некритичные машины на сайте восстановления следует приостановить, чтобы не терять производительность;
Оба сайта должны быть подключены к доверенной IP-сети. Если используется репликация на основе массива, следует убедиться, что сетевое подключение соответствует сетевым требованиям массивов;
Для сайта восстановления открыт доступ к сопоставимым публичным и приватным сетям – точно так же, как и для защищаемого сайта. Хотя диапазон сетевых адресов при этом у них может отличаться.

Операционные ограничения для Site Recovery Manager 8.3.1

Каждый сервер Site Recovery Manager может накрыть лишь определенное количество защищаемых виртуальных машин, групп защиты, групп хранилищ данных, планов по восстановлению и одновременно выполняемых восстановлений.

Максимумы защиты для Site Recovery Manager 8.3.1

Основанные на массивах группы защиты и группы защиты vSphere Replication, а также группы защиты политик хранения можно запускать на одном и том же инстансе сервера Site Recovery Manager. Их количество не может превышать 500, независимо от типа защиты. Аналогично для настройки, в которой репликация vSphere сочетается с репликацией на основе массива, защищается максимум 5000 ВМ. Хотя предел защиты конкретно для vSphere Replication – 2000. Но, суммарно при комбинации репликаций, их возможное количество не складывается (7000), а определяется наибольшим значением (5000).

Интересно, что если с помощью репликации на основе массивов защищается 1000 машин, то с помощью vSphere Replication можно будет защитить еще всего 2000.

Двунаправленная защита

При двунаправленной защите, где сайт Б служит сайтом восстановления для сайта А, а А, в свою очередь, – сайтом восстановления для Б, ограничения работают для обоих, а не для каждого в отдельности. На этих сайтах может защищаться разное количество машин, однако суммарно, все равно, их число не может превышать вышеописанных ограничений.

Максимумы восстановления для Site Recovery Manager 8.3.1

Эти ограничения демонстрируют, что даже если под защитой находятся все 5000 ВМ, за один план восстановления процедура сработает только для 2000 машин. Однако по ее завершению можно запустить следующий план, и тогда еще 2000 успешно восстановятся. И т.д. Примечательно, что, организовав сразу пять планов восстановления, по 1000 машин в каждом, всего два плана из них могут быть запущены одновременно (чтобы суммарно дать те самые 2000). Количество одновременно запускаемых планов не может превышать 10, то есть 10 планов по 200 машин.

Максимальные параметры IP-кастомизации для Site Recovery Manager 8.3

При имплементации IP-кастомизации для восстанавливаемых виртуальных машин при использовании DHCP можно настроить только один IP-адрес для каждой сетевой карты, статический IPv4 или статический IPv6. Для статических IPv4 или IPv6 адресов предоставляется следующая информация (на каждую сетевую карту):

1 IP-адрес,
информация о подсети,
1 адрес сервера GW,
2 DNS-сервера (первичный и вторичный).

На Windows-виртуалках назначается только 2 WINS-адреса для DHCP или IPv4.

Максимумы разворота Site Recovery Manager 8.3 в Shared Recovery Site Configuration

В расшаренной конфигурации сайта восстановления можно развернуть до 10 серверных инстансов Site Recovery Manager для каждого инстанса vCenter Server. Лимиты применяются к паре.

Предостережения и ограничения

Если работают с репликацией vVols, рекомендуется использовать хранилище данных VMFS как основное.
Когда создается связанная машина-клон, некоторые ее диски продолжают пользоваться дисками базовой виртуальной машины.
При репликации vVols нужно реплицировать связанную виртуальную машину в той же самой группе репликации, в которой находится и базовая, иначе вылетит ошибка:

Virtual machine ‘{vmName}’ is replicated by multiple replication groups.

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

Для vCenter Server 6.7U3 зашифрованные виртуальные машины в группах защиты vVols не поддерживаются.
В Site Recovery Manager3.1 не поддерживается включение хеширования SHA-1 для Windows. Чтобы этого добиться, нужно использовать Site Recovery Manager 8.3.1 Appliance.
Сетевое автоназначение для хранения политик групп защиты не поддерживается на NSX-T Data Centers.
Защита и восстановление зашифрованных виртуальных машин с основанной на массивах репликацией групп защиты требует версии vSphere 6.7 и выше.
Защита и восстановление зашифрованных ВМ с vSphere Replication требует апдейта U1 vSphere7, либо более свежего.
Site Recovery Manager 8.3.1 не поддерживает восстановление зашифрованных виртуальных машин в основанной на массивах репликации групп защиты с vCenter Server 6.5 Update 2.
VMware Site Recovery Manager3.1 Configuration Import/Export Tool Importing пытается импортировать настройки восстанавливаемой защищенной ВМ только один раз, независимо от того, являются ли защищаемые виртуальные машины частью одного или многих recovery-планов.
После восстановления vSphere Flash Read Cache выключен на виртуальных машинах и резервирование сброшено до нулевого значения. Перед процедурой восстановления на сконфигурированной для использования vSphere Flash Read Cache машине, рекомендуется сделать заметки о текущем значении резервирования (смотреть в vSphere Web Client). Тогда после восстановления будет легче реконфигурировать vSphere Flash Read Cache.
Site Recovery Manager 8.3.1 поддерживает защиту ВМ однопроцессорной vSphere FT, но после восстановления она будет деактивирована. Если используется однопроцессорная vSphere FT на виртуальных машинах, следует их настроить для однопроцессорной vSphere FT как показано в гайде.
vSphere Replication3.1 поддерживает репликацию на VMware vSphere Virtual Volumes с ограничениями:
- Нельзя делать снэпшоты vSphere Replications Point-in-Time с виртуальных машин, где целью репликации является хранилище данных Virtual Volumes;
- При использовании vSphere Virtual Volumes как цели репликации, все диски, принадлежащие виртуальной машине, должны быть реплицированы в одно хранилище;
- Если реплицируемая виртуальная машина расположена в vSphere Virtual Volumes, все ее диски должны находиться в одном хранилище данных.
Site Recovery Manager 8.3.1 не поддерживает хранилища данных NFS 4.1.
Не поддерживается реконфигурация профиля хранения групп защиты, например, изменение комплекта связанных политик хранения, имени группы, описаний. Чтобы переназначить профиль хранения групп защиты, следует вначале удалить его, а затем создать его с новой конфигурацией.
Site Recovery Manager не защищает RDM-диски или fault-tolerant виртуальные машины в группах защиты политик хранения.
Не поддерживается сопоставление или исключение нереплицированных виртуальных устройств в группах защиты политик хранения.
Чтобы применять двухфакторную идентификацию с RSA SecureID или Smart Card (Common Access Card) аутентификацию среда должна соответствовать следующим требованиям:
- В процессе инсталлирования Site Recovery Manager 8.3.1, а также назначения пар сайтов, нужно использовать учетные данные администратора Platform Services Controller;
- Инстансы vCenter Server на обоих сайтах должны работать в Enhanced Linked Mode. Чтобы избежать ошибок в процессе апдейта Site Recovery Manager с 8.3.1 до последующих версий, инстансы vCenter Server на обоих сайтах должны быть назначены, как прямые партнеры по репликации.

Требования

Минимальные системные требования для SRM Windows

CPU: Два 2.0 Гц (Intel/AMD) х86 процессора или лучше.

Важно! Если SRM разворачивается на больших средах, минимальное количество CPU удваивается.

RAM: 4 ГБ. Размер памяти растет пропорционально при использовании встроенной базы данных, когда размер самой базы данных увеличивается.
Дисковое хранилище: 5 ГБ. Если инсталлятор SRM помещается на отличный от С: диск, на диске С: все равно требуется минимум 1 ГБ свободного места для извлечения и кэширования инсталляционного пакета.
Сеть: 1 Гбит между сайтами SRM. Рекомендовано использовать доверенные сети.

Минимальные системные требования для Site Recovery Manager Virtual Appliance

CPU: 2 vCPU (Light) или 4 vCPU (стандарт);
RAM: 8 ГБ (Light) или 12 ГБ (стандарт);
Дисковое хранилище: один диск 16 ГБ (и для Light-варианта, и для стандарта);
Сеть: 1 Гбит (и для Light-варианта, и для стандарта).

Light-вариант используется для защиты 1000 и менее ВМ, стандарт – для большего количества.

Лицензирование

После успешной инсталляции SRM, служба будет работать в ознакомительном режиме (evaluation mode), пока не введены лицензионные ключи. По окончании разрешенного периода существующие группы защиты сохранят свой статус и процедуры восстановления останутся активными, однако создавать новые группы защиты, добавлять ВМ в уже имеющиеся будет невозможно.
Каждый вид лицензии позволяет защищать предопределенное количество виртуальных машин.
Если инстансы vCenter Server находятся в Linked Mode, лицензии SRM устанавливаются для обоих.
Одинаковая лицензия SRM устанавливается на разных принадлежащих одному и тому же Platform Services Controller инстансах vCenter Server.
Если нужна однонаправленная защита с защищаемого сайта на сайт восстановления, ключи вводятся только для первого. При двунаправленном типе миграции, они нужны на обоих.
Если в процессе работы SRM обнаружит невалидность лицензии или она не будет соответствовать производимым операциям, vSphere создаст лицензионное предупреждение, а служба приостановит свою работу. Система предупреждений настраивается, так что можно организовать рассылку таких предупреждений в удобном виде, в том числе и на email администраторов.

Процедура разворота

Задачей процедуры разворота Site Recovery Manager 8.3.1 будет реализация следующей схемы миграции:

Создание SSL/TLS-сертификатов для Server Endpoint

SRM требует сертификат SSL/TLS в качестве endpoint-сертификата. Он отличается от того, который формируется в процессе создания и регистрации пользователя решения, и служит для идентификации клиентского Site Recovery Manager Server.

Чистая инсталляция SRM 8.3.1 автоматически создает самоподписанный SSL-сертификат, действующий пять лет с момент первого запуска Appliance.

При установке SRM 8.3.1 для Windows доступна опция для генерирования SSL/TLS-сертификатов. Очень простая, с минимум пользовательских действий.

Также можно внедрить настраиваемый SSL/TLS-сертификат типа PKCS#12, но для сопоставимости с SRM он должен отвечать ряду требований.

Важно! Аутентификация Site Recovery Manager 8.x через vCenter Server не использует настраиваемый SSL/TLS-сертификат.

Требования для настраиваемого SSL/TLS-сертификата

Алгоритмы подписи MD5 не принимаются. Только SHA256 или выше (SHA-1 также не подходит);
Личный ключ в файле PKCS #12 должен совпадать с сертификатом. Минимальная длина личного ключа – 2048 бит;
В пароле к сертификату SRM не должно быть более 31 символа;
Текущее время должно вписываться в период валидности сертификата;
Чтобы служить индикатором TLS Web Server Authentication, сертификат должен быть серверным с x509v3 Extended Key Usage. В нем обязательно прописан атрибут «extendedKeyUsage» или «enhancedKeyUsage» со значением «serverAuth». При этом «clientAuth» не требуется;
«Subject Name» не должен быть пустым, но содержать менее 4096 символов. Он может не совпадать с аналогом для парного сайта SRM;
Сертификат должен идентифицировать хост Site Recovery Manager Server. Рекомендовано организовывать это путем указания FQDN хоста. Если же хост идентифицируется с IP-адресом – это будет IPv4-адрес. Использование IPv6-адреса не поддерживается. Сама идентификация хоста, обычно, происходит в атрибуте SAN, но некоторые СА требуют ее в CN значении. Последнее не относится к best practice. Подробнее об этом почитать можно здесь.

Важно! Идентификатор хоста в сертификате должен совпадать с локальным адресом хоста Site Recovery Manager Server, который указывался при инсталляции.

Выданный третьей стороной сертификат, не аккредитованной по умолчанию в Windows, нуждается в установке в Windows certificate store, если хочется достичь доверия к подлинности без проверки отпечатков.

Включение функции SHA-1-хэширования

Подписанные при помощи функции хэширования SHA-1 сертификаты Site Recovery Manager Appliance могут инсталлироваться, если это позволяет среда. По умолчанию, сервер Site Recovery Manager отклоняет инсталляцию таких новых сертификаций. Но, эту возможность можно специально включить в SRM Appliance, если:

Установить связь по SSH к Site Recovery Manager Appliance;
Пройти в папку «/opt/vmware/srm/conf/» и открыть «vmware-dr.xml», а также «drconfig.xml» в текстовом редакторе;
Найти секцию «<connections>» и добавить после нее секцию «<allowSha1>»:

<allowSha1>true<allowSha1>.

Сохранить изменения и перезапустить службу Site Recovery Manager Server;
Для перезагрузки службы dr-configurator выполнить команду:

sudo systemctl restart dr-configurator.

Разворот Site Recovery Manager Virtual Appliance

SRM Virtual Appliance представляет собой сконфигурированную виртуальную машину, оптимизированную для работы Site Recovery Manager и связанных с ним сервисов. Она используется и на защищаемом сайте, и на сайте восстановления. Функциональной может быть и комбинация SRM Virtual Appliance с Site Recovery Manager для Windows.

Site Recovery Manager Appliance поддерживает исключительно встроенную vPostgress базу данных.

Для начала нам понадобится скачать инсталлятор 64-bit Site Recovery Manager в формате «.iso» отсюда. Так как он разворачивается в уже имеющейся среде vCenter Server, предварительно ее необходимо организовать, полностью сформировать и настроить хост ESXi (подробный гайд на тему). Тогда из системы управления ESXi-хостом можно будет воспользоваться мастером-установщиком Site Recovery Manager Virtual Appliance.

Конкретно процедура инсталляции на защищаемом сайте будет выглядеть следующим образом:

Заходим в веб-клиент vSphere;
Кликаем правой кнопкой мыши на хост и выбираем «Deploy OVF template»:

В появившемся окне проходим по порядку пункты меню слева по кнопке «Next».

«Select an OVF template». Появится выбор между скачиванием с URL и локальной загрузкой, выбираем «Local file». Жмем «Upload files» и кнопку «Next»:

Сообщаем расположение образа, выбираем все файлы из папки «bin», нажав «Open», затем кнопку «Next» внизу;
«Select a name and folder». Выбираем имя виртуальной машины и расположение:

«Select a compute resource»:

Проверяем, все ли правильно ввели в «Review details»;
«License agreements» – соглашаемся;
«Configuration»: выбираем тип конфигурации «Light» или «Standard» (требования по ним описывались в «Минимальные системные требования для Site Recovery Manager Virtual Appliance» раздела «Требования» выше):

«Select storage»: выбираем хранилище, где будет осуществлен разворот:

«Select networks»: выбираем группу портов, где разворот будет использоваться:

«Customize template» – назначаем, по пунктам:
- Enable SSHD (значение «Enabled»);
- Initial root password ;
- Initial admin password;
- NTP Server (FQDN или IP-адрес);
- Hostname для этой ВМ;
- Initial database password;

Должно получится, как здесь:

Переходим на следующую страницу конфигурирования кнопкой «Next». Далее:

- File Integrity flag (значение «Enabled»);
- HCX Flag (галочку не ставим);
- Host Network IP Address Family (в выпадающем меню выбираем, например, «IPV4»);
- Host Network Mode (в выпадающем меню выбираем «Static»);
- Default Gateway;
- Domain Name;
- Domain Search Path;

Должно получится как здесь:

Завершаем назначение кнопкой «Next».

«Ready to complete» – жмем «Finish».

После этого в vCenter в «Recent Tasks» будет видно, что Virtual Appliance развернулся.

Повторяем все действия для сайта восстановления.

Конфигурирование SRM Virtual Appliance

Заходим в удаленную консоль и убеждаемся, что Virtual Appliance полностью загрузился (должна появится фраза «Welcome to VMware Site Recovery Manager Appliance»). Теперь в веб-браузере открываем Site Recovery Manager Appliance Management Interface через аккаунт администратора, введя путь «https://xxx», где ххх – FQDN или IP-адрес SRM VA и кликнув на «Launch SRM Appliance Management»:

Появится окно управления с меню слева. Вначале стоит убедиться, что в пунктах «Networking» и «Time» назначено все верно:

Затем открываем «Syslog Forwarding», нажимаем «New»:

и в появившемся окне вводим нужные значения:

Server Address (IP-адрес или FQDN сервера логов);
Protocol (в выпадающем меню TCP/ UDP/RELP)
Port (назначенный порт или порт своей среды):

Он отобразится в таком виде:

Проделываем аналогичное для сайта восстановления.

Чтобы SRM Appliance подключился к инстансу vCenter Server, и для защищаемого сайта, и для сайта восстановления надо убедиться, что в пункте «Summary» указана нужная версия продукта и актуальная сборка, после чего нажать на кнопку «Configure Appliance». Пробежимся по пунктам настройки:

«Platform services controller». Вводим имя хоста PSC, порт подключения, имя пользователя и пароль:

Если нажать кнопку «Next» внизу, вылетит предупреждение по безопасности. Чтобы продолжить работу, следует нажать кнопку «Connect».

«vCenter Server». Информация о vCenter Server, где было указано развернуть SRM VA. «Next». Снова предупреждение по безопасности, и снова – «Connect».
«Name and Extension». Выбираем имя сайта SRM, вводим email администратора, локальный хост и его адрес:

«Next».

На «Ready to complete» жмем «Finish». Запустится прогресс-бар регистрации vCenter Server.

Успешная регистрация будет отражена в пункте «Summary».

Базовая настройка Site Recovery Manager Virtual Appliance

В установленном и подключенном к инстансу vCenter Server SRM VA следует назначить ряд компонентов и осуществить их начальную настройку. В идеале, пошагово нужно осуществить следующее:

назначить новую пару сайтов;
проинсталлировать Storage Replication Adapter (SRA) и настроить пару массивов (если работаем с основанной на массивах репликацией);
сконфигурировать ассоциации для компонентов инвентаря (ассоциации сети, папок, ресурсов и placeholder хранилищ);
создать и настроить группу защиты, а также план восстановления, задав, в том числе, и параметры виртуальной машины восстановления;
запустить тест плана восстановления;
запустить регулярный план восстановления.

Запуск защиты пары сайтов в SRM

Когда SRM Virtual Appliance установился и подключился к vCenter Server, необходимо назначать пару «protected – recovery» сайтов. Заходим в браузере в клиент SRM VA, введя «https://xxx», где ххх – его FQDN или IP-адрес, и нажимаем «Launch Site Recovery»:

Зайдя под учетной записью администратора, нажимаем кнопочку «New site pair»:

и в появившемся окне последовательно проходим все пункты меню:

На вкладке «Site details» выбираем локальный vCenter Server, которому хотим назначить пару, и прописываем все характеристики второго сайта:

После нажатия «Next» вылетит предупреждение по безопасности, где нажимаем «Connect».

«vCenter Server and Services». Для нашего защищаемого сайта выбираем удаленный vCenter и службы:

«Next» опять выдаст оповещение безопасности, где снова жмем «Connect».

«Ready to complete». Проверяем назначение и завершаем его кнопкой «Finish».

После всего в клиенте Site Recovery Manager VA увидим такую картину:

Инсталляция Storage Replication Adapter (SRA)

Защита SRM, в которой используется репликация на основе массивов, требует установки Storage Replication Adapter (SRA). Для нее проходим следующие этапы:

В панели конфигурирования SRM Virtual Appliance заходим на последнюю вкладку левого меню «Storage Replication Adapters» и кликаем на кнопку «New Adapter»:

Далее жмем на «Upload» здесь:

Выбираем желаемый для загрузки SRA и затем кликаем на «Open», после чего появится прогресс-бар, а затем – сообщение об успешном завершении процесса.
Теперь на странице Storage Replication Adapters появится информация о загруженном и установленном SRA.

Конфигурирование пары массивов

После установки SRA и захода в клиент Site Recovery Manager в пункте «Array Based Replication» раздела «Configure» появится вкладка «Array Pairs», где нужно нажать «Add»:

В открывшемся окне проходим все пункты меню слева:

«Storage Replication Adapter». Выбираем требуемый SRA, после чего жмем «Next».
«Local Array Manager». Вписываем конфигурацию локального массива (имя хоста/IP, имя пользователя и пароль):

«Next».

«Remote Array Manager». Аналогично для удаленного:

«Next».

«Array Pairs». Включаем парный массив к основному:

«Next».

«Ready to complete». Проверяем выбор и подтверждаем добавление пары кнопкой «Finish».

Теперь на вкладке «Array Pairs» появится заданная пара.

Задание ассоциации сетей

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

В подразделе «Network Mappings» раздела «Configure», активировав поле с первым (основным) сайтом, нажимаем кнопку «New»:

Откроется окно, в котором пошагово пройдем все пункты.

«Creation Mode». Процесс может быть, как автоматическим, так и проделанным вручную. Первое означает, что сети на защищаемом сайте и на сайте восстановления будут иметь одинаковые имена. При втором задаем их вручную. Выбор делается здесь:

«Next».

«Recovery Networks». Выбираем группу портов для защищаемого сайта, а затем – соответствующую ей сайта восстановления, после чего нажимаем кнопку «Add Mappings» ниже:

«Next».

«Reverse Mapping». Ставим галочку на появившейся паре сетей для выбора обратной ассоциации и жмем «Next»:

«Test Networks». Здесь выбирается сеть для тестирования плана восстановления. Лучше предпочесть изолированную:

«Next».

«Ready to complete». Проверяем все назначенное и жмем «Finish».

Добавление кастомизации IP к существующей ассоциации сетей

Для аварийного переключения и восстановления после сбоя можно использовать функционал автоматического изменения сетевой конфигурации ВМ. Делается это в подразделе «Network Mappings» раздела «Configure» клиента SRM. Процесс кастомизации IP выглядит так:

На вкладке активируем защищаемый сайт, ставим галочку на заданной ассоциации сетей, жмем на «…» вверху таблички и выбираем «Add IP Customization Rule»:

В выпавшем окне прописываем информацию о подсети и для защищаемого сайта, и для сайта восстановления, а также назначаем для сети восстановления шлюз, DNS-адресацию и DNS Suffix:

«Add».

В «Network Mappings» активируем сайт восстановления, ставим галочку на выбранной ассоциации и жмем на «…» вверху. Выбираем «Add IP Customization Rule»:

Аналогично пункту 2. прописываем свои значения для восстанавливаемого сайта и соглашаемся с выбором кнопкой «Add».

Ассоциация папок

Под подразделом «Network Mappings» находится вкладка «Folder Mappings», в которой производится настройка ассоциации папок. Выбираем защищаемый сайт и жмем кнопку «New»:

Далее идем по пунктам меню:

«Creation Mode». Выбор из двух типов организации: автоматической и вручную. Первое означает, что папки на защищаемом сайте и на сайте восстановления будут иметь одинаковые имена. При втором задаем их, прописывая разные:

«Next».

«Recovery Folders». Выбираем папку на защищаемом сайте, а затем соответствующую на сайте восстановления. Жмем кнопку «Add Mappings» и после этого – «Next»:

«Reverse mappings». Ставим галочку в поле соответствия для обратной ассоциации и жмем «Next»:

«Ready to complete». Проверяем выбор и соглашаемся кнопкой «Finish».

Ресурсы ассоциации

Далее в «Configure» выбираем вкладку «Resource Mappings», активируем защищаемый сайт и нажимаем кнопку «New» для задания новых:

Теперь идем по пунктам:

«Recovery Resources». Выбираем кластер на защищаемом сайте и соответствующий ему – на сайте восстановления. Жмем «Add Mappings»:

«Next».

«Reverse mappings». Ставим галочку для задания обратной ассоциации:

«Next».

«Ready to complete». Проверяем назначенное и завершаем кнопкой «Finish».

Хранилище Placeholder

Для складирования placeholder виртуальных машин в SRM используется специальное хранилище Placeholder. Организовать его поможет вкладка «Placeholder Datastore» в «Configure». Щелкаем в ней на защищаемый сайт и нажимаем кнопку «New»:

В появившемся окне выбираем нереплицируемое хранилище и нажимаем «Add».

Затем на вкладке «Placeholder Datastore» выбираем сайт восстановления и снова – «New». В появившемся окне задаем нереплицируемый placeholder защищаемой ВМ и жмем «Add».

Создание группы защиты и плана восстановления

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

Выберем в верхнем горизонтальном меню клиента SRM раздел «Protection Groups» и в открывшемся окне нажмем «New»:

Далее идем по пунктам:

«Name and Direction». Назначаем имя группе и поясняющее ее описание, задаем направление защиты и размещение, после чего жмем «Next»:

«Type». Выбираем тип группы защиты (основанная на массивах репликация, vSphere Replication, vVol replication или политик хранения) и выбираем назначенную пару:

«Datastore groups». Определяем нуждающееся в репликации хранилище, после чего все помеченные в нем машины образуют группу защиты.
«Recovery plan». Здесь выбранную группу можно как присоединить к уже существующему плану восстановления, так и организовать новый, либо же пока воздержаться от действий по ее защите. Кроме того, надо ввести наименование для выбранного плана восстановления:

«Ready to complete». Проверяем все созданную конфигурацию и соглашаемся с ней кнопкой «Finish».

После этого группа защиты появится в списке «Protection Groups» на соответствующей вкладке.

Настройка плана восстановления

В SRM можно по-разному настраивать план восстановления, исходя из задаваемых в нем параметров. Эти параметры включают в себя изменение групп приоритетов, действия до и после включения, настройку зависимостей ВМ и механизм включения-выключения.

Сейчас попробуем задать самую элементарную настройку плана восстановления:

В верхнем меню клиента SRM выбираем вкладку «Recovery Plans» и в ней щелкаем по созданному плану восстановления (его имя придумывали выше в «Protection Groups»):

В открывшемся окне выбираем в верхнем меню «Virtual Machines»:

В появившемся списке ВМ ставим галочку на машине, для которой хотим задать параметры и сверху нажимаем на «Configure Recovery»:

Откроется окно, в котором надо выбрать связанную машину галочкой и нажать «OK»:

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

Все ли грамотно назначено и удовлетворяет ли работа назначенного плана восстановления можно проверить, запустив соответствующий тест. Для этого:

Выбираем в клиенте в верхнем меню вкладку «Recovery Plans» и в боковом меню – сам тестируемый план:

В открывшейся для этого плана вкладке в верхнем ее меню выбираем «Recovery Steps», а затем «Test»:

Проверяем в появившемся окне в пункте «Confirmation options» правильно ли назначен путь репликации и состояние соединения серверов, количество ВМ, после чего ставим галочку в строке «Replicate recent changes to recovery site» и жмем «Next»:

На «Ready to complete» соглашаемся со всем кнопкой «Finish».

Как только это будет сделано, во вкладке «Recovery Steps» будут отображаться шаги восстановления в режиме реального времени. Ее анализ помогает в troubleshooting плана восстановления, показывая ошибки и предупреждения. По окончанию тестовой прогонки появится резюме по проблемам и статусу плана. После того, как со всеми ошибками будет покончено, обязательно следует нажать кнопочку «Cleanup» для очистки:

Запуск плана восстановления

Важно! Как только запустится план восстановления, все ВМ на защищаемом сайте выключатся и включатся на сайте восстановления. Рекомендация сделать предварительно бекап, и окончательно убедиться, что в тестовом запуске все проходит идеально.

Запускается регулярный план восстановления на той же вкладке, что и тестовый, после его выбора в списке:

В открывшемся окне в пункте меню «Confirmation options» нужно выбрать тип восстановления:

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

Важно! Для максимальной эффективности аварийного восстановления следует использовать самые свежие данные хранилища синхронизации.

После выбора соглашаемся кнопкой «Next»:

В пункте «Ready to complete» проверяем все назначения, после чего запускаем миграцию кнопкой «Finish». Ее шаги в режиме реального времени со всеми ошибками и предупреждениями будут отображаться на вкладке «Recovery Steps». По окончанию процесса, демонстрируется сообщение о его успешности. И если все хорошо, надо инициировать повторную защиту плана восстановления (реверс):

Снова откроется вкладка с парой пунктов меню. В первом «Confirmation options» увидим обратный путь миграции и убедимся, что все ОК. Соглашаемся галочкой с предупреждением и жмем «Next»:

Важно! Если процессе защиты ошибок не было, строка «Force Cleanup» будет серой и не даст поставить галочку. В противном случае ставим ее, чтобы очистить.

В пункте «Ready to complete» еще раз проверяем правильность заданных параметров и жмем «Finish», после чего во вкладке «Recovery Steps» снова будет видно прогресс процесса в реальном времени. Когда он завершится, служба сообщит об успехе.

Для изучения более глубокой настройки VMware Site Recovery Manager 8.3.1, частных случаев применения, troubleshooting и прочих нюансов рекомендуется обучиться на соответствующих авторизованных курсах вендора.