Jak dokładnie i konkretnie działa funkcja mieszania adresu docelowego LACP warstwy 3?

Opierając się na wcześniejszym pytaniu ponad rok temu ( Multipleksowany 1 Gbps Ethernet? ), Poszedłem i ustawiłem nowy stojak z nowym ISP z łączami LACP w całym miejscu. Potrzebujemy tego, ponieważ mamy indywidualne serwery (jedna aplikacja, jeden adres IP) obsługujące tysiące komputerów klienckich w całym Internecie, przekraczając łącznie 1 Gb / s.

Ten pomysł LACP ma pozwolić nam przełamać barierę 1 Gb / s bez wydawania fortuny na przełączniki 10GoE i karty sieciowe. Niestety mam problemy z dystrybucją ruchu wychodzącego. (To pomimo ostrzeżenia Kevina Kuphala w powyższym powiązanym pytaniu.)

Router ISP jest pewnego rodzaju Cisco. (Wydedukowałem to z adresu MAC.) Mój przełącznik to HP ProCurve 2510G-24. A serwery to HP DL 380 G5 z systemem Debian Lenny. Jeden serwer jest gorącym trybem gotowości. Nasza aplikacja nie może być grupowana. Oto uproszczony schemat sieci, który obejmuje wszystkie istotne węzły sieciowe z adresami IP, MAC i interfejsami.

Chociaż ma wszystkie szczegóły, jest trochę trudny do pracy i opisania mojego problemu. Dla uproszczenia oto schemat sieci zredukowany do węzłów i łączy fizycznych.

Więc odszedłem i zainstalowałem zestaw na nowym stojaku i podłączyłem okablowanie mojego usługodawcy internetowego do ich routera. Oba serwery mają łącze LACP do mojego przełącznika, a przełącznik ma łącze LACP do routera ISP. Od samego początku zdałem sobie sprawę, że moja konfiguracja LACP była nieprawidłowa: testy wykazały, że cały ruch do iz każdego serwera przechodzi przez jedno fizyczne łącze GoE wyłącznie między serwerem do przełączenia i przełącznikiem do routera.

Podczas niektórych wyszukiwań w Google i dużej ilości czasu RTMF dotyczącego wiązania NIC z linuksem odkryłem, że mogę kontrolować wiązanie NIC poprzez modyfikację /etc/modules

# /etc/modules: kernel modules to load at boot time.
# mode=4 is for lacp
# xmit_hash_policy=1 means to use layer3+4(TCP/IP src/dst) & not default layer2 
bonding mode=4 miimon=100 max_bonds=2 xmit_hash_policy=1

loop

Spowodowało to ruch opuszczający mój serwer przez obie karty sieciowe zgodnie z oczekiwaniami. Ale ruch ruszał z przełącznika do routera na jednym tylko fizycznego łącza, nadal .

Potrzebujemy ruchu przechodzącego przez oba łącza fizyczne. Po przeczytaniu i ponownym przeczytaniu Przewodnika zarządzania i konfiguracji 2510G-24 znajduję:

[LACP wykorzystuje] pary adres-źródło (SA / DA) do dystrybucji ruchu wychodzącego przez łącza trunkingowe. SA / DA (adres źródłowy / adres docelowy) powoduje, że przełącznik rozdziela ruch wychodzący na łącza w grupie linii miejskiej na podstawie par adresu źródłowego / docelowego. Oznacza to, że przełącznik wysyła ruch z tego samego adresu źródłowego na ten sam adres docelowy za pośrednictwem tego samego łącza trunkingowego i wysyła ruch z tego samego adresu źródłowego na inny adres docelowy za pośrednictwem innego łącza, w zależności od rotacji przypisań ścieżek między linki w bagażniku.

Wygląda na to, że połączone łącze ma tylko jeden adres MAC, dlatego moja ścieżka serwer-router zawsze będzie znajdować się na jednej ścieżce od przełącznika do routera, ponieważ przełącznik widzi tylko jeden adres MAC (a nie dwa - jeden z adresu każdego portu) dla obu łączy LACP.

