Effizientes und zuverlässiges Management von Clustern jeder Größenordnung mit Tupperware
Heute auf Wir haben Tupperware eingeführt, unser Cluster-Management-System, das Container auf Millionen von Servern orchestriert, auf denen fast alle unsere Dienste laufen. Wir haben Tupperware erstmals im Jahr 2011 eingesetzt und seitdem ist unsere Infrastruktur stetig gewachsen bis zum Ganzen . Die ganze Zeit über blieb Tupperware nicht stehen und entwickelte sich mit uns weiter. Wir zeigen Ihnen, wie Tupperware erstklassiges Cluster-Management bietet, inklusive komfortabler Unterstützung für Stateful Services, einem einzigen Control Panel für alle Rechenzentren und der Möglichkeit, Kapazitäten zwischen Services in Echtzeit zu verteilen. Wir werden auch die Lehren teilen, die wir im Zuge der Weiterentwicklung unserer Infrastruktur gewonnen haben.
Tupperware übernimmt unterschiedliche Aufgaben. Anwendungsentwickler nutzen es, um Anwendungen bereitzustellen und zu verwalten. Es packt den Anwendungscode und die Abhängigkeiten in ein Image und liefert es als Container an Server. Container sorgen für die Isolierung zwischen Anwendungen auf demselben Server, sodass Entwickler sich um die Anwendungslogik kümmern müssen und sich nicht um die Suche nach Servern oder die Verwaltung von Updates kümmern müssen. Tupperware überwacht außerdem die Leistung des Servers und überträgt bei einem Fehler die Container vom problematischen Server.
Kapazitätsplanungsingenieure verwenden Tupperware, um Serverkapazität basierend auf Budget und Einschränkungen den Teams zuzuweisen. Sie nutzen es auch, um die Serverauslastung zu verbessern. Rechenzentrumsbetreiber wenden sich an Tupperware, um Container ordnungsgemäß auf Rechenzentren zu verteilen und Container während der Wartung anzuhalten oder zu verschieben. Dadurch erfordert die Wartung von Servern, Netzwerken und Geräten nur minimale menschliche Eingriffe.
Tupperware-Architektur
Die Tupperware PRN-Architektur ist einer der Bereiche unserer Rechenzentren. Die Region besteht aus mehreren Rechenzentrumsgebäuden (PRN1 und PRN2), die sich in der Nähe befinden. Wir planen, ein einziges Control Panel zu erstellen, das alle Server in einer Region verwaltet.
Anwendungsentwickler erbringen Dienstleistungen in Form von Tupperware-Jobs. Ein Job besteht aus mehreren Containern, und alle führen normalerweise denselben Anwendungscode aus.
Tupperware ist für die Bereitstellung von Containern und die Verwaltung ihres Lebenszyklus verantwortlich. Es besteht aus mehreren Komponenten:
- Das Tupperware-Frontend bietet APIs für die Benutzeroberfläche, CLI und andere Automatisierungstools, über die Sie mit Tupperware interagieren können. Sie verbergen die gesamte interne Struktur vor Tupperware-Jobbesitzern.
- Tupperware Scheduler ist ein Control Panel, das für die Verwaltung des Container- und Job-Lebenszyklus verantwortlich ist. Es wird auf regionaler und globaler Ebene bereitgestellt, wobei der regionale Scheduler Server in einer Region und der globale Scheduler Server aus verschiedenen Regionen verwaltet. Der Scheduler ist in Shards unterteilt und jeder Shard verwaltet eine Reihe von Jobs.
- Der Scheduler-Proxy von Tupperware verbirgt das interne Sharding und bietet Tupperware-Benutzern eine praktische zentrale Übersicht.
- Der Tupperware-Allokator weist Container Servern zu. Der Scheduler übernimmt das Stoppen, Starten, Aktualisieren und Failover von Containern. Derzeit kann ein Allokator die gesamte Region verwalten, ohne sie in Shards aufzuteilen. (Beachten Sie den Unterschied in der Terminologie. Beispielsweise entspricht der Scheduler in Tupperware dem Control Panel in , und der Tupperware-Allokator wird in Kubernetes als Scheduler bezeichnet.)
- Der Ressourcenbroker speichert die Quelle der Wahrheit für die Server- und Dienstereignisse. Wir betreiben für jedes Rechenzentrum einen Ressourcenbroker, der alle Informationen über die Server in diesem Rechenzentrum speichert. Der Ressourcenbroker und das Kapazitätsverwaltungssystem bzw. Ressourcenbereitstellungssystem entscheiden dynamisch, welche Scheduler-Bereitstellung welchen Server steuert. Der Gesundheitsprüfungsdienst überwacht Server und speichert Daten über deren Gesundheit im Ressourcenbroker. Wenn bei einem Server Probleme auftreten oder eine Wartung erforderlich ist, weist der Ressourcenbroker den Allokator und Planer an, die Container anzuhalten oder auf andere Server zu verschieben.
- Der Tupperware-Agent ist ein Daemon, der auf jedem Server läuft und die Bereitstellung und Entfernung von Containern übernimmt. Anwendungen werden in einem Container ausgeführt, was ihnen mehr Isolation und Reproduzierbarkeit verleiht. An Wir haben bereits beschrieben, wie einzelne Tupperware-Container mithilfe von Images, Btrfs, Cgroupv2 und Systemd erstellt werden.
Besonderheiten von Tupperware
Tupperware ähnelt in vielerlei Hinsicht anderen Cluster-Management-Systemen wie Kubernetes und , aber es gibt auch Unterschiede:
- Integrierte Unterstützung für zustandsbehaftete Dienste.
- Ein einziges Bedienfeld für Server in verschiedenen Rechenzentren zur Automatisierung der Lieferung von Containern je nach Absicht, Stilllegung von Clustern und Wartung.
- Klare Aufteilung des Bedienfelds zum Zoomen.
- Mit Elastic Computing können Sie die Leistung zwischen Diensten in Echtzeit verteilen.
Wir haben diese coolen Funktionen entwickelt, um eine Vielzahl zustandsloser und zustandsbehafteter Anwendungen in einer riesigen globalen Flotte gemeinsam genutzter Server zu unterstützen.
Integrierte Unterstützung für zustandsbehaftete Dienste.
Tupperware betreibt eine Vielzahl kritischer Stateful-Dienste, die dauerhafte Produktdaten für Facebook, Instagram, Messenger und WhatsApp speichern. Dabei kann es sich um große Speicher von Schlüssel-Wert-Paaren handeln (z. B. ) und Überwachung von Datenrepositorys (z. B. и ). Die Aufrechterhaltung zustandsbehafteter Dienste ist nicht einfach, da das System sicherstellen muss, dass die Bereitstellung von Containern großflächigen Störungen, einschließlich Netzwerkausfällen oder Stromausfällen, standhalten kann. Und während konventionelle Techniken wie die Verteilung von Containern über Fehlerdomänen für zustandslose Dienste gut funktionieren, benötigen zustandsbehaftete Dienste zusätzliche Unterstützung.
Wenn beispielsweise ein Serverausfall dazu führt, dass ein Datenbankreplikat nicht verfügbar ist, sollten Sie dann die automatische Wartung aktivieren, die die Kerne auf 50 Servern aus einem Pool von 10 aktualisiert? Es kommt auf die Situation an. Wenn einer dieser 50 Server über ein weiteres Replikat derselben Datenbank verfügt, ist es besser zu warten und nicht zwei Replikate gleichzeitig zu verlieren. Um dynamisch Entscheidungen über Systemwartung und -leistung treffen zu können, benötigen wir Informationen über die interne Datenreplikation und die Platzierungslogik jedes zustandsbehafteten Dienstes.
Die TaskControl-Schnittstelle ermöglicht es zustandsbehafteten Diensten, Entscheidungen zu beeinflussen, die sich auf die Datenverfügbarkeit auswirken. Über diese Schnittstelle benachrichtigt der Scheduler externe Anwendungen über Containervorgänge (Neustart, Update, Migration, Wartung). Ein zustandsbehafteter Dienst implementiert einen Controller, der Tupperware mitteilt, wann die einzelnen Vorgänge sicher ausgeführt werden können. Diese Vorgänge können vorübergehend vertauscht oder verzögert werden. Im obigen Beispiel könnte der Datenbankcontroller Tupperware anweisen, 49 der 50 Server zu aktualisieren, einen bestimmten Server (X) jedoch vorerst in Ruhe lassen. Wenn also der Kernel-Aktualisierungszeitraum abläuft und die Datenbank das problematische Replikat immer noch nicht wiederherstellen kann, aktualisiert Tupperware den X-Server trotzdem.
Viele zustandsbehaftete Dienste in Tupperware nutzen TaskControl nicht direkt, sondern über ShardManager, eine gemeinsame Plattform zum Erstellen zustandsbehafteter Dienste auf Facebook. Mit Tupperware können Entwickler ihre Absicht genau festlegen, wie Container über Rechenzentren verteilt werden sollen. Mit ShardManager geben Entwickler ihre Absicht an, wie Daten-Shards auf Container verteilt werden sollen. ShardManager ist sich der Datenplatzierung und -replikation seiner Anwendungen bewusst und kommuniziert über die TaskControl-Schnittstelle mit Tupperware, um Containervorgänge ohne direkte Anwendungsbeteiligung zu planen. Diese Integration vereinfacht die Verwaltung zustandsbehafteter Dienste erheblich, aber TaskControl kann noch mehr. Unsere umfangreiche Webschicht ist beispielsweise zustandslos und nutzt TaskControl, um die Aktualisierungsrate von Containern dynamisch anzupassen. Zusammenfassend pro Tag ohne Beeinträchtigung der Verfügbarkeit.
Verwaltung von Servern in Rechenzentren
Als Tupperware 2011 zum ersten Mal auf den Markt kam, wurde jeder Servercluster von einem separaten Planer verwaltet. Damals war ein Facebook-Cluster eine Gruppe von Server-Racks, die mit einem Netzwerk-Switch verbunden waren, und das Rechenzentrum beherbergte mehrere Cluster. Der Scheduler konnte nur Server in einem Cluster verwalten, was bedeutet, dass der Job nicht auf mehrere Cluster verteilt werden konnte. Unsere Infrastruktur ist gewachsen, wir haben zunehmend Cluster abgeschrieben. Da Tupperware den Auftrag nicht ohne Änderungen vom stillgelegten Cluster auf andere Cluster verlagern konnte, war ein hoher Aufwand und eine sorgfältige Abstimmung zwischen Anwendungsentwicklern und Rechenzentrumsbetreibern erforderlich. Dieser Prozess führte zu einer Verschwendung von Ressourcen, da die Server aufgrund von Stilllegungsverfahren monatelang im Leerlauf waren.
Wir haben einen Ressourcenbroker erstellt, um das Problem der Cluster-Stilllegung zu lösen und andere Arten von Wartungsaufgaben zu koordinieren. Der Ressourcenbroker verfolgt alle mit einem Server verbundenen physischen Informationen und entscheidet dynamisch, welcher Scheduler die einzelnen Server steuert. Durch die dynamische Verknüpfung von Servern mit Schedulern kann der Scheduler Server in verschiedenen Rechenzentren verwalten. Da ein Tupperware-Job nicht mehr auf einen einzelnen Cluster beschränkt ist, können Tupperware-Benutzer festlegen, wie Container auf Fehlerdomänen verteilt werden sollen. Beispielsweise kann ein Entwickler seine Absicht erklären (sagen wir: „Führe meinen Job auf zwei Fehlerdomänen in der PRN-Region aus“), ohne bestimmte Verfügbarkeitszonen anzugeben. Tupperware selbst wird geeignete Server finden, um dieses Vorhaben umzusetzen, auch wenn der Cluster oder Dienst stillgelegt wird.
Skalierbar zur Unterstützung des gesamten globalen Systems
In der Vergangenheit war unsere Infrastruktur in Hunderte von dedizierten Serverpools für einzelne Teams unterteilt. Aufgrund der Fragmentierung und fehlender Standards hatten wir hohe Betriebskosten und ungenutzte Server waren schwieriger wieder zu nutzen. Auf der letztjährigen Konferenz wir präsentierten , der unsere Infrastruktur in einem großen Einzelserverpark vereinen soll. Aber ein einzelner Serverpark hat seine eigenen Schwierigkeiten. Es muss bestimmte Anforderungen erfüllen:
- Skalierbarkeit. Unsere Infrastruktur wuchs, indem wir in jeder Region Rechenzentren hinzufügten. Server sind kleiner und energieeffizienter geworden, sodass es in jeder Region viel mehr davon gibt. Daher kann ein einzelner Scheduler pro Region nicht die Anzahl der Container bewältigen, die auf Hunderttausenden Servern in jeder Region ausgeführt werden können.
- Zuverlässigkeit. Auch wenn der Scheduler so weit skaliert werden kann, bedeutet der große Umfang des Schedulers, dass ein höheres Fehlerrisiko besteht und ein ganzer Bereich von Containern möglicherweise nicht mehr verwaltet werden kann.
- Fehlertoleranz. Im Falle eines großen Infrastrukturausfalls (z. B. Ausfall der Server, auf denen der Scheduler ausgeführt wird, aufgrund eines Netzwerkfehlers oder Stromausfalls) sollten die negativen Folgen nur einen Teil der Server in der Region betreffen.
- Benutzerfreundlichkeit. Es scheint, dass Sie mehrere unabhängige Planer für eine Region ausführen müssen. Aus praktischer Sicht erleichtert ein zentraler Zugangspunkt zum gemeinsamen Pool einer Region jedoch die Verwaltung von Kapazitäten und Arbeitsplätzen.
Wir haben den Scheduler in Shards unterteilt, um die Probleme bei der Verwaltung eines großen gemeinsamen Pools zu lösen. Jeder Scheduler-Shard verwaltet seinen eigenen Satz von Jobs in der Region, wodurch das mit dem Scheduler verbundene Risiko verringert wird. Wenn der gemeinsame Pool wächst, können wir weitere Scheduler-Shards hinzufügen. Für Tupperware-Benutzer sehen Shards und Scheduler-Proxys wie ein einziges Bedienfeld aus. Sie müssen nicht mit einer Reihe von Shards arbeiten, die Aufgaben orchestrieren. Scheduler-Shards unterscheiden sich grundlegend von den Cluster-Schedulern, die wir zuvor verwendet haben, als das Control Panel partitioniert wurde, ohne den gemeinsam genutzten Serverpool entsprechend der Netzwerktopologie statisch aufzuteilen.
Verbessern Sie die Nutzungseffizienz mit Elastic Computing
Je größer unsere Infrastruktur, desto wichtiger ist es, unsere Server effizient zu nutzen, um die Infrastrukturkosten zu optimieren und die Auslastung zu reduzieren. Es gibt zwei Möglichkeiten, die Effizienz der Servernutzung zu steigern:
- Elastic Computing – Reduzieren Sie Online-Dienste in ruhigen Stunden und nutzen Sie frei gewordene Server für Offline-Arbeitslasten wie maschinelles Lernen und MapReduce-Jobs.
- Überlastung – Platzieren Sie Onlinedienste und Batch-Workloads auf denselben Servern, sodass Batch-Workloads mit niedriger Priorität ausgeführt werden.
Der Engpass in unseren Rechenzentren ist . Daher bevorzugen wir kleine, energieeffiziente Server, die zusammen mehr Rechenleistung bereitstellen. Leider ist eine Überlastung auf kleinen Servern mit wenig CPU und Speicher weniger effektiv. Natürlich können wir mehrere Container mit kleinen Diensten auf einem kleinen energieeffizienten Server platzieren, die wenig Prozessorressourcen und Speicher verbrauchen, aber große Dienste werden in dieser Situation eine geringe Leistung haben. Daher raten wir den Entwicklern unserer großen Dienste, diese so zu optimieren, dass sie die gesamten Server nutzen.
Grundsätzlich verbessern wir die Nutzungseffizienz mithilfe von Elastic Computing. Viele unserer wichtigsten Dienste, wie der Newsfeed, die Messaging-Funktion und die Front-End-Webebene, variieren je nach Tageszeit. Wir drosseln Online-Dienste bewusst in ruhigen Stunden und nutzen frei gewordene Server für Offline-Arbeitslasten, wie zum Beispiel maschinelles Lernen und MapReduce-Jobs.
Aus Erfahrung wissen wir, dass es am besten ist, ganze Server als Einheiten elastischer Kapazität bereitzustellen, da große Dienste sowohl große Spender als auch große Verbraucher elastischer Kapazität sind und für die Nutzung ganzer Server optimiert sind. Wenn der Server während ruhiger Stunden vom Online-Dienst freigegeben wird, vermietet der Ressourcenbroker den Server an den Planer, um darauf Offline-Workloads auszuführen. Kommt es zu einer Spitzenauslastung des Online-Dienstes, ruft der Ressourcenbroker den geliehenen Server schnell zurück und gibt ihn zusammen mit dem Scheduler an den Online-Dienst zurück.
Gelernte Erkenntnisse und Pläne für die Zukunft
In den letzten 8 Jahren haben wir Tupperware weiterentwickelt, um mit dem rasanten Wachstum von Facebook Schritt zu halten. Wir teilen, was wir gelernt haben, und hoffen, dass es anderen bei der Verwaltung schnell wachsender Infrastrukturen hilft:
- Richten Sie eine flexible Verbindung zwischen dem Control Panel und den von ihm verwalteten Servern ein. Diese Flexibilität ermöglicht es dem Control Panel, Server in verschiedenen Rechenzentren zu verwalten, hilft bei der Automatisierung der Stilllegung und Wartung von Clustern und ermöglicht die dynamische Kapazitätszuweisung mithilfe von Elastic Computing.
- Mit einem einzigen Bedienfeld in der Region wird die Arbeit an Aufgaben komfortabler und die Verwaltung einer großen, gemeinsam genutzten Serverflotte einfacher. Beachten Sie, dass das Bedienfeld einen einzigen Zugangspunkt beibehält, auch wenn seine interne Struktur aus Gründen der Skalierung oder Fehlertoleranz getrennt ist.
- Mithilfe eines Plugin-Modells kann das Control Panel externe Anwendungen über bevorstehende Containervorgänge informieren. Darüber hinaus können zustandsbehaftete Dienste die Plugin-Schnittstelle nutzen, um die Containerverwaltung anzupassen. Mit diesem Plugin-Modell bietet das Control Panel Einfachheit und bedient gleichzeitig effizient viele verschiedene zustandsbehaftete Dienste.
- Wir glauben, dass Elastic Computing, bei dem wir den Spenderdiensten ganze Server für Batch-Jobs, maschinelles Lernen und andere nicht dringende Dienste entziehen, der optimale Weg ist, die Effizienz kleiner, energieeffizienter Server zu verbessern.
Wir fangen gerade erst mit der Umsetzung an . Derzeit befinden sich etwa 20 % unserer Server in einem gemeinsamen Pool. Um 100 % zu erreichen, müssen viele Probleme angegangen werden, darunter die Wartung eines gemeinsam genutzten Speicherpools, die Automatisierung der Wartung, die Verwaltung mandantenübergreifender Anforderungen, die Verbesserung der Serverauslastung und die Verbesserung der Unterstützung für maschinelle Lernarbeitslasten. Wir können es kaum erwarten, diese Herausforderungen anzunehmen und unsere Erfolge zu teilen.
Source: habr.com