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

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

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

определения

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

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

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

Компромиссы:

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

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

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

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

Предпочитать бессерверные и полностью управляемые службы, чтобы снизить рабочее бремя

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

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

Глобальные службы со встроенной избыточностью: Службы, такие как Идентификатор Microsoft Entra, Azure DNS и Azure Key Vault, работают в качестве глобальных служб с автоматической избыточностью в нескольких регионах. Эти службы обеспечивают устойчивость, не требуя от вас какой-либо конфигурации избыточности. Они автоматически обрабатывают сценарии отработки отказа и восстановления прозрачно.

Абстрактные модели емкости: Предложения, такие как Azure Cosmos DB, Azure Databricks и управляемые конечные точки Azure OpenAI, абстрагируют сложность базовой инфраструктуры за единицами емкости, DTU или другими логическими метриками. Эти службы автоматически распределяют рабочую нагрузку между несколькими экземплярами, зонами и регионами, предоставляя упрощенную модель выставления счетов и управления. Вместо управления отдельными избыточными экземплярами необходимо указать требования к емкости.

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

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

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

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

Вычислительные ресурсы:

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

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

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

Ресурсы данных:

• Репликация данных в географических регионах для обеспечения устойчивости к региональным сбоям и катастрофическим сбоям.

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

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

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

• Автоматизация отработки отказа после сбоя экземпляра базы данных. Вы можете настроить автоматическую отработку отказа в нескольких службах данных PaaS Azure. Автоматическая отработка отказа не требуется для хранилищ данных, поддерживающих записи в нескольких регионах, таких как Azure Cosmos DB. Дополнительные сведения см. в рекомендациях по разработке стратегии аварийного восстановления.

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

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

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

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

Сетевые ресурсы:

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

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

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

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

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

• Убедитесь, что ваша конструкция для обработки системы доменных имен (DNS) создана с акцентом на устойчивость и поддерживает избыточность инфраструктуры.

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

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

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

Независимо от того, развертываются ли метки в активной модели (где все метки активно обслуживают трафик одновременно) или активно-пассивной модели (где одна метка служит трафику, а другие остаются в режиме ожидания), создайте каждую метку для полного самодостаточного развертывания, которое может обрабатывать определенную рабочую нагрузку независимо.

Обеспечение нулевого простоя с помощью избыточности "активный— активный"

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

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

В следующих разделах описаны параметры конфигурации для развертываний active-active.

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

  • Сети: Используйте задержку или взвешированную глобальную маршрутизацию для распространения трафика между расположениями.

  • Репликация и согласованность данных: Используйте глобально распределенное хранилище данных, например Azure Cosmos DB , для возможностей чтения и записи в нескольких регионах. Для реляционных баз данных используйте доступные для чтения реплики со строками подключения только для чтения.

  • Преимущества этого дизайна: Более низкие операционные затраты, чем перепроизбыточная конструкция.

  • Недостаток этого дизайна: Возможное снижение взаимодействия с пользователем при масштабировании до удовлетворения требований полной нагрузки, если другое расположение испытывает сбой.

• Активно-активный перепроизбыток: Зеркальные метки развертывания в двух или нескольких расположениях, каждая из которых перепроизложена для обработки рабочих нагрузок для расположения или расположений, которые они служат, и для обработки нагрузки из других расположений при возникновении регионального сбоя.

  • Сети: Используйте задержку или взвешированную глобальную маршрутизацию для распространения трафика между расположениями.

  • Репликация и согласованность данных: Используйте глобально распределенное хранилище данных, например Azure Cosmos DB , для возможностей чтения и записи в нескольких регионах. Для реляционных баз данных используйте доступные для чтения реплики со строками подключения только для чтения.

  • Преимущества этого дизайна: Самый устойчивый дизайн.

  • Недостаток этого дизайна: Более высокие операционные затраты, чем масштабируемая конструкция.

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

• Распространенные недостатки обоих конструкций: Более высокие операционные затраты и бремя управления из-за различных факторов, включая необходимость управления синхронизацией состояния приложения и данных.

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

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

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

Рассмотрим следующие варианты конфигурации для активных пассивных развертываний.

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

  • Сети: Используйте глобальную маршрутизацию приоритета .

  • Репликация и согласованность данных: Репликация базы данных в пассивное расположение и использование возможностей автоматической отработки отказа решений PaaS, таких как Azure Cosmos DB и База данных SQL Azure.

  • Преимущества этого дизайна: Самое короткое время восстановления среди активных пассивных конструкций.

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

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

  • Сети: Используйте глобальную маршрутизацию приоритета .

  • Репликация и согласованность данных: Репликация базы данных в пассивное расположение и использование возможностей автоматической отработки отказа решений PaaS, таких как Azure Cosmos DB и База данных SQL.

  • Преимущества этого дизайна: Более низкие операционные затраты, чем теплый запасный дизайн.

  • Недостаток этого дизайна: Продолжительное время восстановления, чем теплое резервное проектирование.

Распределение рабочих нагрузок между независимой инфраструктурой

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

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

Повышение отказоустойчивости с помощью гео удаленных развертываний

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

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

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

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

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

• Обеспечивает встроенную избыточность с множеством решений PaaS и SaaS, некоторые из которых можно настроить.

• Предоставляет глобальные управляемые службы, такие как Идентификатор Microsoft Entra, Azure DNS и Key Vault, которые прозрачно реализуют избыточность без необходимости настройки.

• Позволяет разрабатывать и реализовывать избыточность внутри региона с помощью зон доступности и избыточности между регионами.

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

• Предоставляет службы балансировки нагрузки с поддержкой реплик, такие как шлюз приложений Azure, Azure Front Door и Azure Load Balancer.

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

• Предоставляет возможности восстановления на определенный момент времени (PITR) для многих служб данных PaaS.

• Устраняет нехватку портов через шлюз NAT Azure или брандмауэр Azure.

Упрощение служб Azure для конкретного DNS

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

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

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

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

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

Включите защиту от удаления, чтобы обеспечить сохранение избыточности

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

Компромисс: Применение блокировок замедляет допустимые действия восстановления и может создавать операционные трения. Замки блокируют удаление ресурсов, но не изменения и данные внутри ресурса. Рассматривайте блокировки как тонкую сеть безопасности, которая дополняет, никогда не заменяет, резервные копии, репликацию и управление доступом.

Example

Пример избыточного развертывания с несколькими регионами см. в разделе "Базовый высокодоступный веб-приложение с высоким уровнем доступности".

На следующей схеме показан другой пример.

Связанные ссылки

Дополнительные сведения о избыточности см. в следующих ресурсах:

• Руководство по регионам Azure
• Избыточность службы хранилища Azure
• Хранилище, избыточное между зонами
• Активная георепликация базы данных SQL
• Настройка репликации между двумя управляемыми экземплярами

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

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