Udostępnij za pośrednictwem

Zarządzanie klastrem w programie Orleans

  • Artykuł

Orleans Zapewnia zarządzanie klastrem za pośrednictwem wbudowanego protokołu członkostwa, który czasami nazywamy członkostwem silosu. 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ą tabelą trwałą typu No-SQL, 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 6 implementacji programu IMembershipTable: oparte na usłudze Azure Table Storage, serwerze SQL, usłudze Apache ZooKeeper, operacji we/wy consul, AWS DynamoDB i emulacji w pamięci na potrzeby programowania.

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. Zaczynamy od opisania wewnętrznej implementacji poniższego Orleansprotokołu członkostwa i późniejszego opisania implementacji .IMembershipTable

Protokół członkostwa podstawowego

  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 jest używana jako unikatowe klucze 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 poleceń ping aplikacji ("czy żyjesz" heartbeats). Polecenia Ping są wysyłane jako bezpośrednie komunikaty z silosu do silosu za pośrednictwem tych samych gniazd TCP, które komunikują się silosy. Dzięki temu polecenia ping w pełni korelują z rzeczywistymi problemami z siecią i kondycją serwera. Każdy silos wysyła polecenie ping do konfigurowalnego zestawu innych silosów. Silos wybiera kogo ping, obliczając spójne skróty tożsamości innych silosów, tworząc wirtualny pierścień wszystkich tożsamości i wybierając silosy następców X na pierścieniu (jest to dobrze znana technika rozproszona nazywana spójnym wyznaczaniem wartości skrótów i jest szeroko używana w wielu rozproszonych tabelach skrótów, takich jak Chord DHT).

  3. Jeśli silos S nie otrzymuje odpowiedzi ping Y z monitorowanych serwerów P, podejrzewa go, pisząc jego sygnaturę czasową podejrzenia w wierszu 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 emituje żądanie dla wszystkich silosów, aby ponownie odczytać tabelę członkostwa (co i tak zrobią okresowo).

  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 nie używamy do tego transakcji magazynu. 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. Konfiguracja: udostępniamy konfigurację domyślną, która została ręcznie dostrojona podczas użycia produkcyjnego na platformie Azure. Obecnie wartością domyślną jest: 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). Pingi są wysyłane co dziesięć sekund i trzeba przegapić trzy pingi, aby podejrzewać silos.

  8. Wymuszanie wykrywania doskonałych awarii — teoretycznie możliwe jest, że silos zostanie uznany za martwy, jeśli utraci komunikację z innymi silosami, podczas gdy sam proces silosu jest nadal uruchomiony. Aby rozwiązać ten problem, gdy silos zostanie uznany za martwy w tabeli, jest uważany za martwy przez wszystkich, nawet jeśli nie jest martwy (po prostu partycjonowane tymczasowo lub komunikaty pulsu 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. Na przykład usługa systemu Windows skonfigurowana do automatycznego ponownego uruchamiania po niepowodzeniu lub wdrożeniu platformy Kubernetes.

  9. Optymalizacja w celu zmniejszenia częstotliwości okresowych odczytów tabel i przyspieszenia wszystkich silosów uczenia się o nowych silosach łączących się i martwych silosach. Za każdym razem, gdy dowolny silos zapisuje wszystko pomyślnie do stołu (podejrzenie, nowe sprzężenie itd.), emituje również do wszystkich innych silosów – "przejdź i ponownie odczytaj tabelę teraz". Silos nie mówi innym, co napisał w tabeli (ponieważ te informacje mogą być już nieaktualne/błędne), po prostu informuje ich, aby ponownie odczytać tabelę. Dzięki temu bardzo szybko dowiemy się o zmianach członkostwa bez konieczności oczekiwania na pełny okresowy cykl odczytu. Nadal potrzebujemy okresowego odczytu, jeśli komunikat "Ponownie odczyt tabeli" zostanie utracony.

Właściwości podstawowego 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 polecenia ping przechodzą bezpośrednio między serwerami, a nie do tabeli. 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 głosy do deklarowania utraconych i pominiętych pingów umożliwiają handel tymi dwoma. 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):

    Podstawowy 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:

    Do dwóch celów używamy magazynu trwałego (tabela platformy Azure, SQL Server, AWS DynamoDB, Apache ZooKeeper lub consul IO KV IMembershipTable ). 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. 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. Orleans Jednak nie będzie można zadeklarować martwego silosu (jeśli wykryje niektóre silosy nie żyje za pośrednictwem pominiętych ping, nie będzie w stanie napisać tego faktu do tabeli), a także nie będzie mógł zezwolić nowym silosom na przyłączenie. Tak więc kompletność będzie cierpieć, ale dokładność nie będzie — partycjonowanie z tabeli nigdy nie spowoduje Orleans zadeklarowania silosu jako martwego przez pomyłkę. 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.

  8. 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.

Rozszerzenie do zamawiania widoków członkostwa

