Bonjour,
J'ai une baie netapp qui propose des volumes réseaux en nfs3, je les utilisent pour faire des sauvegardes. Je me pose la question suivante : Est-ce que nfs4 apporterait un gain de performance ?
J'ai trouvé des tests mais que des cas "laboratoire", aucun en prod. Avez-vous des retours sur vos installations (attention je parle pas du petit montage à la maison avec 3 fichiers qui se promènent ;) )
# read vs write
Posté par machmalabala . Évalué à 1.
En pratique, il me semble que les gains de perf de NVFv4 sur NVFv3 se font sur les accès concurrents en lecture. Si c'est juste pour du stockage de backup, avec peu de read, je ne pense pas que ça change grand chose en terme d'I/O pure.
Tu peux avoir plus d'info dans la doc officiel NetApp (TR-3580) mais ce TR ne parle que trèèèès succinctement des différences de perf.
Après, il y a peut-être d'autres choses à faire pour augmenter les perfs (reallocation, etc..)
My 2cts.
[^] # Re: read vs write
Posté par Philippe M (site web personnel) . Évalué à 1.
Ok merci pour ton commentaire.
Les autres choses à faire m'intéresse est-ce que tu peux m'en dire plus ou bien me donner des pistes de recherches ? Je découvre le monde du stockage et normalement cette année je devrais partir en formation pour les certif netapp mais en attendant j'ai quand même tu taf sur la baie :)
Born to Kill EndUser !
[^] # Re: read vs write
Posté par machmalabala . Évalué à 2.
En vrac, tu peux faire :
- un reallocate measure [-l logfile] [-t threshold] [-i interval] [-o] pathname | /vol/volname pour vérifier le degré de fragmentation de tes volumes sur tes agrégats,
- faire des sysstat -x pour voir rapidement s'il y a un bottleneck flagrant sur la baie,
- équilibrer la charge par agrégat (un aggr = un raid group. éviter de mettre tous les volumes gourmands en I/O sur le même aggr)
- si tu as du support, tu peux toujours ouvrir un case chez NetApp avec un perfstat. Mais il vont te poser la question : en quoi les perf actuelles ne vont pas? ça marchait mieux avant? avant quoi? etc..
- vérifier l'alignement des LUNs
[^] # Re: read vs write
Posté par Philippe M (site web personnel) . Évalué à 1.
Merci pour toute ces infos.
J'ai contrôlé le reallocate mesure et j'ai un seul volume qui arrive à 4. Je peux faire le reallocate en prod ?
J'ai un seul aggr mais deux contrôleurs et je réparti suivant le besoin en I/O sur un des deux contrôleurs.
En fait depuis pas mal de mois c'est sur la couche cifs que j'ai un comportement bizarre et particulièrement avec les fichiers excel (2007/2010), ils sont tout simplement affreusement long à s'ouvrir et se peut importe leurs tailles et la machine que j'utilise pour l'ouvrir.
L'alignement des LUN est quelques choses que j'avais commencé à étudié mais comme je dois faire un arrêt des concernés je n'ai pas eu le temps de programmer ça un week-end.
Born to Kill EndUser !
[^] # Re: read vs write
Posté par machmalabala . Évalué à 1.
Pour le reallocate en prod, jette un coup d'oeil à l'utilisation des disques avec un sysstat avant. La réallocation est en basse priorité pour le CPU, mais pas pour les disques :') Du coup, le mieux reste hors prod ou lorsque la prod est moins intense (nuit, week end, jours fériés, etc… )
Les commandes :
reallocate on
reallocate start -p /vol/vol1/
reallocate status /vol/vol1/ (pour vérifier le bon déroulement)
reallocate stop /vol/vol1/ (pour stopper si toujours pas fini et impact sur la prod)
Si tu as un seul aggr, il y a peu de chance que les controleurs soient le bottleneck, ça sera plus facilement les I/O des disques.
Mais par exemple, si tu as des lun misalign, avec des volumes fortement fragmenter, des disques SATA, un petit controler (genre un FAS2220), une version de DataOntap pas terrible (la 8.1 pour ne citer qu'elle) et de la dédup en plus, tu fais très vite tomber les perfs.
Tu es en quelle version de DOT ? Il y a aussi quelques bug sur le CIFS/SMB dans certaines révisions.
[^] # Re: read vs write
Posté par Philippe M (site web personnel) . Évalué à 1.
J'ai viens de faire un test sur un volume nfs peut utilisé mais ayant un gros espace et vue comme s'affole les stats je vais éviter de le faire en prod sur les lun critiques :)
Je suis pas certain d'avoir compris la notion de bottleneck du CPU ?
Je suis sur un FAS2020 en 7.3.7 avec 2 x 12 disques SAS (15 000) en raid 6 DP et deux contrôleurs, le tout connecté via 2 x 2 liens giga à l'infra. En gros le CPU est très peu utilisé, genre 4 ou 5% en moyen sur la journée. Je viens de voir qu'il y a un patch P1 pour la 7.3.7 mais pas moyen de trouver le release note :(
Born to Kill EndUser !
[^] # Re: read vs write
Posté par machmalabala . Évalué à 1.
patch note : http://support.netapp.com/NOW/cgi-bin/relcmp.on?notfirst=Go!&rels=7.3.7+7.3.7P1&what=fix
Cependant, les bugs dont je parlais étaient plus pour les révisions 8.1.x
Le bottleneck CPU, ça arrive si tu as des fortes charges et beaucoup de disques. Ici, avec un shelf, ça serait étonnant que ce soit le cas, les disques vont saturer avant.
[^] # Re: read vs write
Posté par Philippe M (site web personnel) . Évalué à 1.
OUfff grâce à ton lien j'ai enfin compris comment marche le comparateur de release :)
Pas grand chose qui justifie un update en P1 pour moi.
Est-ce qu'il y a un moyen de fonctionner comme avec crontab ? J'ai l'impression que le cron est apparu avec la branche 8 de OnTap. Ce me permettrait de faire le reallocate la nuit ou bien le week-end sur les gros volumes ne pouvait pas être trop touché la journée.
Born to Kill EndUser !
[^] # Re: read vs write
Posté par machmalabala . Évalué à 1. Dernière modification le 14 avril 2014 à 23:09.
L'upgrade en 7.3.7P1 n'est effectivement pas vraiment intéressant pour toi.
Tu peux définir le schedule pour la realloc, c'était déjà dispo en 7.3.7. Tape juste "reallocate schedule ?" et tu auras le man.
Sinon, tu te connectes le soir de chez toi pour lancer la realloc avant de te coucher ;)
[^] # Re: read vs write
Posté par Philippe M (site web personnel) . Évalué à 1.
Sur le schedule y a un peu d'intelligence ? Genre si je programme 2 reallocate à la même heure le même jour il les exécutes l'un après l'autre ou en même temps ?
Merci pour toute ces petites infos que tu me donne ;)
Born to Kill EndUser !
[^] # Re: read vs write
Posté par machmalabala . Évalué à 1.
J'avoue que je ne saurais pas te dire :D Mais dans le doute, fait une nuit par volume. ça peut être très long en fonction de la charge et de la puissance du filer (j'ai vu des reallocation durer plusieurs jours sur des très gros volumes)
Pas de soucis pour les astuces :)
[^] # Re: read vs write
Posté par Philippe M (site web personnel) . Évalué à 1.
J'ai l'impression que pour utiliser scheduler il faut avoir fait déjà au moins un scan… Dommage je suis bon pour le faire à la main de chez moi :(
Born to Kill EndUser !
[^] # Re: read vs write
Posté par machmalabala . Évalué à 1.
sinon tu te fais un cron tab sur un host linux avec accès rsh sur le filer :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.