Миграция WebSphere Deployment с IBM WebSphere Application Server Network Deployment версии 6 на версию 7 в AIX 6.1

В этой статье рассмотрены вопросы и решения, касающиеся миграции сложных сетевых конфигураций IBM WebSphere® Application Server Network Deployment (ND) с версии 6 на версию 7 на платформе AIX® 6.1 Эта статья будет полезна системным администраторам WebSphere и AIX, которым приходится сталкиваться с теми или иными вопросами миграции.

Вивек Арора, старший руководитель программы WebSphere Accelerated Value, IBM

Вивек Арора (Vivek Arora) – старший руководитель программы WebSphere Accelerated Value, работает в IBM Software Group Services, Канберра, Австралия. Его текущими задачами являются оказание заказчикам стратегических услуг и услуг по расширению возможностей архитектуры, интеграции и миграции, управлению проблемами, а также техническая поддержка по направлениям Infrastructure, Message Oriented Connectivity and Business Process Management и Service Oriented Architecture (SOA).



08.04.2013

Краткий обзор миграции WebSphere Network Deployment

Миграция WebSphere может быть выполнена при помощи мастера или специальных команд. Хотя мастер миграции позволяет стандартным образом переносить профили в местоположение по умолчанию, команды окажутся полезными в тех случаях, когда профили переносятся за пределы установочного дерева.

Рисунок 1. Мастер миграции
Мастер миграции

Для миграции приложений и конфигураций в кластерных средах с помощью автоматических сценариев системные администраторы, как правило, могут воспользоваться командами WASPreUpgrade и WASPostUpgrade, что может являться предпочтительным способом. Эти команды позволяют копировать существующие конфигурации среды WebSphere Application Server Network Deployment V6, включая значения по умолчанию и настройки (порты, параметры JVM и т. д.), и объединять их с новыми конфигурациями среды WebSphere Application Server Network Deployment V7.

Команда WASPreUpgrade создает резервную копию конфигурации WebSphere Application Server V6, а команда WASPostUpgrade переносит ее в среду WebSphere Application Server V7. Прежде чем внести какие-либо изменения, команда WASPostUpgrade также создает резервную копию среды WebSphere Application V7; при возникновении ошибок в процессе миграции выполняется откат любых изменений.

Рисунок 2. Процедура миграции с использованием команд WASPreUpgrade и WASPostUpgrade
Процедура миграции с использованием команд WASPreUpgrade и WASPostUpgrade

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

В процессе миграции с Deployment Manager V6.0 на Deployment Manager V7.0 номера портов (включая номер порта коннектора SOAP) по умолчанию не изменяются. Любые потенциальные конфликты, связанные с портами, можно исправить с помощью параметра -replacePorts команды WASPostUpgrade.

Топологии развертывания больших сетей WebSphere

Топология сетевого развертывания WebSphere состоит из менеджера развертывания (deployment manager) с одним или несколькими узлами, на которых располагаются серверы приложений. Большие развертывания зачастую состоят из сотен серверов приложений, работающих на множестве узлов. Примером большой сети может являться среда с 30 или, например, 60 узлами, каждый из которых содержит 20 серверов и управляется одним менеджером развертывания. Другой пример – 25 узлов, содержащих как минимум по одному серверу приложений. В примере этой статьи мы будем использовать относительно небольшую, но сложную топологию в кластерной среде, которая описывается в следующем разделе.

Сложная топология, используемая в примере этой статьи

Мы будем выполнять миграцию в среде со следующей сложной топологией:

  • Один менеджер развертывания управляет 8 узлами серверов AIX в кластерной среде; на каждом узле запущено 2 экземпляра сервера приложений. Другими словами, кластер состоит из 1 менеджера развертывания, 8 агентов узлов и 16 экземпляров WebSphere Application Server. Сервер менеджера развертывания и серверы приложений являются виртуальными.
  • На одном из серверов AIX вместе с менеджером развертывания располагается управляемый сервер приложений WebSphere Application Server. J2EE-приложения с компонентами Message Driven Beans (MDB) развернуты на независимых серверах приложений WAS(MDB).
Рисунок 3. Топология WebSphere Deployment, используемая в примере этой статьи
Топология WebSphere Deployment, используемая в примере этой статьи

Оперативное управление сложной топологией

