Beiträge

Als die beiden deutschen Softwareentwickler Martin und Dietmar Maurer im Frühjahr 2008 die Open SourceVirtualisierungssoftware Proxmox VE erstmals der breiten Öffentlichkeit vorstellten, hatte niemand wirklich damit gerechnet, dass sich die Virtualisierungsplattform in den nächsten 12 Jahren zu einer der meistgenutzten Virtualisierungslösungen im Linux-Segment entwickeln würde. Aktuellen Informationen zufolge werden weltweit mehr als 150.000 Server-Hosts in mehr als 150 Ländern mit Proxmox betrieben.

Allgemeine Informationen zu Proxmox

Ein Umstand, der zum Erfolg der Virtualisierungsplattform maßgeblich beigetragen hat, spiegelt sich in der Tatsache wider, dass Proxmox die Option bereitstellt, zwei unterschiedliche Virtualisierungslösungen gleichzeitig zu betreiben, und zwar:

–       virtuelle Linux Container (LXC)

–       kernelbasierte Virtual Machine (KVM)

Der virtuelle Linux Container ist eine performante und ressourcenschonende Container-Virtualisierung. Bei den KVMs handelt es sich um ein Kernel-Modul auf Linux-Basis, das direkt auf der Hardware als Hypervisor ausgeführt wird und bei der Virtualisierung von Hardware eingesetzt wird. Mit den KVMs lässt sich eine Vielzahl verschiedener Vserver (virtueller Server) erstellen, wobei alle aktuellen Betriebssysteme wie Windows, Linux und verschiedene BSD-Derivate unterstützt werden. Der Linux-Kernel wird im Rahmen der Virtualisierung selbst zum Hypervisor befördert, wodurch der Overhead auf einem Minimum gehalten wird. Die kernelbasierte Virtual Machine gehört außerdem zu einem der am besten gewarteten Open Source-Systeme im Linux-Bereich. Bugs und Probleme werden dank der gigantischen Open Source-Community schnell erkannt und behoben.

Einfache und schnelle Verwaltung von Proxmox

LXC und KVM decken unterschiedliche Einsatzbereiche ab. So virtualisiert KVM beispielsweise im Gegensatz zu LXC mit virtuellen Maschinen und nicht auf Betriebssystem-Ebene. Aus diesem Grund ist LXC viel flexibler und bietet die Möglichkeit, Applikationen und Nutzer Stacks in kürzester Zeit in Betreib zu nehmen sowie einzelne Prozesse und gesamte Prozessgruppen voneinander zu isolieren. Auf diese Weise lassen sich mehrere Linux-Systeme parallel auf einem Host-Betriebssystem betreiben, die voneinander getrennt und abgeschottet sind. Dadurch lässt die Hardware des Hostsystems wesentlich besser auslasten. Ähnlich wie die Konkurrenzprodukte Docker, VMware und Hyper-V ist LXC gleichermaßen gut bei der Virtualisierung einzelner Anwendungen einsetzbar.

Proxmox bot bis zu der Version 3.4 ausschließlich Unterstützung für OpenVZ als Container-Technologie. LXC kam erst mit der Version 4.0 hinzu. Gründe hierfür waren u. a. die bessere Unterstützung für Storage-Devices und ein optimiertes Storage-System für Linux-Container. So können Anwender zum Beispiel mit LXC ZFS Sub-Volumes nutzen, was sich mit OpenVZ nicht realisieren lässt. Hinzu kommt noch die Tatsache, dass die Netzwerk-Konfiguration bei Linux-Containern viel flexibler ist.

Ein dedizierter Server für das Management der Cluster, Virtual Machines oder der Container ist nicht notwendig. Jeder Proxmox-Host ist mit einem eigenen Webinterface ausgestattet, mit dem sich der gesamte Cluster von jedem Knoten aus schnell und unkompliziert verwalten lässt. Durch den Einsatz eines verteilten Dateisystems (Proxmox Cluster File System), können die Konfigurationsdateien auf alle Nodes (Hosts) im Cluster automatisch verteilt werden. Auf diese Weise wird für konsistente Verwaltungsinformationen auf mehreren Tausenden virtueller Maschinen gesorgt.

Virtualisierungsplattform für Linux-Enthusiasten

Promox bietet neben dem intuitiven Web-Interface auch eine API für Administratoren und Entwickler, sodass wiederkehrende Tasks ohne großen Aufwand per Skript automatisiert werden können. Clients stehen für folgende Programmier- bzw. Skriptsprachen zur Verfügung:

–       Python

–       Java

–       JavaScript (NodeJS)

–       PHP

–       Perl

Da sich die Virtualisierungsplattform mit den entsprechenden Programmier-Kenntnissen individuell an die eigenen Bedürfnisse der Nutzer anpassen lässt, wird ein äußerst flexibles Agieren ermöglicht.

Proxmox VE nutzt als Basis die Linux-Distribution Debian, sodass Anwender auf alle Funktionalitäten des Betriebssystems zugreifen können. Nutzer können grundsätzlich auch alle Pakete, die für das beliebte Debian entwickelt wurden, unter Proxmox installieren. Die Virtualisierungsplattform ist somit optimal an die Anforderungen von Administratoren zugeschnitten, die bereits über Linux-Erfahrungen verfügen. Proxmox ermöglicht ein ebenso interaktives Arbeiten wie mit Debian. Dank der riesigen Community steht außerdem viel Know-how zur Verfügung, sodass für viele Probleme, mit denen Anwender konfrontiert werden können, bereits eine Lösung existiert.

Hohe Verfügbarkeit von Proxmox

Da Debian als extrem sicher und stabil gilt, trägt es in wesentlichem Maße zu der Zuverlässigkeit der Virtualisierungssoftware bei. Die Proxmox Server Solutions GmbH ist der Verwalter des Projekts und ist direkt dafür zuständig, die Virtualisierungsplattform regelmäßig zu aktualisieren und sie dabei auch an neue Debian-Versionen anzupassen. Die Virtualisierungsplattform kann ebenfalls mit einer hohen Verfügbarkeit punkten. Der Proxmox VE HA Manager ist dafür zuständig, alle Knoten im Cluster kontinuierlich zu überwachen. Sobald einer dieser Knoten ausfällt, wird der Proxmox VE HA Manager aktiviert. Diese Funktionalität ist bereits bei der Standardinstallation von Proxmox VE bereits vorinstalliert, weswegen Anwender die Funktion lediglich an die eigenen Anforderungen und Bedürfnissen anpassen müssen.

