ՍԴՍՄ-ն ավարտվեց, բայց գրելու անզուսպ ցանկությունը մնում է.

Երկար տարիներ մեր եղբայրը տառապում էր սովորական աշխատանք կատարելուց, մատները խաչակնքելով նախքան գործը սկսելը և գիշերային ետդարձի պատճառով քնելու պակաս։
Բայց մութ ժամանակներն ավարտվում են։

Այս հոդվածով ես կսկսեմ մի շարք, թե ինչպես ինձ երևում է ավտոմատացում.
Ճանապարհին մենք կհասկանանք ավտոմատացման, փոփոխականների պահպանման, ձևավորման ձևավորման, RestAPI, NETCONF, YANG, YDK փուլերը և շատ ծրագրավորում կանենք։
Ինձ նշանակում է, որ ա) դա օբյեկտիվ ճշմարտություն չէ, բ) դա անվերապահորեն լավագույն մոտեցումը չէ, գ) իմ կարծիքը, անգամ առաջին հոդվածից մինչև վերջին հոդվածի շարժման ընթացքում, կարող է փոխվել՝ ճիշտն ասած՝ նախագծի փուլից մինչև հրապարակումը, ես ամեն ինչ ամբողջությամբ վերաշարադրեցի երկու անգամ։

Պարունակություն

1. Նպատակը
   1. Ցանցը նման է մեկ օրգանիզմի
   2. Կազմաձևման փորձարկում
   3. Տարբերակում
   4. Ծառայությունների մոնիտորինգ և ինքնաբուժում

2. Նշանակում է
   1. Գույքագրման համակարգ
   2. IP տարածքի կառավարման համակարգ
   3. Ցանցային ծառայության նկարագրության համակարգ
   4. Սարքի սկզբնավորման մեխանիզմ
   5. Վաճառող-ագնոստիկ կոնֆիգուրացիայի մոդել
   6. Վաճառողի համար հատուկ վարորդի ինտերֆեյս
   7. Սարքին կոնֆիգուրացիան հասցնելու մեխանիզմ
   8. CI / CD
   9. Կրկնօրինակման և շեղումների որոնման մեխանիզմ
   10. Մոնիտորինգի համակարգ

3. Ամփոփում

Ես կփորձեմ ADSM-ն անցկացնել SDSM-ից մի փոքր տարբերվող ձևաչափով։ Խոշոր, մանրամասն, համարակալված հոդվածները կշարունակեն հայտնվել, որոնց արանքում ես կհրապարակեմ փոքրիկ գրառումներ առօրյա փորձից։ Ես կփորձեմ այստեղ պայքարել պերֆեկցիոնիզմի դեմ և ոչ թե լիզել նրանցից յուրաքանչյուրին:

Որքան ծիծաղելի է, որ երկրորդ անգամ պետք է անցնես նույն ճանապարհով։

Սկզբում ես ինքս ստիպված էի հոդվածներ գրել ցանցերի մասին, քանի որ դրանք RuNet-ում չէին:

Այժմ ես չկարողացա գտնել մի համապարփակ փաստաթուղթ, որը կհամակարգի ավտոմատացման մոտեցումները և կվերլուծեր վերը նշված տեխնոլոգիաները՝ օգտագործելով պարզ գործնական օրինակներ:

Ես կարող եմ սխալվել, ուստի խնդրում եմ տրամադրել օգտակար ռեսուրսների հղումներ: Այնուամենայնիվ, սա չի փոխի գրելու իմ վճռականությունը, քանի որ հիմնական նպատակը ինքս ինչ-որ բան սովորելն է, իսկ ուրիշների համար կյանքը հեշտացնելը հաճելի բոնուս է, որը շոյում է փորձի փոխանակման գենը:

Մենք կփորձենք վերցնել միջին չափի LAN DC տվյալների կենտրոն և մշակել ավտոմատացման ամբողջ սխեման:
Ես որոշ բաներ կանեմ գրեթե առաջին անգամ քեզ հետ:

Ես օրիգինալ չեմ լինի այստեղ նկարագրված գաղափարների և գործիքների մեջ: Դմիտրի Ֆիգոլն ունի գերազանց ալիք այս թեմայով հոսքերով.
Հոդվածները շատ առումներով կհամընկնեն դրանց հետ:

LAN DC-ն ունի 4 DC, մոտ 250 անջատիչ, կես տասնյակ երթուղիչներ և մի քանի firewalls:
Ոչ թե ֆեյսբուք, այլ բավական է, որպեսզի խորը մտածես ավտոմատացման մասին:
Կարծիք կա, սակայն, որ եթե ունեք 1-ից ավելի սարք, ապա արդեն ավտոմատացում է անհրաժեշտ։
Իրականում, դժվար է պատկերացնել, որ այժմ ինչ-որ մեկը կարող է ապրել առանց գոնե մի փաթեթի ծնկի սցենարների:
Չնայած ես լսել եմ, որ կան գրասենյակներ, որտեղ IP հասցեները պահվում են Excel-ում, և հազարավոր ցանցային սարքերից յուրաքանչյուրը կարգավորվում է ձեռքով և ունի իր յուրահատուկ կոնֆիգուրացիան։ Սա, իհարկե, կարելի է փոխանցել որպես ժամանակակից արվեստ, բայց ինժեների զգացմունքները անպայման կվիրավորվեն:

