サードパーティ アプライアンスのための内部 TCP / UDP 負荷分散の設定

Google Cloud では、可用性の高いスケールアウト方式でサードパーティ アプライアンスを統合できます。これを行うには、カスタム静的ルートを構成して、Google Cloud の内部 TCP / UDP ロードバランサにネクストホップを設定します。これにより、ロードバランサは、ヘルスチェックされたサードパーティ VM アプライアンスのプールに宛先プレフィックスされたトラフィックを負荷分散できます。

このガイドでは、サンプルを示しながら、内部 TCP / UDP ロードバランサをネクストホップとして構成する方法を説明します。このガイドに進む前に、次の内容を理解しておいてください。

権限

このガイドを使用する前に、インスタンスを作成し、プロジェクト内のネットワークを変更しておく必要があります。そのためにはプロジェクトの所有者または編集者であるか、または次の Compute Engine IAM ロールをすべて持っている必要があります。

タスク 必要なロール
ネットワーク、サブネット、負荷分散コンポーネントの作成 ネットワーク管理者
ファイアウォール ルールの追加と削除 セキュリティ管理者
インスタンスの作成 Compute インスタンス管理者

詳細については、次のガイドをご覧ください。

共通のバックエンドで内部 TCP / UDP ロードバランサをネクストホップとして設定する

このガイドでは、拡張静的ルートのネクストホップとして内部 TCP / UDP ロードバランサを使用して、スケールアウトされた仮想アプライアンスを統合する方法について説明します。

このガイドで説明するソリューションでは、Debian Linux と iptables を実行するアプライアンス VM を作成します。サンプルの VM では、パケット フィルタリングは行いませんが、その機能は、この例の iptables 構成を変更するか、別のパケット フィルタリングまたはルーティング ソフトウェアを使用することで追加できます。

このセクションでは、次のリソースの構成方法について説明します。

  • サンプルの VPC ネットワークとカスタム サブネット
  • バックエンドのアプライアンス仮想マシン(VM)への受信接続を許可する Google Cloud ファイアウォール ルール
  • カスタム静的ルート
  • 接続をテストするための 2 つのクライアント VM
  • 次の内部 TCP / UDP ロードバランサ コンポーネント:
    • マネージド インスタンス グループ(MIG)内のバックエンド VM
    • バックエンド VM に対するヘルスチェック
    • バックエンド VM 間の接続分散を管理する us-west1 リージョン内の内部バックエンド サービス
    • ロードバランサのフロントエンドの内部転送ルールと内部 IP アドレス

この例では、複数の NIC への負荷分散で説明されているように、複数のバックエンド NIC への負荷分散を示します。

トポロジの概要は次のとおりです。

内部 TCP / UDP 負荷分散用のネクストホップ マルチ NIC の詳細例
内部 TCP / UDP 負荷分散用のネクストホップ マルチ NIC の詳細例(クリックして拡大)

この例で作成するリソースは次のとおりです。

  • 内部 TCP / UDP ロードバランサ(この例では fr-ilb1)の背後にあるアプリケーション インスタンス(この例では iptables を実行している VM)。アプリケーション インスタンスには内部 IP アドレスのみが設定されています。
  • 各アプリケーション インスタンスで can-ip-forward フラグが有効になっています。このフラグを設定しないと、Compute Engine VM がパケットを送信できるのが、パケットの送信元 IP アドレスが VM の内部 IP アドレス、エイリアス IP 範囲の IP アドレス、または VM に解決される転送ルールの IP アドレスと一致する場合に限定されます。can-ip-forward フラグを使用すると、VM はどのような送信元 IP アドレスのパケットも送信できるようになります。
  • 宛先 10.50.1.0/24 とネクストホップがロードバランサの転送ルール fr-ilb1 に設定されたカスタム静的ルート

トラフィック フローは次の図のようになります。

  • testing VPC ネットワークには、宛先が 10.50.1.0/24 サブネットのカスタム静的ルートが設定されています。これにより、トラフィックがロードバランサに転送されます。
  • 構成されたセッション アフィニティに基づいて、ロードバランサがいずれかのアプリケーション インスタンスにトラフィックを転送します(セッション アフィニティは TCP トラフィックにのみ適用されます)。

他のユースケースについては、ネクストホップとしての内部 TCP / UDP ロードバランサをご覧ください。

ネットワーク、リージョン、サブネットの構成

