Перенос шлюза приложений Azure и брандмауэра веб-приложений с версии 1 до версии 2

Мы объявили об устаревании SKU шлюза приложений версии V1 (Standard и WAF) 28 апреля 2023 года. SKU версии V1 снимается с производства 28 апреля 2026 года. Дополнительные сведения см. в статье "Миграция шлюзов приложений из SKU V1 в SKU V2" до 28 апреля 2026 г.

Миграция на шлюз приложений Azure и брандмауэр веб-приложений (WAF) версии 2 обеспечивает несколько преимуществ:

• Улучшенная устойчивость: резервирование по отказоустойчивым зонам, автомасштабирование
• Улучшенная безопасность: интеграция Azure Keyvault, улучшенные возможности WAF, Защита ботов
• Расширенные возможности мониторинга: в отличие от версии 1, которая имела только мониторинг ЦП, версия 2 обеспечивает комплексный мониторинг использования ЦП, памяти и диска.
• Улучшено обнаружение и автоматическое устранение рисков: шлюзы версии 2 предоставляют расширенные механизмы обнаружения и автоматизированные процессы устранения рисков, которые могут быстро и точно выявлять и устранять проблемы без необходимости вмешательства вручную.
• Все новые функции выпускаются для SKU версии 2.

Настоятельно рекомендуется создать план миграции. Шлюзы версии 1 не обновляются автоматически до версии 2. Используйте это руководство по миграции, чтобы спланировать и выполнить миграцию.

Существует два этапа миграции:

1. Перенос конфигурации
2. Перенос трафика клиента

Эта статья в основном помогает с миграцией конфигурации. Миграция трафика клиента зависит от среды. Некоторые общие рекомендации приведены в этой статье.

Предпосылки

• Учетная запись Azure с активной подпиской. Создайте учетную запись бесплатно .
• Существующий шлюз приложений версии 1 уровня "Стандартный".
• Убедитесь, что у вас есть последние модули PowerShell или вы можете использовать Azure Cloud Shell на портале.
• При использовании PowerShell на локальном компьютере также нужно запустить Connect-AzAccount, чтобы создать подключение к Azure.
• Убедитесь, что в подписке версии 1 нет существующего шлюза приложений с указанным именем имени и группы ресурсов AppGW версии 2. При этом перезаписываются существующие ресурсы.
• Если указан общедоступный IP-адрес, убедитесь, что он находится в состоянии "Succeeded". Если не указано и AppGWResourceGroupName предоставляется, убедитесь, что общедоступный IP-ресурс с именем AppGWV2Name-IP не существует в группе ресурсов с именем AppGWResourceGroupName в подписке V1.
• Для SKU версии 1 сертификаты проверки подлинности необходимы для настройки подключений TLS с внутренними серверами. SKU V2 требует отправки доверенных корневых сертификатов для той же цели. Хотя версия 1 позволяет использовать самозаверяющие сертификаты в качестве сертификатов проверки подлинности, версия 2 требует создания и отправки самозаверяющего корневого сертификата , если самозаверяющие сертификаты используются в серверной части.
• Убедитесь, что во время миграции не планируется никаких других операций на шлюзе версии 1 или любых связанных ресурсах.

Azure Cloud Shell

Azure размещает Azure Cloud Shell, интерактивную среду оболочки, которую можно использовать в браузере. Для работы со службами Azure можно использовать Bash или PowerShell с Cloud Shell. Для выполнения кода в этой статье можно использовать предустановленные команды Cloud Shell, не устанавливая ничего в локальной среде.

Чтобы запустить Azure Cloud Shell, выполните приведенные действия.

Вариант	Пример/ссылка
Нажмите кнопку Попробовать в правом верхнем углу блока кода или команд. При нажатии кнопки Попробовать код или команда не копируется в Cloud Shell автоматически.
Чтобы открыть Cloud Shell в браузере, перейдите по адресу https://shell.azure.com или нажмите кнопку Запуск Cloud Shell.
Нажмите кнопку Cloud Shell в строке меню в правом верхнем углу окна портала Azure.

Чтобы использовать Azure Cloud Shell, выполните следующие действия:

1. Запустите Cloud Shell.

2. Нажмите кнопку Копировать в блоке кода (или блоке команд), чтобы скопировать код или команду.

