Հե՜յ Հաբր։ Ձեր ուշադրությանն եմ ներկայացնում հոդվածի թարգմանությունը «Սպասարկման ցանցի տվյալների հարթություն ընդդեմ կառավարման հարթության» հեղինակ Մեթ Քլայն.

Այս անգամ ես «ուզեցի և թարգմանեցի» ինչպես սպասարկման ցանցի բաղադրիչների, այնպես էլ տվյալների հարթության և կառավարման հարթության նկարագրությունը: Այս նկարագրությունն ինձ թվում էր ամենահասկանալին ու հետաքրքիրը, և ամենակարևորը տանում է դեպի «Արդյո՞ք դա ընդհանրապես անհրաժեշտ է» հասկացությանը:

Քանի որ «Ծառայության ցանցի» գաղափարը գնալով ավելի տարածված է դարձել վերջին երկու տարիների ընթացքում (Բնօրինակ հոդված 10 հոկտեմբերի, 2017 թ.) և տարածության մասնակիցների թիվը մեծացել է, ես տեսել եմ խառնաշփոթի համաչափ աճ ամբողջ աշխարհում: տեխնոլոգիական համայնքը, թե ինչպես կարելի է համեմատել և հակադրել տարբեր լուծումները:

Իրավիճակը լավագույնս ամփոփվում է հուլիսին գրած թվիթերի հետևյալ շարքով.

Ծառայության ցանցի շփոթություն #1. Linkerd ~ = Nginx ~ = Haproxy ~ = Բանագնաց: Նրանցից ոչ մեկը հավասար չէ Իստիոյին։ Իստիոն բոլորովին այլ բան է։ 1 /

Առաջինները պարզապես տվյալների հարթություններ են: Իրենք իրենք ոչինչ չեն անում։ Նրանք պետք է ավելի շատ տրամադրված լինեն։ 2/

Istio-ն կառավարման հարթության օրինակ է, որը կապում է մասերը: Սա ևս մեկ շերտ է: /վերջ

Նախորդ թվիթերում նշվում են մի քանի տարբեր նախագծեր (Linkerd, NGINX, HAProxy, Envoy և Istio), բայց ավելի կարևոր է, որ ներկայացնում են տվյալների հարթության, սպասարկման ցանցի և կառավարման հարթության ընդհանուր հասկացությունները: Այս գրառման մեջ ես մի քայլ հետ կանեմ և կխոսեմ այն ​​մասին, թե ինչ նկատի ունեմ «տվյալների հարթություն» և «կառավարման հարթություն» տերմիններով շատ բարձր մակարդակով, իսկ հետո կխոսեմ այն ​​մասին, թե ինչպես են տերմինները վերաբերում թվիթերում նշված նախագծերին:

Ի՞նչ է իրականում սպասարկման ցանցը:

Նկար 1. Ծառայության ցանցի ակնարկ

Նկար 1 ցույց է տալիս սպասարկման ցանցի հայեցակարգն իր ամենահիմնական մակարդակում: Կան չորս սպասարկման կլաստերներ (AD): Յուրաքանչյուր ծառայության օրինակ կապված է տեղական վստահված սերվերի հետ: Ամբողջ ցանցային տրաֆիկը (HTTP, REST, gRPC, Redis և այլն) մեկ հավելվածի օրինակից փոխանցվում է տեղական վստահված անձի միջոցով համապատասխան արտաքին ծառայությունների կլաստերներին: Այսպիսով, հավելվածի օրինակը տեղյակ չէ ցանցի մասին որպես ամբողջություն և տեղյակ է միայն իր տեղական վստահված անձի մասին: Փաստորեն, բաշխված համակարգի ցանցը հեռացվեց ծառայությունից:

Տվյալների հարթություն

Ծառայությունների ցանցում հավելվածի համար տեղակայված վստահված սերվերը կատարում է հետևյալ առաջադրանքները.