この例では、次の VPC ネットワーク、リージョン、サブネットを使用します。

  • ネットワーク: この例では、少なくとも 2 つのネットワークが必要です。それぞれに 1 つ以上のサブネットが必要です。各バックエンド サードパーティ アプライアンス VM には、VPC ネットワークごとに 1 つずつ、少なくとも 2 つのネットワーク インターフェースが必要です。この例のネットワークでは、testingproduction というカスタムモードの VPC ネットワークがあります。この例の testing ネットワークには、クライアントとロードバランサが含まれます。production ネットワークには、宛先ターゲット VM が含まれます。

  • リージョン: サブネットは us-west1 リージョンにあります。VM インスタンスはゾーンリソースであるため、サブネットは同じリージョン内に存在する必要があります。

  • サブネット: サブネット testing-subnetproduction-subnet は、それぞれ 10.30.1.0/2410.50.1.0/24 のプライマリ IP アドレス範囲を使用します。

ネットワークとサブネットを作成する手順は次のとおりです。

Console

testing ネットワークと testing-subnet を作成します。

  1. Google Cloud Console で、[VPC ネットワーク] ページに移動します。

    [VPC ネットワーク] に移動

  2. [VPC ネットワークを作成] をクリックします。

  3. [名前] に「testing」を入力します。

  4. [サブネット] セクションで次の設定を行います。

    • [サブネット作成モード] を [カスタム] に設定します。
    • [新しいサブネット] セクションに、次の情報を入力します。
      • 名前: testing-subnet
      • リージョン: us-west1
      • IP アドレス範囲: 10.30.1.0/24
      • [完了] をクリックします。
  5. [作成] をクリックします。

production ネットワークと production-subnet を作成します。

  1. Google Cloud Console で、[VPC ネットワーク] ページに移動します。

    [VPC ネットワーク] に移動

  2. [VPC ネットワークを作成] をクリックします。

  3. [名前] に「production」を入力します。

  4. [サブネット] セクションで次の設定を行います。

    • [サブネット作成モード] を [カスタム] に設定します。
    • [新しいサブネット] セクションに、次の情報を入力します。
      • 名前: production-subnet
      • リージョン: us-west1
      • IP アドレス範囲: 10.50.1.0/24
      • [完了] をクリックします。
  5. [作成] をクリックします。

gcloud

  1. カスタム VPC ネットワークを作成します。

    gcloud compute networks create testing --subnet-mode=custom
    
    gcloud compute networks create production --subnet-mode=custom
    
  2. us-west1 リージョンの testing ネットワークと production ネットワークにサブネットを作成します。

    gcloud compute networks subnets create testing-subnet \
        --network=testing \
        --range=10.30.1.0/24 \
        --region=us-west1
    
    gcloud compute networks subnets create production-subnet \
        --network=production \
        --range=10.50.1.0/24 \
        --region=us-west1
    

ファイアウォール ルールの構成

この例では、次のファイアウォール ルールを使用します。

  • fw-allow-testing-from-both: testing ネットワークのすべてのターゲットに適用される上り(内向き)ルール。このルールは、10.30.1.0/2410.50.1.0/24 両方の IP アドレス範囲にある送信元からのトラフィックを許可します。この 2 つの範囲には、両方のネットワークにある VM のプライマリ内部 IP アドレスが含まれます。

  • fw-allow-production-from-both: production ネットワークのすべてのターゲットに適用される上り(内向き)ルール。このルールは、10.30.1.0/2410.50.1.0/24 両方の IP アドレス範囲にある送信元からのトラフィックを許可します。この 2 つの範囲には、両方のネットワークにある VM のプライマリ内部 IP アドレスが含まれます。

  • fw-allow-testing-ssh: testing VPC ネットワークの VM インスタンスに適用される上り(内向き)ルール。このルールは、任意のアドレスから受信する TCP ポート 22 への SSH 接続を許可します。このルールには、送信元 IP 範囲をより限定して指定できます。たとえば、SSH セッションを開始するシステムの IP 範囲を指定できます。この例では、ファイアウォール ルールを適用する VM の識別に、ターゲットタグ allow-ssh を使用します。

  • fw-allow-production-ssh: production VPC ネットワークの VM インスタンスに適用される上り(内向き)ルール。このルールは、任意のアドレスから受信する TCP ポート 22 への SSH 接続を許可します。fw-allow-testing-ssh ルールのように、送信元の IP 範囲をより限定して指定できます。

  • fw-allow-health-check: 負荷分散されたサードパーティ製アプライアンス VM 用の上り(内向き)ルール。このルールにより、Google Cloud ヘルスチェック システム(130.211.0.0/2235.191.0.0/16)からのトラフィックが許可されます。この例では、ターゲットタグ allow-health-check を使用して、適用するインスタンスを識別します。

  • fw-allow-production-health-check: 負荷分散されたサードパーティ製アプライアンス VM 用の上り(内向き)ルール。このルールにより、Google Cloud ヘルスチェック システム(130.211.0.0/2235.191.0.0/16)からのトラフィックが許可されます。この例では、ターゲットタグ allow-health-check を使用して、適用するインスタンスを識別します。

