Den ultimate guiden til nettverksdesign

Når du har et nettverk på plass, er hovedoppgaven din som nettverksansvarlig å opprettholde kapasiteten. Dette er først og fremst et spørsmål om å legge til mer maskinvare for å imøtekomme større etterspørsel etter båndbredde og flere sluttpunkter for ansatte. Du kan imidlertid bare oppnå denne utvidelsen på en ryddig måte hvis du har et designramme på plass.

Når du oppretter et nytt nettverk, har du fordelen av et rent ark, som gir deg muligheten til å designe en tjeneste som enkelt kan utvides. Så hvis du overtar et dårlig planlagt nettverk, kan det være en god ide å designe systemet fra bunnen av og deretter flytt de eksisterende ressursene for å passe inn i den planlagte utformingen.

I denne guiden vil du lese om et system for å lage et design, som vil gi deg utformingen av et nytt nettverk. Det kan også brukes på eksisterende nettverk for å gi dem bedre ytelse. Opplegget i denne guiden følger systemet som er anbefalt i kurset for Cisco Certified Network Associate-eksamen (CCNA). Så selv om det ikke er sannsynlig at du blir gitt ansvaret for å lage et nettverksdesign akkurat nå, bør tipsene i denne guiden i det minste hjelpe deg å bestå dine CCNA-eksamener.

Les videre for den ultimate guiden til nettverksdesign!

Designmetodikk

Til syvende og sist eksisterer nettverk utelukkende for å betjene en organisasjons behov. Naturligvis har hver virksomhet, veldedighet eller forening unike krav fra sitt nettverk å vurdere. For eksempel maskinvaren og driftsapplikasjonene du trenger for å opprette et nettverk for en online virksomheten er forskjellig fra utstyret du trenger for forretningsstøtte til en murstein og mørtel virksomhet.

Når du vurderer nettverksdesign, trenger du ikke å bekymre deg helt fra begynnelsen av oppgaven med å utarbeide en maskinvarekravliste. Det vil komme senere. Akkurat nå fokuserer vi på utformingen av nettverket, og ikke implementeringen av det designet. Når vi zoomer ut til et ytterligere abstraksjonsnivå, i begynnelsen av en designøvelse, er vi ikke engang opptatt av nettverksoppsettet eller til og med dets formål. Først bør du fokusere på metodikken du vil følge for å utforme nettverket.

Arbeide for å lage et rammeverk som definerer et nettverk, og som vil imøtekomme organisasjonen når som helst i fremtiden, ikke bare dens umiddelbare behov. CCNA retningslinjene anbefaler å ta en top-down tilnærming.

Top-down tilnærming

Å få oppgaven med å lage et nettverk fra bunnen av, kan være en skremmende opplevelse. Spørsmålet er hvor starter du? Overst nede svaret på det spørsmålet er å lage et hierarki av mål, og deretter liste opp oppgavene som må oppnås for å oppnå hvert mål. Når den planen er på plass, vil du gå inn i kritisk baneanalyse for å bestille oppgaver slik at du kan nå målet på kortest mulig tid.

Når du vet hvilke oppgaver som må startes først og hvilke oppgaver som kan utføres parallelt, vil du kunne planlegge ressurskrav. Disse vil gi deg muligheten til å få de rette ekspertene på stedet til rett tid, og få dem til å jobbe så raskt som mulig for å redusere kostnadene. Du vil også kunne skrive opp et inventarbehov, slik at du vet når du trenger å ha utstyr tilgjengelig.

I ovenfra og ned-tilnærmingen skjer hensyn til innkjøp av maskinvare som den siste oppgaven på listen.

Alternative tilnærminger

The bottom-up tilnærming er arbeidsmetoden som du sannsynligvis er vant til. Dette er spesielt tilfelle hvis du utvider et eksisterende nettverk. I dette scenariet er designens utgangspunkt en liste over utstyr. Forutsetningen her er "hva har vi nå, og hvilket utstyr vil vi trenge for å levere et utvidet nettverk?"

