Udostępnij za pośrednictwem

Zarządzanie klastrem w programie Orleans

  • Artykuł

Orleans zapewnia zarządzanie klastrem, używając wbudowanego protokołu członkostwa, który czasami nazywamy członkostwem klastra . Celem tego protokołu jest, aby wszystkie silosy (Orleans serwery) uzgodniły zestaw obecnie żywych silosów, wykryły nieudane silosy i pozwoliły nowym silosom dołączyć do klastra.

Protokół opiera się na usłudze zewnętrznej w celu zapewnienia abstrakcji IMembershipTable. IMembershipTable jest płaską trwałą tabelą, która jest używana do dwóch celów. Po pierwsze, jest używany jako punkt spotkania dla silosów, aby znaleźć siebie nawzajem i Orleans klientów, aby znaleźć silosy. Po drugie, służy do przechowywania bieżącego widoku członkostwa (listy żywych silosów) i pomaga koordynować porozumienie w widoku członkostwa.

Obecnie mamy kilka implementacji IMembershipTable: na podstawie Azure Table Storage, Azure Cosmos DB, ADO.NET (PostgreSQL, MySQL/MariaDB, SQL Server, Oracle), Apache ZooKeeper, Consul IO, AWS DynamoDB, MongoDB, Redis, Apache Cassandraoraz implementację w pamięci na potrzeby rozwoju.

Oprócz każdego silosu IMembershipTable uczestniczy w w pełni rozproszonym protokole członkostwa peer-to-peer, który wykrywa nieudane silosy i osiąga porozumienie w sprawie zestawu żywych silosów. Opisujemy wewnętrzną implementację protokołu członkostwa dla Orleansponiżej.

