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

Введение

WebSphereApplication Server представляет собой сервер приложений J2EE® и Web-служб, созданный для предоставления высокопроизводительного и в высшей степени масштабируемого механизма транзакций для динамических приложений электронного бизнеса (e-business).

WebSphereApplication Server Network Deployment (ND) обеспечивает операционную среду улучшенной производительности и широких функциональных возможностей для поддержки динамических приложений. В дополнение к возможностям и функциям WebSphere Application Server эта конкретная конфигурация обеспечивает улучшенные службы развертывания, включая кластеризацию, службы edge-of-network (концепция границы сети), улучшение Web-служб и повышенную готовность для распределенных конфигураций.

В первой статье этой серии вы познакомились с концепцией HA и процедурой установки и настройки heartbeat. В этой статье обсуждается HA-реализация для WebSphere Application Server и ND в конфигурации холодного резерва с использованием heartbeat.

В этой реализации heartbeat обнаруживает аварию основного узла и затем инициирует восстановление после сбоя, выполняя:

• Остановку WebSphere Application Server и агента узла на основной машине
• Остановку менеджера развертывания ND на основной машине
• Освобождение общего диска на основной машине
• Освобождение IP-адреса службы на основной машине
• Добавление IP-адреса службы на резервной машине
• Монтирование общего диска на резервной машине
• Запуск менеджера развертывания ND на резервной машине
• Запуск сервера (серверов) приложений и агента узла на резервной машине

Для лучшего усвоения материала данной статьи вы должны иметь базовые знания WebSphere Application Server Base, Network Deployment и кластеров High Availability. Также было бы полезно прочитать первую статью этой серии "Программное обеспечение повышенной готовности промежуточного уровня в Linux, часть 1: Heartbeat и Apache Web server".

В начало

WebSphereApplication Server и HA

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

Менеджер развертывания имеет также административную консоль и обеспечивает единый центральный пункт административного управления для всех элементов распределенной сети WebSphere Application Server. Когда менеджер развертывания недоступен, это влияет и на возможность изменить конфигурацию, и на передачу этих изменений серверам приложений. Это делает менеджер развертывания единым пунктом аварии.

В оставшейся части этой статьи рассматривается, как придать менеджеру развертывания среды WebSphere Application Server ND функции повышенной готовности, а также то, как можно восстановить работоспособность основного узла WebSphere, используя резервный узел. Как и в первой статье данной серии, критические файлы расположены в общей файловой системе (в этом примере /ha), которая остается доступной для резервной машины в случае аварии на узле WebSphere Application Server.

На рисунке 1 показана организация файловой системы.

В данном примере:

• Машина ha1 служит в качестве основной машины, на которой выполняется менеджер развертывания WebSphere Application Server и узел WebSphere Application Server.
• Машина ha2 служит в качестве резервной машины, на которой выполняется менеджер развертывания WebSphere Application Server и узел WebSphere Application Server.
• Машина ha3 служит в качестве узла WebSphere Application Server.
• Полная установка менеджера развертывания WebSphere (/ha/WebSphere/DeploymentManager) и WebSphere Node (/ha/WebSphere/AppServer) хранится на общем диске. Только каталоги для журналов остаются на локальных машинах.

В начало

Установка WebSphere Application Server ND и Base в конфигурации HA

В этом разделе вы установите WebSphere Application Server ND и Base.

Установка WebSphere Application Server ND

Для установки WebSphere Application Server ND 5.1 с необходимыми исправлениями на основном и резервном узлах:

1. Проверьте, что heartbeat выполняется на обоих узлах. ha1 будет обслуживать IP-адрес кластера, и файловая система /ha тоже будет смонтирована на ha1.
2. Создайте установочные каталоги для WebSphere Application Server ND и Base на узле ha1:

   mkdir /ha/WebSphere/ mkdir /ha/WebSphere/DeploymentManager mkdir /ha/WebSphere/AppServer

   
   
3. Разархивируйте установочный образ WebSphere Application Server ND 5.1 на узле ha1:

   rm -rf /tmp/was5.1nd-install mkdir /tmp/was5.1nd-install tar xf c53t6ml.tar -C /tmp/was5.1nd-install

   
   Здесь c53t6ml.tar - установочный tar-файл для WebSphere Application Server ND. Ваше имя файла образа может быть другим в зависимости от способа его получения.
