Automatisieren Sie den Festplattenaustausch mit Ansible

Hallo alle. Ich arbeite als leitender Systemadministrator bei OK und bin für den stabilen Betrieb des Portals verantwortlich. Ich möchte darüber sprechen, wie wir den Prozess des automatischen Festplattenaustauschs aufgebaut haben und wie wir dann den Administrator von diesem Prozess ausgeschlossen und ihn durch einen Bot ersetzt haben.

Bei diesem Artikel handelt es sich um eine Art Transliteration Aufführungen auf der HighLoad+ 2018

Erstellen eines Festplattenaustauschprozesses

Zuerst ein paar Zahlen

OK ist ein riesiger Dienst, der von Millionen Menschen genutzt wird. Es wird von etwa 7 Servern bedient, die sich in 4 verschiedenen Rechenzentren befinden. Die Server verfügen über mehr als 70 Festplatten. Stapelt man sie übereinander, erhält man einen Turm mit einer Höhe von mehr als 1 km.

Festplatten sind die Serverkomponente, die am häufigsten ausfällt. Bei diesem Umfang müssen wir etwa 30 Festplatten pro Woche wechseln, und dieser Vorgang ist zu einer nicht sehr angenehmen Routine geworden.

Vorfälle

Wir haben in unserem Unternehmen ein vollwertiges Störfallmanagement eingeführt. Wir zeichnen jeden Vorfall in Jira auf und lösen und analysieren ihn dann. Wenn der Vorfall Auswirkungen auf die Nutzer hatte, dann werden wir uns auf jeden Fall zusammensetzen und darüber nachdenken, wie wir in solchen Fällen schneller reagieren können, wie wir die Auswirkungen reduzieren und natürlich wie wir ein erneutes Auftreten verhindern können.

Lagerung ist keine Ausnahme. Zabbix überwacht ihren Status. Wir überwachen Meldungen im Syslog auf Schreib-/Lesefehler, analysieren den Status von HW/SW-Raids, überwachen SMART, berechnen den Verschleiß von SSDs.

Wie haben sich die Scheiben vorher verändert?

Wenn in Zabbix ein Auslöser ausgelöst wird, wird in Jira ein Vorfall erstellt und automatisch an die entsprechenden Techniker in den Rechenzentren weitergeleitet. Wir tun dies bei allen HW-Vorfällen, also solchen, die physische Arbeiten an der Ausrüstung im Rechenzentrum erfordern.
Ein Rechenzentrumsingenieur ist eine Person, die Hardwareprobleme löst und für die Installation, Wartung und Demontage von Servern verantwortlich ist. Nachdem er ein Ticket erhalten hat, macht sich der Ingenieur an die Arbeit. In Festplatten-Shelfs wechselt es die Festplatten selbstständig. Hat er jedoch keinen Zugriff auf das gewünschte Gerät, wendet sich der Techniker hilfesuchend an die diensthabenden Systemadministratoren. Zunächst müssen Sie die Scheibe aus der Rotation bringen. Dazu müssen Sie die erforderlichen Änderungen auf dem Server vornehmen, Anwendungen stoppen und die Bereitstellung der Festplatte aufheben.

Der diensthabende Systemadministrator ist während der Arbeitsschicht für den Betrieb des gesamten Portals verantwortlich. Er untersucht Vorfälle, führt Reparaturen durch und hilft Entwicklern bei kleinen Aufgaben. Es geht nicht nur um Festplatten.

In der Vergangenheit unterhielten sich Rechenzentrumstechniker mit dem Systemadministrator. Ingenieure schickten Links zu Jira-Tickets, der Administrator ging sie durch und führte ein Arbeitsprotokoll in einem Notizbuch. Doch für solche Aufgaben sind Chats unbequem: Die Informationen dort sind unstrukturiert und gehen schnell verloren. Ja, und der Administrator konnte sich einfach vom Computer entfernen und eine Zeit lang nicht auf Anfragen reagieren, und der Techniker stand mit einem Paket Disketten am Server und wartete.

Das Schlimmste war jedoch, dass die Administratoren nicht das Gesamtbild sahen: welche Festplattenvorfälle es gab und wo möglicherweise ein Problem auftreten könnte. Dies liegt daran, dass wir alle HW-Vorfälle an Ingenieure weitergeben. Ja, es war möglich, alle Vorfälle im Admin-Dashboard anzuzeigen. Aber davon gibt es viele, und nur bei einigen war der Administrator beteiligt.

