Sokan küzdenek az Elasticsearch-el. De mi történik, ha „különösen nagy mennyiségben” naplók tárolására kívánja használni? És fájdalommentes-e megtapasztalni a több adatközpont bármelyikének meghibásodását? Milyen építészetet készítsen, és milyen buktatókba botlik?
Mi az Odnoklassnikinél úgy döntöttünk, hogy az elasticsearch segítségével oldjuk meg a naplókezelés problémáját, és most megosztjuk tapasztalatainkat Habrral: mind az építészetről, mind a buktatókról.
Pjotr Zajcev vagyok, rendszergazdaként dolgozom az Odnoklassnikinél. Előtte admin is voltam, dolgoztam Manticore Search, Sphinx search, Elasticsearch segítségével. Talán, ha megjelenik egy másik ... keresés, valószínűleg én is dolgozom vele. Számos nyílt forráskódú projektben is részt veszek önkéntes alapon.
Amikor az Odnoklassnikihez kerültem, az interjún meggondolatlanul azt mondtam, hogy dolgozhatok az Elasticsearch-el. Miután rájöttem, és elvégeztem néhány egyszerű feladatot, nagy feladatot kaptam, hogy megreformáljam az akkori naplókezelési rendszert.
Követelmények
A rendszerkövetelmények a következőképpen kerültek megfogalmazásra:
- Graylogot kellett használni frontendként. Mivel a cégnek már volt tapasztalata ennek a terméknek a használatában, a programozók és tesztelők tudták, ismerős és kényelmes volt számukra.
- Adatmennyiség: átlagosan 50-80 ezer üzenet másodpercenként, de ha valami elromlik, akkor a forgalmat semmi sem korlátozza, másodpercenként 2-3 millió sor is lehet
- Miután megbeszéltük az ügyfelekkel a keresési lekérdezések feldolgozásának sebességére vonatkozó követelményeket, rájöttünk, hogy egy ilyen rendszer használatának jellemző mintája a következő: az emberek az elmúlt két napra vonatkozó alkalmazásuk naplóit keresik, és nem akarnak többet várni, mint egy második egy megfogalmazott lekérdezés eredménye.
- Az adminisztrátorok ragaszkodtak ahhoz, hogy a rendszer szükség esetén könnyen méretezhető legyen, anélkül, hogy mélyen elmélyülniük kellene a működésében.
- Így az egyetlen karbantartási feladat, amelyet ezeknek a rendszereknek rendszeres időközönként megkövetelnek, néhány hardver cseréje.
- Emellett az Odnoklassniki kiváló technikai hagyományokkal rendelkezik: minden általunk elindított szolgáltatásnak túl kell élnie egy adatközponti hibát (hirtelen, nem tervezett és bármikor).
A projekt megvalósításának utolsó követelménye került nekünk a legtöbbet, amelyről részletesebben fogok beszélni.
Szerda
Négy adatközpontban dolgozunk, míg az Elasticsearch adatcsomópontok csak háromban helyezkednek el (számos nem technikai ok miatt).
Ez a négy adatközpont megközelítőleg 18 ezer különböző naplóforrást tartalmaz – hardvert, konténereket, virtuális gépeket.
Fontos tulajdonság: a fürt konténerekben indul nem fizikai gépeken, hanem azon . A tárolók garantáltan 2 magot tartalmaznak, hasonlóan a 2.0 GHz-es v4-hez, és lehetőség van a maradék magok újrahasznosítására, ha tétlenek.
Más szavakkal:
Topológia
Kezdetben a megoldás általános formáját a következőképpen láttam:
- 3-4 VIP van a Graylog tartomány A-rekordja mögött, erre a címre küldik a naplókat.
- minden VIP egy LVS egyensúlyozó.
- Utána a naplók a Graylog akkumulátorra kerülnek, az adatok egy része GELF, néhány syslog formátumú.
- Aztán mindezt nagy tételekben írják az Elasticsearch koordinátorok csapatára.
- Ők pedig írási és olvasási kéréseket küldenek a megfelelő adatcsomópontoknak.
terminológia
Talán nem mindenki érti részletesen a terminológiát, ezért szeretnék egy kicsit elidőzni rajta.
Az Elasticsearch többféle csomóponttal rendelkezik - mester, koordinátor, adatcsomópont. Két másik típus létezik a különböző naplótranszformációkhoz és a különböző fürtök közötti kommunikációhoz, de mi csak a felsoroltakat használtuk.
Mester
Megpingeli a fürtben lévő összes csomópontot, naprakész fürtleképezést tart fenn, és elosztja azt a csomópontok között, feldolgozza az eseménylogikát, és különféle fürtszintű karbantartást végez.
Koordinátor
Egyetlen feladatot hajt végre: olvasási vagy írási kéréseket fogad el az ügyfelektől, és irányítja ezt a forgalmat. Írási kérés esetén nagy valószínűséggel megkérdezi a mestert, hogy az adott index melyik szilánkjába helyezze azt, és továbbirányítja a kérést.
Adatcsomópont
Adatokat tárol, kívülről érkező keresési lekérdezéseket hajt végre, és műveleteket hajt végre a rajtuk található szilánkokon.
szürke napló
Ez olyasmi, mint a Kibana és a Logstash fúziója egy ELK veremben. A Graylog egyesíti a felhasználói felületet és a naplófeldolgozási folyamatot. A motorháztető alatt a Graylogon a Kafka és a Zookeeper fut, amelyek fürtként biztosítják a kapcsolatot a Grayloggal. A Graylog gyorsítótárazhatja a naplókat (Kafka), ha az Elasticsearch nem elérhető, és megismételheti a sikertelen olvasási és írási kéréseket, csoportosíthatja és megjelölheti a naplókat a meghatározott szabályok szerint. A Logstashhoz hasonlóan a Graylog is rendelkezik a sorok módosításával, mielőtt beírná azokat az Elasticsearch programba.
Ezenkívül a Graylog rendelkezik egy beépített szolgáltatásfelderítéssel, amely lehetővé teszi egy elérhető Elasticsearch csomópont alapján a teljes fürttérkép lekérését és egy adott címkével való szűrését, amely lehetővé teszi a kérések meghatározott tárolókba irányítását.
Vizuálisan valahogy így néz ki:
Ez egy képernyőkép egy adott példányból. Itt a keresési lekérdezés alapján hisztogramot készítünk, és megjelenítjük a releváns sorokat.
Indexek
Visszatérve a rendszerarchitektúrára, szeretnék részletesebben kitérni arra, hogyan építettük fel az indexmodellt úgy, hogy minden megfelelően működjön.
A fenti diagramon ez a legalacsonyabb szint: Elasticsearch adatcsomópontok.
Az index egy nagy virtuális entitás, amely Elasticsearch-szilánkokból áll. Önmagában a szilánkok mindegyike nem más, mint egy Lucene index. És minden Lucene index egy vagy több szegmensből áll.
A tervezés során arra gondoltunk, hogy ahhoz, hogy nagy mennyiségű adat esetén teljesítsük az olvasási sebesség követelményét, ezeket az adatokat egyenletesen kell „elosztanunk” az adatcsomópontok között.
Ez azt a tényt eredményezte, hogy az indexenkénti szilánkok számának (replikákkal) szigorúan meg kell egyeznie az adatcsomópontok számával. Először is, hogy biztosítsuk a kettővel egyenlő replikációs tényezőt (vagyis elveszíthetjük a klaszter felét). Másodszor pedig az olvasási és írási kérelmek feldolgozása érdekében a fürt legalább felében.
A tárolási időt először 30 napban határoztuk meg.
A szilánkok eloszlása grafikusan a következőképpen ábrázolható:
A teljes sötétszürke téglalap egy index. A benne lévő bal oldali piros négyzet az elsődleges szilánk, az első az indexben. A kék négyzet pedig egy replikaszilánk. Különböző adatközpontokban találhatók.
Amikor egy újabb szilánkot adunk hozzá, az a harmadik adatközpontba kerül. És végül ezt a struktúrát kapjuk, amely lehetővé teszi az egyenáram elvesztését az adatok konzisztenciájának elvesztése nélkül:
Az indexek rotációja, i.e. új index létrehozásával és a legrégebbi törlésével 48 órával egyenlővé tettük (az indexhasználati mintázat szerint: az utolsó 48 órát keresik leggyakrabban).
Ez az indexelforgatási intervallum a következő okokból adódik:
Ha egy keresési kérés egy adott adatcsomóponthoz érkezik, akkor teljesítmény szempontjából jövedelmezőbb egy szilánk lekérdezése, ha annak mérete összemérhető a csomópont csípőjének méretével. Ez lehetővé teszi, hogy az index „forró” részét egy kupacban tartsa, és gyorsan elérje azt. Ha sok a „forró rész”, az indexkeresés sebessége csökken.
Amikor egy csomópont keresési lekérdezést kezd végrehajtani egy szilánkon, akkor a fizikai gép hiperszál-magjainak számával megegyező számú szálat foglal le. Ha egy keresési lekérdezés nagyszámú szilánkot érint, akkor a szálak száma arányosan növekszik. Ez negatív hatással van a keresési sebességre, és negatívan befolyásolja az új adatok indexelését.
A szükséges keresési késleltetés biztosítása érdekében úgy döntöttünk, hogy SSD-t használunk. A kérések gyors feldolgozásához az ezeket a tárolókat tároló gépeknek legalább 56 maggal kellett rendelkezniük. Az 56-os számot feltételesen elégséges értéknek választottuk, amely meghatározza, hogy az Elasticsearch hány szálat generál működés közben. Az Elasitcsearch programban számos szálkészlet-paraméter közvetlenül függ az elérhető magok számától, ami viszont közvetlenül befolyásolja a fürtben lévő csomópontok szükséges számát a „kevesebb mag - több csomópont” elv szerint.
Ennek eredményeként azt találtuk, hogy egy szilánk átlagosan körülbelül 20 gigabájtot nyom, és indexenként 1 szilánk található. Ennek megfelelően, ha 360 óránként egyszer forgatjuk őket, akkor 48 db van belőlük. Minden index 15 napra vonatkozó adatokat tartalmaz.
Adatíró és -olvasó áramkörök
Nézzük meg, hogyan rögzítik az adatokat ebben a rendszerben.
Tegyük fel, hogy érkezik egy kérés a Graylogtól a koordinátorhoz. Például 2-3 ezer sort szeretnénk indexelni.
A koordinátor, miután egy kérést kapott a Graylogtól, megkérdezi a mestert: „Az indexelési kérésben konkrétan megadtunk egy indexet, de nem volt megadva, hogy melyik szilánkba kell írni.”
A mester válaszol: „Írja ezt az információt a 71-es számú szilánkra”, majd közvetlenül a megfelelő adatcsomóponthoz küldi, ahol a 71-es elsődleges szilánk található.
Ezt követően a tranzakciós napló replikálódik egy replika-szilánkra, amely egy másik adatközpontban található.
Keresési kérés érkezik a Graylogtól a koordinátorhoz. A koordinátor az indexnek megfelelően irányítja át, míg az Elasticsearch a kör-robin elvet alkalmazva osztja el a kéréseket az elsődleges és a replikaszilánkok között.
A 180 csomópont egyenetlenül reagál, és miközben válaszolnak, a koordinátor olyan információkat halmoz fel, amelyeket a gyorsabb adatcsomópontok már „kiköptek”. Ezt követően, amikor vagy minden információ megérkezett, vagy a kérés elérte az időtúllépést, mindent közvetlenül az ügyfélnek ad át.
Ez az egész rendszer átlagosan 48-300 ms alatt dolgozza fel a keresési lekérdezéseket az elmúlt 400 órában, kivéve azokat a lekérdezéseket, amelyekben a vezető helyettesítő karakter szerepel.
Flowers with Elasticsearch: Java beállítás
Annak érdekében, hogy minden úgy működjön, ahogy eredetileg szerettük volna, nagyon hosszú időt töltöttünk a fürtben található különféle dolgok hibakeresésével.
A felfedezett problémák első része a Java alapértelmezés szerinti előre konfigurálásához kapcsolódik az Elasticsearch programban.
Egy probléma
Nagyon sok jelentést láttunk arról, hogy Lucene szinten, amikor háttérfeladatok futnak, a Lucene szegmens egyesítése hibával meghiúsul. Ugyanakkor a naplókban egyértelműen látszott, hogy ez OutOfMemoryError hiba. A telemetriáról láttuk, hogy a csípő szabaddá vált, és nem volt világos, hogy ez a művelet miért nem sikerült.
Kiderült, hogy a Lucene index összeolvadása a csípőn kívül történik. A konténerek pedig meglehetősen szigorúan korlátozottak a felhasznált erőforrások tekintetében. Csak a kupac fért bele ezekbe az erőforrásokba (a heap.size értéke megközelítőleg megegyezett a RAM-mal), és néhány off-heap művelet memóriafoglalási hibával összeomlott, ha valamiért nem fért bele a limit előtt maradt ~500 MB-ba.
A javítás meglehetősen triviális volt: megnövelték a konténerhez rendelkezésre álló RAM mennyiségét, ami után elfelejtettük, hogy még ilyen gondjaink is vannak.
Második probléma
A fürt elindítása után 4-5 nappal azt vettük észre, hogy az adatcsomópontok időszakosan elkezdtek kiesni a klaszterből, és 10-20 másodperc múlva beléptek abba.
Amikor elkezdtük kitalálni, kiderült, hogy az Elasticsearch-ben ez az off-heap memória semmilyen módon nem szabályozott. Amikor több memóriát adtunk a tárolónak, a direkt puffertárakat meg tudtuk tölteni különféle információkkal, és csak az explicit GC elindítása után törlődött az Elasticsearch-ból.
Egyes esetekben ez a művelet meglehetősen hosszú ideig tartott, és ezalatt a fürtnek sikerült megjelölnie ezt a csomópontot már kilépettként. Ez a probléma jól le van írva .
A megoldás a következő volt: korlátoztuk a Java azon képességét, hogy a kupacon kívüli memória nagy részét ezekhez a műveletekhez használja. 16 gigabájtra korlátoztuk (-XX:MaxDirectMemorySize=16g), biztosítva, hogy az explicit GC-t sokkal gyakrabban hívják meg, és sokkal gyorsabban dolgozzák fel, így többé nem destabilizálja a fürt.
Harmadik probléma
Ha úgy gondolja, hogy a „csomópontok a legváratlanabb pillanatban hagyják el a klasztert” problémái elmúltak, akkor téved.
Amikor a munkát indexekkel konfiguráltuk, az mmapfs to-t választottuk friss szilánkon, nagy szegmentálással. Ez nagy baklövés volt, mert mmapfs használatakor a fájl a RAM-ba van leképezve, majd a leképezett fájllal dolgozunk. Emiatt kiderül, hogy amikor a GC megpróbálja leállítani a szálakat az alkalmazásban, akkor nagyon hosszú időre a biztonságos pontra megyünk, és az oda vezető úton az alkalmazás nem válaszol a mester kérésére, hogy életben van-e. . Ennek megfelelően a mester úgy véli, hogy a csomópont már nincs jelen a fürtben. Ezt követően 5-10 másodperc múlva működik a szemétgyűjtő, a csomópont életre kel, újra belép a klaszterbe és megkezdi a szilánkok inicializálását. Az egész nagyon olyan volt, mint „a produkció, amit megérdemeltünk”, és semmi komolyra nem volt alkalmas.
Hogy megszabaduljunk ettől a viselkedéstől, először standard niofokra váltottunk, majd amikor az Elastic ötödik verziójáról a hatodikra váltottunk, kipróbáltuk a hibrideket, ahol ez a probléma nem reprodukálódott. A tárolási típusokról bővebben olvashat .
Negyedik feladat
Aztán volt még egy nagyon érdekes probléma, amit rekordidőn keresztül kezeltünk. 2-3 hónapig fogtuk, mert teljesen érthetetlen volt a mintája.
A koordinátoraink néha elmentek a Full GC-re, általában valamikor ebéd után, és soha nem tértek vissza onnan. Ugyanakkor a GC késleltetés naplózásakor így nézett ki: minden jól megy, na jó, aztán hirtelen minden nagyon rosszul megy.
Eleinte azt hittük, hogy van egy gonosz felhasználónk, aki olyan kérést indított el, amely kiiktatta a koordinátort a munkamódból. Nagyon sokáig naplóztuk a kéréseket, próbálva kitalálni, mi történik.
Ennek eredményeként kiderült, hogy abban a pillanatban, amikor egy felhasználó hatalmas kérést indít, és az egy adott Elasticsearch koordinátorhoz érkezik, egyes csomópontok hosszabb ideig válaszolnak, mint mások.
És miközben a koordinátor az összes csomópont válaszára vár, összegyűjti a már válaszolt csomópontoktól elküldött eredményeket. A GC esetében ez azt jelenti, hogy a kupachasználati szokásaink nagyon gyorsan változnak. És az általunk használt GC nem tudott megbirkózni ezzel a feladattal.
Az egyetlen olyan javítás, amelyet ebben a helyzetben a fürt viselkedésének megváltoztatására találtunk, a JDK13-ra való migráció és a Shenandoah szemétgyűjtő használata. Ezzel megoldódott a probléma, koordinátoraink leálltak.
Itt értek véget a Java-problémák és kezdődtek a sávszélesség-problémák.
"Bogyók" az Elasticsearch segítségével: áteresztőképesség
Az áteresztőképességgel kapcsolatos problémák azt jelentik, hogy fürtünk stabilan működik, de az indexelt dokumentumok számának csúcspontjainál és a manőverek során a teljesítmény nem elegendő.
Az első tapasztalt tünet: a termelés egyes „robbanásai” során, amikor hirtelen nagyon sok napló generálódik, az es_rejected_execution indexelési hiba gyakran villogni kezd a Graylogban.
Ez annak volt köszönhető, hogy a thread_pool.write.queue egy adatcsomóponton addig a pillanatig, amíg az Elasticsearch nem tudja feldolgozni az indexelési kérelmet és feltölteni az információkat a lemezen lévő szilánkra, alapértelmezés szerint csak 200 kérést képes gyorsítótárazni. És be Nagyon kevés szó esik erről a paraméterről. Csak a szálak maximális száma és az alapértelmezett méret jelenik meg.
Természetesen kiforgattuk ezt az értéket, és a következőket tapasztaltuk: konkrétan a mi beállításunkban akár 300 kérés is elég jól gyorsítótárazott, a magasabb érték pedig azzal jár, hogy ismét Full GC-be repülünk.
Ráadásul mivel ezek egy kérésen belül érkezõ üzenetkötegek, a Graylogon át kellett állítani, hogy ne gyakran és kis kötegekben írjon, hanem hatalmas kötegekben vagy 3 másodpercenként egyszer, ha a köteg még mindig nem teljes. Ebben az esetben kiderül, hogy az Elasticsearch-be írt információ nem két másodperc alatt válik elérhetővé, hanem öt (ami elég jól áll nekünk), de hány újratálcát kell végrehajtani, hogy átnyomjuk a nagyot. információhalmaz csökken.
Ez különösen fontos azokban a pillanatokban, amikor valahol valami összeomlott, és dühösen beszámol róla, hogy ne kapjon egy teljesen spammelt Elasticot, és egy idő után - az eltömődött pufferek miatt működésképtelen Graylog csomópontokat.
Ráadásul, amikor ugyanezek a robbanások a gyártásban történtek, kaptunk panaszokat programozóktól és tesztelőktől: abban a pillanatban, amikor valóban szükségük volt ezekre a naplókra, nagyon lassan kapták meg őket.
Kezdték kitalálni. Egyrészt egyértelmű volt, hogy mind a keresési, mind az indexelési lekérdezéseket lényegében ugyanazokon a fizikai gépeken dolgozták fel, és így vagy úgy lesznek bizonyos hiányosságok.
Ez azonban részben megkerülhető, mivel az Elasticsearch hatodik verziójában megjelent egy olyan algoritmus, amely lehetővé teszi a lekérdezések elosztását a releváns adatcsomópontok között, nem a véletlenszerű kör-robin elv szerint (az indexelést végző tároló és az elsődleges A -shard nagyon elfoglalt lehet, nem lehet gyorsan válaszolni), de továbbítsa ezt a kérést egy kevésbé terhelt konténerre replika-sharddal, amely sokkal gyorsabban válaszol. Más szavakkal, elérkeztünk a use_adaptive_replica_selection: true értékhez.
Az olvasó kép így kezd kinézni:
Az erre az algoritmusra való átállás lehetővé tette a lekérdezési idő jelentős javítását azokban a pillanatokban, amikor nagy mennyiségű naplót kellett írnunk.
Végül a fő probléma az adatközpont fájdalommentes eltávolítása volt.
Amit szerettünk volna a klasztertől azonnal, miután elveszítettük a kapcsolatot egy DC-vel:
- Ha van egy aktuális mesterünk a meghibásodott adatközpontban, akkor a rendszer újra kiválasztja, és szerepként áthelyezi egy másik DC másik csomópontjába.
- A mester gyorsan eltávolítja az összes elérhetetlen csomópontot a fürtből.
- A többiek alapján meg fogja érteni: az elveszett adatközpontban voltak ilyen-olyan elsődleges szilánkjaink, a megmaradt adatközpontokban gyorsan promotálja a kiegészítő replikaszilánkokat, mi pedig folytatjuk az adatok indexelését.
- Ennek eredményeként a klaszter írási és olvasási teljesítménye fokozatosan romlik, de általában minden működni fog, ha lassan is, de stabilan.
Mint kiderült, valami ilyesmit akartunk:
És a következőket kaptuk:
Hogy történt?
Amikor az adatközpont bedőlt, a mesterünk lett a szűk keresztmetszet.
Miért?
A helyzet az, hogy a mester rendelkezik egy TaskBatcherrel, amely bizonyos feladatok és események elosztásáért felelős a fürtben. Bármilyen csomóponti kilépés, egy szilánk replikából elsődlegessé történő előléptetése, minden feladat egy szilánk létrehozására valahol – mindez először a TaskBatcherbe kerül, ahol szekvenciálisan és egy szálban dolgozzák fel.
Egy adatközpont kivonásakor kiderült, hogy a fennmaradt adatközpontokban minden adatcsomópont kötelességének tartotta tájékoztatni a mestert „ilyen-olyan szilánkokat, ilyen-olyan adatcsomópontokat vesztettünk el”.
Ugyanakkor a fennmaradt adatcsomópontok mindezt az információt elküldték az aktuális masternek, és megpróbálták megvárni a megerősítést, hogy elfogadja azokat. Ezt nem várták meg, hiszen a mester gyorsabban kapott feladatokat, mint ahogy válaszolni tudott. A csomópontok időzítették az ismétlődő kéréseket, és a mester ekkor még meg sem próbált válaszolni rájuk, hanem teljesen elmerült a kérések prioritás szerinti rendezésében.
Terminál formában kiderült, hogy az adatcsomópontok annyira spammelték a mastert, hogy az teljes GC-be ment. Ezt követően a mester szerepünk átkerült valamelyik következő csomópontba, teljesen ugyanez történt vele, és ennek következtében a klaszter teljesen összeomlott.
Méréseket végeztünk, és a 6.4.0-s verzió előtt, ahol ez javítva volt, elég volt egyszerre csak 10 adatcsomópontot kiadni a 360-ból a klaszter teljes leállításához.
Valahogy így nézett ki:
A 6.4.0-s verzió után, ahol ezt a szörnyű hibát kijavították, az adatcsomópontok nem ölték meg a mestert. De ettől nem lett „okosabb”. Nevezetesen: amikor 2, 3 vagy 10 (egytől eltérő szám) adatcsomópontot adunk ki, a mester kap valami első üzenetet, amely azt mondja, hogy az A csomópont elment, és megpróbálja ezt közölni a B, C csomóponttal, a D csomóponttal.
Ezt pedig jelenleg csak úgy lehet kezelni, ha kb. 20-30 másodpercnek megfelelő időt állítunk be azokra a kísérletekre, amelyek megpróbálják elmondani valakinek valamit, és így szabályozni a klaszterből kimozduló adatközpont sebességét.
Ez elvileg beleillik a projekt részeként eredetileg a végtermék elé állított követelményekbe, de a „tiszta tudomány” szempontjából ez egy bug. Amit egyébként a fejlesztők a 7.2-es verzióban sikeresen kijavítottak.
Sőt, amikor egy bizonyos adatcsomópont kialudt, kiderült, hogy a kilépésével kapcsolatos információk terjesztése fontosabb, mint az egész klaszternek elmondani, hogy ilyen és ehhez hasonló elsődleges szilánkok vannak rajta (a replika-szilánkok előmozdítása érdekében egy másik adatban központban az elsődlegesben, és információkat lehetett rájuk írni).
Ezért, amikor már minden elhalt, a kiadott adatcsomópontokat nem jelöli meg azonnal elavultként. Ennek megfelelően kénytelenek vagyunk megvárni, amíg minden ping lejár a kiadott adatcsomópontokon, és csak ezután kezdi el a fürtünk közölni velünk, hogy ott, ott és ott kell folytatni az információk rögzítését. Erről bővebben olvashat .
Ebből kifolyólag egy adatközpont kivonásának művelete ma csúcsidőben körülbelül 5 percet vesz igénybe. Egy ilyen nagy és ügyetlen kolosszusnál ez elég jó eredmény.
Ennek eredményeként a következő döntésre jutottunk:
- 360 adatcsomópontunk van 700 gigabájtos lemezekkel.
- 60 koordinátor a forgalom ugyanezeken az adatcsomópontokon keresztül történő irányításához.
- 40 mester, amit a 6.4.0 előtti verziók óta egyfajta örökségül hagytunk - az adatközpont kivonásának túlélése érdekében mentálisan fel voltunk készülve több gép elvesztésére, hogy garantáltan legyen határozatképes mester a legrosszabb forgatókönyv
- A szerepek egy tárolón való kombinálására tett kísérletek azzal a ténnyel találkoztak, hogy a csomópont előbb-utóbb terhelés alatt megszakad.
- A teljes fürt 31 gigabájtnyi heap.size-t használ: a méret csökkentésére tett kísérletek vagy egyes csomópontok megsemmisítését eredményezték a vezető helyettesítő karakterrel végzett nehéz keresési lekérdezéseknél, vagy magába az Elasticsearch megszakítóját.
- Emellett a keresési teljesítmény biztosítása érdekében törekedtünk arra, hogy a klaszterben lévő objektumok száma a lehető legkisebb legyen, hogy a masterben kapott szűk keresztmetszetben a lehető legkevesebb eseményt dolgozzuk fel.
Végül a megfigyelésről
Annak érdekében, hogy mindez a rendeltetésszerűen működjön, a következőket figyeljük:
- Minden adatcsomópont jelenti a felhőnknek, hogy létezik, és vannak rajta ilyen-olyan szilánkok. Ha valahol eloltunk valamit, a klaszter 2-3 másodperc múlva jelzi, hogy az A központban a 2-es, 3-as és 4-es csomópontot kioltottuk – ez azt jelenti, hogy más adatközpontokban semmilyen körülmények között nem tudjuk eloltani azokat a csomópontokat, amelyeken csak egy szilánk van. bal.
- Ismerve a mester viselkedésének természetét, nagyon alaposan megvizsgáljuk a függőben lévő feladatok számát. Mert még egy elakadt feladat is, ha nem telik ki időben, elméletileg valamilyen vészhelyzetben az oka lehet annak, hogy például egy replikaszilánk promóciója az elsődlegesben nem működik, ezért az indexelés leáll.
- Nagyon odafigyelünk a szemétszállító késésekre is, mert ezzel már az optimalizálás során is nagy nehézségeink voltak.
- Cérnánként elutasítja, hogy előre megértse, hol a szűk keresztmetszet.
- Nos, szabványos mérőszámok, például kupac, RAM és I/O.
A megfigyelés építésekor figyelembe kell vennie az Elasticsearch Thread Pool szolgáltatásait. leírja a konfigurációs beállításokat és az alapértelmezett értékeket a kereséshez és az indexeléshez, de teljesen hallgat a thread_pool.managementről. Ezek a szálak különösen olyan lekérdezéseket dolgoznak fel, mint a _cat/shards és más hasonló lekérdezések, amelyek kényelmesen használhatók a megfigyelés írásakor. Minél nagyobb a fürt, annál több ilyen kérést hajtanak végre egységnyi idő alatt, és a fent említett thread_pool.management nemcsak hogy nincs feltüntetve a hivatalos dokumentációban, hanem alapértelmezés szerint 5 szálra van korlátozva, ami nagyon gyorsan megsemmisül. amely monitorozás nem működik megfelelően.
Zárásként azt akarom mondani: megcsináltuk! Programozóinknak és fejlesztőinknek olyan eszközt tudtunk adni, amely szinte minden helyzetben gyorsan és megbízhatóan tud információt adni a termelésben zajló eseményekről.
Igen, elég bonyolultnak bizonyult, de ennek ellenére sikerült a meglévő termékekbe beleillesztenünk kívánságainkat, amelyeket nem kellett magunknak foltozgatnunk, átírni.
Forrás: will.com