Hallo zusammen. Ich arbeite als leitender Systemadministrator bei OK und bin für den stabilen Betrieb des Portals verantwortlich. Ich möchte Ihnen erzählen, wie wir den Prozess des automatischen Festplattentausches aufgebaut haben, und wie wir dann den Administrator aus diesem Prozess herausgenommen und durch einen Bot ersetzt haben.
Dieser Artikel ist eine Art Transkription auf der HighLoad+ 2018
Aufbau eines Prozesses zum Festplattentausch
Zunächst einige Zahlen
OK ist ein riesiger Dienst, den Millionen von Menschen nutzen. Er wird von etwa 7.000 Servern betrieben, die in 4 verschiedenen Rechenzentren stehen. In diesen Servern befinden sich über 70.000 Festplatten. Wenn man sie übereinanderstapelt, ergibt das einen Turm von mehr als 1 km Höhe.
Festplatten sind die Komponenten des Servers, die am häufigsten ausfallen. Bei diesem Volumen müssen wir etwa 30 Festplatten pro Woche austauschen, was diese Prozedur zu einer eher unangenehmen Routine gemacht hat.
Vorfälle
In unserem Unternehmen haben wir ein umfassendes Incident-Management-System implementiert. Jedes Ereignis wird in Jira dokumentiert, anschließend gelöst und analysiert. Wenn ein Vorfall Auswirkungen auf die Nutzer hat, kommen wir zusammen, um zu überlegen, wie wir schneller reagieren können, wie wir die Auswirkungen reduzieren und natürlich, wie wir ein erneutes Eintreten verhindern können.
Speicher ist da keine Ausnahme. Ihr Zustand wird von Zabbix überwacht. Wir analysieren die Nachrichten im Syslog auf Schreib-/Lesefehler, überprüfen den Zustand von HW/SW-RAIDs und überwachen SMART. Für SSDs berechnen wir den Verschleiß.
Wie sich die Festplatten früher verändert haben
Wenn in Zabbix ein Trigger ausgelöst wird, wird in Jira ein Ticket erstellt und automatisch den zuständigen Ingenieuren im Rechenzentrum zugewiesen. Das gilt für alle HW-Vorfälle, also solche, die physische Arbeiten am Equipment im Rechenzentrum erfordern.
Ein Rechenzentrumsingenieur ist verantwortlich für die Hardware, einschließlich der Installation, Wartung und Demontage von Servern. Sobald ein Ticket eingeht, beginnt der Ingenieur mit der Arbeit. In den Festplattenschächten tauscht er die Laufwerke eigenständig aus. Sollte er jedoch keinen Zugang zum erforderlichen Gerät haben, wendet sich der Ingenieur an die diensthabenden Systemadministratoren um Unterstützung. Zuerst muss das Laufwerk aus der Rotation genommen werden. Dazu sind die notwendigen Änderungen am Server vorzunehmen, die Anwendungen anzuhalten und das Laufwerk zu demontieren.
Der diensthabende Systemadministrator ist während seiner Schicht für den reibungslosen Betrieb des gesamten Portals verantwortlich. Er untersucht Vorfälle, führt Reparaturen durch und unterstützt Entwickler bei kleinen Aufgaben. Allerdings kümmert er sich nicht um Festplatten.
Früher kommunizierten die Rechenzentrumsingenieure im Chat mit dem Systemadministrator. Die Ingenieure schickten Links zu Jira-Tickets, und der Administrator durchguckte diese und führte ein Protokoll in einem Notizbuch. Für solche Aufgaben sind Chats jedoch unpraktisch: Die Informationen sind unstrukturiert und gehen schnell verloren. Zudem könnte der Administrator einfach vom Computer weggehen und eine Zeit lang nicht auf Anfragen antworten, während der Ingenieur mit einer Reihe von Festplatten am Server steht und wartet.
Das Schlimmste war jedoch, dass die Administratoren das Gesamte nicht überblickten: welche Festplattenvorfälle es gab und wo potenziell Probleme auftreten könnten. Das liegt daran, dass wir alle HW-Vorfälle den Ingenieuren übergeben. Ja, es wäre möglich gewesen, alle Vorfälle auf dem Dashboard des Administrators darzustellen. Aber es gibt so viele, dass der Administrator nur für einige von ihnen herangezogen wird.
Darüber hinaus konnte der Ingenieur die Prioritäten nicht korrekt setzen, da er nichts über den Zweck der spezifischen Server und die Verteilung der Informationen auf den Speichergeräten wusste.
Neues Verfahren zur Ersatzbeschaffung
Das erste, was wir getan haben, war, alle Datenträgervorfälle in einen eigenen Typ "HW-Disk" zu verschieben und Felder für "Blockgerätename", "Größe" und "Festplattentyp" hinzuzufügen. So bleibt diese Information im Ticket erhalten, und es ist nicht nötig, sie ständig im Chat auszutauschen.
Außerdem haben wir vereinbart, dass wir im Rahmen eines Vorfalls nur eine Festplatte wechseln. Dies hat den Automatisierungsprozess, die Statistiksammlung und die Arbeit erheblich vereinfacht.
Darüber hinaus haben wir das 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, in den Kalender zu schauen und zu suchen. Genau dieses Feld hat es ermöglicht, Tickets auf dem Dashboard des Administrators anzuzeigen, bei denen er möglicherweise Unterstützung benötigt.
Um sicherzustellen, dass alle Beteiligten von den Neuerungen profitieren, haben wir Filter und Dashboards erstellt und diese den Teams vorgestellt. Wenn die Leute die Änderungen verstehen, distanzieren sie sich nicht von ihnen, als wären sie überflüssig. Für einen Ingenieur ist es wichtig, die Rack-Nummer zu kennen, in der der Server untergebracht ist, sowie die Größe und den Typ der Festplatte. Ein Administrator muss in erster Linie verstehen, was für eine Gruppe von Servern es ist und welche Auswirkungen ein Festplattentausch haben könnte.
Die Verfügbarkeit von Feldern und deren Anzeige ist praktisch, aber sie haben uns nicht von der Notwendigkeit befreit, Chats zu nutzen. Dafür musste der Arbeitsablauf angepasst werden.
Früher war es so:
Heute arbeiten die Ingenieure weiterhin so, wenn sie keine Unterstützung vom Administrator benötigen.
Das erste, was wir gemacht haben, war die Einführung eines neuen Status Investigate. In diesem Status befindet sich das Ticket, wenn der Ingenieur noch nicht entschieden hat, ob er Unterstützung vom Administrator benötigt oder nicht. Über diesen Status kann der Ingenieur das Ticket an den Administrator übergeben. Außerdem kennzeichnen wir mit diesem Status Tickets, bei denen eine Festplattenersetzung erforderlich ist, aber die Festplatte am Standort nicht vorhanden ist. Dies geschieht beispielsweise bei CDN und Remote-Standorten.
Wir haben auch einen Status hinzugefügt Bereit. Der Ticket wird nach dem Austausch der Festplatte übertragen. Das bedeutet, dass bereits alles erledigt ist, aber auf dem Server wird HW/SW-RAID synchronisiert. Dies kann ziemlich viel Zeit in Anspruch nehmen.
Wenn ein Administrator in den Prozess involviert ist, wird das Schema etwas komplizierter.
Aus dem Status Öffnen kann das Ticket sowohl von einem Systemadministrator als auch von einem Ingenieur übertragen werden. Im Status In Bearbeitung nimmt der Administrator die Festplatte aus der Rotation, damit der Ingenieur sie einfach herausnehmen kann: er aktiviert die Beleuchtung, mountet die Festplatte ab, stoppt Anwendungen, abhängig von der spezifischen Servergruppe.
Anschließend wird das Ticket in den Status Bereit zum Ändern: dies signalisiert dem Ingenieur, dass die Festplatte entnommen 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 vom Administrator eingetragen.
Nach dem Austausch der Festplatte wird das Ticket in den Status Geändert. Es wird überprüft, dass die richtige Festplatte eingesetzt wurde, die Partitionierung erfolgt, die Anwendung wird gestartet und einige Aufgaben zur Datenwiederherstellung durchgeführt. Das Ticket kann auch in den Status Bereitübertragen werden, in diesem Fall bleibt der Administrator verantwortlich, da er die Festplatte in die Rotation eingeführt hat. Das vollständige Schema sieht folgendermaßen aus.
Die Hinzufügung neuer Felder hat uns das Leben erheblich erleichtert. Die Mitarbeiter arbeiten jetzt mit strukturierten Informationen, und es ist klar, was und in welchem Schritt zu tun ist. Die Prioritäten sind viel relevanter geworden, da sie jetzt vom Administrator festgelegt werden.
Die Notwendigkeit für Chats ist weggefallen. Natürlich kann der Administrator dem Ingenieur schreiben: „Hier muss schneller getauscht werden“ oder „Es wird Abend, schaffst du es noch zu ersetzen?“. Aber wir kommunizieren nicht mehr täglich in Chats über diese Themen.
Die Festplatten werden jetzt in Gruppen gewechselt. Wenn der Administrator etwas früher zur Arbeit kommt, hat er Zeit, und es ist noch nichts passiert, kann er eine Reihe von Servern für den Tausch vorbereiten: Felder setzen, Festplatten aus dem Austausch nehmen und die Aufgabe an den Ingenieur übergeben. Der Ingenieur kommt etwas später ins Rechenzentrum, sieht die Aufgabe, holt die benötigten Speichermedien aus dem Lager und tauscht sie sofort aus. Dadurch hat sich die Geschwindigkeit des Austauschs erhöht.
Erfahrungen aus dem Aufbau von Workflows
- Beim Aufbau von Verfahren müssen Informationen aus verschiedenen Quellen gesammelt werden.
Einige unserer Administratoren wussten nicht, dass Ingenieure die Festplatten selbstständig wechseln. Einige dachten, dass die Ingenieure die Synchronisierung des MD RAID überwachen, obwohl nicht jeder von ihnen die notwendige Zugriffsberechtigung hatte. Einige leitenden Ingenieure kümmerten sich dagegen darum, jedoch nicht immer, da der Prozess nirgendwo dokumentiert war. - Der Ablauf sollte einfach und verständlich sein.
Es ist für Menschen schwierig, sich viele Schritte zu merken. Die wichtigsten benachbarten Status in Jira sollten auf den Hauptbildschirm gebracht werden. Man kann sie umbenennen, zum Beispiel nennen wir 'In Progress' 'Bereit zum Wechseln'. Die anderen Status können in ein Dropdown-Menü versteckt werden, damit sie nicht im Weg sind. Aber es ist besser, die Leute nicht einzuschränken, sondern ihnen die Möglichkeit zu geben, den Übergang zu gestalten.
Erklären Sie den Wert der Neuerungen. Wenn Menschen verstehen, nehmen sie neue Verfahren besser an. Für uns war es sehr wichtig, dass die Leute nicht einfach durch den Prozess klicken, sondern diesem folgen. Darauf haben wir dann die Automatisierung aufgebaut. - Warten, analysieren, verstehen.
Der Aufbau der Verfahren, die technische Umsetzung sowie die Meetings und Diskussionen nahmen bei uns etwa einen Monat in Anspruch. Die Implementierung dauerte jedoch über drei Monate. Ich konnte beobachten, wie die Mitarbeiter langsam begannen, die Neuerung zu nutzen. In den Anfangsphasen gab es viel Negatives. Dies hing jedoch nicht von dem Verfahren oder seiner technischen Umsetzung ab. Zum Beispiel verwendete ein Administrator nicht Jira, sondern ein Jira-Plugin in Confluence, was ihm den Zugriff auf einige Funktionen verwehrte. Nachdem wir ihm Jira gezeigt hatten, stieg seine Produktivität sowohl bei allgemeinen Aufgaben als auch bei Festplattenwechseln erheblich an.
Automatisierung des Festplattenwechsels
Wir haben uns mehrere Male der Automatisierung des Festplattenwechsels genähert. Wir hatten bereits einige Skripte und Entwicklungen, aber alle arbeiteten entweder im interaktiven oder manuellen Modus und verlangten einen separaten Start. Erst nach der Einführung des neuen Verfahrens wurde uns klar, dass genau dieses uns gefehlt hatte.
Da der Prozess der Aktualisierung jetzt in Phasen unterteilt ist, in denen jeweils ein Verantwortlicher und eine Liste von Aufgaben festgelegt sind, können wir die Automatisierung schrittweise einführen, anstatt alles auf einmal zu implementieren. Der einfachste Schritt – das Ready (Überprüfung der RAID/Daten-Synchronisierung) – kann leicht an einen Bot delegiert werden. Wenn der Bot ein wenig trainiert ist, kann ihm eine verantwortungsvollere Aufgabe übertragen werden – die Einführung der Festplatte in den Rotationsprozess usw.
Tierpark der Setups
Bevor wir über den Bot sprechen, machen wir einen kurzen Exkurs in unseren Tierpark der Installationen. Dieser ist in erster Linie durch die gigantische Größe unserer Infrastruktur bedingt. Zweitens versuchen wir, für jeden Dienst eine optimale Hardwarekonfiguration auszuwählen. Wir haben etwa 20 Modelle von Hardware-RAID, hauptsächlich von LSI und Adaptec, aber auch HP und DELL unterschiedlicher Versionen sind vorhanden. Jeder RAID-Controller verfügt über eine eigene Verwaltungssoftware. Der Befehlssatz und die Ausgabe können von Version zu Version bei jedem RAID-Controller variieren. In Fällen, in denen kein HW-RAID verwendet wird, kann mdraid zum Einsatz kommen.
Fast alle neuen Installationen führen wir ohne Festplattenspiegelung durch. Wir verzichten zunehmend auf hardware- und softwarebasierte RAID-Systeme, da wir unsere Systeme auf der Ebene der Rechenzentren und nicht auf der Ebene der Server absichern. Natürlich gibt es jedoch viele Legacy-Server, die weiterhin unterstützt werden müssen.
An manchen Stellen werden Festplatten in RAID-Controllern als Raw-Geräte durchgereicht, andernorts wird JBOD verwendet. Es gibt Konfigurationen mit nur einer Systemfestplatte im Server, und wenn diese ersetzt werden muss, ist es notwendig, den Server neu aufzusetzen, einschließlich des Betriebssystems und der Anwendungen, wobei dieselben Versionen verwendet werden müssen. Anschließend müssen Konfigurationsdateien hinzugefügt und Anwendungen gestartet werden. Außerdem gibt es viele Gruppen von Servern, bei denen die Absicherung nicht auf der Ebene des Speicher-Subsystems erfolgt, sondern direkt in den Anwendungen selbst.
Insgesamt haben wir über 400 einzigartige Gruppen von Servern, auf denen etwa 100 verschiedene Anwendungen laufen. Um eine so große Anzahl an Varianten abzudecken, benötigten wir ein multifunktionales Automatisierungstool. Idealerweise mit einer einfachen DSL, sodass 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 nötig und der Start war schnell. Zudem ist es in Python geschrieben, das im Team als Standard akzeptiert ist.
Übersicht
Lassen Sie uns die allgemeine Automatisierungsschemata anhand eines Vorfalls betrachten. Zabbix erkennt, dass die Festplatte sdb ausgefallen ist, ein Trigger wird aktiviert und ein Ticket in Jira wird erstellt. Der Administrator schaut es sich an, stellt fest, dass es sich nicht um ein Duplikat oder einen False Positive handelt, also muss die Festplatte getauscht werden, und er versetzt das Ticket in den Status In Bearbeitung.
Die Anwendung DiskoBot, die in Python geschrieben ist, fragt Jira regelmäßig nach neuen Tickets ab. Sie bemerkt, dass ein neues Ticket im Status In Bearbeitung hinzugekommen ist, und aktiviert den entsprechenden Thread, der das Playbook in Ansible ausführt (dies geschieht für jeden Status in Jira). In diesem Fall wird Prepare2change gestartet.
Ansible kommuniziert mit dem Host, nimmt die Festplatte aus der Rotation und berichtet den Status der Anwendung über Callbacks.
Basierend auf den Ergebnissen versetzt der Bot das Ticket automatisch in den Status Bereit zum Wechseln. Der Ingenieur erhält eine Benachrichtigung und macht sich auf den Weg, um die Festplatte zu wechseln, danach versetzt er das Ticket in den Status Gewechselt.
Gemäß dem oben beschriebenen Schema gelangt das Ticket zurück zum Bot, der ein anderes Playbook startet, auf den Host geht und die Festplatte in den Rotationsprozess eingibt. Der Bot schließt das Ticket. Hurra!
Nun lassen Sie uns über einige Komponenten des Systems sprechen.
Diskobot
Diese Anwendung ist in Python geschrieben. Sie wählt Tickets aus Jira gemäß JQL aus. Abhängig vom Status des Tickets gelangt es zu dem entsprechenden Bearbeiter, der seinerseits das passende Ansible-Playbook gemäß dem Status ausführt.
JQL und Abfrageintervalle sind in der Konfigurationsdatei der Anwendung 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
Zum Beispiel werden unter den Tickets im Status In Progress 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 wird benötigt, damit der Ingenieur weiß, welcher Festplattengröße erforderlich ist.
Und unter den Tickets mit dem Status Ready werden Tickets mit dem Label dbot_ignore herausgefiltert. Übrigens verwenden wir Jira-Labels sowohl für solche Filterungen als auch zur Kennzeichnung von Duplikaten von Tickets und zur Sammlung von Statistiken.
Im Falle eines Fehlers im Playbook weist Jira das Label dbot_failed zu, um später die Probleme zu klären.
Interaktion mit Ansible
Die Anwendung interagiert mit Ansible über . Im playbook_executor übergeben wir den Dateinamen und eine Sammlung von Variablen. Damit kann das Ansible-Projekt in Form von standardmäßigen yml-Dateien gehalten werden, anstatt es in Python-Code zu beschreiben.
Auch in Ansible werden über *extra_vars* der Name des Blockgeräts, der Status des Tickets sowie die callback_url übergeben, in der der Issue-Key eingebettet ist — dieser wird für den HTTP-Callback verwendet.
Für jeden Lauf wird ein temporäres Inventory erstellt, das aus einem Host und einer Gruppe besteht, in die dieser Host gehört, um die group_vars anzuwenden.
Hier ist ein Beispiel für eine Aufgabe, die den HTTP-Callback implementiert.
Die Ergebnisse der Ausführung von Playbooks erhalten wir über Callback(s). Diese sind von zwei Arten:
- , es liefert Daten zu den Ergebnissen der Playbook-Ausführung. Darin sind die Aufgaben beschrieben, die gestartet wurden, erfolgreich oder nicht erfolgreich abgeschlossen wurden. Dieser Callback wird am Ende der Playbook-Ausführung aufgerufen.
- HTTP-Callback zur Informationsbeschaffung während der Playbook-Ausführung. Im Ansible-Task führen wir eine POST/GET-Anfrage an unsere Anwendung aus.
Über HTTP-Callbacks werden Variablen übermittelt, die während der Ausführung des Playbooks festgelegt wurden und die wir für zukünftige Durchläufe speichern und verwenden möchten. Diese Daten speichern wir in SQLite.
Auch über HTTP-Callbacks hinterlassen wir 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 bei vielen ähnlichen Aufgaben haben wir diese in eine separate Common-Datei ausgelagert und binden sie bei Bedarf ein, um sie nicht ständig im Playbook zu wiederholen. Hier kommt die Callback-URL ins Spiel, in der der Issue-Key und der Hostname enthalten sind. Wenn Ansible diese POST-Anfrage ausführt, versteht der Bot, dass sie im Rahmen eines bestimmten Vorfalls eingegangen ist.
Hier ein Beispiel aus dem Playbook, in dem wir eine Festplatte aus dem MD-Gerät entfernt 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 zur Änderung“ und fügt einen Kommentar hinzu. Außerdem wird in der Variablen mdam_data eine 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 Partitiondump wiederherzustellen und die Festplatte in die MD-Geräte zu bringen, aus denen sie entfernt wurde.
Ansible-Checkmodus
Die Automatisierung zu aktivieren, war beängstigend. Daher haben wir entschieden, alle Playbooks im Modus
, in dem Ansible auf den Servern keine Aktionen ausführt, sondern diese nur emuliert.
Dieser Start wird über ein separates Callback-Modul abgewickelt, und das Ergebnis der Ausführung des Playbooks wird als Kommentar in Jira gespeichert.
Einerseits hat dies die Funktionalität des Bots und der Playbooks validiert. Andererseits hat es das Vertrauen der Administratoren in den Bot gestärkt.
Nachdem wir die Validierung abgeschlossen hatten und feststellten, dass Ansible nicht nur im Dry-Run-Modus gestartet werden kann, haben wir in Jira einen Button 'Run Diskobot' hinzugefügt, um dasselbe Playbook mit denselben Variablen auf demselben Host im normalen Modus auszuführen.
Zudem wird der Button verwendet, um das Playbook im Falle eines Fehlers erneut zu starten.
Struktur der Playbooks
Ich habe bereits erwähnt, dass der Bot je nach Status des Jira-Tickets unterschiedliche Playbooks ausführt.
Einerseits erleichtert das den Zugang erheblich.
Andererseits ist es in einigen Fällen einfach notwendig.
Wenn beispielsweise die Systemfestplatte ersetzt werden muss, sollte man zuerst in das Bereitstellungssystem gehen, eine Aufgabe erstellen, und nach erfolgreicher Bereitstellung wird der Server über SSH verfügbar sein, sodass man die Anwendung installieren kann. Wenn wir all dies in einem einzigen Playbook machen würden, könnte Ansible es aufgrund der Nichterreichbarkeit des Hosts nicht ausführen.
Wir verwenden Ansible-Rollen für jede Gruppe von Servern. Hier sieht man, wie die Playbooks in einer von ihnen organisiert sind.
Das ist praktisch, weil sofort klar ist, wo welche Aufgaben platziert sind. In main.yml, das als Einstieg für die Ansible-Rolle fungiert, kann es einfach einen Include je nach Ticketstatus oder allgemeine Aufgaben geben, die für alle notwendig sind, wie z.B. die Identifikation oder das Abrufen eines Tokens.
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 dies zu erreichen, analysieren wir die Jira-Zusammenfassung sowie den letzten Wert des Zabbix-Triggers. Dort könnte der Name des Blockgeräts zu finden sein – Glück gehabt. Alternativ kann der Mount-Punkt angegeben sein, dann müssen wir zum Server gehen, den Inhalt parsen und die benötigte Festplatte ermitteln. Zudem kann der Trigger die SCSI-Adresse oder andere Informationen übermitteln. Manchmal gibt es jedoch keine Hinweise, und wir müssen alles analysieren.
Sobald wir den Namen des Blockgeräts ermittelt haben, sammeln wir Informationen über den Typ und die Größe der Festplatte, um die entsprechenden Felder in Jira auszufüllen. Außerdem nehmen wir Informationen über den Anbieter, das Modell, die Firmware, die ID, SMART ab und fügen alles in den Kommentar im Jira-Ticket ein. Der Administrator und der Ingenieur müssen jetzt nicht mehr nach diesen Daten suchen. 🙂
prepare2change.yml
Auswurf der Festplatte aus der Rotation, Vorbereitung auf den Austausch. Der schwierigste, verantwortungsvollste Schritt. Hier kann man die Anwendung anhalten, auch wenn dies nicht möglich sein sollte. Oder man zieht die Festplatte, bei der es an Replikaten mangelte, und beeinträchtigt damit die Nutzer oder verliert Daten. Hier haben wir die meisten Prüfungen und Benachrichtigungen im Chat.
Im einfachsten Fall geht es um das Entfernen der Festplatte aus dem HW/MD RAID.
In komplexeren Situationen (in unseren Speichersystemen), in denen die Sicherung auf Anwendungsebene erfolgt, muss man über die API in die Anwendung gehen, den Laufwerksauswurf melden, es deaktivieren und die Wiederherstellung starten.
Wir migrieren derzeit massenhaft in , und wenn der Server cloudbasiert ist, kontaktiert Diskobot die API der Cloud, teilt mit, dass er mit diesem Minion — dem Server, auf dem die Container laufen — arbeiten möchte, und bittet um „migriere alle Container von diesem Minion“. Gleichzeitig wird die Laufwerksbeleuchtung aktiviert, damit der Ingenieur sofort sieht, welches Laufwerk entnommen werden muss.
changed.yml
Nach dem Austausch des Laufwerks überprüfen wir zunächst dessen Verfügbarkeit.
Ingenieure montieren nicht immer neue Laufwerke, deshalb haben wir eine Überprüfung der für uns akzeptablen SMART-Werte hinzugefügt.
Welche Attribute wir betrachtenReallocated Sectors Count (5) < 100
Current Pending Sector Count (107) == 0
Wenn das Laufwerk die Prüfung nicht besteht, wird der Ingenieur über den erforderlichen Austausch informiert. Wenn alles in Ordnung ist, wird die Beleuchtung ausgeschaltet, die Markierung wird erstellt und das Laufwerk in den Betrieb aufgenommen.
ready.yml
Der einfachste Fall: Überprüfung der Synchronisation von HW/SW-Raid oder das Ende der Datensynchronisation in der Anwendung.
API der Anwendungen
Ich habe bereits mehrfach erwähnt, dass der Bot häufig auf die API von Anwendungen zugreift. Natürlich hatten nicht alle Anwendungen die erforderlichen Methoden, daher mussten wir diese anpassen. Hier sind die wichtigsten Methoden, die wir verwenden:
- Status. Der Status des Clusters oder der Festplatte, um zu verstehen, ob man damit arbeiten kann;
- Start/Stopp. Aktivierung und Deaktivierung der Festplatte;
- Migrieren/Wiederherstellen. Migration und Wiederherstellung von Daten während und nach dem Austausch.
Erfahrungen mit Ansible
Ich liebe Ansible sehr. Aber oft, wenn ich mir verschiedene Open-Source-Projekte ansehe und sehe, wie Leute Playbooks schreiben, macht mich das ein wenig nervös. Komplexe logische Verflechtungen aus when/loop, fehlende Flexibilität und Idempotenz aufgrund der häufigen Verwendung von shell/command.
Wir haben uns entschieden, alles so einfach wie möglich zu halten, indem wir den Vorteil von Ansible - die Modularität - nutzen. Auf der obersten Ebene befinden sich die Playbooks, die von jedem Administrator oder externen Entwickler, der ein wenig Ansible kennt, geschrieben werden können.
- name: Disk blinken
become: True
register: locate_action
disk_locate:
locate: '{{ locate }}'
devname: '{{ devname }}'
ids: '{{ locate_ids | default(pd_id) | default(omit) }}'
Wenn eine Logik schwer in Playbooks umzusetzen ist, ziehen wir es vor, sie in ein Ansible-Modul oder einen Filter auszulagern. Die Skripte können sowohl in Python als auch in jeder anderen Programmiersprache geschrieben werden.
Diese sind einfach und schnell zu schreiben. Das Beispiel für das Disk-Highlighting-Modul, das oben beschrieben ist, umfasst 265 Zeilen.
Auf der untersten Ebene befindet sich die Bibliothek. Für dieses Projekt haben wir eine eigene Anwendung geschrieben, die eine Art Abstraktion über die Hardware- und Software-RAID bildet, die die entsprechenden Anfragen bearbeitet.
Die stärksten Punkte von Ansible sind die Einfachheit und die klaren Playbooks. Ich denke, wir sollten das nutzen und keine unübersichtlichen YAML-Dateien mit einer Vielzahl von Bedingungen, Shell-Code und Schleifen generieren.
Wenn Sie unsere Erfahrungen mit der Ansible-API wiederholen möchten, beachten Sie bitte zwei Dinge:
- Dem Playbook_executor und dem Playbook selbst kann kein Timeout übergeben werden. Es gibt ein Timeout für SSH-Sitzungen, aber kein Timeout für das Playbook. Wenn wir versuchen, eine Disk zu unmounten, die im System nicht mehr existiert, wird das Playbook unendlich laufen, weshalb wir seinen Start in einen separaten Wrapper einbetten und nach Timeout beenden mussten.
- Ansible basiert auf Fork-Prozessen, weshalb seine API nicht thread-sicher ist. Wir führen alle unsere Playbooks in einem einzelnen Thread aus.
Dadurch ist es uns gelungen, fast 80 % der Festplatten automatisch zu ersetzen. Insgesamt hat sich die Geschwindigkeit des Austausches verdoppelt. Heute schaut der Administrator nur auf den Vorfall und entscheidet, ob die Festplatte gewechselt werden muss oder nicht, und führt dann einen Klick aus.
Jetzt stehen wir jedoch vor einem anderen Problem: Einige neue Administratoren wissen nicht, wie die Festplatten gewechselt werden. 🙂
Quelle: habr.com
