La Haute Dis­po­ni­bi­lité (High Avai­la­bi­lity) ou HA chez VMware n'est pas une nou­veauté. C'est tou­jours la pos­si­bi­lité de redé­mar­rer une VM qui était sur un ESX sur un autre noeud d'un Clus­ter. Suite à un pro­blème, un ESX du clus­ter est iden­ti­fié comme hors ser­vice, ses machines vir­tuelles sont alors redé­mar­rées sur un autre ESX du clus­ter tant que les res­sources le per­mettent ou que la poli­tique mise en place le tolère.

Com­ment est-il diag­nos­ti­qué qu'un ESX n'est plus en ordre de déli­vrer son service ?

Sur une simple absence de com­mu­ni­ca­tion avec les autres ESX du cluster.

Les ser­veurs hôtes d'un clus­ter HA s'échangent un Heart­beat chaque seconde (valeur par défaut). Au delà de 15s sans échanges d'un ESX du clus­ter, il sera consi­déré comme hors ser­vice suite à une véri­fi­ca­tion com­plé­men­taire par Ping. Le "host net­work iso­la­tion" est propre à un ESX. C'est une capa­cité à ce pla­cer en mode d'isolation. Sans récu­pé­ra­tion de heart­beat des autres ESX du clus­ter pen­dant 12s, un ESX tes­tera ses adresses d'isolation (par défaut la pas­se­relle - 9 autres pos­sibles) avant de se décla­rer isolé du réseau. Au dela de 15s, les autres ESX du clus­ter ten­te­ront de redé­mar­rer les VM de l'ESX en mode d'isolation. Des méca­nismes per­mettent aujourd'hui d'éviter les situa­tions de split brain en chan­ge­ment le para­mètre "host iso­la­tion res­ponse", et le timeout de 15s sur les locks des fichiers vmdk. Lire la suite...

 Dans les news

Le 17 Mai 2011, la for­ma­tion de l'OVA (Open Vir­tua­li­za­tion Alliance) a été annon­cée avec les par­te­na­riats de quelques grands noms de l'informatique : BMC soft­ware, IBM, HP, Intel, Euca­lyp­tus Sys­tems, Red­Hat et Suse (Novell). L'objectif de ce grou­pe­ment est de pro­mou­voir la vir­tua­li­sa­tion à base de KVM (Kernel-based Vir­tual Machine) pour prin­ci­pa­le­ment contrer VMware. Micro­soft et Citrix ne semblent pas être un point de pré­oc­cu­pa­tion pour le moment. La pro­mo­tion de cette vir­tua­li­sa­tion open-source aura pour impact direct un déve­lop­pe­ment accé­léré, les inter­opé­ra­bi­li­tés et les déve­lop­pe­ments tiers. Selon les pro­ta­go­nistes, le choix porté sur KVM est stra­té­gique, il per­met de faire béné­fi­cier les entre­prises d'un noyau sécu­risé fiable et évolu­tif. De plus, la puis­sance de la com­mu­nauté Linux per­met des déve­lop­pe­ments rapides et per­for­mants pour s'adapter aux nou­veaux équi­pe­ments tout en four­nis­sant aux machines vir­tuelles Linux et Win­dows des pilotes adap­tés pour une bonne vir­tua­li­sa­tion. Enfin, l'intérêt est aussi lié à l'intégration en Cloud de cette vir­tua­li­sa­tion pour ne plus pen­ser à une archi­tec­ture de vir­tua­li­sa­tion sans ser­vices com­plé­men­taires (Euca­lyp­tus Sys­tems pro­cède déjà plu­sieurs mil­liers de Clouds Pri­vés basés sur KVM). BMC avait ren­forcé son par­te­na­riat avec Red­Hat quelques jours aupa­ra­vant pour annon­cer l'intégration du pro­duit de ges­tion de cycle de vie dans le Cloud (BMC Cloud Life­cycle Mana­ge­ment) dans les pro­duits Red­Hat (RHEL et RHEV-M). Cela per­met aussi à Red­Hat de béné­fi­cier d'une solu­tion de Cloud avec tous les béné­fices asso­ciés (pro­vi­sion­ne­ment, por­tail client, multi-tenant, confor­mité ITIL....).

KVM sous RedHat

Voici des éléments de réponse à : Com­ment se pré­sente KVM ? Quelles fonc­tion­na­li­tés ? Et à quel prix ?

Lire la suite...

Ven­dredi 13 Mai 2011 - 15h, les nou­velles annonces de Veeam Backup pour les partners....

Elles arrivent pour les blog­geurs le 15 et pour le public Lundi 16 Mai, ne ratez pas le RDV ! Une page dédiée sur le site Veeam sera mis en ligne la semaine pro­chaine sur cette grande nouvelle.

Aujourd'hui Micro­soft c'est 11% du mar­ché de la vir­tua­li­sa­tion contre 84% pour VMware. Dans les 3 ans, Gart­ner annonce 27% pour Micro­soft et 75% pour VMware. Au même titre que Hyper-V arrive chez les clients, Hyper-V arrive aussi chez Veeam. C'est un déve­lop­pe­ment stra­té­gique pour tous les clients. Les besoins seront donc impor­tant de faire fonc­tion­ner les deux solu­tions en parallèle.

Veeam a mar­qué les esprits par ses capa­ci­tés à effec­tuer de la sau­ve­garde image des VM, par la com­pres­sion, la dédu­pli­ca­tion et par l'utilisation du CBT. C'est aussi la capa­cité a faire par le même pro­duit de la sau­ve­garde et de la répli­ca­tion. Veeam Backup c'est aussi plus de 20 000 clients et 1.5 Mil­lon de machines vir­tuelles sécurisées.

La ver­sion 6 arrive pour la fin de l'année ! Retour sur l'historique des avan­cées de Veeam :

Lire la suite...

Les objec­tifs

Les objec­tifs sont mul­tiples, et émergent sui­vant une chro­no­lo­gie qui logi­que­ment per­met l'évolution tech­no­lo­gique à l'origine ou décou­lant d'un nou­veau besoin. Aujourd'hui les besoins de la dédu­pli­ca­tion sont évidents :

• gain en volu­mé­trie cible
• gain en bande passante
• gain en charge système
• réduc­tion des I/O
• réduc­tion des fenêtres de sauvegarde
• Mise en place de PRA/PCA par réplications...

Au pro­gramme de ce post : retour sur l'apparition de la dédu­pli­ca­tion dans l'histoire de la sau­ve­garde, le voca­bu­laire, des logi­ciels, des équipements, des exemples d'utilisation et sans ren­trer dans les détails ce que l'on peut attendre de la déduplication.

Lire la suite...

Voici un petit script qui per­met de récu­pé­rer dans un fichier Excel la liste des VMDK uti­li­sés par les machines vir­tuelles vues d'un vCen­ter. C'est uti­li­sable sans ce der­nier, en sai­sis­sant à l'invite de com­mande le nom ou l'adresse ip d'un ESX.

Le résul­tat se pré­sente sous forme d'un tableau Excel. Les machines vir­tuelles démar­rées génèrent des rem­plis­sages de cases en VERT. Pour un inven­taire com­plet, il faut que les VMware tools fonc­tionnent sur toutes les VM et que le nombre de par­ti­tions des VM soit iden­tique au nombre de VMDK. Cela per­met d'avoir une vue depuis l'intérieur de la VM la taille des partitions, le taux de rem­plis­sage et de géné­rer les alertes rouges ou oranges sui­vant ce taux.

Exemple de rendu :

Lire la suite...

Il n'est plus néces­saire d'expliquer la dif­fé­rence prin­ci­pale entre ces deux types de disques Thin et Thick pro­po­sés par VMware. Mais cer­tains points méritent encore d'être étudiés. La ques­tion des per­for­mances a déjà été abor­dée dans plu­sieurs études (cf site VMware) et montrent dans la plu­part des cas une modi­fi­ca­tion très légère du com­por­te­ment. En résumé on note deux différences :

