このガイドでは、サンプルを示しながら、Google Cloud Platform の内部 TCP / UDP 負荷分散の基礎について解説します。このガイドに進む前に、次の内容を理解しておいてください。
権限
このガイドを使用する前に、インスタンスを作成し、プロジェクト内のネットワークを変更しておく必要があります。そのためにはプロジェクトの所有者または編集者であるか、または次の Compute Engine IAM の役割をすべて持っている必要があります。
タスク | 必要な役割 |
---|---|
ネットワーク、サブネット、ロードバランサ コンポーネントの作成 | ネットワーク管理者 |
ファイアウォール ルールの追加と削除 | セキュリティ管理者 |
インスタンスの作成 | インスタンス管理者 |
設定
このガイドでは、内部 TCP / UDP ロードバランサの構成とテストの方法を説明します。このセクションでは、以下の構成方法について説明します。
- カスタム サブネットを持つ VPC ネットワークのサンプル
- バックエンド VM への受信接続を許可するファイアウォール ルール
- 4 つのバックエンド VM :
- ゾーン
us-west1-a
の非マネージド インスタンス グループ内の 2 つの VM - ゾーン
us-west1-c
の非マネージド インスタンス グループ内の 2 つの VM
- ゾーン
- 接続のテストに使用する 1 台のクライアント VM
- 次の内部 TCP / UDP ロードバランサ コンポーネント:
- バックエンド サービスのヘルスチェック
us-west1
リージョンの内部バックエンド サービス。2 つのゾーン インスタンス グループへの接続分散を管理します。- ロードバランサのフロントエンドの内部転送ルールと内部 IP アドレス
この例のアーキテクチャは次のようになります。
ネットワーク、リージョン、サブネットの構成
少なくとも 1 つのサブネットを持つ VPC ネットワークが必要です。内部 TCP / UDP ロードバランサはリージョンで動作します。VPC ネットワーク内のトラフィックは、そのソースがロードバランサと同じリージョンのサブネットからのものである場合に、ロードバランサにルーティングされます。
この例では、次の VPC ネットワーク、リージョン、サブネットを使用します。
ネットワーク: ネットワークは、
lb-network
という名前のカスタムモードの VPC ネットワークです。リージョン: リージョンは、
us-west1
です。サブネット: サブネット
lb-subnet
は、10.1.2.0/24
の IP 範囲です。
サンプルのネットワークとサブネットを作成する手順は次のとおりです。
Console
- Google Cloud Platform Console で [VPC ネットワーク] ページに移動します。
[VPC ネットワーク] ページに移動 - [VPC ネットワークを作成] をクリックします。
- [名前] に「
lb-network
」を入力します。 - [サブネット] セクションで次の設定を行います。
- [サブネット作成モード] を [カスタム] に設定します。
- [新しいサブネット] セクションに、次の情報を入力します。
- 名前:
lb-subnet
- リージョン:
us-west1
- IP アドレス範囲:
10.1.2.0/24
- [完了] をクリックします。
- 名前:
- [作成] をクリックします。
gcloud
カスタム VPC ネットワークを作成します。
gcloud compute networks create lb-network --subnet-mode=custom
サブネットを
us-west1
リージョン内のlb-network
ネットワークに作成します。gcloud compute networks subnets create lb-subnet \ --network=lb-network \ --range=10.1.2.0/24 \ --region=us-west1
api
networks.insert
メソッドに POST
リクエストを送信します。
POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks
{
"routingConfig": {
"routingMode": "REGIONAL"
},
"name": "lb-network",
"autoCreateSubnetworks": false
}
subnetworks.insert
メソッドに POST
リクエストを送信します。
POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks
{
"name": "lb-subnet",
"network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
"ipCidrRange": "10.1.2.0/24",
"privateIpGoogleAccess": false
}
ファイアウォール ルールの構成
この例では、次のファイアウォール ルールを使用します。
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
: 負荷分散されているインスタンスに適用され、GCP ヘルスチェック システムからのトラフィックを許可する上りルール(130.211.0.0/22
と35.191.0.0/16
)。この例では、ターゲットタグallow-health-check
を使用して適用するインスタンスを識別しています。
これらのファイアウォール ルールがない場合は、デフォルトの上り拒否ルールによってバックエンド インスタンスへの受信トラフィックがブロックされます。
Console
- Google Cloud Platform Console で [ファイアウォール ルール] ページに移動します。
[ファイアウォール ルール] ページに移動 - [ファイアウォール ルールを作成] をクリックして次の情報を入力し、サブネット トラフィックを許可するルールを作成します。
- 名前:
fw-allow-lb-subnet
- ネットワーク:
lb-network
- 優先度:
1000
- トラフィックの方向: 上り
- 一致したときのアクション: 許可
- ターゲット: ネットワーク内のすべてのインスタンス
- ソースフィルタ:
IP ranges
- ソース IP の範囲:
10.1.2.0/24
- プロトコルとポート: すべて許可
- 名前:
- [作成] をクリックします。
- [ファイアウォール ルールを作成] を再度クリックして、SSH 接続の受信を許可するルールを作成します。
- 名前:
fw-allow-ssh
- ネットワーク:
lb-network
- 優先度:
1000
- トラフィックの方向: 上り
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ:
allow-ssh
- ソースフィルタ:
IP ranges
- ソース IP の範囲:
0.0.0.0/0
- プロトコルとポート: 指定されたプロトコルとポートを選択してから、次のように入力します。
tcp:22
- 名前:
- [作成] をクリックします。
- [ファイアウォール ルールを作成] をもう一度クリックして、GCP ヘルスチェックを許可するルールを作成します。
- 名前:
fw-allow-health-check
- ネットワーク:
lb-network
- 優先度:
1000
- トラフィックの方向: 上り
- 一致したときのアクション: 許可
- ターゲット: 指定されたターゲットタグ
- ターゲットタグ:
allow-health-check
- ソースフィルタ:
IP ranges
- 送信元 IP 範囲:
130.211.0.0/22
と35.191.0.0/16
- プロトコルとポート: すべて許可
- 名前:
- [作成] をクリックします。
gcloud
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
ネットワーク タグ
allow-ssh
を使用して、VM との SSH 接続を許可するfw-allow-ssh
ファイアウォール ルールを作成します。source-ranges
を省略すると、GCP は任意の送信元としてルールを解釈します。gcloud compute firewall-rules create fw-allow-ssh \ --network=lb-network \ --action=allow \ --direction=ingress \ --target-tags=allow-ssh \ --rules=tcp:22
fw-allow-health-check
ルールを作成して GCP ヘルスチェックを許可します。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
api
firewalls.insert
メソッドに POST
リクエストを送信して、fw-allow-lb-subnet
ファイアウォール ルールを作成します。
POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls
{
"name": "fw-allow-lb-subnet",
"network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
"priority": 1000,
"sourceRanges": [
"10.1.2.0/24"
],
"allowed": [
{
"IPProtocol": "tcp"
},
{
"IPProtocol": "udp"
},
{
"IPProtocol": "icmp"
}
],
"direction": "INGRESS",
"logConfig": {
"enable": false
},
"disabled": false
}
firewalls.insert
メソッドに POST
リクエストを送信して、fw-allow-ssh
ファイアウォール ルールを作成します。
POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls
{
"name": "fw-allow-ssh",
"network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
"priority": 1000,
"sourceRanges": [
"0.0.0.0/0"
],
"targetTags": [
"allow-ssh"
],
"allowed": [
{
"IPProtocol": "tcp",
"ports": [
"22"
]
}
],
"direction": "INGRESS",
"logConfig": {
"enable": false
},
"disabled": false
}
firewalls.insert
メソッドに POST
リクエストを送信して、fw-allow-health-check
ファイアウォール ルールを作成します。
POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/firewalls
{
"name": "fw-allow-health-check",
"network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
"priority": 1000,
"sourceRanges": [
"130.211.0.0/22",
"35.191.0.0/16"
],
"targetTags": [
"allow-health-check"
],
"allowed": [
{
"IPProtocol": "tcp"
},
{
"IPProtocol": "udp"
},
{
"IPProtocol": "icmp"
}
],
"direction": "INGRESS",
"logConfig": {
"enable": false
},
"disabled": false
}
バックエンド VM とインスタンス グループの作成
この例では、2 つのバックエンド(サーバー)VM を持つ 2 つの非マネージド インスタンスを使用しています。内部 TCP / UDP 負荷分散のリージョン特性を示すために、2 つのインスタンス グループが別々のゾーン(us-west1-a
と us-west1-c
)に配置されています。
- インスタンス グループ
ig-a
には、次の 2 つの VM が含まれています。vm-a1
vm-a2
- インスタンス グループ
ig-c
には、次の 2 つの VM が含まれています。vm-c1
vm-c2
4 つのバックエンド VM へのトラフィックがすべて負荷分散されます。4 つはそれぞれ TCP ポート 80 と 443 で Apache ウェブサーバーを実行します。lb-subnet
の内部 IP アドレスと外部(公開)エフェメラル IP アドレスがそれぞれ割り当てられます。外部 IP アドレスは後で削除できます。
バックエンド VM がインターネットから Apache をダウンロードできる、および SSH 経由で接続しやすいという理由からこの例では使用していますが、バックエンド VM の外部 IP アドレスは必須ではありません。
デフォルトでは、Apache は任意の IP アドレスにバインドされます。 内部 TCP / UDP ロードバランサは、宛先 IP を保持してパケットを配信します。バックエンド VM で実行中のサーバー ソフトウェアが、ロードバランサの内部転送ルールの IP アドレスをリッスンしていることを確認してください。複数の内部転送ルールを設定している場合、ソフトウェアによってそれぞれに関連付けられた内部 IP アドレスがリッスンされます。内部 TCP / UDP ロードバランサによってバックエンド VM に配信されるパケットの宛先 IP アドレスは、転送ルールの内部 IP アドレスです。
これらのバックエンド VM では、説明を簡単にするため、Debian GNU/Linux 9 を実行します。
Console
バックエンド VM の作成
- Google Cloud Platform Console の [VM インスタンス] ページに移動します。
[VM インスタンス] ページに移動 - 次の手順を繰り返し、4 つの VM を作成します。次のような名前とゾーンの組み合わせを使用します。
- 名前:
vm-a1
、ゾーン:us-west1-a
- 名前:
vm-a2
、ゾーン:us-west1-a
- 名前:
vm-c1
、ゾーン:us-west1-c
- 名前:
vm-c2
、ゾーン:us-west1-c
- 名前:
- [インスタンスを作成] をクリックします。
- ステップ 2 に示したように [名前] を設定します。
- [リージョン] には、
us-west1
を選択し、手順 2 に示したゾーンを選択します。 - [ブートディスク] セクションで、選択したイメージが Debian GNU/Linux 9 Stretch であることを確認します。必要に応じてイメージを変更するには、[選択] をクリックします。
[管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックして、次のように変更します。
- [ネットワーク] をクリックして、ネットワーク タグ
allow-ssh
とallow-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
- [ネットワーク] をクリックして、ネットワーク タグ
[作成] をクリックします。
インスタンス·グループの作成
- Google Cloud Platform Console の [インスタンス グループ] ページに移動します。
[インスタンス グループ] ページに移動 - 次の手順を繰り返し、それぞれが 2 つの VM を持つ 2 つの非マネージド インスタンス グループを作成します。以下のような組み合わせを使用します。
- インスタンス グループ:
ig-a
、ゾーン:us-west1-a
、VM:vm-a1
とvm-a2
- インスタンス グループ:
ig-c
、ゾーン:us-west1-c
、VM:vm-c1
とvm-c2
- インスタンス グループ:
- [インスタンス グループを作成] をクリックします。
- ステップ 2 に示したように [名前] を設定します。
- [ロケーション] セクションで、[シングルゾーン] を選択して、[リージョン] には
us-west1
を選択し、ステップ 2 に示したゾーンを選択します。 - [グループタイプ] セクションで [非マネージド インスタンス グループ] を選択します。
- [ネットワーク] に「
lb-network
」と入力します。 - [サブネットワーク] に「
lb-subnet
」と入力します。 - [VM インスタンス] セクションに、ステップ 2 で示した VM を追加します。
- [作成] をクリックします。
gcloud
[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 つの非マネージド インスタンス グループを作成します。
gcloud compute instance-groups unmanaged create ig-a \ --zone=us-west1-a gcloud compute instance-groups unmanaged create ig-c \ --zone=us-west1-c
適切なインスタンス グループに 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
api
4 つの VM の場合は、次の 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]
4 つのバックエンド VM を作成するには、instances.insert
メソッドに 4 つの POST
リクエストを送信します。
POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances
{
"name": "[VM-NAME]",
"tags": {
"items": [
"allow-health-check",
"allow-ssh"
]
},
"machineType": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/machineTypes/n1-standard-1",
"canIpForward": false,
"networkInterfaces": [
{
"network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks/lb-subnet",
"accessConfigs": [
{
"type": "ONE_TO_ONE_NAT",
"name": "external-nat",
"networkTier": "PREMIUM"
}
]
}
],
"disks": [
{
"type": "PERSISTENT",
"boot": true,
"mode": "READ_WRITE",
"autoDelete": true,
"deviceName": "[VM-NAME]",
"initializeParams": {
"sourceImage": "projects/debian-cloud/global/images/debian-9-stretch-v20190618",
"diskType": "projects/[PROJECT_ID]/zones/us-west1-a/diskTypes/pd-standard",
"diskSizeGb": "10"
}
}
]
"metadata": {
"items": [
{
"key": "startup-script",
"value": "#! /bin/bash\napt-get update\napt-get install apache2 -y\na2ensite default-ssl\na2enmod ssl\nvm_hostname=\"$(curl -H \"Metadata-Flavor:Google\" \\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\necho \"Page served from: $vm_hostname\" | \\\ntee /var/www/html/index.html\nsystemctl restart apache2"
}
]
},
"scheduling": {
"preemptible": false
},
"deletionProtection": false
}
instanceGroups.insert
メソッドに POST
リクエストを送信して、2 つのインスタンス グループを作成します。
POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instanceGroups
{
"name": "ig-a",
"network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks/lb-subnet"
}
POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-c/instanceGroups
{
"name": "ig-c",
"network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks/lb-subnet"
}
instanceGroups.addInstances
メソッドに POST
リクエストを送信して、各インスタンス グループにインスタンスを追加します。
POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instanceGroups/ig-a/addInstances
{
"instances": [
{
"instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instances/vm-a1",
"instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instances/vm-a2"
}
]
}
POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-c/instanceGroups/ig-c/addInstances
{
"instances": [
{
"instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-c/instances/vm-c1",
"instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-c/instances/vm-c2"
}
]
}
クライアント VM の作成
この例では、クライアント VM(vm-client
)を、バックエンド(サーバー)VM と同じリージョンに作成します。クライアントは、ロードバランサの構成を検証し、テストセクションで説明されている想定される動作を示すために使用します。
Console
- Google Cloud Platform Console の [VM インスタンス] ページに移動します。
[VM インスタンス] ページに移動 - [インスタンスを作成] をクリックします。
- [名前] を
vm-client
に設定します。 - [ゾーン] を
us-west1-a
に設定します。 - [管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックして、次のように変更します。
- [ネットワーキング] をクリックして
allow-ssh
を ネットワーク タグに追加します。 - [ネットワーク インターフェース] にある編集ボタンをクリックして、次の変更を行い、[完了] をクリックします。
- ネットワーク:
lb-network
- サブネット:
lb-subnet
- プライマリ内部 IP: エフェメラル(自動)
- 外部 IP: エフェメラル
- ネットワーク:
- [ネットワーキング] をクリックして
- [作成] をクリックします。
gcloud
クライアント VM はロードバランサと同じリージョン内の任意のゾーンにあり、そのリージョン内の任意のサブネットを使用できます。この例では、クライアントは us-west1-a
ゾーンにあり、バックエンド 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
api
instances.insert
メソッドに POST
リクエストを送信します。
POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instances
{
"name": "vm-client",
"tags": {
"items": [
"allow-ssh"
]
},
"machineType": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/machineTypes/n1-standard-1",
"canIpForward": false,
"networkInterfaces": [
{
"network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks/lb-subnet",
"accessConfigs": [
{
"type": "ONE_TO_ONE_NAT",
"name": "external-nat",
"networkTier": "PREMIUM"
}
]
}
],
"disks": [
{
"type": "PERSISTENT",
"boot": true,
"mode": "READ_WRITE",
"autoDelete": true,
"deviceName": "[VM-NAME]",
"initializeParams": {
"sourceImage": "projects/debian-cloud/global/images/debian-9-stretch-v20190618",
"diskType": "projects/[PROJECT_ID]/zones/us-west1-a/diskTypes/pd-standard",
"diskSizeGb": "10"
}
}
]
"scheduling": {
"preemptible": false
},
"deletionProtection": false
}
ロードバランサのコンポーネントを構成する
この手順では、ヘルスチェックとバックエンド サービス、フロントエンド コンポーネントなどの内部 TCP / UDP ロードバランサ コンポーネントを構成します。
ヘルスチェック: この例では、HTTP ヘルスチェックで HTTP
200
(OK)レスポンスを確認します。詳細については、内部 TCP / UDP 負荷分散の概要のヘルスチェックのセクションをご覧ください。バックエンド サービス: HTTP トラフィックが内部ロードバランサに渡されるため、UDP ではなく TCP を指定します。
転送ルール: この例では、内部転送ルールを 1 つ作成します。
内部 IP アドレス: この例では、転送ルールを作成する際に内部 IP アドレス(
10.1.2.99
)を指定しています。
Console
ロードバランサの作成とバックエンド サービスの構成
- Google Cloud Platform Console の [負荷分散] ページに移動します。
[負荷分散] ページに移動 - [ロードバランサを作成] をクリックします。
- [TCP 負荷分散] で [設定を開始] をクリックします。
- [インターネット接続または内部専用] で [VM 間のみ] を選択します。
- [続行] をクリックします。
- [名前] を
be-ilb
に設定します。 - [バックエンドの設定] をクリックして、次の変更を行います。
- リージョン:
us-west1
- ネットワーク:
lb-network
- [バックエンド] の [新しいアイテム] セクションで、
ig-a
インスタンス グループを選択し、[完了] をクリックします。 - [バックエンドを追加] をクリックします。[新しいアイテム] セクションが表示されたら、
ig-c
インスタンス グループを選択して、[完了] をもう一度クリックします。 - [ヘルスチェック] で [別のヘルスチェックを作成] を選択し、次の情報を入力して [保存して次へ] をクリックします。
- 名前:
hc-http-80
- プロトコル:
HTTP
- ポート:
80
- プロキシ プロトコル:
NONE
- リクエストパス:
/
- 名前:
- 続行する前に、[バックエンドの設定] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
- リージョン:
- [フロントエンドの設定] をクリックします。[新しいフロントエンドの IP とポート] セクションで、次の変更を行います。
- 名前:
fr-ilb
- サブネットワーク:
ilb-subnet
- [内部 IP] から、[静的内部 IP アドレスの予約] を選択し、以下の情報を入力して [予約] をクリックします。
- 名前:
ip-ilb
- 静的 IP アドレス: 選択を許可
- カスタム IP アドレス:
10.1.2.99
- 名前:
- ポート: [単一] を選択して、ポート番号に「
80
」を入力します。 - 続行する前に、[フロントエンドの設定] の隣に青いチェックマークがあることを確認します。ない場合は、この手順を確認します。
- 名前:
- [確認と完了] をクリックします。設定を再度確認します。
- [作成] をクリックします。
gcloud
新しい HTTP ヘルスチェックを作成して、ポート 80 で VM との TCP 接続をテストします。
gcloud compute health-checks create http hc-http-80 \ --port=80
HTTP トラフィックのバックエンド サービスを作成します。
gcloud compute backend-services create be-ilb \ --load-balancing-scheme=internal \ --protocol=tcp \ --region=us-west1 \ --health-checks=hc-http-80
バックエンド サービスに、2 つのインスタンス グループを追加します。
gcloud compute backend-services add-backend be-ilb \ --region=us-west1 \ --instance-group=ig-a \ --instance-group-zone=us-west1-a gcloud compute backend-services add-backend be-ilb \ --region=us-west1 \ --instance-group=ig-c \ --instance-group-zone=us-west1-c
バックエンド サービスの転送ルールを作成します。転送ルールを作成するときは、サブネット内の内部 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
api
healthChecks.insert
メソッドに POST
リクエストを送信してヘルスチェックを作成します。
POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/healthChecks
{
"name": "hc-http-80",
"type": "HTTP",
"httpHealthCheck": {
"port": 80
}
}
regionBackendServices.insert
メソッドに POST
リクエストを送信してリージョン バックエンド サービスを作成します。
POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices
{
"name": "be-ilb",
"backends": [
{
"group": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instanceGroups/ig-a",
"balancingMode": "CONNECTION"
}
{
"group": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-c/instanceGroups/ig-c",
"balancingMode": "CONNECTION"
}
],
"healthChecks": [
"https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/healthChecks/hc-http-80"
],
"loadBalancingScheme": "INTERNAL",
"connectionDraining": {
"drainingTimeoutSec": 0
}
}
forwardingRules.insert
メソッドに POST
リクエストを送信して転送ルールを作成します。
POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/forwardingRules
{
"name": "fr-ilb",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"ports": [
"80"
],
"loadBalancingScheme": "INTERNAL",
"subnetwork": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/subnetworks/lb-subnet",
"network": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/networks/lb-network",
"backendService": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/be-ilb",
"networkTier": "PREMIUM"
}
テスト
これらのテストでは、ロードバランサの構成を検証し、想定される動作を確認する方法を示します。
負荷分散のテスト
このテストでは、ロードバランサのバックエンド VM からではなく、個別のクライアント VM からロードバランサに接続します。セッション アフィニティが設定されていないため、トラフィックは 4 つのバックエンド VM に分散されます。
クライアント VM インスタンスに接続します。
gcloud compute ssh vm-client --zone=us-west1-a
curl
を使用して IP アドレスに接続するロードバランサへのウェブ リクエストを作成します。レスポンスが異なるバックエンド VM から返ってくることを確認するために、このリクエストを繰り返します。レスポンスを生成する VM の名前が、各バックエンド VM 上で、/var/www/html/index.html
のコンテンツによる HTML レスポンスのテキストとして表示されます。想定されるレスポンスは、Page served from: vm-a1
、Page served from: vm-a2
などです。curl http://10.1.2.99
内部転送ルールにサービスラベルを追加すると、内部 DNS サービス名を使用してロードバランサに接続できます。
curl http://web-test.fr-ilb.il4.us-west1.lb.[PROJECT_ID].internal
ロードバランサの IP アドレスに対する ping の実行
このテストでは、ロードバランサの IP アドレスに対して ping を実行することはできません。このテストではこの想定される動作が示されます。これは、内部 TCP / UDP ロードバランサが、別々のデバイスではなく、仮想ネットワーク プログラミングで実装されているためです。
クライアント VM インスタンスに接続します。
gcloud compute ssh vm-client --zone=us-west1-a
ロードバランサの IP アドレスに対して ping を試行します。レスポンスが返されず、
ping
コマンドがこの例では 10 秒後にタイムアウトすることに注意してください。timeout 10 ping 10.1.2.99
負荷分散された VM からのリクエストの送信
このテストでは、負荷分散されているサーバー VM のバックエンド VM からのロードバランサへのリクエストが、常に同じ VM によって応答されることが示されます。
内部 TCP / UDP 負荷分散は、ゲスト OS の仮想ネットワーク プログラミングと VM 構成を使用して実装されます。Linux VM では、Linux ゲスト環境によってゲスト OS ルーティング テーブルにルートをインストールしてローカル構成が実行されます。ローカルルートのため、ロードバランサの IP アドレスへのトラフィックは、負荷分散された VM 自体に残ります。(このローカルルートは VPC ネットワークのルートとは異なるルートです。)
バックエンド VM に接続します(たとえば、
vm-a1
)。gcloud compute ssh vm-a1 --zone=us-west1-a
IP アドレスまたはサービス名を指定し
curl
を使用して、ロードバランサにウェブリク エストを送信します。 。リクエストを繰り返します。その際、リクエストを処理するバックエンド VM からレスポンスが送信されることに注意してください。vm-a1
からテストするときに想定される応答は常に次のとおりです。Page served from: vm-a1
curl http://10.1.2.99
ローカルのルーティング テーブルを調べて、ロードバランサ自体の IP アドレス(
10.1.2.99
)に一致する宛先を探します。このルートは内部 TCP / UDP 負荷分散に必須の部分です。これにより、ロードバランサの背後にある VM からのリクエストが常に同じ VM によって応答される理由がわかります。ip route show table local | grep 10.1.2.99
追加の構成オプション
このセクションでは、代替および追加の設定オプションを提供する構成例を示します。これらのタスクはすべて省略可です。これらは任意の順序で実行できます。
マネージド インスタンス グループの構成
この構成例では、非マネージド インスタンス グループが作成されています。内部 TCP / UDP 負荷分散のバックエンドとして、マネージド インスタンス グループ(ゾーンまたはリージョンのマネージド インスタンス グループなど)を使用できます。
マネージド インスタンス グループを使用するには、インスタンス テンプレートを作成する必要があります。この例では、ゾーンの 2 つの非マネージド インスタンス グループを 1 つのリージョン マネージド インスタンス グループに置き換える方法を示しています。リージョンのマネージド インスタンス グループは、複数のゾーンに VM を自動的に作成し、ゾーン間で本番環境トラフィックを分散するのが容易になります。
マネージド インスタンス グループは、自動スケーリングと自動修復をサポートします。内部 TCP / UDP 負荷分散で自動スケーリングを使用する場合、負荷分散に基づいてスケーリングすることはできません。
この手順では、内部 TCP / UDP ロードバランサのバックエンド サービスを、リージョンのマネージド インスタンス グループを使用して変更する方法を示します。
Console
インスタンス テンプレート
- Google Cloud Platform Console の VM インスタンス テンプレート ページに移動します。
VM インスタンス テンプレート ページに移動 - [インスタンス テンプレートを作成] をクリックします。
- [名前] を
template-vm-ilb
に設定します。 - マシンタイプを選択してください。
- [ブートディスク] で、[変更] をクリックしてから、[ Debian GNU/Linux 9 Stretch] を選択し、[選択] をクリックします。
- [管理、セキュリティ、ディスク、ネットワーク、単一テナンシー] をクリックします。
- [ネットワーキング] をクリックして、次の変更を行います。
- ネットワーク:
lb-network
- サブネット:
lb-subnet
- ネットワーク タグ:
allow-ssh
とallow-health-check
- ネットワーク:
- [管理] をクリックします。[起動スクリプト] フィールドに、次のスクリプトの内容をコピーして貼り付けます。
#! /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
- [ネットワーキング] をクリックして、次の変更を行います。
- [作成] をクリックします。
マネージド インスタンス グループ
- Google Cloud Platform Console の [VM インスタンス] ページに移動します。
VM インスタンス グループのページに移動 - [インスタンス グループを作成] をクリックします。
- [名前] を
ig-ilb
に設定します。 - [ロケーション] で [マルチゾーン] を選択し、[リージョン] を
us-west1
に設定します。 - [インスタンス テンプレート] を
template-vm-ilb
に設定します。 - (省略可)自動スケーリングを設定します。インスタンス グループは内部 TCP / UDP 負荷分散のバックエンドであるため、HTTP 負荷分散の使用に基づいたインスタンス グループの自動スケーリングはできません。
- [インスタンスの最小数] を
1
、[インスタンスの最大数] を6
にそれぞれ設定します。 - (省略可)自動スケーリングを設定します。自動修復を構成する場合、内部 TCP / UDP ロードバランサのバックエンド サービスで使用されるのと同じヘルスチェックを使用します。この例では、
hc-http-80
.を使用します。 - [作成] をクリックします。
gcloud
インスタンス テンプレートを作成します。必要に応じて、その他のパラメータを設定します。たとえば、イメージ テンプレートには、マシンタイプを設定します。
gcloud compute instance-templates create template-vm-ilb \ --image-family=debian-9 \ --image-project=debian-cloud \ --tags=allow-ssh,allow-health-check \ --subnet=lb-subnet \ --region=us-west1 \ --network=lb-network \ --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'
次のテンプレートを使用して、リージョンのマネージド インスタンス グループを 1 つ作成します。
gcloud compute instance-groups managed create ig-ilb \ --template=template-vm-ilb \ --region=us-west1 \ --size=6
リージョンのマネージド インスタンス グループをバックエンドとして作成済みのバックエンド サービスに追加します。
gcloud compute backend-services add-backend be-ilb \ --region=us-west1 \ --instance-group=ig-ilb \ --instance-group-region=us-west1
ゾーンの 2 つの非マネージド インスタンス グループをバックエンド サービスから切断します。
gcloud compute backend-services remove-backend be-ilb \ --region=us-west1 \ --instance-group=ig-a \ --instance-group-zone=us-west1-a gcloud compute backend-services remove-backend be-ilb \ --region=us-west1 \ --instance-group=ig-c \ --instance-group-zone=us-west1-c
バックエンド VM から外部 IP アドレスを削除する
バックエンド VM を作成したときに、起動スクリプトを介して Apache をダウンロードできるように、それぞれにエフェメラル外部 IP アドレスが割り当てられました。バックエンド VM は内部ロードバランサのみで使用されるため、外部 IP アドレスは削除できます。外部 IP アドレスを削除すると、バックエンド VM から直接インターネットにアクセスできなくなります。
Console
- Google Cloud Platform Console の [VM インスタンス] ページに移動します。
[VM インスタンス] ページに移動 - 各バックエンド VM に対して以下の手順を繰り返します。
- バックエンド VM の名前をクリックします。たとえば、
vm-a1
をクリックすると、VM インスタンスの詳細ページが表示されます。 - [編集] をクリックします。
- [ネットワーク インターフェース] セクションで、[編集] ボタンをクリックします。
- [外部 IP] ポップアップで [なし] を選択して、[完了] をクリックします。
- [保存] をクリックします。
gcloud
インスタンスのゾーンを検索する。 たとえば、リージョンのマネージド インスタンス グループを使用している場合、インスタンスごとに次のコマンドを実行してゾーンを判別します。
[SERVER-VM]
を検索する VM の名前に置き換えます。gcloud compute instances list --filter="name=[SERVER-VM]"
各バックエンド VM に対して次の手順を繰り返します。
[SERVER-VM]
を VM の名前、[ZONE]
を VM のゾーンにそれぞれ置き換えます。gcloud compute instances delete-access-config [SERVER-VM] \ --zone=[ZONE] \ --access-config-name=external-nat
api
各バックエンド VM の instances.deleteAccessConfig
メソッドに POST
リクエストを送信します。vm-a1
は VM の名前、us-west1-a
は VM のゾーンにそれぞれ置き換えます
POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-west1-a/instances/v1-a1/deleteAccessConfig?accessConfig=external-nat&networkInterface=None
複数のポートでトラフィックを受信する
受信トラフィックのポートを制御するコンポーネントは内部転送ルールです。この手順では、ポート 80 の転送ルールをポート 80 とポート 443 でトラフィックを受け入れるルールに置き換えます。バックエンド VM を作成すると、Apache をインストールして設定する起動スクリプトもポート 443 で HTTPS トラフィックを処理するように設定されます。GCP では転送ルールの更新がサポートされていないため、転送ルールを置き換える必要があります。
gcloud
既存の転送ルール
fr-ilb
を削除してください。gcloud compute forwarding-rules delete fr-ilb \ --region=us-west1
ポート 80 と 443 に同じ名前の置換転送ルールを作成します。IP アドレスとバックエンド サービスを含む、このルールのその他のパラメータは同じです。
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,443 \ --backend-service=be-ilb \ --backend-service-region=us-west1
クライアント VM インスタンスに接続し、HTTP 接続と HTTPS 接続をテストします。
クライアント VM に接続します。
gcloud compute ssh vm-client --zone=us-west1-a
HTTP 接続をテストします。
curl http://10.1.2.99
HTTPS 接続をテストします。サンプルの設定の Apache サーバー構成では自己署名証明書を使用するため、
--insecure
フラグが必要です。curl https://10.1.2.99 --insecure
HTTP 要求(ポート 80)と HTTPS 要求(ポート 443)がすべてのバックエンド VM で処理されることを確認します。
セッションア フィニティの使用
構成例では、バックエンド サービスをセッション アフィニティなしで作成しています。
この手順では、クライアント IP アドレスに基づいてセッション アフィニティを使用するように、内部 TCP / UDP ロードバランサのバックエンド サービスを更新する方法を示します。
クライアントの IP アドレスとロードバランサの IP アドレス(内部転送ルールの内部 IP アドレス)から作成されたハッシュに基づいて、特定のクライアントのリクエストが同じバックエンド VM に転送されます。
Console
- Google Cloud Platform Console の [負荷分散] ページに移動します。
[負荷分散] ページに移動 - [be-ilb](この例で作成したバックエンド サービスの名前)をクリックし、[編集] をクリックします。
- 内部ロードバランサの編集ページで、バックエンド設定をクリックします。
- [セッション アフィニティ] ポップアップ メニューからクライアント IP を選択します。
- [更新] をクリックします。
gcloud
クライアント IP セッション アフィニティを指定して、be-ilb
バックエンド サービスを更新するには、次の gcloud
コマンドを使用します。
gcloud compute backend-services update be-ilb \ --session-affinity CLIENT_IP
api
regionBackendServices/patch
メソッドに PATCH
リクエストを送信します。
PATCH https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/us-west1/backendServices/be-ilb
{
"sessionAffinity": "CLIENT_IP"
}
トラフィック分散に影響するセッション アフィニティと各オプションの詳細については、トラフィック分散をご覧ください。
別のサブネットで転送ルールを作成する
この手順では、1 つの内部 TCP / UDP ロードバランサに対して複数の転送ルールを作成できることを示すために、2 つ目の IP アドレスと転送ルールを別のサブネットに作成します。転送ルールのリージョンは、バックエンド サービスのリージョンと一致する必要があります。
ファイアウォール ルールに従うと、リージョン内のサブネット内のクライアントは、内部 TCP / UDP ロードバランサの IP アドレスに接続できます。
us-west1
リージョン内のlb-network
ネットワークに 2 つ目のサブネットを作成します。gcloud compute networks subnets create second-subnet \ --network=lb-network \ --range=10.5.6.0/24 \ --region=us-west1
ポート 80 と 443 に 2 つ目の転送ルールを作成します。IP アドレスやバックエンド サービスなど、このルールのその他のパラメータは、プライマリ転送ルール
fr-ilb
と同じです。gcloud compute forwarding-rules create fr-ilb-2 \ --region=us-west1 \ --load-balancing-scheme=internal \ --network=lb-network \ --subnet=second-subnet \ --address=10.5.6.99 \ --ip-protocol=TCP \ --ports=80,443 \ --backend-service=be-ilb \ --backend-service-region=us-west1
クライアント VM インスタンスに接続し、IP アドレスへの HTTP 接続と HTTPS 接続をテストします。
- クライアント VM に接続します。
gcloud compute ssh vm-client --zone=us-west1-a
- IP アドレスへの HTTP 接続をテストします。
curl http://10.1.2.99 curl http://10.5.6.99
- HTTPS 接続をテストします。サンプル設定の Apache サーバー構成では自己署名証明書を使用するため、
--insecure
を使用する必要があります。
curl https://10.1.2.99 --insecure curl https://10.5.6.99 --insecure
- リクエストは、使用されているプロトコル(HTTP または HTTPS)や IP アドレスに関係なく、すべてのバックエンド VM で処理されることを確認してください。
次のステップ
- 基礎知識については、内部 TCP / UDP 負荷分散のコンセプトをご覧ください。
- フェイルオーバーに関する重要な情報については、内部 TCP / UDP 負荷分散のフェイルオーバーのコンセプトをご覧ください。
- ロードバランサで使用できる DNS 名のオプションについては、内部負荷分散と DNS 名をご覧ください。
- 内部 TCP / UDP ロードバランサのフェイルオーバーの構成の手順と例について詳しくは、内部 TCP / UDP 負荷分散のフェイルオーバーの構成をご覧ください。
- 内部 TCP / UDP 負荷分散に関する Stackdriver のロギングとモニタリングの構成については、内部 TCP / UDP 負荷分散のロギングとモニタリングをご覧ください。
- VPC ネットワークに接続されたピア ネットワークから内部 TCP / UDP ロードバランサにアクセスする方法については、内部 TCP / UDP 負荷分散と接続ネットワークをご覧ください。
- 内部 TCP / UDP ロードバランサの問題のトラブル シューティング方法については、内部 TCP / UDP 負荷分散のトラブルシューティングをご覧ください。