Elasticsearch կլաստեր 200 TB+

Շատ մարդիկ պայքարում են Elasticsearch-ի հետ: Բայց ի՞նչ է տեղի ունենում, երբ ցանկանում եք օգտագործել այն տեղեկամատյանները «հատկապես մեծ ծավալով» պահելու համար: Եվ արդյոք ցավի՞ց է զգալ մի քանի տվյալների կենտրոններից որևէ մեկի ձախողումը: Ինչպիսի՞ ճարտարապետություն պետք է ստեղծեք, և ինչ որոգայթների վրա կբախվեք:

Մենք Odnoklassniki-ում որոշեցինք օգտագործել elasticsearch-ը լոգերի կառավարման խնդիրը լուծելու համար, և այժմ մենք կիսում ենք մեր փորձը Habr-ի հետ՝ և՛ ճարտարապետության, և՛ որոգայթների մասին:

Ես Պյոտր Զայցևն եմ, աշխատում եմ որպես համակարգի ադմինիստրատոր Odnoklassniki-ում: Մինչ այդ ես նաև ադմին էի, աշխատում էի Manticore Search, Sphinx search, Elasticsearch-ի հետ։ Միգուցե, եթե մեկ այլ ...որոնում հայտնվի, ես էլ հավանաբար կաշխատեմ դրա հետ։ Ես նաև կամավոր հիմունքներով մասնակցում եմ մի շարք բաց կոդով նախագծերի:

Երբ եկա Odnoklassniki, հարցազրույցի ժամանակ անխոհեմ ասացի, որ կարող եմ աշխատել Elasticsearch-ի հետ։ Այն բանից հետո, երբ ես հասցրի դա անել և կատարել մի քանի պարզ առաջադրանքներ, ինձ տրվեց այն ժամանակվա լոգերի կառավարման համակարգը բարեփոխելու մեծ խնդիր:

Պահանջներ

Համակարգի պահանջները ձևակերպվել են հետևյալ կերպ.

