{"id":34841,"date":"2019-10-31T22:00:43","date_gmt":"2019-10-31T19:00:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible\/"},"modified":"2019-10-31T22:00:43","modified_gmt":"2019-10-31T19:00:43","slug":"avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible","title":{"rendered":"Automatisation du remplacement des disques avec Ansible","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Automatisation
\n
\nBonjour \u00e0 tous. Je suis administrateur syst\u00e8me senior chez OK et je suis responsable du bon fonctionnement du portail. Je souhaite expliquer comment nous avons mis en place un processus de remplacement automatique des disques, puis comment nous avons \u00e9limin\u00e9 l'intervention de l'administrateur de ce processus en le rempla\u00e7ant par un bot.<\/p>\n

Cet article est une sorte de translit\u00e9ration de la pr\u00e9sentation<\/a><\/noindex> \u00e0 HighLoad+ 2018
\n<\/a><\/noindex><\/p>\n

Mise en place du processus de remplacement des disques<\/h2>\n

<\/p>\n

D'abord, quelques chiffres<\/h3>\n

\nOK est un service g\u00e9ant utilis\u00e9 par des millions de personnes. Il est g\u00e9r\u00e9 par environ 7000 serveurs situ\u00e9s dans 4 centres de donn\u00e9es diff\u00e9rents. Les serveurs contiennent plus de 70 000 disques. Si on les empile, on obtient une tour de plus d'un kilom\u00e8tre de haut. <\/p>\n

Les disques durs sont le composant du serveur qui tombe le plus souvent en panne. \u00c0 ce niveau, nous devons remplacer environ 30 disques par semaine, et cette proc\u00e9dure est devenue une routine assez d\u00e9sagr\u00e9able.<\/p>\n

\"Automatisation
\n<\/p>\n

Incidents<\/h3>\n

\nDans notre entreprise, un syst\u00e8me complet de gestion des incidents a \u00e9t\u00e9 mis en place. Chaque incident est enregistr\u00e9 dans Jira, puis r\u00e9solu et analys\u00e9. Si un incident a eu un impact sur les utilisateurs, nous nous r\u00e9unissons forc\u00e9ment pour r\u00e9fl\u00e9chir \u00e0 la mani\u00e8re de r\u00e9agir plus rapidement dans de tels cas, de minimiser l'impact et bien s\u00fbr de pr\u00e9venir toute r\u00e9currence.<\/p>\n

Les unit\u00e9s de stockage ne font pas exception. Leur \u00e9tat est surveill\u00e9 par Zabbix. Nous surveillons les messages dans Syslog pour d\u00e9tecter les erreurs d'\u00e9criture\/lecture, analysons l'\u00e9tat des RAID HW\/SW, et surveillons les informations SMART, en calculant l'usure pour les SSD. <\/p>\n

Comment les disques \u00e9taient remplac\u00e9s auparavant<\/h3>\n

\nLorsque Zabbix d\u00e9clenche un certain avertissement, un incident est cr\u00e9\u00e9 dans Jira et attribu\u00e9 automatiquement aux ing\u00e9nieurs concern\u00e9s dans les centres de donn\u00e9es. Nous faisons cela pour tous les incidents mat\u00e9riels, c'est-\u00e0-dire ceux qui n\u00e9cessitent un travail physique sur l'\u00e9quipement dans le centre de donn\u00e9es.
\nL'ing\u00e9nieur du centre de donn\u00e9es est la personne qui s'occupe des probl\u00e8mes li\u00e9s au mat\u00e9riel, responsable de l'installation, de la maintenance et du d\u00e9montage des serveurs. D\u00e8s qu'il re\u00e7oit un ticket, l'ing\u00e9nieur commence \u00e0 travailler. Dans les baies de disques, il remplace les disques lui-m\u00eame. Mais s'il n'a pas acc\u00e8s \u00e0 l'appareil n\u00e9cessaire, l'ing\u00e9nieur demande de l'aide aux administrateurs syst\u00e8mes de garde. Dans un premier temps, il faut retirer le disque de la rotation. Pour cela, des modifications doivent \u00eatre apport\u00e9es au serveur, arr\u00eater les applications et d\u00e9monter le disque.<\/p>\n

L'administrateur syst\u00e8me de garde est responsable du bon fonctionnement de l'ensemble du portail pendant son service. Il enqu\u00eate sur les incidents, effectue des r\u00e9parations et aide les d\u00e9veloppeurs \u00e0 accomplir de petites t\u00e2ches. Il ne s'occupe pas uniquement des disques durs.<\/p>\n

Auparavant, les ing\u00e9nieurs des centres de donn\u00e9es communiquaient avec l'administrateur syst\u00e8me via un chat. Les ing\u00e9nieurs envoyaient des liens vers des tickets Jira, l'administrateur les consultait et tenait un journal des travaux dans un bloc-notes. Mais pour ce genre de t\u00e2ches, les chats sont peu pratiques : l'information y est non structur\u00e9e et se perd rapidement. De plus, l'administrateur pouvait simplement s'\u00e9loigner de l'ordinateur et ne pas r\u00e9pondre aux demandes pendant un certain temps, tandis que l'ing\u00e9nieur se tenait devant le serveur avec une pile de disques en attendant.<\/p>\n

Mais le pire, c'est que les administrateurs ne voyaient pas l'ensemble de la situation : quels incidents de disque existaient, o\u00f9 des probl\u00e8mes pourraient potentiellement survenir. Cela s'explique par le fait que nous confions tous les incidents HW aux ing\u00e9nieurs. Oui, il \u00e9tait possible d'afficher tous les incidents sur le tableau de bord de l'administrateur. Mais il y en avait tellement, et l'administrateur n'\u00e9tait impliqu\u00e9 que pour certains d'entre eux.<\/p>\n

De plus, l'ing\u00e9nieur ne pouvait pas correctement \u00e9tablir des priorit\u00e9s, car il ne savait rien sur la destination pr\u00e9cise des serveurs, ni sur la r\u00e9partition des informations sur les supports.<\/p>\n

Nouvelle proc\u00e9dure de remplacement<\/h3>\n

\nLa premi\u00e8re chose que nous avons faite, c'est de cr\u00e9er un nouveau type d'incident pour les disques, \u00ab HW-disk \u00bb, et d'y ajouter des champs \u00ab nom du p\u00e9riph\u00e9rique de bloc \u00bb, \u00ab taille \u00bb et \u00ab type de disque \u00bb, afin que cette information soit conserv\u00e9e dans le ticket et que nous n'ayons pas \u00e0 l'\u00e9changer constamment dans le chat. <\/p>\n

\"Automatisation
\nNous avons \u00e9galement convenu que dans le cadre d'un seul incident, nous ne remplacerions qu'un seul disque. Cela a consid\u00e9rablement simplifi\u00e9 le processus d'automatisation, la collecte de statistiques et le travail par la suite. <\/p>\n

En plus de cela, nous avons ajout\u00e9 un champ \u00ab administrateur responsable \u00bb. L'administrateur de garde y est automatiquement d\u00e9sign\u00e9. C'est tr\u00e8s pratique, car l'ing\u00e9nieur voit toujours qui est responsable. Il n'est pas n\u00e9cessaire d'aller dans le calendrier pour chercher. C'est ce champ qui a permis de mettre en avant sur le tableau de bord de l'administrateur les tickets pour lesquels son aide pourrait \u00eatre n\u00e9cessaire.<\/p>\n

\"Automatisation
\nPour que tous les participants tirent le maximum de b\u00e9n\u00e9fices des innovations, nous avons cr\u00e9\u00e9 des filtres et des tableaux de bord, et en avons parl\u00e9 aux \u00e9quipes. Lorsque les gens comprennent les changements, ils ne s'en \u00e9loignent pas comme d'une chose inutile. Il est important pour l'ing\u00e9nieur de conna\u00eetre le num\u00e9ro de rack o\u00f9 se trouve le serveur, la taille et le type de disque. L'administrateur doit, avant tout, comprendre ce qu'est ce groupe de serveurs et quel pourrait \u00eatre l'effet d'un remplacement de disque.<\/p>\n

Avoir des champs et leur affichage est pratique, mais cela ne nous a pas lib\u00e9r\u00e9s de la n\u00e9cessit\u00e9 d'utiliser des chats. Nous avons d\u00fb changer le flux de travail pour cela. <\/p>\n

Auparavant, il \u00e9tait comme \u00e7a :<\/p>\n

\"Automatisation
\nAujourd'hui, c'est ainsi que continuent de travailler les ing\u00e9nieurs lorsqu'ils n'ont pas besoin de l'aide de l'administrateur.<\/p>\n

La premi\u00e8re chose que nous avons faite est d'avoir introduit un nouveau statut Investigate<\/b>. Ce statut est celui dans lequel le ticket est situ\u00e9 lorsque l'ing\u00e9nieur n'a pas encore d\u00e9cid\u00e9 s'il aura besoin d'un administrateur ou non. \u00c0 travers ce statut, l'ing\u00e9nieur peut transmettre le ticket \u00e0 l'administrateur. De plus, nous marquons les tickets dans ce statut lorsque le remplacement du disque est n\u00e9cessaire, mais que le disque lui-m\u00eame n'est pas disponible sur le site. Cela peut se produire dans le cas de CDN et de sites distants.<\/p>\n

Nous avons \u00e9galement ajout\u00e9 le statut Pr\u00eat<\/b>. Le ticket passe \u00e0 ce statut apr\u00e8s le remplacement du disque. Cela signifie que tout est d\u00e9j\u00e0 fait, mais le HW\/SW RAID sur le serveur est en cours de synchronisation. Cela peut prendre assez de temps.<\/p>\n

Si un administrateur est impliqu\u00e9 dans le travail, le sch\u00e9ma devient un peu plus compliqu\u00e9.<\/p>\n

\"Automatisation
\n\u00c0 partir du statut Ouvrir<\/b> , le ticket peut \u00eatre transf\u00e9r\u00e9 \u00e0 la fois par l'administrateur syst\u00e8me et par l'ing\u00e9nieur. Dans le statut In progress<\/b> , l'administrateur retire le disque de la rotation pour que l'ing\u00e9nieur puisse simplement le retirer : il active le voyant, d\u00e9monte le disque, arr\u00eate les applications, en fonction du groupe de serveurs sp\u00e9cifique.<\/p>\n

Ensuite, le ticket est transf\u00e9r\u00e9 \u00e0 Ready to change<\/b>: c'est un signal pour l'ing\u00e9nieur qu'il peut retirer le disque. Tous les champs dans Jira sont d\u00e9j\u00e0 remplis, l'ing\u00e9nieur sait quel type et quelle taille de disque sont n\u00e9cessaires. Ces donn\u00e9es sont renseign\u00e9es soit automatiquement dans le statut pr\u00e9c\u00e9dent, soit par l'administrateur.<\/p>\n

Apr\u00e8s le remplacement du disque, le ticket est transf\u00e9r\u00e9 au statut Changed<\/b>. On v\u00e9rifie que le disque appropri\u00e9 a \u00e9t\u00e9 ins\u00e9r\u00e9, une sch\u00e9matisation est effectu\u00e9e, l'application est lanc\u00e9e et certaines t\u00e2ches de r\u00e9cup\u00e9ration de donn\u00e9es sont r\u00e9alis\u00e9es. Le ticket peut \u00e9galement \u00eatre transf\u00e9r\u00e9 au statut Pr\u00eat<\/b>, dans ce cas, l'administrateur reste responsable, car c'est lui qui a mis le disque dans la rotation. Le sch\u00e9ma complet ressemble \u00e0 cela.<\/p>\n

\"Automatisation
\nL'ajout de nouveaux champs a consid\u00e9rablement simplifi\u00e9 notre travail. Les \u00e9quipes commencent \u00e0 travailler avec des informations structur\u00e9es, il est devenu clair ce qui doit \u00eatre fait et \u00e0 quelle \u00e9tape. Les priorit\u00e9s sont devenues beaucoup plus pertinentes, car maintenant elles sont d\u00e9finies par l'administrateur.<\/p>\n

Nous n'avons plus besoin de discuter dans les chats. Bien s\u00fbr, l'administrateur peut envoyer un message \u00e0 l'ing\u00e9nieur en disant \"il faut remplacer plus rapidement ici\", ou \"c'est d\u00e9j\u00e0 le soir, vas-tu pouvoir remplacer ?\". Mais nous ne discutons plus quotidiennement dans les chats \u00e0 ce sujet.<\/p>\n

Les disques sont d\u00e9sormais remplac\u00e9s par lots. Si l'administrateur arrive un peu plus t\u00f4t au travail et qu'il a du temps libre, et qu'aucun incident ne s'est produit, il peut pr\u00e9parer plusieurs serveurs pour le remplacement : marquer les champs, retirer les disques de la rotation et passer la t\u00e2che \u00e0 l'ing\u00e9nieur. Plus tard, l'ing\u00e9nieur arrive au centre de donn\u00e9es, voit la t\u00e2che, prend les disques n\u00e9cessaires dans le stock et les remplace imm\u00e9diatement. En cons\u00e9quence, la vitesse de remplacement a augment\u00e9.<\/p>\n

L'exp\u00e9rience acquise lors de la construction du Workflow<\/h3>\n

<\/p>\n