Citymobil-ում մենք օգտագործում ենք MySQL տվյալների բազա՝ որպես մեր հիմնական մշտական տվյալների պահեստավորում: Մենք ունենք տվյալների բազայի մի քանի կլաստերներ տարբեր ծառայությունների և նպատակների համար:
Վարպետի մշտական հասանելիությունը ամբողջ համակարգի և դրա առանձին մասերի աշխատանքի կարևոր ցուցանիշն է: Կլաստերների ավտոմատ վերականգնումը հիմնական ձախողման դեպքում զգալիորեն նվազեցնում է միջադեպի արձագանքման ժամանակը և համակարգի խափանումը: Այս հոդվածում ես կանդրադառնամ MySQL կլաստերի բարձր հասանելիության (HA) դիզայնին, որը հիմնված է և վիրտուալ IP հասցեներ (VIP):
HA լուծում՝ հիմնված VIP-ի վրա
Նախ, ես հակիրճ կասեմ ձեզ, թե որն է մեր տվյալների պահպանման համակարգը:
Մենք օգտագործում ենք կրկնօրինակման դասական սխեման մեկ գրելու համար հասանելի վարպետով և միայն կարդալու համար նախատեսված մի քանի կրկնօրինակներով: Կլաստերը կարող է պարունակել միջանկյալ վարպետ՝ հանգույց, որը և՛ կրկնօրինակ է, և՛ վարպետ մյուսների համար: Հաճախորդները մուտք են գործում կրկնօրինակներ HAProxy-ի միջոցով, ինչը թույլ է տալիս բեռի հավասարաչափ բաշխում և հեշտ մասշտաբում: HAProxy-ի օգտագործումը պայմանավորված է պատմական պատճառներով, և մենք ներկայումս գտնվում ենք ProxySQL տեղափոխման գործընթացում:
Կրկնօրինակումը կատարվում է կիսասինխրոն ռեժիմով, հիմնվելով GTID. Սա նշանակում է, որ առնվազն մեկ կրկնօրինակ պետք է գրանցի գործարքը, նախքան այն հաջողված համարվի: Այս կրկնօրինակման ռեժիմը ապահովում է օպտիմալ հավասարակշռություն կատարման և տվյալների անվտանգության միջև հիմնական հանգույցի ձախողման դեպքում: Հիմնականում բոլոր փոփոխությունները փոխանցվում են վարպետից կրկնօրինակներին՝ օգտագործելով Row Based Replication (RBR), բայց որոշ հանգույցներ կարող են ունենալ mixed binlog format.
Նվագախումբը պարբերաբար թարմացնում է կլաստերային տոպոլոգիայի վիճակը, վերլուծում է ստացված տեղեկատվությունը, և եթե խնդիրներ առաջանան, կարող է գործարկել վերականգնման ավտոմատ ընթացակարգ: Մշակողը պատասխանատու է ինքնին ընթացակարգի համար, քանի որ այն կարող է իրականացվել տարբեր ձևերով՝ հիմնված VIP-ի, DNS-ի վրա, օգտագործելով ծառայության հայտնաբերման ծառայություններ կամ ինքնուրույն գրավոր մեխանիզմներ:
Վարպետը վերականգնելու պարզ եղանակներից մեկը, եթե այն ձախողվի, լողացող VIP հասցեների օգտագործումն է:
Ինչ պետք է իմանաք այս լուծման մասին՝ առաջ շարժվելուց առաջ.
- VIP-ը IP հասցե է, որը կապված չէ որոշակի ֆիզիկական ցանցային ինտերֆեյսի հետ: Եթե հանգույցը ձախողվի կամ պլանավորված սպասարկման ընթացքում, մենք կարող ենք VIP-ը միացնել այլ ռեսուրսի՝ նվազագույն ժամանակով:
- Վիրտուալ IP հասցեի ազատումը և թողարկումը էժան և արագ գործողություն է:
- VIP-ի հետ աշխատելու համար անհրաժեշտ է մուտք գործել սերվեր SSH-ի միջոցով կամ օգտագործել հատուկ կոմունալ ծառայություններ, օրինակ.
keepalived.
Եկեք նայենք մեր կախարդի հետ հնարավոր խնդիրներին և պատկերացնենք, թե ինչպես պետք է գործի վերականգնման ավտոմատ մեխանիզմը:
Ցանցային կապը վարպետին անհետացել է, կամ խնդիր է առաջացել ապարատային մակարդակում, և սերվերն անհասանելի է
- Նվագախումբը թարմացնում է կլաստերի տոպոլոգիան, յուրաքանչյուր կրկնօրինակ հաղորդում է, որ վարպետն անհասանելի է: Նվագախումբը սկսում է նոր վարպետի դերին համապատասխան կրկնօրինակի ընտրության գործընթացը և սկսում է վերականգնումը:
- Մենք փորձում ենք հեռացնել VIP-ին հին վարպետից՝ անհաջող:
- Կրկնօրինակն անցնում է վարպետի դերին: Տոպոլոգիան վերակառուցվում է։
- VIP-ի հետ ցանցային նոր ինտերֆեյսի ավելացում: Քանի որ հնարավոր չէր հեռացնել VIP-ը, մենք սկսում ենք պարբերաբար հարցումներ ուղարկել հետին պլանում անհատույց ՀՀՊ. Այս տեսակի հարցումը/պատասխանը թույլ է տալիս թարմացնել IP և MAC հասցեների քարտեզագրման աղյուսակը միացված անջատիչների վրա՝ դրանով իսկ տեղեկացնելով, որ մեր VIP-ը տեղափոխվել է: Սա նվազագույնի է հասցնում հավանականությունը
split brainհին վարպետին վերադարձնելիս. - Բոլոր նոր կապերն անմիջապես վերահղվում են նոր վարպետին: Հին կապերը ձախողվում են, և տվյալների բազայի կրկնվող զանգերը կատարվում են հավելվածի մակարդակով:
Սերվերը աշխատում է նորմալ ռեժիմով, սխալ է տեղի ունեցել DBMS մակարդակում
Ալգորիթմը նման է նախորդ դեպքին՝ թարմացնելով տոպոլոգիան և սկսել վերականգնման գործընթացը։ Քանի որ սերվերը հասանելի է, մենք հաջողությամբ թողարկում ենք VIP-ը հին վարպետի վրա, փոխանցում այն նորին և ուղարկում ենք մի քանի ARP հարցումներ: Հին վարպետի հնարավոր վերադարձը չպետք է ազդի վերակառուցված կլաստերի և հավելվածի աշխատանքի վրա:
Այլ խնդիրներ
Կրկնօրինակների կամ միջանկյալ վարպետների ձախողում չի տանում ավտոմատ գործողություններին և պահանջում է ձեռքով միջամտություն:
Վիրտուալ ցանցային ինտերֆեյսը միշտ ավելացվում է ժամանակավորապես, այսինքն՝ սերվերի վերագործարկումից հետո VIP-ն ինքնաբերաբար չի նշանակվում: Տվյալների բազայի յուրաքանչյուր օրինակ լռելյայնորեն սկսվում է միայն կարդալու ռեժիմով, նվագախումբն ավտոմատ կերպով փոխում է նոր վարպետը գրելու և փորձում է տեղադրել read only հին վարպետի վրա. Այս գործողությունները նպատակ ունեն նվազեցնելու հավանականությունը split brain.
Խնդիրներ կարող են առաջանալ վերականգնման գործընթացում, որը պետք է նաև տեղեկացվի նվագախմբի միջերեսի միջոցով՝ ի լրումն ստանդարտ մոնիտորինգի գործիքների: Մենք ընդլայնել ենք REST API-ն՝ ավելացնելով այս հատկությունը ( ներկայումս վերանայման փուլում է):
HA լուծման ընդհանուր դիագրամը ներկայացված է ստորև.
Ընտրելով նոր վարպետ
Նվագախումբը բավականաչափ խելացի է և փորձում է ընտրել որպես նոր վարպետ՝ հետևյալ չափանիշներով.
- կրկնօրինակը հետ է մնում վարպետից.
- Master-ի և կրկնօրինակի MySQL տարբերակը;
- կրկնօրինակման տեսակը (RBR, SBR կամ խառը);
- գտնվելու վայրը նույն կամ տարբեր տվյալների կենտրոններում.
- մատչելիություն
errant GTID- գործարքներ, որոնք կատարվել են կրկնօրինակի վրա և չեն գտնվում վարպետի վրա. - հաշվի են առնվում նաև մաքսային ընտրության կանոնները:
Ամեն ակնարկ չէ, որ իդեալական թեկնածու է վարպետի համար: Օրինակ, կրկնօրինակը կարող է օգտագործվել տվյալների կրկնօրինակման համար, կամ սերվերն ունի ավելի թույլ ապարատային կոնֆիգուրացիա: Նվագախումբ ձեռնարկի կանոններ, որոնց օգնությամբ դուք կարող եք հարմարեցնել ձեր թեկնածուների ընտրության նախապատվությունները ամենանախընտրելիից մինչև անտեսված:
Արձագանքման և վերականգնման ժամանակը
Միջադեպի դեպքում կարևոր է նվազագույնի հասցնել համակարգի խափանումների ժամանակը, ուստի եկեք դիտարկենք MySQL պարամետրերը, որոնք ազդում են նվագախմբի կողմից կլաստերային տոպոլոգիայի ստեղծման և թարմացման վրա.
- — վայրկյանների քանակը, որոնց ընթացքում կրկնօրինակը սպասում է նոր տվյալների կամ սրտի բաբախման ազդանշանի, որը կհասնի վարպետից մինչև կապը կորած ճանաչվի և նորից միանա: Որքան ցածր է արժեքը, այնքան ավելի արագ կրկնօրինակը կարող է որոշել, որ կապը վարպետի հետ խզված է: Մենք սահմանել ենք այս արժեքը 5 վայրկյան:
- — վերամիացման փորձերի միջև ընկած վայրկյանների քանակը: Ցանցի խնդիրների դեպքում այս պարամետրի ցածր արժեքը թույլ կտա արագ վերամիացում և կկանխի կլաստերի վերականգնման գործընթացի մեկնարկը: Առաջարկվող արժեքը 1 վայրկյան է:
MASTER_RETRY_COUNT— վերամիացման փորձերի առավելագույն քանակը:MASTER_HEARTBEAT_PERIOD— վայրկյաններով ընդմիջում, որից հետո վարպետը սրտի բաբախման ազդանշան է ուղարկում: Կանխադրված արժեքի կեսըslave_net_timeout.
Նվագախմբի պարամետրերը.
DelayMasterPromotionIfSQLThreadNotUpToDate- եթե հավասար էtrue, ապա հիմնական դերը չի կիրառվի թեկնածուի կրկնօրինակի վրա, քանի դեռ կրկնօրինակի SQL շարանը չի ավարտել բոլոր չկիրառված գործարքները Relay Log-ից: Մենք օգտագործում ենք այս տարբերակը՝ գործարքները չկորցնելու համար, երբ բոլոր թեկնածուների կրկնօրինակները հետ են մնում:InstancePollSeconds— տոպոլոգիայի կառուցման և թարմացման հաճախականությունը:RecoveryPollSeconds- տոպոլոգիայի վերլուծության հաճախականությունը: Եթե խնդիր հայտնաբերվի, սկսվում է տոպոլոգիայի վերականգնումը: Սա, հավասար է 1 վայրկյանի։
Յուրաքանչյուր կլաստերային հանգույց քվեարկվում է նվագախմբի կողմից յուրաքանչյուր անգամ մեկ անգամ InstancePollSeconds վայրկյան Երբ խնդիր է հայտնաբերվում, կլաստերի վիճակը պարտադրվում է, իսկ հետո վերջնական որոշում է կայացվում վերականգնումն իրականացնելու մասին։ Փորձարկելով տվյալների բազայի և նվագախմբի տարբեր պարամետրերը, մենք կարողացանք կրճատել արձագանքման և վերականգնման ժամանակը մինչև 30 վայրկյան:
Փորձարկման տակդիր
Մենք սկսեցինք փորձարկել HA սխեման տեղական մշակմամբ և հետագա իրականացում թեստային և արտադրական միջավայրերում: Տեղական ստենդը լիովին ավտոմատացված է Docker-ի հիման վրա և թույլ է տալիս փորձարկել նվագախմբի և ցանցի կազմաձևումը, կլաստերը 2-3 սերվերից հասցնել մի քանի տասնյակի և վարժանքներ անցկացնել անվտանգ միջավայրում:
Զորավարժությունների ընթացքում մենք ընտրում ենք խնդրի նմանակման մեթոդներից մեկը՝ ակնթարթորեն նկարահանել վարպետին՝ օգտագործելով kill -9, մեղմորեն դադարեցրեք գործընթացը և դադարեցրեք սերվերը (docker-compose stop), մոդելավորել ցանցի խնդիրները՝ օգտագործելով iptables -j REJECT կամ iptables -j DROP. Ակնկալում ենք հետևյալ արդյունքները.
- նվագախումբը կհայտնաբերի վարպետի հետ կապված խնդիրները և կթարմացնի տոպոլոգիան ոչ ավելի, քան 10 վայրկյանում.
- վերականգնման ընթացակարգը ինքնաբերաբար կսկսվի. ցանցի կոնֆիգուրացիան կփոխվի, վարպետի դերը կանցնի կրկնօրինակին, տոպոլոգիան կվերակառուցվի.
- նոր վարպետը կդառնա գրավոր, կենդանի կրկնօրինակները չեն կորչի վերակառուցման գործընթացում.
- տվյալները կսկսեն գրվել նոր վարպետին և վերարտադրվել.
- Վերականգնման ընդհանուր ժամանակը կկազմի ոչ ավելի, քան 30 վայրկյան:
Ինչպես գիտեք, համակարգը կարող է տարբեր կերպ վարվել թեստային և արտադրական միջավայրերում՝ տարբեր ապարատային և ցանցային կոնֆիգուրացիաների, սինթետիկ և իրական բեռի տարբերությունների և այլնի պատճառով: Հետևաբար, մենք պարբերաբար իրականացնում ենք վարժություններ իրական պայմաններում՝ ստուգելով, թե ինչպես է համակարգը վարվում, երբ ցանցի միացումը կորչում է կամ դրա առանձին մասերը քայքայվում են: Ապագայում մենք ցանկանում ենք ստեղծել բոլորովին նույնական ենթակառուցվածք երկու միջավայրերի համար և ավտոմատացնել դրա փորձարկումը:
Արդյունքները
Հիմնական պահեստավորման համակարգի հանգույցի առողջությունը SRE-ի և գործառնական թիմի հիմնական խնդիրներից մեկն է: VIP-ի վրա հիմնված նվագախմբի և ՀԱ լուծման իրականացումը թույլ տվեց մեզ հասնել հետևյալ արդյունքների.
- տվյալների բազայի կլաստերի տոպոլոգիայի հետ կապված խնդիրների հուսալի հայտնաբերում.
- ավտոմատ և արագ արձագանքում վարպետի հետ կապված միջադեպերին՝ նվազեցնելով համակարգի խափանումների ժամանակը:
Այնուամենայնիվ, լուծումն ունի իր սահմանափակումներն ու թերությունները.
- HA սխեման մի քանի տվյալների կենտրոնների մասշտաբը կպահանջի նրանց միջև մեկ L2 ցանց;
- Նախքան նոր վարպետին VIP նշանակելը, մենք պետք է այն թողարկենք հինի վրա: Գործընթացը հաջորդական է, ինչը մեծացնում է վերականգնման ժամանակը.
- VIP-ի թողարկումը պահանջում է SSH մուտք դեպի սերվեր կամ հեռավոր ընթացակարգեր կանչելու ցանկացած այլ եղանակ: Քանի որ սերվերը կամ տվյալների բազան խնդիրներ ունի, որոնք առաջացրել են վերականգնման գործընթացը, մենք չենք կարող վստահ լինել, որ VIP-ի հեռացումը հաջողությամբ կավարտվի: Եվ դա կարող է հանգեցնել նույն վիրտուալ IP հասցեով երկու սերվերի հայտնվելուն և խնդրի
split brain.
Խուսափելու համար split brain, կարող եք օգտագործել մեթոդը («Shoot The Other Node In The Head»), որն ամբողջությամբ մեկուսացնում կամ անջատում է խնդրահարույց հանգույցը: Կլաստերների բարձր հասանելիության իրականացման այլ եղանակներ կան՝ VIP-ի և DNS-ի համադրություն, ծառայության հայտնաբերման և վստահված անձի ծառայություններ, համաժամանակյա վերարտադրություն և այլ մեթոդներ, որոնք ունեն իրենց թերություններն ու առավելությունները:
Ես խոսեցի MySQL ձախողման կլաստերի ստեղծման մեր մոտեցման մասին: Այն հեշտ է իրականացնել և ապահովում է հուսալիության ընդունելի մակարդակ ներկա պայմաններում: Քանի որ ամբողջ համակարգը ընդհանրապես և ենթակառուցվածքները մասնավորապես զարգանում են, այս մոտեցումը, անկասկած, կզարգանա:
Source: www.habr.com