Ausbildung bei inovex: Konzeptionierung und Aufbau eines Software Defined Storage Clusters

Jeder, der sich für die Ausbildung entscheidet, hat sie unweigerlich vor sich: die IHK-Abschlussprüfung. Das kann vor allem in dem Moment lästig erscheinen, in dem man sich ein Projekt selbst zusammenreimen muss. Nicht jedoch bei inovex: Hier klärt Ihr das Projekt mit Eurem Ausbilder ab. Dabei wird darauf geachtet, dass Ihr eine Aufgabe übernehmt, die dem Betrieb und natürlich Euch selbst einen Mehrwert bietet. In diesem Blog-Artikel möchte ich Euch von meinem Abschlussprojekt bei inovex erzählen.

Zunächst ganz kurz zu mir: Mein Name ist Maik Scheske, ich bin 25 Jahre alt und im dritten Lehrjahr meiner Ausbildung zum Fachinformatiker für Systemintegration bei inovex. Angefangen habe ich bei inovex im September 2014. Durch meine vorhergehende schulische und akademische Ausbildung war es mir möglich, direkt im zweiten Lehrjahr in die Ausbildung einzusteigen.

Das Projekt

Der Titel meines Projektes lautete: „Konzeptionierung und Aufbau eines Software-Defined-Storage-Clusters“. Klingt fürs Erste gut, aber was bedeutet das jetzt genau? Der Storage ist vereinfacht ausgedrückt der Speicherort der Daten von Clients und Servern. Das kann die Festplatte in Eurem PC sein oder eben ein groß angelegtes Serversystem.

Im Arbeitsumfeld interessiert uns vor allem die Hochverfügbarkeit unserer Daten. Das bedeutet im Einzelnen, dass sichergestellt sein muss, dass man jederzeit auf die Daten zugreifen kann. Ebenso wichtig ist es dafür zu sorgen, dass die Daten über genügend viele Festplatten gespiegelt werden. So können wir sicherstellen, dass uns keine Daten verloren gehen, wenn einmal eine Festplatte ausfällt.

Herkömmlich wird das über sogenannte RAIDs realisiert (Redundant Arrays of Independent Disks). RAIDs dienen der Organisation mehrerer physischer Massenspeicher wie Festplatten und SSDs, die zu logischen Laufwerken zusammengefasst werden. So soll die Datensicherheit und der Datendurchsatz erhöht werden.

Große Nachteile von RAID-Systemen sind ihr Mangel an Flexibilität und ihre teils sehr teure Umsetzung. Die sogenannten RAID-Level, die festlegen welche Storage-Strategie verfolgt wird, lassen sich nur sehr schwer anpassen, wenn sie einmal gesetzt sind. Die mangelnde Flexibilität zeigt sich außerdem dadurch, dass sich RAID-Systeme nicht verteilen lassen und somit an einzelne Systeme gebunden sind.

Ein Software-gesteuerter Storage verlagert die Fragen, die sich bezüglich der Verwaltung der Daten ergeben, weg von den RAIDs auf die Software-Ebene. Mit eigens dafür entwickelter Software lässt sich von den einzelnen Festplatten über Verzeichnisse hinab bis hin zur einzelnen Datei definieren, wie diese im Storage vorzuhalten sind. Anschließend kümmert sich die Software automatisch um die Verwaltung.

Ziel meines Projektes war es dementsprechend, ein solches Software-Defined-Storage zu planen, die nötige Server-Hardware zu bestellen und diese anschließend entsprechend zu konfigurieren.

Ablauf

Architektur- und Bestellphase

Zu Beginn des Projektes habe ich zusammen mit erfahrenen Systemarchitekten von inovex zwei Server-Architekturen entwickelt. Die Herausforderung war hierbei, die Anforderungen der Software und des Betriebes miteinander zu verbinden.

Anforderungen an die Architektur waren vor allem die Folgenden:

• Vertikale Skalierbarkeit, d.h. dass die Server leicht um weiteren Speicherplatz erweitert werden können
• Horizontale Skalierbarkeit, d.h. dass es möglich sein muss, das Cluster um weitere Server zu erweitern. Dies wird auch in die Breite skalieren genannt.
• Die Server müssen hochverfügbar ausgelegt werden.

