EBS-Volume automatisch an eine neue Spot-Instanz anhängen?

Ich experimentiere mit EC2-Spot-Instanzen und benötige einige Daten, die zwischen den Terminationen gespeichert werden müssen. So wie ich es jetzt verstehe, wenn der aktuelle Preis über meinem max. Gebot, es wird automatisch beendet. Ich gehe davon aus, dass alle Init-Skripte, die ich habe, beim Herunterfahren ausgeführt werden, damit ich die Daten vor dem Abmelden an das EBS übertragen kann.

Meine Frage ist, wie kann ich dasselbe EBS-Volume automatisch auf der neuen Spot-Instanz bereitstellen, sobald der Preis sinkt, da dort keine meiner Init-Skripte vorhanden sind, die ich beim ersten Mal auf das Root-Volume geladen hätte?

Muss ich ein benutzerdefiniertes AMI erstellen oder gibt es eine andere Möglichkeit, dies zu erreichen?

Wenn Sie möchten, dass die Instanz bei jeder Ausführung mit einem festen Startpunkt gestartet wird, können Sie Folgendes tun:

1. Erstellen Sie Ihr eigenes AMI und führen Sie dieses jedes Mal als Instanz aus

2. Geben Sie ein Benutzerdatenskript an, das die Software bei jedem Start einer neuen Instanz von einem Standard-Basis-AMI nach Ihren Vorgaben installiert und konfiguriert.

Wenn Sie den Status zwischen den Instanzen beibehalten möchten, müssen Sie die Daten außerhalb der Instanz / AMI speichern. Beispielsweise:

1. Die Daten können auf S3, SimpleDB, DynamoDB, RDS usw. auf dem neuesten Stand gehalten werden.

2. Sie können ein permanentes EBS-Volume festlegen, das die Instanz beim Start dynamisch anfügt und einbindet. Dies könnte mit einem Benutzerdatenskript erfolgen.

Sehen Sie sich das ec2-spotter-Projekt auf GitHub an. Es wurde erstellt, um das von Ihnen beschriebene Problem zu lösen.

Die in der Antwort von @ mcenzm beschriebenen Probleme (Nr. 1 bis Nr. 4) sind real und werden in ec2-spotter korrekt behandelt.

Ich habe dies schon eine Weile versucht und es gibt immer noch eine Reihe von Problemen mit EC2-Spot-Instanzen und angeschlossenem Speicher.

1. Das Volume, das Sie anhängen möchten, befindet sich möglicherweise nicht in derselben Zone wie die Instanz. Beim Start können keine Zonen angegeben werden.
2. Das interne Anhängen mit dem Init-Skript funktioniert, ist jedoch etwas asynchron, sodass Sie es testen oder sleep 10sagen müssen.

3. Ich kann nicht verstehen, warum die AWS-Konsole eine "Partition" als primäres Blockgerät anzeigt. Vielleicht, um uns zu verweigern, Windows-Images auf einer anderen Partition zu raubkopieren? (sda1 statt sda). Viel Glück beim Auffinden der Partitionstabelle.

   

4. Derzeit ist es schwierig, über die CLI von einem externen Kontrollpunkt aus eine Verbindung herzustellen, was die Verwendung von Snapshots für die Versionierung erschwert.

5. Im Allgemeinen sichere ich also ... tar.bz2 auf einer anderen Box und kann dann beim Start den "Arbeitsbereich" füllen. Dies ist nur für kleine Datenmengen nützlich. Daher ist es eine gute Idee, einen neuen ami mit beiden Volumes zu vergleichen. Spot-Instanzen eignen sich sowieso sehr gut für "Work Unit" - oder "Restartable" -Arbeit, sodass das Konzept des Abrufens von Arbeit von einem Server gut etabliert ist. Wenn Sie im Extremfall 9 Minuten auf einen Start warten, kann es sein, dass Sie nichts dagegen haben, Ihre (möglichst kleine) Festplatte zu formatieren.

   6. EBS ist immer noch ziemlich flockig und Sie müssen für "optimiert" extra bezahlen. Es ist immer noch schneller, als zu versuchen, Ihre abgeschlossene Arbeit in etwa 90s hochzuladen, wenn die Instanz "ausgepreist" ist.

   7. Ich vermute, dass sich dies mit jedem Angebot für "elastische Dateien" ändern wird.

Mögliche Lösung zum Starten von EC2 Spot Instance mit EBS. Beenden Sie EC2 Instance dann, wenn Sie es nicht benötigen, und starten Sie es dann erneut, da die neue Funktion EBS erneut angehängt wird.

https://aws.amazon.com/about-aws/whats-new/2020/01/amazon-ec2-spot-instances-stopped-started-similar-to-on-demand-instances/