3. Вставьте код или команду в сеанс Cloud Shell, выбрав CTRL+SHIFT+V в Windows и Linux или выбрав Cmd+Shift+V в macOS.

4. Нажмите Enter, чтобы запустить код или команду.

Миграция конфигурации

Миграция конфигурации посвящена настройке нового шлюза версии 2 с параметрами из существующей среды V1. Мы предоставляем два скрипта Azure PowerShell, предназначенные для упрощения миграции конфигураций из версии 1 (цен. категория "Стандартный" или WAF) на шлюзы версии 2 (Standard_V2 или WAF_V2). Эти сценарии помогают упростить процесс перехода, автоматив ключевые задачи развертывания и настройки.

1. Расширенный скрипт клонирования

Это новый опыт, который предлагает улучшенный опыт миграции.

• Устранение необходимости ручного ввода внешних SSL-сертификатов и доверенных корневых сертификатов серверной части.
• Поддержка развертывания шлюзов V2 только для частных сетей.

Расширенный скрипт клонирования можно скачать из Галереи PowerShell.

Параметры скрипта: Этот скрипт принимает следующие параметры:

• AppGw V1 ResourceId -Required: этот параметр является идентификатором ресурса Azure для существующего шлюза Standard V1 или WAF версии 1. Чтобы найти это строковое значение, перейдите на портал Azure, выберите шлюз приложений или ресурс WAF и щелкните ссылку "Свойства " для шлюза. Идентификатор ресурса находится на этой странице. Чтобы получить идентификатор ресурса, можно также выполнить следующие команды Azure PowerShell:

  $appgw = Get-AzApplicationGateway -Name <V1 gateway name> -ResourceGroupName <resource group Name>
  $appgw.Id
  

• SubnetAddressRange -Required: адрес подсети в нотации CIDR, где развертывается шлюз приложений версии 2.
• AppGwName -Необязательный: имя шлюза приложений версии 2. Значение по умолчанию = {AppGwV1 Name}_migrated
• AppGwResourceGroupName —необязательно. Имя группы ресурсов, в которой будет создан шлюз приложений версии 2. Если это не указано, будет использоваться группа ресурсов Шлюза приложений версии 1.
• PrivateIPAddress -Необязательный: частный IP-адрес, назначенный шлюзу приложений версии 2. Если это не указано, будет назначен случайный частный IP-адрес.
• ValidateBackendHealth -Необязательный: проверка после миграции путем сравнения ответа ApplicationGatewayBackendHealth. Если этот параметр не задан, эта проверка будет пропущена.
• PublicIpResourceId -Необязательный: идентификатор ресурса общедоступного IP-адреса (если он уже существует) можно подключить к шлюзу приложений. Если он не указан, общедоступный IP-адрес будет иметь значение {AppGwName}-IP.
• DisableAutoscale -Необязательный: отключение конфигурации автомасштабирования для экземпляров Шлюза приложений версии 2, false по умолчанию
• WafPolicyName -Необязательно. Имя политики WAF, которая будет создана из конфигурации WAF версии 1 и будет присоединена к шлюзу WAF версии 2.

Запуск скрипта

Выполните следующее, чтобы запустить этот сценарий.

1. Используется Connect-AzAccount для подключения к Azure.
2. Используйте Import-Module Az, чтобы импортировать модули Az.
3. Запустите командлет Set-AzContext, чтобы задать активный контекст Azure для правильной подписки. Это важный шаг, так как сценарий миграции может очистить существующую группу ресурсов, если она не существует в текущем контексте подписки.

   Set-AzContext -Subscription '<V1 application gateway SubscriptionId>'
   

