Настройка аварийного восстановления с помощью Azure Site Recovery для многоуровневого приложения SharePoint | Документация МайкрософтSet up disaster recovery for a multi-tier SharePoint application for disaster recovery using Azure Site Recovery

В этой статье подробно описывается защита приложения SharePoint с помощью Azure Site Recovery.This article describes in detail how to protect a SharePoint application using Azure Site Recovery.

ОбзорOverview

Microsoft SharePoint — это эффективное приложение, которое может помочь рабочей группе или отделу организовать информацию, обмениваться ею и осуществлять совместную работу.Microsoft SharePoint is a powerful application that can help a group or department organize, collaborate, and share information. SharePoint может предоставлять порталы интрасети, функции управления файлами и документами, совместной работы, социальных сетей, экстрасетей, веб-сайтов, поиска в корпоративной среде и бизнес-аналитики.SharePoint can provide intranet portals, document and file management, collaboration, social networks, extranets, websites, enterprise search, and business intelligence. Эта система также включает возможности интеграции систем и процессов и автоматизации рабочих процессов.It also has system integration, process integration, and workflow automation capabilities. Как правило, организации рассматривают его как приложение первого уровня, чувствительное к простоям и потере данных.Typically, organizations consider it as a Tier-1 application sensitive to downtime and data loss.

На данный момент Microsoft SharePoint не предоставляет какие-либо готовые функции аварийного восстановления.Today, Microsoft SharePoint does not provide any out-of-the-box disaster recovery capabilities. Независимо от типа и масштаба аварии, восстановление включает использование резервного центра обработки данных, в котором можно восстановить ферму.Regardless of the type and scale of a disaster, recovery involves the use of a standby data center that you can recover the farm to. Резервные центры обработки данных требуются для сценариев, когда локальные избыточные системы и резервные копии не позволяют выполнить восстановление после сбоя в основном центре обработки данных.Standby data centers are required for scenarios where local redundant systems and backups cannot recover from the outage at the primary data center.

Хорошее решение аварийного восстановления должно допускать моделирование планов восстановления для сложных архитектур приложений, таких как SharePoint.A good disaster recovery solution should allow modeling of recovery plans around the complex application architectures such as SharePoint. Оно также должно включать возможность добавления настраиваемых действий для обработки сопоставлений приложений между различными уровнями и, таким образом, обеспечивать быструю отработку отказа с низким RTO в случае аварии.It should also have the ability to add customized steps to handle application mappings between various tiers and hence providing a single-click failover with a lower RTO in the event of a disaster.

В этой статье подробно описывается защита приложения SharePoint с помощью Azure Site Recovery.This article describes in detail how to protect a SharePoint application using Azure Site Recovery. Здесь мы рассмотрим рекомендации по репликации трехуровневого приложения SharePoint в Azure, выполнение отработки аварийного восстановления и отработки отказа приложения в Azure.This article will cover best practices for replicating a three tier SharePoint application to Azure, how you can do a disaster recovery drill, and how you can failover the application to Azure.

В видеоролике ниже рассказывается о восстановлении многоуровневого приложения в Azure.You can watch the below video about recovering a multi tier application to Azure.

Предварительные требованияPrerequisites

Прежде чем продолжить, ознакомьтесь со следующими статьями:Before you start, make sure you understand the following:

  1. Репликация виртуальных машин VMware в Azure с помощью Site RecoveryReplicating a virtual machine to Azure
  2. Проектирование сети для аварийного восстановленияHow to design a recovery network
  3. Тестовая отработка отказа в Azure в Site RecoveryDoing a test failover to Azure
  4. Отработка отказа в Site RecoveryDoing a failover to Azure
  5. Защита Active Directory и DNS с Azure Site RecoveryHow to replicate a domain controller
  6. Защита SQL Server с помощью аварийного восстановления SQL Server и Azure Site RecoveryHow to replicate SQL Server

Архитектура SharePointSharePoint architecture

