Pen­sé pour les en­vi­ron­ne­ments vir­tua­li­sés

L'Informaticien - - SOLUTIONS IT - Loïc Du­val

LUne so­lu­tion sans agent

Dans la né­ces­saire conso­li­da­tion des da­ta cen­ters, la vir­tua­li­sa­tion a in­tro­duit de nou­velles contrainte­s que des ou­tils comme Veeam Ba­ckup & Re­pli­ca­tion savent au­jourd’hui le­ver pour fa­ci­li­ter la mise en oeuvre de nou­veaux scé­na­rios de re­prise d’ac­ti­vi­té après si­nistres.

a vir­tua­li­sa­tion a pro­fon­dé­ment trans­for­mé les pro­blé­ma­tiques de ges­tion des pannes d’une ma­nière gé­né­rale et de ges­tion des sau­ve­gardes en par­ti­cu­lier. D’un cô­té la vir­tua­li­sa­tion, avec sa conso­li­da­tion in­ten­sive et sa dis­tri­bu­tion « Live » des VM entre les ser­veurs a of­fert de nou­velles pers­pec­tives et de nou­velles so­lu­tions en ma­tière de mises en oeuvre de PRA et de PCA. Mais d’un autre cô­té, elle a pa­ral­lè­le­ment pro­fon­dé­ment com­plexi­fié la pla­ni­fi­ca­tion et la réa­li­sa­tion des sau­ve­gardes : ex­plo­sion des vo­lu­mé­tries à sau­ve­gar­der par ser­veurs phy­siques, ex­plo­sion des es­paces de sto­ckage né­ces­saires aux sau­ve­gardes, sa­tu­ra­tion des En­trée/Sor­tie, plans de sau­ve­garde exis­tants ren­dus ca­duques, com­plexi­fi­ca­tion du tra­vail d’ad­mi­nis­tra­tion des sau­ve­gardes et de la vé­ri­fi­ca­tion de la qua­li­té/ fia­bi­li­té des ba­ckups…

À pro­blé­ma­tiques spé­ci­fiques, ré­ponses spé­ci­fiques

La so­lu­tion de sau­ve­garde et ré­pli­ca­tion « Veeam Ba­ckup & Re­pli­ca­tion » a été pen­sée et créée spé­ci­fi­que­ment pour les en­vi­ron­ne­ments vir­tua­li­sés. Sa prin­ci­pale force re­pose sur sa sim­pli­ci­té de mise en oeuvre – il n’y a au­cun agent à dé­ployer – ain­si que sur sa technologi­e de cap­tures par snap­shots in­cré­men­tiels. Le pre­mière sau­ve­garde est re­la­ti­ve­ment longue, mais les cap­tures suc­ces­sives sont ins­tan­ta­nées, ou presque, et conservent la co­hé­rence de l’image, ce qui per­met, le cas échéant, de re­dé­mar­rer une VM di­rec­te­ment de sa sau­ve­garde ! L’ab­sence d’agent à dé­ployer sim­pli­fie évi­dem­ment la mise en oeuvre d’une telle so­lu­tion. Ici, tout passe par les API des hy­per­vi­seurs. Veeam ex­ploite au maxi­mum les fonc­tion­na­li­tés of­fertes par ces der­niers plu­tôt que de cher­cher à adap­ter une so­lu­tion de sau­ve­garde tra­di­tion­nelle à des en­vi­ron­ne­ments vir­tua­li­sés. Une in­té­gra­tion qui rend éga­le­ment la so­lu­tion com­pa­tible avec tous les OS puis­qu’elle se greffe à même l’hy­per­vi­seur et non sur les ma­chines vir­tuelles. Nous avons pro­fi­té de la sor­tie de la ver­sion 6.5, com­pa­tible Hy­per-V 3 et Win­dows Server 2012, pour nous re­pen­cher sur cette so­lu­tion plu­tôt éton­nante en nous fo­ca­li­sant sur l’hy­per­vi­seur Mi­cro­soft jus­qu’ici plu­tôt moins bien lo­ti que son concur­rent VM­Ware.

Une ar­chi­tec­ture ori­gi­nale

