Динамические LPAR (DLPAR) и виртуализация (VIO)

Освобождение ресурсов DLPAR и CUoD

При остановке сервера приложения на узле LPAR (группа ресурсов перемещается на другой узел) HACMP освобождает только те ресурсы, которые больше не нужны для поддержки этого приложения на узле. Ресурсы освобождаются в свободный пул фрейма.

HACMP сначала освобождает ресурсы DLPAR или CUoD, которые были получены в последнюю очередь. Это означает, что ресурсы CUoD не всегда освобождаются раньше ресурсов DLPAR.

Свободный пул ограничен только одним фреймом. Другими словами, в кластерах, сконфигурированных на основе двух фреймов, HACMP не запрашивает из второго фрейма ресурсы для узла LPAR, расположенного в первом фрейме.

Кроме того, если LPAR-1 освобождает приложение, помещающее некоторые ресурсы DLPAR в свободный пул, LPAR-2, использующий ресурсы CUoD, не предпринимает попыток освободить ресурсы CUoD и получить свободные ресурсы DLPAR.

Остановка узлов LPAR

При принудительном отключении диспетчера кластера (Cluster Manager) на узле LPAR с последующим завершением работы LPAR (вне HACMP) происходит освобождение ресурсов процессора и памяти (без участия HACMP), которые становятся доступными для других групп ресурсов, запущенных на других LPAR. HACMP не следит за ресурсами процессора и памяти, выделенными для LPAR, и не сохраняет их для использования при реинтеграции узла LPAR в кластер.

Если LPAR не был остановлен после принудительного отключения диспетчера кластера на узле, ресурсы процессора и памяти остаются выделенными для LPAR и используются при реинтеграции LPAR в кластер.

Динамическое изменение ресурсов DLPAR и CUoD

Можно выполнить изменение требований к ресурсам DLPAR и CUoD для серверов приложений без остановки служб кластера. После внесения изменений необходимо выполнить синхронизацию кластера.

Новая конфигурация не отображается до возникновения следующего события, вызывающего освобождение приложения (а значит, и группы ресурсов) и его перехват другим узлом. Другими словами, изменение в требованиях к ресурсам процессора, памяти или обоих компонентов не вызывает перерасчета ресурсов DLPAR. HACMP не останавливает и не перезапускает серверы приложений только для того, чтобы внести изменения в систему обеспечения приложения ресурсами (application provisioning).

Если какое-либо другое изменение динамической реконфигурации (т. е. rg_move) вызывает освобождение и перехват групп ресурсов, новые требования к ресурсам для DLPAR и CUoD используются в конце события динамической реконфигурации.

Примеры использования ресурсов DLPAR и CUoD

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

Конфигурация представляет собой фрейм на восемь процессоров с кластером из двух узлов (каждый из которых представляет собой LPAR). Пул CUoD содержит два процессора, доступные посредством активизации CUoD. Узлы (разделы) имеют характеристики, представленные в табл. 10.1 и 10.2.

Определено три сервера приложений, каждый из которых относится к отдельной группе ресурсов.

Параметры стартовой конфигурации:
Longhorn имеет 3 выделенных процессора;
Hurricane имеет 1 выделенный процессор;
свободный пул содержит 4 выделенных процессора.
Серверы приложений запускаются в следующем порядке:
Longhorn запускает App2. Не происходит выделения 
процессоров для выполнения требования наличия трех
процессоров (3 процессора представляют сумму 
минимального количества процессоров для LPAR первого узла, 
равного единице, и желательного количества процессоров 
для App2, равного двум). Longhorn останавливает App2.
Освобождается 2 процессора; остается 1 процессор, 
что соответствует минимальному требованию. 
(Так как отсутствуют другие запущенные серверы приложений, 
единственное требование – наличие минимального количества 
процессоров для LPAR Longhorn, равного единице).

В этом примере мы начинаем с тех же параметров
конфигурации, которые представлены в первом примере.
Серверы приложений запускаются следующим образом:
Longhorn запускает App1; процессоры не выделяются, 
так как требование наличия двух процессоров выполняется. 
Longhorn запускает App3; выделяется 3 процессора для 
выполнения требования наличия шести процессоров. 
Теперь свободный пул содержит 1 процессор.
Longhorn пытается запустить App2. После того как Longhorn 
подхватит App1 и App3, общее количество процессоров, 
требуемое узлу Longhorn для выполнения этих требований, 
равно шести (сумма минимума для LPAR Longhorn, равного единице,
желательного количества для App1, равного единице, и 
желательного количества для App3, равного четырем).
Так как минимальное количество процессоров для App2 равно двум, 
то для получения App2 узлу Longhorn требуется выделить 2 
дополнительных процессора, однако в свободном пуле остался 
только 1 процессор, что не позволяет выполнить минимальное 
требование для App2, составляющее 2 процессора. 
Группа ресурсов с App2 не подхватывается локально, 
так как свободный пул содержит только 1 процессор,
и использование CUoD не разрешено. Если другие участвующие 
узлы отсутствуют, группа ресурсов переходит в состояние ERROR.
Если бы узел Hurricane был членом группы ресурсов App2 и 
был активным в кластере, то произошел бы вызов rg_move 
для переноса группы ресурсов на узел Hurricane.

Стартовая конфигурация имеет следующие параметры:
Longhorn имеет 3 выделенных процессора;
Hurricane имеет 1 выделенный процессор;
свободный пул содержит 4 выделенных процессора.
Серверы приложений запускаются в следующем порядке:
Longhorn запускает App3; выделяется 2 процессора, 
чтобы выполнить условие наличия пяти процессоров;
Longhorn запускает App2; выделяется 2 процессора, 
чтобы выполнить условие наличия семи процессоров. 
В свободном пуле процессоры отсутствуют;
Longhorn запускает App1, из CUoD выделяется 1 процессор, 
чтобы выполнить условие наличия восьми процессоров;
Longhorn останавливает App3, освобождается 4 процессора, 
1 из которых помещается обратно в пул CUoD.

