Automatisieren Sie den Festplattenaustausch mit Ansible

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

Dieser Artikel ist eine Art Transliteration der Leistung bei HighLoad + 2018

Erstellen eines Disc-Austauschprozesses

Zuerst ein paar Zahlen

OK ist ein gigantischer Dienst, der von Millionen von Menschen genutzt wird. Es wird von etwa 7.000 Servern bedient, die sich in 4 verschiedenen Rechenzentren befinden. Die Server kosten mehr als 70.000 Laufwerke. Wenn Sie sie übereinander stapeln, erhalten Sie einen Turm mit einer Höhe von mehr als 1 km.

Festplatten sind eine Komponente des Servers, die am häufigsten abstürzt. Bei solchen Volumina müssen wir ungefähr 30 Scheiben pro Woche wechseln, und dieses Verfahren ist zu einer nicht sehr angenehmen Routine geworden.

Vorfälle

Wir haben ein vollwertiges Incident Management in unserem Unternehmen eingeführt. Jeder Vorfall, den wir in Jira aufzeichnen und dann lösen und zerlegen. Wenn der Vorfall Auswirkungen auf die Benutzer hatte, werden wir auf jeden Fall darüber nachdenken, wie wir in solchen Fällen schneller reagieren, den Effekt reduzieren und natürlich eine Wiederholung verhindern können.

Laufwerke sind keine Ausnahme. Ihr Status wird von Zabbix überwacht. Wir überwachen Nachrichten in Syslog auf Schreib- / Lesefehler, analysieren den Status von HW / SW-Raids, überwachen SMART und berechnen den Verschleiß von SSDs.

Wie sich die Discs zuvor geändert haben

Wenn in Zabbix ein Auslöser aufleuchtet, wird in Jira ein Vorfall erstellt und automatisch an die entsprechenden Ingenieure in den Rechenzentren weitergeleitet. Wir tun dies bei allen HW-Vorfällen, dh solchen, bei denen physische Arbeit mit den Geräten im Rechenzentrum erforderlich ist.
Ein Ingenieur eines Rechenzentrums ist eine Person, die Probleme im Zusammenhang mit der Hardware löst und für die Installation, Wartung und Demontage von Servern verantwortlich ist. Nachdem der Ingenieur ein Ticket erhalten hat, beginnt er mit der Arbeit. In Plattenregalen wechselt er die Platten selbst. Wenn er jedoch keinen Zugriff auf das gewünschte Gerät hat, bittet der Techniker die diensthabenden Systemadministratoren um Hilfe. Zunächst müssen Sie die Festplatte aus der Rotation entfernen. Dazu müssen Sie die erforderlichen Änderungen auf dem Server vornehmen, die Anwendung stoppen und die Bereitstellung der Festplatte aufheben.

Der während der Schicht diensthabende Systemadministrator ist für den Betrieb des gesamten Portals verantwortlich. Er untersucht Vorfälle, repariert und hilft Entwicklern bei kleinen Aufgaben. Er beschäftigt sich nicht nur mit Festplatten.

Zuvor unterhielten sich Rechenzentrumsingenieure mit dem Systemadministrator. Ingenieure schickten Links zu Jira-Tickets, der Administrator ging sie durch und führte ein Arbeitsprotokoll in einem Notizblock. Chats sind jedoch für solche Aufgaben unpraktisch: Die Informationen dort sind nicht strukturiert und gehen schnell verloren. Und der Administrator konnte sich einfach vom Computer entfernen und einige Zeit nicht auf Anfragen reagieren, und der Ingenieur stand mit ein paar Festplatten am Server und wartete.

Das Schlimmste war jedoch, dass die Administratoren nicht das ganze Bild sahen: Welche Festplattenvorfälle gibt es, bei denen das Problem möglicherweise auftreten könnte? Dies liegt an der Tatsache, dass wir alle HW-Vorfälle an Ingenieure weitergeben. Ja, es war möglich, alle Vorfälle im Admin-Dashboard anzuzeigen. Aber es gibt viele von ihnen, und der Administrator war nur an einigen von ihnen beteiligt.

