VirtualGeekCH

Bon­jour, quelques mots sur la cuvée 2011. VMware avait pléthore de pro­duits à mon­trer, de best prac­tices à don­ner, il a donc été très dif­fi­cile de faire un choix parmi les très nom­breuses ses­sions, qui, pour la plu­part, n’étaient jouées qu’une fois. N’ayant pas le don de me mul­ti­plier, j’ai dû faire des choix. Déjà j’ai choisi de ne pas me focaliser sur des ses­sions par­lant des nou­veaux pro­duits vSphere 5, qui n’auraient fait que répéter ce que tout le monde a déjà lu sur les blogs (dont le nôtre… surtout le nôtre). J’ai choisi d’assister à :

• VSP3866 Per­for­mance Best Prac­tices and Trou­bleshoot­ing : cette ses­sion par­lait essen­tielle­ment des out­ils de mon­i­tor­ing des per­for­mances qui sont les per­for­mances charts du vCen­ter et la com­mande ESXTOP. On y par­lait beau­coup des dif­férentes met­rics CPU et mémoire, expli­quant pour une fois de manière claire les dif­férences entre mem­ory used, granted et con­sumed les (très) nom­breuses met­rics CPU, etc, bref, de quoi vous ren­dre com­plète­ment adepte d’ESXTOP. Egale­ment, on y expli­quait cer­tain pièges du trou­blshooter non-averti : oui, un stock­age lent se ressen­tira d’abord par du CPU élevé ; non, une VM avec 32 vCPU ne fonc­tion­nera pas for­cé­ment mieux qu’avec 2 ; oui, les VMware tools jouent un rôle pri­mor­dial dans le mécan­isme de récla­ma­tion de la mémoire et donc sur les per­for­mances glob­ales ; non, don­ner 25 GB de RAM à une VM en se dis­ant « bof, elle ne con­som­mera que ce dont elle aura besoin » n’est pas une bonne idée. À me lire vous pour­riez croire que l’on a enfoncé des portes ouvertes durant 1 heure, mais il était très intéres­sant (et sure­ment néces­saire pour bon nom­bre) d’expliquer en détail pourquoi, plutôt que de hausser le sour­cil. Si le sujet vous intéresse, je ne peux que vous recom­man­der chaude­ment de suivre un des cours « Man­age for Per­for­mances » ou « Trou­bleshoot­ing » (www.lanexpert.ch/training)

• BCO2479 Under­stand­ing VMware vSphere Stretched Clus­ters, Dis­as­ter Recov­ery and Planned Work­load Mobil­ity : dans cette ses­sion, co-animée par EMC, on parle de Dis­as­ter Recov­ery et de Dis­as­ter Avoid­ance, reprenant et clas­sant dans ces deux caté­gories les solu­tions SRM, Vir­tu­al­i­sa­tion de Stock­age et HA. Pour résumer, HA et SRM sont des solu­tions de Dis­as­ter recov­ery, qui per­me­t­tent très rapi­de­ment de retourner à une sit­u­a­tion de pro­duc­tion nor­male, mais avec une perte pos­si­ble (RPO) car une panne a eu lieu, et on utilise une solu­tion pour revenir à la nor­male. Les solu­tions de vir­tu­al­i­sa­tion de stock­age, quant à elles, per­me­t­tent d’éviter qu’une panne n’ait d’effets et de con­séquences. Dans un design des plus aboutis, la perte de tout un Dat­a­cen­ter ne se ressent à peine. N’ayant pas choisi beau­coup de ses­sion par­lant de SRM, j’ai pu ici voir (revoir) SRM 5, et le Host Based Repli­ca­tion. J’ai fait égale­ment un LAB sur le sujet, un seul mot me vient : Waow! Sim­ple­ment génial, imag­inez : indépen­dant du stock­age ; peut utiliser les stock­ages locaux des ESX pour un DRP pas cher ; pro­tec­tion et répli­ca­tion d’une VM en 3 clicks ; fonc­tion de migra­tion inté­grée, où l’on réplique toutes ses VM sur le nou­veau site, puis on provoque le basculement.

• CIM1264 Pri­vate VMware vCloud Archi­tec­ture Tech­ni­cal Deep Dive : ses­sion pas très intéres­sante, mais néces­saire pour rat­traper un peu mon retard sur vCloud Direc­tor. Mon intérêt dans cette ses­sion était surtout de voir le con­cept de pri­vate cloud avec vCloud Direc­tor, puisqu’il va rem­placer dans le courant de l’année prochaine le LAB Man­ager. Actuelle­ment les linked clones ne sont pas encore inté­grés dans vCloud, mais dès qu’ils le seront, LAB Man­ager va douce­ment disparaitre.