Vielseitige Speichertypen für Proxmox

Proxmox VE ist extrem flexibel in Bezug auf den Speicher. Die Virtualisierungsplattform ist mit verschiedenen lokalen Speicher- und Netzwerkspeicher-Modulen versehen, was ebenfalls Debian zu verdanken ist. Alle Speichertypen, die von der Linux-Distribution unterstützt werden, können im Rahmen von Proxmox genutzt werden. Hierzu gehören:

–       Ceph

–       NFS

–       ISCSI

–       FibreChannnel

–       ZFS

Mithilfe der Shared Storage-Funktionalität lassen sich Abbilder der Vserver im lokalen Netzwerk ablegen. Die Virtualisierungsplattform ist außerdem mit einer Funktion zur Live-Migration versehen, sodass sich die erstellten Vserver ohne Ausfallzeit migrieren lassen.

Lange Jahre wurde die Architektur von Speicher ausschließlich durch die Parameter der Hardware bestimmt. Zumindest, was Größe, Zugriffsgeschwindigkeit und Cache anging. Dynamische Volumes und RAID-Verbünde waren ein erster Schritt, zu mehr Flexibilität. Software defined Storage (SDS) ist die konsequente Fortentwicklung dieses Ansatzes. Der Speicherplatz wird dabei von der Hardware abstrahiert. Dies erlaubt maximale Flexibilität und Skalierbarkeit.

Wie funktioniert die klassische Speicherung von Dateien?

Bis der physikalische Speicher dem Benutzer zum Ablegen seiner Daten angeboten wird, durchläuft er mehrere logische Bearbeitungsprozesse. Dies beginnt beim Controller der klassischen Festplatte. Dieser fasst Speicherbereiche zusammen und bietet sie dem Dateisystem in einer logischen Adressierung an. In Flashspeicher ist ebenfalls eine Abstraktionsschicht integriert, der Flash Translation Layer (FTL). Dieser übernimmt die Adressierung des vom Controller verwalteten Speichers.

Sowohl vom Betriebssystem, als auch auf Hardware-Ebene, können Verbünde erzeugt werden. Beispielsweise durch einen RAID-Controller, der den Speicher von zwei oder mehr Festplatten transparent zu einem großen Bereich zusammenfasst. Auch auf Software-Ebene ist dies möglich, indem beispielsweise unter Windows aus mehreren Festplatten ein dynamisches Laufwerk gebildet wird.

Auf den so zur Verfügung gestellten Speicher greift das Dateisystem zu und übernimmt die Partitionierung sowie Speicherung der Dateien.

Bezüglich der Schreib- und Lesegeschwindigkeit ist man bei diesen Methoden immer auf das „schwächste Glied“ im Verbund reduziert. Die Ablage der Dateien erfolgt zufällig. Auch ist der Austausch oder die Erweiterung der Komponenten nicht in jedem Fall möglich, ohne den gesamten Verbund neu aufzubauen. Ausnahme hiervon sind natürlich RAID-Verbünde, die speziell auf Redundanz ausgelegt sind, dafür aber eine homogene Hardware benötigen.

Wie funktioniert Software defined Storage?

Software defined Storage (SDS) übernimmt mehrere Aufgaben, die zuvor durch unterschiedliche Komponenten erledigt wurden. Er setzt an der Stelle an, wo der Speicher vom Controller logisch zur Verfügung gestellt wird. Er fasst die eingebundenen Komponenten zusammen und setzt sie dynamisch ein.

Dabei kann heterogene Hardware zum Einsatz kommen, ohne dass hierdurch die gesamte Performance beeinträchtigt wird. Vielmehr werden beispielsweise schnelle Speicher für eine Zwischenspeicherung verwendet. Die Daten werden dann zu weniger lastintensiven Zeiten auf andere Bereiche verteilt. Weiterhin ist das Dateisystem ein fester Bestandteil des Systems. So wird dafür gesorgt, dass Daten nicht doppelt abgelegt werden. Sind Dateien inhaltlich mehrfach vorhanden, speichert das Dateisystem sie nur einmal ab und legt Verweise auf den Inhalt an. Diesen Vorgang nennt man Deduplikation.

Auch das Anlegen von Snapshots und Backups wird durch Software defined Storage (SDS) gewährleistet. Die Datenablage erfolgt in redundanten Arrays. So kann Datenverlust bei Ausfall einzelner Komponenten verhindert oder vermindert werden.

Ein großer Vorteil ist die bereits angesprochene Skalierbarkeit. Es ist zu jedem Zeitpunkt möglich, Speicher zu ergänzen. Auch ein Austausch oder das Entfernen von Komponenten ist im laufenden Betrieb möglich.

Anwendungsfälle für Software defined Storage

Software defined Storage (SDS) bietet die flexible Basis für gemeinsam genutzten Speicherplatz in lokalen Netzwerkverbünden. Hauptsächlich dürfte dies für Firmennetzwerke interessant sein. Aus allen bereits vorhandenen Servern kann ein Software defined Storage (SDS) gebildet werden. Auf diesem können dann die notwendigen Dienste angeboten werden. Eine Möglichkeit ist beispielsweise die Nutzung des Speicherplatzes als Fileservers. Auch beliebige Serverdienste können darauf ausgeführt werden. Diese dürfen auch in einer virtualisierten Umgebung laufen. Das gesamte System ist nach der Einrichtung zentral administrierbar.

Was ist Ceph?

