Поделиться через

Перенос приложений WebSphere в Azure Виртуальные машины

  • Статья

В этом руководстве описывается, что следует учитывать при переносе существующего традиционного приложения WebSphere Application Server (WAS) для запуска в Azure Виртуальные машины. Общие сведения о доступных традиционных решениях WAS в Azure Marketplace см. в статье "Что такое решения для запуска семейства продуктов IBM WebSphere в Azure?"

Подготовка к миграции

Чтобы обеспечить успешную миграцию, перед ее началом выполните шаги оценки и инвентаризации, описанные в следующих разделах.

Определение целевого состояние после миграции

Это руководство и соответствующие предложения Azure Marketplace являются отправной точкой для ускорения миграции традиционных рабочих нагрузок WAS в Azure. Перед выполнением этой процедуры важно все продумать. Возможно, вы хотите перенести существующую инфраструктуру в Виртуальные машины Azure по методике lift-and-shift? В таком случае всегда есть соблазн "улучшить" процедуру.

Но мы рекомендуем как можно точнее соблюдать принцип lift-and-shift, применяя описанные в этом руководстве требуемые изменения. Определите для себя целевое состояние миграции, чтобы вы точно знали, что достигли поставленной задачи. После завершения миграции можно создать моментальный снимок Виртуальные машины, как описано в статье "Создание моментального снимка виртуального жесткого диска". Убедившись, что вы можете успешно восстановить моментальный снимок, вы можете сделать улучшения без страха потерять ход миграции, который вы достигли до сих пор.

Убедитесь, что целевой объект является подходящим целевым объектом для усилий по миграции.

Первым шагом в успешной миграции приложения WAS в Azure является выбор наиболее подходящего целевого объекта миграции.

Традиционное работает в Azure Виртуальные машины. Целевой объект виртуальной машины — самый простой выбор, так как он больше всего похож на локальное развертывание. Интерфейс администрирования и развертывания виртуальных машин аналогиен тому, что у вас есть локально.

Другим вариантом является миграция в контейнеры путем преобразования традиционной рабочей нагрузки WAS в контейнеры приложений. Целевой объект контейнера можно запустить в Служба Azure Kubernetes (AKS) и Azure Red Hat OpenShift. Компромисс для этой простоты является экономической стоимостью.

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

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

Если вы можете терпеть преобразование приложения в контейнеры для снижения затрат на среду выполнения, рассмотрите возможность миграции на основе AKS или Azure Red Hat OpenShift.

Для миграции на основе AKS можно начать использование уровня "Бесплатный". Получение бесплатного управления кластерами и оплата только виртуальных машин, связанных с хранилищем и сетевыми ресурсами. В этом случае см. статью "Миграция приложений WebSphere в Служба Azure Kubernetes".

Для миграции на основе Azure Red Hat OpenShift в дополнение к затратам на вычисления и инфраструктуру узлы приложений имеют еще одну стоимость для компонента лицензии OpenShift. Эта плата взимается на основе количества узлов приложения и типа экземпляра. Используйте цены по запросу или зарезервированные экземпляры, независимо от того, что лучше всего соответствует потребностям рабочей нагрузки и бизнеса. В этом случае см. статью "Миграция приложений WebSphere в Azure Red Hat OpenShift".

Инструкции в документации по Azure Red Hat OpenShift охватывают некоторые аспекты, относящиеся к миграции. Полный список руководств см. в документации по Azure Red Hat OpenShift.

Определите, являются ли готовые предложения Azure Marketplace хорошим отправной точкой

IBM и Майкрософт сотрудничают с тем, чтобы перенести набор шаблонов решений Azure в Azure Marketplace, чтобы обеспечить надежную отправную точку для миграции в Azure. Список предложений см. в разделе "Запуск семейства продуктов WebSphere" и "Свобода" в Microsoft Azure, а затем выберите наиболее подходящий вариант для существующего развертывания. Список предложений см. в статье "Общие сведения о решениях для запуска семейства продуктов IBM WebSphere" в Azure?

Если ни одно из существующих предложений не является хорошей отправной точкой, необходимо воспроизвести развертывание вручную с помощью ресурсов виртуальной машины Azure. Пошаговые инструкции см. в руководстве. Вручную установите в Azure Виртуальные машины традиционное сетевое развертывание IBM WebSphere Application Server. См. сведения об IaaS.

Определение совместимости традиционной версии WAS

Существующая традиционная версия WAS должна быть совместима с версией в предложениях IaaS. Сведения о версии можно найти на странице обзора отдельного экземпляра IBM WebSphere Application Server на виртуальной машине Azure и кластере сервера приложений IBM WebSphere на виртуальных машинах Azure. Если существующая традиционная версия WAS несовместима с этой версией, необходимо воспроизвести развертывание вручную с помощью ресурсов IaaS Azure. См. сведения об IaaS.

