Bloc d'activités : Supervision de la solution

Sélectionner des indicateurs pertinents de performance et de qualité du service

Entreprise : OFB

Client : idem

Projet : Supervision de la disponibilité des serveurs proxy OpenLDAP

Dates/Durée : Mai 2020/ 6 jours

Réalisation : Sélection des indicateurs de performance et de qualité à mettre en œuvre avec la solution Paessler PRTG

Autres : Zabbix pour iLinux, Cacti pour CEDICAT

Source documentaire :

https://www.paessler.com/manuals/prtg

La réalisation majeure

Définition du projet ou de la réalisation

Le but de cette réalisation fut de mettre en place des indicateurs de performance et de qualité afin de s'assurer du bon fonctionnement du mécanisme d'authentification, basé sur un proxy OpenLDAP, lors de la phase transitoire de migration d'annuaire Active Directory à l'OFB.

Objectifs, contexte, enjeu, risques, opportunités

L'objectif de cette réalisation fut de mettre en place des indicateurs de performance et de qualité concernant le mécanisme d'authentification fournit par OpenLDAP pour notre service de messagerie Zimbra hébergé chez OVEA.

La réalisation prends place dans un contexte de transition progressive des deux annuaires Active Directory de l'ONCFS et de l'AFB vers l'annuaire de l'OFB (Active Directory également, ou je fut le chef de projet). Or la solution Zimbra ne pouvait s'appuyer que sur un seul annuaire LDAP à la fois pour authentifer nos utilisateurs (pour exploiter notre nouveau domaine mail « ofb.gouv.fr »), j'ai donc du trouver une solution en urgence (en décembre 2019, soit 3 semaines avant la bascule de notre messagerie) pour pouvoir proposer un méta-annuaire fiable et hautement disponible (composé de deux serveurs Debian 10 pour héberger OpenLDAP).

Ce méta-annuaire donnait pleinement satisfaction avec un taux de disponibilité proche de 99% (il fut arrêté en août 2021 car le service de messagerie avait fini par migrer sous le nouvel annuaire Active Directory), cepandant dés qu'une coupure réseau (de plus de 5 mn) survenait sur l'un des deux sites centraux ce dernier n'était plus en mesure d'authentifier les utilisateurs. Il a donc était décidé de mettre en place des indicateurs de performance et de qualité concernant ce méta-annuaire qualifier le problème, puis l'opportunité de le prévenir.

Étapes

Pour cette réalisation j'ai du exploiter notre outil existant dédié à la supervision : la solution de supervision PRTG (Paessler).

