Реализация мультипроцессорных кластеров высокой доступности (HACMP)

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

Разбить на страницы
Показывать лекцию целиком

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

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

(рис 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-адресов узлов в кластере.

    Конфигурация интерфейсов узлов
    Имя хоста Имя интерфейса 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.

    Логические тома на основном и дополнительном сайтах
    Логический том Группа томов Размер (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.

    Определение 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 Неприменимо

    Установка и конфигурирование HAGEO

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

  • AIX 5.3 ML02, RSCT 2.4.2;
  • HACMP 5.3;
  • HAGEO 5.3.
    •

    Установка программного обеспечения HAGEO требует наличия установленных наборов файлов HACMP.

    Были установлены следующие пакеты HACMP/XD HAGEO:

  • cluster.xd.license,
  • hageo.doc.en_US,
  • hageo.gmdsizing,
  • hageo.man.en_US,
  • hageo.manage,
  • hageo.message,
  • hageo.mirror.
    •

    Пример 17.1 содержит список наборов файлов hageo, использовавшихся в нашей конфигурации.

    Flleset	Level State Type Description (Uninstaller)
hageo.doc.enjJS.data    5.3.0.Q  С   F  HAGEO Product Manuals - U.S.
English
hageo.gmdsizirig	5.3.0.0       С	F       GMD Sizing Demonstration Tool
hageo.man.en_US.message.data
5.3.0.0      С        F      HAGEO Geowessage Mar Pages -U.S. English hageo .man ,en_ll5 ,mi rror. data
5.3.0.0       С	F       HAGEO GeoMirror Man Pages U.S. English
liageo.manage.iitns	5.3.0.0       С	F       HAGEO GeoHanage Utilities
hageo.message-.ext	5.3.0.0        С	F        HAGED GeoMesSage Device Driver
hageo.message.utils	5.3.0.0       С        F       HAGEO GeoMessage Utilities
hageo.mirror4.ext	5.3.0.0       С	F       HAGEO GeoMirror Device Driver
hageo.mirror.utils	5.3.0.0       С	F       HAGFO GeoMirror UtiIities

    Дополнительные сведения об установке наборов файлов HAGEO см. в руководстве High Availability Cluster Multi-Processing XD (Extended Distance) for HAGEO Technology: Planning and Administration, SA22-7956.

    Конфигурирование IP-адресов адаптеров

    Мы настроили загрузочные IP-адреса на узлах в соответствии с табл. 17.1. Помимо подсетей, представленных в этой таблице, мы используем выделенную подсеть для мониторинга пульса посредством синонимов: 172.16.100.1/24.

    Сервисный адрес и адрес мониторинга пульса представляют синонимы, работающие через загрузочные IP-метки, активизируемые службами кластера. Постоянный IP-адрес представляет синоним, привязанный к узлу, который остается активным на этом узле даже после остановки служб кластера или перезагрузки системы.

    Определение логических томов

    На обоих сайтах мы создает похожие конфигурации логических томов. Предполагая, что на основном сайте логические тома и файловые системы уже определены, мы определяем логические тома на резервном сайте Munchen. В примере 17.2 мы создаем реплицируемые логические тома на узле frigg сайта Munchen. Обратите внимание на то, что используемый нами тип логического тома statemap представляет собой описательный атрибут логического тома без какой-либо функциональной роли.

    frigg:/#	mkvg -у	vgOl -f -c hdiskl
frigg:/#	varyonvg vgOl
frigg:/#	mklv -y	ulvll_log -t jfs21og vgOl 1
frigg:/#	logform	/dev/ulvll_log
logform:	destroy	/dev/rulvlllog (y)?y
frigg:/#	mklv -y	ulvll  -t jfs2 vgOl  160
frigg:/#	mkvg -y	vg02 -f -c hdisk2
frigg:/#	varyonvg vg02
frigg:/#	mklv -y	ulv21_log -t jfs21og vg02 1
frigg:/#	logform	/dev/ulv21_log
logform:	destroy	/dev/rulv21_log (y)?y
frigg:/#	mklv -y	ulv21 -t jfs2 vg02 160
friggr/#	mklv -y	ulvll_sm -t statemap vgOl 3
frigg:/#	mklv -y	ulv21_sm -t statemap vg02 3
frigg:/#	mklv -y	ulvll_log_sm -t statemap vgOl 1
friggr/#	mklv -y	ul211_log_sm -t statemap vg02 1
    Примечание. Поддерживайте согласованность определений логических томов и групп томов на обоих сайтах в целях интеграции в реплицируемые группы ресурсов в HACMP. Например, при создании группы томов с расширенным одновременным доступом vg01 на сайте Boston необходимо создать группу томов с расширенным одновременным доступом с таким же именем на сайте Munchen.

    Определение топологии HACMP

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

  • Определение имени кластера.
    Cluster name = itso
  • Конфигурирование узлов вместе с путями для связи.
    Node names: thor, odin, frigg
Communication path: thor_geo1, odin_geo1, frigg_geo1
  • Выполнение процесса обнаружения для получения информации об IPадресах и дисках со всех узлов в кластере.
  • Конфигурирование сайтов HACMP.

    Мы выполнили конфигурирование сайтов Boston и Munchen, как показано в примерах 17.3 и 17.4.

    Site Name	[BDstDn]
*	Site Nodes	odin thor
*	Dominance	[Yes]
*	Backup Communications	[syn]

    Поле Dominance (Доминирование) определяет, какой сайт будет остановлен в случае изоляции сайтов. Изоляция сайтов происходит при отказе всех географических сетей, когда по меньшей мере один узел на каждом сайте продолжает работать. В целях предотвращения несогласованности данных выполняется остановка недоминирующего узла.

    Поле Backup Communications (Резервные связи) указывает альтернативный способ связи между сайтами. Возможные значения:

  • sgn (Secondary Geographical Network);
  • dbfs (Dial Back Fail Safe);
  • none.
    •

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

    *	Site Name	[Munchen]
*	Site Nodes	frigg
*	Dominance	[No]
*	Backup Communications	[sgn]
There are 3 node(s) and 5 network(s) defined NODE frigg:
Network boston_diskhb_01 Network boston_ether_01 Network net_Geo_Primary_01
frigg_geol    10.1.101.192 Network net_Geo_Primary_02
frigg_geo2    10.1.102.192 Network net_Geo_Secondary_01
frigg_tty0    /dev/ttyO NODE odin:
Network boston_diskhb_01
odi n_hdisk2   /dev/hdi$k2 Network boston_ether_01
odin_boot2    172.1.1.77
odin_bootl    172.1.1.74 Network net_Geo_Primary_01
odin_geol     192.168.101.74 Network net_Geo_Primary_02
odin_geo2     192.168.102.74 Network net_Geo_Secondary_01
odin_ttyO     /dev/ttyO
NODE thor:
Network bostondiskhbOl
thor_hdisk2	/dev/hdisk2
Network bostonetherOl
thor_boatl	172.1.1.73
thor_boot2	172.1.1.75
Network netGeoPrimaryOl
thorgeol	192.168.101.73
Network net_Geo_Primary_02
thor_geo2	192.168.102.73
Network net_Geo_Secondary_01 No resource groups defined
  • Конфигурирование сетей HACMP. В кластере HACMP выполняется определение следующих сетей:
  • Клиентская локальная сеть для сайта Boston: boston_ether_01. Пример 17.5 содержит подробное описание сети boston_ether_01 в HACMP. Обратите внимание на то, что на этом этапе указывается сеть пульса через синонимы.
  • Локальная сеть пульса через диски для сайта Boston: boston_diskhb_01. Сети пульса через диски используются в качестве сети пульса, отличной от IP, между узлами thor и odin на сайте Boston. В примере 17.6 представлено определение мониторинга пульса через диски.
    Add a GeoMirror Device
Type or select values in entry fields.
Press  Enter AFTER making all  desired changes.
[Entry Fields]
Device Name	[ulvllgmd]
*	Minor Device Number	[10]
*	State Map Logical   Volume	[/dev/rulvllsm]
*	State Map Size  (Number of Entries)	[1024]
*	State Map Region Size	[32768]
*	Local   Logical  Volume	[/dev/rulvll]
*	Device Mode	async
*	Device Role	primary High Uater Mark	[] Sync Concurrency Rate	[]
*	Remote Node,  LV, and Statemap                   [frigg?/dev/rulvll@/dev/rulvll_sm] Remote Node,  LV, and Statemap	[]
Remote Node,  LV, and Statemap	[]
Remote Node,  LV, and Statemap	[]
Remote Node, LV, and Statemap	[]
Remote Node,  LV, and Statemap	[]
Remote Node,  LV, and Statemap	[]
Local   Peer and State Hap Device	[thor(P/dev/rulvll_sm]
Local  Peer and State Hap Device	[]
Local   Peer and State Map Device	[]
Local  Peer and State Hap Device	[]
Local   Peer and State Hap Device	[]
Local  Peer and State Hap Device	[]
    GMD(s) for HACMP to start in parallel	[1]
Network Protocol	[TCP]
Temporal Ordering Policy	[SYSTEM]
Autoset Network Parameters	[Yes]
TCP Send/Receive Space Size (KBytes)	[512]
  • Основные географические сети репликации: net_Geo_Primary_01 и net_Geo_ Primary_02. HACMP использует сеть типа Geo_Primary для репликации данных с использованием HAGEO. Мы определяем сети Geo_Primary в примере 17.7. По умолчанию сеть Geo_Primary создается с атрибутом открытой сети (public). Существует два варианта конфигурирования этой сети:
  • Использовать открытую (public) сеть. На момент добавления коммуникационных интерфейсов в сети нет определенной сервисной IP-метки. Вам необходимо определить сервисные IP-адреса, привязанные к узлу, через меню определения группы ресурсов.
  • Использовать закрытую (private) сеть. В этом случае адреса, определяемые в топологии путем добавления коммуникационных интерфейсов в сеть, являются сервисными IP-метками.
    • *	Network Name	[net_Geo_Primary_Q2]
*	Network Type	Geo_Primary
*	Netmask	[255.255.255.0]
*	Enable IP Address	Takeover via IP Aliases       No
    В нашем сценарии мы используем закрытые сети HACMP, поэтому мы изменяем первоначальное определение сети с открытой на закрытую, как показано в примере 17.8.
    Change/Show All  Resources and Attributes for a Resource Group
Type or select values in entry fields.
Press Enter AFTER making all  desired changes.
[Entry Fields]
Resource Group Name	thorsvcrg
Inter-site Management Policy	ignore
Participating Nodes from Primary Site	thor odin
Participating Nodes from Secondary Site
Startup Policy                                            Online On	Home Mode Only
Fallover Policy                                             Fallover To Next Priority Node
Fallback Policy                                             Fallback To Higher Priority Mode
Fallback Timer Policy  (empty is immediate)	[]
Service IP Labels/Addresses	[thor_svc]
Application Servers	[]
Volume Groups	[]
Use forced varyon of volume groups, if necessary	false
Automatically Import Volume Groups	false
Filesystems (empty is ALL for VGs specified)	[]
Filesystems Consistency Check	fsck
Filesystems Recovery Method	sequential
Filesystems mounted before IP configured	false
Filesystems/Directories to Export	[]
Filesystems/Directories to NFS Mount	[]
Network For NFS Mount	[]
Tape Resources	[]
Raw Disk PVIDs	[]
Primary Workload Manager Class	[]
Secondary Workload Manager Class	[]
Fl=Help	F2=Refresh	F3=Cancel	F4=List
F5=Reset	F6=Command	F7=Edit	F8=Image
F9=Shell	F10=Exit	Enter=Do
    Примечание. Сеть Geo_Primary должна иметь сервисные IP-адреса, предназначенные для связи с устройствами GeoMirror.
  • Дополнительная географическая сеть – сеть RS232 между узлами odin и frigg, соединяющая сайты. Ее определение представлено в примере 17.9.
    *	Network Нате	[net_Geo_Secoridary_01]
*	Nftwork Type	Gep_Secondary
  • Добавление коммуникационных интерфейсов и устройств для определенных сетей. На этом этапе выполняется заполнение ранее определенных сетей соответствующими интерфейсами.
  • Для клиентской сети на сайте Boston.
  • Для основных географических сетей мы добавляем IP-адреса, как в примере 17.10.
    *	IP Label/Address	[thor_geol]
*	Network Type	Geo_Primary
  • Для дополнительной географической сети (пример 17.11).
    *	Device Name	fodin_ttydl
*	Netnorfc Type	Geo_Secondary
*	Network Name	itso_Geo_Secondiiry_OL
*	Device Path	[/dev/ttyO]
*	Node Name	[odin]	+
  • Для последовательной сети пульса через диски (пример 17.12).
    *	Device Name	[odin_hdiskZ]
*	Network Type	diskhb
*	Network Name	bostOfi_(Hsk1ib_01
*	Device Path	[/dev/hdisk2]
*	Node Name	[odin]
  • Конфигурирование постоянных IP-адресов (пример 17.13): odin, thor. Мы определили интерфейсы с именами хостов как постоянные адреса в кластере. Узел frigg имеет один IP-интерфейс в открытой сети на сайте Munchen. Так как он является единственным узлом на сайте Munchen, мы не определяли интерфейс с именем хоста в HACMP.
    *	Mode Name	thor
*	Network Name	[boston_ether_01]
*	Node IP Label/Address	[thor]
  • Синхронизация топологии кластера, определенной на данный момент. Определенная нами конфигурация подробно представлена в выходных данных команды cltopinfo в примере 17.14.
    Cluster Name: itso
Cluster Connection Authentication Mode: Standard
Cluster Message Authentication Mode: None
Cluster Message Encryption: None
Use Persistent Labels for Communication: No
There are 3 node(s) and 5 network(s) defined
NODE frigg:
Network bostondiskhbOl Network boston_ether_01 Network net_Geo_Primary_01
frigg_geol    10.1.101.192 Network net_Geo_Primary_02
frigg_geo2    10.1.102.192 Network net_Geo_Secondary_01
frigg_ttyO    /dev/ttyO NODE odin:
Network boston_diskhb_01
odin_hdisk2   /dev/hdisk2 Network boston_ether_01
odin_boot2    172.1.1.77 odin_bootl    172.1.1.74 Network net_Geo_Primary_01
odin_geol     192.168.101.74 Network net_Geo_Primary_02
odin_geo2     192.168.102.74 Network net_Geo_Secondary_01
odin_ttyO     /dev/ttyO
NODE thor:
Network boston_diskhb_01
thor_hdisk2   /dev/hdisk2
Network hoston_ettier_01
ttiorjrootl	172,1*1.73
thor~boot2	172. 1.1.75
Network inet_Geo_Pri(iiary_Ql
thor_geol	192.116.101.73
Network net_Geo_Pr1iiHry_02
thor_geo2	 192.16B.102.73
Network net_Geo_Secondary_01 No resource groups defined

    • Определение устройств GeoMirror

  • Создание всех устройств GeoMirror. Используя smitty hageo -> Configure GeoMirror Devices (Конфигурирование устройств GeoMirror) -> Configure a GeoMirror Device (Конфигурирование устройства GeoMirror) -> Add a GeoMirror Device (Добавление устройства GeoMirror). В примере 17.15 мы определяем устройство ulv11gmd, соответствующее логическому тому ulv11, и определяем логический том ulv11_sm в качестве statemap device.
    *	Network Name	[boston_ether_01]
*	Network Type	ether
*	Netmask	[255.255.256.0]
*	Enable IP Address Takeover via   IP Aliases	fYes]
IP Address Offset for Heartbeats over IP Aliases [172. 16,100.1] Press Enter AFTER making all   desired Chan pes.
[Entry Fields]
Device Name	[ulvllgimi]
*	Minor Device Number	[10]
*	state Map Logical Volume	[7dev/ruivii_sm]
*	State Map Size (Number of Entries)	[1024]
*	State Map Region Size	[32768]
*	Local  Logical Volume	[/dev/rulvll]
*	Device Mode	async
*	Device Role	primary High water Hark	[] Sync Concurrency Rate	[]
*	Remote Node, LV, and St a tenia p                  [frigg^/"dev/rulvll^/dev/rijlvll_STii] Remote Node,  LV,  and Statemap	[]
Remote Node,   LV,   and Statemap	[]
Remote Node,  LV,  and Statemap	[]
Remote Node,  LV,  and Statemap	[]
Remote Node,  LV,  and Statemap	[]
Remote Node,   LV,   And  Statemap
Local  Peer and state Map Device	[thorGVdev/>utvH_3m]
Local  Peer and State Map Device
Local  Peer and State Map Device	[]
local  Peer and state Map Device	[]
Local  Peer and State Map Device	[]
Local  Peer and State Map Device	[]
  • Синхронизация определения GMD между узлами. Используем smitty hageo -> Configure GeoMirror Devices (Конфигурирование устройств GeoMirror) -> Synchronize GeoMirror Devices (Синхронизация устройств GeoMirror).
  • Настройка свойств GeoMirror. Используем smitty hageo -> Configure GeoMirror Devices (Конфигурирование устройств GeoMirror) -> Configure Global GeoMirror Properties (Настройка глобальных свойств GeoMirror). Мы используем в своем сценарии следующие параметры (пример 17.16):
    GMD(s) for HACMP to start in parallel	[1]
Network Protocol	[TCP]
Temporal Ordering Policy	[SYSTEM]
Autoset Network Parameters	[Yes]
TCP Send/Receive Space Size (KBytes)	[512]
  • Синхронизация свойств GeoMirror. Используем smitty hageo -> Configure GeoMirror Devices (Конфигурирование устройств GeoMirror) -> Synchronize Global GeoMirror Properties (Синхронизация глобальных свойств GeoMirror).
  • Верификация определения GMD. Используем утилиты geo_verify или меню smitty hageo -> Verify HAGEO configuration (Верификация конфигурации HAGEO).
  • На каждом узле кластера связываем файловые системы /app01 и /app02 с устройствами GeoMirror. Редактируем /etc/filesystems и заменяем логический том файловой системы и логический том журнала устройствами GMD, как показано в примере 17.17.
    /appOl:
dev	= /dev/ulvll_gmd
vfs	= jfs2
log	= /dev/ulvll_]og_gmd
mount	= false
check	= false
account	= false
/app02:
dev	= /dev/ulv21_gmd
vfs	= jfs2
log	= /dev/ul v21_log_gmd
mount	= false
check	= false
options	= rw
account	= false
  • Тестирование созданных GMD и файловых систем.
  • Загрузка расширения ядра Geo на узлах:
    /usr/sbin/hageo/krpc/cfgkrpc -ci
  • Конфигурирование устройств GMD. Активизируем группы томов на узлах и конфигурируем устройства GeoMirror с использованием команды cfggmd:
    /usr/lib/methods/cfggmd -l <gmd_name>
  • Запуск устройств GMD. На каждом узле основного сайта перед запуском gmd следует пометить устройство GeoMirror как отключенное на удаленном узле, используя команду gmddown. В нашем сценарии мы используем узел thor на основном сайте и помечаем устройство ulv11_gmd как отключенное на узле frigg. На узле thor:
    /usr/lib/methods/gmddown -l ulv11_gmd frigg
    Запускаем устройства GMD на локальном узле:
    /usr/lib/methods/startgmd -l ulv11_gmd
    На удаленном узле помечаем соответствующий локальный узел thor как отключенный и запускаем устройства GeoMirror. В нашем примере ulv11_gmd активируется на узле thor. На узле frigg мы помечаем GMD как отключенное для узла odin и запускаем устройство:
    /usr/lib/methods/gmddown -l ulv11_gmd odin
/usr/lib/methods/startgmd -l ulv11_gmd
  • Подключение файловых систем на основном узле.
  • Для освобождения устройств GeoMirror необходимо отключить файловые системы, затем остановить устройства GeoMirror на основном и дополнительном сайтах, используя на каждом сайте такую последовательность команд: останавливаем устройство GeoMirror:
    stopgmd -l <gmd_name>
    отменяем конфигурирование GMD:
    ucfggmd -l <gmd_name>
    выгружаем расширение ядра:
    /usr/sbin/hageo/krpc/cfgkrpc -u
    •  Примечание. Перед запуском устройства GeoMirror мы помечаем это устройство как отключенное на узлах, на которых оно сконфигурировано, но не запущено. Это позволяет предотвратить тайм-аут команды startgmd при связи с удаленным узлом.

    Определение групп ресурсов HACMP/XD

    Мы создали четыре группы ресурсов:

  • Две реплицируемые группы ресурсов, содержащие группы томов, файловые системы и GMD, соответствующие приложениям APP01 и APP02, обычно работающие на сайте Boston, на узлах thor и odin соответственно. Они активизируются на обоих сайтах одновременно: основной экземпляр активируется на сайте Boston, а дополнительный экземпляр – на сайте Munchen.
  • Две группы ресурсов, содержащие сервисные IP-метки (odin_svc и thor_svc), доступны только на сайте Boston.
    •

    Определение групп ресурсов

    При конфигурировании групп ресурсов необходимо учитывать следующие аспекты:

  • Нельзя смешивать ресурсы, зависящие от сайта, и межсайтовые ресурсы в одной группе ресурсов. В нашем сценарии сервисные IP-метки odin_svc и thor_svc доступны только на сайте Boston, поэтому их нельзя включить в одну группу ресурсов с устройствами GeoMirror.
  • При определении зависимостей между двумя группами ресурсов убедитесь, что вы используете одинаковые узлы для обеих групп ресурсов. Зависимость группы ресурсов с использованием смешанных реплицируемых и нереплицируемых групп ресурсов не допускается.
  • Можно учитывать порядок последовательного получения/освобождения для определения приоритета обработки групп ресурсов.
  • Определение дополнительных ресурсов.
  • Сервисные IP-адреса для локальной сети на сайте Boston: odin_svc, thor_svc.
  • Конфигурирование серверов приложений: app01_srv, app02_srv.
    •
  • Определение групп ресурсов. Выполняется определение групп ресурсов, привязанных к сайту. Пример 17.18 представляет конфигурацию группы ресурсов thor_svc_rg, связанной с сервисным IP-адресом thor_svc на сайте Boston.
    Change/Show All Resources and Attributes for a Resource Group
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
Resource Group Name	thorsvcrg
Inter-site Management Policy	ignore
Participating Nodes from Primary Site	thor odin
Participating Nodes from Secondary Site
Startup Policy	Online On Home Node Only
Fallover Policy	Fallover To Next Priority Node
Fallback Policy	Fallback To Higher Priority Node
Fallback Timer Policy (empty is immediate)	[]
Service IP Labels/Addresses	[thor_svc]
Application Servers	[]
Volume Groups	[]
Use forced varyon of volume groups, if necessary	false
Automatically Import Volume Groups	false
Filesystems (empty is ALL for VGs specified)	[]
Filesystems Consistency Check	fsck
Filesystems Recovery Method	sequential
Filesystems mounted before IP configured	false
Filesystems/Directories to Export	[]
Filesystems/Directories to NFS Mount	[]
Network For NFS Mount	[]
Tape Resources	[]
Raw Disk PVIDs	[]
Fast Connect Services	[]
Communication Links	[]
Primary Workload Manager Class	[]
Secondary Workload Manager Class	[]
Miscel laneous Data	[]
GeoMirror Devices	[]
Fl=Help                           F2=Refresh	F3=Cancel                          F4=List
F5=Reset                          F6=Command	F7=Edi t                              F8=Image
F9=Shell                           FlOExit	Enter=Do
    Затем мы определяем ресурсы GeoMirror. Пример 17.19 представляет определение группы ресурсов для приложения APP01. Здесь мы добавляем дисковые ресурсы, которые включают устройства GeoMirror, определенные между сайтами.
    Change/Show All   Resources and Attributes for a Resource Group
Type or select values in entry fields.
Press Enter AFTER making all  desired changes.
[Entry Fields]
Resource Group Name	app01_rg
Inter-site Management Policy	Prefer Primary Site
Participating Nodes from Primary Site	odin thor
Participating Nodes from Secondary Site	frigg
Startup Policy	Online On Home Node Only
Fallover Policy	Fallover To Next Priority Node In The List
Fallback Policy	Fallback To Higher Priority Node In The List
Fallback Timer Policy	(empty is immediate)                 []
Service IP Labels/Addresses	[odin_svc]
Application Servers	[app01_srv]
Volume Groups	[vgOl]
Use forced varyon of volume groups, if necessary       false
Automatically Import Volume Groups	false
Filesystems  (empty is ALL for VGs specified)	[/appOl]
Filesystems Consistency Check	fsck
Filesystems Recovery Method	sequential
Filesystems mounted before IP configured	false
Filesystems/Directories to Export	[]
Filesystems/Directories to NFS Mount	[]
Network For NFS Mount	[]
Tape Resources	[]
Raw Disk PVIDs	[]
Fast Connect Services	[]
Communication Links	[]
Primary Workload Manager	Class                                      []
Secondary Workload Manager Class	[]
Miscellaneous Data	[]
GeoMirror Devices	[ulvll_loggmd ulvllgmd]
Fl=Help	F2=Refresh                                  F3=Cancel        F4=List
F5=Reset	F6=Coimiard                                  F7=Edit           F8=Image
  • Синхронизация кластера HACMP. Используем smitty hacmp -> Extended Configuration (Расширенное конфигурирование) -> Extended Verification and Synchronization (Расширенная верификация и синхронизация).
  • Запуск служб кластера. Используем smitty clstart для запуска служб кластера на узле. После запуска служб кластера каждый узел на основном сайте Boston получает группы ресурсов в соответствии с заданным приоритетом. Сервисные IPадреса thor_svc и odin_svc активируются на узлах thor и odin соответственно. Основной экземпляр групп ресурсов app01_rg и app02_rg находится на сайте Boston, где подключены файловые системы, а дополнительный экземпляр – на сайте Munchen. Устройства GeoMirror активируются на обоих сайтах при запуске служб кластера, что вызывает копирование данных, записываемых на основном сайте Boston, через сети Geo_Primary на узел frigg сайта Munchen. Пример 17.20 отображает состояние группы ресурсов, когда службы кластера запущены на всех узлах.
    Group Name   Type       State    Location
thorsvcrg    non-concurrent ONLINE	thor
OFFLINE	odin
appOlrg      non-concurrent ONLINE	thor
OFFLINE	odin
ONLINE SEC	frigg
odin_svc_rg    non-concurrent OFFLINE	thor
ONLINE	odin
app02_rg      non-concurrent OFFLINE	thor
ONLINE	odin
ONLINE SEC	frigg

    • Локальное перемещение при сбое на сайте 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.22) Возврат после восстановления сайта(рис 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.

    Страницы:

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

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

    (рис 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-адресов узлов в кластере.

    Конфигурация интерфейсов узлов
    Имя хоста Имя интерфейса 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.

    Логические тома на основном и дополнительном сайтах
    Логический том Группа томов Размер (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.

    Определение 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 Неприменимо

    Установка и конфигурирование HAGEO

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

  • AIX 5.3 ML02, RSCT 2.4.2;
  • HACMP 5.3;
  • HAGEO 5.3.
    •

    Установка программного обеспечения HAGEO требует наличия установленных наборов файлов HACMP.

    Были установлены следующие пакеты HACMP/XD HAGEO:

  • cluster.xd.license,
  • hageo.doc.en_US,
  • hageo.gmdsizing,
  • hageo.man.en_US,
  • hageo.manage,
  • hageo.message,
  • hageo.mirror.
    •

    Пример 17.1 содержит список наборов файлов hageo, использовавшихся в нашей конфигурации.

    Flleset	Level State Type Description (Uninstaller)
hageo.doc.enjJS.data    5.3.0.Q  С   F  HAGEO Product Manuals - U.S.
English
hageo.gmdsizirig	5.3.0.0       С	F       GMD Sizing Demonstration Tool
hageo.man.en_US.message.data
5.3.0.0      С        F      HAGEO Geowessage Mar Pages -U.S. English hageo .man ,en_ll5 ,mi rror. data
5.3.0.0       С	F       HAGEO GeoMirror Man Pages U.S. English
liageo.manage.iitns	5.3.0.0       С	F       HAGEO GeoHanage Utilities
hageo.message-.ext	5.3.0.0        С	F        HAGED GeoMesSage Device Driver
hageo.message.utils	5.3.0.0       С        F       HAGEO GeoMessage Utilities
hageo.mirror4.ext	5.3.0.0       С	F       HAGEO GeoMirror Device Driver
hageo.mirror.utils	5.3.0.0       С	F       HAGFO GeoMirror UtiIities

    Дополнительные сведения об установке наборов файлов HAGEO см. в руководстве High Availability Cluster Multi-Processing XD (Extended Distance) for HAGEO Technology: Planning and Administration, SA22-7956.

    Конфигурирование IP-адресов адаптеров

    Мы настроили загрузочные IP-адреса на узлах в соответствии с табл. 17.1. Помимо подсетей, представленных в этой таблице, мы используем выделенную подсеть для мониторинга пульса посредством синонимов: 172.16.100.1/24.

    Сервисный адрес и адрес мониторинга пульса представляют синонимы, работающие через загрузочные IP-метки, активизируемые службами кластера. Постоянный IP-адрес представляет синоним, привязанный к узлу, который остается активным на этом узле даже после остановки служб кластера или перезагрузки системы.

    Определение логических томов

    На обоих сайтах мы создает похожие конфигурации логических томов. Предполагая, что на основном сайте логические тома и файловые системы уже определены, мы определяем логические тома на резервном сайте Munchen. В примере 17.2 мы создаем реплицируемые логические тома на узле frigg сайта Munchen. Обратите внимание на то, что используемый нами тип логического тома statemap представляет собой описательный атрибут логического тома без какой-либо функциональной роли.

    frigg:/#	mkvg -у	vgOl -f -c hdiskl
frigg:/#	varyonvg vgOl
frigg:/#	mklv -y	ulvll_log -t jfs21og vgOl 1
frigg:/#	logform	/dev/ulvll_log
logform:	destroy	/dev/rulvlllog (y)?y
frigg:/#	mklv -y	ulvll  -t jfs2 vgOl  160
frigg:/#	mkvg -y	vg02 -f -c hdisk2
frigg:/#	varyonvg vg02
frigg:/#	mklv -y	ulv21_log -t jfs21og vg02 1
frigg:/#	logform	/dev/ulv21_log
logform:	destroy	/dev/rulv21_log (y)?y
frigg:/#	mklv -y	ulv21 -t jfs2 vg02 160
friggr/#	mklv -y	ulvll_sm -t statemap vgOl 3
frigg:/#	mklv -y	ulv21_sm -t statemap vg02 3
frigg:/#	mklv -y	ulvll_log_sm -t statemap vgOl 1
friggr/#	mklv -y	ul211_log_sm -t statemap vg02 1
    Примечание. Поддерживайте согласованность определений логических томов и групп томов на обоих сайтах в целях интеграции в реплицируемые группы ресурсов в HACMP. Например, при создании группы томов с расширенным одновременным доступом vg01 на сайте Boston необходимо создать группу томов с расширенным одновременным доступом с таким же именем на сайте Munchen.

    Определение топологии HACMP

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

  • Определение имени кластера.
    Cluster name = itso
  • Конфигурирование узлов вместе с путями для связи.
    Node names: thor, odin, frigg
Communication path: thor_geo1, odin_geo1, frigg_geo1
  • Выполнение процесса обнаружения для получения информации об IPадресах и дисках со всех узлов в кластере.
  • Конфигурирование сайтов HACMP.

    Мы выполнили конфигурирование сайтов Boston и Munchen, как показано в примерах 17.3 и 17.4.

    Site Name	[BDstDn]
*	Site Nodes	odin thor
*	Dominance	[Yes]
*	Backup Communications	[syn]

    Поле Dominance (Доминирование) определяет, какой сайт будет остановлен в случае изоляции сайтов. Изоляция сайтов происходит при отказе всех географических сетей, когда по меньшей мере один узел на каждом сайте продолжает работать. В целях предотвращения несогласованности данных выполняется остановка недоминирующего узла.

    Поле Backup Communications (Резервные связи) указывает альтернативный способ связи между сайтами. Возможные значения:

  • sgn (Secondary Geographical Network);
  • dbfs (Dial Back Fail Safe);
  • none.
    •

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

    *	Site Name	[Munchen]
*	Site Nodes	frigg
*	Dominance	[No]
*	Backup Communications	[sgn]
There are 3 node(s) and 5 network(s) defined NODE frigg:
Network boston_diskhb_01 Network boston_ether_01 Network net_Geo_Primary_01
frigg_geol    10.1.101.192 Network net_Geo_Primary_02
frigg_geo2    10.1.102.192 Network net_Geo_Secondary_01
frigg_tty0    /dev/ttyO NODE odin:
Network boston_diskhb_01
odi n_hdisk2   /dev/hdi$k2 Network boston_ether_01
odin_boot2    172.1.1.77
odin_bootl    172.1.1.74 Network net_Geo_Primary_01
odin_geol     192.168.101.74 Network net_Geo_Primary_02
odin_geo2     192.168.102.74 Network net_Geo_Secondary_01
odin_ttyO     /dev/ttyO
NODE thor:
Network bostondiskhbOl
thor_hdisk2	/dev/hdisk2
Network bostonetherOl
thor_boatl	172.1.1.73
thor_boot2	172.1.1.75
Network netGeoPrimaryOl
thorgeol	192.168.101.73
Network net_Geo_Primary_02
thor_geo2	192.168.102.73
Network net_Geo_Secondary_01 No resource groups defined
  • Конфигурирование сетей HACMP. В кластере HACMP выполняется определение следующих сетей:
  • Клиентская локальная сеть для сайта Boston: boston_ether_01. Пример 17.5 содержит подробное описание сети boston_ether_01 в HACMP. Обратите внимание на то, что на этом этапе указывается сеть пульса через синонимы.
  • Локальная сеть пульса через диски для сайта Boston: boston_diskhb_01. Сети пульса через диски используются в качестве сети пульса, отличной от IP, между узлами thor и odin на сайте Boston. В примере 17.6 представлено определение мониторинга пульса через диски.
    Add a GeoMirror Device
Type or select values in entry fields.
Press  Enter AFTER making all  desired changes.
[Entry Fields]
Device Name	[ulvllgmd]
*	Minor Device Number	[10]
*	State Map Logical   Volume	[/dev/rulvllsm]
*	State Map Size  (Number of Entries)	[1024]
*	State Map Region Size	[32768]
*	Local   Logical  Volume	[/dev/rulvll]
*	Device Mode	async
*	Device Role	primary High Uater Mark	[] Sync Concurrency Rate	[]
*	Remote Node,  LV, and Statemap                   [frigg?/dev/rulvll@/dev/rulvll_sm] Remote Node,  LV, and Statemap	[]
Remote Node,  LV, and Statemap	[]
Remote Node,  LV, and Statemap	[]
Remote Node, LV, and Statemap	[]
Remote Node,  LV, and Statemap	[]
Remote Node,  LV, and Statemap	[]
Local   Peer and State Hap Device	[thor(P/dev/rulvll_sm]
Local  Peer and State Hap Device	[]
Local   Peer and State Map Device	[]
Local  Peer and State Hap Device	[]
Local   Peer and State Hap Device	[]
Local  Peer and State Hap Device	[]
    GMD(s) for HACMP to start in parallel	[1]
Network Protocol	[TCP]
Temporal Ordering Policy	[SYSTEM]
Autoset Network Parameters	[Yes]
TCP Send/Receive Space Size (KBytes)	[512]
  • Основные географические сети репликации: net_Geo_Primary_01 и net_Geo_ Primary_02. HACMP использует сеть типа Geo_Primary для репликации данных с использованием HAGEO. Мы определяем сети Geo_Primary в примере 17.7. По умолчанию сеть Geo_Primary создается с атрибутом открытой сети (public). Существует два варианта конфигурирования этой сети:
  • Использовать открытую (public) сеть. На момент добавления коммуникационных интерфейсов в сети нет определенной сервисной IP-метки. Вам необходимо определить сервисные IP-адреса, привязанные к узлу, через меню определения группы ресурсов.
  • Использовать закрытую (private) сеть. В этом случае адреса, определяемые в топологии путем добавления коммуникационных интерфейсов в сеть, являются сервисными IP-метками.
    • *	Network Name	[net_Geo_Primary_Q2]
*	Network Type	Geo_Primary
*	Netmask	[255.255.255.0]
*	Enable IP Address	Takeover via IP Aliases       No
    В нашем сценарии мы используем закрытые сети HACMP, поэтому мы изменяем первоначальное определение сети с открытой на закрытую, как показано в примере 17.8.
    Change/Show All  Resources and Attributes for a Resource Group
Type or select values in entry fields.
Press Enter AFTER making all  desired changes.
[Entry Fields]
Resource Group Name	thorsvcrg
Inter-site Management Policy	ignore
Participating Nodes from Primary Site	thor odin
Participating Nodes from Secondary Site
Startup Policy                                            Online On	Home Mode Only
Fallover Policy                                             Fallover To Next Priority Node
Fallback Policy                                             Fallback To Higher Priority Mode
Fallback Timer Policy  (empty is immediate)	[]
Service IP Labels/Addresses	[thor_svc]
Application Servers	[]
Volume Groups	[]
Use forced varyon of volume groups, if necessary	false
Automatically Import Volume Groups	false
Filesystems (empty is ALL for VGs specified)	[]
Filesystems Consistency Check	fsck
Filesystems Recovery Method	sequential
Filesystems mounted before IP configured	false
Filesystems/Directories to Export	[]
Filesystems/Directories to NFS Mount	[]
Network For NFS Mount	[]
Tape Resources	[]
Raw Disk PVIDs	[]
Primary Workload Manager Class	[]
Secondary Workload Manager Class	[]
Fl=Help	F2=Refresh	F3=Cancel	F4=List
F5=Reset	F6=Command	F7=Edit	F8=Image
F9=Shell	F10=Exit	Enter=Do
    Примечание. Сеть Geo_Primary должна иметь сервисные IP-адреса, предназначенные для связи с устройствами GeoMirror.
  • Дополнительная географическая сеть – сеть RS232 между узлами odin и frigg, соединяющая сайты. Ее определение представлено в примере 17.9.
    *	Network Нате	[net_Geo_Secoridary_01]
*	Nftwork Type	Gep_Secondary
  • Добавление коммуникационных интерфейсов и устройств для определенных сетей. На этом этапе выполняется заполнение ранее определенных сетей соответствующими интерфейсами.
  • Для клиентской сети на сайте Boston.
  • Для основных географических сетей мы добавляем IP-адреса, как в примере 17.10.
    *	IP Label/Address	[thor_geol]
*	Network Type	Geo_Primary
  • Для дополнительной географической сети (пример 17.11).
    *	Device Name	fodin_ttydl
*	Netnorfc Type	Geo_Secondary
*	Network Name	itso_Geo_Secondiiry_OL
*	Device Path	[/dev/ttyO]
*	Node Name	[odin]	+
  • Для последовательной сети пульса через диски (пример 17.12).
    *	Device Name	[odin_hdiskZ]
*	Network Type	diskhb
*	Network Name	bostOfi_(Hsk1ib_01
*	Device Path	[/dev/hdisk2]
*	Node Name	[odin]
  • Конфигурирование постоянных IP-адресов (пример 17.13): odin, thor. Мы определили интерфейсы с именами хостов как постоянные адреса в кластере. Узел frigg имеет один IP-интерфейс в открытой сети на сайте Munchen. Так как он является единственным узлом на сайте Munchen, мы не определяли интерфейс с именем хоста в HACMP.
    *	Mode Name	thor
*	Network Name	[boston_ether_01]
*	Node IP Label/Address	[thor]
  • Синхронизация топологии кластера, определенной на данный момент. Определенная нами конфигурация подробно представлена в выходных данных команды cltopinfo в примере 17.14.
    Cluster Name: itso
Cluster Connection Authentication Mode: Standard
Cluster Message Authentication Mode: None
Cluster Message Encryption: None
Use Persistent Labels for Communication: No
There are 3 node(s) and 5 network(s) defined
NODE frigg:
Network bostondiskhbOl Network boston_ether_01 Network net_Geo_Primary_01
frigg_geol    10.1.101.192 Network net_Geo_Primary_02
frigg_geo2    10.1.102.192 Network net_Geo_Secondary_01
frigg_ttyO    /dev/ttyO NODE odin:
Network boston_diskhb_01
odin_hdisk2   /dev/hdisk2 Network boston_ether_01
odin_boot2    172.1.1.77 odin_bootl    172.1.1.74 Network net_Geo_Primary_01
odin_geol     192.168.101.74 Network net_Geo_Primary_02
odin_geo2     192.168.102.74 Network net_Geo_Secondary_01
odin_ttyO     /dev/ttyO
NODE thor:
Network boston_diskhb_01
thor_hdisk2   /dev/hdisk2
Network hoston_ettier_01
ttiorjrootl	172,1*1.73
thor~boot2	172. 1.1.75
Network inet_Geo_Pri(iiary_Ql
thor_geol	192.116.101.73
Network net_Geo_Pr1iiHry_02
thor_geo2	 192.16B.102.73
Network net_Geo_Secondary_01 No resource groups defined

    • Определение устройств GeoMirror

  • Создание всех устройств GeoMirror. Используя smitty hageo -> Configure GeoMirror Devices (Конфигурирование устройств GeoMirror) -> Configure a GeoMirror Device (Конфигурирование устройства GeoMirror) -> Add a GeoMirror Device (Добавление устройства GeoMirror). В примере 17.15 мы определяем устройство ulv11gmd, соответствующее логическому тому ulv11, и определяем логический том ulv11_sm в качестве statemap device.
    *	Network Name	[boston_ether_01]
*	Network Type	ether
*	Netmask	[255.255.256.0]
*	Enable IP Address Takeover via   IP Aliases	fYes]
IP Address Offset for Heartbeats over IP Aliases [172. 16,100.1] Press Enter AFTER making all   desired Chan pes.
[Entry Fields]
Device Name	[ulvllgimi]
*	Minor Device Number	[10]
*	state Map Logical Volume	[7dev/ruivii_sm]
*	State Map Size (Number of Entries)	[1024]
*	State Map Region Size	[32768]
*	Local  Logical Volume	[/dev/rulvll]
*	Device Mode	async
*	Device Role	primary High water Hark	[] Sync Concurrency Rate	[]
*	Remote Node, LV, and St a tenia p                  [frigg^/"dev/rulvll^/dev/rijlvll_STii] Remote Node,  LV,  and Statemap	[]
Remote Node,   LV,   and Statemap	[]
Remote Node,  LV,  and Statemap	[]
Remote Node,  LV,  and Statemap	[]
Remote Node,  LV,  and Statemap	[]
Remote Node,   LV,   And  Statemap
Local  Peer and state Map Device	[thorGVdev/>utvH_3m]
Local  Peer and State Map Device
Local  Peer and State Map Device	[]
local  Peer and state Map Device	[]
Local  Peer and State Map Device	[]
Local  Peer and State Map Device	[]
  • Синхронизация определения GMD между узлами. Используем smitty hageo -> Configure GeoMirror Devices (Конфигурирование устройств GeoMirror) -> Synchronize GeoMirror Devices (Синхронизация устройств GeoMirror).
  • Настройка свойств GeoMirror. Используем smitty hageo -> Configure GeoMirror Devices (Конфигурирование устройств GeoMirror) -> Configure Global GeoMirror Properties (Настройка глобальных свойств GeoMirror). Мы используем в своем сценарии следующие параметры (пример 17.16):
    GMD(s) for HACMP to start in parallel	[1]
Network Protocol	[TCP]
Temporal Ordering Policy	[SYSTEM]
Autoset Network Parameters	[Yes]
TCP Send/Receive Space Size (KBytes)	[512]
  • Синхронизация свойств GeoMirror. Используем smitty hageo -> Configure GeoMirror Devices (Конфигурирование устройств GeoMirror) -> Synchronize Global GeoMirror Properties (Синхронизация глобальных свойств GeoMirror).
  • Верификация определения GMD. Используем утилиты geo_verify или меню smitty hageo -> Verify HAGEO configuration (Верификация конфигурации HAGEO).
  • На каждом узле кластера связываем файловые системы /app01 и /app02 с устройствами GeoMirror. Редактируем /etc/filesystems и заменяем логический том файловой системы и логический том журнала устройствами GMD, как показано в примере 17.17.
    /appOl:
dev	= /dev/ulvll_gmd
vfs	= jfs2
log	= /dev/ulvll_]og_gmd
mount	= false
check	= false
account	= false
/app02:
dev	= /dev/ulv21_gmd
vfs	= jfs2
log	= /dev/ul v21_log_gmd
mount	= false
check	= false
options	= rw
account	= false
  • Тестирование созданных GMD и файловых систем.
  • Загрузка расширения ядра Geo на узлах:
    /usr/sbin/hageo/krpc/cfgkrpc -ci
  • Конфигурирование устройств GMD. Активизируем группы томов на узлах и конфигурируем устройства GeoMirror с использованием команды cfggmd:
    /usr/lib/methods/cfggmd -l <gmd_name>
  • Запуск устройств GMD. На каждом узле основного сайта перед запуском gmd следует пометить устройство GeoMirror как отключенное на удаленном узле, используя команду gmddown. В нашем сценарии мы используем узел thor на основном сайте и помечаем устройство ulv11_gmd как отключенное на узле frigg. На узле thor:
    /usr/lib/methods/gmddown -l ulv11_gmd frigg
    Запускаем устройства GMD на локальном узле:
    /usr/lib/methods/startgmd -l ulv11_gmd
    На удаленном узле помечаем соответствующий локальный узел thor как отключенный и запускаем устройства GeoMirror. В нашем примере ulv11_gmd активируется на узле thor. На узле frigg мы помечаем GMD как отключенное для узла odin и запускаем устройство:
    /usr/lib/methods/gmddown -l ulv11_gmd odin
/usr/lib/methods/startgmd -l ulv11_gmd
  • Подключение файловых систем на основном узле.
  • Для освобождения устройств GeoMirror необходимо отключить файловые системы, затем остановить устройства GeoMirror на основном и дополнительном сайтах, используя на каждом сайте такую последовательность команд: останавливаем устройство GeoMirror:
    stopgmd -l <gmd_name>
    отменяем конфигурирование GMD:
    ucfggmd -l <gmd_name>
    выгружаем расширение ядра:
    /usr/sbin/hageo/krpc/cfgkrpc -u
    •  Примечание. Перед запуском устройства GeoMirror мы помечаем это устройство как отключенное на узлах, на которых оно сконфигурировано, но не запущено. Это позволяет предотвратить тайм-аут команды startgmd при связи с удаленным узлом.

    Определение групп ресурсов HACMP/XD

    Мы создали четыре группы ресурсов:

  • Две реплицируемые группы ресурсов, содержащие группы томов, файловые системы и GMD, соответствующие приложениям APP01 и APP02, обычно работающие на сайте Boston, на узлах thor и odin соответственно. Они активизируются на обоих сайтах одновременно: основной экземпляр активируется на сайте Boston, а дополнительный экземпляр – на сайте Munchen.
  • Две группы ресурсов, содержащие сервисные IP-метки (odin_svc и thor_svc), доступны только на сайте Boston.
    •

    Определение групп ресурсов

    При конфигурировании групп ресурсов необходимо учитывать следующие аспекты:

  • Нельзя смешивать ресурсы, зависящие от сайта, и межсайтовые ресурсы в одной группе ресурсов. В нашем сценарии сервисные IP-метки odin_svc и thor_svc доступны только на сайте Boston, поэтому их нельзя включить в одну группу ресурсов с устройствами GeoMirror.
  • При определении зависимостей между двумя группами ресурсов убедитесь, что вы используете одинаковые узлы для обеих групп ресурсов. Зависимость группы ресурсов с использованием смешанных реплицируемых и нереплицируемых групп ресурсов не допускается.
  • Можно учитывать порядок последовательного получения/освобождения для определения приоритета обработки групп ресурсов.
  • Определение дополнительных ресурсов.
  • Сервисные IP-адреса для локальной сети на сайте Boston: odin_svc, thor_svc.
  • Конфигурирование серверов приложений: app01_srv, app02_srv.
    •
  • Определение групп ресурсов. Выполняется определение групп ресурсов, привязанных к сайту. Пример 17.18 представляет конфигурацию группы ресурсов thor_svc_rg, связанной с сервисным IP-адресом thor_svc на сайте Boston.
    Change/Show All Resources and Attributes for a Resource Group
Type or select values in entry fields.
Press Enter AFTER making all desired changes.
[Entry Fields]
Resource Group Name	thorsvcrg
Inter-site Management Policy	ignore
Participating Nodes from Primary Site	thor odin
Participating Nodes from Secondary Site
Startup Policy	Online On Home Node Only
Fallover Policy	Fallover To Next Priority Node
Fallback Policy	Fallback To Higher Priority Node
Fallback Timer Policy (empty is immediate)	[]
Service IP Labels/Addresses	[thor_svc]
Application Servers	[]
Volume Groups	[]
Use forced varyon of volume groups, if necessary	false
Automatically Import Volume Groups	false
Filesystems (empty is ALL for VGs specified)	[]
Filesystems Consistency Check	fsck
Filesystems Recovery Method	sequential
Filesystems mounted before IP configured	false
Filesystems/Directories to Export	[]
Filesystems/Directories to NFS Mount	[]
Network For NFS Mount	[]
Tape Resources	[]
Raw Disk PVIDs	[]
Fast Connect Services	[]
Communication Links	[]
Primary Workload Manager Class	[]
Secondary Workload Manager Class	[]
Miscel laneous Data	[]
GeoMirror Devices	[]
Fl=Help                           F2=Refresh	F3=Cancel                          F4=List
F5=Reset                          F6=Command	F7=Edi t                              F8=Image
F9=Shell                           FlOExit	Enter=Do
    Затем мы определяем ресурсы GeoMirror. Пример 17.19 представляет определение группы ресурсов для приложения APP01. Здесь мы добавляем дисковые ресурсы, которые включают устройства GeoMirror, определенные между сайтами.
    Change/Show All   Resources and Attributes for a Resource Group
Type or select values in entry fields.
Press Enter AFTER making all  desired changes.
[Entry Fields]
Resource Group Name	app01_rg
Inter-site Management Policy	Prefer Primary Site
Participating Nodes from Primary Site	odin thor
Participating Nodes from Secondary Site	frigg
Startup Policy	Online On Home Node Only
Fallover Policy	Fallover To Next Priority Node In The List
Fallback Policy	Fallback To Higher Priority Node In The List
Fallback Timer Policy	(empty is immediate)                 []
Service IP Labels/Addresses	[odin_svc]
Application Servers	[app01_srv]
Volume Groups	[vgOl]
Use forced varyon of volume groups, if necessary       false
Automatically Import Volume Groups	false
Filesystems  (empty is ALL for VGs specified)	[/appOl]
Filesystems Consistency Check	fsck
Filesystems Recovery Method	sequential
Filesystems mounted before IP configured	false
Filesystems/Directories to Export	[]
Filesystems/Directories to NFS Mount	[]
Network For NFS Mount	[]
Tape Resources	[]
Raw Disk PVIDs	[]
Fast Connect Services	[]
Communication Links	[]
Primary Workload Manager	Class                                      []
Secondary Workload Manager Class	[]
Miscellaneous Data	[]
GeoMirror Devices	[ulvll_loggmd ulvllgmd]
Fl=Help	F2=Refresh                                  F3=Cancel        F4=List
F5=Reset	F6=Coimiard                                  F7=Edit           F8=Image
  • Синхронизация кластера HACMP. Используем smitty hacmp -> Extended Configuration (Расширенное конфигурирование) -> Extended Verification and Synchronization (Расширенная верификация и синхронизация).
  • Запуск служб кластера. Используем smitty clstart для запуска служб кластера на узле. После запуска служб кластера каждый узел на основном сайте Boston получает группы ресурсов в соответствии с заданным приоритетом. Сервисные IPадреса thor_svc и odin_svc активируются на узлах thor и odin соответственно. Основной экземпляр групп ресурсов app01_rg и app02_rg находится на сайте Boston, где подключены файловые системы, а дополнительный экземпляр – на сайте Munchen. Устройства GeoMirror активируются на обоих сайтах при запуске служб кластера, что вызывает копирование данных, записываемых на основном сайте Boston, через сети Geo_Primary на узел frigg сайта Munchen. Пример 17.20 отображает состояние группы ресурсов, когда службы кластера запущены на всех узлах.
    Group Name   Type       State    Location
thorsvcrg    non-concurrent ONLINE	thor
OFFLINE	odin
appOlrg      non-concurrent ONLINE	thor
OFFLINE	odin
ONLINE SEC	frigg
odin_svc_rg    non-concurrent OFFLINE	thor
ONLINE	odin
app02_rg      non-concurrent OFFLINE	thor
ONLINE	odin
ONLINE SEC	frigg

    • Локальное перемещение при сбое на сайте 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.22) Возврат после восстановления сайта(рис 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.

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^