Նպատակը

Այժմ մենք կդնենք առավել վերացական նպատակները.

• Ցանցը նման է մեկ օրգանիզմի
• Կազմաձևման փորձարկում
• Ցանցի վիճակի տարբերակում
• Ծառայությունների մոնիտորինգ և ինքնաբուժում

Հետագայում այս հոդվածում մենք կանդրադառնանք, թե ինչ միջոցներ ենք օգտագործելու, իսկ հետագա նպատակներին և միջոցներին մանրամասն կանդրադառնանք։

Ցանցը նման է մեկ օրգանիզմի

Շարքի որոշիչ արտահայտությունը, թեև առաջին հայացքից կարող է այնքան էլ նշանակալից չթվալ. մենք կկարգավորենք ցանցը, այլ ոչ թե առանձին սարքեր.
Վերջին տարիներին մենք նկատում ենք շեշտադրումների փոփոխություն դեպի ցանցը որպես մեկ միավոր դիտարկելու ուղղությամբ, հետևաբար՝ Softwareրագրային ապահովմամբ սահմանված ցանցեր, Մտադրությունների վրա հիմնված ցանցեր и Ինքնավար ցանցեր.
Ի վերջո, ինչ է պետք հավելվածներին գլոբալ ցանցից՝ կապ A և B կետերի միջև (լավ, երբեմն +B-Z) և մեկուսացում այլ հավելվածներից և օգտվողներից:

Եվ այսպես, այս շարքի մեր խնդիրն է համակարգ կառուցել, պահպանելով ընթացիկ կոնֆիգուրացիան ամբողջ ցանցը, որն արդեն տարրալուծվում է յուրաքանչյուր սարքի վրա իրական կազմաձևում՝ իր դերին և գտնվելու վայրին համապատասխան:
Համակարգ ցանցի կառավարումը ենթադրում է, որ փոփոխություններ կատարելու համար մենք կապվում ենք դրա հետ, և այն, իր հերթին, հաշվարկում է յուրաքանչյուր սարքի համար ցանկալի վիճակը և կարգավորում այն:
Այս կերպ մենք նվազագույնի ենք հասցնում CLI-ի ձեռքով մուտքը գրեթե զրոյի. սարքի կարգավորումներում կամ ցանցի դիզայնի ցանկացած փոփոխություն պետք է ձևակերպվի և փաստաթղթավորվի, և միայն դրանից հետո փոխանցվի ցանցի անհրաժեշտ տարրերին:

Այսինքն, օրինակ, եթե մենք որոշեցինք, որ այսուհետ Կազանի դարակային անջատիչները պետք է հայտարարեն երկու ցանցի փոխարեն, մենք.

1. Սկզբում մենք փաստագրում ենք համակարգերի փոփոխությունները
2. Բոլոր ցանցային սարքերի թիրախային կոնֆիգուրացիայի ստեղծում
3. Մենք գործարկում ենք ցանցի կոնֆիգուրացիայի թարմացման ծրագիրը, որը հաշվարկում է, թե ինչ է պետք հեռացնել յուրաքանչյուր հանգույցից, ինչ ավելացնել, և հանգույցները բերում է ցանկալի վիճակի։

Միևնույն ժամանակ, մենք ձեռքով փոփոխություններ ենք կատարում միայն առաջին քայլում։

Կազմաձևման փորձարկում

Հայտնի էոր խնդիրների 80%-ը առաջանում է կոնֆիգուրացիայի փոփոխության ժամանակ, դրա անուղղակի վկայությունն այն է, որ ամանորյա տոներին ամեն ինչ սովորաբար հանգիստ է։
Ես անձամբ ականատես եմ եղել մարդկային սխալի պատճառով տասնյակ գլոբալ խափանումների. սխալ հրաման, կոնֆիգուրացիան կատարվել է սխալ ճյուղում, համայնքը մոռացել է, MPLS-ը գլոբալ կերպով քանդվել է երթուղիչի վրա, սարքավորման հինգ կտոր կարգավորվել է, բայց սխալը չի ​​եղել։ վեցերորդ օրը կատարվել են մեկ այլ անձի կողմից կատարված հին փոփոխություններ։ Կան մի տոննա սցենարներ.

Ավտոմատացումը մեզ թույլ կտա ավելի քիչ սխալներ թույլ տալ, բայց ավելի մեծ մասշտաբով: Այս կերպ դուք կարող եք աղյուսել ոչ միայն մեկ սարքը, այլ միանգամից ամբողջ ցանցը:

Անհիշելի ժամանակներից մեր պապերը ստուգում էին սրատես աչքով կատարված փոփոխությունների ճիշտությունը, պողպատե գնդիկները և ցանցի ֆունկցիոնալությունը դրանց գլորումից հետո:
Այն պապիկները, որոնց աշխատանքը հանգեցրել է պարապուրդի և աղետալի կորուստների, թողել են ավելի քիչ սերունդ և ժամանակի ընթացքում պետք է մահանան, բայց էվոլյուցիան դանդաղ գործընթաց է, և, հետևաբար, ոչ բոլորն են դեռևս առաջինը լաբորատորիայում փոփոխությունները փորձարկում:
Այնուամենայնիվ, առաջընթացի առաջատարն են նրանք, ովքեր ավտոմատացրել են կոնֆիգուրացիայի փորձարկման գործընթացը և դրա հետագա կիրառումը ցանցում: Այլ կերպ ասած, ես փոխառել եմ CI/CD ընթացակարգը (Շարունակական ինտեգրում, շարունակական տեղակայում) մշակողների կողմից:
Մասերից մեկում մենք կանդրադառնանք, թե ինչպես կարելի է դա իրականացնել՝ օգտագործելով տարբերակների կառավարման համակարգը, հավանաբար Github-ը:

Երբ դուք ընտելանում եք ցանցի CI/CD-ի գաղափարին, մեկ գիշերվա ընթացքում կոնֆիգուրացիան ստուգելու մեթոդը՝ այն կիրառելով արտադրական ցանցում, կթվա վաղ միջնադարյան անտեղյակություն: Մուրճով մարտագլխիկին հարվածելու պես մի տեսակ:

մասին գաղափարների օրգանական շարունակություն համակարգը ցանցի կառավարումը և CI/CD-ն դառնում է կազմաձևման ամբողջական տարբերակ:

Տարբերակում

Մենք կենթադրենք, որ ցանկացած փոփոխության դեպքում, նույնիսկ ամենաչնչին, նույնիսկ մեկ աննկատ սարքի վրա, ամբողջ ցանցը տեղափոխվում է մի վիճակից մյուսը:
Եվ մենք միշտ սարքի վրա հրաման չենք կատարում, մենք փոխում ենք ցանցի վիճակը։
Այսպիսով, եկեք այս պետությունները անվանենք տարբերակներ:

Ենթադրենք, որ ներկայիս տարբերակը 1.0.0 է:
Փոխվե՞լ է արդյոք ToR-ներից մեկի Loopback ինտերֆեյսի IP հասցեն: Սա փոքր տարբերակ է և համարակալվելու է 1.0.1:
Մենք վերանայեցինք BGP երթուղիների ներմուծման քաղաքականությունը՝ մի փոքր ավելի լուրջ՝ արդեն 1.1.0
Մենք որոշեցինք ազատվել IGP-ից և անցնել միայն BGP-ին, սա արդեն արմատական ​​դիզայնի փոփոխություն է՝ 2.0.0:

Միևնույն ժամանակ, տարբեր DC-ները կարող են ունենալ տարբեր տարբերակներ՝ ցանցը զարգանում է, տեղադրվում են նոր սարքավորումներ, ինչ-որ տեղ ավելացվում են ողնաշարի նոր մակարդակներ, այլ ոչ թե մյուսներում և այլն։

Մոտ իմաստային տարբերակում մենք կխոսենք առանձին հոդվածում:

Կրկնում եմ՝ ցանկացած փոփոխություն (բացի վրիպազերծման հրամաններից) տարբերակի թարմացում է։ Ադմինիստրատորները պետք է տեղեկացվեն ընթացիկ տարբերակից ցանկացած շեղումների մասին:

Նույնը վերաբերում է հետադարձ փոփոխություններին. սա վերջին հրամանների չեղարկում չէ, սա սարքի օպերացիոն համակարգի միջոցով հետադարձ կապ չէ. սա ամբողջ ցանցը բերում է նոր (հին) տարբերակի:

Ծառայությունների մոնիտորինգ և ինքնաբուժում

Այս ինքնին հասկանալի խնդիրը նոր մակարդակի է հասել ժամանակակից ցանցերում։
Հաճախ խոշոր ծառայություններ մատուցողները ընդունում են այն մոտեցումը, որ ձախողված ծառայությունը պետք է շատ արագ շտկվի և նորը բարձրացվի՝ պարզելու, թե ինչ է տեղի ունեցել:
«Շատ» նշանակում է, որ դուք պետք է առատաձեռնորեն պատված լինեք բոլոր կողմերից մոնիտորինգով, որը վայրկյանների ընթացքում կբացահայտի նորմայից ամենափոքր շեղումները:
Եվ այստեղ սովորական չափումները, ինչպիսիք են ինտերֆեյսի բեռնումը կամ հանգույցի առկայությունը, այլեւս բավարար չեն: Հերթապահի կողմից դրանց ձեռքով վերահսկելը նույնպես բավարար չէ։
Շատ բաների համար պետք է լինի Ինքնաբուժիչ — Մոնիտորինգի լույսերը կարմիր դարձան, և մենք գնացինք ու ինքներս քսեցինք սոսիը, որտեղ այն ցավում էր։

Եվ այստեղ մենք նաև վերահսկում ենք ոչ միայն առանձին սարքերը, այլև ողջ ցանցի առողջությունը՝ թե whitebox-ը, որը համեմատաբար հասկանալի է, և թե blackbox-ը, որն ավելի բարդ է:

Ի՞նչ է մեզ անհրաժեշտ նման հավակնոտ ծրագրեր իրականացնելու համար։

• Ունեցեք ցանցի բոլոր սարքերի ցանկը, դրանց գտնվելու վայրը, դերերը, մոդելները, ծրագրաշարի տարբերակները:
  kazan-leaf-1.lmu.net, Kazan, տերեւ, Juniper QFX 5120, R18.3.
• Ունենալ ցանցային ծառայությունների նկարագրության համակարգ:
  IGP, BGP, L2/3VPN, քաղաքականություն, ACL, NTP, SSH:
• Կարողանալ սկզբնավորել սարքը:
  Հոսթի անուն, Mgmt IP, Mgmt երթուղի, օգտվողներ, RSA-Ստեղներ, LLDP, NETCONF
• Կարգավորեք սարքը և կոնֆիգուրացիան բերեք ցանկալի (ներառյալ հին) տարբերակին:
• Փորձարկման կոնֆիգուրացիա
• Պարբերաբար ստուգեք բոլոր սարքերի կարգավիճակը ներկայիս սարքերից շեղումների համար և զեկուցեք, թե ում պետք է դա լինի:
  Մեկ գիշերվա ընթացքում ինչ-որ մեկը հանգիստ կանոն ավելացրեց ACL-ին.
• Մոնիտորինգի կատարումը:

Նշանակում է

Այն բավական բարդ է թվում, որպեսզի սկսենք նախագիծը բաղադրիչների տարրալուծել:

Եվ նրանցից տասը կլինեն.

1. Գույքագրման համակարգ
2. IP տարածքի կառավարման համակարգ
3. Ցանցային ծառայության նկարագրության համակարգ
4. Սարքի սկզբնավորման մեխանիզմ
5. Վաճառող-ագնոստիկ կոնֆիգուրացիայի մոդել
6. Վաճառողի համար հատուկ վարորդի ինտերֆեյս
7. Սարքին կոնֆիգուրացիան հասցնելու մեխանիզմ
8. CI / CD
9. Կրկնօրինակման և շեղումների որոնման մեխանիզմ
10. Մոնիտորինգի համակարգ

Սա, ի դեպ, օրինակ է, թե ինչպես փոխվեց ցիկլի նպատակների մասին տեսակետը՝ նախագծում կար 4 բաղադրիչ։

Նկարում ես պատկերել եմ բոլոր բաղադրիչները և հենց սարքը:
Փոխհատվող բաղադրիչները փոխազդում են միմյանց հետ:
Որքան մեծ է բլոկը, այնքան ավելի մեծ ուշադրություն պետք է դարձնել այս բաղադրիչին:

Բաղադրիչ 1. Գույքագրման համակարգ

Ակնհայտ է, որ մենք ուզում ենք իմանալ, թե ինչ սարքավորում որտեղ է գտնվում, ինչին է միացված։
Գույքագրման համակարգը ցանկացած ձեռնարկության անբաժանելի մասն է:
Ամենից հաճախ ձեռնարկությունն ունի ցանցային սարքերի առանձին գույքագրման համակարգ, որն ավելի կոնկրետ խնդիրներ է լուծում։
Որպես այս հոդվածաշարի մաս, մենք այն կանվանենք DCIM - Տվյալների կենտրոնի ենթակառուցվածքների կառավարում: Թեև DCIM տերմինն ինքնին, խստորեն ասած, շատ ավելին է ներառում:

Մեր նպատակների համար մենք դրանում կպահենք սարքի մասին հետևյալ տեղեկությունները.

• Գույքագրման համարը
• Վերնագիր/Նկարագրություն
• Մոդել (Huawei CE12800, Juniper QFX5120 և այլն:)
• Բնութագրական պարամետրեր (տախտակներ, միջերեսներ և այլն:)
• Դեր (Տերև, ողնաշար, սահմանային երթուղիչ և այլն:)
• Գտնվելու վայրը (շրջան, քաղաք, տվյալների կենտրոն, դարակ, միավոր)
• Սարքերի միջև փոխկապակցվածություն
• Ցանցի տոպոլոգիա

Միանգամայն պարզ է, որ մենք ինքներս ենք ուզում իմանալ այս ամենը։
Բայց սա կօգնի՞ ավտոմատացման նպատակներին:
Իհարկե.
Օրինակ, մենք գիտենք, որ Leaf անջատիչների վրա տվյալ տվյալների կենտրոնում, եթե դա Huawei է, VLAN-ում պետք է կիրառվեն որոշակի տրաֆիկի զտման ACL-ներ, իսկ եթե դա Juniper է, ապա ֆիզիկական ինտերֆեյսի 0 միավորի վրա:
Կամ դուք պետք է նոր Syslog սերվեր բացեք տարածաշրջանի բոլոր սահմաններում:

Դրանում մենք կպահենք վիրտուալ ցանցային սարքեր, օրինակ՝ վիրտուալ երթուղիչներ կամ արմատային ռեֆլեկտորներ։ Մենք կարող ենք ավելացնել DNS սերվերներ, NTP, Syslog և ընդհանրապես այն ամենը, ինչ այս կամ այն ​​կերպ առնչվում է ցանցին։

Բաղադրիչ 2. IP տարածքի կառավարման համակարգ

Այո, և մեր օրերում կան մարդկանց թիմեր, որոնք հետևում են Excel ֆայլի նախածանցներին և IP հասցեներին: Բայց ժամանակակից մոտեցումը դեռևս տվյալների շտեմարան է՝ nginx/apache-ի ճակատային մասով, API-ով և IP հասցեների և ցանցերի ձայնագրման լայն գործառույթներով՝ բաժանված VRF-ների:
IPAM - IP հասցեների կառավարում:

Մեր նպատակների համար մենք դրանում կպահենք հետևյալ տեղեկատվությունը.

• ՎԼԱՆ
• VRF
• Ցանցեր/Ենթացանցեր
• IP հասցեներ
• Հասցեների կապակցում սարքերին, ցանցերը տեղանքներին և VLAN համարներին

Կրկին պարզ է, որ մենք ուզում ենք համոզվել, որ երբ մենք նոր IP հասցե ենք հատկացնում ToR-ի հանգույցի համար, մենք չենք սայթաքի այն փաստի վրա, որ այն արդեն նշանակված է ինչ-որ մեկին: Կամ որ մենք օգտագործել ենք նույն նախածանցը երկու անգամ ցանցի տարբեր ծայրերում:
Բայց ինչպե՞ս է սա օգնում ավտոմատացմանը:
Հեշտությամբ.
Մենք խնդրում ենք համակարգում նախածանց Loopbacks դերով, որը պարունակում է տեղաբաշխման համար հասանելի IP հասցեներ. եթե այն գտնվի, մենք հատկացնում ենք հասցեն, եթե ոչ, խնդրում ենք ստեղծել նոր նախածանց:
Կամ սարքի կոնֆիգուրացիան ստեղծելիս մենք կարող ենք նույն համակարգից պարզել, թե որ VRF-ի միջերեսը պետք է տեղակայվի:
Եվ նոր սերվեր գործարկելիս սկրիպտը մուտք է գործում համակարգ, պարզում է, թե որ անջատիչում է գտնվում սերվերը, որ պորտում և որ ենթացանցն է հատկացված ինտերֆեյսին, և դրանից կհատկացնի սերվերի հասցեն:

Սա ենթադրում է DCIM-ը և IPAM-ը մեկ համակարգի մեջ միավորելու ցանկություն, որպեսզի չկրկնվեն գործառույթները և չծառայեն երկու նմանատիպ անձանց:
Դա այն է, ինչ մենք կանենք:

Բաղադրիչ 3. Ցանցային ծառայությունների նկարագրման համակարգ

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

• Ենթակառուցվածք
• Հաճախորդ.

Առաջինները նախատեսված են հիմնական կապի և սարքի կառավարումն ապահովելու համար: Դրանք ներառում են VTY, SNMP, NTP, Syslog, AAA, երթուղային արձանագրություններ, CoPP և այլն:
Վերջիններս հաճախորդի համար կազմակերպում են ծառայությունը՝ MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP և այլն:
Իհարկե, կան նաև սահմանային դեպքեր՝ որտե՞ղ ներառել MPLS LDP, BGP: Այո, և երթուղային արձանագրությունները կարող են օգտագործվել հաճախորդների համար: Բայց սա կարևոր չէ։

Ծառայությունների երկու տեսակները բաժանված են կազմաձևման պարզունակների.

• ֆիզիկական և տրամաբանական միջերեսներ (պիտակ/անտեգ, mtu)
• IP հասցեներ և VRF-ներ (IP, IPv6, VRF)
• ACL-ներ և երթևեկության մշակման քաղաքականություն
• Արձանագրություններ (IGP, BGP, MPLS)
• Ուղղորդման քաղաքականություն (նախածանցային ցուցակներ, համայնքներ, ASN զտիչներ):
• Կոմունալ ծառայություններ (SSH, NTP, LLDP, Syslog...)
• և այլն:

Թե կոնկրետ ինչպես ենք դա անելու, ես դեռ պատկերացում չունեմ։ Մենք դրան կանդրադառնանք առանձին հոդվածում:

Եթե ​​կյանքին մի փոքր ավելի մոտ լինի, ապա մենք կարող ենք դա նկարագրել
Leaf switch-ը պետք է ունենա BGP նիստեր բոլոր միացված Spine անջատիչների հետ, ներմուծի միացված ցանցերը գործընթացի մեջ և ընդունի միայն ցանցեր որոշակի նախածանցից Spine անջատիչներից: Սահմանափակեք CoPP IPv6 ND-ը մինչև 10 pps և այլն:
Իր հերթին, ողնաշարները սեանսներ են անցկացնում բոլոր միացված կապարների հետ՝ հանդես գալով որպես արմատային ռեֆլեկտորներ և դրանցից ընդունում են միայն որոշակի երկարության և որոշակի համայնքի երթուղիներ:

Բաղադրիչ 4. Սարքի սկզբնավորման մեխանիզմ

Այս վերնագրի ներքո ես համատեղում եմ բազմաթիվ գործողություններ, որոնք պետք է կատարվեն, որպեսզի սարքը հայտնվի ռադարում և հասանելի լինի հեռակա կարգով:

1. Մուտքագրեք սարքը գույքագրման համակարգում:
2. Ընտրեք կառավարման IP հասցե:
3. Սահմանեք դրա հիմնական մուտքը.
   Հոսթի անուն, կառավարման IP հասցե, երթուղի դեպի կառավարման ցանց, օգտվողներ, SSH ստեղներ, արձանագրություններ - telnet/SSH/NETCONF

Կան երեք մոտեցում.

