Šis straipsnis yra antrasis iš straipsnių serijos „Kaip valdyti tinklo infrastruktūrą“. Galima rasti visų serijos straipsnių turinį ir nuorodas .
Mūsų tikslas šiame etape yra sutvarkyti dokumentaciją ir konfigūraciją.
Šio proceso pabaigoje turėtumėte turėti reikiamą dokumentų rinkinį ir pagal juos sukonfigūruotą tinklą.
Dabar apie saugumo auditus nekalbėsime – tai bus trečiosios dalies tema.
Žinoma, šiame etape pavestos užduoties atlikimo sunkumai įvairiose įmonėse labai skiriasi.
Ideali situacija yra tada, kai
- jūsų tinklas buvo sukurtas pagal projektą ir jūs turite visą dokumentų rinkinį
- buvo įdiegtas jūsų įmonėje tinklui
- pagal šį procesą turite dokumentus (įskaitant visas reikalingas diagramas), kuriuose pateikiama visa informacija apie esamą padėtį
Šiuo atveju jūsų užduotis yra gana paprasta. Turėtumėte išstudijuoti dokumentus ir peržiūrėti visus padarytus pakeitimus.
Blogiausiu atveju turėsite
- tinklas, sukurtas be projekto, be plano, be pritarimo, inžinierių, kurie neturi pakankamai kvalifikacijos,
- su chaotiškais, nedokumentuotais pokyčiais, su daugybe „šiukšlių“ ir neoptimalių sprendimų
Akivaizdu, kad jūsų situacija yra kažkur tarp jų, bet, deja, šioje skalėje geriau - blogiau yra didelė tikimybė, kad būsite arčiau blogiausio galo.
Tokiu atveju prireiks ir gebėjimo skaityti mintis, nes teks išmokti suprasti, ką norėjo padaryti „dizaineriai“, atkurti savo logiką, užbaigti tai, kas nepabaigta, ir pašalinti „šiukšles“.
Ir, žinoma, reikės ištaisyti jų klaidas, pakeisti (šiuo etapu kuo mažiau) dizainą ir keisti arba perkurti schemas.
Šis straipsnis jokiu būdu nepretenduoja į išsamumą. Čia aprašysiu tik bendruosius principus ir sutelksiu dėmesį į kai kurias įprastas problemas, kurias reikia išspręsti.
Dokumentų rinkinys
Pradėkime nuo pavyzdžio.
Toliau pateikiami kai kurie dokumentai, kurie paprastai kuriami Cisco Systems projektuojant.
CR – Kliento reikalavimai, klientų reikalavimai (techninės specifikacijos).
Jis kuriamas kartu su klientu ir nustato tinklo reikalavimus.HLD – Aukšto lygio dizainas, aukšto lygio projektavimas, pagrįstas tinklo reikalavimais (CR). Dokumente paaiškinami ir pagrindžiami priimti architektūriniai sprendimai (topologija, protokolai, techninės įrangos parinkimas,...). HLD nėra dizaino informacijos, pvz., naudojamų sąsajų ir IP adresų. Taip pat čia neaptariama konkreti aparatinės įrangos konfigūracija. Atvirkščiai, šis dokumentas skirtas paaiškinti pagrindines dizaino koncepcijas kliento techniniam valdymui.
LLD – Žemo lygio dizainas, žemo lygio dizainas, pagrįstas aukšto lygio dizainu (HLD).
Jame turėtų būti visa informacija, reikalinga projektui įgyvendinti, pavyzdžiui, informacija apie tai, kaip prijungti ir konfigūruoti įrangą. Tai yra išsamus dizaino įgyvendinimo vadovas. Šiame dokumente turėtų būti pateikta pakankamai informacijos, kad jį galėtų įgyvendinti net ir mažiau kvalifikuoti darbuotojai.Kažkas, pavyzdžiui, IP adresai, AS numeriai, fizinio perjungimo schema (kabeliai), gali būti „išdėlioti“ atskiruose dokumentuose, pvz. NOP (Tinklo diegimo planas).
Tinklo statyba pradedama sukūrus šiuos dokumentus ir vyksta griežtai laikantis jų, o vėliau užsakovas tikrina (testai) ar atitinka projektą.
Žinoma, skirtingi integratoriai, skirtingi klientai ir skirtingos šalys gali turėti skirtingus reikalavimus projekto dokumentacijai. Bet norėčiau išvengti formalumų ir svarstyti klausimą iš esmės. Šis etapas skirtas ne projektavimui, o reikalų sutvarkymui, o mums reikia pakankamai dokumentų (schemų, lentelių, aprašymų...) mūsų užduotims atlikti.
Ir, mano nuomone, yra tam tikras absoliutus minimumas, be kurio neįmanoma efektyviai valdyti tinklo.
Tai yra šie dokumentai:
- fizinio perjungimo (kabelių) diagrama (logas)
- tinklo schema arba diagramos su esmine L2/L3 informacija
Fizinio perjungimo schema
Kai kuriose mažose įmonėse už darbus, susijusius su įrangos montavimu ir fiziniu perjungimu (laidavimu), atsako tinklo inžinieriai.
Šiuo atveju problema iš dalies išspręsta taikant šį metodą.
- naudokite sąsajos aprašymą, kad apibūdintumėte, kas su ja prijungta
- administraciniu būdu išjungti visus neprijungtus tinklo įrangos prievadus
Tai suteiks jums galimybę, net jei kiltų problemų dėl nuorodos (kai cdp arba lldp neveikia šioje sąsajoje), greitai nustatyti, kas prijungta prie šio prievado.
Taip pat nesunkiai matysite, kurie prievadai yra užimti, o kurie laisvi, o tai būtina planuojant naujos tinklo įrangos, serverių ar darbo vietų jungtis.
Tačiau aišku, kad praradę prieigą prie įrangos, neteksite ir šios informacijos. Be to, tokiu būdu negalėsite įrašyti tokios svarbios informacijos, kaip kokia įranga, kokios energijos sąnaudos, kiek prievadų, kokiame stove yra, kokios yra pataisų plokštės ir kur (kokiame stove/patch panele) ) jie yra sujungti. Todėl papildoma dokumentacija (ne tik įrangos aprašymai) vis dar labai praverčia.
Idealus variantas yra naudoti programas, skirtas dirbti su tokio tipo informacija. Tačiau galite apsiriboti paprastomis lentelėmis (pvz., „Excel“) arba rodyti informaciją, kuri, jūsų manymu, reikalinga L1/L2 diagramose.
Svarbu!
Tinklo inžinierius, žinoma, gali gana gerai išmanyti SCS subtilybes ir standartus, stelažų tipus, nepertraukiamo maitinimo šaltinių tipus, kas yra šaltas ir karštas praėjimas, kaip tinkamai įžeminti... kaip ir iš principo. išmanyti elementariųjų dalelių fiziką arba C++. Bet vis tiek reikia suprasti, kad visa tai nėra jo žinių sritis.
Todėl gera praktika yra turėti tam skirtus skyrius arba specialius žmones, kurie spręstų problemas, susijusias su įrengimu, prijungimu, įrangos priežiūra, taip pat su fiziniu perjungimu. Paprastai duomenų centrams tai yra duomenų centrų inžinieriai, o biurui – pagalbos tarnyba.
Jei jūsų įmonėje yra numatyti tokie skyriai, fizinių perjungimų registravimo klausimai nėra jūsų užduotis ir galite apsiriboti tik sąsajos aprašymu ir nenaudojamų prievadų administraciniu išjungimu.
Tinklo diagramos
Nėra universalaus požiūrio į diagramų braižymą.
Svarbiausia, kad diagramos turėtų padėti suprasti, kaip eismas vyks, per kuriuos loginius ir fizinius jūsų tinklo elementus.
Fiziniais elementais turime omenyje
- aktyvioji įranga
- aktyviosios įrangos sąsajos/prievadai
Pagal logiką -
- loginiai įrenginiai (N7K VDC, Palo Alto VSYS, ...)
- VRF
- Vilanas
- antrinės sąsajos
- tuneliai
- zona
- ...
Be to, jei jūsų tinklas nėra visiškai elementarus, jis susideda iš skirtingų segmentų.
Pavyzdžiui
- duomenų centras
- Internetas
- WAN
- Nuotolinis prisijungimas
- biuro LAN
- DMZ
- ...
Išmintinga turėti kelias diagramas, kuriose pateikiamas bendras vaizdas (kaip eismas vyksta tarp visų šių segmentų) ir išsamus kiekvieno atskiro segmento paaiškinimas.
Kadangi šiuolaikiniuose tinkluose gali būti daug loginių sluoksnių, galbūt yra geras (bet nebūtinas) būdas sukurti skirtingas grandines skirtingiems sluoksniams, pavyzdžiui, perdangos metodo atveju tai gali būti šios grandinės:
- apdangalas
- L1/L2 paklotas
- L3 paklotas
Žinoma, svarbiausia diagrama, be kurios neįmanoma suprasti jūsų dizaino idėjos, yra maršruto schema.
Maršruto schema
Mažiausiai ši diagrama turėtų atspindėti
- kokie maršruto parinkimo protokolai naudojami ir kur
- pagrindinė informacija apie maršruto parinkimo protokolo nustatymus (sritis/AS numeris/maršrutizatoriaus ID/...)
- kuriuose įrenginiuose vyksta perskirstymas?
- kur vyksta filtravimas ir maršrutų agregavimas
- numatytoji maršruto informacija
Be to, dažnai naudinga L2 schema (OSI).
L2 schema (OSI)
Šioje diagramoje gali būti parodyta ši informacija:
- kokie VLAN
- kurie prievadai yra magistraliniai prievadai
- kurie prievadai sujungiami į eterinį kanalą (prievado kanalą), virtualų prievado kanalą
- kokie STP protokolai naudojami ir kokiuose įrenginiuose
- pagrindiniai STP nustatymai: root/root atsarginė kopija, STP kaina, prievado prioritetas
- papildomi STP nustatymai: BPDU apsauga/filtras, šaknies apsauga...
Tipiškos dizaino klaidos
Blogo požiūrio kuriant tinklą pavyzdys.
Paimkime paprastą paprasto biuro LAN kūrimo pavyzdį.
Turėdamas telekomunikacijų dėstymo studentams patirties, galiu pasakyti, kad beveik bet kuris studentas iki antrojo semestro vidurio turi reikiamų žinių (kaip dalį kurso, kurį dėstau), kad susikurtų paprastą biuro LAN.
Kas tokio sudėtingo jungiant jungiklius vienas prie kito, nustatant VLAN, SVI sąsajas (L3 komutatorių atveju) ir statinį maršrutą?
Viskas veiks.
Bet tuo pačiu metu klausimai, susiję su
- saugumas
- rezervacija
- tinklo mastelio keitimas
- produktyvumas
- pralaidumas
- patikimumas
- ...
Kartkartėmis išgirstu teiginį, kad biuro LAN yra kažkas labai paprasto ir dažniausiai tai girdžiu iš inžinierių (ir vadovų), kurie daro viską, išskyrus tinklus, ir jie tai sako taip užtikrintai, kad nenustebkite, jei LAN bus padarė žmonės, neturintys pakankamai praktikos ir žinių, ir jie bus padaryti su maždaug tomis pačiomis klaidomis, kurias aprašysiu toliau.
Dažnos L1 (OSI) projektavimo klaidos
- Jei vis dėlto esate atsakingas už SCS, vienas iš nemaloniausių palikimų, kuriuos galite gauti, yra neatsargus ir neapgalvotas perjungimas.
Taip pat L1 tipui priskirčiau klaidas, susijusias su naudojamos įrangos ištekliais, pvz.
- nepakankamas pralaidumas
- nepakankamas TCAM įrangoje (arba neefektyvus jos naudojimas)
- nepakankamas našumas (dažnai susijęs su ugniasienėmis)
Dažnos L2 (OSI) projektavimo klaidos
Dažnai, kai nėra gero supratimo, kaip veikia STP ir kokias galimas problemas jis atneša, jungikliai sujungiami chaotiškai, su numatytaisiais nustatymais, be papildomo STP derinimo.
Dėl to dažnai turime šiuos dalykus
- didelis STP tinklo skersmuo, dėl kurio gali kilti transliacijos audros
- STP šaknis bus nustatyta atsitiktinai (pagal Mac adresą), o srauto kelias bus neoptimalus
- prievadai, prijungti prie pagrindinio kompiuterio, nebus sukonfigūruoti kaip krašto (portfast), todėl įjungiant / išjungiant galines stotis bus perskaičiuojamas STP
- tinklas nebus segmentuotas L1/L2 lygiu, dėl to bet kurio jungiklio problemos (pvz., galios perkrova) lems STP topologijos perskaičiavimą ir srauto sustabdymą visuose VLAN visuose komutatoriuose (įskaitant vienas kritinis paslaugų tęstinumo segmento požiūriu)
L3 (OSI) projektavimo klaidų pavyzdžiai
Keletas tipiškų pradedančiųjų tinklų klaidų:
- Dažnas (arba tik) statinio maršruto parinkimo naudojimas
- neoptimalaus maršruto parinkimo protokolų naudojimas tam tikram dizainui
- neoptimalus loginis tinklo segmentavimas
- neoptimalus adresų erdvės išnaudojimas, neleidžiantis agreguoti maršrutų
- jokių atsarginių maršrutų
- nėra numatytojo šliuzo rezervavimo
- asimetriškas maršrutas atkuriant maršrutus (gali būti labai svarbus NAT / PAT, būsenos užkardos atveju)
- problemų su MTU
- atstatant maršrutus, eismas vyksta per kitas apsaugos zonas ar net kitas užkardas, todėl šis srautas nutrūksta
- prastas topologijos mastelio keitimas
Projektavimo kokybės vertinimo kriterijai
Kai kalbame apie optimalumą/neoptimalumą, turime suprasti, kokiais kriterijais galime tai įvertinti. Čia, mano požiūriu, yra svarbiausi (bet ne visi) kriterijai (ir paaiškinimas, susijęs su maršruto parinkimo protokolais):
- mastelio keitimas
Pavyzdžiui, nuspręsite pridėti kitą duomenų centrą. Kaip lengva tai padaryti? - naudojimo paprastumas (valdomumas)
Ar paprasti ir saugūs veiklos pakeitimai, pvz., naujo tinklo paskelbimas ar maršrutų filtravimas? - prieinamumas
Kiek procentų laiko jūsų sistema teikia reikiamo lygio paslaugas? - saugumo
Kiek saugūs perduodami duomenys? - kaina
Pokyčiai
Pagrindinis principas šiame etape gali būti išreikštas formule „nedaryti žalos“.
Todėl net ir visiškai nesutinkant su dizainu ir pasirinkta realizacija (konfigūracija), ne visada patartina daryti pakeitimus. Pagrįstas metodas yra visas nustatytas problemas reitinguoti pagal du parametrus:
- kaip lengvai galima išspręsti šią problemą
- kiek ji rizikuoja?
Visų pirma, būtina pašalinti tai, kas šiuo metu sumažina teikiamų paslaugų lygį žemiau priimtino lygio, pavyzdžiui, problemas, dėl kurių dingsta paketai. Tada mažėjančia rizikos laipsnio tvarka ištaisykite tai, ką lengviausia ir saugiausia (nuo didelės rizikos dizaino ar konfigūracijos problemų iki mažos rizikos).
Perfekcionizmas šiame etape gali būti žalingas. Įveskite dizainą į patenkinamą būseną ir atitinkamai sinchronizuokite tinklo konfigūraciją.
Šaltinis: www.habr.com