Ինչպես վերահսկել ձեր ցանցային ենթակառուցվածքը: Գլուխ երկու. Մաքրում և փաստաթղթավորում

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

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

Այժմ մենք չենք խոսի անվտանգության աուդիտների մասին, սա կլինի երրորդ մասի թեման:

Այս փուլում հանձնարարված առաջադրանքը կատարելու դժվարությունը, իհարկե, մեծապես տարբերվում է ընկերությունից ընկերություն:

Իդեալական իրավիճակն այն է, երբ

• ձեր ցանցը ստեղծվել է նախագծին համապատասխան, և դուք ունեք փաստաթղթերի ամբողջական փաթեթ
• ներդրվել է ձեր ընկերությունում վերահսկման և կառավարման գործընթացի փոփոխություն ցանցի համար
• այս գործընթացին համապատասխան, դուք ունեք փաստաթղթեր (ներառյալ բոլոր անհրաժեշտ դիագրամները), որոնք ամբողջական տեղեկատվություն են տրամադրում գործերի ներկա վիճակի մասին

Այս դեպքում ձեր խնդիրը բավականին պարզ է. Դուք պետք է ուսումնասիրեք փաստաթղթերը և վերանայեք բոլոր փոփոխությունները, որոնք կատարվել են:

Վատագույն դեպքում, դուք կունենաք

• ցանց, որը ստեղծվել է առանց նախագծի, առանց պլանի, առանց հաստատման, ինժեներների կողմից, որոնք չունեն բավարար որակավորում,
• քաոսային, չփաստագրված փոփոխություններով, շատ «աղբով» ու ոչ օպտիմալ լուծումներով.

Հասկանալի է, որ ձեր վիճակը ինչ-որ տեղ մեջտեղում է, բայց, ցավոք, այս սանդղակով ավելի լավ-վատ, մեծ է հավանականությունը, որ դուք ավելի մոտ կլինեք ամենավատ ավարտին:

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

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

Փաստաթղթերի հավաքածու

Սկսենք օրինակով.

Ստորև ներկայացված են մի քանի փաստաթղթեր, որոնք սովորաբար ստեղծվում են Cisco Systems-ում նախագծման ընթացքում:

CR – Հաճախորդների պահանջներ, հաճախորդի պահանջներ (տեխնիկական բնութագրեր):
Այն ստեղծվում է հաճախորդի հետ համատեղ և որոշում է ցանցի պահանջները:

HLD- ը – Բարձր մակարդակի դիզայն, բարձր մակարդակի դիզայն՝ հիմնված ցանցի պահանջների վրա (CR): Փաստաթուղթը բացատրում և հիմնավորում է ընդունված ճարտարապետական ​​որոշումները (տոպոլոգիա, արձանագրություններ, սարքավորումների ընտրություն,...): HLD-ը չի պարունակում դիզայնի մանրամասներ, ինչպիսիք են օգտագործված միջերեսները և IP հասցեները: Բացի այդ, կոնկրետ ապարատային կոնֆիգուրացիան այստեղ չի քննարկվում: Ավելի շուտ, այս փաստաթուղթը նախատեսված է հաճախորդի տեխնիկական ղեկավարությանը բացատրելու հիմնական դիզայնի հայեցակարգերը:

Լլդ – Ցածր մակարդակի դիզայն, ցածր մակարդակի դիզայն՝ հիմնված բարձր մակարդակի դիզայնի վրա (HLD):
Այն պետք է պարունակի բոլոր մանրամասները, որոնք անհրաժեշտ են նախագիծն իրականացնելու համար, ինչպես, օրինակ, տեղեկատվություն սարքավորումը միացնելու և կարգավորելու մասին: Սա դիզայնի իրականացման ամբողջական ուղեցույց է: Այս փաստաթուղթը պետք է բավարար տեղեկատվություն տրամադրի դրա իրականացման համար նույնիսկ ավելի քիչ որակավորում ունեցող անձնակազմի կողմից:

Ինչ-որ բան, օրինակ՝ IP հասցեները, ՀԾ-ի համարները, ֆիզիկական անջատման սխեման (մալուխային կապ), կարող են «դուրս գալ» առանձին փաստաթղթերում, օրինակ. PIN- ը (Ցանցի իրականացման պլան):

Ցանցի կառուցումը սկսվում է այս փաստաթղթերի ստեղծումից հետո և տեղի է ունենում դրանց խստորեն համապատասխան, այնուհետև հաճախորդի կողմից ստուգվում է (թեստավորումներ)՝ նախագծման հետ համապատասխանության համար:

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

Եվ իմ կարծիքով, կա որոշակի բացարձակ նվազագույն, առանց որի հնարավոր չէ արդյունավետ վերահսկել ցանցը։

