See artikkel on juba teine osa artiklite tsüklist "Kuidas võtta oma võrguinfrastruktuuri kontrolli alla". Tsükli kõigi artiklite sisu ja lingid leiate .
Meie eesmärk käesolevas etapis on dokumentatsioon ja konfiguratsioon korda saada.
Selle protsessi tulemusena peaks teil olema vajalik dokumentide komplekt ja võrgu konfiguratsioon vastavalt neile.
Praegu me ei räägi turbeauditi läbiviimisest – sellele pühendame kolmanda osa.
Etapi ülesande täitmise keerukus varieerub kindlasti ettevõttest ettevõttesse.
Ideaalne olukord on see, kui
- teie võrk on loodud vastavalt projektile ja teil on täielik dokumentide komplekt
- teie ettevõttes on juurutatud võrgus
- vastavalt sellele protsessile on teil dokumendid (sealhulgas kõik vajalikud skeemid), mis annavad täieliku teabe praegusest olukorrast
Sellisel juhul on teie ülesanne suhteliselt lihtne. Peate uurima dokumente ja vaatama üle kõik muudatused, mis on tehtud.
Halvimal juhul on teil
- võrk, mis on loodud ilma projektita, plaanita, kooskõlastamata, inseneride poolt, kes ei oma piisavat kvalifikatsiooni,
- korraga tekkinud, dokumenteerimata muudatustega, suure hulga "prügiga" ja aladega, mis on optimeerimata.
On selge, et teie olukord on kuskil vahepeal, kuid kahjuks olete tõenäoliselt selle skaalal halvemal poolel.
Sellisel juhul vajate ka mõtte lugemise oskust, sest peate õppima mõistma, mida „disainerid“ tahtsid saavutada, taastama nende loogika, lõpetama need, mis on pooleli jäänud, ning eemaldama „prügi“.
Ja muidugi peate piirama nende vigu, muutma (kui võimalik, siis selle etapi jooksul minimaalselt) projekti ning muutma või täiesti uusi skeeme looma.
See artikkel ei pretendeeri üheski osas täielikkusele. Siin kirjeldan vaid üldisi põhimõtteid ja peatun mõnel levinud probleemil, millega tuleb kokku puutuda.
Dokumendikomplekt
Alustame näitest.
Allpool on toodud mõned dokumendid, mis on tavalised Cisco Systemsis projekteerimisel.
CR – Klientide nõuded, teh. ülesanne.
Loob loodud koos kliendiga ja määratleb võrgu nõuded.HLD – High Level Design, kõrgetasemeline disain võrgu nõuete alusel (CR). Dokument selgitab ja põhjendab tehtud arhitektuurilisi otsuseid (topoloogia, protokollid, seadmete valik jne). HLD ei sisalda disaini detaile, näiteks, kasutatakse liideseid ja IP-aadresse. Siin ei arutata ka seadmete konkreetset konfigureerimist. See dokument on pigem mõeldud tehnilise juhtkonna võtmeidee selgitamiseks.
LLD – Low Level Design, madalatase disain kõrgetasemelisest (HLD).
See peab sisaldama kõiki üksikasju, mis on vajalikud projekti elluviimiseks, nagu teave seadmete ühendamise ja seadistamise kohta. See on täielik juhend disaini rakendamiseks. See dokument peab andma piisavalt teavet, et seda saaks rakendada isegi mitte väga kvalifitseeritud personal.Mõned asjad, näiteks IP-aadressid, AS-numerid, füüsilise ühendamise skeem (cabling), võivad olla "välja toodud" eraldi dokumentides, näiteks NIP (Network Implementation Plan).
Võrgu loomine algab pärast nende dokumentide koostamist ja toimub rangelt nende põhjal ning seejärel kontrollib klient (testid) vastavust disainile.
Muidugi võivad erinevatel integreerijatel, erinevatel klientidel, erinevates riikides olla projektidokumentatsiooni nõuded erinevad. Kuid sooviks vältida formaalsusi ja käsitleda küsimust asja olemuse järgi. See etapp ei ole mitte disainimise küsimus, vaid korra seadmine ja me vajame piisavat dokumentide kogumit (skeeme, tabeleid, kirjeldusi jne) meie ülesannete täitmiseks.
Ja minu arvates on olemas teatud absoluutne miinimum, ilma milleta ei ole võimalik tõhusalt võrku kontrollida.
Need dokumendid on järgmised:
- füüsilise ühendamise (cabling) skeem (ajakiri)
- võrgu skeem või skeemid, milles on olulist L2/L3 teavet
Füüsilise ühenduse skeem
Mõnes väikeses ettevõttes on seadmete paigaldamise ja füüsilise ühendamise (cabling) tööde vastutus võrguspetsialistide käes.
Sellisel juhul lahendatakse ülesanne osaliselt järgmise lähenemise kaudu.
- kasutage liidese kirjeldust selle kohta, mis on ühendatud
- halduslikult deaktiveerige (shutdown) kõik ühendamata võrguseadmete pordid.
See võimaldab teil kiiresti tuvastada, mis on selle porti külge ühendatud, isegi kui esineb probleeme ühenduse loomisega (kui CDP või LLDP ei tööta sellel liidesel).
Samuti näete kergesti, millised ports on teie poolt kasutuses ja millised on vabad, mis on vajalik uute võrkequipmentide, serverite või töökohtade ühenduste planeerimiseks.
Aga on selge, et kui kaotate juurdepääsu seadmetele, kaotate ka juurdepääsu sellele teabele. Sel moel ei saa te samuti dokumenteerida nii olulist teavet nagu see, milline on seade, milline on selle võimsus, kui palju porte tal on, millises racks see asub, millised on seal puudepaneelid ja kuhu (millises rack/puudepaneel) need on ühendatud. Seetõttu on siiski täiendav dokumenteerimine (mitte ainult seadmete kirjeldused) väga kasulik.
Ideaalseks lahenduseks on kasutada rakendusi, mis on loodud sellise teabe töötlemiseks. Kuid piirduda võib ka lihtsate tabelitega (nt Excelis) või kuvada teabe, mida peate vajalikuks L1/L2 skeemides.
Oluline!
Võrguinsener võib muidugi teada niššide ja klassikaliste standardite, rackide tüüpide, katkematu toiteallika tüüpide, külma ja sooja koridori olemuse kohta, teha õige maanduse jne, samas kui ta võib põhimõtteliselt teada ka elementaarosakeste füüsikat või C++. Kuid tuleb mõista, et kõik see ei kuulu tema teadmiste valdkonda.
Seetõttu on hea praktika, et seadmete paigaldamise, ühendamise, töövõimekuse säilitamise ja füüsilise ühendamisega seotud ülesannete lahendamiseks on olemas eraldi osakonnad või eraldi inimesed. Tüüpiliselt and on andmekeskustes andmekeskuse insenerid ja kontoris - tootetugi.
Kui teie ettevõttes on sellised osakonnad olemas, siis füüsilise ühenduse ajakohastamise küsimused ei ole teie ülesanne ja võite piirduda ainult liidesete kirjeldustega ja mittekasutatavate portide haldamisega.
Võrguskeemid
Ühtegi universaalset lähenemist skeemide joonistamiseks ei ole.
Oluline on see, et skeemid peaksid andma arusaama, kuidas liiklus liigub, milliste loogiliste ja füüsiliste elementide kaudu teie võrgus.
Füüsiliste elementidena mõtleme me
- aktiivne varustus
- aktiivsete seadmete liidesed/portid
Loogiliste —
- loogilised seadmed (N7K VDC, Palo Alto VSYS, …)
- VRF
- võrgud
- alamliidesed
- tunnelid
- piirkonnad
- …
Samuti, kui teie võrk ei ole üldse elementaarne, koosneb see erinevatest segmentidest.
Näiteks
- andmekeskus
- internet
- WAN
- kaugjuurdepääs
- kontori LAN
- DMZ
- …
Mõistlik oleks omada mitmeid skeeme, mis annavad nii üldise ülevaate (kuidas liiklus liigub kõikide nende segmentide vahel) kui ka detailse selgituse iga üksiku segmendi kohta.
Kuna tänapäevastes võrkudes võib olla palju loogilisi tasemeid, võib olla hea (kuigi mitte kohustuslik) lähenemine koostada erinevaid skeeme erinevate tasemete jaoks, näiteks juhul, kui kasutada overlay-lähenemist, võivad selleks olla järgmised skeemid:
- overlay
- L1/L2 allkihi
- L3 allkihi
Muidugi, kõige olulisem skeem, ilma milleta ei saa teie disaini ideed mõista, on marsruutimise skeem.
Marsruudingu skeem
Kui mitte vähem, siis peaks selles skeemis olema kõrvaldatud
- millised marsruutimisprotokollid ja kus neid kasutatakse
- peamine teave marsruutimisprotokolli seadistuste kohta (area/AS number/router-id/…)
- millistel seadmetel toimub redistriibimine
- kus toimub marsruutide filtreerimine ja agregatsioon
- teave vaikimisi marsruudi kohta
Samuti on sageli kasulik L2 skeem (OSI).
L2 skeem (OSI)
Selles skeemis võib olla esitatud järgmine teave:
- millised VLAN-id
- millised portid on trunk-portid
- millised portid on koondatud ether-channel'i (port channel), virtuaalse port channel'i
- milliseid STP protokolle ja millistel seadmetel kasutatakse
- STP põhiseaded: root/root backup, STP hind, portide prioriteet
- STP täiendavad seadistused: BPDU guard/filter, root guard…
Tüüpilised vead projekteerimises
Halva lähenemise näide võrgu ehitamisel.
Võtame lihtsa näite lihtsa kontorilokaalse võrgu ehitamisest.
Olles kogenud telekomi õpetajana üliõpilastele, võin öelda, et praktiliselt igal üliõpilasel on teise semestri keskpaigaks vajalikud teadmised (kursuse raames, mida ma õpetasin) lihtsa kontori LAN seadistamiseks.
Mis on nii keerulist, et ühendada lülitid omavahel, seadistada VLAN-id, SVI liideseid (L3 lülitite puhul) ja määrata staatiline marsruutimine?
Kõik töötab.
Kuid sellega jäävad kõrvale küsimused, mis on seotud
- turvalisusega
- varundamisega
- võrgu skaleeritavusega
- sooritusvõimega
- läbilaskevõimega
- usaldusväärsusega
- …
Mõnikord kuulen väidet, et kontorite LAN on midagi väga lihtsat, ja kuulen seda tavaliselt inseneridelt (ja juhtidelt), kes tegelevad kõigega muuga, ainult mitte võrkudega, ning nad ütlevad seda nii enesekindlalt, et ärge imestage, kui LAN-i teevad inimesed, kellel on ebapiisavad harjutused ja teadmised, ning see viiakse ellu umbmääraste vigadega, mida kirjeldan veidi allpool.
Iseloomulikud L1 (OSI) taseme disaini vead
- Kui olete siiski ka vastutav struktuurilise kaablite süsteemi (SKS) eest, siis üks kõige ebameeldivamaid pärandeid, mis teil võib olla, on hoolimatu ja läbi mõtlemata ühendamine.
Samuti kuuluks L1 tüüpi vead seadmeressursside kasutamisega seotud vead, näiteks
- ebapiisav läbilaskevõime
- ebapiisav TCAM seadmel (või selle ebaefektiivne kasutamine)
- ebapiisav jõudlus (tihti puudutab tulemüüre)
Iseloomulikud L2 (OSI) taseme disaini vead
Sageli, kui puudub hea arusaam sellest, kuidas STP töötab, ja milliseid potentsiaalseid probleeme see endaga kaasas kannab, ühendatakse lülitid suvaliselt, vaikeseadetega, ilma STP täiendava häälestamiseta.
Tulemusena on sageli järgnev
- suure STP võrgu diameeter, mis võib põhjustada broadcast torme
- STP juur määratakse juhuslikult (MAC-aadressi alusel) ja liiklusvoog on alaealine
- sadulad, mis on ühendatud hostidega, ei ole seadistatud nagu edge (portfast), mis toob kaasa STP ümberarvutamise lõppseadmete sisse-/väljalülitamisel
- võrk ei ole L1/L2 tasemel segmenteeritud, mistõttu iga lüliti (nt toiteülekoormus) probleem põhjustab STP topoloogia ümberarvutamise ja liikluse seiskumise kõigis VLAN-ides kõigis lülitites (sealhulgas kriitilises teenusekatkestuse segmendis)
Näited projekti L3 (OSI) vigadest
Mõned iseloomulikud vead algajate võrkude spetsialistide seas:
- tihe või ainult staatilise marsruutimise kasutamine
- kõnealuse disaini jaoks mitteoptimaalsete marsruutimisprotokollide kasutamine
- mitteoptimaalne loogiline võrgu segmenteerimine
- mitteoptimaalne aadressiruumide kasutamine, mis takistab marsruutide aggregatsiooni
- varumarsruutide puudumine
- default gateway'i varupäästmise puudumine
- asümmeetriline marsruutimine marsruutide ümberkorraldamisel (see võib olla kriitiline NAT/PAT, stateful tulemüüride korral)
- MTU probleemid
- marsruutide ümberkorraldamise ajal liigub liiklus läbi teiste turvapiirkondade või isegi teiste tulemüüride, mis põhjustab selle liikluse katkestamise
- halb skaleeritavus topoloogias
Kujunduse kvaliteedi hindamise kriteeriumid
Kui me räägime optimaalsusest/mitteoptimaalsusest, siis peame mõistma, milliste kriteeriumide alusel saame seda hinnata. Minu arvates on kõige olulisemad (kuigi mitte kõik) kriteeriumid (ja seletused seoses marsruutimisprotokollidega):
- skaaleeritavus (scalability)
Näiteks, kui otsustasite lisada veel ühe andmekeskuse. Kui lihtsalt saate seda teha? - haldusmugavus (manageability)
Kui lihtne ja ohutu on operatiivsete muudatuste tegemine, näiteks uue võrgustiku kuulutamine või marsruutide filtreerimine - saadavus (availability)
Kui suur osa ajast pakub teie süsteem vajalikku teenuse taset - turvalisus (security)
Kui hästi on edastatavad andmed kaitstud - hind
Muudatused
Peamine põhimõte sel etapil saab väljendada valemiga 'ära tee halba'.
Seetõttu, isegi kui te ei ole täiesti nõus kujunduse ja valitud rakendusega (konfiguratsiooniga), ei ole alati mõistlik muudatusi teha. Mõistlik lähenemine on kõik tuvastatud probleemid alates kahest parameetrist järjekorda seada:
- kui kergesti saab seda probleemi lahendada
- kui suur risk see kujutab
Esiteks tuleks kõrvaldada see, mis hetkel alandab pakutud teenuse taset alla lubatud taseme, näiteks probleemid, mis põhjustavad pakettide kaotust. Seejärel kõrvaldage need, mida on kõige lihtsam ja ohutum kõrvaldada, riski tõsiduse vähenemise järjekorras (disaini või konfiguratsiooni probleemid, mis kujutavad suurt riski väiksemate vastu).
Perfektsionism võib sel etapil olla kahjulik. Viige kujundus rahuldavale tasemele ja sünkroniseerige võrgu konfiguratsioon vastavalt sellele.
Allikas: habr.com
