インストールの問題 ID 管理の問題 Storage スナップショットインフラストラクチャ仮想デスクトップの起動仮想デスクトップコンポーネント Env 削除デモ環境 Active Directory の問題

RunBooks の問題

次のセクションには、発生する可能性のある問題、検出方法、問題の解決方法に関する提案が含まれています。

インストールの問題
ID 管理の問題
Storage
スナップショット
- スナップショットのステータスが Failed である
- スナップショットは、テーブルをインポートできなかったことを示すログとともに適用されません。
インフラストラクチャ
- 正常なインスタンスがないロードバランサーターゲットグループ
仮想デスクトップの起動
仮想デスクトップコンポーネント
Env 削除
デモ環境
- ID プロバイダーへの認証リクエストを処理する際のデモ環境ログインエラー
- デモスタックのキークロークが機能しない
Active Directory の問題

インストールの問題

トピック

CloudFormationスタックはWaitCondition received failed message」というメッセージでを作成できません。Error:States.TaskFailed"
CloudFormationスタックが正常に作成された後に E メール通知が受信されない
インスタンスのサイクルまたは vdc-controller が失敗状態
環境 CloudFormation スタックが依存オブジェクトエラーにより削除に失敗する
環境の作成中に CIDR ブロックパラメータでエラーが発生しました
環境作成中の CloudFormation スタック作成の失敗
AdDomainAdminNode CREATE_FAILED で外部リソース (デモ) スタックの作成が失敗する

........................

CloudFormationスタックはWaitCondition received failed message」というメッセージでを作成できません。Error:States.TaskFailed"

問題を特定するには、という名前の Amazon CloudWatch ロググループを調べます<stack-name>-InstallerTasksCreateTaskDefCreateContainerLogGroup<nonce>-<nonce>。同じ名前のロググループが複数ある場合は、最初に使用できるロググループを調べます。ログ内のエラーメッセージには、問題に関する詳細情報が表示されます。

注記

パラメータ値にスペースがないことを確認します。

........................

CloudFormationスタックが正常に作成された後に E メール通知が受信されない

CloudFormationスタックが正常に作成された後に E メールの招待を受信しなかった場合は、以下を確認します。

E メールアドレスパラメータが正しく入力されたことを確認します。

E メールアドレスが正しくないか、アクセスできない場合は、Research and Engineering Studio 環境を削除して再デプロイします。
インスタンスのサイクルの証拠については、Amazon EC2 コンソールを確認してください。

<envname> プレフィックスが付いた Amazon EC2 インスタンスが終了済みとして表示され、新しいインスタンスに置き換えられる場合、ネットワークまたは Active Directory の設定に問題がある可能性があります。
AWSHigh Performance Compute レシピをデプロイして外部リソースを作成した場合は、VPC、プライベートサブネットとパブリックサブネット、およびその他の選択したパラメータがスタックによって作成されたことを確認します。

パラメータのいずれかが正しくない場合は、RES 環境を削除して再デプロイする必要がある場合があります。詳細については、「製品のアンインストール」を参照してください。
独自の外部リソースを使用して製品をデプロイした場合は、ネットワークと Active Directory が予想される設定と一致していることを確認します。

インフラストラクチャインスタンスが Active Directory に正常に参加したことを確認することが重要です。のステップを試インスタンスのサイクルまたは vdc-controller が失敗状態して問題を解決します。

........................

インスタンスのサイクルまたは vdc-controller が失敗状態

この問題の最も可能性の高い原因は、リソース (複数可) が Active Directory に接続または参加できないことです。

問題を検証するには:

コマンドラインから、vdc-controller の実行中のインスタンスで SSM とのセッションを開始します。
sudo su - を実行します。
systemctl status sssd を実行します。

ステータスが非アクティブ、失敗、またはログにエラーが表示される場合、インスタンスは Active Directory に参加できませんでした。

SSM エラーログ

問題を解決するには:

同じコマンドラインインスタンスから、 cat /root/bootstrap/logs/userdata.log を実行してログを調査します。

この問題には、3 つの根本原因のいずれかが考えられます。

ログを見直します。以下が複数回繰り返される場合、インスタンスは Active Directory に参加できませんでした。


+ local AD_AUTHORIZATION_ENTRY=
+ [[ -z '' ]]
+ [[ 0 -le 180 ]]
+ local SLEEP_TIME=34
+ log_info '(0 of 180) waiting for AD authorization, retrying in 34 seconds ...'
++ date '+%Y-%m-%d %H:%M:%S,%3N'
+ echo '[2024-01-16 22:02:19,802] [INFO] (0 of 180) waiting for AD authorization, retrying in 34 seconds ...'
[2024-01-16 22:02:19,802] [INFO] (0 of 180) waiting for AD authorization, retrying in 34 seconds ...
+ sleep 34
+ (( ATTEMPT_COUNT++ ))

RES スタックの作成中に以下のパラメータ値が正しく入力されたことを確認します。
- directoryservice.ldap_connection_uri
- directoryservice.ldap_base
- directoryservice.users.ou
- directoryservice.groups.ou
- directoryservice.sudoers.ou
- directoryservice.computers.ou
- directoryservice.name
DynamoDB テーブルの誤った値を更新します。テーブルは、テーブルの下の DynamoDB コンソールにあります。テーブル名はである必要があります<stack name>.cluster-settings。
テーブルを更新したら、現在環境インスタンスを実行している cluster-manager と vdc-controller を削除します。Auto Scaling は、DynamoDB テーブルの最新の値を使用して新しいインスタンスを開始します。

ログがを返す場合Insufficient permissions to modify computer account、スタックの作成時に入力した ServiceAccount 名が正しくない可能性があります。

AWSコンソールから Secrets Manager を開きます。
directoryserviceServiceAccountUsername を検索します。シークレットはである必要があります<stack name>-directoryservice-ServiceAccountUsername。
シークレットを開いて詳細ページを表示します。シークレット値 で、シークレット値の取得 を選択し、プレーンテキスト を選択します。
値が更新された場合は、環境の現在実行中の cluster-manager インスタンスと vdc-controller インスタンスを削除します。自動スケーリングは、Secrets Manager の最新値を使用して新しいインスタンスを起動します。

ログにと表示される場合Invalid credentials、スタックの作成時に入力した ServiceAccount パスワードが正しくない可能性があります。

AWSコンソールから Secrets Manager を開きます。
directoryserviceServiceAccountPassword を検索します。シークレットはである必要があります<stack name>-directoryservice-ServiceAccountPassword。
シークレットを開いて詳細ページを表示します。シークレット値 で、シークレット値の取得 を選択し、プレーンテキスト を選択します。
パスワードを忘れた場合、または入力したパスワードが正しいかどうかわからない場合は、Active Directory と Secrets Manager でパスワードをリセットできます。
1. でパスワードをリセットするにはAWS Managed Microsoft AD:
  1. AWSコンソールを開き、に移動しますDirectory Service。
  2. RES ディレクトリのディレクトリ ID を選択し、アクションを選択します。
  3. ユーザーパスワードのリセットを選択します。
  4. ServiceAccount ユーザー名を入力します。
  5. 新しいパスワードを入力し、パスワードのリセットを選択します。
2. Secrets Manager でパスワードをリセットするには:
  1. AWSコンソールを開き、Secrets Manager に移動します。
  2. directoryserviceServiceAccountPassword を検索します。シークレットはである必要があります<stack name>-directoryservice-ServiceAccountPassword。
  3. シークレットを開いて詳細ページを表示します。シークレット値 で、シークレット値の取得 を選択し、プレーンテキスト を選択します。
  4. [編集] を選択します。
  5. ServiceAccount ユーザーの新しいパスワードを設定し、保存を選択します。
値を更新した場合は、環境の現在実行中の cluster-manager インスタンスと vdc-controller インスタンスを削除します。Auto Scaling は、最新の値を使用して新しいインスタンスを開始します。

........................

環境 CloudFormation スタックが依存オブジェクトエラーにより削除に失敗する

などの依存オブジェクトエラーが原因で <env-name>-vdc CloudFormation スタックの削除が失敗した場合vdcdcvhostsecuritygroup、コンソールを使用してAWS RES が作成したサブネットまたはセキュリティグループに起動された Amazon EC2 インスタンスが原因である可能性があります。

この問題を解決するには、この方法で起動されたすべての Amazon EC2 インスタンスを検索して終了します。その後、環境の削除を再開できます。

........................

環境の作成中に CIDR ブロックパラメータでエラーが発生しました

環境を作成すると、レスポンスステータスが [FAILED] の CIDR ブロックパラメータにエラーが表示されます。

エラーの例:


Failed to update cluster prefix list: 
        An error occurred (InvalidParameterValue) when calling the ModifyManagedPrefixList operation: 
        The specified CIDR (52.94.133.132/24) is not valid. For example, specify a CIDR in the following form: 10.0.0.0/16.

この問題を解決するために想定される形式は x.x.x.0/24 または x.x.x.0/32 です。

........................

環境作成中の CloudFormation スタック作成の失敗

環境の作成には、一連のリソース作成オペレーションが含まれます。一部のリージョンでは、容量の問題が発生し、CloudFormation スタックの作成が失敗する可能性があります。

この場合、環境を削除し、作成を再試行します。または、別のリージョンで作成を再試行することもできます。

........................