4. Запустите мастер установки на узле ha1:

   cd /tmp/was5.1nd-install/linuxi386 ./launchpad.sh

   
   Введите следующую информацию в полях мастера:
   • Installation directory: /ha/WebSphere/DeploymentManager
   • Node: haManager
   • Host: ha.haw2.ibm.com
   • Cell: haNetwork
   • В этом примере HTTP-сервер и MQ уже установлены, поэтому я не выбирал их установку. Я также не устанавливал Web services gateway.
5. Очистите каталог с установочным образом:

   rm rf /tmp/was5.1nd-install

   
   
6. Разархивируйте установочный образ WebSphere Application Server ND 5.1 Fix Pack 1 на узле ha1:

   rm -rf /tmp/was5.1.1nd-install mkdir /tmp/was5.1.1nd-install tar xzf was51_nd_fp1_linux.tar.gz -C /tmp/was5.1.1nd-install

   
   Здесь was51_nd_fp1_linux.tar.gz - установочный tar-файл для WebSphere Application Server ND 5.1 Fix Pack 1. Ваше имя файла образа может быть другим, в зависимости от способа его получения.
7. Запустите обновление на ha1:

   . /ha/WebSphere/DeploymentManager/bin/setupCmdLine.sh cd /tmp/was5.1.1nd-install/ ./updateSilent.sh installDir /ha/WebSphere/DeploymentManager -fixpack -install -fixpackDir /tmp/was5.1.1nd-install/fixpacks -fixpackID was51_nd_fp1_linux -skipIHS -skipMQ

   
   
8. Очистите каталог с установочным образом:

   rm rf /tmp/was5.1.1nd-install

   
   
9. Разархивируйте установочный образ WebSphere Application Server ND 5.1.1 Cumulative Fix 1 на узле ha1:

   rm -rf /tmp/was5.1.1.1nd-install mkdir /tmp/was5.1.1.1nd-install unzip -q was511_nd_cf1_linux.zip -d /tmp/was5.1.1.1nd-install

   
   Здесь, was511_nd_cf1_linux.zip - установочный zip-файл для WebSphere Application Server ND 5.1.1 Cumulative Fix 1.
10. Запустите обновление на ha1:

    . /ha/WebSphere/DeploymentManager/bin/setupCmdLine.sh cd /tmp/was5.1.1.1nd-install ./updateSilent.sh installDir /ha/WebSphere/DeploymentManager -fixpack -install -fixpackDir /tmp/was5.1.1.1nd-install/fixpacks -fixpackID was511_nd_cf1_linux -skipIHS -skipMQ

    
    
11. Очистите каталог с установочным образом:

    rm rf /tmp/was5.1.1.1nd-install

    
    
12. Теперь создайте ссылки на каталоги, показанные на рисунке 1.
    1. Удалите каталог logs менеджера развертывания в каталоге установки на ha1:

       rm rf /ha/WebSphere/DeploymentManager/logs

       
       
    2. Создайте каталоги для журналов на локальной файловой системе обоих узлов ha1 и ha2:

       mkdir /var/log/waslog mkdir /var/log/waslog/DeploymentManager

       
       
    3. Установите корректные права доступа на обоих узлах ha1 и ha2:

       chmod 755 /var/log/waslog chmod 755 /var/log/waslog/DeploymentManager

       
       
    4. Создайте символические ссылки только на узле ha1:

       ln -s /var/log/waslog/DeploymentManager /ha/WebSphere/DeploymentManager/logs

       
       

Установка Base

Для установки WebSphere Application Server 5.1 Base с необходимыми пакетами исправления ошибок на основном и резервном узлах:

1. Разархивируйте установочный образ WAS Base 5.1 на узле ha1:

   rm -rf /tmp/was5.1base-install mkdir /tmp/was5.1base-install tar xf c53ipml.tar -C /tmp/was5.1base-install

   
   Здесь c53ipml.tar - установочный tar-файл для WAS Base 5.1. Ваше имя файла образа может быть другим, в зависимости от способа его получения.
