 | Уровень сложности: средний Махеш Вишванатан, ведущий технический специалист, IBM
Сурадж Субраманьян, ведущий архитектор интеграции решений, IBM
19.05.2009 В этой статье описывается реализация высокой готовности (high availability) составного приложения на
основе продукта Linux-HA. Обеспечение высокой готовности составных приложений может быть сложной задачей.
Конфигурация системы усложнена из-за того, что составные приложения состоят из отдельных приложений, каждое со
своими требованиями к готовности. В этой статье авторы расскажут о проектировании и реализации подобной системы на примере
прототипа составного приложения Tivoli® Maximo®.
В их конфигурационном скрипте показано, как можно обеспечить высокую готовность неоднородного кластера взаимосвязанных
приложений с помощью системной, учитывающей приоритеты, процедуры аварийного переключения.
В 2008 году мы разработали решение высокой готовности для нашей реализации CMDB (базы данных управления конфигурацией),
Tivoli Maximo и менеджера обнаружения зависимостей приложения Tivoli (Tivoli Application Dependency Discovery Manager) для
большой сетевой компании. Эта компания начинала проект по работе с полноценной реализацией CCMDB (базы данных управления
изменениями и конфигурацией) для Maximo (нынешнее название - Tivoli Service Request Manager and Tivoli Asset Manager for IT),
включающий в себя один для всей компании продукт Maximo (версию CCMDB). Перед нами стояла цель использовать множество доменных
приложений CMDB для сбора информации из различных подразделений компаний и агрегировать эту информацию в единую базу CMDB.
Данные из этой единой базы CMDB фильтровались и накапливались в базе CCMDB (Maximo).
Maximo хранит как эталонное состояние CMDB (каким оно должно быть) предприятия в соответствии с предустановленными политиками,
так и реальное состояние (что есть на самом деле), представляемое на основе информации, собираемой с тысяч серверов и приложений,
развернутых по всей корпорации.
Вообще говоря, различным функциональным узлам иерархии высокой готовности (HA или high avaialbility)
нужна различная архитектура HA. Например, серверы доступа (gateway) - это обычно Windows®-машины,
для которых требуется MSCS. Доменные приложения CMDB нуждаются в HA, но при этом допустимо и холодное резервирование (cold standby).
Однако Maximo должен был быть доступен в режиме 24/7, кроме того, и Maximo, и единая CMDB соединялись каждый
со своей собственной базой данных - которые в норме тоже являлись бы членами кластера. Однако в этом прототипе мы
сконцентрировались только на высокой готовности приложений. Наш проект показан на рисунке 1.
Рисунок 1. Решение высокой готовности с системой восстановления после
аварий (DR - disaster recovery) для Maximo и менеджера обнаружения зависимостей приложений Enterprise Tivoli:
два кластера высокой готовности из четырех узлов
В этой статье мы расскажем о методе управления отказоустойчивым неоднородным кластером узлов со многими приложениями.
Каждое приложение внутри нашего кластера имеет свои требования к отказоустойчивости, что, конечно же, делает наше решение
сложнее решений высокой готовности для приложений одного класса, например, баз данных.
В нашем решении мы должны были разработать алгоритм действий (протокол) для случая одного или двух последовательных
отказов приложений (узлов) внутри отказоустойчивого кластера. В этом протоколе для каждого узла приложений в кластере
была разработана точная процедура аварийного восстановления. Эти процедуры учитывают ситуации, когда происходит
снижение производительности до неприемлемого уровня и случаи, когда несколько приложений не могут быть запущены
на одной машине из-за конфликтов времени выполнения.
Подробности архитектуры и реализации решения:
- Из трех работающих в кластере приложений (Enterprise
CMDB, ITIC и Maximo) наибольший приоритет имеет Maximo. Поэтому независимо от того, на каком узле произошел отказ, Maximo
должен оставаться доступным для клиентов (клиентские машины работают с API, предоставляемым Maximo).
- Мы развернули систему автоматического аварийного переключения с несбалансированными весами узлов,
так что при восстановлении отказавшего узла приложение автоматически возвращается на него.
- Согласно спецификации, система должна уметь справляться с двумя отказами в кластере, однако для CCMDB (Maximo) мы смогли
спроектировать и реализовать полную готовность даже после трех отказов.
- Изначально мы не планировали использовать в нашей системе кворум-сервер, но нам пришлось это сделать.
- Было довольно сложно настроить Linux®-HA для работы в соответствии со строгими правилами обработки
ситуаций отказа
в случае одного, двух или трех отказов.
- Мы скопировали эту архитектуру на резервную систему, предназначенную для аварийного восстановления
(disaster recovery или DR) - удаленное зеркало на рисунке 1. Внутри каждой системы аварийное переключение
происходит автоматически, а между системами (в случае катастрофической аварии) - вручную.
- Для оптимизации использования машин и поддержки отказоустойчивости мы предусмотрели в нашем кластере четыре узла: по одному
узлу на приложение и один резервный узел, предназначенный для использования в случаях отказа.
Традиционно архитектура HA используется для одиночных приложений, таких как база данных или Web сервер.
В нашем примере мы покажем, как добиться высокой готовности составных приложений, подобных CCMDB,
которое состоит из трех отдельных компонентов:
- Менеджер обнаружения зависимостей приложения Tivoli (TADDM): помогает автоматизировать управление
ИТ-услугами, обеспечивая обнаружение конфигураций и зависимостей приложений.
- Интегратор IBM Tivoli (IBM Tivoli Integration Composer или ITIC): способствует быстрой интеграции системы управления активами
для ИТ с инструментами учета активов и управления системой.
- Maximo: обеспечивает для всех типов активов понятное, основанное на единой платформе, управление их жизненным циклом
и эксплуатацией.
Установка пакета
HA
Установка Linux-HA - это простой и прямолинейный процесс (скачать пакет можно по ссылке в разделе Ресурсы).
Убедитесь, что в вашей системе установлены все патчи, необходимые, чтобы начать установку сервиса heartbeat. Для нашего примера
мы использовали Linux-HA версии 2.1.4.
После завершения установки обязательно нужно перезагрузить машину. Выполните шаги, показанные в листинге 1 на всех четырех машинах,
которые будут составлять этот кластер.
Листинг 1. Установка HA
[root@hacluster2 tmp]# rpm -ivh perl-TimeDate-1.16-3_2.0.el5.noarch.rpm
warning: perl-TimeDate-1.16-3_2.0.el5.noarch.rpm: Header V3 DSA signature:
NOKEY, key ID 66534c2b
Preparing ... ########################################### [100%]
1:perl-TimeDate ########################################### [100%]
[root@hacluster2 tmp]# rpm -ivh heartbeat-pils-2.1.4-2.1.i386.rpm
warning: heartbeat-pils-2.1.4-2.1.i386.rpm: Header V3 DSA signature:
NOKEY, key ID 1d326aeb
Preparing ... ########################################### [100%]
1:heartbeat-pils ########################################### [100%]
[root@hacluster2 tmp]# rpm -ivh heartbeat-stonith-2.1.4-2.1.i386.rpm
warning: heartbeat-stonith-2.1.4-2.1.i386.rpm: Header V3 DSA signature:
NOKEY, key ID 1d326aeb
Preparing ... ########################################### [100%]
1:heartbeat-stonith ########################################### [100%]
[root@hacluster2 tmp]# rpm -ivh heartbeat-2.1.4-2.1.i386.rpm
warning: heartbeat-2.1.4-2.1.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1d326aeb
Preparing ... ########################################### [100%]
1:heartbeat ########################################### [100%]
[root@hacluster2 tmp]#
|
 |
