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

Виртуальные машины

Azure предоставляет три вида услуг:

IaaS (Infrastructure as a Service) – инфраструктура как услуга PaaS (Platform as a Service) – платформа как услуга SaaS (Software as a Service) – программное обеспечение как услуга

Центральным объектом аварийного восстановления является виртуальная машина, которая представляет собой реализацию первого вида услуги – IaaS.
Виртуальная машина IaaS включает в себя как саму виртуальную машину, так и диск виртуальной машины.

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

Использование служб архивации Azure для создания согласованных межрегиональных резервных копий приложения.

С помощью службы архивации Azure (Azure Backup) пользователи могут создавать согласованные резервные копии приложения с нескольких дисков виртуальных машин и поддерживать репликацию резервных копий по регионам. Для этого при создании хранилища резервных копий для него нужно выбрать георепликацию1. Она используется для восстановления данных в случае невозможности использования основного региона.

Разделение диска данных и диска операционной системы.

Важным аспектом использования виртуальных машин IaaS является невозможность внесения изменений в конфигурацию диска операционной системы без повторного создания виртуальной машины. При таком подходе не возникнет проблем, если стратегия восстановления заключается в повторном развертывании после аварии. Тем не менее, это может стать проблемой, если используется подход "теплой замены" для резервной мощности. Для того чтобы правильно реализовать этот подход, и в основном, и в дополнительном расположениях должен быть развернут правильный диск операционной системы, а данные приложений должны храниться на отдельном диске.

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

Диски виртуальных машин реализуются в виде больших двоичных объектов (BLOB-объектов)2 службы хранилища Azure и имеют одинаковые характеристики георепликации. Если служба архивации Azure не используется, нет гарантий согласованности между дисками, так как георепликация выполняется асинхронно, и диски реплицируются независимо друг от друга. При сбое отдельные диски виртуальных машин гарантированно будут в состоянии отказоустойчивости после географической отработки отказа, но они не будут согласованы между собой. В некоторых случаях (например, в случае чередования дисков) это может вызвать проблемы. Иными словами, для полного и корректного восстановления виртуальных машин Azure, необходимо не только использовать георепликацию отдельных дисков, но также и службу архивации (Azure Backup).

Базы данных

База данных SQL

База данных SQL Azure предоставляет два типа восстановления данных: геовосстановление и активная георепликация.

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

Функция геовосстановления также доступна для баз данных уровней "Базовый", "Стандартный" и "Премиум". Она используется по умолчанию, когда база данных недоступна из-за происшествия в регионе, где она размещена. Как и функция восстановления до точки во времени, геовосстановление использует резервные копии базы данных из геоизбыточного хранилища Azure. Восстановление выполняется на основе резервной копии из удаленного хранилища, что позволяет защитить базу данных от сбоев в основном регионе.

Активная георепликация

Активная георепликация доступна для всех уровней баз данных. Она рассчитана на приложения, которые предъявляют более высокие требования к восстановлению по сравнению с теми, которые может обеспечить обычное геовосстановление. Активная георепликация позволяет создавать до четырех доступных для чтения реплик баз данных на серверах в разных регионах. Отработку отказа можно выполнить на любую из баз данных-получателей. Кроме того, активная георепликация применяется при обновлении приложений и их перемещении, а также для балансировки нагрузки (распределения операций чтения).

Подходы к аварийному восстановлению

В предыдущей главе мы рассмотрели 3 подхода к аварийному восстановлению в Azure:

Активный - активный Активный – пассивный Полное восстановление

Далее будет представлено более подробное описание каждой схемы.

Активный - активный (active/active)

В данном случае мы работаем по следующей схеме (рисунок 1):

 

Рисунок 1

Приложение, которое использует эту инфраструктуру должно быть устроено так, что все данные (трафик) делятся между двумя регионами Azure. То есть в обоих регионах развернута одинаковая инфраструктура: сервера, сетевые настройки, хранилища и т. д. Данная схема максимально отказоустойчива, так как не требуется дополнительного времени для развертывания/включения одной инфраструктуры при падении другой. Конечно, как и в других подходах, существует основной регион, к которому обращаются пользователи, и дополнительный. Отличие от подхода «активный-пассивный» лишь в том, что при «активный-активный» подходе дополнительный регион всегда в рабочем (активном) состоянии.

В шаблоне «активный-активный» в основном регионе может потребоваться меньше экземпляров по сравнению с их количеством в шаблоне «активный-пассивный». Если в архитектуре на основе шаблона «активный – пассивный» в основном регионе есть 10 экземпляров, в архитектуре на основе шаблона «активный – активный» в каждом регионе может потребоваться всего 5 экземпляров. Теперь нагрузка распределяется между обоими регионами. Если разместить «горячую» резервную копию с 10 экземплярами, ожидающими отработки отказа, в пассивном регионе, затраты будут меньше по сравнению с затратами в шаблоне «активный –пассивный».

Активный – пассивный

Множество компаний выбирают шаблон "активный-пассивный". Этот шаблон позволяет улучшить показатели целевого времени восстановления. Он требует немного больше затрат по сравнению с повторным развертыванием. В этом сценарии также используются основной и дополнительный регион Azure. Весь трафик передается в активное развертывание в основном регионе. Дополнительный регион лучше подготовлен к аварийному восстановлению, так как база данных работает в обоих регионах. Кроме того, между ними настроен механизм синхронизации. Существует два варианта такого резервного подхода: только с использованием базы данных или полное развертывание в дополнительном регионе.

На рисунке 2 показана модель по шаблону "активный — пассивный", в которой основной и дополнительный регионы содержат полностью развернутую облачную службу.

 

Рисунок 2

Только база данных

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

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

Полная реплика

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

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

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

Чтобы добиться минимального времени отклика в этой модели, необходимо использовать один и тот же масштаб (количество экземпляров ролей) в основном и дополнительном регионах. Несмотря на преимущества, есть неиспользуемые вычислительные операции, которые дорого обходятся, поэтому это не самый выгодный вариант с финансовой точки зрения. По этой причине чаще всего используется версия облачных служб меньшего масштаба в дополнительном регионе. Затем при необходимости можно быстро выполнить отработку отказа и дополнительное развертывание. Следует автоматизировать отработку отказа, чтобы в случае недоступности основного региона можно было активировать дополнительные экземпляры в зависимости от нагрузки. При этом может использоваться механизм автоматического масштабирования, например, наборы для масштабирования виртуальных машин.

На рисунке 3 показана модель по шаблону "активный — пассивный", в которой основной и дополнительный регионы содержат полностью развернутую облачную службу.