В этой статье описываются наиболее распространенные варианты развертывания набора сетевых виртуальных устройств (NVA) для обеспечения высокой доступности в Azure. NVA обычно используется для управления потоком трафика между сегментами сети, классифицированными с разными уровнями безопасности, например между виртуальная сеть и общедоступным Интернетом.
Существует ряд шаблонов проектирования, в которых виртуальные машины используются для проверки трафика между различными зонами безопасности, например:
- Проверка исходящего трафика из виртуальных машин в Интернет и предотвращение кражи данных.
- Чтобы проверить трафик входящего трафика из Интернета в виртуальные машины и предотвратить атаки.
- Чтобы отфильтровать трафик между виртуальными машинами в Azure, чтобы предотвратить боковое перемещение скомпрометированных систем.
- Фильтрация трафика между локальными системами и виртуальными машинами Azure, если они считаются принадлежащими к разным уровням безопасности. (Например, если Azure размещает dmZ и локальные внутренние приложения.)
Существует множество примеров NVAs, таких как брандмауэры сети, обратные прокси-серверы уровня 4, конечные точки VPN IPsec, веб-серверы обратного прокси-сервера с функциональными возможностями брандмауэра веб-приложения, прокси-серверы Интернета, чтобы ограничить доступ к веб-страницам из Azure, подсистем балансировки нагрузки уровня 7 и многих других. Все их можно вставить в структуру Azure с помощью шаблонов, описанных в этой статье. Даже сторонние сетевые виртуальные устройства Azure, такие как Брандмауэр Azure и Шлюз приложений Azure использовать проекты, описанные далее в этой статье. Понимание этих параметров имеет решающее значение как с точки зрения проектирования, так и при устранении неполадок с сетью.
Первый вопрос, на который следует ответить, заключается в том, почему требуется высокий уровень доступности для сетевых виртуальных устройств. Причина заключается в том, что эти устройства управляют обменом данными между сегментами сети. Если они недоступны, сетевой трафик не может выполняться, и приложения перестают работать. Запланированные и незапланированные сбои могут и иногда уменьшать экземпляры NVA (как и любую другую виртуальную машину в Azure или любом другом облаке). Экземпляры удаляются, даже если эти NVA настроены с помощью premium Управляемые диски для предоставления единого экземпляра соглашения об уровне обслуживания в Azure. Таким образом, для высокодоступных приложений потребуется по крайней мере секунда NVA, которая может обеспечить подключение.
Предварительные требования. В этой статье предполагается базовое представление о сети Azure, Azure Load Balancers и виртуальная сеть маршрутизации трафика (UDR).
При выборе оптимального варианта развертывания сетевого виртуального устройства в виртуальной сети Azure наиболее важным аспектом является проверка и проверка конкретной структуры поставщиком NVA. Поставщик также должен предоставить необходимую конфигурацию NVA, необходимую для интеграции NVA в Azure. Если поставщик NVA предлагает различные варианты разработки в качестве поддерживаемых вариантов разработки для NVA, эти факторы могут повлиять на решение:
- Время конвергенции: сколько времени занимает каждое проектирование, чтобы управлять трафиком от неудачного экземпляра NVA?
- Поддержка топологии: какие конфигурации NVA поддерживают каждый вариант разработки? Активный или активный, активный или резервный, масштабируемые кластеры NVA с избыточностью n+1?
- Симметрия трафика: заставляет ли NVA выполнять преобразование адресов исходной сети (SNAT) на пакетах, чтобы избежать асимметричной маршрутизации? Или симметрия трафика применяется другими средствами?
В следующих разделах в документе описаны наиболее распространенные архитектуры, используемые для интеграции NVAs в сеть концентратора и периферийной сети.
Примечание.
В этой статье рассматриваются проекты концентратора и периферийных узлов. Виртуальная глобальная сеть не рассматриваются, так как Виртуальная глобальная сеть гораздо более описательным способом развертывания NVA в зависимости от того, поддерживается ли конкретный NVA в центрах Виртуальная глобальная сеть. Дополнительные сведения см. в разделе "Виртуальные сетевые устройства" в центре Виртуальная глобальная сеть.
Общие сведения об архитектуре высокого уровня доступности
В следующих примерах архитектур описаны ресурсы и конфигурации, необходимые для обеспечения высокой доступности для NVA:
| Решение | Преимущества | Рекомендации |
|---|---|---|
| Azure Load Balancer | Поддерживает NVAs для активных и активных, активных и резервных и масштабируемых виртуальных машин. Очень хорошее время конвергенции | NVA должен предоставить порт для проб работоспособности, особенно для активных и резервных развертываний. Потоки из Интернета требуют SNAT для симметрии |
| Сервер маршрутизации Azure | NVA должна поддерживать BGP. Поддерживает NVAs для активных и активных, активных и резервных и масштабируемых виртуальных машин. | Для симметрии трафика требуется SNAT |
| Подсистема балансировки нагрузки шлюза | Симметрия трафика гарантируется без SNAT. Виртуальные сети могут быть общими для клиентов. Очень хорошее время конвергенции. Поддерживает NVAs для активных и активных, активных и резервных и масштабируемых виртуальных машин. | Поддерживает потоки в Интернет и из Интернета, не потоки "Восток-Запад" |
| Изменение PIP/UDR | Специальные функции, необходимые NVA, не требуются. Гарантирует симметричный трафик | Только для активных и пассивных конструкций. Высокая продолжительность конвергенции 1–2 минуты |
Проектирование Подсистемы балансировки нагрузки
Эта конструкция использует две подсистемы балансировки нагрузки Azure для предоставления кластера виртуальных сетей остальной части сети:
- Внутренняя подсистема балансировки нагрузки используется для перенаправления внутреннего трафика из Azure и локальной среды в NVA. Эта внутренняя подсистема балансировки нагрузки настраивается с правилами портов высокого уровня доступности, чтобы каждый порт TCP/UDP перенаправлялся в экземпляры NVA.
- Общедоступная подсистема балансировки нагрузки предоставляет сетевые сети в Интернете. Так как порты высокого уровня доступности предназначены для входящего трафика, каждый отдельный порт TCP/UDP должен быть открыт в выделенном правиле балансировки нагрузки.
На следующей схеме описывается последовательность прыжков, которые пакеты из Интернета в сервер приложений в периферийной виртуальной сети будут следовать:
Скачайте файл Visio для этой архитектуры.
Механизм отправки трафика из периферийных узлов в общедоступный Интернет через NVAs — это определяемый пользователем маршрут для 0.0.0.0/0 следующего прыжка с IP-адресом внутреннего балансировщика нагрузки.
Для трафика между Azure и общедоступным Интернетом каждое направление потока трафика будет пересекать другую подсистему балансировки нагрузки Azure (пакет входящего трафика через общедоступную подсистему балансировки нагрузки и исходящий пакет через внутреннюю подсистему балансировки нагрузки). В результате, если требуется симметрия трафика, преобразование сетевых адресов источника (SNAT) должно выполняться экземплярами NVA для привлечения возвращаемого трафика и предотвращения асимметрии трафика.
Эту структуру можно использовать, а также для проверки трафика между Azure и локальными сетями:
Механизм отправки трафика между периферийными модулями через NVA точно такой же, поэтому дополнительная схема не предоставляется. В приведенных выше примерах схем, так как функция spoke1 не знает о диапазоне периферийных2, 0.0.0.0/0 UDR отправит трафик, адресованный к периферийным2, во внутреннюю подсистему балансировки нагрузки Azure NVA.
Для трафика между локальными сетями и Azure или между виртуальными машинами Azure симметрия трафика гарантируется внутренней подсистемой балансировки нагрузки Azure: когда оба направления потока трафика проходят через один и тот же Azure Load Balancer, будет выбран один и тот же экземпляр NVA.
Azure Load Balancer имеет очень хорошее время конвергенции в случае отдельных сбоев NVA. Так как пробы работоспособности могут отправляться каждые 5 секунд, и для объявления экземпляра серверной части из службы требуется 10–15 секунд для конвергентного трафика в другой экземпляр NVA.
Эта программа установки поддерживает как активные, так и активные и резервные конфигурации. Однако для активных и резервных конфигураций экземпляры NVA должны предложить порт TCP/UDP или конечную точку HTTP, которая не отвечает на пробы работоспособности Load Balancer, если экземпляр не находится в активной роли.
Использование подсистем балансировки нагрузки L7
В частности, это замена общедоступной подсистемы балансировки нагрузки Azure на подсистему балансировки нагрузки уровня 7, например Шлюз приложений Azure (которая может рассматриваться как NVA самостоятельно). В этом случае виртуальные сети требуют только внутренней подсистемы балансировки нагрузки перед ними, так как трафик из Шлюз приложений будет источником из виртуальной сети, а асимметрия трафика не является проблемой.
NVA должен принимать входящий трафик для протоколов, не поддерживаемых подсистемой балансировки нагрузки уровня 7, а также потенциально всех исходящих трафика. Дополнительные сведения об этой конфигурации при использовании Брандмауэр Azure в качестве NVA и Шлюз приложений Azure в качестве веб-обратного прокси-сервера уровня 7 см. в разделе "Брандмауэр" и Шлюз приложений для виртуальных сетей.
Сервер маршрутизации Azure
Сервер маршрутизации Azure — это служба, которая позволяет NVA взаимодействовать с Azure SDN через протокол BGP. Не только NVAs узнает, какие префиксы IP-адресов существуют в виртуальных сетях Azure, но они смогут внедрять маршруты в эффективные таблицы маршрутов виртуальных машин в Azure.
На схеме над каждым экземпляром NVA выполняется пиринг BGP с сервером маршрутизации Azure. В периферийных подсетях таблица маршрутов не требуется, так как сервер маршрутизации Azure будет программировать маршруты, объявленные NVAs. Если два или более маршрутов запрограммируются на виртуальных машинах Azure, они будут использовать равные затраты multiPathing (ECMP) для выбора одного из экземпляров NVA для каждого потока трафика. В результате SNAT является обязательным в этой структуре, если симметрия трафика является требованием.
Этот метод вставки поддерживает как активные, так и активные (все NVA объявляют одни и те же маршруты на сервере маршрутизации Azure), а также активный или резервный (один NVA объявляет маршруты с более коротким путем AS, чем другой). Сервер маршрутизации Azure поддерживает не более 8 прилагаемых BGP. Таким образом, если используется масштабируемый кластер активных виртуальных виртуальных машин, эта конструкция будет поддерживать не более 8 экземпляров NVA.
Время конвергенции довольно быстро в этой настройке, и будет влиять на хранимые и временные таймеры прилагательной BGP. Хотя сервер маршрутизации Azure имеет хранимые и временные таймеры по умолчанию (60 секунд и 180 секунд соответственно), NVAs могут согласовывать более низкие таймеры во время создания примечаний BGP. Установка этих таймеров слишком низкая может привести к нестабильности BGP.
Эта конструкция является наиболее распространенным вариантом для виртуальных сетей Azure, которые должны взаимодействовать с маршрутизацией Azure, например nVAs завершения VPN, которые должны узнать префиксы, настроенные в виртуальных сетям Azure, или объявлять определенные маршруты через частные пиринги ExpressRoute.
Gateway Load Balancer
Подсистема балансировки нагрузки шлюза Azure — это новый способ вставки NVA в путь к данным без необходимости управлять трафиком с помощью определяемых пользователем маршрутов. Для Виртуальные машины, которые предоставляют рабочие нагрузки через Azure Load Balancer или общедоступный IP-адрес, входящий и исходящий трафик можно перенаправлять прозрачно в кластер NVAs, расположенный в другой виртуальной сети. На следующей схеме описывается путь, который пакеты следуют за входящим трафиком из общедоступного Интернета, если рабочие нагрузки предоставляют приложению через Azure Load Balancer:
Одним из основных преимуществ этого метода внедрения NVA является то, что преобразование сетевых адресов источника (SNAT) не требуется для обеспечения симметрии трафика. Еще одним преимуществом этого варианта проектирования является то, что те же NVA можно использовать для проверки трафика в разные виртуальные сети и из разных виртуальных сетей, что позволяет достичь многотенантности с точки зрения NVA. Пиринг между виртуальной сетью NVA и виртуальной сетью рабочей нагрузки не требуется, а пользовательские маршруты не требуются в виртуальной сети рабочей нагрузки, что значительно упрощает настройку.
Внедрение служб с помощью Подсистемы балансировки нагрузки шлюза можно использовать для входящих потоков, поступающих в общедоступную подсистему балансировки нагрузки Azure (и их возвращаемый трафик), а также для исходящих потоков, поступающих в Azure. Трафик между виртуальными машинами Azure на востоке не может использовать подсистему балансировки нагрузки шлюза для внедрения NVA.
В кластере NVA пробы работоспособности Azure Load Balancer проверка будут использоваться для обнаружения отдельных сбоев экземпляров NVA, что обеспечивает очень быстрое время конвергенции (10–15 секунд).
Изменение PIP-UDR
Идея, лежащая в основе этого дизайна, имеет установку, которая будет необходима без избыточности NVA, и изменить ее в случае, если NVA страдает от простоя. На приведенной ниже схеме показано, как общедоступный IP-адрес Azure связан с активным NVA (NVA1), а определяемые пользователем маршруты в периферийных устройствах имеют ip-адрес активного NVA в качестве следующего прыжка(10.0.0.37).
Если активная NVA стала недоступной, резервный NVA вызовет API Azure для повторного сопоставления общедоступного IP-адреса и периферийных определяемых пользователем маршрутов (или перемещения частного IP-адреса). Эти вызовы API могут занять несколько минут, чтобы быть эффективными, поэтому эта конструкция предлагает худшее время конвергенции всех вариантов в этом документе.
Другое ограничение этой структуры заключается в том, что поддерживаются только активные и резервные конфигурации, что может привести к проблемам масштабируемости: если необходимо увеличить пропускную способность, поддерживаемую сетевыми клиентами, единственным вариантом с этой структурой является масштабирование обоих экземпляров.
Одним из преимуществ этого проекта является то, что для обеспечения симметрии трафика не требуется преобразование исходных сетевых адресов (SNAT), так как в любой момент времени активен только один NVA.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.
Основные авторы:
- Кит Майер | Главный архитектор облачных решений
- Telmo Sampaio | Диспетчер инженеров-служб
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Следующие шаги
- Узнайте, как реализовать безопасную гибридную сеть с помощью Брандмауэр Azure.
- Сети периметра — Cloud Adoption Framework
- Cloud DMZ — Cloud Adoption Framework