High speed verbinding tussen workstation & fileserver

[manofsteam]

Ik heb begrepen dat het mogelijk moet zijn zonder al te grote investeringen onze workstations te moeten kunnen koppelen aan een fileserver met een hogere snelheid dan 1 gigabit.
Als het goed is moet dit op de volgende manier mogelijk zijn:

PCI-E netwerkkaart in fileserver met 4 Gigabit (1000) poorten. Als je in een workstation daarna zo'n zelfde kaart stopt, zou je het zo op moeten kunnen zetten dat je eigenlijk 1 verbinding hebt met een doovoersnelheid van 4 Gbit.

Mijn vraag is:
- Welke eigenschap(pen) van de kaart maken dit mogelijk, dwz waar moet ik op letten?
- Welke eisen heeft dit voor het besturingssysteem? Is het gewoon een TCPIP-verbinding?
- Zijn er speciale drivers nodig, of is het puur alleen een OS-ding?
- Is het mogelijk om de verbinding via een switch te laten lopen, zodat er meerdere workstations op deze verbinding kunnen?

[Verwijderd]

Ik denk dat dit neerkomt op trunking en volgens mij moet je wel een deftige switch hebben wil die daar iets mee kunnen doen.

[Verwijderd]

Valt wel mee hoor, hier kom je met teaming-software voor de ethernet poorten een heel eind. Als je aan beide kanten een team maakt van meerdere ethernet-poorten moet het mogelijk zijn om hogere bandbreedtes dan 1Gbit te halen.

[jvanhambelgium]

In de praktijk volledig nutteloos een 4x1 Gbits van een WORKSTATION naar en SERVER te trekken;
Wegen beperkingen (lees : eigenschappen) van de gebruikte protocols (oa tcp/ip) ga je als "enkeling" nooit die trunk volkrijgen !
Uw workstation kan trouwens de I/O toch niet bijhouden ! Concreet over welke workstations spreken we hier ?


Je zal zelfs al moeite hebben met 1Gbit/s OPTIMAAL te benutten. Hier komt redelijk wat tuning bij kijken (afhang. van gebruikte OS)

Keep it simple stupid. Hang gewoon uw fileserver met 1Gbit/sec op de switich net als uw andere workstations. Zo kom je al een héééél eind.
Ik weet niet wat voor "workstations" jij daar hebt, maar tenzij het video-editing systemen zijn lijkt meer als 1Gbits gewoon nutteloos.

Nu om concreet op je vragen te antwoorden :

- zoek een NIC die "teaming" ondersteuning heeft (vb 802.3ad standaard rond static-link-aggregation)
- kan je instellen, nic-teaming zit op Ethernet-niveau. Dus er zit gewoon 1 IP adres op die kaart.
- drivers van de NIC-kaart met ondersteuning van 802.3ad zijn voldoende aan de client kant.
- kan wel, switch moet natuurlijk ook 802.3ad spreken om effectief een trunk op te zetten natuurlijk!

In de praktijk kan dat wel wat trek en duw-werk worden voor alles deftig werkt, hangt van verschillende factoren af.

[TrailBlazer]

Verwijderd schreef op dinsdag 11 maart 2008 @ 22:30:
Ik denk dat dit neerkomt op trunking en volgens mij moet je wel een deftige switch hebben wil die daar iets mee kunnen doen.

trunking is het sturen van meerdere vlans over een fysiek/logisch touwtje. (802.1Q of ISL).
Hier wil de TS graag gebruik maken van een etherchannel waarbij je meerdere links bundelt tot een logische interfaces (LACP of PaGP) . Hier kan je dan wel weer 802.1q of ISL overheen praten.
Overigens raad ik hem ook aan om om gewoon een mooie switch te kopen die LACP ondersteunt en dan vrolijk een etherchannel te maken tussen de server en die switch en je clients met 1 gb aansluiten op die zelfde switch.

[ Voor 18% gewijzigd door TrailBlazer op 12-03-2008 08:18 ]

[JackBol]

TrailBlazer schreef op woensdag 12 maart 2008 @ 08:15:
[...]

trunking is het sturen van meerdere vlans over een fysiek/logisch touwtje.

Die definitie is nogal vendor-dependent

3com en nortel noemen port ageregatie (802.3ad, LACP en PAgP) bijv. trunking, terwijl Cisco juist vlan tagging (802.1q, ISL) trunking noemt.

We moeten eigenlijk helemaal van het woord trunking af. Want met wie je er ook over praat, je hebt altijd spraak-verwarring!

[manofsteam]

Het gaat inderdaad om video-workstations waar FULL HD uncompressed beelden bewerkt worden en dus heen en weer gepompt moeten worden (soms meerdere lagen tegelijk). Voor standaard e-mail verkeer zou ik niet boven de 1 Gbit uit willen komen.

