内部 TCP / UDP 負荷分散のフェイルオーバーの構成

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

権限

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

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

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

設定

このガイドでは、フェイルオーバーを使用する内部 TCP/UDP ロードバランサの構成とテストの方法を示します。このセクションでは、以下の構成方法について説明します。

  1. カスタム サブネットを持つ VPC ネットワークのサンプル
  2. バックエンド VM への受信接続を許可するファイアウォール ルール
  3. バックエンド VM:
    • ゾーン us-west1-a 内の非マネージド インスタンス グループ内の 1 つのプライマリ バックエンド
    • ゾーン us-west1-c 内の非マネージド インスタンス グループ内の 1 つのフェイルオーバー バックエンド
  4. 接続をテストし、フェイルオーバーの動作を監視する 1 つのクライアント VM
  5. 次の内部 TCP / UDP ロードバランサ コンポーネント:
    • バックエンド サービスのヘルスチェック
    • バックエンド VM 間の接続分散を管理する us-west1 リージョン内の内部バックエンド サービス
    • ロードバランサのフロントエンドの内部転送ルールと内部 IP アドレス

この例のアーキテクチャは次のようになります。

内部 TCP / UDP 負荷分散のフェイルオーバーのシンプルな例(クリックして拡大)
内部 TCP / UDP 負荷分散のフェイルオーバーのシンプルな例(クリックして拡大)

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

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

  • ネットワーク: ネットワークは、lb-network という名前のカスタムモードの VPC ネットワークです。

  • リージョン: リージョンは、us-west1 です。

  • サブネット: サブネット lb-subnet は、10.1.2.0/24 の IP 範囲です。

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

Console

  1. Google Cloud Console で [VPC ネットワーク] ページに移動します。
    [VPC ネットワーク] ページに移動
  2. [VPC ネットワークを作成] をクリックします。
  3. [名前] に「lb-network」を入力します。
  4. [サブネット] セクションで次の設定を行います。
    • [サブネット作成モード] を [カスタム] に設定します。
    • [新しいサブネット] セクションに、次の情報を入力します。
      • 名前: lb-subnet
      • リージョン: us-west1
      • IP アドレス範囲: 10.1.2.0/24
      • [完了] をクリックします。
  5. [作成] をクリックします。

gcloud

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

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

    gcloud compute networks subnets create lb-subnet \
        --network=lb-network \
        --range=10.1.2.0/24 \
        --region=us-west1
    

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

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

  • fw-allow-lb-subnet: VPC ネットワーク内のすべてのターゲットに適用される上り(内向き)ルールで、10.1.2.0/24 の範囲の送信元からのトラフィックを許可します。このルールを使用すると、lb-subnet 内の送信元から負荷分散されているインスタンス(VM)への受信トラフィックが許可されます。

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

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

これらのファイアウォール ルールがない場合は、デフォルトの内向き拒否ルールによってバックエンド インスタンスへの受信トラフィックがブロックされます。

Console

  1. Google Cloud Console の [ファイアウォール] ページに移動します。
    [ファイアウォール] ページに移動
  2. [ファイアウォール ルールを作成] をクリックして次の情報を入力し、サブネット トラフィックを許可するルールを作成します。
    • 名前: fw-allow-lb-subnet
    • ネットワーク: lb-network
    • 優先度: 1000
    • トラフィックの方向: 上り
    • 一致したときのアクション: 許可
    • ターゲット: ネットワーク内のすべてのインスタンス
    • ソースフィルタ: IP ranges
    • ソース IP の範囲: 10.1.2.0/24
    • プロトコルとポート: すべて許可
  3. [作成] をクリックします。
  4. [ファイアウォール ルールを作成] を再度クリックして、SSH 接続の受信を許可するルールを作成します。
    • 名前: fw-allow-ssh
    • ネットワーク: lb-network
    • 優先度: 1000
    • トラフィックの方向: 上り
    • 一致したときのアクション: 許可
    • ターゲット: 指定されたターゲットタグ
    • ターゲットタグ: allow-ssh
    • ソースフィルタ: IP ranges
    • ソース IP の範囲: 0.0.0.0/0
    • プロトコルとポート: [指定されたプロトコルとポート] を選択してから、次のように入力します。 tcp:22
  5. [作成] をクリックします。
  6. [ファイアウォール ルールを作成] をもう一度クリックして、Google Cloud ヘルスチェックを許可するルールを作成します。
    • 名前: fw-allow-health-check
    • ネットワーク: lb-network
    • 優先度: 1000
    • トラフィックの方向: 上り
    • 一致したときのアクション: 許可
    • ターゲット: 指定されたターゲットタグ
    • ターゲットタグ: allow-health-check
    • ソースフィルタ: IP ranges
    • 送信元 IP 範囲: 130.211.0.0/2235.191.0.0/16
    • プロトコルとポート: すべて許可
  7. [作成] をクリックします。

gcloud

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

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

    gcloud compute firewall-rules create fw-allow-ssh \
        --network=lb-network \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-ssh \
        --rules=tcp:22
    
  3. Google Cloud ヘルスチェックを許可する fw-allow-health-check ルールを作成します。

    gcloud compute firewall-rules create fw-allow-health-check \
        --network=lb-network \
        --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
    

