CMG Brasil

Pomegranate to nowatorski rozproszony system plików zbudowany na rozproszonej pamięci tabelarycznej, który działa bardzo podobnie do systemu NoSQL. Jego celem jest zwiększenie wydajności dostępu do małych obiektów w celu wsparcia aplikacji takich jak internetowe serwisy fotograficzne i mikroblogowe, które wymagają wysokiej współbieżności, wysokiej przepustowości i niskich opóźnień. Ich testy wydają się wskazywać, że to działa:

Zademonstrowaliśmy, że system plików nad przechowywaniem tabelarycznym działa dobrze dla wysoce współbieżnego dostępu. W naszym klastrze testowym zaobserwowaliśmy liniowy wzrost ponad 100 000 zagregowanych żądań odczytu i zapisu obsługiwanych na sekundę (RPS).

Raczej niż na szczycie systemu plików, jak prawie każdy inny magazyn K-V, Pomegranate jest upieczony w systemie plików. Chodzi o to, że API systemu plików jest wspólne dla każdej platformy, więc nie wymagałoby oddzielnego API do użycia. Każda aplikacja mogłaby go używać po wyjęciu z pudełka.

Cechami Pomegranate są:

• Obsługuje miliardy małych plików wydajnie, nawet w jednym katalogu;
• Zapewnia oddzielną i skalowalną warstwę buforowania, która może być migawkowa;
• Warstwa przechowywania wykorzystuje log structured store do absorbowania małych zapisów plików w celu wykorzystania przepustowości dysku;
• Buduje globalną przestrzeń nazw zarówno dla małych plików, jak i dużych plików;
• Kolumnowe przechowywanie w celu wykorzystania czasowej i przestrzennej lokalności;
• Dystrybuowany rozszerzalny hash do indeksowania metadanych;
• Snapshot-able i rekonfigurowalne buforowanie w celu zwiększenia równoległości i tolerancji na awarie;
• Pomegranate powinien być pierwszym systemem plików, który jest zbudowany nad tabelaryczną pamięcią masową, a doświadczenie budowania powinno być godne społeczności systemów plików.

Can Ma, który prowadzi badania nad Pomegranate, był na tyle uprzejmy, że zgodził się na krótki wywiad.

Czy możesz proszę dać przegląd architektury i co robisz, że jest fajne i inne?

Podstawowo, nie ma rozproszonego lub równoległego systemu plików, który może obsługiwać miliardy małych plików wydajnie. Jednak możemy przewidzieć, że aplikacje internetowe (takie jak poczta elektroniczna, zdjęcia, a nawet wideo) i bio-komputerowe (sekwencjonowanie genów) potrzebują masowego dostępu do małych plików. Tymczasem, API systemu plików jest wystarczająco ogólne i dobrze zrozumiałe dla większości programistów.

Tak więc, chcemy zbudować system plików do zarządzania miliardami małych plików, i zapewnić wysoką przepustowość współbieżnego dostępu. Chociaż Pomegranate jest zaprojektowany dla dostępu do małych plików, obsługuje również duże pliki. Jest zbudowany na szczycie innych rozproszonych systemów plików, takich jak Lustre, i zarządza tylko przestrzenią nazw i małymi plikami. Chcemy po prostu stanąć na „ramionach gigantów”. Zobacz rysunek poniżej:

Pomegranate ma wiele serwerów metadanych i serwerów przechowywania metadanych do obsługi żądań metadanych i odczytu/zapisu małych plików. MDSy są tylko warstwą buforującą, która ładuje metadane z pamięci masowej i przekazuje migawki pamięci do pamięci masowej. Rdzeniem Pomegranate jest rozproszony system przechowywania danych tabelarycznych o nazwie xTable. Obsługuje on indeksowane kluczem wyszukiwania wielokolumnowe. Używamy rozproszonego rozszerzalnego hasha do lokalizowania serwera na podstawie klucza, ponieważ rozszerzalny hash jest bardziej adaptacyjny do skalowania w górę i w dół.

