Si të merrni kontrollin e infrastrukturës së rrjetit tuaj. Kapitulli i dytë. Pastrimi dhe Dokumentacioni

Ky artikull është i dyti në një seri artikujsh "Si të merrni kontrollin e infrastrukturës së rrjetit tuaj". Përmbajtja e të gjithë artikujve në seri dhe lidhjet mund të gjenden këtu.

Qëllimi ynë në këtë fazë është të vëmë rregull në dokumentacion dhe konfigurim.
Në fund të këtij procesi, duhet të keni grupin e nevojshëm të dokumenteve dhe një rrjet të konfiguruar në përputhje me to.

Tani nuk do të flasim për auditimet e sigurisë - kjo do të jetë tema e pjesës së tretë.

Vështirësia për të kryer detyrën e caktuar në këtë fazë, natyrisht, ndryshon shumë nga kompania në kompani.

Situata ideale është kur

• rrjeti juaj është krijuar në përputhje me projektin dhe ju keni një grup të plotë dokumentesh
• është zbatuar në kompaninë tuaj ndryshimi i procesit të kontrollit dhe menaxhimit për rrjet
• në përputhje me këtë proces, ju keni dokumente (duke përfshirë të gjitha diagramet e nevojshme) që ofrojnë informacion të plotë për gjendjen aktuale të punëve

Në këtë rast, detyra juaj është mjaft e thjeshtë. Ju duhet të studioni dokumentet dhe të rishikoni të gjitha ndryshimet që janë bërë.

Në rastin më të keq, do ta keni

• një rrjet i krijuar pa projekt, pa plan, pa miratim, nga inxhinierë që nuk kanë një nivel të mjaftueshëm kualifikimi,
• me ndryshime kaotike, të padokumentuara, me shumë “plehra” dhe zgjidhje jo optimale

Është e qartë se situata juaj është diku në mes, por për fat të keq, në këtë shkallë më të mirë - më keq, ka një probabilitet të lartë që të jeni më afër fundit më të keq.

Në këtë rast, do t'ju duhet gjithashtu aftësia për të lexuar mendjet, sepse do të duhet të mësoni të kuptoni se çfarë donin të bënin "projektuesit", të rivendosni logjikën e tyre, të përfundoni atë që nuk ishte e përfunduar dhe të hiqni "plehra".
Dhe, sigurisht, do t'ju duhet të korrigjoni gabimet e tyre, të ndryshoni (në këtë fazë sa më minimale të jetë e mundur) dizajnin dhe të ndryshoni ose rikrijoni skemat.

Ky artikull në asnjë mënyrë nuk pretendon të jetë i plotë. Këtu do të përshkruaj vetëm parimet e përgjithshme dhe do të fokusohem në disa probleme të zakonshme që duhet të zgjidhen.

Set dokumentesh

Le të fillojmë me një shembull.

Më poshtë janë disa dokumente që krijohen zakonisht në Cisco Systems gjatë projektimit.

CR – Kërkesat e klientit, kërkesat e klientit (specifikimet teknike).
Ai krijohet së bashku me klientin dhe përcakton kërkesat e rrjetit.

HLD – Dizajn i nivelit të lartë, dizajn i nivelit të lartë bazuar në kërkesat e rrjetit (CR). Dokumenti shpjegon dhe justifikon vendimet arkitekturore të marra (topologjia, protokollet, përzgjedhja e harduerit,...). HLD nuk përmban detaje të dizajnit, të tilla si ndërfaqet dhe adresat IP të përdorura. Gjithashtu, konfigurimi specifik i harduerit nuk diskutohet këtu. Përkundrazi, ky dokument synon të shpjegojë konceptet kryesore të projektimit për menaxhimin teknik të klientit.

LLD – Dizajn i nivelit të ulët, dizajn i nivelit të ulët i bazuar në dizajn të nivelit të lartë (HLD).
Ai duhet të përmbajë të gjitha detajet e nevojshme për zbatimin e projektit, të tilla si informacioni se si të lidhni dhe konfiguroni pajisjet. Ky është një udhëzues i plotë për zbatimin e dizajnit. Ky dokument duhet të sigurojë informacion të mjaftueshëm për zbatimin e tij edhe nga personeli më pak i kualifikuar.

Diçka, për shembull, adresat IP, numrat AS, skema e ndërrimit fizik (kabllo), mund të "hiqen" në dokumente të veçanta, si p.sh. NIP (Plani i Zbatimit të Rrjetit).

