Сеть и подключение для критически важных рабочих нагрузок
Для регионального распределения ресурсов в критически важной эталонной архитектуре требуется надежная сетевая инфраструктура.
Глобально распределенное проектирование рекомендуется, когда службы Azure объединяются для предоставления высокодоступного приложения. Глобальная подсистема балансировки нагрузки в сочетании с региональными метками обеспечивает обеспечение надежного подключения.
Региональные метки — это развертываемая единица в архитектуре. Возможность быстрого развертывания новой метки обеспечивает масштабируемость и поддерживает высокий уровень доступности. Стемпы следуют изолированному проектированию виртуальной сети . Перекрестный трафик не рекомендуется. Пиринги виртуальных сетей или VPN-подключения к другим меткам не требуются.
Архитектура намеренно определяет региональные штампы как временные. Глобальное состояние инфраструктуры хранится в глобальных ресурсах.
Глобальная подсистема балансировки нагрузки необходима для маршрутизации трафика на здоровые метки и предоставления служб безопасности. Он должен иметь определенные возможности.
Проверка работоспособности требуется, чтобы подсистема балансировки нагрузки проверяла работоспособность источника перед маршрутизацией трафика.
Распределение взвешированного трафика.
При необходимости он может выполнять кэширование на периферии сети. Кроме того, предоставьте некоторую гарантию безопасности для входящего трафика с помощью брандмауэра веб-приложения (WAF).
Скачайте файл Visio данной архитектуры.
Входящий трафик
Приложение, определенное в архитектуре, имеет доступ к Интернету и имеет несколько требований:
Решение маршрутизации, которое является глобальным и может распределять трафик между независимыми региональными метками.
Низкая задержка при проверке работоспособности и возможность остановки отправки трафика на неисправные участки.
Предотвращение вредоносных атак на границе.
Предоставьте возможности кэширования на границе сети.
Точка входа для всего трафика в архитектуре осуществляется через Azure Front Door. Front Door — это глобальный балансировщик нагрузки, который направляет HTTP(S) трафик на зарегистрированные бэкэнды или источники. Front Door использует пробы работоспособности, которые отправляют запросы к URI на каждом сервере или источнике. В эталонной реализации вызывается URI, представляющий собой службу проверки работоспособности. Служба здравоохранения рекламирует здоровье штампа. Front Door использует ответ для определения работоспособности отдельных меток и маршрутизации трафика на здоровые метки, способные обслуживать запросы приложений.
Интеграция Azure Front Door с Azure Monitor обеспечивает практически в реальном времени мониторинг трафика, безопасности, успешности и сбоев и оповещений.
Брандмауэр веб-приложений Azure, интегрированный с Azure Front Door, используется для предотвращения атак на границе перед вводом в сеть.
Изолированная виртуальная сеть — API
API в архитектуре использует виртуальные сети Azure в качестве границы изоляции трафика. Компоненты в одной виртуальной сети не могут напрямую взаимодействовать с компонентами в другой виртуальной сети.
Стандартный внешний Azure Load Balancer распределяет запросы на платформу приложений. Он проверяет, что трафик, достигающий подсистемы балансировки нагрузки, был перенаправлен через Azure Front Door, гарантируя, что Azure WAF проверяет весь трафик.
Агенты сборки, используемые для операций и развертывания архитектуры, должны быть в состоянии связаться с изолированной сетью. Изолированная сеть может быть открыта, чтобы позволить агентам взаимодействовать. Кроме того, локальные агенты можно развернуть в виртуальной сети.
Требуется мониторинг пропускной способности сети, производительность отдельных компонентов и работоспособность приложения.
Зависимость взаимодействия платформы приложений
Платформа приложений, используемая с отдельными метками в инфраструктуре, имеет следующие требования к обмену данными:
Платформа приложений должна безопасно взаимодействовать со службами Microsoft PaaS.
Платформа приложений должна безопасно взаимодействовать с другими службами при необходимости.
Архитектура, как определено, использует Azure Key Vault для хранения секретов, таких как строки подключения и ключи API, для безопасного обмена данными через Интернет со службами PaaS Azure. Существуют потенциальные риски при открытии платформы приложений через Интернет в рамках этого взаимодействия. Секретная информация может быть скомпрометирована, поэтому рекомендуется усилить безопасность и мониторинг общедоступных конечных точек.
Рекомендации по расширенным сетям
В этом разделе рассматриваются преимущества и недостатки альтернативных подходов к проектированию сети. Альтернативные сетевые аспекты и использование частных конечных точек Azure являются основной темой в следующих разделах.
Подсети и группы безопасности сети
Подсети в виртуальных сетях можно использовать для сегментирования трафика в структуре. Изоляция подсети отделяет ресурсы для различных функций.
Группы безопасности сети можно использовать для управления трафиком, разрешенным в каждой подсети и выходом из нее. Правила, используемые в группах безопасности сети, можно использовать для ограничения трафика на основе IP-адресов, портов и протокола для блокировки нежелательного трафика в подсети.
Частные конечные точки — вход
Версия Front Door уровня "Премиум" поддерживает использование частных конечных точек Azure. Частные конечные точки предоставляют службе Azure частный IP-адрес в виртуальной сети. Подключения выполняются безопасно и приватно между службами без необходимости маршрутизации трафика на общедоступные конечные точки.
Azure Front Door Premium и приватные конечные точки Azure обеспечивают полностью частные вычислительные кластеры в отдельных регионах. Трафик полностью заблокирован для всех служб Azure PaaS.
Использование частных конечных точек повышает безопасность проектирования. Однако он вводит еще одну точку сбоя. Общедоступные конечные точки, предоставляемые в метках приложений, больше не нужны и больше не могут быть доступны и подвержены возможной атаке DDoS.
Повышенная безопасность должна быть взвешена по сравнению с повышенными усилиями для повышения надежности, затратами и сложностью.
Для развертывания меток необходимо использовать локальные агенты сборки. Управление этими агентами связано с затратами на обслуживание.
Частные конечные точки — платформа приложений
Частные конечные точки поддерживаются для всех служб PaaS Azure, используемых в этой структуре. При использовании частных конечных точек, настроенных для платформы приложений, весь обмен данными будет проходить через виртуальную сеть системы.
Общедоступные конечные точки отдельных служб PaaS Azure можно настроить для запрета общедоступного доступа. Этот процесс изолирует ресурсы от публичных атак, которые могут привести к простою и ограничению, влияющим на надежность и доступность.
Для развертывания меток необходимо использовать агенты локальной сборки, аналогичные предыдущему. Управление этими агентами связано с затратами на обслуживание.
Дальнейшие действия
Разверните эталонную реализацию, чтобы получить полное представление о ресурсах и их конфигурации, используемой в этой архитектуре.
Реализация : Mission-Critical Online