• Ամեն ինչ ամբողջությամբ ձեռքով է։ Սարքը բերվում է տակդիր, որտեղ սովորական օրգանական մարդն այն կմտցնի համակարգերի մեջ, կմիացնի կոնսոլին և կկարգավորի այն։ Կարող է աշխատել փոքր ստատիկ ցանցերի վրա:
• ZTP - Զրոյական հպման ապահովում: Սարքավորումը ժամանեց, կանգնեց, հասցե ստացավ DHCP-ի միջոցով, գնաց հատուկ սերվեր և ինքն իրեն կազմաձևեց:
• Վահանակի սերվերների ենթակառուցվածքը, որտեղ նախնական կոնֆիգուրացիան տեղի է ունենում ավտոմատ ռեժիմում կոնսոլային պորտի միջոցով:

Երեքի մասին էլ կխոսենք առանձին հոդվածում:

Բաղադրիչ 5. Վաճառող-ագնոստիկ կոնֆիգուրացիայի մոդել

Մինչ այժմ, բոլոր համակարգերը եղել են անհամաչափ patches, որոնք ապահովում են փոփոխականներ և դեկլարատիվ նկարագրություն, թե ինչ կցանկանայինք տեսնել ցանցում: Բայց վաղ թե ուշ դուք ստիպված կլինեք զբաղվել կոնկրետությունների հետ:
Այս փուլում, յուրաքանչյուր կոնկրետ սարքի համար պարզունակները, ծառայությունները և փոփոխականները համակցվում են կազմաձևման մոդելի մեջ, որն իրականում նկարագրում է կոնկրետ սարքի ամբողջական կազմաձևումը միայն վաճառողի կողմից չեզոք եղանակով:
Ի՞նչ է անում այս քայլը: Ինչու՞ անմիջապես չստեղծել սարքի կոնֆիգուրացիա, որը կարող եք պարզապես վերբեռնել:
Փաստորեն, սա լուծում է երեք խնդիր.

1. Մի հարմարվեք հատուկ ինտերֆեյսի՝ սարքի հետ շփվելու համար: Լինի դա CLI, NETCONF, RESTCONF, SNMP - մոդելը կլինի նույնը:
2. Մի պահեք կաղապարների/սկրիպտների քանակը՝ ըստ ցանցի վաճառողների թվի, և եթե դիզայնը փոխվի, մի քանի տեղ փոխեք նույն բանը։
3. Բեռնեք կոնֆիգուրացիան սարքից (կրկնօրինակում), դրեք այն ճիշտ նույն մոդելի մեջ և ուղղակիորեն համեմատեք թիրախային կոնֆիգուրացիան գոյություն ունեցողի հետ՝ հաշվարկելու դելտան և պատրաստեք կազմաձևման կարկատ, որը կփոխի միայն այն մասերը, որոնք անհրաժեշտ են կամ հայտնաբերելու շեղումները:

Այս փուլի արդյունքում մենք ստանում ենք վաճառողից անկախ կոնֆիգուրացիա:

Բաղադրիչ 6. Վաճառողի հատուկ վարորդի միջերես

Դուք չպետք է շողոքորթվեք ձեզ հույսերով, որ մի օր հնարավոր կլինի կարգավորել ciska-ն ճիշտ այնպես, ինչպես Juniper-ը, պարզապես նրանց ուղարկելով նույն զանգերը: Չնայած whiteboxes-ի աճող ժողովրդականությանը և NETCONF-ի, RESTCONF-ի, OpenConfig-ի աջակցության առաջացմանը, այս արձանագրությունների մատուցած հատուկ բովանդակությունը տարբերվում է վաճառողից վաճառողից, և սա նրանց մրցակցային տարբերություններից մեկն է, որից նրանք այդքան հեշտությամբ չեն հրաժարվի:
Սա մոտավորապես նույնն է, ինչ OpenContrail-ը և OpenStack-ը, որոնք ունեն RestAPI որպես NorthBound ինտերֆեյս, ակնկալում են բոլորովին այլ զանգեր:

Այսպիսով, հինգերորդ քայլում վաճառողից անկախ մոդելը պետք է ընդունի այն ձևը, որով այն կանցնի ապարատային:
Եվ այստեղ բոլոր միջոցները լավն են (ոչ) CLI, NETCONF, RESTCONF, SNMP պարզապես:

Հետևաբար, մեզ անհրաժեշտ կլինի վարորդ, որը նախորդ քայլի արդյունքը կտեղափոխի կոնկրետ վաճառողի պահանջվող ձևաչափ՝ CLI հրամանների մի շարք, XML կառուցվածք:

Բաղադրիչ 7. Սարքին կոնֆիգուրացիան հասցնելու մեխանիզմ

Մենք ստեղծել ենք կոնֆիգուրացիան, բայց այն դեռ պետք է մատակարարվի սարքերին, և, ակնհայտորեն, ոչ ձեռքով:
Նախ, մեզ մոտ հարց է ծագում, թե ինչ տրանսպորտից ենք օգտվելու։ Եվ այսօր ընտրությունն այլևս փոքր չէ.

• CLI (տելնետ, ssh)
• SNMP
• NETCONF
• RESTCONF
• REST API
• OpenFlow (չնայած դա արտառոց է, քանի որ դա FIB-ի մատուցման միջոց է, ոչ թե կարգավորումներ)

Եկեք կետադրենք t-ն այստեղ: CLI-ն ժառանգություն է: SNMP... հազի հազ.
RESTCONF-ը դեռևս անհայտ կենդանի է, REST API-ն գրեթե ոչ ոք չի աջակցում: Հետևաբար, մենք կկենտրոնանանք NETCONF-ի վրա շարքում:

