Entwölkt

Vor rund einem Jahr startete ich das Experiment Amazon …

Screenshot

USD 46 für ein WP-Blog im Monat? Danke, Amazon, aber nein, danke …

… und heute beende ich es. Ganz unproblematisch war der Abstecher in den »Free Usage Tier« von Amazons Web Services ja schon Anfang des Jahres nicht. Aktuell läuft das kostenlose Jahr aus und wenn mir eines klar geworden ist in diesem Jahr: AWS ist nicht für 24/7-Dienste gedacht.

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.«.

Screenshot

Time to say good-bye …

Die MySQL-Instanz nutze ich schon seit Anfang diesen Jahres nicht mehr, weil sie einfach selbst für mein kleines Blog nicht performant genug war. Aber auch ohne jene wären’s noch immer 18 USD/Monat für die Instanz mit rd. 600 MB RAM, 15 GB HDD und einem(?) E5-2650-Kern »@ 2.00GHz« (1800 MHz lt. /proc/cpuinfo).

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.

FTR: die MySQL läuft seit rd. drei Wochen ebenfalls virtualisiert, derzeit befinden sich beide VMs auf den gleichen Hypervisor (8 Kerne, 16 GB RAM), das wird sich über die Zeit noch ändern. Geplant ist eine ›Datenbank-VM‹, die dann entsprechend mit virtuellen Ressourcen bestückt wird.