Аварийное восстановление SharePoint Server 2013 в Microsoft AzureSharePoint Server 2013 Disaster Recovery in Microsoft Azure

Сводка. С помощью Azure вы можете создать среду аварийного восстановления для локальной фермы SharePoint. В этой статье описываются разработка и реализация этого решения.Summary: Using Azure, you can create a disaster-recovery environment for your on-premises SharePoint farm. This article describes how to design and implement this solution.

Смотрите видео с обзором аварийного восстановления в SharePoint Server 2013Watch the SharePoint Server 2013 disaster recovery overview video

В случае возникновения аварии в локальной среде SharePoint вашей главной задачей является быстрое восстановление работы системы. Аварийное восстановление SharePoint выполняется быстрее и проще, если в Microsoft Azure уже запущена резервная среда. В этом видеоролике рассматриваются основные концепции "горячей" отработки отказов в SharePoint и дополняются подробные сведения, приведенные в этой статье.When disaster strikes your SharePoint on-premises environment, your top priority is to get the system running again quickly. Disaster recovery with SharePoint is quicker and easier when you have a backup environment already running in Microsoft Azure. This video explains the main concepts of a SharePoint warm failover environment and complements the full details available in this article.

Используйте эту статью вместе со следующей моделью решения: Аварийное восстановление SharePoint в Microsoft Azure.Use this article with the following solution model: SharePoint Disaster Recovery in Microsoft Azure.

Процесс аварийного восстановления SharePoint в AzureSharePoint disaster-recovery process to Azure

PDF | VisioPDF | Visio

В этой статьеIn this article:

Использование служб инфраструктуры Azure для аварийного восстановленияUse Azure Infrastructure Services for disaster recovery

Во многих организациях нет среды аварийного восстановления для SharePoint, создание и поддержка которой в локальной организации может требовать значительных затрат. Службы инфраструктуры Azure предоставляют удобные способы создания сред аварийного восстановления с большей гибкостью и меньшими затратами, чем в локальной организации.Many organizations do not have a disaster recovery environment for SharePoint, which can be expensive to build and maintain on-premises. Azure Infrastructure Services provides compelling options for disaster recovery environments that are more flexible and less expensive than the on-premises alternatives.

Используя Службы инфраструктуры Azure, вы получаете следующие преимущества:The advantages for using Azure Infrastructure Services include:

  • Меньшее количество дорогостоящих ресурсов Поддерживайте и оплачивайте меньше ресурсов, чем в локальных средах аварийного восстановления. Количество ресурсов зависит от выбранного типа среды: с холодным или горячим резервированием либо горячей заменой.Fewer costly resources Maintain and pay for fewer resources than on-premises disaster recovery environments. The number of resources depends on which disaster-recovery environment you choose: cold standby, warm standby, or hot standby.

  • Повышенная гибкость ресурсов В случае аварии вы можете с легкостью развернуть ферму восстановления SharePoint в соответствии с требованиями к нагрузке. Когда необходимость в дополнительных ресурсах пропадет, вы можете свернуть ферму.Better resource flexibility In the event of a disaster, easily scale out your recovery SharePoint farm to meet load requirements. Scale in when you no longer need the resources.

  • Меньшая зависимость от центров обработки данных Используйте Службы инфраструктуры Azure, чтобы не вкладывать средства во вспомогательный центр обработки данных в другом регионе.Lower datacenter commitment Use Azure Infrastructure Services instead of investing in a secondary datacenter in a different region.

Для организаций, делающих первые шаги в подготовке аварийного восстановления, доступны простые варианты, а организации с высокими требованиями к надежности могут воспользоваться расширенными вариантами. Определения холодного и горячего резервирования, а также горячей замены немного отличаются в средах, которые размещаются на облачной платформе. В следующей таблице описываются среды для создания фермы восстановления SharePoint в Azure.There are less-complex options for organizations just getting started with disaster recovery and advanced options for organizations with high-resilience requirements. The definitions for cold, warm, and hot standby environments are a little different when the environment is hosted on a cloud platform. The following table describes these environments for building a SharePoint recovery farm in Azure.

Таблица. Среды восстановленияTable: Recovery environments

Тип среды восстановленияType of recovery environment ОписаниеDescription
Горячая заменаHot
Полноразмерная ферма подготавливается, обновляется и работает в ждущем режиме.A fully sized farm is provisioned, updated, and running on standby.
Горячее резервированиеWarm
Создается ферма, а также работают и обновляются виртуальные машины.The farm is built and virtual machines are running and updated.
Восстановление включает присоединение баз данных контента, подготовку приложений-служб и обход контента.Recovery includes attaching content databases, provisioning service applications, and crawling content.
Эта ферма может быть уменьшенной версией рабочей фермы и расширяться для обслуживания всех пользователей.The farm can be a smaller version of the production farm and then scaled out to serve the full user base.
Холодное резервированиеCold
Ферма создается в полном масштабе, но виртуальные машины останавливаются.The farm is fully built, but the virtual machines are stopped.
Обслуживание среды включает запуск виртуальных машин по мере необходимости, а также исправление, обновление и проверку среды.Maintaining the environment includes starting the virtual machines from time to time, patching, updating, and verifying the environment.
Полный запуск среды в случае сбоя.Start the full environment in the event of a disaster.

Важно оценить целевое время восстановления (RTO) и целевую точку восстановления (RPO) для вашей организации. Эти требования определяют, какая среда будет наиболее подходящей.It's important to evaluate your organization's Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs). These requirements determine which environment is the most appropriate investment for your organization.

В этой статье описывается реализация среды горячего резервирования. Ее также можно применять для создания среды холодного восстановления, выполнив соответствующие дополнительные действия. В этой статье не описывается реализация среды горячей замены.The guidance in this article describes how to implement a warm standby environment. You can also adapt it to a cold standby environment, although you need to follow additional procedures to support this kind of environment. This article does not describe how to implement a hot standby environment.

Дополнительные сведения о решениях аварийного восстановления см. в статьях High availability and disaster recovery concepts in SharePoint 2013 и Choose a disaster recovery strategy for SharePoint 2013.For more information about disaster recovery solutions, see High availability and disaster recovery concepts in SharePoint 2013 and Choose a disaster recovery strategy for SharePoint 2013.

Описание решенияSolution description

Для решения аварийного восстановления с горячим резервированием необходимы следующие компоненты среды:The warm standby disaster-recovery solution requires the following environment:

  • локальная рабочая ферма SharePoint;An on-premises SharePoint production farm

  • среда восстановления SharePoint в Azure;A recovery SharePoint farm in Azure

  • VPN-подключение типа "сеть-сеть" между двумя средами.A site-to-site VPN connection between the two environments

На следующем рисунке показаны эти три элемента.The following figure illustrates these three elements.

Рисунок. Элементы решения горячего резервирования в AzureFigure: Elements of a warm standby solution in Azure

Элементы решения "горячего" резервирования SharePoint в Azure

Доставка журналов SQL Server с репликацией распределенной файловой системы (DFSR) используется для копирования резервных копий баз данных и журналов транзакций в ферму восстановления в Azure:SQL Server log shipping with Distributed File System Replication (DFSR) is used to copy database backups and transaction logs to the recovery farm in Azure:

  • DFSR переносит журналы из рабочей среды в среду восстановления. В глобальной сети DFSR намного эффективнее, чем доставка журналов непосредственно на вспомогательный сервер в Azure.DFSR transfers logs from the production environment to the recovery environment. In a WAN scenario, DFSR is more efficient than shipping the logs directly to the secondary server in Azure.

  • Журналы воспроизводятся на сервере SQL Server в среде восстановления Azure.Logs are replayed to the SQL Server in the recovery environment in Azure.

  • Базы данных контента SharePoint с доставкой журналов присоединяются к среде только после восстановления.You don't attach log-shipped SharePoint content databases in the recovery environment until a recovery exercise is performed.

Чтобы восстановить ферму, выполните следующие действия.Perform the following steps to recover the farm:

  1. Остановите доставку журналов.Stop log shipping.

  2. Остановите прием трафика основной фермы.Stop accepting traffic to the primary farm.

  3. Воспроизведите журналы транзакций.Replay the final transaction logs.

  4. Присоедините базу данных контента к ферме.Attach the content databases to the farm.

  5. Восстановите приложения-службы из служб реплицированных баз данных.Restore service applications from the replicated services databases.

  6. Измените записи системы доменных имен (DNS), чтобы они указывали на ферму восстановления.Update Domain Name System (DNS) records to point to the recovery farm.

  7. Запустите полный обход.Start a full crawl.

Рекомендуем регулярно тренироваться выполнять эти действия и документировать их, чтобы обеспечить безотказное восстановление в случае настоящей аварии. Присоединение баз данных контента и восстановление приложений-служб могут занять некоторое время и обычно требуют настраивать некоторые параметры вручную.We recommend that you rehearse these steps regularly and document them to help ensure that your live recovery runs smoothly. Attaching content databases and restoring service applications can take some time and typically involves some manual configuration.

После восстановления это решение предоставляет элементы, перечисленные в следующей таблице.After a recovery is performed, this solution provides the items listed in the following table.

Таблица. Цели восстановления решенияTable: Solution recovery objectives