Problemet med en bottom-up-tilnærming til nettverksdesign er at den bare fokuserer på det umiddelbare behovet for å oppfylle et spesifikt forretningsbehov. Det setter ikke målet inn i sammenhengen med det bredere nettverket og mulig fremtidig utvidelse; du undersøker bare ett område av nettverket som må forbedres. Denne endringen kan påvirke andre tjenester og sette belastning på kapasiteten til andre områder i nettverkets infrastruktur.

Agile-utviklingsmodellen ser ut til å være en bottom-up-metodikk. Med Agile-utvikling får du en grov ide om hvordan du oppfyller et krav, legger den løsningen inn plassere, og juster deretter resultatene når bruksdata kommer inn og gir deg kapasitet i virkeligheten krav. Smidig utvikling er ikke avhengig av gjetting. Faktisk kan Agile-metodikken bare oppnås innenfor et rammeverk, og det er den ovenfra og ned-planen som vil gi nettverksdesignen strukturen som vil tillate rask installasjon og rekursive justeringer.

Målkategorier

Det er tre grunnleggende trinn i utformingen av et nettverk:

1. Identifiser nettverkskrav
2. Dokumenter det eksisterende nettverket
3. Design nettverkstopologien og løsningene

I utgangspunktet må du vite hvordan nettverket ditt skal ende, hva du har fått nå, og hvordan du kommer til å komme deg fra det ene til det andre.

Det kan virke rart å jobbe med å identifisere krav først i stedet for dokumentasjon av det eksisterende nettverket. Du tenker kanskje at det er mer logisk å begynne med det du har, og så se på hva kravet ber. Denne sekvensen av trinn er imidlertid bare skrevet innenfor konteksten av utvidelsesprosjektet. Du bør allerede ha en god plan for nettverket ditt, og en oversikt over utstyret du bruker til daglig feilsøking. Eksistensen av denne informasjonen vil gjøre trinn 2 mye enklere.

Tabula Rasa

Når du jobber med et nettverksdesign, er det en distraksjon å tenke på hva du allerede har. Hvis du tenker på disse vilkårene, vil du ende opp med å tilby en løsning som ligner mye på det eksisterende systemet ditt. Og det er kanskje ikke den beste løsningen. Det er bedre å starte designet uten forutsetninger, ellers vil du aldri få et nettverk som er betydelig bedre enn det du allerede har.

Identifiser nettverkskrav

Utgangspunktet for ethvert prosjekt er et forretningskrav, som vil bli oppgitt av en ikke-teknisk sjef i organisasjonen. Du vil sannsynligvis samarbeide med en prosjektprosjektleder i utviklingen av nettverket.

Brukerkrav

Du må få spesifikasjonen for det prosjekterte som skal skrives i form av et mål. Dette målet må vises på listen:

• Krav til kapasitet: for eksempel gi tilgang til X antall ansatte, eller betjene Y-kunder per dag
• Hensikt: f.eks. programvare for å kjøre over nettverket, poster som skal lagres
• Ytelseskrav: f.eks. "akseptable responstider"
• Plasseringskrav: for eksempel alt på ett kontor eller gir tilgang til eksterne arbeidere
• Tidsbegrensninger: f.eks. innen utgangen av neste måned
• Budsjettbegrensninger: f.eks. det maksimale som kan brukes til å tilby den nødvendige tjenesten

Teknisk krav

De bredt angitte brukerkravene kan oversettes til termer som er meningsfulle for teknisk personell, som viderefører måluttalelsene til spesifikke kapasitetsproblemer. Dette trinnet krever også ytterligere undersøkelser i formålet med brukerkravet. Fra dette skal du kunne liste:

• Ny programvare som skal brukes
• Lagringsløsninger
• Slutt-enhetstyper: f.eks. Stasjonære maskiner, BYOD, WiFi, mobile enheter, skrivere osv
• antall brukere
• Krav til båndbredde