4. Установка скрипта, выполнив действия по установке скрипта
5. Запустите скрипт с помощью соответствующих параметров. Для завершения может потребоваться пять–семь минут.

   ./AzureAppGWClone.ps1
   -resourceId <V1 application gateway Resource ID>
   -subnetAddressRange <subnet space you want to use>
   -appgwName <string to use to append>
   -AppGWResourceGroupName <resource group name you want to use>
   -privateIpAddress <private IP string>
   -publicIpResourceId <public IP name string>
   - disableAutoscale
   -wafpolicyname <wafpolicyname>
   

   Пример

   ./AzureAppGWClone.ps1 `
   -resourceId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv1appgateway `
   -subnetAddressRange 10.0.0.0/24 `
   -appgwname "MynewV2gw" `
   -AppGWResourceGroupName "MyResourceGroup" `
   -privateIpAddress "10.0.0.1" `
   -publicIpResourceId "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/publicIPAddresses/MyPublicIP" `
   

Recommendations

• После завершения скрипта просмотрите конфигурацию шлюза версии 2 на портале Azure и проверьте подключение, отправив трафик непосредственно в IP-адрес шлюза версии 2.
• Сценарий ослабляет проверку TLS серверной части по умолчанию (без цепочки сертификатов, истечения срока действия или проверки SNI) во время клонирования. Если требуются более строгие сертификаты проверки TLS или проверки подлинности, клиент может обновить свой пост создания шлюза приложений версии 2, чтобы добавить доверенные корневые сертификаты и включить эту функцию в соответствии с их требованиями.
• Для работы NTLM/Kerberos в режиме прозрачной передачи установите для подключения к серверу значение true в параметрах HTTP после клонирования.

Предупреждения

• Необходимо указать пространство IP-адресов для другой подсети в виртуальной сети, где находится шлюз версии 1. Скрипт не может создать шлюз версии 2 в подсети, которая уже имеет шлюз версии 1. Если подсеть уже имеет шлюз версии 2, скрипт может все еще работать, при условии, что доступно достаточное адресное пространство IP.
• Если у вас есть группа безопасности сети или определяемые пользователем маршруты, связанные с подсетью шлюза версии 2, убедитесь, что они соответствуют требованиям NSG и требованиям UDR для успешной миграции.
• Если для шлюза версии 1 включен режим FIPS, он не переносится в новый шлюз версии 2.
• Новый WAFV2 настроен для использования CRS 3.0 по умолчанию. Тем не менее, так как CRS 3.0 находится на пути к отмене, рекомендуется обновить до последнего набора правил, DRS 2.1 после миграции. Для получения дополнительных сведений см. группы правил и правила CRS и DRS, которые имеют группы безопасности сети или маршруты, определяемые пользователем, связанные с подсетью шлюза V2. Убедитесь, что они соответствуют требованиям NSG и UDR для успешной миграции.

2. Устаревший скрипт клонирования

Это старый скрипт клонирования, который упрощает переход следующим образом:

• Создание нового Standard_V2 или WAF_V2 шлюза приложений в указанной пользователем подсети виртуальной сети.
• Автоматическое копирование конфигурации из существующего шлюза Standard или WAF версии 1 в только что созданный шлюз версии 2.
• Требует, чтобы клиент предоставлял сертификаты SSL и проверки подлинности в качестве входных данных и не поддерживает частные шлюзы версии 2, вы можете скачать этот скрипт клонирования из коллекции PowerShell.

Параметры скрипта: Устаревший скрипт принимает следующие параметры:

• resourceId: [String]: обязательный: этот параметр является идентификатором ресурса Azure для существующего шлюза Standard V1 или WAF версии 1. Чтобы найти это строковое значение, перейдите на портал Azure, выберите шлюз приложений или ресурс WAF и щелкните ссылку "Свойства " для шлюза. Идентификатор ресурса находится на этой странице. Чтобы получить идентификатор ресурса, можно также выполнить следующие команды Azure PowerShell:

  $appgw = Get-AzApplicationGateway -Name <V1 gateway name> -ResourceGroupName <resource group Name>
  $appgw.Id
  

• subnetAddressRange: [String]: обязательный: этот параметр — это пространство IP-адресов, которое вы выделили (или хотите выделить) для новой подсети, содержащей новый шлюз версии 2. Адресное пространство должно быть указано в нотации CIDR. Например: 10.0.0.0/24. Вам не нужно заранее создать эту подсеть, но CIDR должна быть частью адресного пространства виртуальной сети. Скрипт создает его для вас, если он не существует, и использует существующий, если он уже есть (убедитесь, что подсеть либо пуста, либо содержит только шлюз версии 2, если он есть, и имеет достаточно доступных IP-адресов).
• appgwName: [String]: необязательно. Это строка, которую вы указываете для использования в качестве имени для нового шлюза Standard_V2 или WAF_V2. Если этот параметр не указан, используется имя вашего существующего шлюза версии 1 и добавляется суффикс _V2.
• AppGWResourceGroupName: [String]: необязательно. Имя группы ресурсов, в которой требуется создать ресурсы шлюза приложений версии 2 (значение <V1-app-gw-rgname>по умолчанию )

• sslCertificates: [PSApplicationGatewaySslCertificate]: необязательно. Разделенный запятыми список объектов PSApplicationGatewaySslCertificate, создаваемых для представления сертификатов TLS/SSL из шлюза V1, необходимо отправить в новый шлюз V2. Для каждого сертификата TLS/SSL, настроенного для шлюза Standard V1 или WAF V1, можно создать новый объект PSApplicationGatewaySslCertificate с помощью команды, показанной New-AzApplicationGatewaySslCertificate здесь. Вам нужен путь к файлу сертификата TLS/SSL и паролю.

  Этот параметр является необязательным, если у вас нет прослушивателей HTTPS, настроенных для шлюза версии 1 или WAF. Если у вас есть по крайней мере одна настройка прослушивателя HTTPS, необходимо указать этот параметр.

       $password = ConvertTo-SecureString <cert-password> -AsPlainText -Force
       $mySslCert1 = New-AzApplicationGatewaySslCertificate -Name "Cert01" `
      -CertificateFile <Cert-File-Path-1> `
       Password $password
       $mySslCert2 = New-AzApplicationGatewaySslCertificate -Name "Cert02" `
      -CertificateFile <Cert-File-Path-2> `
      -Password $password
  

  Вы можете передать $mySslCert1, $mySslCert2 (разделенные запятыми) в предыдущем примере в качестве значений для этого параметра в скрипте.

• sslCertificates из KeyVault: опционально. Вы можете скачать сертификаты, хранящиеся в Azure Key Vault, и передать его в скрипт миграции. Чтобы скачать сертификат в виде файла PFX, выполните следующую команду. Эти команды получают доступ к SecretId, а затем сохраняют содержимое в виде PFX-файла.

      $vaultName = ConvertTo-SecureString <kv-name> -AsPlainText -Force
      $certificateName = ConvertTo-SecureString <cert-name> -AsPlainText -Force
      $password = ConvertTo-SecureString <password> -AsPlainText -Force
      $pfxSecret = Get-AzKeyVaultSecret -VaultName $vaultName -Name $certificateName -AsPlainText
      $secretByte = [Convert]::FromBase64String($pfxSecret)
      $x509Cert = New-Object Security.Cryptography.X509Certificates.X509Certificate2
      $x509Cert.Import($secretByte, $null, [Security.Cryptography.X509Certificates.X509KeyStorageFlags]::Exportable)
      $pfxFileByte = $x509Cert.Export([Security.Cryptography.X509Certificates.X509ContentType]::Pkcs12, $password)
      # Write to a file
      [IO.File]::WriteAllBytes("KeyVaultcertificate.pfx", $pfxFileByte)
  

  Для каждого сертификата, скачаемого из Keyvault, можно создать новый объект PSApplicationGatewaySslCertificate с помощью команды New-AzApplicationGatewaySslCertificate, показанной здесь. Вам нужен путь к файлу сертификата TLS/SSL и паролю.

  //Convert the downloaded certificate to SSL object
  $password = ConvertTo-SecureString  <password> -AsPlainText -Force 
  $cert = New-AzApplicationGatewaySSLCertificate -Name <certname> -CertificateFile <Cert-File-Path-1> -Password $password 
  

• trustedRootCertificates: [PSApplicationGatewayTrustedRootCertificate]: необязательное. Список объектов PSApplicationGatewayTrustedRootCertificate, разделенных запятыми, создаваемых для представления доверенных корневых сертификатов для аутентификации ваших внутренних экземпляров из шлюза v2.

  $certFilePath = ".\rootCA.cer"
  $trustedCert = New-AzApplicationGatewayTrustedRootCertificate -Name "trustedCert1" -CertificateFile $certFilePath
  

  Чтобы создать список объектов PSApplicationGatewayTrustedRootCertificate, см. New-AzApplicationGatewayTrustedRootCertificate.

• privateIpAddress: [String]: необязательный. Конкретный частный IP-адрес, который требуется связать с новым шлюзом версии 2. Это должно быть из той же виртуальной сети, которую вы выделяете для нового шлюза версии 2. Если это не указано, скрипт выделяет частный IP-адрес для шлюза версии 2.

• publicIpResourceId: [String]: необязательно. ResourceId существующего ресурса публичного IP-адреса (стандартный SKU) в вашей подписке, который вы хотите выделить для нового шлюза версии 2. Если указано имя ресурса общедоступного IP-адреса, убедитесь, что он существует в успешном состоянии. Если это не указано, скрипт выделяет новый общедоступный IP-адрес в той же группе ресурсов. Имя — это имя шлюза версии 2 с добавленным суффиксом -IP. Если указано appGWResourceGroupName и не указан общедоступный IP-адрес, убедитесь, что общедоступный IP-ресурс с именем AppGWV2Name-IP не существует в группе ресурсов с именем appGWResourceGroupName в подписке V1.

• validateMigration: [switch]: опционально. Этот параметр позволяет скрипту выполнять некоторые базовые проверки сравнения конфигурации после создания шлюза версии 2 и копирования конфигурации. По умолчанию проверка не выполняется.

• enableAutoScale: [switch]: необязательно. Используйте этот параметр, чтобы включить скрипт, который позволит автоматическое масштабирование на новом шлюзе версии 2 после его создания. По умолчанию автомасштабирование отключено. Вы всегда можете включить его вручную на новосозданном шлюзе V2.

Запуск скрипта

Выполните следующее, чтобы запустить этот сценарий.

1. Используется Connect-AzAccount для подключения к Azure.
2. Используйте Import-Module Az, чтобы импортировать модули Az.
3. Запустите командлет Set-AzContext, чтобы задать активный контекст Azure для правильной подписки. Это важный шаг, так как сценарий миграции может очистить существующую группу ресурсов, если она не существует в текущем контексте подписки.

   Set-AzContext -Subscription '<V1 application gateway SubscriptionId>'
   

4. Установка скрипта, выполнив действия по установке скрипта
5. Выполните Get-Help AzureAppGWMigration.ps1, чтобы проверить необходимые параметры:
6. Запустите скрипт с помощью соответствующих параметров. Для завершения может потребоваться пять–семь минут.

      ./AzureAppGWMigration.ps1
      -resourceId <V1 application gateway Resource ID>
      -subnetAddressRange <subnet space you want to use>
      -appgwName <string to use to append>
      -AppGWResourceGroupName <resource group name you want to use>
      -sslCertificates <comma-separated SSLCert objects as above>
      -trustedRootCertificates <comma-separated Trusted Root Cert objects as above>
      -privateIpAddress <private IP string>
      -publicIpResourceId <public IP name string>
      -validateMigration -enableAutoScale
   

   Пример

      ./AzureAppGWMigration.ps1 `
      -resourceId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv1appgateway `
      -subnetAddressRange 10.0.0.0/24 `
      -appgwname "MynewV2gw" `
      -AppGWResourceGroupName "MyResourceGroup" `
      -sslCertificates $mySslCert1,$mySslCert2 `
      -trustedRootCertificates $trustedCert `
      -privateIpAddress "10.0.0.1" `
      -publicIpResourceId "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/publicIPAddresses/MyPublicIP" `
      -validateMigration -enableAutoScale
   

