- 概要
- 要件
- インストール
- インストール後
- クラスターの管理
- 監視とアラート機能
- 移行とアップグレード
- 製品固有の設定
- ベスト プラクティスとメンテナンス
- トラブルシューティング
- 移行後にログインできない
- 管理ポータルのタイムアウト期間を設定する
- 基になるディレクトリ接続を更新する
- Kinit: Cannot Find KDC for Realm <AD Domain> While Getting Initial Credentials
- kinit: Keytab contains no suitable keys for *** while getting initial credentials
- GSSAPI operation failed with error: An invalid status code was supplied (Client's credentials have been revoked).
- Login Failed for User <ADDOMAIN><aduser>. Reason: The Account Is Disabled.
- Alarm received for failed kerberos-tgt-update job
- SSPI Provider: Server not found in Kerberos database
- Automation Suite 診断ツールを使用する
- Automation Suite サポート バンドルを使用する
- ログを確認する
Automation Suite インストール ガイド
マルチノードの高可用性対応の運用設定の場合、ロード バランサーは必須です。
Automation Suite では、この後のセクションで示すとおり、ロード バランサーに対して、2 種類の構成をサポートしています。
セッション永続性または固定セッションを使用するようにロード バランサーを構成することはできますが、要件ではありません。
現在、Automation Suite ではレイヤー 4 (ネットワーク レイヤー) のロード バランサーのみがサポートされています。
このロード バランサーは、TLS の暗号化と終端処理をサポートしていません。サービスを効果的に運用するには、必ず、トラフィックを容易にパススルーできるようにロード バランサーを構成してください。
デプロイに Azure 内部ロード バランサー (LB) を使用している場合は、バックエンド仮想マシン (VM) から LB フロントエンド IP への呼び出しで問題が発生する可能性があります。 この問題は、ネットワークパケットの送信元IPアドレスとMACアドレスの不一致が原因で発生します。 これにより、受信者が正しい応答パスを作成できなくなり、VM から LB へのコールが失敗します。 詳細については、「 Azure Load Balancer コンポーネントの 制限事項」と「 バックエンド トラフィックのトラブルシューティング」を参照してください。
以下に、ロード バランサーの推奨構成を示します。
バックエンド プールを構成する
次の要件を満たす 2 つのバックエンド プールを作成する必要があります。
-
サーバー プール
- すべてのサーバー ノードから構成されます。
- サーバー プール内には、エージェント ノードが存在してはなりません。
-
ノード プール
-
すべてのサーバー ノードとエージェント ノードから構成されます。
-
正常性プローブを構成する
|
プローブ |
プロトコル |
ポート |
間隔 |
再エントリしきい値 |
関連付けるプール |
|---|---|---|---|---|---|
|
|
TCP |
|
15 秒 |
2 |
ノード プール |
|
|
TCP |
|
15 秒 |
2 |
サーバー プール |
構成の詳細については、次の図をご覧ください。
ロード バランサーのポートを有効化する
ロード バランサーのソースに対するファイアウォールで、次のポートが有効化されていることを確認します。
|
ポート |
プロトコル |
目的 |
トラフィックの転送 |
正常性プローブ |
|---|---|---|---|---|
|
|
TCP |
HTTPS 用 (Automation Suite にアクセスする) |
このポートのトラフィックはノード プールに転送する必要があります。 |
|
|
|
TCP |
HTTPS を使用した Kube API へのアクセス用 (ノード参加に必要)。 |
このポートのトラフィックはサーバー プールに転送する必要があります。 |
|
|
|
TCP |
HTTPS を使用した Kube API へのアクセス用 (ノード参加に必要)。 |
このポートのトラフィックはサーバー プールに転送する必要があります。 |
|
HTTPS 以外のすべてのポートについては、クラスター外に公開しないことを推奨します。ファイアウォール/セキュリティ グループの背後でノードを実行します。
ネットワーク上にファイアウォールが設定されている場合、上記のポートが開かれ、トラフィックが許可されていることを確認します。
構成の詳細については、次の図をご覧ください。
この構成には、インストール中にダウンするノードに対する復元性がありません。
プライマリ サーバーがダウンしたり、削除されたりした場合、クラスターの構成を更新する必要があります。
プライマリ サーバーの FQDN を、クラスター内の利用可能な他のマシンに再マッピングする必要があります。
バックエンド プールを構成する
以下のとおり、バックエンド プールを 1 つ作成します。
- ノード プールを作成します。
ロード バランサーのポートを有効化する
ロード バランサーのソースに対するファイアウォールで、次のポートが有効化されていることを確認します。
|
ポート |
プロトコル |
目的 |
トラフィックの転送 |
|---|---|---|---|
|
|
TCP |
HTTPS 用 (Automation Suite にアクセスする)。 |
このポートのトラフィックはノード プールに転送する必要があります。 |
正常性プローブを構成する
|
プローブ |
プロトコル |
ポート |
間隔 |
再エントリしきい値 |
関連付けるプール |
|---|---|---|---|---|---|
|
|
TCP |
|
15 秒 |
2 |
ノード プール |
構成の詳細については、次の図をご覧ください。