Իրականում, ինչպես ընթերցողն արդեն հասկացել է, այս պահին մենք արդեն որոշել ենք ինտերֆեյսի մասին. նախորդ քայլի արդյունքն արդեն ներկայացված է ընտրված ինտերֆեյսի ձևաչափով:

Երկրորդ, և ի՞նչ գործիքներով ենք դա անելու։
Այստեղ կա նաև մեծ ընտրություն.

• Ինքնագրված սցենար կամ հարթակ: Եկեք զինվենք ncclient-ով և assyncIO-ով և ամեն ինչ ինքներս անենք: Ի՞նչ արժե մեզ զրոյից տեղակայման համակարգ կառուցելը:
• Ansible-ը ցանցային մոդուլների իր հարուստ գրադարանով:
• Աղը ցանցի հետ իր խղճուկ աշխատանքով և Նապալմի հետ կապով։
• Իրականում Napalm-ը, որը ճանաչում է մի քանի վաճառողների և վերջ, ցտեսություն:
• Նորնիրը ևս մեկ կենդանի է, որը մենք կհերձենք ապագայում:

Այստեղ ֆավորիտը դեռ չի ընտրվել՝ մենք փնտրելու ենք։

Էլ ի՞նչն է կարևոր այստեղ։ Կազմաձևի կիրառման հետևանքները.
Հաջողակ, թե ոչ. Դեռ կա՞ մուտք դեպի սարքավորում, թե՞ ոչ:
Թվում է, որ commit-ը կօգնի այստեղ հաստատել և վավերացնել այն, ինչ ներբեռնվել է սարքում:
Սա, զուգորդվում է NETCONF-ի ճիշտ իրականացման հետ, զգալիորեն նեղացնում է հարմար սարքերի շրջանակը. արտադրողներից ոչ շատերն են աջակցում նորմալ պարտավորություններին: Բայց սա միայն նախապայմաններից մեկն է Առաջարկների հրավեր. Ի վերջո, ոչ ոք չի անհանգստանում, որ ոչ մի ռուս վաճառող չի համապատասխանի 32*100GE ինտերֆեյսի պայմանին: Թե՞ նա մտահոգված է։

Բաղադրիչ 8. CI/CD

Այս պահին մենք արդեն պատրաստ ենք կոնֆիգուրացիան բոլոր ցանցային սարքերի համար:
Ես գրում եմ «ամեն ինչի համար», քանի որ մենք խոսում ենք ցանցի վիճակի տարբերակման մասին: Եվ նույնիսկ եթե ձեզ անհրաժեշտ է փոխել ընդամենը մեկ անջատիչի կարգավորումները, փոփոխությունները հաշվարկվում են ամբողջ ցանցի համար: Ակնհայտ է, որ հանգույցների մեծ մասի համար դրանք կարող են զրո լինել:

Բայց, ինչպես արդեն ասվեց վերևում, մենք բարբարոսներ չենք, ովքեր ցանկանում են ամեն ինչ գլորել ուղիղ արտադրության մեջ:
Ստեղծված կոնֆիգուրացիան նախ պետք է անցնի Pipeline CI/CD-ի միջով:

CI/CD-ն նշանակում է Continuous Integration, Continuous Deployment: Սա մի մոտեցում է, որով թիմը ոչ միայն թողարկում է նոր հիմնական թողարկում յուրաքանչյուր վեց ամիսը մեկ՝ ամբողջությամբ փոխարինելով հինը, այլև պարբերաբար աստիճանաբար իրականացնում է (տեղակայում) նոր ֆունկցիոնալությունը փոքր մասերում, որոնցից յուրաքանչյուրը համակողմանիորեն փորձարկվում է համատեղելիության, անվտանգության և. կատարում (Ինտեգրում):

Դա անելու համար մենք ունենք տարբերակի կառավարման համակարգ, որը վերահսկում է կազմաձևման փոփոխությունները, լաբորատորիա, որը ստուգում է, թե արդյոք հաճախորդների սպասարկումը խաթարված է, մոնիտորինգի համակարգ, որը ստուգում է այս փաստը, և վերջին քայլը փոփոխություններ է կատարում արտադրական ցանցում:

Բացառությամբ վրիպազերծման հրամանների, ցանցում բացարձակապես բոլոր փոփոխությունները պետք է անցնեն CI/CD խողովակաշարով. սա հանգիստ կյանքի և երկար, երջանիկ կարիերայի մեր երաշխիքն է:

Բաղադրիչ 9. Կրկնօրինակման և անոմալիաների հայտնաբերման համակարգ

Դե, կրկնօրինակների մասին նորից խոսելու կարիք չկա։
Մենք դրանք պարզապես կդնենք git-ի մեջ՝ ըստ թագի կամ կոնֆիգուրացիայի փոփոխության փաստի հիման վրա:

Բայց երկրորդ մասը ավելի հետաքրքիր է. ինչ-որ մեկը պետք է հետևի այս կրկնօրինակներին: Եվ որոշ դեպքերում, այս մեկը պետք է գնա և ամեն ինչ շրջի այնպես, ինչպես եղել է, իսկ որոշ դեպքերում, ինչ-որ մեկին մյանա, որ ինչ-որ բան այն չէ:
Օրինակ, եթե նոր օգտվող է հայտնվել, որը գրանցված չէ փոփոխականներում, դուք պետք է հեռացնեք նրան հաքերից: Եվ եթե ավելի լավ է չդիպչել firewall-ի նոր կանոնին, միգուցե ինչ-որ մեկը պարզապես միացրել է վրիպազերծումը, կամ գուցե նոր ծառայությունը, bungler-ը գրանցված չէ կանոնակարգի համաձայն, բայց մարդիկ արդեն միացել են դրան:

Մենք դեռ չենք փախչի ամբողջ ցանցի մասշտաբով որոշ փոքր դելտայից՝ չնայած ավտոմատացման համակարգերին և կառավարման պողպատե ձեռքին: Խնդիրները կարգաբերելու համար ոչ ոք, այնուամենայնիվ, կոնֆիգուրացիա չի ավելացնի համակարգերին: Ավելին, դրանք կարող են նույնիսկ չներառվել կոնֆիգուրացիայի մոդելում:

Օրինակ՝ խնդիրը տեղայնացնելու համար մեկ կոնկրետ IP-ի համար փաթեթների քանակը հաշվելու firewall կանոնը լրիվ սովորական ժամանակավոր կոնֆիգուրացիա է:

Բաղադրիչ 10. Մոնիտորինգի համակարգ

Սկզբում չէի պատրաստվում անդրադառնալ մոնիտորինգի թեմային, դա դեռ ծավալուն, վիճելի և բարդ թեմա է։ Բայց քանի որ իրադարձությունները զարգանում էին, պարզվեց, որ սա ավտոմատացման անբաժանելի մասն է: Եվ դա անհնար է շրջանցել նույնիսկ առանց պրակտիկայի:

Զարգացող միտքը CI/CD գործընթացի օրգանական մասն է: Կազմաձևը ցանցին դուրս բերելուց հետո մենք պետք է կարողանանք որոշել, թե արդյոք այժմ ամեն ինչ կարգին է դրա հետ:
Եվ մենք խոսում ենք ոչ միայն և ոչ այնքան ինտերֆեյսի օգտագործման ժամանակացույցի կամ հանգույցի առկայության, այլ ավելի նուրբ բաների մասին՝ անհրաժեշտ երթուղիների առկայության, դրանց վրա ատրիբուտների, BGP նիստերի քանակի, OSPF հարևանների, End-to-End կատարման մասին: գերակշռող ծառայություններից:
Արդյո՞ք արտաքին սերվերի syslogs-ները դադարել են գումարվել, կամ SFlow գործակալը խափանվել է, կամ հերթերի կաթիլները սկսել են աճել, կամ մի քանի զույգ նախածանցների միջև կապը խափանվել է:

Այս մասին կանդրադառնանք առանձին հոդվածում։

Ամփոփում

Որպես հիմք, ես ընտրեցի տվյալների կենտրոնների ցանցի ժամանակակից ձևավորումներից մեկը՝ L3 Clos Fabric-ը BGP-ով որպես երթուղային արձանագրություն:
Այս անգամ մենք ցանցը կկառուցենք Juniper-ի վրա, քանի որ այժմ JunOs ինտերֆեյսը vanlove է:

Եկեք ավելի բարդացնենք մեր կյանքը՝ օգտագործելով միայն բաց կոդով գործիքներ և բազմաֆունկցիոնալ ցանց, այնպես որ, բացի Juniper-ից, ես ճանապարհին կընտրեմ ևս մեկ հաջողակ մարդու:

Առաջիկա հրապարակումների պլանը մոտավորապես այսպիսին է.
Նախ կխոսեմ վիրտուալ ցանցերի մասին։ Առաջին հերթին, որովհետև ես ուզում եմ, և երկրորդը, որովհետև առանց սրա ենթակառուցվածքային ցանցի նախագծումը այնքան էլ պարզ չի լինի։
Հետո հենց ցանցի նախագծման մասին՝ տոպոլոգիա, երթուղիացում, քաղաքականություն։
Եկեք լաբորատոր ստենդ հավաքենք։
Եկեք մտածենք դրա մասին և միգուցե փորձենք սարքի սկզբնավորումը ցանցում:
Եվ հետո յուրաքանչյուր բաղադրիչի մասին ինտիմ մանրամասնորեն:

Եվ այո, ես չեմ խոստանում նրբագեղորեն ավարտել այս ցիկլը պատրաստի լուծումով։ 🙂

Օգտակար հղումներ

• Նախքան շարքի մեջ խորանալը, արժե կարդալ Նատաշա Սամոյլենկոյի գիրքը Python ցանցային ինժեներների համար. Եվ գուցե անցնի ընթացքը.
• Օգտակար կլինի նաև կարդալ RFC Պյոտր Լապուխովի կողմից Facebook-ից տվյալների կենտրոնների գործարանների նախագծման մասին։
• Ճարտարապետական ​​փաստաթղթերը ձեզ պատկերացում կտան, թե ինչպես է աշխատում Overlay SDN-ը: Վոլֆրամի գործվածք (նախկինում Open Contrail):

Շնորհակալություն

Հռոմեական կիրճ. Մեկնաբանությունների և խմբագրումների համար։
Արտյոմ Չեռնոբայ. KDPV-ի համար.

Source: www.habr.com