Vraag Hoe precies en specifiek werkt de hashing van layer 3 LACP-bestemmingsadres?


Gebaseerd op een eerdere vraag van meer dan een jaar geleden (Multiplexed 1 Gbps Ethernet?), Ging ik weg en installeerde een nieuw rack met een nieuwe ISP met overal LACP-koppelingen. We hebben dit nodig omdat we individuele servers (één applicatie, één IP) hebben die duizenden clientcomputers over het internet bedienen die meer dan 1 Gbps cumulatief zijn.

Dit LACP-idee zou ons de 1 Gbps-barrière laten doorbreken zonder een fortuin te besteden aan 10GoE-switches en NIC's. Helaas ben ik wat problemen tegengekomen met betrekking tot uitgaande verkeersverdeling. (Dit ondanks de waarschuwing van Kevin Kuphal in de bovenstaande gekoppelde vraag.)

De router van de ISP is een of andere Cisco. (Ik afgeleid dat van het MAC-adres.) Mijn switch is een HP ProCurve 2510G-24. En de servers zijn HP DL 380 G5's met Debian Lenny. Eén server is een warme standby. Onze applicatie kan niet worden geclusterd. Hier is een vereenvoudigd netwerkdiagram dat alle relevante netwerkknooppunten met IP's, MAC's en interfaces omvat.

alt text

Hoewel het alle details bevat, is het een beetje moeilijk om mee te werken en mijn probleem te beschrijven. Dus, omwille van de eenvoud, hier is een netwerkdiagram gereduceerd tot de knooppunten en fysieke koppelingen.

alt text

Dus ging ik weg en installeerde mijn kit in het nieuwe rack en verbond de bekabeling van mijn ISP vanaf hun router. Beide servers hebben een LACP-koppeling naar mijn switch en de switch heeft een LACP-koppeling naar de ISP-router. Vanaf het begin besefte ik dat mijn LACP-configuratie niet klopte: testen toonde aan dat al het verkeer van en naar elke server over één fysieke GoE-koppeling ging, uitsluitend tussen server-to-switch en switch-to-router.

alt text

Met wat google-zoekopdrachten en veel RTMF-tijd met betrekking tot linux-NIC-verlijming, ontdekte ik dat ik de NIC-verlijming kon beheersen door modifiying /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

Hierdoor kreeg het verkeer mijn server over beide NIC's zoals verwacht. Maar het verkeer bewoog van de overstap naar router over slechts één fysieke link, nog steeds.

alt text

We hebben dat verkeer nodig dat over beide fysieke koppelingen gaat. Na het lezen en herlezen van de 2510G-24's Management- en configuratiehandleiding, Ik vind:

[LACP gebruikt] bronbestemmingsadres   paren (SA / DA) voor distributie   uitgaand verkeer over onbelaste koppelingen.   SA / DA (bronadres / bestemming   adres) veroorzaakt de overschakeling naar   distribueer uitgaand verkeer naar de   links binnen de trunkgroep op de   basis van bron / bestemmingsadres   paren. Dat wil zeggen, de schakelaar verzendt   verkeer van hetzelfde bronadres   naar hetzelfde bestemmingsadres   via dezelfde trunk-link, en   verzendt verkeer van dezelfde bron   adres naar een andere bestemming   adres via een andere link,   afhankelijk van de rotatie van het pad   opdrachten tussen de links in de   stam.

Het lijkt erop dat een gelinkte link slechts één MAC-adres bevat en daarom zal mijn server-to-routerpad altijd over één pad van switch-to-router gaan, omdat de switch maar één MAC (en niet twee - één ziet van elke poort) voor beide LACP'd-koppelingen.

Begrepen. Maar dit is wat ik wil:

alt text

Een duurdere HP ProCurve-switch is dat de 2910al de bron- en doeladressen van niveau 3 gebruikt in zijn hash. Van de sectie 'Uitgaande verkeersverdeling over trunklinks' van de ProCurve 2910al's Management- en configuratiehandleiding:

De feitelijke verdeling van het verkeer   via een kofferbak hangt af van een   berekening met behulp van bits uit de bron   Adres en bestemmingsadres. Wanneer   een IP-adres is beschikbaar, de   berekening omvat de laatste vijf   bits van het IP-bronadres en IP   bestemmingsadres, anders de MAC   adressen worden gebruikt.

OK. Dus, om dit te laten werken zoals ik het wil, is het bestemmingsadres de sleutel omdat mijn bronadres is vastgesteld. Dit leidt tot mijn vraag:

Hoe precies en specifiek werkt het werken met layer 3 LACP?

Ik moet weten welk bestemmingsadres wordt gebruikt:

  • het IP-adres van de klant, de eindbestemming?
  • Of het IP-adres van de router, de bestemming van de volgende fysieke linkoverdracht.

We zijn niet afgegaan en hebben nog een vervangende schakelaar gekocht. Help me alsjeblieft om precies te begrijpen of de hashing van de layer 3 LACP-bestemmingsadres is of niet wat ik nodig heb. Het kopen van een andere nutteloze schakelaar is geen optie.


52
2017-08-17 10:33


oorsprong


Uitstekende, goed onderzochte vraag! Helaas, ik weet het antwoord niet ... - Doug Luxem
Kun je de spannings- boomkosten van elke brug / stam op de ProCurve bekijken? - dbasnett
Ook de staat en prioriteit? Het lijkt erop dat bij HP <---> Cisco dat de trunks mogelijk niet dezelfde prioriteit hebben en uiteindelijk geblokkeerd raken. Een advertentie voor het niet mengen van leveranciers ???? - dbasnett
Dit is mogelijk de best geformatteerde vraag die ik heb gezien over Server Fault - sclarson
Ik hoop dat iemand evenveel zorg kan besteden aan het antwoord als op de vraag. - Neil Trodden


antwoorden:


Wat u zoekt, wordt gewoonlijk een "beleid voor verzenden van hash" of "hash-algoritme verzenden" genoemd. Het bestuurt de selectie van een poort uit een groep verzamelpoorten waarmee een frame kan worden verzonden.

Het is moeilijk gebleken om de 802.3ad-standaard te leren kennen, omdat ik niet bereid ben er geld aan uit te geven. Dat gezegd hebbende, heb ik wat informatie kunnen verzamelen van een semi-officiële bron die enig licht werpt op wat je zoekt. Per deze presentatie van de IEEE High Speed ​​Study Group 2007 in Ottawa, ON, CA de 802.3ad-norm geeft geen specifieke algoritmen voor de "frameverdeler":

Deze standaard schrijft geen bepaald distributiealgoritme (en) verplicht; elk distributiealgoritme moet er echter voor zorgen dat, wanneer frames worden ontvangen door een Frame Collector zoals gespecificeerd in 43.2.3, het algoritme niet leidt tot a) verkeerde ordening van frames die deel uitmaken van een bepaald gesprek, of b) duplicatie van frames . Aan de bovenstaande eis om het ordenen van frames te handhaven wordt voldaan door ervoor te zorgen dat alle frames die een bepaald gesprek samenstellen op één enkele link worden verzonden in de volgorde waarin ze door de MAC-client worden gegenereerd; daarom omvat deze vereiste niet de toevoeging (of wijziging) van enige informatie aan het MAC-frame, noch enige buffering of verwerking van de kant van de corresponderende Frame Collector om frames opnieuw te ordenen.

Dus, welk algoritme een switch / NIC-driver ook gebruikt om uitgezonden frames te distribueren, moet voldoen aan de vereisten zoals vermeld in die presentatie (die vermoedelijk een citaat uit de standaard maakte). Er is geen specifiek algoritme gespecificeerd, alleen een compliant gedrag gedefinieerd.

Hoewel er geen algoritme is opgegeven, kunnen we naar een bepaalde implementatie kijken om een ​​idee te krijgen van hoe een dergelijk algoritme zou kunnen werken. De Linux-kernel "bonding" -driver heeft bijvoorbeeld een 802.3ad-compatibel hash-beleid voor verzenden dat de functie toepast (zie bonding.txt in de documentatie \ netwerkdirectory van de kernelbron):

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

Hierdoor worden zowel de bron- als de doel-IP-adressen, evenals de bron- en doel-MAC-adressen, beïnvloed door de poortselectie.

Het bestemmings-IP-adres dat in dit type hashing wordt gebruikt, is het adres dat in het frame aanwezig is. Neem even de tijd om daarover na te denken. Het IP-adres van de router, in een Ethernet-framekop verwijderd van uw server naar internet, wordt nergens in zo'n frame ingekapseld. De router Mac adres is aanwezig in de header van een dergelijk frame, maar het IP-adres van de router is dat niet. Het IP-adres van de bestemming dat is ingekapseld in de payload van het frame, is het adres van de internetclient die de aanvraag naar uw server verzendt.