2. Запустите мастер установки на узле ha1:

   cd /tmp/was5.1base-install/linuxi386 ./launchpad.sh

   
   Введите следующую информацию в полях мастера:
   • Installation directory: /ha/WebSphere/AppServer
   • Node: ha
   • Host: ha.haw2.ibm.com
   • В этом примере HTTP-сервер и MQ уже установлены, поэтому я не выбирал их установку. Вы можете запретить их установку, выбрав вариант Custom Setup.
3. Очистите каталог с установочным образом при помощи следующей команды:

   rm rf /tmp/was5.1base-install

   
   
4. Разархивируйте установочный образ WAS Base 5.1 Fix Pack 1, используя следующие команды на узле ha1:

   rm -rf /tmp/was5.1.1base-install mkdir /tmp/was5.1.1base-install tar xzf was51_fp1_linux.tar.gz -C /tmp/was5.1.1base-install

   
   Здесь was51_fp1_linux.tar.gz - установочный tar-файл для WAS Base 5.1 fix pack 1. Ваше имя файла образа может быть другим, в зависимости от способа его получения.
5. Запустите обновление на ha1, используя следующие команды:

   . /ha/WebSphere/AppServer/bin/setupCmdLine.sh cd /tmp/was5.1.1base-install ./updateSilent.sh installDir /ha/WebSphere/AppServer -fixpack -install -fixpackDir /tmp/was5.1.1base-install/fixpacks -fixpackID was51_fp1_linux -skipIHS -skipMQ

   
   
6. Очистите каталог с установочным образом при помощи следующей команды на узле ha1:

   rm rf /tmp/was5.1.1base-install

   
   
7. Разархивируйте установочный образ WAS Base 5.1.1 Cumulative Fix 1, используя следующие команды на узле ha1:

   rm -rf /tmp/was5.1.1.1base-install mkdir /tmp/was5.1.1.1base-install unzip -q was511_cf1_linux.zip -d /tmp/was5.1.1.1base-install

   
   Здесь was511_cf1_linux.zip - установочный tar-файл для WAS Base 5.1.1 Cumulative Fix 1.
8. Запустите обновление на узле ha1, используя следующую команду:

   . /ha/WebSphere/AppServer/bin/setupCmdLine.sh cd /tmp/was5.1.1.1base-install ./updateSilent.sh installDir /ha/WebSphere/AppServer -fixpack -install -fixpackDir /tmp/was5.1.1.1base-install/fixpacks -fixpackID was511_cf1_linux -skipIHS -skipMQ

   
   
9. Очистите каталог с установочным образом при помощи следующей команды на узле ha1:

   rm rf /tmp/was5.1.1.1base-install

   
   
10. Теперь создайте ссылки на каталоги, показанные на рисунке 1.
    1. Удалите каталоги WebSphere logs из каталога установки на ha1:

       rm rf /ha/WebSphere/AppServer/logs

       
       
    2. Создайте каталоги для журналов на локальной файловой системе на обоих узлах, ha1 и ha2:

       mkdir /var/log/waslog/AppServer

       
       
    3. Установите корректные права доступа на обоих узлах, ha1 и ha2:

       chmod 755 /var/log/waslog/AppServer

       
       
    4. Создайте символические ссылки только на узле ha1:

       ln -s /var/log/waslog/AppServer /ha/WebSphere/AppServer/logs

       
       
11. Установите WebSphere Application Server base на узле ha3 (только шаги 1 - 9, приведенные выше), указав следующую информацию:
    • Installation directory: /opt/WebSphere/AppServer
    • Node: ha3
    • Host: ha3.haw2.ibm.com
    • В этом примере HTTP-сервер и MQ уже установлены, поэтому я не выбирал их установку.
12. Запустите менеджер развертывания на ha1, выполнив startManager.sh из каталога bin установленного менеджера развертывания.
13. Добавьте узлы WAS ha и ha3 (созданные в описанном выше процессе установки WebSphere Application Server base) в секции haNetwork (созданной на шаге 4 установки WebSphere Application Server ND), выполнив следующую команду на каждом узле (из каталога bin сервера приложения) :

    addnode.sh ha

    
    