Rozumiem. Ale tego właśnie chcę:

Droższym przełącznikiem HP ProCurve jest to, że 2910al używa adresów źródłowych i docelowych poziomu 3 w swoim skrócie. Z sekcji „Dystrybucja ruchu wychodzącego przez łącza trunkowane” Przewodnika zarządzania i konfiguracji ProCurve 2910al :

Rzeczywisty rozkład ruchu przez łącze zależy od obliczeń wykorzystujących bity z adresu źródłowego i adresu docelowego. Gdy dostępny jest adres IP, obliczenia obejmują ostatnie pięć bitów adresu źródłowego IP i adresu docelowego IP, w przeciwnym razie wykorzystywane są adresy MAC.

DOBRZE. Aby to działało tak, jak chcę, kluczem jest adres docelowy, ponieważ mój adres źródłowy jest stały. To prowadzi do mojego pytania:

Jak dokładnie i konkretnie działa funkcja mieszania LACP warstwy 3?

Muszę wiedzieć, który adres docelowy jest używany:

• adres IP klienta , miejsce docelowe?
• Lub adres IP routera , następne fizyczne miejsce docelowe transmisji łącza.

Nie poszliśmy i nie kupiliśmy jeszcze zamiennika. Pomóż mi zrozumieć dokładnie, czy mieszanie adresu docelowego LACP warstwy 3 jest, czy nie jest tym, czego potrzebuję. Zakup innego bezużytecznego przełącznika nie wchodzi w grę.

To, czego szukasz, nazywa się powszechnie „zasadą mieszania transmisji” lub „algorytmem transmisji skrótów”. Kontroluje wybór portu z grupy portów zagregowanych, z którymi ma być przesyłana ramka.

Zdobycie standardu 802.3ad okazało się trudne, ponieważ nie chcę na to wydawać pieniędzy. Powiedziawszy to, byłem w stanie zebrać informacje z półoficjalnego źródła, które rzuca nieco światła na to, czego szukasz. Zgodnie z prezentacją przedstawioną przez grupę IEEE High Speed ​​Study Group z Ottawy w 2007 r., Która spełnia standard 802.3ad, nie wymaga określonych algorytmów dla „dystrybutora ramek”:

Ten standard nie wymaga żadnego konkretnego algorytmu (-ów) dystrybucji; jednak każdy algorytm dystrybucji zapewnia, że ​​gdy ramki są odbierane przez moduł zbierający ramki, jak określono w 43.2.3, algorytm nie powinien powodować: a) nieprawidłowego uporządkowania ramek, które są częścią danej konwersacji, lub b) powielania ramek . Powyższy wymóg utrzymania kolejności ramek jest spełniony przez zapewnienie, że wszystkie ramki, które składają się na daną konwersację, są przesyłane na jednym łączu w kolejności, w jakiej są generowane przez klienta MAC; stąd wymaganie to nie obejmuje dodawania (ani modyfikacji) żadnych informacji do ramki MAC, ani żadnego buforowania lub przetwarzania ze strony odpowiedniego modułu zbierającego ramki w celu ponownego zamówienia ramek.

Zatem dowolny algorytm przełącznika / sterownika karty sieciowej do dystrybucji przesyłanych ramek musi być zgodny z wymaganiami określonymi w tej prezentacji (która prawdopodobnie cytowała ze standardu). Nie określono konkretnego algorytmu, zdefiniowano tylko zgodne zachowanie.

Mimo że nie określono żadnego algorytmu, możemy spojrzeć na konkretną implementację, aby dowiedzieć się, jak taki algorytm może działać. Na przykład sterownik „wiązania” jądra systemu Linux ma hash transmisji zgodny z 802.3ad, który stosuje tę funkcję (patrz bonding.txt w katalogu Documentation \ networking źródła jądra):

Destination Port = ((<source IP> XOR <dest IP>) AND 0xFFFF) 
    XOR (<source MAC> XOR <destination MAC>)) MOD <ports in aggregate group>

