/ Forside / Teknologi / Operativsystemer / Linux / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Linux
#NavnPoint
o.v.n. 11177
peque 7911
dk 4814
e.c 2359
Uranus 1334
emesen 1334
stone47 1307
linuxrules 1214
Octon 1100
10  BjarneD 875
Netværksfilsystem
Fra : Jacob Larsen


Dato : 10-10-10 01:50

Hej

Det skulle egentlig have været et spørgsmål, men nu kan jeg da give en
opsummering af hvad jeg har fundet ud af i stedet, siden jeg ikke
rigtigt kunne finde noget eksisterende info om emnet.

Jeg har været ved at undersøge diverse måder at mounte min Linux NAS
på min Linux client. Jeg er startet ud med et eksisterende setup med
Samba mounted via fstab på CIFS, så det har været min reference.

Samba:
----------------------------------------------------------------------
Pro:
- God roaming ved skift mellem interfaces på client (WiFi vs. wired)
- Serveren skal under alle omstændigheder sættes op pga. Windows
client

Con:
- Forholdsvis langsom på client siden, da smbfs driveren ikke udnytter
de helt store pakkestørrelser der er mulige i SMB.
-- Hvis man sammenligner med smbclient, så har smbclient ikke det
problem, men smbclient er ikke et mount.
-- Nautilus SMB support er ikke brugbar, siden det ikke er en rigtig
mount.
-- smbnetfs dur ikke, siden man ikke kan lave 1:1 mapping mellem mount
points, hvilket umuliggør understøttelse af trash, samt giver forkert
svar på free disk space.
- Problematisk ved shutdown pga. problematikken med netværk der er
lukket ned før unmount. Basal bug der har eksisteret i evigheder,
selvom Ubuntu dog har forbedret det. Nu er det kun hvis man bruger
WiFi at man har problemet.
----------------------------------------------------------------------

SSHFS:
----------------------------------------------------------------------
Pro:
- Simpel at sætte op, så længe keys allerede er sat op til SSH.
- Kryptering giver mulighed for mount over Internet.
- En anelse hurtigere end SMB med de CPU'er jeg sidder med pt.
- Mount 1:1 for support for Trash og filsystem størrelse.

Con:
- Høj CPU utilization pga. kryptering, hvilket udgør flaskehals for
throughput.
- Ingen support for roaming ved skift mellem interfaces (WiFi vs.
wired). Sandsynligvis pga. SSH security.
-- Er faktisk rigtig slem i forbindelse med at netværkskablet tages ud
mens den er mounted, kan låse alle mulige processer pga. manglende
svar fra SSHFS mount point. Tilsyneladende mangler der timeout et sted
der.
------------------------------------------------------------------------

NFSv4:
------------------------------------------------------------------------
Pro:
- Højt throughput, er den eneste af de testede, der kommer i nærheden
af 100MB/s over Gigabit Ethernet (bambus switch).
- Mount 1:1 for support for Trash og filsystem størrelse.
- Latency virker lavere end de andre testede (subjektivt)
- Fungerende roaming ved skift mellem interfaces på client (WiFi vs.
wired)

Con:
- Kræver specielt bind mount setup på serveren, hvilket sætter nogle
restriktioner i setuppet.
- Skift mellem interfaces tager længere tid at reconnecte end Samba.
-------------------------------------------------------------------------

På throughput siden har jeg målt omkring 20-25MB/s på mounted Samba,
mens jeg har målt 30-35MB/s på SSHFS, og 95-105MB/s over NFSv4.
Begrænsede Samba klienter som smbclient kunne komme op omkring 95MB/s,
så mounted Samba må være begrænset på klient siden.

Efter alt det er det endt med at jeg er skiftet til at mounte mine
linux klienter med NFS, mens Windows stadig bruger SMB.

NFSv4 er relativt simpel at sætte op, men jeg kan da lige give et par
tips (Virker for Ubuntu 10.04).
Server:
- installer nfs-kernel-server pakken.
- Sæt NEED_IDMAPD=yes i /etc/default/nfs-common
- Lav et directory til NFS root. F.eks. /srv/nfs4
-- Lav subdirectories som placeholders for shares på serveren.
- Ret /etc/fstab og tilføj bind mount for dine shares fra deres
rigtige placering til tilsvarende subdirectory under /srv/nfs4
- Ret /etc/exports og tilføj entries for shares.
- Start idmapd servicen
- Start nfs-kernel-server servicen
- Åbn TCP port 2049 for indkommende forbindelser fra det lokale
netværk i serverens firewall

Client:
- installer nfs-common pakken.
- Sæt NEED_IDMAPD=yes i /etc/default/nfs-common
- Start idmapd servicen
- Indsæt mounts for shares i /etc/fstab
- Det er en fordel at mounte shares hver for sig i fstab, siden det
giver mulighed for 1:1 mount af serverens filsystem.

Sørg for at usernames, UID, GID for brugerne matcher mellem server og
clients, ellers kan det give problemer med at permissions ikke matcher
set fra client.

Der er lidt mere info om at sætte NFSv4 op her:
http://www.brennan.id.au/19-Network_File_System.html#nfs4

/Jacob

 
 
Martin Larsen (10-10-2010)
Kommentar
Fra : Martin Larsen


Dato : 10-10-10 11:25

Jacob Larsen wrote:

> Det skulle egentlig have været et spørgsmål, men nu kan jeg da give en
> opsummering af hvad jeg har fundet ud af i stedet, siden jeg ikke
> rigtigt kunne finde noget eksisterende info om emnet.

Tak for info. Vil gemme indlægget da jeg selv står i en lignende
problemstilling.

Henning (11-10-2010)
Kommentar
Fra : Henning


Dato : 11-10-10 14:36

On 2010-10-10 09:50, Jacob Larsen wrote:
> Hej
>
> Det skulle egentlig have været et spørgsmål, men nu kan jeg da give en
> opsummering af hvad jeg har fundet ud af i stedet, siden jeg ikke
> rigtigt kunne finde noget eksisterende info om emnet.

<cut en masse godt>

> - Ingen support for roaming ved skift mellem interfaces (WiFi vs.
> wired). Sandsynligvis pga. SSH security.
> -- Er faktisk rigtig slem i forbindelse med at netværkskablet tages ud
> mens den er mounted, kan låse alle mulige processer pga. manglende
> svar fra SSHFS mount point. Tilsyneladende mangler der timeout et sted
> der.


Roaming problem kan relativt simpelt klares ved at køre via vpn.

Bruger selv openvpn i stor stil, men et simplet setup med preshared keys
(hvos det kun er mellem to enheder) er meget let at sætte op med openvpn.

Man sætter bare server-parameteren på klienten op til at forsøge
prioriteret sådan

1) serveren på lan-adressen (192.168.1.x typisk)
2) via wan-adressen (som forwardes til serveren i routeren)

Det virker fint med masser af ssh-connections selvom jeg løbende skifter
mellem forkellig kabel-, wifi- og mobil-bredbånds-forbindelser.

Op hvis du vælger at connecte via ssh/sshfs er der ikke den store behov
for at kryptere vpn-tunnelen

/Henning

Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408919
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste