alias la RECUPERATION EFFICACE DES (bourdes) OPERATEUR...

Je dédié cet article à mon estimé collègue le Niol. En espérant que celui ci ne le mutile pas mentalement plus qu'il ne l'est...

Bon ok ok, de janvier à mars, je n'ai pas pondu le moindre article et je vous sens impatients... la raison est simple j'ai déménagé, donc estimez vous déjà heureux de ne pas vous taper un article sur la pose de papier peint où le montage d'un placard en kit c'est déjà ça...

Ce mois ci, ouais bon ok il a été posté border line pour ce mois ci (j'entend déja les remarques désagréables).. MAIS c'est toujours ce mois ci...bref ce mois ci, toujours de l'informatique... et on va donc se dépêcher d'apprendre a fond les possibilités du REDO donné à Vmware ESX... Dépêchons nous avant que ESX V3.0 ne sorte et que l'on se retrouve comme des cons avec notre vieux REDO.

Au passage remercions tous, Mr PC (je vous jure c'est ses vrai initiales), IT dévoué dans une grande société d'assurance dont nous tairons le nom, de m'avoir fournis un joli Proliant 6500 (qui n'a plus d'age) permettant ainsi a votre humble serviteur d'avoir enfin son ESX à lui, chez lui.  Cela dis, P, s'il te reste toujours cette fameuse baie de disques, je suis toujours preneur.

Soit..Une fois de plus la lecture de cet article va pas être facile, figurez vous que pour une obscure raison de hardware fatigué je n'ai pas accès à de la musique dans ma nouvelle salle machine.. je ne sais donc pas vous conseiller le moindre entremet a soumettre a vos tympans... en.. coté gniole par contre tout va bien... il me reste UNE et UNE seule Chimay Bleu.. déja évoquée certes, mais une valeur sur... à votre santé et allons y enfin....

Reprenons les Bases

Prenons un PC standard.. oui, lui votre bon vieux PC avec lequel vous liser ce triste article... toutes vos data sont posée sur votre disque dur... c'est votre Windows (ouais ca pourrais aussi etre votre pinguin) qui utilise un Système de Fichier genre le NTFS et c'est ce même Windows qui contient aussi le driver de ce même disque qui au final pose consciencieusement vos petit fichier en des endroit bien précis de ce disque... premier postulat, le PC, sait juste que vous changer des Bits sur le disque Dur, c'est tout, il ignore tout le process... transposons ceci a Vmware... je rappelle que le disque dur n'est pour le serveur ESX, qu'un énorme fichier à l'extension DSK ou VMDK posé dans une partition VMFS2 et c'est donc dans ce fichier des bits sont changés...

Maintenant le REDO c'est quoi, le REDO c'est pouvoir revenir à l'état des ces fameux bits a l'instant T. comment ca marche, facile.. un fichier avec l'extension .REDO est généré, dès qu'on change un bit  ce bit n'est pas changé dans le disque dur ( le gros fichier DSK ou VMDK ) mais il est noté dans le fichier redo, «à tel secteur j'ai changé la valeur de tel bit»... facile n'est ce pas...

On arrive donc a notre premier constat... en lecture il va falloir regarder dans le redo si on a déjà ce bit, si non... le lire dans le vrai disque, et en écriture on s'un fous il suffit de noter tout cela dans le redo...

On a donc deux options avec notre REDO...

Soit on enlève ce fichier REDO, et notre disque dur revient à la position qu'il avait avant qu'on le mette en place... comme par magie...

pour ceux qui ont pas encore lu tout cet article, pour l'instant la seul approche du REDO que vous avez c'est via la configuration disque et c'est par disques que cela se configure... premièrement il faut avoir la Machine Virtuelle éteinte et là quand on va chipoter la configuration disque via Virtual Center ou le Mui, on tombe sur 4 possibilités...

PERSISTENT: Facile c'est un disque dur normal sans REDO ça devrait pas trop poser de problèmes de compréhension vus que ça ne change rien à rien A partir de la, il reste 3 Autre mode qui on tendance à perturber Mr Niol, déjà pour clarifier la situation, sachez que ESX va inter-agir avec ces modes principalement au Power OFF et eventuellement au Power ON de la dite virtual Machine, entre dehors de cela il ne vous embetteras pas, vous pouvez rebooter autant de fois que cela vous fait plaisir. Attention rebooter pas faire reset.. un reset sous vmware c'est un POWER off/on. Alors les petits modes sont ... alors dans la catégorie REDO sont nominés cette année..... NON PERSISTANT: Comme son nom l'indique (enfin juste pour ceux qui ont de solides bases en anglais) Le REDO quand on fait power Off est simplement et automatiquement supprimé... chaque modification au niveau disque ne subsiste pas au power off... c'est l'idéal pour se faire un serveur de TEST ou de Démo qui a chaque power off reprend sont état initial. UNDOABLE: Ici aussi une vaste connaissance de l'anglais nous permet de comprendre que le fait de choisir ce mode nous ouvrira au Power OFF trois possibilités... détaillons les précisément car c'est ici que Mr Niol dans 95% des cas fait le contraire de ce qu'il pense faire.. on a donc trois possibilité offerte a chaque power de la machine virtuelle

Soyons pratique, prenons le cas concret suivant, j'ai une VM sous Windows avec Internet Explorer 6, je la met en UNDOABLE et ensuite j'installe Internet Explorer 7 Beta. On est tous bien d'accord que le disque de la VM (le gros VMDK) Contient IE6 et que dans le REDO j'ai le delta entre mon HD de base et ce qu'il faut comme bits dissméminés sur le disque pour avoir IE7

Dès que je vais éteindre la machine virtuelle, je vais tomber sur une boi-boite à 3 boutons...Mr NIOL soyez attentif c'est là qu'on y vient :

3 boutons et il se plante a chaque coups... soit allons y.... si vous cliquer sur :

Commit: Il va fusionner le REDO avec votre disque dur... vos modification entre le power on et power off seront donc inscrite dans le disque dur réel et c'est indélébile. Et au power on  recommence un nouveau fichier de REDO tout frais.

Discard: on dégage le REDO sans le fusioner avec le disque dur. Donc les modification entre le power on et power off disparaiterons comme par magie et ce sera comme si vous n'avier rien fait depuis le dernier power on. Hop exit IE7. Comme sont pote le bouton commit, au Power on  recommence un nouveau fichier de REDO tout frais.

Keep: c'est l'option de la raison ou plutôt du mec pas sur... disons que ca ne fait rien au power off, aucune fusion ou suppression..au prochain power on continuera sur le même fichier de redo.

Hein que c'est simple.... et oui... je vous l'avait dis que mon estimé collègue est mentalement mutilé...enfin... on vis avec... reste donc le dernier mode disponible dans le menu général, le mode append...

Bon ca c'est déjà pas mal...mais je vous sens déjà trépignant d'impatience, vous fideles warriors de la command line... comment que je peut fourrer un REDO via le shell de la console ESX.... haaaa j'ai même mieux pour vous mes fideles lecteurs... Non seulement on va voir comment mettre en place un REDO, mais en plus sachez que contrairement à la selection du mode disque avec le MUI ou virtual Center... en ligne de commande on peut mettre en place un REDO sur un disque à chaud... sans jouer avec le power de la bécanne.. en plein milieu du travail de la VM. Génial non ?

vmware-cmd <cfg> addredo <disk_device_name>

cfg c'est le chemin du fichier VMX de la définition de la machine (si on a oublié où c'est vmware-cmd -l votre amis) et le  disk_device_name c'est le nom du périphérique disque dur du type bus:id-scsi définis dans ce fameux fichier. Exemple: SCSI0:0 pour le 1er disque dur (généralement) si vous voulez savoir quel disque SCSI sont dispo dans votre machine virtuelle deux simple grep seront utile.

Damned !! Enfer et damnation, le redo commit automatiquement au Power OFF.. vous imaginer.. (HEIN NIOL)... vous êtes la, on vous a dis le redo c'est génial on peut faire des conneries et après on le discard.. vous démarrer votre VM, vous la salopez affectueusement.. et la ...merde... coincé, vous commencer à tirer une geule de labrador qui aurai dévasté un salon à coup de crocs et aurai été surpris par son maitre...... comment faire... là concretement Rien.. vous êtes totalement niqués, reste eventuellement le backup...vous auriez du faire un 'Double' Redo (Priere de dire Double avec l'accent américain).

