🥇Automatisation du remplacement de disque à l'aide d'Ansible

Salut tout le monde. Je travaille en tant qu'administrateur système principal chez OK et je suis responsable du fonctionnement stable du portail. Je veux parler de la façon dont nous avons construit un processus de remplacement automatique des disques, puis de la façon dont nous avons exclu l'administrateur de ce processus et l'avons remplacé par un robot.

Cet article est une sorte de translittération des performances à HighLoad+ 2018

Construire un processus de remplacement de disque

D'abord quelques chiffres

OK est un service géant utilisé par des millions de personnes. Il est desservi par environ 7 4 serveurs, situés dans 70 centres de données différents. Les serveurs contiennent plus de 1 XNUMX disques. Si vous les empilez les uns sur les autres, vous obtenez une tour de plus de XNUMX km de haut.

Les disques durs sont le composant du serveur qui tombe en panne le plus souvent. Avec de tels volumes, nous devons changer environ 30 disques par semaine, et cette procédure est devenue une routine peu agréable.

Incidents

Notre entreprise a mis en place une gestion complète des incidents. Nous enregistrons chaque incident dans Jira, puis nous le résolvons et le trions. Si un incident a eu un impact sur les utilisateurs, nous nous réunissons certainement et réfléchissons à la manière de réagir plus rapidement dans de tels cas, de réduire l'effet et, bien sûr, d'éviter qu'une répétition ne se reproduise.

Les périphériques de stockage ne font pas exception. Leur statut est surveillé par Zabbix. Nous surveillons les messages dans Syslog pour détecter les erreurs d'écriture/lecture, analysons l'état des raids matériels/logiciels, surveillons SMART et calculons l'usure des SSD.

Comment les disques étaient changés auparavant

Lorsqu'un déclencheur se produit dans Zabbix, un incident est créé dans Jira et automatiquement attribué aux ingénieurs appropriés dans les centres de données. Nous faisons cela pour tous les incidents matériels, c'est-à-dire ceux qui nécessitent un travail physique avec les équipements du centre de données.
Un ingénieur de centre de données est une personne qui résout les problèmes liés au matériel et est responsable de l'installation, de la maintenance et du démontage des serveurs. Après avoir reçu le ticket, l'ingénieur se met au travail. Dans les étagères de disques, il change les disques de manière indépendante. Mais s'il n'a pas accès à l'appareil requis, l'ingénieur se tourne vers les administrateurs système en service pour obtenir de l'aide. Tout d'abord, vous devez retirer le disque de la rotation. Pour ce faire, vous devez apporter les modifications nécessaires sur le serveur, arrêter les applications et démonter le disque.

L'administrateur système de service est responsable du fonctionnement de l'ensemble du portail pendant le quart de travail. Il enquête sur les incidents, effectue des réparations et aide les développeurs à accomplir de petites tâches. Il ne s'occupe pas uniquement des disques durs.

Auparavant, les ingénieurs du centre de données communiquaient avec l'administrateur système via le chat. Les ingénieurs envoyaient des liens vers des tickets Jira, l'administrateur les suivait, tenait un journal de travail dans un bloc-notes. Mais les chats sont peu pratiques pour de telles tâches : les informations n'y sont pas structurées et se perdent rapidement. Et l'administrateur pouvait simplement s'éloigner de l'ordinateur et ne pas répondre aux demandes pendant un certain temps, tandis que l'ingénieur se tenait devant le serveur avec une pile de disques et attendait.

Mais le pire, c'est que les administrateurs n'avaient pas une vue d'ensemble : quels incidents de disque existaient, où un problème pouvait potentiellement survenir. Cela est dû au fait que nous déléguons tous les incidents matériels aux ingénieurs. Oui, il était possible d'afficher tous les incidents sur le tableau de bord de l'administrateur. Mais ils sont nombreux et l’administrateur n’est intervenu que pour certains d’entre eux.

De plus, l'ingénieur n'a pas pu définir correctement les priorités, car il ne sait rien de l'objectif de serveurs spécifiques ni de la répartition des informations entre les lecteurs.