Darüber hinaus konnte der Techniker keine korrekten Prioritäten setzen, da er nichts über den Zweck bestimmter Server und die Verteilung von Informationen auf Laufwerke weiß.

Neues Austauschverfahren

Das erste, was wir getan haben, war, alle Festplattenvorfälle in einen separaten Typ von "HW-Festplatte" zu packen und die Felder "Gerätenamen blockieren", "Größe" und "Festplattentyp" hinzuzufügen, damit diese Informationen im Ticket gespeichert werden und nicht müssen ständig chatten.


Wir haben uns auch darauf geeinigt, dass wir im Rahmen eines Vorfalls nur eine Festplatte wechseln werden. Dies vereinfachte den Automatisierungsprozess, die Statistikerfassung und die Arbeit erheblich.

Außerdem wurde das Feld "Verantwortlicher Administrator" hinzugefügt. Der Systemadministrator wird dort automatisch ersetzt. Dies ist sehr praktisch, da der Ingenieur jetzt immer sieht, wer verantwortlich ist. Sie müssen nicht zum Kalender gehen und suchen. In diesem Feld konnten Tickets in das Dashboard des Administrators gestellt werden, in dem möglicherweise seine Hilfe benötigt wurde.


Um sicherzustellen, dass alle Teilnehmer den größtmöglichen Nutzen aus den Innovationen ziehen, haben wir Filter und Dashboards erstellt und den Jungs davon erzählt. Wenn Menschen die Veränderungen verstehen, distanzieren sie sich nicht von ihnen als von etwas Unnötigem. Für einen 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 Ersetzen einer Festplatte haben kann.

Das Vorhandensein von Feldern und deren Anzeige ist praktisch, aber dies hat uns nicht vor der Notwendigkeit bewahrt, Chats zu verwenden. Dazu musste ich den Workflow ändern.

Früher war es so:


Heute arbeiten Ingenieure so weiter, wenn sie keine Administratorhilfe benötigen.

Als erstes haben wir einen neuen Untersuchungsstatus eingeführt . Das Ticket befindet sich in diesem Status, wenn der Techniker noch nicht entschieden hat, ob er einen Administrator benötigt oder nicht. Über diesen Status kann der Techniker das Ticket an den Administrator weitergeben. Darüber hinaus markieren wir Tickets mit diesem Status, wenn ein Festplattenwechsel erforderlich ist, sich jedoch keine Festplatte selbst auf der Site befindet. Dies geschieht bei CDNs und Remote-Standorten.

Wir haben auch den Status Bereit hinzugefügt. Das Ticket wird nach dem Ersetzen der Festplatte darauf übertragen. Das heißt, alles wurde bereits erledigt, aber HW / SW-RAID wird auf dem Server synchronisiert. Dies kann sehr zeitaufwändig sein.

Wenn ein Administrator beteiligt ist, ist das Schema etwas komplizierter.


Ab dem Status " Öffnen " kann ein Ticket sowohl von einem Systemadministrator als auch von einem Techniker übertragen werden. Im Status " In Bearbeitung" entfernt der Administrator die Festplatte aus der Rotation, sodass der Techniker sie einfach entfernen kann: Je nach Servergruppe wird die Hintergrundbeleuchtung eingeschaltet, die Bereitstellung der Festplatte aufgehoben und Anwendungen gestoppt.

Dann wird das Ticket in Ready to change konvertiert: Dies ist ein Signal an den Techniker, dass die Festplatte herausgezogen 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 automatisch oder vom Administrator auf den vorherigen Status angehängt.

Nach dem Ersetzen der Festplatte wird das Ticket in den Status " Geändert " versetzt. Es wird überprüft, ob der richtige Datenträger eingelegt wurde, das Markup durchgeführt, die Anwendung gestartet und einige Datenwiederherstellungsaufgaben ausgeführt wurden. Das Ticket kann auch in den Status " Bereit " versetzt werden. In diesem Fall bleibt der Administrator verantwortlich, da er die Festplatte abwechselnd gestartet hat. Der vollständige Umriss sieht so aus.


Das Hinzufügen neuer Felder hat unser Leben viel einfacher gemacht. Die Jungs begannen mit strukturierten Informationen zu arbeiten, es wurde klar, was und zu welchem ​​Zeitpunkt zu tun war. Prioritäten sind viel relevanter geworden, da sie jetzt vom Administrator festgelegt werden.

Das Bedürfnis nach Chats ist verschwunden. Natürlich kann der Administrator dem Techniker schreiben, "Sie müssen hier schneller ersetzen" oder "bereits abends, haben Sie Zeit zum Ersetzen?" Wir unterhalten uns jedoch nicht mehr täglich über diese Themen.

Die Festplatten begannen sich in Packungen zu wechseln. Wenn der Administrator etwas früher zur Arbeit kam, er Freizeit hat und nichts passiert ist, kann er eine Reihe von Servern für den Austausch vorbereiten: Felder ablegen, Festplatten aus der Rotation entfernen und die Aufgabe an den Techniker übertragen. Ein Techniker kommt später im Rechenzentrum an, sieht die Aufgabe, nimmt die erforderlichen Laufwerke aus dem Lager und ändert sie sofort. Infolgedessen hat sich die Austauschgeschwindigkeit erhöht.

Lehren aus dem 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 ausgetauscht hat. Einige dachten, dass Ingenieure die MD RAID-Synchronisation überwachten, obwohl einige von ihnen nicht einmal Zugriff darauf hatten. Einige führende Ingenieure haben dies getan, aber nicht immer, da der Prozess nirgendwo beschrieben wurde.
• Das Verfahren sollte einfach und unkompliziert sein.
  Es fällt einem Menschen schwer, viele Schritte im Kopf zu behalten. Die wichtigsten Nachbarstatus in Jira müssen auf dem Hauptbildschirm angezeigt werden. Sie können sie umbenennen, z. B. In Bearbeitung rufen wir Ready to change auf. Und die verbleibenden Status können im Dropdown-Menü ausgeblendet werden, damit sie keine Kallusaugen verursachen. Es ist jedoch besser, die Menschen nicht einzuschränken und die Möglichkeit zu geben, den Übergang zu vollziehen.
  Erklären Sie den Wert von Innovation. Wenn die Leute verstehen, akzeptieren sie das neue Verfahren besser. Für uns war es sehr wichtig, dass die Leute den gesamten Prozess nicht aufriefen, sondern ihm folgten. Dann haben wir auf dieser Automatisierung aufgebaut.
• Warten, analysieren, verstehen.
  Wir haben ungefähr einen Monat gebraucht, um das Verfahren, die technische Implementierung, die Besprechungen und die Diskussionen zu erstellen. Und für die Umsetzung - mehr als drei Monate. Ich habe gesehen, wie die Leute langsam anfangen, die Innovation zu nutzen. In den frühen Stadien gab es viel Negativität. Er war jedoch völlig unabhängig vom Verfahren selbst, seiner technischen Umsetzung. Beispielsweise hat ein Administrator Jira nicht verwendet, aber das Jira-Plugin in Confluence, und einige Dinge standen ihm nicht zur Verfügung. Hat ihm Jira gezeigt, hat der Administrator die Produktivität und die Gesamtaufgaben sowie das Ersetzen von Festplatten erhöht.

Automatisierung des Antriebswechsels

Wir sind mehrmals zur Automatisierung des Austauschs von Festplatten übergegangen. Wir hatten bereits Betriebszeit, Skripte, aber alle arbeiteten entweder interaktiv oder im manuellen Modus. Sie mussten gestartet werden. Und erst nach der Einführung des neuen Verfahrens stellten wir fest, dass wir nur vermisst wurden.

