A fürtök hatékony és megbízható kezelése bármilyen léptékben a Tupperware segítségével
Ma tovább bevezettük a Tupperware-t, a fürtkezelő rendszerünket, amely szinte az összes szolgáltatásunkat futtató szerverek millióira szervezi a konténereket. Először 2011-ben vezettük be a Tupperware-t, és azóta az infrastruktúránk tovább fejlődött egésznek . A Tupperware mindvégig nem állt meg, és velünk együtt fejlődött. Megmutatjuk, hogyan biztosít a Tupperware első osztályú fürtkezelést, beleértve az állapotalapú szolgáltatások kényelmes támogatását, egyetlen vezérlőpanelt az összes adatközponthoz, valamint a kapacitás valós időben történő elosztását a szolgáltatások között. Megosztjuk a tanulságokat is, amelyeket infrastruktúránk fejlődése során tanultunk.
A Tupperware különféle feladatokat lát el. Az alkalmazásfejlesztők az alkalmazások szállítására és kezelésére használják. Az alkalmazáskódot és a függőségeket egy képbe csomagolja, és konténerként szállítja a szerverekre. A tárolók elszigetelést biztosítanak az ugyanazon a szerveren lévő alkalmazások között, így a fejlesztők kezelik az alkalmazás logikáját, és nem kell aggódniuk a kiszolgálók keresése vagy a frissítések kezelése miatt. A Tupperware a szerver teljesítményét is figyeli, és ha hibát talál, konténereket küld át a problémás szerverről.
A kapacitástervező mérnökök a Tupperware segítségével osztják ki a szerverkapacitást a csapatok között a költségvetés és a korlátok alapján. A szerver kihasználtságának javítására is használják. Az adatközpontok üzemeltetői a Tupperware-hez fordulnak a konténerek megfelelő elosztása érdekében az adatközpontok között, és a karbantartás során leállítják vagy áthelyezik a konténereket. Ennek köszönhetően a szerverek, hálózatok és berendezések karbantartása minimális emberi beavatkozást igényel.
Tupperware architektúra
A Tupperware PRN architektúrája adatközpontjaink egyik régiója. A régió számos közeli adatközpont épületből áll (PRN1 és PRN2). Tervezzük egy vezérlőpult létrehozását, amely egy régió összes szerverét kezeli.
Az alkalmazásfejlesztők Tupperware-munkák formájában nyújtanak szolgáltatásokat. Egy feladat több tárolóból áll, és ezek általában ugyanazt az alkalmazáskódot futtatják.
A Tupperware felelős a konténerek ellátásáért és életciklusuk kezeléséért. Több összetevőből áll:
- A Tupperware frontend API-kat biztosít a felhasználói felülethez, a CLI-hez és más automatizálási eszközökhöz, amelyeken keresztül kapcsolatba léphet a Tupperware-rel. A teljes belső struktúrát elrejtik a Tupperware-munkatulajdonosok elől.
- A Tupperware Scheduler egy vezérlőpult, amely a konténer és a munka életciklusának kezeléséért felelős. Regionális és globális szinten kerül telepítésre, ahol a regionális ütemező egy régióban, a globális ütemező pedig különböző régiók kiszolgálóit kezeli. Az ütemező szilánkokra van felosztva, és mindegyik szilánk egy sor feladatot kezel.
- A Tupperware Scheduler Proxyja elrejti a belső szilánkosodást, és kényelmes egyetlen üvegtáblát biztosít a Tupperware felhasználók számára.
- A Tupperware allokátor konténereket rendel a szerverekhez. Az ütemező kezeli a tárolók leállítását, indítását, frissítését és feladatátvételét. Jelenleg egy allokátor képes kezelni az egész régiót anélkül, hogy szilánkokra oszlana. (Jegyezze meg a terminológia különbségét. Például a Tupperware ütemezője megfelel a vezérlőpultnak és a Tupperware allokátort ütemezőnek hívják a Kubernetesben.)
- Az erőforrás-bróker tárolja az igazság forrását a szerver és a szolgáltatás eseményeihez. Minden adatközponthoz egy erőforrás-brókert működtetünk, amely az adott adatközpontban lévő szerverekről minden információt tárol. Az erőforrás-bróker és a kapacitáskezelő rendszer vagy az erőforrás-ellátó rendszer dinamikusan dönti el, hogy melyik ütemező kézbesítés vezérli melyik kiszolgálót. Az állapotellenőrzési szolgáltatás figyeli a szervereket, és az erőforrás-brókerben tárolja az állapotukra vonatkozó adatokat. Ha egy kiszolgálónak problémái vannak, vagy karbantartásra van szüksége, az erőforrás-bróker utasítja az allokátort és az ütemezőt, hogy állítsák le a tárolókat, vagy helyezzék át őket más kiszolgálókra.
- A Tupperware Agent egy minden kiszolgálón futó démon, amely kezeli a tárolók kiépítését és eltávolítását. Az alkalmazások egy tárolóban futnak, ami nagyobb elszigeteltséget és reprodukálhatóságot biztosít számukra. Tovább Már leírtuk, hogyan jönnek létre az egyes Tupperware-tárolók képek, btrfs, cgroupv2 és systemd használatával.
A Tupperware megkülönböztető jellemzői
A Tupperware sok tekintetben hasonló más fürtkezelő rendszerekhez, mint például a Kubernetes és , de vannak különbségek is:
- Beépített támogatás az állapotalapú szolgáltatásokhoz.
- Egyetlen vezérlőpult a különböző adatközpontokban lévő szerverek számára a konténerek kézbesítésének automatizálására a szándék, a fürtök leszerelése és a karbantartás alapján.
- A vezérlőpult egyértelmű felosztása a nagyításhoz.
- Az elasztikus számítástechnika lehetővé teszi az energia valós időben történő elosztását a szolgáltatások között.
Ezeket a nagyszerű szolgáltatásokat azért fejlesztettük ki, hogy támogassuk a különféle állapot nélküli és állapottartó alkalmazásokat egy hatalmas globális megosztott szerverflottán.
Beépített támogatás az állapotalapú szolgáltatásokhoz.
A Tupperware számos kritikus állapotjelző szolgáltatást üzemeltet, amelyek állandó termékadatokat tárolnak a Facebook, Instagram, Messenger és WhatsApp számára. Ezek lehetnek kulcs-érték párok nagy tárolói (pl. ) és megfigyelő adattárak (pl. и ). Az állapotalapú szolgáltatások fenntartása nem egyszerű, mert a rendszernek biztosítania kell, hogy a konténerek ellátása kibírja a nagymértékű fennakadásokat, beleértve a hálózat- vagy áramszüneteket is. És bár a hagyományos technikák, például a konténerek elosztása a hibatartományok között, jól működnek az állapot nélküli szolgáltatásoknál, az állapotalapú szolgáltatásoknak további támogatásra van szükségük.
Például, ha egy szerverhiba miatt egy adatbázis-replika elérhetetlenné válik, engedélyeznie kell az automatikus karbantartást, amely 50 kiszolgáló magját frissíti a 10 50-es készletből? A helyzettől függ. Ha az 2 szerver közül az egyiknek ugyanannak az adatbázisnak egy másik replikája van, jobb, ha vár, és nem veszít el XNUMX replikát egyszerre. Ahhoz, hogy dinamikusan dönthessünk a rendszer karbantartásáról és teljesítményéről, információra van szükségünk a belső adatreplikációról és az egyes állapottartó szolgáltatások elhelyezési logikájáról.
A TaskControl felület lehetővé teszi, hogy az állapotjelző szolgáltatások befolyásolják az adatok elérhetőségét befolyásoló döntéseket. Ezen a felületen az ütemező értesíti a külső alkalmazásokat a konténerműveletekről (újraindítás, frissítés, migráció, karbantartás). Az állapotjelző szolgáltatás egy vezérlőt valósít meg, amely közli a Tupperware-rel, hogy mikor biztonságos az egyes műveletek végrehajtása, és ezek a műveletek ideiglenesen felcserélhetők vagy késleltethetők. A fenti példában az adatbázisvezérlő utasíthatja a Tupperware-t, hogy frissítse az 49 szerver közül 50-et, de egy adott szervert (X) egyelőre békén hagy. Ennek eredményeként, ha a kernel frissítési időszaka lejár, és az adatbázis továbbra sem tudja visszaállítani a problémás replikát, a Tupperware továbbra is frissíti az X szervert.
A Tupperware számos állapotjelző szolgáltatása nem közvetlenül, hanem a ShardManageren keresztül használja a TaskControl-t, amely egy közös platform az állapotjelző szolgáltatások létrehozására a Facebookon. A Tupperware segítségével a fejlesztők meghatározhatják szándékukat, hogy pontosan hogyan kell elosztani a konténereket az adatközpontok között. A ShardManager segítségével a fejlesztők meghatározzák a szándékukat arra vonatkozóan, hogy az adatszilánkokat hogyan kell elosztani a tárolók között. A ShardManager tisztában van alkalmazásai adatelhelyezésével és replikációjával, és a TaskControl felületen keresztül kommunikál a Tupperware-rel a konténerműveletek ütemezéséhez az alkalmazások közvetlen bevonása nélkül. Ez az integráció nagyban leegyszerűsíti az állapotalapú szolgáltatások kezelését, de a TaskControl többre is képes. Például kiterjedt webes rétegünk állapot nélküli, és a TaskControl segítségével dinamikusan állítja be a tárolók frissítési sebességét. Végül is naponta a rendelkezésre állás veszélyeztetése nélkül.
Szerverek kezelése adatközpontokban
Amikor a Tupperware 2011-ben először megjelent, minden szerverfürtöt külön ütemező kezelt. Akkoriban a Facebook-fürt egy hálózati kapcsolóhoz csatlakoztatott szerverállványok csoportja volt, és az adatközpontban több fürt is helyet kapott. Az ütemező csak egy fürtben tudta kezelni a kiszolgálókat, ami azt jelenti, hogy a feladat nem terjedhet több fürtre. Nőtt az infrastruktúránk, egyre gyakrabban írtunk le klasztereket. Mivel a Tupperware nem tudta változtatás nélkül áthelyezni a munkát a leszerelt fürtből más fürtökbe, sok erőfeszítést és gondos koordinációt igényelt az alkalmazásfejlesztők és az adatközpontok üzemeltetői között. Ez a folyamat erőforrás-pazarláshoz vezetett, amikor a szerverek hónapokig tétlenek voltak a leszerelési eljárások miatt.
Létrehoztunk egy erőforrás-brókert a klaszter leszerelési probléma megoldására és más típusú karbantartási feladatok koordinálására. Az erőforrás-bróker nyomon követi a kiszolgálóhoz kapcsolódó összes fizikai információt, és dinamikusan dönti el, hogy melyik ütemező irányítja az egyes szervereket. A kiszolgálók és az ütemezők dinamikus összekapcsolása lehetővé teszi az ütemező számára, hogy különböző adatközpontokban lévő szervereket kezeljen. Mivel a Tupperware-feladatok már nem korlátozódnak egyetlen fürtre, a Tupperware-felhasználók meghatározhatják, hogy a konténereket hogyan kell elosztani a hibatartományok között. Például egy fejlesztő kinyilváníthatja szándékát (mondjuk: "futtassa a munkámat 2 hibatartományon a PRN régióban") anélkül, hogy konkrét rendelkezésre állási zónákat határozna meg. A Tupperware maga is talál megfelelő szervereket ennek a szándéknak a megvalósítására, még akkor is, ha a fürt vagy a szolgáltatás leáll.
A teljes globális rendszer támogatásához méretezhető
A történelem során az infrastruktúránk több száz dedikált szerverkészletre oszlott az egyes csapatok számára. A széttagoltság és a szabványok hiánya miatt magasak voltak az üzemeltetési költségek, és a tétlen szerverek ismét nehezebben használhatók. A tavalyi konferencián bemutattuk , aminek az infrastruktúránkat egy nagy, egyetlen szerverparkban kell egyesítenie. De egyetlen szerverparknak megvannak a maga nehézségei. Meg kell felelnie bizonyos követelményeknek:
- Méretezhetőség. Infrastruktúránk bővült, ahogy minden régióban adatközpontokat adtunk hozzá. A szerverek kisebbek és energiatakarékosabbak lettek, így minden régióban sokkal több van belőlük. Ennek eredményeként régiónként egyetlen ütemező nem tudja kezelni az egyes régiókban több százezer kiszolgálón futtatható tárolók számát.
- Megbízhatóságát. Még ha az ütemezőt is lehet ennyire felnagyítani, az ütemező nagy hatóköre azt jelenti, hogy nagyobb a hibakockázat, és a tárolók egész régiója kezelhetetlenné válhat.
- Hibatűrés. Hatalmas infrastruktúra-hiba esetén (például az ütemezőt futtató szerverek hálózati hiba vagy áramszünet miatt meghibásodnak), a negatív következmények csak a régió szervereinek egy részét érintik.
- Egyszerű használat. Úgy tűnhet, hogy egy régióhoz több független ütemezőt kell futtatnia. A kényelem szempontjából azonban egyetlen belépési pont a régió megosztott készletébe megkönnyíti a kapacitás és a munkahelyek kezelését.
Az ütemezőt szilánkokra osztottuk, hogy megoldjuk a nagy megosztott készlet fenntartásával kapcsolatos problémákat. Minden ütemező szilánk a saját feladatkészletét kezeli a régióban, és ez csökkenti az ütemezőhöz kapcsolódó kockázatot. Ahogy a megosztott készlet növekszik, több ütemező szilánkot is hozzáadhatunk. A Tupperware-felhasználók számára a szilánkok és az ütemező proxyk egy vezérlőpultnak tűnnek. Nem kell egy csomó szilánkkal dolgozniuk, amelyek a feladatokat rendezik. Az ütemező szilánkok alapvetően különböznek a korábban használt fürtütemezőktől, amikor a vezérlőpult particionálása nem történt meg a kiszolgálók megosztott készletének statikus felosztása nélkül a hálózati topológia szerint.
Növelje a használat hatékonyságát az elasztikus számítástechnikával
Minél nagyobb az infrastruktúránk, annál fontosabb a szervereink hatékony használata az infrastruktúra költségeinek optimalizálása és a terhelés csökkentése érdekében. A szerverhasználat hatékonyságának növelésének két módja van:
- Rugalmas számítástechnika – csökkentheti az online szolgáltatásokat csendes órákban, és használhat felszabadított szervereket offline munkaterhelésekhez, például gépi tanuláshoz és MapReduce-feladatokhoz.
- Túlterhelés – Helyezze el az online szolgáltatásokat és a kötegelt munkaterheléseket ugyanazokon a kiszolgálókon, hogy a kötegelt munkaterhelések alacsony prioritásúak legyenek.
Adatközpontjaink szűk keresztmetszete az . Ezért előnyben részesítjük a kisméretű, energiahatékony szervereket, amelyek együttesen nagyobb feldolgozási teljesítményt biztosítanak. Sajnos a kis szervereken kevés CPU-val és memóriával a túlterhelés kevésbé hatékony. Természetesen több konténernyi kis szolgáltatást is elhelyezhetünk egy kis, energiahatékony szerveren, amelyek kevés processzorerőforrást és memóriát fogyasztanak, de a nagy szolgáltatások teljesítménye ebben a helyzetben alacsony lesz. Ezért azt tanácsoljuk a nagy szolgáltatásaink fejlesztőinek, hogy optimalizálják azokat úgy, hogy a teljes szervert használják.
Alapvetően rugalmas számítástechnikával javítjuk a felhasználás hatékonyságát. Számos fő szolgáltatásunk, mint például a hírfolyam, az üzenetküldés és a webes front-end szint a napszaktól függően változik. Csendes órákban szándékosan csökkentjük az online szolgáltatásokat, és felszabadított szervereket használunk offline munkaterhelésekhez, például gépi tanuláshoz és MapReduce-feladatokhoz.
Tapasztalatból tudjuk, hogy az a legjobb, ha a teljes szervereket rugalmas kapacitás egységeiként biztosítjuk, mert a nagy szolgáltatások a rugalmas kapacitás jelentős adományozói és fő fogyasztói, és teljes szerverek használatára vannak optimalizálva. Amikor a kiszolgálót csendes órákban felszabadítják az online szolgáltatásból, az erőforrás-bróker bérbe adja a kiszolgálót az ütemezőnek, hogy offline terheléseket futtasson rajta. Ha az online szolgáltatás csúcsterhelést tapasztal, az erőforrás-bróker gyorsan visszahívja a kölcsönzött szervert, és az ütemezővel együtt visszaküldi azt az online szolgáltatásnak.
Tanulságok és tervek a jövőre nézve
Az elmúlt 8 évben fejlesztettük a Tupperware-t, hogy lépést tartsunk a Facebook gyors növekedésével. Megosztjuk a tanultakat, és reméljük, hogy másoknak is segíteni fognak a gyorsan növekvő infrastruktúrák kezelésében:
- Hozzon létre egy rugalmas kapcsolatot a központ és az általa kezelt szerverek között. Ez a rugalmasság lehetővé teszi a vezérlőpanel számára, hogy felügyelje a különböző adatközpontokban lévő szervereket, segít automatizálni a fürtök leszerelését és karbantartását, valamint lehetővé teszi a dinamikus kapacitáselosztást rugalmas számítástechnikával.
- Egyetlen vezérlőpulttal a régióban kényelmesebbé válik a feladatok kezelése, és könnyebben kezelhető a nagy megosztott szerverflotta. Vegye figyelembe, hogy a központ egyetlen belépési pontot tart fenn, még akkor is, ha a belső szerkezete méretarány vagy hibatűrés miatt el van választva.
- Beépülő modul használatával a központ értesítheti a külső alkalmazásokat a konténer közelgő műveleteiről. Ezenkívül az állapotjelző szolgáltatások a beépülő modul felületét használhatják a tárolókezelés testreszabásához. Ezzel a beépülő modullal a vezérlőpanel egyszerűséget biztosít, miközben számos különféle állapotjelző szolgáltatást hatékonyan szolgál ki.
- Meggyőződésünk, hogy a rugalmas számítástechnika, ahol teljes szervereket veszünk el az adományozó szolgáltatásoktól a kötegelt munkák, a gépi tanulás és más nem sürgős szolgáltatások érdekében, az optimális módja a kis, energiahatékony szerverek hatékonyságának javításának.
Még csak most kezdjük a megvalósítást . Jelenleg szervereink körülbelül 20%-a megosztott készletben található. A 100% eléréséhez számos problémát meg kell oldani, ideértve a megosztott tárolókészlet fenntartását, a karbantartás automatizálását, a bérlők közötti követelmények kezelését, a szerverek kihasználtságának javítását és a gépi tanulási munkaterhelések támogatásának javítását. Alig várjuk, hogy vállalhassuk ezeket a kihívásokat és megosszuk sikereinket.
Forrás: will.com