トラブルシューティング: File Gateway の問題

ゲートウェイが読み取り専用ドメインコントローラー (RODC) を使用してドメインに参加しようとしていないことを確認します。

ゲートウェイが正しい DNS サーバーを使用するように設定されていることを確認します。

例えば、Amazon EC2 ゲートウェイインスタンスを AWSマネージド Active Directory に参加させる場合は、EC2 VPC に設定された DHCP オプションで、 AWSマネージド Active Directory DNS サーバーが指定されていることを確認します。

VPC DHCP オプションセットを使用して設定する DNS サーバーは、VPC 内のすべての EC2 インスタンスに提供されます。個々のゲートウェイに DNS サーバーを指定する場合は、そのゲートウェイの EC2 ローカルコンソールを使用して指定できます。

オンプレミスゲートウェイの場合は、VM ローカルコンソールを使用して DNS サーバーを指定します。

ゲートウェイのローカルコンソールのコマンドプロンプトから次のコマンドを実行して、ゲートウェイのネットワーク接続を確認します。強調表示された変数を、デプロイの実際のドメイン名と IP アドレスに置き換えます。

dig -d ExampleDomainName
ncport -d ExampleDomainControllerIPAddress -p 445
ncport -d ExampleDomainControllerIPAddress -p 389

Active Directory サービスアカウントに、必要なアクセス許可があることを確認します。詳細については、Active Directory サービスアカウントのアクセス許可要件」を参照してください。

ゲートウェイが正しい組織単位 (OU) に参加していることを確認します。

ドメインに参加すると、ゲートウェイのゲートウェイ ID をアカウント名 (SGW-1234ADE など) として使用して、デフォルトのコンピュータコンテナ (OU ではない) に Active Directory コンピュータアカウントが作成されます。このアカウントの名前をカスタマイズすることはできません。

Active Directory 環境に新しいコンピュータオブジェクト用に指定された OU がある場合は、ドメインに参加するときにその OU を指定する必要があります。

指定された OU に参加しようとしたときにアクセス拒否エラーが発生した場合は、Active Directory ドメイン管理者に確認してください。管理者は、ドメインに参加する前にゲートウェイのコンピュータアカウントを事前ステージングする必要がある場合があります。詳細については、Storage Gateway ファイルゲートウェイを Microsoft Active Directory 認証用のドメインに結合する際の問題をトラブルシューティングするにはどうすればよいですか?」を参照してください。

ゲートウェイのローカルコンソールのコマンドプロンプトから次のコマンドを実行して、ゲートウェイのホスト名が DNS で解決可能であることを確認します。強調表示された変数をゲートウェイの実際のホスト名に置き換えます。

dig -d ExampleHostName -r A

ゲートウェイにカスタムホスト名を設定した場合は、IP アドレスを指す DNS A レコードを手動で追加する必要があります。

ゲートウェイとドメインコントローラー間のネットワークレイテンシーが合理的に低いことを確認します。ゲートウェイが 20 秒以内にドメインコントローラーからレスポンスを受信しない場合、ドメインに参加するクエリがタイムアウトすることがあります。

JoinDomain CLI コマンドを使用してゲートウェイをドメインに結合する場合は、 --timeout-in-secondsフラグを追加してタイムアウトを最大 3,600 秒に増やすことができます。

ゲートウェイをドメインに結合するために使用する Active Directory ユーザーが、そのために必要な権限を持っていることを確認します。

ls コマンドの実行時またはディレクトリの参照時にIndexFetchメトリクスが 0 より大きい場合、ファイルゲートウェイは影響を受けるディレクトリの内容に関する情報なしで起動し、FSx for Windows File Server にアクセスする必要がありました。今後そのディレクトリの内容をリストする作業の速度は上がるはずです。

IndexEviction メトリクスが 0 より大きい場合、その時点でファイルゲートウェイがキャッシュで管理できる制限に達したことを意味します。この場合、ファイルゲートウェイは、最近アクセスされたディレクトリから一部のストレージ領域を解放して、新しいディレクトリを一覧表示する必要があります。この問題が頻繁に発生し、パフォーマンスへの影響がある場合は、 にお問い合わせください サポート。

関連する Amazon FSx ファイルシステム サポート の内容と、ユースケースに基づいてパフォーマンスを向上させるための推奨事項について説明します。

最近再起動またはソフトウェアの更新を行った場合は、IOWaitPercent メトリクスを確認します。このメトリクスは、未処理のディスク I/O リクエストがある場合に、CPU がアイドル状態の時間の割合を示します。場合によっては、この値が高く (10 以上)、サーバーの再起動または更新後に増えていることがあります。このような場合、インデックスキャッシュを RAM に再構築するときに、File Gateway がスロールートディスクによってボトルネックになる可能性があります。より高速な物理ディスクをルートディスクに使用することにより、この問題に対処できます。

MemUsedBytes メトリクスが MemTotalBytesメトリクスと同じかほぼ同じ場合、ファイルゲートウェイで使用可能な RAM が不足しています。ファイルゲートウェイに必要な最小限の RAM があることを確認します。既に追加されている場合は、ワークロードとユースケースに基づいて、File Gateway に RAM を追加することを検討してください。

ファイル共有が SMB の場合は、ファイル共有に接続されている SMB クライアントの数が原因である可能性もあります。任意の時点で接続しているクライアントの数を確認するには、SMBV(1/2/3)Sessions メトリクスをチェックします。接続されているクライアントが多数ある場合は、ファイルゲートウェイに RAM を追加する必要がある場合があります。

CachePercentDirty メトリクスが 80 以上の場合、ファイルゲートウェイは Amazon FSx for Windows File Server にデータをアップロードできるよりも速くデータをディスクに書き込んでいます。ファイルゲートウェイからのアップロードの帯域幅を増やすか、1 つ以上のキャッシュディスクを追加するか、クライアントの書き込みを遅くするか、関連する Amazon FSx for Windows File Server のスループットキャパシティを増やすことを検討してください。

CachePercentDirty メトリクスが低い場合は、IoWaitPercent メトリクスを確認します。IoWaitPercent が 10 より大きい場合、ローカルキャッシュディスクの速度によってファイルゲートウェイがボトルネックになる可能性があります。キャッシュには、ローカルソリッドステートドライブ (SSD) ディスク (できれば NVM Express (NVMe)) をお勧めします。このようなディスクが使用できない場合は、パフォーマンスを向上させるために、別々の物理ディスクから複数のキャッシュディスクを使用してみてください。

CachePercentDirty メトリクスが 90% 以上の場合、キャッシュディスクに十分な空き容量がないため、ファイルゲートウェイはディスクへの新しい書き込みを受け入れることができません。ファイルゲートウェイが FSx for Windows File Server にアップロードされる速度を確認するには、 CloudBytesUploadedメトリクスを表示します。そのメトリクスを、クライアントがファイルゲートウェイにファイルを書き込む速度を示す WriteBytesメトリクスと比較します。SMB クライアントが FSx for Windows File Server にアップロードできるよりも速く File Gateway に書き込んでいる場合は、少なくともバックアップジョブのサイズをカバーするキャッシュディスクを追加します。または、アップロード帯域幅を増やします。

バックアップジョブなどの大きなファイルコピーが失敗してもCachePercentDirtyメトリクスが 80% 未満の場合、ファイルゲートウェイがクライアント側のセッションタイムアウトにヒットしている可能性があります。SMB の場合は、PowerShell コマンド Set-SmbClientConfiguration -SessionTimeout 300 を使用してこのタイムアウトを増やすことができます。このコマンドを実行すると、タイムアウトが 300 秒に設定されます。