Wie im Juli angekündigt sind unsere Server umgezogen. Allerdings nicht mehr wie geplant in ein anderes Rechenzentrum. Um etwas weiter auszuholen: NetCologne war weiterhin bereit RackSpace zu sponsern. Uns ist beim Vorbereiten des Umzugs aber nochmal klarer geworden, was wir schon länger befürchtet haben: Hardware Betreuung kostet Zeit – und das nicht gerade wenig. Da kommen schnell Aufwände für Reisen auf, wenn man nicht „mal eben“ um die Ecke beim Rechenzentrum wohnt.
Wir haben uns darum auf die Suche nach Sponsoren gemacht und sind bei unseren bereits vorhanden fündig geworden. Seitdem laufen alle Dienste rund um ubuntuusers.de nicht mehr auf eigener „physischer“ Hardware, sondern in virtuellen Maschinen (VMs). Damit sind wir bisher zufriedener als je zuvor. Die Server aus der Spendenaktion 2012 gingen damit in ihren wohl verdienten Ruhestand.
Zwei VMs in Bamberg bei centron¶
 |
| Willkommensbildschirm bei centron |
Statt der Server-Colocation in Bamberg, sponsert uns centron nun zwei VMs. Die initiale Einrichtung geht gegenüber dem Einbau von Hardware simpel: Über das Webinterface kann man sich bei centron selbst eine VM erstellen. Dabei ist frei wählbar, wie viele CPU-Kerne, RAM und Storage die VM haben soll. Als Betriebssystem wählt man natürlich Ubuntu. Nach einer kurzen Wartezeit ist die VM dann aufgesetzt und per öffentlicher IP erreichbar. Fast Fertig.
 |
| Seite, um eine VM bei centron zu erstellen |
Daneben hat man in der Weboberfläche noch mehr Möglichkeiten:
Man kann kostenfreie VM-Snapshots erstellen.
Per Webkonsole auf eine VM schauen. (Falls man sein Netzwerkkonfiguration mal wieder verbastelt hat und ausbessern muss…)
Der Bootloader hat standardmäßig eine Wartezeit von 30 Sekunden. Das ist gerade mit Webkonsole sinnvoll, um z.B. einen alten Kernel auswählen zu können.
Nach dem Setup ist direkt ein öffentlicher SSH-key hinterlegbar. Das ist nicht nur praktischer, sondern auch sicherer. Das Schwierigste ist dann nur, sich daran zu erinnern, welcher private Schlüssel zum öffentlichen passt.
Statistiken zur Hardware-Nutzung (CPU, RAM etc.) anschauen.
 |
| Statistiken zu einer VM |
Einziger Nachteil, der uns aufgefallen ist: SMTP-Port 25 ist bei allen ccloud³ VMs für neue Konten blockiert. Wir haben diese „Restriktion“ umgangen, indem unser E-Mail-Server bei Anexia in Wien läuft. An sich können wir die Entscheidung, dies nicht anzubieten, nachvollziehen. Simpel ist das Mail-Selberhosten meistens nicht und unbetreute SPAM-Schleudern wird es einige geben.
Insgesamt war der Kontakt mit centron schnell und unkompliziert.
Vorteile einer VM¶
Wir sehen im VM Hosting generell einige Vorteile:
keine Hardware (wie HDDs) mehr tauschen
kein Hoffen und Beten mehr, wenn spontan in einigen hundert Kilometer Entfernung ein Switch-Netzteil den Geist aufgegeben hat. Switche zu konfigurieren und aktualisieren, ist mit VMs nicht mehr unser Problem.
kein IPMIs mehr, die nur TLS 1.0 aus der pre-snowden Ära können. Am schönsten waren immer noch Basteleien für remote consolen mit JAVA, um Zugriff für den Fall der Fälle zu haben. Da ist man fast schon ein wenig froh, sobald als Alternative ein Windows-Programm angeboten wird, das teils unerwartet gut mit wine funktionierte.
Dazu sollte man immer im Hinterkopf behalten, dass wir das Portal in unserer Freizeit betreiben. Mal aus Spaß mit alten IPMIs spielen ist toll. Wenn aber alles brennt und man nur schnell an die Server kommen will, wird das relativ zügig nervig.
Weiteren Schritte mit Ansible¶
Nach dem initialen Setup übernimmt Ansible bei uns. Das war schon in Zeiten von eigener Hardware so. Ansible stellt unter anderem sicher, dass
die Grundkonfiguration einheitlich ist. Dazu gehört beispielsweise, dass alle nötigen Admin-Accounts angelegt sind.
jeder Host Docker erhält.
wireguard für Verbindung zwischen den Maschinen konfiguriert ist.
dnsmasq für internes DNS installiert ist. Das ist nötig, damit die Docker-Container ebenfalls interne DNS-Namen kennen. Sonst würde uns mittlerweile eine einfache hosts-Datei reichen.
Dienste für Backup und Monitoring auf jedem Host konfiguriert sind.
Wie immer kratzt das nur an der Oberfläche, sollte aber einen guten ersten Überblick geben.
Am Standort Wien haben die bereits zwei bestehenden VMs ein Upgrade auf jeweils 8GB RAM bekommen. Das reicht uns für Dienste wie gitea oder grafana. Zusätzlich läuft hier mailcow 🇬🇧, das unter anderem den Mailversand von ubuntuusers.de übernimmt.
Wie man einen Frontend Webserver umzieht¶
Sobald die VMs nun all ihre grundlegenden Dienste konfiguriert haben, steht noch an, jegliche eintreffenden Anfragen auf die neuen VMs zu leiten. Vorab: Spontan geht der Umzug eines Frontend Webservers eher nicht. Das liegt meistens an der jeweiligen Konfiguration der DNS Records, genauer gesagt der Time-To-Live (TTL). Die TTL beschreibt wie lange Clients den Record lokal zwischenspeichern können. Die TTL kann man aber vor dem Umzug auf einige wenige Minuten redzuieren, so dass man 1) als Umziehender nicht lange warten muss, bis man weitermachen kann und 2) der Dienst für Endnutzer nur kurz nicht-verfügbar ist.
Sobald Subdomains dann noch alle einen CNAME haben, muss man nur A und AAA-Record einer Domain ändern, damit der Umzug erfolgen kann. Auch dürfen die TTLs von CNAMEs höher sein (Das hat uns eine AI gesagt und wir haben blind vertraut. Hat in diesem Fall aber sogar mal gestimmt.). Wenn Googles DNS-Server sagen, das passt, dann erhält man – zumindest nach unserer Erfahrung – direkt neue Zertifikate von Let's Encrypt.
Wenn die Konfigurationen in Ansible bereits im Voraus erstellt wurde, diese Syntaxchecks standhält, ist DNS tatsächlich das geringsten Problem.
Fazit¶
In Summe haben wir nun bei Anexia in Wien 2 VMs, sowie 2 weitere VMs bei Centron in Bamberg. Die letzten beiden sind hierbei die mit mehr Leistung. An beide nochmal ein großes Danke, dass sie das Sponsoring übernehmen!
An dieser Stelle wollen wir an die jahrelange gute Kooperation mit NetCologne hinweisen. Ohne Details zu kennen, hätte der verbrauchte Strom der Server wohl einige Haushalte Jahre lang versorgt.
Ansonsten lief der Umzug überraschend ohne große Unterbrechungen. Hoffentlich bleibt das auch so. Zumindest Hardware tauschen muss das Webteam nun nicht mehr.
Was wir vermissen werden? Nicht viel. Am Meisten ggf. noch das Schmunzeln beim Lesen der Schachtelwörter aus einem alten iDrac:
