Миграция приложений WebLogic в Виртуальные машины Azure

Узнайте о том, что следует учитывать при миграции существующего приложения WebLogic для выполнения в Виртуальных машинах Azure. Общие сведения о доступных решениях WebLogic Server в Azure Marketplace см. в статье Что представляют собой решения для запуска Oracle WebLogic Server на виртуальных машинах Azure.

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

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

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

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

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

Определение того, можно ли использовать готовые предложения Marketplace в качестве отправной точки

Oracle и Майкрософт совместно работают над созданием в Azure Marketplace набора шаблонов для решений Azure, с помощью которых можно начать миграцию в Azure. См. документацию по Oracle Fusion Middleware, чтобы изучить список предложений и выбрать то, которое в наибольшей степени отвечает требованиям существующего развертывания. Список предложений см. в статье Что такое Oracle WebLogic Server в Azure.

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

Определение совместимости с версией WebLogic

Текущая версия WebLogic должна быть совместимой с версией в предложениях IaaS. Этот запрос отображает предложения для версии WebLogic 12.2.1.3. Если текущая версия WebLogic не совместима с этой версией, вам нужно будет вручную воспроизвести развертывание на основе ресурсов IaaS Azure. См. сведения в документации по Azure.

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

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

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

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

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

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

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

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

При использовании всех путей миграции в WebLogic в Azure требуется определенная соответствующая версия Java. Вам нужно проверить, может ли приложение правильно работать с этой поддерживаемой версией.

Примечание

Эта проверка особенно важна, если на текущем сервере используется неподдерживаемая версия JDK (например, Oracle JDK или IBM OpenJ9).

Чтобы получить текущую версию Java, войдите на сервер в рабочей среде и выполните следующую команду:

java -version

Примечание

При миграции на WebLogic на виртуальных машинах Azure требования к определенным версиям Java зависят от предварительно установленных версий Java на виртуальных машинах.

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

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

Инспекция конфигурации домена

Основной единицей конфигурации на сервере WebLogic Server является домен. Следовательно, файл config.xml содержит множество конфигураций, которые необходимо внимательно проверить перед миграцией. Файл содержит ссылки на дополнительные XML-файлы, которые хранятся в подкаталогах. Oracle рекомендует использовать консоль администрирования для настройки управляемых объектов и служб WebLogic Server, а также включить для сервера WebLogic Server поддержку файла config.xml. См. сведения о файлах конфигурации домена.

В приложении

Проверьте файлы WEB-INF/weblogic.xml и (или) WEB-INF/web.xml.

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

Если работа приложения зависит от репликации сеансов с помощью модуля Oracle Coherence*Web или без него, у вас есть три варианта:

  • Coherence*Web может выполняться параллельно с WebLogic Server на виртуальных машинах Azure, но такой вариант нужно настроить вручную после подготовки предложения. Coherence также может выполняться на виртуальных машинах Azure отдельно, но и этот вариант нужно настроить вручную после подготовки предложения.
  • Выполните рефакторинг приложения, чтобы использовать базу данных для управления сеансами.
  • Выполните рефакторинг приложения, чтобы перенести сеанс в службу Redis Azure. См. сведения на странице с ценами на Azure Cache for Redis.

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

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

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

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

См. руководство по использованию драйверов JDBC с WebLogic Server.

Определение того, была ли настроена платформа WebLogic

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

  • Были ли изменены скрипты запуска? Эти скрипты включают setDomainEnv, commEnv, startWebLogic и stopWebLogic.
  • Есть ли какие-либо определенные параметры, передаваемые в виртуальную машину Java?
  • Есть ли JAR-файлы, включенные в путь к классу сервера?

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

Если жизненный цикл приложения предполагает управление на основе REST, вам нужно определить, какие порты используются для доступа к REST API и как они проходят проверку подлинности и предоставляются. После миграции необходимо убедиться, что эти порты и механизмы проверки подлинности предоставлены, чтобы жизненный цикл приложения соответствовал тому, который был до миграции. См. руководство по администрированию сервера Oracle WebLogic Server с помощью служб управления RESTful.

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

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

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

Если приложение использует очереди или разделы JMS, их необходимо перенести на внешний размещенный сервер JMS. Использование Служебной шины Azure и Расширенного протокола управления очередью сообщений — это подходящая стратегия миграции для тех, кто работает с JMS. Сведения см. в руководстве по использованию JMS со Служебной шиной Azure и AMQP 1.0.

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

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

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

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

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

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

Если вы использовали пакеты OSGi, добавленные на сервер WebLogic Server, вам нужно будет добавить аналогичные JAR-файлы непосредственно в приложение.

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

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