W systemach plików, tablica katalogów i tablica inode są zawsze oddzielone, aby wspierać dwa różne typy wyszukiwania. Wyszukiwania według nazwy ścieżki są obsługiwane przez tabelę katalogów, podczas gdy wyszukiwania według numeru inode są obsługiwane przez tabelę inode. Konsekwentne aktualizowanie tych dwóch indeksów jest nietrywialne, szczególnie w rozproszonym systemie plików. Tymczasem użycie dwóch indeksów zwiększa opóźnienie wyszukiwania, co jest nie do zaakceptowania przy dostępie do małych plików. Zazwyczaj istnieją pamięci podręczne dla dentry i inode, jednak pamięci podręczne nie mogą być łatwo rozszerzane. Modyfikując metadane trzeba aktualizować wiele lokalizacji. Aby zachować spójność, wprowadzono dziennik operacji. Podczas gdy, dziennik operacji jest zawsze punktem seryjnym dla przepływów żądań.

Pomegranate używa struktury katalogów podobnej do tabeli, aby połączyć tabelę katalogów i tabelę inode. Dwa różne typy wyszukiwania są zunifikowane do wyszukiwania według klucza. Dla systemu plików, kluczem jest wartość hash nazwy dentry. Konflikty hash są rozwiązywane przez globalny unikalny id dla każdego pliku. Dla każdej aktualizacji, musimy tylko wyszukać i zaktualizować jedną tabelę. Aby wyeliminować dziennik operacji, projektujemy i obsługujemy migawki pamięci, aby uzyskać spójny obraz. Brudne regiony każdego snapshotu mogą być bezpiecznie zapisywane w pamięci bez uwzględniania współbieżnych modyfikacji.(Współbieżne aktualizacje są COWed.)

Jednakże istnieją pewne złożone operacje systemu plików, takie jak mkdir, rmdir, hard link i rename, które powinny być brane pod uwagę. Operacje te muszą zaktualizować co najmniej dwie tabele. Zaimplementowaliśmy niezawodną usługę aktualizacji w wielu miejscach, aby propagować delty z jednej tabeli do drugiej. Na przykład, przy mkdir, propagujemy deltę(„nlink +1”) do tabeli nadrzędnej.

Czy istnieją jakieś pojedyncze punkty awarii?

Nie ma żadnego SPOF w projekcie. Używamy klastra MDSów do obsługi żądań metadanych. Jeśli jeden MDS ulegnie awarii, żądania są przekierowywane do innych MDS (używany jest spójny hash i heartbeats). Metadane i małe pliki są replikowane do wielu węzłów albo. Jednak ta replikacja jest wyzwalana przez zewnętrzne narzędzia synchronizacji, które są asynchroniczne do zapisów.

Małe pliki zazwyczaj były śmiercią systemów plików z powodu utrzymania struktury katalogów. Jak to obejść?

Tak, dostęp do małych plików w tradycyjnych systemach plików jest śmiertelnie powolny. Zamieniamy tradycyjną tablicę katalogów (drzewo B+ lub drzewo hashowe) na rozproszoną, rozszerzalną tablicę hashową. Nazwa dentry i metadane inode są traktowane jako kolumny tabeli. Zapytania od klientów są wysyłane (lub kierowane, jeśli trzeba) do właściwego MDS. Tak więc, aby uzyskać dostęp do małego pliku, musimy tylko uzyskać dostęp do jednego wiersza tabeli, aby znaleźć lokalizację pliku. Każdy mały plik jest przechowywany sekwencyjnie w natywnym systemie plików. W rezultacie, jeden dostęp I/O może obsłużyć odczyt małego pliku.

Jakie apisy posixa są obsługiwane? Czy pliki mogą być zablokowane, mapowane, symlinki, itp?

Obecnie, wsparcie POSIX jest w toku. Obsługujemy symlinki, dostęp do mmap. Podczas gdy, flock nie jest obsługiwany.

Dlaczego robimy system plików na poziomie jądra, a nie K-V store na wierzchu?

