S3-kompatible Objektspeichersysteme [geschlossen]

Ist jemand auf ein nahezu 100% Amazon S3 RESTful API-kompatibles Objektspeichersystem gestoßen?

Was ich will, ist eine Ebene, die über einem beliebigen (vorzugsweise POSIX-) Dateisystem liegt, das eine RESTful-API im Amazon S3-Stil zum Speichern ( PUT), Abrufen ( GET), Stat ( HEAD) und Löschen ( DELETE) mit angemessener Authentifizierung bietet.

Kommerzielle Projekte / Ideen sind ebenfalls willkommen.

HINWEIS:

Ich habe bisher Eukalyptus und Cumulus ausprobiert ; von denen sich Eukalyptus scheinbar blindlings S3-kompatibel nennt. Die Antwort-XML-Dokumente sind überhaupt nicht kompatibel und stellenweise lückenhaft, da überhaupt keine XML-Dokumente vorhanden sind. Cumulus hat es geschafft, die Antwortdokumente recht ähnlich zu halten, scheint aber die Datenintegrität vergessen zu haben!

Lassen Sie mich den letzten Teil erklären: Sowohl Eucalyptus als auch Cumulus unterstützen die Integritätsprüfung, die Amazon S3 anbietet, nicht. Mit S3 können Sie eine Base64 (MD5 (FILE)) zusammen mit der PUT-Anforderung bereitstellen, die dann von S3 überprüft wird, bevor sie mit einem Erfolg antworten. Eukalyptus und Cumulus unterstützen dies nicht. Mit Eukalyptus können wir dies zumindest umgehen, indem wir das im Antwortdokument angegebene MD5 überprüfen (nicht S3-kompatibles Verhalten). In Cumulus ist dies nicht möglich, da es mit nichts reagiert (wie S3). Es wird durch Cumulus noch verschlimmert, indem in der HEADAnfrage kein ETag ausgegeben wird .

Swift ist die Objektspeicher-Engine von OpenStack. Ab der Veröffentlichung von Bexar im Februar 2011 wird eine experimentelle S3-kompatible Middleware beansprucht. Da OpenStack immer mehr Beachtung findet (Canonical verlagert Ubuntu beispielsweise im Oktober dieses Jahres auf Eukalyptus), könnte es sich lohnen, einen Blick darauf zu werfen.

Am Ende musste ich mit Eucalyptus Walrus weitermachen. Obwohl ich einige grundlegende Probleme damit hatte, hatten sie alle mögliche Umgehungsmöglichkeiten.

Vielen Dank für Ihre wertvollen Beiträge!

[HAFTUNGSAUSSCHLUSS: Ich arbeite für Scality]

Amazon ist weiterhin sehr aktiv in Bezug auf seine AWS-Produkte und nimmt sehr häufig Ergänzungen und Änderungen / Verbesserungen an seiner API vor. Es ist dann schwierig, ein nahezu 100% kompatibles Produkt zu finden (insbesondere bei kommerziellen Produkten sind OSS-Produkte wahrscheinlich reaktionsfähiger gegenüber Änderungen). Viele Anbieter von Objekt- / Cloud-Speichern haben einige Zeit mit ihren eigenen Protokollen herumgespielt (Atmos, DDN und sogar OpenStack), aber meistens haben sie die Idee aufgegeben, dass ihr eigenes Protokoll genauso weit verbreitet ist wie S3. Sie alle kündigen (fast?) Jetzt oder in den kommenden Monaten eine S3-kompatible Schnittstelle an. Es ist immerhin der Industriestandard. Der einzige verbleibende Konkurrent könnte CDMI sein, nur weil es standardisiert ist und von SNIA stammt, einer gemeinnützigen Organisation ohne Lieferanten. Aber es'

Was die S3-kompatible Schnittstelle angeht, gibt es einige Optionen, wie Mezeo, die von Ihnen erwähnten (Eucalyptus und Cumulus), OpenStack (obwohl es meiner Meinung nach noch nicht erschienen ist). Die Skalierung ist eine andere davon.

Die S3-Implementierung von Scality (RS2 - REST Storage Service) steht S3 sehr nahe, da unsere Anfragen / Antworten mit denen von S3 übereinstimmen. Einige der mit der S3-Infrastruktur verbundenen Funktionen sind aus offensichtlichen Gründen nicht vorhanden (z. B. Auswahl der Region). Die erforderlichen Befehle sind jedoch vorhanden: GET / PUT / DELETE eines Objekts, Bucket-Erstellung und Auflistung; und reagieren wie S3.

