web-dev-qa-db-ja.com

Amazon AWS EphemeralディスクとRAID1

一部のAWSインスタンスには「エフェメラルディスク」が接続されており、EBSよりもはるかに高速です。ただし、エフェメラルディスクは、インスタンスが停止して起動すると空になり、初期化されません。ただし、ディスク上のデータは通常、インスタンスの再起動後も存続します。

質問：エフェメラルディスクとEBSボリューム上に構築されたAWSインスタンスでソフトウェアRAID1を使用する必要がありますか？

私の考えでは、raid1はEBSボリュームのみで縮退モードで起動し、mdadmコマンドを使用して空の一時ディスクをraidに戻すことができます。これにより、raid1が同期している間、パフォーマンスが低下しますが、アプリは5〜10分早く起動できます。

背景：最大40 GBのデータファイルを使用するアプリがあります。アクセス時間はパフォーマンスと直接相関するため、ディスクが高速であるほど、アプリの動作も高速になります。

これまでは、rc.localからrsyncデータ、EBSディスクから一時ディスクへの実行を行ってから、ソフトウェアを起動してきました。同期にかかる時間は5〜10分で、別のインスタンスからの同期にかかる5〜20分よりも優れています。過去には、一時ディスクほど高速ではないRAMディスクのデータファイルを使用することもありました。

詳細-これはi3.4xlargeであるため、2x NVME ephemeralドライブを備えています。

# hdparm -t /dev/md? /dev/nvme?n1 /dev/xvd?
/dev/md0:     9510 MB in  3.00 seconds = 3169.78 MB/sec RAID0 of two eph drives
/dev/nvme0n1: 4008 MB in  3.00 seconds = 1335.74 MB/sec Eph drive
/dev/nvme1n1: 4014 MB in  3.00 seconds = 1337.48 MB/sec Eph drive
/dev/xvda:     524 MB in  3.01 seconds = 174.17 MB/sec  gp2 16GB, 100 IOPs root
/dev/xvdf:     524 MB in  3.01 seconds = 174.23 MB/sec  gp2 120GB, 300 IOPs data
/dev/xvdz:     874 MB in  3.01 seconds = 290.68 MB/sec  gp2 500GB, 1500 IOPs raid-seed disk

私はraid1を作成しました

mdadm  --create /dev/md1 --raid-devices=3 --verbose --level=1 /dev/nvme?n1 /dev/xvdz

これは次を返します：

$ cat /proc/mdstat
Personalities : [raid0] [raid1]
md1 : active raid1 nvme1n1[4] nvme0n1[3] xvdz[2]
      524155904 blocks super 1.2 [3/3] [UUU]
      bitmap: 0/4 pages [0KB], 65536KB chunk

奇妙なことに、RAIDは高速のドライブとほぼ同じ速さで読み取り、最も遅いディスクの速度に限定されません。

/dev/md1:     4042 MB in  3.00 seconds = 1346.67 MB/sec
/dev/nvme0n1: 4104 MB in  3.00 seconds = 1367.62 MB/sec
/dev/nvme1n1: 4030 MB in  3.00 seconds = 1342.93 MB/sec
/dev/xvdz:     668 MB in  3.01 seconds = 222.26 MB/sec

電源オフ/オンは低下したRAIDセットを返しますが、アプリの実行速度は遅くなりますが、それでも実行できます。 5〜10分間待機するコストは回避され、アプリを再起動せずに一時的なディスクをオンザフライでレイドに再追加できます。

それでそれは完全に機能しているように見えますが、私が見逃したり、考慮しなかったりしたことはありますか？

amazon-ec2software-raidamazon-ebsraid1amazon-ephemeral
7
Criggie

うーん、1つのRAID1で2つの非常に異なるボリュームを混在させるかどうかはわかりません。これを行うと、リクエストの半分が低速のEBSから提供され、半分が高速のインスタンスストレージから提供されるため、予測できないパフォーマンスが発生する可能性があります。より良いパフォーマンスを達成するために標準的なツールを検討します。

Provisioned IOPS EBSディスク（高いランダムアクセスIOが必要な場合）またはスループットが最適化されたEBS（大きなファイルを連続して読み取る場合）。彼らはあなたが箱から出して必要なパフォーマンスを提供するかもしれません。 価格はこちら 。

また、cachingも確認する必要があります。これは、言うようにほとんどが読み取り専用のコンテンツであるためです。ファイルが必要になるたびに、一時ストレージのローカルキャッシュディレクトリを調べ、そこにある場合はそこからサービスを提供できます。そうでない場合は、EBSから取得して、コピーをキャッシュに保存します。特に、それがすべて読み取り専用の場合、それは非常に単純なキャッシング層であるべきです。

または、EBS上のファイルがデータベースファイルである場合（おそらくそうであると思われます）クエリの結果をキャッシュまたは Memcacheで処理しますまたはRedis またはデータベースのネイティブキャッシュ（例 MySQL Query Cache ）。

それが役に立てば幸い:)

5
MLu

私は... --write-mostlyを使用しても、RAID1ボリュームを使用しません。セットの再構築中のパフォーマンスの低下は煩わしくなります。

代わりにを検討することをお勧めしますbcache です。 SSDにアクセスできるが、保存するデータが非常に多く（通常は非常に大規模なPostgreSQLデータベース）、すべてを購入するのは費用対効果が低い状況で非常に役立つことがわかりましたSSD。私は「永続的」モードでのみ使用しました。SSDをライトバックキャッシュとして使用しますが、キャッシュストレージレイヤーが一時的なものとして扱われ、書き込みが完了するまで書き込みが完了したと見なされないモードがあります。基礎となる永久ストレージ。

1
womble

40GBは、RAMディスクに十分なサイズです。これは、スクラッチディスクよりも高速になります。アプリはどれくらいの時間実行されますか。また、より大きなメモリ割り当てのインスタンスに支払う価値はありますか？

24時間365日はコストがかかりすぎる可能性があります。しかし、40GBは手の届く範囲にあります。

ボーナスとして、より多くのコアを楽しむ必要があります。

確定的クエリのクエリキャッシュに同意します。どのような種類のバッファリングも時間の経過とともに役立ちます。

1
mckenzm