Ĉi tiu artikolo estas la dua en serio de artikoloj "Kiel Preni Kontrolon de Via Reta Infrastrukturo." La enhavo de ĉiuj artikoloj en la serio kaj ligiloj troveblas .
Nia celo en ĉi tiu etapo estas ordigi la dokumentadon kaj agordon.
Fine de ĉi tiu procezo, vi devus havi la necesan aron da dokumentoj kaj reton agordita laŭ ili.
Nun ni ne parolos pri sekurecaj revizioj - ĉi tio estos la temo de la tria parto.
La malfacileco plenumi la taskon atribuitan en ĉi tiu etapo, kompreneble, multe varias de kompanio al kompanio.
La ideala situacio estas kiam
- via reto estis kreita laŭ la projekto kaj vi havas kompletan aron da dokumentoj
- estis efektivigita en via kompanio por reto
- konforme al ĉi tiu procezo, vi havas dokumentojn (inkluzive de ĉiuj necesaj diagramoj) kiuj provizas kompletajn informojn pri la nuna stato de aferoj.
En ĉi tiu kazo, via tasko estas sufiĉe simpla. Vi devus studi la dokumentojn kaj revizii ĉiujn ŝanĝojn kiuj estis faritaj.
En la plej malbona kazo, vi havos
- reto kreita sen projekto, sen plano, sen aprobo, de inĝenieroj, kiuj ne havas sufiĉan nivelon de kvalifikoj,
- kun ĥaosaj, nedokumentitaj ŝanĝoj, kun multe da "rubo" kaj suboptimumaj solvoj
Estas klare, ke via situacio estas ie intere, sed bedaŭrinde, sur ĉi tiu skalo de pli bona - pli malbona, estas alta probablo ke vi estos pli proksime al la plej malbona fino.
En ĉi tiu kazo, vi ankaŭ bezonos la kapablon legi mensojn, ĉar vi devos lerni kompreni, kion la "projektistoj" volis fari, restarigi sian logikon, fini tion, kio ne estis finita kaj forigi "rubaĵojn".
Kaj, kompreneble, vi devos korekti iliajn erarojn, ŝanĝi (en ĉi tiu etapo kiel eble plej minimume) la dezajnon kaj ŝanĝi aŭ rekrei la skemojn.
Ĉi tiu artikolo neniel pretendas esti kompleta. Ĉi tie mi priskribos nur la ĝeneralajn principojn kaj koncentriĝos pri iuj komunaj problemoj, kiuj devas esti solvitaj.
Aro de dokumentoj
Ni komencu per ekzemplo.
Malsupre estas kelkaj dokumentoj kiuj estas kutime kreitaj ĉe Cisco Systems dum dezajno.
CR – Klientaj Postuloj, klientpostuloj (teknikaj specifoj).
Ĝi estas kreita kune kun la kliento kaj determinas la retajn postulojn.HLD - Altnivela Dezajno, altnivela dezajno bazita sur retaj postuloj (CR). La dokumento klarigas kaj pravigas la arkitekturajn decidojn prenitajn (topologio, protokoloj, aparataro elekto,...). HLD ne enhavas dezajnodetalojn, kiel la interfacoj kaj IP-adresoj uzitaj. Ankaŭ, la specifa aparatara agordo ne estas diskutita ĉi tie. Prefere, ĉi tiu dokumento celas klarigi ŝlosilajn dezajnokonceptojn al la teknika administrado de la kliento.
LLD - Malaltnivela dezajno, malaltnivela dezajno bazita sur altnivela dezajno (HLD).
Ĝi devus enhavi ĉiujn detalojn necesajn por efektivigi la projekton, kiel informojn pri kiel konekti kaj agordi la ekipaĵon. Ĉi tio estas kompleta gvidilo por efektivigi la dezajnon. Ĉi tiu dokumento devus provizi sufiĉajn informojn por ĝia efektivigo eĉ de malpli kvalifikita dungitaro.Io, ekzemple, IP-adresoj, AS-numeroj, fizika ŝanĝskemo (kablado), povas esti "elmetita" en apartaj dokumentoj, kiel ekzemple PIN (Reto-Efektivigo-Plano).
La konstruado de la reto komenciĝas post la kreado de ĉi tiuj dokumentoj kaj okazas en strikta konforme al ili kaj tiam estas kontrolita de la kliento (testoj) por konformeco al la dezajno.
Kompreneble, malsamaj integristoj, malsamaj klientoj kaj malsamaj landoj povas havi malsamajn postulojn por projektdokumentado. Sed mi ŝatus eviti formalaĵojn kaj konsideri la aferon laŭ ĝiaj meritoj. Ĉi tiu etapo ne temas pri dezajno, sed pri ordigo de aferoj, kaj ni bezonas sufiĉan aron da dokumentoj (diagramoj, tabeloj, priskriboj...) por plenumi niajn taskojn.
Kaj laŭ mi, ekzistas certa absoluta minimumo, sen kiu estas neeble efike kontroli la reton.
Ĉi tiuj estas la jenaj dokumentoj:
- diagramo (protokolo) de fizika ŝaltado (kablado)
- retdiagramo aŭ diagramoj kun esencaj L2/L3 informoj
Fizika ŝaltila diagramo
En kelkaj malgrandaj kompanioj, laboro rilata al ekipaĵinstalado kaj fizika ŝaltado (kablado) estas respondeco de retaj inĝenieroj.
En ĉi tiu kazo, la problemo estas parte solvita per la sekva aliro.
- uzu priskribon sur la interfaco por priskribi kio estas konektita al ĝi
- administre fermu ĉiujn nekonektitajn retajn ekipaĵhavenojn
Ĉi tio donos al vi la ŝancon, eĉ en la okazo de problemo kun la ligo (kiam cdp aŭ lldp ne funkcias sur ĉi tiu interfaco), rapide determini kio estas konektita al ĉi tiu haveno.
Vi ankaŭ povas facile vidi, kiuj havenoj estas okupataj kaj kiuj estas liberaj, kio estas necesa por plani konektojn de novaj retaj ekipaĵoj, serviloj aŭ laborstacioj.
Sed estas klare, ke se vi perdos aliron al la ekipaĵo, vi ankaŭ perdos aliron al ĉi tiu informo. Krome, tiamaniere vi ne povos registri tiajn gravajn informojn kiel kian ekipaĵon, kian elektran konsumon, kiom da havenoj, en kia rako ĝi estas, kiaj flikaj paneloj estas tie kaj kie (en kia rako/fakaĵpanelo). ) ili estas kunligitaj . Tial plia dokumentado (ne nur priskriboj pri la ekipaĵo) ankoraŭ estas tre utila.
La ideala opcio estas uzi aplikojn desegnitajn por labori kun ĉi tiu tipo de informoj. Sed vi povas limigi vin al simplaj tabeloj (ekzemple, en Excel) aŭ montri la informojn, kiujn vi opinias necesaj en L1/L2-diagramoj.
Grava!
Reta inĝeniero, kompreneble, povas sufiĉe bone scii la komplikaĵojn kaj normojn de SCS, specojn de rakoj, specojn de seninterrompaj elektroprovizoj, kio estas malvarma kaj varma koridoro, kiel fari taŭgan surteriĝon... same kiel principe li povas. koni la fizikon de elementaj partikloj aŭ C++. Sed oni ankoraŭ devas kompreni, ke ĉio ĉi ne estas lia scio.
Tial, estas bona praktiko havi aŭ dediĉitajn fakojn aŭ dediĉitajn homojn por solvi problemojn ligitajn al instalado, konekto, prizorgado de ekipaĵo, same kiel fizika ŝanĝado. Kutime por datumcentroj tio estas datumcentraj inĝenieroj, kaj por oficejo ĝi estas help-skribotablo.
Se tiaj dividoj estas provizitaj en via kompanio, tiam la problemoj pri registri fizikan ŝanĝadon ne estas via tasko, kaj vi povas limigi vin nur al priskribo pri la interfaco kaj administra ĉesigo de neuzataj havenoj.
Retaj diagramoj
Ne ekzistas universala aliro al desegnado de diagramoj.
La plej grava afero estas, ke la diagramoj devus provizi komprenon pri kiel trafiko fluos, tra kiuj logikaj kaj fizikaj elementoj de via reto.
Per fizikaj elementoj ni celas
- aktiva ekipaĵo
- interfacoj/havenoj de aktiva ekipaĵo
Sub logika -
- logikaj aparatoj (N7K VDC, Palo Alto VSYS, ...)
- VRF
- Vilans
- subinterfacoj
- tuneloj
- zonoj
- ...
Ankaŭ, se via reto ne estas tute elementa, ĝi konsistos el malsamaj segmentoj.
Ekzemple
- datumcentro
- interreto
- WAN
- fora aliro
- oficejo LAN
- DMZ
- ...
Estas saĝe havi plurajn diagramojn, kiuj donas kaj la grandan bildon (kiel trafiko fluas inter ĉiuj ĉi tiuj segmentoj) kaj detalan klarigon de ĉiu individua segmento.
Ĉar en modernaj retoj povas ekzisti multaj logikaj tavoloj, estas eble bona (sed ne necesa) aliro fari malsamajn cirkvitojn por malsamaj tavoloj, ekzemple, en la kazo de superkovra aliro tio povus esti la sekvaj cirkvitoj:
- tegu
- L1/L2 submetaĵo
- L3 subtavolo
Kompreneble, la plej grava diagramo, sen kiu estas neeble kompreni la ideon de via dezajno, estas la vojdiagramo.
Voja skemo
Minimume, ĉi tiu diagramo devus reflekti
- kiaj vojprotokoloj estas uzataj kaj kie
- bazaj informoj pri vojaj protokolaj agordoj (areo/AS-numero/router-id/...)
- sur kiuj aparatoj okazas redistribuo?
- kie okazas filtrado kaj itineragregado
- defaŭltaj itineroj
Ankaŭ, la L2-skemo (OSI) ofte estas utila.
L2-skemo (OSI)
Ĉi tiu diagramo povas montri la sekvajn informojn:
- kiaj VLANoj
- kiuj havenoj estas trunkaj havenoj
- kiuj havenoj estas agregitaj en ether-channel (havenkanalo), virtuala havenkanalo
- kiaj STP-protokoloj estas uzataj kaj sur kiuj aparatoj
- bazaj STP-agordoj: radika/radika sekurkopio, STP-kosto, havenprioritato
- kromaj STP-agordoj: BPDU-gardisto/filtrilo, radika gardisto...
Tipaj eraroj de dezajno
Ekzemplo de malbona aliro al konstruado de reto.
Ni prenu simplan ekzemplon pri konstruado de simpla oficeja LAN.
Havante sperton pri instruado de telekomunikado al studentoj, mi povas diri, ke preskaŭ ĉiu studento meze de la dua semestro havas la necesajn sciojn (kadre de la kurso, kiun mi instruis) por starigi simplan oficejan LAN.
Kio estas tiel malfacila pri konekto de ŝaltiloj unu al la alia, agordo de VLANoj, SVI-interfacoj (kaze de L3-ŝaltiloj) kaj agordo de statika enrutigo?
Ĉio funkcios.
Sed samtempe demandoj rilataj al
- sekureco
- rezervado
- retskalo
- produktiveco
- trairo
- fidindeco
- ...
De tempo al tempo mi aŭdas la deklaron, ke oficeja LAN estas io tre simpla kaj mi kutime aŭdas tion de inĝenieroj (kaj administrantoj) kiuj faras ĉion krom retoj, kaj ili diras tion tiel memfide ke ne miru ĉu la LAN estos. farita de homoj kun nesufiĉa praktiko kaj scio kaj estos farita kun proksimume la samaj eraroj kiujn mi priskribos ĉi-sube.
Oftaj L1 (OSI) Dezajnaj Eraroj
- Se, tamen, vi ankaŭ respondecas pri SCS, tiam unu el la plej malagrablaj heredaĵoj, kiujn vi povas ricevi, estas senzorga kaj nepripensita ŝanĝado.
Mi ankaŭ klasifikus kiel tipo L1 erarojn rilatajn al la rimedoj de la ekipaĵo uzata, ekzemple,
- nesufiĉa bendolarĝo
- nesufiĉa TCAM sur ekipaĵo (aŭ neefika uzo de ĝi)
- nesufiĉa rendimento (ofte rilata al fajromuroj)
Oftaj L2 (OSI) Dezajnaj Eraroj
Ofte, kiam ne ekzistas bona kompreno pri kiel STP funkcias kaj kiajn eblajn problemojn ĝi kunportas, ŝaltiloj estas konektitaj kaose, kun defaŭltaj agordoj, sen plia agordo de STP.
Kiel rezulto, ni ofte havas la jenon
- granda STP retdiametro, kiu povas konduki al elsendaj ŝtormoj
- STP-radiko estos determinita hazarde (surbaze de Mac-adreso) kaj la trafikvojo estos suboptimuma
- havenoj konektitaj al gastigantoj ne estos agorditaj kiel rando (portfast), kio kondukos al STP-rekalkulado kiam oni enŝaltos/malŝaltos finstaciojn.
- la reto ne estos segmentita ĉe la L1/L2-nivelo, kiel rezulto de kiuj problemoj kun iu ajn ŝaltilo (ekzemple, potenca troŝarĝo) kondukos al rekalkulo de la STP-topologio kaj ĉesigo de trafiko en ĉiuj VLANoj sur ĉiuj ŝaltiloj (inkluzive de la unu kritika de la perspektivo de kontinua servosegmento)
Ekzemploj de eraroj en L3 (OSI) dezajno
Kelkaj tipaj eraroj de novulaj retoj:
- Ofta uzo (aŭ uzo nur) de senmova vojigo
- uzo de suboptimumaj vojprotokoloj por antaŭfiksita dezajno
- suboptimuma logika retsegmentado
- suboptimuma uzo de adrespaco, kiu ne permesas itiner-agregadon
- neniuj rezervaj vojoj
- neniu rezervado por defaŭlta enirejo
- nesimetria vojigo dum rekonstruado de itineroj (povas esti kritika en la kazo de NAT/PAT, ŝtatplenaj fajroŝirmiloj)
- problemoj kun MTU
- kiam itineroj estas rekonstruitaj, trafiko iras tra aliaj sekurecaj zonoj aŭ eĉ aliaj fajromuroj, kio kondukas al ĉi tiu trafiko faligita.
- malbona topologia skaleblo
Kriterioj por taksi dezajnokvaliton
Kiam ni parolas pri optimumo/ne-optimumeco, ni devas kompreni el la vidpunkto de kiaj kriterioj ni povas taksi tion. Jen, laŭ mia vidpunkto, la plej signifaj (sed ne ĉiuj) kriterioj (kaj klarigo rilate al enrutaj protokoloj):
- skaleblo
Ekzemple, vi decidas aldoni alian datumcentron. Kiel facile vi povas fari ĝin? - facileco de uzo (regebleco)
Kiom facilaj kaj sekuraj estas funkciaj ŝanĝoj, kiel anonci novan kradon aŭ filtri itinerojn? - havebleco
Kia procento de la tempo via sistemo provizas la bezonatan nivelon de servo? - sekureco
Kiom sekuraj estas la transdonitaj datumoj? - la prezo
Ŝanĝoj
La baza principo en ĉi tiu etapo povas esti esprimita per la formulo "ne malbonu."
Tial, eĉ se vi ne tute konsentas kun la dezajno kaj la elektita efektivigo (agordo), ne ĉiam estas konsilinde fari ŝanĝojn. Akceptebla aliro estas vicigi ĉiujn identigitajn problemojn laŭ du parametroj:
- kiom facile ĉi tiu problemo povas esti riparita
- kiom da risko ŝi portas?
Antaŭ ĉio, necesas forigi tion, kio nuntempe reduktas la nivelon de servo provizita sub la akceptebla nivelo, ekzemple, problemoj kondukantaj al paka perdo. Poste riparu tion, kio estas plej facila kaj sekura ripari en malkreskanta ordo de riska severeco (de altriskaj problemoj pri dezajno aŭ agordo ĝis malaltriskaj).
Perfektismo en ĉi tiu etapo povas esti malutila. Alportu la dezajnon al kontentiga stato kaj sinkronigu la retan agordon laŭe.
fonto: www.habr.com