Un point sur les performances du couple VPlex/XtremIO après un an de production

MAJ du 7/08/2015 : beaucoup de corrections d’orthographe … désolé !

Nous utilisons massivement VPlex au sein de notre production depuis Juin 2012, bien avant l’explosion du marché des AFA et l’acquisition d’XtremIO. Il est vrai que la technologie de virtualisation du stockage d’EMC a été taillé pour soutenir des baies très performantes coté back-end, heureusement ce qui nous a permis d’y intégrer nos nouvelles baies XtremIO sans problème. Le fait est qu’au départ, nous étions malgré tout curieux de pouvoir comparer les performances exceptionnelles de l’AFA d’EMC en terme de latence via des connexion FC directes, une fois son intégration réalisé à travers des volumes VPlex.

Il est logique de vérifier qu’un outil de virtualisation du stockage comme VPlex ou IBM SVC, par exemple, n’a pas, par sa présence, un impact significatif et a forcieri visible des utilisateurs sur les performances applicatives. Sur ce point, à l’époque, EMC avait été très confiant vis à vis de nos questions à ce sujet, mais le doute subsistait. Le PoC XtremIO réalisé en Juin 2014 chez nous a levé une grosse partie des inconnues sur le fonctionnement de ce couple.

Ceci étant, après presque une année de production VPlex/XtremIO pour notre TIER1 (déjà ! le temps passe vite …), je vous propose de revenir sur notre expérience en la matière et surtout les choix d’architecture que nous avons réalisé pour garantir au maximum l’indépendance des silots TIER1 et TIER2.

Notre architecture aujourd’hui est basée sur trois niveaux de tiering, correspondant à 3 niveau de qualité de service et de protection des données hébergées (voir ici pour les détails). Nos ressources financières ne nous permettant pas d’investir dans un nouvel engine VPlex dédié au TIER1, nous sommes donc resté sur notre VPlex Metro “mono engine” servant les ressources de deux ensembles back-end différents, le TIER1 XtremIO et le TIER2 VNX 7500. Il a donc fallu trouver une solution pour limiter l’impact d’un TIER sur l’autre malgré le partage d’un seul composant de virtualisation du stockage. Nous avons choisi pour se faire de spécialiser chaque directeur de chaque cluster VPlex Metro à l’activité d’un TIER particulier. Tous les hosts exploitant le TIER1 utilisent donc des chemins FC prioritaires vers le directeur1 tandis que les hosts exploitant des ressources sur le TIER2 sont dirigés vers le directeur2 (et ce sur chaque cluster VPlex évidemment). De même, les ports FC back-end et front-end sont spécialisés.

En cela, on a essayé de respecter à la lettre les recommandations du guide de production XtremIO/VPlex d’EMC (à lire absolument si vous avez un projet de ce type dans les cartons). D’ailleurs, certains chapitres de ce document confirment la très bonne tenu de VPLex+XtremIO par rapport à un XtremIO seul et connecté directement à ses clients.

Dans la pratique, si l’on constate, comme attendu, des temps de latences XtremIO de l’ordre de 500 microsecondes coté back-end (que ce soit en lecture ou écriture… magie e l’AFA ;) ), les prises de statistiques coté serveur une fois le VPlex traversé nous donne des accès moyens en lecture de l’ordre de de 700 à 800 microsecondes en écriture et environ 500 à 600 microsecondes en lecture. Effectivement, il faut rappeler ici que VPlex utilise systématiquement le write-through pour les écritures (écriture directe, sans mise en cache), ce qui explique cet écart entre les deux type d’I/O.

Coté consommation de CPU sur les VPlex, il clair par contre que nous avons vu une vrai évolution avant/après vis à vis de l’implantation d’XtremIO avec une augmentation moyenne de 10% environ. Ce n’est pas énorme, mais c’est notable. Nous interprétons cette légère augmentation comme le résultat de la réactivité d’XtremIO. Les VPlex passent beaucoup moins de temps à “attendre” le retour des I/O soumises au back-end TIER1 et sont donc mécaniquement plus sollicités. En gros, XtremIO donne un travail plus régulier aux directeurs ;) . Il est possible aussi que cette évolution soit pour partie le résultat d’une augmentation normale de notre activité de production, par contre, difficile d’évaluer précisément la part de chaque composante.

Aujourd’hui, l’activité de nos VPlex est assez importante mais toujours aussi prévisible et conforme aux engagements de la plate-forme :

De même nos briques XtremIO assurent leur rôle de support de stockage “sans compromis”, à tel point que beaucoup d’applications non critiques et docn, en temps normal, non éligibles au TIER1 tapent à la porte pour malgré tout être “élues”. Nous sommes obligés d’être assez selectifs pour le moment car malgré la déduplication et compression inline des baies, leurs capacités ne sont pas illimités et nous n’envisageons pas encore leur extension via l’ajout d’une deuxième X-Brick (sans doute d’ici 2 ans) :

… afin de mettre en perspective les ratios présentés ici, rappelez-vous que notre production TIER1 est composée de bases de données transactionnelles, de machines virtuelles de type serveurs d’applications, ainsi que de l’ensemble de notre production Citrix XenApp (180 serveurs virtuels).

Vu l’engouement vis à vis des AFA aujourd’hui et les baisses de prix régulières constatées sur ce segment de marché, il est clair que la donne va changer dans les prochaines années. Il n’est pas impossible que notre TIER2 soit petit à petit phagocyté par le TIER1. Il ne nous resterait à terme qu’un stockage primaire full flash pour la production à haut niveau de disponibilité et de performances, accompagné par un nouveau TIER2 basé sur du SDS et du commodity hardware (VSAN ou ScaleIO, par exemple).