{"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 Austauschs von Festplatten mit Ansible","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Automatisierung
\n
\nHallo zusammen. Ich arbeite als leitender Systemadministrator bei OK und bin f\u00fcr den stabilen Betrieb des Portals verantwortlich. Ich m\u00f6chte erz\u00e4hlen, wie wir den Prozess der automatischen Festplattentauschs aufgebaut haben und anschlie\u00dfend, wie wir den Administrator aus diesem Prozess ausgeschlossen und ihn durch einen Bot ersetzt haben.<\/p>\n

Dieser Artikel ist eine Art Transliterierung Vortrags<\/a><\/noindex> bei HighLoad+ 2018
\n<\/a><\/noindex><\/p>\n

Aufbau des Prozesses zum Austausch von Festplatten<\/h2>\n

<\/p>\n

Zun\u00e4chst einige Zahlen<\/h3>\n

\nOK ist ein riesiger Dienst, der von Millionen Menschen genutzt wird. Er wird von etwa 7.000 Servern unterst\u00fctzt, die in 4 verschiedenen Rechenzentren verteilt sind. In den Servern befinden sich \u00fcber 70.000 Festplatten. Wenn man sie \u00fcbereinander stapelt, ergibt sich ein Turm von mehr als 1 km H\u00f6he. <\/p>\n

Festplatten sind der Bestandteil eines Servers, der am h\u00e4ufigsten ausf\u00e4llt. Bei solch einem Volumen m\u00fcssen wir etwa 30 Festplatten pro Woche austauschen, und dieser Vorgang ist zu einer unangenehmen Routine geworden.<\/p>\n

\"Automatisierung
\n<\/p>\n

Vorf\u00e4lle<\/h3>\n

\nIn unserem Unternehmen haben wir ein vollst\u00e4ndiges Incident-Management eingef\u00fchrt. Jeden Vorfall dokumentieren wir in Jira und l\u00f6sen ihn dann. Wenn ein Vorfall Auswirkungen auf die Nutzer hatte, kommen wir auf jeden Fall zusammen und \u00fcberlegen, wie wir schneller auf solche F\u00e4lle reagieren k\u00f6nnen, wie wir die Auswirkungen minimieren und nat\u00fcrlich, wie wir Wiederholungen verhindern k\u00f6nnen.<\/p>\n

Speichermedien sind da keine Ausnahme. Ihr Zustand wird von Zabbix \u00fcberwacht. Wir \u00fcberpr\u00fcfen die Syslog-Nachrichten auf Schreib-\/Lesefehler, analysieren den Zustand von HW\/SW-RAIDs und \u00fcberwachen SMART. Bei SSDs berechnen wir den Verschlei\u00df. <\/p>\n

Wie die Festplatten fr\u00fcher ausgetauscht wurden<\/h3>\n

\nWenn in Zabbix ein Trigger aktiviert wird, wird in Jira ein Vorfall erstellt und automatisch den entsprechenden Ingenieuren in den Rechenzentren zugewiesen. So verfahren wir mit allen HW-Vorf\u00e4llen, also solchen, die irgendeine physische Arbeit mit der Hardware im Rechenzentrum erfordern.
\nDer Ingenieur im Rechenzentrum ist die Person, die sich mit Fragen rund um die Hardware besch\u00e4ftigt, verantwortlich f\u00fcr die Installation, Wartung und Demontage der Server ist. Hat er ein Ticket erhalten, beginnt der Ingenieur mit der Arbeit. In den Festplattensch\u00e4chten wechselt er die Festplatten selbstst\u00e4ndig. Hat er jedoch keinen Zugang zum ben\u00f6tigten Ger\u00e4t, wendet sich der Ingenieur an die diensthabenden Systemadministratoren um Hilfe. Zun\u00e4chst muss die Festplatte aus der Rotation genommen werden. Dazu sind die notwendigen \u00c4nderungen am Server vorzunehmen, die Anwendungen zu stoppen und die Festplatte auszuh\u00e4ngen.<\/p>\n

Der diensthabende Systemadministrator ist w\u00e4hrend der Arbeitsschicht f\u00fcr den gesamten Betrieb des Portals verantwortlich. Er untersucht Vorf\u00e4lle, f\u00fchrt Reparaturen durch und unterst\u00fctzt Entwickler bei kleinen Aufgaben. Lediglich um Festplatten k\u00fcmmert er sich nicht.<\/p>\n

Fr\u00fcher kommunizierten die Ingenieure der Rechenzentren im Chat mit dem Systemadministrator. Die Ingenieure schickten Links zu Jira-Tickets, der Administrator ging sie durch und f\u00fchrte ein Protokoll der Arbeiten in einem Notizbuch. Aber f\u00fcr solche Aufgaben sind Chats unpraktisch: Die Informationen sind dort unstrukturiert und gehen schnell verloren. Au\u00dferdem konnte der Administrator einfach vom Computer weggehen und eine Zeit lang keine Anfragen beantworten, w\u00e4hrend der Ingenieur am Server mit einer Stapel Festplatten wartete.<\/p>\n

Das Schlimmste war jedoch, dass die Administratoren das Gesamtbild nicht sahen: welche Festplattenvorf\u00e4lle es gibt und wo potenziell Probleme entstehen k\u00f6nnen. Das liegt daran, dass wir alle HW-Vorf\u00e4lle den Ingenieuren \u00fcbergeben. Ja, man h\u00e4tte alle Vorf\u00e4lle im Dashboard des Administrators anzeigen k\u00f6nnen. Aber es sind zu viele, und der Administrator wurde nur f\u00fcr einige von ihnen eingebunden.<\/p>\n

Dar\u00fcber hinaus konnte der Ingenieur die Priorit\u00e4ten nicht richtig festlegen, da er nichts \u00fcber die spezifische Nutzung der Server oder die Verteilung der Daten auf den Speichern wusste.<\/p>\n

Neues Austauschverfahren<\/h3>\n

\nDas Erste, was wir gemacht haben, war, alle Festplatten-Vorf\u00e4lle in einen separaten Typ \u201eHW-Disk\u201c zu \u00fcberf\u00fchren und ihm die Felder \u201eName des Blockger\u00e4ts\u201c, \u201eGr\u00f6\u00dfe\u201c und \u201eFestplattentyp\u201c hinzuzuf\u00fcgen, damit diese Informationen im Ticket gespeichert werden und nicht st\u00e4ndig im Chat ausgetauscht werden m\u00fcssen. <\/p>\n

\"Automatisierung
\nAu\u00dferdem haben wir vereinbart, dass wir im Rahmen eines Vorfalls nur eine Festplatte austauschen. Das hat den Prozess der Automatisierung, der Statistiksammlung und der Arbeit erheblich vereinfacht. <\/p>\n

Zus\u00e4tzlich haben wir ein Feld \u201everantwortlicher Administrator\u201c 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, im Kalender nachzusehen. Genau dieses Feld hat es erm\u00f6glicht, die Tickets in das Dashboard des Administrators zu bringen, f\u00fcr die m\u00f6glicherweise seine Hilfe ben\u00f6tigt wird.<\/p>\n

\"Automatisierung
\nUm sicherzustellen, dass alle Teilnehmer maximal von den Neuerungen profitieren, haben wir Filter und Dashboards erstellt und den Leuten dar\u00fcber erz\u00e4hlt. Wenn die Menschen die Ver\u00e4nderungen verstehen, distanzieren sie sich nicht von ihnen, als w\u00e4re es etwas \u00dcberfl\u00fcssiges. F\u00fcr den Ingenieur ist es wichtig, die Racknummer zu kennen, in der sich der Server befindet, sowie die Gr\u00f6\u00dfe und den Typ der Festplatte. Der Administrator muss in erster Linie verstehen, um welche Gruppe von Servern es sich handelt und welchen Effekt der Austausch der Festplatte haben k\u00f6nnte.<\/p>\n

Das Vorhandensein von Feldern und deren Anzeige ist zwar praktisch, hat uns jedoch nicht von der Notwendigkeit befreit, Chats zu nutzen. Dazu mussten wir den Arbeitsprozess \u00e4ndern. <\/p>\n

Fr\u00fcher war er so:<\/p>\n

\"Automatisierung
\nHeute arbeiten Ingenieure weiterhin so, wenn sie keine Hilfe vom Administrator ben\u00f6tigen.<\/p>\n

Das erste, was wir gemacht haben, ist die Einf\u00fchrung eines neuen Status Investigate<\/b>. In diesem Status befindet sich das Ticket, wenn der Ingenieur noch nicht entschieden hat, ob er einen Administrator ben\u00f6tigt oder nicht. \u00dcber diesen Status kann der Ingenieur das Ticket an den Administrator weitergeben. Au\u00dferdem kennzeichnen wir mit diesem Status Tickets, wenn eine Festplatte ersetzt werden muss, aber die Festplatte vor Ort nicht vorhanden ist. Das kommt bei CDN und Remote-Standorten vor.<\/p>\n

Au\u00dferdem haben wir den Status Bereit<\/b>hinzugef\u00fcgt. In diesen Status wird das Ticket nach dem Austausch der Festplatte versetzt. Das hei\u00dft, alles ist bereits erledigt, aber auf dem Server wird HW\/SW RAID synchronisiert. Das kann ziemlich viel Zeit in Anspruch nehmen.<\/p>\n

Wenn ein Administrator in die Arbeit einbezogen wird, wird das Schema etwas komplizierter.<\/p>\n

\"Automatisierung
\nDas Ticket kann sowohl vom Systemadministrator als auch vom Ingenieur aus dem Status Offen<\/b> \u00fcbertragen werden. Im Status In progress<\/b> nimmt der Administrator die Festplatte aus dem Betrieb, sodass der Ingenieur sie einfach herausziehen kann: Er aktiviert das Licht, demontiert die Festplatte, stoppt die Anwendungen, je nach der konkreten Gruppe von Servern.<\/p>\n

Dann wird das Ticket in den Status Ready to change<\/b>: das ist das Signal an den Ingenieur, dass die Festplatte herausgenommen 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 durch den Administrator eingetragen.<\/p>\n

Nach dem Austausch der Festplatte wird das Ticket in den Status Changed<\/b>. Es wird \u00fcberpr\u00fcft, dass die richtige Festplatte eingelegt wurde, eine Partitionierung erfolgt, die Anwendung wird gestartet und einige Datenwiederherstellungsaufgaben durchgef\u00fchrt. Das Ticket kann auch in den Status Bereit<\/b>\u00fcbertragen werden, in diesem Fall bleibt der Administrator verantwortlich, da er die Festplatte in Umlauf gebracht hat. Das gesamte Schema sieht so aus.<\/p>\n

\"Automatisierung
\nDie Hinzuf\u00fcgung neuer Felder hat unser Leben erheblich erleichtert. Die Mitarbeiter arbeiten nun mit strukturierten Informationen, es ist klar, was und in welchem Schritt zu tun ist. Die Priorit\u00e4ten sind deutlich relevanter geworden, da sie jetzt vom Administrator festgelegt werden.<\/p>\n

Die Notwendigkeit von Chats entfiel. Nat\u00fcrlich kann der Administrator dem Ingenieur schreiben: \u201eHier muss schneller ersetzt werden\u201c oder \u201eEs ist schon Abend, schaffst du es noch zu ersetzen?\u201c. Aber wir kommunizieren nicht mehr t\u00e4glich in Chats \u00fcber diese Fragen.<\/p>\n

Festplatten werden nun in gro\u00dfen Mengen ausgetauscht. Wenn der Administrator etwas fr\u00fcher zur Arbeit kommt, hat er Zeit und es ist noch nichts passiert, kann er mehrere Server f\u00fcr den Austausch vorbereiten: Felder festlegen, Festplatten aus der Rotation nehmen und die Aufgabe an den Ingenieur \u00fcbergeben. Der Ingenieur kommt etwas sp\u00e4ter ins Rechenzentrum, sieht die Aufgabe, nimmt die ben\u00f6tigten Speichermedien aus dem Lager und wechselt sie sofort aus. Dadurch hat sich die Austauschgeschwindigkeit erh\u00f6ht.<\/p>\n

Erfahrungen aus dem Workflow-Aufbau<\/h3>\n

<\/p>\n