PowerShell を使って Basic Load Balancer をアップグレードする

[アーティクル]
04/09/2024

重要

Basic Load Balancer は 2025 年 9 月 30 日に廃止されます。詳細については、公式告知を参照してください。現在 Basic Load Balancer を使用している場合は、廃止日前に必ず Standard Load Balancer にアップグレードしてください。

Azure Standard Load Balancer では、豊富な機能とゾーンの冗長性による高可用性が提供されます。 Load Balancer SKU の詳細については、比較表を参照してください。

この記事では、Basic Load Balancer と同じ構成を持つ Standard Load Balancer を作成した後、その新しい Load Balancer に仮想マシンスケールセットまたは仮想マシンのバックエンドプールメンバーを関連付ける PowerShell モジュールを紹介します。

アップグレードのモジュールとプロセスの詳細なチュートリアルについては、次のビデオをご覧ください。

03:06 - 詳細な手順
32:54 - 回復
40:55 - 高度なシナリオ
57:54 - リソース

アップグレードの概要

PowerShell モジュールを使って、次の機能を実行できます。

提供された Basic Load Balancer のシナリオのアップグレードがサポートされていることを確認します。
Basic Load Balancer と仮想マシンスケールセットの構成をバックアップし、失敗時またはエラーが発生した場合の再試行を有効にします。
パブリックロードバランサーの場合、フロントエンドのパブリック IP アドレスを Standard SKU と静的割り当に更新します。
Basic Load Balancer の構成を新しい Standard Load Balancer にアップグレードし、構成と機能パリティを確保します。
仮想マシンスケールセットおよび仮想マシンのバックエンドプールメンバーを Basic Load Balancer から Standard Load Balancer に移行します。
ネットワークセキュリティグループを作成して仮想マシンスケールセットまたは仮想マシンに関連付けることにより、Standard Load Balancer の既定で拒否のネットワークポリシーへの移行に従って、負荷分散されたトラフィックがバックエンドプールメンバーに確実に到達するようにします。
仮想マシンスケールセットまたは仮想マシンインスタンスに関連付けられているインスタンスレベルのパブリック IP アドレスをアップグレードします
インバウンド NAT プールを仮想マシンスケールセットバックエンドのインバウンド NAT 規則にアップグレードし、移行された NAT プールごとに新しいバックエンドプールを作成します。後で使用できるバックエンドプールオプションを増やすには、-skipUpgradeNATPoolsToNATRules を指定して、このアップグレードをスキップし、スタンドアロン NAT プール移行モジュールを使用します。
監査とエラー回復を容易にするために、アップグレード操作をログに記録します。

警告

バックエンド VM または VMSS インスタンスにパブリック IP アドレスがない "内部" Basic Load Balancer に移行するには、インターネットへのバックエンド接続のための追加アクションが必要です。「ロードバランサーの送信トラフィックをどのように構成する必要がありますか?」をご覧ください。

Note

Load Balancer バックエンドプール内の仮想マシンスケールセットのネットワーク構成にパブリック IP アドレスが含まれている場合、仮想マシンスケールセットの各インスタンスに関連付けられているパブリック IP アドレスは、Standard SKU にアップグレードされるときに変更されます。これは、スケールセットのインスタンスレベルのパブリック IP アドレスはアップグレードできず、新しい Standard SKU のパブリック IP に置き換えられるだけであるためです。その他すべてのパブリック IP アドレスは、移行を通して保持されます。

Note

Load Balancer の背後にある仮想マシンスケールセットが Service Fabric クラスターの場合、このスクリプトを使用した移行には時間がかかり、アプリケーションに対するリスクが高くなり、ダウンタイムが発生します。移行オプションについては、Service Fabric Cluster Load Balancer のアップグレードに関するガイダンスを参照してください。

サポートされていないシナリオ

IPv6 フロントエンド IP 構成を持つ Basic Load Balancer
Azure Kubernetes Service (AKS) クラスターの Basic Load Balancer
1 つ以上の仮想マシンスケールセットインスタンスで ProtectFromScaleSetActions インスタンス保護ポリシーが有効になっている仮想マシンスケールセットのバックエンドプールメンバーを持つ Basic Load Balancer
既存の Standard Load Balancer への Basic Load Balancer の移行

'AzureBasicLoadBalancerUpgrade' モジュールをインストールする

前提条件

PowerShell: Windows、Linux、macOS を含むすべてのプラットフォームで AzureBasicLoadBalancerUpgrade モジュールに使用するには、サポート対象バージョンである PowerShell 7 以降が推奨されています。ただし、Windows での PowerShell 5.1 はサポートされています。