バックエンド VM とインスタンス グループの作成

この手順では、バックエンド VM と非マネージド インスタンス グループを作成します。

  • us-west1-a のインスタンス グループ ig-a は、2 つの VM を持つプライマリ バックエンドです。
    • vm-a1
    • vm-a2
  • us-west1-c のインスタンス グループ ig-c は、2 つの VM を持つフェイルオーバー バックエンドです。
    • vm-c1
    • vm-c2

プライマリ バックエンドとフェイルオーバー バックエンドは異なるゾーンに配置されることにより手順がわかりやすくなります。これにより、1 つのゾーンがダウンした際のフェイルオーバーが処理されます。

各プライマリ VM とバックアップ VM は、TCP ポート 80 と 443 で Apache ウェブサーバーを実行するように構成されています。lb-subnet 内の各 VM にはクライアント アクセス用に内部 IP アドレスが割り当てられ、SSH アクセス用にエフェメラル外部(公開)IP アドレスが割り当てられます。外部 IP アドレスの削除については、バックエンド VM から外部 IP アドレスを削除するをご覧ください。

デフォルトでは、Apache は任意の IP アドレスにバインドされます。内部 TCP / UDP ロードバランサは、宛先 IP を保持してパケットを配信します。

プライマリ VM とバックアップ VM で実行されているサーバー ソフトウェアによって、ロードバランサの内部転送ルールの IP アドレスがリッスンされるようにしてください。複数の内部転送ルールを設定している場合、ソフトウェアによってそれぞれに関連付けられた内部 IP アドレスがリッスンされます。内部 TCP / UDP ロードバランサによってバックエンド VM に配信されるパケットの宛先 IP アドレスは、転送ルールの内部 IP アドレスです。

手順を簡単にするため、すべてのプライマリ VM とバックアップ VM では Debian GNU / Linux 9 が実行されます。

Console