14. Проверьте через консоль администратора, что секция выглядит корректной. Откройте консоль (http://ha.haw2.ibm.com:9090/admin) и убедитесь, что видны все узлы для Application Servers.
15. Остановите все. Это означает остановку менеджера развертывания и агентов узла на каждом узле WAS nodes. Используйте следующие команды:
    1. Агенты узла: stopNode.sh (из каталога bin Application Server)
    2. Менеджер развертывания: stopManager.sh (из каталога bin менеджера развертывания)

В начало

Настройка heartbeat для управления менеджером развертывания

Теперь вы можете настроить heartbeat для управления менеджером развертывания WebSphere Application Server ND. Во-первых, создайте сценарий для запуска и останова процесса менеджера развертывания. Базовый сценарий (wasdmgr) приведен в листинге 1. Вы можете настроить его под свои требования. Поместите этот сценарий в каталог /etc/rc.d/init.d.

#!/bin/bash
#
#	/etc/rc.d/init.d/wasdmgr
#
# Запуск WebSphere Deployment Manager
#
# chkconfig: 345 88 57
# описание: Запускает  WAS DMGR

. /etc/init.d/functions
# Source function library.

PATH=/usr/bin:/bin:/ha/WebSphere/DeploymentManager/bin
#===============================================
SU="sh"
#================================================
start() {
	echo "$0: starting websphere deployment manager"
	$SU -c "startManager.sh"
}
#================================================
stop() {
	echo "$0: stopping websphere deployment manager"
	$SU -c "stopManager.sh"
}


case $1 in
'start')
    start
    ;;
'stop')
    stop
    ;;
'restart')
    stop
    start
    ;;
*)
    echo "usage: $0 {start|stop|restart}"
    ;;
esac

Затем настройте файл /etc/ha.d/haresources на обоих узлах ha1 и ha2 для включения сценария wasdmgr. Вот соответствующий фрагмент измененного файла:

ha1.haw2.ibm.com 9.22.7.46 Filesystem::hanfs.haw2.ibm.com:/ha::/ha::nfs::rw,hard wasdmgr

Эта строка указывает, что при старте heartbeat ha1 обслуживает IP-адрес кластера, монтирует общую файловую систему и запускает менеджер развертывания WebSphere Application Server. При останове heartbeat сначала остановит менеджер развертывания, демонтирует общую файловую систему и, наконец, освободит IP.

В начало

Настройка heartbeat для управления узлом WebSphere Application Server

Теперь настроим heartbeat для управления агентом узла WebSphere Application Server и процессами сервера приложений. Во-первых, создайте два сценария для запуска и останова агента узла и процессов сервера приложений. Базовый сценарий для запуска агента узла (wasnode) приведен в листинге 2, а сценарий для запуска серверов приложений (wasserver) на узле приведен в листинге 3. Вы можете настроить эти сценарии под свои требования. Поместите эти сценарии в каталог /etc/rc.d/init.d.

#!/bin/bash
#
#	/etc/rc.d/init.d/wasnode
#
# Запуск  WebSphere Node Agent
#
# chkconfig: 345 88 57
# описание: Запускает WAS NODE

. /etc/init.d/functions
# Source function library.

PATH=/usr/bin:/bin:/ha/WebSphere/AppServer/bin
#=====================================
SU="sh"
#======================================
start() {
	echo "$0: starting websphere node agent"
	$SU -c "startNode.sh"
}
#======================================
stop() {
	echo "$0: stopping websphere node agent"
	$SU -c "stopNode.sh"
        #sleep 30
}


case $1 in
'start')
    start
    ;;
'stop')
    stop
    ;;
'restart')
    stop
    start
    ;;
*)
    echo "usage: $0 {start|stop|restart}"
    ;;
esac

#!/bin/bash
#
#	/etc/rc.d/init.d/wasserver
#
# Запуск WebSphere Application Server
#
# chkconfig: 345 88 57
# описание: Запускает WAS Server

. /etc/init.d/functions
# Source function library.

PATH=/usr/bin:/bin:/ha/WebSphere/AppServer/bin
WASSERVERS="server1"
#============================================
SU="sh"
#============================================
start() {
    for wasserver in $WASSERVERS ; do
        export wasserver
	echo "$0: starting websphere application server $wasserver"
	$SU -c "startServer.sh $wasserver"
    done
}
#=============================================
stop() {
    for wasserver in $WASSERVERS ; do
        export wasserver
	echo "$0: stopping websphere application server $wasserver"
	$SU -c "stopServer.sh $wasserver"
    done
}


case $1 in
'start')
    start
    ;;
'stop')
    stop
    ;;
'restart')
    stop
    start
    ;;
*)
    echo "usage: $0 {start|stop|restart}"
    ;;
esac

Теперь настройте файл /etc/ha.d/haresources на обоих узлах ha1 и ha2 для включения сценариев wasnode и wasserver. Вот соответствующий фрагмент измененного файла:

ha1.haw2.ibm.com 9.22.7.46 Filesystem::hanfs.ibm.com:/ha::/ha::nfs::rw,hard 
wasdmgr wasnode wasserver

Эта строка указывает, что при запуске heartbeat ha1 обслуживает IP-адрес кластера, монтирует общую файловую систему и запускает менеджер развертывания WebSphere Application Server, агент узла и серверы приложений. При аварии heartbeat сначала останавливает серверы приложения, агент узла и менеджер развертывания, демонтирует общую файловую систему и, наконец, освобождает IP.

В начало

Тестирование восстановления после отказа менеджера развертывания

В этом разделе рассмотрен процесс тестирования повышенной готовности менеджера развертывания.

1. Запустите службу heartbeat на основном узле и затем на резервном при помощи следующей команды: /etc/rc.d/init.d/heartbeat start. После успешного запуска heartbeat вы увидите новый интерфейс с IP-адресом, который вы настроили в файле ha.cf. Сразу после запуска heartbeat загляните в ваш log-файл (по умолчанию /var/log/ha-log) на основном узле и убедитесь, что выполнилось присоединение IP и запустился dmgr, агент узла, серверы приложений и другие ресурсы. Heartbeat не запустит никаких ресурсов на резервном узле. Это произойдет только после аварии на основном узле.
2. Запустите агент узла WebSphere и WebSphere Application Server на узле ha3.
3. В консоли администратора (http://ha.haw2.ibm.com:9090/admin) проверьте, что серверы приложений выполняются на обеих машинах (ha1 и ha3). Если нет, запустите их.
4. Разверните пример корпоративного приложения, TestWebSphereHA.ear (см. раздел "Загрузка" ниже) в каталоге was\sample_ver_1, используя консоль администратора. Проверьте, что установили его на обоих узлах WAS ha и ha3. Запустите приложение, используя консоль.
5. Проверьте, что приложение работает на обоих узлах, указав в окне браузера следующие URL:
   http://ha.haw2.ibm.com:9080/TestWebSphereHAWeb/Test
   http://ha3.haw2.ibm.com:9080/TestWebSphereHAWeb/Test
   Для обоих URL браузер должен отобразить следующий текст: Test:doGet() Invoked the HA Test Servlet.

На данном этапе вы успешно развернули приложение на двух узлах WebSphere Application Server, управляемых менеджером развертывания, который выполняется на ha1. Теперь, проверьте, перенесется ли при аварии эта информация по настройке на резервный узел.

6. Сэмулируйте аварию, остановив heartbeat на основной системе при помощи команды: /etc/rc.d/init.d/heartbeat stop. Вы должны увидеть, что все службы запускаются на резервной машине. Проверив файл /var/log/ha-log, убедитесь в том, что менеджер развертывания работает на резервной машине. После того как резервная система взяла управление на себя, запустите консоль администратора. Вы должны увидеть два сервера приложений и корпоративное приложение TestWebSphereHA. Это указывает на то, что конфигурационная информация перенесла аварию. Повторите также шаг 5 для проверки работы приложения на обоих узлах.
7. Обновите корпоративное приложение до более новой версии TestWebSphereHA.ear, находящейся в каталоге was\sample_ver_2, используя консоль администратора. Проверьте, что выбрали для обновления оба WAS-узла –ha и ha3.
8. После обновления сохраните основную конфигурацию. Также проверьте, что выбран вариант Synchronize changes with Nodes. Вы должны быть способны успешно обновить приложение. Повторите шаг 5.
9. Для URL http://ha.haw2.ibm.com:9080/TestWebSphereHAWeb/Test браузер отображает Test:doGet() Invoked the HA Test Servlet on remote host : ha2.haw2.ibm.com. Отображается также имя хоста машины. Это подтверждает, что IP кластера ha.haw2.ibm.com обслуживается резервной машиной.
10. Для URL http://ha3.haw2.ibm.com:9080/TestWebSphereHAWeb/Test браузер отображает Test:doGet() Invoked the HA Test Servlet on remote host : ha3.haw2.ibm.com.
11. Запустите службу heartbeat на основной системе. При этом процессы WebSphere Application Server на резервной системе должны остановиться и запуститься на основной системе. Основная система должна также принять управление над IP кластера. Используйте следующую команду: /etc/rc.d/init.d/heartbeat start.
12. Повторно запустите консоль администратора. Вы должны увидеть два сервера приложений и приложение TestWebSphereHA. Это указывает на то, что конфигурационная информация успешно перенесла сбой на основной системе. Повторите шаг 5 для проверки выполнения приложения на обоих узлах.

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

В начало

Тестирование восстановления после сбоя узла WebSphere Application Server

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

Для проверки повышенной готовности узла WebSphere и приложения:

1. Запустите службу heartbeat на основном, а затем и на резервном узле при помощи команды /etc/rc.d/init.d/heartbeat start.
2. Запустите агент узла WebSphere и WebSphere Application Server на узле ha3.
3. В консоли администратора (http://ha.haw2.ibm.com:9090/admin) проверьте, что серверы приложений работают на обеих машинах (ha1 и ha3). Если нет, запустите их. Вы должны также увидеть приложение TestWebSphereHA.
4. Обновите корпоративное приложение до более новой версии TestWebSphereHA.ear, находящейся в каталоге was\sample_ver_3, используя консоль администратора. Выберите для обновления оба узла (ha и ha3). После обновления сохраните основную конфигурацию. Проверьте также, что выбран вариант Synchronize changes with Nodes. Вы должны быть способны успешно обновить приложение.
5. Проверьте, что приложение выполняется на узле ha WebSphere, указав в браузере следующий URL: http://ha.haw2.ibm.com:9080/TestWebSphereHAWeb/Test. Браузер должен отобразить следующую информацию:

   Test:doGet() Invoked the HA Test Servlet on remote host : ha1.haw2.ibm.com Test:doGet() This servlet has been invoked 1 times Test:doGet() Count data file : /ha/WebSphere/AppServer/installedApps/haNetwork /TestWebSphereHA.ear/TestWebSphereHAWeb.war /WEB-INF/count.dat

   
   Эта информация показывает, что приложение успешно работает на WAS-узле ha, который работает на основном узле ha1. Обратите внимание также на то, что файл count.dat расположен в общей файловой системе /ha. Повторите этот шаг еще раз, счетчик примет значение 2.
6. Сэмулируйте аварию, остановив heartbeat на основной системе при помощи команды /etc/rc.d/init.d/heartbeat stop. После того, как резервный узел возьмет управление на себя, запустите консоль администратора. Вы должны увидеть два сервера приложений и приложение TestWebSphereHA.
   Укажите в браузере следующий URL: http://ha.haw2.ibm.com:9080/TestWebSphereHAWeb/Test. Браузер должен отобразить следующую информацию:

   Test:doGet() Invoked the HA Test Servlet on remote host : ha2.haw2.ibm.com Test:doGet() This servlet has been invoked 3 times Test:doGet() Count data file : /ha/WebSphere/AppServer/installedApps/haNetwork /TestWebSphereHA.ear/TestWebSphereHAWeb.war /WEB-INF/count.dat

   
   Эта информация показывает, что приложение успешно работает на WAS-узле ha, который работает на резервном узле ha2. Данные приложения (значение count) тоже перенесли аварию, поскольку расположены на общем диске.

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

7. Запустите службу heartbeat на основном узле. При этом должны остановиться процессы WebSphere Application Server на резервной системе и запуститься на основной. Основной узел должен также взять управление над IP кластера. Используйте следующую команду: /etc/rc.d/init.d/heartbeat start.

В начало

Заключение

Готовность является ключевым требованием при построении системы вычислений по требованию при работе системы в режиме 24/7. В этой статье показывается, как вы можете уменьшить влияние на бизнес времени простоя, реализуя режим повышенной готовности для WebSphere Application Server при помощи программного обеспечения с открытым исходным кодом в операционной системе Linux™. При использовании описанного в этой серии статей подхода вы можете значительно уменьшить плановые и внеплановые перерывы в работе, позволяя обновлять кластер и обслуживать систему без прерывания операций.

В начало

Загрузка

Информация о методах загрузки

Ресурсы

• Оригинал статьи High-availability middleware on Linux, Part 4. IBM WebSphere Application Server.
  
  
• Прочтите следующие статьи этой серии:
  • "Программное обеспечение повышенной готовности промежуточного уровня в Linux, часть 1: Heartbeat и Apache Web server"
  • "Программное обеспечение повышенной готовности промежуточного уровня в Linux, часть 2: IBM WebSphere MQ"
  • "Программное обеспечение повышенной готовности промежуточного уровня в Linux, часть 3: IBM LoadLeveler"
  
  
• Дополнительная информация по конфигурации WebSphere Application Server Network Deployment находится на странице WebSphere Application Server Network Deployment.
  
  
• Посетите Web-сайт проекта High-Availability Linux для получения дополнительной информации по heartbeat, включая успешные примеры применения heartbeat.
  
  
• Большую часть необходимого для этой серии статей программного обеспечения можно загрузить из следующих источников (отмечу, что не все пакеты являются бесплатными):
  • Red Hat Enterprise Linux 3.0 (2.4.21-15.EL)
  • Heartbeat 1.2.3
  • IBM Java™ 2 SDK 1.4.2
  • IBM WebSphere® MQ for Linux 5.3.0.2 with Fix Pack 7
  • IBM WebSphere Base Edition 5.1.1 for Linux with Cumulative Fix 1
  • IBM DB2® Universal Database™ Enterprise Server Edition V8.1 for Linux
  
  
• В статье "Кластеризация IBM DB2 Universal Database: Повышенная готовность в WebSphere Edge Server" (developerWorks, май 2002) рассматривается, как эта архитектура обеспечивает простое кросс-платформенное кластерное решение для повышенной готовности DB2.
  
  
• Подробное обсуждение готовности, ее планирования и поддержки в корпоративной среде приводится в статье "Планирование готовности на предприятии" (developerWorks, декабрь 2003).
  
  
• Хорошо известна поддержка режима повышенной готовности кластерами. Статьи "Построение гетерогенного кластера с coLinux и openMosix" (developerWorks, февраль 2005) и "Linux - кластерное изобилие" (developerWorks, май 2000) могут пополнить ваши знания кластеров.
  
  
• Страница поддержки IBM WebSphere Application Server содержит ссылки на документацию по продукту и Fix Packs.
  
  
• IBM предлагает службы повышенной готовности, в том числе реализации HA-кластера, WebSphere MQ, разнородные сетевые службы и оценки служб для малого бизнеса.
  
  
• IBM предлагает также список ресурсов по повышенной готовности, таких как "белые книги" и документация.
  
  
• Поскольку вы уже здесь, проверьте этот кластер и HA-решения.
  
  
• Дополнительные ресурсы для Linux-разработчиков размещены в зоне developerWorks Linux.
  
  
• Подключайтесь к сообществу developerWorks, участвуя в блогах developerWorks.
  
  
• Приобретите книги по Linux со скидками в разделе Linux Web-сайта Developer Bookstore.
  
  
• Закажите пакет SEK for Linux, набор из двух DVD, содержащий последние пробные версии программного обеспечения IBM для Linux с DB2®, Lotus®, Rational®, Tivoli® и WebSphere®.
  
  
• Примените новые технологии в вашем следующем Linux-проекте с использованием пробного программного обеспечения IBM, доступного для загрузки непосредственно с developerWorks.
  
  

Об авторе

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• WebSphereApplication Server и HA
• Установка WebSphere Application Server ND и Base в конфигурации HA
• Настройка heartbeat для управления менеджером развертывания
• Настройка heartbeat для управления узлом WebSphere Application Server
• Тестирование восстановления после отказа менеджера развертывания
• Тестирование восстановления после сбоя узла WebSphere Application Server
• Заключение
• Загрузка
• Ресурсы
• Об авторе
• Комментарии