Nouvelle procédure de remplacement

La première chose que nous avons faite a été de déplacer tous les incidents de disque dans un type distinct « Disque matériel » et d'y ajouter les champs « Nom du périphérique de blocage », « Taille » et « Type de disque » afin que ces informations soient stockées dans le ticket et soient pas besoin d'échanger constamment dans le chat.

Nous avons également convenu que lors d'un incident, nous ne changerions qu'un seul disque. Cela a considérablement simplifié le processus d'automatisation, la collecte de statistiques et le travail futur.

De plus, nous avons ajouté le champ « administrateur responsable ». L'administrateur système en service y est automatiquement inséré. C'est très pratique, car désormais l'ingénieur voit toujours qui est responsable. Pas besoin d'aller dans le calendrier et de rechercher. C’est ce champ qui permettait d’afficher sur le tableau de bord de l’administrateur les tickets pouvant nécessiter son aide.

Pour garantir que tous les participants bénéficient au maximum des innovations, nous avons créé des filtres et des tableaux de bord et en avons parlé aux gars. Lorsque les gens comprennent les changements, ils ne s’en éloignent pas comme si c’était quelque chose d’inutile. Il est important qu'un ingénieur connaisse le numéro du rack où se trouve le serveur, la taille et le type de disque. L'administrateur doit tout d'abord comprendre de quel type de groupe de serveurs il s'agit et quel peut être l'effet du remplacement d'un disque.

La présence de champs et leur affichage sont pratiques, mais cela ne nous a pas épargné de devoir utiliser les chats. Pour ce faire, nous avons dû modifier le workflow.

Avant, c'était comme ça :

C'est ainsi que les ingénieurs continuent de travailler aujourd'hui lorsqu'ils n'ont pas besoin de l'aide d'un administrateur.

La première chose que nous avons faite a été d'introduire un nouveau statut Enquêter. Le ticket est dans cet état lorsque l'ingénieur n'a pas encore décidé s'il aura besoin ou non d'un administrateur. Grâce à ce statut, l'ingénieur peut transférer le ticket à l'administrateur. De plus, nous utilisons ce statut pour marquer les tickets lorsqu'un disque doit être remplacé, mais que le disque lui-même n'est pas sur place. Cela se produit dans le cas des CDN et des sites distants.

Nous avons également ajouté le statut Prêt à fonctionner. Le ticket y est transféré après remplacement du disque. Autrement dit, tout a déjà été fait, mais le RAID matériel/logiciel est synchronisé sur le serveur. Cela peut prendre beaucoup de temps.

Si un administrateur est impliqué dans les travaux, le schéma devient un peu plus compliqué.

Du statut Ouvert Le ticket peut être traduit à la fois par l'administrateur système et par l'ingénieur. En statut En cours l'administrateur supprime le disque de la rotation pour que l'ingénieur puisse simplement le retirer : allume le rétroéclairage, démonte le disque, arrête les applications, en fonction du groupe spécifique de serveurs.

Le billet est ensuite transféré à Prêt à changer: Ceci est un signal à l'ingénieur que le disque peut être retiré. Tous les champs de Jira sont déjà remplis, l'ingénieur sait quel type et quelle taille de disque. Ces données sont saisies soit automatiquement sur le statut précédent, soit par l'administrateur.

Après avoir remplacé le disque, le statut du ticket passe à Changé. Il vérifie que le bon disque a été inséré, le partitionnement est effectué, l'application est lancée et certaines tâches de récupération de données sont lancées. Le ticket peut également être transféré au statut Prêt à fonctionner, dans ce cas l'administrateur restera responsable, car il a mis le disque en rotation. Le diagramme complet ressemble à ceci.

L'ajout de nouveaux champs nous a rendu la vie beaucoup plus facile. Les gars ont commencé à travailler avec des informations structurées, il est devenu clair ce qui devait être fait et à quel stade. Les priorités sont devenues beaucoup plus pertinentes, puisqu'elles sont désormais fixées par l'administrateur.

