AWS ボリュームのアタッチに時間がかかります。デバッグするにはどうすればいいですか?

AWS ボリュームのアタッチに時間がかかります。デバッグするにはどうすればいいですか?

実稼働 EC2 インスタンスに 10 GB のボリュームが接続されています (300 MB しか使用されていません)。バックアップを行うために、そのスナップショットを作成しました。次に、そのスナップショットからボリュームを作成し、別の EC2 インスタンスに接続しようとしました。ボリュームのステータスは「接続中」と表示され、接続されません。4 回試しましたが、そのうち 1 回だけ正常に接続され、EC2 インスタンスからマウントできました。その 1 回は、接続に 1 分もかかりませんでした。他のすべての時間は、「接続中」状態で停止します。3 ~ 4 時間待っていますが、役に立ちません。その場合、実行できるのは「強制的にデタッチ」することだけです。私はこれまでずっと Web UI を使用しており、CLI は使用していません。

何が間違っているのでしょうか? この問題をどのようにデバッグすればよいでしょうか?

答え1

数か月前にも同じような問題がありました。結局、Amazon 側の問題でした。ec2 フォーラムで Amazon の担当者に連絡してようやく解決しました。https://forums.aws.amazon.com/forum.jspa?forumID=30

答え2

私の場合、実際の問題は 1 つの ec2 インスタンスでした。ボリュームが時々接続されたり切断されたりしていたインスタンスがいくつかありました。他のインスタンスではすべて正常でした。チケットを開いた後、AWS チームが言ったことは次のとおりです。

「OS がデバイス マッピングをロックすることが時々ありますが、これを回避するには、OS を再起動するか (推奨)、デバイス マッピングを変更するか (例: /dev/sdf から /dev/sdj) のいずれかを行います。」

再起動は機能しましたが、1 回の再起動のみで、その後、問題が再発しました。その ec2 インスタンスを毎回再起動したくありませんでした。

sdjへのマッピングは確認していないので、動作するかどうかはわかりません

実際に機能したのは、障害のあるインスタンスをダンプし、その代わりに新しいインスタンスを作成することでした。それを実行した後、すべて正常に動作しました。

関連情報