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

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

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

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

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

Определения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Руководство по уровню инфраструктуры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сеть

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

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

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

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

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

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

Упрощение azure

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

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

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

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

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

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

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

Упрощение azure для DNS

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

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

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

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

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

Пример

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

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

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

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

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

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

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

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