Менеджер развертывания (например, DMGR1) направляет запрос на обслуживание отдельному серверу приложений следующим образом: запрос передается агенту узла, на котором расположен сервер приложений, а затем уже самому серверу приложений. Менеджер развертывания взаимодействует только с агентом узла, а каждый агент узла взаимодействует с соответствующим сервером приложений, например WAS1 или WAS (MDB).

Компоненты рабочей среды

  • WebSphere Application Server Network Deployment V6.0.2 (существующий).
  • WebSphere Application Server Network Deployment V7.0.0.13 (новый).
  • AIX 6.1
  • IBM CICS® 3.2
  • LDAP
  • IBM DB2®
  • WebSphere MQ V6
  • Параметр Global Security в WebSphere Application Server V6 отключен.
  • Безопасность в WebSphere Application Server V7.0 Deployment Manager отключена на время выполнения миграции.

План миграции

  • Создать профили в среде WebSphere Application Server Network Deployment V7:
    • Профиль Deployment Manager – менеджер развертывания, управляющий серверами приложений в кластере.
    • Профили Application Server:
      • Серверы приложений в кластерной среде, объединенные в единый кластер.
      • Сервер приложений, работающий отдельно от серверов кластерной среды и управляемый менеджером развертывания.
  • Выполнить миграцию менеджера развертывания из WebSphere Application Server Network Deployment V6 в WebSphere Application Server Network Deployment V7.
  • Выполнить миграцию узлов серверов приложений кластера из WebSphere V6 в новый экземпляр WebSphere V7 и объедините их с новым менеджером развертывания WebSphere Application Server Network Deployment V7.
  • Выполнить миграцию отдельного сервера приложений вместе с приложениями MDB J2EE.

Подготовительные действия перед миграцией Network Deployment

  • Убедитесь в том, что имеется достаточно дискового пространства для хранения двоичных файлов и профилей WebSphere Application Server V6 и WebSphere Application Server V7.
  • Обеспечьте разрешения на чтение, запись и создание для двоичных файлов WebSphere и Update Installer.
  • Установите WebSphere Application Server Network Deployment V7 и создайте профили менеджера развертывания и серверов приложений (см. раздел "План миграции").
  • Для успешной миграции требуется активное подключение к менеджеру развертывания, поэтому менеджер развертывания WebSphere V7должен быть установлен и запущен.
  • Если ранее предпринималась и была прервана попытка миграции профиля сервера приложений WebSphere V7, необходимо выполнить очистку профиля : для этого можно либо восстановить профиль из резервной копии, либо создать новый профиль перед тем, как выполнять новую попытку. За дополнительной информацией обратитесь к разделу этой статьи "Выполнение очистки после неудавшейся попытки миграции".

Этапы миграции

Утилиты и команды, необходимые в процессе миграции, находятся в директории WebSphere V7 /bin (например, '/usr/Websphere/AppServer/v7.0_app1/bin'). При использовании команд WASPreUpgrade и WASPostUpgrade можно указывать параметр -traceString для включения трассировки кода. В нашем примере были использованы следующие команды:

Листинг 1. Команда WASPreUpgrade
/usr/WebSphere/AppServer/v7.0_MNQ/bin >>  ./WASPreUpgrade.sh
/waslogs/was6_to_was7/migration/migration_ABCD_MNQ_app01_026
/usr/Websphere/AppServer/v6.0_MNQ 
-oldProfile ABCD_MNQ_app01
-traceString "*=all=enabled"   
-traceFile /waslogs/was6_to_was7/trace/WASPreUpgrade_trace.log

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

Листинг 2. Команда manageprofiles
/usr/WebSphere/AppServer/v7.0_MNQ/bin >>   ./manageprofiles.sh 
-create -profileName ABCD_MNQ_temp 
-profilePath   /var/opt/websphere/profiles/ABCD_MNQ _temp 
-cellName ABCD_MNQ_cell01      
-portsFile /tmp/ports_file.txt -hostName 026 -nodeName    ABCD_MNQ_app01_026

Команда manageprofiles создает профиль.

Листинг 3. Команда WASPostUpgrade
/usr/WebSphere/AppServer/v7.0_MNQ/bin >> ./WASPostUpgrade.sh    
/waslogs/was6_to_was7/migration/migration_ ABCD_MNQ_app01_026   
-oldProfile ABCD_MNQ_app01 
-profileName ABCD_MNQ_temp 
-traceString   "*=all=enabled" 
-traceFile  /waslogs/was6_to_was7/trace/WASPostUpgrade_trace.log

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

