Systemy Object Storage zgodne z S3 [zamknięte]

Czy ktoś natknął się na prawie 100% system przechowywania obiektów zgodny z Amazon S3 RESTful API?

To, czego szukam, to warstwa, która znajduje się na dowolnym systemie plików (najlepiej POSIX), który zapewnia interfejs API RESTful w stylu Amazon S3 do przechowywania ( PUT), retrieve ( GET), stat ( HEAD) i delete ( DELETE) z przyzwoitym uwierzytelnieniem.

Mile widziane są także projekty / pomysły komercyjne.

UWAGA:

Do tej pory próbowałem Eukaliptusa i Cumulusa ; z których Eukaliptus wydaje się ślepo nazywać siebie kompatybilnym z S3. Dokumenty XML odpowiedzi w ogóle nie są kompatybilne i są niejednolite w niektórych miejscach bez dokumentów XML. Cumulusowi udało się utrzymać dość podobne dokumenty odpowiedzi, ale wydaje się, że zapomniał o integralności danych!

Pozwól, że wyjaśnię tę drugą część: zarówno Eucalyptus, jak i Cumulus nie obsługują weryfikacji integralności oferowanej przez Amazon S3. To, co możesz zrobić z S3, to dostarczenie Base64 (MD5 (PLIK)) wraz z żądaniem PUT, które następnie zostanie zweryfikowane przez S3, zanim odpowie pomyślnie. Eukaliptus i Cumulus tego nie obsługują. Dzięki Eucalyptus możemy przynajmniej obejść ten problem, sprawdzając MD5 podany w dokumencie odpowiedzi (zachowanie niezgodne z S3). W Cumulusie nie jest to możliwe, ponieważ nie reaguje na nic (jak S3). Sytuację pogarsza jeszcze Cumulus, nie podając ETagu we HEADwniosku.

Swift to mechanizm przechowywania obiektów OpenStack, a od wydania Bexar w lutym 2011 r. Twierdzi, że jest eksperymentalnym oprogramowaniem pośrednim kompatybilnym z S3. Ponieważ OpenStack cieszy się dużym zainteresowaniem (na przykład Canonical przenosi Ubuntu na Eucalyptus w październiku tego roku), warto go zobaczyć.

W końcu musiałem iść naprzód z Eucalyptus Walrus. Chociaż skończyło się na tym, że znalazłem kilka podstawowych problemów, wszystkie miały możliwe obejścia.

Dziękujemy wszystkim za cenny wkład!

[ZASTRZEŻENIE: Pracuję dla Scality]

Amazon pozostaje bardzo aktywny w swoich produktach AWS i bardzo często wprowadza zmiany i ulepszenia do swojego API. Trudno jest zatem znaleźć produkt w 100% zgodny (szczególnie w produktach komercyjnych, prawdopodobnie produkty OSS byłyby bardziej reaktywne na wszelkie zmiany). Wielu dostawców przechowywania obiektów / chmur od pewnego czasu bawi się swoimi własnymi protokołami (Atmos, DDN, nawet szybki OpenStack ..), ale większość z nich porzuciła pomysł, aby ich własny protokół stał się tak powszechny jak S3. Wszyscy (prawie?) Ogłaszają interfejs zgodny z S3 teraz lub w najbliższych miesiącach. Jest to przecież branżowy de facto standard. Jedynym konkurentem może pozostać CDMI tylko ze względu na jego znormalizowany charakter i fakt, że pochodzi on z SNIA, organizacji non-profit, nie sprzedającej. Ale to'

Istnieje kilka opcji, jeśli chodzi o interfejs kompatybilny z S3, jak Mezeo, o których wspomniałeś (Eukaliptus i Cumulus), OpenStack (choć, jak sądzę, nie jest jeszcze dostępny). Scality jest kolejnym z nich.

Implementacja S3 Scality (zwana RS2 - REST Storage Service) jest bardzo zbliżona do S3, ponieważ nasze żądania / odpowiedzi są spójne z tym, co otrzymujesz od S3. Niektóre funkcje związane z infrastrukturą S3 nie są dostępne z oczywistych powodów (na przykład wybór regionu). Ale są tam niezbędne polecenia: GET / PUT / DELETE obiekt, tworzenie i wyświetlanie segmentu; i reagować tak jak S3.