В этом примере при получении группы ресурсов 
происходит сбой в связи с тем, что минимальные 
требуемые ресурсы недоступны при достижении максимума в LPAR.
Конфигурация имеет следующие параметры:
Longhorn имеет 1 процессор;
Hurricane имеет 1 процессор;
свободный пул содержит 6 процессоров.
Серверы приложений запускаются в следующем порядке:
Hurricane запускает App3; выделяется 4 процессора 
для выполнения требования наличия пяти процессоров. 
В свободном пуле остается 2 процессора;
Hurricane пытается запустить App2, однако 
App2 переходит в состояние ERROR, так как максимальное 
количество процессоров для Hurricane – 5 и Hurricane
не может получить больше процессоров.

Ниже приведен реальный пример, имевший место 
на ранних этапах тестирования. Он иллюстрирует 
прямое следствие неправильного планирования 
обеспечения приложений ресурсами.
Мы все еще используем фрейм на восемь процессоров, 
однако дополнительные серверы приложений и узлы 
неприменимы к данному примеру. Конфигурация LPAR
для узла Longhorn представлена в   табл. 10.3.

Сервер приложения App1 имеет параметры, представленные в табл. 10.4:

Стартовая конфигурация представлена ниже.

Сервер приложения App1 запускается локально на узле Longhorn. В процессе получения проверяется минимум для LPAR, который прибавляется к минимуму сервера приложений, что в сумме дает 5. Эта сумма превышает максимум для LPAR, вследствие чего группа ресурсов переходит в состояние ERROR.

Хотя технически LPAR может иметь достаточно ресурсов для содержания приложения, сочетание параметров вызывает отказ. Вообще говоря, минимум и максимум у вас не будут одинаковы.

Такой ситуации можно было избежать одним из трех способов:

Конфигурирование DLPAR в HACMP

Следующие сведения частично взяты из существующего официального документа (whitepaper), созданного перед интеграцией DLPAR с HACMP. Этот документ был посвящен настройке скриптов событий HACMP для использования DLPAR. Однако он также включал и другие основные этапы подготовки. Этот документ был предназначен для внутреннего пользования компанией IBM и ее бизнес-партнерами.

Мы рассмотрим следующие этапы конфигурирования DLPAR в кластере HACMP:

Разрешение имен

Одна из распространенных проблем состоит в несогласованности разрешения имен между всеми системами. Если разрешение имен не сконфигурировано корректно, функцию DLPAR использовать нельзя. Базовая инфраструктура RSCT (Reliable Scalable Cluster Technology) предполагает использование одинакового разрешения имен хостов на всех участвующих узлах. В противном случае RSCT не сможет осуществлять обмен данными должным образом.

Убедитесь в том, что все узлы и HMC настроены одинаково, просмотрев следующий список. Словосочетание "все системы" включает все узлы HACMP и HMC.

Просмотр файлов на системах AIX не представляет сложности. Однако выполнение этой операции в HMC требует дополнительного рассмотрения.

Убедитесь в том, что HMC видит LPAR хоста. Имена и IP-адреса хостов должны быть указаны в списке хостов HMC. Мы рекомендуем конфигурировать информацию хостов через консоль HMC, так как каждая версия кода HMC ограничивает опции командной строки. В Power4 HMC проверка включает следующие действия: HMC Maintenance (Обслуживание HMC) -> System Configuration (Конфигурирование системы) -> Customize Network Settings (Настройка параметров сети) -> Hosts (Узлы). Если адреса и имена не указаны, их можно добавить, щелкнув по кнопке New (Новый). Конфигурация нашего файла узлов HMC представлена на рис. 10.2.

Установка и конфигурирование SSH на узлах HACMP

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

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

Для каждой версии SSH и HMC эти этапы могут несколько различаться. Мы описали процессы, которые мы использовали при успешной реализации своей среды. Информацию по установке SSH в каждой версии AIX можно найти по адресу http://www-1.ibm.com/support/docview.wss?uid=isg1pTechnote0707

Установка SSH

В разделе "Требования" мы рассмотрели, какие пакеты необходимы и где их можно получить. Перечисленные ниже действия предполагают, что эти пакеты уже были скопированы на узлы HACMP. Мы решили поместить все свои образы в общий каталог установки /usr/sys/inst.images.

Пакет rpm.rte должен быть установлен до установки дополнительных пакетов rpm. Для его установки можно использовать либо installp, либо smit install_all. Успешность его установки можно проверить командой lslpp -l rpm.rte ( пример 10.1 ).

Jordan / > lslpp -l rpm.rte
Fileset Level State Description
--------------------------------------------------------------------Path: /usr/lib/objrepos
rpm.rte 3.0.5.36 COMMITTED RPM Package Manager
Path: /etc/objrepos
rpm.rte 3.0.5.36 COMMITTED RPM Package Manager

Теперь можно установить остальные необходимые пакеты с использованием команды rpm. Мы установили эти пакеты, как показано в примере 10.2 .

rpm -i zlib-1.2.1-2.aix5.1.ppc.rpm
rpm -i prngd-0.9.23-3.aix4.3.ppc.rpm
rpm -i openssl-0.9.7d-2.aix5.1.ppc.rpm
rpm -i openssl-devel-0.9.7d-2.aix5.1.ppc.rpm
rpm -i openssl-doc-0.9.7d-2.aix5.1.ppc.rpm

Это выполняет требования, необходимые для установки SSH. В AIX 5.1 и более поздних версиях пакет openSSH имеет формат installp. Если образ был извлечен из tar-пакета, можно теперь его установить с использованием smitty install_all. Необходимо установить три основных набора файлов. Эти наборы файлов и результаты нашей установки представлены в примере 10.3 .