Da der Austauschprozess jetzt in Phasen unterteilt ist, von denen jede einen Ausführenden und eine Liste von Aktionen enthält, können wir die Automatisierung schrittweise und nicht alle gleichzeitig aktivieren. Zum Beispiel kann der einfachste Schritt - Bereit (Überprüfen der RAID- / Datensynchronisation) einfach an den Bot delegiert werden. Wenn der Bot ein wenig lernt, können Sie ihm eine verantwortungsvollere Aufgabe geben - das Drehen der Festplatte usw.

Zoo-Setups

Bevor wir über den Bot sprechen, machen wir einen kurzen Ausflug zu unserem Installationszoo. Dies ist vor allem auf die gigantische Größe unserer Infrastruktur zurückzuführen. Zweitens versuchen wir für jeden Service die optimale Konfiguration des Eisens zu wählen. Wir haben ungefähr 20 Hardware-RAID-Modelle, hauptsächlich LSI und Adaptec, aber es gibt sowohl HP als auch DELL mit unterschiedlichen Versionen. Jeder RAID-Controller verfügt über ein eigenes Verwaltungsdienstprogramm. Der Befehlssatz und die Ausgabe dieser Befehle können von Version zu Version jedes RAID-Controllers unterschiedlich sein. Wenn HW-RAID nicht verwendet wird, kann es Angst haben.

Fast alle Neuinstallationen werden ohne Festplatten-Backup durchgeführt. Wir versuchen, kein Hardware- und Software-RAID mehr zu verwenden, da wir unsere Systeme auf der Ebene von Rechenzentren und nicht von Servern reservieren. Aber natürlich gibt es viele Legacy-Server, die unterstützt werden müssen.

Irgendwo werfen die Festplatten in den RAID-Controllern unformatierte Geräte, irgendwo verwenden sie JBOD. Es gibt Konfigurationen mit einem Systemlaufwerk auf dem Server. Wenn Sie es ersetzen müssen, müssen Sie den Server bei der Installation des Betriebssystems und der Anwendungen mit denselben Versionen neu formatieren, dann Konfigurationsdateien hinzufügen und Anwendungen starten. Es gibt auch viele Servergruppen, bei denen Redundanz nicht auf der Ebene des Festplattensubsystems, sondern direkt in den Anwendungen selbst ausgeführt wird.

Insgesamt haben wir mehr als 400 eindeutige Servergruppen, auf denen etwa 100 verschiedene Anwendungen ausgeführt werden. Um eine so große Anzahl von Optionen abzudecken, brauchten wir ein multifunktionales Automatisierungstool. Es ist ratsam, ein einfaches DSL zu verwenden, damit nicht nur die Person, die dies geschrieben hat, es unterstützen kann.

Wir haben uns für Ansible entschieden, weil es agentenlos ist: Es war nicht erforderlich, die Infrastruktur vorzubereiten und schnell zu starten. Darüber hinaus ist es in Python geschrieben, das im Team als Standard akzeptiert wird.

Allgemeines Schema

Schauen wir uns ein allgemeines Automatisierungsschema am Beispiel eines Vorfalls an. Zabbix erkennt, dass das SDB-Laufwerk nicht in Betrieb ist, der Auslöser leuchtet auf und in Jira wird ein Ticket erstellt. Der Administrator sah es sich an und stellte fest, dass dies kein Duplikat und kein falsch positives Ergebnis ist. Das heißt, Sie müssen die Festplatte ändern und das laufende Ticket übersetzen.


Die in Python geschriebene DiskoBot-Anwendung fragt Jira regelmäßig nach neuen Tickets ab. Es wird darauf hingewiesen, dass ein neues In Bearbeitung-Ticket angezeigt wurde und der entsprechende Thread ausgelöst wird, wodurch das Playbook in Ansible gestartet wird (dies erfolgt für jeden Status in Jira). In diesem Fall wird Prepare2change gestartet.

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


Entsprechend den Ergebnissen überträgt der Bot das Ticket automatisch an Ready to change. Der Techniker erhält eine Benachrichtigung und wechselt die Festplatte. Anschließend überträgt er das Ticket an Changed.


