新規のお客様へのAmazon FSx ファイルゲートウェイの提供は終了しました。FSx ファイルゲートウェイの既存のお客様は、引き続き通常どおりサービスを使用できます。FSx ファイルゲートウェイに似た機能については、[このブログ記事](https://aws.amazon.com/blogs/storage/switch-your-file-share-access-from-amazon-fsx-file-gateway-to-amazon-fsx-for-windows-file-server/)を参照してください。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Storage Gateway のデプロイに関する問題のトラブルシューティング
以下は、ゲートウェイ、ホストプラットフォーム、ファイルシステム、高可用性、データ復旧、スナップショットに関連するベストプラクティスとトラブルシューティングの問題についての情報です。オンプレミスゲートウェイのトラブルシューティング情報は、サポートされている仮想化プラットフォームにデプロイされたゲートウェイにつて述べています。高可用性の問題のトラブルシューティング情報には、VMware vSphere High Availability (HA) プラットフォームで実行されるゲートウェイが含まれます。
**トピック**
+ [トラブルシューティング: ゲートウェイのオフラインに関する問題](troubleshooting-gateway-offline.md) - Storage Gateway コンソールでゲートウェイがオフラインになる原因となる問題を診断する方法について説明します。
+ [トラブルシューティング: Active Directory に関する問題](troubleshooting-active-directory.md) - ファイルゲートウェイを Microsoft Active Directory ドメインに参加させようとする `NETWORK_ERROR`、`TIMEOUT`、`ACCESS_DENIED` などのエラーメッセージが表示された場合の対処方法について説明します。
+ [トラブルシューティング: ゲートウェイのアクティベーションに関する問題](troubleshooting-gateway-activation.md) - Storage Gateway をアクティベートしようとして内部エラーメッセージが表示された場合の対処方法について説明します。
+ [トラブルシューティング: オンプレミスゲートウェイに関する問題](troubleshooting-on-premises-gateway-issues.md) - オンプレミスゲートウェイの操作で発生する可能性がある一般的な問題と、 がゲートウェイに接続 サポート してトラブルシューティングを支援する方法について説明します。
+ [トラブルシューティング: Microsoft Hyper-V セットアップに関する問題](troubleshooting-hyperv-setup.md) - Microsoft Hyper-V プラットフォームに Storage Gateway をデプロイする際に発生する可能性がある一般的な問題について説明します。
+ [トラブルシューティング: Amazon EC2 ゲートウェイに関する問題](troubleshooting-EC2-gateway-issues.md) - Amazon EC2 にデプロイされたゲートウェイを操作するときに発生する可能性のある一般的な問題に関する情報を確認します。
+ [トラブルシューティング: ハードウェアアプライアンスに関する問題](troubleshooting-hardware-appliance-issues.md) - AWS Storage Gatewayハードウェアアプライアンスで発生する可能性のある問題を解決する方法について説明します。
+ [トラブルシューティング: ファイルゲートウェイに関する問題](troubleshooting-file-gateway-issues.md) - ファイルゲートウェイの CloudWatch Log に表示されたエラーの原因やヘルス通知について理解するのに役立つ情報が示されます。
+ [トラブルシューティング: 高可用性に関する問題](troubleshooting-ha-issues.md) - VMware HA 環境にデプロイされているゲートウェイで問題が発生した場合の対処方法について説明します。
# トラブルシューティング: Storage Gateway コンソールでゲートウェイがオフラインとなる
次のトラブルシューティング情報を使用して、 AWS Storage Gateway コンソールにゲートウェイがオフラインであると表示された場合にどう対処すべきかを判断します。
ゲートウェイは、次のいずれかの理由でオフラインと表示されている可能性があります。
+ ゲートウェイが Storage Gateway サービスエンドポイントに到達できません。
+ ゲートウェイが予期せずシャットダウンしました。
+ ゲートウェイに関連付けられたキャッシュディスクが切断または変更されたか、あるいは失敗しました。
ゲートウェイをオンラインに戻すには、ゲートウェイがオフラインになった原因となった問題を特定して解決します。
## 関連付けられたファイアウォールまたはプロキシの確認
プロキシを使用するようにゲートウェイを設定した場合、またはファイアウォールの背後にゲートウェイを配置した場合は、プロキシまたはファイアウォールのアクセスルールを確認してください。プロキシまたはファイアウォールは、Storage Gateway に必要なネットワークポートとサービスエンドポイントとの間のトラフィックを許可する必要があります。詳細については、「[ネットワークとファイアウォールの要件](https://docs.aws.amazon.com/filegateway/latest/filefsxw/Requirements.html#networks)」を参照してください。
## ゲートウェイのトラフィックの継続的な SSL またはディープパケット検査の確認
ゲートウェイと の間のネットワークトラフィックに対して SSL またはディープパケット検査が現在実行されている場合 AWS、ゲートウェイは必要なサービスエンドポイントと通信できない可能性があります。ゲートウェイをオンラインに戻すには、検査を無効にする必要があります。
## 再起動またはソフトウェア更新後の IOWaitPercent メトリクスの確認
再起動またはソフトウェアの更新後、ファイルゲートウェイの `IOWaitPercent` メトリクスが 10 以上であるかどうかを確認します。その場合、インデックスキャッシュを RAM に再構築している間、ゲートウェイの応答が遅くなる可能性があります。詳細については、「[トラブルシューティング: CloudWatch メトリクスの使用](https://docs.aws.amazon.com/filegateway/latest/filefsxw/troubleshooting-file-gateway-issues.html#gateway-not-responding)」を参照してください。
## ハイパーバイザーホストで停電やハードウェア障害がないかの確認
ゲートウェイのハイパーバイザーホストで停電やハードウェア障害が発生すると、ゲートウェイが想定外にシャットダウンし、アクセスできなくなる可能性があります。電源とネットワーク接続を復元すると、ゲートウェイに再びアクセスできるようになります。
ゲートウェイがオンラインに戻ったら、必ずデータを復旧する手順を実行してください。詳細については、「[ベストプラクティス: データの復旧](https://docs.aws.amazon.com/filegateway/latest/filefsxw/recover-data-from-gateway.html)」を参照してください。
## 関連付けられたキャッシュディスクの問題の確認
ゲートウェイに関連付けられたキャッシュディスクの少なくとも 1 つが削除、変更、またはサイズ変更された場合や、破損した場合、ゲートウェイはオフラインになる可能性があります。
**ハイパーバイザーホストから動作キャッシュディスクが削除された場合:**
1. ゲートウェイをシャットダウンします。
1. ディスクを再度追加します。
**注記**
ディスクは必ず同じディスクノードに追加してください。
1. ゲートウェイを再起動します。
**キャッシュディスクが破損しているか、置き換えられたか、またはサイズが変更された場合:**
+ 「[既存の S3 ファイルゲートウェイを新しいインスタンスに置き換える](https://docs.aws.amazon.com/filegateway/latest/files3/migrate-data.html#replace-instance-file-gateway)」で説明されている**方法 2** の手順に従って、新しいゲートウェイを設定し、 AWS クラウドからキャッシュディスク情報を再ダウンロードします。
# トラブルシューティング: ゲートウェイの Active Directory への参加に関する問題
ファイルゲートウェイを Microsoft Active Directory ドメインに参加させようとしたときに、`NETWORK_ERROR`、`TIMEOUT`、`ACCESS_DENIED`、などのエラーメッセージが表示された場合の対処方法を判断したいとき、次のトラブルシューティング情報を利用します。
これらのエラーを解決するには、次の確認事項と設定を実行します。
## nping テストを実行して、ゲートウェイがドメインコントローラーに到達できることを確認する
**nping テストを実行するには:**
1. オンプレミスゲートウェイの場合はハイパーバイザー管理ソフトウェア (VMware、Hyper-V、または KVM) を使用するか、または Amazon EC2 ゲートウェイの場合は ssh を使用して、ゲートウェイローカルコンソールに接続します。
1. 対応する数字を入力して **[ゲートウェイコンソール]** を選択し、`h` を入力して使用可能なすべてのコマンドを一覧表示します。Storage Gateway 仮想マシンとドメイン間の接続をテストするには、次のコマンドを実行します。
`nping -d corp.domain.com -p 389 -c 1 -t tcp`
**注記**
`corp.domain.com` を Active Directory ドメイン DNS 名に置き換え、`389` をご利用の環境の LDAP ポートに置き換えます。
ファイアウォール内で必要なポートが開放されていることを確認します。
以下は、ゲートウェイがドメインコントローラーに到達できた場合の nping テスト成功例です。
```
nping -d corp.domain.com -p 389 -c 1 -t tcp
Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2022-06-30 16:24 UTC
SENT (0.0553s) TCP 10.10.10.21:9783 > 10.10.10.10:389 S ttl=64 id=730 iplen=40 seq=2597195024 win=1480
RCVD (0.0556s) TCP 10.10.10.10:389 > 10.10.10.21:9783 SA ttl=128 id=22332 iplen=44 seq=4170716243 win=8192
Max rtt: 0.310ms | Min rtt: 0.310ms | Avg rtt: 0.310ms
Raw packets sent: 1 (40B) | Rcvd: 1 (44B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.09 seconds
```
以下は、送信先`corp.domain.com`への接続がない場合や、送信先から応答がない場合の nping テストの例です。
```
nping -d corp.domain.com -p 389 -c 1 -t tcp
Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2022-06-30 16:26 UTC
SENT (0.0421s) TCP 10.10.10.21:47196 > 10.10.10.10:389 S ttl=64 id=30318 iplen=40 seq=1762671338 win=1480
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 1 (40B) | Rcvd: 0 (0B) | Lost: 1 (100.00%)
Nping done: 1 IP address pinged in 1.07 seconds
```
## Amazon EC2 ゲートウェイインスタンスの VPC に設定されている DHCP オプションを確認する
ファイルゲートウェイが Amazon EC2 インスタンスで実行されている場合は、DHCP オプションセットが正しく構成され、ゲートウェイインスタンスを含む Amazon 仮想プライベートクラウド (VPC) にアタッチされていることを確認する必要があります。詳細については、「[Amazon VPC DHCP オプションセット](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html)」を参照してください。
## dig クエリを実行して、ゲートウェイがドメインを解決できることを確認する
ドメインがゲートウェイによって解決されない場合、ゲートウェイはドメインに参加できません。
**dig クエリを実行するには:**
1. オンプレミスゲートウェイの場合はハイパーバイザー管理ソフトウェア (VMware、Hyper-V、または KVM) を使用するか、または Amazon EC2 ゲートウェイの場合は ssh を使用して、ゲートウェイローカルコンソールに接続します。
1. 対応する数字を入力して **[ゲートウェイコンソール]** を選択し、`h` を入力して使用可能なすべてのコマンドを一覧表示します。ゲートウェイがドメインを解決できるかどうかをテストするには、次のコマンドを実行します。
`dig -d corp.domain.com`
**注記**
`corp.domain.com` を Active Directory ドメイン DNS 名に置き換えます。
以下に、正常な応答の例を示します。
```
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> corp.domain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24817
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;corp.domain.com. IN A
;; ANSWER SECTION:
corp.domain.com. 600 IN A 10.10.10.10
corp.domain.com. 600 IN A 10.10.20.10
;; Query time: 0 msec
;; SERVER: 10.10.20.228#53(10.10.20.228)
;; WHEN: Thu Jun 30 16:36:32 UTC 2022
;; MSG SIZE rcvd: 78
```
## ドメインコントローラーの設定とロールを確認する
ドメインコントローラーが読み取り専用に設定されていないこと、およびドメインコントローラーにコンピュータが参加するのに十分なロールがあることを確認します。これをテストするには、ゲートウェイ VM と同じ VPC サブネットの他のサーバーをドメインに参加させてみてください。
## ゲートウェイが最寄りのドメインコントローラーに参加していることを確認する
ベストプラクティスとしては、ゲートウェイアプライアンスに地理的に近いドメインコントローラーにゲートウェイを参加させることを推奨します。ネットワークレイテンシーが原因でゲートウェイアプライアンスが 20 秒以内にドメインコントローラーと通信できない場合、ドメイン参加プロセスはタイムアウトすることがあります。たとえば、ゲートウェイアプライアンスが米国東部 (バージニア北部) にあり、 AWS リージョン ドメインコントローラーがアジアパシフィック (シンガポール) にある場合、プロセスはタイムアウトすることがあります AWS リージョン。
**注記**
デフォルトのタイムアウト値を 20 秒に増やすには、 AWS Command Line Interface (AWS CLI) で [join-domain コマンド](https://docs.aws.amazon.com/cli/latest/reference/storagegateway/join-domain.html)を実行し、時間を増やす`--timeout-in-seconds`オプションを含めることができます。また、[JoinDomain API コール](https://amazonaws.com/storagegateway/latest/APIReference/API_JoinDomain.html)を使用し、`TimeoutInSeconds` パラメータを含めてタイムアウト時間を増やすことができます。最大タイムアウト値は 3,600 秒です。
AWS CLI コマンドの実行時にエラーが発生した場合は、最新バージョンを使用していることを確認してください AWS CLI 。
## Active Directory がデフォルトの組織単位 (OU) に新しいコンピュータオブジェクトを作成することを確認する
Microsoft Active Directory に、デフォルトの OU 以外の場所に新しいコンピュータオブジェクトを作成するグループポリシーオブジェクトがないことを確認します。ゲートウェイを Active Directory ドメインに参加させる前に、新しいコンピュータオブジェクトがデフォルトの OU に存在している必要があります。一部の Active Directory 環境は、新しく作成されたオブジェクトに対して異なる OU を持つようにカスタマイズされています。ゲートウェイ VM の新しいコンピュータオブジェクトがデフォルトの OU に存在することを確認するには、ゲートウェイをドメインに参加させる前に、ドメインコントローラーでコンピュータオブジェクトを手動で作成してみてください。 AWS CLIを使用して [join-domain コマンド](https://docs.aws.amazon.com/cli/latest/reference/storagegateway/join-domain.html)を実行することもできます。その場合は、`--organizational-unit` のオプションを指定します。
**注記**
コンピュータオブジェクトを作成するプロセスは、事前ステージングと呼ばれます。
## ドメインコントローラーのイベントログの確認
前のセクションで説明した他のすべての確認事項と設定を試した後にゲートウェイをドメインに参加させられない場合は、ドメインコントローラーのイベントログを調べることを推奨します。ドメインコントローラーのイベントビューワーにエラーがないか確認します。ゲートウェイクエリがドメインコントローラーに到達していることを確認します。
# トラブルシューティング: ゲートウェイのアクティベーション中の内部エラー
Storage Gateway のアクティベーションリクエストは、2 つのネットワークパスを通過します。クライアントによって送信される受信アクティベーションリクエストは、ポート 80 経由でゲートウェイの仮想マシン (VM) または Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに接続します。ゲートウェイがアクティベーションリクエストを正常に受信すると、ゲートウェイは Storage Gateway エンドポイントと通信してアクティベーションキーを受け取ります。ゲートウェイが Storage Gateway エンドポイントに到達できない場合、ゲートウェイは内部エラーメッセージでクライアントに応答します。
AWS Storage Gatewayをアクティベートしようとしたときに内部エラーメッセージが表示された場合は、次のトラブルシューティング情報を使用して対処方法を決定します。
**注記**
必ず最新の仮想マシンイメージファイルまたは Amazon マシンイメージ (AMI) バージョンを使用して、新しいゲートウェイをデプロイしてください。古い AMI を使用するゲートウェイをアクティベートしようとすると、内部エラーが表示されます。
AMI をダウンロードする前に、デプロイする正しいゲートウェイタイプを選択していることを確認してください。各ゲートウェイタイプの .ova ファイルと AMI は異なっており、互換性がありません。
## パブリックエンドポイントを使用してゲートウェイをアクティベートする際のエラーを解決する
パブリックエンドポイントを使用してゲートウェイをアクティベートする際のアクティベーションエラーを解決するには、次のチェックと設定を実行します。
### 必要なポートの確認
オンプレミスにデプロイされたゲートウェイの場合、ポートがローカルファイアウォールで開いていることを確認します。Amazon EC2 インスタンスにデプロイされたゲートウェイの場合、インスタンスのセキュリティグループでポートが開いていることを確認します。ポートが開いていることを確認するには、サーバーからパブリックエンドポイントで telnet コマンドを実行します。このサーバーは、ゲートウェイと同じサブネット内にある必要があります。例えば、次の telnet コマンドは、ポート 443 への接続をテストします。
```
telnet d4kdq0yaxexbo.cloudfront.net 443
telnet storagegateway.region.amazonaws.com 443
telnet dp-1.storagegateway.region.amazonaws.com 443
telnet proxy-app.storagegateway.region.amazonaws.com 443
telnet client-cp.storagegateway.region.amazonaws.com 443
telnet anon-cp.storagegateway.region.amazonaws.com 443
```
ゲートウェイ自体がエンドポイントに到達できることを確認するには、ゲートウェイのローカル VM コンソール (オンプレミスにデプロイされたゲートウェイの場合) にアクセスします。または、ゲートウェイのインスタンス (Amazon EC2 にデプロイされたゲートウェイの場合) に SSH 接続できます。次に、ネットワーク接続テストを実行します。テストで `[PASSED]` が返されることを確認します。詳細については、「[ゲートウェイのネットワーク接続のテスト](https://docs.aws.amazon.com/filegateway/latest/filefsxw/manage-on-premises-fgw.html#MaintenanceTestGatewayConnectivity-fgw)」を参照してください。
**注記**
ゲートウェイコンソールのデフォルトのログインユーザー名は `admin` で、デフォルトのパスワードは `password` です。
### ファイアウォールのセキュリティがゲートウェイからパブリックエンドポイントに送信されたパケットを変更しないことを確認する
SSL 検査、ディープパケット検査、またはその他の形式のファイアウォールセキュリティは、ゲートウェイから送信されるパケットに干渉する可能性があります。SSL 証明書がアクティベーションエンドポイントでの所定の内容から変更されると、SSL ハンドシェイクは失敗します。進行中の SSL 検査がないことを確認するには、ポート 443 のメインアクティベーションエンドポイント (`anon-cp.storagegateway.region.amazonaws.com`) で OpenSSL コマンドを実行します。このコマンドは、ゲートウェイと同じサブネットにあるマシンから実行する必要があります。
```
$ openssl s_client -connect anon-cp.storagegateway.region.amazonaws.com:443 -servername anon-cp.storagegateway.region.amazonaws.com
```
**注記**
*region* を に置き換えます AWS リージョン。
SSL 検査が進行中でない場合、コマンドは次のような応答を返します。
```
$ openssl s_client -connect anon-cp.storagegateway.us-east-2.amazonaws.com:443 -servername anon-cp.storagegateway.us-east-2.amazonaws.com
CONNECTED(00000003)
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 CN = anon-cp.storagegateway.us-east-2.amazonaws.com
verify return:1
---
Certificate chain
0 s:/CN=anon-cp.storagegateway.us-east-2.amazonaws.com
i:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
1 s:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
i:/C=US/O=Amazon/CN=Amazon Root CA 1
2 s:/C=US/O=Amazon/CN=Amazon Root CA 1
i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
3 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
i:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
---
```
SSL 検査が進行中の場合、応答には次のような変更された証明書チェーンが表示されます。
```
$ openssl s_client -connect anon-cp.storagegateway.ap-southeast-1.amazonaws.com:443 -servername anon-cp.storagegateway.ap-southeast-1.amazonaws.com
CONNECTED(00000003)
depth=0 DC = com, DC = amazonaws, OU = AWS, CN = anon-cp.storagegateway.ap-southeast-1.amazonaws.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 DC = com, DC = amazonaws, OU = AWS, CN = anon-cp.storagegateway.ap-southeast-1.amazonaws.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/DC=com/DC=amazonaws/OU=AWS/CN=anon-cp.storagegateway.ap-southeast-1.amazonaws.com
i:/C=IN/O=Company/CN=Admin/ST=KA/L=New town/OU=SGW/emailAddress=admin@company.com
---
```
アクティベーションエンドポイントは、SSL 証明書を認識した場合にのみ SSL ハンドシェイクを受け入れます。つまり、エンドポイントへのゲートウェイのアウトバウンドトラフィックは、ネットワーク内のファイアウォールによって実行される検査から除外される必要があります。これらの検査には、SSL 検査やディープパケット検査などがあります。
### ゲートウェイの時刻同期の確認
過剰な時刻のずれがあると、SSL ハンドシェイクエラーを引き起こす可能性があります。オンプレミスゲートウェイの場合、ゲートウェイのローカル VM コンソールを使用して、ゲートウェイの時刻同期を確認できます。時刻のずれは 60 秒以下にする必要があります。詳細については、「[ゲートウェイ VM 時刻の同期](https://docs.aws.amazon.com/filegateway/latest/filefsxw/MaintenanceTimeSync-hyperv.html)」を参照してください。
**[システム時刻管理]** オプションは、Amazon EC2 インスタンスでホストされているゲートウェイでは使用できません。Amazon EC2 ゲートウェイが適切に時刻を同期できるようにするには、Amazon EC2 インスタンスがポート UDP と TCP 123 経由で次の NTP サーバープールリストに接続できることを確認します。
+ time.aws.com
+ 0.amazon.pool.ntp.org
+ 1.amazon.pool.ntp.org
+ 2.amazon.pool.ntp.org
+ 3.amazon.pool.ntp.org
## Amazon VPC エンドポイントを使用してゲートウェイをアクティベートする際のエラーの解決
Amazon Virtual Private Cloud (Amazon VPC) エンドポイントを使用してゲートウェイをアクティベートする際のアクティベーションエラーを解決するには、次のチェックと設定を実行します。
### 必要なポートの確認
ローカルファイアウォール (オンプレミスにデプロイされたゲートウェイの場合) またはセキュリティグループ (Amazon EC2 にデプロイされたゲートウェイの場合) 内の必要なポートが開いていることを確認します。Storage Gateway VPC エンドポイントにゲートウェイを接続するために必要なポートは、ゲートウェイをパブリックエンドポイントに接続するときに必要なポートとは異なります。Storage Gateway VPC エンドポイントに接続するには、次のポートが必要です。
+ TCP 443
+ TCP 1026
+ TCP 1027
+ TCP 1028
+ TCP 1031
+ TCP 2222
詳細については、「[Storage Gateway 用の VPC エンドポイントの作成](https://docs.aws.amazon.com/filegateway/latest/filefsxw/gateway-private-link.html#create-vpc-endpoint)」を参照してください。
さらに、Storage Gateway VPC エンドポイントにアタッチされているセキュリティグループを確認します。エンドポイントにアタッチされたデフォルトのセキュリティグループでは、必要なポートが許可されない場合があります。ゲートウェイの IP アドレス範囲からのトラフィックを必要なポート経由で許可する新しいセキュリティグループを作成します。次に、そのセキュリティグループを VPC エンドポイントにアタッチします。
**注記**
[Amazon VPC コンソール](https://console.aws.amazon.com//vpc/)を使用して、VPC エンドポイントにアタッチされているセキュリティグループを検証します。コンソールから Storage Gateway VPC エンドポイントを表示し、**[セキュリティグループ]** タブを選択します。
必要なポートが開いていることを確認するには、Storage Gateway VPC エンドポイントで telnet コマンドを実行できます。これらのコマンドは、ゲートウェイと同じサブネットにあるサーバーから実行する必要があります。アベイラビリティーゾーン (AZ) を指定していない最初の DNS 名でテストを実行できます。例えば、次の telnet コマンドは、DNS 名 vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com を使用して必要なポート接続をテストします。
```
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 443
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1026
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1027
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1028
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1031
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 2222
```
### ファイアウォールのセキュリティがゲートウェイから Storage Gateway Amazon VPC エンドポイントに送信されたパケットを変更しないことの確認
SSL 検査、ディープパケット検査、またはその他の形式のファイアウォールセキュリティは、ゲートウェイから送信されるパケットに干渉する可能性があります。SSL 証明書がアクティベーションエンドポイントでの所定の内容から変更されると、SSL ハンドシェイクは失敗します。SSL 検査が進行中でないことを確認するには、Storage Gateway VPC エンドポイントで OpenSSL コマンドを実行します。このコマンドは、ゲートウェイと同じサブネットにあるマシンから実行する必要があります。必要なポートごとにコマンドを実行します。
```
$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:443 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1026 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1027 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1028 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1031 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:2222 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
```
SSL 検査が進行中でない場合、コマンドは次のような応答を返します。
```
openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1027 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
CONNECTED(00000005)
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 CN = anon-cp.storagegateway.us-east-1.amazonaws.com
verify return:1
---
Certificate chain
0 s:CN = anon-cp.storagegateway.us-east-1.amazonaws.com
i:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
1 s:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
i:C = US, O = Amazon, CN = Amazon Root CA 1
2 s:C = US, O = Amazon, CN = Amazon Root CA 1
i:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
3 s:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
i:C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority
---
```
SSL 検査が進行中の場合、応答には次のような変更された証明書チェーンが表示されます。
```
openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1027 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
CONNECTED(00000005)
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 DC = com, DC = amazonaws, OU = AWS, CN = anon-cp.storagegateway.us-east-1.amazonaws.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/DC=com/DC=amazonaws/OU=AWS/CN=anon-cp.storagegateway.us-east-1.amazonaws.com
i:/C=IN/O=Company/CN=Admin/ST=KA/L=New town/OU=SGW/emailAddress=admin@company.com
---
```
アクティベーションエンドポイントは、SSL 証明書を認識した場合にのみ SSL ハンドシェイクを受け入れます。つまり、必要なポートを介した VPC エンドポイントへのゲートウェイのアウトバウンドトラフィックは、ネットワークファイアウォールによって実行される検査から除外されます。そのような検査には、SSL 検査やディープパケット検査などがあります。
### ゲートウェイの時刻同期の確認
過剰な時刻のずれがあると、SSL ハンドシェイクエラーを引き起こす可能性があります。オンプレミスゲートウェイの場合、ゲートウェイのローカル VM コンソールを使用して、ゲートウェイの時刻同期を確認できます。時刻のずれは 60 秒以下にする必要があります。詳細については、「[ゲートウェイ VM 時刻の同期](https://docs.aws.amazon.com/filegateway/latest/filefsxw/MaintenanceTimeSync-hyperv.html)」を参照してください。
**[システム時刻管理]** オプションは、Amazon EC2 インスタンスでホストされているゲートウェイでは使用できません。Amazon EC2 ゲートウェイが適切に時刻を同期できるようにするには、Amazon EC2 インスタンスがポート UDP と TCP 123 経由で次の NTP サーバープールリストに接続できることを確認します。
+ 0.amazon.pool.ntp.org
+ 1.amazon.pool.ntp.org
+ 2.amazon.pool.ntp.org
+ 3.amazon.pool.ntp.org
### HTTP プロキシをチェックして関連するセキュリティグループ設定の確認
アクティベーションの前に、Amazon EC2 の HTTP プロキシがオンプレミスゲートウェイ VM でポート 3128 の Squid プロキシとして設定されているかどうかを確認します。この場合は次の点を確認します。
+ Amazon EC2 の HTTP プロキシにアタッチされたセキュリティグループには、インバウンドルールが必要です。このインバウンドルールでは、ゲートウェイ VM の IP アドレスからのポート 3128 上の Squid プロキシトラフィックを許可する必要があります。
+ Amazon EC2 VPC エンドポイントにアタッチされたセキュリティグループには、インバウンドルールが必要です。これらのインバウンドルールでは、Amazon EC2 の HTTP プロキシの IP アドレスからポート 1026～1028、1031、2222、443 へのトラフィックを許可する必要があります。
## パブリックエンドポイントを使用してゲートウェイをアクティベートし、同じ VPC に Storage Gateway VPC エンドポイントがある場合のエラーの解決
同じ VPC に Amazon Virtual Private Cloud (Amazon VPC) エンポイントがある場合にパブリックエンドポイントを使用してゲートウェイをアクティベートする際のエラーを解決するには、次のチェックと設定を実行します。
### Storage Gateway VPC エンドポイントで **[プライベート DNS 名を有効にする]** 設定が有効になっていないことの確認
**[プライベート DNS 名を有効にする]** が有効になっている場合、その VPC からパブリックエンドポイントへのゲートウェイをアクティベートすることはできません。
**プライベート DNS 名オプションを無効にするには:**
1. [Amazon VPC コンソール](https://console.aws.amazon.com//vpc/) を開きます。
1. ナビゲーションペインで、**[エンドポイント]** を選択します。
1. Storage Gateway VPC エンドポイントを選択します。
1. **[アクション]** を選択します。
1. **[プライベート DNS 名の管理]** を選択します。
1. **[プライベート DNS 名を有効にする]** で、**[このエンドポイントを有効にする]** を選択します。
1. **[プライベート DNS 名の変更]** を選択して設定を保存します。
# トラブルシューティング: オンプレミスゲートウェイに関する問題
オンプレミスゲートウェイの操作で発生する可能性がある一般的な問題と、トラブルシューティングに役立つゲートウェイへの接続を サポート に許可する方法については、以下を参照してください。
次の表は、オンプレミスのゲートウェイを使用しているときに起こりうる典型的な問題を一覧にしたものです。
| 問題 | 実行するアクション |
| --- | --- |
| ゲートウェイの IP アドレスが見つかりません。 | ハイパーバイザークライアントを使用してホストに接続し、ゲートウェイの IP アドレスを見つけます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/filegateway/latest/filefsxw/troubleshooting-on-premises-gateway-issues.html) それでもゲートウェイ IP アドレスが見つからない場合は、 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/filegateway/latest/filefsxw/troubleshooting-on-premises-gateway-issues.html) |
| ネットワークまたはファイアウォールに問題があります。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/filegateway/latest/filefsxw/troubleshooting-on-premises-gateway-issues.html) |
| Storage Gateway マネジメントコンソールで **[アクティブ化に進む]** ボタンをクリックすると、ゲートウェイのアクティベーションは失敗します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/filegateway/latest/filefsxw/troubleshooting-on-premises-gateway-issues.html) |
| ゲートウェイと AWSの間の帯域幅を改善する必要があります。 | アプリケーションとゲートウェイ VM を接続するネットワークアダプタ (NIC) AWS で へのインターネット接続を設定 AWS することで、ゲートウェイから への帯域幅を向上させることができます。このアプローチは、 への高帯域幅接続があり、特にスナップショットの復元中に帯域幅の競合を回避 AWS したい場合に便利です。高スループットのワークロードが要求される場合、[Direct Connect](https://aws.amazon.com/directconnect/) を使用して、オンプレミスのゲートウェイと AWSの間の専用ネットワーク接続を確立できます。ゲートウェイから への接続の帯域幅を測定するには AWS、ゲートウェイの `CloudBytesDownloaded`および `CloudBytesUploaded`メトリクスを使用します。この詳細については、「[パフォーマンスと最適化](Performance.md)」を参照してください。インターネット接続を改善すれば、アップロードバッファがいっぱいになることがありません。 |
| ゲートウェイへのスループットまたはゲートウェイからのスループットがゼロに落ちます。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/filegateway/latest/filefsxw/troubleshooting-on-premises-gateway-issues.html) Amazon CloudWatch コンソールにゲートウェイとの双方向のスループットを表示できます。ゲートウェイとの間のスループットの測定の詳細については AWS、「」を参照してください[パフォーマンスと最適化](Performance.md)。 |
| Microsoft Hyper-V への Storage Gateway のインポート (デプロイ) に問題がある。 | 「[トラブルシューティング: Microsoft Hyper-V セットアップ](troubleshooting-hyperv-setup.md)」を参照してください。ここでは、Microsoft Hyper-V でゲートウェイをデプロイするための一般的な問題を説明しています。 |
| 「ゲートウェイのボリュームに書き込まれたデータが AWS内に安全に保存されていません」というメッセージを受信する。 | このメッセージを受信するのは、ゲートウェイ VM が別のゲートウェイ VM のクローンまたはスナップショットから作成された場合です。そうでない場合は、 サポートにお問い合わせください。 |
## オンプレミスでホストされているゲートウェイのトラブルシューティングに役立つ サポート アクセスを有効にする
Storage Gateway には、ゲートウェイの問題のトラブルシューティングに役立つゲートウェイ サポート へのアクセスの許可など、いくつかのメンテナンスタスクの実行に使用できるローカルコンソールが用意されています。デフォルトでは、ゲートウェイ サポート へのアクセスはオフになっています。このアクセスは、ホストのローカルコンソールを通じて有効にできます。ゲートウェイ サポート へのアクセスを許可するには、まずホストのローカルコンソールにログインし、Storage Gateway のコンソールに移動して、サポートサーバーに接続します。
**ゲートウェイ サポート へのアクセスを有効にするには**
1. ホストのローカルコンソールにログインします。
+ VMware ESXi – 詳細については、「[VMware ESXi でゲートウェイのローカルコンソールにアクセスする](accessing-local-console.md#MaintenanceConsoleWindowVMware-common)」を参照してください。
+ Microsoft Hyper-V – 詳細については、「[Microsoft Hyper-V でゲートウェイのローカルコンソールにアクセスする](accessing-local-console.md#MaintenanceConsoleWindowHyperV-common)」を参照してください。
1. プロンプトで、対応する番号を入力して **[ゲートウェイコンソール]** を選択します。
1. 「**h**」と入力して、利用可能なコマンドのリストを開きます。
1.
次のいずれかを行います。
+ ゲートウェイでパブリックエンドポイントを使用している場合は、**[AVAILABLE COMMANDS]** (利用可能なコマンド) ウィンドウに「**open-support-channel**」と入力して、Storage Gateway のカスタマーサポートに接続します。 AWSへのサポートチャネルを開くことがでるように、TCP ポート 22 を許可します。カスタマーサポートに接続する際、Storage Gateway はサポート番号を割り当てます。サポート番号を書き留めます。
+ ゲートウェイが VPC エンドポイントを使用している場合は、**[AVAILABLE COMMANDS (利用可能なコマンド)]** ウィンドウで「**open-support-channel**」と入力します。ゲートウェイがアクティベートされていない場合は、Storage Gateway のカスタマーサポートに接続する VPC エンドポイントまたは IP アドレスを指定します。 AWSへのサポートチャネルを開くことがでるように、TCP ポート 22 を許可します。カスタマーサポートに接続する際、Storage Gateway はサポート番号を割り当てます。サポート番号を書き留めます。
**注記**
チャネル番号は Transmission Control Protocol/User Datagram Protocol (TCP/UDP) ポート番号ではありません。代わりに、ゲートウェイが Storage Gateway サーバーへの Secure Shell (SSH) (TCP 22) 接続を作成し接続のサポートチャネルを提供します。
1. サポートチャネルが確立されたら、 サポート がトラブルシューティングのサポートを提供 サポート できるように、サポートサービス番号を に提供します。
1. サポートセッションが完了したら、「**q**」と入力してセッションを終了します。サポートセッションが完了したことを Amazon Web Services サポートが通知するまでは、セッションを終了しないようにします。
1. 「**exit**」と入力して、Storage Gateway コンソールからログアウトします。
1. プロンプトに従ってローカルコンソールを終了します。
# トラブルシューティング: Microsoft Hyper-V セットアップ
次の表は、Microsoft Hyper-V プラットフォームに Storage Gateway をデプロイする際に発生する可能性がある一般的な問題の一覧です。
| 問題 | 実行するアクション |
| --- | --- |
| ゲートウェイをインポートしようとすると、次のエラーメッセージが表示されます。 「仮想マシンのインポート中にサーバーエラーが発生しました。インポートに失敗しました。場所 [...] では、仮想マシンのインポートファイルが見つかりません。Hyper-V を使用して仮想マシンを作成してエクスポートする場合にのみ、仮想マシンをインポートできます。」 | このエラーは、次の原因で発生することがあります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/filegateway/latest/filefsxw/troubleshooting-hyperv-setup.html) |
| ゲートウェイをインポートしようとすると、次のエラーメッセージが表示されます。 「仮想マシンのインポート中にサーバーエラーが発生しました。インポートに失敗しました。インポートタスクは [...] からファイルをコピーできませんでした。ファイルが存在しています。(0x80070050)」 | 既にゲートウェイをデプロイしていて、仮想ハードディスクファイルと仮想マシン構成ファイルを保存するデフォルトのフォルダを再利用しようとすると、このエラーが発生します。この問題を修正するには、**[Hyper-V の設定]** ダイアログボックスの左側にあるパネルで、**[サーバー]** の下に新しい場所を指定します。 |
| ゲートウェイをインポートしようとすると、次のエラーメッセージが表示されます。 「仮想マシンのインポート中にサーバーエラーが発生しました。インポートに失敗しました。インポートが失敗したのは、仮想マシンには新しい識別子が必要だからです。新しい識別子を選択して、インポートを再試行してください」。 | ゲートウェイをインポートするときは、**[仮想マシンをインポート]** ダイアログボックスで、**[仮想マシンをコピー]** を選択し、**[すべてのファイルを複製]** ボックスをオンにしていることを確認して、VM の新しい固有の ID を作成します。 |
| ゲートウェイ VM を起動しようとすると、次のエラーメッセージが表示されます。 「選択した仮想マシンを起動しようとしたときにエラーが発生しました。子パーティションのプロセッサの設定は、親パーティションと互換性がありません。「AWS-Storage-Gateway」を初期化できませんでした。(仮想マシン ID [...])」 | このエラーは通常、ゲートウェイで必要とされる CPU と、ホストで使用可能な CPU の不一致が原因で発生します。VM の CPU 数が、基本ハイパーバイザーでサポートされていることを確認します。 Storage Gateway の要件の詳細については、「[ファイルゲートウェイのセットアップ要件](Requirements.md)」を参照してください。 |
| ゲートウェイ VM を起動しようとすると、次のエラーメッセージが表示されます。 「選択した仮想マシンを起動しようとしたときにエラーが発生しました。「AWS-Storage-Gateway」を初期化できませんでした。(仮想マシン ID [...]) パーティションの作成に失敗しました。リクエストされたサービスを完了するためのシステムリソースが不足しています。(0x800705AA)」 | このエラーは通常、ゲートウェイで必要とされる RAM と、ホストで使用可能な RAM の不一致が原因で発生します。 Storage Gateway の要件の詳細については、「[ファイルゲートウェイのセットアップ要件](Requirements.md)」を参照してください。 |
| スナップショットとゲートウェイソフトウェアのアップデートが、予想とわずかに異なる時刻に発生します。 | ゲートウェイの VM のクロックが実際の時刻からずれている可能性があります (クロックドリフトと呼ばれています)。ローカルゲートウェイコンソールの時刻同期オプションを使って、VM の時刻を確認して修正します。詳細については、「[ゲートウェイの Network Time Protocol (NTP) サーバーの設定](MaintenanceTimeSync-fgw.md)」を参照してください。 |
| 解凍済みの Microsoft Hyper-V Storage Gateway ファイルを、ホストファイルシステムに保存する必要があります。 | 一般的な Microsoft Windows サーバーと同じようにホストにアクセスします。たとえば、ハイパーバイザーホストの名前が `hyperv-server` の場合、UNC パス `\\hyperv-server\c$` という UNC パスを使用できます。このパスは `hyperv-server` という名前が解決可能であるか、あるいはローカルホストファイルで定義されていることを前提としています。 |
| ハイパーバイザーへの接続時に、認証情報の入力を求められます。 | Sconfig.cmd ツールを使って、ハイパーバイザーホストのローカル管理者として、自分のユーザー認証情報を追加します。 |
| Broadcom ネットワークアダプタを使用する Hyper-V ホストで仮想マシンキュー (VMQ) をオンにすると、ネットワークパフォーマンスが低下することがあります。 | 回避策については、Microsoft のドキュメントの「[Poor network performance on virtual machines on a Windows Server 2012 Hyper-V host if VMQ is turned on](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/poor-network-performance-hyper-v-host-vm)」を参照してください。 |
# トラブルシューティング: Amazon EC2 ゲートウェイに関する問題
以下のセクションでは、Amazon EC2 にデプロイされているゲートウェイを操作しているときに発生する可能性がある一般的な問題について説明します。オンプレミスのゲートウェイと Amazon EC2 にデプロイされているゲートウェイの違いに関する詳細については、「[FSx ファイルゲートウェイ用のデフォルトの Amazon EC2 ホストをデプロイするFSx ファイルゲートウェイ用にカスタマイズされた Amazon EC2 ホストをデプロイする](ec2-gateway-file.md)」を参照してください。
**Topics**
+ [しばらくしてもゲートウェイのアクティベーションが実行されない](#activation-issues)
+ [インスタンスリストに EC2 ゲートウェイインスタンスがない](#find-instance)
+ [Amazon EC2 シリアルコンソールを使用してゲートウェイインスタンスに接続したい](#ec2-serial-console)
+ [Amazon EC2 ゲートウェイ サポート のトラブルシューティングを支援したい](#EC2-EnableAWSSupportAccess)
## しばらくしてもゲートウェイのアクティベーションが実行されない
Amazon EC2 コンソールで以下を確認します。
+ インスタンスに関連付けられているセキュリティグループでポート 80 が有効になっているか。セキュリティグループのルールの追加に関する詳細については、「*Amazon EC2 ユーザーガイド*」の「[セキュリティグループルールの追加](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html#adding-security-group-rule)」を参照してください。
+ ゲートウェイインスタンスに実行中の印が付いています。Amazon EC2 コンソールで、インスタンスの **[状態]** 値が RUNNING になっている必要があります。
+ Amazon EC2 インスタンスタイプが「[ストレージの要件](Requirements.md#requirements-storage)」で説明されている最低要件を満たしていることを確認します。
問題を修正したら、ゲートウェイを再度アクティベートしてみてください。これを行うには、Storage Gateway コンソールを開き、**[Deploy a new Gateway on Amazon EC2]** を選択し、インスタンスの IP アドレスを再入力します。
## インスタンスリストに EC2 ゲートウェイインスタンスがない
インスタンスにリソースタグを指定せずに多くのインスタンスを実行中の場合は、起動したインスタンスの判断が困難になることがあります。この場合、ゲートウェイインスタンスを見つけるために、次のアクションを実行できます。
+ インスタンスの **[説明]** タブで、Amazon マシンイメージ (AMI) の名前を確認します。Storage Gateway AMI を基礎とするインスタンスは、「**aws-storage-gateway-ami**」というテキストで始まります。
+ Storage Gateway AMI を基礎とするインスタンスが複数ある場合、インスタンスの起動時間を確認してインスタンスを見分けます。
## Amazon EC2 シリアルコンソールを使用してゲートウェイインスタンスに接続したい
Amazon EC2 シリアルコンソールを使用して、起動、ネットワーク設定、およびその他の問題のトラブルシューティングができます。手順とトラブルシューティングのヒントについては、「*Amazon Elastic Compute Cloud ユーザーガイド*」の「[Amazon EC2 シリアルコンソール](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-serial-console.html)」を参照してください。
## Amazon EC2 ゲートウェイ サポート のトラブルシューティングを支援したい
Storage Gateway には、ゲートウェイの問題のトラブルシューティングに役立つゲートウェイ サポート へのアクセスの許可など、いくつかのメンテナンスタスクの実行に使用できるローカルコンソールが用意されています。デフォルトでは、ゲートウェイ サポート へのアクセスはオフになっています。このアクセスを有効にするには、Amazon EC2 ローカルコンソールを使用します。Amazon EC2 ローカルコンソールは、Secure Shell (SSH) を使用してログインします。SSH を使用して正常にログインするために、インスタンスのセキュリティグループには、TCP ポート 22 を開くルールが必要です。
**注記**
既存のセキュリティグループに新しいルールを追加すると、新しいルールが、そのセキュリティグループを使用するすべてのインスタンスに適用されます。セキュリティグループと、セキュリティグループルールの追加方法については、*Amazon EC2 ユーザーガイド*の「[Amazon EC2 とは](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html)」を参照してください。
がゲートウェイ サポート に接続できるようにするには、まず Amazon EC2 インスタンスのローカルコンソールにログインし、Storage Gateway のコンソールに移動して、アクセスを提供します。
**Amazon EC2 インスタンスにデプロイされたゲートウェイの サポート アクセスを有効にするには**
1. Amazon EC2 インスタンスのローカルコンソールにログインします。手順については、「*Amazon EC2 ユーザーガイド*」の「[インスタンスへの接続](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html)」を参照してください。
次のコマンドを使用して、EC2 インスタンスのローカルコンソールにログインできます。
```
ssh –i PRIVATE-KEY admin@INSTANCE-PUBLIC-DNS-NAME
```
**注記**
*PRIVATE-KEY* は、Amazon EC2 インスタンスを起動するために使用した EC2 キーペアのプライベート証明書を含む `.pem` ファイルです。詳細については、「*Amazon EC2 ユーザーガイド*」の「[キーペアのパブリックキーを取得する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#retriving-the-public-key)」を参照してください。
*INSTANCE-PUBLIC-DNS-NAME* は、ゲートウェイが実行中の Amazon EC2 インスタンスのパブリックドメインネームシステム (DNS) です。このパブリック DNS 名を取得するには、EC2 コンソールで Amazon EC2 インスタンスを選択して、**[説明]** タブをクリックします。
1. プロンプトで「**6 - Command Prompt**」と入力して、 サポート Channel コンソールを開きます。
1. 「**h**」と入力して **[AVAILABLE COMMANDS (利用可能なコマンド)]** ウィンドウを開きます。
1. 次のいずれかを行います。
+ ゲートウェイでパブリックエンドポイントを使用している場合は、**[AVAILABLE COMMANDS]** (利用可能なコマンド) ウィンドウに「**open-support-channel**」と入力して、Storage Gateway のカスタマーサポートに接続します。 AWSへのサポートチャネルを開くことがでるように、TCP ポート 22 を許可します。カスタマーサポートに接続する際、Storage Gateway はサポート番号を割り当てます。サポート番号を書き留めます。
+ ゲートウェイが VPC エンドポイントを使用している場合は、**[AVAILABLE COMMANDS (利用可能なコマンド)]** ウィンドウで「**open-support-channel**」と入力します。ゲートウェイがアクティベートされていない場合は、Storage Gateway のカスタマーサポートに接続する VPC エンドポイントまたは IP アドレスを指定します。 AWSへのサポートチャネルを開くことがでるように、TCP ポート 22 を許可します。カスタマーサポートに接続する際、Storage Gateway はサポート番号を割り当てます。サポート番号を書き留めます。
**注記**
チャネル番号は Transmission Control Protocol/User Datagram Protocol (TCP/UDP) ポート番号ではありません。代わりに、ゲートウェイが Storage Gateway サーバーへの Secure Shell (SSH) (TCP 22) 接続を作成し接続のサポートチャネルを提供します。
1. サポートチャネルが確立されたら、 サポート がトラブルシューティングのサポートを提供 サポート できるように、サポートサービス番号を に提供します。
1. サポートセッションが完了したら、「**q**」と入力してセッションを終了します。サポートセッションが完了したことを Amazon Web Services サポートが通知するまでは、セッションを終了しないようにします。
1. 「**exit**」と入力して、Storage Gateway コンソールを終了します。
1. コンソールメニューに従って Storage Gateway インスタンスからログアウトします。
# トラブルシューティング: ハードウェアアプライアンスに関する問題
**注記**
可用性の終了通知: 2025 年 5 月 12 日をもって、 AWS Storage Gateway ハードウェアアプライアンスは提供されなくなります。 AWS Storage Gateway ハードウェアアプライアンスの既存のお客様は、2028 年 5 月まで引き続き を使用し、サポートを受けることができます。別の方法として、 AWS Storage Gateway サービスを使用して、オンプレミスおよびクラウド内のアプリケーションに事実上無制限のクラウドストレージへのアクセスを許可することもできます。
以下のトピックでは、 AWS Storage Gateway ハードウェアアプライアンスで発生する可能性のある問題と、それらのトラブルシューティングに関する提案について説明します。
**Topics**
+ [サービスの IP アドレスを特定できない](#service_ip_address)
+ [工場出荷時設定へのリセットを実行するにはどうすればよいですか](#factory_reset)
+ [リモート再起動を実行するにはどうすればよいですか](#remote-restart)
+ [Dell iDRAC のサポートを受けるにはどうすればよいですか](#iDRAC_support)
+ [ハードウェアアプライアンスのシリアル番号が見つからない](#appliance_serial_number)
+ [ハードウェアアプライアンスのサポートの依頼先](#appliance_support)
## サービスの IP アドレスを特定できない
ご利用のサービスに接続するときは、ホストの IP アドレスではなく、サービスの IP アドレスを使用していることを確認します。サービスのコンソールでサービスの IP アドレスを設定し、ハードウェアコンソールでホストの IP アドレスを設定します。ハードウェアコンソールは、ハードウェアアプライアンスを起動すると表示されます。ハードウェアコンソールからサービスコンソールにアクセスするには、**[サービスコンソールを開く]** を選択します。
## 工場出荷時設定へのリセットを実行するにはどうすればよいですか
アプライアンスでファクトリリセットを実行する必要がある場合は、以下のサポートセクションで説明されているように、 AWS Storage Gateway ハードウェアアプライアンスチームにサポートを依頼してください。
## リモート再起動を実行するにはどうすればよいですか
アプライアンスをリモートで再起動する必要がある場合は、Dell iDRAC の管理インターフェイスを使用して実行できます。詳細については、Dell Technologies InfoHub ウェブサイトの「[iDRAC9 Virtual Power Cycle: Remotely power cycle Dell EMC PowerEdge Servers](https://infohub.delltechnologies.com/en-us/p/idrac9-virtual-power-cycle-remotely-power-cycle-dell-emc-poweredge-servers/)」を参照してください。
## Dell iDRAC のサポートを受けるにはどうすればよいですか
Dell PowerEdge サーバーには、Dell iDRAC 管理インターフェイスが搭載されています。次の構成を推奨します。
+ iDRAC 管理インターフェイスを使用する場合は、デフォルトのパスワードを変更する必要があります。iDRAC 認証情報の詳細については、「[Dell PowerEdge - What is the default sign-in credentials for iDRAC?](https://www.dell.com/support/article/en-us/sln306783/dell-poweredge-what-is-the-default-username-and-password-for-idrac?lang=en)」を参照してください。
+ セキュリティ違反を防ぐため、ファームウェアが最新であることを確認します。
+ iDRAC ネットワークインターフェイスを通常の (`em`) ポートに移動すると、パフォーマンスの問題が発生したり、アプライアンスの通常の機能を妨げたりする可能性があります。
## ハードウェアアプライアンスのシリアル番号が見つからない
Storage AWS Storage Gateway Gateway ハードウェアアプライアンスのシリアル番号を確認できます。
**ハードウェアアプライアンスのシリアル番号を確認するには:**
1. Storage Gateway コンソール ([https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/)) を開きます。
1. ページの左側のナビゲーションメニューから **[ハードウェア]** を選択します。
1. リストからハードウェアアプライアンスを選択します。
1. アプライアンスの **[詳細]** タブで **[シリアル番号]** フィールドを見つけます。
## ハードウェアアプライアンスのサポートの依頼先
ハードウェアアプライアンスのテクニカルサポート AWS については、「」を参照してください[サポート](https://aws.amazon.com/contact-us)。
サポート チームは、ゲートウェイの問題をリモートでトラブルシューティングするために、サポートチャネルをアクティブ化するよう求める場合があります。このポートは、ゲートウェイの通常のオペレーションでは開いておく必要はありませんが、トラブルシューティングでは必要です。以下の手順に示すように、ハードウェアコンソールからサポートチャネルをアクティベートすることができます。
**のサポートチャネルを開くには AWS**
1. ハードウェアコンソールを開きます。
1. ハードウェアコンソールのメインページの下部にある **[サポートチャネルを開く]** を選択し、`Enter` を押します。
ネットワーク接続やファイアウォールに問題がなければ、割り当てられたポート番号が 30 秒以内に表示されます。例えば、次のようになります。
**ステータス: ポート 19599 で開く**
1. ポート番号を書き留めて指定します サポート。
# トラブルシューティング: ファイルゲートウェイに関する問題
Amazon CloudWatch ロググループにログエントリを書き込むようにファイルゲートウェイを設定できます。その場合は、ファイルゲートウェイのヘルスステータスと、ゲートウェイで発生したエラーに関する通知が表示されます。CloudWatch ログで、これらのエラーおよびヘルス通知に関する情報を参照できます。
以下のセクションでは、各エラーとヘルス通知の原因、およびその問題の修正方法を理解するのに役立つ情報が見つかります。
**Topics**
+ [エラー: FileMissing](#troubleshoot-logging-errors-filemissing)
+ [エラー: FsxFileSystemAuthenticationFailure](#troubleshoot-logging-errors-fsxfilesystemauthenticationfailure)
+ [エラー: FsxFileSystemConnectionFailure](#troubleshoot-logging-errors-fsxfilesystemconnectionfailure)
+ [エラー: FsxFileSystemFull](#troubleshoot-logging-errors-fsxfilesystemfull)
+ [エラー: GatewayClockOutOfSync](#troubleshoot-logging-errors-gatewayclockoutofsync)
+ [エラー: InvalidFileState](#troubleshoot-logging-errors-invalidfilestate)
+ [エラー: ObjectMissing](#troubleshoot-logging-errors-objectmissing)
+ [エラー: DroppedNotifications](#troubleshoot-logging-errors-droppednotifications)
+ [通知: HardReboot](#troubleshoot-hardreboot-notification)
+ [通知: リブート](#troubleshoot-reboot-notification)
+ [トラブルシューティング: Active Directory ドメインに関する問題](#troubleshooting-ad-domain)
+ [トラブルシューティング: CloudWatch メトリクスの使用](#troubleshooting-with-cw-metrics)
## エラー: FileMissing
`FileMissing` エラーは `ObjectMissing` エラーに似ており、解決する手順は同じです。指定されたファイルゲートウェイ以外のライターが、指定ファイルを Amazon FSx から削除すると、`FileMissing` エラーが発生する場合があります。以降、Amazon FSx へのオブジェクトのアップロード、または Amazon FSx からのオブジェクトの取得は失敗します。
**FileMissing エラーを解決するには**
1. ファイルの最新のコピーを SMB クライアントのローカルファイルシステムに保存します (ステップ 3 でこのファイルのコピーが必要です)。
1. SMB クライアントを使用して、ファイルゲートウェイからファイルを削除します。
1. SMB クライアントを使用して、ステップ 1 Amazon FSx で保存したファイルの最新バージョンをコピーします。この操作はファイルゲートウェイを介して行います。
## エラー: FsxFileSystemAuthenticationFailure
ファイルシステムをアタッチする際に指定した認証情報の有効期限が切れている場合、またはその権限が取り消されている場合、`FsxFileSystemAuthenticationFailure` エラーが発生することがあります。
**FsxFileSystemAuthenticationFailure エラーを解決するには**
1. Amazon FSx ファイルシステムのアタッチ時に指定した認証情報がまだ有効であることを確認します。
1. 「[Amazon FSx for Windows File Server ファイルシステムのアタッチ](https://docs.aws.amazon.com/filegateway/latest/filefsxw/attach-fsxw-filesystem.html)」で説明されているように、ユーザーにすべての必要なアクセス許可があることを確認します。
## エラー: FsxFileSystemConnectionFailure
Amazon FSx サーバーがゲートウェイマシンからアクセスできない場合、`FsxFileSystemConnectionFailure` エラーが発生することがあります。
**FsxFileSystemConnectionFailure エラーを解決するには**
1. すべてのファイアウォールと VPC ルールで、ゲートウェイマシンと Amazon FSx サーバー間の接続が許可されていることを確認します。
1. Amazon FSx サーバーが実行中であることを確認します。
## エラー: FsxFileSystemFull
Amazon FSx ファイルシステムに十分な空きディスク容量がない場合、`FsxFileSystemFull`エラーが発生することがあります。
**FsxFileSystemFull エラーを解決するには**
+ Amazon FSx ファイルシステムのストレージ容量を増やします。
## エラー: GatewayClockOutOfSync
ゲートウェイがローカルシステム時刻と AWS Storage Gatewayサーバーによって報告された時刻の差を 5 分以上検出すると、`GatewayClockOutOfSync`エラーが発生することがあります。クロック同期の問題は、ゲートウェイと 間の接続に悪影響を及ぼす可能性があります AWS。ゲートウェイクロックが同期していない場合、NFS および SMB の接続で I/O エラーが発生し、SMB ユーザーに認証エラーが発生する可能性があります。
**GatewayClockOutOfSync エラーを解決するには**
+ ゲートウェイと NTP サーバー間のネットワーク設定を確認します。ゲートウェイ VM 時刻の同期と NTP サーバー設定の更新の詳細については、「[ゲートウェイのネットワークタイムプロトコル (NTP) サーバーの設定](https://docs.aws.amazon.com/filegateway/latest/filefsxw/manage-on-premises-fgw.html#MaintenanceTimeSync-fgw)」を参照してください。
## エラー: InvalidFileState
指定されたゲートウェイ以外のライターが、指定されたファイル共有内の指定されたファイルを変更すると、`InvalidFileState` エラーが発生する場合があります。その結果、ファイルゲートウェイのファイルの状態が Amazon FSx のファイルの状態と一致しなくなります。以降、Amazon FSx からのファイルのアップロードまたは取得は失敗する可能性があります。
**InvalidFileState エラーを解決するには**
1. ファイルの最新のコピーを SMB クライアントのローカルファイルシステムに保存します (ステップ 4 でこのファイルのコピーが必要です)。Amazon FSx 内のファイルのバージョンが最新の場合、そのバージョンをダウンロードします。これを行うには、任意の SMB クライアントを使用して Amazon FSx 共有に直接アクセスします。
1. Amazon FSx でファイルを直接削除します。
1. SMB クライアントを使用して、ゲートウェイからファイルを削除します。
1. SMB クライアントを使用して、ステップ 1 で保存したファイルの最新バージョンを*ファイルゲートウェイ経由で* Amazon FSx にコピーします。
## エラー: ObjectMissing
指定されたファイルゲートウェイ以外のライターが、指定ファイルを Amazon FSx から削除すると、`ObjectMissing` エラーが発生する場合があります。以降、Amazon FSx へのオブジェクトのアップロード、または Amazon FSx からのオブジェクトの取得は失敗します。
**ObjectMissing エラーを解決するには**
1. ファイルの最新のコピーを SMB クライアントのローカルファイルシステムに保存します (ステップ 3 でこのファイルのコピーが必要です)。
1. SMB クライアントを使用して、ファイルゲートウェイからファイルを削除します。
1. SMB クライアントを使用して、ステップ 1 Amazon FSx で保存したファイルの最新バージョンをコピーします。この操作はファイルゲートウェイを介して行います。
## エラー: DroppedNotifications
ゲートウェイのルートディスクの空きストレージ容量が 1 GB 未満の場合や、1 分以内に 100 件を超えるヘルス通知が生成された場合、他の予想されるタイプの CloudWatch Log エントリの代わりに`DroppedNotifications` エラーが表示されることがあります。このような状況では、ゲートウェイは予防策として、詳細な CloudWatch ログ通知の生成を停止します。
**DroppedNotifications エラーを解決するには**
1. Storage Gateway コンソールのゲートウェイの **[モニタリング]** タブの `Root Disk Usage` メトリクスを確認して、使用可能なルートディスク容量が少ないかどうかを確認します。
1. 使用可能な容量が 1 GB 未満の場合は、ゲートウェイのルートストレージディスクのサイズを増やします。手順については、仮想マシンハイパーバイザーのドキュメントを参照してください。
Amazon EC2 ゲートウェイのルートディスクサイズを増やすには、「*Amazon Elastic Compute Cloud ユーザーガイド*」の「[EBS ボリュームの変更をリクエストする](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/requesting-ebs-volume-modifications.html)」を参照してください。
**注記**
AWS Storage Gateway ハードウェアアプライアンスのルートディスクサイズを増やすことはできません。
1. ゲートウェイを再起動します。
## 通知: HardReboot
ゲートウェイ VM が予期せず再起動された場合、`HardReboot` 通知が表示されることがあります。このような再起動の原因としては、電源の喪失、ハードウェア障害、またはその他のイベントが考えられます。VMware ゲートウェイの場合、vSphere High Availability のアプリケーションの監視によるリセットにより、このイベントが引き起こされることがあります。
ゲートウェイがこのような環境で実行されている場合は、`HealthCheckFailure` 通知の有無を確認し、VM の VMware イベントログを調べます。
## 通知: リブート
ゲートウェイ VM の再起動時に、再起動通知が表示される場合があります。VM ハイパーバイザーの管理コンソールまたは Storage Gateway コンソールを使用して、ゲートウェイ VM を再起動できます。また、ゲートウェイのメンテナンスサイクル中にゲートウェイソフトウェアを使用して再起動することもできます。
再起動の時刻がゲートウェイで設定された[メンテナンス開始時刻](MaintenanceManagingUpdate-common.md)から 10 分以内である場合、この再起動の発生はおそらく正常であり、問題の兆候ではありません。メンテナンスの大幅な期間外に再起動が発生した場合は、ゲートウェイを手動で再起動したかどうかを確認します。
## トラブルシューティング: Active Directory ドメインに関する問題
FSx ファイルゲートウェイは、Active Directory ドメインに関する問題についての特定のログメッセージを生成しません。ゲートウェイを Active Directory ドメインに参加させられない場合は、次の操作を行います。
+ ゲートウェイが読み取り専用ドメインコントローラー (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 サービスアカウントのアクセス許可要件](https://docs.aws.amazon.com/filegateway/latest/filefsxw/ad-serviceaccount-permissions.html)」を参照してください。
+ ゲートウェイが正しい組織単位 (OU) に参加していることを確認します。
ドメインに参加すると、ゲートウェイの**ゲートウェイ ID** をアカウント名 (SGW-1234ADE など) として使用して、デフォルトのコンピュータコンテナ (OU ではない) に Active Directory コンピュータアカウントが作成されます。このアカウントの名前をカスタマイズすることはできません。
Active Directory 環境に新しいコンピュータオブジェクト用に指定された OU がある場合は、ドメインに参加するときにその OU を指定する必要があります。
指定された OU に参加しようとしたときにアクセス拒否エラーが発生した場合は、Active Directory ドメイン管理者に確認してください。管理者は、ドメインに参加する前にゲートウェイのコンピュータアカウントを事前にステージングしておく必要がある場合があります。詳細については、「[Storage Gateway ファイルゲートウェイを Microsoft Active Directory 認証用のドメインに参加させる際の問題をトラブルシューティングするにはどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/storage-gateway-domain-join-error/)」を参照してください。
+ ゲートウェイのローカルコンソールのコマンドプロンプトから次のコマンドを実行して、ゲートウェイのホスト名が DNS で解決可能であることを確認します。強調表示された変数を、ゲートウェイの実際の値に置き換えてください。
```
dig -d ExampleHostName -r A
```
ゲートウェイにカスタムホスト名を設定した場合は、IP アドレスを指す DNS A レコードを手動で追加する必要があります。
+ ゲートウェイとドメインコントローラー間のネットワークレイテンシーが許容できる範囲で低いことを確認します。ゲートウェイが 20 秒以内にドメインコントローラーから応答を受信しない場合、ドメインに加入するクエリがタイムアウトすることがあります。
[JoinDomain](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_JoinDomain.html) CLI コマンドを使用してゲートウェイをドメインに参加させる場合は、`--timeout-in-seconds` フラグを追加してタイムアウトを最大 3,600 秒に増やすことができます。
+ ゲートウェイをドメインに参加させるために使用する Active Directory ユーザーが、そのために必要な権限を持っていることを確認します。
## トラブルシューティング: CloudWatch メトリクスの使用
Storage Gateway で Amazon CloudWatch メトリクスを使用する際の問題に対処するためのアクションについては、次を参照してください。
**Topics**
+ [ディレクトリの閲覧時にゲートウェイの反応が遅い](#slow-gateway)
+ [ゲートウェイが応答しない](#gateway-not-responding)
+ [Amazon FSx ファイルシステムにファイルが表示されない](#files-missing-fsx)
+ [Amazon FSx ファイルシステムに古いスナップショットが表示されない](#snapshots-missing-fsx)
+ [ゲートウェイを介した Amazon FSx へのデータ転送速度が遅い](#slow-data-transfer-to-fsx)
+ [ゲートウェイへの書き込み時にゲートウェイのバックアップジョブが失敗する、またはエラーが発生する](#backup-job-fails)
### ディレクトリの閲覧時にゲートウェイの反応が遅い
**ls** コマンドの実行時またはディレクトリの閲覧時にファイルゲートウェイの反応が遅い場合は、`IndexFetch` および `IndexEviction` の CloudWatch メトリクスを確認します。
+ `ls` コマンドの実行時またはディレクトリの閲覧時に `IndexFetch` メトリクスが 0 を超えている場合、ファイルゲートウェイは影響を受けるディレクトリの内容に関する情報なしで起動し、FSx for Windows File Server にアクセスする必要がありました。今後そのディレクトリの内容をリストする作業の速度は上がるはずです。
+ `IndexEviction` メトリクスが 0 を超えている場合は、ファイルゲートウェイがその時点でキャッシュとして管理できる上限に達していることを意味します。この場合、ファイルゲートウェイでは、最近最もアクセスしていないディレクトリから一部のストレージ領域を解放して、新しいディレクトリをリストする必要があります。この問題が頻繁に発生し、パフォーマンスへの影響がある場合は、 にお問い合わせください サポート。
関連する Amazon FSx ファイルシステム サポート の内容と、ユースケースに基づいてパフォーマンスを向上させるための推奨事項について説明します。
### ゲートウェイが応答しない
ファイルゲートウェイが応答しない場合は、次の操作を行います。
+ 最近再起動またはソフトウェアの更新を行った場合は、`IOWaitPercent` メトリクスを確認します。このメトリクスは、未処理のディスク I/O リクエストがある場合に、CPU がアイドル状態の時間の割合を示します。場合によっては、この値が高く (10 以上)、サーバーの再起動または更新後に増えていることがあります。このような場合、ファイルゲートウェイによりインデックスのキャッシュが RAM に再構築されるため、低速のルートディスクがゲートウェイのボトルネックになっている可能性があります。より高速な物理ディスクをルートディスクに使用することにより、この問題に対処できます。
+ `MemUsedBytes` メトリクスが `MemTotalBytes` メトリクスと同じか、ほぼ同じ場合、ファイルゲートウェイで使用可能な RAM が不足しています。ファイルゲートウェイに最低限必要な RAM があることを確認してください。既にある場合は、ワークロードとユースケースに基づいて、ファイルゲートウェイに RAM を追加することを検討してください。
ファイル共有が SMB の場合は、ファイル共有に接続されている SMB クライアントの数が問題の原因である可能性もあります。任意の時点で接続しているクライアントの数を確認するには、`SMBV(1/2/3)Sessions` メトリクスをチェックします。多くのクライアントが接続されている場合、ファイルゲートウェイに RAM の追加が必要になることがあります。
### Amazon FSx ファイルシステムにファイルが表示されない
ゲートウェイ上のファイルが Amazon FSx ファイルシステムに反映されていない場合は、`FilesFailingUpload` メトリクスを確認してください。メトリクスが一部のファイルのアップロードに失敗したことを報告している場合は、ヘルス通知を確認します。ファイルのアップロードに失敗すると、ゲートウェイは問題の詳細を示したヘルス通知を生成します。
### Amazon FSx ファイルシステムに古いスナップショットが表示されない
FSx ファイルゲートウェイでの一部のファイル操作 (トップレベルフォルダの名前変更や権限変更など) は、複数のファイル操作を引き起こし、FSx for Windows File Server ファイルシステムに高い I/O 負荷をもたらす可能性があります。ファイルシステムにワークロードに十分なパフォーマンスリソースがない場合、ファイルシステムは[シャドウコピー](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/shadow-copies-fsxW.html)の保持履歴よりも継続的な I/O の可用性を優先するため、シャドウコピーを削除する可能性があります。
Amazon FSx コンソールで、「**モニタリングとパフォーマンス**」ページを見て、ファイルシステムがプロビジョニング不足かどうかを確認します。その場合は、SSD ストレージに切り替えるか、スループット容量を増やすか、または SSD IOPS を増やしてワークロードを処理することができます。
### ゲートウェイを介した Amazon FSx へのデータ転送速度が遅い
ファイルゲートウェイを介した Amazon FSx for Windows File Server へのデータ転送速度が遅い場合は、次の操作を行います。
+ `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 にアップロードできる速度よりも速く書き込みを行っている場合は、少なくともバックアップジョブのサイズに対応できるキャッシュディスクを追加します。または、アップロード帯域幅を増やします。
+ バックアップジョブが失敗しているにもかかわらず、`CachePercentDirty` メトリクスが 80 パーセント未満の場合は、ファイルゲートウェイでクライアント側のセッションがタイムアウトしている可能性があります。SMB の場合は、PowerShell コマンド `Set-SmbClientConfiguration -SessionTimeout 300` を使用してこのタイムアウトを増やすことができます。このコマンドを実行すると、タイムアウトが 300 秒に設定されます。
## 高可用性のヘルス通知
VMware vSphere High Availability (HA) プラットフォームでゲートウェイを実行すると、ヘルス通知が表示される場合があります。ヘルス通知の詳細については、「[トラブルシューティング: 高可用性に関する問題](troubleshooting-ha-issues.md)」を参照してください。
# トラブルシューティング: 高可用性に関する問題
可用性の問題が発生した場合の対処方法については、以下を参照してください。
**Topics**
+ [ヘルス通知](#ha-health-notifications)
+ [メトリクス](#ha-health-notification-metrics)
## ヘルス通知
VMware vSphere HA でゲートウェイを実行すると、すべてのゲートウェイで、設定済みの Amazon CloudWatch ロググループに対して次のヘルス通知が生成されます。これらの通知は、`AvailabilityMonitor` と呼ばれるログストリームに入ります。
**Topics**
+ [通知: リブート](#troubleshoot-reboot-notification)
+ [通知: HardReboot](#troubleshoot-hardreboot-notification)
+ [通知: HealthCheckFailure](#troubleshoot-healthcheckfailure-notification)
+ [通知: AvailabilityMonitorTest](#troubleshoot-availabilitymonitortest-notification)
### 通知: リブート
ゲートウェイ VM の再起動時に、再起動通知が表示される場合があります。VM ハイパーバイザーの管理コンソールまたは Storage Gateway コンソールを使用して、ゲートウェイ VM を再起動できます。また、ゲートウェイのメンテナンスサイクル中にゲートウェイソフトウェアを使用して再起動することもできます。
**実行するアクション**
再起動の時間がゲートウェイで設定された[メンテナンス開始時間](MaintenanceManagingUpdate-common.md)から 10 分以内である場合、これは通常の発生であり、問題の兆候ではありません。メンテナンスの大幅な期間外に再起動が発生した場合は、ゲートウェイを手動で再起動したかどうかを確認します。
### 通知: HardReboot
ゲートウェイ VM が予期せず再起動された場合、`HardReboot` 通知が表示されることがあります。このような再起動の原因としては、電源の喪失、ハードウェア障害、またはその他のイベントが考えられます。VMware ゲートウェイの場合、vSphere High Availability のアプリケーションの監視によるリセットにより、このイベントが引き起こされることがあります。
**実行するアクション**
ゲートウェイがこのような環境で実行されている場合は、`HealthCheckFailure` 通知の有無を確認し、VM の VMware イベントログを調べます。
### 通知: HealthCheckFailure
VMware vSphere HA のゲートウェイでは、ヘルスチェックが不合格になり、VM の再起動が要求されたときに `HealthCheckFailure` 通知が表示される場合があります。このイベントは、`AvailabilityMonitorTest` 通知によって示される可用性をモニタリングするためのテスト中にも発生します。この場合、`HealthCheckFailure` 通知の発生が想定されます。
**注記**
この通知は VMware ゲートウェイ専用です。
**実行するアクション**
`AvailabilityMonitorTest` 通知が表示されることなくこのイベントが繰り返し発生する場合は、VM インフラストラクチャに問題 (ストレージ、メモリなど) がないか確認してください。さらにサポートが必要な場合は、 にお問い合わせください サポート。
### 通知: AvailabilityMonitorTest
VMware vSphere HA のゲートウェイでは、VMware で[可用性とアプリケーションのモニタリング](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_StartAvailabilityMonitorTest.html)システムの[テストを実行](vmware-ha.md#vmware-ha-test-failover)すると、`AvailabilityMonitorTest` 通知が表示されます。
## メトリクス
`AvailabilityNotifications` メトリクスはすべてのゲートウェイで使用できます。このメトリクスは、ゲートウェイによって生成された可用性関連のヘルス通知の数です。`Sum` 統計情報を使用して、ゲートウェイで可用性関連のイベントが発生しているかどうかを調べます。イベントの詳細については、設定した CloudWatch ロググループを参照してください。