Je me suis donc appuyé sur le travail de mon collègue Johann Lefevre (Administreur réseau à l'OFB) qui est le gestionnaire de PRTG.

J'ai donc procédé ainsi :

  • Identification des serveurs (2), protocoles (1) et autres composants (2) entrant en jeu dans l'authentification nécessaire à la messagerie Zimbra :

    • 78ProxyLDAPP1 (Debian 10 + OpenLDAP), localisé sur un site du 78,

    • 94ProxyLDAPP1 (Debian 10 + OpenLDAP), localisé sur un site du 94,

    • Protocol TCP/LDAP, port 389,

    • Protocol ICMP/full (IPv4) en interne et en externe (projet différent).

  • réunion avec l'administrateur de la solution PRTG en exposant l'architecture avec laquelle les capteurs (indicateurs) devraient tavailler,

  • Mise en place des indicateurs de performance : identification, installation et paramètrage des capteurs pour PRTG : Ping et LDAP :

  • récolte d'informations dans la durée :

  • Analyse lorsque l'incident réseau s'est reproduit :

  • Debriefing avec :

    • les responsables du services infrastructure,

    • les administrateurs réseau

    • l'administrateur de la messagerie Zimbra.

Mes actions

J'ai réalisé la plupart des étapes mentionnées ci-dessus, hormis celles conduitent avec mes collègues.

Acteurs et interactions au sein du projet

J'ai réalisé la majeur partie de l'analyse des indicateurs et leur corrélation avec le service LDAP seul en m'appuyant sur mes connaissances du système d'exploitation GNU/Linux.

Mais j'ai du m'appuyer sur les connaissances  :

  • PRTG de Johann Lefevre (Administrateur réseau à l'OFB),

  • Messagerie d'Antoine Dinahet (Administrateur messagerie à l'OFB) pour la partie troubleshooting Zimbra avec OVEA (+ accès directe au support de ce dernier),

... pour mener à bien ce projet.

Résultats (pour moi, pour l'entreprise)

Les résultats furent ceux escomptés. En effet cette réalisation nous a permis de remplir les objectifs fixés en début de projet.

L'analyse de ces indicateurs de performance nous a permis de comprendre la source exact du problème d'authentification survenant suite à une coupure réseau assez longue (> 6mn pour visible sous PRTG calé sur un échantillonage calé à 5 mn).

En conclusion :

Une fois le réseau à nouveau opérationnel les requêtes LDAP (10 000 req./s) émanant de notre prestataire de service messagerie (OVEA), provoquées par les  :

  • SmartPhone,

  • ordinateur fixes

  • ordinateurs portables

  • etc.,

... pour s'authentifier sur la messagerie Zimbra provoquaient des DoS Attack sur nos deux services OpenLDAP.

Lendemains du projet

Un deuxième PRTG a été monté, mais cette fois en dehors de notre LAN pour monitorer les IP publics censées recevoir les requêtes LDAP de notre prestataire de messagerie OVEA.

La compétence : autocritique et évolution

Mon niveau de maîtrise de la compétence

J'ai un niveau expert dans la compétence.

Place, importance, priorité de cette compétence dans mon profil d'Expert en Ingénierie ou dans mon métier actuel

Cette compétence, consistant à sélectionner des indicateurs pertinents de performance et de qualité du service, est omniprésente dans mon poste actuel (cf.Annexe : Curriculum Vitae).

Mon évolution

Ayant une solide expérience en supervision du SI avec des outils comme Zabbix pour iLinux (en 2019), Cacti pour le CEDICAT (2006), PRTG pour l'OFB, je poursuis mon évolution en me formant et travaillant sur la suite ELK.

Place de la compétence dans mon projet personnel

Au niveau personnel cette compétence m'a permis de pouvoir superviser, et ce depuis 2019, mon hébergeur associatif via Zabbix pour iLinux

Niveau que je souhaite atteindre dans cette compétence à moyen terme

Bien qu'étant expert dans cette compétence je découvre toujours des nouvelles technologies qui me permettent d'augmenter mon niveau dans cette compétence.

Formation ou autoformation en cours ou à venir, sur cette compétence

une veille technologique constante et active...participer à des forums , parcourir des sites internet.

Mettre en place un tableau de suivi des performances et de la qualité à travers les indicateurs

Entreprise : OFB

Client : idem

Projet : Tableau de bord de la solution HAProxy ALOHA

Dates/Durée : février 2022 / 5 jours

Réalisation : Tableau de bord de suivi des performances via la solution ElasticSearch Logstash Kibana pour le suivi du traffic HTTP

Source documentaire :

https://www.elastic.co/guide/index.html

https://www.haproxy.com/documentation/aloha/latest/getting-started/

La réalisation majeure

Définition du projet ou de la réalisation

l'OFB  (Office Français pour la Biodiversité) nous hébergeons plus de 150 sites Web internes et externes.

Suite à un incident électrique il m 'a été demandé d'expliquer pourquoi notre solution de reverse proxy (HAProxy ALOHA) n'avait pas correctement redémarré. Or cette solution est constitué d'un cluster d'appliance virtuelle, lequel ne stocke pas les journaux, ce qui empéche toute analyse lors d'un redémarrage.

J'ai donc du mettre en place une solution visant à mettre à disposition un tableau de suivi des performances et de la qualité à travers des indicateurs précis : ELK

Objectifs, contexte, enjeu, risques, opportunités

L'objectif de ce projet fut de monter une solution de rétention des journaux systèmes pouvant servir pour toute notre production à l'OFB mais aussi d'avoir un outil fiable, souple et modulaire pour produire des tableaux de suivi des performances et de la qualité.

Comme dit ci-dessus le contexte est celui d'un incident electrique ayant provoqué une coupure de service de 8 heures non ouvrées concernant l'accès à nos sites Web.

Beat : permet de récolter les journaux systèmes et les envoyer vers un ETL.

Logstash : est un ETL qui permet d'ingérer des données et de les filtrer/transformer au besoin.

Elasticsearch : est un logiciel d'indexation et de recherche de données.

Kibana : est un outil de visualisation de donnéee permettant, entre autre, de faire des tableaux de suivi des performances et de la qualité.

Étapes

Pour répondre à notre problématique de disposer de tableaux de suivi des performances et de la qualité j'ai procéder comme suit :

  • mise en place d'une réunion pour définir nos besoins,

  • mise en place d'une réunion pour choisir l'outil permettant de répondre aux besoins exprimés précédement : ELK sorti unanimement auprès de mes collégues,

  • auto-formation (recherches, documentations officielles, tutoriels) sur le produit,

  • réalisation d'un POC concluant, cloturé par une présentation au service infrastructure de la DSI de l'OFB,

  • mise en production de la solution ELK :

    • installation sur un serveur de production de la solution ELK,

    • sécurisation de la solution (reverse proxy, certificats, flux etc.),

    • paramètrage de l'envoi des journaux de notre solution HAProxy vers l'ETL,

    • paramètrage de l'ETL logstash avec les patterns GROK adéquates,

    • paramètrage d'Elasticsearch pour la création d'indexes concernant les journaux systèmes, d'événements et de trafic HTTP de la solution HAproxy ALOHA,

    • recettage de la confirmité des données ingérées par la solution,

    • création des tableaux de suivi des performances et de la qualité.

  • présentation de la solution mise en production suivie d'une mini-formation pour l'équipe infrastructure de l'OFB.

Note : La mise en place de cette solution avait été planifiée dans un document d'architecture technique rédigé par mes soins en concertation avec l'équipe d'administrateurs système GNU/Linux dès juin 2020.

Pour avoir plus de détail sur les étapes mentionnées ci-dessus se référer à l'Annexe : Mise en place Elasticsearch Logstash Kibana

Mes actions

J'ai réalisé personnellement toutes les étapes mentionnées ci-dessus.

Acteurs et interactions au sein du projet

Comme mentionné plus haut, la mise en place de tableaux de suivi des performances et de la qualité avait été inscrite dans un document d'architecture technique en juin 2020 par l'équipe en charge de l'administration système des serveurs GNU/Linux, à savoir :

  • moi-même,

  • Frédéric Dumont,

  • Cédric Serra,

  • Zakaria Sokrane.

La possiblité de mettre en place cette solution a été évoqué maintes fois en réunion hebdomadaire du service infrastructure de l'OFB mais écarté systèmatiquement par notre hierarchie la considérant comme non prioritaire.

Ainsi ce n'est qu'en février 2022 (suite à l'incident survenu sur notre prodution) que j'ai pris la décision de mettre en place la soution ELK.

Pour ce faire j'ai assuré 90% du travail tout en étant en relation avec les acteurs suivants :

  • Cédric Serra (Administrateur système à l'OFB),

  • Johann Lefevre (Administrateur réseau à l'OFB).

Résultats (pour moi, pour l'entreprise)

Les résultats furent ceux escomptés.

En effet cette réalisation nous a permis de remplir les objectifs fixés en début de projet et ainsi pouvoir disposer de tableaux de suivi des performances et de la qualité comme ci-dessous :

Lendemains du projet

Au niveau du deverminage j'ai d'ors et déjà identifié des points nécessitants des modifications :

  • un meilleur paramètrage de la durée de rétention des données (cycle de vie des données), cela étant du à la maitrise de la volumétrie des journaux concernant le trafic HTTP,

  • la modification, au niveau de la partie ETL ou ElasticSearch, du format de certains champs des données ingérées  : texte vs numérique, très important pour les comparaisons dans le produit ,

  • une séparation « physique » des composants de la solution :

    • Logstash(+Filebeat) sur une machine virtuelle à part,

    • 2 ou plusieurs machines virtuelles pour ElasticSearch et Kibana.

La compétence : autocritique et évolution

Mon niveau de maîtrise de la compétence

J'ai un niveau confirmé dans la compétence.

Place, importance, priorité de cette compétence dans mon profil d'Expert en Ingénierie ou dans mon métier actuel

Cette compétence est amenée à prendre une place importante dans mon profil d'expert car il nous est de plus en plus demandé de produire des représentations visuelles des actions que menons dans les couches basses du système d'information, au niveau de l'infrastructure.

Mon évolution

Ne connaissant pas techniquement ELK avant ce projet, je souhaite acquérir un bonne expertise de ce genre de solution, de ce fait une formation vient d'être demandé à notre service formation. Cette dernière est programmée pour cette année.

Place de la compétence dans mon projet personnel

Cette compétence prends une place très importante dans mon projet personnel, cf. la demande de formation sur la plate-forme ElasticSearch (ELK).

Niveau que je souhaite atteindre dans cette compétence à moyen terme

Bien qu'étant d'un nivau confirmé dans cette compétence je découvre toujours des nouvelles technologies qui me permettent d'augmenter mon niveau dans cette compétence.

A terme je souhaite être capable de savoir déployer un cluster complet pour la solution ELK ainsi que maitriser la partie concernant la création de tableaux de suivi des performances et de la qualité.

Formation ou autoformation en cours ou à venir, sur cette compétence

Formation demandé sur 2022 ... et consultation régulière du forum dédié au produit :

Activité sur le forum communautaire (Discourse) dédié à la solution et consultation régulière de la documentation du produit.

Maintenir la qualité du service en utilisant les outils adéquats

Entreprise : OFB

Client : idem

Projet : Assurer la qualité de service de la production GNU/Linux à l'OFB

Dates/Durée : septembre 2021/ 8 jours

Réalisation : Garantir le bon fonctionnement donc la qualité de service de la production GNU/Linux à l'aide de l'outil Rundeck

Second : Ansible (client : OFB & iLinux)

Source documentaire :

https://docs.rundeck.com/docs/about/introduction.html#what-is-rundeck

La réalisation majeure

Définition du projet ou de la réalisation

Ce projet consiste en la mise place d'un frontal graphique permettant de piloter l'outil de mise en conformité du SI via l'outil Ansible, ce dernier étant en production depuis juin 2020 à l'OFB.

Objectifs, contexte, enjeu, risques, opportunités

Suite à la fusion des 2 établissements publiques ONCFS et AFB (janvier 2020) il n'était plus envisageable de gérer les serveurs GNU/Linux de manière unitaire, c'est à dire sans mise en place d'une industrialisation du processus de cycle de vie des serveurs GNU/Linux.

L'objectif était donc de mettre en place un outil permettant de suivre et maintenir la qualité de service de la production des serveurs GNU/Linux de façon simple et synthétique.

En juin 2020 suite à la fusion, des contrats de services sont arrivés à terme.

Dans l'urgence (moins de 2 mois de marge de manoeuvre) il nous (service infrastructure) a été demandé d'accueillir plus d'une cinquantaine de nouveaux serveurs GNU/Linux sur nos 4 DataCenter donc sur notre plate-forme de virtualisation VMware vSphere.

Certains serveurs GNU/Linux furent dupliqués tel quel, mais pour d'autres ce fût des nouveaux déploiements qui ont du être effectués.

Par conséquent fort de mon expérience avec la création de mon hébergeur associatif iLinux, j'ai proposé à l'équipe d'administrateurs GNU/Linux de mettre en oeuvre l'outil Ansible.

Devant l'urgence de la situation j'ai été obligé de gérer cette partie du projet de mise en place d'une infrastructure Ansible, laquelle étant amenée à piloter un peu plus d'une centaine de serveurs (mes collégues n'ayant pas ce genre d'expérience) :

A ce jour, seuls 2 ETP au mieux (sur une équipe de 10 ETP dont les 2 chefs) sont en mesure d'assurer la gestion quotidienne de la production pilotée par Ansible.

L'enjeu était donc de mettre en place un habillage graphique à cette solution afin de permettre une maintenance aisée de la qualité du service concernant la production GNU/Linux.

De ce fait, après plusieurs POC portant sur plusieurs produits d'ordonnancement, j'ai choisi de mettre en place la solution Open sourceRundeck.

L'opportunités qu'offrait ce genre d'outils était aussi de permettre des déploiements et configurations rapides des serveurs GNU/Linux via une interface graphique.

Étapes

Pour mettre en oeuvre cet outil de supervision de la production et de maintien de la qualité de service j'ai procédé comme suit :

  • mise en production de l'outil Rundeck:

    • installation sur un serveur de production,

    • sécurisation de la solution (reverse proxy, certificats, flux etc.),

    • paramètrage initial de l'outil (création des environnements de test, puis recette enfin de production),

    • très légère adaptation de la production Ansible pour être pilotée par ce nouvel outil,

    • nouveau paramètrage de l'outil afin de créer des modèles de travaux (travaux de masterisation de serveur, de mise en conformité unitaire et de regroupement par serveur),

    • recettage et homologation de la solution sur des travaux de test,

    • validation de la solution afin de maintenir la qualité de service inhérente à nos serveurs GNU/Linux.

  • présentation de la solution mise en production et mini-formation pour l'équipe infrastructure de l'OFB.

Pour avoir plus de détail sur l'outil Rundeck veuillez vous référer à l'Annexe : Mise en place de Rundeck

Mes actions

J'ai réalisé personnellement toutes les étapes mentionnées ci-dessus.

Acteurs et interactions au sein du projet

Je fut le principal acteur de ce projet.

Les collègues suivants, qui n'ont pas le temps de gérer la production et d'assurer en simultané la conduite de projet touchant à la globalité de l'infrastructure, sont intervenus au moment d'être formé par mes soins :

  • Cédric Serra (Administrateur système, service infrastructure DSI-OFB),

  • Frédéric Dumont (Administrateur système, service infrastructure DSI-OFB),

  • Benoit Le-goulm (Technicien informatique du support utilisateur qui assure la liaison entre le service infrastructure et son service)

L'objectif étant de simplifier leurs tâches de maintien de la qualité de service inhérente à nos serveurs GNU/Linux.

Résultats (pour moi, pour l'entreprise)

Les résultats furent ceux escomptés.

En effet cette réalisation nous a permis de remplir les objectifs fixés en début de projet.

Lendemains du projet

Suite à cette mise en poduction plutot réussie, j'ai souhaité prendre contact avec la société (US) assurant le support payant du logiciel afin de bénéficer d'un support officielle (en plus du support communautaire) et ainsi rassurer ma hierarchie.

Après quelques échanges par courriel et une réunion avec la société (US), il en est resorti que nous n'avion pas besoin de prendre la version payante du produit :la version communautaire suffisait.

En plus de former l'équipe d'administrateurs GNU/Linux j'ai mis en place une séance d'information auprès des chefs de projet intéressés.

Le but étant que ces derniers puissent avoir un visuel sur l'état de la production.

Mon regard critique sur le projet ou la réalisation

Il s'agit d'un regard plutot positif, car l'outil Rundeck permet aisément de maintenir la qualité de service attendue pour une exploitation de serveurs GNU/Linux en environnement professionnel.

Je regrette cependant de n'avoir pas pu monter un cluster afin d'assurer la haute disponibilité de la solution.

La compétence : autocritique et évolution

Mon niveau de maîtrise de la compétence

J'ai un niveau confirmé dans la compétence.

Place, importance, priorité de cette compétence dans mon profil d'Expert en Ingénierie ou dans mon métier actuel

Cette compétence est toujours prioritaire dans mon profil d'Expert en Ingénierie, car je dois constament m'assurer que la qualité de service soit au rendez-vous pour chaque projet que je dois mener.

La recherche d'outils permettant d'atteindre ce but est donc toujours d'actualité.

Mon évolution

A terme je souhaiterai pouvoir piloter notre production Ansible via l'outil clairement dédié à cela : RedHat Ansible TOWER.

Pour se faire nous devons d'abord monter en compétence sur la plate-forme Kubernetes car de plus en plus de produit sont uniquement exploitables via cette plat-forme : Ansible TOWER en fait partie.

Place de la compétence dans mon projet personnel

Je pense que cette compétence doit rester une cible à atteindre, car la qualité de service est la plupart du temps au centre des discussions dans un service informatique.

Niveau que je souhaite atteindre dans cette compétence à moyen terme

Bien qu'étant d'un niveau confirmé dans cette compétence je découvre toujours des nouvelles technologies qui me permettent d'augmenter mon niveau dans cette compétence.

Formation ou autoformation en cours ou à venir, sur cette compétence

Je reste en constante veille technologique sur cette compétence, le marché évoluant assez vite dans ce domaine.