Gemäß dem obigen Schema kehrt das Ticket zum Bot zurück, startet ein weiteres Playbook, geht zum Host und gibt die Festplatte in Rotation ein. 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 Ticketstatus gelangt dieser zum entsprechenden Handler, der seinerseits den entsprechenden Ansible-Playbook-Status startet.

JQL- und Abfrageintervalle sind 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 den Tickets im Status "In Bearbeitung" nur diejenigen mit den Feldern "Datenträgergröße" und "Gerätename" ausgefüllt. Gerätename ist der Name des Blockgeräts, das zum Ausführen des Playbooks benötigt wird. Die Festplattengröße wird benötigt, damit der Techniker weiß, welche Festplattengröße benötigt wird.

Bei Tickets mit dem Status "Bereit" werden Tickets mit dem Label "dbot_ignore" herausgefiltert. Übrigens verwenden wir Jira-Labels sowohl zum Filtern als auch zum Markieren doppelter Tickets und zum Sammeln von Statistiken.

Wenn das Playbook abstürzt, weist Jira das Label dbot_failed zu, damit Sie es später herausfinden können.

Interaktion mit Ansible

Die Anwendung interagiert mit Ansible über die Ansible Python-API . In playbook_executor übergeben wir den Dateinamen und die Variablen. Auf diese Weise können Sie das Ansible-Projekt in Form von regulären yml-Dateien beibehalten, anstatt es in Python-Code zu beschreiben.

Auch in Ansible über * extra_vars * wird der Name des Blockgeräts, der Status des Tickets sowie callback_url verwendet, in dem der Ausgabeschlüssel verkabelt ist - er wird für den Rückruf in HTTP verwendet.

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

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

Das Ergebnis der Playbooks erhalten wir mit Callaback (s). Es gibt zwei Arten:

• Ansible Callback Plugin , es liefert Daten über die Ergebnisse eines Playbooks. Es beschreibt die Aufgaben, die gestartet, erfolgreich oder erfolglos ausgeführt wurden. Dieser Rückruf wird am Ende des Playbooks aufgerufen.
• HTTP-Rückruf, um Informationen beim Abspielen eines Playbooks abzurufen. In Ansible führen wir eine POST / GET-Anforderung an die Seite unserer Anwendung aus.

Über HTTP-Rückrufe werden Variablen übertragen, 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 durch HTTP-Rückruf hinterlassen wir Kommentare und ändern den Ticketstatus.


Wie viele Aufgaben derselben Art legen wir sie in einer separaten gemeinsamen Datei ab und fügen sie bei Bedarf hinzu, um sie nicht ständig in Spielbüchern zu wiederholen. Hier wird die Rückruf-URL angezeigt, in der der Ausgabeschlüssel und der Hostname geschützt sind. Wenn Ansible diese POST-Anforderung ausführt, erkennt der Bot, dass sie Teil eines solchen Vorfalls war.

Und hier ist ein Beispiel aus einem Playbook, in dem wir eine Diskette von einem MD-Gerät angezeigt 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. Außerdem speichert die Variable mdam_data die Liste der md-Geräte, von denen die Festplatte gelöscht wurde, und den parted_-Speicherauszug der partierten Partition in parted_info.

Wenn der Techniker eine neue Festplatte einlegt, können wir diese Variablen verwenden, um den Partitionsspeicherauszug wiederherzustellen und die Festplatte in die MD-Geräte einzulegen, von denen sie gelöscht wurde.

Ansible Check-Modus

Das Einschalten der Automatisierung war beängstigend. Aus diesem Grund haben wir beschlossen, alle Playbooks im Modus auszuführen
Trockenlauf , bei dem Ansible keine Aktionen auf den Servern ausführt, sondern nur emuliert.

Ein solcher Start wird über ein separates Rückrufmodul ausgeführt, und das Ergebnis des Playbooks wird in Jira als Kommentar gespeichert.



