Сценарии установки кластера

Основные этапы внедрения кластера HACMP

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

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

1. Планирование. Этот этап наиболее важен, так как он требует глубоких знаний и четкого представления о своей среде. Тщательное планирование является основой успешного внедрения кластера. Дополнительные сведения о методах планирования см. в "Планирование" , "Планирование".
   Примечание. Помимо конфигурации кластера, этап планирования должен также обеспечивать план тестирования кластера. Этот план тестирования следует использовать на последнем этапе внедрения, а также при периодических проверках кластера.
2. Установка и подключение оборудования. На этом этапе аппаратная среда уже должна быть подготовлена в соответствии с конфигурацией, определенной на этапе планирования. Должны быть выполнены следующие задачи:
   • установка оборудования pSeries (стойки, источники питания, консоль управления оборудованием HMC и т. д.);
   • конфигурирование разделов (где применимо);
   • подключение компьютеров к локальной сетевой среде;
   • подключение компьютеров к хранилищу (SAN).
3. Установка и конфигурирование базовой операционной системы (AIX) и выполнение обязательных условий для работы HACMP. На данном этапе нужно выполнить следующие задачи:
   • установка базовой операционной системы, приложения и обязательных пакетов для работы HACMP (CD-ROM, Network Install Manager) в соответствии с локальными правилами;
   • конфигурирование локальной сетевой среды (конфигурирование TCP/IP – интерфейсы, разрешение имен и т. д.);
   • конфигурирование пользователей, групп, аутентификации и т. д.
4. Конфигурирование общего хранилища. Может включать (в зависимости от используемой подсистемы хранения):
   • конфигурирование драйверов устройства хранения и многопутевых расширений (если применимо);
   • конфигурирование соответствия логического хранилища физическому (RAID-массивов, LUN и т. д.) и защита хранилища;
   • конфигурирование безопасности хранения (маскирование LUN, разделение SAN на зоны) – там, где применимо;
   • конфигурирование метода хранения для приложения (файловые системы, логические тома прямого доступа или диски прямого доступа).
5. Установка и конфигурирование приложений. На данном этапе должно быть выполнено конфигурирование приложений и тестирование их выполнения на автономном узле. Также следует вручную выполнить перемещение и тестирование приложения на всех узлах, выделенных для выполнения приложения в кластере высокой доступности:
   • создайте и протестируйте скрипты запуска и остановки приложения; убедитесь в том, что приложение способно восстанавливаться после неожиданных отказов, и что скрипты запуска/остановки работают должным образом на всех узлах, выделенных для выполнения приложения;
   • создайте и протестируйте скрипты мониторинга приложения (если нужно) на всех узлах, выделенных для выполнения приложения.
6. Установка программного обеспечения HACMP и выполнение перезагрузки всех узлов. Это также обязательно после применения исправлений HACMP.
7. Определение кластера и обнаружение или определение вручную топологии кластера. Так как HACMP содержит несколько инструментов конфигурирования, можно выбрать между "стандартным" (простым) и "расширенным" (более сложным) путем конфигурирования. Кроме того, можно выбрать между введением всех данных топологии вручную и использованием механизма обнаружения HACMP, которое упрощает конфигурирование кластера.
8. Синхронизация топологии кластера и запуск служб HACMP (на всех узлах). На этом этапе мы рекомендуем выполнить верификацию и синхронизацию топологии кластера и запустить службы кластера. Верификация и синхронизация на данном этапе упрощают выполнение последующих этапов внедрения, так как ошибки конфигурации гораздо проще обнаружить и исправить их на данном этапе, обеспечивая надежную топологию кластера для дальнейшего конфигурирования ресурсов.
9. Конфигурирование ресурсов кластера. На данном этапе следует выполнить конфигурирование следующих ресурсов:
   • сервисные IP-адреса (метки);
   • серверы приложений (скрипты запуска/остановки приложений);
   • мониторы приложений (скрипты и действия мониторинга приложений).