Protokół członkostwa

  1. Po uruchomieniu każdego silosu dodaje wpis dla siebie do dobrze znanej, udostępnionej tabeli przy użyciu implementacji IMembershipTable. Kombinacja tożsamości silosu (ip:port:epoch) i identyfikatora wdrożenia usługi (identyfikator klastra) jest używana jako unikatowy klucz w tabeli. Epoka jest just time w kleszczach, gdy ten silos zaczął, i w związku z tym ip:port:epoch gwarantuje, że będzie unikatowy w danym Orleans wdrożeniu.

  2. Silosy monitorują się bezpośrednio za pośrednictwem sond aplikacji ("czy żyjesz" heartbeats). Sondy są wysyłane jako bezpośrednie komunikaty z silosu do silosu za pośrednictwem tych samych gniazd TCP, których używają silosy do komunikacji. Dzięki temu sondy w pełni skorelują się z rzeczywistymi problemami z siecią i kondycją serwera. Każdy silos bada konfigurowalny zestaw innych silosów. Silos wybiera, kogo sondować, poprzez obliczanie spójnych skrótów z tożsamości innych silosów, tworząc wirtualny pierścień ze wszystkich tożsamości i wybierając X następców silosów na pierścieniu (jest to dobrze znana technika rozproszona o nazwie spójne tworzenie skrótów i jest powszechnie używana w wielu rozproszonych tabelach skrótów, takich jak Chord DHT).

  3. Jeśli silos S nie otrzymuje Y odpowiedzi sondy z monitorowanego serwera P, zaczyna go podejrzewać, zapisując swoje podejrzenie wraz ze znacznikiem czasowym do wiersza serwera P w IMembershipTable.

  4. Jeśli P ma więcej niż Z podejrzeń w ciągu K sekund, S zapisuje, że P jest martwy w wierszu P i wysyła zrzut aktualnej tabeli członkostwa do wszystkich innych silosów. Silosy okresowo odświeżają tabelę, więc migawka jest optymalizacją mającą na celu skrócenie czasu potrzebnego wszystkim silosom do poznania nowego widoku członkostwa.

  5. Więcej szczegółów:

    1. Podejrzenie jest zapisywane w IMembershipTableobiekcie w specjalnej kolumnie w wierszu odpowiadającym P. Kiedy S podejrzewa P pisze: "w czasie TTT S podejrzewaŁ P".

    2. Jedno podejrzenie nie wystarczy, aby zadeklarować P jako martwe. Potrzebujesz podejrzeń Z z różnych silosów w konfigurowalnym przedziale czasu T, zazwyczaj 3 minuty, aby zadeklarować P jako martwy. Podejrzenie jest zapisywane przy użyciu optymistycznej kontroli współbieżności zapewnianej przez program IMembershipTable.

    3. Podejrzany silos S odczytuje wiersz P.

    4. Jeśli S jest ostatnim podejrzanym (było już Z-1 podejrzanych w okresie T, jak napisano w kolumnie podejrzeń), S decyduje się zadeklarować P jako Martwy. W tym przypadku S dodaje się do listy podejrzanych, a także zapisuje w kolumnie Stan P, że P jest martwy.

    5. W przeciwnym razie, jeśli S nie jest ostatnim podejrzanym, S po prostu dodaje się do kolumny podejrzanego.

    6. W obu przypadkach zapis wsteczny używa numeru wersji lub elementu ETag, który został odczytany, więc aktualizacje tego wiersza są serializowane. Jeśli zapis nie powiódł się z powodu niezgodności wersji/elementu ETag, ponawianie prób (odczyt ponownie i spróbuj zapisać, chyba że P został już oznaczony jako martwy).

    7. Na wysokim poziomie ta sekwencja "odczyt, modyfikacja lokalna, zapis zwrotny" jest transakcją. Jednak niekoniecznie używamy do tego transakcji przechowywania. Kod "Transaction" jest wykonywany lokalnie na serwerze i używamy optymistycznej współbieżności dostarczonej przez program , IMembershipTable aby zapewnić izolację i niepodzielność.

  6. Każdy silos okresowo odczytuje całą tabelę członkostwa na potrzeby wdrożenia. W ten sposób silosy dowiedzą się o nowych silosach łączących się i o innych silosach, które są deklarowane jako martwe.

  7. Transmisja migawki: aby zmniejszyć częstotliwość okresowych odczytów tabeli, za każdym razem, gdy silos zapisuje w tabeli (podejrzenie, nowe dołączenie itp.) wysyła migawkę bieżącego stanu tabeli do wszystkich innych silosów. Ponieważ tabela członkostwa jest spójna i monotonicznie wersjonowana, każda aktualizacja tworzy unikatowo wersjonowaną migawkę, którą można bezpiecznie udostępnić. To umożliwia natychmiastowe propagowanie zmian członkostwa bez konieczności czekania na okresowy cykl odczytu. Okresowy odczyt jest nadal utrzymywany jako mechanizm rezerwowy w przypadku niepowodzenia dystrybucji migawek.

  8. Uporządkowane widoki członkostwa: Protokół członkostwa zapewnia, że wszystkie konfiguracje członkostwa są globalnie całkowicie uporządkowane. Ta kolejność zapewnia dwie kluczowe korzyści:

    1. Gwarantowana łączność: gdy nowy silos dołącza do klastra, musi zweryfikować dwukierunkową łączność z każdym innym aktywnym silosem. Jeśli jakikolwiek istniejący silos nie odpowiada (potencjalnie wskazuje na problem z łącznością sieciową), nowy silos nie może zostać przyłączony. Zapewnia to pełną łączność między wszystkimi silosami w klastrze podczas uruchamiania. Zobacz notatkę dotyczącą rozwiązania IAmAlive poniżej, aby uzyskać wyjątek w przypadku odzyskiwania po awarii.

    2. Spójne aktualizacje katalogów: Protokoły wyższego rzędu, takie jak rozproszony katalog ziaren, polegają na wszystkich silosach mających spójny, monotoniczny widok członkostwa. Umożliwia to inteligentniejsze rozpoznawanie zduplikowanych aktywacji ziarna. Aby uzyskać więcej informacji, zobacz dokumentację katalogu grain.

    szczegóły implementacji :

    1. IMembershipTable wymaga atomowych aktualizacji w celu zagwarantowania globalnej całkowitej kolejności zmian.

      • Implementacje muszą aktualizować zarówno wpisy tabeli (listę silosów), jak i numer wersji w sposób atomowy.
      • Można to osiągnąć przy użyciu transakcji bazodanowych (jak w programie SQL Server) lub atomowych operacji porównania i wymiany przy użyciu ETags (jak w Azure Table Storage)
      • Określony mechanizm zależy od możliwości bazowego systemu magazynowania

    2. Specjalny wiersz wersji członkostwa w tabeli śledzi zmiany:

      • Każdy zapis w tabeli (podejrzenia, deklaracje śmierci, łączenia) zwiększa ten numer wersji
      • Wszystkie operacje zapisu są serializowane poprzez ten wiersz za pomocą aktualizacji atomowych
      • Monotonicznie zwiększająca się wersja zapewnia łączną kolejność wszystkich zmian członkostwa

    3. Gdy silos S aktualizuje stan silosu P:

      • S najpierw odczytuje najnowszy stan tabeli
      • W ramach pojedynczej operacji atomowej aktualizuje zarówno wiersz związany z P, jak i zwiększa numer wersji.
      • Jeśli aktualizacja atomowa nie powiedzie się (np. z powodu współbieżnych modyfikacji), operacja zostanie ponowiona z wykładniczym odstępem czasu.

    zagadnienia dotyczące skalowalności:

    Serializowanie wszystkich zapisów w wierszu wersji może mieć wpływ na skalowalność ze względu na zwiększoną rywalizację. Protokół został sprawdzony w produkcji z maksymalnie 200 silosami, ale może stanąć przed wyzwaniami przekraczającymi tysiąc silosów. W przypadku bardzo dużych wdrożeń inne części Orleans (komunikaty, katalog ziarna, hosting) pozostają skalowalne, nawet jeśli aktualizacje członkostwa staną się wąskim gardłem.

  9. domyślna konfiguracja: domyślna konfiguracja została ręcznie dostrojona podczas użycia produkcyjnego na platformie Azure. Domyślnie: każdy silos jest monitorowany przez trzy inne silosy, dwa podejrzenia są wystarczające, aby zadeklarować martwy silos, podejrzenia tylko z ostatnich trzech minut (w przeciwnym razie są nieaktualne). Sondy są wysyłane co dziesięć sekund i należy przegapić trzy sondy, aby podejrzewać silos.

  10. autokontrola: Wykrywacz błędów zawiera pomysły z badań Lifeguard (artykuł, prezentacja, blog) w celu poprawy stabilności klastra podczas katastroficznych zdarzeń, w których duża część klastra doświadcza częściowej usterki. Składnik LocalSiloHealthMonitor ocenia kondycję każdego silosu przy użyciu wielu heurystyki:

    • Stan aktywny w tabeli członkostwa
    • Brak podejrzeń ze strony innych silosów
    • Ostatnie pomyślne odpowiedzi sondy
    • Odebrane ostatnie żądania sondy
    • Czas odpowiedzi puli wątków (elementy robocze wykonywane w ciągu 1 sekundy)
    • Dokładność czasomierza (wypalanie w ciągu 3 sekund od harmonogramu)

    Wynik kondycji silosu wpływa na limity czasu sondy: silosy w złej kondycji (ocenianie 1–8) zwiększyły limity czasu w porównaniu do zdrowych silosów (wynik 0). Ma to dwie korzyści:

    • Daje więcej czasu na powodzenie sond, gdy sieć lub system jest pod obciążeniem
    • Zwiększa prawdopodobieństwo, że niezdrowe silosy zostaną uznane za zakończone, zanim niepoprawnie wyeliminują zdrowe silosy.

    Jest to szczególnie przydatne w sytuacjach, takich jak wyczerpywanie puli wątków, gdzie wolne węzły mogą w przeciwnym razie nieprawidłowo podejrzewać zdrowe węzły, ponieważ nie mogą przetwarzać odpowiedzi wystarczająco szybko.

  11. pośrednie sondowanie: Inna funkcja ratownika, która poprawia dokładność wykrywania błędów, zmniejszając prawdopodobieństwo, że silos w złej kondycji lub podzielony na partycje nieprawidłowo zadeklaruje zdrowy silos martwy. Gdy silos monitorowania ma przed sobą dwie pozostałe próby sondowania dla silosu docelowego, zanim zostanie oddany głos, aby uznać, że jest nieaktywny, stosuje pośrednie sondowanie:

    • Silos monitorujący losowo wybiera innego silosa jako pośrednika i prosi go o zbadanie celu.
    • Pośrednik próbuje skontaktować się z silosem docelowym
    • Jeśli element docelowy nie odpowiada w okresie limitu czasu, pośrednik wysyła negatywne potwierdzenie.
    • Jeśli silos monitorowania otrzymał negatywne potwierdzenie od pośrednika, a pośrednik deklaruje się w dobrej kondycji (poprzez samodzielne monitorowanie, opisane powyżej), silos monitorowania odda głos w celu zadeklarowania martwych celów
    • W przypadku domyślnej konfiguracji dwóch wymaganych głosów, negatywne potwierdzenie z pośredniej sondy liczy się jako oba głosy, co pozwala szybciej uznać silosy za martwe, gdy awaria jest potwierdzona z wielu perspektyw.

  12. Wymuszanie doskonałego wykrywania błędów: Gdy silos zostanie uznany za martwy w tabeli, wszyscy uznają go za martwy, nawet jeśli nie jest martwy (po prostu tymczasowo podzielony lub sygnały kontrolne zostały utracone). Każdy przestaje się z nim komunikować i gdy dowie się, że jest martwy (czytając jego nowy status z tabeli), popełnia samobójstwo i zamyka swój proces. W związku z tym musi istnieć infrastruktura, aby ponownie uruchomić silos jako nowy proces (po uruchomieniu jest generowany nowy numer epoki). Gdy jest hostowana na platformie Azure, odbywa się to automatycznie. Jeśli tak nie jest, wymagana jest inna infrastruktura, taka jak usługa systemu Windows skonfigurowana do automatycznego ponownego uruchamiania po awarii lub wdrożenie platformy Kubernetes.

  13. Co się stanie, jeśli tabela nie jest dostępna przez jakiś czas:

    Gdy usługa magazynu nie działa, jest niedostępna lub występują problemy z komunikacją z nią, Orleans protokół nie deklaruje silosów jako utraconych przez pomyłkę. Silosy operacyjne będą nadal działać bez żadnych problemów. Jednak Orleans nie będzie w stanie zadeklarować martwego silosu (jeśli wykryje, że jakiś silos jest martwy za pośrednictwem nieodebranych sond, nie będzie w stanie zapisać tej informacji do tabeli), a także nie będzie mógł zezwolić na dołączenie nowych silosów. Tak więc kompletność będzie cierpieć, ale dokładność - nie. Partycjonowanie z tabeli nigdy nie spowoduje, że Orleans błędnie zadeklaruje silos jako martwy. Ponadto w przypadku częściowej partycji sieciowej (jeśli niektóre silosy mogą uzyskać dostęp do tabeli, a niektóre nie), może się zdarzyć, że Orleans zadeklaruje martwy silos jako martwy, ale zajmie trochę czasu, dopóki wszystkie inne silosy o tym dowiedzą się. Wykrywanie może być opóźnione, ale Orleans nigdy nie zabije silosu z powodu niedostępności tabeli.

  14. IAmAlive zapisuje dane na potrzeby diagnostyki i odzyskiwania po awarii:

    Oprócz pulsów wysyłanych między silosami każdy silos okresowo aktualizuje znacznik czasu "I Am Alive" w wierszu w tabeli. Służy to dwóm celom:

    1. W przypadku diagnostyki zapewnia administratorom systemu prosty sposób sprawdzania aktywności klastra i określania, kiedy silos był ostatnio aktywny. Sygnatura czasowa jest zwykle aktualizowana co 5 minut.
    2. W przypadku odzyskiwania po awarii, jeśli silos nie zaktualizował sygnatury czasowej przez kilka okresów (skonfigurowanych za pośrednictwem NumMissedTableIAmAliveLimit), nowe silosy będą go ignorować podczas sprawdzania łączności przy uruchamianiu, co pozwala klastrowi odzyskać sprawność w sytuacjach, gdy silosy uległy awarii bez odpowiedniego czyszczenia.