ЭлементItem ОписаниеDescription
Сайты и контентSites and content
Сайты и контент доступны в среде восстановления.Sites and content are available in the recovery environment.
Новый экземпляр поискаA new instance of search
В этом решении горячего резервирования поиск не восстанавливается из соответствующих баз данных. Компоненты поиска в ферме восстановления по мере возможности настраиваются аналогично рабочей ферме. После восстановления сайтов и контента запускается полный обход для восстановления индекса поиска. Чтобы сделать сайты и контент доступными, вам не придется дожидаться завершения обхода.In this warm standby solution, search is not restored from search databases. Search components in the recovery farm are configured as similarly as possible to the production farm. After the sites and content are restored, a full crawl is started to rebuild the search index. You do not need to wait for the crawl to complete to make the sites and content available.
СлужбыServices
Службы, которые хранят данные в базах данных, восстанавливаются из баз данных с доставкой журналов. Службы, которые не хранят данные в базах данных, просто запускаются.Services that store data in databases are restored from the log-shipped databases. Services that do not store data in databases are simply started.
Не все службы с базами данных требуют восстановления. Перечисленные ниже службы не требуют восстановления, и их можно запустить после отработки отказа.Not all services with databases need to be restored. The following services do not need to be restored from databases and can simply be started after failover:
Приложение-служба сбора данных об использовании и работоспособностиUsage and Health Data Collection
Служба состоянийState service
Служба автоматизации WordWord automation
Любая другая служба, которая не использует базу данныхAny other service that doesn't use a database

Вы можете сотрудничать со службами консультации Майкрософт (MCS) или партнерами, чтобы выполнять более сложные задачи восстановления. Эти задачи представлены в следующей статье.You can work with Microsoft Consulting Services (MCS) or a partner to address more-complex recovery objectives. These are summarized in the following table.

Таблица. Другие задачи, которые могут выполнить MCS или партнерыTable: Other items that can be addressed by MCS or a partner

ЭлементItem ОписаниеDescription
Синхронизация решений пользовательской фермыSynchronizing custom farm solutions
В идеальном случае конфигурация фермы восстановления идентична конфигурации рабочей фермы. Консультант или партнер может помочь вам определить, реплицируются ли решения пользовательской фермы и налажен ли процесс синхронизации двух сред.Ideally, the recovery farm configuration is identical to the production farm. You can work with a consultant or partner to evaluate whether custom farm solutions are replicated and whether the process is in place for keeping the two environments synchronized.
Подключения к локальным источникам данныхConnections to data sources on-premises
Реплицировать подключения к серверным системам данных, например резервным контроллерам доменов (BDC) и источникам контента поиска, может быть нецелесообразно.It might not be practical to replicate connections to back-end data systems, such as backup domain controller (BDC) connections and search content sources.
Сценарии восстановления поискаSearch restore scenarios
Так как корпоративные среды поиска обычно являются довольно уникальными и сложными, восстановление поиска из баз данных требует больших инвестиций. Консультант или партнер может помочь вам определить и реализовать сценарии восстановления поиска, которые могут требоваться вашей организации.Because enterprise search deployments tend to be fairly unique and complex, restoring search from databases requires a greater investment. You can work with a consultant or partner to identify and implement search restore scenarios that your organization might require.

В этой статье предполагается, что локальная ферма уже разработана и развернута.The guidance provided in this article assumes that the on-premises farm is already designed and deployed.

Подробная архитектураDetailed architecture

В идеальном случае конфигурация фермы восстановления в Azure идентична конфигурации локальной рабочей фермы, включая:Ideally, the recovery farm configuration in Azure is identical to the production farm on-premises, including the following:

  • одинаковое представление ролей серверов;The same representation of server roles

  • одинаковую конфигурацию настроек;The same configuration of customizations

  • одинаковую конфигурацию компонентов поиска.The same configuration of search components

Среда в Azure может быть уменьшенной версией рабочей фермы. Если вы планируете развернуть ферму восстановления после отработки отказа, все роли серверов должны быть представлены изначально.The environment in Azure can be a smaller version of the production farm. If you plan to scale out the recovery farm after failover, it's important that each type of server role be initially represented.

Некоторые конфигурации может быть нецелесообразно реплицировать в среде отработки отказа. Испытайте процедуры и среду отработки отказа, чтобы убедиться, что ферма отработки отказа предоставляет ожидаемый уровень обслуживания.Some configurations might not be practical to replicate in the failover environment. Be sure to test the failover procedures and environment to help ensure that the failover farm provides the expected service level.

Это решение не требует определенной топологии фермы SharePoint. Фокус этого решения использование Azure для фермы отработки отказа и реализация доставки журналов и DFSR между двумя средами.This solution doesn't prescribe a specific topology for a SharePoint farm. The focus of this solution is to use Azure for the failover farm and to implement log shipping and DFSR between the two environments.

Среды горячего резервированияWarm standby environments

В среде горячего резервирования запущены все виртуальные машины среды Azure. Среда готова к отработке пробного или настоящего отказа.In a warm standby environment, all virtual machines in the Azure environment are running. The environment is ready for a failover exercise or event.

На следующем рисунке показано решение аварийного восстановления из локальной фермы SharePoint в ферму Azure, которая настроена как среда горячего резервирования.The following figure illustrates a disaster recovery solution from an on-premises SharePoint farm to an Azure-based SharePoint farm that is configured as a warm standby environment.

Рисунок. Топология и основные элементы рабочей фермы и фермы восстановления с горячим резервированиемFigure: Topology and key elements of a production farm and a warm standby recovery farm

Топология фермы SharePoint и фермы восстановления с "горячим" резервированием

На этой схеме:In this diagram:

  • показаны две среды: локальная ферма SharePoint и ферма горячего резервирования в Azure;Two environments are illustrated side by side: the on-premises SharePoint farm and the warm standby farm in Azure.

  • Каждая среда содержит общий файловый ресурс.Each environment includes a file share.

  • каждая ферма состоит из четырех уровней. Для обеспечения высокой доступности каждый уровень включает два сервера или две виртуальные машины, которые одинаково настроены для определенной роли, например интерфейсных служб, службы распределенного кэша, внутренних служб или баз данных. На этой схеме конкретные компоненты не имеют значения. Две фермы настроены одинаково;Each farm includes four tiers. To achieve high availability, each tier includes two servers or virtual machines that are configured identically for a specific role, such as front-end services, distributed cache, back-end services, and databases. It isn't important in this illustration to call out specific components. The two farms are configured identically.

  • четвертый уровень — это уровень баз данных. Доставка журналов используется для копирования журналов со вспомогательного сервера баз данных в локальной среде на общий файловый ресурс в той же среде;The fourth tier is the database tier. Log shipping is used to copy logs from the secondary database server in the on-premises environment to the file share in the same environment.

  • DFSR копирует файлы из общего файлового ресурса локальной среды на общий файловый ресурс среды Azure;DFSR copies files from the file share in the on-premises environment to the file share in the Azure environment.

  • доставка журналов воспроизводит журналы из общего файлового ресурса в среде Azure для основной реплики в группе доступности SQL Server AlwaysOn в среде восстановления.Log shipping replays the logs from the file share in the Azure environment to the primary replica in the SQL Server AlwaysOn availability group in the recovery environment.

Среды холодного резервированияCold standby environments

В среде холодного резервирования большинство виртуальных машин SharePoint можно отключить (рекомендуем время от времени запускать виртуальные машины, например каждые две недели или раз в месяц, чтобы они синхронизировались с доменом). Чтобы обеспечить непрерывную работу доставки журналов и DFSR, в среде восстановления Azure должны быть всегда запущены следующие виртуальные машины:In a cold standby environment, most of the SharePoint farm virtual machines can be shut down. (We recommend occasionally starting the virtual machines, such as every two weeks or once a month, so that each virtual machine can sync with the domain.) The following virtual machines in the Azure recovery environment must remain running to help ensure continuous operations of log shipping and DFSR:

  • Общий файловый ресурсThe file share

  • Основной сервер баз данныхThe primary database server

  • Как минимум одна виртуальная машина, на которой запущены доменные службы Windows Server Active Directory и DNSAt least one virtual machine running Windows Server Active Directory Domain Services and DNS

На приведенном ниже рисунке показана среда отработки отказа Azure, в которой запущены виртуальные машины файловых ресурсов и виртуальная машина базы данных SharePoint. Все остальные виртуальные машины SharePoint остановлены. Виртуальная машина с Windows Server Active Directory и DNS не показана.The following figure shows an Azure failover environment in which the file share virtual machine and the primary SharePoint database virtual machine are running. All other SharePoint virtual machines are stopped. The virtual machine that is running Windows Server Active Directory and DNS is not shown.

Рисунок. Виртуальные машины, запущенные в ферме восстановления с холодным резервированиемFigure: Cold standby recovery farm with running virtual machines

Элементы решения холодного резервирования SharePoint в Azure

После отработки отказа в среде с холодным резервированием запускаются все виртуальные машины и должен быть настроен метод обеспечения высокой доступности серверов баз данных, например группы доступности SQL Server AlwaysOn.After failover to a cold standby environment, all virtual machines are started, and the method to achieve high availability of the database servers must be configured, such as SQL Server AlwaysOn availability groups.

Если реализовано несколько групп хранения (базы данных распределены между несколькими группами высокой доступности SQL Server), должна быть запущена основная база данных для каждой группы хранения, чтобы получить журналы, связанные с соответствующей группой хранения.If multiple storage groups are implemented (databases are spread across more than one SQL Server high availability set), the primary database for each storage group must be running to accept the logs associated with its storage group.