• EUC1987 VMware View PC-over-IP Per­for­mance and Best Prac­tices : ce que j’ai retenu de cette ses­sion, ce sont les amélio­ra­tions apportées au pro­to­cole PCoIP. Bien qu’en terme de fonc­tion­nal­ités, ou de con­fig­u­ra­tion, rien de très impres­sion­nant, tous les nou­veaux paramé­trages se font via GPO et des .adm. En revanche il était intéres­sant de voir les tests com­para­t­ifs entre RDP, PCoIP et ICA, et entre l’ancien PCoIP et le nou­veau. VMware annonce une amélio­ra­tion théorique jusqu’à 70% de la bande pas­sante ! Mazel­tov ! Ceci grâce au fait que le pro­to­cole lui-même prend beau­coup moins de bande pas­sante, et au fait qu’il charge beau­coup moins le CPU. Dans la pra­tique, on annonce plutôt dans les 30% de réduc­tion de la bande pas­sante con­som­mée. Selon les tests de VMware, en toutes cir­con­stances, le PCoIP est doré­na­vant com­pa­ra­ble à l’ICA de Cit­rix. Champagne !

• SPO3400 Agent­less Secu­rity for VMware Envi­ron­ments:  A Report Card on the Past 12 Months and a crys­tal ball for the future : Ses­sion présen­tée par Trend­Mi­cro, pour par­ler de Deep Secu­rity, solu­tion basée sur les API VMware vShield End­point, qui per­me­t­tent de sor­tir com­plète­ment l’analyse anti-virus des VMs. C’est-à-dire d’avoir des Vir­tual Appli­ances qui vont assurer la sécu­rité depuis l’extérieur, au niveau des serveurs ESX. Mon avis est que la solu­tion est très promet­teuse, car le futur ne sera pas sans ce con­cept, mais encore un peu jeune. La dernière ver­sion de Deep Secu­rity est très récente, et celle d’avant n’avait pas le niveau attendu. Sachant que pour l’instant Trend­Mi­cro à une longueur d’avance sur la con­cur­rence, vive­ment que d’autres éditeurs s’y met­tent, pour stim­uler un peu ce domaine qui ne pro­gresse pas vite. Les pro­jets VDI n’attendent que ça.

• EUC3865 Tips, Tricks and Best Prac­tices for VMware View Suc­cess: Learn­ing from Cus­tomer sup­port : Ses­sion tenue par le sup­port de VMware, par­lant des dif­férents cas (les plus fréquents, pas for­cé­ment les plus intéres­sants) qu’ils reçoivent. Pour résumer : ne touchez jamais à une VM desk­top depuis le vCenter !

• VSP1682 VMware vSphere Clus­ter­ing Q&A : J’ai beau­coup aimé cette ses­sion, un peu par­ti­c­ulière, où des par­tic­i­pants pou­vaient poser des ques­tions durant 1h. Elle était ani­mée par la dream team VMware soit : Ducan Epping (@DuncanYB, Mr. Yel­low Bricks) ; Frank Den­ne­man (@FrankDenneman, le co-auteur des livres de Ducan) ; et Chris Colotti (@ccolotti). Les ques­tions étaient assez intéres­santes, notam­ment une ques­tion sur le partage entre ressource pools et VMs : il faut éviter de met­tre des VMs au même niveau que des ressources pools, car en cas de con­tention, une VM aura autant de ressource que l’ensemble d’un ressource pool, et cela fausse com­plète­ment le cal­cul. Un autre point, les shares d’un ressource pool sont à diviser par l’ensemble des VMs à l’intérieur. Prenons un exem­ple avec 6 VMs : 2 VMs dans un ressource pool avec un share de 2000 et 4 VMs dans un ressource pool avec un share de 4000. En cas de con­tention, on peut diviser le nom­bre de share par le nom­bre de VM dans le pool, dans le cas présent, chaque VM à 1000, et donc la même impor­tance. Or on imag­i­nait priv­ilégier le pool à 4000. Main­tenant, si on ajoute 4 VMs dans le pool à 4000 share, les VMs n’auront plus que 500, etc.

