Продолжение статьи о настройке виртуального хранилища NetApp Data ONTAP Edge. Сегодня о том, как настроить синхронную репликацию между двумя хранилищами. Первая часть статьи тут.
Для корректной работы репликации важно правильно настроить службу разрешения имен на хранилищах и добавить все необходимые A-записи, которые позволяли бы разрешать имена как самих хранилищ, так и дополнительных сетевых интерфейсов. Это важно в случае, если в при настройке вы пользуетесь не конкретными IP адресами, а алиасами, вроде ontap02, ontap01-e0a и т.п.
На исходном хранилище включите репликацию, используя команду:
Из .ova шаблона разверните новую ВМ, которая будет использоваться в качестве целевого хранилища. Подробную информацию о развертывании смотрите в первой части.
При развертывании задайте другое имя (ontap02) и другой IP адрес (192.168.1.252).
После завершения, зайдите в консоль ВМ и с помощью команды setup задайте IP адрес на интерфейсе e0b (192.168.2.252). Остальные настройки можете задать по аналогии с ontap01. Не забудьте перезагрузиться (reboot).
Добавьте лицензии с помощью license add.
Создайте новый том, который будет использоваться для хранения реплицированных данных с основного хранилища, а также группу инициаторов, в которой будет находиться резервный сервер виртуализации на втором сайте (esx02). Также запустите службу iSCSI.
Формат конфигурации выглядит следующим образом:
destination- целевая пара пара хранилище:том, например (ontap02:vol1);
arguments - дополнительные аргументы, такие как ограничение максимальной скорости передачи данных, использование сжатия и т.п. Если дополнительные аргументы не указывается, то ставится прочерк "-".
schedule- расписание репликации (для асинхронной репликации), либо параметр "sync" (для синхронной репликации).
Например, для синхронной репликации vol1 с хранилища ontap01 на хранилище ontap02, конфигурация будет выглядеть следующим образом:
mode - режим использования пар IP адресов: failover (использование одной пары в качестве основной, а второй в качестве резервной), или multi (использование обоих пар одновременно с балансировкой нагрузки);
source_ip_addrN - IP адрес интерфейса исходного хранилища;
dest_ip_addrN - IP адрес интерфейса целевого хранилища.
Например:
Таким образом, файл конфигурации snapmirror.conf будет выглядеть следующим образом:
Во-первых, подключить корневой том (vol0) по протоколу NFS, как было описано в предыдущей статье, и использовать текстовый редактор, поддерживающий переносы в стиле *nix, например, Notepad++.
Во-вторых, с помощью команды wrfile.
Если вам требуется добавить строку в существующий файл, используйте команду:
<destination>- целевая пара пара хранилище:том, например (ontap02:vol1)
Для запуска репликации тома vol1 с хранилища ontap01 на хранилище ontap02 выполните:
После того, как все данные будут переданы, репликация на короткое время перейдет в состояние idle, а затем in-sync, означающее, что синхронная репликация работает.
Для начала скопируйте на LUN в основном сайте какую-либо тестовую ВМ или файлы, после чего остановите репликацию, введя команду на целевом хранилище:
Например:
Презентуйте реплицированный LUN серверу ESXi во втором сайте:
ESXi автоматически не монтирует реплицированные datastore'ы. Поэтому требуется смонтировать хранилище вручную. Для этого выберите Configuration -> Storage -> Add Storage. Из списка дисков выберите реплицированный LUN. Для монтирования с сохранением файловой системы и всех данных выберите один из двух вариантов: Keep the existing signature или Assign a new signature.
Для реплицированного хранилища будет сгенерировано новое имя.
Теперь вы можете зайти на реплицированный Datastore, зарегистрировать и запустить ВМ для проверки.
После завершения тестирования для возобновления репликации разрегистрируйте тестовую ВМ, отключите реплицированный том и выполните ресинхронизацию на целевом хранилище с помощью команды:
Через некоторое время все изменения будут синхронизированы и пара перейдет в состояние in-sync.
Схожим образом можно осуществить запланированный перенос инфраструктуры ВМ из основного сайте в резервный. Алгоритм переноса выглядит следующим образом:
Примечание: Если вы используете данный вариант для тестирования, то учтите, что он имеет один существенный недостаток - на время теста данные с основного хранилища не реплицируются на резервное, поэтому если в этот момент произойдет сбой, есть риск потери определенного объема данных.
Создать flexclone том на целевом хранилище можно следующей командой:
[-s none | file | volume]- резервирование пространства под создаваемый том;
-b <parent_flexvol>- имя тома, из которого будет создан клон;
[<parent_snapshot>]- снапшот тома, из которого будет создан клон.
Например:
Посмотреть список доступный снапшотов для тома можно с помощью команды:
Для того, чтобы иметь возможность смонтировать LUN, переведите его в режим online, выполнив команду:
После проверки репликации, отключите flexclone том, используя команду:
План такой:
Репликация в обратную сторону настраивается аналогичным образом.
На хранилище в резервном сайте (ontap02) добавьте IP адреса хранилища основного сайта:
Однако, далеко не всегда работа из командной строки является приемлемым вариантом. В больших инфраструктурах, насчитывающих сотни виртуальных машин, а также при необходимости уменьшения времени простоя, для автоматизации операции восстановления ВМ на резервном сайте может пригодиться такой продукт, как VMware Site Recovery Manager. VMware SRM позволяет заранее настроить процедуры тестирования, переноса или восстановления ВМ в резервном сайте, избавив администратора от необходимости работы с консолью, ограничившись лишь несколькими щелчками мыши в интерфейсе vSphere Client. Более подробно о SRM вы можете прочитать тут.
Настройка DNS
Для корректной работы репликации важно правильно настроить службу разрешения имен на хранилищах и добавить все необходимые A-записи, которые позволяли бы разрешать имена как самих хранилищ, так и дополнительных сетевых интерфейсов. Это важно в случае, если в при настройке вы пользуетесь не конкретными IP адресами, а алиасами, вроде ontap02, ontap01-e0a и т.п.
Настройка исходного хранилища
Все указанные ниже настройки выполняются на исходном хранилище (ontap01).На исходном хранилище включите репликацию, используя команду:
options snapmirror.enable onУкажите, какие хосты являются целевыми для репликации, и на какие IP адреса могут реплицироваться данные:
options snapmirror.access host=<HOST_IP1>,< HOST_IP2>[,...,< HOST_IPN>]Например, чтобы разрешить репликацию на хранилище ontap02, который имеет два IP адреса (192.168.1.252 и 192.168.2.252), введите:
options snapmirror.access host=192.168.1.252,192.168.2.252Просмотреть все опции, связанные с репликацией можно с помощью команды:
options snapmirror
Настройка целевого хранилища
Все указанные ниже настройки выполняются на целевом хранилище (ontap02).Из .ova шаблона разверните новую ВМ, которая будет использоваться в качестве целевого хранилища. Подробную информацию о развертывании смотрите в первой части.
При развертывании задайте другое имя (ontap02) и другой IP адрес (192.168.1.252).
После завершения, зайдите в консоль ВМ и с помощью команды setup задайте IP адрес на интерфейсе e0b (192.168.2.252). Остальные настройки можете задать по аналогии с ontap01. Не забудьте перезагрузиться (reboot).
Добавьте лицензии с помощью license add.
Создайте новый том, который будет использоваться для хранения реплицированных данных с основного хранилища, а также группу инициаторов, в которой будет находиться резервный сервер виртуализации на втором сайте (esx02). Также запустите службу iSCSI.
vol create vol1 -s none aggr0 10g
snap sched vol1 0 0 0
snap reserve vol1 0
iscsi start
igroup create -i -t vmware VMWARE_SERVERS iqn.2012-10.local.test:esx02Учтите, что для корректной работы репликации, том на целевом хранилище должен быть такого же размера или больше, чем том на исходном хранилище. Проверить размер тома можно с помощью команды:
vol size <имя_тома>Включите репликацию на целевом хранилище:
options.snapmirror.enable onТеперь вам потребуется отредактировать файл snapmirror.conf (vol/vol0/etc/snapmirror.conf), содержащий информацию о настройках репликации. В данном файле описывается перечень реплицируемых томов, тип репликции (синхронная, асинхронная), расписание репликации (для асинхронной репликации), максимальная скорость репликации, использование сжатия, интерфейсы, по которым передаются данные и многое другое.
Формат конфигурации выглядит следующим образом:
source destination arguments schedule, где source - исходная пара хранилище:том, например (ontap01:vol1);
destination- целевая пара пара хранилище:том, например (ontap02:vol1);
arguments - дополнительные аргументы, такие как ограничение максимальной скорости передачи данных, использование сжатия и т.п. Если дополнительные аргументы не указывается, то ставится прочерк "-".
schedule- расписание репликации (для асинхронной репликации), либо параметр "sync" (для синхронной репликации).
Например, для синхронной репликации vol1 с хранилища ontap01 на хранилище ontap02, конфигурация будет выглядеть следующим образом:
ontap01:vol1 ontap02:vol1 - syncОднако, по умолчанию, передача данных будет выполняться по IP адресам, которые хранилища получили, разрешив имена ontap01 и ontap02, т.е. 192.168.1.251 и 192.168.1.252. Для использования второй пары IP адресов (192.168.2.251 и 192.168.2.252) требуется добавить в файл строку следующего формата.
name = mode(source_ip_addr1, dest_ip_addr1)(source_ip_addr2, dest_ip_addr2)где, name - имя исходного хранилища, например ontap01;
mode - режим использования пар IP адресов: failover (использование одной пары в качестве основной, а второй в качестве резервной), или multi (использование обоих пар одновременно с балансировкой нагрузки);
source_ip_addrN - IP адрес интерфейса исходного хранилища;
dest_ip_addrN - IP адрес интерфейса целевого хранилища.
Например:
ontap01=failover(192.168.2.251, 192.168.2.252)(192.168.1.251, 192.168.1.252)задает конфигурацию, при которой пара IP адресов из 192.168.2.0 подсети будет использоваться для передачи данных репликации, а пара IP адресов из 192.168.1.0 подсети будет использоваться как резервная на случай сбоя первой пары.
Таким образом, файл конфигурации snapmirror.conf будет выглядеть следующим образом:
ontap01=failover(192.168.2.251, 192.168.2.252)(192.168.1.251, 192.168.1.252)
ontap01:vol1 ontap02:vol1 - syncКак отредактировать файл snapmirror.conf? Есть несколько вариантов.
Во-первых, подключить корневой том (vol0) по протоколу NFS, как было описано в предыдущей статье, и использовать текстовый редактор, поддерживающий переносы в стиле *nix, например, Notepad++.
Во-вторых, с помощью команды wrfile.
wrfile <путь_к_файлу>Например,
wrfile /vol/vol0/etc/snapmirror.confКоманда позволит вам отредактировать указанный файл прямо из консоли. После окончания редактирования файла нажмите CTRL + c. Учтите, что команда полностью перезаписывает файл.
Если вам требуется добавить строку в существующий файл, используйте команду:
wrfile -a <путь_к_файлу> <добавляемая_строка>Прочитать данные из существующего файла можно с помощью команды:
rdfile /vol/vol0/etc/snapmirror.conf
Запуск и проверка репликации
После завершения настроек запустите репликацию с целевого хранилища. Перед запуском репликации запретите доступ к тому, используя команду:vol restrict <имя_тома>Например:
vol restrict vol1Запуск репликации осуществляется командой:
snapmirror initialize -S <source> <destination>, где: <source> - исходная пара хранилище:том, например (ontap01:vol1);
<destination>- целевая пара пара хранилище:том, например (ontap02:vol1)
Для запуска репликации тома vol1 с хранилища ontap01 на хранилище ontap02 выполните:
snapmirror initialize -S ontap01:vol1 ontap02:vol1Для проверки работы репликации используйте команду:
snapmirror statusСразу после запуска репликации начнется передача данных с исходного тома на целевой.
После того, как все данные будут переданы, репликация на короткое время перейдет в состояние idle, а затем in-sync, означающее, что синхронная репликация работает.
Тестирование с остановкой репликации/плановый перенос
Данный вариант может применяться для проверки корректности настроек репликации и тестового восстановления инфраструктуры в резервном сайте.Для начала скопируйте на LUN в основном сайте какую-либо тестовую ВМ или файлы, после чего остановите репликацию, введя команду на целевом хранилище:
snapmirror quiesce <имя_тома>Например:
snapmirror quiesce vol1Разорвите пару:
snapmirror break <destination><destination> - целевая пара пара хранилище:том.
Например:
snapmirror break ontap02:vol1После разрыва пары реплицированный LUN на целевом хранилище станет доступен для чтения/записи.
Презентуйте реплицированный LUN серверу ESXi во втором сайте:
lun map /vol/vol1/lun0 VMWARE_SERVERS 0На сервере ESXi подключитесь к целевому хранилищу и выполните сканирование для обнаружения новых томов.
ESXi автоматически не монтирует реплицированные datastore'ы. Поэтому требуется смонтировать хранилище вручную. Для этого выберите Configuration -> Storage -> Add Storage. Из списка дисков выберите реплицированный LUN. Для монтирования с сохранением файловой системы и всех данных выберите один из двух вариантов: Keep the existing signature или Assign a new signature.
Для реплицированного хранилища будет сгенерировано новое имя.
Теперь вы можете зайти на реплицированный Datastore, зарегистрировать и запустить ВМ для проверки.
После завершения тестирования для возобновления репликации разрегистрируйте тестовую ВМ, отключите реплицированный том и выполните ресинхронизацию на целевом хранилище с помощью команды:
snapmirror resync <имя_тома>Например:
snapmirror resync vol1На вопрос системы, хотите ли вы начать репликацию с последнего снапшота, введите: yes.
Через некоторое время все изменения будут синхронизированы и пара перейдет в состояние in-sync.
Схожим образом можно осуществить запланированный перенос инфраструктуры ВМ из основного сайте в резервный. Алгоритм переноса выглядит следующим образом:
- Выключите все ВМ на реплицируемом хранилище в основном сайте.
- Разрегистрируйте все ВМ и отмонтируйте хранилище.
- Дождитесь, пока завершится репликация (в случае использования асинхронной репликации).
- Остановите репликацию (snapmirror quiesce) и разорвите пару (snapmirror break) из консоли на целевом хранилище.
- Презентуйте реплицированный LUN серверу виртуализации в резервном сайте, используя команду lun map (если это не было сделано ранее).
- Подключите и выполните обнаружение новый LUN на сервере ESXi (если это не было сделано ранее).
- Смонтируйте хранилище, назначив им новый идентификатор.
- Переименуйте хранилище, вернув ему старое именя.
- Зарегистрируйте и запустите все ВМ с реплицированного хранилища.
- Если вы не планируете больше выполнять репликацию с основного хранилища на резервное, отключите пару, используя команду:
snapmirror release <имя тома> <destination>, например: snapmirror release vol1 ontap02:vol1 - Также удалите или закомментируйте конфигурацию из файла snapmirror.conf.
Тестирование без остановки репликации
В качестве альтернативного варианта тестирования репликации существует возможность создания на основе реплицированного тома flexclone том, доступный на чтение/запись, с последующим монтированием LUN'а с этого тома и проверкой работы репликации.Создать flexclone том на целевом хранилище можно следующей командой:
vol clone create <vol-name> [-s none | file | volume] [-f] -b <parent_flexvol> [<parent_snapshot>], где <vol-name> - имя для нового тома;
[-s none | file | volume]- резервирование пространства под создаваемый том;
-b <parent_flexvol>- имя тома, из которого будет создан клон;
[<parent_snapshot>]- снапшот тома, из которого будет создан клон.
Например:
vol clone create vol2 -s none -b vol1 ontap02(2147483976)_vol1.308создаст flexclone том с именем vol2 из снапшота реплицированного тома vol1.
Посмотреть список доступный снапшотов для тома можно с помощью команды:
snap listПосле создания flexclone тома, LUN на нем будет в состоянии offline.
Для того, чтобы иметь возможность смонтировать LUN, переведите его в режим online, выполнив команду:
lun online <путь_к_lun>Например:
lun online /vol/vol2/lun0После этого, вы сможете смонтировать LUN с помощью команды lun map.
После проверки репликации, отключите flexclone том, используя команду:
vol offline <имя_тома>Например:
vol offline vol2А затем удалите flexclone том, используя команду:
vol destroy <имя_тома>Например:
vol destroy vol2
Аварийно переключение на резервное хранилище
Итак, предположим, что настал тот неприятный момент, когда первый сайт лежит в руинах и основное хранилище приказало долго жить. Какие шаги следует предпринять для восстановления инфраструктуры во втором сайте?План такой:
Смиритесь с потерей, поплачьте, если это поможет.- Остановите репликацию (snapmirror quiesce) и разорвите пару (snapmirror break) из консоли на целевом хранилище.
- Презентуйте реплицированный LUN серверу виртуализации в резервном сайте, используя команду lun map (если это не было сделано ранее).
- Подключите и выполните обнаружение нового LUN'а на сервере ESXi (если это не было сделано ранее).
- Смонтируйте хранилище, назначив ему новый идентификатор.
- Переименуйте хранилище, вернув ему старое имя.
- Зарегистрируйте и запустите все ВМ с реплицированного хранилища.
- Если хранилище на первом сайте полностью отказало, и вы не планируете больше выполнять репликацию с основного хранилища на резервное, отключите пару, используя команду:
snapmirror release <имя тома> <destination>, например: snapmirror release vol1 ontap02:vol1 - Также удалите или закомментируйте конфигурацию из файла snapmirror.conf.
Настройка возможности репликации в обратном направлении
Предположим, что после планового переноса или выполнения аварийного переключения на резервное хранилище вы восстановили хранилище в основном сайте и теперь хотите, чтобы репликация осуществлялась в обратном направлении, т.е. с резервного хранилища на основное.Репликация в обратную сторону настраивается аналогичным образом.
На хранилище в резервном сайте (ontap02) добавьте IP адреса хранилища основного сайта:
options snapmirror.access host=192.168.1.251,192.168.2.251На хранилище в основном сайте (ontap01) отредактируйте файл snapmirror.conf:
ontap02=failover(192.168.2.252, 192.168.2.251)(192.168.1.252, 192.168.1.251)
ontap02:vol1 ontap01:vol1 - syncНа хранилище в основном сайте выполните команды:
vol restrict vol1
snapmirror initialize -S ontap02:vol1 ontap01:vol1Проверьте статус репликации командой snapmirror status.
Заключение
Механизм репликации в Data ONTAP является крайне гибким и функциональным. Он позволяет реплицировать данные как в синхронном, так и в асинхронном режиме, ограничивать полосу пропускания, использовать несколько интерфейсов для репликации, тестировать план восстановления без необходимости остановки репликации, перенастраивать репликацию в обратную сторону и многое другое.Однако, далеко не всегда работа из командной строки является приемлемым вариантом. В больших инфраструктурах, насчитывающих сотни виртуальных машин, а также при необходимости уменьшения времени простоя, для автоматизации операции восстановления ВМ на резервном сайте может пригодиться такой продукт, как VMware Site Recovery Manager. VMware SRM позволяет заранее настроить процедуры тестирования, переноса или восстановления ВМ в резервном сайте, избавив администратора от необходимости работы с консолью, ограничившись лишь несколькими щелчками мыши в интерфейсе vSphere Client. Более подробно о SRM вы можете прочитать тут.
0 коммент.:
Отправить комментарий