5/5 - (2 голоса)

Какая часть компании является самой важной в наши дни? Отдел продаж? Управление? Разработчики? Точно никто не скажет. Но реальность такова, что ни одна из перечисленных групп не является незаменимой, может возникнуть лишь некоторое неудобство, если ключевой член команды уходит и его заменяют другим сотрудником. Если ваша ИТ-структура катится в тартарары, едва ли найдется компания, которая сможет поддерживать ее работо­способность, так как зависимость предприятий от ИТ только увеличивается. По этой причине у каждой компании либо уже предусмотрены процедуры вос­становления после аварийных ситуаций Disaster Recovery (DR), либо компания присматривается к тому, чтобы получить DR, но пока это дорого. Центры обработки данных, подключения, серверы, охлаждение, лицензии, элек­тропитание и многое другое— все это, как вы надеетесь, никогда не потребуется. Это весьма дорогой «ремень безопасности». Было бы здорово иметь какой-нибудь сер­вер, за который вы платите только тогда, когда реально используете его, то есть что-то, оплачиваемое по потребности.

Разработка и реализация стратегии построения отказоустойчивых, быстро восстанавливающихся систем, [email protected]

Кроме шуток: большая часть «облачных» служб оплачива­ется по мере использования, они весьма привлекательны для применения в качестве решения DR. Существуют определенные повседневные эксплуатационные издержки, такие как система хранения, лицензирование и, может быть, некоторые приложения (виртуальные машины) для ключевых рабочих процессов. Но вы платите только за те прикладные приложения, которые вам реально приходится запускать в случае вос­становления после отказа в работе либо в режиме реального времени, либо в тестовом варианте.

Лучше всего я знаком с «облачными» службами Microsoft, поэтому хочу посмотреть, как можно использовать «облачные» службы этой компании для обычных сред. Суть в том, чтобы не думать о выборе какой-либо одной среды, это всеобъемлющее решение. Выберите подходящее решение для каждого приложения, а затем продумайте, как автоматизировать процесс вос­становления после отказа. Но ­пре­жде чем рассматривать восстанов­ление после сбоя как «облачную» службу, давайте посмотрим, как процедуры восстановления после сбоя выполнялись бы между разными местоположениями в локаль­ных сетях.

Прежде всего, выполняется обсле­дование важных для бизнеса систем, выясняется, от чего зависят эти системы (поскольку им приходит­ся быть взаимозависимыми), опре­деляются различные требования к доступности, включая то, какдолго они могут быть недоступны (опре­деляется целевое время восста­новления, Recovery Time Objective) и то, как много данных может быть утеряно (определяется целе­вая точка восстановления. Recovery Point Objective). Первое представ­ление может быть таким: «систе­ма должна быть доступной через 30 секунд, и я не могу потерять дан­ные». Но в реальности достижение этой цели может обойтись в 500 тыс. долл, в год, тогда как 15-минутная остановка в работе и потеря данных за последниие 5 минут будут стоить компании лишь 5 тыс. долл, от уте­рянного объема продаж. Не самое лучшее вложение.

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

  1. Репликация на уровне при­ложений, вроде SQL AlwaysOn, репликации между несколькими основными контроллерами доме­на, группы доступности Exchange Database Availability Groups и т.д. Имея под рукой эти технологии, вы получите полную видимость состояния репликации, контроль над репликациями, а приложе­ния будут защищены от любых отказов.
  2. Репликация внутри гостевой операционной системы или репликация на уровне гиперви­зора, которая может дополни­тельно подключиться к службе мгновенных снимков VSS, чтобы предоставить периодические точки восстановления для при­ложений (экземпляры на опре­деленный момент времени для защищаемого прикладного при­ложения, которые могут быть восстановлены вместо недавнего состояния прикладного прило­жения).
  3. Репликация на уровне хранили­ща данных.
  4. Восстановление из резервной копии.

Кроме того, возможен другой вариант, который часто оставляют без внимания, но его место в этом списке зависит от различных условий. Некоторые прикладные приложения не имеют фиксируемого состояния. Подумайте о ферме из 50 веб-серверов, работающих на IIS. Они просто обслуживают запросы, а актуальные данные сохраняются в базе данных. Я не беспокоюсь о состоянии веб-серверов. Таким образом, вместо резервного копирования у меня есть образ сервера IIS или настройки режима DSC для PowerShell, которые в случае аварии создают новую ферму из 50 серверов по шаблону. Такой подход позволяет избежать любого резервного копирования и производить запуск так же быстро, как и активацию процесса создания новых 50 экземпляров.