Ceph ist eine freie Variante des Software defined Storage (SDS). Sie wird unter GNU Lesser General Public License angeboten (LGPL). Ceph läuft unter Linux und wird von einem Konsortium verschiedener Hard- und Softwarehersteller entwickelt. Unter den Firmen befinden sich Canonical (Entwickler von Ubuntu-Linux), Cisco, Fujitsu, Intel, Red Hat, SanDisk und SuSE-Linux.

Die Software läuft auf handelsüblicher Hardware. Zur Speicherung wird ein Algorithmus mit Namen CRUSH verwendet. Dies steht für Controlled Replication Under scalable Hashing und setzt die Verteilung der Daten im System um. Die Komponenten im System werden Object Storage Nodes (OSDs) genannt. Es ist eine Redundanz der Daten vorgesehen, die dafür sorgt, dass ausgefallene Komponenten ohne Datenverlust ersetzt werden können. Die Software bringt mit CephFS ein eigenes Dateisystem mit.

Was ist Storage Spaces Direct?

Storage Spaces Direct (S2D) heißt der Software defined Storage (SDS) von Microsoft. Das System ist bereits in den Datacenter-Versionen von Windows Server 2016 und 2019 integriert. Es kann also relativ einfach verwendet werden, wenn die Infrastruktur auf diesen Betriebssystemen basiert. Die Flexibilität ist allerdings insofern eingeschränkt, als dass für jedes eingebundene Gerät eine Lizenz erforderlich ist.

Die Einrichtung von S2D erfolgt per PowerShell. Als Dateisystem kann das bekannte NTFS oder das für diesen Zweck optimierte ReFS zur Anwendung kommen. Bei ausreichend eingebundenen Komponenten liegt die Speichereffizienz bei bis zu 80 Prozent. Auch S2D bietet eine Wiederherstellung verlorener Dateien. Dies wird mit der Technik Local Reconstruction Codes (LRC) gewährleistet.

Weitere Anbieter von Software defined Storage

VMWare, der Spezialist für Virtualisierung, verwendet Software defined Storage (SDS) für seine Software vSAN, die Wiederherstellungssoftware Site Recovery Manager und sein Framework Virtual Volumes. Hierbei handelt es sich um ein kostenpflichtiges Angebot. Eine freie Alternative zu Ceph ist das Netzwerk-Dateisystem GlusterFS.

OpenStack Swift ist ein weiteres System zur Bereitstellung von Netzwerkspeicher aus verteilten Systemen. Es handelt sich dabei um Open-Source-Software, die also kostenfrei genutzt werden darf.

Gehört Software defined Storage die Zukunft?

Es sieht im Moment danach aus, dass Software defined Storage (SDS) das Konzept der Zukunft ist. Insbesondere gegenüber vorhandenen NAS- und SAN-Lösungen besticht es durch seine Flexibilität.  Man kann Hardware kann integrieren. Zuwächse in der Performance sind auch mit geringen Investitionen möglich. Zudem scheint der integrative Ansatz ein großer Vorteil bei der Administration zu sein. Backup-Strategien müssen beispielsweise nicht separat entworfen werden. Die Möglichkeit zur zentralen Administration ist ein grundsätzlicher Bestandteil der Technologie. Zudem sind keine Beschränkungen bei der Art der Nutzung des Speicherplatzes des Software defined Storage (SDS) gegeben. Somit harmoniert es beispielsweise gut mit dem Konzept der Virtualisierung von Systemen.

Ceph – was ist das? Viele Internetnutzer haben – in den meisten Fällen unbewusst – schon damit zu tun gehabt. Mit Ceph – einer Softwarelösung – können große Datenmengen einfach und günstig verarbeitet und auf standardisierter Industriehardware gespeichert werden. Ceph kommt zum Beispiel in Speichersystem von Webshops oder bei Anbietern von Onlinespeicher zur Anwendung.

Was ist Ceph?

Ceph ist eine nahezu endlos skalierende und hochverfügbare Softwarelösung zur verteilten Speicherung von Daten im Netzwerk. Die Software ist Open Source, basiert auf Linux und wurde für den Einsatz als Objekt-, Block- und Dateispeicher entwickelt. Das Gesamtsystem ist extrem robust und eignet sich für Datenmengen von wenigen hundert Gigabyte bis hin zu einigen Peta– und sogar Exabytes (1 Exabyte sind 1 Milliarde Gigabyte!).

Die Geschichte von Ceph

Ceph wurde als ein Projekt für die Doktorarbeit von Sage Weil an der University of California in Santa Cruz ins Leben gerufen. Die ersten Codezeilen wurden 2004 geschrieben und im Jahr 2005 gab es den ersten funktionierenden Prototypen von Ceph. Das System wurde 2006 durch Sage Weil bei zwei Konferenzen der Öffentlichkeit vorgestellt.

Weil arbeitete nach seiner Dissertation weiter am Projekt und gründete im Jahr 2012 die Firma Intank Storage, um das System auch professionell nutzen und vermarkten zu können. Kurz vorher, 2010, wurde der erste Ceph Client in den Linux-Kernel integriert. Intank Storage wurde 2014 von RedHat, einem Anbieter von professionellen Linux Systemen, gekauft und ist heute als „Red Hat Ceph Storage“ ein Bestandteil der Produktpalette von RedHat.

Unabhängig davon steht das Ceph-Projekt weiterhin als Open Source Software kostenfrei jedem zur Verfügung.

Wie funktioniert Ceph?

Ceph läuft als Software auf einem herkömmlichen Linux System. Mindestens drei, besser sind mehr als vier, Computer (Knoten oder englNodes) bilden ein Cluster. Lesen Sie hier mehr über Linux.

Ceph-Knoten

Storage-Knoten sind wichtig

 

Die wichtigsten Komponenten im Ceph Cluster sind die Storage Knoten. Sie sind verantwortlich für die Speicherung der Daten und verfügen daher im Regelfall über eine große Speicherkapazität. Die Festplatten und Disksysteme sollten im RAID-Verbund zur Verbesserung der Fehlertoleranz und Geschwindigkeit organisiert sein. Der Primary Storage Node entscheidet im Cluster über die Datenverteilung, Replikation und Recovery. Alle anderen Knoten stehen als Secondary Storage Node zur Überwachung zur Verfügung und können im Fehlerfall die Rolle des Primary Storage Nodes übernehmen.

