Protokoły/algorytmy bicia serca lub najlepsze praktyki
Ostatnio dodałem kilka możliwości równoważenia obciążenia do oprogramowania, które napisałem. Jest to aplikacja sieciowa, która wykonuje niektóre dane na podstawie danych wejściowych pochodzących z bazy danych SQL. Ponieważ chrupanie może być dość intensywne dodałem możliwość posiadania wielu instancji tej aplikacji działających na różnych serwerach, aby podzielić obciążenie, ale ponieważ jest to teraz równoważenie obciążenia jest działaniem ręcznym. Użytkownik musi określić, które instancje pobierają jaką część danych wejściowych domena.
Chciałbym przenieść to na kolejny poziom i zaprogramować instancje, aby automatycznie negocjowały podnoszenie się danych wejściowych i rozpoznawały, czy jedna z nich "znika" (uległa awarii lub została wyłączona), aby Pozostałe instancje mogły przejąć obciążenie uszkodzonej instancji.
Aby to zaimplementować, rozważam użycie prostego protokołu heartbeat między instancjami, aby określić, kto jest online, a kto nie i chociaż nie jest to strasznie skomplikowane chciałbym się dowiedzieć czy są jakieś ustalone protokoły sieciowe (oparte na UDP, TCP lub obu).
Oczywiście dzieje się to często w świecie sieci z klastrem, fail-over i technologii wysokiej dostępności, więc myślę, że w końcu chciałbym wiedzieć, czy są jakieś ustalone protokoły lub algorytmy, które powinienem być świadomy lub zaimplementować.
EDIT
Wydaje się, na podstawie odpowiedzi, że albo nie ma dobrze ugruntowanych protokoły bicia serca lub że nikt o nich nie wie (co oznaczałoby, że nie są one jednak tak dobrze ugruntowane) w takim przypadku po prostu będę toczyć własne.
Podczas gdy żadna z odpowiedzi nie oferowała tego, czego konkretnie Szukałem, zagłosuję na odpowiedź Matta Davisa ponieważ była najbliższa i wskazał dobry pomysł na użycie multicastu.
Dziękuję wszystkim za Wasz czas~
5 answers
Distribued Interactive Simulation (DIS), która jest zdefiniowana w standardzie IEEE Standard 1278, używa domyślnego bicia serca wynoszącego 5 sekund przez transmisję UDP. Dysfunkcja jest zasadniczo stanem podmiotu, który w pełni definiuje stan, w tym pozycję, danego podmiotu. Ze względu na jego zastosowanie w społeczności symulacji, DIS wykorzystuje również koncepcję określaną jako dead-reckoning, aby zapewnić wyższe częstotliwości uderzeń serca, gdy rzeczywista pozycja, na przykład, znajduje się poza biorąc pod uwagę próg jego przewidywanej pozycji.
W Twoim przypadku PDU typu Dis Entity State byłoby przesadą. Wspominam o tym tylko, aby odnotować fakt, że bicie serca może różnić się częstotliwością w zależności od okoliczności. Nie wiem, czy potrzebujesz czegoś takiego do opisanej aplikacji, ale nigdy nie wiadomo.
Dla heartbeats, użyj UDP, nie TCP. Bicie serca jest, z natury, bezpołączeniowym kontrivance, więc wychodzi na to, że UDP (connectionless) jest tutaj bardziej istotne niż TCP (connection-oriented).
O transmisjach UDP należy pamiętać, że transmisja jest ograniczona do domeny broadcast domain . W skrócie, jeśli masz komputery, które są oddzielone urządzeniem warstwy 3, np. routerem, transmisje nie będą działać, ponieważ router nie będzie przesyłać wiadomości nadawanych z jednej domeny nadawanej do drugiej. W tym przypadku polecam użycie multicastu, ponieważ obejmie on domeny transmisji, zapewniając wartość time-To-live (TTL) jest ustawiona wystarczająco wysoko. Jest to również bardziej zautomatyzowane podejście niż ukierunkowane unicast, które wymagałoby od nadawcy znajomości adresu IP odbiorcy w celu wysłania wiadomości.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-09-18 06:44:45
Nadawać bicie serca co t za pomocą UDP; jeśli nie słyszał od Maszyny więcej niż k * t, to zakłada się, że w dół. Należy uważać, aby łączna przepustowość nie była drenażem zasobów. Możesz użyć adresów rozgłoszeniowych IP Lub zachować listę konkretnych adresów IP, dla których pracujesz.
Upewnij się, że bicie serca zawiera "liczbę restartów" oraz "ID maszyny", aby wiedzieć, że poprzedni stan serwera nie jest w pobliżu.
Polecam użycie MapReduce jeśli pasuje. Informatyka zaoszczędziłoby to sporo pracy.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-09-18 01:38:49
Nie jestem pewien, czy to odpowie na pytanie, ale może zainteresuje cię sposób, w jaki klastry serwerów Weblogic działają pod maską. Z książki Mastering BEA WebLogic Server :
[...] WebLogic Server clustering zapewnia luźne połączenie serwerów w klastrze. Każdy serwer w klastrze jest niezależny i nie polega na żadnym innym serwerze dla żadnych podstawowych operacji. Nawet jeśli kontakt z każdym innym serwerem zostanie utracony, każdy serwer będzie nadal działał i być w stanie przetwarzać otrzymane żądania. Każdy serwer w klastrze utrzymuje własną listę innych serwerów w klastrze za pomocą okresowych komunikatów bicia serca. Co 10 sekund każdy serwer wysyła komunikat heartbeat do innych serwerów w klastrze, aby dać im znać, że wciąż żyje. Komunikaty bicia serca są wysyłane za pomocą technologii multicast IP wbudowanej w JVM, dzięki czemu mechanizm ten jest wydajny i skalowalny wraz z rosnącą liczbą serwerów w klastrze. Każdy serwer otrzymuje te wiadomości heartbeat z innych serwerów i używa ich do utrzymywania bieżącej listy członków klastra. Jeśli serwer nie otrzyma trzech komunikatów bicia serca z rzędu od innego serwera, usuwa ten serwer z listy członków, dopóki nie otrzyma kolejnej wiadomości bicia serca z tego serwera. Technologia heartbeat pozwala na dynamiczne dodawanie i usuwanie serwerów z klastra bez wpływu na konfiguracje istniejących serwerów.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-09-18 01:52:46
Przełączniki zawartości Cisco są sprzętowym rozwiązaniem tego problemu. Implementują wirtualny adres IP jako front end do wielu prawdziwych serwerów, których prawdziwe adresy IP są znane przełącznikowi. Przełącznik okresowo wysyła żądania HTTP HEAD do serwerów WWW, aby sprawdzić, czy nadal działają (co oprogramowanie przełącznika nazywa "keepalive", chociaż nie utrzymuje to samego serwera przy życiu). Przełącznik Cisco akceptuje ruch na wirtualnym IP i przekazuje go do rzeczywistych serwerów internetowych, korzystanie z konfigurowalnego równoważenia obciążenia, takiego jak round-robin lub zdefiniowane przez użytkownika równoważenie obciążenia.
Te przełączniki sprzedają się w przedziale $3-10K, chociaż mój partner biznesowy kupił jeden na eBay za około $ 300 rok temu. Jeśli możesz sobie na to pozwolić, stanowią one sprawdzone rozwiązanie sprzętowe na pytanie, Jak mieć usługę rozłożoną w sposób przejrzysty na wielu serwerach. Redhat zawiera wbudowaną konfigurację portów, dzięki czemu możesz zaimplementować swój własny przełącznik Cisco używając taniego pudełka RedHat. Google dla "wirtualny adres ip" i "router treści cisco", aby uzyskać więcej informacji.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-09-18 02:11:37
Oprócz wypróbowania sprzętowych równoważników obciążenia, Możesz również wypróbować wolne oprogramowanie o otwartym kodzie źródłowym, takie jak HAProxy, dostępne dla Linuksa i BSD.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-09-18 02:18:21