Quelle plateforme pour les applications « Share Nothing Architecture » ?

Les entreprises cherchent de l’agilité pour aller de plus en plus vite dans leur croissance. Lorsqu’elles développent des applications à destination de l’interne ou de l’externe c’est pour accompagner cette croissance de manière à avoir un impact direct ou indirect. Il faut donc tout faire pour que les développeurs puissent développer ces applications en ayant eux aussi l’agilité attendue. D’où l’attrait des services du cloud public, en effet tout est déjà prêt à être consommé, il déploie simplement un service de données (type base de données ou objet) et interconnecte l’application avec, ils se focalisent sur leur développement. Avoir cette souplesse dans son datacenter permettrait d’allier agilité et sécurité maîtrisée.

La plate-forme VMware Cloud Foundation withTanzu (anciennement vSphere with Kubernetes ou encore Projet Pacific) est une plate-forme mixte capable d’héberger simultanément des applications fonctionnant sur des machines virtuelles et des applications fonctionnant sur des PODs Kubernetes (des containers). Elle permet aussi de fournir d’ores et déjà les services réseau, les services de stockage, le service de registry et le service de sauvegarde/restauration. La plate-forme se dote désormais de services autour de la donnée. Au moment de la rédaction de cet article, deux solutions y sont déjà intégrées : Minio et Cloudian, solutions de stockage objets compatible avec l’API S3, deux autres sont en cours d’intégration : Dell EMC ObjectScale lui aussi un stockage objet compatible S3 et Datastax une base de données NoSQL à base de Cassandra. D’autres viendront rapidement.

 

En quoi est-ce révolutionnaire ?

Contrairement à la majorité des applications dites traditionnelles/classiques/monolithique, les applications dites modernes/Cloud Native/scalable, elles, ne comptent pas sur les artifices de l’infrastructure pour optimiser leur performance ou pour assurer leur résilience, elles utilisent leurs propres mécanismes de manière à être disponible, performante autant que possible et ce quelle que soit l’infrastructure. Elles ont bien sûr besoin de cette infrastructure mais brute, juste pour consommer directement les ressources telles quelles, brutes (les processeurs, de la mémoire et des axes d’IO). Ces applications sont bien souvent des applications SNA (Shared Nothing Architecture), chaque instance servant une même application utilise ses propres ressources sur un serveur distinct et répartissent les données entres ces serveurs, les lectures et  les écritures des données sont ainsi distribuées pour de meilleur performances et une meilleure résilience en prenant en compte la perte potentiel d’un serveur voire d’un site complet.

Sur une infrastructure physique (sans virtualisation), chaque instance à son propre serveur et ses propres ressources. Il n’y a donc pas de problème de placement, une instance sur chaque serveur, cependant, cela induit un problème financier car les serveurs sont dédiés à cet usage, ce n’est pas optimum à moins de consommer toutes les ressources et tout le temps, ce qui est rarement le cas.

Sur une infrastructure virtuelle, les ressources sont partagées, par conséquent celles non utilisées le sont par d’autres applications, elle permet aussi de s’affranchir des problèmes de comptabilité avec le matériel et de bénéficier de tous les autres avantages maintenant connus apportés par la virtualisation. Cependant elle apporte une contrainte pour les applications SNA, comme les instances sont virtualisées, comment s’assurer que ces instances et surtout les données générées sont bien réparties sur des serveurs de virtualisation distincts et donc pouvoir se prémunir de la perte de l’un d’entres eux ?

C’est là que la plateforme VMware Cloud Foundation with Tanzu couplée au module vSAN Data Persistence plateforme (vDPp) entre en jeux. Elle permet aux éditeurs partenaire de tirer le meilleur parti de la plateforme en fournissant leur solution « as a Service ». Cela passe par le développement d’un opérateur qui va automatiser l’installation, la configuration et simplifier le maintien en condition opérationnelle de l’application.

Il suffit de cliquer pour que le service soit opérationnel

 

vDPp connait l’infrastructure, l’application, elle, sait comment assurer sa disponibilité et obtenir ses meilleures performance. L’opérateur va ainsi répartir le nombre d’instance nécessaire sur différents serveurs de virtualisation.

Cette politique de stockage vSAN permet

de garder l’instance applicative sur le même serveur de virtualisation où sont stockées les données.

 

Lors d’opérations de maintenance, l’application est tenue informée afin qu’elle puisse prendre en compte le décommissionnement à chaud d’un serveur de virtualisation.

vDPp tient également informée l’application de manière pro-active si des disques commencent à donner des signes de défaillance.

