Cloud Computing; Infrastructure DevOps

Infrastructure gérée par évènements

Contexte

Dans le contexte actuel, toujours plus tendu, de gestion des infrastructures informatiques au services des applications d’entreprise, et le développement du cloud computing; le besoin de la mise en place d’infrastructures informatiques réactives se fait impératif, en particulier dans les démarches DevOps.

De plus, cette souplesse et les besoins grandissants, tant en termes de nombre d’applications que de réactivité face aux charges rencontrées, ainsi que les impératifs de réduction des coûts et d’émission de CO2 (Green IT, es-tu là ?), font que les attendus de la part des infrastructures sont de plus en plus grandes, aussi bien en adaptabilité qu’en réactivité.

Dans les filières historiques, la réactivité dépend majoritairement des exploitants. Ceux-ci utilisent des outils de supervision des systèmes et applicatifs (Nagios, AppDynamics, DynaTrace, Prometheus, etc.). De manière conventionnelle, ces outils sont utilisés pour alerter l’exploitant des problèmes survenant à un instant, mais trop peu souvent pour remédier à ces mêmes problèmes (les systèmes d’alerting étant utilisés pour envoyer des mails/SMS/etc. aux exploitants).

Et si ces systèmes de supervision étaient intégrés dans les chaînes de déploiement, et les systèmes d’alerting utilisé pour générer des évènements auxquels ces chaînes pourraient répondre sans intervention humaine ?

Nous allons voir dans cet article comment répondre à des évènements en utilisant Saltstack.

Cas de gestion des systèmes de fichiers

Intéressons-nous à un cas simple, et rencontré fréquemment par les équipes d’exploitation : La saturation d’un système de fichiers.

Prenons l’exemple d’un système Linux supervisé par un logiciel de supervision système (Centreon/Prometheus…). Vous avez à disposition des métriques vous permettant de déterminer l’utilisation des ressources du SI.

Ces métriques permettent alors de définir des seuils d’alerte, ceux-ci servant en général à avertir les administrateurs système des risques en cours.

Lorsque votre sonde lève une alerte concernant l’utilisation d’un système de fichiers, vous pouvez alors définir une réaction à cette alerte.
Voici un schéma explicatif :

Schéma de gestion d'alerte

Ici, nous allons exécuter une commande shell générant un évènement dans le bus d’évènement de Saltstack :

Nous devons alors indiquer à Saltstack de réagir à cet évènement. Ceci se fait dans la configuration du salt-master :

Nous écrivons ensuite le comportement à adopter (ici, nous avons choisi d’augmenter la taille du volume logique de 20%) :

Limitations

Évidemment, ceci reste un exemple volontairement simpliste. Dans un cas réel, il faudra également se préoccuper des éléments sous-jacents :

  • Taille des groupes de volumes associés aux volumes logiques
  • Disponibilité et taille des disques physiques existants
  • Gestion du rétrécissement des volumes logiques
  • Gestion des contraintes applicatives (taille minimum du système de fichier, par exemple)

Projections

Plusieurs cas d’usage peuvent être envisagés, en utilisant ce système afin de répondre à différentes problématiques d’exploitation :

  • Auto-Scaling
  • Résilience des infrastructures
  • Maintient en conditions de sécurité

Auto-Scaling

Si nous nous plaçons du côté applicatif, le dimensionnement des clusters, leur configuration, ainsi que la gestion des ressources et des flux pèsent lourdement sur les équipes en charge de l’exploitation. En effet, ces dernières doivent adapter la configuration des middlewares aux différents nœuds des clusters, ouvrir et fermer les flux entre les composants via la configuration des firewall et autres boitiers réseau, afin de les adapter aux changements nécessaires impliqués par un redimensionnement.

Dans les faits, une supervision d’un cluster applicatif peut parfaitement remonter une alerte en cas de dépassement de seuils (mémoire utilisée, nombre de descripteurs de fichiers, taille des pools, etc.).

Ces alertes peuvent alors être utilisées pour ajouter ou supprimer des nœuds dans un cluster, en effectuant de manière autonome du provisionning de VM, et des installations de middlewares et applicatifs. Ces évènements d’ajout et de suppression peuvent alors être utilisés en cascade, afin de reconfigurer les équipements réseau et les répartiteurs de charge (ou tout autre composant en liaison directe).

Évidemment, dans les faits, ceci est légèrement plus complexe, car il faut également prendre en compte la répartition des nœuds au sein des châssis hébergeurs, ainsi que la capacité de ces châssis. Tout ceci afin d’éviter de surcharger certains composants physiques ou de voir apparaître des points individuels de défaillance (SPOF).

Résilience des infrastructures

De la même façon, les applications de supervision peuvent détecter l’arrêt d’un composant du SI. Cet arrêt peut alors être traité soit en redémarrant le composant, soit en le recréant.

En se projetant, toute défaillance peut être identifiée et des tentatives de remédiation être mises en place.

Dans le cas de défaillance de filesystem, par exemple, il est envisageable de ré-allouer un disque, d’effectuer une restauration de la dernière sauvegarde et de remonter ce nouveau filesystem sur le système ayant été soumis à cette défaillance.

Maintient en conditions de sécurité

Dans le cas de la sécurité, les failles et problèmes de sécurité peuvent également être supervisées. Les alertes peuvent alors être traitées en appliquant des correctifs de sécurité, en effectuant des reconfigurations, ou toute autre action nécessitée par l’alerte levée.

Un exemple récent a été la faille Spectre, ou un exemple de gestion de cette faille et d’application de correctif a été détaillé dans un article illustrant bien les principes évoqués.

Nous nous plaçons alors dans une optique DevSecOps ou les équipes d’exploitation, de sécurité et de développement travaillent de concert afin de répondre de la manière la plus proactive possible à la bonne santé du système d’information.

Conclusion

Bon nombre d’opérations peuvent être (et devraient) être automatisées au sein de l’infrastructure d’un SI, dégageant du temps pour les exploitants afin qu’il puissent se concentrer sur des tâches à plus forte valeur ajoutée.

C’est d’ailleurs la logique poursuivi par les fournisseurs cloud computing. Ceux-ci mettent en effet à disposition des ressources et des mécaniques permettant, dans l’état de l’art actuel, de ne déposer au final que du code, sans se préoccuper de toute la gestion afférente aux ressources utilisées (cas du Serverless computing, et dans ses déclinaisons, du PaaS et du FaaS).

Toutefois, toutes les entreprises, en fonction de leurs contraintes légales et/ou opérationnelles, ne peuvent pas se tourner vers de telles solutions. De même, toutes les entreprises n’ont pas les moyens de mettre en place un cloud privée, pour des raisons de coûts et/ou de compétences.

Les mécaniques offertes par Saltstack permettent alors d’apporter de la souplesse et de la réactivité aux infrastructures.

Les possibilités ne sont limitées que par votre imagination et vos souhaits d’automatisation !

Leave a Reply

Your email address will not be published. Required fields are marked *