NAS med FreeBSD/ZFS

Jag har ny migrerat färdigt min datapool och har nu mina 10 TB lagringsutrymme (eller nja det blev väl ungefär 9 TB om man räknar med 1TB=1024*1024*1024*1024). Har även lagt in samba och får ca 60 MB/s med Windows 7 som klient. Lite svårt att jämföra prestandan med opensolaris eftersom jag nu inte har samma hårdvara (har ju flera hårddiskar och flera kontrollerkort varav ett körandes på PCI) men där fick jag ändå 90 MB/s. Är väl ganska nöjd med hastigheten men skulle nog vilja ha lite bättre. Men jag har knappt tweakat något ännu.

Ett problem jag fick var att datorn startade om sig varje natt klockan 3 och på lördagmorgnar även klockan 4:15. Tog bort security checks i periodic daily och någon annan grej i periodic weekly som accessade hårddiskarna mycket så löste det sig tillfälligt. Men sedan när jag började hårdtesta samba så fick jag kernel panic. Har nu lagt in följande tweak i boot/loader.conf:
vfs.zfs.arc_max=”2048M”
Detta verkade göra susen när det gäller stabiliteten och den startar inte om sig längre.
Frågan är dock varför jag var tvungen att göra detta, och hur vet man hur man tweakar optimalt?
ZFS ska ju inte behöva tweakas med amd64 och >2GB RAM (jag har 4GB).
Man vill ju gärna utnyttja minnet optimalt utan att äventyra stabiliteten.
Lite konstigt att kärnan och ZFS inte riktigt verkar veta om varandras minnesanvändning och man alltså måste tweaka så att de inte krockar med varandra (känns i alla fall som att det är så)... Kärnan ska väl inte få panik bara för att RAM-minnet används? Jag har ju ändå 8GB swap-utrymme så det borde väl räcka rätt långt. Visserligen testar jag överföra filer på 30GB och mera via samba för att stressa filservern litegrann men jag använder sådana filer ibland när jag redigerar video.

Nu har jag tweakat litegrann och får ca 79 MB/s läshastighet från filservern till dator med Windows 7 och ca 90 MB/s skrivhastighet till filservern när jag överför filer med samba.

Det som verkligen gjorde susen är följande i /boot/loader.conf
vfs.zfs.prefetch_disable=0
vm.kmem_size="8G"
vfs.zfs.arc_max=”2048M”

Dessutom har jag ändrat tillbaka socket options i smb.conf till:
socket options = TCP_NODELAY

Jag tror detta är default i smb.conf och det verkar vara en vettig inställning alltså. I och för sig blev det knappt någon skillnad om jag kommenterade bort hela raden med socket options heller (fortfarande 79 MB/s läs och 90 MB/s skriv).
Har även kompilerat samba med aio support och har detta i smb.conf:
aio read size = 16384
aio write size = 16384

Går säkert att tweaka mera men om allting funkar stabilt nu så är jag nöjd med hastigheterna.
Det är väl ungefär i nivå med vad jag hade i opensolaris, kanske något sämre läshastighet. Men med tanke på att några hårddiskar sitter på PCI-kontroller så borde det sänka farten något (dock så används sällan mer än en disk i taget från PCI-kontrollern). Antar att flaskhalsen sitter mer i ZFS tillsammans med nätverkskortet.

EDIT: Detta verkar göra susen för skrivhastigheten:
vfs.zfs.txg.write_limit_override=524288000
Skriver nu med ca 96 MB/s via samba till filservern (tror läshastigheten för lokala hårddisken i klienten stoppar)... Källa: ZFS Write Speed Very Inconsistent - The FreeBSD Forums