SharePoint можно развертывать на одном или нескольких серверах с помощью многоуровневых топологий и ролей сервера для реализации архитектуры фермы, отвечающей конкретным требованиям и целям.SharePoint can be deployed on one or more servers using tiered topologies and server roles to implement a farm design that meets specific goals and objectives. Типичная большая ферма серверов SharePoint с высокой загрузкой, которая поддерживает большое число одновременных пользователей и элементов содержимого, использует группирование служб как часть стратегии масштабирования.A typical large, high-demand SharePoint server farm that supports a high number of concurrent users and a large number of content items use service grouping as part of their scalability strategy. Этот подход включает выполнение служб на выделенных серверах, их группирование, а затем масштабирование серверов как группы.This approach involves running services on dedicated servers, grouping these services together, and then scaling out the servers as a group. Следующие топологии иллюстрирует группирование служб и серверов для трехуровневой фермы серверов SharePoint.The following topology illustrates the service and server grouping for a three tier SharePoint server farm. Подробное руководство по различным топологиям SharePoint можно найти в документации по SharePoint и описаниях архитектур семейств продуктов.Please refer to SharePoint documentation and product line architectures for detailed guidance on different SharePoint topologies. Дополнительные сведения о развертывании SharePoint 2013 см. в этом документе.You can find more details about SharePoint 2013 deployment in this document.

Модель развертывания 1

Поддержка Site RecoverySite Recovery support

Для написания этой статьи использовались виртуальные машины VMware под управлением Windows Server 2012 R2 Enterprise.For creating this article, VMware virtual machines with Windows Server 2012 R2 Enterprise were used. Кроме того, использовались выпуски SharePoint 2013 Enterprise и SQL Server 2014 Enterprise.SharePoint 2013 Enterprise edition and SQL server 2014 Enterprise edition were used. Так как репликация Site Recovery не зависит от приложения, описанные здесь рекомендации также подходят для сценариев, представленных ниже.As Site Recovery replication is application agnostic, the recommendations provided here are expected to hold on for following scenarios as well.

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

СценарийScenario На дополнительный сайтTo a secondary site В AzureTo Azure
Hyper-VHyper-V YesYes YesYes
VMwareVMware YesYes YesYes
Физический серверPhysical server YesYes YesYes
Таблицы AzureAzure Нет данныхNA YesYes

Версии SharePointSharePoint Versions

Поддерживаются следующие версии SharePoint Server.The following SharePoint server versions are supported.

  • SharePoint Server 2013 StandardSharePoint server 2013 Standard
  • SharePoint Server 2013 EnterpriseSharePoint server 2013 Enterprise
  • SharePoint Server 2016 StandardSharePoint server 2016 Standard
  • SharePoint Server 2016 EnterpriseSharePoint server 2016 Enterprise

Важные аспектыThings to keep in mind

При использовании общего кластера на основе диска в качестве любого из уровней приложения вы не сможете использовать репликацию Site Recovery для репликации таких виртуальных машин.If you are using a shared disk-based cluster as any tier in your application then you will not be able to use Site Recovery replication to replicate those virtual machines. Можно использовать собственный механизм репликации, предоставляемый приложением, а затем применить план восстановления для отработки отказа всех уровней.You can use native replication provided by the application and then use a recovery plan to failover all tiers.

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

В этом руководстве приводится процедура первой репликации виртуальных машин в Azure.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'. Например, если веб-уровень включает три виртуальные машины, убедитесь, что все три виртуальные машины настроены как часть одной группы доступности в Azure.For example, if your web tier has 3 VMs, ensure all the 3 VMs are configured to be part of same availability set in Azure.

    Set-Availability-Set

  • Рекомендации по защите Active Directory и DNS см. в соответствующем документе.For guidance on protecting Active Directory and DNS, refer to Protect Active Directory and DNS document.

  • Рекомендации по защите уровня базы данных на сервере SQL Server см. в документе, посвященном защите SQL Server.For guidance on protecting database tier running on SQL server, refer to Protect SQL Server document.

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

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

  • Для виртуальных машин веб-уровня и уровня приложений настройте параметры сети на портале Azure таким образом, чтобы виртуальные машины подключались к правильной сети аварийного восстановления после отработки отказа.For the App and Web tier VMs, configure network settings in Azure portal so that the VMs get attached to the right DR network after failover.

    Выбор сети

  • Если вы используете статический IP-адрес, укажите нужный IP-адрес для виртуальной машины в поле Целевой IP-адрес.If you are using a static IP, then specify the IP that you want the virtual machine to take in the Target IP field

    Настройка статического IP-адреса

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

Для сайтов, работающих с Интернетом, создайте профиль диспетчера трафика типа "Приоритет" в подписке Azure.For internet facing sites, create a Traffic Manager profile of 'Priority' type in the Azure subscription. Затем настройте профиль DNS и диспетчера трафика следующим образом.And then configure your DNS and Traffic Manager profile in the following manner.

WhereWhere ИсточникSource ЦельTarget
Общедоступное имя DNSPublic DNS Общедоступное имя DNS для сайтов SharePointPublic DNS for SharePoint sites

