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


Руководство. Перенос сервера приложений WebSphere в Azure Виртуальные машины с высоким уровнем доступности и аварийного восстановления

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

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

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

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

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

Диспетчер трафика Azure проверяет работоспособность регионов и направляет трафик соответствующим образом на уровень приложений. Основной регион имеет полное развертывание кластера WebSphere. После защиты основного региона с помощью Azure Site Recovery можно восстановить дополнительный регион во время отработки отказа. В результате основной регион активно обслуживает сетевые запросы от пользователей, а дополнительный регион пассивный и активируется для получения трафика, только если основной регион испытывает нарушение работы службы.

Диспетчер трафика Azure обнаруживает работоспособность приложения, развернутого на СЕРВЕРе IBM HTTP Server для реализации условной маршрутизации. Геоработка отказа RTO уровня приложений зависит от времени завершения работы основного кластера, восстановления вторичного кластера, запуска виртуальных машин и запуска дополнительного кластера WebSphere. RPO зависит от политики репликации Azure Site Recovery и База данных SQL Azure. Эта зависимость обусловлена тем, что данные кластера хранятся и реплицируются в локальном хранилище виртуальных машин, а данные приложения сохраняются и реплицируются в группе отработки отказа База данных SQL Azure.

На предыдущей схеме показан основной регион и дополнительный регион в качестве двух регионов, состоящих из архитектуры высокого уровня доступности и аварийного восстановления. Эти регионы должны быть парными регионами Azure. Дополнительные сведения о парных регионах см. в статье о репликации между регионами Azure. В статье используется восточная часть США и западная часть США в качестве двух регионов, но они могут быть любыми парными регионами, которые должны иметь смысл для вашего сценария. Список пар регионов см. в разделе "Пары регионов Azure" репликации между регионами Azure.

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

Это руководство было написано с помощью Azure Site Recovery и службы База данных SQL Azure, так как в этом руководстве используются функции высокой доступности этих служб. Другие варианты базы данных возможны, но вы должны учитывать функции высокой доступности любой выбранной базы данных.

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

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

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

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

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

    1. На шаге 4 для создания новой группы ресурсов сохраните значение имени группы ресурсов, например myResourceGroup.
    2. В шаге 5 для имени базы данных сохраните значение имени базы данных, например mySampleDatabase.
    3. На шаге 6 для создания сервера выполните следующие действия.
      1. Введите уникальное имя сервера, например sqlserverprimary-mjg022624.
      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 снимите редактор и введите следующий запрос, а затем снова нажмите кнопку "Выполнить ".

      CREATE TABLE sessions (
         ID VARCHAR(128) NOT NULL,
         PROPID VARCHAR(128) NOT NULL,
         APPNAME VARCHAR(128) NOT NULL,
         LISTENERCNT SMALLINT,
         LASTACCESS BIGINT,
         CREATIONTIME BIGINT,
         MAXINACTIVETIME INT,
         USERNAME VARCHAR(256),
         SMALL VARBINARY(MAX),
         MEDIUM VARCHAR(MAX),
         LARGE VARBINARY(MAX)
      );
      

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

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

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

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

    1. На шаге 5 для создания группы отработки отказа введите и сохраните уникальное имя группы отработки отказа, например failovergroup-mjg022624.
    2. На шаге 5 для настройки сервера выберите параметр для создания нового сервера-получателя, а затем выполните следующие действия.
      1. Введите уникальное имя сервера, например sqlserversecondary-mjg022624.
      2. Введите тот же администратор сервера и пароль, что и основной сервер.
      3. Для расположения выберите (США) западная часть США.
      4. Убедитесь, что выбрана служба Azure для доступа к серверу .
    3. На шаге 5 для настройки баз данных в группе выберите базу данных, созданную на основном сервере, например mySampleDatabase.
  2. После выполнения всех действий в разделе "Тест тестирования" плановая отработка отказа откройте страницу группы отработки отказа и используйте ее для тестов отработки отказа кластеров WebSphere позже.

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

В этом разделе описано, как создать основные кластеры WebSphere на виртуальных машинах Azure с помощью кластера СЕРВЕРА приложений IBM WebSphere на виртуальных машинах Azure. Вторичный кластер восстанавливается из основного кластера во время отработки отказа с помощью Azure Site Recovery позже.

Развертывание основного кластера WebSphere

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

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

  1. Убедитесь, что значение, отображаемое для подписки , совпадает с ролями, перечисленными в разделе предварительных требований.
  2. Необходимо развернуть предложение в пустой группе ресурсов. В поле "Группа ресурсов" выберите "Создать" и введите уникальное значение для группы ресурсов, напримерwas-cluster-eastus-mjg022624.
  3. В разделе "Сведения об экземпляре" для региона выберите "Восточная часть США".
  4. Для развертывания с существующими правами WebSphere или лицензией на оценку? выберите "Оценка " для этого руководства. Вы также можете выбрать "Право" и указать учетные данные IBMid.
  5. Выберите "Я прочитал" и примите лицензионное соглашение IBM..
  6. Оставьте значения по умолчанию для других полей.
  7. Нажмите кнопку "Далее", чтобы перейти к области конфигурации кластера.

Снимок экрана: портал Azure, на котором показан кластер сервера приложений IBM WebSphere на панели

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

  1. Для администратора виртуальной машины укажите пароль.
  2. Для администратора WebSphere укажите пароль. Сохраните имя пользователя и пароль администратора WebSphere.
  3. Оставьте значения по умолчанию для других полей.
  4. Нажмите кнопку "Рядом", чтобы перейти к области подсистемы балансировки нагрузки.

Снимок экрана: портал Azure, на котором показан кластер сервера приложений IBM WebSphere на панели конфигурации кластера виртуальных машин Azure.

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

  1. Для администратора виртуальной машины укажите пароль.
  2. Для администратора IBM HTTP Server укажите пароль.
  3. Оставьте значения по умолчанию для других полей.
  4. Нажмите кнопку "Рядом", чтобы перейти к области "Сеть".

Снимок экрана: портал Azure, на котором показан кластер сервера приложений IBM WebSphere на панели балансировки нагрузки виртуальных машин Azure.

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

