SPC-1, a-t-il un sens ?

Il y a quelques jours, lors de l'Oracle Open World qui s'est déroulé à San Francisco, Oracle et Sun ont présenté une configuration qui détient le record aux tests SPC-1. La configuration mise en avant coûte la bagatelle de ... 22 Millions de $. On est loin de ce que peut se payer la majorité des entreprises aujourd'hui, surtout en ces temps de crise économique, d'autant que les entreprises qui recrutent ou qui maintiennent l'emploi sont les PMEs. Bien entendu, on peut comprendre qu'il est difficile pour ces dernières de monter un benchmark bien qu'elles aient conscience qu'il leur faille un système d'information évolutif et performant. Accepteriez-vous d'attendre 10 minutes pour l'ouverture d'un fichier Word ? Le stockage y prend donc une part prépondérante.
Ne serait-il pas judicieux plutôt que de ne s'appuyer que sur des critères purement techniques, d'y adjoindre une once de cadre économique réaliste. Par exemple, qu'est-ce que je pourrais espérer pour un budget de 10, 25, 50, 100, 250 k€ tout en prenant en compte la facilité d'administration et la dimension emprunte carbone chère à nos élus.
Récemment, l'un des mes amis m'a indiqué un thread dans la communauté VMware WorldWide : Unofficial storage performance thread http://communities.vmware.com/thread/73745 et http://communities.vmware.com/thread/197844 L’objet est d'y comparer de manière amicale, les performances des différents stockages mis à disposition chez chacun d’entre nous grâce à l’outil open source et reconnu iometer (www.iometer.org). J'ai donc joué le jeu en m'appuyant sur les critères suivants :

- Notre environnement étant totalement virtualisé, il n’a pas été possible de tester les performances depuis une machine physique. Tous les tests se sont déroulés en environnement virtuel au sein d’un serveur hébergeant VMware vSphere, soit le cas le plus défavorable.

- Pillar se disant performant sans optimisation particulière, il m’a semblé intéressant de travailler sur notre configuration la plus petite à savoir un AXIOM 500 équipé d’un Slammer SAN ISCSI/Fiber Channel et de trois briques comprenant 30 disques SATA II d’une volumétrie unitaire de 500 Go pour un total de 16 To utiles

- Pour ne pas tirer parti de la configuration la plus favorable pour Pillar, j’ai créé un LUN avec le SLA (QOS) en mode ARCHIVE soit le plus faible et sans privilégier ni lecture ni écriture dans le cache (I/O Bias). Pour faire simple, respectant la philosophie prônée par Pillar, le LUN a été créé en 6 clics souris sans tunnig particulier sur le SAN ni sur vSphere ni dans la VM. Pour être complet, parmi les éléments à mettre en perspective et qui vont dans le sens de l’entreprise visant à diminuer son emprunte carbone, j’ajouterai que la baie en question ne consomme que 680w soit la puissance d’un serveur simple supplémentaire.

- La machine virtuelle a été crée avec 1 vCpu et 1Go de ram et supporte le système d’exploitation Windows 2008 R2 sans optimisation particulière. Le serveur hôte est un SUN FIRE X4170 bi-processeurs à la fréquence de 2.5Ghz hébergeant 24 Go de RAM équipé de 4 ports gigabit Ethernet et d’une carte Fiber Channel 4 Gb/s Qlogic bi-canal 2432. La configuration a été paramétrée en fail-over et non en load-balancing, paramètre permettant arbitrairement de doubler la vitesse d’accès et de masquer les vrais performances des accès aux disques proprement dits.

- Du point de vue prix, nous sommes dans la tranche des 100k€, en fait 95k€ pour un Pillar d' une volumétrie utile nette de 16 To.

Les options d’accès proposé par le team ont été paramétrées comme il se doit :

The global options are:
=====================================
Worker
Worker 1
Worker type
DISK
Default target settings for worker
Number of outstanding IOs, test connection rate,transactions per connection : 64,ENABLED,500
Disk maximum size,starting sector
8000000,0

La durée du test a été fixée de la même manière à 5 minutes. Cela permet de stabiliser les I/Os du stockage et d’avoir une moyenne fiable.
Run time = 5 min

Test de débit maximum, le plus favorable :

######## TEST NAME: Max Throughput-100%Readsize,% of size,% reads,% random,delay,burst,align,reply32768,100,100,0,0,1,0,0

Le test ‘Real Life’, ce que l’on expérimente tous les jours dans la vraie vie :

######## TEST NAME: RealLife-60%Rand-65%Readsize,% of size,% reads,% random,delay,burst,align,reply8192,100,65,60,0,1,0,0

Le debit façon copie de fichiers :

######## TEST NAME: Max Throughput-50%Readsize,% of size,% reads,% random,delay,burst,align,reply32768,100,50,0,0,1,0,0

Le debit façon accès à une base de données transactionnelle

######## TEST NAME: Random-8k-70%Readsize,% of size,% reads,% random,delay,burst,align,reply8192,100,70,100,0,1,0,0

Voici les résultats que j’ai soumis sur le forum VMware Corp :

SERVER TYPE: VM Windows Server 2008, 1GB RAMCPU TYPE / NUMBER: 1 VCPUHOST TYPE: SUN X4170, 24GB RAM, 2.5 GHz, Dual XEON NEHALEMSTORAGE TYPE / DISK NUMBER / RAID LEVEL: PILLAR DATA SYSTEMS AXIOM 500 (24 GB CACHE / 8 Ctrl) / 30 x SATA 7200 RPM /R5 SAN TYPE / HBAs : 1 x FC 4, QLOGIC 2432 using single path

##########################################################

TEST NAME----------Av.Resp.Time ms---Av.IOs/se---Av.MB/sek------##########################################################
Max Throughput-100%Read....5.4486........ 10965........ 342.67 CPU=21%
RealLife-60%Rand-65%Read...1.4193......... 34207........ 286.78 CPU=47%
Max Throughput-50%Read.....4.7475..........12176........ 379.71 CPU=24%
Random-8k-70%Read...........1.3620........ 34443......... 300.25 CPU=46%
#########################################################

Ce qui est remarquable c'est que les résultats en terme de débit, le temps d'accès aux informations que vont ressentir les utilisateurs :), sont homogènes quelque soit le type d'accès.

Cela signifie d’une part que la baie possède encore largement la performance capable d’accompagner les évolutions applicatives de l’entreprises, que sa baisse de performance pourra être prédictive tout en ayant la possibilité d’y remédier au plus juste par le strict ajout tiroirs de disques supplémentaires permettant de retrouver les SLAs attendus, voir par ajout d’un contrôleur d’interconnexion appelé Slammer qui permet de démultiplier encore la performance.

Bien entendu, les esprits chagrins dirons : oui, mais on travaille dans le cache de la baie, le test ne serait pas aussi significatif avec 200 Go ... Alors pourquoi ne pas le faire avec 100 To tant qu'on y est ? La volumétrie modifiée quotidiennement chez nous hors vidéo est de 35Go, en fait à peine plus que le cache.

Pour vous éviter de remonter au début, je redonne les liens pour comparer les résultats avec ceux de nos confrères :

http://communities.vmware.com/thread/73745 et http://communities.vmware.com/thread/197844