Рекомендации по проектированию избыточности

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

Связанные руководства. Высокодоступная многорегиональное проектирование | с помощью зон доступности и регионов

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

Определения

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

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

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

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

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

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

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

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

Разработка избыточной архитектуры

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

Метки развертывания и единицы масштабирования

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

Зоны доступности в регионах Azure

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

Реализация избыточности зоны для вычислительных ресурсов

• Выберите соответствующую службу вычислений для рабочей нагрузки. В зависимости от типа рабочей нагрузки, которую вы разрабатываете, могут быть доступны несколько вариантов. Изучите доступные службы и понять, какие типы рабочих нагрузок лучше всего работают в данной вычислительной службе. Например, рабочие нагрузки SAP обычно лучше подходят для служб вычислений инфраструктуры как службы (IaaS). Для контейнерного приложения определите определенные функциональные возможности, которые необходимо контролировать, чтобы определить, следует ли использовать Служба Azure Kubernetes (AKS) или платформу как службу (PaaS). Облачная платформа полностью управляет службой PaaS.

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

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

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

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

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

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

Реализация избыточности зоны для ресурсов данных

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

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

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

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

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

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

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

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

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

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

Реализация избыточности зоны для сетевых ресурсов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример

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

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

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

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

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

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

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