Les développeurs quant à eux, n’ont qu’à consommer ces services via les APIs habituelles et se consacrer au développement de leur application sans se soucier de rien d’autre. Ils ont un service de données activable à la demande, résiliant, performance.

 

En résumé :

La plateforme VMware Cloud Foundation with Tanzu couplée avec vSAN Data Persistence platform offre une agilité unique pour faciliter le maintien en condition opérationnelle des services de données. Grace à cela, les développeurs se focalisent sur le développement de leur application en continuant d’utiliser leurs outils traditionnels, ils ont une plate-forme souple à l’instar de ce qui se fait sur le cloud public.

Il faut voir la plateforme Cloud Foundation with Tanzu comme une plateforme complète pour développer et héberger les applications traditionnelles comme les applications modernes avec les services intégrés disponible à la demande que cela nécessite.

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 

Pourquoi vSAN (HCI : Hyper Convergence Infrastructure)

vSAN est une solution stockage qui utilise les médias de stockage internes (Disque dur, SSD, NVME, …) de plusieurs hyperviseurs formant un cluster pour qu’ils soient vus par chacun comme un seul espace de stockage partagé.

vSAN a été conçu pour simplifier l’utilisation du stockage et diminuer les coûts opérationnels et d’acquisition. En effet contrairement aux solutions classiques vSAN ne nécessite pas de compétences pointues et de matériels dédiés spécifiques.

Pourquoi est-il important d’avoir besoin d’un espace de stockage partagé par plusieurs hyperviseurs ?

  • Les VMs sont constituées de fichiers persistants, pour qu’elles puissent s’exécuter sur l’ensemble des hyperviseurs il faut que ceux-ci puissent y accéder.

Quelles fonctionnalités de vSphere ont le plus besoin d’un stockage partagé ?

  • High Availability (HA) : Assure la haute disponibilité des VMs et ses applications. Si l’hyperviseur qui exécute la VM subit une panne, la VM est redémarrée sur un autre hyperviseur.
  • Distributed Resources Scheduler (DRS) : Réparti les charges (VMs) entre les hyperviseurs de façon à optimiser l’utilisation des ressources.
  • vMotion : Fonctionnalité qui permet de déplacer à chaud une VM d’un hyperviseur à un autre de façon préventive. Par exemple lors des opérations de maintenance pour éviter des interruptions de service.
  • Fault Tolerant : Une VM est exécutée sur un hyperviseur et les instructions (mémoire, CPU) induites sont envoyées simultanément sur un autre hyperviseur. Si l’hyperviseur qui effectue l’exécution subit une panne, l’autre hyperviseur active la VM immédiatement, il n’y aura pas d’interruption de service.

 

Avec des solutions de stockage traditionnelles, les administrateurs créent plusieurs espaces de stockage en fonction de leur capacité de stockage, de performance et de résilience.

Pour respecter le niveau de service requis par les applications, l’administrateur doit connaître les capacités de ces différents espaces de stockage.

Pour simplifier tout ça, vSAN ne créé lui qu’un seul espace de stockage et bénéficie d’une fonctionnalité intéressante : les politiques de stockage. L’administrateur les créés en fonction du niveau de service souhaité (niveau de tolérance aux pannes, de performance, de réservation, …).

Lorsqu’il crée une VM, il affecte à celle-ci la politique de stockage souhaitée et c’est ensuite l’hyperviseur qui s’assure que la VM sera stockée correctement afin de respecter ce niveau de service.

Si vous utilisez un portail self-service tel que vRealize Automation, celui-ci sera capable aussi d’affecter automatiquement la politique de stockage attendue à la VM à déployer.

Les politiques de stockage de vSAN apportent de la souplesse et un gain de temps non négligeable qui pourra être utilisé à autre chose.

vSAN est directement et complètement intégré dans l’hyperviseur, il ne nécessite pas d’installation. L’administration se fait comme pour l’hyperviseur, directement via le client web de vSphere.

vSAN est la brique principale des offres HCI (Hyper Convergence Infrastructure) qui consiste à créer un cluster de ressources comprenant des serveurs physiques, du stockage interne, un hyperviseur, un logiciel de virtualisation du stockage et de virtualisation du réseau.

Elle peut être « consommée » sous plusieurs formes différentes :

  • Dans des « Appliances Constructeur » comme par exemple VxRAIL ou VxRACK (il en existe d’autres chez plusieurs constructeurs). Le constructeur se charge d’effectuer l’ingénierie d’intégration et assure le support de l’ensemble.
  • Chez les cloud publics : AWS, IBM, OVH, ATOS et bien d’autres. Ici la constitution du cluster de ressources se fait à la volée, l’administrateur choisi le nombre d’hyperviseurs et un configurateur se charge d’interconnecter les serveurs entre eux, installe et configure la partie logicielle.
  • Directement sur vos hyperviseurs à base de serveurs compatibles vSAN Ready Node. Ici tous les composants ont déjà été validés par le constructeur.
  • Sur vos serveurs existants, dans ce cas Il y a un point de vigilance à prendre en compte si vous voulez que la solution fonctionne correctement. Il faut s’assurer que la carte contrôleur des médias, le média de cache et le media de capacité figurent bien dans la matrice de compatibilité.

