Выбор стратегии аварийного восстановления для SharePoint Server
ОБЛАСТЬ ПРИМЕНЕНИЯ:
2013 2016 2019 Subscription Edition 
SharePoint в Microsoft 365
Мы определяем аварийное восстановление как возможность восстановления после ситуации, когда основной центр обработки данных, на котором размещена ферма SharePoint Server, не может продолжать работу. Вне зависимости от природы события и его причины сбой центра обработки данных достаточно серьезен, чтобы привести в действие план аварийного восстановления вашей организации. Это подразумевает активацию полноценной фермы с помощью вычислительных ресурсов, расположенных в центре обработки данных, не затронутых аварией.
Серверы SharePoint Server 2019, 2016, 2013 и серверы SQL Server, которые их поддерживают, предоставляют параметры конфигурации и восстановления содержимого, которые могут соответствовать целевому времени восстановления (RTO) и целевой точке восстановления (RPO), необходимым для вашей организации в случае аварии. Дополнительные сведения об этих и других понятиях аварийного восстановления см. в статье Концепции высокого уровня доступности и аварийного восстановления в SharePoint Server.
Введение
Эффективной стратегии аварийного восстановления для фермы SharePoint Server должно быть достаточно для удовлетворения бизнес-требований организации, которые обычно выражаются с помощью двух мер: целевого времени восстановления (RTO) и целевой точки восстановления (RPO). Требования RTO и RPO определяются на основе стоимости простоя организации в случае аварии.
Важно!
Мы рекомендуем четко определить RTO и RPO организации перед разработкой стратегии восстановления и реализации технического решения. Сконцентрируйтесь на том, что необходимо, а не на том, как это сделать.
Стоимость простоя может сильно варьироваться в различных отраслях, особенно из-за разного влияния простоя. Наиболее очевидным фактором является размер бизнеса. Однако это далеко не единственный фактор. Определение измерения означает выявление природы и последствий сбоя. Если говорить максимально просто, сбой критического приложения может привести к следующим последствиям:
Потеря службы приложения. Влияние на простой зависит от приложения и компании.
Потеря данных. Возможная потеря данных из-за сбоя системы может иметь значительные юридические и финансовые последствия.
Большинство организаций понесут ущерб от простоя в связи с двумя указанными выше потерями, но природа бизнеса определяет, какая из них приведет к наихудшим последствиям. В указанной далее статье, написанной Крисом Праймсбергером (Chris Preimesberger) для веб-сайта eWEEK, описаны финансовые последствия простоя центра обработки данных. Незапланированный простой ИТ-специалистов может стоить 5000 долл. США в минуту: отчет.
В большинстве случаев продукты SharePoint являются одним из нескольких приложений, которые необходимо восстановить в случае завершения работы центра обработки данных, что квалифицируется как авария. По этой причине мы не включили сведения о планировании аварийного восстановления, но сосредоточимся на вариантах, чтобы вы могли восстановить ферму SharePoint Server в другом расположении.
Независимо от типа и масштаба аварии для восстановления требуется резервный центр обработки данных, в котором можно развернуть ферму.
Варианты восстановления резервного центра обработки данных
Резервные центры обработки данных необходимы в тех случаях, когда избыточные системы и резервные копии не удается восстановить после сбоя в основном центре обработки данных. Время и усилия для развертывания фермы для замены в другом расположении часто описывают как "горячее", "теплое" и "холодное" резервирование. Мы определяем такие центры обработки данных следующим образом:
Холодное резервирование. Дополнительный центр обработки данных, которые обеспечивает доступность в течение нескольких часов или дней.
Теплое резервирование. Дополнительный центр обработки данных, которые обеспечивает доступность в течение нескольких минут или часов.
Горячее резервирование. Дополнительный центр обработки данных, которые обеспечивает доступность в течение нескольких секунд или минут.
Каждый из таких резервных центров обработки данных обладает уникальными характеристиками и требованиями. С ними также связаны определенные расходы на эксплуатацию и обслуживание.
Стратегия аварийного восстановления с холодным резервированием: компания регулярно отправляет резервные копии для поддержки восстановления исходного состояния в локальные и региональные хранилища, у нее заключены контракты для экстренной аренды серверов в другом регионе.
Плюсы: Часто самый дешевый вариант обслуживания, в оперативном режиме. Часто это дорогой вариант для восстановления, так как для него требуется, чтобы физические серверы были после аварии правильно настроены.
Минусы: самый медленный вариант восстановления.
Стратегия аварийного восстановления с горячим резервированием с использованием Azure Site Recovery.
Плюсы: часто этот вариант относительно недорого обходится при восстановлении, так как виртуальную ферму серверов можно довольно быстро и легко настроить.
Минусы: обслуживание этого варианта может быть очень дорогим и отнимать много времени.
Стратегия аварийного восстановления с горячим резервированием: компания использует несколько центров обработки данных, но предоставляет контент и службы только через один из них.
Плюсы: часто восстановление происходит довольно быстро.
Минусы: обслуживание и настройка этого варианта могут быть очень дорогими.
Важно!
Независимо от выбранного решения аварийного восстановления, определенных потерь данных избежать нельзя.
Восстановление с холодным резервированием
В сценарии аварийного восстановления в холодном режиме ожидания восстановление выполняется путем настройки новой фермы в новом расположении (желательно с помощью развертывания с помощью сценария) и восстановления резервных копий. Вы также можете восстановить ферму с помощью решения резервного копирования, например System Center Data Protection Manager (DPM). DPM защищает данные на уровне операционной системы компьютера и позволяет восстанавливать каждый сервер по отдельности. В этой статье не представлены подробные инструкции для создания и восстановления в сценариях с холодным резервированием. Дополнительные сведения см. в разделе:
Общие сведения о резервном копировании и восстановлении в SharePoint Server
Планирование резервного копирования и восстановления в SharePoint Server
Восстановление с теплым резервированием
В сценарии восстановления с теплым резервированием создается среда теплого резервирования — копия фермы в другом центре обработки данных, которая регулярно обновляется с использованием полных и добавочных резервных копий основной фермы.
Виртуальные среды горячего резервирования
Виртуализация является применимым и экономичным вариантом для решения по восстановлению с теплым резервированием. Вы можете использовать Hyper-V как локальное решение или Azure как размещенное решение для получения инфраструктуры, необходимой для восстановления. Дополнительные сведения см. в статье Развертывание SharePoint Server с группами доступности AlwaysOn SQL Server в Azure.
Восстановление с горячим резервированием
В сценарии восстановления с горячим резервированием вы настраиваете отказоустойчивую ферму в резервном центре обработки данных, чтобы возобновить работу почти сразу же после сбоя основной фермы. Среда с отдельной отказоустойчивой фермой обладает следующими характеристиками:
В отказоустойчивой ферме должны размещаться отдельная база данных конфигурации и база данных контента Веб-сайт центра администрирования SharePoint.
Все настройки должны быть развернуты на обеих фермах.
Совет
Две фермы согласованы. Чтобы снизить вероятность возникновения ошибок, мы рекомендуем использовать развертывание на основе скриптов, чтобы создать основную и дополнительную ферму с одинаковыми параметрами конфигурации и настройками.
Обновления для операционной системы, а также для SQL Server и SharePoint Server должны быть установлены в обеих фермах для обеспечения единообразия конфигурации.
Вы можете скопировать базы данных контента SharePoint Server в ферму отработки отказа, используя асинхронное зеркальное отображение, асинхронную фиксацию в реплике группы доступности или доставку журналов.
Примечание.
Зеркальное отображение SQL Server можно использовать только для копирования баз данных на один зеркальный сервер, но доставку журналов можно выполнить на несколько дополнительных серверов.
Функция зеркального отображения базы данных SQL Server будет удалена в будущих версиях. Рекомендуется избегать использования этой функции в новых развертываниях. Запланируйте изменение приложений, которые используют его в данный момент. Вместо этого используйте группы доступности AlwaysOn.
Некоторые приложения-службы можно переместить в ферму с помощью доставки журналов, а некоторые — нет. Дополнительные сведения см. в разделе Избыточность приложений службы далее в этой статье.
Топологию фермы горячего резервирования можно использовать в нескольких центрах обработки данных, если настроить доставку журналов SQL Server в один или несколько центров обработки данных.
Важно!
При использовании отработки отказа для аварийного восстановления основными факторами являются полоса пропускания и задержка сети. Рекомендуется проконсультироваться с поставщиком SAN, чтобы определить, можно ли использовать репликацию SAN для баз данных SQL или другой поддерживаемый механизм для обеспечения уровня доступности в центрах обработки данных в режиме горячего ожидания. Обратите внимание, что использование репликации SAN для серверов SharePoint не поддерживается.
Избыточность приложений-служб
Чтобы обеспечить доступность приложений-служб в различных центрах обработки данных, мы рекомендуем использовать для служб, которые могут работать в разных фермах, отдельную ферму, доступную в основном и дополнительном центре обработки данных.
Чтобы обеспечить доступность служб, которые не могут работать в разных фермах, и самой фермы служб, применяются различные стратегии избыточности в центрах обработки данных. Используемая стратегия зависит от следующих факторов:
Работа приложения-службы в ферме аварийного восстановления (когда она не используется) имеет ценность для бизнеса.
Базы данных, связанные с приложением-службой, можно перемещать с помощью доставки журналов, асинхронного зеркального отображения или асинхронной фиксации.
Приложение-служба может работать с базами данных только для чтения.
Перед созданием решения аварийного восстановления, использующего центр обработки данных с теплым или горячим резервированием, прочитайте статью Поддерживаемые варианты обеспечения высокой доступности и аварийного восстановления для баз данных SharePoint.
Системные требования для восстановления
В идеальной ситуации резервные компоненты и системы полностью совпадают с основными компонентами и системами: платформа, оборудование и серверы. Как минимум, резервная среда должна обрабатывать тот объем трафика, который предполагается во время отработки отказа. Помните, что в некоторых случаях резервный сайт может обслуживать только часть пользователей. В основных и резервных системах должны по крайней мере совпадать следующие компоненты:
версии операционной системы и все обновления;
версии SQL Server и все обновления;
версии SharePoint Server и все обновления.
В дополнение к предыдущим требованиям время восстановления фермы также зависит от доступности среды и компонентов инфраструктуры. Убедитесь, что выполняются следующие требования:
полная избыточность питания, охлаждения, сети, каталогов и SMTP;
выберите механизм переключения на основе ваших потребностей: балансировка нагрузки на основе DNS или аппаратная балансировка нагрузки.
См. также
Понятия
Концепции высокой доступности и аварийного восстановления в SharePoint Server
Другие ресурсы
Какие рабочие нагрузки можно защитить с помощью Azure Site Recovery?