モジュールのインストール

PowerShell ギャラリーからモジュールをインストールします

Install-Module -Name AzureBasicLoadBalancerUpgrade -Scope CurrentUser -Repository PSGallery -Force

移行前後の手順

移行前の手順

シナリオがサポートされていることを検証する
移行中のアプリケーションのダウンタイム計画
トラフィックの受信と送信の接続テストを開発する
仮想マシンスケールセットインスタンスでインスタンスレベルのパブリック IP の変更を計画する (注を参照)
(推奨) ネットワークセキュリティグループを作成するか、バックエンドプールメンバーの既存のネットワークセキュリティグループにセキュリティ規則を追加します。 Load Balancer を通過するトラフィックと、パブリック Standard SKU リソースで明示的に許可する必要があるその他のトラフィックを許可します
(推奨) 後の「ロードバランサーの送信トラフィックをどのように構成する必要がありますか?」で説明されている方法のいずれかを使って、送信接続を準備します。

移行後の手順

移行が正常に終了したことを確認する
Load Balancer を使用して受信アプリケーション接続をテストする
バックエンドプールメンバーからインターネットへの送信接続をテストする
複数のバックエンドプールを持つ Public Load Balancer の場合は、バックエンドプールごとに送信ルールを作成します

モジュールを使う

Select-AzSubscription を実行して、Basic Load Balancer のサブスクリプション ID を選択していることを確認します。
```
Select-AzSubscription -Subscription <SubscriptionId>
```
アップグレードするロードバランサーを見つけます。その名前とリソースグループ名をメモします。
基本的なモジュールのパラメーターを確認します。
- BasicLoadBalancerName [string] "必須" - このパラメーターは、アップグレードする既存の Basic Load Balancer の名前です。
- ResourceGroupName [string] "必須" - このパラメーターは、Basic Load Balancer が含まれているリソースグループの名前です。
- "StandardLoadBalancerName [文字列] 省略可能" - このパラメーターを使って、必要に応じて Standard Load Balancer の新しい名前を構成します。指定しない場合は、Basic Load Balancer の名前が再利用されます。
- RecoveryBackupPath [string] "省略可能" - このパラメーターを使用すると、Basic Load Balancer の ARM テンプレートバックアップファイルを格納するための代替パスを指定できます (既定値は現在の作業ディレクトリ)。
ヒント

高度なシナリオおよび復旧シナリオ用の追加パラメーターは、Get-Help Start-AzBasicLoadBalancerUpgrade -Detailed を実行して確認できます
次の例を参考にして、Start-AzBasicLoadBalancerUpgrade コマンドを実行します。

例: シナリオを検証する

Basic Load Balancer がアップグレードでサポートされていることを確認する

Start-AzBasicLoadBalancerUpgrade -ResourceGroupName <loadBalancerRGName> -BasicLoadBalancerName <basicLBName> -validateScenarioOnly

例: 名前によるアップグレード

Basic Load Balancer の名前とリソースグループを指定して、Basic Load Balancer を同じ名前の Standard Load Balancer にアップグレードする

Start-AzBasicLoadBalancerUpgrade -ResourceGroupName <loadBalancerRGName> -BasicLoadBalancerName <basicLBName>

例: アップグレード、名前の変更、ログの表示

Basic Load Balancer を指定された名前の Standard Load Balancer にアップグレードし、ログに記録された出力を画面に表示する

Start-AzBasicLoadBalancerUpgrade -ResourceGroupName <loadBalancerRGName> -BasicLoadBalancerName <basicLBName> -StandardLoadBalancerName <newStandardLBName> -FollowLog

例: 代替バックアップパスを使用したアップグレード

Basic Load Balancer を指定された名前の Standard Load Balancer にアップグレードし、Basic Load Balancer のバックアップファイルを指定されたパスに格納する

Start-AzBasicLoadBalancerUpgrade -ResourceGroupName <loadBalancerRGName> -BasicLoadBalancerName <basicLBName> -StandardLoadBalancerName <newStandardLBName> -RecoveryBackupPath C:\BasicLBRecovery

例: 完了した移行を検証する

Basic Load Balancer 状態ファイルのバックアップと Standard Load Balancer の名前を渡して完了した移行を検証する

Start-AzBasicLoadBalancerUpgrade -validateCompletedMigration -StandardLoadBalancerName <newStandardLBName> -basicLoadBalancerStatePath C:\RecoveryBackups\State_mybasiclb_rg-basiclbrg_20220912T1740032148.json

