Настройка аварийного восстановления с помощью Azure Site Recovery для многоуровневого приложения SharePoint | Документация Майкрософт

В этой статье подробно описывается защита приложения SharePoint с помощью Azure Site Recovery.

Обзор

Microsoft SharePoint — это эффективное приложение, которое может помочь рабочей группе или отделу организовать информацию, обмениваться ею и осуществлять совместную работу. SharePoint может предоставлять порталы интрасети, функции управления файлами и документами, совместной работы, социальных сетей, экстрасетей, веб-сайтов, поиска в корпоративной среде и бизнес-аналитики. Эта система также включает возможности интеграции систем и процессов и автоматизации рабочих процессов. Как правило, организации рассматривают его как приложение первого уровня, чувствительное к простоям и потере данных.

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

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

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

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

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

1. Репликация виртуальных машин VMware в Azure с помощью Site Recovery
2. Проектирование сети для аварийного восстановления
3. Тестовая отработка отказа в Azure в Site Recovery
4. Отработка отказа в Site Recovery
5. Защита Active Directory и DNS с Azure Site Recovery
6. Защита SQL Server с помощью аварийного восстановления SQL Server и Azure Site Recovery

Архитектура SharePoint

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

Поддержка Site Recovery

Служба Site Recovery не зависит от приложения и должна работать с любой версией SharePoint, выполняемой на поддерживаемом компьютере. В этой статье использовались виртуальные машины VMware с Windows Server 2012 R2 Enterprise. Кроме того, использовались выпуски SharePoint 2013 Enterprise и SQL Server 2014 Enterprise.

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

Важные аспекты

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

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

В этом руководстве приводится процедура первой репликации виртуальных машин в Azure.

• После завершения репликации перейдите на каждую виртуальную машину каждого уровня и выберите один и тот же набор доступности в разделе "Параметры>реплицированного элемента>">"Вычисления и сеть". Например, если на веб-уровне есть 3 виртуальные машины, убедитесь, что все 3 виртуальные машины настроены как часть одной группы доступности в Azure.

  

• Рекомендации по защите Active Directory и DNS см. в соответствующем документе.

• Рекомендации по защите уровня базы данных на сервере SQL Server см. в документе, посвященном защите SQL Server.

Конфигурации сети

Свойства сети

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

  

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

  

DNS и маршрутизация трафика

Для сайтов, работающих с Интернетом, создайте профиль диспетчера трафика типа "Приоритет" в подписке Azure. Затем настройте профиль DNS и диспетчера трафика следующим образом.

В профиле диспетчера трафика создайте первичную конечную точку и конечную точку восстановления. Используйте внешнюю конечную точку для локальной конечной точки и общедоступный IP-адрес для конечной точки Azure. Убедитесь, что для локальной конечной точки задан более высокий приоритет.

Разместите тестовую страницу по определенному порту (например, 800) в веб-уровне SharePoint, чтобы диспетчер трафика мог автоматически обнаруживать доступность после отработки отказа. Это обходное решение на случай, если невозможно включить анонимную проверку подлинности для всех сайтов SharePoint.

Настройте профиль Диспетчер трафика с помощью следующих параметров:

• Метод маршрутизации — "Приоритет"
• Срок жизни (TTL) DNS — "30 секунд"
• Параметры монитора конечной точки — если можно включить анонимную проверку подлинности, вы можете указать конечную точку определенного веб-сайта. В противном случае можно использовать тестовую страницу по конкретному порту (например, 800).

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

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

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

1. Создайте план восстановления, добавив виртуальные машины уровня приложений и веб-уровней.

2. Щелкните "Настроить", чтобы сгруппировать виртуальные машины. По умолчанию все виртуальные машины входят в группу 1.

   

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

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

Вы можете развернуть наиболее часто используемые скрипты Azure Site Recovery в учетной записи службы автоматизации, нажав кнопку "Развернуть в Azure". При использовании любого опубликованного скрипта убедитесь, что вы следуйте инструкциям в скрипте.

1. Добавьте скрипт предварительного действия в Группу 1 для отработки отказа группы доступности SQL. Используйте скрипт, опубликованный ASR-SQL-FailoverAG в примерах скриптов. Обязательно выполните инструкции, предусмотренные сценарием, и внесите необходимые изменения в сценарий соответствующим образом.

   

   

