Mise en place d’un PoC VPlex/VE (partie 2)

Après un premier billet consacré à l’installation de VPlex/VE proprement dit, je vous propose de découvrir maintenant son utilisation à travers les outils dédiés proposé par EMC. Nous évoquerons aussi, sans trop détailler malgré tout, les grandes étapes nécessaires coté ESXi pour pouvoir connecter correctement un LUN iSCSI de VPlex/VE et s’en servir de datastore.

Introduction

Quand on connait la solution VPlex historique basée sur des composants physiques, la première chose qui saute aux yeux, c’est que vous ne disposez pas de console Unisphere for VPlex ! Certes, étant adepte de la ligne de commande, je ne suis pas un gros consommateur de la console web, mais malgré tout, je m’interroge encore sur le pourquoi de cette restriction. De mon point de vue, c’est LE point noir de VPlex/VE comparé à son grand frère. En effet, une fois l’installation terminée, si vous tentez de vous connecter à l’un des deux management server, vous atterrirez immanquablement sur cette page :

… frustrant :) ! En lieu et place, VPlex/VE vous a installé automatiquement un plugin pour la console web-client de votre vCenter, que je vous propose de découvrir d’ici quelques lignes. Mais que les allergiques aux clicodromes, comme moi, se rassurent : l’accès vplexcli est toujours là ! Et après une petite connexion classique via ssh, on retrouve ses marques très rapidement. D’ailleurs, pour être complet, sachez qu’après ma première installation réussie, je n’ai pas pu utiliser le plug-in vCenter à cause d’un problème spécifique à mon serveur VMWare. Il a donc fallut que je passe directement en mode console pour pouvoir avancer. Au final et pour les besoins de ces articles, je me suis attelé à résoudre mon souci spécifique VMWare pour pouvoir vous montrer l’intégration VPlex/VE dans la console web-client.

Découverte des fonctions VPlex/VE intégrées à VMWare

Après connexion au web-client vCenter, vous noterez qu’une nouvelle icône apparait dans votre page d’accueil :

… Une fois dans la section VPlex/VE, vous disposez de 3 contextes dédiés “Systems”, “Storage Arrays” et “Maintenance”. La partie “Systems” vous permet d’ajouter votre/vos VPlex/VE et éventuellement de modifier les IP publiques des management server. La partie “Storage Arrays” concerne la gestion des connexions “back-end” de votre VPlex. La première chose à faire est donc d’ajouter le VPlex :

… ensuite, vous pourrez vous rendre dans la section Storage Arrays pour découvrir les baies iSCSI présentes et lancer des phase de découvertes (en cas de présentation d’un nouveau LUN, par exemple :

… et c’est tout ! La partie maintenance n’est présente que pour vous permettre de collecter des logs de diagnostic ainsi que de suivre une phase d’upgrade éventuelle.

Pour la partie opérationnelle, c’est tout aussi “light”. Dans la section storage de vCenter, vous disposez d’une action contextuelle supplémentaire vous permettant de provisionner un datastore distribué. Voici les captures d’écran d’une séquence de création d’un de ces datastores :

A noter qu’il n’est pas possible de créer, via l’interface, de datastores ne reposant pas sur des distributed devices, ni de proposer du raid-1 local.

Au final, les fonctions sont simples, voir simplistes, très intégrées à vCenter et relativement explicites. Ceci étant, il n’est nul part présenté les concepts spécifiques à VPlex et leur puissance : distributed devices, storage views, virtual volumes, extents etc. … En fait, techniquement, tout cela existe, mais tout est caché à l’administrateur et est automatiquement géré via les outils présentés plus haut.

Pour un techno-geek-bidouilleur-professionel comme moi, je ne vous cache pas que je suis assez déçu par cette intégration. Quitte à supprimer la console Unisphere for VPlex, j’aurais au moins imaginé qu’on avait a peu de choses près l’équivalent intégré à vSphere. En outre, il ne semble pas, d’après la FAQ d’EMC, que la version officielle, non trial, soit mieux lotie à ce niveau là. Alors, comme souvent, les roadmaps d’EMC sont toujours compliquées à obtenir mais gageons qu’il y aura sans doute des améliorations de ce coté là, notamment lors de l’intégration probable de ce produit à la suite ViPR.

Et vplexcli alors ?

Après une vraie déception du coté des fonctions web, qu’en est-il de la partie plus underground du vplexcli. Et bien … bonne nouvelle : toutes les fonctions sont là, et même plus ! Il existe tout un jeu de commandes spécifiques à VPlex/VE autour de la gestion des composants virtualisés ainsi que pour gérer la partie iSCSI, absente de l’édition FibreChannel, évidemment :

Par exemple, vous pouvez directement utiliser les commandes configuration virtual unregister-vsphere-plugin et configuration virtual register-vsphere-plugin pour supprimer et réintégrer le plug-in vSphere … cela m’a aidé dans la résolution de mes problèmes initiaux ;)

