- 概要
- 要件
- インストール
- インストール後
- クラスターの管理
- 監視とアラート機能
- 移行とアップグレード
- 製品固有の設定
- ベスト プラクティスとメンテナンス
- トラブルシューティング
- インストール時にサービスをトラブルシューティングする方法
- クラスターをアンインストールする方法
- オフライン成果物をクリーンアップしてディスク領域を改善する方法
- Redis データをクリアする方法
- Istio ログを有効化する方法
- ログを手動でクリーンアップする方法
- sf-logs バンドルに保存されている古いログをクリーンアップする方法
- AI Center のストリーミング ログを無効化する方法
- 失敗した Automation Suite インストールをデバッグする方法
- アップグレード後に古いインストーラーからイメージを削除する方法
- Longhorn のスナップショットを自動的にクリーンアップする方法
- TX チェックサム オフロードを無効化する方法
- ArgoCD のログ レベルを手動で Info に設定する方法
- 外部レジストリーのエンコードされたpull_secret_valueを生成する方法
- TLS 1.2 で弱い暗号に対処する方法
- RHEL 8.4 OS でオフライン インストールを実行できない
- バンドルのダウンロード中のエラー
- バイナリがないため、オフライン インストールが失敗する
- オフライン インストールでの証明書の問題
- Longhorn のセットアップ中に最初のインストールが失敗する
- SQL 接続文字列の検証エラー
- selinux iscsid モジュールの前提条件の確認が失敗する
- Azure ディスクが SSD としてマークされない
- 証明書の更新後のエラー
- ウイルス対策が原因でインストールの問題が発生する
- OS のアップグレード後に Automation Suite が動作しない
- Automation Suite で backlog_wait_time を 0 に設定する必要がある
- リソースが利用できないことの影響を受ける GPU ノード
- ワークロードの準備ができていないためボリュームをマウントできない
- 管理ポータルのタイムアウト期間を設定する
- 基になるディレクトリ接続を更新する
- 移行後に認証が機能しない
- Kinit: Cannot find KDC for realm <AD Domain> while getting initial credentials
- kinit: Keytab contains no suitable keys for *** while getting initial credentials
- 無効なステータス コードが原因で GSSAPI 操作が失敗した
- Alarm received for failed kerberos-tgt-update job
- SSPI Provider: Server not found in Kerberos database
- アカウントが無効なため AD ユーザーのログインに失敗した
- ArgoCD へのログインに失敗した
- サンドボックス イメージを取得できない
- ポッドが ArgoCD UI に表示されない
- Redis プローブの障害
- RKE2 サーバーの起動に失敗する
- UiPath 名前空間でシークレットが見つからない
- 初回インストール後に ArgoCD が進行中ステートになる
- ArgoCD の読み取り専用アカウントにアクセスする際の問題
- MongoDB ポッドが CrashLoopBackOff になるか、削除後に PVC プロビジョニングの保留中になる
- クラスターの復元またはロールバック後にサービスが異常になる
- Init:0/X でポッドがスタックする
- Prometheus が CrashloopBackoff ステートにあり、メモリ不足 (OOM) エラーを伴う
- Ceph-rook のメトリックが監視ダッシュボードに表示されない
- Automation Suite 診断ツールを使用する
- Automation Suite サポート バンドル ツールを使用する
- ログを確認する
手順 3: デプロイ後の手順
\
を使用) をコピーして貼り付けようとすると、期待どおりに動作しない可能性があることに注意してください。改行が正しく解釈されるようにするには、コンソールのクリップボード ウィジェットを使用します。
installResult
というコンテナー内の自動生成ファイルの内容が successful
である場合、インストールは完了しています。インストールに失敗した場合は、failed
という内容になります。
インストール プロセスによって、ユーザーに代わって自己署名証明書が生成されます。これらの証明書は、FIPS 140-2 に対応しています。Azure のデプロイ テンプレートには、自動生成された自己署名証明書を使用する代わりに、CA によって発行されたサーバー証明書をインストール時に指定するオプションもあります。
自己署名証明書は 90 日で有効期限が切れるので、インストールが完了したら速やかに、信頼された CA によって署名された証明書に置き換える必要があります。証明書を更新しないと、90 日後にインストールが停止します。
Automation Suite を FIPS 140-2 が有効化されたホストにインストールした後で証明書を更新する場合は、その証明書が FIPS 140-2 に対応していることを確認してください。
手順については、「証明書を管理する」をご覧ください。
Azure のデプロイ テンプレートを使用して Automation Suite のインストールが完了したら、お使いのマシンで FIPS 140-2 を有効化できます。手順については、「セキュリティとコンプライアンス」をご覧ください。
Automation Suite のインストール プロセスやその他の操作に関する詳細情報が必要な場合はまずは、クラスターのデプロイおよびメンテナンス時にさまざまなフラグやログを保存するために使用されるストレージ アカウントを確認することをお勧めします。
ストレージ アカウントを見つけるには、次の手順に従います。
フラグ コンテナーには、管理または単純にさまざまな操作のステータスを報告するために必要な必要ないろいろなフラグまたはファイルを格納します。新しいクラスターでは、flags コンテナーの内容は通常次の例のように表示されます。
フラグ コンテナー内のファイルは、クラスター上の Automation Suite のインストール プロセスや、インスタンスの更新などの特定のクラスター操作などのさまざまな操作を管理するために使用されます。たとえば、次のとおりです。
uipath-server-000000.success
は、クラスターの特定のノードでのインフラストラクチャのインストールが正常に完了しことを示します。installResult
は、インストール全体が成功するとsuccess
を読み取ります。
通常、操作の実行時には、logs コンテナー内にログ ファイルが生成されます。新規クラスター上では、ログ コンテナーの内容は、通常、次の例のように表示されます。
logs コンテナー内のすべてのファイルは、インストール プロセスの特定の手順のログを表します。以下に例を示します。
infra-uipath-server-000000.log
は、インフラストラクチャのインストール ログを保存します。fabric.log
は、ファブリックのインストールに関するログを保存します。services.log
は、アプリケーションとサービスのインストールに関するログが保存されます。
インストールが完了したら、[出力] タブのデプロイの出力にアクセスする必要があります。
DateTime
など) → [出力] に移動します。
出力 |
説明 |
---|---|
ドキュメント |
ドキュメントへのリンク。 |
URL |
ロード バランサーの URL。直接アクセスに使用できます。 カスタム ドメインが有効だった場合は、このドメインを CNAME バインドに使用します。 |
KeyVaultURL |
デプロイによって作成された Key Vault の Azure Portal URL。デプロイで使用されるすべてのシークレット (資格情報) が含まれます。 |
ArgoCDURL |
ArgoCD にアクセスするための URL。これは VNet 内で利用可能です。この URL への外部アクセスは、「手順 4: DNS を構成する」に示すように設定する必要があります。 |
ArgoCDPassword |
ArgoCD ポータルにログインするために使用するパスワードです。 |
HostAdminUsername および HostAdminPassword |
ホスト管理に使用する資格情報。 |
ClusterAdministrationURL | |
LonghornMonitoringURL | Longhorn 監視ツールの URLです。 |
GrafanaMonitoringURL | Grafana 監視ツールの URL です。 |
PrometheusMonitoringURL | Prometheus 監視ツールの URL です。 |
AlertmanagerMonitoringURL | Alertmanager 監視ツールの URL です。 |
デプロイで使用されるすべての資格情報は、デプロイ時にプロビジョニングされた Key Vault 内にシークレットとして保存されます。シークレットにアクセスするには、リソース グループ内のリソースをフィルター処理し、Vault を検索して、[シークレット] をクリックします。
The operation “List” is not enabled in the key vault’s access policy
」という警告が表示された場合は、次の手順を実行します。
- [アクセス ポリシー] → [アクセス ポリシーの追加] → [テンプレートからの構成] → [シークレットの管理] → [プリンシパルの選択] に移動します。
- ユーザーを選択し、[保存]をクリックします。
- [シークレット] に戻ります。警告が消え、シークレットが表示されるはずです。
「手順 1: Azure のデプロイを計画する」で説明したように、Automation Suite の Azure デプロイにより、パブリック IP と DNS ラベルが関連付けられたロード バランサーが作成されます。この DNS ラベルは Microsoft が所有します。
デプロイでは、さらに、クラスター VNet 内でプライベート DNS ゾーンがプロビジョニングされ、インストールおよび構成プロセスで使用されるいくつかのレコードも追加されます。
外部マシンから接続する場合、プライベート DNS ゾーンを使用してさまざまなサービスの DNS を解決することはできないため、これらのレコードを自身のホスト ファイルに追加する必要があります。
詳細については、「手順 4: DNS を構成する」をご覧ください。
これで、クラスター上で実行されるさまざまなサービスに接続できるようになります。
Cluster Administration ポータルには、Automation Suite のインストールを完了したり、インストール後の一般的な操作を実行したりするために必要なすべてのリソースが一元化されています。詳しくは、「Cluster Administration ポータルの利用を開始する」をご覧ください。
Cluster Administration ポータルにアクセスするには、次の手順に従います。
https://${CONFIG_CLUSTER_FQDN}/uipath-management
に移動します。一般的な用途での Automation Suite ユーザー インターフェイスは、組織の管理者とユーザーの両方に対するポータルとして機能します。これは、誰もがすべての Automation Suite 領域 (管理ページ、プラットフォーム レベルのページ、サービス固有ページ、およびユーザー固有ページ) にアクセスできる、組織レベルの共通リソースです。
Automation Suite にアクセスするには、次の手順に従います。
- URL:
https://${Loadbalancer_dns}
(<loadbalancer_dns>
は、ロード バランサーの DNS ラベルであり、出力の下にあります) に移動します。 - 既定の組織に切り替えます。
- ユーザー名は orgadmin です。
- [Key Vault] から [シークレット]、[ホスト管理者のパスワード] に進み、パスワードを取得します。
システム管理者は、ホスト ポータルで Automation Suite インスタンスを構成します。このポータルから構成した設定は、組織全体に継承され、一部は組織レベルで上書きできます。
ホスト管理にアクセスするには、次の手順に従います。
- URL:
https://${Loadbalancer_dns}
(<loadbalancer_dns>
は、ロード バランサーの DNS ラベルであり、[出力] の下にあります) に移動します。 - Host 組織に切り替えます。
- 以前に [UiPath 管理者のユーザー名] パラメーターの値として指定したユーザー名を入力します。
- 以前に [UiPath 管理者のパスワード] パラメーターの値として指定したパスワードを入力します。[Key Vault] から [シークレット]、[ホスト管理者のパスワード] に進み、パスワードを取得します。
ArgoCD コンソールを使用して、インストールした製品を管理できます。
ArgoCD にアクセスするには、次の手順に従います。
- URL:
https://alm.${Loadbalancer_dns}
(<loadbalancer_dns>
は、ロード バランサーの DNS ラベルであり、[出力] の下にあります) に移動します。この URL への外部アクセスは、「手順 4: DNS を構成する」に示すように設定する必要があることに注意してください。 - ユーザー名は admin です。
- パスワードにアクセスするには、[出力] タブ、または資格情報 Key Vault に移動します。
監視ツールに初めてアクセスする場合、管理者として次の既定の資格情報でログインします。
- ユーザー名: admin
- パスワード: パスワードを取得するには、
次のコマンドを実行
します。
kubectl get secrets/dex-static-credential -n uipath-auth -o "jsonpath={.data['password']}" | base64 -d
kubectl get secrets/dex-static-credential -n uipath-auth -o "jsonpath={.data['password']}" | base64 -d
監視ツールへのアクセスに使用する既定のパスワードを更新するには、次の手順を実行します。
-
newpassword
を新しいパスワードに置き換えて、次のコマンドを実行します。password="newpassword" password=$(echo -n $password | base64) kubectl patch secret dex-static-credential -n uipath-auth --type='json' -p="[{'op': 'replace', 'path': '/data/password', 'value': '$password'}]"
password="newpassword" password=$(echo -n $password | base64) kubectl patch secret dex-static-credential -n uipath-auth --type='json' -p="[{'op': 'replace', 'path': '/data/password', 'value': '$password'}]" -
<cluster_config.json>
を構成ファイルのパスに置き換えて、次のコマンドを実行します。/opt/UiPathAutomationSuite/UiPath_Installer/install-uipath.sh -i <cluster_config.json> -f -o output.json --accept-license-agreement
/opt/UiPathAutomationSuite/UiPath_Installer/install-uipath.sh -i <cluster_config.json> -f -o output.json --accept-license-agreement
デプロイからプロビジョニングされた計算リソースは、スケーリングを容易にする Azure スケール セットで構成されます。
サーバー ノード、エージェント ノード、特殊なエージェント ノード (GPU ノードなど) の追加など、特定のスケール セットに手動でリソースを追加することができます。
特定のスケール セットを指定することにより手動でスケーリングを実行し、直接リソースを追加できます。
そのためには、以下の手順に従ってください。
Automation Suite クラスターのアップグレード後、新しいノードがクラスターに正常に参加できるように、Azure テンプレートのデプロイにいくつかの変更を加える必要があります。これらの変更操作を自動化するには、専用のスクリプトを使用することをお勧めします。手順については、こちらをご覧ください。
Azure では、シャットダウンの準備をするために最大で 15 分の時間枠が許可されていますが、Automation Suite ノードの正常終了にかかる時間は、20 分 (エージェント ノードおよび GPU エージェント ノードの場合) から数時間 (サーバー ノードの場合) まで幅があります。
データ損失を避けるために、サーバーの VMSS アップグレード ポリシーを手動に設定し、サーバー仮想マシンでスケール セット アクションからの保護を有効化します。そのため、提供されている Runbook を使用してサーバーのライフサイクルを管理することをお勧めします。
InstanceRefresh、RemoveNodes、RemoveServers、CheckServerZoneResilience の Runbook は、マルチノードの高可用性対応の運用環境のデプロイでのみサポートされます。
Runbook の実行後のサーバーの数は、奇数かつ 3 より大きくする必要があります (たとえば、サーバーが 4 つの場合はインスタンスの更新を実行できません。合計で 5 つの場合はサーバーを削除できません)。
Running
である必要があります。
一度に実行する Runbook は 1 つだけにする必要があります。
すべてのストレージ アカウントと SQL Server には、プライベート エンドポイントがあります。ハイブリッド ワーカー グループは、既存の自動化された操作を実行し、問題なく動作するようにします。
Hybrid Worker とは、VNET 内に存在し、さまざまなオートメーションが実行される仮想マシンです。
仮想マシンは通常、Standard_D2s_v3 または Standard_F2s_v2です。これは、サーバー仮想マシンにどれを選択するか、およびクォータが許可されているかどうかに応じて異なります。コストを最小限に抑えるために、デプロイが完了すると仮想マシンはシャットダウンされます。
Runbook は、通常の Runbook とハイブリッド Runbook の 2 つのカテゴリに分かれています。処理の開始やすべてのデータの収集には通常の Runbook を使用します。その後、通常の Runbook は Hybrid Worker 仮想マシンとハイブリッド Runbook を開始し、後者によって処理が完了します。
処理が完了したら、Hybrid Worker 仮想マシンをオフにしてコストを制限できます。
次の表で、Runbook の内訳を示します。
通常の Runbook |
ハイブリッド Runbook |
---|---|
AddGpuNode | HybridAddGpuNode |
BackupCluster | HybridBackupCluster |
GetAllBackups | HybridGetAllBackups |
InstanceRefresh | HybridInstanceRefresh (+HybridCheckServerZoneRezilience) |
RegisterAiCenterExternalOrchestrator | HybridRegisterAiCenterExternalOrchestrator |
RemoveNodes | HybridRemoveNodes |
RemoveServers | HybridRemoveServers |
RestoreClusterInitialize | HybridRestoreClusterInitialize + HybridRestoreClusterSnapshot |
ValidateFullInstall | デプロイの最後に実行され、完全なインストールを検証します。 |
説明
InstanceRefresh Runbook のユース ケースは次のとおりです。
- サーバー、エージェント、GPU スケール セット上で VMSS OS SKU を更新します。
- 1 つ以上の VMSS に対してノード ローテーション操作を実行します。
- あらかじめ VMSS に適用されていたその他の VMSS 構成変更。
使用状況
実装の詳細
InstanceRefresh Runbook は、RemoveNodes Runbook のラッパーです。その結果、RemoveNodes の実行中にステータスが追跡されます。これはすべての VMSS OS バージョンを (必要に応じて) 更新し、受け取ったパラメーターに基づいてノード ローテーション操作のホスト名を抽出して、RemoveNodes に転送します。クラスターに正確に 3 つのサーバーが存在する場合、InstanceRefresh Runbook は 3 つの新しいサーバーを作成します。それ以外の場合、RemoveNodes は、各可用性ゾーン内にサーバーを常に少なくとも 1 つ維持するためにスケールアップを処理します。
説明
RemoveNodes Runbook のユース ケースは次のとおりです。
- 指定したノードを Automation Suite クラスターから削除します。
- 1 つまたは 2 つの VM に対してノード ローテーション操作を実行します。
使用状況
NODESTOBEREMOVEDCOMPUTERNAME
は、削除する仮想マシンのコンピューター名のコンマ区切りリストです (例:pxlqw-agent-000009,pxlqw-agent-00000A
)。これは唯一の必須パラメーターです。一度に 1 つの VMSS からノードを削除することをお勧めします。-
ISINSTANCEREFRESH
およびTHREESERVERSSCENARIO
は、InstanceRefresh ラッパーによって設定されるフラグです。[OK] ボタンをクリックして Runbook を開始します。
実装の詳細
RemoveNodes Runbook には、3 時間のフェア シェア タイムアウトを克服するための再帰的なアプローチがあります。受信したリストから最初のノードまたは最初の 2 つのノード (この数字は、サーバー数の奇数制限を満たすために選択されます) を削除または再舗装し、Runbook の別のインスタンスを残りのリストで再実行します。
ノードに対してノード再舗装操作を実行するには、次の手順を実行する必要があります。
- 削除されるノードの数に基づいて、1 つまたは 2 つの仮想マシンを使用して VMSS をスケールアウトします。
- 古いインスタンスに対してノードの削除を実行します。
ノードに対してノード削除操作を実行するには、次の手順を実行する必要があります。
- インスタンスを遮断およびドレインします。この操作は、エージェントの場合は 20 分後、サーバーの場合は
number_of_instances * 60
分後にタイムアウトします。 - インスタンスの rke サービスを停止します。この操作は 5 分後にタイムアウトします。
- ノードを Automation Suite クラスターから削除し、VM を削除します。この操作は、エージェントの場合は 20 分後、サーバーの場合は
number_of_instances * 60
分後にタイムアウトします。
説明
RemoveServers Runbook のユース ケースは次のとおりです。
- サーバーを Automation Suite クラスターから削除する。
使用状況
- Azure Portal に移動し、RemoveServers というリソースを検索します。
- [開始] ボタンをクリックして、パラメーター リストを開きます。以下の点を考慮して、パラメーターを完成させます。
-
REMOVEDSERVERSCOUNT
は、削除されるサーバーの数です。フェア シェア タイムアウトに達しないように、一度に削除するサーバーは 2 台以下にすることをお勧めします。
実装の詳細
RemoveServers Runbook は、パラメーターとして受け取った数のサーバーを、仮想マシンが最も多い可用性ゾーンから削除します。
説明
CheckServerZoneResilience Runbook は、サーバーの VMSS をスケールアウトし、RemoveServers Runbook を使用してサーバーを可用性ゾーン間に分散します。これは InstanceRefresh フローの一部であり、手動で実行しないでください。
説明
初期デプロイを GPU ノードなしで作成したシナリオでは、仮想マシンスケール セットが作成されますが、ゾーン/SKU の可用性の問題を防ぐために異なる SKU が使用されます。この Runbook は、SKU を GPU SKU に変更し、ノードを追加します。
使用状況
この Runbook を使用するには、以下の手順に従います。
- Automation Suite をデプロイしたリソース グループに移動し、[Automation アカウント] を特定してクリックします。
- [Runbooks] をクリックしてから、[AddGPUNode] Runbook をクリックします。
- 必要な SKU の名前を入力して、[開始] をクリックします。
パラメーター:
skuName
– GPU ノード VMSS の SKU。
許容値:
Standard_NC8as_T4_v3
Standard_NC12s_v3
Standard_NC24s_v3
説明
この Runbook は、AI Center を、デプロイ時に指定された外部 Orchestrator に登録します。
使用状況
IdentityToken
が公開されます。このパラメーターは、外部の ID サービスによって生成されるインストール アクセス トークンです。トークンが利用可能な時間は短いので (約 1 ~ 2 時間)、Runbook を実行する直前にトークンを生成することをお勧めします。手順については、「インストール キー」をご覧ください。
説明
GetAllBackups Runbook では、利用可能なすべてのバックアップ (スケジュールされたバックアップと手動バックアップの両方) のリストを表示できます。
説明
これらの Runbook は、クラスターの復元を実行するのに役立ちます。
使用状況
復元操作を実行するには、次の手順に従います。
- 仮想マシンが Automation Suite クラスターに参加できない場合、ロールバックが試行されます。新たに作成された仮想マシンは、通常のノード削除と同じ手順に従います (遮断、ドレイン、rke サービスの停止、クラスターからのノードの削除、仮想マシンの削除)。参加ノードの手順のログは、ストレージ アカウント内の BLOB (
infra-<hostname>.log
など) 内の [logs] コンテナー内にあります。 -
ノードの削除中に障害が発生した場合、Runbook は停止し、失敗した手順のログが表示されます。問題を修正し、プロセスを手動で、または RemoveNodes Runbook を使用して完了します。ストレージ アカウントのログはすべて、次で示すように logs コンテナー内で確認できます。
- 遮断およびドレイン –
<timestamp>-<runbook_abreviation>-drain_nodes.log
- rke サービスの停止 –
<timestamp>-<runbook_abreviation>-stop_rke.log
- クラスターからノードを削除する –
<timestamp>-<runbook_abreviation>-remove_nodes.log
- 遮断およびドレイン –
- タイムアウトが発生する場合は、手順の実行が完了するまで待ってからログを確認し、手動で、または RemoveNodes Runbook を使用してプロセスを完了する必要があります。すべての Runbook は、Azure の実行コマンド機能を使用して、仮想マシンのコンテキスト内でコードを実行します。この方法の 1 つの制限は、実行のステータスが返されない点です。そのため、rke サービスの遮断、ドレイン、停止のステップは非同期に実行され、ステータスが BLOB に
<timestamp>-<runbook_abreviation>-<step_name>.<success/fail>
の形式で保持されます。
- インストールを検証する
- 証明書を更新する
- FIPS 140-2 を有効化する
- フラグとログを検索する
- flags コンテナー
- logs コンテナー
- デプロイの出力にアクセスする
- デプロイの出力
- クラスターの仮想マシンにアクセスする
- DNS の要件
- Cluster Administration ポータルにアクセスする
- Automation Suite の一般インターフェイスにアクセスする
- ホストの管理にアクセスする
- ArgoCD にアクセスする
- 監視ツールにアクセスする
- クラスターをスケーリングする
- アップグレードを完了する
- Azure VM のライフサイクル操作
- Hybrid Worker
- InstanceRefresh
- RemoveNodes
- RemoveServers
- CheckServerZoneResilience
- AddGpuNode
- RegisterAiCenterExternalOrchestrator
- BackupCluster
- GetAllBackups
- RestoreClusterInitialize、RestoreSnapshot
- トラブルシューティング