Описание функций обеспечения высокой доступности и аварийного восстановления Azure для виртуальных машин Azure
Azure предоставляет три основных варианта повышения доступности для развертываний IaaS.
Группы доступности
зоны доступности;
Azure Site Recovery
Все три этих параметра являются внешними для виртуальной машины и не знают, какая рабочая нагрузка выполняется внутри нее.
Группы доступности
Группы доступности обеспечивают бесперебойную работу по обслуживанию, связанному с Azure, и единые точки отказа в одном центре обработки данных. Это одна из функций первого уровня доступности, появившихся в платформе Azure, и ее фактически можно рассматривать как правила защиты от несоответствия для виртуальных машин. Это означает, что при наличии двух виртуальных машин SQL Server в группе доступности или паре доставки журналов они гарантированно не будут запущены на одном физическом сервере.
Группы доступности разделяются как на домены сбоя, так и на домены обновления, чтобы поддерживать оба обновления в базовой инфраструктуре Azure. Домены сбоя — это комплекты серверов в центре обработки данных, использующие один и тот же источник питания и сеть. В центре обработки данных может быть до трех доменов сбоя, они обозначены на рисунке ниже как FD 0, 1 и 2. Домены обновления — это группы виртуальных машин и базовое физическое оборудование, которые могут быть перезагружены одновременно. Они обозначены на рисунке ниже как UD. Разные домены обновления обеспечивают функциональное разделение.
Группы доступности и зоны не защищаются от сбоев в гостевой системе, таких как сбой ОС или RDBMS; Именно поэтому необходимо реализовать дополнительные решения, такие как AGs или FCIs, чтобы обеспечить соответствие ОСРВ и RPOS. Группы и зоны доступности предназначены для ограничения влияния проблем среды на уровне Azure, в частности сбоев в центре обработки данных, физического сбоя оборудования, простоев сети и аварийных отключений питания.
В многоуровневом приложении следует размещать каждый уровень приложения в отдельной группе доступности. Например, если бы вы разрабатывали веб-приложение с серверной частью на SQL Server и доменными службами Active Directory (AD DS), то создали бы группу доступности для каждого уровня (Интернет, база данных и AD DS).
Группы доступности — это не единственный способ разделения виртуальных машин IaaS. Azure также предоставляет Зоны доступности, но их нельзя объединить. Можно выбрать одну из них.
Зоны доступности
Учетная запись зон доступности для сбоя на уровне центра обработки данных в Azure. Каждый регион Azure состоит из множества центров обработки данных с сетевыми подключениями между ними, имеющими низкое значение задержки. При развертывании ресурсов виртуальной машины в регионе с поддержкой зон доступности можно развернуть эти ресурсы в зоне 1, 2 или 3. Зона — это уникальное физическое местоположение, то есть центр обработки данных в регионе Azure.
Номера зон являются логическими представлениями. Например, если два подписчика Azure развертывают виртуальную машину в зоне 1 в своих собственных подписках, это не означает, что эти виртуальные машины существуют в одном физическом центре обработки данных Azure. Кроме того, из-за расстояния может возникать дополнительная задержка при развертывании в зонах. Необходимо проверить задержку между виртуальными машинами, чтобы убедиться, что она соответствует целевым показателям производительности. В большинстве случаев задержка кругового пути будет менее 1 миллисекунды, что позволяет поддерживать синхронное перемещение данных в рамках таких функциональных возможностей, как группы доступности. Также можно развернуть базу данных SQL Azure в зонах доступности.
Azure Site Recovery
Azure Site Recovery обеспечивает лучшую доступность виртуальных машин на уровне Azure и может работать с виртуальными машинами, на которых размещен SQL Server. Azure Site Recovery реплицирует виртуальную машину из одного региона Azure в другой, чтобы создать решение для аварийного восстановления этой виртуальной машины. Как отмечалось ранее, эта функция не знает, что SQL Server запущен на виртуальной машине, и ничего не знает о транзакциях. Хотя Azure Site Recovery может соответствовать RTO, он может не соответствовать RPO, так как он не определяет, где данные находится внутри SQL Server. Azure Site Recovery имеет указанное ежемесячное значение RTO в два часа. Хотя большинство специалистов по базам данных могут предпочесть использовать для аварийного восстановления метод на основе базы данных, архитектура Azure Site Recovery эффективна, если она соответствует потребностям RTO и RPO.