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

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

権限

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

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

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

シングル バックエンド NIC への負荷分散

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

このガイドで説明するソリューションには仮想アプライアンスが統合されています。仮想アプライアンスにトラフィックを送信するために、クライアントを明示的に再構成する必要はありません。この設定ガイドの例では、負荷分散された一連のファイアウォール仮想アプライアンスを介してすべてのトラフィックを送信します。

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

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

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

内部 TCP / UDP 負荷分散のネクストホップ シングル NIC の例(クリックして拡大)
内部 TCP / UDP 負荷分散のネクストホップ シングル NIC の例(クリックして拡大)

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

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

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

  • testing VPC ネットワークには、宛先が 10.50.1.0/24 サブネットのカスタム静的ルートが設定されています。これにより、トラフィックがロードバランサに転送されます。
  • 設定されたセッション アフィニティに基づいて、ロードバランサがいずれかのアプリケーション インスタンスにトラフィックを転送します(セッション アフィニティは TCP トラフィックにのみに適用されます)。
  • production VPC ネットワークのインスタンス グループにパケットを配信するため、アプリケーション インスタンスがソース ネットワーク アドレス変換(SNAT)を実行します。戻りトラフィックに対しては、testing VPC ネットワークのクライアント インスタンスにパケットを配信するため、宛先ネットワーク アドレス変換(DNAT)を実行します。

他のユースケースについては、ネクストホップとしての内部 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-subnet: testing ネットワークのすべてのターゲットに適用される上り(内向き)ルールで、10.30.1.0/24 の範囲の送信元からのトラフィックを許可します。このルールにより、testing-subnet の VM インスタンスとサードパーティ VM アプライアンスの通信が可能になります。

  • fw-allow-production-subnet: production ネットワークのすべてのターゲットに適用される上り(内向き)ルールで、10.50.1.0/24 の範囲の送信元からのトラフィックを許可します。このルールにより、production-subnet の VM インスタンスとサードパーティ VM アプライアンスの通信が可能になります。

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

  • 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 を使用して、適用するインスタンスが識別されます。

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

Console

  1. Google Cloud Console の [ファイアウォール] ページに移動します。
    [ファイアウォール] ページに移動
  2. [ファイアウォール ルールを作成] をクリックして次の情報を入力し、サブネット トラフィックを許可するルールを作成します。
    • 名前: fw-allow-testing-subnet
    • ネットワーク: testing
    • 優先度: 1000
    • トラフィックの方向: 上り
    • 一致したときのアクション: 許可
    • ターゲット: ネットワーク内のすべてのインスタンス
    • ソースフィルタ: IP ranges
    • ソース IP の範囲: 10.30.1.0/24
    • プロトコルとポート: すべて許可
  3. [作成] をクリック
  4. [ファイアウォール ルールを作成] をクリックして次の情報を入力し、サブネット トラフィックを許可するルールを作成します。
    • 名前: fw-allow-production-subnet
    • ネットワーク: production
    • 優先度: 1000
    • トラフィックの方向: 上り
    • 一致したときのアクション: 許可
    • ターゲット: ネットワーク内のすべてのインスタンス
    • ソースフィルタ: IP ranges
    • ソース IP の範囲: 10.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
    • プロトコルとポート: すべて許可
  11. [作成] をクリックします。

gcloud

  1. fw-allow-testing-subnet ファイアウォール ルールを作成して、サブネットとの通信を許可します。

    gcloud compute firewall-rules create fw-allow-testing-subnet \
        --network=testing \
        --action=allow \
        --direction=ingress \
        --source-ranges=10.30.1.0/24 \
        --rules=tcp,udp,icmp
    
  2. fw-allow-production-subnet ファイアウォール ルールを作成して、サブネットとの通信を許可します。

    gcloud compute firewall-rules create fw-allow-production-subnet \
        --network=production \
        --action=allow \
        --direction=ingress \
        --source-ranges=10.50.1.0/24 \
        --rules=tcp,udp,icmp
    
  3. fw-allow-testing-ssh ファイアウォール ルールを作成し、ネットワーク タグ allow-ssh を持つ VM への 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. fw-allow-production-ssh ファイアウォール ルールを作成し、ネットワーク タグ allow-ssh を持つ VM への 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,udp,icmp
    

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

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

Console

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

gcloud

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

    gcloud compute instance-templates create third-party-template \
        --region=us-west1 \
        --network-interface subnet=testing-subnet,address="" \
        --network-interface subnet=production-subnet \
        --tags=allow-ssh,allow-health-check \
        --image-family=debian-9 \
        --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 -H "Metadata-Flavor:Google" $md_net/0/gateway)"
        nic0_mask="$(curl -H "Metadata-Flavor:Google" $md_net/0/subnetmask)"
        nic1_gw="$(curl -H "Metadata-Flavor:Google" $md_net/1/gateway)"
        nic1_mask="$(curl -H "Metadata-Flavor:Google" $md_net/1/subnetmask)"
        nic1_addr="$(curl -H "Metadata-Flavor:Google" $md_net/1/ip)"
        # Start iptables:
        /sbin/iptables -t nat -F
        /sbin/iptables -t nat -A POSTROUTING \
        -s "$nic0_gw/$nic0_mask" \
        -d "$nic1_gw/$nic1_mask" \
        -o eth1 \
        -j SNAT \
        --to-source "$nic1_addr"
        /sbin/iptables-save
        # 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 \
        --size=3
    

負荷分散リソースの作成

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

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

  • バックエンド サービス: この例のバックエンド サービスは TCP プロトコルを指定しますが、ロードバランサがルートのネクストホップの場合、TCP トラフィックと UDP トラフィックの両方がロードバランサのバックエンドに送信されます。

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

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

Console

ロードバランサの作成とバックエンド サービスの構成

  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. [作成] をクリックします。

gcloud

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

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

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

    gcloud compute backend-services add-backend ilb1 \
        --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
    

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

静的ルートを作成する場合、next-hop-address を使用してロードバランサの転送ルールの IP アドレスを参照することはできません。next-hop-address を使用すると、Google Cloud はその IP アドレスに割り当てられた VM インスタンスにトラフィックを転送しますが、ロードバランサは VM インスタンスではないからです。ロードバランサをネクストホップとして指定する場合は、この例で示すように next-hop-ilb フラグを使用する必要があります。

Console

  1. Google Cloud Console の [ルート] ページに移動します。
    [ルート] ページに移動
  2. [ルートを作成] をクリックします。
  3. ルートの名前として「ilb-nhop-dest-10-50-1」と入力します。
  4. testing ネットワークを選択します。
  5. [宛先 IP の範囲] に 10.50.1.0/24 と入力します。
  6. この機能ではタグはサポートされていません。タグは指定しないでください。
  7. ルートのネクストホップで、[内部 TCP/UDP ロードバランサの転送ルールを指定する] を選択します。
  8. ネクストホップ リージョンに us-west1 を選択します。
  9. 転送ルール名に fr-ilb1 を選択します。
  10. [作成] をクリックします。

gcloud

ネストホップにロードバランサの転送ルールを設定し、宛先範囲をルート 10.50.1.0/24 に設定して、高度なルートを作成します。

gcloud compute routes create ilb-nhop-dest-10-50-1 \
    --network=testing \
    --destination-range=10.50.1.0/24 \
    --next-hop-ilb=fr-ilb1 \
    --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-9 \
        --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-9 \
        --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 デプロイに対する負荷分散のテスト

このテストでは、testing VPC ネットワークのクライアント VM から production VPC ネットワークのサンプル VM に接続します。ロードバランサは、ロードバランサの IP アドレスに送信するのではなく、ロードバランサ経由でパケットを宛先 10.50.1.100 に送信するため、ネクストホップとしても使用されます。

