Migration von AWS t1 zu t2: Client.InstanceInitiatedShutdown für neue t2-Instanz

Ich habe seit ein paar Jahren ein Linux t1.micro, auf dem eine kleine Apache / PHP / Postgresql-Website ausgeführt wird (hier als "Originalinstanz" bezeichnet). Klappt wunderbar.

Ich wollte die Site auf die neue (billigere) t2.micro-Instanz migrieren. Ich kann nicht Schritt für Schritt Anleitung zum finden , wie dies zu tun, aber nahm Kenntnis von dieser und dies .

Mein grundlegender Ansatz war

Erstellen Sie Snapshots der beiden Volumes (Root und Datenlaufwerk für die Postgresql-Daten), die von der ursprünglichen Instanz verwendet werden
Erstellen Sie eine neue HVM-AMI aus den gerade aufgenommenen Root- und Daten-Snapshots (ELASTIC BLOCK STORE> Snapshots> Root-Snaphot der Originalinstanz auswählen> Aktionen> Image erstellen) mit
- Architektur = x86_64, wie die ursprüngliche Instanz
- Gerätenamen des Root-Geräts und des Datenvolumes = identisch mit der ursprünglichen Instanz
- Virtualisierungstyp = Hardwareunterstützte Virtualisierung (HVM, zur Kompatibilität mit dem neuen t2 VM-Format)
- Kernel ID = "Standard verwenden" (Ich habe versucht, dieselbe Kernel-ID wie die ursprüngliche Instanz zu verwenden, aber die AMI-Erstellung ist fehlgeschlagen, da dies für eine HVM-AMI nicht verwendet werden konnte.)
Erstellen und starten Sie eine neue Instanz mit dem AMI, das gerade in Schritt 2 erstellt wurde

Problem: Beim Starten dieser neuen Instanz wird sie sofort mit einem Client.InstanceInitiatedShutdownFehler heruntergefahren . Wie kann ich das beheben?

Bin ich naiv zu glauben, dass ich einen Root-Snapshot verwenden kann, der in einer PVM-Umgebung in einer HVM-Umgebung funktioniert? Gibt es eine einfachere Möglichkeit, von t1 nach t2 zu migrieren?

Ich hoffe, dass ich meinen Server in t2 nicht von Grund auf neu erstellen und Daten manuell migrieren muss (ich habe keine automatisierten Build-Skripte verwendet).

Bearbeiten : Am Ende habe ich die t2-Instanz von Grund auf neu erstellt: P.

amazon-web-services amazon-ami

— vornehmsten
quelle

Ich hatte kürzlich ein sehr ähnliches Problem, aber es war mit Datenträgertypen anstelle von Instanzfamilien. Ich habe versucht, eine neue Instanz mit den neuen SSD-Volumes vom Typ "gp2" aus den AWS Powershell-Dienstprogrammen zu erstellen. Die Instanz wird erstellt und sofort mit einem InstanceInitiatedShutdown beendet. Ich konnte das Problem schließlich lösen, indem ich ein "gp2" -Volume explizit definierte und es '/dev/sda1'in einer Blockgerätezuordnung auf den Gerätenamen setzte. Möglicherweise müssen Sie Ihr Root-Volume ebenfalls untersuchen und ändern.

— Anthony Neace

Danke @HyperAnthony. Ich bin mir nicht sicher, ob ich die Fähigkeiten dafür habe und mehr Schaden als Nutzen anrichten kann. : PI fand dies jedoch "Es gibt keine einfache Möglichkeit, den Vitalisierungstyp von PV auf HVM zu ändern ... Ihre beste Lösung wäre, eine neue Instanz hochzufahren und Ihre Daten zu migrieren."

— vornehmster

Siehe auch stackoverflow.com/questions/26676933/…

— Deckel

Ich wechselte von HVM zu PV und bemerkte das gleiche Problem. Es stellte sich heraus, dass ich (meine Automatisierung) immer noch Blockspeicher an / dev / sda1 anhängte, was ich für mein HVM-AMI benötigte, aber an / dev / xvda anhängen musste.

— George IV
quelle

Für mich passiert dasselbe auf einem LC. Aus irgendeinem Grund stimmt AWS Mount nicht mit AMI überein, wenn es den LC validiert.

— Einarc