Kako prevzeti nadzor nad svojo omrežno infrastrukturo. Drugo poglavje. Čiščenje in dokumentacija

Ta članek je drugi v nizu člankov »Kako prevzeti nadzor nad svojo omrežno infrastrukturo«. Vsebino vseh člankov v seriji in povezave najdete tukaj.

Kako prevzeti nadzor nad svojo omrežno infrastrukturo. Drugo poglavje. Čiščenje in dokumentacija

Naš cilj na tej stopnji je narediti red v dokumentaciji in konfiguraciji.
Na koncu tega postopka bi morali imeti potreben nabor dokumentov in v skladu z njimi konfigurirano omrežje.

Zdaj ne bomo govorili o varnostnih revizijah - to bo tema tretjega dela.

Težavnost dokončanja naloge, dodeljene v tej fazi, se seveda zelo razlikuje od podjetja do podjetja.

Idealna situacija je, ko

  • vaše omrežje je bilo ustvarjeno v skladu s projektom in imate celoten nabor dokumentov
  • implementiran v vašem podjetju proces nadzora in upravljanja sprememb za omrežje
  • V skladu s tem postopkom imate dokumente (vključno z vsemi potrebnimi diagrami), ki zagotavljajo popolne informacije o trenutnem stanju

V tem primeru je vaša naloga precej preprosta. Preučiti morate dokumente in pregledati vse spremembe, ki so bile narejene.

V najslabšem primeru boste imeli

  • omrežje, ki je narejeno brez projekta, brez načrta, brez soglasja, s strani inženirjev, ki nimajo zadostne usposobljenosti,
  • s kaotičnimi, nedokumentiranimi spremembami, z veliko »smeti« in neoptimalnimi rešitvami

Jasno je, da je vaša situacija nekje vmes, a žal je na tej lestvici boljše – slabše velika verjetnost, da boste bližje najslabšemu koncu.

V tem primeru boste potrebovali tudi sposobnost branja misli, saj se boste morali naučiti razumeti, kaj so "oblikovalci" želeli narediti, obnoviti njihovo logiko, dokončati tisto, kar ni bilo dokončano, in odstraniti "smeti".
In seveda boste morali popraviti njihove napake, spremeniti (na tej stopnji čim manj) dizajn in spremeniti ali ponovno ustvariti sheme.

Ta članek nikakor ne trdi, da je popoln. Tukaj bom opisal samo splošna načela in se osredotočil na nekatere pogoste težave, ki jih je treba rešiti.

Komplet dokumentov

Začnimo s primerom.

Spodaj je nekaj dokumentov, ki jih Cisco Systems običajno ustvari med načrtovanjem.

CR – Zahteve naročnika, zahteve naročnika (tehnične specifikacije).
Ustvari se skupaj s stranko in določa omrežne zahteve.

HLD – Zasnova na visoki ravni, zasnova na visoki ravni, ki temelji na zahtevah omrežja (CR). Dokument pojasnjuje in utemeljuje sprejete arhitekturne odločitve (topologija, protokoli, izbira strojne opreme,...). HLD ne vsebuje podrobnosti zasnove, kot so uporabljeni vmesniki in naslovi IP. Tukaj tudi ni obravnavana posebna konfiguracija strojne opreme. Namesto tega je ta dokument namenjen razlagi ključnih konceptov oblikovanja tehničnemu vodstvu stranke.

LLD – Načrtovanje na nizki ravni, načrtovanje na nizkem nivoju, ki temelji na načrtovanju na visoki ravni (HLD).
Vsebovati mora vse podrobnosti, potrebne za izvedbo projekta, kot so informacije o tem, kako povezati in konfigurirati opremo. To je popoln vodnik za izvedbo zasnove. Ta dokument bi moral zagotoviti dovolj informacij za njegovo izvajanje tudi s strani manj usposobljenega osebja.

Nekaj, na primer naslove IP, številke AS, fizično preklopno shemo (kabli), je mogoče "dati" v ločenih dokumentih, kot je npr. NIP (Načrt izvedbe omrežja).

Gradnja omrežja se začne po izdelavi teh dokumentov in poteka v strogem skladu z njimi, nato pa ga stranka (preizkusi) preveri glede skladnosti z zasnovo.

Seveda imajo lahko različni integratorji, različni naročniki in različne države različne zahteve glede projektne dokumentacije. Vendar bi se rad izognil formalnostim in zadevo obravnaval po meri. V tej fazi ne gre za načrtovanje, temveč za urejanje stvari, pri čemer potrebujemo zadosten nabor dokumentov (diagrami, tabele, opisi ...) za dokončanje naših nalog.

In po mojem mnenju obstaja nek absolutni minimum, brez katerega ni mogoče učinkovito nadzorovati omrežja.

To so naslednji dokumenti:

  • diagram (log) fizičnega preklopa (kabliranja)
  • omrežni diagram ali diagrami z bistvenimi informacijami L2/L3

Fizični preklopni diagram

V nekaterih manjših podjetjih je delo v zvezi z namestitvijo opreme in fizičnim preklopom (kabliranje) v pristojnosti omrežnih inženirjev.

