Рекомендации по использованию зон доступности и регионов

Применяется к этой рекомендации проверка списка надежности платформы Azure Well-Architected Framework:

RE:05	Добавьте избыточность на разных уровнях, особенно для критических потоков. Примените избыточность к вычислительным ресурсам, данным, сети и другим уровням инфраструктуры в соответствии с идентифицированными целевыми объектами надежности.

Связанные руководства:Высокодоступная многорегиональный дизайн | избыточность

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

При разработке решения для Azure необходимо решить, будет ли развертываться в нескольких зонах доступности в регионе или развертываться в нескольких регионах. Это решение влияет на надежность, стоимость и производительность решения, а также способность вашей команды работать с решением. В этом руководстве содержатся сведения о ключевых бизнес-требованиях, влияющих на решение, подходы, которые можно рассмотреть, компромиссы, связанные с каждым подходом, и эффект каждого подхода к основным основам платформы Azure Well-Architected Framework.

Решение о лучших регионах Azure, используемых для решения, является критически важным выбором. В руководстве по выбору регионов Azure описывается, как выбрать и работать в нескольких географических регионах. Выбор того, как вы используете регионы и зоны доступности в решении, также влияет на несколько основных компонентов платформы Well-Architected Framework:

• Надежность. Выбор подхода к развертыванию может помочь устранить различные типы рисков. В целом, распространяя рабочую нагрузку в более географически распределенной области, можно добиться более высокой устойчивости.
• Оптимизация затрат: некоторые архитектурные подходы требуют развертывания большего количества ресурсов, чем другие, что может увеличить затраты на ресурсы. Другие подходы включают отправку данных между географически разделенными зонами доступности или регионами, которые могут взимать плату за сетевой трафик. Кроме того, важно учитывать текущие затраты на управление ресурсами, что обычно выше при наличии комплексных бизнес-требований.
• Эффективность производительности. Зоны доступности объединяются через сеть с высокой пропускной способностью, низкой задержкой, которая достаточно для большинства рабочих нагрузок для обеспечения синхронной реплика связи между зонами. Однако если рабочая нагрузка протестирована и учитывает задержку в сети между зонами, может потребоваться физически найти компоненты рабочей нагрузки, чтобы свести к минимуму задержку при обмене данными.
• Операционное превосходство. Сложная архитектура требует больше усилий для развертывания, настройки и управления ими. Кроме того, для высокодоступного решения может потребоваться спланировать отработку отказа в дополнительный набор ресурсов. Отработка отказа, восстановление размещения и прозрачное перенаправление трафика могут быть сложными, особенно при необходимости вручную. Рекомендуется автоматизировать процессы развертывания и управления. Дополнительные сведения см. в руководствах по работе, включая инфраструктуру OE:05 в качестве кода, автоматизацию задач OE:09, проектирование автоматизации OE:10 и методики развертывания OE:11.

Однако вы разрабатываете решение, применяется компонент безопасности. Как правило, решения о том, следует ли использовать зоны доступности и регионы, не изменяя состояние безопасности. Azure применяет один и тот же уровень безопасности к каждому региону и зоне доступности.

Совет

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

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

Определения

Термин	Определение
Шаблон "активный — активный"	Архитектура, в которой одновременно несколько экземпляров решения активно обрабатывают запросы.
Шаблон "активный — пассивный"	Архитектура, в которой один экземпляр решения обозначается как основной и обрабатывает трафик, а один или несколько дополнительных экземпляров развертываются для обслуживания трафика, если основной является недоступным.
Асинхронная репликация	Подход к реплика данных, в котором данные записываются и фиксируется в одном расположении. В дальнейшем изменения реплика в другое расположение.
Availability zone	Отдельная группа центров обработки данных в пределах региона. Каждая зона доступности не зависит от других, с собственной мощностью, охлаждением и сетевой инфраструктурой. Многие регионы поддерживают зоны доступности.
Центр обработки данных	Объект, содержащий серверы, сетевое оборудование и другое оборудование для поддержки ресурсов и рабочих нагрузок Azure.
Локально избыточное развертывание	Модель развертывания, в которой ресурс развертывается в одном регионе без ссылки на зону доступности. В регионе, поддерживающем зоны доступности, ресурс может быть развернут в любой из зон доступности региона.
Развертывание в нескольких регионах	Модель развертывания, в которой ресурсы развертываются в нескольких регионах Azure.
Пары регионов	Связь между двумя регионами Azure. Некоторые регионы Azure подключены к другому определенному региону, чтобы включить определенные типы решений с несколькими регионами. Новые регионы Azure не связаны.
Область/регион	Географический периметр, содержащий набор центров обработки данных.
Архитектура региона	Конкретная конфигурация региона Azure, включая количество зон доступности и связь региона с другим регионом.
Синхронная репликация	Подход реплика обработки данных, в котором данные записываются и фиксируется в нескольких расположениях. Каждое расположение должно подтвердить завершение операции записи до завершения общей операции записи.
Зональное развертывание (закреплено)	Модель развертывания, в которой ресурс развертывается в определенной зоне доступности.
Развертывание, избыточное между зонами	Модель развертывания, в которой ресурс развертывается в нескольких зонах доступности. Корпорация Майкрософт управляет синхронизацией данных, распределением трафика и отработкой отказа в случае сбоя зоны.

