Показаны сообщения с ярлыком migration. Показать все сообщения
Показаны сообщения с ярлыком migration. Показать все сообщения

среда, 18 апреля 2012 г.

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

Описание: Описана настройка автоматической миграции серверов в конфигуции с двумя физическими машинами.
ПО: RHEL 5.5, Weblogic 10.3.5.

Есть простой Weblogic-домен следующей конфигурации:
Weblogic сервера:
  • AdminServer - порт 7001;
  • mserver1 - порт 7100.
Есть две физические машины (с точки зрения ОС) с IP-адресами, например:
  • 192.168.2.130
  • 192.168.2.96

Последовательность шагов:
  1. Необходимо разрешить пользователю операционной системы под которым развернут Oracle FMW (в нашем случае - это weblogic) полномочия для запуска команд /sbin/ifconfig и /sbin/arping. Для этого пользователем root добавим в файл /etc/sudoers следующую строку (выделена красным):
     ......
     ## Next comes the main part: which users can run what software on  
     ## which machines (the sudoers file can be shared between multiple  
     ## systems).  
     ## Syntax:  
     ##  
     ##   user  MACHINE=COMMANDS  
     ##  
     ## The COMMANDS section may have other options added to it.  
     ##  
     ## Allow root to run any commands anywhere  
     root  ALL=(ALL)    ALL  
     weblogic    ALL=NOPASSWD:  /sbin/ifconfig,/sbin/arping  
    
     ## Allows members of the 'sys' group to run networking, software,  
     ## service management apps and more.  
     ...... 
  2. Для обеспечения работоспособности необходим дополнительный "плавающий"/виртуальный IP-адрес из той же подсети, например: 192.168.2.139. После этого выполнить следующие команды на первой машине:
     $ sudo /sbin/ifconfig eth0:1 192.168.2.139 netmask 255.255.252.0  
     $ sudo /sbin/arping -q -U -c 3 -I eth0 192.168.2.139  
    
  3. Добавить в переменную PATH следующее (лучше на уровне профиля пользователя, если используется bash, то это файл ~/.bash_profile):
     PATH=$PATH:$MW_HOME/wlserver_10.3/common/nodemanager:$MW_HOME/user_projects/domains/bam_domain/bin/server_migration:$MW_HOME/wlserver_10.3/common/bin  
     export PATH
    
  4. Зайти в mserver1 и ввести Server Listen Address - 192.168.2.139:
  5. Клонируем mserver1 (переходим в "Environment"->"Servers", выбираем mserver1 и нажимаем на кнопку "Clone"). Новый сервер:
    • Server Name - mserver2;
    • Server Listen Address - 192.168.2.96;
    • Server Listen Port - 7200.
  6. Создаем кластер:
    • Name - WLS_Cluster;
    • Messaging Mode - Unicast.
  7. Добавляем в данный кластер оба сервера - mserver1 и mserver2:
  8. На каждой физической машине (с т.з. операционной системы) сконфигурируем по Node Manager-у (подробнее здесь) и создадим две Weblogic-машины (Machines):
    • Machine1 - 192.168.2.130;
    • Machine2 - 192.168.2.96.
  9. Соотнесём Weblogic-сервера и Weblogic-машины следующий образом:
    • mserver1 - Machine1;
    • mserver2 - Machine2.
  10. Создать новый Data Source для механизма контроля миграции (если потребуется, то создать отдельного пользователя в СУБД. Не использовать административных пользователей, таких как SYS и SYSTEM) и соотнесём его с кластером WLS_Cluster:
  11. Создадим необходимую служебную таблицу для механизма контроля миграции, для этого надо выполнить скрипт лежащий в $MW_HOME/wlserver_10.3/server/db/<СУБД>/leasing.ddl.
  12. Если используется технология JMS, то перейти в "Services"->"Persistence Stores" и проверить какие типы Persistence Store-ов используются:
    • Если FileStore, то обеспечить доступ к директориям со второго сервера, как правило для этого используется раздел дискового массива или кластерной файловой системы.
    • Если JDBCStore, то соотнести используемый Data Source с кластером WLS_Cluster.
  13. Необходимо донастроить Node Manager-ы на каждой физической машине, добавить опции для сетевых интерфейсов в файл nodemanager.properties:
     Interface=eth0  
     NetMask=255.255.255.0  
     UseMACBroadcast=true  
    
    где eth0 - имя сетевого интерфейса на котором будет поднят "плавающий"/виртульный IP-адрес.
  14. Затем в Weblogic Console выбрать кластер WLS_Cluster и перейти в "Configuration"->"Migration" и заполнить поле "Data Source For Automatic Migration:", где выбрать созданный Data Source для механизма контроля миграции (см. пункт 11):
  15. Далее перейти в "Environment"->"Servers" выбрать mserver1. Перейти в "Configuration"->"Migration" и поставить галку "Automatic Server Migration Enabled". Аналогично для mserver1:
  16. Перезапустить сервера и протестировать миграцию.

