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

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

Архитектура для миссии-критичных приложений использует Azure Front Door из-за высокой доступности (SLA) и богатого набора функций:

• Маршрутизация трафика в несколько регионов в модели "активный-активный" или "активный-пассивный"
• Автоматическое перенаправление на следующую оптимальную точку присутствия (PoP) при неисправности точки присутствия (PoP)
• Обслуживание статического содержимого с пограничных узлов с помощью интегрированных сетей доставки содержимого (CDN)
• Блокировка несанкционированного доступа с помощью брандмауэра встроенного веб-приложения

Дополнительные сведения о возможностях Azure Front Door см. в разделе Ускорьте и защитите ваше веб-приложение с помощью Azure Front Door.

Azure Front Door предназначен для обеспечения максимальной надежности и доступности не только для внешних клиентов, но и для нескольких активов Майкрософт. Хотя корпорация Майкрософт предлагает передовое в отрасли соглашение об уровне обслуживания (SLA) для Azure Front Door, если у вас есть критически важное приложение, требующее еще более высокого SLA, вам потребуется реализовать дополнительные пути входящего трафика.

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

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

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

В этой статье описываются стратегии глобальной маршрутизации. Эти стратегии используют Azure Traffic Manager для направления трафика к альтернативному маршрутизатору, если Azure Front Door недоступны.

Подход

На этой схеме архитектуры показан общий подход с несколькими избыточными путями трафика.

Этот подход представляет несколько компонентов и предоставляет рекомендации, которые вносят значительные изменения, связанные с доставкой веб-приложений:

• Traffic Manager направляет трафик в Azure Front Door или в выбранную альтернативную службу.

  Диспетчер трафика — это глобальная подсистема балансировки нагрузки на основе DNS. Запись CNAME домена указывает на диспетчер трафика, который определяет назначение на основе настройки метода маршрутизации. Для критически важной архитектуры рекомендуется использовать взвешанный метод маршрутизации. Этот метод можно настроить для отправки некоторых или всех трафика в разные конечные точки. В обычных операциях весь трафик обычно направляется через Azure Front Door.

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

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

• У вас есть два входных пути:

  • Azure Front Door предоставляет основной путь. В обычных операциях он обрабатывает и направляет весь или большую часть трафика приложения.

  • Другой маршрутизатор служит резервным копированием для Azure Front Door. Трафик проходит через этот вторичный путь, если Azure Front Door становится недоступным.

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

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

Компромиссы

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

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

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

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

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

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

Доступность диспетчера трафика

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

Диспетчер трафика возвращает кэшируемые ответы DNS. Если время жизни (TTL) в записях DNS позволяет кэширование, короткие сбои диспетчера трафика могут не быть проблемой. Это связано с тем, что подчиненные сопоставители DNS, возможно, кэшировали предыдущий ответ. Вам стоит подготовиться к длительным перебоям. Вы можете вручную перенастроить DNS-серверы для направления пользователей в Azure Front Door если диспетчер трафика недоступен.

Согласованность маршрутизации трафика

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

При планировании альтернативного пути трафика следует учитывать некоторые ключевые вопросы:

• Используются ли функции кэширования Azure Front Door? Если кэширование недоступно, могут ли серверы-источники следить за трафиком?
• Используется ли подсистема правил Azure Front Door для выполнения пользовательской логики маршрутизации или для перезаписи запросов?
• Используете ли вы брандмауэр веб-приложения Azure Front Door (WAF) для защиты приложений?
• Ограничиваете ли вы трафик на основе IP-адреса или географического положения?
• Кто выдает и управляет вашими сертификатами TLS?
• Как ограничить доступ к серверам исходных приложений, чтобы обеспечить его прохождение через Azure Front Door? Вы используете Private Link или используете общедоступные IP-адреса с тегами служб и заголовками идентификаторов?
• Серверы приложений принимают трафик из любого места, кроме Azure Front Door? Если они делают, какие протоколы они принимают?
• Используют ли ваши клиенты поддержку HTTP/2 в Azure Front Door?

Межсетевой экран веб-приложений (WAF)

Если вы используете WAF Azure Front Door для защиты приложения, рассмотрите, что происходит, если трафик не проходит Azure Front Door.

Если альтернативный путь также предоставляет WAF, рассмотрите следующие вопросы:

• Можно ли настроить его так же, как и Azure Front Door WAF?
• Нужно ли настраивать и тестировать его независимо, чтобы снизить вероятность ложноположительных обнаружений?

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

Наилучше было бы защитить все пути к серверам приложений.

Дополнительные рекомендации по обеспечению высокого уровня доступности

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

Доменные имена и DNS

Критически важное приложение должно использовать имена пользовательских доменов для управления потоками трафика в приложение и уменьшения зависимостей от одного поставщика. При планировании подхода DNS следует учитывать следующие моменты:

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

• Сопоставители DNS: Рекомендуется использовать несколько сопоставителей DNS для повышения общей устойчивости.

• Домены apex: При использовании диспетчера трафика вы используете CNAME, чтобы указать доменное имя в профиль диспетчера трафика. Стандарты DNS не позволяют создавать CNAME в вершине домена (или корневом каталоге). Разместите домен DNS на Azure DNS и используйте записи alias, чтобы указать профиль диспетчера трафика.

• CNAME chaining: Solutions, которые объединяют Traffic Manager, Azure Front Door и другие службы, используют многоуровневый процесс резолвинга DNS CNAME, который также называется CNAME chaining. Например, при разрешении собственного личного домена может появиться пять или более записей CNAME перед возвратом IP-адреса.

  Добавление дополнительных ссылок в цепочку CNAME может повлиять на производительность разрешения DNS-имен. Но ответы DNS обычно кэшируются, что снижает влияние на производительность.

Сертификаты TLS

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

Ниже приведены некоторые преимущества.

• Чтобы выдавать и обновлять управляемые сертификаты TLS, Azure Front Door проверяет владение доменом. Процесс проверки домена предполагает, что записи CNAME домена указывают непосредственно на Azure Front Door. Но это предположение часто не является правильным. Выдача и продление управляемых сертификатов TLS на Azure Front Door может не работать гладко, и вы повышаете риск сбоя из-за проблем с сертификатом TLS.

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

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

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

Безопасность источника

При настройке источника только для приема трафика через Azure Front Door вы получаете защиту от атак уровня 3 и уровня 4 DDoS. Azure Front Door реагирует только на действительный HTTP-трафик, что также помогает уменьшить вашу уязвимость перед многими угрозами на основе протокола. Если вы изменяете архитектуру, чтобы разрешить альтернативные пути входа, необходимо оценить, не увеличили ли вы случайно воздействие угроз на ваш источник.

Если вы используете Private Link для подключения из Azure Front Door к исходному серверу, как трафик проходит через альтернативный путь? Можно ли использовать частные IP-адреса для доступа к источникам или использовать общедоступные IP-адреса?

Если в вашем происхождении используется тег службы Azure Front Door и заголовок X-Azure-FDID для проверки того, что трафик прошел через Azure Front Door, рассмотрите возможность перенастроить ваши происхождения для проверки того, что трафик прошел через любой из ваших допустимых маршрутов. Необходимо проверить, что вы не случайно открыли источник для трафика через другие пути, в том числе из профилей Azure Front Door других клиентов.

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

Если есть выделенные общедоступные IP-адреса, рассмотрите, следует ли реализовать Azure защиту от атак DDoS, чтобы снизить риск атак типа "отказ в обслуживании" против ваших источников. Кроме того, следует ли реализовать Azure Firewall или другой брандмауэр, способный защитить вас от различных сетевых угроз. Кроме того, вам может потребоваться больше стратегий обнаружения вторжений. Эти элементы управления могут быть важными элементами в более сложной многопутьной архитектуре.

Моделирование состояния здоровья

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

Включите эти вопросы в дизайн модели здоровья:

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

Мониторинг здоровья

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

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

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

Процедуры реагирования

Если системы мониторинга обнаруживают, что Azure Front Door недоступна, перенастройьте диспетчер трафика, чтобы направить весь трафик через альтернативный путь. Используйте один из следующих подходов:

• Вручную определите сбой: Вручную отключите конечную точку в профиле диспетчера трафика. Дополнительные сведения см. в статье "Добавление, отключение, включение, удаление или перемещение конечных точек".

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

  • Azure CLI
  • Azure PowerShell
  • REST API Azure REST API

  az network traffic-manager endpoint update \
      --resource-group MyRG \
      --profile-name MyProfile \
      --name MyEndpoint \
      --type externalEndpoints \
      --endpoint-status Disabled
  

  Дополнительные сведения см. в статье az network traffic-manager endpoint update.

Несколько факторов влияют на время, в течение которого сбой влияет на ваш трафик, в том числе:

• Значения TTL записи DNS

• Источник обнаружения сбоев (диспетчер трафика или настраиваемый мониторинг)

• Частота проверки состояния

• Порог отказа проверки работоспособности перед перенаправлением трафика

• Длительность клиентского и вышестоящего DNS-кэша для ответов диспетчера трафика

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

См. критически важную область проектирования: моделирование здоровья

Устойчивые процессы перенастройки

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

При планировании стратегии аварийного восстановления избегайте зависимости от одного инструмента, например портала Azure, в случае нарушения его подключения. Узнайте, как использовать такие средства, как Azure CLI, Azure PowerShell или REST API для выполнения задач перенастройки, таких как перенаправка трафика. Дополнительные сведения о примерах команд для сценариев аварийного переключения см. в процедурах реагирования.

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

См. раздел : Критически важная область проектирования: развертывание без простоя

Непрерывная проверка

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

Убедитесь, что процессы тестирования включают следующие элементы:

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

См. раздел: критически важные области проектирования: непрерывная проверка

Распространенные сценарии

Ниже приведены распространенные сценарии, в которых можно использовать эту структуру:

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

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

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основные авторы:

• Dave Burkhardt | Главный диспетчер программ, Azure Front Door
• John Downs | Ведущий инженер-программист, Azure шаблоны и практики
• Ахил Кармалькар | Главный диспетчер программ, Azure Front Door
• Priyanka Wilkins | Ведущий разработчик содержимого, Azure шаблоны и практики

Чтобы просмотреть непубличные профили на LinkedIn, войдите в свой аккаунт.

Дальнейшие шаги

• Архитектурные рекомендации для Azure Front Door
• Рекомендации по архитектуре диспетчера трафика

Связанные ресурсы

• Критически важный глобальный входной поток HTTP
• Критически важная глобальная доставка контента