{"id":34841,"date":"2019-10-31T22:00:43","date_gmt":"2019-10-31T19:00:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible\/"},"modified":"2019-10-31T22:00:43","modified_gmt":"2019-10-31T19:00:43","slug":"avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible","title":{"rendered":"Automatisierung des Festplattentauschs mit Ansible","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Automatisierung des Festplattentauschs mit Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/c60a2326ab13e7766eafda3ae5ac39c5.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHallo zusammen. Ich arbeite als leitender Systemadministrator bei OK und bin f\u00fcr den stabilen Betrieb des Portals verantwortlich. Ich m\u00f6chte Ihnen erz\u00e4hlen, 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.<\/p>\n<p>Dieser Artikel ist eine Art Transkription <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/watch?v=5WhbG3FQveE&amp;list=FLKN7KW1sxju7fWJvKuyKxEQ\">eines Vortrags<\/a><\/noindex> auf der HighLoad+ 2018<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Aufbau eines Prozesses zum Festplattentausch<\/h2>\n<p><\/p>\n<h3>Zun\u00e4chst einige Zahlen<\/h3>\n<p>\nOK 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 \u00fcber 70.000 Festplatten. Wenn man sie \u00fcbereinanderstapelt, ergibt das einen Turm von mehr als 1 km H\u00f6he. <\/p>\n<p>Festplatten sind die Komponenten des Servers, die am h\u00e4ufigsten ausfallen. Bei diesem Volumen m\u00fcssen wir etwa 30 Festplatten pro Woche austauschen, was diese Prozedur zu einer eher unangenehmen Routine gemacht hat.<\/p>\n<p><img decoding=\"async\" alt=\"Automatisierung des Festplattentauschs mit Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/5e915e9077994efcc4e74a26fc6286fa.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Vorf\u00e4lle<\/h3>\n<p>\nIn unserem Unternehmen haben wir ein umfassendes Incident-Management-System implementiert. Jedes Ereignis wird in Jira dokumentiert, anschlie\u00dfend gel\u00f6st und analysiert. Wenn ein Vorfall Auswirkungen auf die Nutzer hat, kommen wir zusammen, um zu \u00fcberlegen, wie wir schneller reagieren k\u00f6nnen, wie wir die Auswirkungen reduzieren und nat\u00fcrlich, wie wir ein erneutes Eintreten verhindern k\u00f6nnen.<\/p>\n<p>Speicher ist da keine Ausnahme. Ihr Zustand wird von Zabbix \u00fcberwacht. Wir analysieren die Nachrichten im Syslog auf Schreib-\/Lesefehler, \u00fcberpr\u00fcfen den Zustand von HW\/SW-RAIDs und \u00fcberwachen SMART. F\u00fcr SSDs berechnen wir den Verschlei\u00df. <\/p>\n<h3>Wie sich die Festplatten fr\u00fcher ver\u00e4ndert haben<\/h3>\n<p>\nWenn in Zabbix ein Trigger ausgel\u00f6st wird, wird in Jira ein Ticket erstellt und automatisch den zust\u00e4ndigen Ingenieuren im Rechenzentrum zugewiesen. Das gilt f\u00fcr alle HW-Vorf\u00e4lle, also solche, die physische Arbeiten am Equipment im Rechenzentrum erfordern. <br \/>\nEin Rechenzentrumsingenieur ist verantwortlich f\u00fcr die Hardware, einschlie\u00dflich der Installation, Wartung und Demontage von Servern. Sobald ein Ticket eingeht, beginnt der Ingenieur mit der Arbeit. In den Festplattensch\u00e4chten tauscht er die Laufwerke eigenst\u00e4ndig aus. Sollte er jedoch keinen Zugang zum erforderlichen Ger\u00e4t haben, wendet sich der Ingenieur an die diensthabenden Systemadministratoren um Unterst\u00fctzung. Zuerst muss das Laufwerk aus der Rotation genommen werden. Dazu sind die notwendigen \u00c4nderungen am Server vorzunehmen, die Anwendungen anzuhalten und das Laufwerk zu demontieren.<\/p>\n<p>Der diensthabende Systemadministrator ist w\u00e4hrend seiner Schicht f\u00fcr den reibungslosen Betrieb des gesamten Portals verantwortlich. Er untersucht Vorf\u00e4lle, f\u00fchrt Reparaturen durch und unterst\u00fctzt Entwickler bei kleinen Aufgaben. Allerdings k\u00fcmmert er sich nicht um Festplatten.<\/p>\n<p>Fr\u00fcher kommunizierten die Rechenzentrumsingenieure im Chat mit dem Systemadministrator. Die Ingenieure schickten Links zu Jira-Tickets, und der Administrator durchguckte diese und f\u00fchrte ein Protokoll in einem Notizbuch. F\u00fcr solche Aufgaben sind Chats jedoch unpraktisch: Die Informationen sind unstrukturiert und gehen schnell verloren. Zudem k\u00f6nnte der Administrator einfach vom Computer weggehen und eine Zeit lang nicht auf Anfragen antworten, w\u00e4hrend der Ingenieur mit einer Reihe von Festplatten am Server steht und wartet.<\/p>\n<p>Das Schlimmste war jedoch, dass die Administratoren das Gesamte nicht \u00fcberblickten: welche Festplattenvorf\u00e4lle es gab und wo potenziell Probleme auftreten k\u00f6nnten. Das liegt daran, dass wir alle HW-Vorf\u00e4lle den Ingenieuren \u00fcbergeben. Ja, es w\u00e4re m\u00f6glich gewesen, alle Vorf\u00e4lle auf dem Dashboard des Administrators darzustellen. Aber es gibt so viele, dass der Administrator nur f\u00fcr einige von ihnen herangezogen wird.<\/p>\n<p>Dar\u00fcber hinaus konnte der Ingenieur die Priorit\u00e4ten nicht korrekt setzen, da er nichts \u00fcber den Zweck der spezifischen Server und die Verteilung der Informationen auf den Speicherger\u00e4ten wusste.<\/p>\n<h3>Neues Verfahren zur Ersatzbeschaffung<\/h3>\n<p>\nDas erste, was wir getan haben, war, alle Datentr\u00e4gervorf\u00e4lle in einen eigenen Typ \"HW-Disk\" zu verschieben und Felder f\u00fcr \"Blockger\u00e4tename\", \"Gr\u00f6\u00dfe\" und \"Festplattentyp\" hinzuzuf\u00fcgen. So bleibt diese Information im Ticket erhalten, und es ist nicht n\u00f6tig, sie st\u00e4ndig im Chat auszutauschen. <\/p>\n<p><img decoding=\"async\" alt=\"Automatisierung des Festplattentauschs mit Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/c4526bf668e31d90e0fbd061de44f1a7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nAu\u00dferdem haben wir vereinbart, dass wir im Rahmen eines Vorfalls nur eine Festplatte wechseln. Dies hat den Automatisierungsprozess, die Statistiksammlung und die Arbeit erheblich vereinfacht. <\/p>\n<p>Dar\u00fcber hinaus haben wir das Feld \"verantwortlicher Administrator\" hinzugef\u00fcgt. Dort wird automatisch der diensthabende Sysadmin eingetragen. Das ist sehr praktisch, denn jetzt sieht der Ingenieur immer, wer verantwortlich ist. Es ist nicht n\u00f6tig, in den Kalender zu schauen und zu suchen. Genau dieses Feld hat es erm\u00f6glicht, Tickets auf dem Dashboard des Administrators anzuzeigen, bei denen er m\u00f6glicherweise Unterst\u00fctzung ben\u00f6tigt.<\/p>\n<p><img decoding=\"async\" alt=\"Automatisierung des Festplattentauschs mit Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/5097e5dcca1fddd68d1e5f296c09f60a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nUm sicherzustellen, dass alle Beteiligten von den Neuerungen profitieren, haben wir Filter und Dashboards erstellt und diese den Teams vorgestellt. Wenn die Leute die \u00c4nderungen verstehen, distanzieren sie sich nicht von ihnen, als w\u00e4ren sie \u00fcberfl\u00fcssig. F\u00fcr einen Ingenieur ist es wichtig, die Rack-Nummer zu kennen, in der der Server untergebracht ist, sowie die Gr\u00f6\u00dfe und den Typ der Festplatte. Ein Administrator muss in erster Linie verstehen, was f\u00fcr eine Gruppe von Servern es ist und welche Auswirkungen ein Festplattentausch haben k\u00f6nnte.<\/p>\n<p>Die Verf\u00fcgbarkeit von Feldern und deren Anzeige ist praktisch, aber sie haben uns nicht von der Notwendigkeit befreit, Chats zu nutzen. Daf\u00fcr musste der Arbeitsablauf angepasst werden. <\/p>\n<p>Fr\u00fcher war es so:<\/p>\n<p><img decoding=\"async\" alt=\"Automatisierung des Festplattentauschs mit Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/2b79cdb7ec88b5ae3d2917ad8b164c6d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nHeute arbeiten die Ingenieure weiterhin so, wenn sie keine Unterst\u00fctzung vom Administrator ben\u00f6tigen.<\/p>\n<p>Das erste, was wir gemacht haben, war die Einf\u00fchrung eines neuen Status <b>Investigate<\/b>. In diesem Status befindet sich das Ticket, wenn der Ingenieur noch nicht entschieden hat, ob er Unterst\u00fctzung vom Administrator ben\u00f6tigt oder nicht. \u00dcber diesen Status kann der Ingenieur das Ticket an den Administrator \u00fcbergeben. Au\u00dferdem 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.<\/p>\n<p>Wir haben auch einen Status hinzugef\u00fcgt <b>Bereit<\/b>. Der Ticket wird nach dem Austausch der Festplatte \u00fcbertragen. Das bedeutet, dass bereits alles erledigt ist, aber auf dem Server wird HW\/SW-RAID synchronisiert. Dies kann ziemlich viel Zeit in Anspruch nehmen.<\/p>\n<p>Wenn ein Administrator in den Prozess involviert ist, wird das Schema etwas komplizierter.<\/p>\n<p><img decoding=\"async\" alt=\"Automatisierung des Festplattentauschs mit Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/5b6aacbb0d4049e62e7cb9ee28eb6498.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nAus dem Status <b>\u00d6ffnen<\/b> kann das Ticket sowohl von einem Systemadministrator als auch von einem Ingenieur \u00fcbertragen werden. Im Status <b>In Bearbeitung<\/b> 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\u00e4ngig von der spezifischen Servergruppe.<\/p>\n<p>Anschlie\u00dfend wird das Ticket in den Status <b>Bereit zum \u00c4ndern<\/b>: dies signalisiert dem Ingenieur, dass die Festplatte entnommen werden kann. Alle Felder in Jira sind bereits ausgef\u00fcllt, der Ingenieur wei\u00df, welcher Typ und welche Gr\u00f6\u00dfe die Festplatte hat. Diese Daten werden entweder im vorherigen Status automatisch oder vom Administrator eingetragen.<\/p>\n<p>Nach dem Austausch der Festplatte wird das Ticket in den Status <b>Ge\u00e4ndert<\/b>. Es wird \u00fcberpr\u00fcft, dass die richtige Festplatte eingesetzt wurde, die Partitionierung erfolgt, die Anwendung wird gestartet und einige Aufgaben zur Datenwiederherstellung durchgef\u00fchrt. Das Ticket kann auch in den Status <b>Bereit<\/b>\u00fcbertragen werden, in diesem Fall bleibt der Administrator verantwortlich, da er die Festplatte in die Rotation eingef\u00fchrt hat. Das vollst\u00e4ndige Schema sieht folgenderma\u00dfen aus.<\/p>\n<p><img decoding=\"async\" alt=\"Automatisierung des Festplattentauschs mit Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/32f8d488e2ff6a28a3341114b66de0a3.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nDie Hinzuf\u00fcgung 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\u00e4ten sind viel relevanter geworden, da sie jetzt vom Administrator festgelegt werden.<\/p>\n<p>Die Notwendigkeit f\u00fcr Chats ist weggefallen. Nat\u00fcrlich kann der Administrator dem Ingenieur schreiben: \u201eHier muss schneller getauscht werden\u201c oder \u201eEs wird Abend, schaffst du es noch zu ersetzen?\u201c. Aber wir kommunizieren nicht mehr t\u00e4glich in Chats \u00fcber diese Themen.<\/p>\n<p>Die Festplatten werden jetzt in Gruppen gewechselt. Wenn der Administrator etwas fr\u00fcher zur Arbeit kommt, hat er Zeit, und es ist noch nichts passiert, kann er eine Reihe von Servern f\u00fcr den Tausch vorbereiten: Felder setzen, Festplatten aus dem Austausch nehmen und die Aufgabe an den Ingenieur \u00fcbergeben. Der Ingenieur kommt etwas sp\u00e4ter ins Rechenzentrum, sieht die Aufgabe, holt die ben\u00f6tigten Speichermedien aus dem Lager und tauscht sie sofort aus. Dadurch hat sich die Geschwindigkeit des Austauschs erh\u00f6ht.<\/p>\n<h3>Erfahrungen aus dem Aufbau von Workflows<\/h3>\n<p><\/p>\n<ul>\n<li><b>Beim Aufbau von Verfahren m\u00fcssen Informationen aus verschiedenen Quellen gesammelt werden.<\/b><br \/>\nEinige unserer Administratoren wussten nicht, dass Ingenieure die Festplatten selbstst\u00e4ndig wechseln. Einige dachten, dass die Ingenieure die Synchronisierung des MD RAID \u00fcberwachen, obwohl nicht jeder von ihnen die notwendige Zugriffsberechtigung hatte. Einige leitenden Ingenieure k\u00fcmmerten sich dagegen darum, jedoch nicht immer, da der Prozess nirgendwo dokumentiert war.<\/li>\n<li><b>Der Ablauf sollte einfach und verst\u00e4ndlich sein.<\/b><br \/>\nEs ist f\u00fcr 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\u00f6nnen in ein Dropdown-Men\u00fc versteckt werden, damit sie nicht im Weg sind. Aber es ist besser, die Leute nicht einzuschr\u00e4nken, sondern ihnen die M\u00f6glichkeit zu geben, den \u00dcbergang zu gestalten.<br \/>\nErkl\u00e4ren Sie den Wert der Neuerungen. Wenn Menschen verstehen, nehmen sie neue Verfahren besser an. F\u00fcr uns war es sehr wichtig, dass die Leute nicht einfach durch den Prozess klicken, sondern diesem folgen. Darauf haben wir dann die Automatisierung aufgebaut.<\/li>\n<li><b>Warten, analysieren, verstehen.<\/b><br \/>\nDer Aufbau der Verfahren, die technische Umsetzung sowie die Meetings und Diskussionen nahmen bei uns etwa einen Monat in Anspruch. Die Implementierung dauerte jedoch \u00fcber 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\u00e4t sowohl bei allgemeinen Aufgaben als auch bei Festplattenwechseln erheblich an.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Automatisierung des Festplattenwechsels<\/h2>\n<p>\nWir haben uns mehrere Male der Automatisierung des Festplattenwechsels gen\u00e4hert. 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\u00fchrung des neuen Verfahrens wurde uns klar, dass genau dieses uns gefehlt hatte.<\/p>\n<p>Da der Prozess der Aktualisierung jetzt in Phasen unterteilt ist, in denen jeweils ein Verantwortlicher und eine Liste von Aufgaben festgelegt sind, k\u00f6nnen wir die Automatisierung schrittweise einf\u00fchren, anstatt alles auf einmal zu implementieren. Der einfachste Schritt \u2013 das Ready (\u00dcberpr\u00fcfung der RAID\/Daten-Synchronisierung) \u2013 kann leicht an einen Bot delegiert werden. Wenn der Bot ein wenig trainiert ist, kann ihm eine verantwortungsvollere Aufgabe \u00fcbertragen werden \u2013 die Einf\u00fchrung der Festplatte in den Rotationsprozess usw.<\/p>\n<h3>Tierpark der Setups<\/h3>\n<p>\nBevor wir \u00fcber den Bot sprechen, machen wir einen kurzen Exkurs in unseren Tierpark der Installationen. Dieser ist in erster Linie durch die gigantische Gr\u00f6\u00dfe unserer Infrastruktur bedingt. Zweitens versuchen wir, f\u00fcr jeden Dienst eine optimale Hardwarekonfiguration auszuw\u00e4hlen. Wir haben etwa 20 Modelle von Hardware-RAID, haupts\u00e4chlich von LSI und Adaptec, aber auch HP und DELL unterschiedlicher Versionen sind vorhanden. Jeder RAID-Controller verf\u00fcgt \u00fcber eine eigene Verwaltungssoftware. Der Befehlssatz und die Ausgabe k\u00f6nnen von Version zu Version bei jedem RAID-Controller variieren. In F\u00e4llen, in denen kein HW-RAID verwendet wird, kann mdraid zum Einsatz kommen.<\/p>\n<p>Fast alle neuen Installationen f\u00fchren 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\u00fcrlich gibt es jedoch viele Legacy-Server, die weiterhin unterst\u00fctzt werden m\u00fcssen.<\/p>\n<p>An manchen Stellen werden Festplatten in RAID-Controllern als Raw-Ger\u00e4te 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\u00dflich des Betriebssystems und der Anwendungen, wobei dieselben Versionen verwendet werden m\u00fcssen. Anschlie\u00dfend m\u00fcssen Konfigurationsdateien hinzugef\u00fcgt und Anwendungen gestartet werden. Au\u00dferdem gibt es viele Gruppen von Servern, bei denen die Absicherung nicht auf der Ebene des Speicher-Subsystems erfolgt, sondern direkt in den Anwendungen selbst.<\/p>\n<p>Insgesamt haben wir \u00fcber 400 einzigartige Gruppen von Servern, auf denen etwa 100 verschiedene Anwendungen laufen. Um eine so gro\u00dfe Anzahl an Varianten abzudecken, ben\u00f6tigten wir ein multifunktionales Automatisierungstool. Idealerweise mit einer einfachen DSL, sodass nicht nur derjenige, der es geschrieben hat, es unterst\u00fctzen kann.<\/p>\n<p>Wir haben uns f\u00fcr Ansible entschieden, weil es agentenlos ist: Es war keine Vorbereitung der Infrastruktur n\u00f6tig und der Start war schnell. Zudem ist es in Python geschrieben, das im Team als Standard akzeptiert ist.<\/p>\n<h3>\u00dcbersicht<\/h3>\n<p>\nLassen 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.<\/p>\n<p><img decoding=\"async\" alt=\"Automatisierung des Festplattentauschs mit Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/673df0fe9600bc65633841222f436d37.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nDie Anwendung DiskoBot, die in Python geschrieben ist, fragt Jira regelm\u00e4\u00dfig 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\u00fchrt (dies geschieht f\u00fcr jeden Status in Jira). In diesem Fall wird Prepare2change gestartet.<\/p>\n<p>Ansible kommuniziert mit dem Host, nimmt die Festplatte aus der Rotation und berichtet den Status der Anwendung \u00fcber Callbacks. <\/p>\n<p><img decoding=\"async\" alt=\"Automatisierung des Festplattentauschs mit Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/8bfc13129f8deca640eb63ea81f616c7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nBasierend auf den Ergebnissen versetzt der Bot das Ticket automatisch in den Status Bereit zum Wechseln. Der Ingenieur erh\u00e4lt eine Benachrichtigung und macht sich auf den Weg, um die Festplatte zu wechseln, danach versetzt er das Ticket in den Status Gewechselt. <\/p>\n<p><img decoding=\"async\" alt=\"Automatisierung des Festplattentauschs mit Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/eeda06b6966f435e2172d3f9c61b341e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nGem\u00e4\u00df dem oben beschriebenen Schema gelangt das Ticket zur\u00fcck zum Bot, der ein anderes Playbook startet, auf den Host geht und die Festplatte in den Rotationsprozess eingibt. Der Bot schlie\u00dft das Ticket. Hurra!<\/p>\n<p><img decoding=\"async\" alt=\"Automatisierung des Festplattentauschs mit Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/51b8c7050b0c10c16ad6a6d4974c3ebf.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nNun lassen Sie uns \u00fcber einige Komponenten des Systems sprechen.<\/p>\n<h3>Diskobot<\/h3>\n<p>\nDiese Anwendung ist in Python geschrieben. Sie w\u00e4hlt Tickets aus Jira gem\u00e4\u00df JQL aus. Abh\u00e4ngig vom Status des Tickets gelangt es zu dem entsprechenden Bearbeiter, der seinerseits das passende Ansible-Playbook gem\u00e4\u00df dem Status ausf\u00fchrt.<\/p>\n<p>JQL und Abfrageintervalle sind in der Konfigurationsdatei der Anwendung definiert.<\/p>\n<pre><code class=\"plaintext\">jira_states:\n  investigate:\n    jql: '\u2026 status = Open and \"Disk Size\" is EMPTY'\n    interval: 180\n\n  inprogress:\n    jql: '\u2026 and \"Disk Size\" is not EMPTY and \"Device Name\" is not EMPTY'\n \n  ready:\n    jql: '\u2026 and (labels not in (\"dbot_ignore\") or labels is EMPTY)'\n    interval: 7200\n<\/code><\/pre>\n<p>\nZum Beispiel werden unter den Tickets im Status In Progress nur die ausgew\u00e4hlt, bei denen die Felder Disk Size und Device Name ausgef\u00fcllt sind. Device Name ist der Name des Blockger\u00e4ts, das f\u00fcr die Ausf\u00fchrung des Playbooks ben\u00f6tigt wird. Disk Size wird ben\u00f6tigt, damit der Ingenieur wei\u00df, welcher Festplattengr\u00f6\u00dfe erforderlich ist.<\/p>\n<p>Und unter den Tickets mit dem Status Ready werden Tickets mit dem Label dbot_ignore herausgefiltert. \u00dcbrigens verwenden wir Jira-Labels sowohl f\u00fcr solche Filterungen als auch zur Kennzeichnung von Duplikaten von Tickets und zur Sammlung von Statistiken.<\/p>\n<p>Im Falle eines Fehlers im Playbook weist Jira das Label dbot_failed zu, um sp\u00e4ter die Probleme zu kl\u00e4ren. <\/p>\n<h3>Interaktion mit Ansible<\/h3>\n<p>\nDie Anwendung interagiert mit Ansible \u00fcber <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.ansible.com\/ansible\/latest\/dev_guide\/developing_api.html\">Ansible Python API<\/a><\/noindex>. Im playbook_executor \u00fcbergeben wir den Dateinamen und eine Sammlung von Variablen. Damit kann das Ansible-Projekt in Form von standardm\u00e4\u00dfigen yml-Dateien gehalten werden, anstatt es in Python-Code zu beschreiben. <\/p>\n<p>Auch in Ansible werden \u00fcber *extra_vars* der Name des Blockger\u00e4ts, der Status des Tickets sowie die callback_url \u00fcbergeben, in der der Issue-Key eingebettet ist \u2014 dieser wird f\u00fcr den HTTP-Callback verwendet.<\/p>\n<p>F\u00fcr jeden Lauf wird ein tempor\u00e4res Inventory erstellt, das aus einem Host und einer Gruppe besteht, in die dieser Host geh\u00f6rt, um die group_vars anzuwenden.<\/p>\n<p>Hier ist ein Beispiel f\u00fcr eine Aufgabe, die den HTTP-Callback implementiert.<\/p>\n<p>Die Ergebnisse der Ausf\u00fchrung von Playbooks erhalten wir \u00fcber Callback(s). Diese sind von zwei Arten:<\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/docs.ansible.com\/ansible\/latest\/plugins\/callback.html\">Ansible Callback-Plugin<\/a><\/noindex>, es liefert Daten zu den Ergebnissen der Playbook-Ausf\u00fchrung. Darin sind die Aufgaben beschrieben, die gestartet wurden, erfolgreich oder nicht erfolgreich abgeschlossen wurden. Dieser Callback wird am Ende der Playbook-Ausf\u00fchrung aufgerufen.<\/li>\n<li>HTTP-Callback zur Informationsbeschaffung w\u00e4hrend der Playbook-Ausf\u00fchrung. Im Ansible-Task f\u00fchren wir eine POST\/GET-Anfrage an unsere Anwendung aus.<\/li>\n<\/ul>\n<p>\n\u00dcber HTTP-Callbacks werden Variablen \u00fcbermittelt, die w\u00e4hrend der Ausf\u00fchrung des Playbooks festgelegt wurden und die wir f\u00fcr zuk\u00fcnftige Durchl\u00e4ufe speichern und verwenden m\u00f6chten. Diese Daten speichern wir in SQLite.<\/p>\n<p>Auch \u00fcber HTTP-Callbacks hinterlassen wir Kommentare und \u00e4ndern den Status des Tickets.<\/p>\n<p><b class=\"spoiler_title\">HTTP-Callback<\/b><\/p>\n<pre><code class=\"plaintext\"># Make callback to Diskobot App\n# Variables:\n#    callback_post_body: # A dict with follow keys. All keys are optional\n#       msg: If exist it would be posted to Jira as comment\n#       data: If exist it would be saved in Incident.variables\n#       desire_state: Set desire_state for incident\n#       status: If exist Proceed issue to that status\n\n  - name: Callback to Diskobot app (jira comment\/status)\n    uri:\n      url: \"{{ callback_url }}\/{{ devname }}\"\n      user: \"{{ diskobot_user }}\"\n      password: \"{{ diskobot_pass }}\"\n      force_basic_auth: True\n      method: POST\n      body: \"{{ callback_post_body | to_json }}\"\n      body_format: json\n    delegate_to: 127.0.0.1\n<\/code><\/pre>\n<p>Wie bei vielen \u00e4hnlichen Aufgaben haben wir diese in eine separate Common-Datei ausgelagert und binden sie bei Bedarf ein, um sie nicht st\u00e4ndig 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\u00fchrt, versteht der Bot, dass sie im Rahmen eines bestimmten Vorfalls eingegangen ist.<\/p>\n<p>Hier ein Beispiel aus dem Playbook, in dem wir eine Festplatte aus dem MD-Ger\u00e4t entfernt haben:<\/p>\n<pre><code class=\"plaintext\">  # Save mdadm configuration\n  - include: common\/callback.yml\n    vars:\n      callback_post_body:\n        status: 'Ready to change'\n        msg: \"Removed disk from mdraid {{ mdadm_remove_disk.msg | comment_jira }}\"\n        data:\n          mdadm_data: \"{{ mdadm_remove_disk.removed }}\"\n          parted_info: \"{{ parted_info | default() }}\"\n    when:\n      - mdadm_remove_disk | changed\n      - mdadm_remove_disk.removed\n<\/code><\/pre>\n<p>\nDiese Aufgabe versetzt das Jira-Ticket in den Status \u201eBereit zur \u00c4nderung\u201c und f\u00fcgt einen Kommentar hinzu. Au\u00dferdem wird in der Variablen mdam_data eine Liste der MD-Ger\u00e4te gespeichert, aus denen die Festplatte entfernt wurde, und in parted_info wird ein Dump der Partition von Parted gespeichert. <\/p>\n<p>Wenn der Ingenieur die neue Festplatte einsetzt, k\u00f6nnen wir diese Variablen verwenden, um den Partitiondump wiederherzustellen und die Festplatte in die MD-Ger\u00e4te zu bringen, aus denen sie entfernt wurde.<\/p>\n<h3>Ansible-Checkmodus<\/h3>\n<p>\nDie Automatisierung zu aktivieren, war be\u00e4ngstigend. Daher haben wir entschieden, alle Playbooks im Modus <br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/docs.ansible.com\/ansible\/latest\/user_guide\/playbooks_checkmode.html\">Dry Run<\/a><\/noindex>, in dem Ansible auf den Servern keine Aktionen ausf\u00fchrt, sondern diese nur emuliert. <\/p>\n<p>Dieser Start wird \u00fcber ein separates Callback-Modul abgewickelt, und das Ergebnis der Ausf\u00fchrung des Playbooks wird als Kommentar in Jira gespeichert.<\/p>\n<p><img decoding=\"async\" alt=\"Automatisierung des Festplattentauschs mit Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/b02d7f1dc428f2797ae8556cd496b115.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEinerseits hat dies die Funktionalit\u00e4t des Bots und der Playbooks validiert. Andererseits hat es das Vertrauen der Administratoren in den Bot gest\u00e4rkt. <\/p>\n<p>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\u00fcgt, um dasselbe Playbook mit denselben Variablen auf demselben Host im normalen Modus auszuf\u00fchren. <\/p>\n<p>Zudem wird der Button verwendet, um das Playbook im Falle eines Fehlers erneut zu starten.<\/p>\n<h3>Struktur der Playbooks<\/h3>\n<p>\nIch habe bereits erw\u00e4hnt, dass der Bot je nach Status des Jira-Tickets unterschiedliche Playbooks ausf\u00fchrt.<\/p>\n<p>Einerseits erleichtert das den Zugang erheblich. <br \/>\nAndererseits ist es in einigen F\u00e4llen einfach notwendig. <\/p>\n<p>Wenn beispielsweise die Systemfestplatte ersetzt werden muss, sollte man zuerst in das Bereitstellungssystem gehen, eine Aufgabe erstellen, und nach erfolgreicher Bereitstellung wird der Server \u00fcber SSH verf\u00fcgbar sein, sodass man die Anwendung installieren kann. Wenn wir all dies in einem einzigen Playbook machen w\u00fcrden, k\u00f6nnte Ansible es aufgrund der Nichterreichbarkeit des Hosts nicht ausf\u00fchren.<\/p>\n<p>Wir verwenden Ansible-Rollen f\u00fcr jede Gruppe von Servern. Hier sieht man, wie die Playbooks in einer von ihnen organisiert sind. <\/p>\n<p><img decoding=\"async\" alt=\"Automatisierung des Festplattentauschs mit Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/7a14035392b33f01d3182d5fff779321.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDas ist praktisch, weil sofort klar ist, wo welche Aufgaben platziert sind. In main.yml, das als Einstieg f\u00fcr die Ansible-Rolle fungiert, kann es einfach einen Include je nach Ticketstatus oder allgemeine Aufgaben geben, die f\u00fcr alle notwendig sind, wie z.B. die Identifikation oder das Abrufen eines Tokens.<\/p>\n<h4>Investigation.yml<\/h4>\n<p>\nWird f\u00fcr Tickets im Status Investigation und Open gestartet. Das Wichtigste f\u00fcr dieses Playbook ist der Name des Blockger\u00e4ts. Diese Information ist nicht immer verf\u00fcgbar. <\/p>\n<p>Um dies zu erreichen, analysieren wir die Jira-Zusammenfassung sowie den letzten Wert des Zabbix-Triggers. Dort k\u00f6nnte der Name des Blockger\u00e4ts zu finden sein \u2013 Gl\u00fcck gehabt. Alternativ kann der Mount-Punkt angegeben sein, dann m\u00fcssen wir zum Server gehen, den Inhalt parsen und die ben\u00f6tigte Festplatte ermitteln. Zudem kann der Trigger die SCSI-Adresse oder andere Informationen \u00fcbermitteln. Manchmal gibt es jedoch keine Hinweise, und wir m\u00fcssen alles analysieren.<\/p>\n<p>Sobald wir den Namen des Blockger\u00e4ts ermittelt haben, sammeln wir Informationen \u00fcber den Typ und die Gr\u00f6\u00dfe der Festplatte, um die entsprechenden Felder in Jira auszuf\u00fcllen. Au\u00dferdem nehmen wir Informationen \u00fcber den Anbieter, das Modell, die Firmware, die ID, SMART ab und f\u00fcgen alles in den Kommentar im Jira-Ticket ein. Der Administrator und der Ingenieur m\u00fcssen jetzt nicht mehr nach diesen Daten suchen. \ud83d\ude42<\/p>\n<p><img decoding=\"async\" alt=\"Automatisierung des Festplattentauschs mit Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/259bf8712c013ee00d238f111b4280fb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h4>prepare2change.yml<\/h4>\n<p>\nAuswurf der Festplatte aus der Rotation, Vorbereitung auf den Austausch. Der schwierigste, verantwortungsvollste Schritt. Hier kann man die Anwendung anhalten, auch wenn dies nicht m\u00f6glich sein sollte. Oder man zieht die Festplatte, bei der es an Replikaten mangelte, und beeintr\u00e4chtigt damit die Nutzer oder verliert Daten. Hier haben wir die meisten Pr\u00fcfungen und Benachrichtigungen im Chat.<\/p>\n<p>Im einfachsten Fall geht es um das Entfernen der Festplatte aus dem HW\/MD RAID. <\/p>\n<p>In komplexeren Situationen (in unseren Speichersystemen), in denen die Sicherung auf Anwendungsebene erfolgt, muss man \u00fcber die API in die Anwendung gehen, den Laufwerksauswurf melden, es deaktivieren und die Wiederherstellung starten.<\/p>\n<p>Wir migrieren derzeit massenhaft in <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/odnoklassniki\/blog\/346868\">die Cloud<\/a><\/noindex>, und wenn der Server cloudbasiert ist, kontaktiert Diskobot die API der Cloud, teilt mit, dass er mit diesem Minion \u2014 dem Server, auf dem die Container laufen \u2014 arbeiten m\u00f6chte, und bittet um \u201emigriere alle Container von diesem Minion\u201c. Gleichzeitig wird die Laufwerksbeleuchtung aktiviert, damit der Ingenieur sofort sieht, welches Laufwerk entnommen werden muss.<\/p>\n<h4>changed.yml<\/h4>\n<p>\nNach dem Austausch des Laufwerks \u00fcberpr\u00fcfen wir zun\u00e4chst dessen Verf\u00fcgbarkeit. <\/p>\n<p>Ingenieure montieren nicht immer neue Laufwerke, deshalb haben wir eine \u00dcberpr\u00fcfung der f\u00fcr uns akzeptablen SMART-Werte hinzugef\u00fcgt.<\/p>\n<p><b class=\"spoiler_title\">Welche Attribute wir betrachten<\/b>Reallocated Sectors Count (5) &lt; 100<br \/>\nCurrent Pending Sector Count (107) == 0<\/p>\n<p>Wenn das Laufwerk die Pr\u00fcfung nicht besteht, wird der Ingenieur \u00fcber den erforderlichen Austausch informiert. Wenn alles in Ordnung ist, wird die Beleuchtung ausgeschaltet, die Markierung wird erstellt und das Laufwerk in den Betrieb aufgenommen.<\/p>\n<h4>ready.yml<\/h4>\n<p>\nDer einfachste Fall: \u00dcberpr\u00fcfung der Synchronisation von HW\/SW-Raid oder das Ende der Datensynchronisation in der Anwendung.<\/p>\n<h3>API der Anwendungen<\/h3>\n<p>\nIch habe bereits mehrfach erw\u00e4hnt, dass der Bot h\u00e4ufig auf die API von Anwendungen zugreift. Nat\u00fcrlich hatten nicht alle Anwendungen die erforderlichen Methoden, daher mussten wir diese anpassen. Hier sind die wichtigsten Methoden, die wir verwenden:<\/p>\n<ul>\n<li>Status. Der Status des Clusters oder der Festplatte, um zu verstehen, ob man damit arbeiten kann;\n<\/li>\n<li>Start\/Stopp. Aktivierung und Deaktivierung der Festplatte;\n<\/li>\n<li>Migrieren\/Wiederherstellen. Migration und Wiederherstellung von Daten w\u00e4hrend und nach dem Austausch.\n<\/li>\n<\/ul>\n<p><\/p>\n<h3>Erfahrungen mit Ansible<\/h3>\n<p>\nIch 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\u00f6s. Komplexe logische Verflechtungen aus when\/loop, fehlende Flexibilit\u00e4t und Idempotenz aufgrund der h\u00e4ufigen Verwendung von shell\/command.<\/p>\n<p>Wir haben uns entschieden, alles so einfach wie m\u00f6glich zu halten, indem wir den Vorteil von Ansible - die Modularit\u00e4t - nutzen. Auf der obersten Ebene befinden sich die Playbooks, die von jedem Administrator oder externen Entwickler, der ein wenig Ansible kennt, geschrieben werden k\u00f6nnen.<\/p>\n<pre><code class=\"plaintext\">- name: Disk blinken\n  become: True\n  register: locate_action\n  disk_locate:\n      locate: '{{ locate }}'\n      devname: '{{ devname }}'\n      ids: '{{ locate_ids | default(pd_id) | default(omit) }}'\n<\/code><\/pre>\n<p>Wenn eine Logik schwer in Playbooks umzusetzen ist, ziehen wir es vor, sie in ein Ansible-Modul oder einen Filter auszulagern. Die Skripte k\u00f6nnen sowohl in Python als auch in jeder anderen Programmiersprache geschrieben werden. <\/p>\n<p>Diese sind einfach und schnell zu schreiben. Das Beispiel f\u00fcr das Disk-Highlighting-Modul, das oben beschrieben ist, umfasst 265 Zeilen.<\/p>\n<p><img decoding=\"async\" alt=\"Automatisierung des Festplattentauschs mit Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/08e0384bfad24f3ee61e0643ca087852.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAuf der untersten Ebene befindet sich die Bibliothek. F\u00fcr dieses Projekt haben wir eine eigene Anwendung geschrieben, die eine Art Abstraktion \u00fcber die Hardware- und Software-RAID bildet, die die entsprechenden Anfragen bearbeitet. <\/p>\n<p><img decoding=\"async\" alt=\"Automatisierung des Festplattentauschs mit Ansible\" src=\"\/wp-content\/uploads\/2019\/06\/0edda3182026ce6279bd84c99613e3d6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDie st\u00e4rksten Punkte von Ansible sind die Einfachheit und die klaren Playbooks. Ich denke, wir sollten das nutzen und keine un\u00fcbersichtlichen YAML-Dateien mit einer Vielzahl von Bedingungen, Shell-Code und Schleifen generieren.<\/p>\n<p>Wenn Sie unsere Erfahrungen mit der Ansible-API wiederholen m\u00f6chten, beachten Sie bitte zwei Dinge:<\/p>\n<ul>\n<li>Dem Playbook_executor und dem Playbook selbst kann kein Timeout \u00fcbergeben werden. Es gibt ein Timeout f\u00fcr SSH-Sitzungen, aber kein Timeout f\u00fcr 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.\n<\/li>\n<li>Ansible basiert auf Fork-Prozessen, weshalb seine API nicht thread-sicher ist. Wir f\u00fchren alle unsere Playbooks in einem einzelnen Thread aus.\n<\/li>\n<\/ul>\n<p>\nDadurch 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\u00fchrt dann einen Klick aus.<\/p>\n<p>Jetzt stehen wir jedoch vor einem anderen Problem: Einige neue Administratoren wissen nicht, wie die Festplatten gewechselt werden. \ud83d\ude42<br \/>\n<br \/>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/odnoklassniki\/blog\/452110\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u042f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0432\u0435\u0434\u0443\u0449\u0438\u043c \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u043c \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u043e\u043c \u0432 \u041e\u041a \u0438 \u043e\u0442\u0432\u0435\u0447\u0430\u044e \u0437\u0430 \u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u0443\u044e \u0440\u0430\u0431\u043e\u0442\u0443 \u043f\u043e\u0440\u0442\u0430\u043b\u0430. \u0425\u043e\u0447\u0443 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043c\u044b \u0432\u044b\u0441\u0442\u0440\u043e\u0438\u043b\u0438 \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u0437\u0430\u043c\u0435\u043d\u044b \u0434\u0438\u0441\u043a\u043e\u0432, \u0430 \u0437\u0430\u0442\u0435\u043c, \u043a\u0430\u043a \u0438\u0441\u043a\u043b\u044e\u0447\u0438\u043b\u0438 \u0438\u0437 \u044d\u0442\u043e\u0433\u043e \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430 \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u0430 \u0438 \u0437\u0430\u043c\u0435\u043d\u0438\u043b\u0438 \u0435\u0433\u043e \u0431\u043e\u0442\u043e\u043c. \u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u0432\u043e\u0435\u0433\u043e \u0440\u043e\u0434\u0430 \u0442\u0440\u0430\u043d\u0441\u043b\u0438\u0442\u0435\u0440\u0430\u0446\u0438\u0435\u0439 \u0432\u044b\u0441\u0442\u0443\u043f\u043b\u0435\u043d\u0438\u044f \u043d\u0430 HighLoad+ 2018 \u041f\u043e\u0441\u0442\u0440\u043e\u0435\u043d\u0438\u0435 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430 \u043f\u043e \u0437\u0430\u043c\u0435\u043d\u0435 \u0434\u0438\u0441\u043a\u043e\u0432 \u0421\u043d\u0430\u0447\u0430\u043b\u0430 \u043d\u0435\u043c\u043d\u043e\u0433\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26233,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34841","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u042f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0432\u0435\u0434\u0443\u0449\u0438\u043c \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u043c \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u043e\u043c \u0432 \u041e\u041a \u0438 \u043e\u0442\u0432\u0435\u0447\u0430\u044e \u0437\u0430 \u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u0443\u044e \u0440\u0430\u0431\u043e\u0442\u0443 \u043f\u043e\u0440\u0442\u0430\u043b\u0430. \u0425\u043e\u0447\u0443 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043c\u044b \u0432\u044b\u0441\u0442\u0440\u043e\u0438\u043b\u0438 \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u0437\u0430\u043c\u0435\u043d\u044b \u0434\u0438\u0441\u043a\u043e\u0432, \u0430 \u0437\u0430\u0442\u0435\u043c, \u043a\u0430\u043a \u0438\u0441\u043a\u043b\u044e\u0447\u0438\u043b\u0438 \u0438\u0437 \u044d\u0442\u043e\u0433\u043e \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430 \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u0430 \u0438 \u0437\u0430\u043c\u0435\u043d\u0438\u043b\u0438 \u0435\u0433\u043e \u0431\u043e\u0442\u043e\u043c. \u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u0432\u043e\u0435\u0433\u043e \u0440\u043e\u0434\u0430 \u0442\u0440\u0430\u043d\u0441\u043b\u0438\u0442\u0435\u0440\u0430\u0446\u0438\u0435\u0439 \u0432\u044b\u0441\u0442\u0443\u043f\u043b\u0435\u043d\u0438\u044f \u043d\u0430 HighLoad+ 2018 \u041f\u043e\u0441\u0442\u0440\u043e\u0435\u043d\u0438\u0435 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430 \u043f\u043e \u0437\u0430\u043c\u0435\u043d\u0435 \u0434\u0438\u0441\u043a\u043e\u0432 \u0421\u043d\u0430\u0447\u0430\u043b\u0430 \u043d\u0435\u043c\u043d\u043e\u0433\u043e\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0410\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u044f \u0437\u0430\u043c\u0435\u043d\u044b \u0434\u0438\u0441\u043a\u043e\u0432 \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e Ansible | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u042f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0432\u0435\u0434\u0443\u0449\u0438\u043c \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u043c \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u043e\u043c \u0432 \u041e\u041a \u0438 \u043e\u0442\u0432\u0435\u0447\u0430\u044e \u0437\u0430 \u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u0443\u044e \u0440\u0430\u0431\u043e\u0442\u0443 \u043f\u043e\u0440\u0442\u0430\u043b\u0430. \u0425\u043e\u0447\u0443 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043c\u044b \u0432\u044b\u0441\u0442\u0440\u043e\u0438\u043b\u0438 \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u0437\u0430\u043c\u0435\u043d\u044b \u0434\u0438\u0441\u043a\u043e\u0432, \u0430 \u0437\u0430\u0442\u0435\u043c, \u043a\u0430\u043a \u0438\u0441\u043a\u043b\u044e\u0447\u0438\u043b\u0438 \u0438\u0437 \u044d\u0442\u043e\u0433\u043e \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430 \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u0430 \u0438 \u0437\u0430\u043c\u0435\u043d\u0438\u043b\u0438 \u0435\u0433\u043e \u0431\u043e\u0442\u043e\u043c. \u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u0432\u043e\u0435\u0433\u043e \u0440\u043e\u0434\u0430 \u0442\u0440\u0430\u043d\u0441\u043b\u0438\u0442\u0435\u0440\u0430\u0446\u0438\u0435\u0439 \u0432\u044b\u0441\u0442\u0443\u043f\u043b\u0435\u043d\u0438\u044f \u043d\u0430 HighLoad+ 2018 \u041f\u043e\u0441\u0442\u0440\u043e\u0435\u043d\u0438\u0435 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430 \u043f\u043e \u0437\u0430\u043c\u0435\u043d\u0435 \u0434\u0438\u0441\u043a\u043e\u0432 \u0421\u043d\u0430\u0447\u0430\u043b\u0430 \u043d\u0435\u043c\u043d\u043e\u0433\u043e\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:00:43+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:00:43+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Automatisierung des Festplattentausches mit Ansible | ProHoster","description":"Hallo zusammen. Ich arbeite als leitender Systemadministrator bei OK und bin verantwortlich f\u00fcr den stabilen Betrieb des Portals. Ich m\u00f6chte dar\u00fcber erz\u00e4hlen, wie wir den Prozess des automatischen Festplattentausches aufgebaut haben und dann den Administrator aus diesem Prozess ausgeschlossen und durch einen Bot ersetzt haben. Dieser Artikel ist eine Art Transkription meines Vortrags auf der HighLoad+ 2018 \u00fcber den Aufbau des Festplattentausches. Zun\u00e4chst etwas","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0410\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u044f \u0437\u0430\u043c\u0435\u043d\u044b \u0434\u0438\u0441\u043a\u043e\u0432 \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e Ansible | ProHoster","og:description":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442. \u042f \u0440\u0430\u0431\u043e\u0442\u0430\u044e \u0432\u0435\u0434\u0443\u0449\u0438\u043c \u0441\u0438\u0441\u0442\u0435\u043c\u043d\u044b\u043c \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u043e\u043c \u0432 \u041e\u041a \u0438 \u043e\u0442\u0432\u0435\u0447\u0430\u044e \u0437\u0430 \u0441\u0442\u0430\u0431\u0438\u043b\u044c\u043d\u0443\u044e \u0440\u0430\u0431\u043e\u0442\u0443 \u043f\u043e\u0440\u0442\u0430\u043b\u0430. \u0425\u043e\u0447\u0443 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043c\u044b \u0432\u044b\u0441\u0442\u0440\u043e\u0438\u043b\u0438 \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u0437\u0430\u043c\u0435\u043d\u044b \u0434\u0438\u0441\u043a\u043e\u0432, \u0430 \u0437\u0430\u0442\u0435\u043c, \u043a\u0430\u043a \u0438\u0441\u043a\u043b\u044e\u0447\u0438\u043b\u0438 \u0438\u0437 \u044d\u0442\u043e\u0433\u043e \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430 \u0430\u0434\u043c\u0438\u043d\u0438\u0441\u0442\u0440\u0430\u0442\u043e\u0440\u0430 \u0438 \u0437\u0430\u043c\u0435\u043d\u0438\u043b\u0438 \u0435\u0433\u043e \u0431\u043e\u0442\u043e\u043c. \u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u0432\u043e\u0435\u0433\u043e \u0440\u043e\u0434\u0430 \u0442\u0440\u0430\u043d\u0441\u043b\u0438\u0442\u0435\u0440\u0430\u0446\u0438\u0435\u0439 \u0432\u044b\u0441\u0442\u0443\u043f\u043b\u0435\u043d\u0438\u044f \u043d\u0430 HighLoad+ 2018 \u041f\u043e\u0441\u0442\u0440\u043e\u0435\u043d\u0438\u0435 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430 \u043f\u043e \u0437\u0430\u043c\u0435\u043d\u0435 \u0434\u0438\u0441\u043a\u043e\u0432 \u0421\u043d\u0430\u0447\u0430\u043b\u0430 \u043d\u0435\u043c\u043d\u043e\u0433\u043e","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:00:43+00:00","article:modified_time":"2019-10-31T19:00:43+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34841","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 20:48:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:14:05","updated":"2026-01-21 20:48:19"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/34841","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=34841"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/34841\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/26233"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=34841"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=34841"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=34841"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}