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

Применяется к этой рекомендации по контрольным спискам надежности Платформы 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 применяет одну и ту же строгость безопасности к каждому региону и зоне доступности.

Совет

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

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

Определения

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

Ключевые стратегии проектирования

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

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

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

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

Схема центров обработки данных, зон доступности и регионов.

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

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

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

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

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

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

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

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

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

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

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

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

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

Риску

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

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

Риск Примеры Вероятность
Сбой оборудования Проблема с жестким диском или сетевым оборудованием.

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

Стихийное бедствие в одной части столичного района.
Средний
Сбой региона Крупное стихийное бедствие, затрагивающее широкий географический район.

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

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

Совет

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

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

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

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

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

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

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

Местонахождение данных

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

Примечание

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

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

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

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

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

Даже если пользователи находятся в разных географических регионах, подумайте, требуется ли развертывание в нескольких регионах. Подумайте, можете ли вы достичь своих требований в одном регионе с помощью глобального ускорения трафика, например ускорения, предоставляемого 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, которая вообще не развертывается в регионе.

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

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

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

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

Аспект Влияние
надежность; При развертывании в одной зоне доступности:низкая надежность. Зональное развертывание не обеспечивает устойчивость к сбою в центре обработки данных или зоне доступности. Для обеспечения высокой устойчивости необходимо развернуть избыточные ресурсы в нескольких зонах доступности.

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

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

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

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

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

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

Совет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Совет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Схема, на которую показано решение, развернутое в нескольких регионах. Репликация данных выполняется асинхронно.

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

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

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

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

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

Схема, на которую показано решение, развернутое в нескольких регионах. Репликация данных выполняется синхронно.

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

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

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

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

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

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

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

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

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

Важно!

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

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

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

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

Примеры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Lamna Healthcare Company внедряет новую систему электронных медицинских записей в Azure.

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

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

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

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

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

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

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

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

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

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

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

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

Контрольный список надежности

См. полный набор рекомендаций.