Chciałbym tylko dodać, aby odpowiedzieć na twój drugi problem, że produkt Scality, RING, to platforma do przechowywania obiektów oprogramowania, która rozwiązuje problemy z integralnością danych, o których mówisz, poprzez sumowanie i sprawdzanie integralności w tle wszystkich obiektów przechowywanych w RING. Przechowywanie obiektu jest w zasadzie zapytaniem transakcyjnym, a gdy obiekt zostanie uznany za „pomyślnie zapisany”, na zawsze będzie, ze stałą kontrolą integralności (na przykład przy każdym odczycie).

Nie będę wchodził w szczegóły. możesz przejść na naszą stronę internetową, aby dowiedzieć się, jak złagodzić administratorów pamięci masowej od typowych koszmarów związanych z zarządzaniem danymi i pozwolić im spać w nocy, wiedząc, że ich dane są dostępne. Zawsze. :)

Pozdrawiam, Marc Villemade @mastachand

Ceph firmy Newdream ma kompatybilną z S3 bramę fastcgi, która wykorzystuje ten sam system przechowywania obiektów, co sam system plików Ceph. ( http://ceph.newdream.net/wiki/RADOS_Gateway ) Wciąż nie jest gotowy do produkcji, ale dokonuje regularnych aktualizacji.

Odkryłem, że magazyn obiektów Openstack jest bardziej niezawodny w moich testach, chociaż nie jest zgodny z S3 z bibliotekami s3, których używałem lub tak naprawdę z własnym klientem Java dla rackspace dla ich usługi przechowywania plików w chmurze (która używa własnej wersji swift). Chociaż projekt jclouds, który obsługuje zarówno s3, jak i Swift, zadziałał dla mnie.

Możesz także spojrzeć na Cloud Foundry vBlob: https://github.com/cloudfoundry/vblob

Jest to aplikacja node.js (z opakowaniem Ruby do integracji z CF), która implementuje sporą część protokołu S3 na dowolnym systemie plików, który maszyna wirtualna „widzi”.

Zarówno s3ql (GNU GPL v3), jak i s3backer (GNU GPL v2) robią to, czego szukasz.

Stare / odpowiedzi na pytanie, ale https://github.com/basho/riak_cs zostało właśnie otwarte na https://github.com/basho/riak_cs : „Riak CS to system przechowywania obiektów zbudowany na Riak. Ułatwia przechowujący duże obiekty w Riak i prezentujący interfejs kompatybilny z S3. Zapewnia również funkcje mutantancji, takie jak konta użytkowników, uwierzytelnianie, mechanizmy kontroli dostępu i raportowanie użycia według kont. ”

Jestem pewien, że masz tak wiele opcji powyżej, ale powinieneś sprawdzić OpenStack Swift, to OpenSource Object Storage, a także obsługuje API kompatybilne z S3. Jest używany jako rozwiązanie do przechowywania obiektów dla Rackspace, Hpcloud Korea Telecom i wielu innych.

Dokumentacja http://docs.openstack.org/developer/swift/associated_projects.html Swift3 https://github.com/fujita/swift3 Swift3 Middleware dla OpenStack Swift, umożliwiający dostęp do OpenStack swift poprzez interfejs API Amazon S3.

Mam nadzieję, że to pomoże.

[OŚWIADCZENIE: Pracuję dla Cloudian]

Oprogramowanie do przechowywania obiektów Cloudian HyperStore jest w 100% kompatybilne z interfejsem API Amazon S3. Implementuje wszystkie interfejsy API S3, aż do kodów błędów i wszystkich funkcji, które ma Amazon S3.

Aby wymienić niektóre, Cloudian HyperStore obsługuje przesyłanie wieloczęściowe, wersjonowanie obiektów, ACL kompatybilny z S3, automatyczne warstwowanie do S3 i Glacier, udostępnianie zasobów między różnymi źródłami S3 (CORS), typ kodowania S3, ograniczenie lokalizacji i wiele innych.

Tak, dzięki Cloudian możesz dostarczyć Base64 (MD5 (FILE)) wraz z żądaniem PUT, które następnie zostaną zweryfikowane przed odpowiedzią z powodzeniem.

Aby uzyskać więcej informacji, sprawdź ten post na blogu http://www.cloudian.com/blog/?p=64 i stronę internetową Cloudian pod adresem http://www.cloudian.com/products/cloudian-hyperstore.php

Sprawdziłeś s3fs ? Nie ma w nim czeku MD5, który chcesz ( http://code.google.com/p/s3fs/issues/detail?id=37&q=md5 ), ale przypuszczam, że wdrożenie tego nie byłoby trudne. Warto zauważyć, że ostatecznie jest spójny.