Bouw flinke NAS

[jaco]

100GE is erg duur om in je netwerk te zetteb, maar als 8x10GE niet meer genoeg is moet je wat (8 is bij Cisco de grens van een aggregated link - etherchannel voor cisco)

[Robert T]

Zou de use case best eens willen horen voor 10Gbps thuis 

[riwi]

Zou de use case best eens willen horen voor 10Gbps thuis 

Da's simpel :
Je hebt 1 NAS server vol staan met  100 TB en wil een backup maken naar de tweede NAS. Dan is het via 10Gbe wel een stuk vlotter gedaan dan via 1Gbe.

Ik heb met 3 zpools in 1 PC ook al eens een pool 'leeg' gekopieerd (data naar de andere 2 pools) en dat gaat dan intern in de PC met 400-500MB/sec. Dat soort acties duren anders gewoon te lang. Ik heb mijn 2de PC via dual gbit gekoppeld, maar moet nog testen hoe snel het nu is. De 2de PC is ook een beetje een oud gebakje die moet ik eigenlijk vervangen, maar voor testwerk nog wel OK.

[jvanhambelgium]

Da's simpel :
Je hebt 1 NAS server vol staan met  100 TB en wil een backup maken naar de tweede NAS. Dan is het via 10Gbe wel een stuk vlotter gedaan dan via 1Gbe.

Ik heb met 3 zpools in 1 PC ook al eens een pool 'leeg' gekopieerd (data naar de andere 2 pools) en dat gaat dan intern in de PC met 400-500MB/sec. Dat soort acties duren anders gewoon te lang. Ik heb mijn 2de PC via dual gbit gekoppeld, maar moet nog testen hoe snel het nu is. De 2de PC is ook een beetje een oud gebakje die moet ik eigenlijk vervangen, maar voor testwerk nog wel OK.

Het schijnt veranderen de regeltjes in sommige applicaties (vb SMBv2/NFSv3/4) die bovenop UDP/TCP/IP lopen een beetje als het echt snel begint te gaan zeker als je hoopt van 1 bron naar een ander te kunnn gaan en die "volle" snelheid te benutten.

Dan nog alles rond "offloading" van CRC-checks etc die je systeem ook nog eens kunnen belasten etc.

Op een netwerk met veel clients & servers kan je die linken wel beter benutten dan van 1 IP naar een ander IP proberen te gaan een echt hoge snelheid te halen.

Wij hebben ondertussen ook wel 100Gbits/sec op wat interconnects tussen wat routertjes ;-) maar dat is natuurlijk een grote mix verkeer...

[jaco]

1sessie met mtu van 1500 via smb is inderdaad een bottleneck..

Als je de mtu naar 9K zet wordt het al beter en kun je wel een 10GE bijna volkrijgen heb ik op youtube gezien.

En het waarom ? Het scheelt wacht tijd. Copy met 200-300 MB/sec/sec is minder lang wachten dan met 100 MB/sec.

[riwi]

Het schijnt veranderen de regeltjes in sommige applicaties (vb SMBv2/NFSv3/4) die bovenop UDP/TCP/IP lopen een beetje als het echt snel begint te gaan zeker als je hoopt van 1 bron naar een ander te kunnn gaan en die "volle" snelheid te benutten.

Dan nog alles rond "offloading" van CRC-checks etc die je systeem ook nog eens kunnen belasten etc.

Op een netwerk met veel clients & servers kan je die linken wel beter benutten dan van 1 IP naar een ander IP proberen te gaan een echt hoge snelheid te halen.

Wij hebben ondertussen ook wel 100Gbits/sec op wat interconnects tussen wat routertjes ;-) maar dat is natuurlijk een grote mix verkeer...

SMBv3 is al veel efficienter dan v2. Eigenlijk even snel als NFS naar het schijnt. Maar vergt nog wel meer CPU. Dus inderdaad zal je met een 10Gbe link andere bottlenecks tegenkomen. Nu met 1x 1Gbe link zie ik gewoon een strakke lijn 110-115MB/sec ongeveer dus dan is de netwerk link wel duidelijk de bottleneck.
Ik zie in de ZFS iostat ook dat de schijven af en toe even wat moeten schrijven en dan weer 2 seconden wachten tot de Gbe link eindelijk weer wat data heeft aangeleverd

En mijn eerste Gbe switch (een 3com in 2002) kon ook niet echt de complete gbit snelheid aan. Dat zal met de huidige 10Gbe spullen ook wel weer gelden.

100Gbe zal nog wel een paar jaar duren voor we dat thuis gaan gebruiken

[Robert T]

Uitgaande van een volle backup en je daadwerkelijk 100TB moet transporteren, dan is tijd toch geen factor? Leuk als het sneller kan maar of dat een use case is.. tja, moet ieder voor zich weten.

Na een initiele backup zullen het toch alleen maar incremental backups zijn en dus een fractie van de data.

Desalniettemin zou ik ook wel 10Gbps/100Gbps tot m'n beschikking willen hebben maar dat is nog altijd gewoon hobby.

Da's simpel :
Je hebt 1 NAS server vol staan met  100 TB en wil een backup maken naar de tweede NAS. Dan is het via 10Gbe wel een stuk vlotter gedaan dan via 1Gbe.

Ik heb met 3 zpools in 1 PC ook al eens een pool 'leeg' gekopieerd (data naar de andere 2 pools) en dat gaat dan intern in de PC met 400-500MB/sec. Dat soort acties duren anders gewoon te lang. Ik heb mijn 2de PC via dual gbit gekoppeld, maar moet nog testen hoe snel het nu is. De 2de PC is ook een beetje een oud gebakje die moet ik eigenlijk vervangen, maar voor testwerk nog wel OK.

[Robert T]

Uhm. Je haalt het eea door elkaar hier.

Met applicatie protocollen als cifs ben je idd niet altijd beter af, zeker niet wanneer je latency introduceert maar daar heb je thuis geen last van natuurlijk. IP is het protocol, TCP of UDP is de transport laag. Met data transfer wil je eigenlijk geen UDP gebruiken als het betrouwbaar moet dus zit je aan TCP vast.

Thuis, weer uitgaande van 1 "fatsoenlijke" switch zal dit elkaar ook niet bijten. Een switch transporteert van poort naar poort op basis van laag 2, (MAC addressen). Een switch leert welke hosts op welke poorten zitten dus de data kan niet andere poort storen (misconfiguraties daargelaten)

Het schijnt veranderen de regeltjes in sommige applicaties (vb SMBv2/NFSv3/4) die bovenop UDP/TCP/IP lopen een beetje als het echt snel begint te gaan zeker als je hoopt van 1 bron naar een ander te kunnn gaan en die "volle" snelheid te benutten.

Dan nog alles rond "offloading" van CRC-checks etc die je systeem ook nog eens kunnen belasten etc.

Op een netwerk met veel clients & servers kan je die linken wel beter benutten dan van 1 IP naar een ander IP proberen te gaan een echt hoge snelheid te halen.

Wij hebben ondertussen ook wel 100Gbits/sec op wat interconnects tussen wat routertjes ;-) maar dat is natuurlijk een grote mix verkeer...

[Robert T]

netwerktechnisch zou het niet uit moeten maken, maar minder packets door grotere packets betekent minder overhead (elk packet heeft headers) en minder processing door de hosts en dus sneller.  Jumbo frames worden idd ook vaak toegepast op high bandwidth netwerken, evenals andere TCP tweaks.

1sessie met mtu van 1500 via smb is inderdaad een bottleneck..

Als je de mtu naar 9K zet wordt het al beter en kun je wel een 10GE bijna volkrijgen heb ik op youtube gezien.

En het waarom ? Het scheelt wacht tijd. Copy met 200-300 MB/sec/sec is minder lang wachten dan met 100 MB/sec.

[dennism]

