Vill Leit kämpfen mat Elasticsearch. Awer wat geschitt wann Dir et benotze wëllt fir Logbicher "an engem besonnesch grousse Volumen" ze späicheren? An ass et och schmerzlos den Echec vun engem vun e puer Datenzenteren ze erliewen? Wéi eng Architektur sollt Dir maachen, a wéi eng Fallfäegkeete stéisst Dir?
Mir bei Odnoklassniki hu beschloss Elasticsearch ze benotzen fir d'Thema vun der Logverwaltung ze léisen, an elo deele mir eis Erfahrung mat Habr: souwuel iwwer d'Architektur an iwwer d'Fallen.
Ech sinn de Pyotr Zaitsev, ech schaffen als Systemadministrator bei Odnoklassniki. Virdru war ech och en Admin, hunn mat Manticore Search, Sphinx Sich, Elasticsearch geschafft. Vläicht, wann eng aner ... Sich erschéngt, wäert ech wahrscheinlech och domat schaffen. Ech huelen och op fräiwëlleger Basis un enger Rei vun Open Source Projeten deel.
Wéi ech op Odnoklassniki komm sinn, hunn ech recklessly am Interview gesot datt ech mat Elasticsearch kéint schaffen. Nodeems ech et fäerdeg bruecht hunn an e puer einfach Aufgaben ofgeschloss hunn, krut ech déi grouss Aufgab fir de Logmanagementsystem ze reforméieren deen deemools existéiert huet.
Ufuerderunge
D'System Ufuerderunge goufen wéi follegt formuléiert:
- Graylog sollt als Frontend benotzt ginn. Well d'Firma scho Erfahrung mat dësem Produkt hat, hunn d'Programméierer an d'Tester et gewosst, et war hinnen vertraut a praktesch.
- Datevolumen: Duerchschnëtt 50-80 Tausend Messagen pro Sekonn, awer wann eppes brécht, ass de Verkéier net limitéiert, et kann 2-3 Millioune Linnen pro Sekonn sinn
- Nodeems mir mat Clienten d'Ufuerderunge fir d'Geschwindegkeet vun der Veraarbechtung vun Sichufroen diskutéiert hunn, hu mir gemierkt datt dat typesch Muster fir sou e System ze benotzen ass dat: d'Leit sichen no Logbicher vun hirer Applikatioun fir déi lescht zwee Deeg a wëllen net méi waarden wéi e zweet fir d'Resultat vun enger formuléierter Ufro.
- D'Administrateuren hunn insistéiert datt de System liicht skalierbar ass wann néideg, ouni datt se verlaangen déif ze verdéiwen wéi et funktionnéiert.
- Also datt déi eenzeg Ënnerhalt Aufgab déi dës Systemer periodesch erfuerderen ass e puer Hardware z'änneren.
- Zousätzlech huet Odnoklassniki eng exzellent technesch Traditioun: all Service dee mir lancéiere muss en Datenzenterfehler iwwerliewen (plötzlech, ongeplangt an absolut zu all Moment).
Déi lescht Fuerderung an der Ëmsetzung vun dësem Projet kascht eis am meeschten, iwwer déi ech méi am Detail schwätzen.
Mëttwoch
Mir schaffen a véier Datenzenteren, während Elasticsearch Dateknäppchen nëmmen an dräi lokaliséiert kënne ginn (aus enger Rei vun net-technesche Grënn).
Dës véier Rechenzentren enthalen ongeféier 18 Tausend verschidde Logquellen - Hardware, Container, virtuell Maschinnen.
Wichteg Feature: de Stärekoup fänkt a Container un net op kierperlech Maschinnen, mee op . Container si garantéiert 2 Cores, ähnlech wéi 2.0Ghz v4, mat der Méiglechkeet déi verbleiwen Cores ze recycléieren wa se Idle sinn.
An anere Wierder:
Topologie
Ech hunn am Ufank déi allgemeng Form vun der Léisung wéi follegt gesinn:
- 3-4 VIPs stinn hannert dem A-Rekord vum Graylog Domain, dat ass d'Adress op déi d'Logbicher geschéckt ginn.
- all VIP ass en LVS Balancer.
- Duerno ginn d'Logbicher op d'Graylog Batterie, e puer vun den Donnéeën sinn am GELF Format, e puer am Syslog Format.
- Da gëtt dat alles a grousse Chargen op eng Batterie vun Elasticsearch Koordinatoren geschriwwen.
- A si, ofwiesselnd, schécken Schreiwen a Liesen Ufroen un déi relevant Dateknäppchen.
Terminologie
Vläicht versteet net jiddereen d'Terminologie am Detail, also wëll ech e bëssen drop ophalen.
Elasticsearch huet verschidden Aarte vu Wirbelen - Master, Koordinator, Datennode. Et ginn zwou aner Zorte fir verschidde Logbicher Transformatiounen a Kommunikatioun tëscht verschiddene Stärekéip, mä mir hunn nëmmen déi opgezielt benotzt.
Master
Et pingt all Noden, déi am Cluster präsent sinn, hält eng aktuell Clusterkaart a verdeelt se tëscht Noden, veraarbecht Eventlogik, a mécht verschidden Aarte vu Clusterbreet Haushaltung.
Koordinator
Féiert eng eenzeg Aufgab: akzeptéiert Lies- oder Schreifufroe vu Clienten a leet dëse Traffic. Am Fall wou et eng schreiwen Ufro ass, wahrscheinlech, et wäert Meeschter froen, déi shard vun der zoustännegen Index soll et an, a wäert d'Ufro weider redirect.
Daten Node
Späichert Donnéeën, mécht Sichufroen aus, déi vu baussen ukommen a mécht Operatiounen op Stécker, déi drop sinn.
graulog
Dëst ass eppes wéi eng Fusioun vu Kibana mat Logstash an engem ELK Stack. Graylog kombinéiert souwuel eng UI an eng Logveraarbechtungspipeline. Ënnert der Hood leeft Graylog Kafka an Zookeeper, déi Konnektivitéit mat Graylog als Cluster ubidden. Graylog kann Logbicher (Kafka) cache am Fall datt Elasticsearch net verfügbar ass an net erfollegräich Lies- a Schreiffuerderunge widderhuelen, Logbicher no spezifizéierte Reegelen gruppéieren a markéieren. Wéi Logstash, huet Graylog Funktionalitéit fir Reihen z'änneren ier se op Elasticsearch schreiwen.
Zousätzlech huet Graylog eng agebaute Service-Entdeckung déi et erlaabt, baséiert op engem verfügbaren Elasticsearch Node, déi ganz Clusterkaart ze kréien an se duerch e spezifeschen Tag ze filteren, wat et méiglech mécht Ufroen op spezifesch Container ze dirigéieren.
Visuell gesäit et esou aus:
Dëst ass e Screenshot vun enger spezifescher Instanz. Hei bauen mir en Histogramm op Basis vun der Sichufro a weisen relevant Zeilen.
Indexen
Zréck op d'Systemarchitektur wëll ech méi am Detail ophalen wéi mir den Indexmodell gebaut hunn, sou datt et alles richteg funktionnéiert.
Am Diagramm uewendriwwer ass dëst den niddregsten Niveau: Elasticsearch Dateknäppchen.
En Index ass eng grouss virtuell Entitéit, déi aus Elasticsearch Schnëtt besteet. U sech ass jidderee vun de Schnëtt näischt méi wéi e Lucene Index. An all Lucene Index, am Tour, besteet aus een oder méi Segmenter.
Beim Design hu mir geduecht datt fir d'Ufuerderung fir d'Liesgeschwindegkeet op enger grousser Quantitéit un Daten z'erreechen, mir dës Donnéeën gläichméisseg iwwer Datenknäppchen mussen "verbreeden".
Dëst huet zu der Tatsaach gefouert datt d'Zuel vun de Schäerft pro Index (mat Repliken) strikt gläich wéi d'Zuel vun den Dateknäppchen sollt sinn. Als éischt, fir e Replikatiounsfaktor gläich wéi zwee ze garantéieren (dat ass, mir kënnen d'Halschent vum Cluster verléieren). An zweetens, fir op d'mannst d'Halschent vum Stärekoup Lies- a Schreiffuerderungen ze veraarbecht.
Mir hunn als éischt d'Späicherzäit als 30 Deeg bestëmmt.
D'Verdeelung vun de Schnëtt ka grafesch wéi follegt duergestallt ginn:
De ganze donkelgroe Rechteck ass en Index. De lénksen roude Quadrat dran ass de primäre Schnëtt, deen éischten am Index. An de bloe Quadrat ass e Replica-Schärft. Si sinn a verschiddenen Datenzenteren lokaliséiert.
Wa mir en anere Shard addéieren, geet et an den drëtten Rechenzentrum. An um Enn kréie mir dës Struktur, déi et méiglech mécht DC ze verléieren ouni Datenkonsistenz ze verléieren:
Rotatioun vun Indexen, d.h. en neien Index erstellen an den eelsten läschen, mir hunn et gläich 48 Stonnen gemaach (no dem Muster vun der Indexverbrauch: déi lescht 48 Stonnen ginn am meeschte gesicht).
Dësen Indexrotatiounsintervall ass wéinst de folgende Grënn:
Wann eng Sich Ufro bei engem spezifeschen Dateknuet ukomm ass, dann, aus enger Leeschtungssiicht, ass et méi rentabel wann ee Shard gefrot gëtt, wa seng Gréisst mat der Gréisst vun der Hip vum Node vergläichbar ass. Dëst erlaabt Iech den "waarme" Deel vum Index an engem Koup ze halen a séier Zougang. Wann et vill "waarm Deeler" sinn, degradéiert d'Geschwindegkeet vun der Index Sich.
Wann e Node ufänkt eng Sichufro op engem Shard auszeféieren, verdeelt et eng Zuel vun Threads gläich wéi d'Zuel vun den Hyperthreading-Käre vun der kierperlecher Maschinn. Wann eng Sichufro eng grouss Zuel vu Schäerft beaflosst, da wiisst d'Zuel vun de Threads proportional. Dëst huet en negativen Impakt op d'Sichgeschwindegkeet an en negativen Impakt op d'Indexéiere vun neien Donnéeën.
Fir déi néideg Sichlatenz ze bidden, hu mir beschloss eng SSD ze benotzen. Fir séier Ufroen ze verarbeiten, hunn d'Maschinnen, déi dës Container gehost hunn, op d'mannst 56 Kären hunn. D'Figur vun 56 gouf als bedingt genuch Wäert gewielt, deen d'Zuel vun de Threads bestëmmt, déi Elasticsearch während der Operatioun generéiert. An Elasitcsearch hänke vill thread Pool Parameteren direkt vun der Unzuel vun de verfügbare Kären of, wat am Tour direkt déi erfuerderlech Unzuel vun Noden am Stärekoup beaflosst no dem Prinzip "manner Kären - méi Noden".
Als Resultat hu mir festgestallt datt am Duerchschnëtt e Shard ongeféier 20 Gigabyte waacht, an et gi 1 Shards pro Index. Deementspriechend, wa mir se eemol all 360 Stonnen rotéieren, dann hu mir 48 vun hinnen. All Index enthält Daten fir 15 Deeg.
Daten Schreiwen a Lieskreesser
Loosst eis erausfannen wéi Daten an dësem System opgeholl ginn.
Loosst eis soen datt eng Demande vum Graylog un de Koordinator kënnt. Zum Beispill wëlle mir 2-3 dausend Zeilen indexéieren.
De Koordinator, nodeems hien eng Demande vum Graylog kritt huet, freet de Meeschter: "An der Indexéierungsufro hu mir speziell en Index spezifizéiert, awer a wéi engem Schnëtt et ze schreiwen ass net spezifizéiert."
De Meeschter reagéiert: "Schreift dës Informatioun op d'Shardnummer 71", duerno gëtt se direkt an den zoustännegen Dateknuet geschéckt, wou d'Primär-Shard Nummer 71 läit.
Duerno gëtt den Transaktiounsprotokoll op e Replica-Shard replizéiert, deen an engem aneren Rechenzentrum läit.
Eng Sich Ufro kënnt vum Graylog un de Koordinator. De Koordinator redirectéiert et no dem Index, während Elasticsearch Ufroen tëscht dem Primär-Shard a Replica-Shard verdeelt mam Round-Robin Prinzip.
Déi 180 Knäpper reagéieren ongläichméisseg, a wärend se reagéieren, sammelt de Koordinator Informatioun déi scho vu méi séier Dateknäppchen "ausgespuckt" gouf. Duerno, wann entweder all Informatioun ukomm ass, oder d'Ufro en Timeout erreecht huet, gëtt alles direkt un de Client.
Dëse ganze System veraarbecht am Duerchschnëtt Sichufroe fir déi lescht 48 Stonnen an 300-400ms, ausser dës Ufroe mat enger féierender Wildcard.
Blummen mat Elasticsearch: Java Setup
Fir et alles ze maachen wéi mir ursprénglech wollten, hu mir eng ganz laang Zäit verbruecht fir eng grouss Varietéit vu Saachen am Cluster ze debuggéieren.
Den éischten Deel vun de entdeckte Probleemer war am Zesummenhang mat der Aart a Weis wéi Java par défaut an Elasticsearch pre-konfiguréiert ass.
Problem eent
Mir hunn eng ganz grouss Zuel vu Berichter observéiert datt op der Lucene Niveau, wann Hannergrond Aarbechtsplaze lafen, Lucene Segment fusionéieren versoen mat engem Feeler. Zur selwechter Zäit war et kloer an de Logbicher datt dëst en OutOfMemoryError Feeler war. Mir hunn aus der Telemetrie gesinn datt d'Hüft fräi war, an et war net kloer firwat dës Operatioun gescheitert ass.
Et huet sech erausgestallt datt de Lucene Index Fusioun ausserhalb vun der Hip geschitt. A Container si ganz strikt limitéiert wat d'Ressourcen verbraucht ginn. Nëmmen Heap konnt an dës Ressourcen passen (de Heap.size Wäert war ongeféier gläich wéi RAM), an e puer Off-Heap Operatioune sinn mat engem Erënnerungsallokatiounsfehler erofgefall, wa se aus iergendengem Grond net an de ~ 500MB passen, déi virun der Limit bliwwen sinn.
De Fix war zimmlech trivial: d'Quantitéit vum RAM verfügbar fir de Container gouf erhéicht, duerno hu mir vergiess datt mir souguer esou Probleemer haten.
Problem zwee
4-5 Deeg nom Start vum Stärekoup hu mir gemierkt datt d'Datennoden periodesch aus dem Cluster falen an no 10-20 Sekonnen anzeginn.
Wéi mir ugefaang hunn et erauszefannen, huet sech erausgestallt datt dës Off-Heap Erënnerung an Elasticsearch op kee Fall kontrolléiert gëtt. Wann mir méi Erënnerung un de Container ginn, mir konnten déi direkt Prellbock déinen mat verschiddenen Informatiounen ze fëllen, an et war nëmmen no der explizit GC aus Elasticsearch lancéiert geläscht.
A verschiddene Fäll huet dës Operatioun zimmlech laang gedauert, a während dëser Zäit huet de Cluster et fäerdeg bruecht dësen Node ze markéieren wéi schonn erausgaang. Dëse Problem ass gutt beschriwwen .
D'Léisung war wéi follegt: mir limitéiert d'Fäegkeet vum Java fir de gréissten Deel vun der Erënnerung ausserhalb vum Koup fir dës Operatiounen ze benotzen. Mir limitéiert et op 16 Gigabyte (-XX: MaxDirectMemorySize = 16g), fir sécherzestellen datt explizit GC vill méi dacks genannt gouf a vill méi séier veraarbecht gouf, doduerch de Stärekoup net méi destabiliséiert.
Problem dräi
Wann Dir mengt datt d'Problemer mat "Noden, déi de Stärekoup am meeschte onerwaarte Moment verloossen" eriwwer sinn, da sidd Dir falsch.
Wa mir d'Aarbecht mat Indexen konfiguréiert hunn, hu mir mmapfs gewielt op frësche Schiermer mat grousser Segmentatioun. Dëst war zimlech e Feeler, well wann Dir mmapfs benotzt, gëtt d'Datei an de RAM mapéiert, an da schaffe mir mat der mapéierter Datei. Dofir stellt sech eraus datt wann de GC probéiert Threads an der Applikatioun ze stoppen, gi mir ganz laang op de Safepoint, an um Wee dohinner hält d'Applikatioun op d'Ufroe vum Meeschter op ob et lieweg ass. . Deementspriechend mengt de Meeschter datt den Node net méi am Cluster präsent ass. Duerno, no 5-10 Sekonnen, funktionnéiert de Müllsammler, de Knuet gëtt lieweg, geet erëm an de Cluster a fänkt un d'Schärften un. Et huet alles ganz vill gefillt wéi "d'Produktioun déi mir verdéngt hunn" a war net gëeegent fir eppes sérieux.
Fir dëst Verhalen lass ze ginn, hu mir als éischt op Standard Niofs gewiesselt, an dann, wa mir vun de fënneften Versioune vun Elastic op déi sechster migréiert sinn, hu mir Hybridfs probéiert, wou dëse Problem net reproduzéiert gouf. Dir kënnt méi iwwer Späichertypen liesen .
Problem véier
Da gouf et nach e ganz interessante Problem, dee mir fir eng Rekordzäit behandelt hunn. Mir hunn et fir 2-3 Méint gefaangen well säi Muster absolut onverständlech war.
Heiansdo sinn eis Koordinateuren op Full GC gaangen, normalerweis iergendwann nom Mëttegiessen, an sinn ni vun do zréck komm. Zur selwechter Zäit, beim Logbuch vun der GC-Verzögerung, huet et esou ausgesinn: alles geet gutt, gutt, gutt, an dann op eemol geet alles ganz schlecht.
Am Ufank hu mir geduecht datt mir e béise Benotzer haten, deen eng Aart Ufro lancéiert huet, déi de Koordinator aus dem Aarbechtsmodus geschloen huet. Mir protokolléiert Ufroe fir eng ganz laang Zäit, probéiert erauszefannen wat geschitt ass.
Als Resultat huet et sech erausgestallt datt am Moment wou e Benotzer eng rieseg Ufro lancéiert, an et an e spezifesche Elasticsearch Koordinator kënnt, e puer Node méi laang reagéieren wéi anerer.
A wärend de Koordinator op eng Äntwert vun all de Wirbelen waart, sammelt hien d'Resultater, déi vun den Wirbelen geschéckt ginn, déi scho geäntwert hunn. Fir GC heescht dat, datt eis Heap Notzungsmuster ganz séier änneren. An de GC, dee mir benotzt hunn, konnt dës Aufgab net eens ginn.
Déi eenzeg Fix déi mir fonnt hunn fir d'Verhalen vum Stärekoup an dëser Situatioun z'änneren ass d'Migratioun op JDK13 an d'Benotzung vum Shenandoah Müllsammler. Dëst huet de Problem geléist, eis Koordinateuren hunn opgehalen ze falen.
Dëst ass wou d'Problemer mat Java opgehalen hunn an d'Bandbreedungsproblemer ugefaang hunn.
"Beeren" mat Elasticsearch: Duerchgang
Probleemer mam Duerchgang bedeit datt eise Stärekoup stabil funktionnéiert, awer bei Peaks an der Unzuel vun indexéierten Dokumenter a während Manöveren ass d'Leeschtung net genuch.
Dat éischt Symptom begéint: während e puer "Explosiounen" an der Produktioun, wann eng ganz grouss Zuel vu Logbicher op eemol generéiert ginn, fänkt den Indexfeeler es_rejected_execution dacks am Graylog ze blénken.
Dëst war wéinst der Tatsaach datt thread_pool.write.queue op engem Dateknuet, bis de Moment Elasticsearch fäeg ass d'Indexéierungsufro ze veraarbechten an d'Informatioun op de Shard op der Disk eropzelueden, ass fäeg nëmmen 200 Ufroen als Standard ze cache. An an Ganz wéineg gëtt iwwer dëse Parameter gesot. Nëmmen déi maximal Unzuel u thread an d'Standardgréisst ginn uginn.
Natierlech si mir dëse Wäert verdreift an hunn déi folgend erausfonnt: speziell an eisem Setup si bis zu 300 Ufroe ganz gutt cache, an e méi héije Wäert ass voll mat der Tatsaach datt mir erëm an de Full GC fléien.
Ausserdeem, well dëst Chargen vu Messagen sinn, déi an enger Ufro ukommen, war et néideg Graylog ze tweaken, sou datt et net dacks a klenge Chargen schreift, awer a grousse Chargen oder eemol all 3 Sekonnen, wann de Batch nach ëmmer net komplett ass. An dësem Fall stellt sech eraus datt d'Informatioun, déi mir an Elasticsearch schreiwen, net an zwou Sekonnen verfügbar ass, mä a fënnef (wat eis ganz gutt passt), awer d'Zuel vun de Retrayeren déi musse gemaach ginn fir duerch eng grouss ze drécken. Stack vun Informatioun gëtt reduzéiert.
Dëst ass besonnesch wichteg an deene Momenter wou eppes iergendwou erofgefall ass a rosen doriwwer bericht, fir net e komplett gespammelt Elastik ze kréien, an no enger Zäit - Graylog Wirbelen déi inoperabel sinn wéinst verstoppte Puffer.
Zousätzlech, wa mir déi selwecht Explosiounen an der Produktioun haten, krute mir Reklamatioune vu Programméierer an Tester: am Moment wou se dës Logbicher wierklech gebraucht hunn, kruten se se ganz lues.
Si hunn ugefaang et erauszefannen. Engersäits war et kloer datt souwuel Sichufroen wéi och Indexéierungsufroe veraarbecht goufen, am Wesentlechen, op déiselwecht physesch Maschinnen, an op eng oder aner Manéier géifen et bestëmmte Réckzuch ginn.
Awer dëst kéint deelweis ëmgoen wéinst der Tatsaach, datt an de sechsten Versioune vun Elasticsearch en Algorithmus erschéngt, deen Iech erlaabt Ufroen tëscht relevanten Dateknäppchen ze verdeelen net no dem zoufällege Round-Robin-Prinzip (de Container deen d'Indexéierung mécht an de primäre hält) -Shard ka ganz beschäftegt sinn, et gëtt kee Wee fir séier ze reagéieren), awer dës Ufro un e manner gelueden Container mat engem Replica-Shard weiderzebréngen, dee vill méi séier reagéiert. An anere Wierder, mir ukomm use_adaptive_replica_selection: richteg.
D'Liesbild fänkt esou un:
Den Iwwergank zu dësem Algorithmus huet et méiglech gemaach d'Ufrozäit wesentlech ze verbesseren an deene Momenter wou mir e grousse Flux vu Logbicher haten fir ze schreiwen.
Schlussendlech war den Haaptproblem d'schmerzlos Entfernung vum Rechenzentrum.
Wat mir aus dem Stärekoup wollten direkt nodeems se d'Verbindung mat engem DC verluer hunn:
- Wa mir en aktuellen Meeschter am gescheitert Datenzenter hunn, da gëtt se nei gewielt an als Roll an en aneren Node an engem aneren DC geplënnert.
- De Meeschter wäert séier all onzougängleche Wirbelen aus dem Cluster ewechhuelen.
- Baséierend op déi verbleiwen, wäert hien verstoen: am verluerenen Datenzenter hu mir esou an esou primär Schnëtt gehat, hie wäert séier komplementär Replica-Shards an de verbleiwen Rechenzentren förderen, a mir wäerte weider d'Indexéiere vun den Donnéeën.
- Als Resultat vun dësem wäert de Cluster d'Schreiwen an d'Liesendoutput graduell ofbauen, awer am Allgemengen funktionnéiert alles, awer lues, awer stabil.
Wéi et sech erausstellt, wollte mir eppes wéi dat:
A mir hunn déi folgend:
Wéi ass et geschitt?
Wéi de Rechenzentrum gefall ass, gouf eise Meeschter de Flaschenhals.
Firwat?
D'Tatsaach ass datt de Master en TaskBatcher huet, dee verantwortlech ass fir verschidden Aufgaben an Eventer am Cluster ze verdeelen. All Node-Ausgang, all Promotioun vun engem Shard vu Replik op Primär, all Aufgab fir e Shard iergendwou ze kreéieren - dat alles geet als éischt op TaskBatcher, wou et sequentiell an an engem thread veraarbecht gëtt.
Zu der Zäit vum Réckzuch vun engem Rechenzentrum huet sech erausgestallt datt all Datenknäppchen an den iwwerliewende Rechenzentren et als hir Pflicht ugesinn hunn, de Meeschter z'informéieren "Mir hunn esou an esou Schnëtt verluer an esou an esou Datenknäppchen."
Zur selwechter Zäit hunn déi iwwerliewend Dateknäppchen all dës Informatioun un den aktuellen Meeschter geschéckt a probéiert op d'Bestätegung ze waarden datt hien et akzeptéiert huet. Si hunn net drop gewaart, well de Meeschter Aufgaben méi séier krut wéi hie konnt beäntweren. D'Knäppercher hunn d'Widderhuelungsfuerderunge gestoppt, an de Meeschter zu dëser Zäit huet net emol probéiert se ze beäntweren, awer war komplett an der Aufgab absorbéiert fir Ufroen no Prioritéit ze sortéieren.
An der Terminalform huet sech erausgestallt datt d'Datennoden de Master op de Punkt gespammelt hunn datt et a voll GC gaang ass. Duerno ass eis Meeschterroll op en nächsten Node geplënnert, absolut datselwecht geschitt mat deem, an als Resultat ass de Stärekoup komplett zesummegeklappt.
Mir hunn Miessunge gemaach, a virun der Versioun 6.4.0, wou dëst fixéiert gouf, war et genuch fir eis gläichzäiteg nëmmen 10 Dateknuten aus 360 auszebréngen fir de Cluster komplett auszeschalten.
Et huet sou eppes ausgesinn:
No der Versioun 6.4.0, wou dëse schreckleche Feeler fixéiert gouf, hunn d'Datennoden opgehalen de Master ëmzebréngen. Awer dat huet hien net "méi schlau" gemaach. Nämlech: wa mir 2, 3 oder 10 (all Zuel aner wéi een) Datenknäppchen ausginn, kritt de Meeschter e puer éischte Message deen seet datt den Node A fort ass, a probéiert den Node B, Node C iwwer dëst, Node D ze soen.
An am Moment kann dëst nëmmen duerch d'Astellung vun engem Timeout fir Versich een iwwer eppes ze soen, gläich un ongeféier 20-30 Sekonnen, an domatter Kontroll der Vitesse vun der Daten Zentrum Plënneren aus dem Stärekoup.
Am Prinzip passt dat an d'Ufuerderungen, déi am Ufank am Kader vum Projet dem Endprodukt virgestallt goufen, awer aus der Siicht vun der "renger Wëssenschaft" ass dëst e Feeler. Wat iwwregens erfollegräich vun den Entwéckler an der Versioun 7.2 fixéiert gouf.
Ausserdeem, wann e bestëmmten Dateknuet erausgaang ass, huet et sech erausgestallt datt d'Verbreedung vun Informatioun iwwer seng Sortie méi wichteg war wéi de ganze Stärekoup ze soen datt et esou an esou Primär-Schärften drop waren (fir e Replica-Shard an aneren Donnéeën ze förderen Zentrum an der Primärschoul, an Informatiounen kéint op hinnen geschriwwe ginn).
Dofir, wann alles scho verstuerwen ass, ginn déi verëffentlecht Dateknäppchen net direkt als onbestänneg markéiert. Deementspriechend si mir gezwongen ze waarden bis all Pings op déi verëffentlecht Datenknäppchen ausgeschloss sinn, an nëmmen duerno fänkt eise Cluster un eis ze soen datt do, do, an do musse mir weider Informatioun ophuelen. Dir kënnt méi iwwer dëst liesen .
Als Resultat dauert d'Operatioun vum Réckzuch vun engem Datenzenter haut ongeféier 5 Minutten während der Rushstonn. Fir sou e groussen a knaschtege Koloss ass dëst e relativ gutt Resultat.
Als Resultat hu mir zu folgender Decisioun komm:
- Mir hunn 360 Datennoden mat 700 Gigabyte Disken.
- 60 Koordinatore fir de Verkéier duerch déiselwecht Dateknäppchen ze routen.
- 40 Meeschter, déi mir als eng Aart Ierfschaft hannerlooss hunn zënter Versioune virun 6.4.0 - fir de Réckzuch vum Rechenzentrum ze iwwerliewen, ware mir geeschteg bereet, verschidde Maschinnen ze verléieren, fir garantéiert ze sinn, e Quorum vun de Meeschteren ze hunn och an am schlëmmste Fall Szenario
- All Versuch, Rollen op engem Container ze kombinéieren, gouf mat der Tatsaach begéint, datt fréier oder spéider de Node ënner Laascht briechen.
- De ganze Cluster benotzt eng Heap.Gréisst vun 31 Gigabytes: all Versuche fir d'Gréisst ze reduzéieren hunn dozou gefouert datt entweder e puer Noden op schwéier Sichufroe mat der féierender Wildcard ëmbruecht goufen oder de Circuit Breaker an Elasticsearch selwer kritt.
- Zousätzlech, fir d'Sichleistung ze garantéieren, hu mir probéiert d'Zuel vun den Objeten am Stärekoup sou kleng wéi méiglech ze halen, fir esou wéineg Eventer wéi méiglech am Flaschenhals ze veraarbecht, dee mir am Master kruten.
Endlech iwwer Iwwerwaachung
Fir sécherzestellen datt dat alles funktionnéiert wéi virgesinn, iwwerwaache mir déi folgend:
- All Dateknuet mellt eis Wollek datt et existéiert, an et gi sou an esou Schnëtt drop. Wa mir iergendwou eppes ausléisen, mellt de Stärekoup no 2-3 Sekonnen datt mir am Zentrum A d'Knäppchen 2, 3 a 4 ausgeschloss hunn - dat heescht datt mir an aneren Datenzenteren ënner kengen Ëmstänn déi Knäpper kënnen ausléisen, op deenen et nëmmen ee Schier ass lénks.
- Wann Dir d'Natur vum Verhalen vum Meeschter kennt, kucke mir ganz suergfälteg op d'Zuel vun den ofhängegen Aufgaben. Well och eng festgehalen Aufgab, wann et net an der Zäit ass, theoretesch an enger Noutsituatioun kann de Grond ginn, firwat zum Beispill d'Promotioun vun engem Replika-Schärft an der Primär net funktionnéiert, dofir hält d'Indexéierung op.
- Mir kucken och ganz genee op Drecksverzögerungen, well mir hate scho grouss Schwieregkeeten mat deem während der Optimisatioun.
- Refuséiert duerch Fuedem fir am Viraus ze verstoen wou de Flaschenhals ass.
- Gutt, Standard Metriken wéi Heap, RAM an I / O.
Wann Dir Iwwerwaachung baut, musst Dir d'Features vum Thread Pool an Elasticsearch berücksichtegen. beschreift d'Konfiguratiounsoptiounen an d'Standardwäerter fir d'Sich an d'Indexéierung, awer ass komplett roueg iwwer thread_pool.management. Dës Threads veraarbechten, besonnesch Ufroen wéi _cat/shards an aner ähnlech, déi bequem ze benotzen beim Schreiwen Iwwerwachung. Wat de Cluster méi grouss ass, wat méi esou Ufroe pro Zäiteenheet ausgefouert ginn, an déi uewe genannte thread_pool.management gëtt net nëmmen net an der offizieller Dokumentatioun presentéiert, mee ass och standardiséiert op 5 Threads limitéiert, déi ganz séier entsuergt ginn, no déi Iwwerwaachung ophält richteg ze schaffen.
Wat ech zum Schluss wëll soen: Mir hunn et gemaach! Mir konnten eise Programméierer an Entwéckler e Tool ginn, dat a bal all Situatioun séier an zouverlässeg Informatiounen iwwer dat wat an der Produktioun geschitt ass.
Jo, et huet sech als zimlech komplizéiert erausgestallt, awer trotzdem hu mir et fäerdeg bruecht eis Wënsch an existéierend Produkter ze passen, déi mir net fir eis selwer musse patchen an nei schreiwen.
Source: will.com