Ndërtimi i rrjetit fillon pas krijimit të këtyre dokumenteve dhe ndodh në përputhje të rreptë me to dhe më pas kontrollohet nga klienti (testet) për përputhjen me projektin.

Natyrisht, integrues të ndryshëm, klientë të ndryshëm dhe vende të ndryshme mund të kenë kërkesa të ndryshme për dokumentacionin e projektit. Por unë do të doja të shmangja formalitetet dhe ta konsideroja çështjen në bazë të saj. Kjo fazë nuk ka të bëjë me projektimin, por me vendosjen e gjërave në rregull, dhe ne kemi nevojë për një grup të mjaftueshëm dokumentesh (diagrame, tabela, përshkrime...) për të përfunduar detyrat tona.

Dhe për mendimin tim, ekziston një minimum i caktuar absolut, pa të cilin është e pamundur të kontrollohet në mënyrë efektive rrjeti.

Këto janë dokumentet e mëposhtme:

• diagrami (log) i ndërrimit fizik (kabllo)
• diagrami i rrjetit ose diagramet me informacion thelbësor L2/L3

Diagrami i ndërrimit fizik

Në disa kompani të vogla, puna në lidhje me instalimin e pajisjeve dhe kalimin fizik (kabllo) është përgjegjësi e inxhinierëve të rrjetit.

Në këtë rast, problemi zgjidhet pjesërisht nga qasja e mëposhtme.

• përdorni një përshkrim në ndërfaqe për të përshkruar atë që është e lidhur me të
• mbyllja administrative e të gjitha porteve të palidhura të pajisjeve të rrjetit

Kjo do t'ju japë mundësinë, edhe në rast të një problemi me lidhjen (kur cdp ose lldp nuk funksionon në këtë ndërfaqe), të përcaktoni shpejt se çfarë është e lidhur me këtë port.
Ju gjithashtu mund të shihni lehtësisht se cilat porte janë të zëna dhe cilat janë të lira, gjë që është e nevojshme për planifikimin e lidhjeve të pajisjeve të reja të rrjetit, serverëve ose stacioneve të punës.

Por është e qartë se nëse humbni aksesin në pajisje, do të humbni edhe aksesin në këtë informacion. Për më tepër, në këtë mënyrë nuk do të jeni në gjendje të regjistroni informacione kaq të rëndësishme si çfarë lloj pajisjeje, çfarë konsumi energjie, sa porta, në çfarë rafti është, çfarë panelesh patch janë atje dhe ku (në çfarë rafti/paneli patch ) janë të lidhura . Prandaj, dokumentacioni shtesë (jo vetëm përshkrimet në pajisje) është ende shumë i dobishëm.

Opsioni ideal është përdorimi i aplikacioneve të krijuara për të punuar me këtë lloj informacioni. Por mund të kufizoheni në tabela të thjeshta (për shembull, në Excel) ose të shfaqni informacionin që ju e konsideroni të nevojshëm në diagramet L1/L2.

Rëndësishme!

Një inxhinier rrjeti, natyrisht, mund të dijë mjaft mirë ndërlikimet dhe standardet e SCS, llojet e rafteve, llojet e furnizimit me energji të pandërprerë, çfarë është korridori i ftohtë dhe i nxehtë, si të bëhet tokëzimi i duhur... ashtu si, në parim, ai mund të njohë fizikën e grimcave elementare ose C++. Por ende duhet kuptuar se e gjithë kjo nuk është fusha e tij e njohurive.

Prandaj, është praktikë e mirë që të ketë ose departamente të dedikuara ose njerëz të përkushtuar për të zgjidhur problemet që lidhen me instalimin, lidhjen, mirëmbajtjen e pajisjeve, si dhe ndërrimin fizik. Zakonisht për qendrat e të dhënave kjo është inxhinierë e qendrave të të dhënave, dhe për një zyrë është ndihmës.

Nëse ndarje të tilla ofrohen në kompaninë tuaj, atëherë problemet e ndërrimit fizik të regjistrimit nuk janë detyra juaj dhe mund të kufizoheni vetëm në përshkrimin në ndërfaqen dhe mbylljen administrative të porteve të papërdorura.

Diagramet e rrjetit

Nuk ka qasje universale për vizatimin e diagrameve.

Gjëja më e rëndësishme është që diagramet duhet të ofrojnë një kuptim se si do të rrjedhë trafiku, përmes cilit elementë logjikë dhe fizikë të rrjetit tuaj.

Me elemente fizike kuptojmë