SMBv3 is al veel efficienter dan v2. Eigenlijk even snel als NFS naar het schijnt. Maar vergt nog wel meer CPU. Dus inderdaad zal je met een 10Gbe link andere bottlenecks tegenkomen. Nu met 1x 1Gbe link zie ik gewoon een strakke lijn 110-115MB/sec ongeveer dus dan is de netwerk link wel duidelijk de bottleneck.
Ik zie in de ZFS iostat ook dat de schijven af en toe even wat moeten schrijven en dan weer 2 seconden wachten tot de Gbe link eindelijk weer wat data heeft aangeleverd

En mijn eerste Gbe switch (een 3com in 2002) kon ook niet echt de complete gbit snelheid aan. Dat zal met de huidige 10Gbe spullen ook wel weer gelden.

100Gbe zal nog wel een paar jaar duren voor we dat thuis gaan gebruiken

Dat valt best mee, 10GBe is allang geen cutting edge meer, met goede nic's, een goede switch en goede storage (met goede caching, of all flash), en niet te vergeten goede bekabeling is 10GBe goed te benutten.

[jaco]

Ik heb er vandaag weer een 10GE kaart gekocht voor weinig: €142 voor een intel x520da2 met 2x SR sfp+ optics. Die overkoop ik door voor €50 en dan kost de kaart dus €92

Komt aan een D-Link switch met 4 spf+ poorten die €351 was, dus het hoeft niet meer de hoofdprijs te kosten. Er moet dan wel een direct attach kabel van €60 tussen.

[riwi]

Uitgaande van een volle backup en je daadwerkelijk 100TB moet transporteren, dan is tijd toch geen factor? Leuk als het sneller kan maar of dat een use case is.. tja, moet ieder voor zich weten.

Even rekenen :
100TB via 100MB/sec = 10^6 seconden is 277 uur is 11 dagen
100TB via 1000MB/sec = 10^5 seconden is 27.7 uur is 1.1 dagen

En je mag aannemen dat tijdens deze "backup" de service wel geimpact is. Dwz geen film kijken

Bij mij komt het ong. 1x per jaar voor dat ik een pool wil leeg kopieren om iets met de schijven te herorganiseren. Dus inderdaad hobby Je vraagt een man met een Ducati toch ook niet waarom die motor zo snel moet zijn, en of het allemaal wel nodig is

[Kjelt]

Nu nog een NAS en HDD's die 1000MB/s aan kan, zijn die er al?

[jvanhambelgium]

Uhm. Je haalt het eea door elkaar hier.

Met applicatie protocollen als cifs ben je idd niet altijd beter af, zeker niet wanneer je latency introduceert maar daar heb je thuis geen last van natuurlijk. IP is het protocol, TCP of UDP is de transport laag. Met data transfer wil je eigenlijk geen UDP gebruiken als het betrouwbaar moet dus zit je aan TCP vast.

Thuis, weer uitgaande van 1 "fatsoenlijke" switch zal dit elkaar ook niet bijten. Een switch transporteert van poort naar poort op basis van laag 2, (MAC addressen). Een switch leert welke hosts op welke poorten zitten dus de data kan niet andere poort storen (misconfiguraties daargelaten)

En de doorvoer moet natuurlijk ook mee willen van de switch, blocking / non-blocking / sustained etc.
Er zijn genoeg switches met 1G/10G poorten die helemaal geen "sustained" 1/10Gbits effectief continue kunnen leveren
Verschillende switchpoortjes op dezelfde ASIC etc.Nu in een thuis-netwerkje hoeft dat niet zo direct een probleem te zijn...hobby...

Vanaf je 10Gbits begint te stressen komen inderdaad OS/kernel-tuning/tcp-tuning/firmware van NIC's zeer zeker terug in de picture om het goed te krijgen in een "real world" omgeving.
Bij ons worden de servertjes "standaard" met 4x10GBits (LACP) voorzien en daar komen we wel even mee toe voorlopig denk ik 

[jaco]

Nu nog een NAS en HDD's die 1000MB/s aan kan, zijn die er al?

Als ik in zfsguru test van raid-z2 met 10x4TB is het 1000MB/sec

