Optimiser le coût d’usage des GPUs

Les GPUs (Graphical Processing Unit) ont été créés dans les années 70s pour accélérer la création et la manipulation des images. Elles ont vite été adoptées par les constructeurs de console de jeux pour améliorer la fluidité des graphismes. C’est dans les années 2000 qu’a commencé l’utilisation des GPU pour faire des calculs en dehors du domaine du graphisme. Aujourd’hui l’utilisation en vogue des GPUs concernent les domaines d’IA (intelligence artificielle) et de ML (Machine Learning). Plus d’historique sur le site de Wikipédia : : Graphics processing unit – Wikipedia.

C’est pour cela que dans les serveurs des datacenters on retrouve ces GPUs car les applications de type IA et ML nécessitent de nombreux calculs qui s’exécutent en parallèle, ce qu’un processeur classique (CPU) aurait du mal à faire de par sa fonction. En effet une CPU est l’élément central d’un serveur qui est là pour exécuter plein de petites taches séquentielles, très rapide et à faible latence, pour cela il peut compter sur une soixantaine de cœurs par CPU (à date de la rédaction de l’article). Une GPU quant à elle, est faite pour exécuter des milliers de taches en parallèle grâce à ses milliers de cœurs qui la compose.

L’inconvénient d’une GPU c’est son coût, cela peut atteindre des dizaines de milliers d’euro, il faut donc s’assurer qu’elle soit bien utilisée tout le temps. L’idéal est de pouvoir la partager pour qu’elle soit utilisable simultanément par plusieurs applications afin d’être proche de consommer l’ensemble des ressources.

C’est le crédo de Bitfusion solution rachetée par VMware en 2019 et qui maintenant fait partie d’un add-on à vSphere. Les GPUs sont installées sur les hyperviseurs et forment un pool de GPUs qui seront accessibles par les applications directement hébergées sur ces hyperviseurs ou via le réseau IP si les applications sont hébergées sur d’autres hyperviseurs, les applications peuvent même être hébergées sur des serveurs physiques ou être à base de container Kubernetes. L’usage est réservé aux applications types Intelligence Artificielle ou Machine Learning utilisant les routines CUDA. CUDA a été développé par NVDIA pour permettre l’accès directe à des GPUs pour des applications non graphiques.

Les applications peuvent consommer une GPU, plusieurs GPUs ou simplement un portion de GPU (en réalité c’est la mémoire de la GPU qui est partagée). Une fois la consommation terminée, les applications libèrent les ressources GPUs octroyées qui retournent ensuite dans le pool à la disposition de futures demandes.

 

 

D’un point de vue technique, Bitfusion nécessite l’installation de composants de part et d’autre. Coté hyperviseurs qui possèdent les GPUs, il faut déployer sur chacun une appliance virtuelle téléchargeable à partir du site VMware. Pour les clients (VM, Bare Metal ou containers/PODs Kubernetes) qui vont consommer les ressources GPUs, il faut installer un client Bitfusion, ce dernier permettra d’intercepter les appels CUDA fait par l’application pour les transférer à l’appliances Bitfusion via le réseau IP. C’est transparent pour l’application.

 

Du fait que les échanges entre les clients et les appliances Bitfusion passent par le réseau IP, il est préférable d’avoir au minimum un réseau 10 Gb/s, il faut compter en général 1 réseau 10 Gb/s pour 4 GPUs.

Personnaliser une VM Ubuntu avec Cloud-Init sur vSphere

Cloud-Init semble être l’outil de personnalisation de prédilection pour les OS majeurs visant à être installer sur différents environnement cloud (AWS, Azure, GCP, vSphere, …), il est très puissant, hétérogène mais au début, il est difficile à appréhender.

Les informations de personnalisation sont stockées dans un fichier appelé user-data. Ce fichier est transmis à Cloud-Init grâce à un mécanisme propre à chaque cloud. Dans notre cas, ce sont les VMtools qui vont transmettre le fichier user-data, une fois reçu, Cloud-Init l’exécutera.

J’ai perdu énormément de temps à trouver les étapes minimales pour personnaliser l’OS Ubuntu avec Cloud-Init dans un environnement vSphere. Je recherchais la possibilité de personnaliser l’OS lors des clones à partir de template OVF.

Ci-dessous la procédure que j’utilise pour un Ubuntu 20.04.2 LTS, fraîchement installé et après son premier reboot. J’ai gardé les valeurs par défaut hormis le clavier Français et l’installation de l’option OpenSSH server.

Il faut dire à Cloud-Init de récupérer le fichier de personnalisation user-data via les paramètres OVF de la VM, il y a une étape à faire coté VM et une coté OS.

 

Coté OS :

  • Supprimer le fichier qui met la Datasource à none au lieu d’OVF
    • sudo rm /etc/cloud/cloud.cfg.d/99-installer.cfg
  • Si vous souhaitez que la configuration réseau se fasse, supprimer le fichier qui la désactive
    • sudo rm /etc/cloud/cloud.cfg.d/subiquity-disable-cloudinit-networking.cfg
  • Si vous êtes en DHCP, la VM récupérera toujours la même IP car elle gardera le même machine ID. Pour éviter cela il faut remettre à zéro l’identité de l’OS :
    • sudo truncate -s 0 /etc/machine-id

 

Coté VM :

  • Récupérer le contenu de votre fichier cloud-init user-data et le codé avec base64 :
    • Base64 user-data.yaml
  • A partir du vSphere client, lorsque la VM est arrêtée, Activer les propriétés de l’OVF :
    • Sélectionnez la VM => Configure => vApp Options => vApp Options are disabled … Edit => Cliquer sur “Enable vApp options”
    • Dans l’onglet OVF details => => sélectionner la case VMware Tools
  • A partir du vSphere client, lorsque la VM est arrêtée, ajouter le champ user-data dans les propriétés de l’OVF :
    • => Sélectionnez la VM => Configure => vApp Options => Properties => ADD mettre le Label et Key id  à la valeur user-data.
  • A partir du vSphere client, lorsque la VM est arrêtée, ajouter la valeur au champ user-data dans les propriétés de l’OVF :
    • Sélectionnez la VM => Configure => vApp Options => Properties => SET VALUE, un popup s’ouvre et mettre la clé base64 du contenu du fichier user-data récupérée un peu plus haut

 

 

Maintenant à partir de cette VM, faite directement un clone pour en faire une autre VM ou pour en faire un template. Si vous souhaitez changer le fichier user-data, au moment du déploiement de la VM, changez uniquement la clé base64 par la nouvelle clé.

 

 

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.

Comment supprimer des containers volumes “orphelins” dans vSphere

Lorsque vous créez des volumes Kubernetes hébergés sur vSphere, cela génère des fichiers VMDKs, ils sont visibles au travers de l’interface graphique

C’est très utile, il est même possible de voir à quel cluster les volumes appartiennent.

Dans certaines situations, vous pouvez vous retrouver avec des volumes dits orphelins, notamment si un cluster Kubernetes est supprimé “brutalement”. Malheureusement il n’est pas possible de supprimer ces volumes/vmdks depuis l’interface graphique (à date de la rédaction de cet article, vSphere 7). Pour ce faire, il existe d’autres possibilités comme par exemple utiliser l’utilitaire govc développé par VMware. Cependant la version habituelle (référence à la version govc version 0.23.0) ne prend pas en charge les options volume.ls et volume.rm, il faut pour cela utiliser une version à compiler soi-même. ci-dessous les étapes à respecter pour y parvenir :

Installer go (sur Ubuntu server dans mon cas), il est important d’avoir une version récente : https://golang.org/doc/install