Darüber hinaus konnte der Ingenieur die Prioritäten nicht richtig festlegen, da er nichts über den Zweck bestimmter Server und die Verteilung der Informationen auf die Laufwerke weiß.

Neues Austauschverfahren

Als erstes haben wir alle Festplattenvorfälle in einen separaten Typ „HW-Festplatte“ verschoben und die Felder „Blockgerätename“, „Größe“ und „Festplattentyp“ hinzugefügt, damit diese Informationen im Ticket gespeichert werden und nicht Ich muss ständig chatten.

Wir haben auch vereinbart, dass wir im Rahmen eines Vorfalls nur eine Festplatte wechseln. Dies vereinfachte den Automatisierungsprozess, die Erhebung von Statistiken und die Arbeit in der Zukunft erheblich.

Zusätzlich wurde das Feld „zuständiger Administrator“ hinzugefügt. Dort wird automatisch der diensthabende Systemadministrator vertreten. Das ist sehr praktisch, da der Ingenieur jetzt immer sieht, wer verantwortlich ist. Sie müssen nicht zum Kalender gehen und nachschauen. Dieses Feld ermöglichte die Anzeige von Tickets im Dashboard des Administrators, bei denen möglicherweise seine Hilfe benötigt wird.

Damit alle Teilnehmer den größtmöglichen Nutzen aus den Innovationen ziehen können, haben wir Filter und Dashboards erstellt und den Jungs davon erzählt. Wenn Menschen Veränderungen verstehen, distanzieren sie sich nicht davon als etwas Unnötiges. Für den Techniker ist es wichtig, die Rack-Nummer, in der sich der Server befindet, sowie die Größe und den Typ der Festplatte zu kennen. Der Administrator muss zunächst verstehen, um welche Art von Servergruppe es sich handelt und welche Auswirkungen dies beim Austausch einer Festplatte haben kann.

Das Vorhandensein von Feldern und deren Anzeige ist praktisch, aber das hat uns nicht von der Notwendigkeit befreit, Chats zu verwenden. Dazu mussten wir den Arbeitsablauf ändern.

Früher war es so:

Heute arbeiten Ingenieure auf diese Weise weiter, wenn sie nicht die Hilfe eines Administrators benötigen.

Als erstes haben wir einen neuen Status eingeführt Untersuchen. Das Ticket befindet sich in diesem Status, wenn der Bearbeiter noch nicht entschieden hat, ob er einen Administrator benötigt oder nicht. Über diesen Status kann der Bearbeiter das Ticket an den Administrator weiterleiten. Darüber hinaus kennzeichnen wir Tickets mit diesem Status, wenn ein Datenträgeraustausch erforderlich ist, der Datenträger selbst jedoch nicht vor Ort ist. Dies geschieht im Fall von CDN und Remote-Sites.

Wir haben auch einen Status hinzugefügt Bereit. Das Ticket wird nach dem Austausch der Festplatte darauf übertragen. Das heißt, alles ist bereits erledigt, aber HW/SW-RAID ist auf dem Server synchronisiert. Dies kann ziemlich lange dauern.

Wenn ein Administrator an der Arbeit beteiligt ist, wird das Schema etwas komplizierter.

Außerhalb des Status Offen Das Ticket kann sowohl vom Systemadministrator als auch vom Techniker übersetzt werden. im Status In Arbeit Der Administrator entfernt die Festplatte aus der Rotation, sodass der Techniker sie einfach herausziehen kann: Er schaltet die Hintergrundbeleuchtung ein, hebt die Bereitstellung der Festplatte auf und stoppt Anwendungen, abhängig von der spezifischen Servergruppe.

Das Ticket wird dann übersetzt in Bereit zum Wechseln: Dies ist ein Signal an den Techniker, dass die Diskette herausgezogen werden kann. Alle Felder in Jira sind bereits ausgefüllt, der Techniker weiß, um welchen Typ und welche Größe es sich handelt. Diese Daten werden entweder zum vorherigen Stand automatisch oder vom Administrator eingetragen.