Кроме того, затраты очень отличаются, а увеличение затрат зависит от использования «облака», оплачиваемого при его применении в качестве целевой системы.

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

Теперь, при наличии «облака», стали доступны различные типы служб. Существуют виртуальные машины, работающие по принципу «инфраструктура как служба», Infrastructure as a Service; службы, предоставляющие платформы по модели Platform as a Service, однако они требуют, чтобы приложения были написаны для модели PaaS. Последнего, вероятно, нет в большинстве организаций, но ситуация изменится с появлением Azure Stack. Также существует служба про­граммного обеспечения, работающая по модели Software as a Service, такая как Office 365. Сегодня что-то типа Office 365 в случае аварийной ситуации используется редко, однако выполненный ранее переход к Office 365 не оставляет сомнений в эффективности этой службы во время аварийной ситуации. Если Exchange, SharePoint и т.д. пере­мещаются в «облако», то в случае аварийной ситуации вам не только не придется беспокоиться об этих службах, но они станут жизненно важными службами коммуника­ции, на которые вы сможете положиться и которые будут использо­ваться во время процесса восста­новления после сбоя.

Теперь давайте сосредоточимся на службах IaaS, которые обеспечи­вают использование виртуальных машин в «облаке». К «облаку» применимы те же самые варианты, что существуют для локальных сетей, но разница в затратах огромна. На уровне приложения виртуальная машина должна запускаться в Azure для того, чтобы использо­вать возможность репликации. Это означает возникновение издержек и ассоциированного хранилища данных, но дает наилучшую управ­ляемость и репликации. Это был бы хороший вариант для самых критичных баз данных, которые являются особо важными для деятель­ности компании, где дополнитель­ные затраты оправдываются, если нужен полный контроль и обзор репликации, а также обеспечение очень быстрого восстановления после аварийной ситуации и наименьшая потеря данных.

Можно использовать и другое средство для репликации. В Azure это служба Azure Site Recovery, которая отвечает за репликации на уровне гипервизора для виртуальных машин Hyper-V и репликации уровня гостевой операци­онной системы для виртуальных машин ESX и физических систем. Для применения этой технологии требуется лицензия ASR, которая выдается на каждую защищаемую копию операционной системы на месяц (также ее можно купить как часть комплекта Operations Management Suite) плюс хранилище данных, но здесь сложно посчитать издержки за вычислительные ресурсы до тех пор, пока вы реально не выполните восстановление после аварийной ситуации. Они не будут определены, пока не будут учтены издержки на ресурсы, основанные на Azure.

Уровень хранилища данных может использоваться для таких устройств, как StorSimple, которое представляет собой специализи­рованную систему, использующую Azure в качестве дополнительного уровня хранения данных как наи­менее доступное хранилище плюс хранилище данных для полных снимков экрана всего содержимого. В случае аварийной ситуации в Azure можно запустить виртуаль­ный StorSimple и предоставить данные. Повседневные эксплуатаци­онные издержки возможны только за хранилище данных в Azure. Кроме того, существует вариант простого развертывания виртуальных машин по шаблону, где состояние не является проблемой, и именно этим удобны менеджер Azure Resource Manager и наборы масштабирования VM Scale Sets. За 5 минут я могу развернуть 100-узловую ферму I IS без пред­варительных затрат на эксплуата­цию, если не принимать во внимание размещение на хосте одного образа шаблона.

Таким образом, мы имеем целый ряд вариантов. Я использую различные технологии, поэтому в случае настоящей аварийной ситуации мой план восстановления будет сложным, со множеством шагов в разных системах. Azure Site Recovery предоставляет при­мер плана восстановления. План восстановления создается заранее, в нем определяется порядок вос­становления отказавших машин. PowerShell можно вызвать через Azure Automation, интегро рация с SQL AlwaysOn доступна, можно даже добавить шаг ожидания для мани­пуляций вручную, если нужно привести в действие что-либо во время реальной аварийной ситуации. Это занимает время, но в случае реальной аварийной ситуации выполняется одно задание, которое управляет всем процессом обработки отказа в работе (и последующим возвратом к состоянию до момента сбоя). Это важно в случае стрессовой аварийной ситуации, когда от сотрудников нельзя ожидать, что они будут выполнять какие- либо шаги вручную. Такая же технология используется для тестового прогона процесса обработки отказа в работе, но резервные копии развертываются в изолированной сети, чтобы она не пересекалась с производственной средой.

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