翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 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-file-share-issues.md) - ファイル共有で想定外の問題が発生した場合に行うアクションについて説明します。
+ [トラブルシューティング: 高可用性に関する問題](troubleshooting-ha-issues.md) - VMware HA 環境にデプロイされているゲートウェイで問題が発生した場合の対処方法について説明します。
# トラブルシューティング: Storage Gateway コンソールでゲートウェイがオフラインとなる
次のトラブルシューティング情報を使用して、 AWS Storage Gateway コンソールにゲートウェイがオフラインであると表示された場合にどう対処すべきかを判断します。
ゲートウェイは、次のいずれかの理由でオフラインと表示されている可能性があります。
+ ゲートウェイが Storage Gateway サービスエンドポイントに到達できません。
+ ゲートウェイが予期せずシャットダウンしました。
+ ゲートウェイに関連付けられたキャッシュディスクが切断または変更されたか、あるいは失敗しました。
ゲートウェイをオンラインに戻すには、ゲートウェイがオフラインになった原因となった問題を特定して解決します。
## 関連付けられたファイアウォールまたはプロキシの確認
プロキシを使用するようにゲートウェイを設定した場合、またはファイアウォールの背後にゲートウェイを配置した場合は、プロキシまたはファイアウォールのアクセスルールを確認してください。プロキシまたはファイアウォールは、Storage Gateway に必要なネットワークポートとサービスエンドポイントとの間のトラフィックを許可する必要があります。詳細については、「[ネットワークとファイアウォールの要件](https://docs.aws.amazon.com/filegateway/latest/files3/Requirements.html#networks)」を参照してください。
## ゲートウェイのトラフィックの継続的な SSL またはディープパケット検査の確認
ゲートウェイと の間のネットワークトラフィックに対して SSL またはディープパケット検査が現在実行されている場合 AWS、ゲートウェイは必要なサービスエンドポイントと通信できない可能性があります。ゲートウェイをオンラインに戻すには、検査を無効にする必要があります。
## 再起動またはソフトウェア更新後の IOWaitPercent メトリクスの確認
再起動またはソフトウェアの更新後、ファイルゲートウェイの `IOWaitPercent` メトリクスが 10 以上であるかどうかを確認します。その場合、インデックスキャッシュを RAM に再構築している間、ゲートウェイの応答が遅くなる可能性があります。詳細については、「[トラブルシューティング: CloudWatch メトリクスの使用](https://docs.aws.amazon.com/filegateway/latest/files3/troubleshooting-file-gateway-issues.html#gateway-not-responding)」を参照してください。
## ハイパーバイザーホストで停電やハードウェア障害がないかの確認
ゲートウェイのハイパーバイザーホストで停電やハードウェア障害が発生すると、ゲートウェイが想定外にシャットダウンし、アクセスできなくなる可能性があります。電源とネットワーク接続を復元すると、ゲートウェイに再びアクセスできるようになります。
ゲートウェイがオンラインに戻ったら、必ずデータを復旧する手順を実行してください。詳細については、「[ベストプラクティス: データの復旧](https://docs.aws.amazon.com/filegateway/latest/files3/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/files3/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/files3/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/files3/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/files3/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/files3/troubleshooting-on-premises-gateway-issues.html) それでもゲートウェイ IP アドレスが見つからない場合は、 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/filegateway/latest/files3/troubleshooting-on-premises-gateway-issues.html) |
| ネットワークまたはファイアウォールに問題があります。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/filegateway/latest/files3/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/files3/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/files3/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 のクローンまたはスナップショットから作成された場合です。そうでない場合は、 サポートにお問い合わせください。 |
## トラブルシューティング: セキュリティスキャンで NFS ポートの開放が検出される
特定の NFS ポートは、SMB ファイル共有でのみ使用するゲートウェイでも、デフォルトで有効になっています。Qualys などのサードパーティのセキュリティソフトウェアを使用してファイルゲートウェイがデプロイされているネットワークをスキャンする場合、スキャン結果はこれらの NFS ポートの開放を潜在的なセキュリティ脆弱性として報告することがあります。SMB ファイル共有でのみゲートウェイを使用し、セキュリティ上の理由から未使用の NFS ポートを無効にする場合は、次の手順を行います。
**ファイルゲートウェイで NFS ポートを無効にするには:**
1. [ローカルコンソールでの Storage Gateway コマンドの実行](MaintenanceGatewayConsole-fgw.md) で説明されている手順を使用して、ゲートウェイローカルコンソールのコマンドプロンプトにアクセスします。
1. NFS トラフィックを無効にするには、次のコマンドを入力します。
**IPv4**
```
iptables -I INPUT -p udp -m udp --dport 111 -j DROP
iptables -I INPUT -p udp -m udp --dport 2049 -j DROP
iptables -I INPUT -p udp -m udp --dport 20048 -j DROP
iptables -I INPUT -p tcp -m tcp --dport 111 -j DROP
iptables -I INPUT -p tcp -m tcp --dport 2049 -j DROP
iptables -I INPUT -p tcp -m tcp --dport 20048 -j DROP
```
**IPv6**
```
ip6tables -I INPUT -p udp -m udp --dport 111 -j DROP
ip6tables -I INPUT -p udp -m udp --dport 2049 -j DROP
ip6tables -I INPUT -p udp -m udp --dport 20048 -j DROP
ip6tables -I INPUT -p tcp -m tcp --dport 111 -j DROP
ip6tables -I INPUT -p tcp -m tcp --dport 2049 -j DROP
ip6tables -I INPUT -p tcp -m tcp --dport 20048 -j DROP
```
1. 次のコマンドを入力して、ブロックされた NFS ポートが IP テーブルに表示されることを確認します。
**IPv4**
```
iptables -n -L -v --line-numbers
```
**IPv6**
```
ip6tables -n -L -v --line-numbers
```
## オンプレミスでホストされているゲートウェイのトラブルシューティングに役立つ サポート アクセスを有効にする
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/files3/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 にデプロイされているゲートウェイの違いに関する詳細については、「[S3 ファイルゲートウェイ用のデフォルトの Amazon EC2 ホストをデプロイするS3 ファイルゲートウェイ用にカスタマイズされた Amazon EC2 ホストをデプロイする](ec2-gateway-file.md)」を参照してください。
エフェメラルストレージの使用については、「[EC2 ゲートウェイでのエフェメラルストレージの使用](ephemeral-disk-cache.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**
+ [エラー: 1344 (0x00000540)](#troubleshoot-copying-files-to-s3)
+ [エラー: GatewayClockOutOfSync](#troubleshoot-logging-errors-gatewayclockoutofsync)
+ [エラー: InaccessibleStorageClass](#troubleshoot-logging-errors-inaccessiblestorageclass)
+ [エラー: InvalidObjectState](#troubleshoot-logging-errors-invalidobjectstate)
+ [エラー: ObjectMissing](#troubleshoot-logging-errors-objectmissing)
+ [エラー: RoleTrustRelationshipInvalid](#misconfig-trust)
+ [エラー: S3AccessDenied](#troubleshoot-logging-errors-s3accessdenied)
+ [エラー: DroppedNotifications](#troubleshoot-logging-errors-droppednotifications)
+ [通知: HardReboot](#troubleshoot-hardreboot-notification)
+ [通知: リブート](#troubleshoot-reboot-notification)
+ [トラブルシューティング: セキュリティスキャンで NFS ポートの開放が検出される](#troubleshoot-open-nfs-ports)
+ [トラブルシューティング: CloudWatch メトリクスの使用](#troubleshooting-with-cw-metrics)
## エラー: 1344 (0x00000540)
Amazon S3 へのファイルの移行中に、10 を超えたアクセスコントロールエントリ (ACEs) を持つファイルを Amazon S3 にコピーしようとすると、`ERROR 1344 (0x00000540)` が発生することがあります。アクセスコントロールエントリは、アクセスコントロールリスト (ACL) に記載されています。
Amazon S3 ファイルゲートウェイは、特定のファイルまたはフォルダごとに 10 個の ACE エントリのみを保持できます。
**エラー 1344 を解決するには: NTFS セキュリティを送信先ディレクトリにコピーします。**
10 を超えるエントリのあるファイルまたはフォルダの Windows アクセス許可のエントリの数を減らします。一般的な方法は、エントリの完全なリストを備えたグループを作成し、エントリのリストをその単一のグループに置き換えることです。エントリ数が 10 未満になったら、ファイルまたはフォルダのゲートウェイへのコピーを再試行できます。
## エラー: GatewayClockOutOfSync
ゲートウェイがローカルシステム時刻と AWS Storage Gatewayサーバーによって報告された時刻の差を 5 分以上検出すると、`GatewayClockOutOfSync`エラーが発生することがあります。クロック同期の問題は、ゲートウェイと 間の接続に悪影響を及ぼす可能性があります AWS。ゲートウェイクロックが同期していない場合、NFS および SMB の接続で I/O エラーが発生し、SMB ユーザーに認証エラーが発生する可能性があります。
**GatewayClockOutOfSync エラーを解決するには**
+ ゲートウェイと NTP サーバー間のネットワーク設定を確認します。ゲートウェイ VM 時刻の同期と NTP サーバー設定の更新の詳細については、「[ゲートウェイのネットワークタイムプロトコル (NTP) サーバーの設定](https://docs.aws.amazon.com/filegateway/latest/files3/manage-on-premises-fgw.html#MaintenanceTimeSync-fgw)」を参照してください。
## エラー: InaccessibleStorageClass
オブジェクトを Amazon S3 Standardのストレージクラスから出した場合、`InaccessibleStorageClass` エラーが発生する場合があります。
通常、このエラーは、ファイルゲートウェイが 指定されたオブジェクトを Amazon S3 バケットにアップロードしようとした場合か、またはそこからオブジェクトを読み取ろうとした場合に発生します。このエラーでは、通常、オブジェクトは Amazon Glacier に移動され、S3 Glacier Flexible Retrieval あるいは S3 Glacier Deep Archive ストレージクラスのいずれかにあります。
S3 ファイルゲートウェイは、このエラーが原因で現在 Amazon S3 へのアップロードに失敗しているゲートウェイキャッシュ内のすべてのファイルを一覧表示するキャッシュレポートを生成できます。このレポートの情報は、 サポート を使用してゲートウェイ、Amazon S3、または IAM 設定の問題を解決するのに役立ちます。詳細については、「[キャッシュレポートの作成](https://docs.aws.amazon.com/filegateway/latest/files3/create-cache-report.html)」を参照してください。
**InaccessibleStorageClass エラーを解決するには**
+ S3 Glacier Flexible Retrieval あるいは S3 Glacier Deep Archive ストレージクラスから、オブジェクトを S3 の元のストレージクラスに復元します。
アップロードエラーを修正するためにオブジェクトを S3 バケットに復元すると、ファイルは最終的にアップロードされます。読み取りエラーを修正するためにオブジェクトを復元すると、ファイルゲートウェイの SMB クライアントまたは NFS クライアントがファイルを読み取れるようになります。
## エラー: InvalidObjectState
指定されたファイルゲートウェイ以外のライターが、指定された Amazon S3 バケット内の指定されたファイルを変更すると、`InvalidObjectState` エラーが発生する場合があります。その結果、ファイルゲートウェイのファイルの状態が Amazon S3 のファイルの状態と一致しなくなります。以降、Amazon S3 へのファイルのアップロードまたは Amazon S3 からのファイルの取得は失敗します。
S3 ファイルゲートウェイは、このエラーが原因で現在 Amazon S3 へのアップロードに失敗しているゲートウェイキャッシュ内のすべてのファイルを一覧表示するキャッシュレポートを生成できます。このレポートの情報は、 サポート を使用してゲートウェイ、Amazon S3、または IAM 設定の問題を解決するのに役立ちます。詳細については、「[キャッシュレポートの作成](https://docs.aws.amazon.com/filegateway/latest/files3/create-cache-report.html)」を参照してください。
**InvalidObjectState エラーを解決するには**
ファイルを変更するオペレーションが `S3Upload` または `S3GetObject` の場合は、次の手順を実行します。
1. ファイルの最新のコピーを SMB または NFS クライアントのローカルファイルシステムに保存します (ステップ 4 でこのファイルのコピーが必要です)。Amazon S3 内のファイルのバージョンが最新の場合、そのバージョンをダウンロードします。これは、 AWS マネジメントコンソール または を使用して実行できます AWS CLI。
1. AWS マネジメントコンソール または を使用して Amazon S3 内のファイルを削除します AWS CLI。
1. SMB または NFS クライアントを使用して、ファイルゲートウェイからファイルを削除します。
1. SMB または NFS クライアントを使用して、ステップ 1 で保存したファイルの最新バージョンを Amazon S3 にコピーします。この操作はファイルゲートウェイを介して行います。
## エラー: ObjectMissing
指定されたファイルゲートウェイ以外のライターが、指定されたファイルを S3 バケットから削除すると、`ObjectMissing` エラーが発生する場合があります。以降、Amazon S3 へのオブジェクトのアップロード、または Amazon S3 からのオブジェクトの取得は失敗します。
S3 ファイルゲートウェイは、このエラーが原因で現在 Amazon S3 へのアップロードに失敗しているゲートウェイキャッシュ内のすべてのファイルを一覧表示するキャッシュレポートを生成できます。このレポートの情報は、 サポート を使用してゲートウェイ、Amazon S3、または IAM 設定の問題を解決するのに役立ちます。詳細については、「[キャッシュレポートの作成](https://docs.aws.amazon.com/filegateway/latest/files3/create-cache-report.html)」を参照してください。
**ObjectMissing エラーを解決するには**
ファイルを変更するオペレーションが `S3Upload` または `S3GetObject` の場合は、次の手順を実行します。
1. ファイルの最新のコピーを SMB または NFS クライアントのローカルファイルシステムに保存します (ステップ 3 でこのファイルのコピーが必要です)。
1. SMB または NFS クライアントを使用して、ファイルゲートウェイからファイルを削除します。
1. SMB または NFS クライアントを使用して、ステップ 1 で保存したファイルの最新バージョンをコピーします。この操作はファイルゲートウェイを介して行います。
## エラー: RoleTrustRelationshipInvalid
このエラーは、ファイル共有の IAM ロールで IAM の信頼関係が正しく設定されていない (つまり IAM ロールで `storagegateway.amazonaws.com` という名前の Storage Gateway プリンシパルが信頼されていない) 場合に発生します。その結果、ファイルゲートウェイでは、ファイル共有をバックアップする S3 バケットでオペレーションを実行するための認証情報を取得できなくなります。
**RoleTrustRelationshipInvalid エラーを解決するには**
+ ファイル共有の IAMrole によって信頼されるプリンシパルとして `storagegateway.amazonaws.com` を含めるには、IAM コンソールまたは IAM API を使用します。IAM ロールの詳細については、[「チュートリアル: IAM ロールを使用して AWS アカウント間でアクセスを委任](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)する」を参照してください。
## エラー: S3AccessDenied
ファイル共有の Amazon S3 バケットアクセス AWS Identity and Access Management (IAM) ロールに`S3AccessDenied`エラーが発生することがあります。この場合、エラー内の `roleArn` により指定された S3 バケットにアクセスする IAM ロールでは、関連するオペレーションは許可されません。オペレーションが許可されないのは、Amazon S3 プレフィックスで指定されたディレクトリ内のオブジェクトに対するアクセス許可のためです。
S3 ファイルゲートウェイは、このエラーが原因で現在 Amazon S3 へのアップロードに失敗しているゲートウェイキャッシュ内のすべてのファイルを一覧表示するキャッシュレポートを生成できます。このレポートの情報は、 サポート を使用してゲートウェイ、Amazon S3、または IAM 設定の問題を解決するのに役立ちます。詳細については、「[キャッシュレポートの作成](https://docs.aws.amazon.com/filegateway/latest/files3/create-cache-report.html)」を参照してください。
**S3AccessDenied エラーを解決するには**
+ ファイルゲートウェイのヘルスログで `roleArn` にアタッチされている Amazon S3 のアクセスポリシーを変更して、Amazon S3 オペレーションに対するアクセス許可を付与します。アクセスポリシーで、エラーの原因となったオペレーションに対するアクセス許可を付与されていることを確認します。また、`prefix` のログで指定されたディレクトリに対するアクセス許可も許可します。Amazon S3 のアクセス許可についての詳細は、「*Amazon Simple Storage Service ユーザーガイド*の「[ポリシーでのアクセス許可の指定](https://docs.aws.amazon.com/AmazonS3/latest/dev/using-with-s3-actions.html)」を参照してください。
これらのオペレーションにより、`S3AccessDenied` エラーが発生する可能性があります。
+ `S3HeadObject`
+ `S3GetObject`
+ `S3ListObjects`
+ `S3DeleteObject`
+ `S3PutObject`
## エラー: 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 分以内である場合、この再起動の発生はおそらく正常であり、問題の兆候ではありません。メンテナンスの大幅な期間外に再起動が発生した場合は、ゲートウェイを手動で再起動したかどうかを確認します。
## トラブルシューティング: セキュリティスキャンで NFS ポートの開放が検出される
特定の NFS ポートは、SMB ファイル共有でのみ使用するゲートウェイでも、デフォルトで有効になっています。Qualys などのサードパーティのセキュリティソフトウェアを使用してファイルゲートウェイがデプロイされているネットワークをスキャンする場合、スキャン結果はこれらの NFS ポートの開放を潜在的なセキュリティ脆弱性として報告することがあります。SMB ファイル共有でのみゲートウェイを使用し、セキュリティ上の理由から未使用の NFS ポートを無効にする場合は、次の手順を行います。
**ファイルゲートウェイで NFS ポートを無効にするには:**
1. [ローカルコンソールでの Storage Gateway コマンドの実行](MaintenanceGatewayConsole-fgw.md) で説明されている手順を使用して、ゲートウェイローカルコンソールのコマンドプロンプトにアクセスします。
1. NFS トラフィックを無効にするには、次のコマンドを入力します。
**IPv4**
```
iptables -I INPUT -p udp -m udp --dport 111 -j DROP
iptables -I INPUT -p udp -m udp --dport 2049 -j DROP
iptables -I INPUT -p udp -m udp --dport 20048 -j DROP
iptables -I INPUT -p tcp -m tcp --dport 111 -j DROP
iptables -I INPUT -p tcp -m tcp --dport 2049 -j DROP
iptables -I INPUT -p tcp -m tcp --dport 20048 -j DROP
```
**IPv6**
```
ip6tables -I INPUT -p udp -m udp --dport 111 -j DROP
ip6tables -I INPUT -p udp -m udp --dport 2049 -j DROP
ip6tables -I INPUT -p udp -m udp --dport 20048 -j DROP
ip6tables -I INPUT -p tcp -m tcp --dport 111 -j DROP
ip6tables -I INPUT -p tcp -m tcp --dport 2049 -j DROP
ip6tables -I INPUT -p tcp -m tcp --dport 20048 -j DROP
```
1. 次のコマンドを入力して、ブロックされた NFS ポートが IP テーブルに表示されることを確認します。
**IPv4**
```
iptables -n -L -v --line-numbers
```
**IPv6**
```
ip6tables -n -L -v --line-numbers
```
## トラブルシューティング: CloudWatch メトリクスの使用
Storage Gateway で Amazon CloudWatch メトリクスを使用する際の問題に対処するためのアクションについては、次を参照してください。
**Topics**
+ [ディレクトリの閲覧時にゲートウェイの反応が遅い](#slow-gateway)
+ [ゲートウェイが応答しない](#gateway-not-responding)
+ [ゲートウェイを介した Amazon S3 へのデータ転送速度が遅い](#slow-data-transfer-to-S3)
+ [ゲートウェイが想定よりも多くの Amazon S3 オペレーションを実行している](#gateway-performing-more-s3-operations)
+ [Amazon S3 バケットにファイルが表示されない](#files-missing-s3-bucket)
+ [ゲートウェイへの書き込み時にゲートウェイのバックアップジョブが失敗する、またはエラーが発生する](#backup-job-fails)
### ディレクトリの閲覧時にゲートウェイの反応が遅い
**ls** コマンドの実行時またはディレクトリの閲覧時にファイルゲートウェイの反応が遅い場合は、`IndexFetch` および `IndexEviction` の CloudWatch メトリクスを確認します。
+ `ls` コマンドの実行時またはディレクトリの閲覧時に `IndexFetch` メトリクスが 0 を超えている場合、ファイルゲートウェイは影響を受けるディレクトリの内容に関する情報なしで起動し、Amazon S3 にアクセスする必要がありました。今後そのディレクトリの内容をリストする作業の速度は上がるはずです。
+ `IndexEviction` メトリクスが 0 を超えている場合は、ファイルゲートウェイがその時点でキャッシュとして管理できる上限に達していることを意味します。この場合、ファイルゲートウェイでは、最近最もアクセスしていないディレクトリから一部のストレージ領域を解放して、新しいディレクトリをリストする必要があります。この問題が頻繁に発生し、パフォーマンスへの影響がある場合は、 にお問い合わせください サポート。
関連する S3 バケット サポート の内容と、ユースケースに基づいてパフォーマンスを向上させるための推奨事項について説明します。
### ゲートウェイが応答しない
ファイルゲートウェイが応答しない場合は、次の操作を行います。
+ 最近再起動またはソフトウェアの更新を行った場合は、`IOWaitPercent` メトリクスを確認します。このメトリクスは、未処理のディスク I/O リクエストがある場合に、CPU がアイドル状態の時間の割合を示します。場合によっては、この値が高く (10 以上)、サーバーの再起動または更新後に増えていることがあります。このような場合、ファイルゲートウェイによりインデックスのキャッシュが RAM に再構築されるため、低速のルートディスクがゲートウェイのボトルネックになっている可能性があります。より高速な物理ディスクをルートディスクに使用することにより、この問題に対処できます。
+ `MemUsedBytes` メトリクスが `MemTotalBytes` メトリクスと同じか、ほぼ同じ場合、ファイルゲートウェイで使用可能な RAM が不足しています。ファイルゲートウェイに最低限必要な RAM があることを確認してください。既にある場合は、ワークロードとユースケースに基づいて、ファイルゲートウェイに RAM を追加することを検討してください。
ファイル共有が SMB の場合は、ファイル共有に接続されている SMB クライアントの数が問題の原因である可能性もあります。任意の時点で接続しているクライアントの数を確認するには、`SMBV(1/2/3)Sessions` メトリクスをチェックします。多くのクライアントが接続されている場合、ファイルゲートウェイに RAM の追加が必要になることがあります。
### ゲートウェイを介した Amazon S3 へのデータ転送速度が遅い
ファイルゲートウェイを介した Amazon S3 へのデータ転送速度が遅い場合は、次の操作を行います。
+ `CachePercentDirty` メトリクスが 80 以上の場合、ファイルゲートウェイでは、データが Amazon S3 にアップロードされる速度よりも速いペースでデータがディスクに書き込まれています。ファイルゲートウェイからのアップロードの帯域幅を増やす、1 つ以上のキャッシュディスクを追加する、またはクライアントの書き込み速度を遅くすることを検討してください。
+ `CachePercentDirty` メトリクスが低い場合は、`IoWaitPercent` メトリクスを確認します。`IoWaitPercent` が 10 を超える場合、ファイルゲートウェイでローカルキャッシュディスクの速度がボトルネックになっている可能性があります。キャッシュには、ローカルソリッドステートドライブ (SSD) ディスク (できれば NVM Express (NVMe)) をお勧めします。このようなディスクが使用できない場合は、パフォーマンスを向上させるために、別々の物理ディスクから複数のキャッシュディスクを使用してみてください。
+ `S3PutObjectRequestTime`、`S3UploadPartRequestTime`、または `S3GetObjectRequestTime` が高い場合、ネットワークにボトルネックが発生している可能性があります。ネットワークを分析して、ゲートウェイに想定どおりの帯域幅が確保されていることを確認してください。
### ゲートウェイが想定よりも多くの Amazon S3 オペレーションを実行している
ファイルゲートウェイが想定よりも多くの Amazon S3 オペレーションを実行している場合は、`FilesRenamed` メトリクスを確認します。名前変更オペレーションはAmazon S3で実行するとコストがかかります。ワークフローを最適化して、名前変更オペレーションの数を最小限に抑えます。
### Amazon S3 バケットにファイルが表示されない
ゲートウェイ上のファイルが Amazon S3 バケットに反映されていない場合は、`FilesFailingUpload` メトリクスを確認してください。メトリクスが一部のファイルのアップロードに失敗したことを報告している場合は、ヘルス通知を確認します。ファイルのアップロードに失敗すると、ゲートウェイは問題の詳細を示したヘルス通知を生成します。
### ゲートウェイへの書き込み時にゲートウェイのバックアップジョブが失敗する、またはエラーが発生する
ファイルゲートウェイへの書き込み時にゲートウェイのバックアップジョブが失敗する、またはエラーが発生する場合は、次の操作を行います。
+ `CachePercentDirty` メトリクスが 90 パーセント以上の場合、キャッシュディスクに十分な空き領域がないため、ファイルゲートウェイではディスクへの新しい書き込みを受け付けることができません。ファイルゲートウェイでの Amazon S3 へのアップロード速度を確認するには、`CloudBytesUploaded` メトリクスを表示します。そのメトリクスと、クライアントによるファイルゲートウェイへのファイルの書き込みの速さを示す `WriteBytes` メトリクスを比較します。SMB クライアントがファイルゲートウェイが、Amazon S3 にアップロードできる速度よりも速く書き込みを行っている場合は、少なくともバックアップジョブのサイズに対応できるキャッシュディスクを追加します。または、アップロード帯域幅を増やします。
+ バックアップジョブが失敗しているにもかかわらず、`CachePercentDirty` メトリクスが 80 パーセント未満の場合は、ファイルゲートウェイでクライアント側のセッションがタイムアウトしている可能性があります。SMB の場合は、PowerShell コマンド `Set-SmbClientConfiguration -SessionTimeout 300` を使用してこのタイムアウトを増やすことができます。このコマンドを実行すると、タイムアウトが 300 秒に設定されます。
NFS の場合は、クライアントがソフトマウントではなくハードマウントを使用してマウントされていることを確認してください。
# トラブルシューティング: ファイル共有に関する問題
このセクションでは、ファイル共有で想定外の問題が発生した場合に行うアクションについて説明します。
**Topics**
+ [ファイル共有が CREATING、UPDATING、または DELETING 状態でスタックする](#troubleshooting-file-share-stuck-states)
+ [ファイル共有を作成できない](#create-file-troubleshoot)
+ [SMB ファイル共有で複数の異なるアクセス方法が使えない](#smb-fileshare-troubleshoot)
+ [マッピングされた S3 バケットに複数のファイル共有を書き込めない](#multiwrite)
+ [監査ログを使用する場合の削除済みロググループの通知](#multiwrite)
+ [S3 バケットにファイルをアップロードできない](#access-s3bucket)
+ [SSE-KMS を使用して、S3 バケットに保存されたオブジェクトを暗号化するように、デフォルトの暗号化を変更できない](#encryption-issues)
+ [オブジェクトのバージョニングが有効になっている S3 バケットで直接行われた変更は、ファイル共有で表示される内容に影響することがあります。](#s3-object-versioning-file-share-issue)
+ [オブジェクトのバージョニングを有効にして S3 バケットに書き込む場合、Amazon S3 ファイルゲートウェイは S3 オブジェクトの複数のバージョンを作成することがあります。](#s3-object-versioning-file-gateway-issue)
+ [S3 バケットに対する変更が Storage Gateway に反映されない](#s3-changes-issue)
+ [ACL のアクセス許可が予期する動作を行わない](#smb-acl-issues)
+ [再帰的なオペレーションを実行すると、ゲートウェイのパフォーマンスが低下した](#recursive-operation-issues)
## ファイル共有が CREATING、UPDATING、または DELETING 状態でスタックする
ファイル共有ステータスは、ファイル共有の状態をまとめたものです。S3 File Gateway ファイル共有が `CREATING`、、`UPDATING`または `DELETING`状態でスタックしている場合は、次のトラブルシューティングステップを使用して問題を特定して解決します。
### IAM ロールのアクセス許可と信頼関係を確認する
ファイル共有に関連付けられた AWS Identity and Access Management (IAM) ロールには、Amazon S3 バケットにアクセスするための十分なアクセス許可が必要です。さらに、ロールの信頼ポリシーは、ロールを引き受けるアクセス許可を Storage Gateway サービスに付与する必要があります。
**IAM ロールのアクセス許可を確認するには:**
1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。
1. ナビゲーションペインで **Roles (ロール) ** を選択してください。
1. ファイル共有に関連付けられている IAM ロールを選択します。
1. **[信頼関係]** タブを選択します。
1. Storage Gateway が信頼されたエンティティとしてリストされていることを確認します。Storage Gateway が信頼されたエンティティでない場合は、**信頼関係の編集**を選択し、次のポリシーを追加します。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "storagegateway.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. IAM ロールに正しいアクセス許可があり、Amazon S3 バケットが IAM ポリシーにリソースとしてリストされていることを確認します。詳細については、「[Amazon S3 バケットに対するアクセス権限の付与](grant-access-s3.md)」を参照してください。
**注記**
サービス間の混乱した代理防止の問題を回避するには、条件コンテキストキーを含む信頼関係ポリシーを使用します。詳細については、「[サービス間の混乱した代理の防止](cross-service-confused-deputy-prevention.md)」を参照してください。
### リージョンで AWS STS がアクティブ化されていることを確認します。
AWS リージョンで AWS Security Token Service (AWS STS) が非アクティブ化されている場合、ファイル共有は `CREATING`または `UPDATING`状態でスタックする可能性があります。
**AWS STS ステータスを確認するには:**
1. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で AWS Identity and Access Management コンソールを開きます。
1. ナビゲーションペインで **[アカウント設定]** を選択します。
1. **Security Token Service (STS)** セクションで、ファイル共有を作成する AWS リージョン**のステータス**が**アクティブ**であることを確認します。
1. ステータスが**非アクティブ**の場合は、**アクティブ化**を選択してそのリージョン AWS STS で を有効にします。
### S3 バケットが存在し、命名規則に従っていることを確認する
ファイル共有には、Amazon S3 の命名規則に従った有効な Amazon S3 バケットが必要です。
**S3 バケットを確認するには:**
1. Amazon S3 コンソール ([https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)) を開きます。
1. ファイル共有にマッピングされた Amazon S3 バケットが存在することを確認します。バケットが存在しない場合は、作成します。バケットを作成すると、ファイル共有ステータスは に変わります`AVAILABLE`。詳細については、*Amazon Simple Storage Service ユーザーガイド*の「[バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/gsg/CreatingABucket.html)」を参照してください。
1. バケット名が *Amazon Simple Storage Service ユーザーガイド*の[バケット命名規則](https://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html#bucketnamingrules)に準拠していることを確認します。
**注記**
S3 File Gateway は、バケット名にピリオド (`.`) を含む Amazon S3 バケットをサポートしていません。
### ファイル共有を DELETING 状態で強制的に削除する
ファイル共有を削除すると、ゲートウェイは関連付けられた Amazon S3 バケットから共有を削除します。ただし、現在アップロード中のデータは、削除が完了する前に引き続きアップロードされます。このプロセス中に、ファイル共有のステータスが表示されます`DELETING`。
**重要**
ゲートウェイ`CachePercentDirty`の Amazon CloudWatch メトリクスをチェックして、アップロード保留中のデータの量を確認します。Storage Gateway メトリクスの詳細については、「」を参照してください[S3 ファイルゲートウェイのモニタリング](monitoring-file-gateway.md)。
進行中のすべてのアップロードが完了するまで待機しない場合は、ファイル共有を強制的に削除できます。
**ファイル共有を強制的に削除するには:**
1. [https://console.aws.amazon.com/storagegateway/](https://console.aws.amazon.com/storagegateway/) で Storage Gateway コンソールを開きます。
1. ナビゲーションペインで、**ファイル共有**を選択します。
1. 削除するファイル共有を選択します。
1. **詳細**タブを選択し、**このファイル共有は削除中です**というメッセージを確認します。
1. メッセージ内のファイル共有の ID を確認し、確認ボックスを選択します。
**注記**
強制削除オペレーションを元に戻すことはできません。
1. **今すぐ強制削除**を選択します。
または、 AWS CLI [delete-file-share](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/storagegateway/delete-file-share.html) コマンドを使用して、 `--force-delete`パラメータを に設定することもできます`true`。
**重要**
ファイル共有を強制的に削除する前に、ゲートウェイが `OFFLINE`状態になっていないことを確認してください。ゲートウェイがオフラインの場合は、まずオフラインの問題を解決します。詳細については、「[トラブルシューティング: Storage Gateway コンソールでゲートウェイがオフラインとなる](troubleshooting-gateway-offline.md)」を参照してください。
ゲートウェイ仮想マシン (VM) がすでに削除されている場合は、Storage Gateway コンソールからゲートウェイを削除して、 `DELETING`状態でスタックしているファイル共有を含む、関連するすべてのファイル共有を削除する必要があります。詳細については、「[ゲートウェイおよび関連リソースの削除](deleting-gateway-common.md)」を参照してください。
### ネットワーク接続に関する問題のトラブルシューティングを行う
ネットワークの問題により、ファイル共有が `CREATING`、、`UPDATING`または `DELETING`状態から移行できなくなる可能性があります。一般的なネットワークの問題は次のとおりです。
+ ゲートウェイがオフラインであるか、ゲートウェイ VM が削除されます。
+ Storage Gateway と Amazon S3 サービスエンドポイント間のネットワークアクセスはブロックされます。
+ ゲートウェイが Amazon S3 との通信に使用する Amazon S3 Amazon VPC エンドポイントが削除されました。
+ 必要なネットワークポートが開いていないか、ネットワークルーティングが正しく設定されていません。
#### ゲートウェイローカルコンソールから S3 接続をテストする
**S3 接続をテストするには:**
1. ゲートウェイのローカルコンソールにログインします。詳細については、「[ファイルゲートウェイローカルコンソールへのログイン](LocalConsole-login-fgw.md)」を参照してください。
1. **Storage Gateway - 設定**のメインメニューに、**テスト S3 接続**に対応する番号を入力します。
1. Amazon S3 エンドポイントタイプを選択します。
+ インターネットゲートウェイ、NAT ゲートウェイ、トランジットゲートウェイ、または Amazon S3 ゲートウェイの Amazon VPC エンドポイントを通過する Amazon S3 トラフィックの場合は、**「パブリック**」を選択します。
+ Amazon S3 インターフェイス Amazon VPC エンドポイントを通過する Amazon S3 トラフィックの場合は、**VPC (PrivateLink)** を選択します。
+ FIPS エンドポイントの場合は、FIPS オプションを選択します。
1. Amazon S3 バケットリージョンを入力します。
1. Amazon VPC エンドポイントを使用する場合は、Amazon S3 Amazon VPC エンドポイントの DNS 名 (例: ) を入力します`vpce-0329c2790456f2d01-0at85l34`。
ゲートウェイは、ネットワーク接続と SSL 接続の両方を検証する接続テストを自動的に実行します。テストが失敗した場合:
+ **ネットワークテストの失敗** - 通常、ファイアウォールルール、セキュリティグループ設定、不適切なネットワークルーティングが原因で発生します。必要なポートが開いていて、ネットワークルーティングが正しく設定されていることを確認します。
+ **SSL テストの失敗** - ゲートウェイ VM と Amazon S3 サービスエンドポイントの間で SSL 検査またはディープパケット検査が発生していることを示します。Storage Gateway トラフィックの SSL およびディープパケットインスペクションを無効にします。
#### プロキシ設定の確認
ゲートウェイがプロキシサーバーを使用している場合は、プロキシがネットワーク通信をブロックしていないことを確認します。
**プロキシ設定を確認するには:**
1. **Storage Gateway - Configuration** メインメニューで、**HTTP/SOCKS Proxy Configuration** に対応する番号を入力します。
1. 現在のネットワークプロキシ設定を表示するオプションを選択します。
1. プロキシが設定されている場合は、Amazon S3 トラフィックが Storage Gateway からポート 3128 (または設定されたリスナーポート) 経由でプロキシサーバーに流れ、ポート 443 経由で Amazon S3 エンドポイントに流れることを確認します。
1. プロキシまたはファイアウォールが、Storage Gateway に必要なネットワークポートとサービスエンドポイントとの間のトラフィックを許可していることを確認します。詳細については、必要なネットワークポートを参照してください。
問題が解決しない場合は、プロキシ設定を一時的に削除して、プロキシが問題の原因となっているかどうかを判断できます。
#### セキュリティグループとネットワークルーティングを検証する
+ **Amazon EC2 上のゲートウェイ**の場合 - セキュリティグループで Amazon S3 エンドポイントに対してポート 443 が開いていることを確認します。Amazon EC2 サブネットのルートテーブルが Amazon S3 トラフィックを Amazon S3 エンドポイントに適切にルーティングしていることを確認します。詳細については、必要なネットワークポートを参照してください。
+ **オンプレミスゲートウェイの場合** - ファイアウォールルールで必要なポートが許可されており、ローカルルートテーブルが Amazon S3 トラフィックを Amazon S3 エンドポイントに適切にルーティングしていることを確認します。詳細については、必要なネットワークポートを参照してください。
+ **VPC エンドポイント** - ゲートウェイで使用される Amazon S3 Amazon VPC エンドポイントが削除されていないことを確認します。Amazon VPC エンドポイントが削除され、ゲートウェイにパブリック IP アドレスがない場合、ゲートウェイは Amazon S3 と通信できません。
## ファイル共有を作成できない
1. ファイル共有が CREATING ステータスのまま止まっているためにファイル共有を作成できない場合には、ファイル共有をマッピングした S3 バケットが存在することを確認します。これを行う方法については、「[ファイル共有が CREATING、UPDATING、または DELETING 状態でスタックする](#troubleshooting-file-share-stuck-states)」を参照してください。
1. S3 バケットが存在する場合は、ファイル共有を作成するリージョンで AWS Security Token Service がアクティブ化されていることを確認します。セキュリティトークンが有効になっていない場合は、有効にする必要があります。を使用してトークンをアクティブ化する方法については AWS Security Token Service、*IAM ユーザーガイド*の[「 AWS リージョンでの AWS STS のアクティブ化と非アクティブ化](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html)」を参照してください。
## SMB ファイル共有で複数の異なるアクセス方法が使えない
SMB ファイル共有には、以下の制約があります。
1. 同じクライアントが Active Directory とゲストアクセスの SMB ファイル共有の両方をマウントしようとすると、次のエラーメッセージが表示されます。`Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.`
1. Windows ユーザーは、2 つのゲストアクセスの SMB ファイル共有に接続することはできません。新しいゲストアクセス接続が確立されると切断される場合があります。
1. Windows クライアントは、同じゲートウェイによってエクスポートされた、ゲストアクセスと Active Directory の SMB ファイル共有の両方をマウントすることはできません。
## マッピングされた S3 バケットに複数のファイル共有を書き込めない
1 つの S3 バケットに複数のファイル共有を書き込むことを許可するよう S3 バケットを設定することは推奨されません。このやり方では、想定外の結果を引き起こす場合があります。
代わりに、各 S3 バケットに 1 つのファイル共有のみ書き込めるようにすることが推奨されます。ファイル共有に関連付けられた 1 つのロールのみがバケットに書き込めるようにするバケットポリシーを作成します。詳細については、「[ファイルゲートウェイのベストプラクティス](https://docs.aws.amazon.com/filegateway/latest/files3/best-practices.html)」を参照してください。
## 監査ログを使用する場合の削除済みロググループの通知
ロググループが存在しない場合、ユーザーはそのメッセージの下にあるロググループリンクを選択して、新しいロググループを作成するか、または既存のロググループを使用して、監査ログの対象として利用できます。
## S3 バケットにファイルをアップロードできない
S3 バケットにファイルをアップロードできない場合には、以下を行います。
1. S3 バケットにファイルをアップロードする Amazon S3 ファイルゲートウェイに必要なアクセス権限があることを確認します。詳細については、「[Amazon S3 バケットに対するアクセス権限の付与](grant-access-s3.md)」を参照してください。
1. バケットを作成したロールに S3 バケットに書き込みを行う許可があることを確認します。詳細については、「[ファイルゲートウェイのベストプラクティス](https://docs.aws.amazon.com/filegateway/latest/files3/best-practices.html)」を参照してください。
1. ファイルゲートウェイが暗号化に SSE-KMS または DSSE-KMS を使用している場合は、ファイル共有に関連付けられた IAM ロールに *kms:Encrypt*、*kms:Decrypt*、*kms:ReEncrypt\$1*、*kms:GenerateDataKey*、および *kms:DescribeKey* のアクセス許可が含まれていることを確認してください。詳細については、「[Storage Gateway でアイデンティティベースのポリシー (IAM ポリシー) を使用する](https://docs.aws.amazon.com/filegateway/latest/files3/using-identity-based-policies.html)」を参照してください。
## SSE-KMS を使用して、S3 バケットに保存されたオブジェクトを暗号化するように、デフォルトの暗号化を変更できない
デフォルトの暗号化を変更して SSE-KMS ( AWS KMS– マネージドキーを使用したサーバー側の暗号化) を S3 バケットのデフォルトにすると、Amazon S3 ファイルゲートウェイがバケットに保存するオブジェクトは SSE-KMS で暗号化されません。デフォルトでは、S3 ファイルゲートウェイで S3 バケットにデータを書き込む際、Amazon S3 で管理されるサーバー側の暗号化 (SSE-S3) が使用されます。デフォルトを変更しても、暗号化は自動的に変更されません。
独自の AWS KMS キーで SSE-KMS を使用するように暗号化を変更するには、SSE-KMS 暗号化を有効にする必要があります。これを行うには、ファイル共有を作成するときに KMS キーの Amazon リソースネーム (ARN) を指定します。ファイル共有の KMS 設定は、`UpdateNFSFileShare` または `UpdateSMBFileShare` API オペレーションを使用して更新することもできます。この更新は、更新後に S3 バケットに保存されているオブジェクトに適用されます。詳細については、「[を使用したデータ暗号化 AWS KMS](encryption.md)」を参照してください。
## オブジェクトのバージョニングが有効になっている S3 バケットで直接行われた変更は、ファイル共有で表示される内容に影響することがあります。
S3 バケットのオブジェクトが別のクライアントから書き込まれている場合、S3 バケットオブジェクトのバージョニングの結果として S3 バケットのビューが最新でなくなる可能性があります。目的のファイルを調べる前に必ずキャッシュを更新してください。
* オブジェクトのバージョニング*は、同じ名前のオブジェクトの複数のコピーを保存することによりデータを保護するためのオプションの S3 バケット機能です。各コピーには、個別の ID 値があります (`file1.jpg`: `ID="xxx"` および `file1.jpg`: `ID="yyy"` など)。同じ名前のオブジェクトの数とその存続期間は、Amazon S3 ライフサイクルポリシーによって制御されます。これらの Amazon S3 の概念の詳細については、「*Amazon S3 開発者ガイド*」の「[バージョニングの使用](https://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html)」と「[オブジェクトのライフサイクルの管理](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html)」を参照してください。
バージョニングされたオブジェクトを削除すると、そのオブジェクトには削除マーカーのフラグが付けられますが保持されます。バージョニングがオンになっているオブジェクトは、S3 バケット所有者のみが完全に削除することができます。
S3 ファイルゲートウェイでは、表示されるファイルは、オブジェクトが取得されたかキャッシュが更新された時点の S3 バケットにおけるオブジェクトの最新バージョンです。S3 ファイルゲートウェイは、古いバージョン、または削除対象としてマークされたすべてのオブジェクトを無視します。ファイルを読み込むとき、最新バージョンからデータを読み取ります。ファイル共有にファイルを書き込むと、S3 ファイルゲートウェイにより、指定オブジェクトの新しいバージョンが変更を適用して作成され、そのバージョンが最新バージョンになります。
S3 ファイルゲートウェイは、以前のバージョンから読み取りを続けます。アプリケーション外で S3 バケットに新しいバージョンが追加された場合、ゲートウェイによる更新は以前のバージョンに基づいて行われます。オブジェクトの最新バージョンを読み取るには、「[Amazon S3 バケットのオブジェクトキャッシュの更新](refresh-cache.md)」で説明されているように、[RefreshCache](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_RefreshCache.html) API アクションを使用するか、コンソールから更新します。
**重要**
ファイル共有以外の経路から、S3 ファイルゲートウェイの S3 バケットにオブジェクトまたはファイルを書き込むことは推奨されません。
## オブジェクトのバージョニングを有効にして S3 バケットに書き込む場合、Amazon S3 ファイルゲートウェイは S3 オブジェクトの複数のバージョンを作成することがあります。
オブジェクトのバージョニングを有効にすると、NFS または SMB クライアントからファイルを更新するたびに、Amazon S3 でオブジェクトの複数のバージョンが作成されることがあります。S3 バケットにオブジェクトの複数のバージョンが作成される可能性があるシナリオを次に示します。
+ Amazon S3 にアップロードされたファイルが、NFS または SMB クライアントによってAmazon S3 ファイルゲートウェイ内で変更されると、S3 ファイルゲートウェイはファイル全体をアップロードするのではなく、新しいデータまたは変更されたデータのみをアップロードします。ファイルを変更すると、Amazon S3 オブジェクトの新しいバージョンが作成されます。
+ NFS または SMB クライアントによってファイルゲートウェイにファイルが書き込まれると、S3 ファイルゲートウェイによりファイルデータが Amazon S3 にアップロードされます。その後、メタデータ (所有権、タイムスタンプなど) がアップロードされます。ファイルデータをアップロードすると Amazon S3 オブジェクトが作成され、ファイルのメタデータをアップロードすると、Amazon S3 オブジェクトのメタデータが更新されます。このプロセスにより、別のバージョンのオブジェクトが作成され、オブジェクトのバーションが 2 つになります。
+ S3 ファイルゲートウェイが大きなファイルをアップロードする場合、クライアントがファイルゲートウェイへの書き込みを完了する前に、ファイルを小さく分けてアップロードする必要がある場合があります。その理由には、キャッシュ領域の解放や、ファイルへの書き込み率が高いことなどが挙げられます。この処理では、S3 バケットで複数バージョンのオブジェクトが作成されることがあります。
オブジェクトを異なるストレージクラスに移動するライフサイクルポリシーを設定する前に、S3 バケットをモニタリングして、オブジェクトのバージョン数を確認する必要があります。S3 バケット内のオブジェクトのバージョン数を最小限に抑えるには、過去のバージョンのライフサイクルに有効期限を設定する必要があります。S3 バケット間で、同一リージョンでのレプリケーション (SRR) またはクロスリージョンでのレプリケーション (CRR) を使用すると、使用されるストレージが増加します。レプリケーションの詳細については、「[レプリケーション](https://docs.aws.amazon.com/AmazonS3/latest/dev/replication.html)」を参照してください。
**重要**
オブジェクトのバージョニングが有効になっているときに使用されているストレージの量を把握するまで、S3 バケット間のレプリケーションを設定しないでください。
バージョニングされた S3 バケットを使用すると、ファイルを変更するたびに S3 オブジェクトの新しいバージョンが作成されるため、Amazon S3 内のストレージの量が大幅に増加します。この動作を上書きし、保持されるバージョンの数を制限するポリシーを別に作成しない限り、デフォルトでは、Amazon S3 はこれらのすべてのバージョンを保存し続けます。オブジェクトのバージョニングを有効にして、ストレージ使用量が異常に大きいことに気づいた場合、ストレージポリシーが適切に設定されていることを確認してください。ブラウザリクエストに対する `HTTP 503-slow down` 応答の数が増えても、オブジェクトのバージョニングの問題が発生する可能性があります。
S3 ファイルゲートウェイのインストール後にオブジェクトのバージョニングを有効にした場合、すべての一意のオブジェクトが保持され (`ID=”NULL”`)、ファイルシステムにそれらすべてが表示されます。新しいバージョンのオブジェクトには固有の ID が割り当てられます (古いバージョンは保持されます)。オブジェクトのタイムスタンプに基づいて、最新のバージョニングされたオブジェクトのみが NFS ファイルシステムに表示されます。
オブジェクトのバージョニングを有効にすると、S3 バケットをバージョニングが設定されていない状態に戻すことはできません。ただし、バージョニングを停止することは可能です。バージョニングを停止した場合、新しいオブジェクトに ID が割り当てられます。`ID=”NULL”` 値を持つ同じ名前のオブジェクトが存在する場合は、以前のバージョンが上書きされます。ただし、`NULL` 以外の ID が格納されているバージョンは保持されます。タイムスタンプは、新しいオブジェクトを最新のオブジェクトとして識別します。そのオブジェクトが NFS ファイルシステムに表示されます。
## S3 バケットに対する変更が Storage Gateway に反映されない
Storage Gateway は、ファイル共有を使用してローカルでキャッシュにファイルが書き込まれると、ファイル共有キャッシュを自動的に更新します。ただし、ファイルを Amazon S3 に直接アップロードしても、Storage Gateway はキャッシュを自動的に更新しません。これを行う際には、`RefreshCache` オペレーションを実行して、ファイル共有の変更を確認します。複数のファイル共有がある場合は、各ファイル共有に対して `RefreshCache` オペレーションを実行する必要があります。
次のように、Storage Gateway コンソールと AWS Command Line Interface (AWS CLI) を使用してキャッシュを更新できます。
+ Storage Gateway コンソールを使用してキャッシュを更新するには、「Amazon S3 バケット内のオブジェクトの更新」を参照してください。
+ AWS CLIを使用してキャッシュを更新するには次の手順を実行します。
1. コマンド `aws storagegateway list-file-shares` を実行します
1. 更新するキャッシュとのファイル共有の Amazon リソースナンバー (ARN) をコピーします。
1. ARN を `--file-share-arn` の値として `refresh-cache` コマンドを次のように実行します。
`aws storagegateway refresh-cache --file-share-arn arn:aws:storagegateway:eu-west-1:12345678910:share/share-FFDEE12`
`RefreshCache` オペレーションを自動化するには、「[Storage Gateway で RefreshCache 操作を自動化する方法](https://aws.amazon.com/premiumsupport/knowledge-center/storage-gateway-automate-refreshcache/)」を参照してください。
## ACL のアクセス許可が予期する動作を行わない
アクセスコントロールリスト (ACL) 権限が SMB ファイル共有で所定の動作を行わない場合は、テストを実行できます。
これを行うには、まず、Microsoft Windows ファイルサーバーあるいはローカル Windows ファイル共有でアクセス権限をテストします。次に、ゲートウェイのファイル共有と動作を比較します。
## 再帰的なオペレーションを実行すると、ゲートウェイのパフォーマンスが低下した
一部のケースでは、ディレクトリの名前変更や ACL での継承を有効にするなどの再帰的なオペレーションを実行し、その変更をツリー全体に強制的に適用することがあります。これを行った場合、S3 ファイルゲートウェイはこのオペレーションを再帰的にファイル共有のすべてのオブジェクトに適用します。
例えば、S3 バケット内の既存のオブジェクトに継承を適用するとします。S3 ファイルゲートウェイは、バケット内のすべてのオブジェクトに継承を再帰的に適用します。このようなオペレーションは、ゲートウェイの実行が拒否される要因となることがあります。
## 高可用性のヘルス通知
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 ロググループを参照してください。