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

Руководство по переносу Oracle WebLogic Server в Azure Виртуальные машины с высоким уровнем доступности и аварийного восстановления

  • Статья

В этом руководстве описан простой и эффективный способ реализации высокой доступности и аварийного восстановления (HA/DR) для Java с помощью Oracle WebLogic Server (WLS) в Azure Виртуальные машины (виртуальные машины). Решение показывает, как достичь низкой цели времени восстановления (RTO) и целевой точки восстановления (RPO) с помощью простого приложения Jakarta EE, работающего в WLS. Высокий уровень доступности и аварийного восстановления — это сложная тема с множеством возможных решений. Оптимальное решение зависит от уникальных требований. Другие способы реализации высокого уровня доступности и аварийного восстановления см. в конце этой статьи.

В этом руководстве описано следующее:

  • Используйте оптимизированные для Azure рекомендации по обеспечению высокой доступности и аварийного восстановления.
  • Настройте группу отработки отказа База данных SQL Microsoft Azure в парных регионах.
  • Настройка парных кластеров WLS на виртуальных машинах Azure.
  • Настройте Диспетчер трафика Azure.
  • Настройте кластеры WLS для обеспечения высокой доступности и аварийного восстановления.
  • Тестирование отработки отказа с первичного на вторичную.

На следующей схеме показана архитектура, которая вы создаете:

Схема архитектуры решения WLS на виртуальных машинах Azure с высоким уровнем доступности и аварийного восстановления.

Диспетчер трафика Azure проверяет работоспособность регионов и направляет трафик соответствующим образом на уровень приложений. Основной регион и дополнительный регион имеют полное развертывание кластера WLS. Однако только основной регион активно обслуживает сетевые запросы от пользователей. Дополнительный регион является пассивным и активируется для получения трафика только в том случае, если основной регион испытывает нарушение работы службы. Диспетчер трафика Azure использует функцию проверки работоспособности Шлюз приложений Azure для реализации этой условной маршрутизации. Основной кластер WLS выполняется, а вторичный кластер завершает работу. Геоотработка RTO уровня приложений зависит от времени запуска виртуальных машин и запуска дополнительного кластера WLS. RPO зависит от База данных SQL Azure, так как данные сохраняются и реплицируются в группе отработки отказа База данных SQL Azure.

Уровень базы данных состоит из группы отработки отказа База данных SQL Azure с первичным сервером и сервером-получателем. Основной сервер находится в активном режиме чтения и записи и подключен к основному кластеру WLS. Сервер-получатель находится в пассивном режиме только для готовности и подключен к вторичному кластеру WLS. Геоработка отказа переключает все базы данных-получатели в группе на основную роль. Сведения о географической отработки отказа RPO и RTO База данных SQL Azure см. в разделе "Обзор непрерывности бизнес-процессов".

Эта статья была написана с помощью службы База данных SQL Azure, так как в этой статье используются функции высокой доступности этой службы. Другие варианты базы данных возможны, но вы должны учитывать функции высокой доступности любой выбранной базы данных. Дополнительные сведения, включая сведения о том, как оптимизировать конфигурацию источников данных для репликации, см. в разделе "Настройка источников данных для oracle Fusion Middleware Active-Passive Deployment".

Необходимые компоненты

Настройка группы отработки отказа База данных SQL Azure в парных регионах

В этом разделе описано, как создать группу База данных SQL Azure отработки отказа в парных регионах для использования с кластерами и приложением WLS. В следующем разделе описана настройка WLS для хранения данных сеанса и данных журнала транзакций (TLOG) в этой базе данных. Эта практика согласуется с архитектурой максимальной доступности Oracle (MAA). Это руководство предоставляет адаптацию Azure для MAA. Дополнительные сведения об MAA см. в статье Oracle Maximum Availability Architecture.

Сначала создайте первичную База данных SQL Azure, выполнив действия портал Azure в кратком руководстве. Создание отдельной базы данных — База данных SQL Azure. Следуйте инструкциям, но не включая раздел "Очистка ресурсов". Используйте следующие инструкции, как описано в статье, а затем вернитесь к этой статье после создания и настройки База данных SQL Azure:

  1. Когда вы перейдете к разделу "Создание одной базы данных", выполните следующие действия.

    1. На шаге 4 для создания новой группы ресурсов сохраните значение имени группы ресурсов, например myResourceGroup.
    2. На шаге 5 для имени базы данных сохраните значение имени базы данных, например mySampleDatabase.
    3. На шаге 6 для создания сервера выполните следующие действия.
      1. Сохраните уникальное имя сервера, например sqlserverprimary-ejb120623.
      2. В поле Расположение выберите Восточная часть США.
      3. Для метода проверки подлинности выберите "Использовать проверку подлинности SQL".
      4. Сохраните значение входа администратора сервера, например azureuser.
      5. Сохраните значение пароля .
    4. На шаге 8 для среды рабочей нагрузки выберите "Разработка". Просмотрите описание и рассмотрите другие варианты рабочей нагрузки.
    5. На шаге 11 для избыточности хранилища резервных копий выберите локально избыточное хранилище резервных копий. Рассмотрим другие варианты резервного копирования. Дополнительные сведения см. в разделе избыточности хранилища резервных копий автоматических резервных копий в База данных SQL Azure.
    6. На шаге 14 в конфигурации правил брандмауэра для разрешения доступа к этому серверу служб и ресурсов Azure нажмите кнопку "Да".

  2. Когда вы перейдете к разделу "Запрос базы данных", выполните следующие действия.

    1. На шаге 3 введите сведения о входе администратора сервера проверки подлинности SQL для входа.

      Примечание.

      Если сбой входа с сообщением об ошибке, аналогичным клиенту с IP-адресом "xx.xx.xx", не разрешен доступ к серверу, выберите allowlist IP xx.xx.xx.xx на сервере <your-sqlserver-name> в конце сообщения об ошибке. Дождитесь завершения обновления правил брандмауэра сервера, а затем нажмите кнопку "ОК ".

    2. После выполнения примера запроса на шаге 5 очистите редактор и создайте таблицы.

