Das Infrastruktur-Herz schlägt höher - endlich eigene Server vor Ort - zum Anfassen, Hingehen und nicht nur zum Verbinden auf eine gesichtslose Recheneinheit in Frankfurt.
Wie es der Zufall wollte, ergab sich die Chance verhältnismäßig günstig an eigenes Blech zu kommen. Die Server sind gebraucht und passen somit gut zu unserem angestrebten Ziel der Nachhaltigkeit.
Die Diskussion rund um eigene Server ist durchaus ein paar Monate alt. Auf unserem diesjährigen Retreat weckte Fabian die Diskussion aus dem Dornröschenschlaf. Denn für die vielen Fotos und Videos, die bei sämtlichen Gelegenheiten wie Meetups, Retreats und anderen Events entstehen, sollte endlich eine vernünftige, möglichst redundante Speicherlösung her.
Da nicht nur Bedarf im Hinblick auf Speicherplatz bestand, sprang die Diskussion von einer reinen NAS-Lösung schnell wieder zu eigenen Servern über. Die Server sollten insbesondere für Experimente, Infrastruktur-Learnings und auch Machine Learning mit Kubeflow genutzt werden.
Alle Server besitzen ein SSD–RAID1 für das Betriebssystem und zusätzliche HDDs für Nutzdaten. Zwei Server sind eher rechenlastig mit 32 Kernen, 64 GB RAM und 8x1 TB HDDs. Der dritte Server hat 16 Kerne, 24 GB RAM und 24x1 TB HDDs.
Als die Server dann endlich geliefert wurden, war es für einige wie Weihnachten.
Auf– und Einbau
Endlich waren sie da. Also direkt einen Serverschrank bestellen. Wir haben hin und her überlegt, wo wir einen im Büro hinstellen können und viele Sandstormies (FabiansStimme aus dem Off: 2 ;-)) sind mit Zollstock durch das Büro getigert auf der Suche nach einem passenden Plätzchen. Der passende Serverschrank kam einen Tag nach der Bestellung an und war bereits montiert. Die Türen und Seitenwände habe wir für den Einbau wieder entfernt.
Der Einbau der Server dauerte etwas länger als mit routinierten Händen, hat aber viel Spaß gemacht.
Nach langem hin und her ist die Entscheidung auf ZFS gefallen, genauer gesagt auf ZFS mit RAIDZ-2. Der größte Vorteil für uns ist die hohe Ausfallsicherheit, auch gegen "write holes". Der größte Nachteil von ZFS ist für uns, dass man Festplatten gleicher Kapazität benötigt und Festplatten–Pools nur vergrößern, nicht aber verkleinern kann.
Daher haben wir bei dem Server mit 24 Platten 4 Pools mit je 6 Platten erstellt. Damit können wir einen Pool ersetzen, wenn wir nur 6 neue Platten einbauen. Die alten Daten wechseln auf die Nachbar–Pools. Die Lösung erhöht außerdem die Performance, verringert aber die Netto-Kapazität. Bei den Servern mit acht Platten befinden sich alle in einem gemeinsamen Pool.
Während der Recherche sind wir auf eine erstklassige Reihe von Blog–Artikeln über ZFS gestoßen. Die Artikelreihe ist ein hervorragender Einstieg in das Thema ZFS und liest sich wie ein Handbuch - im positiven Sinne ;-)
Hack–Night zur Server-Inbetriebnahme
Für die erste Inbetriebnahme nutzten Sebastian und ich einen langen Abend. Zwei Dinge überraschten uns:
Wir wollten wissen, welche Festplatte in welchen Slot steckt. Trotz "sanfter" Methoden haben wir das System auf die Probe gestellt. Wir zogen im laufenden Betrieb eine Festplatte nach der anderen raus, notierten das Fach, schoben sie wieder rein - gar kein Problem!
Ohne RS232-USB Adapter war der Switch nicht zu konfigurieren. Also wieder bei Seite gelegt ;-)
Übrigens, natürlich nützt das beste RAID-System nichts, wenn niemand auf die Server achtet.
Um dies auszuschließen, planen wir ein Monitoring der Server inklusive aller Festplatten in das Prometheus/Grafana Setup des Kubernetes–Cluster einzuhängen.
Vielen Dank für's Lesen. Das ein oder andere Thema zu den Servern findet bestimmt seinen Weg in zukünftige Blogposts. Schreibt uns gern bei Fragen und Anregungen.
Dein Besuch auf unserer Website produziert laut der Messung auf websitecarbon.com nur 0,28 g CO₂.