Nach dem Ersetzen der Festplatte wird das Ticket in den Status übertragen Geändert. Es wird überprüft, ob die richtige Festplatte eingelegt wurde, die Partitionierung durchgeführt, die Anwendung gestartet und einige Datenwiederherstellungsaufgaben gestartet. Außerdem kann das Ticket in den Status übernommen werden Bereit, in diesem Fall bleibt der Administrator verantwortlich, da er die Festplatte in Rotation versetzt hat. Das komplette Schema sieht so aus.

Die Hinzufügung neuer Felder hat uns das Leben erheblich erleichtert. Die Jungs begannen mit strukturierten Informationen zu arbeiten, es wurde klar, was in welcher Phase getan werden muss. Prioritäten sind viel relevanter geworden, da sie jetzt vom Administrator festgelegt werden.

Keine Notwendigkeit für Chats. Natürlich kann der Administrator dem Techniker schreiben: „Hier müssen Sie schneller austauschen“ oder „Es ist schon Abend, haben Sie Zeit für den Austausch?“. Aber wir kommunizieren nicht mehr täglich in Chats zu diesen Themen.

Die Festplatten begannen sich schubweise zu verändern. Wenn der Administrator etwas früher zur Arbeit kommt, er Freizeit hat und noch nichts passiert ist, kann er eine Reihe von Servern für den Austausch vorbereiten: Felder ausfüllen, Festplatten aus der Rotation nehmen und die Aufgabe an einen Techniker übergeben. Wenig später kommt ein Techniker ins Rechenzentrum, sieht die Aufgabe, holt die benötigten Laufwerke aus dem Lager und tauscht sie sofort aus. Dadurch ist die Ersatzquote gestiegen.

Gelernte Erfahrung beim Erstellen von Workflows

• Beim Erstellen einer Prozedur müssen Sie Informationen aus verschiedenen Quellen sammeln.
  Einige unserer Administratoren wussten nicht, dass der Techniker die Festplatten selbst wechselt. Einige Leute dachten, dass das MD-RAID von den Ingenieuren synchron gehalten wurde, obwohl einige von ihnen nicht einmal Zugriff darauf hatten. Einige führende Ingenieure haben dies getan, jedoch nicht immer, da der Prozess nirgendwo beschrieben wurde.
• Das Verfahren sollte einfach und verständlich sein.
  Für einen Menschen ist es schwierig, viele Schritte im Kopf zu behalten. Die wichtigsten Nachbarstatus in Jira sollten auf dem Hauptbildschirm platziert werden. Sie können sie umbenennen, zum Beispiel in „In Bearbeitung“ nennen wir „Bereit zum Ändern“. Und die restlichen Status können im Dropdown-Menü ausgeblendet werden, damit sie nicht stören. Aber es ist besser, die Menschen nicht einzuschränken, sondern ihnen die Möglichkeit zu geben, den Übergang zu schaffen.
  Erklären Sie den Wert von Innovation. Wenn die Leute es verstehen, akzeptieren sie das neue Verfahren besser. Für uns war es sehr wichtig, dass die Leute den gesamten Prozess nicht durchklicken, sondern ihm folgen. Dann haben wir auf dieser Automatisierung aufgebaut.
• Abwarten, analysieren, verstehen.
  Wir haben etwa einen Monat gebraucht, um das Verfahren, die technische Umsetzung, Besprechungen und Diskussionen aufzubauen. Und für die Umsetzung – mehr als drei Monate. Ich habe gesehen, wie die Leute langsam anfangen, die Innovation zu nutzen. In der Anfangsphase gab es viel Negativität. Aber es war völlig unabhängig vom Verfahren selbst, seiner technischen Umsetzung. Beispielsweise nutzte ein Administrator nicht Jira, sondern ein Jira-Plugin in Confluence und einige Dinge standen ihm nicht zur Verfügung. Wir zeigten ihm Jira und der Administrator steigerte die Produktivität sowohl bei allgemeinen Aufgaben als auch beim Austauschen von Festplatten.

Automatisierung des Festplattenaustauschs

Wir haben uns mehrmals mit der Automatisierung des Austauschs von Festplatten beschäftigt. Wir hatten bereits Entwicklungen und Skripte, aber sie alle funktionierten entweder im interaktiven oder manuellen Modus und mussten gestartet werden. Und erst nach der Einführung des neuen Verfahrens wurde uns klar, dass es genau das war, was wir brauchten.

Da der Ersetzungsprozess nun in Phasen unterteilt ist, von denen jede über einen Ausführenden und eine Liste von Aktionen verfügt, können wir die Automatisierung in Etappen und nicht in allen auf einmal ermöglichen. Beispielsweise kann die einfachste Phase „Ready“ (Überprüfung von RAID/Datensynchronisation) problemlos an einen Bot delegiert werden. Wenn der Bot ein wenig lernt, können Sie ihm eine verantwortungsvollere Aufgabe übertragen – die Festplatte in Rotation versetzen usw.

Zoo einrichten

Bevor wir über den Bot sprechen, machen wir einen kurzen Rundgang durch unseren Installationszoo. Das liegt zum einen an der gigantischen Größe unserer Infrastruktur. Zweitens versuchen wir, für jeden Dienst die optimale Hardwarekonfiguration auszuwählen. Wir haben etwa 20 Hardware-RAID-Modelle, hauptsächlich LSI und Adaptec, aber es gibt auch HP und DELL in verschiedenen Versionen. Jeder RAID-Controller verfügt über ein eigenes Verwaltungsdienstprogramm. Der Befehlssatz und die Ausgabe können je nach RAID-Controller von Version zu Version unterschiedlich sein. Wenn HW-RAID nicht verwendet wird, kann Mdraid vorhanden sein.

Wir führen fast alle Neuinstallationen ohne Festplattenredundanz durch. Wir versuchen, auf den Einsatz von Hardware- und Software-RAIDs zu verzichten, da wir unsere Systeme auf der Ebene von Rechenzentren und nicht auf Serverebene sichern. Aber natürlich gibt es viele Legacy-Server, die gewartet werden müssen.

Irgendwo werden Festplatten in RAID-Controllern als Rohgeräte ausgegeben, irgendwo werden JBODs verwendet. Es gibt Konfigurationen mit einer Systemfestplatte im Server, und wenn diese ersetzt werden muss, müssen Sie den Server mit der Installation des Betriebssystems und der Anwendungen sowie der gleichen Versionen neu starten, dann Konfigurationsdateien hinzufügen und Anwendungen ausführen. Es gibt auch viele Servergruppen, bei denen die Redundanz nicht auf der Ebene des Festplattensubsystems, sondern direkt in den Anwendungen selbst erfolgt.

Insgesamt verfügen wir über über 400 einzigartige Servergruppen, auf denen etwa 100 verschiedene Anwendungen ausgeführt werden. Um eine so große Anzahl an Optionen abzudecken, brauchten wir ein funktionsreiches Automatisierungstool. Am besten mit einem 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 keine Vorbereitung der Infrastruktur erforderlich, ein schneller Einstieg. Darüber hinaus ist es in Python geschrieben, was im Team als Standard akzeptiert wird.

Allgemeines Schema

Schauen wir uns das allgemeine Automatisierungsschema am Beispiel eines Vorfalls an. Zabbix erkennt, dass die SDB-Festplatte ausgefallen ist, der Trigger wird ausgelöst und in Jira wird ein Ticket erstellt. Der Administrator sah es sich an, stellte fest, dass es sich nicht um ein Duplikat und kein Falschpositiv handelte, d. h. die Festplatte musste gewechselt werden, und übertrug das Ticket auf „In Bearbeitung“.

Die in Python geschriebene DiskoBot-Anwendung fragt Jira regelmäßig nach neuen Tickets ab. Es stellt fest, dass ein neues In-Progress-Ticket aufgetaucht ist, der entsprechende Thread wird ausgelöst, der das Playbook in Ansible startet (dies erfolgt für jeden Status in Jira). In diesem Fall wird Prepare2change ausgeführt.

Ansible geht zum Host, entfernt die Festplatte aus der Rotation und meldet den Status über Callbacks an die Anwendung.

Basierend auf den Ergebnissen ändert der Bot das Ticket automatisch in „Bereit zum Ändern“. Der Techniker erhält eine Benachrichtigung und wechselt die Festplatte. Anschließend überträgt er das Ticket auf „Geändert“.

Gemäß dem obigen Schema geht das Ticket zurück zum Bot, der ein weiteres Playbook startet, zum Host geht und die Festplatte in Rotation versetzt. Der Bot schließt das Ticket. Hurra!

Lassen Sie uns nun über einige Komponenten des Systems sprechen.

