Hoi,
Ik heb me eens geamuseerd met benchmarks om te kijken welk protocol het snelst is voor een NAS voor thuisgebruik.
De NAS in kwestie is een zelfbouw op basis van een Debian server (zonder GUI) en een 6x 2 TB RAID-5 in JFS geformatteerd en in zijn geheel gedeeld voor Windows clients (SMB), voor NFS (v4/3/2) en voor SSHFS.
Alleen die laatste ondersteunt standaard encryptie en tunneling over ssh, wat dus voor een ingebouwde vertraging zorgt maar wel veel veliger is. Bovendien kan sshfs ook veilig over het internet heen gebruikt worden. Daar kan Windows nog een puntje aan zuigen!
Als client heb ik getest met een Ubuntu 10.04.3 'Lucid Lynx' LTS en als benchmarksofware heb ik bonnie++ gebruikt.
De resultaten:
1. Het traagst: SMB tijdens het schrijven, sshfs tijdens het lezen
2. Middelmoot: SMB tijdens het lezen, sshfs tijdens het schrijven
3. Het snelst (met voorsprong!): NFS!
Conclusie: je gebruikt best NFS om met een Linux of Mac desktop te werken met een NAS. Windows kan zelf alleen SMB gebruiken. SSHFS is voornamelijk interessant als veilige oplossing om over het internet heen met een fileserver te kunnen werken alsof hij een lokale NAS was.
Als je NFS v4 kunt gebruiken, doe dat dan. Alle moderne Linux'en ondersteunen dat. Anders NFS v3 en pas als laatste NFS v2.
1. Server of NAS:
Voor het geval je die nog zelf moet installeren, heb je het pakket nfs-kernel-server nodig. Mocht die nog niet geïnstalleerd zijn dan kun je dat (bij Debian-achtigen waaronder ook Ubuntu) doen met behulp van:
sudo aptitude -y install nfs-kernel-server
(Als je hier een foutmelding krijgt dat aptitude niet gevonden kan worden, gebruik dan apt-get overal waar ik hier aptitude schrijf. Je kunt aptitude ook installeren op systemen waar dat niet aanwezig is via sudo apt-get install aptitude.
Daarna neem je alle shares op in een tekstbestand /etc/exports. Bijvoorbeeld:
/data/pub 10.0.0.0/24(rw,async,no_subtree_check,no_root_squash)
Hierbij is /data/pub wat ik over het netwerk wil delen. Dat mag aan heel mijn interne netwerk (10.0.0.0-adressen, de /24 wil zeggen een netmasker van 255.255.255.0) en elke netwerkgebruiker die toegang wil moet als user aangemaakt zijn op de server of NAS, dan heb je geen rechtenproblemen.
De opties uitgelegd:
rw: dit volume is voor lezen en schrijven
async: lieg clients voor dat I/O-opdrachten succesvol afgewerkt zijn zodra de opdracht ontvangen wordt, ook al is die dan nog niet uitgevoerd. Dit mag je alleen doen als je een ZEER BETROUWBARE server of NAS hebt. Dat wil zeggen een stabiel OS en voorzien van een noodvoeding (UPS). Zoniet zou data gecorrumpeerd kunnen raken als de netwerkverbinding verbroken wordt terwijl I/O-opdrachten nog niet uitgevoerd zijn. Bij een minder betrouwbare server gebruik je best sync in plaats van async. Bij sync wordt gewacht tot een einde van een I/O-opdracht en het echte resultaat dan meegedeeld aan de client. Die moet dan dus daarop wachten.
no_subtree_check: voor elk bestand wordt de hele subtree waarin zich dat bevindt iedere keer weer gecontroleerd, wat nodeloos tijdverkwistend is en daarom kun je deze optie weergeven. Dit doe je beter niet bij een snel veranderende NAS met veel gebruikers.
no_root_squash: omdat de root op een clientpc niet noodzakelijk dezelfde is als die op de server, wordt alle toegang voor de gebruiker root normaal door de server omgezet naar een anonieme gebruiker. Daardoor werken rootopdrachten niet zoals je verwacht als je wél de root bent van zowel de clientpc als de server. Dan kun je deze opdracht opgeven om de root behoorlijk te laten werken.
2. Clientpc (alleen Linux of Unix, Windows ondersteunt dit niet):
Aan de clientkant heb je het pakket nfs-common nodig. Normaal zou je verwachten dat elke Linux dit standaard al aan boord heeft, maar mijn Ubuntu 10.04.3 LTS had het dus niet geïnstalleerd. Dan doe je dit:
sudo aptitude -y install nfs-common
Nu kun je de netwerkshare toevoegen in /etc/fstab:
10.0.0.251:/data/pub /media/MijnNAS nfs4 rw,hard,intr,async,actimeo=0,nodev,nosuid 0 0
waarbij 10.0.0.251 het ip-adres van de NAS of server in mijn eigen netwerk is. Dat moet je natuurlijk vervangen door die van jou.
En /media/MijnNAS is het koppelpunt dat ik aangemaakt heb. Ook hier vul je weer je eigen voorkeur in.
Dan de opties:
nfs4: we geven aan dat we met nfs4 willen werken. Merk op dat geen blocksizes gedefinieerd zijn. NFS4 bepaalt die zelf in een onderhandeling tussen client en server en dat kan dus veel groter zijn dan bij NFS3 (tot 32 soms 64 KB) of NFS2 (tot 8KB). In mijn geval (Gigabit Ethernet netwerk) kozen client en server een blocksize van 1 GB! Bij Linux-systemen die geen nfs4 als filetype ondersteunen kun je nfs opgeven en dan nfsver=4 in de opties daarachter. Werk je met een ouder Linux-systeem dat geen nfs4 ondersteunt, dan kun je natuurlijk ook met nfs3 werken. Ook dan kunnen client en server zelf een blokgrootte onderhandelen. Bij nfs2 moet je het echter zelf opgeven.
rw: we gebruiken een volume voor lezen en schrijven.
hard: gebruik hardlinks in plaats van softlinks. Dat is veiliger (softlinks staan er bekend voor dat ze bij NFS nogal eens geleid hebben tot datacorruptie). Het nadeel is dat als de server offline gaat, de client tot in alle eeuwigheid wacht op die server en dus muurvast zit. Dat lossen we op via:
intr: de onderbreekbaar-vlag zorgt ervoor dat als de server niet meer reageert, de client zelf de verbinding kan afbreken.
async: zie hoger bij de server. Je moet aan beide kanten hetzelfde definiëren: alletwee async of alletwee sync. Sync is veiliger, maar trager. Async is sneller maar de ingebakken onveiligheid hoeft geen probleem te zijn als de NAS of server stabiel is en een noodvoeding heeft.
actimeo=0: dit zet een hele batterij attribuutcachetijden op 0. Normaal worden attributen gecacht en dat kan dus tot een minuut lang zijn. Als bij een NAS de bestanden snel veranderen, dan wil je dit niet. Zeker bij een NAS die gebruikt wordt om multimediabestanden naar een of meer streamers te sturen, krijg je allerlei ongewenste effecten als die attributen te lang gecacht worden. Moderne computers zijn snel genoeg en dus vond ik het wel kunnen om de attributencaches gewoon uit te schakelen.
nodev en nosuid: beveiligingen om aan te geven dat het volume zeker geen block-devices bevat en ook geen dingen die als "hogere user" (meestal root) uitgevoerd moeten worden.