Starnberg, 22. Aug. 2014 – Warum ist die objektorientierte Datenspeicherung im kommerziellen Rechenzentrum notwendig?
Im folgenden ersten Teil dieses Beitrags habe ich versucht, einen knappen Überblick zum Einstieg in die Thematik "Object-Storage" zu geben. In einem zweiten Teil im Herbst soll dann stärker auf einzelne Anwendungsbeispiele und auch Kostenaspekte eingegangen werden. Bitte versäumen Sie bei Interesse hierzu nicht den Besuch unserer nächsten Rechenzentrums-Fachtagung am 9. Okt. in München zum Thema "Moderne Archivierungs- und Datenschutzstrategien". Es wird dort auch das Thema Objektdaten-Speicherung und OpenStack / Swift behandelt. Das Storage Consortium ist dieses Mal Gast bei T-Systems und die ersten 10 Anmeldungen zur Konferenz erhalten eine exklusive Führung durch das Hochsicherheits-RZ des Dienstleisters.
Zum Beitrag: NAS & SAN speichern Dateien schnell und in großer Menge, warum also eine dritte Speichertechnologie mit Object Storage? Die größte Herausforderung bei SAN/NAS Systemen ist die Skalierbarkeit (Kapazität/Leistung/Kosten). NAS kann als singuläres System im Normalfall keine Multi-Petabyte-Umgebungen kosteneffizient und benutzerfreundlich verwalten. Scale-out clustered NAS hingegen erfordert eine Kombination von vielen Systemen (nodes) und bringt damit bei sehr großen Umgebungen durch die n-node cluster Architektur einen höheren Verwaltungsaufwand mit = Kosten; die Datenmigration auf Scale-out-Systeme bleibt zudem arbeits- und kostenintensiv. SANs können ebenfalls komplex im Management werden vor allem mit einem separaten Filesystem "on top". Dies ist bislang weniger für gängige kommerzielle Rechenzentren mit Standard-Anwendungen zutreffend, als für bspw. große Cloud Services Anbieter, die meist bereits mit preiswerter Standard Hardware (für Ihre Zwecke optimiert / x86 shared nothing cluster) und zum Teil proprietärer Software Object Storage Systeme einsetzen (Google Cloud Storage, Rackspace, Apple, Amazon S3…).
Nichts desto weniger wird das rasche Datenwachstum in den Unternehmens-RZ's dazu führen, dass auch eine breitere Anzahl von IT-Organisationen sich mit dem Thema der objektorientierten Datenspeicherung beschäftigen werden. Getrieben wird die Entwicklung durch "Always On"-Business Anwendungen, Big Data Archive, Industrie 4.0 (Maschinenbau-/Fertigung-/Sensordaten), Compliance-Anforderungen (Cold Data, active Archives) und Entwicklungen bei Internet of Things. In all diesen Feldern entstehen massiv neue Daten (unstrukturiert / semistrukturiert wie logfiles) und fordern damit traditionelle SAN-/NAS Storage Architekturen und IT-Organisationen kosten- und leistungsmäßig heraus.
- Nach Untersuchungen von IDC soll der weltweite Umsatz im Bereich Datei- und Objektspeicher bis 2017 auf 38 Milliarden US-Dollar ansteigen. Dies entspräche einem Plus von 65 Prozent im Vergleich zu dem im Jahr 2013 erzielten Umsatz von schätzungsweise 23 Milliarden US-Dollar. Bis 2017 sollen danach Datei- und Objektspeicher mit einer Gesamtkapazität von 173 Exabyte ausgeliefert werden, d.h. die Marktforscher rechnen mit einer Vervierfachung der ausgelieferten Kapazität innerhalb von vier Jahren.
Wie arbeitet Object Storage?
Wenn ein Benutzer eine Datei modifiziert, wird diese neue Version auch immer als ein neues Objekt gespeichert (Metadaten). Das führt besonders für große Kapazitäten zu einer einfacheren Architektur als bei herkömmlichen Filesystemen. Die Object-Backend-Architektur ist so gestaltet, dass alle Storage Nodes als ein gemeinsamer, elastischer Datenpool abgebildet werden. Es gibt keine Dateisystem-Hierarchie wie bei NAS. Diese Architektur der Plattform (zusammen mit neuen Datenintegritäts-Features wie z.B. kein RAID 5/6, sondern verteilte, kryptografische Hashing-Alogrithmen) erlauben es, den Pool nahezu unbegrenzt zu skalieren, während das System weiterhin einfach zu verwalten bleibt.
Benutzer greifen über Anwendungen auf Objektspeicher typischerweise über eine REST-API zu. Man verwendet dazu eine Reihe von einfachen Befehlen wie GET (lesen), PUT (speichern) und DELETE (löschen). REST ist ein für Online-Anwendungen optimiertes Internet-Protokoll und macht den Objektspeicher damit geeignet für Cloud Umgebungen. Wenn die Objekte gespeichert sind, wird eine Kennung erzeugt, um das jeweilige Objekt in dem Pool zu finden (Object ID); Anwendungen können die benötigten Daten für die Benutzer durch diese Objekt-ID schnell abrufen – bzw. durch die Abfrage von Metadaten (Informationen über Objekte sind z.B.: Name; wann erstellt; durch wen…). Das arbeitet in der Regel schneller und effizienter als der Versuch, eine Datei mit Hilfe eines traditionellen Filesystems zu lokalisieren. Anwendungen übernehmen auch die Benutzerzugriffsverwaltung. Jedes Mal, wenn eine Datei (Objekt) geändert wird, wird diese als neues Objekt gespeichert. Dies verhindert Datenkorruption bei gleichzeitiger Änderungen eines Datensatzes (concurrent access).
Anwendungsbereiche für Object Storage
Compliance-/Archive, Social Media, Sendeanstalten-/Filmstudions, Cloud Archives-/Backup, Filesharing, Collaboration und Online Web Services.
Wo gibt es Einschränkungen?
Einige Anbieter liefern derzeit Objekt-Datenspeicher, die zwar eine RESTful API aufweisen, aber weiterhin ein POSIX File System als zusätzlichen Layer über dem zugehörigen Festplattenpool verwenden. Im Gegensatz zu einer flachen single-layer Adress-Struktur zur Reduzierung von Disk I/Os, unter voller Ausnutzung der vorhandenen Speicherkapazitäten des Storagepools, die reine Object Storage Systeme kennzeichnen. Ebenfalls ein kritischer Punkt: die Unterstützung von sowohl großen als auch kleinen Filegrößen.
Anmerkung zur Standardisierung
RESTful APIs sind die Schnittstelle zum Data Management, aber hiervon existieren verschiedene Ausprägungen, die sowohl Hersteller- als auch Technologiebedingt je nach Implementierung zum Einsatz kommen (OSD T10, CDMI /SNIA proposed, SWIFT OpenStack Cloud Software / Ceph, Amazon / Simple Storage Service S3 u.a.).
Bekannte Hersteller-/Anbieter von Objekt Storage Systemen sind kommerzielle Firmen und Communities wie Lustre (HPC Umfeld), EMC Atmos, Centera, IBM (SoftLayer), Hitachi HCP, Quantum (Lattus), Red Hat / Inktank (Object) Storage, Scality (Ring), NetApp (StorageGRID), Dell, HP...
Erstes Fazit:
Object Storage hat technologisch das Potential und bereits die Reife, in Verbindung mit kapazitätsoptimierenden Maßnahmen wie (Inline-) Deduplizierung, Data Compression und Netzwerkoptimierung die genannten Herausforderungen für bestimmte Anwendungsfelder zu adressieren. Einschränkungen bestehen derzeit noch bei der mangelnden Verfügbarkeit von (nativen) Anwendungen und einer fehlenden Festlegung auf verbindliche Standards (derzeit verschiedene herstellerspezifischen Schnittstellen-Implementierungen). Darauf und auf die Kostenseite (TCO, OPEX, CAPEX) werde ich im nächsten Teil dieses Blogs eingehen.
Hier ein Überblick zu den Objektspeicher-Lösungen von Red Hat und Quantum Lattus – vorgestellt auf unseren Rechenzentrums-Fachtagungen in München und Düsseldorf 2013 mit weiteren Weblinks unter:
http://www.storageconsortium.de/files/downloads_registrated/RedHat_2013-11-14-RHS-SC-Düsseldorf.pdf
Abb. 1: Bildquelle Inktank (Red Hat), Ceph Block Storage
Weitere Quellen:
http://www.inktank.com/what-is-ceph/
http://en.wikipedia.org/wiki/Object_storage_device
Abb. 2: Bildquelle Quantum Lattus, Positionierung im Storagestack