D’emblée, le sujet peut surprendre. Pourtant, il se justifie pleinement aujourd’hui ! Les objectifs des entreprises sont très clairs :
- augmentation du Chiffre d’Affaire et de la marge
- réduction des coûts internes et des risques.
L’Entreprise cherche donc à être le plus agile possible afin de répondre instantanément à toute opportunité Métier. Dans le même temps, la situation sanitaire entre autres impose des contraintes.
L’Entreprise compte sur son Système d’Information pour être un vecteur d’agilité dans la croissance de ses activités Métier tout comme dans le traitement de ses contraintes.
Le Système d’Information doit garantir cette agilité afin d’assurer la réactivité.
Un élément clé pour cette agilité est la capacité du Système d’Information à disposer de la meilleure visibilité possible sur le comportement de ses composants :
- L’Expérience Utilisateur des collaborateurs,
- Les éléments d’infrastructure,
- Les applications.
Ceci permettra de prendre la bonne décision en toute connaissance de cause pour adresser une demande Métier.
Les équipementiers et éditeurs du marché fournissent les divers éléments qui composent le SI. Ils disposent tous de leur propre solution de supervision. Ils font tous partie d’organismes comme l’IEEE ou l’IETF qui « standardisent » les protocoles mis en œuvre dans leurs solutions. Le SI peut potentiellement se retrouver avec de multiples solutions de supervision liées au choix qu’il aura fait des éléments composant ce SI. Il existe également des « frameworks » généralistes qui consolident les informations d’équipements de divers fournisseurs.
Concernant les composants Réseau, deux constatations s’imposent à notre esprit :
- La configuration se fait majoritairement en CLI,
- Les informations remontées pour la supervision sont essentiellement sous forme de MIB accédées par le protocole SNMP.
En aucune façon nous ne remettons en cause les bénéfices apportés par ce couple CLI / SNMP. Cependant, ils ne s’insèrent pas forcément de façon simple dans une stratégie d’automatisation des composants d’infrastructure. Or, l’automatisation est essentielle pour garantir la réactivité du Système d’Information. Elle garantira l’agilité de l’Entreprise.
Redonner de l’indépendance au Système d’Information par rapport à ses choix de composants
Nous assistons à cette Tendance depuis quelques années grâce à l’Open Source. Notons que la majorité des fournisseurs adhère à cette tendance. Or, le monde de l’Open Source, c’est la jungle diront certains : pléthore de solutions pour chacun des points à adresser dans un SI.
Il convient alors de prendre la mesure de cette nouvelle approche. Gardons à l’esprit quelques grands principes. Une solution Open Source n’est liée à aucun fournisseur, et inversement. Elle respecte donc le principe d’abstraction. Elle est comme interchangeable.
On peut répondre à un besoin déterminé avec une solution Open Source sur un environnement de composants donnés :
- Pour changer de composants d’infrastructure, il suffit d’adapter la solution Open Source pour aller chercher les nouvelles métriques,
- Pour changer de solution Open Source, mes choix de composants d’infrastructure ne sont pas remis en cause.
Comment décrire l’Open Source ?
Au premier chef, il s’agit d’une communauté. Tout le monde y partage son savoir avec tout le monde. Chaque contributeur (vous, moi, un éditeur) enrichit l’expérience des autres de son savoir. La mise en œuvre est d’autant plus aisée qu’il y a de fortes chances que ce que vous cherchez à faire, quelqu’un d’autre l’ait déjà fait. Du fait que tout soit partagé, le travail déjà fait est à récupérer pour être enrichir et remis à disposition. Cependant, le reproche majeur fait à l’Open Source. C’est de l’Open Source !!
- Si vous avez récupéré un script Python sur Github et que ce script « plante » dans votre environnement, vous n’aurez aucun support.
- Si ce même script fonctionne mais que vous faites un reload modifié par un autre contributeur, même chose.
- Gouvernance et connaissance : un de vos collaborateurs a développé toutes les routines nécessaires afin de présenter un tableau de bord complet de votre SI. Comment sera repris ce travail si ce collaborateur quitte la société ?
La majorité des fournisseurs suit ce mouvement de l’Open Source et proposent des solutions supportées, et donc tarifées.
Il y a quelques années, j’avais monté une démonstration Infra-as-Code pour un pur environnement de production :
- Je tournais un playbook Ansible depuis ma CentOS,
- Ce playbook allait provisionner un EPG (End-Point Group) sur mon Réseau SDN ACI,
- Lequel créait automatiquement un nouveau Port Group dans ma vCenter. Je n’avais plus qu’à y rattacher mes VM.
Si je veux assurer du HA de ma CentOS Ansible, du backup de mes fichiers YAML (qui contiennent les paramètres utilisés par mon playbook), du support…. l’éditeur RedHat propose des licences Ansible avec de nombreuses fonctions avancées et du support. Même chose avec le TIG ci-après, l’éditeur Influxdata propose du support sur la base InfluxDB.
Les composants clés de l’Open Source
Les composants clés de l’Open Source : la communauté, sans elle, il n’y aurait pas d’Open Source. Ensuite, nous pouvons répertorier les éléments de base utilisés par cette communauté de la façon suivante :
La communication entre composants : l’API au format REST pour sa simplicité ( REST est basé sur le format http, soit 4 ordres (le modèle CRUD) ) et son universalité (tout composant du SI dispose aujourd’hui de son API au format REST).
La représentation des données :
Il s’agit certainement là de l’aspect le plus déroutant lorsque l’on s’intéresse à l’Open Source . Nous allons l’illustrer via les protocoles d’accès Réseau en alternative de notre SNMP bien connu et de ses MIBs. Différencions le « Data Model » du « Data Format » :
- Data Model : décrit les éléments que l’on peut configurer et superviser, ainsi que les actions que l’on peut effectuer sur ces éléments. Le Data Model le plus utilisé par les protocoles Réseau est YANG.
- Data Format : un fichier au format texte utilisé par une API pour échanger de l’information. L’encodage proprement dit du fichier de données. Les 3 principaux formats sont XML, JSON et YAML. La caractéristique majeure de ces fichiers texte est qu’ils sont facilement lisibles.
Pour illustrer, résumons les protocoles Réseau basés sur API :
- NETCONF : démarré en 2002 (les API au format REST n’avaient pas encore pris leur envol). Data Model YANG, Data Format XML,
- RESTCONF : un sous-ensemble de NETCONF, plus récent et au format REST (utilise donc le CRUDX avec un transport http). Data Model YANG, Data Format XML et JSON,
- gNMI : d’origine Google et basé sur gRPC. Data Model OpenConfig / YANG, Data Format JSON ou ProtoBuf.
Le format YAML n’apparait pas ci-dessus. Pourtant ce format est extrêmement populaire car c’est le plus lisible de tous. Et surtout, c’est le Data Format utilisé par le moteur d’Infra-as-Code Ansible.
Le repository des sources :
Il est basé sur Git afin d’assurer le « versionning » du code. Le Git Public sur lequel toute la communauté dépose ses codes aujourd’hui est GitHub. Vous cherchez un script Python pour un extract de donnée via Telegraf, quelqu’un l’a déjà certainement posté sur GitHub.
Le langage de « scripting » :
Tout type de langage peut faire l’affaire mais il apparait que la communauté utilise massivement Python.
Pour sa simplicité et sa lisibilité.
Moi qui n’ai jamais fait de programmation, j’ai su créer quelques routines en Python. Ces routines me renvoyaient des informations de configuration de mon infra Réseau ACI dans un fichier JSON. Je pouvais mettre ensuite ce fichier JSON dans un format clair via un template JINJA.
Ma supervision d’Infrastructure en Open Source
Je vais démontrer l’ensemble du propos ci-dessus par le cas d’usage suivant.
- Je dispose d’une infrastructure de calcul à base de serveurs UCS de Cisco,
- J’envisage une solution de supervision indépendante du constructeur et du « dashboarding » Graphana me convient parfaitement.
J’explore la solution TIG Open Source et je regarde si UCS peut s’insérer dans mon besoin.
TIG est l’abréviation pour les 3 outils Open Source suivants :
- Telegraf : le collecteur de données. Je trouve un script Python pour UCS sur GitHub qui sera appelé par Telegraf. Ce dernier va ensuite alimenter la base InfluxDB.
- InfluxDB : la base de données proprement dite qui va stocker les infos envoyées par le collecteur.
- Graphana : mes tableaux de bords !!
Le contributeur initial a écrit son script Python afin d’aller chercher les métriques dont lui avait besoin. J’ai besoin de plus de métriques. Je duplique et modifie le script en ce sens.
Telegraf est capable d’invoquer différents scripts. Il dispose également de plein d’autres sources de collecte. Le site Telegraf présente à ce titre de nombreux collecteurs issus de différents fournisseurs.
La gamme Nexus9000 pour mon Réseau de DC fonctionne de la même façon que l’IOS-XE du LAN. Telegraf récupère les informations de télémétrie via gRPC avec un data format GPB (Google Proto Buf).
Le choix d’InfluxDB pour mon besoin précis n’est pas non plus anodin. InfluxDB est une base de données de type « Time Series ».
Contrairement à une base de données relationnelle, une Time Series Data Base (TSDB) associera des couples valeur – temps. Ce qui est parfaitement approprié à un besoin de Supervision. On récupère des valeurs associées à un instant t selon les métriques remontées depuis chaque composant.
Je veux modifier ou ajouter de nouveaux dashboards dans mon Graphana. Les requêtes entre Graphana et InfluxDB sont de type SQL. Je peux créer mes nouveaux dashboards dans Graphana en y associant les bonnes requêtes. Si besoin d’assistance pour la création de mes requêtes SQL, Chronograf, un autre outil Open Source, va me facilite la tâche.
Exemple obtenu :
Dans mon « dashboarding » Graphana, je peux ajouter des graphes propres à ma supervision LAN Campus, DC et WAN. Les collecteurs sont à disposition, soit via un script Python appelé par Telegraf, soit via gRPC.
Je peux ainsi disposer d’une supervision complète de l’Infrastructure de mon Système d’Information grâce à cette suite d’outils Open Source indépendamment de mes choix de composants d’Infrastructure.
Dans un prochain article, nous verrons comment certains outils peuvent aider à traiter une problématique mise à jour par le TIG ci-dessus. Mais en l’occurrence, il ne s’agira pas d’outils Open Source.
