a klaszter ütemezési rendszer fejlődése

a Kubernetes a konténer-hangszerelés területén de facto szabvány lett. A jövőben minden alkalmazást a Kubernetes-en fejlesztenek és futtatnak. Ennek a cikksorozatnak az a célja, hogy mélyreható és egyszerű módon bemutassa a Kubernetes mögöttes megvalósítási elveit.

a Kubernetes egy klaszter ütemezési rendszer. Ez a cikk elsősorban a Kubernetes néhány korábbi klaszterütemezési rendszer-architektúráját mutatja be. A tervezési ötletek és az architektúra jellemzőinek elemzésével tanulmányozhatjuk a klaszter ütemezési rendszer architektúrájának evolúciós folyamatát, valamint a fő problémát, amelyet figyelembe kell venni az architektúra tervezésében. Ez nagyon hasznos lesz a Kubernetes architektúra megértésében.

meg kell értenünk a klaszter ütemezési rendszer néhány alapfogalmát, hogy világossá tegyük, a koncepciót egy példán keresztül magyarázom, tegyük fel, hogy egy elosztott Cron-t akarunk megvalósítani. A rendszer egy sor Linux gazdagépet kezel. A felhasználó meghatározza a feladatot a rendszer által biztosított API-n keresztül. a rendszer rendszeresen elvégzi a megfelelő feladatot a feladat meghatározása alapján, ebben a példában az alapfogalmak az alábbiak:

• fürt: a rendszer által kezelt Linux-gazdagépek erőforráskészletet alkotnak a feladatok futtatásához. Ezt az erőforráskészletet Klaszternek hívják.
• feladat: meghatározza, hogy a fürt hogyan végzi a feladatait. Ebben a példában a Crontab pontosan egy egyszerű feladat, amely egyértelműen megmutatja, hogy mit kell tennie (végrehajtási szkript), milyen időben(időintervallum).Egyes feladatok meghatározása összetettebb, például egy több feladatban elvégzendő feladat meghatározása, valamint a feladatok közötti függőségek, valamint az egyes feladatok erőforrás-követelményei.
• feladat: a feladatot meghatározott teljesítménytevékenységekbe kell ütemezni. Ha meghatározunk egy feladatot, hogy minden este 1 órakor hajtsunk végre egy szkriptet, akkor a minden nap 1 órakor végrehajtott szkriptfolyamat feladat.

a klaszter ütemezési rendszer tervezésekor a rendszer alapvető feladatai két:

• Feladat ütemezése: Miután a feladatokat elküldték a klaszter ütemezési rendszerbe, a beküldött feladatokat külön végrehajtási feladatokra kell osztani, és a feladatok végrehajtási eredményeit nyomon kell követni és nyomon kell követni. Az elosztott Cron példáján az ütemezési rendszernek időben el kell indítania a folyamatot a művelet követelményeinek megfelelően. Ha a folyamat nem sikerül, az újrapróbálkozás szükséges stb. Néhány összetett forgatókönyv, mint például a Hadoop-leképezés csökkentése, az ütemezési rendszernek fel kell osztania a leképezés-csökkentési feladatot a megfelelő többszörös leképezésre és a feladatok csökkentésére, és végül meg kell szereznie a feladat végrehajtásának eredményadatait.
• erőforrás-ütemezés: alapvetően a feladatok és az erőforrások összehangolására szolgál, és a fürtben lévő gazdagépek erőforrás-felhasználása szerint a feladatok futtatásához megfelelő erőforrásokat rendelnek hozzá. Hasonló az operációs rendszer ütemezési algoritmusának folyamatához, az erőforrás-ütemezés fő célja az erőforrás-kihasználtság lehető legnagyobb mértékű javítása és a feladatok várakozási idejének csökkentése a rögzített erőforrás-ellátás feltételei mellett, valamint a feladat vagy a válaszidő késleltetésének csökkentése (ha kötegelt feladatról van szó, akkor a feladat műveletek kezdetétől a végéig tartó időre utal, ha online válasz típusú feladatokról, például webes alkalmazásokról van szó, amely a kérésre adott minden válaszidőre utal), a feladat prioritását figyelembe kell venni, miközben ugyanolyan tisztességes, mint a feladat végrehajtása lehetséges (az erőforrások tisztességesen vannak elosztva minden feladathoz). E célok némelyike ellentmondásos és kiegyensúlyozottnak kell lennie, mint például az erőforrás-felhasználás, a válaszidő, a méltányosság és a prioritások.

Hadoop MRv1

