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

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

Обзор

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

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

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

В этой статье подробно описывается защита приложения SharePoint с помощью Azure Site Recovery. Здесь мы рассмотрим рекомендации по репликации трехуровневого приложения SharePoint в Azure, выполнение отработки аварийного восстановления и отработки отказа приложения в 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.

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

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

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

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

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

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

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

  

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

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

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

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

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

  

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

  

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

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

Where	Источник	Целевой объект
Общедоступное имя DNS	Общедоступное имя DNS для сайтов SharePoint Например: sharepoint.contoso.com	Диспетчер трафика contososharepoint.trafficmanager.net
Локальное имя 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" ниже. При использовании любого опубликованного сценария необходимо выполнять указанные в нем инструкции.

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.