Обеспечение избыточности всех компонентов

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

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

Рекомендации

Оцените бизнес-требования. Степень избыточности системы влияет на ее стоимость и сложность. Архитектура должна быть проинформирована вашими бизнес-требованиями, такими как цель времени восстановления (RTO) и цель точки восстановления (RPO). Вы также должны учитывать требования к производительности и возможность вашей команды управлять сложными наборами ресурсов.

Рассмотрим архитектуры с несколькими зонами и несколькими регионами. Убедитесь, что вы понимаете, как зоны доступности и регионы обеспечивают устойчивость и различные наборы архитектурных компромиссов.

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

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

Совет

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

Дополнительные сведения о том, как разработать решение для использования зон доступности и регионов, см. в Рекомендации по использованию зон доступности и регионов.

Разместите виртуальные машины за подсистемой балансировки нагрузки. Не допускайте, чтобы критически важные рабочие нагрузки выполнялись только на одной виртуальной машине. Используйте сразу несколько виртуальных машин, подключенных к подсистеме балансировки нагрузки. Если какая-либо виртуальная машина станет недоступной, подсистема балансировки нагрузки переместит трафик на работоспособные виртуальные машины. Сведения о развертывании этой конфигурации см. в статье [Несколько виртуальных машин для масштабируемости и доступности][много vm-blueprint].

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

Если вы используете решение базы данных IaaS, выберите ее, которая поддерживает реплика tion и отработку отказа, например группы доступности Sql Server AlwaysOn.

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

Решения с несколькими регионами

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

Если вы используете Диспетчер трафика в решении с несколькими регионами, рассмотрите следующие рекомендации:

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

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

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

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