it-swarm.com.de

Mounten einer NVME-Diskette in AWS EC2

Also habe ich i3.large mit NVME-Datenträger auf jedem Knoten erstellt. Hier war mein Prozess:

  1. lsblk -> nvme0n1 (prüfen, ob nvme noch nicht eingehängt ist)
  2. Sudo mkfs.ext4 -E nodiscard/dev/nvme0n1
  3. Sudo-Mount -o Discard/dev/nvme0n1/mnt/meine-Daten
  4. / dev/nvme0n1/mnt/my-data ext4 Standardwerte, nofail, verwerfen 0 2
  5. Sudo-Mount -a (überprüfen, ob alles in Ordnung ist)
  6. Sudo Neustart

Damit das alles funktioniert, kann ich mich wieder mit der Instanz verbinden. Ich habe 500 Go auf meiner neuen Partition.

Nachdem ich die EC2-Maschinen gestoppt und erneut gestartet habe, waren einige von ihnen zufällig nicht mehr erreichbar (AWS-Warnung nur 1/2 Teststatus geprüft).

Wenn ich mir die Protokolle anschaue, warum es nicht erreichbar ist, wird mir gesagt, es geht um die nvme-Partition.

Ich habe die AWS-Protokolle nicht genau, aber ich habe ein paar Zeilen davon:

Ungültige magische Zahl im Superblock beim Öffnen

dann ist der Superblock beschädigt und Sie können versuchen, e2fsck mit einem alternativen Superblock auszuführen:

/ dev/fd/9: Zeile 2: Plymouth: Befehl nicht gefunden

14
tricky

Das Stoppen und Starten einer Instanz löscht die kurzlebigen Datenträger, verschiebt die Instanz auf neue Host-Hardware und gibt Ihnen neue leere Datenträger ... sodass die kurzlebigen Datenträger nach dem Stoppen/Starten immer leer sind. Wenn eine Instanz gestoppt wird, ist sie auf keinem physischen Host vorhanden - die Ressourcen werden freigegeben.

Wenn Sie also Instanzen stoppen und starten möchten, sollten Sie sie nicht zu /etc/fstab Hinzufügen, sondern sie nur beim ersten Start formatieren und anschließend bereitstellen. Eine Möglichkeit zu testen, ob ein Dateisystem bereits vorhanden ist, ist die Verwendung des Dienstprogramms file und der Ausgabe von grep. Wenn grep keine Übereinstimmung findet, wird false zurückgegeben.

Die NVMe-SSD in der i3-Instanzklasse ist ein Beispiel für ein Instance Store Volume , das auch als Ephemeral [Disk | Lautstärke | Laufwerk]. Sie befinden sich physisch in der Instanz und sind extrem schnell, aber nicht redundant und nicht für persistente Daten vorgesehen ... daher "kurzlebig". Persistente Daten müssen sich auf einem Elastic Block Store (EBS) -Datenträger oder einem Elastic File System (EFS) befinden. Beide überleben das Stoppen/Starten der Instanz, Hardwarefehler und Instandhaltung.

Es ist nicht klar, warum Ihre Instanzen nicht booten können, aber nofail tut möglicherweise nicht das, was Sie erwarten, wenn ein Volume vorhanden ist, aber kein Dateisystem vorhanden ist. Mein Eindruck war, dass es irgendwann gelingen sollte.

Möglicherweise müssen Sie jedoch apt-get install linux-aws eingeben, wenn Sie Ubuntu 16.04 ausführen. Ubuntu 14.04 NVMe-Unterstützung ist nicht wirklich stabil und nicht empfohlen .

Jede dieser drei Speicherlösungen hat ihre Vor- und Nachteile.

Der Instance Store ist lokal, also ziemlich schnell ... aber kurzlebig. Es übersteht harte und weiche Neustarts, jedoch keine Stopp-/Startzyklen. Wenn Ihre Instanz einen Hardwarefehler erleidet oder vor dem Stillstand steht, wie dies eventuell für die gesamte Hardware der Fall ist, müssen Sie die Instanz anhalten und starten, um sie auf neue Hardware zu verschieben. Reservierte und dedizierte Instanzen ändern das temporäre Festplattenverhalten nicht.

EBS ist ein permanenter, redundanter Speicher, der von einer Instanz getrennt und in eine andere verschoben werden kann (und dies geschieht automatisch bei einem Stopp/Start). EBS unterstützt Point-in-Time-Snapshots, die auf Blockebene inkrementell sind. Sie müssen also nicht für das Speichern der Daten zahlen, die sich zwischen den Snapshots nicht geändert haben um den Überblick über "vollständige" und "inkrementelle" Snapshots zu behalten - Die Snapshots sind nur logische Container mit Zeigern auf die gesicherten Datenblöcke. Sie sind also im Wesentlichen alle "vollständigen" Snapshots, werden jedoch nur als inkrementelle Snapshots abgerechnet. Wenn Sie einen Snapshot löschen, werden nur die Blöcke, die zum Wiederherstellen des Snapshots und aller anderen Snapshots nicht mehr benötigt werden, aus dem Back-End-Speichersystem gelöscht (das für Sie transparent ist und tatsächlich Amazon S3 verwendet).