Возможные проблемы и их решения

Проблема. Во время миграции сервера приложений команда WASPreUpgrade завершилась с ошибкой MIGR0484E/MIGR0272E.

Листинг 4. Ошибка миграции MIGR0484E/MIGR0272E
IBM WebSphere Application Server, Release 7.0
Product Upgrade PreUpgrade tool, Version 1.0
Copyright IBM Corp., 1997-2008
MIGR0300I: The migration function is starting to save the existing 
Application Server environment.
MIGR0302I: The existing files are being saved.
MIGR0484E: No profiles or instances found with name ABCD_MNQ_app01.
MIGR0001I: The class name of the WASPreUpgrade command is WASPreUpgrade
MIGR0272E: The migration function cannot complete the command.

Перед возникновением этой ошибки были выполнены следующие действия:

  • Менеджер развертывания WebSphere Application Server V7 был запущен и находился в работающем состоянии, а агенты узлов и серверы приложений WebSphere Application Server V6 были остановлены.
  • Менеджер развертывания был успешно мигрирован с WebSphere Application Server версии 6 на версию 7.

Решение. Для устранения этой ошибки убедитесь в том, что в WebSphere Application Server V6 не была запущена команда wasprofile (для этого запустите команду ps-ef|grep java), а также в том, что в реестре профилей выполняется правильное сопоставление с профилем ABCD_MNQ_app01 (для этого просмотрите содержимое файла profileRegistry.xml, расположенного в директории '/usr/WebSphere/AppServer/v6.0_MNQ/properties').

Листинг 5. Файл ProfileRegistry.xml
profile isDefault="true" name="ABCD_MNQ_app01"           
path="/var/opt/websphere/profiles/ABCD_MNQ_app01"
template="/usr/Websphere/AppServer/v6.0_MNQ/profileTemplates/managed"

Также убедитесь в отсутствии в этой директории файла profileRegistry.xml_LOCK.

После выполнения всех необходимых проверок было обнаружено, что профиль ABCD_MNQ_app01 не был связан с директорией fsdb, вследствие чего процесс миграции завершился с ошибкой. Для исправления этой ситуации в домашнюю директорию WAS_HOME Directory /properties/fsdb был скопирован следующий сценарий:

Листинг 6. Сценарий, скопированный в директорию fsdb
#!/bin/sh 
WAS_USER_SCRIPT=/var/opt/websphere/profiles/ABCD_MNQ_app01/bin/setupCmdLine.sh
export WAS_USER_SCRIPT

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

Проблема. Команда WASPostUpgrade завершилась с ошибкой MIGR0286E, вызванной исключением Illegal State Exception.

Листинг 7. Ошибка миграции MIGR0286E, вызванная исключением java.lang.IllegalStateException
DSRA7602I: Attempting to delete newly created Derby database 
/var/opt/websphere/profiles/ABCD_MNQ_app701/databases/ABCD_MNQ_app01_027.
ABCD_MNQ_app01_027_s01-ImmediateBatchBus_027_s01_122132600_

CLOUDSCAPE_MIGRATION_DELETION_DONE
java.lang.IllegalStateException: java.lang.IllegalStateException:
Depth value 3 must be set
at com.ibm.ws.runtime.component.VariableMapImpl.reload(VariableMapImpl.java:238)
at com.ibm.ws.runtime.component.VariableMapImpl.refresh(VariableMapImpl.java:152)...
at com.ibm.ws.migration.postupgrade.WASPostUpgrade.restore(WASPostUpgrade.java:246)
at com.ibm.ws.migration.postupgrade.WASPostUpgrade.main(WASPostUpgrade.java:539)
      
Caused by: com.ibm.websphere.management.exception.RepositoryException: 
com.ibm.websphere.management.filetransfer.client.TransferFailedException: 
Error occurred during upload to: upload/cells/ABCD_MNQ _cell01/nodegroups/
DefaultNodeGroup/nodegroup.xml. 
Exception: java.io.IOException: Read error

Caused by: java.io.IOException: Read error
at java.io.FileInputStream.read(FileInputStream.java:191)
at com.ibm.ws.management.repository.TempFileInputStream.read
(TempFileInputStream.java:91)
at com.ibm.websphere.management.repository.RepositoryInputStream.read
(RepositoryInputStream.java:120)...
at com.ibm.ws.management.filetransfer.client.FileTransferClientImpl.uploadFile
(FileTransferClientImpl.java:302)
.. 30 more

