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

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

Смотрите видео с обзором аварийного восстановления в SharePoint Server 2013

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

Используйте эту статью вместе со следующей моделью решения: Аварийное восстановление SharePoint в Microsoft Azure.

PDF | Visio

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

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

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

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

• Повышение гибкости ресурсов В случае аварии легко масштабируйте ферму SharePoint для восстановления в соответствии с требованиями к нагрузке. Когда необходимость в дополнительных ресурсах пропадет, вы можете свернуть ферму.

• Меньшая зависимость от центров обработки данных Используйте Службы инфраструктуры Azure, чтобы не вкладывать средства во вспомогательный центр обработки данных в другом регионе.

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

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

Тип среды восстановления	Описание
Горячая замена	Полноразмерная ферма подготавливается, обновляется и работает в ждущем режиме.
Горячее резервирование	Создается ферма, а также работают и обновляются виртуальные машины. Восстановление включает присоединение баз данных контента, подготовку приложений-служб и обход контента. Эта ферма может быть уменьшенной версией рабочей фермы и расширяться для обслуживания всех пользователей.
Холодное резервирование	Ферма создается в полном масштабе, но виртуальные машины останавливаются. Обслуживание среды включает запуск виртуальных машин по мере необходимости, а также исправление, обновление и проверку среды. Полный запуск среды в случае сбоя.

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

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

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

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

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

• локальная рабочая ферма SharePoint;

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

• VPN-подключение типа "сеть-сеть" между двумя средами.

На следующем рисунке показаны эти три элемента.

Рисунок. Элементы решения горячего резервирования в Azure

Доставка журналов SQL Server с репликацией распределенной файловой системы (DFSR) используется для копирования резервных копий баз данных и журналов транзакций в ферму восстановления в Azure:

• DFSR переносит журналы из рабочей среды в среду восстановления. При использовании глобальной сети функция DFSR более эффективна, чем прямая доставка журналов на вторичный сервер в Azure.

• Журналы воспроизводятся на сервере SQL Server в среде восстановления Azure.

• Базы данных контента SharePoint с доставкой журналов присоединяются к среде только после восстановления.

Чтобы восстановить ферму, выполните следующие действия.

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

2. Остановите прием трафика основной фермы.

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

4. Присоедините базу данных контента к ферме.

5. Восстановите приложения-службы из служб реплицированных баз данных.

6. Измените записи системы доменных имен (DNS), чтобы они указывали на ферму восстановления.

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

Рекомендуем регулярно тренироваться выполнять эти действия и документировать их, чтобы обеспечить безотказное восстановление в случае настоящей аварии. Присоединение баз данных контента и восстановление приложений-служб могут занять некоторое время и обычно требуют настраивать некоторые параметры вручную.

После восстановления это решение предоставляет элементы, перечисленные в следующей таблице.

Таблица. Цели восстановления решения

Элемент	Описание
Сайты и контент	Сайты и контент доступны в среде восстановления.
Новый экземпляр поиска	В этом решении горячего резервирования поиск не восстанавливается из соответствующих баз данных. Компоненты поиска в ферме восстановления по мере возможности настраиваются аналогично рабочей ферме. После восстановления сайтов и контента запускается полный обход для восстановления индекса поиска. Чтобы сделать сайты и контент доступными, вам не придется дожидаться завершения обхода.
Службы	Службы, которые хранят данные в базах данных, восстанавливаются из баз данных с доставкой журналов. Службы, которые не хранят данные в базах данных, просто запускаются. Не все службы с базами данных требуют восстановления. Перечисленные ниже службы не требуют восстановления, и их можно запустить после отработки отказа. Приложение-служба сбора данных об использовании и работоспособности Служба состояний Служба автоматизации Word Любая другая служба, которая не использует базу данных

Вы можете сотрудничать со службами консультации Майкрософт (MCS) или партнерами, чтобы выполнять более сложные задачи восстановления. Эти задачи представлены в следующей статье.

Таблица. Другие задачи, которые могут выполнить MCS или партнеры

Элемент	Описание
Синхронизация решений пользовательской фермы	В идеальном случае конфигурация фермы восстановления идентична конфигурации рабочей фермы. Консультант или партнер может помочь вам определить, реплицируются ли решения пользовательской фермы и налажен ли процесс синхронизации двух сред.
Подключения к локальным источникам данных	Реплицировать подключения к серверным системам данных, например резервным контроллерам доменов (BDC) и источникам контента поиска, может быть нецелесообразно.
Сценарии восстановления поиска	Так как корпоративные среды поиска обычно являются довольно уникальными и сложными, восстановление поиска из баз данных требует больших инвестиций. Консультант или партнер может помочь вам определить и реализовать сценарии восстановления поиска, которые могут требоваться вашей организации.