2. Добавьте сценарий завершающего действия для подключения подсистемы балансировки нагрузки на виртуальных машинах веб-уровня (группа 2), для которых выполнена отработка отказа. Используйте скрипт, опубликованный ASR-AddSingleLoadBalancer в примерах скриптов. Обязательно выполните инструкции, предусмотренные сценарием, и внесите необходимые изменения в сценарий соответствующим образом.

   

   

3. Добавьте действие вручную для изменения записей DNS для указания на новую ферму в Azure.

   • Для сайтов, работающих с Интернетом, изменение записей DNS после отработки отказа не требуется. Выполните действия, описанные в разделе "Руководство по настройке сети", чтобы настроить диспетчер трафика. Если профиль Диспетчер трафика настроен, как описано в предыдущем разделе, добавьте сценарий для открытия фиктивного порта (800 в примере) на виртуальной машине Azure.

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

4. Добавьте действие вручную для восстановления приложения поиска из резервной копии или запуска новой службы поиска.

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

   • Этот способ предполагает, что резервная копия приложения-службы поиска была создана до аварийного события и доступна на сайте аварийного восстановления.
   • Проще всего будет запланировать резервное копирование (например, раз в день) и использовать процедуру копирования для переноса резервной копии на сайт аварийного восстановления. Процедуры копирования могут включать программы на основе сценариев, такие как AzCopy (копирование Azure) или настройку DFSR (репликации распределенных файловых служб).
   • Когда ферма SharePoint будет запущена, перейдите в раздел "Архивация и восстановление" центра администрирования и выберите "Восстановить". Функция восстановления опрашивает указанное расположение архивации (может потребоваться обновить значение). Выберите резервную копию приложения-службы поиска, которую требуется восстановить.
   • Служба поиска будет восстановлена. Учтите, что служба восстановления ожидает ту же топологию (то же число серверов) и буквы жестких дисков, назначенные этим серверам. Дополнительные сведения см. в документе Восстановление приложений-служб поиска в SharePoint 2013.

6. Чтобы начать с нового приложения служба , выполните следующие действия:

   • Этот способ предполагает, что резервная копия базы данных Администрирование поиска доступна на сайте аварийного восстановления.
   • Так как другие базы данных приложения службы поиска не реплицируются, их необходимо повторно создать. Для этого перейдите в центр администрирования и удалите приложение-службу поиска. На любых серверах, на которых размещается индекс поиска, удалите файлы индекса.
   • Повторно создайте приложение-службу поиска, при этом базы данных будут воссозданы автоматически. Рекомендуется создать подготовленный скрипт, который повторно создает это приложение-службу, так как невозможно выполнить все действия с помощью графического интерфейса пользователя. Например, задание расположения диска индекса и настройку топологии поиска можно выполнить только с помощью командлетов PowerShell для SharePoint. Используйте командлет Windows PowerShell Restore-SPEnterpriseSearchServiceApplication и укажите базу данных администрирования поиска, для которой выполнена доставка журналов и репликация, Search_Service__DB. Этот командлет предоставляет конфигурацию поиска, схему, управляемые свойства, правила и источники и создает набор других компонентов по умолчанию.
   • Как только потребуется повторно создать приложение-службу поиска, вы должны будете запустить полный обход всех источников содержимого для восстановления этой службы. Будут потеряны некоторые данные аналитики из локальной фермы, например рекомендации по поиску.

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

   

Тестовая отработка отказа

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

1. Перейдите на портал Azure и выберите хранилище служб восстановления.
2. Выберите план восстановления, созданный для приложения SharePoint.
3. Выберите Тестовая отработка отказа.
4. Выберите точку восстановления и виртуальную сеть Azure, чтобы запустить тестовую отработку отказа.
5. Как только будет запущена вторичная среда, вы сможете выполнить проверку.
6. После завершения проверки можно нажать кнопку "Очистить тестовую отработку отказа" в плане восстановления. Тестовая среда отработки отказа будет очищена.

Инструкции по выполнению тестовой отработки отказа для AD и DNS см. в документе Рекомендации по тестированию отработки отказа для AD и DNS.

Рекомендации по выполнению тестовой отработки отказа для групп доступности SQL Always ON см. в документе Выполнение DR приложения с Azure Site Recovery и тестовая отработка отказа.

Отработка отказа

При выполнении отработки отказа используйте это руководство.

1. Перейдите на портал Azure и выберите хранилище служб восстановления.
2. Щелкните план восстановления, созданный для приложения SharePoint.
3. Щелкните "Отработка отказа".
4. Выберите точку восстановления, чтобы запустить отработку отказа.

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

Вы можете больше узнать о репликации других приложений с помощью Site Recovery.