次の方法で共有


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

重要

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 モジュールを紹介します。

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

アップグレードの概要

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 の場合は、バックエンド プールごとに送信ルールを作成します

モジュールを使う

  1. Select-AzSubscription を実行して、Basic Load Balancer のサブスクリプション ID を選択していることを確認します。

    Select-AzSubscription -Subscription <SubscriptionId>
    
  2. アップグレードするロード バランサーを見つけます。 その名前とリソース グループ名をメモします。

  3. 基本的なモジュールのパラメーターを確認します。

    • 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 を実行して確認できます

  4. 次の例を参考にして、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 を個別に復旧します。

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

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

次のステップ