Du bør også kunne finne ut om de nye kravene vil påvirke hele nettverket, eller bare ett geografisk område. For eksempel vil en ny forretningsskikk, for eksempel å introdusere en ERP, sannsynligvis legge til trafikk til alle koblinger på et kontornettverk. Tillegg av nye medarbeidere i HR-avdelingen vil bare legge til trafikk til nettverket (som ligger mellom enhetene nye medarbeidere bruker for å få tilgang til nettverket), så vel som serverne og utstyret som personalet vil trenge tilgang til.

Målavtale

Så du har dokumentert brukerkrav og en grov oversikt over IT-tjenestene som skal oppnå disse målene. Deretter skriver du prosjektmålene inn i et dokument og får brukerstyreren til å registrere det før du fortsetter videre.

Lagre nye krav til fremtidige prosjekter

Når du har en målavtale, har du etablert parameterne for prosjektet, og du kan unngå at ekstra krav blir lagt til. Nye krav vil naturlig nok oppstå etter hvert som prosjektet skrider frem. Disse skal imidlertid noteres og settes som mål å bli vurdert for et oppfølgingsprosjekt, og ikke få lov til å utsette eller avlede arbeidsinnsatsen for det nåværende prosjektet.

Opprettelse eller utvidelse av et nettverk er uunngåelig knyttet til programvare- og databehandlingsbehovene i organisasjonen. Hensynet til programvarekjøp og serverkapasitet bør imidlertid deles ut som separate mål.

Fjern vage språk fra dine mål

I denne veiledningen fokuserer vi bare på planleggingen for nettverksdesign. Målavtalen bør derfor skrives etter brukersjefen har allerede vurdert programvarealternativer og dannet et klart bemanningsbehov for virksomheten.

Skriv presise figurer inn i målet der det er mulig, da vaghet over resultatmål er uunngåelig når du kommuniserer med ikke-teknisk personale. Imidlertid bør antallet brukere som forventes å bli lagt til nettverket, antall og type sluttpunkter, og antall besøkende som forventes til et nettsted, være tydelig angitt.

Hvis du ikke skjerper målavtalen din, bruker brukeren manager vage mål som en bakdør for å utvide prosjektet. Og da må du svare på spørsmål om hvorfor du ikke klarte å følge det avtalte budsjett- og leveringsplanen.

Dokumenter det eksisterende nettverket

Forhåpentligvis har du effektiv nettverksadministrasjonsprogramvare allerede på plass. Dette verktøyet vil kunne gi deg en statusrapport om den nåværende ytelsen til nettverket. Hvis du oppretter et nytt nettverk, er den eksisterende ytelsen til nettverket ikke aktuelt - du må bare hoppe over dette trinnet.

Ta lager av utstyr på stedet

Ettersom du skal kunne samle kapasiteten til alle enheter og kabler i nettverket ut av nettverksmonitoren, er det ikke bortkastet tid å inkludere en undersøkelse av alt utstyret i nettverket. Imidlertid bør de geografiske kravene i målavtalen gjøre det mulig for deg å begrense omfanget av planleggingsøvelsen. Hvis du for eksempel kjører et WAN, legger du til ti nye sluttpunkter til ett nettsted. Konsekvensanalysen din kan rimeligvis begrenses til nettverksutstyr og kabel på stedet der utvidelsen skal finne sted. Hvis disse sluttpunktene vil bli brukt til å kommunisere med en ekstern server, er internettkoblingen til den serveren også relevant for prosjektet.

Kartlegg nettverkstopologi

Ta en kopi av din eksisterende nettverkstopologi, enten digitalt eller fysisk, og merk et omriss rundt den delen av nettverket som vil bli berørt av endringen. Lag en liste over enheter og koblinger i det begrensede området. Merk for hvert element i nettverket:

• Enhetens båndbreddekapasitet
• Gjennomsnittlig gjeldende båndbreddebehov
• Topp gjeldende båndbreddebehov

Merk for disse ekstra faktorene for hver bryter på nettverket ditt:

• Nåværende antall inntatte havner
• Gjeldende tilkoblinger til nærliggende enheter
• Nåværende tilkoblinger til sluttpunkter
• Antall tilgjengelige porter