• pajisje aktive
• ndërfaqet/portet e pajisjeve aktive

Në mënyrë logjike -

• pajisje logjike (N7K VDC, Palo Alto VSYS, ...)
• Zgjerimi VRF
• Vilanet
• nënndërfaqet
• tunele
• zonat
• ...

Gjithashtu, nëse rrjeti juaj nuk është plotësisht elementar, ai do të përbëhet nga segmente të ndryshme.
Për shembull

• Qendra e të dhënave
• Internet
• WAN
• akses në distancë
• LAN zyre
• DMZ
• ...

Është e mençur të kemi disa diagrame që japin një pamje të madhe (si rrjedh trafiku midis të gjithë këtyre segmenteve) dhe një shpjegim të detajuar të secilit segment individual.

Meqenëse në rrjetet moderne mund të ketë shumë shtresa logjike, është ndoshta një qasje e mirë (por jo e nevojshme) për të krijuar qarqe të ndryshme për shtresa të ndryshme, për shembull, në rastin e një qasjeje mbivendosjeje, kjo mund të jetë qarqet e mëposhtme:

• mbulesë
• Nënshtresa L1/L2
• Nënshtresa L3

Sigurisht, diagrami më i rëndësishëm, pa të cilin është e pamundur të kuptohet ideja e dizajnit tuaj, është diagrami i rrugëzimit.

Skema e rrugëzimit

Së paku, ky diagram duhet të pasqyrojë

• çfarë protokolle rutimi përdoren dhe ku
• informacion bazë rreth cilësimeve të protokollit të rrugëtimit (zona/numri AS/identifikues i ruterit/…)
• në cilat pajisje ndodh rishpërndarja?
• ku ndodh filtrimi dhe grumbullimi i rrugës
• informacioni i parazgjedhur i rrugës

Gjithashtu, skema L2 (OSI) është shpesh e dobishme.

Skema L2 (OSI)

Ky diagram mund të tregojë informacionin e mëposhtëm:

• çfarë VLAN
• cilat porte janë porta trunk
• cilat porte grumbullohen në kanal eter (kanali port), kanal port virtual
• çfarë protokolle STP përdoren dhe në cilat pajisje
• cilësimet bazë të STP: kopje rezervë e rrënjës/rrënjës, kostoja e STP, përparësia e portit
• cilësimet shtesë të STP: Mbrojtës/filtri BPDU, mbrojtësi rrënjë…

Gabimet tipike të projektimit

Një shembull i një qasjeje të keqe për ndërtimin e një rrjeti.

Le të marrim një shembull të thjeshtë të ndërtimit të një LAN të thjeshtë zyre.

Duke pasur përvojë në mësimdhënien e telekomit për studentët, mund të them se praktikisht çdo student nga mesi i semestrit të dytë ka njohuritë e nevojshme (si pjesë e lëndës që kam dhënë) për të ngritur një LAN të thjeshtë zyre.

Çfarë është kaq e vështirë për lidhjen e ndërprerësve me njëri-tjetrin, vendosjen e VLAN-ve, ndërfaqet SVI (në rastin e ndërprerësve L3) dhe vendosjen e rrugëzimit statik?

Gjithçka do të funksionojë.

Por në të njëjtën kohë, pyetjet që lidhen me

• sigurinë
• rezervim
• shkallëzimi i rrjetit
• produktivitetit
• xhiros
• besueshmëria
• ...

Herë pas here dëgjoj deklaratën se një LAN zyre është diçka shumë e thjeshtë dhe zakonisht e dëgjoj këtë nga inxhinierët (dhe menaxherët) që bëjnë gjithçka përveç rrjeteve, dhe ata e thonë këtë me aq besim sa mos u habitni nëse LAN-i do të jetë të bëra nga njerëz me praktikë dhe njohuri të pamjaftueshme dhe do të bëhen afërsisht me të njëjtat gabime që do të përshkruaj më poshtë.

Gabimet e zakonshme të projektimit L1 (OSI).

• Nëse, megjithatë, jeni përgjegjës edhe për SCS, atëherë një nga trashëgimitë më të pakëndshme që mund të merrni është ndërrimi i pakujdesshëm dhe i menduar keq.

Unë gjithashtu do të klasifikoja si gabime të tipit L1 që lidhen me burimet e pajisjeve të përdorura, për shembull,

• gjerësi bande e pamjaftueshme
• TCAM e pamjaftueshme në pajisje (ose përdorimi joefektiv i tij)
• performanca e pamjaftueshme (shpesh e lidhur me muret e zjarrit)

