[Protocol] Grote hoeveelheden data

[capedro]

Alloa,

Hier op mijn werk zitten we met een aantal leuke uitdagingen... details mag ik helaas niet verklappen anders sta ik op straat

Goed het volgende...

Voor een aantal processen die wij hebben moet we veelal Gigabytes transporteren, momenteel lopen we met die (minder) fijne FireWire schijven van Lacie heen en weer. Echter de betrouwbaarheid van deze schijven (van Lacie) laat veelal te wensen over

We willen dus een lekker NAS/SAN plaatsen waarbij dus een aantal collega's binnen dat proces over een netwerk heen kunnen werken. Momenteel gebruiken we intern (zoals iedereen bijna) het TCP/IP Protocol icm SMB. Echter ik heb begrepen dat TCP/IP nogal wat overhead heeft, waardoor we weer minder bandbreedte hebben voor de genoemde processen.

Hebben jullie enig idee welk protocol ik anders zou kunnen gebruiken (maw uitgekleede versie van TCP/IP of gewoon heeeeeel iets anders)

Ik ben benieuwd...

_{Ik hoop dat dit het goede forum is...}

[richard_kraal]

netbeui, niet routeerbaar en het kleinste overhead

[dvherk]

Misschien kan je eens zoeken naar:
- gigabit ethernet
- 10gigabit ethernet ( http://www.10gea.org/ )
- verder zijn er nog protocollen als ATM/ atm over ethernet ...

Twee lekkere dikkuh switches van foundry tussen de afdelingen/vestigingen zou een leuke oplossingen zijn. Een glasvezel draadje er tussen en klaar?!

Denk dat je op site's als foundry/cisco/nortel networks/extreme wel aardig wat info weg kan trekken

[The Eagle]

Denk dat je met iets van Cityring van KPN wel het e.e.a kunt doen, tenminste als je het over meerdere vestigingen hebt. En anders ben je denk ik een beetje dom om data te vervoeren op firewire HDD's ipv via een netwerkverbinding.

[mvdejong]

Echte FibreChannel gebruiken, niet je data-transport-protocol nog eens bovenop een netwerk-protocol sturen.
FibreChannel is speciaal gemaakt voor SAN-toepassingen.

[Coen Rosdorff]

Hoever liggen de locaties uit elkaar?
Is er al een netwerk? Zo ja is de reden dat dit netwerk niet gebruikt wordt voor deze data puur de snelheid?

Te weinig details voor een zinnig antwoord.

[Maarten @klet.st]

capedro schreef op 15 juli 2003 @ 12:24:
We willen dus een lekker NAS/SAN plaatsen waarbij dus een aantal collega's binnen dat proces over een netwerk heen kunnen werken. Momenteel gebruiken we intern (zoals iedereen bijna) het TCP/IP Protocol icm SMB. Echter ik heb begrepen dat TCP/IP nogal wat overhead heeft, waardoor we weer minder bandbreedte hebben voor de genoemde processen.

Hebben jullie enig idee welk protocol ik anders zou kunnen gebruiken (maw uitgekleede versie van TCP/IP of gewoon heeeeeel iets anders)
_{Ik hoop dat dit het goede forum is...}

Je bent een beetje vaag in wat je precies wilt, maar ik doe even de aanname dat je met meerdere collega's in een gebouw bij een grote hoeveelheid data wilt. Cifs/SMB is dan de meest logische optie. NFS is een alternatief, maar zal in jouw geval niet helpen. Zowel NFS als SMB gebruiken inderdaad tcp/ip als drager. Voor mainstream toepassingen voldoende, maar als je echt high-performance wilt kan het een probleem worden. high-performance is een rekbaar begrip, enkele tientallen megabytes/sec moet echt wel lukken via SMB of NFS, mits de server met de storage dat trekt (disk c.q. raid IO is vaak de bottleneck).

Alternatief, als je daadwerkelijk met meerdere gebruikers gelijktijdig, wilt werken is een SAN waarbij elk werkstation een eigen fibre-channel HBA heeft dat (meestal via een switch) verbonden is met de SAN storage.
In 99% van de gevallen worden simultane connecties (meerdere servers/werkstations naar dezelfde storage partitie) echter niet ondersteund De software die je gebruikt om het SAN in te richten moet het ondersteunen (wordt meestal bij het ijzer geleverd), maar belangrijker: het filesystem.
Er zijn er een handjevol, bijvoorbeeld: veritas filesystem, IBM's gpfs, GFS van polyserve, GFS van een ander bedrijf (ff naam kwijt), cXFS van SGI. Met NTFS, ext2, ext3, UFS e.d. kun je simultane read/write connecties vergeten, daar zijn die filesystems niet voor gemaakt. (Ext2 met 1x rw en 1x ro heb ikwel eens getest, lijkt te werken).

Bovenstaande optie is echter nogal een dure oplossing. Als je het allemaal zelf voor elkaar wilt krijgen moet je rekening houden met de nodige kosten voor SAN storage, SAN switches, meerdere HBA's, prijzige licenties voor software en/of filesystem etc. Het probleem met de meeste SAN oplossingen is dat ze niet waarmaken wat ze lijken te beloven, namelijk simultane connecties door meer servers naar een storagelocatie/partitie. Voordeel van het gebruik van een SAN an sich is dat de gebruikte (RAID) controllers wat vlotter werken dat een 'eenvoudige' SCSI RAID controller in een server. Die laatste laten het meestal afweten qua cpu power als je veel (meerdere TB's) wilt (vooral in Raid 3/4/5).

[capedro]

little_soundman schreef op 15 juli 2003 @ 21:39:
Hoever liggen de locaties uit elkaar?
Is er al een netwerk? Zo ja is de reden dat dit netwerk niet gebruikt wordt voor deze data puur de snelheid?

Te weinig details voor een zinnig antwoord.

We zitten allemaal op dezelfde verdieping!

Er is al een netwerk (100Mbit ) echter deze gaat ook vervangen worden door minimaal Gigabit ethernet danwel glasvezel.

[Coen Rosdorff]

capedro schreef op 16 July 2003 @ 11:17:We zitten allemaal op dezelfde verdieping!

Er is al een netwerk (100Mbit ) echter deze gaat ook vervangen worden door minimaal Gigabit ethernet danwel glasvezel.

Eerder NAS dan in dat geval lijkt mij. GigE met NAS zou voldoende performance moeten leveren.

NAS apparatuur is er in vele soorten en maten. Van een paar honderd GB tot een paar TB en van relatief goedkoop tot zeer duur. Kan je echt alle kanten mee op.

[igmar]

capedro schreef op 15 juli 2003 @ 12:24:
Momenteel gebruiken we intern (zoals iedereen bijna) het TCP/IP Protocol icm SMB. Echter ik heb begrepen dat TCP/IP nogal wat overhead heeft, waardoor we weer minder bandbreedte hebben voor de genoemde processen.

Je gebruikt SMB, en maakt je zorgen over de TCP overhead ?

Hebben jullie enig idee welk protocol ik anders zou kunnen gebruiken (maw uitgekleede versie van TCP/IP of gewoon heeeeeel iets anders)

Gewoon een SAN neerzetten, en zorgen dat je voldoende bandbreedte hebt. Gigabit is meer dan voldoende zou ik zo zeggen.