Automatisierung des Austauschs von Festplatten mit Ansible

Hallo zusammen. Ich arbeite als leitender Systemadministrator bei OK und bin für den stabilen Betrieb des Portals verantwortlich. Ich möchte erzählen, wie wir den Prozess der automatischen Festplattentauschs aufgebaut haben und anschließend, wie wir den Administrator aus diesem Prozess ausgeschlossen und ihn durch einen Bot ersetzt haben.

Dieser Artikel ist eine Art Transliterierung Vortrags bei HighLoad+ 2018

Aufbau des Prozesses zum Austausch von Festplatten

Zunächst einige Zahlen

OK ist ein riesiger Dienst, der von Millionen Menschen genutzt wird. Er wird von etwa 7.000 Servern unterstützt, die in 4 verschiedenen Rechenzentren verteilt sind. In den Servern befinden sich über 70.000 Festplatten. Wenn man sie übereinander stapelt, ergibt sich ein Turm von mehr als 1 km Höhe.

Festplatten sind der Bestandteil eines Servers, der am häufigsten ausfällt. Bei solch einem Volumen müssen wir etwa 30 Festplatten pro Woche austauschen, und dieser Vorgang ist zu einer unangenehmen Routine geworden.

Vorfälle

In unserem Unternehmen haben wir ein vollständiges Incident-Management eingeführt. Jeden Vorfall dokumentieren wir in Jira und lösen ihn dann. Wenn ein Vorfall Auswirkungen auf die Nutzer hatte, kommen wir auf jeden Fall zusammen und überlegen, wie wir schneller auf solche Fälle reagieren können, wie wir die Auswirkungen minimieren und natürlich, wie wir Wiederholungen verhindern können.

Speichermedien sind da keine Ausnahme. Ihr Zustand wird von Zabbix überwacht. Wir überprüfen die Syslog-Nachrichten auf Schreib-/Lesefehler, analysieren den Zustand von HW/SW-RAIDs und überwachen SMART. Bei SSDs berechnen wir den Verschleiß.

Wie die Festplatten früher ausgetauscht wurden

Wenn in Zabbix ein Trigger aktiviert wird, wird in Jira ein Vorfall erstellt und automatisch den entsprechenden Ingenieuren in den Rechenzentren zugewiesen. So verfahren wir mit allen HW-Vorfällen, also solchen, die irgendeine physische Arbeit mit der Hardware im Rechenzentrum erfordern.
Der Ingenieur im Rechenzentrum ist die Person, die sich mit Fragen rund um die Hardware beschäftigt, verantwortlich für die Installation, Wartung und Demontage der Server ist. Hat er ein Ticket erhalten, beginnt der Ingenieur mit der Arbeit. In den Festplattenschächten wechselt er die Festplatten selbstständig. Hat er jedoch keinen Zugang zum benötigten Gerät, wendet sich der Ingenieur an die diensthabenden Systemadministratoren um Hilfe. Zunächst muss die Festplatte aus der Rotation genommen werden. Dazu sind die notwendigen Änderungen am Server vorzunehmen, die Anwendungen zu stoppen und die Festplatte auszuhängen.

Der diensthabende Systemadministrator ist während der Arbeitsschicht für den gesamten Betrieb des Portals verantwortlich. Er untersucht Vorfälle, führt Reparaturen durch und unterstützt Entwickler bei kleinen Aufgaben. Lediglich um Festplatten kümmert er sich nicht.

Früher kommunizierten die Ingenieure der Rechenzentren im Chat mit dem Systemadministrator. Die Ingenieure schickten Links zu Jira-Tickets, der Administrator ging sie durch und führte ein Protokoll der Arbeiten in einem Notizbuch. Aber für solche Aufgaben sind Chats unpraktisch: Die Informationen sind dort unstrukturiert und gehen schnell verloren. Außerdem konnte der Administrator einfach vom Computer weggehen und eine Zeit lang keine Anfragen beantworten, während der Ingenieur am Server mit einer Stapel Festplatten wartete.

Das Schlimmste war jedoch, dass die Administratoren das Gesamtbild nicht sahen: welche Festplattenvorfälle es gibt und wo potenziell Probleme entstehen können. Das liegt daran, dass wir alle HW-Vorfälle den Ingenieuren übergeben. Ja, man hätte alle Vorfälle im Dashboard des Administrators anzeigen können. Aber es sind zu viele, und der Administrator wurde nur für einige von ihnen eingebunden.