Введите следующий запрос, чтобы создать схему для TLOG.

create table TLOG_msp1_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp2_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp3_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table wl_servlet_sessions (wl_id VARCHAR(100) NOT NULL, wl_context_path VARCHAR(100) NOT NULL, wl_is_new CHAR(1), wl_create_time DECIMAL(20), wl_is_valid CHAR(1), wl_session_values VARBINARY(MAX), wl_access_time DECIMAL(20), wl_max_inactive_interval INTEGER, PRIMARY KEY (wl_id, wl_context_path));

После успешного выполнения вы увидите сообщение о успешном выполнении: затронутые строки: 0.

Эти таблицы баз данных используются для хранения данных журнала транзакций (TLOG) и данных сеанса для кластеров и приложений WLS. Дополнительные сведения см. в статье Об использовании хранилища TLOG JDBC и использовании базы данных для постоянного хранилища (сохраняемость JDBC).

Затем создайте группу отработки отказа База данных SQL Azure, выполнив портал Azure действия, описанные в разделе "Настройка группы отработки отказа для База данных SQL Azure". Вам потребуется только следующие разделы: создание группы отработки отказа и тестирование плановая отработка отказа. Выполните следующие действия, как описано в статье, а затем вернитесь к этой статье после создания и настройки группы отработки отказа База данных SQL Azure:

  1. Когда вы перейдете к разделу "Создание группы отработки отказа", выполните следующие действия.

    1. На шаге 5 для создания группы отработки отказа выберите параметр для создания нового сервера-получателя, а затем выполните следующие действия.
      1. Введите и сохраните имя группы отработки отказа, например имя отказоустойчивой группы-ejb120623.
      2. Введите и сохраните уникальное имя сервера, например sqlserversecondary-ejb120623.
      3. Введите тот же администратор сервера и пароль, что и основной сервер.
      4. Для расположения выберите другой регион, отличный от региона, используемого для базы данных-источника.
      5. Убедитесь, что выбрана служба Azure для доступа к серверу .
    2. На шаге 5 для настройки баз данных в группе выберите базу данных, созданную на основном сервере, например mySampleDatabase.

  2. Завершив все действия в разделе "Тест тестирования плановая отработка отказа", откройте страницу группы отработки отказа и используйте ее для тестов отработки отказа кластеров WLS позже.

Настройка парных кластеров WLS на виртуальных машинах Azure

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

Настройка основного кластера WLS

Сначала откройте кластер Oracle WebLogic Server на виртуальных машинах Azure в браузере и нажмите кнопку "Создать". Вы увидите область "Основные сведения" предложения.

Чтобы заполнить область "Основные сведения", выполните следующие действия.

  1. Убедитесь, что значение, отображаемое для подписки , совпадает с ролями, перечисленными в разделе предварительных требований.
  2. Необходимо развернуть предложение в пустой группе ресурсов. В поле "Группа ресурсов" выберите "Создать" и введите уникальное значение для группы ресурсов, например wls-cluster-eastus-ejb120623.
  3. В разделе "Сведения об экземпляре" для региона выберите "Восточная часть США".
  4. В разделе Учетные данные для Виртуальные машины и WebLogic укажите пароль для учетной записи администратора виртуальной машины и администратора WebLogic соответственно. Сохраните имя пользователя и пароль администратора WebLogic.
  5. Оставьте значения по умолчанию для других полей.
  6. Нажмите кнопку "Далее", чтобы перейти к области конфигурации TLS/SSL.

Снимок экрана: портал Azure, на котором показан кластер Oracle WebLogic Server на панели

Оставьте значения по умолчанию в области конфигурации TLS/SSL, нажмите кнопку "Далее", чтобы перейти к области Шлюз приложений Azure, а затем выполните следующие действия.

  1. Для подключения к Шлюз приложений Azure?нажмите кнопку "Да".
  2. Чтобы выбрать нужный параметр TLS/SSL-сертификата, выберите "Создать самозаверяющий сертификат".
  3. Нажмите кнопку "Рядом", чтобы перейти к области "Сеть".

