Ces dernières années au sein des technologies de réseaux et systèmes d’entreprise, une tendance claire se dessine vers les solutions dites Software Defined : SD Networks, SD-WAN, SD Storage, etc. Elles ont pour objectif de répondre aux problématiques moderne en s’émancipant de la couche physique et en se concentrant sur les services. L’omniprésence du cloud est un bon exemple de cette tendance. Les fabricants et éditeurs n’ont pas mis longtemps à capitaliser sur cette tendance et ont proposés leurs propre solutions comme celles qui nous intéresse aujourd’hui : Cisco ACI et Nutanix.
Le but dans cet article sera de démontrer les capacités d’intégrations de ces deux technologies au sein d’un réseau d’entreprise.
Qu’est-ce que Cisco ACI ?
Cisco Application Centric Infrastructure (ACI) est une solution de Software-Defined Network (SDN) proposée depuis mi-2014. Le choix de ACI comme nom de solution n’est pas anodin car son objectif premier est d’articuler l’infrastructure réseau autour des applications qui sont les composants les plus importants d’un Système d’Information.
Une chose importante à retenir, la solution se veut agnostique, c’est-à-dire qu’elle intègre les autres solutions qui compose le datacenter au sein de la fabric avec en tête de proue les solutions de virtualisation/conteneurs comme VMware, Kubernetes ou encore, depuis août 2023, le support de Nutanix AHV.
Pour adresser ce besoin, la fabric ACI se repose sur une architecture Spine/Leaf, permettant une meilleure évolutivité de l’infrastructure, le tout orchestré par des instances APIC. Ces derniers reposent intégralement sur l’utilisation de l’API REST mise à disposition pour la configuration de la fabric.
Intégration Cisco ACI et Nutanix
Afin de démontrer ce fonctionnement, nous allons configurer un connecteur Nutanix au sein de la fabric ACI et y déployer un VLAN. Nous verrons également en fin d’article comment la superviser facilement.
Pour que ces technologies présentent un réel intérêt, il est essentiel de les approcher d’un point de vue global et non “par périmètre”. En effet, les applications et les données hébergées sur une plateforme Nutanix ont besoins du réseau pour être utilisés et le réseau n’a pas d’intérêt s’il ne donne pas accès aux applications. Cisco ACI permet de connecter des clusters Nutanix (grâce à l’API Nutanix) afin que ces deux périmètres communiquent et facilite la gestion et le déploiement d’application.
Utilisation de l’API APIC
Afin de créer les objets, nous allons voir la structure de APIC REST API et exposer les méthodes et outils utiliser pour parvenir à déployer notre configuration. Nous rentrerons en détail sur la création de certains objets.
Structure
L’intégralité des éléments d’une fabric ACI sont représentés par des objets organisés de manière hiérarchisée dans une base de données MIT (Management Information Tree).
Chaque nœud est un objet possédant une classe ainsi qu’un nom unique (Distinguished Name) composé du nom de l’objet parent et de son nom relatif.
On peut interroger ces objets via l’API en composant une requête qui respecte la syntaxe REST de la plateforme.
Une requête, peu importe son type, doit se terminer par le format utilisé lors de la communication : JSON ou XML. Les données contenu dans le body de la requête doit correspondre au type indiqué. On indique cela avec l’ajout de .json ou .xml à la suite du nom de l’objet. Nous utiliserons uniquement le format JSON dans la suite. Enfin, des filtres optionnels peuvent être ajouté à la suite de l’opérateur “?”, comme query-target qui permet de préciser l’étendu de la requête sur l’objet.
Voici un exemple de requête permettant d’obtenir la liste des domaines VMM Nutanix.
Afin de composer nos requêtes et réaliser des actions, nous devons connaitre le nom de l’objet à modifier, ses propriétés ainsi que le “chemin” (DN) pour y accéder. Nous pouvons procéder de plusieurs manières suivant la situation.
Object Store Browser
Si l’objet que l’on souhaite manipuler existe déjà dans la fabric, on peut afficher ses détails via Object Store Browser disponible sur l’APIC. Par exemple, avec un VLAN Pool, je sélectionne l’objet dans la GUI puis “Open in Object Store Browser”.
On voit alors l’objet, sa classe, son Distinguished Name ainsi que ses propriétés.
API Inspector
Si l’objet que je souhaite créer n’existe pas encore, je peux le créer via GUI et observer la requête générée lors de la création. En effet, l’interface graphique communique avec la fabric via API, de la même manière que nous le faisons avec nos requêtes. De ce fait, Cisco a intégré un outil afin d’observer les requêtes API réalisées par la GUI vers la fabric.
Si on créé un VLAN Pool via GUI, je peux récupérer la requête POST et ainsi copier le payload afin de m’en servir comme référence.
Requêtes GET et filtres
Dans certaines situations, il peut être nécessaire de lister les objets qui en composent un autre (les objets enfants), ce que ne permettent pas de faire les deux méthodes précédentes. Par exemple avec les domaines VMM, certains objets représente une association entre deux autres objets : si on souhaite associer un VLAN pool (fvnsVlanInstP) à un domaine VMM (vmmDomP), on doit créer un troisième objet qui décrit cette relation (infraRsVlanNs).
Ces classes d’objets contiennent le mot clé Rs dans leur nom pour RelationShip.
Un objet créé via GUI contiendra tous les objets nécessaires à son fonctionnement. On peut également les interroger et lister les sous-objets qui le compose.
Démonstration avec un domaine VMM
Requête HTTP GET vers un domaine VMM Nutanix créé via GUI.
Notez l’option ?query-target=children à la fin de la requête.
Ainsi, nous connaissons les objets qui composent un domaine VMM.
Object Model Documentation
Maintenant que nous sommes en mesure de connaitre les éléments nécessaires à la création de tous nos objets, il est important de consulter les propriétés de ces derniers dans la documentation. Prenons l’exemple de la classe vmmDomP pour les domaines VMM :
On y voit ses règles de nommage.
Dans l’onglet Properties, les propriétés de l’objet et les valeurs possibles.
Dans l’onglet Relationships, les relations disponibles (Rs) pour cet objet.
Dans l’onglet Containment, les objets parents et enfants.
Démonstration
Nous allons démontrer comment déployer un VLAN sur un cluster Nutanix à travers la fabric ACI.
Afin de valider la démonstration :
La fabric ACI doit se connecter au cluster Nutanix
Déployer un VLAN “TESTAPI” avec le bon nom coté cluster Nutanix
Déployer un domaine VMM “NUTANIX-VMM-API”
ACI doit récupérer les informations du cluster (vSwitch, VMs, nodes, controleurs, etc)
Workflow de création des objets
Les méthodes exposées nous ont permis d’établir les objets à créer ainsi que l’ordre dans lequel ils doivent être créés.
Authentification
Tout d’abord, il est nécessaire de s’authentifier auprès de l’APIC avant d’envoyer des requêtes. On envoie une requête POST à l’URL suivante :
https://{{aci}}:{{port}}/api/aaaLogin.json
Le body se compose du nom d’utilisateur et du mot de passe.
Si l’authentification réussie, on reçoit un token qui nous permettra de communiquer avec l’APIC tant que celui-ci est valide.
Avec Postman, le token est stocké et ajouté automatiquement dans les entêtes des prochaines requêtes.
Il arrive à expiration après une durée pré-déterminée et doit être regénéré avec une nouvelle requête.
Création des objets
En suivant le workflow, nous crééons chaque objet les uns après les autres. Ensuite, on indique l’URL en respectant la syntaxe.
On ajoute les valeurs aux propriétés de l’objet. Le HTTP body doit respecter la syntaxe suivante :
{"imdata": [
{***properties***}
]
}
Une création d’objet réussie renvoie un code 200 (OK) et un HTTP body “vide” comme ci-après. En cas d’erreur, des détails seront présents dans le corps de la réponse.
On peut voir les objets créés avec une requête GET ou supprimer un objet avec une requête DELETE. Également, on peut voir les objets dans l’interface graphique.
Une fois tous les objets créés, on peut valider sur le cluster Nutanix que le Virtual Network apparait ainsi que dans la fabric ACI si les informations du cluster ont été récupérées.
Liste des hyperviseurs depuis l’interface Cisco ACI
Nutanix – VLAN déployé sur vs0
Particularités Nutanix
Certaines valeurs d’objet dans la fabric ACI ne sont pas compatible avec Nutanix sans que cela ne soit documenté chez Cisco (corrigé depuis la version 6.0). C’est le cas par exemple pour l’association d’un EPG à un VMM Domain et la propriété “Resolution Immediacy” qui accepte comme valeur uniquement “pre-provision”.
Soyez vigilant lors de vos configurations, réalisez toujours des tests par objet avant de les intégrer dans des recettes de déploiement.
Monitoring
L’utilisation de l’API nous permet également de récupérer des informations sur l’état général de la fabric. En nous inspirant du travail de Michael Schoen sur GitHub, nous avons pu mettre en place un dashboard en utilisant la TIG stack (Telegraf, InfluxDB, Grafana).
Conclusion
Nous avons parcouru les fonctionnalités de la stack ACI, présenter le fonctionnement et la manière d’interagir avec la APIC REST API puis réaliser le déploiement d’un VLAN au sein de la fabric et d’un cluster Nutanix. Également, nous avons survolé les possibilités de monitoring qu’offre l’API.
Avec l’arrivé récente de la version 6.0 de l’API, la documentation s’est enrichi et intègre désormais certaines informations manquantes dans les versions antérieurs (particulièrement sur l’intégration Nutanix). Néanmoins, on regrettera que l’API ne respecte pas les standards OpenAPI, chose commune à beaucoup de technologies du secteur, obligeant les utilisateurs à devoir se documenter spécifiquement pour cette plateforme.
La transition vers des technologies application-centric, avec une abstraction de la couche physique et une capacité native à l’automatisation est aujourd’hui inévitable. Cisco ACI et Nutanix se présentent comme pionier et leader dans cette approche. Intéressez-vous à ces technologies dès maintenant avant de rater le train, elles auront forcément quelque chose à vous apporter.
