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

  • Статья

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

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

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

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

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

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

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

Первым шагом в успешной миграции приложения WLS в Azure является выбор наиболее подходящего целевого объекта миграции. WLS работает хорошо на виртуальных машинах Azure или Служба Azure Kubernetes (AKS). Целевой объект виртуальной машины — самый простой выбор, так как он больше всего похож на локальное развертывание. Интерфейс администрирования и развертывания для виртуальных машин очень аналогичен тому, что у вас есть в локальной среде. Компромисс для этой простоты является экономической стоимостью. Как правило, затраты на минуту решения на основе виртуальных машин выше по сравнению с AKS. Хотя решение на основе AKS стоит меньше для запуска, необходимо ограничить приложение в соответствии с требованиями AKS. Если минимизация изменений является самым важным фактором для усилий по миграции, рассмотрите возможность миграции на основе виртуальной машины. В этом случае см. статью "Миграция приложений WebLogic в Azure Виртуальные машины". Если вы можете терпеть преобразование приложения в Kubernetes для снижения затрат на среду выполнения, рассмотрите возможность миграции на основе AKS. В этом случае перейдите к Служба Azure Kubernetes приложениям WebLogic Server для миграции.

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

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

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

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

Текущая версия WebLogic должна быть совместимой с версией в предложениях IaaS. Чтобы просмотреть предложения для WebLogic версии 12.2.1.4, выполните запрос к Azure Marketplace для Oracle WebLogic 12.2.1.4. Если существующая версия 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

Примечание.

При миграции на виртуальные машины Azure на виртуальных машинах Azure требования к определенным версиям Java определяются предварительно установленным Java на виртуальных машинах. При миграции в WLS в AKS определенная версия Java определяется выбранным образом контейнера. Существует широкий спектр вариантов, но все они используют Oracle JDK.

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

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

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

Основной единицей конфигурации на сервере 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. Дополнительные сведения см. в разделе "Использование службы сообщений Java 1.1" с Служебная шина Azure standard и AMQP 1.0.

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

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

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

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

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

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

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

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

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

Определение того, используется ли 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.

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

Текущий набор предложений 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. При выборе размера виртуальной машины важно учитывать все аспекты (память, процессор, диск). Дополнительные сведения см. в документации Azure по определению размера виртуальных машин.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Большинство приложений используют какие-либо механизмы аутентификации и авторизации. Если вы используете LDAP для проверки подлинности, вы можете настроить доменные службы Microsoft Entra с помощью безопасного ПРОТОКОЛА LDAP и настроить подключения LDAP в WebLogic Server. Дополнительные сведения см. в статье "Создание и настройка управляемого домена доменных служб Microsoft Entra" и настройка защищенного LDAP для управляемого домена доменных служб Microsoft Entra.

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

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

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

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

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

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

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

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

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

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