Проверка емкости сервера

Определите характеристики оборудования текущих рабочих серверов (показатели памяти, ЦП и диска), а также среднее и пиковое количество запросов и объем потребляемых ресурсов. Эти сведения помогут вам выбрать размер виртуальной машины. Дополнительные сведения см. в статье Размеры для облачных служб.

Проверка всех секретов

До появления таких технологических решений "конфигурация как услуга", как Azure Key Vault, понятие "секреты" не было четко определено. Вместо этого предоставлялся разнородный набор параметров конфигурации, которые использовались в качестве того, что сейчас называется секретами. С такими серверами приложений, как WAS, эти секреты находятся во многих разных файлах конфигурации и хранилищах конфигурации. Проверьте все свойства и файлы конфигурации на рабочих серверах на наличие секретов и паролей. Кроме того, в приложении могут быть файлы конфигурации, содержащие пароли или учетные данные. WAS хранит данные конфигурации в нескольких документах в каскадной иерархии каталогов. Большинство документов конфигурации содержат XML-содержимое. Дополнительные сведения см. в разделах "Документы конфигурации" и основные понятия Azure Key Vault.

Проверка всех сертификатов

Определите все сертификаты, используемые для общедоступных конечных точек SSL. Вы можете просмотреть все сертификаты на рабочих серверах, выполнив следующую команду:

keytool -list -v -keystore <path to keystore>

Дополнительные сведения см. в руководстве по управлению сертификатами документов IBM в SSL

Проверка правильной работы поддерживаемой версии Java

Для использования WAS в Azure Виртуальные машины требуется определенная версия Java, поэтому необходимо убедиться, что приложение работает правильно, используя поддерживаемую версию.

IBM Java 8 поставляется с дистрибутивом WAS9. Мы рекомендуем использовать JRE, предоставляемый IBM. Дополнительные сведения см. в статье Java SE 8 в традиционном сервере приложений WebSphere Версии 9.

Если вы хотите переключиться на другой пакет SDK для Java, следуйте документу IBM, переключению пакета SDK Java на сервере приложений WebSphere.

Проверка ресурсов JNDI

Проверьте все ресурсы JNDI. Например, у источников данных, таких как базы данных, может быть связанное имя JNDI, которое позволяет JPA правильно привязывать экземпляры EntityManager к определенной базе данных. Дополнительные сведения о ресурсах и базах данных JNDI см . в документации IBM по источникам данных WebSphere. Для других ресурсов, связанных с JNDI, таких как брокеры сообщений JMS, может потребоваться выполнить миграцию или перенастройку. Дополнительные сведения о конфигурации JMS см. в разделе "Использование ресурсов JMS".

Проверка конфигурации профиля

Основной единицей конфигурации в WAS является профиль. Таким образом, файл resources.xml содержит множество конфигураций, которые необходимо тщательно рассмотреть для миграции. Файл содержит ссылки на дополнительные XML-файлы, хранящиеся в подкаталогах. IBM рекомендует обычно использовать консоль IBM для настройки управляемых объектов и служб WAS, а также разрешить WAS поддерживать папку профилей или имени профиля. Дополнительные сведения см. в разделе "Управление профилями в распределенных и операционных системах IBM i".

В приложении

Проверьте файл deployment.xml и/или ФАЙЛ WEB-INF/web.xml.

Определение того, используется ли репликация сеансов

Если приложение использует репликацию сеансов, у вас есть следующие параметры:

Для всех этих параметров рекомендуется понять, как выполняется репликация состояния сеанса HTTP. Дополнительные сведения см. в документации IBM по администрированию сеансов .

Определение источников данных

Если приложение использует какие-либо базы данных, необходимо определить следующие сведения:

  • имя источника данных;
  • конфигурация пула подключений;
  • путь к JAR-файлу драйвера JDBC.

Дополнительные сведения о драйверах JDBC в WAS см. в разделе "Использование драйверов JDBC с сервером приложений WebSphere".

Определение того, настроено ли значение WAS

Определите, какие из следующих настроек были сделаны.

  • Были ли изменены скрипты запуска? К таким сценариям относятся wsadmin, AdminControl, AdminConfig, AdminApp и AdminTask.
  • Есть ли какие-либо определенные параметры, передаваемые в виртуальную машину Java?
  • Есть ли JAR-файлы, включенные в путь к классу сервера?
  • Используются ли такие средства уровня ОС, как systemd для автоматического запуска компонентов WAS после перезапуска сервера?

Необходимо учитывать рекомендации по миграции в зависимости от ответов на эти вопросы.

Определение того, нужно ли подключаться к локальной среде

Если вашему приложению требуется доступ к какой-либо из локальных служб, вам необходимо подготовить одну из служб подключения Azure. Дополнительные сведения см. в статье Выбор решения для подключения локальной сети к Azure. Кроме того, необходимо выполнить рефакторинг приложения, чтобы использовать общедоступные API-интерфейсы, предоставляемые локальными ресурсами.

Определение того, используются ли очереди или разделы Java Message Service (JMS)

Если приложение использует очереди или разделы JMS, необходимо перенести их на внешний размещенный сервер JMS. Одной из стратегий использования JMS является использование Служебная шина Azure и расширенного протокола очереди сообщений. Дополнительные сведения см. в разделе "Использование службы сообщений Java 1.1" с Служебная шина Azure standard и AMQP 1.0.

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

Если вы используете IBM MQ, вы можете перенести это программное обеспечение в Azure Виртуальные машины и использовать его как есть.

Корпорация Майкрософт имеет решение для интеграции IBM MQ с Logic Apps. Дополнительные сведения см. в статье "Подключение к серверу IBM MQ" из рабочего процесса в Azure Logic Apps.

Определение того, используются ли настраиваемые общие библиотеки Java EE

Если вы используете общие библиотеки Java EE, у вас есть два варианта:

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

Определение того, используются ли пакеты OSGi

Если вы использовали пакеты OSGi, добавленные в WAS, необходимо добавить эквивалентные JAR-файлы непосредственно в веб-приложение.

Определение того, содержит ли приложение код, зависящий от ОС

Если приложение содержит любой код с зависимостями в ос узла, необходимо рефакторинговать его, чтобы удалить эти зависимости. Например, может потребоваться заменить любое использование / или \ в пути к файловой системе или File.Separator Paths.get , если ваше приложение работает в Windows.

Определение того, используется ли шина интеграции IBM

Если приложение использует IBM Integration Bus, необходимо записать, как настроена шина интеграции IBM. Дополнительные сведения см . в документации по IBM Integration Bus.

Определение того, состоит ли приложение из нескольких WAR-файлов

Если приложение состоит из нескольких WAR-файлов, их следует рассматривать как отдельные приложения, как описано в этом руководстве.

Определение того, упаковано ли приложение как EAR-файл

Если приложение упаковывается в виде ФАЙЛА EAR, обязательно изучите application.xml, ibm-application-bnd.xmi и ibm-application-ext.xmi-файлы и зафиксируйте их конфигурации. Дополнительные сведения см. в статье о создании пакета корпоративного архива (EAR) в WebSphere.

Определение всех внешних процессов и управляющих программ, запущенных на рабочих серверах

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

Определение того, используется ли файловая система и как именно она используется

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

Статическое содержимое только для чтения

Если ваше приложение сейчас обслуживает статическое содержимое, вам потребуется альтернативное расположение для этого статического содержимого. Вы можете переместить статическое содержимое в хранилище BLOB-объектов Azure и включить Azure CDN для быстрого скачивания в глобальном масштабе. Дополнительные сведения см. в статье "Размещение статических веб-сайтов" в служба хранилища Azure и кратком руководстве. Интеграция учетной записи хранения Azure с Azure CDN.

Динамически опубликованное статическое содержимое

Если приложение допускает использование статического содержимого, которое передается или создается приложением и после этого становится неизменяемым, вы можете использовать хранилище BLOB-объектов Azure и Azure CDN, как описано выше, с Функциями Azure для выполнения отправки и обновления CDN. Практический пример реализации см. в руководстве по отправке и предварительной загрузке статического содержимого CDN с помощью Функций Azure.

Определение топологии сети

Текущий набор предложений Azure Marketplace — это отправная точка для миграции. Если предложение не охватывает аспекты архитектуры, которую необходимо перенести, необходимо записать сетевую топологию существующего развертывания. Затем необходимо воспроизвести эту топологию сети в Azure даже после создания базового предложения с одним из шаблонов решений.

Топология сети является широкой темой, но следующие ссылки могут дать некоторое направление для ваших усилий по миграции:

  • В следующей ссылке перечислены разделы высокого уровня, относящиеся к миграции топологии сети в Azure: топологии сетевого развертывания webSphere Application Server.
  • Так как источники данных являются отдельными серверами в системе WAS, их необходимо рассматривать как часть анализа топологии сети. Дополнительные сведения см. в разделе "Источники данных сервера приложений WebSphere".
  • Источники служб сообщений также являются отдельными серверами: Дополнительные сведения см. в разделе "Топологии сети": взаимодействие с помощью поставщика обмена сообщениями WebSphere MQ.
  • Балансировка нагрузки Следующая ссылка охватывает сторону балансировки нагрузки WAS: кластеризация с балансировкой нагрузки webSphere Application Server Network Deployment.

Учетная запись использования адаптеров JCA и адаптеров ресурсов

