Czy można używać wielu modułów równoważenia obciążenia do przekierowywania ruchu na moje serwery aplikacji?

Jestem nowy w równoważeniu obciążenia i zastanawiam się, czy można użyć wielu modułów równoważenia obciążenia w celu przekierowania ruchu do moich serwerów aplikacji. Naprawdę nie rozumiem, jak można to zrobić. Czy nazwa domeny nie powinna pasować jeden do jednego z adresem IP określonego serwera (w tym przypadku IP jednego modułu równoważenia obciążenia)? Jeśli każdy serwer równoważenia obciążenia ma inny adres IP, w jaki sposób żądanie może zostać odebrane przez oba moduły równoważące obciążenie (lub przez 10 modułów równoważących obciążenie lub 50 lub 100)?

Korzystanie z Round Robin DNS nie jest tak świetne ze względu na wysoką dostępność - jeśli jeden serwer przejdzie w tryb offline, klienci nadal będą próbowali się z nim połączyć i czekać na limit czasu.

Istnieją inne sposoby osiągnięcia tego celu.
1) Aktywne / pasywne usługi równoważenia obciążenia
Zasadniczo jeden moduł równoważenia obciążenia obsługuje cały ruch dla jednego adresu IP.
Jeśli moduł równoważący ulegnie awarii, węzeł pasywny włączy się i przejmie adres IP.
Należy pamiętać, że usługi równoważenia obciążenia są w zasadzie tylko ruchem przekierowującym, więc w przypadku małych i średnich witryn może to działać poprawnie.

2) Aktywne / aktywne równoważenia obciążenia
Ten sam adres IP ruchu jest skonfigurowany na obu (lub wielu) równoważeniach obciążenia.
Ruch przychodzący jest wysyłany do wszystkich modułów równoważących obciążenie, ale algorytm wybiera, który moduł równoważący powinien odpowiedzieć, wszystkie inne odrzucają ten ruch.
Prosty sposób myślenia o tym, masz dwa moduły równoważące obciążenie:
gdy żądający adres IP kończy się liczbą parzystą, moduł równoważenia obciążenia A odpowiada, w przeciwnym razie moduł równoważenia obciążenia B odpowiada.

Oczywiście twoja infrastruktura musi to obsługiwać i jest narzut z powodu wysyłania ruchu, ale odrzucania.
Więcej informacji, np. Tutaj: http://community.brocade.com/t5/SteelApp-Docs/Feature-Brief-Deep-dive-on-Multi-Hosted-IP-addresses-in-Stingray/ta-p/73867

Wysoka dostępność z modułami równoważenia obciążenia jest zwykle implementowana przy użyciu protokołu wirtualnego adresu IP (VIP), który pozwala kilku hostom (tj. Modułom równoważącym obciążenie) odpowiadać na jeden wspólny adres IP na jeden z kilku możliwych sposobów (warianty na aktywny / pasywny, aktywny / aktywny) .

Istnieje wiele takich protokołów, te, które widziałem najczęściej przy zwykłych modułach równoważenia obciążenia to VRRP i NLB (a także wiele nieokreślonych protokołów blackboxed w urządzeniach). Rozszerzanie routery i zapory można także napotkać CARP , HRSP , GLSP na przykład.

Ta strategia ma wiele zalet w porównaniu z równoważeniem obciążenia DNS, która jest prostszą strategią (o której jest mowa w innej odpowiedzi).

Równoważenie obciążenia DNS jest obciążone na przykład:

• powolny obrót mechanizmów buforowania dns
• algorytmy ograniczonego równoważenia obciążenia (zwykle tylko round-robin)
• outsourcing decyzji o równoważeniu obciążenia do klienta (poprzez buforowanie rekordu dns)
• Powolne opróżnianie kolejek usług, gdy serwer (tj. Moduł równoważenia obciążenia) jest wyłączany z rotacji (na podstawie rekordów TTL rekordów DSL obsługiwanych przez dostawców usług internetowych i klientów )
• Powolne przełączanie awaryjne po awarii modułu równoważenia obciążenia

Korzystając z wirtualnego protokołu IP dla HA, można wybrać między innymi:

• Wybór algorytmu równoważenia obciążenia między modułami równoważenia obciążenia
• Centralne dla serwera decyzje dotyczące równoważenia obciążenia (fascynujące, na przykład środki oparte na kondycji usług i routing)
• Szybsze opróżnianie kolejek serwisowych, gdy moduł równoważenia obciążenia zostanie wyłączony z obrotu.
• Natychmiastowe przełączanie awaryjne po awarii modułu równoważenia obciążenia

Tylko Ty wiesz, która strategia i protokół najlepiej pasuje do Twojego scenariusza.

