© Artem Egorov,123RF

Zwar finden sich in vielen Unternehmen auch heute noch klassische NAS- und SAN-Appliances, doch im Kontext von Container-Umgebungen übernehmen Software Defined Storage und hyperkonvergente Speicherarchitekturen langsam die Regie. Das Linux-Magazin zeigt, welche Storage-Systeme sich für welche Einsatzzwecke eignen.

Karl Valentin postulierte einst, heute sei die gute alte Zeit von morgen. Gar nicht so wenige Menschen meinen entsprechend, früher sei Vieles besser gewesen. Ob das stimmt, sei dahingestellt – Fakt ist aber: Im Kontext von IT-Infrastruktur waren früher viele Dinge zumindest einfacher.

Virtualisierung hat die Industrie in gleich mehreren Wellen umgewälzt: Erst traten virtuelle Maschinen auf den Plan, die aus schneller Hardware viele virtuelle Systeme machten. Die Cloud erweiterte das Thema Virtualisierung um den Aspekt der Automation und der Selbstbedienung: Nicht mehr länger sollten Admins damit beschäftigt sein, Storage-Volumes anzulegen und Netze auf Switches zu konfigurieren, damit Kunden Compute-Ressourcen nutzen konnten. Im Fahrwasser der Cloud stellte die Container-Virtualisierung dann nochmals vieles auf den Kopf: Container brauchen weniger Ressourcen, vor allem ermöglichen sie aber komplexe Prozesse für Continuous Integration und Continuous Delivery viel eleganter als Vollvirtualisierung.

Zudem verändert jeder große Umbruch in der IT die Infrastruktur, die für den Betrieb der jeweiligen Geräte notwendig ist. An manchen Stellen erschließt sich das ganz von allein: Server wurden in den vergangenen Jahren immer leistungsstärker, daher brauchen Racks heute viel mehr Strom als früher. Andere Änderungen erschließen sich hingegen nicht so schnell – etwa die Frage nach der richtigen Art und Weise, Speicher im Rechenzentrum zu implementieren. Hier bekommt der Admin es gleich mit zwei verschiedenen Problemfeldern zu tun: Einerseits stellt sich die Frage nach der Architektur des Speichers, also der Art und Weise, wie dieser konstruiert sein soll. In der Vergangenheit hat man bevorzugt auf SAN- und NAS-Geräte gesetzt, heute erfreut sich Software Defined Storage zunehmender Beliebtheit.

Die Frage nach dem Gerät oder der Architektur des Speichers geht Hand in Hand mit der Frage nach dem Protokoll, über das man auf die Daten zugreift. Manche Szenarien bedingen den Zugriff auf Blockspeichergeräte, in anderen Umgebungen wiederum spielt der Zugriff über Dateisysteme eine herausgehobene Rolle. Nicht zu vergessen ist mittlerweile auch der Zugriff auf Objektspeicher, etwa über Amazons S3-Protokoll. Für den Admin ergibt sich daraus eine schwierige Aufgabe: Welcher Speicher passt ideal zu einem Setup? Der folgende Artikel gibt eine Übersicht über aktuelle Optionen und geht auf die Nützlichkeit für verschiedene Einsatzszenarien ein.

Eine Frage der Hardware

Wenn Admins heute neue Setups planen, sehen sie sich mehreren Storage-Optionen gegenüber. Den klassischen Ansatz bilden NAS- und SAN-Geräte. Sie existieren seit Jahrzehnten und gelten bis heute als sichere Bank. Entsprechende Systeme gibt es von diversen Herstellern, darunter Dell-EMC (Abbildung 1), NetApp und Huawei.

Abbildung 1: Klassischer Storage wie SAN-Geräte (hier von Dell-EMC) … Quelle: Dell-EMC

Klassische SANs setzen noch immer auf ein eigenes Netzwerk für den Zugriff; hier hat sich bis heute FibreChannel als regelmäßig genutzte Option erhalten. Zugriffsmöglichkeiten bieten klassische SAN- und NAS-Speicher (Abbildung 2) über eine Vielzahl von Protokollen: Bei SANs ist iSCSI weit verbreitet, das den Zugriff auf Volumes via Blockmethode ermöglicht. NAS-Systeme setzen eher auf Netzwerkdateisysteme wie NFS oder CIFS. Aber auch SAN-Geräte lassen sich per Dateisystem ansprechen, und viele NAS-Geräte beherrschen iSCSI, setzen dabei aber auf Ethernet. Im Hinblick auf ihren Funktionsumfang ähneln sich SAN- und NAS-Geräte also weitgehend.