MIGR0286E: The migration failed to complete.

Решение. Синхронизация завершилась с ошибкой из-за того, что системный пользователь столкнулся с ограничением файловых обработчиков в среде AIX. Для решения этой проблемы значение параметра AIX nofiles (т. е. ulimit -n) было увеличено с 2000 (значение по умолчанию) до 10000.

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

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

Проблема. Процесс миграции завершился ошибкой с сообщением 'network connection reset' или 'network read error'. Во время загрузки одного из файлов в процессе миграции было сброшено сетевое подключение, в результате чего загрузка файла завершилась ошибкой. Сообщение об ошибке было передано компоненту, отвечающему за миграцию, и процесс миграции был прерван. Бывали ситуации, когда передавалось сообщение чтения по сети, после чего процесс миграции также прерывался (это случалось при обработке уже других файлов). Все эти признаки указывали на разрыв сетевого подключения между узлом и менеджером развертывания в процессе миграции.

Решение. На первый взгляд можно было бы говорить о наличии проблем с сетью, поскольку менеджер развертывания обрывал соединение, и именно так это воспринимал мигрирующий узел. Однако это предположение было отброшено, поскольку сервер менеджера развертывания и сервер приложений являются виртуальными серверами, работающими под управлением гипервизора. На самом деле проблема была вызвана превышением менеджером развертывания максимального количества входящих подключений, разрешенных для канала. Эта причина была установлена после изучения log-файла менеджера развертывания SystemOut, в котором содержались записи о том, что для TCP-канала 'TCP_1' было превышено максимальное количество открытых подключений, равное 100.

Настройки этого параметра изображены на следующих рисунках.

Рисунок 4. Максимальное количество открытых подключений для TCP-канала на порту WC_adminhost
Максимальное количество открытых подключений для TCP-канала на порту WC_adminhost
Рисунок 5. Максимальное количество открытых подключений для TCP-канала на порту WC_adminhost_secure
Максимальное количество открытых подключений для TCP-канала на порту WC_adminhost_secure

Данная проблема была решена путем увеличения на время миграции максимального количества открытых подключений TCP-канала со 100 до 20000 для портов WC_adminhost и WC_adminhost_secure.

Проблема. При проверке на предмет корректного выполнения миграции на одном из серверов приложений не смог запуститься процесс 'ibmasyncrsp'.

Листинг 8. Ошибка запуска системного приложения 'ibmasyncrsp'
00000021 ApplicationMg A   WSVR0200I: Starting application: ibmasyncrsp 
00000021 ApplicationMg A   WSVR0203I: 
Application: ibmasyncrsp  Application build level: 1 [2] 
00000020 ApplicationMg A   WSVR0200I: Starting application: MNQ_v3.30_HF11 
ApplicationMg A   WSVR0204I: Application: MNQ_v3.30_HF11  
Application build level: Unknown 
00000021 FfdcProvider  W com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: 
FFDC Incident emitted 
00000021 DeployedAppli W   WSVR0206E: Module, ibmasyncrsp.war, of application, 
ibmasyncrsp.ear/deployments/ibmasyncrsp, failed to start 
00000021 ApplicationMg W   WSVR0101W: An error occurred starting, ibmasyncrsp 
00000021 ApplicationMg A   WSVR0217I: Stopping application: ibmasyncrsp 
00000021 FfdcProvider  W  com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: 
FFDC Incident   emitted

Решение. В нашем примере перед началом миграции значение "default_host" было изменено через консоль администрирования с 'default_host' на 'MNQ_default_host', и сопоставление виртуального хоста для приложения было изменено соответствующим образом. Тем не менее после выполнения миграции казалось, что системное приложение все еще ссылается на значение 'default_host' вместо значения 'MNQ_default_host', а в процессе трассировки запуска сервера приложений было получено следующее сообщение: "open for e-business, problems occurred during startup".

Выяснилось, что системное приложение 'ibmasyncrsp.ear', предназначенное для получения асинхронных сообщений SIBus и Web-сервисов, было сопоставлено хосту по умолчанию 'default_host', а не требуемому виртуальному хосту 'MNQ_default_host'.

