Weblogic Server Migration

Server Migration - технология, позволяющая организовать отказоустойчивое решение с  защитой от потери сервиса при потере одного из хостов кластера. Управляемый сервер со всеми приложениями и сервисами поднимается на новом хосте. Решение особенно эффективно для singleton-сервисов.  

Моё окружение.

Host 1: 172.16.1.1 hostname: sms_a
Host 2: 172.16.1.2 hostname: sms_b
VIP     : 172.16.1.3
Weblogic Server 12.1.2
Oracle Linux 6.4

1.Настройки ОС.

1.1 Для пользователя oracle обновить CLASSPATH на обоих хостах.

export MW_HOME=/opt/oracle/middleware/Oracle_WL
PATH=$PATH:$MW_HOME/user_projects/domains/sms_domain/nodemanager:$MW_HOME/user_projects/domains/sms_domain/bin/server_migration:$MW_HOME/Oracle_WL/wlserver/common/bin
export PATH

 1.2 Добавить пользователю oracle возможность запускать утилиты с правами суперпользователя. Для этого на обоих хостах редактируется файл /etc/sudoers 

oracle ALL=NOPASSWD: /sbin/ifconfig,/sbin/arping,$DOMAIN_HOME/bin/server_migration/wlsifconfig.sh

Если этого не сделать, в логах nodemanager-а можно наблюдать вот такие сообщения:

<Jul 16, 2014 11:41:19 AM MSK> <WARNING> <sudo: sorry, you must have a tty to run sudo>
<Jul 16, 2014 11:41:19 AM MSK> <WARNING> <Failed to remove 172.16.5.231 netmask  from eth0:1.>
<Jul 16, 2014 11:41:19 AM MSK> <WARNING> <Exception while executing 'PostStop' ExecutableCallbacks>
java.io.IOException: Exception while executing 'PostStop' ExecutableCallbacks
        at weblogic.nodemanager.server.WLSProcess$MultiExecuteCallbackHook.execute(WLSProcess.java:290)
        at weblogic.nodemanager.server.WLSProcess.executePostStopHooks(WLSProcess.java:239)
        at weblogic.nodemanager.server.WLSProcess.waitForProcessDeath(WLSProcess.java:205)
        at weblogic.nodemanager.server.ServerMonitor.runMonitor(ServerMonitor.java:298)
        at weblogic.nodemanager.server.ServerMonitor.run(ServerMonitor.java:254)
        at java.lang.Thread.run(Thread.java:745)
Caused by: weblogic.nodemanager.util.MultiException:

В Linux обычно запрещено выполнение команд вида

ssh oracle@servername sudo ifconfig

Они не безопасны, так как передают пароль в открытом виде. Такая команда завершится с ошибкой.

sudo: sorry, you must have a tty to run sudo

Вообще говоря, при подключении по ssh у пользователя нет tty не только для sudo:

ssh oracle@servername tty
not a tty

1.4 Опционально можно настроить аутентификацию без пароля
ssh-keygen
ssh-copy-id oracle@servername_1

После выполнения этих пунктов у пользователя oracle будет достаточно прав для создания интерфейса eth0:1 и назначения ему виртуального ip-адреса. Во время миграции сервера этот интерфейс будет создаваться с помощью скрипта wlsifconfig.sh, запущенного nodemanager-ом.
Интерфейс с VIP-адресом (в моём случае это 172.16.1.3) необходимо создать до того, как будет запущен сервер, слушающий на нём.
1.5 Создание интерфейса eth0:1 на первом хосте:

[oracle@servername_1 ~]sudo $DOMAIN_HOME/bin/server_migration/wlsifconfig.sh -addif eth0 172.16.1.3 255.255.240.0

 Здесь 172.16.1.3        - VIPадрес
            255.255.240.0 - маска подсети.
Если скрипт отработает без ошибок, в выводе ifconfig появится новый интерфейс.

