Archive dans juin 2018

Et l’écologie ?

Il y a plusieurs moyens d’apporter sa contribution à rendre la planète moins polluée, que ce soit dans sa vie personnelle ou dans sa vie professionnelle.

Dans la vie professionnelle notamment en informatique le choix du matériel (serveur, stockage, switch, …) est important mais pas suffisant. En effet le logiciel a une part plus importante que le matériel à la fois sur la consommation énergétique directe induite par la consommation électrique des équipements (serveur, stockage, switch, … ) et sur la consommation énergétique indirecte induite par la climatisation pour diminuer la dissipation thermique.

Alors pourquoi le choix du logiciel a-t-il un impact plus importante que le choix du matériel ?

Le premier levier est la consolidation des composants du Data Center en les virtualisant (SDDC : Software Defined Data Center). L’hyperviseur de par ses algorithmes d’optimisation et notamment la mémoire, a le meilleur taux de consolidation du marché. Avec vSphere vous hébergerez plus de VMs sur un serveur physique qu’avec tout autre hyperviseur. Ainsi, dans le DC, il y aura moins de serveurs physiques, donc moins de connectiques réseaux, moins de connectiques stockage réduisant ainsi le nombre de switches réseaux et SAN. La consommation électrique est réduite, la dissipation thermique aussi, le DC peut-être plus petit.

En plus du fort taux de consolidation possible, les fonctionnalités intégrées à l’hyperviseur permettent également d’obtenir des gains de consommations. DPM (Distributed Power Management), DRS (Distributed Ressource Scheduler) et vMotion fonctionnent conjointement pour optimiser l’utilisation des ressources sur un minimum d’hyperviseurs. DPM va analyser la demande de ressource et définir combien d’hyperviseurs sont nécessaires pour honorer cette demande, s’il y a trop d’hyperviseurs, il va demander à vMotion de déplacer à chaud les VMs afin de les concentrer sur un nombre réduit d’hyperviseur, ceux qui se retrouve sans VMs seront arrêter physiquement. Si DRS se rend compte que la demande s’accroit et que les ressources risques de ne plus être suffisantes, il va demander à DPM de démarrer le nombre d’hyperviseurs nécessaires et à vMotion et de déplacer certaines VMs afin d’équilibrer les charges entres eux. Pour que cela fonctionne, les serveurs physiques doivent supporter l’un des protocoles suivants : IPMI, ILO ou WOL.

 

Grace à la virtualisation du réseau et de la sécurité, tous les trafics de communication Est-Ouest (trafics intra DC) qui représentent environ 80% du trafic total, se font sans passer par le coeur de réseau car les fonctionnalités de routage, switch et firewall sont directement intégrées dans l’hyperviseur. En évitant ainsi de passer par les équipements physiques (voir illustration ci-dessous), cela permet de réduire en nombre et/ou en taille ces équipements.

 

Et ceci peut encore être optimisé ! Grâce aux tableaux de bord vRealize Operations (vROps) :

Vous pouvez connaitre les VMs qui ont été déployées, démarrées mais pas ou plus utilisées. Elles consomment tout de même de l’espace de stockage et des ressources processeur et mémoire :

 

Vous pouvez lister les VMs déployées mais éteintes depuis un certain temps qui consomment de l’espace stockage :

 

 

Une étude IDC détaillée (en Anglais) explique les calculs qui ont permis de mesurer les gains obtenus grâce à la virtualisation de l’ensemble des composants du Data Center et elle estime que les solutions VMware ont permis d’économiser 450 millions de tonnes de CO2 depuis la création de la société VMware : https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/company/vmw-data-center-energy-and-carbon-emission-reductions-through-compute-storage-and-networking-virtualization.pdf

Pourquoi PKS (VMware Pivotal Container Service)

Après les VMs, les containers, c’est autour des orchestrateurs de containers de rencontrer un vif succès, mais dans ce domaine les modes ont été éphémères, il y en a un qui sort son épingle du jeu c’est Kubernetes et cet engouement à l’air de s’installer. Je n’ai pas rencontré un client qui ne me parle de ça. Ils ne sont pas tous au même niveau de connaissance et d’appétence mais tous y vont, certes à tâtons car c’est un monde nouveau mais ils y vont. Pour être rassurés, les clients souhaitent se reposer sur des éditeurs pérennes, en qui ils ont confiance, qui ont des solutions robustes et un support fiable. C’est une des raisons pour laquelle PKS est rassurante.

PKS est une solution issue du partenariat entre VMware, Pivotal et Google où chacun apporte sa contribution. D’un point de vu macroscopique VMware apporte la partie registre des containers ainsi que la virtualisation du réseau et de la sécurité, Pivotal apporte la partie gestion du cycle de vie des cluster Kubernetes et Google son orchestrateur de containers kubernetes.

PKS ne modifie pas Kubernetes et n’apporte pas de surcouche ou d’interface intermédiaire. Le Kubernetes qui est utilisé n’est pas non plus un “fork” (une sous branche) mais belle est bien celui de Google, toutes les APIs et les lignes de commande ainsi que les applications que vous allez développer seront compatibles avec un Kubernetes hors PKS. A quelques semaines près vous aurez toujours la dernière version stable de Kubernetes qui sera supportée.

Lorsqu’il est hébergé sur le data center privé, PKS repose sur le SDDC (Software Defined Data Center) de VMware, il utilisera à minima les ressources vSphere et idéalement s’appuiera sur vSAN et NSX. Certains éléments de kubernetes seront surveillés est relancés par PKS, certains éléments de PKS quant à eux seront surveillés et relancés par vSphere HA. Grace à PKS, Kubernetes utilisera de manière transparente la partie stockage de vSphere pour le stockage éphémère ou pour le stockage persistant, lorsque vSAN est présent, les classes de stockage Kubernetes ou les volumes Docker pourront bénéficier des politiques de stockage de vSAN comme par exemple définition de la tolérance aux pannes (FTT). PKS couplé à NSX offre un vrai SDN et une sécurité accrue. Les fonctionnalités de routage, switching et sécurité sont intégrées et distribuées aux hyperviseurs ce qui offre de meilleures performances, une meilleure scalabilité et une plus grande sécurité.  Lorsque des pod Kubernetes sont déployés, les réseaux, les routeurs et les services tels que le load balancing sont automatiquement provisionnés. Les Network Policy utilisé par Kubernetes permettent de définir des règles de sécurités qui sont traduites par des règles de firewall NSX (des vraies pas des ACLs). Il est possible de définir des règles de sécurités inter Pod. Encore une fois c’est transparent pour le développeur, il a juste besoin de connaitre les commandes/API kubernetes et Docker.

 

 

Pour connaitre les flux réseaux, la fonctionnalité Traceflow permet de les visualiser entre deux composants parmi les critères suivants logical switch, VM, IP et MAC. 

Si des règles de sécurité firewall ont bloquées les communications, elles seront aussi affichées ce qui permettra de vite identifier quelle règle est en cause.

 