Знания и опытSkills and experience

В этом решении аварийного восстановления используется несколько технологий. Чтобы обеспечить надлежащую работу этих технологий, необходимо правильно установить и настроить каждый компонент среды Azure и локальной среды. Специалисту или команде специалистов, которые будут настраивать это решение, рекомендуется иметь богатые знания и навыки работы с технологиям, описанными в следующих статьях:Multiple technologies are used in this disaster recovery solution. To help ensure that these technologies interact as expected, each component in the on-premises and Azure environment must be installed and configured correctly. We recommend that the person or team who sets up this solution have a strong working knowledge of and hands-on skills with the technologies described in the following articles:

Кроме того, рекомендуются навыки написания сценариев, которые помогут вам автоматизировать задачи, связанные с этими технологиями. Все задачи, описанные в этом решении, можно выполнить с помощью доступных пользовательских интерфейсов. Тем не менее, такой подход может занимать много времени и приводить к ошибкам, а также приносит непредсказуемые результаты.Finally, we recommend scripting skills that you can use to automate tasks associated with these technologies. It's possible to use the available user interfaces to complete all the tasks described in this solution. However, a manual approach can be time consuming and error prone and delivers inconsistent results.

Помимо Windows PowerShell, также доступны библиотеки Windows PowerShell для SQL Server, SharePoint Server и Azure. Не забывайте про запросы T-SQL, которые также помогут сократить время настройки и обслуживания среды аварийного восстановления.In addition to Windows PowerShell, there are also Windows PowerShell libraries for SQL Server, SharePoint Server, and Azure. Don't forget T-SQL, which can also help reduce the time to configure and maintain your disaster-recovery environment.

Схема аварийного восстановленияDisaster recovery roadmap

Визуальное представление схемы аварийного восстановления SharePoint.

Эта схема подразумевает, что рабочая ферма SharePoint Server 2013 уже развернута.This roadmap assumes that you already have a SharePoint Server 2013 farm deployed in production.

Таблица. Схема аварийного восстановленияTable: Roadmap for disaster recovery

ЭтапPhase ОписаниеDescription
Этап 1Phase 1
Разработка среды аварийного восстановления.Design the disaster recovery environment.
Этап 2Phase 2
Создание виртуальной сети Azure и VPN-подключения.Create the Azure virtual network and VPN connection.
Этап 3Phase 3
Развертывание Windows Active Directory и служб доменных имен в виртуальной сети Azure.Deploy Windows Active Directory and Domain Name Services to the Azure virtual network.
Этап 4Phase 4
Развертывание фермы восстановления SharePoint в Azure.Deploy the SharePoint recovery farm in Azure.
Этап 5Phase 5
Настройка DFSR между фермами.Set up DFSR between the farms.
Этап 6Phase 6
Настройка доставки журналов в ферму восстановления.Set up log shipping to the recovery farm.
Этап 7Phase 7
Проверка решений для отработки отказа и восстановления. Она включает следующие процедуры и технологии:Validate failover and recovery solutions. This includes the following procedures and technologies:
остановка доставки журналов;Stop log shipping.
восстановление резервных копий;Restore the backups.
обход контента;Crawl content.
восстановление служб;Recover services.
управление записями DNS.Manage DNS records.

Этап 1. Разработка среды аварийного восстановленияPhase 1: Design the disaster recovery environment

Следуйте указаниям из статьи Архитектуры Microsoft Azure для SharePoint 2013, чтобы разработать среду аварийного восстановления, включая ферму восстановления SharePoint. Чтобы приступить к разработке, вы можете использовать иллюстрации из файла Visio Решение для аварийного восстановления SharePoint в Azure. Рекомендуем полностью разработать среду, прежде чем приступать к работе в среде Azure.Use the guidance in Microsoft Azure Architectures for SharePoint 2013 to design the disaster-recovery environment, including the SharePoint recovery farm. You can use the graphics in theSharePoint Disaster Recovery Solution in Azure Visio file to start the design process. We recommend that you design the entire environment before beginning any work in the Azure environment.

Выполнив указания по разработке виртуальной сети, VPN-подключения, Active Directory и фермы SharePoint, приведенные в статье Архитектуры Microsoft Azure для SharePoint 2013, также необходимо добавить роль файлового ресурса в среду Azure.In addition to the guidance provided in Microsoft Azure Architectures for SharePoint 2013 for designing the virtual network, VPN connection, Active Directory, and SharePoint farm, be sure to add a file share role to the Azure environment.

Для поддержки доставки журналов в решении аварийного восстановления в подсеть, содержащую роли баз данных, добавлена виртуальная машина файлового ресурса. Файловый ресурс также выполняет роль третьего узла большинства узлов для группы доступности SQL Server AlwaysOn. Эта конфигурация рекомендуется для стандартной фермы SharePoint, которая использует группы доступности SQL Server AlwaysOn.To support log shipping in a disaster-recovery solution, a file share virtual machine is added to the subnet where the database roles reside. The file share also serves as the third node of a Node Majority for the SQL Server AlwaysOn availability group. This is the recommended configuration for a standard SharePoint farm that uses SQL Server AlwaysOn availability groups.

Примечание

Важно изучить необходимые условия для участия базы данных в группе доступности SQL Server AlwaysOn. Дополнительные сведения см. в статье Предварительные требования, ограничения и рекомендации по использованию групп доступности AlwaysOn.It is important to review the prerequisites for a database to participate in a SQL Server AlwaysOn availability group. For more information, see Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups.

Рисунок. Расположение файлового сервера, используемого решением для аварийного восстановленияFigure: Placement of a file server used for a disaster recovery solution

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

На этой схеме в подсеть в Azure, содержащую роли серверов баз данных, добавлена виртуальная машина файлового ресурса. Не добавляйте эту виртуальную машину к группе доступности с другими ролями серверов, например ролей SQL Server.In this diagram, a file share virtual machine is added to the same subnet in Azure that contains the database server roles. Do not add the file share virtual machine to an availability set with other server roles, such as the SQL Server roles.

Если вас интересует высокая доступность журналов, вы можете применить другой подход резервное копирование и восстановление SQL Server с помощью служб хранилища BLOB-объектов Azure. Это новая функция Azure, которая сохраняет журналы непосредственно по URL-адресу хранилища BLOB-объектов. Это решение не включает указания по использованию этой функции.If you are concerned about the high availability of the logs, consider taking a different approach by using SQL Server backup and restore with Azure Blob Storage Service. This is a new feature in Azure that saves logs directly to a blob storage URL. This solution does not include guidance about using this feature.

При разработке фермы восстановления помните, что успешная среда аварийного восстановления точно отражает рабочую ферму, которую нужно восстановить. Размер фермы восстановления не самая важная составляющая разработки, развертывания и тестирования фермы восстановления. Масштабы ферм в разных организациях отличаются и зависят от бизнес-требований. Вы можете использовать уменьшенную ферму во время короткого отключения питания или до тех пор, пока для достижения нужных производительности и емкости не потребуется масштабирование фермы.When you design the recovery farm, keep in mind that a successful disaster recovery environment accurately reflects the production farm that you want to recover. The size of the recovery farm is not the most important thing in the recovery farm's design, deployment, and testing. Farm scale varies from organization to organization based on business requirements. It might be possible to use a scaled-down farm for a short outage or until performance and capacity demands require you to scale the farm.

По мере возможности настройте ферму восстановления идентично рабочей ферме, чтобы она соответствовала требованиям соглашения об уровне обслуживания (SLA) и предоставляла функции, необходимые для поддержки вашего предприятия. При разработке решения для аварийного восстановления также следует рассмотреть процесс управления изменениями для рабочей среды. Рекомендуем расширить процесс управления изменениями в среду восстановления, обновляя среду восстановления с теми же интервалами, что и рабочую среду. В ходе процесса управления изменениями рекомендуем вести подробный учет конфигурации фермы, приложений и пользователей.Configure the recovery farm as identically as possible to the production farm so that it meets your service level agreement (SLA) requirements and provides the functionality that you need to support your business. When you design the disaster recovery environment, also look at your change management process for your production environment. We recommend that you extend the change management process to the recovery environment by updating the recovery environment at the same interval as the production environment. As part of the change management process, we recommend maintaining a detailed inventory of your farm configuration, applications, and users.

Этап 2. Создание виртуальной сети Azure и VPN-подключенияPhase 2: Create the Azure virtual network and VPN connection

В статье Подключение локальной сети к виртуальной сети Microsoft Azure показано, как планировать и развертывать виртуальную сеть Azure, а также создать VPN-подключение. Следуйте указаниям из этой статьи, чтобы выполнить следующие действия:Connect an on-premises network to a Microsoft Azure virtual network shows you how to plan and deploy the virtual network in Azure and how to create the VPN connection. Follow the guidance in the topic to complete the following procedures:

  • Планирование пространства частных IP-адресов Виртуальная сеть.Plan the private IP address space of the Virtual Network.

  • Планирование изменений инфраструктуры маршрутизации для Виртуальная сеть.Plan the routing infrastructure changes for the Virtual Network.

  • Планирование правил брандмауэра для входящего и исходящего трафика на локальном устройстве VPN.Plan firewall rules for traffic to and from the on-premises VPN device.

  • Создание распределенной виртуальной сети в Azure.Create the cross-premises virtual network in Azure.

  • Настройка маршрутизации между локальной сетью и Виртуальная сеть.Configure routing between your on-premises network and the Virtual Network.