Powoduje to, że źródłowy i docelowy adres IP, a także źródłowy i docelowy adres MAC mają wpływ na wybór portu.

Docelowy adres IP użyty w tego rodzaju haszowaniu byłby adresem obecnym w ramce. Zastanów się nad tym. Adres IP routera w nagłówku ramki Ethernet z dala od serwera do Internetu nie jest nigdzie zamknięty w takiej ramce. Adres MAC routera jest obecny w nagłówku takiej ramki, ale adres IP routera nie jest. Docelowy adres IP umieszczony w polu danych ramki będzie adresem klienta internetowego wysyłającego żądanie do serwera.

Polityka mieszania transmisji, która uwzględnia zarówno źródłowy, jak i docelowy adres IP, zakładając, że masz bardzo zróżnicowaną pulę klientów, powinna być całkiem dobra. Zasadniczo, bardziej zróżnicowane źródłowe i / lub docelowe adresy IP w ruchu przepływającym przez taką zagregowaną infrastrukturę będą skutkować bardziej wydajną agregacją, gdy zastosowana zostanie zasada mieszania transmisji oparta na warstwie 3.

Twoje diagramy pokazują żądania przychodzące bezpośrednio do serwerów z Internetu, ale warto wskazać, co proxy może zrobić w tej sytuacji. Jeśli więc przybliżasz żądania klientów do swoich serwerów, jak mówi Chris w swojej odpowiedzi , możesz powodować wąskie gardła. Jeśli ten serwer proxy wysyła żądanie z własnego źródłowego adresu IP, zamiast z adresu IP klienta internetowego, będziesz mieć mniej możliwych „przepływów” w ścisłej warstwie 3 opartej na haśle transmisji.

Polityka skrótu transmisji może również uwzględniać informacje warstwy 4 (numery portów TCP / UDP), o ile są zgodne z wymaganiami standardu 802.3ad. Taki algorytm znajduje się w jądrze Linuksa, jak wspomniałeś w swoim pytaniu. Uwaga: dokumentacja tego algorytmu ostrzega, że ​​ze względu na fragmentację ruch może niekoniecznie przepływać tą samą ścieżką i jako taki algorytm nie jest ściśle zgodny ze standardem 802.3ad.

co zaskakujące, kilka dni temu nasze testy wykazały, że xmit_hash_policy = layer3 + 4 nie będzie miało żadnego wpływu między dwoma bezpośrednio połączonymi serwerami Linux, cały ruch będzie korzystał z jednego portu. oba działają xen z 1 mostkiem, który ma element łączący jako element. najbardziej oczywiste, że most może powodować problem, po prostu dlatego, że nie ma to wcale sensu, biorąc pod uwagę, że użyto by haszowania opartego na portach IP +.

Wiem, że niektórym osobom udaje się przesuwać 180 MB + przez połączone linki (tj. Użytkownicy ceph), więc ogólnie działa. Możliwe rzeczy do obejrzenia: - Użyliśmy starego CentOS 5.4 - Przykład OP oznaczałby, że drugi LACP „rozłącza” połączenia - czy ma to kiedykolwiek sens?

Co pokazał mi ten wątek i czytanie dokumentacji itp.:

• Zasadniczo każdy wie dużo na ten temat, umie recytować teorię z poradników dotyczących wiązania, a nawet standardów IEEE, podczas gdy praktyczne doświadczenie jest bliskie zeru.
• Dokumentacja RHEL jest co najwyżej niekompletna.
• Dokumentacja spajania pochodzi z 2001 roku i nie jest wystarczająco aktualna
• Tryb warstwy 2 + 3 najwyraźniej nie działa w CentOS (nie pokazuje się w modinfo, aw naszym teście po włączeniu zrzucił cały ruch)
• Nie pomaga to, że SUSE (BONDING_MODULE_OPTS), Debian (-o bondXX) i RedHat (BONDING_OPTS) mają różne sposoby określania ustawień trybu poszczególnych obligacji
• Moduł jądra CentOS / RHEL5 jest „SMP bezpieczny”, ale nie „SMP zdolny” (patrz dyskusja o wysokiej wydajności na Facebooku) - NIE skaluje się powyżej jednego procesora, więc przy wiązaniu wyższego zegara procesora> wielu rdzeni

