Architecture vPlex Metro / VMWare de notre environnement de production

A l’occasion de nombreuses rencontres et séminaires (EMC Forum, VMWorld etc. …) j’ai plusieurs fois eu l’occasion de décrire notre environnement de production VMWare, basé sur les technologies classiques de vSphere 5 mais aussi (et surtout ;) ) sur le couple EMC VPlex et EMC VNX. Il était temps de vous en faire un portrait simplifié dans ce blog.

Voici l’architecture synoptique qui présente globalement notre infrastructure de production VMWare :

vplexmetro

Ce système a été mise en place progressivement à partir d’une infrastructure beaucoup plus classique et historique, basée sur MirrorView Synchrone et des baies CX4 à l’époque. La migration elle-même a pris environ 6 mois, entre la signature du bon de commande VPlex Metro et la fin de sa mise en production. Si vous souhaitez plus de détail sur le déroulement et la MCO de cette infra depuis plus d’un an maintenant, rendez-vous sur ce billet.

Notre production s’articule donc principalement sur les fonctionnalités de cache cohérent distribué de VPlex Metro. Nous utilisons actuellement 2 engines (un par datacenter, largement suffisant pour nos besoins en I/O) qui servent un certain nombre de serveurs ESXi, répartis équitablement sur nos deux DC. Notre cahier des charges actuel, posée par la direction de notre institution, est de disposer d’une capacité globale de production virtualisée au moins équivalente à 200% de la charge maxmimale constatée au quotidien, que ce soit au niveau CPU, mémoire ou IOps.

Nous utilisons aussi, vous le voyez, la fonctionnalité cross-connect, qui permet de palier à une “disparition” temporaire ou définitive d’un de nos deux engines VPlex. D’autres part, en cas de problème majeur sur un de nos deux DC, nous utilisons conjointement les fonctionnalités de maintient de la production I/O par le VPlex restant et le déclenchement “HA” coté VMWare pour redémarrer les VMs ayant disparu sur la première salle. Cette fonction a été évaluée et validée initialement lors des tests unitaires et nous l’avons, malheureusement, déjà éprouvé en production, à cause d’un problème de liaisons optiques entre nos deux DC.

Coté stockage, les deux back-end s’ignorent proprement, étant donné que ce sont les VPlex qui assurent le mirroring synchrone des données. A ce sujet, nous utilisons à la fois les datastores VMFS classiques et, pour certains environnements spécifiques, des Raw Devices sur les VMs. Tout cela passe évidemment par les VPlex.

Vous noterez enfin que nous disposons d’un trosième site sur lequel nous avons implanté le VPlex Witness, afin d’être dans les meilleures conditions pour confirmer les choix des engines vis à vis de pannes diverses (détermination du winner et looser notamment, quel que soit le cas de figure). Ce Witness est une petite VM connectée en IP aux deux VPlex.

Si vous avez des questions complémentaires, n’hésitez pas à m’en faire part, j’enrichirai cette présentation avec mes réponses, dans la mesure de mes compétences évidemmment ;)

3 thoughts on “Architecture vPlex Metro / VMWare de notre environnement de production

  1. Gael says:

    Bonjour,

    Nous disposons exactement de la même architecture dans notre institution localisée dans le sud.
    Pourriez vous me détailler votre gestion du multipathing au niveau des hyperviseurs svp?

    De notre coté, nous utilisons le multipathing natif d’ESXi en mode de sélection de chemin “Fixed”. Le paramétrage de cette partie étant lourde, nous l’avons scripté.

    Merci d’avance.

    • Cédric Cédric says:

      Bonjour,

      Même chose chez nous, du gros scripting sur une VMA (shell et perl). D’ailleurs j’avais publié un billet à ce sujet il y a quelques semaines ici.

Répondre à Gael Annuler la réponse.

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