Object Storage gewinnt an Fahrt – geplante Übernahme von Cleversafe durch IBM

Armonk, Starnberg, 5./6. Okt. 2015 – Aquisition liefert Object Storage Techologien für on-premise und IBM’s Hybrid Cloud Storage Business inklusive SoftLayer...

Einige Fakten zur geplanten Übernahme: Cleversafe wurde bereits 2004 als privat geführtes Unternehmen mit Sitz in Chicago gegründet und besitzt über 350 Patente für die objektbasierte Datenspeicherung. Die aktuellen Storagelösungen des Anbieters erlauben es, bis in den Exabyte-Bereich zu skalieren. Kunden aus verschiedenen Branchen nutzen Cleversafe für große Content Repositories aber auch Backup, Archivierung oder Storage as a Service.

Sobald das Abkommen zur Übernahme abgeschlossen ist, wird IBM das Cleversafe-Produktportfolio in die IBM Cloud Geschäftseinheit integrieren, um On-Premise, Cloud und Hybrid-Cloud-Bereitstellungsoptionen für die Kunden zu ermöglichen. Object Storage liefert gerade bei großen Datenmengen mehr Flexibilität, vereinfachte Verwaltung und Konsistenz. IDC schätzt, dass ca. 80 Prozent aller neuen Cloud-Anwendungen „Big-Data-intensive“ sein werden (1).


Auszug aus der Originalmeldung IBM to Aquire Cleversafe Inc.: „... Clients will be able to use SoftLayer cloud services and IBM Bluemix, IBM’s Platform-as-a-Service, to create dynamic and innovative applications with the Cleversafe technology as a foundational content repository and data archive...The planned acquisition underscores IBM’s continued commitment to data storage innovation including investments across Flash, Software Defined Storage and Cloud Storage environments over the last five years alone."

Quellen:

[1] IDC MarketScape: Worldwide Object-Based Storage 2014 Vendor Assessment report (PDF)

Aktuelles zu OpenStack Swift und Object Storage im aktuellen Storage Consortium Blog vom 28. Sept. 2015

Cloud Storage und Hyperkonvergenz - 16. Anwendertagung des Storage Consortium vom 25. Juni 2015  bei e-shelter in Frankfurt/M.


Hintergrundinformationen: Wie arbeitet Object Storage?

Wenn ein Benutzer eine Datei modifiziert, wird diese neue Version auch immer als neues Objekt gespeichert (Metadaten). Das führt für große Kapazitäten zu einer einfacheren Architektur als bei normalen Filesystemen. Die Object-Backend-Architektur ist so gestaltet, dass alle Storage Nodes als ein Datenpool abgebildet werden; es gibt somit keine Dateisystem-Hierarchie wie bei NAS. Diese Architektur der Plattform, zusammen mit anderen Datenintegritäts-Features (kein RAID 5/6, sondern verteilte Hashing-Alogrithmen / erasure coding ) erlauben es, den Pool nahezu unbegrenzt zu skalieren, während das System weiterhin relativ 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 für Cloud Umgebungen geeignet. 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 abrufen – bzw. durch die Abfrage von Metadaten (Informationen über Objekte sind z.B.: Name; wann erstellt; durch wen…). Die Datei mit Hilfe eines traditionellen Filesystems zu lokalisieren, würde zu lange dauern. Anwendungen übernehmen auch die Benutzerzugriffsverwaltung. Falls eine Datei (Objekt) geändert wird, wird diese als neues Objekt gespeichert - dies verhindert Datenkorruption (concurrent access).
  • RESTful APIs sind die Schnittstelle zum Data Management; hiervon existieren verschiedene Ausprägungen, die sowohl Hersteller- als auch Technologiebedingt je nach Implementierung zum Einsatz kommen können (OSD T10, CDMI / SNIA proposed, SWIFT/ OpenStack, Amazon S3 u.a.).

Gibt es Einschränkungen?

  • Es existieren Anbieter-Implementierungen für Objekt-Datenspeicher, die zwar eine RESTful API aufweisen, aber darunter ein POSIX Filesystem als zusätzlichen Layer über dem Storagepool verwenden. Im Gegensatz zu einer flachen single-layer Adress-Struktur zur Reduzierung von Disk I/O unter voller Ausnutzung der vorhandenen Speicherkapazitäten des Storagepools, die reine Object Storage - Systeme kennzeichnen. Auch ein Punkt: die Unterstützung von sowohl großen als auch kleinen File-Sizes.