Начать эту статью я хочу с трех ключевых вопросов, ответы на которые нам необходимо получить, приступая к теме аварийного восстановления. Как вы готовитесь к аварийному восстановлению 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. А также существует более сложное, но, на мой взгляд, лучшее решение для полного восстановления сайта, обеспечивающее самую надежную защиту.

ПАО «Банк «Санкт-Петербург» выбирает DeviceLock

Один из крупнейших региональных банков России ПАО «Банк «Санкт-Петербург» основан в 1990 году. Банк осуществляет свою деятельность на территории Санкт-Петербурга, Ленинградской области, Москвы, Калининграда.

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

В банке используется гетерогенная информационная среда, организационная структура управления ИТ создана в соответствии с рекомендациями ITIL и основными мировыми практиками. Управление по обеспечению информационной безопасности в дирекции по безопасности осуществляет контроль деятельности более чем 2500 сотрудников. Модель системы информационной безопасности банка основана на процессном подходе к построению СИБ для противодействия актуальным угрозам ИБ, определенным с применением экспертного подхода.

Программный продукт DeviceLock используется в Банке «Санкт-Петербург» с 2012 года для защиты конфиденциальной информации и контроля подключения внешних устройств к персональным компьютерам. Для эффективной эксплуатации системы в банке были своевременно разработаны инструкции, регламентирующие работу его подразделений в отношении сопровождения программного обеспечения и предоставления доступа.

«Для выбора оптимального решения задачи противодействия утечкам через внешние устройства нами был реализован пилотный проект с привлечением основных игроков на рынке контроля периферийных устройств, — рассказывает начальник управления по обеспечению информационной безопасности банка Анатолий Валентинович Скородумов. — DeviceLock показал себя как надежное программное обеспечение с простой моделью внедрения. В итоге была реализована гибкая модель управлением доступом к внешним устройствам с использованием групповых политик, при этом все работы по внедрению были выполнены собственными силами».

Дополнительная литература

  • SharePoint Disaster Recovery to Microsoft Azure: https://www.microsoft.com/en-us/download/details.aspx?id=41993
  • What workloads can you protect with Azure Site Recovery: https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-workload

 

Купить номер с этой статьей в PDF