eth0      Link encap:Ethernet  HWaddr 55:53:56:56:11:30
          inet addr:172.16.1.1  Bcast:172.16.15.255  Mask:255.255.240.0
         [...]
eth0:1    Link encap:Ethernet  HWaddr 5:53:56:56:11:30
          inet addr:172.16.1.3  Bcast:172.16.15.255  Mask:255.255.240.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

Теперь можно обновить arp-таблицу на ближайшем свиче командой

sudo arping -q -U -c 5 -I eth0 172.16.1.3

 2. Настройка Nodemanager.

 К конфигурационный файл nodemanager.properties добавить строки

Interface=eth0
NetMask=255.255.240.0
UseMACBroadcast=true
ListenAddress=172.16.1.1

В качестве  ListenAddress указываются ip адреса хостов. В моём случае это 172.16.1.1 и 172.16.1.2 соответственно.

3. Настройки Weblogic сервера.

3.1. Необходимо создать кластер. В моём случае это trvlrCluster.

3.2. Создать две машины.

 В настройках первой указать ip-адрес (hostname) и порт nodemanager-a первого хоста 172.16.1.1 (sms-a) Для второго - 172.16.1.2 (sms-b)

 3.3. Создать два сервера. trvlr_1 и trvlr_2.  Для первого серверa указать Listen Address - адрес виртуального интерфейса, созданного на шаге 1.5. В моём случае это 172.16.1.3. Для второго сервера - ip адрес второго хоста(172.16.1.2). Возможности мигрировать у второго сервера не будет.

 В настройках серверов (Servers -> trvlr_1 -> Configuration - > General) выбрать имя кластера, созданного в пункте 3.2 и машину, созданную в пункте 3.2

 Для второго сервера мои настройки выглядят так:

 В настройках первого сервера выбрать Automatic Server Migration Enabled

 3.4 Опционально с помощью скрипта $WL_HOME/wlserver/server/db/oracle/920/leasing.ddl  можно создать в БД таблицу лизинга для кластера. Затем создать датасорс (в моём случае leasingDS), назначить его всем серверам кластера и на вкладке Clustername - > Configuration ->Migration   выбрать в качетве Migration Basis базу данных.

4. Проверка работоспособности.

4.1 На вкладке servers -> trvlr_1 -> Control -> Migration можно проверить возможность мигрировать на второй хост. 

После нажатия кнопки "Save" на втором хосте будет поднят интерфейс eth0:1 с адресом  172.16.1.3 и сервер trvlr_1. На хосте 172.16.1.1 (sms-a) соответствующий интерфейс будет опущен автоматически.
4.2 После того как сервер поднимется на втором хосте можно проверить автоматическую миграцию сервера. Для этого надо выключить host 172.16.1.2. Если возможности выключить хост нет, можно погасить на нём nodemanager, сервер trvlr_1 и интерфейс eth0:1

killall -f -9 weblogic.NodeManager
killall -f -9 trvlr_1
sudo $DOMAIN_HOME/bin/server_migration/wlsifconfig.sh -removeif eth0 172.16.1.3 255.255.240.0

Weblogic Portal

Маленькая особенность установки Weblogic Portal.

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

<Critical> <WebLogicServer> <BEA-000362> <Server failed. Reason:java.net.UnknownHostException: someserver.ru        at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)        at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:850)...

И сама ошибка

Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class weblogic.protocol.ServerIdentityManager$Initializer        at weblogic.protocol.ServerIdentityManager.findServerIdentity(ServerIdentityManager.java:64)        at weblogic.protocol.URLManager.findAdministrationURL(URLManager.java:172)        at weblogic.server.ServerLifeCycleRuntime.getLifeCycleOperationsRemote(ServerLifeCycleRuntime.java:801)        at weblogic.t3.srvr.ServerRuntime.sendStateToAdminServer(ServerRuntime.java:423)        at weblogic.t3.srvr.ServerRuntime.updateRunState(ServerRuntime.java:409)        at weblogic.t3.srvr.T3Srvr.setState(T3Srvr.java:187)        at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:458)        at weblogic.Server.main(Server.java:67)Stopping PointBase server...PointBase server stopped.

Оказалось, управляемый сервер потерял параметр

-Dweblogic.management.server=http://AdminServer.ru:7001

Порядок применения параметров запуска weblogic-сервера.

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

java [JVM options] [Weblogic Options] weblogic.Server

Собственно, компонованием этой строки и занимается startWeblogic.sh, лежащий в $MW_HOME/bin. Этот скрипт рекомендован Oracle для запуска и остановки серверов. Его можно немного подредактировать под свои нужды или передать ему пару параметров прямо из командной строки

nohup sh $DOMAIN_HOME/bin/startWebLogic.sh -Dweblogic.management.username=weblogic -Dweblogic.management.password=password > wls_start.log &

2. Запуск Admin-сервера командой startServer из консоли WLST. Пример такой команды можно посмотреть, набрав

help('startServer') 

3. Запуск серверов из консоли WLST с помощью NodeManager командой

nmStart('ServerName')

В первом случае все параметры запуска задаются в тексте команды. Во втором параметры запуска jvmArgs передаются как аргумент метода startServer(). В третьем случае параметры берутся из конфиг-файлов и скрипта запуска. Параметры, хранящиеся в файле config.xml в этом случае не применяются. Они там просто хранятся.

Есть свои правила применения параметров при запуске сервера через Nodemanager:
1. В первую очередь применяются параметры, указанные явно в консоли WLST. В этом случае мы переопределяем всё, что  было задано другими методами.

arg="Arguments=\" -Dweblogic.management.server=localhost:7001\""
prps=makePropertiesObject(arg)
nmStart('serverName',props=prps)

2. Параметры, заданные в файле startup.properties.

После запуска блока из предыдущего пункта в директории {DOMAIN_HOME}/servers/serverName/data/nodemanager/

появится файл startup.properties примерно такого содержания

#Server startup properties
#Fri Jun 03 16:59:19 MSD 2011
Arguments=\ -Dweblogic.management.server\=localhost\:7001

Именно этот файл, а не  config.xml читает Nodemanager перед запуском сервера. Полный список возможных параметров можно посмотреть тут.

3.  Параметры запуска можно указать через web-консоль. Вообще говоря, этот способ - практически полное повторение пункта 2, но со своей логикой работы. При запуске/остановке серверов через web-консоль AdminServer обращается к NodeManager-у, который управляет ManagedServer-ом. Nodemanager в свою очередь выполняет метод nmStart('serverName')

На страничке Server Start вводим всё, что интересует

После сохранения и применения изменений  значения пишутся в файл config.xml и, если сервер уже запущен, генерируется файл startup.properties.Если сервер не запущен, файл не создаётся. Такое поведение похоже на вызов функции

nmGenBootStartupProps('serverName')

из консоли WLST, которая генерирует startup.properties-файл на основе config.xml и которая также требует подключения к работающему серверу.
Если сервер до этого ни разу не запускался, то необходимого для запуска файла startup.properties всё ещё нет. За его создание почему-то отвечает кнопка "Start" на странице управления серверами.

Такая логика работы web-консоли позволяет избежать ошибки (а может именно она её и вызывает), с которой сталкиваются новички, пытаясь стартовать свежесконфигурированный сервер из консоли WLST командой nmStart('serverName') до того, как будут заданы все необходимые параметры запуска.
4. Ещё один способ запустить сервер с нужными параметрами - использовать одновременно и скрипт startWeblogic, и файл startup.properties.
Если почитать документацию, можно найти вот такой текст:

You can use a start script to specify required startup properties and perform any other work you need performed at start up.

Для этого надо отредактировать конфиг NodeManager-а