Die entwickelten Architekturen wurden dann der Fachabteilung zur Diskussion vorgelegt. Innerhalb dieser Diskussion wurde festgelegt, welche der beiden Architekturen schlussendlich umgesetzt werden sollte.

Anschließend habe ich mich mit der Recherche geeigneter Hardware für die ausgewählte Architektur beschäftigt. Anhand einer Liste konnte ich Kontakt mit verschiedenen Anbietern aufnehmen und Angebote anfordern.

Diese Angebote habe ich miteinander verglichen, um eine Vorauswahl zu treffen. Ausschlaggebend waren in dieser Phase zum einen die Inhalte des Angebots und zum anderen natürlich der Preis.

Zwei der vier Anbieter konnten unsere Hardware-Anforderungen nicht erfüllen, weshalb wir nur mit den verbliebenen zwei Anbietern in die Nachverhandlungen traten. Als Ergebnis fiel die Wahl auf den Anbieter, der uns das günstigste Angebot unterbreitete.

Mit der Annahme des Angebots und der Auftragsbestätigung, endete die erste Phase meines Projekts.

Durchführungsphase

Einige Wochen später war es dann soweit: Alle Hardware-Komponenten wurden geliefert und der praxisorientierte Teil des Projektes konnte beginnen.

Zunächst habe ich die Lieferung auf ihre Vollständigkeit hin geprüft und zur Inventarisierung an den IT-Einkauf übergebenen. Anschließend wurden die bestellten SSDs ein- und der Cluster für einen Testbetrieb aufgebaut.

Hardware-Test: RAM und CPU

Hierzu habe ich die Server entsprechend mit Strom versorgt und über den Switch an das Netzwerk angebunden. Nun galt es die Hardware sogenannten Burn-In-Tests zu unterziehen, um etwaige Defekte ausschließen zu können. Hierfür wurde zunächst ein Memory-Test gestartet, mit dem sich der RAM und die Funktionalität der CPUs testen lassen. Diese Tests liefen etwa 24 Stunden und zeigten zunächst keine Fehler bei den Servern auf (mehr dazu unten).

Automatisierte Installation des Betriebssystems

Die Server sollten mit CentOS als Betriebssystem über das Netzwerk installiert werden. Hierfür galt es entsprechende Firewall-Anpassungen durchzuführen, um Installationen über das Netzwerk am Standort Karlsruhe zu ermöglichen.

Anschließend habe ich für die Server noch statische IP-Adressen reserviert, sodass sichergestellt ist, dass sie immer unter den gleichen Adressen zu erreichen sind.

Zur Verwaltung solcher Installationen setzt inovex Foreman ein. Foreman ist eine Softwarelösung, die sich unter anderem um die Installation von Betriebssystemen einzelner Hosts kümmert, diese provisioniert und konfiguriert. So kann ich den Zustand beschreiben, in den meine Systeme versetzt werden sollen, und Foreman kümmert sich dann darum an den richtigen Zahnrädern zu drehen, um diesen Zustand zu realisieren.

Test der Netzwerkanbindung

Da die Server nun mit einem Betriebssystem ausgestattet waren, konnte ich einen Test der Netzwerkanbindung durchführen. Hierfür habe ich iperf3 auf den Systemen installiert.

Dieses Tool zum Testen von Übertragungsgeschwindigkeiten im Netzwerk, wird auf einem Client als iperf-Server gestartet und auf einem zweiten Client, dessen Verbindung zum Server geprüft werden soll, als iperf-Client.

Der Client erzeugt nun fortwährend Datenpakete innerhalb seines Arbeitsspeichers und überträgt diese an den Server, der wiederum die Daten in seinen eigenen Arbeitsspeicher einliest. Dabei wird gemessen, wie lange die Übertragung jeweils dauert. Nach der Übertragung wird der Arbeitsspeicher erneut befüllt.

Die Geschwindigkeit, mit der die einzelnen Datenpakete übertragen wurden, lässt sich dann auf dem iperf-Server auslesen.

Der Test ergab, dass alle Netzwerkkarten ihre Übertragungsgeschwindigkeiten von knapp 10 Gbit/s erreichen konnten.

Installation von Quobyte

