netwerk transfer, waar zit de bottleneck

[grindal81]

Mogelijk een eenvoudig vraagje voor jullie netwerk specialisten...

Ik zou willen weten wat de "bottleneck" is in data transfer als je data over een 1Gig netwerk link verstuurd.
is dit de storage (harde schijven) of is dit de netwerk verbinding.


locatie A: Storage Raid 6 (6TB SAS )<=> 1 Gig netwerk link <=> B: Storage Raid 6

Hoeveel capaciteit van de 1 Gig link zal er gebruikt worden en waar zit de limiet?
In de lees/schrijfsnelheid van de schijven of in de netwerk verbinding?

% hoeveel van de 1Gig link zal dus Maw gebruikt worden op het moment dat ik bv data copier van bv 200GB

iemand die dit kan verklaren?

komt er op neer dat ik wil weten of je door een data transfer uw 1gig verbinding kan plat-gooien (waar ook andere trafiek over loopt).

[MAX3400]

Is dit theoretisch of praktisch?

Indien theoretisch: ja, je kan Gbit makkelijk volpompen.

Indien praktisch: wat zijn de storage benchmarks (write I/O bij bepaalde QD) en is dat hoger/lager dan 128MB/s continuous?

[Microkid]

Ja, je kan de verbinding plat gooien. Als ik vanaf mijn werkstation met SSD een groot bestand naar mijn NAS kopieer via een 1Gbps verbinding, trekt deze actie de verbinding geheel dicht, de snelheid is dan >100MB/sec. De kopieeractie zal alles pakken wat hij aan bandbreedte kan krijgen.

[grindal81]

ah ok thx... opletten dus bij copy acties....

[MAX3400]

grindal81 schreef op donderdag 12 juli 2018 @ 21:09:
ah ok thx... opletten dus bij copy acties....

Nee? Wat is je throughput van je controller tijdens synthetische benchmarks? Over welke protocollen hebben we het? "Hoe" ziet die 200GB aan data eruit?

[RocketKoen]

Of je verbinding dicht getrokken wordt ligt meer aan je switch en de software die je gebruikt.
Een ethernet packet is max 1,5 kB. Bij 1Gbit is dat een packet per 0.01ms. Anders verkeer kan dus ongemerkt voorrang krijgen als het slim wordt geshaped.

[Ben(V)]

Tjonge wat een theoretische geleuter.

Tenzij je antieke hardware hebt is de 1Gb/s absoluut de bottleneck.
1Gb/s komt neer op theoretisch max van 125MB/s
De volgende bottleneck is je Harddisk die maxen uit op zo'n 180MB/s

[M2M]

Ben(V) schreef op donderdag 12 juli 2018 @ 21:44:
Tjonge wat een theoretische geleuter.

Tenzij je antieke hardware hebt is de 1Gb/s absoluut de bottleneck.
1Gb/s komt neer op theoretisch max van 125GB/s
De volgende bottleneck is je Harddisk die maxen uit op zo'n 180GB/s

toch wel erg veel zo'n 125GB/s. Dat is toch een goede terrabit per seconde.

[Ben(V)]

Bedank voor de melding, ik heb m'n fout aangepast.

[MAX3400]

Ben(V) schreef op donderdag 12 juli 2018 @ 21:44:
Tjonge wat een theoretische geleuter.
...
De volgende bottleneck is je Harddisk die maxen uit op zo'n 180MB/s

Over geleuter gesproken...

^ plaatje uit 2011 van relatief consumer-grade controllers met een degraded array etc...

Vraag me dus af waar je die zogenaamde 180MB/s vandaan haalt? Afhankelijk van de array-configuratie, caching, source-data, blocksizing, drive-cache, spindle-speed etc. etc. etc. is die 180MB/s van je enigszins uit de lucht gegrepen en niet gestaafd tegen enige uitspraken/waarden/info van de topicstarter.

Hier dan even een dd write-test inclusief controller sync op een Intel 170-chipset met 2 "gewone" consumer-grade HGST-drives van elk 2TB in software RAID0 (mdadm-based)

Resultaten zullen ongetwijfeld tegenvallen (zal iemand beargumenteren) maar heb niet opgelet welke andere processen er op dat moment aktief waren, hoeveel RAM er was, wat de actuele diskload was etc.

Ach, ook MKB-nasjes zoals een DS15xx of DS18xx met een Gbit-trunk halen in verschillende write tests ook snelheden ver boven de 350MB/s. Om dus "bot" te stellen dat je bottleneck je disk wordt want maar 180MB/s, snap ik dan niet geheel, ook niet omdat er sprake is van SAS-disks die per stuk al gewaardeerd worden (in v3.0 uitvoering en aangesloten op correcte controllers) tot meerdere GB/s burst-speeds zoals pricewatch: Seagate Enterprise Performance 15K HDD (2016), 4K, 600GB


TLDR? Aannames van 180MB/s op basis van te weinig info, vind ik lastig in een storage-vraagstukje.

[Ben(V)]

Modbreak:

Dergelijke uitspraken zijn niet nodig. Of je onderbouwt je verhaal met bewijs, of je zegt niets. Domweg roepen dat het geleuter is vind ik erg kinderachtig.

[ Voor 82% gewijzigd door Equator op 13-07-2018 06:55 ]

[Equator]

Er zijn natuurlijk vele meer factoren die van invloed zijn op de doorvoersnelheid. Wat voor storage systeem, processor type, aantal spindels, queudepth, type disken (NLSAS, 10k, 15k), cache in het systeem, het type data (grote files van 100GB, of 1M files van 10kB.) en het gebruikte protocol.

Dus er is weinig over te zeggen. Een nieuw storage systeem krijgt met 1M files van 10kB de lijn waarschijnlijk niet vol op het CIFS protocol. Maar gebruikt de storage een blockbased synchronisatie techniek, dan kan dat zomaar anders zijn.

En zelfs al heb je al deze informatie, dan is dat vrijwel onmogelijk om te berekenen. Meten is weten. Gewoon een keer proberen in de avonduren

[grindal81]

Ben(V) schreef op donderdag 12 juli 2018 @ 21:44:
Tjonge wat een theoretische geleuter.

Tenzij je antieke hardware hebt is de 1Gb/s absoluut de bottleneck.
1Gb/s komt neer op theoretisch max van 125MB/s
De volgende bottleneck is je Harddisk die maxen uit op zo'n 180MB/s

Allen bedankt voor de reacties...

Conclusie, speed netwerk is de beperkende factor en kan je dus idd dichttrekken als je niet oplet.

[Croga]

grindal81 schreef op woensdag 18 juli 2018 @ 12:26:
Conclusie, speed netwerk is de beperkende factor en kan je dus idd dichttrekken als je niet oplet.

Die is wat voorbarig. Kijk eens naar MAX' post. De real-world performance is heel wat anders dan de theoretische performance.

Ofwel: Theoretisch is het wellicht juist de 1Gbit/s de beperking is. In de praktijk not so much; mijn 4-drive RAID0 array in m'n Synology NAS komt nog niet in de buurt van de 125MB/s, ondanks dat de 4 schijven bij elkaar dat makkelijk vol zouden moeten kunnen trekken.

Meten is weten; wat is de daadwerkelijke real-life performance van je schijf-systeem?

[Umbrah]

grindal81 schreef op woensdag 18 juli 2018 @ 12:26:
[...]


Allen bedankt voor de reacties...

Conclusie, speed netwerk is de beperkende factor en kan je dus idd dichttrekken als je niet oplet.

"Dicht trekken" is ook zo'n ruim begrip... tussen jou en de NAS ligt waarschijnlijk meer dan een crosslink kabel. Waarschijnlijk is er een switch, misschien een paar routers, mogelijk een gateway, mooie palo alto appliance, etc... de gemiddelde switch is perfect in staat om z'n backplane aan te wenden om als JIJ 1gbit aan het pompen bent naar de NAS, het verkeer van iemand anders naar je internet endpoint niet te knijpen. Daar is het immers een switch voor, geen hub.

Op je eigen computer heb je daarnaast ook nog eens QOS vaak, wat er voor zorgt dat je andere netwerk workflows niet gelijk óók problemen hebben, dicht trekken is dus een breed begrip.

Bovendien hebben de meeste NAS-en wel meerdere netwerkpoorten (die kunnen teamen), of zelfs een 10GBit link naar een switch met een 10GBit poort, en zo kun je dan vrij eenvoudig meerdere mensen vanaf één NAS voorzien terwijl ze elk hun individuele 1GBit lijntje vol trekken.

[Ben(V)]

Croga schreef op woensdag 18 juli 2018 @ 12:31:
[...]

Die is wat voorbarig. Kijk eens naar MAX' post. De real-world performance is heel wat anders dan de theoretische performance.

Ofwel: Theoretisch is het wellicht juist de 1Gbit/s de beperking is. In de praktijk not so much; mijn 4-drive RAID0 array in m'n Synology NAS komt nog niet in de buurt van de 125MB/s, ondanks dat de 4 schijven bij elkaar dat makkelijk vol zouden moeten kunnen trekken.

Meten is weten; wat is de daadwerkelijke real-life performance van je schijf-systeem?

Je meet zeker over het netwerk want je moet wel een heel beroerde Nas hebben wil die dat niet kunnen bijbenen.
Meet maar eens de snelheid binnen je Nas.
Dus bestand kopieren van de ene plek naar de andere.

