vendredi 17 juin 2011

Quand trop de cache dans le stockage tue la perf ...

Depuis l'avènement du disque SSD, on assiste à une inflation considérable du cache "marketing" dans les baies de stockage : on nous annonce parfois jusqu’à plusieurs To rien que ça, mais avec des disques SSD à minima en mirroring pour prévenir une casse toujours possible du fait de la longévité moindre de ce type de média. Pourquoi donc ?


Et bien, l'apport de cette technologie salvatrice permet de soulager les traditionnelles têtes contrôleurs, par ailleurs déjà bien occupées à gérer les migrations de données et autres dialogues avec les serveurs, afin de fluidifier la descente des données sur les disques pour éviter les a-coups générateurs de temps de réponse parfois un peu longuet (on dit latence dans le jargon)

Chez Pillar, depuis la genèse le cache a toujours été conséquent puisqu’étant initialement fixé à 24 Go de DRAM dans les AXIOM 500, il est passé à 48Go de DRAM dans les actuels 600. Cependant, aujourd'hui on pourrait se dire : ah ben tient ? ils sont à présent dépassés ... Que nenni !






Dans le tableau ci-dessus, on s'aperçoit que la DRAM ira 1000 fois plus vite que le plus rapide des SSD. Pour rappel un stockage Axiom Pillar Data n'utilise exclusivement qu'un ensemble de contrôleurs RAID matériels distribués 20 fois plus rapides que le traditionnel RAID ou les pools gérés logiciellement chez les concurrents. Du coup, l'écriture étant réalisée beaucoup plus rapidement, il n'y a pas nécessité d'un gros cache complété voir ralenti par du SSD. Accessoirement moins de cycle d’horloge CPU seront consommé : CQFD !


Résultat constaté il y a quelques jours sur un AXIOM 600 doté de 6 briques soit 72 disques SATA , connecté à un serveur en double attachement FC 2gb/s, le tout réalisé devant témoins :






IOMETER : 100% random, 30% write, 70% read, 64 x 500 transactions



Ne pleurez pas, ce n'est pas grave ; imaginez simplement ce que Pillar Data vous permettrait de réaliser avec votre SI. Songez-y lors de votre prochaine acquisition :)Lien

2 commentaires:

Anonyme a dit…

Je suis tres etonne que les block de 1, 4, 8KB donnent plus d'IOPS que les blocks de 512B... D'habitude le block de 512B permet de tirer le maximum possible d'IOPS d'un storage sachant bien que cette taille de block est raremment utilisee en 'real life' bien sure mais ca permet d'etablir une base de performance IOPS...

dunestudio45 - DS45 a dit…

C'est peut-être ça le problème avec les baies traditionnelles quelle taille de bloc utilise par Windows ou Linux ?

Bon a savoir, on peut aussi utiliser des tailles de blocs physique a 1 mo avec un profil oracle ou vmware