Chronique d’un SDDC, partie 2 : les fondations

Après, une première partie consacrée à décrire mon projet de SDDC, dans le cadre du vVNX Next Challenge, voici le second chapitre, beaucoup plus opérationnel, celui-là : la mise en place des briques de base du stockage et des outils de haute disponibilité associés. Comme déjà présenté, je vais m’appuyer sur deux solutions software d’EMC : vVNX (la version 3.1.4, sortie très récemment) et la trial de VPlex/VE, en version 2.1. Si vous souhaitez des informations détaillées sur ces deux produits, je vous rappelle que j’ai écrit sur la question ici pour vVNX ainsi que ici et ici pour VPlex/VE.

L’ensemble du sysème s’appuie sur un cluster VMWare constitué par deux serveurs ESXi. Normalement, il devraient être chacun pourvu d’un stockage local suffisant. Malheureusement, les machines sur lesquelles je me suis appuyé n’en disposaient pas, du coup j’ai monté un datastore partagé “classique”, basé sur une connectique SAN, mais cela n’enlève rien à la validité du PoC. Ces deux serveurs tournent donc sur ESXi 6.0u1 et sont gérées par un vCenter 6.0u1 également (dernières versions en date). A noter que toutes les connexions réseau (4 cartes par machines) sont en Gigabit, les transferts seront donc limités par ces débits (On a coutume de dire qu’un lien Gigabit Ethernet peut délivrer, en TCP, de l’ordre de 110 Mo/s pour du gigabit).

La première étape consiste à monter les vVNX de chaque datacenter DC1 et DC2 (référez-vous au schéma que je vous ai présenté dans le premier billet). Histoire d’avoir les meilleurs version de code du projet liberty d’EMC, j’ai découvert une “astuce” : vous pouvez noter sur cette page (la page magique de tous les téléchargements EMC disponibles en trial/free-to-use) qu’il existe deux versions différentes de vVNX : une “classique” en version 3.1.2 proposant les fonctions block/file de la solution et une très récente en 3.1.4 (avec une interface renouvellée) disposant des APIs et code nécessaire pour évaluer vVOL (je vous proposerai un article spécifique à ce sujet bientôt). Ensuite, vous devez entrer un fichier de license correspondant, normalement, à la version que vous souhaitez évaluer. En fait, il se trouve que vous pouvez tout à fait générer un fichier de licence pour vVNX 3.1.2 et l’utiliser dans la 3.1.4. Ce faisant, vous récupérez un code plus récent pour des fonctions block/file. Bon évidemment, pour ce que nous allons exploiter ici (block mode en iSCSI), ça ne changera pas grand chose, mais bon… c’est mon coté geek ;)

L’installation des vVNX ne pose pas de problème particulier. Une fois les licences installées, j’ai rajouté une règle DRS pour forcer les machines vVNX1 pour DC1 et vVNX2 pour DC2 à tourner sur les serveurs ESXi correspondant à leur hébergement nomminal. Enfin, on provisionne quelques centaines de giga de chaque coté pour pouvoir travailler ensuite et mettre à disposition les divers LUNs.

Après la création d’un total de 6 LUNs par vVNX pour le fonctionnement de base des deux clusters VPlex, nous sommes donc parés pour rajouter la couche VPlex/VE par dessus. Je ne vais pas détailler le process, assez lourd, d’implantation de VPlex car je l’ai déjà largement présenté dans les billets dédiés évoqués plus haut, mais comme initialement, les deux solutions vVNX et VPlex/VE se sont très bien accordées l’une avec l’autre et du premier coup !

Au final, on obtient un VPlex/VE en configuration Metro, dont chaque cluster (deux directeurs par cluster) s’appuie sur une vVNX pour obtenir du stockage. Les deux ESXi sont connectés chacun à leur engine via iSCSI.

Pour vérifier que l’on a des performances acceptables pour pouvoir continuer, j’ai procédé à quelques tests rapides. Rappelez-vous tout de même que je me suis basé sur des démonstrateurs vVNX et VPlex/VE, donc évidemment, ils ne sont sans doute pas dans leur configuration “de production” (en particulier les vVNX). De plus, les tests réalisés n’ont pas l’ambition ni d’être exhaustifs, ni même de constituer un étalon fiable : les conditions et le matériel peuvent largement influer sur le résultat, comme on va le voir.

J’ai réalisé le premier test brut via VPlex/VE directement. Lorsque vous créez un volume distribué, vous pouvez le déclarer comme consistant dès le début, auquel cas, VPlex considère les deux “pattes” (two legs in English ;) ) comment déjà synchro et place de volume dans l’état cohérent. Mais vous pouvez aussi le déclarer comme étant constitué initialement d’une patte source à copier sur la seconde patte. Cette opération déclenche une re-synchro totale du LUN source vers le LUN destination. C’est précisément cette opération que j’ai réalisé. Dès la création, les deux vVNX ont donc été très sollicitées par des IO larges et séquentielles. Comme un métronome, VPlex à réalisé son opération à une moyenne tout à fait satisfaisante de 70 à 80 Mo/s (avec un transfer-size à 32M). Ca parait peu, certes, mais rappelez-vous que nous sommes limités par nos cartes réseau Gigabit ;) . Pendant cette phase, j’ai regardé un peu les stats via les outils disponibles sur les vVNX. Voila ce que ça donne :

Ce qui est notable ici c’est l’utilisation CPU (2 vCPU par VNX), elle reste très raisonnable, augurant le meilleur si j’avais eu du 10 Gbit à dispo sur le vLab :)

Ensuite, J’ai procédé à des tests via l’indécrotable IOmeter, lancé sur une banale petite VM Windows 7 bi-vCPU hébergée sur un datastore fourni par VPlex/VE. La encore, on obtient globalement des bon résultats. Voici deux tests particuliers : le premièr est constitué d’un pattern de 100% de lectures dont 50% sont aléatoires, on dépasse les 3000 IOps et un taux de transfert moyen de plus de 100 Mo/s ; le second est un full write avec 50% d’aléatoire et toujours des blocs de 64k, on tombe à 300 IOps, à un peu plus de 20 Mo/s. Même si ce n’est encore une fois qu’un petit essai, cela donne une idée du potentiel “production” des solutions employées.

Ce qui est aussi intéressant, c’est de constater le comportement des ESXi pendant ces phases de test. On remarque en particulier des paliers sur les IO réseau : en fait, des paliers très très plats, souvent synonymes de saturation “physique”. Et le fait est que c’est souvent le cas… gigabit oblige ;) . De même, pendant ces tests, un petit vMotion a permit de voir les IO passer d’un ESXi à l’autre… c’est logique, prévisible, mais depuis que je fais du VMWare, cette techno m’a toujours autant bluffé !

J’ai noté aussi pendant certaines phases de lecture intensive que, curieusement, les vVNX n’étaient quasiment pas sollicitées. En fait, je pense que le cache des directeurs VPlex étaient à l’oeuvre derrière ce mystère apparent ! Malheureusement, VPlex/VE étant amputé des fonctions intégrées de supervision et monitoring de son grand frère, je n’ai pas pu le vérifier.

Au final, ces petits benchs m’ont au moins permis de valider que la solution montée était fonctionnelle et fiable et que l’on va pouvoir envisager d’héberger quelques VM dessus pour aller plus loin dans ce projet ;)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *