В beszéltünk a Watcher használatára tett kísérleteinkről, és tesztjelentést adtunk. Rendszeresen végzünk ilyen teszteket egy nagyvállalati vagy üzemeltetői felhő kiegyensúlyozására és egyéb kritikus funkcióira vonatkozóan.
A megoldandó probléma összetettsége miatt több cikkre is szükség lehet projektünk leírásához. Ma közzétesszük a sorozat második cikkét, amely a virtuális gépek felhőben való kiegyensúlyozásáról szól.
Néhány terminológia
A VmWare cég bevezette a DRS (Distributed Resource Scheduler) segédprogramot az általa fejlesztett és kínált virtualizációs környezet terhelésének kiegyensúlyozására.
Ahogy írja
„A VMware DRS (Distributed Resource Scheduler) egy olyan segédprogram, amely kiegyensúlyozza a számítási terhelést a rendelkezésre álló erőforrásokkal egy virtuális környezetben. A segédprogram a VMware Infrastructure nevű virtualizációs csomag része.
A VMware DRS segítségével a felhasználók szabályokat határoznak meg a fizikai erőforrások virtuális gépek (VM-ek) közötti elosztására vonatkozóan. A segédprogram manuális vagy automatikus vezérlésre konfigurálható. A VMware erőforráskészletei könnyen hozzáadhatók, eltávolíthatók vagy átszervezhetők. Kívánt esetben az erőforráskészletek elkülöníthetők a különböző üzleti egységek között. Ha egy vagy több virtuális gép terhelése drámaian megváltozik, a VMware DRS újraelosztja a virtuális gépeket a fizikai szerverek között. Ha az általános munkaterhelés csökken, előfordulhat, hogy néhány fizikai szerver átmenetileg offline állapotba kerül, és a terhelés konszolidálható."
Miért van szükség az egyensúlyozásra?
Véleményünk szerint a DRS kötelező felhőszolgáltatás, bár ez nem jelenti azt, hogy mindig és mindenhol a DRS-t kell használni. A felhő céljától és igényeitől függően eltérő követelmények vonatkozhatnak a DRS-re és a kiegyenlítési módszerekre. Előfordulhatnak olyan helyzetek, amikor egyáltalán nincs szükség az egyensúlyozásra. Vagy akár káros is.
Annak érdekében, hogy jobban megértsük, hol és mely ügyfelek számára van szükség a DRS-re, tekintsük át céljaikat és célkitűzéseiket. A felhők nyilvánosra és privátra oszthatók. Íme a fő különbségek a felhők és az ügyfelek céljai között.
Privát felhők / Nagyvállalati ügyfelek
Nyilvános felhők / Közép- és kisvállalkozások, emberek
Az üzemeltető fő kritériuma és céljai
Megbízható szolgáltatás vagy termék biztosítása
A szolgáltatások költségeinek csökkentése a versenypiaci küzdelemben
Szolgáltatási követelmények
Megbízhatóság minden szinten és minden rendszerelemben
Garantált teljesítmény
A virtuális gépeket több kategóriába sorolhatja
Információs és fizikai adatbiztonság
SLA és XNUMX órás támogatás
A szolgáltatás igénybevételének maximális egyszerűsége
Viszonylag egyszerű szolgáltatások
Az adatokért az ügyfél felelőssége
Nem szükséges a virtuális gép prioritása
Információbiztonság a standard szolgáltatások szintjén, felelősség az ügyfélen
Lehetnek hibák
Nincs SLA, a minőség nem garantált
E-mailes támogatás
Biztonsági mentés nem szükséges
Ügyfélfunkciók
Nagyon széles alkalmazási kör.
A vállalatnál örökölt alkalmazások.
Komplex egyedi architektúrák minden ügyfél számára.
Affinitási szabályok.
A szoftver megállás nélkül működik 7x24 módban.
Menet közbeni biztonsági mentési eszközök.
Kiszámítható ciklikus ügyfélterhelés.
Tipikus alkalmazások – hálózati kiegyensúlyozás, Apache, WEB, VPN, SQL
Az alkalmazás egy időre leállhat
Lehetővé teszi a virtuális gépek tetszőleges elosztását a felhőben
Ügyfél biztonsági mentése
Megjósolható statisztikailag átlagolt terhelés nagyszámú ügyféllel.
Az építészetre gyakorolt hatás
Geoclustering
Központi vagy elosztott tárolás
Fenntartott IBS
Helyi adattárolás számítási csomópontokon
Kiegyensúlyozó célok
Egyenletes terheléselosztás
Maximális reakciókészség
Minimális késleltetési idő a kiegyenlítéshez
Egyensúlyozás csak akkor, ha egyértelműen szükséges
Ki kell vinni néhány berendezést megelőző karbantartás céljából
A szolgáltatási költségek és az üzemeltetői költségek csökkentése
Egyes erőforrások letiltása alacsony terhelés esetén
Energiamegtakarítás
Személyi költségek csökkentése
Saját magunk számára a következő következtetéseket vonjuk le:
Privát felhőkhözA nagyvállalati ügyfelek számára biztosított DRS a következő korlátozások mellett használható:
- az információbiztonság és az affinitási szabályok figyelembevétele az egyensúlyozás során;
- elegendő tartalék tartalék rendelkezésre állása baleset esetére;
- a virtuális gép adatai egy központi vagy elosztott tárolórendszeren találhatók;
- döbbenetes adminisztrációs, biztonsági mentési és egyensúlyozási eljárások az idő múlásával;
- kiegyensúlyozás csak az ügyfélállomások összességén belül;
- a kiegyensúlyozás csak erős egyensúlyhiány esetén a leghatékonyabb és legbiztonságosabb virtuális gép-migrációk (végül is a migráció meghiúsulhat);
- a viszonylag „csendes” virtuális gépek kiegyensúlyozása (a „zajos” virtuális gépek migrációja nagyon sokáig tarthat);
- kiegyensúlyozás a „költség” figyelembevételével - a tárolórendszer és a hálózat terhelése (nagy ügyfelek számára testreszabott architektúrákkal);
- kiegyensúlyozás az egyes virtuális gépek egyéni viselkedési jellemzőinek figyelembevételével;
- Az egyensúlyozás lehetőleg munkaidőn kívül (éjszaka, hétvégén, ünnepnapokon) történjen.
Nyilvános felhők számárakis ügyfeleknek nyújt szolgáltatásokat, a DRS sokkal gyakrabban használható, fejlett képességekkel:
- információbiztonsági korlátozások és affinitási szabályok hiánya;
- egyensúlyozás a felhőn belül;
- kiegyensúlyozás bármely ésszerű időpontban;
- bármely virtuális gép kiegyensúlyozása;
- a „zajos” virtuális gépek kiegyensúlyozása (hogy ne zavarjon másokat);
- a virtuális gép adatai gyakran helyi lemezeken találhatók;
- figyelembe véve a tárolórendszerek és hálózatok átlagos teljesítményét (a felhő architektúra egységes);
- kiegyensúlyozás az általános szabályok és a rendelkezésre álló adatközponti viselkedési statisztikák szerint.
A probléma összetettsége
Az egyensúlyozás nehézsége az, hogy a DRS-nek számos bizonytalan tényezővel együtt kell működnie:
- az egyes ügyfelek információs rendszereinek felhasználói viselkedése;
- algoritmusok információs rendszerszerverek működtetéséhez;
- DBMS-kiszolgálók viselkedése;
- a számítási erőforrások, tárolórendszerek, hálózat terhelése;
- a szerverek egymás közötti interakciója a felhő-erőforrásokért folytatott küzdelemben.
Nagyszámú virtuális alkalmazásszerver és adatbázis terhelése a felhő-erőforrásokon idővel jelentkezik, a következmények megnyilvánulhatnak és átfedhetik egymást, előre nem látható időn keresztül. Még a viszonylag egyszerű folyamatok vezérléséhez is (például egy motor, egy vízmelegítő rendszer otthoni vezérléséhez) az automatikus vezérlőrendszereknek komplexet kell használniuk. algoritmusok visszacsatolással.
Feladatunk sok nagyságrenddel összetettebb, és fennáll annak a veszélye, hogy a rendszer nem tudja ésszerű időn belül kiegyenlíteni a terhelést a megállapított értékekre, még akkor sem, ha nincs külső behatás a felhasználók részéről.
Fejlesztéseink története
A probléma megoldása érdekében úgy döntöttünk, hogy nem a nulláról kezdjük, hanem a meglévő tapasztalatokra építünk, és elkezdtünk kapcsolatba lépni az ezen a területen tapasztalt szakemberekkel. Szerencsére a probléma megértése teljesen egybeesett.
1 színpad
Neurális hálózati technológián alapuló rendszert használtunk, és ennek alapján próbáltuk optimalizálni az erőforrásainkat.
Ennek a szakasznak az volt az érdeke, hogy egy új technológiát teszteljünk, fontossága pedig egy olyan probléma megoldásának nem szabványos megközelítése volt, ahol a standard megközelítések – más dolgok mellett – gyakorlatilag kimerítették magukat.
Elindítottuk a rendszert, és tényleg elkezdtük az egyensúlyozást. Felhőnk mérete nem tette lehetővé a fejlesztők által megfogalmazott optimista eredmények elérését, de az egyértelmű volt, hogy a kiegyenlítés működik.
Ugyanakkor elég komoly korlátaink voltak:
- Egy neurális hálózat betanításához a virtuális gépeknek hetekig vagy hónapokig jelentős változtatások nélkül kell futniuk.
- Az algoritmust a korábbi „történelmi” adatok elemzésén alapuló optimalizálásra tervezték.
- A neurális hálózat betanítása meglehetősen nagy mennyiségű adatot és számítási erőforrást igényel.
- Az optimalizálás és a kiegyensúlyozás viszonylag ritkán – néhány óránként egyszer – elvégezhető, ami nyilvánvalóan nem elég.
2 színpad
Mivel nem voltunk megelégedve a dolgok állásával, úgy döntöttünk, hogy módosítjuk a rendszert, és ennek érdekében válaszolunk fő kérdés - kinek készítjük?
Először is - vállalati ügyfelek számára. Ez azt jelenti, hogy szükségünk van egy gyorsan működő rendszerre, olyan vállalati korlátozásokkal, amelyek csak egyszerűsítik a megvalósítást.
Második kérdés – Mit értesz az „azonnal” szó alatt? Rövid vita eredményeként úgy döntöttünk, hogy 5-10 perces válaszidővel indulhatunk, hogy a rövid távú túlfeszültségek ne vigyék rezonanciába a rendszert.
Harmadik kérdés – a kiegyensúlyozott szerverszámból mekkora méretet válasszunk?
Ez a probléma magától megoldódott. Az ügyfelek általában nem teszik túl nagyra a szerver-összesítéseket, és ez összhangban van a cikk azon ajánlásaival, hogy az aggregációkat 30-40 szerverre korlátozzák.
Ezenkívül a szerverkészlet szegmentálásával leegyszerűsítjük a kiegyenlítő algoritmus feladatát.
Negyedik kérdés – Mennyire alkalmas számunkra egy neurális hálózat a hosszú tanulási folyamatával és a ritka egyensúlyozással? Úgy döntöttünk, hogy elhagyjuk az egyszerűbb műveleti algoritmusok javára, hogy másodpercek alatt eredményt kapjunk.
Megtalálható egy ilyen algoritmust használó rendszer leírása és annak hátrányai
Bevezettük és elindítottuk ezt a rendszert, és biztató eredményeket kaptunk - most már rendszeresen elemzi a felhőterhelést, és javaslatokat tesz a virtuális gépek mozgatására, amelyek nagyrészt helyesek. Már most is egyértelmű, hogy 10-15%-os erőforrás-felszabadulást érhetünk el az új virtuális gépeknél, miközben a meglévők munkaminőségét javítjuk.
Ha a RAM-ban vagy a CPU-ban egyensúlyhiányt észlel, a rendszer parancsokat ad ki a Tionix ütemezőnek a szükséges virtuális gépek élő migrációjának végrehajtására. Amint a megfigyelő rendszerből látható, a virtuális gép az egyik (felső) állomásról a másikra (alsó) költözött, és a felső gazdagépen szabadított fel memóriát (sárga körökkel kiemelve), illetve az alsón foglalta el (fehérrel kiemelve). körök).
Most megpróbáljuk pontosabban felmérni a jelenlegi algoritmus hatékonyságát, és megpróbáljuk megtalálni az esetleges hibákat.
3 színpad
Úgy tűnik, ezen meg lehet nyugodni, megvárni a bizonyított hatékonyságot, és lezárni a témát.
De a következő nyilvánvaló optimalizálási lehetőségek késztetnek bennünket egy új szakasz megvalósítására
- A statisztikák pl. и azt mutatja, hogy a két- és négyprocesszoros rendszerek teljesítménye lényegesen alacsonyabb, mint az egyprocesszoros rendszerek. Ez azt jelenti, hogy minden felhasználó lényegesen kevesebb kimenetet kap a többprocesszoros rendszerekben vásárolt CPU-ból, RAM-ból, SSD-ből, LAN-ból, FC-ből az egyprocesszoroshoz képest.
- Magukban az erőforrás-ütemezőkben lehetnek súlyos hibák, ebben a témában.
- Az Intel és az AMD RAM és gyorsítótár figyelésére kínált technológiái lehetővé teszik a virtuális gépek viselkedésének tanulmányozását és olyan elhelyezését, hogy a „zajos” szomszédok ne zavarják a „csendes” virtuális gépeket.
- A paraméterkészlet bővítése (hálózat, tárolórendszer, a virtuális gép prioritása, a migráció költsége, az átállásra való felkészültsége).
Összességében
A kiegyenlítő algoritmusok fejlesztésére irányuló munkánk eredménye az az egyértelmű következtetés, hogy a korszerű algoritmusokkal jelentős mértékben (25-30%) lehet optimalizálni az adatközponti erőforrásokat, és ezzel párhuzamosan javítani az ügyfélszolgálat minőségét.
A neurális hálózatokra épülő algoritmus mindenképpen érdekes, de továbbfejlesztésre szoruló megoldás, és a meglévő korlátok miatt nem alkalmas ilyen jellegű problémák megoldására a privát felhőkre jellemző köteteken. Ugyanakkor az algoritmus jelentős méretű nyilvános felhőkben mutatott jó eredményeket.
A processzorok, ütemezők képességeiről és a magas szintű kiegyensúlyozásról a következő cikkekben fogunk többet mondani.
Forrás: will.com