Magazyn obiektów w chmurze: OpenStack Swift i Ceph Object Gateway
OpenStack Swift jest usługą magazynu obiektów, która z kolei jest częścią platformy OpenStack w chmurze. Usługa Swift udostępnia klientom oparty na protokole REST interfejs HTTP, który umożliwia korzystanie z obiektów binarnych, podobnie jak w przypadku usługi Azure Blob Storage. Swift to bezpłatna usługa dostępna dla wszystkich użytkowników na licencji open-source. Umożliwia ona instalację i konfigurację na dowolnym komputerze, dostarczając magazyn obiektów w chmurach publicznych i prywatnych.
Model danych i interfejsy API usługi Swift
Rysunek 11. Model danych Swift
W usłudze SWIFT użytkownicy mają dostęp dokonta umożliwiającego definiowanie kontenerów, które z kolei mogą służyć do przechowywania obiektów. Na przykład załóżmy, że użytkownik ma konto 123456 w usłudze Swift działającej w środowisku swift.mycloud.com i zapisuje obiekt o nazwie picture.jpg w kontenerze images. Pełna ścieżka dostępu do obiektu w tym przykładzie:
https://swift.mycloud.com/v1/123456/images/picture.jpg
Ponieważ usługa Swift korzysta z interfejsu RESTful, używa ona standardowych poleceń dostępu HTTP, takich jak GET, PUT i POST. Ponieważ interfejs API usługi SWIFT jest wymodelowany na wzór interfejsu API S3, mechanizm interfejsu API i obsługiwanych operacji jest podobny. Polecenia są bezstanowe i zależne od kontekstu, w którym są stosowane. Polecenie GET w kontenerze powoduje wyświetlenie wszystkich obiektów przechowywanych w tym kontenerze, podczas gdy polecenie GET na obiekcie powoduje pobranie tego obiektu. Pełna lista operacji usługi Swift jest dostępna w dokumentacji interfejsu API (interfejsu API usługi Swift). Należy zauważyć, że usługi S3 i SWIFT nie są w 100% zgodne z interfejsem API. Na przykład żądania interfejsu API usługi S3, które są związane z rozliczeniami i regionami usługi AWS, nie są replikowane w usłudze Swift.
Należy zauważyć, że usługa Swift obsługuje także uwierzytelniony dostęp użytkowników próbujących uzyskać dostęp do usługi (jako nieuwierzytelniony, publiczny dostęp do usługi Swift). Usługa Swift integruje się z usługą uwierzytelniania usługi OpenStack o nazwie Keystone.
Architektura usługi Swift
Usługa Swift korzysta z architektury wielowarstwowej w celu zapewnienia wydajności, odporności na uszkodzenia, niezawodności i trwałości. Podobnie jak w przypadku innych rozproszonych magazynów danych usługa Swift używa replikacji w celu zapewnienia odporności na uszkodzenia. Jak wskazano w omówieniu interfejsu API usługi Swift, musi ona obsługiwać informacje dotyczące kont, kontenerów i obiektów. W związku z tym usługa Swift uruchamia niezależne procesy, aby śledzić informacje dotyczące poszczególnych warstw w klastrze.
Poniżej wymieniono różne składniki architektury usługi Swift:
Rysunek 12. Architektura klastra Swift
Węzły serwera proxy: są to serwery frontonu, które przetwarzają przychodzące żądania interfejsu API. Klaster usługi Swift może obejmować wiele serwerów proxy do obsługi większych obciążeń żądań przychodzących. Serwer proxy określa serwer transmisji do klienta, do którego ma zostać wysłane żądanie. Serwery proxy koordynują także odpowiedzi i obsługują awarie.
Węzły obiektów: są to rzeczywiste urządzenia magazynujące obiekty, które mogą przechowywać lub pobierać obiekty.
Strefy: usługa Swift umożliwia skonfigurowanie stref dostępności w celu odizolowania granic awarii. Jeśli jest to możliwe, każda replika danych znajduje się w osobnej strefie. Na najniższym poziomie strefa może być pojedynczym serwerem obiektów lub grupą kilku serwerów obiektów. Strefy służą do organizowania serwerów i partycji w taki sposób, aby system mógł tolerować co najmniej jedną awarię w każdej strefie bez utraty danych lub dostępności usług.
Umieszczanie danych w usłudze Swift
Pierścienie: pierścień reprezentuje mapowanie między nazwami konta/kontenera/obiektów i ich lokalizacji fizycznej. Istnieją oddzielne pierścienie dla kont, kontenerów i jeden pierścień obiektu przypadający na każdą zasady magazynu (wyjaśnione poniżej). Gdy inne składniki wymagają wykonania dowolnej operacji na obiekcie, kontenerze lub koncie, muszą one współdziałać z odpowiednim pierścieniem, aby określić jego lokalizację w klastrze. Pierścień obsługuje to mapowanie przy użyciu stref, serwerów obiektów, partycji i replik. Poszczególne partycje w pierścieniu są replikowana domyślnie po 3 razy w klastrze, a lokalizacje partycji są przechowywane w mapowaniu obsługiwanym przez pierścień. Pierścień odpowiada również za określenie, które urządzenia są używane do przekazywania w scenariuszach awarii.
Partycja: usługa Swift używa spójnego tworzenia skrótów w celu określenia, które węzły obiektów w strefie muszą przechowywać obiekty. Każda część pierścienia spójnego wyznaczania skrótów jest znana jako partycja.
Zasady magazynu: Zasady magazynu umożliwiają dostawcom magazynu obiektów rozróżnianie poziomów usług, funkcji i zachowań wdrożenia usługi Swift. Wszystkie zasady magazynu skonfigurowane w usłudze Swift są udostępniane klientowi za pośrednictwem nazwy abstrakcyjnej. Każde urządzenie w systemie jest przypisane do co najmniej jednej zasady magazynu. Jest to realizowane za pomocą wielu pierścieni obiektów, w których poszczególne zasady magazynu mają niezależne pierścienie obiektów mogące obejmować podzestaw sprzętu implementującego konkretne rozróżnienie. Korzystając z zasad magazynu, dostawca usług w chmurze może zapewnić szybki dostęp oparty na dyskach SSD do obiektów dla jednego klienta z wyższym poziomem umowy SLA, zapewniając jednocześnie tradycyjny magazyn oparty na dyskach dla innego klienta z inną umową SLA.
Teraz spójrzmy na przykład sposobu wykonywania operacji na obiektach w usłudze Swift. Załóżmy, że żądanie klienta składa się z żądania PUT obiektu wysyłanego do określonego kontenera. Żądanie zostanie najpierw odebrane przez węzeł serwera proxy, co najpierw spowoduje uwierzytelnienie żądania w celu zapewnienia odpowiedniego dostępu. Następnie serwer proxy przeniesie skrót nazwy obiektu i wyszuka wszystkie trzy lokalizacje partycji, czyli dyski, w których dane powinny być przechowywane, przy użyciu pierścienia obiektu. Następnie proces użyje pierścienia obiektu do wyszukania adresu IP oraz innych informacji dotyczących tych trzech urządzeń.
Po ustaleniu lokalizacji wszystkich trzech partycji proces serwera proxy wysyła obiekt do poszczególnych węzłów magazynu, w których następuje jego umieszczenie w odpowiedniej partycji. Po osiągnięciu kworum (w danym przypadku po zwróceniu co najmniej dwóch z trzech zapisów jako pomyślnych) proces serwera proxy powiadamia klienta o pomyślnym przekazaniu. W ten sposób usługa Swift korzysta z zapisów kworum jako mechanizmu spójności. Na koniec warstwa kontenera jest aktualizowana asynchronicznie w celu odzwierciedlenia w nim nowego obiektu.
Model spójności w usłudze Swift
Usługa Swift została zaprojektowana jako ostatecznie spójny system. Wszystkie dane w usłudze Swift są replikowane między strefami. Ponadto są obsługiwane wersje obiektów. Usługa Swift uruchamia procesy specjalnego przeznaczenia, nazywane replikatorami. Monitorują one stan kont, kontenerów i obiektów. W przypadku znalezienia nowej jednostki lub zaktualizowanej wersji jednostki gwarantuje to, że dane są replikowane do innych serwerów zgodnie z zasadami replikacji klastra.
Usługa Swift wykorzystuje również specjalne procesy nazywane audytorami, które skanują dane przechowywane w klastrze usługi Swift, aby upewnić się, że nie zostały naruszone. Audytor ponownie oblicza sumę kontrolną dla poszczególnych obiektów, aby upewnić się, że są one zgodne. Jeśli wystąpią jakieś rozbieżności, obiekt zostanie przeniesiony do obszaru kwarantanny, a administrator magazynu zostanie powiadomiony o konieczności rozpoczęcia badania.
Brama Ceph Object Gateway
Aby zakończyć dyskusję na temat magazynów obiektów w chmurze, należy wspomnieć o bramie Ceph Object Gateway, znanej również jako RADOSGW. RADOSGW to dodatkowa warstwa nad klastrem magazynu Ceph (RADOS), która udostępnia interfejs HTTP RESTful do współdziałania z obiektami przechowywanymi w magazynie RADOS. Brama Ceph Object Gateway jest unikalna w zakresie obsługi interfejsów API usług Amazon S3 i SWIFT, umożliwiając migrację aplikacji na tę platformę. Brama RADOSGW replikuje modele danych używane w usługach Amazon S3 i Swift oraz udostępnia funkcjonalność podobną do obu tych usług.