Det kan gå väldrigt snabbt så länge man skriver till filcachen på filservern (alltså tills RAM-minnet är fullt).
Testa en riktigt stor fil (typ 20 GB) så kan det sjunka litegrann efter en stund. Men du kanske har hittat någon optimal uthållig inställning. Dessutom gäller det ju att ha snabb intern håddisk i klientdatorn man testar från (annars har man ju en flaskhals vid läsning av hårddisken man kopierar ifrån). Sitter man med SSD-disk så är väl inte det något problem, själv har jag tyvärr ingen SSD ännu.

Teoretiskt max för gigabit är ca 119 MB/s om man räknar 1 MB = 1024*1024 byte.
Jag får testa NFS också. Jag fick bara 25 MB/s mot min ubuntumaskin med CIFS. Mot Windows7 går det i 78 - 96 MB/s. Hur har du tweakat NFS förresten?

Om du skaffat SSD så kan du avsätta en partition för ZFS L2ARC så får du kanonbra accesstider på småfiler som cacheas på SSD när du läser från din zpool. Nackdelen är att det äter upp en del RAM-minne att ha L2ARC så det kanske inte är lönt om man inte har mer än 4GB RAM.

Så här får jag när jag testar med dd:

[root@filserver ~]# dd if=/dev/zero of=/tank/video/test/test.000 bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes transferred in 75.542510 secs (138806084 bytes/sec)

Sedan omstart av filservern för att tömma eventuell filcache i RAM och:

[root@filserver ~]# dd if=/tank/video/test/test.000 of=/dev/null bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes transferred in 26.992897 secs (388463676 bytes/sec)
[root@filserver ~]#

Jag har finslipat mitt tidigare tweak i /etc/sysctl.conf till:
vfs.zfs.txg.write_limit_override=671088640

Man kan finjustera värdet på denna för att maximera hastigheten på gigabitnätverket och då hamnar man väl på ca 120 MB/s i skrivhastighet till sin zpool med dd-testen ovan (det går som snabbast när skrivning till disk går ungefär lika snabbt som gigabitnätverkets filöverföringshastighet). Men man kan också tweaka värdet för att maximera hastigheten internt när man kör dd-testet enligt ovan (och då kan jag väl maxa uppåt 200 MB/s om jag minns rätt). Ökar man värdet för mycket så börjar hastigheten på gigabitnätet sjunka men man får ju snabbare skrivning när raiden jobbar internt. Så jag labbade lite för att hitta någon kompromiss som inte segade ner gigabitnätet alltför mycket men samtidigt heller inte segar ner skrivning till raiden internt alltför mycket. Har väl inte hittat optimala ännu men då jag prioriterar nätverkshasigheten stannade jag någonstans innan hastigheten började gå ner på grund av för högt värde på vfs.zfs.txg.write_limit_override. Så denna tweak bromsar alltså skrivhastigheten för att undvika det ojämna flödet när data skrivs stötvis till hårddiskarna och jämnast dataflöde får man ju när hårddiskar och nätverk går lika snabbt.

Jag köpte 4 stycken Samsung EcoGreen F3 HD203WI 32MB 2TB och en Samsung EcoGreen F2 HD154UI 32MB 1.5TB. Sedan tidigare har jag fem stycken Western Digital Caviar Green WD10EACS 16MB 1TB som jag återanvände. Jag har inte haft några problem med HD203WI diskarna ännu (dessa har inte heller 4k sektorer) men de verkar vara på utgående och svåra att få tag på numera (jag hade nog tur och köpte innan de började ta slut).

Jag skulle nog avvakta med att köpa 4k hårddisk för ZFS eftersom många verkar ha problem med western digitals 4k-diskar. Det bör snart visa sig hur dessa samsung F4 funkar med ZFS. Verkar som de flesta nya stora hårddiskar är 4k-diskar så frågan är om någon eventuell ny spinpoint kanske också blir 4k? Problemet med dagens 4k-diskar är att de luras och inte talar om för operativsystemet att de verkligen är 4k-diskar utan påstår att de är 512-diskar. Om de inte hade lurats så hade de funkat utmärkt.

