Vor rund einem Jahr startete ich das Experiment Amazon …
Satte 46 US-Dollar, also irgendwas bei 37 Euro aktuell, veranschlagt Amazon für eine (zu lahme) 20 GB-MySQL (ohne Redundanz: Single AZ) sowie eine minimalistische Linux-Instanz. Die Antwort auf die Frage, ob ich das in AWS weiterhin laufen lassen will? »Ich denke nicht, Tim.«.
Was also tun? So ein WordPress-Blog ist eigentlich schnell aufgesetzt, aber irgendwie … wir haben hier eine VM, und das Ziel wird ebenfalls eine VM sein (deren CPU dann 5000 statt 3600 BogoMIPS aufweist). Warum also nicht das AWS-VM-Image nehmen und in eine KVM-Instanz wandeln?
Dazu gibt es einige Blogbeiträge; was ich effektiv allerdings gemacht habe, ist etwas anderes: ich habe einen neuen Storage für die Ziel-VM definiert, diesen in Root und Swap aufgeteilt:
root@willikins:~# fdisk -l /dev/VM-Storage/aws-blogdoch
Disk /dev/VM-Storage/aws-blogdoch: 17.2 GB, 17179869184 bytes
255 heads, 63 sectors/track, 2088 cylinders, total 33554432 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/VM-Storage/aws-blogdoch1 * 2048 31459327 15728640 83 Linux
/dev/VM-Storage/aws-blogdoch2 31459328 33554431 1047552 82 Linux swap / Solaris
Dann ein ext4-FS anlegen:
root@willikins:~# kpartx -av /dev/VM-Storage/aws-blogdoch add map VM--Storage-aws--blogdoch1 (252:4): 0 31457280 linear /dev/VM-Storage/aws-blogdoch 2048 add map VM--Storage-aws--blogdoch2 (252:5): 0 2095104 linear /dev/VM-Storage/aws-blogdoch 31459328 root@willikins:~# mkfs.ext4 -L aws-blogdoch /dev/mapper/VM--Storage-aws--blogdoch1
Dieses ›anmontieren‹ (vulgo ›mounten‹) und auf einen tar-Datenstrom aus der Wolke via nc warten:
root@willikins:~# mount /dev/mapper/VM--Storage-aws--blogdoch1 /mnt root@willikins:~# nc -l -p 8888 -q 2 | (cd /mnt ; tar --sparse -x -v -f - --atime-preserve --numeric-owner --preserve)
Dann, auf der AWS-Instanz:
root@ip-172-31-46-203:~# tar --sparse -c -f - --atime-preserve --exclude=dev --exclude=run --exclude=sys --exclude=proc --numeric-owner --exclude=swap.file --preserve * | nc willikins.uu.org 8888
Kurzer Abstecher zum lokalen Weihnachstmarkt, denn ca. 6 GB dauern aus der Wolke auch bei 100 MBit/sec-Zugang.
Wenn dann die Daten drüben sind, müssen noch ein paar Details angepaßt werden:
- Ein neues root-PW möchte man ggf. setzen (chroot /mnt ; passwd), auch vielleicht in [/mnt]/root/.ssh/authorized_keys SSH-Schlüssel hinterlegen.
- Das Root-FS liegt nicht mehr auf /dev/xvda1 sondern (hier) auf /dev/vda1 => [/mnt]/etc/fstab und auch [/mnt]/boot/grub/grub.cfg anpassen.
- Überhaupt, grub. Das war die größte Baustelle, das Anpassen hat irgendwie nie wirklich funktioniert, sodaß ich letztlich per (jessie-) Recovery-Boot /boot/grub komplett weggeworfen habe, per »apt-get purge« grub2 und grub-pc gelöscht und dann neu installiert habe. Dann endlich bootete die VM.
- Der Kernel ist nach wie vor der auch in AWS benutzte Kernel von Debian-Jessie, 3.11-2-amd64.
Abschließend auf der AWS-Instanz, die KVM-Instanz ist up und im DNS hinterlegt:
root@ip-172-31-46-203:~# /etc/init.d/apache2 stop root@ip-172-31-46-203:~# rsync --sparse -av --progress --perms --acls --owner --group --devices --specials --times --numeric-ids /var/log/apa* kvm.blogdoch.net:/var/log/
Und dann auf der KVM-Instanz:
root@kvm:~# /etc/init.d/apache2 start
Nach der Umstellung des DNS läuft blogdoch.net nun wieder auf meiner Kiste in einem RZ; allerdings in einer separaten VM, die ich nun nach Bedarf sizen oder zwischen den Hypervisoren verschieben kann. Und kurz vor Ende der Testperiode kann ich die AWS-Instanz zurückgeben (ebenso die EIP und die RDS-Instanz):
root@ip-172-31-46-203:~# uptime ; shutdown -h now ; exit 22:26:53 up 364 days, 3:19, 2 users, load average: 0.00, 0.01, 0.05 The system is going down for system halt NOW!(pts/0) (Sun Dec 7 22:26:53 201 logout Connection to aws.blogdoch.net closed.
Thank you, AWS, for the experience — but for my use case, you’re too expensive.