Les pre­mières ver­sions de Veeam B&R étaient mo­no­li­thiques. Ce n’est plus vrai de­puis la Ver­sion 6 qui per­met non seule­ment de gé­rer des flux dif­fé­rents et pa­ral­lèles mais aus­si de pi­lo­ter et cen­tra­li­ser, en une même con­sole, l’ad­mi­nis­tra­tion de mul­tiples sites dis­tants. L’ar­chi­tec­ture re­pose sur trois mo­dules, trois rôles : un Ba­ckup Server – qui joue le rôle d’or­don­nan­ceur des jobs en éva­luant les connexions, les charges des proxys, etc. –, des Da­ta-Mo­vers – qui jouent le rôle de proxys entre la source et l’es­pace de sau­ve­garde et se charge du trai­te­ment et dé­pla­ce­ment des don­nées – et des Re­po­si­to­ries – les em­pla­ce­ments de sau­ve­garde qui contiennen­t les don­nées sau­ve­gar­dées et les fi­chiers auxi­liaires.

Pa­ral­lé­li­sa­tion des flux

Cette ar­chi­tec­ture dis­tri­buée per­met de consi­dé­ra­ble­ment ré­duire les temps de sau­ve­garde ou de ré­pli­ca­tion de mul­tiples ser­veurs no­tam­ment au tra­vers d’un WAN. Elle per­met aus­si de contrô­ler plus ai­sé­ment les mon­tées en charge en trans­fé­rant les tra­fics de sau­ve­garde/ ré­pli­ca­tion vers les Proxys plu­tôt que di­rec­te­ment vers le ser­veur cible de sau­ve­garde. On peut en ef­fet dé­cor­ré­ler le Ba­ckup Server et le Da­ta-Mo­ver ain­si qu’uti­li­ser plu­sieurs Da­ta-Mo­vers pour ré­duire consi­dé­ra­ble­ment les temps de sau­ve­garde. De même, on peut mul­ti­plier les « Re­po­si­to­ries » afin de mieux pa­ral­lé­li­ser les flux. Se­lon nos tests, le simple fait d’ajou­ter un se­cond Da­ta-Mo­ver peut di­vi­ser les temps de sau­ve­garde par deux, tout dé­pend de la po­si­tion du Da­ta-Mo­ver et des I/O des Re­po­si­to­ries. Cha­cun de ces rôles peut être vir­tua­li­sé, in­utile d’y dé­dier des ser­veurs phy­siques. Vir­tua­li­ser ain­si les rôles per­met, en outre, de les dis­tri­buer plus in­tel­li­gem­ment (et plus ai­sé­ment) dans son in­fra­struc­ture. Si Ba­ckup Server et Proxys doivent être hé­ber­gés sous Win­dows, les Re­po­si­to­ries peuvent être in­dif­fé­rem­ment hé­ber­gés sous Win­dows, Li­nux ou n’im­porte quel dos­sier par­ta­gé CIFS du ré­seau.

Des sau­ve­gardes in­tel­li­gentes

L’un des élé­ments fon­da­men­taux de Veeam ré­side dans son po­ten­tiel de pré­ser­va­tion des es­paces de sto­ckage. Les Proxies réa­lisent à la fois une com­pres­sion et une dé­du­pli­ca­tion des don­nées. C’est évi­dem­ment fon­da­men­tal. Les ma­chines vir­tua­li­sées tendent ef­fec­ti­ve­ment à par­ta­ger un nombre non né­gli­geable de don­nées – ne se­rait-ce que les fi­chiers du sys­tème. Du­rant nos tests, la sau­ve­garde de 14 VM Win­dows Server re­pré­sen­tait au dé­part 170 Go de don­nées. L’es­pace oc­cu­pé par la pre­mière sau­ve­garde Veeam com­plète n’en oc­cu­pait que 32 Go. Après une se­maine d’ac­ti­vi­té, et deux sau­ve­gardes com­plé­men­taires réa­li­sées, l’oc­cu­pa­tion sur le Re­po­si­to­ry res­tait in­fé­rieure à 44 Go – au lieu de 170 Go x 3. Veeam pro­pose dif­fé­rents modes de sau­ve­garde. Le mode « For­ward In­cre­men­tal » réa­lise une pre­mière sau­ve­garde com­plète dans un fi­chier .VBK, puis y ajoute des sau­ve­gardes in­cré­men­tales dans des fi­chiers .VIB. Ce mode est as­sez pra­tique si vous de­vez en­suite réa­li­ser une sau­ve­garde sur bandes – sa­chant que Veeam ne gère au­jourd’hui que des Re­po­si­to­ry disques et pas de sys­tèmes de bandes –, mais l’oc­cu­pa­tion disque est su­pé­rieure et les res­tau­ra­tions plus lentes. Dans le mode « Re­ver­sed In­cre­men­tal », les in­cré­ments sont

