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

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

Overview

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

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

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

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

Prerequisites

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

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 architecture

SharePoint можно развертывать на одном или нескольких серверах с помощью многоуровневых топологий и ролей сервера для реализации архитектуры фермы, отвечающей конкретным требованиям и целям. Типичная большая ферма серверов SharePoint с высокой загрузкой, которая поддерживает большое число одновременных пользователей и элементов содержимого, использует группирование служб как часть стратегии масштабирования. Этот подход включает выполнение служб на выделенных серверах, их группирование, а затем масштабирование серверов как группы. Следующие топологии иллюстрирует группирование служб и серверов для трехуровневой фермы серверов SharePoint. Дополнительные сведения о различных топологиях SharePoint см. в документации и архитектуре продуктов SharePoint. You can find more details about SharePoint 2013 deployment in this document.

Поддержка Site Recovery

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

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

Scenario	На дополнительный сайт	To Azure
Hyper-V	Yes	Yes
VMware	Yes	Yes
Physical server	Yes	Yes
Azure	NA	Yes

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

Если вы используете общий дисковый кластер в качестве любого уровня в приложении, вы не сможете использовать репликацию Site Recovery для репликации этих виртуальных машин. You can use native replication provided by the application and then use a recovery plan to fail over all tiers.

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

Follow this guidance to start replicating the virtual machine to Azure.

• Once the replication is complete, make sure you go to each virtual machine of each tier and select same availability set in Replicated item>Settings>Properties>Compute and Network. Например, если на веб-уровне есть 3 виртуальные машины, убедитесь, что все 3 виртуальные машины настроены как часть одной группы доступности в Azure.

  

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

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

Networking configuration

Network properties

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

  

• If you're using a static IP, then specify the IP that you want the virtual machine to take in the Target IP field

  

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

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

Where	Source	Target
Public DNS	Общедоступный DNS для сайтов SharePoint Ex: sharepoint.contoso.com	Traffic Manager contososharepoint.trafficmanager.net
On-premises DNS	sharepointonprem.contoso.com	Общедоступный IP-адрес в локальной ферме

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

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

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

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

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

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

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

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

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

   

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

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

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

Развертывание в 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. Чтобы начать с нового приложения служба , выполните следующие действия:

   • This method assumes that a backup of the Search Administration database is available at the DR site.
   • Так как другие базы данных приложения службы поиска не реплицируются, их необходимо повторно создать. Для этого перейдите в центр администрирования и удалите приложение-службу поиска. На любых серверах, на которых размещается индекс поиска, удалите файлы индекса.
   • Повторно создайте приложение-службу поиска, при этом базы данных будут воссозданы автоматически. Рекомендуется создать подготовленный скрипт, который повторно создает это приложение-службу, так как невозможно выполнить все действия с помощью графического интерфейса пользователя. Например, задание расположения диска индекса и настройку топологии поиска можно выполнить только с помощью командлетов PowerShell для SharePoint. Используйте командлет Windows PowerShell Restore-SPEnterpriseSearchServiceApplication и укажите базу данных администрирования поиска, для которой выполнена доставка журналов и репликация, Search_Service__DB. Этот командлет предоставляет конфигурацию поиска, схему, управляемые свойства, правила и источники и создает набор других компонентов по умолчанию.
   • Как только потребуется повторно создать приложение-службу поиска, вы должны будете запустить полный обход всех источников содержимого для восстановления этой службы. Будут потеряны некоторые данные аналитики из локальной фермы, например рекомендации по поиску.

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

   

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

Follow this guidance to do a test failover.

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

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

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

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

Follow this guidance for doing a failover.

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

Next steps

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