Abbildung 2: … oder NAS-Geräte (wie hier von Qnap) eignen sich für Setups, in denen Skalierbarkeit in die Breite keine Rolle spielt. Quelle: Qnap

Der signifikante Nachteil solcher Komponenten: Sie ketten die Nutzer an den jeweiligen Hersteller. Ersatzteile sind oft nur für horrende Summen zu bekommen, ähnliches gilt für Erweiterungskomponenten. Das erscheint umso bizarrer, als es sich bei den Festplatten, RAM-Riegeln und anderen Bauteilen der gängigen Storages um Hardware von der Stange handelt, die der Anbieter meist lediglich mit einem Aufkleber oder einer anderen Firmware versieht.

Je nach Szenario bieten SAN- und NAS-Geräte zudem keine echte Skalierbarkeit in die Breite. Ob das ein Problem ist, hängt auch vom Setup ab: Wer eine Cloud baut, will sich beim Speicher nicht künstlich limitieren. Baut man stattdessen eine Lösung, deren Dimensionen im Vorfeld klar definiert sind, spielt die Skalierbarkeit des Speichers eine untergeordnete Rolle.

Das Fazit für SAN- und NAS-Geräte fällt insofern gemischt aus. Sie bieten diverse Zugriffsmöglichkeiten und sind heute oft in der Anschaffung auch nicht mehr so teuer wie noch vor ein paar Jahren. Im Gegenzug zwingen sie den Betreiber in die Abhängigkeit von einem bestimmten Anbieter und bieten nur begrenzte Möglichkeiten des Skalierens. Für wachsende Setups eignen sich die Geräte also eher nicht. Sie finden ihren Platz eher in konventionellen Umgebungen, in denen traditionelle Zugriffsmethoden wie iSCSI, NFS oder CIFS dominieren.

Das Modell der Zukunft: skalierbare Objektspeicher

Das Linux-Magazin hat in den vergangenen Jahren immer wieder über skalierbare Object-Stores geredet, und oft genug ging es dabei um Ceph. Objektspeicher sind im Storage-Kontext so etwas wie die Wachablösung für konventionelle NAS- und SAN-Geräte. Sie bedienen nicht nur ein anderes Kundensegment, sondern funktionieren unter der Haube auch völlig anders.

Erfunden wurden sie eigentlich, um die Skalierbarkeitsprobleme konventioneller Speicherlösungen zu umgehen. Klassische Storage-Systeme skalieren letztlich nur bis zu einem bestimmten Grad und nur in die Höhe. Oft besteht die Möglichkeit, weitere Festplatten einzubauen oder zusätzliche JBOD-Gehäuse anzuschließen. Doch bei jedem SAN- oder NAS-Gerät kommt irgendwann der Punkt, an dem sich der Instanz kein weiterer Plattenplatz mehr hinzufügen lässt. Dann braucht man eine zweite Kiste, was nicht nur den Vorteil der zentralen Administrierbarkeit zunichte macht, sondern auch weiteres Geld verschlingt.

Objektspeicher folgen einem anderen Prinzip. Sie ziehen eine Abstrahierungsschicht zwischen der tatsächlichen Hardware und dem Frontend ein, auf das Clients zugreifen. Wie es hinter dieser Abstrahierungsschicht aussieht, braucht den Client dabei nicht zu interessieren. Der Objektspeicher nutzt die Zwischenschicht jedoch, um im Hintergrund nahezu beliebig viele Blockspeichergeräte anzusprechen.

Der Objektspeicher Ceph etwa versteht sich auf den Umgang mit über 270 Millionen Festplatten in einer einzelnen Instanz – ein schier unvorstellbarer Wert. Dass jemand einen so großen Ceph-Cluster schon einmal im echten Leben gebaut hat, darf man bezweifeln. Die horrend große Zahl macht trotzdem deutlich, dass Objektspeicher wie Ceph sich für skalierbare Umgebungen wie Clouds oder große Virtualisierungsflotten besser eignen als typische SAN- oder NAS-Geräte.

Hardware von der Stange

Auch in anderer Hinsicht haben Objektspeicher Vorteile. So gut wie alle relevanten Objektspeicherimplementierungen setzen auf Hardware von der Stange. Startet der Admin also jetzt mit einem Objektspeicher und braucht später mehr Platz, ist er nicht an einen bestimmten Hersteller gebunden. Dass die erste Charge von Dell kam, heißt nicht, dass die zweite nicht von HP oder IBM kommen kann. Solange sich die Software auf den Systemen betreiben lässt, ist der Aufkleber auf dem Gerät komplett egal.

Das eröffnet bei Ceph-Clustern auch eine Option, die sich bei NAS- oder SAN-Storage so nicht ohne Weiteres ergibt. Letztere kommen üblicherweise mit einem Ablaufdatum daher, meist in Form des Auslaufens der Herstellergarantie. Nach fünf Jahren ist in den meisten Fällen Schluss; dann steht dem Admin eine aufwendige Migration inklusive einer Downtime ins Haus. Bei Objektspeichern ist das anders.

Weil sich die nutzbare Hardware hier beliebig miteinander kombinieren lässt, entfernen Admins einzelne Knoten bei Bedarf aus der Installation und ersetzen sie durch neue. Der Prozess unterscheidet sich technisch vom Skalieren in die Breite nur insofern, dass bei Letzterem das vorherige Entfernen der alten Platten nicht stattfindet. Nach fünf Jahren lassen sich die Knoten eines Clusters dadurch zur Gänze ersetzen, aber ohne Downtime und ohne allzu viel administrativen Aufwand. Admins gefällt das naturgemäß.

Komplexere Handhabung

Die Objektspeicher-Medaille hat aber auch eine Kehrseite. Der aus Sicht des Admins deutlichste Nachteil: Die Administration und das Setup von Objektspeichern geraten deutlich komplexer als bei konventionellen Storages. Ein SAN- oder NAS-Gerät wird vom Hersteller in der Regel vorkonfiguriert geliefert. Der Administrator installiert es in seiner Infrastruktur und hat anschließend üblicherweise Zugriff auf ein grafisches Konfigurationswerkzeug (Abbildung 3), mit dem er die Einrichtung erledigt. Weil alle Komponenten vom selben Hersteller kommen und auf hohen Nutzungskomfort ausgelegt sind, geht der gesamte Prozess einfach von der Hand.

Abbildung 3: SAN- und NAS-Appliances kommen mit GUIs daher, die die Einrichtung erleichtern. Objektspeichern fehlt so etwas. Quelle: Huawei

Das ist bei Objektspeichern üblicherweise nicht so: Einen Ceph-Cluster kann man bei Dell, HP oder anderen Anbietern bis heute schlechterdings nicht fertig kaufen. Zwar gibt es mittlerweile mehr als genug Firmen, die Ceph auf Kundenwunsch als Dienstleistung installieren. Eine zusätzliche Ebene Komplexität und Aufwand bedeutet das aber trotzdem, zumal der Admin einiges beachten muss, wenn er mit Objektspeichern loslegen will. Bei Ceph spielt etwa schon die Topologie der Hardware eine Rolle. Kommen unterschiedlich große Platten zum Einsatz, möchte man diese auf der Ceph-Ebene unter Umständen unterschiedlichen Speicher-Silos zuweisen. Obendrein lassen sich in Ceph HDDs und SSDs zwar problemlos kombinieren, das muss der Admin aber einrichten.

Der ganze Setup-Prozess von Objektspeichern gestaltet sich sehr viel komplexer als bei konventionellen Storages. So muss sich der Admin erst einmal darum kümmern, dass sie ein Betriebssystem erhalten. Nach dessen Installation ist die Software für den Objektspeicher selbst an der Reihe. Um das Setup wartbar zu halten, sollte zumindest dieser Teil der Arbeit automatisiert erfolgen. Damit hat der Admin dann Werkzeuge wie Ceph-ansible an der Backe, die er erst einmal verstehen muss: Die Konfiguration, die Ceph-ansible nutzt, um Ceph auszurollen, kann leicht mehrere Bildschirmseiten umfassen. Es gibt auch kein grafisches Tool samt Installer, das dem Administrator die Bürde der Installation abnimmt. Dieselben oder ähnliche Probleme stellen sich bei anderen Lösungen ebenfalls ein. Plug & Play, wie es bei SAN und NAS mittlerweile üblich ist, funktioniert bei Objektspeichern jedenfalls nicht.

Hat der Admin einen Objektspeicher erst einmal aufgesetzt, gestaltet sich auch dessen Betrieb viel komplexer als der klassischer Storages. Monitoring, Alerting und Trending (Abbildung 4) sind von essenzieller Bedeutung. Schließlich möchte der Admin wissen, wenn mal etwas nicht passt oder wenn er Hardware zum Skalieren in die Breite nachstecken muss. Anders als bei konventionellen Storages hat der Admin es hier aber eben nicht mit einem Gerät zu tun, sondern im einfachsten Fall mit dreien. Wächst der Cluster, wächst auch die Anzahl der zu überwachenden Knoten.

Abbildung 4: Objektspeicher sind deutlich komplizierter in der Installation, im Betrieb und in der Wartung als SAN- oder NAS-Geräte. Quelle: Inktank

Frontends nach Wunsch, noch mehr Komplexität

Je nach genutztem Objektspeicher ergeben sich verschiedene Varianten für den Zugriff darauf. OpenStack Swift etwa spricht sein natives Protokoll, lässt sich per Plugin aber auch um S3-Funktionalität erweitern. Bei Minio handelt es sich um einen reinen S3-Nachbau, der nur den Zugriff per S3-Client ermöglicht. GlusterFS ist zwar kein Objektspeicher, fällt jedoch trotzdem in die Kategorie der skalierbaren Speicherlösungen und bietet Zugriff über ein eigenes Protokoll.

Am breitesten aufgestellt ist Ceph: Dessen Objektspeicher RADOS lässt sich von Clients als Blockspeichergerät, als Dateisystem (CephFS) sowie über das Ceph Object Gateway auch als S3-Speicher ansprechen. Auch hier steigt jedoch die Komplexität noch einmal, wenn der Admin alle verfügbaren Frontends tatsächlich nutzen möchte. Das Ceph Object Gateway bedingt ebenso wie CephFS nämlich eigene Dienste, die es als Teil des Ceph-Clusters auszurollen gilt.

Objektspeicher sind toll, aber komplex

Objektspeicher haben die Rangordnung der Storage-Systeme im Rechenzentrum in den letzten Jahren gehörig durcheinandergebracht. Sie eignen sich besonders für Setups, die mit unkalkulierbaren Platzbedürfnissen einhergehen oder bei denen sich Admins nicht an bestimmte Hardware-Hersteller binden wollen.

Planung, Installation und Betrieb von Objektspeichern sind merklich aufwendiger als bei konventionellen Lösungen. Dafür lassen sich universelle Objektspeicher – allen voran Ceph – mit allen Frontends nutzen, die auch SAN- oder NAS-Geräte unterstützen.

Dem Admin muss jedoch klar sein, dass Objektspeicher sich nicht ohne Weiteres ausrollen und in Betrieb nehmen lassen. Sie setzen ein tiefes Verständnis der Materie voraus und bedingen meist erheblichen Lernaufwand – nicht nur beim Admin, der das Setup plant und umsetzt, sondern auch bei jenen, die das Setup später betreiben.

Das Thema Hyperkonvergenz

Eine Frage, die sich nur im Kontext von Objektspeichern und ähnlichen Lösungen überhaupt stellt, ist die Frage nach der Hyperkonvergenz von Storage. Damit ist gemeint, dass die Komponenten einer Software-Defined-Storage-Lösung wie Ceph auf denselben Servern laufen, auf denen beispielsweise auch virtuelle Maschinen ihr Zuhause haben.

Aus Sicht des Admins wirkt das im ersten Moment verlockend, denn die Hardware für die Compute-Systeme muss er ohnehin anschaffen. Steckt er in die jeweiligen Server einfach noch ein paar große Festplatten, bieten diese auch den nötigen Speicher an. Vielleicht übt diese Option auf viele Admins eine fast schon magische Anziehungskraft aus, weil sie sich überhaupt erst mit Software Defined Storage umsetzen lässt. Bei SAN- und NAS-Geräten ist von vornherein klar, dass separate Hardware ins Rack kommt.

Das Thema Hyperkonvergenz ist allerdings mit Vorsicht zu betrachten. Sämtliche Lösungen für Software Defined Storage implementieren Funktionen wie Replikation und das automatische Wiederherstellen von verlorenen Replikas, falls einzelne Komponenten des Clusters den Geist aufgeben. Fällt ein Knoten mit 50 oder 60 Terabyte Bruttokapazität aus einem Ceph-Cluster aus, müssen die verbliebenen Knoten im Hintergrund dafür sorgen, alle nun fehlenden Replikas binärer Objekte wieder herzustellen. Bei Ceph ist das eine sehr CPU-intensive Aufgabe. Sie frisst auch reichlich RAM, und nicht zuletzt pustet ein Ceph-Cluster während der Resynchronisation das Netzwerk ordentlich durch – falls SSDs im Spiel sind, auch 25- und 50-Gbit/s-Uplinks.