La rêgle est simple... le fichier nommé .REDO est commité au power Off, et vous avez pas le choix c'est comme ca et puis c'est tout. C'est la loi !.. le truc pour se tirer de ce gay pied (oui bon ok mais écrit comme ca c'est tendance) aurait été de créer un double redo... ainsi :

Qu'en déduisons nous, le second REDO (le REDO.REDO) est utilisé pour stoquer nos IO et le 1er REDO (Le REDO tout court) ne fous rien, et est quasiment vide (élémentaire mon cher Dr watson).  Le redo tout cours qui est vide c'est le 1er que nous avons fait pendant notre scéance redo du jour.. c'est lui qui va être comité au power off... donc on commitera du vide... et on risque rien.

--------------------------------------- CUT HERE ----------------------------------------

1 VIDE
0 VIDE
LEDISQUE (I/O)

1 VIDE
0 REDO (I/O)
LEDISQUE

1 REDO
0 REDO.REDO(I/O)
LEDISQUE

1 VIDE
0 REDO (IO)
LEDISQUE

--------------------------------------- CUT HERE ----------------------------------------

1) J'arrête pas ma prod et je veut tenter un truc...

2) Je fait un REDO

3) immédiatement après, Je fait un second REDO, le 1er est donc vide

4) je fait ma connerie... merde ca marche pas

5) j'eteint ma VM.. il commit le redo vide...et renomme le redo.redo en redo tout court

6) je pete le REDO qui contient ma connerie...avec un bete commande « rm »

7) je redémarre ma machine comme une fleur....

On aurais aussi pus ne pas peter le REDO avec notre commande RM et au power on de la VM, la console nous aurais gentiment demandé le sort qu'on réserve au REDO restant.

Pas se planter Hein.. HEIN Mr NIOL... commit c'est une connerie dans ce cas de figure...

Bon maintenant adméttons que le truc qu'on voulait tenter ai marché... on veut donc conserver ces redo et les fusionner au disque dur.

vmware-cmd <cfg> commit <disk_device_name> <level> <freeze> <wait>

Freeze : et là drame de l'histoire.. ET OUI la machine est toute frezzée pendant le commitage du REDO qui à les I/O disques (décidément y a pas de secrets ) le fameux level 0 (revoir le mémo des boites que vous avez découpé) par contre on peut commiter le redo nr 1 sans freezer la VM. L'option 1 ici frezera la VM et l'option 0 commitera san frezer la VM (mais juste pour le redo level 1) cependant le disque sera plus lent pendant le commitage, on a rien sans rien de nos jours

Wait : la commande de commit doit elle rendre la main immédiatement ou attendre la fin du commitage du redo ? donc 0 ca veut dire j'attend pas que ca ai finis de comité, 1 j'attend la fin du commit avant de rendre la main.

Avant que vous vous lancier sur cette commande , il y a un Bug qui cours toujours même sur les ESX 2.5 qui fait que le parsage des « level » « freeze » et  « wait » merdouille à mort voir la page :

Vmware c'est de la merde mais la knowledge base est sympas

Veuillez SVP mettre a jour le script vmware-cmd comme indiqué avant de se lancer dans un commit sauvage...................j'attend.........c'est patché votre commande...Commitons la bete... alors un level 0 avec un freeze à 1 ( pas le choix ) et en attendant wait a 1.. et Hop

Alors a quoi que ca peut servir de pouvoir commiter le redo level 1 sans freezer la bécanne.. et bien mettons que vous faite un backup de votre VM, vous venez de découvrir le REDO ca change votre vie, vous pouvez backuper à chaud vos disques de serveur sans les éteindre en plein journée ... le panard !!! Sauf que mettons que votre backup mette 2H.. vous faites un REDO et il se mange les I/O disque pendant 2H. Il a de grande chances de faire au moins quelque centaine de mégas votre redo.. du coup le freeze pendant le commit du redo level 0 ca pourrait prendre quelques minutes... et patatra votre beau backup en nonstop, foutu.. au placard..niké. car cela sera dur a faire croire que vous backuper sans arret si après le backup il y a 15mn de downtime.

1) Je fait un REDO ( level 0 )

2) je backup... ca dure et mon redo level 0 enfle..

3) j'ai finis le backup je fait un redo.redo level 0 mon redo simple passe donc à level 1

4) je commit sans freezer le REDO enorme de level 1,

5) du coup le REDO.REDO passe à level 0 et se renomme redo tout court

6) je commit en freezant l'ancien redo.redo devenus redo de level 0 et qui est tout petit

j'ai donc un freeze ridiculement petit, qui prend le temps du commit du redo vide de la taille minimale de 16Mo plus éventuellement du nombre d'I/O écriture qui on eu lieu pendant le commit du premier redo...

Bon alors là, je vous entend déjà ho joie, on peut backuper a chaud en journée sans downtime, tranquille tranquille.. oui mais non !!... la mise en place du redo c'est exactement la même chose que si on avait un miroir ( RAID 1 ) et qu'on arrachait a la hussarde un des deux disque pour s'assurer un backup... ne riez pas de nombreux le font je peut donner des noms...