smitty install_all
> openssh.base ALL ¦
¦ + 3.8.0.5202 Open Secure Shell Commands ¦
¦ + 3.8.0.5202 Open Secure Shell Server ¦
¦ > openssh.license ALL ¦
¦ + 3.8.0.5202 Open Secure Shell License ¦
¦ ¦
¦ > openssh.man.en_US ALL ¦
¦ + 3.8.0.5202 Open Secure Shell Documentation - U.S. English ¦
Name Level Part Event Result
--------------------------------------------------------------------openssh.license 3.8.0.5202 USR APPLY SUCCESS
openssh.base.client 3.8.0.5202 USR APPLY SUCCESS
openssh.base.server 3.8.0.5202 USR APPLY SUCCESS
openssh.base.client 3.8.0.5202 ROOT APPLY SUCCESS
openssh.base.server 3.8.0.5202 ROOT APPLY SUCCESS
openssh.man.en_US 3.8.0.5202 USR APPLY SUCCESS

После установки SSH необходимо выполнить конфигурирование узлов HACMP для доступа к HMC без паролей для выполнения удаленных операций DLPAR.

Конфигурирование доступа к HMC через SSH

Документ "Managing the Hardware Management Console" ("Управление консолью управления оборудованием") содержит раздел, описывающий этапы настройки доступа к Remote Secure Shell. Это руководство можно скопировать с веб-сайта IBM по адресу http://publib.boulder.ibm.com/infocenter/iseries/v1r2s/en_US/info/iphai/iphai.pdf Ниже приведены действия, выполнявшиеся нами при настройке для включения доступа к SSH с узлов HACMP.

Во-первых, следует убедиться в том, что консоль HMC настроена на выполнение удаленных операций; для этого нужно выполнить следующие действия:

Необходимо создать каталог $HOME/.ssh для пользователя root, чтобы хранить ключи аутентификации. HACMP будет выполнять удаленные операции DLPAR ssh под учетной записью root. По умолчанию создается каталог с именем /.ssh, которые мы и применили.

Для генерирования открытых и закрытых ключей следует выполнить на каждом узле HACMP команду

/usr/bin/ssh-keygen -t rsa

При этом в каталоге /.ssh будут созданы следующие файлы:

закрытый ключ: id_rsa
открытый ключ: id_rsa.pub

Биты записи для группы и остальных пользователей отключаются. Убедитесь в том, что закрытый ключ имеет разрешение 600.

Открытый ключ HMC должен быть записан в файл known_hosts на каждом узле HACMP, и наоборот. Это легко делается путем выполнения ssh на HMC с каждого узла HACMP. При первом выполнении выводится запрос на вставку ключа в файл. Ответьте Yes (Да) для продолжения, после чего система запросит ввод пароля. Это связано с тем, что настройка беспарольного доступа к ssh еще не завершена ( пример 10.4 ).

Jordan /tmp > ssh -l hscroot 192.168.100.69
The authenticity of host '192.168.100.69 (192.168.100.69)' can't be
established.
RSA key fingerprint is 2d:50:3f:03:d3:51:96:27:5a:5e:94:f4:e3:9b:e7:78
Are you sure you want to continue connecting (yes/no)?yes
Warning: Permanently added '192.168.100.69' (RSA) to the list of known
hosts.

При использовании двух консолей HMC, как в нашей тестовой конфигурации, необходимо повторить этот процесс для каждой консоли HMC. Также может потребоваться сделать это для всех узлов-участников, чтобы обеспечить выполнение операций ssh между ними (т. е. scp, sftp и ssh).

Чтобы обеспечить беспарольный доступ к ssh, нужно поместить открытые ключи каждого узла HACMP в файл authorized_keys2 в HMC. Это можно сделать несколькими способами, однако ниже мы приведем действия, которые предприняли мы.

На первом этапе мы вручную создали файл authorized_keys2. Это можно сделать как из командной строки в HMC, так и удаленно с клиента. Мы выполнили эту операцию удаленно с клиента. Мы решили сначала создать файл-макет (dummy file), после чего скопировать (scp) содержимое объединенных файлов ключей в HMC, заменяя, таким образом, наш файл-макет. Чтобы создать файл-макет мы выполнили с одного клиента следующую команду:

ssh hscroot@hmc "mkauthkeys --add '*' "

В консоли HMC убедитесь, что файл authorized_keys2 существует в каталоге .ssh. Для этого мы выполнили с клиента следующую команду:

ssh hscroot@hmc "ls -al .ssh/"

Затем из каталога /.ssh в LPAR AIX мы создали копию открытого ключа и переименовали ее таким образом, чтобы имя файла включало имя локального узла. После этого мы скопировали (с использованием scp) открытый ключ каждого компьютера (Jessica и Alexis) на один узел (Jordan). Затем мы выполнили команду cat для создания файла authorized_keys2, содержащего информацию об открытых ключах для всех узлов HACMP. Команды, выполняемые на каждом узле, представлены в примере 10.5 :

