Nicht alles ist ein Nagel

Ist dein einziges Werkzeug ein Hammer, so ist jedes Problem ein Nagel

Dieser Spruch ist ein guter Ratgeber, wenn es darum geht das richtige Vorgehen zu wählen. Dazu ein Beispiel aus meiner Arbeit.
Achutng, das Besipiel nimmt starken Bezug auf Ceph, sollte jedoch auch ohne Kenntnisse von Ceph verstanden werden.

Beispiel

Bei der letzten Umstellung der Infrastruktur viel die Entscheidung, von einem einzelnen NAS auf ein Speichercluster umzusteigen. Die Gründe dafür waren vielfälltig. So kann bei einem einzelnen NAS ein Hardwarefehler zu einem Stillstand der gesamten Infrastruktur führen. Ist Ersatzthardware vorhanden, so ist dies kein grösseres Problem. Jedoch ist jemand von Nöten, welcher den Fehler finden und die betreffende Hardware austauschen kann. Da ich die IT alleine Betreue fehlt diese Person, sollte ich abwesend sein. Das heisst nicht, dass ich der einzige Mitarbeiter bin, der dazu in der Lage ist. Jedoch kenn ich die Infrastruktur gut, während die anderen Mitarbeiter eine regelmässige Schulung und Auffrischungen bräuchten, um mithalten zu können. Bei begrenzten Mannstunden ist dies ein unnötige Belastung.
Der alternative Weg ist, dass die Infrastruktur einen Ausfall einzelner Hardware, bis zum Ausfall eines ganzen Servers überlebt und nicht direkt ein menschliches Eingreifen erfordert.

Zu dieser Zeit hatten wird auch nicht das Geld, um ein Speichercluster einzukaufen. Jedoch bekammen wir die Chance aus mehreren Palletten alter Serverhardware Material für uns herauszusuchen. Dabei habe ich in damaliger Unwissenheit vor allem alte IBM Storagesysteme ausgewählt. Diese hatten orginal nur FibreChannel Anschlüsse, welche mit unserem Hypervisor nicht einfach zu nutzen sind. Jedoch hatten die Hauptserver zwei PCIe Anschlüsse. Meine Idee war, die Server mit Netzwerkkarten nachzurüsten.

Dies schloss aus meiner Sicht das nutzen des IBM Betriebssystem aus. Das Neuinstallieren von Ubuntu-Server auf der Hardware bereitete mir jedoch Mühe. So wurde ein SAS-Adapter benutz, von dem ich keine Treiber gefunden habe. Also schied das direkte Nutzen der Server aus. Jedoch haben wir auch eine Anzahl an JBODs mitgenommen. Daher war die nächste Idee die JBODs direkt an einem anderen Computer anzuschliessen und so diesen um 24 2.5" SAS-Anschlüsse zu erweitern. Diese Versuche vielen auch ins Wasser. Durch Recherche im Internet fand ich heraus, das die IBM-JBDOs auf die speziellen SAS-Adapter angewiesen sind und somit nur mit IBM Servern liefen.

Somit hatte ich einen Berg von IBM Hardware, welche für mich nutzlos war. Einzig die Harddisks konnten ohne Probleme auf andere Hardware betrieben werden. Somit wurde aus der Not die Idee für unsere eigenen JBODs geboren. Wir haben uns Servergehäuse mit eingebauten SAS-Backplanes gekauft und dann mit einem Netzteil und SAS-Adaptern ausgerüstet. Diese JBODs waren billiger als fertige Modelle, verfügten aber nicht über die Überwachungsfuktionen gekaufter JBODs. Als Server dienten alte HP Elitedesks, welche mit externen SAS-Adaptern ausgrüstet worden sind. die Elitedesk hatten wir von einer bestehenden Spende in genügender Menge vorhanden

Nun ging es an das Aufsetzten des Clusters. Dabei bestand die Wahl zwischen Ceph und Gluster. Dabei hat mich Ceph mehr überzogen. Auch scheint  das Glusterprojekt seit längerem nicht mehr aktiv betreut zu werden.
Da mir bewusst ist, dass die Elitedesk nicht über viel Leistung verfügen, habe ich entschieden, neben den vier Elitedesk mit je einem JBOD, drei Elitedesk für die Monitoring-Dienst einzusetzten. So habe ich mit dem Implementieren des Clusters begonnen. Das lief gut und bis auf kleinere Störungen, welche durch meine Wahl von Harddisk geschuldet waren lief das Cluster einwandfrei.