Opisany powyżej podstawowy protokół członkostwa został później rozszerzony w celu obsługi uporządkowanych widoków członkostwa. Krótko opiszemy przyczyny tego rozszerzenia i sposób jego implementacji. Rozszerzenie nie zmienia niczego w powyższym projekcie, po prostu dodaje właściwość, że wszystkie konfiguracje członkostwa są globalnie całkowicie uporządkowane.

Dlaczego warto zamówić widoki członkostwa?

  • Umożliwia to serializowanie łączenia nowych silosów z klastrem. W ten sposób, gdy nowy silos dołącza do klastra, może zweryfikować dwukierunkową łączność z każdym innym silosem, który został już uruchomiony. Jeśli niektóre z nich już przyłączone silosy nie odpowiadają na nie (potencjalnie wskazujące problem z łącznością sieciową z nowym silosem), nowy silos nie może zostać przyłączony. Gwarantuje to, że co najmniej po uruchomieniu silosu istnieje pełna łączność między wszystkimi silosami w klastrze (jest to zaimplementowane).

  • Protokoły wyższego poziomu w silosie, takie jak katalog rozproszony ziarna, mogą korzystać z faktu, że widoki członkostwa są uporządkowane i używają tych informacji do przeprowadzania inteligentniejszego rozpoznawania zduplikowanych aktywacji. W szczególności, gdy katalog dowie się, że 2 aktywacje zostały utworzone, gdy członkostwo było w fluksie, może zdecydować się dezaktywować starszą aktywację utworzoną na podstawie obecnie nieaktualnych informacji o członkostwie.

Rozszerzony protokół członkostwa:

  1. W przypadku implementacji tej funkcji korzystamy z obsługi transakcji w wielu wierszach udostępnianych przez program MembershipTable.

  2. Do tabeli dodamy wiersz wersji członkostwa, który śledzi zmiany tabeli.

  3. Kiedy silos S chce napisać podejrzenie lub deklarację śmierci dla silosu P:

    1. S odczytuje najnowszą zawartość tabeli. Jeśli P jest już martwy, nie rób nic. Inaczej
    2. W tej samej transakcji zapisz zmiany w wierszu P, a także zwiększ numer wersji i zapisz go z powrotem w tabeli.
    3. Oba zapisy są warunkowe z elementami ETag.
    4. Jeśli transakcja przerywa się z powodu niezgodności elementu ETag w wierszu P lub wierszu wersji, spróbuj ponownie.

  4. Wszystkie operacje zapisu w tabeli modyfikują i zwiększają wiersz wersji. W ten sposób wszystkie operacje zapisu w tabeli są serializowane (przez serializowanie aktualizacji do wiersza wersji) i ponieważ silosy tylko zwiększają numer wersji, zapisy są również całkowicie uporządkowane w kolejności rosnącej.

Skalowalność protokołu rozszerzonego członkostwa:

W rozszerzonej wersji protokołu wszystkie zapisy są serializowane za pośrednictwem jednego wiersza. Może to potencjalnie zaszkodzić skalowalności protokołu zarządzania klastrem, ponieważ zwiększa ryzyko konfliktów między współbieżnych zapisów tabeli. Aby częściowo wyeliminować ten problem, silosy ponawiają próbę wszystkich operacji zapisu w tabeli przy użyciu wycofywania wykładniczego. Zaobserwowaliśmy, że rozszerzone protokoły działają płynnie w środowisku produkcyjnym na platformie Azure z maksymalnie 200 silosami. Uważamy jednak, że protokół może mieć problemy ze skalowaniem ponad tysiąc silosów. W takich dużych konfiguracjach aktualizacje wiersza wersji mogą być łatwo wyłączone, zasadniczo utrzymując resztę protokołu zarządzania klastrem i rezygnując z właściwości całkowitej kolejności. Należy również pamiętać, że w tym miejscu odwołujemy się do skalowalności protokołu zarządzania klastrem, a nie pozostałej części programu Orleans. Uważamy, że inne części Orleans środowiska uruchomieniowego (komunikaty, katalog rozproszony, hosting ziarna, łączność klienta z bramą) są skalowalne poza setki silosów.

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. Obecnie mamy sześć implementacji : IMembershipTablena podstawie tabel platformy Azure, programu SQL Server, apache ZooKeeper, consul IO, AWS DynamoDB i emulacji 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. Emulacja w pamięci na potrzeby konfiguracji programistycznej. Używamy specjalnego ziarna systemu o nazwie MembershipTableGrain, dla tej implementacji. 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.

Konfigurowanie

Protokół członkostwa jest konfigurowany za pośrednictwem Liveness elementu w sekcji w Globals pliku OrleansConfiguration.xml . Wartości domyślne zostały dostrojone w latach użycia produkcyjnego na platformie Azure i uważamy, że reprezentują dobre ustawienia domyślne. Ogólnie rzecz biorąc, nie ma potrzeby ich zmieniania.

