Google Cloud – 内部ロードバランサーの使用

ここでは、トラフィックをアクティブノードにルーティングする内部ロードバランサーを作成して、Google Cloud の内部ロードバランサーを使用してノードを切り替える方法について説明します。クライアントは、内部ロードバランサーが提供するフロントエンド IP アドレスに接続します。内部ロードバランサーは、ユーザー定義の「ヘルスチェックプローブ」機能を使用してバックエンドプール内の各 VM の状態を定期的にチェックし、クライアントのリクエストをアクティブノードにルーティングします。

インスタンスグループを作成する

内部ロードバランサーを使用するには、まず各ノードを含むインスタンスグループを作成します。以下のパラメータを使用してインスタンスグループを作成します。

1. ナビゲーションメニューから [Compute Engine] > [Instance Group] を選択します。

2. 「CREATE INSTANCE GROUP」、「New Unmanaged instance group」を選択し、表にリストされているパラメーターを入力します。

3. 同じ手順に従って lk-ig02 を作成します。

4. これで、2つのインスタンスグループが作成されました。

内部ロードバランサーを作成する

内部ロードバランサーはトラフィックをアクティブノードに分散し、次の手順を使用して作成できます。ロードバランサーを構成するには、node-aでアプリケーションを起動します（LifeKeeperを使用して構成する前に、ロードバランサーが動作していることを確認します）。

1. ナビゲーションメニューで、[Network Service] > [Load Balancing] を選択します。

2. 「TCP負荷分散」の下の [構成を開始] をクリックします。

3. 「VM間のみ」（内部ロードバランサーを意味します）を選択し、「シングル リージョンのみ」を選択します。 [続行] をクリックします。

4. 名前をlk-lbと指定し、バックエンドパラメーターを構成します。[リージョン]、[ネットワーク] に lk-vpc を選択し、ドロップダウンメニューから2つのインスタンスグループ（lk-ig01 と lk-ig02）を選択して、バックエンドプールに追加します。

5. バックエンドの構成ページの下部にある「ヘルスチェック」に移動します。 [ヘルスチェックの作成] を選択します。

6. 名前は lk-health-check を選択し、[ポート] を選択して、 LB Health Check リソース が使用するポート（例：54321）を指定します。他のパラメーターを確認して、[保存して次へ] をクリックします。

7. 「フロントエンドの設定」タブに移動します。フロントエンドの名前とサブネットワークを指定します。この例では、lk-frontend という名前を使用して、lk-subnet サブネットワークを選択します。[IP アドレス] で[エフェメラル（カスタム）] を選択し、ロードバランサーのフロントエンドで使用するカスタムエフェメラル IP アドレスを指定します。この例では、IP アドレス10.20.0.10 を使用します。 [ポート] で、トラフィックがルーティングされるアプリケーションに基づいて、必要に応じて[単一]、[複数]、または [すべて] を選択し、必要なポートを入力します。この例では、TCP ポート 80 でトラフィックを転送します。

8. 「確認と完了」タブに移動し、[作成] をクリックします。

9. ロードバランサーが作成されると、ステータスが表示されます。アプリケーション（httpdなど）はこれらのノードの1つでのみ実行されるため、 アイコンが表示される場合がありますが、これは想定内です。

10. これで、内部ロードバランサーが設定されました。node-aに保護するアプリケーションをインストールすると、先ほど設定したILBのフロントエンドIP（10.20.0.10）を介してアプリケーションに接続できます。次の例では、ILB を介して現在のターゲットのhttpトラフィックを確認する方法を示しています。

IP 転送を無効にする

特定の構成では、内部ロードバランサーの異なるバックエンドサーバーでホストされている 2 つのアプリケーションが、ロードバランサー自体のフロントエンド IP を介して通信する必要がある場合があります。これはたとえば、内部ロードバランサを使用して SAP AS ABAP デプロイメントのASCS および ERS インスタンスのフローティング IP フェイルオーバーを管理する場合に発生します。

Google Cloud でのルートベースのロードバランサーの実装の結果として、ロードバランサーのバックエンドサーバーからロードバランサーのフロントエンドIPに送信されるトラフィックは、ロードバランサーのヘルスチェックで正常と見なされるかどうかにかかわらず、デフォルトで、その元となる同じバックエンドサーバーにルーティングされます。 詳細については、 内部 TCP / UDP 負荷分散のトラブルシューティング 「トラフィックが予期したとおりにバックエンド VM に送信されない」 のセクションを参照してください。

以下は、Google Cloud の VM で IP 転送を無効にする手順です。これにより、上記のバックエンド内トラフィックの問題も解決されます。これらの手順は、ロードバランサーのバックエンドターゲットとして追加されるすべての VM で実行する必要があります。

1. etc/default/instance_configs.cfg fileファイルの [NetworkInterfaces] セクションで ip_forwarding = false を設定します。

# vi /etc/default/instance_configs.cfg
# cat /etc/default/instance_configs.cfg
[...]
[NetworkInterfaces]
[...]
ip_forwarding = false
[...]

2. 変更が正常に保存されたら、VMを再起動して、変更を有効にします。
   

IP 転送が無効になっている場合、ロードバランサーのヘルスチェックに応答する LifeKeeper LB Health Check リソースには、ロードバランサーのフロントエンド IP アドレスを保護し、ネットマスク/ 32（255.255.255.255）を使用する子 IP リソースが必要です。この子 IP リソースがないと、LB Health Check リソースは In-Service になりません。これらのリソースの作成と LB Health Check リソースの依存関係としての追加の詳細については、 ロードバランサーのヘルスチェックに応答する の 「フロントエンド IP リソースの作成」 と 「LB Health Check リソースの依存関係としてのフロントエンド IP リソースの追加」 のセクションを参照してください。

ロードバランサーと対応するLB Health Checkリソース階層の正常な動作をテストする方法の詳細については、 ロードバランサーのヘルスチェックに応答する の 「LB Health Checkリソースのスイッチオーバーとフェイルオーバーのテスト」 のセクションを参照してください。