Il n'y a pas besoin de chats. Bien entendu, l'administrateur peut écrire à l'ingénieur « il faut le remplacer plus rapidement » ou « c'est déjà le soir, aurez-vous le temps de le remplacer ? Mais nous ne communiquons plus quotidiennement dans les chats sur ces sujets.

Les disques ont commencé à être changés par lots. Si l'administrateur est venu travailler un peu plus tôt, qu'il a du temps libre et que rien ne s'est encore passé, il peut préparer un certain nombre de serveurs à remplacer : remplir les champs, retirer les disques de la rotation et confier la tâche à un ingénieur. L'ingénieur arrive au centre de données un peu plus tard, voit la tâche, prend les disques nécessaires dans l'entrepôt et les remplace immédiatement. En conséquence, le taux de remplacement a augmenté.

Leçons apprises lors de la création d'un workflow

Lors de l’élaboration d’une procédure, vous devez collecter des informations provenant de différentes sources.
Certains de nos administrateurs ne savaient pas que l'ingénieur change lui-même les disques. Certaines personnes pensaient que la synchronisation MD RAID était gérée par les ingénieurs, même si certains d'entre eux n'y avaient même pas accès. Certains ingénieurs de renom l’ont fait, mais pas toujours parce que le processus n’était décrit nulle part.
La procédure doit être simple et compréhensible.
Il est difficile pour une personne de garder à l’esprit de nombreuses étapes. Les statuts voisins les plus importants dans Jira doivent être placés sur l'écran principal. Vous pouvez les renommer, par exemple, nous les appelons En cours Prêt à changer. Et d'autres statuts peuvent être masqués dans un menu déroulant afin qu'ils ne soient pas une nuisance visuelle. Mais il vaut mieux ne pas limiter les gens, leur donner la possibilité de faire la transition.
Expliquez la valeur de l’innovation. Lorsque les gens comprennent, ils acceptent davantage la nouvelle procédure. Il était très important pour nous que les gens ne suivent pas tout le processus, mais le suivent. Ensuite, nous avons construit l'automatisation sur cette base.
Attendez, analysez, comprenez.
Il nous a fallu environ un mois pour construire la procédure, la mise en œuvre technique, les réunions et les échanges. Et la mise en œuvre prend plus de trois mois. J'ai vu comment les gens commencent lentement à utiliser l'innovation. Il y avait beaucoup de négativité au début. Mais cela était totalement indépendant de la procédure elle-même et de sa mise en œuvre technique. Par exemple, un administrateur n'utilisait pas Jira, mais le plugin Jira dans Confluence, et certaines choses ne lui étaient pas disponibles. Nous lui avons montré Jira et la productivité de l'administrateur a augmenté à la fois pour les tâches générales et pour le remplacement des disques.

Automatisation du remplacement des disques

Nous avons abordé l'automatisation du remplacement des disques à plusieurs reprises. Nous avions déjà des développements et des scripts, mais ils fonctionnaient tous soit de manière interactive, soit manuellement et nécessitaient un lancement. Et ce n’est qu’après avoir introduit la nouvelle procédure que nous avons réalisé que c’était exactement ce qui nous manquait.

Puisque notre processus de remplacement est désormais divisé en étapes, chacune ayant un intervenant spécifique et une liste d'actions, nous pouvons activer l'automatisation par étapes, et non en une seule fois. Par exemple, l'étape la plus simple - Prêt (vérification de la synchronisation RAID/données) peut être facilement déléguée à un bot. Lorsque le bot a appris un peu, vous pouvez lui confier une tâche plus importante : mettre le disque en rotation, etc.

Installations de zoo

Avant de parler du bot, faisons une petite excursion dans notre zoo d’installations. Tout d’abord, cela est dû à la taille gigantesque de nos infrastructures. Deuxièmement, nous essayons de sélectionner la configuration matérielle optimale pour chaque service. Nous avons environ 20 modèles RAID matériels, principalement LSI et Adaptec, mais il existe également HP et DELL de différentes versions. Chaque contrôleur RAID possède son propre utilitaire de gestion. L'ensemble des commandes et leur émission peuvent différer d'une version à l'autre pour chaque contrôleur RAID. Lorsque HW-RAID n’est pas utilisé, mdraid peut être utilisé.