共有バックエンドメンバーを持つ複数の Load Balancer を同時に移行する (通常、アプリケーションに内部と外部 Load Balancer がある場合)

# build array of multiple basic load balancers
$multiLBConfig = @(
    @{
        'standardLoadBalancerName' = 'myStandardInternalLB01' # specifying the standard load balancer name is optional
        'basicLoadBalancer' = (Get-AzLoadBalancer -ResourceGroupName myRG -Name myBasicInternalLB01)
    },
        @{
        'standardLoadBalancerName' = 'myStandardExternalLB02'
        'basicLoadBalancer' = (Get-AzLoadBalancer -ResourceGroupName myRG -Name myBasicExternalLB02)
    }
)
# pass the array of load balancer configurations to the -MultiLBConfig parameter
Start-AzBasicLoadBalancerUpgrade -MultiLBConfig $multiLBConfig

例: 失敗した仮想マシンスケールセットの移行を再試行する

Basic Load Balancer と仮想マシンスケールセットのバックアップ状態ファイルを指定して、(エラーまたはスクリプトの終了のために) 失敗した仮想マシンスケールセットのロードバランサーのアップグレードを再試行する

Start-AzBasicLoadBalancerUpgrade -FailedMigrationRetryFilePathLB C:\RecoveryBackups\State_mybasiclb_rg-basiclbrg_20220912T1740032148.json -FailedMigrationRetryFilePathVMSS C:\RecoveryBackups\VMSS_myVMSS_rg-basiclbrg_20220912T1740032148.json

例: 失敗した仮想マシンの移行を再試行する

Basic Load Balancer のバックアップ状態ファイルを指定して、(エラーまたはスクリプトの終了のために) 失敗した VM ロードバランサーのアップグレードを再試行する

Start-AzBasicLoadBalancerUpgrade -FailedMigrationRetryFilePathLB C:\RecoveryBackups\State_mybasiclb_rg-basiclbrg_20220912T1740032148.json

一般的な質問

自分の環境で移行する Basic Load Balancer を一覧表示するにはどうすればよいですか?

環境内で移行する必要がある Basic Load Balancer の一覧を取得する方法の 1 つが、Azure Resource Graph クエリを使用することです。この単純なクエリでは、アクセスして表示できるすべての Basic Load Balancer が一覧表示されます。

Resources
| where type == 'microsoft.network/loadbalancers' and sku.name == 'Basic'

また、より複雑なクエリも用意しており、このモジュールで検証中にチェックするほとんどの条件について、各 Basic Load Balancer の移行の準備状況を評価することができます。 Resource Graph クエリは GitHub プロジェクトにあります。また、Azure Resource Graph Explorer で開くこともできます。

この移行によってアプリケーションにダウンタイムが発生しますか?

はい。新しい Standard Load Balancer を作成する前に Basic Load Balancer を削除する必要があるため、アプリケーションにダウンタイムが発生します。「アップグレードにはどのくらいの時間がかかりますか?」を参照してください。

このモジュールは、フロントエンド IP アドレスを新しい Standard Load Balancer に移行しますか?

はい、このモジュールを使うと、パブリックと内部の両方のロードバランサーについて、フロントエンドの IP アドレスは維持されます。パブリック IP の場合は、移行前に IP が静的 IP に変換されます。内部フロントエンドの場合、モジュールは Basic ロードバランサーが削除されたときに解放されたのと同じ IP アドレスの再割り当てを試みます。プライベート IP が使用できない場合、スクリプトは失敗します (「移行の途中でアップグレードに失敗した場合はどうなりますか?」を参照)。

アップグレードにはどのくらいの時間がかかりますか?

アップグレードは、通常、スクリプトが完了するまでに数分かかります。次の要因によって、アップグレードにかかる時間が長くなることがあります。

ロードバランサーの構成が複雑な場合
バックエンドプールメンバーの数
関連付けられた Virtual Machine Scale Sets または Virtual Machines のインスタンス数
Service Fabric クラスター: Service Fabric クラスターのアップグレードは、テストに約 1 時間かかります

そのため、ダウンタイムを考慮し、必要に応じてフェールオーバーを計画してください。

このスクリプトは、Basic Load Balancer のバックエンドプールメンバーを新しく作成された Standard Load Balancer に移行しますか?

はい。この Azure PowerShell スクリプトは、Virtual Machine Scale Sets と Virtual Machines を新しく作成された Standard Load Balancer バックエンドプールに移行します。

