Ժամանակակից տվյալների կենտրոններն ունեն հարյուրավոր ակտիվ սարքեր, որոնք ծածկված են տարբեր տեսակի մոնիտորինգով: Բայց նույնիսկ կատարյալ ինժեները՝ կատարյալ մոնիտորինգով ձեռքին, կկարողանա ճիշտ արձագանքել ցանցի խափանումին ընդամենը մի քանի րոպեում: Next Hop 2020 կոնֆերանսի զեկույցում ես ներկայացրեցի տվյալների կենտրոնի ցանցի նախագծման մեթոդաբանությունը, որն ունի եզակի առանձնահատկություն՝ տվյալների կենտրոնն ինքն իրեն բուժում է միլիվայրկյաններով: Ավելի ճիշտ՝ ինժեները հանգիստ լուծում է խնդիրը, մինչդեռ ծառայությունները դա պարզապես չեն նկատում։
Շատ ցանցային ինժեներների համար տվյալների կենտրոնի ցանցը սկսվում է, իհարկե, ToR-ով, դարակում գտնվող անջատիչով: ToR սովորաբար ունի երկու տեսակի հղումներ. Փոքրիկները գնում են դեպի սերվերներ, մյուսները՝ նրանց թիվը N անգամ ավելին է, գնում են դեպի առաջին մակարդակի ողնաշարը, այսինքն՝ դեպի նրա վերելակները։ Վերադարձ կապերը սովորաբար համարվում են հավասար, և վերին հղումների միջև երթևեկությունը հավասարակշռված է 5-ապատիկ հեշի հիման վրա, որը ներառում է proto, src_ip, dst_ip, src_port, dst_port: Այստեղ անակնկալներ չկան։
Հաջորդը, ինչպիսի՞ն է ինքնաթիռների ճարտարապետությունը: Առաջին մակարդակի ողնաշարերը միմյանց հետ կապված չեն, այլ միացված են սուպերսպինների միջոցով։ X տառը պատասխանատու կլինի սուպերսպինների համար, այն գրեթե խաչաձեւ կապի նման է:
Եվ պարզ է, որ մյուս կողմից, Թորին կապված է առաջին մակարդակի բոլոր ողնաշարի հետ։ Ի՞նչն է կարևոր այս նկարում: Եթե մենք ունենք փոխազդեցություն դարակի ներսում, ապա փոխազդեցությունը, իհարկե, անցնում է ToR-ով: Եթե փոխազդեցությունն անցնում է մոդուլի ներսում, ապա փոխազդեցությունն անցնում է առաջին մակարդակի ողնաշարի միջով: Եթե փոխազդեցությունը միջմոդուլային է, ինչպես այստեղ՝ ToR 1 և ToR 2, ապա փոխազդեցությունը կանցնի ինչպես առաջին, այնպես էլ երկրորդ մակարդակների ողնաշարի միջով:
Տեսականորեն, նման ճարտարապետությունը հեշտությամբ ընդլայնելի է: Եթե մենք ունենք նավահանգստի հզորություն, տվյալների կենտրոնի տարածքի պահուստ և նախապես դրված մանրաթել, ապա ինքնաթիռների թիվը միշտ կարող է ավելացվել՝ դրանով իսկ ավելացնելով համակարգի ընդհանուր հզորությունը: Թղթի վրա դա շատ հեշտ է անել: Այդպես կլիներ իրական կյանքում։ Բայց այսօրվա պատմությունը դրա մասին չէ։
Ես ուզում եմ, որ ճիշտ եզրակացություններ արվեն։ Մենք ունենք բազմաթիվ ուղիներ տվյալների կենտրոնի ներսում: Նրանք պայմանականորեն անկախ են։ Տվյալների կենտրոնի ներսում մի ճանապարհ հնարավոր է միայն ToR-ի ներսում: Մոդուլի ներսում մենք ունենք նույն թվով ուղիներ, որքան ինքնաթիռների թիվը: Մոդուլների միջև երթուղիների թիվը հավասար է ինքնաթիռների քանակի և յուրաքանչյուր հարթության մեջ սուպերսպինների քանակի արտադրյալին: Ավելի պարզ դարձնելու, մասշտաբները զգալու համար ես կտամ թվերը, որոնք վավեր են Yandex տվյալների կենտրոններից մեկի համար։
Կան ութ ինքնաթիռ, յուրաքանչյուր ինքնաթիռ ունի 32 սուպերպտույտ։ Արդյունքում պարզվում է, որ մոդուլի ներսում կա ութ ուղի, և միջմոդուլային փոխազդեցությամբ դրանք արդեն 256-ն են։
Այսինքն, եթե մենք մշակում ենք «Խոհարարական գիրք»՝ փորձելով սովորել, թե ինչպես ստեղծել սխալ հանդուրժող տվյալների կենտրոններ, որոնք ինքնաբուժում են, ապա հարթ ճարտարապետությունը ճիշտ ընտրություն է: Այն թույլ է տալիս լուծել մասշտաբի խնդիրը, իսկ տեսականորեն դա հեշտ է։ Կան բազմաթիվ անկախ ուղիներ: Հարցը մնում է. ինչպե՞ս է նման ճարտարապետությունը գոյատևում ձախողումներից: Կան տարբեր վթարներ. Եվ մենք հիմա կքննարկենք դա:
Թող մեր սուպերսպիններից մեկը հիվանդանա։ Այստեղ ես վերադարձա երկու ինքնաթիռների ճարտարապետությանը։ Մենք կպահպանենք դրանք որպես օրինակ, քանի որ ավելի հեշտ կլինի տեսնել, թե ինչ է կատարվում այստեղ՝ ավելի քիչ շարժվող մասերով: Թող X11-ը հիվանդանա: Ինչպե՞ս դա կազդի տվյալների կենտրոնների ներսում ապրող ծառայությունների վրա: Շատ բան կախված է նրանից, թե իրականում ինչպիսին է ձախողումը:
Եթե ձախողումը լավ է, այն բռնվում է նույն BFD-ի ավտոմատացման մակարդակում, ավտոմատացումը ուրախությամբ դնում է խնդրահարույց հոդերը և մեկուսացնում խնդիրը, ապա ամեն ինչ լավ է: Մենք ունենք բազմաթիվ ճանապարհներ, երթևեկությունն ակնթարթորեն փոխակերպվում է այլընտրանքային երթուղիներով, և ծառայությունները ոչինչ չեն նկատի։ Սա լավ սցենար է։
Վատ սցենարն այն է, եթե անընդհատ կորուստներ ենք ունենում, իսկ ավտոմատացումը չի նկատում խնդիրը։ Հասկանալու համար, թե ինչպես է դա ազդում հավելվածի վրա, մենք ստիպված կլինենք մի փոքր ժամանակ ծախսել՝ քննարկելու, թե ինչպես է աշխատում TCP արձանագրությունը:
Հուսով եմ, որ ոչ մեկին չեմ ցնցի այս տեղեկատվությամբ. TCP-ն ձեռքսեղմման արձանագրություն է: Այսինքն՝ ամենապարզ դեպքում ուղարկողը երկու փաթեթ է ուղարկում, և դրանց վրա ստանում է կուտակային ակ. «Ես ստացել եմ երկու փաթեթ»։
Դրանից հետո նա եւս երկու փաթեթ կուղարկի, եւ իրավիճակը կկրկնվի։ Նախապես ներողություն եմ խնդրում որոշ պարզեցման համար։ Այս սցենարը ճիշտ է, եթե պատուհանը (փաթեթների թիվը թռիչքի ժամանակ) երկու է: Իհարկե, դա պարտադիր չէ, որ ընդհանուր առմամբ այդպես լինի։ Բայց փաթեթների վերահասցեավորման համատեքստը չի ազդում պատուհանի չափից:
Ի՞նչ կլինի, եթե մենք կորցնենք 3-րդ փաթեթը: Այս դեպքում ստացողը կստանա 1-ին, 2-րդ և 4-րդ փաթեթները: Եվ նա հստակորեն կտեղեկացնի ուղարկողին՝ օգտագործելով SACK տարբերակը. Նա ասում է «Ack 2, SACK 4»:
Ուղարկողն այս պահին կրկնում է հենց այն փաթեթը, որը կորել է առանց որևէ խնդրի։
Բայց եթե պատուհանի վերջին փաթեթը կորչի, իրավիճակը շատ այլ տեսք կունենա:
Ստացողը ստանում է առաջին երեք փաթեթները և առաջին հերթին սկսում է սպասել։ Linux միջուկի TCP փաթեթի որոշ օպտիմալացումների շնորհիվ այն կսպասի զուգակցված փաթեթի, եթե դրոշներում հստակ նշում չկա, որ սա վերջին փաթեթն է կամ նման բան: Այն կսպասի մինչև հետաձգված ACK-ի ժամկետի ավարտը և այնուհետև հաստատում կուղարկի առաջին երեք փաթեթների համար: Բայց հիմա ուղարկողը կսպասի։ Նա չգիտի՝ չորրորդ փաթեթը կորե՞լ է, թե՞ պատրաստվում է հասնել։ Եվ ցանցը չծանրաբեռնելու համար այն կփորձի սպասել փաթեթի կորստի հստակ ցուցումին կամ RTO-ի ժամկետի ավարտին։
Ի՞նչ է RTO-ի ժամկետը: Սա առավելագույնն է RTT-ից, որը հաշվարկվում է TCP կույտի կողմից և որոշակի հաստատուն: Ինչ է սա հաստատուն, մենք հիմա կքննարկենք:
Բայց կարևոր է, որ եթե մենք նորից անհաջողություն ունենանք, և չորրորդ փաթեթը նորից կորչի, ապա RTO-ն կրկնապատկվի: Այսինքն՝ յուրաքանչյուր անհաջող փորձ թայմաութի կրկնապատկում է։
Հիմա տեսնենք, թե ինչի է հավասար այս բազան։ Լռելյայնորեն, նվազագույն RTO-ն 200 մս է: Սա տվյալների փաթեթների նվազագույն RTO-ն է: SYN փաթեթների համար դա տարբեր է՝ 1 վայրկյան։ Ինչպես տեսնում եք, նույնիսկ փաթեթները նորից ուղարկելու առաջին փորձը կտևի 100 անգամ ավելի երկար, քան RTT-ը տվյալների կենտրոնի ներսում:
Հիմա վերադառնանք մեր սցենարին: Ի՞նչ է կատարվում ծառայության հետ: Ծառայությունը սկսում է կորցնել փաթեթները: Թող ծառայությունը սկզբում բախտի բերի և պատուհանի մեջտեղում ինչ-որ բան կորցնի, այնուհետև նա ստանում է SCK, նորից ուղարկում կորցրած փաթեթները:
Բայց եթե վատ բախտը կրկնվի, ապա մենք ունենք RTO: Ի՞նչն է այստեղ կարևոր: Այո, մենք ունենք բազմաթիվ ուղիներ ցանցում: Բայց մեկ կոնկրետ TCP կապի TCP երթևեկությունը կշարունակի անցնել նույն կոտրված փաթեթով: Փաթեթների կորուստը, պայմանով, որ մեր կախարդական X11-ը ինքնուրույն դուրս չգա, չի հանգեցնում երթևեկության հոսքի դեպի տարածքներ, որոնք խնդրահարույց չեն: Մենք փորձում ենք փաթեթ առաքել նույն կոտրված կույտի միջոցով: Դա հանգեցնում է կասկադային ձախողման. տվյալների կենտրոնը փոխազդող հավելվածների մի շարք է, և այս բոլոր հավելվածների TCP կապերից մի քանիսը սկսում են վատթարանալ, քանի որ սուպերսպինը ազդում է բոլոր հավելվածների վրա, որոնք գտնվում են DC-ի ներսում: Ինչպես ասվում է՝ եթե ձիուն կոշիկ չես դնում, ձին կաղում է. ձին կաղացել է - հաշվետվությունը չի ներկայացվել. ուղերձը չհասցվեց՝ նրանք պարտվեցին պատերազմում։ Միայն այստեղ հաշվարկն անցնում է վայրկյանների ընթացքում խնդրի առաջացման պահից մինչև դեգրադացիայի այն աստիճանը, որը ծառայությունները սկսում են զգալ: Սա նշանակում է, որ օգտվողները կարող են ինչ-որ տեղ ինչ-որ բան չստանալ:
Կան երկու դասական լուծումներ, որոնք լրացնում են միմյանց. Առաջինը ծառայություններն են, որոնք փորձում են ցողել և լուծել խնդիրը հետևյալ կերպ. Եվ եկեք կիրառենք կիրառման մակարդակի ժամանակի ընդմիջումներ կամ երկարատև TCP նիստեր՝ ներքին առողջության ստուգումներով: Խնդիրն այն է, որ նման լուծումները՝ ա) ընդհանրապես չեն մասշտաբվում. բ) շատ վատ փորձարկված: Այսինքն, նույնիսկ եթե ծառայությունը պատահաբար կարգավորի TCP փաթեթը, որպեսզի այն ավելի լավը դառնա, նախ, դա դժվար թե կիրառելի լինի բոլոր հավելվածների և տվյալների բոլոր կենտրոնների համար, և երկրորդ, ամենայն հավանականությամբ, նա չի հասկանա, թե ինչ է արվել ճիշտ և ինչ: ոչ: Այսինքն՝ աշխատում է, բայց վատ է աշխատում ու չի մասշտաբվում։ Իսկ եթե ցանցի խնդիր կա, ո՞վ է մեղավոր։ Իհարկե ՀԱՕԿ. Ի՞նչ է անում ՀԱՕԿ-ը.
Շատ ծառայություններ կարծում են, որ ԱՕԿ-ում աշխատանքը մոտավորապես այսպես է ընթանում. Բայց անկեղծ ասած, ոչ միայն.
ՀԱՕԿ-ը դասական սխեմայով զբաղվում է բազմաթիվ մոնիտորինգների մշակմամբ: Սրանք և՛ սև արկղի մոնիտորինգն են, և՛ սպիտակ արկղերի մոնիտորինգը: Սև արկղ-ողնաշարի մոնիտորինգի օրինակի մասին Ալեքսանդր Կլիմենկոն անցյալի Next Hop-ի մասին. Ի դեպ, այս մոնիտորինգն աշխատում է։ Բայց նույնիսկ կատարյալ մոնիտորինգը ժամանակային ուշացում կունենա: Սովորաբար դա մի քանի րոպե է: Այն աշխատելուց հետո հերթապահ ինժեներներին ժամանակ է պետք՝ կրկնակի ստուգելու դրա աշխատանքը, տեղայնացնելու խնդիրը, այնուհետև խնդրահարույց տարածքը մարելու համար։ Այսինքն՝ լավագույն դեպքում խնդրի բուժումը տեւում է 5 րոպե, վատագույն դեպքում՝ 20 րոպե, եթե անմիջապես ակնհայտ չէ, թե որտեղ են լինում կորուստները։ Հասկանալի է, որ այս ամբողջ ընթացքում՝ 5 կամ 20 րոպե, մեր ծառայությունները կշարունակեն վնասել, ինչը, հավանաբար, լավ չէ։
Ի՞նչ կցանկանայիք ստանալ: Մենք այնքան շատ ճանապարհներ ունենք: Եվ խնդիրներն առաջանում են հենց այն պատճառով, որ TCP հոսքերը, որոնք անհաջող են, շարունակում են օգտագործել նույն երթուղին: Մեզ պետք է մի բան, որը թույլ կտա մեզ օգտագործել մի քանի երթուղիներ մեկ TCP կապի շրջանակներում: Կարծես թե մենք լուծում ունենք։ Գոյություն ունի TCP, որը կոչվում է այսպես՝ multipath TCP, այսինքն՝ TCP բազմաթիվ ուղիների համար։ Ճիշտ է, այն մշակվել է բոլորովին այլ առաջադրանքի համար՝ մի քանի ցանցային սարքեր ունեցող սմարթֆոնների համար: Փոխանցումն առավելագույնի հասցնելու կամ առաջնային/պահուստային ռեժիմը դարձնելու համար մշակվել է մեխանիզմ, որը թափանցիկորեն ստեղծում է մի քանի թելեր (սեսիաներ) հավելվածի համար և թույլ է տալիս անցնել դրանց միջև ձախողման դեպքում: Կամ, ինչպես ասացի, առավելագույնի հասցնել թողունակությունը:
Բայց այստեղ մի նրբերանգ կա. Հասկանալու համար, թե ինչ է դա, մենք պետք է նայենք, թե ինչպես են ստեղծվում հոսքերը:
Թելերը տեղադրվում են հաջորդաբար: Առաջին հոսքը տեղադրվում է առաջինը: Հետագա հոսքերը այնուհետև սահմանվում են այդ շղթայի շրջանակներում արդեն համաձայնեցված թխուկի միջոցով: Եվ ահա խնդիրը.
Խնդիրն այն է, որ եթե առաջին շարանը չի տեղադրվում, երկրորդ և երրորդ թելերը երբեք չեն առաջանա: Այսինքն, multipath TCP-ն չի լուծում SYN փաթեթի կորուստը առաջին հոսքում։ Եվ եթե SYN-ը կորչում է, բազմուղի TCP-ն դառնում է նորմալ TCP: Այսպիսով, տվյալների կենտրոնի միջավայրում դա մեզ չի օգնի լուծել գործարանում կորուստների խնդիրը և սովորել, թե ինչպես օգտագործել բազմաթիվ ուղիներ ձախողման դեպքում:
Ի՞նչը կարող է օգնել մեզ: Ձեզանից ոմանք արդեն անունից կռահել են, որ մեր հետագա պատմության կարևոր դաշտը կլինի IPv6 հոսքի պիտակի վերնագրի դաշտը: Իրոք, սա դաշտ է, որը հայտնվում է v6-ում, այն չկա v4-ում, այն տեւում է 20 բիթ, և դրա օգտագործման վերաբերյալ վաղուց հակասություններ կան: Սա շատ հետաքրքիր է. վեճեր եղան, ինչ-որ բան շտկվեց RFC-ի շրջանակներում, և միևնույն ժամանակ Linux միջուկում հայտնվեց մի իրականացում, որը երբեք ոչ մի տեղ չփաստաթղթավորվեց:
Առաջարկում եմ միանալ ինձ մի փոքր հետաքննության համար: Եկեք նայենք, թե ինչ է տեղի ունենում Linux միջուկում վերջին մի քանի տարիների ընթացքում:
տարի 2014 թ. Խոշոր և հեղինակավոր ընկերության ինժեները Linux միջուկի ֆունկցիոնալությանը ավելացնում է հոսքի պիտակի արժեքի կախվածությունը վարդակի հեշից: Ի՞նչ են փորձում շտկել այստեղ։ Սա կապված է RFC 6438-ի հետ, որը քննարկել է հետևյալ հարցը. Տվյալների կենտրոնի ներսում IPv4-ը հաճախ պարփակվում է IPv6 փաթեթների մեջ, քանի որ գործարանն ինքնին IPv6 է, բայց IPv4-ը պետք է ինչ-որ կերպ դուրս գա: Երկար ժամանակ խնդիրներ կային անջատիչների հետ, որոնք չէին կարող նայել երկու IP վերնագրերի տակ՝ հասնելու համար TCP կամ UDP և այնտեղ գտնել src_ports, dst_ports: Պարզվեց, որ հեշը, եթե նայեք առաջին երկու IP վերնագրերին, պարզվեց, որ գրեթե ֆիքսված է: Սրանից խուսափելու համար, որպեսզի այս պարփակված երթևեկության հավասարակշռումը ճիշտ աշխատի, առաջարկվեց հոսքի պիտակի դաշտի արժեքին ավելացնել հեշ 5-ակի պարփակված փաթեթից: Մոտավորապես նույնը արվել է այլ encapsulation սխեմաների համար, UDP-ի, GRE-ի համար, վերջինում օգտագործվել է GRE Key դաշտը։ Այսպես թե այնպես, այստեղ նպատակները պարզ են. Եվ գոնե այդ պահին դրանք օգտակար էին:
2015 թվականին նույն հարգված ինժեների կողմից նոր կարկատել է գալիս: Նա շատ հետաքրքիր է։ Այն ասում է հետևյալը. մենք պատահականորեն կկազմակերպենք հեշը բացասական երթուղային իրադարձության դեպքում: Ի՞նչ է բացասական երթուղային իրադարձությունը: Սա RTO-ն է, որը մենք ավելի վաղ քննարկեցինք, այսինքն, պատուհանի պոչի կորուստը իրադարձություն է, որն իսկապես բացասական է: Ճիշտ է, համեմատաբար դժվար է կռահել, թե դա ինչ է։
2016, մեկ այլ հարգված ընկերություն, նույնպես մեծ. Այն վերլուծում է վերջին հենակները և դարձնում այն այնպես, որ այն հեշը, որը մենք նախկինում արել էինք պատահականորեն, այժմ փոխվում է SYN-ի յուրաքանչյուր վերահաղորդման ժամանակ և յուրաքանչյուր RTO ժամանակի ավարտից հետո: Եվ այս նամակում առաջին և վերջին անգամ հնչում է վերջնական նպատակը՝ համոզվել, որ ալիքների կորստի կամ ծանրաբեռնվածության դեպքում երթևեկությունն ունի մեղմ վերափոխման հնարավորություն՝ օգտագործելով բազմաթիվ ուղիներ: Իհարկե, դրանից հետո շատ հրապարակումներ եղան, դրանք հեշտությամբ կարող եք գտնել։
Թեև ոչ, դուք չեք կարող, քանի որ այս թեմայով որևէ հրապարակում չի եղել: Բայց մենք գիտենք!
Եվ եթե դուք լիովին չեք հասկանում, թե ինչ է արվել, ես ձեզ հիմա կասեմ.
Ի՞նչ է արվել, ի՞նչ գործառույթ է ավելացվել Linux միջուկին։ txhash-ը փոխվում է պատահական արժեքի յուրաքանչյուր RTO իրադարձությունից հետո: Սա նույն բացասական երթուղային արդյունքն է: Հեշը կախված է այս txhash-ից, իսկ հոսքի պիտակը կախված է skb հեշից: Այստեղ գործառույթների վերաբերյալ որոշ հաշվարկներ կան, բոլոր մանրամասները չեն կարող տեղադրվել մեկ սլայդի վրա: Եթե որևէ մեկին հետաքրքրում է, կարող եք անցնել միջուկի կոդը և ստուգել:
Ի՞նչն է այստեղ կարևոր: Հոսքի պիտակի դաշտի արժեքը յուրաքանչյուր RTO-ից հետո փոխվում է պատահական թվի: Ինչպե՞ս է դա ազդում մեր անհաջող TCP հոսքի վրա:
SACK-ի դեպքում ոչինչ չի փոխվել, քանի որ մենք փորձում ենք նորից ուղարկել հայտնի կորցրած փաթեթը: Առայժմ ամեն ինչ լավ է:
Բայց RTO-ի դեպքում, պայմանով, որ մենք ավելացրել ենք հոսքի պիտակ ToR-ի հեշ ֆունկցիային, երթևեկությունը կարող է այլ ուղի ունենալ: Եվ որքան շատ ինքնաթիռներ, այնքան ավելի հավանական է գտնել մի ճանապարհ, որը չի ազդի կոնկրետ սարքի վթարի վրա:
Մնում է մեկ խնդիր՝ RTO. Մեկ այլ երթուղի, իհարկե, գտնված է, բայց դրա վրա շատ ժամանակ է ծախսվում։ 200ms-ը շատ է: Երկրորդն ընդհանրապես վայրիություն է: Ավելի վաղ ես խոսեցի ծառայությունները կարգավորող ժամկետների մասին: Այսպիսով, երկրորդը ժամանակի ավարտ է, որը սովորաբար ստեղծում է ծառայություն հավելվածի մակարդակով, և այս դեպքում ծառայությունը նույնիսկ համեմատաբար ճիշտ կլինի: Ավելին, կրկնում եմ, ժամանակակից տվյալների կենտրոնի ներսում իրական RTT-ը մոտ 1 միլիվայրկյան է:
Ի՞նչ կարելի է անել RTO-ի ժամկետների հետ կապված: Տվյալների փաթեթների կորստի դեպքում RTO-ի համար պատասխանատու ժամկետը կարող է համեմատաբար հեշտությամբ կարգավորվել օգտագործողի տարածությունից. կա IP կոմունալ, և դրա պարամետրերից մեկը պարունակում է նույն rto_min: Հաշվի առնելով, որ, իհարկե, անհրաժեշտ է RTO-ն դարձնել ոչ թե գլոբալ, այլ տվյալ նախածանցների համար, նման մեխանիզմը բավականին աշխատունակ է թվում:
Ճիշտ է, SYN_RTO-ի հետ ամեն ինչ մի փոքր ավելի վատ է: Այն բնականաբար մեխված է: Արժեքը ամրագրված է միջուկում՝ 1 վայրկյան, և վերջ։ Դուք չեք կարող դրան հասնել օգտվողի տարածքից: Կա միայն մեկ ճանապարհ.
eBPF-ը գալիս է օգնության: Պարզ ասած, դրանք փոքր C ծրագրեր են: Դրանք կարող են տեղադրվել կեռիկների մեջ միջուկի կույտի և TCP ստեկի կատարման տարբեր վայրերում, որոնցով կարող եք փոխել շատ մեծ թվով կարգավորումներ: Ընդհանուր առմամբ, eBPF-ն երկարաժամկետ միտում է: Տասնյակ նոր sysctl պարամետրեր սղոցելու և IP-ի օգտակարությունը ընդլայնելու փոխարեն, շարժումը eBPF-ի ուղղությամբ է և ընդլայնում է դրա ֆունկցիոնալությունը: eBPF-ի միջոցով դուք կարող եք դինամիկ կերպով փոխել գերբեռնվածության կառավարումը և TCP-ի տարբեր այլ կարգավորումները:
Բայց մեզ համար կարևոր է, որ դրա օգնությամբ դուք կարող եք շրջել SYN_RTO-ի արժեքները: Եվ կա հրապարակայնորեն տեղադրված օրինակ. . Ի՞նչ է արվում այստեղ։ Օրինակը գործում է, բայց ինքնին շատ կոպիտ է։ Այստեղ ենթադրվում է, որ տվյալների կենտրոնի ներսում մենք համեմատում ենք առաջին 44 բիթերը, եթե դրանք համընկնում են, ապա մենք հայտնվում ենք DC-ի ներսում։ Եվ այս դեպքում մենք փոխում ենք SYN_RTO ժամանակի դադարի արժեքը մինչև 4ms: Նույն խնդիրը կարելի է անել շատ ավելի նրբագեղ։ Բայց այս պարզ օրինակը ցույց է տալիս, թե ինչն է ա) հնարավոր. բ) համեմատաբար հեշտ:
Ի՞նչ գիտենք մենք արդեն: Այն, որ հարթ ճարտարապետությունը թույլ է տալիս մասշտաբել, պարզվում է, որ չափազանց օգտակար է մեզ համար, երբ մենք միացնում ենք հոսքի պիտակը ToR-ում և հնարավորություն ենք ստանում հոսել խնդրահարույց տարածքների շուրջ: RTO և SYN-RTO արժեքները նվազեցնելու լավագույն միջոցը eBPF ծրագրերի օգտագործումն է: Հարցը մնում է. անվտանգ է արդյոք օգտագործել հոսքի պիտակը հավասարակշռման համար: Եվ այստեղ մի նրբերանգ կա.
Ենթադրենք, դուք ունեք ծառայություն ցանցում, որն ապրում է anycast-ում: Ցավոք, ես ժամանակ չունեմ anycast-ի մասին մանրամասնելու համար, բայց դա բաշխված ծառայություն է, որտեղ տարբեր ֆիզիկական սերվերներ հասանելի են նույն IP հասցեով: Եվ ահա հնարավոր խնդիր կա. RTO իրադարձությունը կարող է տեղի ունենալ ոչ միայն այն ժամանակ, երբ երթևեկությունն անցնում է գործարանով: Այն կարող է առաջանալ նաև ToR բուֆերային մակարդակում. երբ տեղի է ունենում անուղղակի իրադարձություն, այն կարող է առաջանալ նույնիսկ հյուրընկալողի վրա, երբ հյուրընկալողը ինչ-որ բան է թափում: Երբ տեղի է ունենում RTO իրադարձություն, և այն փոխում է հոսքի պիտակը: Այս դեպքում երթևեկությունը կարող է գնալ ցանկացած այլ օրինակ: Ենթադրենք, որ այն պետական anycast է, այն պարունակում է կապի վիճակ. դա կարող է լինել L3 Balancer կամ որևէ այլ ծառայություն: Հետո խնդիր է առաջանում, քանի որ RTO-ից հետո TCP կապը հասնում է սերվերին, որը ոչինչ չգիտի այս TCP կապի մասին։ Եվ եթե մենք չունենանք պետական փոխանակում anycast սերվերների միջև, ապա այդպիսի տրաֆիկը կթողարկվի և TCP կապը կխզվի:
Ի՞նչ կարելի է անել այստեղ: Ձեր վերահսկվող միջավայրում, որտեղ դուք միացնում եք հոսքի պիտակի հավասարակշռումը, դուք պետք է ֆիքսեք հոսքի պիտակի արժեքը, երբ մուտք գործեք anycast սերվերներ: Ամենահեշտ ձևը դա անելն է նույն eBPF ծրագրի միջոցով: Բայց ահա մի շատ կարևոր կետ. ի՞նչ անել, եթե դուք տվյալների կենտրոնի ցանց չեք աշխատում, բայց հեռահաղորդակցության օպերատոր եք: Սա նաև ձեր խնդիրն է. սկսած Juniper-ի և Arista-ի որոշ տարբերակներից, դրանք լռելյայնորեն ներառում են հոսքի պիտակը հեշ ֆունկցիայի մեջ. Սա կարող է պատճառ դառնալ, որ դուք դադարեցնեք TCP կապերը ձեր ցանցով անցնող օգտվողներից: Հետևաբար, ես խորհուրդ եմ տալիս ստուգել ձեր երթուղիչի կարգավորումները այս վայրում:
Այսպես թե այնպես, ինձ թվում է, որ մենք պատրաստ ենք անցնել փորձերի։
Երբ մենք միացրինք հոսքի պիտակը ToR-ում, պատրաստեցինք գործակալի eBPF-ն, որն այժմ ապրում է հյուրընկալողների վրա, մենք որոշեցինք չսպասել հաջորդ մեծ ձախողմանը, այլ իրականացնել վերահսկվող պայթյուններ: Մենք վերցրեցինք ToR-ը, որն ունի չորս վերին հղում, և կաթիլներ արեցինք դրանցից մեկի վրա: Կանոն գծեցին, ասացին՝ հիմա բոլոր փաթեթները կորցնում ես։ Ինչպես տեսնում եք ձախ կողմում, մենք ունենք մեկ փաթեթի մոնիտորինգ, որն ընկել է մինչև 75%, այսինքն՝ փաթեթների 25%-ը կորչում է: Աջ կողմում ներկայացված են այս ToR-ի հետևում ապրող ծառայությունների գրաֆիկները: Փաստորեն, դրանք դարակի ներսում սերվերների հետ կապերի տրաֆիկի գծապատկերներ են: Ինչպես տեսնում եք, դրանք էլ ավելի են սուզվել։ Ինչո՞ւ են դրանք իջել ավելի ցածր՝ ոչ թե 25%-ով, այլ որոշ դեպքերում՝ 3-4 անգամ։ Եթե TCP կապը անհաջող է, այն շարունակում է փորձել հասնել կոտրված ինտերֆեյսի միջոցով: Սա սրվում է DC-ի ներսում ծառայության բնորոշ վարքագծի պատճառով. մեկ օգտվողի հարցման համար ստեղծվում են N հարցումներ ներքին ծառայություններին, և պատասխանը կուղղվի օգտատիրոջը՝ կա՛մ տվյալների բոլոր աղբյուրները պատասխանելու դեպքում, կա՛մ երբ ժամանակի վերջ է դրվում: հավելվածի մակարդակը, որը դեռ պետք է կազմաձևվի: Այսինքն՝ ամեն ինչ շատ-շատ վատ է։
Հիմա նույն փորձը, բայց հոսքի պիտակը միացված է: Ինչպես տեսնում եք, ձախ կողմում մեր խմբաքանակի մոնիտորինգը խորտակվել է նույն 25%-ով։ Սա բացարձակապես ճիշտ է, քանի որ նա ոչինչ չգիտի վերահաղորդումների մասին, ուղարկում է փաթեթներ և պարզապես հաշվում է առաքված և կորցրած փաթեթների քանակի հարաբերակցությունը:
Իսկ աջ կողմում ծառայությունների ժամանակացույցն է։ Այստեղ դուք չեք գտնի խնդրահարույց հոդերի ազդեցությունը: Այդ նույն միլիվայրկյանների երթևեկությունը հոսում էր խնդրահարույց տարածքից դեպի մնացած երեք վերելակները, որոնց վրա խնդիրը չէր ազդել: Մենք ստացանք ցանց, որն ինքն իրեն բուժում է:
Սա իմ վերջին սլայդն է, ժամանակն է գնահատել: Այժմ, հուսով եմ, դուք գիտեք, թե ինչպես ստեղծել ինքնաբուժվող տվյալների կենտրոնի ցանց: Դուք կարիք չեք ունենա անցնել Linux միջուկի արխիվը և այնտեղ փնտրել հատուկ patches, դուք գիտեք, որ Flow պիտակը լուծում է խնդիրը այս դեպքում, բայց դուք պետք է ուշադիր մոտենաք այս մեխանիզմին: Եվ կրկին շեշտում եմ, որ եթե դու կրող ես, չպետք է օգտագործես flow label-ը որպես հեշ ֆունկցիա, այլապես կխախտես քո օգտատերերի նիստերը։
Ցանցի ինժեներների համար հայեցակարգային փոփոխություն պետք է տեղի ունենա. ցանցը չի սկսվում ToR-ից, ոչ թե ցանցային սարքից, այլ հոսթից: Բավական ցայտուն օրինակն այն է, թե ինչպես ենք մենք օգտագործում eBPF-ն ինչպես RTO-ն փոխելու, այնպես էլ ցանկացած ծառայությունների հոսքի պիտակը ամրագրելու համար:
Հոսքի պիտակի մեխանիկը, անշուշտ, հարմար է վերահսկվող վարչական հատվածում այլ օգտագործման համար: Սա կարող է լինել տվյալների կենտրոնների միջև երթևեկություն, կամ դուք կարող եք օգտագործել այդպիսի մեխանիզմները հատուկ ձևով՝ ելքային թրաֆիկը վերահսկելու համար: Բայց այս մասին կխոսեմ, հուսով եմ, հաջորդ անգամ։ Շատ շնորհակալ եմ ուշադրության համար։
Source: www.habr.com