В этой статье предполагается, что локальная ферма уже разработана и развернута.

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

В идеальном случае конфигурация фермы восстановления в Azure идентична конфигурации локальной рабочей фермы, включая:

• одинаковое представление ролей серверов;

• одинаковую конфигурацию настроек;

• одинаковую конфигурацию компонентов поиска.

Среда в Azure может быть меньшей версией рабочей фермы. Если вы планируете масштабировать ферму восстановления после отработки отказа, важно, чтобы каждый тип роли сервера изначально был представлен.

Некоторые конфигурации может быть нецелесообразно реплицировать в среде отработки отказа. Испытайте процедуры и среду отработки отказа, чтобы убедиться, что ферма отработки отказа предоставляет ожидаемый уровень обслуживания.

Это решение не требует определенной топологии фермы SharePoint. Основное внимание в этом решении уделяется использованию Azure для фермы отработки отказа и реализации доставки журналов и DFSR между двумя средами.

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

В теплой среде ожидания все виртуальные машины в среде Azure работают. Среда готова к отработке пробного или настоящего отказа.

На следующем рисунке показано решение аварийного восстановления из локальной фермы SharePoint в ферму Azure, которая настроена как среда горячего резервирования.

Рисунок. Топология и основные элементы рабочей фермы и фермы восстановления с горячим резервированием

На этой схеме:

• показаны две среды: локальная ферма SharePoint и ферма горячего резервирования в Azure;

• Каждая среда содержит общий файловый ресурс.

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

• четвертый уровень — это уровень баз данных. Доставка журналов используется для копирования журналов со вспомогательного сервера баз данных в локальной среде на общий файловый ресурс в той же среде;

• DFSR копирует файлы из общего файлового ресурса локальной среды на общий файловый ресурс среды Azure;

• доставка журналов воспроизводит журналы из общего файлового ресурса в среде Azure для основной реплики в группе доступности SQL Server AlwaysOn в среде восстановления.

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

В холодной резервной среде большинство виртуальных машин фермы SharePoint можно завершить работу. (Рекомендуется иногда запускать виртуальные машины, например каждые две недели или раз в месяц, чтобы каждая виртуальная машина могла синхронизироваться с доменом.) Следующие виртуальные машины в среде восстановления Azure должны оставаться запущенными, чтобы обеспечить непрерывную доставку журналов и DFSR:

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

• Основной сервер баз данных

• Как минимум одна виртуальная машина, на которой запущены доменные службы Windows Server Active Directory и DNS

На следующем рисунке показана среда отработки отказа Azure, в которой запущены виртуальная машина с общей папкой и основная виртуальная машина базы данных SharePoint. Все остальные виртуальные машины SharePoint остановлены. Виртуальная машина под управлением Windows Server Active Directory и DNS не отображается.

Рисунок. Виртуальные машины, запущенные в ферме восстановления с холодным резервированием

После отработки отказа в среде с холодным резервированием запускаются все виртуальные машины и должен быть настроен метод обеспечения высокой доступности серверов баз данных, например группы доступности SQL Server AlwaysOn.

Если реализовано несколько групп хранения (базы данных распределены между несколькими группами высокой доступности SQL Server), должна быть запущена основная база данных для каждой группы хранения, чтобы получить журналы, связанные с соответствующей группой хранения.

Знания и опыт

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

• Службы репликации распределенной файловой системы (DFS)

• Отказоустойчивая кластеризация Windows Server (WSFC) с SQL Server

• Группы доступности AlwaysOn (SQL Server)

• Резервное копирование и восстановление баз данных SQL Server

• Установка SharePoint Server 2013 и развертывание в ферме

• Microsoft Azure

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

Помимо Windows PowerShell, существуют также Windows PowerShell библиотеки для SQL Server, SharePoint Server и Azure. Не забывайте о T-SQL, который также может помочь сократить время настройки и обслуживания среды аварийного восстановления.

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

Эта схема подразумевает, что рабочая ферма SharePoint Server 2013 уже развернута.

Таблица. Схема аварийного восстановления

