LAG / LACP beperking PC-switch-PC

[BartNL]

ik overweeg mijn thuisnetwerk uit te breiden door de Intel PRO/1000 PT Dual PCI-E netwerk kaart in mijn fileserver ook dubbel aan te sluiten en als één link / LAG te gebruiken. Het is niet een ingewikkeld netwerk maar wat uitgebreider thuisnetwerk met 2 PC's, 1 laptop, 1 HTPC, 1 mediaspeler en 1 mediastreamer.
LAG zou handig kunnen zijn wanneer er een download loopt, van of naar de fileserver wordt gekopieerd/gebackupped en er via de HTPC of mediaspeler film wordt gekeken. Met alleen kopiëren trek ik nu de 1 Gbit bandbreedte al zo'n beetje vol. Fileserver is Areca 1882ix raid5 die ruim meer dan 1Gbit aankan.
Met LAG Hiermee hoop ik ook meer dan 1 Gbit van/naar de fileserver te kunnen schrijven zodat er via netwerk op volle snelheid van/naar een harde schijf kan worden gekopieerd en er nog overhead is op netwerk voor de ander taken. In het thuisnetwerk is de redundantie van LAG geen overweging..
Ik heb dan nog wel een switch nodig die dat ondersteund en dat is qua kosten wat mij betreft te overzien. Ik zit dan ergens van €130 voor een TP-Link SG3216 tot €300 voor Cisco 300-28.
Nu lees ik dat link aggregation voor de hierboven geschetste situatie kan werken. Er is echter de beperking dat een enkele link van PC-switch-PC nooit meer dan 1Gbit zou kunnen halen. Afhankelijk van deze beperking wil ik in beide PC's eventueel ook dual NIC's inzetten en bepalen of genoemde switches zinvolle investering zijn.
Mijn vraag is hoe een enkele link dan gedefinieerd is en of dat ook geldt wanneer ik op één PC twee bestanden naar twee schijven kopieer. Naar mijn idee zijn dat dan twee links? Of blijf je dan beperkt tot 1Gbit?

[ Voor 3% gewijzigd door BartNL op 27-07-2012 14:26 ]

[raymonvdm]

Volgens mij ligt dit aan het type LACP wat er gedaan wordt

Wikipedia: Link aggregation

"Normaal" gesproken haalt een machine nooit meer dan 1 gigabit maar 2 machines halen wel 2 gbit

[TrailBlazer]

het ligt aan het hashing algoritme. Als er gehashed wordt op source destination ip dan zal verkeer tussen server en client nooit boven de 1 gbit komen. Wordt er gehashed op source destination port dan zal dat verkeer wel boven de 1 gbit kunnen komen als er meerdere parallelle sessies worden opgestart.

[BartNL]

Wiki heb ik gelezen en daar wordt dit niet echt duidelijk. Wanneer jij zegt dat het aan het type LACP ligt wordt het wat mij betreft alleen maar onduidelijker

[BartNL]

TrailBlazer schreef op vrijdag 27 juli 2012 @ 14:29:
het ligt aan het hashing algoritme. Als er gehashed wordt op source destination ip dan zal verkeer tussen server en client nooit boven de 1 gbit komen. Wordt er gehashed op source destination port dan zal dat verkeer wel boven de 1 gbit kunnen komen als er meerdere parallelle sessies worden opgestart.

Ik zie in de manuals van zowel TP-link als Cisco staan dat je kunt kiezen tussen MAC en IP adres gebaseerde algoritmes. Als je in de switch LAG management op MAC adres instelt zou je met meerdere sessies op dezelfde PC boven 1Gbit uit kunnen komen?

[Bartjezz]

Kun je niet een VM maken, die de bestanden download en op een shared volume zet? Die VM kun je dan toewijzen aan een hardwarematige poort. Dus dan heb je eigenlijk 2 systemen in elkaar die hardwarematig gebruik maken van 2 verschillende poorten.
Als de bestanden dan op de share staan, kun je met je normale systeem alles uitpakken en sorteren.

[BartNL]

is misschien wel een idee maar dan heb ik volgens mij al wel een LAG verbinding nodig vanaf de fileserver naar de switch. Als dat al nodig is, is de VM alleen aan de client kant een oplossing. Wanneer ik de switch al heb dan zou het zonder VM wel eenvoudiger zijn aangezien VM's voor mij nog niet gebruikt worden en dus onbekend mee ben.
Momenteel heb ik al wel een workaround doordat ik via een lange eSata kabel data van de fileserver op externe schijf zet die als back-up dient. Voor mij zou het handiger zijn wanneer dat via een cliënt over het netwerk kan. Daarbij zou ik dan wat flexibeler zijn.

[TrailBlazer]

BartNL schreef op vrijdag 27 juli 2012 @ 14:43:
[...]

Ik zie in de manuals van zowel TP-link als Cisco staan dat je kunt kiezen tussen MAC en IP adres gebaseerde algoritmes. Als je in de switch LAG management op MAC adres instelt zou je met meerdere sessies op dezelfde PC boven 1Gbit uit kunnen komen?

O ja source destination mac heb je ook nog in een subnet maakt dat niks uit tov op basis van ip. Nee op basis van tcp udp poort nummers is het beste.

[BartNL]

Bartjezz schreef op vrijdag 27 juli 2012 @ 15:03:
Kun je niet een VM maken,

ik heb nu een VM draaien en zie dat ik daar een eigen IP en MAC adres kan instellen. Sowieso een optie waar ik niet aan gedacht had, bedankt voor de tip!

[jimmy87]

LACP geldt zoiezo alleen voor uitgaand verkeer, niet inkomend. Je switch kan uitgaand wel balancen maar inkomend niet. Je zou ook eens kunnen kijken naar multilink maar of dat is wat je zoekt.

2x 1gbit zal namelijk nooit precies 2gbit worden omdat je ook nog met wat overhead zit.

There are also limitations you need to be aware of, especially when using multiple 1 GBIT uplinks. This limitation comes from the way how TCP works and the load balancing methods (layers) the switches use.

From a server with multiple 1 GBIT uplinks:

to a server with multiple 1 GBIT uplinks: max 1 GBIT
to multiple servers with 1 GBIT uplinks: max 1 GBIT per destination server
to a server with a 10 GBIT uplink: max 80% of your total capacity

[BartNL]

jimmy87 schreef op zaterdag 28 juli 2012 @ 12:10:
to multiple servers with 1 GBIT uplinks: max 1 GBIT per destination server

dat gaat met een fysieke PC met daarop een VM dus lukken? D.w.z. 1Gbit naar de PC en 1 Gbit naar de VM?