Предостережение\Ограничения

• Новый шлюз версии 2 имеет новые общедоступные и частные IP-адреса. Невозможно легко переместить IP-адреса, связанные с существующим шлюзом версии 1, в версию 2. Однако вы можете выделить существующий (нераспределенный) общедоступный или частный IP-адрес для нового шлюза версии 2.
• Необходимо указать пространство IP-адресов для другой подсети в виртуальной сети, где находится шлюз версии 1. Скрипт не может создать шлюз версии 2 в подсети, которая уже имеет шлюз версии 1. Если подсеть уже имеет шлюз версии 2, скрипт может все еще работать, при условии, что доступно достаточное адресное пространство IP.
• Если у вас есть группа безопасности сети или определяемые пользователем маршруты, связанные с подсетью шлюза версии 2, убедитесь, что они соответствуют требованиям группы безопасности сети и требованиям UDR для успешной миграции.
• Политики конечных точек служб для виртуальной сети в настоящее время не поддерживаются в подсети Шлюза приложений.
• Чтобы перенести конфигурацию TLS/SSL, необходимо указать все сертификаты TLS/SSL, используемые в шлюзе версии 1.
• Если для шлюза версии 1 включен режим FIPS, он не переносится в новый шлюз версии 2.
• WAFv2 создается в старом режиме конфигурации WAF; Требуется миграция в политику WAF.
• Новый WAFv2 настроен для использования CRS 3.0 по умолчанию. Тем не менее, так как CRS 3.0 находится на пути к отмене, рекомендуется обновить до последнего набора правил, DRS 2.1 после миграции. Дополнительные сведения см. в группах и правилах CRS и DRS.