Nous effectuons presque toutes les nouvelles installations sans sauvegarde de disque. Nous essayons de ne plus utiliser le RAID matériel et logiciel, car nous sauvegardons nos systèmes au niveau du centre de données, et non des serveurs. Mais bien sûr, de nombreux serveurs existants doivent être pris en charge.

Quelque part, les disques des contrôleurs RAID sont transférés vers des périphériques bruts, quelque part des JBOD sont utilisés. Il existe des configurations avec un disque système dans le serveur, et s'il doit être remplacé, il faut alors réinstaller le serveur avec l'installation du système d'exploitation et des applications, des mêmes versions, puis ajouter des fichiers de configuration, lancer des applications. Il existe également de nombreux groupes de serveurs où la sauvegarde est effectuée non pas au niveau du sous-système disque, mais directement dans les applications elles-mêmes.

Au total, nous disposons de plus de 400 groupes de serveurs uniques exécutant près de 100 applications différentes. Pour couvrir un si grand nombre d’options, nous avions besoin d’un outil d’automatisation multifonctionnel. De préférence avec un simple DSL, afin que non seulement celui qui l'a écrit puisse le prendre en charge.

Nous avons choisi Ansible car il est sans agent : il n'y avait pas besoin de préparer l'infrastructure, un démarrage rapide. De plus, il est écrit en Python, qui est accepté comme standard au sein de l’équipe.

Régime général

Examinons le schéma général d'automatisation en utilisant un incident comme exemple. Zabbix détecte que le disque SDB est en panne, le déclencheur s'allume et un ticket est créé dans Jira. L'administrateur l'a examiné, s'est rendu compte qu'il ne s'agissait pas d'un doublon ni d'un faux positif, c'est-à-dire que le disque devait être changé et a transféré le ticket vers En cours.

L'application DiskoBot, écrite en Python, interroge périodiquement Jira pour détecter de nouveaux tickets. Il remarque qu'un nouveau ticket En cours est apparu, le thread correspondant se déclenche, qui lance le playbook dans Ansible (cela se fait pour chaque statut dans Jira). Dans ce cas, Prepare2change est lancé.

Ansible est envoyé à l'hôte, supprime le disque de la rotation et signale l'état à l'application via des rappels.

En fonction des résultats, le bot transfère automatiquement le ticket vers Prêt à modifier. L'ingénieur reçoit une notification et va changer le disque, après quoi il transfère le ticket vers Changé.

Selon le schéma décrit ci-dessus, le ticket retourne au bot, qui lance un autre playbook, se rend chez l'hôte et met le disque en rotation. Le bot ferme le ticket. Hourra!

Parlons maintenant de certains composants du système.

Diskobot

Cette application est écrite en Python. Il sélectionne les tickets de Jira selon JQL. En fonction du statut du ticket, ce dernier est dirigé vers le gestionnaire correspondant, qui lance à son tour le playbook Ansible correspondant au statut.

JQL et les intervalles d'interrogation sont définis dans le fichier de configuration de l'application.

jira_states:
  investigate:
    jql: '… status = Open and "Disk Size" is EMPTY'
    interval: 180

  inprogress:
    jql: '…  and "Disk Size" is not EMPTY and "Device Name" is not EMPTY'
 
  ready:
    jql: '… and (labels not in ("dbot_ignore") or labels is EMPTY)'
    interval: 7200

Par exemple, parmi les tickets au statut En cours, seuls ceux dont les champs Taille du disque et Nom du périphérique sont renseignés sont sélectionnés. Le nom du périphérique est le nom du périphérique bloc nécessaire pour exécuter le playbook. La taille du disque est nécessaire pour que l'ingénieur sache quelle taille de disque est nécessaire.

