Automatiser l’approvisionnement des machines virtuelles avec CUIC (Cloupia)
Pour être capable d’industrialiser les tâches d’administration des PODs, il faut d’abord avoir une vision et un contrôle centralisé de l’ensemble des composants du PODs. Si vous avez lu ce billet, vous savez que Cisco Unified Infrastructure Controller (CUIC) – produit issu du rachat de Cloupia – permet cette vision centralisée. Intéressons-nous maintenant à la manière dont CUIC permet d’industrialiser et automatiser les nombreuses tâches répétitives nécessaires pour approvisionner des machines virtuelles dans un POD.
Pour préparer un nouveau serveur et son espace de stockage dans un POD, il est nécessaire d’effectuer, dans un ordre bien précis, une succession d’actions de configuration sur plusieurs composants du POD. Par exemple, il faut d’abord créer un espace (Volume et LUN) sur la baie de stockage, puis configurer le Zoning dans le commutateur SAN, puis configurer un nouveau service profile dans l’UCS en mode “boot from SAN”, puis éventuellement créer un nouveau VLAN sur le Nexus, puis découvrir le serveur dans UCS, etc …. .
cliquer pour agrandir
Toutes ces actions de configuration peuvent être automatisées dans CUIC au moyen d’un “workflow“, qui est une succession de tâches élémentaires. CUIC propose une librairie de plus de 450 tâches, concernant chacun des composants du POD (virtualisation, compute, réseau et stockage), plus des tâches génériques permettant l’interaction en dehors de CUIC. Un outil graphique “workflow designer” permet de construire ses propres workflows en enchaînant des tâches choisies dans la librairie. Des paramètres sont demandés au début du workflow, et utilisés ensuite par les tâches.
cliquer pour agrandir
Le résultat d’une tâche est binaire (succès ou échec) et elles s’enchaînent de manière strictement séquentielle, exactement comme un administrateur qui réalise une configuration de manière séquentielle. Il n’y a pas de boucle répétitive ou d’instruction conditionnelle autre que le résultat de la tâche précédente. Cela parait à première vue un peu simpliste, mais cela permet à CUIC de “défaire” automatiquement ou à la demande un workflow déjà exécuté. Cela n’a l’air de rien à première vue, mais c’est extrêmement puissant, car il n’est pas nécessaire de concevoir un deuxième workflow pour “déconfigurer” ce qu’un autre a déjà configuré. 🙂 De même, les workflows peuvent être utilisés de manière récursive, ce qui permet la définition de workflows de base, que l’on peut facilement assembler en workflows plus sophistiqués. Une vraie boite à outils… 🙂
Lors de l’exécution d’un workflow, CUIC affiche l’état d’avancement du workflow avec tous les détails de chaque tâche (paramètres, résultats des commandes, objets crées ou supprimés, durée de chaque tâche, etc …)
cliquer pour agrandir
Il y a plusieurs manières d’exécuter un workflow:
- Depuis la librairie des workflows, l’administrateur demande une exécution immédiate ou planifiée, en fournissant tous les paramètres nécessaires.
- Dans toutes les pages qui affichent l’inventaire des composants du POD, il est possible de rajouter des actions supplémentaires associées à un objet physique ou virtuel. Cela permet d’enrichir et de personnaliser l’interface de CUIC avec des nouveaux menus qui déclenchent l’exécution d’un workflow. L’administrateur peut donc personnaliser et enrichir CUIC avec ses propres actions, simples ou sophistiquées.
- Des “trigger” permettent de déclencher automatiquement l’exécution d’un workflow lors de la survenance d’une condition de type état opérationnel d’un serveur ou d’une VM, taux de remplissage d’un volume de stockage, charge CPU ou mémoire d’un serveur, etc …
Et bien évidement, les workflows peuvent être publiés dans un catalogue de services à destination d’utilisateurs techniques (mais pas des administrateurs). Je vous en dirai plus dans mon prochain billet….
Tags:
2 commentaires