Naszym początkowym celem jest zaimplementowanie systemu plików do obsługi większej ilości istniejących aplikacji. Obecnie wspieramy interfejs K/V na wierzchu xTable. Zobacz rysunek architektury, klient AMC jest klientem klucz/wartość dla Pomegranate. Obsługujemy proste predykaty na kluczach lub wartościach, na przykład obsługujemy „select * from table where key < 10 and 'xyz’ in value” aby uzyskać pary k/v, których wartość zawiera „xyz” i klucz < 10.

Jak to się ma do innych rozproszonych systemów plików?

Chcemy porównać wydajność małych plików z innymi systemami plików. Jednak jeszcze tego nie przetestowaliśmy. Zrobimy to w ciągu najbliższego miesiąca. Uważamy jednak, że większość rozproszonych systemów plików nie jest w stanie efektywnie obsługiwać masowego dostępu do małych plików.

Czy indeksy i wszelkiego rodzaju zapytania są obsługiwane?

Na razie nie zostały one jeszcze odpowiednio rozważone. Planujemy rozważyć zapytania zakresowe w następnej kolejności.

Czy to działa w różnych centrach danych, to znaczy, jak radzi sobie z opóźnieniami?

Pomegranate działa tylko w centrum danych. Obsługa sieci WAN nie była jeszcze brana pod uwagę.

Wygląda na to, że używacie architektury in-memory dla zwiększenia szybkości. Czy możesz o tym opowiedzieć?

Używamy dedykowanej warstwy pamięci podręcznej dla szybkości. Wiersze tabeli są pogrupowane jako plasterki tabeli. W pamięci, sl
ices tabeli są haszowane w lokalnej rozszerzalnej tabeli haszującej, zarówno dla wydajności, jak i zużycia miejsca. Pokazane na poniższym rysunku,

Klienci wydają żądania przez hashowanie nazwy pliku i lookup w bitmapie. Następnie, używając spójnego pierścienia hash do zlokalizowania serwera cache (MDS) lub serwera pamięci masowej (MDSL). Każda aktualizacja najpierw dostaje *otwartą* grupę transakcji i może być zastosowana tylko do wiersza tabeli w pamięci. Każda zmiana grupy transakcji jest atomowa. Po zakończeniu wszystkich oczekujących aktualizacji, grupa transakcji może być bezpiecznie przekazana do magazynu. To podejście jest podobne do ZFS firmy Sun.

Jak jest obsługiwana wysoka dostępność?

Cóż, centralny serwer do spójnego zarządzania pierścieniem hashowym i koordynator awarii powinien być replikowany przez algorytm Paxos. Planujemy użyć ZooKeeper dla wysokodostępnej usługi centralnej.
Inne komponenty są zaprojektowane tak, aby były odporne na błędy. Awarie MDS i MDSL mogą być skonfigurowane jako odzyskiwane natychmiast poprzez kierowanie żądań do nowych serwerów (poprzez wybór następnego punktu w spójnym pierścieniu hashowym).

Operacyjnie, jak to działa? Jak węzły są dodawane do systemu?

Dodawanie węzłów do warstwy cache jest proste. Serwer centralny (R2) dodaje nowy węzeł do spójnego pierścienia hashującego. Wszystkie serwery cache powinny zareagować na tę zmianę i po prostu unieważnić swoje zbuforowane plasterki tabeli, jeśli będą one zarządzane przez nowy węzeł. Żądania od klientów są kierowane do nowego serwera, a powiadomienie o zmianie pierścienia CH będzie piggyback do klienta, aby wyciągnąć nowy pierścień z serwera centralnego.

Jak radzisz sobie z dużymi plikami? Czy jest to odpowiednie dla strumieniowego przesyłania wideo?

Jak opisano wcześniej, duże pliki są przekazywane do innych rozproszonych systemów plików. Nasza warstwa buforowania nie zostanie zanieczyszczona przez strumieniowe dane wideo.

Coś jeszcze chciałbyś dodać?

Kolejny rysunek przedstawiający interakcję komponentów Pomegranate.

.