V tem primeru je problem delno rešen z naslednjim pristopom.

  • uporabite opis na vmesniku, da opišete, kaj je z njim povezano
  • administrativno zaustavite vsa nepovezana vrata omrežne opreme

To vam bo dalo priložnost, da tudi v primeru težave s povezavo (ko cdp ali lldp ne deluje na tem vmesniku) hitro ugotovite, kaj je povezano s temi vrati.
Prav tako lahko preprosto vidite, katera vrata so zasedena in katera prosta, kar je potrebno za načrtovanje povezav nove omrežne opreme, strežnikov ali delovnih postaj.

Vendar je jasno, da če izgubite dostop do opreme, boste izgubili tudi dostop do teh informacij. Poleg tega na ta način ne boste mogli zabeležiti tako pomembnih informacij, kot so vrsta opreme, kakšna poraba energije, koliko vrat, v katerem omari je, kateri patch paneli so tam in kje (v katerem omari/patch panelu ) so povezani . Zato je dodatna dokumentacija (ne le opisi na opremi) še kako koristna.

Idealna možnost je uporaba aplikacij, zasnovanih za delo s to vrsto informacij. Lahko pa se omejite na preproste tabele (na primer v Excelu) ali prikažete informacije, ki se vam zdijo potrebne v diagramih L1/L2.

Pomembno!

Omrežni inženir seveda lahko precej dobro pozna podrobnosti in standarde SCS, vrste regalov, vrste neprekinjenih napajalnikov, kaj je hladen in topel prehod, kako narediti pravilno ozemljitev ... tako kot načeloma lahko pozna fiziko osnovnih delcev ali C++. Toda vseeno je treba razumeti, da vse to ni njegovo področje znanja.

Zato je dobra praksa imeti namenske oddelke ali namenske ljudi za reševanje težav v zvezi z namestitvijo, priklopom, vzdrževanjem opreme ter fizičnim preklopom. Običajno so to za podatkovne centre inženirji podatkovnih centrov, za pisarne pa služba za pomoč uporabnikom.

Če so v vašem podjetju takšne delitve zagotovljene, potem vprašanja beleženja fizičnega preklopa niso vaša naloga in se lahko omejite le na opis na vmesniku in administrativno zaustavitev neuporabljenih vrat.

Omrežni diagrami

Ni univerzalnega pristopa k risanju diagramov.

Najpomembneje je, da diagrami omogočajo razumevanje, kako bo potekal promet, skozi katere logične in fizične elemente vašega omrežja.

S fizičnimi elementi mislimo

  • aktivna oprema
  • vmesniki/vrata aktivne opreme

Pod logično -

  • logične naprave (N7K VDC, Palo Alto VSYS, ...)
  • VRF
  • Vilans
  • podvmesniki
  • tuneli
  • cona
  • ...

Tudi, če vaše omrežje ni povsem osnovno, bo sestavljeno iz različnih segmentov.
Na primer

  • podatkovno središče
  • Internet
  • WAN
  • oddaljen dostop
  • pisarniški LAN
  • DMZ
  • ...

Pametno je imeti več diagramov, ki dajejo tako veliko sliko (kako poteka promet med vsemi temi segmenti) kot tudi podrobno razlago vsakega posameznega segmenta.

Ker je v sodobnih omrežjih lahko veliko logičnih plasti, je morda dober (vendar ne nujen) pristop narediti različna vezja za različne plasti, na primer v primeru prekrivnega pristopa so to lahko naslednja vezja:

  • prekrivni
  • Podloga L1/L2
  • Podloga L3

Seveda je najpomembnejši diagram, brez katerega je nemogoče razumeti idejo vašega dizajna, diagram usmerjanja.

Shema usmerjanja

Ta diagram mora odražati vsaj

  • kateri usmerjevalni protokoli se uporabljajo in kje
  • osnovne informacije o nastavitvah usmerjevalnega protokola (območje/številka AS/router-id/…)
  • na katerih napravah pride do prerazporeditve?
  • kjer pride do filtriranja in združevanja poti
  • informacije o privzeti poti

Pogosto je uporabna tudi shema L2 (OSI).

Shema L2 (OSI)

Ta diagram lahko prikazuje naslednje informacije:

  • kakšni VLAN-i
  • katera vrata so trunk vrata
  • katera vrata so združena v kanal ether (kanal vrat), kanal virtualnih vrat
  • kateri protokoli STP se uporabljajo in na katerih napravah
  • osnovne nastavitve STP: root/root backup, stroški STP, prioriteta vrat
  • dodatne nastavitve STP: BPDU guard/filter, root guard…

Tipične napake pri oblikovanju

Primer slabega pristopa k izgradnji mreže.

Vzemimo preprost primer gradnje preprostega pisarniškega lokalnega omrežja.

Glede na izkušnje s poučevanjem telekomunikacij študentom lahko rečem, da ima tako rekoč vsak študent do sredine drugega semestra potrebno znanje (v okviru predmeta, ki sem ga predaval) za postavitev preprostega pisarniškega LAN-a.