Снимок экрана: портал Azure, на котором показан кластер Oracle WebLogic Server на виртуальных машинах Azure Шлюз приложений Azure области.

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

  1. Выберите "Изменить виртуальную сеть". Сохраните адресное пространство виртуальной сети, например 10.1.4.0/23.

    Снимок экрана: портал Azure, на котором показан кластер Oracle WebLogic Server на виртуальная сеть виртуальных машинах Azure.

  2. Выберите wls-subnet , чтобы изменить подсеть. В разделе "Сведения о подсети" сохраните начальный адрес и размер подсети, например 10.1.5.0 и /28.

    Снимок экрана: портал Azure, на котором показан кластер Oracle WebLogic Server в подсети виртуальная сеть виртуальных машин Azure.

  3. При внесении изменений сохраните изменения.

  4. Вернитесь в панель "Сеть ".

  5. Нажмите кнопку "Рядом", чтобы перейти к области "База данных".

Ниже показано, как заполнить область базы данных :

  1. Для подключения к базе данных нажмите кнопку "Да".
  2. В поле "Выбор типа базы данных" выберите Microsoft SQL Server (поддержка подключения без пароля).
  3. Для имени JNDI введите jdbc/WebLogicCafeDB.
  4. Для строки подключения DataSource замените заполнители значениями, сохраненными в предыдущем разделе для основного База данных SQL, например jdbc:sqlserverprimary-ejb120623.database.windows.net:1433; database=mySampleDatabase.
  5. Для глобального протокола транзакций выберите "Нет".
  6. Для имени пользователя базы данных замените заполнители значениями, сохраненными в предыдущем разделе для основного База данных SQL, например azureuser@sqlserverprimary-ejb120623.
  7. Введите пароль для входа администратора сервера, сохраненный ранее для пароля базы данных. Введите то же значение для подтверждения пароля.
  8. Оставьте значения по умолчанию для других полей.
  9. Выберите Review + create (Просмотреть и создать).
  10. Дождитесь завершения последней проверки, а затем нажмите кнопку "Создать".

Снимок экрана: портал Azure, на котором показан кластер Oracle WebLogic Server на панели

Через некоторое время отобразится страница развертывания , на которой выполняется развертывание.

Примечание.

Если во время выполнения окончательной проверки возникли проблемы, исправьте их и повторите попытку.

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

В то же время можно настроить вторичный кластер WLS параллельно.

Настройка вторичного кластера WLS

Выполните те же действия, что и в разделе "Настройка основного кластера WLS", чтобы настроить вторичный кластер WLS в регионе "Западная часть США", за исключением следующих различий:

  1. В области "Основные сведения" выполните следующие действия.

    1. В поле группы ресурсов выберите "Создать" и введите другое уникальное значение для группы ресурсов, например wls-cluster-westtus-ejb120623.
    2. В разделе "Сведения об экземпляре" для региона выберите "Западная часть США".

  2. На панели "Сеть" выполните следующие действия.

    1. Для изменения виртуальной сети введите то же адресное пространство виртуальной сети, что и основной кластер WLS, например 10.1.4.0/23.

      Примечание.

      Появится предупреждение, аналогичное следующему: адресное пространство "10.1.4.0/23" (10.1.4.0 - 1.1.5.255)" перекрывается с адресным пространством "10.1.4.0/23" (10.1.4.0 - 10.1.5.255)" виртуальной сети "wls-vnet". Виртуальные сети с перекрывающимся адресным пространством не могут быть одноранговыми. Если вы планируете пиринговать эти виртуальные сети, измените адресное пространство 10.1.4.0/23 (10.1.4.0 - 1.1.5.255)". Это сообщение можно игнорировать, так как вам нужны два кластера WLS с одной конфигурацией сети.

    2. Введите wls-subnetтот же начальный адрес и размер подсети, что и основной кластер WLS, например 10.1.5.0 и /28.

  3. В области "База данных" выполните следующие действия.

    1. Для строки подключения DataSource замените заполнители значениями, сохраненными в предыдущем разделе для вторичного База данных SQL, например jdbc:sqlserversecondary-ejb120623.database.windows.net:1433; database=mySampleDatabase.
    2. Для имени пользователя базы данных замените заполнители значениями, сохраненными в предыдущем разделе для вторичного База данных SQL , например, azureuser@sqlserversecondary-ejb120623.

Зеркальное отображение параметров сети для двух кластеров

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