Maar ja om dat nu over een 10GE nic naar een andere server te kopiëren is andere koek.

Ik denk maar een apart vlan te maken voor file copy tussen PC en NAS units, en een 1 GE poort of LAGG te nemen voor afspelen naar Dune units.
Dan kan de MTU op het copy vlan naar 9000, en dan kan de snelheid tussen NAS units omhoog.
Alleen is dat geen dagelijks werk..

Groot nadeel is dat ik dan een mapping naar een share moet maken voor copy, en een andere om met Yadis dezelfde share te indexeren.

[riwi]

Ik heb in het verleden wel MTU 9000, jumboframes gebruikt op de NAS, maar kwam er achter dat de mediaplayers daar niet tegen kunnen. Als je TCP doet dan volgt er wel een window size onderhandeling, maar als je UDP gebruikt zal de NAS gewoon MTU 9000 gebruiken terwijl de Dune er niet tegen kan. Bij mijn testen toen, hielp de hogere MTU niet voor betere kopieer snelheden dus ik ben weer naar de standaard MTU van 1500 gegaan.

[jaco]

Ach ik kan enkel voor een nas copy een re-config doen en daarna weer terug naar 1500

[dennism]

Ik zou trouwens geen wonderen verwachten van MTU 9000 of Jumbo frames. Op high end hardware zien wij vaak maar een verschil van +- 10% t.o.v. MTU 1500, en dat is dan binnen omgevingen die er gericht op gebouwd zijn om met MTU 9000 te werken. Afhankelijk van de inrichting van de omgeving kan het beter werken, maar het is zeker niet iets waar ik speciaal voor thuis hardware voor zou kopen en zelfs zakelijk zie ik eigenlijk alleen  MTU 9000 gebruik wanneer het een best practise / explicite aanbeveling is voor de gekozen soft/hardware oplossing.

Aparte Vlans of beter nog een apart storage netwerk zou ik in ieder geval wel aanraden als je er thuis mee aan de slag wil anders kan je rare zaken gaan zien op je netwerk en zelfs je netwerk performance negatief beinvloeden.

[Robert T]

dan zijn we het helemaal eens ja

Bij mij komt het ong. 1x per jaar voor dat ik een pool wil leeg kopieren om iets met de schijven te herorganiseren. Dus inderdaad hobby Je vraagt een man met een Ducati toch ook niet waarom die motor zo snel moet zijn, en of het allemaal wel nodig is

[Robert T]

Niet elke NIC ondersteunt jumbo frames, nee.

Vwb UDP/TCP is dat wel een beetje vreemd. Ja, de ontvanger adverteerd een TCP window size maar dat zegt niks over de grootte van de packets, dat zegt alleen maar wat over hoeveel data tergelijkertijd onderweg kan zijn zonder acknowledgement van ontvanging. Uitgaande van standaard TCP (RFC793) is het TCPwindow size veld 16 bits groot dus 2^16 = 64KB / 1500bytes = grofweg 40 packets maar met jumbo frames is dat 7 packets. Het zal wel iets met de TCP MSS te maken hebben.

Ik heb in het verleden wel MTU 9000, jumboframes gebruikt op de NAS, maar kwam er achter dat de mediaplayers daar niet tegen kunnen. Als je TCP doet dan volgt er wel een window size onderhandeling, maar als je UDP gebruikt zal de NAS gewoon MTU 9000 gebruiken terwijl de Dune er niet tegen kan. Bij mijn testen toen, hielp de hogere MTU niet voor betere kopieer snelheden dus ik ben weer naar de standaard MTU van 1500 gegaan.

[jaco]

Ik heb nu veel getest met NFS tussen 2 servers met freebsd os.
Met mtu 1500 blijft het op 100 mbps steken. Met mtu 9000 kom ik tot 150 MB/sec.
Het gaat over Intel x520-ad2 kaarten via een D-Link switch.

Vanaf de PC kan ik een copy maken via smb van 300-340 MB/sec.
Als ik dan het terug copy krijg ik ook maar 100-150 Mb/sec.

