Le 16/07/10 14:51, Charles a écrit : > faudrait trouver les présentations de la réunion frnog hiver 2009 il y > avait une belle présentation ssd...
Belle présentation... Ou pas. Il n'as pas répondu aux questions, et son
cas d'utilisation n'a pas grand chose à voir avec ce qu'on a en hébergement.
Petit récap donc de discussions précédentes :
- Il y a trois types de SSD Flash
* Les SATA à base de MLC à destination du grand public : fiabilité
réduite, rapport perf/prix très intéressant
* Les SATA ou SAS pro : prix élevés mais un peu plus fiables que les
SSD grand public. Quoique les vieux MTRON se sont montrés peu fiables...
* Les SSD spécifiques, généralement sur PCIe, chers mais
potentiellement conçus pour l'usage serveur (Fusion-IO, pas OCZ)
- Et les SSD RAM, qui n'ont pas les mêmes contraintes et applications
car ils sont volatiles mais ne s'usent pas.
- On ne peut pas considérer un SSD sous contrainte d'IO (écriture en
tout cas) comme étant fiable a l'heure actuelle. Il doit forcement être
complété par de la réplication ou une architecture logicielle adaptée.
- En terme de performances, ça décoiffe, c'est indéniable. Que ce soit
pour servir des fichiers statiques en HTTP, pour stocker un snapshot
courant d'une base de données (en RO ou RW si toutes les dispositions
ont été prises), ou pour du streaming à whatmille sessions simultanées
sur le même fichier, ça permet de réduire significativement les IO WAIT
et donc d'augmenter par un facteur 10 à 500 le nombre de clients servis
simultanément par une machine (hors architecture proprio, spécifique, ou
plus dépendante du réseau ou du CPU que du stockage).
Donc quelques conseils :
- Ne JAMAIS remplacer simplement les HDD par des SSD si l'architecture
n'est pas basée sur des noeuds "jetables".
- Adapter le SOFT à l'utilisation des SSD (réplication logique,
multi-DB) ou au moins au niveau système (clustering, réplication en GFS
ou clustering de la DB)
- Surveiller de près les erreurs d'IO, surtout sur du SSD grand public,
pour prévenir d'un raté.
- Bien bencher TON usage avant de déployer en prod, avec certains moteur
de base de données ou certaines conf système, ça ne vaut pas la peine de
s'emmerder avec du stockage hétérogène. Typiquement, de l'Oracle sur des
machines en SAS 15krpm gavées de cache et de RAM ne bénéficiera
quasiment pas des SSD, le moteur est optimisé pour les "standards".
L'intérêt, en suivant toutes ces bonnes pratiques, et si l'application
initiale s'y prête bien, c'est que tu peux effectivement tabler sur de
grosses économies en nombre de serveur, et donc en énergie.
Simple indication, sur un site de VPC servant un peu de vidéo et
beaucoup de static, avec une énorme base produit en (quasi) RO, on a
ainsi pu passer de 40 machines à... 8. Et tout est doublé.
Le ROI est finalement hyper rapide, pour peu que ce soit bien fait ;)
--
Jérôme Nicolle
signature.asc
Description: OpenPGP digital signature