10. Конфигурирование групп ресурсов кластера и общего хранилища. Группы ресурсов кластера являются "контейнерами", используемыми для группирования ресурсов, управляемых совместно в HACMP. Изначально группы ресурсов определяются как пустые контейнеры:
    • определите группы ресурсов; выполните синхронизацию кластера;
    • определите общее хранилище (группы томов, файловые системы, дисковые системы сторонних производителей и т. д.);
    • наполните группы ресурсов сервисными IP-метками, серверами приложений, группами томов, мониторами приложений.
11. Выполните синхронизацию кластера. Так как топология HACMP уже сконфигурирована и службы HACMP запущены, то после синхронизации кластера группы ресурсов будут подключены. Проведите оценку кластера путем проверки сообщений (консоль, /tmp/hacmp. out и т. д.).
12. Проведите тестирование кластера. Как только кластер достигнет стабильного (stable) состояния, следует провести тестирование кластера.
    Примечание. Несмотря на возможность использования инструмента автоматического тестирования кластера, мы настоятельно рекомендуем также выполнять тщательное тестирование кластера вручную. Инструмент автоматического тестирования кластера особенно полезен: а) для документирования тестов и результатов, б) для обновления документации кластера.

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

Помимо "классического" конфигурирования с использованием инструмента System Management Interface Tool (SMIT), HACMP V5.2 и более поздние версии также включают веб-интерфейс для конфигурирования кластера. Хотя необходимо выполнить некоторую подготовительную работу, использование веб-интерфейса для доступа к SMIT-панелям для управления является эффективным методом конфигурирования и обслуживания кластера.

WebSMIT также содержит графический интерфейс для мониторинга работы кластера HACMP. Следует помнить о том, что WebSMIT – это всего лишь интерфейс к меню SMIT и информации о состоянии кластера с некоторыми полезными дополнениями (например, выводом структуры меню SMIT), а также с простым для восприятия графическим интерфейсом.

Основные этапы установки и конфигурирования WebSMIT следующие:

• установка пакета HACMP WebSMIT;
• подготовка платформы – установка Apache и обязательных пакетов;
• конфигурирование защищенного доступа на веб-сервере Apache;
• конфигурирование WebSMIT и документирование;
• верификация и запуск страниц WebSMIT;
• конфигурирование и обслуживание кластера HACMP.

Установка веб-сервера Apache и обязательных пакетов

В этом разделе описывается установка и конфигурирование защищенного HTTP-сервера (Apache с использованием SSL) на узлах кластера. Вы можете установить Apache на всех выделенных узлах кластера или только на некоторых из них. Мы рекомендуем выполнить установку на всех узлах в кластере, так как при этом можно осуществлять администрирование кластера через WebSMIT с любого узла в кластере.

Прежде чем начать, следует просмотреть последний файл README в каталоге /usr/es/sbin/cluster/wsm на узлах кластера.

Необходимо наличие следующих наборов файлов:

• rpm.rte,
• expat-XXXX.ppc.rpm,
• apache-XXXX.ppc.rpm,
• mod_ssl-XXXX.ppc.rpm,
• openssl-XXXX.ppc.rpm.

Где "XXXX" должен отражать текущую версию набора файлов, указанную в файле / usr/es/sbin/cluster/wsm/README на узлах кластера. На момент написания этого курса мы использовали следующие версии:

expat-1.95.7-1.aix5.1.ppc.rpm
apache-1.3.31-1ssl.aix5.1.ppc.rpm
mod_ssl-2.8.19-1ssl.aix5.1.ppc.rpm
openssl-0.9.7d-1.aix5.1.ppc.rpm

Проверьте, установлены ли они в вашей системе, с помощью команды

# rpm -qa

А также проверьте наличие предыдущего списка пакетов RPM.

В текущих инсталляциях AIX 5L, RPM (Red Hat Package Manager) устанавливается по умолчанию. Если RPM не установлен в вашей системе, скопируйте его по адресу ftp://ftp.software.ibm.com/aix/freeSoftware/aixtoolbox/INSTALLP/ppc/rpm.rte и установите

# installp -qacXgd rpm.rte

Копирование кода Apache и необходимых пакетов

В браузере введите следующий URL: http://www-1.ibm.com/servers/aix/products/aixos/linux/download.html

