Ceph: Wie bei XORTEX der Umstieg gelang
0
Die XORTEX eBusiness GmbH, ein Tochterunternehmen der Thomas-Krenn.AG, ist eine Internetagentur, deren Portfolio von Websites, Onlineshops und Newslettern bis zu Mobile Apps reicht. Die Leistungen von XORTEX umfassen Consulting, Development, Online Marketing und den Betrieb der Anwendungen. Kennzeichnend ist dabei die nahtlose Integration der Software in die Geschäftsprozesse und die interne IT-Landschaft des Kunden.
XORTEX hostet die Websites seiner Kunden auf eigener Hardware in einem Frankfurter Rechenzentrum. Am Firmenstandort im österreichischen Neufelden stehen die Server, die für Entwicklung und Tests der Kundenprojekte sowie für die Infrastruktur und den Geschäftsbetrieb verwendet werden. An beiden Standorten laufen die Systeme seit mehreren Monaten unter Ceph/KVM in einer „hyperkonvergierten“ Umgebung im Eigenbau.
Das TKmag sprach mit Erik Meixner von XORTEX über seine Erfahrungen (und kommt
dabei fast ganz ohne Ceph-typischen Fachjargon aus). Erik gehört zum Storage Team der Thomas-Krenn.Group, das auch interne Erfahrungen intensiv nutzt, um neue Produkte und Speicherlösungen für die Kunden der Thomas-Krenn.AG zu entwickeln.
TKmag: Laut Aussage mancher etablierter Storage-Anbieter ist das Aufsetzen und Administrieren eines Ceph-Systems in „Eigenleistung“ nur etwas für Leute mit zu viel Zeit. War Euch langweilig?
Erik Meixner: Ganz sicher nicht. Die Hardware für unsere Produktivserver im Rechenzentrum und die Entwicklungssyteme hier in Neufelden war in die Jahre gekommen und brauchte ohnehin Ersatz. Unsere vorherige Virtualisierungslösung funktionierte mit OpenVZ, das Storage war klassisch über iSCSI angebunden und für die Ausfallsicherheit sorgte ein DRBD-Cluster. Soweit ein ganz normales Setup für den stabilen Betrieb. Es war uns allerdings zu unflexibel, zu wenig skalierbar und eigentlich auch zu komplex. Ceph in Verbindung mit KVM versprach, eine ganze Menge Komplexität herauszunehmen und für wesentlich mehr Skalierbarkeit zu sorgen.
Und nach fast einem Jahr Produktivbetrieb muss man sagen: Es hat funktioniert.
TKmag: Ceph gilt als nicht völlig trivial, will man hohe Verfügbarkeit, Performance und
Skalierbarkeit gleichzeitig unter einen Hut bekommen. Hattet Ihr externe Beratung im Haus?
Erik Meixner: Nein, wir haben uns unser Know-how selbst aufgebaut, wobei es natürlich
hilfreich war, dass auch in Freyung bei der Thomas-Krenn.AG und in Gütersloh bei filoo gute Leute sitzen, auf die man bei Bedarf zurückgreifen kann. Aber es stimmt schon: Vor allem in der Netzwerk-Administration sollte man sehr sattelfest sein, wenn man so ein System aufsetzt. Doch sobald es einmal läuft, ist es sehr entspannt. Im Sommer 2014 haben wir mit einem Testsystem angefangen und seit Oktober 2014 laufen die Produktivserver im Rechenzentrum auf KVM/Ceph, unsere internen Systeme seit Frühjahr.
TKmag: Wie sieht denn nun Eure Architektur konkret aus?
Erik Meixner: Wir haben derzeit vier identisch aufgebaute Nodes, also einzelne Maschinen, im Cluster. Auf jedem dieser Nodes läuft KVM als Hypervisor und die Workloads entsprechend in virtuellen Maschinen. In unserem Ceph-Cluster sind alle Nodes gleichberechtigt, so dass bei einem Ausfall die anderen automatisch die Workloads übernehmen können. Ceph ist derzeit so konfiguriert, dass von jedem Datenobjekt drei Replikas auf verschiedenen Nodes existieren. Als Dateisystem haben wir uns für XFS entschieden, wie das von Ceph vorgeschlagen wird. Die VMs haben darauf liegend natürlich ihr eigenes Dateisystem, in den meisten Fällen Ext4.
TKmag: Und das Netzwerk? Du sagtest, dort wird es schnell kompliziert?
Erik Meixner: Ja, man muss aufpassen, sich dort keinen Single Point of Failure hereinzuholen und natürlich auch beachten, dass vor allem dann, wenn etwas ausfällt, Ceph eine ganze Menge Bandbreite für die Replikation braucht. Wir haben deshalb alle Switche redundant ausgelegt, und sämtliche Netzwerkkarten sind über Bonding an jeweils zwei verschiedene Switche angebunden. Außerdem haben wir dem Ceph-Storage ein eigenes physikalisches privates 10 GB-Netzwerk spendiert, so dass der Storage-Traffic nicht über das gleiche Netzwerk läuft wie der Traffic für die Workloads.
TKmag: Was passiert denn, wenn beispielsweise erstmal eine Platte ausfällt?
Erik Meixner: Nun, einerseits sind die Chancen hoch, dass wir das schon vorher entdecken. Die Systeme werden mit Icinga und S.M.A.R.T.-Monitoring überwacht, und wenn eine SSD Probleme macht, sehen wir das meist schon vor dem Ausfall. Sollte es aber doch passieren und eine von 24 SSDs ausfallen, erkennt Ceph den Ausfall, ernennt eines der beiden anderen Replikas zum Haupt-Replika und sucht sich auf einer der 23 anderen Platten Platz, um das dritte Replika erneut zu erstellen. Dieser Remapping-Prozess läuft vollautomatisch im Hintergrund ab. Nach dem Austausch teilt man Ceph einfach mit, dass die Platte wieder da ist und das war’s.
TKmag: Du sagst immer nur SSDs. Gibt es keine Harddisks mehr?
Erik Meixner: Richtig. Wir haben die Gelegenheit genutzt, komplett auf SSDs umzusteigen, um noch mehr Performance herauszuholen.
TKmag: Zurück zur Verfügbarkeit. Was geschieht, wenn ein ganzer Node stirbt?
Erik Meixner: Ceph erkennt, dass ein Knoten fehlt und fängt mit dem Remapping an, ähnlich wie beim vorigen Fall, nur ist hier für Ceph eben etwas mehr zu tun. Jetzt ist Zeit, den Node in Ruhe zu reparieren oder zu ersetzen. Anschließend wird er wieder im Cluster angemeldet. Falls Platten ersetzt wurden, müssen diese ebenfalls dem Cluster hinzugefügt werden. Ceph beginnt dann wieder das Remapping, bis alles seinen gewünschten Zustand erreicht hat.
TKmag: Was sind für Euch, abgesehen von diesem sehr entspannten Umgang mit Ausfällen, die wichtigsten Vorteile der derzeitigen Architektur?
Erik Meixner: An erster Stelle ganz klar die einfache Skalierbarkeit. Wir können einerseits Platten hinzufügen, so lange in den Nodes Platz ist, andererseits aus den derzeit vier Nodes fünf, sechs oder sieben machen, unter normalen Umständen stößt man hier nie auf Grenzen. Und in beiden Fällen liegt der Konfigurationsaufwand nahe Null. Andererseits nimmt Ceph, wie schon gesagt, Komplexität heraus, und zwar vor allem auf zwei Ebenen. Erstens brauchen wir keine RAID-Controller mehr, die in der Vergangenheit für Ärger gesorgt hatten. Zweitens verringert sich die Komplexität in der Anbindung der Virtualisierung zum Storage, da KVM direkt auf die Ceph Block Devices zugreifen kann. Drittens ist es natürlich praktisch, beispielsweise die Möglichkeit zu haben, VMs live ohne Downtime zwischen Hosts zu verschieben oder durch Thin Provisioning den Speicherplatz optimal zu nutzen.
TKmag: Wie administriert Ihr die Umgebung?
Erik Meixner: Wir haben dazu unsere eigene Web-basierte Oberfläche namens Servercenter geschaffen. Damit erledigen wir Dinge wie Einschalten, Ausschalten, Migrieren, Erstellen, Konfigurieren oder Löschen von VMs. Für andere Aufgaben wie das Monitoring verwenden wir Icinga, teilweise mit selbst entwickelten Plugins oder Plugins von Thomas-Krenn. Als Linux-Admins ist uns natürlich auch die Kommandozeile geläufig. Zur Installation eines Ceph-Clusters kommen von uns erstellte Ansible PlayBooks zum Einsatz, dank derer ein Linux-Server innerhalb weniger Minuten nach der Grundinstallation des OS zum vollwertigen Ceph-Knoten und zum Mitglied des Clusters wird.
TKmag: Zusammengefasst: Ihr würdet es also wieder tun. Welcher Art von Unternehmen
würdest Du ein ähnliches Vorgehen empfehlen?
Erik Meixner: Sinnvoll ist es bei Firmen, die eine hohe Skalierbarkeit im Storage-Bereich in Verbindung mit viel Flexibilität bei der Konfiguration der Virtualisierungsumgebung und hohen oder sehr flexiblen Anforderungen an die Verfügbarkeit brauchen. Auf jeden Fall sind erfahrene Netzwerk-Administratoren ein großes Plus, und ein gewisses Maß an Neugier, Lernbereitschaft und Spaß an neuer Technik sollten die Admins auch mitbringen.