среда, 4 апреля 2012 г.

Weblogic Cluster: принцип работы Сonsensus leasing

В Weblogic Cluster есть два механизма контроля миграции:
  • Database - информация хранится/изменяется в СУБД;
  • Сonsensus - информация хранится в памяти.
В данной статье пойдёт речь об принципах работы механизма Сonsensus.

Принцип работы:
Допущение: для простоты восприятия принципа работы будем считать, что данные хранятся в виртуальной таблице в памяти мастера (никакого отношения к таблицам СУБД не имеет).

Все сервера кластера периодически отправляют информацию о статусе, так называемые лизы (от слова leasing) мастеру кластера, которую он кладёт в "виртуальную" таблицу в памяти, а от него в ответ получают текущую копию виртуальной таблицы - делается это для обеспечения отказоустойчивость при выходе из строя мастера.
Мастер выбирается всеми запущенными серверами кластера. Сервер становится мастером после одобрения большинства. Если Node Manager сообщает, что статус сервера:
  • остановлен (SHUTDOWN), то потенциальный мастер считает, что остановленный сервер одобрил его кандидатуру, как мастера;
  • неизвестен (UNKNOWN), то потенциальный мастер считает, что сервер не одобрил его кандидатуру;
  • запускается (STARTING), то состоится перевыбор мастера (так же это случится при выходе из строя самого мастера), где основной критерий выбора - наименьшее время старта сервера.
Механизм Сonsensus требует большинства серверов для продолжения функционирования: при выходе из строя (или невозможности доступа к мастеру) сервера кластер логически делится на две части - большая часть кластера продолжает, а меньшая завершает функционировать (переходит в статус FAILED).

В двухмашинной конфигурации использование Сonsensus Leasing проблематично и рекомендуется использование Database Leasing.

Пример:
При старте первого сервера он ищет остальных участников кластера, чтобы узнать есть ли мастер:
Если нет мастера, то он становится мастером:

При старте второго сервера из кластера он ищет участников кластера, находит первый сервер, являющийся мастером:
Далее оба сервера пересматривают вопрос по мастеру кластера: если время старта второго меньше, чем первого (который на данный момент является мастером), то мастером становится второй сервер:
Аналогично с третьим и последующим серверами.

четверг, 29 марта 2012 г.

Конфигурирование автоматической миграции JMS-серверов

Описание: WebLogic-кластере приложения и Data Source-ы могут быть распределены на всех узлах кластера, но есть несколько типов singleton-ресурсов, которые должны быть в единственном экземпляре в кластере:
  • JMS-сервера и их destinations;
  • JMS SAF-агенты;
  • Persistance store;
  • Менеджер транзакций и его логи;
  • Созданные пользователем классы (должен быть имплементирован интерфейс weblogic.cluster.singleton.SingletonService).
Для обеспечения высокой доступности данных ресурсов используются два подхода:
  • Миграция всего Managed-сервера;
  • Миграция сервисов (т.е. данных singleton-ресурсов с одного Managed-сервера на другой в Weblogic-кластере).

В данной статье пойдёт речь об автоматической миграцией JMS-ресурсов в конфигурации из двух физических серверов (с точки зрения операционной системы).

Последовательность шагов:
  1. Создадим два Managed-сервера, например jms_server1 и jms_server2:
  2. Создадим кластер, например JMS_Cluster и добавим ранее созданные Managed-сервера:
  3. Создадим две Machine и соотнесём их с каждым Managed-сервером:
  4. Создадим Data Source для целей миграции, например MigrationDS:
  5. Создадим JDBC Persistence Store, например JDBCStore1:
  6. Создадим JMS-сервер, например JMSServer1:
  7. Создадим JMS-модуль, например JMSModule1:
  8. Создадим в JMSModule1 новый Subdeployment, например JMSServer1Sub, и назначим его на JMSServer1:
  9. В JMSModule1 создадим Connection Factory и очередь, например JMSConnectionFactory и TestQueue соответственно, и соотвесём их с SubDeployment - JMSServer1Sub:
  10. Перейти в JMS_Cluster на страницу "Configuration"->"Migration" и выбрать тип механизма контроля миграции, в нашем случае будем использовать Database и выберем созданный (на шаге 4) Data Source - MigrationDS:
  11. Создадим необходимую служебную таблицу для механизма контроля миграции, для этого надо выполнить скрипт лежащий в $MW_HOME/wlserver_10.3/server/db/<СУБД>/leasing.ddl.
  12. Затем перейти в "Environment"->"Migratable Targets" выбрать "jms_server1 (migratable)" и изменить Service Migration Policy, например:
  13. Аналогично для "jms_server2 (migratable)":
  14. Перезапустить AdminServer, а после этого запустить jms_server1 и jms_server2:
  15. Тестируем миграцию JMS-сервера. Например с помощью данного консольного клиента.