Często widzę architektury aplikacji internetowych z SLB / reverse-proxy przed wieloma serwerami aplikacji.
Co się stanie, gdy liczba połączeń z SLB wymaga zbyt wielu zasobów, aby jedna SLB mogła skutecznie obsługiwać? Na konkretny, ale przesadny przykład, rozważ 2 miliony trwałych połączeń HTTP. Oczywiście jedna SLB nie może sobie z tym poradzić.
Jaka jest zalecana konfiguracja dla skalowania się do SLB?
Czy typowe jest tworzenie grupy / klastra banków lokalnych? Jeśli tak, w jaki sposób obciążenie klienta rozkłada się na grupę banków lokalnych?
Odpowiedzi:
Równoważenie obciążenia nie może być łatwo skalowane przez inne moduły równoważenia obciążenia, ponieważ z natury będzie istniał pojedynczy moduł równoważenia obciążenia na łańcuchu utrzymujący połączenia. To powiedziawszy, równoważniki takie jak LVS lub HAProxy mają absurdalną pojemność w zakresie Gb / s. Gdy przekroczysz możliwości pojedynczego modułu równoważenia obciążenia (oprogramowanie, sprzęt, cokolwiek innego), musisz przejść do innych technik, takich jak okrągły robin DNS.
źródło
OK, odpowiedź jest już zaakceptowana, ale jest coś do dodania. Najczęstsze „klasyczne” sposoby skalowania warstwy modułu równoważenia obciążenia to (w określonej kolejności):
Round Round Robin, aby opublikować wiele adresów IP dla domeny. Dla każdego adresu IP zaimplementuj wysoce dostępną parę serwerów (2 serwery współpracujące w utrzymaniu pracy jednego adresu IP przez cały czas). Każdy adres IP odpowiada jednemu klastrowi usługi równoważenia obciążenia, przy użyciu urządzeń lub serwerów z oprogramowaniem do równoważenia obciążenia. Skaluj w poziomie, dodając w razie potrzeby więcej par modułu równoważenia obciążenia.
Poprawki routingu lub zapory ogniowej w celu rozłożenia obciążenia na wiele modułów równoważenia obciążenia. Poproś routera przedniego lub zaporę przednią o rozłożenie połączeń przychodzących na kilka adresów IP (każdy reprezentujący jedną parę modułu równoważenia obciążenia), mieszając źródłowy adres IP , mając wiele równych kosztów tras do modułów równoważenia obciążenia lub podobnych.
Warstwa modułu równoważenia obciążenia na poziomie IP przed warstwą modułu równoważenia obciążenia na poziomie HTTP . Równoważenie obciążenia w warstwie IP można zaimplementować w układach ASIC / silicon, a w niektórych przypadkach może być szybkie. W ten sposób jedna para modułu równoważenia obciążenia IP może często „nadążać” za kilkoma modułami równoważenia obciążenia HTTP / HTTPS i zapewniać poziomy wydajności na poziomie wielu gigabitów, utrzymując jednocześnie architekturę ładną i prostą.
Przejście dogłębnie na różne sposoby wykonywania powyższych czynności wymagałoby bardzo długiej odpowiedzi. Ale ogólnie skalowanie warstwy usługi równoważenia obciążenia nie jest trudne, znacznie trudniej jest skalować warstwę serwera aplikacji, a zwłaszcza warstwę bazy danych.
Niezależnie od tego, czy wybierzesz format urządzenia (F5, Cisco, A10), czy zwykły serwer (oprogramowanie Windows / Linux +), ma mniejsze znaczenie. Najważniejsze kwestie dotyczące skalowania warstwy równoważenia obciążenia to:
Zasadniczo nie musisz się tym martwić, zanim twoja strona stanie się bardzo duża - pojedynczy nowoczesny serwer z fx nginx obsłuży dziesiątki tysięcy zwykłych żądań HTTP na sekundę. Więc nie rób przedwczesnej optymalizacji, nie zajmuj się tym zanim będziesz musiał.
źródło
Kluczem do skalowania warstwy równoważenia obciążenia HTTP jest najpierw dodanie kolejnej warstwy równoważenia obciążenia niższego poziomu (IP lub TCP). Warstwę tę można zbudować w całości za pomocą oprogramowania typu open source, chociaż lepsze wyniki uzyskasz, jeśli posiadasz nowoczesne routery.
Przepływy (sesje TCP) powinny być zaszyfrowane przy użyciu nagłówków, takich jak źródłowy / docelowy port IP i porty TCP, aby zdecydować, do którego frontendu się udają. Potrzebujesz również mechanizmu, aby upewnić się, że gdy interfejs umiera, przestaje się przyzwyczajać.
Istnieją różne strategie, przedstawię kilka, które wykorzystałem w produkcji w witrynach obsługujących miliony użytkowników, abyś mógł uzyskać pomysł. To byłoby zbyt długie, aby wyjaśnić wszystko szczegółowo, ale mam nadzieję, że ta odpowiedź dostarczy ci wystarczających informacji / wskazówek, aby zacząć. Aby wdrożyć te rozwiązania, będziesz potrzebować kogoś, kto ma naprawdę dużą wiedzę na temat sieci.
Wprawdzie to, co tu opisuję, jest znacznie trudniejsze do wdrożenia niż to, co opisano w innych odpowiedziach, ale tak naprawdę jest to najnowocześniejsze, jeśli masz witrynę o dużym natężeniu ruchu z dużymi problemami ze skalowalnością i dostępnością powyżej 99,9% . Pod warunkiem, że masz już inżyniera sieciowego, to kosztuje mniej na instalacji i uruchomieniu (zarówno w nakładach inwestycyjnych, jak i operacjach operacyjnych) niż w urządzeniach do równoważenia obciążenia i można go skalować dalej prawie bez dodatkowych kosztów (w porównaniu z zakupem nowego, jeszcze więcej drogie urządzenie, gdy przerosniesz swój obecny model).
Pierwsza strategia: z zaporą ogniową
Przypuszczalnie masz kilka routerów, do których podłączone są łącza wysyłające twojego ISP. Twój dostawca usług internetowych zapewnia 2 linki (aktywne / pasywne, przy użyciu VRRP). Na routerach korzystasz także z VRRP i kierujesz ruch do sieci publicznej do zapory. Zapory ogniowe (
FW 1
iFW 2
poniżej) również są aktywne / pasywne i będą filtrować ruch i wysyłać każdy przepływ do zdrowego serwera frontendowego (do równoważników obciążenia HTTPFE 1
iFE 2
niższych).Celem jest, aby przepływ wyglądał tak:
Teraz magia dzieje się w krokach 4 i 5, więc zobaczmy bardziej szczegółowo, co robią.
Twoja zapora ogniowa zna listę frontendów (
FE 1
iFE 2
) i wybierze jeden z nich na podstawie określonego aspektu przepływu (np. Mieszając źródłowe IP i port, między innymi nagłówkami). Ale musi także upewnić się, że przekierowuje ruch do zdrowej nakładki, w przeciwnym razie zablokujesz ruch. Jeśli na przykład używasz OpenBSD, możesz użyćrelayd
. Corelayd
robi jest proste: sprawdza poprawność wszystkich twoich nakładek (np. wysyłając im zapytanie HTTP z sondą), a ilekroć nakładka jest zdrowa, dodaje ją do tabeli używanej przez zaporę ogniową do wybierania następnego przeskoku pakietów danego przepływu . Jeśli interfejs nie przejdzie kontroli poprawności, zostanie usunięty ze stołu i żadne pakiety nie będą już do niego wysyłane. Podczas przesyłania pakietu do interfejsu użytkownika zapora zamienia docelowy adres MAC pakietu na adres wybranego interfejsu.W kroku 5 pakiety od użytkownika są odbierane przez moduł równoważenia obciążenia (czy to Lakier, Nginx lub cokolwiek innego). W tym momencie pakiet jest nadal kierowany na twój publiczny adres IP, więc musisz aliasować swoich VIPów na interfejsie sprzężenia zwrotnego. Nazywa się to DSR (Direct Server Return), ponieważ twoje interfejsy kończą połączenie TCP, a zapora pomiędzy nimi widzi tylko ruch simpleks (tylko pakiety przychodzące). Router skieruje wychodzące pakiety bezpośrednio z powrotem do routerów usługodawcy internetowego. Jest to szczególnie dobre w przypadku ruchu HTTP, ponieważ żądania są zwykle mniejsze niż odpowiedzi, czasem znacznie większe. Żeby było jasne: nie jest to kwestia specyficzna dla OpenBSD i jest szeroko stosowana w witrynach o dużym natężeniu ruchu.
Gotchas:
Druga strategia: bez zapory ogniowej
Ta strategia jest bardziej wydajna, ale trudniejsza do skonfigurowania, ponieważ zależy bardziej od specyfiki posiadanych routerów. Chodzi o to, aby omijać zaporę powyżej i pozwolić routerom wykonać całą pracę, którą wykonują zapory ogniowe.
Będziesz potrzebować routerów obsługujących listy ACL L3 / L4 na port, BGP i ECMP oraz routing oparty na zasadach (PBR). Tylko routery wysokiej klasy obsługują te funkcje i często mają dodatkowe opłaty licencyjne za korzystanie z BGP. Jest to zwykle nadal tańsze niż sprzętowe równoważenia obciążenia, a także znacznie łatwiejsze do skalowania. Dobrą rzeczą w tych routerach z wyższej półki jest to, że mają tendencję do liniowej szybkości (np. Zawsze mogą maksymalnie wykorzystać łącze, nawet na interfejsach 10GbE, ponieważ wszystkie decyzje, które podejmują, są podejmowane sprzętowo przez ASIC).
Na portach, na których masz łącza uplink ISP, zastosuj listę ACL, która była wcześniej w zaporze (np. „Zezwól tylko na 80 / tcp i 443 / tcp na ten konkretny adres IP”). Następnie poproś, aby każda z twoich nakładek utrzymywała sesję BGP z routerem. Możesz użyć doskonałego OpenBGPD (jeśli twoje nakładki są na OpenBSD) lub Quagga . Router będzie ECMP generował ruch do interfejsów, które są zdrowe (ponieważ utrzymują sesje BGP). Router będzie również odpowiednio kierował ruch przy użyciu PBR.
Udoskonalenia
pfsync
.pfsync
zwykle podwaja szybkość pakietów w twoich zaporach ogniowych.pfsync
.Przykładowa
relayd
konfiguracjaZobacz także HOWTO na https://calomel.org/relayd.html
źródło
Osobiście przechodzę do prostszych, mniej konfigurowalnych sprzętowych równoważników obciążenia w tym momencie - takich jak ACE / ASA firmy Cisco, Foundry ServerIrons, a może nawet Zeus ZXTM (SW LB zaprojektowany dla bardzo dużych obciążeń).
źródło
Być może zamiast stale utrzymywać tak wiele otwartych połączeń w celu wysyłania odpowiedzi, koduj swoją aplikację w taki sposób, aby klienci okresowo sondowali Twoje serwery tak często, jak to konieczne?
Czy to, co robisz, wymaga tak naprawdę milisekundy, czy klient może czekać 15/20 sekund do następnego okresu odpytywania?
źródło
Typowym podejściem byłoby utworzenie klastra wystarczająco dużego, aby poradzić sobie z wymaganym obciążeniem i użyć SLB, która może wykonać deterministyczne równoważenie obciążenia (w przypadku trwałych połączeń).
Coś w rodzaju CARP używa skrótu żądającego adresu IP w celu ustalenia, który serwer WWW zaplecza obsługiwałby żądanie, powinno to być deterministyczne, ale niezbyt przydatne, jeśli przed modułem równoważenia obciążenia znajduje się zapora ogniowa lub NAT.
Możesz również znaleźć coś takiego jak IPVS, jeśli pracujesz w systemie Linux.
źródło