- 概要
- 要件
- インストール
- インストール後
- クラスターの管理
- 監視とアラート機能
- 移行とアップグレード
- 製品固有の設定
- ベスト プラクティスとメンテナンス
- トラブルシューティング
- インストール時にサービスをトラブルシューティングする方法
- クラスターをアンインストールする方法
- オフライン成果物をクリーンアップしてディスク領域を改善する方法
- Redis データをクリアする方法
- Istio ログを有効化する方法
- ログを手動でクリーンアップする方法
- sf-logs バケットに保存されている古いログをクリーンアップする方法
- AI Center のストリーミング ログを無効化する方法
- 失敗した Automation Suite インストールをデバッグする方法
- アップグレード後に古いインストーラーからイメージを削除する方法
- Longhorn のスナップショットを自動的にクリーンアップする方法
- TX チェックサム オフロードを無効化する方法
- TLS 1.2 で弱い暗号に対処する方法
- RHEL 8.4 OS でオフライン インストールを実行できない
- バンドルのダウンロード中のエラー
- バイナリがないため、オフライン インストールが失敗する
- オフライン インストールでの証明書の問題
- Longhorn のセットアップ中に最初のインストールが失敗する
- SQL 接続文字列の検証エラー
- selinux iscsid モジュールの前提条件の確認が失敗する
- Azure ディスクが SSD としてマークされない
- 証明書の更新後のエラー
- OS のアップグレード後に Automation Suite が動作しない
- Automation Suite で Backlog_wait_time を 1 に設定する必要がある
- ワークロードの準備ができていないためボリュームをマウントできない
- インストールおよびアップグレード中に RKE2 が失敗する
- 管理ポータルのタイムアウト期間を設定する
- 基になるディレクトリ接続を更新する
- 移行後にログインできない
- 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).
- Alarm received for failed kerberos-tgt-update job
- SSPI Provider: Server not found in Kerberos database
- Login Failed for User <ADDOMAIN><aduser>. Reason: The Account Is Disabled.
- ArgoCD へのログインに失敗した
- サンドボックス イメージを取得できない
- ポッドが ArgoCD UI に表示されない
- Redis プローブの障害
- RKE2 サーバーの起動に失敗する
- UiPath 名前空間でシークレットが見つからない
- 初期インストール後、ArgoCD アプリが Progressing ステートになる
- MongoDB ポッドが CrashLoopBackOff になるか、削除後に PVC プロビジョニングの保留中になる
- Unexpected inconsistency; run fsck manually
- クラスターの復元後に MongoDB またはビジネス アプリケーションの機能が低下する
- self-heal-operator および sf-k8-utils リポジトリが見つからない
- クラスターの復元またはロールバック後にサービスが異常になる
- RabbitMQ ポッドが CrashLoopBackOff でスタックする
- Prometheus が CrashloopBackoff ステートにあり、メモリ不足 (OOM) エラーを伴う
- Ceph-rook のメトリックが監視ダッシュボードに表示されない
- プロキシ環境でポッドが FQDN と通信できない
- Automation Suite 診断ツールを使用する
- Automation Suite サポート バンドルを使用する
- ログを確認する
クラスター ノードを再舗装する
クラスター ノードの再舗装 (リハイドレート プロセスとも呼ばれます) は、次のシナリオで必要になる場合があります。
- ホストのオペレーティング システムまたはソフトウェアのパッチ アップグレードを実行する場合。
- セキュリティ ポリシーにより、クラスター内のノードを定期的にローテーションすることが要求されている場合。
- 組織で他のポリシー制限が課されている場合。
既にクラスターに属しているノードに対して直接メンテナンスを行うと、インストールされているソフトウェアやネットワーク・マネージャーに干渉し、クラスターが不安定になり、ダウンタイムが発生する場合があります。
これらの問題を回避するには、次の手順を実行してノードをローテーションします。
-
クラスターにノードを追加します。この手順で追加するノードにより、手順 2 で削除するノードがなくてもクラスターが正しく機能するようにする必要があります。
-
対象のノードをクラスターから削除します。
重要:ノードのメンテナンス操作を実行するには、新しいノードをクラスターに追加するための追加のハードウェア リソースを導入する必要があります。これにより、障害やクォーラム損失のリスクを防止し、クラスターの高可用性を維持します。クラスターに新しいノードが追加されたらすぐに、古いノードの削除に進むことができます。
New nodes (both server and agent) must meet the Automation Suite hardware requirement so that they can take the load from the nodes being removed. Ensure that the server nodes satisfy the quorum requirements while you perform the entire procedure.
削除されたノードにクラスターを再インストールしないでください。ノード削除プロセスによって残余ファイルが残されるため、そのノードは以降のインストールに使用できなくなる可能性があります。
クラスターのノードを追加または削除する方法の詳細については、以下をご覧ください。