Darüber hinaus konnte der Ingenieur die Prioritäten nicht richtig festlegen, da er nichts über die spezifische Nutzung der Server oder die Verteilung der Daten auf den Speichern wusste.

Neues Austauschverfahren

Das Erste, was wir gemacht haben, war, alle Festplatten-Vorfälle in einen separaten Typ „HW-Disk“ zu überführen und ihm die Felder „Name des Blockgeräts“, „Größe“ und „Festplattentyp“ hinzuzufügen, damit diese Informationen im Ticket gespeichert werden und nicht ständig im Chat ausgetauscht werden müssen.

Außerdem haben wir vereinbart, dass wir im Rahmen eines Vorfalls nur eine Festplatte austauschen. Das hat den Prozess der Automatisierung, der Statistiksammlung und der Arbeit erheblich vereinfacht.

Zusätzlich haben wir ein Feld „verantwortlicher Administrator“ hinzugefügt. Dort wird automatisch der diensthabende Sysadmin eingetragen. Das ist sehr praktisch, denn jetzt sieht der Ingenieur immer, wer verantwortlich ist. Es ist nicht nötig, im Kalender nachzusehen. Genau dieses Feld hat es ermöglicht, die Tickets in das Dashboard des Administrators zu bringen, für die möglicherweise seine Hilfe benötigt wird.

Um sicherzustellen, dass alle Teilnehmer maximal von den Neuerungen profitieren, haben wir Filter und Dashboards erstellt und den Leuten darüber erzählt. Wenn die Menschen die Veränderungen verstehen, distanzieren sie sich nicht von ihnen, als wäre es etwas Überflüssiges. Für den Ingenieur ist es wichtig, die Racknummer zu kennen, in der sich der Server befindet, sowie die Größe und den Typ der Festplatte. Der Administrator muss in erster Linie verstehen, um welche Gruppe von Servern es sich handelt und welchen Effekt der Austausch der Festplatte haben könnte.

Das Vorhandensein von Feldern und deren Anzeige ist zwar praktisch, hat uns jedoch nicht von der Notwendigkeit befreit, Chats zu nutzen. Dazu mussten wir den Arbeitsprozess ändern.

Früher war er so:

Heute arbeiten Ingenieure weiterhin so, wenn sie keine Hilfe vom Administrator benötigen.

Das erste, was wir gemacht haben, ist die Einführung eines neuen Status Investigate. In diesem Status befindet sich das Ticket, wenn der Ingenieur noch nicht entschieden hat, ob er einen Administrator benötigt oder nicht. Über diesen Status kann der Ingenieur das Ticket an den Administrator weitergeben. Außerdem kennzeichnen wir mit diesem Status Tickets, wenn eine Festplatte ersetzt werden muss, aber die Festplatte vor Ort nicht vorhanden ist. Das kommt bei CDN und Remote-Standorten vor.

Außerdem haben wir den Status Bereithinzugefügt. In diesen Status wird das Ticket nach dem Austausch der Festplatte versetzt. Das heißt, alles ist bereits erledigt, aber auf dem Server wird HW/SW RAID synchronisiert. Das kann ziemlich viel Zeit in Anspruch nehmen.

Wenn ein Administrator in die Arbeit einbezogen wird, wird das Schema etwas komplizierter.

Das Ticket kann sowohl vom Systemadministrator als auch vom Ingenieur aus dem Status Offen übertragen werden. Im Status In progress nimmt der Administrator die Festplatte aus dem Betrieb, sodass der Ingenieur sie einfach herausziehen kann: Er aktiviert das Licht, demontiert die Festplatte, stoppt die Anwendungen, je nach der konkreten Gruppe von Servern.

Dann wird das Ticket in den Status Ready to change: das ist das Signal an den Ingenieur, dass die Festplatte herausgenommen werden kann. Alle Felder in Jira sind bereits ausgefüllt, der Ingenieur weiß, welcher Typ und welche Größe die Festplatte hat. Diese Daten werden entweder im vorherigen Status automatisch oder durch den Administrator eingetragen.