@MAX3400
Je vergelijkt appels met peren.
Ik had het over de snelheid van een enkele harddisk en jij gaat het vergelijken met Nas raidsystemen.
En uiteraard is die 180MB/s geen absoluut getal en dat beweerde ik ok niet.
Je staaft de orde van grote eigenlijk zelf met je eigen dd write test van een Raid 0 set.

En uiteraard ga je in op iets wat helemaal niet met de vraag te maken had.
TS wilde gewoon weten of het netwerk de bottleneck is dat is juist.
trek je eigen conclusies.

[ Voor 23% gewijzigd door Ben(V) op 18-07-2018 13:01 ]

[MAX3400]

@Ben(V) dan ga je nog steeds voorbij aan mijn voorbeeld dat een goede SAS-controller met die Seagate disk, een burst van enkele GB/s kan hebben. Dat is nog immer hoger dan de waarde die je constant noemt. Ik wil best leren maar licht mij (en topicstarter) dan voor op basis van de beschikbare info waar de disk-limiet ligt?

Daarna zet je Gbit af tegen die arbitraire grens en stelt dat het netwerk de bottleneck is. Zoals mijn eerdere antwoord; afhankelijk van protocol en de totale datastream (incl het lezen), kan het zomaar zijn dat de throughput op het netwerk helemaal geen Gbit benadert maar blijft steken op 17MB/s bijvoorbeeld.

Ongetwijfeld zal ik ook waarden missen of niet snappen (ook in mijn ervaring met enterprise storage) maar sta open voor een verhelderend antwoord waardoor ik ook snap (en bewijsbaar heb) dat Gbit voor topicstarter de absolute en enige bottleneck is.

[Ben(V)]

Begrijp echt niet waar je heen wilt.
Ik gaf alleen het voorbeeld van wat een enkele disk ongeveer voor snelheid kan halen ter illustratie dat het netwerk de bottleneck is.

En jij komt met verhalen aan dat raidset en raidcontrollers nog veel hogere snelheden halen.
En dat netwerk overhead er voor zorgt dat je effectief die 1Gb niet haalt.
Is allemaal waar, maar dat zorgt er alleen maar voor dat het nog duidelijker wordt dat het netwerk de bottleneck is.
Daar ging het toch om?

En natuurlijk kun je ook een 10Gb netwerk bouwen maar dat is net als enterprise storage toch volkomen buiten de scope van zijn vraag?

[McKaamos]

@Ben(V)
We (als reageerders in dit topic) hebben geen idee wat de hardware achter de RAID6 sets van de TS is.
Ja, in theorie is een reguliere harddisk zo tussen de 150 en 200MB/s bij sequentieele reads en writes.
Ja, dat is sneller dan een Gigabit netwerkverbinding, die op z'n top 125MB/s verplaatst.

Mag je dan meteen de conclusie stellen dat het netwerk de bottleneck is?
Nee, helaas niet.

Wat @MAX3400 tegen je probeert te zeggen, is dat jouw voorbeeld niet van toepassing is.
Een single-disk situatie is totaal wat anders dan een RAID6 array. Die RAID situatie is waar de TS naar vraagt.
Daar heb je dan ook nog weer verschillende gradaties in. Zijn voorbeeld laat zien dat, mits goed uitgevoerd met fatsoenlijke aansturende hardware, een RAID6 array zich totaal anders gedraagt dan een single-disk toepassing.
En per toeval dan ook nog eens knetterveel sneller is, maar dat terzeide.

Aan de andere kant van het spectrum heb je volledig non-adequate hardware zoals een Synology of QNAP consumer-grade NAS. B.v. de situatie die @Croga laat zien.
Mits genoeg gevulde drive-slots, kan zo'n ding prima ingesteld worden om RAID6 te draaien.
Gaat dat dan ook de hele Gigabit vol trekken? Hoogstwaarschijnlijk niet, en mag je in je handjes wrijven als je 0,25Gigabit haalt.
Dat illustreert @Croga door een relatief rekenwerk-vrije variant van RAID te gebruiken (namelijk RAID0, dat is vele malen minder intensief dan RAID6) op een array van disks, en dan alsnog een beroerd lage snelheid te halen.

[ Voor 3% gewijzigd door McKaamos op 18-07-2018 14:06 ]

[dion_b]

Het is inderdaad aannemelijk - maar allerminst bewezen - dat deze transfers de verbinding plat zouden kunnen trekken. Dit moet je gewoon testen.

Als het zo blijkt te zijn de volgende vraag is: nou en? Wat voor verkeer (hoeveelheid en type) gaat verder over die verbinding?

