Infrastructure IT 2.0

Bonjour amis lecteurs.

Que de temps a passé depuis mon dernier article. Les raisons sont multiples, avant tout une année très chargée et un doute quand on ton que mes articles allaient prendre maintenant que je suis du coté obscur (l’empire galactique des constructeurs-éditeurs). Mais je réalise deux choses: la première est que j’ai toujours mon objectivité et ma liberté de parole, si je trouve qu’un produit est nul je le dis ; et la deuxième, encore plus importante, est que j’ai choisi cette société (VCE) car je crois en ses solutions et en sa vision. Et parler de ce en quoi je crois, je le fais depuis 6 ans sur ce blog. Donc où est le problème?! Me revoilà!

Bref, VirtualGeek.ch n’était plus dans votre historique Internet Explorer et vous ne l’avez surement pas ouvert pour lire mes états d’âme. Mais j’espère que la machine est relancée et pouvoir vous fournir des infos intéressantes plus régulièrement. J’espère pouvoir vous éclairer un peu dans ce monde IT de plus en plus complexe et flou. J’espère que vous trouverez toujours notre contenu intéressant, mais par dessus tout, j’espère qu’en réalité vous n’utilisez plus Internet Explorer (et là, Microsoft me fait un procès)!

L’article que je vous propose aujourd’hui, traitera de l’infrastructure 2.0. Globalement, une infrastructure 2.0 peut être définie comme “tout ce qui n’est pas du build-your-own”. Depuis pas mal d’années, m’étant très intensément focalisé sur la virtualisation, je dois dire que je voyais l’infrastructure comme une sorte de mal nécessaire, qui allait me fournir le compute et le stockage nécessaire pour monter des environnements VMware de toute beauté (ou Citrix, ok Christophe). Toutes ces années en tant que consultant, j’avoue que l’infrastructure me faisait peur (mon psy m’a dit que je devais affronter mes peurs). Avant un upgrade, un patching, un changement de baie de stockage, je passais rapidement à l’église allumer un cierge avant d’aller chez le client. Aujourd’hui avec le recul, mon expérience de troubleshooteur de l’extrême (l’appellation n’est pas de moi) me permet de faire le point et d’affirmer qu’environ 80% des pannes et instabilités de l’infrastructure sur lesquelles j’ai dû intervenir sont liées à des problèmes d’interopérabilité de celle-ci. On upgrade vSphere : purple-screen car il faut upgrader les firmwares des serveurs. On change le PSP en round-robin : LUN trespass ou perte de Datastore car la baie doit être mise à jour. On active le IP-hash network teaming : perte de réseau car l’ether-channel est mal configuré sur les switches physiques. Sans parler de zoning avec multiples initiateurs, iSCSI sans Jumbo-frames, etc etc. Ces exemples sont issus de mon expérience et j’en ai encore des dizaines. J’en suis arrivé à deux conclusions simples, et qui ont en grande partie décidées mon choix de travailler pour le leader de l’infrastructure convergée:

  • Aujourd’hui une infrastructure traditionnelle ne peux plus garantir les SLA imposés aux applications par le Business (tout est devenu critique, quelle société peut aujourd’hui se passer ne serait-ce que de sa messagerie?).
  • l’adoption de nouvelles technologies ou tout projets positifs pour le Business sont freinés par une charge opérationnelle toujours grandissante et une augmentation de la complexité.

Pour expliquer le dernier point, il est intéressant de lire IDC, qui considère qu’une équipe IT passe entre 50% et 70% de son temps à maintenir une infrastructure plutôt qu’à la faire évoluer en fonction des besoins du Business (50% dans le cas ou elle est hébergée chez un provider). En gros, on passe plus de la moitié de son temps à garder les lumières allumées dans le Datacenter. Pourquoi? La raison est simple, et pour l’expliquer, vous me pardonnerez une petite analogie, vous savez à quel point j’aime les analogies:

Imaginez…

