Die Gewährleistung, dass unsere Server kontinuierlich auf sichere und geprüfte Betriebssysteme aktualisiert werden, ist ein wichtiger Schritt, den wir unternehmen, um sicherzustellen, dass unsere Mitglieder und Kunden auf LinkedIn zugreifen können, um nach neuen Rollen zu suchen, auf neue Lernprogramme zuzugreifen oder Wissen mit anderen Fachleuten auszutauschen. LinkedIn verfügt über eine ziemlich große Flotte von Servern vor Ort, die auf interne Tools angewiesen sind, um sicherzustellen, dass sie auf den neuesten Betriebssystemen bleiben. In diesem Beitrag wird ein internes Tool vorgestellt, das als Schnittstelle für die Verwaltung der Serverlebenszyklen auf LinkedIn-Ebene dient. Wir werden die Gründe für die Existenz dieses Tools hervorheben, den Weg, es unseren Hauptkunden (z. B. Website-Zuverlässigkeitsingenieure) zur Verfügung zu stellen, und wie wir diesen Dienst neu strukturiert und skaliert haben, sodass er nur noch maximal 72.000 Servereinreichungen pro Tag akzeptieren kann dass es keine Einschränkungen hinsichtlich der Akzeptanzrate gibt.
Das Bedürfnis nach einer Lösung
Vor Metal as a Service (MaaS) wurden alle Server-Upgrade-Anfragen über Jira-Tickets an Ingenieure (von der Production Systems Software Engineering-Organisation) weitergeleitet. Es lag in ihrer alleinigen Verantwortung, diesen Aufwand manuell voranzutreiben. Obwohl es klar definiert war, erforderte es eine Übertragung der Kontrolle vom Host-/Poolbesitzer an einen Techniker einer anderen Organisation. Oftmals kam es zu unerwarteten Verzögerungen, weil die Kommunikation über ein Ticket bearbeitet wurde. Manche Probleme erforderten oft eine praxisorientiertere Herangehensweise und das Eingreifen von Rechenzentrumstechnikern, um die Dinge voranzubringen. Die größte Herausforderung bestand daher darin, die Verwaltung des Serverlebenszyklus angemessen an die entsprechenden SREs und Poolbesitzer zu delegieren. Das Entfernen einer zusätzlichen Koordinierungsebene würde dazu beitragen, Probleme schneller zu isolieren und den Eigentümern ein Gefühl der Kontrolle über die Server zu geben, für die sie verantwortlich sind.
Hintergrund
Um den Kontext für die bevorstehende Diskussion festzulegen, werden wir die folgenden Begriffe definieren:
Überlappende Hosts
Eines der Hauptanliegen, die bei der Interaktion mit Partner-SRE-Teams geäußert wurden, war die Frage, wie dieses Produkt überlappende Anfragen ermitteln würde, d. h. wie kann dieses Produkt Mitglieder isolieren und davon abhalten, unterschiedliche Vorgänge auf einem Standardsatz von Hosts zu versuchen? Vor der Alpha-Version haben wir eine Prüfung hinzugefügt, die überprüft, ob Hosts in einem aktuell übermittelten Batch Teil eines anderen sind. Wenn dies der Fall ist, wird der aktuelle Stapel durch entsprechende Benachrichtigung des Endbenutzers ungültig gemacht.
Neubild
Ein Betriebssystem-Upgrade, das vorhandene Daten von der Festplatte löscht und den Server wieder in einen sauberen Zustand versetzt, wobei hostspezifische Konfigurationen gebootet werden.
Vor MaaS gab es eine Version von „Reimager“. Während die Vorgängerversion von „reimager“ ein effektives Tool war, war es nicht abfragbar und erforderte die manuelle Erfüllung spezifischer Voraussetzungen. Mit dem übergreifenden Thema, Site Reliability Engineers (SREs) die Möglichkeit zu geben, die Verantwortung für diesen gesamten Prozess zu übernehmen, mussten wir über die bestehende Lösung hinausdenken, was zur Entwicklung eines Tools führte, das den direkten Zugriff auf SREs für die Verwaltung des Serverlebenszyklus ermöglichen könnte. Eine gute Möglichkeit hierfür war die Bereitstellung verschiedener Funktionalitäten über eine API. Eine weitere Änderung, die wir herbeiführen wollten, war das Konzept einer Charge; Dies wurde ausdrücklich untersucht, um die starke Abhängigkeit von Jira-Tickets als Quelle der Wahrheit zu durchbrechen. Batching war ein relevantes Konzept, da es sich um eine gemeinsame Gruppierungssemantik handelte, mit der Hostbesitzer einen Standardsatz an anzuwendenden Konfigurationen definieren konnten, z. B. mit welcher Betriebssystemversion alle Hosts aktualisiert werden sollten, welche Aktion auf allen Hosts ausgeführt werden sollte usw. Wir auch wollte sicherstellen, dass die richtige Zielgruppe Zugriffsrechte für die Interaktion mit MaaS hat, da die meisten von diesem Produkt ausgeführten Aktionen (wie Reimage, Neustart, Außerbetriebnahme, Datenträgerlöschung usw.) destruktiv sein können. Das erwartete Ergebnis sollte eine dünne Schicht sein, die eine Datenvalidierung durchführt, externe Quellen aktualisiert, um anzuzeigen, dass übermittelte Server bald mutiert werden, und diese Hosts zur weiteren Bearbeitung an einen Downstream-Dienst weiterleitet.
Aloha MaaS!
Mit einem grundlegenden Verständnis dafür, wie sich der Server-Upgrade-Workflow weiterentwickeln musste, interagierte das PSSEBuild-Team mit verschiedenen SRE-Teams, um Anforderungen zu sammeln, die am besten zu ihrer Benutzerfreundlichkeit und ihren Anforderungen passen. Mit dem fertigen Design haben wir eine API geschrieben, mit der SRE-Teams direkt interagieren können. Metal as a Service (MaaS) war eine Self-Service-API, die es Endbenutzern ermöglicht, stapelweise Upgrades (Reimages), Neustarts, Ein-/Ausschaltvorgänge, angeschlossene Festplatten zu löschen und Server außer Betrieb zu nehmen. Im Mittelpunkt steht MaaS, konzipiert als CRUD Flasche-basierte Anwendung, würde verwaltet von systemd oder so ähnlich. Diese Anwendung würde a offenlegen AUSRUHENEine vollständige API, auf die autorisierte Benutzer Zugriff haben, um sie auszuüben. Wir haben uns für eine Benutzerzuordnung mit einem internen entschieden Active Directory (AD) Gruppe zur Durchsetzung der Autorisierung; Alle Authentifizierungsanfragen waren ebenfalls AD-basiert. Nachdem eine Grundstruktur vorhanden war, arbeiteten wir an der Bereitstellung von Endpunkten für:
- Die Übermittlung neuer Anfragen zur Verarbeitung kann aus „Reimage“, „Neustart“ usw. bestehen. Bei erfolgreicher Übermittlung würde MaaS eine Batch-ID zurückgeben, die Benutzer als Referenz für zukünftige Interaktionen verwenden könnten.
- Abfragen des Status eines Stapels relativ zu Stapel-ID und Hostnamen
- Abfragen von Batches, die vom AD-Benutzernamen übermittelt wurden
- Statistiken zur Batch-Laufzeit abfragen
- Stornieren von Stapeln, die versehentlich übermittelt wurden
- Abfragen des Backend-Dienstes, um die Anzahl aktiver Server-Upgrades in allen Rechenzentren zu ermitteln
Unser Ziel war nicht nur die Bereitstellung von Funktionalitäten über eine API, sondern auch die Verbesserung der Sichtbarkeit der gesamten Pipeline. Wir nutzten Iris-basierte Benachrichtigungen und einen intern verfügbaren Ereignisbus, über den SREs den Status ihrer Übermittlungen kennen konnten, ohne ständig mit der API interagieren zu müssen. Irisbasierte Alarme sind detaillierter und synchroner; Einreicher können über verschiedene Zustellmethoden (E-Mail, Slack, SMS usw.) benachrichtigt werden. Iris würde sie anpingen, sobald ein Stapel erfolgreich angenommen und die Ausführung abgeschlossen wurde. Oft besteht die Notwendigkeit, eine verkeilte Einreichung zu selektieren; Wir haben MaaS in die Lage versetzt, Tickets zu erstellen, die an ein internes Team weitergeleitet werden, das sich um einmalige Fehler kümmert und gleichzeitig die Einreicher damit markiert, damit sie über den Fortschritt informiert sind.
Mit zunehmender Akzeptanz von MaaS mussten Architektur und Bereitstellungsschema weiterentwickelt werden, um eine hohe Verfügbarkeit zu gewährleisten und gleichzeitig den für die Produktfreigabe erforderlichen menschlichen Eingriff zu reduzieren. Wir werden nun die Entwicklung der Architektur dieses Tools beschreiben, die Herausforderungen beschreiben, die mit der zunehmenden Einführung dieses Tools einhergehen, und einige Ergebnisse seiner Gesamtleistung im Laufe der Zeit vorstellen.