これらのファイアウォール ルールがない場合は、デフォルトの上り(内向き)拒否ルールによってバックエンド インスタンスへの受信トラフィックがブロックされます。Google Cloud プローブ システムの IP 範囲からのヘルスチェックを許可するには、ファイアウォール ルールを作成する必要があります。詳細については、プローブの IP 範囲をご覧ください。

Console

  1. Google Cloud Console で [ファイアウォール] ページに移動します。

    [ファイアウォール] に移動

  2. [ファイアウォール ルールを作成] をクリックして次の情報を入力し、テスト VM がテスト用サブネットと本番環境サブネットからパケットを受信できるようにします。

    • 名前: fw-allow-testing-from-both
    • ネットワーク: testing
    • 優先度: 1000
    • トラフィックの方向: 上り
    • 一致したときのアクション: 許可
    • ターゲット: ネットワーク内のすべてのインスタンス
    • ソースフィルタ: IP ranges
    • ソース IP の範囲: 10.30.1.0/2410.50.1.0/24
    • プロトコルとポート: すべて許可
  3. [作成] をクリックします。

  4. [ファイアウォール ルールを作成] をクリックして次の情報を入力し、本番環境 VM がテスト用サブネットと本番環境サブネットからパケットを受信できるようにします。

    • 名前: fw-allow-production-from-both
    • ネットワーク: production
    • 優先度: 1000
    • トラフィックの方向: 上り
    • 一致したときのアクション: 許可
    • ターゲット: ネットワーク内のすべてのインスタンス
    • ソースフィルタ: IP ranges
    • ソース IP の範囲: 10.30.1.0/2410.50.1.0/24
    • プロトコルとポート: すべて許可
  5. [作成] をクリックします。

  6. [ファイアウォール ルールを作成] をクリックして、テスト環境で受信する SSH 接続を許可するルールを作成します。

    • 名前: fw-allow-testing-ssh
    • ネットワーク: testing
    • 優先度: 1000
    • トラフィックの方向: 上り
    • 一致したときのアクション: 許可
    • ターゲット: 指定されたターゲットタグ
    • ターゲットタグ: allow-ssh
    • ソースフィルタ: IP ranges
    • 送信元 IP 範囲: 0.0.0.0/0
    • プロトコルとポート: 指定されたプロトコルとポートを選択して、tcp:22 と入力します。
  7. [作成] をクリックします。

  8. [ファイアウォール ルールを作成] をクリックして、本番環境で受信する SSH 接続を許可するルールを作成します。

    • 名前: fw-allow-production-ssh
    • ネットワーク: production
    • 優先度: 1000
    • トラフィックの方向: 上り
    • 一致したときのアクション: 許可
    • ターゲット: 指定されたターゲットタグ
    • ターゲットタグ: allow-ssh
    • ソースフィルタ: IP ranges
    • 送信元 IP 範囲: 0.0.0.0/0
    • プロトコルとポート: 指定されたプロトコルとポートを選択して、tcp:22 と入力します。
  9. [作成] をクリックします。

  10. [ファイアウォール ルールを作成] をクリックして、テスト環境で Google Cloud ヘルスチェックを許可するルールを作成します。

    • 名前: fw-allow-health-check
    • ネットワーク: testing
    • 優先度: 1000
    • トラフィックの方向: 上り
    • 一致したときのアクション: 許可
    • ターゲット: 指定されたターゲットタグ
    • ターゲットタグ: allow-health-check
    • ソースフィルタ: IP ranges
    • 送信元 IP 範囲: 130.211.0.0/2235.191.0.0/16
    • プロトコルとポート: tcp
  11. [作成] をクリックします。

  12. [ファイアウォール ルールを作成] をクリックして、本番環境で Google Cloud ヘルスチェックを許可するルールを作成します。

    • 名前: fw-allow-production-health-check
    • ネットワーク: production
    • 優先度: 1000
    • トラフィックの方向: 上り
    • 一致したときのアクション: 許可
    • ターゲット: 指定されたターゲットタグ
    • ターゲットタグ: allow-health-check
    • ソースフィルタ: IP ranges
    • 送信元 IP 範囲: 130.211.0.0/2235.191.0.0/16
    • プロトコルとポート: tcp
  13. [作成] をクリックします。

