EN ROUTE VERS LE TOUT VIR­TUA­LI­SÉ route vers le tout vir­tuA­li­sé

La vir­tua­li­sa­tion des ser­veurs, du sto­ckage et des ré­seaux, aug­men­tée d’une couche d’au­to­ma­ti­sa­tion doit per­mettre aux en­tre­prises d’être aus­si ré­ac­tives que les start-up.

L'Informaticien - - SOFTWARE DEFINED - YANN SER­RA

Après une an­née 2015 fi­na­le­ment plus ex­pé­ri­men­tale que pré­vue, les tech­no­lo­gies Soft­ware Defined de­vraient être à l’hon­neur dans les en­tre­prises en 2016. L’ap­pel­la­tion Soft­ware Defined re­groupe tout l’ou­tillage lo­gi­ciel qui consiste à vir­tua­li­ser des res­sources ma­té­rielles, qu’il s’agisse des ser­veurs, du sto­ckage ou du ré­seau. L’en­jeu tech­nique est double. Il y a d’abord la pers­pec­tive d’ache­ter en in­terne des ma­chines gé­né­riques pour consti­tuer un ré­ser­voir de res­sources, le­quel se­ra dis­po­nible à la dé­coupe à chaque fois que les mé­tiers au­ront un nou­veau pro­jet à lan­cer. Il y a en­suite la pro­messe qu’une ap­pli­ca­tion fi­nale soit si in­dé­pen­dante des spé­ci­fi­ci­tés de l’in­fra­struc­ture sous-ja­cente qu’on puisse tan­tôt la tes­ter sur le da­ta­cen­ter in­terne, tan­tôt la mettre en production dans un Cloud ex­terne – ou l’in­verse – et, ce, sans ef­fec­tuer au­cune mo­di­fi­ca­tion, sans perdre le temps de s’adap­ter aux choix tech­niques de part et d’autre. Pour les en­tre­prises, il s’agit de par­ve­nir en 2016 à mettre le plus ra­pi­de­ment pos­sible de nou­velles ap­pli­ca­tions en production, pour res­ter com­pé­ti­tives face à des star­tup ex­trê­me­ment ré­ac­tives.

des mA­chines vir­tuelles trAns­por­tAbles

En ce qui concerne la puis­sance de cal­cul, ou Soft­ware Defined Da­ta­cen­ter (SDDC) les en­tre­prises vont de­voir tes­ter en 2016 deux choses : l’op­por­tu­ni­té de rem­pla­cer les ma­chines vir­tuelles par des contai­ners, d’une part, et un en­vi­ron­ne­ment d’au­to­ma­ti­sa­tion dit « DevOps », d’autre part, qui ajoute de l’au­to­ma­ti­sa­tion aux suites de vir­tua­li­sa­tion ha­bi­tuelles (vS­phere de VM­ware, Hy­per-V de Mi­cro­soft, KVM, etc.). Conçus comme des ma­chines vir­tuelles al­lé­gées, sans sys­tème d’ex­ploi­ta­tion propre mais fai­sant ap­pel à un OS père sur une VM ex­terne, ce qui per­met d’en exé­cu­ter entre 10 et 100 fois plus sur un même clus­ter de ser­veurs x86, les contai­ners sont en train de se stan­dar­di­ser au­tour du nou­veau for­mat OCF, cen­sé agir comme une couche d’abs­trac­tion vis-à-vis de l’in­fra­struc­ture sous-ja­cente. Avec un contai­ner OCF, il de­vien­drait ain­si pos­sible d’exé­cu­ter une ap­pli­ca­tion Win­dows dans un Cloud où les ma­chines vir­tuelles fonc­tionnent sous Linux, et vice-ver­sa. L’abs­trac­tion entre des ap­pli­ca­tions Win­dows et un OS Linux, ou l’in­verse, se­ra as­su­rée par la ré­cente mise en Open Source des rouages de .NET par Mi­cro­soft. Des so­lu­tions com­mer­ciales de contai­ners OCF de­vraient sor­tir dès le pre­mier tri­mestre 2016, no­tam­ment chez Red Hat, et elles fonc­tion­ne­ront soit par-des­sus des so­lu­tions de vir­tua­li­sa­tion clas­siques, soit di­rec­te­ment sur des ser­veurs phy­siques. En ce qui concerne les en­vi­ron­ne­ments DevOps, en re­vanche, trop d’op­tions co­existent pour qu’il s’en dé­gage à coup sûr une seule en 2016. Les so­lu­tions d’au­to­ma­ti­sa­tion his­to­riques de VM­ware, Mi­cro­soft, HP et IBM né­ces­sitent en­core d’être ma­ni­pu­lées par les équipes de l’IT. OpenS­tack tarde à mu­rir (lire L’In­for­ma­ti­cien n°141). Pi­vo­tal, Red Hat ou en­core CA lancent des por­tails clés en main, qui per­mettent vé­ri­ta­ble­ment aux dé­ve­lop­peurs d’ap­puyer sur un bou­ton pour mettre leurs ap­pli­ca­tions en production avec toutes les res­sources né­ces­saires, mais ces so­lu­tions doivent en­core faire leurs preuves.

l'es­sor du sto­ckAge ob­jet