Для сохранения скопированных файлов используйте каталог /tmp. Скопируйте пакет RPM для пакета expat, после чего щелкните по ссылке "AIX Toolbox Cryptographic Content" ("Криптографическое содержимое пакета инструментов AIX"), войдите в систему, получите лицензию и скопируйте RPMS для пакетов openssl, apache и mod_ssl.

Установка Apache и обязательных пакетов

После копирования пакетов в каталог /tmp используйте rpm для установки четырех rpm-файлов (порядок установки этих пакетов является важным), как показано в примере 4.1.

# cd /tmp
# rpm -ivh openssl-*.rpm
# rpm -ivh expat-*.rpm
# rpm -ivh apache-*.rpm
# rpm -ivh mod_ssl-*.rpm

Альтернативный метод установки rpm-пакетов заключается в использовании SMIT (или команды installp, так как команда installp способна обрабатывать rpm-пакеты) с применением быстрого пути smitty install_latest.

Конфигурирование WebSMIT

Программное обеспечение HACMP, включая набор файлов WebSMIT, к этому моменту уже должно быть установлено. См. раздел "Установка веб-сервера Apache и обязательных пакетов".

Для конфигурирования WebSMIT мы собираемся использовать веб-сервер Apache для предоставления меню HACMP SMIT с "виртуального хоста" ("Virtual Host").

Кроме того, в целях безопасности мы используем:

• аутентификацию пользователей (пользователей операционной системы);
• протокол Secure HTTP (HTTPS), чтобы избежать передачи открытым текстом, например при передаче паролей пользователей.
• отдельный порт для страниц WebSMIT – 42267/TCP (чтобы избежать конфликтов с другими веб-страницами, которые могут быть доступны через стандартные порты 80 и 443).

Следуйте файлу README и скопируйте файл конфигурации Apache. Эта конфигурация предполагает, что на вашем компьютере не установлен другой веб-сервер. Если же другой веб-сервер установлен, нужно следовать локальным правилам конфигурирования веб-сервера и проконсультироваться с локальным веб-администратором, прежде чем приступать к конфигурированию WebSMIT и Apache.

Начните с сохранения первоначального файла конфигурации Apache (httpd.conf). Затем скопируйте файл /usr/es/sbin/cluster/wsm/httpd.conf.sample, поставляемый с пакетом WebSMIT, в /etc/opt/freeware/apache/httpd.conf.

Измените файл конфигурации в соответствии с файлом README и параметрами своей среды (разрешение имен, путь, конфигурация IP). Во втором разделе файла httpd.conf следует изменить директиву ServerName в соответствии с примером 4.2.

.................................. Строки пропущены ...........................
#
#ServerName localhost.your.domain
>>>>>>>>>>>>>>> Заменить на: <<<<<<<<<<<<<<<<
#
#ServerName localhost.your.domain
ServerName ha53node1 <------- Добавление строки

Далее в третьем разделе файла httpd.conf следует изменить фрагмент VirtualHost таким образом, чтобы он обрабатывал страницы WebSMIT в соответствии с локальной конфигурацией. Следует добавить целый раздел, как показано в примере 4.3 .

............................ Строки пропущены .....................
### Section 3: Virtual Hosts
............................ Строки пропущены ....................
##
## SSL Virtual Host Context
##
<VirtualHost _default_:443>
................................... Строки пропущены ................................
<VirtualHost>
##### ------------------ Добавлять отсюда ----------------------</VirtualHost>
#!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
#!!!!! Следующие значения должны быть изменены, чтобы отразить 						!!!!!
#!!!!! действительную конфигурацию WebSMIT и HACMP. 							!!!!!
#!!!!! 													!!!!!
#!!!!! Строки начинаются со следующих записей: 								!!!!!
#!!!!! NameVirtualHost 											!!!!!
#!!!!! <VirtualHost> 											!!!!!
#!!!!! 													!!!!!
#!!!!! ServerName 											!!!!!
#!!!!! ServerAdmin 	   										!!!!!
#!!!!! 													!!!!!
#!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