AdDomainAdminNode CREATE_FAILED で外部リソース (デモ) スタックの作成が失敗する

デモ環境スタックの作成が次のエラーで失敗した場合、インスタンスの起動後のプロビジョニング中に Amazon EC2 パッチ適用が予期せず発生した可能性があります。


AdDomainAdminNode CREATE_FAILED  Failed to receive 1 resource signal(s) within the specified duration

失敗の原因を特定するには:

SSM ステートマネージャーで、パッチ適用が設定されているかどうか、およびすべてのインスタンスに設定されているかどうかを確認します。
SSM RunCommand/Automation の実行履歴で、パッチ適用関連の SSM ドキュメントの実行がインスタンスの起動と一致するかどうかを確認します。
環境の Amazon EC2 インスタンスのログファイルで、ローカルインスタンスのログ記録を確認して、プロビジョニング中にインスタンスが再起動したかどうかを確認します。

パッチ適用が原因で問題が発生した場合は、起動から少なくとも 15 分後に RES インスタンスのパッチ適用を遅らせます。

........................

ID 管理の問題

シングルサインオン (SSO) と ID 管理のほとんどの問題は、設定ミスが原因で発生します。SSO 設定の設定については、以下を参照してください。

ID 管理に関連するその他の問題をトラブルシューティングするには、以下のトラブルシューティングトピックを参照してください。

トピック

iam:PassRole を実行する権限がありません
自分の AWSアカウント以外のユーザーにAWSリソースの Research and Engineering Studio へのアクセスを許可したい
環境にログインすると、すぐにログインページに戻ります。
ログイン試行時の「ユーザーが見つかりません」エラー
Active Directory に追加されたが、RES にないユーザー
セッションの作成時に使用できないユーザー
CloudWatch クラスターマネージャーログのサイズ制限超過エラー

........................

iam:PassRole を実行する権限がありません

iam:PassRole アクションを実行する権限がないというエラーが表示された場合は、ポリシーを更新して RES にロールを渡すことができるようにする必要があります。

一部のAWSサービスでは、新しいサービスロールまたはサービスにリンクされたロールを作成する代わりに、そのサービスに既存のロールを渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。

次の例のエラーは、marymajor という名前の IAM ユーザーがコンソールを使用して RES でアクションを実行しようとすると発生します。ただし、このアクションをサービスが実行するには、サービスロールから付与されたアクセス許可が必要です。Mary には、ロールをサービスに渡すアクセス許可がありません。


User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole

この場合、Mary のポリシーを更新してメアリーに iam:PassRole アクションの実行を許可する必要があります。サポートが必要な場合は、AWS管理者にお問い合わせください。サインイン資格情報を提供した担当者が管理者です。

........................

自分の AWSアカウント以外のユーザーにAWSリソースの Research and Engineering Studio へのアクセスを許可したい

他のアカウントのユーザーや組織外の人が、リソースにアクセスするために使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。

詳細については、以下を参照してください:

所有しているAWSアカウント間でリソースへのアクセスを提供する方法については、IAM ユーザーガイドの「所有している別のAWSアカウントの IAM ユーザーへのアクセスを提供する」を参照してください。
サードパーティーAWSアカウントにリソースへのアクセスを提供する方法については、IAM ユーザーガイドの「サードパーティーが所有するAWSアカウントへのアクセスを提供する」を参照してください。
ID フェデレーションを通じてアクセスを提供する方法については、IAM ユーザーガイドの「外部で認証されたユーザー (ID フェデレーション) へのアクセスを提供する」を参照してください。
クロスアカウントアクセスにロールとリソースベースのポリシーを使用する方法の違いについては、IAM ユーザーガイドの「IAM ロールとリソースベースのポリシーの違い」を参照してください。

........................

この問題は、SSO 統合の設定が間違っている場合に発生します。問題を特定するには、コントローラーインスタンスログをチェックし、エラーがないか設定を確認します。

ログを確認するには:

CloudWatch コンソールを開きます。
ロググループから、という名前のグループを見つけます/<environment-name>/cluster-manager。
ロググループを開いて、ログストリームのエラーを検索します。

設定を確認するには:

DynamoDB コンソールを開く
テーブルから、という名前のテーブルを見つけます<environment-name>.cluster-settings。
テーブルを開き、Explore テーブル項目を選択します。
フィルターセクションを展開し、次の変数を入力します。
- 属性名 – キー
- 条件 – を含む
- 値 – sso
[Run] (実行) を選択します。
返された文字列で、SSO 設定値が正しいことを確認します。正しくない場合は、sso_enabled キーの値を False に変更します。
RES ユーザーインターフェイスに戻り、SSO を再設定します。

........................

ログイン試行時の「ユーザーが見つかりません」エラー

ユーザーが RES インターフェイスにログインしようとしたときに「ユーザーが見つかりません」というエラーが表示され、そのユーザーが Active Directory に存在する場合:

ユーザーが RES に存在せず、最近 AD にユーザーを追加した場合
- ユーザーがまだ RES に同期されていない可能性があります。RES は 1 時間ごとに同期するため、次の同期後にユーザーが追加されたことを待機して確認する必要がある場合があります。すぐに同期するには、「」の手順に従いますActive Directory に追加されたが、RES にないユーザー。
ユーザーが RES に存在する場合:
1. 属性マッピングが正しく設定されていることを確認します。詳細については、「シングルサインオン (SSO) 用の ID プロバイダーの設定」を参照してください。
2. SAML 件名と SAML E メールの両方がユーザーの E メールアドレスにマッピングされていることを確認します。

........................

Active Directory に追加されたが、RES にないユーザー

注記

このセクションは RES 2024.10 以前に適用されます。RES 2024.12 以降については、「」を参照してください同期を手動で実行する方法 (リリース 2024.12 および 2024.12.01)。RES 2025.03 以降については、「」を参照してください同期を手動で開始または停止する方法 (リリース 2025 年 3 月以降)。

ユーザーを Active Directory に追加しても RES にない場合は、AD 同期をトリガーする必要があります。AD 同期は、AD エントリを RES 環境にインポートする Lambda 関数によって 1 時間ごとに実行されます。場合によっては、新しいユーザーまたはグループを追加した後、次の同期プロセスが実行されるまで遅延することがあります。Amazon Simple Queue Service から手動で同期を開始できます。

同期プロセスを手動で開始します。

Amazon SQS コンソールを開きます。
キューから、を選択します<environment-name>-cluster-manager-tasks.fifo。
[メッセージの送信と受信] を選択します。
メッセージ本文には、次のように入力します。

{ "name": "adsync.sync-from-ad", "payload": {} }
メッセージグループ ID には、次のように入力します。 adsync.sync-from-ad
メッセージ重複排除 ID には、ランダムな英数字の文字列を入力します。このエントリは、過去 5 分以内に行われたすべての呼び出しとは異なる必要があります。そうしないと、リクエストは無視されます。

........................

セッションの作成時に使用できないユーザー

セッションを作成する管理者が、セッションの作成時に Active Directory に属しているユーザーが利用できない場合、ユーザーは初めてログインする必要がある場合があります。セッションはアクティブなユーザーに対してのみ作成できます。アクティブなユーザーは、少なくとも 1 回環境にログインする必要があります。

........................

CloudWatch クラスターマネージャーログのサイズ制限超過エラー


2023-10-31T18:03:12.942-07:00 ldap.SIZELIMIT_EXCEEDED: {'msgtype': 100, 'msgid': 11, 'result': 4, 'desc': 'Size limit exceeded', 'ctrls': []}

CloudWatch クラスターマネージャーログにこのエラーが表示された場合、ldap 検索が返したユーザーレコードが多すぎる可能性があります。この問題を修正するには、IDP の ldap 検索結果の制限を引き上げます。

........................

Storage

トピック

RES を使用してファイルシステムを作成しましたが、VDI ホストにマウントされません
RES を介してファイルシステムをオンボードしたが、VDI ホストにマウントされない
VDI ホストから読み書きできない
RES から Amazon FSx for NetApp ONTAP を作成しましたが、ドメインに参加していません

........................

RES を使用してファイルシステムを作成しましたが、VDI ホストにマウントされません

ファイルシステムは、VDI ホストでマウントする前に「使用可能」状態である必要があります。以下のステップに従って、ファイルシステムが必須状態であることを確認します。

Amazon EFS

Amazon EFS コンソールに移動します。
ファイルシステムの状態が使用可能であることを確認します。
ファイルシステムの状態が使用可能でない場合は、VDI ホストを起動する前に待ちます。

Amazon FSx ONTAP

Amazon FSx コンソールに移動します。
ステータスが使用可能であることを確認します。
Status が使用可能でない場合は、VDI ホストを起動するまで待ちます。

........................

RES を介してファイルシステムをオンボードしたが、VDI ホストにマウントされない

RES にオンボードされるファイルシステムには、VDI ホストがファイルシステムをマウントできるように、必要なセキュリティグループルールが設定されている必要があります。これらのファイルシステムは RES の外部で作成されるため、RES は関連するセキュリティグループルールを管理しません。

オンボードされたファイルシステムに関連付けられたセキュリティグループは、次のインバウンドトラフィックを許可する必要があります。

Linux " ホストからの NFS トラフィック (ポート: 2049)
Windows " ホストからの SMB トラフィック (ポート: 445)

........................

VDI ホストから読み書きできない