Этап	Описание
Этап 1	Разработка среды аварийного восстановления.
Этап 2	Создание виртуальной сети Azure и VPN-подключения.
Этап 3	Развертывание Windows Active Directory и служб доменных имен в виртуальной сети Azure.
Этап 4	Развертывание фермы восстановления SharePoint в Azure.
Этап 5	Настройка DFSR между фермами.
Этап 6	Настройка доставки журналов в ферму восстановления.
Этап 7	Проверка решений для отработки отказа и восстановления. Она включает следующие процедуры и технологии: остановка доставки журналов; восстановление резервных копий; обход контента; восстановление служб; управление записями DNS.

Этап 1. Разработка среды аварийного восстановления

Следуйте указаниям из статьи Microsoft Azure Architectures for SharePoint 2013, чтобы разработать среду аварийного восстановления, включая ферму восстановления SharePoint. Вы можете использовать графические элементы в файле Решения аварийного восстановления SharePoint в Azure Visio, чтобы начать процесс проектирования. Рекомендуем полностью разработать среду, прежде чем приступать к работе в среде Azure.

Выполнив указания по разработке виртуальной сети, VPN-подключения, Active Directory и фермы SharePoint, приведенные в статье Архитектуры Microsoft Azure для SharePoint 2013, также необходимо добавить роль файлового ресурса в среду Azure.

Для поддержки доставки журналов в решении аварийного восстановления в подсеть, содержащую роли баз данных, добавлена виртуальная машина файлового ресурса. Файловый ресурс также выполняет роль третьего узла большинства узлов для группы доступности SQL Server AlwaysOn. Эта конфигурация рекомендуется для стандартной фермы SharePoint, которая использует группы доступности SQL Server AlwaysOn.

Примечание.

Важно изучить необходимые условия для участия базы данных в группе доступности SQL Server AlwaysOn. Дополнительные сведения см. в разделе Предварительные требования, ограничения и рекомендации для групп доступности AlwaysOn.

Рисунок. Расположение файлового сервера, используемого решением для аварийного восстановления

На этой схеме в подсеть в Azure, содержащую роли серверов баз данных, добавлена виртуальная машина файлового ресурса. Не добавляйте эту виртуальную машину к группе доступности с другими ролями серверов, например ролей SQL Server.

Если вас беспокоит высокий уровень доступности журналов, попробуйте использовать другой подход, используя SQL Server резервное копирование и восстановление с помощью службы Хранилище BLOB-объектов Azure. Это новая функция в Azure, которая сохраняет журналы непосредственно в URL-адресе хранилища BLOB-объектов. Это решение не включает указания по использованию этой функции.

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

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

Этап 2. Создание виртуальной сети Azure и VPN-подключения

Подключение локальной сети к виртуальной сети Microsoft Azure показывает, как спланировать и развернуть виртуальную сеть в Azure и как создать VPN-подключение. Следуйте указаниям из этой статьи, чтобы выполнить следующие действия:

• Планирование пространства частных IP-адресов Виртуальная сеть.

• Планирование изменений инфраструктуры маршрутизации для Виртуальная сеть.

• Планирование правил брандмауэра для входящего и исходящего трафика на локальном устройстве VPN.

• Создание распределенной виртуальной сети в Azure.

• Настройка маршрутизации между локальной сетью и Виртуальная сеть.

Этап 3. Развертывание Active Directory и служб доменных имен в виртуальной сети Azure

Этот этап включает развертывание Windows Server Active Directory и DNS в Виртуальная сеть в гибридном сценарии, как описано в статье Архитектуры Microsoft Azure для SharePoint 2013 и показано на следующем рисунке:

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

На этом рисунке в одной подсети развертываются две виртуальные машины. На каждой из этих виртуальных машин размещаются две роли: Active Directory и DNS.

Перед развертыванием Active Directory в Azure ознакомьтесь с рекомендациями по развертыванию Windows Server Active Directory в Azure Виртуальные машины. Эти указания помогут вам определить требуются ли для вашего решения другие параметры конфигурации.

Подробные указания по настройке контроллера домена в Azure см. в статье Установка реплики контроллера домена Active Directory в виртуальных сетях Azure.

До этого этапа виртуальные машины не развертывались в виртуальная сеть. Виртуальные машины для размещения Active Directory и DNS, скорее всего, не являются самыми большими виртуальными машинами, необходимыми для решения. Перед развертыванием этих виртуальных машин сначала создайте самую большую виртуальную машину, которую планируется использовать в виртуальная сеть. Это помогает гарантировать, что ваше решение будет размещено на теге в Azure, который обеспечивает максимальный размер. В настоящее время настраивать эту виртуальную машину не требуется. Просто создайте его и отложите в сторону. Если этого не сделать, вы можете столкнуться с ограничением при попытке создать более крупные виртуальные машины позже, что было проблемой во время написания этой статьи.

