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

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

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

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

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

Azure Front Door предназначен для обеспечения максимальной устойчивости и доступности не только для наших внешних клиентов, но и для нескольких объектов внутри корпорации Microsoft. Возможности Azure Front Door более чем достаточно для удовлетворения большинства бизнес-требований, однако с любой распределенной системой ожидают сбоя. Компонент или система не являются непобедимыми. Корпорация Майкрософт предлагает соглашение об уровне обслуживания в отрасли (SLA) для Azure Front Door. Даже если другой поставщик предлагает соглашение об уровне обслуживания с бесперебойной работой на 100%, важно отметить, что это не гарантирует отсутсвие простоев, и что такие соглашения обычно предусматривают предоставление кредитов за обслуживание в случае сбоя.

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

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

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

Подход

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

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

1. Диспетчер трафика Azure направляет трафик в Azure Front Door или в альтернативную службу, которую вы выбрали.

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

   Это важно

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

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

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

   • Azure Front Door предоставляет основной путь и процессы и маршрутизирует весь трафик приложения.

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

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

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

Компромиссы

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

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

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

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

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

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

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

Диспетчер трафика Azure — это надежная служба с соглашением об уровне обслуживания в отрасли, но служба управления трафиком не может гарантировать 100% доступности. Если диспетчер трафика недоступен, пользователи могут не иметь доступа к приложению, даже если 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? Вы используете приватный канал или используете общедоступные IP-адреса с тегами службы и заголовками идентификаторов?
• Серверы приложений принимают трафик из любого места, кроме Azure Front Door? Если они делают, какие протоколы они принимают?
• Используют ли ваши клиенты поддержку HTTP/2 в Azure Front Door?

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

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

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

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

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

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

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

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

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

Критически важное приложение должно использовать имя личного домена. Вы будете контролировать потоки трафика в приложение и сократить зависимости от одного поставщика.

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

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

Цепочка CNAME

Решения, которые объединяют Traffic Manager, Azure Front Door и другие службы, используют многоуровневый процесс разрешения CNAME DNS, также называемый цепочкой CNAME. Например, при разрешении собственного личного домена может появиться пять или более записей 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-трафик, который также помогает снизить риск для многих угроз на основе протокола. Если вы изменяете архитектуру, чтобы разрешить альтернативные пути входа, необходимо оценить, не увеличили ли вы случайно воздействие угроз на ваш источник.

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

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

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

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

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

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

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

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

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

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

• Время жизни (TTL) в записях DNS.
• Как часто Traffic Manager проводит проверки состояния здоровья.
• Сколько неудачных проб диспетчер трафика настроен на просмотр, прежде чем он перенаправляет трафик.
• Как долго клиенты и внешние DNS-серверы кэшируют DNS-ответы Диспетчера трафика.

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

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

Развертывание без простоя

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

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

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

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

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

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

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

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

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

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

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

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

Соавторы

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

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

• Дэйв Беркхардт | Главный диспетчер программ, Azure Front Door
• Джон Даунс | Главный инженер программного обеспечения
• Приянка Уилкинс | Разработчик основного содержимого

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

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

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