Основные стратегии проектирования

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

Регионы Azure имеют различные конфигурации, которые также называются архитектурами регионов.

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

На следующей схеме показано несколько примеров регионов Azure. Регионы 1 и 2 поддерживают зоны доступности.

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

Существует два способа использования зон доступности в решении:

• Зональные ресурсы закреплены в определенной зоне доступности. Можно объединить несколько зональных развертываний в разных зонах, чтобы соответствовать высоким требованиям к надежности. Вы несете ответственность за управление репликацией данных и распределение запросов между зонами. Если сбой возникает в одной зоне доступности, вы несете ответственность за отработку отказа в другую зону доступности.
• Ресурсы, избыточные между зонами, распределяются по нескольким зонам доступности. Microsoft управляет распределением запросов между зонами и репликацией данных между зонами. Если сбой возникает в одной зоне доступности, Microsoft автоматически управляет отработкой отказа.

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

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

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

Дополнительные сведения о том, как Azure использует регионы и зоны доступности, см. в статье "Что такое регионы и зоны доступности Azure"?

Общие сведения о общих обязанностях

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

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

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

Определение ключевых требований к бизнесу и рабочей нагрузке

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

Риску

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

В этой таблице перечислены некоторые распространенные риски, которые следует учитывать в облачной среде:

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

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

Совет

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

Требования к устойчивости

Важно понимать требования к устойчивости для рабочей нагрузки, включая цель времени восстановления (RTO) и цель точки восстановления (RPO). Эти цели помогут вам решить, какие подходы следует исключить. Если у вас нет четких требований, вы не можете принять информированное решение о том, какой подход следует выполнить. Дополнительные сведения см. в разделе "Целевые функциональные и нефункциональные требования".

Цели уровня обслуживания

Вы должны понимать ожидаемый целевой уровень обслуживания (SLO) вашего решения. Например, у вас может быть бизнес-требование, что решение должно соответствовать 99,9 % времени простоя.

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

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

Место расположения данных

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

Примечание.

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

Местонахождение пользователей

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

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

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

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

Бюджет

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

Сложность

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

Упрощение функций Azure

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

Чтобы проиллюстрировать подходы к развертыванию, которые можно использовать, рассмотрим пример сценария. Предположим, вы думаете о развертывании нового решения, включающего приложение, которое записывает данные в определенное хранилище:

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

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

Принцип	Локально избыточное	Зональный (закрепленный)	Избыточность между зонами	Многорегионная
Надежность	Низкая надежность	Зависит от подхода	Высокая или очень высокая надежность	Высокая или очень высокая надежность
Оптимизация затрат	Низкая стоимость	Зависит от подхода	Средняя стоимость	Высокая стоимость
Уровень производительности	Допустимая производительность (для большинства рабочих нагрузок)	Высокопроизводительные	Допустимая производительность (для большинства рабочих нагрузок)	Зависит от подхода
Эффективность работы	Низкие операционные требования	Высокие операционные требования	Низкие операционные требования	Высокие операционные требования

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

Архитектурные проблемы	Локально избыточное	Зональный (закрепленный)	Избыточность между зонами	Многорегионная
Соответствие месту расположения данных	Высокая	Высокая	Высокая	Зависит от региона
Доступность в регионах	Все регионы	Регионы с зонами доступности	Регионы с зонами доступности	Зависит от региона

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