… que vous vivez dans un monde où si vous avez besoin d’une voiture, vous devez la monter vous-même. Vous allez donc vous mettre en chasse des différents composants. Heureusement cela fait déjà 5 ans que vous suivez activement tout ce qui se fait sur le marché des boites à vitesses et vous avez un collègue spécialisé dans les moteurs, un autre dans les roues, un quatrième dans les siège, un autre dans les interfaces utilisateurs (commandes, volant, levier de vitesse, etc.). Chacun d’entre vous à déjà bon nombre de voiture à gérer, mais vous devez prendre le temps d’en construire une nouvelle. Vous allez donc organiser des meetings avec les différents leaders du marché dans chacun de ces domaines, puis faire vos choix, puis commander, puis attendre les cartons. Ensuite le long et fastidieux travail d’assemblage commence. Chacun d’entre vous est spécialiste de son domaine et donne ses propres requirements.

Chacun a donc assemblé sa part, en respectant les best-practices de son domaine et du fabriquant choisi. Mais ayant toutefois assez peu d’idées des interactions avec les réglages qu’ont faits les autres. Une fois l’ensemble monté, on va démarrer la voiture et affiner, régler, ajuster, serrer des visses, jusqu’à ce que l’ensemble nous paraisse cohérent. Finalement vient le moment du tour d’essai sur les quais, capote baissée et musique à fond, on est fier de nous! Mais là une autre voiture, assemblée par le concurrent nous dépasse en trombe! Mince! (Pour rester poli). Comment diable savoir quoi faire pour aller plus vite? Est-ce à cause d’un choix d’un des composant? Un réglage? Le conducteur? Comment savoir. Et surtout comment corriger les problèmes alors que tout le budget a été dépensé? Alors on va faire appel aux constructeurs, à des consultants, pour s’assurer que c’est assemblé au mieux.

Puis un jour ou l’autre, quelqu’un va bien devoir signer en bas de page pour que la voiture parte en production! Une fois que la voiture a rejoint la flotte des voitures de l’entreprise, son entretien s’ajoute à celui des autres. On va la nettoyer, serrer des visses et boulons environ 4 jours par semaine et elle roulera 3 jours.

Un jour la voiture sera en panne, et il faudra à ce moment là savoir chez quel fournisseur allez sonner. Le problème vient-il du moteur, des roues, du software? Et dans quelques années, quand on s’apercevra qu’elle est vraiment plus lente que les autres, et que l’entreprise pourrait gagner plus d’argent avec une voiture plus rapide, on va se demander quelle pièce on peut changer dans la voiture pour qu’elle aille plus vite. Changera-t-on les roues? Le moteur? Le pot d’échappement (si on a un moteur Allemand…)?

On nage en pleine fiction vous dites-vous? Relisez en pensant à une infrastructure IT traditionnelle. Il y aura peut-être quelques différences, par exemple, pour reporter la responsabilité, vous allez peut-être utiliser un partenaire pour les choix technologiques et sécuriser l’assemblage, mais quelles garanties avez-vous?

Fort de ce constat, l’Architecture de Référence est née il y a déjà environ 6-8 ans. Avec une AR, on vous aide à monter une infrastructure en vous conseillant des produits, des versions de soft et firmware et des réglages. Ensuite l’infrastructure vit sa vie et perd tous les avantages de standardisation initiaux. C’est comme acheter un meuble chez un gros vendeur Suédois jaune et bleu. On vous fourni un schéma de montage ou on vous vend du service, mais ensuite vous faites ce que vous voulez du meuble (c’était ma dernière analogie, promis). C’est ainsi qu’est né le convergé et l’hyper-convergé (attention à ceux qui vous diront que le convergé est mort et l’hyper-convergé est le nouveaux standard… j’y reviens).


Le point commun de ces infrastructures 2.0 est qu’elles sont, si elles sont bien faites, 100% maitrisées et standardisées par leur vendeur. Vous avez non-seulement une garantie de cohérence et d’interopérabilité lorsque vous en faites l’acquisition, mais en plus tout au long de la vie de la solution, le constructeur (ou intégrateur dans le cas de VCE) va vous garantir de façon continue cette interopérabilité. En cela, les deux plateformes sont légèrement différentes:

  • Le convergé est une plateforme type P2, faite pour des applications traditionnelles (2 ou 3 tiers, monolithique, scale-up). Pour ces applications, habituellement le cœur des entreprises, l’infrastructure doit fournir des très grandes garanties de stabilité, de tolérance de pannes et de redondance. On fera un site de DR ou BC, de la réplication, du miroring de stockage etc.
  • l’hyper-convergé, malgré certains messages (dangereux) que vous entendrez peut-être, s’adresse à des applications nouvelle génération (dites P3). Les critères de ces applications sont : l’auto-résilience (aucun impact sur l’applicatif en cas de perte d’une partie de l’infra) ; distributivité (l’application est capable de se déployer pour supporter une augmentation de charge ou une panne hardware); un mode de croissance globalement horizontal (l’application grandit en se multipliant).

 