${MW_HOME}/wlserver_10.3/common/nodemanager/nodemanager.properties

 StartScriptEnabled=true

и перезапустить его и сервер. После рестарта получаем процесс примерно такого вида:

ps -ef | grep weblogic.Server

/opt/oracle/java/latest/bin/java

-server
-Xms256m
-Xmx512m
-XX:MaxPermSize=256m
-Dweblogic.Name=serverName
-Djava.security.policy=/opt/oracle/middleware/wlserver_10.3/server/lib/weblogic.policy
-Dweblogic.ProductionModeEnabled=true
-Dweblogic.system.BootIdentityFile=/.../data/nodemanager/boot.properties
-Dweblogic.nodemanager.ServiceEnabled=true
-Dweblogic.security.SSL.ignoreHostnameVerification=true
-Dweblogic.ReverseDNSAllowed=false
-server
-Xms256m
-Xmx256m
-XX:MaxPermSize=128m
-Dplatform.home=/opt/oracle/middleware/wlserver_10.3
-Dwls.home=/opt/oracle/middleware/wlserver_10.3/server
-Dweblogic.home=/opt/oracle/middleware/wlserver_10.3/server
-Dweblogic.management.discover=false
-Dweblogic.management.server=http://...:7001

Первая выделенная группа - параметры JVM, заданные в скрипте startWeblogic.sh.
Вторая - параметры JVM, заданные в файле startup.properties. Параметры из этого файла всегда будут добавляться в конец строки запуска. Действующими параметрами будут только последние. Способ стоит пользоваться осторожно, так как для некоторых параметров JVM важен порядок следования, также важен порядок перечисления путей в переменной CLASSPATH .

Параметры JVM для weblogic

Общие рассуждения о работе JVM.

Выделением памяти в Java занимается виртуальная машина. Машина выделяет память под объекты, удаляет объекты и освобождает память. В соответствии с Generation Model, объект за время своего существования перемещается между областями памяти, которые называются Young и Tenured. Но скорее всего, до Tenured объект не доживёт, ибо по статистике объекты умирают молодыми. Удалением объектов занимается сборщик мусора, который запускается по мере заполнения памяти.

Балансировка нагрузки с помощью mod_wl

Балансировка нагрузки возможна не только между серверами, объединёнными в кластер. С некоторыми ограничениями, можно сделать это с помощью любого балансировщика нагрузки, в том числе и с помощью apache + mod_wl просто перенаправляя запросы на разные сервера, на которые задеплоено одно приложение. Естественно, фича session failover при этом не доступна.

В моём случае необходимо было реализовать возможность перезагрузки экземпляров weblogic (по очереди) без потери доступности сервиса. При этом потеря сессии и её состояния не считается критичной.
Будем реализовывать вот такую схему:

Если почитать документацию, можно найти нужный параметр

WebLogicCluster

под которым подразумевается

List of WebLogic Servers that can be used for load balancing

Это список  серверов, доступных для перенаправления на них запросов. Список динамически обновляется, учитывая failed и recvered в данный момент сервера.
При этом не стоит переопределять параметр

DynamicServerList

он по имелчанию равен ON. При установке его в Off возможно перенаправление запроса на неработающий в данный момент сервер.

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

LoadModule weblogic_module "/etc/apache2/modules/mod_wl_22.so"

<IfModule mod_weblogic.c>
       WebLogicCluster server1:8001,server1:8002,server2:8001,server2:8002
     MatchExpression *.jsp №перенаправлять только jsp-страницы
</IfModule>

Или, например, так

<Location /myApp>
    SetHandler weblogic-handler
    PathTrim /myApp    WebLogicCluster server1:8001,server1:8002,server2:8001,server2:8002
</Location>

Парвый вариант перенапрвляет запрс на основе MIME-типа. Второй по явному указанию пути (path) или его части

