Starnberg, 2. Juli 2013 - An dieser Stelle sollen kurz einige Storage-Anforderungen bei „Big- und Much Data“ inklusive Object-Storage-Technologie besprochen werden...
Um was es hier geht: Für Real-time-Analysen von Datenquellen (Big Data) sind aus Leistungsgründen Direct-Attachted Storagesysteme (DAS) oder komplette integrierte Appliances (Hardware, Software) geeignet, während transaktionsorientierte Anwendungen (klassisches RDMS bzw. Data Warehousing) über Tiered-Hybrid Arrays (Flash, SSD, HDD, FC, SAS) bedient werden (Read-/Write-Ratio beachten). In-Memory-Computing stellt bei Big Data und Data Warehousing für bestimmte Workloads einen wichtigen Entwicklungsschritt dar (z.B. strukturierte SQL-Abfragen), denn damit verlagert sich der I/O direkt von SSD oder Festplatte in den Hauptspeicher (RAM) allerdings sind die Kosten noch entsprechend hoch (CAPEX, Implementierung, Know-How etc.), bei begrenzter Skalierbarkeit (Appliance-Modell). Auch ist RAM bei Stromausfall flüchtig, d.h. alle wichtigen Inhalte müssen regelmäßig auf weitere Medien gesichert werden (Automatisierungsgrad, Disaster Recovery ?!). Eine weitere Alternative wie z.B. ausschließlich auf Flash-basierte Arrays sind bei Big Data auf Grund der meisten I/O-Workload-Profile im Bereich von NoSQL / Hadoop weniger geeignet; auch aus Kostengründen bietet sich deshalb Storage Tiering an; siehe hierzu auch:
Die andere Herausforderung besteht bei der Speicherung und Archivierung sehr großer Datenpools (Much Data), die sich mit klassischen Ansätzen wie FC-SANs im Storage-Backend nicht hinreichend adressieren lassen (Skalierbarkeit, Kosten). Auch hier ist Tiering der optimale Ansatz, allerdings sind - um wirklich große Datenmengen sowohl Benutzer- als auch kostengünstig zu verwalten – massiv skalierbare (Cloud-) Architekturen nötig. Weitere Randbedingungen betreffen die Wirtschaftlichkeit (CAPEX, OPEX), den möglichst geringen Energieverbrauch, Verfügbarkei, Redundanz, Datenintegrität, schnelle Zugriffsleistung bei niedrigen Speicher- und Verwaltungskosten sowie transparente und standardisierte Benutzerschnittstellen.
Eine Möglichkeit sind Scale-out-clustered (NAS-) Filesysteme mit globalem Namensraum; diese bilden jedenfalls die Basis gängiger derzeitiger Lösungsangebote und werden von fast allen namhaften Storage Herstellern angeboten (IBM, EMC Isilon, Bull/Lustre, HP, Quantum, NetApp, Oracle/Sun ZFS, Red Hat usw.).
Ein gar nicht mehr so neuer Lösungsansatz für „Much Data“ ist (Cloud-) Object Storage...
Objekt-Datenspeicherung bedeutet im Gegensatz zu Block- oder Datei, dass die kleinste Speichereinheit ein ganzes Objekt darstellt. Dem Speichersystem sind bestimmte Informationen über Inhalt und Art des Objektes bekannt (Metadaten). Diese werden ebenfalls gespeichert und darüber lässt sich die Zugriffsbeschränkung für jedes Objekt erreichen. Mit dieser Methode kann ein großer flexibler Speicher geschaffen werden, der je nach Plattform und Software bis zu mehrere Milliarden Objekte abspeichern kann. Traditionelle Arraybasierte RAID-Controller-Architekturen sind dafür natürlich nicht ausgelegt (RAID Overhead, Datenintegrität, Rebuild-time, Skalierbarkeit, Kosten).
Neben Start-up’s ( siehe Scality, Cleversafe, Amplidata etc.) verfügen inzwischen auch alle bekannten Storageanbieter wie HDS, EMC, NetApp, HP, Dell, Quantum oder Red Hat über Object-Storage-Technologien, die im Zusammenhang mit den gestiegenen Anforderungen an (Cloud) Storage Architekturen auch bei kommerziellen Industrieunternehmen und Service Providern langsam auf Interesse stoßen. Hier ein kurzer Überblick zu den Funktionsprinzipien:
-
Die Objektdaten-Speicherung besteht im Backend aus Commodity-Storage-Nodes (scale-out) für die nötige Speicherdichte, während das Front-End aus davon getrennten Controller-Nodes besteht, die eine skalierbare Leistung und Verfügbarkeit für das Storage Management liefern sollen. Durch die (räumliche) Trennung in Compute- und Storage Nodes können die Systeme sogar weltweit skalieren und damit granular auf die jeweiligen Applikations- und Verfügbarkeitserfordernisse elastisch angepasst werden.
-
Der Zugriff auf die Daten erfolgt über HTTP/REST APIs, so dass für Anwendungen ein Filesystem-unabhängiger Zugriff auf die gespeicherten Objekte ermöglicht wird. Zur Standardisierung gibt es für technisch interessierte ein neutrales Dokument zum erweiterten Object-Storage-Modell der SNIA (A Cloud Environment for Data-intensive Storage Services).
-
Verteilte Datenintegrität-Funktionen speichern Objekte nicht mit RAID-Verfahren, sondern über mathematische Gleichungen, die über den gesamten Speicher-Pool verteilt werden. Data Objects (Files) werden in Sub-Blöcke aufgeteilt, aus denen Algorithmen berechnet werden. Je nach Verfügbarkeitsanspruch wird ein definierter Overhead an Gleichungen berechnet und diese über so viele Platten möglich verteilt (ähnlich einem distributed parity system); sind Speichermedien defekt, können aus den verteilten Gleichungen die Daten im Hintergrund wieder neu berechnet werden.
Wann macht der Einsatz von Object Storage im Unternehmen Sinn? Object Storage wurde für die automatisierte Speicherung und Archivierung von großen Datenmengen entwickelt, typischerweise ab einem Petabyte aufwärts. Von Bedeutung ist hier neben der Technik aber auch die Fragestellung, welche Daten überhaupt in ein Object-Storagesystem bzw. in die Cloud gehören ... Stichwort„Datenklassifizierung“ > http://www.storageconsortium.de/content/node/719
-
Empfehlung: falls Daten über mehr als zwei Rechenzentren verteilt werden, sollte eine Objekt Storage-Plattform möglichst ohne klassische Replikations-Mechanismen auskommen, um sowohl den Overhead als auch die TCO gering zu halten.
Mehr zum Thema Objekt-Datenspeicherung, Tiered Storage und SSD's finden Sie übrigens als registrierter Benutzer dieser Seite auch in den Vortragsunterlagen unseres Performance-Workshop’s für Rechenzentren vom 20. Juni in München. Siehe Rubrik „Downloads“ unter: