optimisation de serveur NFS

Eric Belhomme a écrit :

Philippe Weill a écrit :

quel type de switch

il en existe avec des firmwares bien pourri

C'est un Dell pc5448, configuré comme ceci :

interface range ethernet g41-44
no switchport mode
channel-group 2 mode auto
interface port-channel 2
switchport mode access
switchport access vlan 9


Je graphe avec snmp mon bond0 sur le serveur et le ch2 sur le switch, et
mes 2 courbes sont cohérentes

j'ai quand meme un probleme avec les 65 K octet/ s

cela fait 232 Mo/ heure donc on est tres loin du 1 tera en 5 heure

si les 65 Ko sont dans tes graphes via snmp

a tu utilisé les compteurs 64 bits ?

pour moi 1,1 Tera octet en 5 Heure c'est plutot environ 60 Mo/s

et la du nfs sous linux en sync c'est pas du tout anormal

eventuellement faire un iostat sur le serveur pendant l'écriture

pour les perf locales cela donne quoi le systeme de fichier

hem... en fait j'ai pas testé :))

il me semble que c'est la base ;-)

On n'a _aucune_ information. La machine en question tourne avec
knfsd (c'est bien, c'est mieux que unfs ou userland-nfsd).

Que veux-tu savoir exactement ?

Je commencerais à mettre un NFSv3/TCP (pas de v4, parce que ce truc
est actuellement inutilisable sous Linux) avec des paquets de 32 Ko.

Je n'ai pas précisé TCP dans l'automonteur... Il me semble que depuis
nfs v3 TCP est utilisé par défaut non ?
Pour ce qui est du V3, est-ce qu'il y a moyen de préciser à nfs de ne
faire que du V3 et rien d'autre ?

J'espère que le mode async est activé (parce que sinon ça risque de
ramouiller très fort). Je ne suis vraiment pas sûr que le fait de passer
à 128 threads soit une excellente idée surtout dans le cas d'un daemon
UDP (ça pourrait se justifier en TCP, et encore). Bref :
- 8 threads pour commencer
- mode async pour tout le monde
- NFSv3

oups :

rico@filer1:~$ cat /etc/exports
/data/fae *(rw,sync,no_subtree_check)

coté automonteur, j'ai fais dans la simplicité :

[rico@kapa4 ~]$ mount | grep filer1
filer1:/data/fae on /auto/filer1_fae type nfs (rw,addr=x.x.x.x)

rw,rsize2768,wsize2768,tcp,addr=X.X.X.X

Cette machine est destinée à être lourdement sollicitée, et aura besoin
de ses 4gbps de bande passante, donc il _FAUT_ que nfs se dépatouille
avec le bonding !

en cas de doute on peut faire sans mais cela marche bien

options bonding miimon0 mode=4 xmit_hash_policy=layer3+4

je me suis contenté de ça :
options bonding mode=4 miimon0 downdelay 0 updelay 0
Quel est l'intéret du xmit_hash_policy ?

load balancing sur ip des clients meilleure répartition sur les interfaces

JKB a écrit :

Version du noyau (des deux côtés), type de système de fichiers,
options de montages (locales et distantes), type de NFS.

Le serveur est une Debian Lenny :

filer1:/data/fae# uname -a
Linux filer1 2.6.26-2-amd64 #1 SMP Thu May 28 21:28:49 UTC 2009 x86_64
GNU/Linux
filer1:/data/fae# mount | grep /data
/dev/mapper/vg_filer-data on /data type jfs (rw,errors=remount-ro)
filer1:/data/fae# df -h | grep /data
/dev/mapper/vg_filer-data 6,6T 1,3T 5,4T 19% /data
filer1:/data/fae# dpkg -l | grep nfs-kernel-server
ii nfs-kernel-server 1:1.1.2-6lenny1

Les clients sont des RHEL4 32 et 64 bits :

[rico@kapa3 ~]$ uname -a
Linux kapa3.eve 2.6.9-55.ELsmp #1 SMP Fri Apr 20 16:36:54 EDT 2007
x86_64 x86_64 x86_64 GNU/Linux
[rico@kapa3 ~]$ mount | grep filer1
filer1:/data/fae on /auto/filer1_fae type nfs
(rw,tcp,rsize2768,wsize2768,addr=x.x.x.x)

