Развертывание высокодоступных сетевых виртуальных устройств (NVAs)

В этой статье описываются распространенные способы развертывания набора виртуальных сетевых устройств (NVA) для обеспечения высокой доступности в Azure. NVA обычно управляет потоком трафика между сегментами сети с различными уровнями безопасности. Например, можно использовать NVA между виртуальной сетью периметра и Интернетом, или для подключения внешних объектов к Azure через VPN или программно-определяемую глобальную сеть (SD-WAN).

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

Многие шаблоны проектирования используют NVA для проверки трафика между различными зонами безопасности. Эти шаблоны могут использовать NVAs для:

  • Проверьте исходящий трафик из виртуальных машин в Интернет и предотвратите кражу данных.

  • Проверьте входящий трафик из Интернета в виртуальные машины и предотвратите атаки.

  • Фильтрация трафика между виртуальными машинами в Azure, чтобы предотвратить боковое перемещение скомпрометированных систем.

  • Фильтрация трафика между локальными системами и виртуальными машинами Azure, особенно если они относятся к разным уровням безопасности. Например, Azure размещает периметральную сеть, а локальная среда размещает внутренние приложения.

  • Завершите VPN- или SD-WAN-туннели из внешних местоположений, таких как локальные сети или другие общедоступные облака.

В проект Azure можно добавить следующие NVA с помощью шаблонов в этой статье:

  • Сетевые брандмауэры
  • Обратные прокси-серверы уровня 4
  • Конечные точки VPN с защитой по протоколу IPsec
  • бытовые приборы SD-WAN
  • Веб-серверы обратного прокси с функциями брандмауэра веб-приложений (WAF)
  • Интернет-прокси, чтобы ограничить доступ к интернет-страницам из Azure
  • Подсистемы балансировки нагрузки уровня 7

Azure родные NVA, такие как Azure Firewall и Azure Application Gateway, используют проекты, описанные далее в этой статье. Эти параметры следует понимать с точки зрения проектирования и для устранения неполадок сети.

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

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

  • Время конвергенции: Время, затрачиваемое каждым дизайном на перенаправление трафика от вышедшего из строя экземпляра NVA

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

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

Замечание

В этой статье рассматриваются звено-лучевые конструкции. Он не охватывает Azure Virtual WAN так как он содержит более подробные рекомендации по развертыванию NVA в зависимости от того, поддерживает ли центр Virtual WAN конкретный NVA. Дополнительные сведения см. в разделе NVAs в концентраторе Virtual WAN.

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

Общие сведения об архитектуре высокого уровня доступности

Решение Преимущества Соображения
Балансировщик нагрузки Это решение поддерживает активные/активные и активные/резервные конфигурации, а также сетевые виртуальные устройства (NVA) с возможностью расширения и хорошим временем конвергенции. NVA должен предоставить порт для проб работоспособности, особенно для активных и резервных развертываний. Для устройств с отслеживанием состояния, таких как брандмауэры, требующие симметрии трафика, потоки данных в Интернет и из Интернета требуют SNAT.
Сервер маршрутизации Azure NVA должен поддерживать протокол граничного шлюза (BGP). Это решение поддерживает активные и активные, активные, резервные и масштабируемые NVAs. Для симметрии трафика требуется SNAT в этом решении.
Подсистема балансировки нагрузки шлюза Симметрия трафика гарантируется без SNAT. Виртуальные сети могут быть общими для клиентов. Это решение имеет хорошее время конвергенции и поддерживает активные и активные, активные и резервные и масштабируемые NVAs. Это решение поддерживает потоки и из Интернета и не поддерживает потоки East-West.
Динамический общедоступный IP-адрес и маршруты, определяемые пользователем (UDR) NVA не требует специальных функций. Это решение гарантирует симметричный трафик. Это решение предназначено только для активных и пассивных конструкций. Он имеет большое время конвергенции от одного до двух минут.

Распространенные шаблоны высокой доступности

Следующие рекомендации и соображения применяются ко всем конструкциям:

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

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

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

Балансировщик нагрузки