Установка скрипта

Существует два варианта в зависимости от вашей локальной настройки и предпочтений в среде PowerShell:

• Если у вас нет установленных модулей Azure Az или не удается удалить модули Azure Az, лучше всего использовать Install-Script этот параметр для запуска скрипта.
• Если вам нужно сохранить модули Azure Az, лучше всего скачать скрипт и запустить его напрямую. Чтобы определить, установлены ли модули Azure Az, выполните команду Get-InstalledModule -Name az. Если вы не видите установленных модулей Az, можно использовать метод Install-Script.

Установка с помощью метода Install-Script (рекомендуется)

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

Выполните скрипт со следующей командой, чтобы получить последнюю версию:

• Для улучшенного клонирования скрипта сохранения публичных IP-адресов — Install-Script -Name AzureAppGWIPMigrate -Force

• Для устаревшего скрипта клонирования — Install-Script -Name AzureAppGWMigration -Force

Эта команда также устанавливает необходимые модули Az.

Установка с помощью скрипта напрямую

Если у вас установлены некоторые модули Azure Az и их не удается удалить (или не хотите их удалить), можно вручную скачать сценарий с помощью вкладки " Скачивание вручную " в ссылке скачивания скрипта.

Скрипт загружается как необработанный nupkg-файл. Чтобы установить скрипт из этого файла nupkg, см. раздел "Скачивание пакетов вручную".