a Map Reduce egyfajta párhuzamos számítási modell. Hadoop képes futtatni ezt a fajta klaszter menedzsment platform párhuzamos számítástechnika. Az MRv1 a Hadoop platform Map Reduce task scheduling motorjának első generációs verziója. Röviden, Az MRv1 felelős a feladat ütemezéséért és végrehajtásáért a fürtön, és visszatér a számítási eredményekhez, amikor a felhasználó meghatároz egy Térképcsökkentési számítást, és elküldi azt a Hadoop-nak. Így néz ki az MRv1 architektúrája:

az architektúra viszonylag egyszerű, a standard Master / Slave architektúrának két alapvető összetevője van:

• a Feladatkövető a fürt fő felügyeleti összetevője, amely mind az erőforrás-ütemezésért, mind a feladatütemezésért felelős.
• Task Tracker fut minden gépen a fürt, amely felelős a futó konkrét feladatokat a fogadó és a jelentés állapotát.

a Hadoop népszerűségével és a különböző igények növekedésével az MRv1 a következő problémákat javítja:

• az előadásnak van egy bizonyos szűk keresztmetszete: a kezelést támogató csomópontok maximális száma 5000, a működést támogató feladatok maximális száma 40 000. Van még mit javítani.
• nem elég rugalmas más tevékenységtípusok kiterjesztéséhez vagy támogatásához. A Map reduce típusú feladatok mellett a Hadoop ökoszisztémában számos más feladattípus is van, amelyeket ütemezni kell, például Spark, Hive, HBase, Storm, Oozie stb. Ezért egy általánosabb ütemezési rendszerre van szükség, amely több tevékenységtípust támogat és bővít
• alacsony erőforrás-kihasználtság: Az MRv1 statikusan konfigurálja az egyes csomópontokhoz rögzített számú résidőt, és minden rés csak az adott feladattípushoz használható (térkép vagy Csökkentés), ami az erőforrás-kihasználtság problémájához vezet. Például számos Térképfeladat sorban áll az üresjárati erőforrásokért, de valójában nagyszámú Reduce slot tétlen a gépek számára.
• több bérleti és több verziójú problémák. Például különböző osztályok futtatnak feladatokat ugyanabban a fürtben, de logikusan el vannak szigetelve egymástól, vagy a Hadoop különböző verzióit futtatják ugyanabban a fürtben.

fonal

fonal(még egy erőforrás tárgyaló) egy második generációs Hadoop ,a fő cél az, hogy megoldja mindenféle problémát MRv1. A fonal építészet így néz ki:

a fonal egyszerű megértése az, hogy a fő fejlesztés az MRv1-hez képest az, hogy az eredeti JobTrack felelősségét két különböző összetevőre osztja: erőforrás-kezelő és Alkalmazásmester

• erőforrás-kezelő: Felelős az erőforrás-ütemezésért, kezeli az összes erőforrást, erőforrásokat rendel a különböző típusú feladatokhoz, és könnyen kiterjeszti az erőforrás-ütemezési algoritmust egy dugaszolható architektúrán keresztül.
• Application Master: felelős a feladatok ütemezéséért. Minden feladat (az úgynevezett application in YARN) elindít egy megfelelő Alkalmazásmestert, amely felelős a feladat meghatározott feladatokra történő felosztásáért, valamint az erőforrás-kezelőtől származó erőforrások igényléséért, a feladat elindításáért, a tevékenység állapotának nyomon követéséért és az eredmények jelentéséért.

vessünk egy pillantást arra, hogy ez az architektúra-változás hogyan oldotta meg az MRv1 különböző problémáit:

• ossza fel a Job Tracker eredeti feladatütemezési felelősségét, ami jelentős teljesítménynövekedést eredményez. Az eredeti Feladatkövető feladatütemezési felelősségét felosztották, hogy az Alkalmazásmester vállalja, és az Alkalmazásmester elosztásra került, minden példány csak egy feladat kérését kezelte, így elősegítette a fürtcsomópontok maximális számát 5000-ről 10 000-re.
• a feladatütemezés, az alkalmazás-fő-és az erőforrás-ütemezés összetevői egymástól függetlenek és dinamikusan jönnek létre a feladatkérések alapján. Egy alkalmazás Mesterpéldány csak egy ütemezési feladatért felelős, ami megkönnyíti a különböző típusú feladatok támogatását.
• bevezetésre kerül a konténerszigetelési technológia, minden feladat elszigetelt tárolóban fut, ami nagymértékben javítja az erőforrások felhasználását a feladat dinamikusan kiosztható erőforrások iránti igényének megfelelően. Ennek hátránya, hogy a YARN erőforrás-gazdálkodásának és elosztásának csak egy dimenziója van a memóriának.

