Какая часть компании является самой важной в наши дни? Отдел продаж? Управление? Разработчики? Точно никто не скажет. Но реальность такова, что ни одна из перечисленных групп не является незаменимой, может возникнуть лишь некоторое неудобство, если ключевой член команды уходит и его заменяют другим сотрудником. Если ваша ИТ-структура катится в тартарары, едва ли найдется компания, которая сможет поддерживать ее работоспособность, так как зависимость предприятий от ИТ только увеличивается. По этой причине у каждой компании либо уже предусмотрены процедуры восстановления после аварийных ситуаций Disaster Recovery (DR), либо компания присматривается к тому, чтобы получить DR, но пока это дорого. Центры обработки данных, подключения, серверы, охлаждение, лицензии, электропитание и многое другое— все это, как вы надеетесь, никогда не потребуется. Это весьма дорогой «ремень безопасности». Было бы здорово иметь какой-нибудь сервер, за который вы платите только тогда, когда реально используете его, то есть что-то, оплачиваемое по потребности.
Разработка и реализация стратегии построения отказоустойчивых, быстро восстанавливающихся систем, [email protected]
Кроме шуток: большая часть «облачных» служб оплачивается по мере использования, они весьма привлекательны для применения в качестве решения DR. Существуют определенные повседневные эксплуатационные издержки, такие как система хранения, лицензирование и, может быть, некоторые приложения (виртуальные машины) для ключевых рабочих процессов. Но вы платите только за те прикладные приложения, которые вам реально приходится запускать в случае восстановления после отказа в работе либо в режиме реального времени, либо в тестовом варианте.
Лучше всего я знаком с «облачными» службами Microsoft, поэтому хочу посмотреть, как можно использовать «облачные» службы этой компании для обычных сред. Суть в том, чтобы не думать о выборе какой-либо одной среды, это всеобъемлющее решение. Выберите подходящее решение для каждого приложения, а затем продумайте, как автоматизировать процесс восстановления после отказа. Но прежде чем рассматривать восстановление после сбоя как «облачную» службу, давайте посмотрим, как процедуры восстановления после сбоя выполнялись бы между разными местоположениями в локальных сетях.
Прежде всего, выполняется обследование важных для бизнеса систем, выясняется, от чего зависят эти системы (поскольку им приходится быть взаимозависимыми), определяются различные требования к доступности, включая то, какдолго они могут быть недоступны (определяется целевое время восстановления, Recovery Time Objective) и то, как много данных может быть утеряно (определяется целевая точка восстановления. Recovery Point Objective). Первое представление может быть таким: «система должна быть доступной через 30 секунд, и я не могу потерять данные». Но в реальности достижение этой цели может обойтись в 500 тыс. долл, в год, тогда как 15-минутная остановка в работе и потеря данных за последниие 5 минут будут стоить компании лишь 5 тыс. долл, от утерянного объема продаж. Не самое лучшее вложение.
Существуют многочисленные методы защиты прикладных приложений, которые можно перечислить в таком порядке предпочтений:
- Репликация на уровне приложений, вроде SQL AlwaysOn, репликации между несколькими основными контроллерами домена, группы доступности Exchange Database Availability Groups и т.д. Имея под рукой эти технологии, вы получите полную видимость состояния репликации, контроль над репликациями, а приложения будут защищены от любых отказов.
- Репликация внутри гостевой операционной системы или репликация на уровне гипервизора, которая может дополнительно подключиться к службе мгновенных снимков VSS, чтобы предоставить периодические точки восстановления для приложений (экземпляры на определенный момент времени для защищаемого прикладного приложения, которые могут быть восстановлены вместо недавнего состояния прикладного приложения).
- Репликация на уровне хранилища данных.
- Восстановление из резервной копии.
Кроме того, возможен другой вариант, который часто оставляют без внимания, но его место в этом списке зависит от различных условий. Некоторые прикладные приложения не имеют фиксируемого состояния. Подумайте о ферме из 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, контейнеры, получение пользователями доступа к службам во время аварийной ситуации. И это еще далеко не полный список.