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

Внимание

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

В большинстве случаев вам не потребуется архитектура, описанная в этой статье.

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

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

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

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

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

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

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

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

Подход

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

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

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

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

   Внимание

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

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

2. У вас есть два пути входящего трафика:

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

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

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

3. Серверы приложений-источника должны быть готовы к приему трафика из любой службы. Рассмотрим, как вы защищаете трафик к источнику, и какие обязанности предоставляют 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 для альтернативного пути входящего трафика. Этот подход можно рассматривать для поддержки целевой цели надежности приложения. Однако это не рекомендуется.

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

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

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

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

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

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

Цепочка CNAME

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

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

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

Моделирование работоспособности

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

Включите следующие вопросы в структуру модели работоспособности:

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

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

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

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

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

Совет

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

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

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

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

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

Предупреждение

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

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

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

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

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

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

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

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

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

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

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

Предупреждение

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

Следующие шаги

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