Gevolg van meer aanbod van ongeprioritiseerd verkeer aan een link dan het aankan is dat alles in principe wel doorkomt, maar de capaciteit wordt gedeeld waardoor bandbreedte van het andere verkeer vermoedelijk evenredig omlaag zal gaan, en mogelijk latencies iets toenemen.

Wil je dat vermijden, dan kun je prima verschillende VLANs gebruiken met verschillende QoS prioriteit, waarbij je het bulkverkeer 'background' maakt en de overige verkeer 'best effort' of beter.

[ Voor 4% gewijzigd door dion_b op 18-07-2018 14:10 ]

[McKaamos]

dion_b schreef op woensdag 18 juli 2018 @ 14:09:
Het is inderdaad aannemelijk - maar allerminst bewezen - dat deze transfers de verbinding plat zouden kunnen trekken. Dit moet je gewoon testen.

Als het zo blijkt te zijn de volgende vraag is: nou en? Wat voor verkeer (hoeveelheid en type) gaat verder over die verbinding?

Gevolg van meer aanbod van ongeprioritiseerd verkeer aan een link dan het aankan is dat alles in principe wel doorkomt, maar de capaciteit wordt gedeeld waardoor bandbreedte van het andere verkeer vermoedelijk evenredig omlaag zal gaan, en mogelijk latencies iets toenemen.

Wil je dat vermijden, dan kun je prima verschillende VLANs gebruiken met verschillende QoS prioriteit, waarbij je het bulkverkeer 'background' maakt en de overige verkeer 'best effort' of beter.

Precies, als dat dan weer een probleem wordt, zal je moeten gaan kijken naar managed switches.
Gelukkig zijn er tegenwoordig aardig wat betaalbare switches op de markt die dergelijke functionaliteit bieden.
Voor wie zoiets zoekt: https://nl.hardware.info/...review-onmisbare-schakels

[Ben(V)]

@McKaamos
Ik kan je verzekeren dat een Synology Nas met gemakt een 1Gb netwerk verbinding dichttrek en daar hoef je helemaal geen duur model voor te hebben.
Mijn DS414 met een simpele arm processor erin doet dat met gemak.
Alleen als je gaat testen met veel kleine bestanden gaat er een cpu bottleneck onstaan.

Ik heb uitgebreide metingen daaraan gedaan en zelfs een PC met een enkele trage disk van 5400 toeren trekt nog met gemak een 1Gb netwerk verbinding vol.
Metingen zijn gedaan zonder andere belasting op het netwerk.

[McKaamos]

Ben(V) schreef op woensdag 18 juli 2018 @ 14:23:
@McKaamos
Ik kan je verzekeren dat een Synology Nas met gemakt een 1Gb netwerk verbinding dichttrek en daar hoef je helemaal geen duur model voor te hebben.
Mijn DS414 met een simpele arm processor erin doet dat met gemak.
Alleen als je gaat testen met veel kleine bestanden gaat er een cpu bottleneck onstaan.

Ik heb uitgebreide metingen daaraan gedaan en zelfs een PC met een enkele trage disk van 5400 toeren trekt nog met gemak een 1Gb netwerk verbinding vol.
Metingen zijn gedaan zonder andere belasting op het netwerk.

Maar nu de hamvraag: Gebruik je RAID, en zo ja, welk level?
Als het een JBOD is of RAID0 of 1, dan is het totaal niet relevant dat je de gigabit vol krijgt. De TS vraagt naar RAID6.

Edti:
Laat ik daar nog even wat aan toevoegen om het punt te benadrukken: Niet alle NASsen zijn gelijk. Er zijn ook betere modellen te krijgen dan de standaard consumentenmodellen en die trekken de gigabit wel netjes tot z'n max onder de door de TS beoogde toepasing.
Maar dat is het punt van de discussie niet.

Het punt is dat je niet zomaar kan stellen dat gigabit de bottleneck is zonder te weten wat de rest van de hardware is.

[ Voor 22% gewijzigd door McKaamos op 18-07-2018 15:09 . Reden: even extra duidelijkheid toegevoegd ]

[Simon1984]

Je vroeg onderaan je topic als volgt:

komt er op neer dat ik wil weten of je door een data transfer uw 1gig verbinding kan plat-gooien (waar ook andere trafiek over loopt).

Ja dat kan, het is helemaal afhankelijk van je 'omgeving' wat voor soort data is het, zoals al eerder gesteld je theoretische maximale waarde op netwerkvlak is 125MB/s.

Je kunt inderdaad ook nog werken met jumbo frames, QoS en andere zaken echter is dit allemaal niet relevant in die zin, deze vraag is niet echt te beantwoorden en dat lijkt mij ook niet zo erg...soms is 'nee' ook een antwoord .


Ik vraag me af of je in de tussentijd al eens wat getest hebt.....je startte het topic de 12e, mogelijk weet je zelf al meer>