Onderwerp: Netwerk storage hulp gezocht

Beste allen,

Wij ondervinden problemen met een cluster bestaande uit 4 KVM nodes op 2 ZFS fileservers.

Het probleem zit in het netwerk.

Beide ZFS servers hebben 4x1Gbit poorten in een bond 802.3ad (layer2+3 xmit-hash-policy)
Alle 4 KVM nodes hebben 2x1Gbit in een bond 802.3ad (layer2+3 xmit-hash-policy)
De Switch is managed en ingested op LACP, LAG groepen en Layer2+3 hashing

De 4 KVM nodes maken allemaal verbinding via een NFS share naar de primaire ZFS server (2e ZFS server is back-up/standby). Wij zien echter dat er maar 1 netwerk poort tegelijk gebruikt wordt op de KVM nodes. Hierdoor kan een enkele kopie/IO actie alle VM's onbereikbaar maken op een node.

Wij willen juist dat een enkele KVM node met 2 gigabit poorten tegelijk kan verbinden naar de ZFS server. Dus wanneer 2 VM's iets zouden kopieren, dat je 2Gbit totaal kan gebruiken. Ook willen we dat de ZFS servers met 4x1Gbit onderling kunnen communiceren, zodat kopieer acties en initiele syncs/resyncs met hoge snelheid mogelijk worden.

Wanneer wij een test doen naar beide ZFS servers tegelijk werkt het wel goed, dan zien we inderdaad beide netwerk interfaces gebruikt worden. Het werkt ook goed wanneer we vanaf alle 4 KVM nodes tegelijk een test doen naar de ZFS server, op de ZFS server zien we dan alle 4 de poorten in gebruik (op de KVM nodes ieder 1 actief).

Kortom:
1. Is het mogelijk om met layer2/layer2+3 te loadbalancen naar een enkele server?
2. Kan iemand ons eventueel betaald helpen met het zoeken en implementeren van een oplossing?

Wij hadden zelf bedacht dat 4x1Gbit en 2x1Gbit trunks een goede oplossing was, maar vooralsnog hadden we net zo goed zonder trunks aan de slag kunnen gaan.

10Gbit op de fileservers is geen oplossing, de nodes blijven dan nog steeds met maximaal 1Gbit verbinden. Het is ook geen oplossing om in alle 6 servers een 10Gbit kaart te steken, dat is enorme overkill en te kostbaar.

Ben je al geholpen?

Ik zie hier een misverstand die vaak door mensen wordt gemaakt. LACP bonding is niet 1 x 2 GBit maar meer 2 x 1 GBit. Ik paste hier even een stukje van een andere site, scheelt weer typewerk ;-

http://doc.freenas.org/index.php/Link_Aggregations

Considerations When Using LACP, MPIO, NFS, or ESXi

LACP bonds Ethernet connections in order to improve bandwidth. For example, four physical interfaces can be used to create one mega interface. However, it cannot increase the bandwidth for a single conversation. It is designed to increase bandwidth when multiple clients are simultaneously accessing the same system. It also assumes that quality Ethernet hardware is used and it will not make much difference when using inferior Ethernet chipsets such as a Realtek.

LACP reads the sender and receiver IP addresses and, if they are deemed to belong to the same TCP connection, always sends the packet over the same interface to ensure that TCP does not need to reorder packets. This makes LACP ideal for load balancing many simultaneous TCP connections, but does nothing for increasing the speed over one TCP connection.

Als je verder nog hulp nodig hebt laat maar even via PM weten.

Nog niet geholpen, draai nog steeds op 1 been qua netwerk.

