Обзор Azure Well-Architected Framework для шлюза Azure NAT

Шлюз приложений Azure
Виртуальная сеть Azure
Приватный канал Azure

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

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

NAT означает преобразование сетевых адресов. Общие сведения о переводе сетевых адресов.

Оптимизация затрат

Доступ к службам PaaS должен осуществляться через Приватный канал Azure или конечные точки службы (включая хранилище), чтобы избежать использования шлюза NAT. Приватный канал и конечные точки служб не требуют обхода шлюза NAT для доступа к службам PaaS. При сравнении затрат шлюза NAT на Приватный канал или конечных точек службы плата взимается за ГБ обработанных данных. Существуют дополнительные преимущества безопасности для использования Приватный канал или конечных точек службы.

Оптимизация производительности

Каждый ресурс шлюза NAT обеспечивает до 50 Гбит/с пропускной способности. Вы можете разделить развертывания на несколько подсетей, а затем назначить каждую подсеть или группы подсетей шлюза NAT для горизонтального масштабирования.

Каждый общедоступный IP-адрес шлюза NAT предоставляет 64 512 портов SNAT. Для шлюза NAT можно назначить до 16 IP-адресов. IP-адреса могут быть отдельными общедоступными IP-адресами уровня "Стандартный", префиксом общедоступного IP-адреса или обоими. Для подключений к той же конечной точке назначения шлюз NAT может поддерживать до 50 000 одновременных потоков для TCP и UDP соответственно на назначенный исходящий IP-адрес. Дополнительные сведения см. в следующем разделе по переводу адресов исходной сети (SNAT). ПРОТОКОЛ TCP обозначает протокол управления передачей, а протокол UDP — протокол пользовательской диаграммы данных.

Нехватка SNAT

  • Ресурсы шлюза NAT имеют время простоя TCP по умолчанию в течение 4 минут, которые можно настроить до 120 минут. Если этот параметр изменяется на более высокое значение, чем по умолчанию, шлюз NAT будет храниться в потоках дольше и может вызвать ненужное давление на инвентаризацию портов SNAT.
  • Атомарные запросы (один запрос на подключение) — это плохой вариант проектирования, так как он ограничивает масштаб, снижает производительность и снижает надежность. Вместо этого повторно используйте подключения HTTP/S, чтобы уменьшить количество подключений и связанных портов SNAT. Подключение повторное использование позволит приложению масштабироваться. Производительность приложения улучшится из-за снижения затрат на подтверждение, нагрузку и криптографическую операцию при использовании TLS.
  • Подстановки системы доменных имен (DNS) могут вводить множество отдельных потоков на томе, если клиент не кэширования результата разрешения DNS. Используйте кэширование DNS для уменьшения объема потоков и уменьшения количества портов SNAT. DNS — это система именования, которая сопоставляет доменные имена с IP-адресами для ресурсов, подключенных к Интернету или к частной сети.
  • Потоки UDP, такие как подстановки DNS, используют порты SNAT во время ожидания простоя. Таймер времени ожидания простоя UDP фиксируется в 4 минутах и не может быть изменен.
  • Используйте пулы соединений, чтобы контролировать число подключений.
  • Никогда не отменяйте поток TCP без оповещения и не доверяйте очистку потоков таймерам TCP. Если не разрешить TCP явно закрыть подключение, подключение TCP остается открытым. Промежуточные системы и конечные точки будут использовать это подключение, что, в свою очередь, делает порт SNAT недоступным для других подключений. Этот анти-шаблон может вызвать сбои приложений и исчерпание SNAT.
  • Не изменяйте значения таймера, связанные с TCP на уровне ОС, без экспертных знаний о последствиях. Даже если это исправит стек протокола TCP, производительность приложения может снизиться, если конечные точки подключения не будут отвечать ожиданиям. Изменение значений таймера обычно является признаком базовой проблемы проектирования. Если базовое приложение имеет другие антишаблоны, то исчерпание SNAT также может быть усилено, если значения таймера изменяются.

Ознакомьтесь со следующими рекомендациями по повышению масштаба и надежности службы:

  • Изучите эффект уменьшения времени ожидания простоя TCP до более низких значений. Время ожидания простоя по умолчанию в течение 4 минут может освободить инвентаризацию портов SNAT ранее.
  • Рассмотрим асинхронные шаблоны опроса для длительных операций, чтобы освободить ресурсы подключения для других операций.
  • Длительные потоки, такие как повторно используемые TCP-подключения, должны использовать хранимые протоколы TCP или хранение на уровне приложений, чтобы избежать истечения времени ожидания промежуточных систем. Вы должны увеличить время ожидания простоя в качестве последнего средства, и это может не устранить первопричину. Длительное время ожидания может вызвать сбои с низкой скоростью, когда истекает время ожидания, и может привести к задержке и ненужным сбоям. Хранение TCP можно включить с одной стороны подключения, чтобы обеспечить работоспособность подключения с обеих сторон.
  • Для длительных потоков с трафиком UDP можно включить UDP-хранимые данные для поддержания активности подключений. Имейте в виду, что UDP-хранимые значения, включенные на одной стороне подключения, поддерживают только подключение с одной стороны. Хранимые UDP должны быть включены на обеих сторонах подключения, чтобы обеспечить работоспособность подключения.
  • Следует использовать аккуратные шаблоны повторных попыток, чтобы избежать агрессивных всплесков нагрузки при временном сбое или при восстановлении после сбоя. Антипаттерн, называемый атомарными подключениями, заключается в создании нового TCP-подключения для каждой операции HTTP. Атомарные подключения не позволят приложению хорошо масштабироваться и будут тратить ресурсы. Обязательно объединяйте последовательные операции в один конвейер в пределах одного подключения. Это повысит скорость транзакций в приложении и снизит затраты ресурсов. Если приложение использует шифрование уровня транспорта (например, TLS), с обработкой новых подключений возникает значительный объем затрат. Дополнительные рекомендации см . в шаблонах облачного проектирования Azure.

Эффективность работы

Хотя шлюз NAT можно использовать с Служба Azure Kubernetes (AKS), он не управляется как часть AKS. Если вы назначаете шлюз NAT подсети интерфейса сети контейнеров (CNI), вы включите модули pod AKS для исходящего трафика через шлюз NAT.

При использовании нескольких шлюзов NAT в разных зонах или регионах сохраняйте управление исходящими IP-адресами с помощью префиксов общедоступных IP-адресов Azure или префиксов 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 эти сетевые сети будут использовать адреса шлюза NAT для исходящего подключения, а не IP-адреса подсистемы балансировки нагрузки или отдельных IP-адресов. Сведения об использовании этого сценария с Брандмауэр Azure см. в статье "Интеграция Брандмауэр Azure с Azure Load Balancer (цен. категория ".

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

Microsoft Defender для облака может отслеживать любые подозрительные исходящие подключения через шлюз NAT. Это функция оповещения в Microsoft Defender для облака.

Соавторы

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

Автор субъекта:

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

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