Relevante Fehlertoleranz

Eine wichtige Funktion ist die Fehlertoleranz, sprich die Reaktion auf Ausfälle einzelner Komponenten des Gesamtsystems. Zu diesem Zweck tauschen die Knoten untereinander Informationen über den Zustand der Einzelsysteme aus und können so auf verschiedene Betriebszustände wie hohe Last, Ausfall eines Knotens oder Ähnliches reagieren. Die einzelnen Knoten haben dabei unterschiedliche Aufgaben und Wertigkeiten. Die Entscheidungsfindung bei Hardwarefehlern ist kompliziert und immer dem Ziel des maximalen Datenschutzes untergeordnet. Im Normalfall isoliert sich der fehlerhafte Knoten und der Betrieb geht mit den verbliebenen Knoten unterbrechungsfrei weiter. In sehr seltenen Fällen kommt der Cluster nach den vorgegebenen Regeln zur Entscheidungsfindung zu keinem Ergebnis oder die verbleibenden Knoten reichen nicht zur Sicherung der Fehlertoleranz aus. Anschließend schaltet sich das gesamte System im Sinne des Schutzes der Daten ab.

Ceph

Wie kommuniziert Ceph?

Die Kommunikation zwischen den Knoten und mit den Storage Clients erfolgt über das normale Netzwerk. Im Serverbereich wird heute zumeist die 10Gbit Technik eingesetzt, die einzelnen Server/Knoten können zur Erhöhung der Geschwindigkeit mit mehreren (gebündelten) Netzkarten versehen werden. Die Anbindung an das Netzwerk wird im Idealfall über mehrere Switcheredundant realisiert. Durch diese Maßnahme gibt es im Ceph Cluster keine zentrale Komponente, deren Fehler das Gesamtsystem zum Ausfall bringen könnte.

Welche Vorteile bietet Ceph?

Der große Vorteil von Ceph ist, dass der Anwender unabhängig von proprietären und teuren hardwarebasierten Storagesystemen großer Hersteller wird. Ceph läuft auf Standard-Hardware und kann unterschiedliche Systeme verschiedener Hersteller unter einen Hut bringen. Durch den Einsatz der Open Source Software und preisgünstiger standardisierter Hardware kann der Anwender Kosten in Höhe von 20% bis 50% gegenüber den Storagesystemen großer Hersteller einsparen.

Ein Ceph-Storagesystem ist sehr hoch skalierbar. Durch Hinzufügen von zusätzlichen Knoten und Festplatten lässt sich die Kapazität einfach und schnell erweitern. Neben der Kapazität kann man die Performance des Systems durch Zufügen von Hardware verbessern. Da Ceph verteilt arbeitet, gibt es keinen einzelnen Performance-Engpass (Flaschenhals oder englBottleneck), das System steuert die Lastverteilung auf die einzelnen Knoten selbst.

Durch das Hinzufügen weiterer Knoten lässt sich ebenso die Redundanz des Gesamtsystems steigern. Die intelligente Datenverteilung auf den Disksystemen und über die verschiedenen Knoten macht das System sehr robust. Hardwarefehler einzelner Bauteile oder Knoten kann der Cluster im Betrieb transparent überbrücken. Je nach Konfiguration der Regeln zur Datenverteilung über die Knoten ist der Ausfall mehrerer Knoten ohne Ausfall des gesamten Systems möglich.

Gibt es auch Nachteile?

Ceph-Nachteile

Nachteile von Ceph

Planung, Installation und Pflege eines Storagesystems mit Ceph stellen den Anwender vor große Herausforderungen. Er sollte mit Linux als Betriebssystem und der Software Ceph gut vertraut sein. Bei der Planung sind Kenntnisse im Bereich der StoragetechnologienRedundanzkonzepten und Netzwerk unerlässlich. Im Fehlerfall ist der Anwender auf Eigenhilfe oder die Unterstützung der Community angewiesen.

Der Kauf einer professionellen Variante (zum Beispiel von RedHat) bietet Vorteile bezüglich der Handhabbarkeit und vor allem beim professionellen Support durch den Hersteller, erhöht im Gegenzug allerdings die Kosten.

Wo wird Ceph eingesetzt?

Der Speicherbedarf im Internet und bei Unternehmen wächst beständig. Neue Anwendungen, Clouds, Social Media, Online Shops und Multimedia Dienste benötigen immer größere Speicherkapazitäten. Vorhandene Daten müssen per Backup gesichert und alte Daten archiviert werden, die Grenzen des Speicherwachstums sind momentan nicht absehbar. Dabei steigt vor allem der Bedarf nach kostengünstigen und einfach skalierbaren Speicherlösungen. In diesem Bereich spielt Ceph seine Stärken aus.

Es wird heute von Kunden aus verschiedenen Bereichen eingesetzt. E-Commerce Lösungen mit Magento oder Shopwarearbeiten mit Ceph im Hintergrund, Datenbanken profitieren von der enormen und skalierbaren Geschwindigkeit von Ceph. Viele Onlinedienste nutzen Ceph als Datenspeicher und schätzen dabei vor allem die geringen Kosten und die einfache Erweiterbarkeit.

In großen Rechenzentren kommen die Vorteile von Ceph zum Tragen. Hohe Redundanz und Geschwindigkeit werden mit der steigenden Anzahl von Knoten im Cluster besser nutzbar. In Virtualisierungsumgebungen wie KVM oder XEN ist neben den genannten Punkten die hohe Skalierbarkeit wichtig, um dem Wachstum der angeschlossenen Dienste gerecht zu werden.

Wenn man den neuesten Prognosen Glauben schenkt, so wird der Speicherplatzbedarf weltweit noch weiter zunehmen. Durch Big Data Analytics sowie unzählige Sensordaten, die zu jeder Zeit des Tages entstehen, lässt sich das Datenwachstum nicht mehr aufhalten.¹

Das Datenwachstum im Überblick