Gabimet e zakonshme të projektimit L2 (OSI).

Shpesh, kur nuk ka kuptim të mirë se si funksionon STP dhe çfarë problemesh të mundshme sjell me të, çelsat lidhen në mënyrë kaotike, me cilësime të paracaktuara, pa akordim shtesë STP.

Si rezultat, ne shpesh kemi si më poshtë

• diametër i madh i rrjetit STP, i cili mund të çojë në stuhi transmetimi
• Rrënja STP do të përcaktohet në mënyrë të rastësishme (bazuar në adresën mac) dhe shtegu i trafikut do të jetë jooptimal
• portet e lidhura me hostet nuk do të konfigurohen si skaj (portfast), gjë që do të çojë në rillogaritjen e STP kur aktivizoni/fikni stacionet fundore
• rrjeti nuk do të segmentohet në nivelin L1/L2, si rezultat i të cilit problemet me ndonjë ndërprerës (për shembull, mbingarkesa e energjisë) do të çojnë në një rillogaritje të topologjisë STP dhe ndalimin e trafikut në të gjitha VLAN-të në të gjithë çelësat (përfshirë një kritik nga pikëpamja e segmentit të shërbimit të vazhdimësisë)

Shembuj të gabimeve në projektimin L3 (OSI).

Disa gabime tipike të rrjeteve fillestare:

• Përdorimi i shpeshtë (ose përdorimi vetëm) i rrugëzimit statik
• përdorimi i protokolleve nënoptimale të rrugëtimit për një dizajn të caktuar
• segmentimi logjik i rrjetit nënoptimal
• përdorimi jo optimal i hapësirës së adresave, i cili nuk lejon grumbullimin e rrugës
• nuk ka rrugë rezervë
• asnjë rezervë për portën e paracaktuar
• drejtimi asimetrik kur rindërtoni rrugët (mund të jetë kritik në rastin e NAT/PAT, muret e zjarrit me status të plotë)
• probleme me MTU
• kur rrugët rindërtohen, trafiku kalon nëpër zona të tjera sigurie apo edhe mure të tjera zjarri, gjë që çon në rënien e këtij trafiku
• shkallëzim i dobët i topologjisë

Kriteret për vlerësimin e cilësisë së projektimit

Kur flasim për optimalitet/mosoptimalitet, duhet të kuptojmë nga pikëpamja se çfarë kriteresh mund ta vlerësojmë këtë. Këtu, nga këndvështrimi im, janë kriteret më domethënëse (por jo të gjitha) (dhe shpjegimi në lidhje me protokollet e rrugëzimit):

• shkallëzueshmëria
  Për shembull, ju vendosni të shtoni një qendër tjetër të dhënash. Sa lehtë mund ta bësh?
• lehtësia e përdorimit (menaxhueshmëria)
  Sa të lehta dhe të sigurta janë ndryshimet operacionale, të tilla si shpallja e një rrjeti të ri apo filtrimi i rrugëve?
• disponueshmëria
  Sa përqind e kohës ofron sistemi juaj nivelin e kërkuar të shërbimit?
• sigurinë
  Sa të sigurta janë të dhënat e transmetuara?
• çmim

ndryshimet

Parimi bazë në këtë fazë mund të shprehet me formulën "mos bëni dëm".
Prandaj, edhe nëse nuk jeni plotësisht dakord me dizajnin dhe zbatimin (konfigurimin) e zgjedhur, nuk këshillohet gjithmonë të bëni ndryshime. Një qasje e arsyeshme është të renditen të gjitha problemet e identifikuara sipas dy parametrave:

• sa lehtë mund të zgjidhet ky problem
• sa rrezik mbart ajo?

Para së gjithash, është e nevojshme të eliminohet ajo që aktualisht ul nivelin e shërbimit të ofruar nën nivelin e pranueshëm, për shembull, problemet që çojnë në humbjen e paketave. Më pas rregulloni atë që është më e lehtë dhe më e sigurta për t'u rregulluar në rend në rënie të ashpërsisë së rrezikut (nga problemet e projektimit ose konfigurimit me rrezik të lartë deri te ato me rrezik të ulët).

Perfeksionizmi në këtë fazë mund të jetë i dëmshëm. Sillni dizajnin në një gjendje të kënaqshme dhe sinkronizoni konfigurimin e rrjetit në përputhje me rrethanat.

Burimi: www.habr.com