Alexis /.ssh > cp id_rsa.pub id_rsa.pub.alexis
Alexis /.ssh > scp id_rsa.pub.alexis jordan:/.ssh/id_rsa.pub.alexis
Jessica /.ssh > cp id_rsa.pub id_rsa.pub.jessica
Jessica /.ssh > scp id_rsa.pub.jessica jordan:/.ssh/id_rsa.pub.jessica
Jordan /.ssh > cp id_rsa.pub id_rsa.pub.jordan
Jordan /.ssh > cat id_rsa.pub.alexis id_rsa.pub.jessica id_rsa.pub.jordan
>authorized_keys2
Jordan /.ssh > ls -al
total 64
drwx------ 2 root system 256 Jul 18 22:27 .
drwxr-xr-x 21 root system 4096 Jul 14 02:11 ..
-rw-r--r-- 1 root system 664 Jun 16 16:31 authorized.keys2
-rw------- 1 root system 883 Jun 16 14:12 id_rsa
-rw-r--r-- 1 root system 221 Jun 16 14:12 id_rsa.pub
-rw-r--r-- 1 root system 221 Jun 16 16:30 id_rsa.pub.alexis
-rw-r--r-- 1 root system 222 Jun 16 15:20 id_rsa.pub.jessica
-rw-r--r-- 1 root system 221 Jun 16 16:27 id_rsa.pub.jordan
-rw-r--r-- 1 root system 1795 Jul 14 04:08 known_hosts
Jordan/.ssh > scp authorized.keys2 hscroot@192.168.100.69:.ssh/authorized_keys2
hscroot@192.168.100.69's password:
authorized_keys2 100% 664 0.7KB/s 00:00

При выполнении команды копирования (scp) в консоль HMC система запрашивает пароль пользователя hscroot. После его ввода происходит копирование файла authorized_ key2. Затем можно протестировать, работает ли беспарольный доступ с каждого узла путем выполнения команды ssh, как было показано в примере 10.4 . Однако на этот раз вы должны будете попасть в приглашение командной строки оболочки HMC, как показано в примере 10.6 .

Alexis /.ssh > ssh -l hscroot 192.168.100.
Last login:Thur Jun 16 22:46:51 2005 from 192.168.100.61
hscroot@hmcitso:~>

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

Определение имен HMC и управляемой системы

Для каждого узла HACMP должны быть заданы IP-адреса HMC, которые будут использовать DLPAR. В нашем примере каждый узел HACMP соответствует LPAR. Каждый LPAR назначается управляемой системе. Управляемыми системами называются системы, физически подключенные к HMC и управляемые HMC. Эти управляемые системы также должны быть определены в HACMP.

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

Чтобы определить подключение HMC для каждого узла HACMP сделайте следующее:

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

В процессе верификации кластера HACMP проверяет доступность HMC, выдавая ping на заданный IP-адрес. Если HMC реагирует, то HACMP проверяет способность каждого заданного узла HACMP поддерживать DLPAR, выдавая команду lssycfg через ssh в консоли HMC.

Конфигурирование обеспечения приложений ресурсами

Конфигурирование ресурсов динамических LPAR и CUoD для каждого сервера приложений, который может использовать выделенные ресурсы DLPAR или CUoD, состоит из следующих действий:

В smit hacmp выберите Extended Configuration (Расширенное конфигурирование) -> Extended Resource Configuration (Расширенное конфигурирование ресурсов) -> HACMP Extended Resources Configuration (Расширенное конфигурирование ресурсов HACMP) -> Configure HACMP Applications (Конфигурирование приложений HACMP) -> Configure HACMP for Dynamic LPAR and CUoD Resources (Конфигурирование ресурсов динамических LPAR и CUoD в HACMP) -> Configure Dynamic LPAR and CUoD Resources for Applications (Конфигурирование ресурсов динамических LPAR и CUoD для прило жений) -> Add Dynamic LPAR and CUoD Resources for Applications (Добавление ресурсов динамических LPAR и CUoD для приложений) и нажмите Enter. Выводится список сконфигурированных серверов приложений(рис 10.3) Определение HMC и управляемой системы в HACMPЗамечание. Можно использовать быстрый путь smit cladd_appdlpar.dialog

Выберите сервер приложения из списка и нажмите Enter. Появляется экран указания требований для сервера приложения. Дополнительные сведения см. в справочных экранах и в разделе "Предоставление доступа к приложениям".

Заполните следующие поля:

Application Server Name (Имя сервера приложения). Здесь указывается сервер приложений, для которого выполняется конфигурирование предоставления ресурсов динамического LPAR и CUoD, выбранных в предыдущем меню.

Minimum Number of CPUs (Минимальное количество процессоров). Введите минимальное количество процессоров, которое следует получить при запуске сервера приложения. По умолчанию задано значение 0. Для осуществления обеспечения приложений ресурсами HACMP проверяет, сколько процессоров сверх минимального значения узел LPAR имеет на данный момент, сравнивает это число с минимумом, заданным в этом поле, и на основании этого запрашивает больше процессоров, если это необходимо.

Number of CPUs (Количество процессоров1). Введите максимальное количество процессоров, которое HACMP попытается выделить на узле перед запуском этого приложения на данном узле. По умолчанию задано значение 0. Minimum Amount of Memory (Минимальный объем памяти). Введите объем памяти, который требуется получить при запуске сервера приложения. Значение должно быть кратно 256.

Use CUoD if resources are insufficient? (Использовать CUoD при нехватке ресурсов?). По умолчанию установлено значение No. Выберите Yes, чтобы HACMP использовал CUoD (Capacity Upgrade on Demand), чтобы получить достаточно ресурсов для обеспечения запрошенного минимального количества. Использование CUoD требует ввода лицензионного ключа (кода активизации) в консоли управления оборудованием (Hardware Management Console, HMC), что может вызвать дополнительные затраты в связи с использованием лицензии CUoD.

I agree to use CUoD resources (Я согласен использовать ресурсы CUoD). По умолчанию установлено значение No. Выберите Yes, чтобы подтвердить, что вы понимаете, что использование CUoD может вызвать дополнительные затраты. HACMP записывает ответ в файлы syslog и smit.log.

Когда приложение требует выделения дополнительных ресурсов на заданном узле, HACMP определяет, достаточно ли будет запросить только ресурсы DLPAR из свободного пула фрейма, чтобы обеспечить требуемое количество ресурсов, или же необходимо также запросить ресурсы CUoD для сервера приложения. После этого HACMP продолжает запрашивать желаемый объем памяти и оптимальное количество процессоров, если эти параметры были выбраны.