Шаблон проектирования Load Balancer использует два системы балансировки нагрузки Azure для предоставления кластера сетевых виртуальных устройств (NVA) остальной части сети. Подход подходит как для NVA с отслеживанием состояния, так и без него.

  • Внутренняя подсистема балансировки нагрузки перенаправляет внутренний трафик из Azure и локальной среды в NVA. Эта внутренняя балансировка нагрузки настроена с правилами высокой доступности портов, чтобы каждый порт протоколов управления передачей (TCP) и UDP перенаправлялся на экземпляры NVA.

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

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

Диаграмма, отображающая входящий интернет-трафик с интеграцией с балансировщиком нагрузки.

Скачайте файл Visio этой архитектуры.

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

На следующей схеме показан немного другой шаблон исходящего трафика.

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

Для отправки трафика из сегментов спутниковой сети в общедоступный Интернет через NVAs используется UDR для 0.0.0.0/0, применяемый к подсети сервера приложений в сегменте спутниковой виртуальной сети. Следующий прыжок — это IP-адрес внутренней подсистемы балансировки нагрузки. Подсистема балансировки нагрузки перенаправит трафик в один из экземпляров NVA, который отправляет его в общедоступный Интернет через шлюз NAT. Шлюз NAT гарантирует, что обратный трафик перенаправляется в тот же экземпляр NVA, который затем доставляет его на первый сервер приложений.

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

Диаграмма, которая показывает локальный трафик с интеграцией балансировщика нагрузки.

На предыдущих схемах Spoke1 не знает о диапазоне Spoke2. Таким образом, 0.0.0.0/0 UDR отправляет трафик, предназначенный для Spoke2 во внутреннюю подсистему балансировки нагрузки NVA.

Для трафика между локальными сетями и Azure или между виртуальными машинами Azure симметрия трафика гарантируется внутренним балансировщиком нагрузки в одиночном сетевом интерфейсном контроллере (NIC) NVA. Если оба направления потока трафика проходят через один и тот же балансировщик нагрузки, подсистема балансировки нагрузки выбирает один и тот же экземпляр NVA для обоих направлений. Если в структуре NVA с двумя сетевыми адаптерами используется внутренняя подсистема балансировки нагрузки для каждого направления взаимодействия, SNAT требуется для обеспечения симметрии трафика. На предыдущей схеме North-South представлен пример этого проектирования.

В этой конфигурации двухпортовые виртуальные сетевые устройства (NVA) должны определить, куда именно следует отправлять ответы на проверки работоспособности балансировщика нагрузки. Load Balancer всегда использует тот же IP-адрес, что и источник проверки работоспособности, который 168.63.129.16. NVA должен отправлять эти ответы проверки работоспособности обратно через тот же интерфейс, по которому они были получены. Обычно для этого процесса требуется несколько таблиц маршрутизации в ОС, так как маршрутизация на основе назначения отправляет ответы через один сетевой адаптер.

Балансировщик нагрузки имеет хорошее время конвергенции при отдельных сбоях NVA. Пробы работоспособности можно отправлять каждые пять секунд, и экземпляр на сервере считается неисправным после трех неудачных проб. Балансировщику нагрузки обычно требуется 10–15 секунд, чтобы перенаправить трафик к другому экземпляру NVA.

Эта конфигурация поддерживает как активные/активные, так и активные/резервные конфигурации. Для активных и резервных конфигураций экземпляры NVA должны предоставить порт TCP или UDP или конечную точку HTTP, которая отвечает только на пробы работоспособности подсистемы балансировки нагрузки для экземпляра в активной роли.

Подсистемы балансировки нагрузки уровня 7

Конкретный дизайн для устройств безопасности заменяет общедоступный балансировщик нагрузки Azure на балансировщик нагрузки уровня 7, например шлюз приложений (Application Gateway), который также можно рассматривать как NVA.

В этом сценарии виртуальные сети требуют только внутренней подсистемы балансировки нагрузки для трафика из систем рабочих нагрузок. Dual-NIC устройства иногда используют этот подход, чтобы избежать проблем с маршрутизацией при проверке работоспособности подсистемы балансировки нагрузки. Эта конструкция поддерживает только протоколы уровня 7, поддерживаемые подсистемой балансировки нагрузки уровня 7, которые обычно являются HTTP и HTTPS.

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

