Sergey Nivens - stock.adobe.com
Swift und Ceph im Vergleich
Die Objekt-Storage-Lösungen Ceph und Swift speichern zwar den gleichen Datentyp, ansonsten unterscheiden sie sich aber in vielen Details und in der Anwendung.
Die Objekt-Storage-Lösungen Ceph und Swift stammen beide aus dem Open-Source-Umfeld. Ceph eröffnet einen flexibleren Zugriff auf Daten und Storage-Informationen, aber das bedeutet nicht, dass es ein besseres Objekt-Storage-System ist als Swift.
Beide Systeme speichern ausschließlich Objekte. Sie zerstückeln Daten in binäre Objekte und replizieren diese Teile auf das Storage. Mit beiden, Ceph und Swift, können Objekt-Storage-Systeme auf einem Linux-Filesystem aufgebaut werden. Häufig wird XFS verwendet, aber es kann auch ein anderes Linux-Filesystem sein.
Beide Systeme wurden in Hinblick auf Skalierbarkeit entwickelt. Deshalb ist es bei beiden einfach, Storage-Knoten hinzuzufügen, wenn sie gebraucht werden.
Hier enden allerdings die Gemeinsamkeiten zwischen beiden Lösungen.
Datenzugriff
Swift wurde von Rackspace als skalierbares Storage für die Cloud entwickelt. Wegen der Cloud-Perspektive wird meist über die RESTful-API darauf zugegriffen. Applikationen können auf Swift direkt, also ohne Umweg übers Betriebssystem, zugreifen und Daten auf dem Swift-Storage ablegen. Das ist in einer reinen Cloud-Umgebung sehr nützlich, kompliziert Swift-Storage aber außerhalb der Cloud.
Ceph-Entwickler zielten stärker auf ein allgemein verwendbares Objekt-Storage-System als Swift. Es gibt dort drei Zugriffsmethoden:
- Zugriff auf Amazon S3-kompatible RESTful-API über ein Rados-Gateway: Hier ist Ceph mit Swift vergleichbar, aber auch mit jeder Amazon-S3-Cloud-Umgebung. Amazon ist die Vorlage für alles, was in modernen Cloud-Umgebungen passiert.
- Ceph FS: Dieses Filesystem ist kompatibel zu POSIX (Portable Operating System Interface). Es läuft auf jeder Linux-Distribution, so dass das Betriebssystem direkt auf Ceph-Storage zugreifen kann.
- Rados Block Device (RBD): RBD ist ein Block-System auf Linux-Kernel-Ebene, mit dem Anwender auf alle Ceph-ähnlichen Linux-Block-Devices zugreifen können.
- iSCSI-Gateway: Diese Erweiterung des Ceph-Projekts wurde durch SUSE eingebracht. Damit können Administratoren ein iSCSI-Gateway auf Ceph laufen lassen. Es verwandelt sich in einen SAN-File-Speicher, auf den jedes OS zugreifen kann.
Weil Ceph noch viel mehr Methoden anbietet, das Objekt-Storage-System anzubinden, ist es einfacher zu nutzen und flexibler als Swift.
Zugriff auf das Objekt-Storage-System
Auch auf einer anderen Ebene unterscheidet sich Ceph radikal von Swift, nämlich darin, wie Clients auf das System zugreifen. In Swift muss ein Client ein Swift-Gateway ansprechen, das eine potenzielle Schwachstelle darstellt, wenn es nur einmal vorhanden ist. Um das Problem zu lösen, implementieren viele Nutzer hier höhere Verfügbarkeiten.
Ceph verwendet ein Object Storage Device (OSD), das auf jedem Storage-Knoten läuft. Ceph kann das OSD kontaktieren, um Informationen über die Storage-Topologie und darüber, wo die Binärobjekte zu finden sind, dort abzufragen. Sie werden gebraucht, um Zugriff auf die Originaldaten zu bekommen. Eine zweite Komponente, die notwendig ist, um auf die Objekt-Storage zuzugreifen, läuft auf dem Client. Deshalb hat Cephs Zugang zum Storage nicht nur einen Eingang. Dadurch ist es flexibler als Swift.
Anwendungen
Es gibt fundamentale Unterschiede in der Organisation von Ceph und Swift, aber das bedeutet nicht, dass eine Lösung besser wäre als die andere. Beide sind gesunde Open-Source-Projekte, die weltweit von Kunden aktiv genutzt werden; Organisationen verwenden sie aber aus unterschiedlichen Gründen.
Ceph leistet am meisten in Umgebungen mit nur einem Standort, die mit virtuellen Maschinen, Datenbanken und anderen Datentypen mit hohen Konsistenzansprüchen interagieren. Swift passt besser zu sehr großen Umgebungen, in denen riesige Datenmengen gehandhabt werden müssen.
Diese Differenz resultiert direkt daraus, wie beide Objekt-Storage-Systeme die Datenkonsistenz in ihren Replikationsalgorithmen handhaben. Ceph-Daten sind über einen Cluster hinweg streng konsistent, während Swift-Daten zwar am Ende konsistent werden, es aber erheblich länger dauert, bis die Daten über den Cluster hinweg synchronisiert sind.
Keine der beiden Lösungen ist besser als die andere; sie dienen unterschiedlichen Zwecken, also werden wohl auch beide längerfristig überleben.
Folgen Sie SearchStorage.de auch auf Twitter, Google+, Xing und Facebook!
