AWS EC2でNVMEディスクをマウントする

Question

だから私は各ノードにNVMEディスクでi3.largeを作成しました、ここに私のプロセスがありました：

lsblk-> nvme0n1（nvmeがまだマウントされていないか確認してください）
Sudo mkfs.ext4 -E nodiscard/dev/nvme0n1
Sudoマウント-o discard/dev/nvme0n1/mnt/my-data
/ dev/nvme0n1/mnt/my-data ext4 defaults、nofail、discard 0 2
Sudo mount -a（すべてが正常かどうかを確認します）
須藤リブート

これですべてが機能し、インスタンスに接続できます。新しいパーティションに500 Goがあります。

しかし、EC2マシンを停止して再起動した後、一部のマシンはランダムにアクセスできなくなりました（AWSは1/2のテストステータスのみをチェックしました）

アクセスできない理由のログを見ると、それはnvmeパーティションに関するものです（ただし、Sudo mount -aを実行して、これが問題ないかどうかを確認したため、わかりません）

私はAWSのログを正確に持っていませんが、いくつかの行があります：

開こうとしているときに、スーパーブロック内の不正なマジックナンバー

その後、スーパーブロックが破損しているため、代替スーパーブロックでe2fsckを実行してみてください。

/ dev/fd/9：行2：plymouth：コマンドが見つかりません

Michael - sqlbot · Accepted Answer

インスタンスを停止して起動すると、エフェメラルディスクが消去され、インスタンスが新しいホストハードウェアに移動され、新しい空のディスクが提供されます...そのため、エフェメラルディスクは停止/起動後に常に空白になります。インスタンスが停止しても、物理ホストには存在しません-リソースは解放されます。

したがって、インスタンスを停止および開始する場合の最良のアプローチは、それらを/etc/fstabに追加するのではなく、最初のブート時にフォーマットしてからマウントすることです。ファイルシステムが既に存在するかどうかをテストする1つの方法は、fileユーティリティとgrepの出力を使用することです。 grepが一致するものを見つけられない場合、falseを返します。

I3インスタンスクラスのNVMe SSDは、 Instance Store Volume の例であり、Ephemeral [Disk |ボリューム|ドライブ]。それらは物理的にインスタンス内にあり、非常に高速ですが、冗長ではなく、永続的なデータを対象としていません...したがって、「一時的」です。永続データは Elastic Block Store（EBS）ボリュームまたは Elastic File System（EFS）に存在する必要があります。どちらもインスタンスの停止/開始、ハードウェア障害、メンテナンス。

インスタンスが起動に失敗する理由は明らかではありませんが、nofailは、ボリュームが存在するがファイルシステムがない場合に期待どおりに動作しない可能性があります。私の印象では、最終的には成功するはずです。

ただし、Ubuntu 16.04を実行している場合は、 apt-get install linux-aws が必要になる場合があります。 Ubuntu 14.04 NVMeのサポートは実際には安定しておらず、非推奨です。

これら3つのストレージソリューションにはそれぞれ長所と短所があります。

インスタンスストアはローカルなので、非常に高速です...しかし、それは一時的なものです。ハードリブートとソフトリブートに耐えますが、停止/開始サイクルには耐えません。インスタンスにハードウェア障害が発生した場合、またはすべてのハードウェアに最終的に発生するリタイアが予定されている場合は、インスタンスを停止および開始して新しいハードウェアに移動する必要があります。リザーブドインスタンスと専用インスタンスは、一時ディスクの動作を変更しません。

EBSは永続的な冗長ストレージであり、1つのインスタンスから切り離して別のインスタンスに移動することができます（これは停止/開始を越えて自動的に行われます）。 EBSはポイントインタイムスナップショットをサポートしており、これらはブロックレベルで増分であるため、スナップショット間で変更されなかったデータを保存する費用はかかりません...しかし、いくつかの優れた魔術を通して、あなたも持っていません「フル」スナップショットと「インクリメンタル」スナップショットを追跡するために、スナップショットはバックアップされたデータブロックへのポインタの論理コンテナにすぎないため、本質的にはすべて「フル」スナップショットですが、増分として請求されます。スナップショットを削除すると、そのスナップショットと他のスナップショットのいずれかを復元する必要がなくなったブロックのみがバックエンドストレージシステムから消去されます（これは実際にはAmazon S3を使用します）。