Das Datenwachstum im Überblick

Diese Entwicklung führt bei den meisten Unternehmen zu einem Problem. Sie müssen den eigenen Bedarf an Speicherplatz so gut wie möglich vorhersehen. Nur so können sie entsprechende Kapazitäten dort zur Verfügung stellen, wo sie dringend von Nöten sind. In den verschiedenen Bereichen steigt die Datenmenge auch unterschiedlich an. Des Weiteren sind sehr unterschiedliche Anforderungen an diese Daten gegeben. Eine einfache Erhöhung der Brutto-Speicherkapazität der Systeme reicht daher nicht mehr aus. Bestimmte Bereiche benötigen genau zur richtigen Zeit diese erhöhte Speicherkapazität.

Eine „Modernisierung“ ist Pflicht!

Beim Thema Datenwachstum denken viele Administratoren hauptsächlich darüber nach, wie sie es schaffen können, so viel Speicher wie möglich frei zu bekommen. Dies könnte durch die Ankopplung einer (weiteren) JBOD Erweiterung an den vorhandenen netzwerkgebundenen Speicher (NAS) geschehen. Schließlich ist dieses Vorgehen bis dato in vielen Bereichen das Standardverfahren.

Allerdings müssen die Ressourcen in einer zeitgemäßen IT-Infrastruktur flexibel bereit gestellt sein und vor allem auch genau dann, wenn sie von Nöten sind. Um diesen neuen Anforderungen zu entsprechen, sollte Sie die Speicherumgebung ab jetzt modernisieren.

Wer an dieser Stelle mit hohen Kosten rechnet, kann aber aufatmen. Die vorhandene Infrastruktur kann man durchaus weiter verwenden, falls sie noch nicht veraltet ist. Sie wird lediglich mit entsprechenden Technologien so flexibel und skalierbar wie möglich gemacht. Denn so wie sich die Geschäftsbereiche sehr schnell an sich ändernde Anforderungen anpassen, muss dies auch die Infrastruktur der IT tun. Mit Ceph ist die Umsetzung dieser Modernisierung einfacher umsetzbar.

Was ist Ceph?

Bei Ceph handelt es sich um eine verteilte Storage-Lösung. Gemeinsam mit RADOS (reliable autonomic distributed object store) ist Ceph ein Objektspeicher, der sich über eine beliebige Anzahl an Servern überreichlich verteilen lässt. Drei Arten von Speicher sind dem Nutzer hier geboten: Der Objektspeicher, der Blockspeicher und CephFS. Letzteres ist ein verteiltes Dateisystem. Kopien der Objekte werden hier gespeichert. Sollten Daten beschädigt sein, so kann Ceph diese durch die Kopien, die sich auf anderen Speichermedien befinden, wiederherstellen. So heilt es sich quasi selbst und kann einen Ausfall der verschiedenen Komponenten jederzeit auffangen.²

An anderer Stelle wurden die mit dieser Software-Defined-Storage-Lösung einhergehenden Herausforderungen schon rudimentär erklärt. In diesem Artikel wird nun genauer erläutert, mit welchen Möglichkeiten die Speichersysteme durch Ceph ideal genutzt werden können. Des Weiteren geht es hier auch darum, wie sich die Investitionskosten schnellstmöglich auszahlen.

Möchte man sein bestehendes RAID erweitern, so geht dies nur mühsam vonstatten. Und irgendwann kommt der Punkt, an dem keine zusätzlichen Erweiterungen mehr verwaltet werden können. Legt man zusätzlich auch noch Wert auf Markenprodukte, so kann eine Erweiterung recht teuer werden. Daher sollte man derartige Investitionen im Vorfeld gründlich überdenken. Ebenso sollte die vorhandene IT-Infrastruktur in dem Punkt hinterfragt werden, ob sie in ihrem momentanen Zustand noch für die Arbeitsweisen und Unternehmensziele passt.

Kosten durch intelligent verteilte Objekte minimieren

Ceph als Software-Defined-Straoge-Lösung ist bestens geeignet, um den Preis, der für ein GB ansteht, zu reduzieren. Dies geschieht zum einen durch das Einsetzen von commodity Hardware und zum anderen dadurch, dass teure SAS- oder SSD-Festplatten für eine gute Leistung nicht notwendig sind. Durch wenige, als I/O-Cache eingesetze, SSD-Festplatten erreicht man dennoch die benötigte Performance. Dazu werden diese SSD-Festplatten beispielsweise den SATA HDDs vorgeschalten, die um einiges langsamer, jedoch auch deutlich günstiger sind. Die Kosten für ein GB sinken und bei vielen Anwendungen ist hiermit schon ein gutes Preis-/Leistungsverhältnis erreicht.

Für die optimale Nutzung des Speichersystems gibt es jedoch einen Punkt, der noch viel wichtiger ist. Ceph hat die Möglichkeit verschiedene Pools zu erzeugen, die man wiederum verschiedenen Festplatten zuordnen kann. Diese Festplatten heißen in der Sprache von Ceph OSDs.Auf diese Weise kann der Administrator für unterschiedliche Anwendungsmöglichkeiten gezielt verschiedene Pools verwenden. Hierfür genügt ihm der Zugriff auf immer denselben Cluster, was dazu führt, dass der Aufwand für Administrationsarbeiten sinkt.

Ein konkretes Beispiel für die Kostensenkung

Für eine Datenbankanwendung würde so beispielsweise das Betreiben auf einem eher kleinen Pool nur mit SSDs ausreichen. Die Virtuelle Maschine nutzt hingegen nur SATA HDDs, vor die evtl. noch ein Cache geschalten ist. Die Virtuelle Maschine kann auf vglw. günstigem Speicher betrieben werden, da die  Leistung ihres Betriebssystems nicht sehr stark von den Zugriffszeiten abhängt. Die kostspieligen SSDs können also optimal für die Datenbanken genutzt werden.