gcloud

  1. テスト VM が、testing サブネットと production サブネットからパケットを受信できるように、fw-allow-testing-subnet ファイアウォール ルールを作成します。

    gcloud compute firewall-rules create fw-allow-testing-from-both \
        --network=testing \
        --action=allow \
        --direction=ingress \
        --source-ranges=10.30.1.0/24,10.50.1.0/24 \
        --rules=all
    
  2. 本番環境 VM が、testing サブネットと production サブネットからパケットを受信できるように、fw-allow-production-subnet ファイアウォール ルールを作成します。

    gcloud compute firewall-rules create fw-allow-production-from-both \
        --network=production \
        --action=allow \
        --direction=ingress \
        --source-ranges=10.30.1.0/24,10.50.1.0/24 \
        --rules=all
    
  3. ネットワーク タグ allow-ssh を使用して、VM との SSH 接続を許可する fw-allow-testing-ssh ファイアウォール ルールを作成します。source-ranges を省略すると、Google Cloud は任意の送信元としてルールを解釈します。

    gcloud compute firewall-rules create fw-allow-testing-ssh \
        --network=testing \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-ssh \
        --rules=tcp:22
    
  4. ネットワーク タグ allow-ssh を使用して、VM との SSH 接続を許可する fw-allow-production-ssh ファイアウォール ルールを作成します。

    gcloud compute firewall-rules create fw-allow-production-ssh \
        --network=production \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-ssh \
        --rules=tcp:22
    
  5. fw-allow-health-check ルールを作成して、testing ネットワークのサードパーティ アプライアンス VM に対する Google Cloud ヘルスチェックを許可します。

    gcloud compute firewall-rules create fw-allow-testing-health-check \
        --network=testing \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-health-check \
        --source-ranges=130.211.0.0/22,35.191.0.0/16 \
        --rules=tcp
    
  6. fw-allow-production-health-check ファイアウォール ルールを作成して、production ネットワークのサードパーティ アプライアンス VM に対する Google Cloud ヘルスチェックを許可します。

    gcloud compute firewall-rules create fw-allow-production-health-check \
        --network=production \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-health-check \
        --source-ranges=130.211.0.0/22,35.191.0.0/16 \
        --rules=tcp
    

サードパーティ仮想アプライアンスの作成

ここでは、iptables ソフトウェアをサードパーティの仮想アプライアンスとして使用して、インスタンス テンプレートとマネージド リージョン インスタンス グループを作成する手順を説明します。

Console

複数のネットワーク インターフェースを含むインスタンス テンプレートを作成する必要があるため、このステップでは gcloud を使用します。Cloud Console では、複数のネットワーク インターフェースを含むインスタンス テンプレートを現在作成できません。

gcloud

  1. サードパーティ仮想アプライアンスのインスタンス テンプレートを作成します。インスタンス テンプレートに --can-ip-forward フラグを追加します。これにより、テンプレートから作成された VM インスタンスが testing ネットワークと production ネットワークの他のインスタンスからパケットを転送できるようになります。

    gcloud compute instance-templates create third-party-template-multinic \
        --region=us-west1 \
        --network-interface subnet=testing-subnet,address="" \
        --network-interface subnet=production-subnet \
        --tags=allow-ssh,allow-health-check \
        --image-family=debian-10 \
        --image-project=debian-cloud \
        --can-ip-forward \
        --metadata=startup-script='#! /bin/bash
        # Enable IP forwarding:
        echo 1 > /proc/sys/net/ipv4/ip_forward
        echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-iptables.conf
        # Read VM network configuration:
        md_vm="http://169.254.169.254/computeMetadata/v1/instance/"
        md_net="$md_vm/network-interfaces"
        nic0_gw="$(curl $md_net/0/gateway -H "Metadata-Flavor:Google" )"
        nic0_mask="$(curl $md_net/0/subnetmask -H "Metadata-Flavor:Google")"
        nic0_addr="$(curl $md_net/0/ip -H "Metadata-Flavor:Google")"
        nic0_id="$(ip addr show | grep $nic0_addr | awk '{print $NF}')"
        nic1_gw="$(curl $md_net/1/gateway -H "Metadata-Flavor:Google")"
        nic1_mask="$(curl $md_net/1/subnetmask -H "Metadata-Flavor:Google")"
        nic1_addr="$(curl $md_net/1/ip -H "Metadata-Flavor:Google")"
        nic1_id="$(ip addr show | grep $nic1_addr | awk '{print $NF}')"
        # Source based policy routing for nic1
        echo "100 rt-nic1" >> /etc/iproute2/rt_tables
        ip rule add pri 32000 from $nic1_gw/$nic1_mask table rt-nic1
        sleep 1
        ip route add 35.191.0.0/16 via $nic1_gw dev $nic1_id table rt-nic1
        ip route add 130.211.0.0/22 via $nic1_gw dev $nic1_id table rt-nic1
        # Use a web server to pass the health check for this example.
        # You should use a more complete test in production.
        apt-get update
        apt-get install apache2 -y
        a2ensite default-ssl
        a2enmod ssl
        echo "Example web page to pass health check" | \
        tee /var/www/html/index.html
        systemctl restart apache2'
    
  2. サードパーティ仮想アプライアンスのマネージド インスタンス グループを作成します。このコマンドは、us-west1 内でリージョン マネージド インスタンス グループを作成し、自動的にスケーリングします。

    gcloud compute instance-groups managed create third-party-instance-group \
        --region=us-west1 \
        --template=third-party-template-multinic \
        --size=3
    