Quobyte ist eine Softwarelösung zur Verwaltung von Massenspeicher in Form eines Software Defined Storage. Diese Lösung wurde in Absprache mit inovex gewählt. Die Installation der Quobyte-Software auf dem Cluster wurde von mir vorgenommen.

Quobyte kennt drei Arten von logischen Geräten/Services:

• Das Metadata Device verwaltet die Metadaten eines Volumens und der darin befindlichen Dateien und Verzeichnisse.
• Der Registry Service sorgt dafür, dass die einzelnen Knoten untereinander kommunizieren können, indem diese registriert werden.
• Das Data Device stellt den Massenspeicher dar, der von Quobyte verwaltet werden kann.

Die einzelnen Knoten stimmen sich über einen Consensus-Algorithmus (Paxos) ab, wodurch immer ein definierter Zustand des Clusters gewährleistet werden kann.

Einrichtung von Quobyte

In Quobyte lassen sich nun Volumengruppen definieren, diese beschreiben die logische Zusammenfassung von Speicherplatz. Für jedes dieser Volumen kann man eigene Konfigurationen anlegen, in denen man zum Beispiel festlegt wie oft die Daten über die unterschiedlichen Server und die einzelnen Platten repliziert werden sollen.

Für den ersten Testbetrieb wurde ein Volumen angelegt, das dreimal repliziert werden soll.

Test der SSDs

Um die Schreib- und Lesegeschwindigkeit der SSDs zu testen, wurde das zuvor angelegte Volumen als Verzeichnis auf einem der Server gemountet. Mit dem Tool bonnie++ wurde in das Verzeichnis geschrieben und aus diesem gelesen. Die gemessenen Geschwindigkeiten ließen sich dabei direkt der Web-Oberfläche von Quobyte entnehmen. Das Ergebnis dieser Tests war positiv und entsprechend der technischen Spezifikationen der SSDs.

 

Dokumentation

Natürlich bleibt für ein erfolgreiches Projekt die Projektdokumentation nicht aus. Diese habe ich über die Dauer des Projektes hinweg beständig erweitert. Den Abschluss bildete hierbei die Erstellung der Benutzerdokumentation. Da diese sich an eine Fachabteilung richtete, ging ich hier in meiner Beschreibung sehr in die technische Tiefe des Projektes.

Probleme/Herausforderungen

Eine besondere Herausforderung war für mich die Erstellung der Architektur des Clusters, da ich eine solche Architektur zuvor noch nie erstellt hatte. Jedoch konnte ich mit der Unterstützung meiner Kolleg:innen viel lernen und wir entwickelten so zusammen eine effektive Lösung.

Problematisch waren die Lieferzeiten der Server. Da ich zunächst auf die Projektzusage der IHK warten musste, konnte ich hier nicht direkt vorarbeiten. Nach der Planungsphase und der Auswahl des geeigneten Hardwarelieferanten dauerte es noch gut 4 Wochen, bis die Hardware komplett geliefert war. Das hat die Durchführungsphase entsprechend weit nach hinten verschoben.

Unvorhergesehenes bleibt leider auch nicht aus. So konnte ich das Projekt schlussendlich nur mit drei von vier Servern abschließen, da ein Server mit einer defekten CPU geliefert wurde und dieser entsprechend reklamiert werden musste.

Ergebnis & Ausblick

Trotz eines defekt gelieferten Servers konnte das Projekt erfolgreich durchgeführt werden. Der Fachabteilung wurde die Serverhardware übergeben. Diese wurde in einem ersten Testbetrieb bereitgestellt, sodass sie den Cluster für den späteren Betrieb im Rechenzentrum testen kann.

Da es sich bei meinem Projekt um einen Teil eines Großprojektes handelte, wird der Cluster sich künftig in den Plan eines Software-Defined Data Centers als Storage-Lösung eingliedern. Mein Projekt hat dem Betrieb also einen direkten Mehrwert gebracht hat.

Ausbildung@inovex

Interesse geweckt? Wenn du selbst eine Ausbildung als Fachinformatiker*in für Systemintegration anstrebst oder einen Job in der IT suchst, schau Dir die Details zur Arbeit bei inovex an. Dich erwartet eine motivierende Arbeitsumgebung, in der Du sowohl die Basics als auch innovative neue Technologien in einem freundlichen und respektvollen Umfeld kennenlernst und anwendest.