Amazon AWS Ephemeral Disks und RAID1

An einige AWS-Instanzen sind "kurzlebige Datenträger" angeschlossen, die viel schneller als EBS sind. Vergängliche Datenträger sind jedoch leer und nicht initialisiert, wenn Ihre Instanz gestoppt und gestartet wird. Die Daten auf der Festplatte überleben jedoch im Allgemeinen einen Neustart der Instanz.

Frage : Sollte ich auf meiner AWS-Instanz ein Software-RAID1 verwenden, das über eine kurzlebige Festplatte und ein EBS-Volume erstellt wurde?

Ich denke, dass raid1 nur mit dem EBS-Volume im herabgesetzten Modus angezeigt wird, und dann können wir mdadm-Befehle verwenden, um die leere kurzlebige Festplatte wieder in den raid aufzunehmen. Dadurch kann die App 5-10 Minuten früher gestartet werden, was zu einer schlechteren Leistung führt, während raid1 synchronisiert wird.

Hintergrund : Ich habe eine App, die ~ 40 GB Datendateien verwendet. Die Zugriffszeiten hängen direkt von der Leistung ab. Je schneller die Festplatte, desto schneller die App.

In der Vergangenheit haben wir etwas von rc.local bis rsync-Daten von einer EBS-Festplatte auf die kurzlebige Festplatte ausgeführt und dann die Software gestartet. Die Synchronisierung dauert 5-10 Minuten, besser als die 5-20 Minuten, die für die Synchronisierung von einer anderen Instanz benötigt wurden. In der Vergangenheit haben wir sogar die Datendateien von einer Ramdisk verwendet, die nicht so schnell war wie die kurzlebigen Festplatten.

Weitere Informationen - Dies ist ein i3.4xlarge mit zwei kurzlebigen NVME-Laufwerken.

# 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

Ich habe einen raid1 mit erstellt

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

was zurückgibt:

$ 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

Seltsamerweise liest sich der Raid ungefähr so ​​schnell wie die schnelleren Laufwerke und ist nicht auf die Geschwindigkeit der langsamsten Festplatte beschränkt.

/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

Ein Aus- / Einschalten gibt ein verschlechtertes Raidset zurück, aber die App kann immer noch ausgeführt werden, wenn auch langsamer. Die Kosten für das Warten von 5 bis 10 Minuten werden vermieden, und ich kann die kurzlebigen Festplatten ohne einen Neustart der App im laufenden Betrieb erneut zum Raid hinzufügen.

Gibt es etwas, das ich verpasst oder nicht berücksichtigt habe, obwohl es perfekt zu funktionieren scheint?

Hmm, ich bin mir nicht sicher, ob ich zwei so unterschiedliche Volumes in einem einzigen RAID1 mischen möchte. Wenn Sie dies tun, werden die Hälfte Ihrer Anforderungen vom langsameren EBS und die Hälfte vom schnelleren Instanzspeicher bedient, was zu einer unvorhersehbaren Leistung führen kann. Ich würde mir Standardwerkzeuge ansehen, um eine bessere Leistung zu erzielen.

Sehen Sie sich die bereitgestellten IOPS-EBS- Festplatten (wenn Sie E / A mit hohem Direktzugriff benötigen) oder die durchsatzoptimierten EBS (wenn Sie nacheinander große Dateien lesen) an. Sie bieten möglicherweise die Leistung, die Sie sofort benötigen. Die Preise finden Sie hier .

Sie sollten sich auch das Caching ansehen , zumal es sich, wie Sie sagen, hauptsächlich um schreibgeschützte Inhalte handelt. Jedes Mal, wenn die Datei benötigt wird, können Sie im lokalen Cache-Verzeichnis des kurzlebigen Speichers nachsehen und sie von dort aus bereitstellen. Wenn nicht, nehmen Sie es von EBS und speichern Sie eine Kopie im Cache. Besonders wenn alles schreibgeschützt ist, sollte es eine recht einfache Caching-Ebene sein.

Oder wenn es sich bei den Dateien in EBS um Datenbankdateien handelt (von denen ich vermute, dass dies der Fall ist), werden die Ergebnisse Ihrer Abfragen oder Verarbeitungen in Memcache oder Redis oder im nativen Datenbankcache (z. B. MySQL Query Cache ) zwischengespeichert.

Ich hoffe, das hilft :)

40 GB sind klein genug für RAM-Disks, die schneller sind als Scratch-Disks. Wie lange läuft Ihre App und lohnt es sich, für eine Instanz mit größerer Speicherzuweisung zu bezahlen?

24x7 kann zu teuer sein. Aber 40 GB sind in Reichweite.

Als Bonus sollten Sie mehr Kerne genießen.

Ich stimme dem Query Caching für deterministische Abfragen zu, und jede Art von Pufferung wird im Laufe der Zeit hilfreich sein.

Ich ... würde kein RAID1-Volume verwenden, auch nicht mit --write-mostly. Der Leistungsabfall während der Neuerstellung des Sets wird ärgerlich.

Was ich stattdessen empfehlen würde , ist bcache . Ich habe festgestellt, dass es in Situationen sehr nützlich ist, in denen ich Zugriff auf SSDs habe, aber auch eine sehr große Datenmenge speichern muss (normalerweise sehr große PostgreSQL-Datenbanken), für die es nicht kostengünstig ist, alle zu kaufen SSDs. Ich habe es nur im "persistenten" Modus verwendet, in dem die SSDs als Rückschreibcache verwendet werden, aber es gibt einen Modus, in dem die Cache-Speicherebene als kurzlebig behandelt wird und keine Schreibvorgänge als abgeschlossen betrachtet werden, bis sie abgeschlossen sind auf dem zugrunde liegenden permanenten Speicher.