Många verkar rekommendera Hitachi 2TB-diskar som ska funka bra med ZFS. Western digital black 2TB ska nog funka bra också men de är ju halvdyra. Själv hade jag Seagate barracuda LP som ett alternativ när jag letade hårddiskar. Det finns ett eventuellt firmwareproblem med dessa men jag har läst att de funkar bra med ZFS (de har 512 byte sektorer).
Seagate Barracuda - Wikipedia, the free encyclopedia
Men man kan ju se till att lägga in senaste firmware så ska väl Barracuda LP funka bra. De är också ganska strömsnåla och billiga.

Här är några alternativ:
Produktjämförelse hos Prisjakt

Utifrån dina önskemål att inte ha en "green" och att det ska vara prisvärt så verkar väl Hitachi vara ett vettigt val. Själv hade jag nog valt Seagate Barracuda LP om det inte längre går att köpa samsung HD203WI då jag gärna vill ha det strömsnålt. Samsung F4 är "undvik" p.g.a. 4k sektorer...

Enligt detta har Barracuda LP ingen ingen 4k emulering, men möjligen ett firmwareproblem:
The FreeBSD Forums - View Single Post - [Solved] Recommended HDD for ZFS homeserver
Nästa post hävdar att de funkar utmärkt.

Det är inga problem att streama bluray, det är sekventiell läsning och med ganska låg hastighet dessutom. Jag som endast har green-diskar får uppåt 95 MB/s sekventiell läs och skrivhastighet över gigabitnätverk och bluray är typ max 5 MB/s. Torrents kör jag inte mot raidz2-arrayen. När jag kör nerladdningar så gör jag det mot systemdisken och kopierar sedan över filen till lagringsarrayen när den laddat färdigt.

The_Slain_Man: Det bästa är om du kan installera alla hårddiskar samtidigt. Annars kan du i och för sig börja med en raidz1 på 4 diskar och sen lägga till en raidz1 på 4 diskar till i din pool. Men raidz2 på 8 diskar är ett säkrare alternativ.

Alla: Själv har jag köpt en ny switch, en D-Link Prosafe GS108Tv2. Switchen verkar ha stöd för IEEE 802.3ad LACP. Alltså link aggregation. Kom att tänka på att jag förutom mitt intel pro 1000pt PCIe nätverkskort i servern även har moderkortets inbyggda realtek nätverkskort. Eftersom jag fortfarande har en port ledig på min nya switch funderar jag på att koppla två nätverkskablar till min server och på så sätt få redundans och bättre bandbredd mellan switchen och servern om jag kan få servern att ansluta med 802.3ad LACP.

Om jag fattat rätt finns det något som heter lagg som stödjer detta i freebsd. Funkar detta även om man har två olika sorters nätverkskort, realtek och intel som i mitt fall? Fördelen skulle vara om två klientdatorer samtidigt kör filöverföringar via gigabitnätverket så skulle bandbredden fördelas i de två kablarna (load balancing) och man skulle slippa flaskhalsen mellan servern och switchen. En annan fördel är redundans så att om ena nätverkkortet eller nätverkskabeln krånglar så växlar den automatiskt över till den andra kabeln mellan switchen och servern. Jag skulle i och för sig även kunna ansluta min desktop med två sladdar på samma sätt och få det att funka snabbare om jag överförde från två hårddiskar samtidigt till servern men tyvärr går inte det när jag kör Windows på desktopdatorn (funkar bara med vissa identiska nätverkskort eller typ intels serverkort med två anslutningar). Men det kanske kan fungera med olika nätverkskort i Linux på desktopdatorn?

En annan grej man skulle kunna använda lagg till är om man kör trådlöst nätverk så kan man få den att atuomatiskt växla mellan kabel och trådlöst (bra på en bärbar dator om den kör freebsd). Kan ju också användas som redundans på servern så att den växlar till trådlöst om t.ex. switchen skulle gå sönder. Jag har några trådlösa PCI-kort liggandes så här skulle jag ju kunna få användning av ett sådant. Nu är det väl inte så jättekritiskt med redundant nätverk hemma men det är roligt att labba med.

