Efficiënt en betrouwbaar beheer van clusters op elke schaal met Tupperware
Vandaag op we hebben Tupperware geïntroduceerd, ons clusterbeheersysteem dat containers orkestreert over miljoenen servers waarop bijna al onze services draaien. We hebben Tupperware voor het eerst geïmplementeerd in 2011 en sindsdien is onze infrastructuur gegroeid tot geheel . Al die tijd heeft Tupperware niet stil gestaan en met ons mee ontwikkeld. We laten u zien hoe Tupperware eersteklas clusterbeheer biedt, inclusief handige ondersteuning voor stateful services, één enkel controlepaneel voor alle datacenters en de mogelijkheid om capaciteit in realtime tussen services te verdelen. We zullen ook de lessen delen die we hebben geleerd naarmate onze infrastructuur evolueert.
Tupperware voert verschillende taken uit. Applicatieontwikkelaars gebruiken het om applicaties te leveren en te beheren. Het verpakt de applicatiecode en afhankelijkheden in een afbeelding en levert deze als containers aan servers. Containers bieden isolatie tussen applicaties op dezelfde server, zodat ontwikkelaars met de applicatielogica kunnen omgaan en zich geen zorgen hoeven te maken over het vinden van servers of het beheren van updates. Tupperware houdt ook de prestaties van de server in de gaten en als er een storing wordt geconstateerd, worden containers van de problematische server overgezet.
Capaciteitsplanningsingenieurs gebruiken Tupperware om servercapaciteit aan teams toe te wijzen op basis van budget en beperkingen. Ze gebruiken het ook om het servergebruik te verbeteren. Exploitanten van datacenters wenden zich tot Tupperware om containers op de juiste manier over datacenters te verdelen en containers te stoppen of te verplaatsen tijdens onderhoud. Hierdoor vereist het onderhoud van servers, netwerken en apparatuur minimale menselijke tussenkomst.
Tupperware-architectuur
Tupperware PRN-architectuur is een van de regio's van onze datacenters. De regio bestaat uit verschillende nabijgelegen datacentergebouwen (PRN1 en PRN2). We zijn van plan één controlepaneel te maken dat alle servers in één regio zal beheren.
Applicatieontwikkelaars leveren diensten in de vorm van Tupperware-banen. Een taak bestaat uit meerdere containers en deze voeren doorgaans allemaal dezelfde applicatiecode uit.
Tupperware is verantwoordelijk voor het inrichten van containers en het beheren van hun levenscyclus. Het bestaat uit verschillende componenten:
- De Tupperware-frontend biedt API's voor de gebruikersinterface, CLI en andere automatiseringstools waarmee u met Tupperware kunt communiceren. Ze verbergen de hele interne structuur voor Tupperware-baaneigenaren.
- Tupperware Scheduler is een controlepaneel dat verantwoordelijk is voor het beheer van de container- en taaklevenscyclus. Het wordt ingezet op regionaal en mondiaal niveau, waarbij de regionale planner servers in één regio beheert en de globale planner servers uit verschillende regio's beheert. De planner is verdeeld in shards, en elke shard beheert een reeks taken.
- Tupperware's Scheduler Proxy verbergt de interne sharding en biedt een handig enkel venster voor Tupperware-gebruikers.
- De Tupperware-allocator wijst containers toe aan servers. De planner zorgt voor het stoppen, starten, bijwerken en failover van containers. Momenteel kan één allocator de hele regio beheren zonder deze in shards op te splitsen. (Let op het verschil in terminologie. De planner in Tupperware komt bijvoorbeeld overeen met het controlepaneel in en de Tupperware-allocator wordt in Kubernetes een planner genoemd.)
- De resource broker slaat de bron van waarheid op voor de server- en servicegebeurtenissen. Voor elk datacenter hebben we één resource broker, waarin alle informatie over de servers in dat datacenter wordt opgeslagen. De resource broker en het capaciteitsbeheersysteem, of het resource provisioning-systeem, beslissen dynamisch welke planner-levering welke server bestuurt. De statuscontroleservice bewaakt servers en slaat gegevens over hun gezondheid op in de resourcebroker. Als een server problemen heeft of onderhoud nodig heeft, vertelt de resource broker de allocator en planner om de containers te stoppen of naar andere servers te verplaatsen.
- De Tupperware Agent is een daemon die op elke server draait en die het inrichten en verwijderen van containers afhandelt. Applicaties draaien in een container, waardoor ze beter geïsoleerd en reproduceerbaar zijn. Op We hebben al beschreven hoe individuele Tupperware-containers worden gemaakt met behulp van images, btrfs, cgroupv2 en systemd.
Onderscheidende kenmerken van Tupperware
Tupperware is in veel opzichten vergelijkbaar met andere clusterbeheersystemen zoals Kubernetes en , maar er zijn ook verschillen:
- Ingebouwde ondersteuning voor stateful services.
- Eén controlepaneel voor servers in verschillende datacenters om de levering van containers op basis van intentie, het buiten gebruik stellen van clusters en het onderhoud te automatiseren.
- Duidelijke indeling van het bedieningspaneel voor zoomen.
- Met Elastic Computing kunt u de stroom in realtime tussen services verdelen.
We hebben deze coole functies ontwikkeld om een verscheidenheid aan staatloze en stateful applicaties te ondersteunen op een enorm wereldwijd gedeeld serverpark.
Ingebouwde ondersteuning voor stateful services.
Tupperware exploiteert een verscheidenheid aan kritische stateful services die persistente productgegevens opslaan voor Facebook, Instagram, Messenger en WhatsApp. Dit kunnen grote voorraden sleutel-waardeparen zijn (bijv. ) en het monitoren van gegevensopslagplaatsen (bijvoorbeeld и ). Het onderhouden van stateful services is niet eenvoudig, omdat het systeem ervoor moet zorgen dat de aanvoer van containers bestand is tegen grootschalige verstoringen, waaronder netwerkstoringen of stroomstoringen. En hoewel conventionele technieken, zoals het distribueren van containers over foutdomeinen, goed werken voor staatloze services, hebben stateful services aanvullende ondersteuning nodig.
Als een serverfout bijvoorbeeld één databasereplica onbeschikbaar maakt, moet u dan automatisch onderhoud inschakelen dat de kernen op 50 servers uit een pool van 10 bijwerkt? Ligt aan de situatie. Als een van deze 50 servers nog een replica van dezelfde database heeft, is het beter om te wachten en niet in één keer twee replica's kwijt te raken. Om dynamisch beslissingen te kunnen nemen over systeemonderhoud en -prestaties, hebben we informatie nodig over interne gegevensreplicatie en de plaatsingslogica van elke stateful service.
Met de TaskControl-interface kunnen stateful services beslissingen beïnvloeden die van invloed zijn op de beschikbaarheid van gegevens. Met behulp van deze interface informeert de planner externe applicaties over containerbewerkingen (herstarten, updaten, migratie, onderhoud). Een stateful service implementeert een controller die Tupperware vertelt wanneer het veilig is om elke bewerking uit te voeren, en deze bewerkingen kunnen tijdelijk worden verwisseld of uitgesteld. In het bovenstaande voorbeeld kan de databasecontroller Tupperware opdracht geven om 49 van de 50 servers bij te werken, maar een specifieke server (X) voorlopig met rust te laten. Als gevolg hiervan, als de kernelupdateperiode verstrijkt en de database de problematische replica nog steeds niet kan herstellen, zal Tupperware de X-server nog steeds updaten.
Veel stateful services in Tupperware gebruiken TaskControl niet rechtstreeks, maar via ShardManager, een gemeenschappelijk platform voor het creëren van stateful services op Facebook. Met Tupperware kunnen ontwikkelaars precies aangeven hoe containers over datacenters moeten worden gedistribueerd. Met ShardManager specificeren ontwikkelaars hun intentie voor de manier waarop gegevensscherven over containers moeten worden gedistribueerd. ShardManager is op de hoogte van de gegevensplaatsing en replicatie van zijn applicaties en communiceert met Tupperware via de TaskControl-interface om containerbewerkingen te plannen zonder directe betrokkenheid van de applicatie. Deze integratie vereenvoudigt het beheer van stateful services aanzienlijk, maar TaskControl is tot meer in staat. Onze uitgebreide weblaag is bijvoorbeeld staatloos en gebruikt TaskControl om de snelheid van updates van containers dynamisch aan te passen. Eventueel per dag zonder dat dit ten koste gaat van de beschikbaarheid.
Beheer van servers in datacenters
Toen Tupperware in 2011 voor het eerst werd gelanceerd, werd elk servercluster beheerd door een afzonderlijke planner. Destijds was een Facebook-cluster een groep serverracks die op één netwerkswitch waren aangesloten, en het datacenter huisvestte verschillende clusters. De planner kon slechts servers in één cluster beheren, wat betekent dat de taak zich niet over meerdere clusters kon verspreiden. Onze infrastructuur groeide, we schreven steeds meer clusters af. Omdat Tupperware de taak niet zonder wijzigingen van het buiten gebruik gestelde cluster naar andere clusters kon verplaatsen, vergde dit veel inspanning en zorgvuldige coördinatie tussen applicatieontwikkelaars en datacenterexploitanten. Dit proces resulteerde in verspilling van bronnen wanneer servers maandenlang inactief waren vanwege ontmantelingsprocedures.
We hebben een resource broker gecreëerd om het probleem van de ontmanteling van clusters op te lossen en andere soorten onderhoudstaken te coördineren. De resource broker houdt alle fysieke informatie bij die aan een server is gekoppeld en beslist dynamisch welke planner elke server beheert. Door servers dynamisch te koppelen aan planners kan de planner servers in verschillende datacenters beheren. Omdat een Tupperware-taak niet langer beperkt is tot één cluster, kunnen Tupperware-gebruikers opgeven hoe containers over foutdomeinen moeten worden verdeeld. Een ontwikkelaar kan bijvoorbeeld zijn bedoeling kenbaar maken (zeg: "mijn taak uitvoeren op twee foutdomeinen in de PRN-regio") zonder specifieke beschikbaarheidszones op te geven. Tupperware zal zelf geschikte servers vinden om dit voornemen uit te voeren, ook als het cluster of de dienst buiten gebruik wordt gesteld.
Schaalbaar om het hele mondiale systeem te ondersteunen
Historisch gezien is onze infrastructuur verdeeld in honderden speciale serverpools voor individuele teams. Door fragmentatie en gebrek aan standaarden hadden we hoge operationele kosten en waren inactieve servers moeilijker opnieuw te gebruiken. Op de conferentie van vorig jaar wij presenteerden , die onze infrastructuur zou moeten verenigen in één groot serverpark. Maar een enkel serverpark heeft zijn eigen problemen. Het moet aan bepaalde eisen voldoen:
- Schaalbaarheid. Onze infrastructuur groeide naarmate we datacenters in elke regio toevoegden. Servers zijn kleiner en energiezuiniger geworden, waardoor er in elke regio veel meer zijn. Als gevolg daarvan kan één enkele planner per regio niet overweg met het aantal containers dat op honderdduizenden servers in elke regio kan draaien.
- Betrouwbaarheid. Zelfs als de planner zoveel kan worden opgeschaald, betekent de grote reikwijdte van de planner dat er een groter risico op fouten bestaat en dat een hele regio met containers onbeheersbaar kan worden.
- Fouttolerantie. In het geval van een grote infrastructuurstoring (de servers waarop de planner draait, vallen bijvoorbeeld uit als gevolg van een netwerkstoring of stroomstoring), zouden de negatieve gevolgen slechts een deel van de servers in de regio moeten treffen.
- Gebruiksgemak. Het lijkt misschien dat u meerdere onafhankelijke planners voor één regio moet uitvoeren. Maar vanuit een gemaksperspectief maakt één enkel toegangspunt tot de gedeelde pool van een regio het gemakkelijker om capaciteit en banen te beheren.
We hebben de planner in shards verdeeld om de problemen bij het onderhouden van een grote gedeelde pool op te lossen. Elke planner-shard beheert zijn eigen set taken in de regio, en dit vermindert het risico dat aan de planner is verbonden. Naarmate de gedeelde pool groeit, kunnen we meer planner-shards toevoegen. Voor Tupperware-gebruikers zien shards en planner-proxy's eruit als één controlepaneel. Ze hoeven niet te werken met een stel scherven die taken orkestreren. Scheduler-shards verschillen fundamenteel van de clusterplanners die we eerder gebruikten, toen het controlepaneel was gepartitioneerd zonder de gedeelde serverpool statisch te verdelen volgens de netwerktopologie.
Verbeter de gebruiksefficiëntie met Elastic Computing
Hoe groter onze infrastructuur, hoe belangrijker het is om onze servers efficiënt te gebruiken om de infrastructuurkosten te optimaliseren en de belasting te verminderen. Er zijn twee manieren om de efficiëntie van het servergebruik te vergroten:
- Elastisch computergebruik: verklein online services tijdens rustige uren en gebruik vrijgekomen servers voor offline workloads, zoals machine learning en MapReduce-taken.
- Overbelasting - Plaats online services en batch-workloads op dezelfde servers, zodat batch-workloads een lage prioriteit hebben.
Het knelpunt in onze datacenters is . Daarom geven wij de voorkeur aan kleine, energiezuinige servers die samen voor meer rekenkracht zorgen. Helaas is overbelasting op kleine servers met weinig CPU en geheugen minder effectief. Natuurlijk kunnen we meerdere containers met kleine services op één kleine, energiezuinige server plaatsen die weinig processorbronnen en geheugen verbruiken, maar grote services zullen in deze situatie lage prestaties leveren. Daarom adviseren wij de ontwikkelaars van onze grote diensten om deze zo te optimaliseren dat ze de volledige servers gebruiken.
Kortom, we verbeteren de gebruiksefficiëntie met behulp van elastisch computergebruik. Veel van onze belangrijkste services, zoals de nieuwsfeed, de berichtenfunctie en de front-end weblaag, variëren afhankelijk van het tijdstip van de dag. We schalen de online services opzettelijk af tijdens rustige uren en gebruiken vrijgekomen servers voor offline werklasten, zoals machine learning en MapReduce-taken.
We weten uit ervaring dat het het beste is om hele servers in te richten als eenheden van elastische capaciteit, omdat grote services zowel grote donoren als grote consumenten van elastische capaciteit zijn, en geoptimaliseerd zijn om hele servers te gebruiken. Wanneer de server tijdens rustige uren wordt vrijgegeven uit de online service, verhuurt de resource broker de server aan de planner om er offline werklasten op uit te voeren. Als de online dienst een piekbelasting ervaart, roept de resource broker snel de geleende server terug en stuurt deze samen met de planner terug naar de online dienst.
Geleerde lessen en plannen voor de toekomst
De afgelopen 8 jaar hebben we Tupperware ontwikkeld om de snelle groei van Facebook bij te houden. We delen wat we hebben geleerd en hopen dat dit anderen zal helpen bij het beheren van snelgroeiende infrastructuren:
- Zet een flexibele verbinding op tussen het bedieningspaneel en de servers die het beheert. Dankzij deze flexibiliteit kan het controlepaneel servers in verschillende datacenters beheren, de buitengebruikstelling en het onderhoud van clusters automatiseren en dynamische capaciteitstoewijzing mogelijk maken met behulp van elastic computing.
- Met één enkel controlepaneel in de regio wordt het handiger om met taken te werken en eenvoudiger een groot gedeeld serverpark te beheren. Houd er rekening mee dat het bedieningspaneel één enkel ingangspunt heeft, zelfs als de interne structuur gescheiden is vanwege schaal- of fouttolerantie.
- Met behulp van een plug-inmodel kan het controlepaneel externe applicaties op de hoogte stellen van aankomende containerbewerkingen. Bovendien kunnen stateful services de plug-ininterface gebruiken om het containerbeheer aan te passen. Met dit plug-inmodel biedt het configuratiescherm eenvoud en biedt het efficiënt veel verschillende stateful services.
- Wij zijn van mening dat elastic computing, waarbij we hele servers weghalen van donordiensten voor batchtaken, machinaal leren en andere niet-dringende diensten, de optimale manier is om de efficiëntie van kleine, energiezuinige servers te verbeteren.
We zijn nog maar net begonnen met de implementatie . Momenteel bevindt ongeveer 20% van onze servers zich in een gedeelde pool. Om 100% te bereiken moeten veel problemen worden aangepakt, waaronder het onderhouden van een gedeelde opslagpool, het automatiseren van onderhoud, het beheren van cross-tenant vereisten, het verbeteren van het servergebruik en het verbeteren van de ondersteuning voor machine learning-workloads. We kunnen niet wachten om deze uitdagingen aan te gaan en onze successen te delen.
Bron: www.habr.com