Снимок экрана: портал Azure, на котором показан кластер сервера приложений IBM WebSphere на панели

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

  1. Для подключения к базе данных нажмите кнопку "Да".
  2. Для выбора типа базы данных выберите Microsoft SQL Server .
  3. Для имени JNDI введите jdbc/WebSphereCafeDB.
  4. Для источника данных строка подключения (jdbc:sqlserver://<host>:<port>; database=<database>), замените заполнители значениями, сохраненными в предыдущем разделе для группы отработки отказа для База данных SQL Azure, напримерjdbc:sqlserver://failovergroup-mjg022624.database.windows.net:1433;database=mySampleDatabase.
  5. Для имени пользователя базы данных введите имя входа администратора сервера и имя группы отработки отказа, сохраненное в предыдущем разделе, например azureuser@failovergroup-mjg022624.

    Примечание.

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

  6. Введите пароль для входа администратора сервера, сохраненный ранее для пароля базы данных. Введите то же значение для подтверждения пароля.
  7. Оставьте значения по умолчанию для других полей.
  8. Выберите Review + create (Просмотреть и создать).
  9. Дождитесь завершения последней проверки, а затем нажмите кнопку "Создать".

Снимок экрана: портал Azure, на котором показан кластер сервера приложений IBM WebSphere на панели

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

Примечание.

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

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

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

Вы развернули IBM HTTP-сервер (IHS) и диспетчер развертывания WebSphere (Dmgr) в кластере. IHS выступает в качестве подсистемы балансировки нагрузки для всех серверов приложений в кластере. Dmgr предоставляет веб-консоль для конфигурации кластера.

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

  1. Вернитесь на страницу развертывания , а затем выберите выходные данные.

  2. Скопируйте значение свойства ihsConsole. Откройте этот URL-адрес на новой вкладке браузера. Обратите внимание, что мы не используем https для IHS в этом примере. Вы увидите страницу приветствия IHS без каких-либо сообщений об ошибке. Если вы этого не сделали, перед продолжением необходимо устранить проблему и устранить ее. Откройте консоль и используйте ее для проверки развертывания приложения кластера позже.

    Снимок экрана: экран приветствия IBM HTTP Server.

  3. Скопируйте и сохраните значение свойства adminSecuredConsole. Откройте его на новой вкладке браузера. Примите предупреждение браузера для самозаверяющего сертификата TLS. Не перейдите в рабочую среду с помощью самозаверяющего сертификата TLS.

    Вы увидите страницу входа в консоль интегрированных решений WebSphere. Войдите в консоль с именем пользователя и паролем администратора WebSphere, сохраненного ранее. Если вы не можете войти, перед продолжением необходимо устранить проблему и устранить ее. Откройте консоль и используйте ее для дальнейшей настройки кластера WebSphere позже.

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

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

Настройка кластера

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

  1. Вернитесь в консоль интегрированных решений WebSphere и снова войдите в систему, если вы вышли из системы.
  2. В области навигации выберите параметры консоли администрирования>системы.
  3. В области параметров консоли выберите "Синхронизировать изменения с узлами" и нажмите кнопку "Применить". Должно появиться сообщение о том, что ваши предпочтения были изменены.

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

  1. В области навигации выберите серверы>серверов>типа вебсферы приложений.
  2. На панели "Серверы приложений" вы увидите 3 сервера приложений. Для каждого сервера приложений выполните следующие инструкции по настройке распределенных сеансов базы данных:
    1. В таблице под текстом можно администрировать следующие ресурсы, выберите гиперссылку для сервера приложений, которая начинается с MyCluster.
    2. В разделе "Параметры контейнера" выберите "Управление сеансами".
    3. В разделе "Дополнительные свойства" выберите параметры распределенной среды.
    4. Для распределенных сеансов выберите базу данных (поддерживается только для веб-контейнера.).
    5. Выберите базу данных и выполните следующие действия.
      1. Для имени JNDI источника данных введите jdbc/WebSphereCafeDB.
      2. Для идентификатора пользователя введите имя входа администратора сервера и имя группы отработки отказа, сохраненные в предыдущем разделе, например azureuser@failovergroup-mjg022624.
      3. Введите пароль для входа администратора SQL Server Azure, сохраненный ранее для пароля.
      4. В поле "Имя пространства таблиц" введите сеансы.
      5. Выберите "Использовать схему с несколькими строками".
      6. Нажмите ОК. Вы будете перенаправлены обратно в область параметров распределенной среды.
    6. В разделе "Дополнительные свойства" выберите параметры настраиваемой настройки.
    7. Для параметра "Уровень настройки" выберите "Низкий" (оптимизация для отработки отказа).
    8. Нажмите ОК.
    9. В разделе "Сообщения" выберите "Сохранить". Дождитесь завершения.
    10. Выберите серверы приложений на верхней панели навигации. Вы направляетесь обратно на панель серверов приложений.
  3. В области навигации выберите >кластеры серверов WebSphere, кластеры>серверов приложений WebSphere.
  4. В области кластеров серверов приложений WebSphere отобразится список кластеровMyCluster. Установите флажок рядом с MyCluster.
  5. Выберите Ripplestart.
  6. Дождитесь перезапуска кластера. Вы можете выбрать значок состояния и, если новое окно не отображается , а затем вернуться к консоли и обновить веб-страницу через некоторое время. Повторите операцию, пока не увидите "Начало". Вы можете увидеть частичный запуск перед достижением состояния "Запущено"

Откройте консоль и используйте ее для развертывания приложений позже.

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

В этом разделе показано, как развернуть и запустить пример приложения CRUD Java/Jakarta EE в кластере WebSphere для тестовой отработки отказа аварийного восстановления.

Серверы приложений настроены для использования источника jdbc/WebSphereCafeDB данных для хранения данных сеанса ранее, что позволяет выполнять отработку отказа и балансировку нагрузки между кластером серверов приложений WebSphere. Пример приложения также настраивает схему сохраняемости для сохранения данных coffee приложения в том же источнике jdbc/WebSphereCafeDBданных.

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

git clone https://github.com/Azure-Samples/websphere-cafe
cd websphere-cafe
git checkout 20240326
mvn clean package

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

Пакет должен быть успешно создан и расположен в <папке parent-path-to-your-local-clone>/websphere-café/websphere-café-application/target/websphere-café.ear. Если пакет не отображается, перед продолжением необходимо устранить проблему и устранить ее.

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

  1. Вернитесь в консоль интегрированных решений WebSphere и снова войдите в систему, если вы вышли из системы.
  2. В области навигации выберите корпоративные приложения ">Типы>приложений WebSphere".
  3. На панели "Корпоративные приложения" выберите "Установить>файл". Затем найдите пакет, расположенный в <папке parent-path-to-your-local-clone>/websphere-café/websphere-café-application/target/websphere-café.ear и выберите "Открыть". Нажмите кнопку "Далее".>>
  4. В области "Сопоставление модулей с серверами" нажмите клавиши CTRL и выберите все элементы, перечисленные в разделе "Кластеры и серверы". Установите флажок рядом с websphere-café.war. Выберите Применить. Нажмите кнопку "Далее", пока не появится кнопка "Готово".
  5. Нажмите кнопку "Готово>сохранить", а затем дождитесь завершения. Нажмите ОК.
  6. Выберите установленное приложение websphere-cafeи нажмите кнопку "Пуск". Подождите, пока не увидите сообщения, указывающие на успешное запуск приложения. Если вы не можете увидеть успешное сообщение, перед продолжением необходимо устранить проблему и устранить ее.

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

  1. Вернитесь в консоль IHS. Добавьте корень /websphere-cafe/ контекста развернутого приложения в адресную строку, например http://ihs70685e.eastus.cloudapp.azure.com/websphere-cafe/, и нажмите клавишу ВВОД. Вы увидите страницу приветствия примера приложения.

  2. Создайте кофе с именем и ценой , например, Coffee 1 с ценой $ 10 - которая сохраняется как в таблице данных приложения, так и в таблице сеансов базы данных. Отображаемый пользовательский интерфейс должен быть похож на следующий снимок экрана:

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

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

Настройка аварийного восстановления для кластера с помощью Azure Site Recovery

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

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

    1. На шаге 5 для группы ресурсов создайте новую группу ресурсов с уникальным именем в подписке, например was-cluster-westus-mjg022624.

    2. В шаге 6 для имени хранилища укажите имя хранилища, например recovery-service-vault-westus-mjg022624.

    3. На шаге 7 для региона выберите "Западная часть США".

    4. Перед нажатием кнопки "Просмотр и создание " на шаге 8 нажмите кнопку "Далее: избыточность". В области избыточности выберите "Геоизбыточное" для избыточности хранилища резервных копий и включите восстановление между регионами.

      Примечание.

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

    5. Включите Site Recovery, выполнив действия, описанные в разделе "Включить Site Recovery".

  2. Когда вы перейдете к разделу "Включить репликацию", выполните следующие действия.

    1. В разделе "Выбор параметров источника" выполните следующие действия.
      1. В поле Страна или регион выберите Восточная часть США.

      2. Для группы ресурсов выберите ресурс, в котором развертывается основной кластер, например was-cluster-eastus-mjg022624.

        Примечание.

        Если требуемая группа ресурсов не указана, сначала можно выбрать западную часть США для региона, а затем вернуться на восточную часть США.

      3. Оставьте значения по умолчанию для других полей. Выберите Далее.

    2. В разделе "Выбор виртуальных машин" для виртуальных машин выберите все пять виртуальных машин, перечисленных, а затем нажмите кнопку "Далее".
    3. В разделе "Просмотр параметров репликации" выполните следующие действия.
      1. В качестве целевого расположения выберите "Западная часть США".
      2. Для целевой группы ресурсов выберите группу ресурсов, в которой развернуто хранилище восстановления службы, например was-cluster-westus-mjg022624.
      3. Запишите новую виртуальную сеть отработки отказа и подсеть отработки отказа, сопоставленную с теми из них в основном регионе.
      4. Оставьте значения по умолчанию для других полей.
      5. Выберите Далее.
    4. В разделе "Управление" выполните следующие действия.
      1. Для политики репликации используйте политику хранения по умолчанию 24-часовой. Вы также можете создать новую политику для вашего бизнеса.
      2. Оставьте значения по умолчанию для других полей.
      3. Выберите Далее.
    5. В разделе "Рецензирование" выполните следующие действия.
      1. После нажатия кнопки "Включить репликацию" обратите внимание на сообщение "Создание ресурсов Azure". Не закрывайте эту колонку. отображается в нижней части страницы. Ничего не делать и ждать, пока область не будет закрыта автоматически. Вы перенаправляетесь на страницу Site Recovery .

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

        Снимок экрана: портал Azure с виртуальными машинами, которые реплицируются и защищены.

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

  1. На шаге 2 введите имя плана, например recovery-plan-mjg022624.
  2. На шаге 3 для источника выберите "Восточная часть США" и "Целевой", выберите "Западная часть США".
  3. На шаге 4 для выбора элементов выберите все пять защищенных виртуальных машин для этого руководства.

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

Дальнейшая конфигурация сети для дополнительного региона

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

  1. Создайте общедоступный IP-адрес для Dmgr в дополнительном регионе, следуя инструкциям в кратком руководстве. Создание общедоступного IP-адреса с помощью портал Azure с помощью следующих настроек:

    1. Для группы ресурсов выберите группу ресурсов, в которой развернуто хранилище восстановления службы, например was-cluster-westus-mjg022624.
    2. Для региона выберите западную часть США.
    3. В поле "Имя" введите значение, например dmgr-public-ip-westus-mjg022624.
    4. Для метки DNS-имени введите уникальное значение, например dmgrmjg022624.
  2. Создайте другой общедоступный IP-адрес для IHS в дополнительном регионе, выполнив одно и то же руководство со следующими настройками:

    1. Для группы ресурсов выберите группу ресурсов, в которой развернуто хранилище восстановления службы, например was-cluster-westus-mjg022624.
    2. Для региона выберите западную часть США.
    3. В поле "Имя" введите значение, например ihs-public-ip-westus-mjg022624. Записывайте.
    4. Для метки DNS-имени введите уникальное значение, например ihsmjg022624.
  3. Создайте группу безопасности сети в дополнительном регионе, следуя инструкциям в разделе "Создание группы безопасности сети" раздела "Создание, изменение или удаление группы безопасности сети" со следующими настройками:

    1. Для группы ресурсов выберите группу ресурсов, в которой развернуто хранилище восстановления службы, например was-cluster-westus-mjg022624.
    2. В поле "Имя" введите значение, например nsg-westus-mjg022624.
    3. В поле Регион выберите Западная часть США.
  4. Создайте правило безопасности для входящего трафика для группы безопасности сети, следуя инструкциям в разделе "Создание правила безопасности" той же статьи со следующими настройками:

    1. На шаге 2 выберите созданную группу безопасности сети, например nsg-westus-mjg022624.
    2. На шаге 3 выберите правила безопасности для входящего трафика.
    3. На шаге 4 настройте следующие параметры:
      1. Для диапазонов портов назначения введите 9060 9080 9043 9443 80.
      2. В поле Протокол выберите TCP.
      3. В поле "Имя" введите ALLOW_HTTP_ACCESS.
  5. Свяжите группу безопасности сети с подсетью, следуя инструкциям в разделе "Связывание" или разъединении группы безопасности сети с разделом подсети той же статьи, со следующими настройками:

    1. На шаге 2 выберите созданную группу безопасности сети, например nsg-westus-mjg022624.
    2. Выберите "Связать", чтобы связать группу безопасности сети с подсетью отработки отказа, указанной ранее.

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

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

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

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

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

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

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

  1. Выберите обзор созданного профиля Диспетчер трафика.

  2. Выберите и скопируйте имя системы доменных имен (DNS) профиля Диспетчер трафика, а затем добавьте его с /websphere-cafe/ помощью , напримерhttp://tmprofile-mjg022624.trafficmanager.net/websphere-cafe/.

  3. Откройте URL-адрес на новой вкладке браузера. На странице должен появиться кофе, созданный ранее.

  4. Создайте другой кофе с другим именем и ценой , например , Coffee 2 с ценой 20 , которая сохраняется как в таблице данных приложения, так и в таблице сеансов базы данных. Отображаемый пользовательский интерфейс должен быть похож на следующий снимок экрана:

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

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

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

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

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

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

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

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

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

  1. В поле поиска в верхней части портал Azure введите хранилища служб восстановления и выберите хранилища служб восстановления в результатах поиска.

  2. Выберите имя хранилища служб восстановления, например recovery-service-vault-westus-mjg022624.

  3. В разделе Управление выберите Планы восстановления (Site Recovery). Выберите созданный план восстановления, например recovery-plan-mjg022624.

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

    Примечание.

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

    Снимок экрана: портал Azure, на котором показана панель отработки отказа.

  5. Отслеживайте отработку отказа в уведомлениях до завершения. Выполнение упражнения в этом руководстве занимает около 10 минут.

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

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

  6. При необходимости можно просмотреть сведения о задании отработки отказа, выбрав событие отработки отказа , например, отработка отказа "recovery-plan-mjg022624" выполняется... - из уведомлений.

    Снимок экрана: страница портал Azure отработки отказа, на котором показаны сведения о задании отработки отказа.

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

  1. В поле поиска в верхней части портал Azure введите группы ресурсов и выберите группы ресурсов в результатах поиска.
  2. Выберите имя группы ресурсов для дополнительного региона, например was-cluster-westus-mjg022624. Сортировка элементов по типу на странице "Группа ресурсов".
  3. Выберите префикс сетевого интерфейса с dmgrпрефиксом. Выберите IP-конфигурации>ipconfig1. Выберите "Связать общедоступный IP-адрес". Для общедоступного IP-адреса выберите префикс dmgrобщедоступного IP-адреса. Этот адрес создан ранее. В этой статье адрес dmgr-public-ip-westus-mjg022624называется. Нажмите кнопку "Сохранить", а затем дождитесь завершения.
  4. Вернитесь в группу ресурсов и выберите префикс сетевого интерфейса.ihs Выберите IP-конфигурации>ipconfig1. Выберите "Связать общедоступный IP-адрес". Для общедоступного IP-адреса выберите префикс ihsобщедоступного IP-адреса. Этот адрес создан ранее. В этой статье адрес ihs-public-ip-westus-mjg022624называется. Нажмите кнопку "Сохранить", а затем дождитесь завершения.

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

  1. Найдите метку DNS-имени для общедоступного IP-адреса созданного ранее dmgr. Откройте URL-адрес консоли интегрированных решений Dmgr WebSphere на новой вкладке браузера. Не забудьте использовать https. Например, https://dmgrmjg022624.westus.cloudapp.azure.com:9043/ibm/console. Обновите страницу, пока не увидите страницу приветствия для входа.

  2. Войдите в консоль с именем пользователя и паролем администратора WebSphere, сохраненного ранее, и выполните следующие действия.

    1. В области навигации выберите "Серверы все серверы>". На панели серверов по промежуточному слоям отображаются 4 сервера, включая 3 сервера приложений WebSphere, состоящие из кластера MyCluster WebSphere и 1 веб-сервера, который является IHS. Обновите страницу, пока не увидите, что все серверы запущены.

      Снимок экрана: консоль интегрированных решений Dmgr WebSphere, на котором показана страница серверов по промежуточному слоям.

    2. В области навигации выберите корпоративные приложения ">Типы>приложений WebSphere". На панели "Корпоративные приложения " должно появиться 1 приложение — websphere-cafe указано и запущено.

      Снимок экрана: консоль интегрированных решений Dmgr WebSphere, на котором показана страница корпоративных приложений.

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

      Снимок экрана: консоль интегрированных решений Dmgr WebSphere с флажком

      Снимок экрана: консоль интегрированных решений Dmgr WebSphere, на котором показана страница параметров базы данных с состоянием параметра распределенных сеансов.

  3. Найдите метку DNS-имени для общедоступного IP-адреса созданного IHS. Откройте URL-адрес консоли IHS, добавленный с помощью корневого контекста /websphere-cafe/. Обратите внимание, что не следует использовать https. Этот пример не используется https для IHS, например http://ihsmjg022624.westus.cloudapp.azure.com/websphere-cafe/. На странице должно появиться два кофе, созданных ранее.

  4. Перейдите на вкладку браузера профиля Диспетчер трафика, а затем обновите страницу, пока не увидите, что значение состояния монитора конечной точки myFailoverEndpoint станет "в Сети", а значение состояния монитора конечной точки myPrimaryEndpoint становится пониженным.

  5. Перейдите на вкладку браузера с DNS-именем профиля Диспетчер трафика , напримерhttp://tmprofile-mjg022624.trafficmanager.net/websphere-cafe/. Обновите страницу, и вы увидите те же данные, которые сохраняются в таблице данных приложения, а таблица сеансов отображается. Отображаемый пользовательский интерфейс должен быть похож на следующий снимок экрана:

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

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

Применение отработки отказа

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

  1. В поле поиска в верхней части портал Azure введите хранилища служб восстановления и выберите хранилища служб восстановления в результатах поиска.

  2. Выберите имя хранилища служб восстановления, например recovery-service-vault-westus-mjg022624.

  3. В разделе Управление выберите Планы восстановления (Site Recovery). Выберите созданный план восстановления, например recovery-plan-mjg022624.

  4. Нажмите кнопку "Зафиксировать".>

  5. Отслеживайте фиксацию в уведомлениях, пока она не завершится.

    Снимок экрана: панель уведомлений портал Azure, на котором показана фиксация отработки отказа.

    Снимок экрана: панель уведомлений портал Azure, на котором показана фиксация отработки отказа завершена.

  6. Выберите элементы в плане восстановления. Вы увидите 5 элементов, указанных как фиксация отработки отказа.

    Снимок экрана: портал Azure, в котором отображаются реплицированные элементы в виде фиксации отработки отказа.

Отключение репликации

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

  1. Для каждого элемента в плане восстановления выберите кнопку с многоточием (...), а затем нажмите кнопку "Отключить репликацию".

  2. Если вам будет предложено указать причину отключения защиты для этой виртуальной машины, выберите ее, например, я завершил перенос приложения. Нажмите ОК.

  3. Повторите шаг 1, пока не отключите репликацию для всех элементов.

  4. Отслеживайте процесс в уведомлениях до тех пор, пока он не завершится.

    Снимок экрана: панель уведомлений портал Azure, на котором показано готовое сообщение об удалении реплицированных элементов.

  5. Выберите "Обзор>удаления". Выберите Да, чтобы подтвердить удаление.

Подготовка к отработку отказа: повторная защита сайта отработки отказа

Дополнительный регион теперь является сайтом отработки отказа и активным. Его следует повторно защитить в основном регионе.

Сначала выполните следующие действия, чтобы очистить ресурсы, неиспользуемые и которые служба Azure Site Recovery будет реплицировать в основном регионе позже. Невозможно просто удалить группу ресурсов, так как site recovery восстанавливает ресурсы в существующую группу ресурсов.

  1. В поле поиска в верхней части портал Azure введите группы ресурсов и выберите группы ресурсов в результатах поиска.
  2. Выберите имя группы ресурсов для основного региона, например was-cluster-eastus-mjg022624. Сортировка элементов по типу на странице группы ресурсов.
  3. Чтобы удалить виртуальные машины, выполните следующие действия.
    1. Выберите фильтр "Тип", а затем выберите виртуальную машину в раскрывающемся списке "Значение".
    2. Выберите Применить.
    3. Выберите все виртуальные машины, нажмите кнопку "Удалить", а затем введите удаление , чтобы подтвердить удаление.
    4. Выберите команду Удалить.
    5. Отслеживайте процесс в уведомлениях до тех пор, пока он не завершится.
  4. Чтобы удалить диски, выполните следующие действия.
    1. Выберите фильтр "Тип", а затем выберите диски из раскрывающегося списка "Значение".
    2. Выберите Применить.
    3. Выберите все диски, нажмите кнопку "Удалить", а затем введите удаление , чтобы подтвердить удаление.
    4. Выберите команду Удалить.
    5. Отслеживайте процесс в уведомлениях и дождитесь завершения.
  5. Чтобы удалить конечные точки, выполните следующие действия.
    1. Выберите фильтр "Тип", выберите частную конечную точку в раскрывающемся списке "Значение".
    2. Выберите Применить.
    3. Выберите все частные конечные точки, нажмите кнопку "Удалить", а затем введите удаление , чтобы подтвердить удаление.
    4. Выберите команду Удалить.
    5. Отслеживайте процесс в уведомлениях до тех пор, пока он не завершится. Игнорируйте этот шаг, если тип частной конечной точки не указан.
  6. Чтобы удалить сетевые интерфейсы, выполните следующие действия.
    1. Выберите фильтр > "Тип" выберите сетевой интерфейс в раскрывающемся списке "Значение".
    2. Выберите Применить.
    3. Выберите все сетевые интерфейсы, нажмите кнопку "Удалить", а затем введите удаление , чтобы подтвердить удаление.
    4. Выберите команду Удалить. Отслеживайте процесс в уведомлениях до тех пор, пока он не завершится.
  7. Чтобы удалить учетные записи хранения, выполните следующие действия.
    1. Выберите фильтр > "Тип" выберите учетную запись хранения в раскрывающемся списке "Значение".
    2. Выберите Применить.
    3. Выберите все учетные записи хранения, нажмите кнопку "Удалить", а затем введите удаление , чтобы подтвердить удаление.
    4. Выберите команду Удалить. Отслеживайте процесс в уведомлениях до тех пор, пока он не завершится.

Затем выполните те же действия, что и в разделе "Настройка аварийного восстановления для кластера" с помощью раздела Azure Site Recovery для основного региона, за исключением следующих различий:

  1. В разделе "Создание хранилища служб восстановления" выполните следующие действия.
    1. Выберите группу ресурсов, развернутую в основном регионе, например was-cluster-eastus-mjg022624.
    2. Введите другое имя хранилища служб, например recovery-service-vault-eastus-mjg022624.
    3. В поле Страна или регион выберите Восточная часть США.
  2. Для включения репликации выполните следующие действия.
    1. Для региона в источнике выберите "Западная часть США".
    2. Для параметров репликации выполните следующие действия.
      1. Для целевой группы ресурсов выберите существующую группу ресурсов, развернутую в основном регионе, например was-cluster-eastus-mjg022624.
      2. Для виртуальной сети отработки отказа выберите существующую виртуальную сеть в основном регионе.
  3. Для создания плана восстановления для источника выберите "Западная часть США" и " Целевой" выберите "Восточная часть США".
  4. Пропустите шаги в разделе "Дополнительная конфигурация сети" для дополнительного региона , так как вы создали и настроили эти ресурсы ранее.

Примечание.

Вы можете заметить, что Azure Site Recovery поддерживает повторное защита виртуальных машин при наличии целевой виртуальной машины. Дополнительные сведения см. в разделе "Повторное защита виртуальной машины" руководства. Отработка отказа виртуальных машин Azure в дополнительный регион. Из-за подхода, который мы принимаем для WebSphere, эта функция не работает. Причина заключается в том, что только изменения между исходным диском и целевым диском синхронизируются для кластера WebSphere на основе результата проверки. Чтобы заменить функциональные возможности функции повторной защиты виртуальной машины, в этом руководстве устанавливается новая репликация с вторичного сайта на первичный сайт после отработки отказа. Все диски копируются из региона отработки отказа в основной регион. Дополнительные сведения см. в разделе "Что происходит во время повторной защиты?" , посвященном повторному отработке отказа виртуальных машин Azure в основном регионе.

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

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

  1. Выберите хранилище служб восстановления, развернутое в основном регионе, например recovery-service-vault-eastus-mjg022624.
  2. Выберите группу ресурсов, развернутую в основном регионе, например was-cluster-eastus-mjg022624.
  3. После включения внешнего доступа к консоли интегрированных решений WebSphere и примера приложения в основном регионе перейдите на вкладки браузера консоли интегрированных решений WebSphere и пример приложения для первичного кластера, который вы открыли ранее. Убедитесь, что они работают должным образом. В зависимости от того, сколько времени потребовалось отработки отказа, возможно, данные сеанса не отображаются в разделе "Новый кофе " примера пользовательского интерфейса приложения, если срок действия истек более одного часа ранее.
  4. В разделе "Фиксация отработки отказа" выберите хранилище служб восстановления, развернутое в основном , напримерrecovery-service-vault-eastus-mjg022624.
  5. В профиле Диспетчер трафика вы увидите, что конечная точка myPrimaryEndpoint становится подключенной, а конечная точка myFailoverEndpoint становится пониженной.
  6. В разделе "Подготовка к отработке отказа" выполните следующие действия.
    1. Основной регион — это сайт отработки отказа и активный, поэтому его следует повторно защитить в дополнительном регионе.
    2. Очистка ресурсов, развернутых в дополнительном регионе, например, в ресурсах, развернутых в was-cluster-westus-mjg022624.
    3. Используйте те же действия в разделе "Настройка аварийного восстановления для кластера" с помощью раздела Azure Site Recovery для защиты основного региона в дополнительном регионе, за исключением следующих изменений:
      1. Пропустите шаги в разделе "Создание хранилища служб восстановления", так как вы создали его ранее, например recovery-service-vault-westus-mjg022624.
      2. Для включения параметров>репликации>виртуальной сети отработки отказа выберите существующую виртуальную сеть в дополнительном регионе.
      3. Пропустите шаги в разделе "Дополнительная конфигурация сети" для раздела "Дополнительный регион ", так как вы создали и настроили эти ресурсы ранее.

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

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

  1. Введите имя группы ресурсов База данных SQL Azure серверов , например, myResourceGroup в поле поиска в верхней части портал Azure и выберите соответствующую группу ресурсов из результатов поиска.
  2. Выберите команду Удалить группу ресурсов.
  3. Введите имя группы ресурсов, чтобы подтвердить удаление, введите имя группы ресурсов.
  4. Выберите команду Удалить.
  5. Повторите шаги 1-4 для группы ресурсов Диспетчер трафика, напримерmyResourceGroupTM1.
  6. В поле поиска в верхней части портал Azure введите хранилища служб восстановления и выберите хранилища служб восстановления в результатах поиска.
  7. Выберите имя хранилища служб восстановления, например recovery-service-vault-westus-mjg022624.
  8. В разделе Управление выберите Планы восстановления (Site Recovery). Выберите созданный план восстановления, например recovery-plan-mjg022624.
  9. Используйте те же действия, что и в разделе "Отключить репликацию ", чтобы удалить блокировки для реплицированных элементов.
  10. Повторите шаги 1-4 для группы ресурсов основного кластера WebSphere, например was-cluster-westus-mjg022624.
  11. Повторите шаги 1-4 для группы ресурсов вторичного кластера WebSphere, например was-cluster-eastus-mjg022624.

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

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

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