• VSP3299 Using VMware vSphere Stor­age Appli­ance to Cre­ate Shared Stor­age from Local Stor­age : dans cette ses­sion, il est ques­tion de la VSA (voir mon arti­cle) petites mod­i­fi­ca­tions par rap­port aux pre­mières annonces : SSD non sup­portés et RAID 10 de 4, 6 ou 8 dis­ques. Les shares NFS mon­trés par la VSA peu­vent être util­isés par n’importe quel autre ESX, mais pour l’instant, max­i­mum 3 nœud dans un clus­ter VSA. La ver­sion suiv­ante de ce pro­duit va cer­taine­ment apporter un peu de sou­p­lesse dans la recon­fig­u­ra­tion (ajout de disque, serveur). VMware a voulu la VSA très sim­ple, et preuves à l’appui, elle s’installe en max­i­mum 10 clicks, vrai­ment très impres­sion­nant (une semaine de design, de réflex­ions, de réu­nions avec le client pour 10 clicks…)

• VSP2447 Under­stand­ing Vir­tu­al­ized Mem­ory Per­for­mance Man­age­ment : cette ses­sion allait en détails dans les mécan­ismes de récla­ma­tion de la mémoire, mais n’apportait rien de plus que l’on en apprend dans le cours « Man­age for Per­for­mance ». Ce qui est intéres­sant : les dif­férents niveaux de récla­ma­tion : HIGH. Until 6% mem­ory free. No action ; SOFT. Between 6% and 4%. Action = bal­loon­ing ; HARD. Between 4% and 2%. Action = bal­loon­ing and swap­ping ; LOW. Between 2% and 1%. Action = swap­ping. La com­para­i­son entre le bal­loon­ing et le swap­ping était intéres­sante, dans le cas du bal­loon­ing, on gon­fle un process, ce qui va avoir pour con­séquence de réclamer au Win­dows toute la mémoire de sa free-list, puis éventuelle­ment de le forcer à swap­per la idle mem­ory, et en dernier recours, de swap­per l’active mem­ory (perf impact). Le VMK­er­nel swap­ping, lui, donne sim­ple­ment du disque au lieu de la RAM, donc indif­férem­ment, de l’idle ou active mem­ory seront sur du disque, donc gros impact. Vous me direz, « cela, on le savait » mais VMware à fait une analyse com­par­a­tive de l’impact au niveau des per­for­mances. Le bal­loon est une tech­nolo­gie très intéres­sante pour les per­for­mances : bal­loon­ing de la moitié de la RAM de la VM, impact sur les perf = 0. Avec le VMk­er­nel swap­ping, je vous laisse imag­iner… ensuite, quand le bal­lon gon­fle, les per­for­mances bais­sent, sim­ple­ment car Win­dows com­mence à swap­per de la mémoire active.

• VSP2774 Super­charge Your VMware Deploy­ment with VAAI and VAAI-enabled Stor­age Arrays : VAAI (vStor­age API for Array Inte­gra­tion, voir l’article de Cédric) per­met de déléguer cer­taines prim­i­tives (com­man­des SCSI) à la baie de stock­age, par exem­ple, lors de la copie d’une VM, chaque bloc de don­née passe de la baie de stock­age au serveur ESX pour retourner sur la baie de stock­age, avec VAAI, l’ESX donne une liste de com­mande à la baie de stock­age, qui les exé­cute toute seule. Grace à cela, les opéra­tions répéti­tives pren­nent beau­coup moins de temps, et char­gent net­te­ment moins le réseau de stock­age. Il était très intéres­sant de dis­cuter en détails toutes les prim­i­tives VAAI, et de voir exacte­ment où sont les avan­tages. Pariez que cette tech­nolo­gie, déjà présente chez beau­coup de fab­ri­cant, sera dans quelques temps une évidence.

• VSP3868 VMware vStor­age Best Prac­tices : très déçu de cette ses­sion, tenue égale­ment par le sup­port VMware. On nous a présenté ici les com­man­des pour voir les devices/volumes présen­tés à un ESX, vu les ques­tions de res­ig­na­ture de LUN et de mon­tage de LUN snap­shot, et quand cela deve­nait intéres­sant : que faire quand un Data­s­tore a été effacé (du moins la table de par­ti­tion), réponse : « là c’est le moment d’appeler le support… »

 Si un de ces thèmes vous inter­pelle, n’hésitez pas à me le dire, j’en ferai un sujet d’article.

A bien­tôt

Stéphane

A pro­pos de Stéphane Grim­buh­ler

http://ch.linkedin.com/in/sgrimbuhler

Stéphane GRIMBUHLER 

Vir­tu­al­iza­tion & Stor­age Archi­tect (VCP / VCAP-DCA)
VMware Instruc­tor (VCI)

twit­ter : @sgrimbuhler
sgrimbuhler@virtualgeek.ch