rico@filer1:~$ cat /etc/exports
/data/fae *(rw,sync,no_subtree_check)

Bon, ça n'aide pas.

certes ! c'est corrigé

J'ai toujours fait sans en faisant des sous-réseaux indépendants. Je
ne répondrais donc pas à la question.

en l'occurence, c'est un serveur nfs pour une ferme de calcul, et les
membres de la ferme (une 50 aine de machines) sont déjà isolées dans un
réseau

--
Rico

Fabien LE LEZ a écrit :

On Tue, 09 Jun 2009 16:18:16 +0200, Eric Belhomme
<{rico}+no/spam@ricospirit.net>:

time dd if=/dev/urandom bs=1k count4857600
of=/auto/filer1_fae/test_`uname -n`.dat

Pendant que j'y pense : /dev/urandom est peut-être le goulot
d'étranglement.
Que donne cette ligne ?
time dd if=/dev/urandom bs=1k count4857600 of=/dev/null

effectivement, mon test n'etait peut-etre pas tres adapté :


rico@filer1:/data/rd$ time dd if=/dev/urandom bs=1k count4857600
of=./test_local.dat
104857600+0 enregistrements lus
104857600+0 enregistrements écrits
107374182400 bytes (107 GB) copied, 13772,1 s, 7,8 MB/s

real 229m32.121s
user 0m12.277s
sys 226m19.945s

rico@filer1:/data/rd$ time dd if=/dev/zero bs=1k count4857600
of=./test_local_zero.dat
104857600+0 enregistrements lus
104857600+0 enregistrements écrits
107374182400 bytes (107 GB) copied, 391,354 s, 274 MB/s

real 6m31.512s
user 0m9.857s
sys 2m59.587s

230 minutes pour créer 100GB de random, 6 minutes pour créer 100GB de
zéros... c'est beaucoup mieux !

--
Rico

Eric Belhomme a écrit :

en l'occurence, c'est un serveur nfs pour une ferme de calcul, et les
membres de la ferme (une 50 aine de machines) sont déjà isolées dans un
réseau

sur notre cluster j'ai jamais réussi à obtenir les perf que l'on avait besoin
en nfs et du coup on est passé en lustre au niveau filesystem

depuis un client ( bond sur deux interfaces )

[weill@ciclad3 test]$ dd if=/dev/zero of=TOTO bs=1M count240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 56.1089 seconds, 191 MB/s

Philippe Weill a écrit :

Je virerais aussi l'agrégation (je ne sais pas comment un NFS va
utiliser ça, donc dans le doute...).

en cas de doute on peut faire sans mais cela marche bien

options bonding miimon0 mode=4 xmit_hash_policy=layer3+4

Je me disais aussi qu'un peu de contro lde traffic ne pourrait nuire...
Que pensez-vous de mettre un classificateur simple, genre sfq, afin de
répartir équitablement la bande passante ? Y a-t-il des contres
indications avec nfs ?

--
Rico

Philippe Weill a écrit :

sur notre cluster j'ai jamais réussi à obtenir les perf que l'on avait
besoin
en nfs et du coup on est passé en lustre au niveau filesystem

depuis un client ( bond sur deux interfaces )

[weill@ciclad3 test]$ dd if=/dev/zero of=TOTO bs=1M count240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 56.1089 seconds, 191 MB/s

LUSTRE sous linux ??? comment ?

--
Rico

Le 10-06-2009, ? propos de
Re: optimisation de serveur NFS,
Eric Belhomme ?crivait dans fr.comp.stockage :

JKB a écrit :

Version du noyau (des deux côtés), type de système de fichiers,
options de montages (locales et distantes), type de NFS.

Le serveur est une Debian Lenny :

filer1:/data/fae# uname -a
Linux filer1 2.6.26-2-amd64 #1 SMP Thu May 28 21:28:49 UTC 2009 x86_64
GNU/Linux
filer1:/data/fae# mount | grep /data
/dev/mapper/vg_filer-data on /data type jfs (rw,errors=remount-ro)
filer1:/data/fae# df -h | grep /data
/dev/mapper/vg_filer-data 6,6T 1,3T 5,4T 19% /data
filer1:/data/fae# dpkg -l | grep nfs-kernel-server
ii nfs-kernel-server 1:1.1.2-6lenny1