• Ծառայության բացահայտում. Ի՞նչ ծառայություններ/հավելվածներ են հասանելի ձեր դիմումի համար:
• Առողջության ստուգում. Արդյո՞ք ծառայության հայտնաբերման միջոցով վերադարձված ծառայության օրինակները առողջ են և պատրաստ են ընդունելու ցանցային տրաֆիկը: Սա կարող է ներառել և՛ ակտիվ (օրինակ՝ պատասխան/առողջության ստուգում), և՛ պասիվ (օրինակ՝ 3 անընդմեջ 5xx սխալների օգտագործումը որպես ծառայության անառողջ վիճակի ցուցիչ) առողջության ստուգումներ:
• Երթուղիավորում. REST ծառայությունից «/foo»-ի հարցում ստանալիս ծառայության ո՞ր կլաստերին պետք է ուղարկվի հարցումը:
• Բեռների հավասարակշռում. Երթուղավորման ընթացքում ծառայության կլաստեր ընտրելուց հետո ծառայության ո՞ր օրինակին պետք է ուղարկվի հարցումը: Ի՞նչ թայմաութով: Շղթայի անջատման ի՞նչ պարամետրերով: Եթե ​​հարցումը ձախողվի, պե՞տք է արդյոք այն նորից փորձել:
• Նույնականացում և թույլտվություն. Մուտքային հարցումների դեպքում զանգահարող ծառայությունը կարո՞ղ է գաղտնագրորեն նույնականացնել/թույլատրել mTLS-ի կամ որևէ այլ մեխանիզմի միջոցով: Եթե ​​այն ճանաչված է/լիազորված է, թույլատրվու՞մ է ծառայության վրա կանչել պահանջվող գործողությունը (վերջնակետը), թե՞ պետք է վերադարձվի չհաստատված պատասխան:
• Դիտորդելիություն. Յուրաքանչյուր հարցման համար պետք է ստեղծվեն մանրամասն վիճակագրություն, տեղեկամատյաններ/տեղեկամատյաններ և բաշխված հետագծային տվյալներ, որպեսզի օպերատորները կարողանան հասկանալ բաշխված երթևեկության հոսքը և վրիպազերծման խնդիրները, երբ դրանք առաջանան:

Տվյալների հարթությունը պատասխանատու է սպասարկման ցանցի բոլոր նախորդ կետերի համար: Փաստորեն, ծառայության (կողային սայլի) տեղական վստահված անձը տվյալների հարթությունն է: Այլ կերպ ասած, տվյալների հարթությունը պատասխանատու է պայմանականորեն հեռարձակելու, փոխանցելու և վերահսկելու յուրաքանչյուր ցանցային փաթեթ, որն ուղարկվում է ծառայության կամ ծառայության հետ:

Կառավարման ինքնաթիռը

Ցանցի աբստրակցիան, որը տեղական վստահված անձը տրամադրում է տվյալների հարթությունում, կախարդական է(?): Այնուամենայնիվ, ինչպե՞ս վստահված անձը իրականում գիտի «/foo» երթուղու մասին դեպի ծառայություն B: Ինչպե՞ս կարող են օգտագործվել ծառայության հայտնաբերման տվյալները, որոնք լցված են վստահված անձի հարցումներով: Ինչպե՞ս են պարամետրերը կազմաձևվում ծանրաբեռնվածության հավասարակշռման, ժամանակի դադարի, միացման խզման և այլնի համար: Ինչպե՞ս եք տեղադրում հավելվածը՝ օգտագործելով կապույտ/կանաչ մեթոդը կամ երթևեկության նրբագեղ անցման եղանակը: Ո՞վ է կարգավորում ամբողջ համակարգի նույնականացման և թույլտվության կարգավորումները:

Վերոնշյալ բոլոր կետերը գտնվում են սպասարկման ցանցի կառավարման հարթության հսկողության տակ: Վերահսկիչ ինքնաթիռը վերցնում է մեկուսացված քաղաքացիություն չունեցող վստահված անձանց մի շարք և դրանք վերածում բաշխված համակարգի.