1. Le volume créé en thin pro­vi­sio­ning doit à un cer­tain moment être étendu pour accueillir de nou­velles don­nées. C'est ce besoin qui est res­senti. Quizz : lorsqu'une don­née est sup­pri­mée, une nou­velle don­née demande-t-elle une exten­sion du disque ou peut-elle prendre les blocs des don­nées supprimées ?
2. La frag­men­ta­tion des volumes VMFS est alors plus impor­tante. Les fichiers des VM ne peuvent plus être conti­gus en rai­son de l'entrelacement des exten­sions des fichiers VMDK. Quizz : Com­ment est gérée cette frag­men­ta­tion sur les volumes VMFS ?

Et un point de détail com­plé­men­taire : L'initialisation des blocs à 0. A quoi cor­res­pondent les termes Disk Blocks, Lazy Zero, Eager Zero, Zeroing... ?

Lire la suite...

L'API vSto­rage de VMware est arri­vée avec vSphere, tout comme bien d'autres. Cette API per­met la mise en place d'un suivi des blocs modi­fiés (change block tra­cking ou CBT) de fichiers VMDK dans le but d'améliorer les per­for­mances liées au sto­ckage. C'est uti­lisé, entre autres, par les outils de sau­ve­garde et de répli­ca­tion. Le "Sto­rage vMo­tion" tire aussi plei­ne­ment pro­fit de cette avan­cée pour réduire la charge sys­tème d'une opé­ra­tion de relo­ca­li­sa­tion d'une machine vir­tuelle. Cela per­met notam­ment d'effectuer plu­sieurs opé­ra­tions de ce type en simultané. 

On parle bien d'une fonc­tion­na­lité récente, ne pou­vant être acti­vée que sur des machines vir­tuelles au niveau maté­riel égal à 7. Tout comme la jour­na­li­sa­tion Win­dows 2003 et plus, c'est le sys­tème qui héberge les don­nées qui logue les modi­fi­ca­tions et qui les res­ti­tue à l'outil qui les demande. L'hyperviseur (ESX ou ESXi) garde une trace des blocs modi­fiés d'un VMDK par l'activité même de la VM  depuis la der­nière sau­ve­garde. Au moment de la sau­ve­garde, cette table est relue par le VMKer­nel (inter­rogé par l'outil via l'API) et les don­nées sont trans­mises à l'outil qui effec­tue la sécu­ri­sa­tion. Les logi­ciels qui tolèrent ce mode de fonc­tion­ne­ment (uti­li­sa­tion du CBT), en lieu et place du bon VCB (VMware Conso­li­da­ted Backup) ne le peuvent qu'au tra­vers de l'API et uti­lisent les termes suivants :

• API vSto­rage
• CBT
• VADP (vSto­rage API for Data Protection)

Lire la suite...

HP Data Pro­tec­tor 6.2 est dis­po­nible ! Toute la docu­men­ta­tion ici, et les nou­veau­tés là.

L'outil de sau­ve­garde d'HP : Data Pro­tec­tor était dis­po­nible en ver­sion 6.11 depuis plus d'un an. Plu­sieurs patchs sont sor­tis depuis pour y ajou­ter des sys­tèmes aussi variés qu'indispensables aux tables de compatibilité. Les clus­ters VMware sont sup­por­tés en der­nière ver­sion, ainsi que les clus­ters Hyper-V avec CSV (clus­ter sha­red volumes) et les envi­ron­ne­ments XEN.

L'interface est tou­jours un peu vieillis­sante, mais cer­tains modules com­plé­men­taires viennent agré­men­ter l'utilisation du pro­duit. Les exten­sions Data Pro­tec­tor Gra­nu­lar Reco­very per­mettent aux uti­li­sa­teurs d'infrastructures VMware et Sha­re­Point d'effectuer des res­tau­ra­tions direc­te­ment depuis leurs inter­faces d'administration, sans demande de res­tau­ra­tion aux res­pon­sables des sau­ve­gardes. Dans le cas qui nous inté­resse, un plug-in vient s'ajouter à l'interface du vSphere client pour per­mettre de faire des res­tau­ra­tions direc­te­ment depuis les medias de sau­ve­garde disque ou bande.

Lire la suite...

Comm­vault a sorti en ce début d'année Sim­pana 9.0. C'est aussi en Jan­vier que Gart­ner à sorti son Magic Qua­drant for Enter­prise Disk-Based Backup/Recovery qui place Comm­vault en tête du mar­ché. Pour récu­pé­rer l'étude, pas­ser par le site de Comm­vault sur la page d'identification. Comm­vault y fait parti des 4 com­pé­ti­teurs Lea­ders et Vision­naires (avec EMC, IBM et Symantec). 

