Cisco ACI սկրիպտի այս կախարդական կտորի օգնությամբ դուք կարող եք արագ ցանց ստեղծել:
Cisco ACI տվյալների կենտրոնի ցանցային գործարանը գոյություն ունի արդեն հինգ տարի, բայց Habré-ն իրականում ոչինչ չի ասել դրա մասին, ուստի ես որոշեցի մի փոքր շտկել այն: Ես ձեզ իմ սեփական փորձից կասեմ, թե ինչ է դա, ինչի օգուտը և որտեղ այն ունի փոցխ:
Ի՞նչ է դա և որտեղի՞ց է առաջացել:
Երբ ACI-ն (Application Centric Infrastructure) հայտարարվեց 2013 թվականին, մրցակիցներն առաջ էին տանում տվյալների կենտրոնների ցանցերի ավանդական մոտեցումները միանգամից երեք կողմից:
Մի կողմից, OpenFlow-ի վրա հիմնված «առաջին սերնդի» SDN լուծումները խոստացան ցանցերը դարձնել ավելի ճկուն և միևնույն ժամանակ ավելի էժան: Գաղափարն այն էր, որ որոշումների կայացումը, որն ավանդաբար արվում էր սեփական անջատիչ ծրագրաշարի միջոցով, տեղափոխել կենտրոնական վերահսկիչ:
Այս կարգավորիչը կունենա մեկ տեսլական այն ամենի մասին, ինչ տեղի է ունենում, և դրա հիման վրա կծրագրավորեր բոլոր անջատիչների սարքավորումը հատուկ հոսքերի մշակման կանոնների մակարդակով:
Մյուս կողմից, ծածկույթի ցանցային լուծումները հնարավորություն տվեցին իրականացնել կապի և անվտանգության անհրաժեշտ քաղաքականություն՝ առանց ֆիզիկական ցանցում ընդհանրապես որևէ փոփոխության՝ վիրտուալացված հոսթերների միջև ծրագրային թունելներ կառուցելով: Այս մոտեցման ամենահայտնի օրինակը Nicira-ն էր, որը մինչ այդ արդեն ձեռք էր բերվել VMWare-ի կողմից 1,26 միլիարդ դոլարով և առաջացրեց ներկայիս VMWare NSX-ը: Իրավիճակին որոշ դիպուկ ավելացավ այն փաստը, որ Nicira-ի համահիմնադիրները նույն մարդիկ էին, ովքեր նախկինում կանգնած էին OpenFlow-ի ակունքներում՝ այժմ ասելով, որ տվյալների կենտրոնի գործարան կառուցելու համար։ .
Եվ վերջապես, բաց շուկայում առկա անջատիչ չիպերը (ինչը կոչվում է առևտրական սիլիցիում) հասել է հասունության մի փուլի, որտեղ դրանք իրական սպառնալիք են դարձել ավանդական անջատիչների արտադրողների համար: Եթե նախկինում յուրաքանչյուր վաճառող ինքնուրույն մշակում էր չիպեր իր անջատիչների համար, ապա ժամանակի ընթացքում երրորդ կողմի արտադրողների չիպերը, հիմնականում Broadcom-ից, սկսեցին կրճատել վաճառողի չիպերի հետ հեռավորությունը գործառույթների առումով և գերազանցել դրանք գնի / կատարողականի հարաբերակցությամբ: Հետևաբար, շատերը կարծում էին, որ իրենց դիզայնի չիպերի անջատիչների օրերը համարակալված են:
ACI-ն դարձել է Cisco-ի «ասիմետրիկ պատասխանը» (ավելի ճիշտ՝ նրա Insieme ընկերությունը, որը հիմնադրվել է իր նախկին աշխատակիցների կողմից) վերը նշված բոլորին։
Ո՞րն է տարբերությունը OpenFlow-ի հետ:
Գործառույթների բաշխման առումով ACI-ն իրականում OpenFlow-ի հակառակն է:
OpenFlow ճարտարապետության մեջ վերահսկիչը պատասխանատու է մանրամասն կանոններ (հոսքեր) գրելու համար:
բոլոր անջատիչների ապարատում, այսինքն՝ մեծ ցանցում, այն կարող է պատասխանատու լինել ցանցի հարյուրավոր կետերում տասնյակ միլիոնավոր գրառումներ պահպանելու և, ամենակարևորը, փոփոխելու համար, ուստի դրա կատարողականությունն ու հուսալիությունը դառնում են խոչընդոտ։ մեծ իրականացում։
ACI-ն օգտագործում է հակառակ մոտեցումը. իհարկե, կա նաև վերահսկիչ, բայց անջատիչները դրանից ստանում են բարձր մակարդակի հռչակագրային քաղաքականություն, և անջատիչն ինքն է կատարում դրանց փոխանցումը ապարատային հատուկ պարամետրերի մանրամասներին: Կարգավորիչը կարող է վերագործարկվել կամ ընդհանրապես անջատվել, և ցանցին ոչ մի վատ բան չի պատահի, բացառությամբ, իհարկե, այս պահին հսկողության բացակայությունից։ Հետաքրքիր է, որ ACI-ում կան իրավիճակներ, որոնցում OpenFlow-ը դեռ օգտագործվում է, բայց լոկալ հոսթի ներսում Open vSwitch ծրագրավորման համար:
ACI-ն ամբողջությամբ կառուցված է VXLAN-ի վրա հիմնված կափարիչ տրանսպորտի վրա, սակայն ներառում է հիմքում ընկած IP փոխադրումը որպես մեկ լուծման մաս: Cisco-ն սա անվանեց «ինտեգրված ծածկույթ» տերմին: Որպես ACI-ում ծածկույթների վերջնակետ, շատ դեպքերում օգտագործվում են գործարանային անջատիչներ (նրանք դա անում են կապի արագությամբ): Հոսթներից չի պահանջվում որևէ բան իմանալ գործարանի, ինկապսուլյացիայի և այլնի մասին, այնուամենայնիվ, որոշ դեպքերում (օրինակ, OpenStack հոսթինգները միացնելու համար), VXLAN տրաֆիկը կարող է բերվել նրանց մոտ:
ACI-ում ծածկույթներն օգտագործվում են ոչ միայն տրանսպորտային ցանցի միջոցով ճկուն կապ ապահովելու, այլ նաև մետատեղեկատվություն փոխանցելու համար (այն օգտագործվում է, օրինակ, անվտանգության քաղաքականության կիրառման համար):
Broadcom-ի չիպերը նախկինում Cisco-ի կողմից օգտագործվել են Nexus 3000 սերիայի անջատիչներում: Nexus 9000 ընտանիքում, որը հատուկ թողարկվել է ACI-ին աջակցելու համար, ի սկզբանե ներդրվել է հիբրիդային մոդել, որը կոչվում է Merchant +: Անջատիչը միաժամանակ օգտագործեց ինչպես նոր Broadcom Trident 2 չիպը, այնպես էլ Cisco-ի կողմից մշակված լրացուցիչ չիպը, որն իրականացնում է ACI-ի ողջ մոգությունը: Ըստ երևույթին, դա թույլ տվեց արագացնել արտադրանքի թողարկումը և նվազեցնել անջատիչի գինը մի մակարդակի, որը մոտ է այն մոդելներին, որոնք պարզապես հիմնված են Trident 2-ի վրա: Այս մոտեցումը բավարար էր ACI-ի մատակարարումների առաջին երկու-երեք տարիների համար: Այս ընթացքում Cisco-ն մշակեց և թողարկեց հաջորդ սերնդի Nexus 9000-ը սեփական չիպերի վրա՝ ավելի մեծ կատարողականությամբ և առանձնահատկություններով, բայց նույն գների մակարդակով: Արտաքին բնութագրերը գործարանում փոխազդեցության առումով ամբողջությամբ պահպանված են։ Միևնույն ժամանակ, ներքին լցոնումն ամբողջությամբ փոխվել է՝ ռեֆակտորինգի նման մի բան, բայց երկաթի համար։
Ինչպես է աշխատում Cisco ACI Architecture-ը
Ամենապարզ դեպքում ACI-ն կառուցված է Klose ցանցի տոպոլոգիայի վրա կամ, ինչպես հաճախ են ասում, Spine-Leaf-ի վրա։ Ողնաշարի մակարդակի անջատիչները կարող են լինել երկուսից (կամ մեկից, եթե մենք չենք մտածում սխալների հանդուրժողականության մասին) մինչև վեցը: Համապատասխանաբար, որքան շատ լինեն դրանք, այնքան բարձր է անսարքության հանդուրժողականությունը (որքան ցածր է թողունակությունը և հուսալիության նվազումը վթարի կամ մեկ ողնաշարի պահպանման դեպքում) և ընդհանուր կատարումը: Բոլոր արտաքին կապերն անցնում են տերևի մակարդակի անջատիչներին. սրանք սերվերներ են և արտաքին ցանցերի հետ կապակցում L2 կամ L3-ի միջոցով և միացնում APIC կարգավորիչները: Ընդհանուր առմամբ, ACI-ով ոչ միայն կոնֆիգուրացիա, այլև վիճակագրության հավաքագրում, ձախողումների մոնիտորինգ և այլն, ամեն ինչ արվում է կարգավորիչների միջերեսի միջոցով, որոնցից երեքը կան ստանդարտ չափսի իրականացումներում:
Դուք երբեք չպետք է միացնեք անջատիչներին կոնսոլով, նույնիսկ ցանցը գործարկելու համար. վերահսկիչն ինքն է հայտնաբերում անջատիչները և դրանցից հավաքում գործարան, ներառյալ սպասարկման բոլոր արձանագրությունների կարգավորումները, հետևաբար, ի դեպ, շատ կարևոր է. Գրեք տեղադրման ընթացքում տեղադրվող սարքավորումների սերիական համարները, որպեսզի հետագայում ստիպված չլինեք գուշակել, թե որ անջատիչը որ դարակում է գտնվում: Անսարքությունների վերացման համար, անհրաժեշտության դեպքում, դուք կարող եք միանալ անջատիչներին SSH-ի միջոցով. դրանք բավականին ուշադիր վերարտադրում են Cisco-ի սովորական շոուի հրամանները:
Ներքին մասում գործարանն օգտագործում է IP տրանսպորտ, ուստի դրա մեջ չկա Spanning Tree և անցյալի այլ սարսափներ. բոլոր օղակները ներգրավված են, և խափանումների դեպքում կոնվերգենցիան շատ արագ է: Գործվածքի մեջ երթևեկությունը փոխանցվում է VXLAN-ի վրա հիմնված թունելների միջոցով: Ավելի ճիշտ, Cisco-ն ինքն է անվանում iVXLAN encapsulation, և այն տարբերվում է սովորական VXLAN-ից նրանով, որ ցանցի վերնագրի վերապահված դաշտերը օգտագործվում են ծառայության տեղեկատվությունը փոխանցելու համար, հիմնականում, EPG խմբի հետ տրաֆիկի փոխհարաբերությունների մասին: Սա թույլ է տալիս կիրառել սարքավորումների խմբերի միջև փոխգործակցության կանոնները՝ օգտագործելով նրանց համարները այնպես, ինչպես հասցեները օգտագործվում են սովորական մուտքի ցուցակներում:
Թունելները թույլ են տալիս և՛ L2 հատվածները, և՛ L3 հատվածները (այսինքն՝ VRF) ձգվել ներքին IP տրանսպորտի միջոցով: Այս դեպքում լռելյայն դարպասը բաշխվում է: Սա նշանակում է, որ յուրաքանչյուր անջատիչ պատասխանատու է գործվածք մտնող երթևեկության ուղղման համար: Երթևեկության հոսքի տրամաբանության առումով ACI-ն նման է VXLAN/EVPN գործվածքին:
Եթե այո, ապա որո՞նք են տարբերությունները: Մնացած ամեն ինչ!
Թիվ մեկ տարբերությունը, որը դուք հանդիպում եք ACI-ի հետ, այն է, թե ինչպես են սերվերները միացված ցանցին: Ավանդական ցանցերում և՛ ֆիզիկական սերվերների, և՛ վիրտուալ մեքենաների ներառումը գնում է դեպի VLAN, և մնացած ամեն ինչ կախված է դրանցից՝ կապ, անվտանգություն և այլն: ACI-ում օգտագործվում է դիզայն, որը Cisco-ն անվանում է EPG (End-point Group), որից փախչելու տեղ չկա: Հնարավո՞ր է արդյոք այն հավասարեցնել VLAN-ին: Այո, բայց այս դեպքում հնարավորություն կա կորցնելու ACI-ի տվածի մեծ մասը:
Ինչ վերաբերում է EPG-ին, մուտքի բոլոր կանոնները ձևակերպված են, իսկ ACI-ում լռելյայն օգտագործվում է «սպիտակ ցուցակի» սկզբունքը, այսինքն՝ թույլատրվում է միայն երթևեկությունը, որի անցումը բացահայտորեն թույլատրված է։ Այսինքն՝ մենք կարող ենք ստեղծել «Web» և «MySQL» EPG խմբերը և սահմանել կանոն, որը թույլ է տալիս նրանց միջև հաղորդակցվել միայն 3306 նավահանգստում: Սա կաշխատի առանց ցանցի հասցեների հետ կապվելու և նույնիսկ նույն ենթացանցում:
Մենք ունենք հաճախորդներ, ովքեր ընտրել են ACI-ն հենց այս հատկության պատճառով, քանի որ այն թույլ է տալիս սահմանափակել մուտքը սերվերների միջև (վիրտուալ կամ ֆիզիկական, կարևոր չէ)՝ առանց դրանք ենթացանցերի միջև քաշելու, ինչը նշանակում է առանց հասցեագրման դիպչելու: Այո, այո, մենք գիտենք, որ ոչ ոք ձեռքով չի նշանակում IP հասցեներ հավելվածների կոնֆիգուրացիաներում, այնպես չէ՞:
ACI-ում երթևեկության կանոնները կոչվում են պայմանագրեր: Նման պայմանագրում բազմաշերտ հավելվածի մեկ կամ մի քանի խմբեր կամ մակարդակներ դառնում են ծառայություններ մատուցող (ասենք՝ տվյալների բազայի ծառայություն), մյուսները՝ սպառող։ Պայմանագիրը կարող է պարզապես փոխանցել երթևեկությունը, կամ կարող է անել ավելի բարդ բան, օրինակ՝ ուղղել այն դեպի firewall կամ հավասարակշռող, ինչպես նաև փոխել QoS արժեքը:
Ինչպե՞ս են սերվերները մտնում այս խմբերի մեջ: Եթե դրանք ֆիզիկական սերվերներ են կամ գոյություն ունեցող ցանցում ընդգրկված ինչ-որ բան, որի մեջ մենք ստեղծել ենք VLAN բեռնախցիկ, ապա դրանք EPG-ում տեղադրելու համար ձեզ հարկավոր է մատնանշել անջատիչ պորտը և դրա վրա օգտագործվող VLAN-ը: Ինչպես տեսնում եք, VLAN-ները հայտնվում են այնտեղ, որտեղ դուք չեք կարող անել առանց դրանց:
Եթե սերվերները վիրտուալ մեքենաներ են, ապա բավական է դիմել միացված վիրտուալացման միջավայրին, և ամեն ինչ ինքնըստինքյան կկատարվի. կստեղծվի պորտ խումբ (VMWare-ի առումով)՝ VM-ը միացնելու համար, անհրաժեշտ VLAN-ները կամ VXLAN-ները։ նշանակված կլինեն, դրանք կգրանցվեն անհրաժեշտ անջատիչ պորտերում և այլն: Այսպիսով, չնայած ACI-ն կառուցված է ֆիզիկական ցանցի շուրջ, վիրտուալ սերվերների համար կապերը շատ ավելի պարզ են թվում, քան ֆիզիկականների համար: ACI-ն արդեն ունի ներկառուցված կապ VMWare-ի և MS Hyper-V-ի հետ, ինչպես նաև աջակցություն OpenStack-ի և RedHat վիրտուալացման համար: Ինչ-որ պահից ի վեր հայտնվել է նաև ներկառուցված աջակցություն կոնտեյներային հարթակների համար. որ խմբերի մեջ են մտնում։
Բացի որոշակի նավահանգիստների խմբում ընդգրկվելուց, վիրտուալ սերվերներն ունեն լրացուցիչ հատկություններ՝ անուն, ատրիբուտներ և այլն, որոնք կարող են օգտագործվել որպես չափորոշիչներ՝ դրանք մեկ այլ խմբին փոխանցելու համար, ասենք, երբ VM-ն վերանվանվում է կամ լրացուցիչ պիտակ է հայտնվում: այն. Cisco-ն սա անվանում է միկրո-հատվածային խմբեր, չնայած, մեծ հաշվով, դիզայնն ինքնին, որը կարող է նույն ենթացանցում EPG-ների տեսքով ստեղծել բազմաթիվ անվտանգության սեգմենտներ, նույնպես բավականին միկրոհատվածացում է: Դե, վաճառողը ավելի լավ գիտի:
EPG-ներն իրենք զուտ տրամաբանական կոնստրուկցիաներ են, որոնք կապված չեն կոնկրետ անջատիչների, սերվերների և այլնի հետ, այնպես որ դուք կարող եք անել այնպիսի բաներ, որոնք հիմնված են դրանց վրա (հավելվածներ և վարձակալներ), որոնք դժվար է անել սովորական ցանցերում, օրինակ՝ կլոնավորումը: Արդյունքում, ենթադրենք, շատ հեշտ է կլոնավորել արտադրական միջավայրը, որպեսզի ստանանք թեստային միջավայր, որը երաշխավորված է, որ նույնական է արտադրական միջավայրին: Դուք կարող եք դա անել ձեռքով, բայց դա ավելի լավ է (և ավելի հեշտ) API-ի միջոցով:
Ընդհանուր առմամբ, ACI-ի կառավարման տրամաբանությունը բոլորովին նման չէ նրան, ինչ սովորաբար հանդիպում եք
նույն Cisco-ի ավանդական ցանցերում. ծրագրային ինտերֆեյսը առաջնային է, իսկ GUI-ն կամ CLI-ն երկրորդական են, քանի որ դրանք աշխատում են նույն API-ի միջոցով: Հետևաբար, գրեթե բոլորը, ովքեր ներգրավված են ACI-ում, որոշ ժամանակ անց սկսում են նավարկել կառավարման համար օգտագործվող օբյեկտի մոդելը և ավտոմատացնել ինչ-որ բան իրենց կարիքներին համապատասխան: Դա անելու ամենահեշտ ձևը Python-ն է՝ դրա համար հարմար պատրաստի գործիքներ կան։
Խոստացված փոցխ
Հիմնական խնդիրն այն է, որ ACI-ում շատ բաներ այլ կերպ են արվում: Դրա հետ նորմալ աշխատելու համար հարկավոր է վերապատրաստվել։ Սա հատկապես ճիշտ է խոշոր հաճախորդների ցանցային օպերացիոն թիմերի համար, որտեղ ինժեներները տարիներ շարունակ «նշանակում են VLAN-ներ» ըստ պահանջի: Այն փաստը, որ այժմ VLAN-ներն այլևս VLAN-ներ չեն, և ձեզ հարկավոր չէ ձեռքով VLAN-ներ ստեղծել՝ վիրտուալացված հոսթերում նոր ցանցեր տեղադրելու համար, ամբողջովին փչում է ավանդական ցանցերի տանիքը և ստիպում նրանց կառչել ծանոթ մոտեցումներից: Հարկ է նշել, որ Cisco-ն փորձել է մի փոքր քաղցրացնել հաբը և կարգավորիչին ավելացրել է «NXOS-ի նման» CLI, որը թույլ է տալիս կոնֆիգուրացիա կատարել ավանդական անջատիչների նման ինտերֆեյսից։ Բայց այնուամենայնիվ, ACI-ն նորմալ օգտագործելու համար պետք է հասկանալ, թե ինչպես է այն աշխատում:
Գների առումով, մեծ և միջին մասշտաբներով, ACI ցանցերն իրականում չեն տարբերվում Cisco-ի սարքավորումների ավանդական ցանցերից, քանի որ դրանց կառուցման համար օգտագործվում են նույն անջատիչները (Nexus 9000-ը կարող է աշխատել ACI-ով և ավանդական ռեժիմով և այժմ դարձել է հիմնականը: «աշխատանքային ձի» տվյալների կենտրոնների նոր նախագծերի համար): Բայց երկու անջատիչների տվյալների կենտրոնների համար կարգավորիչների առկայությունը և Spine-Leaf ճարտարապետությունը, իհարկե, իրենց զգացնել են տալիս: Վերջերս հայտնվել է Mini ACI գործարանը, որում երեք կարգավորիչներից երկուսը փոխարինվում են վիրտուալ մեքենաներով։ Սա նվազեցնում է ծախսերի տարբերությունը, բայց այն դեռ մնում է: Այսպիսով, հաճախորդի համար ընտրությունը թելադրված է նրանով, թե որքանով է նա հետաքրքրված անվտանգության առանձնահատկություններով, վիրտուալացման հետ ինտեգրմամբ, վերահսկման մեկ կետով և այլն:
Source: www.habr.com