負荷分散リソースの作成

この手順では、ヘルスチェックとバックエンド サービス、フロントエンド コンポーネントなどの内部 TCP / UDP ロードバランサ コンポーネントを構成します。

  • ヘルスチェック: この例では、HTTP ヘルスチェックで HTTP 200(OK)レスポンスを確認します。詳細については、内部 TCP / UDP 負荷分散の概要のヘルスチェックのセクションをご覧ください。

  • バックエンド サービス: この例のバックエンド サービスは TCP プロトコルを指定しますが、ロードバランサがルートのネクストホップの場合、Google Cloud はすべてのプロトコル(TCP、UDP、ICMP)のトラフィックを転送します。

  • 転送ルール: TCP ポート 80 が指定されていても、ロードバランサがルートのネクストホップの場合、TCP ポートまたは UDP ポートのトラフィックがロードバランサのバックエンドに送信されます。

  • 内部 IP アドレス: この例では、転送ルールに内部 IP アドレス 10.30.1.99 を指定します。

Console

1 つ目のロードバランサを作成する

  1. Google Cloud Console で、[負荷分散] ページに移動します。

    [負荷分散] に移動

  2. [ロードバランサを作成] をクリックします。

  3. [TCP 負荷分散] で [構成を開始] をクリックします。

  4. [インターネット接続または内部専用] で [VM 間のみ] を選択します。

  5. [続行] をクリックします。

  6. [名前] を ilb1 に設定します。

  7. [バックエンドの構成] をクリックして、次の変更を行います。

    1. リージョン: us-west1
    2. ネットワーク: testing
    3. [バックエンド] の [新しいアイテム] セクションで、「third-party-instance-group」インスタンス グループを選択し、[完了] をクリックします。
    4. [ヘルスチェック] で、[別のヘルスチェックを作成] を選択し、次の情報を入力して [保存して次へ] をクリックします。
      • 名前: hc-http-80
      • プロトコル: HTTP
      • ポート: 80
      • プロキシ プロトコル: NONE
      • リクエストパス: /。Cloud Console を使用してロードバランサを作成すると、ヘルスチェックはグローバルになります。リージョン ヘルスチェックを作成する場合は、gcloud または API を使用します。
    5. 続行する前に、[バックエンドの構成] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
  8. [フロントエンドの構成] をクリックします。[新しいフロントエンドの IP とポート] セクションで、次の変更を行います。

    1. 名前: fr-ilb1
    2. サブネットワーク: testing-subnet
    3. [内部 IP] から、[静的内部 IP アドレスの予約] を選択し、以下の情報を入力して [予約] をクリックします。
      • 名前: ip-ilb
      • 静的 IP アドレス: 選択を許可
      • カスタム IP アドレス: 10.30.1.99
    4. [ポート] で、[単一] を選択して、[ポート番号] に「80」を入力します。ロードバランサに選択したプロトコルとポートにより、ロードバランサがルートのネクストホップの場合に使用されるプロトコルやポートが制限されることはありません。
    5. 続行する前に、[フロントエンドの設定] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
  9. [確認と完了] をクリックします。設定を再度確認します。

  10. [作成] をクリックします。