Et parmi les tickets avec le statut Prêt, les tickets avec l’étiquette dbot_ignore sont filtrés. À propos, nous utilisons les étiquettes Jira à la fois pour ce filtrage et pour marquer les tickets en double et collecter des statistiques.

Si un playbook échoue, Jira attribue l'étiquette dbot_failed afin qu'il puisse être trié ultérieurement.

Interopérabilité avec Ansible

L'application communique avec Ansible via API Python Ansible. À playbook_executor, nous transmettons le nom du fichier et un ensemble de variables. Cela vous permet de conserver le projet Ansible sous la forme de fichiers yml classiques, plutôt que de le décrire en code Python.

Toujours dans Ansible, via *extra_vars*, le nom du périphérique de blocage, le statut du ticket, ainsi que le callback_url, qui contient la clé d'émission - il est utilisé pour le rappel en HTTP.

Pour chaque lancement, un inventaire temporaire est généré, composé d'un hôte et du groupe auquel cet hôte appartient, afin que les group_vars soient appliquées.

Voici un exemple de tâche qui implémente le rappel HTTP.

Nous obtenons le résultat de l’exécution de playbooks à l’aide de callaback(s). Ils sont de deux types :

Plugin de rappel Ansible, il fournit des données sur les résultats de l'exécution du playbook. Il décrit les tâches qui ont été lancées, terminées avec succès ou non. Ce rappel est appelé lorsque la lecture du playbook a terminé.
Rappel HTTP pour recevoir des informations lors de la lecture d'un playbook. Dans la tâche Ansible, nous exécutons une requête POST/GET à notre application.

Les variables sont transmises via des rappels HTTP qui ont été définis lors de l'exécution du playbook et que nous souhaitons enregistrer et utiliser lors des exécutions ultérieures. Nous écrivons ces données en sqlite.

Nous laissons également des commentaires et modifions le statut du ticket via un rappel HTTP.

Rappel HTTP

# Make callback to Diskobot App
# Variables:
#    callback_post_body: # A dict with follow keys. All keys are optional
#       msg: If exist it would be posted to Jira as comment
#       data: If exist it would be saved in Incident.variables
#       desire_state: Set desire_state for incident
#       status: If exist Proceed issue to that status

  - name: Callback to Diskobot app (jira comment/status)
    uri:
      url: "{{ callback_url }}/{{ devname }}"
      user: "{{ diskobot_user }}"
      password: "{{ diskobot_pass }}"
      force_basic_auth: True
      method: POST
      body: "{{ callback_post_body | to_json }}"
      body_format: json
    delegate_to: 127.0.0.1

Comme beaucoup de tâches du même type, nous la mettons dans un fichier commun séparé et l'incluons si nécessaire, afin de ne pas la répéter constamment dans les playbooks. Cela inclut l'url callback_, qui contient la clé du problème et le nom d'hôte. Lorsqu’Ansible exécute cette requête POST, le bot comprend qu’elle s’inscrit dans le cadre de tel ou tel incident.

Et voici un exemple tiré du playbook, dans lequel nous produisons un disque à partir d'un périphérique MD :

  # Save mdadm configuration
  - include: common/callback.yml
    vars:
      callback_post_body:
        status: 'Ready to change'
        msg: "Removed disk from mdraid {{ mdadm_remove_disk.msg | comment_jira }}"
        data:
          mdadm_data: "{{ mdadm_remove_disk.removed }}"
          parted_info: "{{ parted_info | default() }}"
    when:
      - mdadm_remove_disk | changed
      - mdadm_remove_disk.removed

Cette tâche transfère le ticket Jira au statut « Prêt à modifier » et ajoute un commentaire. De plus, la variable mdam_data stocke une liste des périphériques md dont le disque a été supprimé, et parted_info stocke un vidage de partition de parted.

Lorsque l'ingénieur insère un nouveau disque, nous pouvons utiliser ces variables pour restaurer le vidage de la partition, ainsi que pour insérer le disque dans les périphériques md dont il a été supprimé.

Mode de vérification Ansible

