Hey Habr! Ich präsentiere Ihnen die Übersetzung des Artikels von Adib Daw.
Wenn Ihnen diese Überschrift keinen leichten Schauer über den Rücken jagt, sollten Sie mit dem nächsten Absatz fortfahren oder unsere entsprechende Seite besuchen - Wir würden gerne reden.
Кто мы
Wir sind ein Team von 4 Pinguinen, die es lieben, Code zu schreiben und mit Hardware zu arbeiten. In unserer Freizeit sind wir für die Bereitstellung, Wartung und den Betrieb einer Flotte von über 7000 physischen Servern mit Linux verantwortlich, die auf drei verschiedene Rechenzentren in den Vereinigten Staaten verteilt sind.
Wir hatten auch die Möglichkeit, dies 10 km von den Einsatzorten entfernt zu tun, bequem von unserem eigenen Büro aus, das nur eine kurze Autofahrt vom Strand am Mittelmeer entfernt liegt.
Skalenprobleme
Während es für ein Startup aufgrund der relativ geringen Anfangsinvestition sinnvoll ist, seine Infrastruktur zunächst in der Cloud zu hosten, haben wir uns bei Outbrain für den Einsatz eigener Server entschieden. Wir haben dies getan, weil die Kosten der Cloud-Infrastruktur die Kosten für den Betrieb unserer eigenen Geräte in Rechenzentren nach der Entwicklung bis zu einem gewissen Grad weit übersteigen. Darüber hinaus bietet Ihr Server ein Höchstmaß an Kontroll- und Fehlerbehebungsmöglichkeiten.
Während wir uns weiterentwickeln, sind Probleme immer in der Nähe. Außerdem kommen sie meist in Gruppen. Das Server-Lifecycle-Management erfordert eine ständige Selbstverbesserung, um angesichts der rasant steigenden Anzahl von Servern ordnungsgemäß funktionieren zu können. Softwaremethoden zur Verwaltung von Servergruppen in Rechenzentren werden schnell unhandlich. Das Erkennen, Beheben und Beheben von Fehlern bei gleichzeitiger Einhaltung von QoS-Standards wird zu einer Frage des Jonglierens mit extrem unterschiedlichen Hardware-Arrays, unterschiedlichen Arbeitslasten, Upgrade-Fristen und anderen netten Dingen, über die sich niemand Sorgen machen möchte.
Beherrschen Sie Ihre Domains
Um viele dieser Probleme zu lösen, haben wir den Serverlebenszyklus in Outbrain in seine Hauptkomponenten zerlegt und sie Domänen genannt. Beispielsweise deckt ein Bereich den Ausrüstungsbedarf ab, ein anderer die Logistik im Zusammenhang mit dem Bestandslebenszyklus und ein dritter die Kommunikation mit dem Außendienstpersonal. Es gibt noch eine weitere Frage zur Hardware-Beobachtbarkeit, wir werden jedoch nicht alle Punkte beschreiben. Unser Ziel war es, Domänen zu untersuchen und zu definieren, damit sie mithilfe von Code abstrahiert werden können. Sobald eine funktionierende Abstraktion entwickelt wurde, wird sie in einen manuellen Prozess übertragen, der bereitgestellt, getestet und verfeinert wird. Schließlich wird die Domäne für die Integration mit anderen Domänen über APIs konfiguriert und bildet so ein ganzheitliches, dynamisches und sich ständig weiterentwickelndes Hardware-Lebenszyklussystem, das einsetzbar, testbar und beobachtbar ist. Genau wie alle unsere anderen Produktionssysteme.
Durch die Übernahme dieses Ansatzes konnten wir viele Probleme richtig lösen – durch die Entwicklung von Tools und Automatisierung.
Benötige Domain
Obwohl E-Mail und Tabellenkalkulationen in der Anfangszeit eine praktikable Möglichkeit zur Befriedigung der Nachfrage darstellten, war dies keine erfolgreiche Lösung, insbesondere als die Anzahl der Server und das Volumen der eingehenden Anfragen ein bestimmtes Niveau erreichten. Um eingehende Anfragen angesichts der schnellen Expansion besser organisieren und priorisieren zu können, mussten wir ein Ticketsystem verwenden, das Folgendes bieten konnte:
- Möglichkeit, die Ansicht nur relevanter Felder anzupassen (einfach)
- Offene APIs (erweiterbar)
- Unserem Team bekannt (verstanden)
- Integration in unsere bestehenden Arbeitsabläufe (einheitlich)
Da wir Jira zur Verwaltung unserer Sprints und internen Aufgaben verwenden, haben wir uns entschieden, ein weiteres Projekt zu erstellen, das unseren Kunden dabei helfen soll, Tickets einzureichen und ihre Ergebnisse zu verfolgen. Durch den Einsatz von Jira für eingehende Anfragen und die Verwaltung interner Aufgaben konnten wir ein einziges Kanban-Board erstellen, das es uns ermöglichte, alle Prozesse als Ganzes zu betrachten. Unsere internen „Kunden“ sahen nur Anfragen nach Ausrüstung, ohne sich mit den weniger wichtigen Details zusätzlicher Aufgaben (wie der Verbesserung von Tools, der Behebung von Fehlern) zu befassen.
Kanban-Board in Jira
Als Bonus ermöglichte die Tatsache, dass Warteschlangen und Prioritäten nun für alle sichtbar waren, zu verstehen, „wo in der Warteschlange“ sich eine bestimmte Anfrage befand und was ihr vorausging. Dies ermöglichte es den Eigentümern, ihre eigenen Anfragen neu zu priorisieren, ohne uns kontaktieren zu müssen. Ziehen Sie es und das war's. Außerdem konnten wir unsere SLAs anhand der in Jira generierten Metriken je nach Anforderungstyp überwachen und bewerten.
Gerätelebenszyklusdomäne
Versuchen Sie sich vorzustellen, wie komplex die Verwaltung der in jedem Server-Rack verwendeten Hardware ist. Noch schlimmer ist, dass viele Hardwareteile (RAM, ROM) vom Lager in den Serverraum und zurück verschoben werden können. Sie fallen ebenfalls aus oder werden abgeschrieben und ersetzt und zum Austausch/Reparatur an den Lieferanten zurückgesandt. All dies muss den Colocation-Servicemitarbeitern mitgeteilt werden, die an der physischen Wartung der Geräte beteiligt sind. Um diese Probleme zu lösen, haben wir ein internes Tool namens Floppy erstellt. Seine Aufgabe ist:
- Management der Kommunikation mit Außendienstmitarbeitern, Aggregation aller Informationen;
- Aktualisierung der „Lager“-Daten nach jeder abgeschlossenen und überprüften Gerätewartungsaufgabe.
Das Lager wiederum wird mithilfe von Grafana visualisiert, mit dem wir alle unsere Kennzahlen grafisch darstellen. Daher verwenden wir dasselbe Tool für die Lagervisualisierung und für andere Produktionsanforderungen.
Bedienfeld für Lagerausrüstung in Grafana
Für Servergeräte, für die eine Garantie besteht, verwenden wir ein anderes Tool namens Dispatcher. Er:
- Sammelt Systemprotokolle;
- Erstellt Berichte in dem vom Anbieter geforderten Format;
- Erstellt eine Anfrage vom Anbieter über die API;
- Empfängt und speichert die Anwendungskennung zur weiteren Verfolgung des Fortschritts.
Sobald unsere Reklamation angenommen wurde (in der Regel innerhalb der Geschäftszeiten), wird das Ersatzteil an das entsprechende Rechenzentrum gesendet und von den Mitarbeitern entgegengenommen.
Jenkins-Konsolenausgabe
Kommunikationsdomäne
Um mit dem schnellen Wachstum unseres Unternehmens Schritt zu halten, das immer größere Kapazitäten erfordert, mussten wir die Art und Weise anpassen, wie wir mit technischen Spezialisten in lokalen Rechenzentren zusammenarbeiten. Wenn die Skalierung zunächst den Kauf neuer Server bedeutete, wurde es nach einem Konsolidierungsprojekt (basierend auf der Umstellung auf Kubernetes) etwas völlig anderes. Unsere Entwicklung vom „Hinzufügen von Racks“ zur „Neuverwendung von Servern“.
Die Verwendung eines neuen Ansatzes erforderte auch neue Tools, die eine komfortablere Interaktion mit dem Personal des Rechenzentrums ermöglichten. Diese Werkzeuge waren erforderlich, um:
- Einfachheit;
- Autonomie;
- Effizienz;
- Verlässlichkeit.
Wir mussten uns aus der Kette ausschließen und die Arbeit so strukturieren, dass die Techniker direkt mit der Serverausrüstung arbeiten konnten. Ohne unser Eingreifen und ohne regelmäßig all diese Fragen bezüglich Arbeitsbelastung, Arbeitszeiten, Geräteverfügbarkeit usw. anzusprechen.
Um dies zu erreichen, haben wir in jedem Rechenzentrum iPads installiert. Nach dem Herstellen einer Verbindung zum Server geschieht Folgendes:
- Das Gerät bestätigt, dass dieser Server tatsächlich einige Arbeiten erfordert;
- Auf dem Server laufende Anwendungen werden geschlossen (falls erforderlich);
- Auf einem Slack-Kanal wird eine Reihe von Arbeitsanweisungen veröffentlicht, in denen die erforderlichen Schritte erläutert werden.
- Nach Abschluss der Arbeiten überprüft das Gerät die Richtigkeit des Endzustands des Servers;
- Startet Anwendungen bei Bedarf neu.
Darüber hinaus haben wir auch einen Slack-Bot vorbereitet, der dem Techniker hilft. Dank einer breiten Palette an Fähigkeiten (wir haben die Funktionalität ständig erweitert) erleichterte der Bot ihnen die Arbeit und machte unser Leben viel einfacher. Auf diese Weise haben wir den Großteil des Prozesses der Umnutzung und Wartung von Servern optimiert und uns selbst aus dem Arbeitsablauf ausgeschlossen.
iPad in einem unserer Rechenzentren
Hardware-Domäne
Die zuverlässige Skalierung unserer Rechenzentrumsinfrastruktur erfordert einen guten Einblick in jede Komponente, zum Beispiel:
- Erkennung von Hardwarefehlern
- Serverzustände (aktiv, gehostet, Zombie usw.)
- Leistungsaufnahme
- Firmware Version
- Analysen für das gesamte Unternehmen
Unsere Lösungen ermöglichen es uns, Entscheidungen darüber zu treffen, wie, wo und wann wir Geräte kaufen, manchmal sogar bevor sie tatsächlich benötigt werden. Durch die Bestimmung der Auslastung verschiedener Geräte konnten wir außerdem eine bessere Ressourcenzuteilung erreichen. Insbesondere der Energieverbrauch. Wir können jetzt fundierte Entscheidungen über die Platzierung eines Servers treffen, bevor er im Rack installiert und an eine Stromquelle angeschlossen wird, während seines gesamten Lebenszyklus und bis zu seiner endgültigen Außerbetriebnahme.
Energie-Dashboard in Grafana
Und dann erschien COVID-19 ...
Unser Team entwickelt Technologien, die es Medienunternehmen und Verlagen online ermöglichen, Besuchern dabei zu helfen, relevante Inhalte, Produkte und Dienstleistungen zu finden, die für sie von Interesse sein könnten. Unsere Infrastruktur ist darauf ausgelegt, den Traffic zu bedienen, der entsteht, wenn spannende Neuigkeiten veröffentlicht werden.
Die intensive Berichterstattung in den Medien rund um COVID-19 und der zunehmende Verkehr machten es erforderlich, dass wir dringend lernen mussten, mit diesem Druck umzugehen. Darüber hinaus musste all dies während einer globalen Krise geschehen, als die Lieferketten unterbrochen waren und die meisten Mitarbeiter zu Hause waren.
Aber wie gesagt, unser Modell geht bereits davon aus, dass:
- Die Geräte in unseren Rechenzentren sind für uns größtenteils physisch unzugänglich;
- Wir erledigen fast alle körperlichen Arbeiten aus der Ferne;
- Die Arbeit wird asynchron, autonom und in großem Umfang durchgeführt;
- Den Bedarf an Geräten decken wir mit der „Build-from-Parts“-Methode, statt neue Geräte zu kaufen;
- Wir verfügen über ein Lager, das es uns ermöglicht, etwas Neues zu schaffen und nicht nur Routinereparaturen durchzuführen.
Daher hatten die weltweiten Beschränkungen, die vielen Unternehmen den physischen Zugang zu ihren Rechenzentren verwehrten, kaum Auswirkungen auf uns. Und was Ersatzteile und Server betrifft, ja, wir haben versucht, einen stabilen Betrieb der Geräte sicherzustellen. Dies geschah jedoch mit dem Ziel, mögliche Zwischenfälle zu verhindern, wenn sich plötzlich herausstellte, dass eine Hardware nicht verfügbar ist. Wir haben dafür gesorgt, dass unsere Reserven gefüllt wurden, ohne den aktuellen Bedarf decken zu wollen.
Zusammenfassend möchte ich sagen, dass unser Ansatz für die Arbeit in der Rechenzentrumsbranche beweist, dass es möglich ist, die Prinzipien eines guten Code-Designs auf die physische Verwaltung eines Rechenzentrums anzuwenden. Und vielleicht finden Sie es interessant.
Original:
Source: habr.com