8 Cores, 32GB RAM und 2x3TB Storage?!? Shiny!

p(abstract). Mein alter Hetzner-Server war ja schon relativ saftig ausgestattet. Gegen eine vollständige Virtualisierung aller Services sprach eigentlich immer nur Hauptspeicher. Dann hat Hetzner das Special EQ4 S um Ostern raus gebracht. Das hier ist kein _Howto_ sondern nur ein genereller überblick über mein Setup des Servers. Vielleicht zieht ja jemand ein paar Ideen raus, wenn er vergleichbare Überlegungen für seine eigene Umgebung anstellt.

h2. Die Altumgebung

Hetzner hat sich ohnehin schon immer mit IP-Adressen schwer getan. Beim alten Server hatte ich noch 3 zusätzliche Adressen erworben, um die diversen VMs adressierbar zu machen.

* Host
* Webserver
* Mailserver
* Frei für Tests, Migrationen, etc.

Mich hat dabei eigentlich immer gestört, dass wg. des Mangels an Adressen alle Webauftritte auf einem einzelnen Server laufen mussten. Apache bietet mit NameBased VirtualHosts zwar eine Möglichkeit, eine Vielzahl von Auftritten auf einer einzelnen Adresse zu betreiben, aber alle diese Auftritte laufen immer noch auf derselben (virtuellen) Maschine.

Diesmal habe ich beim Aufbau eine andere Strategie gewählt.

h2. Der Neue

h3. OS

Die Kerndaten von „behemoth“ stehen im Titel dieses Posts.

Die Grundinstallation des Servers ist eine ordinäre „Ubuntu 12.4 Precise Server Minimal“ Installation.  Das bietet sich insbesondere deshalb an, weil die 12.4 wieder mal eine LTS-Release ist, also 4 Jahre supported.  

h3. Virtualisierung

Als Virtualisierung habe ich eigentlich alles durch.  Xen war mit seiner Dom-0-Scheisse immer ein paar Kernel-Releases hinterher. Ob das noch immer so ist, kann ich nicht sagen, die Erinnerung an das Theater hat mich aber bewogen, Xen nicht erneut zu betrachten.  kvm ist mir entschieden zu minimalistisch. VMWare Server war mit dem Schritt auf Version 2.0 nicht mehr zu gebrauchen. Blieb also nur VirtualBox.  Das stinkt zwar auf dem Arbeitsplatz gegen VMWare Workstation massiv ab, ist aber auf dem Server super, u.A. wg. des möglichen Headless-Betriebs.

Darauf laufen derzeit folgende VMs:

* Primary Webserver (Apache, PHP, WordPress, Dokuwiki, Zen-Photo)
* Monitoringserver (Icinga)
* Projektserver (Trac)
* MySQL-Datenbankserver
* Mailserver (Postfix, Dovecot, DSPAM)
* Eine Backup-Maschine zum Off-Site-Backup eines befreundeten Servers
* Eine Template-VM, aus der neue VMs geklont werden können (Ubuntu-Precise Server minimal)

Für die VMs habe ich nur ein einzelnes hostonly-Netz aufgebaut an das alle VMs gehängt werden. Man könnte hier natürlich weitere Netze schaffen um eine Multi-Tier-Umgebung aufzubauen, aber da ich keine Bank betreibe, und meine Zeit auch für Spassprojekte begrenzt ist, habe ich davon mal abgesehen.

h3. Infrastrukturdienste auf dem Host

Folgende Services stellt „behemoth“ für die VMs sowie für deren Administration bereit.

* OpenVPN um direkten Zugriff auf das Hostonly-Netz der VMs zu bieten
* DNS für die VMs sowie an’s VPN angebundene Clients
* nginx als Reverse Proxy (siehe unten)
* SNAT und DNAT für die VMs

Alle VMs haben durch das SNAT Zugriff nach draußen, so dass aus dem Netz gezogene Updates kein Problem sind.

Der DNS bedient die Zone intern.lamertz.net sowie die Reverse-Lookups des Hostonly-Netzes (10.0.0.0/24) für alle VMs und die OpenVPN-Clients.

h3. Webserver

DNAT würde als Zugriffsmöglichkeit für den Webserver das NameBased-Problem nicht lösen. Statt dessen habe ich mich für nginx als Reverse-Proxy auf „behemoth“ entschieden. nginx ist klein, schnell, simpel konfiguriert und weit verbreitet. nginx holt den gewünschten Servernamen aus dem HTTP-Header und schiebt die Anfrage dann an die entsprechende VM weiter. Auf dem Haupt-Webserver läuft dabei weiterhin das ganze PHP-Geraffel, diverse Blogs von mir und Bekanten, das Wiki, etc. Auf dieser VM läuft Apache ebenfalls mit NameBased VirtualHost Setup. Zusätzlich gibt es weitere Server an die nginx abhängig vom angefragen Namen delegiert, wie z.B. ein Icinga-Host zum Monitoren der ganzen Kiste, aller VMs sowie einiger externer Server, und ein Trac Server mit dem ich meine Todos und die Knowledgebase verwalte (welcher mittelfristig vielleicht das Wiki ablösen wird aber im Moment eher den Status einer Spielwiese hat).

Das sieht Konfigurationstechnisch dann so aus, dass der nginx-Default-Server pauschal alles an den primären Webserver weiter leitet

behemoth:/etc/nginx/sites-enabled# cat default 
behemoth:/etc/nginx/sites-available$ cat -n default
     1  server {
     2          listen *:80 default;
     3          server_name _;
     4          location / {
     5                  proxy_set_header Host $host;
     6                  proxy_set_header X-Real-IP $remote_addr;
     7                  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     8                  proxy_pass http://www.intern.lamertz.net/;
     9          }
    10          access_log /var/log/nginx/access.log;
    11          error_log /var/log/nginx/error.log;
    12  
    13  }
behemoth:/etc/nginx/sites-available$ 

Anfragen die an gesonderte Webserver gehen, bekommen einfach eine weitere Konfiguration verpasst. Relevant sind hierbei die zu oben unterschiedlichen Zeilen 3 und 8:

behemoth:/etc/nginx/sites-available$ cat -n icinga.lamertz.net 
     1  server {
     2          listen *:80;
     3          server_name icinga.lamertz.net;
     4          location / {
     5                  proxy_set_header Host $host;
     6                  proxy_set_header X-Real-IP $remote_addr;
     7                  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
     8                  proxy_pass http://icinga.intern.lamertz.net/;
     9          }
    10          access_log /var/log/nginx/access.log;
    11          error_log /var/log/nginx/error.log;
    12  }
behemoth:/etc/nginx/sites-available$ 

h3. Mailserver

nginx ist zwar auch in der Lage, Proxy für SMTP und imap zu spielen, aber da ich dann das ganze SASL/TLS-Geraffel hätte neu bauen müssen, habe ich hier die Abkürzung gewählt und stattdessen eine DNAT-Regel eingerichtet, die die Ports 25, 143, etc umschreibt und an den Mailserver weiter leitet.

Hier läuft die übliche Kombination aus postfix, dovecot (der wirklich erheblich leichter konfigurierbar ist als Courier), zusätzlich postgrey und DSPAM um den üblichen Dreck soweit möglich vorzufiltern.

Alle VMs haben den Mailserver als Relay konfiguriert, so dass Statusmails von Cronjobs und dergleichen sauber raus gehen. Das 10.0.0.0/24er Netz ist für den Mailserver trusted.

h3. MySQL

Hierzu gibt es eigentlich nichts zu sagen, da ausschließlich MySQL läuft. Das Backup wird über Percona xtrabackup gemacht, mit dem ich beim aktuellen Seitenprojekt ausgezeichnete Erfahrungen gemacht habe.

h3. Icinga

Überwacht wird die ganze Umgebung sowie ein paar weitere Server außerhalb mit Icinga. So wie ich es derzeit betreibe, unterscheidet es sich quasi nicht von Nagios, daher gibt es hier auch nichts zu erklären. Das modernere Icinga-Web-Interface setze ich derzeit ebensowenig ein wie PNP zur erzeugung von lastkurven. Das Zeug dort sauber rein zu integrieren ist immer noch gefrickel und so wichtig war es dann bisher nicht.

h3. VM Template

Neben dem ganzen VM-Zoo gibt es noch eine VM, die als Template für Neuinstallationen dient. Hierbei handelt es sich um ein Minimalsystem mit kleineren Addons und einer Basiskonfiguration, das bei Bedarf dann zum Klonen eines neuen Servers heran gezogen wird.

Das hier ist das Basis-Setup für neue VMs.

behemoth:/virtualbox# cat -n clonevm 
     1  #!/bin/sh
     2
     3  set -x
     4  set -e
     5
     6  host=$1; shift 1
     7
     8  lvcreate -L vbox-$host -n10G vg0
     9  mkfs.xfs /dev/vg0/vbox-$host
    10  echo "/dev/vg0/vbox-$host /virtualbox/VMs/$host xfs defaults 0 0" >>/etc/fstab
    11  mkdir /virtualbox/VMs/$host
    12  mount -a
    13
    14  VBoxManage createvm --name "$host" --ostype Ubuntu_64 --register
    15  VBoxManage modifyvm "$host" --memory 1536
    16  VBoxManage modifyvm "$host" --cpus 1
    17
    18  VBoxManage modifyvm "$host" --nictype1 virtio
    19  VBoxManage modifyvm "$host" --nic1 hostonly
    20  VBoxManage modifyvm "$host" --hostonlyadapter1 vboxnet0
    21
    22  VBoxManage clonevdi VMs/precise/sda.vdi VMs/$host/sda.vdi
    23  VBoxManage storagectl "$host" --name "SATA Controller" --add sata --controller IntelAHCI
    24  VBoxManage storageattach "$host" --storagectl "SATA Controller" --port 0 --device 0 --type hdd --medium "VMs/$host/sda.vdi"
    25
    26  VBoxManage storagectl "$host" --name "IDE Controller" --add ide --controller PIIX4
    27  VBoxManage storageattach "$host" --storagectl "IDE Controller" --port 0 --device 0 --type dvddrive --medium emptydrive
    28  VBoxManage modifyvm "$host" --boot1 dvd
    29
    30  VBoxManage modifyvm "$host" --vrdeaddress 10.0.0.1
    31  VBoxManage modifyvm "$host" --vrdeport 3390
    32  VBoxManage modifyvm "$host" --vrde on
    33
    34  VBoxHeadless --startvm "$host"
    35  VBoxManage startvm "$host" --type headless
