Обеспечение избыточности всех компонентов
Обеспечьте избыточность приложения, чтобы устранить все единые точки отказа.
Надежное приложение спокойно обходит любые сбои. Определите критические пути в приложении. Обеспечена ли избыточность для каждой точки этого пути? Когда подсистема завершается сбоем, отработка отказа приложения на что-нибудь другое?
В идеальной реализации добавление универсальной избыточности может экспоненциально увеличить доступность системы. Например, представьте, что у вас есть N эквивалентные, равные сбалансированные компоненты, которые:
- может неисправно и одновременно удален из пула
- имеют идентичное состояние или нет состояния
- не имеет работы, которая постоянно теряется во время сбоя
- идентичны в возможностях
- не зависят друг от друга
- обрабатывает сокращение емкости без дополнительной неисправности
Если у каждого отдельного компонента есть доступность A, можно вычислить общую доступность системы с помощью формулы 1 - (1 - A)^N.
Рекомендации
Оцените бизнес-требования. Степень избыточности системы влияет на ее стоимость и сложность. Архитектура должна быть проинформирована вашими бизнес-требованиями, такими как цель времени восстановления (RTO) и цель точки восстановления (RPO). Вы также должны учитывать требования к производительности и возможность вашей команды управлять сложными наборами ресурсов.
Рассмотрим архитектуры с несколькими зонами и несколькими регионами. Убедитесь, что вы понимаете, как зоны доступности и регионы обеспечивают устойчивость и различные наборы архитектурных компромиссов.
Зоны доступности Azure являются изолированными наборами центров обработки данных в пределах региона. Используя зоны доступности, вы можете быть устойчивыми к сбоям одного центра обработки данных или всей зоны доступности. Зоны доступности можно использовать для компромисса между затратами, устранением рисков, производительностью и возможностью восстановления. Например, при использовании избыточных между зонами служб в архитектуре Azure обеспечивает автоматическую репликацию данных и отработку отказа между географически разделенными экземплярами, что снижает множество различных типов рисков.
Если у вас есть критически важные рабочие нагрузки и необходимо снизить риск сбоя на уровне региона, рассмотрите возможность развертывания в нескольких регионах. Хотя развертывания с несколькими регионами изолируют вас от региональных бедствий, они поставляются по стоимости. Развертывания с несколькими регионами дороже, чем развертывание в одном регионе, и более сложны для управления. Вам потребуются операционные процедуры для обработки отработки отказа и восстановления размещения. В зависимости от требований RPO может потребоваться принять немного более низкую производительность, чтобы включить репликацию данных между регионами. Дополнительные затраты и сложности могут быть оправданы для некоторых бизнес-сценариев.
Совет
Для многих рабочих нагрузок архитектура с избыточностью между зонами обеспечивает лучший набор компромиссов. Рассмотрим архитектуру с несколькими регионами, если бизнес-требования указывают на то, что вам нужно устранить маловероятное риск сбоя на уровне региона, и если вы готовы принять компромиссы, участвующие в таком подходе.
Дополнительные сведения о разработке решения для использования зон доступности и регионов см . в рекомендациях по использованию зон доступности и регионов.
Разместите виртуальные машины за подсистемой балансировки нагрузки. Не допускайте, чтобы критически важные рабочие нагрузки выполнялись только на одной виртуальной машине. Используйте сразу несколько виртуальных машин, подключенных к подсистеме балансировки нагрузки. Если какая-либо виртуальная машина станет недоступной, подсистема балансировки нагрузки переместит трафик на работоспособные виртуальные машины.
Реплицируйте базы данных. База данных SQL Azure и Azure Cosmos DB автоматически реплицируют данные в регионе и могут быть настроены для репликации между зонами доступности для повышения устойчивости. Вы также можете включить георепликацию между регионами. Георепликация для База данных SQL Azure и Azure Cosmos DB создает вторичные реплики для чтения данных в одном или нескольких дополнительных регионах. Если сбой происходит в основном регионе, база данных может выполнить отработку отказа в дополнительный регион для записи. В зависимости от конфигурации репликации может возникнуть некоторая потеря данных из нерасположенных транзакций.
Если вы используете решение базы данных IaaS, выберите ее, которая поддерживает репликацию и отработку отказа, например группы доступности SQL Server AlwaysOn.
Используйте секционирование для повышения доступности. Секционирование базы данных чаще применяется для масштабируемости, но оно позволяет повысить и доступность. Если один сегмент выходит из строя, остальные остаются доступными. Сбой одного сегмента повлияет только на некоторую часть транзакций.
Проверьте и проверьте избыточные компоненты. Преимущества надежности во многих отношениях от простоты и добавления избыточности могут повысить сложность. Чтобы убедиться, что добавление избыточности фактически приводит к повышению доступности, необходимо проверить следующее:
- Может ли ваша система надежно обнаруживать здоровые и неработоспособные избыточные компоненты, а также безопасно и оперативно удалять их из пула компонентов?
- Может ли система надежно масштабировать и в избыточных компонентах?
- Могут ли ваши обычные, нерегламентированные и экстренные рабочие нагрузки обрабатывать избыточность?
Решения с несколькими регионами
На схеме ниже представлено приложение в нескольких регионах, для которого диспетчер трафика Azure управляет отработкой отказа.
Если вы используете Диспетчер трафика или Azure Front Door в решении с несколькими регионами в качестве механизма маршрутизации отработки отказа, рассмотрите следующие рекомендации:
Синхронизируйте отработку отказа для интерфейсной и серверной частей приложения. Используйте механизм маршрутизации для отработки отказа внешнего интерфейса. Если интерфейс становится недоступным в одном регионе, отработка отказа перенаправит новые запросы в дополнительный регион. В зависимости от компонентов серверной части и решения базы данных может потребоваться координировать отработку отказа внутренних служб и баз данных.
Используйте автоматическую отработку отказа, но восстановление размещения выполняйте вручную. Используйте автоматизацию для отработки отказа, но не для восстановления размещения. Автоматическое восстановление размещения может привести к тому, что приложение вернется в основной регион раньше, чем он полностью восстановит работоспособность. Сначала следует убедиться, что все подсистемы приложения полностью работоспособны, и после этого вручную выполнить восстановление размещения. Кроме того, перед восстановлением размещения необходимо проверить согласованность данных.
Для этого отключите основную конечную точку после отработки отказа. Обратите внимание, что если интервал мониторинга проб короткий и допустимое количество сбоев невелико, отработка отказа, а также восстановление размещения будет происходить в течение короткого времени. В некоторых случаях отключение не будет завершено вовремя. Чтобы избежать отмены восстановления размещения, рекомендуется также реализовать конечную точку работоспособности, которая может проверить работоспособность всех подсистем. См. шаблон мониторинга конечных точек работоспособности.
Включите избыточность для решения маршрутизации. Рассмотрите возможность разработки решения глобальной избыточности маршрутизации для критически важных веб-приложений.