Листинг 9. Сопоставление системного приложения ibmasyncrsp.ear
profile_root>/config/cells/ELN1_mwp_cell01/applications/ibmasyncrsp.ear   
/deployments/ibmasyncrsp/ibmasyncrsp.war/WEB-INF/ibm-web-bnd.xmi 

 com.ibm.ejs.models.base.bindings.webappbnd:WebAppBinding 
 xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" 
 xmlns:com.ibm.ejs.models.base.bindings.webappbnd="webappbnd.xmi" 
 xmi:id="WebAppBinding_1155152745161" virtualHostName="default_host"

Поскольку приложение WebSphere ('ibmasyncrsp.ear') не было доступно из консоли администрирования, файл ibm-web-bnd.xml был изменен таким образом, чтобы указывать на требуемый виртуальный хост 'MNQ_default_host'.

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

Проблема. После выполнения миграции шифр протокола TLS (Transport Layer Security), использовавшийся в WebSphere Application Server V6, невозможно использовать в WebSphere Application Server V7, если не включить поддержку федерального стандарта обработки информации США (FIPS, Federal Information Processing Standard) для повторного подключения сервера MDB-приложений к WebSphere MQ V6.

Решение. Была поставлена задача найти шифр, который можно было бы использовать как в WebSphere Application Server V7, так и в WebSphere MQ V6 без необходимости включения поддержки FIPS. Названия шифров в спецификации SSL (Secure Sockets Layer) CipherSpecs, используемой в WebSphere MQ V6, отличаются от имен тех же шифров в WebSphere Application Server V7, поэтому был выполнен поиск совместимых шифров. В результате потребовалось изменить параметры раздела “SSL configurations” на странице "Quality of protection (QoP) settings" в конфигурации WebSphere Application Server V7. Конфигурация WebSphere MQ V6 SSL для каналов также была изменена и настроена на использование нового шифра.

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

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

WebSphere Application Server V7

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

Листинг 10. Команда 'manageprofiles' для удаления профиля
/install_root/v7.0/bin/>> 
./manageprofiles.sh -delete -profileName NewProfileNameForVersion7

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

Листинг 11. Поиск поддиректорий профиля, которые необходимо удалить
/install_root/profiles/NewProfileNameForVersion7/>> ls -la

Существующая директория профиля также должна быть удалена. Следует оставить только поддиректорию с log-файлами.

Листинг 12. Удаление директорий профиля
/install_root /profiles/NewProfileNameForVersion7>>cd ..
/install_root /profiles/>> rm -r NewProfileNameForVersion7

WebSphere Application Server V6

Здесь нам придется удалить резервную директорию (например, /waslogs/was6_to_was7/migration), созданную командой WASPreUpdgrade. В качестве альтернативного варианта можно указать другую резервную директорию при следующем запуске этой команды (например, /waslogs/was6_to_was7/migration1).

Заключительные действия после миграции и проверка

  • Остановите и запустите менеджер развертывания в WebSphere V7. Запустите консоль администрирования и выберите System administration > nodes для проверки того, что новый узел был перенесен в WebSphere V7.
  • Удалите старые настройки JVM из профилей WebSphere Application Server V7 – аргументы JVM, переносимые из JVM версии 1.4.2, не используются в JVM версии 1.6, и их следует удалить. Некоторые из таких параметров:
    • -Xloratio0.2
    • -Xp32K,4K
    • -Xminf0.25
    • -Xpartialcompactgc
    • -Xk64000
  • Установите максимальное количество открытых подключений TCP-канала для WC_adminhost и WC_adminhost_secure равным 100.
  • Отслеживайте производительность с помощью средства compressed references, доступного в JVM версии 1.6. Для включения мониторинга удалите параметр командной строки JVM "-Xcompressedrefs".
  • Проверьте и убедитесь, что в WebSphere Application Server V7 Deployment Manager включена безопасность (параметр security установлен в 'on'), а безопасность шины service integration bus в данной топологии отключена.
  • Проверьте конфигурацию SSL в WebSphere Application Server V7.
  • Убедитесь в том, что серверы приложений запускаются и развернутые приложения правильно работают.

Заключение

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

Ресурсы

Научиться

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы в первый раз заходите в developerWorks. Выберите данные в своем профиле (имя, страна/регион, компания) которые будут общедоступными и будут отображаться, когда вы публикуете какую-либо информацию. Вы можете изменить данные вашего ИБМ аккаунта в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere
ArticleID=863897
ArticleTitle=Миграция WebSphere Deployment с IBM WebSphere Application Server Network Deployment версии 6 на версию 7 в AIX 6.1
publish-date=04082013