В этой статье описаны рекомендации по шлюзу NAT Azure. Руководство основано на пяти основных принципах архитектурного превосходства: оптимизация затрат, эффективность работы, эффективность производительности, надежность и безопасность.
В качестве необходимых условий для этого руководства у вас должно быть рабочее знание шлюза NAT Azure и понимание соответствующих функций. Дополнительные сведения см . в документации по шлюзу NAT Azure.
Оптимизация затрат
Настройте доступ к решениям платформы как услуга (PaaS) с помощью Приватный канал Azure или конечных точек службы, включая хранилище, чтобы не использовать шлюз NAT. Приватный канал и конечные точки службы не требуют обхода шлюза NAT для доступа к службам PaaS. Этот подход снижает затраты на гигабайт (ГБ) обработанных данных по сравнению с затратами на использование шлюза NAT. Приватный канал и конечные точки службы также обеспечивают преимущества безопасности.
Оптимизация производительности
Каждый ресурс шлюза NAT предоставляет до 50 гигабит в секунду (Гбит/с) пропускной способности. Развертывания можно разделить на несколько подсетей, а затем назначить шлюз NAT каждой подсети или группе подсетей для горизонтального масштабирования.
Каждый общедоступный IP-адрес шлюза NAT предоставляет 64512 портов преобразования сетевых адресов (SNAT). Вы можете назначить до 16 IP-адресов шлюзу NAT, включая отдельные общедоступные IP-адреса, префикс общедоступного IP-адреса или оба. Для каждого назначенного исходящего IP-адреса, который отправляется в одну конечную точку назначения, шлюз NAT может поддерживать до 50 000 одновременных потоков для протокола управления передачей (TCP) и протокола пользовательской диаграммы данных (UDP) соответственно.
Нехватка SNAT
Рассмотрим следующее руководство, чтобы предотвратить исчерпание SNAT:
Ресурсы шлюза NAT имеют время ожидания простоя TCP по умолчанию в течение четырех минут. Время ожидания можно настроить до 120 минут. Если изменить этот параметр на более высокое значение, чем по умолчанию, шлюз NAT удерживается на потоки дольше, что может создать ненужное давление на инвентаризацию портов SNAT.
Атомарные запросы (один запрос на подключение) ограничивают масштаб, сокращают производительность и снижают надежность. Вместо атомарных запросов можно повторно использовать подключения HTTP или HTTPS, чтобы уменьшить количество подключений и связанных портов SNAT. При повторном использовании подключений приложение может масштабироваться лучше. Производительность приложения улучшается из-за снижения затрат на подтверждение, нагрузку и криптографическую операцию при использовании TLS.
Если вы не кэшируете результаты сопоставителя DNS, подстановки системы доменных имен (DNS) могут вводить множество отдельных потоков в томе. Используйте кэширование DNS для уменьшения объема потоков и уменьшения количества портов SNAT. DNS — это система именования, которая сопоставляет доменные имена с IP-адресами для ресурсов, подключенных к Интернету или к частной сети.
Потоки UDP, такие как подстановки DNS, используют порты SNAT во время ожидания простоя. Таймер ожидания простоя UDP фиксируется в четыре минуты.
Используйте пулы соединений, чтобы контролировать число подключений.
Чтобы очистить потоки, не забудьте отказаться от потоков TCP или использовать таймеры TCP. Если не разрешить TCP явно закрыть подключение, tcp-подключение остается открытым. Промежуточные системы и конечные точки сохраняют это подключение, что делает порт SNAT недоступным для других подключений. Этот антипаттерн может вызвать сбои приложений и исчерпание SNAT.
Не изменяйте значения таймера, связанные с TCP на уровне ОС, если вы не знаете о последствиях. Если конечные точки подключения не совпадают с ожиданиями, стек TCP может восстановиться, но это может негативно повлиять на производительность приложения. Обычно у вас есть базовая проблема проектирования, если необходимо изменить значения таймера. И если базовое приложение имеет другие антипаттерны, и вы изменяете значения таймера, вы также можете ускорить исчерпание SNAT.
Ознакомьтесь со следующими рекомендациями по повышению масштаба и надежности службы:
Рассмотрим последствия уменьшения времени ожидания простоя TCP до меньшего значения. Время ожидания простоя по умолчанию в течение четырех минут может предварительно освободить инвентаризацию портов SNAT.
Рассмотрим асинхронные шаблоны опроса для длительных операций, чтобы освободить ресурсы подключения для других операций.
Рассмотрите возможность использования хранимых TCP-подключений или хранения на уровне приложений для длительных потоков TCP, таких как повторно использованные TCP-подключения, чтобы предотвратить время ожидания промежуточных систем. Вы должны увеличить время ожидания простоя в качестве последнего средства, и это может не устранить первопричину. Длительное время ожидания может привести к сбою с низкой скоростью, когда истекает время ожидания. Она также может привести к задержке и ненужным сбоям. Вы можете включить поддержку TCP с одной стороны подключения, чтобы обеспечить работоспособность подключения с обеих сторон.
Рассмотрите возможность использования хранимых данных UDP для длительных потоков UDP, чтобы предотвратить время ожидания промежуточных систем. При включении хранимых данных UDP на одной стороне подключения только одна сторона подключения остается активной. Необходимо включить хранимые UDP на обеих сторонах подключения, чтобы обеспечить работоспособность подключения.
Рассмотрите грациозные шаблоны повторных попыток, чтобы избежать агрессивных повторных попыток и всплесков во время временного сбоя или восстановления сбоя. Для антипаттернных атомарных подключений создается новое TCP-подключение для каждой операции HTTP. Атомарные подключения тратят ресурсы и не позволяют приложению масштабироваться хорошо.
Чтобы увеличить скорость транзакций и уменьшить затраты на ресурсы для приложения, всегда конвейерируйте несколько операций в одном подключении. Если приложение использует шифрование уровня транспорта, например TLS, новая обработка подключений увеличивает затраты. Дополнительные рекомендации см . в шаблонах проектирования облака Azure.
Эффективность работы
Шлюз NAT можно использовать с Служба Azure Kubernetes (AKS), но управление шлюзом NAT не входит в AKS. При назначении шлюза NAT подсети сетевого интерфейса контейнеров (CNI) можно включить модули pod AKS для исходящего трафика через шлюз NAT.
При использовании нескольких шлюзов NAT в зонах или регионах сохраняйте управление исходящими IP-адресами с помощью префиксов общедоступных IP-адресов Azure или префиксов СОБСТВЕННЫх IP-адресов (BYOIP). Невозможно назначить размер префикса IP, размер которому больше 16 IP-адресов (/28 префиксов) шлюзу NAT.
Используйте оповещения Azure Monitor для мониторинга и оповещения об использовании портов SNAT, обработанных или удаленных пакетах, а также объема передаваемых данных. Используйте журналы потоков группы безопасности сети (NSG), чтобы отслеживать исходящий поток трафика из экземпляров виртуальной машины в подсети, настроенной шлюзом NAT.
При настройке подсети с шлюзом NAT шлюз NAT заменяет все остальные исходящие подключения к общедоступному Интернету для всех виртуальных машин в этой подсети. Шлюз NAT имеет приоритет над подсистемой балансировки нагрузки независимо от правил исходящего трафика. Шлюз также имеет приоритет над общедоступными IP-адресами, назначенными непосредственно виртуальным машинам. Azure отслеживает направление потока и предотвращает асимметричную маршрутизацию. Исходящий трафик, например внешний IP-адрес подсистемы балансировки нагрузки, преобразуется правильно, и он преобразуется отдельно от исходящего трафика через шлюз NAT. Такое разделение позволяет беспрепятственно сосуществовать входящим и исходящим службам.
Мы рекомендуем шлюз NAT в качестве стандартного для включения исходящего подключения для виртуальных сетей. Шлюз NAT обеспечивает эффективность и операционную простоту по сравнению с другими методами исходящего подключения в Azure. Шлюзы NAT выделяют порты SNAT по запросу и используют более эффективный алгоритм для предотвращения конфликтов повторного использования портов SNAT. Не полагаться на исходящие подключения по умолчанию антипаттерн для вашего имущества. Вместо этого явно определите конфигурацию с ресурсами шлюза NAT.
Надежность
Ресурсы шлюза NAT имеют высокий уровень доступности в одной зоне доступности и охватывают несколько доменов сбоя. Шлюз NAT можно развернуть в ни в какой зоне, в которой Azure автоматически выбирает зону для размещения шлюза NAT или изолирует шлюз NAT к определенной зоне доступности.
Чтобы обеспечить изоляцию зоны доступности, каждая подсеть должна иметь ресурсы только в определенной зоне. Для реализации этого подхода можно:
- Разверните подсеть для каждой зоны доступности, в которой развертываются виртуальные машины.
- Выровняйте зональные виртуальные машины с соответствующими зональными шлюзами NAT.
- Создание отдельных зональных стеков.
На следующей схеме виртуальная машина в зоне доступности 1 находится в подсети с другими ресурсами, которые также находятся в зоне доступности 1. Шлюз NAT настраивается в зоне доступности 1 для обслуживания этой подсети.
Виртуальные сети и подсети охватывают все зоны доступности в регионе. Их не нужно разделять по зонам доступности для размещения зональных ресурсов.
Безопасность
При использовании шлюза NAT отдельные виртуальные машины или другие вычислительные ресурсы не требуют общедоступных IP-адресов и могут оставаться полностью закрытыми. Ресурсы без общедоступных IP-адресов по-прежнему могут обращаться к внешним источникам за пределами виртуальной сети. Вы можете связать префикс общедоступного IP-адреса, чтобы обеспечить использование непрерывного набора IP-адресов для исходящего подключения. Правила брандмауэра назначения можно настроить на основе этого прогнозируемого списка IP-адресов.
Распространенный подход заключается в разработке сценария виртуального (модуль) сети только для исходящего трафика (NVA) с брандмауэрами, отличными от Майкрософт, или с прокси-серверами. При развертывании шлюза NAT в подсети с масштабируемым набором виртуальных машин NVAs эти NVAs используют один или несколько адресов шлюза NAT для исходящего подключения вместо IP-адреса подсистемы балансировки нагрузки или отдельных IP-адресов. Сведения об использовании этого сценария с Брандмауэр Azure см. в статье "Интеграция Брандмауэр Azure со стандартной подсистемой балансировки нагрузки Azure".
Функцию оповещения Microsoft Defender для облака можно использовать для мониторинга любых подозрительных исходящих подключений в шлюзе NAT.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.
Автор субъекта:
- Итан Хаслетт | Старший архитектор облачных решений
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Следующие шаги
- Microsoft Well-Architected Framework
- Руководство. Создание шлюза NAT с помощью портал Azure
- Рекомендации по использованию зон доступности и регионов