Например: sharepoint.contoso.comEx: sharepoint.contoso.com
Диспетчер трафикаTraffic Manager

contososharepoint.trafficmanager.netcontososharepoint.trafficmanager.net
Локальное имя DNSOn-premises DNS sharepointonprem.contoso.comsharepointonprem.contoso.com Общедоступный IP-адрес в локальной фермеPublic IP on the on-premises farm

В профиле диспетчера трафика создайте первичную конечную точку и конечную точку восстановления.In the Traffic Manager profile, create the primary and recovery endpoints. Используйте внешнюю конечную точку для локальной конечной точки и общедоступный IP-адрес для конечной точки Azure.Use the external endpoint for on-premises endpoint and public IP for Azure endpoint. Убедитесь, что для локальной конечной точки задан более высокий приоритет.Ensure that the priority is set higher to on-premises endpoint.

Разместите тестовую страницу по определенному порту (например, 800) в веб-уровне SharePoint, чтобы диспетчер трафика мог автоматически обнаруживать доступность после отработки отказа.Host a test page on a specific port (for example, 800) in the SharePoint web tier in order for Traffic Manager to automatically detect availability post failover. Это обходное решение на случай, если невозможно включить анонимную проверку подлинности для всех сайтов SharePoint.This is a workaround in case you cannot enable anonymous authentication on any of your SharePoint sites.

Настройте профиль диспетчера трафика, используя приведенные ниже параметры.Configure the Traffic Manager profile with the below settings.

  • Метод маршрутизации — "Приоритет"Routing method - 'Priority'
  • Срок жизни (TTL) DNS — "30 секунд"DNS time to live (TTL) - '30 seconds'
  • Параметры монитора конечной точки — если можно включить анонимную проверку подлинности, вы можете указать конечную точку определенного веб-сайта.Endpoint monitor settings - If you can enable anonymous authentication, you can give a specific website endpoint. В противном случае можно использовать тестовую страницу по конкретному порту (например, 800).Or, you can use a test page on a specific port (for example, 800).

Создание плана восстановленияCreating a recovery plan

План восстановления в многоуровневом приложении позволяет выполнять виртуализацию отработки отказов различных уровней, а значит — поддерживает целостность на уровне приложения.A recovery plan allows sequencing the failover of various tiers in a multi-tier application, hence, maintaining application consistency. При создании плана восстановления для многоуровневого веб-приложения следует выполнить действия, приведенные ниже.Follow the below steps while creating a recovery plan for a multi-tier web application. Дополнительные сведения см. в статье Создание планов восстановления.Learn more about creating a recovery plan.

Добавление виртуальных машин в группы отработки отказаAdding virtual machines to failover groups

  1. Создайте план восстановления, добавив виртуальные машины веб-уровня и уровня приложений.Create a recovery plan by adding the App and Web tier VMs.
  2. Щелкните "Настроить", чтобы сгруппировать виртуальные машины.Click on 'Customize' to group the VMs. По умолчанию все виртуальные машины входят в группу 1.By default, all VMs are part of 'Group 1'.

    Настройка плана восстановления

  3. Создайте другую группу (группа 2) и переместите виртуальные машины веб-уровня в эту новую группу.Create another Group (Group 2) and move the Web tier VMs into the new group. Виртуальные машины уровня приложений должны входить в группу 1, а виртуальные машины веб-уровня — в группу 2.Your App tier VMs should be part of 'Group 1' and Web tier VMs should be part of 'Group 2'. Это позволяет гарантировать, что виртуальные машины уровня приложений будут загружаться до виртуальных машин веб-уровня.This is to ensure that the App tier VMs boot up first followed by Web tier VMs.

Добавление скриптов в план восстановленияAdding scripts to the recovery plan

Наиболее часто используемые сценарии Azure Site Recovery можно развернуть в учетной записи автоматизации, нажав кнопку "Развертывание в Azure" ниже.You can deploy the most commonly used Azure Site Recovery scripts into your Automation account clicking the 'Deploy to Azure' button below. При использовании любого опубликованного сценария необходимо выполнять указанные в нем инструкции.When you are using any published script, ensure you follow the guidance in the script.

Развертывание в AzureDeploy to Azure

  1. Добавьте сценарий предварительного действия в группу 1 для отработки отказа группы доступности SQL.Add a pre-action script to 'Group 1' to failover SQL Availability group. Используйте сценарий ASR-SQL-FailoverAG, опубликованный в примерах сценариев.Use the 'ASR-SQL-FailoverAG' script published in the sample scripts. Обязательно выполните инструкции, предусмотренные сценарием, и внесите необходимые изменения в сценарий соответствующим образом.Ensure you follow the guidance in the script and make the required changes in the script appropriately.

    Add-AG-Script-Step-1

    Add-AG-Script-Step-2

  2. Добавьте сценарий завершающего действия для подключения подсистемы балансировки нагрузки на виртуальных машинах веб-уровня (группа 2), для которых выполнена отработка отказа.Add a post action script to attach a load balancer on the failed over virtual machines of Web tier (Group 2). Используйте сценарий ASR-AddSingleLoadBalancer, опубликованный в примерах сценариев.Use the 'ASR-AddSingleLoadBalancer' script published in the sample scripts. Обязательно выполните инструкции, предусмотренные сценарием, и внесите необходимые изменения в сценарий соответствующим образом.Ensure you follow the guidance in the script and make the required changes in the script appropriately.

    Add-LB-Script-Step-1

    Add-LB-Script-Step-2

  3. Добавьте действие вручную для изменения записей DNS для указания на новую ферму в Azure.Add a manual step to update the DNS records to point to the new farm in Azure.

    • Для сайтов, работающих с Интернетом, изменение записей DNS после отработки отказа не требуется.For internet facing sites, no DNS updates are required post failover. Выполните действия, описанные в разделе "Руководство по настройке сети", чтобы настроить диспетчер трафика.Follow the steps described in the 'Networking guidance' section to configure Traffic Manager. Если профиль диспетчера трафика настроен, как описано в предыдущем разделе, добавьте сценарий для открытия фиктивного порта (например, 800) на виртуальной машине Azure.If the Traffic Manager profile has been set up as described in the previous section, add a script to open dummy port (800 in the example) on the Azure VM.

    • Для внутренних сайтов добавьте действие вручную для изменения записи DNS для указания на IP-адресе подсистемы балансировки нагрузки новой виртуальной машины веб-уровня.For internal facing sites, add a manual step to update the DNS record to point to the new Web tier VM’s load balancer IP.

  4. Добавьте действие вручную для восстановления приложения поиска из резервной копии или запуска новой службы поиска.Add a manual step to restore search application from a backup or start a new search service.

  5. Для восстановления приложения-службы поиска из резервной копии выполните следующие действия.For restoring Search service application from a backup, follow below steps.

    • Этот способ предполагает, что резервная копия приложения-службы поиска была создана до аварийного события и доступна на сайте аварийного восстановления.This method assumes that a backup of the Search Service Application was performed before the catastrophic event and that the backup is available at the DR site.
    • Проще всего будет запланировать резервное копирование (например, раз в день) и использовать процедуру копирования для переноса резервной копии на сайт аварийного восстановления.This can easily be achieved by scheduling the backup (for example, once daily) and using a copy procedure to place the backup at the DR site. Процедуры копирования могут включать программы на основе сценариев, такие как AzCopy (копирование Azure) или настройку DFSR (репликации распределенных файловых служб).Copy procedures could include scripted programs such as AzCopy (Azure Copy) or setting up DFSR (Distributed File Services Replication).
    • Когда ферма SharePoint будет запущена, перейдите в раздел "Архивация и восстановление" центра администрирования и выберите "Восстановить".Now that the SharePoint farm is running, navigate the Central Administration, 'Backup and Restore' and select Restore. Функция восстановления опрашивает указанное расположение архивации (может потребоваться обновить значение).The restore interrogates the backup location specified (you may need to update the value). Выберите резервную копию приложения-службы поиска, которую требуется восстановить.Select the Search Service Application backup you would like to restore.
    • Служба поиска будет восстановлена.Search is restored. Учтите, что служба восстановления ожидает ту же топологию (то же число серверов) и буквы жестких дисков, назначенные этим серверам.Keep in mind that the restore expects to find the same topology (same number of servers) and same hard drive letters assigned to those servers. Дополнительные сведения см. в документе Восстановление приложений-служб поиска в SharePoint 2013.For more information, see 'Restore Search service application in SharePoint 2013' document.
  6. Чтобы начать работу с новым приложением-службой поиска, выполните следующие действия.For starting with a new Search service application, follow below steps.

    • Этот способ предполагает, что резервная копия базы данных "Администрирование поиска" доступна на сайте аварийного восстановления.This method assumes that a backup of the “Search Administration” database is available at the DR site.
    • Поскольку другие базы данных приложения-службы поиска не реплицируются, их потребуется создать повторно.Since the other Search Service Application databases are not replicated, they need to be re-created. Для этого перейдите в центр администрирования и удалите приложение-службу поиска.To do so, navigate to Central Administration and delete the Search Service Application. На любых серверах, на которых размещается индекс поиска, удалите файлы индекса.On any servers which host the Search Index, delete the index files.
    • Повторно создайте приложение-службу поиска, при этом базы данных будут воссозданы автоматически.Re-create the Search Service Application and this re-creates the databases. Рекомендуется заранее подготовить сценарий, который повторно создает это приложение-службу, поскольку вы не сможете выполнить все действия через графический интерфейс.It is recommended to have a prepared script that re-creates this service application since it is not possible to perform all actions via the GUI. Например, задание расположения диска индекса и настройку топологии поиска можно выполнить только с помощью командлетов PowerShell для SharePoint.For example, setting the index drive location and configuring the search topology are only possible by using SharePoint PowerShell cmdlets. Используйте командлет Windows PowerShell Restore-SPEnterpriseSearchServiceApplication и укажите базу данных администрирования поиска, для которой выполнена доставка журналов и репликация, Search_Service__DB.Use the Windows PowerShell cmdlet Restore-SPEnterpriseSearchServiceApplication and specify the log-shipped and replicated Search Administration database, Search_Service__DB. Этот командлет предоставляет конфигурацию поиска, схему, управляемые свойства, правила и источники и создает набор других компонентов по умолчанию.This cmdlet gives the search configuration, schema, managed properties, rules, and sources and creates a default set of the other components.
    • Как только потребуется повторно создать приложение-службу поиска, вы должны будете запустить полный обход всех источников содержимого для восстановления этой службы.Once the Search Service Application has be re-created, you must start a full crawl for each content source to restore the Search Service. Будут потеряны некоторые данные аналитики из локальной фермы, например рекомендации по поиску.You lose some analytics information from the on-premises farm, such as search recommendations.
  7. После завершения всех этих действий сохраните план восстановления. Окончательный план восстановления будет похож на приведенный ниже.Once all the steps are completed, save the recovery plan and the final recovery plan will look like following.

    Сохраненный план восстановления