Merk på nettverkskartet stedet for nytt utstyr, for eksempel de nødvendige stasjonære datamaskinene, og test deretter ruter mellom nærmeste bytte til den sannsynlige destinasjonen for den nye trafikken som prosjektet vil generere. For hver identifiserte rute tegner du banen og viser kabel- og nettverksenhetene i rekkefølge. Noter det laveste kapasitetselementet i hver rute, og registrer deretter gjennomsnittlig og topp etterspørsel på den ruten, både link-for-link og ende til ende.

Designlag

Når du er i designfasen av prosjektet ditt, må du undersøke de nye kravene og om ditt eksisterende utstyr og layout vil bidra til å levere målet. CCNA-kurset deler opp nettverksdesign i tre lag:

• Kjerne
• Fordeling
• Adgang

Hvert av disse lagene krever forskjellige designhensyn:

Hensyn til kjernelagdesign

Kjernelaget er nettverkets ryggrad. Når du planlegger dette aspektet av nettverket ditt, undersøker du det fysiske utstyret du trenger. Husk å angi omfanget av kjernelagsvurderingen til den delen av nettverket som vil bli påvirket av prosjektet. Du vil fokusere på kravene til:

• Rutere og brytere
• Lastbalansering
• Ruteoppsigelse
• Krav til høyhastighetskobling
• Optimale rutingsprotokoller

Ute på internett må hver ruter implementere Border Gateway-protokollen. Imidlertid har du mange flere alternativer innenfor rammen av ditt private nettverk, og du kan velge hvilken ruteprotokoll som passer best til nettverksformålet.

Kravet om lastbalansering og rutinghensyn er avhengig av hverandre. For eksempel begrenser Spanning Tree Protocol rutingsalternativene til bare en bane og lar deg ikke dele trafikk. Prøv å bygge i ruteoppsigelse for å gi dekning for svikt i hovedstien.

Vurder å implementere:

• Forbedret interiør Gateway Routing Protocol
• Åpne korteste vei første protokoll

Krav til maskinvare

Undersøk maskinvarekravene for den valgte protokollen. For eksempel kan det hende du må bruke rutere i nettverket der du vanligvis kan installere brytere. Prioriter utstyr som har sviktende funksjoner, for eksempel ekstra styringsmoduler, doble støttekomponenter (strømforsyninger og vifter), og et chassisbasert design som gjør det enklere å samarbeide duplisert utstyr.

Nettverkstopologi

Den neste saken du bør vurdere er nettverkstopologien, bør du vurdere muligheter for full mesh og delvis netting? Topologien du velger vil være avhengig av størrelsen på nettverket, antall overflødige koblinger du bygger inn og valget ditt for rutingprotokoll.

Hensyn til distribusjonslagdesign

Distribusjonssjiktet undersøker grensene mellom systemene. Dette inkluderer samspillet mellom nettverket ditt og omverdenen, eller mellom det området av nettverket som er under vurdering og resten av nettverket. Grenseforholdene dekket ved distribusjonssjiktet inkluderer også samspillet mellom Access-laget og Kjernelaget.

Ettersom dette laget er opptatt av grensene til nettverket ditt, fokuserer det på rutere i stedet for brytere. Du vurderer tilstrømningen og utstrømningen av trafikk som kjernelagsdesignet ditt har å gjøre med. Fokuser på disse faktorene:

• Trafikkfiltrering
• Adgangskontroll
• Ruteoppsummering
• Kjernebeskyttelse
• Inter-VLAN-trafikk

Forme trafikk

I dette laget vil du se på mulige trafikkformingstiltak, for eksempel prioritering og kø i grensen til nettverket.

• Tenk på hvordan fasilitetene i nettverkstopologien kan forbedres ved å rute hensynet til å gi noen noder raskere tilgang til viktige tjenester, for eksempel applikasjonsservere eller lagring. Vurder trunking og lastbalansering med QoS-tagging for å få spesifikke brukere bedre ytelse fra nøkkelapplikasjonene deres.
• Hvis du har en webserver og betjener en gren av nettverket isolert fra kontorsystemet ditt, vil samhandlingen mellom disse sonene være underlagt distribusjonslaget. Vurder å installere utstyrsklynger og lastbalansering ved inngangsporten til eksterne utvendige ressurser. Bruk ressursredundans for kritisk viktige tilgangsstier.
• Vurder tilgangskontrollister (ACL-er) for å filtrere trafikk fra internett eller en DMZ til kjernenettverket ditt.