Для устаревшего сценария клонирования версия 1.0.11 — это новая версия скрипта миграции, которая включает основные исправления ошибок. Обязательно используйте последнюю стабильную версию из коллекции PowerShell

Как проверить версию скачаемого скрипта

Чтобы проверить версию скачаемого скрипта, выполните следующие действия.

1. Извлеките содержимое пакета NuGet.
2. Откройте файл в папке и проверьте .PS1, чтобы удостовериться в версии, указанной сверху, загруженного скрипта.

<#PSScriptInfo
.VERSION 1.0.10
.GUID be3b84b4-e9c5-46fb-a050-699c68e16119
.AUTHOR Microsoft Corporation
.COMPANYNAME Microsoft Corporation
.COPYRIGHT Microsoft Corporation. All rights reserved.

Миграция трафика

Предпосылки

• Сначала дважды убедитесь, что скрипт успешно создал новый шлюз версии 2 с точной конфигурацией, перенесенной из шлюза версии 1. Это можно проверить на портале Azure.
• Кроме того, отправьте небольшой объем трафика через шлюз версии 2 в виде ручного теста.

Скрипт хранения общедоступных IP-адресов

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

• Переключение общедоступного IP-адреса: этот скрипт резервирует общедоступный IP-адрес стандартного уровня "Basic" из версии 1, преобразует его в уровень "Standard" и подключает к шлюзу версии 2. Это эффективно перенаправляет весь входящий трафик на шлюз версии 2.
• Ожидаемое время простоя: эта операция переключения IP-адресов обычно приводит к краткому простою примерно на 1–5 минут. Планируйте работу соответствующим образом.
• После успешного выполнения скрипта общедоступный IP-адрес перемещается из Шлюза приложений версии 1 в шлюз приложений версии 2, а шлюз приложений версии 1 получает новый общедоступный IP-адрес.

Этот скрипт хранения общедоступных IP-адресов можно скачать из коллекции PowerShell

Параметры скрипта:

Для этого скрипта требуются следующие обязательные параметры:

