Обзор сетевой архитектуры сред службы приложений

Внимание

Эта статья посвящена Среде службы приложений версии 1. Среда службы приложений версии 1 и 2 отставаются от 31 августа 2024 года. Имеется новая версия среды службы приложений, которая проще в использовании и которая работает на более мощной инфраструктуре. Чтобы узнать больше о новой версии, начните с изучения статьи Введение в Среду службы приложений. Если вы используете Среду службы приложений версии 1, выполните действия, описанные в этой статье, чтобы перейти на новую версию.

По состоянию на 31 августа 2024 года соглашение об уровне обслуживания (SLA) и кредиты на обслуживание больше не применяются к рабочим нагрузкам Среда службы приложений версии 1 и 2, которые продолжают работать, так как они являются устаревшими продуктами. Началось списание оборудования Среда службы приложений версии 1 и 2, и это может повлиять на доступность и производительность приложений и данных.

Необходимо выполнить миграцию в Среда службы приложений версии 3 немедленно или удалить приложения и ресурсы. Мы попытаемся выполнить автоматическую миграцию всех оставшихся Среда службы приложений версии 1 и 2 на основе оптимальной работы с помощью функции миграции на месте, но корпорация Майкрософт не утверждает или не гарантирует доступность приложений после автоматической миграции. Вам может потребоваться выполнить настройку вручную, чтобы завершить миграцию и оптимизировать выбор номера SKU плана Служба приложений в соответствии с вашими потребностями. Если автоматическая миграция невозможна, ваши ресурсы и связанные данные приложения будут удалены. Мы настоятельно призываем вас действовать сейчас, чтобы избежать любого из этих экстремальных сценариев.

Если вам потребуется дополнительное время, мы можем предложить одноразовый 30-дневный льготный период для завершения миграции. Дополнительные сведения и запросы на этот льготный период см. в обзоре льготного периода, а затем перейдите к портал Azure и перейдите в колонку "Миграция" для каждого Среда службы приложений.

Последние сведения об обновлении Среда службы приложений версии 1/2 см. в Среда службы приложений обновлении для выхода на пенсию версии 1 и версии 2.

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

Общий поток сетевого трафика

Когда среда службы приложений (ASE) использует общедоступный виртуальный IP-адрес для приложений, на него поступает весь входящий трафик. Этот трафик включает трафик HTTP и HTTPS для приложений, а также другой трафик для FTP, функций удаленной отладки и операций управления Azure. Полный список всех портов (обязательных и необязательных) для общедоступного виртуального IP-адреса см. в статье Как управлять входящим трафиком в среде службы приложений.

Кроме того, среда службы приложений поддерживают работающие приложения, которые привязаны только к внутреннему адресу виртуальной сети, также называемому адресом внутреннего балансировщика нагрузки (ILB). Для трафика ASE, HTTP и HTTPS для приложений и удаленных вызовов отладки включено asE, HTTP и HTTPS, прибывают по адресу ILB. Для наиболее распространенных конфигураций ILB-ASE трафик FTP/FTPS также поступает по адресу ILB. Однако поток операций управления Azure к портам 454/455 на общедоступном ВИРТУАЛЬНОМ IP-адресе включенной ASE с поддержкой ILB.

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

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

Внимание

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

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

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

Дополнительную информацию о разрешении исходящего подключения к Интернету в среде службы приложений см. в статье о работе с Express Route. Метод, описанный в статье, применяется также при работе с подключением «сеть — сеть» и при использовании принудительного туннелирования.

Исходящие сетевые адреса

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

Если вызываемая конечная точка находится вне топологии виртуальной сети, то исходящий адрес (также известный как исходящий адрес NAT) является общедоступным ВИРТУАЛЬНЫМ IP-адресом Среда службы приложений. Этот адрес можно найти в пользовательском интерфейсе портала для Среды службы приложений в разделе "Свойства".

Этот адрес также можно определить для ASEs, которые имеют только общедоступный IP-адрес, создав приложение в Среда службы приложений, а затем выполните nslookup на адресе приложения. Результирующий IP-адрес — это общедоступный ВИРТУАЛЬНЫЙ IP-адрес и исходящий NAT-адрес Среда службы приложений.

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

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

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

Расшифровка схемы выше.

• Так как общедоступный виртуальный IP-адрес среды службы приложений — 192.23.1.2, он является исходящим IP-адресом, используемым при отправке вызовов к конечным точкам в «Интернете».
• Диапазон CIDR подсети, содержащей среду службы приложений — 10.0.1.0/26. Другие конечные точки в пределах инфраструктуры той же виртуальной сети будут «видеть» вызовы из приложений как исходящие из какого-то адреса в этом диапазоне.

Вызовы между средами службы приложений

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

На схеме ниже показан пример многоуровневой архитектуры с приложениями в одной Среде службы приложений (например, веб-приложениями Front Door), которые обращаются к приложениям во второй Среде службы приложений (например, внутренним приложениям API серверной части, которые не должны быть доступны из Интернета).

В приведенном выше примере среда службы приложений «ASE 1» имеет исходящий IP-адрес 192.23.1.2. Если приложение, запущенное в этой среде службы приложений, выполняет исходящий вызов приложения, запущенного во второй среде службы приложений («ASE 2»), которая расположена в той же виртуальной сети, то исходящий вызов будет считаться «обращением к Интернету». В результате сетевой трафик, поступающий во вторую Среду службы приложений, будет выглядеть так, как будто он поступает с IP-адреса 192.23.1.2 (т. е. с адреса, не входящего в диапазон адресов подсети первой Среды службы приложений).

Несмотря на то что вызовы между разными Среда службы приложений рассматриваются как "Интернет", когда оба Среда службы приложений находятся в одном регионе Azure, сетевой трафик останется в региональной сети Azure и физически не будет осуществляться через общедоступный Интернет. В итоге вы можете использовать сетевую группу безопасности в подсети второй среды службы приложений, чтобы разрешить только входящие вызовы с адреса первой среды службы приложений (исходящий IP-адрес которой 192.23.1.2). Тем самым вы обеспечите защищенный обмен данными между средами службы приложений.

Дополнительные ссылки и сведения

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

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