Лекция 17: Сценарий аварийного восстановления в HAGEO
Локальное перемещение при сбое на сайте Boston
При отказе одного из узлов на сайте Boston второй узел получает свои ресурсы, как в случае обычного перемещения при сбое. Основной экземпляр реплицируемой группы ресурсов повторно активируется на работающем узле ( рис. 17.2). Устройства GeoMirror перезапускаются во время процесса восстановления, после чего репликация данных между сайтами возобновляется.
Мы протестировали локальное перемещение при сбое на сайте Boston, остановив службы кластера на узле thor с использованием опции постепенной остановки с передачей ресурсов. Группы ресурсов thor_svc_rg и app01_rg активируются на узле odin. Пример 17.21 показывает состояние групп ресурсов после перемещения при сбое.
Group Name Type State Location thorsvcrg non-concurrent OFFLINE thor ONLINE odin app01_rg r.on-concurrent OFFLINE thor ONLINE odin ONLINE SEC frigg odinsvcrg non-concurrent OFFLINE thor ONLINE odin app02_rg non-concurrent OFFLINE thor ONLINE odinПример 17.21. Состояние группы ресурсов после перемещения при сбое
Перемещение при сбое сайта и возврат после восстановления сайта
В случае аварии на основном сайте оба узла с основного сайта становятся недоступными. Службы кластера на удаленном узле проверяют доступность узлов на основном сайте с использованием всех сетей Geo_Primary и Geo_Secondary. В случае использования системы DBFS (Dial Back Fail Safe) удаленный сайт вызывает основной сайт, чтобы проверить, работает ли какой-либо узел на основном сайте. Если с основного сайта нет ответа, дополнительный сайт перехватывает группы ресурсов. Рис. 17.3 показывает перемещение групп ресурсов после аварии на основном сайте.
Обратите внимание на то, что теперь только реплицируемые группы ресурсов активны на сайте Munchen. Внешний клиент подключается к узлу frigg через локальную сеть, доступную на сайте Munchen. Так как мы используем асинхронные устройства GeoMirror, при перемещении при сбое сайта атрибуты устройств GeoMirror изменяются на атрибуты основной роли, вследствие чего устройства GeoMirror способны обрабатывать запросы записи от приложений.
Мы имитировали в своей среде перемещение при сбое сайта путем остановки служб кластера на обоих узлах, odin и thor, одновременно. После перемещения на сайт Munchen состояние реплицируемых ресурсов на узле frigg изменяется с ONLINE SECONDARY на ONLINE (пример 17.22).
При реинтеграции основного сайта в кластер сети Geo_Primary переходят в рабочее состояние, после чего запускается репликация данных в обратном направлении, с основных устройств GeoMirror на сайте Munchen на дополнительные устройства GeoMirror на сайте Boston ( рис. 17.4).
Group Name Type State Location thor_svc_rg non-concurrent OFFLINE thor OFFLINE odin app01_rg non-concurrent OFFLINE thor OFFLINE odin ONLINE frigg odin_svc_rg non-concurrent OFFLINE thor OFFLINE odin app02_rg non-concurrent OFFLINE thor OFFLINE odin ONLINE friggПример 17.22. Состояние группы ресурсов после перемещения при сбое сайта
Мы используем в своем сценарии политику межсайтового управления Prefer Primary Site (Предпочтительное использование основного сайта). После выполнения синхронизации происходит повторное получение ресурсов на сайте Boston, а также возврат к первоначальным значениям атрибутов устройств GeoMirror: устройства GeoMirror на сайте Boston играют основную роль, а на сайте Munchen – второстепенную. Подключаются файловые системы /app01 и /app02, и оба приложения – APP01 и APP02 – запускаются на сайте Boston.