Um Ihr zweites Problem zu beantworten, möchte ich hinzufügen, dass das Produkt von Scality, RING, eine Software-Objektspeicherplattform ist, die die Datenintegritätsprobleme, auf die Sie sich beziehen, durch Prüfsummen und Hintergrund-Integritätsprüfungen aller auf dem RING gespeicherten Objekte löst. Das Speichern eines Objekts ist im Grunde eine Transaktionsabfrage, und wenn ein Objekt als "erfolgreich gespeichert" deklariert wurde, wird dies für immer der Fall sein, mit ständigen Integritätsprüfungen (zum Beispiel bei jedem Lesevorgang).

Ich werde nicht auf Details eingehen. Besuchen Sie unsere Website, um zu erfahren, wie wir Speicheradministratoren von den üblichen Datenverwaltungs-Albträumen befreien und sie nachts schlafen lassen, wenn sie wissen, dass ihre Daten verfügbar sind. Immer. :)

Am besten Marc Villemade @mastachand

Newdreams Ceph verfügt über ein S3-kompatibles FastCgi-Gateway, das dasselbe Objektspeichersystem verwendet wie das Ceph-Dateisystem. ( http://ceph.newdream.net/wiki/RADOS_Gateway ) Noch nicht produktionsbereit, aber regelmäßige Updates.

Openstacks Objektspeicher erwies sich in meinen Tests als zuverlässiger, obwohl S3 nicht mit den von mir verwendeten s3-Bibliotheken oder wirklich mit dem Java-Client von Rackspace für den Speicherdienst für Cloud-Dateien (der eine eigene Version von swift verwendet) kompatibel ist. Das jclouds-Projekt, das sowohl s3- als auch Swift-Unterstützung hat, hat für mich funktioniert.

Sie können sich auch Cloud Foundry vBlob ansehen: https://github.com/cloudfoundry/vblob

Es handelt sich um eine node.js-App (mit Ruby-Wrapper für die CF-Integration), die über jedes Dateisystem, das die VM "sehen" kann, einen fairen Teil des S3-Protokolls implementiert.

Sowohl s3ql (GNU GPL v3) als auch s3backer (GNU GPL v2) machen das, wonach Sie suchen.

Alte / beantworteten Frage, aber https://github.com/basho/riak_cs wurde nur an Quellen offen https://github.com/basho/riak_cs . „Riak CS ist ein Objekt - Speichersystem auf der Riak gebaut Es erleichtert Speichern großer Objekte in Riak und Präsentation einer S3-kompatiblen Schnittstelle. Außerdem bietet es Funktionen zur Änderung der Mandantenfähigkeit, wie Benutzerkonten, Authentifizierung, Zugriffskontrollmechanismen und Berichte zur Kontonutzung. "

Ich bin mir sicher, dass Sie oben so viele Optionen haben, aber Sie sollten OpenStack Swift, einen OpenSource-Objektspeicher, überprüfen und auch S3-kompatible API unterstützen. Es wird als Objektspeicherlösung für Rackspace, Hpcloud Korea Telecom und viele andere verwendet.

Dokumentation http://docs.openstack.org/developer/swift/associated_projects.html Swift3 https://github.com/fujita/swift3 Swift3 Middleware für OpenStack Swift, mit der über die Amazon S3-API auf OpenStack swift zugegriffen werden kann.

Ich hoffe es hilft.

[HAFTUNGSAUSSCHLUSS: Ich arbeite für Cloudian]

Cloudian HyperStore-Objektspeichersoftware ist zu 100% mit der Amazon S3-API kompatibel. Es implementiert alle S3-APIs bis auf die Fehlercodes und alle Funktionen von Amazon S3.

Cloudian HyperStore unterstützt unter anderem das Hochladen mehrerer Teile, die Objektversionierung, die S3-kompatible Zugriffssteuerungsliste, die automatische Zuordnung zu S3 und Glacier, die S3-CORS-Verschlüsselung (Cross-Origin Resource Sharing) sowie Standortbeschränkungen.

Und ja, mit Cloudian können Sie ein Base64 (MD5 (FILE)) zusammen mit der PUT-Anforderung bereitstellen, die dann überprüft wird, bevor Sie mit einem Erfolg antworten.

Weitere Informationen finden Sie in diesem Blogbeitrag unter http://www.cloudian.com/blog/?p=64 und auf der Cloudian-Website unter http://www.cloudian.com/products/cloudian-hyperstore.php

Hast du s3fs ausgecheckt ? Die von Ihnen gewünschte MD5-Überprüfung ist nicht verfügbar ( http://code.google.com/p/s3fs/issues/detail?id=37&q=md5 ), aber es dürfte nicht sehr schwierig sein, diese zu implementieren. Bemerkenswert ist, dass dies letztendlich konsistent ist.