Սրանք հետևյալ փաստաթղթերն են.

• Ֆիզիկական միացման (մալուխային) դիագրամ (տեղեկամատյան)
• ցանցային դիագրամ կամ դիագրամներ հիմնական L2/L3 տեղեկություններով

Ֆիզիկական անջատման դիագրամ

Որոշ փոքր ընկերություններում սարքավորումների տեղադրման և ֆիզիկական միացման (մալուխների) հետ կապված աշխատանքը ցանցի ինժեներների պարտականությունն է:

Այս դեպքում խնդիրը մասամբ լուծվում է հետեւյալ մոտեցմամբ.

• օգտագործեք նկարագրությունը ինտերֆեյսի վրա՝ նկարագրելու համար, թե ինչն է կապված դրան
• ադմինիստրատիվ անջատում ցանցի բոլոր չմիացված սարքավորումների նավահանգիստները

Սա ձեզ հնարավորություն կտա, նույնիսկ հղման հետ կապված խնդրի դեպքում (երբ cdp-ն կամ lldp-ն չի աշխատում այս ինտերֆեյսի վրա), արագ որոշել, թե ինչն է միացված այս պորտին:
Կարող եք նաև հեշտությամբ տեսնել, թե որ նավահանգիստներն են զբաղված և որոնք են անվճար, ինչը անհրաժեշտ է ցանցային նոր սարքավորումների, սերվերների կամ աշխատանքային կայանների միացումների պլանավորման համար:

Բայց պարզ է, որ եթե դուք կորցնեք հասանելիությունը սարքավորումներին, դուք նույնպես կկորցնեք հասանելիությունը այս տեղեկատվությանը: Բացի այդ, այս կերպ դուք չեք կարողանա գրանցել այնպիսի կարևոր տեղեկատվություն, ինչպիսին է սարքավորումը, ինչ էներգիայի սպառում, քանի պորտ, ինչ դարակում է այն, ինչ patch-պանելներ կան և որտեղ (ինչ դարակում/patch panel-ում ) դրանք կապված են: Հետևաբար, լրացուցիչ փաստաթղթերը (ոչ միայն սարքավորումների նկարագրությունները) դեռ շատ օգտակար են:

Իդեալական տարբերակն այս տեսակի տեղեկատվության հետ աշխատելու համար նախատեսված հավելվածների օգտագործումն է: Բայց դուք կարող եք սահմանափակվել պարզ աղյուսակներով (օրինակ, Excel-ում) կամ ցուցադրել այն տեղեկությունները, որոնք անհրաժեշտ եք համարում L1/L2 դիագրամներում:

Կարեւոր!

Ցանցային ինժեները, իհարկե, կարող է բավականին լավ իմանալ SCS-ի բարդություններն ու չափանիշները, դարակների տեսակները, անխափան սնուցման սարքերի տեսակները, ինչ է սառը և տաք միջանցքը, ինչպես ճիշտ հիմնավորում անել... ճիշտ այնպես, ինչպես սկզբունքորեն կարող է: իմանալ տարրական մասնիկների ֆիզիկան կամ C++. Բայց դեռ պետք է հասկանալ, որ այս ամենը նրա գիտելիքների ոլորտը չէ։

Հետևաբար, լավ պրակտիկա է ունենալ հատուկ ստորաբաժանումներ կամ նվիրված մարդիկ՝ սարքավորումների տեղադրման, միացման, սպասարկման, ինչպես նաև ֆիզիկական միացման հետ կապված խնդիրները լուծելու համար: Սովորաբար տվյալների կենտրոնների համար սա տվյալների կենտրոնի ինժեներներն են, իսկ գրասենյակի համար՝ օգնական:

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

Ցանցային դիագրամներ

Դիագրամներ գծելու ունիվերսալ մոտեցում չկա:

Ամենակարևորն այն է, որ դիագրամները պետք է հասկանան, թե ինչպես է երթևեկությունը հոսելու, որի միջոցով է ձեր ցանցի տրամաբանական և ֆիզիկական տարրերը:

Ֆիզիկական տարրեր ասելով նկատի ունենք

• ակտիվ սարքավորումներ
• ակտիվ սարքավորումների ինտերֆեյսներ/պորտեր

Տրամաբանական -

• տրամաբանական սարքեր (N7K VDC, Palo Alto VSYS, ...)
• VRF
• Վիլաններ
• ենթաինտերֆեյսներ
• թունելներ
• գոտիներ
• ...

Բացի այդ, եթե ձեր ցանցը ամբողջովին տարրական չէ, այն բաղկացած կլինի տարբեր հատվածներից։
Օրինակ

• տվյալների կենտրոն
• Ինտերնետ
• WAN
• հեռավոր մուտք
• գրասենյակային LAN
• DMZ
• ...

Խելամիտ է ունենալ մի քանի դիագրամներ, որոնք տալիս են և՛ մեծ պատկերը (ինչպես է երթևեկությունը հոսում այս բոլոր հատվածների միջև), և՛ յուրաքանչյուր առանձին հատվածի մանրամասն բացատրություն:

Քանի որ ժամանակակից ցանցերում կարող են լինել բազմաթիվ տրամաբանական շերտեր, միգուցե լավ (բայց ոչ անհրաժեշտ) մոտեցում է տարբեր շերտերի համար տարբեր սխեմաներ պատրաստելը, օրինակ, ծածկույթի մոտեցման դեպքում սա կարող է լինել հետևյալ սխեմաները.

• կափարիչը
• L1/L2 տակդիր
• L3 ներքև

Իհարկե, ամենակարևոր դիագրամը, առանց որի անհնար է հասկանալ ձեր դիզայնի գաղափարը, երթուղային դիագրամն է:

Երթուղիների սխեման

Առնվազն այս դիագրամը պետք է արտացոլի

• ինչ երթուղային արձանագրություններ են օգտագործվում և որտեղ
• հիմնական տեղեկատվություն երթուղային արձանագրության կարգավորումների մասին (տարածք/AS համար/երթուղիչ-id/…)
• ո՞ր սարքերի վրա է կատարվում վերաբաշխումը:
• որտեղ տեղի է ունենում ֆիլտրում և երթուղու համախմբում
• կանխադրված երթուղու տեղեկատվություն

Բացի այդ, L2 սխեման (OSI) հաճախ օգտակար է:

L2 սխեման (OSI)

Այս դիագրամը կարող է ցույց տալ հետևյալ տեղեկատվությունը.

• ինչ VLAN-ներ
• որ նավահանգիստներն են միջքաղաքային նավահանգիստները
• որ նավահանգիստները միավորվում են եթերային ալիքի (պորտի ալիք), վիրտուալ պորտի ալիքի մեջ
• ինչ STP արձանագրություններ են օգտագործվում և ինչ սարքերում
• STP-ի հիմնական կարգավորումները՝ արմատ/արմատ կրկնօրինակում, STP արժեք, պորտի առաջնահերթություն
• լրացուցիչ STP կարգավորումներ՝ BPDU պահակ/զտիչ, արմատային պահակ…

Տիպիկ դիզայնի սխալներ

Ցանց կառուցելու վատ մոտեցման օրինակ.

Բերենք պարզ գրասենյակային LAN կառուցելու պարզ օրինակ:

Ունենալով ուսանողներին հեռահաղորդակցության դասավանդման փորձ, կարող եմ ասել, որ գործնականում ցանկացած ուսանող մինչև երկրորդ կիսամյակի կեսը ունի անհրաժեշտ գիտելիքներ (որպես դասընթացի մաս, որը ես դասավանդեցի) պարզ գրասենյակային LAN ստեղծելու համար:

Ի՞նչ դժվար է անջատիչները միմյանց միացնելը, VLAN-ները, SVI ինտերֆեյսները (L3 անջատիչների դեպքում) կարգավորելը և ստատիկ երթուղին սահմանելը:

Ամեն ինչ կաշխատի։

Բայց միևնույն ժամանակ հարցեր՝ կապված

• անվտանգություն
• ամրագրում
• ցանցի մասշտաբավորում
• արտադրողականություն
• թողունակությունը
• հուսալիություն
• ...

Ժամանակ առ ժամանակ ես լսում եմ հայտարարություն, որ գրասենյակային LAN-ը շատ պարզ բան է, և ես սովորաբար դա լսում եմ ինժեներներից (և մենեջերներից), ովքեր անում են ամեն ինչ, բացի ցանցերից, և նրանք դա ասում են այնքան վստահ, որ մի զարմացեք, եթե LAN-ը լինի: արված է անբավարար պրակտիկայով և գիտելիքներով մարդկանց կողմից և արվելու է մոտավորապես նույն սխալներով, որոնք ես կնկարագրեմ ստորև։

Ընդհանուր L1 (OSI) դիզայնի սխալներ

• Եթե, այնուամենայնիվ, դուք նույնպես պատասխանատու եք SCS-ի համար, ապա ամենատհաճ ժառանգություններից մեկը, որը դուք կարող եք ստանալ, անզգույշ և չմտածված փոխարկումն է:

Ես նաև կդասակարգեի որպես L1 տեսակի սխալներ՝ կապված օգտագործվող սարքավորումների ռեսուրսների հետ, օրինակ.

• անբավարար թողունակություն
• անբավարար TCAM սարքավորումների վրա (կամ դրա անարդյունավետ օգտագործումը)
• անբավարար կատարում (հաճախ կապված է firewalls-ի հետ)

Ընդհանուր L2 (OSI) դիզայնի սխալներ

Հաճախ, երբ չկա լավ պատկերացում, թե ինչպես է աշխատում STP-ն և ինչ պոտենցիալ խնդիրներ է այն բերում, անջատիչները միացվում են քաոսային կերպով, լռելյայն կարգավորումներով, առանց լրացուցիչ STP թյունինգի:

Արդյունքում հաճախ ունենում ենք հետեւյալը

• STP ցանցի մեծ տրամագիծը, որը կարող է հանգեցնել հեռարձակման փոթորիկների
• STP արմատը կորոշվի պատահականորեն (հիմնված mac հասցեի վրա) և երթևեկության ուղին կլինի ոչ օպտիմալ
• Հոսթներին միացված նավահանգիստները չեն կազմաձևվի որպես եզրային (portfast), ինչը կհանգեցնի STP-ի վերահաշվարկի վերջնական կայանները միացնելիս/անջատելիս:
• ցանցը չի բաժանվի L1/L2 մակարդակում, ինչի արդյունքում որևէ անջատիչի հետ կապված խնդիրները (օրինակ՝ հոսանքի ծանրաբեռնվածությունը) կհանգեցնեն STP տոպոլոգիայի վերահաշվարկի և երթևեկության դադարեցմանը բոլոր VLAN-ներում բոլոր անջատիչների վրա (ներառյալ՝ մեկը կարևոր է սպասարկման շարունակական հատվածի տեսանկյունից)

L3 (OSI) դիզայնի սխալների օրինակներ

Սկսնակ ցանցերի մի քանի բնորոշ սխալներ.

• Ստատիկ երթուղիների հաճախակի օգտագործում (կամ օգտագործում միայն):
• տվյալ դիզայնի համար ոչ օպտիմալ երթուղային արձանագրությունների օգտագործումը
• ենթաօպտիմալ տրամաբանական ցանցի հատվածավորում
• հասցեների տարածության ոչ օպտիմալ օգտագործումը, որը թույլ չի տալիս երթուղիների համախմբում
• ոչ մի պահուստային երթուղի
• լռելյայն դարպասի վերապահում չկա
• ասիմետրիկ երթուղում երթուղիները վերակառուցելիս (կարող է կարևոր լինել NAT/PAT-ի, պետական ​​հրդեհային պատերի դեպքում)
• խնդիրներ MTU-ի հետ
• երբ երթուղիները վերակառուցվում են, երթևեկությունն անցնում է անվտանգության այլ գոտիներով կամ նույնիսկ այլ firewalls, ինչը հանգեցնում է այս երթևեկության դադարեցմանը:
• վատ տոպոլոգիայի մասշտաբայնություն

Դիզայնի որակի գնահատման չափանիշներ

Երբ խոսում ենք օպտիմալության/ոչ օպտիմալության մասին, պետք է հասկանանք, թե ինչ չափանիշներով կարող ենք սա գնահատել։ Ահա, իմ տեսանկյունից, ամենակարևոր (բայց ոչ բոլոր) չափանիշները (և բացատրությունը երթուղային արձանագրությունների հետ կապված).

• մասշտաբայնություն
  Օրինակ, դուք որոշում եք ավելացնել մեկ այլ տվյալների կենտրոն: Որքան հեշտ կարող եք դա անել:
• օգտագործման հեշտություն (կառավարելիություն)
  Որքանո՞վ են հեշտ և ապահով գործառնական փոփոխությունները, ինչպիսիք են նոր ցանցի հայտարարումը կամ երթուղիների զտումը:
• հասանելիություն
  Ժամանակի քանի՞ տոկոսն է ձեր համակարգը ապահովում սպասարկման պահանջվող մակարդակը:
• անվտանգություն
  Որքանո՞վ են ապահով փոխանցված տվյալները:
• գին

Փոփոխություններ

Հիմնական սկզբունքն այս փուլում կարող է արտահայտվել «մի վնասիր» բանաձևով։
Հետևաբար, նույնիսկ եթե դուք լիովին համաձայն չեք դիզայնի և ընտրված իրականացման (կազմաձևման) հետ, միշտ չէ, որ նպատակահարմար է փոփոխություններ կատարել: Խելամիտ մոտեցում է հայտնաբերված բոլոր խնդիրները դասակարգել ըստ երկու պարամետրերի.

• որքան հեշտությամբ կարելի է լուծել այս խնդիրը
• որքան ռիսկ է նա կրում:

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

Պերֆեկցիոնիզմն այս փուլում կարող է վնասակար լինել։ Դիզայնը բերեք բավարար վիճակի և համապատասխանաբար համաժամացրեք ցանցի կոնֆիգուրացիան:

Source: www.habr.com