В этом разделе показано, как зеркально зеркально отображать параметры сети из основного кластера в дополнительный кластер.

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

  1. В области "Обзор" страницы "Развертывание" выберите "Перейти к группе ресурсов".

  2. Выберите сетевой интерфейс adminVM_NIC_with_pub_ip.

    1. Выберите Конфигурации IP в разделе Параметры.
    2. Выберите ipconfig1.
    3. В разделе "Параметры частного IP-адреса" выберите "Статический " для выделения. Сохраните частный IP-адрес.
    4. Выберите Сохранить.

  3. Вернитесь в группу ресурсов основного кластера WLS, а затем повторите шаг 3 для сетевых интерфейсов mspVM1_NIC_with_pub_ipиmspVM2_NIC_with_pub_ipmspVM3_NIC_with_pub_ip.

  4. Дождитесь завершения всех обновлений. Вы можете выбрать значок уведомлений в портал Azure, чтобы открыть панель уведомлений для мониторинга состояния.

    Снимок экрана: значок уведомлений портал Azure.

  5. Вернитесь в группу ресурсов основного кластера WLS, а затем скопируйте имя ресурса с типом Частной конечной точки , например 7e8c8bsaep. Используйте это имя для поиска оставшегося сетевого интерфейса, например 7e8c8bsaep.c0438c1a-1936-4b62-864c-6792eec3741a. Выберите его и выполните указанные выше действия, чтобы получить частный IP-адрес.

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

  1. В области "Обзор" страницы "Развертывание" выберите "Перейти к группе ресурсов".

  2. Для сетевых интерфейсов, mspVM1_NIC_with_pub_ipи mspVM2_NIC_with_pub_ipmspVM3_NIC_with_pub_ipвыполните описанные выше действия, чтобы обновить выделение частных adminVM_NIC_with_pub_ipIP-адресов на статический.

  3. Дождитесь завершения всех обновлений.

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

    Примечание.

    Вы не можете изменить частный IP-адрес сетевого интерфейса, который является частью частной конечной точки. Чтобы легко зеркально отражать частные IP-адреса сетевых интерфейсов для управляемых серверов, попробуйте обновить частный IP-адрес до adminVM_NIC_with_pub_ip IP-адреса, который не используется. В зависимости от выделения частных IP-адресов в двух кластерах может потребоваться обновить частный IP-адрес в основном кластере.

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

Кластер Сетевой интерфейс Частный IP-адрес (до) Частный IP-адрес (после) Обновление последовательности
Основной 7e8c8bsaep.nic.c0438c1a-1936-4b62-864c-6792eec3741a 10.1.5.4 10.1.5.4
Основной adminVM_NIC_with_pub_ip 10.1.5.7 10.1.5.7
Основной mspVM1_NIC_with_pub_ip 10.1.5.5 10.1.5.5
Основной mspVM2_NIC_with_pub_ip 10.1.5.8 10.1.5.9 1
Основной mspVM3_NIC_with_pub_ip 10.1.5.6 10.1.5.6
Вторичные 1696b0saep.nic.2e19bf46-9799-4acc-b64b-a2cd2f7a4ee1 10.1.5.8 10.1.5.8
Вторичные adminVM_NIC_with_pub_ip 10.1.5.5 10.1.5.4 4
Вторичные mspVM1_NIC_with_pub_ip 10.1.5.7 10.1.5.5 5
Вторичные mspVM2_NIC_with_pub_ip 10.1.5.6 10.1.5.9 2
Вторичные mspVM3_NIC_with_pub_ip 10.1.5.4 10.1.5.6 3

Проверьте набор частных IP-адресов для всех управляемых серверов, состоящий из внутреннего пула Шлюз приложений Azure развернутых в каждом кластере. Если оно обновлено, выполните следующие действия, чтобы обновить серверный пул Шлюз приложений Azure соответствующим образом:

  1. Откройте группу ресурсов кластера.
  2. Найдите ресурс myAppGateway с помощью шлюза приложений типа. Выберите ее, чтобы открыть.
  3. В разделе "Параметры" выберите серверные пулы, а затем выберите myGatewayBackendPool.
  4. Измените значения целевых объектов серверной части с обновленным частным IP-адресом или адресами, а затем нажмите кнопку "Сохранить". Дождитесь завершения.
  5. В разделе "Параметры" выберите пробы работоспособности и выберите HTTPhealthProbe.
  6. Убедитесь, что я хочу проверить работоспособности серверной части перед добавлением пробы работоспособности, а затем нажмите кнопку "Тест". Должно быть видно, что значение состояния внутреннего пула myGatewayBackendPool помечается как работоспособное. Если это не так, проверьте, обновляются ли частные IP-адреса, как ожидалось, и виртуальные машины выполняются, а затем проверьте пробу работоспособности еще раз. Перед продолжением необходимо устранить проблему и устранить ее.

В следующем примере обновляется серверный пул Шлюз приложений Azure для каждого кластера:

Кластер серверный пул Шлюз приложений Azure Целевые объекты серверной части (до) Целевые объекты серверной части (после)
Основной myGatewayBackendPool (10.1.5.5, , 10.1.5.610.1.5.8) (10.1.5.5, , 10.1.5.610.1.5.9)
Вторичные myGatewayBackendPool (10.1.5.7, , 10.1.5.410.1.5.6) (10.1.5.5, , 10.1.5.610.1.5.9)

Чтобы автоматизировать зеркальное отображение параметров сети, рекомендуется использовать Azure CLI. Дополнительные сведения можно найти в документации по началу работы с Azure CLI.