ONTAP は、ボリュームの UNIX、NTFS、MIXED セキュリティスタイルをサポートしています。セキュリティスタイルは、ONTAP がデータアクセスを制御するために使用するアクセス許可のタイプと、これらのアクセス許可を変更できるクライアントタイプを決定します。

たとえば、ボリュームが UNIX セキュリティスタイルを使用している場合でも、ONTAP のマルチプロトコル特性により、SMB クライアントは引き続きデータにアクセスできます (ただし、適切に認証および認可される場合に限ります）。ただし、ONTAP は UNIX クライアントのみがネイティブツールを使用して変更できる UNIX アクセス許可を使用します。

アクセス許可処理のユースケースの例

Linux ワークロードでの UNIX スタイルのボリュームの使用

アクセス許可は、他のユーザーの sudoer で設定できます。たとえば、次の例では、 /<project-name> ディレクトリに対する<group-ID>完全な読み取り/書き込みアクセス許可のすべてのメンバーに付与します。


sudo chown root:<group-ID> /<project-name>
sudo chmod 770 /<project-name>

Linux および Windows ワークロードでの NTFS スタイルのボリュームの使用

共有アクセス許可は、特定のフォルダの共有プロパティを使用して設定できます。たとえば、ユーザーuser_01とフォルダがある場合myfolder、Full Control、、Changeまたはのアクセス許可Readを Allowまたはに設定できますDeny。

共有アクセス許可は、フルコントロール、変更、または読み取りの許可または拒否に設定できます。

ボリュームを Linux クライアントと Windows クライアントの両方で使用する場合は、Linux ユーザー名を同じユーザー名に domain\username の NetBIOS ドメイン名形式に関連付ける名前マッピングを SVM に設定する必要があります。これは、Linux ユーザーと Windows ユーザーの間で変換するために必要です。リファレンスについては、「Amazon FSx for NetApp ONTAP によるマルチプロトコルワークロードの有効化」を参照してください。

........................

RES から Amazon FSx for NetApp ONTAP を作成しましたが、ドメインに参加していません

現在、RES コンソールから Amazon FSx for NetApp ONTAP を作成すると、ファイルシステムはプロビジョニングされますが、ドメインに参加しません。作成した ONTAP ファイルシステム SVM をドメインに結合するには、「Microsoft Active Directory SVMs の結合」を参照して、Amazon FSx コンソールの手順に従ってください。必要なアクセス許可が AD の Amazon FSx サービスアカウントに委任されていることを確認します。SVM がドメインに正常に参加したら、SVM 概要 > エンドポイント > SMB DNS 名に移動し、後で必要になるため DNS 名をコピーします。

ドメインに結合したら、クラスター設定 DynamoDB テーブルで SMB DNS 設定キーを編集します。

Amazon DynamoDB コンソールに移動します。
Tables を選択し、を選択します<stack-name>-cluster-settings。
「Explore table items」で、フィルタを展開し、次のフィルタを入力します。
- 属性名 - キー
- 条件 - に等しい
- 値 - shared-storage.<file-system-name>.fsx_netapp_ontap.svm.smb_dns
返された項目を選択し、次にアクション、編集項目を選択します。
以前にコピーした SMB DNS 名で値を更新します。
[保存して閉じる] を選択します。

さらに、ファイルシステムに関連付けられたセキュリティグループが、Amazon VPC によるファイルシステムアクセスコントロールで推奨されているトラフィックを許可していることを確認します。ファイルシステムを使用する新しい VDI ホストは、ドメインに参加している SVM とファイルシステムをマウントできるようになりました。

または、RES Onboard File System 機能を使用してドメインに既に参加している既存のファイルシステムをオンボードすることもできます。環境管理からファイルシステム、オンボードファイルシステムを選択します。

........................

スナップショット

トピック

スナップショットのステータスが Failed である
スナップショットは、テーブルをインポートできなかったことを示すログとともに適用されません。

........................

スナップショットのステータスが Failed である

RES スナップショットページで、スナップショットのステータスが Failed の場合、エラーが発生した時間、クラスターマネージャーの Amazon CloudWatch ロググループに移動することで原因を特定できます。


[2023-11-19 03:39:20,208] [INFO] [snapshots-service] creating snapshot in S3 Bucket:
  asdf at path s31
[2023-11-19 03:39:20,381] [ERROR] [snapshots-service] An error occurred while
  creating the snapshot: An error occurred (TableNotFoundException)
  when calling the UpdateContinuousBackups operation: 
  Table not found: res-demo.accounts.sequence-config

........................

スナップショットは、テーブルをインポートできなかったことを示すログとともに適用されません。

以前の env から取得したスナップショットが新しい env に適用されない場合は、クラスターマネージャーの CloudWatch ログを調べて問題を特定します。必要なテーブルクラウドがインポートされないことが問題で言及されている場合は、スナップショットが有効な状態であることを確認します。

metadata.json ファイルをダウンロードし、さまざまなテーブルの ExportStatus のステータスが COMPLETED であることを確認します。さまざまなテーブルに ExportManifestフィールドが設定されていることを確認します。上記のフィールドが設定されていない場合、スナップショットは無効な状態であり、スナップショットの適用機能では使用できません。
スナップショットの作成を開始したら、RES でスナップショットのステータスが COMPLETED になっていることを確認します。スナップショットの作成プロセスには最大 5～10 分かかります。スナップショット管理ページを再ロードまたは再アクセスして、スナップショットが正常に作成されたことを確認します。これにより、作成されたスナップショットが有効な状態になります。

........................

インフラストラクチャ

トピック

正常なインスタンスがないロードバランサーターゲットグループ

........................

正常なインスタンスがないロードバランサーターゲットグループ

サーバーエラーメッセージなどの問題が UI に表示されるか、デスクトップセッションが接続できない場合、インフラストラクチャの Amazon EC2 インスタンスに問題がある可能性があります。

問題の原因を特定する方法は、まず Amazon EC2 コンソールで、繰り返し終了し、新しいインスタンスに置き換えられていると思われる Amazon EC2 インスタンスがないかを確認することです。その場合は、Amazon CloudWatch logsをチェックして原因を特定できます。

もう 1 つの方法は、システム内のロードバランサーを確認することです。システムに問題がある可能性があることを示すのは、Amazon EC2 コンソールで見つかったロードバランサーに、登録された正常なインスタンスが表示されない場合です。

通常の外観の例を以下に示します。

Healthy エントリが 0 の場合、リクエストを処理できる Amazon EC2 インスタンスがないことを示します。

Unhealthy エントリが 0 以外の場合は、Amazon EC2 インスタンスが循環している可能性があります。これは、インストールされているアプリケーションソフトウェアがヘルスチェックに合格していないことが原因である可能性があります。

Healthy エントリと Unhealthy エントリの両方が 0 の場合、ネットワークの設定ミスの可能性を示します。たとえば、パブリックサブネットとプライベートサブネットには、対応する AZs がない場合があります。この状態が発生すると、ネットワーク状態が存在することを示す追加のテキストがコンソールに表示される場合があります。

........................

仮想デスクトップの起動

トピック

Windows Virtual Desktop のログインアカウントが管理者に設定されています
外部リソース CertificateRenewalNode を使用する場合、証明書の有効期限が切れます
以前に機能していた仮想デスクトップが正常に接続できなくなった
5 つの仮想デスクトップしか起動できない
デスクトップ Windows の接続試行は「接続が閉じられました。トランスポートエラー"
VDIsプロビジョニング状態でスタックする
起動後に VDIsがエラー状態になる
ログインすると、VDI セッションが空白の画面になります

........................

Windows Virtual Desktop のログインアカウントが管理者に設定されています

RES ウェブポータルで Windows Virtual Desktop を起動できるが、接続時にログインアカウントが管理者に設定されている場合、Windows VDI が Active Directory に正常に参加していない可能性があります。

確認するには、Amazon EC2 コンソールから Windows インスタンスに接続し、のブートストラップログを確認しますC:\Users\Administrator\RES\Bootstrap\virtual-desktop-host-windows\。で始まるエラーメッセージ[Join AD] authorization failed:は、インスタンスが AD に参加できなかったことを示します。障害の詳細については、ロググループ名で CloudWatch の Cluster Manager ログ/<res-environment-name>/cluster-managerを確認してください。

Insufficient permissions to modify computer account
- このエラーは、サービスアカウントに AD にコンピュータを追加する適切なアクセス許可がないことを示します。Microsoft Active Directory のサービスアカウントを設定する「」セクションで、サービスアカウントに必要なアクセス許可を確認してください。
Invalid Credentials
- AD のサービスアカウントの認証情報の有効期限が切れているか、誤った認証情報が指定されています。サービスアカウントの認証情報を確認または更新するには、Secrets Manager コンソールにパスワードを保存するシークレットにアクセスします。RES 環境の Identity Management ページの Active Directory Domain の Service Account Credentials Secret ARN フィールドで、このシークレットの ARN が正しいことを確認します。

........................

外部リソース CertificateRenewalNode を使用する場合、証明書の有効期限が切れます

外部リソースレシピをデプロイし、Linux VDIs への接続"The connection has been closed. Transport error"中にというエラーが発生した場合、最も可能性の高い原因は、Linux での pip インストールパスが正しくないために自動的に更新されない期限切れの証明書です。証明書の有効期限は 3 か月です。

Amazon CloudWatch ロググループは、次のようなメッセージで接続試行エラーをログに記録する<envname>/vdc/dcv-connection-gateway場合があります。


| 2024-07-29T21:46:02.651Z | Jul 29 21:46:01.702  WARN HTTP:Splicer Connection{id=341 client_address="x.x.x.x:50682"}: Error in connection task: TLS handshake error: received fatal alert: CertificateUnknown | redacted:/res-demo/vdc/dcv-connection-gateway | dcv-connection-gateway_10.3.146.195 |
| 2024-07-29T21:46:02.651Z | Jul 29 21:46:01.702  WARN HTTP:Splicer Connection{id=341 client_address="x.x.x.x:50682"}: Certificate error: AlertReceived(CertificateUnknown) | redacted:/res-demo/vdc/dcv-connection-gateway | dcv-connection-gateway_10.3.146.195 |

問題を解決するには:

AWSアカウントで、EC2 に移動します。という名前のインスタンスがある場合は*-CertificateRenewalNode-*、インスタンスを終了します。

Lambda に移動します。という名前の Lambda 関数が表示され*-CertificateRenewalLambda-*、Lambda コードに次のようなものがないか確認してください。


export HOME=/tmp/home
mkdir -p $HOME

cd /tmp
wget https://bootstrap.pypa.io/pip/3.7/get-pip.py 
python3 ./get-pip.py
pip3 install boto3
eval $(python3 -c "from botocore.credentials import InstanceMetadataProvider, InstanceMetadataFetcher; provider = InstanceMetadataProvider(iam_role_fetcher=InstanceMetadataFetcher(timeout=1000, num_attempts=2)); c = provider.load().get_frozen_credentials(); print(f'export AWS_ACCESS_KEY_ID={c.access_key}'); print(f'export AWS_SECRET_ACCESS_KEY={c.secret_key}'); print(f'export AWS_SESSION_TOKEN={c.token}')")

mkdir certificates
cd certificates
git clone https://github.com/Neilpang/acme.sh.git
cd acme.sh

最新の外部リソース Certs スタックテンプレートについては、こちらを参照してください。テンプレートで Lambda コードを見つけます: リソース → CertificateRenewalLambda → プロパティ → コード。次のようなものがあります。


sudo yum install -y wget
export HOME=/tmp/home
mkdir -p $HOME
cd /tmp
wget https://bootstrap.pypa.io/pip/3.7/get-pip.py
mkdir -p pip
python3 ./get-pip.py --target $PWD/pip
$PWD/pip/bin/pip3 install boto3
eval $(python3 -c "from botocore.credentials import InstanceMetadataProvider, InstanceMetadataFetcher; provider = InstanceMetadataProvider(iam_role_fetcher=InstanceMetadataFetcher(timeout=1000, num_attempts=2)); c = provider.load().get_frozen_credentials(); print(f'export AWS_ACCESS_KEY_ID={c.access_key}'); print(f'export AWS_SECRET_ACCESS_KEY={c.secret_key}'); print(f'export AWS_SESSION_TOKEN={c.token}')")

mkdir certificates
cd certificates
VERSION=3.1.0
wget https://github.com/acmesh-official/acme.sh/archive/refs/tags/$VERSION.tar.gz -O acme-$VERSION.tar.gz
tar -xvf acme-$VERSION.tar.gz
cd acme.sh-$VERSION

*-CertificateRenewalLambda-* Lambda 関数のステップ 2 のセクションをステップ 3 のコードに置き換えます。デプロイを選択し、コード変更が有効になるまで待ちます。
Lambda 関数を手動でトリガーするには、テストタブに移動し、テストを選択します。追加の入力は必要ありません。これにより、Secret Manager で Certificate シークレットと PrivateKey シークレットを更新する証明書 EC2 インスタンスが作成されます。
既存の dcv-gateway インスタンスを終了<env-name>-vdc-gatewayし、自動スケーリンググループが新しいインスタンスを自動的にデプロイするのを待ちます。

........................

以前に機能していた仮想デスクトップが正常に接続できなくなった

デスクトップ接続が閉じられたり、接続できなくなったりすると、基盤となる Amazon EC2 インスタンスが失敗するか、Amazon EC2 インスタンスが RES 環境外で終了または停止されたことが原因である可能性があります。管理者 UI のステータスは、準備完了状態を引き続き表示する場合がありますが、接続の試行は失敗します。

Amazon EC2 コンソールを使用して、インスタンスが終了または停止されたかどうかを判断する必要があります。停止した場合は、もう一度開始してみてください。状態が終了した場合は、別のデスクトップを作成する必要があります。ユーザーのホームディレクトリに保存されたデータは、新しいインスタンスの起動時に引き続き使用できます。

以前に失敗したインスタンスが管理者 UI にまだ表示されている場合は、管理者 UI を使用して終了する必要がある場合があります。

........................

5 つの仮想デスクトップしか起動できない

ユーザーが起動できる仮想デスクトップの数のデフォルトの制限は 5 です。これは、管理者が管理者 UI を使用して次のように変更できます。

デスクトップ設定に移動します。
[一般] タブを選択します。
プロジェクトごとのユーザーあたりのデフォルトの許可されたセッションの右側にある編集アイコンを選択し、値を目的の新しい値に変更します。
[Submit] を選択してください。
ページを更新して、新しい設定が設定されていることを確認します。

........................

デスクトップ Windows の接続試行は「接続が閉じられました。トランスポートエラー"

Windows デスクトップ接続が UI エラー「接続が閉じられました。トランスポートエラー」。Windows インスタンスでの証明書の作成に関連する DCV サーバーソフトウェアの問題が原因である可能性があります。

Amazon CloudWatch ロググループは、次のようなメッセージで接続試行エラーをログに記録する<envname>/vdc/dcv-connection-gateway場合があります。


Nov 24 20:24:27.631 DEBUG HTTP:Splicer Connection{id=9}:
Websocket{session_id="1291e75f-7816-48d9-bbb2-7371b3b911cd"}:
Resolver lookup{client_ip=Some(52.94.36.19) 
session_id="1291e75f-7816-48d9-bbb2-7371b3b911cd"
 protocol_type=WebSocket extension_data=None}:NoStrictCertVerification: 
 Additional stack certificate (0): [s/n: 0E9E9C4DE7194B37687DC4D2C0F5E94AF0DD57E]

Nov 24 20:25:15.384  INFO HTTP:Splicer Connection{id=21}:Websocket{
session_id="d1d35954-f29d-4b3f-8c23-6a53303ebc3f"}: 
Connection initiated error: unreachable, server io error Custom { 
kind: InvalidData, error:
General("Invalid certificate: certificate has expired (code: 10)") }

Nov 24 20:25:15.384  WARN HTTP:Splicer Connection{id=21}:
Websocket{session_id="d1d35954-f29d-4b3f-8c23-6a53303ebc3f"}: 
Error in websocket connection: Server unreachable: Server error: IO error: 
unexpected error: Invalid certificate: certificate has expired (code: 10)

この場合、SSM セッションマネージャーを使用して Windows インスタンスへの接続を開き、次の 2 つの証明書関連ファイルを削除することが解決される可能性があります。


PS C:\Windows\system32\config\systemprofile\AppData\Local\NICE\dcv> dir

    Directory: C:\Windows\system32\config\systemprofile\AppData\Local\NICE\dcv


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----         8/4/2022  12:59 PM           1704 dcv.key
-a----         8/4/2022  12:59 PM           1265 dcv.pem

ファイルは自動的に再作成され、それ以降の接続試行が成功する可能性があります。

この方法で問題を解決し、Windows デスクトップの新しい起動で同じエラーが発生した場合は、ソフトウェアスタックの作成関数を使用して、再生成された証明書ファイルを含む固定インスタンスの新しい Windows ソフトウェアスタックを作成します。これにより、正常な起動と接続に使用できる Windows ソフトウェアスタックが生成されます。

........................

VDIsプロビジョニング状態でスタックする

デスクトップ起動が管理者 UI のプロビジョニング状態のままである場合は、いくつかの理由が考えられます。

原因を特定するには、デスクトップインスタンスのログファイルを調べ、問題の原因となっている可能性のあるエラーを探します。このドキュメントには、ログファイルと Amazon CloudWatch ロググループのリストが含まれており、有用なログおよびイベント情報ソースというラベルが付いたセクションに関連情報が含まれています。

この問題の潜在的な原因は次のとおりです。

使用されている AMI ID は software-stack として登録されていますが、RES ではサポートされていません。

Amazon マシンイメージ (AMI) に必要な設定またはツールがないため、ブートストラッププロビジョニングスクリプトを完了できませんでした。Linux インスタンスなど、インスタンス/root/bootstrap/logs/のログファイルには、これに関する有用な情報が含まれている場合があります。AWSMarketplace から取得した AMIs ID は、RES デスクトップインスタンスでは機能しない場合があります。サポートされているかどうかを確認するには、テストが必要です。
ユーザーデータスクリプトは、Windows 仮想デスクトップインスタンスがカスタム AMI から起動されたときに実行されません。

デフォルトでは、ユーザーデータスクリプトは Amazon EC2 インスタンスの起動時に 1 回実行されます。既存の仮想デスクトップインスタンスから AMI を作成し、その AMI にソフトウェアスタックを登録して、このソフトウェアスタックで別の仮想デスクトップを起動しようとすると、ユーザーデータスクリプトは新しい仮想デスクトップインスタンスでは実行されません。

この問題を解決するには、AMI の作成に使用した元の仮想デスクトップインスタンスで管理者として PowerShell コマンドウィンドウを開き、次のコマンドを実行します。
```
C:\ProgramData\Amazon\EC2-Windows\Launch\Scripts\InitializeInstance.ps1 –Schedule
```
次に、インスタンスから新しい AMI を作成します。新しい AMI を使用してソフトウェアスタックを登録し、後で新しい仮想デスクトップを起動できます。プロビジョニング状態のままのインスタンスで同じコマンドを実行し、インスタンスを再起動して仮想デスクトップセッションを修正することもできますが、設定ミスのある AMI から別の仮想デスクトップを起動すると、同じ問題が再度発生することに注意してください。

........................

起動後に VDIsがエラー状態になる

考えられる問題 1: ホームファイルシステムに、異なる POSIX アクセス許可を持つユーザーのディレクトリがあります。

これは、次のシナリオが当てはまる場合に直面する問題である可能性があります。

デプロイされた RES バージョンは 2024.01 以降です。
RES スタックのデプロイ中に、の属性がに設定EnableLdapIDMappingされましたTrue。
RES スタックのデプロイ中に指定されたホームファイルシステムは、RES 2024.01 より前のバージョンで使用されたか、を EnableLdapIDMappingに設定して以前の環境で使用されましたFalse。

解決手順: ファイルシステム内のユーザーディレクトリを削除します。

クラスターマネージャーホストへの SSM。
cd /home.
ls - は、、.. などのユーザー名に一致するディレクトリ名を持つディレクトリadmin1を一覧表示する必要がありますadmin2。
ディレクトリを削除しますsudo rm -r 'dir_name'。ssm-user ディレクトリと ec2-user ディレクトリを削除しないでください。
ユーザーが新しい env に既に同期されている場合は、ユーザーの DDB テーブルからユーザーのを削除します (clusteradmin を除く)。
AD 同期の開始 - クラスターマネージャー Amazon EC2 sudo /opt/idea/python/3.9.16/bin/resctl ldap sync-from-adで実行します。
RES ウェブページから Error状態の VDI インスタンスを再起動します。VDI が約 20 分で Ready状態に移行することを検証します。

........................

ログインすると、VDI セッションが空白の画面になります

ログイン後にコンソールセッションタイプの VDI セッションが空白で応答しない場合、X サーバーが壊れていることを意味します。これは、DCV がデスクトップをストリーミングしようとしているが、ストリーミングする OS の問題が原因である可能性があります。この最も可能性の高い原因は、Xorg 設定の問題です。次のコマンドを実行して、デフォルトの Xorg 設定にあまり依存しないようにできます。

Debian ベースの Linux:


dpkg-divert --package nice-xdcv --divert /usr/bin/Xorg.orig --rename /usr/bin/Xorg ln -sf /usr/bin/Xdcv-console /usr/bin/Xorg

Red Hat ベースの Linux:


rpm -q --whatprovides /usr/bin/Xorg && \
cp /usr/bin/Xorg /usr/bin/Xorg.orig && \
ln -sf /usr/bin/Xdcv-console /usr/bin/Xorg

........................

仮想デスクトップコンポーネント

トピック

Amazon EC2 インスタンスがコンソールで終了を繰り返し表示
AD への参加に失敗したために vdc-controller インスタンスがサイクルしています / eVDI モジュールが失敗した API ヘルスチェックを表示
プロジェクトは、ソフトウェアスタックを編集して追加するときにプルダウンに表示されません
cluster-manager Amazon CloudWatch ログには、「<user-home-init> アカウントはまだ利用できません。ユーザーの同期を待っています」と表示されます (アカウントはユーザー名です）。
ログイン試行時の Windows デスクトップに「アカウントが無効になっています。管理者にお問い合わせください」
外部/顧客の AD 設定に関する DHCP オプションの問題
Firefox エラー MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING

........................

Amazon EC2 インスタンスがコンソールで終了を繰り返し表示

インフラストラクチャインスタンスが Amazon EC2 コンソールで終了と繰り返し表示される場合、原因はその設定に関連している可能性があり、インフラストラクチャインスタンスタイプによって異なります。以下に、原因を特定する方法を示します。

Amazon EC2 コンソールで vdc-controller インスタンスが終了状態が繰り返し表示される場合は、シークレットタグが正しくない可能性があります。RES によって維持されるシークレットには、インフラストラクチャの Amazon EC2 インスタンスにアタッチされた IAM アクセスコントロールポリシーの一部として使用されるタグがあります。vdc-controller がサイクルしていて、CloudWatch ロググループに次のエラーが表示された場合、シークレットが正しくタグ付けされていない可能性があります。シークレットには、次のタグを付ける必要があることに注意してください。


{
    "res:EnvironmentName": "<envname>" # e.g. "res-demo"
    "res:ModuleName": "virtual-desktop-controller"
}

このエラーの Amazon CloudWatch ログメッセージは、次のように表示されます。


An error occurred (AccessDeniedException) when calling the GetSecretValue
operation: User: arn:aws:sts::160215750999:assumed-role/<envname>-vdc-gateway-role-us-east-1/i-043f76a2677f373d0 
is not authorized to perform: secretsmanager:GetSecretValue on resource:
arn:aws:secretsmanager:us-east-1:160215750999:secret:Certificate-res-bi-Certs-5W9SPUXF08IB-F1sNRv 
because no identity-based policy allows the secretsmanager:GetSecretValue action

Amazon EC2 インスタンスのタグをチェックし、上記のリストと一致することを確認します。

........................

AD への参加に失敗したために vdc-controller インスタンスがサイクルしています / eVDI モジュールが失敗した API ヘルスチェックを表示

eVDI モジュールがヘルスチェックに失敗した場合、環境ステータスセクションに以下が表示されます。

この場合、デバッグの一般的なパスは、クラスターマネージャーの CloudWatch ログを調べることです。( という名前のロググループを探します<env-name>/cluster-manager。)

考えられる問題:

ログにテキストが含まれている場合はInsufficient permissions、res スタックの作成時に指定された ServiceAccount ユーザー名のスペルが正しいことを確認してください。

ログ行の例:
```
Insufficient permissions to modify computer account: CN=IDEA-586BD25043,OU=Computers,OU=RES,OU=CORP,DC=corp,DC=res,DC=com: 000020E7: AtrErr: DSID-03153943, #1: 0: 000020E7: DSID-03153943, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 90008 (userAccountControl):len 4 >> 432 ms - request will be retried in 30 seconds
```
- SecretsManager コンソールから、RES デプロイ中に提供される ServiceAccount ユーザー名にアクセスできます。Secrets Manager で対応するシークレットを検索し、プレーンテキストの取得を選択します。ユーザー名が正しくない場合は、編集を選択してシークレット値を更新します。現在の cluster-manager インスタンスと vdc-controller インスタンスを終了します。新しいインスタンスは安定した状態になります。
- 提供された外部リソーススタックによって作成されたリソースを使用している場合、ユーザー名は「ServiceAccount」である必要があります。RES のデプロイ中に DisableADJoinパラメータが False に設定されている場合は、ServiceAccount」ユーザーに AD でコンピュータオブジェクトを作成するアクセス許可があることを確認します。
使用したユーザー名が正しいが、ログにテキストが含まれている場合Invalid credentials、入力したパスワードが間違っているか、有効期限が切れている可能性があります。

ログ行の例:
```
{'msgtype': 97, 'msgid': 1, 'result': 49, 'desc': 'Invalid credentials', 'ctrls': [], 'info': '80090308: LdapErr: DSID-0C090569, comment: AcceptSecurityContext error, data 532, v4563'}
```
- 環境の作成時に入力したパスワードは、Secrets Manager コンソールにパスワードを保存するシークレットにアクセスして読み取ることができます。シークレット ( など<env_name>directoryserviceServiceAccountPassword) を選択し、プレーンテキストの取得を選択します。
- シークレットのパスワードが正しくない場合は、編集を選択してシークレットの値を更新します。現在の cluster-manager インスタンスと vdc-controller インスタンスを終了します。新しいインスタンスは更新されたパスワードを使用し、安定した状態になります。
- パスワードが正しい場合は、接続された Active Directory でパスワードの有効期限が切れている可能性があります。最初に Active Directory でパスワードをリセットしてから、シークレットを更新する必要があります。Directory Service コンソールから Active Directory でユーザーのパスワードをリセットできます。
  1. 適切なディレクトリ ID を選択する
  2. アクション、ユーザーパスワードのリセットを選択し、ユーザー名 (ServiceAccount」など) と新しいパスワードをフォームに入力します。
  3. 新しく設定したパスワードが以前のパスワードと異なる場合は、対応する Secret Manager シークレットのパスワードを更新します (例: <env_name>directoryserviceServiceAccountPassword。
  4. 現在の cluster-manager インスタンスと vdc-controller インスタンスを終了します。新しいインスタンスは安定した状態になります。

........................

プロジェクトは、ソフトウェアスタックを編集して追加するときにプルダウンに表示されません

この問題は、ユーザーアカウントと AD の同期に関連する次の問題に関連している可能性があります。この問題が発生した場合は、クラスターマネージャーの Amazon CloudWatch ロググループでエラー<user-home-init> account not available yet. waiting for user to be synced「」をチェックして、原因が同じか関連しているかを判断します。

........................

cluster-manager Amazon CloudWatch ログには、「<user-home-init> アカウントはまだ利用できません。ユーザーの同期を待っています」と表示されます (アカウントはユーザー名です）。

SQS サブスクライバーは、ユーザーアカウントにアクセスできないため、ビジー状態で無限ループに陥っています。このコードは、ユーザーの同期中にユーザーのホームファイルシステムを作成しようとしたときにトリガーされます。

ユーザーアカウントにアクセスできないのは、使用中の AD に対して RES が正しく設定されていないためです。たとえば、BI/RES 環境の作成時に使用された ServiceAccountCredentialsSecretArnパラメータの値が正しくない可能性があります。

........................

ログイン試行時の Windows デスクトップに「アカウントが無効になっています。管理者にお問い合わせください」

ユーザーがロックされた画面に再度ログインできない場合は、SSO 経由で正常にサインオンした後、RES 用に設定された AD でユーザーが無効になっている可能性があります。

AD でユーザーアカウントが無効になっている場合、SSO ログインは失敗します。

........................

外部/顧客の AD 設定に関する DHCP オプションの問題

独自の Active Directory "The connection has been closed. Transport error"で RES を使用するときに Windows 仮想デスクトップでというエラーが発生した場合は、dcv-connection-gateway Amazon CloudWatch ログに次のようなものがないか確認してください。


Oct 28 00:12:30.626  INFO HTTP:Splicer Connection{id=263}:
Websocket{session_id="96cffa6e-cf2e-410f-9eea-6ae8478dc08a"}: Connection initiated error: unreachable, server io error Custom { kind: Uncategorized, error: "failed to lookup address information: Name or service not known" } 

Oct 28 00:12:30.626  WARN HTTP:Splicer Connection{id=263}: Websocket{session_id="96cffa6e-cf2e-410f-9eea-6ae8478dc08a"}: Error in websocket connection: Server unreachable: Server error: IO error: failed to lookup address information: Name or service not known
 
Oct 28 00:12:30.627 DEBUG HTTP:Splicer Connection{id=263}: ConnectionGuard dropped

独自の VPC の DHCP オプションに AD ドメインコントローラーを使用している場合は、以下を行う必要があります。

AmazonProvidedDNS を 2 つのドメインコントローラー IPs。
ドメイン名を ec2.internal に設定します。

以下に例を示します。この設定がない場合、RES/DCV は ip-10-0-x-xx.ec2.internal ホスト名を検索するため、Windows デスクトップはトランスポートエラー を返します。

........................

Firefox エラー MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING

Firefox ウェブブラウザを使用すると、仮想デスクトップに接続しようとすると、MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING というエラーメッセージが表示されることがあります。

原因は、RES ウェブサーバーが TLS + ステープリングオンでセットアップされているが、ステープリング検証で応答していないことです (https://support.mozilla.org/en-US/questions/1372483。

これは、https://really-simple-ssl.com/mozilla_pkix_error_required_tls_feature_missing の指示に従って修正できます。

........................

Env 削除

トピック

res-xxx-cluster スタックが「DELETE_FAILED」状態で、「Role is invalid or cannot be assumed」エラーのため手動で削除できない
ログの収集
VDI ログのダウンロード
Linux EC2 インスタンスからのログのダウンロード
Windows EC2 インスタンスからのログのダウンロード
WaitCondition エラーの ECS ログの収集
ネットワークインターフェイスの削除に失敗しました

........................

res-xxx-cluster スタックが「DELETE_FAILED」状態で、「Role is invalid or cannot be assumed」エラーのため手動で削除できない

「res-xxx-cluster」スタックが「DELETE_FAILED」状態で、手動で削除できない場合は、次の手順を実行して削除できます。

スタックが「DELETE_FAILED」状態になっている場合は、まず手動で削除してみてください。スタックの削除を確認するダイアログが表示される場合があります。[削除] を選択します。

必要なスタックリソースをすべて削除しても、保持するリソースを選択するメッセージが表示されることがあります。その場合は、「保持するリソース」としてすべてのリソースを選択し、「削除」を選択します。

次のようなエラーが表示される場合があります。 Role: arn:aws:iam::... is Invalid or cannot be assumed

これは、スタックの削除に必要なロールが、スタックの前に最初に削除されたことを意味します。これを回避するには、ロールの名前をコピーします。IAM コンソールに移動し、次に示すパラメータを使用して、その名前のロールを作成します。

信頼されたエンティティタイプでAWSサービスを選択します。
ユースケース で、 Use cases for otherAWS servicesを選択しますCloudFormation。

IAM ロールロールの作成ステップ 1 ウィンドウでは、信頼されたエンティティを選択できます。

[次へ] を選択します。ロールに「」およびAWSCloudFormationFullAccessAdministratorAccess「」のアクセス許可を付与してください。レビューページは次のようになります。

次に、CloudFormation コンソールに戻り、スタックを削除します。これで、ロールを作成した後で削除できるようになります。最後に、IAM コンソールに移動し、作成したロールを削除します。

........................

ログの収集

EC2 コンソールから EC2 インスタンスにログインする

Linux EC2 インスタンスにログインするには、次の手順に従います。
Windows EC2 インスタンスにログインするには、次の手順に従います。次に、Windows PowerShell を開いてコマンドを実行します。

インフラストラクチャホストログの収集

Cluster-manager: 次の場所からクラスターマネージャーのログを取得し、チケットにアタッチします。
1. CloudWatch ロググループからのすべてのログ<env-name>/cluster-manager。
2. <env-name>-cluster-manager EC2 インスタンスの /root/bootstrap/logs ディレクトリにあるすべてのログ。このセクションの冒頭にあるEC2 コンソールから EC2 インスタンスにログインする」からにリンクされている手順に従って、インスタンスにログインします。
Vdc-controller: 次の場所から vdc-controller のログを取得し、チケットにアタッチします。
1. CloudWatch ロググループからのすべてのログ<env-name>/vdc-controller。
2. <env-name>-vdc-controller EC2 インスタンスの /root/bootstrap/logs ディレクトリにあるすべてのログ。このセクションの冒頭にあるEC2 コンソールから EC2 インスタンスにログインする」からにリンクされている手順に従って、インスタンスにログインします。

ログを簡単に取得する方法の 1 つは、 Linux EC2 インスタンスからのログのダウンロードセクションの指示に従うことです。モジュール名はインスタンス名になります。

VDI ログの収集

対応する Amazon EC2 インスタンスを特定する

ユーザーがセッション名で VDI を起動した場合VDI1、Amazon EC2 コンソールのインスタンスの対応する名前はになります<env-name>-VDI1-<user name>。

Linux VDI ログの収集

このセクションの冒頭にあるAmazon EC2 コンソールから EC2 インスタンスにログインする」の「」にリンクされた手順に従って、Amazon EC2 コンソールから対応する Amazon EC2 インスタンスにログインします。VDI Amazon EC2 インスタンスの /root/bootstrap/logsおよび /var/log/dcv/ ディレクトリにあるすべてのログを取得します。

ログを取得する方法の 1 つは、ログを s3 にアップロードし、そこからダウンロードすることです。そのためには、以下の手順に従って 1 つのディレクトリからすべてのログを取得し、アップロードします。

/root/bootstrap/logs ディレクトリの下に dcv ログをコピーするには、次の手順に従います。
```
sudo su - 
cd /root/bootstrap
mkdir -p logs/dcv_logs
cp -r /var/log/dcv/* logs/dcv_logs/ 
```
次に、次のセクション「」に記載されている手順に従ってVDI ログのダウンロードログをダウンロードします。

Windows VDI ログの収集

このセクションの冒頭にあるAmazon EC2 コンソールから EC2 インスタンスにログインする」の「」にリンクされた手順に従って、Amazon EC2 コンソールから対応する Amazon EC2 インスタンスにログインします。VDI EC2 インスタンスの $env:SystemDrive\Users\Administrator\RES\Bootstrap\Log\ ディレクトリですべてのログを取得します。

ログを取得する方法の 1 つは、ログを S3 にアップロードし、そこからダウンロードすることです。これを行うには、次のセクション「」に記載されているステップに従いますVDI ログのダウンロード。

........................

VDI ログのダウンロード

VDI EC2 インスタンスの IAM ロールを更新して、S3 アクセスを許可します。
EC2 コンソールに移動し、VDI インスタンスを選択します。
使用している IAM ロールを選択します。
アクセス許可の追加ドロップダウンメニューのアクセス許可ポリシーセクションで、ポリシーのアタッチを選択し、AmazonS3FullAccess ポリシーを選択します。
アクセス許可を追加 を選択して、そのポリシーをアタッチします。
その後、VDI タイプに基づいて以下の手順に従ってログをダウンロードします。モジュール名はインスタンス名になります。
1. Linux EC2 インスタンスからのログのダウンロード Linux 用。
2. Windows EC2 インスタンスからのログのダウンロード for Windows。
最後に、ロールを編集してAmazonS3FullAccessポリシーを削除します。

注記

すべての VDIs、と同じ IAM ロールを使用します。 <env-name>-vdc-host-role-<region>

........................

Linux EC2 インスタンスからのログのダウンロード

ログをダウンロードする EC2 インスタンスにログインし、次のコマンドを実行してすべてのログを s3 バケットにアップロードします。


sudo su -
ENV_NAME=<environment_name>
REGION=<region>
ACCOUNT=<aws_account_number>
MODULE=<module_name>

cd /root/bootstrap
tar -czvf ${MODULE}_logs.tar.gz logs/ --overwrite
aws s3 cp ${MODULE}_logs.tar.gz s3://${ENV_NAME}-cluster-${REGION}-${ACCOUNT}/${MODULE}_logs.tar.gz

その後、S3 コンソールに移動<environment_name>-cluster-<region>-<aws_account_number>し、名前がのバケットを選択し、以前にアップロードした<module_name>_logs.tar.gzファイルをダウンロードします。

........................

Windows EC2 インスタンスからのログのダウンロード

ログをダウンロードする EC2 インスタンスにログインし、次のコマンドを実行してすべてのログを S3 バケットにアップロードします。


$ENV_NAME="<environment_name>"
$REGION="<region>"
$ACCOUNT="<aws_account_number>"
$MODULE="<module_name>"

$logDirPath = Join-Path -Path $env:SystemDrive -ChildPath "Users\Administrator\RES\Bootstrap\Log"
$zipFilePath = Join-Path -Path $env:TEMP -ChildPath "logs.zip"
Remove-Item $zipFilePath
Compress-Archive -Path $logDirPath -DestinationPath $zipFilePath
$bucketName = "${ENV_NAME}-cluster-${REGION}-${ACCOUNT}"
$keyName = "${MODULE}_logs.zip"
Write-S3Object -BucketName $bucketName -Key $keyName -File $zipFilePath

その後、S3 コンソールに移動<environment_name>-cluster-<region>-<aws_account_number>し、名前がのバケットを選択し、以前にアップロードした<module_name>_logs.zipファイルをダウンロードします。

........................

WaitCondition エラーの ECS ログの収集

デプロイされたスタックに移動し、リソースタブを選択します。
Deploy → ResearchAndEngineeringStudio → Installer → Tasks → CreateTaskDef → CreateContainer → LogGroup を展開し、ロググループを選択して CloudWatch ログを開きます。
このロググループから最新のログを取得します。

........................

ネットワークインターフェイスの削除に失敗しました

RES ファイナライザースタックdetachvpcfromlambdacustomresourceの削除の「イベント」セクションで削除に失敗した場合、これは Lambda サービスが削除に失敗したか、RES Lambdas にアタッチされたネットワークインターフェイスが時間内に削除されなかったことを意味します。

Amazon EC2 コンソール内のネットワークインターフェイスページに移動し、を含む説明でフィルタリングすることで、これらの古いネットワークインターフェイスを手動で削除できますAWS Lambda VPC ENI-{RES-Environment-Name}。最大 14 個のネットワークインターフェイスが必要ですが、正常に削除できた Lambda の数によっては少なくなる場合があります。これらのネットワークインターフェイスを手動で削除し、RES スタックの削除を再起動します。

デモ環境

........................

問題

ログインしようとして、ID プロバイダーへの認証リクエストを処理するときに「予期しないエラー」が発生した場合、パスワードの有効期限が切れている可能性があります。これは、ログインしようとしているユーザーのパスワードまたは Active Directory サービスアカウントのいずれかです。

緩和策

Directory サービスコンソールでユーザーとサービスアカウントのパスワードをリセットします。
Secrets Manager のサービスアカウントのパスワードを、上記で入力した新しいパスワードと一致するように更新します。
- Keycloak スタックの : PasswordSecret-...-RESExternal-...-DirectoryService-... with Description: Password for Microsoft Active Directory
- for RES: res-ServiceAccountPassword-... with 説明: Active Directory サービスアカウントのパスワード
EC2 コンソールに移動し、クラスターマネージャーインスタンスを終了します。Auto Scaling ルールは、新しいインスタンスのデプロイを自動的にトリガーします。

........................

デモスタックのキークロークが機能しない

問題

キークロークサーバーがクラッシュし、サーバーを再起動したときにインスタンスの IP が変更された場合、キークロークが壊れた可能性があります。RES ポータルのログインページがロードに失敗するか、ロード状態でスタックし、解決されません。

緩和策

Keycloak を正常な状態に復元するには、既存のインフラストラクチャを削除し、Keycloak スタックを再デプロイする必要があります。以下の手順に従ってください。

Cloudformation に移動します。そこに 2 つのキークローク関連スタックが表示されます。
- <env-name>-RESSsoKeycloak-<random characters> (Stack1)
  
  <env-name>-RESSsoKeycloak-<random characters>-RESSsoKeycloak-* (スタック2)
Stack1 を削除します。ネストされたスタックを削除するように求められたら、はいを選択してネストされたスタックを削除します。

スタックが完全に削除されていることを確認します。
ここで RES SSO Keycloak スタックテンプレートをダウンロードします。
削除されたスタックとまったく同じパラメータ値を使用して、このスタックを手動でデプロイします。CloudFormation コンソールからデプロイするには、スタックの作成 → 新しいリソース (標準) を使用 → 既存のテンプレートを選択する → テンプレートファイルをアップロードします。削除されたスタックと同じ入力を使用して、必要なパラメータを入力します。これらの入力は、CloudFormation コンソールでフィルターを変更し、パラメータタブに移動することで、削除されたスタックで確認できます。環境名、キーペア、およびその他のパラメータが元のスタックパラメータと一致していることを確認します。
スタックがデプロイされると、環境を再度使用する準備が整います。ApplicationUrl は、デプロイされたスタックの出力タブにあります。

........................

Active Directory の問題

トピック

VDI がプロビジョニング状態に長時間スタックしているか、VDI の準備が整った後に VDI を AD ユーザーとしてログインできない
SSO の設定後に RES ウェブポータルにログインできない
AD ユーザーは、Linux VDIs を正常に起動した後でも、ファイルブラウザを使用してホームディレクトリにアクセスできません
SSH アクセスが有効になっていると、AD 管理者ユーザーは踏み台ホストにアクセスできません
RES 外部リソーススタックによってデプロイされた Active Directory の表示と管理

VDI がプロビジョニング状態に長時間スタックしているか、VDI の準備が整った後に VDI を AD ユーザーとしてログインできない

最初に VDI のインストールログと設定ログ (/root/bootstrap/logs/Linux の場合はおよび /opt/idea/app/logs/ ディレクトリ、Windows の場合は C:\Users\Administrator\RES\Bootstrap\Log\および C:\Program Files\RES\app\logs\ ディレクトリ) で、インストールエラーや設定エラーがないか確認してください。

インスタンスが Active Directory に参加できなかったというエラーメッセージが表示された場合は、通常、Cluster Manager が AD のインスタンスのコンピュータアカウントをプリセットできないためです。/environment-name/cluster-manager CloudWatch ロググループの Cluster Manager ログを確認し、を含むエラーメッセージをフィルタリングします[preset-computer]。一般的な問題は次のとおりです。

AD サービスアカウントの認証情報が無効です。
- RES に提供したサービスアカウントのシークレットを確認します。ユーザー名とパスワードがキーと値のペアとして提供され{username: password}、認証情報が有効であることを確認します。既存のインスタンスを終了し、サービスアカウントのシークレットを変更した後に自動スケーリンググループが新しいインスタンスを自動的に起動できるようにして、クラスターマネージャーインスタンスをサイクルする必要があります。次に、新しい VDIsを起動して変更を適用します。
サービスアカウントには、AD でコンピュータアカウントを作成するアクセス許可がありません。
- サービスアカウントに、「」に記載されているすべての必要なアクセス許可があることを確認しますMicrosoft Active Directory のサービスアカウントを設定する。AD でサービスアカウントのアクセス許可を修正した後、新しい VDIsを起動する必要があります。
LDAP サーバーに接続できません。
- AD 設定で VPC 内の LDAP/LDAPS 接続が許可され、AWSマネージド AD を使用している場合は AWSManaged Microsoft AD の DHCP オプションセットを作成または変更した後、VPC の DHCP オプションが正しく設定されていることを確認します。
- LDAPS 接続では、 DomainTLSCertificateSecretArnパラメータが必要であり、接続を保護するために有効な CA 証明書を指定する必要があります。既存のインスタンスを終了し、TLS 証明書シークレットを変更した後に自動スケーリンググループが新しいインスタンスを自動的に起動できるようにして、Cluster Manager インスタンスをサイクルする必要があります。次に、新しい VDIsを起動して変更を適用します。
- RES と AD 間の接続をテストするには、Cluster Manager インスタンスで次の ldapsearch コマンドを実行します (ユーザー OU、LDAP 接続 URI、サービスアカウントのユーザー名とパスワードを置き換えます）。AD が接続を許可するように適切に設定されている場合、このコマンドは指定された OU のすべてのユーザーを返します。
```
ldapsearch -x -b "OU=Users,OU=RES,OU=CORP,DC=corp,DC=res,DC=com" -D "ServiceAccount@corp.res.com" -H ldap://corp.res.com -w service-account-password "(objectClass=group)"
```

RES のインストールtrue時に DisableADJoin をに設定した場合、Linux VDIs SSSD サービスを介して接続するのではなく、Active Directory にのみ接続します。EC2 コンソールから VDI インスタンスに接続し、そのインスタンスid usernameでコマンドを実行します。コマンドが対応する AD ユーザーの UID / GID を返すことができない場合は、VDI インスタンスsudo systemctl status sssdのコマンドと /var/log/sssd/ ディレクトリの SSSD サービスログを使用して SSSD サービスのステータスを確認します。

AD に接続するために SSSD 設定をカスタマイズする必要がある場合は、SSSD 設定ファイル (/etc/sssd/sssd.conf) を手動で編集し、infra / VDI host (2024.12.01 release 以前sudo systemctl restart sssdでコマンドを使用して SSSD サービスを再起動するか、RES ウェブポータルから追加の SSSD 設定を提供できます。Active Directory の同期これは、既存または新しい VDIs に自動的に適用されます (2025.03 release 以降）。

........................

SSO の設定後に RES ウェブポータルにログインできない

environment-name.accounts.users と environment-name.accounts.groups DynamoDB テーブルをチェックして、ユーザーとグループが Active Directory から同期されているかどうかを確認します。テーブルが空であるか、ログインしているユーザーが見つからない場合は、/environment-name/cluster-managerCloudWatch ロググループ (2024.12 リリース以前) または /environment-name/ad-sync CloudWatch ロググループ (2024.12 リリース以降) の AD 同期ログを確認します。

に記載されている一般的な AD 設定の問題に加えてVDI がプロビジョニング状態に長時間スタックしているか、VDI の準備が整った後に VDI を AD ユーザーとしてログインできない、他のエラーには次のようなものがあります。

サービスアカウントには、AD のユーザーとグループをクエリするアクセス許可がありません。
- サービスアカウントに、「」に記載されているすべての必要なアクセス許可があることを確認しますMicrosoft Active Directory のサービスアカウントを設定する。
Active Directory のユーザー/グループに E メールアドレスなどの必須属性がありません。
- ユーザー/グループの属性を更新して問題を解決します。

AD 同期の問題を修正したら、次にスケジュールされた AD 同期が 1 時間ごとに発生するのを待つか、同期を手動で実行する方法 (リリース 2024.12 および 2024.12.01) (2024.12 および 2024.12.01 リリース) または同期を手動で開始または停止する方法 (リリース 2025 年 3 月以降) (リリース 2025.03 以降) の指示に従って手動でトリガーできます。

........................

AD ユーザーは、Linux VDIs を正常に起動した後でも、ファイルブラウザを使用してホームディレクトリにアクセスできません

Cluster Manager インスタンスid usernameでコマンドを実行して、AD ユーザーが Cluster Manager に表示されるかどうかを確認します。コマンドが対応する AD ユーザーの UID / GID を返すことができない場合は、/environment-name/cluster-managerCloudWatch ロググループの Cluster Manager ログを確認し、SSSD サービスの開始に関するエラーを検索します。Cluster Manager ログにエラーがない場合は、Cluster Manager インスタンスsudo systemctl status sssdのコマンドと /var/log/sssd/ ディレクトリの SSSD サービスログを使用して、SSSD サービスのステータスを確認します。

AD ユーザーが Cluster Manager に表示されている場合は、コマンドを実行して、ユーザーのホームディレクトリ (/home/username) の UID / GID を確認しますls -n /home。ユーザーのホームディレクトリの UID/GID を、 id username コマンドによって返された UID/GID と比較します。UID / GID が一致しない場合、ユーザーのホームディレクトリが RES の外部または以前の RES デプロイから作成される可能性があります。重要なユーザーデータをバックアップし、ホームディレクトリを削除して、ユーザーで新しい Linux VDI を起動します。新しい VDI が正常にプロビジョニングされると、ホームディレクトリは適切な UID/GID で再作成されます。

........................

SSH アクセスが有効になっていると、AD 管理者ユーザーは踏み台ホストにアクセスできません

踏み台ホストインスタンスid usernameでコマンドを実行して、AD ユーザーが踏み台ホストに表示されるかどうかを確認します。コマンドが対応する AD ユーザーの UID / GID を返すことができない場合は、/environment-name/bastion-hostCloudWatch ロググループの踏み台ホストログをチェックし、SSSD サービスの開始に関するエラーを検索します。踏み台ホストログにエラーがない場合は、踏み台ホストインスタンスsudo systemctl status sssdのコマンドと /var/log/sssd/ ディレクトリの SSSD サービスログを使用して、SSSD サービスのステータスを確認します。

........................

RES 外部リソーススタックによってデプロイされた Active Directory の表示と管理

AWSマネージド Active Directory が RES 外部リソーススタックによってデプロイされている場合、Active Directory へのアクセスと管理に使用できるAWS、アカウントの下にAdDomainWindowsNode-external-resource-stack-name-WindowsManagementHostデプロイされたで始まる名前のインスタンスが必要です。次の認証情報を使用して、EC2 コンソールの Fleet Manager を介してインスタンスにログインできます。

username: 管理者
password: 外部リソーススタックをデプロイするときに提供される AdminPassword パラメータ

AWSマネージド Active Directory を管理するには、AWS「 Directory Service 管理ガイド」のAmazon EC2 インスタンスを使用してユーザーとグループを管理する」を確認してください。

........................

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

一般的なデバッグとモニタリング

既知の問題

RunBooks の問題

インストールの問題

トピック

CloudFormationスタックはWaitCondition received failed message」というメッセージで を作成できません。Error:States.TaskFailed"

注記

CloudFormationスタックが正常に作成された後に E メール通知が受信されない

インスタンスのサイクルまたは vdc-controller が失敗状態

問題を検証するには:

問題を解決するには:

環境 CloudFormation スタックが依存オブジェクトエラーにより削除に失敗する

環境の作成中に CIDR ブロックパラメータでエラーが発生しました

環境作成中の CloudFormation スタック作成の失敗

AdDomainAdminNode CREATE_FAILED で外部リソース (デモ) スタックの作成が失敗する

失敗の原因を特定するには:

ID 管理の問題

トピック

iam:PassRole を実行する権限がありません

自分の AWSアカウント以外のユーザーにAWSリソースの Research and Engineering Studio へのアクセスを許可したい

環境にログインすると、すぐにログインページに戻ります。

ログを確認するには:

設定を確認するには:

ログイン試行時の「ユーザーが見つかりません」エラー

ユーザーが RES に存在せず、最近 AD にユーザーを追加した場合

ユーザーが RES に存在する場合:

Active Directory に追加されたが、RES にないユーザー

注記

同期プロセスを手動で開始します。

セッションの作成時に使用できないユーザー

CloudWatch クラスターマネージャーログのサイズ制限超過エラー

Storage

トピック

RES を使用してファイルシステムを作成しましたが、VDI ホストにマウントされません

RES を介してファイルシステムをオンボードしたが、VDI ホストにマウントされない

VDI ホストから読み書きできない

アクセス許可処理のユースケースの例

RES から Amazon FSx for NetApp ONTAP を作成しましたが、ドメインに参加していません

スナップショット

トピック

スナップショットのステータスが Failed である

スナップショットは、テーブルをインポートできなかったことを示すログとともに適用されません。

インフラストラクチャ

トピック

正常なインスタンスがないロードバランサーターゲットグループ

仮想デスクトップの起動

トピック

Windows Virtual Desktop のログインアカウントが管理者に設定されています

外部リソース CertificateRenewalNode を使用する場合、証明書の有効期限が切れます

問題を解決するには:

以前に機能していた仮想デスクトップが正常に接続できなくなった

5 つの仮想デスクトップしか起動できない

デスクトップ Windows の接続試行は「接続が閉じられました。トランスポートエラー"

VDIsプロビジョニング状態でスタックする

起動後に VDIsがエラー状態になる

ログインすると、VDI セッションが空白の画面になります

仮想デスクトップコンポーネント

トピック

Amazon EC2 インスタンスがコンソールで終了を繰り返し表示

AD への参加に失敗したために vdc-controller インスタンスがサイクルしています / eVDI モジュールが失敗した API ヘルスチェックを表示

プロジェクトは、ソフトウェアスタックを編集して追加するときにプルダウンに表示されません

cluster-manager Amazon CloudWatch ログには、「<user-home-init> アカウントはまだ利用できません。ユーザーの同期を待っています」と表示されます (アカウントはユーザー名です）。

ログイン試行時の Windows デスクトップに「アカウントが無効になっています。管理者にお問い合わせください」

外部/顧客の AD 設定に関する DHCP オプションの問題

Firefox エラー MOZILLA_PKIX_ERROR_REQUIRED_TLS_FEATURE_MISSING

Env 削除

トピック

res-xxx-cluster スタックが「DELETE_FAILED」状態で、「Role is invalid or cannot be assumed」エラーのため手動で削除できない

ログの収集

VDI ログのダウンロード

注記

Linux EC2 インスタンスからのログのダウンロード

Windows EC2 インスタンスからのログのダウンロード

WaitCondition エラーの ECS ログの収集

ネットワークインターフェイスの削除に失敗しました

デモ環境

トピック

ID プロバイダーへの認証リクエストを処理する際のデモ環境ログインエラー

デモスタックのキークロークが機能しない

Active Directory の問題

トピック

VDI がプロビジョニング状態に長時間スタックしているか、VDI の準備が整った後に VDI を AD ユーザーとしてログインできない

CloudFormationスタックはWaitCondition received failed message」というメッセージでを作成できません。Error:States.TaskFailed"