どのロードバランサーコンポーネントが移行されますか?

このスクリプトは、Basic Load Balancer から Standard Load Balancer に次のものを移行します。

パブリックおよびプライベートロードバランサー:

正常性プローブ:
- すべてのプローブが新しい Standard Load Balancer に移行される
負荷分散ルール:
- すべての負荷分散規則が新しい Standard Load Balancer に移行される
インバウンド NAT 規則:
- ユーザーが作成したすべての NAT 規則が新しい Standard Load Balancer に移行される
受信 NAT プール:
- 既定では、NAT プールは NAT 規則にアップグレードされます
- 代わりに NAT プールを移行するには、アップグレード時に -skipUpgradeNATPoolsToNATRules パラメータを指定します
バックエンドプール:
- すべてのバックエンドプールが新しい Standard Load Balancer に移行される
- 仮想マシンスケールセットと仮想マシンのすべてのネットワークインターフェイスと IP 構成が新しい Standard Load Balancer に移行される
- 仮想マシンスケールセットがローリングアップグレードポリシーを使用している場合、このスクリプトは、移行プロセス中に仮想マシンスケールセットのアップグレードポリシーを [手動] に更新し、移行が完了したら [ローリング] に戻します。
インスタンスレベルのパブリック IP アドレス
- Virtual Machines と Virtual Machine Scale Sets の両方で、アタッチされたパブリック IP が Basic から Standard SKU に変換されます。スケールセットのインスタンスのパブリック IP はアップグレードの間に変更されますが、仮想マシンの IP は変更されないことに注意してください。
タグが Basic Load Balancer から Standard Load Balancer に

パブリックロードバランサー:

パブリックフロントエンドの IP 構成
- 動的な場合はパブリック IP を静的 IP に変換します
- Basic の場合、パブリック IP SKU を Standard に更新します
- 関連付けられたすべてのパブリック IP を新しい Standard Load Balancer にアップグレードする
アウトバウンド規則:
- Basic ロードバランサーは構成されたアウトバウンド規則をサポートしていません。このスクリプトにより、Basic ロードバランサーのアウトバウンド動作を維持するアウトバウンド規則が Standard ロードバランサーに作成されます。アウトバウンド規則の詳細については、アウトバウンド規則に関するページを参照してください。
ネットワークセキュリティグループ
- Basic Load Balancer には、送信接続を許可するためのネットワークセキュリティグループが必要ありません。仮想マシンスケールセットに関連付けられたネットワークセキュリティグループがない場合は、同じ機能を保持するために、新しいネットワークセキュリティグループが作成されます。この新しいネットワークセキュリティグループは、仮想マシンスケールセットのバックエンドプールメンバーのネットワークインターフェイスに関連付けられます。これにより、同じ負荷分散規則のポートとプロトコルが許可され、アウトバウンド接続が保持されます。

内部ロードバランサー:

プライベートフロントエンドの IP 構成

Note

ネットワークセキュリティグループは、内部ロードバランサーのアップグレードの一部として構成されません。 NSG の詳細については、ネットワークセキュリティグループに関する記事を参照してください

バックエンドプールのメンバーが複数の Load Balancer に属している場合、どのように移行すればよいですか?

バックエンドプールのメンバーが別の Load Balancer のバックエンドプールにも属しているシナリオ (同じアプリケーションに内部 Load Balancer と外部 Load Balancer がある場合など) では、各 Basic Load Balancer を同時に移行する必要があります。 Load Balancer を一度に 1 つずつ移行しようとすると、Basic SKU と Standard SKU のリソースを混在させることになりますが、それは許可されていません。移行スクリプトでは、同じスクリプト実行に -MultiLBConfig パラメーターを使って複数の Basic Load Balancer を渡すことで、これがサポートされます。

移行が成功したことを検証するにはどうすればよいですか?

アップグレードモジュールは、その実行の最後に以下の検証を実行し、Basic Load Balancer と新しい Standard Load Balancer を比較します。移行が失敗した場合は、-validateCompletedMigration パラメーターと -basicLoadBalancerStatePath パラメーターを使って同じ操作を呼び出し、Standard Load Balancer の構成状態 (作成された場合) を判断することができます。移行中に作成されたログファイルにも、移行操作とエラーに関する詳細が記載されています。