Проверка развертываний кластеров

Вы развернули Шлюз приложений Azure и сервер администрирования WLS в каждом кластере. Шлюз приложений Azure выступает в качестве подсистемы балансировки нагрузки для всех управляемых серверов в кластере. Сервер администрирования WLS предоставляет веб-консоль для конфигурации кластера.

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

  1. Вернитесь на страницу развертывания , а затем выберите выходные данные.
  2. Скопируйте значение свойства appGatewayURL. Добавьте строку weblogic/ready и откройте этот URL-адрес на новой вкладке браузера. Вы увидите пустую страницу без сообщения об ошибке. Если вы этого не сделали, перед продолжением необходимо устранить проблему и устранить ее.
  3. Скопируйте и сохраните значение администратора свойстваConsole. Откройте его на новой вкладке браузера. Вы увидите страницу входа в консоль администрирования сервера WebLogic Server. Войдите в консоль с именем пользователя и паролем администратора WebLogic, который вы сохранили ранее. Если вы не можете войти, перед продолжением необходимо устранить проблему и устранить ее.

Чтобы получить IP-адрес Шлюз приложений Azure для каждого кластера, выполните следующие действия. Эти значения используются при настройке Диспетчер трафика Azure позже.

  1. Откройте группу ресурсов, в которой развернут кластер, например, выберите "Обзор ", чтобы вернуться на панель обзора страницы развертывания. Затем выберите "Перейти к группе ресурсов".
  2. Найдите ресурс gwip с общедоступным IP-адресом типа, а затем выберите его, чтобы открыть его. Найдите поле IP-адреса и сохраните его значение.

Настройка Диспетчер трафика Azure

В этом разделе описано, как создать Диспетчер трафика Azure для распространения трафика в общедоступные приложения в глобальных регионах Azure. Основная конечная точка указывает на Шлюз приложений Azure в основном кластере WLS, а вторичная конечная точка указывает на Шлюз приложений Azure в дополнительном кластере WLS.

Создайте профиль Диспетчер трафика Azure, выполнив следующее краткое руководство. Создание профиля Диспетчер трафика с помощью портал Azure. Пропустить раздел "Предварительные требования". Вам потребуется только следующие разделы: создание профиля Диспетчер трафика, добавление конечных точек Диспетчер трафика и профиль тестирования Диспетчер трафика. Выполните следующие действия, как описано в этих разделах, а затем вернитесь к этой статье после создания и настройки Диспетчер трафика Azure.

  1. Когда вы перейдете к разделу Создание профиля Диспетчер трафика, выполните следующие действия.

    1. На шаге 2 Создание профиля Диспетчер трафика выполните следующие действия.
      1. Сохраните уникальное имя профиля Диспетчер трафика для имени, например tmprofile-ejb120623.
      2. Сохраните новое имя группы ресурсов для группы ресурсов, например myResourceGroupTM1.

  2. Когда вы перейдете к разделу Добавление конечных точек Диспетчер трафика, выполните следующие действия.

    1. Выполните это дополнительное действие после шага Выбора профиля из результатов поиска.
      1. В разделе Параметры выберите пункт Конфигурация.
      2. Для времени жизни DNS (TTL) введите 10.
      3. В разделе "Параметры монитора конечных точек" в поле "Путь" введите /weblogic/ready.
      4. В разделе "Быстрые параметры отработки отказа конечной точки" используйте следующие значения:
        • Для проверки внутренних данных введите 10.
        • Для допустимого числа сбоев введите 3.
        • Время ожидания пробы — 5.
      5. Выберите Сохранить. Дождитесь завершения.
    2. На шаге 4 для добавления основной конечной точки myPrimaryEndpointвыполните следующие действия:
      1. Для типа целевого ресурса выберите общедоступный IP-адрес.
      2. Выберите раскрывающийся список "Выбор общедоступного IP-адреса" и введите IP-адрес Шлюз приложений развернутых в кластере WLS восточной части США, который вы сохранили ранее. Должно появиться одно совпадение записи. Выберите его для общедоступного IP-адреса.
    3. На шаге 6 для добавления отработки отказа или вторичной конечной точки myFailoverEndpoint выполните следующие действия.
      1. Для типа целевого ресурса выберите общедоступный IP-адрес.
      2. Выберите раскрывающийся список "Выбор общедоступного IP-адреса" и введите IP-адрес Шлюз приложений, развернутый в кластере WLS западной части США, который вы сохранили ранее. Должно появиться одно совпадение записи. Выберите его для общедоступного IP-адреса.
    4. Подождите некоторое время. Выберите "Обновить", пока значение состояния монитора для обеих конечных точек находится в Сети.

  3. Когда вы перейдете к профилю тестового Диспетчер трафика раздела, выполните следующие действия.

    1. В подразделе Проверка DNS-имени используйте следующий шаг:
      1. На шаге 3 сохраните DNS-имя вашего Диспетчер трафика профиля, напримерhttp://tmprofile-ejb120623.trafficmanager.net.
    2. В подразделе представление Диспетчер трафика в действии выполните следующие действия:
      1. На шаге 1 и 3 добавьте /weblogic/ready к DNS-имени профиля Диспетчер трафика в веб-браузере, напримерhttp://tmprofile-ejb120623.trafficmanager.net/weblogic/ready. Вы увидите пустую страницу без сообщения об ошибке.
      2. После выполнения всех шагов включите основную конечную точку, ссылаясь на шаг 2, но замените "Отключено". Затем вернитесь на страницу конечных точек.