Erstens erlaubte es, die Arbeit des Bots und der Spielbücher zu validieren. Zweitens wurde das Vertrauen der Administratoren in den Bot erhöht.

Als wir die Validierung durchlaufen haben und festgestellt haben, dass Sie Ansible nicht nur im Trockenlaufmodus ausführen können, haben wir in Jira die Schaltfläche "Diskobot ausführen" aktiviert, um dasselbe Playbook mit denselben Variablen auf demselben Host, jedoch im normalen Modus, zu starten.

Darüber hinaus wird die Schaltfläche verwendet, um das Playbook im Falle eines Fehlers neu zu starten.

Playbooks Struktur

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

Erstens ist es viel einfacher, einen Eintrag zu arrangieren.
Zweitens ist es in einigen Fällen einfach notwendig.

Wenn Sie beispielsweise eine Systemfestplatte ersetzen, müssen Sie zuerst zum Bereitstellungssystem wechseln, eine Aufgabe erstellen. Nach der korrekten Bereitstellung kann der Server über ssh aufgerufen werden, und Sie können die Anwendung darauf rollen. Wenn wir dies alles in einem Playbook tun würden, könnte Ansible es aufgrund der Unzugänglichkeit des Hosts nicht ausführen.

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



Dies ist praktisch, da sofort klar ist, wo sich welche Aufgaben befinden. In main.yml, der Eingabe für die Ansible-Rolle, können wir nur den Ticketstatus oder allgemeine Aufgaben angeben, die für alle erforderlich sind, z. B. das Übergeben der Identifikation oder das Empfangen eines Tokens.

Investigation.yml

Läuft für Tickets im Status "Untersuchung" und "Offen". Das Wichtigste für dieses Playbook ist der Name des Blockgeräts. Diese Informationen sind nicht immer verfügbar.

Um dies zu erreichen, analysieren wir die Jira-Zusammenfassung, den letzten Wert des Zabbix-Triggers. Es kann den Namen des Blockgeräts enthalten - zum Glück. Oder es enthält einen Mount-Punkt. Dann müssen Sie zum Server gehen, das gewünschte Laufwerk analysieren und berechnen. Ein Trigger kann auch eine SCSI-Adresse oder andere Informationen übertragen. 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 Informationen über den Typ und die Größe der Festplatte, um die Felder in Jira auszufüllen. Wir entfernen auch Informationen über den Hersteller, das Modell, die Firmware, die ID und SMART und fügen all dies in einen Kommentar im Jira-Ticket ein. Der Administrator und der Techniker müssen nicht mehr nach diesen Daten suchen. :) :)

prepare2change.yml

Die Ausgabe der Platte aus der Rotation, Vorbereitung für den Austausch. Die schwierigste und entscheidende Phase. Hier können Sie die Anwendung stoppen, wenn sie nicht gestoppt werden kann. Oder ziehen Sie eine Festplatte heraus, die nicht über genügend Replikate verfügt und sich dadurch auf die Benutzer auswirkt, und verlieren Sie einige Daten. Hier haben wir die meisten Überprüfungen und Benachrichtigungen im Chat.

Im einfachsten Fall handelt es sich um das Entfernen eines Laufwerks aus HW / MD RAID.

In komplexeren Situationen (in unseren Speichersystemen) müssen Sie, wenn die Sicherung auf Anwendungsebene durchgeführt wird, mithilfe der API zur Anwendung wechseln, die Festplattenausgabe melden, sie deaktivieren und die Wiederherstellung starten.

Wir migrieren jetzt massiv in die Cloud . Wenn der Server trübe ist, greift Diskobot auf die Cloud-API zu und sagt, dass dies mit diesem Minion - dem Server, auf dem die Container ausgeführt werden - funktioniert. Er fragt, ob alle Container von diesem Minion migriert werden sollen. Gleichzeitig wird die Hintergrundbeleuchtung eingeschaltet, sodass der Techniker sofort sieht, welche herausgezogen werden muss.

geändert.yml

