Implementacja katalogu ziarna
Omówienie i architektura
Katalog ziarna w Orleans jest magazynem klucz-wartość, w którym klucz jest identyfikatorem ziarna, a wartość jest wpisem rejestracji wskazującym aktywny silos, który (potencjalnie) hostuje ziarno.
Chociaż Orleans zapewnia domyślną implementację katalogu rozproszonego w pamięci (opisaną w tym artykule), system katalogów grain został zaprojektowany tak, aby był modułowy. Deweloperzy mogą zaimplementować własny katalog, implementując interfejs IGrainDirectory i rejestrując go w kolekcji usług silosu. Umożliwia to implementacje katalogów niestandardowych, które mogą używać różnych zaplecza przechowywania lub modeli spójności w celu lepszego dopasowania do określonych wymagań aplikacji. Od czasu wprowadzenia nowego katalogu o silnej spójności, istnieje małe zapotrzebowanie na implementacje katalogów zewnętrznych, ale interfejs API pozostaje w celu zapewnienia zgodności z poprzednimi wersjami i elastycznością. Katalog ziarna można skonfigurować na podstawie typu ziarna.
Aby zoptymalizować wydajność, wyszukiwanie katalogów jest buforowane lokalnie w każdym silosie. Oznacza to, że potencjalnie zdalne odczyty katalogu są konieczne tylko wtedy, gdy brakuje lokalnego wpisu pamięci podręcznej lub jest on nieprawidłowy. Ten mechanizm buforowania zmniejsza obciążenie sieci i opóźnienia związane z wyszukiwaniem lokalizacji ziarna.
Pierwotnie Orleans zaimplementowano docelowo spójny katalog o strukturze rozproszonej tabeli skrótów. Zostało to zastąpione przez silnie spójny katalog w Orleans w wersji 9.0, w oparciu o dwufazową metodologię wirtualnie synchroniczną, a także ustrukturyzowaną jako rozproszoną tabelę skrótów, ale z ulepszonym równoważeniem obciążenia za pomocą węzłów wirtualnych. W tym artykule opisano drugą, nowszą implementację katalogu ziarna.
Rozproszony katalog ziaren
Dystrybuowany katalog ziarna w Orleans oferuje silną spójność, równomierne rozłożenie obciążenia, wysoką wydajność i odporność na uszkodzenia. Implementacja jest zgodna z dwufazowym projektem opartym na metodologii synchronizacji wirtualnej , wykazując podobieństwa do Pionowego Paxos.
Partycje katalogów mają dwa tryby działania:
- Normalna operacja: partycje przetwarzają żądania lokalnie bez koordynacji z innymi hostami.
- Zmiana widoku: hosty koordynują się ze sobą, aby przenieść własność zakresów katalogów.
Katalog korzysta z systemu członkostwa w klastrze o silnej spójności Orleans, w którym konfiguracje nazywane "widokami" mają monotonicznie rosnące numery wersji. W miarę łączenia i opuszczania silosów w klastrze tworzone są kolejne widoki, co prowadzi do zmian w zakresie zarządzania.
Wszystkie operacje katalogu obejmują koordynację widoku:
- Żądania noszą numer widoku elementu wywołującego.
- Odpowiedzi obejmują numer widoku partycji.
- Niezgodności numerów wyświetleń wyzwalają synchronizację.
- Żądania są automatycznie ponawiane podczas wyświetlania zmian.
Dzięki temu wszystkie żądania są przetwarzane przez odpowiedniego właściciela partycji katalogu.
Strategia partycjonowania
Katalog jest partycjonowany przy użyciu spójnego pierścienia skrótów z zakresami przypisanymi do aktywnych silosów w klastrze. Identyfikatory ziarna są haszowane, aby znaleźć silos, który jest właścicielem sekcji pierścienia odpowiadającej jego skrótem.
Każdy aktywny silos jest właścicielem wstępnie skonfigurowanej liczby zakresów, domyślnie 30 zakresów na silos. Jest to podobne do schematu używanego przez Amazon Dynamo i apache Cassandra, gdzie dla każdego węzła (hosta) jest tworzonych wiele "węzłów wirtualnych" (zakresów).
Rozmiar partycji jest określony przez odległość między jej skrótem a skrótem następnej partycji. Istnieje możliwość podzielenia zakresu między wiele silosów podczas zmiany widoku, co zwiększa złożoność procedury zmiany widoku, ponieważ każda partycja musi potencjalnie koordynować wiele innych partycji.
Wyświetl procedurę zmiany
Partycje katalogów (zaimplementowane w GrainDirectoryPartition) używają blokad zakresów wersji, aby zapobiec nieprawidłowemu dostępowi do zakresów podczas zmian widoku. Blokady zakresu są tworzone podczas zmiany widoku i są zwalniane po zakończeniu zmiany widoku. Te zamki są analogiczne do "klinów" używanych w metodologii Virtual Synchrony.
Gdy wystąpi zmiana widoku, partycja może rosnąć lub zmniejszać:
- Jeśli nowy silos dołączył do klastra, istniejące partycje mogą zmniejszyć się, aby zrobić miejsce.
- Jeśli silos opuścił klaster, pozostałe partycje mogą wzrosnąć, aby przejąć oddzielone zakresy.
Rejestracje katalogów muszą zostać przeniesione ze starego właściciela do nowego właściciela, zanim będzie można obsłużyć żądania. Proces transferu jest zgodny z następującymi krokami:
- Poprzedni właściciel uszczelnia zakres i tworzy migawkę swoich wpisów katalogu.
- Nowy właściciel żąda i stosuje migawkę.
- Nowy właściciel zaczyna realizować żądania dotyczące obsługi zakresu.
- Poprzedni właściciel jest powiadamiany i usuwa migawkę.
Proces odzyskiwania
Gdy host ulega awarii bez prawidłowego przekazania partycji katalogu, kolejni administratorzy partycji muszą przeprowadzić proces odzyskiwania. Obejmuje to:
- Wykonywanie zapytań dotyczących wszystkich aktywnych silosów w klastrze pod kątem rejestracji ziarna.
- Ponowne kompilowanie stanu katalogu dla zakresów, których dotyczy problem.
- Zapewnienie, że nie wystąpią żadne zduplikowane aktywacje ziarna.
Odtworzenie jest konieczne, gdy zmiany członkostwa w klastrze następują szybko. Chociaż członkostwo w klastrze gwarantuje monotoniczność, silosy mogą przegapić pośrednie widoki członkostwa. W takich przypadkach:
- Transfery migawek zostały porzucone.
- Odzyskiwanie jest wykonywane zamiast zwykłego przekazywania partycji do partycji.
- System utrzymuje spójność pomimo braku stanów pośrednich.
Przyszła poprawa członkostwa w klastrze może zmniejszyć lub wyeliminować te scenariusze, zapewniając, że wszystkie widoki są widoczne dla wszystkich silosów.