Теперь у вас есть как конечные точки, так и в сети в профиле Диспетчер трафика. Оставьте страницу открытой, и вы используете ее для мониторинга состояния конечной точки позже.

Настройка кластеров WLS для обеспечения высокой доступности и аварийного восстановления

В этом разделе описана настройка кластеров WLS для обеспечения высокой доступности и аварийного восстановления.

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

В этом разделе описано, как создать и упаковать пример приложения CRUD Java/JakartaEE, которое будет развернуто и запущено в кластерах WLS для тестирования отработки отказа.

Приложение использует сохраняемость сеанса JDBC WebLogic Server для хранения данных сеанса HTTP. В источнике jdbc/WebLogicCafeDB данных хранятся данные сеанса для включения отработки отказа и балансировки нагрузки в кластере серверов WebLogic. Она настраивает схему сохраняемости для сохранения данных coffee приложения в одном источнике jdbc/WebLogicCafeDBданных.

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

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

    git clone https://github.com/Azure-Samples/azure-cafe.git
cd azure-cafe
git checkout 20231206

    Если вы видите сообщение о Detached HEADнем, это безопасно игнорировать.

  2. Используйте следующие команды, чтобы перейти к образцу каталога, а затем скомпилировать и упаковать пример:

    cd weblogic-cafe
mvn clean package

После успешного создания пакета его можно найти на <сайте parent-path-to-your-local-clone>/azure-café/weblogic-café/target/weblogic-café.war. Если пакет не отображается, перед продолжением необходимо устранить проблему и устранить ее.

Развертывание примера приложения

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

  1. Откройте adminConsole кластера на новой вкладке веб-браузера. Войдите в консоль администрирования сервера WebLogic с именем пользователя и паролем администратора WebLogic, сохраненного ранее.
  2. Найдите доменные структуры>wlsd>Deployments в области навигации. Выберите Развертывания.
  3. Выберите "Блокировка" и "Изменить установку",>чтобы отправить>файлы.> Выберите файл weblogic-café.war, подготовленный ранее.
  4. Нажмите кнопку "Далее".>> Выберите cluster1 параметр "Все серверы в кластере " для целевых объектов развертывания. Выберите Далее>Готово. Выберите " Активировать изменения".
  5. Перейдите на вкладку "Элемент управления" и выберите weblogic-cafe из таблицы развертываний. Выберите "Начать" с параметра "Обслуживание всех запросов>да". Подождите некоторое время и обновите страницу, пока не увидите, что состояние развертывания weblogic-cafe активно. Перейдите на вкладку "Мониторинг" и убедитесь, что корень контекста развернутого приложения — /weblogic-café. Оставьте консоль администрирования WLS открытой, чтобы использовать ее позже для дальнейшей настройки.

Повторите те же действия в консоли администрирования webLogic Server, но для дополнительного кластера в регионе "Западная часть США".

Обновление узла переднего плана

Выполните следующие действия, чтобы сделать кластеры WLS известными о Диспетчер трафика Azure. Так как Диспетчер трафика Azure является точкой входа для запросов пользователей, обновите внешний узел кластера WebLogic Server до DNS-имени профиля Диспетчер трафика, начиная с основного кластера.

  1. Убедитесь, что вы вошли в консоль администрирования webLogic Server.
  2. Перейдите к доменным структурам>кластеров среды>wlsd>в области навигации. Выберите кластеры.
  3. Выберите cluster1 из таблицы кластеров.
  4. Выберите "Блокировка" и "Изменить>HTTP". Удалите текущее значение для внешнего узла и введите DNS-имя профиля Диспетчер трафика, который вы сохранили ранее, без ведущих http:// — например, tmprofile-ejb120623.trafficmanager.net. Нажмите кнопку "Сохранить>изменения активации".

Повторите те же действия в консоли администрирования сервера WebLogic, но для дополнительного кластера в регионе "Западная часть США".

Настройка хранилища журналов транзакций

Затем настройте хранилище журналов транзакций JDBC для всех управляемых серверов кластеров, начиная с основного кластера. Эта практика описана в разделе "Использование файлов журнала транзакций для восстановления транзакций".

Выполните следующие действия в основном кластере WLS в восточном регионе США:

  1. Убедитесь, что вы вошли в консоль администрирования сервера WebLogic.
  2. Перейдите к доменным структурам>wlsd>Environment>Servers в области навигации. Выберите Серверы.
  3. Серверы msp1msp2должны отображаться и msp3 перечислены в таблице серверов.
  4. Выберите msp1>"Блокировка служб>" и "Изменить". В разделе "Хранилище журналов транзакций" выберите JDBC.
  5. Для источника данных типа>выберите jdbc/WebLogicCafeDB.
  6. Убедитесь, что значение для имени префикса равно TLOG_msp1_, которое является значением по умолчанию. Если значение отличается, измените его на TLOG_msp1_.
  7. Выберите Сохранить.
  8. Выберите серверы и повторите те же действия, за исключением того, что значение по умолчанию для имени префиксаmsp2> TLOG_msp2_.
  9. Выберите серверы и повторите те же действия, за исключением того, что значение по умолчанию для имени префиксаmsp3> TLOG_msp3_.
  10. Выберите " Активировать изменения".

Повторите те же действия в консоли администрирования webLogic Server, но для дополнительного кластера в регионе "Западная часть США".

Перезапустите управляемые серверы основного кластера

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

  1. Убедитесь, что вы вошли в консоль администрирования WebLogic Server.
  2. Перейдите к доменным структурам>wlsd>Environment>Servers в области навигации. Выберите Серверы.
  3. Выберите вкладку "Элемент управления ". Выберите msp1, msp2и msp3. Выберите "Завершение работы" с параметром "Когда работа завершается>да". Щелкните значок обновления. Подождите, пока значение "Состояние последнего действия " будет ЗАВЕРШЕНО. Должно быть видно, что значение состояния для выбранных серверов — SHUTDOWN. Щелкните значок обновления еще раз, чтобы остановить мониторинг состояния.
  4. Выберите msp1, msp2и msp3 снова. Нажмите кнопку "Пуск>да". Щелкните значок обновления. Подождите, пока значение "Состояние последнего действия " будет ЗАВЕРШЕНО. Должно быть видно, что значение состояния для выбранных серверов выполняется. Щелкните значок обновления еще раз, чтобы остановить мониторинг состояния.

Остановка виртуальных машин в дополнительном кластере

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

  1. Откройте портал Azure дома на новой вкладке браузера, а затем выберите все ресурсы. В поле "Фильтр для любого поля... введите имя группы ресурсов, в которой развернут дополнительный кластер - например, wls-cluster-westus-ejb120623.
  2. Выбор типа равен всем , чтобы открыть фильтр "Тип ". Введите значение виртуальной машины. Должно появиться одно совпадение записи. Выберите его для значения. Выберите Применить. Вы увидите 4 виртуальных машины, в том числе adminVM, mspVM1mspVM2и mspVM3.
  3. Выберите, чтобы открыть каждую из виртуальных машин. Выберите "Остановить " и подтвердить для каждой виртуальной машины.
  4. Щелкните значок уведомлений из портал Azure, чтобы открыть панель уведомлений.
  5. Отслеживайте событие остановки виртуальной машины для каждой виртуальной машины , пока значение не будет успешно остановлено виртуальной машиной. Сохраните страницу открытой, чтобы использовать ее для тестов отработки отказа позже.

Теперь перейдите на вкладку браузера, в которой вы отслеживаете состояние конечных точек Диспетчер трафика. Обновите страницу, пока не увидите, что конечная точка понижена, а конечная точка myFailoverEndpoint myPrimaryEndpoint находится в сети.

Примечание.

Готовое к работе решение высокой доступности и аварийного восстановления, вероятно, захотите достичь более низкого уровня RTO, оставив виртуальные машины запущенными, но только остановив программное обеспечение WLS, работающее на виртуальных машинах. Затем в случае отработки отказа виртуальные машины уже будут работать, и программное обеспечение WLS займет меньше времени для запуска. Эта статья решила остановить виртуальные машины, так как программное обеспечение, развернутые кластером Oracle WebLogic Server на виртуальных машинах Azure, автоматически запускает программное обеспечение WLS при запуске виртуальных машин.

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

Так как основной кластер выполняется и работает, он выступает в качестве активного кластера и обрабатывает все запросы пользователей, перенаправленные вашим профилем Диспетчер трафика.

Откройте DNS-имя профиля Диспетчер трафика Azure на новой вкладке браузера, добавив корень контекста /weblogic-café развернутого приложения, напримерhttp://tmprofile-ejb120623.trafficmanager.net/weblogic-cafe. Создайте новый кофе с именем и ценой - например, coffee 1 с ценой 10. Эта запись сохраняется как в таблице данных приложения, так и в таблице сеансов базы данных. Отображаемый пользовательский интерфейс должен быть похож на следующий снимок экрана:

Снимок экрана: пример пользовательского интерфейса приложения.

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

Сохраните страницу открытой, чтобы использовать ее для отработки отказа позже.

Тестирование отработки отказа из первичного в вторичный

Чтобы проверить отработку отказа, вы вручную завершите сбой сервера базы данных-источника и кластера на сервер базы данных-получателя и кластер, а затем выполните отработку отказа с помощью портал Azure в этом разделе.

