Test: Datacore Swarm
Objektspeicher als SDS-Lösung
Fortsetzung des Artikels von Teil 1
Aufbau der Plattform
Für den Aufbau einer Swarm-Plattform stehen mehrere Optionen zur Verfügung. Datacore bietet vorkonfigurierte Hardware-Appliances an, Unternehmen können aber auch eigene Server-Hardware verwenden. Ein Storage-Cluster unterstützt einen Mischbetrieb mit unterschiedlichen Hardware-Servern und stellt keine besonders hohen Anforderungen an die eingesetzte Hardware. In der Regel lassen sich die Storage-Nodes auf Hardwaresystemen implementieren. Datacore bietet auch die Möglichkeit, die komplette Plattform auf einer Virtualisierungsinfrastruktur mit VMware ESXi oder KVM zu betreiben.
Für den LANline-Test nutzten wir die VMware-vSphere-7-Umgebung. Datacore hat eine Deployment-VM entwickelt, die die Bereitstellung der verschiedenen Swarm-Systeme durch vorkonfigurierte Skripte stark vereinfacht. Wir importierten die virtuelle Appliance über das vCenter, führten anschließend die diversen Skripte aus und installierten damit insgesamt elf Swarm-Systeme.
Die Storage-Nodes lassen sich standardmäßig über ein dediziertes Storage-Netzwerk per PXE-Boot starten und laufen vollständig im RAM des jeweiligen Rechners. Auf den lokalen Platten ist lediglich ein Journal gespeichert, das etwa fünf Prozent der Plattenkapazität belegt. Der Rest steht als Objektspeicher zur Verfügung. Alternativ lässt sich das Swarm-OS auch von einem lokalem USB-Laufwerk booten. Wie bereits erwähnt, kommt für den Schutz vor Datenverlusten eine Kombination aus Erasure Coding und Replikation zum Einsatz. Standardmäßig erstellt Swarm von kleineren Objekten zwei Replikate. Datenobjekte, die größer als 1 MByte sind, schützt Swarm mit Hilfe von Erasure Coding, um den Redundanz-Overhead zu reduzieren. Wenn Objekte im Lauf der Zeit anwachsen oder sich verkleinern, ändert Swarm automatisch die eingesetzte Redundanztechnik. Ein weiterer Schutzmechanismus ist die Versionierung auf der Objektebene. Zu jedem Objekt sind Metadaten lokal auf dem Storage-Node und zusätzlich im zentralen Elastic-Search-Index gespeichert. Durch die Versionierung ist es unter anderem möglich, versehentlich gelöschte Objekte wiederherzustellen oder ältere Versionen eines Objekts anzuzeigen. Die Suchfunktionen der Elastic-Search-Engine bieten zahlreiche Filteroptionen, um auf dem S3-Storage gespeicherte Datenobjekte schnell finden zu können. Bei Swarm handelt es sich um eine mandantenfähige Object-Storage-Lösung. Die Verwaltung der Zugriffsstruktur und der Speicherbereiche erfolgt per Web-Browser. In der Content-Management-Konsole legten wir LANline als Mandanten an und fügten auf der Domain-Ebene unseren Swarm-Cluster hinzu. Mit einem Klick auf den Domain-Namen landet man eine Ebene tiefer bei den Buckets und den Search Collections. Hier legten wir ein neues Test-Bucket an, um Daten auf dem Swarm-System speichern zu können.
In Unternehmen wird dies in der Regel über die S3-Schnittstelle der Anwendung erfolgen. Über die Content-Konsole lassen sich auch einzelne Dateien in ein Bucket kopieren. Wir klickten hierfür auf den Add-Button und übertrugen nacheinander eine Handvoll Dateien auf das Swarm-System. Um mehrere Dateien oder Verzeichnisse in einem Rutsch hochzuladen, lässt sich der S3-Browser von AWS nutzen. Damit kopierten wir ein Verzeichnis mit mehreren tausend kleinen Dateien in den Bucket. Die Swarm-Software verteilte diese Dateiobjekte gleichmäßig auf alle Nodes des Storage-Clusters.
Um die Auslagerung von Daten in die AWS-Cloud zu testen, konfigurierten wir bei AWS ein Bucket und legten einen Benutzer für den Swarm-Zugriff an. Anschließend richteten wir in der Swarm-Storage-Konsole einen sogenannten Feed für die Verlagerung von Daten zu AWS ein. Nachdem wir die Zugangsdaten für den AWS-Bucket eingegeben hatten, stellte das Swarm-System über das Internet eine Verbindung zu AWS her. Mit Hilfe der Swarm-Konsole konnten wir nun Datenobjekte in den AWS-Bucket übertragen. Swarm kann Objekte auch im WORM-Format (Write Once Read Many) speichern und unterstützt zudem die WORM-Funktion S3 Object Lock von AWS. Eine AES-Verschlüsselung der gespeicherten Objekte ist ebenfalls möglich. Ein automatisiertes Storage-Tiering, das Daten in Abhängigkeit von der Zugriffshäufigkeit innerhalb des Objekt-Storage-Systems zum Beispiel zwischen einem schnellen SSD-Tier und einem langsameren HDD-Tier hin und her verschiebt, ist in Swarm bislang nicht implementiert. Die Speicherkapazitäten einer Swarm-Installation lassen sich einfach erweitern, indem man zusätzliche Laufwerke eingebaut oder neue Storage-Nodes hinzufügt. Die Software integriert neue Laufwerke und Nodes automatisch in den Cluster-Verbund und führt dabei ein Re-Balancing des Gesamtsystems durch.
Für den Test fügten wir zu einem Storage-Node eine zusätzliche Disk hinzu. Diese war in der Cluster-Konsole sofort als freie Speicherkapazität gekennzeichnet. Auch die Erweiterung um einen zusätzlichen Storage-Node war mit wenigen Mausklicks erledigt. Wir erstellten im vCenter eine neue VM-Hülle mit denselben Hardware- und Netzwerkeinstellungen wie bei den vorhandenen Nodes. Beim Einschalten der Hülle startete über die Netzwerkkarte automatisch der PXE-Boot und lud das Swarm-OS in den RAM der VM. In der Storage-Konsole war die neue VM direkt nach dem Hochfahren angezeigt und das Re-Balancing des Storage-Clusters startete.
Swarm bietet mehrere Wege für die Integration des Objektspeichers in bestehende Umgebungen und die Verbindung mit S3-Cloud-Anbietern. Durch den NFS- und SMB-Support lassen sich die Kostenvorteile von Object Storage auch für klassische File-System-Infrastrukturen nutzen.
- Objektspeicher als SDS-Lösung
- Aufbau der Plattform
Lesen Sie mehr zum Thema