В процессе верификации HACMP выполняет проверку на то, чтобы введенные значения были ниже максимальных значений объема памяти и количества процессоров для LPAR. В противном случае HACMP выдает сообщение об ошибке с описанием этих требований.

HACMP также выполняет проверку на то, чтобы суммарное количество требуемых ресурсов для ВСЕХ серверов приложений, которые могут одновременно выполняться в LPAR, было меньше максимального значения для LPAR. При несоблюдении данного требования HACMP выдает предупреждение. Заметьте, что такая ситуация может произойти при последующих перемещениях при сбое. Другими словами, если узел LPAR уже содержит серверы приложений, требующие ресурсы DLPAR и CUoD, то при получении еще одного сервера приложения, LPAR может оказаться неспособным получить какие-либо дополнительные ресурсы, превышающие его максимум. HACMP выполняет соответствующую проверку и выдает предупреждение.

Пример настройки обеспечения приложения ресурсами в нашей тестовой конфигурации представлен на рис. 10.4.

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

Устранение ошибок верификации HMC

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

ERROR: The HMC with IP label 192.168.100.69 configured on node jordan is not
reachable. Make sure the HMC IP address is correct, the HMC is turned on and
connected to the network, and the HMC has OpenSSH installed and setup with the
public key of node jordan.

В примере 10.7 сообщение об ошибке само по себе содержит предполагаемые причины проблемы. Ниже описывается, что можно сделать для определения источника проблемы.

Если команда ssh выполняется неуспешно или если она запрашивает пароль, это указывает на неправильную конфигурацию ssh.

ERROR: An HMC has been configured for node jordan, but the node does
not appear to be DLPAR capable.

Возникновение сообщения, представленного в примере 10.8 , указывает на то, что доступ к HMC работает, однако определение LPAR, соответствующее определенному узлу, не сообщает о том, что оно поддерживает DLPAR. Это можно проверить вручную из командной строки HMC, как показано в примере 10.9 .

hscroot@hmcitso:~> lssyscfg -r lpar -m itso_p690_1 -n Jordan
Name id DLPAR State Profile OpPanel
Jordan 001 NO Running Jordan_Prod

Это сообщение может быть вызвано, например, тем, что на узле выполняется версия AIX ниже 5.2, которая необходима для операций DLPAR. Оно также может быть вызвано некорректным обновлением RMC.

В процессе нашего тестирования возникло несколько событий за очень короткие периоды времени. В определенный момент наш LPAR выдал сообщение о том, что он не поддерживает DLPAR. Спустя некоторое время все снова работало нормально. Мы считаем, что это было вызвано нарушением синхронизации информации RMC между логическими разделами и HMC.

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

Наша тестовая конфигурация состоит из трех LPAR на двух системах p690s: двух рабочих LPAR (Jordan, Jessica) на одной системе p690 (itso_p690_1) и одного дежурного LPAR (Alexis) на второй системе p690 (itso_p690_2). Каждая система p690 содержит восемь процессоров и 8 Гб памяти и подключена к двум консолям HMC в целях обеспечения избыточности.

В каждом разделе установлены следующие версии программного обеспечения:

В каждом разделе установлены следующие адаптеры:

Оба HMC имеют:

Наши тестовые LPAR и соответствующие фреймы см. на рис. 10.5.

В качестве общего хранилища мы использовали ESS с восьмью LUN на 10 Гб, четыре из которых назначены рабочим группам ресурсов. Для тестирования общее хранилище не было важным; оно предназначалось только для настройки более полной конфигурации кластера с использованием мониторинга пульса через диски.

Для этих LPAR сконфигурированы параметры разделов, представленные в табл. 10.5.

У нас сконфигурировано две группы ресурсов (app1_rg и app2_rg), каждая из которых содержит свои серверы приложений – app1 и app2 соответственно. Каждая группа ресурсов конфигурируется как подключающаяся на домашнем узле (online on home node). App1_rg содержит участвующие узлы Jordan и Alexis. App2_rg содержит участвующие узлы Jessica и Alexis. В итоге получается кластер с конфигурацией 2+1, где узел Alexis является дежурным (standby node).

Для каждого узла связи с HMC были настроены таким образом, чтобы включать обе консоли HMC с IP-адресами 192.168.100.69 и 192.168.100.5.

Параметры конфигурации DLPAR для серверов приложений представлены в табл. 10.6.

Мы специально установили минимальные, нулевые, значения, чтобы всегда можно было получить группу ресурсов.

Результаты тестирования

Сценарий 1: получение группы ресурсов

В этом сценарии мы начинаем со следующей конфигурации:

При запуске служб кластера на узле Jordan app1 запускается локально и пытается получить оптимальное количество ресурсов. Так как свободный пул содержит достаточно ресурсов, он получает еще 3 процессора и 3 Гб памяти, как показано на рис. 10.6.

Сценарий 2: освобождение группы ресурсов

В этом сценарии узел Jessica подключен в кластере с запущенным сервером приложения app2 при максимальных значениях: 2 процессора и 2 Гб.

При остановке служб кластера на узле Jessica сервер приложения app2 останавливается локально и освобождает ресурсы обратно в свободный пул. При этом HACMP не освобождает больше ресурсов, чем изначально было получено.

На рис. 10.7 представлено освобождение ресурсов и их перемещение обратно в свободный пул.

Сценарий 3: последовательное перемещение при сбое для каждого LPAR

Этот сценарий состоит из двух частей, при котором выполняется перемещение при сбое для каждого раздела: сначала для узла Jordan, затем для узла Jessica. Это демонстрирует, что во время перемещения при сбое получение ресурсов выполняется подобно получению локальной группы ресурсов.

