Выпускная квалификационная работа. Разработка методологии автоматического аварийного восстановления гибридной инфраструктуры в Microsoft Azure (стр. 3 )

Рисунок 3

Полное восстановление

При повторном развертывании в дополнительном регионе приложения и базы данных содержатся только в основном регионе. Дополнительный регион не настроен для автоматической отработки отказа. Поэтому при сбое все компоненты службы необходимо развернуть в новом регионе. При этом нужно добавить облачную службу в Azure, развернуть облачную службу, восстановить данные и изменить DNS для перенаправления трафика.

Хотя это и самый доступный вариант для нескольких регионов, он предполагает максимальное целевое время восстановления. В этой модели резервные копии пакета службы и базы данных сохраняются локально или в экземпляре хранилища BLOB-объектов Azure в дополнительном регионе. Тем не менее, до возобновления работы нужно развернуть новую службу и восстановить данные. Даже если полностью автоматизировать передачу данных из хранилища резервных копий, развертывание новой среды базы данных занимает много времени. Перенос данных из дискового хранилища резервных копий в пустую базу данных в дополнительном регионе — самый дорогостоящий этап восстановления. Тем не менее, его нужно выполнить, чтобы запустить новую базу данных, так как она не реплицируется.

Лучше всего хранить пакеты службы в хранилище BLOB-объектов в дополнительном регионе. Это устраняет необходимость передавать пакет в Azure, что происходит при развертывании из локального компьютера разработки. Вы можете быстро развернуть пакеты службы в новой облачной службе из хранилища BLOB-объектов, используя сценарии PowerShell.

Сценарий PowerShell представляет из себя программный код на языке PowerShell исполняемый в среде ОС Windows. (Аналог скриптового языка Bash для операционных систем Linux)

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

Общую схему полного восстановления можно увидеть на рисунке 4.

 

Рисунок 4

Гибридное аварийное восстановление

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

Автоматизация

Некоторые рассмотренные шаблоны требуют быстрой активации автономных развертываний, а также восстановления определенных компонентов системы. Автоматизация и написание сценариев поддерживают возможность активации ресурсов по запросу и быстрого развертывания решений. Автоматизация, связанная с аварийным восстановлением, выполняется в Azure PowerShell, но также можно использовать и REST API3 управления службами.

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

Чтобы автоматизировать эту задачу, рекомендуется создать репозиторий сценариев PowerShell или сценариев интерфейса командной строки по аварийному восстановлению Azure.

Для автоматизации процессов в Azure используется инструмент “Runbook”, который представляет собой объект, содержащий сценарий PowerShell и различные конфигурации для этого сценария. Сам объект Runbook использует модули Runbook, чтобы он мог взаимодействовать со средой Azure. Модули Runbook реализуют основные функции службы автоматизации Azure. Они выступают в роли контейнеров для пользовательских сценариев и рабочих процессов. Кроме того, модули Runbook обычно имеют ссылки на ресурсы службы автоматизации, такие как учетные данные, переменные, подключения и сертификаты. Они также могут содержать другие модули Runbook, что позволяет создавать более сложные рабочие процессы. Вызывать и запускать модули Runbook можно как по требованию, так и в соответствии с выбранным расписанием.

Для автоматизации с помощью PowerShell следует выбирать, так называемый PowerShell Wokflow. Это надстройка над данным языком, которая добавляет множество различных функций, таких как например распараллеливание. Данная функция будет очень полезна для целей этой дипломной работы, так как значительно ускорит обработку данных и действия, которые будут совершаться с помощью инструментов автоматизации.

Обнаружение сбоев

Чтобы устранять проблемы доступности и выполнять аварийное восстановление должным образом, необходимо иметь возможность выявления и диагностики сбоев. Чтобы быстро узнавать о внезапном сбое системы или ее частей, необходимо внедрить расширенный мониторинг серверов и развертываний. Частично это задание могут выполнять средства мониторинга, которые отслеживают общую работоспособность облачной службы и ее зависимых компонентов. Одно из таких средств Майкрософт — System Center 2016. Возможности мониторинга могут также предоставлять сторонние средства. Большинство решений мониторинга отслеживают основные счетчики производительности, а также доступность службы.

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

Как работает аварийное восстановление в Azure сейчас

Компания Microsoft гарантирует, что все ваши данные, в случае если вы настроили их репликацию в другой ЦОД4, будут восстановлены. Давайте рассмотрим подробнее, какие условия должны быть выполнены, чтобы инфраструктура могла быть восстановлена после аварии в основном ЦОД:

Должны быть использованы хранилища с автоматической репликацией в другой ЦОД. Так называемые «гео-избыточные» хранилища. Необходима команда инженеров, которые смогут быстро восстановить всю инфраструктуру с нуля, причем количество инженеров растет с количеством серверов и сервисов в инфраструктуре.

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

После исследования технологий и методов развертывания серверов в облаке Azure было выяснено, что на разворачивание одного сервера уходит около 10 минут. Это означает, что при владении инфраструктурой в 1000 серверов будет потрачено около 167 часов, что неприемлемо для современного бизнеса. Конечно, можно нанять 10 инженеров, которые смогут восстановить систему за 16,7 часов, что тоже довольно долго. При этом стоит учитывать и человеческий фактор, то есть при работе инженеров, могут быть допущены ошибки, что еще больше увеличит время восстановления.

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

Потери

На данный момент существует множество крупных компаний, которые используют облачные технологии, в частности Microsoft Azure как в России, так и за рубежом. Для крупных компаний каждый час простоя инфраструктуры может стоить десятки тысяч долларов. При расчете в пятьдесят тысяч долларов в час можно посчитать, что компания потеряет за 10 часов простоя полмиллиона долларов. При этом такое количество времени простоя вполне реально при нынешней системе восстановления. Плюс к этим финансовым потерям можно прибавить затраты на системных инженеров, которые будут заниматься восстановлением инфраструктуры. Если говорить о России, то достаточно квалифицированный инженер будет стоить от 300-400 рублей/час. За рубежом стоимость таких инженеров гораздо выше. Конечно, эта стоимость несравнима с финансовыми потерями компании, но и на этом можно сэкономить в случае автоматизации аварийного восстановления.

Система аварийного восстановления с использованием инструментов Azure и Powershell

В данной главе будет конкретно рассмотрена система аварийного восстановления с помощью инструментов Azure и языка сценариев – Powershell.

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

В этой работе будут использованы следующие виртуальные машины (ниже приведены их имена) в облаке Azure:

DRDC01 – Контроллер домена в первом ЦОД DRDC02 – Контроллер домена во втором ЦОД ConfServer – сервер конфигурации, который будет использован для репликации данных в облако Client01 – один из серверов, используемых в инфраструктуре Client02 – один из серверов, используемых в инфраструктуре

К сожалению, бесплатное использование Azure ограничено по количеству ресурсов, которые можно использовать. Именно по этой причине в данной работе используется необходимый минимум серверов, для реализации и тестирование этой системы. Также будут использованы сервера развернутые на базе VMWare локально. Они будут рассматриваться как сервера (виртуальные машины), находящиеся в демилитаризованной зоне, то есть не входящие в домен. Локально также развернут сервер конфигурации, благодаря которому происходит репликация в облако, во второй ЦОД.

На следующем рисунке можно увидеть верхнеуровневую схему всей системы: