Starnberg, 29. April 2020 - Object Storage im Gegensatz zu (scale-out) NAS und SAN. Anwendungsbereiche beginnen sich zu verändern; was sind die Rahmenbedingungen...
Um was es hier geht: Vernetzte Speichersysteme auf Datei- oder Filelevel (NAS) sind beliebt; waren und sind sie doch relativ einfach zu implementieren und flexibel einzusetzen (NFS, SMB/CIFS) und stellen eine relativ kostengünstige Speicheroption für eine Vielzahl bestehender Anwendungen dar. Ihr Einsatz wird jedoch dann problematisch, wenn die Gesamtzahl und auch Größe der Files schnell und stark ansteigt (Stichwort: semi-/unstrukturierte Applikationsdaten) und verteilte (geo-redundante) Architekturen gefordert sind. Hier kommen dann je nach Anwendung "scale-out" File-Systemlösungen (z.B. clustered n-node NAS) ins Spiel, die unter diesen Randbedingungen hoch skalieren, einfacher zu verwalten sind (global Namespace) und je nach Architektur (nur Software via x86-nodes oder integrierter Appliance-Ansatz) sowohl hohe Leistung (Parallelität) als auch Kapazität liefern, allerdings zu höheren Kosten. Nicht immer deckt dieser Ansatz jedoch alle geforderten Leistungsmerkmale funktionell und kosteneffizient ab.
Block-basierte, vernetzte Speichersysteme (SANs) bieten neben niedrigen Latenzen, hohen Durchsatzraten (IOPS / GB/s), Datenintegrität-/Sicherheit und flexible Konfigurationsmöglichkeiten für kritische Unternehmensanwendungen (strukturierte Daten / RDMBS etc.). Allerdings ist eine hochleistungsfähige, voll-redundante SAN-Infrastruktur nicht für die Verwaltung riesiger unstrukturierter Daten-Archive geeignet.
Auf Grund von Digitalisierungs-Intitiativen, Cloud Computing, hoher Daten-Mobilität, IoT, Big Data Analytics und neuen Anwendungen (Stichwort: Apps) steigt die absolute Menge an semi- und unstrukturierten Daten in den Unternehmen gerade stark, auch im Edge. Das Interesse an alternativen kosteneffizienten Speicherlösungen ist somit offensichtlich. Die Speicherung von Objekten im Rahmen populärer Cloud-Anwendungen, wie wir sie gerne täglich in unserem Privatleben nutzen, ist ja für viele bereits eine Selbstverständlichkeit (z. B. Content-Streaming, Fotofreigabe oder die beliebten File Sharing Dienste), und auch im Datacenter wird sich dieser Prozess beschleunigen. Hier beginnt sich neben dem klassischen SAN und NAS inkl. scale-out NAS mit Object Storage eine dritte Speicher-Plattform zu etablieren. Bei Hyperscalern ist dieser Prozess im Datacenter bereits seit längerem vollzogen.
Objekt Storage dient nicht dazu, NAS oder SAN als Speichermethode vollständig abzulösen. Das Verfahren ist derzeit aus Anwendungssicht sinnvoll in der Kombination mit File- und Block Storage. Technisch gesehen sind aus Sicht der Applikation sowohl Objekte als und Dateien zwar ähnliche Konzepte zur Speicherung zusammengehöriger Informationen, um eine logische Datenverknüpfung herzustellen. Im Vergleich zu File Storage zeichnen sich Objekte aber durch zusätzlich mitgespeicherte Metadaten für Zugriffsschutz bzw. Speicherart und einem flachen Namensraum aus.
Weitere Katalysatoren für den Einsatz von Objekt-Speichersystemen sind verstärkte Investitionen in hybride Cloud - Speicherkapazitäten, um Flexibilität, Kostenvorteile (pay as you use) und skalierbare Leistung von Cloud Services zu nutzen. Auch das Interesse von DevOps-Teams / Entwicklern an neuen Anwendungen im Zuge der Digitalisierung nimmt zu. Die Teams sind, getrieben durch das Business, zunehmend auf der Suche nach agilen IT-Infrastrukturen, die sich auf die Public Cloud (hybride Deployments) ausdehnen lassen.
Der Bekanntheitsgrad und die Akzeptanz von Objektspeicherlösungen im Unternehmenseinsatz steigt somit, wenngleich der Einsatz bislang auf bestimmte Marktsegmente begrenzt war. Einer der Hauptgründe lag bislang auf der Anwendungsseite: Object Storage ist auf kompatible Anwendungen angewiesen. Lokaler- und Cloud-Object-Storage ist in der Regel nicht kompatibel mit traditionellen Betriebssystemen, Anwendungs-Schnittstellen bzw. Datenstrukturen. Die Inkompatibilität gängiger Dateisysteme mit hierarchischen Datenstrukturen kann für moderne Workloads ein Problem darstellen. Da aber jede Menge an älteren- aber auch aktuellen Anwendungen auf dem klassischen Filesystem-Ansatz basieren, können diese nicht einfach auf die Daten im Objektspeicher zugreifen. Dies steht der Implementierung einer hochintegrierten Speicherverwaltung, die über eine zentrale Schnittstelle gesteuert werden soll (Software Defined) und aktuelle Speichermedien wie SCM, Flash, HDDs, Tape, Objektspeicher und die Cloud umfasst, meist entgegen.
Die Unterstützung von nicht für Object Storage programmierten Anwendungen (legacy apps) erfordern Gateways, um den Zugriff via File-Level auf den Objektspeicher (on-premise oder in der Cloud) möglich zu machen, was aber wiederum eigene Herausforderungen bergen kann (Komplexität, Kosten, Zuverlässigkeit). Cloud-Gateway-Funktionalitäten finden sich auch nativ in Object Software als (unified) Daten- und Speicherverwaltungssystem integriert, was die Komplexität reduziert. Aber egal ob als Gateway oder als Software gelöst: die Integration ist notwendig, um bisherige File System Implementierungen wie z.B. unter Windows mit Cloud, NAS und ggf. Band zusammenzuführen. Weitere Anforderungen betreffen den Backup-Restore, Notfallwiederherstellung bzw. Replikation sowie die Möglichkeit einer möglichst transparenten Datenmigration in die Cloud.
Eine wichtige Frage lautet: Wie lassen sich vorhandene Anwendungen und Speicherumgebungen auf File- und auch Block-basierten Zugriffsmechanismen mit Object Storage - auch in der Cloud - transparent und kosteneffizient verbinden und kombinieren (Stichwort: Cloud Integrated Storage). Auch die performance-seitige Weiterentwicklung von Object Storage - und damit ein breiterer Anwendungseinsatz - ist ein interessanter Entwicklungstrend, den ich im zweiten Teil dieses Blogs behandeln werde (siehe auch Anmerkung unten am Textende).
Was ist ein Objekt im Gegensatz zu einer Datei?
Bei der Objektdaten-Speicherung wird jedem Datenelement ein eindeutiger Identifier zugeordnet, welcher unabhängig vom Speicherort nur durch Angabe seiner URL (web-based design) wieder abgerufen werden kann. Metadaten und Nutzdaten werden hierfür getrennt gespeichert. Aus Sicht der IT-Administration wird im Gegensatz zu einer NAS-Lösung ein Tenant A, B, C etc. gebildet. Tenant steht jeweils für einen eigenständigen (aka mandantenfähiger) Bereich wie z.B. ein Kunde. "Unterhalb" befindet sich der jeweilige Namespace (1-n) als eine Art „Folder“, bei S3 „bucket“ genannt. Ein großer Vorteil dieses Verfahrens und der daraus abgeleiteten technologischen Fähigkeit zur „Selbst-Administration“ pro Mandant ist, dass zeitaufwändige File System Checks wegfallen können und der Automatisierungsgrad erhöht wird. Damit reduzieren sich die Betriebskosten (CAPEX) bei komplexeren Implementierungen.
Ein wichtiges, gemeinsames Attribut von Objektspeichern ist es ferner, dass sie gegenüber der Anwendung einen flachen Namensraum (namespace) abbilden. Filesysteme und relationale Datenbanken strukturieren die Daten so, dass sie aus Sicht der Anwendung schnell auffindbar sind. Die dafür notwendige funktionale Ebene zwischen Anwendung und Daten kann jedoch die Skalierbarkeit einer Speicherumgebung einschränken (software defined vs. Array-Silos). Die Objektspeicherung als Software-Definierter Ansatz umgeht diese Beschränkungen inhärent, indem ein flacher, potenziell unendlicher Namensraum geschaffen wird. Anstelle von Filesystemen- oder Datenbankstrukturen wird ein Metadaten-Repository verwendet...
Ende Blogposts Teil 1 / Im zweiten Teil dieses Blogs wird in Kürze auf weitere wichtige Punkte im Zusammenhang mit Object Storage eingegangen. Also z.B. warum Erasure Coding und RAIN und nicht RAID? Vorteile von Protokollen auf Basis RESTful APIs, S3? Kritische Einsatzgebiete und KPIs, Performanceaspekte beim Sizing einer Lösung usw.
Querverweis:
Mein Blogpost > Storage Management im Zusammenhang mit DevOps und Container Storage