Исходящие подключения (классическое развертывание)

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

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

Для этого Azure использует преобразование адресов исходной сети (SNAT). Если несколько частных IP-адресов маскируются под одним общедоступным IP-адресом, Azure использует преобразование адресов портов (PAT), чтобы замаскировать частные IP-адреса. Для PAT используются временные порты, которые предварительно выделяются в зависимости от размера пула.

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

Общие сведения о сценарии

Azure предоставляет три различных способа установления исходящего подключения для классических развертываний. Эти три сценария подходят не для всех классических развертываний.

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

Разные развертывания с классической моделью имеют различные возможности.

Для стратегий устранения рисков характерны такие же отличия.

Алгоритм, используемый для предварительного выделения временных портов для личного маркера доступа в классических развертываниях, аналогичен алгоритму для развертывания ресурсов Azure Resource Manager.

Сценарий 1. Виртуальная машина с общедоступным IP-адресом на уровне экземпляра

В этом случае виртуальной машине назначен общедоступный IP-адрес уровня экземпляра (ILPIP). Что касается исходящих подключений, то не имеет значения, имеет ли виртуальная машина конечную точку с балансировкой нагрузки. Этот сценарий приоритетнее остальных. Виртуальная машина использует ILPIP-адрес для всех исходящих потоков.

Общедоступный IP-адрес назначается виртуальной машине в соотношении "один к одному" (а не "один ко многим") через NAT типа "один к одному" без отслеживания состояния. Маскировка портов (PAT) не используется, и виртуальная машина может использовать все временные порты.

Если приложение инициирует большое количество исходящих потоков и возникает нехватка портов для SNAT, назначьте ILPIP-адрес, чтобы устранить ограничения SNAT. Сведения о проблеме см. в разделе Управление нехваткой портов SNAT (PAT).

Сценарий 2. Общедоступная конечная точка с балансировкой нагрузки

В этом сценарии виртуальная машина или рабочая роль связаны с общедоступным IP-адресом через конечную точку с балансировкой нагрузки. Виртуальной машине не назначен общедоступный IP-адрес.

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

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

Порты SNAT выделяются предварительно, как описано в разделе Основные сведения о SNAT и PAT. Они представляют собой ограниченный ресурс, который можно исчерпать. Важно понимать, как они используются. Чтобы понять, как спроектировать архитектуру и избежать этой проблемы, см. сведения в разделе Управление нехваткой портов SNAT (PAT).

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

Сценарий 3. Отсутствие связанного общедоступного IP-адреса

В этом сценарии виртуальная машина или рабочая роль не являются частью общедоступной конечной точки с балансировкой нагрузки. И в случае с виртуальной машиной у нее нет назначенного ей ILPIP-адреса. Когда виртуальная машина создает исходящий поток, Azure преобразует частный исходный IP-адрес исходящего потока в общедоступный исходный IP-адрес. Общедоступный IP-адрес, используемый для этого исходящего потока, настроить нельзя, и он не учитывается в ограничениях подписки на ресурсы общедоступного IP-адреса. Azure автоматически выделяет этот адрес.

Для выполнения этой функции Azure использует SNAT с маскировкой портов (PAT). Эта ситуация аналогична сценарию 2, кроме того, что нельзя управлять использованием IP-адреса. Это резервный сценарий, на случай если не исполняются сценарии 1 и 2. Мы не рекомендуем использовать этот сценарий, если необходим контроль над исходящими адресами. Если исходящие подключения являются важной частью приложения, необходимо выбрать другой сценарий.

Порты SNAT выделяются предварительно, как описано в разделе Основные сведения о SNAT и PAT. Количество виртуальных машин или рабочих ролей, которые совместно используют общедоступный IP-адрес, определяет количество предварительно выделенных временных портов. Важно понимать, как они используются. Чтобы понять, как спроектировать архитектуру и избежать этой проблемы, см. сведения в разделе Управление нехваткой портов SNAT (PAT).

Основные сведения о SNAT и PAT

SNAT с маскировкой портов (PAT)

Когда развертывание устанавливает исходящее подключение, перезаписывается каждый источник такого подключения. Источник перезаписывается из пространства частных IP-адресов в общедоступный IP-адрес, связанный с развертыванием (на основе описанных выше сценариев). В пространстве общедоступных IP-адресов поток из 5 кортежей (исходного IP-адреса, исходного порта, транспортного IP-протокола, конечного IP-адреса, конечного порта) должен быть уникальным.

Для обеспечения этого используются временные порты (порты SNAT) после перезаписи частного исходного IP-адреса, так как из одного общедоступного IP-адреса исходят несколько потоков.

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

Несколько потоков, каждый из которых направляется к разным конечным IP-адресу, порту и протоколу, используют отдельный порт SNAT. Конечный IP-адрес, порт и протокол делают потоки уникальными, устраняя необходимость в дополнительных портах источника, чтобы различать потоки в пространстве общедоступных IP-адресов.

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

Шаблоны, позволяющие уменьшить риски возникновения условий, которые обычно приводят к нехватке портов, см. в разделе Управление нехваткой портов SNAT (PAT).

Предварительное выделение временных портов для SNAT с маскировкой портов (PAT)