Подход к развертыванию 1. Локально избыточные развертывания

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

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

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

В этой таблице приведены некоторые из основных проблем:

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

В этой таблице приведены некоторые проблемы с точки зрения архитектуры:

Архитектурные проблемы	Воздействие
Соответствие месту расположения данных	Высокая. При развертывании решения, использующего этот подход, данные хранятся в выбранном регионе Azure.
Доступность в регионах	Высокая. Этот подход можно использовать в любом регионе Azure.

Локально избыточные развертывания с резервным копированием в разных регионах

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

При реализации этого подхода необходимо тщательно рассмотреть RTO и RPO:

• Время восстановления. Если происходит региональный сбой, может потребоваться перестроить решение в другом регионе Azure, что влияет на время восстановления. Рассмотрите возможность создания решения с помощью подхода "инфраструктура как код" (IaC), чтобы можно было быстро развернуть развертывание в другом регионе при возникновении серьезной аварии. Убедитесь, что средства и процессы развертывания являются столь же устойчивыми, как и приложения, чтобы их можно было использовать для повторного развертывания решения, даже если произошел сбой. Планирование и репетиция шагов, необходимых для восстановления решения обратно в рабочее состояние.
• Точка восстановления. Частота резервного копирования определяет объем потери данных, который может возникнуть (точка восстановления). Обычно можно управлять частотой резервных копий, чтобы обеспечить соответствие RPO.

В этой таблице приведены некоторые из основных проблем:

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

В этой таблице приведены некоторые проблемы с точки зрения архитектуры:

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

Подход к развертыванию 2. Зональные (закрепленные) развертывания

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

Зональный подход снижает задержку между компонентами. Тем не менее, само по себе это не повышает устойчивость решения. Чтобы повысить устойчивость, необходимо развернуть несколько экземпляров компонентов в нескольких зонах доступности и решить, как маршрутизировать трафик между каждым экземпляром. В этом примере показан подход к маршрутизации трафика с активным пассивным трафиком:

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

При использовании зональной модели развертывания вы берете на себя множество обязанностей:

• Необходимо развернуть ресурсы в каждой зоне доступности и настроить и управлять этими ресурсами по отдельности.
• Необходимо решить, как и когда реплика te данные между зонами доступности, а затем настроить реплика и управлять ими.
• Вы несете ответственность за распространение запросов на правильные ресурсы, используя, например, подсистему балансировки нагрузки. Необходимо убедиться, что подсистема балансировки нагрузки соответствует вашим требованиям к устойчивости. Кроме того, необходимо решить, следует ли использовать модель распространения запросов "активный- пассивный" или "активный- активный".
• Если зона доступности возникает сбой, необходимо обработать отработку отказа, чтобы отправить трафик ресурсам в другой зоне доступности.

Активное пассивное развертывание в нескольких зонах доступности иногда называется аварийное восстановление региона или аварийное восстановление метро.

В этой таблице приведены некоторые из основных проблем:

Принцип	Воздействие
Надежность	При развертывании в одной зоне доступности:низкая надежность. Зональное развертывание не обеспечивает устойчивость к сбою в центре обработки данных или зоне доступности. Чтобы обеспечить высокую устойчивость, необходимо развернуть избыточные ресурсы в нескольких зонах доступности. При развертывании в нескольких зонах доступности:высокая надежность. Службы могут быть устойчивы к сбоям в центре обработки данных или зоне доступности.
Оптимизация затрат	При развертывании в одной зоне доступности:низкая стоимость. Для развертывания с одной зоной требуется только один экземпляр каждого ресурса. При развертывании в нескольких зонах доступности:высокая стоимость. Вы развертываете несколько экземпляров ресурсов, каждый из которых выставляется отдельно.
Уровень производительности	Высокая производительность. Задержка может быть очень низкой, если компоненты, обслуживающие запрос, находятся в той же зоне доступности.
Эффективность работы	Низкая операционная эффективность. Необходимо настроить несколько экземпляров службы и управлять ими. Необходимо реплика te данные между зонами доступности. Во время сбоя зоны доступности отработка отказа является вашей ответственностью.

В этой таблице приведены некоторые проблемы с точки зрения архитектуры:

Архитектурные проблемы	Воздействие
Соответствие месту расположения данных	Высокая. При развертывании решения, использующего этот подход, данные хранятся в выбранном регионе Azure.
Доступность в регионах	Регионы с зонами доступности. Этот подход доступен в любом регионе, поддерживающем зоны доступности.

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

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

Совет

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

Подход к развертыванию 3. Развертывание, избыточное между зонами

При использовании этого подхода уровень приложений распространяется между несколькими зонами доступности. При поступлении запросов подсистема балансировки нагрузки, встроенная в службу (которая охватывает зоны доступности), распределяет запросы по экземплярам в каждой зоне доступности. Если зона доступности возникает сбой, подсистема балансировки нагрузки направляет трафик к экземплярам в здоровых зонах доступности.

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

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

В этой таблице приведены некоторые из основных проблем:

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

В этой таблице приведены некоторые проблемы с точки зрения архитектуры:

Архитектурные проблемы	Воздействие
Соответствие месту расположения данных	Высокая. При развертывании решения, использующего этот подход, данные хранятся в выбранном регионе Azure.
Доступность в регионах	Регионы с зонами доступности. Этот подход доступен в любом регионе, поддерживающем зоны доступности.

Этот подход возможен со многими службами Azure, включая Azure Масштабируемые наборы виртуальных машин, службу приложение Azure, Функции Azure, Служба Azure Kubernetes. служба хранилища Azure, SQL Azure, Служебная шина Azure и многие другие. Полный список служб, поддерживающих избыточность зоны, см. в разделе "Служба зоны доступности" и региональная поддержка.

Развертывания с избыточностью между зонами с резервным копированием в разных регионах

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

При реализации этого подхода необходимо тщательно рассмотреть RTO и RPO:

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

• Точка восстановления. Частота резервного копирования определяет объем потери данных, который может возникнуть (точка восстановления). Обычно можно контролировать частоту резервных копий для соответствия RPO.

Совет

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

В этой таблице приведены некоторые из основных проблем:

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

В этой таблице приведены некоторые проблемы с точки зрения архитектуры:

Архитектурные проблемы	Воздействие
Соответствие месту расположения данных	Зависит от выбора региона. Данные хранятся в основном в указанном регионе Azure, но для хранения резервных копий необходимо выбрать другой регион. Выберите регион, совместимый с требованиями к месту размещения данных.
Доступность в регионах	Регионы с зонами доступности. Этот подход доступен в любом регионе, поддерживающем зоны доступности.

Подход к развертыванию 4. Развертывание в нескольких регионах

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

Активные и пассивные регионы

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

Репликация данных

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

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

Асинхронное реплика данных

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

В этой таблице приведены некоторые из основных проблем:

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

В этой таблице приведены некоторые проблемы с точки зрения архитектуры:

Архитектурные проблемы	Воздействие
Соответствие месту расположения данных	Зависит от выбора региона. Этот подход требует выбора нескольких регионов для выполнения рабочей нагрузки. Выберите регионы, совместимые с требованиями к месту размещения данных.
Доступность в регионах	Многие регионы Azure связаны. Некоторые службы Azure используют парные регионы для автоматического реплика te данных. Если вы запускаете рабочую нагрузку в регионе, у которых нет пары, может потребоваться использовать другой подход для реплика управления данными.

Синхронные данные реплика

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

В этой таблице приведены некоторые из основных проблем:

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

В этой таблице приведены некоторые проблемы с точки зрения архитектуры:

Архитектурные проблемы	Воздействие
Соответствие месту расположения данных	Зависит от выбора региона. Этот подход требует выбора нескольких регионов для выполнения рабочей нагрузки. Выберите регионы, совместимые с требованиями к месту расположения данных.
Доступность в регионах	Многие регионы Azure связаны. Некоторые службы Azure используют парные регионы для автоматического реплика te данных. Если вы запускаете рабочую нагрузку в регионе, у которых нет пары, может потребоваться использовать другой подход для реплика управления данными.

Архитектура регионов

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

Вы можете создать решение с несколькими регионами, даже если регионы не связаны. Однако подходы, используемые для реализации архитектуры с несколькими регионами, могут отличаться. Например, в служба хранилища Azure можно использовать геоизбыточное хранилище (GRS) с парными регионами. Если GRS недоступен, попробуйте использовать такие функции, как служба хранилища Azure объект реплика tion, или создать приложение для записи в несколько регионов.

Объединение подходов с несколькими зонами и несколькими регионами

