翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # ゲートウェイのトラブルシューティング 以下は、ゲートウェイ、ホストプラットフォーム、ボリューム、高可用性、データ復旧、スナップショットに関連するベストプラクティスとトラブルシューティングの問題についての情報です。オンプレミスゲートウェイのトラブルシューティング情報は、サポートされている仮想化プラットフォームにデプロイされたゲートウェイを対象としています。高可用性の問題のトラブルシューティング情報には、VMware vSphere High Availability (HA) プラットフォームで実行されているゲートウェイが含まれます。 **トピック** + [トラブルシューティング: ゲートウェイのオフライン問題](troubleshooting-gateway-offline.md) - Storage Gateway コンソールでゲートウェイがオフラインになる原因となる問題を診断する方法について説明します。 + [トラブルシューティング: ゲートウェイのアクティベーション中の内部エラー](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) - Storage Gateway ハードウェアアプライアンスで発生する可能性のある問題を解決する方法について説明します。 + [ボリュームの問題のトラブルシューティング](troubleshoot-volume-issues.md) - ボリュームを使用しているときに発生する可能性のある最も一般的な問題と、これらを修正する際に推奨されるアクションに関する情報を確認します。 + [高可用性に関する問題のトラブルシューティング](troubleshooting-ha-issues.md) - VMware HA 環境にデプロイされているゲートウェイで問題が発生した場合の対処方法について説明します。 # トラブルシューティング: ゲートウェイのオフライン問題 次のトラブルシューティング情報を使用して、 AWS Storage Gateway コンソールにゲートウェイがオフラインであると表示された場合にどう対処すべきかを判断します。 ゲートウェイは、次のいずれかの理由でオフラインと表示されている可能性があります。 + ゲートウェイが Storage Gateway サービスエンドポイントに到達できません。 + ゲートウェイが予期せずシャットダウンしました。 + ゲートウェイに関連付けられたキャッシュディスクが切断または変更されたか、あるいは失敗しました。 ゲートウェイをオンラインに戻すには、ゲートウェイがオフラインになった原因となった問題を特定して解決します。 ## 関連付けられたファイアウォールまたはプロキシの確認 プロキシを使用するようにゲートウェイを設定した場合、またはファイアウォールの背後にゲートウェイを配置した場合は、プロキシまたはファイアウォールのアクセスルールを確認してください。プロキシまたはファイアウォールは、Storage Gateway に必要なネットワークポートとサービスエンドポイントとの間のトラフィックを許可する必要があります。詳細については、「[ネットワークとファイアウォールの要件](https://docs.aws.amazon.com/storagegateway/latest/vgw/Requirements.html#networks)」を参照してください。 ## ゲートウェイのトラフィックの継続的な SSL またはディープパケット検査の確認 ゲートウェイと の間のネットワークトラフィックに対して SSL またはディープパケット検査が現在実行されている場合 AWS、ゲートウェイは必要なサービスエンドポイントと通信できない可能性があります。ゲートウェイをオンラインに戻すには、検査を無効にする必要があります。 ## ハイパーバイザーホストで停電やハードウェア障害がないかの確認 ゲートウェイのハイパーバイザーホストで停電やハードウェア障害が発生すると、ゲートウェイが想定外にシャットダウンし、アクセスできなくなる可能性があります。電源とネットワーク接続を復元すると、ゲートウェイに再びアクセスできるようになります。 ゲートウェイがオンラインに戻ったら、必ずデータを復旧する手順を実行してください。詳細については、「[データの復旧に関するベストプラクティス](https://docs.aws.amazon.com/storagegateway/latest/vgw/recover-data-from-gateway.html)」を参照してください。 ## 関連付けられたキャッシュディスクの問題の確認 ゲートウェイに関連付けられたキャッシュディスクの少なくとも 1 つが削除、変更、またはサイズ変更された場合や、破損した場合、ゲートウェイはオフラインになる可能性があります。 **ハイパーバイザーホストから動作キャッシュディスクが削除された場合:** 1. ゲートウェイをシャットダウンします。 1. ディスクを再度追加します。 **注記** ディスクは必ず同じディスクノードに追加してください。 1. ゲートウェイを再起動します。 **キャッシュディスクが破損しているか、置き換えられたか、またはサイズが変更された場合:** 1. ゲートウェイをシャットダウンします。 1. キャッシュディスクをリセットします。 1. キャッシュストレージ用にディスクを再設定します。 1. ゲートウェイを再起動します。 # トラブルシューティング: ゲートウェイのアクティベーション中の内部エラー 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/storagegateway/latest/vgw/manage-on-premises-common.html#MaintenanceTestGatewayConnectivity-common)」を参照してください。 **注記** ゲートウェイコンソールのデフォルトのログインユーザー名は `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/storagegateway/latest/vgw/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 ## 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/storagegateway/latest/vgw/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/storagegateway/latest/vgw/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/storagegateway/latest/vgw/troubleshooting-on-premises-gateway-issues.html) それでもゲートウェイ IP アドレスが見つからない場合は、 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/storagegateway/latest/vgw/troubleshooting-on-premises-gateway-issues.html) | | ネットワークまたはファイアウォールに問題があります。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/storagegateway/latest/vgw/troubleshooting-on-premises-gateway-issues.html) | | Storage Gateway マネジメントコンソールで **[アクティブ化に進む]** ボタンをクリックすると、ゲートウェイのアクティベーションは失敗します。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/storagegateway/latest/vgw/troubleshooting-on-premises-gateway-issues.html) | | アップロードバッファ領域として割り当てられているディスクを削除する必要があります。たとえば、ゲートウェイのアップロードバッファ領域の量を減らしたり、エラーが発生したアップロードバッファとして使用されているディスクを置き換えたりする必要が生じる場合があります。 | アップロードバッファ領域として割り当てられているディスクを削除する手順については、「[ゲートウェイからのディスクの削除](add-remove-disks.md)」を参照してください。 | | ゲートウェイと AWSの間の帯域幅を改善する必要があります。 | アプリケーションとゲートウェイ VM を接続するネットワークアダプタ (NIC) AWS で へのインターネット接続を設定 AWS することで、ゲートウェイから への帯域幅を向上させることができます。このアプローチは、 への高帯域幅接続があり、特にスナップショットの復元中に帯域幅の競合を回避 AWS したい場合に便利です。高スループットのワークロードが要求される場合、[Direct Connect](https://aws.amazon.com/directconnect/) を使用して、オンプレミスのゲートウェイと AWSの間の専用ネットワーク接続を確立できます。ゲートウェイから への接続の帯域幅を測定するには AWS、ゲートウェイの `CloudBytesDownloaded`および `CloudBytesUploaded`メトリクスを使用します。この詳細については、「[ゲートウェイと の間のパフォーマンスの測定 AWS](PerfGatewayAWS-common.md)」を参照してください。インターネット接続を改善すれば、アップロードバッファがいっぱいになることがありません。 | | ゲートウェイへのスループットまたはゲートウェイからのスループットがゼロに落ちます。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/storagegateway/latest/vgw/troubleshooting-on-premises-gateway-issues.html) Amazon CloudWatch コンソールにゲートウェイとの双方向のスループットを表示できます。ゲートウェイと との間のスループットの測定の詳細については AWS、「」を参照してください[ゲートウェイと の間のパフォーマンスの測定 AWS](PerfGatewayAWS-common.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**するには、 と入力します。 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/storagegateway/latest/vgw/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 の時刻を確認して修正します。詳細については、「[VM の時刻を Hyper-V または Linux KVM ホストの時刻と同期する](MaintenanceTimeSync-hyperv.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 にデプロイされているゲートウェイの違いに関する詳細については、「[ボリュームゲートウェイ用にカスタマイズされた Amazon EC2 インスタンスをデプロイする](ec2-gateway-common.md)」を参照してください。 **Topics** + [しばらくしてもゲートウェイのアクティベーションが実行されない](#activation-issues) + [インスタンスリストに EC2 ゲートウェイインスタンスがない](#find-instance) + [Amazon EBS ボリュームを作成したが、EC2 ゲートウェイインスタンスにアタッチできない](#ebs-volume-issue) + [EC2 ゲートウェイのボリュームターゲットにイニシエータをアタッチできない](#initiator-issue) + [ストレージボリュームを追加するときに利用可能なディスクがないというメッセージが表示される](#no-disk) + [アップロードバッファ領域を削減するために、アップロードバッファ領域として割り当てられたディスクを削除したい](#uploadbuffer-issue) + [EC2 ゲートウェイとの間のスループットがゼロに低下する](#gateway-throughput-issue) + [EC2 ゲートウェイのトラブルシューティングを支援 サポート したい](#EC2-EnableAWSSupportAccess) + [Amazon EC2 シリアルコンソールを使用してゲートウェイインスタンスに接続したい](#ec2-serial-console) ## しばらくしてもゲートウェイのアクティベーションが実行されない 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 EBS ボリュームを作成したが、EC2 ゲートウェイインスタンスにアタッチできない 問題の Amazon EBS ボリュームがゲートウェイインスタンスと同じアベイラビリティーゾーンにあることを確認します。アベイラビリティーゾーンが異なる場合、インスタンスと同じアベイラビリティーゾーンで新しい Amazon EBS ボリュームを作成します。 ## EC2 ゲートウェイのボリュームターゲットにイニシエータをアタッチできない iSCSI アクセスに使用しているポートを許可するルールが、インスタンスを起動したセキュリティグループに含まれていることを確認します。通常、ポートは 3260 に設定されています。ボリュームへの接続の詳細については、「[Windows クライアントからボリュームへの接続](ConfiguringiSCSIClient.md)」を参照してください。 ## ストレージボリュームを追加するときに利用可能なディスクがないというメッセージが表示される 新しくアクティベートしたゲートウェイには、ボリュームストレージが定義されていません。ボリュームストレージを定義するには、アップロードバッファおよびキャッシュストレージとして使用するために、先にゲートウェイにローカルディスクを割り当てる必要があります。Amazon EC2 にデプロイされているゲートウェイについては、ローカルディスクはインスタンスにアタッチされている Amazon EBS ボリュームになります。このエラーメッセージは、インスタンスに Amazon EBS ボリュームが定義されていないために発生する可能性が高いと考えらえます。 ゲートウェイを実行しているインスタンスに定義されているブロックデバイスを確認します。ブロックデバイスが 2 つだけ (AMI に付属するデフォルトデバイス) の場合、ストレージを追加してください。その設定方法の詳細については、「[ボリュームゲートウェイ用にカスタマイズされた Amazon EC2 インスタンスをデプロイする](ec2-gateway-common.md)」を参照してください。2 つ以上の Amazon EBS ボリュームを取り付けたら、ゲートウェイにボリュームストレージを作成してみます。 ## アップロードバッファ領域を削減するために、アップロードバッファ領域として割り当てられたディスクを削除したい 「[割り当てるアップロードバッファのサイズの決定](decide-local-disks-and-sizes.md#CachedLocalDiskUploadBufferSizing-common)」のステップを実行してください。 ## EC2 ゲートウェイとの間のスループットがゼロに低下する ゲートウェイインスタンスが実行中であることを確認します。たとえば、再起動に起因してインスタンスが起動中の場合、インスタンスが再開するのを待ちます。 また、ゲートウェイ IP が変更されていないことを確認します。インスタンスを停止し、再開した場合、インスタンスの IP アドレスが変わっている可能性があります。その場合、新しいゲートウェイをアクティブ化する必要があります。 Amazon CloudWatch コンソールにゲートウェイとの双方向のスループットを表示できます。ゲートウェイと との間のスループットの測定の詳細については AWS、「」を参照してください[ゲートウェイと の間のパフォーマンスの測定 AWS](PerfGatewayAWS-common.md)。 ## 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**」と入力してセッションを終了します。サポートセッションが完了したことが サポート 通知されるまで、セッションを閉じないでください。 1. 「**exit**」と入力して、Storage Gateway コンソールを終了します。 1. コンソールメニューに従って Storage Gateway インスタンスからログアウトします。 ## Amazon EC2 シリアルコンソールを使用してゲートウェイインスタンスに接続したい Amazon EC2 シリアルコンソールを使用して、起動、ネットワーク設定、およびその他の問題のトラブルシューティングができます。手順とトラブルシューティングのヒントについては、「*Amazon Elastic Compute Cloud ユーザーガイド*」の「[Amazon EC2 シリアルコンソール](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-serial-console.html)」を参照してください。 # ハードウェアアプライアンスの問題のトラブルシューティング 以下のトピックでは、 Storage Gateway ハードウェアアプライアンスを使用する際に発生する可能性がある問題と、そのトラブルシューティング案を示します。 ## サービスの IP アドレスを特定できない ご利用のサービスに接続するときは、ホストの IP アドレスではなく、サービスの IP アドレスを使用していることを確認します。サービスのコンソールでサービスの IP アドレスを設定し、ハードウェアコンソールでホストの IP アドレスを設定します。ハードウェアコンソールは、ハードウェアアプライアンスを起動すると表示されます。ハードウェアコンソールからサービスコンソールにアクセスするには、**[サービスコンソールを開く]** を選択します。 ## 工場出荷時設定へのリセットを実行するにはどうすればよいですか アプライアンスで工場出荷時設定へのリセットを行う必要がある場合は、以下のサポートセクションの説明に従って、サポートについて 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 Gateway コンソールを使用して、Storage 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. ポート番号を書き留めて指定します サポート。 # ボリュームの問題のトラブルシューティング このセクションでは、ボリュームを使用しているときに発生する可能性のある最も一般的な問題と、これらを修正する際に推奨されるアクションについて説明します。 **Topics** + [ボリュームが設定されていないとコンソールに表示される](#troubleshoot-volume-issues.VolumeNotConfigured) + [ボリュームは復旧不可能であるとコンソールに表示される](#troubleshoot-volume-issues.VolumeIrrecoverable) + [ゲートウェイキャッシュ型が到達不可能なためデータを復旧する場合](#RecoverySnapshotTroubleshooting) + [ボリュームのステータスが PASS THROUGH であるとコンソールに表示される](#troubleshoot-volume-issues.VolumePassthrough) + [ボリュームの整合性を確認し、エラーがある場合は修正する](#troubleshoot-volume-issues.VerifyIntegrity) + [ボリュームの iSCSI ターゲットが Windows のディスク管理コンソールに表示されない](#troubleshoot-volume-issues.DoesNotAppear) + [ボリュームの iSCSI ターゲット名を変更したい](#troubleshoot-volume-issues.ChangeISCSI) + [スケジュールしたボリュームのスナップショットが実行されなかった](#troubleshoot-volume-issues.NoSnapshot) + [障害が発生したディスクの取り外しまたは交換が必要な場合](#troubleshoot-volume-issues.RemoveVolume) + [アプリケーションからボリュームへのスループットがゼロに低下した](#troubleshoot-volume-issues.ThroughputZero) + [ゲートウェイのキャッシュディスクでエラーが発生する](#troubleshoot-volume-issues.CacheDiskFail) + [ボリュームのスナップショットのステータスが予想以上に長い時間にわたって PENDING のままである](#SnapshotTroubleshooting.Pending) + [高可用性のヘルス通知](#troubleshooting-ha-notifications) ## ボリュームが設定されていないとコンソールに表示される Storage Gateway コンソールで、ボリュームのステータスが「UPLOAD BUFFER NOT CONFIGURED (アップロードバッファが構成されていません)」と表示されている場合は、アップロードバッファ容量をゲートウェイに追加します。ゲートウェイのアップロードバッファが設定されていない場合、ゲートウェイを使用してアプリケーションデータを格納することはできません。詳細については、「[ゲートウェイ用のアップロードアップロードバッファまたはキャッシュストレージを追加して設定するには](ConfiguringLocalDiskStorage.md#GatewayWorkingStorageCachedTaskBuffer)」を参照してください。 ## ボリュームは復旧不可能であるとコンソールに表示される 保管型ボリュームの場合、Storage Gateway コンソールにボリュームのステータスが「IRRECOVERABLE (回復不可能)」と表示されていたら、このボリュームはもう使用できません。Storage Gateway コンソールで、ボリュームの削除を試みることができます。ボリュームにデータがある場合は、新しいボリュームを作成するときに、最初にボリュームを作成するために使用された VM のローカルディスクに基づいて、データを復旧できます。新しいボリュームを作成するとき、[**Preserve existing data**] を選択します。ボリュームを作成する前に、必ずボリュームの保留スナップショットを削除してください。詳細については、「[ストレージボリュームのスナップショットの削除](DeletingASnapshot.md)」を参照してください。Storage Gateway コンソールでボリュームを削除できない場合は、ボリュームに割り当てられているディスクが VM から不適切に削除されたために、アプライアンスから削除できない可能性があります。 キャッシュ型ボリュームでは、Storage Gateway コンソールが示すボリュームのステータスが IRRECOVERABLE であれば、このボリュームはもう使用できません。ボリュームにデータがある場合、ボリュームのスナップショットを作成し、スナップショットからデータを回復したり、最後の復旧ポイントからボリュームをクローンしたりすることができます。データを復旧した後、こののボリュームは削除できます。詳細については、「[ゲートウェイキャッシュ型が到達不可能なためデータを復旧する場合](#RecoverySnapshotTroubleshooting)」を参照してください。 保存型ボリュームでは、回復不可能なボリュームの作成に使用されたディスクから新しいボリュームを作成できます。詳細については、「[ストレージボリュームの作成](GettingStartedCreateVolumes.md)」を参照してください。ボリュームステータスについては、「[ボリュームステータスと移行について](StorageVolumeStatuses.md)」を参照してください。 ## ゲートウェイキャッシュ型が到達不可能なためデータを復旧する場合 ゲートウェイが到達不可能になった時は (シャットダウン時など)、ボリューム復旧ポイントからスナップショットを作成し、そのスナップショットを使用するか、または既存ボリュームの最後の復旧ポイントから新しいボリュームをクローンすることができます。ボリューム復旧ポイントからのクローンは、スナップショットを作成するよりも素早く経済的です。ボリュームのクローン作成に関する詳細については、「[復旧ポイントからキャッシュされたボリュームのクローン](clone-volume.md)」を参照してください。 Storage Gateway には、キャッシュ型ボリュームゲートウェイアーキテクチャで各ボリュームの復旧ポイントが用意されています。*ボリューム復旧ポイント*とは、ボリュームのすべてのデータに整合性があり、そこからスナップショットを作成したり、ボリュームをクローンしたりできる時点です。 ## ボリュームのステータスが PASS THROUGH であるとコンソールに表示される ボリュームのステータスが「PASSTHROUGH (パススルー)」であると Storage Gateway コンソールに表示されることがあります。ボリュームのステータスがパススルーとなる場合、複数の理由が考えられます。アクションが必要な理由と、そうでない理由があります。 たとえば、ゲートウェイのアップロードバッファ領域が完全に消費されているためボリュームのステータスが PASS THROUGH になっている場合には、アクションが必要です。アップロードバッファが過去に超過したかどうかを確認するには、Amazon CloudWatch コンソールで `UploadBufferPercentUsed` メトリクスを確認します。詳細については、「[アップロードバッファのモニタリング](PerfUploadBuffer-common.md)」を参照してください。アップロードバッファ領域を使い切ったためゲートウェイのステータスが PASS THROUGH になっている場合、ゲートウェイに追加のアップロードバッファ領域を割り当てる必要があります。バッファ領域を追加すると、ボリュームのステータスが自動的に PASS THROUGH から BOOTSTRAPPING (ブートストラップ) に変わり、さらに AVAILABLE (使用可能) に変わります。ボリュームのステータスが BOOTSTRAPPING のとき、ゲートウェイはボリュームのディスクからデータを読み取り、このデータを Amazon S3 にアップロードして、必要に応じてキャッチアップします。ゲートウェイがキャッチアップを完了し、ボリュームデータを Amazon S3 に保存すると、ボリュームのステータスが AVAILABLE になり、スナップショットを再開できるようになります。ボリュームのステータスが PASS THROUGH または BOOTSTRAPPING になっても、ボリュームディスクとの間のデータの読み書きは続行できます。アップロードバッファ容量の追加に関する詳細については、[割り当てるアップロードバッファのサイズの決定](decide-local-disks-and-sizes.md#CachedLocalDiskUploadBufferSizing-common) を参照してください。 アップロードバッファを超過する前に、操作を行うには、ゲートウェイのアップロードバッファにしきい値アラームを設定できます。詳細については、「[ゲートウェイのアップロードバッファの上限アラームを設定するには](PerfUploadBuffer-common.md#GatewayAlarm1-common)」を参照してください。 一方、たとえば、別のボリュームがブートストラップ中であるためブートストラップを待っているボリュームのステータスが PASS THROUGH である場合には、アクションは不要です。ゲートウェイはボリュームを 1 つずつ起動します。 まれに、PASS THROUGH ステータスにより、アップロードバッファに割り当てられているディスクに障害が発生したことが示されることがあります。その場合、ディスクを取り除く必要があります。詳細については、「[ボリュームゲートウェイのストレージリソースの使用](resource-volume-gateway.md)」を参照してください。ボリュームステータスについては、「[ボリュームステータスと移行について](StorageVolumeStatuses.md)」を参照してください。 ## ボリュームの整合性を確認し、エラーがある場合は修正する ゲートウェイが Microsoft Windows イニシエータを使用してそのボリュームに接続している場合は、Windows CHKDSK ユーティリティを使用して、ボリュームの整合性を確認し、ボリュームにエラーがある場合はエラーを修正できます。Windows では、ボリュームの破損が検出されたときに自動的に CHKDSK ツールを実行できます。または、ユーザー自身がこのツールを実行することもできます。 ## ボリュームの iSCSI ターゲットが Windows のディスク管理コンソールに表示されない ボリュームの iSCSI ターゲットが Windows のディスク管理コンソールに表示されない場合は、ゲートウェイのアップロードバッファが設定されていることを確認します。詳細については、「[ゲートウェイ用のアップロードアップロードバッファまたはキャッシュストレージを追加して設定するには](ConfiguringLocalDiskStorage.md#GatewayWorkingStorageCachedTaskBuffer)」を参照してください。 ## ボリュームの iSCSI ターゲット名を変更したい ボリュームの iSCSI ターゲット名を変更するには、そのボリュームを削除し、新しいターゲット名で再度追加する必要があります。この操作を行うと、ボリューム上のデータを保持できます。 ## スケジュールしたボリュームのスナップショットが実行されなかった スケジュールしたボリュームのスナップショットが実行されなかった場合は、ボリュームのステータスがパススルーであるかどうか、またはスケジュールしたスナップショットの実行時刻の直前にゲートウェイのアップロードバッファが完全に消費されていたかどうかを確認します。Amazon CloudWatch コンソールで、ゲートウェイの `UploadBufferPercentUsed` メトリクスを確認し、そのメトリクスに対してアラームを作成できます。詳細については、「[アップロードバッファのモニタリング](PerfUploadBuffer-common.md)」および「[ゲートウェイのアップロードバッファの上限アラームを設定するには](PerfUploadBuffer-common.md#GatewayAlarm1-common)」を参照してください。 ## 障害が発生したディスクの取り外しまたは交換が必要な場合 障害が発生したボリュームディスクや、不要なボリュームを交換する必要がある場合は、まず Storage Gateway コンソールを使用してボリュームを削除する必要があります。詳細については、「[ボリュームを削除するには](ApplicationStorageVolumesCached-Removing.md#CachedRemovingAStorageVolume)」を参照してください。次に、ハイパーバイザークライアントを使用して、バックアップストレージを削除します。 + VMware ESXi の場合、[ストレージボリュームの削除](ApplicationStorageVolumesCached-Removing.md) の説明に基づき、バックアップストレージを削除します。 + Microsoft Hyper-V の場合、バックアップストレージを削除します。 ## アプリケーションからボリュームへのスループットがゼロに低下した アプリケーションからボリュームへのスループットがゼロに低下した場合は、以下を試してください。 + VMware vSphere クライアントを使用している場合は、ボリュームの [**Host IP**] アドレスが、vSphere クライアントの [**Summary**] タブに表示されるアドレスの 1 つと一致していることを確認します。ストレージボリュームの **[Host IP]** (ホスト IP) アドレスは、Storage Gateway コンソールのボリュームの **[Details]** (詳細) タブで確認できます。ゲートウェイに新しい静的 IP アドレスを割り当てたときなどは、IP アドレスに不一致が発生することがあります。不一致がある場合、「[ゲートウェイ VM のシャットダウン](MaintenanceShutDown-common.md)」に示されているように、Storage Gateway コンソールからゲートウェイを再起動します。再起動後、**[ISCSI Target Info]** (ISCSI ターゲット情報) タブのストレージボリュームの **[Host IP]** (ホスト IP) アドレスは、ゲートウェイの **[Summary]** (概要) タブの vSphere クライアントに表示される IP アドレスと一致するはずです。 + ボリュームの [**ホスト IP**] ボックスに IP アドレスがなく、ゲートウェイがオンラインである場合。たとえば、2 つ以上のネットワークアダプタを備えたゲートウェイのネットワークアダプタの IP アドレスに関連付けられたボリュームを作成するときにこの状態が発生することがあります。ボリュームに関連付けられているネットワークアダプタを取り外すか無効にすると、IP アドレスが **[ホスト IP]** に表示されなくなる場合があります。この問題に対処するには、ボリュームを削除し、その既存のデータを保持したまま再度作成します。 + アプリケーションで使用する iSCSI イニシエータが現在、ストレージボリュームの iSCSI ターゲットにマッピングされていることを確認します。ストレージボリュームへの接続の詳細については、[Windows クライアントからボリュームへの接続](ConfiguringiSCSIClient.md) を参照してください。 ボリュームのスループットを表示し、Amazon CloudWatch コンソールからアラームを作成できます。アプリケーションからボリュームへのスループットの測定に関する詳細については、「[アプリケーションとゲートウェイの間のパフォーマンスの測定](PerfAppGateway-common.md)」を参照してください。 ## ゲートウェイのキャッシュディスクでエラーが発生する ゲートウェイの 1 つ以上のキャッシュディスクに障害が発生した場合、仮想テープとボリュームに対する読み取りおよび書き込みオペレーションがゲートウェイによって禁止されます。通常の機能を再開するには、次の手順に従ってゲートウェイを再設定します。 + キャッシュディスクにアクセスできない、または使用できない場合は、ゲートウェイ構成からディスクを削除します。 + キャッシュディスクがまだアクセス可能で使用可能な場合は、ゲートウェイに再接続します。 **注記** キャッシュディスクを削除した場合、ゲートウェイが通常の機能を再開したとき、クリーンデータがあるテープまたはボリューム (キャッシュディスクと Amazon S3 とのデータが同期している場合) は引き続き使用できます。例えば、ゲートウェイに 3 つのキャッシュディスクがあり、2 つを削除した場合、クリーンであるテープまたはボリュームは AVAILABLE ステータスになります。他のテープおよびボリュームは、IRRECOVERABLE ステータスになります。 ゲートウェイのキャッシュディスクとしてエフェメラルディスクを使用したり、キャッシュディスクをエフェメラルドライブにマウントしたりすると、ゲートウェイのシャットダウン時にキャッシュディスクが失われます。キャッシュディスクと Amazon S3 が同期していないときにゲートウェイをシャットダウンすると、データが失われる可能性があります。そのため、エフェメラルドライブやディスクを使用することは推奨されていません。 ## ボリュームのスナップショットのステータスが予想以上に長い時間にわたって PENDING のままである ボリュームのスナップショットが予想以上に長い時間にわたって保留中状態のままである場合は、ゲートウェイ VM が予期せずクラッシュしたか、ボリュームのステータスがパススルーまたは回復不能に変わった可能性があります。これらのいずれかの場合、スナップショットのステータスは PENDING のままになり、スナップショットは正常に完了しません。この場合は、スナップショットを削除することをお勧めします。詳細については、「[ストレージボリュームのスナップショットの削除](DeletingASnapshot.md)」を参照してください。 ボリュームのステータスが使用可能に戻ったら、ボリュームの新しいスナップショットを作成します。ボリュームステータスについては、「[ボリュームステータスと移行について](StorageVolumeStatuses.md)」を参照してください。 ## 高可用性のヘルス通知 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 ロググループを参照してください。