Лекция 17: Сценарий аварийного восстановления в HAGEO

Локальное перемещение при сбое на сайте Boston

При отказе одного из узлов на сайте Boston второй узел получает свои ресурсы, как в случае обычного перемещения при сбое. Основной экземпляр реплицируемой группы ресурсов повторно активируется на работающем узле ( рис. 17.2). Устройства GeoMirror перезапускаются во время процесса восстановления, после чего репликация данных между сайтами возобновляется.

увеличить изображение
Рис. 17.2. Перемещение ресурсов при отказе узла на основном сайте

Мы протестировали локальное перемещение при сбое на сайте 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

Перемещение при сбое сайта и возврат после восстановления сайта

В случае аварии на основном сайте оба узла с основного сайта становятся недоступными. Службы кластера на удаленном узле проверяют доступность узлов на основном сайте с использованием всех сетей Geo_Primary и Geo_Secondary. В случае использования системы DBFS (Dial Back Fail Safe) удаленный сайт вызывает основной сайт, чтобы проверить, работает ли какой-либо узел на основном сайте. Если с основного сайта нет ответа, дополнительный сайт перехватывает группы ресурсов. Рис. 17.3 показывает перемещение групп ресурсов после аварии на основном сайте.

увеличить изображение
Рис. 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).

увеличить изображение
Рис. 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

Мы используем в своем сценарии политику межсайтового управления Prefer Primary Site (Предпочтительное использование основного сайта). После выполнения синхронизации происходит повторное получение ресурсов на сайте Boston, а также возврат к первоначальным значениям атрибутов устройств GeoMirror: устройства GeoMirror на сайте Boston играют основную роль, а на сайте Munchen – второстепенную. Подключаются файловые системы /app01 и /app02, и оба приложения – APP01 и APP02 – запускаются на сайте Boston.