D’autre part, toutes les hiérarchies habituelles (clusters, storage-elements etc, etc…) sont là et les concepts associés toujours accessibles. Comme déjà évoqué, ma première tentative d’installation réussie m’a conduit à directement me plonger dans le vplexcli. J’ai donc fait l’exercice complet de préparer un distributed device à la main, sans l’aide de l’interface web. Je ne vais pas détailler cette partie, mais sachez que toutes les habitudes que j’ai prise sur VPlex ont été parfaitement reproduites dans VE : claiming des storage-volumes, création des extents, devices, montage des distributed devices, virtual volumes. Du coté des storage view, il a fallut découvrir aussi le fonctionnement (somme toute très proche de son équivalent FC) des commande d’enregistrement d’initiateurs. En substance, un administrateur VPlex habitué à la version physique, moyennant utilisation de la ligne de commande (ou des API REST, elles sont également là) ne sera pas perdu.

Un petit mot autour du setup iSCSI coté ESXi

N’étant pas familier du iSCSI (en production tout du moins), j’ai un peu tatonné au départ quant il a fallut créer des adaptateurs logiciels pour que les ESXi se connectent correctement à VPlex. Cela n’a pas posé de difficulté particulière, mais j’ai du d’abord “apprendre” les bonnes règles VMWare pour utiliser ce protocole. Une chose à savoir, notamment, est qu’un adaptateur iSCSI ne peut être connecté au réseau qu’à travers un vSwitch, les dvSwitchs n’étant pas acceptés (avec vSPhere 5.5U2 en tout cas).

Une fois l’adapteur iSCSI configuré et connecté au bon VLAN, j’ai donc ajouté les IPs de chaque directeur VPlex pour le site concerné (4 IPs par site, donc). Ensuite, que ce soit manuellement (via vplexcli) ou automatiquement via le plugin vSPhere, j’ai pu sans problème provisionner des LUNs et les formatter comme il se doit.

Conclusion

Pour résumer et pour le moment : du très bon avec la procédure d’installation et la mise en oeuvre générale, du pas terrible voir insuffisant avec le plug-in vSphere et de l’excellent avec le vplexcli.

Dans l’ensemble ce VPlex/VE reste une très bonne surprise pour moi et il est clair qu’un outil de ce calibre sur des configurations “modestes” (pour une version production, EMC exige quand même pas moins de 8 serveurs ESXi … voir ce billet à ce sujet) peut être un excellent moyen pour mettre en place une très haute disponibilité accessible en terme de prix et potentiellement du même niveau qu’un VPlex physique, en tout cas sur le papier. Son intégration probable à la suite ViPR, qui fait sens, va sans doute le rendre plus visible et donc désirable pour les clients potentiels.

La version “Trial”, quant à elle est tout simplement parfaite (hormis l’absence d’Unisphere for VPlex …. je suis chafouin :D) pour de la formation ou du test. Du reste, j’envisage plus que fortement à intégrer ce produit officiellement dans nos environnements de bac à sable. Dommage que cette version ne soit pour l’instant pas utilisable avec ViPR. J’ai tenté de l’intégrer, mais ViPR refuse de le voir à cause d’une incompatibilité de version :

… je vais essayer d’en savoir plus grâce à mes contacts EMC (Emmanuel, si tu me lis … ;) ).

Enfin, pour terminer, sachez que je vais aussi essayer de mener quelques benchs sur la plateforme, notamment en terme d’IOps (sachant que les 2 VM NAS OpenFiler que j’ai monté pour le back-end utilisent une de nos baie XtremIO comme source, je n’ai donc aucune inquiétude particulière sur un éventuel goulot d’étranglement au niveau du physique ;) ). Je vous ferais un retour à ce sujet via un troisième billet spécifique. EMC annonce, en théorie, jusqu’à 20.000 IOps par vDirector… on verra cela !