Сервер маршрутизации

Route Server — это служба, которая подключает NVA к Azure программно-определяемой сети через BGP. NVA узнают, какие префиксы IP-адресов существуют в виртуальных сетях Azure. Они также могут внедрять маршруты в действующие таблицы маршрутов виртуальных машин в Azure.

Схема, показывающая интернет-трафик с интеграцией Route Server.

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

Этот метод вставки поддерживает как активные, так и активные и резервные конфигурации. В активной или активной конфигурации все NVA объявляют одинаковые маршруты к серверу маршрутизации. В активной или резервной конфигурации один NVA объявляет маршруты с более коротким путьом автономной системы (AS), чем другой. Сервер маршрутизации поддерживает не более восьми подключений BGP, поэтому если вы используете масштабируемый кластер активных NVAs, эта конструкция поддерживает не более восьми экземпляров NVA.

Эта настройка имеет быстрое время конвергенции. Таймеры keepalive и holdtime в BGP-соединении влияют на время сходимости. Сервер маршрутизации по умолчанию имеет таймеры keepalive, установленные на 60 секунд, и таймеры удержания, установленные на 180 секунд. Но NVAs могут вести переговоры о более низких таймерах во время установления соседства BGP. Если установить эти таймеры слишком низко, это может вызвать нестабильность BGP.

Этот дизайн подходит для NVAs, которые должны взаимодействовать с маршрутизацией Azure. Примеры включают SD-WAN или IPsec NVA, которые обычно имеют хорошую поддержку BGP. Эти NVAs должны получить префиксы, настроенные в виртуальных сетях Azure, или объявить определенные маршруты через частные пиринги ExpressRoute. Эти виды устройств обычно бездействующие, поэтому равномерность трафика не является проблемой, и SNAT не требуется.

Балансировщик нагрузки шлюза

Gateway Load Balancer может вставлять NVAs в путь к данным без необходимости маршрутизации трафика с помощью маршрутов, определяемых пользователем. Для виртуальных машин, которые предоставляют свои рабочие нагрузки через подсистему балансировки нагрузки или через общедоступный IP-адрес, можно перенаправить входящий и исходящий трафик прозрачно в кластер NVAs, расположенный в другой виртуальной сети. На следующей схеме показан маршрут, который пакеты проходят для входящего трафика из публичного интернета, если рабочая нагрузка предоставляет приложение через балансировщик нагрузки.

Диаграмма, показывающая интернет-трафик с интеграцией шлюза Load Balancer.

Этот метод внедрения NVA:

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

Внедрение служб можно использовать через шлюзовый балансировщик нагрузки для входящего трафика в общедоступный балансировщик нагрузки Azure, его возвращаемого трафика и исходящего трафика из Azure. East-West трафик между виртуальными машинами Azure не может использовать шлюз Load Balancer для внедрения NVA.

В кластере NVA проверка работоспособности подсистемы балансировки нагрузки обнаруживает сбои в отдельных экземплярах NVA, что обеспечивает быстрое время конвергенции от 10 до 15 секунд.

Динамический общедоступный IP-адрес и управление UDR

Цель этого проекта заключается в создании конфигурации, которая функционирует без резервирования NVA и может быть изменена в случае простоя NVA. На следующей схеме показано, как общедоступный IP-адрес Azure связывается с активным NVA (NVA1 на этой схеме). Пользовательские таблицы маршрутов (UDR) в периферийных сетях используют IP-адрес активного NVA 10.0.0.37 в качестве следующего прыжка.

Схема, показывающая интернет-трафик с динамическим общедоступным IP-адресом и управлением UDR.

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

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

Эта конструкция не требует SNAT для обеспечения симметрии трафика, так как только одна NVA активна в любое время.

Соавторы

Microsoft поддерживает эту статью. Следующие авторы написали эту статью.

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

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

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

  • Last updated on