Der RADOS-Objectstore und Ceph (Teil 1)

In die Breite gegangen

Skalierbares Storage ist eine Kernkomponente von Cloud-Umgebungen. RADOS und Ceph treten mit dem Versprechen an, nahtlos skalierbares Storage zu ermöglichen.
NAS-Speicher mit einer Kapazität von einigen Dutzend Terabyte, wie sie sich für mittelständische Anwender eignen, nimmt die ADMIN-Redaktion in der Ausgabe ... (mehr)

Der IT-Thema der Gegenwart ist zweifellos das Cloud Computing. Kaum eine Frage treibt die Verantwortlichen für Infrastruktur bei großen Unternehmen gegenwärtig so an wie die nach der besten Umsetzung der Wolke. Das Prinzip Cloud ist dabei eigentlich sehr einfach: Das Ziel von typischen IaaS-Systemen ist es, Benutzern Kapazitäten in Form von Rechenleistung und Speicherplatz anzubieten und zwar so, dass für den Anbieter selbst dabei so wenig Arbeit wie möglich entsteht und die gesamte Plattform so flexibel wie möglich ist. Konkret heißt das, dass Kunden Rechenleistung und Plattenplatz nach eigenem Gutdünken anfordern können und benutzen, solange sie die Services tatsächlich brauchen. Für die IT-Dienstleister ergibt sich die Notwendigkeit, die eigenen Setups möglichst skalierbar anzulegen: Lastspitzen sollten ohne Probleme abzufangen sein. Wenn die Plattform wächst – und Wachstum ist letztlich das Ziel von praktisch jedem Unternehmen – soll auch die dauerhafte Erweiterung kein Problem sein.

In der Praxis gestaltet sich die Umsetzung einer solchen Lösung freilich etwas umständlicher. Skalierbare Virtualisierungsumgebungen gehören zu den eher leicht umzusetzenden Themen; Xen und KVM tragen in Verbindung mit den einschlägigen Management-Tools dazu bei, dass sich Virtualisierungshosts ohne Schwierigkeiten verwalten lassen. Auch der Scale-Out ist kein Problem: Braucht die Plattform mehr Rechenleistung, kommen weitere Rechner dazu, die sich nahtlos in die vorhandene Infrastruktur einfügen.

Knackpunkt Storage

Interessant wird die Sache beim Thema Storage. Die Art und Weise, wie in IT-Umgebungen Daten gespeichert werden, hat sich im Grunde in den letzten Jahren kaum verändert. Anfang der 90er gab es in Rechenzentren viele Server mit lokalem Storage, die alle die klassischen Probleme eines Single Point of Failure (SPOF) hatten. Ab Mitte der 90er hielten SANs Einzug samt dazugehöriger FibreChannel-HBAs. Die boten zwar wesentlich mehr Redundanz als ihre Vorgänger, waren und sind im Gegenzug aber auch empfindlich teuer. Wer es lieber etwas günstiger mag, setzt seit ein paar Jahren auf DRBD mit Standard-Hardware und umgeht so die teils horrenden Kosten von SANs. Ein Problem haben all diese Ansätze gemein: Sie skalieren nicht nahtlos.

Scale-Out & Scale-Up

Admins unterscheiden grundsätzlich zwischen zwei Formen von Skalierbarkeit: Skalieren in die Höhe (Scale-Up) basiert auf der Idee, die Ressourcen bereits vorhandener Geräte zu erweitern. Dem gegenüber steht das Skalieren in die Breite (Scale-Out), das darauf setzt, neue Geräte hinzuzufügen (Abbildung 1). Ein Beispiel für Scale-Out-Lösungen sind Datenbanken: Hier ist es oft möglich, die Last auf mehrere Slave-Server zu verteilen.

Abbildung 1: Der Unterschied zwischen vertikaler und horizontaler Skalierung.

Im Hinblick auf Storage ist Scale-Out allerdings ein nahezu unbekanntes Thema: Lokales Storage in Servern, SAN-Storages oder Server mit DRBD sind meistens nur in die Höhe erweiterbar (mehr Platten), aber nicht in die Breite. Wenn das Gehäuse voll ist, muss im Zweifelsfalle ein zweites Storage her, das sich dann aber oft genug nicht mit dem schon vorhandenen zusammenfassen lässt und so die Wartung erschwert. Bei SAN-Storages gilt außerdem: Zwei SAN-Storages verdoppeln den ohnehin hohen Preis!

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019