Nach dem Austausch der Festplatte wird das Ticket in den Status Changed. Es wird überprüft, dass die richtige Festplatte eingelegt wurde, eine Partitionierung erfolgt, die Anwendung wird gestartet und einige Datenwiederherstellungsaufgaben durchgeführt. Das Ticket kann auch in den Status Bereitübertragen werden, in diesem Fall bleibt der Administrator verantwortlich, da er die Festplatte in Umlauf gebracht hat. Das gesamte Schema sieht so aus.

Die Hinzufügung neuer Felder hat unser Leben erheblich erleichtert. Die Mitarbeiter arbeiten nun mit strukturierten Informationen, es ist klar, was und in welchem Schritt zu tun ist. Die Prioritäten sind deutlich relevanter geworden, da sie jetzt vom Administrator festgelegt werden.

Die Notwendigkeit von Chats entfiel. Natürlich kann der Administrator dem Ingenieur schreiben: „Hier muss schneller ersetzt werden“ oder „Es ist schon Abend, schaffst du es noch zu ersetzen?“. Aber wir kommunizieren nicht mehr täglich in Chats über diese Fragen.

Festplatten werden nun in großen Mengen ausgetauscht. Wenn der Administrator etwas früher zur Arbeit kommt, hat er Zeit und es ist noch nichts passiert, kann er mehrere Server für den Austausch vorbereiten: Felder festlegen, Festplatten aus der Rotation nehmen und die Aufgabe an den Ingenieur übergeben. Der Ingenieur kommt etwas später ins Rechenzentrum, sieht die Aufgabe, nimmt die benötigten Speichermedien aus dem Lager und wechselt sie sofort aus. Dadurch hat sich die Austauschgeschwindigkeit erhöht.

Erfahrungen aus dem Workflow-Aufbau

• Beim Aufbau der Prozedur müssen Informationen aus verschiedenen Quellen gesammelt werden.
  Einige unserer Administratoren wussten nicht, dass Ingenieure die Festplatten eigenständig wechseln. Einige dachten, dass die Ingenieure die MD-RAID-Synchronisation überwachen, obwohl einige von ihnen nicht einmal Zugang dazu hatten. Einige leitende Ingenieure erledigten dies, jedoch nicht immer, da der Prozess nirgendwo dokumentiert war.
• Die Prozedur sollte einfach und verständlich sein.
  Es ist für Menschen schwierig, sich viele Schritte zu merken. Die wichtigsten angrenzenden Status in Jira sollten auf dem Hauptbildschirm angezeigt werden. Man kann sie umbenennen, zum Beispiel nennen wir 'In progress' 'Bereit zum Wechseln'. Die anderen Status können im Dropdown-Menü versteckt werden, damit sie nicht stören. Es ist jedoch besser, die Menschen nicht einzuschränken, sondern ihnen die Möglichkeit zu geben, den Übergang zu machen.
  Erklärt den Wert der Neuerungen. Wenn die Menschen verstehen, nehmen sie die neue Prozedur besser an. Für uns war es sehr wichtig, dass die Menschen den gesamten Prozess nicht einfach durchklicken, sondern ihm folgen. Danach haben wir darauf die Automatisierung aufgebaut.
• Warten, analysieren, verstehen.
  Wir haben ungefähr einen Monat benötigt, um das Verfahren, die technische Umsetzung, die Meetings und die Diskussionen zu erstellen. Die Implementierung dauerte mehr als drei Monate. Ich habe gesehen, wie die Leute allmählich mit der Neuerung zu arbeiten begannen. In den ersten Phasen gab es viel Negatives. Aber das hing überhaupt nicht vom Verfahren oder der technischen Umsetzung ab. Zum Beispiel benutzte ein Administrator nicht Jira, sondern ein Jira-Plugin in Confluence, und einige Funktionen waren für ihn nicht verfügbar. Als wir ihm Jira zeigten, stieg seine Produktivität sowohl bei den allgemeinen Aufgaben als auch bei den Festplattentauschvorgängen.

Automatisierung des Festplattentausches

Wir haben uns mehrmals der Automatisierung des Festplattentausches genähert. Wir hatten bereits einige Entwicklungen und Skripte, aber alle funktionierten entweder interaktiv oder manuell und erforderten einen Start. Erst nach der Implementierung des neuen Verfahrens haben wir verstanden, dass wir genau das fehlten.

Da der Prozess des Festplattentausches nun in Etappen unterteilt ist, für die jeweils ein Verantwortlicher und eine Liste von Aktionen festgelegt sind, können wir die Automatisierung schrittweise aktivieren, und nicht auf einmal. Zum Beispiel kann die einfachste Phase - Ready (Überprüfung der RAID-/Daten-Synchronisation) - leicht an einen Bot delegiert werden. Wenn der Bot ein wenig trainiert ist, kann man ihm eine verantwortungsvollere Aufgabe geben - die Einführung der Festplatte in die Rotation usw.

Der Zoo der Setups

Bevor ich von dem Bot erzähle, machen wir einen kurzen Ausflug in unseren Zoo der Installationen. Zunächst ist dies auf die riesige Größe unserer Infrastruktur zurückzuführen. Zweitens versuchen wir, für jeden Dienst die optimale Hardwarekonfiguration auszuwählen. Wir haben etwa 20 Modelle von Hardware-RAID, hauptsächlich von LSI und Adaptec, aber auch HP und DELL in verschiedenen Versionen. Jeder RAID-Controller hat sein eigenes Verwaltungstool. Die Befehle und die Ausgabe können von Version zu Version bei jedem RAID-Controller unterschiedlich sein. Wo kein HW-RAID verwendet wird, kann mdraid zum Einsatz kommen.

Fast alle neuen Installationen führen wir ohne Festplattenspiegelung durch. Wir versuchen, keine Hardware- und Software-RAID mehr zu verwenden, da wir unsere Systeme auf Data-Center-Ebene und nicht auf Server-Ebene reservieren. Aber natürlich gibt es viele Legacy-Server, die gewartet werden müssen.

Irgendwo werden in RAID-Controllern Raw-Geräte durchgeschleift, irgendwo werden JBODs verwendet. Es gibt Konfigurationen mit einer einzigen Systemplatte im Server, und wenn diese ersetzt werden muss, muss der Server mit der Installation von OS und Anwendungen, einschließlich der gleichen Versionen, neu aufgesetzt werden, gefolgt von dem Hinzufügen von Konfigurationsdateien und dem Starten von Anwendungen. Es gibt auch viele Gruppen von Servern, bei denen die Redundanz nicht auf der Ebene des Speichersystems, sondern direkt in den Anwendungen implementiert ist.

Insgesamt haben wir mehr als 400 einzigartige Gruppen von Servern, auf denen etwa 100 verschiedene Anwendungen laufen. Um eine so enorme Anzahl von Varianten abzudecken, benötigten wir ein vielseitiges Automatisierungstool. Vorzugsweise mit einer einfachen DSL, damit nicht nur derjenige, der es geschrieben hat, es unterstützen kann.

Wir haben uns für Ansible entschieden, weil es agentenlos ist: Es war nicht notwendig, die Infrastruktur vorzubereiten, ein schneller Start. Außerdem ist es in Python geschrieben, was im Team als Standard akzeptiert ist.

Das allgemeine Schema

Lassen Sie uns das allgemeine Automatisierungsschema am Beispiel eines Vorfalls betrachten. Zabbix erkennt, dass die Festplatte sdb ausgefallen ist, ein Trigger wird aktiviert und ein Ticket in Jira erstellt. Der Administrator sieht sich das Ticket an, erkennt, dass es kein Duplikat und kein false positive ist, das heißt, die Festplatte muss gewechselt werden, und verschiebt das Ticket in den Status "In Bearbeitung".

Die Anwendung DiskoBot, die in Python geschrieben ist, fragt regelmäßig Jira nach neuen Tickets. Sie bemerkt, dass ein neues Ticket im Status In Bearbeitung erscheint, ein entsprechender Thread wird aktiviert, der das Playbook in Ansible startet (das geschieht für jeden Status in Jira). In diesem Fall wird Prepare2change gestartet.

Ansible wird auf den Host gesendet, entfernt die Festplatte aus der Rotation und berichtet den Status der Anwendung über Callbacks.

Nach den Ergebnissen übersetzt der Bot das Ticket automatisch in den Status "Bereit zum Wechseln". Der Ingenieur erhält eine Benachrichtigung und macht sich an den Wechsel der Festplatte, wonach er das Ticket in den Status "Gewechselt" verschiebt.

Nach dem oben beschriebenen Schema gelangt das Ticket zurück zum Bot, dieser startet ein anderes Playbook, geht zum Host und führt die Festplatte wieder in die Rotation ein. Der Bot schließt das Ticket. Hurra!

Jetzt sprechen wir über einige Komponenten des Systems.

Diskobot