Standard Load Balancer が存在し、その SKU が "Standard" である
フロントエンド IP 構成の数が一致し、IP アドレスが同じである
バックエンドプールとそのメンバーシップの数が一致する
負荷分散規則の数が一致する
正常性プローブの数が一致する
インバウンド NAT 規則の数が一致する
インバウンド NAT プールの数が一致する
外部 Standard Load Balancer にアウトバウンド規則が構成されている
外部 Standard Load Balancer バックエンドプールのメンバーにネットワークセキュリティグループが関連付けられている

ロードバランサーの送信トラフィックをどのように構成する必要がありますか?

Standard SKU Load Balancer では、バックエンドプールメンバーの既定の送信アクセスは許可されません。インターネットへの送信アクセスを許可するには、追加の手順が必要です。

外部ロードバランサーの場合は、アウトバウンド規則を使って、プールメンバーの送信トラフィックを明示的に有効にできます。バックエンドプールが 1 つだけの場合は、移行の間にアウトバウンド規則が自動的に構成されます。バックエンドプールが複数ある場合は、ユーザーがアウトバウンド規則を手動で作成して、ポートの割り当てを指定する必要があります。

内部ロードバランサーの場合は、SNAT を経由するパブリック IP アドレスがないため、アウトバウンド規則はオプションではありません。次のようなオプションを考慮する必要があります。

NAT Gateway: ほとんどの場合、送信トラフィックに対しては NAT Gateway が Azure の推奨されるアプローチです。ただし、NAT ゲートウェイを使うときは、アタッチされたサブネットに Basic SKU ネットワークリソースが存在していてはなりません。つまり、使う前にすべてのロードバランサーとパブリック IP アドレスを移行しておく必要があります。このため、2 ステップのアプローチの使用をお勧めします。最初に送信接続に対して次のいずれかのアプローチを使用した後、Basic SKU の移行が完了したら NAT Gateway に切り替えます。
ネットワーク仮想アプライアンス: Azure Firewall などのネットワーク仮想アプライアンスを通してトラフィックをルーティングします。その後で、トラフィックはインターネットにルーティングされます。このオプションは、ネットワーク仮想アプライアンスが既に構成されている場合に最適です。
セカンダリ外部ロードバランサー: セカンダリ外部ロードバランサーをバックエンドリソースに追加すると、アウトバウンド規則を構成して送信トラフィックに外部ロードバランサーを使用できます。この外部ロードバランサーに負荷分散規則、NAT 規則、または受信 NAT プールが構成されていない場合、バックエンドリソースは、受信トラフィック用に内部ネットワークに分離されたままになります。「送信専用のロードバランサーの構成」をご覧ください。このオプションを使うと、Basic から Standard SKU に移行する前に外部ロードバランサーを構成し、-MultiLBConfig パラメーターを使って内部ロードバランサーと同時に移行できます。
パブリック IP アドレス: 最後に、パブリック IP アドレスを仮想マシンまたは仮想マシンスケールセットインスタンスに直接追加することもできます。ただし、セキュリティの脅威にさらされる領域が増え、パブリック IP アドレスを追加する費用がかかるため、このオプションはお勧めしません。

移行の途中でアップグレードに失敗した場合はどうなりますか?

このモジュールは、未処理のエラーまたは予期しないスクリプトの終了による失敗に対応するように設計されています。このエラー設計は "フェールフォワード" のアプローチです。つまり、元の Basic Load Balancer に移行し直そうとするのではなく、エラーの原因となった問題を修正し (エラー出力またはログファイルを参照)、-FailedMigrationRetryFilePathLB <BasicLoadBalancerBackupFilePath> -FailedMigrationRetryFilePathVMSS <VMSSBackupFile> パラメーターを指定して移行を再試行する必要があります。パブリックロードバランサーの場合は、パブリック IP アドレス SKU が Standard に更新されているため、同じ IP を元の Basic Load Balancer に移行し直すことはできません。

回復プロセスのビデオをご覧ください。

失敗した移行が複数のロードバランサーを同時にターゲットにしていた場合は、-MultiLBConfig パラメーターを使って、以下と同じプロセスに従って各 Load Balancer を個別に復旧します。

基本的なエラー回復の手順は次のとおりです。