Man kann also durch Pools sehr granulär entscheiden, welcher Typ I/O innerhalb eines Ceph Clusters welche Art Festplatte nutzt. Dass man hierbei alles innerhalb eines denkbar logischen Systems verwalten kann, ist im Gegensatz zu lokalen Speicherpools, bzw. unterschiedlichen NAS- oder SAN-Systemen der große Vorteil. Das Ceph Cluster System liegt hierbei über der vorhandenen Hardware. So ist es problemlos möglich, bei Bedarf die Kapazität zu erhöhen.

Außerdem ist es möglich, dass man nur einzelne Pools bei Bedarf durch passende Erweiterungen oder Festplatten erweitert. Dies kann man jederzeit kurzfristig und kostengünstig umsetzen. Auf diese Weise nutzt man den Speicherplatz dann und dort, wo man ihn benötigt und verschwendet seine Kapazität nicht über längere Zeiträume. Wurde zuvor zusätzlicher Speicherplatz benötigt und eingebunden, so kann dieser jederzeit problemlos an anderer Stelle eingesetzt werden. Hierfür ist kein physisches Eingreifen nötig und der laufende Betrieb wird nicht gestört.

Angepassten Replikationsraten sorgen für das Feintuning

Bei der Wahl eines passenden Level bei einem klassischen RAID, kommt es drauf an, welcher Anwendungszweck für dieses RAID angedacht ist. Ceph ermöglicht auch hier eine sehr individuelle und auch kurzfristige Entscheidung. Die Anzahl der anzulegenden Replikationen für jedes einzelne Objekt, definiert man, sobald man einen neuen Pool anlegt. Für ein Backup ist möglicherweise eine einfache Kopie eines unwichtigen Dokumentes ausreichend.

Wichtige geschäftliche Unterlagen sollten bei einem Backup jedoch evtl. mehrfach kopiert werden. Es ist außerdem möglich, den Speicherort für diese Kopien festzulegen. So ist beispielsweise die Speicherung auf einer anderen Festplatte oder sogar in einem anderen Brandabschnitt möglich. Auf diese Weise kann man Ceph noch idealer nutzen. Der Speicherplatz, der durch die einzelne Kopie der unwichtigen Unterlagen gespart wird, kann an anderer Stelle gewinnbringend eingesetzt werden.

Zusammenfassung

Ceph ist also ideal geeignet, wenn man trotz zu erwartendem Datenwachstum Kosten sparen möchte. Die bereits vorhandene Hardware kann man weiter nutzen. Bei eventuell anstehenden Neuanschaffungen muss man nicht auf teure Marken setzen. Durch die Möglichkeit, die unterschiedlichen Anwendungen mit ihren unterschiedlichen Geschwindigkeiten auf verschiedene Pools zu verteilen, sorgt für eine optimale Nutzung der Hardwareleistung.

Ebenso gewinnbringend ist die Möglichkeit, das Replikationslevel individuell festlegen zu können. Hierbei werden zusätzliche Kapazitäten frei, die an anderer Stelle sinnvoll eingesetzt werden können. Hohe Kosten für Markenprodukte entfallen. Der Administrationsaufwand reduziert sich dadurch, dass man sich statt auf viele verschiedene Speichersysteme, nur noch auf ein einzelnes stützt. Wenn man das Ceph Cluster optimal auf sein Unternehmen und dessen spezifische Anwendungen anpasst, erhält man einen sehr guten ROI in vielen Bereichen. Deshalb lohnt es sich, einmal über die Anschaffung eines solchen modernen Speichersystems Gedanken zu machen. Denken Sie an das unvermeidbare Datenwachstum.

Verweise:

1. https://www.storage-insider.de/weltweite-datenmenge-soll-sich-bis-2020-verzehnfachen-a-442411/  letzter Aufruf 03.12.2017.
2. https://de.wikipedia.org/wiki/Ceph letzter Aufruf 03.12.2017

vgl. https://www.eetimes.com/author.asp?section_id=36&doc_id=1330462 letzter Aufruf 03.12.2017
vgl. http://ceph.com/geen-categorie/how-data-is-stored-in-ceph-cluster/ letzter Aufruf, 03.12.2017
vgl. http://docs.ceph.com/docs/jewel/ letzter Aufruf 03.12.2017.

Warum das richtige Netzwerk bei Ceph so wichtig ist

Vor der Integration eines Ceph storage-clusters steht jeder Linux-Administrator irgendwann vor der Frage, welches Netzwerk (Ethernet, Infiniband, Omnipath) er verwenden möchte. Das hängt zunächst selbstverständlich vom zu erwartenden Workload und der Anzahl der Clients ab. Allerdings gibt es noch einen wichtigen weiteren Faktor den es zu beachten gibt. Ceph nutzt viele unabhängige Festplatten. RAID Arrays bieten sich nicht an, da die Performance mit  jeder zusätzlichen Festplatte wunderbar linear skaliert. Die vielen einzelnen Festplatten sowie der Aufbau des Ceph Clusters bringen es mit sich, dass alle Datenblöcke auf mehrere Knoten verteilt werden müssen. Je nach implementiertem Regelwerk sogar über Racks oder Rechenzentren hinweg. Das schafft Ausfallsicherheit. Jedoch bedeutet das, dass bei jedem Lese- oder Schreibzugriff eine Kommunikation mit allen Ceph-Nodes über das Netzwerk stattfinden muss, um alle notwendigen Datenblöcke zu erreichen.

Festplattenzugriff = Netzwerkzugriff bei Ceph

Da also jeder Zugriff auf eine der vorhandenen Festplatten auch ein Netzwerkzugriff ist, sollte man unbedingt auf ein 10 GE Netzwerk zurückgreifen um alle Ceph Knoten untereinander zu verbinden. 10 GE stellt hierbei das absolute Minimum dar. Möchten Sie Ceph richtig im produktiven Betrieb mit mehreren clients einsetzen, kommt ein 1 GE Netzwerk wirklich extrem schnell an seine Grenzen. Hier ist nicht nur der Datenverkehr zu den Clients und zwischen den Ceph Knoten bei der konkreten Datenabfrage zu betrachten. Ceph muss schließlich auch alle Replikationen auf den vorhandenen Servern und Festplatten des Clusters verteilen. Im besonderen wenn eine der Festplatten oder ein ganzer Server ausfällt, repliziert Ceph automatisch die Daten bis wieder die gewünschte Anzahl an Repliken vorliegt.

Netzwerkoptimierung

Dieses Verhalten kann durch getrennte Netzwerke optimiert werden. Ein Netzwerk übernimmt dann die Kommunikation zu den clients. Das zweite Netzwerk ist ausschließlich für die OSD Replikationen zuständig.

Die Konfiguration

Um zwei separate Netzwerke zu nutzen, müssen die Netzwerke innerhalb der ceph.conf eingetragen werden. Hierzu genügt es bereits die Netz ID mit entsprechendem Prefix anzugeben.

[global]

public network = 172.10.10.0/24

cluster network = 172.10.11.0/24

Sobald die Ceph Konfiguration auf allen Knoten verteilt wurde und die Services neu gestartet sind, werden die Netzwerke entsprechend verwendet. Damit wurde ein möglicher Flaschenhals in der Architektur  des Clusters optimiert bzw. verhindert.

Datenwachstum als Herausforderung der IT

Das stetige Wachstum der Datenmengen ist ein Problem, dem sich jede IT-Abteilung früher oder später stellen muss. Nutzen Sie ausschließlich klassische Speicherlösungen wie SAN oder NAS müssen die zur Verfügung stehenden Kapazitäten irgendwann mühsam erweitert werden. Eine solche Maßnahme hat des öfteren auch eine kurze downtime zur Folge, da nicht jede Erweiterung im laufenden Betrieb möglich ist.

Damit stellt sich bereits ein weiteres großes Problem ein. Kunden erwarten heutzutage, dass IT-Services zu 100 % an jedem Tag und zu jeder Stunde verfügbar sind. Downtimes werden immer weniger toleriert, besonders im Bereich von Rechenzentren sowie des Hostings. Eine mögliche Lösung um diese Zeiten zu minimieren oder gar völlig auszuschließen bietet beispielsweise Software Defined Storage oder kurz SDS.

Ceph geht neue Wege

Ceph Architektur

Abbildung 1
Ceph Architektur

Schwierigkeiten bei Software Defined Storage

CEPH ist aber keineswegs perfekt und bringt selbstverständlich auch Nachteile mit sich. Ein Merkmal mit dem man sich vor der Inbetriebnahme auseinandersetzen muss, sind die Latenzen die SDS im Vergleich zu Direct Attached Storage (DAS) mit sich bringt. Die erhöhte Komplexität des Software Stacks in Kombination mit den verwendeten Netzwerkverbindungen erhöhen die Latenz pro IO signifikant.

Es erweist sich als äußerst schwierig die Latenz unter den Wert von einigen Millisekunden für Schreibvorgänge zu senken. Woher diese Latenz kommt lässt sich verdeutlichen, wenn man sich die Arbeitsweise von CEPH bei Schreibvorgängen etwas genauer betrachtet (Abbildung 2).

Ein synchroner IO muss vom Client zur primären OSD gesendet werden. Die primäre OSD schickt anschließend die Anzahl konfigurierter Replikationen zu weiteren OSD’s und deren Journalen. Sobald die Repliken auf den Journalen aller OSD’s vorliegen, wird der Vorgang an die primäre OSD bestätigt. Hat die primäre OSD nun alle Bestätigungen erhalten, wird eine Bestätigung an den Client gesendet und dieser kann den nächsten IO senden. Das verdeutlicht schon weshalb es bereits zu Latenzen innerhalb des Software Stacks kommt.

SDS mit Ceph - Arhcitektur

Abbildung 2

Zusätzlich spielt auch das eingesetzte Netzwerk bei Ceph eine entscheidende Rolle. Es gilt hier zunächst unnötige Hops zu vermeiden, da jeder Hop etwa 200us Latenz mit sich bringt. Ein 10GE Netzwerk gilt hierbei als das absolute Minimum, welches Sie beim Einsatz von Ceph oder einem anderen verteilten Speichersystem verwenden sollten. Das verringert Latenzen und erhöht die Bandbreite. Eine zusätzliche Verbesserung bringt Ihnen selbstverständlich der Einsatz von RDMA, jedoch müssen hier die Kosten beachtet werden. All diese Faktoren spielen eine wichtige Rolle und müssen optimiert werden um Latenzen unter dem 2ms Level zu erhalten und dabei eine Balance zwischen Kosten und Nutzen zu finden, was natürlich nicht immer einfach ist.

 

Anforderungen an eine gute SDS Lösung

Damit Sie nach der Einführung einer SDS Lösung wie Ceph nicht enttäuscht sind, gibt es einige Punkte zu beachten. SSDs oder (Enterprise SSD oder NVME SSD) für die Journale, in denen die Schreibvorgänge gecached werden, sowie ein 10GE Netzwerk sind nach herrschender Meinung innerhalb der Ceph Community und unseren eigenen Erfahrungen ein Muss. Für die OSD’s sollten nach Möglichkeiten SAS3 HDD’s verwendet werden. Es ist auch denkbar bei Bedarf einen Teil der OSD’s rein aus SSDs zu erstellen und gesondert zur Verfügung zu stellen. Wichtig ist zudem keine RAID Arrays zu verwenden. Ceph profitiert stark von vielen unabhängigen Festplatten. Einem schwerwiegenden Datenverlust entgehen Sie zudem indem Sie mehrere Server mit möglichst vielen Festplatten (OSD’s) bereitstellen

Die CPU sollte möglichst viele Prozessor-Kerne haben, und der Arbeitsspeicher mit etwa 1-2 GB pro OSD berechnet werden um hier keinen Flaschenhals zu generieren. Der Einsatz von RDMA muss wohl überlegt sein und kommt auf den speziellen Workload an. Werden extrem niedrige Latenzen und hohe Bandbreite über 10 GE benötigt bietet es sich eventuell eher an auf ein spezielles Storage System wie GPFS, BeeGFS oder Lustre  in Kombination mit Infiniband/Omnipath zu setzen.