Tabela członkostwa

Jak już wspomniano, IMembershipTable jest używany jako punkt spotkania dla silosów, aby znaleźć siebie nawzajem i Orleans klientów do znajdowania silosów, a także pomaga koordynować umowę w widoku członkostwa. Główne repozytorium Orleans zawiera implementacje dla wielu systemów, takich jak Azure Table Storage, Azure Cosmos DB, PostgreSQL, MySQL/MariaDB, SQL Server, Apache ZooKeeper, Consul IO, Apache Cassandra, MongoDB, Redis, AWS DynamoDB i implementacja w pamięci na potrzeby programowania.

  1. Azure Table Storage — w tej implementacji używamy identyfikatora wdrożenia platformy Azure jako klucza partycji i tożsamości silosu (ip:port:epoch) jako klucza wiersza. Razem gwarantują unikatowy klucz na silos. W przypadku kontrolki współbieżności używamy optymistycznej kontroli współbieżności opartej na elementach ETag tabel platformy Azure. Za każdym razem, gdy odczytujemy z tabeli, przechowujemy element ETag dla każdego wiersza odczytu i używamy tego elementu ETag podczas próby zapisania z powrotem. Znaczniki ETag są automatycznie przypisywane i sprawdzane przez usługę Azure Table Service na każdym zapisie. W przypadku transakcji wielowierszowych korzystamy z obsługi transakcji wsadowych udostępnianych przez tabelę platformy Azure, co gwarantuje serializacji transakcji w wierszach z tym samym kluczem partycji.

  2. SQL Server — w tej implementacji skonfigurowany identyfikator wdrożenia służy do rozróżniania wdrożeń i silosów należących do których wdrożeń. Tożsamość silosu jest definiowana jako kombinacja deploymentID, ip, port, epoch w odpowiednich tabelach i kolumnach. Zaplecze relacyjne używa optymistycznej kontroli współbieżności i transakcji, podobnie jak procedura używania elementów ETag w implementacji tabel platformy Azure. Implementacja relacyjna oczekuje, że aparat bazy danych wygeneruje używany element ETag. W przypadku programu SQL Server w programie SQL Server 2000 wygenerowany element ETag jest jednym uzyskanym z wywołania metody .NEWID() W programie SQL Server 2005 lub nowszym jest używana wersja ROWVERSION . Orleans odczytuje i zapisuje relacyjne znaczniki ETag jako nieprzezroczyste VARBINARY(16) tagi i przechowuje je w pamięci jako ciągi zakodowane w formacie base64 . Orleans Obsługuje wstawianie wielu wierszy przy użyciu ( UNION ALL w przypadku programu Oracle, w tym PODWÓJNE), które jest obecnie używane do wstawiania danych statystycznych. Dokładna implementacja i uzasadnienie dla programu SQL Server można zobaczyć w CreateOrleansTables_SqlServer.sql.

  3. Apache ZooKeeper — w tej implementacji używamy skonfigurowanego identyfikatora wdrożenia jako węzła głównego i tożsamości silosu (ip:port@epoch) jako węzła podrzędnego. Razem gwarantują wyjątkową ścieżkę na silos. W przypadku kontroli współbieżności używamy optymistycznej kontroli współbieżności opartej na wersji węzła. Za każdym razem, gdy odczytujemy z węzła głównego wdrożenia, przechowujemy wersję dla każdego węzła silosu podrzędnego odczytu i używamy tej wersji podczas próby zapisania z powrotem. Za każdym razem, gdy dane węzła zmieniają się, numer wersji zwiększa się niepodziecznie przez usługę ZooKeeper. W przypadku transakcji wielowierszowych korzystamy z wielowierszowej metody, która gwarantuje serializacji transakcji w węzłach silosu z tym samym nadrzędnym węzłem identyfikatora wdrożenia.

  4. Consul IO — użyliśmy magazynu klucz/wartość konsula w celu zaimplementowania tabeli członkostwa. Aby uzyskać więcej informacji, zobacz Consul-Deployment.

  5. AWS DynamoDB — w tej implementacji używamy identyfikatora wdrożenia klastra jako klucza partycji i tożsamości Silo (ip-port-generation) jako klucza rangekey tworzącego jedność rekordu. Optymistyczna współbieżność jest dokonana przez ETag atrybut przez wykonywanie warunkowych zapisów w bazie danych DynamoDB. Logika implementacji jest bardzo podobna do usługi Azure Table Storage.

  6. Apache Cassandra — w tej implementacji używamy kombinacji identyfikatora usługi i identyfikatora klastra jako klucza partycji oraz tożsamości silosu (ip:port:epoch) jako klucza wiersza. Razem gwarantują unikatowy wiersz dla każdego silosu. W przypadku kontrolki współbieżności używamy optymistycznej kontrolki współbieżności opartej na statycznej wersji kolumny przy użyciu uproszczonej transakcji. Ta kolumna wersji jest współdzielona dla wszystkich wierszy w partycji/klastrze, dlatego zapewnia spójny numer wersji przyrostowej dla tabeli członkostwa każdego klastra. W tej implementacji nie ma transakcji wielowierszowych.

  7. Emulacja w pamięci na potrzeby konfiguracji programistycznej. Do tej implementacji używamy specjalnego ziarna systemu. To ziarno znajduje się na wyznaczonym silosie podstawowym, który jest używany tylko do konfiguracji programowania. W żadnym rzeczywistym użyciu produkcji podstawowy silos nie jest wymagany.