При SNAT с маскировкой портов (PAT) Azure использует алгоритм, определяющий количество предварительно выделяемых доступных портов SNAT в зависимости от размера внутреннего пула. Порты SNAT — это временные порты, доступные для конкретного общедоступного исходного IP-адреса.

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

В таблице ниже указаны предварительно выделяемые порты SNAT для уровней размера внутреннего пула.

Помните, что количество доступных портов SNAT не преобразуется автоматически в количество потоков. Один порт SNAT можно использовать повторно для нескольких уникальных назначений. Порты используются, только если это необходимо, чтобы сделать поток уникальным. Советы по проектированию и уменьшению рисков см. в разделе об управлении этим исчерпаемым ресурсом, а описание PAT — в разделе SNAT с маскировкой портов (PAT).

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

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

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

Порты SNAT выделяются для конкретного транспортного протокола IP (то есть отдельно для TCP и UDP) и освобождаются при следующих условиях:

Освобождение TCP-порта SNAT

• Если клиент и сервер отправляют флаги FIN и ACK, порт SNAT освобождается через 240 секунд.
• Если получен сегмент с флагом RST, порт SNAT освобождается через 15 секунд.
• Если достигнуто время ожидания в режиме простоя.

Освобождение UDP-порта SNAT

• Если достигнуто время ожидания в режиме простоя.

Решение проблем

Этот раздел предназначен, чтобы помочь устранить нехватку портов SNAT и другие проблемы, которые могут возникнуть с исходящими подключениями в Azure.

Управление нехваткой портов SNAT (PAT)

Временные порты, используемые для PAT, являются ограниченным ресурсом, как описано в разделах Отсутствие связанного общедоступного IP-адреса и Общедоступная конечная точка с балансировкой нагрузки.

При инициировании множества исходящих TCP- или UDP-подключений к одним и тем же конечным IP-адресу и порту подключения будут завершаться сбоем или же вы будете получать уведомления от службы поддержки о нехватке SNAT (выделенных временных портов, используемых для PAT). У вас есть несколько вариантов устранения этой проблемы. Ознакомьтесь с ними, чтобы выбрать доступный и подходящий вариант для своего сценария. Возможно, один или несколько вариантов помогут вам решить проблему.

Если вам непонятно поведение исходящих подключений, можно использовать статистику распределения IP-адресов (netstat) или записывать пакеты.

Изменение приложения для повторного использования подключений

Вы можете снизить потребность во временных портах, используемых для SNAT, повторно используя подключения в приложении. Это особенно касается таких протоколов, как HTTP/1.1, в которых подключения используются повторно по умолчанию. В свою очередь, это может положительно повлиять на другие протоколы, использующие HTTP в качестве транспортировки (например, REST).

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

Изменение приложения для использования пулов подключений

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

Возможно, пулы подключений уже существуют в платформе, которая используется вами для разработки приложения или параметров конфигурации приложения. Их можно объединить с повторным использованием подключений. В этом случае для обработки нескольких запросов можно будет использовать фиксированное, прогнозируемое число портов для одних и тех же конечных IP-адреса и порта. Кроме того, вы можете воспользоваться преимуществами повышенной эффективности транзакций TCP, сокращающей задержки и использование ресурсов. Транзакции UDP также могут предоставлять преимущества, так как возможность изменить число потоков UDP позволяет избежать нехватки и управлять использованием портов SNAT.

Изменение приложения для использования менее "жесткой" логики повторных попыток

При нехватке предварительно выделенных временных портов для PAT или сбоях приложения строгая логика повтора или логика повтора методом подбора без логики отхода и времени сохранения не позволяет устранить проблему. Вы можете снизить потребность во временных портах, используя менее "жесткую" логику повторных попыток.

Для временных портов установлено время ожидания простоя 4 минуты (не регулируется). Если повторные попытки слишком частые, нехватка будет наблюдаться в любом случае. Поэтому знать, как и как часто приложение повторяет транзакции, очень важно для проектирования.

Назначение общедоступного IP-адреса на уровне экземпляра для каждой виртуальной машины

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

Использование проверки активности для сброса времени ожидания простоя исходящих подключений

Для исходящих подключений задано время ожидания простоя 4 минуты. Это время не регулируется. Тем не менее вы можете использовать проверку активности транспортного уровня (например, TCP-подключений) или уровня приложения, чтобы обновлять простаивающие потоки и сбрасывать время ожидания, если необходимо. Обратитесь к поставщику любого комплекта программного обеспечения, чтобы узнать, поддерживается ли эта функция или как ее включить. В основном для сброса времени ожидания простоя только одна сторона должна отправлять запросы проверки активности.

Обнаружение общедоступного IP-адреса, используемого виртуальной машиной

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

С помощью команды nslookup можно отправить к сопоставителю OpenDNS запрос DNS для имени myip.opendns.com. Служба возвращает исходный IP-адрес, который был использован для отправки запроса. При выполнении следующего запроса, поступившего с виртуальной машины, ответ будет содержать общедоступный IP-адрес, используемый для этой виртуальной машины.

nslookup myip.opendns.com resolver1.opendns.com

Дальнейшие действия

• Узнайте больше о балансировщике нагрузки, используемом в развертываниях Resource Manager.
• Узнайте больше о сценариях исходящего подключения, доступных в развертываниях Resource Manager.