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

Сетевые функции

< Лекция 13 || Лекция 14: 1234 || Лекция 15 >

Варианты размещения сервисных IP-синонимов

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

Этот атрибут сети можно использовать для настройки балансировки нагрузки сервисных IP-меток HA, учитывая, что все постоянные IP-метки уже сконфигурированы. Выбранный вариант размещения поддерживается при запуске кластера и последующих событиях кластера. Вариант размещения поддерживается до тех пор, пока в кластере доступны подходящие сетевые интерфейсы. Однако HACMP всегда поддерживает сервисные IP-метки в активном состоянии, даже при невозможности обеспечения требуемого варианта размещения.

Существует четыре различных политики размещения:

  • Без совместного размещения (Anti-collocation). Используется по умолчанию. HACMP распределяет все сервисные IP-метки по всем базовым IP-адресам с использованием выбора "наименьшей загруженности".
  • С совместным размещением (Collocation). HACMP размещает все сервисные IP-синонимы на одной сетевой интерфейсной карте (NIC).
  • Без совместного размещения и с постоянной меткой (Anti-Collocation with persistent). HACMP размещает все сервисные IP-синонимы по всем активным физическим интерфейсам, не содержащим постоянную IP-метку. HACMP размещает сервисные IP-синонимы на интерфейсе, содержащем постоянную метку, только если недоступен другой сетевой интерфейс. Если не сконфигурированы постоянные IP-метки, HACMP позволяет выбрать вариант размещения AntiCollocation with Persistent, однако выдает предупреждение и по умолчанию использует обычный вариант без совместного размещения.
  • С совместным размещением и с постоянной меткой (Collocation with persistent). Все сервисные IP-синонимы размещаются на одной сетевой карте, содержащей постоянную IP-метку. Это может быть полезно в средах с VPN и брандмауэром, где только один интерфейс имеет внешний выход и где все IP-метки (постоянные и сервисные) должны размещаться на одной интерфейсной карте. Если не были сконфигурированы постоянные IP-адреса, HACMP позволяет выбрать вариант размещения Collocation with Persistent, однако выдает предупреждение и по умолчанию использует обычный вариант с совместным размещением.

Конфигурирование политики размещения сервисных IP-адресов

Вариант размещения можно устанавливать и изменять динамически. Ниже перечислены действия по конфигурированию политики размещения этого типа.

  1. Введите smit hacmp.
  2. В SMIT выберите Extended Configuration (Расширенное конфигурирование) > Extended Resource Configuration (Расширенное конфигурирование ресурсов) > HACMP Extended Resources Configuration (Расширенное конфигурирование ресурсов HACMP) > Configure Resource Distribution Preferences (Конфигурирование вариантовразмещения ресурсов) > Configure Service IP labels/addresses Distribution Preferences (Конфигурирование вариантов размещения сервисных IP-меток/адресов) и нажмите Enter. HACMP выводит только сети, использующие перехват IP-адресов посредством синонимов.
  3. Выберите сеть, для которой требуется задать политику, и нажмите Enter.
  4. На экране Configure Service IP Labels/Address Distribution Preference (Конфигурирование вариантов размещения сервисных IP-меток/адресов) выберите требуемый вариант размещения.
  5. Нажмите Enter, чтобы принять выбранные значения и обновить ODM HACMP на локальном узле.
  6. Для того чтобы изменения вступили в действие и были распространены на все узлы, требуется выполнить синхронизацию кластера. Перейдите в меню Initialization and Standard Configuration (Инициализация и стандартное конфигурирование) или Extended Configuration (Расширенное конфигурирование) и выберите Verification and Synchronization (Верификация и синхронизация). Это инициирует событие динамической реконфигурации.
Примечание. При конфигурировании политики размещения сервисных IP-адресов мы получили следующие сообщения: cldare: Detected changes to service IP label app1svc. Please note that changing parameters of service IP label via a DARE may result in releasing resource group <name>

Просмотр варианта размещения сервисных IP-меток