EBS-Volumes sind sowohl als SSD- als auch als Spinning-Platter-Magnet-Volumes erhältlich, wiederum mit Kompromissen bei Kosten, Leistung und geeigneten Anwendungen. Siehe EBS-Volume-Typen . EBS-Volumes ahmen normale Festplatten nach, mit der Ausnahme, dass ihre Kapazität bei Bedarf manuell erhöht (aber nicht verringert) und von einem Volume-Typ zu einem anderen konvertiert werden kann, ohne das System herunterzufahren. EBS führt die gesamte Datenmigration im laufenden Betrieb durch, wobei die Leistung verringert wird, jedoch keine Unterbrechungen auftreten. Dies ist eine relativ neue Innovation.

EFS verwendet NFS, sodass Sie ein EFS-Dateisystem auf beliebig vielen Instanzen bereitstellen können, auch über Verfügbarkeitszonen innerhalb einer Region hinweg. Die Größenbeschränkung für eine Datei in EFS beträgt 52 Terabyte, und Ihre Instanz meldet tatsächlich 8 Exabyte freien Speicherplatz. Der tatsächliche freie Speicherplatz ist für alle praktischen Zwecke unbegrenzt, aber EFS ist auch der teuerste. Wenn Sie einen Monat lang eine 52-TiB-Datei dort gespeichert hätten, würde dieser Speicherplatz über 15.000 US-Dollar kosten. Das meiste, das ich jemals gespeichert habe, war ungefähr 20 TiB für 2 Wochen, kostete mich ungefähr 5.000 USD, aber wenn Sie den Platz brauchen, ist der Platz da. Es wird stündlich abgerechnet. Wenn Sie die 52-TiB-Datei also nur ein paar Stunden lang gespeichert und dann gelöscht haben, zahlen Sie möglicherweise 50 US-Dollar. Das "Elastic" in EFS bezieht sich auf die Kapazität und den Preis. Sie stellen keinen Speicherplatz für EFS bereit. Sie verwenden, was Sie benötigen, und löschen, was Sie nicht benötigen. Die Abrechnungsgröße wird stündlich berechnet.

Eine Diskussion über die Speicherung wäre ohne S3 nicht vollständig. Es ist kein Dateisystem, es ist ein Objektspeicher. Bei ungefähr 1/10 des Preises von EFS hat S3 auch eine praktisch unendliche Kapazität und eine maximale Objektgröße von 5 TB. Einige Anwendungen sollten besser mit S3-Objekten anstelle von Dateien erstellt werden.

S3 kann auch problemlos von Systemen außerhalb von AWS verwendet werden, sei es in Ihrem Rechenzentrum oder in einer anderen Cloud. Die anderen Speichertechnologien sind für die Verwendung in EC2 vorgesehen, obwohl es eine ndokumentierte Problemumgehung gibt, mit der EFS extern oder über Regionen hinweg mit Proxys und Tunneln verwendet werden kann.

14

Sie finden nützliche neue EC2-Instanzfamilien, die mit lokalem NVMe-Speicher ausgestattet sind: C5d.

Siehe den Blogeintrag der Ankündigung: https://aws.Amazon.com/blogs/aws/ec2-instance-update-c5-instances-with-local-nvme-storage-c5d/

 enter image description here

Einige Auszüge aus dem Blogbeitrag:

  • Sie müssen keine Blockgerätzuordnung in Ihrem AMI oder während des Instanzstarts angeben. Der lokale Speicher wird nach dem Booten des Gastbetriebssystems als ein oder mehrere Geräte (/ dev/nvme * 1 unter Linux) angezeigt.
  • Abgesehen von dem Hinzufügen von lokalem Speicher haben C5 und C5d dieselben Spezifikationen. 
  • Sie können jedes AMI verwenden, das Treiber für den Elastic Network Adapter (ENA) und NVMe enthält
  • Jedes lokale NVMe-Gerät wird mit der XTS-AES-256-Blockverschlüsselung und einem eindeutigen Schlüssel hardware-verschlüsselt. 
  • Lokale NVMe-Geräte haben die gleiche Lebensdauer wie die Instanz, an die sie angeschlossen sind, und bleiben nach dem Stoppen oder Beenden der Instanz nicht erhalten.
1
Vlad Holubiev

Ich hatte gerade eine ähnliche Erfahrung! Meine C5.xlarge-Instanz erkennt ein EBS als nvme1n1. Ich habe diese Zeile in fstab hinzugefügt. 

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

Nach ein paar Neustarts sah es gut aus. Es lief wochenlang weiter. Aber heute habe ich gerade erfahren, dass die Instanz nicht verbunden werden konnte. Ich habe einen Neustart von der AWS-Konsole aus versucht, kein Glück sieht aus, der Schuldige ist der Fstab. Die Festplattenmontage ist fehlgeschlagen. 

Ich habe das Ticket zum AWS-Support erhoben, noch keine Rückmeldung. Ich muss eine neue Instanz starten, um meinen Dienst wiederherzustellen. 

In einer anderen Testinstanz versuche ich, UUID (get by command blkid) anstelle von/dev/nvme1n1 zu verwenden. Bis jetzt sieht es immer noch aus ... werde sehen, ob es Probleme gibt.

Ich werde hier aktualisieren, wenn AWS-Support-Feedback vorliegt. 

================= BEARBEITEN mit meinem Fix ===========

AWS gibt mir noch kein Feedback, aber ich habe das Problem gefunden. In fstab ist es egal, was Sie/dev/nvme1n1 oder UUID mounten. Mein Problem ist, dass mein ESB einige Fehler im Dateisystem hat. Ich habe es an eine Instanz angehängt und dann ausgeführt 

fsck.ext4 /dev/nvme1n1

Nachdem ein paar Dateisystemfehler behoben wurden, legen Sie ihn in fstab ein, starten Sie ihn neu, kein Problem mehr!

0
user1619801