NameVirtualHost 192.168.100.31:42267
<VirtualHost 192.168.100.31:42267>

# General setup for the virtual host
DocumentRoot "/usr/es/sbin/cluster/wsm/htdocs/en_US"
ServerName ha53node1
ServerAdmin root@localhost
ErrorLog /usr/es/sbin/cluster/wsm/logs/error_log
TransferLog /usr/es/sbin/cluster/wsm/logs/access_log

# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on

# SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# See the mod_ssl documentation for a complete list.
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

# Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. A test
# certificate can be generated with 'make certificate' under
# built time. Keep in mind that if you've both a RSA and a DSA
# certificate you can configure both in parallel (to also allow
# the use of DSA ciphers, etc.)
SSLCertificateFile /etc/opt/freeware/apache/ssl.crt/server.crt
#SSLCertificateFile /etc/opt/freeware/apache/ssl.crt/server-dsa.crt

# Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file. Keep in mind that if
# you've both a RSA and a DSA private key you can configure
# both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /etc/opt/freeware/apache/ssl.key/server.key
#SSLCertificateKeyFile /etc/opt/freeware/apache/ssl.key/server-dsa.key

# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile
# when the CA certificates are directly appended to the server
# certificate for convinience.
#SSLCertificateChainFile /etc/opt/freeware/apache/ssl.crt/ca.crt

# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
# Note: Inside SSLCACertificatePath you need hash symlinks
# 	to point to the certificate files. Use the provided
# 	Makefile to update the hash symlinks after changes.
#SSLCACertificatePath /etc/opt/freeware/apache/ssl.crt
#SSLCACertificateFile /etc/opt/freeware/apache/ssl.crt/ca-bundle.crt

# Certificate Revocation Lists (CRL):
# Set the CA revocation path where to find CA CRLs for client
# authentication or alternatively one huge file containing all
# of them (file must be PEM encoded)
# Note: Inside SSLCARevocationPath you need hash symlinks
# 	to point to the certificate files. Use the provided
# 	Makefile to update the hash symlinks after changes.
#SSLCARevocationPath /etc/opt/freeware/apache/ssl.crl
#SSLCARevocationFile /etc/opt/freeware/apache/ssl.crl/ca-bundle.crl
# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional, require and optional_no_ca. Depth is a
# number which specifies how deeply to verify the certificate
# issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth 10

# Access Control:
# With SSLRequire you can do per-directory access control based
# on arbitrary complex boolean expressions containing server
# variable checks and other lookup directives. The syntax is a
# mixture between C and Perl. See the mod_ssl documentation
# for more details.
#<Location />
#SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
# 	and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
# 	and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
# 	and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
# 	and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \
# 	or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
#</Location>

#
# Aliases: Add here as many aliases as you need (with no limit). The format is
# Alias fakename realname
#
<IfModule mod_alias.c>

#
# Note that if you include a trailing / on fakename then the server will
# require it to be present in the URL. So "/icons" isn't aliased in this
# example, only "/icons/". If the fakename is slash-terminated, then the
# realname must also be slash terminated, and if the fakename omits the
# trailing slash, the realname must also omit it.
#
# ScriptAlias: This controls which directories contain server scripts.
# ScriptAliases are essentially the same as Aliases, except that
# documents in the realname directory are treated as applications and
# run by the server when requested rather than as documents sent to the client.
# The same rules about trailing "/" apply to ScriptAlias directives as to
# Alias.
#
	ScriptAlias /cgi-bin/ "/usr/es/sbin/cluster/wsm/cgi-bin/"
#
# "/opt/freeware/apache/cgi-bin" should be changed to whatever your ScriptAlias ed
# CGI directory exists, if you have that configured.
#
	<Directory "/usr/es/sbin/cluster/wsm/cgi-bin">
	 AllowOverride AuthConfig
	 Options None
	 Order allow,deny
	 <FilesMatch ".*\.cgi$|wsm_tree">
	  Allow from all
	</FilesMatch>
	</Directory>
