Көп адамдар 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 түйүндөрүнүн бир нече түрү бар - мастер, координатор, маалымат түйүнү. Ар кандай лог трансформацияларынын жана ар кандай кластерлердин ортосундагы байланыштын дагы эки түрү бар, бирок биз тизмеленгендерди гана колдондук.
кожоюн
Ал кластерде бар бардык түйүндөргө пинг жүргүзөт, заманбап кластер картасын жүргүзөт жана аны түйүндөрдүн ортосунда бөлүштүрөт, окуялардын логикасын иштетет жана кластердик кеңири үй иштеринин ар кандай түрлөрүн аткарат.
координатору
Бир эле тапшырманы аткарат: кардарлардын окуу же жазуу өтүнүчтөрүн кабыл алат жана бул трафикти багыттайт. Эгерде жазуу өтүнүчү бар болсо, ал кожоюндан аны тиешелүү индекстин кайсы бөлүгүнө киргизүүнү сурайт жана суроо-талапты андан ары багыттайт.
Маалымат түйүнү
Маалыматтарды сактайт, сырттан келген издөө сурамдарын аткарат жана анда жайгашкан сыныктар боюнча операцияларды аткарат.
graylog
Бул ELK стекиндеги Кибана менен Logstash менен биригүү сыяктуу нерсе. Graylog UI менен журналды иштетүү түтүгүн бириктирет. Капоттун астында Graylog Kafka жана Zookeeper иштетет, алар Graylog менен кластер катары байланышты камсыз кылат. Elasticsearch жеткиликсиз болгон учурда Graylog журналдарды кэштейт (Кафка) жана ийгиликсиз окуу жана жазуу өтүнүчтөрүн кайталап, журналдарды белгиленген эрежелерге ылайык топтоп жана белгилей алат. Logstash сыяктуу Graylog да Elasticsearch'ке жазуудан мурун саптарды өзгөртүү мүмкүнчүлүгүнө ээ.
Кошумчалай кетсек, Graylog бир жеткиликтүү Elasticsearch түйүнүнүн негизинде бүт кластер картасын алууга жана аны белгилүү бир тег менен чыпкалоого мүмкүндүк берген орнотулган кызмат ачылышына ээ, бул суроо-талаптарды белгилүү бир контейнерлерге багыттоого мүмкүндүк берет.
Визуалдык түрдө бул төмөнкүдөй көрүнөт:
Бул белгилүү бир инстанциянын скриншоту. Бул жерде биз издөө сурамынын негизинде гистограмма курабыз жана тиешелүү саптарды көрсөтөбүз.
көрсөткүчтөрү
Системанын архитектурасына кайрылып, мен индекс моделин кантип курганыбызга кененирээк токтолгум келет, ошонун баары туура иштеши үчүн.
Жогорудагы диаграммада бул эң төмөнкү деңгээл: Elasticsearch маалымат түйүндөрү.
Индекс - бул Elasticsearch сыныктарынан турган чоң виртуалдык объект. Өз алдынча, сыныктардын ар бири Lucene индексинен башка эч нерсе эмес. Ал эми ар бир Lucene индекси, өз кезегинде, бир же бир нече сегменттерден турат.
Долбоорлоодо биз чоң көлөмдөгү маалыматтардын окуу ылдамдыгы талабын канааттандыруу үчүн бул маалыматтарды маалымат түйүндөрүнө бирдей "жайышыбыз" керек деп ойлодук.
Бул индекстин сыныктарынын саны (репликалар менен) маалымат түйүндөрүнүн санына так болушу керек экендигине алып келди. Биринчиден, экиге барабар репликация факторун камсыз кылуу үчүн (башкача айтканда, биз кластердин жарымын жоготуп алабыз). Экинчиден, кластердин жок дегенде жарымында окуу жана жазуу сурамдарын иштеп чыгуу үчүн.
Алгач сактоо мөөнөтүн 30 күн деп аныктадык.
Бөлүштүрүүнү графикалык түрдө төмөнкүчө чагылдырууга болот:
Бүтүндөй кочкул боз тик бурчтук индекс болуп саналат. Андагы сол кызыл чарчы негизги сынык, индекстин биринчиси. Ал эми көк чарчы реплика сынык. Алар ар кандай маалымат борборлорунда жайгашкан.
Биз дагы бир сынык кошкондо, ал үчүнчү маалымат борборуна барат. Акыр-аягы, биз маалымат ырааттуулугун жоготпостон DC жоготууга мүмкүндүк берген бул структураны алабыз:
Индекстердин айлануусу, б.а. жаңы индексти түзүү жана эң эскисин жок кылуу менен, биз аны 48 саатка барабар кылдык (индексти колдонуу үлгүсүнө ылайык: эң көп изделген акыркы 48 саат).
Бул индекстин айлануу аралыгы төмөнкү себептерге байланыштуу:
Издөө өтүнүчү белгилүү бир маалымат түйүнүнө келгенде, аткаруу жагынан алганда, бир сынык суралганда, анын өлчөмү түйүнүн жамбашынын өлчөмү менен салыштырылган болсо, пайдалуураак болот. Бул индекстин "ысык" бөлүгүн үймөктө сактоого жана ага тез жетүүгө мүмкүндүк берет. "Ысык бөлүктөр" көп болгондо, индексти издөө ылдамдыгы төмөндөйт.
Түйүн бир сыныкта издөө сурамын аткара баштаганда, ал физикалык машинанын гипертрейдинг өзөктөрүнүн санына барабар бир катар жиптерди бөлүп берет. Эгерде издөө суроосу көп сандагы сыныктарга таасир этсе, анда жиптердин саны пропорционалдуу өсөт. Бул издөө ылдамдыгына терс таасирин тийгизет жана жаңы маалыматтарды индексациялоого терс таасирин тийгизет.
Керектүү издөө күтүү убактысын камсыз кылуу үчүн, биз SSD колдонууну чечтик. Сурамдарды тез иштетүү үчүн, бул контейнерлерди жайгаштырган машиналарда кеминде 56 өзөк болушу керек болчу. 56 цифрасы шарттуу жетиштүү маани катары тандалган, ал Elasticsearch операция учурунда түзө турган жиптердин санын аныктайт. Elasitcsearch'те жип пулунун көптөгөн параметрлери түздөн-түз жеткиликтүү өзөктөрдүн санына көз каранды, бул өз кезегинде "азыраак өзөк - көбүрөөк түйүн" принцибине ылайык кластердеги түйүндөрдүн керектүү санына түздөн-түз таасирин тийгизет.
Натыйжада, биз орто эсеп менен бир сынык болжол менен 20 гигабайт салмакта экенин аныктадык жана индексте 1 сынык бар. Ошого жараша аларды 360 саатта бир жолу айлантсак, анда бизде алардын 48и бар. Ар бир индекс 15 күндүк маалыматтарды камтыйт.
Маалыматтарды жазуу жана окуу схемалары
Келгиле, бул системада маалыматтар кантип жазылганын карап көрөлү.
Грейлогдон координаторго кандайдыр бир өтүнүч келди дейли. Мисалы, биз 2-3 миң катар индекстештирүүнү каалайбыз.
Координатор Грейлогдон суроо-талапты алып, мастерге суроо салат: "Индекстөө өтүнүчүндө биз индексти атайын көрсөткөнбүз, бирок аны кайсы сыныкта жазуу керектиги көрсөтүлгөн эмес".
Мастер мындай деп жооп берет: "Бул маалыматты 71 номерлүү бөлүккө жазыңыз", андан кийин ал түздөн-түз тиешелүү маалымат түйүнүнө жөнөтүлөт.
Андан кийин транзакциялар журналы башка маалымат борборунда жайгашкан реплика-shardга көчүрүлөт.
Грейлогдон координаторго издөө өтүнүчү келет. Координатор аны индекске ылайык багыттайт, ал эми Elasticsearch сурамдарды тегерек-робин принцибинин жардамы менен баштапкы жана реплика-shard ортосунда бөлүштүрөт.
180 түйүн бирдей эмес жооп берет жана алар жооп берип жатып, координатор тезирээк маалымат түйүндөрү тарабынан буга чейин "түкүрүлгөн" маалыматты топтоп жатат. Андан кийин, же бардык маалымат келгенде, же суроо-талап күтүү мөөнөтүнө жеткенде, ал бардыгын түздөн-түз кардарга берет.
Бул бүтүндөй система орточо эсеп менен акыркы 48 сааттын ичинде издөө сурамдарын 300-400 мс аралыгында иштетет.
Elasticsearch менен гүлдөр: Java орнотуу
Баары биз каалагандай иштеш үчүн, биз кластердеги көп түрдүү нерселерди оңдоого көп убакыт жумшадык.
Табылган көйгөйлөрдүн биринчи бөлүгү Java Elasticsearchте демейки боюнча алдын ала конфигурацияланган жол менен байланышкан.
Бир көйгөй
Биз Люсен деңгээлинде фондо жумуштар иштеп жатканда, Lucene сегментинин биригүүлөрү ката менен ишке ашпай калгандыгы тууралуу өтө көп сандагы отчетторду көрдүк. Ошол эле учурда, бул OutOfMemoryError катасы экени журналдарда айкын болгон. Биз телеметриядан жамбаштын бош экенин көрдүк, эмне үчүн бул операция ийгиликсиз болуп жатканы белгисиз.
Люсен индексинин биригиши жамбаштын сыртында экени белгилүү болду. Ал эми контейнерлер керектелген ресурстар жагынан абдан катуу чектелген. Бул ресурстарга үймөк гана туура келе алган (heap.size мааниси болжол менен RAMга барабар болгон) жана кээ бир үймөктөн сырткары операциялар кандайдыр бир себептерден улам чектөөгө чейин калган ~500МБга туура келбесе, эстутум бөлүштүрүү катасы менен кыйрады.
Түзөтүү анча маанилүү эмес болчу: контейнер үчүн RAM көлөмү көбөйдү, андан кийин бизде мындай көйгөйлөр бар экенин унутуп койдук.
Экинчи маселе
Кластер ишке киргизилгенден 4-5 күндөн кийин биз маалымат түйүндөрү мезгил-мезгили менен кластерден чыгып, 10-20 секунддан кийин кире баштаганын байкадык.
Биз аны түшүнө баштаганда, Elasticsearchдеги бул үймөктөн сырткары эстутум эч кандай башкарылбайт экен. Контейнерге көбүрөөк эстутум бергенде, биз түз буфердик бассейндерди ар кандай маалымат менен толтура алдык жана ал Elasticsearchтен ачык GC ишке киргизилгенден кийин гана тазаланды.
Кээ бир учурларда, бул операция бир топ убакытты талап кылды жана бул убакыттын ичинде кластер бул түйүндү мурунтан эле чыгып кеткен деп белгилөөгө жетишти. Бул көйгөй жакшы сүрөттөлгөн .
Чечим төмөнкүдөй болду: биз Java-нын бул операциялар үчүн үймөктүн сыртында эстутумдун негизги бөлүгүн колдонуу мүмкүнчүлүгүн чектедик. Биз аны 16 гигабайт менен чектедик (-XX:MaxDirectMemorySize=16g), ачык GC тез-тез чакырылып, тезирээк иштетилип, ошону менен кластерди дестабилдештирбейбиз.
Үчүнчү маселе
Эгерде сиз “кластерден күтүлбөгөн учурда чыгып кеткен түйүндөр” көйгөйлөрү бүттү деп ойлосоңуз, жаңылып жатасыз.
Ишти индекстер менен конфигурациялаганда, биз mmapfs тандадык улуу сегментация менен жаңы сыныктар боюнча. Бул абдан ката болду, анткени mmapfs колдонууда файл RAMга түшүрүлөт, анан биз карталанган файл менен иштейбиз. Ушундан улам, GC тиркемедеги жиптерди токтотууга аракет кылганда, биз коопсуз пунктка көпкө барабыз жана ага бара жатып, колдонмо анын тирүү же жокпу деген кожоюндун суроо-талабына жооп бербей калат. . Демек, мастер түйүн кластерде мындан ары жок деп эсептейт. Андан кийин, 5-10 секунддан кийин таштанды жыйноочу иштейт, түйүн жанданып, кайрадан кластерге кирип, сыныктарды инициализациялай баштайт. Мунун баары "биз татыктуу болгон өндүрүшкө" окшош жана олуттуу эч нерсеге ылайыктуу эмес болчу.
Бул жүрүм-турумдан арылуу үчүн биз адегенде стандарттуу niofs'го өттүк, анан биз Elasticтин бешинчи версиясынан алтынчы версиясына көчкөндө гибриддерди сынап көрдүк, анда бул көйгөй кайталанбай калган. Сиз сактоо түрлөрү жөнүндө көбүрөөк окуй аласыз .
Маселе төрт
Андан кийин дагы бир абдан кызыктуу маселе болду, аны биз рекорддук убакытка чейин дарыладык. Биз аны 2-3 ай кармадык, анткени анын үлгүсү таптакыр түшүнүксүз болчу.
Кээде биздин координаторлор, адатта, түшкү тамактан кийин, Full GCге барып, ал жактан эч качан кайтып келишкен эмес. Ошол эле учурда, GC кечигүү журналында, ал мындай көрүндү: баары жакшы болуп жатат, жакшы, жакшы, анан күтүлбөгөн жерден баары абдан начар болуп жатат.
Адегенде бизде координаторду жумуш режиминен чыгарып салган кандайдыр бир өтүнүчтү ишке киргизген жаман колдонуучу бар деп ойлодук. Биз эмне болуп жатканын түшүнүүгө аракет кылып, көп убакыт бою сурамдарды каттадык.
Натыйжада, колдонуучу чоң суроо-талапты ишке киргизген учурда жана ал белгилүү бир Elasticsearch координаторуна жеткенде, кээ бир түйүндөр башкаларга караганда узагыраак жооп берери белгилүү болду.
Ал эми координатор бардык түйүндөрдөн жооп күтүп жатканда, буга чейин жооп берген түйүндөрдөн жөнөтүлгөн жыйынтыктарды топтойт. GC үчүн бул биздин үймөктү колдонуу үлгүлөрүбүз абдан тез өзгөрөт дегенди билдирет. Ал эми биз колдонгон ГК бул милдетти аткара алган жок.
Бул кырдаалда кластердин жүрүм-турумун өзгөртүү үчүн биз тапкан жападан жалгыз оңдоп-түзөө бул JDK13кө көчүү жана Shenandoah таштанды жыйгычын колдонуу. Муну менен көйгөй чечилди, биздин координаторлор түшпөй калышты.
Бул жерде Java менен көйгөйлөр аяктады жана өткөрүү жөндөмдүүлүгү көйгөйлөрү башталды.
Elasticsearch менен "мөмөлөр": өткөрүү жөндөмдүүлүгү
Өткөрүү жөндөмдүүлүгүнүн көйгөйлөрү биздин кластердин туруктуу иштеп жатканын билдирет, бирок индекстелген документтердин эң жогорку чегинде жана маневрлер учурунда аткаруу жетишсиз.
Биринчи жолуккан симптом: өндүрүштөгү кээ бир "жарылуулар" учурунда, күтүлбөгөн жерден өтө көп сандагы журналдар пайда болгондо, Graylog'до es_rejected_execution индекстөө катасы бат-баттан жарк эте баштайт.
Бул бир маалымат түйүнүндөгү thread_pool.write.queue, Elasticsearch индекстөө өтүнүчүн иштеп чыгууга жана маалыматты дисктеги сыныкка жүктөй алганга чейин, демейки боюнча 200 гана сурамды кэштей ала тургандыгы менен шартталган. Жана в Бул параметр жөнүндө абдан аз айтылат. Жиптердин максималдуу саны жана демейки өлчөмү гана көрсөтүлгөн.
Албетте, биз бул маанини бурмалоого барып, төмөнкүлөрдү билдик: тагыраак айтканда, биздин орнотууда 300гө чейин суроо-талап жакшы кэштелген, ал эми жогорураак маани, биз кайрадан Full GCге учуп жатканыбызга байланыштуу.
Кошумчалай кетсек, булар бир суроонун ичинде келген билдирүүлөрдүн партиялары болгондуктан, Graylog тез-тез жана майда партиялар менен эмес, чоң партиялар менен же партия дагы эле толук эмес болсо, 3 секундада бир жолу жаза тургандай кылып өзгөртүү керек болчу. Бул учурда, биз Elasticsearchте жазган маалымат эки секундда эмес, бештен кийин (бул бизге абдан ылайыктуу) жеткиликтүү болуп калат, бирок чоң көлөмдөн өтүү үчүн жасалышы керек болгон рейкалардын саны. маалымат топтому кыскарган.
Бул толугу менен спамдалган Elastic жана бир нече убакыт өткөндөн кийин - буферлердин бүтөлгөндүгүнө байланыштуу иштебей калган Graylog түйүндөрүн албоо үчүн, бир нерсе кулап түшкөн жана ал жөнүндө катуу кабарланган учурларда өзгөчө маанилүү.
Мындан тышкары, биз өндүрүштө ушул эле жарылуулар болгондо, биз программисттерден жана тестерлерден даттанууларды алдык: алар бул журналдарга чындап муктаж болгон учурда, аларга өтө жай берилди.
Алар муну түшүнө башташты. Бир жагынан алганда, издөө сурамдары да, индекстөө сурамдары да, негизинен, бир эле физикалык машиналарда иштетилгени жана тигил же бул жол менен белгилүү бир азаюулар болору айкын болгон.
Бирок, Elasticsearchтин алтынчы версияларында кокустук тегерек-робин принцибине ылайык эмес (индекстештирүүнү жүргүзгөн контейнер) тиешелүү маалымат түйүндөрүнүн ортосунда сурамдарды бөлүштүрүүгө мүмкүндүк берген алгоритм пайда болгондугуна байланыштуу муну жарым-жартылай айланып өтүүгө болот. shard абдан бош болушу мүмкүн, тез жооп берүүгө эч кандай жол жок), бирок бул сурамды реплика-shard менен азыраак жүктөлгөн контейнерге жөнөтүү үчүн, ал тезирээк жооп берет. Башкача айтканда, биз use_adaptive_replica_selection: чындыкка келдик.
Окуу сүрөтү мындай боло баштайт:
Бул алгоритмге өтүү бизде жазуулардын көп агымы болгон учурда суроо убактысын бир топ жакшыртууга мүмкүндүк берди.
Акыр-аягы, негизги көйгөй маалымат борборунун оорутпай алып салуу болду.
Бир DC менен байланышты үзгөндөн кийин дароо кластерден эмнени кааладык:
- Эгерде бизде иштебей калган маалымат борборунда учурдагы мастер болсо, анда ал кайра тандалып, башка DCдеги башка түйүнгө рол катары жылдырылат.
- Мастер кластерден бардык жеткиликсиз түйүндөрдү тез эле алып салат.
- Калгандарынын негизинде ал түшүнөт: жоголгон маалымат борборунда бизде ушундай жана ушундай негизги сыныктар болгон, ал тез арада калган маалымат борборлорунда толуктоочу реплика сыныктарын илгерилетет жана биз маалыматтарды индексациялоону улантабыз.
- Натыйжада, кластердин жазуу жана окуу жөндөмдүүлүгү акырындык менен начарлайт, бирок жалпысынан баары жай болсо да, туруктуу иштейт.
Көрсө, биз мындай нерсени кааладык:
Жана биз төмөнкүлөрдү алдык:
Бул кантип болду?
Дата борбору кулаганда, биздин агайыбыз кыйынчылыкка учурады.
Эмне үчүн?
Чындыгында, мастерде кластердеги белгилүү бир тапшырмаларды жана окуяларды бөлүштүрүү үчүн жооптуу 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 түйүндөрдү өчүргөнүбүздү билдирет - бул башка маалымат борборлорунда биз эч кандай шартта бир гана сынык бар түйүндөрдү өчүрө албайбыз дегенди билдирет. сол.
- Кожоюндун жүрүм-турумунун мүнөзүн билип, биз күтүп жаткан милдеттердин санын абдан кылдаттык менен карап чыгабыз. Анткени бир тыгылып калган тапшырма да, эгер ал өз убагында бүтпөсө, теориялык жактан кандайдыр бир өзгөчө кырдаалда, мисалы, реплика сыныктарын баштапкы деңгээлде жылдыруу иштебей калышынын себеби болуп калышы мүмкүн, ошондуктан индекстөө иштебей калат.
- Биз ошондой эле таштанды жыйноочулардын кечигүүсүн кылдаттык менен карап чыгабыз, анткени оптималдаштыруу учурунда биз буга чейин чоң кыйынчылыктарга туш болгонбуз.
- Бөгөттүн кайда экенин алдын ала түшүнүү үчүн жип менен четке кагат.
- Ооба, үймөк, RAM жана I/O сыяктуу стандарттуу көрсөткүчтөр.
Мониторингди курууда Elasticsearch ичиндеги Thread Pool өзгөчөлүктөрүн эске алышыңыз керек. издөө жана индекстөө үчүн конфигурация параметрлерин жана демейки маанилерди сүрөттөйт, бирок thread_pool.management жөнүндө такыр унчукпайт.Бул жиптер, атап айтканда, _cat/shards жана башка ушул сыяктуу суроолорду иштеп чыгат, алар мониторинг жазууда колдонууга ыңгайлуу. Кластер канчалык чоң болсо, убакыт бирдигине ошончолук көп суроо-талаптар аткарылат жана жогоруда айтылган thread_pool.management расмий документацияда гана көрсөтүлбөстөн, демейки боюнча 5 жип менен чектелет, ал өтө тез жок кылынат, кийин кайсы мониторинг туура иштебей калат.
Жыйынтыктап айтканда эмнени айткым келет: биз муну жасадык! Биз программисттерибизге жана иштеп чыгуучуларыбызга дээрлик бардык кырдаалда өндүрүштө эмне болуп жаткандыгы тууралуу маалыматты тез жана ишенимдүү бере алган куралды бере алдык.
Ооба, бул абдан татаал болуп чыкты, бирок, ошентсе да, биз өзүбүздүн каалоолорубузду учурдагы өнүмдөрдүн ичине киргизе алдык, аларды өзүбүз үчүн жамап, кайра жазууга туура келген жок.
Source: www.habr.com