Компания IBM
Опубликован: 01.02.2008 | Доступ: свободный | Студентов: 616 / 22 | Оценка: 4.60 / 4.40 | Длительность: 43:55:00
Специальности: Разработчик аппаратуры
Теги:
Лекция 17: Сценарий аварийного восстановления в HAGEO
Установка и конфигурирование 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Пример 17.1. Список установленных наборов файлов hageo
Дополнительные сведения об установке наборов файлов 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Пример 17.2. Создание томов и файловых систем на удаленном сайте Munchen
Примечание. Поддерживайте согласованность определений логических томов и групп
томов на обоих сайтах в целях интеграции в реплицируемые группы ресурсов
в 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]
Пример 17.3. Определение сайта BostonПоле Dominance (Доминирование) определяет, какой сайт будет остановлен в случае изоляции сайтов. Изоляция сайтов происходит при отказе всех географических сетей, когда по меньшей мере один узел на каждом сайте продолжает работать. В целях предотвращения несогласованности данных выполняется остановка недоминирующего узла.
Поле Backup Communications (Резервные связи) указывает альтернативный способ связи между сайтами. Возможные значения:
Настоятельно рекомендуется определить сеть резервной связи в кластере, так как это помогает избежать изоляции сайта в случае отказа основных географических сетей.
* 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
Пример 17.4. Определение сайта Munchen - Конфигурирование сетей 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 []
Пример 17.5. Определение открытой сети сайта BostonGMD(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]
Пример 17.6. Определение сети пульса через диски - Основные географические сети репликации: net_Geo_Primary_01 и net_Geo_
Primary_02.
HACMP использует сеть типа Geo_Primary для репликации данных с использованием HAGEO. Мы определяем сети Geo_Primary в примере 17.7.
По умолчанию сеть Geo_Primary создается с атрибутом открытой сети (public).
Существует два варианта конфигурирования этой сети:
- Использовать открытую (public) сеть. На момент добавления коммуникационных интерфейсов в сети нет определенной сервисной IP-метки. Вам необходимо определить сервисные IP-адреса, привязанные к узлу, через меню определения группы ресурсов.
- Использовать закрытую (private) сеть. В этом случае адреса, определяемые в топологии путем добавления коммуникационных интерфейсов в сеть, являются сервисными IP-метками.
В нашем сценарии мы используем закрытые сети HACMP, поэтому мы изменяем первоначальное определение сети с открытой на закрытую, как показано в примере 17.8.* Network Name [net_Geo_Primary_Q2] * Network Type Geo_Primary * Netmask [255.255.255.0] * Enable IP Address Takeover via IP Aliases No
Пример 17.7. Определение сетей Geo_PrimaryChange/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
Пример 17.8. Изменение атрибута типа сетиПримечание. Сеть Geo_Primary должна иметь сервисные IP-адреса, предназначенные для связи с устройствами GeoMirror. - Дополнительная географическая сеть – сеть RS232 между узлами odin и frigg, соединяющая сайты. Ее определение представлено в примере 17.9.
* Network Нате [net_Geo_Secoridary_01] * Nftwork Type Gep_Secondary
Пример 17.9. Определение сети Geo_Secondary
- Добавление коммуникационных интерфейсов и устройств для определенных сетей. На этом этапе выполняется заполнение ранее определенных сетей
соответствующими интерфейсами.
- Для клиентской сети на сайте Boston.
- Для основных географических сетей мы добавляем IP-адреса, как в примере 17.10.
* IP Label/Address [thor_geol] * Network Type Geo_Primary
Пример 17.10. Определение интерфейса в сети 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.11. Определение интерфейса в сети Geo_Secondary - Для последовательной сети пульса через диски (пример 17.12).
* Device Name [odin_hdiskZ] * Network Type diskhb * Network Name bostOfi_(Hsk1ib_01 * Device Path [/dev/hdisk2] * Node Name [odin]
Пример 17.12. Определение интерфейса последовательной сети пульса через диски
- Конфигурирование постоянных IP-адресов (пример 17.13): odin, thor.
Мы определили интерфейсы с именами хостов как постоянные адреса в кластере.
Узел frigg имеет один IP-интерфейс в открытой сети на сайте Munchen. Так как он
является единственным узлом на сайте Munchen, мы не определяли интерфейс с именем хоста в HACMP.
* Mode Name thor * Network Name [boston_ether_01] * Node IP Label/Address [thor]
Пример 17.13. Конфигурирование постоянных IP-адресов - Синхронизация топологии кластера, определенной на данный момент.
Определенная нами конфигурация подробно представлена в выходных данных команды 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
Пример 17.14. Выходные данные команды cltopinfo