Jeśli ktoś kończy dobrą konfigurację łączenia o wysokiej wydajności lub naprawdę wie, o czym mówi, byłoby świetnie, gdyby poświęcił pół godziny na napisanie nowego małego podręcznika, który dokumentuje JEDEN działający przykład przy użyciu LACP, żadnych dziwnych rzeczy i przepustowości > jeden link

Jeśli twój przełącznik zobaczy prawdziwe miejsce docelowe L3, może się z tym zgadzać. Zasadniczo, jeśli masz 2 linki, pomyśl, że link 1 dotyczy nieparzystych miejsc docelowych, link 2 dotyczy parzystych miejsc docelowych. Nie sądzę, aby kiedykolwiek korzystali z adresu IP następnego przeskoku, chyba że jest to skonfigurowane, ale to prawie tak samo, jak przy użyciu adresu MAC celu.

Problem, na który natkniesz się, polega na tym, że w zależności od ruchu docelowym miejscem docelowym będzie zawsze pojedynczy adres IP pojedynczego serwera, więc nigdy nie użyjesz tego innego łącza. Jeśli miejscem docelowym jest zdalny system w Internecie, otrzymasz równomierną dystrybucję, ale jeśli jest to coś w rodzaju serwera WWW, gdzie twój system jest adresem docelowym, przełącznik zawsze wysyła ruch tylko przez jeden z dostępnych łączy.

Będziesz w jeszcze gorszym stanie, jeśli gdzieś tam jest moduł równoważenia obciążenia, ponieważ wtedy „zdalny” adres IP zawsze będzie adresem IP modułu równoważenia obciążenia lub serwerem. Można to trochę obejść, używając wielu adresów IP w module równoważenia obciążenia i serwerze, ale to hack.

Możesz nieco rozszerzyć horyzont dostawców. Inni dostawcy, na przykład sieci ekstremalne, mogą mieszać takie rzeczy jak:

Algorytm L3_L4 - Warstwa 3 i Warstwa 4, połączone źródłowe i docelowe adresy IP oraz źródłowe i docelowe numery portów TCP i UDP. Dostępne w przełącznikach serii SummitStack i Summit X250e, X450a, X450e i X650.

Tak więc w zasadzie, dopóki zmieni się port źródłowy klienta (który zwykle bardzo zmienia), równomiernie rozprowadzisz ruch. Jestem pewien, że inni dostawcy mają podobne funkcje.

Nawet mieszanie źródłowego i docelowego adresu IP wystarczyłoby, aby uniknąć gorących punktów, pod warunkiem, że nie ma modułu równoważenia obciążenia w miksie.

Domyślam się, że jest to adres IP klienta, a nie router. Rzeczywiste źródłowe i docelowe adresy IP będą miały ustalone przesunięcie w pakiecie, a to będzie szybkie zrobienie zamieszania. Hashowanie adresu IP routera wymagałoby wyszukiwania na podstawie adresu MAC, prawda?

Odkąd właśnie skończyłem tutaj, nauczyłem się kilku rzeczy: Aby uniknąć siwych włosów, potrzebujesz porządnego przełącznika obsługującego zasady warstwy 3 + 4, i to samo także w Linuksie.

W wielu przypadkach perkozorator standardów o nazwie ALB / SLB (tryb 6) może działać lepiej. Operacyjnie jest do bani.

Sam staram się używać 3 + 4 tam, gdzie to możliwe, ponieważ często chcę przepustowości między dwoma sąsiednimi systemami.

Próbowałem też z OpenVSwitch i miałem raz wystąpienie, w którym zakłócony przepływ ruchu (każdy utracony pierwszy pakiet ... nie mam pojęcia)