Unser Infrastrukturumzug in die Cloud

Heute geht es um ein Projekt aus unserem letzten Hackathon im Januar 2019: den Sandmann. Doch zunächst ein wenig Hintergrund. Wir haben die letzten drei Jahre damit verbracht, langsam, aber sicher praktisch unsere komplette Hosting-Infrastruktur von selbstbetriebenen Racks in diversen Rechenzentren in mehrere IaaS-Clouds umzuziehen:

Wie man sieht, war das ein langer Prozess, der nun aber endlich seinem Ende entgegen geht. Der Techniker in uns sieht das natürlich auch mit einem weinenden Auge, weil der Betrieb eigener Hardware viel Gestaltungsspielraum und auch einfach Spaß mit sich bringt. Aber die neue Welt bietet auch ihre eigenen einzigartigen Vorteile. Nur: Worin liegen die eigentlich?

Wenn man sich die üblichen Werbetexte ansieht, dann wird dort viel von Skalierung nach Bedarf und Lastspitzen gesprochen. Die treten bei uns eher selten auf. Wie man am Chart oben deutlich sieht, haben wir ein sehr konstantes Wachstum, jedoch keine Explosionen. Trotzdem wollten wir einen Vorteil der Cloud besser nutzen: die stundenweise Abrechnung.

Wenig genutzte Systeme zeitweise abschalten

Bisher liefen alle unsere Systeme rund um die Uhr durch - und zwar sowohl die kritischen Produktivsysteme als auch kleine, spezielle Testsysteme, die eigentlich nur selten tatsächlich gebraucht werden. Und bei letzteren haben wir im Hackathon angesetzt: Können wir die nicht automatisch nachts und am Wochenende abschalten? Das spart hier und da ein paar Euro und schont vielleicht sogar ein bisschen die Umwelt.

So ward der Sandmann geboren, der unsere weniger wichtigen Systeme fortan regelmäßig schlafen legt:

Das ganze Konstrukt besteht aus einer kleinen Webanwendung, die oben zu sehen ist, und Scripts, die sich über unser Config-Management einfach auf allen Systemen ausrollen lassen und sich nahtlos in unsere existierenden lokalen Snapshots, Offsite-Backups und ins Monitoring integrieren. So kann gewährleistet werden, dass ein System nicht gerade dann schläft, wenn es eigentlich Backups machen sollte. Oder dass das Monitoring nicht anschlägt, nur weil ein System regulär schlafen geht.

Durch diese enge Integration in unsere Infrastruktur können wir den Sandmann leider nicht sinnvoll als Open-Source-Lösung zur Verfügung stellen. Aber es handelt sich wie gesagt um ein Hackathon-Projekt: Drei Personen haben weniger als 24 Stunden gebraucht, um den aktuellen Stand zu entwickeln - und daher sollte es auch für andere Unternehmen möglich sein, mit überschaubarem Aufwand ein ähnliches Ergebnis zu erzielen, wenn die Voraussetzungen stimmen.

Flexible Anpassung in der Konfiguration

Eine wichtige Grundlage unserer Lösung ist das Config-Management in Form von BundleWrap. Hier ist die Konfiguration jedes Systems komplett hinterlegt und nachvollziehbar. Änderungen an vielen Systemen sind denkbar einfach. Soll ein System oder eine ganze Gruppe schlafen gehen, ergänzen wir einfach diese Metadaten zur restlichen Konfiguration:

'sandmann': {
    'up': {
        '45 6 * * mon-fri',
    },
    'down': {
        '15 19 * * mon-fri',
    },
},

Hier ist im Stile eines klassischen Unix-Crons die Information hinterlegt, dass das System jeden Montag bis Freitag um 06:45 UTC aufwachen und um 19:15 wieder schlafen soll. Nachts und am Wochenende ist die virtuelle Maschine also aus und verursacht praktisch keine Kosten. Nachdem diese Konfiguration in Git hinterlegt wurde, ist nur noch ein Aufruf von bw apply nötig, um die Konfiguration auf das Zielsystem auszurollen. Doch was passiert dann?

So funktioniert der Sandmann

Das System prüft ständig, ob es sich nun in einem Zeitfenster befindet, in dem es eigentlich schlafen sollte. Sobald dies der Fall ist, wird gegebenenfalls ein Backup gestartet. Wenn das fertig ist, wird die Sandmann-Webanwendung per API kontaktiert und ein Weckauftrag erstellt. Der Sandmann trägt entsprechend eine Downtime im Monitoring-System Icinga ein. Sofern dies alles ohne Fehler funktioniert hat, kann sich die virtuelle Maschine nun einfach selbst herunterfahren, sodass noch alle Dienste ordnungsgemäß beendet werden.

Zur Weckzeit kontaktiert der Sandmann dann einfach die API des jeweiligen Cloud-Anbieters und startet die entsprechende VM. Alternativ haben alle Kollegen auch die Möglichkeit, unkompliziert auf den oben sichtbaren WAKE NOW-Knopf zu drücken. So kann ein System auch vor der eigentlichen Weckzeit wieder gestartet werden, falls jemand beispielsweise doch mal am Wochenende daran arbeiten möchte.

Wir haben gut einen Monat nach dem Hackathon eine Reihe von unkritischen Testsystemen und ähnlichen Anwendungen für den Sandmann konfiguriert und damit innerhalb von 30 Tagen schon solide 551 Euro eingespart. Wenn wir keine weiteren Systeme aufnehmen, werden wir im ersten Jahr etwas über 8.300 Euro sparen. Gar nicht schlecht. Jedenfalls dürfte das nächste Team-Event damit großzügig finanziert sein. 😉

Hast du Lust, zusammen mit unseren Systemadministratoren an solchen Dingen zu arbeiten?

Vielleicht bist du bei unserem nächsten Hackathon-Projekt ja schon mit von der Partie! Aktuell sind wir auf der Suche nach Sysadmins und Kollegen für das IT-Servicemanagement. In unserem Portal für Bewerber und Interessenten findest du alle Infos zu den Jobs und viele Hintergründe rund um die Arbeit bei //SEIBERT/MEDIA. Oder schau einfach mal bei uns vorbei: An jedem dritten Freitag im Monat laden wir interessierte Leute zum OpenOffice ein. Wir würden uns freuen, dich kennenzulernen!

View this post in English

Weiterführende Infos

OpenOffice bei //SEIBERT/MEDIA oder unser monatlicher Tag der offenen Tür für Job-Interessierte
Ausbau der Freifunk-Infrastruktur bei //SEIBERT/MEDIA: Mehr freies WLAN für die Wiesbadener City
Ausgewählte Problemlösungen in unserem IT-Tagebuch
Freie Fahrt in ganz Hessen: Das RMV-Jobticket bei //SEIBERT/MEDIA

Mehr über die Creative-Commons-Lizenz erfahren