Этап 4. Развертывание фермы восстановления SharePoint в Azure

Разверните ферму SharePoint в виртуальная сеть в соответствии с планами проектирования. Прежде чем развертывать роли SharePoint в Azure, рекомендуется ознакомиться с разделом Planning for SharePoint 2013 on Azure Infrastructure Services .

Ниже приводятся рекомендации, которые помогли нам при создании нашей экспериментальной среды:

• Создавайте виртуальные машины с помощью портала Azure или PowerShell.

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

• Перезагружайте виртуальные машины через интерфейс Azure, а не с экрана входа. Интерфейс Azure более удобен и предсказуем.

• Если вам нужно завершить работу виртуальной машины в целях снижения затрат, используйте интерфейс Azure. Если завершить работу на экране входа виртуальной машины, проблемы начнут накапливаться.

• Используйте соглашение об именовании для виртуальных машин.

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

• Функция автоматического масштабирования в Azure не поддерживается для ролей SharePoint.

• Не настраивайте элементы фермы, которые будут восстановлены, например семейства веб-сайтов.

Этап 5. Настройка DFSR между фермами

Чтобы настроить репликацию с помощью DFSR, используйте оснастку управления DNS. Однако перед установкой DFSR войдите на локальный файловый сервер и файловый сервер Azure и включите службу в Windows.

На панели мониторинга диспетчера серверов выполните следующие действия.

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

• Запустите мастер добавления ролей и компонентов.

• Откройте узел Файловые службы и службы хранилища.

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

• Нажмите кнопку Далее, чтобы завершить работу мастера.

В приведенной ниже таблице представлены ссылки на справочные статьи и сообщения блогов, посвященные DFSR.

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

Название	Описание
Репликация	Статья по управлению DFS на сайте TechNet, включающая ссылки для репликации
Практические советы по репликации DFS	Вики-сайт со ссылками на сведения о DFS
Репликация DFS. Вопросы и ответы	Статья о репликации DFS на сайте TechNet
Блог Хосе Баррето (Jose Barreto)	Блог главного руководителя проекта из группы файловых серверов Майкрософт
Блог группы Майкрософт, ответственной за хранение	Блог, посвященный файловым службам и функциям хранения в Windows Server

Этап 6. Настройка доставки журналов в ферму восстановления

Доставка журналов — ключевой компонент настройки аварийного восстановления в этой среде. Вы можете использовать доставку журналов, чтобы автоматически отправлять файлы журналов транзакций из основной базы данных во вспомогательный экземпляр сервера баз данных. Сведения о настройке доставки журналов см. в статье Configure log shipping in SharePoint 2013.

Важно!

Поддержка доставки журналов в SharePoint Server ограничена определенными базами данных. Дополнительные сведения см. в статье Поддерживаемые варианты высокого уровня доступности и аварийного восстановления для баз данных SharePoint (SharePoint 2013).

Этап 7. Проверка отработки отказа и восстановления

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

Для начала необходимо остановить входящие запросы пользователей к службам или контенту фермы. Это можно сделать, отключив записи DNS или отключив интерфейсные веб-серверы. После того как ферма не работает, вы можете выполнить отработку отказа на ферму восстановления.

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

Перед восстановлением фермы необходимо остановить доставку журналов. Сначала сделайте это на вспомогательном сервере в Azure, а затем — на основном локальном сервере. Используйте приведенный ниже сценарий, чтобы остановить доставку журналов сначала на вспомогательном сервере, а затем — на основном. Имена баз данных в сценарии могут отличаться от имен в вашей среде.

-- 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 + ' )')

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

Восстанавливать резервные копии нужно в порядке их создания. Перед восстановлением определенной резервной копии журнала транзакций необходимо сначала восстановить следующие предыдущие резервные копии без отката незафиксированных транзакций (т. е. с помощью WITH NORECOVERY):

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

• Все резервные копии журналов транзакций. Восстановите все резервные копии журнала транзакций, сделанные после полной резервной копии базы данных или разностной резервной копии (если вы восстановите ее) и перед конкретной резервной копией журнала транзакций. Резервные копии журналов необходимо применять в порядке их создания, не пропуская журналы.