Կարծում եմ, որ շատ տեխնոլոգներ տվյալների հարթության և կառավարման հարթության առանձին հասկացությունները շփոթեցնող են համարում այն ​​պատճառով, որ մարդկանց մեծամասնության համար տվյալների հարթությունը ծանոթ է, մինչդեռ կառավարման հարթությունը օտար/անհասկանալի է: Մենք երկար ժամանակ աշխատում ենք ֆիզիկական ցանցային երթուղիչների և անջատիչների հետ: Մենք հասկանում ենք, որ փաթեթները/հարցերը պետք է անցնեն A կետից B կետ, և որ մենք կարող ենք օգտագործել ապարատային և ծրագրային ապահովում՝ դա անելու համար: Ծրագրային ապահովման նոր սերնդի պրոքսիները պարզապես այն գործիքների շքեղ տարբերակներն են, որոնք մենք օգտագործում էինք երկար ժամանակ:

Նկար 2. Մարդկային կառավարման ինքնաթիռ

Այնուամենայնիվ, մենք երկար ժամանակ օգտագործում ենք կառավարման ինքնաթիռներ, չնայած ցանցային օպերատորների մեծամասնությունը կարող է համակարգի այս հատվածը չկապել որևէ տեխնոլոգիական բաղադրիչի հետ: Պատճառը պարզ է.
Այսօր օգտագործվող կառավարման ինքնաթիռների մեծ մասը... մենք ենք.

On Նկար 2 ցույց է տալիս այն, ինչ ես անվանում եմ «Մարդկային հսկողության ինքնաթիռ»: Այս տիպի տեղաբաշխման ժամանակ, որը դեռ շատ տարածված է, հավանաբար կոպիտ մարդկային օպերատորը ստեղծում է ստատիկ կոնֆիգուրացիաներ՝ հնարավոր սկրիպտների միջոցով, և դրանք տեղակայում է ինչ-որ հատուկ գործընթացի միջոցով բոլոր վստահված սերվերների վրա: Այնուհետև վստահված անձինք սկսում են օգտագործել այս կոնֆիգուրացիան և սկսում են մշակել տվյալների հարթությունը՝ օգտագործելով թարմացված կարգավորումները:

Նկար 3. Ընդլայնված սպասարկման ցանցի կառավարման հարթություն

On Նկար 3 ցույց է տալիս սպասարկման ցանցի «ընդլայնված» կառավարման հարթությունը: Այն բաղկացած է հետևյալ մասերից.

• ՄարդըԴեռևս կա մի մարդ (հուսանք՝ ավելի քիչ զայրացած), ով բարձր մակարդակի որոշումներ է կայացնում ամբողջ համակարգի վերաբերյալ որպես ամբողջություն:
• Կառավարման ինքնաթիռի UIՄարդը փոխազդում է որոշ տեսակի օգտատիրոջ միջերեսի հետ՝ համակարգը կառավարելու համար: Սա կարող է լինել վեբ պորտալ, հրամանի տող հավելված (CLI) կամ որևէ այլ ինտերֆեյս: Օգտագործելով ինտերֆեյսը, օպերատորին հասանելի են համակարգի գլոբալ կազմաձևման այնպիսի պարամետրեր, ինչպիսիք են.
  • Տեղակայման հսկողություն, կապույտ/կանաչ և/կամ աստիճանական երթևեկության անցում
  • Նույնականացման և լիազորման ընտրանքներ
  • Երթուղային աղյուսակի բնութագրերը, օրինակ, երբ A հավելվածը տեղեկատվություն է պահանջում «/foo»-ի մասին, թե ինչ է տեղի ունենում
  • Բեռնվածության հավասարակշռիչի կարգավորումները, ինչպիսիք են ժամանակի ընդհատումները, կրկնվող փորձերը, միացումների անջատման կարգավորումները և այլն:
• Աշխատանքային բեռի ժամանակացույցԾառայություններն իրականացվում են ենթակառուցվածքի վրա որոշ տեսակի պլանավորման/նվագավորության համակարգի միջոցով, ինչպիսիք են Kubernetes-ը կամ Nomad-ը: Ժամանակացույցը պատասխանատու է ծառայության բեռնման համար՝ իր տեղական վստահված անձի հետ միասին:
• Ծառայության բացահայտում. Երբ ժամանակացույցը սկսում և դադարեցնում է սպասարկման օրինակները, այն հայտնում է առողջական վիճակի մասին ծառայության հայտնաբերման համակարգին:
• Sidecar պրոքսիի կազմաձևման API-ներ Տեղական պրոքսիները դինամիկ կերպով դուրս են հանում վիճակը համակարգի տարբեր բաղադրիչներից՝ օգտագործելով ի վերջո հետևողական մոդել՝ առանց օպերատորի միջամտության: Ամբողջ համակարգը, որը բաղկացած է ներկայումս գործող բոլոր սպասարկման օրինակներից և տեղական պրոքսի սերվերներից, ի վերջո համախմբվում է մեկ էկոհամակարգի մեջ: Envoy-ի տվյալների համընդհանուր հարթության API-ն օրինակներից մեկն է, թե ինչպես է դա աշխատում գործնականում:

Ըստ էության, կառավարման հարթության նպատակն է սահմանել այն քաղաքականությունը, որն ի վերջո կընդունվի տվյալների հարթության կողմից: Ավելի առաջադեմ կառավարման ինքնաթիռները կհեռացնեն որոշ համակարգերի ավելի շատ մասեր օպերատորից և կպահանջեն ավելի քիչ ձեռքով շահագործում, պայմանով, որ դրանք ճիշտ աշխատեն:...

Տվյալների հարթություն և կառավարման հարթություն: Տվյալների հարթությունն ընդդեմ կառավարման հարթության ամփոփում

• Սպասարկման ցանցի տվյալների հարթությունԱզդում է համակարգի յուրաքանչյուր փաթեթի/հարցումի վրա: Պատասխանատու է դիմումի/ծառայության հայտնաբերման, առողջության ստուգման, երթուղիների, բեռի հավասարակշռման, նույնականացման/լիազորման և դիտարկելիության համար:
• Սպասարկման ցանցի կառավարման ինքնաթիռՏրամադրում է քաղաքականություն և կազմաձևում սպասարկման ցանցում գործող տվյալների բոլոր հարթությունների համար: Չի շոշափում համակարգում առկա որևէ փաթեթ/խնդրանք: Կառավարման հարթությունը բոլոր տվյալների հարթությունները վերածում է բաշխված համակարգի:

Ընթացիկ նախագծի լանդշաֆտը

Հասկանալով վերը նշված բացատրությունը՝ եկեք նայենք սպասարկման ցանցի նախագծի ներկա վիճակին:

• Տվյալների հարթություններLinkerd, NGINX, HAProxy, Envoy, Traefik
• Կառավարման ինքնաթիռներԻստիո, Նելսոն, SmartStack

Փոխանակ վերը նշված լուծումներից յուրաքանչյուրի խորը վերլուծության մեջ մտնելու փոխարեն, ես համառոտ կանդրադառնամ որոշ կետերի, որոնք, իմ կարծիքով, հենց հիմա էկոհամակարգում մեծ շփոթություն են առաջացնում:

Linkerd-ը 2016 թվականի սկզբին ծառայության ցանցի համար նախատեսված տվյալների ինքնաթիռի առաջին վստահված սերվերներից մեկն էր և ֆանտաստիկ աշխատանք է կատարել՝ բարձրացնելով իրազեկությունն ու ուշադրությունը սպասարկման ցանցի դիզայնի մոդելի նկատմամբ: Դրանից մոտ 6 ամիս անց Էնվոյը միացավ Linkerd-ին (չնայած նա Lyft-ի հետ էր 2015 թվականի վերջից): Linkerd-ը և Envoy-ն այն երկու նախագծերն են, որոնք առավել հաճախ հիշատակվում են սպասարկման ցանցերը քննարկելիս:

Istio-ն հայտարարվել է 2017 թվականի մայիսին։ Istio նախագծի նպատակները շատ նման են ընդլայնված կառավարման ինքնաթիռին, որը ցուցադրված է Նկար 3. Istio-ի բանագնացը լռելյայն վստահված անձն է: Այսպիսով, Իստիոն հսկիչ հարթությունն է, իսկ Էնվոյը տվյալների հարթությունն է։ Կարճ ժամանակում Istio-ն մեծ ոգևորություն առաջացրեց, և տվյալների այլ ինքնաթիռներ սկսեցին ինտեգրվել որպես Envoy-ի փոխարինող (և Linkerd-ը և NGINX-ը ցուցադրեցին ինտեգրումը Istio-ի հետ): Այն փաստը, որ տվյալների տարբեր հարթություններ կարող են օգտագործվել նույն կառավարման հարթության մեջ, նշանակում է, որ կառավարման հարթությունը և տվյալների հարթությունը պարտադիր չէ, որ սերտորեն միացված լինեն: API-ն, ինչպիսին է Envoy-ի ընդհանուր տվյալների հարթության API-ն, կարող է կամուրջ ձևավորել համակարգի երկու մասերի միջև:

Nelson-ը և SmartStack-ն օգնում են ավելի պատկերացնել կառավարման հարթության և տվյալների հարթության տարանջատումը: Նելսոնն օգտագործում է Envoy-ը որպես իր վստահված անձ և կառուցում է հուսալի կառավարման հարթություն սպասարկման ցանցի համար՝ հիմնված HashiCorp ստեկի վրա, այսինքն. Քոչվոր և այլն: SmartStack-ը թերեւս առաջինն էր սպասարկման ցանցերի նոր ալիքից: SmartStack-ը կառուցում է կառավարման հարթություն HAProxy-ի կամ NGINX-ի շուրջ՝ ցուցադրելով կառավարման հարթությունը ծառայության ցանցից տվյալների հարթությունից անջատելու ունակությունը:

Ծառայությունների ցանցով միկրոսերվիսային ճարտարապետությունը ավելի ու ավելի մեծ ուշադրություն է գրավում (ճիշտ է), և ավելի ու ավելի շատ նախագծեր և վաճառողներ են սկսում աշխատել այս ուղղությամբ: Առաջիկա մի քանի տարիների ընթացքում մենք կտեսնենք բազմաթիվ նորարարություններ ինչպես տվյալների հարթության, այնպես էլ կառավարման հարթության մեջ, ինչպես նաև տարբեր բաղադրիչների հետագա խառնուրդում: Ի վերջո, միկրոսերվիսային ճարտարապետությունը պետք է դառնա ավելի թափանցիկ և կախարդական (՞) օպերատորի համար։
Հուսանք՝ ավելի ու ավելի քիչ նյարդայնացած:

Հիմնական միջոցներ

• Սպասարկման ցանցը բաղկացած է երկու տարբեր մասերից՝ տվյալների հարթությունից և կառավարման հարթությունից: Երկու բաղադրիչներն էլ պարտադիր են, և առանց դրանց համակարգը չի աշխատի:
• Բոլորը ծանոթ են կառավարման ինքնաթիռին, և այս պահին վերահսկիչ ինքնաթիռը կարող եք լինել դուք:
• Տվյալների բոլոր հարթությունները միմյանց հետ մրցում են առանձնահատկությունների, կատարողականի, կազմաձևման և ընդարձակման հարցում:
• Կառավարման բոլոր ինքնաթիռները միմյանց հետ մրցում են առանձնահատկություններով, կարգավորելիությամբ, ընդարձակելիությամբ և օգտագործման հեշտությամբ:
• Կառավարման մեկ հարթությունը կարող է պարունակել ճիշտ աբստրակցիաներ և API-ներ, որպեսզի կարողանան օգտագործել բազմաթիվ տվյալների հարթություններ:

Source: www.habr.com