この例では、ロードバランサの正常なバックエンド アプライアンス VM の iptables ソフトウェアがパケットの NAT を処理します。

  1. クライアント VM インスタンスに接続します。

    gcloud compute ssh testing-vm --zone=us-west1-a
    
  2. curl を使用して、宛先インスタンスのウェブサーバー ソフトウェアにウェブ リクエストを送信します。予想される出力は、宛先インスタンスのインデックス ページの内容です(Page served from: destination-instance)。

    curl http://10.50.1.100
    

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

複数の NIC への負荷分散に説明されているように、負荷分散は複数のバックエンド NIC に展開できます。

内部 TCP / UDP 負荷分散のネクストホップ マルチ NIC の詳細例(クリックして拡大)
内部 TCP / UDP 負荷分散のネクストホップ マルチ NIC の詳細例(クリックして拡大)
  1. 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,udp,icmp
    
  2. 新しいインスタンス テンプレートを作成します。

    この設定でヘルスチェックをシームレスに動作させるには、ヘルスチェックの下り(外向き)レスポンス パケットが正しいインターフェースを通るように、ポリシーベースのルーティングを構成する必要があります。ヘルスチェックでは、外部 IP アドレスをヘルスチェック プローブのソースとして使用します。ゲスト OS は、宛先 IP アドレスに基づいて送信 NIC を選択します。宛先 IP アドレスがサブネットの範囲内にない場合、送信 NIC はデフォルトで nic0 になります。このような場合は、ポリシーベースのルーティングを使用して、ネットワーク インターフェースごとに個別のルーティング テーブルを構成する必要があります。

    ソースベースのポリシー ルーティングは、Windows や macOS ではサポートされていません。

    バックエンド VM テンプレートで、次のポリシー ルーティングを追加します。ここで、10.50.1.0/24 はロードバランサとマルチ NIC VM の eth1 が使用するサブネットです。デフォルト ゲートウェイは 10.50.1.1 です

    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-9 \
        --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")"
        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")"
        # 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 eth1 table rt-nic1
        ip route add 130.211.0.0/22 via $nic1_gw dev eth1 table rt-nic1
        # Start iptables:
        iptables -t nat -F
        iptables -t nat -A POSTROUTING \
        -s $nic0_gw/$nic0_mask \
        -d $nic1_gw/$nic1_mask \
        -o eth1 \
        -j SNAT \
        --to-source $nic1_addr
        iptables -t nat -A POSTROUTING \
        -s $nic1_gw/$nic1_mask \
        -d $nic0_gw/$nic0_mask \
        -o eth0 \
        -j SNAT \
        --to-source $nic0_addr
        iptables-save
        # 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'
    
  3. インスタンス グループを更新します。

    gcloud compute instance-groups managed set-instance-template \
        third-party-instance-group \
        --region us-west1 \
        --template=third-party-template-multinic
    
  4. 新しい third-party-template-multinic テンプレートを使用して、マネージド インスタンス グループを再作成します。

    gcloud compute instance-groups managed rolling-action replace \
        third-party-instance-group \
        --region us-west1
    

    インスタンスが準備されるまで数分間待ちます。進捗状況を確認するには、list-instances コマンドを実行します。

    gcloud compute instance-groups managed list-instances \
        third-party-instance-group \
        --region us-west1
    

    出力は次のようになります。

    NAME                             ZONE        STATUS   ACTION  INSTANCE_TEMPLATE              VERSION_NAME                        LAST_ERROR
    third-party-instance-group-5768  us-west1-a  RUNNING  NONE    third-party-template-multinic  0/2019-10-24 18:48:48.018273+00:00
    third-party-instance-group-4zf4  us-west1-b  RUNNING  NONE    third-party-template-multinic  0/2019-10-24 18:48:48.018273+00:00
    third-party-instance-group-f6lm  us-west1-c  RUNNING  NONE    third-party-template-multinic  0/2019-10-24 18:48:48.018273+00:00
    
  5. production VPC ネットワークにロードバランサのリソースを構成します。

    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
    
    gcloud compute backend-services add-backend ilb2 \
        --instance-group=third-party-instance-group \
        --instance-group-region=us-west1 \
        --region=us-west1
    
    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
    
    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
    

マルチ 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
    

クリーンアップ

  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
    

次のステップ