Также мы покажем различия между этим сценарием и сценарием 4, "Перемещение при сбое для рабочих LPAR в обратном порядке", в общем количестве ресурсов на дежурном узле.

В первой части инициируется отказ узла Jordan командой reboot -q. При этом происходит перемещение при сбое на узле Alexis. Alexis получает группу ресурсов app1 и выделяет желаемое количество ресурсов, как показано на рис. 10.8.

Узел Alexis теперь имеет такое же количество ресурсов, как и первый отказавший узел.

Вторая часть этого сценария начинается со следующей конфигурации:

Теперь инициируется отказ узла Jessica командой reboot -q. Узел Alexis перехватывает группу ресурсов app2 и получает желаемое количество ресурсов, как показано на рис. 10.9.

В конечном итоге Alexis остается с максимальными параметрами раздела: 6 процессоров и 6 Гб памяти.

Сценарий 4: перемещение при сбое для рабочих LPAR в обратном порядке

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

На этот раз мы сначала инициируем отказ узла Jessica своим предпочтительным методом или командой reboot -q. Это приводит к тому, что узел Alexis получает группу ресурсов app2 и оптимальное количество ресурсов, как показано на рис. 10.10.

Здесь необходимо отметить, что теперь Alexis имеет 3 процессора и 3 Гб памяти. Обычно группа ресурсов app2 имеет только 2 процессора и 2 Гб памяти на узле Jessica. Технически это может превышать необходимое количество ресурсов. Как видим, при предоставлении доступа к приложениям в конце может использоваться другое количество ресурсов, в зависимости от того, на каком LPAR/профиле раздела группа ресурсов оказывается в конечном итоге.

Вторая часть сценария начинается со следующей конфигурации:

Jordan (фрейм 1) имеет 4 процессора и 4 Гб памяти;

узел Jessica отключен;(рис 10.11) Перемещение при сбое для второго рабочего LPAR сначала(рис 10.10) Результаты второго перемещения при сбое

Alexis (фрейм 2) имеет 3 процессора и 3 Гб памяти;

свободный пул (фрейм 2) содержит 5 процессоров и 5 Гб памяти.

Теперь мы инициируем отказ узла Jordan командой reboot -q. Узел Alexis перехватывает группу ресурсов app1 и получает желаемые ресурсы, как показано на рис. 10.11. В итоге получаем то же, что и в предыдущем сценарии.

Сценарий 5: повторное получение группы ресурсов через rg_move

В этом сценарии мы начинаем с конфигурации, полученной в результате выполнения сценария 4 после перезапуска узлов Jordan и Jessica в кластере. Стартовая конфигурация имеет следующий вид:

Узел Alexis на данный момент содержит две группы ресурсов. Мы выполняем rg_ move для перемещения группы ресурсов app2_rg с узла Alexis обратно на домашний узел Jessica. Узел Alexis освобождает 2 процессора и 2 Гб памяти, тогда как узел Jessica получает только 1 процессор и 1 Гб памяти, как показано на рис. 10.12. Это опять же является прямым следствием сочетания настроек обеспечения приложений ресурсами и параметров LPAR.

Сценарий 6: тестирование избыточности HMC

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

Мы физически отключили кабель Ethernet из первой указанной консоли HMC с адресом 192.168.100.69. После этого мы инициировали отказ узла Jordan, чтобы вызвать перемещение при сбое. Это показано на рис. 10.13.

В процессе перемещения при сбое и попыток получения доступа к HMC происходит следующее:

Операции тестирования HMC можно просмотреть в файле /tmp/hacmp.out с использованием утилиты clhmcexec.

HACMP и виртуализация

Во время написания данной книги было сделано официальное сообщение о поддержке виртуализации в HACMP. Подробности поддержки мы рассмотрим в последующих разделах, тогда как текст сообщения можно найти по следующему адресу: http://w3-1.ibm.com/sales/systems/portal/_s.155/254?navID=f220s240geoID= Allpr odID=IBM%20eServer%20And%20TotalStorage%20ProductsdocID=hacmpvio063005

Требования

Для использования встроенных функций виртуализации и/или CUoD в HACMP в системах Power5 на всех узлах LPAR в кластере должны быть установлены как минимум следующие версии программного обеспечения:

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

Для правильного управления и обеспечения функций DLPAR необходимо подключение HMC к LPAR. В консоли HMC также должны быть установлены как минимум следующие версии программного обеспечения:

HMC Version 4 Release 5 Build 20050519.1 или выше.

Обеспечение приложений ресурсами

Все аспекты, рассмотренные в разделе "Обеспечение приложений ресурсами", относятся и к конфигурированию микроразделов (micropartitioning).

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

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

Вы не сможете использовать выделенные мощности (с точностью до 1/10 мощности процессора) в качестве значения для определения обеспечения приложений ресурсами в меню HACMP.

HACMP не проверяет, является ли раздел capped или uncapped. В зависимости от конфигурации необходимо проверить возможные варианты самостоятельно. Максимальным значением для одного виртуального процессора является один физический процессор ( рис. 10.14). Таким образом, количество виртуальных процессоров, назначенных для раздела, определяют максимум вычислительной мощности для этого раздела.

Поэтому можно достичь хороших результатов с использованием виртуальных процессоров с HACMP, вместо того чтобы настраивать количество виртуальных процессоров в разделе на случай наихудшего развития событий (когда множество приложений выполняет перемещение при сбое на один узел). В этом случае количество(рис 10.14) Назначение выделенной мощности разделувиртуальных процессоров не оптимизировано (с большим использованием вычислительной мощности в гипервизоре).

При работе в capped-среде следует заранее прогнозировать количество виртуальных процессоров в разделе для обеспечения требуемой производительности для своего приложения. В действительности, если установить выделенную мощность в один процессор и создать четыре виртуальных процессора, всегда будет назначена выделенная мощность в один процессор, что соответствует одному физическому процессору, а не четырем. В uncapped среде такая проблема не возникает ( рис. 10.15). Единственный способ ограничить раздел состоит в ограничении количества виртуальных процессоров и веса.

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

