Bonjour à tous.
J'aimerais rebondir sur le thread précèdent pour vous demander vos avis sur le matériel Netapp. Il existe une espèce d'image très positive sur cette marque hors je n'ai eu bien des soucis avec.
Le dernier en date étant assez exceptionnel, perte d'une liaison FC, puis panic d'une tête. Après le reboot tout était revenu... J'en ai eu beaucoup d'autre, sans compter le fait que je trouve très très cher pour ce que cela fait.
Merci de vos retours.
2010/9/12 Raphael Mazelier raph@futomaki.net:
Bonjour à tous.
J'aimerais rebondir sur le thread précèdent pour vous demander vos avis sur le matériel Netapp. Il existe une espèce d'image très positive sur cette marque hors je n'ai eu bien des soucis avec.
Le dernier en date étant assez exceptionnel, perte d'une liaison FC, puis panic d'une tête. Après le reboot tout était revenu... J'en ai eu beaucoup d'autre, sans compter le fait que je trouve très très cher pour ce que cela fait.
J'ai passer pas mal de temps avec du matos NetApp. Je ne l'ai utilise qu'en mode NAS et tres peu en SAN (mais du peu ce que j'ai vu je n'ai jamais eu de probleme avec) Sur la partie NAS, on peut citer les bons cotes : - Snapshots a gogo - Writeble Snapshots - Volume Flexibles - Thin Provisioning - Deduplication - Configuration Reseau supportant les Vlans (mine de rien y'a encore des constructeur de baie NAS qui ne le supportent pas) - C'est super rapide en I/O grace au cache en NVRAM. Les commits d'ecriture sont fait des que la donnees est ecrite en RAM et pas sur disque. (vitesse a compare avec un simple NFSD sous linux/solaris/xxx) - etc etc (le site officiel est la pour ca non ?)
Les limites : - 16To par aggeragat donc des volumes/LUNs qui ne depassent pas les 10To utile. Meme dans les modeles Haut de Gammes. En fait c'est bete, mais c'est une limitation de l'OS (Data ONTAP). Ils viennent de passer la limite a 150To dans la nouvelle version de DataOntap avec ce qu'ils apelles les aggregats 64bits mais ca resque quand meme ridicule dans certains usages. - Data ONTAP souffre d'un support incorrect/mauvais du multiprocess/multithread. C'est du code ferme mais on peut quand meme se poser des questions quand un utilisateur lance un gros rm sur une arboresence assez profonde et pleins d'inode (type cache squid ou maildirs) de quelques centaines de giga et que l'ensemble des serveurs commencent a souffrir avec "Nfs is not responding" (rigolo quand tu sais que leur slogan est "No more NFS is not Responding"). Sur la baie, 7 processurs sont en IDLE et le process NFSD squatte un seul processeur/core a 100%. NetApp n'a jamais voulu reconnaitre le probleme ni l'investiguer. - Pour tous les problemes de perfs, il faut etre a moins de 92% de remplissage des volumes pour esperer que le probleme arrive juqu'au support niveau 2/3. D'apres eux, passe ce taux de remplissage, l'OS/Filesystem se comprtent de facon differente.
Le future : Ils ont carrement merde leurs relase 8. Ils ont voulu que cette version soit celle qui unira (enfin !) GX et ONTAP avec une base de code commune. On se retrouve finalement avec deux versions batardes. - La 8 7-mode : c'est la version 7 (Snapshot, Flexvol etc) avec quelques nouveautes telque les aggregats 64bits. Et c'est tout. En plus les aggregats 64bits ne sont pas compatibles avec leurs predesseseurs. Upgrader le controleur de 7 a 8 ne transforme pas les anciens aggregats en 64bits automagiquement ils restent 32bits, il faudra en creer des nouveaux (64bits) a cote et transvaser les donners des anciens vers les nouveaux... - La 8 cluster-mode : Qui elle une version GX et donc offre la scalabilite horizontale. Les tetes ne sont plus en Clusters 2 noeuds mais plus tu rajoute de tetes plus tu rajoutes de la puissance de traitement. Plus tu rajoute des shelfs plus tu rajoute de la capacite. C'est du scale-out NAS en gros. Mauvaise nouvelle, c'est pas production ready et tu n'as rien des fonctionnalites de ONTAP (ni Snapshots, ni FlexVol)
Donc pour le moment, il faut attendre encore 1 an ou 2 ans pour esperer voir de vrais nouveautes. Ils ont rachete GX il y'a 3 ou 4 ans et ils se sont endormi sur leurs loriers. Le produit n'a jamais vu le jour et c'est a peine s'il commence a emerger aujourd'hui.
Enfin une petite note sur l'administration. Le fait que ca soit un cluster actif/passif (croise) rajoute une penibilite non negligeable dans la gestion de tout les jours. Il faut a tout moment savoir sur quel tete est rattache tel volume pour pouvoir le modifier (meme chose pour la gestion des exports et des shares CIFS) La CLI n'est pas coherente, parfois il suffit de taper des commandes pour que ca soit "reboot proof" parfois il faut ecrire les commandes dans des fichiers a la main pour que ca soit "reboot proof".
A part ca, ca fonctionne correctement, ca supporte les coups dures (type coupure de courant brutale) faut prendre son mal en patience quand quelqu'un fait un gros rm :) En terme de perfs c'est en fonction des disques mais ca va tres vite en regle generale. En terme de fonctionnalites, je crois qu'ils restent quand meme les plus riches meme si les concurrents commencent a egaler ce qu'ils font (faute d'innovation)
Youssef Ghorbal
PS : N'hesitez pas a me corriger si j'ai dis des betises.
[...]
A part ca, ca fonctionne correctement, ca supporte les coups dures (type coupure de courant brutale) faut prendre son mal en patience quand quelqu'un fait un gros rm :) En terme de perfs c'est en fonction des disques mais ca va tres vite en regle generale. En terme de fonctionnalites, je crois qu'ils restent quand meme les plus riches meme si les concurrents commencent a egaler ce qu'ils font (faute d'innovation)
--- J'ai realise il y'a quelques temps des petits tests de perfs sur du FAS 6080c en comparaison avec une x4540 sous ZFS. A noter que les x4540 ont des disques plus recents que le 6080 qui a des disques SATA qui ont plus de 3 ans. Les tests ont ete realise avec un simple dd sur NFS et en utilisant bonnie++ pour lire/ecrire/supprimer 1024 petits fichier (~100K) reparties dans 1024 repertoires, actions realisees aleatoirement et sequentiellement. J'ai les commandes exacts si ca vous interesse. Ci-joint les graphes/chiffres : - La difference en lecture/ecriture brute (dd de 16Go) peut s'expliquer par les vitesses des disques mais un tel decalage ne peut pas uniquement etre explique par la vitesse des disques. Je concidere donc que sur terrain la Sun/ZFS l'emporte. Sur la lecture j'arrive presque a saturer le lien Gigabit entre le client et la baie. - Sur la creation/suppression de fichiers NetAPP l'emporte (de loin) grace au cache. La SUN dispose d'autant de RAM que la tete du 6080 (ou plus meme) sauf que NFSD ecrit sur le disque avant de commiter au client la creation ou la suppression des fichiers alors que le NetAPP commit des que l'info est en NVRAM ce qui lui permet d'aller treeeeees vite. - Sur les lectures de fichiers on retrouve la constatation de depart, mais je concidere que le gap ici peut s'expliquer simplement par la vitesse/techno des disques et donc je concidere les deux solutions "comparables"
Ce n'est pas tres rigoureux comme tests mais ca permet d'avoir une idee. Certains utilisateurs que j'ai passe de NetApp a Sun/ZFS se sont tout de suite pleins de "lenteurs" a cause de cette difference enorme en vitesse de commit.
Youssef Ghorbal
Salut,
Le 14 sept. 2010 à 01:58, Youssef Ghorbal a écrit :
[...]
A part ca, ca fonctionne correctement, ca supporte les coups dures (type coupure de courant brutale) faut prendre son mal en patience quand quelqu'un fait un gros rm :) En terme de perfs c'est en fonction des disques mais ca va tres vite en regle generale. En terme de fonctionnalites, je crois qu'ils restent quand meme les plus riches meme si les concurrents commencent a egaler ce qu'ils font (faute d'innovation)
J'ai realise il y'a quelques temps des petits tests de perfs sur du FAS 6080c en comparaison avec une x4540 sous ZFS. A noter que les x4540 ont des disques plus recents que le 6080 qui a des disques SATA qui ont plus de 3 ans. Les tests ont ete realise avec un simple dd sur NFS et en utilisant bonnie++ pour lire/ecrire/supprimer 1024 petits fichier (~100K) reparties dans 1024 repertoires, actions realisees aleatoirement et sequentiellement. J'ai les commandes exacts si ca vous interesse. Ci-joint les graphes/chiffres :
- La difference en lecture/ecriture brute (dd de 16Go) peut
s'expliquer par les vitesses des disques mais un tel decalage ne peut pas uniquement etre explique par la vitesse des disques. Je concidere donc que sur terrain la Sun/ZFS l'emporte. Sur la lecture j'arrive presque a saturer le lien Gigabit entre le client et la baie.
- Sur la creation/suppression de fichiers NetAPP l'emporte (de loin)
grace au cache. La SUN dispose d'autant de RAM que la tete du 6080 (ou plus meme) sauf que NFSD ecrit sur le disque avant de commiter au client la creation ou la suppression des fichiers alors que le NetAPP commit des que l'info est en NVRAM ce qui lui permet d'aller treeeeees vite.
- Sur les lectures de fichiers on retrouve la constatation de depart,
mais je concidere que le gap ici peut s'expliquer simplement par la vitesse/techno des disques et donc je concidere les deux solutions "comparables"
Ce n'est pas tres rigoureux comme tests mais ca permet d'avoir une idee. Certains utilisateurs que j'ai passe de NetApp a Sun/ZFS se sont tout de suite pleins de "lenteurs" a cause de cette difference enorme en vitesse de commit.
J'ai remarqué effectivement ce "problème" sur ZFS... Est-ce que ton x4540 as un (ou plusieurs) SSD en logzilla et en arc2cache ?
/Xavier
Youssef Ghorbal <16Go-read-test.png><16Go-write-test.png><creation-test.png><delete-test.png><read-test.png>_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour,
Le 14/09/2010 01:58, Youssef Ghorbal a écrit :
J'ai realise il y'a quelques temps des petits tests de perfs sur du FAS 6080c en comparaison avec une x4540 sous ZFS. A noter que les x4540 ont des disques plus recents que le 6080 qui a des disques SATA qui ont plus de 3 ans. Les tests ont ete realise avec un simple dd sur NFS et en utilisant bonnie++ pour lire/ecrire/supprimer 1024 petits fichier (~100K) reparties dans 1024 repertoires, actions realisees aleatoirement et sequentiellement. J'ai les commandes exacts si ca vous interesse. Ci-joint les graphes/chiffres :
- La difference en lecture/ecriture brute (dd de 16Go) peut
s'expliquer par les vitesses des disques mais un tel decalage ne peut pas uniquement etre explique par la vitesse des disques. Je concidere donc que sur terrain la Sun/ZFS l'emporte. Sur la lecture j'arrive presque a saturer le lien Gigabit entre le client et la baie.
- Sur la creation/suppression de fichiers NetAPP l'emporte (de loin)
grace au cache. La SUN dispose d'autant de RAM que la tete du 6080 (ou plus meme) sauf que NFSD ecrit sur le disque avant de commiter au client la creation ou la suppression des fichiers alors que le NetAPP commit des que l'info est en NVRAM ce qui lui permet d'aller treeeeees vite.
- Sur les lectures de fichiers on retrouve la constatation de depart,
mais je concidere que le gap ici peut s'expliquer simplement par la vitesse/techno des disques et donc je concidere les deux solutions "comparables"
Il faut vraiment faire attention avec ZFS et bien comprendre comment il fonctionne. Déjà, un disque SATA qui a 3 ans est à peine moins performant qu'un disque SATA moderne, il y a eu eu très peu d'évolution et seule la vitesse du bus et de rotation change les perfs.
Ensuite, sur un NetApp on aura tendance à utiliser leur RAID-DP qui offre une bonne sécurité et des bonnes perfs, par contre, en ZFS le RAID-Z et RAID-Z2 sont à proscrire car ils offrent les performances en écriture d'un seul disque !!
ZFS = RAID-10 obligatoire sauf cas très spécifiques. En RAID-10 sur n disques, ZFS fourni 60*n iops en lecture et 60*n/2 iops en écriture. On peut ajouter un SSD de log pour accélérer les écritures (cache de qq secondes le temps de trouver de l'espace lire et d'écrire séquentiellement des écritures aléatoires) mais on restera limité en écriture stream par le IOPs des disques.
Frédéric.
Le 14 sept. 2010 à 09:44, Frédéric VANNIÈRE a écrit :
Ensuite, sur un NetApp on aura tendance à utiliser leur RAID-DP qui [...] ZFS = RAID-10 obligatoire sauf cas très spécifiques.
Si c'est vrai, on a un énorme gap de densité entre les deux : entre 2/14e (si mes souvenirs sont bons) et 50% de perte, ça fait une grosse différence.
(A moins de considérer ceux qui ont besoin de densité dans les cas très spécifiques, mais c'est alors vexant de se faire traiter de "cas très spécifique" :D )
Il me paraitrait intéressant d'avoir un comparatif de perfs NetApp (RAID-DP) vs ZFS (RAID 10) vs ZFS (RAID-DP like).
JFB
Le 14/09/2010 10:06, JF Bustarret a écrit :
Le 14 sept. 2010 à 09:44, Frédéric VANNIÈRE a écrit :
Ensuite, sur un NetApp on aura tendance à utiliser leur RAID-DP qui [...] ZFS = RAID-10 obligatoire sauf cas très spécifiques.
Si c'est vrai, on a un énorme gap de densité entre les deux : entre 2/14e (si mes souvenirs sont bons) et 50% de perte, ça fait une grosse différence.
L'idée de ZFS est de mettre des gros disques lents (1 ou 2 To en 7.2k) et de compenser avec énormément de cache en lecture (plein de RAM et des SSD) ainsi qu'un cache en écriture sur NVram ou SSD.
Il me paraitrait intéressant d'avoir un comparatif de perfs NetApp (RAID-DP) vs ZFS (RAID 10) vs ZFS (RAID-DP like).
Pour environ le même prix j'ai eu un NetApp en 2008 et un Sun Storage en 2010, impossible de comparer les deux sur le papier :
- NetApp FAS2050, cluster actif/actif, Celeron mobile à 2,2 GHz (1 cœur), 2 Go cache en lecture + 256 Mo NVRAM par tête, 2x1,5 To utiles en RAID-DP sur 20 disques 300 Go SAS 15k : 2x(7+2parité+1spare) => 2x1050 iops en lecture et 2x1050 iops en écriture.
- Sun Storage 7310, cluster actif/passif, Bi-Opteron Hexa-core à 2,2 GHz (12 cœurs), 64 Go RAM + 200 Go SSD de cache en lecture, 18 Go SSD cache en écriture, 6 To utiles en RAID-10 triple sur 21 disques 1 To SATA 7.2k + 1 spare. => 1200 iops en lecture et 420 iops en écriture séquentielle (contre près de 200 000 iops NFS en lecture depuis le cache)
à cause du petit cache en lecture le NetApp doit souvent lire les disques alors que le Sun lui va le faire beaucoup plus rarement. Par contre, pour écrire les données en séquentiel le NetApp va être bien plus efficace.
Les performances vont surtout dépendre de l'usage car on a deux approches totalement différentes pour faire de l'IOPS.
Frédéric.
Bon 3 crash en 3 jours... j'abandonne et je vais prendre ma hache pour l'achever. Vive l'attachement direct.
Le 14/09/2010 15:50, Raphael Mazelier a écrit :
Bon 3 crash en 3 jours... j'abandonne et je vais prendre ma hache pour l'achever. Vive l'attachement direct.
Si je devais faire un petit SAN sans fonctionnalités avancées et pour quelques serveurs (hôtes Xen/KVM), je pense que je partirais vers une baie de stockage RAID SAS-2 (HP MSA, Infortrend, Xyratex ou autre) et un switch SAS-2 LSI. Simple, fiable et économique:
http://www.lsi.com/storage_home/products_home/sas_switch/sas6100/index.html
J'ai utilisé pdt 5 ans un FAS3020C et n'ai eu qu'un crash disque pendant cette période. La seule fois ou j'ai recontré un crash, cela provenait de la version 7.2P6 de DataONTAP si mes souvenirs sont bons. Je suis donc passé sur une version (n-2) 7.3.2P1 et le problème n'est jamais réapparu.
Il me semble que Netapp fournit des outils pour mesurer les perfs de ton filer : "perfstat". Je l'ai utilisé une fois sur un problème justement de réparition I/O.
Pour infos le FAS3020 embarquait "seulement" 2go de RAM ce qui est juste si on l'utilise pour la gestion d'un FS assez volumineux (beaucoup de fichiers dans beaucoup trop de répertoire). Le filer passait son temps à traiter les metadatas.
impact => systat indiquait que les disques constamment utilisés à 100%.
on a repensé l'organisation des FS + répartition correctes des volumes par aggrégat en fct du nombre de disques et tout est revenu dans l'ordre.
T'as une idée sur l'origine du crash ? ton filer est-il à jour (version -b) ? etc....
sysstat -sux 1 pour vérifier le bon cycle d'écriture/lecture & le taux utilisation cache + disque
normalement : sync toutes les 10 sec (à confirmer)
Le filer écrit dans le cache puis synchronise toutes les n secs les disques.
Tiens-bon & bon courage !!!!
Le 14 septembre 2010 15:50, Raphael Mazelier raph@futomaki.net a écrit :
Bon 3 crash en 3 jours... j'abandonne et je vais prendre ma hache pour l'achever. Vive l'attachement direct.
-- Raphael Mazelier
Liste de diffusion du FRsAG http://www.frsag.org/
En mode admin et CLI, on aussi statit (il me semble) qui donne des informations interessantes. Attention à ne pas le laisser tourner trop longtemps, surtout en pleine charge. :)
Si tu fais aussi beaucoup d'écriture, il est bon de monitorer les "Back to Back" (nvram qui a pas le temps de se vider avant que l'autre partie soit pleine), soit en CLI, soit via la couche SNMP.
Et bon courage aussi. :)
Le 14/09/2010 16:23, Karim AZAIZIA a écrit :
J'ai utilisé pdt 5 ans un FAS3020C et n'ai eu qu'un crash disque pendant cette période. La seule fois ou j'ai recontré un crash, cela provenait de la version 7.2P6 de DataONTAP si mes souvenirs sont bons. Je suis donc passé sur une version (n-2) 7.3.2P1 et le problème n'est jamais réapparu.
Il me semble que Netapp fournit des outils pour mesurer les perfs de ton filer : "perfstat". Je l'ai utilisé une fois sur un problème justement de réparition I/O.
Pour infos le FAS3020 embarquait "seulement" 2go de RAM ce qui est juste si on l'utilise pour la gestion d'un FS assez volumineux (beaucoup de fichiers dans beaucoup trop de répertoire). Le filer passait son temps à traiter les metadatas.
impact => systat indiquait que les disques constamment utilisés à 100%.
on a repensé l'organisation des FS + répartition correctes des volumes par aggrégat en fct du nombre de disques et tout est revenu dans l'ordre.
T'as une idée sur l'origine du crash ? ton filer est-il à jour (version -b) ? etc....
sysstat -sux 1 pour vérifier le bon cycle d'écriture/lecture & le taux utilisation cache + disque
normalement : sync toutes les 10 sec (à confirmer)
Le filer écrit dans le cache puis synchronise toutes les n secs les disques.
Tiens-bon & bon courage !!!!
Le 14/09/2010 16:23, Karim AZAIZIA a écrit :
J'ai utilisé pdt 5 ans un FAS3020C et n'ai eu qu'un crash disque pendant cette période. La seule fois ou j'ai recontré un crash, cela provenait de la version 7.2P6 de DataONTAP si mes souvenirs sont bons. Je suis donc passé sur une version (n-2) 7.3.2P1 et le problème n'est jamais réapparu.
Il me semble que Netapp fournit des outils pour mesurer les perfs de ton filer : "perfstat". Je l'ai utilisé une fois sur un problème justement de réparition I/O.
Pour infos le FAS3020 embarquait "seulement" 2go de RAM ce qui est juste si on l'utilise pour la gestion d'un FS assez volumineux (beaucoup de fichiers dans beaucoup trop de répertoire). Le filer passait son temps à traiter les metadatas.
impact => systat indiquait que les disques constamment utilisés à 100%.
on a repensé l'organisation des FS + répartition correctes des volumes par aggrégat en fct du nombre de disques et tout est revenu dans l'ordre.
T'as une idée sur l'origine du crash ? ton filer est-il à jour (version -b) ? etc....
sysstat -sux 1 pour vérifier le bon cycle d'écriture/lecture& le taux utilisation cache + disque
normalement : sync toutes les 10 sec (à confirmer)
Le filer écrit dans le cache puis synchronise toutes les n secs les disques.
Tiens-bon& bon courage !!!!
Merci si tu veux bien m'aider, parce que le support la... donc déjà j'ai repassé mes cluster sql sur des disques locaux :p pour le debug :
netapp01> version -b 1:/x86_elf/kernel/primary.krn: OS 7.3.1P3 1:/backup/x86_elf/kernel/primary.krn: OS 7.2.6.1 1:/x86_elf/diag/diag.krn: 5.3.6 1:/x86_elf/firmware/deux/firmware.img: Firmware 3.1.0 1:/x86_elf/firmware/SB_XIV/firmware.img: BIOS/NABL Firmware 3.0 1:/x86_elf/firmware/SB_XIV/bmc.img: BMC Firmware 1.2 netapp01> sysstat -sux CPU NFS CIFS HTTP Total Net kB/s Disk kB/s Tape kB/s Cache Cache CP CP Disk FCP iSCSI FCP kB/s iSCSI kB/s in out read write read write age hit time ty util in out in out 17% 9 6 0 15 52 23 4263 1317 0 0 3 96% 11% T 87% 0 0 0 0 0 0 17% 2 1 0 3 6 8 4140 1230 0 0 2s 96% 8% T 86% 0 0 0 0 0 0 18% 12 29 0 41 80 15 4753 2358 0 0 3 96% 14% Tf 87% 0 0 0 0 0 0 21% 10 45 0 55 74 31 4315 1776 0 0 2s 96% 20% T 88% 0 0 0 0 0 0 18% 1 35 0 36 12 15 4262 1386 0 0 2s 96% 10% T 87% 0 0 0 0 0 0 41% 11 44 0 55 108 41 4238 1227 0 0 4 97% 11% T 87% 0 0 0 0 0 0 23% 12 30 0 42 83 73 4660 2897 0 0 3 96% 20% T 89% 0 0 0 0 0 0 20% 7 1 0 8 47 17 4214 1433 0 0 2s 96% 12% T 87% 0 0 0 0 0 0
L'utilisation des disques me parrait violente car normalement le netapp ne fait plus rien ??
Bonjour,
Le 12/09/2010 21:21, Raphael Mazelier a écrit :
J'aimerais rebondir sur le thread précèdent pour vous demander vos avis sur le matériel Netapp. Il existe une espèce d'image très positive sur cette marque hors je n'ai eu bien des soucis avec.
Le dernier en date étant assez exceptionnel, perte d'une liaison FC, puis panic d'une tête. Après le reboot tout était revenu... J'en ai eu beaucoup d'autre, sans compter le fait que je trouve très très cher pour ce que cela fait.
Pour résumer: c'était bien il y a 10 ans. Aujourd'hui c'est complètement à la rue au niveau des fonctionnalités et de l'administration.
L'interface web est merdique (formulaire en applet java), les têtes ont peu de cache et de puissance et je confirme qu'il faut bidouiller des script rc à la main pour que ça soit "reboot proof", notamment pour la gestion des vlans. Ça fait toujours plaisir de voir qu'un NAS à 40K€ qui utilise un OS mature (un peu ranci) perd des interfaces réseau au reboot ...
Au lieu de dépenser des centaines de milliers de dollars en frais d'avocat pour attaquer Sun sur les brevet ZFS ils auraient pu se payer une vraie interface d'administration et faire de l'innovation technologie.
Pour un NAS/SAN classique et moderne la solution Sun Storage 7000 est bien meilleure pour moins cher. Le gros inconvénient ce sont les performances en écriture stream et .... Oracle ... (ça va changer). La gamme sera mise à jour d'ici peu avec des gros Xeon, jusqu'à 1 To de RAM, des disques SAS et un cache en écriture plus rapide. Sur ces bestioles l'interface web est vraiment sympa, on peut activer la compression des données sans soucis (20 à 30% de gain en espace sur des VMs linux), même la changer en cours de route (gzip-9 pour importer la VM et les données puis gzip-2 en prod), la déduplication est juste commerciale et n'est vraiment pas conseillée. Le plus fort c'est toute la partie "analytics" qui est super fine et permet de voir comment les disques travaillent, quel LUN fait des IOs et même quel fichier NFS est le plus accédé.
Fred.
PS: j'aurai bientôt un FAS2050 à vendre :)
Plop,
Pour résumer: c'était bien il y a 10 ans. Aujourd'hui c'est complètement à la rue au niveau des fonctionnalités et de l'administration.
Ca marche toujours de mon coté... et c'est FIABLE... (en tous cas pour ceux qui sont fait en FCAL ou SAS, pas les SATA).
L'interface web est merdique (formulaire en applet java), les têtes ont peu de cache et de puissance et je confirme qu'il faut bidouiller des script rc à la main pour que ça soit "reboot proof", notamment pour la gestion des vlans. Ça fait toujours plaisir de voir qu'un NAS à 40K€ qui utilise un OS mature (un peu ranci) perd des interfaces réseau au reboot ...
Heu... J'ai toujours administré un netapp en ligne de commande, les interface web c'est fait pour les gens qui ne veulent pas lire le manuel... D'ailleurs le mode non documenté est pas mal.
Après si tu lis pas la doc et que tu modifie pas ton /etc/rc libre a toi de ronchonner...
Au lieu de dépenser des centaines de milliers de dollars en frais d'avocat pour attaquer Sun sur les brevet ZFS ils auraient pu se payer une vraie interface d'administration et faire de l'innovation technologie.
Elle y est. Le web c'est naze. Est-ce que tu administrie tes Cisco avec l'interface web ?
Pour un NAS/SAN classique et moderne la solution Sun Storage 7000 est bien meilleure pour moins cher. Le gros inconvénient ce sont les performances en écriture stream et .... Oracle ... (ça va changer). La gamme sera mise à jour d'ici peu avec des gros Xeon, jusqu'à 1 To de RAM, des disques SAS et un cache en écriture plus rapide. Sur ces bestioles l'interface web est vraiment sympa, on peut activer la compression des données sans soucis (20 à 30% de gain en espace sur des VMs linux), même la changer en cours de route (gzip-9 pour importer la VM et les données puis gzip-2 en prod), la déduplication est juste commerciale et n'est vraiment pas conseillée. Le plus fort c'est toute la partie "analytics" qui est super fine et permet de voir comment les disques travaillent, quel LUN fait des IOs et même quel fichier NFS est le plus accédé.
Effectivement ZFS et des choses que Sun Storage ou Nexenta Stor sont assez en avance. Tiens tu parles d'interface web moisie... Bah va jouer avec nexenta stor... elle est pas mal mais je trouve que prendre une interface web c'est une perte de temps que de jouer avec une ligne de commande... qui elle sur nexenta stor est trop limitée...
Fred.
PS: j'aurai bientôt un FAS2050 à vendre :)
Tu le files a des assoces ? De toute façon tu peux pas revendre les licenses Netapp (c'est sur ton contrat)...
/Xavier
Ah j'allais oublier :
C'est fiable et depuis 2000 que j'aministrie ces bidules je n'ai _jamais_ perdu la moindre donnée... J'ai eu de beau crash, des shelfs qui se viandaient, ou autres, j'ai même eu le coup de lancer les d7 (oui... F760 hein) pour pouvoir récup le filesystems jamais perdu quoi que ce soit.
J'en ai eu plusieurs en production, et même si ça prends de la place c'est fiable.
Bon le coté relou c'est les 16Tb... ça je trouve assez nul, mais bon... Chaque produit a des limites... (16Tb pour du netapp, 24 noeuds maxi pour l'isilon... le fantôme Oracle pour le ZFS....).
Bref il faut faire la part des choses... et peser le pour et le contre...
Xavier
Le 13/09/2010 10:17, Xavier Beaudouin a écrit :
Ah j'allais oublier :
C'est fiable et depuis 2000 que j'aministrie ces bidules je n'ai _jamais_ perdu la moindre donnée... J'ai eu de beau crash, des shelfs qui se viandaient, ou autres, j'ai même eu le coup de lancer les d7 (oui... F760 hein) pour pouvoir récup le filesystems jamais perdu quoi que ce soit.
J'en ai eu plusieurs en production, et même si ça prends de la place c'est fiable.
Bon le coté relou c'est les 16Tb... ça je trouve assez nul, mais bon... Chaque produit a des limites... (16Tb pour du netapp, 24 noeuds maxi pour l'isilon... le fantôme Oracle pour le ZFS....).
Bref il faut faire la part des choses... et peser le pour et le contre...
Xavier
Vous me dites que c'est fiable, mais bon pour un équipement qui coute au moins 40K, avoir des panic, ou autres trucs de ce genre je trouve ca juste inadmissible. Quels avantages par rapport un nexentastor sur du matos DELL ? (mis a part a part le support ? et encore)
Le lundi 13 septembre 2010 10:21:15, Raphael Mazelier a écrit :
Vous me dites que c'est fiable, mais bon pour un équipement qui coute au moins 40K, avoir des panic, ou autres trucs de ce genre je trouve ca juste inadmissible.
Je pense que le plus important, c'est de se poser la question essentielle : pourquoi faire ? Quel volume, quelle utilisation. Dans bien des cas, des solutions plus "standards" peuvent parfaitement tenir la route, pour un coût bien inférieur.
J'ai un client qui a du netapp "grosse version", genre le bouzin qui pèse quelques tonnes et prends plusieurs baies.. C'est une chose, mais pour les autres, et des besoins de quelques dizaines de To, ça se gère très bien avec des technos plus "standards"..
amicalement,
Le 13/09/2010 10:21, Raphael Mazelier a écrit :
Vous me dites que c'est fiable, mais bon pour un équipement qui coute au moins 40K, avoir des panic, ou autres trucs de ce genre je trouve ca juste inadmissible. Quels avantages par rapport un nexentastor sur du matos DELL ? (mis a part a part le support ? et encore)
Nexenta ce n'est pas sérieux du tout. J'ai demandé un devis à ASInfo (Supermicro) et Alyseo (Nexenta) pour une offre concurrente du Sun Storage 7310, ils sont censés proposer hard+soft bien adapté.
Déjà ils m'ont proposé du Intel X25-E en SSD de Log alors que ce n'est pas du tout adapté et surtout, je n'ai jamais eu la moindre offre.
Nexenta sera intéressant quand ils auront des appliances supportées avec du matériel fiable et testé.
Frédéric.
Frédéric VANNIÈRE wrote:
Le 13/09/2010 10:21, Raphael Mazelier a écrit :
Vous me dites que c'est fiable, mais bon pour un équipement qui coute au moins 40K, avoir des panic, ou autres trucs de ce genre je trouve ca juste inadmissible. Quels avantages par rapport un nexentastor sur du matos DELL ? (mis a part a part le support ? et encore)
Nexenta ce n'est pas sérieux du tout. J'ai demandé un devis à ASInfo (Supermicro)
Et Asinfo non plus... J'ai d'ailleurs aussi eu cette proposition sous les yeux qu'on s'est empressé d'écarter.
Salut,
Le 13 sept. 2010 à 10:21, Raphael Mazelier a écrit :
Le 13/09/2010 10:17, Xavier Beaudouin a écrit :
Ah j'allais oublier :
C'est fiable et depuis 2000 que j'aministrie ces bidules je n'ai _jamais_ perdu la moindre donnée... J'ai eu de beau crash, des shelfs qui se viandaient, ou autres, j'ai même eu le coup de lancer les d7 (oui... F760 hein) pour pouvoir récup le filesystems jamais perdu quoi que ce soit.
J'en ai eu plusieurs en production, et même si ça prends de la place c'est fiable.
Bon le coté relou c'est les 16Tb... ça je trouve assez nul, mais bon... Chaque produit a des limites... (16Tb pour du netapp, 24 noeuds maxi pour l'isilon... le fantôme Oracle pour le ZFS....).
Bref il faut faire la part des choses... et peser le pour et le contre...
Xavier
Vous me dites que c'est fiable, mais bon pour un équipement qui coute au moins 40K, avoir des panic, ou autres trucs de ce genre je trouve ca juste inadmissible. Quels avantages par rapport un nexentastor sur du matos DELL ? (mis a part a part le support ? et encore)
Depuis 2000, sur une 10 aine de netapp j'ai eu : - 1 panic (dû a priori un pb de ram ecc que j'ai pas vu dans le logs) - 2 plantage de la chaine FCAL - 1 plantage d'un cluster de F760
Il vaut mieux avoir des plantage et de l'idispo de donnée pendant quelques heures que... perdre ses données, car un client ronchonne quand il n'as pas accès a ses données, mais te colle un procès si tu les as perdues....
NexentaStor, pour avoir parlé avec eux, il faut suivre la liste de matériel "supporté". J'ai une grosse dent vis a vis de Dell et ses cartes réseau en carton (quelle idée de foutre du broadcom). NexentaStor m'avais dit un jour "Vous utilisez du supermicro ? Cool alors on a pas de pb et on peux faire ce qu'on veux, voici la liste de ce qui marche....". Je n'ai pas parlé de Dell dans ce job (job -1) à l'époque car la politique de Job-1 c'étais plus de dell (trop cher, rendement electrique de "m......", bref...).
Pour mes besoin de ma boite actuel : Dell -> Out (idem avec HP aussi)...
/Xavier
Raphael Mazelier wrote:
Le 13/09/2010 10:17, Xavier Beaudouin a écrit :
Ah j'allais oublier :
C'est fiable et depuis 2000 que j'aministrie ces bidules je n'ai _jamais_ perdu la moindre donnée... J'ai eu de beau crash, des shelfs qui se viandaient, ou autres, j'ai même eu le coup de lancer les d7 (oui... F760 hein) pour pouvoir récup le filesystems jamais perdu quoi que ce soit.
J'en ai eu plusieurs en production, et même si ça prends de la place c'est fiable.
Bon le coté relou c'est les 16Tb... ça je trouve assez nul, mais bon... Chaque produit a des limites... (16Tb pour du netapp, 24 noeuds maxi pour l'isilon... le fantôme Oracle pour le ZFS....).
Bref il faut faire la part des choses... et peser le pour et le contre...
Xavier
Vous me dites que c'est fiable, mais bon pour un équipement qui coute au moins 40K, avoir des panic, ou autres trucs de ce genre je trouve ca juste inadmissible. Quels avantages par rapport un nexentastor sur du matos DELL ? (mis a part a part le support ? et encore)
Comme quoi il vaut mieux multiplier les équipements plus modestes mais bien secourus qu'un seul vendu par les très bons commerciaux de Netapp comme étant infaillible. On a étudié l'année dernière une proposition pour un 3170 mais finalement renoncé à faire reposer l'essentiel de notre activité sur quelques U. On ne le regrette pas.
Le 13/09/2010 12:42, Mathieu Chouteau a écrit :
Comme quoi il vaut mieux multiplier les équipements plus modestes mais bien secourus qu'un seul vendu par les très bons commerciaux de Netapp comme étant infaillible. On a étudié l'année dernière une proposition pour un 3170 mais finalement renoncé à faire reposer l'essentiel de notre activité sur quelques U. On ne le regrette pas.
C'est un peu ma réflexion actuelle. Plus ca va, moins j'aime le trop centralisé. Certes cela fait plus de chose à maintenir; mais quand ca plante, ca ne plante pas tous.
Le 13/09/2010 12:55, Raphael Mazelier a écrit :
Le 13/09/2010 12:42, Mathieu Chouteau a écrit :
Comme quoi il vaut mieux multiplier les équipements plus modestes mais bien secourus qu'un seul vendu par les très bons commerciaux de Netapp comme étant infaillible. On a étudié l'année dernière une proposition pour un 3170 mais finalement renoncé à faire reposer l'essentiel de notre activité sur quelques U. On ne le regrette pas.
C'est un peu ma réflexion actuelle. Plus ca va, moins j'aime le trop centralisé. Certes cela fait plus de chose à maintenir; mais quand ca plante, ca ne plante pas tous.
Dans ce cas, qu'utilisez-vous pour avoir un NFS "unique" accessible depuis plusieurs machines ? Je suis preneur de l'information. :)
PS : j'utilise différentes choses dont du NetApp, quand on connait les limitations de ce dernier, cela ne fonctionne pas si mal, mais oui c'est couteux et le CLI n'est pas top (vive la convivialité du wrfile...)
Merci.
Le 13/09/2010 17:03, David B. a écrit :
Dans ce cas, qu'utilisez-vous pour avoir un NFS "unique" accessible depuis plusieurs machines ? Je suis preneur de l'information. :)
PS : j'utilise différentes choses dont du NetApp, quand on connait les limitations de ce dernier, cela ne fonctionne pas si mal, mais oui c'est couteux et le CLI n'est pas top (vive la convivialité du wrfile...)
Merci.
Dans l'idéal je n'utiliserais pas de NFS, mais il faut reconnaitre que c'est souvent pratique. Dans c'est cas la (cad uniquement besoin de NFS) un simple serveur sous linux (ou autre) avec une baie de disques (ou non) me parait largement suffisante. Pour la redondance, un cluster actif passif avec recopie via rsync, ou actif actif avec drdb + ocfs2.
On en a en prod mais on a clairement que des problèmes de performance sur des serveurs DELL sous Debian/Ubuntu ... la carte LSI est spécialement faite pour fonctionner uniquement avec du Linux Payant ... autrement on se tape du 30 Mo/s en writing sur un RAID 6 ... de 6 disques tout cela sur un réseau Gigabit avec de l'ISCSI et du bonding sur les 2 serveurs qui exportent les LUN.
Perso : je déconseille cela sur du DELL même avec des cartes hyper performantes ... un petit truc .. si vous ne voulez pas que tout votre système parte en vrille, on a virtualisé ces points sensibles car un reboot complet de la machine parce que monsieur OCFS2 s'est coincé le doigt ça fait pas du bien ... et conseil : si vous voulez mettre de l'OCFS2, exit NFS ... et pensez à prendre les dernières versions de kernel, beaucoup de bugs sont régulièrement corrigés par Oracle.
On avait même essayé de switcher sur GFS ( Redhat ) et ça n'a rien changé : la prod partait complètement en choucroute dû à des perfs, attention aussi aux valeurs mises dans la conf d'OCFS2 ... Pour utiliser cela correctement : il faut tout tuner et faire du benchmark à fond, solution qui se met en place en une semaine minimum.
On Mon, 13 Sep 2010 17:44:36 +0200, Mathieu Chouteau mc@ispfr.net wrote:
Raphael Mazelier wrote:
ou actif actif avec drdb + ocfs2.
Tu as déjà mis cette solution en prod ? Si oui en es-tu satisfait ?
Tu as déjà mis cette solution en prod ? Si oui en es-tu satisfait ?
Oui cela a tourné pendant 2 ans sans problème. Je précise que la volumétrie était peu importante (<100g) et la charge faible. Mais même durant mes tests je n'avais pas rencontré de soucis.
Pour revenir sur le sujet initial voir le bug report:
BUG TITLE: Issuing a lock break could be disruptive if there are active CIFS sessions on the Storage System BUG DESCRIPTION: If a CIFS session has held a lock on a file, and the storage administrator invokes a "lock break" command (with any of the options -p/-o /-h/-f or with a combination) which breaks the lock, and also, at some later time, an application running on that CIFS client atte mpts to perform an SMB "setAttr" operation on that file, then, because of a software defect in Data ONTAP, the CIFS session may tr y to access stale internal information pertaining to the broken lock, and an interruption of storage service can occur. BUG WORKA ROUND: CIFS should be terminated before issuing "lock break". This panic message is a result of bug 380780; however, there is no fix currently available for this particular bug.
Un peu violent comme réaction.
Le 13 sept. 2010 à 10:17, Xavier Beaudouin a écrit :
Bon le coté relou c'est les 16Tb... ça je trouve assez nul, mais bon... Chaque produit a des limites... (16Tb pour du netapp, 24 noeuds maxi pour l'isilon... le fantôme Oracle pour le ZFS....).
Exact ! Faut juste trouver le produit dont les limites (et le prix) sont acceptables.
NB : la comparaison n'est pas cohérente : la limite des 24 noeuds isilon n'est pas une limite physique, on peut aller au delà, au prix de certains compromis (coûts, perfs moins bonnes qu'avec 2 clusters séparés), contrairement aux 16Tb du NetApp (sauf versions récentes), qu'on ne pourra pas dépasser quoi qu'il arrive.
Sinon, indépendamment du débat "NetApp fiable/pas fiable", c'est vrai que Dataontap a pris un sacré coup de vieux par rapport à la concurrence. Tout ça parce qu'ils ont merdé avec l'intégration de GX.
Ca a bien changé par rapport à la bonne vieille époque des 740.
JFB
-
Christophe Casalegno -
David B. -
Frédéric VANNIÈRE -
JF Bustarret -
Karim AZAIZIA -
Lilian RIGARD - Devclic -
Mathieu Chouteau -
Raphael Mazelier -
Xavier Beaudouin -
Youssef Ghorbal