Определение того, используется ли Oracle Service Bus

Если приложение использует Oracle Service Bus (OSB), необходимо определить настройки этой службы. См. руководство по установке Oracle Service Bus.

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

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

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

Если приложение упаковано как EAR-файл, обязательно проверьте файлы application.xml и weblogic-application.xml, определив их конфигурации.

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

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

Определение того, используется ли WebLogic Scripting Tool (WLST)

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

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

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

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

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

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

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

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

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

Хотя это очень обширная тема, следующие ресурсы помогут вам спланировать миграцию:

  • Список общих статей, которые имеют отношение к переносу топологии сети в Azure: Fast Track Deployment Guide (Руководство по развертыванию Fast Track).
  • Рекомендации по кластеризации, которая влияет на топологию сети: WebLogic Server Clustering (Кластеризация WebLogic Server).
  • Так как источники данных в системе WebLogic представляют собой отдельные серверы, их необходимо учитывать при анализе топологии сети: Источники данных в WebLogic Server.
  • Источники служб сообщений также являются отдельными серверами: Обмен сообщениями в WebLogic Server.
  • Балансировка нагрузки В следующем документе описана балансировка нагрузки на стороне WebLogic Server: Load Balancing in a Cluster (Балансировка нагрузки в кластере).

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

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

Учетная запись для использования настраиваемых поставщиков услуг безопасности и JAAS

Если приложение использует JAAS, убедитесь, что конфигурация поставщиков безопасности правильно перенесена. См. руководство по настройке поставщиков услуг безопасности WebLogic Security в документации по Oracle.

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

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

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

Балансировка нагрузки является важнейшей частью процесса переноса кластера Oracle WebLogic Server в Azure. Самым простым решением является использование встроенной поддержки Шлюза приложений Azure, предоставляемой в предложении Azure Marketplace для кластера Oracle WebLogic Server. Дополнительные сведения см. в статье Учебник. Перенос кластера серверов WebLogic Server в Azure с помощью Шлюза приложений Azure в качестве подсистемы балансировки нагрузки.

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

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

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

Миграция

Выбор предложения WebLogic в Виртуальных машинах Azure

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

Во время развертывания предложения вам будет предложено выбрать размер виртуальной машины для узлов WebLogic Server. При выборе размера виртуальной машины важно учитывать все аспекты (память, процессор, диск). Дополнительные сведения см. в документации Azure по определению размера виртуальных машин.

Отдельный узел WebLogic Server без сервера администрирования

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

Отдельный узел WebLogic Server с сервером администрирования

Это предложение подготавливает одну виртуальную машину и устанавливает на ней WebLogic Server. При этом создается домен и запускается сервер администрирования.

N-узловой кластер WebLogic Server

Это предложение создает высокодоступный кластер виртуальных машин WebLogic Server.

N-узловой динамический кластер WebLogic Server

Это предложение создает высокодоступный масштабируемый динамический кластер виртуальных машин WebLogic Server.

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

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

Миграция доменов

Подготовив предложение, изучите конфигурацию доменов и изучите инструкции по миграции доменов.

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

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

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

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

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

Подключившись к базам данных, вы можете настроить JMS согласно руководству по администрированию ресурсов JMS для сервера Oracle WebLogic Server с помощью Fusion Middleware.

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

Большинство приложений используют какие-либо механизмы аутентификации и авторизации. Если вы используете LDAP для аутентификации, WebLogic Server в Azure поддерживает автоматическую интеграцию. Предложение в Marketplace использует доменные службы Azure Active Directory (Azure AD DS) с защищенным протоколом LDAP. Предложение создает область по умолчанию для WebLogic Server из данных в Azure AD DS. Дополнительные сведения см. в статье Авторизация и аутентификация конечных пользователей для переноса приложений Java в WebLogic Server в Azure.

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

Используйте интеграцию с Elastic в Azure, предоставляемую предложением Oracle WebLogic Server в Azure Marketplace. Это самый простой способ ведения журнала. Полную версию учебника см. в статье Учебник. Перенос кластера WebLogic Server в Azure с помощью Elastic в Azure в качестве решения для ведения журнала. Список предложений можно просмотреть в обзорной статье Что представляют собой решения для запуска Oracle WebLogic Server на виртуальных машинах Azure.

Если интеграция службы Elastic невозможна, перенесите существующую конфигурацию ведения журнала при переносе домена. Сведения о том, как настроить уровни ведения журнала в java.util.logging, а также файлы журналов и фильтрацию сообщений журнала для Oracle WebLogic Server, см. в документации Oracle.

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

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

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

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

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

Действия после миграции

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