Если существующее приложение использует адаптеры JCA или другие адаптеры ресурсов для подключения к другим корпоративным системам, убедитесь, что вы применяете конфигурацию этих артефактов к запущенной в Azure Виртуальные машины. Дополнительные сведения см. в разделе "Адаптеры реляционных ресурсов" и JCA в документации IBM.

Учет требований аутентификации и авторизации

Большинство приложений используют какие-либо механизмы аутентификации и авторизации. Если вы используете OpenID для проверки подлинности, можно настроить проверку подлинности OpenID для подключения с помощью идентификатора Microsoft Entra. Дополнительные сведения см. в разделе "Проверка подлинности OpenID Connect с помощью идентификатора Microsoft Entra".

Определение того, используется ли кластеризация WAS

Скорее всего, вы развернули приложение на нескольких серверах WAS, чтобы обеспечить высокий уровень доступности. Эти кластеры можно перенести непосредственно из локальной установки в WAS, запущенную в Azure Виртуальные машины. Дополнительные сведения см. в статье WebSphere Application Server Network Deployment в документации IBM.

Учет требований к балансировке нагрузки

Балансировка нагрузки является важной частью миграции кластера WAS в Azure. Проще всего использовать встроенную поддержку Шлюз приложений Azure или IBM HTTP Server, предоставляемых в предложении Azure Marketplace для кластера серверов приложений IBM WebSphere.

Сводка возможностей Шлюз приложений Azure по сравнению с другими решениями балансировки нагрузки Azure см. в разделе "Параметры балансировки нагрузки".

Определение того, используется ли клиент приложения Java EE

Если приложение использует клиент приложения Java EE, оно должно работать без изменений после миграции в Виртуальные машины Azure. См. руководство по использованию модулей клиентского приложения Java EE.

Миграция

Выбор традиционного предложения ВИРТУАЛЬНЫЕ МАШИНЫ в Azure

Следующие предложения доступны для WAS в Azure Виртуальные машины.

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

Подготовка предложения

Выбрав предложение для начала, подготовьте это предложение, выполнив инструкции по развертыванию кластера webSphere Application Server (традиционного) в Azure Виртуальные машины.

Перенос профилей

После подготовки предложения можно проверить конфигурацию профиля. Дополнительные сведения см . в разделе "Основные понятия " в документации IBM.

Подключение баз данных

После переноса профилей можно подключить базы данных, выполнив инструкции по настройке источника данных WebSphere Application Server в документации IBM.

Учет хранилищ ключей

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

Подключение источников JMS

После подключения баз данных можно настроить JMS, следуя инструкциям по настройке JMS в IBM WebSphere Application Server в документации IBM.

Учет требований аутентификации и авторизации

Большинство приложений используют какие-либо механизмы аутентификации и авторизации. Если вы используете OpenID для проверки подлинности, можно настроить проверку подлинности OpenID для подключения с помощью идентификатора Microsoft Entra. Дополнительные сведения см. в разделе "Проверка подлинности OpenID Connect с помощью идентификатора Microsoft Entra".

Учетная запись для ведения журнала

Вы можете настроить Elastic Stack, следуя инструкциям по анализу журналов сервера приложений WebSphere с помощью Elastic Stack в документации IBM. Azure обеспечивает поддержку Elastic. Дополнительные сведения см. в статье "Что такое интеграция Elastic с Azure? Вы можете объединить знания в этих двух ресурсах, чтобы достичь решения для ведения журналов, оптимизированного для Azure для WAS на виртуальных машинах.

Миграция приложений

Методики, которые группы разработки используют для развертывания приложений на тестовых, промежуточных и рабочих серверах, могут сильно отличаться. В некоторых случаях существует высокоразвитая платформа CI/CD, которая приводит к развертыванию приложений на сервере приложений WebSphere. В других случаях процесс частично может выполняться вручную. Одним из преимуществ использования Azure Виртуальные машины для переноса традиционных приложений WAS в облако является то, что существующие процессы продолжают работать.

Необходимо настроить группу безопасности сети, которая предоставляет предложение, чтобы разрешить доступ к конвейеру CI/CD или ручной системе развертывания. Дополнительные сведения см. в разделе Группы безопасности сети.

Тестирование

Для доступа к новым серверам, работающим в Azure, необходимо настроить все тесты в контейнере для приложений. Как и для CI/CD, здесь важно настроить правила безопасности сети, открывающие доступ к приложениям, развернутым в Azure, для тестирования. Дополнительные сведения см. в разделе Группы безопасности сети.

После миграции

После достижения целевого состояния миграции, которое вы определили на этапе подготовки к миграции, выполните комплексное приемочное тестирование и убедитесь, что все работает правильно. Рекомендации по некоторым потенциальным улучшениям после миграции см. в следующих рекомендациях.