Daraus ergibt sich freilich ein Problem: Laufen auf den Systemen, auf denen die Dienste eines Objektspeichers gerade die CPU und das RAM durch die Mühle drehen, auch virtuelle Instanzen, gehen diesen schlimmstenfalls die Ressourcen aus. Und weil ein typischer Resync in Ceph durchaus einige Zeit in Anspruch nehmen kann, hält dieser Zustand unter ungünstigen Umständen eine ganze Weile an.

Geänderte Ansichten

Spannenderweise haben sich die Ansichten der Hersteller im Hinblick auf hyperkonvergente Infrastrukturen in den vergangenen Monaten stark gewandelt. Als Inktank noch eine eigenständige Firma war, rieten die Ceph-Entwickler dort dringend vom hyperkonvergenten Betrieb ab. Mittlerweile stellt Red Hat als heutiger Eigentümer von Inktank selbst Dokumentation online, die beschreibt, wie sich hyperkonvergente Setups mit Ceph erreichen lassen. Für andere verteilte Speicher wie Minio oder OpenStack Swift gibt es ebenfalls entsprechende Dokumentation, auch wenn die potenziellen Schmerzen dort nicht so groß sind: Die Backing Devices der Container und virtuellen Instanzen eines Setups können mangels entsprechender Schnittstelle nicht in Minio oder Swift liegen.

Gerade beim Einsatz von Ceph gibt es weiterhin gute Argumente gegen hyperkonvergente Setups. Wer sich trotzdem für diesen Weg entscheidet, muss unter allen Umständen darauf achten, dass er wirklich leistungsstarke Systeme mit vielen physischen CPU-Kernen und reichlich RAM kauft. Darüber hinaus müssen hyperkonvergente Server mit dicken Links ans Netz angebunden sein. Auf der Ceph-Ebene empfiehlt es sich zudem, den Durchsatz der Resynchronisation zu deckeln, um genug Ressourcen für andere Aufgaben übrigzulassen.

Direkter Zugriff auf Objektspeicher als neue Option

Bis hierhin hat der Artikel sich vorrangig mit konventionellen Zugriffsarten auf zu speichernde Daten beschäftigt. Ganz gleich, ob eine Storage-Architektur hyperkonvergent ist, auf dedizierte Hardware für den Objektspeicher setzt oder SAN- und NAS-Geräte nutzt: Der Zugriff auf Blockgeräte oder auf der Dateiebene ist ein alter Hut und seit Anbeginn der IT fast unverändert Standardprozedere.

Langsam, aber sicher hat sich in den vergangenen Jahren jedoch noch ein zusätzliches Zugriffsmodell für Dateien etabliert. Entwickler mögen es weniger, weil es einen Umbau der zugreifenden Applikation bedingt. Die Vorteile, die Dienste daraus ziehen können, sind jedoch enorm. Die Rede ist von Objektspeichern, auf die man tatsächlich auch als solche zugreift.

Im Kontext von Ceph ist zwar meist die Rede vom Zugriff auf Blockgeräte, das Ceph-Dateisystem CephFS oder das Ceph Object Gateway. Wer Ceph jedoch nur in diesem Kontext sieht, vergisst, dass dabei unter der Haube RADOS steckt, ein komplett ausgebauter Objektspeicher mit eigenem Protokoll für den Zugriff. Etwas offensichtlicher wird die Idee bei anderen Objektspeichern wie OpenStack Swift oder Minio, die keine Frontends für Posix- oder blockbasierten Zugriff bieten.

Webbezogene Entwicklung pusht

Worin besteht nun aber die Innovation des neuen Speicheransatzes? Er geht zunächst davon aus, dass Anwendungen immer stärker online-basiert sind und sich in Microservices aufteilen. Eine große Herausforderung beim Betrieb von Online-Anwendungen – und allen voran Websites – war und ist es, Asset-Daten sinnvoll zu verwalten. Die machen bei normalen Internet-Seiten den Löwenanteil dessen aus, was der Anwender letztlich sieht: Grafiken, Fotos, Navigationselemente, schematische Darstellungen und noch viele andere Arten von Grafik.

