Tämä artikkeli on toinen artikkelisarjassa "Kuinka ottaa verkkoinfrastruktuurisi hallintaan". Sarjan kaikkien artikkeleiden sisältö ja linkit löytyvät .
Tavoitteemme tässä vaiheessa on saada järjestystä dokumentaatioon ja konfigurointiin.
Tämän prosessin lopussa sinulla pitäisi olla tarvittavat asiakirjat ja verkko määritettynä niiden mukaisesti.
Nyt emme puhu turvatarkastuksista - tämä on kolmannen osan aihe.
Tässä vaiheessa määrätyn tehtävän suorittamisen vaikeus vaihtelee tietysti suuresti yhtiöittäin.
Ihanteellinen tilanne on kun
- verkostosi on luotu projektin mukaisesti ja sinulla on täydellinen asiakirjasarja
- on otettu käyttöön yrityksessäsi verkkoa varten
- tämän prosessin mukaisesti sinulla on asiakirjoja (mukaan lukien kaikki tarvittavat kaaviot), jotka tarjoavat täydelliset tiedot nykyisestä tilanteesta
Tässä tapauksessa tehtäväsi on melko yksinkertainen. Sinun tulee tutkia asiakirjoja ja tarkistaa kaikki tehdyt muutokset.
Pahimmassa tapauksessa sinulla on
- verkosto, joka on luotu ilman projektia, ilman suunnitelmaa, ilman hyväksyntää, sellaisten insinöörien toimesta, joilla ei ole riittävää pätevyyttä,
- kaoottisilla, dokumentoimattomilla muutoksilla, paljon "roskaa" ja alioptimaalisia ratkaisuja
On selvää, että tilanteesi on jossain välissä, mutta valitettavasti tällä asteikolla parempi - pahempi on suuri todennäköisyys, että olet lähempänä pahinta loppua.
Tässä tapauksessa tarvitset myös kykyä lukea ajatuksia, koska sinun on opittava ymmärtämään, mitä "suunnittelijat" halusivat tehdä, palauttaa heidän logiikkansa, viimeistellä se, mikä ei ollut valmis, ja poistaa "roskat".
Ja tietysti sinun on korjattava heidän virheet, muutettava (tässä vaiheessa mahdollisimman vähän) suunnittelua ja muutettava tai luotava uudelleen järjestelmiä.
Tämä artikkeli ei millään tavalla väitä olevansa täydellinen. Tässä kuvailen vain yleiset periaatteet ja keskityn joihinkin yleisiin ongelmiin, jotka on ratkaistava.
Joukko asiakirjoja
Aloitetaan esimerkillä.
Alla on joitain asiakirjoja, jotka yleensä luodaan Cisco Systemsissä suunnittelun aikana.
CR – Asiakasvaatimukset, asiakkaan vaatimukset (tekniset tiedot).
Se luodaan yhdessä asiakkaan kanssa ja määrittää verkkovaatimukset.HLD – Korkean tason suunnittelu, korkean tason suunnittelu, joka perustuu verkkovaatimuksiin (CR). Dokumentti selittää ja perustelee tehdyt arkkitehtoniset päätökset (topologia, protokollat, laitteiston valinta jne.). HLD ei sisällä suunnittelun yksityiskohtia, kuten käytettyjä rajapintoja ja IP-osoitteita. Myöskään erityistä laitteistokokoonpanoa ei käsitellä tässä. Tämän asiakirjan tarkoituksena on pikemminkin selittää keskeiset suunnittelukonseptit asiakkaan tekniselle johdolle.
LLD – Low Level Design, matalan tason suunnittelu, joka perustuu korkean tason suunnitteluun (HLD).
Sen tulee sisältää kaikki projektin toteuttamiseen tarvittavat tiedot, kuten tiedot laitteiden kytkemisestä ja konfiguroinnista. Tämä on täydellinen opas suunnittelun toteuttamiseen. Tämän asiakirjan tulee antaa riittävästi tietoa sen täytäntöönpanoa varten myös vähemmän koulutettujen henkilöiden toimesta.Jotain, esimerkiksi IP-osoitteita, AS-numeroita, fyysistä kytkentäkaaviota (kaapelointi), voidaan "ulkea" erillisiin asiakirjoihin, kuten esim. NIP (Verkon toteutussuunnitelma).
Verkon rakentaminen alkaa näiden asiakirjojen luomisen jälkeen ja tapahtuu tiukasti niiden mukaisesti, minkä jälkeen asiakas tarkastaa sen (testit) suunnitelman mukaisuuden.
Tietysti eri integraattoreilla, eri asiakkailla ja eri maissa voi olla erilaiset vaatimukset projektidokumentaatiolle. Haluaisin kuitenkin välttää muodollisuuksia ja tarkastella asiaa perusteellisesti. Tässä vaiheessa ei ole kyse suunnittelusta, vaan asioiden laittamisesta järjestykseen, ja tarvitsemme riittävän määrän asiakirjoja (kaavioita, taulukoita, kuvauksia...) tehtäviemme suorittamiseen.
Ja mielestäni on olemassa tietty ehdoton minimi, jota ilman verkkoa on mahdotonta hallita tehokkaasti.
Nämä ovat seuraavat asiakirjat:
- fyysisen kytkennän (kaapeloinnin) kaavio (loki)
- verkkokaavio tai kaaviot, joissa on olennaisia L2/L3-tietoja
Fyysinen kytkentäkaavio
Joissakin pienissä yrityksissä laiteasennuksiin ja fyysiseen kytkentään (kaapelointiin) liittyvät työt ovat verkkoinsinöörien vastuulla.
Tässä tapauksessa ongelma ratkaistaan osittain seuraavalla lähestymistavalla.
- käytä käyttöliittymässä olevaa kuvausta kuvaamaan, mitä siihen on liitetty
- sammuta hallinnollisesti kaikki yhdistämättömät verkkolaitteiden portit
Tämä antaa sinulle mahdollisuuden jopa linkin ongelman sattuessa (kun cdp tai lldp ei toimi tässä käyttöliittymässä) määrittää nopeasti, mikä tähän porttiin on kytketty.
Näet myös helposti mitkä portit ovat varattuja ja mitkä ovat vapaita, mikä on välttämätöntä uusien verkkolaitteiden, palvelimien tai työasemien yhteyksien suunnittelussa.
Mutta on selvää, että jos menetät pääsyn laitteisiin, menetät myös pääsyn näihin tietoihin. Lisäksi tällä tavalla et voi tallentaa sellaisia tärkeitä tietoja, kuten millaisia laitteita, mitä virrankulutusta, kuinka monta porttia, missä telineessä se on, mitä patch-paneeleita siellä on ja missä (missä telineessä/patch-paneelissa ) ne ovat yhteydessä toisiinsa. Siksi lisädokumentaatio (ei vain laitteiden kuvaukset) on edelleen erittäin hyödyllinen.
Ihanteellinen vaihtoehto on käyttää sovelluksia, jotka on suunniteltu toimimaan tämäntyyppisten tietojen kanssa. Voit kuitenkin rajoittua yksinkertaisiin taulukoihin (esimerkiksi Excelissä) tai näyttää tarpeellisiksi katsomasi tiedot L1/L2-kaavioissa.
Tärkeää!
Verkkoinsinööri voi tietysti tuntea varsin hyvin SCS:n hienoudet ja standardit, telinetyypit, keskeytymättömien virtalähteiden tyypit, mikä on kylmä ja kuuma käytävä, miten maadoitus tehdään kunnolla... aivan kuten periaatteessa hän osaa. tuntea alkuainehiukkasten tai C++:n fysiikan. Mutta täytyy silti ymmärtää, että tämä kaikki ei ole hänen osaamisaluettaan.
Siksi on hyvä käytäntö, että asennukseen, kytkentöihin, laitteiden huoltoon ja fyysiseen vaihtoon liittyvien ongelmien ratkaisemiseen on joko omat osastoja tai henkilöitä. Yleensä palvelinkeskuksissa tämä on datakeskusinsinööri, ja toimistolle se on help-desk.
Jos yritykselläsi on tällaiset jaot, niin fyysisen kytkennän kirjaaminen ei ole sinun tehtäväsi, vaan voit rajoittua vain käyttöliittymän kuvaukseen ja käyttämättömien porttien hallinnolliseen sulkemiseen.
Verkkokaaviot
Kaavioiden piirtämiseen ei ole universaalia lähestymistapaa.
Tärkeintä on, että kaavioiden tulee antaa käsitys siitä, kuinka liikenne kulkee, minkä loogisten ja fyysisten osien kautta verkkosi kautta.
Fyysisillä elementeillä tarkoitamme
- aktiiviset laitteet
- aktiivisten laitteiden liitännät/portit
Loogisesti -
- loogiset laitteet (N7K VDC, Palo Alto VSYS, ...)
- VRF laajennus
- Vilans
- alirajapinnat
- tunnelit
- vyöhyke
- ...
Lisäksi, jos verkkosi ei ole täysin alkeellista, se koostuu eri segmenteistä.
Esimerkiksi
- datakeskus
- Internet
- WAN
- etäyhteys
- toimiston LAN
- DMZ
- ...
On viisasta käyttää useita kaavioita, jotka antavat sekä yleiskuvan (miten liikenne kulkee kaikkien näiden segmenttien välillä) että yksityiskohtaisen selityksen jokaisesta yksittäisestä segmentistä.
Koska nykyaikaisissa verkoissa voi olla monia loogisia kerroksia, on ehkä hyvä (mutta ei välttämätön) tapa tehdä erilaisia piirejä eri kerroksille, esimerkiksi overlay-lähestymistavan tapauksessa nämä voivat olla seuraavat piirit:
- päällys
- L1/L2 aluskate
- L3 aluskate
Tietenkin tärkein kaavio, jota ilman suunnittelusi ideaa on mahdotonta ymmärtää, on reitityskaavio.
Reitityskaavio
Tämän kaavion pitäisi ainakin heijastua
- mitä reititysprotokollia käytetään ja missä
- perustiedot reititysprotokollan asetuksista (alue/AS-numero/reitittimen tunnus/…)
- millä laitteilla uudelleenjako tapahtuu?
- jossa suodatus ja reittien yhdistäminen tapahtuu
- oletusreitin tiedot
Myös L2-skeema (OSI) on usein hyödyllinen.
L2-malli (OSI)
Tämä kaavio voi näyttää seuraavat tiedot:
- mitkä VLANit
- mitkä portit ovat runkoportteja
- mitkä portit on koottu eetterikanavaksi (porttikanavaksi), virtuaaliseksi porttikanavaksi
- mitä STP-protokollia käytetään ja millä laitteilla
- STP:n perusasetukset: root/root varmuuskopio, STP-hinta, portin prioriteetti
- STP-lisäasetukset: BPDU-suoja/suodatin, juurisuoja…
Tyypillisiä suunnitteluvirheitä
Esimerkki huonosta lähestymistavasta verkoston rakentamiseen.
Otetaan yksinkertainen esimerkki yksinkertaisen toimiston lähiverkon rakentamisesta.
Koska minulla on kokemusta tietoliikenteen opettamisesta opiskelijoille, voin sanoa, että käytännössä jokaisella opiskelijalla on toisen lukukauden puoliväliin mennessä tarvittavat tiedot (osana opettamaani kurssia) perustaakseen yksinkertaisen toimiston lähiverkon.
Mikä on niin vaikeaa kytkimien yhdistämisessä toisiinsa, VLAN-verkkojen, SVI-liitäntöjen (L3-kytkimien tapauksessa) ja staattisen reitityksen asettamisessa?
Kaikki toimii.
Mutta samaan aikaan liittyviä kysymyksiä
- turvallisuus
- varaus
- verkon skaalaus
- tuottavuutta
- läpijuoksu
- luotettavuus
- ...
Ajoittain kuulen väitteen, että toimisto-LAN on jotain hyvin yksinkertaista, ja kuulen tämän yleensä insinööreiltä (ja esimiehiltä), jotka tekevät kaikkea muuta kuin verkkoja, ja he sanovat tämän niin itsevarmasti, että älkää ihmetelkö, jos lähiverkko tulee olemaan jotka ovat tehneet ihmiset, joilla on riittämätön käytäntö ja tieto, ja ne tehdään suunnilleen samoilla virheillä, joita kuvailen alla.
Yleisiä L1 (OSI) -suunnitteluvirheitä
- Jos kuitenkin olet vastuussa myös SCS:stä, yksi epämiellyttävimmistä perinnöistä, joita saatat saada, on huolimaton ja harkitsematon vaihtaminen.
Luokittaisin myös tyyppi L1 virheet, jotka liittyvät käytettyjen laitteiden resursseihin, esim.
- riittämätön kaistanleveys
- riittämätön TCAM laitteistossa (tai sen tehoton käyttö)
- riittämätön suorituskyky (liittyy usein palomuuriin)
Yleisiä L2 (OSI) -suunnitteluvirheitä
Usein, kun ei tiedetä kunnolla STP:n toiminnasta ja mahdollisista ongelmista, joita se tuo mukanaan, kytkimet kytketään kaoottisesti oletusasetuksilla ilman ylimääräistä STP-viritystä.
Tämän seurauksena meillä on usein seuraavat asiat
- suuri STP-verkon halkaisija, mikä voi johtaa lähetysmyrskyihin
- STP-juuri määritetään satunnaisesti (mac-osoitteen perusteella) ja liikennepolku ei ole optimaalinen
- isäntiin kytkettyjä portteja ei konfiguroida reunaksi (portfast), mikä johtaa STP-uudelleenlaskentaan, kun pääteasemia kytketään päälle/pois
- verkkoa ei segmentoida L1/L2-tasolla, minkä seurauksena minkä tahansa kytkimen ongelmat (esimerkiksi virran ylikuormitus) johtavat STP-topologian uudelleenlaskentaan ja liikenteen pysäyttämiseen kaikissa VLAN-verkoissa kaikissa kytkimissä (mukaan lukien yksi kriittinen jatkuvuuspalvelusegmentin kannalta)
Esimerkkejä virheistä L3 (OSI) suunnittelussa
Muutamia tyypillisiä aloittelevien verkkokäyttäjien virheitä:
- Staattisen reitityksen toistuva käyttö (tai vain käyttö).
- epäoptimaalisten reititysprotokollien käyttö tietylle mallille
- alioptimaalinen looginen verkon segmentointi
- osoiteavaruuden epäoptimaalinen käyttö, mikä ei salli reittien yhdistämistä
- ei varareittejä
- ei varausta oletusyhdyskäytävälle
- epäsymmetrinen reititys reittejä rakennettaessa uudelleen (voi olla kriittistä NAT/PAT:n, tilan täyttävien palomuurien tapauksessa)
- ongelmia MTU:n kanssa
- kun reittejä rakennetaan uudelleen, liikenne kulkee muiden turvavyöhykkeiden tai jopa muiden palomuurien läpi, mikä johtaa tämän liikenteen katkeamiseen
- huono topologian skaalautuvuus
Suunnittelun laadun arviointikriteerit
Kun puhumme optimaalisuudesta/ei-optimaalisuudesta, meidän on ymmärrettävä, millä kriteereillä voimme arvioida tätä. Tässä on minun näkökulmastani tärkeimmät (mutta eivät kaikki) kriteerit (ja selitys reititysprotokollien suhteen):
- skaalautuvuus
Päätät esimerkiksi lisätä toisen palvelinkeskuksen. Kuinka helposti voit tehdä sen? - helppokäyttöisyys (hallittavuus)
Kuinka helppoja ja turvallisia ovat toiminnalliset muutokset, kuten uuden ruudukon ilmoittaminen tai reittien suodatus? - saatavuus
Kuinka monta prosenttia ajasta järjestelmäsi tarjoaa vaaditun palvelun? - turvallisuus
Kuinka turvallisia siirretyt tiedot ovat? - hinta
muutokset
Perusperiaate tässä vaiheessa voidaan ilmaista kaavalla "älä vahingoita".
Siksi, vaikka et olisi täysin samaa mieltä suunnittelusta ja valitusta toteutuksesta (konfiguraatiosta), ei aina ole suositeltavaa tehdä muutoksia. Järkevä lähestymistapa on luokitella kaikki tunnistetut ongelmat kahden parametrin mukaan:
- kuinka helposti tämä ongelma voidaan korjata
- kuinka paljon riskiä hän kantaa?
Ensinnäkin on tarpeen poistaa se, mikä tällä hetkellä laskee tarjotun palvelun tasoa alle hyväksyttävän tason, esimerkiksi pakettien katoamiseen johtavat ongelmat. Korjaa sitten helpoin ja turvallisin korjattava riskin vakavuuden alenevassa järjestyksessä (suuren riskin suunnittelu- tai konfigurointiongelmista vähäriskisiin).
Perfektionismi tässä vaiheessa voi olla haitallista. Tuo suunnittelu tyydyttävään tilaan ja synkronoi verkkokokoonpano sen mukaisesti.
Lähde: will.com