Если бизнес-требования требуют такого решения, следует объединить инструкции с несколькими зонами и несколькими регионами. Например, можно развернуть компоненты, избыточные между зонами, в каждом регионе, а также настроить реплика между регионами. Для некоторых решений этот подход обеспечивает очень высокую степень надежности. Однако настройка этого типа подхода может быть сложной, и такой подход может быть дорогостоящим.

Внимание

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

Как службы Azure поддерживают подходы к развертыванию

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

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

Примеры

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

Бизнес-приложение для предприятия

Contoso, Ltd., является крупной производственной компанией. Компания реализует бизнес-приложение для управления некоторыми компонентами финансовых процессов.

Бизнес-требования: сведения, которыми управляет система, трудно заменить, поэтому данные должны быть надежно сохранены. Архитекторы говорят, что система должна нести как можно меньше простоев и как можно меньше потери данных. Сотрудники Компании Contoso используют систему на протяжении всего рабочего дня, поэтому высокую производительность важно, чтобы избежать ожидания участников команды. Стоимость также является проблемой, потому что финансовая команда должна платить за решение.

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

Внутреннее приложение

Четвертый кофе - это небольшой бизнес. Компания разрабатывает новое внутреннее приложение, которое сотрудники могут использовать для отправки расписаний.

Бизнес-требования. Для этой рабочей нагрузки эффективность затрат является основной проблемой. Четвертый кофе оценил влияние простоя на бизнес и решил, что приложению не нужно определять приоритеты устойчивости или производительности. Компания принимает риск того, что сбой в зоне доступности Azure или регионе может временно сделать приложение недоступным.

Предлагаемые подходы:

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

Миграция устаревших приложений

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

Бизнес-требования: производительность является приоритетом для этого приложения. Устойчивость также важна, и приложение должно продолжать работать, даже если центр обработки данных Azure испытывает сбой.

Предлагаемый подход:

• Fabrikan должен сначала попробовать развертывание, избыточное между зонами. Они должны проверить производительность в соответствии с их требованиями.
• Если производительность решения, избыточного между зонами, неприемлема, рассмотрите зональное (закрепленное) развертывание с пассивными развертываниями в нескольких зонах доступности (аварийное восстановление в регионе).

Приложение для здравоохранения

Компания Lamna Healthcare реализует новую электронную систему записи работоспособности в Azure.

Бизнес-требования: из-за характера данных, которые хранятся в этом решении, место размещения данных критически важно. Lamna работает в строгой нормативной базе, которая предписывает, что данные должны оставаться в определенном расположении.

Предлагаемые подходы:

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

Банковская система

Woodgrove Bank выполняет свои основные банковские операции из большого решения, развернутого в Azure.

Бизнес-требования: это критически важная система. Любые сбои могут привести к серьезным финансовым последствиям для клиентов. В результате Woodgrove Bank имеет очень низкую устойчивость к риску. Система нуждается в самом высоком уровне надежности, и архитектура должна снизить риск любых сбоев, которые могут быть устранены.

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

Программное обеспечение как услуга (SaaS)

Proseware, Inc., создает программное обеспечение, которое используется компаниями по всему миру. База пользователей компании широко распределена по географическому расположению.

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

Предлагаемые подходы:

• Развертывание с несколькими зонами обычно является хорошим выбором для поставщика SaaS, особенно если оно используется в шаблоне меток развертывания.
• Развертывание, избыточное между зонами, в сочетании с решением глобального ускорения трафика, например Azure Front Door.

Дополнительные ссылки

Ниже приведены некоторые эталонные архитектуры и примеры сценариев для решений с несколькими зонами и несколькими регионами:

• Базовое высокодоступное веб-приложение с высоким уровнем доступности
• Высокодоступное веб-приложение с несколькими регионами
• Многорегионное N-уровневое приложение
• Многоуровневое веб-приложение, созданное для высокого уровня доступности и аварийного восстановления

Многие службы Azure предоставляют рекомендации по использованию нескольких зон доступности, включая следующие примеры:

• Azure Site Recovery: включение аварийного восстановления виртуальной машины Azure между зонами доступности
• Azure NetApp Files. Общие сведения о межзоны реплика tion Azure NetApp Files
• Репликация службы хранилища Azure

Список проверка надежности

Ознакомьтесь с полным набором рекомендаций.

Список проверка надежности