Diese Anwendung ist in Python geschrieben. Sie wählt Tickets aus Jira gemäß JQL aus. Je nach Status des Tickets gelangt es zu dem entsprechenden Handler, der seinerseits das passende Ansible Playbook startet.

JQL und Umfrageintervalle sind in der Konfigurationsdatei der Anwendung definiert.

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

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

Zum Beispiel, unter den Tickets im Status In progress werden nur die ausgewählt, bei denen die Felder Disk size und Device name ausgefüllt sind. Device name ist der Name des Blockgeräts, das für die Ausführung des Playbooks benötigt wird. Disk size ist wichtig, damit der Ingenieur weiß, welche Größe die Festplatte haben muss.

Unter den Tickets im Status Ready werden die Tickets mit dem Label dbot_ignore gefiltert. Übrigens verwenden wir Jira-Labels sowohl für eine solche Filterung als auch zur Kennzeichnung von Duplikaten und zur Sammlung von Statistiken.

Im Falle eines Fehlers im Playbook weist Jira das Label dbot_failed zu, um später eine Analyse zu ermöglichen.

Interaktion mit Ansible

Die Anwendung interagiert mit Ansible über Ansible Python API. Im playbook_executor übergeben wir den Dateinamen und eine Gruppe von Variablen. Dies ermöglicht es, das Ansible-Projekt in Form von normalen yml-Dateien zu halten, anstatt es in Python-Code zu beschreiben.

Zudem werden in Ansible über *extra_vars* der Name des Blockgeräts, der Status des Tickets sowie die callback_url übergeben, in der der Issue-Schlüssel eingebettet ist – dieser wird für den Callback in HTTP verwendet.

Für jeden Lauf wird ein temporäres Inventory generiert, das aus einem Host und einer Gruppe besteht, zu der dieser Host gehört, damit die group_vars angewendet werden können.

Hier ist ein Beispiel für eine Aufgabe, in der der HTTP-Callback implementiert ist.

Die Ergebnisse der Ausführung der Playbooks erhalten wir durch Callbacks. Es gibt zwei Typen:

• Ansible Callback-Plugin, es liefert Daten zu den Ergebnissen der Ausführung des Playbooks. Dort sind die Aufgaben beschrieben, die gestartet wurden, erfolgreich oder erfolglos ausgeführt wurden. Dieses Callback wird am Ende des Playbook-Spielens aufgerufen.
• HTTP-Callback zur Informationsabfrage während des Spielens des Playbooks. Im Ansible-Task führen wir eine POST/GET-Anfrage an unsere Anwendung durch.

Über HTTP-Callbacks werden die Variablen übermittelt, die bei der Ausführung des Playbooks definiert wurden und die wir speichern und in zukünftigen Läufen verwenden möchten. Diese Daten schreiben wir in SQLite.

Außerdem hinterlassen wir über HTTP-Callbacks Kommentare und ändern den Status des Tickets.

HTTP-Callback

# 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

Wie viele ähnliche Aufgaben haben wir es in eine separate gemeinsame Datei ausgegliedert und fügen es bei Bedarf hinzu, um nicht ständig im Playbooks zu wiederholen. Hier spielt die callback_url eine Rolle, in der der Issue-Key und der Hostname eingebettet sind. Wenn Ansible diese POST-Anfrage ausführt, versteht der Bot, dass sie im Rahmen eines bestimmten Vorfalls eingegangen ist.

Hier ist ein Beispiel aus dem Playbook, in dem wir die Festplatte aus dem MD-Gerät ausgegeben haben:

  # 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

Diese Aufgabe versetzt das Jira-Ticket in den Status „Bereit zum Ändern“ und fügt einen Kommentar hinzu. In der Variablen mdam_data wird auch die Liste der md-Geräte gespeichert, aus denen die Festplatte entfernt wurde, und in parted_info wird ein Dump der Partition von parted gespeichert.

Wenn der Ingenieur die neue Festplatte einsetzt, können wir diese Variablen verwenden, um den Dump der Partitionen wiederherzustellen und die Festplatte in die md-Geräte einzuführen, aus denen sie entfernt wurde.

Ansible-Prüfmodus

Es war beängstigend, die Automatisierung zu aktivieren. Daher haben wir beschlossen, alle Playbooks im
Trockentest, in dem Ansible keine Aktionen auf den Servern ausführt, sondern sie nur emuliert.

