EFS ファイルシステムのマウント時に「nfs: server 127.0.0.1 が応答しません」というエラーのトラブルシューティングを行う方法を教えて下さい。

所要時間2分
0

Amazon Elastic File System (Amazon EFS) サーバーが応答せず、「nfs: サーバー 127.0.0.1 が応答していません」というエラーメッセージが表示され、ハングします。この問題を解決する方法を教えてください。

簡単な説明

サーバーが応答しないというエラーが表示される一般的な理由は次のとおりです:

  • NFS クライアントが EFS サーバーに接続することができない。
  • インスタンスの再起動またはシャットダウンが発生した。または、EC2 インスタンスからの他の接続が切断された。このような状況が発生すると、NFS クライアントと EFS サーバー間のネットワーク接続が切断されます。この動作は TCP RFC に準拠していません。接続が切断されると、Amazon EFS から Amazon Elastic Compute Cloud (Amazon EC2) インスタンスまたは NFS クライアントへの応答が数分間ブロックされる可能性があります。
  • NFS クライアントを使用してファイルシステムをマウントするとき、noresvport マウントオプションは使用されていませんでした。
  • EFS マウント障害の原因となるカーネルバージョンに問題がある可能性があります。例えば、RHEL6 には、応答しないファイルシステムと同様の症状を引き起こす NFS クライアントの問題が数多く確認されています。以前のカーネルバージョンの RHEL6.X では、ファイルシステムが使用できなくなり、再マウントに失敗することがあります。以下を実行している場合、Amazon EFS で NFS 接続がハングすることがあります:
  • RHEL または CentOS 7.6 以降 (カーネルバージョン 3.10.0-957)
  • カーネルバージョン 4.16 から 4.19 までの、それ以外の Linux ディストリビューション

解決方法

1.    ファイルシステムをマウントするときは、noresvport マウントオプションを使用します。このオプションにより、ネットワーク接続を再確立する必要がある場合に、NFS クライアントが新しい TCP ソースポートを使用するようにします。noresvport を使用すると、ネットワークリカバリイベント後も EFS ファイルシステムの可用性が中断されることはありません。

$   sudo mount -t nfs -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport mount-target-ip:/ mnt

EFS マウントヘルパーを使用している場合、デフォルトで noresvport オプションが表示されます。マウントに NFS を使用している場合は、このパラメーターを明示的に追加する必要があります。詳細については、「NFS の推奨されるマウントオプション」を参照してください。

2.    カーネルバージョンを確認します。RHEL や CentOS 7.6 以降 (カーネルバージョン 3.10.0-957) などの、特定のカーネルバージョンに問題があり、ファイルシステムのマウントが失敗する可能性があります。これらのカーネルバージョンのいずれかを実行している場合は、ファイルシステムへのアクセスを回復するため再起動します。カーネルバージョンが問題であることを確認するには、ls を実行できないときの ps コマンドの出力を確認します:

$ ps auxwwwm | grep <mount_point_IP>

カーネルバージョンに問題がある場合は、カーネルをアップグレードします。パフォーマンスを改善させるには、現行世代の Linux NFS4v.1 かそれ以降のクライアントを使用するのがベストプラクティスです。

3.    次のコマンドを実行して、クライアントがサーバーに接続できることを確認します:

telnet <ip-of-efs> 2049

/var/log/messages の下にある NFS クライアントログ (EC2 インスタンス OS ログ) にエラーがないかどうかを確認します。ログは、ご使用の OS に応じて、 /var/log/syslog または /var/log/dmesg ディレクトリの下にある場合があります。

また、EFS マウントヘルパーを使用してファイルシステムをマウントした場合は、/var/log/amazon/efs ディレクトリの下にある EFS util ログを確認します。EFS マウントヘルパーには、ログメカニズムが組み込まれています。

4.    EC2 インスタンスに接続できることを確認します。

5.    リソースの過剰使用により EC2 が過負荷になっていないか確認します。これは、CPUUtilization やネットワーク関連のメトリクスなど、Amazon CloudWatch の EC2 メトリックスをモニタリングすることで確認できます。リソースには、CPU、メモリ、アプリケーションレベルの問題などが含まれます。

  • メモリの過剰使用: これは、RAM が過剰に利用されている場合に発生することがあります。過剰使用とは、例えば、アプリケーションがより多くの RAM を消費し始めた場合に、インスタンスのメモリ容量が不足している状態を指します。過剰使用により、メモリ不足 (OOM) エラーが発生します。これらのエラーが発生すると、OOM スコアが高いプロセスやメモリを消費しているプロセスを終了させてしまいます。OOM エラーが発生しても、インスタンスにアクセスできない状態であることが理想的です。
    OOM エラーを一時的に解決するには、システムを再起動してメモリ領域を解放します。
    長期的な解決策として、「atop」や「top」などのツールを使用し、システムリソースの使用量をモニタリングします。次に、ワークロードにより適した別のインスタンスタイプへ移行します。詳細については、「EC2 Linux インスタンスがリソースの過剰使用が原因で応答しなくなるのはなぜですか?」を参照してください。
  • ネットワークパフォーマンス: インスタンスのネットワークパフォーマンスを確認します。CloudWatch メトリクスでネットワークの使用率が低くても、マイクロバーストが発生することがあります。マイクロバーストは、数秒の内にワークロードから大量のトラフィックを送信するものです。マイクロバーストは、通常 1 分以内に終了します。CloudWatch グラフや Amazon Elastic Block Store (Amazon EBS) の統計ではこれらのツール内で使用される最小間隔が 1 分であるため、このバーストは不明瞭です。「sar」、「nload」、「iftop」などのツールを使用して、マイクロバーストの動作をモニタリングします。詳細については、「平均使用率が低いのに、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスがネットワーク制限を超えるのはなぜですか?」を参照してください。

6.    EFS CloudWatch メトリックスを確認し、EFS レベルでスロットリングが発生するかどうかを確認します。これは、EFS がキャパシティを超えて動作していることを意味します。バーストスループットモードを使用している場合は、BurstBalance CloudWatch メトリックスを確認し、バーストバランスが不足していないかを確認します。また、許可されたスループットの CloudWatch メトリックスを確認して、プロビジョニングされた量よりも高いスループットを使用しているかどうかを特定します。バーストクレジットの詳細については、「Amazon EFS バーストクレジットの仕組みを教えてください」を参照してください。

アプリケーションで常に継続的なスループットが必要な場合は、プロビジョンドスループットモードを使用します。バーストスループットからプロビジョンドスループットモードに切り替える前に、どの程度のスループットをプロビジョニングするかを検討します。必要なプロビジョンドスループットの最小量を判断するには、過去 2 週間のファイルシステムの平均スループット使用量を確認します。最も高いピーク時の量を確認し、メガバイト単位で切り上げます。詳細については、「EFS で使用できるスループットモードは何ですか、また、ワークロードに適したスループットモードは何ですか?」を参照してください。


関連情報

マウント問題のトラブルシューティング

Amazon EFS のトラブルシューティング

AWS公式
AWS公式更新しました 2年前