Is bijvoorbeeld 'teaming' en standaard optie onder Windows? Ik ben wel IT-er maar al een tijdje uit de netwerkbusiness....

[jvanhambelgium]

>Is bijvoorbeeld 'teaming' en standaard optie onder Windows? Ik ben wel IT-er maar al een tijdje uit >de netwerkbusiness....

Indien je een 802.3ad capabele NIC gaat steken + drivers zal je een bonding groepje kunnen maken.
Windows "as-such" heeft er niet veel mee te zien.
Vooral de LAN-switch moet er natuurlijk mee omkunnen.

Sowieso denk ik dat meer als 2x1Gbps echt wel een limiet is voor een "workstation"
Zo'n dubbelen link geeft je toch wel een héééél aardige netwerk-transferrate in een switched omgeving.

Je zou dan kunnen proberen zo'n 4x1Gbps NIC kaart in "de server" te stoppen die dan hopelijk aan een rete-snelle SAN omgeving hangt ;-)

De volgende stap zou zijn de "workstations" uit te rusten met SAN HBA's om direct op een SAN storage omgeving te kunnen zonder eerst over een "minder efficient" Ethernet LAN netwerk te moeten. Maar iets zegt me dat dit budgettaire niet verantwoord gaat zijn ;-)

[manofsteam]

Dank je, jvanham. De server hangt aan een schijvenkabinet, en zou via PCI-E 8x i/o een snelheid moeten kunnen halen van 1600 Mb/seconden (lezen). Via gigabit kan je op een workstation (heb ik mij laten vertellen) zo rond de 100 Mb/sec opvragen. Theoretisch zou je dus 3 workstations kunnen verbinden met die server, allemaal direct, zonder switch, via 4x4 Gbit. Dan kan elk workstation 400 mb/sec opvragen en is er nog ruimte voor overhead op de server....

[jvanhambelgium]

Hmm, ik moet je zeggen dat toen ik een redelijk performante NAS heb gemaakt (ook via PCI-E ARECA raid controller en alle toeters en bellen onder Gentoo64 Linux) de transferrates van onze Sun "clients" ongeveer op 75MBytes/sec lagen.

PS : Vergeet die 400MB/sec per workstation maar al ;-) Het enige nuttige aan die 4x1G link met de server is dat je concurrent I/O wat beter gaat lukken, maar je mag niet zomaar beginnen vermenigdvuldigen...
Ik durf geen cijfers te plakken, maar ik zou het hééél puik vinden indien je workstations 150MBytes/sec kan doen indien je 2x1Gbps zou teamen.
Verwacht echt geen honderden megabytes /sec hoor ... DAT zou ik wel eens willen zien...

Voor de rest kan de performantie nog verschrikkelijk verschillen in functie van het gebruikt file-system (vb indien je "server" ook een windows bak is waar je een share ter beschikking gaat stellen voor workstations is dit de minst performante oplossing...)
Anders moet je een keertje naar iSCSI kijken vb.

[TrailBlazer]

Je moet eerst eens gaan kijken hoe je verkeerspatroon is want hoe groot is de kans nou dat al je clients tegelijkertijd die bandbreedte nodig hebben.

[jvanhambelgium]

Qua I/O patroon denk ik dat het vooral grote blokken data zijn (sequential reads/writes) indien het van die video bestanden van enkele gigabytes / stuk zijn, maar de concurrency is natuurlijk gokken van hieruit ... daar zal de topicstarter wel iets over kunnen zeggen.

Wat zijn eigenlijk de specs van de workstations ?? (gewoon ter info)

[TrailBlazer]

dan kan toch veel beter iets doen met een san oplossing of iets dergelijks. Je data hoeft dan toch niet volledig op je systeem te staan voordat je er wat mee kan doen.

[jvanhambelgium]

Tja, het snelste en beste zou inderdaad zijn om effectief een HBA (host-bus-adapter) in het workstation te prikken zijn zodat je direct een SAN omgeving kan inhaken...doch ik vrees ook de meest dure ;-)
Als de HBA weg inslaat heb je de performantie alsof je disken lokaal staan....dan heb je nog de keuze van FC (over glas of koper) , iSCSI ,etc.

Ze hebben daar "een schijvenkabinet met PCI-E controllertje" staan maar dat zegt niet veel...zelfbouwding ?
In dat geval zou ik me durven wagen aan iSCSI over ethernet met een 2x1G NIC's in teaming als goedkoopste en performanste oplossing.

Wel ,natuurlijk zorgen dat de server-kant iSCSI target capabel is natuurlijk...iSCSI initiator software voor Windows is (gratis) beschikbaar.