C'était effrayant d'allumer l'automatisation. Par conséquent, nous avons décidé d'exécuter tous les playbooks en mode
course à sec, dans lequel Ansible n'effectue aucune action sur les serveurs, mais les émule uniquement.

Un tel lancement est exécuté via un module de rappel séparé et le résultat de l'exécution du playbook est enregistré dans Jira en tant que commentaire.

Tout d’abord, cela a permis de valider le travail du bot et des playbooks. Deuxièmement, cela a accru la confiance des administrateurs dans le bot.

Lorsque nous avons réussi la validation et réalisé que vous pouvez exécuter Ansible non seulement en mode d'exécution à sec, nous avons créé un bouton Exécuter Diskobot dans Jira pour lancer le même playbook avec les mêmes variables sur le même hôte, mais en mode normal.

De plus, le bouton permet de redémarrer le playbook s'il plante.

Structure des manuels de jeu

J'ai déjà mentionné qu'en fonction du statut du ticket Jira, le bot lance différents playbooks.

Premièrement, il est beaucoup plus facile d’organiser l’entrée.
Deuxièmement, dans certains cas, c'est simplement nécessaire.

Par exemple, lors du remplacement d'un disque système, vous devez d'abord accéder au système de déploiement, créer une tâche, et après un déploiement correct, le serveur deviendra accessible via ssh et vous pourrez y déployer l'application. Si nous faisions tout cela dans un seul playbook, Ansible ne serait pas en mesure de le terminer en raison de l'indisponibilité de l'hôte.

Nous utilisons des rôles Ansible pour chaque groupe de serveurs. Ici, vous pouvez voir comment le(s) playbook(s) sont organisés dans l'un d'entre eux.

C’est pratique car il est immédiatement clair où se trouvent les tâches. Dans main.yml, qui est l'entrée du rôle Ansible, nous pouvons simplement inclure par statut de ticket ou les tâches générales requises pour tout le monde, par exemple passer une pièce d'identité ou recevoir un jeton.

Enquête.yml

Exécute les tickets avec le statut Enquête et Ouvert. La chose la plus importante pour ce playbook est le nom du périphérique bloqué. Ces informations ne sont pas toujours disponibles.

Pour l'obtenir, nous analysons le résumé Jira, la dernière valeur du déclencheur Zabbix. Il peut contenir le nom du périphérique bloc - chanceux. Ou il peut contenir un point de montage, vous devez alors vous rendre sur le serveur, l'analyser et calculer le disque requis. Le déclencheur peut également transmettre une adresse scsi ou d'autres informations. Mais il arrive aussi qu’il n’y ait pas d’indices, et qu’il faille analyser.

Après avoir découvert le nom du périphérique bloc, nous collectons des informations sur le type et la taille du disque pour remplir les champs dans Jira. Nous supprimons également les informations sur le fournisseur, le modèle, le firmware, l'ID, SMART, et insérons tout cela dans un commentaire dans le ticket Jira. L'administrateur et l'ingénieur n'ont plus besoin de rechercher ces données. 🙂

préparer2change.yml

Retrait du disque de la rotation, préparation au remplacement. L'étape la plus difficile et la plus importante. C'est ici que vous pouvez arrêter l'application alors qu'elle ne devrait pas l'être. Ou supprimez un disque qui ne contenait pas suffisamment de répliques, ce qui aurait un effet sur les utilisateurs en perdant certaines données. Ici, nous avons le plus de contrôles et de notifications dans le chat.

Dans le cas le plus simple, nous parlons de supprimer un disque d'un RAID HW/MD.

Dans des situations plus complexes (dans nos systèmes de stockage), lorsque la sauvegarde est effectuée au niveau de l'application, vous devez accéder à l'application via l'API, signaler la sortie du disque, la désactiver et lancer la récupération.

Nous migrons désormais en masse vers nuage, et si le serveur est basé sur le cloud, Diskobot appelle l'API cloud, dit qu'il va fonctionner avec ce serviteur - le serveur exécutant les conteneurs - et demande "migrer tous les conteneurs de ce serviteur". Et en même temps, il allume le rétroéclairage du disque afin que l'ingénieur puisse voir immédiatement lequel doit être retiré.