Anbefalte ruteprotokoller

Cisco anbefaler et par flere rutingsmetoder for distribusjonssjiktet enn det gjør for kjernelaget. Ta i betraktning:

• Forbedret interiør Gateway Routing Protocol
• Åpne korteste vei første protokoll
• Routing Information Protocol versjon 2
• Intermediate System-to-Intermediate System Protocol

Disse protokollene inkluderer alle prosedyrer for ruteoppsummering, som er et viktig nettverksoptimaliseringselement som kreves i distribusjonssjiktet. Du bør spesielt unngå klassiske rutingsmetoder for distribusjonssjiktet. Disse vil spesifisere individuelle ruter for all trafikk, som er ineffektiv når du mater trafikk inn i nettverket og ikke utnytter subnettinginnsatsen mest mulig.

Hensyn til tilgang til lagdesign

Mens distribusjonssjiktet ser på hvordan trafikk strømmer inn fra andre nettverk, er Access-laget opptatt av hvordan brukerens sluttpunkter knytter seg til kjernenettet. På dette siste laget har du allerede planlagt Core-nettverket og distribusjonslagene. Når du arbeider med sluttpunkter, trenger du ikke å være opptatt av hvordan trafikk fra et sluttpunkt vil krysse kjernenettverket, ut gjennom en ruter og over internett til eksterne ressurser. Du trenger bare å undersøke hvordan typen og plasseringen av brukerenheter vil påvirke kjernetrafikkmønsteret.

Ettersom brukerenheter i stor grad overgår alle andre typer utstyr i et kontornettverk, kan denne delen være den viktigste delen av designen. Når det gjelder små, internettbaserte virksomheter, har du imidlertid ikke mye arbeid å gjøre i Access-laget. Etter hvert som skytjenester og telekommunikasjon blir mer utbredt, blir konseptene om sluttpunkter mindre viktige.

Ressurskrevende applikasjoner

I dette laget vil du undersøke utstyret til ledningsskapene dine og deres plassering. De mest kritiske applikasjonene som vil trenge mye oppmerksomhet i Access-laget er interaktive verktøy som kjører over VLAN-er - tale- og videotjenester. Her må du implementere QoS-tagging for å holde VLAN-trafikken forskjellig fra datanettverket. Du må også vurdere å prioritere denne typen trafikk, fordi leveringshastigheten er kritisk viktig for funksjonaliteten deres.

virtualizations

Virtualiseringer er også ansvaret for Access-laget. CCNA-retningslinjene nevner imidlertid denne teknologien bare kort. Hvis du studerer hensyn til nettverksdesign for en faktisk implementering, vil du bruke mye mer tid på å undersøke virtualiseringskravene dine enn deg vil bruke på VLAN-ene dine. Hvis du imidlertid studerer til CCNA-eksamenene, fokuserer du mer på å bli kjent med VLAN-spørsmål fordi de kommer opp i eksamen mer enn virtualizations.

Mobile enheter

Trådløst utstyr bør vurderes i Access-laget, og håndtering av mobile enheter er også en viktig faktor i dette laget. Du må undersøke programvare for styring av mobilenheter og bestemme om du skal oppmuntre brukeren til ansatte-eide enheter, eller levere alle mobile enheter.

Nettverksdesign faktorer

Til syvende og sist må du legge til nettverksadministrasjonsprogramvare når du designer nettverket. Vurder anbefalingene i Vanedannende tips gjennomgang av nettverksadministrasjonsprogramvare som retningslinje.

Følger du en annen metodikk for nettverksdesign? Har du gått gjennom CCNA-eksamenene og deretter implementert trelagsmodellen i en faktisk nettverksdesign? Legg igjen en melding i kommentarfeltet nedenfor, og del dine erfaringer.