Чтобы восстановить базу данных контента на вспомогательном сервере для отображения сайтов, удалите все подключения баз данных перед восстановлением. Чтобы восстановить базу данных, используйте следующую инструкцию SQL:

restore database WSS_Content with recovery

Важно!

Если вы используете T-SQL в явной форме, укажите параметр WITH NORECOVERY или WITH RECOVERY в каждом операторе RESTORE, чтобы избежать неоднозначности — это очень важно при написании сценариев. После восстановления полной и разностной резервной копии журналы транзакций можно восстановить в SQL Server Management Studio. Кроме того, так как доставка журналов уже остановлена, база данных контента находится в состоянии ожидания, которое нужно изменить на полный доступ.

В SQL Server Management Studio щелкните правой кнопкой мыши базу данных WSS_Content, наведите указатель на пункт Восстановление задач>, а затем выберите журнал транзакций (если вы не восстановили полную резервную копию, это недоступно). Дополнительные сведения см. в статьеВосстановление резервной копии журнала транзакций (SQL Server).

Обход источника контента

Чтобы восстановить службу поиска, необходимо запустить полный обход для каждого источника контента. Обратите внимание, что потеряются некоторые сведения аналитики из локальной фермы, например рекомендации поиска. Перед началом полного обхода контента используйте командлет Windows PowerShell Restore-SPEnterpriseSearchServiceApplication и укажите поставляемую в журнал и реплицированную базу данных администрирования поиска Search_Service__DB_<GUID>. Этот командлет задает конфигурацию, схему, управляемые свойства и правила поиска, а также создает набор других компонентов по умолчанию.

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

1. В Центр администрирования SharePoint 2013 откройте раздел Управление приложениями>Приложения-службы>Управление приложениями-службами, а затем щелкните приложение-службу поиска, обход которого нужно выполнить.

2. На странице Администрирование поиска нажмите Источники контента, наведите указатель на нужный источник контента, щелкните стрелку и нажмите Начать полный обход.

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

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

Важно!

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

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

Восстановление этих служб из баз данных с доставкой журналов	В этих службах есть базы данных, но их рекомендуется запускать без восстановления баз данных	Эти службы не хранят данные в базах данных. Запускайте их после отработки отказа
Служба машинного перевода Служба управляемых метаданных Служба Secure Store Служба профилей пользователей. (Поддерживаются только базы данных профилей и социальных тегов. База данных синхронизации не поддерживается.) Служба параметров подписки Microsoft SharePoint Foundation	Приложение-служба сбора данных об использовании и работоспособности Служба состояний Служба автоматизации Word	Службы Excel PerformancePoint Services Служба преобразования PowerPoint Служба графики Visio Служба управления работой

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

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

Сначала используйте New-SPMetadataServiceApplicationи укажите DatabaseName параметр с именем восстановленной базы данных.

Затем настройте новое приложение-службу управляемых метаданных на вспомогательном сервере, указав следующие параметры:

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

• Сервер базы данных: имя базы данных из доставленного журнала транзакций

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

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

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

Необходимо вручную создать записи DNS, указывающие на ферму SharePoint.

В большинстве случаев при наличии нескольких интерфейсных веб-серверов имеет смысл воспользоваться преимуществами функции балансировки сетевой нагрузки в Windows Server 2012 или аппаратной подсистемы балансировки нагрузки для распределения запросов между веб-интерфейсными серверами в ферме. Балансировка сетевой нагрузки также может снизить риск, распределяя запросы на другие серверы в случае сбоя одного из интерфейсных веб-серверов.

Как правило, при настройке балансировки сетевой нагрузки кластеру назначается один IP-адрес. Затем вы создадите запись узла DNS в поставщике DNS для сети, которая указывает на кластер. (Для этого проекта мы помещаем DNS-сервер в Azure для обеспечения устойчивости в случае сбоя локального центра обработки данных.) Например, в диспетчере DNS в Active Directory можно создать запись DNS, которая https://sharepoint.contoso.comуказывает на IP-адрес кластера с балансировкой нагрузки.

Для внешнего доступа к ферме SharePoint можно создать запись узла на внешнем DNS-сервере с тем же URL-адресом, который клиенты используют в интрасети (например, https://sharepoint.contoso.com), который указывает на внешний IP-адрес в брандмауэре. (В этом примере рекомендуется настроить разделение DNS, чтобы внутренний DNS-сервер был полномочным для contoso.com и перенаправит запросы непосредственно в кластер фермы SharePoint, а не маршрутизацию DNS-запросов на внешний DNS-сервер.) Затем можно сопоставить внешний IP-адрес с внутренним IP-адресом локального кластера, чтобы клиенты могли найти нужные ресурсы.

После этого может возникнуть один из описанных ниже сценариев аварийного восстановления.

Пример сценария. Локальная ферма SharePoint недоступна по причине сбоя оборудования в локальной ферме SharePoint. В этом случае после выполнения действий по отработке отказа на ферму Azure SharePoint можно настроить балансировку сетевой нагрузки на веб-серверах sharePoint для восстановления так же, как и в локальной ферме. Затем вы можете перенаправить запись узла во внутреннем поставщике DNS, чтобы указать на IP-адрес кластера фермы восстановления. Обратите внимание, что обновление кэшированных записей DNS в клиентах, чтобы они указывали на ферму восстановления, может занять некоторое время.

Пример сценария. Локальный центр обработки данных полностью потерян. Этот сценарий может возникнуть в результате стихийного бедствия, например пожара или наводнения. В этом случае для предприятия, скорее всего, у вас будет дополнительный центр обработки данных, размещенный в другом регионе, а также подсеть Azure с собственными службами каталогов и DNS. Как и в предыдущем сценарии аварии, вы можете перенаправить внутренние и внешние записи DNS, чтобы указать на ферму Azure SharePoint. Помните, что распространение записей DNS может занять некоторое время.

Если вы используете семейства веб-сайтов с именем узла, как рекомендуется в статье Архитектура и развертывание семейства веб-сайтов с именем узла (SharePoint 2013), у вас может быть несколько семейств веб-сайтов, размещенных в одном веб-приложении в ферме SharePoint, с уникальными DNS-именами (например, https://sales.contoso.com и https://marketing.contoso.com). В этом случае вы можете создать для каждого семейства веб-сайтов записи DNS, указывающие на IP-адрес кластера. Когда запросы достигают интерфейсных веб-серверов SharePoint, эти серверы обрабатывают маршрутизацию запросов в соответствующие семейства веб-сайтов.

Экспериментальная среда Майкрософт

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

В следующей таблице описываются виртуальные машины Hyper-V, созданные и настроенные для локальной тестовой среды.

Таблица. Виртуальные машины для локального тестирования

Имя сервера	Роль	Конфигурация
DC1;	Контроллер домена с Active Directory.	Два процессора От 512 МБ до 4 ГБ ОЗУ 1 жесткий диск объемом 127 ГБ
RRAS	Сервер, на котором настроена роль службы маршрутизации и удаленного доступа (RRAS).	Два процессора 2-8 ГБ ОЗУ 1 жесткий диск объемом 127 ГБ
FS1	Файловый сервер с общими папками для резервных копий и конечной точкой для DFSR.	Четыре процессора 2-12 ГБ ОЗУ 1 жесткий диск объемом 127 ГБ 1 жесткий диск объемом 1 ТБ (SAN) 1 жесткий диск объемом 750 ГБ
SP-WFE1, SP-WFE2	Интерфейсные веб-серверы.	Четыре процессора 16 ГБ ОЗУ
SP-APP1, SP-APP2, SP-APP3	Серверы приложений	Четыре процессора 2-16 ГБ ОЗУ
SP-SQL-HA1, SP-SQL-HA2	Серверы баз данных, настроенные с SQL Server групп доступности AlwaysOn 2012 для обеспечения высокого уровня доступности. В этой конфигурации используются SP-SQL-HA1 и SP-SQL-HA2, основная и вспомогательная реплики.	Четыре процессора 2-16 ГБ ОЗУ

В следующей таблице описываются конфигурации дисков для виртуальных машин Hyper-V, которые мы создали и настроили для серверов приложений и интерфейсных веб-серверов в локальной тестовой среде.

Таблица. Требования к дискам виртуальных машин для серверов приложений и интерфейсных веб-серверов в локальной тестовой среде

Буква диска	Size	Имя каталога	Path
В	80	Системный диск	<DriveLetter>:\Program Files\Microsoft SQL Server\
E	80	Диск журналов (40 ГБ)	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
F	80	Диск файла подкачки (36 ГБ)	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL\DATA

В следующей таблице описаны конфигурации дисков для виртуальных машин Hyper-V, созданных и настроенных в качестве локальных серверов баз данных. На странице Настройка компонента Database Engine откройте вкладку Каталоги данных, чтобы задать и подтвердить параметры, показанные в следующей таблице.

Таблица. Требования к диска виртуальных машин для сервера базы данных в локальной тестовой среде

Буква диска	Size	Имя каталога	Path
В	80	Корневой каталог данных	<DriveLetter>:\Program Files\Microsoft SQL Server\
E	500	Каталог базы данных пользователей	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
F	500	Каталог журнала базы данных пользователей	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
G	500	Временный каталог БД	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA
H	500	Временный каталог журнала БД	<DriveLetter>:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA

Настройка тестовой среды

На разных этапах развертывания команда тестирования обычно работала сначала над локальной архитектурой, а затем в соответствующей среде Azure. То же самое обычно происходит в реальных сценариях, где внутренние рабочие фермы уже запущены. Еще важнее знать текущую рабочую нагрузку, емкость и типичную производительностью. Создав модель аварийного восстановления, соответствующую бизнес-требованиям, следует изменить размеры ее серверов для минимального уровня обслуживания. Как правило, в средах с холодным или горячим резервированием ферма восстановления меньше рабочей фермы. Когда ферма восстановления будет находиться в стабильном рабочем состоянии, ее можно будет разворачивать и сворачивать в соответствии с требованиями к рабочей нагрузке.

Развертывание нашей тестовой среды выполнялось в три этапа:

• Настройка гибридной инфраструктуры

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

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

Настройка гибридной инфраструктуры

На этом этапе была настроена доменная среда для локальной фермы и для фермы восстановления в Azure. Помимо обычных задач, связанных с настройкой Active Directory, команда тестирования реализовала решение для маршрутизации и VPN-соединение между двумя средами.

Подготовка серверов

Помимо серверов ферм, требовалось подготовить серверы для контроллеров доменов и настроить сервер для обработки RRAS и VPN типа "сеть-сеть". Для службы DFSR были подготовлены два файловых сервера, а для тестировщиков — несколько клиентских компьютеров.

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

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

Мы создали серверы баз данных с установленными SQL Server перед созданием серверов SharePoint 2013. Так как это было новое развертывание, мы создали группы доступности перед развертыванием SharePoint. Мы создали три группы, следуя рекомендациям службы MCS.

Примечание.

Создайте подстановочные базы данных, чтобы иметь возможность создать группы доступности перед установкой SharePoint. Дополнительные сведения см. в статье Настройка групп доступности AlwaysOn SQL Server 2012 для SharePoint 2013.

Мы создали ферму и объединили дополнительные серверы в следующем порядке:

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

• Настройка AlwaysOn и создание трех групп доступности для фермы.

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

• Подготовка серверов SP-WFE1 и SP-WFE2 для размещения распределенного кэша.

Мы использовали параметр командной строки skipRegisterAsDistributedCachehost при запуске программы psconfig.exe. Дополнительные сведения см . в статье Планирование веб-каналов и службы распределенного кэша в SharePoint Server 2013.

В среде восстановления мы повторили следующие этапы:

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

• Настройка AlwaysOn и создание трех групп доступности для фермы.

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

• Подготовка серверов AZ-WFE1 и AZ-WFE2 для размещения распределенного кэша.

Настроив распределенный кэш и добавив тестовых пользователей и тестовый контент, мы приступили ко второму этапу развертывания. Для этого потребовалось развернуть уровни и настроить серверы ферм для поддержки топологии высокой доступности, описанной в архитектуре фермы.

В следующей таблице описываются виртуальные машины, подсети и группы доступности, настроенные для фермы восстановления.

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

Имя сервера	Роль	Конфигурация	Подсеть	Группа доступности
spDRAD	Контроллер домена с Active Directory	Два процессора От 512 МБ до 4 ГБ ОЗУ 1 жесткий диск объемом 127 ГБ	sp-ADservers
AZ-SP-FS	Файловый сервер с общими папками для резервных копий и конечной точкой службы DFSR	Конфигурация A5: Два процессора 14 ГБ ОЗУ 1 жесткий диск объемом 127 ГБ 1 жесткий диск объемом 135 ГБ 1 жесткий диск объемом 127 ГБ 1 жесткий диск объемом 150 ГБ	sp-databaseservers	DATA_SET
AZ-WFE1, AZ -WFE2	Интерфейсные веб-серверы	Конфигурация A5: Два процессора 14 ГБ ОЗУ 1 жесткий диск объемом 127 ГБ	sp-webservers	WFE_SET
AZ -APP1, AZ -APP2, AZ -APP3	Серверы приложений	Конфигурация A5: Два процессора 14 ГБ ОЗУ 1 жесткий диск объемом 127 ГБ	sp-applicationservers	APP_SET
AZ -SQL-HA1, AZ -SQL-HA2	Серверы баз данных, основная и вспомогательная реплики для групп доступности AlwaysOn	Конфигурация A5: Два процессора 14 ГБ ОЗУ	sp-databaseservers	DATA_SET

Операции

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

• Настройка полных и разностных резервных копий.

• Настройка DFSR на файловых серверах, которые передают журналы транзакций между средой Azure и локальной средой.

• Настройка доставки журналов на основном сервере баз данных.

• Стабилизация, проверка и устранение неполадок доставки журналов по мере необходимости. Это включает определение и документирование действий, которые могут вызывать проблемы, например задержку сети, которая приводит к сбоям доставки журналов или синхронизации файлов DFSR.

Databases

Наши испытания отработки отказа включали следующие базы данных:

• WSS_Content

• ManagedMetadata

• БД профилей

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

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

• Концентратор типов контента (база данных для выделенного концентратора синдикации типов контента)

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

В этом разделе рассматриваются проблемы, с которыми мы столкнулись в ходе тестирования, и их решения.

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

Убедитесь, что у учетной записи пула приложений, используемой веб-приложением, есть разрешение "Доступ на чтение в банк терминов".

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

Проверьте связи приложений-служб между семейством веб-сайтов контента и концентратором типов контента. Кроме того, на экране Управляемые метаданные — <имя> семейства веб-сайтов Свойства подключения убедитесь, что этот параметр включен: Это приложение-служба является расположением хранилища по умолчанию для наборов терминов для столбцов.

Команда Windows PowerShell Get-ADForest вызывает ошибку "Имя "Get-ADForest" не распознано как имя командлета, функции, файла скрипта или выполняемой программы".

При настройке профилей пользователей необходимо имя леса Active Directory. В мастере добавления ролей и компонентов убедитесь, что вы включили модуль Active Directory для Windows PowerShell (в разделе Средства администрирования ролей удаленного администрирования>сервера AD>DS и средства AD LDS). Кроме того, прежде чем использовать команду Get-ADForest, выполните следующие команды, чтобы обеспечить загрузку программных зависимостей.

Import-Module ServerManager
Import-Module ActiveDirectory

Создание группы доступности завершается сбоем при запуске сеанса XEvent "AlwaysOn_health" на "<имя> сервера"

Убедитесь, что оба узла отказоустойчивого кластера находятся в состоянии "Работает", а не "Приостановлен" или "Остановлен".

Задание доставки журналов SQL Server завершается с ошибкой отказа в доступе при попытке подключиться к общему файловому ресурсу

Убедитесь, что агент SQL Server работает с учетными данными сети, а не учетными данными по умолчанию.

Задание доставки журналов SQL Server завершается без ошибок, но файлы не копируются

Это происходит из-за того, что по умолчанию для группы доступности используется параметр Предпочитать вторичный. Убедитесь, что задание доставки журналов выполняется с сервера-получателя для группы доступности, а не с основного сервера; В противном случае задание завершится автоматическим сбоем.

Служба управляемых метаданных (или другая служба SharePoint) не запускается автоматически после установки

Запуск служб может занять несколько минут в зависимости от производительности и текущей нагрузки на сервере SharePoint Server. Нажмите кнопку Запустить для службы и дайте ей достаточно времени для запуска, периодически обновляя экран "Службы на сервере" и проверяя ее состояние. Если служба останется остановленной, включите сбор данных диагностики SharePoint, снова попробуйте запустить службу и проверьте журнал на предмет ошибок. Дополнительные сведения см. в статье Настройка ведения журнала диагностики в SharePoint 2013.

После настройки DNS для среды отработки отказа Azure браузеры клиентов продолжают использовать старый IP-адрес сайта SharePoint

Изменение DNS может не сразу стать видимым для всех клиентов. Выполните следующую команду из командной строки с повышенными полномочиями в тестовом клиенте и повторите попытку доступа к сайту.

Ipconfig /flushdns

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

Поддерживаемые варианты обеспечения высокой доступности и аварийного восстановления для баз данных SharePoint

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

См. также

Центр архитектуры и решений Microsoft 365