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

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

На самом деле существует много ответов на эти вопросы и целый ряд способов подготовки решений аварийного восстановления для SharePoint (локальная версия). Некоторые из средств, с которыми мне довелось работать в последнее время, основаны на распределенной ферме SharePoint и используют группы доступности SQL Server в нескольких центрах обработки данных, чтобы просто создать «холодную» или «теплую» резервную ферму в другом центре обработки данных для отработки сбоя основной фермы. У каждого варианта есть свои достоинства, но один способ, который быстро завоевывает популярность, особенно среди пользователей SharePoint 2013 и SharePoint 2016, — переместить решение аварийного восстановления в «облако» Microsoft Azure. Это позволяет освободить ресурсы сервера для размещения локальной версии и получить преимущества «облачной» службы.

Какие же существуют варианты аварийного восстановления SharePoint с использованием Microsoft Azure?

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

1. Службы инфраструктуры Azure:

• горячее восстановление;
• теплое восстановление;
• холодное восстановление.

2. Служба Azure Site Recovery.

Эти два основных варианта обеспечивают большую гибкость при выборе решения.

Службы инфраструктуры Azure

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

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

1. Локальная производственная ферма SharePoint.
2. Производственная ферма восстановления SharePoint в Microsoft Azure.
3. VPN-соединение типа «сеть-сеть» между двумя фермами SharePoint.

Примерная структура, одобренная Microsoft, может быть простой, как показано на рисунке.

Рисунок. Пример структуры служб для выполнения восстановления

Главное здесь — пропускная способность канала и VPN-соединение между двумя расположениями. С помощью Azure ExpressRoute можно создать частные подключения между центрами обработки данных Azure и инфраструктурой в компании или в среде совместной работы. Подключения ExpressRoute не проходят через общедоступный Интернет. Они отличаются более высокой надежностью, быстродействием, меньшими задержками и лучшей защищенностью по сравнению с обычными подключениями к Интернету. В некоторых случаях использование подключений ExpressRoute для пересылки данных между локальными системами и Azure дает значительную экономию. ExpressRoute обеспечивает быстрое и надежное подключение к Azure, полезное в таких случаях, как периодический перенос данных, репликация в целях устойчивого функционирования компании, аварийное восстановление и другие ситуации, требующие высокой доступности. Такой вариант может быть выгоден для пересылки больших объемов данных, например наборов данных для высокопроизводительных вычислительных приложений или перемещения больших виртуальных машин между средами разработки и тестирования в виртуальном частном «облаке» Azure и вашей локальной производственной средой.

Благодаря использованию Express­Route подход Microsoft Azure не просто приемлем, но даже напрашивается вопрос: почему мы не используем его до сих пор?

Для этого подхода служба репликации распределенной файловой системы DSFR (https://msdn.microsoft.com/en-us/library/bb540031(v=vs.85).aspx) должна быть реализована как локально, так и в инфраструктуре аварийного восстановления. DSFR обеспечивает перемещение файлов базы данных и т. д. из одного расположения в другое. Это уменьшает необходимость внедрения таких технологий, как репликация SQL Server. Результатом будут более высокая производительность и четкий контроль над процессом отработки сбоя в работе фермы.

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

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

• Аварийное восстановление с холодным резервированием.

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

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

Недостатки: самое медленное восстановление.

• Аварийное восстановление с теплым резервированием.

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

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

Недостатки: обслуживание может быть очень дорогостоящим и требовать больших затрат времени.

• Аварийное восстановление с горячим резервированием.

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

Преимущества: восстановление выполняется довольно быстро.

Недостатки: настройка и обслуживание могут быть дорогостоящими.

Дополнительную информацию можно найти в статье по адресу: https://technet.microsoft.com/en-us/library/ff628971.aspx

Если вы придете к выводу о предпочтительности более автоматизированного подхода, то компонент Azure Site Recovery (ASR) может оказаться подходящим вариантом. Site Recovery — превосходный способ, но потребуется приложить усилия для его настройки.

С помощью Azure Site Recovery можно развернуть решения доступности по требованию с учетом приложений. Будь то приложения на основе Windows Server или Linux, собственные корпоративные приложения Microsoft или продукты других поставщиков, вы можете использовать Azure Site Recovery, чтобы включить аварийное восстановление, развернуть среду разработки и тестирования по требованию или перенести ее в Azure. Технологии репликации ASR позволяют защитить целую виртуальную машину со всеми дисками и данными. Это обеспечивает совместимость с любыми приложениями, запускаемыми на машине. Преимуществами ASR могут воспользоваться такие приложения, как SharePoint, Exchange, Dynamics, SQL Server.

Как работает Azure Site Recovery

Локальная производственная среда может состоять из физических или виртуальных машин, так как ASR защитит их. Настроив конфигурацию среды, вы можете подготовить ASR для создания моментальных снимков производственных серверов. Они формируются как файлы виртуального жесткого диска (VHD). Примечательно, что ASR поддерживает не только стек продуктов Microsoft, например Hyper-V или физический сервер, но и VMWare как защищаемую производственную среду.

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

Настройка параметров между двумя сайтами выполняется на основе репликации текущей среды Active Directory на вспомогательном сайте или за счет ввода дополнительного контроллера домена в отказоустойчивый сайт.

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

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

Вы можете получить дополнительную документацию от компании Microsoft по адресу: https://gallery.technet.microsoft.com/SharePoint-DR-Solution-f6b4aeae.

Рекомендации по развертыванию служб аварийного восстановления с использованием Microsoft Azure Site Recovery можно найти в презентации по адресу: https://channel9.msdn.com/Events/Ignite/2015/BRK3503

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