Een hash-beleid voor verzending dat rekening houdt met zowel bron- als bestemmings-IP-adressen, ervan uitgaande dat u een zeer gevarieerde groep klanten heeft, zou het best goed voor u moeten doen. In het algemeen zullen meer breed gevarieerde bron- en / of bestemmings-IP-adressen in het verkeer dat door een dergelijke geaggregeerde infrastructuur stroomt, resulteren in een efficiëntere aggregatie wanneer een op laag 3 gebaseerd hash-beleid voor verzending wordt gebruikt.

In uw diagrammen worden verzoeken weergegeven die rechtstreeks van internet naar de servers komen, maar het is de moeite waard om erop te wijzen wat een proxy met de situatie kan doen. Als u clientaanvragen naar uw servers proxeert, dan, als Chris spreekt in zijn antwoord dan kan je knelpunten veroorzaken. Als die proxy de aanvraag doet vanuit zijn eigen bron-IP-adres, in plaats van vanuit het IP-adres van de internetcliënt, hebt u minder mogelijke "flows" in een strikt layer 3-gebaseerd hash-beleid voor verzenden.

Een hash-beleid voor verzenden kan ook rekening houden met laag 4-informatie (TCP / UDP-poortnummers), mits deze voldoet aan de vereisten van de 802.3ad-standaard. Zo'n algoritme bevindt zich in de Linux-kernel, zoals je in je vraag verwijst. Pas op dat de documentatie voor dat algoritme waarschuwt dat verkeer, vanwege fragmentatie, niet noodzakelijkerwijs hetzelfde pad volgt en als zodanig is het algoritme niet strikt 802.3ad-compatibel.


13
2017-08-19 22:47



Ja, ik heb de linux-server geregeld "hash-beleid verzenden". (Een zeer leerzame ervaring die deze vraag mogelijk maakte.) Het is de verdraaide switch die me in de greep heeft. Bedankt voor de info over IP-frames - ik ben een beetje zwak over hoe de lagere niveaus van de netwerkstack. In mijn gedachten was het frame gericht aan de router, met een bestemming dieper in de payload. : P - Stu Thompson


zeer verrassend, een paar dagen geleden hebben onze testen aangetoond dat xmit_hash_policy = layer3 + 4 geen enkel effect zal hebben tussen twee direct verbonden linux-servers, al het verkeer zal één poort gebruiken. beide runen xen met 1 brug die het verbindingsapparaat als een lid heeft. Het is duidelijk dat de brug het probleem zou kunnen veroorzaken, alleen dat het helemaal niet logisch is, gezien het feit dat op ip + poort gebaseerde hashing zou worden gebruikt.

Ik weet dat sommige mensen erin slagen om 180MB + over gekoppelde links te duwen (d.w.z. ceph-gebruikers), dus het werkt in het algemeen. Mogelijke zaken om naar te kijken: - We gebruikten oud CentOS 5.4 - Het OPs-voorbeeld zou betekenen dat de tweede LACP de verbindingen "unhashes" - is dat logisch, ooit?

Wat deze thread en documentatie lezen etc. heeft mij getoond:

  • Over het algemeen weet iedereen hier veel van, is het goed in het reciteren van theorie uit de verbindende howto of zelfs de IEEE-normen, terwijl praktische ervaring bijna geen is.
  • De RHEL-documentatie is op zijn best onvolledig.
  • De bondingdocumentatie is van 2001 en niet actueel genoeg
  • layer2 + 3-modus is blijkbaar niet in CentOS (het wordt niet weergegeven in modinfo en in onze test is alle verkeer gedropt wanneer ingeschakeld)
  • Het helpt niet dat SUSE (BONDING_MODULE_OPTS), Debian (-o bondXX) en RedHat (BONDING_OPTS) allemaal verschillende manieren hebben om per-band modus-instellingen te specificeren
  • De kernelmodule van CentOS / RHEL5 is "SMP veilig", maar niet "SMP-compatibel" (zie facebook highperformance talk) - het schaalt NIET boven één CPU, dus met een hogere cpu-klok> veel kernen

Als iedereen eindigt een goede high-performance bonding-setup, of weet echt waar ze over praten zou geweldig zijn als ze een half uur nodig hadden om een ​​nieuwe kleine howto te schrijven die één werkend voorbeeld met LACP documenteert, geen rare dingen en bandbreedte> één link


5
2018-06-16 12:30