Табл. 10.8 содержит действительные активные значения.

Чтобы определить количество свободных ресурсов, следует отнять 2,8 [сумму столбца (1) для одного компьютера] от общего количества процессоров на компьютере.

Свободные ресурсы на компьютере patrick: 4 – 2,8 = 1,2.

Свободные ресурсы на компьютере shawn: 4 – 1,3 = 2,7.

Вычисления с одним ресурсом на узле Patrick: 1 VP (минимум для LPAR) + 2 VP (желательное количество) = 3 VP, активных при запущенном app2.

Вычисления по добавлению еще одного приложения app1: 1 VP (желательное количество) + 3 VP (активные на данный момент) – 1 VP (минимум для LPAR) – 2 VP = 1 VP (нужно добавить). Если это значение меньше количества свободных ресурсов (1,2), то HACMP добавляет его.

Код HACMP допускает настройку оптимального размера LMB. Размер LMB берется из HMC. Однако меню smit позволяет добавлять только по 256 Мб.

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

Сценарии конфигурирования HACMP и виртуализации

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

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

Сценарий 1

Обзор HACMP и виртуальных компонентов

HACMP можно использовать как обычно в виртуальной среде. Конечно же, нужно учитывать вышеперечисленные ограничения. Схема на рис. 10.16 иллюстрирует компоненты так, как они представлены в HACMP. В целях избыточности мы определили два виртуальных сервера ввода-вывода (Virtual I/O server) на компьютер. Раздел клиента AIX указывает через виртуальный адаптер на раздел VIOS. При использовании Virtual SCSI для доступа к дискам (vscsi0, vscsi1, ...) автоматически применяется MPIO (Multi-path I/O). Поэтому существует два пути доступа к общим дискам. Команда

lspath выводит путь, управляемый MPIO ( рис. 10.17). Виртуальный адаптер не выдает ошибок оборудования в AIX. Однако HACMP использует RSCT для передачи информации о состоянии всех компонентов, участвующих в обмене данными.

Пример 10.10 показывает конфигурацию HACMP в нашем тестовом кластере.

patrick / > cldump
_____________________________________________________________________________
Cluster Name: app2_cluster
Cluster State: UP
Cluster Substate: UNSTABLE
_____________________________________________________________________________
Node Name: patrick State: UP
Network Name: net_diskhb_01 State: UP
Address: Label: patrick2shawn State: UP
Network Name: net_ether_01 State: UP
Address: 10.10.5.2 Label: patrick_base1 State: UP
Address: 10.10.6.2 Label: patrick_base2 State: UP
Address: 192.168.101.143 Label: vio_svc2 State: UP
Node Name: shawn State: UP
Network Name: net_diskhb_01 State: UP
Address: Label: shawn2patrick State: UP
Network Name: net_ether_01 State: UP
Address: 10.10.5.1 Label: shawn_base1 State: UP
Address: 10.10.6.1 Label: shawn_base2 State: UP
Address: 192.168.101.142 Label: vio_svc1 State: UP
Cluster Name: app2_cluster
Resource Group Name: app2_group
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
Site Policy: ignore
Priority Override Information:
Primary Instance POL:
Node Group State
---------------------------- --------------shawn ONLINE
patrick OFFLINE
Resource Group Name: app1_group
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
Site Policy: ignore
Priority Override Information:
Primary Instance POL:
Node Group State
---------------------------- --------------patrick ONLINE
shawn OFFLINE

Необходимо сконфигурировать виртуальный сервер ввода-вывода (Virtual I/O, VIO), который бы предлагал виртуальные компоненты для использования в разделе.

На следующей схеме ( рис. 10.18) представлены подробные сведения об используемых аппаратных компонентах. Условные обозначения позволяют отличить виртуальные компоненты от физических компонентов. Обратите внимание на то, что в нашем тесте работа AIX и HACMP основана только на виртуальных компонентах. На каждом узле используется четыре виртуальных SCSI, два из которых предназначены для зеркального отображения системного диска, а еще два для общих дисков. Весь доступ распределен по двум VIO-серверам.

Общие диски для обоих клиентских разделов должны быть определены как диски мониторинга пульса (hdisk) в целевом определении на VIO-сервере.

Настройка виртуализации

Во-первых, как сказано в книге Advanced POWER Virtualization on IBM Eserver® p5 Servers: Introduction and Basic Configuration, SG24-7940, необходимо планировать свои операции. Ниже перечислены операции, которые мы выполнили для реализации своей конфигурации виртуализации.

