Równoważenie obciążenia warstwy 4 i warstwy 7

Usiłuję zdecydować między zastosowaniem rozwiązania równoważenia obciążenia warstwy 4 dla mojego centrum danych lub rozwiązaniem warstwy 7. Niestety (dla mojego rozsądku) mój przypadek użycia jest na tyle prosty, że oba rozwiązania działałyby dobrze, unikając większości słabości i nie wykorzystując w rzeczywistości mocnych stron. Niezależnie od tego, z jakiego rozwiązania się skorzystamy, musi ono mieć wysoką dostępność i wysoką przepustowość. Ale planujemy go używać tylko do równoważenia obciążenia klastra serwerów internetowych, z których żaden nie ma żadnych wymagań dotyczących „lepkiego” zarządzania sesjami (cookie lub IP), złożonych reguł przepisywania - lub, w tym przypadku, jakichkolwiek reguł przepisywania w wszystko.

Elementy równoważące obciążenie zostaną podłączone do dwóch przełączników, oba z niezależnym połączeniem do warstwy agregacji centrum danych i połączone ze sobą za pomocą drzewa Rapid Spanning Tree i dowolnego zastrzeżonego protokołu używanego przez przełączniki do wirtualizacji. Równoważniki obciążenia będą również połączone ze sobą za pomocą kabla krosowego. Wszystkie serwery w klastrze są podłączone do obu przełączników. Wszystko, co muszą zrobić moduły równoważące obciążenie, to skierować na nich ruch.

Ponieważ jest to tylko HTTP, mogę użyć rozwiązania równoważenia obciążenia warstwy 7, takiego jak HAProxy lub nginx. Ale mógłbym również użyć projektu LVS z ldirectord lub keepalived lub cokolwiek innego.

Próbowałem rozbić zalety i wady, jak je widzę, ale to kończy się na praniu. Co byś polecił i dlaczego? Czy coś brakuje?

Jedną z przydatnych zalet „L7”, takich jak haproxy, jest możliwość używania plików cookie, aby utrzymać tę samą przeglądarkę na tym samym serwerze zaplecza. To znacznie ułatwia debugowanie klienta.

Równoważenie L4 może powodować odrzucenie pojedynczego użytkownika na kilku serwerach zaplecza. (co w niektórych przypadkach może być korzystne, ale w sensie debugowania / profilowania użycie „L7” jest o wiele bardziej wartościowe).

EDYCJA: Istnieje również potencjalna przewaga prędkości przy użyciu równoważenia HTTP. Dzięki utrzymywaniu przy życiu klienci mogą ustanowić pojedynczą sesję TCP do modułu równoważącego, a następnie wysyłać wiele HITów bez konieczności ponownego ustanawiania nowych sesji TCP (3-drożny uścisk dłoni). Podobnie wiele LB utrzymuje sesje utrzymywania aktywności w systemach zaplecza, eliminując potrzebę wykonywania tego samego uzgadniania na zapleczu.

Ścisłe równoważenie obciążenia TCP może nie osiągnąć obu tych zadań tak łatwo.

/ * FWIW: Nie powiedziałbym „L7” lub „L4”, powiedziałbym HTTP lub TCP. Ale jestem zwolennikiem unikania używania OSI do opisywania rzeczy, które nie pasują dobrze. * /

Myślę, że zasadniczo, jeśli nie jesteś pewien, co wdrożyć, wybierz to, co wydaje ci się proste i naturalne. Przetestuj (użyj ławki Apache?) I upewnij się, że działa dla Twoich potrzeb. Dla mnie HTTP LB jest bardziej naturalny.

Biorąc pod uwagę brak korzyści dla ciebie z równoważenia L7, zdecydowałbym się na równoważenie L4. Jestem wielkim fanem tego, aby upraszczać to tak prosto, jak to możliwe, nie poświęcając zbyt wiele.

L7 wymaga, aby moduły równoważące sprawdzały nagłówki http w pakietach, które je przechodzą pod kątem odpowiedniego routingu, dodając dodatkowy narzut i marginalny wzrost opóźnienia dla użytkownika końcowego. Wydaje mi się to bezcelowym wydatkiem, jeśli dzięki temu nic nie zyskasz.

Niektórzy dostawcy DNS mają prostą funkcję przełączania awaryjnego. Wspomniałeś, jakie są twoje wymagania, a nie jakie są, ale jeśli wszystko, czego potrzebujesz, to okrągły robin z przełączaniem awaryjnym, jeśli coś jest nie tak, możesz użyć np. Przełączania awaryjnego zoneedit.com . W zależności od potrzeb HA, które mogą być wystarczająco dobre, możesz pominąć cały poziom w swojej architekturze.