Компания IBM
Опубликован: 01.02.2008 | Доступ: свободный | Студентов: 539 / 20 | Оценка: 4.60 / 4.40 | Длительность: 43:55:00
Специальности: Разработчик аппаратуры

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

< Лекция 16 || Лекция 17: 1234 || Лекция 18 >
Аннотация: Эта лекция содержит сценарий аварийного восстановления на основе HACMP/ XD HAGEO. Мы представляем подробное описание конфигурирования среды HAGEO. Данная лекция охватывает следующие темы: описание сценария, планирование конфигурации HAGEO, установка и конфигурирование HACMP/XD HAGEO, аспекты перемещения при сбое сайта и возврата после восстановления сайта

Описание сценария и планирование

В нашем сценарии используется три узла на двух сайтах: Boston и Munchen. На рис. 17.1 подробно изображено расположение узлов и путь для связи между двумя сайтами. Внешний клиент способен осуществлять доступ к открытой сети на каждом сайте.

Сценарий HAGEO

увеличить изображение
Рис. 17.1. Сценарий HAGEO

Мы используем узлы thor и odin в конфигурации со взаимным перехватом на сайте Boston и узел frigg в качестве дежурного узла на сайте Munchen. Каждый узел использует два интерфейса Ethernet для репликации данных между сайтами.

Две географические сети обеспечивают высокую доступность и балансировку нагрузки для механизма репликации. Последовательное подключение RS232 используется в качестве сетей пульса, отличных от IP, между сайтами. Имеется две группы ресурсов, построенные вокруг приложений APP01 и APP02, выполняющихся поверх устройств GeoMirror.

Планирование конфигурации сети

Мы определили следующие сети HACMP вместе с их подсетями:

  • Открытая сеть на сайте Boston для доступа клиентов к приложениям APP01 и APP02: 172.1.1.0/24. Мы реализовали одну подсеть для локальной сети сайта Boston, так как у нас используется мониторинг пульса через синонимы для этой сети. Наша подсеть пульса – 172.16.100.0/24. На сайте Munchen нет сети HACMP для клиентского доступа, так как к этой сети подключен один узел с одним интерфейсом Ethernet. Подсеть, используемая для этой сети, – 10.1.1.0/24.
  • Географические сети репликации:
    • geo1: 192.168.101.0/24 (сайт Boston) и 10.1.101.0/24 (сайт Munchen);
    • geo2: 192.168.102.0/24 (сайт Boston) и 10.1.102.0/24 (сайт Munchen).
  • Сеть пульса через диски на сайте Boston, используемая в качестве сети пульса, отличной от IP, для связи между узлами odin и thor.
  • Вторая географическая сеть пульса последовательного типа RS232 между узлами odin (Boston) и frigg (Munchen).

Табл. 17.1 отображает конфигурацию IP-адресов узлов в кластере.

Таблица 17.1. Конфигурация интерфейсов узлов
Имя хоста Имя интерфейса IP-адрес/маска сети Интерфейс AIX Назначение
thor thor_boot1 172.1.1.73/24 en0 Загрузочный
thor_boot2 172.1.1.75/24 en1 Загрузочный
thor 192.168.100.73/24 Неприменимо Постоянный
thor_svc 192.168.100.75/24 Неприменимо Сервисный
thor_geo1 192.168.101.73/24 en2 Geo_primary
thor_geo2 192.168.102.73/24 en3 Geo_primary
odin odin_boot1 172.1.1.74/24 en0 Загрузочный
odin_boot2 172.1.1.77/24 en1 Загрузочный
odin 192.168.100.74/24 Неприменимо Постоянный
odin_svc 192.168.100.77/24 Неприменимо Сервисный
odin_geo1 192.168.101.74/24 en2 Geo_primary
odin_geo2 192.168.102.74/24 en3 Geo_primary
frigg frigg_geo1 10.1.101.192/24 en0 Geo_primary
frigg_geo2 10.1.102.192/24 en2 Geo_primary
frigg 10.1.1.192/24 en1 Загрузочный

Мы применяем одну подсеть для локальной сети сайта Boston, так как у нас используется мониторинг пульса посредством синонимов.

Планирование конфигурации логических томов

Определение устройства Geo-Mirror требует создания логических томов с одинаковыми именами на обоих сайтах. В реплицируемой группе ресурсов HACMP используется имя группы томов, содержащее устройства GeoMirror; оно также должно быть одинаковым на обоих сайтах.

Помимо логического тома, которому оно сопоставляется, каждое устройство GeoMirror использует логический том для карты состояния (state map logical volume) для регистрации несинхронизированных данных локальных и удаленных хостов. При создании state map logical volume необходимо учитывать размер логического тома, с которым он связан, используя следующую формулу:

размер statemap = макс. размер LV/(размер региона x 2).

Максимальный размер логического тома представляет приблизительную оценку максимального объема логического тома. Размер региона представляет размер блока данных на логическом томе, отображенного 4-битовой структурой данных на statemap logical volume. По умолчанию размер региона составляет 32768 байт (32 Кб).

Например, мы используем ulv11 с максимальным размером 10 Гб (160 физических разделов по 64 Мб). Действительный размер statemap составляет

10*1024*1024 Кб/(32 Кб x 2) = 160 Мб.

Размер statemap logical volume следует округлить в большую сторону до получения числа, кратного размеру физического раздела, так что в действительности для логического тома выделяется 192 Мб (три физических раздела). Табл. 17.2 представляет конфигурацию логических томов, используемых нами в конфигурации HAGEO.

Таблица 17.2. Логические тома на основном и дополнительном сайтах
Логический том Группа томов Размер (PP = 128 Мб) Сайты
ulv11 vg01 160 Boston, Munchen
ulv11_sm vg01 3 Boston, Munchen
ulv11_log vg01 1 Boston, Munchen
ulv11_log_sm vg01 1 Boston, Munchen
ulv21 vg02 160 Boston, Munchen
ulv21_sm vg02 3 Boston, Munchen
ulv21_log vg02 1 Boston, Munchen
ulv21_log_sm vg02 1 Boston, Munchen

Для каждого логического тома определен statemap logical volume. Имя и размер логического тома должны быть одинаковы на обоих сайтах.

Примечание. В целях повышения производительности мы рекомендуем размещать statemaps и логические тома данных на разных физических томах.

Определение GMD

В своей конфигурации мы определили четыре GMD, соответствующие двум файловым системам. APP01 и APP02 представляют собой два обычных приложения, использующих данные в файловых системах /app01 и /app02. Каждый логический том имеет соответствующий statemap. Табл. 17.3 представляет конфигурацию устройств GeoMirror.

Таблица 17.3. Определение GMD
Имя GMD Младший номер Том statemap Логический том Режим устройства Файловая система
ulv11_gmd 10 ulv11_sm ulv11 async /app01
ulv11_log_gmd 11 ulv11_log_sm ulv11_log async Неприменимо
ulv21_gmd 20 ulv21_sm ulv21 async /app02
ulv21_log_gmd 21 ulv21_log_sm ulv21_log async Неприменимо
< Лекция 16 || Лекция 17: 1234 || Лекция 18 >