Het wordt nog erger: verschillende versies van Debian hebben verschillende methoden voor het configureren van bonding! Ik heb echt gedocumenteerd hoe ik mijn binding heb opgezet in een blogbericht, dat behoorlijk verkeer lijkt te krijgen. - Stu Thompson


Als je switch de echte L3-bestemming ziet, kan dat hash zijn. Als u over twee koppelingen beschikt, denkt u dat link 1 voor oneven genummerde bestemmingen is, link 2 is voor even genummerde bestemmingen. Ik denk niet dat ze ooit het IP-adres van de volgende hop gebruiken, tenzij ze hiervoor zijn geconfigureerd, maar dat is ongeveer hetzelfde als het MAC-adres van het doel gebruiken.

Het probleem dat u tegenkomt, is dat, afhankelijk van uw verkeer, de bestemming altijd het enige IP-adres van de enkele server is, zodat u die andere link nooit zult gebruiken. Als de bestemming het externe systeem op internet is, krijgt u een gelijkmatige distributie, maar als het zoiets is als een webserver, waarbij uw systeem het bestemmingsadres is, zal de switch altijd verkeer verzenden over slechts een van de beschikbare koppelingen.

Je zult er nog slechter aan toe zijn als er ergens een load-balancer is, want dan zal het "externe" IP altijd het IP-adres van de belastingsbalans of de server zijn. Je zou dat een beetje kunnen omzeilen door veel IP-adressen op de load balancer en de server te gebruiken, maar dat is een hack.

Misschien wilt u uw horizon van verkopers een beetje uitbreiden. Andere leveranciers, zoals extreme netwerken, kunnen hasj gebruiken voor zaken als:

L3_L4-algoritme: laag 3 en laag 4, de gecombineerde bron- en doel-IP-adressen en   bron- en doel-TCP- en UDP-poortnummers. Beschikbaar op SummitStack and Summit   X250e, X450a, X450e en X650 series switches.

Dus zolang de bronpoort van de klant (die meestal veel verandert) verandert, verdeelt u het verkeer gelijkmatig. Ik weet zeker dat andere leveranciers vergelijkbare functies hebben.

Zelfs hashing op bron- en doel-IP zou genoeg zijn om hotspots te vermijden, zolang je geen load-balancer in de mix hebt.


2
2017-08-19 19:53



Bedankt. Geen taakverdeling. En ik maak me geen zorgen over inkomend verkeer - we hebben een> 50: 1 uit: in verkeersverhouding. (Het is een webvideotoepassing.) - Stu Thompson
Ik denk dat in jouw geval de hash op bestemming niets oplevert, omdat de switch de bestemming als jouw server zal zien. L2 traffic engineering is gewoon niet erg goed. En 'hash' in dit soort toepassingen zal behoorlijk primitief zijn - figuur het beste wat je kunt doen is optellen alle bits in welk adres (sen) dan ook in gebruik zijn en als het resultaat 0 is, ga dan één link of 1 ga de andere uit. - chris
Zoals ik het begrijp uit mijn bovenstaande citaat van ProCurve 2910, staat de hash op de laatste vijf bits van de bron en bestemming. Dus, het maakt niet uit of een (mijn server) is opgelost, de andere zal voor bijna elke klant op niveau 3 variëren. Niveau 2? Dat is mijn huidige probleem - er is slechts één bron- en één bestemmingsadres tegen hasj. - Stu Thompson


Ik zal veronderstellen dat het van het cliëntip, niet de router is. De echte bron- en doel-IP's bevinden zich op een vaste offset in het pakket en dat zal snel zijn om hashen op te doen. Het hashen van de IP-router vereist een lookup op basis van de MAC, toch?


0
2017-08-19 16:47





Sinds ik hier net ben beland, heb ik nu een paar dingen geleerd: Om grijs haar te voorkomen, heb je een fatsoenlijke switch nodig die een layer3 + 4 beleid ondersteunt, en hetzelfde ook in Linux.

In nogal wat gevallen zou de norm-perverterende brander genaamd ALB / SLB (mode6) mogelijk beter werken. Operationeel gezien is het echter rot.

Ik probeer waar mogelijk 3 + 4 te gebruiken, omdat ik vaak die bandbreedte wil tussen twee aangrenzende systemen.

Ik heb het ook geprobeerd met OpenVSwitch en had ooit een instantie waar dat de verkeersstromen verstoorde (elk eerste pakket dat verloren ging ... ik heb geen idee)


-1
2018-03-26 18:24