[Femme]

Mijn ervaring is dat Windows filesharing gewoon waardeloos schaalt. Tussen client en server haal je in de praktijk niet meer dan 50MB/s ongeacht de performance van de storage aan beide zijden van het draadje. Ik ben benieuwd of er mensen zijn die ervaring hebben met trunking en prestaties daarvan.

Met een software iSCSI-initiator haal je wel 120MB/s op een gigabitverbinding. Als de gedachte is dat de videobestanden voor meerdere systemen toegankelijk moeten zijn wil je echter geen iSCSI gebruiken.

[CyBeR]

_DH schreef op woensdag 12 maart 2008 @ 11:40:
[...]


Die definitie is nogal vendor-dependent

3com en nortel noemen port ageregatie (802.3ad, LACP en PAgP) bijv. trunking, terwijl Cisco juist vlan tagging (802.1q, ISL) trunking noemt.

Cisco is correct hier (voor de gein )

We moeten eigenlijk helemaal van het woord trunking af. Want met wie je er ook over praat, je hebt altijd spraak-verwarring!

Lijkt me overdreven. Het woord komt al sinds ver voor de computerindustrie bestond uit de telefoniewereld. Een trunk is daar een verbinding waarover meerdere gesprekken tegelijk gevoerd konden worden. (Toentertijd meestal geimplementeerd met enorme bundels koper )

[TrailBlazer]

Femme schreef op donderdag 13 maart 2008 @ 13:06:
Mijn ervaring is dat Windows filesharing gewoon waardeloos schaalt. Tussen client en server haal je in de praktijk niet meer dan 50MB/s ongeacht de performance van de storage aan beide zijden van het draadje. Ik ben benieuwd of er mensen zijn die ervaring hebben met trunking en prestaties daarvan.

Met een software iSCSI-initiator haal je wel 120MB/s op een gigabitverbinding. Als de gedachte is dat de videobestanden voor meerdere systemen toegankelijk moeten zijn wil je echter geen iSCSI gebruiken.

Op mijn werk worden wel poorten gebundeld maar dat is denk ik meer voor redundancy dan voor echt hogere bandbreedte. Gisteren toevallig de 1e servers direct met 10Gb aangesloten en daar haalden we wel een gezamenlijke bandbreedte van meer dan 2 GB/s op. Dit is allemaal wel state of the art hardware die we hiervoor inzetten. Alle SANs zijn ook met multigigabit aangesloten.

[jvanhambelgium]

>Gisteren toevallig de 1e servers direct met 10Gb aangesloten en daar haalden we wel een >gezamenlijke bandbreedte van meer dan 200 GB/s op.

Wat bedoel je hier ? Een hele groep servers met elk 10Gbits/sec ethernet kaarten op de switches aangesloten en aldus 200GB/s ??

[TrailBlazer]

nee dat ik grootheids waanzin heb. was meer dan 2 Gigabyte per seconde.

[jvanhambelgium]

Dan zal het een heel flinke server zijn !! Enig idee over welke hardware we hier spreken ?
Ziet er mij een flinke Sun server-complex, HP Superdome of gelijkwaardig uit om 2Gbytes/sec aan I/O te doen....kwijl,kwijl

[TrailBlazer]

het schijnt the top of the line te zijn van de IBM P5 series

[Hardware Junk]

Een gemiddeld Workstation plankje bezit al 2x 1Gbit netwerk poort, en is vaak managable. Met mijn 'oude' Tyan Thunder n3600B stond er op de driverCD gewoon software om de 2x 1GBit te laten bundelen als 1x 2Gbit met failover (trekt er realtime een kabel uit en je gaat van 2Gbit naar 1Gbit zonder de connectie te verbreken). Geen dure PCI-E kaartjes voor nodig.

Wel zal je een trechter gaan vormen naar de server zelf toe. Als je hierin met flinke Raid 10 of Raid 50 te maken hebt, kan je de vernauwing op het netwerk gaan zoeken. Dus alleen in de server een quad ports Gbit netwerkkaartje is al voldoende.

Switches die hiervoor geschikt zijn hoeven niet duur te zijn. Voor onder de 100 euro heb je op eBay al leuke Summits.

[gammuts]

1 probleem dat ik nog niet gehoord hebt: de switches die ik ken (HP ProCurves) spreken LACP, maar 'verdelen' data over de poortjes met het volgende algoritme:
(srcmac ^ dstmac) % #poorteningroep
Aangezien de aanmelder spreekt over een 1-op-1-situatie, kan de server en workstation wel met 4 Gbps gaan pompen, maar levert de switch de data met 1 Gbps af op de workstation resp. server, immers srcmac en dstmac zijn constant, switch gebruikt steeds dezelfde poort...