Het zal dus liggen aan de oplevering van de data van de server. Met test van freebsd is dat tussen 900-1000 MB/sec van de pool.

Als ik met iperf test, dan haal ik met 1 sessie 400 MB/sec als ik de packet size wat verhoog tussen pc en server.

[riwi]

Vanaf de PC kan ik een copy maken via smb van 300-340 MB/sec.
Als ik dan het terug copy krijg ik ook maar 100-150 Mb/sec.

Interessant. Wat ik heb gemerkt is dat het ook veel scheelt aan welke kant je het commando geeft.
Dus lezen van lokale PC en schrijven naar NFS bestemming is trager dan lezen van NFS en lokaal schrijven. Dat komt omdat het schrijven via NFS veel meer CPU kost. Dus met een dikke CPU zal het niet uitmaken verwacht ik.

Ik heb met mijn 2 ZFSonLinux PCs vorige week getest met dual Gbit met bonding in balance-rr mode. Heb de tips van louwrentius doorgelezen, maar kreeg het op die manier niet werkend (vlan definities in de switch). Als ik een LAG op de switch definieer voor de beide poorten van de server kreeg ik de doorvoer niet boven de 115MB/sec. Als ik 2 losse poorten in de switch neem per PC en flowcontrol aanzet dan zie ik 170-180MB/sec. Maar het gaat wel met horten en stoten want de oude core2duo PC kan het niet aan (4GB geheugen is voor ZFS ook echt te weinig). Ik zag ook dat de grote NAS eerst z'n 24GB geheugen vol pompt en dan pas via de 2xGbit de data overpompt. Dus initieel zie je 500MB/sec en dan zakt het naar 170MB/sec of lager omdat de oude PC staat te hikken.

[jaco]

Bede servers zijn Xeon 1220 (v1/v3) met 32 GB ram.CPU staat niets te doen, of niet veel.

Het is voor mij de onbekendheid met FreeBSD en NFS om te snappen waarom er dingen gebeuren.
NFS zou sneller zijn dan samba, maar van mijn bejaarde i7-920 gaat er tot 450 MB/sec naar zo'n server toe (van ramdisk)
Testen op file systeem geven 900-1000Mb/sec. Dat zijn dan wel interne testen, dus wat er getest wordt is me niet duidelijk, zla wel buiten ZFS omgaan.

Ik heb met iperf getest, als ik dan de buffer wat opschroef met de packet size, dan gaat er 400 MB/sec door 1 sessie. Met 3 sessies is de 10GE link vol.
Dus de I/O over de NIC lijkt goed te zijn na tuning van de buffers.

NFS gaat niet echt snel. Je hebt rsize en wsize parameters, en dat is standaard 8kb, die heb ik al op 32 en 256 gehad. Dan zie je de snelheid toenemen, maar niet over de 150 MB/sec.

Nu worden er weer dingen als zfs prefetch en weet ik wat gesuggereerd.

[jvanhambelgium]

Ach, met m'n eigen Linux servertje beneden in de kast klaag ik niet.
Ik maar 1Gbits liggen in huis, dus véél meer als hieronder gaat het niet worden ;-)
Geen fancy RAID-controllers etc, erg kleinschalig.

[riwi]

Op de gigabit naar mijn low power atom servertje haal ik ook de gbit wel vol met SMB van windows7 naar de kleine linux PC.

@Jaco : Als je intern in de PC van de ene pool naar de andere gaat dan haal je toch wel hogere snelheden? Dan zou ik denken dat het niet door ZFS wordt gelimiteerd.

Ik heb bij mij ook wel dat wegschrijven van windows naar ZFS met 115MB/sec gaat en lezen soms wat langzamer. 90MB/sec of zo.
En dat heb ik ook naar/van de atom PC die ext4 heeft (geen zfs) en een enkele SSD. Ik denk soms dat het de windows kant is die niet sneller wil lezen.

Van windows naar ZFS raidz2 (10x4TB) :



En terug lezen van dezelfde 33GB file :