Выбор стратегии аварийного восстановления для SharePoint Server

  • Статья

 

**Применимо к:**SharePoint Foundation 2013, SharePoint Server 2013, SharePoint Server 2016

**Последнее изменение раздела:**2017-08-01

Сводка. Описание параметров аварийного восстановления и поддерживаемых технологий восстановления фермы SharePoint Server 2016 и SharePoint 2013 в случае аварии.

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

В этой статье

  • Введение

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

  • Системные требования для восстановления

SharePoint Server 2016 и SQL Server 2014 с пакетом обновления 1 (SP1) или SQL Server 2016, SharePoint 2013 и SQL Server 2008 R2 с пакетом обновления 1 (SP1) или SQL Server 2012 предоставляют возможности восстановления конфигурации и контента, позволяющие добиться целевого времени восстановления (RTO) и целевой точки восстановления (RPO), необходимых вашей организации в случае аварии. Дополнительные сведения об этих и других понятиях аварийного восстановления см. в статье Концепции высокой доступности и аварийного восстановления в SharePoint Server.

Введение

Эффективная стратегия аварийного восстановления для фермы SharePoint Server должна соответствовать бизнес-требованиям организации, которые обычно выражаются с помощью двух показателей: целевого времени восстановления (RTO) и целевой точки восстановления (RPO). Требования RTO и RPO определяются на основе стоимости простоя организации в случае аварии.

Важно!

Мы рекомендуем четко определить RTO и RPO организации перед разработкой стратегии восстановления и реализации технического решения. Сконцентрируйтесь на том, что необходимо, а не на том, как это сделать.

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

  • Потеря службы приложения. Влияние на простой зависит от приложения и компании.

  • Потеря данных. Возможная потеря данных из-за сбоя системы может иметь значительные юридические и финансовые последствия.

Большинство организаций понесут ущерб от простоя в связи с двумя указанными выше потерями, но природа бизнеса определяет, какая из них приведет к наихудшим последствиям. В указанной далее статье, написанной Крисом Праймсбергером (Chris Preimesberger) для веб-сайта eWEEK, описаны финансовые последствия простоя центра обработки данных. Отчет: незапланированный простой ИТ-среды может обходиться в 5000 долларов в минуту.

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

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

Варианты восстановления резервного центра обработки данных

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

  • Холодное резервирование. Дополнительный центр обработки данных, которые обеспечивает доступность в течение нескольких часов или дней.

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

  • Горячее резервирование. Дополнительный центр обработки данных, которые обеспечивает доступность в течение нескольких секунд или минут.

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

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

    Плюсы:

    • часто это самый дешевый в обслуживании вариант.

    • Часто этот вариант дорого обходится при восстановлении, так как после аварии необходимо правильно настроить физические серверы.

    Минусы: самый медленный вариант восстановления.

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

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

    Минусы: обслуживание этого варианта может быть очень дорогим и отнимать много времени.

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

    Плюсы: часто восстановление происходит довольно быстро.

    Минусы: обслуживание и настройка этого варианта могут быть очень дорогими.

Важно!

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

Восстановление с холодным резервированием

В сценарии восстановления с холодным резервированием вы настраиваете новую ферму в новом расположении (предпочтительно с использованием развертывания на основе скриптов) и восстанавливаете там резервные копии. Или же можно восстановить ферму, используя решение резервного копирования, такое как System Center 2016 Data Protection Manager (DPM) или System Center 2012 — Data Protection Manager (DPM). System Center Data Protection Manager защищает данные на уровне операционной системы компьютера и позволяет восстановить каждый сервер отдельно. В этой статье не представлены подробные инструкции для создания и восстановления в сценариях с холодным резервированием. Дополнительные сведения см. в таких статьях:

Восстановление с теплым резервированием

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

Виртуальные среды горячего резервирования

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

Можно создать виртуальные образы рабочих серверов и отправить их в резервный центр обработки данных. В этом случае необходимо убедиться, что виртуальные образы создаются достаточно часто для обеспечения актуальности контента и конфигурации фермы, необходимой для ее восстановления. В дополнительном расположении должна быть доступна среда, где можно легко настроить и подключить образы для воссоздания фермы. Дополнительные сведения см. в статье Развертывание SharePoint Server 2016 в Azure с использованием групп доступности AlwaysOn для SQL Server.

Восстановление с горячим резервированием

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

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

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

    Совет

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

  • Обновления для операционной системы, а также для SQL Server и SharePoint Server должны быть установлены в обеих фермах для обеспечения единообразия конфигурации.

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

    Примечание

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

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

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

Важно!

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

Избыточность приложений-служб

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

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

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

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

  • Приложение-служба может работать с базами данных только для чтения.

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

Системные требования для восстановления

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

  • версии операционной системы и все обновления;

  • версии SQL Server и все обновления;

  • версии SharePoint Server и все обновления.

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

  • полная избыточность питания, охлаждения, сети, каталогов и SMTP;

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

See also

Концепции высокой доступности и аварийного восстановления в SharePoint Server