Nouveautés de VMware Data Recovery 2.0

Avec la sortie de vSphere 5, VMware en profite pour sortir la version 2.0 de Data Recovery (VDR).  Pour rappel VDR est une solution de sauvegarde des VM à chaud capable de faire de la déduplication. La licence VDR est fournit dés la version standard (depuis l’update 1 de d’ESXi 4.1) de vSphere.

VDR se présente sur sous la forme d’une appliance a déployer dans l’infrastructure et d’un plugin à intégrer au vSphere Client.

La précédente version (1.2) était la première étape pour remplacer VCB. Malgré ses qualités, le produit montre de nombreuses limites et problèmes de performance liés à sa jeunesse.  Par exemple, pour sauvegarder sur un partage Windows (CIFS), il est recommandé que le volume de destination ne dépasse pas 500Go (sous peine de voir les performances s’effondrer).  Si le contrôle d’intégrité quotidien tombe en erreur, il est impossible de sauvegarder ou de restaurer des données car le magasin de données est verrouillé.

VMware a réparé le tir grâce à VDR 2.0 dont voici les nouveautés :

• Possibilité de suspendre un job sans affecter les autres
• Possibilité de définir une  fenêtre de maintenance
• Modifier la périodicité du contrôle d’intégrité
• Choix de la sauvegarde du swap des VM
• Génération d’un reporting par email
• Amélioration des performances de la déduplication via l’utilisation de nouveaux algorithmes
• Passage en 64bits de l’appliance VDR pour une meilleure utilisation des ressources
• Exclusion de la sauvegarde des swaps des VM Windows et Linux par défaut
• Correction de bugs : blocage sauvegarde CIFS, …

Pour l’instant VDR 2.0 n’est disponible que pour vSphere 5.0. En attendant de faire les premiers tests, il semble que , sur le papier, VMware est entendu les remarques des utilisateurs.

Pour plus d’informations concernant les nouveautés, je vous invite à consulter la documentation: http://www.vmware.com/files/pdf/techpaper/Whats-New-VMware-Data-Recovery-20-Technical-Whitepaper.pdf

Estimer le nombre de licences vSphere 5 nécessaires pour migrer une infrastructure existante : vSphere Licensing Advisor 1.0

La nouvelle mouture de vSphere sort aujourd’hui. Elle apporte avec elle de nombreuses évolutions techniques. (http://www.vmware.com/products/vsphere/upgrade-center/overview.html). Une autre évolution (pas forcément attendue avec impatience) arrive avec vSphere 5.0 : le nouveau système de gestion des licences.
Pour comprendre les changements, je vous invite à consulter le document officiel : http://www.vmware.com/files/pdf/vsphere_pricing.pdf.

Pour résumer :

• Il faut toujours 1 licence par CPU.
• L’édition Advanced disparait. Les licences vSphere 4 pourront être migrées en vSphere 5 enterprise.
• Le nombre de core par CPU n’est plus limité selon l’édition.
• Le nombre de vCPU par VM est limité par l’édition.
• Les nouvelles fonctionnalités ne sont disponibles que dans l’édition enterprise plus.
• Une licence donne droit à une quantité de vRAM (mémoire configurée) :

License Type	Essentials	Essentials Plus	Standard	Enterprise	Enterprise Plus
vRAM Entitlement per License	32GB	32GB	32GB	64GB	96GB

Pour nous aider à nous retrouver dans toutes ces nouveautés, VMware met à notre disposition un outil nommé vSphere Licensing Advisor. (disponible sur cette page).

Cet outil se connecte sur l’infrastructure existante et estime la quantité de mémoire configurée utilisée et la quantité de mémoire configurée utilisable dans le cas du licensing vSphere 5.

Pour utiliser l’outil, saisir les infos de connexion aux VCenter.

L’utilitaire récupère les informations nécessaires.

Un rappel sur les règles de calcul est affiché.

Voici le résultat :

La colonne vRAM Used correspond à la quantité de mémoire configurée sur des VM démarrées (état PowerOn ).

La colonne vRAM capacity correspond à la quantité de mémoire configurable. C’est à dire la quantité maximale de mémoire que l’on peut configurer(  différent de la quantité réellement consommée) à des VM démarrées. On peut assigner plus de vRAM à des VM mais celles-ci ne pourront pas être démarrées.

Dans notre cas,  la quantité de mémoire configurable en vSphere 5 pour les VM est de 448 GO. Ce nombre correspond à 14 (nb licences vSphere 4) * 32 (quantité max de mémoire pour l’édition standard).

De ce pool de 448Go, 244Go sont utilisées.  Cela signifie que la somme de la mémoire configurée pour toutes les VM démarrées est de 244Go.

La conclusion est que pour faire fonctionner l’ensemble des VM existantes dans mon infrastructure aucun achat n’est obligatoire. La migration des licences vSphere 4 en vSphere 5 permet de couvrir le double mon existant.

Par contre d’un point de vue technique mon infrastructure possèdent les ressources suivantes :

Je dispose de 471,64 Go de mémoire disponible. Or avec 14 licences vSphere 5, je ne peux disposer que de 448Go de vRAM. Si je souhaite exploiter au maximum mes ressources physiques, il faut que je rajoute au moins 1 licence standard. Dans le cas, où je souhaite faire de l’overcommit, il faudra que je rajoute encore des licences. Cela remet en cause les calculs de ROI réalisés à base de vSphere 4.

En conclusion, dans le cadre d’une  migration vers vSphere 5, il est important d’estimer le coût du surplus de licence à acheter.

Le nouveau système ne remet pas en cause fondamentalement  la rentabilité d’un projet de virtualisation mais il nous pousse à réfléchir quant à notre dépendance vis à vis des politiques tarifaires d’un éditeur.  Le changement de solution de virtualisation n’est pas simple notamment pour les fournisseurs d’offre cloud IAS (infrastructure as a service). L’utilisation (ou au moins l’étude) d’une solution alternative à vSphere (Hyper-v, XenServer) peut permettre de se libérer en partie des aléas tarifaires de l’éditeur.