Les clients sont des RHEL4 32 et 64 bits :

[rico@kapa3 ~]$ uname -a
Linux kapa3.eve 2.6.9-55.ELsmp #1 SMP Fri Apr 20 16:36:54 EDT 2007
x86_64 x86_64 x86_64 GNU/Linux
[rico@kapa3 ~]$ mount | grep filer1
filer1:/data/fae on /auto/filer1_fae type nfs
(rw,tcp,rsize2768,wsize2768,addr=x.x.x.x)

Celui-là, il est _mauvais_. Lorsqu'on voit tout ce qui s'est passé
dans la couche NFS entre le 2.6.9 et le 2.6.26, j'essayerai de me
rapprocher d'un 2.6.26 pour les client.

rico@filer1:~$ cat /etc/exports
/data/fae *(rw,sync,no_subtree_check)

Bon, ça n'aide pas.

certes ! c'est corrigé

J'ai toujours fait sans en faisant des sous-réseaux indépendants. Je
ne répondrais donc pas à la question.

en l'occurence, c'est un serveur nfs pour une ferme de calcul, et les
membres de la ferme (une 50 aine de machines) sont déjà isolées dans un
réseau

Je suis _exactement_ dans la même configuration que toi pour mon
cluster (aux OS près). J'ai deux machines frontales redondantes
(linux/sparc) qui exportent un volume raid5+1 soft over iSCSI en NFS (soit
l'une, soit l'autre). Les serveurs derrières sont des Sparc diskless sous
Solaris 10 (les disques systèmes de ces machines sont des images ISO
montées en loopback puis exportées en NFS). Les taux de lecture/écriture
approchent les 120 Mo/s avec la configuration par défaut du serveur NFS en
terme de nombre de threads (et je suis pervers, j'ai du PostgreSQL et du mySQL
sur le cluster). Par contre, le switch, c'est du 3Com, pas du Dell. Je ne fais
pas d'agrégation parce que je n'ai plus aucune interface gigabit
disponible (4 par machine, deux vers l'extérieur montées en interfaces
virtuelles, une pour le iSCSI entre les machines et la dernière pour le
cluster). Avec ça, ça tourne raisonnablement bien (d'autant que le
premier truc à saturer, c'est le iSCSI, pas le serveur NFS).

Mes options d'export sont :

/export/home/srv/solaris10-dvorak
192.168.1.71(rw,async,no_root_squash,subtree_check)

Chez moi, tout est en ext3, les serveurs ont 24 procs/4 Go de
mémoire et les clients 32 procs/8 Go. La grande majorité de la mémoire
des serveurs est en fait utilisée par le cache disque (ces machines ne
font que routeur, firewall et serveur NFS).

RPCNFSDCOUNT=8

poulenc:[/etc/default] > ps auwx | grep nfs
root 3229 0.0 0.0 0 0 ? S< 2008 0:00 [nfsiod]
root 25283 0.1 0.0 0 0 ? S Mar03 215:12 [nfsd]
root 25284 0.1 0.0 0 0 ? S Mar03 212:53 [nfsd]
root 25285 0.1 0.0 0 0 ? S Mar03 207:41 [nfsd]
root 25286 0.1 0.0 0 0 ? S Mar03 212:49 [nfsd]
root 25287 0.1 0.0 0 0 ? S Mar03 209:19 [nfsd]
root 25288 0.1 0.0 0 0 ? S Mar03 213:39 [nfsd]
root 25289 0.1 0.0 0 0 ? S Mar03 210:05 [nfsd]
root 25290 0.1 0.0 0 0 ? S Mar03 208:40 [nfsd]
bertrand 29504 0.0 0.0 3920 1080 pts/0 S+ 09:23 0:00 grep nfs
poulenc:[/etc/default] >

Le noyau est un 2.6.26 quelque chose (j'ai deux ou trois patches
sauvages dedans ne serait-ce que pour le iSCSI target et initiator).
J'ai _totalement_ viré le NFSv4 parce que je n'ai pas envie d'essuyer
les plâtres avec une brique. Le noyau de base fonctionnait très mal en
NFS parce qu'il essayait d'exporter des trucs par défaut en NFSv4 (donc
clients qui ne bootaient plus et problèmes divers et variés).

Les options de montage côté solaris sont :

192.168.1.254:/export/home/srv/solaris10-tchaikovski/ - / nfs 1
yes logging,vers=3,proto=tcp

Avec une nuance, L'openprom ne supporte un boot réseau qu'en
NFSv2/UDP avec des paquets de 8k. Donc je laisse le serveur se démerder
avec les protocoles v2/v3, TCP/UDP et les tailles des paquets. Il y
arrive très bien. Je le laisse d'autant plus se démerder qu'en forçant
des paquets de 32 Ko côté client, les performances étaient moindres.

Bref, tant que tu n'arrives pas à 120 Mo/s entre un serveur et un
client _au cul_ du serveur, c'est-à-dire sans passer par un switch
(parce que les switches permettent d'avoir des surprises assez
désagréables...), c'est qu'il reste un problème quelque part (et je ne
fais confiance à Dell ni pour les serveurs, ni pour les switches.).

Cordialement,

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 10-06-2009, ? propos de
Re: optimisation de serveur NFS,
Eric Belhomme ?crivait dans fr.comp.stockage :

Philippe Weill a écrit :

Je virerais aussi l'agrégation (je ne sais pas comment un NFS va
utiliser ça, donc dans le doute...).