Тестовая отработка отказаDoing a test failover

Чтобы выполнить тестовую отработку отказа, используйте это руководство.Follow this guidance to do a test failover.

  1. Перейдите на портал Azure и выберите хранилище служб восстановления.Go to Azure portal and select your Recovery Service vault.
  2. Щелкните план восстановления, созданный для приложения SharePoint.Click on the recovery plan created for SharePoint application.
  3. Щелкните "Тестовая отработка отказа".Click on 'Test Failover'.
  4. Выберите точку восстановления и виртуальную сеть Azure, чтобы запустить тестовую отработку отказа.Select recovery point and Azure virtual network to start the test failover process.
  5. Как только будет запущена вторичная среда, вы сможете выполнить проверку.Once the secondary environment is up, you can perform your validations.
  6. После завершения проверки можно нажать кнопку "Очистить тестовую отработку отказа" в плане восстановления. Тестовая среда отработки отказа будет очищена.Once the validations are complete, you can click 'Cleanup test failover' on the recovery plan and the test failover environment is cleaned.

Инструкции по выполнению тестовой отработки отказа для AD и DNS см. в документе Рекомендации по тестированию отработки отказа для AD и DNS.For guidance on doing test failover for AD and DNS, refer to Test failover considerations for AD and DNS document.

Инструкции по выполнении тестовой отработки отказа для групп доступности SQL AlwaysOn см. в соответствующем документе.For guidance on doing test failover for SQL Always ON availability groups, refer to Doing Test failover for SQL Server Always On document.

Отработка отказаDoing a failover

При выполнении отработки отказа используйте это руководство.Follow this guidance for doing a failover.

  1. Перейдите на портал Azure и выберите хранилище служб восстановления.Go to Azure portal and select your Recovery Services vault.
  2. Щелкните план восстановления, созданный для приложения SharePoint.Click on the recovery plan created for SharePoint application.
  3. Щелкните "Отработка отказа".Click on 'Failover'.
  4. Выберите точку восстановления, чтобы запустить отработку отказа.Select recovery point to start the failover process.

Дополнительная информацияNext steps

Вы можете больше узнать о репликации других приложений с помощью Site Recovery.You can learn more about replicating other applications using Site Recovery.