Mettre à disposition les ressources d’un POD en libre service avec CUIC (Cloupia)
Après le tableau de bord unifié du POD, et l‘automatisation des tâches d’approvisionnement des machines virtuelles, Cisco Unified Infrastructure Controller (CUIC) permet de mettre directement à disposition des utilisateurs finaux les ressources d’un POD et les “services” leur permettant d’utiliser ces ressources.
Comme expliqué dans ce billet, un POD administré par CUIC est composé de 4 types de ressources : les machines virtuelles, les serveurs, le réseau et le stockage. Pour mettre ces ressources à disposition des utilisateurs finaux de manière sécurisée et contrôlée, CUIC utilise un concept de Virtual Data Center (vDC). Précisons d’emblée que le vDC de CUIC n’a aucun rapport ni dépendance avec le Virtual DataCenter de VMWare vCloud Director, et encore moins avec le Virtual Device Context du Nexus 7000 :). Dans CUIC, un vDC est un regroupement logique de :
serveurs virtualisables (typiquement ESXi) qui ont certaines caractéristiques (version ESXi, taille mémoire, nombre de CPUs, appartenance a un certain groupe de serveurs dans le VCenter, etc …)- espaces de stockage d’un certain type (SAN, NFS, local) et qui possèdent certaines caractéristiques (capacité, pourcentage d’espace libre, latence, etc …)
- ressources et caractéristiques réseau des machines virtuelles, telle que le Port Group VMware, le réseau VMWare, le type d’adaptateur, le pool d’adresses IP, etc ….
- politiques d’affectation des machines virtuelles dans les VLANs
- ressources système telles que les templates de VM, le nommage des VM, le type de système d’exploitation, les licenses MS Windows, le domaine DNS, la timezone, etc …
Un vDC est donc un sous-ensemble des ressources du POD et toutes les politiques d’utilisation de ces ressources qui vont permettre ensuite d’instancier des machines virtuelles ayant des caractéristiques exactement définies à l’avance. Par exemple, on définira un vDC pour un groupe d’utilisateurs qui demande des machines virtuelles ayant 2 vCPU et maximum 8GB de mémoire RAM, avec du stockage de minimum 20 GB, pour tourner des serveurs web sous Linux.
cliquer pour agrandir
Lorsqu’un utilisateur final se connecte sur le portail CUIC, il se voit proposer un catalogue de “services” qui ont été préalablement définis par l’administrateur. Chaque service correspond à un type de machine virtuelle (Windows ou Linux), avec le template de VM à instancier et le Virtual Data Center dans lequel cette VM sera créée. De cette manière l’utilisateur final n’a pas à connaître et spécifier tous les paramètres et toutes les options possibles relatives à la VM et à toute l’infrastructure physique sous-jacente, puisque ceux-ci ont été définis et “cadrés” par l’administrateur du POD dans la définition préalable du VDC. Vous me suivez ? 🙂
Selon le niveau de “technicité” de l’utilisateur final, on pourra lui proposer plus ou moins d’options techniques dans chaque service du catalogue. Par exemple, le nombre de vCPU ou la taille mémoire de la VM, etc …
cliquer pour agrandir
L’utilisateur final qui veut créer une nouvelle machine virtuelle va donc demander à CUIC l’exécution d’un service parmi toutes ceux qui lui proposés dans son catalogue. L’exécution sera soit immédiate et entièrement automatique, soit soumise à l’approbation d’un administrateur CUIC. Certains utilisateurs intermédiaires auront donc le droit d’approuver les demandes de création de machine virtuelle.
cliquer pour agrandir
L’utilisateur peut suivre l’état d’approbation et d’exécution de sa demande. Il visualise l’historique de toutes ses requêtes, et demande la suppression lorsqu’il n’a plus besoin de la machine virtuelle. Il voit également toutes ses ressources physiques (vDC) et virtuelles (machines virtuelles), et administre ses machines virtuelles, si l’administrateur lui en a donné les droits.
Pour personnaliser encore d’avantage les services qui sont mis à disposition des utilisateurs finaux, il est possible de déclarer un workflow CUIC comme un service dans le catalogue (voir ce billet pour la notion de workflow). De cette manière, un utilisateur final peut exécuter, sans en connaître les détails techniques, des opérations plus ou moins complexes qui lui auront été préalablement “programmées” dans CUIC par l’administrateur qui a, lui, la connaissance et la maîtrise complète du POD.
Un mécanisme complet de gestion des droits d’accès, avec différents niveaux de droits fonctionnels (administrateur, administrateur d’un type de ressource, administrateur de groupe, approbateur, utilisateur final) et la possibilité d’autoriser un groupe d’utilisateurs finaux à un ou plusieurs vDC permet de partager un même POD entre plusieurs groupes d’utilisateurs disjoints, tels que des filiales ou des départements. Le cloisonnement et le contrôle des ressources utilisées par chaque groupe d’utilisateur est aussi garanti par l’utilisation de Virtual Data Centers séparés. Chaque utilisateur d’un groupe ne voit que ses ressources, son catalogue de services et ses machines virtuelles.
CUIC possède donc toutes les fonctionnalités permettant de “faire de l’IaaS” (Infrastructure as a Service) facilement à partir d’un POD ! Pour être complet, il faut aussi avoir les moyens de facturer les ressources du POD selon leur utilisation. C’est également possible avec CUIC, et je vous en parlerai dans un prochain billet
Tags:
1 commentaires