en cas de doute on peut faire sans mais cela marche bien

options bonding miimon0 mode=4 xmit_hash_policy=layer3+4

Je me disais aussi qu'un peu de contro lde traffic ne pourrait nuire...
Que pensez-vous de mettre un classificateur simple, genre sfq, afin de
répartir équitablement la bande passante ? Y a-t-il des contres
indications avec nfs ?

Je ne pense pas que ce soit une bonne idée pour commencer, d'autant
plus que les classificateurs moyennent les débits. En plus, ça rajoute
encore une couche et je ne suis pas bien sûr que pour obtenir quelque
chose de fonctionnel, le jeu en vaille la chandelle.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Eric Belhomme a écrit :

Philippe Weill a écrit :

sur notre cluster j'ai jamais réussi à obtenir les perf que l'on avait
besoin
en nfs et du coup on est passé en lustre au niveau filesystem

depuis un client ( bond sur deux interfaces )

[weill@ciclad3 test]$ dd if=/dev/zero of=TOTO bs=1M count240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB) copied, 56.1089 seconds, 191 MB/s

LUSTRE sous linux ??? comment ?

sous linux bien sur

[weill@ciclad1 ~]$ uname -a
Linux ciclad1 2.6.18-53.1.14.el5_lustre.1.6.5.1smp #1 SMP Wed Jun 18 19:45:15 EDT 2008 x86_64 x86_64
x86_64 GNU/Linux

Centos 5.2

[weill@ciclad1 ~]$ lfs df -h
UUID bytes Used Available Use% Mounted on
homefs-MDT0000_UUID 87.5G 564.7M 85.9G 0% /home[MDT:0]
homefs-OST0000_UUID 1.3T 49.4G 1.3T 3% /home[OST:0]

filesystem summary: 1.3T 49.4G 1.3T 3% /home

UUID bytes Used Available Use% Mounted on
datafs-MDT0000_UUID 350.0G 3.8G 342.2G 1% /data[MDT:0]
datafs-OST0000_UUID 7.8T 7.3T 472.4G 93% /data[OST:0]
datafs-OST0001_UUID 7.8T 7.3T 430.7G 93% /data[OST:1]
datafs-OST0002_UUID 7.8T 7.2T 518.1G 92% /data[OST:2]
datafs-OST0003_UUID 7.8T 7.2T 535.3G 92% /data[OST:3]
datafs-OST0004_UUID 4.5T 4.1T 379.6G 90% /data[OST:4]
datafs-OST0005_UUID 4.5T 4.2T 329.7G 91% /data[OST:5]
datafs-OST0006_UUID 4.5T 4.2T 340.5G 91% /data[OST:6]
datafs-OST0007_UUID 4.5T 4.1T 380.4G 90% /data[OST:7]

voir peut etre www.lustre.org ;-)

pour notre archi et un exemple d'implémentation

voir les 2 docs sur
ftp://ftp.aero.jussieu.fr/aeronomie/weill/private/lustre/