Ժամանակակից վեբը գրեթե անհնար է պատկերացնել առանց մեդիա բովանդակության. գրեթե յուրաքանչյուր տատիկ ունի սմարթֆոն, բոլորը սոցիալական ցանցերում են, իսկ տեխնիկական սպասարկումը ծախսատար է ընկերությունների համար: Ահա ընկերության պատմության սղագրությունը այն մասին, թե ինչպես է նա կազմակերպել լուսանկարների առաքումը` օգտագործելով ապարատային լուծում, ինչ կատարողական խնդիրներ է նա հանդիպել գործընթացում, ինչի պատճառ է դարձել դրանք, և ինչպես են այդ խնդիրները լուծվել Nginx-ի վրա հիմնված ծրագրային լուծումների միջոցով՝ միաժամանակ ապահովելով սխալների հանդուրժողականություն բոլոր մակարդակներում () Շնորհակալություն ենք հայտնում Օլեգի պատմության հեղինակներին Եֆիմովան և Ալեքսանդրա Դիմովան, ովքեր կիսվեցին իրենց փորձով համաժողովում .
— Սկսենք մի փոքր ներածությունից, թե ինչպես ենք մենք պահում և պահում լուսանկարները: Մենք ունենք շերտ, որտեղ մենք պահում ենք դրանք, և շերտ, որտեղ մենք պահում ենք լուսանկարները: Միևնույն ժամանակ, եթե մենք ցանկանում ենք հասնել հնարքների բարձր արագության և նվազեցնել պահեստավորման բեռը, մեզ համար կարևոր է, որ առանձին օգտագործողի յուրաքանչյուր լուսանկար լինի մեկ քեշավորման սերվերի վրա: Հակառակ դեպքում մենք ստիպված կլինեինք տեղադրել այնքան շատ սկավառակներ, որքան շատ սերվերներ ունենք: Մեր հնարքների մակարդակը մոտ 99% է, այսինքն՝ մենք 100 անգամ նվազեցնում ենք մեր պահեստի բեռը, և դա անելու համար 10 տարի առաջ, երբ այս ամենը կառուցվում էր, մենք ունեինք 50 սերվեր։ Համապատասխանաբար, այս լուսանկարները սպասարկելու համար մեզ, ըստ էության, անհրաժեշտ էին 50 արտաքին տիրույթներ, որոնք սպասարկում են այս սերվերները։
Բնականաբար, անմիջապես հարց առաջացավ՝ եթե մեր սերվերներից մեկն անջատվի և անհասանելի դառնա, տրաֆիկի ո՞ր մասն ենք կորցնում։ Մենք նայեցինք, թե ինչ կա շուկայում և որոշեցինք գնել մի կտոր սարքավորում, որպեսզի այն լուծի մեր բոլոր խնդիրները։ Ընտրությունը ընկավ F5 ցանցային ընկերության լուծման վրա (որը, ի դեպ, վերջերս գնել է NGINX, Inc-ը)՝ BIG-IP տեղական տրաֆիկի մենեջեր:
Ինչ է անում այս սարքաշարը (LTM). այն երկաթյա երթուղիչ է, որն իր արտաքին պորտերի ավելցուկ է դարձնում և թույլ է տալիս երթևեկել՝ հիմնվելով ցանցի տոպոլոգիայի վրա, որոշ կարգավորումների վրա և կատարում է առողջական ստուգումներ: Մեզ համար կարևոր էր, որ այս սարքաշարը կարող էր ծրագրավորվել: Համապատասխանաբար, մենք կարող ենք նկարագրել տրամաբանությունը, թե ինչպես են կոնկրետ օգտատիրոջ լուսանկարները մատուցվում կոնկրետ քեշից: Ինչ տեսք ունի, ինչի նման է դա? Կա մի սարքաշար, որը նայում է ինտերնետին մեկ տիրույթում, մեկ IP-ով, ssl-ի բեռնաթափում է անում, վերլուծում է http հարցումները, ընտրում է քեշի համարը IRule-ից, որտեղ գնալ և թույլ է տալիս, որ տրաֆիկը գնա այնտեղ: Միևնույն ժամանակ, նա առողջական ստուգումներ է անում, և ինչ-որ մեքենայի անհասանելիության դեպքում, այդ ժամանակ մենք այնպես արեցինք, որ տրաֆիկը գնում է մեկ պահեստային սերվեր: Կազմաձևման տեսանկյունից, իհարկե, կան որոշ նրբերանգներ, բայց ընդհանուր առմամբ ամեն ինչ բավականին պարզ է. ցանցում գրանցում ենք քարտ, որոշակի թվի համապատասխանություն մեր IP-ին, ասում ենք, որ կլսենք 80 նավահանգիստներով: և 443, մենք ասում ենք, որ եթե սերվերը անհասանելի է, ապա դուք պետք է ուղարկեք երթևեկությունը պահուստային, այս դեպքում՝ 35-րդին, և մենք նկարագրում ենք մի խումբ տրամաբանություն, թե ինչպես պետք է ապամոնտաժվի այս ճարտարապետությունը: Միակ խնդիրն այն էր, որ լեզուն, որով ծրագրավորված էր սարքավորումը, Tcl-ն էր: Եթե որևէ մեկն ընդհանրապես հիշում է սա... այս լեզուն ավելի շատ գրելու համար է, քան ծրագրավորման համար հարմար լեզու.
Ի՞նչ ստացանք։ Մենք ստացանք սարքավորման մի կտոր, որն ապահովում է մեր ենթակառուցվածքի բարձր հասանելիությունը, ուղղորդում է մեր ողջ երթևեկությունը, ապահովում է առողջության առավելություններ և պարզապես աշխատում է: Ավելին, այն աշխատում է բավականին երկար ժամանակ. վերջին 10 տարիների ընթացքում դրա վերաբերյալ բողոքներ չեն եղել։ 2018 թվականի սկզբին մենք արդեն ուղարկում էինք վայրկյանում մոտ 80 հազար լուսանկար։ Սա մոտավորապես 80 գիգաբիթ տրաֆիկ է մեր երկու տվյալների կենտրոններից:
Այնուամենայնիվ…
2018-ի սկզբին աղյուսակներում տեսանք մի տգեղ պատկեր՝ ակնհայտորեն ավելացել էր լուսանկարներ ուղարկելու ժամանակը։ Եվ դա դադարեց մեզ հարմարվել: Խնդիրն այն է, որ այս պահվածքը տեսանելի էր միայն երթևեկության պիկ ժամանակ. մեր ընկերության համար սա կիրակիից երկուշաբթի գիշերն է: Բայց մնացած ժամանակ համակարգն իրեն սովորականի նման պահեց, ձախողման նշաններ չկան:
Այնուամենայնիվ, խնդիրը պետք է լուծվեր։ Մենք հայտնաբերեցինք հնարավոր խոչընդոտները և սկսեցինք վերացնել դրանք: Նախևառաջ, իհարկե, մենք ընդլայնեցինք արտաքին կապերը, կատարեցինք ներքին վերին հղումների ամբողջական աուդիտ և գտանք բոլոր հնարավոր խոչընդոտները: Բայց այս ամենն ակնհայտ արդյունք չտվեց, խնդիրը չվերացավ։
Մեկ այլ հնարավոր խոչընդոտ էր հենց լուսանկարների պահոցների կատարումը: Եվ մենք որոշեցինք, որ խնդիրը միգուցե նրանց մեջ է։ Դե, մենք ընդլայնեցինք կատարումը. հիմնականում ցանցային նավահանգիստները լուսանկարների քեշերի վրա: Բայց կրկին ակնհայտ բարելավում չի նկատվել։ Ի վերջո, մենք մեծ ուշադրություն դարձրինք հենց LTM-ի աշխատանքին, և ահա գրաֆիկների վրա տեսանք տխուր պատկեր. բոլոր պրոցեսորների ծանրաբեռնվածությունը սկսում է սահուն անցնել, բայց հետո հանկարծակի հասնում է սարահարթի: Միևնույն ժամանակ, LTM-ը դադարում է համարժեք արձագանքել առողջական ստուգումներին և վերահղումներին և սկսում է պատահականորեն անջատել դրանք, ինչը հանգեցնում է արդյունավետության լուրջ անկման:
Այսինքն՝ մենք բացահայտել ենք խնդրի աղբյուրը, բացահայտել ենք շիշը։ Մնում է որոշել, թե ինչ ենք անելու։
Առաջին, առավել ակնհայտ բանը, որ մենք կարող էինք անել, դա ինչ-որ կերպ արդիականացնելն է հենց LTM-ը: Բայց այստեղ կան որոշ նրբերանգներ, քանի որ այս սարքավորումը բավականին յուրահատուկ է, դուք չեք գնա մոտակա սուպերմարկետ և գնեք այն: Սա առանձին պայմանագիր է, առանձին լիցենզային պայմանագիր, և դրա համար շատ ժամանակ կպահանջվի։ Երկրորդ տարբերակն այն է, որ սկսեք մտածել ինքներդ ձեզ համար, հայտնեք ձեր լուծումը, օգտագործելով ձեր սեփական բաղադրիչները, գերադասելիորեն օգտագործելով բաց մուտքի ծրագիր: Մնում է միայն որոշել, թե կոնկրետ ինչ ենք ընտրելու դրա համար և որքան ժամանակ ենք ծախսելու այս խնդրի լուծման վրա, քանի որ օգտատերերը բավականաչափ լուսանկարներ չէին ստանում։ Ուստի այս ամենը պետք է անենք շատ, շատ արագ, կարելի է ասել երեկ։
Քանի որ առաջադրանքը հնչում էր այնպես, ինչպես «ինչ-որ բան արեք որքան հնարավոր է արագ և օգտագործելով մեր ունեցած ապարատը», առաջին բանը, որ մենք մտածեցինք, պարզապես առջևից մի քանի ոչ շատ հզոր մեքենաներ հեռացնելն էր, այնտեղ տեղադրել Nginx-ը, որով մենք գիտենք, թե ինչպես անել: աշխատեք և փորձեք իրականացնել այն նույն տրամաբանությունը, որը նախկինում անում էր սարքավորումը: Այսինքն, փաստորեն, մենք թողեցինք մեր սարքաշարը, տեղադրեցինք ևս 4 սերվեր, որոնք պետք է կազմաձևեինք, ստեղծեցինք արտաքին տիրույթներ նրանց համար, ինչպես դա 10 տարի առաջ էր... Մենք մի փոքր կորցրեցինք հասանելիությունը, եթե այս մեքենաները ընկան, բայց դեռ ավելի քիչ, նրանք լուծեցին մեր օգտատերերի խնդիրը տեղում:
Համապատասխանաբար, տրամաբանությունը մնում է նույնը. մենք տեղադրում ենք Nginx, այն կարող է անել SSL-offload, մենք կարող ենք ինչ-որ կերպ ծրագրավորել երթուղիների տրամաբանությունը, կոնֆիգուրների առողջության ստուգումները և պարզապես կրկնօրինակել այն տրամաբանությունը, որը նախկինում ունեինք։
Եկեք նստենք կոնֆիգուրացիաներ գրելու։ Սկզբում թվում էր, թե ամեն ինչ շատ պարզ է, բայց, ցավոք, շատ դժվար է ձեռնարկներ գտնել յուրաքանչյուր առաջադրանքի համար։ Հետևաբար, մենք խորհուրդ չենք տալիս պարզապես գուգլել «ինչպես կարգավորել Nginx-ը լուսանկարների համար». ավելի լավ է դիմել պաշտոնական փաստաթղթերին, որոնք ցույց կտան, թե որ պարամետրերը պետք է դիպչել: Բայց ավելի լավ է ինքներդ ընտրել կոնկրետ պարամետրը: Դե, ուրեմն ամեն ինչ պարզ է՝ մենք նկարագրում ենք մեր ունեցած սերվերները, նկարագրում ենք սերտիֆիկատները... Բայց ամենահետաքրքիրը, փաստորեն, բուն երթուղային տրամաբանությունն է։
Սկզբում մեզ թվում էր, որ մենք պարզապես նկարագրում ենք մեր գտնվելու վայրը, համապատասխանեցնում ենք դրա մեջ մեր լուսանկարների քեշի քանակը, օգտագործում ենք մեր ձեռքերը կամ գեներատորը, որպեսզի նկարագրենք, թե քանի վերին հոսք է մեզ անհրաժեշտ, յուրաքանչյուր վերևում մենք նշում ենք այն սերվերը, որին պետք է տրաֆիկը: գնա և պահուստային սերվեր, եթե հիմնական սերվերը հասանելի չէ.
Բայց, հավանաբար, եթե ամեն ինչ այդքան պարզ լիներ, մենք պարզապես կգնայինք տուն և ոչինչ չէինք ասի։ Ցավոք, լռելյայն Nginx-ի կարգավորումներով, որոնք, ընդհանուր առմամբ, կատարվել են երկար տարիների մշակման ընթացքում և լիովին հարմար չեն այս դեպքի համար... կոնֆիգուրն այսպիսի տեսք ունի. փոխարկում է երթևեկությունը հաջորդին: Ավելին, առաջին ձախողումից հետո 10 վայրկյանի ընթացքում սերվերը նույնպես կանջատվի, ինչպես սխալմամբ, այնպես էլ ժամանակի դադարով, դա նույնիսկ չի կարող կարգավորվել որևէ կերպ: Այսինքն, եթե մենք հեռացնենք կամ զրոյացնենք ժամանակի վերջնաժամկետի տարբերակը վերընթաց հրահանգում, ապա, չնայած Nginx-ը չի մշակի այս հարցումը և կպատասխանի ոչ այնքան լավ սխալով, սերվերը կփակվի:
Դրանից խուսափելու համար մենք երկու բան արեցինք.
ա) նրանք արգելեցին Nginx-ին դա անել ձեռքով, և, ցավոք, դա անելու միակ միջոցը պարզապես առավելագույն ձախողման կարգավորումները սահմանելն է:
բ) մենք հիշեցինք, որ այլ նախագծերում մենք օգտագործում ենք մոդուլ, որը թույլ է տալիս մեզ կատարել ֆոնային առողջական ստուգումներ. համապատասխանաբար, մենք բավականին հաճախակի առողջական ստուգումներ ենք կատարել, որպեսզի դժբախտ պատահարի դեպքում պարապուրդը նվազագույն լինի:
Ցավոք սրտի, սա նույնպես ամբողջը չէ, քանի որ բառացիորեն այս սխեմայի գործարկման առաջին երկու շաբաթները ցույց տվեցին, որ TCP-ի առողջության ստուգումը նույնպես անվստահելի բան է. վերընթաց սերվերի վրա այն կարող է չլինել Nginx կամ Nginx D- վիճակում, և այս դեպքում միջուկը կընդունի կապը, առողջության ստուգումը կանցնի, բայց չի աշխատի։ Հետևաբար, մենք անմիջապես դա փոխարինեցինք Health-check http-ով, պատրաստեցինք կոնկրետ, որը, եթե վերադարձնում է 200, ապա այս սկրիպտում ամեն ինչ աշխատում է։ Դուք կարող եք կատարել լրացուցիչ տրամաբանություն, օրինակ, սերվերների քեշավորման դեպքում ստուգեք, որ ֆայլային համակարգը ճիշտ է տեղադրված.
Եվ սա կհամապատասխաներ մեզ, բացառությամբ, որ տվյալ պահին միացումն ամբողջությամբ կրկնեց այն, ինչ արեց սարքավորումը: Բայց մենք ուզում էինք ավելի լավ անել: Նախկինում մենք ունեինք մեկ պահեստային սերվեր, և դա, հավանաբար, այնքան էլ լավ չէ, քանի որ եթե ունեք հարյուր սերվեր, ապա երբ միանգամից մի քանիսը ձախողվում են, դժվար թե մեկ պահուստային սերվերը կարողանա հաղթահարել բեռը: Հետևաբար, մենք որոշեցինք վերապահումը բաշխել բոլոր սերվերների վրա. մենք պարզապես պատրաստեցինք ևս մեկ առանձին վերև, այնտեղ գրեցինք բոլոր սերվերները որոշակի պարամետրերով, ըստ այն բեռի, որը նրանք կարող են սպասարկել, ավելացրինք նույն առողջության ստուգումները, որոնք նախկինում ունեինք.
Քանի որ հնարավոր չէ մեկ այլ հոսանքին հակառակ անցնել, անհրաժեշտ էր համոզվել, որ եթե հիմնական վերին հոսանքը, որում մենք պարզապես գրանցել ենք ճիշտ, անհրաժեշտ ֆոտոքեշը, անհասանելի է, մենք պարզապես error_page միջով անցանք դեպի հետադարձ, սկսած: որտեղ մենք գնացինք պահուստային հոսանքին հակառակ.
Եվ բառացիորեն չորս սերվեր ավելացնելով, սա այն է, ինչ մենք ստացանք. մենք փոխարինեցինք բեռի մի մասը. մենք այն հեռացրեցինք LTM-ից այս սերվերների վրա, նույն տրամաբանությունն իրականացրեցինք այնտեղ, օգտագործելով ստանդարտ սարքավորումներ և ծրագրակազմ, և անմիջապես ստացանք բոնուսը, որը կարող են այս սերվերները: լինեն մասշտաբային, քանի որ դրանք կարող են պարզապես մատակարարվել այնքան, որքան անհրաժեշտ է: Դե, միակ բացասականն այն է, որ մենք կորցրել ենք բարձր հասանելիությունը արտաքին օգտագործողների համար: Բայց այդ պահին մենք պետք է զոհաբերեինք սա, քանի որ անհրաժեշտ էր անհապաղ լուծել խնդիրը։ Այսպիսով, մենք հանեցինք բեռի մի մասը, այն այդ ժամանակ մոտ 40% էր, LTM-ն իրեն լավ էր զգում, և բառացիորեն խնդրի սկսվելուց երկու շաբաթ անց մենք սկսեցինք ուղարկել ոչ թե 45 հազար հարցում վայրկյանում, այլ 55 հազար: Փաստորեն, մենք աճել ենք 20%-ով. սա ակնհայտորեն այն տրաֆիկն է, որը մենք չենք տվել օգտատիրոջը: Եվ դրանից հետո սկսեցին մտածել, թե ինչպես լուծել մնացած խնդիրը՝ ապահովել բարձր արտաքին հասանելիություն։
Մենք որոշակի դադար ունեցանք, որի ընթացքում քննարկեցինք, թե ինչ լուծում ենք օգտագործելու դրա համար։ Առաջարկներ կային DNS-ի միջոցով հուսալիություն ապահովելու, որոշ տնային գրված սկրիպտների, դինամիկ երթուղային պրոտոկոլների օգտագործման համար... շատ տարբերակներ կային, բայց արդեն պարզ դարձավ, որ լուսանկարների իսկապես հուսալի առաքման համար պետք է ներմուծել մեկ այլ շերտ, որը կվերահսկի դա: . Մենք այս մեքենաներին անվանեցինք ֆոտոռեժիսորներ: Ծրագրաշարը, որի վրա մենք ապավինում էինք, Keepalived էր.
Սկսելու համար, ինչից է բաղկացած Keepalived-ը: Առաջինը VRRP արձանագրությունն է, որը լայնորեն հայտնի է ցանցային աշխատողներին, որը տեղակայված է ցանցային սարքավորումների վրա, որն ապահովում է սխալների հանդուրժողականություն արտաքին IP հասցեի նկատմամբ, որին միանում են հաճախորդները: Երկրորդ մասը IPVS-ն է՝ IP վիրտուալ սերվերը՝ լուսանկարչական երթուղիչների միջև հավասարակշռելու և այս մակարդակում սխալների հանդուրժողականության ապահովման համար: Եվ երրորդը՝ առողջական ստուգումներ։
Սկսենք առաջին մասից. VRRP - ինչ տեսք ունի: Կա որոշակի վիրտուալ IP, որը մուտք ունի dns badoocdn.com-ում, որտեղ հաճախորդները միանում են։ Ժամանակի ինչ-որ պահի մենք ունենք IP հասցե մեկ սերվերի վրա: Keepalived փաթեթները աշխատում են սերվերների միջև՝ օգտագործելով VRRP արձանագրությունը, և եթե վարպետը անհետանում է ռադարից՝ սերվերը վերագործարկվել է կամ այլ բան, ապա պահուստային սերվերն ավտոմատ կերպով վերցնում է այս IP հասցեն. ձեռքով գործողություններ չեն պահանջվում: Վարպետի և կրկնօրինակի միջև տարբերությունը հիմնականում առաջնահերթ է. որքան բարձր է այն, այնքան մեծ է մեքենայի վարպետ դառնալու հավանականությունը: Շատ մեծ առավելությունն այն է, որ ձեզ հարկավոր չէ IP հասցեները կարգավորել հենց սերվերի վրա, բավական է դրանք նկարագրել կոնֆիգուրացիայի մեջ, և եթե IP հասցեներին անհրաժեշտ են որոշակի երթուղային կանոններ, դա նկարագրվում է անմիջապես կոնֆիգուրայում՝ օգտագործելով նույն շարահյուսությունը, ինչպես նկարագրված է VRRP փաթեթում: Դուք չեք հանդիպի անծանոթ բաների:
Ինչպիսի՞ն է սա գործնականում: Ի՞նչ է պատահում, եթե սերվերներից մեկը ձախողվի: Հենց որ վարպետը անհետանում է, մեր կրկնօրինակը դադարում է գովազդ ստանալ և ինքնաբերաբար դառնում է վարպետ։ Որոշ ժամանակ անց մենք վերանորոգեցինք վարպետը, վերագործարկեցինք, բարձրացրինք Keepalived-ը. գովազդները գալիս են ավելի բարձր առաջնահերթությամբ, քան կրկնօրինակը, և կրկնօրինակումն ավտոմատ կերպով հետ է դառնում, հեռացնում է IP հասցեները, ձեռքով գործողություններ պետք չէ անել:
Այսպիսով, մենք ապահովել ենք արտաքին IP հասցեի սխալների հանդուրժողականությունը: Հաջորդ մասը պետք է ինչ-որ կերպ հավասարակշռել տրաֆիկը արտաքին IP հասցեից դեպի լուսանկարչական երթուղիչներ, որոնք արդեն դադարեցնում են այն: Հավասարակշռման արձանագրություններով ամեն ինչ միանգամայն պարզ է։ Սա կա՛մ պարզ շրջանաձև է, կա՛մ մի փոքր ավելի բարդ բաներ, wrr, ցուցակի միացում և այլն: Սա հիմնականում նկարագրված է փաստաթղթերում, առանձնահատուկ բան չկա: Բայց առաքման եղանակը... Այստեղ մենք ավելի մանրամասն կանդրադառնանք, թե ինչու ենք ընտրել դրանցից մեկը: Սրանք են NAT-ը, Direct Routing-ը և TUN-ը: Փաստն այն է, որ մենք անմիջապես ծրագրել էինք 100 գիգաբիթ տրաֆիկ մատակարարել կայքերից։ Եթե գնահատում եք, ապա ձեզ հարկավոր է 10 գիգաբիթ քարտ, չէ՞: 10 գիգաբիթ քարտը մեկ սերվերում արդեն դուրս է, համենայն դեպս, մեր «ստանդարտ սարքավորման» հայեցակարգի շրջանակներից: Եվ հետո մենք հիշեցինք, որ մենք ոչ միայն տալիս ենք որոշ երթևեկություն, այլ նվիրում ենք լուսանկարներ:
Ինչն է առանձնահատուկ: - Հսկայական տարբերություն մուտքային և ելքային տրաֆիկի միջև: Մուտքային տրաֆիկը շատ փոքր է, ելքային տրաֆիկը շատ մեծ է.
Եթե նայեք այս գրաֆիկներին, կարող եք տեսնել, որ այս պահին տնօրենը վայրկյանում ստանում է մոտ 200 ՄԲ, սա շատ սովորական օր է։ Մենք վերադարձնում ենք վայրկյանում 4,500 ՄԲ, մեր հարաբերակցությունը մոտավորապես 1/22 է: Արդեն պարզ է, որ 22 աշխատող սերվերներին ելքային տրաֆիկ ամբողջությամբ ապահովելու համար մեզ անհրաժեշտ է միայն մեկը, որն ընդունում է այս կապը: Այստեղ է, որ մեզ օգնության է հասնում ուղիղ երթուղիների ալգորիթմը:
Ինչ տեսք ունի, ինչի նման է դա? Մեր ֆոտոռեժիսորը, ըստ իր աղյուսակի, կապեր է փոխանցում ֆոտո երթուղիչներին։ Բայց լուսանկարչական երթուղիչները հետադարձ թրաֆիկը ուղարկում են ուղղակիորեն ինտերնետ, ուղարկում հաճախորդին, այն չի վերադառնում լուսանկարչական տնօրենի միջոցով, այդպիսով նվազագույն թվով մեքենաների դեպքում մենք ապահովում ենք սխալների ամբողջական հանդուրժողականություն և ամբողջ տրաֆիկի պոմպում: Կազմաձևերում այն ունի հետևյալ տեսքը. մենք նշում ենք ալգորիթմը, մեր դեպքում դա պարզ rr է, տրամադրում ենք ուղիղ երթուղիների մեթոդը և սկսում ենք թվարկել բոլոր իրական սերվերները, որոնցից քանիսն ունենք։ Որը կորոշի այս երթեւեկությունը: Եթե մենք այնտեղ ունենք ևս մեկ կամ երկու սերվեր կամ մի քանի սերվեր, նման անհրաժեշտություն է առաջանում, մենք պարզապես ավելացնում ենք այս բաժինը կազմաձևին և շատ մի անհանգստացեք: Իրական սերվերների կողմից, լուսանկարչական երթուղիչի կողմից, այս մեթոդը պահանջում է նվազագույն կոնֆիգուրացիա, այն հիանալի նկարագրված է փաստաթղթերում, և այնտեղ որոգայթներ չկան:
Հատկապես հաճելին այն է, որ նման լուծումը չի ենթադրում տեղական ցանցի արմատական վերանախագծում, սա մեզ համար կարևոր էր, մենք պետք է դա լուծեինք նվազագույն ծախսերով: Եթե նայեք , ապա կտեսնենք, թե ինչ տեսք ունի այն։ Այստեղ մենք ունենք որոշակի վիրտուալ սերվեր՝ 443 պորտում, լսում է, ընդունում է կապը, բոլոր աշխատող սերվերները թվարկված են, և դուք կարող եք տեսնել, որ կապը, տալ կամ վերցնել, նույնն է։ Եթե նայենք նույն վիրտուալ սերվերի վիճակագրությանը, ապա մենք ունենք մուտքային փաթեթներ, մուտքային կապեր, բայց բացարձակապես ոչ ելքային: Ելքային կապերը ուղղակիորեն գնում են հաճախորդին: Լավ, մենք կարողացանք անհավասարակշռել այն: Հիմա, ի՞նչ տեղի կունենա, եթե մեր լուսանկարչական երթուղիչներից մեկը ձախողվի: Ի վերջո, երկաթը երկաթ է: Այն կարող է ընկնել միջուկի խուճապի մեջ, կարող է կոտրվել, էներգիայի մատակարարումը կարող է այրվել: Ցանկացած բան: Ահա թե ինչու են անհրաժեշտ առողջական ստուգումներ։ Դրանք կարող են լինել այնքան պարզ, որքան ստուգելը, թե ինչպես է նավահանգիստը բաց, կամ ինչ-որ ավելի բարդ բան, մինչև տնային գրված որոշ սցենարներ, որոնք նույնիսկ կստուգեն բիզնեսի տրամաբանությունը:
Մենք կանգ առանք ինչ-որ տեղ մեջտեղում. մենք ունենք https հարցում կոնկրետ վայրում, սկրիպտը կոչվում է, եթե այն պատասխանում է 200-րդ պատասխանով, կարծում ենք, որ ամեն ինչ կարգին է այս սերվերի հետ, որ այն կենդանի է և կարող է բավականին միացնել: հեշտությամբ.
Ինչպես է սա, կրկին, գործնականում: Եկեք անջատենք սերվերը սպասարկման համար, օրինակ՝ BIOS-ը թարթելով: Տեղեկամատյաններում մենք անմիջապես ունենում ենք թայմաութ, տեսնում ենք առաջին տողը, այնուհետև երեք փորձից հետո այն նշվում է որպես «ձախողված», և այն պարզապես հանվում է ցուցակից։
Հնարավոր է նաև վարքագծի երկրորդ տարբերակը, երբ VS-ը պարզապես զրոյական է, բայց եթե լուսանկարը վերադարձվի, դա լավ չի աշխատում: Սերվերը հայտնվում է, Nginx-ը սկսում է այնտեղ, առողջության ստուգումը անմիջապես հասկանում է, որ կապն աշխատում է, որ ամեն ինչ լավ է, և սերվերը հայտնվում է մեր ցուցակում, և բեռը անմիջապես սկսում է կիրառվել դրա վրա: Հերթապահ ադմինիստրատորից ձեռքով գործողություններ չեն պահանջվում: Սերվերը վերագործարկվել է գիշերը. մոնիտորինգի բաժինը մեզ չի զանգում այս մասին գիշերը: Տեղեկացնում են, որ դա եղել է, ամեն ինչ լավ է։
Այսպիսով, բավականին պարզ ձևով, փոքր քանակությամբ սերվերների օգնությամբ մենք լուծեցինք արտաքին սխալների հանդուրժողականության խնդիրը։
Մնում է միայն ասել, որ այս ամենն, իհարկե, վերահսկման կարիք ունի։ Առանձին-առանձին, հարկ է նշել, որ Keepalivede-ը, որպես վաղուց գրված ծրագրակազմ, ունի այն վերահսկելու մի շարք եղանակներ՝ ինչպես DBus-ի, SMTP-ի, SNMP-ի, այնպես էլ ստանդարտ Zabbix-ի միջոցով ստուգումների միջոցով: Բացի այդ, նա ինքն էլ գիտի, թե ինչպես գրել տառեր գրեթե ամեն փռշտոցի համար, և ճիշտն ասած, ինչ-որ պահի մենք նույնիսկ մտածել ենք այն անջատելու մասին, քանի որ նա շատ տառեր է գրում ցանկացած տրաֆիկի միացման, միացման, յուրաքանչյուր IP կապի համար, եւ այլն . Իհարկե, եթե կան շատ սերվերներ, ապա դուք կարող եք ծանրաբեռնել ձեզ այս տառերով: Մենք վերահսկում ենք nginx-ը ֆոտո երթուղիչների վրա՝ օգտագործելով ստանդարտ մեթոդներ, և ապարատային մոնիտորինգը չի վերացել: Մենք, իհարկե, խորհուրդ կտայինք ևս երկու բան՝ առաջին հերթին՝ արտաքին առողջության ստուգումներ և հասանելիություն, քանի որ նույնիսկ եթե ամեն ինչ աշխատում է, իրականում օգտատերերը գուցե լուսանկարներ չեն ստանում արտաքին պրովայդերների հետ կապված խնդիրների կամ ինչ-որ ավելի բարդ բանի պատճառով: Միշտ արժե ինչ-որ տեղ պահել մեկ այլ ցանցում՝ Amazon-ում կամ մեկ այլ տեղ, առանձին մեքենա, որը կարող է ձեր սերվերներին դրսից ping ուղարկել, ինչպես նաև արժե օգտագործել կամ անոմալիաների հայտնաբերումը, նրանց համար, ովքեր գիտեն, թե ինչպես անել բարդ մեքենայական ուսուցում, կամ պարզ մոնիտորինգ: , համենայն դեպս՝ հետևելու համար՝ արդյոք հարցումները կտրուկ նվազել են, կամ, ընդհակառակը, աճել են։ Այն կարող է նաև օգտակար լինել։
Եկեք ամփոփենք. մենք, փաստորեն, փոխարինեցինք երկաթապատ լուծումը, որը ինչ-որ պահի դադարել էր մեզ հարմարվել, բավականին պարզ համակարգով, որն ամեն ինչ անում է նույնը, այսինքն՝ ապահովում է HTTPS տրաֆիկի դադարեցում և հետագա խելացի երթուղում անհրաժեշտ առողջական ստուգումներ. Մենք բարձրացրել ենք այս համակարգի կայունությունը, այսինքն՝ մենք դեռևս ունենք բարձր հասանելիություն յուրաքանչյուր շերտի համար, գումարած մենք ունենք բոնուս, որ բավականին հեշտ է այդ ամենը չափել յուրաքանչյուր շերտի վրա, քանի որ դա ստանդարտ ապարատ է ստանդարտ ծրագրաշարով, այսինքն. , մենք պարզեցրել ենք հնարավոր խնդիրների ախտորոշումը։
Ինչի՞ հետ հայտնվեցինք։ Մենք խնդիր ունեինք 2018 թվականի հունվարյան տոներին. Առաջին վեց ամիսների ընթացքում, երբ մենք գործարկեցինք այս սխեման, մենք ընդլայնեցինք այն ամբողջ տրաֆիկի վրա, որպեսզի հեռացնենք ամբողջ տրաֆիկը LTM-ից, մենք աճեցինք միայն մեկ տվյալների կենտրոնի թրաֆիկը 40 գիգաբիթից մինչև 60 գիգաբիթ, և միևնույն ժամանակ. ամբողջ 2018 թվականը կարողացել է վայրկյանում երեք անգամ ավելի շատ լուսանկարներ ուղարկել:
Source: www.habr.com