Såg också att nya switchen stödjer VLAN. Man kan alltså separera olika virtuella nätverk. Kanske kan vara bra säkerhetsmässigt? Så om jag t.ex. vill ha en webbserver så kan man separera den till ett jail i FreeBSD och sedan ansluta den med ett VLAN via switchen till routern och om jag byter firmware i min Linksys WRT54GL till DD-WRT eller något sådant kanske få en egen separat länk ut mot internet som isoleras från mitt övriga nätverk? Är det så man ska tänka? Har inte riktigt förstått det är med VLAN innan. Behöver man dessutom sätta upp någon brandvägg internt mellan jailet i FreeBSD och övriga nätverket för att förhindra åtkomst via localhost? Eller är det separerat från början när man skapar ett jail?

Funderar också på det här med jumbo frames. Bör man isolera gigabitnätverket via t.ex. VLAN så att man kan använda jumboframes eller brukar det gå bra att mixa nätverk med enheter som inte kör jumbo frames? Om jag fattat rätt kan man få problem med UDP om man mixar medan TCP bör anpassa sig automatiskt. Kanske finns någon bra sida på nätet man kan lära sig om nätverksuppbyggnad?

Lagg har stöd för LACP så ska inte vara några problem där, har blandat nätverkskort tidigare men inte med LACP, utan roundrobin istället.

Jag fick igång lagg med LACP utan problem häromkvällen. FreeBSD var enkelt att konfigurera. Däremot var min switch lite svårare på grund av ologiskt användargränssnitt (Netgear GS 108T v2) men det gick bra till slut.
För FreeBSD följde jag denna guide: FreeBSD: NIC Bonding / Link Aggregation / Trunking / Link Failover Tutorial

Funkar bra trots att ena gränssnittet re0 är realtek och det andra em0 är intel nätverkskort. Jag kan rycka ut en av de två kablarna mellan switchen och servern och få trafiken att fortsätta på den andra kabeln utan att filöverföringen avbryts. Jag har ännu inte testat att köra parallella överföringar från flera datorer samtidigt mot servern, det är där man kan få bättre prestanda när båda kablarna arbetar parallellt mellan switchen och servern. Egentligen känns LACP lite som en smått onödig funktion i hemmanätverket men då jag kunde göra det och hade utrustning som klarade det så gjorde jag det.

Dock har jag märkt att det tar lång tid att stänga av FreeBSD-servern, precis som att det är något som hänger sig tills timeout sker under nedstägningsproceduren. Kanske är något nedstängningsscript som behöver modifieras för att stänga ner lagg innan nätverkskorten stängs ner?

En annan grej är att jag inte riktigt kan styra vilket nätverkskort som har högst prioritet. Intelkortet presterar en aning bättre men ibland väljs realtek trots att intel inte är belastat. Har i switchen satt högre prioritetsvärde på porten som går till intelkortet (jag satte värde 192 istället för 128). Men man kan också välja mellan LACP och static i switchens inställningar, vet dock inte skillnaden riktigt. Antar att det är i switchen man får ändra prioriteten eller kanske det är möjligt att justera prioritet i FreeBSD-servern också?

I och för sig är skillnaden i hastighet mellan realtek och intel inte så stor. Får ca 76 MB/s på intel och 70 MB/s från realtek vid nerladdning från servern med samba och ungefär samma hastighet 93 - 96 MB/s vid uppladdning. Men det känns som servern får jobba hårdare med realtek nätverkskort, processorfläkten låter mera. Antagligen avlastar intelkortet processorn en aning. Så helst vill jag köra intel som default och att realtek får hjälpa till när det behövs. Går det?

Funkar samba nu med nya kärnan?