In ons netwerk t.b.v. backups, staat een linuxdoos als router. Die doos heb ik geconfigureerd dat ie in layer 4 data over de NICs verdeeld (src IP, dst IP, src port, dst port worden meegenomen). Op die manier kan je aan de serverkant nog wel iets bewerkstelligen om richting 1 andere doos meer dan 1Gpbs te sturen. Maar ja, nogmaals, als de switch 'slechts' verdeeld op basis van layer 2 zal aan het andere eind de bottleneck van 1 Gbps zitten.

[geneuzel]
Linux 2.6 hebben niet veel 'chiptuning' nodig qua kernelparameters; er wordt on-the-fly door de kernel zelf aan getuned. Zelf tunen in 2.4 leverde ons 950Mpbs full duplex op in een 1 NIC configuratie.
[/geneuzel]

[jvanhambelgium]

>1 probleem dat ik nog niet gehoord hebt: de switches die ik ken (HP ProCurves) spreken LACP, >maar 'verdelen' data over de poortjes met het volgende algoritme:
>(srcmac ^ dstmac) % #poorteningroep
>Aangezien de aanmelder spreekt over een 1-op-1-situatie, kan de server en workstation wel met 4 >Gbps gaan pompen, maar levert de switch de data met 1 Gbps af op de workstation resp. server, i
>mmers srcmac en dstmac zijn constant, switch gebruikt steeds dezelfde poort...


Geen round-robin verdeling van de frames over de 2 links ?? Dat zou straf zijn...
Anyway, dan is het tijd om een andere switch te nemen ;-)

[TrailBlazer]

round robin kan je volgens mij vaak wel instellen maar het wordt vaak niet gedaan omdat je dan problemen kan krijgen met out of order paketten.

[CyBeR]

TrailBlazer schreef op zondag 16 maart 2008 @ 08:51:
round robin kan je volgens mij vaak wel instellen maar het wordt vaak niet gedaan omdat je dan problemen kan krijgen met out of order paketten.

Ik snap 't probleem daarmee nooit zo. TCP houdt daar rekening mee (sequence nummers) en met UDP is 't bekend dat dat kan gebeuren en moet je als applicatieontwikkelaar er rekening mee houden. Andere niet-reliable protocollen idem dito.

[ Voor 4% gewijzigd door CyBeR op 16-03-2008 13:27 ]

[jvanhambelgium]

Deze round-robin is zelfs op ethernet niveau, dus afwisselend een frame op de ene link en dan de andere.
Hetgeen ik ervan gelezen heb is dat je iets van specifieke buffering moet hebben aan de andere kant op eventueel een "out of order" op te vangen.

In principe denk ik dat de problemen wel meevallen : zelfde link-snelheid, direct path (kabel) tussen server en switch zonder enige andere "verstoring". (het is niet dat er nog ergens ander L2 hardware/repeaters tussen staan)

Tja, proberen hé en zien wat de netto-winst zal zijn....

[Verwijderd]

Klopt, maar je moet je wel realiseren dat een paar mili seconden verschil al een paar handert frames out of order betekend, en daar houden tcp stacks over het algemeen weer geen rekening mee.

CyBeR schreef op zondag 16 maart 2008 @ 13:27:
[...]


Ik snap 't probleem daarmee nooit zo. TCP houdt daar rekening mee (sequence nummers) en met UDP is 't bekend dat dat kan gebeuren en moet je als applicatieontwikkelaar er rekening mee houden. Andere niet-reliable protocollen idem dito.

[CyBeR]

Verwijderd schreef op dinsdag 18 maart 2008 @ 20:18:
Klopt, maar je moet je wel realiseren dat een paar mili seconden verschil al een paar handert frames out of order betekend, en daar houden tcp stacks over het algemeen weer geen rekening mee.


[...]

Met round-robin over een dual-link verbinding heen betekent niet een paar milliseconden of een paar honderd frames out-of-order, dat betekent dat er mischien twee frames tussen zitten..

[jvanhambelgium]

Zolang je streeft naar identieke links zal het wel meevallen. Met die 2 linken zul je vb dan 195% capaciteit halen ipv de theoretische 200%. Als je vb 4 links zou gebruiken denk ik niet dat je 400% snelheid gaat halen maar eerder 320% a 330% ofzo (wat nog retesnel is natuurlijk...) ? Ik heb hier geen praktische testen mee gedaan,

Als je centen genoeg heb mischien eens kijken of een 10GE kaartje en switch-module in budget zitten ;-)
Koop er dan maar ineens een deftige server bij die deze I/O kan verwerken ;-)