Diskobot

Diese Anwendung ist in Python geschrieben. Es wählt Tickets von Jira gemäß JQL aus. Abhängig vom Status des Tickets gelangt dieses zum entsprechenden Handler, der wiederum das dem Status entsprechende Ansible-Playbook startet.

JQL- und Abfrageintervalle werden in der Anwendungskonfigurationsdatei definiert.

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

Beispielsweise werden unter Tickets mit dem Status „In Bearbeitung“ nur diejenigen ausgewählt, bei denen die Felder „Festplattengröße“ und „Gerätename“ ausgefüllt sind. Der Gerätename ist der Name des Blockgeräts, das zum Ausführen des Playbooks benötigt wird. Die Festplattengröße ist erforderlich, damit der Techniker weiß, welche Festplattengröße benötigt wird.

Und unter Tickets mit dem Status „Bereit“ werden Tickets mit der Bezeichnung „dbot_ignore“ herausgefiltert. Übrigens verwenden wir Jira-Labels sowohl für diese Filterung als auch zum Markieren doppelter Tickets und zum Sammeln von Statistiken.

Im Falle eines Playbook-Fehlers weist Jira die Bezeichnung „dbot_failed“ zu, damit das Problem später behoben werden kann.

Interaktion mit Ansible

Die Anwendung interagiert mit Ansible über Ansible-Python-API. In playbook_executor übergeben wir einen Dateinamen und eine Reihe von Variablen. Dies ermöglicht es Ihnen, das Ansible-Projekt in Form gewöhnlicher YML-Dateien beizubehalten und es nicht in Python-Code zu beschreiben.

Außerdem werden der Name des Blockgeräts, der Status des Tickets sowie die callback_url, in der der Issue-Schlüssel fest codiert ist, über *extra_vars* an Ansible übermittelt – sie wird für Callbacks in HTTP verwendet.

Für jeden Lauf wird ein temporäres Inventar erstellt, das aus einem Host und der Gruppe besteht, zu der dieser Host gehört, sodass „group_vars“ angewendet werden.

Hier ist ein Beispiel für eine Aufgabe, die einen HTTP-Rückruf implementiert.

Das Ergebnis der Ausführung des Playbooks erhalten wir mithilfe von Callaback(s). Es gibt zwei Arten:

• Ansible-Callback-Plugin, es liefert Daten zu den Ergebnissen der Playbook-Ausführung. Es beschreibt die Aufgaben, die gestartet, erfolgreich oder erfolglos abgeschlossen wurden. Dieser Rückruf wird aufgerufen, wenn die Wiedergabe des Playbooks beendet ist.
• HTTP-Rückruf zum Abrufen von Informationen während der Wiedergabe des Playbooks. In der Ansible-Aufgabe führen wir eine POST/GET-Anfrage an die Seite unserer Anwendung durch.

Durch den/die HTTP-Callback(s) werden Variablen übergeben, die während der Ausführung des Playbooks definiert wurden und die wir speichern und in nachfolgenden Läufen verwenden möchten. Wir schreiben diese Daten in SQLite.

Auch per HTTP-Callback hinterlassen wir Kommentare und ändern den Ticketstatus.

HTTP-Rückruf

# 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 Aufgaben derselben Art haben wir sie in eine separate gemeinsame Datei verschoben und bei Bedarf aktiviert, um sie in Playbooks nicht ständig zu wiederholen. Hier erscheint die Callback-URL, in der der Issue-Schlüssel und der Hostname geschützt sind. Wenn Ansible diese POST-Anfrage ausführt, versteht der Bot, dass sie Teil dieses oder jenes Vorfalls war.

Und hier ist ein Beispiel aus einem Playbook, in dem wir eine Disc aus einem MD-Gerät ausgeworfen 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 ändert den Status des Jira-Tickets in „Bereit zum Ändern“ und fügt einen Kommentar hinzu. Die Variable mdam_data enthält außerdem eine Liste der MD-Geräte, von denen die Festplatte entfernt wurde, und parted_info enthält einen Partitionsdump von parted.

Wenn der Techniker eine neue Festplatte einfügt, können wir diese Variablen verwenden, um den Partitions-Dump wiederherzustellen und die Festplatte in die MD-Geräte zu übertragen, von denen sie entfernt wurde.

Ansible-Prüfmodus

