2019 թվականի ամառվա առաջին և երկրորդ ամսվա վերջը բարդ էր և նշանավորվեց համաշխարհային ՏՏ ծառայությունների մի քանի խոշոր անկումներով։ Հատկանշականներից են. երկու լուրջ միջադեպ CloudFlare ենթակառուցվածքում (առաջինը՝ ծուռ ձեռքերով և BGP-ի նկատմամբ ԱՄՆ-ի որոշ ISP-ների կողմից անփույթ վերաբերմունքով, երկրորդը՝ իրենք՝ CF-ի խեղաթյուրված տեղակայմամբ, որը ազդել է CF օգտագործող բոլորի վրա։ , և սրանք շատ նշանավոր ծառայություններ են) և Facebook-ի CDN ենթակառուցվածքի անկայուն աշխատանքը (ազդել են FB-ի բոլոր արտադրանքների վրա, ներառյալ Instagram-ը և WhatsApp-ը): Մենք նույնպես ստիպված էինք բռնվել բաշխման մեջ, չնայած մեր անջատումը շատ ավելի քիչ նկատելի էր համաշխարհային ֆոնի վրա: Ինչ-որ մեկն արդեն սկսել է քաշել սև ուղղաթիռները և «ինքնիշխան» դավադրությունները, ուստի մենք հրապարակում ենք մեր միջադեպի հրապարակային դիահերձումը:
03.07.2019, 16: 05
Սկսեցին արձանագրվել ռեսուրսների հետ կապված խնդիրներ, որոնք նման էին ներքին ցանցի միացման խափանմանը: Ամբողջովին չստուգելով ամեն ինչ՝ նրանք սկսեցին շտկել արտաքին ալիքի կատարումը դեպի DataLine, քանի որ պարզ դարձավ, որ խնդիրը ներքին ցանցի Ինտերնետ (NAT) հասանելիության հետ է, մինչև BGP նիստը DataLine-ի վրա դնելը:
03.07.2019, 16: 35
Ակնհայտ դարձավ, որ ցանցի հասցեների թարգմանությունը և կայքի տեղական ցանցից դեպի ինտերնետ (NAT) մուտք ապահովող սարքավորումը խափանվել է: Սարքավորումը վերագործարկելու փորձերը ոչնչի չհանգեցրին, կապի կազմակերպման այլընտրանքային տարբերակների որոնումը սկսվեց նախքան տեխնիկական աջակցության պատասխան ստանալը, քանի որ փորձից, ամենայն հավանականությամբ, դա չէր օգնի:
Խնդիրը որոշակիորեն սրվել է նրանով, որ այս սարքավորումը նաև դադարեցրել է հաճախորդի VPN-ի աշխատակիցների մուտքային կապերը, և հեռահար վերականգնման աշխատանքները դժվարացել են իրականացնել:
03.07.2019, 16: 40
Մենք փորձեցինք վերակենդանացնել նախկինում գոյություն ունեցող պահեստային NAT սխեման, որը նախկինում լավ էր աշխատում: Բայց պարզ դարձավ, որ ցանցի մի շարք վերանորոգումներն այս սխեման գրեթե ամբողջությամբ անգործունակ դարձրին, քանի որ դրա վերականգնումը լավագույն դեպքում կարող էր չաշխատել, իսկ վատագույն դեպքում՝ կոտրել այն, ինչ արդեն գործում էր:
Մենք սկսեցինք աշխատել մի քանի գաղափարների վրա՝ երթևեկությունը փոխանցելու ողնաշարը սպասարկող նոր երթուղիչների մի շարք, բայց դրանք անգործունակ թվացին՝ հիմնական ցանցում երթուղիների բաշխման առանձնահատկությունների պատճառով:
03.07.2019, 17: 05
Միևնույն ժամանակ, խնդիր է հայտնաբերվել անունների լուծման մեխանիզմում անունների սերվերների վրա, ինչը հանգեցրել է հավելվածների վերջնակետերի լուծման սխալների, և նրանք սկսել են արագորեն լրացնել հոսթ ֆայլերը կարևոր ծառայությունների գրառումներով:
03.07.2019, 17: 27
Habr-ի սահմանափակ գործառույթը վերականգնվել է:
03.07.2019, 17: 43
Բայց ի վերջո սահմանային երթուղիչներից մեկով երթեւեկությունը կազմակերպելու համեմատաբար անվտանգ լուծում է գտնվել, որն արագ տեղադրվել է։ Ինտերնետ կապը վերականգնվել է։
Հաջորդ մի քանի րոպեների ընթացքում մոնիտորինգի համակարգերից բազմաթիվ ծանուցումներ ստացան մոնիտորինգի գործակալների ֆունկցիոնալությունը վերականգնելու մասին, սակայն որոշ ծառայություններ պարզվեց, որ անգործունակ էին, քանի որ անունների լուծման մեխանիզմը խախտվել էր անունների սերվերների (dns) վրա:
03.07.2019, 17: 52
NS-ը վերագործարկվեց և քեշը մաքրվեց: Լուծումը վերականգնվել է։
03.07.2019, 17: 55
Բոլոր ծառայությունները սկսեցին աշխատել, բացի MK-ից, Freelansim-ից և Toaster-ից:
03.07.2019, 18: 02
MK-ն և Freelansim-ը սկսեցին աշխատել։
03.07.2019, 18: 07
Վերադարձեք անմեղ BGP նիստը DataLine-ի հետ:
03.07.2019, 18: 25
Նրանք սկսեցին արձանագրել ռեսուրսների հետ կապված խնդիրներ, ինչը պայմանավորված էր NAT լողավազանի արտաքին հասցեի փոփոխությամբ և մի շարք ծառայությունների ակլում դրա բացակայությամբ, ինչը արագ շտկվեց: Տոստերը անմիջապես սկսեց աշխատել։
03.07.2019, 20: 30
Մենք նկատեցինք սխալներ՝ կապված Telegram բոտերի հետ։ Պարզվեց, որ մոռացել են գրանցել արտաքին հասցեն մի քանի acl-ում (proxy server), որն օպերատիվ կերպով ուղղվել է։
Արդյունքները
- Սարքավորումը, որը նախկինում կասկածներ էր սերմանում իր պիտանիության վերաբերյալ, ձախողվեց։ Ծրագրեր կային այն վերացնել աշխատանքից, քանի որ այն խանգարում էր ցանցի զարգացմանը և ուներ համատեղելիության խնդիրներ, բայց միևնույն ժամանակ կատարում էր կարևոր գործառույթ, ինչի պատճառով ցանկացած փոխարինում տեխնիկապես դժվար էր առանց ծառայությունների ընդհատման։ Այժմ դուք կարող եք առաջ շարժվել:
- DNS-ի խնդիրը կարելի է խուսափել՝ դրանք ավելի մոտեցնելով նոր հիմնական ցանցին NAT ցանցից դուրս և դեռևս լիարժեք կապ ունենալով մոխրագույն ցանցին՝ առանց թարգմանության (ինչը նախատեսում էր դեպքից առաջ):
- Դուք չպետք է օգտագործեք տիրույթի անուններ RDBMS կլաստերներ հավաքելիս, քանի որ IP հասցեն թափանցիկ փոխելու հարմարավետությունն առանձնապես անհրաժեշտ չէ, քանի որ նման մանիպուլյացիաները դեռ պահանջում են կլաստերի վերակառուցում: Այս որոշումը թելադրված էր պատմական պատճառներով և, առաջին հերթին, RDBMS կոնֆիգուրացիաներում անվանական վերջնակետերի ակնհայտությամբ: Ընդհանրապես, դասական թակարդ։
- Սկզբունքորեն, անցկացվել են «Ռունետի ինքնիշխանության» հետ համեմատելի վարժանքներ, մտածելու բան կա ինքնավար գոյատևման հնարավորությունների ամրապնդման առումով:
Source: www.habr.com