[W2k3] 2xGbit NIC, 1 server, route uitgaand verkeer.

[Kokkers]

Er zijn al voldoende topics langs gekomen over connection teaming, port aggegration, trunking, loadbalancing e.d. Toch kom ik er niet uit en vraag ik me af of er voor mijn probleem wel een werkbare oplossing is.

Ik heb 1 (live) streaming server (Windows server 2003) die voldoende capaciteit heeft om 1 Gigabit interface dicht te trekken. Ik heb de server uitgerust met een 2e Gigabit interface in de hoop zo de capaciteit uit te breiden. Om jullie voor te zijn, ja ik zou natuurlijk nog meer machines bij kunnen plaatsen maar dit is niet mijn probleem / punt.

Beide interfaces hebben een eigen (public) IP adres en worden door een hardware 'session balancer' voorzien van requests. (Gebruikte techniek, 1 virtual IP, meerdere realservers en direct server return)

Dit werkt naar behoren en ik krijg op beide interfaces requests binnen die netjes door de achterliggende applicatie afgehandeld worden. Uitgaand verkeer moet terug naar het internet en gaat dus via de default gateway naar buiten.

In de routetabel hebben de 2 externe interfaces exact dezelfde Metric waarde.
Het operating system zal dus de eerste waarde uit de route tabel gebruiken als interface om het verkeer naar buiten te sturen. In Windows kun je deze volgorde specificeren onder 'Adapters and Bindings' in de advanced network setting.

Mijn probleem is dat ik in de huidige situatie nog steeds maar 1 Gbit interface kan gebruiken om verkeer door naar buiten te sturen. De 2e interface zal alleen worden gebruikt wanneer de eerst interface niet bereikbaar is.

Het liefst zou ik op basis van source adres het verkeer via dezelfde interface terug willen kunnen sturen. Ik vraag me echter af of hier binnen Windows Server 2003 mogelijkheden voor zijn.

Termen als source & policy based routing (Route maps bij Cisco / Foundry) zijn bij mij al naar voren gekomen maar ik kan helaas niks terug vinden hoe dit toe te passen en of dit uberhaupt mogelijk is onder Windows.

Iemand tips?

[bazkar]

Vast een rare vraag, maar waarom team je de twee NIC's niet tot een 2 Gbit interface en zet er 1 publiek adres op? Dat scheelt je een boel routeringsproblemen.

[Verwijderd]

Misschien wat te simpel bedacht, maar kun je de streaming applicatie niet aan een ip binden? En hem dan 2x opstarten met als enige verschil in de 2e config het ip van de 2e gbit interface?

[Kokkers]

Verwijderd schreef op woensdag 20 december 2006 @ 12:21:
Misschien wat te simpel bedacht, maar kun je de streaming applicatie niet aan een ip binden? En hem dan 2x opstarten met als enige verschil in de 2e config het ip van de 2e gbit interface?

Hier heb ik ook aan zitten denken, het OS bepaald echter de interface van het uitgaande verkeer, niet de applicatie.

Als het technisch mogelijk zou kunnen om de applicatie aan een specifiek IP en poort te binden zou dit volgens mij nog geen verschil maken.

[Kokkers]

bazkar schreef op woensdag 20 december 2006 @ 12:20:
Vast een rare vraag, maar waarom team je de twee NIC's niet tot een 2 Gbit interface en zet er 1 publiek adres op? Dat scheelt je een boel routeringsproblemen.

Ik heb geen ervaring met het teamen van 2 NIC's onder Windows Server 2003.
Als ik zou weten hoe en wat de technische gevolgen zijn...

Kom net 'Scalable Networking Pack' tegen in Windows Server 2003 SP1:
http://www.microsoft.com/technet/network/snp/faq.mspx

Onderdeel hiervan is TCP Chimney Offload Design:

TCP Chimney Offload also provides IHVs with a variety of intermediate driver solutions, such as “teaming” several network adapters to create a single virtual network adapter (for better fault tolerance or load balancing), and support of multiple Virtual LANs. IHVs with network adapters that support TCP Chimney Offload must update their intermediate drivers for NDIS 5.2 and TCP Chimney Offload.

[Kokkers]

WTF hey, ik heb een gebroken klomp...
De Intel adapters hebben in hun advanced config gewoon een tabblad 'Teaming'.

TCP Chimney Offload provides automated, stateful offload of Transmission Control Protocol (TCP) traffic processing to a specialized network adapter implementing a TCP Offload Engine (TOE). The stateful capabilities—meaning that the network adapter retains in memory the significant attributes of a connection, such as IP address, ports being used, and packet sequence numbers—significantly reduce the need for CPU cycles in managing offloaded traffic. For long-lived connections with large-sized packet payloads; like those associated with storage workloads, multimedia streaming, and other content-heavy applications; TCP Chimney Offload greatly reduces CPU overhead by delegating network packet processing tasks, including packet segmentation and reassembly, to the network adapter. This frees up CPU cycles for other application tasks, such as supporting more users sessions or processing application requests with lower latency.

Dit in combinatie met LACP op de router zou een 2GBit layer 2 kanaal op moeten leveren maken met virtuele adapter aan de client kant en een enkel publiek IP.

[ Voor 8% gewijzigd door Kokkers op 20-12-2006 13:14 ]

[bazkar]

Kokkers schreef op woensdag 20 december 2006 @ 12:41:
WTF hey, ik heb een gebroken klomp...
De Intel adapters hebben in hun advanced config gewoon een tabblad 'Teaming'.


[...]


Dit in combinatie met LACP op de router zou een 2GBit layer 2 kanaal op moeten leveren maken met virtuele adapter aan de client kant en een enkel publiek IP.

Dat was mijn punt ook een beetje Ik ben gewend te werken met HP DL380's en die hebben ook gewoon teaming software aan boord. Lijkt me allemaal een stuk simpeler (en goedkoper!) als routering/loadbalancing buiten de machine zelf.