in­jec­tés dans le VBK pour conser­ver une sau­ve­garde com­plète tou­jours ac­tuelle et les an­ciens blocs mo­di­fiés sont trans­fé­rés vers des fi­chiers VBR. La charge I/O sur le ser­veur Re­po­si­to­ry est bien su­pé­rieure mais offre une plus grande sou­plesse en ma­tière de ré­ten­tion d’images dans le temps et ac­cé­lère ins­tan­ta­né­ment les res­tau­ra­tions. Une fonc­tion « Syn­the­tic Full » mixe les deux concepts et per­met de réa­li­ser un « For­ward In­cre­men­tal » tout en ré­gé­né­rant un VBK com­plet à in­ter­valle ré­gu­lier. Il est aus­si pos­sible de trans­for­mer une sau­ve­garde « Re­ver­sed » en « For­ward » à une cer­taine date.

Des res­tau­ra­tions ga­ran­ties

Mais la vraie force d’une so­lu­tion de sau­ve­garde se me­sure à ces op­tions de res­tau­ra­tion. Et en la ma­tière, Veeam se dé­marque et fait très fort. Tout d’abord, il est pos­sible de res­tau­rer in­té­gra­le­ment une VM, ou seule­ment un en­semble de fi­chiers d’une VM, en ex­plo­rant le conte­nu des disques. Il est aus­si pos­sible, dans cer­taines condi­tions et grâce à une ex­ten­sion spé­ci­fique (U-AIR), de res­tau­rer des ob­jets comme l’Ac­tive Di­rec­to­ry, ou une boîte aux lettres – voire juste un email – d’Ex­change Server. Sur­tout, son prin­cipe de sau­ve­garde main­tient la co­hé­rence des VMDK et des VHD. Dès lors Veeam vous per­met de re­lan­cer di­rec­te­ment une VM à par­tir des fi­chiers de sau­ve­garde ! Les uti­li­sa­teurs peuvent donc de­meu­rer opé­ra­tion­nels pen­dant que vous oeu­vrez à la ré­pa­ra­tion de l’in­ci­dent. En­fin, et ce n’est pas la moindre de ses qua­li­tés, Veeam in­cor­pore éga­le­ment une fonc­tion « Su­reBa­ckup » qui per­met de vé­ri­fier au­to­ma­ti­que­ment la « res­tau­ra­bi­li­té » de chaque sau­ve­garde – chaque VM, mais aus­si chaque point de res­tau­ra­tion – sans avoir be­soin de ma­té­riel com­plé­men­taire. Pour ce­la, Su­reBa­ckup dé­marre phy­si­que­ment vos VM de­puis la sau­ve­garde dans un en­vi­ron­ne­ment vir­tua­li­sé iso­lé, un Lab vir­tuel. On peut y as­so­cier des tests au­to­ma­tiques pour vé­ri­fier que les fonc­tions hé­ber­gées par la VM sau­ve­gar­dée sont bien opé­ra­tion­nelles. Pour en sa­voir plus, Veeam pro­pose une ex­cel­lente vi­déo ex­pli­ca­tive ( http://bit.ly/Zi423h).

Ré­pli­ca­tion

Veeam est aus­si une so­lu­tion de ré­pli­ca­tion – si­non prin­ci­pa­le­ment, se­lon vos usages. Les fonc­tion­na­li­tés avan­cées de com­pres­sion/dé­du­pli­ca­tion et son ar­chi­tec­ture dis­tri­buée servent évi­dem­ment de fon­da­tion aux fonc­tions de ré­pli­ca­tions. Toutes sortes de scé­na­rios de ré­pli­ca­tion et de PRA peuvent être mis en oeuvre – à tra­vers le Da­ta­Cen­ter comme à tra­vers un Wan, entre un siège et des fi­liales, etc. – avec une seule vraie li­mi­ta­tion : il faut un même hy­per­vi­seur de chaque cô­té ! Il n’est donc pas pos­sible d’ima­gi­ner une ré­pli­ca­tion entre un ser­veur VM­Ware et un ser­veur Hy­per-V grâce à Veeam. En­fin, sa­chez que le lo­gi­ciel com­plet est fac­tu­ré au « So­cket » – donc pas de li­cences par VM à sau­ve­gar­der, par proxies/ re­po­si­to­ries, ou par coeur. Il existe même une ver­sion gra­tuite de Veeam Ba­ckup pour les TPE – sans ré­pli­ca­tion, ni scrip­ting, ni sau­ve­garde in­cré­men­tielle – ce qui li­mite son in­té­rêt et ses usages.

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.