J’ai des clients dans chaque cas de figure :

  • L’utilisation du modèle Appliance concerne des clients qui ont une certaine maturité et qui ne souhaitent plus avoir à gérer les installations de serveurs et des logiciels mais consacrent leur temps aux besoins plus proches des métiers.
  • L’utilisation du cloud public concerne des clients qui ne veulent plus du tout gérer d’infrastructures physiques et logiciels. Avoir vSAN dans le cloud public permet d’avoir le même mode opérationnel que sur le cloud privé, avec une définition des niveaux de service au travers des politiques de stockage.

Je vous conseille de bien répartir les serveurs dans des racks différents et de créer des « Fault Domain », comme illustré dans l’exemple ci-dessous : une VM est bien sûr stockée sur deux hyperviseurs différents mais surtout dans deux racks différents. Ainsi, si vous perdez un rack complet la VM restera malgré tout accessible. Le placement inter rack est automatique, la seule chose que l’administrateur est amené à faire c’est de définir l’appartenance de chaque hyperviseur à un rack donné.

Ce qui fait aussi la force de vSAN c’est son évolutivité, vous démarrez avec au minimum trois hyperviseurs et vous évoluez en fonction de vos besoins. Vous avez de nouvelles applications à héberger ? Vous ajoutez un hyperviseur (cela se fait à chaud) et votre cluster se retrouve avec plus de ressource processeur, mémoire, stockage et IOPS.

Autre point important si vous avez des sites distants, magasins, usines, agences ou autres qui ne nécessitent pas beaucoup de ressources, vous pouvez partir sur une configuration à deux hyperviseurs. Ces sites sont plus simples à déployer : juste deux serveurs !

Si vous avez des contraintes de licences avec un certain éditeur, grâce à vSAN et son espace de stockage partagé uniquement par les membres d’un cluster, vous pouvez affecter les licences de cet éditeur à ce cluster, et comme le stockage est « étanche », les autres hyperviseurs ne pourront pas accéder aux VMs.

Si vous avez des contraintes de sécurité, sachez que l’espace de stockage vSAN peut être crypté.

Si vous avez besoin de disponibilité, pas de souci, suivant la définition des politiques de stockage vous pouvez perdre un ou plusieurs hyperviseurs ou encore un site complet (configuration stretched cluster).

Dans l’illustration ci-dessous la VM est à la fois protégée sur le site local et sur le site distant, de manière à ce qu’une panne d’un hyperviseur n’entraine pas une bascule distante. Le witness sert d’arbitre en cas de rupture totale des communications inter-sites, les données générées par les VMs ne sont jamais envoyées au Witness.

Vous pouvez aussi augmenter cette disponibilité en ajoutant une réplication sur un troisième site en général beaucoup plus éloigné.

Je n’aborde pas toutes les fonctionnalités comme, la déduplication, la compression ou encore la possibilité de limiter les IOPS, ça serait trop long.

Comme son utilisation est transparente, vSAN ne se cantonne pas à un seul cas d’usage, mes clients l’utilisent comme du stockage traditionnel et ce pour tout type d’application, A titre d’exemple, le premier client vSAN Français a commencé avec un petit périmètre pour de la sauvegarde et maintenant l’utilise pour l’ensemble de ses environnements virtualisés en mode stretched cluster (cluster réparti sur deux sites éloignés de quelques kilomètres à des fins de résilience). Résultat : il ne possède plus de baie de stockage !

Les gains : le coût, la simplicité, la résilience et la performance.

Si je résume :

  • Rien à installer, tout est dans l’hyperviseur.
  • Pas de compétences spécifiques requises.
  • Plus besoin de baie de stockage et de réseau SAN, on utilise les médias internes.
  • Un seul et unique espace de stockage pour un cluster d’hyperviseur.
  • Niveau de service défini par des politiques de stockage.
  • Évolutivité verticale (ajout/retrait de média de stockage) ou horizontale (ajout/retrait d’hyperviseur).
  • Résilience locale ou par site.
  • Configuration deux hyperviseurs pour sites distants.
  • Large support de constructeurs et d’acteurs de cloud public.

Si vous souhaitez en savoir plus sur vSAN :