Przykładowy element konfiguracji:

<Liveness ProbeTimeout="5s"
    TableRefreshTimeout="10s"
    DeathVoteExpirationTimeout="80s"
    NumMissedProbesLimit="3"
    NumProbedSilos="3"
    NumVotesForDeathDeclaration="2" />

Zaimplementowano 4 typy utrzymania. Typ protokołu liveness jest konfigurowany za pośrednictwem atrybutu SystemStore elementu w sekcji w Globals pliku OrleansConfiguration.xml.SystemStoreType

  1. MembershipTableGrain: tabela członkostwa jest przechowywana w ziarnie na silosie podstawowym. Jest to tylko konfiguracja programowania.
  2. AzureTable: tabela członkostwa jest przechowywana w tabeli platformy Azure.
  3. SqlServer: tabela członkostwa jest przechowywana w relacyjnej bazie danych.
  4. ZooKeeper: tabela członkostwa jest przechowywana w zespole ZooKeeper.
  5. Consul: skonfigurowany jako niestandardowy magazyn systemowy za pomocą polecenia MembershipTableAssembly = "OrleansConsulUtils". Aby uzyskać więcej informacji, zobacz Consul-Deployment.
  6. DynamoDB: skonfigurowany jako niestandardowy magazyn systemowy z programem MembershipTableAssembly = "OrleansAWSUtils".

Dla wszystkich typów utrzymania typowe zmienne konfiguracji są definiowane w Globals.Liveness elemecie:

  1. ProbeTimeout: Liczba sekund sondowania innych silosów pod kątem ich życia lub silosu do wysyłania "Jestem żywy" wiadomości pulsu o sobie. Wartość domyślna to 10 sekund.
  2. TableRefreshTimeout: liczba sekund pobierania aktualizacji z tabeli członkostwa. Wartość domyślna to 60 sekund.
  3. DeathVoteExpirationTimeout: czas wygaśnięcia w sekundach na głosowanie śmierci w tabeli członkostwa. Wartość domyślna to 120 sekund
  4. NumMissedProbesLimit: Liczba nieodebranych komunikatów pulsu "Jestem żywa" z silosu lub liczby nieodparzonych sond, które prowadzą do podejrzewania tego silosu jako martwego. Wartość domyślna to 3.
  5. NumProbedSilos: liczba silosów, które sondy silosu są sondy pod kątem aktywności. Wartość domyślna to 3.
  6. NumVotesForDeathDeclaration: Liczba głosów, które nie wygasły, które są potrzebne do zadeklarowania niektórych silosów jako nieaktywnych (powinna być w większości NumMissedProbesLimit). Wartość domyślna to 2.
  7. UseLivenessGossip: Czy używać optymalizacji plotek, aby przyspieszyć rozpowszechnianie informacji o żywo. Ustawieniem domyślnym jest true.
  8. IAmAliveTablePublishTimeout: liczba sekund, które mają być okresowo zapisywane w tabeli członkostwa, że ten silos jest aktywny. Używane tylko do diagnostyki. Wartość domyślna to 5 minut.
  9. NumMissedTableIAmAliveLimit: Liczba nieodebranych aktualizacji "Jestem żywy" w tabeli z silosu, który powoduje zarejestrowanie ostrzeżenia. Nie ma wpływu na protokół liveness. Wartość domyślna to 2.
  10. MaxJoinAttemptTime: liczba sekund próby przyłączenia się do klastra silosów przed rezygnacją. Wartość domyślna to 5 minut.
  11. ExpectedClusterSize: oczekiwany rozmiar klastra. Nie trzeba być bardzo dokładnym, może być nadmiernie najwyższy. Służy do dostrajania algorytmu wycofywania wykładniczego ponownych prób zapisu w tabeli platformy Azure. Wartość domyślna to 20.

Uzasadnienie projektowania

Naturalne pytanie, które można zadać, to dlaczego nie polegać całkowicie na usłudze Apache ZooKeeper dla implementacji członkostwa w klastrze, potencjalnie przy użyciu gotowej obsługi członkostwa w grupach z 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ą (przynajmniej w momencie pisania w lipcu 2015 r. i zdecydowanie, kiedy po raz pierwszy zaimplementowaliśmy ten protokół latem 2011 r. nie było żadnej wersji zookeeper działającej jako usługa hostowana przez żadnego głównego dostawcę usług w chmurze). 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.

Podziękowania

Chcielibyśmy przyznać wkład Alexa Kogana do projektowania i implementacji pierwszej wersji tego protokołu. Ta praca została wykonana w ramach letniego stażu w Microsoft Research latem 2011 roku. Implementacja zooKeeper została IMembershipTable wykonana przez Shay Hazor, implementacja sql IMembershipTable została wykonana przez Veikko Eeva, implementacja AWS DynamoDB IMembershipTable została wykonana przez Gutemberg Ribeiro, a implementacja konsula IMembershipTable została wykonana przez Paula Northa.