移行の失敗の原因に対処します。詳細については、ログファイル Start-AzBasicLoadBalancerUpgrade.log を確認します
新しい Standard Load Balancer を削除します (作成された場合)。移行のどの段階で失敗したかによっては、Standard Load Balancer を削除するために、仮想マシンスケールセットまたは仮想マシンのネットワークインターフェイス (IP 構成) と正常性プローブから Standard Load Balancer の参照を削除することが必要になる場合があります。
Basic Load Balancer の状態バックアップファイルを見つけます。このファイルは、スクリプトが実行されたディレクトリか、または失敗した実行の間に -RecoveryBackupPath パラメーターで指定されたパスのどちらかにあります。ファイルの名前は State_<basicLBName>_<basicLBRGName>_<timestamp>.json です
-BasicLoadBalancerName の代わりに -FailedMigrationRetryFilePathLB <BasicLoadBalancerbackupFilePath> および -FailedMigrationRetryFilePathVMSS <VMSSBackupFile> (仮想マシンスケールセットバックエンド用) パラメータを指定するか、またはパイプライン経由で Basic Load Balancer を渡して、移行スクリプトを再実行します

次のステップ

スキップした場合は、NAT プールの使用から Virtual Machine Scale Sets の NAT 規則に移行する
[Azure Load Balancer] について説明します。

次の方法で共有

PowerShell を使って Basic Load Balancer をアップグレードする

アップグレードの概要

サポートされていないシナリオ

'AzureBasicLoadBalancerUpgrade' モジュールをインストールする

前提条件

モジュールのインストール

移行前後の手順

移行前の手順

移行後の手順

モジュールを使う

例: シナリオを検証する

例: 名前によるアップグレード

例: アップグレード、名前の変更、ログの表示

例: 代替バックアップパスを使用したアップグレード

例: 完了した移行を検証する

例: 失敗した仮想マシンスケールセットの移行を再試行する

例: 失敗した仮想マシンの移行を再試行する

一般的な質問

自分の環境で移行する Basic Load Balancer を一覧表示するにはどうすればよいですか?

この移行によってアプリケーションにダウンタイムが発生しますか?

このモジュールは、フロントエンド IP アドレスを新しい Standard Load Balancer に移行しますか?

アップグレードにはどのくらいの時間がかかりますか?

このスクリプトは、Basic Load Balancer のバックエンドプールメンバーを新しく作成された Standard Load Balancer に移行しますか?

どのロードバランサーコンポーネントが移行されますか?

バックエンドプールのメンバーが複数の Load Balancer に属している場合、どのように移行すればよいですか?

移行が成功したことを検証するにはどうすればよいですか?

ロードバランサーの送信トラフィックをどのように構成する必要がありますか?

移行の途中でアップグレードに失敗した場合はどうなりますか?

次のステップ

フィードバック

その他のリソース

次の方法で共有

PowerShell を使って Basic Load Balancer をアップグレードする

アップグレードの概要

サポートされていないシナリオ

'AzureBasicLoadBalancerUpgrade' モジュールをインストールする

前提条件

モジュールのインストール

移行前後の手順

移行前の手順

移行後の手順

モジュールを使う

例: シナリオを検証する

例: 名前によるアップグレード

例: アップグレード、名前の変更、ログの表示

例: 代替バックアップ パスを使用したアップグレード

例: 完了した移行を検証する

例: 複数の関連ロード バランサーを移行する

例: 失敗した仮想マシン スケール セットの移行を再試行する

例: 失敗した仮想マシンの移行を再試行する

一般的な質問

自分の環境で移行する Basic Load Balancer を一覧表示するにはどうすればよいですか?

この移行によってアプリケーションにダウンタイムが発生しますか?

このモジュールは、フロントエンド IP アドレスを新しい Standard Load Balancer に移行しますか?

アップグレードにはどのくらいの時間がかかりますか?

このスクリプトは、Basic Load Balancer のバックエンド プール メンバーを新しく作成された Standard Load Balancer に移行しますか?

どのロード バランサー コンポーネントが移行されますか?

バックエンド プールのメンバーが複数の Load Balancer に属している場合、どのように移行すればよいですか?

移行が成功したことを検証するにはどうすればよいですか?

ロード バランサーの送信トラフィックをどのように構成する必要がありますか?

移行の途中でアップグレードに失敗した場合はどうなりますか?

次のステップ

フィードバック

その他のリソース

例: 代替バックアップパスを使用したアップグレード

例: 複数の関連ロードバランサーを移行する

例: 失敗した仮想マシンスケールセットの移行を再試行する

このスクリプトは、Basic Load Balancer のバックエンドプールメンバーを新しく作成された Standard Load Balancer に移行しますか?

どのロードバランサーコンポーネントが移行されますか?

バックエンドプールのメンバーが複数の Load Balancer に属している場合、どのように移行すればよいですか?

ロードバランサーの送信トラフィックをどのように構成する必要がありますか?