Das Einschalten der Automatisierung war beängstigend. Daher haben wir uns entschieden, alle Playbooks in diesem Modus auszuführen
Probelauf, bei dem Ansible keine Aktionen auf den Servern ausführt, sondern diese lediglich emuliert.

Ein solcher Start erfolgt über ein separates Callback-Modul und das Ergebnis der Playbook-Ausführung 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 bestanden und erkannten, dass es möglich war, Ansible nicht nur im Probelaufmodus auszuführen, haben wir in Jira eine Schaltfläche „Diskobot ausführen“ erstellt, um dasselbe Playbook mit denselben Variablen auf demselben Host, jedoch im normalen Modus, auszuführen.

Außerdem wird die Schaltfläche verwendet, um das Playbook neu zu starten, wenn es abstürzt.

Struktur von Playbooks

Ich habe bereits erwähnt, dass der Bot je nach Status des Jira-Tickets unterschiedliche Playbooks startet.

Erstens ist es viel einfacher, den Eingang zu organisieren.
Zweitens ist es in manchen Fällen einfach notwendig.

Wenn Sie beispielsweise die Systemfestplatte austauschen, müssen Sie zunächst zum Bereitstellungssystem gehen, eine Aufgabe erstellen. Nach der korrekten Bereitstellung wird der Server über SSH verfügbar und Sie können die Anwendung darauf ausführen. Wenn wir dies alles in einem Playbook erledigen würden, wäre Ansible aufgrund der Nichtverfügbarkeit des Hosts nicht in der Lage, es auszuführen.

Wir verwenden Ansible-Rollen für jede Servergruppe. Hier können Sie sehen, wie die Playbooks in einem davon organisiert sind.

Das ist praktisch, denn es ist sofort klar, wo welche Aufgaben liegen. In main.yml, der Eingabe für die Ansible-Rolle, können wir einfach den Status des Tickets oder allgemeine Aufgaben einbeziehen, die für alle notwendig sind, zum Beispiel die Ausweisübergabe oder den Erhalt eines Tokens.

investigative.yml

Gestartet für Tickets mit den Status „Untersuchung“ und „Offen“. Das Wichtigste für dieses Playbook ist der Name des Blockgeräts. Diese Informationen sind nicht immer verfügbar.

Um es zu erhalten, analysieren wir die Jira-Zusammenfassung, den letzten Wert des Zabbix-Triggers. Es kann den Namen des Blockgeräts enthalten – Glück gehabt. Und es kann einen Einhängepunkt enthalten – dann müssen Sie zum Server gehen, den erforderlichen Datenträger analysieren und berechnen. Außerdem kann der Trigger eine SCSI-Adresse oder andere Informationen senden. Es kommt aber auch vor, dass es keine Hinweise gibt und man analysieren muss.

Nachdem wir den Namen des Blockgeräts herausgefunden haben, sammeln wir von ihm Informationen über Typ und Größe der Festplatte, um die Felder in Jira auszufüllen. Wir entfernen auch Informationen über Hersteller, Modell, Firmware, ID, SMART und fügen all diese in einen Kommentar im Jira-Ticket ein. Der Administrator und Ingenieur muss nicht mehr nach diesen Daten suchen. 🙂

Prepare2change.yml

Antrieb aus der Rotation, Vorbereitung zum Austausch. Die schwierigste und verantwortungsvollste Phase. Hier können Sie die Anwendung stoppen, wenn sie nicht gestoppt werden kann. Oder ziehen Sie eine Festplatte heraus, auf der Replikate fehlen, und führen Sie dadurch zu einem Datenverlust für die Benutzer. Hier haben wir die meisten Checks und Benachrichtigungen im Chat.

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

In komplexeren Situationen (in unseren Speichersystemen), wenn die Sicherung auf Anwendungsebene erfolgt, müssen Sie über die API zur Anwendung gehen, das Auswerfen der Festplatte melden, sie deaktivieren und die Wiederherstellung starten.

Wir migrieren jetzt massenhaft dorthin Wolke, und wenn der Server bewölkt ist, dann greift Diskobot auf die Cloud-API zu, sagt, dass es mit diesem Minion – dem Server, auf dem die Container laufen – arbeiten wird und fragt „Alle Container von diesem Minion migrieren“. Gleichzeitig wird die Hintergrundbeleuchtung der Diskette eingeschaltet, sodass der Ingenieur sofort erkennen kann, welche Diskette herausgezogen werden muss.

geändert.yml

Nach dem Austausch einer Festplatte prüfen wir zunächst deren Verfügbarkeit.

Ingenieure installieren nicht immer neue Festplatten, daher haben wir eine Prüfung auf SMART-Werte hinzugefügt, mit denen wir zufrieden sind.

Welche Attribute betrachten wir?Anzahl der neu zugewiesenen Sektoren (5) < 100
Aktuelle ausstehende Sektoranzahl (107) == 0

Wenn das Laufwerk den Test nicht besteht, wird der Techniker aufgefordert, es erneut auszutauschen. Wenn alles in Ordnung ist, wird die Hintergrundbeleuchtung ausgeschaltet, Markierungen angebracht und die Scheibe in Rotation versetzt.

ready.yml

Der einfachste Fall: Überprüfung der Synchronisierung von HW/SW-RAID oder des Endes der Datensynchronisierung in der Anwendung.

Anwendungs-APIs

Ich habe mehrfach erwähnt, dass der Bot oft auf die Anwendungs-API zugreift. Natürlich verfügten nicht alle Anwendungen über die erforderlichen Methoden und mussten daher finalisiert werden. Hier sind die wichtigsten Methoden, die wir verwenden:

• Status. Der Status eines Clusters oder einer Festplatte, um festzustellen, ob damit gearbeitet werden kann;
• Start stop. Festplattenaktivierung/-deaktivierung;
• Migrieren/Wiederherstellen. Migration und Wiederherstellung von Daten während und nach dem Austausch.

Von Ansible gerenderte Erfahrung

Ich liebe Ansible wirklich. Aber wenn ich mir verschiedene Open-Source-Projekte ansehe und sehe, wie Leute Playbooks schreiben, bekomme ich oft ein wenig Angst. Komplexe logische Verflechtung von when/loop, mangelnde Flexibilität und Idempotenz aufgrund der häufigen Verwendung von Shell/Befehl.

Wir haben uns entschieden, alles so weit wie möglich zu vereinfachen und dabei den Vorteil von Ansible – die Modularität – zu nutzen. Auf der höchsten Ebene befinden sich Playbooks. Sie können von jedem Administrator oder Drittentwickler geschrieben werden, der sich ein wenig mit Ansible auskennt.

- 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 zu implementieren ist, verschieben wir sie in ein Ansible-Modul oder einen Ansible-Filter. Skripte können in Python oder einer anderen Sprache geschrieben werden.

Sie sind einfach und schnell zu schreiben. Das oben gezeigte Scheibenbeleuchtungsmodul hat beispielsweise 265 Zeilen.

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

Die größten Stärken von Ansible sind seine Einfachheit und die leicht verständlichen Playbooks. Ich denke, dass Sie dies nutzen müssen und keine schrecklichen Yaml-Dateien und eine große Anzahl von Bedingungen, Shell-Code und Schleifen generieren dürfen.

Wenn Sie unsere Ansible-API-Erfahrung wiederholen möchten, beachten Sie zwei Dinge:

• Playbook_executor und Playbook im Allgemeinen können keine Zeitüberschreitung erhalten. Es gibt eine Zeitüberschreitung für die SSH-Sitzung, aber keine Zeitüberschreitung für das Playbook. Wenn wir versuchen, die Bereitstellung einer nicht mehr im System vorhandenen Festplatte aufzuheben, wird das Playbook auf unbestimmte Zeit ausgeführt. Daher mussten wir seinen Start in einen separaten Wrapper verpacken und es durch Zeitüberschreitung beenden.
• Ansible arbeitet auf Basis von Fork-Prozessen, daher ist seine API nicht Thread-sicher. Wir führen alle unsere Playbooks in einem einzigen Thread aus.

Dadurch konnten wir den Austausch von etwa 80 % der Festplatten automatisieren. Generell hat sich die Ersatzquote verdoppelt. Heute schaut sich der Administrator nur den Vorfall an und entscheidet, ob die Festplatte gewechselt werden soll oder nicht, und macht dann einen Klick.

Aber jetzt stoßen wir auf ein anderes Problem: Einige neue Administratoren wissen nicht, wie man Laufwerke wechselt. 🙂

Source: habr.com