PKS permet de créer des cluster Kubernetes à la demande. Chaque cluster Kubernetes est indépendant et isolé, plusieurs versions de Kubernetes peuvent résider sur une même plate-forme mais aussi pour plusieurs usages, dev, tests, pré-prod, … ou encore plusieurs “tenant” (colocation. Si vous possédez un portail self service tel que vRA (vRealize Automation), vous pouvez proposer un blueprint Kubernetes As A Service et offrir à un développeur ou à une équipe de développeurs de provisionner de manière automatisée des cluster Kubernetes.

PKS permet de gérer le cycle de vie complet des cluster kubernetes et de ses composants allant de l’installation, des mises à jour, de l’application de patches et le “scaling” du cluster, le tout à chaud.

 

PKS intègre un registre des containers privés (Harbor) pour y déposer vos images que vous ne souhaitez pas mettre sur un registre public. Il intègre une gestion des rôles d’accès (RBAC). Harbor peut scanner les images à la recherche de vulnérabilités, signer les images et répliquer les images sur un autre registre de containers. 

 

Si vous utilisez vROps (vRealize Operations) vous aurez la possibilité de surveiller vos clusters Kubernetes ainsi que l’infrastructure qui l’héberge et avoir ainsi des corrélations de performance et d’incidents.

 

 

Pour monitorer le fonctionnement des applications et/ou les métriques métiers comme par exemple le nombre de transaction par seconde, vous pouvez utiliser WaveFront :

 

 

Pour résumer les avantages de PKS :

  • Dernière version stable de Kubernetes natif de Google, même lignes de commandes, même API. Pas de surcouche !
  • Gestion complète du cycle de vie de Kubernetes, installation, mise à jour, application de patch et scalabilité.
  • Kubernetes As A Service, des cluster Kubernetes à la demande indépendant et isolé.
  • Utilisation du SDDC VMware permettant d’avoir un environnement Kubernetes résilient, performant et sécurisé.
  • Provisionnement automatique et natif de load balancer, réseaux, règles de sécurité et niveaux de service stockage.
  • Possibilité de monitorer l’infrastructure complète et les applications.

 

Les avantages non techniques :

  • Gain de temps en formation et en développement : les développeurs non que Kubernetes et Docker à connaitre.
  • Risques réduits : PKS est supportée par VMware et repose une plate-forme SDDC sécurisée.

Pour plus d’information https://cloud.vmware.com/fr/pivotal-container-service/resources

Pour la tester : http://labs.hol.vmware.com/HOL/catalogs/lab/4249 

C’est gratuit ! ?

€€€€

Combien de fois j’ai entendu cette phrase : Hyper-V et OpenStack c’est gratuit ! ? des centaines de fois, ou encore VMware c’est le top mais ça coute cher.

Certe les solutions VMware ont un coût, il est induit principalement par la recherche et développement et par la valeur ajoutée qu’elles apportent. La cherté subsiste s’il n’y a pas de valeur constatée. Pour faire un comparatif objectif, il faut prendre en compte toute la chaine de coûts et non pas seulement la partie CAPEX (acquisition) des licences, il faut intégrer la partie OPEX (opérationnelle) et tous les autres paramètres induits. Il existe beaucoup d’études comparatives qui démontrent la réalité des choses, je vais lister ici les éléments de ce qui m’a été remonté par mes clients.

Sur la partie hyperviseur :

  • vSphere a la meilleure densité VM par serveur sans compromettre sa stabilité. Sur un serveur ça peut-être paraître négligeable mais sur un grand nombre ça ne l’est plus. Un serveur a bien sûr un coût mais aussi, prend de la place en salle machine, consomme de l’énergie électrique et en climatisation, il consomme occupe aussi des ports réseau et éventuellement SAN. Les applications avec une tarification à la CPU nécessitent moins de licences.
  • vSphere à un noyau léger et stable, il consomme très peu stockage et subit très peu de panne ce qui induit beaucoup moins d’incidents à gérer.
  • Les opérations d’administration du quotidien prennent moins de temps, déplacement à chaud de VMs, déploiement de nouveaux hyperviseur, configuration réseau et stockage
  • vSphere fonctionne comme une ferme d’hyperviseur où toutes les ressources sont fédérées, mutualisées, l’équilibrage des charges se fait automatiquement et libère tu temps à l’administrateur pour qu’il se consacre à des tâches plus gratifiantes.

Sur la partie Cloud, on me mettait souvent en compétition avec les solutions Open Source comme OpenStack, il y a quelques années elles avaient le vent en poupe, c’est beaucoup moins le cas maintenant. Les arguments étaient, c’est gratuit et ce n’est pas vendor lock-in. Dans les fait ce n’est pas le cas, force est de constaté, ce qui n’est pas dépensé chez un éditeur doit l’être en ressource humaine pour développer et maintenir toute l’automatisation déjà présente dans les solutions payantes. Quelques exemples de ce qui est à développer sur OpenStack et qui est natif dans vRA (vRealize Automation) :

  • L’installation de vRA est beaucoup plus simple, en quelques heures on a un cloud opérationnel.
  • Nativement vRA intègre de la gouvernance basée sur des “Policies” (qui à le droit de faire quoi), des workflows d’approbation, les baux d’expirations, tout le cycle de vie d’un déploiement, un designer graphique de blueprint, …

Bref rien n’est gratuit, tout à un prix, tout à un coût. Il faut faire des comparaisons en prenant en compte toute la chaine et identifier les éléments qui ont de la valeur pour vous.