- 概要
- 要件
- インストール
- インストール後
- クラスターの管理
- 監視とアラート機能
- 移行とアップグレード
- 製品固有の設定
- ベストプラクティスとメンテナンス
- トラブルシューティング
- 移行後にログインできない
- 管理ポータルのタイムアウト期間を設定する
- 基になるディレクトリ接続を更新する
- 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 クラスターにおけるエラー回復性と高可用性の実装方法によるものです。
次の表では、上記で紹介した用語を踏まえて、基本プロファイルと完全プロファイルのマルチノードの高可用性対応のハードウェア要件について説明します。
あらかじめ設定されたハードウェア構成 |
サーバー ノードの数 |
サーバー ノードのディスク サイズ |
クラスターの合計ディスク サイズ |
アプリケーションが利用可能なストレージ (オンライン) |
アプリケーションが使用可能なストレージ (オフライン) |
---|---|---|---|---|---|
3 |
512 GiB |
1.5 TiB |
41 GiB |
37 GiB | |
3 |
2 TiB |
6 TiB |
291 GiB |
286 GiB |
利用可能な 291 GiB のストレージを利用するには、PVC の値を、事前設定された 100 GB の値ではなく 291 GiB にサイズ変更する必要があります。そうしないと、アプリケーションは 100 GB を超える領域を利用できません。
手順については、「PVC のサイズを変更する」をご覧ください。
クラスターで製品を有効化して使用する際、アプリケーションが利用可能なストレージの一部が各製品によって使用されます。製品には通常、小さな有効化フットプリントと、ユース ケース、利用規模、プロジェクトによって異なる、使用状況に依存するフットプリントがあります。ストレージ消費は、すべてのストレージ リソース (データ ディスク) にわたって均等に分散され、Automation Suite の監視スタックを使用してストレージ使用率のレベルを監視できます。
Automation Suite クラスターでは、永続ボリュームと呼ばれる Kubernetes の内部的な概念を内部抽象化として使用し、それによってクラスター上のすべてのノードにまたがるディスクを表します。
不安定性を回避するために、監視とアラートを設定して、永続ボリュームの空き領域が、アプリケーションが利用可能なストレージの値を下回っているかどうかを常に確認することをお勧めします。詳細については、「永続ボリュームを監視する」をご覧ください。
アラートがトリガーされる場合は、次のセクションで説明するように、クラスターのストレージ容量を増やすことでアラートを軽減できます。
評価したニーズが推奨ハードウェア要件を満たさない場合は、次の方法の 1 つまたは両方を使用して、さらにストレージ容量を追加できます。
- ディスクを搭載したサーバー ノードを追加する。手順については、「クラスターに新しいノードを追加する」をご覧ください。
-
既存のノードにさらにディスクを追加する。手順については、「シングルノードの評価環境でのデータ ディスクの拡張について」、および「マルチノードの HA 対応運用環境でのデータ ディスクの拡張について」に関する説明をご覧ください。
重要: 必要な製品固有のストレージ 60 GiB ごとに、Automation Suite クラスターでは、クラスターで利用可能な合計ストレージに 1 TiB のストレージを追加し、サーバー ノード間に均等に分散する必要があります。
次の表に示す製品固有のメトリックを使用して、ストレージ使用量を推定できます。次の表は、入手時の状態のままのクラスターにコンテンツをどれだけ配置できるかを示しています。参考のために、各製品の一般的な使用シナリオのストレージ フットプリントも示しています。
基本の製品選択
製品 |
ストレージ駆動メトリック |
メトリックあたりのストレージ |
一般的なユース ケース |
---|---|---|---|
Orchestrator |
|
|
通常、パッケージは 5 MiB であり、バケット (ある場合) は 1 MiB 未満です。成熟した大企業では、5 GiB のパッケージと 6 GiB のバケットをデプロイしています。 |
Action Center |
|
|
通常、ドキュメントには 0.15 MiB、入力フォームには追加で 0.15 KiB が必要です。成熟した大企業では、これは合計 4 GiB に増える可能性があります。 |
Test Manager |
|
|
通常、すべてのファイルと添付ファイルの合計は最大で約 5 GiB です。 |
Insights |
|
|
有効化に 2 GiB が必要で、ストレージ フットプリントはこの数字に応じて増加します。大手企業規模のデプロイでは、すべてのダッシュボード用にさらに数 GiB が必要です。 |
Automation Hub |
N/A |
N/A |
2 GiB の固定フットプリント |
Automation Ops |
N/A |
N/A |
ストレージ フットプリントなし |
完全な製品選択
製品 |
ストレージ駆動メトリック |
メトリックあたりのストレージ |
一般的なユース ケース |
---|---|---|---|
Apps (アプリ) |
|
|
通常、データベースには約 5 GiB が必要で、一般的な複雑なアプリは約 15 MiB を消費します。 |
AI Center |
|
|
代表的な実証済みのインストールでは、5 つのパッケージに 8 GiB、データセットに追加で 1 GiB を消費します。 パイプラインが追加の 50 GiB を消費することがありますが、アクティブに実行されている場合だけです。 |
Document Understanding |
|
|
成熟したデプロイでは、12 GiB が ML モデルに、17 GiB が OCR に、50 GiB がすべての保存済みドキュメントに使用されます。 |
Task Mining |
|
|
通常、意味のある自動化を提案するには、約 200 GiB のアクティビティ ログ データを分析する必要があります。ただし、反復的な作業では、必要なデータは大幅に少なくなる場合があります。 |