Fazit zu Ceph

Zusammenfassend lässt sich sagen, dass Software Defined Storage definitiv eine gute Möglichkeit darstellt, um stetig wachsende Datenbestände einfacher zu verwalten. Jedoch hat Software Defined Storage genau wie jede andere Lösung gewisse Einschränkungen denen man sich bewusst sein muss. Im modernen IT-Betrieb wird man aber nicht auf SDS verzichten können. Die mitgebrachten Vorteile wie Skalierbarkeit, einfache Erweiterung und eine sehr hohe Verfügbarkeit werden zunehmend wichtiger.

Weiterführende Links zum Thema:

Howtos

Ceph deep scrub error beheben

Wer Ceph produktiv betreibt, wird im Laufe der Zeit immer mal wieder einen „unhealthy“ Zustand des Clusters erleben. Solange es sich dabei um eine noch harmlose „Ceph Warning“ geht, ist der gesunde Zustand des Clusters oft schnell wieder erreicht. Oft sogar ganz von alleine ohne ein Zutun des Linux-Administrators.

Doch was tun wenn „plötzlich“ ein echter Fehler auftritt? Mit „ceph health detail“ erfahren wir auf einen Blick, was das Cluster macht. In unserem konkreten Fall war Ceph ohne Vorwarnung auf unserem frisch installierten Proxmox Cluster in einen „Health Error“ gewechselt.

root@pve02:/var/log/ceph# ceph health detail
HEALTH_ERR 129254/2436848 objects misplaced (5.304%); 1 scrub errors; Possible data damage: 1 pg inconsistent
OBJECT_MISPLACED 129254/2436848 objects misplaced (5.304%)
OSD_SCRUB_ERRORS 1 scrub errors
PG_DAMAGED Possible data damage: 1 pg inconsistent
pg 4.41 is active+remapped+inconsistent+backfill_wait, acting [0,10]

In Folge einer neu eingebauten Platte ergaben sich eine überschaubare Menge (5,3%) von Placement Groups (pg), die nun nicht mehr richtig verteilt waren. In einer normalen Ceph Umgebung wäre das Thema in wenigen Stunden von alleine erledigt gewesen.

Im konkreten Fall haben wir aber eine Placement Group, die ein echtes Problem hat: PG 4.41.

Diese PG liegt sowohl auf OSD.0 als auch OSD.10 – zu erkennen an [0,10] -> hier werden die OSD Nummern aufgelistet.

Ceph deep scrub error analysieren

Um das Problem genauer zu analysieren loggen wir uns also per ssh auf den jeweiligen ceph hosts an auf  denen die osds liegen bzw. die OSD-Prozesse laufen. Pro Ceph-OSD liegt unter /var/log/ceph ein einzelnes Log-File. Wir schauen uns nun genau das Logfile des OSD-Prozesses an, der von Ceph selbst in der obigen Meldung ausgegeben wird.

Pve02# cd /var/log/ceph
(host mit osd.10)
cat ceph-osd.0.log | grep -i 4.41
-> viel output -> suche nach „error“ oder „fail“
=> kein Ergebnis

Da der erste Host keinen Fehler anzeigt, muss also die andere potentielle OSD, auf der die Placement Group liegt, ein Problem haben. Wie loggen uns also auf dem Host ein  auf dem die OSD.0 liegt

root@pve01# cd /var/log/ceph
root@pve01:/var/log/ceph# cat ceph-osd.10.log | grep -i 4.41
(…)
2018-06-21 20:05:48.793010 7fc78b0f3700  0 log_channel(cluster) log [DBG] : 4.41 deep-scrub starts
2018-06-21 20:06:23.380373 7fc78b0f3700 -1 log_channel(cluster) log [ERR] : 4.41 shard 0: soid 4:823a7476:::rbd_data.2862f74b0dc51.0000000000006060:head candidate had a read error <== Hier beginnt das Problem
2018-06-21 20:07:04.032674 7fc78b0f3700 -1 log_channel(cluster) log [ERR] : 4.41 deep-scrub 0 missing, 1 inconsistent objects
2018-06-21 20:07:04.032681 7fc78b0f3700 -1 log_channel(cluster) log [ERR] : 4.41 deep-scrub 1 errors
2018-06-21 20:18:38.424228 7fc7830e3700  4 rocksdb: (Original Log Time 2018/06/21-20:18:38.424147) [/home/builder/source/ceph-12.2.5/src/rocksdb/db/memtable_list.cc:383] [default] Level-0 commit table #451: memtable #1 done

Dem Logfile nach liegt also auf der OSD.10 vermutlich das Problem.

 

Lösungsansatz zur Behebung des Deep Scrub Error

Wir entfernen temporär die OSD.10 aus dem Cluster und „zwingen“ Ceph die Placement Groups neu zu verteilen. Die Lösung dabei ist höchst einfach:

Befehl: ceph osd out osd.<OSD_ID>

 

root@pve01:/var/log/ceph# ceph osd out osd.10
root@pve01:/var/log/ceph# ceph osd df
ID CLASS WEIGHT  REWEIGHT SIZE   USE   AVAIL  %USE  VAR  PGS
8   hdd 1.81929  1.00000  1862G  485G  1377G 26.05 0.80  51
9   hdd 1.81929  1.00000  1862G  677G  1185G 36.38 1.12  72
10   hdd 1.63730        0      0     0      0     0    0  52
11   hdd 1.63730  1.00000  1676G  534G  1142G 31.86 0.98  57
12   hdd 1.81929  1.00000  1862G  479G  1383G 25.76 0.79  51

 

Nun ist die OSD 10 ist raus und 52 Placement Groups müssen verschoben bzw. neu auf die restlichen Platten verteilt werden. Mit „ceph –w“ können wir den laufenden Status des Ceph Clusters permanent überwachen. Dort kann man nach einigen Minuten auch anhand der sich verkleinernden Prozentzahl hochrechnen, wie lange der Umverteilungs-Vorgang noch dauern wird.

Weitere Infos zum Deep Scrub Error