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

9

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)?

użytkownik3790827
źródło
Dziękuję za odpowiedź. Więc w zasadzie, jeśli chcę używać wielu modułów równoważących obciążenie do obsługi mojego ruchu, muszę tylko ustawić inną CNAME dla każdego z nich? W szczególności, jeśli potrzebuję 10 modułów równoważenia obciążenia do obsługi ruchu do mojej witryny, czy to jedyny sposób, aby to zrobić?
user3790827,
1
Zalecam pozostawienie pytań otwartych przez co najmniej jeden dzień przed ich zamknięciem. Nawet to zwykle jest pochopne. To, że otrzymałeś odpowiedź, nie oznacza, że ​​jest to jedyna (lub najlepsza) odpowiedź, a zaznaczenie odpowiedzi na pytania zwykle oznacza mniejszą uwagę.
Andrew B,
1
@Anatoly Nie podjąłem jeszcze decyzji. Przejrzałem przedstawione tutaj rozwiązania i rozmawiałem z kilkoma przyjaciółmi, którzy polecili mi inne rozwiązania. Myślę, że w moim przypadku najlepszym rozwiązaniem do tej pory byłoby użycie serwerów VPS od taniego dostawcy, takiego jak DO lub Vultr, które nie oferują wirtualnego adresu IP i użycie metody stosowanej przez Algolię z równoważeniem obciążenia klienta. Potrzebuję HA i skalowalności tylko dla API, dlatego nie byłoby takiej wielkiej rzeczy, jeśli utworzę różne subdomeny dla każdego modułu równoważenia obciążenia. Użytkownicy końcowi widgetu i tak nigdy ich nie zauważą.
user3790827,
@ user3790827 brzmi jak plan. Pomimo tego, że wymagania dotyczące HA i przełączania awaryjnego są zbyt liczne, każdy napotyka ten sam problem, ale nie każdy ma SLA 99,9 (8 godzin przestoju rocznie) lub więcej. Rozwiązania HA są zwykle drogie, a biznes kompromis pomiędzy dostępnością a kosztem. Klienci zwykle akceptują 99,9 i zdają sobie sprawę z potencjalnego przestoju lub zaplanowanych ram czasowych, nawet 100% czasu sprawności nie gwarantuje, że nie będziesz mieć błędów w programowaniu / wdrażaniu / bezpieczeństwie lub ludzkich błędach.
Anatolij,
Zbadałem, że Google Chrome wymusza unieważnienie DNS i zapytanie w przypadku przekroczenia limitu 3 sekund. Nie jestem jednak pewien, czy działają inne przeglądarki.
Anatolij

Odpowiedzi:

12

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

oszust
źródło
Kiedy mówisz „oczywiście twoja infrastruktura musi to obsługiwać” masz na myśli, że potrzebuję dodatkowej maszyny lub maszyny wirtualnej, która będzie wysyłać żądania do modułów równoważenia obciążenia?
user3790827,
2
@ user3790827 Infrastruktura w tym kontekście to sprzęt sieciowy, a nie serwery. ”
Jenny D.
1
Planuję użyć dostawcy chmury, dlatego nie mam bezpośredniej kontroli nad infrastrukturą fizyczną. O co powinienem zapytać mojego dostawcę usług vps?
user3790827,
1
Istnieją tylko abstrakcyjne rekomendacje, ponieważ zależy to od wielu szczegółów. Nie wiemy nawet, czy warto mieć tutaj wiele hostowanych adresów IP - może jego ruch wynosi zaledwie kilkaset Mbit / s. Jeśli potrzebujesz tego, ocenię odpowiednie oprogramowanie, sprawdzę wymagania i dowiem się, który dostawca je obsługuje. Czy DNS RR będzie działać? Pewnie. Czy użyłbym tego? Zależy od tego, do jakiego rodzaju dostępności dąży właściciel firmy, dla której pracuję!
faker
@faker Przepraszam, myślę, że to moja wina, ponieważ nie podałem wystarczająco dużo szczegółów. Chcę zbudować skrypt javascript, który zostanie wstawiony do witryn innych osób i będzie zbierał dane o ruchu (pomyśl Google Analytics), a także będzie uzyskiwał dostęp do serwera w celu wyświetlania statystyk dla każdej strony, na której jest ładowany. Zasadniczo byłby plik javascript, który będzie ładowany dla każdej witryny, na której jest używany.
user3790827,
6

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.

ErikE
źródło
1
Dodam również, że niektóre usługi równoważenia obciążenia obsługują nawiązywanie sesji BGP z pobliskimi routerami, co pozwala skonfigurować rozwiązania Anycast . Jeśli moduł równoważenia obciążenia przestanie działać lub w inny sposób przestanie reklamować VIP (nieudana kontrola stanu), wygrywa następny najlepszy kandydat na routing. Ostatnie zdanie tej odpowiedzi jest jednak niezbędne: naprawdę musisz porozmawiać z administratorami sieci swojej firmy.
Andrew B,
Oto ładny opis tego, co opisujesz
Martin Podval
2

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.

Anatolij
źródło
1
Myślę, że podejście Algolii jest najlepsze dla mojego budżetu i przypadków użycia. Normalnie bym się ponownie używał innej subdomeny dla każdego modułu równoważenia obciążenia, ale ponieważ używa ich tylko widżet JS, użytkownik końcowy nigdy nie zauważy różnicy.
user3790827,
1
Ktoś zasugerował także użycie DNS Cloudflare.com cloudflare.com/features-optimizer do przekierowania ruchu do rezerwowego modułu równoważenia obciążenia, gdy tylko wystąpi awaria w aktualnie używanym module równoważenia obciążenia. cloudflare.com/dns
user3790827