haribo scalability

Puisque ces nouvelles applications ne souffrent pas des pannes hardwares, ou très peu, c’est un cas idéal pour de l’hyper-convergé basé sur du compute commodité (fabriqué à la chaine à moindre prix, avec des tests et des garanties de fiabilité inférieures). Prenons un exemple de workload idéal pour de l’hyper-convergé : le VDI. C’est scale-out (le VDI grandit horizontalement, on rajoute des users donc des VMs) ; très faible croissance scale-up (il est très improbable qu’un seul desktop requiert beaucoup plus de ressources que la moyenne) ; auto-résilient (si on perd un ESX, les desktops sont recréés à la volée sur d’autres). Je précise que le VDI n’est pas à proprement parlé un workload type P3, mais c’est un bon exemple.

Je reviendrai dans un prochain article sur les différences entre Converged et Hyper-Converged mais il est important de ne pas faire l’amalgame et de ne pas se laisser entrer l’idée au pied de biche dans la tête que l’hyper-convergé est l’infra 3.0 ou du convergé 2.0. C’est simplement un nouveau use-case pour des nouveaux workloads. Pour information, IDC (encore eux) on établi qu’aujourd’hui, seulement 28% des applications des clients sont de type plateforme 3 et donc par extension adaptées à une infrastructure hyper-convergée (attention je ne dis pas pour autant qu’aucune application P2 ne peut tourner sur de l’hyper-convergé). Ce chiffre va passer à 60% en 2020 mais ce qui est intéressant (voir image) c’est que finalement relativement peu d’applications P2 vont être remplacées par des applications P3. Ce 60% s’explique par une explosion du nombre global d’applications et qui seront, pour la plupart, du type P3. Comment IDC peut prévoir cela? Ils ont interrogé des développeurs pour savoir quel est le type des applications développées aujourd’hui et demain.

IDC P2 & P3 apps

Pour terminer, en guise de conclusion, voici selon moi les messages les plus importants :

  • l’hyper-convergé n’est pas une évolution du convergé. Différents workloads, différentes applications, différentes architectures et infrastructure.
  • Convergé, hyper-convergé, peut-être demain Supra-convergé ou Méga-convergé! Une chose est sur (pour moi) le modèle traditionnel build-your-own va disparaître car il ne peut plus soutenir les besoins du business.
  • N’oubliez pas : l’application définit l’infrastructure et non le contraire.

Merci de m’avoir lu. J’espère que ces informations vous auront été utiles et n’hésitez pas à commenter.

A bientôt.

Stéphane Grimbuhler.

 

————————————————————————————–

Articles à suivre :

  • Convergé Vs. Hyper-convergé : les différences, les use cases
  • SAP-HANA virtualisé sur TDI: que la force soit avec vous
  • Docker’s revolution (si j’ai le courage)

(n’hésitez pas à me dire dans les commentaires sur quel sujet vous voulez me voir travailler en priorité)

 

 

Disclaimer : all opinions in this article are mine and would not reflect any official position (from VirtualGeek.ch or companies we work for)

 

 

 

 

A propos de 

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

Stéphane GRIMBUHLER 

Virtualization & Storage Architect (VCP / VCAP-DCA)
VMware Instructor (VCI)
vExpert 2012 to 2014

twitter : @sgrimbuhler
sgrimbuhler@virtualgeek.ch

  1. Article très intéressant !
    Je vote pour un “Convergé Vs. Hyper-convergé : les différences, les use cases”, cela permettra aux responsables infra de redéfinir leurs réels besoins 😉

  2. Merci pour cet article,

    Je vote aussi pour “convergence et hyper-convergence”

  3. Art. Intéressant mais au final que propose VCE?
    Pour moi il manque la conclusion.

  4. Intéressant. Je vote aussi pour “Convergé Vs. Hyper-convergé : les différences, les use cases”

Laisser un commentaire


NOTE - Vous pouvez utiliser les éléments et attributs HTML tags and attributes:
<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>