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


Настройка аварийного восстановления для многоуровневого веб-приложения на основе IIS

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

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

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

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

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

Предпосылки

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

Шаблоны развертывания

Веб-приложение на основе IIS обычно следует одному из следующих шаблонов развертывания:

Шаблон развертывания 1

Веб-ферма на основе IIS с маршрутизацией запросов приложений (ARR), сервером IIS и SQL Server.

Схема веб-фермы на основе IIS с тремя уровнями

Шаблон развертывания 2

Веб-ферма на основе IIS с ARR, сервером IIS, сервером приложений и SQL Server.

Схема веб-фермы на основе IIS с четырьмя уровнями

Поддержка Site Recovery

В примерах этой статьи мы используем виртуальные машины VMware с IIS 7.5 в Windows Server 2012 R2 Enterprise. Так как репликация Site Recovery не зависит от приложения, рекомендации в этой статье должны применяться в сценариях, перечисленных в следующей таблице, и для разных версий IIS.

Исходный и целевой объект

Сценарий На дополнительный сайт в Azure
Hyper-V Да Да
VMware Да Да
Физический сервер нет Да
Лазурный NA Да

Репликация виртуальных машин

Чтобы начать реплицировать все виртуальные машины веб-фермы IIS в Azure, следуйте инструкциям в разделе Site Recovery, посвященном тестовой отработке отказа в Azure.

Если вы используете статический IP-адрес, можно указать IP-адрес, который требуется принять виртуальной машине. Чтобы задать IP-адрес, перейдите к параметрам> сетиTARGET IP.

Снимок экрана, показывающий, как установить целевой IP-адрес на панели сети Site Recovery

Создание плана восстановления

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

Добавление виртуальных машин в группы устойчивости к сбоям

Обычное веб-приложение IIS нескольких уровней состоит из следующих компонентов:

  • Уровень базы данных с виртуальными машинами SQL.
  • Веб-уровень, состоящий из сервера IIS и уровня приложений.

Добавьте виртуальные машины в разные группы на основе уровня:

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

Дополнительные сведения см. в разделе "Настройка плана восстановления".

Добавление скрипта в план восстановления

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

Обновление DNS

Если DNS настроено для динамического обновления DNS, виртуальные машины обычно обновляют DNS с новым IP-адресом при запуске. Если вы хотите добавить явный шаг для обновления DNS с новыми IP-адресами виртуальных машин, добавьте скрипт для обновления IP-адресов в DNS в качестве действия после завершения отказа в группах планов восстановления.

Строка подключения в приложении web.config

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

Если строка подключения ссылается на виртуальную машину базы данных с помощью IP-адреса, ее необходимо обновить после отработки отказа. Например, следующая строка подключения указывает на базу данных с IP-адресом 127.0.1.2:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<connectionStrings>
<add name="ConnStringDb1" connectionString="Data Source= 127.0.1.2\SqlExpress; Initial Catalog=TestDB1;Integrated Security=False;" />
</connectionStrings>
</configuration>

Чтобы обновить строку подключения на веб-уровне, добавьте скрипт обновления подключения IIS после группы 3 в плане восстановления.

Привязки сайта для приложения

Каждый сайт состоит из связывающей информации. Сведения о привязке включают тип привязки, IP-адрес, по которому сервер IIS прослушивает запросы сайта, номер порта и имена узлов для сайта. Во время переключения на резерв может потребоваться обновить эти привязки, если произошло изменение IP-адреса, который с ними связан.

Замечание

Если для привязки сайта задано значение Все не назначенные, вам не нужно обновлять эту привязку после устранения неполадок. Кроме того, если IP-адрес, связанный с сайтом, не изменился после отказа, не нужно обновлять привязку сайта. (Хранение IP-адреса зависит от сетевой архитектуры и подсетей, назначенных основным сайтам и сайтам восстановления. Обновление их может оказаться невозможным для вашей организации.)

Снимок экрана: настройка привязки TLS/SSL

Если вы связывали IP-адрес с сайтом, обновите все привязки сайта новым IP-адресом. Чтобы изменить привязки сайта, добавьте скрипт обновления веб-уровня IIS после группы 3 в плане восстановления.

Обновление IP-адреса подсистемы балансировки нагрузки

Если у вас есть виртуальная машина ARR, чтобы обновить IP-адрес, добавьте скрипт отработки отказа IIS ARR после группы 4.

Привязка TLS/SSL-сертификата для подключения HTTPS

Веб-сайт может иметь связанный TLS/SSL-сертификат, который помогает обеспечить безопасную связь между веб-сервером и браузером пользователя. Если веб-сайт имеет подключение HTTPS, а также ассоциированную привязку HTTPS сайта к IP-адресу сервера IIS с привязкой TLS/SSL-сертификата, необходимо добавить новую привязку сайта для сертификата с IP-адресом виртуальной машины IIS после восстановления после сбоя.

Сертификат TLS/SSL можно выдавать для этих компонентов:

  • Полное доменное имя веб-сайта.
  • Имени сервера.
  • Подстановочный сертификат для доменного имени.
  • IP-адреса. Если сертификат TLS/SSL выдан по IP-адресу сервера IIS, необходимо вывести другой СЕРТИФИКАТ TLS/SSL по IP-адресу сервера IIS на сайте Azure. Необходимо создать дополнительную привязку TLS для этого сертификата. Из-за этого рекомендуется не использовать SSL-сертификат, выданный по IP-адресу. Этот параметр менее широко используется и в ближайшее время будет устарел в соответствии с новыми изменениями центра сертификации или браузера.

Обновление зависимости между веб-уровнем и уровнем приложения

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

Запуск тестового переключения на резервный режим

  1. На портале Azure выберите хранилище служб восстановления.
  2. Выберите план восстановления, созданный для веб-фермы IIS.
  3. Выберите Тест отказоустойчивости.
  4. Чтобы начать процесс тестового переключения, выберите точку восстановления и виртуальную сеть Azure.
  5. При запуске вторичной среды можно выполнить проверку.
  6. После завершения проверок, чтобы очистить тестовую среду отказоустойчивости, выберите Validations complete.

Дополнительные сведения см. в статье "Тестовая отработка отказа в Azure" в Site Recovery.

Запустить резервное переключение

  1. На портале Azure выберите хранилище служб восстановления.
  2. Выберите план восстановления, созданный для веб-фермы IIS.
  3. Выберите Failover.
  4. Чтобы запустить процесс переключения на резерв, выберите точку восстановления.

Дополнительные сведения см. в разделе "Переключение на резервное оборудование" в Site Recovery.

Дальнейшие шаги