2 つ目のロードバランサを作成する

  1. Google Cloud Console で、[負荷分散] ページに移動します。

    [負荷分散] に移動

  2. [ロードバランサを作成] をクリックします。

  3. [TCP 負荷分散] で、[構成を開始] をクリックします。

  4. [インターネット接続または内部専用] で、[VM 間のみ] を選択します。

  5. [続行] をクリックします。

  6. [名前] を ilb2 に設定します。

  7. [バックエンドの構成] をクリックして、次の変更を行います。

    1. リージョン: us-west1
    2. ネットワーク: production
    3. [バックエンド] の [新しいアイテム] セクションで、「third-party-instance-group」インスタンス グループを選択し、[完了] をクリックします。
    4. [ヘルスチェック] で、「hc-http-80」を選択します。
    5. 続行する前に、[バックエンドの構成] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
  8. [フロントエンドの構成] をクリックします。[新しいフロントエンドの IP とポート] セクションで、次の変更を行います。

    1. 名前: fr-ilb2
    2. サブネットワーク: testing-subnet
    3. [内部 IP] で、[静的内部 IP アドレスを予約] を選択し、以下の情報を入力して [予約] をクリックします。
      • 名前: ip-ilb2
      • 静的 IP アドレス: 選択を許可
      • カスタム IP アドレス: 10.50.1.99
    4. [ポート] で、[単一] を選択して、[ポート番号] に「80」を入力します。ロードバランサに選択したプロトコルとポートにより、ロードバランサがルートのネクストホップの場合に使用されるプロトコルやポートが制限されることはありません。
    5. 続行する前に、[フロントエンドの設定] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
  9. [確認と完了] をクリックします。設定を再度確認します。

  10. [作成] をクリックします。

  11. production VPC ネットワークにロードバランサのリソースを構成します。

gcloud

  1. 新しい HTTP ヘルスチェックを作成して、ポート 80 で VM との TCP 接続をテストします。

    gcloud compute health-checks create http hc-http-80 \
        --region=us-west1 \
        --port=80
    
  2. us-west1 リージョンに、内部バックエンド サービスを 2 つ作成します。

    gcloud compute backend-services create ilb1 \
        --load-balancing-scheme=internal \
        --health-checks-region=us-west1 \
        --health-checks=hc-http-80 \
        --region=us-west1 \
        --network=testing \
        --session-affinity=CLIENT_IP
    
    gcloud compute backend-services create ilb2 \
        --load-balancing-scheme=internal \
        --health-checks-region=us-west1 \
        --health-checks=hc-http-80 \
        --region=us-west1 \
        --network=production \
        --session-affinity=CLIENT_IP
    
  3. サードパーティの仮想アプライアンスを含むインスタンス グループを、バックエンドとしてバックエンド サービスに追加します。

    gcloud compute backend-services add-backend ilb1 \
        --instance-group=third-party-instance-group \
        --instance-group-region=us-west1 \
        --region=us-west1
    
    gcloud compute backend-services add-backend ilb2 \
        --instance-group=third-party-instance-group \
        --instance-group-region=us-west1 \
        --region=us-west1
    
  4. 内部転送ルールを作成し、バックエンド サービスに接続してロードバランサの構成を完了します。なお、ロードバランサがルートのネクストホップとして使用される場合、ロードバランサのプロトコル(TCP)とポート(80)によって、バックエンド インスタンス(サードパーティの仮想アプライアンス)に転送されるポートとプロトコルが制限されることはありません。

    gcloud compute forwarding-rules create fr-ilb1 \
        --load-balancing-scheme=internal \
        --ports=80 \
        --network=testing \
        --subnet=testing-subnet \
        --region=us-west1 \
        --backend-service=ilb1 \
        --address=10.30.1.99
    
    gcloud compute forwarding-rules create fr-ilb2 \
        --load-balancing-scheme=internal \
        --ports=80 \
        --network=production \
        --subnet=production-subnet \
        --region=us-west1 \
        --backend-service=ilb2 \
        --address=10.50.1.99
    

ロードバランサをネクストホップとして定義する静的ルートの作成

next-hop-ilb で示されるカスタム静的ルートを 2 つ作成します。

Console

第 1 のルートを作成する

  1. Google Cloud Console で、[ルート] ページに移動します。

    [ルート] に移動

  2. [ルートを作成] をクリックします。

  3. ルートの [名前] に「ilb-nhop-dest-10-50-1」と入力します。

  4. testing ネットワークを選択します。

  5. [宛先 IP の範囲] に「10.50.1.0/24」と入力します。

  6. (省略可)ネットワーク タグを 1 つ以上指定します。ルートにネットワーク タグを指定すると、特定の VM にルートを適用できます。ネットワーク タグを指定しない場合、VPC ネットワーク内のすべての VM にルートが適用されます。この例では、ルートのネットワーク タグとして my-network-tag を使用しています。

  7. ルートの [ネクストホップ] で、[内部 TCP / UDP ロードバランサの転送ルールを指定する] を選択します。

  8. ネクストホップ リージョンに us-west1 を選択します。

  9. 転送ルールの名前または IP アドレスを指定します。転送ルール名に fr-ilb1 を選択します。IP アドレスとして、「10.30.1.99」と入力します。IP アドレスを指定すると、カスタムルートをエクスポートしなくても、この IP アドレスをピア間で学習できます。

  10. [作成] をクリックします。

第 2 のルートを作成する

  1. [ルートを作成] をクリックします。
  2. ルートの [名前] に「ilb-nhop-dest-10-30-1」と入力します。
  3. testing ネットワークを選択します。
  4. [宛先 IP の範囲] に「10.30.1.0/24」と入力します。
  5. ルートの [ネクストホップ] で、[内部 TCP / UDP ロードバランサの転送ルールを指定する] を選択します。
  6. ネクストホップ リージョンに us-west1 を選択します。
  7. 転送ルール名に fr-ilb2 を選択します。
  8. [作成] をクリックします。

gcloud

ネクストホップに各ロードバランサの転送ルールを設定し、それに応じて各宛先範囲を設定した詳細ルートを作成します。

gcloud compute routes create ilb-nhop-dest-10-50-1 \
    --network=testing \
    --destination-range=10.50.1.0/24 \
    --next-hop-ilb=10.30.1.99 \
    --next-hop-ilb-region=us-west1 \
    --tags=my-network-tag
gcloud compute routes create ilb-nhop-dest-10-30-1 \
    --network=production \
    --destination-range=10.30.1.0/24 \
    --next-hop-ilb=fr-ilb2 \
    --next-hop-ilb-region=us-west1

testing VM インスタンスの作成

この例では、IP アドレスが 10.30.1.100 の VM インスタンスを testing VPC ネットワークの testing-subnet10.30.1.0/24)に作成します。

gcloud

  1. 次のコマンドを実行して testing-vm を作成します。

    gcloud compute instances create testing-vm \
        --zone=us-west1-a \
        --image-family=debian-10 \
        --image-project=debian-cloud \
        --tags=allow-ssh \
        --subnet=testing-subnet \
        --private-network-ip 10.30.1.100 \
        --metadata=startup-script='#! /bin/bash
        apt-get update
        apt-get install apache2 -y
        a2ensite default-ssl
        a2enmod ssl
        vm_hostname="$(curl -H "Metadata-Flavor:Google" \
        http://169.254.169.254/computeMetadata/v1/instance/name)"
        echo "Page served from: $vm_hostname" | \
        tee /var/www/html/index.html
        systemctl restart apache2'
    

production VM インスタンスの作成

この例では、IP アドレスが 10.50.1.100 の VM インスタンスを production VPC ネットワークの production-subnet10.50.1.0/24)に作成します。

gcloud

production-vm はロードバランサと同じリージョン内の任意のゾーンにあり、そのリージョン内の任意のサブネットを使用できます。この例では、production-vmus-west1-a ゾーンにあります。

  1. 次のコマンドを実行して production-vm を作成します。

    gcloud compute instances create production-vm \
        --zone=us-west1-a \
        --image-family=debian-10 \
        --image-project=debian-cloud \
        --tags=allow-ssh \
        --subnet=production-subnet \
        --private-network-ip 10.50.1.100 \
        --metadata=startup-script='#! /bin/bash
        apt-get update
        apt-get install apache2 -y
        a2ensite default-ssl
        a2enmod ssl
        vm_hostname="$(curl -H "Metadata-Flavor:Google" \
        http://169.254.169.254/computeMetadata/v1/instance/name)"
        echo "Page served from: $vm_hostname" | \
        tee /var/www/html/index.html
        systemctl restart apache2'
    

マルチ NIC デプロイに対する負荷分散のテスト

  1. ロードバランサのバックエンドの正常性を確認します。

    gcloud compute backend-services get-health ilb1 --region us-west1
    
    gcloud compute backend-services get-health ilb2 --region us-west1
    
  2. testing VM からの接続をテストします。

    gcloud compute ssh testing-vm --zone=us-west1-a
    
    curl http://10.50.1.100
    
    exit
    
  3. production VM からの接続をテストします。

    gcloud compute ssh production-vm --zone=us-west1-a
    
    curl http://10.30.1.100
    

対称ハッシュの有効化

バックエンド インスタンスにマッピングされたハッシュを計算する場合、Google Cloud では IP アドレスとポートの方向が無視されます。TCP / UDP パケットの算出された一貫性のあるハッシュ値は、パケットの発信方向に関係なく同じになります。これは、対称ハッシュと呼ばれます。

既存の内部 TCP / UDP ロードバランサでこのハッシュ動作を有効にするには、転送ルールとネクストホップ ルートを再作成する必要があります。

詳細については、対称ハッシュをご覧ください。

転送ルールを削除して再作成する

Console

転送ルールを削除して新しいルールを作成する

  1. Google Cloud Console で、[負荷分散] ページに移動します。

    [負荷分散] に移動

  2. be-ilb ロードバランサをクリックして、[編集] をクリックします。

  3. [フロントエンドの構成] をクリックします。

  4. ポインタを転送ルールの上に置き、 [削除] をクリックして削除します。

  5. [フロントエンド IP とポートの追加] をクリックします。

  6. [新しいフロントエンドの IP とポート] セクションで、次の変更を行います。

    1. 名前: FORWARDING_RULE_NAME
    2. サブネットワーク: SUBNET_NAME
    3. [内部 IP] で [IP_ADDRESS] を選択します。
    4. ポート: PORT_NUMBER または ALL
    5. [完了] をクリックします。
    6. 続行する前に、[フロントエンドの設定] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
  7. [確認と完了] をクリックします。設定を再度確認します。

  8. [作成] をクリックします。

gcloud

  1. 既存の転送ルールを削除します。

    gcloud compute forwarding-rules delete FORWARDING_RULE_NAME \
        --region=REGION
    
  2. 同じ名前で代わりの転送ルールを作成します。

    gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
        --load-balancing-scheme=internal \
        --ports=PORT_NUMBER or `ALL` \
        --network=NETWORK_NAME \
        --subnet=SUBNET_NAME \
        --region=REGION \
        --backend-service=BACKEND_SERVICE_NAME \
        --address=IP_ADDRESS
    

SNAT が不要な場合

前の例で示したように、次のすべてに当てはまる場合、ソース ネットワーク アドレス変換(SNAT)は必要ありません。

  • 内部 TCP / UDP ロードバランサの転送ルールは、2021 年 6 月 22 日以降に作成された。
  • 転送ルールを参照するカスタム静的ルートは、2021 年 6 月 22 日以降に作成された。
  • 内部 TCP / UDP ロードバランサのバックエンド サービスは、NONE のセッション アフィニティ設定を使用しない。

既存のネクストホップの内部 TCP / UDP ロードバランサ ルートは、次の手順に沿って操作することで、対称ハッシュを使用するように変換できます。

  • 内部 TCP / UDP ロードバランサのバックエンド サービスが、NONE のセッション アフィニティ設定を使用しないようにします。

  • 同じバックエンド サービスを参照する、代わりの転送ルールを作成します。代わりの転送ルールでは、別の IP アドレスを使用します。

  • 新しい転送ルールを参照する代わりのカスタム静的ルートを作成します。この代わりのルートには、既存のルートよりも高い優先度を設定します。

  • (以前の転送ルールを参照する)優先度の低い既存のルートを削除してから、以前の転送ルールを削除します。

クリーンアップ

  1. ロードバランサの構成で、バックエンド サービスからバックエンドを削除します。

    gcloud compute backend-services remove-backend ilb1 \
        --instance-group=third-party-instance-group \
        --instance-group-region=us-west1 \
        --region=us-west1
    
    gcloud compute backend-services remove-backend ilb2 \
        --instance-group=third-party-instance-group \
        --instance-group-region=us-west1 \
        --region=us-west1
    
  2. ルーティング経路を削除します。

    gcloud compute routes delete ilb-nhop-dest-10-50-1
    
    gcloud compute routes delete ilb-nhop-dest-10-30-1
    
  3. ロードバランサの構成で、転送ルールを削除します。

    gcloud compute forwarding-rules delete fr-ilb1 \
        --region=us-west1
    
    gcloud compute forwarding-rules delete fr-ilb2 \
        --region=us-west1
    
  4. ロードバランサの構成で、バックエンド サービスを削除します。

    gcloud compute backend-services delete ilb1 \
        --region=us-west1
    
    gcloud compute backend-services delete ilb2 \
        --region=us-west1
    
  5. ロードバランサの構成で、ヘルスチェックを削除します。

    gcloud compute health-checks delete hc-http-80 \
        --region=us-west1
    

    Cloud Console を使用した場合、ヘルスチェックはグローバルになります。そのため、コマンドは次のようになります。

    gcloud compute health-checks delete hc-http-80 \
         --global
    
  6. マネージド インスタンス グループを削除します。

    gcloud compute instance-groups managed delete third-party-instance-group \
        --region=us-west1
    
  7. インスタンス テンプレートを削除します。

    gcloud compute instance-templates delete third-party-template
    
    gcloud compute instance-templates delete third-party-template-multinic
    
  8. テスト インスタンスと本番環境インスタンスを削除します。

    gcloud compute instances delete testing-vm \
        --zone=us-west1-a
    
    gcloud compute instances delete production-vm \
        --zone=us-west1-a
    

次のステップ