Dieser Start wird über ein separates Callback-Modul durchgeführt, und das Ergebnis der Ausführung des Playbooks wird in Jira als Kommentar gespeichert.

Erstens ermöglichte es die Validierung der Arbeit des Bots und der Playbooks. Zweitens erhöhte es das Vertrauen der Administratoren in den Bot.

Als wir die Validierung abgeschlossen hatten und verstanden, dass wir Ansible nicht nur im Trockentestmodus ausführen können, haben wir in Jira die Schaltfläche Run Diskobot für die Ausführung des gleichen Playbooks mit den gleichen Variablen auf demselben Host im regulären Modus erstellt.

Darüber hinaus wird die Schaltfläche verwendet, um das Playbook im Fall eines Fehlers erneut auszuführen.

Struktur der Playbooks

Ich habe bereits erwähnt, dass der Bot je nach Status des Jira-Tickets verschiedene Playbooks ausführt.

Erstens ist es so viel einfacher, den Zugang zu organisieren.
Zweitens ist es in einigen Fällen einfach notwendig.

Zum Beispiel muss man bei der Ersetzung der Systemfestplatte zuerst ins Bereitstellungssystem gehen, eine Aufgabe erstellen, und nach der korrekten Bereitstellung wird der Server über SSH verfügbar, und man kann die Anwendung aufspielen. Wenn wir all dies in einem Playbook gemacht hätten, hätte Ansible es aufgrund der Nichterreichbarkeit des Hosts nicht ausführen können.

Wir verwenden Ansible-Rollen für jede Servergruppe. Hier sieht man, wie die Playbooks in einer von ihnen organisiert sind.

Es ist praktisch, da sofort klar ist, wo sich welche Aufgaben befinden. In der main.yml, die der Eingang für die Ansible-Rolle ist, können wir einfach nach dem Status des Tickets oder allgemeinen Aufgaben, die für alle notwendig sind, wie z.B. Identifikation oder Token-Abruf, einfügen.

Investigation.yml

Wird für Tickets im Status Investigation und Open gestartet. Das Wichtigste für dieses Playbook ist der Name des Blockgeräts. Diese Information ist nicht immer verfügbar.

Um diese zu erhalten, analysieren wir die Zusammenfassung in Jira, den letzten Wert vom Zabbix-Trigger. Dort kann der Name des Blockgeräts enthalten sein – Glück gehabt. Oder es könnte der Mount-Punkt sein, dann muss man auf den Server gehen, parsen und die benötigte Festplatte berechnen. Auch der Trigger kann die SCSI-Adresse oder andere Informationen übermitteln. Aber manchmal gibt es auch keine Hinweise, und man muss analysieren.

Nachdem wir den Namen des Blockgeräts herausgefunden haben, sammeln wir Informationen über den Typ und die Größe der Festplatte, um die Felder in Jira auszufüllen. Wir erfassen auch Informationen über den Anbieter, das Modell, die Firmware, die ID, SMART und fügen all dies in den Kommentar im Jira-Ticket ein. Der Administrator und der Techniker müssen diese Daten jetzt nicht mehr suchen. 🙂

prepare2change.yml

Aus der Rotation nehmen der Festplatte, Vorbereitung auf den Austausch. Die schwierigste und verantwortungsvollste Phase. Hier kann man die Anwendung anhalten, wenn sie nicht gestoppt werden kann. Oder man zieht die Festplatte heraus, bei der keine Replikate vorhanden waren, was Auswirkungen auf die Benutzer hat und möglicherweise Datenverlust bedeutet. Hier haben wir die meisten Überprüfungen und Benachrichtigungen im Chat.

Im einfachsten Fall handelt es sich um das Entfernen der Festplatte aus HW/MD RAID.

In komplexeren Situationen (in unseren Speichersystemen), wenn das Backup auf Anwendungsebene durchgeführt wird, muss man über die API zur Anwendung gehen, die Entfernung der Festplatte melden, sie deaktivieren und die Wiederherstellung einleiten.

Wir migrieren derzeit massiv nach die Cloud, und wenn der Server in der Cloud ist, kontaktiert Diskobot die API der Cloud, teilt mit, dass er mit diesem Minion – dem Server, auf dem die Container laufen – arbeiten wird, und bittet darum, "alle Container von diesem Minion zu migrieren". Gleichzeitig aktiviert er die Beleuchtung der Festplatte, damit der Ingenieur sofort sieht, welche herausgezogen werden muss.

changed.yml

Nach dem Austausch der Festplatte überprüfen wir zuerst deren Verfügbarkeit.

Ingenieure setzen nicht immer neue Festplatten ein, daher haben wir eine Überprüfung der uns geeigneten SMART-Werte hinzugefügt.

Welche Attribute betrachten wirAnzahl der umgeschichteten Sektoren (5) < 100
Aktuelle Anzahl der wartenden Sektoren (107) == 0

Wenn die Festplatte den Test nicht besteht, wird der Ingenieur über einen erneuten Austausch informiert. Wenn alles in Ordnung ist, schaltet sich die Anzeige aus, wird eine Markierung aufgebracht und die Festplatte wird in den Betrieb genommen.

ready.yml

Der einfachste Fall: Überprüfung der Synchronisation von HW/SW Raid oder Abschluss der Datensynchronisation in der Anwendung.

API der Anwendungen

Ich habe mehrfach erwähnt, dass der Bot häufig auf die API der Anwendungen zugreift. Natürlich hatten nicht alle Anwendungen die erforderlichen Methoden, also mussten sie angepasst werden. Hier sind die wichtigsten Methoden, die wir verwenden:

• Status. Status des Clusters oder der Festplatte, um zu verstehen, ob man damit arbeiten kann;
• Start/Stopp. Aktivierung-Deaktivierung der Festplatte;
• Migrieren/Wiederherstellen. Migration und Wiederherstellung von Daten während und nach dem Austausch.

Erfahrungen zu Ansible

Ich liebe Ansible sehr. Aber oft, wenn ich mir verschiedene Open-Source-Projekte ansehe und sehe, wie die Leute Playbooks schreiben, macht es mir ein wenig Angst. Komplexe logische Verknüpfungen von when/loop, mangelnde Flexibilität und Idempotenz aufgrund der häufigen Verwendung von shell/command.

Wir haben beschlossen, alles so einfach wie möglich zu halten und die Modularität von Ansible zu nutzen. Auf der höchsten Ebene befinden sich die Playbooks, die von jedem Administrator oder externen Entwickler, der ein wenig Ansible kennt, geschrieben werden können.

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

Wenn eine Logik in Playbooks schwer umzusetzen ist, lagern wir sie in ein Ansible-Modul oder einen Filter aus. Die Skripte können in Python oder jeder anderen Sprache geschrieben werden.

Sie sind leicht und schnell zu schreiben. Zum Beispiel besteht das oben gezeigte Modul zur Anzeigesteuerung der Festplatte aus 265 Zeilen.

Auf der untersten Ebene befindet sich die Bibliothek. Für dieses Projekt haben wir eine separate Anwendung geschrieben, eine Art Abstraktion über Hardware- und Software-RAID, die die entsprechenden Anfragen ausführt.

Die größten Stärken von Ansible sind die Einfachheit und die verständlichen Playbooks. Ich glaube, dass man dies nutzen sollte, anstatt schreckliche YAML-Dateien und eine große Menge an Bedingungen, Shell-Code und Schleifen zu generieren.

Wenn Sie unsere Erfahrungen mit der Ansible-API nachahmen möchten, beachten Sie bitte zwei Dinge:

• Playbook_executor und dem playbook kann kein Timeout übergeben werden. Es gibt ein Timeout für SSH-Sitzungen, aber kein Timeout für das Playbook. Wenn wir versuchen, eine Festplatte zu demontieren, die im System nicht mehr existiert, wird das Playbook endlos ausgeführt, weshalb wir ihren Start in einen separaten Wrapper einbetten und nach Timeout beenden mussten.
• Ansible basiert auf Fork-Prozessen, daher ist seine API nicht thread-sicher. Wir führen alle unsere Playbooks einsträngig aus.

Insgesamt ist es uns gelungen, den Austausch von etwa 80 % der Festplatten zu automatisieren. Insgesamt hat sich die Austauschgeschwindigkeit verdoppelt. Heute schaut der Administrator nur auf das Incident und trifft eine Entscheidung, ob die Festplatte gewechselt werden muss oder nicht, und klickt dann einmal.

Aber jetzt stehen wir vor einem anderen Problem: Einige neue Administratoren wissen nicht, wie man Festplatten wechselt. 🙂

Quelle: habr.com