7 Die Storage Special Interest Group der CNCF hat ein ausführliches Whitepaper (auf Englisch) veröffentlicht, das den Aufbau von Speichersystemen für Cloud-native Anwendungen erklärt. Das Dokument ist Pflichtlektüre, um verschiedene Speicherarten und ihren heutigen Einsatz in der Produktion umfassend zu verstehen und zu vergleichen. Dieser Beitrag ist ein Auszug aus dem Papier, das auf der KubeCon Shanghai vorgestellt wurde; das PDF finden Sie im GitHub-Repository der CNCF Storage SIG (auf Englisch). Cloud-native Anwendungen werden dadurch definiert, wie wir sie entwerfen, entwickeln und bereitstellen – nicht unbedingt dadurch, wo sie „leben“. Cloud-native bedeutet Microservices, Container, Orchestratoren und mehr; die Grundidee ist, wirklich plattformunabhängige, flexible Anwendungen zu entwickeln, die jeder autorisierte Endbenutzer ausführen kann. Hier einige zentrale Merkmale Cloud-nativer Anwendungen, wie sie die Cloud Native Computing Foundation (CNCF) definiert – nachzulesen in einem Beitrag auf The New Stack (auf Englisch): In Containern verpackt Als lose gekoppelte Microservices konzipiert Unabhängig von Server und Betriebssystem Richtlinienbasierte Ressourcenzuweisung Verwaltet über agile DevOps-Prozesse Auf APIs für die Interaktion ausgerichtet Wer nicht auf Cloud-native setzt, verpasst wichtige, hochmoderne Technologien und verbringt am Ende mehr Zeit mit dem Patchen und der Pflege seiner Anwendung. Natürlich gibt es Ausnahmen. Bedarf an Speicher Nehmen wir an, Sie haben beschlossen, eine zustandsbehaftete Anwendung auf Kubernetes bereitzustellen. Zustandsbehaftet bedeutet, dass sich die Anwendung Dinge merken muss, wenn ein Client mit ihr interagiert. Das Speichern solcher Informationen erfordert Speicher. Was ist für Ihre Anwendung wichtig? Der erste Abschnitt des Whitepapers stellt die grundlegenden Eigenschaften von Speicherschnittstellen und -systemen vor. Das sind Merkmale, die ein Speichersystem in der Regel hat oder haben sollte. Da jede Anwendung eigene Funktionen und Ziele hat, möchten Sie vielleicht alle Eigenschaften, nur einige davon oder alle, wobei Sie auf einige mehr und auf andere weniger Wert legen. Zentrale Eigenschaften eines Speichersystems: Verfügbarkeit Skalierbarkeit Leistung Konsistenz Beständigkeit Instanziierung & Bereitstellung Speicherschichten Man kann Speichersysteme auch danach beschreiben, woraus sie bestehen. Das hilft zu bestimmen, wie Ihre Daten gespeichert und abgerufen werden, wie sie geschützt sind und wie sie mit Ihren Anwendungen (Betriebssystem und Orchestrator) interagieren. Diese Schichten hängen eng mit den oben genannten Eigenschaften zusammen. Speichertopologie – wie die verschiedenen Teile eines Systems zusammenhängen und verbunden sind (etwa Speichergeräte, Rechenknoten und Daten). Die Topologie ist wichtig, weil sie beim Aufbau viele Eigenschaften eines Speichersystems beeinflusst. Die Speichertopologie kann zentralisiert, verteilt, geshardet oder hyperkonvergent sein. Datenschutz – ein wichtiger Dienst, der dafür sorgt, dass Ihre Daten selbst im Katastrophenfall erhalten bleiben. Dafür gibt es mehrere Wege: RAID (Redundant Array of Independent Disks) – Verfahren, um Daten redundant auf mehrere Festplatten zu verteilen Erasure Coding – ein Verfahren zum Schutz von Daten, bei dem sie in Fragmente aufgeteilt, kodiert und mit mehreren redundanten Paritätssätzen gespeichert werden. Replikat – eine vollständige Kopie eines Datensatzes, verteilt auf mehrere Server. Datendienste – Dienste, die oft als Zusatzfunktionen zu den Hauptfunktionen des Speichersystems implementiert werden. Das variiert von System zu System; verbreitet sind etwa Replikation, Versionskontrolle, Verwaltungsfunktionen und mehr. Verschlüsselung – Speichersysteme können den Datenschutz durch Verschlüsselung sicherstellen. Dabei ist zu beachten, dass Verschlüsselung wegen des Rechenaufwands die Leistung beeinträchtigt; moderne Systeme bieten jedoch Beschleunigungsoptionen. Physische Schicht – die eigentliche Hardware, auf der die Daten gespeichert werden. Die Wahl des physischen Speichers beeinflusst die Gesamtleistung des Systems und die Beständigkeit der gespeicherten Daten. Klassische Systeme nutzen Magnetplatten und Flash-basierte SSDs/NVM. Datenzugriffsschnittstelle Die Datenzugriffsschnittstelle legt fest, wie Daten (von Anwendungen oder Workloads) genutzt und/oder gespeichert werden. Meist bevorzugen Anwendungen eine bestimmte Zugriffsmethode, oder sie ist durch die Architektur vorgegeben. Die Wahl der Schnittstelle beeinflusst auch wichtige Eigenschaften wie Verfügbarkeit, Leistung und Skalierbarkeit. Im Whitepaper werden Datenzugriffsschnittstellen in Volumes und Anwendungs-APIs unterteilt. Datenzugriffsschnittstelle: Volumes Blockspeicher Das ist wohl das älteste Speichersystem. Daten werden in Stücken fester Größe, sogenannten Blöcken, gespeichert. Diese Blöcke werden typischerweise numerisch adressiert. Um Daten abzurufen, muss die Anwendung also die richtige numerische Adresse angeben und dann aus den Teilen eine vollständige Datei zusammensetzen. Daten lassen sich nur über Adressen speichern und abrufen. Das ermöglicht einen sehr granularen und – wenn das Persistenzziel lokal ist – sehr schnellen Zugriff. Dateisystem Das ist eine logische Persistenzschicht, die Daten über Dateien speichert und abruft. Diese Schnittstelle bietet mehr Grundfunktionen (z. B. Verzeichnisstruktur, Zugriffskontrolle und Benennung) als ein Blockspeicher und eignet sich daher besser für die Nutzung durch Anwendungen. Die eigentliche Persistenzfunktion übersetzt Dateien in logische Blockadressen. Dateisysteme können lokal, remote oder verteilt sein. Zudem gibt es zahlreiche Arten von Dateisystemen, die für Eigenschaften wie Leistung, Beständigkeit, Speichermedium und Zugriffsmuster optimiert sind. Datenzugriffsschnittstelle: Anwendungs-API Objektspeicher Im Allgemeinen nutzen Objektspeichersysteme atomare Key-Value-Speicher. Anders als bei Dateisystemen und Blockspeichern sind die Implementierungen von Objektspeichern recht unterschiedlich. Das Whitepaper konzentriert sich auf HTTP-basierte Objektspeicher, wie sie AWS S3, Azure Blob, Google Cloud und OpenStack Swift definieren. Diese Systeme definieren eine Reihe von Methoden auf Basis des HTTP-Protokolls. Bei dieser Schnittstelle muss ein Objektspeicher nicht gemountet oder angehängt werden; diese Systeme sind für den anfragenden Knoten immer remote. Ein Vorteil HTTP-basierter Systeme ist das Metadatenmanagement: Objekten lassen sich eigene Metadaten zuordnen. Ein weiterer Vorteil ist die granulare Zugriffskontrolle. HTTP-Objektspeicher sind auf Skalierbarkeit und Beständigkeit ausgelegt. Sie können extrem große Datenmengen verteilt über verschiedene Rechenzentren und Regionen unterstützen und bieten meist viele Methoden, um höchste Datenintegrität zu gewährleisten. Key-Value-Speicher Diese Art von System ist darauf ausgelegt, Schlüssel-Wert-Paare zu speichern, abzurufen und zu verwalten. Ein Key-Value-Speicher hat kein vordefiniertes Schema und ist daher flexibel. Die Anwendung hat die volle Kontrolle darüber, was im „Wert“ gespeichert wird. Ein solches System kann auf einem einzelnen Knoten laufen oder auf viele skalieren, lokal oder über das Netzwerk angesprochen werden und seine Daten vollständig im Arbeitsspeicher, teilweise im Arbeitsspeicher oder vollständig auf der Festplatte speichern. Viele komplexere Speichersysteme bauen auf Key-Value-Speichern auf. Schnittstellen für Orchestrierung und Verwaltung Cloud-native bedeutet containerisiert. Container benötigen in der Regel ein Verwaltungssystem oder einen Orchestrator. Wie interagieren diese Orchestrierungssysteme mit den Speichersystemen, um Workloads mit Daten aus den Speichersystemen zu verbinden? Je nach Datenzugriffsschnittstelle können verschiedene Schichten beteiligt sein. Kubernetes kann beispielsweise mehrere Schnittstellen zur Interaktion mit dem Speichersystem unterstützen. Das Speichersystem kann: eine Control-Plane-API unterstützen und direkt mit dem Orchestrator interagieren über eine API-Framework-Schicht oder andere Tools mit dem Orchestrator interagieren Control-Plane-API bezeichnet Speicherschnittstellen zum Container-Orchestrator und konzentriert sich auf die dynamische Bereitstellung von Speicher für Workloads. API-Frameworks und andere Tools sind Erweiterungen von Control-Plane-APIs und können neben der Bereitstellung auch Automatisierung und weitere Datendienste unterstützen (Datenschutz, Datenmigration, Datenreplikation und vieles mehr). Das Whitepaper enthält zudem nützliche Vergleichstabellen für eine Reihe von Funktionen von Speichersystemen, die bei der Entscheidung helfen, welches am besten zu Ihren Anforderungen passt. Die CNCF hat außerdem ein begleitendes Webinar (auf Englisch) zum Whitepaper veranstaltet, das sich wirklich lohnt.
