Cloud computing-ը գնալով ավելի ու ավելի է թափանցում մեր կյանք, և հավանաբար չկա մի մարդ, ով գոնե մեկ անգամ չօգտվի որևէ ամպային ծառայությունից: Այնուամենայնիվ, թե կոնկրետ ինչ է ամպը և ինչպես է այն աշխատում, քչերը գիտեն նույնիսկ գաղափարի մակարդակով։ 5G-ն արդեն իրականություն է դառնում, և հեռահաղորդակցության ենթակառուցվածքը սկսում է բևեռային լուծումներից անցնել ամպային լուծումների, ինչպես դա արվեց, երբ այն ամբողջությամբ ապարատային լուծումներից անցավ վիրտուալացված «սյուներին»:
Այսօր մենք կխոսենք ամպային ենթակառուցվածքի ներաշխարհի մասին, մասնավորապես կանդրադառնանք ցանցային մասի հիմունքներին:
Ի՞նչ է ամպը: Նույն վիրտուալիզացիան - պրոֆիլի տեսք?
Ավելի քան տրամաբանական հարց. Ոչ, սա վիրտուալացում չէ, չնայած դա հնարավոր չէր անել առանց դրա: Դիտարկենք երկու սահմանումներ.
Cloud computing (այսուհետ՝ Cloud) բաշխված հաշվողական ռեսուրսներին օգտագործողի համար հարմար հասանելիություն ապահովելու մոդել է, որը պետք է տեղակայվի և գործարկվի ըստ պահանջի հնարավորինս նվազագույն ուշացումով և ծառայության մատակարարի համար նվազագույն ծախսերով:
Վիրտուալացում - սա մեկ ֆիզիկական էություն (օրինակ՝ սերվեր) մի քանի վիրտուալների բաժանելու հնարավորություն է՝ դրանով իսկ մեծացնելով ռեսուրսների օգտագործումը (օրինակ, դուք ունեիք 3 սերվեր բեռնված 25-30 տոկոսով, վիրտուալացումից հետո ստանում եք 1 սերվեր բեռնված։ 80-90 տոկոսով): Բնականաբար, վիրտուալացումը խժռում է որոշ ռեսուրսներ. դուք պետք է կերակրեք հիպերվիզորին, սակայն, ինչպես ցույց է տվել պրակտիկան, խաղն արժե մոմը: Վիրտուալիզացիայի իդեալական օրինակ է VMWare-ը, որը հիանալի պատրաստում է վիրտուալ մեքենաներ, կամ օրինակ KVM-ն, որը ես նախընտրում եմ, բայց սա ճաշակի հարց է։
Մենք օգտագործում ենք վիրտուալացում՝ առանց գիտակցելու, և նույնիսկ երկաթյա երթուղիչները արդեն օգտագործում են վիրտուալացում, օրինակ՝ JunOS-ի վերջին տարբերակում օպերացիոն համակարգը տեղադրված է որպես վիրտուալ մեքենա՝ իրական ժամանակի Linux բաշխման վերևում (Wind River 9): Բայց վիրտուալացումը ամպը չէ, բայց ամպը չի կարող գոյություն ունենալ առանց վիրտուալացման:
Վիրտուալիզացիան այն շինանյութերից մեկն է, որի վրա կառուցված է ամպը:
Ամպ ստեղծելը, պարզապես մի քանի հիպերվիզորներ հավաքելով մեկ L2 տիրույթում, ավելացնելով մի քանի yaml playbook-ներ, որոնք ավտոմատ կերպով գրանցում են vlan-ները ինչ-որ Ansible-ի միջոցով և դրա վրա տեղադրելով նվագախմբային համակարգի նման մի բան՝ վիրտուալ մեքենաներ ավտոմատ ստեղծելու համար, չի աշխատի: Դա ավելի ճշգրիտ կլինի, բայց ստացված Ֆրանկենշտեյնը մեզ անհրաժեշտ ամպը չէ, չնայած այն կարող է լինել վերջնական երազանք ուրիշների համար: Ավելին, եթե դուք վերցնում եք նույն Openstack-ը, դա, ըստ էության, դեռ Ֆրանկենշտեյն է, բայց ախ լավ, եկեք առայժմ չխոսենք այդ մասին:
Բայց ես հասկանում եմ, որ վերը ներկայացված սահմանումից լիովին պարզ չէ, թե իրականում ինչ կարելի է անվանել ամպ:
Հետևաբար, NIST-ի (Ստանդարտների և տեխնոլոգիաների ազգային ինստիտուտ) փաստաթուղթը տրամադրում է 5 հիմնական բնութագրերը, որոնք պետք է ունենան ամպային ենթակառուցվածքը.
Ծառայությունների մատուցում ըստ պահանջի: Օգտագործողին պետք է տրամադրվի անվճար մուտք դեպի իրեն հատկացված համակարգչային ռեսուրսները (օրինակ՝ ցանցեր, վիրտուալ սկավառակներ, հիշողություն, պրոցեսորային միջուկներ և այլն), և այդ ռեսուրսները պետք է տրամադրվեն ավտոմատ կերպով, այսինքն՝ առանց ծառայության մատակարարի միջամտության:
Ծառայության լայն հասանելիություն։ Ռեսուրսների հասանելիությունը պետք է ապահովվի ստանդարտ մեխանիզմներով, որոնք թույլ կտան օգտագործել ինչպես ստանդարտ համակարգիչներ, այնպես էլ thin client-ներ և շարժական սարքեր:
Ռեսուրսների համատեղում լողավազանների մեջ: Ռեսուրսային լողավազանները պետք է կարողանան միաժամանակ ռեսուրսներ տրամադրել բազմաթիվ հաճախորդների՝ ապահովելով, որ հաճախորդները մեկուսացված են և զերծ են փոխադարձ ազդեցությունից և ռեսուրսների համար մրցակցությունից: Լողավազաններում ներառված են նաև ցանցեր, ինչը վկայում է համընկնող հասցեների օգտագործման հնարավորության մասին: Լողավազանները պետք է կարողանան մեծանալ ըստ պահանջի: Լողավազանների օգտագործումը հնարավորություն է տալիս ապահովել ռեսուրսների անսարքության հանդուրժողականության և ֆիզիկական և վիրտուալ ռեսուրսների աբստրակցիայի անհրաժեշտ մակարդակը. ծառայության ստացողին պարզապես տրամադրվում է իր պահանջած ռեսուրսների փաթեթը (որտեղ այդ ռեսուրսները գտնվում են ֆիզիկապես, քանի սերվերներ և անջատիչներ - դա կարևոր չէ հաճախորդի համար): Սակայն պետք է հաշվի առնել այն հանգամանքը, որ մատակարարը պետք է ապահովի այդ ռեսուրսների թափանցիկ վերապահում։
Արագ հարմարեցում տարբեր պայմաններին: Ծառայությունները պետք է լինեն ճկուն՝ ռեսուրսների արագ տրամադրում, դրանց վերաբաշխում, հաճախորդի ցանկությամբ ռեսուրսների ավելացում կամ կրճատում, իսկ հաճախորդի կողմից պետք է զգացողություն լինի, որ ամպային ռեսուրսներն անվերջ են: Հասկանալու համար, օրինակ, դուք չեք տեսնում նախազգուշացում, որ Apple iCloud-ում ձեր սկավառակի տարածքի մի մասն անհետացել է, քանի որ սերվերի կոշտ սկավառակը փչացել է, և կրիչներն իսկապես փչանում են: Բացի այդ, ձեր կողմից այս ծառայության հնարավորությունները գրեթե անսահման են՝ ձեզ 2 ՏԲ է անհրաժեշտ՝ խնդիր չկա, դուք վճարել և ստացել եք այն: Նմանատիպ օրինակ կարելի է բերել Google.Drive-ի կամ Yandex.Disk-ի հետ:
Մատուցվող ծառայության չափման հնարավորությունը. Ամպային համակարգերը պետք է ավտոմատ կերպով վերահսկեն և օպտիմիզացնեն սպառված ռեսուրսները, և այդ մեխանիզմները պետք է թափանցիկ լինեն ինչպես օգտագործողի, այնպես էլ ծառայություն մատուցողի համար: Այսինքն, դուք միշտ կարող եք ստուգել, թե որքան ռեսուրսներ եք սպառում դուք և ձեր հաճախորդները:
Արժե հաշվի առնել այն փաստը, որ այս պահանջները հիմնականում պահանջներ են հանրային ամպի համար, ուստի մասնավոր ամպի համար (այսինքն՝ ընկերության ներքին կարիքների համար գործարկված ամպի համար) այս պահանջները կարող են մի փոքր ճշգրտվել: Այնուամենայնիվ, դրանք դեռ պետք է կատարվեն, հակառակ դեպքում մենք չենք ստանա ամպային հաշվարկի բոլոր առավելությունները:
Ինչու՞ մեզ պետք է ամպ:
Այնուամենայնիվ, ցանկացած նոր կամ գոյություն ունեցող տեխնոլոգիա, ցանկացած նոր արձանագրություն ստեղծվում է ինչ-որ բանի համար (լավ, բացի RIP-ng-ից, իհարկե): Արձանագրություն ոչ մեկին պետք չէ պրոտոկոլի համար (լավ, բացի RIP-ng-ից, իհարկե): Տրամաբանական է, որ Cloud-ը ստեղծված է օգտատիրոջը/հաճախորդին ինչ-որ ծառայություն մատուցելու համար։ Մենք բոլորս ծանոթ ենք առնվազն մի քանի ամպային ծառայություններին, օրինակ՝ Dropbox-ին կամ Google.Docs-ին, և ես կարծում եմ, որ մարդկանց մեծամասնությունը հաջողությամբ օգտագործում է դրանք, օրինակ՝ այս հոդվածը գրվել է Google.Docs ամպային ծառայության միջոցով: Բայց մեզ հայտնի ամպային ծառայությունները ամպի հնարավորությունների միայն մի մասն են, ավելի ճիշտ՝ դրանք միայն SaaS տիպի ծառայություն են։ Մենք կարող ենք ամպային ծառայություն տրամադրել երեք եղանակով՝ SaaS, PaaS կամ IaaS տեսքով: Ինչ ծառայություն է ձեզ անհրաժեշտ, կախված է ձեր ցանկություններից և հնարավորություններից:
Դիտարկենք յուրաքանչյուրը հերթականությամբ.
Ծրագրակազմ ՝ որպես ծառայություն (SaaS) հաճախորդին լիարժեք ծառայություն մատուցելու մոդել է, օրինակ՝ Yandex.Mail-ի կամ Gmail-ի նման էլփոստի ծառայություն: Ծառայությունների մատուցման այս մոդելում դուք, որպես հաճախորդ, իրականում ոչինչ չեք անում, բացի ծառայություններից օգտվելուց, այսինքն՝ կարիք չկա մտածել ծառայության ստեղծման, դրա սխալների հանդուրժողականության կամ ավելորդության մասին: Հիմնական բանը ձեր գաղտնաբառը չխախտելն է, մնացածն այս ծառայության մատակարարը կանի ձեզ համար: Ծառայությունների մատակարարի տեսանկյունից նա լիովին պատասխանատու է ամբողջ ծառայության համար՝ սերվերի սարքաշարից և հոսթ օպերացիոն համակարգերից մինչև տվյալների բազայի և ծրագրային ապահովման կարգավորումներ:
Պլատֆորմը որպես ծառայություն (PaaS) — այս մոդելն օգտագործելիս ծառայության մատակարարը հաճախորդին տրամադրում է ծառայության համար նախատեսված աշխատանքային մաս, օրինակ՝ եկեք վերցնենք վեբ սերվերը: Ծառայությունների մատակարարը հաճախորդին տրամադրել է վիրտուալ սերվեր (իրականում ռեսուրսների մի շարք, օրինակ՝ RAM/CPU/Storage/Nets և այլն), և նույնիսկ այս սերվերի վրա տեղադրել է ՕՀ-ն և անհրաժեշտ ծրագրակազմը, այնուամենայնիվ, կոնֆիգուրացիան Այս ամենը կատարվում է հենց հաճախորդի կողմից և ծառայության կատարման համար հաճախորդը պատասխանում է: Ծառայությունների մատակարարը, ինչպես և նախորդ դեպքում, պատասխանատու է ֆիզիկական սարքավորումների, հիպերվիզորների, հենց վիրտուալ մեքենայի, ցանցի հասանելիության և այլնի կատարման համար, սակայն ծառայությունն ինքն այլևս իր պատասխանատվության ոլորտում չէ:
Ենթակառուցվածքը որպես ծառայություն (IaaS) - այս մոտեցումն արդեն ավելի հետաքրքիր է, փաստորեն, ծառայություններ մատուցողը հաճախորդին տրամադրում է ամբողջական վիրտուալացված ենթակառուցվածք, այսինքն՝ ռեսուրսների մի շարք (լողավազան), ինչպիսիք են CPU Cores, RAM, Networks և այլն: Մնացած ամեն ինչ կախված է: հաճախորդը - ինչ է հաճախորդը ցանկանում անել այս ռեսուրսների հետ հատկացված լողավազանի (քվոտայի) շրջանակներում - դա առանձնապես կարևոր չէ մատակարարի համար: Անկախ նրանից, թե հաճախորդը ցանկանում է ստեղծել իր սեփական vEPC-ն կամ նույնիսկ ստեղծել մինի օպերատոր և տրամադրել կապի ծառայություններ, կասկած չկա, դա արեք: Նման սցենարի դեպքում ծառայություն մատուցողը պատասխանատու է ռեսուրսների տրամադրման, դրանց սխալ հանդուրժողականության և հասանելիության, ինչպես նաև ՕՀ-ի համար, որը թույլ է տալիս նրանց միավորել այդ ռեսուրսները և դրանք հասանելի դարձնել հաճախորդին՝ ցանկացած պահի ռեսուրսները մեծացնելու կամ նվազեցնելու ունակությամբ: հաճախորդի խնդրանքով: Հաճախորդն ինքն է կարգավորում բոլոր վիրտուալ մեքենաները և այլ շղարշը ինքնասպասարկման պորտալի և վահանակի միջոցով, ներառյալ ցանցերի կարգավորումը (բացառությամբ արտաքին ցանցերի):
Ի՞նչ է OpenStack-ը:
Բոլոր երեք տարբերակներում ծառայություն մատուցողին անհրաժեշտ է ՕՀ, որը հնարավորություն կտա ստեղծել ամպային ենթակառուցվածք: Փաստորեն, SaaS-ի դեպքում մեկից ավելի ստորաբաժանումներ պատասխանատու են տեխնոլոգիաների ամբողջ փաթեթի համար. կա բաժին, որը պատասխանատու է ենթակառուցվածքի համար, այսինքն՝ այն տրամադրում է IaaS մեկ այլ ստորաբաժանման, այս բաժինը SaaS է տրամադրում հաճախորդին: OpenStack-ը ամպային օպերացիոն համակարգերից մեկն է, որը թույլ է տալիս հավաքել մի շարք անջատիչներ, սերվերներ և պահեստավորման համակարգեր մեկ ռեսուրսային լողավազանի մեջ, բաժանել այս ընդհանուր լողավազանը ենթափողերի (վարձակալների) և այդ ռեսուրսները տրամադրել հաճախորդներին ցանցի միջոցով:
OpenStack ամպային օպերացիոն համակարգ է, որը թույլ է տալիս վերահսկել հաշվողական ռեսուրսների, տվյալների պահպանման և ցանցային ռեսուրսների մեծ լողավազաններ, որոնք տրամադրվում և կառավարվում են API-ի միջոցով՝ օգտագործելով ստանդարտ նույնականացման մեխանիզմներ:
Այլ կերպ ասած, սա անվճար ծրագրային նախագծերի մի շարք է, որը նախատեսված է ստեղծելու ամպային ծառայություններ (և՛ հանրային, և՛ մասնավոր), այսինքն՝ գործիքների մի շարք, որոնք թույլ են տալիս միավորել սերվերը և սարքավորումները փոխարկել ռեսուրսների մեկ լողավազանի մեջ, կառավարել: այս ռեսուրսները՝ ապահովելով սխալների հանդուրժողականության անհրաժեշտ մակարդակ:
Այս նյութը գրելու պահին OpenStack կառուցվածքն ունի հետևյալ տեսքը.
Լուսանկարը վերցված է
OpenStack-ում ներառված բաղադրիչներից յուրաքանչյուրը կատարում է որոշակի գործառույթ: Այս բաշխված ճարտարապետությունը թույլ է տալիս լուծման մեջ ներառել ձեզ անհրաժեշտ ֆունկցիոնալ բաղադրիչների փաթեթը: Այնուամենայնիվ, որոշ բաղադրիչներ արմատային բաղադրիչներ են, և դրանց հեռացումը կհանգեցնի լուծույթի ամբողջական կամ մասնակի անգործության: Այս բաղադրիչները սովորաբար դասակարգվում են որպես.
- Կարգավորման հարթակ — Վեբ վրա հիմնված GUI՝ OpenStack ծառայությունները կառավարելու համար
- Պորտաքար ինքնության կենտրոնացված ծառայություն է, որն ապահովում է նույնականացման և թույլտվության գործառույթներ այլ ծառայությունների համար, ինչպես նաև կառավարում է օգտվողի հավատարմագրերը և նրանց դերերը:
- Նեյտրոնային - ցանցային ծառայություն, որն ապահովում է միացում տարբեր OpenStack ծառայությունների ինտերֆեյսների միջև (ներառյալ ՎՄ-ների միջև կապը և նրանց մուտքն արտաքին աշխարհ)
- Մոխր — ապահովում է մուտք դեպի արգելափակման պահեստ վիրտուալ մեքենաների համար
- Նոր — վիրտուալ մեքենաների կյանքի ցիկլի կառավարում
- Հայացք — վիրտուալ մեքենայի պատկերների և նկարահանումների պահոց
- արագ — ապահովում է մուտք դեպի պահեստավորման օբյեկտ
- Երկարաչափ — ծառայություն, որն ապահովում է հեռաչափությունը հավաքելու և հասանելի և սպառված ռեսուրսները չափելու հնարավորություն
- Շոգ — նվագախմբում՝ հիմնված կաղապարների վրա՝ ռեսուրսների ավտոմատ ստեղծման և տրամադրման համար
Բոլոր նախագծերի ամբողջական ցանկը և դրանց նպատակը կարելի է դիտել .
OpenStack-ի յուրաքանչյուր բաղադրիչ ծառայություն է, որն իրականացնում է որոշակի գործառույթ և ապահովում է API՝ այդ գործառույթը կառավարելու և այլ ամպային օպերացիոն համակարգի ծառայությունների հետ միասնական ենթակառուցվածք ստեղծելու համար: Օրինակ՝ Nova-ն տրամադրում է հաշվողական ռեսուրսների կառավարում և API՝ այս ռեսուրսները կարգավորելու համար, Glance-ը տրամադրում է պատկերների կառավարում և API՝ դրանք կառավարելու համար, Cinder-ն ապահովում է բլոկների պահեստավորում և API՝ այն կառավարելու համար և այլն: Բոլոր գործառույթները փոխկապակցված են շատ սերտ ձևով:
Այնուամենայնիվ, եթե նայեք դրան, ապա OpenStack-ում աշխատող բոլոր ծառայությունները, ի վերջո, ինչ-որ վիրտուալ մեքենա (կամ կոնտեյներ) են միացված ցանցին: Հարց է առաջանում՝ ինչո՞ւ են մեզ այդքան շատ տարրեր պետք։
Եկեք անցնենք վիրտուալ մեքենա ստեղծելու և այն ցանցին միացնելու և Openstack-ում մշտական պահպանման ալգորիթմով:
- Երբ դուք ստեղծում եք մեքենա ստեղծելու հարցում, լինի դա հարցում Horizon-ի (վահանակի) միջոցով, թե հարցումը CLI-ի միջոցով, առաջին բանը, որ տեղի է ունենում, ձեր հարցման թույլտվությունն է Keystone-ում. կարո՞ղ եք ստեղծել մեքենա, ունի՞ արդյոք այն: այս ցանցից օգտվելու իրավունքը, ձեր քվոտայի նախագիծը և այլն:
- Keystone-ը վավերացնում է ձեր հարցումը և պատասխան հաղորդագրության մեջ ստեղծում է վավերացման նշան, որը հետագայում կօգտագործվի: Ստանալով պատասխան Keystone-ից՝ հարցումն ուղարկվում է դեպի Nova (nova api):
- Nova-api-ն ստուգում է ձեր հարցման վավերականությունը՝ կապվելով Keystone-ի հետ՝ օգտագործելով նախկինում գեներացված վավերացման նշանը
- Keystone-ն իրականացնում է նույնականացում և տրամադրում է տեղեկատվություն թույլտվությունների և սահմանափակումների վերաբերյալ՝ հիմնված այս վավերացման նշանի վրա:
- Nova-api-ն նոր VM-ի համար մուտք է ստեղծում nova-database-ում և մեքենայի ստեղծման հարցումը փոխանցում է nova-scheduler-ին:
- Nova-scheduler-ը ընտրում է այն հոսթը (համակարգչային հանգույցը), որի վրա կտեղակայվի VM-ը՝ հիմնվելով նշված պարամետրերի, կշիռների և գոտիների վրա: Այս մասին գրառումը և VM ID-ն գրված են nova-database-ում:
- Այնուհետև, nova-scheduler-ը կապվում է nova-compute-ի հետ՝ օրինակ տեղակայելու խնդրանքով: Nova-compute-ը կապվում է nova-դիրիժորի հետ՝ մեքենայի պարամետրերի մասին տեղեկատվություն ստանալու համար (nova-conductor-ը nova տարր է, որը գործում է որպես proxy-սերվեր nova-database-ի և nova-compute-ի միջև՝ սահմանափակելով հարցումների քանակը դեպի nova-database՝ տվյալների բազայի հետ կապված խնդիրներից խուսափելու համար։ հետևողականության բեռի նվազեցում):
- Nova-դիրիժորը ստանում է պահանջվող տեղեկատվությունը nova-database-ից և փոխանցում այն nova-compute-ին:
- Հաջորդը, nova-compute զանգերը մի հայացք նետեք՝ պատկերի ID-ն ստանալու համար: Glace-ը վավերացնում է հարցումը Keystone-ում և վերադարձնում պահանջվող տեղեկատվությունը:
- Nova-comput-ը կապում է նեյտրոնի հետ ցանցի պարամետրերի մասին տեղեկատվություն ստանալու համար: Ինչպես հայացքից, նեյտրոնը վավերացնում է հարցումը Keystone-ում, որից հետո ստեղծում է մուտք տվյալների բազայում (պորտի նույնացուցիչը և այլն), ստեղծում է հարցում՝ պորտ ստեղծելու համար և վերադարձնում է պահանջվող տեղեկատվությունը nova-compute-ին։
- Nova-comput կոնտակտները այրվում են վիրտուալ մեքենային ծավալ հատկացնելու խնդրանքով: Հայացքի նման, սիդրը վավերացնում է հարցումը Keystone-ում, ստեղծում է ծավալի ստեղծման հարցում և վերադարձնում պահանջվող տեղեկատվությունը:
- Nova-compute կոնտակտները libvirt են՝ նշված պարամետրերով վիրտուալ մեքենա տեղակայելու խնդրանքով:
Իրականում, պարզ թվացող վիրտուալ մեքենայի ստեղծման պարզ գործողությունը վերածվում է API-ի զանգերի նման հորձանուտի ամպային հարթակի տարրերի միջև: Ավելին, ինչպես տեսնում եք, նույնիսկ նախկինում նշանակված ծառայությունները նույնպես բաղկացած են ավելի փոքր բաղադրիչներից, որոնց միջև տեղի է ունենում փոխազդեցություն: Մեքենայի ստեղծումը միայն մի փոքր մասն է այն ամենի, ինչ թույլ է տալիս ամպային հարթակը. կա ծառայություն, որը պատասխանատու է տրաֆիկի հավասարակշռման համար, ծառայություն, որը պատասխանատու է բլոկների պահպանման համար, ծառայություն, որը պատասխանատու է DNS-ի համար, ծառայություն, որը պատասխանատու է մերկ մետաղական սերվերների տրամադրման համար և այլն: Ամպը թույլ է տալիս, որ ձեր վիրտուալ մեքենաներին վերաբերվեք ոչխարների հոտի պես (ի տարբերություն վիրտուալացման): Եթե ձեր մեքենայի հետ ինչ-որ բան պատահի վիրտուալ միջավայրում, դուք վերականգնում եք այն կրկնօրինակներից և այլն, բայց ամպային հավելվածները կառուցված են այնպես, որ վիրտուալ մեքենան այդքան կարևոր դեր չի խաղում. վիրտուալ մեքենան «մահացել է», խնդիր չկա: - Նորը նոր է ստեղծվել, մեքենան հիմնված է կաղապարի վրա և, ինչպես ասում են, ջոկատը չի նկատել կործանիչի կորուստը։ Բնականաբար, սա նախատեսում է նվագախմբային մեխանիզմների առկայություն. օգտագործելով Heat կաղապարները, դուք հեշտությամբ կարող եք տեղակայել բարդ գործառույթ, որը բաղկացած է տասնյակ ցանցերից և վիրտուալ մեքենաներից:
Միշտ արժե նկատի ունենալ, որ առանց ցանցի չկա ամպային ենթակառուցվածք. յուրաքանչյուր տարր այս կամ այն կերպ փոխազդում է այլ տարրերի հետ ցանցի միջոցով: Բացի այդ, ամպը բացարձակապես ոչ ստատիկ ցանց ունի։ Բնականաբար, ներքևի ցանցը նույնիսկ քիչ թե շատ ստատիկ է. նոր հանգույցներ և անջատիչներ չեն ավելացվում ամեն օր, բայց ծածկույթի բաղադրիչը կարող է և անխուսափելիորեն փոխվելու է անընդհատ. նոր ցանցեր կավելացվեն կամ ջնջվեն, նոր վիրտուալ մեքենաներ կհայտնվեն, իսկ հները մեռնել. Եվ ինչպես հիշում եք հոդվածի հենց սկզբում տրված ամպի սահմանումից, ռեսուրսները պետք է օգտագործողին հատկացվեն ավտոմատ կերպով և ծառայության մատակարարի նվազագույն (կամ ավելի լավ է, առանց) միջամտության: Այսինքն, ցանցային ռեսուրսների տրամադրման տեսակը, որն այժմ գոյություն ունի ճակատային մասի տեսքով, ձեր անձնական հաշվի տեսքով, որը հասանելի է http/https-ի և հերթապահ ցանցային ինժեներ Վասիլիի, որպես հետին պլան, ամպ չէ, նույնիսկ եթե Վասիլին ութ ձեռք ունի.
Նեյտրոնը, որպես ցանցային ծառայություն, տրամադրում է API՝ ամպային ենթակառուցվածքի ցանցային հատվածը կառավարելու համար: Ծառայությունը հզորացնում և կառավարում է Openstack-ի ցանցային մասը՝ ապահովելով աբստրակցիոն շերտ, որը կոչվում է Network-as-a-service (NaaS): Այսինքն, ցանցը նույն վիրտուալ չափելի միավորն է, ինչպիսին, օրինակ, վիրտուալ պրոցեսորի միջուկները կամ RAM-ի քանակը:
Բայց նախքան OpenStack-ի ցանցային մասի ճարտարապետությանը անցնելը, եկեք դիտարկենք, թե ինչպես է այս ցանցը աշխատում OpenStack-ում և ինչու է ցանցը ամպի կարևոր և անբաժանելի մաս:
Այսպիսով, մենք ունենք երկու RED հաճախորդի VM և երկու GREEN հաճախորդի VM: Ենթադրենք, որ այս մեքենաները տեղակայված են երկու հիպերվիզորների վրա այսպես.
Այս պահին սա ընդամենը 4 սերվերի վիրտուալացում է և ոչ ավելին, քանի որ մինչ այժմ մենք ընդամենը 4 սերվերի վիրտուալացում ենք արել՝ դրանք տեղադրելով երկու ֆիզիկական սերվերների վրա։ Իսկ մինչ այժմ նրանք նույնիսկ միացված չեն ցանցին։
Ամպ ստեղծելու համար մենք պետք է մի քանի բաղադրիչ ավելացնենք։ Նախ, մենք վիրտուալացնում ենք ցանցի մասը. մենք պետք է միացնենք այս 4 մեքենաները զույգերով, և հաճախորդները ցանկանում են L2 կապ: Դուք կարող եք օգտագործել անջատիչ և կարգավորել բեռնախցիկը իր ուղղությամբ և լուծել ամեն ինչ՝ օգտագործելով linux կամուրջ կամ, ավելի առաջադեմ օգտվողների համար, openvswitch (մենք կանդրադառնանք դրան ավելի ուշ): Բայց կարող են լինել շատ ցանցեր, և L2-ի անջատիչի միջով անընդհատ մղելը լավագույն գաղափարը չէ. կան տարբեր բաժիններ, սպասարկման սեղան, դիմումի ավարտին սպասելու ամիսներ, անսարքությունների վերացման շաբաթներ. ժամանակակից աշխարհում սա մոտեցումն այլևս չի աշխատում. Եվ որքան շուտ ընկերությունը հասկանա դա, այնքան ավելի հեշտ է առաջ շարժվել: Հետևաբար, հիպերվիզորների միջև մենք կընտրենք L3 ցանց, որի միջոցով մեր վիրտուալ մեքենաները կշփվեն, և այս L3 ցանցի վերևում մենք կկառուցենք վիրտուալ L2 ցանցեր, որտեղ կաշխատի մեր վիրտուալ մեքենաների տրաֆիկը: Դուք կարող եք օգտագործել GRE, Geneve կամ VxLAN որպես encapsulation: Առայժմ կենտրոնանանք վերջինիս վրա, թեև դա առանձնապես կարևոր չէ։
Մենք պետք է ինչ-որ տեղ գտնենք VTEP-ը (հուսով եմ, որ բոլորը ծանոթ են VxLAN տերմինաբանությանը): Քանի որ մենք ունենք L3 ցանց, որը գալիս է անմիջապես սերվերներից, ոչինչ չի խանգարում մեզ տեղադրել VTEP-ը հենց սերվերների վրա, և OVS-ը (OpenvSwitch) հիանալի է դա անում: Արդյունքում մենք ստացանք այս դիզայնը.
Քանի որ VM-ների միջև տրաֆիկը պետք է բաժանվի, վիրտուալ մեքենաների պորտերը կունենան տարբեր vlan համարներ: Պիտակի համարը դեր է խաղում միայն մեկ վիրտուալ փոխարկիչում, քանի որ VxLAN-ում պարփակվելիս մենք կարող ենք հեշտությամբ հեռացնել այն, քանի որ կունենանք VNI:
Այժմ մենք կարող ենք ստեղծել մեր մեքենաներն ու վիրտուալ ցանցերը նրանց համար առանց որևէ խնդիրների:
Այնուամենայնիվ, ի՞նչ անել, եթե հաճախորդն ունի այլ մեքենա, բայց գտնվում է այլ ցանցում: Մեզ անհրաժեշտ է արմատավորում ցանցերի միջև: Մենք կանդրադառնանք մի պարզ տարբերակի, երբ օգտագործվում է կենտրոնացված երթուղում, այսինքն՝ երթևեկությունը ուղղորդվում է հատուկ հատուկ ցանցային հանգույցների միջոցով (լավ, որպես կանոն, դրանք համակցված են կառավարման հանգույցների հետ, ուստի մենք կունենանք նույնը):
Թվում է, թե ոչ մի բարդ բան չկա. մենք ստեղծում ենք կամուրջ ինտերֆեյս կառավարման հանգույցի վրա, տեղափոխում ենք երթևեկությունը դեպի այն և այնտեղից այն ուղղորդում ենք այնտեղ, որտեղ մեզ անհրաժեշտ է: Բայց խնդիրն այն է, որ RED հաճախորդը ցանկանում է օգտագործել 10.0.0.0/24 ցանցը, իսկ GREEN հաճախորդը ցանկանում է օգտագործել 10.0.0.0/24 ցանցը: Այսինքն՝ մենք սկսում ենք հատել հասցեների տարածությունները։ Բացի այդ, հաճախորդները չեն ցանկանում, որ այլ հաճախորդները կարողանան երթուղի անցնել իրենց ներքին ցանցեր, ինչը իմաստ ունի: Ցանցերը և հաճախորդի տվյալների տրաֆիկը բաժանելու համար մենք նրանցից յուրաքանչյուրի համար կհատկացնենք առանձին անվանատարածք: Անվանատարածքը իրականում Linux ցանցի կույտի պատճենն է, այսինքն՝ RED անվանատարածքի հաճախորդները լիովին մեկուսացված են հաճախորդներից GREEN անվանումների տարածքից (լավ, կամ այս հաճախորդի ցանցերի միջև երթուղին թույլատրվում է լռելյայն անվանատարածքի կամ վերին հոսքի տրանսպորտային սարքավորումների միջոցով):
Այսինքն, մենք ստանում ենք հետևյալ դիագրամը.
L2 թունելները զուգակցվում են բոլոր հաշվողական հանգույցներից դեպի կառավարման հանգույց: հանգույց, որտեղ տեղակայված է այս ցանցերի L3 ինտերֆեյսը, յուրաքանչյուրը առանձնացված անվանատարածքում:
Այնուամենայնիվ, մենք մոռացել ենք ամենակարեւորը. Վիրտուալ մեքենան պետք է ծառայություն մատուցի հաճախորդին, այսինքն՝ այն պետք է ունենա առնվազն մեկ արտաքին ինտերֆեյս, որի միջոցով կարելի է հասնել նրան։ Այսինքն՝ մենք պետք է դուրս գանք արտաքին աշխարհ։ Այստեղ կան տարբեր տարբերակներ: Եկեք կատարենք ամենապարզ տարբերակը. Մենք յուրաքանչյուր հաճախորդին կավելացնենք մեկ ցանց, որը վավեր կլինի մատակարարի ցանցում և չի համընկնի այլ ցանցերի հետ: Ցանցերը կարող են նաև հատվել և դիտել տարբեր VRF-ներ մատակարարի ցանցի կողմից: Ցանցի տվյալները նույնպես կբնակվեն յուրաքանչյուր հաճախորդի անվանատարածքում: Այնուամենայնիվ, նրանք դեռ դուրս կգան արտաքին աշխարհ մեկ ֆիզիկական (կամ կապի, որն ավելի տրամաբանական է) ինտերֆեյսի միջոցով: Հաճախորդի տրաֆիկը բաժանելու համար դրսում ընթացող երթևեկությունը պիտակավորվելու է հաճախորդին հատկացված VLAN պիտակով:
Արդյունքում ստացանք այս դիագրամը.
Խելամիտ հարց է առաջանում, թե ինչու չստեղծել դարպասներ հաշվողական հանգույցների վրա: Սա մեծ խնդիր չէ, ավելին, եթե դուք միացնեք բաշխված երթուղիչը (DVR), դա կաշխատի: Այս սցենարում մենք դիտարկում ենք ամենապարզ տարբերակը կենտրոնացված դարպասով, որը լռելյայն օգտագործվում է Openstack-ում: Բարձր բեռնվածության գործառույթների համար նրանք կօգտագործեն ինչպես բաշխված երթուղիչ, այնպես էլ արագացման տեխնոլոգիաներ, ինչպիսիք են SR-IOV-ը և Passthrough-ը, բայց, ինչպես ասում են, դա բոլորովին այլ պատմություն է: Նախ, եկեք զբաղվենք հիմնական մասով, այնուհետև կանդրադառնանք մանրամասներին:
Իրականում, մեր սխեման արդեն կիրառելի է, բայց կան մի քանի նրբերանգներ.
- Մենք պետք է ինչ-որ կերպ պաշտպանենք մեր մեքենաները, այսինքն՝ ֆիլտր դնենք անջատիչի ինտերֆեյսի վրա դեպի հաճախորդը:
- Հնարավորություն տվեք վիրտուալ մեքենային ավտոմատ կերպով ստանալ IP հասցե, այնպես որ դուք ստիպված չլինեք ամեն անգամ մուտք գործել դրա մեջ վահանակի միջոցով և գրանցել հասցեն:
Սկսենք մեքենաների պաշտպանությունից: Դրա համար դուք կարող եք օգտագործել banal iptables, ինչու ոչ:
Այսինքն, այժմ մեր տոպոլոգիան մի փոքր ավելի բարդ է դարձել.
Անցնենք առաջ։ Մենք պետք է ավելացնենք DHCP սերվեր: Յուրաքանչյուր հաճախորդի համար DHCP սերվերներ գտնելու ամենաիդեալական վայրը կլինի արդեն վերը նշված կառավարման հանգույցը, որտեղ գտնվում են անունների տարածքները.
Այնուամենայնիվ, կա մի փոքր խնդիր. Ինչ անել, եթե ամեն ինչ վերագործարկվի, և DHCP-ում հասցեներ վարձակալելու մասին բոլոր տեղեկությունները անհետանան: Տրամաբանական է, որ մեքենաներին կտրվեն նոր հասցեներ, ինչը այնքան էլ հարմար չէ։ Այստեղ երկու ելք կա. կամ օգտագործեք տիրույթի անուններ և ավելացրեք DNS սերվեր յուրաքանչյուր հաճախորդի համար, այնուհետև հասցեն մեզ համար առանձնապես կարևոր չի լինի (նման է k8s-ի ցանցային մասին), բայց արտաքին ցանցերի հետ կապված խնդիր կա, քանի որ Դրանցում հասցեները կարող են տրվել նաև DHCP-ի միջոցով. ձեզ հարկավոր է համաժամացում DNS սերվերների հետ ամպային հարթակում և արտաքին DNS սերվերի հետ, ինչը, իմ կարծիքով, այնքան էլ ճկուն չէ, բայց միանգամայն հնարավոր է: Կամ երկրորդ տարբերակը մետատվյալների օգտագործումն է, այսինքն՝ պահպանել մեքենային տրված հասցեի մասին տեղեկատվությունը, որպեսզի DHCP սերվերն իմանա, թե որ հասցեն պետք է տրամադրի մեքենային, եթե մեքենան արդեն հասցե է ստացել: Երկրորդ տարբերակն ավելի պարզ ու ճկուն է, քանի որ թույլ է տալիս լրացուցիչ տեղեկություններ պահպանել մեքենայի մասին։ Այժմ դիագրամում ավելացնենք գործակալի մետատվյալները.
Մեկ այլ խնդիր, որը նույնպես արժե քննարկել, բոլոր հաճախորդների կողմից մեկ արտաքին ցանց օգտագործելու հնարավորությունն է, քանի որ արտաքին ցանցերը, եթե դրանք պետք է վավեր լինեն ամբողջ ցանցում, ապա բարդություն կլինի. անհրաժեշտ է անընդհատ բաշխել և վերահսկել բաշխումը: այս ցանցերը։ Բոլոր հաճախորդների համար մեկ արտաքին նախապես կազմաձևված ցանց օգտագործելու հնարավորությունը շատ օգտակար կլինի հանրային ամպ ստեղծելիս: Սա կհեշտացնի մեքենաների տեղակայումը, քանի որ մենք կարիք չունենք խորհրդակցելու հասցեների տվյալների բազայի հետ և յուրաքանչյուր հաճախորդի արտաքին ցանցի համար ընտրելու եզակի հասցեի տարածք: Բացի այդ, մենք կարող ենք նախապես գրանցել արտաքին ցանց, և տեղակայման պահին մեզ միայն անհրաժեշտ կլինի արտաքին հասցեները կապել հաճախորդի մեքենաների հետ:
Եվ ահա NAT-ը գալիս է մեզ օգնության. մենք պարզապես հնարավորություն կտանք հաճախորդներին մուտք գործել արտաքին աշխարհ լռելյայն անվանատարածքի միջոցով՝ օգտագործելով NAT թարգմանությունը: Դե, ահա մի փոքր խնդիր. Սա լավ է, եթե հաճախորդի սերվերը գործում է որպես հաճախորդ և ոչ թե որպես սերվեր, այսինքն՝ այն նախաձեռնում է, այլ ոչ թե ընդունում կապերը: Բայց մեզ համար հակառակը կլինի։ Այս դեպքում մենք պետք է կատարենք նպատակակետ NAT, որպեսզի երթևեկությունը ստանալիս կառավարման հանգույցը հասկանա, որ այս տրաֆիկը նախատեսված է A հաճախորդի վիրտուալ մեքենայի համար, ինչը նշանակում է, որ մենք պետք է կատարենք NAT թարգմանություն արտաքին հասցեից, օրինակ՝ 100.1.1.1: .10.0.0.1, ներքին հասցեով 100. Այս դեպքում, չնայած բոլոր հաճախորդները կօգտագործեն նույն ցանցը, ներքին մեկուսացումը լիովին պահպանված է: Այսինքն, մենք պետք է անենք dNAT և sNAT կառավարման հանգույցի վրա: Լողացող հասցեներով կամ արտաքին ցանցերով մեկ ցանց օգտագործելը, թե երկուսն էլ միանգամից, կախված է նրանից, թե ինչ եք ուզում ներդնել ամպի մեջ: Մենք դիագրամում չենք ավելացնի լողացող հասցեներ, այլ կթողնենք ավելի վաղ ավելացված արտաքին ցանցերը. յուրաքանչյուր հաճախորդ ունի իր արտաքին ցանցը (դիագրամում դրանք նշված են որպես vlan 200 և XNUMX արտաքին ինտերֆեյսի վրա):
Արդյունքում ստացանք հետաքրքիր և միևնույն ժամանակ մտածված լուծում, որն ունի որոշակի ճկունություն, բայց դեռևս չունի սխալների հանդուրժողականության մեխանիզմներ։
Նախ, մենք ունենք միայն մեկ կառավարման հանգույց. դրա ձախողումը կհանգեցնի բոլոր համակարգերի փլուզմանը: Այս խնդիրը շտկելու համար դուք պետք է կազմեք առնվազն 3 հանգույցների քվորում: Դիագրամին ավելացնենք սա.
Բնականաբար, բոլոր հանգույցները սինխրոնիզացված են, և երբ ակտիվ հանգույցը հեռանում է, մեկ այլ հանգույց կստանձնի նրա պարտականությունները:
Հաջորդ խնդիրը վիրտուալ մեքենայի սկավառակներն են: Այս պահին դրանք պահվում են հենց հիպերվիզորների վրա, և հիպերվիզորի հետ կապված խնդիրների դեպքում մենք կորցնում ենք բոլոր տվյալները, և ռեյդի առկայությունը այստեղ չի օգնի, եթե մենք կորցնենք ոչ թե սկավառակը, այլ ամբողջ սերվերը: Դա անելու համար մենք պետք է ստեղծենք ծառայություն, որը կգործի որպես առաջնամաս որոշակի պահեստավորման համար: Թե ինչպիսի պահեստավորում կլինի դա, մեզ համար առանձնապես կարևոր չէ, բայց այն պետք է պաշտպանի մեր տվյալները ինչպես սկավառակի, այնպես էլ հանգույցի և, հնարավոր է, ամբողջ կաբինետի ձախողումից: Այստեղ կան մի քանի տարբերակներ. կան, իհարկե, SAN ցանցեր Fiber Channel-ով, բայց եկեք անկեղծ լինենք, FC-ն արդեն անցյալի մասունք է, տրանսպորտում E1-ի անալոգը, այո, համաձայն եմ, այն դեռ օգտագործվում է, բայց միայն այնտեղ, որտեղ դա բացարձակապես անհնար է առանց դրա: Հետևաբար, ես 2020 թվականին կամավոր չէի տեղադրի FC ցանց՝ իմանալով, որ կան այլ ավելի հետաքրքիր այլընտրանքներ: Թեև յուրաքանչյուրի համար կարող են լինել այնպիսիք, ովքեր հավատում են, որ ՖԱ-ն իր բոլոր սահմանափակումներով այն ամենն է, ինչ մեզ պետք է, ես չեմ վիճելու, յուրաքանչյուրն ունի իր կարծիքը: Այնուամենայնիվ, իմ կարծիքով ամենահետաքրքիր լուծումը SDS-ի օգտագործումն է, ինչպիսին Ceph-ն է:
Ceph-ը թույլ է տալիս ստեղծել տվյալների պահպանման բարձր հասանելի լուծում մի շարք հնարավոր պահուստային տարբերակներով, սկսած կոդերից՝ հավասարության ստուգմամբ (որը նման է ռեյդ 5-ին կամ 6-ին), վերջացրած տվյալների ամբողջական վերարտադրմամբ տարբեր սկավառակների վրա՝ հաշվի առնելով սկավառակների գտնվելու վայրը։ սերվերներ և կաբինետներում գտնվող սերվերներ և այլն:
Ceph-ը կառուցելու համար անհրաժեշտ է ևս 3 հանգույց: Պահեստի հետ փոխգործակցությունը կիրականացվի նաև ցանցի միջոցով՝ օգտագործելով բլոկների, օբյեկտների և ֆայլերի պահպանման ծառայություններ: Եկեք պահեստավորում ավելացնենք սխեմային.
Նշում. կարող եք նաև ստեղծել հիպերկոնվերգացված հաշվողական հանգույցներ. սա մի հանգույցի վրա մի քանի ֆունկցիաների համակցման հայեցակարգ է, օրինակ՝ պահեստավորում+հաշվարկ՝ առանց ceph-ի պահպանման համար հատուկ հանգույցներ հատկացնելու: Մենք կստանանք նույն սխալների հանդուրժող սխեման, քանի որ SDS-ը կպահի տվյալները մեր կողմից նշված ամրագրման մակարդակով: Այնուամենայնիվ, հիպերկոնվերգացված հանգույցները միշտ փոխզիջում են, քանի որ պահեստավորման հանգույցը ոչ միայն տաքացնում է օդը, ինչպես թվում է առաջին հայացքից (քանի որ դրա վրա վիրտուալ մեքենաներ չկան), այլ այն ծախսում է պրոցեսորի ռեսուրսները SDS-ի սպասարկման վրա (իրականում, դա անում է ամեն ինչ: հանգույցների, սկավառակների և այլնի ձախողումներից հետո կրկնօրինակում և վերականգնում): Այսինքն, դուք կկորցնեք հաշվողական հանգույցի հզորության մի մասը, եթե այն համատեղեք պահեստի հետ:
Այս ամենը պետք է ինչ-որ կերպ կառավարվի. մեզ անհրաժեշտ է մի բան, որի միջոցով մենք կարող ենք ստեղծել մեքենա, ցանց, վիրտուալ երթուղիչ և այլն: Դա անելու համար մենք կավելացնենք ծառայություն կառավարման հանգույցին, որը կգործի որպես վահանակ. հաճախորդը կկարողանա միանալ այս պորտալին http/ https-ի միջոցով և անել այն ամենը, ինչ իրեն անհրաժեշտ է (լավ, գրեթե):
Արդյունքում, մենք այժմ ունենք անսարքությունների հանդուրժող համակարգ: Այս ենթակառուցվածքի բոլոր տարրերը պետք է ինչ-որ կերպ կառավարվեն։ Նախկինում նկարագրված էր, որ Openstack-ը նախագծերի մի շարք է, որոնցից յուրաքանչյուրն ապահովում է որոշակի գործառույթ։ Ինչպես տեսնում ենք, կան ավելի քան բավարար տարրեր, որոնք պետք է կազմաձևվեն և վերահսկվեն: Այսօր կխոսենք ցանցային մասի մասին։
Նեյտրոնային ճարտարապետություն
OpenStack-ում Նեյտրոնն է, ով պատասխանատու է վիրտուալ մեքենայի նավահանգիստները ընդհանուր L2 ցանցին միացնելու համար, ապահովելով երթևեկության երթուղավորում տարբեր L2 ցանցերում տեղակայված VM-ների միջև, ինչպես նաև դեպի արտաքին երթուղում՝ մատուցելով ծառայություններ, ինչպիսիք են NAT, Floating IP, DHCP և այլն:
Բարձր մակարդակով ցանցային ծառայության աշխատանքը (հիմնական մասը) կարելի է նկարագրել հետևյալ կերպ.
ՎՄ-ն միացնելիս ցանցային ծառայությունը.
- Ստեղծում է նավահանգիստ տվյալ VM-ի (կամ նավահանգիստների) համար և դրա մասին տեղեկացնում է DHCP ծառայությանը.
- Ստեղծվում է նոր վիրտուալ ցանցային սարք (libvirt-ի միջոցով);
- VM-ը միանում է 1-ին քայլում ստեղծված միացք(ներ)ին.
Տարօրինակ կերպով, Նեյտրոնի աշխատանքը հիմնված է ստանդարտ մեխանիզմների վրա, որոնք ծանոթ են բոլորին, ովքեր երբևէ սուզվել են Linux-ի մեջ՝ անունների տարածքներ, iptables, linux կամուրջներ, openvswitch, conntrack և այլն:
Անմիջապես պետք է պարզաբանել, որ Նեյտրոնը SDN կարգավորիչ չէ։
Նեյտրոնը բաղկացած է մի քանի փոխկապակցված բաղադրիչներից.
Openstack-neutron-server Դեյմոն է, որն աշխատում է օգտատերերի հարցումների հետ API-ի միջոցով: Այս դեյմոնը ներգրավված չէ ցանցային որևէ կապի գրանցման մեջ, սակայն դրա համար անհրաժեշտ տեղեկատվություն է տրամադրում իր պլագիններին, որոնք այնուհետև կարգավորում են ցանկալի ցանցային տարրը: Նեյտրոնային գործակալները OpenStack հանգույցներում գրանցվում են Նեյտրոնային սերվերում:
Նեյտրոն-սերվերը իրականում python-ով գրված հավելված է, որը բաղկացած է երկու մասից.
- ՀԱՆԳՍՏԻ ծառայություն
- Նեյտրոնային պլագին (միջուկ/ծառայություն)
REST ծառայությունը նախատեսված է այլ բաղադրիչներից API զանգեր ստանալու համար (օրինակ՝ որոշ տեղեկություններ տրամադրելու հարցում և այլն):
Փլագինները միացնող ծրագրային բաղադրիչներ/մոդուլներ են, որոնք կանչվում են API հարցումների ժամանակ, այսինքն՝ ծառայության վերագրումը տեղի է ունենում դրանց միջոցով: Փլագինները բաժանվում են երկու տեսակի՝ սպասարկման և արմատային։ Որպես կանոն, ձիու փլագինը հիմնականում պատասխանատու է VM-ների միջև հասցեների տարածության և L2 կապերի կառավարման համար, իսկ սպասարկման պլագիններն արդեն ապահովում են լրացուցիչ գործառույթներ, ինչպիսիք են VPN կամ FW:
Օրինակ՝ կարելի է դիտել այսօր առկա պլագինների ցանկը
Կարող է լինել մի քանի սպասարկման պլագին, բայց կարող է լինել միայն մեկ ձիու պլագին:
openstack-neutron-ml2 ստանդարտ Openstack արմատային հավելվածն է: Այս փլագինը ունի մոդուլային ճարտարապետություն (ի տարբերություն իր նախորդի) և կարգավորում է ցանցի ծառայությունը դրան միացված դրայվերների միջոցով։ Մենք մի փոքր ուշ կանդրադառնանք բուն հավելվածին, քանի որ իրականում այն տալիս է այն ճկունությունը, որն ունի OpenStack-ը ցանցային մասում: Root plugin-ը կարող է փոխարինվել (օրինակ, Contrail Networking-ը նման փոխարինում է անում):
RPC ծառայություն (rabbitmq-սերվեր) — ծառայություն, որն ապահովում է հերթերի կառավարում և փոխազդեցություն այլ OpenStack ծառայությունների հետ, ինչպես նաև փոխազդեցություն ցանցային սպասարկման գործակալների միջև:
Ցանցային գործակալներ — գործակալներ, որոնք տեղակայված են յուրաքանչյուր հանգույցում, որոնց միջոցով կարգավորվում են ցանցային ծառայությունները:
Գործակալների մի քանի տեսակներ կան.
Հիմնական գործակալն է L2 գործակալ. Այս գործակալներն աշխատում են հիպերվիզորներից յուրաքանչյուրի վրա, ներառյալ կառավարման հանգույցները (ավելի ճիշտ՝ բոլոր հանգույցների վրա, որոնք ցանկացած ծառայություն են մատուցում վարձակալներին) և նրանց հիմնական գործառույթն է միացնել վիրտուալ մեքենաները ընդհանուր L2 ցանցին, ինչպես նաև ստեղծել ահազանգեր, երբ տեղի են ունենում որևէ իրադարձություն ( օրինակ՝ անջատել/միացնել պորտը):
Հաջորդ, ոչ պակաս կարևոր գործակալն է L3 գործակալ. Լռելյայնորեն, այս գործակալն աշխատում է բացառապես ցանցային հանգույցի վրա (հաճախ ցանցի հանգույցը զուգակցվում է կառավարման հանգույցի հետ) և ապահովում է երթուղիներ վարձակալների ցանցերի միջև (ինչպես իր ցանցերի, այնպես էլ այլ վարձակալների ցանցերի միջև, և հասանելի է արտաքին աշխարհին՝ ապահովելով NAT, ինչպես նաև DHCP ծառայություն): Այնուամենայնիվ, երբ օգտագործում եք DVR (բաշխված երթուղիչ), L3 plugin-ի անհրաժեշտությունը հայտնվում է նաև հաշվողական հանգույցների վրա:
L3 գործակալը օգտագործում է Linux անունների տարածքներ, որպեսզի յուրաքանչյուր վարձակալի տրամադրի իր մեկուսացված ցանցերը և վիրտուալ երթուղիչների գործառույթը, որոնք ուղղորդում են երթևեկությունը և ապահովում են դարպասի ծառայություններ 2-րդ շերտի ցանցերի համար:
Database — ցանցերի, ենթացանցերի, նավահանգիստների, լողավազանների և այլնի նույնացուցիչների տվյալների բազա:
Իրականում, Նեյտրոնը ընդունում է API հարցումները ցանցի ցանկացած միավորի ստեղծումից, իսկորոշում է հարցումը և RPC-ի միջոցով (եթե մուտք է գործում որևէ plugin կամ գործակալ) կամ REST API-ն (եթե այն հաղորդակցվում է SDN-ով) փոխանցում է գործակալներին (պլագինների միջոցով) ցուցումներ, որոնք անհրաժեշտ են պահանջվող ծառայությունը կազմակերպելու համար:
Հիմա եկեք դիմենք թեստային տեղադրմանը (ինչպես է այն տեղադրվում և ինչ է ներառված դրանում, մենք կտեսնենք ավելի ուշ գործնական մասում) և տեսնենք, թե որտեղ է գտնվում յուրաքանչյուր բաղադրիչ.
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$ 
Իրականում դա նեյտրոնի ամբողջ կառուցվածքն է: Այժմ արժե որոշ ժամանակ ծախսել ML2 հավելվածի վրա:
Մոդուլային շերտ 2
Ինչպես նշվեց վերևում, plugin-ը ստանդարտ OpenStack արմատային պլագին է և ունի մոդուլային ճարտարապետություն:
ML2 plugin-ի նախորդն ուներ մոնոլիտ կառուցվածք, որը թույլ չէր տալիս, օրինակ, մի քանի տեխնոլոգիաների խառնուրդ օգտագործել մեկ տեղադրման մեջ։ Օրինակ, դուք չեք կարող միաժամանակ օգտագործել openvswitch-ը և linuxbridge-ը` կամ առաջինը, կամ երկրորդը: Այդ իսկ պատճառով ստեղծվել է ML2 փլագինը իր ճարտարապետությամբ։
ML2-ն ունի երկու բաղադրիչ՝ երկու տեսակի դրայվերներ՝ Type drivers և Mechanism drivers:
Տիպի դրայվերներ որոշել այն տեխնոլոգիաները, որոնք կօգտագործվեն ցանցային կապերը կազմակերպելու համար, օրինակ՝ VxLAN, VLAN, GRE: Միաժամանակ վարորդը թույլ է տալիս օգտագործել տարբեր տեխնոլոգիաներ։ Ստանդարտ տեխնոլոգիան VxLAN-ի ինկապսուլյացիան է կափարիչ ցանցերի և vlan արտաքին ցանցերի համար:
Տիպի դրայվերները ներառում են ցանցի հետևյալ տեսակները.
Բնակարան - ցանց առանց պիտակավորման
ՎԼԱՆ - հատկորոշված ցանց
Տեղական. — ցանցի հատուկ տեսակ «ամբողջական մեկում» տեղակայումների համար (այդպիսի տեղադրումները անհրաժեշտ են կա՛մ մշակողների, կա՛մ վերապատրաստման համար)
GRE — ծածկույթի ցանց՝ օգտագործելով GRE թունելները
VxLAN — ծածկել ցանց՝ օգտագործելով VxLAN թունելները
Մեխանիզմի վարորդներ սահմանել գործիքներ, որոնք ապահովում են տիպի դրայվերում նշված տեխնոլոգիաների կազմակերպումը, օրինակ՝ openvswitch, sr-iov, opendaylight, OVN և այլն։
Կախված այս դրայվերի ներդրումից, կամ կօգտագործվեն Neutron-ի կողմից վերահսկվող գործակալներ, կամ կօգտագործվեն արտաքին SDN կարգավորիչի հետ կապեր, որը հոգում է L2 ցանցերի կազմակերպման, երթուղավորման և այլնի հետ կապված բոլոր հարցերը:
Օրինակ. եթե մենք օգտագործում ենք ML2-ը OVS-ի հետ միասին, ապա յուրաքանչյուր հաշվողական հանգույցի վրա տեղադրվում է L2 գործակալ, որը կառավարում է OVS-ը: Այնուամենայնիվ, եթե մենք օգտագործում ենք, օրինակ, OVN կամ OpenDayLight, ապա OVS-ի կառավարումը անցնում է նրանց իրավասության ներքո. Neutron-ը, root plugin-ի միջոցով, հրամաններ է տալիս վերահսկիչին, և նա արդեն անում է այն, ինչ ասվել է:
Եկեք գործարկենք Open vSwitch-ը
Այս պահին OpenStack-ի հիմնական բաղադրիչներից մեկը Open vSwitch-ն է։
OpenStack-ը առանց որևէ լրացուցիչ մատակարարի SDN-ի տեղադրման ժամանակ, ինչպիսիք են Juniper Contrail-ը կամ Nokia Nuage-ը, OVS-ը ամպային ցանցի հիմնական ցանցային բաղադրիչն է և, iptables-ի, conntrack-ի, namespace-ների հետ միասին, թույլ է տալիս կազմակերպել բազմաբնակարան վարձակալական ծածկույթի ամբողջական ցանցեր: Բնականաբար, այս բաղադրիչը կարող է փոխարինվել, օրինակ, երրորդ կողմի սեփականության (վաճառողի) SDN լուծումներ օգտագործելիս:
OVS-ը բաց կոդով ծրագրային անջատիչ է, որը նախատեսված է վիրտուալացված միջավայրերում որպես վիրտուալ երթևեկության փոխանցող օգտագործելու համար:
Այս պահին OVS-ն ունի շատ պատշաճ ֆունկցիոնալություն, որը ներառում է այնպիսի տեխնոլոգիաներ, ինչպիսիք են QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK և այլն:
Նշում. OVS-ն ի սկզբանե չի ստեղծվել որպես փափուկ անջատիչ հեռահաղորդակցության բարձր բեռնված գործառույթների համար և ավելի շատ նախատեսված էր ավելի քիչ թողունակություն պահանջող ՏՏ գործառույթների համար, ինչպիսիք են WEB սերվերը կամ փոստային սերվերը: Այնուամենայնիվ, OVS-ն ավելի է զարգանում, և OVS-ի ներկայիս իրականացումները զգալիորեն բարելավել են դրա կատարումը և հնարավորությունները, ինչը թույլ է տալիս այն օգտագործել հեռահաղորդակցության օպերատորների կողմից բարձր բեռնված գործառույթներով, օրինակ, կա OVS ներդրում DPDK արագացման աջակցությամբ:
OVS-ի երեք կարևոր բաղադրիչ կա, որոնց մասին դուք պետք է տեղյակ լինեք.
- Միջուկի մոդուլ — միջուկի տարածքում տեղակայված բաղադրիչ, որը մշակում է երթևեկությունը կառավարման տարրից ստացված կանոնների հիման վրա.
- vSwitch Daemon-ը (ovs-vswitchd) օգտատիրոջ տարածքում գործարկված գործընթաց է, որը պատասխանատու է միջուկի մոդուլի ծրագրավորման համար, այսինքն՝ այն ուղղակիորեն ներկայացնում է անջատիչի աշխատանքի տրամաբանությունը:
- Տվյալների բազայի սերվեր - տեղական տվյալների բազա, որը տեղակայված է OVS աշխատող յուրաքանչյուր հոսթի վրա, որում պահվում է կոնֆիգուրացիան: SDN կարգավորիչները կարող են հաղորդակցվել այս մոդուլի միջոցով՝ օգտագործելով OVSDB արձանագրությունը:
Այս ամենն ուղեկցվում է ախտորոշիչ և կառավարման կոմունալ ծառայությունների մի շարքով, ինչպիսիք են ovs-vsctl, ovs-appctl, ovs-ofctl և այլն:
Ներկայումս Openstack-ը լայնորեն օգտագործվում է հեռահաղորդակցական օպերատորների կողմից ցանցի գործառույթները դեպի իրեն տեղափոխելու համար, ինչպիսիք են EPC, SBC, HLR և այլն: Որոշ գործառույթներ կարող են առանց խնդիրների OVS-ի հետ ապրել այն ձևով, որով այն կա, բայց օրինակ, EPC-ն մշակում է բաժանորդների տրաֆիկը: - այնուհետև այն անցնում է հսկայական տրաֆիկի միջով (այժմ երթևեկության ծավալները հասնում են վայրկյանում մի քանի հարյուր գիգաբիթ): Բնականաբար, միջուկի տարածության միջով նման երթևեկություն վարելը (քանի որ առաքիչը լռելյայնորեն գտնվում է այնտեղ) լավագույն գաղափարը չէ: Հետևաբար, OVS-ը հաճախ տեղակայվում է ամբողջությամբ օգտագործողի տարածքում՝ օգտագործելով DPDK արագացման տեխնոլոգիան՝ միջուկը շրջանցելով երթևեկությունը NIC-ից օգտվողի տարածք:
Նշում. հեռահաղորդակցության գործառույթների համար տեղակայված ամպի համար հնարավոր է ելքային տրաֆիկ հաշվողական հանգույցից՝ շրջանցելով OVS-ն ուղղակիորեն դեպի անջատիչ սարքավորում: Այդ նպատակով օգտագործվում են SR-IOV և Passthrough մեխանիզմները:
Ինչպե՞ս է սա աշխատում իրական դասավորության վրա:
Դե, հիմա եկեք անցնենք գործնական մասին և տեսնենք, թե ինչպես է այդ ամենն աշխատում գործնականում:
Նախ, եկեք տեղադրենք Openstack-ի պարզ տեղադրումը: Քանի որ ես փորձերի համար ձեռքի տակ չունեմ սերվերների հավաքածու, մենք նախատիպը կհավաքենք մեկ ֆիզիկական սերվերի վրա վիրտուալ մեքենաներից: Այո, բնականաբար, նման լուծումը հարմար չէ կոմերցիոն նպատակների համար, բայց Openstack-ում ցանցի աշխատանքի օրինակ տեսնելու համար նման ինստալացիա բավական է աչքերին։ Ավելին, նման տեղադրումը նույնիսկ ավելի հետաքրքիր է վերապատրաստման նպատակներով, քանի որ դուք կարող եք բռնել երթևեկությունը և այլն:
Քանի որ մենք պետք է տեսնենք միայն հիմնական մասը, մենք չենք կարող օգտագործել մի քանի ցանցեր, այլ բարձրացնել ամեն ինչ՝ օգտագործելով ընդամենը երկու ցանց, և այս դասավորության երկրորդ ցանցը կօգտագործվի բացառապես undercloud և DNS սերվեր մուտք գործելու համար: Արտաքին ցանցերին առայժմ չենք անդրադառնա՝ սա առանձին մեծ հոդվածի թեմա է։
Այսպիսով, եկեք սկսենք հերթականությամբ: Նախ, մի փոքր տեսություն. Մենք կտեղադրենք Openstack-ը՝ օգտագործելով TripleO (Openstack on Openstack): TripleO-ի էությունն այն է, որ մենք տեղադրում ենք Openstack-ը բոլորը մեկում (այսինքն՝ մեկ հանգույցի վրա), որը կոչվում է undercloud, այնուհետև օգտագործում ենք տեղակայված Openstack-ի հնարավորությունները՝ շահագործման համար նախատեսված Openstack-ը տեղադրելու համար, որը կոչվում է overcloud: Undercloud-ը կօգտագործի ֆիզիկական սերվերները (մերկ մետաղ) կառավարելու իր բնորոշ ունակությունը՝ Ironic նախագիծը, հիպերվիզորներ տրամադրելու համար, որոնք կկատարեն հաշվարկման, վերահսկման, պահեստավորման հանգույցների դերերը: Այսինքն՝ մենք չենք օգտագործում երրորդ կողմի որևէ գործիք Openstack-ը տեղակայելու համար. մենք Openstack-ը տեղակայում ենք Openstack-ի միջոցով: Դա շատ ավելի պարզ կդառնա, քանի որ տեղադրումը զարգանում է, այնպես որ մենք կանգ չենք առնի այնտեղ և առաջ շարժվենք:
Նշում. Այս հոդվածում, պարզության համար, ես չեմ օգտագործել ցանցի մեկուսացում ներքին Openstack ցանցերի համար, բայց ամեն ինչ տեղակայվում է միայն մեկ ցանցի միջոցով: Այնուամենայնիվ, ցանցի մեկուսացման առկայությունը կամ բացակայությունը չի ազդում լուծման հիմնական ֆունկցիոնալության վրա. ամեն ինչ կաշխատի նույն կերպ, ինչ մեկուսացման ժամանակ, բայց երթևեկությունը կհոսի նույն ցանցով: Առևտրային տեղադրման համար, բնականաբար, անհրաժեշտ է օգտագործել մեկուսացում, օգտագործելով տարբեր վլաններ և միջերեսներ: Օրինակ, ceph-ի պահեստավորման կառավարման տրաֆիկը և ինքնին տվյալների տրաֆիկը (մեքենայի մուտք դեպի սկավառակներ և այլն), երբ մեկուսացված են, օգտագործում են տարբեր ենթացանցեր (Պահպանման կառավարում և Պահպանում), և դա թույլ է տալիս լուծումն ավելի հանդուրժող դարձնել սխալների նկատմամբ՝ բաժանելով այս տրաֆիկը, օրինակ, , տարբեր նավահանգիստների միջոցով կամ օգտագործելով տարբեր QoS պրոֆիլներ տարբեր տրաֆիկի համար, որպեսզի տվյալների տրաֆիկը չսեղմի ազդանշանային տրաֆիկը: Մեր դեպքում նրանք գնալու են նույն ցանցով և իրականում դա մեզ ոչ մի կերպ չի սահմանափակում։
Նշում. Քանի որ մենք պատրաստվում ենք վիրտուալ մեքենաներ գործարկել վիրտուալ միջավայրում, որը հիմնված է վիրտուալ մեքենաների վրա, մենք նախ պետք է միացնենք nested վիրտուալացումը:
Դուք կարող եք ստուգել, արդյոք nested virtualization-ը միացված է, թե ոչ, այսպես.
[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested N [root@hp-gen9 bormoglotx]#Եթե տեսնում եք N տառը, ապա մենք միացնում ենք ներդիր վիրտուալացման աջակցությունը՝ համաձայն ցանկացած ուղեցույցի, որը դուք կգտնեք ցանցում, օրինակ. .
Վիրտուալ մեքենաներից մենք պետք է հավաքենք հետևյալ սխեման.
Իմ դեպքում, ապագա տեղադրման մաս կազմող վիրտուալ մեքենաները միացնելու համար (և ես ստացել եմ դրանցից 7-ը, բայց դուք կարող եք հաղթահարել 4-ով, եթե շատ ռեսուրսներ չունեք), ես օգտագործեցի OpenvSwitch-ը: Ես ստեղծեցի մեկ ovs կամուրջ և միացրի վիրտուալ մեքենաներ դրան պորտ-խմբերի միջոցով: Դա անելու համար ես ստեղծեցի xml ֆայլ հետևյալ կերպ.
[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1
<network>
<name>ovs-network-1</name>
<uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
<forward mode='bridge'/>
<bridge name='ovs-br1'/>
<virtualport type='openvswitch'/>
<portgroup name='trunk-1'>
<vlan trunk='yes'>
<tag id='100'/>
<tag id='101'/>
<tag id='102'/>
</vlan>
</portgroup>
<portgroup name='access-100'>
<vlan>
<tag id='100'/>
</vlan>
</portgroup>
<portgroup name='access-101'>
<vlan>
<tag id='101'/>
</vlan>
</portgroup>
</network>Այստեղ հայտարարված են երեք նավահանգիստների խմբեր՝ երկու մուտք և մեկ բեռնախցիկ (վերջինս անհրաժեշտ էր DNS սերվերի համար, բայց դուք կարող եք անել առանց դրա, կամ տեղադրել այն հյուրընկալող մեքենայի վրա՝ որն ավելի հարմար է ձեզ համար): Հաջորդը, օգտագործելով այս ձևանմուշը, մենք հայտարարում ենք մերը virsh net-define-ի միջոցով.
virsh net-define ovs-network-1.xml
virsh net-start ovs-network-1
virsh net-autostart ovs-network-1 Այժմ մենք խմբագրում ենք հիպերվիզորի պորտի կազմաձևերը.
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# Նշում. այս սցենարում ovs-br1 նավահանգստի հասցեն հասանելի չի լինի, քանի որ այն չունի vlan պիտակ: Դա շտկելու համար դուք պետք է թողարկեք հրամանը sudo ovs-vsctl set port ovs-br1 tag=100: Այնուամենայնիվ, վերաբեռնումից հետո այս պիտակը կվերանա (եթե որևէ մեկը գիտի, թե ինչպես անել, որ այն մնա տեղում, ես շատ շնորհակալ կլինեմ): Բայց սա այնքան էլ կարևոր չէ, քանի որ այս հասցեն մեզ պետք կգա միայն տեղադրման ժամանակ և այն կարիք չի ունենա, երբ Openstack-ը լիովին գործարկվի:
Հաջորդը, մենք ստեղծում ենք undercloud մեքենա.
virt-install -n undercloud --description "undercloud" --os-type=Linux --os-variant=centos7.0 --ram=8192 --vcpus=8 --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0Տեղադրման ընթացքում դուք սահմանում եք բոլոր անհրաժեշտ պարամետրերը, ինչպիսիք են մեքենայի անունը, գաղտնաբառերը, օգտվողները, ntp սերվերները և այլն, կարող եք անմիջապես կարգավորել նավահանգիստները, բայց անձամբ ինձ համար, տեղադրումից հետո, ավելի հեշտ է մուտք գործել մեքենա: կոնսոլը և ուղղել անհրաժեշտ ֆայլերը: Եթե դուք արդեն ունեք պատրաստի պատկեր, կարող եք օգտագործել այն, կամ անել այն, ինչ ես արեցի՝ ներբեռնեք նվազագույն Centos 7 պատկերը և օգտագործեք այն VM-ը տեղադրելու համար:
Հաջող տեղադրումից հետո դուք պետք է ունենաք վիրտուալ մեքենա, որի վրա կարող եք տեղադրել undercloud
[root@hp-gen9 bormoglotx]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
62 undercloud runningՆախ տեղադրեք տեղադրման գործընթացի համար անհրաժեշտ գործիքները.
sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool
Undercloud տեղադրում
Մենք ստեղծում ենք stack user, սահմանում ենք գաղտնաբառ, ավելացնում այն sudoer-ին և նրան հնարավորություն ենք տալիս կատարել root հրամանները sudo-ի միջոցով՝ առանց գաղտնաբառ մուտքագրելու:
useradd stack
passwd stack
echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stackԱյժմ մենք նշում ենք ամբողջական undercloud անունը hosts ֆայլում.
vi /etc/hosts
127.0.0.1 undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6Հաջորդը, մենք ավելացնում ենք պահեստներ և տեղադրում մեզ անհրաժեշտ ծրագրաշարը.
sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansibleՆշում. եթե դուք չեք նախատեսում տեղադրել ceph, ապա ձեզ հարկավոր չէ մուտքագրել ceph-ի հետ կապված հրամաններ: Ես օգտագործել եմ Queens-ի թողարկումը, բայց դուք կարող եք օգտագործել ցանկացած այլ, որը ցանկանում եք:
Հաջորդը, պատճենեք undercloud-ի կազմաձևման ֆայլը օգտվողի տնային գրացուցակում.
cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.confԱյժմ մենք պետք է շտկենք այս ֆայլը՝ այն հարմարեցնելով մեր տեղադրմանը:
Դուք պետք է ավելացնեք այս տողերը ֆայլի սկզբում.
vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10Այսպիսով, եկեք անցնենք պարամետրերը.
undercloud_hostname — undercloud սերվերի լրիվ անվանումը պետք է համապատասխանի DNS սերվերի մուտքագրմանը
local_ip — տեղական undercloud հասցե ցանցի տրամադրման ուղղությամբ
ցանց_դարպաս — նույն տեղական հասցեն, որը գերամպային հանգույցների տեղադրման ժամանակ արտաքին աշխարհ մուտք գործելու դարպաս, համընկնում է նաև տեղական IP-ի հետ։
undercloud_public_host — արտաքին API հասցե, տրամադրվող ցանցից ցանկացած անվճար հասցե հատկացվում է
undercloud_admin_host ներքին API հասցե, տրամադրվող ցանցից ցանկացած անվճար հասցե հատկացվում է
undercloud_nameservers - DNS սերվեր
գեներացնել_ծառայություն_վկայական - այս տողը շատ կարևոր է ընթացիկ օրինակում, քանի որ եթե այն չսահմանեք false, տեղադրման ժամանակ սխալ կստանաք, խնդիրը նկարագրված է Red Hat-ի սխալների հետագծում:
տեղական_ինտերֆեյս ինտերֆեյս ցանցի մատակարարման մեջ: Այս ինտերֆեյսը կվերակազմավորվի undercloud-ի տեղակայման ժամանակ, այնպես որ դուք պետք է ունենաք երկու ինտերֆեյս undercloud-ի վրա՝ մեկը մուտք գործելու համար, երկրորդը՝ տրամադրելու համար:
local_mtu - MTU. Քանի որ մենք ունենք փորձարկման լաբորատորիա, և ես ունեմ MTU 1500 OVS անջատիչի նավահանգիստներում, անհրաժեշտ է այն դնել 1450-ի վրա, որպեսզի VxLAN-ով պարփակված փաթեթները կարողանան անցնել միջով:
ցանց_cidr - մատակարարման ցանց
դիմակահանդես — օգտագործելով NAT՝ արտաքին ցանց մուտք գործելու համար
դիմակահանդես_ցանց - ցանց, որը կլինի NAT
dhcp_start — հասցեների ֆոնդի մեկնարկային հասցեն, որից հասցեները վերագրվելու են հանգույցներին գերամպային տեղակայման ժամանակ
dhcp_end — հասցեների ֆոնդի վերջնական հասցեն, որից հասցեները վերագրվելու են հանգույցներին գերամպային տեղակայման ժամանակ
inspection_iprange - Ինքնատեսության համար անհրաժեշտ հասցեների մի խումբ (չպետք է համընկնի վերը նշված ֆոնդի հետ)
scheduler_max_ttempts — Overcloud-ի տեղադրման փորձերի առավելագույն քանակը (պետք է լինի հանգույցների քանակից մեծ կամ հավասար)
Ֆայլը նկարագրելուց հետո կարող եք հրաման տալ undercloud-ը տեղակայելու համար.
openstack undercloud install
Գործընթացը տևում է 10-ից 30 րոպե՝ կախված ձեր երկաթից: Ի վերջո, դուք պետք է տեսնեք արդյունքը այսպես.
vi undercloud.conf
2020-08-13 23:13:12,668 INFO:
#############################################################################
Undercloud install complete.
The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.
There is also a stackrc file at /home/stack/stackrc.
These files are needed to interact with the OpenStack services, and should be
secured.
#############################################################################Այս ելքը ասում է, որ դուք հաջողությամբ տեղադրել եք undercloud-ը և այժմ կարող եք ստուգել undercloud-ի կարգավիճակը և անցնել overcloud-ի տեղադրմանը:
Եթե նայեք ifconfig ելքին, կտեսնեք, որ հայտնվել է նոր կամուրջ ինտերֆեյս
[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.1 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe2c:89e prefixlen 64 scopeid 0x20<link>
ether 52:54:00:2c:08:9e txqueuelen 1000 (Ethernet)
RX packets 14 bytes 1095 (1.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20 bytes 1292 (1.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Overcloud-ի տեղակայումն այժմ կիրականացվի այս ինտերֆեյսի միջոցով:
Ստորև բերված արդյունքից կարող եք տեսնել, որ մենք ունենք բոլոր ծառայությունները մեկ հանգույցի վրա.
(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name | Service | Zone |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute | nova |
+--------------------------+-----------+----------+Ստորև ներկայացված է ամպային ցանցի մասի կազմաձևումը.
(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json
{
"network_config": [
{
"addresses": [
{
"ip_netmask": "192.168.255.1/24"
}
],
"members": [
{
"dns_servers": [
"192.168.255.253"
],
"mtu": 1450,
"name": "eth0",
"primary": "true",
"type": "interface"
}
],
"mtu": 1450,
"name": "br-ctlplane",
"ovs_extra": [
"br-set-external-id br-ctlplane bridge-id br-ctlplane"
],
"routes": [],
"type": "ovs_bridge"
}
]
}
(undercloud) [stack@undercloud ~]$Overcloud տեղադրում
Այս պահին մենք ունենք միայն undercloud, և չունենք բավարար հանգույցներ, որոնցից overcloud-ը կհավաքվի։ Հետևաբար, առաջին հերթին եկեք տեղակայենք մեզ անհրաժեշտ վիրտուալ մեքենաները: Տեղակայման ընթացքում undercloud-ն ինքը կտեղադրի ՕՀ-ն և անհրաժեշտ ծրագրակազմը overcloud մեքենայի վրա, այսինքն՝ մեզ պետք չէ ամբողջությամբ տեղակայել մեքենան, այլ միայն դրա համար ստեղծել սկավառակ (կամ սկավառակներ) և որոշել դրա պարամետրերը, այսինքն. Փաստորեն, մենք ստանում ենք մերկ սերվեր առանց դրա վրա տեղադրված ՕՀ-ի:
Եկեք գնանք մեր վիրտուալ մեքենաների սկավառակներով թղթապանակ և ստեղծենք պահանջվող չափի սկավառակներ.
cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160GՔանի որ մենք աշխատում ենք որպես root, մենք պետք է փոխենք այս սկավառակների սեփականատերը, որպեսզի իրավունքների հետ կապված խնդիր չառաջանա.
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]#
[root@hp-gen9 images]#
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu 61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu 41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# Նշում․ եթե չեք նախատեսում տեղադրել ceph՝ այն ուսումնասիրելու համար, ապա հրամանները չեն ստեղծում առնվազն 3 հանգույց՝ առնվազն երկու սկավառակով, այլ ձևանմուշում նշվում է, որ կօգտագործվեն վիրտուալ սկավառակներ vda, vdb և այլն։
Հիանալի է, հիմա մենք պետք է սահմանենք այս բոլոր մեքենաները.
virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml
virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml
virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml
virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml
virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml Վերջում կա հրաման -print-xml > /tmp/storage-1.xml, որը ստեղծում է xml ֆայլ՝ յուրաքանչյուր մեքենայի նկարագրությամբ /tmp/ թղթապանակում, եթե այն չավելացնեք, չեք լինի ի վիճակի է նույնականացնել վիրտուալ մեքենաները:
Այժմ մենք պետք է սահմանենք այս բոլոր մեքենաները virsh-ով.
virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Այժմ մի փոքր նրբերանգ՝ tripleO-ն օգտագործում է IPMI՝ կառավարելու սերվերները տեղադրման և ինքնավերլուծության ժամանակ:
Ինտրոսպեկտը սարքաշարի ստուգման գործընթաց է՝ հանգույցների հետագա ապահովման համար անհրաժեշտ դրա պարամետրերը ստանալու համար: Ինտրոսպեկցիան իրականացվում է հեգնական ծառայության միջոցով, որը նախատեսված է մերկ մետաղական սերվերների հետ աշխատելու համար:
Բայց ահա խնդիրն այն է, որ եթե ապարատային IPMI սերվերներն ունեն առանձին պորտ (կամ ընդհանուր նավահանգիստ, բայց դա կարևոր չէ), ապա վիրտուալ մեքենաները չունեն այդպիսի նավահանգիստներ: Այստեղ մեզ օգնության է գալիս vbmc կոչվող հենակը՝ մի օգտակար ծրագիր, որը թույլ է տալիս ընդօրինակել IPMI պորտը: Այս նրբերանգին արժե ուշադրություն դարձնել հատկապես նրանց համար, ովքեր ցանկանում են նման լաբորատորիա տեղադրել ESXI հիպերվիզորի վրա. ճիշտն ասած, ես չգիտեմ, թե արդյոք այն ունի vbmc-ի անալոգը, ուստի արժե մտածել այս հարցի շուրջ ամեն ինչ տեղակայելուց առաջ: .
Տեղադրեք vbmc:
yum install yum install python2-virtualbmcԵթե ձեր ՕՀ-ն չի կարողանում գտնել փաթեթը, ապա ավելացրեք պահեստը.
yum install -y https://www.rdoproject.org/repos/rdo-release.rpmԱյժմ մենք ստեղծեցինք կոմունալ ծրագիրը: Այստեղ ամեն ինչ խայտառակության աստիճան բանալ է։ Հիմա տրամաբանական է, որ vbmc ցուցակում սերվերներ չկան
[root@hp-gen9 ~]# vbmc list
[root@hp-gen9 ~]# Որպեսզի դրանք հայտնվեն, դրանք պետք է ձեռքով հայտարարվեն այսպես.
[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1 | down | :: | 7004 |
| compute-2 | down | :: | 7005 |
| control-1 | down | :: | 7001 |
| storage-1 | down | :: | 7002 |
| storage-2 | down | :: | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#Կարծում եմ, հրամանի շարահյուսությունը պարզ է առանց բացատրության: Այնուամենայնիվ, առայժմ մեր բոլոր նիստերը DOWN կարգավիճակում են: Որպեսզի նրանք տեղափոխվեն UP կարգավիճակ, դուք պետք է միացնեք դրանք.
[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]#
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status | Address | Port |
+-------------+---------+---------+------+
| compute-1 | running | :: | 7004 |
| compute-2 | running | :: | 7005 |
| control-1 | running | :: | 7001 |
| storage-1 | running | :: | 7002 |
| storage-2 | running | :: | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#Եվ վերջին հպումը. դուք պետք է շտկեք firewall-ի կանոնները (կամ ամբողջությամբ անջատեք այն).
firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload
Հիմա եկեք գնանք undercloud և ստուգենք, որ ամեն ինչ աշխատում է: Հոսթ մեքենայի հասցեն է 192.168.255.200, undercloud-ում մենք ավելացրել ենք անհրաժեշտ ipmitool փաթեթը տեղակայման նախապատրաստման ժամանակ.
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
65 control-1 runningԻնչպես տեսնում եք, մենք հաջողությամբ գործարկել ենք կառավարման հանգույցը vbmc-ի միջոցով: Հիմա եկեք անջատենք այն և շարունակենք.
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$
[root@hp-gen9 ~]# virsh list --all
Id Name State
----------------------------------------------------
6 dns-server running
64 undercloud running
- compute-1 shut off
- compute-2 shut off
- control-1 shut off
- storage-1 shut off
- storage-2 shut off
[root@hp-gen9 ~]#Հաջորդ քայլը հանգույցների ներքննությունն է, որոնց վրա կտեղադրվի overcloud: Դա անելու համար մենք պետք է պատրաստենք json ֆայլ՝ մեր հանգույցների նկարագրությամբ։ Խնդրում ենք նկատի ունենալ, որ, ի տարբերություն մերկ սերվերների վրա տեղադրման, ֆայլը ցույց է տալիս այն նավահանգիստը, որի վրա աշխատում է vbmc-ն յուրաքանչյուր մեքենայի համար:
[root@hp-gen9 ~]# virsh domiflist --domain control-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:20:a2:2f
- network ovs-network-1 virtio 52:54:00:3f:87:9f
[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:98:e9:d6
[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:6a:ea:be
[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:79:0b:cb
[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface Type Source Model MAC
-------------------------------------------------------
- network ovs-network-1 virtio 52:54:00:a7:fe:27Նշում․ հսկիչ հանգույցն ունի երկու ինտերֆեյս, բայց այս դեպքում դա կարևոր չէ, այս տեղադրման դեպքում մեկը մեզ բավական կլինի։
Այժմ մենք պատրաստում ենք json ֆայլը: Մենք պետք է նշենք նավահանգստի կակաչի հասցեն, որի միջոցով կիրականացվի մատակարարումը, հանգույցների պարամետրերը, նրանց անուններ տալ և նշել, թե ինչպես հասնել ipmi.
{
"nodes":[
{
"mac":[
"52:54:00:20:a2:2f"
],
"cpu":"8",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"control-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7001"
},
{
"mac":[
"52:54:00:79:0b:cb"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7002"
},
{
"mac":[
"52:54:00:a7:fe:27"
],
"cpu":"4",
"memory":"16384",
"disk":"160",
"arch":"x86_64",
"name":"storage-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7003"
},
{
"mac":[
"52:54:00:98:e9:d6"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-1",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7004"
},
{
"mac":[
"52:54:00:6a:ea:be"
],
"cpu":"12",
"memory":"32768",
"disk":"60",
"arch":"x86_64",
"name":"compute-2",
"pm_type":"pxe_ipmitool",
"pm_user":"admin",
"pm_password":"admin",
"pm_addr":"192.168.255.200",
"pm_port":"7005"
}
]
}Այժմ մենք պետք է պատրաստենք պատկերներ հեգնանքի համար: Դա անելու համար ներբեռնեք դրանք wget-ի միջոցով և տեղադրեք.
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack 916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack 15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack 53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$Պատկերների վերբեռնում undercloud.
(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | aki | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | ari | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | qcow2 | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | aki | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
| ID | Name | Disk Format | Size | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | ari | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$Ստուգում, որ բոլոր պատկերները բեռնված են
(undercloud) [stack@undercloud ~]$ openstack image list
+--------------------------------------+------------------------+--------+
| ID | Name | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$Եվս մեկ բան՝ դուք պետք է ավելացնեք DNS սերվեր.
(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID | Name | Network | Subnet |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field | Value |
+-------------------+-----------------------------------------------------------+
| allocation_pools | 192.168.255.11-192.168.255.50 |
| cidr | 192.168.255.0/24 |
| created_at | 2020-08-13T20:10:37Z |
| description | |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 192.168.255.1 |
| host_routes | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id | f45dea46-4066-42aa-a3c4-6f84b8120cab |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | ctlplane-subnet |
| network_id | 6ca013dc-41c2-42d8-9d69-542afad53392 |
| prefix_length | None |
| project_id | a844ccfcdb2745b198dde3e1b28c40a3 |
| revision_number | 0 |
| segment_id | None |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2020-08-13T20:10:37Z |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$Այժմ մենք կարող ենք ներդաշնակության հրաման տալ.
(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$Ինչպես տեսնում եք ելքից, ամեն ինչ ավարտվեց առանց սխալների: Եկեք ստուգենք, որ բոլոր հանգույցները հասանելի վիճակում են.
(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID | Name | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None | power off | available | False |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None | power off | available | False |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None | power off | available | False |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None | power off | available | False |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None | power off | available | False |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ Եթե հանգույցները գտնվում են այլ վիճակում, սովորաբար կառավարելի, ապա ինչ-որ բան սխալ է տեղի ունեցել, և դուք պետք է նայեք գրանցամատյանը և պարզեք, թե ինչու է դա տեղի ունեցել: Հիշեք, որ այս սցենարում մենք օգտագործում ենք վիրտուալացում և կարող են լինել վրիպակներ՝ կապված վիրտուալ մեքենաների կամ vbmc-ի օգտագործման հետ:
Հաջորդը, մենք պետք է նշենք, թե որ հանգույցը ինչ գործառույթ կկատարի, այսինքն՝ նշենք այն պրոֆիլը, որով հանգույցը կտեղակայվի.
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | None | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | None | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | None | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | None | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | None | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 | 40 | 0 | 1 | True |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal | 4096 | 40 | 0 | 1 | True |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control | 4096 | 40 | 0 | 1 | True |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 | 40 | 0 | 1 | True |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute | 4096 | 40 | 0 | 1 | True |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage | 4096 | 40 | 0 | 1 | True |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$Նշեք պրոֆիլը յուրաքանչյուր հանգույցի համար.
openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167Եկեք ստուգենք, որ մենք ամեն ինչ ճիշտ ենք արել.
(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available | control | |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available | ceph-storage | |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available | ceph-storage | |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available | compute | |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available | compute | |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$Եթե ամեն ինչ ճիշտ է, մենք հրաման ենք տալիս տեղակայել overcloud:
openstack overcloud deploy --templates --control-scale 1 --compute-scale 2 --ceph-storage-scale 2 --control-flavor control --compute-flavor compute --ceph-storage-flavor ceph-storage --libvirt-type qemuԻրական տեղադրման դեպքում, բնականաբար, կօգտագործվեն հարմարեցված ձևանմուշներ, մեր դեպքում դա մեծապես կբարդացնի գործընթացը, քանի որ ձևանմուշի յուրաքանչյուր խմբագրումը պետք է բացատրվի: Ինչպես ավելի վաղ գրվել էր, նույնիսկ պարզ տեղադրումը բավական կլինի, որպեսզի տեսնենք, թե ինչպես է այն աշխատում:
Նշում. --libvirt տիպի qemu փոփոխականն անհրաժեշտ է այս դեպքում, քանի որ մենք կօգտագործենք nested virtualization: Հակառակ դեպքում, դուք չեք կարողանա գործարկել վիրտուալ մեքենաներ:
Այժմ դուք ունեք մոտ մեկ ժամ, կամ գուցե ավելի շատ (կախված սարքավորման հնարավորություններից) և կարող եք միայն հուսալ, որ այս ժամանակից հետո կտեսնեք հետևյալ հաղորդագրությունը.
2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE Stack CREATE completed successfully
Stack overcloud CREATE_COMPLETE
Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$Այժմ դուք ունեք openstack-ի գրեթե լիարժեք տարբերակը, որի վրա կարող եք ուսումնասիրել, փորձարկել և այլն։
Եկեք ստուգենք, որ ամեն ինչ ճիշտ է աշխատում: Օգտագործողի տնային գրացուցակում կա երկու ֆայլ՝ մեկը stackrc ( undercloud-ի կառավարման համար) և երկրորդը՝ overcloudrc (overcloud-ի կառավարման համար): Այս ֆայլերը պետք է նշվեն որպես աղբյուր, քանի որ դրանք պարունակում են նույնականացման համար անհրաժեշտ տեղեկատվություն:
(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID | Name | Status | Networks | Image | Flavor |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0 | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$
(undercloud) [stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID | Name |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$
(overcloud) [stack@undercloud ~]$ openstack network agent list
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID | Agent Type | Host | Availability Zone | Alive | State | Binary |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-l3-agent |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent | overcloud-controller-0.localdomain | nova | :-) | UP | neutron-dhcp-agent |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent | overcloud-controller-0.localdomain | None | :-) | UP | neutron-metadata-agent |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$Իմ տեղադրումը դեռ պահանջում է մեկ փոքր հպում` կարգավորիչի վրա երթուղի ավելացնելը, քանի որ մեքենան, որի հետ ես աշխատում եմ, այլ ցանցում է: Դա անելու համար ջերմային ադմինիստրատորի հաշվի տակ անցեք control-1 և գրանցեք երթուղին
(undercloud) [stack@undercloud ~]$ ssh heat-admin@192.168.255.15
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254Դե, հիմա դուք կարող եք գնալ դեպի հորիզոն: Բոլոր տեղեկությունները` հասցեները, մուտքի անունը և գաղտնաբառը, գտնվում են /home/stack/overcloudrc ֆայլում: Վերջնական դիագրամն այսպիսին է թվում.
Ի դեպ, մեր տեղադրման ժամանակ մեքենաների հասցեները տրվել են DHCP-ի միջոցով և, ինչպես տեսնում եք, դրանք տրվում են «պատահական» սկզբունքով: Կաղապարում կարող եք խստորեն սահմանել, թե որ հասցեին պետք է կցվի տեղակայման ժամանակ, եթե դա ձեզ անհրաժեշտ է։
Ինչպե՞ս է թրաֆիկը հոսում վիրտուալ մեքենաների միջև:
Այս հոդվածում մենք կանդրադառնանք երթեւեկության անցման երեք տարբերակին
- Երկու մեքենա մեկ հիպերվիզորի վրա մեկ L2 ցանցում
- Երկու մեքենա տարբեր հիպերվիզորների վրա նույն L2 ցանցում
- Երկու մեքենա տարբեր ցանցերում (միջցանցային արմատավորում)
Արտաքին ցանցի միջոցով արտաքին աշխարհ մուտք գործելու դեպքերը, օգտագործելով լողացող հասցեները, ինչպես նաև բաշխված երթուղին, մենք կքննարկենք հաջորդ անգամ, առայժմ կկենտրոնանանք ներքին տրաֆիկի վրա:
Ստուգելու համար եկեք միասին կազմենք հետևյալ դիագրամը.
Մենք ստեղծել ենք 4 վիրտուալ մեքենա՝ 3-ը մեկ L2 ցանցում՝ net-1, և ևս 1-ը՝ net-2 ցանցում։
(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID | Name | Tenant ID | Status | Task State | Power State | Networks |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | - | Running | net-2=10.0.2.8 |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ Տեսնենք, թե ինչ հիպերվիզերների վրա են գտնվում ստեղծված մեքենաները.
(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-1 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000001 |(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-2 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-3 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-0.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000003 |(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname | vm-4 |
| OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.localdomain |
| OS-EXT-SRV-ATTR:instance_name | instance-00000004 | (overcloud) [stack@undercloud ~]$
Մեքենաները vm-1 և vm-3 գտնվում են compute-0-ի վրա, vm-2 և vm-4 մեքենաները տեղակայված են compute-1 հանգույցում:
Բացի այդ, ստեղծվել է վիրտուալ երթուղիչ՝ նշված ցանցերի միջև երթուղին հնարավոր դարձնելու համար.
(overcloud) [stack@undercloud ~]$ openstack router list --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID | Name | Status | State | Distributed | HA | Project |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP | False | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ Երթուղիչն ունի երկու վիրտուալ պորտ, որոնք գործում են որպես ցանցերի դարպասներ.
(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ Բայց նախքան նայենք, թե ինչպես է երթևեկությունը հոսում, եկեք տեսնենք, թե ինչ ունենք ներկայումս կառավարման հանգույցում (որը նաև ցանցային հանգույց է) և հաշվողական հանգույցում: Սկսենք հաշվողական հանգույցից։
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Այս պահին հանգույցն ունի երեք ovs կամուրջ՝ br-int, br-tun, br-ex։ Նրանց միջև, ինչպես տեսնում ենք, կա միջերեսների մի շարք: Հասկանալու համար, եկեք գծենք այս բոլոր միջերեսները դիագրամի վրա և տեսնենք, թե ինչ է տեղի ունենում:
Նայելով այն հասցեներին, որոնց վրա բարձրացված են VxLAN թունելները, կարելի է տեսնել, որ մեկ թունելը բարձրացված է compute-1 (192.168.255.26), երկրորդ թունելը նայում է դեպի control-1 (192.168.255.15): Բայց ամենահետաքրքիրն այն է, որ br-ex-ը չունի ֆիզիկական ինտերֆեյսներ, և եթե նայեք, թե ինչ հոսքեր են կազմաձևված, կարող եք տեսնել, որ այս կամուրջը կարող է միայն երթևեկությունը թողնել տվյալ պահին:
[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.19 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe6a:eabe prefixlen 64 scopeid 0x20<link>
ether 52:54:00:6a:ea:be txqueuelen 1000 (Ethernet)
RX packets 2909669 bytes 4608201000 (4.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1821057 bytes 349198520 (333.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-novacompute-0 ~]$ Ինչպես տեսնում եք ելքից, հասցեն ուղղակիորեն պտտվում է ֆիզիկական պորտին, և ոչ թե վիրտուալ կամուրջի միջերեսին:
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-ex
cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$ Առաջին կանոնի համաձայն, այն ամենը, ինչ եկել է phy-br-ex նավահանգստից, պետք է դեն նետվի:
Իրականում, այս կամրջի մեջ երթևեկության այլ տեղ չկա, բացի այս ինտերֆեյսից (ինտերֆեյս br-int-ով), և դատելով անկումներից, BUM տրաֆիկը արդեն թռչել է կամուրջ:
Այսինքն՝ երթևեկությունը կարող է դուրս գալ այս հանգույցից միայն VxLAN թունելով և ուրիշ ոչինչ։ Այնուամենայնիվ, եթե դուք միացնեք DVR-ն, իրավիճակը կփոխվի, բայց մենք դրանով կզբաղվենք մեկ այլ անգամ: Ցանցի մեկուսացում օգտագործելիս, օրինակ՝ vlan-ներ օգտագործելիս, դուք կունենաք ոչ թե մեկ L3 ինտերֆեյս vlan 0-ում, այլ մի քանի ինտերֆեյս: Այնուամենայնիվ, VxLAN-ի տրաֆիկը նույն կերպ կթողնի հանգույցը, բայց նաև կներառվի ինչ-որ հատուկ վլանում:
Մենք դասավորել ենք հաշվողական հանգույցը, եկեք անցնենք կառավարման հանգույցին:
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
br-ex:
br-ex 65534/1: (internal)
eth0 1/2: (system)
phy-br-ex 2/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/3: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
br-tun:
br-tun 65534/4: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$Փաստորեն, կարելի է ասել, որ ամեն ինչ նույնն է, բայց IP հասցեն այլևս ֆիզիկական ինտերֆեյսի վրա չէ, այլ վիրտուալ կամրջի վրա։ Դա արվում է, քանի որ այս նավահանգիստը այն նավահանգիստն է, որի միջոցով երթևեկությունը դուրս կգա արտաքին աշխարհ:
[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 192.168.255.15 netmask 255.255.255.0 broadcast 192.168.255.255
inet6 fe80::5054:ff:fe20:a22f prefixlen 64 scopeid 0x20<link>
ether 52:54:00:20:a2:2f txqueuelen 1000 (Ethernet)
RX packets 803859 bytes 1732616116 (1.6 GiB)
RX errors 0 dropped 63 overruns 0 frame 0
TX packets 808475 bytes 121652156 (116.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
port VLAN MAC Age
3 100 28:c0:da:00:4d:d3 35
1 0 28:c0:da:00:4d:d3 35
1 0 52:54:00:98:e9:d6 0
LOCAL 0 52:54:00:20:a2:2f 0
1 0 52:54:00:2c:08:9e 0
3 100 52:54:00:20:a2:2f 0
1 0 52:54:00:6a:ea:be 0
[heat-admin@overcloud-controller-0 ~]$ Այս նավահանգիստը կապված է br-ex կամրջի հետ, և քանի որ դրա վրա չկան vlan պիտակներ, այս նավահանգիստը միջքաղաքային նավահանգիստ է, որի վրա թույլատրվում են բոլոր վլանները, այժմ երթևեկությունը դուրս է գալիս առանց պիտակի, ինչպես նշված է vlan-id 0-ով: ելքը վերևում:
Մնացած ամեն ինչ այս պահին նման է հաշվողական հանգույցին՝ նույն կամուրջները, նույն թունելները, որոնք գնում են դեպի երկու հաշվարկային հանգույց:
Այս հոդվածում մենք չենք դիտարկի պահեստավորման հանգույցները, բայց հասկանալու համար պետք է ասել, որ այս հանգույցների ցանցային մասը խայտառակության աստիճանի անիմաստ է: Մեր դեպքում կա միայն մեկ ֆիզիկական նավահանգիստ (eth0), որին տրված է IP հասցե և վերջ: Չկան VxLAN թունելներ, թունելային կամուրջներ և այլն, ընդհանրապես ovs չկա, քանի որ դրա մեջ ոչ մի կետ չկա: Ցանցի մեկուսացում օգտագործելիս այս հանգույցը կունենա երկու ինտերֆեյս (ֆիզիկական պորտեր, bodny կամ ընդամենը երկու վլան, դա կարևոր չէ, դա կախված է նրանից, թե ինչ եք ուզում) - մեկը կառավարման համար, երկրորդը տրաֆիկի համար (գրում է VM սկավառակի վրա): , սկավառակից կարդալ և այլն)
Մենք պարզեցինք, թե ինչ ունենք հանգույցների վրա որևէ ծառայությունների բացակայության դեպքում: Այժմ եկեք գործարկենք 4 վիրտուալ մեքենաներ և տեսնենք, թե ինչպես է փոխվում վերը նկարագրված սխեման. մենք պետք է ունենանք նավահանգիստներ, վիրտուալ երթուղիչներ և այլն:
Մինչ այժմ մեր ցանցն ունի հետևյալ տեսքը.
Յուրաքանչյուր համակարգչային հանգույցում ունենք երկու վիրտուալ մեքենա: Օգտագործելով compute-0 որպես օրինակ, տեսնենք, թե ինչպես է ամեն ինչ ներառված:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list
Id Name State
----------------------------------------------------
1 instance-00000001 running
3 instance-00000003 running
[heat-admin@overcloud-novacompute-0 ~]$ Մեքենան ունի միայն մեկ վիրտուալ ինտերֆեյս՝ tap95d96a75-a0:
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
Այս ինտերֆեյսը նայում է linux կամրջում.
[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.0242904c92a8 no
qbr5bd37136-47 8000.5e4e05841423 no qvb5bd37136-47
tap5bd37136-47
qbr95d96a75-a0 8000.de076cb850f6 no qvb95d96a75-a0
tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ Ինչպես տեսնում եք ելքից, կամրջում կա ընդամենը երկու ինտերֆեյս՝ tap95d96a75-a0 և qvb95d96a75-a0:
Այստեղ արժե մի փոքր անդրադառնալ OpenStack-ում վիրտուալ ցանցային սարքերի տեսակների վրա.
vtap - վիրտուալ ինտերֆեյս, որը կցված է օրինակին (VM)
qbr - Linux կամուրջ
qvb և qvo - vEth զույգը միացված է Linux կամրջին և Open vSwitch կամուրջին
br-int, br-tun, br-vlan — Բացեք vSwitch կամուրջները
patch-, int-br-, phy-br- - Բացել vSwitch patch ինտերֆեյսները, որոնք միացնում են կամուրջները
qg, qr, ha, fg, sg - Բացեք vSwitch պորտերը, որոնք օգտագործվում են վիրտուալ սարքերի կողմից OVS-ին միանալու համար
Ինչպես հասկանում եք, եթե մենք կամրջում ունենք qvb95d96a75-a0 պորտ, որը vEth զույգ է, ապա ինչ-որ տեղ կա դրա նմանակը, որը տրամաբանորեն պետք է կոչվի qvo95d96a75-a0: Եկեք տեսնենք, թե ինչ նավահանգիստներ կան OVS-ում:
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
br-ex:
br-ex 65534/1: (internal)
phy-br-ex 1/none: (patch: peer=int-br-ex)
br-int:
br-int 65534/2: (internal)
int-br-ex 1/none: (patch: peer=phy-br-ex)
patch-tun 2/none: (patch: peer=patch-int)
qvo5bd37136-47 6/6: (system)
qvo95d96a75-a0 3/5: (system)
br-tun:
br-tun 65534/3: (internal)
patch-int 1/none: (patch: peer=patch-tun)
vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ Ինչպես տեսնում ենք, նավահանգիստը գտնվում է br-int-ում։ Br-int-ը գործում է որպես անջատիչ, որն ավարտում է վիրտուալ մեքենայի նավահանգիստները: Բացի qvo95d96a75-a0-ից, ելքում տեսանելի է qvo5bd37136-47 նավահանգիստը: Սա երկրորդ վիրտուալ մեքենայի պորտն է: Արդյունքում, մեր դիագրամն այժմ ունի հետևյալ տեսքը.
Հարց, որը պետք է անմիջապես հետաքրքրի ուշադիր ընթերցողին. ո՞րն է linux կամուրջը վիրտուալ մեքենայի պորտի և OVS պորտի միջև: Բանն այն է, որ մեքենան պաշտպանելու համար օգտագործվում են անվտանգության խմբեր, որոնք ոչ այլ ինչ են, քան iptable-ներ։ OVS-ը չի աշխատում iptable-ների հետ, ուստի այս «կռունկը» հայտնագործվել է: Այնուամենայնիվ, այն դառնում է հնացած. նոր թողարկումներում այն փոխարինվում է conntrack-ով:
Այսինքն, ի վերջո սխեման այսպիսի տեսք ունի.
Երկու մեքենա մեկ հիպերվիզորի վրա մեկ L2 ցանցում
Քանի որ այս երկու VM-ները տեղակայված են միևնույն L2 ցանցում և նույն հիպերվիզորում, նրանց միջև տրաֆիկը տրամաբանորեն կհոսի տեղական br-int-ի միջոցով, քանի որ երկու մեքենաներն էլ կլինեն նույն VLAN-ի վրա.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface Type Source Model MAC
-------------------------------------------------------
tap5bd37136-47 bridge qbr5bd37136-47 virtio fa:16:3e:83:ad:a4
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int
port VLAN MAC Age
6 1 fa:16:3e:83:ad:a4 0
3 1 fa:16:3e:44:98:20 0
[heat-admin@overcloud-novacompute-0 ~]$ Երկու մեքենա տարբեր հիպերվիզորների վրա նույն L2 ցանցում
Հիմա տեսնենք, թե ինչպես է երթևեկությունը ընթանալու նույն L2 ցանցի երկու մեքենաների միջև, որոնք գտնվում են տարբեր հիպերվիզորների վրա: Անկեղծ ասած, ոչինչ շատ չի փոխվի, պարզապես հիպերվիզորների միջև տրաֆիկը կանցնի vxlan թունելով։ Դիտարկենք մի օրինակ։
Վիրտուալ մեքենաների հասցեները, որոնց միջև մենք դիտելու ենք երթևեկությունը.
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface Type Source Model MAC
-------------------------------------------------------
tap95d96a75-a0 bridge qbr95d96a75-a0 virtio fa:16:3e:44:98:20
[heat-admin@overcloud-novacompute-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface Type Source Model MAC
-------------------------------------------------------
tape7e23f1b-07 bridge qbre7e23f1b-07 virtio fa:16:3e:72:ad:53
[heat-admin@overcloud-novacompute-1 ~]$ Մենք նայում ենք վերահասցեավորման աղյուսակին br-int-ով compute-0-ում.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
2 1 fa:16:3e:72:ad:53 1
[heat-admin@overcloud-novacompute-0 ~]Երթևեկությունը պետք է գնա դեպի նավահանգիստ 2. եկեք տեսնենք, թե ինչպիսի նավահանգիստ է դա.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$Սա patch-tun-ն է, այսինքն՝ ինտերֆեյսը br-tun-ում: Տեսնենք, թե ինչ է պատահում br-tun փաթեթի հետ.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ Փաթեթը փաթեթավորված է VxLAN-ով և ուղարկվում է 2-րդ նավահանգիստ: Տեսնենք, թե ուր է տանում 2-րդ նավահանգիստը.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:b2:d1:f8:21:96:66
2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$Սա vxlan թունել է compute-1-ում.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$Եկեք գնանք compute-1 և տեսնենք, թե ինչ կլինի հետո փաթեթի հետ.
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
2 1 fa:16:3e:44:98:20 1
[heat-admin@overcloud-novacompute-1 ~]$ Mac-ը գտնվում է compute-1-ի br-int վերահասցեավորման աղյուսակում, և ինչպես երևում է վերևի ելքից, այն տեսանելի է 2-րդ պորտի միջոցով, որը նավահանգիստն է դեպի br-tun:
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46Դե, ապա մենք տեսնում ենք, որ br-int-ում compute-1-ում կա նպատակակետային կակաչ.
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
3 1 fa:16:3e:72:ad:53 0
[heat-admin@overcloud-novacompute-1 ~]$ Այսինքն՝ ստացված փաթեթը կթռչի դեպի 3-րդ նավահանգիստ, որի հետևում արդեն կա վիրտուալ մեքենայի օրինակ-00000003։
Վիրտուալ ենթակառուցվածքում սովորելու համար Openstack-ի տեղադրման գեղեցկությունն այն է, որ մենք հեշտությամբ կարող ենք գրավել հիպերվիզորների միջև տրաֆիկը և տեսնել, թե ինչ է կատարվում դրա հետ: Սա այն է, ինչ մենք հիմա կանենք, գործարկել tcpdump-ը vnet պորտում դեպի compute-0:
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
*****************omitted*******************Առաջին տողը ցույց է տալիս, որ Patek-ը 10.0.1.85 հասցեից գնում է 10.0.1.88 հասցե (ICMP տրաֆիկ), և այն փաթաթված է vni 22-ով VxLAN փաթեթով, իսկ փաթեթը գնում է 192.168.255.19 (հաշվարկ-0) հոսթից մինչև 192.168.255.26: .1 (հաշվարկ-XNUMX): Մենք կարող ենք ստուգել, որ VNI-ը համապատասխանում է ovs-ում նշվածին:
Եկեք վերադառնանք այս տողին actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],ելք:2: 0x16-ը vni է տասնվեցական թվային համակարգում: Այս թիվը փոխարկենք 16-րդ համակարգի.
16 = 6*16^0+1*16^1 = 6+16 = 22Այսինքն՝ vni-ն համապատասխանում է իրականությանը։
Երկրորդ տողում ցույց է տրված հետադարձ երթեւեկությունը, լավ, բացատրելն իմաստ չունի, այնտեղ ամեն ինչ պարզ է։
Երկու մեքենա տարբեր ցանցերում (միջցանցային երթուղի)
Այսօրվա վերջին դեպքը ցանցերի միջև երթուղավորումն է մեկ նախագծի շրջանակներում՝ օգտագործելով վիրտուալ երթուղիչ: Մենք դիտարկում ենք դեպք առանց DVR-ի (մենք կանդրադառնանք մեկ այլ հոդվածում), ուստի երթուղավորումը տեղի է ունենում ցանցի հանգույցում։ Մեր դեպքում ցանցային հանգույցը չի տեղադրվում առանձին էության մեջ և գտնվում է կառավարման հանգույցի վրա։
Նախ, եկեք տեսնենք, որ երթուղավորումն աշխատում է.
$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 msՔանի որ այս դեպքում փաթեթը պետք է գնա gateway և ուղղորդվի այնտեղ, մենք պետք է պարզենք gateway-ի MAC հասցեն, որի համար մենք նայում ենք ARP աղյուսակին օրինակում.
$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether] on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether] on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether] on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether] on eth0Հիմա տեսնենք, թե ուր պետք է ուղարկվի երթևեկությունը նպատակակետով (10.0.1.254) fa:16:3e:c4:64:70.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
2 1 fa:16:3e:c4:64:70 0
[heat-admin@overcloud-novacompute-0 ~]$ Եկեք նայենք, թե որտեղ է տանում 2-րդ նավահանգիստը.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:7e:7f:28:1f:bd:54
2(patch-tun): addr:0a:bd:07:69:58:d9
3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ Ամեն ինչ տրամաբանական է, տրաֆիկը գնում է դեպի br-tun։ Տեսնենք, թե որ vxlan թունելում այն կփաթաթվի.
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ Երրորդ նավահանգիստը vxlan թունել է.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ Որը նայում է կառավարման հանգույցին.
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ Երթևեկությունը հասել է կառավարման հանգույցին, ուստի մենք պետք է գնանք այնտեղ և տեսնենք, թե ինչպես է երթուղավորումը տեղի ունենալու:
Ինչպես հիշում եք, վերահսկիչ հանգույցը ներսում ճիշտ նույն տեսքն ուներ, ինչ հաշվողական հանգույցը. նույն երեք կամուրջները, միայն br-ex-ն ուներ ֆիզիկական նավահանգիստ, որի միջոցով հանգույցը կարող էր երթևեկություն ուղարկել դուրս: Օրինակների ստեղծումը փոխեց հաշվողական հանգույցների կոնֆիգուրացիան՝ հանգույցներին ավելացվեցին linux bridge, iptables և ինտերֆեյսներ։ Ցանցերի և վիրտուալ երթուղիչի ստեղծումն իր հետքն է թողել նաև կառավարման հանգույցի կազմաձևման վրա։
Այսպիսով, ակնհայտ է, որ gateway MAC հասցեն պետք է լինի կառավարման հանգույցի br-int վերահասցեավորման աղյուսակում: Եկեք ստուգենք, որ այն կա և որտեղ է նայում.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
5 1 fa:16:3e:c4:64:70 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Mac-ը տեսանելի է qr-0c52b15f-8f պորտից: Եթե վերադառնանք Openstack-ի վիրտուալ նավահանգիստների ցանկին, ապա այս տեսակի պորտն օգտագործվում է տարբեր վիրտուալ սարքեր OVS-ին միացնելու համար: Ավելի ճշգրիտ լինելու համար, qr-ը վիրտուալ երթուղիչի պորտ է, որը ներկայացված է որպես անվանատարածք:
Տեսնենք, թե ինչ անունների տարածքներ կան սերվերի վրա.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ Երեք օրինակ։ Բայց անուններից դատելով՝ կարելի է գուշակել դրանցից յուրաքանչյուրի նպատակը։ Մենք ավելի ուշ կվերադառնանք ID 0 և 1-ով օրինակներին, այժմ մեզ հետաքրքրում է անվանատարածք qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254
[heat-admin@overcloud-controller-0 ~]$ Այս անվանատարածքը պարունակում է երկու ներքին, որոնք մենք ստեղծել ենք ավելի վաղ: Երկու վիրտուալ պորտերն էլ ավելացվել են br-int-ին: Եկեք ստուգենք qr-0c52b15f-8f նավահանգստի mac հասցեն, քանի որ տրաֆիկը, դատելով նպատակակետ Mac հասցեից, գնաց այս ինտերֆեյսի:
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.254 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fec4:6470 prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:c4:64:70 txqueuelen 1000 (Ethernet)
RX packets 5356 bytes 427305 (417.2 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5195 bytes 490603 (479.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[heat-admin@overcloud-controller-0 ~]$ Այսինքն, այս դեպքում ամեն ինչ աշխատում է ստանդարտ երթուղավորման օրենքներով։ Քանի որ տրաֆիկը նախատեսված է հյուրընկալող 10.0.2.8-ի համար, այն պետք է դուրս գա երկրորդ ինտերֆեյսի qr-92fa49b5-54 միջով և անցնի vxlan թունելով դեպի հաշվարկային հանգույց.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address HWtype HWaddress Flags Mask Iface
10.0.1.88 ether fa:16:3e:72:ad:53 C qr-0c52b15f-8f
10.0.1.90 ether fa:16:3e:83:ad:a4 C qr-0c52b15f-8f
10.0.2.8 ether fa:16:3e:6c:ad:9c C qr-92fa49b5-54
10.0.2.42 ether fa:16:3e:f5:0b:29 C qr-92fa49b5-54
10.0.1.85 ether fa:16:3e:44:98:20 C qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ Ամեն ինչ տրամաբանական է, ոչ մի անակնկալ։ Տեսնենք, թե որտեղ է տեսանելի հոսթ 10.0.2.8-ի poppy հասցեն br-int-ում.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
2 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:2e:58:b6:db:d5:de
2(patch-tun): addr:06:41:90:f0:9e:56
3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ Ինչպես և սպասվում էր, երթևեկությունը գնում է դեպի br-tun, եկեք տեսնենք, թե հաջորդ թունելն է գնում.
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
1(patch-int): addr:a2:69:00:c5:fa:ba
2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ Երթևեկությունը մտնում է թունել՝ 1-ը հաշվարկելու համար: Դե, compute-1-ում ամեն ինչ պարզ է. br-tun-ից փաթեթն անցնում է br-int և այնտեղից վիրտուալ մեքենայի ինտերֆեյս.
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
4 2 fa:16:3e:6c:ad:9c 1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr
1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
2(patch-tun): addr:46:cc:40:bd:20:da
3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ Եկեք ստուգենք, որ սա իսկապես ճիշտ ինտերֆեյս է.
[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.02429c001e1c no
qbr3210e8ec-c0 8000.ea27f45358be no qvb3210e8ec-c0
tap3210e8ec-c0
qbre7e23f1b-07 8000.b26ac0eded8a no qvbe7e23f1b-07
tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface Type Source Model MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge qbr3210e8ec-c0 virtio fa:16:3e:6c:ad:9c
[heat-admin@overcloud-novacompute-1 ~]$ Փաստորեն, մենք ամբողջ ճանապարհն անցանք փաթեթով։ Կարծում եմ՝ նկատեցիք, որ տրաֆիկը անցնում էր տարբեր vxlan թունելներով և դուրս էր գալիս տարբեր VNI-ներով։ Տեսնենք, թե ինչպիսի VNI-ներ են դրանք, որից հետո հանգույցի կառավարման պորտի վրա աղբանոց կհավաքենք և կհամոզվենք, որ երթևեկությունը հոսում է ճիշտ այնպես, ինչպես նկարագրված է վերևում։
Այսպիսով, 0-ն հաշվելու թունելն ունի հետևյալ գործողությունները=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],ելք՝3: Եկեք 0x16-ը փոխարկենք տասնորդական թվային համակարգի.
0x16 = 6*16^0+1*16^1 = 6+16 = 221-ը հաշվելու թունելն ունի հետևյալ VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],ելք՝2: Եկեք 0x63-ը փոխարկենք տասնորդական թվային համակարգի.
0x63 = 3*16^0+6*16^1 = 3+96 = 99Դե, հիմա եկեք նայենք աղբանոցին.
[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes
*****************omitted*******************
04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
*****************omitted*******************Առաջին փաթեթը vxlan փաթեթ է հյուրընկալող 192.168.255.19-ից (հաշվարկ-0) մինչև հոսթ 192.168.255.15 (control-1) vni 22-ով, որի ներսում ICMP փաթեթը փաթեթավորված է հյուրընկալող 10.0.1.85-ից մինչև հյուրընկալող 10.0.2.8: Ինչպես մենք հաշվարկեցինք վերևում, vni-ն համընկնում է այն, ինչ տեսանք ելքում:
Երկրորդ փաթեթը vxlan փաթեթ է հյուրընկալող 192.168.255.15-ից (control-1) մինչև հոսթ 192.168.255.26 (հաշվարկել-1) vni 99-ով, որի ներսում ICMP փաթեթը փաթեթավորված է հյուրընկալող 10.0.1.85-ից մինչև հյուրընկալող 10.0.2.8: Ինչպես մենք հաշվարկեցինք վերևում, vni-ն համընկնում է այն, ինչ տեսանք ելքում:
Հաջորդ երկու փաթեթները վերադարձի տրաֆիկ են 10.0.2.8-ից ոչ 10.0.1.85-ից:
Այսինքն, վերջում մենք ստացանք կառավարման հանգույցի հետևյալ սխեման.
Արդյո՞ք այս ամենը: Մենք մոռացել ենք երկու անվանատարածք.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ Քանի որ մենք խոսեցինք ամպային հարթակի ճարտարապետության մասին, լավ կլիներ, որ մեքենաները հասցեներ ստանան ավտոմատ կերպով DHCP սերվերից: Սրանք երկու DHCP սերվերներ են մեր երկու ցանցերի 10.0.1.0/24 և 10.0.2.0/24 համար:
Եկեք ստուգենք, որ դա ճիշտ է: Այս անվանատարածքում կա միայն մեկ հասցե՝ 10.0.1.1՝ հենց DHCP սերվերի հասցեն, և այն ներառված է նաև br-int-ում.
[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 1 bytes 28 (28.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 28 (28.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.0.1.1 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::f816:3eff:fee6:2c5c prefixlen 64 scopeid 0x20<link>
ether fa:16:3e:e6:2c:5c txqueuelen 1000 (Ethernet)
RX packets 129 bytes 9372 (9.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 49 bytes 6154 (6.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0Տեսնենք, արդյոք վերահսկիչ հանգույցում qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 պարունակող գործընթացներն իրենց անունով.
[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
root 640420 0.0 0.0 4220 348 ? Ss 11:31 0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+ 951620 0.0 0.0 112944 980 pts/0 S+ 18:50 0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ Գոյություն ունի նման գործընթաց և հիմնվելով վերը նշված ելքի մեջ ներկայացված տեղեկատվության վրա, մենք կարող ենք, օրինակ, տեսնել, թե ներկայումս ինչ ունենք վարձով.
[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$Արդյունքում մենք ստանում ենք ծառայությունների հետևյալ փաթեթը կառավարման հանգույցի վրա.
Դե, նկատի ունեցեք. սա ընդամենը 4 մեքենա է, 2 ներքին ցանց և մեկ վիրտուալ երթուղղիչ... Մենք հիմա այստեղ արտաքին ցանցեր չունենք, տարբեր նախագծերի փունջ, յուրաքանչյուրն իր սեփական ցանցերով (համընկնող), և մենք ունենք: բաշխված երթուղիչն անջատվեց, և ի վերջո, փորձարկման նստարանում կար միայն մեկ հսկիչ հանգույց (անսարքության հանդուրժողականության համար պետք է լինի երեք հանգույցների քվորում): Տրամաբանական է, որ առևտրի մեջ ամեն ինչ «մի փոքր» ավելի բարդ է, բայց այս պարզ օրինակում մենք հասկանում ենք, թե ինչպես պետք է դա աշխատի. 3 կամ 300 անվանատառ ունես, իհարկե, կարևոր է, բայց ամբողջի գործարկման տեսանկյունից։ կառուցվածքը, ոչինչ շատ չի փոխվի... թեև մինչև չես միացնի որոշ վաճառող SDN: Բայց դա բոլորովին այլ պատմություն է:
Հուսով եմ, որ հետաքրքիր էր: Եթե ունեք մեկնաբանություն/հավելումներ, կամ ինչ-որ տեղ ես ուղղակիորեն ստել եմ (ես մարդ եմ և իմ կարծիքը միշտ սուբյեկտիվ է լինելու), գրեք այն, ինչ պետք է ուղղել/ավելացնել, մենք ամեն ինչ կուղղենք/ավելացնենք:
Եզրափակելով, ես կցանկանայի մի քանի խոսք ասել Openstack-ը (և՛ վանիլային, և՛ վաճառող) VMWare-ի ամպային լուծման հետ համեմատելու մասին. վերջին մի քանի տարիների ընթացքում ինձ շատ հաճախ են տվել այս հարցը և, անկեղծ ասած, ես արդեն հոգնել եմ դրանից, բայց դեռ. Իմ կարծիքով, այս երկու լուծումները համեմատելը շատ դժվար է, բայց միանշանակ կարելի է ասել, որ երկու լուծումներում էլ կան թերություններ, և մեկ լուծում ընտրելիս պետք է կշռել դրական և բացասական կողմերը։
Եթե OpenStack-ը համայնքի վրա հիմնված լուծում է, ապա VMWare-ն իրավունք ունի անել միայն այն, ինչ ցանկանում է (կարդալ՝ ինչն է ձեռնտու) և դա տրամաբանական է, քանի որ այն առևտրային ընկերություն է, որը սովոր է գումար վաստակել իր հաճախորդներից: Բայց կա մեկ մեծ և չաղ ԲԱՅՑ. դուք կարող եք դուրս գալ OpenStack-ից, օրինակ Nokia-ից, և փոքր ծախսերով անցնել լուծմանը, օրինակ, Juniper-ից (Contrail Cloud), բայց դժվար թե կարողանաք դուրս գալ VMWare-ից: . Ինձ համար այս երկու լուծումներն այսպիսի տեսք ունեն՝ Openstack-ը (վաճառողը) պարզ վանդակ է, որի մեջ քեզ դրված են, բայց դու ունես բանալի և կարող ես ցանկացած պահի հեռանալ: VMWare-ը ոսկե վանդակ է, տերը ունի վանդակի բանալին, և դա ձեզ շատ կարժենա։
Ես չեմ գովազդում ոչ առաջին ապրանքը, ոչ երկրորդը. դուք ընտրում եք այն, ինչ ձեզ հարկավոր է: Բայց եթե ես նման ընտրություն ունենայի, ես կընտրեի երկու լուծումները՝ VMWare ՏՏ ամպի համար (ցածր բեռնվածություն, հեշտ կառավարում), OpenStack որոշ վաճառողից (Nokia-ն և Juniper-ը տալիս են շատ լավ բանտապահ լուծումներ)՝ Telecom cloud-ի համար։ Ես չէի օգտագործի Openstack-ը մաքուր ՏՏ-ի համար. դա նման է թնդանոթով ճնճղուկներին կրակելուն, բայց ավելորդությունից բացի այլ հակացուցումներ չեմ տեսնում: Այնուամենայնիվ, հեռահաղորդակցման մեջ VMWare-ի օգտագործումը նման է Ford Raptor-ով մանրացված քար տեղափոխելուն. այն գեղեցիկ է դրսից, բայց վարորդը պետք է կատարի 10 ուղևորություն մեկի փոխարեն:
Իմ կարծիքով, VMWare-ի ամենամեծ թերությունը նրա լիակատար փակությունն է. ընկերությունը ձեզ որևէ տեղեկություն չի տա այն մասին, թե ինչպես է այն աշխատում, օրինակ՝ vSAN կամ ինչ կա հիպերվիզորի միջուկում, դա պարզապես ձեռնտու չէ նրա համար, այսինքն՝ դուք երբեք մի դարձիր VMWare-ի փորձագետ. առանց վաճառողի աջակցության դու դատապարտված ես (շատ հաճախ ես հանդիպում եմ VMWare-ի փորձագետների, ովքեր շփոթված են չնչին հարցերից): Ինձ համար VMWare-ը մեքենա է գնում կողպված կապոցով. այո, դուք կարող եք ունենալ մասնագետներ, ովքեր կարող են փոխել ժամանակի գոտին, բայց միայն նա, ով ձեզ վաճառել է այս լուծումը, կարող է բացել կապոտը: Անձամբ ես չեմ սիրում լուծումներ, որոնց մեջ չեմ կարող տեղավորվել: Կասեք, որ գուցե ստիպված չլինեք գլխարկի տակ մտնել։ Այո, դա հնարավոր է, բայց ես ձեզ կնայեմ, երբ պետք է ամպի մեջ մեծ ֆունկցիա հավաքել 20-30 վիրտուալ մեքենաներից, 40-50 ցանցերից, որոնցից կեսը ցանկանում է դուրս գալ, իսկ երկրորդ կեսը խնդրում է. SR-IOV արագացում, հակառակ դեպքում ձեզ կպահանջվի ավելի շատ այս մեքենաներից մի քանի տասնյակ, հակառակ դեպքում կատարումը բավարար չի լինի:
Կան այլ տեսակետներ, այնպես որ միայն դուք կարող եք որոշել, թե ինչ ընտրել, և, որ ամենակարևորն է, այդ ժամանակ պատասխանատու կլինեք ձեր ընտրության համար: Սա ուղղակի իմ կարծիքն է՝ մարդ, ով տեսել և շոշափել է առնվազն 4 ապրանք՝ Nokia, Juniper, Red Hat և VMWare։ Այսինքն՝ ես համեմատելու բան ունեմ։
Source: www.habr.com