Mesos architecture

a fonal tervezési célja továbbra is a Hadoop ökoszisztéma ütemezésének kiszolgálása. A Mesos célja közelebb kerül, úgy tervezték, hogy egy általános ütemezési rendszer legyen, amely képes kezelni a teljes adatközpont működését. Mint látjuk, a Mesos építészeti tervezése sok fonalat használt referenciaként, a munka ütemezését és az erőforrás ütemezését a különböző modulok külön viselik. De a legnagyobb különbség a Mesos és a fonal között az erőforrások ütemezésének módja, az erőforrás-ajánlatnak nevezett egyedi mechanizmust tervezték. Az erőforrások ütemezésének nyomása tovább csökken, és a feladatok ütemezésének skálázhatósága is növekszik.

a Mesos fő összetevői:

• Mesos Master: ez egy olyan összetevő, amely kizárólag az erőforrás-allokációért és a menedzsment összetevőiért felelős, amely a belső fonalnak megfelelő erőforrás-kezelő. De a működési mód kissé eltér, ha később tárgyaljuk.
• keretrendszer: felelős a feladatok ütemezéséért, a különböző feladattípusoknak megfelelő Keretrendszerük lesz, például a Spark keretrendszer, amely a Spark feladatokért felelős.

a Mesos erőforrás-kínálata

úgy tűnhet, hogy a Mesos és a fonal architektúrák meglehetősen hasonlóak, de valójában az erőforrás-gazdálkodás szempontjából a Mesos mestere nagyon egyedi (és kissé bizarr) erőforrás-kínálati mechanizmussal rendelkezik:

• a fonal húzza: Az erőforrás-kezelő által a YARN-ban biztosított erőforrások passzívak,amikor az erőforrás (Alkalmazásmester) fogyasztóinak erőforrásokra van szükségük, az erőforrások megszerzéséhez az erőforrás-kezelő felületét hívhatja, az erőforrás-kezelő pedig csak passzívan reagál az alkalmazás-mester igényeire.
• a Mesos Push: A Master of Mesos által biztosított források proaktívak. A Mesos mestere rendszeresen kezdeményezi, hogy az összes rendelkezésre álló erőforrást (az úgynevezett erőforrás-ajánlatokat, mostantól ajánlatnak hívom) a keretrendszerbe tolja. Ha vannak olyan feladatok, amelyeket a keretrendszernek végre kell hajtania, akkor nem tud aktívan pályázni erőforrásokra, kivéve, ha az ajánlatok beérkeznek. A keretrendszer kiválaszt egy minősített erőforrást az ajánlatból, amelyet el kell fogadni (ezt az indítványt a Mesos-ban elfogadásnak hívják), és elutasítja a fennmaradó ajánlatokat (ezt az indítványt elutasításnak hívják). Ha nincs elegendő képzett erőforrás ebben az ajánlati körben, meg kell várnunk a mester következő fordulóját, hogy ajánlatot nyújtson.

úgy gondolom, hogy amikor meglátja ezt az aktív ajánlati mechanizmust, akkor ugyanaz az érzés lesz velem. Vagyis a hatékonyság viszonylag alacsony, a következő problémák merülnek fel:

• bármely keret döntési hatékonysága befolyásolja az általános hatékonyságot. A következetesség érdekében a Master egyszerre csak egy keretrendszernek tud ajánlatot adni, és megvárja, amíg a keretrendszer kiválasztja az ajánlatot, mielőtt a többit a következő keretrendszernek adja. Ily módon bármely keret döntéshozatali hatékonysága befolyásolja az általános hatékonyságot.
• sok időt”pazarol” olyan keretrendszerekre, amelyek nem igényelnek erőforrásokat. A Mesos nem igazán tudja, melyik keretnek van szüksége erőforrásokra. Tehát lesz olyan keretrendszer, amelynek erőforrásigénye van, sorban áll az ajánlatért, de az erőforrásigény nélküli keretrendszer gyakran kap ajánlatot.

a fenti kérdésekre válaszul a Mesos néhány mechanizmust biztosított a problémák enyhítésére, például időtúllépést állapított meg a keret számára a döntések meghozatalához, vagy lehetővé tette a keret elutasítását azáltal, hogy elnyomta az állapotot. Mivel ez nem a vita középpontjában áll, a részleteket itt elhanyagolják.

valójában van néhány nyilvánvaló előnye a Mesos-nak az aktív ajánlat ezen mechanizmusának használatával:

