Contexte - première tentative d'achat informatique entre les divers laboratoires de Chevaleret, via l'Institut Fédératif -> choix politique - réseau math.jussieu.fr environ 600 comptes, dont plus 200 utilisateurs de clients légers moins de 50 Go de $HOME moins de 100 Go de $HOME, scratch, /usr/local, espace Web, miroirs - réseau logique.jussieu.fr environ 10 Go de $HOME - 50 utilisateurs - réseau proba.jussieu.fr et ann.jussieu.fr populations, besoins, volumes mal connus uniquement du miroir de serveurs de production - financement multiple Institut Fédératif chaque laboratoire UFR de mathématiques de Paris 7 - long processus de concertation, de définition des besoins, d'examens de tous les choix possibles, d'annonce du choix, de decision, de financement et d'achat : de debut à fin 2002 (près de 10 mois) Cahier des charges - vu le positionnement politique de l'achat, il avait été choisi de prendre qqch de sérieux, solide, simple, assez évolutif, et dédié avant tout à NFS et permettant de faire des snapshots. - l'aspect SMB et AFP avait été considéré comme second (et envisageable via une machine frontale). - la partie sauvegarde sur bande était incluse, avec une forte volonté de continuer à différencier les $HOME et le scratch. Souhait de garder un logiciel très simple. - une redondance quasi totale mais éventuellement manuelle était souhaitée. - l'alimentation de chaque réseau par une interfacé réseau dédiée était voulue. - dimensionnement visé : 300 à 350 Go nets - un lecteur de bande simple pour commencer - budget envisagé : 30 à 35 KE HT Espace des choix - NetApp : on ne pouvait se payer que le modèle d'entrée de gamme qu'il aurait fallu prendre complet d'entrée de jeu (disques et cartes réseau). Solution chère (30 KE sans le DLT à 10 KE !) possible, mais non évolutive. Mais solution du père tranquille. On a voulu prendre plus pour le même prix, quitte à prendre un peu plus de risques. - à cet époque, Dell venait de supprimer ses baies RAID externes SCSI Le seul fournisseur de ce genre était Transtec, pour des capacités trop grandes et à des prix élevés. Cela a changé depuis : la meme baie HP que celle qu'on a achetée se vend désormais en attachement SCSI. On l'aurait sans doute prise si elle avait existé. - les serveurs avec disques internes hot-plugs (Dell, IBM, HP) ne comportaient pas assez de slots pour une évolutivité raisonnable (les disques SCSI de 140 Go n'existaient pas encore vraiment). On avait aussi un peu peur de la non-indépendance de la partie RAID vis à vis de l'OS, et de la capacité de reconstruction à chaud. - Sun avait des trous importants dans sa gamme. Il n'y avait rien dans notre créneau. - les NAS ou baies RAID en disques IDE ne semblaient pas raisonnables comme solution primaire de stockage. - idem pour les solutions purement intégrateurs en SCSI (Option+, Elonex) - refus des solutions NAS basés sur Windows 2000 comme OS. Choix final - système mixte avec deux serveurs deux baies deux niveaux de sérieux un lecteur SDLT et 20 bandes pour un cout d'environ 35 KE HT - stockage primaire serveur HP Proliant ML 350 G3 - 512 Mo de RAM 1 disque de boot interne 6 interfaces réseau baie externe HP MSA 1000 - 14 slots SCSI hot-plugs attachement Fiber Channel 7 + 3 disques de 72 Go fonction : service NFS uniquement, vers < 10 serveurs Unix - stockage secondaire serveur Option+ avec AMD MP1800 - 512 Mo de RAM baie RAID externe - 8 slots IDE hot-plugs attachement SCSI 8 disques de 80 Go fonction : snapshots - sauvegarde lecteur SDLT 160/320 attaché sur le serveur primaire logiciel choisi : tar - lien Giga optique entre les serveurs - FreeBSD sur les deux serveurs validation de Linux, officiellement supporté par HP, sur le serveur HP -> longue galère de deux mois prise de risque de démarrer sur FreeBSD, avec Linux comme OS de secours, et de management de la baie. - redondance possibilité de mettre la 2eme baie sur le premier serveur et réciproquement possibilite de fournir le service NFS sur le 2ème serveur via les snapshots Mise en production - le seul problème réel a été d'obtenir la bonne version du driver de la carte Fiber Channel (HBA) sous Linux pour le serveur HP. Plus de deux mois, et beaucoup de sueur. - nombreux tests en tous sens, et notamment de reconstruction, d'arret sauvage, des possibilités du logiciel de management qui sera inaccessible en régime de production. - choix fait de faire sur le 1 seul ensemble de disques : 10 disques, dont 1 de spare 1 seul LUN RAID 5 avec 9 disques -> espace égal à 8 fois 72 Go 1 seul filesystem en ufs non journalisé, mais avec softupdates -> 534 Go vus par df - bascule faite le 8 mai 2003 (jour férié) des anciens serveurs de math.jussieu.fr en moins de 6 heures (annonce de coupure totale sur la journée - 1ere de ce genre depuis plus de 3 ans) Bilan depuis la mise en production jusqu'à aujourd'hui pour le serveur et la baie principale - 0 problème de fonctionnement le serveur n'a jamais planté la baie n'a jamais eu de problème logique 0 pb NFS 0 perte de fichiers - performances tout à fait satisfaisantes pour notre usage - 1 panne de ventilateur redondant sur la baie principale réparation à chaud par la maintenance HP - achat de 4 autres disques de 72 Go cela remplit la baie, qui peut s'étendre avec 2 autres racks de 14 disques arrêt pour définition d'un autre LUN RAID 5 (qui partage le meme disque de spare) et donc d'un autre filesystem de 267 Go c'est cet espace que squatte Mathrice actuellement - achat d'un controleur RAID et d'un attachement FC redondant problème de taille mémoire des controleurs -> attente depuis 3 mois suspense dans la mise en oeuvre - mise en place d'une carte RAID pour avoir un système de boot en RAID 1 suspense dans la mise en oeuvre - sauvegarde 'tar' de tout (math.jussieu.fr, logique.jussieu.fr) chaque nuit, avec rotation sur 3 hebdos, 3 mensuelles, archivage de la quotidienne chaque mois à mon domicile on en est à 165 Go de fichiers mis sur la bande DLT 160/320 lorsque le lecteur SDLT sera plein, il aura été bien utilisé, et on en achètera un plus gros -> confirmation du choix judicieux - renoncement à plusieurs reprises d'utiliser la fonctionnalité SAN via le Fiber Channel cout des switches, des Gbics, et des HBA en technologie Fiber Channel hors de prix on a préféré gonfler en disques hot-plugs SCSI avec carte RAID internes les serveurs Windows et VMware il est probable qu'on ne fera jamais de SAN d'où le regret de ne pas avoir pu avoir cette config en attachement SCSI au lieu de FC - impression générale excellente :-)) mais grosse déception devant le professionnalisme d'HP :-(( Bilan depuis la mise en production jusqu'à aujourd'hui pour le serveur et la baie secondaires - problèmes de fonctionnement 1 ventilateur défectueux sur le processeur AMD -> crashes de plus en plus répétés => achat chez Surcouf d'un ventilateur 1 crash du disque IDE miroir du disque IDE de boot -> ouf ... NB : on le faisait par rsync auj. on le fait tjs par rsync mais sur baie SCSI/IDE 0 pb sur la baie IDE, mais 1 disque H.S sur la baie jumelle achetée pour Mathrice fin 2004, au bout de qqs semaines - snapshots via rsync au-dessus de NFS et le lien Giga que sur les $HOME (70 Go) et /var/spool/mail (5 Go) de math.jussieu.fr 5 fois par jour + chaque jour de la semaine + chaque semaine du mois -> 17 versions des $HOME cela occupe grosso modo 2.5 fois l'espace primaire, mais difficile à dire : du est inutilisable. évidemment sensible à des fortes variations des $HOME -> fort suivi du top 40 des $HOME / rappels fréquents sur l'usage de l'espace scratch coup CPU important pour le parcours des arbres de fichiers -> c'est ce qui prend le plus de temps. Environ 50 minutes. très sensible à des ratés ou à des interruptions -> cela entraine qu'on recopie l'intégralité de l'espace primaire :-(( -> nécessité de surveiller cela de près, et d'avoir tout largement de la place sur l'espace prévu pour cela. par rapport à des snapshots filesystem comme chez NetApp, trois avantages - on peut en faire autant qu'on veut à concurrence de son argent : il suffit d'acheter de l'espace IDE/SATA - si qqn fait rajoute 100 fichiers de 10 Go, une fois les snapshot filesystem faits, on n'a pas de moyen facile de supprimer l'espace pris par ces fichers excessifs. Avec rsync, on fait simplement 'rm' - quand la baie primaire est rade, on ne dispose pas non plus des snapshots avec des snapshots filesystem. Alors qu'avec rsync, c'est externe -> ces deux derniers avantages nous semblent un facteur de tranquillité - autres fonctions recopie de fichiers .bkf (issus de NTbackup) complets de nos partitions des serveurs Windows machine centrale d'administration de notre réseau -> c'est elle qui a les clefs SSH pour accéder de root à root partout autres rsync pour d'autres machines en mode "1 instance, avec --delete" - machines de la maquette Mathrice (Chevaleret, Bordeaux) - machines (virtuelles) emath.fr - Lyon, Rouen, Paris 13 - évolution remplacement du PC intégrateur par un HP ML 350 G3 avec carte RAID et disques SCSI en RAID 1 déplacement des rsync de machines extérieures vers la baie Mathrice - impression générale très bonne :-)) les utilisateurs apprécient les snapshots qu'ils peuvent utiliser tous seuls, via un export NFS mais scalabilité limitée (temps de parcours), et pas trop possible pour une population d'usage plus "chaotique" de ces $HOME Commentaires et perspectives - solution bien adaptée à nos besoins - ratio prix, services, volumes, stabilité tout à fait bon - bon sentiment de tranquillité - probablement bien dimensionnée, et qu'on ne fera probablement plus évoluer - sans doute pas bien adaptée à des usages plus conséquents, ou à des $HOME plus volatiles (par la techno des snapshots) - si c'était à refaire, sans doute le meme achat général, sauf pour l'attachement FC (on prendrai du SCSI), vu le prix de la techno FC et le peu d'usage des autres labos, qui ne justifient pas le passage à un vrai SAN. - les 14 disques de la baie HP sont interchangeables avec nos 6 serveurs HP :-)