Wymagania: mieć praktyczne rozwiązanie, które działa w chmurze lub w dowolnym środowisku, w którym nie ma dostępu do sprzętowych mechanizmów równoważenia obciążenia, protokołów BGP i tym podobnych.

Numer wniosku o dochód aplikacji jest nieznany, ale powinien być na tyle wysoki, aby bez obawy spełniać zwiększone oczekiwania dotyczące obciążenia.

Znajdźmy aplikację o podobnym charakterze obciążenia, na przykład rejestrowanie sklepu i aplikację do wyszukiwania. Znalazłem jeden .

Czego chcą:

1. Zrównoważyć obciążenie kolektorów
2. Oferuj odporność na uszkodzenia, co pozwala nam kontynuować pobieranie danych, jeśli jeden z kolektorów umrze lub wystąpią problemy
3. Skaluj w poziomie wraz ze wzrostem naszych objętości kłód

Czego się nauczyli o ELB:

1. Nie działa zgodnie z oczekiwaniami
2. Problemy z opóźnieniami spowodowane zwiększonym obciążeniem
3. Za mało możliwości monitorowania
4. Zbyt wiele ograniczeń (liczba otwartych portów i protokołów)

Dlaczego wybrali z Route53:

1. „Round Robin jest dość podstawowym równoważeniem obciążenia, ale działa dobrze dla nas z punktu widzenia wydajności”
2. „Korzystamy z kontroli stanu pracy awaryjnej Route 53”.
3. „Jeśli wystąpi problem z kolektorem, Route 53 automatycznie wyłącza go z usługi; nasi klienci nie zauważą żadnego wpływu”.
4. W przypadku trasy 53 nie jest wymagane wstępne rozgrzewanie

Route 53 okazała się najlepszym sposobem dla Loggly na skorzystanie z naszych wysokowydajnych kolektorów, biorąc pod uwagę nasze ogromne objętości kłód, nieprzewidziane zmiany i ciągły rozwój naszej działalności. Jest on zgodny z podstawowymi celami kolektorów: do zbierania danych z prędkością linii sieciowej przy zerowej utracie i pozwala nam korzystać z elastyczności wszystkich usług AWS, z których korzystamy w Loggly.

Ten konkretny przykład pokazuje, że w niektórych scenariuszach (moduł gromadzący dzienniki, usługa reklamowa itp.) Moduł równoważenia obciążenia jest zbędny, a „rozwiązanie sprawdzania poprawności DNS za pomocą okradzin” działa bardzo dobrze.

Zobaczmy, co AWS mówi o przełączeniu awaryjnym DNS:

Dzięki funkcji DNS Failover Route 53 może wykryć awarię Twojej witryny i przekierować użytkowników końcowych do wskazanych przez ciebie alternatywnych lub zapasowych lokalizacji. Przełączanie awaryjne DNS trasy 53 polega na sprawdzaniu kondycji - regularnym przesyłaniu żądań internetowych do punktów końcowych aplikacji z wielu lokalizacji na całym świecie - w celu ustalenia, czy każdy punkt końcowy aplikacji jest w górę, czy w dół.

Ta technika sprawia, że ​​ELB (niewymagany, tylko dla notatki) jest bardziej niezawodny, ponownie opiera się na RR + Health Check:

Przełączanie awaryjne DNS Route 53 obsługuje wszystkie te scenariusze awarii, integrując się z ELB za kulisami. Po włączeniu Route 53 automatycznie konfiguruje i zarządza sprawdzeniami kondycji poszczególnych węzłów ELB.

Zobaczmy teraz, jak to działa za sceną. Oczywistym pytaniem jest, jak radzić sobie z buforowaniem DNS:

Jednak buforowanie DNS może nadal stanowić problem (patrz nasz poprzedni post, w którym omówiono problem z „długim ogonem”), jeśli TTL nie jest przestrzegane przez wszystkie warstwy między twoim klientem a trasą 53. Możesz wtedy zastosować technikę „pomijania pamięci podręcznej”: wysłać zapytanie do unikalnej domeny

("http://<unique-id>.<your-domain>") 

i zdefiniuj symbol wieloznaczny

Record "*.<your-domain>" to match it.

Algolia wprowadziła „strategię ponownych prób klienta”, która działa całkiem dobrze, jeśli twój klient (JS w twoim przypadku) może sobie z tym poradzić:

W końcu wdrożyliśmy podstawową strategię ponownych prób w naszych klientach API. Każdy klient API został opracowany tak, aby mieć dostęp do trzech różnych maszyn. Trzy różne rekordy DNS reprezentowały każdego użytkownika: USERIDID.algolia.io, USERID-2.algolia.io i USERID-3.algolia.io. Naszą pierwszą implementacją było losowe wybranie jednego z rekordów, a następnie ponowienie próby z innym w przypadku awarii.