Рекомендации по использованию зон доступности и регионов
Применяется к этой рекомендации по контрольным спискам надежности 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 предоставляет соглашения об уровне обслуживания для каждой службы. Соглашение об уровне обслуживания указывает уровень времени простоя, который необходимо ожидать от службы, и условия, необходимые для достижения ожидаемого соглашения об уровне обслуживания. Однако помните, что способ, которым соглашение об уровне обслуживания 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 Traffic Manager, который не развертывается в регионе вовсе.
При использовании зональной модели развертывания вы берете на себя множество обязанностей:
- Необходимо развернуть ресурсы в каждой зоне доступности и настроить и управлять этими ресурсами по отдельности.
- Необходимо решить, как и когда реплицировать данные между зонами доступности, а затем настроить репликацию и управлять ими.
- Вы несете ответственность за распространение запросов на правильные ресурсы, используя, например, подсистему балансировки нагрузки. Необходимо убедиться, что подсистема балансировки нагрузки соответствует вашим требованиям к устойчивости. Кроме того, необходимо решить, следует ли использовать модель распространения запросов "активный-пассивный" или "активный-активный".
- Если в зоне доступности происходит сбой, необходимо обработать отказ, чтобы перенаправить трафик к ресурсам в другой зоне доступности.
Активно-пассивное развертывание в нескольких зонах доступности иногда называется аварийного восстановления в регионе или метро DR.
В этой таблице приведены некоторые из основных проблем:
| Столб | Удар |
|---|---|
| Надёжность |
При развертывании в одной зоне доступности:низкая надежность. зональное развертывание не обеспечивает устойчивость к сбою в центре обработки данных или зоне доступности. Чтобы обеспечить высокую устойчивость, необходимо развернуть избыточные ресурсы в нескольких зонах доступности. При развертывании в нескольких зонах доступности:высокий уровень надежности. службы могут быть устойчивы к сбоям в центре обработки данных или зоне доступности. |
| Оптимизация затрат |
При развертывании в одной зоне доступности:низкая стоимость. Развертывание в одной зоне требует лишь одного экземпляра каждого ресурса. При развертывании в нескольких зонах доступности:Высокая стоимость. Вы развертываете несколько экземпляров ресурсов, каждый из которых оплачивается отдельно. |
| Эффективность производительности | Высокая производительность. Задержка может быть очень низкой, если компоненты, обслуживающие запрос, находятся в той же зоне доступности. |
| Операционное превосходство | Низкая операционная эффективность. Необходимо настроить несколько экземпляров службы и управлять ими. Необходимо реплицировать данные между зонами доступности. В случае сбоя зоны доступности переключение на резервный ресурс лежит на вашей ответственности. |
В этой таблице приведены некоторые проблемы с точки зрения архитектуры:
Этот подход обычно используется для рабочих нагрузок, основанных на виртуальных машинах. Полный список служб, поддерживающих зональные развертывания, см. в разделе служба зоны доступности и региональная поддержка.
При планировании зонального развертывания убедитесь, что используемые службы Azure поддерживаются в зонах доступности, которые вы планируете использовать. Например, сведения о том, какие номера SKU виртуальных машин доступны в каждой зоне доступности, см. в разделе Проверка доступности SKU виртуальной машины.
Совет
При развертывании ресурса в определенной зоне доступности выберите номер зоны. Последовательность номеров зон отличается для каждой подписки Azure. При развертывании ресурсов в нескольких подписках Azure проверьте номера зон, которые следует использовать в каждой подписке. Для получения дополнительной информации см. физические и логические зоны доступности.
Подход к развертыванию 3: Развертывание избыточное по зонам
При использовании этого подхода компоненты вашего приложения распределяются по нескольким зонам доступности. При поступлении запросов подсистема балансировки нагрузки, встроенная в службу (которая охватывает зоны доступности), распределяет запросы по экземплярам в каждой зоне доступности. Если в зоне доступности происходит сбой, балансировщик нагрузки направляет трафик к экземплярам серверов в исправных зонах доступности.
Уровень хранилища также распространяется по нескольким зонам доступности. Копии данных вашего приложения распределяются по нескольким зонам доступности с помощью синхронной репликации. Когда приложение вносит изменения в данные, служба хранилища записывает изменения в несколько зон доступности, и транзакция считается завершенной только после завершения всех этих изменений. Этот процесс гарантирует, что каждая зона доступности всегда имеет up-to-date копии данных. Если в зоне доступности происходит сбой, для доступа к тем же данным можно использовать другую зону доступности.
Подход с избыточностью по зонам повышает устойчивость вашего решения к проблемам, таким как сбои центра обработки данных. Так как данные реплицируются синхронно, приложение должно ждать записи данных в нескольких отдельных расположениях, которые могут находиться в разных частях городской области. Для большинства приложений задержка, связанная с взаимодействием между зонами, не является незначительной. Однако для некоторых рабочих нагрузок с высокой задержкой синхронизация между зонами доступности может повлиять на производительность приложения.
В этой таблице приведены некоторые из основных проблем:
| Столб | Удар |
|---|---|
| Надёжность | Высокая надежность. Службы устойчивы к сбоям центра обработки данных или зоны доступности. Данные синхронно реплицируются между зонами доступности и без задержки. |
| Оптимизация затрат | Средняя стоимость. В зависимости от используемых вами служб вы можете понести некоторые затраты на более высокие уровни обслуживания, чтобы обеспечить избыточность по зонам. |
| Эффективность производительности |
Для большинства рабочих нагрузок:допустимую производительность. Этот подход, скорее всего, обеспечивает удовлетворительную производительность. Для рабочих нагрузок с высокой задержкой:низкая производительность. Некоторые компоненты могут быть чувствительны к задержке из-за трафика между зонами или времени репликации данных. |
| Операционное превосходство | Высокая эффективность работы. Обычно необходимо управлять только одним логическим экземпляром каждого ресурса. Для большинства служб во время сбоя зоны доступности отработка отказа выполняется компанией Microsoft автоматически. |
В этой таблице приведены некоторые проблемы с точки зрения архитектуры:
Этот подход возможен со многими службами Azure, включая масштабируемые наборы виртуальных машин Azure, Службу приложений Azure, Функции Azure, Службу Azure Kubernetes, службу хранилища Azure, SQL Azure, служебную шину Azure и многие другие. Для получения полного списка служб, поддерживающих резервирование зон, см. в разделе "Служба зон доступности и региональная поддержка".
Развертывания с зональной избыточностью и резервным копированием по разным регионам
Развертывание с зональной избыточностью можно расширить, выполняя регулярные резервные копии инфраструктуры и данных во вторичный регион. Этот подход дает преимущества зонально-избыточного подхода и добавляет слой защиты для смягчения последствий крайне маловероятного события полного сбоя в регионе.
При внедрении этого метода, необходимо тщательно учитывать ваши показатели времени восстановления (RTO) и точки восстановления (RPO):
время восстановления. Если происходит региональный сбой, может потребоваться перестроить решение в другом регионе Azure, что влияет на время восстановления. Рассмотрите возможность создания решения с помощью подхода IaC, чтобы быстро развернуть его в другом регионе во время крупной аварии. Убедитесь, что средства и процессы развертывания так же устойчивы, как и ваши приложения, чтобы их можно было использовать для повторного развертывания решения, даже если происходит сбой. Запланируйте и репетируйте шаги, необходимые для восстановления вашего решения в рабочее состояние.
точка восстановления: частота резервного копирования определяет объем потери данных, который может возникнуть (точка восстановления). Обычно можно контролировать частоту резервных копий для соответствия RPO.
Совет
Этот подход часто обеспечивает хороший баланс для всех архитектурных проблем. Если вы не уверены, какой подход используется, начните с этого типа развертывания.
В этой таблице приведены некоторые из основных проблем:
| Столб | Удар |
|---|---|
| Надёжность | Очень высокая надежность. Службы устойчивы к сбоям центра обработки данных или зоны доступности. Для большинства служб данные реплицируются в зонах автоматически и без задержки. Данные резервируются асинхронно в географически разделенном регионе. Эта резервная копия снижает влияние полного сбоя региона за счет минимизации потери данных. После полного сбоя региона можно вручную восстановить операции в другом регионе. Однако процессы восстановления могут быть сложными, и может потребоваться время для ручного восстановления в другом регионе. |
| Оптимизация затрат | Средняя стоимость. Как правило, добавление резервного копирования в другой регион стоит лишь немного дороже, чем создание избыточности между зонами. |
| Эффективность производительности |
Для большинства рабочих нагрузок:допустимую производительность. Этот подход, скорее всего, обеспечивает удовлетворительную производительность. Для рабочих нагрузок с высокой задержкой:низкая производительность. Некоторые компоненты могут быть чувствительны к задержке из-за трафика между зонами или времени репликации данных. |
| Операционное превосходство |
Во время сбоя зоны доступности:высокая операционная эффективность. За отработку отказа отвечает Microsoft, и она происходит автоматически. во время регионального сбоя:низкая эффективность работы. отработка отказа является вашей ответственностью и может потребовать ручных операций и повторного развертывания. |
В этой таблице приведены некоторые проблемы с точки зрения архитектуры:
Подход к развертыванию 4. Развертывание в нескольких регионах
Вы можете совместно использовать несколько регионов Azure для распространения решения по широкому географическому региону. Этот подход с несколькими регионами можно использовать для повышения надежности решения или поддержки географически распределенных пользователей. При развертывании в нескольких регионах также снижается риск, с которым вы столкнетесь с временным ограничением емкости ресурсов в одном регионе. Если расположение данных важно для вашего решения, тщательно выберите регионы, чтобы убедиться, что ваши данные хранятся только в местах, соответствующих вашим требованиям.
Активные и пассивные регионы
Архитектура с несколькими регионами сложна, и существует множество способов разработки решения с несколькими регионами. Для некоторых рабочих нагрузок имеет смысл, чтобы несколько регионов одновременно обрабатывали запросы (активно-активные развертывания). Для других рабочих нагрузок лучше назначить один основной регион и использовать один или несколько дополнительных регионов для резервирования (активно-пассивные развертывания). В этом разделе основное внимание уделяется второму сценарию, в котором один регион активен, а другой — пассивным. Сведения об активно-активных много-региональных решениях см. в шаблоне меток развертывания и шаблоне геод.
Репликация данных
Обмен данными между регионами намного медленнее, чем обмен данными в пределах региона. Как правило, более большое географическое расстояние между двумя регионами вызывает большую задержку сети из-за более длительного физического расстояния, на которое должны перемещаться данные. См. статистику показателей полного цикла задержки в сети Azure для сведения об ожидаемой сетевой задержке при подключении между двумя регионами.
Задержка в сети между регионами может значительно повлиять на разработку решения, так как необходимо тщательно рассмотреть, как дополнительная задержка влияет на репликацию данных и другие транзакции. Для многих решений архитектура между регионами требует асинхронной репликации, чтобы свести к минимуму влияние трафика между регионами на производительность.
Асинхронная репликация данных
При реализации асинхронной репликации в разных регионах приложение не ожидает подтверждения изменений во всех регионах. После фиксации изменения в основном регионе транзакция считается завершенной. Изменение реплицируется во вторичные регионы на более позднем этапе. Этот подход гарантирует, что задержка подключения между регионами не влияет непосредственно на производительность приложения. Однако из-за задержки репликации может произойти сбой на уровне региона, что может привести к потере данных. Эта потеря данных может произойти, если в регионе произойдет сбой после завершения записи в основном регионе, но до того, как изменение сможет реплицироваться в другой регион.
В этой таблице приведены некоторые из основных проблем:
| Столб | Удар |
|---|---|
| Надёжность | Высокая надежность. Решение устойчиво к сбою центра обработки данных, зоны доступности или всего региона. Данные реплицируются, но могут не быть синхронными, поэтому возможна потеря данных в сценарии переключения на резерв. |
| Оптимизация затрат | Высокая стоимость. Необходимо развернуть отдельные ресурсы в каждом регионе, и каждый ресурс несет затраты на развертывание и обслуживание. Репликация данных в разных регионах также может привести к значительным затратам. |
| Эффективность производительности | Высокая производительность. Запросы приложений не требуют трафика между регионами, поэтому задержка трафика обычно низкой. |
| Операционное превосходство | Низкая операционная эффективность. Необходимо развернуть ресурсы и управлять ими в нескольких регионах. Вы также несете ответственность за резервное переключение между регионами во время регионального сбоя. |
В этой таблице приведены некоторые проблемы с точки зрения архитектуры:
| Архитектурные проблемы | Удар |
|---|---|
| Соответствие месту расположения данных | Зависит от выбора региона. Этот подход требует выбрать несколько регионов, в которых будет выполняться ваша рабочая нагрузка. Выберите регионы, совместимые с требованиями к месту размещения данных. |
| Региональная доступность | сопряжены многие регионы Azure. Некоторые службы Azure используют парные регионы для автоматической репликации данных. Если вы выполняете рабочую нагрузку в регионе , который не имеет пары, может потребоваться использовать другой подход для репликации данных. |
Синхронная репликация данных
Если вы реализуете синхронное решение с несколькими регионами, приложение должно ожидать завершения операций записи в каждом регионе Azure до завершения транзакции. Задержка, вызванная ожиданием операций записи, зависит от расстояния между регионами. Для многих рабочих нагрузок задержка между регионами может сделать синхронную репликацию слишком медленной, чтобы быть полезной.
В этой таблице приведены некоторые из основных проблем:
| Столб | Удар |
|---|---|
| Надёжность | Очень высокая надежность. Решение устойчиво к сбою центра обработки данных, зоны доступности или всего региона. Данные всегда синхронизируются между регионами, поэтому, даже если происходит полная потеря региона, данные доступны и завершены в другом регионе. |
| Оптимизация затрат | Высокая стоимость. Необходимо развернуть отдельные ресурсы в каждом регионе, и каждый ресурс несет затраты на развертывание и обслуживание. Репликация данных в разных регионах также может привести к значительным затратам. |
| Эффективность производительности | Низкая производительность. Для запросов приложений требуется трафик между регионами. В зависимости от расстояния между регионами синхронная репликация может добавить значительную задержку в запросы. |
| Операционное превосходство | Низкая операционная эффективность. Необходимо развернуть ресурсы и управлять ими в нескольких регионах. Вы также несете ответственность за переключение на резервный ресурс между регионами во время регионального сбоя. |
В этой таблице приведены некоторые проблемы с точки зрения архитектуры:
| Архитектурные проблемы | Удар |
|---|---|
| Соответствие месту расположения данных | Зависит от выбора региона. Этот подход требует выбора нескольких регионов для выполнения рабочей нагрузки. Выберите регионы, совместимые с требованиями к месту расположения данных. |
| Региональная доступность | Многие регионы Azure сопряжены. Некоторые службы Azure используют парные регионы для автоматической репликации данных. Если вы выполняете рабочую нагрузку в регионе , который не имеет пары, может потребоваться использовать другой подход для репликации данных. |
Архитектура регионов
При разработке решения с несколькими регионами следует учитывать, связаны ли регионы Azure, которые планируется использовать.
Вы можете создать решение с несколькими регионами, даже если регионы не связаны. Однако подходы, используемые для реализации архитектуры с несколькими регионами, могут отличаться. Например, в службе хранилища Azure можно использовать геоизбыточное хранилище (GRS) с парными регионами. Если GRS недоступен, рассмотрите возможность использования таких функций, как репликация объектов службы хранилища Azure или создание приложения для записи в несколько регионов.
Объедините подходы с несколькими зонами и регионами
Если ваши бизнес-требования требуют такого решения, вам следует сочетать заявления с несколькими зонами и регионами. Например, вы можете развернуть зонально-избыточные компоненты в каждом регионе, а также настроить репликацию между регионами. Для некоторых решений этот подход обеспечивает очень высокую степень надежности. Однако настройка этого типа подхода может быть сложной, и такой подход может быть дорогостоящим.
Важный
Критически важные рабочие нагрузки должны использовать несколько зон доступности и, а также несколько регионов. Дополнительные сведения о рекомендациях, которые следует учитывать при разработке критически важных рабочих нагрузок, см. в документации по критически важным рабочим нагрузкам.
Как службы Azure поддерживают подходы к развертыванию
Важно понимать конкретные сведения используемых служб Azure. Например, для некоторых служб Azure требуется настроить конфигурацию зоны доступности при первом развертывании ресурса, а другие поддерживают изменение подхода к развертыванию позже. Аналогичным образом некоторые функции службы могут быть недоступны при каждом подходе к развертыванию.
Чтобы узнать больше о конкретных вариантах развертывания и подходах, которые стоит рассмотреть для каждой службы Azure, посетите центр надежности.
Примеры
В этом разделе описываются некоторые распространенные варианты использования и основные требования, которые обычно необходимо учитывать для каждой рабочей нагрузки. Для каждой рабочей нагрузки предоставляются один или несколько предлагаемых подходов к развертыванию на основе требований и подходов, описанных в этой статье.
Корпоративное прикладное программное обеспечение для предприятия
Contoso, Ltd., является крупной производственной компанией. Компания реализует бизнес-приложение для управления некоторыми компонентами финансовых процессов.
бизнес-требования: сведения, которыми управляет система, трудно заменить, поэтому данные должны быть надежно сохранены. Архитекторы говорят, что система должна нести как можно меньше простоев и как можно меньше потери данных. Сотрудники компании Contoso используют систему в течение рабочего дня, поэтому важна высокая производительность, чтобы избежать ожидания членов команды. Стоимость также является проблемой, потому что финансовая команда должна платить за решение.
рекомендуемый подход: зонально избыточное развертывание с резервным копированием по регионам обеспечивает несколько уровней устойчивости с высокой производительностью.
Внутреннее приложение
Четвертый кофе - это небольшой бизнес. Компания разрабатывает новое внутреннее приложение, которое сотрудники могут использовать для отправки расписаний.
бизнес-требования. Для этой рабочей нагрузки эффективность затрат является основной проблемой. Компания "Четвертый Кофе" оценила влияние простоев на бизнес и решила, что приложению не нужно уделять внимание устойчивости или производительности. Компания принимает риск того, что сбой в зоне доступности Azure или регионе может временно сделать приложение недоступным.
предлагаемые подходы:
- локально избыточное развертывание с резервными копиями в разных регионах обладает наименьшей стоимостью, однако значительными рисками.
- Избыточное между зонами развертывание с резервным копированием в разных регионах обеспечивает более высокую устойчивость, но при слегка более высокой стоимости.
Миграция устаревших приложений
Fabrikam, Inc., переносит устаревшее приложение из локального центра обработки данных в Azure. Реализация будет использовать подход IaaS, основанный на виртуальных машинах. Приложение не было разработано для облачной среды, а взаимодействие между уровнем приложений и базой данных очень чат.
бизнес-требования: производительность является приоритетом для этого приложения. Устойчивость также важна, и приложение должно продолжать работать, даже если центр обработки данных Azure испытывает сбой.
предлагаемый подход:
- Fabrikam должно сначала попробовать развертывание с избыточностью между зонами . Они должны проверить производительность в соответствии с их требованиями.
- Если производительность зонально-резервного решения вас не устраивает, рассмотрите зональное (закрепленное) развертывание с пассивными развертываниями в нескольких зонах доступности (в рамках регионального аварийного восстановления).
Приложение для здравоохранения
Компания Lamna Healthcare внедряет новую электронную систему медицинских записей на платформе Azure.
бизнес-требования: из-за характера данных, которые хранятся в этом решении, критически важно место расположения данных. Lamna работает в строгой нормативной базе, которая предписывает, что данные должны оставаться в определенном расположении.
предлагаемые подходы:
- Развертывание в нескольких зонах и регионах, если существует несколько регионов, которые соответствуют требованиям к размещению данных Lamna.
- Если имеется только один регион, который соответствует их требованиям, рассмотрите возможность развертывания с избыточностью между зонами или развертывания с избыточностью между зонами и резервным копированием в разных регионах , что предоставляет решение для одного региона.
Банковская система
Woodgrove Bank выполняет свои основные банковские операции из большого решения, развернутого в Azure.
бизнес-требования: это критически важная система. Любые сбои могут привести к серьезным финансовым последствиям для клиентов. В результате Woodgrove Bank имеет очень низкую устойчивость к риску. Система нуждается в самом высоком уровне надежности, и архитектура должна снизить риск любых сбоев, которые могут быть устранены.
Рекомендуемый подход: Для критически важной системы используйте многозонное и многорегиональное развертывание. Убедитесь, что регионы соответствуют требованиям к месту расположения данных компании.
Программное обеспечение как услуга (SaaS)
Proseware, Inc., создает программное обеспечение, которое используется компаниями по всему миру. База пользователей компании широко распределена по географическому расположению.
бизнес-требования. Proseware необходимо разрешить каждому из своих клиентов выбрать регион развертывания, близкий к клиенту. Включение этого варианта важно для задержки и требований к месту расположения данных клиентов.
предлагаемые подходы:
- многозональное многорегиональное развертывание обычно является хорошим выбором для поставщика SaaS, особенно когда используется в шаблоне Deployment Stamps.
- Зонально избыточное развертывание в одной зоне региона в сочетании с глобальным решением для ускорения трафика, таким как Azure Front Door.
Связанные ссылки
Ниже приведены некоторые эталонные архитектуры и примеры сценариев для решений с несколькими зонами и несколькими регионами:
- Базовые зонально-избыточные высокодоступные веб-приложения
- высокодоступное веб-приложение с несколькими регионами
- многорегиональное приложение n-уровня
- многоуровневое веб-приложение, созданное для высокого уровня доступности и аварийного восстановления
Многие службы Azure предоставляют рекомендации по использованию нескольких зон доступности, включая следующие примеры:
- Azure Site Recovery: включение аварийного восстановления виртуальной машины Azure между зонами доступности
- Azure NetApp Files. Общие сведения о репликации между зонами Azure NetApp Files
- Избыточность хранилища Azure
Контрольный список надежности
Ознакомьтесь с полным набором рекомендаций.
контрольный список надежности