• Graylog-ը պետք է օգտագործվեր որպես ճակատ: Քանի որ ընկերությունն արդեն ուներ այս արտադրանքն օգտագործելու փորձ, ծրագրավորողները և փորձարկողները գիտեին դա, դա նրանց համար ծանոթ էր և հարմար:
• Տվյալների ծավալը՝ միջինը վայրկյանում 50-80 հազար հաղորդագրություն, բայց եթե ինչ-որ բան կոտրվում է, ապա երթևեկությունը ոչնչով չի սահմանափակվում, այն կարող է լինել 2-3 միլիոն տող վայրկյանում։
• Հաճախորդների հետ քննարկելով որոնման հարցումների մշակման արագության պահանջները՝ մենք հասկացանք, որ նման համակարգ օգտագործելու բնորոշ օրինաչափությունը հետևյալն է. մարդիկ վերջին երկու օրվա ընթացքում փնտրում են իրենց հավելվածի տեղեկամատյանները և չեն ցանկանում սպասել ավելի քան երկրորդը` ձևակերպված հարցման արդյունքի համար:
• Ադմինիստրատորները պնդում էին, որ անհրաժեշտության դեպքում համակարգը հեշտությամբ ընդլայնելի լինի՝ չպահանջելով, որ նրանք խորապես խորանան, թե ինչպես է այն աշխատում:
• Այսպիսով, պահպանման միակ խնդիրը, որ այս համակարգերը պարբերաբար պահանջում են, որոշ սարքաշար փոխելն է:
• Բացի այդ, Odnoklassniki-ն ունի հիանալի տեխնիկական ավանդույթ. ցանկացած ծառայություն, որը մենք գործարկում ենք, պետք է վերապրի տվյալների կենտրոնի խափանումը (հանկարծակի, չպլանավորված և բացարձակապես ցանկացած պահի):

Ամենաշատը մեզ վրա նստեց այս նախագծի իրականացման վերջին պահանջը, որի մասին կխոսեմ ավելի մանրամասն։

չորեքշաբթի

Մենք աշխատում ենք չորս տվյալների կենտրոններում, մինչդեռ Elasticsearch տվյալների հանգույցները կարող են տեղակայվել միայն երեքում (մի շարք ոչ տեխնիկական պատճառներով):

Այս չորս տվյալների կենտրոնները պարունակում են մոտավորապես 18 հազար տարբեր տեղեկամատյանների աղբյուրներ՝ սարքավորումներ, կոնտեյներներ, վիրտուալ մեքենաներ:

Կարևոր առանձնահատկություն. կլաստերը սկսվում է տարաներով Պոդման ոչ թե ֆիզիկական մեքենաների վրա, այլ վրա սեփական ամպային արտադրանք մեկ ամպ. Բեռնարկղերը երաշխավորված են 2 միջուկով, որը նման է 2.0 ԳՀց v4-ին, մնացած միջուկները վերամշակելու հնարավորությամբ, եթե դրանք պարապ են:

Այլ կերպ ասած:

Տոպոլոգիա

Ես սկզբում տեսա լուծման ընդհանուր ձևը հետևյալ կերպ.

• Graylog տիրույթի A-գրառման հետևում 3-4 VIP-ներ են, սա այն հասցեն է, որին ուղարկվում են տեղեկամատյանները:
• յուրաքանչյուր VIP հանդիսանում է LVS հավասարակշռող:
• Դրանից հետո տեղեկամատյանները գնում են Graylog մարտկոց, որոշ տվյալները GELF ձևաչափով են, որոշները syslog ձևաչափով:
• Այնուհետև այս ամենը մեծ խմբաքանակներով գրվում է Elasticsearch համակարգողների մարտկոցին:
• Իսկ նրանք իրենց հերթին գրելու և կարդալու հարցումներ են ուղարկում տվյալների համապատասխան հանգույցներին։

Տերմինոլոգիա

Թերեւս ոչ բոլորն են մանրամասն հասկանում տերմինաբանությունը, ուստի ես կցանկանայի մի փոքր կանգ առնել դրա վրա:

Elasticsearch-ն ունի մի քանի տեսակի հանգույցներ՝ վարպետ, համակարգող, տվյալների հանգույց։ Գոյություն ունեն երկու այլ տեսակներ տարբեր տեղեկամատյանների փոխակերպումների և տարբեր կլաստերների միջև հաղորդակցության համար, բայց մենք օգտագործեցինք միայն թվարկվածները:

վարպետ
Այն կապում է կլաստերում առկա բոլոր հանգույցները, պահպանում է թարմացված կլաստերի քարտեզը և բաշխում այն ​​հանգույցների միջև, մշակում է իրադարձությունների տրամաբանությունը և կատարում տարբեր տեսակի կլաստերային տնային տնտեսություն:

Համակարգող
Կատարում է մեկ առաջադրանք՝ ընդունում է հաճախորդներից կարդալու կամ գրելու հարցումները և ուղղորդում այս երթևեկությունը: Գրելու հարցում լինելու դեպքում, ամենայն հավանականությամբ, այն կհարցնի վարպետին, թե համապատասխան ինդեքսի որ հատվածը պետք է տեղադրի այն և կվերահղի հարցումը:

Տվյալների հանգույց
Պահպանում է տվյալները, կատարում է որոնողական հարցումներ, որոնք գալիս են դրսից և կատարում գործողություններ դրանց վրա տեղակայված բեկորների վրա:

Գրեյլոգ
Սա Kibana-ի միաձուլման նման մի բան է Logstash-ի հետ ELK փաթեթում: Graylog-ը համատեղում է և՛ միջերեսը, և՛ տեղեկամատյանների մշակման խողովակաշարը: Կափարիչի տակ Graylog-ն աշխատում է Kafka-ն և Zookeeper-ը, որոնք ապահովում են կապը Graylog-ին որպես կլաստեր: Graylog-ը կարող է քեշավորել տեղեկամատյանները (Kafka), եթե Elasticsearch-ն անհասանելի է, և կրկնում է անհաջող կարդալու և գրելու հարցումները, խմբավորում և նշում տեղեկամատյանները՝ ըստ սահմանված կանոնների: Ինչպես Logstash-ը, Graylog-ն ունի տողերը Elasticsearch-ում գրելուց առաջ փոփոխելու գործառույթ:

Բացի այդ, Graylog-ն ունի ներկառուցված ծառայության բացահայտում, որը թույլ է տալիս, հիմնվելով մեկ հասանելի Elasticsearch հանգույցի վրա, ստանալ ամբողջ կլաստերի քարտեզը և զտել այն հատուկ պիտակով, ինչը հնարավորություն է տալիս հարցումներն ուղղել որոշակի կոնտեյներներ:

Տեսողականորեն նման բան է թվում.

Սա սքրինշոթ է կոնկրետ օրինակից: Այստեղ մենք կառուցում ենք հիստոգրամ՝ հիմնվելով որոնման հարցման վրա և ցուցադրում համապատասխան տողեր։

Ցուցանիշները

Վերադառնալով համակարգի ճարտարապետությանը, ես կցանկանայի ավելի մանրամասն անդրադառնալ, թե ինչպես ենք մենք կառուցել ինդեքսային մոդելը, որպեսզի այն ամեն ինչ ճիշտ աշխատի:

Վերևի դիագրամում սա ամենացածր մակարդակն է՝ Elasticsearch տվյալների հանգույցները:

Ինդեքսը մեծ վիրտուալ միավոր է, որը կազմված է Elasticsearch-ի բեկորներից: Ինքնին բեկորներից յուրաքանչյուրը ոչ այլ ինչ է, քան Լյուսենի ինդեքս: Եվ յուրաքանչյուր Lucene ինդեքս, իր հերթին, բաղկացած է մեկ կամ մի քանի հատվածներից։

Նախագծելիս մենք հասկացանք, որ մեծ քանակությամբ տվյալների վրա կարդալու արագության պահանջը բավարարելու համար մենք պետք է այս տվյալները հավասարապես «տարածենք» տվյալների հանգույցներում:

Սա հանգեցրեց նրան, որ մեկ ինդեքսի բեկորների քանակը (կրկնօրինակներով) պետք է խստորեն հավասար լինի տվյալների հանգույցների թվին: Նախ՝ կրկնօրինակման գործակից ապահովելու համար երկուսին հավասար (այսինքն՝ մենք կարող ենք կորցնել կլաստերի կեսը)։ Եվ, երկրորդը, կլաստերի առնվազն կեսի վերաբերյալ կարդալու և գրելու հարցումները մշակելու համար:

Մենք նախ որոշեցինք պահպանման ժամկետը 30 օր:

Բեկորների բաշխումը գրաֆիկորեն կարելի է ներկայացնել հետևյալ կերպ.

Ամբողջ մուգ մոխրագույն ուղղանկյունը ցուցիչ է: Դրանում գտնվող ձախ կարմիր քառակուսին առաջնային բեկորն է, առաջինը ինդեքսում։ Իսկ կապույտ քառակուսին կրկնօրինակ բեկոր է: Դրանք տեղակայված են տվյալների տարբեր կենտրոններում:

Երբ մենք ավելացնում ենք ևս մեկ բեկոր, այն գնում է երրորդ տվյալների կենտրոն: Եվ, ի վերջո, մենք ստանում ենք այս կառուցվածքը, որը հնարավորություն է տալիս կորցնել DC-ն՝ չկորցնելով տվյալների հետևողականությունը.

Ցուցանիշների ռոտացիան, այսինքն. ստեղծելով նոր ինդեքս և ջնջելով ամենահինը, այն հավասարեցրինք 48 ժամի (ըստ ինդեքսների օգտագործման օրինաչափության. ամենից հաճախ որոնվում են վերջին 48 ժամը)։

Այս ցուցանիշի ռոտացիայի միջակայքը պայմանավորված է հետևյալ պատճառներով.

Երբ որոնման հարցումը հասնում է կոնկրետ տվյալների հանգույց, ապա, կատարողականի տեսակետից, ավելի շահավետ է, երբ հարցվում է մեկ բեկոր, եթե դրա չափը համեմատելի է հանգույցի ազդրի չափի հետ: Սա թույլ է տալիս ինդեքսի «տաք» մասը պահել կույտում և արագ մուտք գործել դրան: Երբ կան շատ «տաք մասեր», ինդեքսի որոնման արագությունը նվազում է:

Երբ հանգույցը սկսում է կատարել որոնման հարցում մեկ բեկորի վրա, այն հատկացնում է մի շարք թելեր, որոնք հավասար են ֆիզիկական մեքենայի հիպերթելային միջուկների թվին: Եթե ​​որոնման հարցումը ազդում է մեծ թվով բեկորների վրա, ապա թելերի թիվը համամասնորեն աճում է: Սա բացասաբար է անդրադառնում որոնման արագության վրա և բացասաբար է անդրադառնում նոր տվյալների ինդեքսավորման վրա։

Որոնման անհրաժեշտ ուշացումն ապահովելու համար մենք որոշեցինք օգտագործել SSD: Հարցումները արագ մշակելու համար այս բեռնարկղերը հյուրընկալող մեքենաները պետք է ունենային առնվազն 56 միջուկ: 56 թիվը ընտրվել է որպես պայմանականորեն բավարար արժեք, որը որոշում է թելերի քանակը, որոնք Elasticsearch-ը կստեղծի շահագործման ընթացքում: Elasitcsearch-ում թելերի լողավազանի շատ պարամետրեր ուղղակիորեն կախված են առկա միջուկների քանակից, որն իր հերթին ուղղակիորեն ազդում է կլաստերի անհրաժեշտ քանակի հանգույցների վրա՝ համաձայն «ավելի քիչ միջուկներ՝ ավելի շատ հանգույցներ» սկզբունքի:

Արդյունքում մենք պարզեցինք, որ միջինում մեկ բեկորը կշռում է մոտ 20 գիգաբայթ, իսկ մեկ ինդեքսի վրա կա 1 բեկոր: Համապատասխանաբար, եթե դրանք պտտենք 360 ժամը մեկ, ապա ունենք դրանցից 48-ը։ Յուրաքանչյուր ինդեքս պարունակում է տվյալներ 15 օրվա համար:

Տվյալների գրման և ընթերցման սխեմաներ

Եկեք պարզենք, թե ինչպես են տվյալները գրանցվում այս համակարգում:

Ենթադրենք, Graylog-ից ինչ-որ հարցում է հասնում համակարգողին: Օրինակ, մենք ցանկանում ենք ինդեքսավորել 2-3 հազար տող:

Համակարգողը, ստանալով Graylog-ի հարցումը, հարցնում է վարպետին. «Ինդեքսիավորման հարցումում մենք հատուկ նշել ենք ինդեքսը, բայց թե որ հատվածում է այն գրել, նշված չէ»:

Վարպետը պատասխանում է. «Գրի՛ր այս տեղեկատվությունը 71 համարի վրա», որից հետո այն ուղարկվում է անմիջապես համապատասխան տվյալների հանգույց, որտեղ գտնվում է առաջնային բեկորային համարը 71:

Որից հետո գործարքների գրանցամատյանը կրկնօրինակվում է կրկնօրինակի բեկորին, որը գտնվում է մեկ այլ տվյալների կենտրոնում:

Գրեյլոգից որոնման հարցում է հասնում համակարգողին: Համակարգողն այն վերահղում է ըստ ինդեքսի, մինչդեռ Elasticsearch-ը հարցումները բաշխում է հիմնական-շարդի և կրկնօրինակի բեկորների միջև՝ օգտագործելով round-robin սկզբունքը:

180 հանգույցներն արձագանքում են անհավասարաչափ, և մինչ նրանք արձագանքում են, համակարգողը կուտակում է տեղեկատվություն, որն արդեն «թքվել է» ավելի արագ տվյալների հանգույցների կողմից: Դրանից հետո, երբ կա՛մ ամբողջ տեղեկատվությունը հասել է, կա՛մ հարցումը հասել է ժամանակի ավարտին, այն ամեն ինչ տալիս է անմիջապես հաճախորդին:

Այս ամբողջ համակարգը միջինում մշակում է որոնման հարցումները վերջին 48 ժամվա ընթացքում 300-400 մվ-ով, ​​բացառելով այն հարցումները, որոնցում առկա են առաջատար wildcard:

Flowers with Elasticsearch. Java-ի կարգավորում

Որպեսզի ամեն ինչ աշխատի այնպես, ինչպես մենք ի սկզբանե ցանկանում էինք, մենք շատ երկար ժամանակ ծախսեցինք կլաստերի տարբեր բաների վրիպազերծման վրա:

Հայտնաբերված խնդիրների առաջին մասը կապված էր Elasticsearch-ում Java-ի նախնական կազմաձևման հետ:

Խնդիր առաջին
Մենք շատ մեծ թվով հաղորդումներ ենք տեսել, որ Lucene մակարդակում, երբ աշխատում են ֆոնային աշխատանքները, Lucene հատվածի միաձուլումը ձախողվում է սխալմամբ: Միևնույն ժամանակ, գրանցամատյաններում պարզ էր, որ սա OutOfMemoryError սխալ էր: Հեռաչափությունից տեսանք, որ ազդրը ազատ է, և պարզ չէր, թե ինչու էր այս վիրահատությունը ձախողվում։

Պարզվեց, որ Lucene ինդեքսի միաձուլումները տեղի են ունենում ազդրից դուրս: Իսկ տարաները սպառվող ռեսուրսների առումով բավականին խիստ սահմանափակ են։ Միայն կույտը կարող էր տեղավորվել այս ռեսուրսների մեջ (heap.size արժեքը մոտավորապես հավասար էր RAM-ին), և որոշ off-heap գործողություններ խափանվեցին հիշողության բաշխման սխալով, եթե ինչ-ինչ պատճառներով դրանք չտեղավորվեին մինչև սահմանաչափը մնացած ~500 ՄԲ-ի մեջ:

Ուղղումը բավականին չնչին էր. կոնտեյների համար հասանելի օպերատիվ հիշողության ծավալն ավելացվեց, որից հետո մենք մոռացանք, որ նույնիսկ նման խնդիրներ ունենք:

Խնդիր երկրորդ
Կլաստերի գործարկումից 4-5 օր անց մենք նկատեցինք, որ տվյալների հանգույցները սկսեցին պարբերաբար դուրս գալ կլաստերից և 10-20 վայրկյան հետո մտնել այնտեղ:

Երբ մենք սկսեցինք պարզել դա, պարզվեց, որ Elasticsearch-ում այս անջատված հիշողությունը ոչ մի կերպ չի վերահսկվում: Երբ մենք ավելի շատ հիշողություն տվեցինք կոնտեյներին, մենք կարողացանք ուղղակի բուֆերային լողավազանները լրացնել տարբեր տեղեկություններով, և այն մաքրվեց միայն Elasticsearch-ից բացահայտ GC-ի գործարկումից հետո:

Որոշ դեպքերում այս գործողությունը բավականին երկար է տևել, և այս ընթացքում կլաստերին հաջողվել է նշել այս հանգույցը որպես արդեն դուրս եկած: Այս խնդիրը լավ նկարագրված է այստեղ.

Լուծումը հետևյալն էր. մենք սահմանափակեցինք Java-ի հնարավորությունը՝ օգտագործելու հիշողության մեծ մասը կույտից դուրս այդ գործողությունների համար: Մենք սահմանափակեցինք այն 16 գիգաբայթով (-XX:MaxDirectMemorySize=16g)՝ ապահովելով, որ բացահայտ GC-ն շատ ավելի հաճախ կանչվի և շատ ավելի արագ մշակվի՝ այդպիսով այլևս չապակայունացնելով կլաստերը:

Խնդիր երրորդ
Եթե ​​կարծում եք, որ «կլաստերից ամենաանսպասելի պահին լքող հանգույցների» հետ կապված խնդիրներն ավարտվել են, ապա սխալվում եք։

Երբ մենք կազմաձևեցինք աշխատանքը ինդեքսներով, մենք ընտրեցինք mmapfs to կրճատել որոնման ժամանակը թարմ բեկորների վրա՝ մեծ սեգմենտացիայով։ Սա բավականին կոպիտ սխալ էր, քանի որ mmapfs օգտագործելիս ֆայլը քարտեզագրվում է RAM-ի մեջ, այնուհետև մենք աշխատում ենք քարտեզագրված ֆայլի հետ: Դրա պատճառով պարզվում է, որ երբ GC-ն փորձում է դադարեցնել թեմաները հավելվածում, մենք շատ երկար ժամանակով գնում ենք անվտանգ կետ, և դրան հասնելու ճանապարհին հավելվածը դադարում է պատասխանել վարպետի խնդրանքներին այն մասին, թե արդյոք այն կենդանի է: . Համապատասխանաբար, վարպետը կարծում է, որ հանգույցն այլևս չկա կլաստերում։ Դրանից հետո 5-10 վայրկյան հետո աղբահանը աշխատում է, հանգույցը կենդանանում է, նորից մտնում է կլաստերի մեջ և սկսում է բեկորների սկզբնավորումը: Այդ ամենը շատ նման էր «արտադրության, որին մենք արժանի էինք» և ոչ մի լուրջ բանի հարմար չէր:

Այս պահվածքից ազատվելու համար մենք նախ անցանք ստանդարտ niof-ների, իսկ հետո, երբ Elastic-ի հինգերորդ տարբերակներից տեղափոխեցինք վեցերորդ, փորձեցինք հիբրիդներ, որտեղ այս խնդիրը չէր վերարտադրվում։ Դուք կարող եք ավելին կարդալ պահեստավորման տեսակների մասին այստեղ.

Խնդիր չորրորդ
Հետո մեկ այլ շատ հետաքրքիր խնդիր կար, որը մենք ռեկորդային ժամանակով բուժեցինք։ Մենք բռնեցինք 2-3 ամիս, քանի որ դրա օրինաչափությունը բացարձակապես անհասկանալի էր։

Երբեմն մեր համակարգողները գնում էին Full GC, սովորաբար ճաշից հետո, և այնտեղից չէին վերադառնում: Միևնույն ժամանակ, GC-ի հետաձգումը գրանցելիս այն կարծես այսպիսին էր՝ ամեն ինչ լավ է ընթանում, լավ, լավ, և հետո հանկարծ ամեն ինչ շատ վատ է ընթանում:

Սկզբում մենք մտածեցինք, որ ունենք չար օգտատեր, ով ինչ-որ հարցում էր դիմում, որը համակարգողին դուրս էր թողնում աշխատանքային ռեժիմից։ Մենք շատ երկար ժամանակ գրանցում էինք հարցումները՝ փորձելով պարզել, թե ինչ է կատարվում:

Արդյունքում պարզվեց, որ այն պահին, երբ օգտատերը հսկայական հարցում է ուղարկում, և այն հասնում է կոնկրետ Elasticsearch համակարգողին, որոշ հանգույցներ ավելի երկար են արձագանքում, քան մյուսները։

Եվ մինչ համակարգողը սպասում է պատասխանի բոլոր հանգույցներից, նա կուտակում է արդեն արձագանքած հանգույցներից ուղարկված արդյունքները։ GC-ի համար սա նշանակում է, որ մեր կույտերի օգտագործման օրինաչափությունները շատ արագ փոխվում են: Եվ GC-ն, որը մենք օգտագործում էինք, չկարողացավ հաղթահարել այս խնդիրը:

Այս իրավիճակում կլաստերի վարքագիծը փոխելու միակ ուղղումը, որը մենք գտանք, միգրացիան դեպի JDK13 և Shenandoah աղբահանի օգտագործումն է: Սա լուծեց խնդիրը, մեր համակարգողները դադարեցին ընկնել։

Այստեղ ավարտվեցին Java-ի հետ կապված խնդիրները և սկսվեցին թողունակության խնդիրները:

«Հատապտուղներ» Elasticsearch-ով. թողունակություն

Արտադրողականության հետ կապված խնդիրները նշանակում են, որ մեր կլաստերը կայուն է աշխատում, սակայն ինդեքսավորված փաստաթղթերի քանակի գագաթնակետին և մանևրների ընթացքում կատարողականը անբավարար է:

Առաջին ախտանիշը, որը նկատվում է. արտադրության մեջ որոշ «պայթյունների» ժամանակ, երբ հանկարծ ստեղծվում են շատ մեծ թվով տեղեկամատյաններ, ինդեքսավորման սխալը es_rejected_execution սկսում է հաճախակի թարթել Graylog-ում:

Դա պայմանավորված էր նրանով, որ thread_pool.write.queue-ը տվյալների մեկ հանգույցում, մինչև այն պահը, երբ Elasticsearch-ը կարողանա մշակել ինդեքսավորման հարցումը և վերբեռնել տեղեկատվությունը սկավառակի վրա գտնվող հատվածի վրա, կարող է լռելյայն քեշավորել ընդամենը 200 հարցում: Եվ մեջ Elasticsearch փաստաթղթեր Այս պարամետրի մասին շատ քիչ է խոսվում։ Նշված են միայն թելերի առավելագույն քանակը և լռելյայն չափը:

Իհարկե, մենք գնացինք շրջելու այս արժեքը և պարզեցինք հետևյալը. մասնավորապես, մեր կարգավորումներում մինչև 300 հարցումները բավականին լավ են պահվում, և ավելի բարձր արժեքը հղի է նրանով, որ մենք նորից թռչում ենք Full GC:

Բացի այդ, քանի որ դրանք հաղորդագրությունների խմբաքանակներ են, որոնք հասնում են մեկ հարցման ընթացքում, անհրաժեշտ էր շտկել Graylog-ը այնպես, որ այն գրի ոչ հաճախ և փոքր խմբաքանակներով, այլ հսկայական խմբաքանակներով կամ 3 վայրկյանը մեկ անգամ, եթե խմբաքանակը դեռ ամբողջական չէ: Այս դեպքում պարզվում է, որ Elasticsearch-ում մեր գրած տեղեկատվությունը հասանելի է դառնում ոչ թե երկու վայրկյանում, այլ հինգ վայրկյանում (ինչը մեզ բավականին հարմար է), այլ այն թվով կրկնապատկերներ, որոնք պետք է արվեն՝ մեծ միջով անցնելու համար։ տեղեկատվության փաթեթը կրճատվում է.

Սա հատկապես կարևոր է այն պահերին, երբ ինչ-որ բան ինչ-որ տեղ ընկել է և կատաղորեն հաղորդվում է դրա մասին, որպեսզի չստանաք ամբողջովին սպամավորված Էլաստիկ, իսկ որոշ ժամանակ անց՝ Graylog հանգույցները, որոնք անգործունակ են խցանված բուֆերների պատճառով:

Բացի այդ, երբ արտադրության մեջ մենք ունեցանք նույն պայթյունները, մենք բողոքներ ստացանք ծրագրավորողներից և փորձարկողներից. այն պահին, երբ նրանց իսկապես անհրաժեշտ էին այդ գերանները, դրանք շատ դանդաղ էին տալիս:

Նրանք սկսեցին պարզել դա: Մի կողմից, պարզ էր, որ և՛ որոնման հարցումները, և՛ ինդեքսավորման հարցումները մշակվում էին, ըստ էության, նույն ֆիզիկական մեքենաների վրա, և այսպես թե այնպես, որոշակի անկումներ կլինեն:

Բայց դա կարելի էր մասամբ շրջանցել, քանի որ Elasticsearch-ի վեցերորդ տարբերակներում հայտնվեց ալգորիթմ, որը թույլ է տալիս հարցումները բաշխել համապատասխան տվյալների հանգույցների միջև՝ ոչ ըստ պատահական շրջանաձև սկզբունքի (կոնտեյներ, որը ինդեքսավորում է և պահում է առաջնայինը): shard-ը կարող է շատ զբաղված լինել, արագ արձագանքելու տարբերակ չի լինի), բայց այս հարցումը փոխանցել ավելի քիչ բեռնված կոնտեյների՝ կրկնօրինակ-բեկորով, որը շատ ավելի արագ կպատասխանի: Այլ կերպ ասած, մենք հասանք use_adaptive_replica_selection. ճշմարիտ:

Ընթերցանության նկարը սկսում է այսպիսի տեսք ունենալ.

Այս ալգորիթմին անցումը հնարավորություն տվեց զգալիորեն բարելավել հարցումների ժամանակը այն պահերին, երբ մենք գրելու համար տեղեկամատյանների մեծ հոսք ունեինք:

Ի վերջո, հիմնական խնդիրը տվյալների կենտրոնի ցավազուրկ հեռացումն էր:

Այն, ինչ մենք ուզում էինք կլաստերից անմիջապես մեկ DC-ի հետ կապը կորցնելուց հետո.

• Եթե ​​մենք ունենք ընթացիկ վարպետ տվյալների ձախողված կենտրոնում, ապա այն կվերընտրվի և որպես դեր կտեղափոխվի մեկ այլ հանգույց մեկ այլ DC-ում:
• Վարպետը արագորեն կհեռացնի բոլոր անհասանելի հանգույցները կլաստերից:
• Մնացածների հիման վրա նա կհասկանա. կորած տվյալների կենտրոնում մենք ունեինք այս և այն առաջնային բեկորներ, նա արագորեն կխթանի լրացուցիչ կրկնօրինակների բեկորները մնացած տվյալների կենտրոններում, և մենք կշարունակենք ինդեքսավորել տվյալները:
• Սրա արդյունքում կլաստերի գրելու և կարդալու թողունակությունը աստիճանաբար կնվազի, բայց ընդհանուր առմամբ ամեն ինչ կաշխատի, թեև դանդաղ, բայց կայուն:

Ինչպես պարզվեց, մենք ուզում էինք այսպիսի բան.

Եվ մենք ստացանք հետևյալը.

Ինչպե՞ս եղավ:

Երբ տվյալների կենտրոնն ընկավ, մեր վարպետը դարձավ խցան:

Ինչու?

Փաստն այն է, որ վարպետն ունի TaskBatcher, որը պատասխանատու է կլաստերում որոշակի առաջադրանքների և իրադարձությունների բաշխման համար: Ցանկացած հանգույցի ելք, բեկորի ցանկացած առաջխաղացում՝ կրկնօրինակից առաջնային, ցանկացած խնդիր՝ ինչ-որ տեղ բեկոր ստեղծելու համար, այս ամենը նախ գնում է TaskBatcher-ին, որտեղ այն մշակվում է հաջորդաբար և մեկ շղթայում:

Տվյալների մեկ կենտրոնի դուրսբերման պահին պարզվեց, որ գոյատևած տվյալների կենտրոնների բոլոր տվյալների հանգույցները իրենց պարտքն էին համարում տեղեկացնել վարպետին «մենք կորցրել ենք այսինչ բեկորները և այսինչ տվյալների հանգույցները»:

Միևնույն ժամանակ, գոյատևած տվյալների հանգույցներն այս ամբողջ տեղեկատվությունը ուղարկեցին ներկայիս վարպետին և փորձեցին սպասել հաստատման, որ նա ընդունել է այն: Սրան չսպասեցին, քանի որ վարպետն առաջադրանքներն ավելի արագ էր ստանում, քան կարող էր պատասխանել։ Հանգույցները սպառեցին կրկնվող հարցումները, և վարպետն այս պահին նույնիսկ չփորձեց պատասխանել դրանց, այլ ամբողջովին կլանված էր հարցումները ըստ առաջնահերթության դասակարգելու:

Տերմինալային ձևով պարզվեց, որ տվյալների հանգույցները սպամ են ուղարկել վարպետին այն աստիճան, որ այն մտել է ամբողջական GC: Դրանից հետո մեր գլխավոր դերը տեղափոխվեց հաջորդ հանգույց, բացարձակապես նույնը տեղի ունեցավ նրա հետ, և արդյունքում կլաստերը ամբողջովին փլուզվեց:

Մենք չափումներ արեցինք, և մինչև 6.4.0 տարբերակը, որտեղ սա ֆիքսված էր, բավական էր, որ մենք միաժամանակ 10-ից միայն 360 տվյալների հանգույց դուրս գայինք, որպեսզի ամբողջությամբ անջատեինք կլաստերը:

Դա նման բան էր թվում.

6.4.0 տարբերակից հետո, որտեղ շտկվեց այս սարսափելի սխալը, տվյալների հանգույցները դադարեցին սպանել վարպետին: Բայց դա նրան «ավելի խելացի» չդարձրեց։ Երբ մենք դուրս ենք բերում 2, 3 կամ 10 (ցանկացած թիվ մեկից բացի) տվյալների հանգույց, վարպետը ստանում է առաջին հաղորդագրությունը, որն ասում է, որ A հանգույցը հեռացել է, և փորձում է այս մասին հայտնել B հանգույցին, C հանգույցին, D հանգույցին:

Եվ այս պահին դա կարող է լուծվել միայն՝ սահմանելով ինչ-որ մեկին ինչ-որ բանի մասին պատմելու փորձերի ժամանակացույց, որը հավասար է մոտ 20-30 վայրկյանի և այդպիսով վերահսկելու տվյալների կենտրոնի արագությունը, որը դուրս է գալիս կլաստերից:

Սկզբունքորեն, սա համապատասխանում է այն պահանջներին, որոնք ի սկզբանե ներկայացվել էին վերջնական արտադրանքին որպես նախագծի մաս, բայց «մաքուր գիտության» տեսանկյունից սա վրիպակ է: Ինչն, ի դեպ, հաջողությամբ շտկվել է մշակողների կողմից 7.2 տարբերակում։

Ավելին, երբ որոշակի տվյալների հանգույց դուրս եկավ, պարզվեց, որ դրա ելքի մասին տեղեկատվության տարածումն ավելի կարևոր էր, քան ամբողջ կլաստերին ասելը, որ դրա վրա կան այսինչ առաջնային բեկորներ (այլ տվյալների մեջ կրկնօրինակի բեկորը խթանելու համար: կենտրոն սկզբնականում, և դրանց վրա կարելի էր գրել տեղեկատվության մեջ):

Հետևաբար, երբ ամեն ինչ արդեն մարել է, թողարկված տվյալների հանգույցները անմիջապես չեն նշվում որպես հնացած: Համապատասխանաբար, մենք ստիպված ենք սպասել, մինչև բոլոր ping-ները դուրս գան թողարկված տվյալների հանգույցներին, և միայն դրանից հետո մեր կլաստերը սկսում է մեզ ասել, որ ինչ-որ տեղ, այնտեղ և այնտեղ մենք պետք է շարունակենք տեղեկատվության գրանցումը: Այս մասին կարող եք կարդալ ավելին այստեղ.

Արդյունքում, տվյալների կենտրոնի դուրսբերման գործողությունն այսօր մեզ մոտ 5 րոպե տևում է պիկ ժամին: Նման մեծ ու անշնորհք կոլոսի համար սա բավականին լավ արդյունք է։

Արդյունքում եկանք հետևյալ որոշման.

• Մենք ունենք 360 տվյալների հանգույց՝ 700 գիգաբայթ սկավառակներով։
• 60 համակարգիչներ՝ այս նույն տվյալների հանգույցների միջոցով երթևեկության ուղղորդման համար:
• 40 վարպետներ, որոնք մենք թողել ենք որպես մի տեսակ ժառանգություն մինչև 6.4.0-ի տարբերակներից - տվյալների կենտրոնի դուրսբերումից հետո գոյատևելու համար մենք մտավոր պատրաստ էինք կորցնել մի քանի մեքենաներ, որպեսզի երաշխավորված լինենք վարպետների քվորում ունենալ նույնիսկ Հայաստանում: ամենավատ սցենարը
• Մեկ կոնտեյների վրա դերերը համատեղելու ցանկացած փորձ հանդիպեց նրանով, որ վաղ թե ուշ հանգույցը կկոտրվի ծանրաբեռնվածության տակ:
• Ամբողջ կլաստերը օգտագործում է 31 գիգաբայթանոց heap.size. չափը նվազեցնելու բոլոր փորձերը հանգեցրին նրան, որ կա՛մ սպանվեցին որոշ հանգույցներ ծանր որոնման հարցումներում՝ առաջատար նիշերով, կա՛մ ձեռք բերեցին անջատիչը հենց Elasticsearch-ում:
• Բացի այդ, որոնման կատարողականությունն ապահովելու համար մենք փորձեցինք հնարավորինս փոքր պահել կլաստերի օբյեկտների քանակը, որպեսզի հնարավորինս քիչ իրադարձություններ մշակենք այն խցանման մեջ, որը մենք ստացել ենք վարպետում:

Վերջապես մոնիտորինգի մասին

Ապահովելու համար, որ այս ամենը աշխատում է այնպես, ինչպես նախատեսված է, մենք վերահսկում ենք հետևյալը.

• Յուրաքանչյուր տվյալների հանգույց հաղորդում է մեր ամպին, որ այն գոյություն ունի, և դրա վրա կան այսինչ բեկորներ: Երբ ինչ-որ տեղ ինչ-որ բան մարում ենք, կլաստերը 2-3 վայրկյան հետո հայտնում է, որ A կենտրոնում մենք մարել ենք 2, 3 և 4 հանգույցները, սա նշանակում է, որ այլ տվյալների կենտրոններում մենք ոչ մի դեպքում չենք կարող մարել այն հանգույցները, որոնց վրա կա միայն մեկ բեկոր: ձախ.
• Իմանալով վարպետի վարքագծի բնույթը, մենք շատ ուշադիր նայում ենք առկախ առաջադրանքների քանակին: Քանի որ նույնիսկ մեկ խրված առաջադրանքը, եթե այն ժամանակին չի ավարտվում, տեսականորեն ինչ-որ արտակարգ իրավիճակում կարող է պատճառ դառնալ, որ, օրինակ, կրկնօրինակի բեկորի առաջմղումը առաջնայինում չաշխատի, ինչի պատճառով ինդեքսավորումը կդադարի աշխատել:
• Մենք նաև շատ ուշադիր ենք նայում աղբահանների ուշացումներին, քանի որ օպտիմալացման ժամանակ արդեն մեծ դժվարություններ ենք ունեցել դրա հետ կապված։
• Մերժում է թեմայով, որպեսզի նախապես հասկանա, թե որտեղ է շիշը:
• Դե, ստանդարտ չափումներ, ինչպիսիք են կույտը, RAM-ը և I/O-ն:

Մոնիտորինգ կառուցելիս պետք է հաշվի առնել Thread Pool-ի առանձնահատկությունները Elasticsearch-ում: Elasticsearch Փաստաթղթեր նկարագրում է կազմաձևման ընտրանքները և լռելյայն արժեքները որոնման և ինդեքսավորման համար, բայց ամբողջովին լռում է thread_pool.management-ի մասին: Այս շղթաները մշակում են, մասնավորապես, _cat/shards և այլ նմանատիպ հարցումներ, որոնք հարմար են օգտագործել մոնիտորինգ գրելիս: Որքան մեծ է կլաստերը, այնքան ավելի շատ նման հարցումներ են կատարվում մեկ միավորի համար, և վերոհիշյալ thread_pool.management-ը ոչ միայն ներկայացված չէ պաշտոնական փաստաթղթերում, այլ նաև լռելյայն սահմանափակվում է 5 թեմայով, որը շատ արագ հեռացվում է, հետո: որի մոնիտորինգը դադարում է ճիշտ աշխատել:

Եզրափակելով այն, ինչ ուզում եմ ասել. մենք դա արեցինք: Մենք կարողացանք մեր ծրագրավորողներին և ծրագրավորողներին տալ մի գործիք, որը գրեթե ցանկացած իրավիճակում կարող է արագ և հուսալի տեղեկատվություն տրամադրել արտադրության մեջ տեղի ունեցողի մասին:

Այո, պարզվեց, որ բավականին բարդ էր, բայց, այնուամենայնիվ, մեզ հաջողվեց մեր ցանկությունները տեղավորել առկա ապրանքների մեջ, որոնք մենք ստիպված չէինք կարկատել և վերաշարադրել մեզ համար:

Source: www.habr.com