Jedoch traten mit der Zeit verschiedene Probleme auf. So sind einzelne OSDs immer wieder auf abwesend gewechselt, was eine Clusterreparatur ausgelöst hatte. Nach 10-15 Minuten war der betreffende OSD wieder erreichbar, was ein "Rückbau" der Wiederherstellung auslöste. Zusätzlich konnte es unter hoher Last vorkommen, dass die virtuellen Disk nicht genügend schnell eine Antwort bekammen und somit das Filesystem auf read-only wechselte. Dies erforderte einen Neustart der Virtuellen Maschinen und manchmal sogar eine manuelle Reparatur.

Auch verfügten die EliteDesk keine Möglichkeit zur abgetrennten Überwachung und Steuerung, wie zum Beispiel ein Server mit IPMI.
So mussten die Server zum Teil von Hand neu gestartet werden. Da das Rack im gleichen Raum ist wie mein Büro, so stellte dies kein grössere Problem dar. Jedoch hatte ich keine Möglichkeit auf die Konsole zuzugreifen, ausser per ssh.
Auch gerieten die Elitedesk immer wieder an ihre Grenzen.

Für 2024 hatte ich ein genügend grosses Budget, um mir vier alte Supermicro Server kaufen zu können, welche die Elitedesk mit den JBODs ersetzt haben. Die drei Monitor-Elitedesk verbleiben für den Moment im Cluster, da der ISCSI-Gateway auf diesen läuft und die Konfiguration von diesem extrem mühsam war. Auch ist die Last genügend klein, so dass ihre schwache Hardware das Cluster nicht ausbremst.

Seit dem Serverwechsel hat sich kein OSD mehr aus dem Cluster zurückgezogen. Auch haben sich bis jetzt auch unter grösserer Last keine der virtuellen Disks blockiert.

Lehren

Bis dir der Grenzen deiner Hardware im klaren. So hat das fehlen von IPMI mir die Arbeit mehrfach erschwert. Auch hat die geringe Hardwareleistung der Elitedesk die Performance des Clusters eingegrenzt.

Ein weiterer Punkt ist die Suche nach Alternativen. Meine JBODs waren günstiger als die Alternativen und hatten keine Einschränkungen, welche mich behindert haben. Jedoch haben die Supermicro Server ungefähr gleichviel wie die komplete Hardware aus JBODs und SAS-Karten für die Elitedesk gekostet.

Habe ich damals die falsche Entscheidung getroffen?

Rückwirkend ist man immer schlauer. Zum Zeitpunkt der Entscheidung die JBODs selber zu bauen, kannte ich den Lieferanten der Occassions-Server noch nicht. Auch kam mir die Idee von Occassionsserver gar nicht. Ich sties auf den Lieferanten, als ich andere Komputerhardware gesucht habe. Erst später habe ich die Server und ihre Preise bemerkt.

Zusätzlich sind vier der JBODS noch immer bei den BackUp-NAS angeschlossen und leisten dort klaglos ihren Dienst.

Auch war das Cluster zu 99% der Zeit ohne Probleme am laufen. Ich konnte Server neustarten, ohne das ich alle Virtuellen Maschinen stoppen musste. Die Probleme waren zum Teil auch auf ein unvollständiges Verständniss von Ceph zurückzuführen.

Auch werden wir demnächst eine Laborumgebung bauen. Dort werden die EliteDesk erneut als Server herhalten müssen. Jedoch hat die Laborumgebung keine 99.99999% Verfügbarkeit als Anfoderung und die Last wird auch nicht so hoch sein. Die Umgebung dient mehr als Testumgebung für Konfigurationen und zur Ausbildung von lehrwilligen Mitarbeitern. So dass nicht die gesamte Produktive Umgebung stillsteht, wenn ein Fehler begannen wird.

Tipps für dich

Solltest du in die Lage kommen, ein ähliches Projekt wie mein Beispiel betreuen zu müssen, so denke auch über nicht direkt logische Alternativen nach. Man kann zwar den Bau eigener JBODs als unkonventionel betrachten, jedoch war mein weg dahin gradlinig.

1. IBM Server mit IBM JBODs
2. eigener Server mit IBM JBODs
3. eigener Server mit eigenem JBOD

Auch kann ein Blick von aussen, auch durch technisch schlechter bewanderte Personen, helfen eine alternative zu finden.
Ich hatte schon mehrmals durch Gespräche mit meinen Eltern gute Ideen, welche sich als extrem wertvoll erwiesen. Zwar ist mein Vater in der IT tätig, jedoch ist er nicht als Systemadministrator tätig, sondern betreut Software, welche auf den Servern läuft. Meine Mutter arbeitet in einem nicht technischen Beruf und hat auch sonst nicht viel mit Komputern am Hut.

Aber genau solche Ansichten und Ideen von aussen können als Gedankenstarter benutzt werden.