Netwerk storage hulp gezocht

[Netbulae]

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.

[Netbulae]

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.

[frederikbove]

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.

[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.

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

[systemdeveloper]

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

[visser]

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.

[systemdeveloper]

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.

[visser]

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.

[systemdeveloper]

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