Настройка
HA
Теперь надо создать файл /etc/ha.d/ha.cf, в котором содержится информация о том, из каких узлов состоит наша система.
Создайте файл ha.cf на машине, выделенной в системе как координатор (designated
coordinator или DC). Скопируйте этот файл и файл authkeys на другие машины с помощью FTP или SCP. Так как наш кластер
состоит из четырех узлов
(три узла приложений и один свободный), наш файл ha.cf будет выглядеть примерно так:
Листинг 2. ha.cf - файл конфигурации НА
node hacluster1.svl.ibm.com hacluster2.svl.ibm.com hacluster3.svl.ibm.com
hacluster4.svl.ibm.com
bcast eth0
crm on
|
Директивы (параметры) в листинге 2:
-
node перечисляет узлы, составляющие этот кластер.
-
bcast указывает интерфейс, через который будет осуществляться сообщение и пинг между узлами.
-
crm определяет, должен ли сервис heartbeat запускать менеджер кластера, который поддерживает
два или более узлов.
В листинге 2 мы указали имена машин, входящих в наш кластер. Теперь нам надо добавить ключ
аутентификации в файл /etc/ha.d/authkeys. В листинге 3 показан пример, который мы использовали:
Листинг 3. Пример файла аутентификации authkeys
#
# Authentication file. Must be mode 600
#
#
# Must have exactly one auth directive at the front.
# auth sne authentication using this method-id
#
# Then, list the method and key that go with that method-id
#
# Available methods: crc sha1, md5. Crc doesn't need/want a key.
#
# You normally only have one authentication method-id listed in this file
#
# Put more than one to make a smooth transition when changing wuth
# methods and/or keys.
#
#
# sha1 is believed to be the "best", md5 next best.
#
# crc adds no security, except from packet corruption.
# Use only on physically secure networks.
#
auth 1
1 sha1 haclusteringisfun
|
Замечание: права на этот файл должны быть выставлены в 0600. После создания этих файлов можно запустить сервис heartbeat с помощью
команды
/etc/init.d/heartbeat start.
Запустите на всех машинах кластера команду, показанную в листинге 4:
Листинг 4. Запуск сервиса высокой готовности (High-Availability)
[root@hacluster1 heartbeat]# /etc/init.d/heartbeat start
Starting High-Availability services:
[ OK ]
[root@hacluster1 heartbeat]#
|
Если вы видите это сообщение, значит вы успешно установили Linux-HA. Теперь пришло время проверить высокую готовность
нашего составного приложения.
Добавляем кворум-сервер
В кластере, состоящем из двух узлов, в случае отказа одного из узлов или проблем с сетевым соединением каждый из узлов
считает себя главным и начинает взаимодействовать с внешним миром (от имени всего кластера). Возникает потенциально
конфликтная ситуация,
что, конечно же, нежелательно. Нам нужен независимый внешний арбитр, чтобы попросить одну из машин остановиться.
Если на одной из машин происходит сбой, арбитр исключает эту машину из кластера. Этот арбитр называется
кворум-сервером; им может служить любая машина, к которой имеют доступ оба узла кластера. Кворум-сервер называется
так потому, что на нем работает демон quorum. На всех узлах добавьте в файл ha.cf следующую строку:
Листинг 5. Указываем кворум-сервер в файле ha.cf
cluster ourcmdb
quorum_server hacluster4.svl.ibm.com
|
На кворум-сервере необязательно должен быть запущен сервис heartbeat, однако мы все же рекомендуем его установить,
чтобы получить доступ ко всем двоичным файлам и директориям, создающимся во время установки (таким как /etc/ha.d). Добавьте на кворум-сервере в файл
/etc/ha.d/quorumd.conf следующие строки:
Листинг 6. Настройка кворум-сервера
cluster ourcmdb
version 2_1_4
interval 1000
timeout 5000
takeover 3000
giveup 2000
|
Затем запустите кворум-демон с помощью команды quorumd. Нужно, чтобы он запускался автоматически каждый
раз при
перезапуске машины; для этого добавьте его в inetd.
Linux-HA использует конфигурационный файл cib.xml, который создается на каждом узле кластера автоматически при запуске
сервиса heartbeat. В этом файле хранится конфигурация приложения (описывающая, какие приложения, согласно правилам отказоустойчивости,
имеют более высокий приоритет).
Файл cib.xml можно изменять с помощью графического инструмента
/usr/bin/hb_gui (рекомендуется) или вручную.
Файл cib.xml содержит следующую информацию:
- Информация о конфигурации:
- информация об узлах кластера
- информация о ресурсах
- информация об ограничениях на
ресурсы
- Статусная информация:
- какие узлы включены/выключены
- атрибуты узлов
- какие ресурсы где запущены
Поскольку файл cib.xml контролируется процессом heartbeat, избегайте изменения этого файла во время работы кластера.
Замечание: Права на файл cib.xml должны быть выставлены в 0600, а его владельцем должен быть пользователь haclient:hacluster.
Linux-HA поставляется вместе с набором ресурсных агентов, основанных на стандартной инфраструктуре обеспечения
высокой готовности Open Cluster Framework (OCF). Так как в нашем случае все приложения адаптировались к конкретному решению,
нам пришлось самим конструировать ресурсных агентов OCF для отдельных компонентов нашего составного приложения.
Настройка heartbeat
В листинге 7 показана конфигурация ресурсов в используемой нами версии heartbeat. Конфигурационный файл находится здесь:
/var/lib/heartbeat/crm/cib.xml. В этом файле описываются ресурсы кластера и то, где эти ресурсы должны запускаться.
Вот файл cib.xml, который мы разработали для нашего сценария (см. ссылку в разделе Ресурсы), снабженный
для удобства комментариями.
Listing 7. Конфигурация ресурсов в heartbeat версии 2
<cib generated="true" admin_epoch="0" have_quorum="true" ignore_dtd="false" num_peers="2"
ccm_transition="2" cib_feature_revision="2.0" crm_feature_set="2.0" epoch="3" dc_uuid="
ad893965-d27d-4908-a2ea-868f1661f644" num_updates="3" cib-last-written="Fri Nov 14
10:14:40 2008">
<configuration>
<crm_config>
<cluster_property_set id="cib-bootstrap-options">
<attributes/>
</cluster_property_set>
</crm_config>
<nodes> /* Имена узлов, составляющих кластер */
<node id="ad893965-d27d-4908-a2ea-868f1661f644"
uname="hacluster1.svl.ibm.com" type="normal"/> /* узел Maximo */
<node id="5994eb92-0a13-4fc7-ab41-76098672fdbb"
uname="hacluster3.svl.ibm.com" type="normal"/> /* узел ITIC */
<node id="c14b9082-5b1a-481c-930a-561e926df7c3"
uname="hacluster4.svl.ibm.com" type="normal"/> /* узел CMDB */
<node id="827b7884-06db-4d8d-994d-7e743b9bb969"
uname="hacluster2.svl.ibm.com" type="normal"/> /* резервный узел */
</nodes>
<resources>
<group id="maximo_group">
/* Назначаем базовые параметры приложения Maximo */
<primitive class="lsb" id="maximo_id" type="maximo">
<operations>
<op id="1" name="monitor" interval="10s"/>
<op id="2" name="start" start_delay="10s"/>
</operations>
<meta_attributes id="063383a7-2c60-4cf0-b3b0-a3670328c3b8">
<attributes> /* Приоритеты выставляются с помощью весовых коэффициентов.
Ими определяется то, какое приложение будет запущено на
резервном узле в случае второго последовательного сбоя. В
нашем случае порядок такой: Maximo > eCMDB > ITIC.
Заметьте, что при первом сбое отказавшее приложение всегда
переносится на резервный узел. В случае второго сбоя,
именно приоритеты приложений определяют, какое из двух
отказавших приложений будет работать на резервном узле.*/
<nvpair name="priority" value="3"
id="f0c58dd3-43bb-4a1e-86cc-8993e58ba399"/>
</attributes>
</meta_attributes>
</primitive>
</group>
<group id="iticd_group"> /* Назначаем базовые параметры приложения ITIC */
<primitive class="lsb" id="itic_id" type="iticd">
<operations>
<op id="3" name="monitor" interval="10s"/>
<op id="4" name="start" start_delay="10s"/>
</operations>
<meta_attributes id="cb35cbb3-3241-4bf6-9ab7-f06d6f5baf89">
<attributes>
<nvpair name="priority" value="2"
id="7f7a35eb-aff8-4f7d-8e4d-ec6a0414d6da"/>
</attributes>
</meta_attributes>
</primitive>
</group>
<group id="taddm_group"> /* Назначаем базовые параметры приложения eCMDB */
<primitive class="lsb" id="taddm_id" type="taddm">
<operations>
<op id="5" name="monitor" interval="10s"/>
<op id="6" name="start" start_delay="10s"/>
</operations>
<meta_attributes id="e7baab9a-1460-423f-aabd-f68137d00d42">
<attributes>
<nvpair name="priority" value="1"
id="0448d632-f8e7-4347-90bd-de8222b77bda"/>
</attributes>
</meta_attributes>
</primitive>
</group>
</resources>
<constraints>
<rsc_colocation id="not_same_1" to="maximo_group" from="iticd_group"
score="-INFINITY" symmetrical="false"/> /* Приложение Maximo не должно запускаться
на узле, предназначенном для ITIC */
<rsc_colocation id="not_same_3" to="maximo_group" from="taddm_group"
score="-INFINITY" symmetrical="false"/> /* Приложение Maximo не должно запускаться
на узле, предназначенном для eCMDB */
<rsc_colocation id="not_same_2" to="taddm_group" from="iticd_group"
score="-INFINITY" symmetrical="false"/> /* Приложение eCMDB не должно запускаться
на узле, предназначенном для ITIC */
<rsc_location id="location_maximo" rsc="maximo_group">
<rule id="prefered_location_maximo_1" score="20">
<expression attribute="#uname" operation="eq" value="hacluster2.svl.ibm.com"
id="a4b1be4e-4c25-46a6-9237-60a3b7b44389"/> /* Резервный узел для запуска
Maximo в случае отказа предпоч-
тительного узла */
</rule>
<rule id="prefered_location_maximo_2" score="100">
<expression attribute="#uname" operation="eq" value="hacluster1.svl.ibm.com"
id="3ece30c7-0530-4b54-a21b-ace9b127d3e3"/> /* Предпочтительный узел для
запуска Maximo */
</rule>
<rule id="prefered_location_maximo_3" score="-INFINITY">
<expression attribute="#uname" operation="eq" value="hacluster4.svl.ibm.com"
id="7cb3b3e2-191f-492d-84f9-257b96c02c3c"/> /* Maximo не может работать на
этом узле совместно с eCMDB */
</rule>
<rule id="prefered_location_maximo_4" score="-INFINITY">
<expression attribute="#uname" operation="eq" value="hacluster3.svl.ibm.com"
id="a78cce70-c717-4c33-910e-11cc39ded186"/> /* Maximo не может работать на
этом узле совместно с ITIC */
</rule>
</rsc_location>
<rsc_location id="location_iticd" rsc="iticd_group">
<rule id="prefered_location_iticd_1" score="20">
<expression attribute="#uname" operation="eq" value="hacluster2.svl.ibm.com"
id="e3de5eee-ee29-4e94-89d7-36fef3d76082"/> /* Резервный узел для запуска
ITIC в случае отказа предпоч-
тительного узла */
</rule>
<rule id="prefered_location_iticd_2" score="100">
<expression attribute="#uname" operation="eq" value="hacluster3.svl.ibm.com"
id="f8153d3d-f821-46e3-b41d-7e869e2960ec"/> /* Предпочтительный узел для
запуска ITIC */
</rule>
<rule id="prefered_location_iticd_3" score="-INFINITY">
<expression attribute="#uname" operation="eq" value="hacluster1.svl.ibm.com"
id="7b7e7ec4-1381-47fb-afdf-732c4b180ba6"/> /* ITIC не может работать на
этом узле совместно с Maximo */
</rule>
<rule id="prefered_location_iticd_4" score="-INFINITY">
<expression attribute="#uname" operation="eq" value="hacluster4.svl.ibm.com"
id="1fd82c28-982b-462e-b147-6726d655a87f"/> /* ITIC не может работать на
этом узле совместно с eCMDB */
</rule>
</rsc_location>
<rsc_location id="location_taddm" rsc="taddm_group">
<rule id="prefered_location_taddm_1" score="20">
<expression attribute="#uname" operation="eq" value="hacluster2.svl.ibm.com"
id="b029d8a7-5a40-481f-8ebc-1168d6d76efa"/> /* Резервный узел для запуска
eCMDB в случае отказа предпоч-
тительного узла */
</rule>
<rule id="prefered_location_taddm_2" score="100">
<expression attribute="#uname" operation="eq" value="hacluster4.svl.ibm.com"
id="2cdf690e-e9c7-464e-9148-21be25565161"/> /* Предпочтительный узел для
запуска eCMDB */
</rule>
<rule id="prefered_location_taddm_3" score="-INFINITY">
<expression attribute="#uname" operation="eq" value="hacluster1.svl.ibm.com"
id="a3065c9e-e253-4890-879f-9cf143d82fed"/> /* eCMDB не может работать на
этом узле совместно с Maximo */
</rule>
<rule id="prefered_location_taddm_4" score="-INFINITY">
<expression attribute="#uname" operation="eq" value="hacluster3.svl.ibm.com"
id="dfd2f607-a322-483d-af67-b33b6ba3556d"/> /* eCMDB не может работать на
этом узле совместно с ITIC */
</rule>
</rsc_location>
</constraints>
</configuration>
</cib>
</code>
|
|
Тестирование сценария
В приведенном здесь примере система состоит из трех приложений: трех основных и одного резервного узла. Для нашего алгоритма
мы использовали кластер из четырех машин с одинаковой аппаратной конфигурацией: по машине для Maximo, eCMDB (сокращение от
Enterprise TADDM), IC (сокращение от Integration Composer) и одна машина пассивного резерва. Кроме того, мы укомплектовали
удаленную систему набором из четырех аналогичных машин. На резервной машине может запускаться любое из трех приложений: Maximo,
eCMDB или IC. Алгоритм работает по следующей логике:
- Приложение, вышедшее из строя первым, запускается на резервном узле. Если вышедший из строя узел снова переходит в рабочее состояние,
приложение автоматически возвращается на него.
- 2. В случае второго сбоя приложение, которое будет работать на резервном узле, определяется согласно приоритету:
сначала Maximo, затем eCMDB и потом IC. Maximo - это самое важное приложение, так как предполагается, что клиентские приложения
постоянно будут обращаться к нему.
- Такой приоритет приложений установлен на обеих системах: как локальной, так и удаленной.
Нам нужен только один резервный узел для трех различных приложений. Эти приложения имеют встроенные приоритеты. Хотя все они
должны работать в режиме высокой готовности, для них установлены строгие приоритеты, которые должны признавать все машины и приложения.
Если у нас есть одно приложение, которое должно быть доступно в режиме 24x7, а ко всем остальным приложениям не предъявляется столь
строгих требований, тогда нам нужен по меньшей мере один резервный узел. Если у нас есть две машины с такими требованиями к готовности,
то нам нужно два резервных узла, и так далее. Написанное выше верно, если наши приложения не могут сосуществовать на одном резервном узле,
т.е. нет конфликтов, не позволяющих установить все три приложения на одну (резервную) машину. На рисунке 1 показан
пример кластера с тремя приложениями и четырьмя узлами. Слева находится основная система, справа - её зеркало. Зеркало используется
для восстановления после аварий в случае отказа всех четырех машин основной системы.
В приведенной ниже таблице приложения Maximo (= A), eCMDB (= B) и ITIC (= C) запускаются на отдельных машинах. Имена машин не
имеют значения, мы будем идентифицировать машины по именам приложений, которые на них запущены.
На этих машинах не запущено никаких других важных приложений, за исключением обозначенных выше. На резервной машине (= O) установлены
и Maximo, и eCMDB, и
ITIC, но в каждый момент времени работать на ней может только какое-то одно приложение.
Напомним, что согласно нашей архитектуре НА приложения имеют следующий приоритет: Maximo > eCMDB > ITIC; а узел O является
выделенным координатором (резервным узлом).
Таблица 1. Первый сбой
| Отказавшее приложение | Конфигурация приложений после первого сбоя |
|---|
| A | A => O; B; C |
|---|
| B | A; B => O; C |
|---|
| C | A; B; C => O |
|---|
| O | нет стратегии |
|---|
Рисунок 2. Первый сбой
Таблица 2. Второй сбой (A = O означает, что A
уже работает на O после первого сбоя)
| Первый сбой | Конфигурация ПЕРЕД вторым сбоем | Второй сбой | Конфигурация ПОСЛЕ второго сбоя |
|---|
| A | A => O; B; C | B | A = O; B недоступно; C; |
|---|
| | C | A = O; B; C недоступно |
|---|
| B | A; B => O; C | A | B exits; A => O; C; B недоступно |
|---|
| | C | A; B = O; C недоступно |
|---|
| C | A; B; C => O | A | C exits; A => O; B; C недоступно |
|---|
| | B | C exits; A; B => O; C недоступно |
|---|
Второй сбой, вариант 1: если отказывает А, оно перемещается на резервный узел. Если затем отказывает ITIC или eCMDB, то
ничего не произойдет. Maximo все так же будет доступен на резервном узле.
Рисунок 3. Второй сбой, вариант 1
Второй сбой, вариант 2: Если на резервном узле работает eCMDB, то при последующем отказе ITIC ничего не поменяется, если
откажет Maximo, то оно вытеснит eCMDB с резервного узла.
Рисунок 4. Второй сбой,
вариант 2
Второй сбой, вариант 3: Если на резервном узле работает ITIC, то, в случае последующего отказа, eCMDB вытеснит ITIC оттуда. А
если потом откажет и Maximo, то оно вытеснит eCMDB с резервного узла. Если в кластере не будет работать ни один узел, кроме
резервного, то Maximo будет единственным работающим приложением.
Рисунок 5. Второй сбой, вариант 3
Итоги реализации
Итак, вот каким получилось наше решение:
- Используется кластер из четырех узлов, один из которых - резервный.
- Три приложения работают на отдельных узлах.
- Приложения не могут работать вместе на одной машине (они взаимно исключают друг друга).
- В случае сбоя приложения оно будет дважды перезапущено, а затем перенесено на резервный узел.
- В случае отказа узла приложение переносится на резервный узел. При восстановлении отказавшего узла
приложение будет перенесено обратно на выделенный ему узел.
- Восстановление приложения от сбоя занимает примерно 45 секунд. Больше только для TADDM.
- Приложения перемещаются на резервный узел в порядке очереди: первый пришел/первым обслужили.
- Во всех случаях учитывается иерархия готовности: Maximo > TADDM
> ITIC.
- В случае второго сбоя узла/приложения Maximo будет оставаться доступным. Если на резервном узле уже работало ITIC или TADDM,
оно будет вытеснено оттуда в пользу Maximo.
- Чтобы убедиться, что это именно так, был выполнен полный
набор независимых тестов round-robin.
- Созданный своими руками и протестированный конфигурационный файл был настроен для реализации описанного выше поведения.
Восстановление после аварий
Система, находящаяся на удаленном узле идентична рабочей, но ни одно из приложений там не запущено. Только на общий внешний диск
с основного диска осуществляется репликация данных. При сбое основной системы предпринимаются следующие действия:
- Останавливаются все машины основной системы (включая базы данных).
- С машин основной системы снимаются назначенные им виртуальные IP-адреса (VIP).
- Управление (вручную) передается удаленной системе.
- Сетевой диск удаленной системы обозначается как главный (Master).
- Запускается сервис heartbeat с помощью нашего скрипта управления кластером (который запустит приложения в той же последовательности и с теми же приоритетами, что и на основной системе).
- Приложения синхронизируются с сетевым диском и базами данных.
- Виртуальные IP-адреса машин основной системы назначаются соответствующим машинам удаленной сети.
- Система (как и раньше) начинает отвечать на запросы клиентов.
Резюме
В этой статье описывается реализация отказоустойчивости составного приложения с помощью проекта Linux-HA, основанная на нашем опыте
и требованиях заказчика. Наша задача включала в себя обеспечение высокой готовности нескольких приложений с различными приоритетами
внутри одного кластера. Возможно, проще было бы добавить по одному резервному узлу для каждого приложения, но подобное решение не
является экономичным. В большинстве случаев при работе с HA в реальной жизни вам придется решать задачи и экономии, и обеспечения
избыточности, зачастую являющиеся взаимно исключающими.
Благодарности
Нашим консультантом и советником был Алан Робертсон, гуру проекта Linux-HA. Мы просто-напросто не смогли бы сделать эту
работу без его поддержки и великодушной помощи.
Ресурсы Научиться
- Ознакомьтесь с оригиналом
статьи (EN).
- На этом сайте представлена простая типовая конфигурация ресурсов
(на которой основан пример файла cib.xml из этой статьи). (EN)
- Узнайте больше о пакете heartbeat из
этих веб-трансляций и документов, а также обучающих
руководств.(EN)
- Обратитесь к эксперту, который познакомит вас с
API для Linux-HA Quorum,
а потом предоставит
еще
более подробную информацию по данной теме. (EN)
- На сайте стандартов OCF вы можете узнать больше об
агентах ресурсов (упомянутых в этой статье) и познакомиться с другими API открытой кластерной инфраструктуры, включающими другие
ресурсные сервисы, сервисы для узлов, групп и блокировок, а также внешние интерфейсы.(EN)
- В статье
"Set up a
Web server cluster in 5 easy steps"
(developerWorks, август 2007 г.) показано, как построить работающую систему с Linux Virtual Server и
сервисом Heartbeat от Linux-HA.org. (EN)
- В серии статей об установке
большого кластера Linux, начатой на developerWorks в декабре 2006 г., описываются кластерные вычисления в среде Linux; в первой
статье серии представлены пакеты HA и heartbeat. (EN)
- Узнайте последние новости о продуктах Tivoli от IBM. (EN)
- В основном разделе Linux и в разделе
Linux для новичков вы найдете множество ресурсов для Linux-разработчиков; также просмотрите наши самые популярные статьи и руководства (EN).
-
Ознакомьтесь с другими
советами по Linux и
учебными пособиями по Linux на сайте developerWorks.
- Следите за новостями в разделе технических мероприятий и Web-трансляций (EN) developerWorks.
Получить продукты и технологии
- Загрузите себе пакет Linux-HA: компонент CRM теперь сопровождается как независимый проект под названием Pacemaker; последним релизом с CRM был Heartbeat 2.1.4.(EN)
- Разработайте ваш следующий Linux-проект с помощью пробного ПО от IBM, которое можно загрузить непосредственно с сайта
developerWorks. (EN)
Обсудить
Об авторах | | | Махеш Вишванатан - ведущий технический специалист IBM Global
Technology Services. Он является главным архитектором проекта
Express Remote Managed Infrastructure Services. Махеш был штатным исследователем исследовательского центра Т.Дж. Уотсона.
Круг его интересов включает в себя удаленное оказание услуг, сервисные информационные системы, повышенную готовность
составных приложений,
человеко-машинные интерфейсы в автомобилях, распознавание и синтез речи, поиск и извлечение аудио и видео, анализ изображений.
Он имеет ученую степень политехнического университета Ренсселаера по компьютерной, системной и электротехнике со
специализацией в анализе изображений.
Он имеет более 30 технических публикаций и 20 международных патентов, также он является ведущим изобретателем IBM и
ведущим членом IEEE. |
| | | Сурадж Субраманьян - ведущий архитектор по интеграции в центре Banking Center of Excellence, HiPODS, в Сан-Хосе, штат Калифорния.
Он отвечает за быструю разработку прототипов решений, демонстрирующих интеграцию ПО от IBM,
для банков и других заказчиков IBM.
До этого Сурадж работал 5 лет в IBM в подразделении Global Services и был ИТ-архитектором клиентских систем для eBay.
Круг его интересов включает в себя архитектуру интеграции решений для бизнеса с фокусом на их высокой готовности и
производительности. Он имеет степень бакалавра электроники Бомбейского университета, Индия. |
Выскажите мнение об этой странице
| |