Запуск и остановка серверов c помощью NodeManager Update 03.06.2011

В качестве best practices управления weblogic-доменами предлагается использовать NodeManager.

NodeManager запускается один на хост и может обслуживать несколько managed-серверов, принадлежащих одному или нескольким доменам.

Benefits от использования:

1. Возможность управления  managed-серверами через админскую консоль.

2. Возможность автоматического выключения\рестарта серверов в случае ошибки.

3. Автоматический запуск управляемых серверов.

4. Возможность восстановления состояния серверов до состояния, предшествующего "неожиданному выключению" (это значит, что если ваш сервер перед сбоем находился в состоянии standby, он запустится в standby, а не running)

5. Удобная настройка новых серверов на удалённых машинах.
6. Миграция серверов.

Запуск weblogic на 80 порту upd 16.01.12

В Unix-like системах запуск приложений, слушаюших на портах меньших 1024 возможен только от пользователя root.  Соответственно, запуск weblogic на 80 порту от  имени другого пользователя невозможен.  Пара способов обойти это ограничние.

1.       Запуск процесса от имени root с последующим переключением его на непривилигированнойго пользователя. Настройка Weblogic-сервера производится через admin-консоль на вкладке

     Environment - > Machines -> [Mashine name]

Post-Bind UID: – UID  группы, на пользователя которой мы переключаемся.

Post-Bind GID: – GID пользователя, на которого переключаемся

2.       Второй способ – запуск прокси-сервера на 80 порту и перенаправление на weblogic всех запросов, адресованных приложению.

В качестве прокси будем использовать apache 2.2 с модулем mod_wl

Для SuSE linux и утановленного из репозиториев apache это будет выглядеть так

1.       Установка web-сервера

rpm –ihv apache2*

2.       Создаём папку /etc/apache2/modules и копируем  в неё mod_wl_22.so

3.       В папке  /etc/apache2/conf.d создаём конфиг примерно такого содержания:

LoadModule weblogic_module "/etc/apache2/modules/mod_wl_22.so" 

<Location /console>
    SetHandler weblogic-handler
    WebLogicHost server
    WeblogicPort 7001
</Location>

           KeepAliveEnabled ON           KeepAliveSecs      30

                 

запросы к приложению console на 80 порту теперь перенаправляются на 7001 порт

4. Перезапускаем apache

                               rcapache2 reload

                Проверяем работоспособность

Третий способ.
Завернуть трафик с порта управляемого сервера на порт 80.

iptables -t nat -A PREROUTING -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080 

iptables -t nat -A PREROUTING -p udp -m udp --dport 80 -j REDIRECT --to-ports 8080

Пример конфигурирования домена Weblogic

Примеров конфтгурирования доменов Weblogic в сети достаточо много. К ним у меня есть только одно существенное дополнение. В сколько-нибудь production-среде weblogic сервера ассоциируются с машинами. AdminServer - тоже сервер, и его тоже неплохо бы расположить на машине. Лучше отдельной.

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

Перенос конфигурации домена

Немного теории о том какакие существуют утилиты для создания, модификации и переноса доменов weblogic.

1. Утилита config.sh - в процессе настройки домена не генерирует его с чистого листа. Она предоставляет интерфейс для редактирования шаблонов из папки

$DOMAIN_HOME/wlserver_10.3/common/templates/domains

и интерфейс добавления к существующему домену изменений на основе всё тех же шаблонов, сгенерированных, например, утилитой config_builder.sh
2. Утилита config_builder.sh генерирует шаблон домена целиком с возможностью добавлять собственные конфигурационные скрипты или генерирует шаблон изменений. Утилита может генерировать шаблон на основе существующего и работающего домена. Полученные с её помощью jar-архивы можно скормить config.sh или отредактировать с помощью консоли WLST.
3. C помощью weblogic.WLST можно сделать практически всё. В частности, можно отредактировать шаблон с доменом, используя те же самые команды конфигурирования, что и для развёрнутого домена.
Открываем шаблон:

wls:/offline/ > readTemplate('template.jar')

Редактируем

wls:/offline/base_domain > create('...')

Сохраняем

wls:/offline/base_domain >writeTemplate('newTemplate.jar')

 4. С помощью weblogic.WLST можно запускать jyton-скрипты. Этот способ переноса домена не использует шаблоны и не позволяет перносить дополнительные файлы и директории. Из основных его плюсов стоит отметить простоту использования. Вот пример команды, генерирующей скрипт:

$ configToScript('/path/to/domain','script.py')

и команды разворачивающей на его основе домен:

$ weblogic.WLST script.py

Стоит отметить, что скрипт перенесёт не только конфигурационные файлы, но и файлы с паролями, например boot.properties, если такой файл был создан.

5. Утилита pack позволяет создать архив для переноса домена целиком или для переноса отдельного его сервера. Генерируя архив для перноса управляемого сервера, утилита не включает в него некоторые файлы, например  SerializedSystemIni.dat. Об этом надо просто помнить и следовать инструкциям Oracle по поднятию Managed серверов.

6. В поставку weblogic включён так же скрипт clone.sh
Утилита клонирует файлы из каталога с доменом. Что именно копировать, можно указать в лежащем рядом конфигурационном файле clone.xml.
Важная особенность: можно воспользоваться этим способом только если совпадают директории установки приложений на development  и production средах. Я не очень углублялся в возможности этой утилиты. На первый взгляд она очень напоминает копирование.

7. При должном понимании того, что делаешь, можно перенсти сервер простым копированием файлов.

Oracle предлагает несколько способов разворачивания production-среды, видимо, намекая на то, что не нужно конфигурировать production домен от самого Simple Domain Template

Установка

Установка Weblogic достаточно проста, но есть несколько особенностей.

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

export JAVA_HOME=/opt/oracle/java/latest/bin/java

export PATH=$JAVA_HOME/bin:$PATH 

2.  для 64 битных систем указываем ключик  -d64. У меня это JAVA64=-d64
3. Я использовал файл ответов, отчего нашёл ещё одну "особенность" установки.
В файле ответов, предлагаемом Oracle, присутствуют линшние символы переноса строки.
Если копироваь файл со странички, и подсовывать в качестве файла ответов, получим ошибку

The local BEA product registry is corrupted

лечится очень просто. Удаляем все лишние пробелы в разделе "COMPONENT_PATHS" В итоге получаем что-то вроде

echo "<?xml version=\"1.0\" encoding=\"UTF-8\"?>
   <bea-installer>
     <input-fields>
       <data-value name=\"BEAHOME\" value=\"${BEA_HOME}\" />
       <data-value name=\"WLS_INSTALL_DIR\" value=\"${WL_HOME}\" />
       <data-value name=\"COMPONENT_PATHS\"
        value=\"WebLogic Server/Core Application Server|WebLogic Server/Administration Console|WebLogic Server/Configuration Wizard and Upgrade Framework|WebLogic Server/Web 2.0 HTTP Pub-Sub Server|WebLogic Server/WebLogic JDBC Drivers|WebLogic Server/Third Party JDBC Drivers|WebLogic Server/WebLogic Server Clients|WebLogic Server/WebLogic Web Server Plugins|WebLogic Server/UDDI and Xquery Support|WebLogic Server/Server Examples\"/>
       <data-value name=\"INSTALL_SHORTCUT_IN_ALL_USERS_FOLDER\" value=\"no\"/>
       <data-value name=\"LOCAL_JVMS\" value=\"${JAVA_HOME}\"/>
     </input-fields>
</bea-installer>" > /tmp/silent$$.xml

Запускаем

java ${JAVA64} -jar ${WL_DISTRIB} -mode=silent -silent_xml=/tmp/silent$$.xml

Готово.