Dans le do­maine du sto­ckage, ou Soft­ware Defined Sto­rage (SDS), deux ten­dances se dé­gagent. D’abord, c’est un suc­cès, le prin­cipe de si­mu­ler une baie de sto­ckage à par­tir des disques durs pré­sents dans des ser­veurs x86 s’est po­pu­la­ri­sé (voir l’ar­ticle dé­dié aux in­fra­struc­tures hy­per­con­ver­gées de ce même dos­sier), au point que des baies de sto­ckage dites SDS, deux fois moins chères que des baies SAN conven­tion­nelles, de­vraient dé­fer­ler sur le mar­ché dès les pre­mières se­maines de 2016. Ce se­ra très éco­no­mique à l’achat pour consti­tuer un ré­ser­voir de sto­ckage in­terne, mais ce­la ne ré­sou­dra en rien la pro­blé­ma­tique de por­ta­bi­li­té des ap­pli­ca­tions du da­ta­cen­ter in­terne à un Cloud ex­terne. D’au­tant que, en l’état, les baies SDS ne savent pas syn­chro­ni­ser leur conte­nu entre deux sites dis­tants. L’autre pan du SDS est le sto­ckage ob­jet. C’est la tech­no­lo­gie que les en­tre­prises vont de­voir adop­ter sur leurs baies de sto­ckage pour

per­mettre à leurs ap­pli­ca­tions d’al­ler cher­cher leurs don­nées via l’URL d’un do­maine, une méthode qui ré­sume la do­mi­ci­lia­tion en in­terne ou en ex­terne à une simple re­con­fi­gu­ra­tion de DNS. Pro­blème n°1, en­core faut-il que les baies de sto­ckage ac­ceptent le mode ob­jet. Les rares qui le font, comme les HP 3PAR, ne fonc­tionnent pas en clus­ter, ce qui li­mite la quan­ti­té de don­nées pos­sibles à la ca­pa­ci­té d’une seule baie. Il faut donc pas­ser par un lo­gi­ciel ex­terne, ca­pable de cha­peau­ter plu­sieurs baies en mode ob­jet. À date, ViPR d’EMC semble bien plus opé­ra­tion­nel qu’OpenS­tack, mais bien plus lié aux ta­rifs et au de­ve­nir d’un seul four­nis­seur aus­si. Pro­blème n°2, il existe plu­sieurs pro­to­coles ob­jet. La com­mu­nau­té OpenS­tack vou­drait que son mo­dule Swift fasse of­fice de stan­dard, aus­si bien sur les baies in­ternes (ViPR est com­pa­tible, ouf !) que chez les hé­ber­geurs de Cloud. Mais ni Ama­zon S3, ni Win­dows Azure ne le sup­portent. Ne pas pas­ser par du SDS de type ob­jet im­po­se­rait aux en­tre­prises de fixer les don­nées de leurs ap­pli­ca­tions sur un site unique, ac­ces­sible en pé­riode de test comme de production, ce qui reste une pos­si­bi­li­té.

Les com­pé­tences en pLace guident Le choix du sdn

Dans le do­maine du Soft­ware Defined Net­work (SDN), deux mo­dèles de fonc­tion­ne­ment conti­nue­ront de ba­tailler en 2016. Dans tous les cas, le but consiste à main­te­nir des sous-ré­seaux de ma­chines vir­tuelles ré­par­ties sur plu­sieurs ser­veurs phy­siques, soit pour des ques­tions d’équi­li­brage des charges en in­terne, soit parce que les ap­pli­ca­tions hé­ber­gées dans les VM sont opé­ra­tion­nelles sur plu­sieurs sites. Chez VM­ware, le SDN por­té par le lo­gi­ciel NSX consiste à ac­co­ler une table de rou­tage sur chaque hy­per­vi­seur. L’in­té­rêt est que l’équipe en charge des ser­veurs peut ad­mi­nis­trer des groupes de VM en­tiers avec des règles d’ac­cès – qui voit qui – dé­fi­nies pour les ap­pli­ca­tions. L’in­con­vé­nient est que ce­la ne fonc­tionne que sur les sites où NSX est dé­ployé. Chez les fa­bri­cants d’équi­pe­ment ré­seau, on pré­fère in­té­grer cette fonc­tion dans les rou­teurs et les com­mu­ta­teurs au tra­vers du pro­to­cole stan­dard VXLAN. Par rap­port à NSX, VXLAN ap­porte en plus la qua­li­té de ser­vice et per­met de dé­pas­ser la li­mite stan­dard de 4 000 VLAN. En re­vanche, une équipe d’ad­mi­nis­tra­teurs ré­seau re­de­vient obli­ga­toire. Et chaque construc­teur a sa ma­nière bien à lui d’in­di­quer à VXLAN com­ment re­con­naître les ma­chines vir­tuelles. Chez Cis­co, par exemple, le SDN ACI a la pos­si­bi­li­té de lire les at­tri­buts des VM en in­ter­ro­geant vS­phere et sa der­nière ver­sion pré­sente l’avan­tage ex­clu­sif de sa­voir re­con­naître des contai­ners au for­mat Do­cker, l’an­cêtre d’OCF. Dans les en­tre­prises, le choix d’un SDN par­ti­cu­lier ne semble pas se faire sur des as­pects tech­niques mais hu­main : la so­lu­tion adop­tée in fine est celle que les équipes en place sont le plus sus­cep­tibles de sa­voir ad­mi­nis­trer.

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.