Kaj je tako težkega pri medsebojnem povezovanju stikal, nastavitvi VLAN-ov, SVI vmesnikov (v primeru L3 stikal) in nastavitvi statičnega usmerjanja?

Vse bo delovalo.

A hkrati se vprašanja v zvezi z

  • varnost
  • rezervacija
  • skaliranje omrežja
  • produktivnost
  • prepustnost
  • zanesljivost
  • ...

Od časa do časa slišim izjavo, da je pisarniški LAN nekaj zelo preprostega in to običajno slišim od inženirjev (in menedžerjev), ki delajo vse, razen omrežij, in to trdijo tako samozavestno, da ne bodite presenečeni, če bo LAN naredili ljudje z nezadostno prakso in znanjem in bodo narejeni s približno enakimi napakami, kot jih bom opisal v nadaljevanju.

Pogoste načrtovalske napake L1 (OSI).

  • Če pa ste kljub temu odgovorni tudi za SCS, potem je ena najbolj neprijetnih zapuščin, ki jih lahko prejmete, neprevidno in nepremišljeno menjavanje.

Med napake tipa L1 bi uvrstil tudi napake, povezane z viri uporabljene opreme, na primer

  • nezadostna pasovna širina
  • nezadosten TCAM na opremi (ali neučinkovita uporaba le-te)
  • nezadostna zmogljivost (pogosto povezana s požarnimi zidovi)

Pogoste načrtovalske napake L2 (OSI).

Pogosto, ko ni dobrega razumevanja, kako STP deluje in kakšne morebitne težave prinaša s seboj, se stikala povezujejo kaotično, s privzetimi nastavitvami, brez dodatne nastavitve STP.

Posledično imamo pogosto naslednje

  • velik premer omrežja STP, kar lahko privede do oddajnih neviht
  • Koren STP bo določen naključno (na podlagi naslova mac) in prometna pot bo neoptimalna
  • vrata, povezana z gostitelji, ne bodo konfigurirana kot robna (portfast), kar bo vodilo do ponovnega izračuna STP pri vklopu/izklopu končnih postaj
  • omrežje ne bo segmentirano na ravni L1/L2, zaradi česar bodo težave s katerimkoli stikalom (na primer preobremenitev z električno energijo) vodile do ponovnega izračuna topologije STP in zaustavitve prometa v vseh VLAN na vseh stikalih (vključno z en kritičen z vidika storitvenega segmenta kontinuitete)

Primeri napak pri oblikovanju L3 (OSI).

Nekaj ​​tipičnih napak omrežnikov začetnikov:

  • Pogosta uporaba (ali samo uporaba) statičnega usmerjanja
  • uporaba neoptimalnih usmerjevalnih protokolov za dano zasnovo
  • suboptimalna logična segmentacija omrežja
  • neoptimalna uporaba naslovnega prostora, ki ne omogoča združevanja poti
  • ni rezervnih poti
  • ni rezervacije za privzeti prehod
  • asimetrično usmerjanje pri vnovični izgradnji poti (lahko kritično v primeru NAT/PAT, požarnih zidov s popolnim stanjem)
  • težave z MTU
  • ko so poti ponovno zgrajene, gre promet skozi druga varnostna območja ali celo druge požarne zidove, zaradi česar se ta promet zmanjša
  • slaba skalabilnost topologije

Kriteriji za ocenjevanje kakovosti oblikovanja

Ko govorimo o optimalnosti/neoptimalnosti, moramo razumeti, po katerih kriterijih lahko to ocenjujemo. Tu so z mojega vidika najpomembnejša (vendar ne vsa) merila (in razlaga v zvezi s protokoli usmerjanja):

  • razširljivost
    Na primer, odločite se dodati še en podatkovni center. Kako preprosto lahko to storite?
  • enostavnost uporabe (vodljivost)
    Kako preproste in varne so operativne spremembe, kot je najava novega omrežja ali filtriranje poti?
  • razpoložljivost
    Kolikšen odstotek časa vaš sistem zagotavlja zahtevano raven storitev?
  • varnost
    Kako varni so preneseni podatki?
  • Cena

Spremembe

Osnovno načelo na tej stopnji lahko izrazimo s formulo »ne škodi«.
Zato, tudi če se z zasnovo in izbrano izvedbo (konfiguracijo) ne strinjate v celoti, spremembe niso vedno priporočljive. Razumen pristop je, da vse ugotovljene težave razvrstimo glede na dva parametra:

  • kako preprosto je mogoče to težavo odpraviti
  • koliko tveganja nosi?

Najprej je treba odpraviti tisto, kar trenutno znižuje raven storitev pod sprejemljivo raven, na primer težave, ki vodijo do izgube paketov. Nato popravite tisto, kar je najlažje in najvarneje popraviti v padajočem vrstnem redu glede na resnost tveganja (od težav z zasnovo ali konfiguracijo z visokim tveganjem do tistih z nizkim tveganjem).

Perfekcionizem na tej stopnji je lahko škodljiv. Pripravite načrt v zadovoljivo stanje in ustrezno sinhronizirajte konfiguracijo omrežja.

Vir: www.habr.com

Dodaj komentar