</IfModule>
# SSL Engine Options:
# Set various options for the SSL engine.
# o FakeBasicAuth:
# Translate the client X.509 into a Basic Authorisation. This means that
# the standard Auth/DBMAuth methods can be used for access control. The
# user name is the 'one line' version of the client's X.509 certificate.
# Note that no password is obtained from the user. Every entry in the user
# file needs this password: 'xxj31ZMTZzkVA'.
# o ExportCertData:
# This exports two additional environment variables: SSL_CLIENT_CERT and
# SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
# server (always existing) and the client (only existing when client
# authentication is used). This can be used to import the certificates
# into CGI scripts.
# o StdEnvVars:
# This exports the standard SSL/TLS related 'SSL_*' environment variables.
# Per default this exportation is switched off for performance reasons,
# because the extraction step is an expensive operation and is usually
# useless for serving static content. So one usually enables the
# exportation for CGI and SSI requests only.
# o CompatEnvVars:
# This exports obsolete environment variables for backward compatibility
# to Apache-SSL 1.x, mod_ssl 2.0.x, Sioux 1.0 and Stronghold 2.x. Use this
# to provide compatibility to existing CGI scripts.
# o StrictRequire:
# This denies access when "SSLRequireSSL" or "SSLRequire" applied even
# under a "Satisfy any" situation, i.e. when it applies access is denied
# and no other module can change it.
# o OptRenegotiate:
# This enables optimized SSL connection renegotiation handling when SSL
# directives are used in per-directory context.
#SSLOptions +FakeBasicAuth +ExportCertData +CompatEnvVars +StrictRequire
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</Files>
<Directory "/usr/es/sbin/cluster/wsm/cgi-bin">
SSLOptions +StdEnvVars
</Directory>
# SSL Protocol Adjustments:
# The safe and default but still SSL/TLS standard compliant shutdown
# approach is that mod_ssl sends the close notify alert but doesn't wait for
# the close notify alert from client. When you need a different shutdown
# approach you can use one of the following variables:
# o ssl-unclean-shutdown:
# This forces an unclean shutdown when the connection is closed, i.e. no
# SSL close notify alert is send or allowed to received. This violates
# the SSL/TLS standard but is needed for some brain-dead browsers. Use
# this when you receive I/O errors because of the standard approach where
# mod_ssl sends the close notify alert.
# o ssl-accurate-shutdown:
# This forces an accurate shutdown when the connection is closed, i.e. a
# SSL close notify alert is send and mod_ssl waits for the close notify
# alert of the client. This is 100% SSL/TLS standard compliant, but in
# practice often causes hanging connections with brain-dead browsers. Use
# this only for browsers where you know that their SSL implementation
# works correctly.
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for this.
# Similarly, one has to force some clients to use HTTP/1.0 to workaround
# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
# "force-response-1.0" for this.
SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
# Per-Server Logging:
# The home of a custom SSL log file. Use this when you want a
# compact non-error SSL logfile on a virtual host basis.
CustomLog /usr/es/sbin/cluster/wsm/logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>

Затем следует подготовить файлы и каталоги WebSMIT для локальной платформы, как показано в примере 4.4 .

# ha53node1_> cd /usr/es/sbin/cluster/wsm
# ha53node1_> chown nobody:sytem logs
# ha53node1_> chmod 775 logs
# ha53node1_> chmod 4511 cgi-bin/wsm_cmd_exec
# ha53node1_> ln -sf /usr/share/man/info/en_US/cluster/HAES \
> /usr/es/sbin/cluster/wsm/htdocs/en_US/HAES

Просмотрите файл /ust/es/sbin/cluster/wsm/wsm.conf на наличие следующих параметров (представленных в примере 4.5 ).

AUTHORIZED_PORT=42267
REDIRECT_TO_HTTPS=1
AUTHORIZED_USERS=root
REQUIRE_AUTHENTICATION=1

Эти переменные конфигурации (здесь представлены значения по умолчанию) указывают, что трафик WebSMIT перенаправляется в порт 42267/TCP (как сконфигурировано в разделе VirtualHost для Apache), используется протокол связи HTTPS, доступ к меню HACMP SMIT через WebSMIT разрешен для пользователя "root" и что аутентификация пользователя обязательна.