changé.yml

Après avoir remplacé un disque, nous vérifions d'abord sa disponibilité.

Les ingénieurs n'installent pas toujours de nouveaux disques, nous avons donc ajouté une vérification des valeurs SMART qui nous satisfont.

Quels attributs recherchons-nous ?Nombre de secteurs réaffectés (5) < 100
Nombre actuel de secteurs en attente (107) == 0

Si le disque échoue au test, l'ingénieur est invité à le remplacer à nouveau. Si tout est en ordre, le rétroéclairage s'éteint, des marquages sont appliqués et le disque est mis en rotation.

prêt.yml

Le cas le plus simple : vérifier la synchronisation du raid matériel/logiciel ou terminer la synchronisation des données dans l'application.

API d'applications

J'ai mentionné à plusieurs reprises que le bot accède souvent aux API des applications. Bien entendu, toutes les applications ne disposaient pas des méthodes nécessaires, elles ont donc dû être modifiées. Voici les méthodes les plus importantes que nous utilisons :

Statut. État d'un cluster ou d'un disque pour comprendre s'il peut être utilisé ;
Commencer arrêter. Activation/désactivation du disque ;
Migrer/restaurer. Migration et récupération des données pendant et après le remplacement.

Leçons tirées d’Ansible

J'aime vraiment Ansible. Mais souvent, quand je regarde différents projets open source et que je vois comment les gens écrivent des playbooks, j'ai un peu peur. Entrelacements logiques complexes de when/loop, manque de flexibilité et idempotence dus à l'utilisation fréquente de shell/commande.

Nous avons décidé de tout simplifier autant que possible, en profitant de l'avantage d'Ansible : la modularité. Au plus haut niveau, il existe des playbooks ; ils peuvent être écrits par n'importe quel administrateur, développeur tiers connaissant un peu Ansible.

- name: Blink disk
  become: True
  register: locate_action
  disk_locate:
      locate: '{{ locate }}'
      devname: '{{ devname }}'
      ids: '{{ locate_ids | default(pd_id) | default(omit) }}'

Si une logique est difficile à implémenter dans les playbooks, nous la déplaçons dans un module ou un filtre Ansible. Les scripts peuvent être écrits en Python ou dans tout autre langage.

Ils sont faciles et rapides à écrire. Par exemple, le module de rétroéclairage du disque, dont un exemple est présenté ci-dessus, comprend 265 lignes.

Au niveau le plus bas se trouve la bibliothèque. Pour ce projet, nous avons écrit une application distincte, une sorte d'abstraction sur les RAID matériels et logiciels qui effectuent les requêtes correspondantes.

Les plus grandes forces d'Ansible sont sa simplicité et ses playbooks clairs. Je pense que vous devez l'utiliser et ne pas générer de fichiers yaml effrayants et un grand nombre de conditions, de code shell et de boucles.

Si vous souhaitez répéter notre expérience avec l'API Ansible, gardez deux choses à l'esprit :

Playbook_executor et les playbooks en général ne peuvent pas bénéficier d'un délai d'attente. Il y a un délai d'attente sur la session ssh, mais il n'y a pas de délai d'attente sur le playbook. Si nous essayons de démonter un disque qui n'existe plus dans le système, le playbook s'exécutera sans fin, nous avons donc dû envelopper son lancement dans un wrapper séparé et le tuer avec un délai d'attente.
Ansible s'exécute sur des processus forkés, son API n'est donc pas thread-safe. Nous exécutons tous nos playbooks avec un seul thread.

Nous avons ainsi pu automatiser le remplacement d'environ 80 % des disques. Globalement, le taux de remplacement a doublé. Aujourd'hui, l'administrateur se contente d'examiner l'incident et décide si le disque doit être changé ou non, puis effectue un clic.

Mais maintenant, nous commençons à rencontrer un autre problème : certains nouveaux administrateurs ne savent pas comment changer de lecteur. 🙂

Source: habr.com

Automatisation du remplacement de disque avec Ansible