Alors effectivement ca marche nickel pour des file serveur ou des disques système mais faut avouer que dès que ca va toucher une database ou un truc qui fait genre database ( exchange, notes ) ca risque de laisser la DB dans un état pathétique. Car notre redo et l'arrachage de HD travaille au niveau I/O rien ne peut dire que on est pas en plein transaction dans un db, rien ne peut même dire qu'on a pas un fichier en cours d'écriture. Dans ces cas la, il vaut mieux un bon viel agent de backup dans la machine virtuelle... la journalisation à ses limites il parait. je n'ai jamais eu le temps de tester les dire de M. Vmware la dessus. mais pour des backup consistent, sur ce coup là j'ai tendance à le croire.

Donc on peut effectivement faire le backup de DSK via redo sans problèmes pour avoir une image des disque systèmes et en cas de crash ou de drp repartir sur les image puis recharger les db du backup traditionnel. C'est ce qu'on peut appeller du norton ghost classieux à 2000€ la licence.

L'autre couillonerie chiante c'est qu'on ne peut pas restorer au niveau fichier.. enfin je dis on ne peut pas... si on peut mais c'est loin d'etre pratique (yep on peut monter une un disque d'une VM depuis la console.. ne le dite jamais à l'audit). Disons que si vous sauver un file serveur, et que madame machin vous à, pour la enieme fois, péter son fichier XLS.. ce sera quand meme beaucoup plus facile de restorer son putain de fichier excel du backup fichier de l'intérieur de la VM que de l'extraire du disque backupé...

Enfin pour l'exercice de style, comment restaurer un fichier emprisoné à l'intérieur d'un disque vmware vmdk:

Alors on a deux options, soit vous avez backuper directement les disques complets vmdk, soit vous avez intelligemment (et parce que vous aviez de la place) exporté les disque au format COW (copy on write), le format utiliser par GSX 3, avant de backuper. (rapellez vous la commande vmkfstool -e qui permet d'exporter le disque ENORME VMDK en block de 2 Go dans lequel on ne garde que les secteurs vraiment utilisé... )

Si c'est un vmdk on peut le monter directement dans la console , voir la commande vmware-mount

Chaques médailles ayant sont revers ( expression placée ici idéalement, parce que par exemple ici, chaque pot a son couvercle expression chère à ma grand mêre n'aurait pas convenu) il vas quand même falloir que je vous le dise, le REDO ca plomble les performances disques.... je sais c'est un drame. mais ne vous pendez pas tout de suite...écoutez pourquoi...

Bon déjà on se doute... si on fait des I/O dans le Redo, c'est pas des I/O linéaires comme dans un faux disque Vmware c'est indéxé bref on perd de la performance là déjà.. ensuite quand on lis un truc et que le redo l'a pas faut le lire dans le vrais disque et la rebam on a aussi pbm de performances, et enfin le redo il grossis... et cà c'est chiant.. sur une partitions VMFS a chaque fois qu'une des machines change l'attribut d'un fichier ( pas lire ét ecrire dedans ) genre faire grossir le redo, pour eviter tout pbm toutes les machines sous ESX qui sont connectées à cette partition VMFS sont privée d'I/O pendant ce temps là....

Dans les deux cas C'est  un peu la même choses on va faire un fichier qui prendra les I/O ce qui va permettre de Revenir à un instant T... le Redo c'est le fameux Fichier crée à l'instant T. On a bien compris que si on se sépare de ce fichier on revint à cet instant T.

Le Snapshot c'est le nom Donné à cet instant et du coup On Comprend mieux que quand Vmware demande «voulez vous revenir au Snapshot» cela veut dire qu'il va discarder le redo.

Bon Normalement vous n'aurez pas ce problème car vous êtes des puristes et vous ne Travaillez qu'avec Vmware Esx et donc vous ne verrez que des Redo  car le Snapshot on ne le trouve que sur les autres Produits Vmware le Gsx le workstation et bien sur le nouveau gsx,  l'ami des gens qui n'ont Pas de sous votre nouvel ami  j'ai cité Virtual server .

Juste une Petite chose encore Sur Gsx et Virtual Server il n'y a qu'un seul niveau de redo alors que Sur la workstation, il faut bien avouer qu'ils on bétonné la chose. Il y a possibilité de mettre en place de multiples snapshot, mais on peut aussi repartir d'un snapshot, faire un nouveau snapshot... puis revenir a l'original snapshot et resnasphsoter..etc. bref c'est festif !

Moyenne Dédicace au Chef Chaudart pour sa lecture peu motivée ce coup ci.
Et monsieur Niol... bon courage à ce qui vont bientôt vous supporter. (mais qui va finir l'alcool chinois avec moi !)

Contactez Moi et soyez méchant

Go Home