バックエンド VM の作成

  1. Google Cloud Console の [VM インスタンス] ページに移動します。
    [VM インスタンス] ページに移動
  2. 次の手順を繰り返し、4 つの VM を作成します。次のような名前とゾーンの組み合わせを使用します。
    • 名前: vm-a1、ゾーン: us-west1-a
    • 名前: vm-a2、ゾーン: us-west1-a
    • 名前: vm-c1、ゾーン: us-west1-c
    • 名前: vm-c2、ゾーン: us-west1-c
  3. [インスタンスを作成] をクリックします。
  4. ステップ 2 に示したように [名前] を設定します。
  5. [リージョン] には、us-west1 を選択し、手順 2 に示したゾーンを選択します。
  6. [ブートディスク] セクションで、選択したイメージが Debian GNU/Linux 9 Stretch であることを確認します。必要に応じてイメージを変更するには、[選択] をクリックします。
  7. [管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックして、次のように変更します。

    • [ネットワーク] をクリックして、ネットワーク タグ allow-sshallow-health-check を追加します。
    • [ネットワーク インターフェース] にある編集ボタンをクリックして、次の変更を行い、[完了] をクリックします。
      • ネットワーク: lb-network
      • サブネット: lb-subnet
      • プライマリ内部 IP: エフェメラル(自動)
      • 外部 IP: エフェメラル
    • [管理] をクリックします。[起動スクリプト] フィールドに、次のスクリプトの内容をコピーして貼り付けます。スクリプトの内容は 4 つの VM ですべて同じです。

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

インスタンス·グループの作成

  1. Google Cloud Console の [インスタンス グループ] ページに移動します。
    [インスタンス グループ] ページに移動
  2. 次の手順を繰り返し、それぞれが 2 つの VM を持つ 2 つの非マネージド インスタンス グループを作成します。以下のような組み合わせを使用します。
    • インスタンス グループ: ig-a、ゾーン: us-west1-a、VM: vm-a1vm-a2
    • インスタンス グループ: ig-c、ゾーン: us-west1-c、VM: vm-c1vm-c2
  3. [インスタンス グループを作成] をクリックします。
  4. [新しい非マネージド インスタンス グループ] をクリックします。
  5. ステップ 2 に示したように [名前] を設定します。
  6. [ロケーション] セクションで、[リージョン] に us-west1 を選択し、ステップ 2 で示したように [ゾーン] を選択します。
  7. [ネットワーク] に「lb-network」と入力します。
  8. [サブネットワーク] に「lb-subnet」と入力します。
  9. [VM インスタンス] セクションに、ステップ 2 で示した VM を追加します。
  10. [作成] をクリックします。

gcloud

  1. [VM-NAME][ZONE] の 4 つの組み合わせを使用して、次のコマンドを 4 回実行して 4 つの VM を作成します。スクリプトの内容は 4 つの VM ですべて同じです。

    • vm-a1[VM-NAME]us-west1-a[ZONE]
    • vm-a2[VM-NAME]us-west1-a[ZONE]
    • vm-c1[VM-NAME]us-west1-c[ZONE]
    • vm-c2[VM-NAME]us-west1-c[ZONE]
    gcloud compute instances create [VM-NAME] \
        --zone=[ZONE] \
        --image-family=debian-9 \
        --image-project=debian-cloud \
        --tags=allow-ssh,allow-health-check \
        --subnet=lb-subnet \
        --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'
    
  2. 各ゾーンに次の 2 つの非マネージド インスタンス グループを作成します。

    gcloud compute instance-groups unmanaged create ig-a \
        --zone=us-west1-a
    gcloud compute instance-groups unmanaged create ig-c \
        --zone=us-west1-c
    
  3. 適切なインスタンス グループに VM を追加します。

    gcloud compute instance-groups unmanaged add-instances ig-a \
        --zone=us-west1-a \
        --instances=vm-a1,vm-a2
    gcloud compute instance-groups unmanaged add-instances ig-c \
        --zone=us-west1-c \
        --instances=vm-c1,vm-c2
    

クライアント VM の作成

この例では、ロードバランサと同じリージョンにクライアント VM を作成しています(vm-client)。クライアントは、フェイルオーバーの仕組みを示すために使用されます。

Console

  1. Google Cloud Console の [VM インスタンス] ページに移動します。
    [VM インスタンス] ページに移動
  2. [インスタンスを作成] をクリックします。
  3. [名前] を vm-client に設定します。
  4. [ゾーン] を us-west1-a に設定します。
  5. [管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックして、次のように変更します。
    • [ネットワーキング] をクリックして allow-sshネットワーク タグに追加します。
    • [ネットワーク インターフェース] にある編集ボタンをクリックして、次の変更を行い、[完了] をクリックします。
      • ネットワーク: lb-network
      • サブネット: lb-subnet
      • プライマリ内部 IP: エフェメラル(自動)
      • 外部 IP: エフェメラル
  6. [作成] をクリックします。

gcloud

クライアント VM はロードバランサと同じリージョン内の任意のゾーンにあり、そのリージョン内の任意のサブネットを使用できます。この例では、クライアントは us-west1-a ゾーンにあり、プライマリ VM とバックアップ VM が使用するサブネットと同じサブネットを使用します。

gcloud compute instances create vm-client \
    --zone=us-west1-a \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --tags=allow-ssh \
    --subnet=lb-subnet

ロードバランサのコンポーネントを構成する

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

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

  • バックエンド サービス: サンプルでは、HTTP トラフィックが内部ロードバランサに渡されるため、この構成では UDP ではなく TCP を指定します。フェイルオーバーの状態を示すバックエンド サービスのフェイルオーバー率の値は 0.75 です。

  • 転送ルール: この例では、内部転送ルールを 1 つ作成します。

  • 内部 IP アドレス: この例では、転送ルールを作成する際に内部 IP アドレス(10.1.2.99)を指定しています。

Console

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

  1. Google Cloud Console の [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. [ロードバランサを作成] をクリックします。
  3. [TCP 負荷分散] で [設定を開始] をクリックします。
  4. [インターネット接続または内部専用] で [VM 間のみ] を選択します。
  5. [続行] をクリックします。
  6. [名前] を be-ilb に設定します。
  7. [バックエンドの設定] をクリックして、次の変更を行います。
    1. リージョン: us-west1
    2. ネットワーク: lb-network
    3. [バックエンド] の [新しいアイテム] セクションで ig-a インスタンス グループを選択します。[このインスタンス グループをバックアップ用のフェイルオーバー グループとして使用する] を必ずオフにしてください。[完了] をクリックします。
    4. [バックエンドを追加] をクリックします。[新しいアイテム] セクションが表示されたら、ig-c インスタンス グループを選択します。[このインスタンス グループをバックアップ用のフェイルオーバー グループとして使用する] をオンにします。[完了] をクリックします。
    5. [ヘルスチェック] で [別のヘルスチェックを作成] を選択し、次の情報を入力して [保存して次へ] をクリックします。
      • 名前: hc-http-80
      • プロトコル: HTTP
      • ポート: 80
      • プロキシ プロトコル: NONE
      • リクエストパス: /
    6. [詳細構成] をクリックします。[フェイルオーバー ポリシー] セクションで、次のように設定します。
      • フェイルオーバー率: 0.75
      • [フェイルオーバー時のコネクション ドレインを有効にする] をオンにします。
    7. 続行する前に、[バックエンドの設定] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
  8. [フロントエンドの設定] をクリックします。[新しいフロントエンドの IP とポート] セクションで、次の変更を行います。
    1. 名前: fr-ilb
    2. サブネットワーク: ilb-subnet
    3. [内部 IP] から、[静的内部 IP アドレスの予約] を選択し、以下の情報を入力して [予約] をクリックします。
      • 名前: ip-ilb
      • 静的 IP アドレス: 選択を許可
      • カスタム IP アドレス: 10.1.2.99
    4. ポート: [単一] を選択して、ポート番号に「80」を入力します。
    5. 続行する前に、[フロントエンドの設定] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
  9. [確認と完了] をクリックします。設定を再度確認します。
  10. [作成] をクリックします。

gcloud

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

    gcloud compute health-checks create http hc-http-80 \
        --port=80
    
  2. HTTP トラフィックのバックエンド サービスを作成します。

    gcloud compute backend-services create be-ilb \
        --global-health-checks \
        --load-balancing-scheme=internal \
        --protocol=tcp \
        --region=us-west1 \
        --health-checks=hc-http-80 \
        --failover-ratio 0.75
    
  3. プライマリ バックエンドをバックエンド サービスに追加します。

    gcloud compute backend-services add-backend be-ilb \
        --region=us-west1 \
        --instance-group=ig-a \
        --instance-group-zone=us-west1-a
    
  4. フェイルオーバー バックエンドをバックエンド サービスに追加します。

    gcloud compute backend-services add-backend be-ilb \
        --region=us-west1 \
        --instance-group=ig-c \
        --instance-group-zone=us-west1-c \
        --failover
    
  5. バックエンド サービスの転送ルールを作成します。転送ルールを作成するときは、サブネット内の内部 IP に 10.1.2.99 を指定します。

    gcloud compute forwarding-rules create fr-ilb \
        --region=us-west1 \
        --load-balancing-scheme=internal \
        --network=lb-network \
        --subnet=lb-subnet \
        --address=10.1.2.99 \
        --ip-protocol=TCP \
        --ports=80 \
        --backend-service=be-ilb \
        --backend-service-region=us-west1
    

テスト

これらのテストでは、ロードバランサの構成を検証し、想定される動作を確認する方法を示します。

クライアント テスト手順

この手順では、クライアント VM からロードバランサに接続します。この手順は、後ほど他のテストを完了するために使用します。

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

    gcloud compute ssh vm-client --zone=us-west1-a
    
  2. curl を使用して IP アドレスに接続するロードバランサへのウェブ リクエストを作成します。

    curl http://10.1.2.99
    
  3. curl コマンドを実行して戻された値の文字列をメモします。レスポンスを生成するバックエンド VM の名前が文字列内に表示されます(たとえば、Page served from: vm-a1)。

初期状態のテスト

サンプルのロードバランサを構成した後は、通常、4 つのバックエンド VM すべてが正常に動作するようになります。

  • 2 つのプライマリ VM(vm-a1vm-a2
  • 2 つのバックアップ VM(vm-c1vm-c2

クライアント テスト手順に従ってください。2 つ目のステップを数回繰り返します。想定される動作は、2 つのプライマリ VM(vm-a1vm-a2)が両方とも正常になりトラフィックが正常に提供されることです。このロードバランサでセッション アフィニティが設定されていないため、約半分のレスポンスが各プライマリ VM によって処理されます。

フェイルオーバーのテスト

このテストでは、vm-a1 の障害をシミュレートしてフェイルオーバーの動作を確認できます。

  1. vm-a1 VM に接続します。

    gcloud compute ssh vm-a1 --zone=us-west1-a
    
  2. Apache ウェブサーバーを停止します。10 秒後、Google Cloud はこの VM を正常ではないと認識します(セットアップで作成した hc-http-80 ヘルスチェックでは、デフォルトのチェック間隔は 5 秒とされ、連続で 2 回のプローブの失敗が異常しきい値として使用されます)。

    sudo apachectl stop
    
  3. クライアント テスト手順に従ってください。2 つ目のステップを数回繰り返します。想定される動作は、2 つのバックアップ VM(vm-c1vm-c2)によってトラフィックが正常に提供されることです。正常なプライマリ VM(vm-a2)は 1 つのみであるため、正常なプライマリ VM のすべてのプライマリ VM に対する割合は 0.5 になります。この数はフェイルオーバーしきい値の 0.75 よりも小さいため、Google Cloud によってバックアップ VM を使用するようにロードバランサのアクティブプールが再構成されます。このロードバランサでセッション アフィニティが構成されない限り、約半分のレスポンスが各バックアップ VM によって処理されます。

フェイルバックのテスト

このテストでは、vm-a1 上の Apache サーバーを再起動してフェイルバックをシミュレートします。

  1. vm-a1 VM に接続します。

    gcloud compute ssh vm-a1 --zone=us-west1-a
    
  2. Apache ウェブサーバーを起動し、10 秒待ちます。

    sudo apachectl start
    
  3. クライアント テスト手順に従ってください。2 つ目のステップを数回繰り返します。想定される動作は、2 つのプライマリ VM(vm-a1vm-a2)によりトラフィックが正常に提供されることです。両方のプライマリ VM が正常な場合、すべてのプライマリ VM に対する正常なプライマリ VM の割合は 1.0 になります。この値は、フェイルオーバーしきい値 0.75 よりも大きい値であるため、プライマリ VM が再び使用されるように Google Cloud によってアクティブプールが構成されます。

バックエンド VM の追加

このセクションでは、ロードバランサにさらにプライマリ VM とバックアップ VM を追加してサンプルの構成例を拡張します。同じリージョン内の複数のゾーンにプライマリ VM とバックアップ VM を分散できることを示す 2 つのバックエンド インスタンス グループを作成します。

  • 第 3 のインスタンス グループ(us-west1-cig-d)は、2 つの VM を持つプライマリ バックエンドとして動作します。
    • vm-d1
    • vm-d2
  • 第 4 のインスタンス グループ(us-west1-aig-b)は、次の 2 つの VM を持つフェイルオーバー バックエンドとして動作します。
    • vm-b1
    • vm-b2

この例の修正されたアーキテクチャは次のようになります。

マルチゾーンの内部 TCP / UDP 負荷分散フェイルオーバー(クリックして拡大)
マルチゾーンの内部 TCP / UDP 負荷分散フェイルオーバー(クリックして拡大)

追加の VM とインスタンス グループの作成

追加のプライマリ VM とバックアップ VM、および対応する非マネージド インスタンス グループを作成します。

Console

バックエンド VM の作成

  1. Google Cloud Console の [VM インスタンス] ページに移動します。
    [VM インスタンス] ページに移動
  2. 次の手順を繰り返し、4 つの VM を作成します。次のような名前とゾーンの組み合わせを使用します。
    • 名前: vm-b1、ゾーン: us-west1-a
    • 名前: vm-b2、ゾーン: us-west1-a
    • 名前: vm-d1、ゾーン: us-west1-c
    • 名前: vm-d2、ゾーン: us-west1-c
  3. [インスタンスを作成] をクリックします。
  4. ステップ 2 に示したように [名前] を設定します。
  5. [リージョン] には、us-west1 を選択し、手順 2 に示したゾーンを選択します。
  6. [ブートディスク] セクションで、選択したイメージが Debian GNU/Linux 9 Stretch であることを確認します。必要に応じてイメージを変更するには、[選択] をクリックします。
  7. [管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックして、次のように変更します。

    • [ネットワーク] をクリックして、ネットワーク タグ allow-sshallow-health-check を追加します。
    • [ネットワーク インターフェース] にある編集ボタンをクリックして、次の変更を行い、[完了] をクリックします。
      • ネットワーク: lb-network
      • サブネット: lb-subnet
      • プライマリ内部 IP: エフェメラル(自動)
      • 外部 IP: エフェメラル
    • [管理] をクリックします。[起動スクリプト] フィールドに、次のスクリプトの内容をコピーして貼り付けます。スクリプトの内容は 4 つの VM ですべて同じです。

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

インスタンス·グループの作成

  1. Google Cloud Console の [インスタンス グループ] ページに移動します。
    [インスタンス グループ] ページに移動
  2. 次の手順を繰り返し、それぞれが 2 つの VM を持つ 2 つの非マネージド インスタンス グループを作成します。以下のような組み合わせを使用します。
    • インスタンス グループ: ig-b、ゾーン: us-west1-a、VM: vm-b1vm-b2
    • インスタンス グループ: ig-d、ゾーン: us-west1-c、VM: vm-d1vm-d2
  3. [インスタンス グループを作成] をクリックします。
  4. [新しい非マネージド インスタンス グループ] をクリックします。
  5. ステップ 2 に示したように [名前] を設定します。
  6. [ロケーション] セクションで、[リージョン] に us-west1 を選択し、ステップ 2 で示したように [ゾーン] を選択します。
  7. [ネットワーク] に「lb-network」と入力します。
  8. [サブネットワーク] に「lb-subnet」と入力します。
  9. [VM インスタンス] セクションに、ステップ 2 で示した VM を追加します。
  10. [作成] をクリックします。

gcloud

  1. [VM-NAME][ZONE] の 4 つの組み合わせを使用して、次のコマンドを 4 回実行して 4 つの VM を作成します。スクリプトの内容は 4 つの VM ですべて同じです。

    • vm-b1[VM-NAME]us-west1-a[ZONE]
    • vm-b2[VM-NAME]us-west1-a[ZONE]
    • vm-d1[VM-NAME]us-west1-c[ZONE]
    • vm-d2[VM-NAME]us-west1-c[ZONE]
    gcloud compute instances create [VM-NAME] \
        --zone=[ZONE] \
        --image-family=debian-9 \
        --image-project=debian-cloud \
        --tags=allow-ssh,allow-health-check \
        --subnet=lb-subnet \
        --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'
    
  2. 各ゾーンに次の 2 つの非マネージド インスタンス グループを作成します。

    gcloud compute instance-groups unmanaged create ig-b \
        --zone=us-west1-a
    gcloud compute instance-groups unmanaged create ig-d \
        --zone=us-west1-c
    
  3. 適切なインスタンス グループに VM を追加します。

    gcloud compute instance-groups unmanaged add-instances ig-b \
        --zone=us-west1-a \
        --instances=vm-b1,vm-b2
    gcloud compute instance-groups unmanaged add-instances ig-d \
        --zone=us-west1-c \
        --instances=vm-d1,vm-d2
    

プライマリ バックエンドの追加

この手順は、既存の内部 TCP / UDP ロードバランサのバックエンド サービスに非マネージド インスタンス グループをプライマリ バックエンドとして追加する際に使用できます。この構成例では、インスタンス グループ ig-d をプライマリ バックエンドとして be-ilb ロードバランサに追加する方法を示します。

Console

  1. Google Cloud Console の [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. [ロードバランサ] タブで、既存の内部 TCP または内部 UDP ロードバランサの名前をクリックします(この例の場合は、be-ilb)。
  3. [編集] をクリックします。
  4. [バックエンドの構成] で、[バックエンドを追加] をクリックして、非マネージド インスタンス グループを選択します(この例の場合は、ig-d)。
  5. [このインスタンス グループをバックアップ用のフェイルオーバー グループとして使用する] を必ずオフにしてください。
  6. [完了]、[更新] の順にクリックします。

gcloud

既存の内部 TCP / UDP ロードバランサのバックエンド サービスにプライマリ バックエンドを追加するには、次の gcloud コマンドを使用します。

gcloud compute backend-services add-backend [BACKEND_SERVICE_NAME] \
   --instance-group [INSTANCE_GROUP_NAME] \
   --instance-group-zone [INSTANCE_GROUP_ZONE] \
   --region [REGION]

ここで

  • [BACKEND_SERVICE_NAME] は、ロードバランサのバックエンド サービスの名前です。たとえば、be-ilb を使用します。
  • [INSTANCE_GROUP_NAME] は、プライマリ バックエンドとして追加するインスタンス グループの名前です。たとえば、ig-d を使用します。
  • [INSTANCE_GROUP_ZONE] は、インスタンス グループが定義されているゾーンです。 たとえば、us-west1-c を使用します。
    • [REGION] は、ロードバランサのリージョンです。たとえば、us-west1 を使用します。

api

regionBackendServices.patch メソッドを使用して、既存のバックエンド サービスにプライマリ バックエンドを追加します。

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/[REGION]/backendServices/[BACKEND_SERVICE_NAME]

{
  "backends":
  [
    {
      "balancingMode": "connection",
      "failover": false,
      "group": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[INSTANCE_GROUP_ZONE]/instanceGroups/[INSTANCE_GROUP_NAME]"
    }
  ]
}

ここで

  • [PROJECT_ID] は、プロジェクト ID です。
  • [REGION] は、ロードバランサのリージョンです。たとえば、us-west1 を使用します。
  • [BACKEND_SERVICE_NAME] は、ロードバランサのバックエンド サービスの名前です。たとえば、be-ilb を使用します。
  • [INSTANCE_GROUP_ZONE] は、インスタンス グループが定義されているゾーンです。 たとえば、us-west1-c を使用します。
  • [INSTANCE_GROUP_NAME] は、プライマリ バックエンドとして追加するインスタンス グループの名前です。たとえば、ig-d を使用します。

フェイルオーバー バックエンドの追加

この手順は、既存の内部 TCP / UDP ロードバランサのバックエンド サービスに非マネージド インスタンス グループをフェイルオーバー バックエンドとして追加する際に使用できます。この構成例では、インスタンス グループ ig-b をフェイルオーバー バックエンドとして be-ilb ロードバランサに追加する方法を示します。

Console

  1. Google Cloud Console の [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. [ロードバランサ] タブで、既存の内部 TCP または内部 UDP ロードバランサの名前をクリックします(この例の場合は、be-ilb)。
  3. [編集] をクリックします。
  4. [バックエンドの構成] で、[バックエンドを追加] をクリックして、非マネージド インスタンス グループを選択します(この例の場合は、ig-b)。
  5. [このインスタンス グループをバックアップ用のフェイルオーバー グループとして使用する] をオンにします。
  6. [完了]、[更新] の順にクリックします。

gcloud

既存の内部 TCP / UDP ロードバランサのバックエンド サービスにフェイルオーバー バックエンドを追加するには、次の gcloud コマンドを使用します。

gcloud compute backend-services add-backend [BACKEND_SERVICE_NAME] \
   --instance-group [INSTANCE_GROUP_NAME] \
   --instance-group-zone [INSTANCE_GROUP_ZONE] \
   --region [REGION] \
   --failover

ここで

  • [BACKEND_SERVICE_NAME] は、ロードバランサのバックエンド サービスの名前です。たとえば、be-ilb を使用します。
  • [INSTANCE_GROUP_NAME] は、フェイルオーバー バックエンドとして追加するインスタンス グループの名前です。たとえば、ig-b を使用します。
  • [INSTANCE_GROUP_ZONE] は、インスタンス グループが定義されているゾーンです。 たとえば、us-west1-a を使用します。
  • [REGION] は、ロードバランサのリージョンです。たとえば、us-west1 を使用します。

api

regionBackendServices.patch メソッドを使用して、既存のバックエンド サービスにフェイルオーバー バックエンドを追加します

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/[REGION]/backendServices/[BACKEND_SERVICE_NAME]

{
  "backends":
  [
    {
      "balancingMode": "connection",
      "failover": true,
      "group": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[INSTANCE_GROUP_ZONE]/instanceGroups/[INSTANCE_GROUP_NAME]"
    }
  ]
}

ここで

  • [PROJECT_ID] は、プロジェクト ID です。
  • [REGION] は、ロードバランサのリージョンです。たとえば、us-west1 を使用します。
  • [BACKEND_SERVICE_NAME] は、ロードバランサのバックエンド サービスの名前です。たとえば、be-ilb を使用します。
  • [INSTANCE_GROUP_ZONE] は、インスタンス グループが定義されているゾーンです。 たとえば、us-west1-a を使用します。
  • [INSTANCE_GROUP_NAME] は、フェイルオーバー バックエンドとして追加するインスタンス グループの名前です。たとえば、ig-b を使用します。

プライマリ バックエンドまたはフェイルオーバー バックエンドの変換

内部 TCP / UDP ロードバランサのバックエンド サービスからインスタンス グループを削除せずに、プライマリ バックエンドをフェイルオーバー バックエンドに変換すること(またはその逆)ができます。

Console

  1. Google Cloud Console の [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. [ロードバランサ] タブで、既存の内部 TCP または内部 UDP ロードバランサの名前をクリックします。
  3. [編集] をクリックします。
  4. [バックエンドの構成] で、いずれかのバックエンド インスタンス グループの名前をクリックします。次に下記のように指定します。
    • インスタンス グループをフェイルオーバー バックエンドにするには、[このインスタンス グループをバックアップ用のフェイルオーバー グループとして使用する] をオンにします。
    • インスタンス グループをプライマリ バックエンドにするには、[このインスタンス グループをバックアップ用のフェイルオーバー グループとして使用する] をオフにします。
  5. [完了]、[更新] の順にクリックします。

gcloud

既存のプライマリ バックエンドをフェイルオーバー バックエンドに変換するには、次の gcloud コマンドを使用します。

gcloud compute backend-services update-backend [BACKEND_SERVICE_NAME] \
   --instance-group [INSTANCE_GROUP_NAME] \
   --instance-group-zone [INSTANCE_GROUP_ZONE] \
   --region [REGION] \
   --failover

既存のフェイルオーバー バックエンドをプライマリ バックエンドに変換するには、次の gcloud コマンドを使用します。

gcloud compute backend-services update-backend [BACKEND_SERVICE_NAME] \
   --instance-group [INSTANCE_GROUP_NAME] \
   --instance-group-zone [INSTANCE_GROUP_ZONE] \
   --region [REGION] \
   --no-failover

ここで

  • [BACKEND_SERVICE_NAME] は、ロードバランサのバックエンド サービスの名前です。
  • [INSTANCE_GROUP_NAME] はインスタンス グループの名前です。
  • [INSTANCE_GROUP_ZONE] は、インスタンス グループが定義されているゾーンです。
  • [REGION] は、ロードバランサのリージョンです。

api

regionBackendServices.patch メソッドを使用してプライマリ バックエンドをフェイルオーバー バックエンド(またはその逆)に変換します

プライマリ バックエンドをフェイルオーバー バックエンドに変換するには、次のように指定します。

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/[REGION]/backendServices/[BACKEND_SERVICE_NAME]

{
  "backends":
  [
    {
      "failover": true,
      "group": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[INSTANCE_GROUP_ZONE]/instanceGroups/[INSTANCE_GROUP_NAME]"
    }
  ]
}

フェイルオーバー バックエンドをプライマリ バックエンドに変換するには、次のように指定します。

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/[REGION]/backendServices/[BACKEND_SERVICE_NAME]

{
  "backends":
  [
    {
      "failover": false,
      "group": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[INSTANCE_GROUP_ZONE]/instanceGroups/[INSTANCE_GROUP_NAME]"
    }
  ],
}

ここで

  • [PROJECT_ID] は、プロジェクト ID です。
  • [REGION] は、ロードバランサのリージョンです。
  • [BACKEND_SERVICE_NAME] は、ロードバランサのバックエンド サービスの名前です。
  • [INSTANCE_GROUP_ZONE] は、インスタンス グループが定義されているゾーンです。
  • [INSTANCE_GROUP_NAME] は、インスタンス グループの名前です。

フェイルオーバー ポリシーの構成

このセクションでは、内部 TCP / UDP ロードバランサのバックエンド サービスのフェイルオーバー ポリシーを管理する方法について説明します。フェイルオーバー ポリシーは次のように構成されます。

  • フェイルオーバー率
  • すべてのバックエンド VM が正常でない場合のトラフィックの廃棄
  • フェイルオーバー時にコネクション ドレインを行う

フェイルオーバー ポリシーのパラメータについて詳しくは、次をご覧ください。

フェイルオーバー ポリシーの定義

次の手順は、既存の内部 TCP / UDP ロードバランサのフェイルオーバー ポリシーを定義します。

Console

Cloud Console を使用してフェイルオーバー ポリシーを定義するには、少なくとも 1 つのフェイルオーバー バックエンドが必要です。

  1. Google Cloud Console の [負荷分散] ページに移動します。
    [負荷分散] ページに移動
  2. [ロードバランサ] タブで、[TCP(内部)] または [ UDP(内部)] ロードバランサを選択します。
  3. [編集] をクリックします。
  4. 少なくとも 1 つのフェイルオーバー バックエンドが存在することを確認してください。ロードバランサのバックエンドの少なくとも 1 つで、[このインスタンス グループをバックアップ用のフェイルオーバー グループとして使用する] をオンにする必要があります。
  5. [詳細構成] をクリックします。
    • [フェイルオーバー ポリシー] で、[フェイルオーバー率] を 0.01.0 の値に設定します。
    • アクティブな VM とバックアップ VM がすべて正常でない場合にトラフィックをドロップするには、[トラフィックのドロップを有効にする] をオンにします。
    • フェイルオーバーの際に既存の接続をすばやく終了させるには、[フェイルオーバー時にコネクション ドレインを有効にする] をオンにします。
  6. [確認と完了] をクリックしてから、[更新] をクリックします。

gcloud

フェイルオーバー ポリシーを定義するには、gcloud コマンドライン ツールを使用してロードバランサのバックエンド サービスを更新します。

gcloud compute backend-services update [BACKEND_SERVICE_NAME] \
   --region [REGION] \
   --failover-ratio [FAILOVER_RATIO] \
   --drop-traffic-if-unhealthy \
   --no-connection-drain-on-failover

ここで

  • [BACKEND_SERVICE_NAME] は、ロードバランサのバックエンド サービスの名前です。たとえば、be-ilb を使用します。
  • [REGION] は、ロードバランサのリージョンです。たとえば、us-west1 を使用します。
  • [FAILOVER_RATIO] は、フェイルオーバー率です。可能な値は、0.01.0 です。たとえば、0.75 を使用します。
  • --drop-traffic-if-unhealthy を指定すると、プライマリ VM とバックアップ VM がすべて正常でない場合に、ロードバランサがトラフィックをドロップするように設定されます。バックエンド VM がすべて正常でない場合にすべてのプライマリ VM 間でトラフィックを分散させるには、この指定を --no-drop-traffic-if-unhealthy に変更します。
  • --no-connection-drain-on-failover を指定すると、既存の TCP 接続をフェイルオーバー中にすばやく終了するようにロードバランサが設定されます。--connection-drain-on-failover を使用すると、フェイルオーバーの際にコネクション ドレインが有効になります。

api

regionBackendServices.patch メソッドを使用してフェイルオーバー ポリシーを定義します。

PATCH https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/[REGION]/backendServices/[BACKEND_SERVICE_NAME]

{
  "failoverPolicy":
  {
    "failoverRatio": [FAILOVER_RATIO],
    "dropTrafficIfUnhealthy": [true|false],
    "disableConnectionDrainOnFailover": [true|false]
  }
}

ここで

  • [PROJECT_ID] は、プロジェクト ID です。
  • [REGION] は、ロードバランサのリージョンです。
  • [BACKEND_SERVICE_NAME] は、ロードバランサのバックエンド サービスの名前です。
  • [FAILOVER_RATIO] は、フェイルオーバー率です。可能な値は、0.01.0 です。
  • dropTrafficIfUnhealthytrue に設定すると、プライマリ VM とバックアップ VM がすべて正常でない場合に、ロードバランサがトラフィックをドロップするように設定されます。バックエンド VM がすべて正常でない場合にすべてのプライマリ VM 間でトラフィックを分散させるには、この指定を false に設定します。
  • disableConnectionDrainOnFailovertrue に設定すると、プライマリ VM とバックアップ VM がすべて正常でない場合に、フェイルオーバーの際に既存の TCP 接続をすばやく終了するようにロードバランサが設定されます。この値を false に設定すると、フェイルオーバーの際にコネクション ドレインが有効になります。

フェイルオーバー ポリシーの表示

次の手順は、内部 TCP / UDP ロードバランサの既存のフェイルオーバー ポリシーを表示します。

Console

内部 TCP / UDP ロードバランサを編集する際に、Cloud Console に既存のフェイルオーバー ポリシー設定が表示されます。手順については、フェイルオーバー ポリシーの定義をご覧ください。

gcloud

フェイルオーバー ポリシーの設定を一覧表示するには、gcloud コマンドライン ツールで次のコマンドを使用します。フェイルオーバー ポリシーで定義されていない設定は、デフォルトのフェイルオーバー ポリシーの値を使用します。

gcloud compute backend-services describe [BACKEND_SERVICE_NAME] \
   --region [REGION] \
   --format="get(failoverPolicy)"

ここで

  • [BACKEND_SERVICE_NAME] は、ロードバランサのバックエンド サービスの名前です。たとえば、be-ilb を使用します。
  • [REGION] は、ロードバランサのリージョンです。たとえば、us-west1 を使用します。

api

regionBackendServices.get メソッドを使用してフェイルオーバー ポリシーを表示します

この API リクエストに対するレスポンスは、フェイルオーバー ポリシーを示します。たとえば、次のようになります。

GET https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/[REGION]/backendServices/[BACKEND_SERVICE_NAME]

ここで

  • [PROJECT_ID] は、プロジェクト ID です。
  • [REGION] は、ロードバランサのリージョンです。
  • [BACKEND_SERVICE_NAME] は、ロードバランサのバックエンド サービスの名前です。
{
...
"failoverPolicy": {
"disableConnectionDrainOnFailover": false,
"dropTrafficIfUnhealthy": false,
"failoverRatio": 0.75
...
}

次のステップ