手順 6: ロード バランサーを構成する

Automation Suite のマルチノード高可用性対応の運用環境デプロイにおけるロード バランサーの要件と構成オプション。

概要

マルチノードの高可用性対応の運用設定の場合、ロード バランサーは必須です。

Azure Load Balancer などの一部のロード バランサーには、クライアントの IP アドレスを独自のアドレスに置き換えずにサーバーに転送する機能があります。この機能により、サーバーは元のクライアントの IP を確認できるため、サーバーがクライアントの IP アドレスを識別するための追加の手順は必要ありません。

一方、ロード バランサーがクライアントの IP アドレスを独自の IP アドレスに置き換える場合は、サーバーに送信する要求に x-forwarded-for ヘッダーと呼ばれる特別なヘッダーを追加することで補うことができます。このヘッダーには、元のクライアントの IP アドレスが含まれます。その後、サーバーはこのヘッダーを読み取って、クライアントの IP アドレスを取得できます。

Automation Suite では、この後のセクションで示すとおり、ロード バランサーに対して、2 種類の構成をサポートしています。

セッション永続性または固定セッションを使用するようにロード バランサーを構成することはできますが、要件ではありません。

注:

現在、Automation Suite ではレイヤー 4 (ネットワーク レイヤー) のロード バランサーがサポートされています。レイヤー 7 (アプリケーション レイヤー) ロード バランサーもサポートされています。詳しくは、「 L7 ロード バランサーを構成する (任意)」をご覧ください。

このロード バランサーは、TLS の暗号化と終端処理をサポートしていません。サービスを効果的に運用するには、必ず、トラフィックを容易にパススルーできるようにロード バランサーを構成してください。

デプロイに Azure Internal Load Balancer (LB) を使用している場合、バックエンド仮想マシン (VM) から LB フロントエンド IP への呼び出しで問題が発生する可能性があります。この問題は、ネットワーク パケットの送信元 IP アドレスと MAC アドレスの不一致が原因で発生します。

これにより、受信者が正しい応答パスを特定できなくなり、VM から LB への呼び出しが失敗します。詳しくは、「 Azure Load Balancer コンポーネント の制限事項」および 「バックエンド トラフィックのトラブルシューティング」をご覧ください。

サーバーとノード プールの構成

以下に、ロード バランサーの推奨構成を示します。

バックエンド プールを構成する

次の要件を満たす 3 つのバックエンド プールを作成する必要があります。

• サーバー プール
  • すべてのサーバー ノードから構成されます。
  • サーバー プール内には、エージェント ノードが存在してはなりません。
• ノード プール
  • すべてのサーバー ノードと特殊化されていないエージェント ノードから構成されます。特殊なエージェント ノードには、 gpuと asrobotsが含まれます。
• 一時レジストリ プール
  • 一時レジストリがインストールされているサーバー ノードのみで構成されます。
  注:

  一時レジストリ プールは、Automation Suite のインストール、ノード参加、およびアップグレードの手順でのみ使用されます。 手順を完了したら、一時レジストリ プールを閉じることができます。

正常性プローブを構成する

次の表で、ロード バランサーの正常性プローブの構成について説明します。

プローブ	プロトコル	ポート	間隔	再エントリしきい値	関連付けるプール
https-probe	TCP	443	15 秒	2	ノード プール
kubeapi-probe	TCP	6443	15 秒	2	サーバー プール

構成の詳細については、次の画像を参照してください。

ロード バランサーのポートを有効化する

ロード バランサーのソースに対するファイアウォールで、次のポートが有効化されていることを確認します。

ポート	プロトコル	目的	トラフィックの転送	正常性プローブ
443	TCP	HTTPS 用 (Automation Suite にアクセスする)。	このポートのトラフィックはノード プールに転送する必要があります。	https-probe
300701	TCP	HTTP を使用したインストールおよびアップグレード中に一時レジストリにアクセスするため。	このポートのトラフィックは一時レジストリ プールに転送する必要があります。	N/A
6443	TCP	HTTPS を使用した Kube API へのアクセス用 (ノード参加に必要)。	このポートのトラフィックはサーバー プールに転送する必要があります。	kubeapi-probe
9345	TCP	HTTPS を使用した Kube API へのアクセス用 (ノード参加に必要)。	このポートのトラフィックはサーバー プールに転送する必要があります。	kubeapi-probe

¹ 外部の OCI 準拠レジストリがない場合は、ロード・バランサーと、一時的な Docker レジストリをインストールする予定のサーバー・ノードでポート 30070 を開く必要があります。

注:

HTTPS 以外のすべてのポートについては、クラスター外に公開しないことを推奨します。ファイアウォール/セキュリティ グループの背後でノードを実行します。

ネットワーク上にファイアウォールが設定されている場合、上記のポートが開かれ、トラフィックが許可されていることを確認します。

通常のロード バランサーの構成は、次の図のいずれかのようになります。

代替構成

重要:

この構成には、インストール中にダウンするノードに対する復元性がありません。

プライマリ サーバーがダウンしたり、削除されたりした場合、クラスターの構成を更新する必要があります。

プライマリ サーバーの FQDN を、クラスター内の利用可能な他のマシンに再マッピングする必要があります。

バックエンド プールを構成する

以下のとおり、バックエンド プールを 1 つ作成します。

• ノード プールを作成します。

ロード バランサーのポートを有効化する

ロード バランサーのソースに対するファイアウォールで、次のポートが有効化されていることを確認します。

ポート	プロトコル	目的	トラフィックの転送
443	TCP	HTTPS 用 (Automation Suite にアクセスする)。	このポートのトラフィックはノード プールに転送する必要があります。

正常性プローブを構成する

次の表で、ロード バランサーの正常性プローブの構成について説明します。

プローブ	プロトコル	ポート	間隔	再エントリしきい値	関連付けるプール
https-probe	TCP	443	15 秒	2	ノード プール

構成の詳細については、次の画像を参照してください。