Uzasadnienie projektowania

Naturalnym pytaniem jest, dlaczego nie polegać całkowicie na Apache ZooKeeper lub etcd dla implementacji członkostwa w klastrze, potencjalnie przy użyciu gotowej obsługi ZooKeeper dla członkostwa w grupach za pomocą efemerycznych węzłów? Dlaczego przeszkadzało nam zaimplementowanie naszego protokołu członkostwa? Były przede wszystkim trzy powody:

  1. Wdrażanie/hosting w chmurze:

    Zookeeper nie jest usługą hostowaną. Oznacza to, że w środowisku Orleans chmury klienci musieliby wdrożyć/uruchomić/zarządzać swoim wystąpieniem klastra ZK. Jest to po prostu kolejny niepotrzebny ciężar, którego nie chcieliśmy wymuszać na naszych klientach. Korzystając z tabeli platformy Azure, korzystamy z hostowanej, zarządzanej usługi, która znacznie upraszcza życie naszego klienta. Zasadniczo w chmurze użyj chmury jako platformy, a nie jako infrastruktury. Z drugiej strony, w przypadku uruchamiania lokalnych serwerów i zarządzania nimi, poleganie na kluczu ZK jako implementacji IMembershipTable elementu jest opłacalną opcją.

  2. Wykrywanie błędów bezpośrednich:

    W przypadku korzystania z członkostwa w grupie ZK w węzłach efemerycznych wykrywanie błędów jest wykonywane między Orleans serwerami (klientami ZK) i serwerami ZK. Może to niekoniecznie być skorelowane z rzeczywistymi problemami sieciowymi między serwerami Orleans . Naszym pragnieniem było, aby wykrywanie błędów dokładnie odzwierciedlało stan komunikacji wewnątrz klastra. W szczególności, w naszym projekcie, jeśli Orleans silos nie może komunikować się z IMembershipTable nim nie jest uważany za martwy i może kontynuować pracę. W przeciwieństwie do tego, czy użyliśmy członkostwa w grupie ZK z węzłami efemerycznym rozłączenie z serwerem ZK może spowodować Orleans , że silos (klient ZK) zostanie zadeklarowany jako martwy, podczas gdy może być aktywny i w pełni funkcjonalny.

  3. Przenośność i elastyczność:

    W ramach Orleansfilozofii nie chcemy wymuszać silnej zależności od żadnej konkretnej technologii, ale raczej mieć elastyczny projekt, w którym różne składniki można łatwo przełączać przy użyciu różnych implementacji. Jest to dokładnie cel, który IMembershipTable służy abstrakcji.

Właściwości protokołu członkostwa

  1. Może obsłużyć dowolną liczbę błędów:

    Nasz algorytm może obsługiwać dowolną liczbę błędów (czyli f<=n), w tym pełne ponowne uruchomienie klastra. Jest to w przeciwieństwie do "tradycyjnych" rozwiązań opartych na rozwiązaniach Paxos , które wymagają kworum, co zwykle jest większością. Widzieliśmy w sytuacjach produkcyjnych, gdy ponad połowa silosów spadła. Nasz system pozostał funkcjonalny, podczas gdy członkostwo oparte na paxos nie będzie w stanie poczynić postępów.

  2. Ruch do tabeli jest bardzo lekki:

    Rzeczywiste sondy przechodzą bezpośrednio między serwerami, a nie do tabeli, jak można by pomyśleć. Spowodowałoby to wygenerowanie dużej liczby ruchu plus byłoby mniej dokładne z perspektywy wykrywania błędów - jeśli silos nie mógł dotrzeć do stołu, brakowałoby pisania jego jestem żywy puls, a inni go zabiją.

  3. Możliwość dostosowania dokładności w porównaniu z kompletnością:

    Chociaż nie można osiągnąć zarówno doskonałego, jak i dokładnego wykrywania błędów, zwykle chce mieć możliwość kompromisu dokładności (nie chcesz zadeklarować silosu, który żyje jako martwy) z kompletnością (chcesz zadeklarować martwy silos, który jest rzeczywiście martwy tak szybko, jak to możliwe). Konfigurowalne ustawienia pozwalające na deklarowanie sond jako martwe lub zgubione umożliwiają zamianę tych dwóch. Aby uzyskać więcej informacji, zobacz Yale University: Computer Science Failure Detectors (Uniwersytet Yale: narzędzia do wykrywania błędów informatyki).

  4. Scale (Skala):

    Protokół może obsługiwać tysiące, a prawdopodobnie nawet dziesiątki tysięcy serwerów. Jest to w przeciwieństwie do tradycyjnych rozwiązań opartych na rozwiązaniach Paxos, takich jak protokoły komunikacyjne grupy, które są znane, aby nie skalować poza dziesiątki.

  5. Diagnostyka:

    Tabela jest również bardzo wygodna w przypadku diagnostyki i rozwiązywania problemów. Administratorzy systemu mogą natychmiast znaleźć w tabeli bieżącą listę żywych silosów, a także zobaczyć historię wszystkich zabitych silosów i podejrzeń. Jest to szczególnie przydatne podczas diagnozowania problemów.

  6. Dlaczego potrzebujemy niezawodnego magazynu trwałego na potrzeby implementacji elementu IMembershipTable:

    Używamy trwałego magazynu dla IMembershipTable do dwóch celów. Po pierwsze, jest używany jako punkt spotkania dla silosów, aby znaleźć siebie nawzajem i Orleans klientów, aby znaleźć silosy. Po drugie, używamy niezawodnego magazynu, aby pomóc nam koordynować umowę w widoku członkostwa. Chociaż przeprowadzamy wykrywanie błędów bezpośrednio w sposób równorzędny między silosami, przechowujemy widok członkostwa w niezawodnym magazynie i używamy mechanizmu kontroli współbieżności dostarczonego przez ten magazyn, aby osiągnąć porozumienie o tym, kto żyje i kto nie żyje. W ten sposób nasz protokół udostępnia twardy problem rozproszonego konsensusu do chmury. W tym celu w pełni wykorzystujemy możliwości podstawowej platformy w chmurze, używając jej tak naprawdę jako platformy jako usługi (PaaS).

  7. Bezpośrednie zapisy IAmAlive w tabeli tylko do diagnostyki:

    Oprócz pulsów wysyłanych między silosami każdy silos okresowo aktualizuje kolumnę "I Am Alive" w swoim wierszu w tabeli. Ta kolumna "I Am Alive" jest używana tylko do ręcznego rozwiązywania problemów i diagnostyki i nie jest używana przez sam protokół członkostwa. Zwykle jest zapisywany z znacznie niższą częstotliwością (raz na 5 minut) i służy jako bardzo przydatne narzędzie dla administratorów systemu w celu sprawdzenia aktywności klastra lub łatwego ustalenia, kiedy silos był ostatnio aktywny.

Podziękowania

Chcielibyśmy przyznać wkład Alexa Kogana w projekt i implementację pierwszej wersji tego protokołu. Ta praca została wykonana w ramach letniego stażu w Microsoft Research latem 2011 roku. Implementacja IMembershipTable ZooKeeper została wykonana przez Shay Hazor, implementacja IMembershipTable SQL została wykonana przez Veikko Eeva, implementacja IMembershipTable AWS DynamoDB została wykonana przez Gutemberg Ribeiro i implementacja IMembershipTable opartego na Consul została wykonana przez Paul North, a w końcu wdrożenie IMembershipTable Apache Cassandra zostało dostosowane z OrleansCassandraUtils przez Arshia001.