behemoth:/virtualbox# 

Nach dem Klonen müssen nur noch Hostname (/etc/hostname) und IP-Adresse (/etc/network/interfaces) angepasst, und /etc/udev/rules.d/70-persistent-net.rules gelöscht werden. Nach einem Reboot ist die neue VM einsatzfähig.

h3. Umzug auf den neuen Server

Nach der Grundeinrichtung des neuen servers konnten alle existierenden VMs vom Altserver einfach kopiert werden. Mehr als ein bisschen Schrauben an IP-Adresse, Routing und DNS-Konfiguration war nicht notwendig.

Die alten VMs haben natürlich einen veralteten Softwarestand, aber mit dem Klonen auf Knopfdruck ist jetzt eine bequeme Migration im Hintergrund möglich, ohne das Risiko einer unnötig langen Ausfallzeit, weil z.B. ein Upgrade nicht sauber durch läuft. Ist das neue System sauber aufgesetzt, werden die entsprechenden DNAT-Regeln oder die nginx-Konfiguration auf die neue VM verbogen und können im Fehlerfall auch problemlos wieder zurück gesetzt werden.

h3. Sonstiges

Password-Authentification ist abgeschaltet. Alle Server sind nur über Public-Key-Authentification erreichbar. Zwischen den Servern gibt es derzeit keine verteilten Keys.

Die Konsolen der VMs sind via rdesktop erreichbar. Der Zugriff ist auf das 10.0.0.0/24er Netz beschränkt, man kommt also nur über das VPN an die Konsolen.

Gesichert werden die VMs mit simplem cpio, abgezogen per SSH und abgelegt auf dem Hetzner Backup-Storage.

h3. Was fehlt?

Vermutlich muss ich mindestens 1 Adresse zusätzlich bestellen, um mir einen Cloud-Store mit Sparkleshare aufzusetzen. Eingang in Sparkleshare ist ssh, und der Port ist bereits für „behemoth“ belegt.

Natürlich kann die ssh für Sparkleshare auf einem anderen Port betrieben werden, aber ich bin noch unentschieden, ob mir das passt oder ob ich den EUR 1,00 für die zusätzliche Adresse ausgebe.

Dann sind auch die Platzprobleme von Dropbox Vergangenheit.

h3. Fazit

Die durch das neue Setup gewonnene Flexibilität macht einen Heidenspass. Keine Angst mehr, sich die laufende Umgebung durch Ausprobieren irgendwelcher verwursteter Software zu versauen. Einfach eine neue Maschine hochziehen und wenn’s nicht gefällt wieder eintonnen.

Migrationspfade haben sich massiv vereinfacht, da jetzt parallel und nicht länger unter Zeitdruck migriert werden kann.

Sollte irgendwann die nächste Servergeneration rufen, ist der Umzug der VMs auf eine neue Plattform trivial, das hat sich ja beim jetzt durchgeführten Umzug bereits bewährt.

Und das alles für gerade mal EUR 59,00 im Monat. Sehr unterhaltsam! 😀

5 Gedanken zu „8 Cores, 32GB RAM und 2x3TB Storage?!? Shiny!“

  1. Kannst du auch mal ein paar config files für das „Schrauben an IP-Adresse, Routing und DNS-Konfiguration“ dazu packen?
    Zum backupen kann ich auch noch duplicity empfehlen.

    1. Hey Lennart,

      naja, was man so macht, wenn man einen Server ohne Reinstall in ein neues Netz steckt.

      Neue IP-Adresse vergeben, neues Default-Gateway setzen, und den DNS auf die neuen Kisten (in dem Fall ja die Adresse von Primary-Host) zeigen lassen. Fertig.

      Ich habe mittlerweile auch auf duplicity umgestellt, und fuer die MySQL xtrabackup.

      Config-Files zu liefern macht nur bedingt Sinn, da das jede Distro ja anders macht. Bei meinen Debian-Based Ubuntu-Servern ist das /etc/network/interfaces. Bei RHEL/CentOS waere es /etc/sysconfig/network-scripts/ifcfg-ethXX, bei SuSE dasselbe nur woanders, und die sehen auch alle unterschiedlich aus.

      Da ich hier einen Umzug beschreibe und keine Neuinstallation, sollten die Files und ihre Syntax bekannt sein, denn das System muss ja initial mal aufgesetzt worden sein.

      Wenn Du was konkretes wissen willst, gib‘ Laut.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.