Планирование аварийного восстановления (SharePoint Server 2010)
Применимо к: SharePoint Foundation 2010, SharePoint Server 2010
Последнее изменение раздела: 2016-11-30
В этой статье описываются ключевые решения при выборе стратегий аварийного восстановления для среды Microsoft SharePoint Server 2010.
Содержание:
Обзор аварийного восстановления
Выбор стратегии аварийного восстановления
Планирование для центров обработки данных с "холодным" резервированием
Планирование для центров обработки данных с "горячим" резервированием
Планирование для центров обработки данных с "горячей" заменой
Системные требования для аварийного восстановления
Обзор аварийного восстановления
Для целей настоящей статьи аварийное восстановление определяется как возможность восстановления в ситуации, когда центр обработки данных, в котором размещается SharePoint Server, становится недоступным.
Стратегия аварийного восстановления, используемая для SharePoint Server, должна быть согласована со стратегией аварийного восстановления для соответствующей инфраструктуры, в том числе доменов Active Directory, сервера Exchange Server и Microsoft SQL Server. Разрабатывая согласованные стратегию и план аварийного восстановления, сотрудничайте с администраторами используемой инфраструктуры.
Время и непосредственные усилия по созданию другой фермы и запуску в другом расположении часто называются "горячей" заменой, "горячим" резервированием и "холодным" резервированием. В рамках этой статьи эти термины определяются следующим образом:
Горячая замена. Второй центр обработки данных, который может обеспечить доступность в течение секунд или минут.
Горячее резервирование. Второй центр обработки данных, который может обеспечить доступность в течение минут или часов.
Холодное резервирование. Второй центр обработки данных, который может обеспечить доступность в течение часов или дней.
Аварийное восстановление может быть одним из наиболее дорогих требований к системе. Чем короче интервал между отказом и доступностью и чем большее количество систем защищается, тем сложнее и дороже, скорее всего, будет решение для аварийного восстановления. При инвестировании в центры обработки данных с горячей заменой или горячим резервированием нужно учитывать следующие расходы:
Дополнительное аппаратное и программное обеспечение, которое часто увеличивает сложность работы программных приложений, таких как специализированные скрипты для отработки отказа и восстановления.
Дополнительная сложность эксплуатации.
Стоимость поддержки горячей замены или горячего резервирования для центров обработки данных следует оценивать на основе потребностей конкретного бизнеса. Не для всех решений в организации, скорее всего, требуется один и тот же уровень доступности после аварии. Для различных служб, ферм, контента можно предложить различные уровни аварийного восстановления — например, для контента, который сильно влияет на бизнес, или для службы поиска, или для фермы публикации в Интернете.
Аварийное восстановление — это ключевая область, в которой ИТ-отделы предлагают заключать соглашения об уровне обслуживания, определяющие ожидания групп пользователей. Многие ИТ-организации предлагают различные соглашения об уровне обслуживания, связанные с различными уровнями внутренних расчетов.
При реализации отработки отказа для ферм серверов рекомендуется сначала развернуть и настроить базовое решение на ферме, а затем реализовать и протестировать аварийное восстановление.
Выбор стратегии аварийного восстановления
В зависимости от потребностей бизнеса для среды SharePoint Server можно выбирать среди многих подходов к обеспечению аварийного восстановления. В следующих примерах показывается, почему компании могут выбирать стратегии аварийного восстановления с "холодным" резервированием, "горячим" резервированием и "горячей" заменой.
Стратегия аварийного восстановления с холодным резервированием: предприятие регулярно доставляет резервные копии в локальное и региональное внешнее хранилище для поддержки восстановления исходного состояния системы, а также заключило контракт на аренду сервера аварийного восстановления в другом регионе.
Плюсы.
Часто самый дешевый в обслуживании вариант (с точки зрения затрат на эксплуатацию).
Часто это дорогой вариант для восстановления, так как для него требуется, чтобы физические серверы были после аварии правильно настроены.
Минусы. Самый медленный вариант для восстановления.
Стратегия аварийного восстановления с горячим резервированием: предприятие доставляет образы виртуальных серверов на локальные и региональные фермы аварийного восстановления.
Плюсы. Часто относительно недорогой вариант восстановления, так как ферма виртуальных серверов требует при восстановлении минимальной настройки.
Минусы. Обслуживание может быть очень дорогим и занимать много времени.
Стратегия аварийного восстановления с горячей заменой: предприятие использует несколько центров обработки данных, однако обслуживает контент и службы только через один центр обработки данных.
Плюсы. Часто восстановление выполняется относительно быстро.
Минусы. Этот вариант может быть достаточно дорогим в настройке и обслуживании.
Важно!
Независимо от решения аварийного восстановления, выбранного для реализации в используемой среде, скорее всего, какая-то часть данных будет потеряна.
Планирование для центров обработки данных с "холодным" резервированием
В сценарии аварийного восстановления с "холодным" резервированием можно выполнить восстановление, создавая новую ферму в новом месте (желательно используя развертывание с помощью скрипта) и восстанавливая резервные копии. Либо можно выполнить восстановление, восстанавливая ферму из резервного решения, такого как Microsoft System Center Data Protection Manager 2007, защищающего данные на уровне компьютера и позволяющего восстанавливать каждый сервер индивидуально. Эта статья не содержит подробных инструкций о создании и восстановлении в сценариях с холодным резервированием. Дополнительные сведения см. в следующих статьях:
Планирование для центров обработки данных с "горячим" резервированием
В сценарии аварийного восстановления с "горячим" резервированием можно создать решение горячего резервирования, обеспечив последовательное и частое создание виртуальных образов серверов используемой фермы, доставляемых в дополнительное расположение. Для повторного создания среды используемой фермы в этом дополнительном расположении необходимо наличие среды, в которой можно легко настроить и подключить образы.
Эта статья не содержит подробных инструкций по созданию решений с горячим резервированием. Дополнительные сведения о планировании развертывания ферм с помощью виртуальных решений см. в статье Планирование виртуализации (SharePoint Server 2010).
Планирование для центров обработки данных с "горячей" заменой
В сценарии аварийного восстановления с "горячей" заменой можно настроить ферму, обеспечивающую отработку отказа, чтобы обеспечить аварийное восстановление основной фермы в отдельном центре обработки данных. Среда, содержащая отдельную ферму, обеспечивающую отработку отказа, обладает следующими характеристиками:
На ферме, обеспечивающей отработку отказа, должны поддерживаться отдельная база данных конфигурации и база данных контента центра администрирования.
Все настройки должны развертываться на обеих фермах.
Примечание
Рекомендуется использовать развертывание с помощью скриптов для создания основной фермы и фермы, обеспечивающей отработку отказа, с использованием тех же параметров конфигурации и настроек. Дополнительные сведения см. в статье Установка SharePoint Server 2010 с помощью Windows PowerShell.
Обновления должны применяться к обеим фермам по отдельности.
Для баз данных контента SharePoint Server может быть успешно выполнено асинхронное зеркальное отображение или доставка журнала на ферму, обеспечивающую отработку отказа.
Примечание
Зеркальное отображение SQL Server можно использовать только для копирования баз данных на один сервер зеркала, но доставку журнала можно выполнить на несколько серверов-получателей.
Приложения-службы могут отличаться в зависимости от того, могут ли их журналы доставляться на ферму. Дополнительные сведения см. в разделе Избыточность приложений-служб в центрах обработки данных далее в этой статье.
Эту топологию можно повторить для многих центров обработки данных, если настроить доставку журнала SQL Server в один или несколько дополнительных центров обработки данных.
Чтобы определить, можно ли использовать репликацию SAN или другой поддерживаемый механизм для обеспечения доступности центров обработки данных, обратитесь к своему поставщику SAN.
На следующем рисунке показаны основная ферма и ферма, обеспечивающая отработку отказа, перед выполнением отработки отказа.
Основная ферма и ферма, обеспечивающая отработку отказа, перед выполнением отработки отказа
.gif "Основная и резервная фермы до отказа")
Избыточность приложений-служб в центрах обработки данных
Для обеспечения доступности приложений-служб в центрах обработки данных рекомендуется, чтобы службы, которые могут выполняться межферменно, выполнялись на отдельной ферме служб, доступной как для основного, так и для дополнительного центра обработки данных.
Для служб, которые не могут выполняться межферменно, и для обеспечения доступности самой фермы служб могут использоваться различные стратегии обеспечения избыточности приложения-службы в центрах обработки данных. Используемая стратегия зависит от следующих факторов:
Для бизнеса важно выполнение приложения-службы на ферме аварийного использования, когда она не используется.
Для баз данных, связанных с приложением-службой, могут быть выполнены доставка журнала или асинхронное зеркальное копирование.
Приложение-служба может выполняться для баз данных в режиме только для чтения.
В следующих разделах описываются стратегии аварийного восстановления, рекомендуемые для каждого приложения-службы. Приложения-службы сгруппированы по стратегиям.
Базы данных, для которых возможны доставка журнала или асинхронное зеркальное копирование
После первоначального развертывания приложения-службы на дополнительной ферме для баз данных, которые поддерживают следующие приложения-службы, между фермами можно выполнить асинхронное зеркальное копирование или доставку журнала:
Приложение-служба управляемых метаданных
Базы данных: служба управляемых метаданных
Примечание
Если используются теги, для успешной работы приложения-службы управляемых метаданных в ферме аварийного восстановления также требуется запустить модуль репликации профилей пользователей, который включен в набор средств администрирования SharePoint. Дополнительные сведения см. в статье User Profile Replication Engine overview (SharePoint Server 2010).
PerformancePoint Services
Базы данных: приложение-служба PerformancePoint
Приложение-служба Project Server
Базы данных: черновиков, опубликованных проектов, отчетов или архива
В Project Server 2010 требуется синхронизация между базами данных. Project Server поддерживает репликацию между фермами с использованием асинхронного механизма репликации (асинхронное зеркалирование базы данных, доставка журнала или асинхронная репликация SAN), однако при восстановлении необходимо убедиться, что синхронизируются журналы базы данных Project.
Примечание
Несмотря на то, что рекомендуется выполнять доставку журнала или зеркалирование баз данных Project Server в ферме аварийного восстановления, приложение-служба не поддерживает работу с базами данных, доступными только для чтения. В связи с этим не рекомендуется выполнять приложение-службу Project Server в ферме аварийного восстановления после отработки отказа. Для успешной синхронизации баз данных Project Server в ферме аварийного восстановления необходимо настроить отметки времени или пометки журнала для баз данных.
Приложение-служба Secure Store
Базы данных: безопасное хранение
Приложение-служба сбора данных об использовании и исправности
Базы данных: ведение журнала
Примечание
Для базы данных журналов можно выполнить доставку журнала или зеркальное копирование. Однако рекомендуется не выполнять на ферме аварийного восстановления службу сбора данных об использовании и исправности и не использовать для базы данных журналов ни доставку журнала, ни зеркальное копирование.
Приложение-служба Web Analytics
Базы данных: промежуточная, отчеты
Примечание
Рекомендуется выполнять доставку журнала или зеркалирование промежуточной базы данных и БД отчетов Web Analytics. Тем не менее не рекомендуется выполнять приложение-службу Web Analytics в ферме аварийного восстановления до отработки отказа.
Приложения-службы и базы данных, для которых невозможно выполнять ни доставку журнала, ни асинхронное зеркальное копирование
Следующие приложения-службы должны быть развернуты как на основной ферме, так и на ферме, обеспечивающей отработку отказа. Для них нельзя использовать ни доставку журнала, ни асинхронное зеркальное копирование. Для большинства этих приложений-служб рекомендуется сначала развернуть их, а затем проверить, что параметры конфигурации фермы, обеспечивающей отработку отказа, совпадают с настройками основной фермы. Если на основной ферме выполняются изменения конфигурации, влияющие на данную службу, необходимо обновить и конфигурацию фермы, обеспечивающей отработку отказа.
Приложение-служба реестра приложений
Базы данных: служба реестра приложений
Доставка журнала базы данных службы реестра приложений не поддерживается.
Приложение службы подключения к бизнес-данным
Базы данных: подключение к бизнес-данным
Приложение-служба профилей пользователей
Базы данных: профили, синхронизация, социальные теги
Базы данных профилей, синхронизации и социальных тегов не поддерживают доставку журнала.
Чтобы обеспечить резервирование приложения-службы профилей пользователей, необходимо сначала развернуть приложение-службу одновременно в центре обработки данных — источнике и центре обработки данных — получателе.
Для настройки баз данных профилей и сертификации рекомендуется восстановить резервные копии баз данных в центр обработки данных — получатель и присоединить их к приложению-службе профилей пользователей в этом центре обработки данных.
Чтобы обеспечить синхронизацию профилей, необходимо после обновления данных профиля в основной ферме запустить модуль репликации профилей пользователей, входящий в набор средств администрирования SharePoint. Дополнительные сведения см. в статье User Profile Replication Engine overview (SharePoint Server 2010).
Приложение-служба параметров подписки Microsoft SharePoint Foundation
База данных: подписка
Примечание
Доставка журнала базы данных параметров подписки не поддерживается.
Службы Access
Базы данных: нет
Службы Excel
Базы данных: нет
Поиск
Базы данных: обход контента, свойства, администрирование поиска
Поиск требует полной синхронизации между базой данных и индексом. В связи с этим требованием данные поиска нельзя реплицировать между фермами, используя механизм асинхронной репликации (асинхронное зеркалирование базы данных, доставка журнала или асинхронная репликация SAN).
Чтобы обеспечить актуальность поиска в резервной ферме, необходимо выполнять поиск в ферме-получателе.
Важно!
Приложение-служба поиска в резервной ферме должно быть настроено на активный обход контента в ферме-получателе. Для отработки отказа необходимо настроить сопоставление веб-приложения на использование резервного приложения-службы поиска.
Служба состояния
Базы данных: состояния
Примечание
Доставка журнала базы данных состояний не поддерживается.
Службы Visio
Базы данных: нет
Word Automation Services
Базы данных: Word Automation Services
Доставка журнала для базы данных Word Automation Services не поддерживается.
Системные требования для аварийного восстановления
В идеальном сценарии компоненты и системы, поддерживающие отработку отказа, полностью соответствуют основным компонентам и системам: платформа, оборудование и количество серверов. Среда, поддерживающая отработку отказа, должна, как минимум, уметь обрабатывать трафик, ожидаемый во время отработки отказа. Помните, что только некоторое подмножество пользователей может быть обслужено сайтом, поддерживающим отработку отказа. Системы должны соответствовать друг другу, по крайней мере, по следующим параметрам:
Версия и все обновления операционной системы
Версия и все обновления SQL Server
Версии и все обновления Продукты SharePoint 2010
В этой статье главным образом рассматривается доступность Продукты SharePoint 2010, однако на время работоспособного состояния системы также будут влиять и другие ее компоненты. В частности, убедитесь, что выполнены следующие действия:
Обеспечьте полную избыточность таких инфраструктурных зависимостей, как питание, сеть, служба каталогов и SMTP.
Выберите удовлетворяющий своим потребностям механизм переключения, будь это DNS или аппаратная балансировка нагрузки.