У вас должна быть возможность выводить текущий вариант размещения для каждой сети с использованием команд cltopinfo или cllsnw.

Выходные данные команды cltopinfo -w имеют следующий вид:

# /usr/es/sbin/cluster/utilities/cltopinfo -w
NODE cobra:
Network net_diskhb_01
cobra_vpath0 /dev/vpath0
Network net_ether_01
app1svc 192.168.100.83
app2svc 192.168.100.82
cobraa 10.10.31.33
cobrab 10.10.32.33
NODE viper:
Network net_diskhb_01
viper_vpath0 /dev/vpath0
Network net_ether_01
app1svc 192.168.100.83
app2svc 192.168.100.82
viperb 10.10.32.32
vipera 10.10.31.32
Network net_ether_01 is using the following
 distribution preference for service labels:
Collocation with persistent - service label(s) 
will be mapped to the same
interface as the persistent label

Ниже приведен пример выходных данных команды cllsnw -c, выводящей вариант размещения сервисной метки (service label distribution preference, sldp) для определенной сети.

#/usr/es/sbin/cluster/utilities/cllsnw -c
#netname:attr:alias:monitor_method:sldp:
net_ether_01:public:true:default:ppstest::
 sldp_collocation_with_persistent

Эксперименты с политикой размещения сервисных меток

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

python-# more /etc/hosts
10.10.31.31 pythona # base address 1
10.10.32.31 pythonb # base address 2
192.168.100.31 p630n01 n1 # python persistent address
192.168.100.82 app1svc # cobra service address
192.168.100.83 app2svc # viper service address
python-# netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
en0 1500 link#2 0.2.55.4f.c4.ab 5044669 0 1828909 0 0
en0 1500 10.10.31 pythona 5044669 0 1828909 0 0
en0 1500 192.168.100 p630n01 5044669 0 1828909 0 0
en0 1500 192.168.100 app1svc 5044669 0 1828909 0 0
en0 1500 192.168.100 app2svc 5044669 0 1828909 0 0
en3 1500 link#3 0.20.35.e2.7f.8d 3191047 0 1410806 0 0
en3 1500 10.10.32 pythonb 3191047 0 1410806 0 0
lo0 16896 link#1 1952676 0 1957548 0 0
lo0 16896 127 localhost 1952676 0 1957548 0 0
lo0 16896 localhost 1952676 0 1957548 0 0
Примечание. В представленных выше выходных данных узел python имел группы ресурсов для узлов cobra и viper, а также соответствующие сервисные IP-адреса. Была установлена политика распределения Collocation with persistent (С совместным размещением и с постоянной меткой).

При тестировании динамического изменения этой политики не произошло перемещения какой-либо метки после синхронизации. Во время синхронизации кластера после изменения политики размещения IP-адресов было зарегистрировано следующее сообщение:

Verifying additional pre-requisites for Dynamic Reconfiguration...
cldare: Detected changes to service IP label app1svc. Please note that changing
parameters of service IP label via a DARE may result in releasing resource group
APP1_RG .
cldare: Detected changes to service IP label app2svc. Please note that changing
parameters of service IP label via a DARE may result in releasing resource group
APP2_RG .
Примечание. В данном случае зарегистрированное сообщение является обычным, и выдается только потому, что было обнаружено изменение. Если это изменение является единственным, отключения ресурсов не произойдет.

Изменение политики размещения сервисных IP-адресов применяется только при вызове события переключения или при остановке и перезапуске HACMP на узле вручную. Обратите внимание на то, что такое выполнение функции является преднамеренным и предназначено для того, чтобы не допустить потенциального нарушения связи с этими IP-адресами. Остальные узлы кластера не применяют политику, если только на них не будет выполнена остановка и перезапуск служб кластера.

< Лекция 13 || Лекция 14: 1234 || Лекция 15 >
Динар Валеев
Динар Валеев
Россия
Lichodedov Andrej
Lichodedov Andrej
Литва