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

Разбить на страницы

Показывать лекцию целиком

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

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

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

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

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

установка оборудования pSeries (стойки, источники питания, консоль управления оборудованием HMC и т. д.);

конфигурирование разделов (где применимо);

подключение компьютеров к локальной сетевой среде;

подключение компьютеров к хранилищу (SAN).

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

установка базовой операционной системы, приложения и обязательных пакетов для работы HACMP (CD-ROM, Network Install Manager) в соответствии с локальными правилами;

конфигурирование локальной сетевой среды (конфигурирование TCP/IP – интерфейсы, разрешение имен и т. д.);

конфигурирование пользователей, групп, аутентификации и т. д.

Конфигурирование общего хранилища. Может включать (в зависимости от используемой подсистемы хранения):

конфигурирование драйверов устройства хранения и многопутевых расширений (если применимо);

конфигурирование соответствия логического хранилища физическому (RAID-массивов, LUN и т. д.) и защита хранилища;

конфигурирование безопасности хранения (маскирование LUN, разделение SAN на зоны) – там, где применимо;

конфигурирование метода хранения для приложения (файловые системы, логические тома прямого доступа или диски прямого доступа).

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

создайте и протестируйте скрипты запуска и остановки приложения; убедитесь в том, что приложение способно восстанавливаться после неожиданных отказов, и что скрипты запуска/остановки работают должным образом на всех узлах, выделенных для выполнения приложения;

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

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

Определение кластера и обнаружение или определение вручную топологии кластера. Так как HACMP содержит несколько инструментов конфигурирования, можно выбрать между "стандартным" (простым) и "расширенным" (более сложным) путем конфигурирования. Кроме того, можно выбрать между введением всех данных топологии вручную и использованием механизма обнаружения HACMP, которое упрощает конфигурирование кластера.

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

Конфигурирование ресурсов кластера. На данном этапе следует выполнить конфигурирование следующих ресурсов:

сервисные IP-адреса (метки);

серверы приложений (скрипты запуска/остановки приложений);

мониторы приложений (скрипты и действия мониторинга приложений).

Конфигурирование групп ресурсов кластера и общего хранилища. Группы ресурсов кластера являются "контейнерами", используемыми для группирования ресурсов, управляемых совместно в HACMP. Изначально группы ресурсов определяются как пустые контейнеры:

определите группы ресурсов; выполните синхронизацию кластера;

определите общее хранилище (группы томов, файловые системы, дисковые системы сторонних производителей и т. д.);

наполните группы ресурсов сервисными IP-метками, серверами приложений, группами томов, мониторами приложений.

Выполните синхронизацию кластера. Так как топология HACMP уже сконфигурирована и службы HACMP запущены, то после синхронизации кластера группы ресурсов будут подключены. Проведите оценку кластера путем проверки сообщений (консоль, /tmp/hacmp. out и т. д.).