Отработка отказа на дополнительный сайт

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

  1. Найдите имя группы ресурсов, в которой развернут основной кластер WLS, например wls-cluster-eastus-ejb120623. Затем выполните действия, описанные в разделе остановки виртуальных машин в дополнительном кластере, но измените целевую группу ресурсов на основной кластер WLS, чтобы остановить все виртуальные машины в этом кластере.
  2. Перейдите на вкладку браузера Диспетчер трафика, обновите страницу, пока не увидите, что значение состояния монитора конечной точки myPrimaryEndpoint становится пониженным.
  3. Перейдите на вкладку браузера примера приложения и обновите страницу. Вы должны увидеть время ожидания шлюза 504 или 502 Недопустимый шлюз , так как ни одна из конечных точек не доступна.

Затем выполните следующие действия, чтобы выполнить отработку отказа База данных SQL Azure с основного сервера на дополнительный сервер:

  1. Перейдите на вкладку браузера База данных SQL Azure группы отработки отказа.
  2. Выберите "Да" отработки>отказа.
  3. Дождитесь завершения.

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

  1. Перейдите на вкладку браузера, на которой остановлены все виртуальные машины в дополнительном кластере.
  2. Выберите виртуальную машину adminVM. Выберите Пуск.
  3. Отслеживайте событие запуска виртуальной машины adminVM в области уведомлений и подождите, пока значение не станет запущенной виртуальной машиной.
  4. Перейдите на вкладку браузера консоли администрирования сервера WebLogic для дополнительного кластера, а затем обновите страницу, пока не увидите страницу приветствия для входа.
  5. Вернитесь на вкладку браузера, где перечислены все виртуальные машины в дополнительном кластере. Для виртуальных машин mspVM1mspVM2выберите mspVM3каждую из них, чтобы открыть ее, а затем нажмите кнопку "Пуск".
  6. Для виртуальных машин mspVM1и отслеживайте событие "Запуск виртуальной машины" в области уведомлений и подождите, пока значения не станут запущенными виртуальными машинами.mspVM3mspVM2

Наконец, выполните следующие действия, чтобы проверить пример приложения после того, как конечная точка myFailoverEndpoint находится в состоянии Online :

  1. Перейдите на вкладку браузера Диспетчер трафика, а затем обновите страницу, пока не увидите, что значение состояния монитора конечной точки myFailoverEndpoint введите состояние Online.

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

    Снимок экрана: пример пользовательского интерфейса приложения после отработки отказа.

    Если вы не видите это поведение, это может быть связано с тем, что Диспетчер трафика занимает время для обновления DNS, чтобы указать на сайт отработки отказа. Проблема также может быть в том, что браузер кэшировал результат разрешения DNS-имен, указывающий на сбой сайта. Подождите некоторое время и снова обновите страницу.

Примечание.

Решение высокого уровня доступности и аварийного восстановления будет учитывать непрерывное копирование конфигурации WLS из основного в вторичные кластеры в регулярное расписание. Дополнительные сведения о том, как это сделать, см. в справочнике по документации Oracle в конце этой статьи.

Чтобы автоматизировать отработку отказа, рассмотрите возможность использования оповещений по метрикам Диспетчер трафика и служба автоматизации Azure. Дополнительные сведения см. в разделе "Оповещения о Диспетчер трафика метрик" Диспетчер трафика метрик и оповещений и используйте оповещение для активации модуля Runbook служба автоматизации Azure.

Отработка отказа на основной сайт

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

  1. Сначала завершите работу виртуальных машин в дополнительном кластере. Вы увидите, что конечная точка myFailoverEndpoint становится пониженной.
  2. Затем отработка отказа База данных SQL Azure с сервера-получателя на первичный сервер.
  3. Затем запустите все серверы в основном кластере.
  4. Наконец, проверьте пример приложения после того, как конечная точка myPrimaryEndpoint находится в Сети.

Очистка ресурсов

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

  1. Введите имя группы ресурсов База данных SQL Azure серверов (например, myResourceGroup) в поле поиска в верхней части портал Azure и выберите соответствующую группу ресурсов из результатов поиска.
  2. Выберите команду Удалить группу ресурсов.
  3. Введите имя группы ресурсов, чтобы подтвердить удаление, введите имя группы ресурсов.
  4. Выберите команду Удалить.
  5. Повторите шаги 1-4 для группы ресурсов Диспетчер трафика, напримерmyResourceGroupTM1.
  6. Повторите шаги 1-4 для группы ресурсов основного кластера WLS, например wls-cluster-eastus-ejb120623.
  7. Повторите шаги 1–4 для группы ресурсов вторичного кластера WLS, например wls-cluster-westus-ejb120623.

Следующие шаги

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

Перейдите к следующим ссылкам для получения дополнительных возможностей для создания решений ha/DR и запуска WLS в Azure:

Решения аварийного восстановления для продуктов Oracle Fusion Middleware

Документация по надежности Azure

Создание решений для обеспечения высокой доступности

Автоматическая отработка отказа с помощью Диспетчер трафика Azure

Дополнительные сведения о Oracle WebLogic на виртуальных машинах Azure

Дополнительные сведения об Oracle WebLogic в AKS