Этап 3. Развертывание Active Directory и служб доменных имен в виртуальной сети AzurePhase 3: Deploy Active Directory and Domain Name Services to the Azure virtual network

Этот этап включает развертывание Windows Server Active Directory и DNS в Виртуальная сеть в гибридном сценарии, как описано в статье Архитектуры Microsoft Azure для SharePoint 2013 и показано на следующем рисунке:This phase includes deploying both Windows Server Active Directory and DNS to the Virtual Network in a hybrid scenario as described in Microsoft Azure Architectures for SharePoint 2013 and as illustrated in the following figure.

Рисунок. Гибридная конфигурация домена Active DirectoryFigure: Hybrid Active Directory domain configuration

Две виртуальные машины, развернутые в виртуальной сети Azure и подсети фермы SharePoint — это реплики контроллеров домена и DNS-серверы

На этом рисунке в одной подсети развертываются две виртуальные машины. На каждой из этих виртуальных машин размещаются две роли: Active Directory и DNS.In the illustration, two virtual machines are deployed to the same subnet. These virtual machines are each hosting two roles: Active Directory and DNS.

Перед развертыванием Active Directory в Azure прочитайте руководства по развертыванию Windows Server Active Directory на виртуальных машинах Azure. Эти указания помогут вам определить требуются ли для вашего решения другие параметры конфигурации.Before deploying Active Directory in Azure, read Guidelines for Deploying Windows Server Active Directory on Azure Virtual Machines. These guidelines help you determine whether you need a different architecture or different configuration settings for your solution.

Подробные указания по настройке контроллера домена в Azure см. в статье Установка реплики контроллера домена Active Directory в виртуальных сетях Azure.For detailed guidance on setting up a domain controller in Azure, see Install a Replica Active Directory Domain Controller in Azure Virtual Networks.

До этого этапа вы не развертывали виртуальные машины в Виртуальная сеть. Скорее всего, виртуальные машины для размещения Active Directory и DNS не самые большие виртуальные машины, необходимые для этого решения. Прежде чем развертывать эти виртуальные машины, создайте самую большую виртуальную машину, которую планируется использовать для Виртуальная сеть. Это поможет обеспечить, что решение попадет на тег Azure, в котором разрешается самый большой размер, который вам понадобится. В данный момент настраивать эту виртуальную машину не требуется. Просто создайте ее и приступайте к развертыванию. Если это не сделать, вы можете столкнуться с ограничением при попытке создать виртуальные машины большего размера. На момент написания данной статьи эта проблема актуальнаBefore this phase, you didn't deploy virtual machines to the Virtual Network. The virtual machines for hosting Active Directory and DNS are likely not the largest virtual machines you need for the solution. Before you deploy these virtual machines, first create the largest virtual machine that you plan to use in your Virtual Network. This helps ensure that your solution lands on a tag in Azure that allows the largest size you need. You do not need to configure this virtual machine at this time. Simply create it, and set it aside. If you do not do this, you might run into a limitation when you try to create larger virtual machines later, which was an issue at the time this article was written.

Этап 4. Развертывание фермы восстановления SharePoint в AzurePhase 4: Deploy the SharePoint recovery farm in Azure

Разверните ферму SharePoint в своей виртуальной сети в соответствии с проектными планами. Рекомендуем ознакомиться со статьей Планирование для SharePoint 2013 в службах инфраструктуры Azure перед развертыванием ролей SharePoint в Azure.Deploy the SharePoint farm in your Virtual Network according to your design plans. It might be helpful to review Planning for SharePoint 2013 on Azure Infrastructure Services before you deploy SharePoint roles in Azure.

Ниже приводятся рекомендации, которые помогли нам при создании нашей экспериментальной среды:Consider the following practices that we learned by building our proof of concept environment:

  • Создавайте виртуальные машины с помощью портала Azure или PowerShell.Create virtual machines by using the Azure portal or PowerShell.

  • Azure и Hyper-V не поддерживают динамическую память. Убедитесь, что это учитывается в ваших планах производительности и емкости.Azure and Hyper-V do not support dynamic memory. Be sure this is factored into your performance and capacity plans.

  • Перезагружайте виртуальные машины через интерфейс Azure, а не с экрана входа. Интерфейс Azure более удобен и предсказуем.Restart virtual machines through the Azure interface, not from the virtual machine logon itself. Using the Azure interface works better and is more predictable.

  • Если вам нужно завершить работу виртуальной машины в целях снижения затрат, используйте интерфейс Azure. Если завершить работу на экране входа виртуальной машины, проблемы начнут накапливаться.If you want to shut down a virtual machine to save costs, use the Azure interface. If you shut down from the virtual machine logon, charges continue to accrue.

  • Используйте соглашение об именовании для виртуальных машин.Use a naming convention for the virtual machines.

  • Обращайте внимание на расположение центра обработки, в котором развертываются виртуальные машины.Pay attention to which datacenter location the virtual machines are being deployed.

  • Функция автоматического масштабирования в Azure не поддерживается для ролей SharePoint.The automatic scaling feature in Azure is not supported for SharePoint roles.

  • Не настраивайте элементы фермы, которые будут восстановлены, например семейства веб-сайтов.Do not configure items in the farm that will be restored, such as site collections.

Этап 5. Настройка DFSR между фермамиPhase 5: Set up DFSR between the farms

Чтобы настроить репликацию с помощью DFSR, используйте оснастку управления DNS. Тем не менее, перед настройкой DFSR необходимо войти на файловый сервер Azure и локальный файловый сервер, а затем включить службу в Windows.To set up file replication by using DFSR, use the DNS Management snap-in. However, before the DFSR setup, log on to your on-premises file server and Azure file server and enable the service in Windows.

На панели мониторинга диспетчера серверов выполните следующие действия.From the Server Manager Dashboard, complete the following steps:

  • Настройте локальный сервер.Configure the local server.

  • Запустите мастер добавления ролей и компонентов.Start the Add Roles and Features Wizard.

  • Откройте узел Файловые службы и службы хранилища.Open the File and Storage Services node.

  • Выберите пункты Пространства имен DFS и Репликация DFS.Select DFS Namespaces and DFS replication.

  • Нажмите кнопку Далее, чтобы завершить работу мастера.Click Next to finish the wizard steps.

В приведенной ниже таблице представлены ссылки на справочные статьи и сообщения блогов, посвященные DFSR.The following table provides links to DFSR reference articles and blog posts.

Таблица. Справочные статьи, посвященные DFSRTable: Reference articles for DFSR

TitleTitle ОписаниеDescription
РепликацияReplication
Статья по управлению DFS на сайте TechNet, включающая ссылки для репликацииDFS Management TechNet topic with links for replication
Практические советы по репликации DFSDFS Replication: Survival Guide
Вики-сайт со ссылками на сведения о DFSWiki with links to DFS information
Репликация DFS. Вопросы и ответыDFS Replication: Frequently Asked Questions
Статья о репликации DFS на сайте TechNetDFS Replication TechNet topic
Блог Хосе Баррето (Jose Barreto)Jose Barreto's Blog
Блог главного руководителя проекта из группы файловых серверов МайкрософтBlog written by a Principal Program Manager on the File Server team at Microsoft
Блог группы Майкрософт, ответственной за хранениеThe Storage Team at Microsoft - File Cabinet Blog
Блог, посвященный файловым службам и функциям хранения в Windows ServerBlog about file services and storage features in Windows Server

Этап 6. Настройка доставки журналов в ферму восстановленияPhase 6: Set up log shipping to the recovery farm

Доставка журналов ключевой компонент настройки аварийного восстановления в этой среде. Вы можете использовать доставку журналов, чтобы автоматически отправлять файлы журналов транзакций из основной базы данных во вспомогательный экземпляр сервера баз данных. Сведения о настройке доставки журналов см. в статье Configure log shipping in SharePoint 2013.Log shipping is the critical component for setting up disaster recovery in this environment. You can use log shipping to automatically send transaction log files for databases from a primary database server instance to a secondary database server instance. To set up log shipping, see Configure log shipping in SharePoint 2013.

Важно!

Поддержка доставки журналов в SharePoint Server ограничена определенными базами данных. Дополнительные сведения см. в статье Поддерживаемые варианты обеспечения высокого уровня доступности и аварийного восстановления для баз данных SharePoint (SharePoint 2013).Log shipping support in SharePoint Server is limited to certain databases. For more information, see Supported high availability and disaster recovery options for SharePoint databases (SharePoint 2013).

Этап 7. Проверка отработки отказа и восстановленияPhase 7: Validate failover and recovery

Цель последнего этапа — проверить работу решения для восстановления. Для этого создайте сбой, который приводит к отключению рабочей фермы и запуску фермы восстановления. Вы можете запустить сценарий отработки отказа вручную или с помощью сценариев.The goal of this final phase is to verify that the disaster recovery solution works as planned. To do this, create a failover event that shuts down the production farm and starts up the recovery farm as a replacement. You can start a failover scenario manually or by using scripts.

Для начала необходимо остановить входящие запросы пользователей к службам или контенту фермы. Это можно сделать, отключив записи DNS или отключив интерфейсные веб-серверы. После "сбоя" фермы вы можете выполнить переход на ферму восстановления.The first step is to stop incoming user requests for farm services or content. You can do this by disabling DNS entries or by shutting down the front-end web servers. After the farm is "down," you can fail over to the recovery farm.