Lancer la commande go suivante  : go get -u github.com/vmware/govmomi/govc (https://github.com/vmware/govmomi/tree/master/govc). Ca va télécharger les sources dans le répertoire ~/go/src, compiler et stocker le binaire govc dans ~/go/bin.

il faut positionner ensuite un certain nombre de variable à govc afin qu’il puisse se connecter à l’infrastructure, exemple :

export GOVC_URL=<fqdn du vcenter>
export GOVC_USERNAME=<compte avec des droits en consultation>
export GOVC_PASSWORD=<mot de passe du compte>
export GOVC_INSECURE=true (si vous utilisez des certificats non signés)

Grâce à ce govc spécifique, vous pouvez utiliser la commande ~/go/bin/govc volume.ls pour lister tous les volumes et la commande ~/go/bin/govc volume.rm <volume>. Attention à bien choisir les volumes orphelins sinon vous risquez de perdre des données.

Un développeur à fait un script intéressant pour supprimer les volumes orphelins : https://gist.github.com/bburky/fd729f129347b9141255fbc2185c52ea#file-remove-orphaned-cns-volumes-sh-L1 (attention ce script suppose que govc soit dans votre variable $PATH, si ce n’est pas le cas mettez cette variable à jour ou modifier le script pour qu’il pointe sur le bon govc).

Ce script à un petit bémol auquel il faut prêter attention, il suppose qu’il y ait un seul cluster car il utilise la commande kubectl, celle-ci se connecte en utilisant le contexte actif. Si vous avez plusieurs clusters kubernetes hébergés sur votre infrastructure, vous risquez de supprimer des volumes vus comme orphelin alors qu’ils peuvent potentiellement appartenir à d’autres clusters Kubernetes, j’ai soumis au développeur du script cette modification :

> "$temp_dir/kubernetes-temp.txt"
for context in $(kubectl config view -o jsonpath='{.contexts[*].name}')
do
        echo checking context : $context
        kubectl get pv -o jsonpath='{range .items[*]}{.spec.csi.volumeHandle}{"\t"}{.metadata.name}{"\n"}{end}' --context $context  >> "$temp_dir/kubernetes-temp.txt"
done
sort $temp_dir/kubernetes-temp.txt > $temp_dir/kubernetes.txt

Ce n’est pas encore parfait, il peut inclure des volumes provenant de cluster Kubernetes non vSphere mais il n’y aura pas d’incidence sur la suppression des volumes.

 

Une solution Kubernetes as a Service pour tous les Clouds

Kubernetes est l’orchestrateur de containers en vogue. Il est disponible sous différentes formes, à installer et à gérer soit même ou complètement géré par un tiers comme c’est le cas pour les solutions Google GKE, Microsoft AKS ou Amazon EKS.

Comme pour les anciennes applications qui étaient majoritairement monolithiques et difficile à faire évoluer, elles deviennent maintenant micro-services pour être plus agile dans leur cycle de vie. Les clusters Kubernetes “historiques” déjà en place ont une stratégie monolithique avec un gros cluster compliqué à déployer et à faire évoluer. De ce constat VMware a adopté une toute autre stratégie. Avoir une solution simple à déployer, simple à maintenir, simple à faire évoluer modulaire et ce sans être verrouillé à une plate-forme. De cette manière, il est possible d’avoir un cluster Kubernetes en 5 mn sur du OnPremise ou dans le cloud public. (Aujourd’hui sur vSphere et AWS, les autres plateformes telles qu’Azure ou GCP vont rapidement arriver).

Cette stratégie a été élaborée sous l’impulsion des équipes issues du rachat de la société Heptio en 2018. Heptio a été fondée par 2 des créateurs de Kubernetes et font toujours parti des effectifs de VMware. L’ADN d’Heptio était exclusivement basée sur Kubernetes, vendre du conseil, développer des outils open source, contribuer à des projets open source existants et dispenser gratuitement des formations en ligne. Cette ADN a été conservée et VMware est désormais le deuxième contributeur sur Kubernetes, juste derrière Google. Une partie de ces contributions figure ici : https://github.com/vmware-tanzu.

C’est avec cet esprit que la solution Tanzu Kubernetes Grid (TKG) est née, à base d’open source, elle est dotée du moteur Kubertenes upstream et du gestionnaire Cluster API pour gérer le cycle de vie. Les binaires sont vérifiés par VMware pour parer aux failles de sécurité et pour une meilleure stabilité afin d’être en mesure d’en assurer le support. Plutôt que d’avoir une grosse solution tout intégrée difficile à maintenir, TKG est modulaire, vous pouvez y ajouter les modules que vous voulez, qu’ils soient développés par un tiers ou ceux développés par VMware.

Modules intégrables non exhaustifs. (En gris projet où VMware était à l’origine ou est principal contributaire)

Le Life-cycle Manager Cluster API fait partie intégrante de TKG

En résumé, s’il y a une chose à retenir : TKG c’est du Kubernetes As a Service, modulaire et multi-cloud, basé sur des solutions Opensources upstream.

Bénéfice principal : Avoir une infrastructure de développement et d’hébergement de container aussi agile que les applications qui y vont être développées et hébergées !

 

je vais maintenant rentrer un peu dans la technique.


Comment TKG fonctionne ?

C’est vraiment très simple à installer et à utiliser et c’est assez bluffant.

A partir d’un point d’administration (Linux, Mac ou Windows) vous installez le binaire TKG CLI pour initialiser le cluster Kubernetes management de TKG, ça prend environ 10 minutes. Une fois initialiser, toujours via TKG CLI, vous créez des clusters Kubenetes TKG pour les worloads applicatifs, ça prend environ 5 minutes.

 

Ensuite, il est très simple de faire évoluer à chaud (à la baisse ou à la hausse) la taille des clusters kubernetes de workload, ça prend environ 2 minutes.

TKG intègre nativement la CSI (Container Storage Interface) pour pouvoir provisionner des PVC (Persistent Volume Claim) utiles aux PODs statefull. Ces volumes seront automatiquement fournis par l’infrastructure sur laquelle réside TKG.

 

J’ai testé TKG sur une palte-forme vSphere à partir de laquelle je fais des démonstrations à mes clients. J’ai mis ci-dessous les étapes à respecter.

Il faut télécharger à partir du site VMware, le binaire TKG CLI et deux images (OVA). L’une des images servira pour les serveurs Kubernetes (Control Plane et Workers) et l’autre pour le serveur de Load Balancer HA Proxy pour servir les Control Planes.

A partir d’un cluster vSphere 6.7U3 minimum, activez DRS, créez un Ressource Pool et un VM Folder, chargez les deux images OVA.

Une fois les deux OVA chargées, faire un snapshot (étape nécessaire pour pouvoir utiliser les Instant Clone) et les convertir en template.

C’est tout ce qu’il y a à faire coté vSphere.

A partir d’un point d’administration Windows, Linux ou Mac (Linux dans mon exemple), copier le binaire TKG CLI puis lancer la commande : tkg init –infrastructure=vsphere –ui et remplir les champs demandés comme dans l’exemple ci-dessous, cette étape peut aussi se faire en ligne de commande en configurant le fichier config.yaml à placer de préférence dans le répertoire $HOME/.tkg :

(Screenshots issues de la version beta que j’ai testée)

Choix de la plate-forme (vSphere et AWS pour la première version les autres suivront très vite)

 

Information de connexion à la plateforme

 

Type de plan de deploiement et localisation du cluster de management

 

CIDR du réseau Kubernetes et type d’OS pour les control plane et worker nodes

 

Récapitulatif des informations renseignées

 

Suivi du déploiement

 

Une fois le cluster de management déployé, vous pouvez créer des clusters de wokload via la commande ci-dessous :

$ tkg create cluster prod1 -p prod -w 5 (5 pour 5 workers)

En moins de 5mn vous avez un cluster à votre disposition, vous pouvez “scaler” à chaud en modifiant à la hausse ou à la baisse le nombre de control plane ou de worker via la commande ci-dessous :

$ tkg scale cluster prod1 -w 4 -c3 (-w pour les workers et -c pour le control plane)

TKG surveille les VMs Kubernetes, si une est amenée à s’arrêter, TKG va la redémarrer automatiquement.

Pour utiliser un cluster déployé, il faut utiliser la commande Kubernetes kubectl :

Lancer la commande sans changer de contexte :

$ kubectl <commande> –context <context-tkg>

Pour changer de context et lancer les commandes sans spécifier de contexte :

$ kubectl config get-contexts (pour connaitre le nom du contexte)

$ kubectl config use-context <context-tkg>

Pour effacer le cluster :

$ tkg delete cluster prod1

C’est vraiment très simple à utiliser.

 

Pour en savoir un peu plus, je vous invite à consulter les articles d’Alex et Mika, deux personnes avec qui j’ai plaisir à travailler quotidiennement :

Alex : https://hackmd.io/@ac09081979

Mika : https://myvmworld.fr/vmware-tanzu/