1x2Gbit is inderdaad niet de bedoeling (was het maar zo'n feest). Het moet wel zo zijn dat 2 VM's (2 threads) over 2x1Gbit gaan.

Wellicht komt het doordat NFS altijd dezelfde source/dest IP/MAC/PORT heeft en daarom kan het storage verkeer niet ge-loadbalanced worden omdat er op basis van de hashing geen verschil is.

Oorspronkelijk geplaatst door Anoniem

Nog niet geholpen, draai nog steeds op 1 been qua netwerk.

1x2Gbit is inderdaad niet de bedoeling (was het maar zo'n feest). Het moet wel zo zijn dat 2 VM's (2 threads) over 2x1Gbit gaan.

Wellicht komt het doordat NFS altijd dezelfde source/dest IP/MAC/PORT heeft en daarom kan het storage verkeer niet ge-loadbalanced worden omdat er op basis van de hashing geen verschil is.

Er is wel een oplossing te bedenken maar dat kunnen we beter even buiten het forum bespreken.

NFS gebruikt inderdaad maar 1 poort van een lacp truck. Kan je geen gebruik maken van iscsi die zal de poorten wel geload balanced gebruiken.

Wij gebruiken ZFS on Linux, iscsi werkt daar nog niet op (althans, er is nog geen stable versie)

In feite heeft het niet met nfs te maken maar met je lacp. Jij trapt traffic vanaf NODE 1 over je bond met zijn EIGEN macadres naar STORAGE 1 met ook een bond en zijn EIGEN macadres.
Daardoor levert je hash policy telkens dezelfde waarde op waardoor dezelfde poort wordt gebruikt.

Als je in jouw geval vanaf de beide storages tegelijk data gaat pompen naar eenzelfde node, zul je zien dat dan ook beide nics op de node gebruikt worden.

Aan de kant van de storage zie je dat ook goed als je met alle 4 de nodes data gaat pompen. In dat geval krijg je voor elke macadres op de nodes een nieuwe hash en poort en kun je 4gb bijna halen.

Wat je nog kunt proberen is om op de nodes 'balanced alb' te gebruiken voor je 2 storage poorten en vervolgens deze poorten van de nodes op de switch UIT de trunks te halen (lacp en lag uitvinken dus).

Als je beide storages in een active/active setup zou willen gebruiken moet je een switch erbij hangen, zorgen dat je per node 4 keer een 1 gb nic hebt en overstappen op multipath io. zfs dumpen en drbd gebruiken voor je replicatie. Dan heb je niet alleen een goede ha setup, maar kun je ook de throughput van alle nics gebruiken. Moet je wel de boel redelijk omgooien, dus ik zou de eerste optie even proberen

Bedankt voor de informatie Systemdeveloper, dat is inderdaad logisch en een duidelijke reden waarom het fout gaat.

Momenteel test ik een node met balance-alb icm de 2e ZFS server. Ik zie nog weinig verschil ten opzichte van LACP, maar in ieder geval heb ik geen switch configuratie meer nodig.

active/active met DRBD is technisch erg mooi, maar ook wel weer gevaarlijk(er). Wij gebruiken de ZFS server ook vanwege de snapshots, snapshot replicatie, cache, ZIL log en compressie. Hierdoor hebben we ieder uur lokale back-ups, remote back-ups en alle opslag is gemiddeld 50% minder groot (en dus 2x meer capaciteit). Wij hebben in het verleden een keer een DRBD split-brain meegemaakt bij een IT partner en dat heeft ervoor gezorgd dat we liever voor de oplossing gaan zoals we die nu hebben draaien. Eventueel nog met GlusterFS erbij voor echte HA, maar dat zal slechts voor een paar VM's zijn.

Test je het met iperf (en dan bv 10-20 clients opgeven) of gewoon met copy's vanaf de vm's?

Oorspronkelijk geplaatst door systemdeveloper

In feite heeft het niet met nfs te maken maar met je lacp. Jij trapt traffic vanaf NODE 1 over je bond met zijn EIGEN macadres naar STORAGE 1 met ook een bond en zijn EIGEN macadres.
Daardoor levert je hash policy telkens dezelfde waarde op waardoor dezelfde poort wordt gebruikt.

Als je in jouw geval vanaf de beide storages tegelijk data gaat pompen naar eenzelfde node, zul je zien dat dan ook beide nics op de node gebruikt worden.

Aan de kant van de storage zie je dat ook goed als je met alle 4 de nodes data gaat pompen. In dat geval krijg je voor elke macadres op de nodes een nieuwe hash en poort en kun je 4gb bijna halen.

Dat hoeft niet eens. Met twee flows heb je nog steeds 50% kans dat beide flows op hetzelfde channel member uitkomen en je dus geen loadbalancing hebt.
Met vier flows kun je ook nog best scheef uitkomen.
De statische verdeling gaat mooi bij "best een aantal" flows, maar twee of vier is een beetje weinig om daar echt op te rekenen.

Oorspronkelijk geplaatst door visser

Dat hoeft niet eens. Met twee flows heb je nog steeds 50% kans dat beide flows op hetzelfde channel member uitkomen en je dus geen loadbalancing hebt.
Met vier flows kun je ook nog best scheef uitkomen.
De statische verdeling gaat mooi bij "best een aantal" flows, maar twee of vier is een beetje weinig om daar echt op te rekenen.

Let op dat ik zei vanaf verschillende machines om een andere hash te forceren. Vanaf 1 machine over een bond naar 1 andere machine blijft het gokken. Daarom dat ik zelf ook liever met iperf de boel aanjaag en 20-100 clientprocessen start. Of ja... liever... ik gebruik zelf mpio met fysiek gescheiden verbindingen en ik laat iscsi connecten naar verschillende ip's in hun eigen subnet. Dan zoekt iscsi het zich maar lekker uit.

Oorspronkelijk geplaatst door systemdeveloper

Let op dat ik zei vanaf verschillende machines om een andere hash te forceren. Vanaf 1 machine over een bond naar 1 andere machine blijft het gokken. Daarom dat ik zelf ook liever met iperf de boel aanjaag en 20-100 clientprocessen start. Of ja... liever... ik gebruik zelf mpio met fysiek gescheiden verbindingen en ik laat iscsi connecten naar verschillende ip's in hun eigen subnet. Dan zoekt iscsi het zich maar lekker uit.

Ik zag je dat niet zo erg zeggen , vanaf (veel) andere machines.

Je hebt een hash met twee uitkomsten (twee channelmembers), en een andere machine nemen kan prima (50% kans) op hetzelfde kanaal uitkomen.
Je wilt een redelijk aantal verschillende inputs voor de hash leveren om de output te zien uitmiddelen over de twee (of n) mogelijkheden. Oftewel, meer dan een handvol verkeersstromen.

Let op dat als je bijvoorbeeld een hash (alleen) op mac adres basis hebt op een link bundel tussen twee routers, dan wordt er niks gebalanced omdat de verkeersstromen tussen de routers maar twee mac adressen laten zien.
Maar meestal wordt natuurlijk IP en port meegenomen in de hash, en dan kun je met een aantal verkeersflows (zoals je iperf test) een mooie verdeling krijgen.

Maar fundamenteel is er weinig aan te doen : out-of-order delivery is fors rampzalig, dus moet verkeer op flow-basis verdeeld worden over gebundelde verbindingen.
En die verdeling gaat statisch mooi als er wat te middelen valt, en dat vereist meer dan een enkele verkeersflow .

Ik denk dat in je iscsi voorkeur je ook afhankelijk bent van 'voldoende' sessies om iscsi wat te geven om zelf uit te zoeken en zo de gezamelijke capaciteit goed te benutten.

Nou ja 'veel'... TS heeft er 4, dus dan houdt het ver op.

layer-2-and-3 gebruikt geen poort nummer en het ip nummer is niet relevant (tenzij je wat virtuele ip's aan je bond hangt).
Misschien is layer-4-and-5 waarbij de poort in de hash wordt meegenomen idd nog een optie is. Not sure of je dan tcp fragmentation moet disablen, dacht het wel. (En eventueel je mtu wat verhogen).
En volgens mij werkt dat ook alleen als je nfs over tcp connect ipv. udp. Ach, parameter aanpassen, netwerk restarten en je weet of het werkt

Bij iscsi worden lacp's iig altijd afgeraden omdat de mpio stack dat daar regelt. Dan krijg je zoiets als onderstaand, waarbij traffic in dit geval gewoon rr wordt gedaan. Je hebt er wat meer nics voor nodig, minimaal 2 (storage) switchen, maar dan kan je wel overal iets kapot gaan.

1IET_00010001 dm-13 IET,VIRTUAL-DISK
size=1.5T features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=0 status=active
|- 120:0:0:1 sdg 8:96 active undef running
`- 121:0:0:1 sdh 8:112 active undef running