Ce post ne fait pas un état com­plèt des capa­ci­tés du pro­duit de sau­ve­garde, il y a trop de choses à dire. Sim­ple­ment, quelques infor­ma­tions pour décrire le pro­duit : c'est un pro­duit de sau­ve­garde comme on a l'habitude d'en voir, on y gère des clients (qui peuvent être pous­sés sur Win­dows et Linux), du sto­ckage disque et bande, des pla­ni­fi­ca­tions, des sau­ve­garde incré­men­tales, com­plètes et autres syn­thé­tiques, des répli­ca­tions de volumes de sauvegarde... et enfin pos­sède une dédu­pli­ca­tion à la source (nou­veauté 9.0) et glo­bale. Plu­sieurs outils font de la dédu­pli­ca­tion au niveau d'un job de sau­ve­garde (comme Veeam), mais la dédu­pli­ca­tion pro­po­sée par Comm­vault va bien plus loin. Une don­née d'un ser­veur de fichiers qui n'a pas encore été sau­ve­gardé, mais déjà conte­nue dans la sau­ve­garde d'un autre ser­veur de fichiers (d'une autre société par exemple) ne sera pas ren­voyée. La dédu­pli­ca­tion est alors gérée par un ser­veur cen­tral qui gère une DDB (dedu­pli­ca­tion data­base). Toute  l'administration s'effectue par une appli­ca­tion cliente ou par un por­tail Web. Les deux inter­faces sont identiques.

Aujourd'hui je m'intéresse à la la sau­ve­garde des envi­ron­ne­ments vir­tua­li­sés. Pour obte­nir toutes les docu­men­ta­tions tech­niques et les matrices de com­pa­ti­bi­lité, RDV sur http://documentation.commvault.com/.

Lire la suite...

Voici depuis quelques jours une nou­velle ver­sion de Veeam Backup et Repli­ca­tion, la 5.0.2.  Parmi les dif­fé­rentes avan­cées, j'en relève 2 impor­tantes : L'accès inter­net pour les Vir­tual Lab et l'application de réten­tions sur les sau­ve­gardes. Les U-AIR ont aussi été mis à jour en 5.0.2, l'Enterprise Mana­ger n'est plus une obli­ga­tion pour les uti­li­ser. Seul l'assistant Exchange a evo­lué en fonc­tion­na­lité : il sup­porte main­te­nant Exchange 2010 SP1 avec https ET http.

La réten­tion sur les sau­ve­gardes per­met de sup­pri­mer auto­ma­ti­que­ment, lors d'une exé­cu­tion d'un tra­vail de sau­ve­garde, les sauve­gardes de machines vir­tuelles ayant été dépla­cées ou sup­pri­mées. Par défaut ce para­mètre est placé à 14 jours. Ce n'est pas une valeur en nombre de points de res­tau­ra­tion, mais bien en nombre de jours.

Atten­tion ! cette fonc­tion­na­lité est nou­velle et à un petit pro­blème de mise en place : lors d'une mon­tée de ver­sion de Veeam, il faut modi­fier ce para­mètre pour tous les tra­vaux de sau­ve­garde avant le déclen­che­ment de la sau­ve­garde. Sans cela tous les points de res­tau­ra­tion anté­rieurs à 14 jours seront sup­pri­més, alors que les VM sont tou­jours exis­tantes. Il faut fixer la valeur eu fonc­tion du nombre de points de res­tau­ra­tion à gar­der, et en fonc­tion de la pério­di­cité de la sau­ve­garde (90 points de res­tau­ra­tion à gar­der, avec 2 sau­ve­gardes par jours = 45 jours).

L'accès inter­net pour les Labs Sur­eBa­ckup per­met de tes­ter aussi les mises à jour de patchs sur les pla­te­formes iso­lées. Mais ce para­mètre est par défaut désac­tivé. L'activation se faite par une modi­fi­ca­tion d'une clef de registre sur le ser­veur de sau­ve­garde Veeam.