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