EBSボリュームは、SSDと回転するPlatter磁気ボリュームの両方として利用できますが、コスト、パフォーマンス、および適切なアプリケーションのトレードオフがあります。 EBSボリュームタイプを参照してください。 EBSボリュームは通常のハードドライブに似ていますが、容量を必要に応じて手動で増やすことができます（ただし、減らすことはできません）。また、システムをシャットダウンせずにボリュームタイプを別のボリュームタイプに変換できます。 EBSはすべてのデータ移行をオンザフライで実行し、パフォーマンスは低下しますが、中断はありません。これは比較的最近の革新です。

EFSはNFSを使用するため、1つのリージョン内のアベイラビリティーゾーンをまたいで、必要な数のインスタンスにEFSファイルシステムをマウントできます。 EFSの1つのファイルのサイズ制限は52テラバイトであり、インスタンスは実際に8エクサバイトの空き容量を報告します。実際の空き容量は、すべての実用的な目的で無制限ですが、EFSは最も高価です。52TiBファイルを1か月間保存した場合、そのストレージは15,000ドル以上かかります。私が今までに保管したほとんどのものは、2週間で約20 TiBで、約5,000ドルかかりましたが、スペースが必要な場合はそこにあります。 1時間ごとに請求されるため、52 TiBファイルをほんの数時間保存してから削除した場合、おそらく50ドルを支払うことになります。 EFSの「弾性」とは、容量と価格を指します。 EFSにスペースを事前にプロビジョニングしないでください。必要なものを使用し、不要なものを削除すると、請求可能なサイズが1時間ごとに計算されます。

ストレージの説明は、S3がなければ完了しません。ファイルシステムではなく、オブジェクトストアです。 EFSの価格の約1/10で、S3の容量は事実上無限であり、最大オブジェクトサイズは5TBです。一部のアプリケーションは、ファイルではなくS3オブジェクトを使用してより適切に設計されます。

S3は、データセンターまたは別のクラウドにあるかどうかに関係なく、AWSの外部のシステムでも簡単に使用できます。他のストレージテクノロジーはEC2内での使用を目的としていますが、プロキシとトンネルを使用して、外部またはリージョン間でEFSを使用できるドキュメント化されていない回避策があります。

Vlad Holubiev · Answer

ローカルNVMeストレージを備えた便利な新しいEC2インスタンスファミリを見つけることができます：C5d。

発表のブログ投稿を参照してください： https://aws.Amazon.com/blogs/aws/ec2-instance-update-c5-instances-with-local-nvme-storage-c5d/

ブログ投稿からの抜粋：

AMIでブロックデバイスマッピングを指定する必要はありません、またはインスタンスの起動中に。ローカルストレージは、ゲストオペレーティングシステムの起動後に1つ以上のデバイス（Linuxでは/ dev/nvme * 1）として表示されます。
ローカルストレージの追加以外は、C5とC5dは同じ仕様を共有しています。
Elastic Network Adapter（ENA）およびNVMeのドライバーを含むAMIを使用できます
各ローカルNVMeデバイスは、XTS-AES-256ブロック暗号と一意のキーを使用して暗号化されたハードウェアです。
ローカルNVMeデバイスは、接続されているインスタンスと同じライフタイムを持ち、インスタンスが停止または終了した後も保持されません。

user1619801 · Answer

私はちょうど同じような経験をしました！ C5.xlargeインスタンスは、EBSをnvme1n1として検出します。この行をfstabに追加しました。

 /dev/nvme1n1 /data ext4 discard,defaults,nofail 0 2

数回再起動した後、動作しているように見えました。それは数週間走り続けました。しかし、今日、インスタンスが接続できなかったという警告を受け取りました。 AWSコンソールから再起動してみましたが、原因はfstabのようです。ディスクのマウントに失敗しました。

AWSサポートへのチケットを募集しましたが、まだフィードバックはありません。サービスを回復するには、新しいインスタンスを起動する必要があります。

別のテストインスタンスでは、/ dev/nvme1n1の代わりにUUID（get by command blkid）を使用しようとします。これまでのところまだ動作しているように見えます...それが問題を引き起こすかどうか確認します。

AWSからのフィードバックがあれば、ここで更新します。

================私の修正で編集===========

AWSはまだフィードバックをくれませんが、問題は見つかりました。実際、fstabでは、/ dev/nvme1n1またはUUIDをマウントするかどうかは関係ありません。私の問題は、ESBのファイルシステムにエラーがあることです。インスタンスに添付して実行します

fsck.ext4 /dev/nvme1n1

いくつかのファイルシステムエラーを修正したら、fstabに入れて再起動します。もう問題ありません！