Es ergibt keinen Sinn, diese Asset-Daten auf jedem Webserver hinter Load-Balancern zu haben. Einerseits erzwingt das ein komplexes Regime, um die Daten bei Updates synchron zu halten, andererseits frisst dieser Ansatz unnötig viel Speicherplatz. Die meisten Setups legen Asset-Daten deshalb auf einem geteilten Netzwerkdateisystem ab, auf das alle Webserver im Read-only-Modus zugreifen. Der Zugriff auf das Dateisystem, das Posix-Garantien bietet, entpuppt sich regelmäßig jedoch als echte Herausforderung in Sachen Performance und Wartung. Posix gibt Anwendern zwar viele Garantien, doch die brauchen typische Asset-Daten von Websites gar nicht: Sie verändern sich nicht, werden nicht überschrieben und bilden keine komplexen Hierarchien.

Das Aufkommen von Protokollen wie S3 hat Entwickler deshalb zur Frage gebracht, ob sich diese Dienste nicht besser verwenden lassen, um Asset-Daten zu verwalten. Die Idee: Die Website verlinkt in ihrem Quelltext unmittelbar auf Objekte im Objektspeicher, bindet sie also unmittelbar von dort ein. Wahlweise übernimmt die Web-Software den Download aus dem Objektspeicher und liefert dem Client das Asset, oder – falls sich der Objektspeicher per Internet erreichen lässt – lädt der Client die Datei direkt von dort. Das entlastet nicht nur den Webserver, sondern macht auch einen zentralen Speicher etwa auf Basis von NFS überflüssig. Viele moderne Anwendungen nach den Standards der Microservices-Architektur folgen eben diesem Ansatz.

Änderungen an der Applikation nötig

Einen Pferdefuß hat die Sache freilich: Die Applikation braucht eine native Anbindung an den Objektspeicher, wenigstens um Dateien dort hochzuladen. Hier kommt den Autoren von Programmen aber zugute, dass es Client-Bibliotheken für S3 sowie für den nativen Zugriff auf RADOS gibt, die über diverse Skriptsprachen-Bindings verfügen (Abbildung 5). In PHP lässt sich der RADOS-Zugriff auf diese Weise ebenso gut erreichen wie der Zugriff auf S3 aus Go oder Ruby heraus. Gerade Legacy-Anwendungen brauchen jedoch eine Anpassung: Als sie entstanden, war von Objektspeichern oft noch gar keine Rede. Die Option, einen Posix-kompatiblen Datenspeicher aus dem Setup loszuwerden, lässt diese Arbeit aber lohnenswert erscheinen.

Abbildung 5: Immer mehr Anwendungen, wie hier Apache Spark, setzen im Hintergrund auf nativen S3-Speicher – gerade im Container-Kontext. Quelle: Yifeng Jiang

Übrigens: Glaubt man den Analysten verschiedener Dienstleister, ist objektbasierter Speicher die zentrale Speichertechnologie der Zukunft. Objektspeicher, besonders in hyperkonvergenter Form als Teil der Compute-Knoten, nimmt demnach eine zentrale Stelle in der Speicherarchitektur der Rechenzentren der Zukunft ein.

Dienste wie Kubernetes und Anwendungen, die in Containern in Kubernetes laufen, konsumieren laut der jeweiligen Analysen ihren Speicher am liebsten in Form von echtem Object Storage. Blockbasierter Speicher, den viele Administratoren heute als Zentrum ihres Speicherrückgrats sehen, nimmt dagegen an Bedeutung ab. Noch wäre es zu früh, an dieser Stelle von einer wirklichen Wachablösung zu sprechen. Es wird aber aus Sicht des Administrators extrem spannend sein, diese Entwicklung in naher Zukunft zu verfolgen.

Fazit

Das Thema Storage im Rechenzentrum präsentiert sich heute so divers und zum Teil chaotisch wie lange nicht mehr. Ausschlaggebend ist heute nicht mehr so sehr die Frage, welche Storage-Systeme in der Firma bereits laufen und über welches Wissen die Admins verfügen. Wer heute nach dem passenden Speicher für Umgebungen sucht, muss sich zuerst die Frage stellen, was er leisten soll und wie er zum Einsatz kommt. Für Setups, in denen Skalierbarkeit in die Breite keine Rolle spielt, sind SAN- und NAS-Anwendungen noch immer eine gute Lösung. Kommt Skalierbarkeit ins Spiel, bleiben als Option fast nur skalierbare Objektspeicher übrig. Die bekommen unerwartete Schützenhilfe von Containern, die immer häufiger S3 und echte Objektspeicher als Storage-Backend nutzen. (jcb)