• a teljesítmény nyilvánvalóan javult. Egy fürt akár 100 000 csomópontot is támogathat a szimulációs tesztelés szerint, a Twitter termelési környezetében a legnagyobb klaszter 80 000 csomópontot képes támogatni. ennek fő oka, hogy a Mesos Master mechanizmus aktív kínálata tovább egyszerűsíti a Mesos felelősségét. az erőforrás-ütemezés, az erőforrás-feladat-egyeztetés folyamata a Mesos-ban két szakaszra oszlik: az erőforrások kínálata és a feladat felajánlása. A Mesos mester csak az első szakasz befejezéséért felelős, a második szakasz illesztése pedig a keretre marad.
• rugalmasabb és képes megfelelni a feladatütemezés felelősségteljesebb irányelveinek. Például az összes vagy semmi erőforrás-felhasználási stratégiája.

a Mesos DRF ütemezési algoritmusa (domináns erőforrás-méltányosság)

ami a DRF algoritmust illeti, valójában semmi köze a Mesos architektúra megértéséhez, de nagyon fontos és fontos a Mesos-ban, ezért itt egy kicsit elmagyarázom.

mint fentebb említettük, a Mesos egymás után kínál ajánlatot a keretrendszernek, tehát melyik keretet kell kiválasztani, hogy minden alkalommal ajánlatot nyújtson? Ez az alapvető probléma, amelyet a DRF algoritmussal kell megoldani. Az alapelv a méltányosság és a hatékonyság figyelembevétele. A keretrendszer valamennyi erőforrásigényének kielégítése mellett a lehető legigazságosabbnak kell lennie annak elkerülésére, hogy egy keretrendszer túl sok erőforrást emésztjen fel, és más kereteket halálra éheztessen.

a DRF a min-max méltányossági algoritmus egyik változata. Egyszerűen fogalmazva, a legalacsonyabb domináns erőforrás-felhasználású keret kiválasztása az ajánlat minden alkalommal történő biztosításához. Hogyan lehet kiszámítani a keret domináns erőforrás-felhasználását? A keretrendszer által elfoglalt összes erőforrás-típus közül a legalacsonyabb erőforrás-kihasználtsági arányú erőforrás-típus kerül kiválasztásra domináns erőforrásként. Erőforrás-kihasználtsága pontosan a keretrendszer domináns erőforrás-felhasználása. Például a keretrendszer CPU-ja a teljes erőforrás 20% – át, a memória 30% – át és a lemez 10% – át foglalja el. Tehát a keretrendszer domináns erőforrás-felhasználása 10% lesz, a hivatalos kifejezés a lemezt domináns erőforrásnak nevezi, ezt a 10% – ot pedig domináns erőforrás-használatnak nevezzük.

a DRF végső célja az erőforrások egyenlő elosztása az összes keretrendszer között. Ha egy X keretrendszer túl sok erőforrást fogad el ebben az ajánlati körben, akkor sokkal hosszabb időt vesz igénybe a következő ajánlat lehetősége. A gondos olvasók azonban úgy találják, hogy van egy feltételezés ebben az algoritmusban, vagyis miután a keret elfogadja az erőforrásokat, gyorsan felszabadítja őket, különben két következmény lesz:

• más keretek éhen halnak. Az egyik a keretrendszer egyszerre fogadja el a fürt erőforrásainak nagy részét, és a feladat megszakítás nélkül fut, így az erőforrások nagy részét az a keretrendszer foglalja el, és más keretrendszerek már nem kapják meg az erőforrásokat.
• Éheztesse magát halálra. Mivel ennek a keretrendszernek a domináns erőforrás-felhasználása mindig nagyon magas, így hosszú időre nincs esély az ajánlat megszerzésére, így több feladat nem futtatható.

tehát a Mesos csak rövid feladatok ütemezésére alkalmas, a Mesos-t eredetileg az adatközpontok rövid feladataira tervezték.

összefoglaló

a nagy architektúrából az összes ütemezési rendszer architektúrája Master/Slave architektúra, a Slave end minden gépen telepítve van a menedzsment követelményével, amelyet a gazdagép információinak gyűjtésére és a gazdagépen végzett feladatok elvégzésére használnak. A mester elsősorban az erőforrás-ütemezésért és a feladatütemezésért felelős. Az erőforrás-ütemezés magasabb követelményeket támaszt a teljesítménnyel, a feladatütemezés pedig magasabb követelményeket támaszt a skálázhatósággal kapcsolatban. Az általános tendencia az, hogy megvitassák a kétféle vám szétválasztása, és töltse ki őket a különböző összetevők.