Ողջույն, ես Կոստյա Կրամլիխն եմ, ես Yandex.Cloud-ում Virtual Private Cloud բաժնի առաջատար ծրագրավորողն եմ: Ես վիրտուալ ցանցային աշխատող եմ, և ինչպես կարող եք կռահել, այս հոդվածում ես կխոսեմ Virtual Private Cloud (VPC) սարքի մասին ընդհանրապես և վիրտուալ ցանցի մասին, մասնավորապես: Եվ դուք նաև կիմանաք, թե ինչու ենք մենք՝ ծառայության մշակողները, կարևորում մեր օգտատերերի արձագանքները: Բայց առաջին հերթին առաջինը:
Ի՞նչ է VPC-ն:
Մեր օրերում կան ծառայությունների տեղակայման մի շարք տարբերակներ: Համոզված եմ, որ ինչ-որ մեկը դեռ սերվերը պահում է ադմինիստրատորի սեղանի տակ, չնայած հուսով եմ, որ նման պատմությունները քիչ են:
Այժմ ծառայությունները փորձում են գնալ դեպի հանրային ամպեր, և հենց այստեղ են նրանք բախվում VPC-ներին: VPC-ն հանրային ամպի մի մասն է, որը կապում է օգտատերերին, ենթակառուցվածքին, հարթակին և այլ հնարավորություններին, որտեղ էլ որ լինեն, մեր Cloud-ում կամ դրանից դուրս: Միևնույն ժամանակ, VPC-ն թույլ է տալիս անհարկի չբացահայտել այդ հնարավորությունները ինտերնետին, դրանք մնում են ձեր մեկուսացված ցանցում:
Ինչպիսի՞ն է վիրտուալ ցանցը արտաքինից:
VPC ասելով մենք առաջին հերթին նկատի ունենք ծածկույթի ցանց և ցանցային ծառայություններ, ինչպիսիք են VPNaaS, NATaas, LBaas և այլն: Եվ այս ամենը աշխատում է անսարքության հանդուրժող ցանցային ենթակառուցվածքի վրա, որն արդեն եղել է: այստեղ՝ Հաբրեում։
Եկեք ավելի սերտ նայենք վիրտուալ ցանցին և դրա սարքին:
Դիտարկենք երկու մատչելիության գոտիներ: Մենք տրամադրում ենք վիրտուալ ցանց՝ այն, ինչ մենք անվանեցինք VPC: Իրականում դա սահմանում է ձեր «գորշ» հասցեների յուրահատկության տարածությունը։ Յուրաքանչյուր վիրտուալ ցանցում դուք լիովին վերահսկում եք այն հասցեների տարածությունը, որոնք կարող եք նշանակել ռեսուրսների հաշվարկման համար:
Ցանցը գլոբալ է: Միևնույն ժամանակ, այն նախագծվում է յուրաքանչյուր հասանելիության գոտիների վրա՝ Subnet կոչվող սուբյեկտի տեսքով: Յուրաքանչյուր ենթացանցին դուք նշանակում եք CIDR՝ 16 կամ ավելի փոքր չափի: Յուրաքանչյուր հասանելիության գոտում կարող է լինել մեկից ավելի այդպիսի միավոր, և նրանց միջև միշտ կա թափանցիկ երթուղի: Սա նշանակում է, որ ձեր բոլոր ռեսուրսները նույն VPC-ի ներսում կարող են «խոսել» միմյանց հետ, նույնիսկ եթե դրանք գտնվում են տարբեր Հասանելիության գոտիներում: «Շփվել» առանց ինտերնետ հասանելիության, մեր ներքին ալիքներով՝ «մտածելով», որ նրանք գտնվում են նույն մասնավոր ցանցում։
Վերևի դիագրամը ցույց է տալիս տիպիկ իրավիճակ. երկու VPC, որոնք հատվում են ինչ-որ տեղ հասցեներում: Երկուսն էլ կարող են լինել ձերը: Օրինակ՝ մեկը զարգացման համար, մյուսը՝ թեստավորման։ Պարզապես կարող են լինել տարբեր օգտվողներ, այս դեպքում դա նշանակություն չունի: Եվ յուրաքանչյուր VPC-ին միացված է մեկ վիրտուալ մեքենա:
Եկեք ավելի վատացնենք սխեման: Դուք կարող եք այնպես անել, որ մեկ վիրտուալ մեքենա խրված լինի միանգամից մի քանի ենթացանցերի մեջ: Եվ ոչ միայն այդպես, այլ տարբեր վիրտուալ ցանցերում։
Միևնույն ժամանակ, եթե Ձեզ անհրաժեշտ է մեքենաները բացահայտել ինտերնետին, դա կարող է արվել API-ի կամ UI-ի միջոցով: Դա անելու համար դուք պետք է կարգավորեք ձեր «մոխրագույն» ներքին հասցեի NAT թարգմանությունը, «սպիտակ»՝ հանրային: Դուք չեք կարող ընտրել «սպիտակ» հասցե, այն նշանակվում է պատահականորեն մեր հասցեների լողավազանից: Հենց որ դադարեք օգտագործել արտաքին IP-ն, այն վերադարձվում է լողավազան: Դուք վճարում եք միայն «սպիտակ» հասցեից օգտվելու ժամանակի համար։
Հնարավոր է նաև սարքին մուտք գործել ինտերնետ՝ օգտագործելով NAT օրինակը: Դուք կարող եք երթևեկությունը ուղղորդել դեպի օրինակ՝ ստատիկ երթուղային աղյուսակի միջոցով: Մենք տրամադրել ենք նման դեպք, քանի որ օգտատերերին երբեմն դա անհրաժեշտ է, և մենք գիտենք դրա մասին։ Համապատասխանաբար, մեր պատկերների կատալոգը պարունակում է հատուկ կազմաձևված NAT պատկեր:
Բայց նույնիսկ երբ կա պատրաստ NAT պատկեր, կարգավորումը կարող է բարդ լինել: Մենք հասկացանք, որ որոշ օգտատերերի համար սա ամենահարմար տարբերակը չէ, ուստի, ի վերջո, մենք հնարավորություն տվեցինք մեկ սեղմումով միացնել NAT-ը ցանկալի ենթացանցին: Այս հատկությունը դեռ փակ նախադիտման հասանելիության մեջ է, որտեղ այն փորձարկվում է համայնքի անդամների օգնությամբ:
Ինչպես է վիրտուալ ցանցը դասավորված ներսից
Ինչպե՞ս է օգտատերը համագործակցում վիրտուալ ցանցի հետ: Վեբը արտաքին տեսք ունի իր API-ով: Օգտագործողը գալիս է API և աշխատում է թիրախային վիճակի հետ: API-ի միջոցով օգտատերը տեսնում է, թե ինչպես պետք է ամեն ինչ դասավորվի և կազմաձևվի, մինչդեռ նա տեսնում է կարգավիճակը, թե որքանով է իրական վիճակը տարբերվում ցանկալիից։ Սա օգտատիրոջ նկարն է։ Ի՞նչ է կատարվում ներսում։
Մենք գրում ենք ցանկալի վիճակը Yandex Database-ում և գնում կարգավորելու մեր VPC-ի տարբեր մասերը: Yandex.Cloud-ի ծածկույթի ցանցը հիմնված է OpenContrail-ի ընտրված բաղադրիչների վրա, որը վերջերս ստացել է վոլֆրամի գործվածք անվանումը: Ցանցային ծառայություններն իրականացվում են մեկ CloudGate հարթակի վրա: CloudGate-ում մենք նաև օգտագործեցինք մի շարք բաց կոդով բաղադրիչներ՝ GoBGP՝ վերահսկման տեղեկատվության մուտք գործելու համար, ինչպես նաև VPP՝ ծրագրային երթուղիչի ներդրման համար, որն աշխատում է DPDK-ի վերևում՝ տվյալների ուղու համար:
Վոլֆրամի գործվածքը հաղորդակցվում է CloudGate-ի հետ GoBGP-ի միջոցով: Պատմում է, թե ինչ է կատարվում ծածկույթի ցանցում: CloudGate-ն, իր հերթին, միացնում է կափարիչ ցանցերը միմյանց և ինտերնետի հետ:
Հիմա տեսնենք, թե ինչպես է վիրտուալ ցանցը լուծում մասշտաբի և հասանելիության խնդիրները։ Դիտարկենք մի պարզ դեպք. Կա մեկ հասանելիության գոտի, և դրանում ստեղծվում են երկու VPC: Մենք տեղադրեցինք վոլֆրամի գործվածքների մեկ օրինակ, և այն ձգում է մի քանի տասնյակ հազար ցանցեր: Ցանցերը շփվում են CloudGate-ի հետ: CloudGate-ը, ինչպես արդեն ասացինք, ապահովում է նրանց կապը միմյանց և ինտերնետի հետ։
Ենթադրենք, ավելացվի երկրորդ հասանելիության գոտին։ Այն պետք է ձախողվի ամբողջովին անկախ առաջինից: Հետևաբար, հասանելիության երկրորդ գոտում մենք պետք է տեղադրենք վոլֆրամի գործվածքների առանձին օրինակ: Սա կլինի առանձին համակարգ, որը կզբաղվի ծածկույթով և քիչ բան գիտի առաջին համակարգի մասին: Եվ տեսանելիությունը, որ մեր վիրտուալ ցանցը գլոբալ է, իրականում ստեղծում է մեր VPC API-ն: Սա նրա խնդիրն է։
VPC1-ը քարտեզագրվում է Հասանելիության գոտու B-ին, եթե առկայության գոտու B-ում կան ռեսուրսներ, որոնք դրված են դեպի VPC1: Եթե VPC2-ից ռեսուրսներ չկան հասանելիության B գոտում, մենք VPC2-ն այս գոտում չենք նյութականացնի: Իր հերթին, քանի որ VPC3-ից ռեսուրսները գոյություն ունեն միայն B գոտում, VPC3-ը գոյություն չունի A գոտում: Ամեն ինչ պարզ է և տրամաբանական:
Եկեք մի փոքր խորանանք և տեսնենք, թե ինչպես է աշխատում Y.Cloud-ում որոշակի հոսթ: Հիմնական բանը, որ ուզում եմ նշել, այն է, որ բոլոր հյուրընկալողները դասավորված են նույն ձևով: Մենք այնպես ենք անում, որ միայն անհրաժեշտ նվազագույն ծառայություններն աշխատեն ապարատային, մնացած բոլորը՝ վիրտուալ մեքենաներով: Մենք կառուցում ենք ավելի բարձր կարգի ծառայություններ՝ հիմնվելով հիմնական ենթակառուցվածքի ծառայությունների վրա, ինչպես նաև օգտագործում ենք Cloud-ը՝ որոշ ինժեներական խնդիրներ լուծելու համար, օրինակ՝ Continuous Integration-ի շրջանակներում:
Եթե մենք նայենք կոնկրետ հոսթին, կարող ենք տեսնել, որ հյուրընկալող ՕՀ-ում գործում են երեք բաղադրիչ.
- Հաշվարկ - մաս, որը պատասխանատու է հոսթի վրա հաշվողական ռեսուրսների բաշխման համար:
- VRouter-ը վոլֆրամի գործվածքի մի մասն է, որը կազմակերպում է ծածկույթ, այսինքն՝ թունելներ է անցկացնում փաթեթները տակդիրի միջով:
- VDisks-ը պահեստավորման վիրտուալացման կտորներ են:
Բացի այդ, ծառայությունները գործարկվում են վիրտուալ մեքենաներում՝ ամպային ենթակառուցվածքի ծառայություններ, հարթակի ծառայություններ և հաճախորդների հնարավորություններ: Հաճախորդների կարողությունները և պլատֆորմի ծառայությունները միշտ անցնում են ծածկույթի վրա VRouter-ի միջոցով:
Ենթակառուցվածքային ծառայությունները կարող են մնալ ծածկույթի մեջ, բայց հիմնականում նրանք ցանկանում են աշխատել ներքևի տակ: ՍՌ-ԻՈՎ-ի օգնությամբ խրված են տակի մեջ։ Փաստորեն, մենք կտրում ենք քարտը վիրտուալ ցանցային քարտերի (վիրտուալ գործառույթներ) և դրանք մղում ենթակառուցվածքի վիրտուալ մեքենաների մեջ, որպեսզի չկորցնենք կատարողականությունը: Օրինակ, նույն CloudGate-ը գործարկվում է որպես այս ենթակառուցվածքի վիրտուալ մեքենաներից մեկը:
Այժմ, երբ մենք նկարագրեցինք վիրտուալ ցանցի գլոբալ խնդիրները և ամպի հիմնական բաղադրիչների կառուցվածքը, եկեք տեսնենք, թե ինչպես են վիրտուալ ցանցի տարբեր մասերը փոխազդում միմյանց հետ:
Մեր համակարգում մենք առանձնացնում ենք երեք շերտ.
- Config Plane - սահմանում է համակարգի թիրախային վիճակը: Սա այն է, ինչ օգտվողը կարգավորում է API-ի միջոցով:
- Control Plane - տրամադրում է օգտագործողի կողմից սահմանված իմաստաբանություն, այսինքն՝ բերում է տվյալների հարթության վիճակին, ինչ նկարագրված է օգտագործողի կողմից Config Plane-ում:
- Տվյալների հարթություն - ուղղակիորեն մշակում է օգտագործողի փաթեթները:
Ինչպես ասացի վերևում, ամեն ինչ սկսվում է նրանից, որ օգտագործողը կամ ներքին հարթակի ծառայությունը գալիս է API և նկարագրում է որոշակի թիրախային վիճակ:
Այս վիճակն անմիջապես գրվում է Yandex Database-ում, վերադարձնում է ասինխրոն գործողության ID-ն API-ի միջոցով և գործարկում է մեր ներքին մեքենան՝ վերադարձնելու այն վիճակը, որը ցանկանում էր օգտատերը: Կազմաձևման առաջադրանքները գնում են դեպի SDN կարգավորիչ և ասում են վոլֆրամի գործվածքին, թե ինչ անել ծածկույթում: Օրինակ, նրանք պահում են նավահանգիստներ, վիրտուալ ցանցեր և այլն:
Config Plane-ը վոլֆրամի գործվածքում ուղարկում է անհրաժեշտ վիճակը կառավարման հարթությանը: Դրա միջոցով Config Plane-ը շփվում է հյուրընկալողների հետ՝ պատմելով, թե կոնկրետ ինչ է պտտվելու նրանց վրա շուտով։
Հիմա եկեք տեսնենք, թե ինչպես է համակարգը նայում տանտերերին: Վիրտուալ մեքենան ունի ցանցային ադապտեր, որը միացված է VRouter-ին: VRouter-ը վոլֆրամի գործվածքների հիմնական մոդուլ է, որը նայում է փաթեթներին: Եթե ինչ-որ փաթեթի համար արդեն հոսք կա, մոդուլը մշակում է այն: Եթե հոսք չկա, մոդուլը կատարում է այսպես կոչված punting, այսինքն՝ ուղարկում է փաթեթ usermod պրոցեսին։ Գործընթացը վերլուծում է փաթեթը և կամ ինքն է արձագանքում դրան, ինչպես DHCP-ն և DNS-ը, կամ ասում է VRouter-ին, թե ինչ անել դրա հետ: Դրանից հետո VRouter-ը կարող է մշակել փաթեթը:
Ավելին, նույն վիրտուալ ցանցի ներսում վիրտուալ մեքենաների միջև երթևեկությունը անցնում է թափանցիկ, այն չի ուղղվում CloudGate-ին: Հոսթերները, որոնց վրա տեղակայված են վիրտուալ մեքենաները, ուղղակիորեն շփվում են միմյանց հետ: Նրանք թունել են անցնում երթևեկությունը և այն փոխանցում են միմյանց համար տակի միջով:
Կառավարման ինքնաթիռները միմյանց հետ շփվում են հասանելիության գոտիների միջև BGP-ի միջոցով, ինչպես մեկ այլ երթուղիչով: Նրանք ասում են, թե որ մեքենաները որտեղ են գտնվում, որպեսզի մի գոտու VM-ները կարողանան ուղղակիորեն շփվել այլ VM-ների հետ:
Իսկ Control Plane-ը շփվում է CloudGate-ի հետ։ Նմանապես, այն հայտնում է, թե որտեղ և որ վիրտուալ մեքենաներ են բարձրացվում, ինչ հասցեներ ունեն: Սա թույլ է տալիս ուղղորդել արտաքին տրաֆիկը և երթևեկությունը հավասարակշռողներից դեպի նրանց:
VPC-ից դուրս եկող տրաֆիկը գալիս է դեպի CloudGate՝ դեպի տվյալների ուղի, որտեղ մեր պլագիններով VPP-ն արագորեն ծամվում է: Այնուհետև երթևեկությունը գործարկվում է դեպի այլ VPC կամ դրսում, դեպի սահմանային երթուղիչներ, որոնք կազմաձևված են հենց CloudGate-ի Control Plane-ի միջոցով:
Մոտ ապագայի պլանները
Եթե վերը նշված ամեն ինչ ամփոփենք մի քանի նախադասությամբ, ապա կարող ենք ասել, որ VPC-ն Yandex.Cloud-ում լուծում է երկու կարևոր խնդիր.
- Ապահովում է մեկուսացում տարբեր հաճախորդների միջև:
- Համատեղում է ռեսուրսները, ենթակառուցվածքը, պլատֆորմի ծառայությունները, այլ ամպերը և ներքին տարածքը մեկ ցանցի մեջ:
Եվ այս խնդիրները լավ լուծելու համար անհրաժեշտ է ապահովել ընդլայնելիություն և սխալների հանդուրժողականություն ներքին ճարտարապետության մակարդակով, ինչը անում է VPC-ն։
Աստիճանաբար VPC-ն գործառույթներ է ձեռք բերում, մենք ներդրում ենք նոր հնարավորություններ, փորձում ենք ինչ-որ բան բարելավել օգտատերերի հարմարության առումով։ Որոշ գաղափարներ հնչում և առաջնահերթություն են ստանում մեր համայնքի անդամների շնորհիվ։
Ներկայումս մենք ունենք մոտ ապագայի պլանների հետևյալ ցանկը.
- VPN-ը որպես ծառայություն.
- Անձնական DNS օրինակները պատկերներ են՝ նախապես կազմաձևված DNS սերվերով վիրտուալ մեքենաների արագ տեղադրման համար:
- DNS որպես ծառայություն:
- Ներքին բեռի հավասարակշռող:
- «Սպիտակ» IP հասցեի ավելացում՝ առանց վիրտուալ մեքենայի վերստեղծման:
Հավասարակշռիչը և արդեն ստեղծված վիրտուալ մեքենայի համար IP հասցեն փոխելու հնարավորությունը օգտատերերի խնդրանքով այս ցանկում էին: Ճիշտն ասած, առանց բացահայտ արձագանքների, մենք այս գործառույթները կստանձնեինք մի փոքր ուշ: Եվ այսպես, մենք արդեն աշխատում ենք հասցեների խնդրի վրա։
Սկզբում «սպիտակ» IP հասցե կարող էր ավելացվել միայն մեքենա ստեղծելիս: Եթե օգտագործողը մոռացել է դա անել, վիրտուալ մեքենան պետք է վերստեղծվեր: Նույնը և անհրաժեշտության դեպքում հեռացնել արտաքին IP-ն: Շուտով հնարավոր կլինի միացնել և անջատել հանրային IP-ն՝ առանց սարքը վերստեղծելու:
Ազատ զգալ արտահայտել ձեր այլ օգտվողներ: Դուք օգնում եք մեզ բարելավել Cloud-ը և ավելի արագ ստանալ կարևոր և օգտակար գործառույթներ:
Source: www.habr.com