Проведите тестирование кластера. Как только кластер достигнет стабильного (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 с любого узла в кластере.

Важно. Несмотря на распространенное мнение, что установка веб-сервера на сервере в рабочей среде может вызвать проблемы безопасности, конфигурирование через WebSMIT обеспечивает ЗАЩИЩЕННЫЙ способ администрирования кластера. WebSMIT лишь предоставляет доступ к меню HACMP SMIT (а не к SMIT в целом), а также обеспечивает аутентификацию и шифрование трафика.

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

Примечание. Так как Apache и SSL не являются продуктами компании IBM и содержат программы шифрования, на которые распространяются экспортные ограничения в США и других странах, необходимо получить пакеты в соответствии с правилами вашей страны. IBM обеспечивает возможность копирования криптографических пакетов со своего сервера, однако вы ДОЛЖНЫ зарегистрироваться на веб-сайте IBM, прежде чем вам будет предоставлен доступ для копирования. Процесс регистрации может занять до 24 ч, в зависимости от вашей географической зоны, к этому следует готовиться заранее.

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

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 в каталоге /usr/es/ sbin/cluster/wsm. Также проверяйте наличие обновленной версии этого файла на вебсайте IBM.

Следуйте файлу 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>

Примечание. В нашей среде 192.168.100.31 представляет постоянный IP-адрес, соответствующий "ha53node1" в /etc/hosts.

Затем следует подготовить файлы и каталоги 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

Примечание. При обновлении пакетов WebSMIT вам нужно будет перезапустить команды, представленные в Примере 4.4 .

Просмотрите файл /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" и что аутентификация пользователя обязательна.

Запуск веб-сервера Apache

После внесения изменений в конфигурацию можно запустить веб-сервер Apache. Рекомендуется тестировать конфигурацию перед каждым запуском сервера с использованием следующей команды:

# apachectl configtest
SYNTAX OK

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

Запустите веб-сервер Apache с опцией SSL с использованием следующей команды:

#apachectl startssl

Примечание. Если не удается запустить сервер с опцией SSL (с использованием команды apachectl start), вы не сможете получить доступ к страницам WebSMIT!

Чтобы остановить веб-сервер Apache, необходимо выполнить следующую команду:

# apachectl stop

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

Доступ к страницам WebSMIT из браузера

В результате тестирования WebSMIT была подтверждена полная поддержка его использования с Internet Explorer v5 и выше. Также поддерживаются Mozilla, Firefox и прочие браузеры на основе Gecko. Работают все функции на основе Javascript, за исключением, пожалуй, функциональных клавиш. Функции на основе Javascript не работают в Netscape Navigator v4 и ниже. (Не проводилось тестирование использования с Opera и браузерами на основе KHTML.)

Сначала нужно запустить на своем браузере WebSmit, после чего задать в нем следующий URL: https://<yourIPaddress>:42267

Появится страница, подобная изображенной на рис. 4.1:

По умолчанию доступ к WebSMIT осуществляется под учетной записью пользователя "root" (в соответствии с параметрами, заданными в файле /usr/es/sbin/cluster/wsm/wsm_ smit.conf). Этот параметр можно заменить таким образом, чтобы он указывал на любого пользователя AIX (пользователь должен существовать и иметь допустимый пароль).

(рис 4.1) Страница входа в WebSMITВнимание! Этот пользователь сможет запускать WebSMIT с правами пользователя "root", даже если у него нет таких прав в AIX.

После определения пользователей в операционной системе AIX вы можете добавлять или изменять пользователей WebSMIT в файле /usr/es/sbin/cluster/wsm/wsm_ smit.conf.

Введение в WebSMIT

После успешного входа в WebSMIT появится экран, подобный изображенному на рис. 4.2:

Основная часть окна содержит три элемента:

Cluster Status (Состояние кластера) – представляет обзор кластера и его состояния. Пример сконфигурированного и работающего кластера приведен на рис. 4.3.

Cluster Configuration and Management (Конфигурирование и управление кластером) – предоставляет доступ к инструментам конфигурирования кластера. Описывается в разделе "Меню WebSMIT: Конфигурирование и управление кластером".

Online Documentation (Электронная документация) – предоставляет доступ к системе документации HACMP (HACMP Documentation Bookshelf). Она содержит все руководства по HACMP 5.3.

(рис 4.3) Главное меню WebSMIT(рис 4.2) Состояние кластера WebSMITВажно! На странице состояния кластера также можно выполнять операции над узлами кластера, ресурсами и группами ресурсов. Обязательно прочитывайте информационные и справочные сообщения, прежде чем выполнять какие-либо действия.

Меню WebSMIT: конфигурирование и управление кластером

Меню Cluster Configuration and Management (Конфигурирование и управление кластером) предоставляет доступ к той же структуре и функциям меню, к которым предоставляет доступ и SMIT с меню HACMP. Меню WebSMIT имеют следующие преимущества в сравнении с меню SMIT:

Структурное представление ( Treeview ) дает полный структурный обзор всех меню и подменю. Кроме того, оно может использоваться в качестве навигационной панели. Можно щелкнуть мышью по пункту в Treeview, и в главном окне WebSMIT произойдет переход в соответствующее меню.

При перемещении курсора мыши над меню в главном окне выводятся всплывающие окна. Они содержат текст контекстно зависимой справки.

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

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

кнопка "Назад" ("Back") в окне браузера;

клавиша возврата (Backspace);

клавиша F3;

кнопка F3 в нижней части страницы.

Кнопка F1, показанная в нижней части страницы, выводит контекстно зависимую справку для текущей страницы. Кроме того, при перемещении курсора мыши по экрану выводится контекстно зависимая справка для каждой операции.

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

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

Можно начать с использования Two-Node Configuration Assistant для создания базовой конфигурации и затем на основании этой базовой конфигурации настроить требуемую конфигурацию. Этот сценарий обсуждается в разделе "Стандартный путь конфигурирования – Two-Node Configuration Assistant".

С другой стороны, можно сначала сконфигурировать только топологию, а затем выполнить конфигурирование всех ресурсов, групп ресурсов и т. д. через расширенные меню. Этот сценарий представлен в "Использование расширенного пути конфигурирования и C-SPOC".

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

В этой главе мы выполним конфигурирование с применением обоих сценариев в соответствии с планом, представленным на рис. 3.3.

Общие аспекты методов конфигурирования

Когда следует использовать стандартный путь конфигурирования. Использование стандартного пути конфигурирования позволяет добавлять базовые компоненты в базу данных конфигурации HACMP (ODM) за несколько простых этапов. Такой путь конфигурирования в значительной степени автоматизирует обнаружение и выбор сведений о конфигурации, а также определяет стандартные режимы работы для сетей и групп ресурсов.

Предварительные условия, предположения и параметры по умолчанию в стандартном пути:

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

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

Процесс обнаружения HACMP выполняется на всех серверных узлах, а не только на локальном узле.

Хотя при использовании стандартного пути конфигурирования требуемая информация находится на удаленных узлах, HACMP автоматически собирает необходимую информацию о кластере. При использовании стандартного пути конфигурирования обнаружение кластера выполняется автоматически.Ограничение. При использовании стандартного пути конфигурирования нельзя выбрать перехват IP-адреса посредством замены. Эти параметры необходимо задавать в расширенном пути конфигурирования (Extended Configuration path).

HACMP предполагает, что все сетевые интерфейсы в физической сети относятся к одной сети HACMP.

В качестве имен узлов используются имена хостов.

HACMP использует IP-синонимы по умолчанию.

Осуществляется конфигурирование групп ресурсов с политиками запуска, перемещения при сбое и возврата после восстановления (без настройки политик таймеров возврата после восстановления).

Стандартный путь конфигурирования позволяет задавать скрипты запуска и остановки приложений, однако скрипты мониторинга приложений можно внедрить только при использовании расширенного пути конфигурирования (Extended Configuration path).

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

Использование опций в меню расширенного конфигурирования позволяет добавлять в базу данных конфигурации HACMP основные компоненты кластера, а также дополнительные типы режимов работы и ресурсов. Расширенный путь конфигурирования (Extended Configuration path) следует использовать для настройки тех компонентов, политик и опций кластера, которые не реализованы в меню Initialization (Инициализация) и Standard Configuration (Стандартное конфигурирование).

Расширенный путь конфигурирования (Extended Configuration path) следует использовать в следующих ситуациях:

если нужно, чтобы имя узла отличалось от имени хоста;

если требуется использовать IPAT посредством замены;

если нужно добавить или изменить IP-сеть;

если нужно добавить или изменить сети, отличные от IP, и устройства;

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

если требуется задать политики таймеров возврата после восстановления для групп ресурсов;

если нужно добавить или изменить конфигурацию кластера, когда один из узлов недоступен, и т. д.

Постоянные IP-адреса

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

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

Возможный сценарий назначения постоянных IP-адресов см. на рис. 4.4. Чтобы изменить базовые IP-адреса адаптера, нужно подключиться к узлам либо через системную консоль, либо через telnet с использованием интерфейса, который не подвергнется этому изменению. В данном случае следует на узле ha53node1 использовать интерфейс en1 ( IP-метка = ha53node1b ) либо на узле ha53node2 использовать интерфейс en0 ( IP-метка = ha53node2a ).

(рис 4.4) Назначение постоянных IP-адресов

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

# netstat -i

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

#smitty
->Communications Applications and Services
 ->TCP/IP
  ->Further Configuration
   ->Network Interfaces
    ->Network Interface Selection
     ->Change / Show Characteristics of a Network Interface

Выберите интерфейс, который требуется изменить. Возникнет экран, подобный представленному на рис. 4.5.

На экране SMIT, показанном на рис. 4.5, удалите значения полей INTERNET ADDRESS (dotted decimal) и NETWORK MASK (hexadecimal or dotted decimal). Установите в поле Current STATE значение down или detached. Чтобы убедиться в том, что состояние интерфейса было изменено на down или на detached, нужно выполнить следующую команду:

#netstat -i

Вполне возможно, что это изменение приведет к потере маршрута по умолчанию. Мы выполним конфигурирование маршрутизации позже. Войдите в тот же экран SMIT, который показан на рис. 4.5. Можно использовать быстрый путь smitty chinet. Смените интерфейс и назначьте для него базовый адрес,

(рис 4.5) Изменение IP-адреса интерфейса

связанный с HACMP, через поля INTERNET ADDRESS и NETWORK MASK. Установите в поле Current STATE значение up.

Добавьте постоянную IP-метку:

#smitty
->Communications Applications and Services
 ->TCP/IP
  ->Further Configuration
   ->Network Interfaces
    ->Network Interface Selection
     ->Configure Aliases (select your IP version - we use IPV4)
      ->Add an IPV4 Network Alias

Выберите сетевой интерфейс, для которого следует назначить синоним. Скорее всего, этим интерфейсом будет интерфейс, на котором находится второй базовый адрес HACMP. Введите значения полей INTERNET ADDRESS и NETWORK MASK.

Проверьте наличие маршрута по умолчанию:

#netstat -rn (или lsattr -El inet0)

Если путь по умолчанию отсутствует, добавьте его с использованием следующей команды:

# mkdev -l inet0

SMIT-панели, связанные с HACMP, и их структура

Использование WebSMIT позволяет отображать структуру (дерево) SMIT-меню, связанных с HACMP. Каждый треугольник указывает на наличие как минимум одного подменю. Это представлено на рис. 4.6.

(рис 4.6) Структура меню, связанных с HACMP, в WebSMIT (фрагмент)

Стандартный путь конфигурирования – Two-Node Configuration Assistant

Сначала мы выполним настройку очень простой топологии кластера с использованием WebSMIT. Мы применим инструмент Two-Node Cluster Configuration Assistant, в котором для базового конфигурирования кластера нужно будет ответить на пять вопросов. На этом этапе уже должна быть настроена сетевая конфигурация, конфигурация LVM и скрипты запуска и остановки приложений.

Эти пять элементов перечислены ниже.

путь для связи с резервным узлом;

имя сервера приложений;

скрипт запуска сервера приложений;

скрипт остановки сервера приложений;

сервисная IP-метка.

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

Чтобы обеспечить требуемые результаты при использовании стандартного пути установки с применением Two-Node Configuration Assistant, необходимо выполнить следующие приготовления, прежде чем приступить к конфигурированию.

Конфигурирование сети

При подготовке постоянных IP-меток в разделе "Постоянные IP-адреса" уже было выполнено конфигурирование базовых сетей. Для запуска Two Node Configuration Assistant этого достаточно. Все остальное будет добавлено позднее.

Конфигурирование хранилища

Чтобы использовать Two Node Configuration Assistant, все, что касается групп томов, логических томов и файловых систем, должно быть сконфигурировано предварительно.

Примечание. Если у вас уже есть группы томов (содержащие логические тома и файловые системы), сконфигурированные на внешних дисках, то, даже если они не будут связаны с приложением, интеграцию которого вы собираетесь выполнить, Two Node Configuration Assistant обнаружит эти группы томов и будет их использовать в составе кластера.

Ниже приведена процедура, которой мы рекомендуем придерживаться (см. далее соответствующие разделы настоящей работы).

Проверка конфигурации.

Создание группы томов с расширенным одновременным доступом.

Создание логического тома журнала для этой группы томов.

Создание требуемого количества логических томов.

Создание файловых систем для каждого определенного логического тома.

Подключение файловых систем.

Проверка отсутствия другого логического тома журнала.

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

Деактивизация группы томов.

Импорт группы томов на другом узле с последующей верификацией.

Подключение всех файловых систем.

Документирование неподдерживаемых команд (varyonvg -c -P xxxx).

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

Проверка конфигурации

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

Для этого следует выполнить следующую команду на обоих узлах:

# lspv

Сравните выходные данные на обоих узлах, чтобы убедиться в том, что обе стороны видят одни и те же не назначенные в группы томов физические тома с одинаковым идентификатором физического тома (physical volume identifier, PVID).

Если вы не видите PVID для hdisk, следует запустить следующую команду на всех узлах, прежде чем выполнять дальнейшие операции:

# chdev -l hdiskX -a pv=yes

Примечание. Все общие диски должны иметь одинаковый назначенный PVID. В противном случае вы не сможете создавать компоненты LVM.

Создание группы томов с расширенным одновременным доступом

Мы рекомендуем использовать в качестве общих групп томов только группы томов с расширенным одновременным доступом.

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

Группа томов с расширенным одновременным доступом используется как для общих групп ресурсов (без совместного доступа), так и для групп ресурсов с совместным доступом. Таким образом, группа томов может работать либо в режиме одновременного доступа (Concurrent mode), либо в общем режиме (Shared mode). Группа томов с возможностью одновременного доступа применяться в группах ресурсов с одновременным доступом под управлением HACMP и RSCT. Если группа томов с возможностью одновременного доступа используется в группе ресурсов без одновременного доступа, она предоставляет дополнительные возможности:

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

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

Примечание. Не рекомендуется активизировать группы томов с расширенным одновременным доступом вручную. Эту задачу должен координировать HACMP.

Для конфигурирования группы томов следует использовать SMIT:

#smitty mkvg

После этого появится экран, представленный на рис. 4.7:

Убедитесь в том, что в поле Activate volume group AUTOMATICALLY at system restart? (Установить автоматическую активацию группы томов при перезапуске системы?) установлено значение No.

(рис 4.7) Определение группы томов с использованием SMIT

Если вы планируете использовать NFS для экспорта каталогов, расположенных в файловых системах, определенных в этой группе томов, следует также убедиться в том, что на всех узлах кластера установлено одинаковое уникальное значение параметра Volume Group MAJOR NUMBER (Старший номер группы томов).

При этом не происходит немедленной активизации группы томов. Для активизации следует выполнить команду

# varyonvg app2vg

Создание логического тома журнала для этой группы томов

Мы рекомендуем вручную создать выделенный логический том для журналов JFS или JFS2. В этом случае вы сможете выбрать имя и расположение логического тома.

Важно! Встроенные журналы для общих файловых систем JFS2 НЕ поддерживаются в HACMP.

Для определения логического тома используется команда

# smitty mklv

(рис 4.8) Создание логического тома журнала

Выберите только что созданную и активизированную группу томов. В нашем примере мы будем использовать группу томов app2vg, как показано на рис. 4.8.

Для параметра Number of Logical Partitions (Количество логических разделов) обычно достаточно задать значение 1Подробнее про журналы файловых систем вы можете прочитать в документации по ОС AIX "Operating system and device management". . Убедитесь в том, что для параметра Logical volume TYPE (Тип логического тома) задано значение jfslog или jfs2log, в зависимости от ситуации.

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

# logform /dev/app2loglv

где значение параметра app2loglv должно соответствовать имени, заданному в параметре Logical Volume Name (Имя логического тома) на предыдущем этапе.

Система спросит, следует ли ликвидировать (destroy) соответствующее устройствоТо есть отформатировать журнал. , нужно ответить Yes (Да).

Создание требуемого количества логических томов

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

(рис 4.9) Создание логического тома

Создание файловых систем для каждого определенного логического тома

Используйте SMIT:

#smitty
->System Storage Management (Physical Logical Storage)
 ->File Systems
  ->Add /Change / Show Delete File Systems
   ->Enhanced Journaled File Systems
    ->Add a Enhanced Journaled File Systems on a Previously
     Defined Logical volume

Создайте все файловые системы на соответствующих логических томах, как показано на рис. 4.10.

(рис 4.10) Создание файловых систем на предварительно определенных логических томах

Убедитесь в том, что в поле Mount AUTOMATICALLY at system restart (Осуществлять ли подключение при перезапуске системы?) установлено значение No.

Подключение файловых систем

Нужно выполнить подключение всех файловых систем командой

# mount /app2

Проверка отсутствия другого логического тома журнала

Теперь нужно убедиться в том, что используется созданный вами логический том журнала (см. пример 4.6 ).

root@ha53node1:/>
root@ha53node1:/> mount /app2
root@ha53node1:/> lsvg -l app2vg
app2vg:
LV NAME	 	TYPE 	LPs 	PPs 	PVs 	LV 	STATE 	MOUNT 	POINT
app2loglv 	jfs2log 1 	1 	1 	open/syncd 	N/A
app2lv 		jfs2 	30 	30 	1 	open/syncd 	/app2
root@ha53node1:/>

Отключение всех файловых систем в группах томов, связанных с HACMP

Нужно отключить все файловые системы, связанные с HACMP, командой

# umount /app2

Деактивизация группы томов

Деактивизация группы томов выполняется командой

#varryoffvg app2vg

Импорт группы томов на другом узле с последующей верификацией

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

В нашем случае используется следующая команда:

# importvg -V 102 -y app2vg hdisk2

Следующий шаг состоит в том, чтобы активизировать группу томов:

# varyonvg app2vg

Подключение всех файловых систем

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

# mount /app2
# lsvg -l app2vg

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

# varyoffvg app2vg

Подготовка приложения

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

Скрипт запуска запускает приложение.

Скрипт остановки останавливает приложениеОчевидно, третий скрипт предназначен для мониторинга приложения (опционально). .

Использование расширенного пути конфигурирования и C-SPOC

В данном сценарии мы начинаем конфигурирование кластера с обнаружения топологии кластера, после чего используем C-SPOC для последующего конфигурирования. Это вносит некоторые изменения в список действий, приведенный в разделе "Основные этапы внедрения кластера HACMP", в частности этап 4, "Конфигурирование общего хранилища", и этап 5.1, "Создайте и протестируйте скрипты запуска и остановки приложения; убедитесь в том, что приложение способно восстанавливаться после неожиданных отказов и что скрипты запуска/остановки работают должным образом на всех узлах, выделенных для выполнения приложения", выполняются после этапа 7, "Определение кластера и обнаружение или определение вручную топологии кластера".

Все последующее конфигурирование кластера выполняется через C-SPOC во время работы кластера.

Конфигурирование топологии с использованием расширенного пути конфигурирования

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

Определение кластера

#smitty
->Communications Applications and Services
 ->HACMP for AIX
  ->Extended Configuration
   ->Extended Topology Configuration
    ->Configure an HACMP Cluster
     ->Add/Change/Show an HACMP Cluster

Выберите имя своего кластера.

Добавление узлов в кластер

После определения имени кластера следует добавить узлы и путь для связи (IP-адрес, назначаемый доступному сетевому интерфейсу) для каждого узла:

#smitty
 ->Communications Applications and Services
  ->HACMP for AIX
   ->Extended Configuration
    ->Extended Topology Configuration
     ->Configure HACMP Nodes

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

Добавление сетей (IP и отличных от IP)

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

#smitty
->Communications Applications and Services
->HACMP for AIX
->Extended Configuration
->Extended Topology Configuration
->Configure HACMP Networks

Выберите Add a Network (Добавить сеть). Система запросит у вас тип сети. Проверьте, соответствует ли ваш тип перечисленным в разделе Discovered IP-based Network Types (Обнаруженные типы IP-сетей), и если это не так, выберите требуемый тип в разделе Pre-defined IP-based Network Types (Предопределенные типы IP-сетей). После этого появится экран, представленный на рис. 4.11.

(рис 4.11) Добавление IP-сети

В этом меню можно указать, что не требуется применять метод перехвата IP-адреса посредством синонимов. Если требуется использовать IPAT посредством замены, выберите Nо (Нет).

Повторите эти действия для всех сетей (IP и отличных от IP), которые требуется добавить.

Коммуникационные интерфейсы и устройства

Следующий этап состоит в том, чтобы выполнить конфигурирование коммуникационных интерфейсов/устройств (Configure Communication Interfaces/Devices). Выберите соответствующий пункт меню на экране Extended Topology Configuration (Расширенное конфигурирование топологии), на следующем экране выберите пункт Add Communication Interface/Devices (Добавить коммуникационный интерфейс/устройства), после чего выберите пункт Add Pre-defined Communication Interfaces and Devices (Добавить предопределенные коммуникационные интерфейсы и устройства) и затем выберите пункт Communication Interfaces (Коммуникационные интерфейсы). Будет выведена ранее созданная сеть. После ее выбора появится экран, представленный на рис. 4.12.

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

(рис 4.12) Добавление коммуникационных интерфейсов

Обнаружение информации HACMP со всех узлов

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

#smitty
 ->Communications Applications and Services
  ->HACMP for AIX
   ->Extended Configuration
    ->Discover HACMP related Information from Configured Nodes

При этом выполнится автоматическое обнаружение кластера (IP и не IP-сетей коммуникационных интерфейсов и устройств, общих групп томов).

Обнаруженные данные будут представлены в виде выделения для расширенной топологии и меню ресурсов.

Верификация и синхронизация кластера

На экране SMIT Extended Configuration (Расширенное конфигурирование) также представлен следующий этап.

->Extended Verification and Synchronization

После выбора этого пункта появится экран, представленный на рис. 4.13.

Выберите требуемые значения; здесь нужно выбрать значения, представленные выше.

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

(рис 4.13) Расширенная верификация и синхронизация HACMP

Конфигурирование остальных параметров через C-SPOC

Сокращение C-SPOC обозначает Cluster Single Point Of Control (Единая точка управления кластером) и является названием мощного инструмента администрирования, позволяющего выполнять изменения в конфигурации кластера с одного узла.

Примечание. Автоматическое исправление ошибок может выполняться только при полной остановке HACMP на всех узлах в кластере.

Зачем использовать C-SPOC

Как системному администратору кластера HACMP, вам может потребоваться выполнять следующие задачи, связанные с LVM:

создание новой общей группы томов;

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

создание нового общего логического тома;

увеличение, уменьшениеУменьшение размера логического тома возможно только как часть уменьшения размера файловой системы. , изменение или удаление существующего логического тома;

создание новой общей файловой системы;

увеличениеВ AIX 5.3 возможно уменьшение размера файловой системы JFS2 без ее отключения (с автоматическим уменьшением размера соответствующего логического тома). , изменение или удаление существующей файловой системы;

добавление, удаление физических томов.

C-SPOC позволяет избежать большинства распространенных отказов, связанных со стабильностью информации кластера на всех узлах.

Команды C-SPOC работают только на тех компонентах LVM с общим доступом или с одновременным доступом, которые определены как часть группы ресурсов HACMP.

При использовании SMIT HACMP C-SPOC выполнение команд происходит на узле, который является владельцем компонента LVM (узле, на котором он активизированИмеется в виду активизация (vary on) группы томов как части группы ресурсов. ).

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

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

Удаление файловой системы или логического тома

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

Обновление компонентов LVM в кластере HACMP

При изменении определения общего компонента LVM в кластере данная операция обновляет данные LVM, описывающие компонент, как на локальном узле, так и в области дескриптора группы томов (Volume Group Descriptor Area, VGDA) на дисках в группе томов. В AIX 5L LVM позволяет всем узлам в кластере получать информацию об изменениях группы томов, логического тома и файловой системы сразу же при внесении изменений, не ожидая получения этой информации во время медленных обновлений.

Нужно войти в меню Smitty C-SPOC следующим образом:

#smitty
 ->Communications Applications and Services
  ->HACMP for AIX
   ->System Management (C-SPOC)

Появится экран, представленный на рис. 4.14.

(рис 4.14) Главное меню C-SPOC

Страницы:

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

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

установка оборудования pSeries (стойки, источники питания, консоль управления оборудованием HMC и т. д.);

конфигурирование разделов (где применимо);

подключение компьютеров к локальной сетевой среде;

подключение компьютеров к хранилищу (SAN).

конфигурирование локальной сетевой среды (конфигурирование TCP/IP – интерфейсы, разрешение имен и т. д.);

конфигурирование пользователей, групп, аутентификации и т. д.

Конфигурирование общего хранилища. Может включать (в зависимости от используемой подсистемы хранения):

конфигурирование драйверов устройства хранения и многопутевых расширений (если применимо);

конфигурирование соответствия логического хранилища физическому (RAID-массивов, LUN и т. д.) и защита хранилища;

конфигурирование безопасности хранения (маскирование LUN, разделение SAN на зоны) – там, где применимо;

Конфигурирование ресурсов кластера. На данном этапе следует выполнить конфигурирование следующих ресурсов:

сервисные IP-адреса (метки);

серверы приложений (скрипты запуска/остановки приложений);

мониторы приложений (скрипты и действия мониторинга приложений).

определите группы ресурсов; выполните синхронизацию кластера;

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

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

установка пакета HACMP WebSMIT;

подготовка платформы – установка Apache и обязательных пакетов;

конфигурирование защищенного доступа на веб-сервере Apache;

конфигурирование WebSMIT и документирование;

верификация и запуск страниц WebSMIT;

конфигурирование и обслуживание кластера HACMP.

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

Прежде чем начать, следует просмотреть последний файл 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.

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.

# installp -qacXgd rpm.rte

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

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

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

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

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

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

аутентификацию пользователей (пользователей операционной системы);

протокол Secure HTTP (HTTPS), чтобы избежать передачи открытым текстом, например при передаче паролей пользователей.

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

NameVirtualHost 192.168.100.31:42267
<VirtualHost 192.168.100.31:42267>

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

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

Примечание. В нашей среде 192.168.100.31 представляет постоянный IP-адрес, соответствующий "ha53node1" в /etc/hosts.

Затем следует подготовить файлы и каталоги 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

Примечание. При обновлении пакетов WebSMIT вам нужно будет перезапустить команды, представленные в Примере 4.4 .

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

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

Запуск веб-сервера Apache

# apachectl configtest
SYNTAX OK

Запустите веб-сервер Apache с опцией SSL с использованием следующей команды:

#apachectl startssl

Чтобы остановить веб-сервер Apache, необходимо выполнить следующую команду:

# apachectl stop

Доступ к страницам WebSMIT из браузера

Сначала нужно запустить на своем браузере WebSmit, после чего задать в нем следующий URL: https://<yourIPaddress>:42267

Появится страница, подобная изображенной на рис. 4.1:

Введение в WebSMIT

После успешного входа в WebSMIT появится экран, подобный изображенному на рис. 4.2:

Основная часть окна содержит три элемента:

Меню WebSMIT: конфигурирование и управление кластером

кнопка "Назад" ("Back") в окне браузера;

клавиша возврата (Backspace);

клавиша F3;

кнопка F3 в нижней части страницы.

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

Общие аспекты методов конфигурирования

Предварительные условия, предположения и параметры по умолчанию в стандартном пути:

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

Процесс обнаружения HACMP выполняется на всех серверных узлах, а не только на локальном узле.

HACMP предполагает, что все сетевые интерфейсы в физической сети относятся к одной сети HACMP.

В качестве имен узлов используются имена хостов.

HACMP использует IP-синонимы по умолчанию.

Расширенный путь конфигурирования (Extended Configuration path) следует использовать в следующих ситуациях:

если нужно, чтобы имя узла отличалось от имени хоста;

если требуется использовать IPAT посредством замены;

если нужно добавить или изменить IP-сеть;

если нужно добавить или изменить сети, отличные от IP, и устройства;

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

если требуется задать политики таймеров возврата после восстановления для групп ресурсов;

если нужно добавить или изменить конфигурацию кластера, когда один из узлов недоступен, и т. д.

Постоянные IP-адреса

(рис 4.4) Назначение постоянных IP-адресов

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

# netstat -i

#smitty
->Communications Applications and Services
 ->TCP/IP
  ->Further Configuration
   ->Network Interfaces
    ->Network Interface Selection
     ->Change / Show Characteristics of a Network Interface

Выберите интерфейс, который требуется изменить. Возникнет экран, подобный представленному на рис. 4.5.

#netstat -i

(рис 4.5) Изменение IP-адреса интерфейса

связанный с HACMP, через поля INTERNET ADDRESS и NETWORK MASK. Установите в поле Current STATE значение up.

Добавьте постоянную IP-метку:

#smitty
->Communications Applications and Services
 ->TCP/IP
  ->Further Configuration
   ->Network Interfaces
    ->Network Interface Selection
     ->Configure Aliases (select your IP version - we use IPV4)
      ->Add an IPV4 Network Alias

Проверьте наличие маршрута по умолчанию:

#netstat -rn (или lsattr -El inet0)

Если путь по умолчанию отсутствует, добавьте его с использованием следующей команды:

# mkdev -l inet0

SMIT-панели, связанные с HACMP, и их структура

(рис 4.6) Структура меню, связанных с HACMP, в WebSMIT (фрагмент)

Стандартный путь конфигурирования – Two-Node Configuration Assistant

Эти пять элементов перечислены ниже.

путь для связи с резервным узлом;

имя сервера приложений;

скрипт запуска сервера приложений;

скрипт остановки сервера приложений;

сервисная IP-метка.

Конфигурирование сети

Конфигурирование хранилища

Проверка конфигурации.

Создание группы томов с расширенным одновременным доступом.

Создание логического тома журнала для этой группы томов.

Создание требуемого количества логических томов.

Создание файловых систем для каждого определенного логического тома.

Подключение файловых систем.

Проверка отсутствия другого логического тома журнала.

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

Деактивизация группы томов.

Импорт группы томов на другом узле с последующей верификацией.

Подключение всех файловых систем.

Документирование неподдерживаемых команд (varyonvg -c -P xxxx).

Проверка конфигурации

Для этого следует выполнить следующую команду на обоих узлах:

# lspv

# chdev -l hdiskX -a pv=yes

Создание группы томов с расширенным одновременным доступом

Для конфигурирования группы томов следует использовать SMIT:

#smitty mkvg

После этого появится экран, представленный на рис. 4.7:

(рис 4.7) Определение группы томов с использованием SMIT

При этом не происходит немедленной активизации группы томов. Для активизации следует выполнить команду

# varyonvg app2vg

Создание логического тома журнала для этой группы томов

Важно! Встроенные журналы для общих файловых систем JFS2 НЕ поддерживаются в HACMP.

Для определения логического тома используется команда

# smitty mklv

(рис 4.8) Создание логического тома журнала

# logform /dev/app2loglv

Создание требуемого количества логических томов

(рис 4.9) Создание логического тома

Создание файловых систем для каждого определенного логического тома

Используйте SMIT:

#smitty
->System Storage Management (Physical Logical Storage)
 ->File Systems
  ->Add /Change / Show Delete File Systems
   ->Enhanced Journaled File Systems
    ->Add a Enhanced Journaled File Systems on a Previously
     Defined Logical volume

Создайте все файловые системы на соответствующих логических томах, как показано на рис. 4.10.

(рис 4.10) Создание файловых систем на предварительно определенных логических томах

Подключение файловых систем

Нужно выполнить подключение всех файловых систем командой

# mount /app2

Проверка отсутствия другого логического тома журнала

Теперь нужно убедиться в том, что используется созданный вами логический том журнала (см. пример 4.6 ).

root@ha53node1:/>
root@ha53node1:/> mount /app2
root@ha53node1:/> lsvg -l app2vg
app2vg:
LV NAME	 	TYPE 	LPs 	PPs 	PVs 	LV 	STATE 	MOUNT 	POINT
app2loglv 	jfs2log 1 	1 	1 	open/syncd 	N/A
app2lv 		jfs2 	30 	30 	1 	open/syncd 	/app2
root@ha53node1:/>

Отключение всех файловых систем в группах томов, связанных с HACMP

Нужно отключить все файловые системы, связанные с HACMP, командой

# umount /app2

Деактивизация группы томов

Деактивизация группы томов выполняется командой

#varryoffvg app2vg

Импорт группы томов на другом узле с последующей верификацией

В нашем случае используется следующая команда:

# importvg -V 102 -y app2vg hdisk2

Следующий шаг состоит в том, чтобы активизировать группу томов:

# varyonvg app2vg

Подключение всех файловых систем

# mount /app2
# lsvg -l app2vg

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

# varyoffvg app2vg

Подготовка приложения

Скрипт запуска запускает приложение.

Использование расширенного пути конфигурирования и C-SPOC

Все последующее конфигурирование кластера выполняется через C-SPOC во время работы кластера.

Конфигурирование топологии с использованием расширенного пути конфигурирования

Определение кластера

#smitty
->Communications Applications and Services
 ->HACMP for AIX
  ->Extended Configuration
   ->Extended Topology Configuration
    ->Configure an HACMP Cluster
     ->Add/Change/Show an HACMP Cluster

Выберите имя своего кластера.

Добавление узлов в кластер

#smitty
 ->Communications Applications and Services
  ->HACMP for AIX
   ->Extended Configuration
    ->Extended Topology Configuration
     ->Configure HACMP Nodes

Добавление сетей (IP и отличных от IP)

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

#smitty
->Communications Applications and Services
->HACMP for AIX
->Extended Configuration
->Extended Topology Configuration
->Configure HACMP Networks

(рис 4.11) Добавление IP-сети

Повторите эти действия для всех сетей (IP и отличных от IP), которые требуется добавить.

Коммуникационные интерфейсы и устройства

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

(рис 4.12) Добавление коммуникационных интерфейсов

Обнаружение информации HACMP со всех узлов

#smitty
 ->Communications Applications and Services
  ->HACMP for AIX
   ->Extended Configuration
    ->Discover HACMP related Information from Configured Nodes

Обнаруженные данные будут представлены в виде выделения для расширенной топологии и меню ресурсов.

Верификация и синхронизация кластера

На экране SMIT Extended Configuration (Расширенное конфигурирование) также представлен следующий этап.

->Extended Verification and Synchronization

После выбора этого пункта появится экран, представленный на рис. 4.13.

Выберите требуемые значения; здесь нужно выбрать значения, представленные выше.

(рис 4.13) Расширенная верификация и синхронизация HACMP

Конфигурирование остальных параметров через C-SPOC

Зачем использовать C-SPOC

создание новой общей группы томов;

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

создание нового общего логического тома;

создание новой общей файловой системы;

добавление, удаление физических томов.

Удаление файловой системы или логического тома

Обновление компонентов LVM в кластере HACMP

Нужно войти в меню Smitty C-SPOC следующим образом:

#smitty
 ->Communications Applications and Services
  ->HACMP for AIX
   ->System Management (C-SPOC)

Появится экран, представленный на рис. 4.14.

(рис 4.14) Главное меню C-SPOC

Занятие пройдено

Предыдущее занятие Занятие пройдено Следующее занятие

Вернуться к учебному плану

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

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

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

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

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

Запуск веб-сервера Apache

Доступ к страницам WebSMIT из браузера

Введение в WebSMIT

Меню WebSMIT: конфигурирование и управление кластером

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

Стандартный путь конфигурирования – Two-Node Configuration Assistant

Использование расширенного пути конфигурирования и C-SPOC

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

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

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

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

Запуск веб-сервера Apache

Доступ к страницам WebSMIT из браузера

Введение в WebSMIT

Меню WebSMIT: конфигурирование и управление кластером

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

Стандартный путь конфигурирования – Two-Node Configuration Assistant

Использование расширенного пути конфигурирования и C-SPOC

Купить дополнительную попытку

Вы действительно хотите купить ещё одну попытку для прохождения тестирования?

Успешно!

Напишите нам, если у вас есть вопросы

Уважаемые пользователи ИНТУИТ!

Уважаемые пользователи ИНТУИТ!

Добро пожаловать на обновлённый сайт НОУ «ИНТУИТ»!