Наборы доступности Azure и зоны доступности

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

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

Наборы доступности Azure используются для размещения ваших виртуальных машин в разных доменах сбоя и доменах обновлений, но в одном и том же центре обработки данных. Следовательно, 99,95 % SLA.

Когда дело доходит до зон доступности Azure, каждый регион логически разделен на 3 зоны, и ваши виртуальные машины будут помещены в разные домены сбоя и домены обновлений в разные зоны, что обеспечивает большую отказоустойчивость. Следовательно, 99,99 % SLA.

Есть два типа - Зональный и Зональный резерв.

Если вы хотите решить, в какой зоне должен быть развернут ваш ресурс, выберите Зональный сервис. Если вы хотите, чтобы Azure управляла зонами, выберите службу Zonal Redundant.

Прежде чем перейти к SLA, вот несколько основ:

Группы доступности Azure — это KNOB, который данный Azure DataCenter предоставляет вам — в размещение инфраструктуры в пределах данного центра обработки данных — как размещены между хостами, стойками, блоками питания и системами охлаждения - в основном во всех возможных точках отказа. Таким образом, если вы использовали параметр Группы доступности Azure, а затем, скажем, в один плохой день в регионе Восток США, RACK, на котором работает ваша виртуальная машина в центре обработки данных на востоке США, вышла из строя, вы в безопасности, поскольку вы создали избыточность для этих сбоев. баллы - ваши вещи работают на другой стойке. Однако, если выйдет из строя весь центр обработки данных Azure или, в худшем случае, произойдет обрушение центра обработки данных, ваши виртуальные машины будут полностью недоступны. Лазурный имел понятие Группы доступности с самого начала существования Лазурный.

Зоны доступности Azure был представлен Azure недавно в период 2017-18 — в основном для защиты от этих сбоев на уровне центра обработки данных. В рамках решения этой задачи данный регион был разделен на Зоны. Проще говоря, Zone — это старый центр обработки данных. Итак, в регионе теперь несколько центров обработки данных! Вы (клиенты) можете ссылаться на эти зоны — с идентификаторами ZoneID и размещать свою инфраструктуру в одном регионе — через Центры обработки данных! Это означает, что теперь, если вы использовали функцию Зоны доступности и если один из центров обработки данных вышел из строя, у вас все еще есть избыточная инфраструктура, которую вы предоставили в том же регионе (что означает очень похожие гарантии задержки), и она работает!

Теперь, хотя это выглядит очень просто, чтобы построить полностью зонально избыточное решение, есть сложные проблемы, которые следует понять, например, если вы создаете Virtual Machine Scale Set, используя VMs из разных зон - как Azure решает поддержание избыточной инфраструктуры n/w, как клиент, сколько Azure взимает за n/w'ing в этих межзональных виртуальных машинах, какие доступны решения для хранения/данных и как выбрать ручки Azure для служб данных для репликации этих данных между зонами!?

всего в Azure есть 3 варианта высокой доступности. читать дальше...