Nach dem Ersetzen einer Festplatte überprüfen wir zunächst deren Verfügbarkeit.

Ingenieure legen nicht immer neue Discs ein, daher haben wir eine Überprüfung auf SMART-Werte hinzugefügt, die uns zufrieden stellen.


Wenn das Laufwerk den Test nicht besteht, wird der Techniker über einen Austausch informiert. Wenn alles in Ordnung ist, wird die Hintergrundbeleuchtung ausgeschaltet, das Markup wird angewendet und die Festplatte wird in Rotation eingelegt.

ready.yml

Der einfachste Fall: Überprüfen der HW / SW-Raid-Synchronisation oder Beenden der Datensynchronisation in der Anwendung.

Anwendungs-API

Ich habe mehrmals erwähnt, dass der Bot häufig auf die Anwendungs-APIs zugreift. Natürlich hatten nicht alle Anwendungen die notwendigen Methoden, deshalb musste ich sie verfeinern. Hier sind die wichtigsten Methoden, die wir verwenden:

• Status Der Status eines Clusters oder einer Festplatte, um zu verstehen, ob es möglich ist, damit zu arbeiten.
  
• Start / Stopp. Aktivierung-Deaktivierung der Festplatte;
  
• Migrieren / Wiederherstellen. Migration und Datenwiederherstellung während und nach dem Austausch.
  

Von Ansible gelernte Lektionen

Ich liebe Ansible wirklich. Aber oft, wenn ich mir verschiedene OpenSource-Projekte anschaue und sehe, wie Leute Playbooks schreiben, bekomme ich ein bisschen Angst. Komplexes logisches Geflecht aus Wann / Schleife, mangelnde Flexibilität und Idempotenz aufgrund der häufigen Verwendung von Shell / Befehl.

Wir haben uns entschlossen, alles so weit wie möglich zu vereinfachen und die Ansible-Modularität zu nutzen. Auf der höchsten Ebene befinden sich Playbooks. Sie können von jedem Administrator geschrieben werden, einem Drittentwickler, der Ansible ein wenig kennt.

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

Wenn es schwierig ist, eine Logik in Playbooks zu implementieren, platzieren wir sie in einem Ansible-Modul oder -Filter. Skripte können sowohl in Python als auch in einer anderen Sprache geschrieben werden.

Sie sind einfach und schnell zu schreiben. Beispielsweise besteht das Plattenhervorhebungsmodul, dessen Verwendungsbeispiel oben angegeben ist, 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 die Hardware- und Software-RAIDs, die die entsprechenden Anforderungen ausführen.



Die größten Stärken von Ansible sind die Einfachheit und die verständlichen Spielbücher. Ich glaube, dass Sie dies verwenden müssen und keine beängstigenden Yaml-Dateien und eine große Anzahl von Bedingungen, Shell-Code und Schleifen generieren müssen.

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

• Playbook_executor und im Allgemeinen Playbook können nicht abgelaufen werden. Es gibt eine Zeitüberschreitung in der SSH-Sitzung, aber keine Zeitüberschreitung im Playbook. Wenn wir versuchen, die Bereitstellung eines Laufwerks aufzuheben, das noch nicht im System vorhanden ist, wird das Playbook unbegrenzt ausgeführt. Daher mussten wir es in einem separaten Wrapper einpacken und nach Zeitüberschreitung beenden.
  
• Ansible ist gegabelt, daher ist seine API nicht threadsicher. Wir starten alle unsere Playbooks und Single-Threaded.
  

Dadurch konnten wir den Austausch von ca. 80% der Laufwerke automatisieren. Im Allgemeinen hat sich die Ersatzrate verdoppelt. Heute betrachtet der Administrator nur den Vorfall und entscheidet, ob die Festplatte geändert werden soll oder nicht, und macht dann einen Klick.

Jetzt stellen wir uns jedoch einem anderen Problem: Einige neue Administratoren wissen nicht, wie sie Laufwerke wechseln sollen. :) :)