Остановка доставки журналовStop log shipping

Перед восстановлением фермы необходимо остановить доставку журналов. Сначала сделайте это на вспомогательном сервере в Azure, а затем — на основном локальном сервере. Используйте приведенный ниже сценарий, чтобы остановить доставку журналов сначала на вспомогательном сервере, а затем — на основном. Имена баз данных в сценарии могут отличаться от имен в вашей среде.You must stop log shipping before farm recovery. Stop log shipping on the secondary server in Azure first, and then stop it on the primary server on-premises. Use the following script to stop log shipping on the secondary server first and then on the primary server. The database names in the script might be different, depending on your environment.

-- This script removes log shipping from the server.
-- Commands must be executed on the secondary server first and then on the primary server.

SET NOCOUNT ON
DECLARE  @PriDB nvarchar(max)
,@SecDB nvarchar(250)
,@PriSrv nvarchar(250)
,@SecSrv nvarchar(250)

Set @PriDB= ''
SET @PriDB = UPPER(@PriDB)
SET @PriDB = REPLACE(@PriDB, ' ', '')
SET @PriDB = '''' + REPLACE(@PriDB, ',', ''', ''') + ''''

Set @SecDB = @PriDB

Exec ( 'Select  ''exec master..sp_delete_log_shipping_secondary_database '' + '''''''' + prm.primary_database +  ''''''''   
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec  ON  prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')

Exec ( 'Select  ''exec master..sp_delete_log_shipping_primary_secondary '' + '''''''' + prm.Primary_Database + '''''', '''''' + sec.Secondary_Server + '''''', '''''' + sec.Secondary_database + ''''''''   
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec  ON  prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')

Exec ( 'Select  ''exec master..sp_delete_log_shipping_primary_database '' + '''''''' + prm.primary_database +  ''''''''   
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec  ON  prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')

Exec ( 'Select  ''exec master..sp_delete_log_shipping_secondary_primary '' + '''''''' + prm.primary_server + '''''', '''''' + prm.primary_database +  ''''''''   
from msdb.dbo.log_shipping_monitor_primary prm INNER JOIN msdb.dbo.log_shipping_primary_secondaries sec  ON  prm.primary_database=sec.secondary_database
where prm.primary_database in ( ' + @PriDB + ' )')

Восстановление резервных копийRestore the backups

Восстанавливать резервные копии нужно в порядке их создания. Прежде чем восстанавливать резервную копию определенного журнала транзакций, необходимо восстановить следующие резервные копии без отката неподтвержденных транзакций (то есть с использованием WITH NORECOVERY):Backups must be restored in the order in which they were created. Before you can restore a particular transaction log backup, you must first restore the following previous backups without rolling back uncommitted transactions (that is, by using WITH NORECOVERY):

  • Полное резервное копирование баз данных и последнее разностное резервное копирование восстановите эти резервные копии (если они есть), созданные перед резервным копированием определенного журнала транзакций. До создания последней полной или разностной резервной копии базы данных в ней использовалась модель полного восстановления или модель восстановления с неполным протоколированием.The full database backup and the last differential backup - Restore these backups, if any exist, taken before the particular transaction log backup. Before the most recent full or differential database backup was created, the database was using the full recovery model or bulk-logged recovery model.

  • Все резервные копии журналов транзакций восстановите все резервные копии журналов транзакций, созданные после полного резервного копирования базы данных или разностного резервного копирования (если восстанавливалась эта копия) и до резервного копирования определенного журнала транзакций. Резервные копии журналов необходимо применять в порядке их создания, не пропуская журналы.All transaction log backups - Restore any transaction log backups taken after the full database backup or the differential backup (if you restore one) and before the particular transaction log backup. Log backups must be applied in the sequence in which they were created, without any gaps in the log chain.

Чтобы восстановить базу данных контента на вспомогательном сервере для отображения сайтов, удалите все подключения баз данных перед восстановлением. Чтобы восстановить базу данных, используйте следующую инструкцию SQL:To recover the content database on the secondary server so that the sites render, remove all database connections before recovery. To restore the database, run the following SQL statement.

restore database WSS_Content with recovery

Важно!

Если вы используете T-SQL в явной форме, укажите параметр WITH NORECOVERY или WITH RECOVERY в каждом операторе RESTORE, чтобы избежать неоднозначности это очень важно при написании сценариев. После восстановления полных и разностных резервных копий можно восстановить журналы транзакций в SQL Server Management Studio. Кроме того, так как доставка журналов уже остановлена, база данных контента находится в состоянии ожидания, которое нужно изменить на полный доступ.When you use T-SQL explicitly, specify either WITH NORECOVERY or WITH RECOVERY in every RESTORE statement to eliminate ambiguity—this is very important when writing scripts. After the full and differential backups are restored, the transaction logs can be restored in SQL Server Management Studio. Also, because log shipping is already stopped, the content database is in a standby state, so you must change the state to full access.

В SQL Server Management Studio щелкните базу данных WSS_Content правой кнопкой мыши, наведите указатель на пункт Задачи > Восстановить и выберите Журнал транзакций (если вы не восстанавливали полную резервную копию, эта команда недоступна). Дополнительные сведения см. в статьеВосстановление резервной копии журнала транзакций (SQL Server).In SQL Server Management Studio, right-click the WSS_Content database, point to Tasks > Restore, and then click Transaction Log (if you have not restored the full backup, this is not available). For more information, seeRestore a Transaction Log Backup (SQL Server).

Обход источника контентаCrawl the content source

Чтобы восстановить службу поиска, необходимо запустить полный обход для каждого источника контента. Обратите внимание, что потеряются некоторые сведения аналитики из локальной фермы, например рекомендации поиска. Прежде чем запускать полный обход, используйте командлет Windows PowerShell Restore-SPEnterpriseSearchServiceApplication и укажите реплицированную базу данных администрирования поиска с доставкой журналов, Search_Service__DB_. Этот командлет задает конфигурацию, схему, управляемые свойства и правила поиска, а также создает набор других компонентов по умолчанию.You must start a full crawl for each content source to restore the Search Service. Note that you lose some analytics information from the on-premises farm, such as search recommendations. Before you start the full crawls, 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.

Чтобы запустить полный обход, выполните следующие действия.To start a full crawl, complete the following steps:

  1. В Центр администрирования SharePoint 2013 откройте раздел Управление приложениями > Приложения-службы > Управление приложениями-службами, а затем щелкните приложение-службу поиска, обход которого нужно выполнить.In the SharePoint 2013 Central Administration, go to Application Management > Service Applications > Manage service applications, and then click the Search Service application that you want to crawl.

  2. На странице Администрирование поиска нажмите Источники контента, наведите указатель на нужный источник контента, щелкните стрелку и нажмите Начать полный обход.On the Search Administration page, click Content Sources, point to the content source that you want, click the arrow, and then click Start Full Crawl.

Восстановление служб фермыRecover farm services

В приведенной ниже таблице показано, как восстановить службы, в которых есть базы данных с доставкой журналов, службы, где есть базы данных, но не рекомендуется восстановление с доставкой журналов, и службы, в которых нет баз данных.The following table shows how to recover services that have log-shipped databases, the services that have databases but are not recommended to restore with log shipping, and the services that do not have databases.

Важно!

При восстановлении локальной базы данных SharePoint в среде Azure не восстанавливаются службы SharePoint, которые еще не установлены в Azure вручную.Restoring an on-premises SharePoint database into the Azure environment will not recover any SharePoint services that you did not already install in Azure manually.

Таблица. Справка по базам данных приложений-службTable: Service application database reference

Восстановление этих служб из баз данных с доставкой журналовRestore these services from log-shipped databases В этих службах есть базы данных, но их рекомендуется запускать без восстановления баз данныхThese services have databases, but we recommend that you start these services without restoring their databases Эти службы не хранят данные в базах данных. Запускайте их после отработки отказаThese services do not store data in databases; start these services after failover
Служба машинного переводаMachine Translation Service
Служба управляемых метаданныхManaged Metadata Service
Служба Secure StoreSecure Store Service
Служба профилей пользователей. (Поддерживаются только базы данных профилей и тегов. База данных синхронизации не поддерживается.)User Profile. (Only the Profile and Social Tagging databases are supported. The Synchronization database is not supported.)
Служба параметров подписки Microsoft SharePoint FoundationMicrosoft SharePoint Foundation Subscription Settings Service
Приложение-служба сбора данных об использовании и работоспособностиUsage and Health Data Collection
Служба состоянийState service
Служба автоматизации WordWord automation
Службы ExcelExcel Services
PerformancePoint ServicesPerformancePoint Services
Служба преобразования PowerPointPowerPoint Conversion
Служба графики VisioVisio Graphics Service
Служба управления работойWork Management

На следующем примере показано, как восстановить службу управляемых метаданных из базы данных.The following example shows how to restore the Managed Metadata service from a database.

В этом примере использует существующая база данныхManaged_Metadata_DB. Эта база данных использует доставку журналов, но на вспомогательной ферме нет активных приложений-служб, поэтому ее нужно подключить после установки приложения-службы.This uses the existing Managed_Metadata_DB database. This database is log shipped, but there is no active service application on the secondary farm, so it needs to be connected after the service application is in place.

Для начала используйте команду New-SPMetadataServiceApplication и укажите параметр DatabaseName с именем восстановленной базы данных.First, use New-SPMetadataServiceApplication, and specify the DatabaseName switch with the name of the restored database.

Затем настройте новое приложение-службу управляемых метаданных на вспомогательном сервере, указав следующие параметры:Next, configure the new Managed Metadata Service Application on the secondary server, as follows:

  • Имя: служба управляемых метаданныхName: Managed Metadata Service

  • Сервер базы данных: имя базы данных из доставленного журнала транзакцийDatabase server: The database name from the shipped transaction log

  • Имя базы данных:Managed_Metadata_DBDatabase name: Managed_Metadata_DB

  • Пул приложений: приложения-службы SharePointApplication pool: SharePoint Service Applications

Управление записями DNSManage DNS records

Необходимо вручную создать записи DNS, указывающие на ферму SharePoint.You must manually create DNS records to point to your SharePoint farm.

В большинстве случаев, когда имеется несколько интерфейсных веб-серверов, будет целесообразно воспользоваться функцией балансировки сетевой нагрузки в Windows Server 2012 или устройством балансировки нагрузки, чтобы распределять запросы между интерфейсными веб-серверами фермы. Балансировка сетевой нагрузки также может снизить риск, распределяя запросы на другие серверы в случае сбоя одного из интерфейсных веб-серверов.In most cases where you have multiple front-end web servers, it makes sense to take advantage of the Network Load Balancing feature in Windows Server 2012 or a hardware load balancer to distribute requests among the web-front-end servers in your farm. Network load balancing can also help reduce risk by distributing requests to the other servers if one of your web-front-end servers fails.

Как правило, при настройке балансировки сетевой нагрузки кластеру назначается один IP-адрес. Затем необходимо создать у поставщика DNS для вашей сети запись узла DNS, которая указывает на кластер (для нашего проекта мы поместили DNS-сервер в Azure для повышения отказоустойчивости в случае сбоя локального центра обработки данных). Например, вы можете создать в диспетчере DNS службы Active Directory запись DNS с именем http://sharepoint.contoso.com, которая указывает на IP-адрес кластера с балансировкой нагрузки.Typically, when you set up network load balancing, your cluster is assigned a single IP address. You then create a DNS host record in the DNS provider for your network that points to the cluster. (For this project, we put a DNS server in Azure for resiliency in case of an on-premises datacenter failure.) For instance, you can create a DNS record, in DNS Manager in Active Directory, for example, called http://sharepoint.contoso.com, that points to the IP address for your load-balanced cluster.

Для внешнего доступа к ферме SharePoint можно создать на внешнем DNS-сервере с URL-адресом, который клиенты используют в интрасети (например, http://sharepoint.contoso.com)), запись узла, указывающую на внешний IP-адрес в брандмауэре (в этом примере рекомендуем настроить разделенный DNS, чтобы внутренний DNS-сервер был полномочным сервером для домена contoso.com и направлял запросы непосредственно в кластер фермы SharePoint, а не на внешний DNS-сервер). Затем можно сопоставить внешний IP-адрес со внутренним IP-адресом локального кластера, чтобы клиенты находили нужные им ресурсы.For external access to your SharePoint farm, you can create a host record on an external DNS server with the same URL that clients use on your intranet (for example, http://sharepoint.contoso.com) that points to an external IP address in your firewall. (A best practice, using this example, is to set up split DNS so that the internal DNS server is authoritative for contoso.com and routes requests directly to the SharePoint farm cluster, rather than routing DNS requests to your external DNS server.) You can then map the external IP address to the internal IP address of your on-premises cluster so that clients find the resources they are looking for.

После этого может возникнуть один из описанных ниже сценариев аварийного восстановления.From here, you might run into a couple of different disaster-recovery scenarios:

Пример сценария. Локальная ферма SharePoint недоступна по причине сбоя оборудования в локальной ферме SharePoint. В этом случае после выполнения действий по отработке отказа в ферме Azure SharePoint вы можете настроить балансировку сетевой нагрузки на интерфейсных веб-серверах фермы SharePoint так же, как и на локальной ферме. Затем вы можете изменить запись узла у внутреннего поставщика DNS, чтобы она указывала на IP-адрес кластера фермы восстановления. Обратите внимание, что обновление кэшированных записей DNS в клиентах, чтобы они указывали на ферму восстановления, может занять некоторое время.Example scenario: The on-premises SharePoint farm is unavailable because of hardware failure in the on-premises SharePoint farm. In this case, after you have completed the steps for failover to the Azure SharePoint farm, you can configure network load balancing on the recovery SharePoint farm's web-front-end servers, the same way you did with the on-premises farm. You can then redirect the host record in your internal DNS provider to point to the recovery farm's cluster IP address. Note that it can take some time before cached DNS records on clients are refreshed and point to the recovery farm.

Пример сценария. Локальный центр обработки данных полностью потерян. Этот сценарий может возникнуть в результате стихийного бедствия, например пожара или наводнения. Скорее всего, в этом случае в предприятии есть вспомогательный центр обработки данных, размещенный в другом регионе, а также подсеть Azure с собственными службами каталогов и DNS. Как и в предыдущем сценарии, вы можете изменить свои внутренние и внешние записи DNS, чтобы они указывали на ферму SharePoint в Azure. Помните, что распространение записей DNS может занять некоторое время.Example scenario: The on-premises datacenter is lost completely. This scenario might occur due to a natural disaster, such as a fire or flood. In this case, for an enterprise, you would likely have a secondary datacenter hosted in another region as well as your Azure subnet that has its own directory services and DNS. As in the previous disaster scenario, you can redirect your internal and external DNS records to point to the Azure SharePoint farm. Again, take note that DNS-record propagation can take some time.

Если вы используете семейства веб-сайтов с именами на основе узлов, как рекомендуется в статье Архитектура и развертывание семейства сайтов с именем на основе узла в SharePoint Server, то в вашей ферме SharePoint может быть несколько семейств веб-сайтов, размещаемых в одном веб-приложении, с уникальными DNS-именами (например, http://sales.contoso.com и http://marketing.contoso.com)). В этом случае вы можете создать для каждого семейства веб-сайтов записи DNS, указывающие на IP-адрес кластера. Когда запросы достигают интерфейсных веб-серверов SharePoint, эти серверы выполняют маршрутизацию запросов в соответствующие семейства веб-сайтов.If you are using host-named site collections, as recommended in Host-named site collection architecture and deployment (SharePoint 2013), you might have several site collections hosted by the same web application in your SharePoint farm, with unique DNS names (for example, http://sales.contoso.com and http://marketing.contoso.com). In this case, you can create DNS records for each site collection that point to your cluster IP address. After a request reaches your SharePoint web-front-end servers, they handle routing each request to the appropriate site collection.

Экспериментальная среда МайкрософтMicrosoft proof-of-concept environment

Мы разработали и испытали экспериментальную среду для этого решения. Целями проекта были развертывание и восстановление фермы SharePoint, которая может встретиться в среде клиента. Мы сделали несколько предположений, не забывая, что ферма должна предоставлять все стандартные функции без дополнительной настройки. Топология разработана для высокой доступности с использованием рекомендаций от группы разработки и тестирования продуктов.We designed and tested a proof-of-concept environment for this solution. The design goal for our test environment was to deploy and recover a SharePoint farm that we might find in a customer environment. We made several assumptions, but we knew that the farm needed to provide all of the out-of-the-box functionality without any customizations. The topology was designed for high availability by using best practice guidance from the field and product group.

В следующей таблице описываются виртуальные машины Hyper-V, созданные и настроенные для локальной тестовой среды.The following table describes the Hyper-V virtual machines that we created and configured for the on-premises test environment.

Таблица. Виртуальные машины для локального тестированияTable: Virtual machines for on-premises test

Имя сервераServer name РольRole КонфигурацияConfiguration
DC1DC1
Контроллер домена с Active Directory.Domain controller with Active Directory.
Два процессораTwo processors
От 512 МБ до 4 ГБ ОЗУFrom 512 MB through 4 GB of RAM
1 жесткий диск объемом 127 ГБ1 x 127-GB hard disk
RRASRRAS
Сервер, на котором настроена роль службы маршрутизации и удаленного доступа (RRAS).Server configured with the Routing and Remote Access Service (RRAS) role.
Два процессораTwo processors
2-8 ГБ ОЗУ2-8 GB of RAM
1 жесткий диск объемом 127 ГБ1 x 127-GB hard disk
FS1FS1
Файловый сервер с общими папками для резервных копий и конечной точкой для DFSR.File server with shares for backups and an end point for DFSR.
Четыре процессораFour processors
2-12 ГБ ОЗУ2-12 GB of RAM
1 жесткий диск объемом 127 ГБ1 x 127-GB hard disk
1 жесткий диск объемом 1 ТБ (SAN)1 x 1-TB hard disk (SAN)
1 жесткий диск объемом 750 ГБ1 x 750-GB hard disk
SP-WFE1, SP-WFE2SP-WFE1, SP-WFE2
Интерфейсные веб-серверы.Front-end web servers.
Четыре процессораFour processors
16 ГБ ОЗУ16 GB of RAM
SP-APP1, SP-APP2, SP-APP3SP-APP1, SP-APP2, SP-APP3
Серверы приложенийApplication servers.
Четыре процессораFour processors
2-16 ГБ ОЗУ2-16 GB of RAM
SP-SQL-HA1, SP-SQL-HA2SP-SQL-HA1, SP-SQL-HA2
Серверы баз данных, на которых настроены группы доступности AlwaysOn SQL Server 2012, обеспечивающие высокую доступность. В этой конфигурации используются SP-SQL-HA1 и SP-SQL-HA2, основная и вспомогательная реплики.Database servers, configured with SQL Server 2012 AlwaysOn availability groups to provide high availability. This configuration uses SP-SQL-HA1 and SP-SQL-HA2 as the primary and secondary replicas.
Четыре процессораFour processors
2-16 ГБ ОЗУ2-16 GB of RAM

В следующей таблице описываются конфигурации дисков для виртуальных машин Hyper-V, которые мы создали и настроили для серверов приложений и интерфейсных веб-серверов в локальной тестовой среде.The following table describes drive configurations for the Hyper-V virtual machines that we created and configured for the front-end web and application servers for the on-premises test environment.

Таблица. Требования к дискам виртуальных машин для серверов приложений и интерфейсных веб-серверов в локальной тестовой средеTable: Virtual machine drive requirements for the Front End Web and Application servers for the on-premises test

Буква дискаDrive letter РазмерSize Имя каталогаDirectory name ПутьPath
CC
8080
Системный дискSystem drive
:\Program Files\Microsoft SQL Server\:\Program Files\Microsoft SQL Server\
EE
8080
Диск журналов (40 ГБ)Log drive (40 GB)
:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
FF
8080
Диск файла подкачки (36 ГБ)Page (36 GB)
:\Program Files\Microsoft SQL Server\MSSQL\DATA:\Program Files\Microsoft SQL Server\MSSQL\DATA

В следующей статье представлены конфигурации дисков для виртуальных машин Hyper-V, созданных и настроенных как локальные серверы баз данных. На странице Настройка компонента Database Engine откройте вкладку Каталоги данных, чтобы задать и подтвердить параметры, показанные в следующей таблице.The following table describes drive configurations for the Hyper-V virtual machines created and configured to serve as the on-premises database servers. On the Database Engine Configuration page, access the Data Directories tab to set and confirm the settings shown in the following table.

Таблица. Требования к диска виртуальных машин для сервера базы данных в локальной тестовой средеTable: Virtual machine drive requirements for the database server for the on-premises test

Буква дискаDrive letter РазмерSize Имя каталогаDirectory name ПутьPath
CC
8080
Корневой каталог данныхData root directory
:\Program Files\Microsoft SQL Server\:\Program Files\Microsoft SQL Server\
EE
500500
Каталог базы данных пользователейUser database directory
:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
FF
500500
Каталог журнала базы данных пользователейUser database log directory
:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
ГG
500500
Временный каталог БДTemp DB directory
:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
HH
500500
Временный каталог журнала БДTemp DB log directory
:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA

Настройка тестовой средыSetting up the test environment

В ходе разных этапов развертывания команда тестирования обычно работала сначала над локальной архитектурой, а затем над соответствующей средой Azure. То же самое обычно происходит в реальных сценариях, где внутренние рабочие фермы уже запущены. Еще важнее знать текущую рабочую нагрузку, емкость и типичную производительностью. Создав модель аварийного восстановления, соответствующую бизнес-требованиям, следует изменить размеры ее серверов для минимального уровня обслуживания. Как правило, в средах с холодным или горячим резервированием ферма восстановления меньше рабочей фермы. Когда ферма восстановления будет находиться в стабильном рабочем состоянии, ее можно будет разворачивать и сворачивать в соответствии с требованиями к рабочей нагрузке.During the different deployment phases, the test team typically worked on the on-premises architecture first and then on the corresponding Azure environment. This reflects the general real-world cases where in-house production farms are already running. What is even more important is that you should know the current production workload, capacity, and typical performance. In addition to building a disaster recovery model that can meet business requirements, you should size the recovery farm servers to deliver a minimum level of service. In a cold or warm standby environment, a recovery farm is typically smaller than a production farm. After the recovery farm is stable and in production, the farm can be scaled up and out to meet workload requirements.

Развертывание нашей тестовой среды выполнялось в три этапа:We deployed our test environment in the following three phases:

  • Настройка гибридной инфраструктурыSet up the hybrid infrastructure

  • Подготовка серверовProvision the servers

  • Развертывание ферм SharePointDeploy the SharePoint farms

Настройка гибридной инфраструктурыSet up the hybrid infrastructure

Этот этап включает настройку доменной среды для локальной фермы и фермы восстановления в Azure. Помимо обычных задач, связанных с настройкой Active Directory, команда тестирования реализовала решение для маршрутизации и VPN-соединение между двумя средами.This phase involved setting up a domain environment for the on-premises farm and for the recovery farm in Azure. In addition to the normal tasks associated with configuring Active Directory, the test team implemented a routing solution and a VPN connection between the two environments.

Подготовка серверовProvision the servers

Помимо серверов ферм, требовалось подготовить серверы для контроллеров доменов и настроить сервер для обработки RRAS и VPN типа "сеть-сеть". Для службы DFSR были подготовлены два файловых сервера, а для тестировщиков — несколько клиентских компьютеров.In addition to the farm servers, it was necessary to provision servers for the domain controllers and configure a server to handle RRAS as well as the site-to-site VPN. Two file servers were provisioned for the DFSR service, and several client computers were provisioned for testers.

Развертывание ферм SharePointDeploy the SharePoint farms

Развертывание ферм SharePoint выполнялось в два этапа, чтобы упростить стабилизацию среды и устранение неполадок в случае необходимости. На первом этапе каждая ферма была развернута на минимальном количестве серверов для каждого уровня топологии, обеспечивая необходимые функции.The SharePoint farms were deployed in two stages in order to simplify environment stabilization and troubleshooting, if required. During the first stage, each farm was deployed on the minimum number of servers for each tier of the topology to support the required functionality.

Мы создали серверы баз данных с установленным SQL Server, прежде чем создавать серверы SharePoint 2013. Так как это было новое развертывание, мы создали группы доступности перед развертыванием SharePoint. Мы создали три группы, следуя рекомендациям службы MCS.We created the database servers with SQL Server installed before creating the SharePoint 2013 servers. Because this was a new deployment, we created the availability groups before deploying SharePoint. We created three groups based on MCS best practice guidance.

Примечание

Создайте подстановочные базы данных, чтобы иметь возможность создать группы доступности перед установкой SharePoint. Дополнительные сведения см. в статье Настройка групп обеспечения доступности SQL Server 2012 AlwaysOn для SharePoint 2013.Create placeholder databases so that you can create availability groups before the SharePoint installation. For more information, see Configure SQL Server 2012 AlwaysOn Availability Groups for SharePoint 2013

Мы создали ферму и объединили дополнительные серверы в следующем порядке:We created the farm and joined additional servers in the following order:

  • Подготовка серверов SP-SQL-HA1 и SP-SQL-HA2.Provision SP-SQL-HA1 and SP-SQL-HA2.

  • Настройка AlwaysOn и создание трех групп доступности для фермы.Configure AlwaysOn and create the three availability groups for the farm.

  • Подготовка сервера SP-APP1 для размещения Центра администрирования.Provision SP-APP1 to host Central Administration.

  • Подготовка серверов SP-WFE1 и SP-WFE2 для размещения распределенного кэша.Provision SP-WFE1 and SP-WFE2 to host the distributed cache.

Мы использовали параметр командной строки skipRegisterAsDistributedCachehost при запуске программы psconfig.exe. Дополнительные сведения см. в статьеПланирование веб-каналов и службы распределенного кэша в SharePoint Server 2013.We used the skipRegisterAsDistributedCachehost parameter when we ran psconfig.exe at the command line. For more information, seePlan for feeds and the Distributed Cache service in SharePoint Server 2013.

В среде восстановления мы повторили следующие этапы:We repeated the following steps in the recovery environment:

  • Подготовка серверов AZ-SQL-HA1 и AZ-SQL-HA2.Provision AZ-SQL-HA1 and AZ-SQL-HA2.

  • Настройка AlwaysOn и создание трех групп доступности для фермы.Configure AlwaysOn and create the three availability groups for the farm.

  • Подготовка сервера AZ-APP1 для размещения Центра администрирования.Provision AZ-APP1 to host Central Administration.

  • Подготовка серверов AZ-WFE1 и AZ-WFE2 для размещения распределенного кэша.Provision AZ-WFE1 and AZ-WFE2 to host the distributed cache.

Настроив распределенный кэш и добавив тестовых пользователей и тестовый контент, мы приступили ко второму этапу развертывания. Для этого потребовалось развернуть уровни и настроить серверы ферм для поддержки топологии высокой доступности, описанной в архитектуре фермы.After we configured the distributed cache and added test users and test content, we started stage two of the deployment. This required scaling out the tiers and configuring the farm servers to support the high-availability topology described in the farm architecture.

В следующей таблице описываются виртуальные машины, подсети и группы доступности, настроенные для фермы восстановления.The following table describes the virtual machines, subnets, and availability sets we set up for our recovery farm.

Таблица. Инфраструктура фермы восстановленияTable: Recovery farm infrastructure

Имя сервераServer name РольRole КонфигурацияConfiguration ПодсетьSubnet Группа доступностиAvailability set
spDRADspDRAD
Контроллер домена с Active DirectoryDomain controller with Active Directory
Два процессораTwo processors
От 512 МБ до 4 ГБ ОЗУFrom 512 MB through 4 GB of RAM
1 жесткий диск объемом 127 ГБ1 x 127-GB hard disk
sp-ADserverssp-ADservers
AZ-SP-FSAZ-SP-FS
Файловый сервер с общими папками для резервных копий и конечной точкой службы DFSRFile server with shares for backups and an endpoint for DFSR
Конфигурация A5:A5 configuration:
Два процессораTwo processors
14 ГБ ОЗУ14 GB of RAM
1 жесткий диск объемом 127 ГБ1 x 127-GB hard disk
1 жесткий диск объемом 135 ГБ1 x 135-GB hard disk
1 жесткий диск объемом 127 ГБ1 x 127-GB hard disk
1 жесткий диск объемом 150 ГБ1 x 150-GB hard disk
sp-databaseserverssp-databaseservers
DATA_SETDATA_SET
AZ-WFE1, AZ -WFE2AZ-WFE1, AZ -WFE2
Интерфейсные веб-серверыFront End Web servers
Конфигурация A5:A5 configuration:
Два процессораTwo processors
14 ГБ ОЗУ14 GB of RAM
1 жесткий диск объемом 127 ГБ1 x 127-GB hard disk
sp-webserverssp-webservers
WFE_SETWFE_SET
AZ -APP1, AZ -APP2, AZ -APP3AZ -APP1, AZ -APP2, AZ -APP3
Серверы приложенийApplication servers
Конфигурация A5:A5 configuration:
Два процессораTwo processors
14 ГБ ОЗУ14 GB of RAM
1 жесткий диск объемом 127 ГБ1 x 127-GB hard disk
sp-applicationserverssp-applicationservers
APP_SETAPP_SET
AZ -SQL-HA1, AZ -SQL-HA2AZ -SQL-HA1, AZ -SQL-HA2
Серверы баз данных, основная и вспомогательная реплики для групп доступности AlwaysOnDatabase servers and primary and secondary replicas for AlwaysOn availability groups
Конфигурация A5:A5 configuration:
Два процессораTwo processors
14 ГБ ОЗУ14 GB of RAM
sp-databaseserverssp-databaseservers
DATA_SETDATA_SET

ОперацииOperations

Когда команда тестирования стабилизировала среды ферм и завершила функциональное тестирование, она приступила к следующим задачам, необходимым для настройки локальной среды восстановления:After the test team stabilized the farm environments and completed functional testing, they started the following operations tasks required to configure the on-premises recovery environment:

  • Настройка полных и разностных резервных копий.Configure full and differential backups.

  • Настройка DFSR на файловых серверах, которые передают журналы транзакций между средой Azure и локальной средой.Configure DFSR on the file servers that transfer transaction logs between the on-premises environment and the Azure environment.

  • Настройка доставки журналов на основном сервере баз данных.Configure log shipping on the primary database server.

  • Стабилизация, проверка и устранение неполадок доставки журналов по мере необходимости. Это включает определение и документирование действий, которые могут вызывать проблемы, например задержку сети, которая приводит к сбоям доставки журналов или синхронизации файлов DFSR.Stabilize, validate, and troubleshoot log shipping, as required. This included identifying and documenting any behavior that might cause issues, such as network latency, which would cause log shipping or DFSR file synchronization failures.

DatabasesDatabases

Наши испытания отработки отказа включали следующие базы данных:Our failover tests involved the following databases:

  • WSS_ContentWSS_Content

  • ManagedMetadataManagedMetadata

  • БД профилейProfile DB

  • БД синхронизацииSync DB

  • БД социальных функцийSocial DB

  • Концентратор типов контента (база данных для выделенного концентратора синдикации типов контента)Content Type Hub (a database for a dedicated Content Type Syndication Hub)

Советы по устранению неполадокTroubleshooting tips

В этом разделе рассматриваются проблемы, с которыми мы столкнулись в ходе тестирования, и их решения.The section explains the problems we encountered during our testing and their solutions.

При использовании средства управления банками терминов возникала ошибка "Хранилище управляемых метаданных или подключение в настоящий момент недоступно".Using the Term Store Management Tool caused the error, "The Managed Metadata Store or Connection is currently not available."

Убедитесь, что у учетной записи пула приложений, используемой веб-приложением, есть разрешение "Доступ на чтение в банк терминов".Ensure that the application pool account used by the web application has the Read Access to Term Store permission.

Пользовательские банки терминов недоступны в семействе веб-сайтовCustom term sets are not available in the site collection

Проверьте наличие связи между семейством веб-сайтов контента и концентратором типов контента. Кроме того, перейдите на экран свойств Управляемые метаданные — подключение к и убедитесь, что включен параметр Это приложение-служба является используемым по умолчанию местом хранения для наборов терминов, определяемых столбцом.Check for a missing service application association between your content site collection and your content type hub. In addition, under the Managed Metadata - Connection properties screen, make sure this option is enabled: This service application is the default storage location for column specific term sets.

Команда Windows PowerShell Get-ADForest вызывает ошибку "Имя "Get-ADForest" не распознано как имя командлета, функции, файла скрипта или выполняемой программы".The Get-ADForest Windows PowerShell command generates the error, "The term 'Get-ADForest' is not recognized as the name of a cmdlet, function, script file, or operable program."

При настройке профилей пользователей необходимо имя леса Active Directory. Убедитесь, что в мастере добавления ролей и компонентов включен модуль Active Directory для Windows PowerShell (в разделе Средства удаленного администрирования сервера>Средства администрирования ролей>Средства AD DS и AD LDS). Кроме того, прежде чем использовать команду Get-ADForest, выполните следующие команды, чтобы обеспечить загрузку программных зависимостей.When setting up user profiles, you need the Active Directory forest name. In the Add Roles and Features Wizard, ensure that you have enabled the Active Directory Module for Windows PowerShell (under the Remote Server Administration Tools>Role Administration Tools>AD DS and AD LDS Tools section). In addition, run the following commands before using Get-ADForest to help ensure that your software dependencies are loaded.

Import-module servermanager
Import-module activedirectory

Ошибка создания группы доступности на этапе запуска сеанса XEvent "AlwaysOn_health" на сервере <имя сервера>Availability group creation fails at Starting the 'AlwaysOn_health' XEvent session on ''

Убедитесь, что оба узла отказоустойчивого кластера находятся в состоянии "Работает", а не "Приостановлен" или "Остановлен".Ensure that both nodes of your failover cluster are in the Status "Up" and not "Paused" or "Stopped".

Задание доставки журналов SQL Server завершается с ошибкой отказа в доступе при попытке подключиться к общему файловому ресурсуSQL Server log shipping job fails with access denied error trying to connect to the file share

Убедитесь, что агент SQL Server работает с учетными данными сети, а не учетными данными по умолчанию.Ensure that your SQL Server Agent is running under network credentials, instead of the default credentials.

Задание доставки журналов SQL Server завершается без ошибок, но файлы не копируютсяSQL Server log shipping job indicates success, but no files are copied

Это вызвано тем, что по умолчанию для группы доступности выбран параметр резервного копирования Предпочитать вторичную. Убедитесь, что задание доставки журналов выполняется на вспомогательном, а не основном, сервере группы доступности. В противном случае оно не принесет результатов.This happens because the default backup preference for an availability group is Prefer Secondary. Ensure that you run the log shipping job from the secondary server for the availability group instead of the primary; otherwise, the job will fail silently.

Служба управляемых метаданных (или другая служба SharePoint) не запускается автоматически после установкиManaged Metadata service (or other SharePoint service) fails to start automatically after installation

Запуск служб может занять несколько минут в зависимости от производительности и текущей нагрузки на сервере SharePoint Server. Нажмите кнопку Запустить для службы и дайте ей достаточно времени для запуска, периодически обновляя экран "Службы на сервере" и проверяя ее состояние. Если служба останется остановленной, включите сбор данных диагностики SharePoint, снова попробуйте запустить службу и проверьте журнал на предмет ошибок. Дополнительные сведения см. в статьеНастройка сбора данных диагностики в SharePoint 2013Services might take several minutes to start, depending on the performance and current load of your SharePoint Server. Manually click Start for the service and provide adequate time for startup while occasionally refreshing the Services on Server screen to monitor its status. In case the service remains stopped, enable SharePoint diagnostic logging, attempt to start the service again, and then check the log for errors. For more information, seeConfigure diagnostic logging in SharePoint 2013

После настройки DNS для среды отработки отказа Azure браузеры клиентов продолжают использовать старый IP-адрес сайта SharePointAfter changing DNS to the Azure failover environment, client browsers continue to use the old IP address for the SharePoint site

Изменение DNS может не сразу стать видимым для всех клиентов. Выполните следующую команду из командной строки с повышенными полномочиями в тестовом клиенте и повторите попытку доступа к сайту.Your DNS change might not be visible to all clients immediately. On a test client, perform the following command from an elevated command prompt and attempt to access the site again.

Ipconfig /flushdns

Дополнительные ресурсыAdditional resources

Поддерживаемые варианты обеспечения высокого уровня доступности и аварийного восстановления для баз данных SharePoint (SharePoint 2013)Supported high availability and disaster recovery options for SharePoint databases (SharePoint 2013)

Настройка групп обеспечения доступности SQL Server 2012 AlwaysOn для SharePoint 2013Configure SQL Server 2012 AlwaysOn Availability Groups for SharePoint 2013

См. такжеSee Also

Освоение облака и гибридные решенияCloud adoption and hybrid solutions