Планирование операций (рис 10.19(рис 10.19) Схема архитектуры виртуализации(рис 10.18) Инструмент планирования операций виртуализации в среде Excel

Создание конфигурации LPAR в консоли HMC. Каждый раздел VIOS определяется с одним адаптером Virtual Ethernet и с двумя адаптерами Virtual SCSI. Адаптер Virtual Ethernet определяется как транковый (trunk) адаптер (в дальнейшем – ent1). Оба адаптера Virtual SCSI определены как серверы (в дальнейшем – vhost0 и vhost1).

Установка раздела VIOS с последующим его обновлением командой updateios.

Установка общего адаптера Ethernet (Shared Ethernet Adapter, SEA). (Пример 10.11).

mkvdev -sea ent0 -vadapter ent1 default ent1 -defaultid 1
mktcpip -hostname vioserver_lisa -inetaddr 192.168.100.220 -netmask
255.255.255.0 -gateway 192.168.100.60 -start

Создание виртуальных дисков. В нашем кластере мы создаем два типа дисков для клиента. На узле shawn мы создаем оба целевых диска в разделе VIOS как логический том (см. пример 10.2). На узле patrick мы создаем оба целевых диска в разделе VIOS как диск hdisk (см. пример 10.2).

mkvg -f -vg shawnvg hdisk1
mklv -lv shawn_lv shawnvg 30G
mkvdev -vdev shawn_lv -vadapter vhost0 -dev vshawn_disk
mkvdev -vdev hdisk1 -vadapter vhost0 -dev vpatrick_disk

Установка системы и HACMP в клиентском разделе.

Зеркальное отображение системных дисков и изменение списка загрузочных устройств.

Если вы хотите использовать функцию DLPAR или CUoD, следует установить и сконфигурировать SSH, как описано в разделе "Установка и конфигурирование SSH на узлах HACMP".

Результаты тестирования

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

Зеркальное отображение rootvg

При завершении работы VIOS пропадает доступ к части дисков. Зеркальное отображение позволяет продолжить работу. На имеющемся уровне AIX для восстановления доступности дисков необходимо убрать диск из определения rootvg, после чего добавить такой же диск и выполнить зеркальное отображение. Затем необходимо выполнить команду bosboot.

Замена адаптера

HACMP использует RSCT для слежения за состоянием коммуникационных интерфейсов или устройств. На рис. 10.20 показано выявление отказа на виртуальном адаптере. В этом тесте мы отключаем кабель Ethernet для имитации отказа физической сети.

В этом примере до 18:33 сетевое подключение было доступно. В 18:33:30 мы отключили кабель Ethernet. В 18:33:59 службы топологии определяют отсутствие пульса, указывающее на отключение адаптера en2. В 18:34:02 HACMP выполняет операцию swap_adapter.

Отключение VIO-сервера

В этом тесте происходит отключение сервера vioserver_lisa. Все операции продолжают выполняться с использованием второго пути. MPIO выполняет свои функции, сохраняя доступ к данным через второй VIO-сервер, vioserver_maelle. Конечно же, rootvg всегда активен на диске с зеркальным отображением (см. рис. 10.21). Команда lspath показывает, что на одном пути произошел отказ доступа к общим дискам.

Как описывается в разделе "Зеркальное отображение rootvg", когда VIO-сервер включен, необходимо выполнять операцию вручную. Команда lspath показывает состояние каждого пути ( рис. 10.13). Можно выполнить команду chpath или использовать быстрый путь smit mpiopath_enable_all; на рис. 10.21 представлено состояние после выполнения этой команды. Адаптер Virtual Ethernet подключается автоматически событием join_interface.

Пример 10.13 отображает информацию об отсутствующих путях для виртуальных дисков.

(рис 10.13) Отказ VIO-сервера(рис 10.21) Команда lspath – вывод отсутствующих путейpatrick / > lspath
Enabled hdisk1 vscsi1
Missing hdisk3 vscsi2
Missing hdisk4 vscsi2
Missing hdisk5 vscsi2
Missing hdisk6 vscsi2
Failed hdisk6 vscsi3
Failed hdisk5 vscsi3
Failed hdisk4 vscsi3
Failed hdisk3 vscsi3
Enabled hdisk2 vscsi0
Missing hdisk0 vscsi0

При отключении одного VIO-сервера команда lspath выдает выходные данные, подобные представленным в примере 10.14.

patrick / > lspath
Enabled hdisk1 vscsi1
Missing hdisk3 vscsi2
Missing hdisk4 vscsi2
Missing hdisk5 vscsi2
Missing hdisk6 vscsi2
Enabled hdisk6 vscsi3
Enabled hdisk5 vscsi3
Enabled hdisk4 vscsi3
Enabled hdisk3 vscsi3
Enabled hdisk2 vscsi0
Missing hdisk0 vscsi0

Перемещение при сбое для одного узла

В итоге ситуация после выполнения этих тестов одинакова:

HACMP завершил логическую обработку.

Аспекты производительности и архитектуры (сценарий 2)

Мы пойдем дальше и попытаемся добавить еще один кластер в ту же инфраструктуру. Этот сценарий включает два кластера HACMP. Мы определяем еще два сервера Virtual SCSI ( рис. 10.22).

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

Каждое приложение имеет собственный кластер. Администрирование упрощается, что позволяет улучшить управление средой. Конфигурирование виртуализации позволяет управлять обеспечением приложений ресурсами. Конфигурирование этого кластера с использованием HACMP config assist отнимает минимальное количество времени.

Группа ресурсов RG1 представляет рабочую группу ресурсов, требующую больше ресурсов процессора. Сконфигурировав значение веса uncapped на каждом разделе, можно осуществлять поддержку среды. HACMP активизирует ресурсы, связанные с сервером приложения (количество виртуальных процессоров). Механизм вычисления такой же, как и в разделе "Обеспечение приложений ресурсами".

В этой конфигурации мы используем две функции: функцию обеспечения приложений ресурсами в HACMP и функцию микроразделов, входящую в APV (Advance Power Virtualization). Вместо остановки другого раздела в целях освобождения некоторых ресурсов мы используем функцию веса uncapped, чтобы сохранить приоритет за более важным разделом.

Параметры микроразделов ( табл. 10.9) не зависят от параметров HACMP. Ниже описывается тест, который можно выполнить. Инициируем перемещение при сбое с одного узла на другой. В то же время осуществляем сбор некоторых данных производительности в каждом разделе. Значение веса uncapped для LPAR patrick составляет 200, а для LPAR guilaine – 10; это означает, что раздел patrick имеет более высокий приоритет.

Вес uncapped представляет собой число в диапазоне от 0 до 255, устанавливаемое для каждого uncapped раздела в пуле общих процессоров; 255 – наивысший вес.

Доступная неиспользуемая мощность распределяется между разделами пропорционально значениям веса uncapped.

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