• V1 ResourceId — идентификатор ресурса шлюза приложений версии 1, общедоступный IP-адрес которого будет зарезервирован и связан с версией 2.
• ResourceId версии 2 — идентификатор ресурса шлюза приложений версии 2, которому будет назначен общедоступный IP-адрес версии 1. Шлюз версии 2 можно создать вручную или использовать любой из скриптов клонирования.

После скачивания и установки скрипта

Выполните AzureAppGWIPMigrate.ps1 с необходимыми параметрами:

   ./AzureAppGWIPMigrate.ps1
    -v1resourceId <V1 application gateway Resource ID>
    -v2resourceId <V2 application gateway Resource ID>

Пример

 ./AzureAppGWIPMigrate.ps1 `
 -v1resourceId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv1appgateway `
 -v2resourceId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv2appgateway `

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

Рекомендации по миграции трафика

Ниже приведены несколько сценариев, в которых текущий шлюз приложений (стандартный) может получать клиентский трафик и рекомендации по каждому из них:

• Настраиваемая зона DNS (например, contoso.com), указывающая на внешний IP-адрес (используя запись A), связанную с шлюзом Standard V1 или WAF V1. Вы можете обновить запись DNS, чтобы указать на внешний IP-адрес или метку DNS, связанную с шлюзом приложений Standard_V2. В зависимости от настроенного показателя TTL в вашей записи DNS может потребоваться какое-то время, чтобы весь клиентский трафик переключился на новый шлюз версии 2.
• Настраиваемая зона DNS (например, contoso.com), указывающая на метку DNS (например, myappgw.eastus.cloudapp.azure.com с записью CNAME), связанную с шлюзом V1. У вас есть два варианта:
  • Если вы используете общедоступные IP-адреса в шлюзе приложений, вы можете выполнить контролируемую, детализированную миграцию, используя профиль Диспетчера трафика для постепенной маршрутизации трафика, применяя взвешенный метод маршрутизации к новому шлюзу версии V2. Это можно сделать, добавив метки DNS для шлюзов приложений версии 1 и версии 2 в профиль диспетчера трафика и создав CNAME-запись вашей настраиваемой записи DNS (например, www.contoso.com) в домен диспетчера трафика (например, contoso.trafficmanager.net).
  • Кроме того, вы можете обновить запись DNS личного домена, чтобы указать на метку DNS нового шлюза приложений версии 2. В зависимости от значения TTL (времени жизни), установленного в вашей записи DNS, может пройти некоторое время до того, как весь трафик клиента будет перенаправлен на новый шлюз версии 2.
• Клиенты подключаются к внешнему IP-адресу шлюза приложений. Обновите клиентов, чтобы использовать IP-адрес, связанный с недавно созданным шлюзом приложений V2. Рекомендуется не использовать IP-адреса напрямую. Рекомендуется использовать метку DNS-имени (например, yourgateway.eastus.cloudapp.azure.com), связанную с вашим шлюзом приложений, которую вы можете указать в качестве CNAME в вашей собственной пользовательской зоне DNS (например, contoso.com).

После миграции

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

Рекомендации по ценам

Модели ценообразования отличаются для номеров SKU шлюза приложений версии 1 и версии 2. Плата за V2 взимается в зависимости от объема потребления. Перед переносом см. цены на шлюз приложений, чтобы получить информацию о ценах.

Руководство по повышению эффективности затрат

SKU версии 2 поставляется с рядом преимуществ, таких как увеличение производительности в 5 раз, улучшенная безопасность благодаря интеграции с Key Vault, более быстрые обновления правил безопасности в WAF_V2, пользовательских правилах для WAF, ассоциациях политик, а также защите ботов. Она также обеспечивает высокую масштабируемость, оптимизированную маршрутизацию трафика и простую интеграцию со службами Azure. Эти функции могут улучшить общий пользовательский интерфейс, предотвратить замедление во время интенсивного трафика и избежать дорогостоящих нарушений данных.

Существует пять вариантов в версии SKU V1 на основе типа и размера — Standard_Small, Standard_Medium, Standard_Large, WAF_Medium и WAF_Large.

Для дальнейших проблем с ценами обратитесь к CSAM или обратитесь к нашей группе поддержки за помощью.

Распространенные вопросы

Распространенные вопросы о миграции можно найти здесь

Дальнейшие шаги

Сведения о шлюзе приложений версии 2