Көптеген адамдар Elasticsearch-пен күреседі. Бірақ оны журналдарды «ерекше үлкен көлемде» сақтау үшін пайдаланғыңыз келгенде не болады? Сондай-ақ бірнеше деректер орталықтарының кез келгенінің сәтсіздігін сезіну ауыртпалықсыз ба? Қандай сәулет жасау керек және қандай тұзақтарға тап боласыз?
Біз Одноклассники-де журналдарды басқару мәселесін шешу үшін elasticsearch-ті пайдалануды шештік, енді біз Хабрмен тәжірибемізбен бөлісеміз: сәулет туралы да, тұзақтар туралы да.
Мен Петр Зайцевпін, Одноклассники сайтында жүйелік әкімші болып жұмыс істеймін. Бұған дейін мен әкімші болдым, Manticore Search, Sphinx Search, Elasticsearch қызметтерімен жұмыс істедім. Мүмкін, егер басқа іздеу пайда болса, мен онымен де жұмыс істейтін шығармын. Мен сондай-ақ көптеген ашық бастапқы жобаларға ерікті түрде қатысамын.
Одноклассникиге келгенімде мен сұхбатта Elasticsearch-пен жұмыс істей алатынымды абайсызда айттым. Мен оны меңгеріп, қарапайым тапсырмаларды орындағаннан кейін маған сол кездегі журналдарды басқару жүйесін реформалау бойынша үлкен тапсырма берілді.
талаптар
Жүйе талаптары келесідей тұжырымдалған:
- Фронт ретінде Graylog қолданылуы керек еді. Компанияның бұл өнімді пайдалану тәжірибесі болғандықтан, бағдарламашылар мен тестерлер оны білетін, олар үшін бұл таныс және ыңғайлы болды.
- Деректер көлемі: орта есеппен секундына 50-80 мың хабарлама, бірақ бірдеңе бұзылса, трафик ештеңемен шектелмейді, секундына 2-3 миллион жолды құрауы мүмкін.
- Тұтынушылармен іздеу сұрауларын өңдеу жылдамдығына қойылатын талаптарды талқылай отырып, біз мұндай жүйені пайдаланудың әдеттегі үлгісі мынада екенін түсіндік: адамдар соңғы екі күнде өз өтініштерінің журналдарын іздейді және бір күннен артық күтуді қаламайды. екінші – тұжырымдалған сұрау нәтижесі үшін.
- Әкімшілер жүйені қажет болған жағдайда оның қалай жұмыс істейтінін терең зерделеуді талап етпей, оңай масштабтауға болатынын талап етті.
- Осылайша, бұл жүйелер мерзімді түрде талап ететін жалғыз техникалық қызмет көрсету міндеті кейбір аппараттық құралдарды өзгерту болып табылады.
- Сонымен қатар, Одноклассники-де тамаша техникалық дәстүр бар: біз іске қосатын кез келген қызмет деректер орталығының істен шығуына (кенеттен, жоспардан тыс және кез келген уақытта) аман қалуы керек.
Бұл жобаны жүзеге асырудағы соңғы талап бізге ең қымбатқа түсті, мен бұл туралы толығырақ айтып беремін.
Сәрсенбі
Біз төрт деректер орталығында жұмыс істейміз, ал Elasticsearch деректер түйіндері тек үшеуінде орналаса алады (бірқатар техникалық емес себептерге байланысты).
Бұл төрт деректер орталықтарында шамамен 18 мың түрлі журнал көздері бар - аппараттық құралдар, контейнерлер, виртуалды машиналар.
Маңызды мүмкіндік: кластер контейнерлерде басталады физикалық машиналарда емес, бірақ . Контейнерлерге 2 ГГц v2.0-ке ұқсас 4 ядроға кепілдік беріледі, егер олар бос болса, қалған ядроларды қайта өңдеу мүмкіндігі бар.
Басқа сөздермен айтқанда:
Топология
Мен бастапқыда шешімнің жалпы формасын келесідей көрдім:
- Graylog доменінің A-жазбасының артында 3-4 VIP бар, бұл журналдар жіберілетін мекенжай.
- әрбір VIP LVS теңгерімшісі болып табылады.
- Одан кейін журналдар Graylog батареясына өтеді, кейбір деректер GELF пішімінде, кейбіреулері syslog пішімінде.
- Содан кейін мұның бәрі Elasticsearch координаторларының батареясына үлкен партиялармен жазылады.
- Және олар, өз кезегінде, сәйкес деректер түйіндеріне жазу және оқу сұрауларын жібереді.
Терминология
Терминологияны әркім жан-жақты түсінбейтін шығар, сондықтан мен оған аздап тоқталғым келеді.
Elasticsearch-те түйіндердің бірнеше түрі бар – мастер, координатор, деректер түйіні. Әртүрлі журнал түрлендірулері мен әртүрлі кластерлер арасындағы байланыстың басқа екі түрі бар, бірақ біз тек тізімделгендерін қолдандық.
Master
Ол кластерде бар барлық түйіндерді тексереді, жаңартылған кластер картасын жүргізеді және оны түйіндер арасында таратады, оқиғалар логикасын өңдейді және кластер кеңістігіндегі үй шаруашылығының әртүрлі түрлерін орындайды.
үйлестірушісі
Бір ғана тапсырманы орындайды: клиенттерден оқу немесе жазу сұрауларын қабылдайды және осы трафикті бағыттайды. Жазу сұрауы болған жағдайда, ол шеберден тиісті индекстің қай бөлігін қою керектігін сұрайды және сұрауды әрі қарай бағыттайды.
Деректер түйіні
Деректерді сақтайды, сырттан келетін іздеу сұрауларын орындайды және онда орналасқан үзінділермен операцияларды орындайды.
Грейлог
Бұл ELK стекіндегі Кибана мен Logstash біріктіруі сияқты нәрсе. Graylog пайдаланушы интерфейсін де, журналды өңдеу құбырын да біріктіреді. Сорғыштың астында Graylog кластер ретінде Graylog қосылымын қамтамасыз ететін Кафка және Zookeeper бағдарламаларын басқарады. Elasticsearch қолжетімсіз болған жағдайда Graylog журналдарды кэштей алады (Кафка) және сәтсіз оқу және жазу сұрауларын қайталайды, белгіленген ережелерге сәйкес журналдарды топтастыру және белгілеу. Logstash сияқты Graylog-те жолдарды Elasticsearch-ке жазбас бұрын өзгерту мүмкіндігі бар.
Сонымен қатар, Graylog бір қолжетімді Elasticsearch түйініне негізделген бүкіл кластер картасын алуға және оны белгілі бір тег бойынша сүзуге мүмкіндік беретін кірістірілген қызметті ашады, бұл сұрауларды нақты контейнерлерге бағыттауға мүмкіндік береді.
Көрнекі түрде ол келесідей көрінеді:
Бұл белгілі бір дананың скриншоты. Мұнда біз іздеу сұрауына негізделген гистограмма құрастырамыз және сәйкес жолдарды көрсетеміз.
Көрсеткіштер
Жүйе архитектурасына қайта оралсақ, мен бәрі дұрыс жұмыс істеуі үшін индекс үлгісін қалай құрастырғанымызға толығырақ тоқталғым келеді.
Жоғарыдағы диаграммада бұл ең төменгі деңгей: Elasticsearch деректер түйіндері.
Индекс - Elasticsearch бөліктерінен тұратын үлкен виртуалды нысан. Өздігінен, сынықтардың әрқайсысы Люцен индексінен басқа ештеңе емес. Және әрбір Lucene индексі, өз кезегінде, бір немесе бірнеше сегменттерден тұрады.
Жобалау кезінде біз деректердің үлкен көлемін оқу жылдамдығына қойылатын талаптарды қанағаттандыру үшін бұл деректерді деректер түйіндері бойынша біркелкі «тарату» керектігін түсіндік.
Бұл индекске арналған үзінділер саны (көшірмелері бар) деректер түйіндерінің санына қатаң түрде тең болуы керек екеніне әкелді. Біріншіден, екіге тең репликация коэффициентін қамтамасыз ету үшін (яғни кластердің жартысын жоғалтуымыз мүмкін). Екіншіден, кластердің кем дегенде жартысында оқу және жазу сұраныстарын өңдеу үшін.
Біз алдымен сақтау мерзімін 30 күн деп анықтадық.
Бөлшектердің таралуын графикалық түрде келесідей көрсетуге болады:
Бүкіл қара сұр тіктөртбұрыш индекс болып табылады. Ондағы сол жақ қызыл шаршы - негізгі сынық, индекстегі бірінші. Ал көк шаршы – көшірме сынық. Олар әртүрлі деректер орталықтарында орналасқан.
Біз басқа үзіндіні қосқанда, ол үшінші деректер орталығына өтеді. Ақыр соңында, біз деректердің үйлесімділігін жоғалтпай тұрақты ток жоғалтуға мүмкіндік беретін осы құрылымды аламыз:
Индекстердің айналуы, яғни. жаңа индексті құру және ең ескісін жою, біз оны 48 сағатқа тең еттік (индексті пайдалану үлгісіне сәйкес: соңғы 48 сағат жиі ізделеді).
Бұл индекстің айналу аралығы келесі себептерге байланысты:
Іздеу сұрауы белгілі бір деректер түйініне келгенде, өнімділік тұрғысынан, егер оның өлшемі түйіннің жамбас өлшемімен салыстырылатын болса, бір үзінді сұралғанда тиімдірек болады. Бұл индекстің «ыстық» бөлігін үймеде сақтауға және оған жылдам қол жеткізуге мүмкіндік береді. «Ыстық бөліктер» көп болғанда, индексті іздеу жылдамдығы төмендейді.
Түйін бір үзіндіде іздеу сұрауын орындауды бастағанда, ол физикалық машинаның гиперағынды ядроларының санына тең ағындар санын бөледі. Егер іздеу сұрауы кесінділердің үлкен санына әсер етсе, онда ағындар саны пропорционалды түрде өседі. Бұл іздеу жылдамдығына теріс әсер етеді және жаңа деректерді индекстеуге теріс әсер етеді.
Қажетті іздеу кідірісін қамтамасыз ету үшін біз SSD пайдалануды шештік. Сұрауларды жылдам өңдеу үшін осы контейнерлерді орналастыратын машиналарда кемінде 56 ядро болуы керек. 56 саны жұмыс кезінде Elasticsearch жасайтын ағындардың санын анықтайтын шартты жеткілікті мән ретінде таңдалды. Elasitcsearch-те көптеген жіп пулының параметрлері қол жетімді ядролардың санына тікелей байланысты, бұл өз кезегінде «аз ядролар - көп түйіндер» принципіне сәйкес кластердегі түйіндердің қажетті санына тікелей әсер етеді.
Нәтижесінде біз сынықтардың орташа салмағы шамамен 20 гигабайт болатынын және бір индексте 1 фрагмент бар екенін анықтадық. Тиісінше, егер біз оларды 360 сағатта бір рет айналдырсақ, онда бізде олардың 48-і бар. Әрбір индекс 15 күндік деректерді қамтиды.
Мәліметтерді жазу және оқу схемалары
Бұл жүйеде деректер қалай жазылатынын анықтайық.
Грейлогтан үйлестірушіге сұраныс келді делік. Мысалы, біз 2-3 мың жолды индекстегіміз келеді.
Грейлогтан сұраныс алған үйлестіруші шеберге сұрақ қояды: «Индекстеу сұрауында біз индексті арнайы көрсеттік, бірақ оны қай бөлікке жазу керектігі көрсетілмеді».
Шебер жауап береді: «Бұл ақпаратты 71-бөлшек нөміріне жазыңыз», содан кейін ол тікелей 71-ші шарт нөмірі орналасқан тиісті деректер түйініне жіберіледі.
Одан кейін транзакция журналы басқа деректер орталығында орналасқан реплика-шардқа көшіріледі.
Грейлогтан координаторға іздеу сұрауы келеді. Үйлестіруші оны индекске сәйкес қайта бағыттайды, ал Elasticsearch сұрауларды бастапқы және реплика-shard арасында round-robin принципін пайдалана отырып таратады.
180 түйін біркелкі емес жауап береді және олар жауап беріп жатқанда, үйлестіруші жылдамырақ деректер түйіндері арқылы «түкірген» ақпаратты жинақтайды. Осыдан кейін, барлық ақпарат келгенде немесе сұрау күту уақытына жеткенде, ол барлығын тікелей клиентке береді.
Бұл бүкіл жүйе орта есеппен соңғы 48 сағат ішінде іздеу сұрауларын 300-400 мс аралығында өңдейді, алдыңғы қойылмалы таңбалы сұрауларды қоспағанда.
Elasticsearch көмегімен гүлдер: Java орнату
Барлығы өзіміз қалағандай жұмыс істеуі үшін біз кластердегі көптеген нәрселерді жөндеуге өте ұзақ уақыт жұмсадық.
Табылған мәселелердің бірінші бөлігі Java-ны Elasticsearch жүйесінде әдепкі бойынша алдын ала конфигурациялау әдісіне қатысты болды.
Бір мәселе
Біз Lucene деңгейінде фондық тапсырмалар орындалып жатқанда, Lucene сегментін біріктіру қатемен орындалмайтыны туралы есептердің өте көп санын көрдік. Сонымен қатар, журналдарда бұл OutOfMemoryError қатесі екені анық болды. Біз телеметриядан жамбастың бос екенін көрдік, бұл операцияның неліктен сәтсіз болғаны белгісіз.
Люцен индексінің біріктірілуі жамбастың сыртында болатыны анықталды. Ал контейнерлер тұтынылатын ресурстар тұрғысынан айтарлықтай шектеулі. Бұл ресурстарға тек үйме сыйды (heap.size мәні шамамен ЖЖҚ-ға тең болды) және кейбір үймеден тыс операциялар қандай да бір себептермен шектеуге дейін қалған ~500 МБ-қа сәйкес келмесе, жадты бөлу қателігімен бұзылды.
Түзету өте тривиальды болды: контейнерге арналған ЖЖҚ көлемі ұлғайтылды, содан кейін бізде мұндай проблемалар болғанын ұмытып кеттік.
Екінші мәселе
Кластер іске қосылғаннан кейін 4-5 күннен кейін деректер түйіндері мезгіл-мезгіл кластерден шығып, 10-20 секундтан кейін кіре бастағанын байқадық.
Біз оны анықтай бастағанда, Elasticsearch-тегі бұл үймеден тыс жад ешқандай жолмен басқарылмайтыны анықталды. Контейнерге көбірек жад бергенде, біз тікелей буферлік пулдарды әртүрлі ақпаратпен толтыра алдық және ол Elasticsearch-тен нақты GC іске қосылғаннан кейін ғана тазартылды.
Кейбір жағдайларда бұл операция өте ұзақ уақытқа созылды және осы уақыт ішінде кластер бұл түйінді шығып кеткен деп белгілей алды. Бұл мәселе жақсы сипатталған .
Шешім келесідей болды: біз Java-ның осы операциялар үшін үймеден тыс жадтың негізгі бөлігін пайдалану мүмкіндігін шектедік. Біз оны 16 гигабайтпен (-XX:MaxDirectMemorySize=16г) шектедік, бұл анық GC әлдеқайда жиі шақырылатынын және әлдеқайда жылдам өңделуін қамтамасыз етеміз, осылайша кластерді тұрақсыздандырмайды.
Үшінші мәселе
Егер сіз «ең күтпеген сәтте кластерден шығатын түйіндер» проблемалары аяқталды деп ойласаңыз, қателесесіз.
Біз индекстермен жұмысты конфигурациялағанда, біз mmapfs таңдадық үлкен сегментациясы бар жаңа сынықтарда. Бұл өте өрескел қате болды, өйткені mmapfs пайдаланған кезде файл ЖЖҚ-ға салыстырылады, содан кейін біз салыстырылған файлмен жұмыс істейміз. Осыған байланысты, GC қолданбадағы ағындарды тоқтатуға тырысқанда, біз қауіпсіз нүктеге өте ұзақ уақыт барамыз және оған барар жолда қолданба оның тірі немесе жоқтығы туралы шебердің сұрауларына жауап беруді тоқтатады. . Сәйкесінше, шебер түйін енді кластерде жоқ деп есептейді. Осыдан кейін, 5-10 секундтан кейін қоқыс жинағыш жұмыс істейді, түйін өмірге келеді, кластерге қайтадан кіреді және сынықтарды инициализациялауды бастайды. Мұның бәрі «біз лайық болған өнімге» ұқсайды және маңызды ештеңеге сәйкес келмеді.
Бұл мінез-құлықтан құтылу үшін біз алдымен стандартты ниофтарға көштік, содан кейін біз Elastic-тің бесінші нұсқасынан алтыншы нұсқасына көшкен кезде гибридтерді қолданып көрдік, онда бұл мәселе қайталанбады. Сақтау түрлері туралы көбірек оқуға болады .
Төртінші мәселе
Содан кейін біз рекордтық уақыт ішінде емдейтін тағы бір өте қызықты мәселе болды. Біз оны 2-3 ай бойы ұстадық, өйткені оның үлгісі мүлдем түсініксіз болды.
Кейде біздің үйлестірушілеріміз әдетте түскі астан кейін толық GC-ге барды және ол жерден ешқашан оралмайды. Сонымен қатар, GC кідірісін тіркеу кезінде ол былай көрінді: бәрі жақсы, жақсы, жақсы, содан кейін кенеттен бәрі өте нашар.
Басында бізде координаторды жұмыс режимінен шығаратын қандай да бір сұрауды іске қосатын зұлым пайдаланушы бар деп ойладық. Біз не болып жатқанын анықтауға тырысып, өте ұзақ уақыт бойы сұрауларды тіркедік.
Нәтижесінде, пайдаланушы үлкен сұранысты іске қосқан кезде және ол нақты Elasticsearch үйлестірушісіне жеткенде, кейбір түйіндер басқаларға қарағанда ұзағырақ жауап беретіні белгілі болды.
Ал үйлестіруші барлық түйіндерден жауап күтіп тұрғанда, ол жауап берген түйіндерден жіберілген нәтижелерді жинақтайды. GC үшін бұл біздің үйме пайдалану үлгілерінің өте тез өзгеретінін білдіреді. Ал біз пайдаланған МК бұл тапсырманы орындай алмады.
Бұл жағдайда кластердің әрекетін өзгерту үшін тапқан жалғыз түзету - JDK13 жүйесіне көшу және Shenandoah қоқыс жинағышын пайдалану. Бұл мәселені шешті, біздің координаторлар құлауды тоқтатты.
Мұнда Java-мен проблемалар аяқталды және өткізу қабілеттілігі мәселелері басталды.
Elasticsearch көмегімен «Жидектер»: өткізу қабілеті
Өткізу қабілетіне қатысты мәселелер біздің кластердің тұрақты жұмыс істейтінін білдіреді, бірақ индекстелген құжаттар санының шыңында және маневрлер кезінде өнімділік жеткіліксіз.
Кездескен бірінші симптом: өндірістегі кейбір «жарылыстар» кезінде, журналдардың өте көп саны кенеттен жасалған кезде, Graylog бағдарламасында es_rejected_execution индекстеу қатесі жиі жыпылықтай бастайды.
Бұл бір деректер түйініндегі thread_pool.write.queue бағдарламасының Elasticsearch индекстеу сұрауын өңдеуге және ақпаратты дискідегі фрагментке жүктеп салуға қабілетті болғанға дейін әдепкі бойынша тек 200 сұрауды кэштей алатындығына байланысты болды. Және ішінде Бұл параметр туралы өте аз айтылған. Тек ағындардың максималды саны және әдепкі өлшем көрсетілген.
Әрине, біз бұл мәнді бұрмалауға бардық және мынаны білдік: атап айтқанда, біздің орнатуымызда 300-ге дейін сұраулар өте жақсы кэштеледі, ал жоғары мән қайтадан толық GC-ге ұшатындығымен байланысты.
Бұған қоса, бұл бір сұрау ішінде келетін хабарлар топтамалары болғандықтан, Graylog жиі және шағын топтамалармен емес, үлкен партиялармен немесе пакет әлі аяқталмаса, 3 секунд сайын бір рет жазатындай етіп түзету қажет болды. Бұл жағдайда, Elasticsearch-те біз жазған ақпарат екі секундта емес, бес секундта (бұл бізге өте қолайлы) қол жетімді болады, бірақ үлкен жолды итеру үшін жасалуы керек қайталаулар саны. ақпарат жинағы азаяды.
Бұл, әсіресе, бір жерде бірдеңе бұзылып, ол туралы қатты хабарлаған кезде, толығымен спамға жіберілген Elastic алмас үшін және біраз уақыттан кейін - бітеліп қалған буферлерге байланысты жұмыс істемейтін Graylog түйіндері өте маңызды.
Сонымен қатар, бізде өндірісте дәл осындай жарылыстар болған кезде, біз бағдарламашылар мен тестерлерден шағымдар алдық: олар бұл журналдарға шынымен мұқтаж болған кезде, олар өте баяу берілді.
Олар оны анықтай бастады. Бір жағынан, іздеу сұраулары да, индекстеу сұраулары да бірдей физикалық машиналарда өңделетіні және қандай да бір жолмен белгілі бір кемшіліктер болатыны анық болды.
Бірақ мұны ішінара айналып өтуге болады, себебі Elasticsearch-тің алтыншы нұсқаларында сұрауларды кездейсоқ айналым принципіне (индекстеуді жүзеге асыратын және бастапқы деректерді сақтайтын контейнер) сәйкес деректер түйіндері арасында таратуға мүмкіндік беретін алгоритм пайда болды. shard өте бос болуы мүмкін, жылдам жауап беру мүмкіндігі болмайды), бірақ бұл сұрауды әлдеқайда жылдамырақ жауап беретін реплика-shard бар аз жүктелген контейнерге жіберу үшін. Басқаша айтқанда, біз use_adaptive_replica_selection: true дегенге келдік.
Оқу суреті келесідей бола бастайды:
Бұл алгоритмге көшу бізде жазу үшін журналдардың үлкен ағыны болған сәттерде сұрау уақытын айтарлықтай жақсартуға мүмкіндік берді.
Ақырында, негізгі мәселе деректер орталығын ауыртпалықсыз алып тастау болды.
Бір тұрақты токпен қосылымды жоғалтқаннан кейін кластерден бірден не қалайтынымыз:
- Егер бізде сәтсіз деректер орталығында ағымдағы шебер болса, онда ол қайта таңдалады және рөл ретінде басқа тұрақты токтағы басқа түйінге жылжытылады.
- Мастер кластерден барлық қол жетімсіз түйіндерді жылдам жояды.
- Қалғандарына сүйене отырып, ол түсінеді: жоғалған деректер орталығында бізде осындай және осындай негізгі бөлшектер болған, ол қалған деректер орталықтарында қосымша реплика бөліктерін жылдам жылжытады және біз деректерді индекстеуді жалғастырамыз.
- Нәтижесінде кластердің жазу және оқу қабілеті бірте-бірте нашарлайды, бірақ жалпы алғанда бәрі баяу болса да, тұрақты жұмыс істейді.
Белгілі болғандай, біз мынаны қалаймыз:
Және біз мынаны алдық:
Бұл қалай болды?
Дата-орталық құлаған кезде біздің шеберіміз тығырыққа тірелді.
Неге?
Мастерде кластердегі белгілі бір тапсырмалар мен оқиғаларды таратуға жауап беретін TaskBatcher бар. Кез келген түйіннен шығу, үзіндіні көшірмеден негізгіге дейін жылжыту, бір жерде сынық жасау үшін кез келген тапсырма - мұның бәрі алдымен TaskBatcher-ге өтеді, онда ол дәйекті түрде және бір ағында өңделеді.
Бір дата орталығын алып тастаған кезде, сақталған деректер орталықтарындағы барлық деректер түйіндері шеберге «біз анау-мынау сынықтарды және осындай деректер түйіндерін жоғалттық» деп хабарлауды өздерінің міндеті деп санайтыны белгілі болды.
Сонымен бірге, аман қалған деректер түйіндері осы ақпаратты ағымдағы шеберге жіберіп, оны қабылдағанын растауды күтуге тырысты. Олар мұны күтпеді, өйткені шебер тапсырмаларды жауап бергеннен тезірек алды. Түйіндер қайталанатын сұрауларды аяқтады, ал шебер бұл уақытта тіпті жауап беруге тырыспады, бірақ сұраныстарды басымдылық бойынша сұрыптау міндетіне толығымен кірісті.
Терминал түрінде деректер түйіндері шеберге спам жіберіп, ол толық GC-ге ауысатыны белгілі болды. Осыдан кейін біздің басты рөліміз келесі түйінге көшті, онымен бірдей нәрсе болды және нәтижесінде кластер толығымен құлады.
Біз өлшеулер жүргіздік және бұл реттелетін 6.4.0 нұсқасына дейін кластерді толығымен өшіру үшін бір уақытта 10-дан тек 360 деректер түйінін шығару жеткілікті болды.
Бұл келесідей көрінді:
Бұл қорқынышты қате түзетілген 6.4.0 нұсқасынан кейін деректер түйіндері шеберді өлтіруді тоқтатты. Бірақ бұл оны «ақылды» етпеді. Атап айтқанда: біз 2, 3 немесе 10 (бірден басқа кез келген сан) деректер түйіндерін шығарған кезде, шебер А түйінінің кеткені туралы алғашқы хабарламаны алады және бұл туралы В түйініне, С түйініне, D түйініне айтуға тырысады.
Қазіргі уақытта мұны біреуге бір нәрсе туралы айту әрекеттері үшін шамамен 20-30 секундқа тең күту уақытын орнату арқылы ғана шешуге болады, осылайша деректер орталығының кластерден шығу жылдамдығын басқаруға болады.
Негізінде бұл жобаның бөлігі ретінде түпкілікті өнімге ұсынылған талаптарға сәйкес келеді, бірақ «таза ғылым» тұрғысынан бұл қате. Айтпақшы, оны әзірлеушілер 7.2 нұсқасында сәтті бекітті.
Сонымен қатар, белгілі бір деректер түйіні сөнген кезде, оның шығуы туралы ақпаратты тарату бүкіл кластерге ондағы осындай және осындай бастапқы бөліктер бар екенін айтудан гөрі маңыздырақ болып шықты (басқа деректерде реплика-шардты жылжыту үшін). орталық бастауышта, ал ақпаратта оларда жазылуы мүмкін).
Сондықтан, бәрі біткен кезде, шығарылған деректер түйіндері бірден ескірген деп белгіленбейді. Тиісінше, біз барлық пингтер шығарылған деректер түйіндеріне уақыт біткенше күтуге мәжбүрміз, содан кейін ғана біздің кластер бізге сол жерде, сонда және сол жерде ақпаратты жазуды жалғастыру керек екенін айта бастайды. Бұл туралы толығырақ оқуға болады .
Нәтижесінде дата орталығын алып тастау операциясы бүгін қарбалас уақытта шамамен 5 минутты алады. Мұндай үлкен және ебедейсіз колоссус үшін бұл өте жақсы нәтиже.
Нәтижесінде біз келесі шешімге келдік:
- Бізде 360 гигабайт дискілері бар 700 деректер түйіндері бар.
- Осы деректер түйіндері арқылы трафикті бағыттауға арналған 60 үйлестіруші.
- 40-ге дейінгі нұсқалардан бері біз өзіміздің мұра ретінде қалдырған 6.4.0 шебер - деректер орталығының шығарылуынан аман қалу үшін біз тіпті шеберлердің кворумына кепілдік беру үшін бірнеше машинаны жоғалтуға ойша дайын болдық. ең нашар жағдай сценарийі
- Рөлдерді бір контейнерде біріктірудің кез келген әрекеті ерте ме, кеш пе түйіннің жүктеме кезінде үзілетіндігімен кездесті.
- Бүкіл кластер 31 гигабайт үйінді өлшемін пайдаланады: өлшемді азайту әрекеттерінің барлығы жетекші қойылмалы таңбамен ауыр іздеу сұрауларындағы кейбір түйіндерді жоюға немесе Elasticsearch ішіндегі автоматты ажыратқышты алуға әкелді.
- Сонымен қатар, іздеу өнімділігін қамтамасыз ету үшін біз шеберде қолымыздан келген қиыншылықта мүмкіндігінше аз оқиғаларды өңдеу үшін кластердегі нысандардың санын мүмкіндігінше аз ұстауға тырыстық.
Соңында мониторинг туралы
Мұның бәрі мақсатқа сай жұмыс істеуін қамтамасыз ету үшін біз мыналарды бақылаймыз:
- Әрбір деректер түйіні біздің бұлтқа оның бар екендігі туралы хабарлайды және ондағы осындай және осындай сынықтар бар. Біз бір жерде бір нәрсені сөндіргенде, кластер 2-3 секундтан кейін А орталығында біз 2, 3 және 4 түйіндерді сөндірдік деп хабарлайды - бұл басқа деректер орталықтарында біз ешбір жағдайда бір ғана сынық бар түйіндерді өшіре алмайтынымызды білдіреді. сол.
- Шебердің мінез-құлқының сипатын біле отырып, біз күтілетін тапсырмалардың санын мұқият қарастырамыз. Тіпті бір тоқтап қалған тапсырма, егер ол уақытында бітпесе, теориялық тұрғыдан кейбір төтенше жағдайда, мысалы, бастапқыда реплика сынығын жылжыту жұмыс істемеуі мүмкін, сондықтан индекстеу жұмысын тоқтатады.
- Біз сондай-ақ қоқыс жинаушының кідірістерін мұқият қарастырамыз, өйткені оңтайландыру кезінде біз бұған дейін үлкен қиындықтарға тап болдық.
- Тығынның қай жерде екенін алдын ала түсіну үшін жіп бойынша бас тартады.
- Үйме, жедел жад және енгізу/шығару сияқты стандартты көрсеткіштер.
Бақылауды құру кезінде Elasticsearch ішіндегі Thread Pool мүмкіндіктерін ескеру қажет. іздеу және индекстеу үшін конфигурация опциялары мен әдепкі мәндерін сипаттайды, бірақ thread_pool.management туралы мүлдем үнсіз.Бұл ағындар, атап айтқанда, _cat/shards сияқты сұрауларды және бақылауды жазу кезінде қолдануға ыңғайлы басқа ұқсас сұрауларды өңдейді. Кластер неғұрлым үлкен болса, уақыт бірлігінде соғұрлым мұндай сұраулар орындалады және жоғарыда аталған thread_pool.management ресми құжаттамада көрсетіліп қана қоймайды, сонымен қатар әдепкі бойынша 5 ағынмен шектеледі, олар кейін өте тез жойылады. қандай бақылау дұрыс жұмысын тоқтатады.
Қорытындылай келе мен айтқым келеді: біз мұны жасадық! Біз бағдарламашылар мен әзірлеушілерге кез келген жағдайда өндірісте не болып жатқаны туралы ақпаратты тез және сенімді түрде бере алатын құралды ұсына алдық.
Иә, бұл өте күрделі болды, бірақ соған қарамастан, біз өз тілектерімізді қолданыстағы өнімдерге сәйкестендіруге қол жеткіздік, оларды өзіміз үшін түзетуге және қайта жазуға тура келмеді.
Ақпарат көзі: www.habr.com