Ett stort flatt nettverk

Det er en naturlig tendens til at nettverk blir unødvendig kompliserte. Men det er stor verdi i å holde nettverk rene og enkle. Enkle nettverk er lettere å administrere, mer ytelsesdyktige og mer pålitelige, og er generelt rimeligere. Hvert nettverk trenger et ulikt nivå av kompleksitet, og store nettverk vil absolutt trenge et omfattende nivå av det, men små bedrifter kan ofte holde nettverk ekstremt enkle, noe som er en del av det som gjør mindre bedrifter mer fleksible og rimeligere, og gir dem et fortrinn over sine større motparter. Dette er et fortrinn de må utnytte fordi de mangler skalainntektene som store virksomheter har.

Det er to måter å se på nettverkskompleksitet. Den første er det fysiske nettverket – den faktiske oppsettet av svitsjer og rutere som utgjør nettverket. Den andre er det logiske nettverket – hvordan IP-adresseområder er segmentert, hvor rutingsbarrierer finnes, osv. Begge er viktige å vurdere når man ser på kompleksiteten i nettverket.

Det bør være målet for ethvert nettverk å være så enkelt som mulig, men likevel oppfylle alle mål og krav til nettverket.

Det første aspektet vi vil ta opp er det fysisk flate nettverket. Å redusere et fysisk nettverk til å være flatt kan ha en virkelig bemerkelsesverdig effekt på ytelsen og påliteligheten til det nettverket. I et veldig lite nettverk kan dette bety å jobbe fra én enkelt svitsj for alle tilkoblinger. Vanligvis er dette bare tilgjengelig for de aller minste nettverkene, ettersom svitsjer sjelden finnes over førti-åtte eller muligens femti-to porter. Men for mange små bedrifter er dette fullt mulig. Det kan kreve ytterligere kabling i en bygning for å bringe alle tilkoblinger tilbake til en sentral plassering, men kan ofte oppnås – i det minste på nettstedbasis. Mange bedrifter i dag har flere lokasjoner eller ansatte som jobber hjemmefra, og dette kan gjøre nettverksutfordringene mye større, selv om hver lokasjon kan strebe etter sin egen enkelhet i disse tilfellene.

Etter hvert som et nettverk vokser kan konseptet med den enkle svitsjen vokse med det ved hjelp av konseptet switch stacking. Stablede svitsjer deler et enkelt switching fabric eller backplane. Når de er stablet oppfører de seg som én enkelt svitsj, men med flere porter. (Noen svitsjer gjør ekte backplane-deling og noen etterligner dette med veldig høyhastighets opplinkporter med delt administrasjon via den porten.) En svitsjestabel administreres som én enkelt svitsj, noe som gjør nettverksadministrasjon ikke mer krevende, kompleks eller tidkrevende for en stabel enn for en enkelt svitsj. Det er vanlig at en svitsjestabel vokser til minst tre hundre porter om ikke mer. Dette muliggjør mye større fysisk vekst på et nettsted før man trenger å forlate tilnærmingen med én enkelt svitsj.

I noen tilfeller vil noen store modulbaserte enkeltsvitsj-chassier vokse enda større enn dette og tillate fire hundre eller flere porter i én enkelt svitsj, men i et "blade-lignende" enterprise switching-chassis.

Ved å være kreativ og se etter enkle, elegante løsninger er det fullt mulig å holde selv et moderat stort nettverk innenfor ett enkelt switching fabric, slik at alle nettverkstilkoblinger kan dele ett enkelt backplane.

Det andre området vi må undersøke er den logiske kompleksiteten i nettverket. Selv i fysisk enkle nettverk er det vanlig å finne små bedrifter som investerer en betydelig mengde tid og energi på å implementere unødvendige subnett eller VLAN-er og all overhead som følger med dem.

Subnetting er sjelden nødvendig i en liten eller til og med en mindre mellomstor bedrift. Tradisjonelt, tilbake til 1990-tallet, var det svært vanlig å ønske å holde subnett til maksimalt 256 enheter (eller et /24-subnett) på grunn av pakkekollisjon, kringkastinger og andre praktiske problemer. Dette ga mye mening i den epoken da huber ble brukt i stedet for svitsjer, kringkastinger var vanlige og nettverksbåndbredde var heldig om den var 10 Mb/s på en delt buss. Dagens kringkastingslette, kollisjonsfrie, 1 Gb/s dedikerte kanalnett opplever nettverksbelastning på en helt annen måte. Der 256 enheter på et subnett var et ekstremt stort nettverk da, er det å ha mer enn 1000 enheter på ett enkelt subnett et ikke-problem i dag.

Disse endringene i hvordan nettverk oppfører seg betyr at små og mellomstore bedrifter nesten aldri trenger å subnettverk av skalagrunner, og komfortabelt kan bruke ett enkelt subnett for hele virksomheten, noe som reduserer kompleksitet og letter nettverksadministrasjon. Mer enn ett enkelt subnett kan være nødvendig for å støtte spesifikk nettverkssegmentering, som å skille produksjons- og gjestenettverket, men skala – den tradisjonelt oppgitte årsaken til subnettverk – blir et problem kun for større bedrifter.

Det er fristende å ønske å implementere VLAN-er i hvert lite bedriftsmiljø. Subnetting og VLAN-er er ofte relaterte og ofte forvirret, men subnett eksisterer ofte uten VLAN-er, mens VLAN-er ikke eksisterer uten subnett.

I store miljøer er VLAN-er en selvfølge, og det antas ganske enkelt at de vil eksistere. Denne mentaliteten filtrerer ofte ned til mindre organisasjoner som ofte er fristet til å anvende dette på bedrifter som mangler den skalaen som gjør VLAN-administrasjon meningsfull. VLAN-er bør være relativt sjeldne i et lite bedriftsnettverk.

Det vanligste stedet der jeg ser VLAN-er brukt når de ikke er nødvendige er i Voice over IP- eller VoIP-nettverk. Det er en vanlig antagelse at VoIP har spesielle behov som krever VLAN-støtte. Dette er ikke sant. VoIP og den QoS det noen ganger trenger er tilgjengelig uten VLAN-er og vil ofte fungere bedre uten dem.

VLAN-er blir virkelig viktige bare når enten administrasjon er nødvendig i stor skala (der skalaen er større enn ett enkelt subnett kan tilby) og ikke kan fysisk segregeres, eller når spesifikk nettverkslagssikkerhet er nødvendig, noe som er relativt sjeldent i SMB-markedet. VLAN-er er svært nyttige og har sin plass. VLAN-er brukes ofte hvis et dedikert gjestenett er nødvendig, men generelt i en liten bedrift gis gjesteadgang via en direkte gjestetilkobling til Internett i stedet for et karantenenett for gjester.

Den vanligste praktiske bruken av et VLAN i en SMB er sannsynligvis en walled garden DMZ designet for karantene BYOD-fjerntilgang der BYOD-enheter kobler til omtrent som gjester, men har muligheten til å få tilgang til fjerntilgangsressurser som RDP-, ICA- eller PCoIP-protokoller. VLAN-er vil også være populære for å bygge tradisjonelle DMZ-er for eksternt tilgjengelige offentlige tjenester som web- og e-postservere – unntatt at disse tjenestene ikke vanligvis holdes på det lokale nettverket for hosting i dagens SMB-er, så denne klassiske bruken av VLAN-er i SMB-en fades raskt bort.

Et annet brukstilfelle der VLAN-er ofte brukes upassende er for et Storage Area Network eller SAN. Det er beste praksis at et SAN er et fullstendig uavhengig (air gapped), fysisk unikt nettverk uten sammenheng med den vanlige switching-infrastrukturen. Det anbefales generelt ikke at et SAN opprettes ved hjelp av VLAN-er eller subnett, men i stedet på dedikerte svitsjer.

Det er fristende å legge til komplekse switching-oppsett, ekstra subnett og VLAN-er fordi vi hører om disse tingene fra større miljøer, de er morsomme og spennende, og de ser ut til å øke jobbsikkerhet ved å gjøre nettverket vanskeligere å vedlikeholde. Komplekse nettverk krever høyere kompetanse og kan virke som en fin måte å bruke det nettverkssertifikatet på. Men på lang sikt er dette en dårlig karriere- og IT-strategi. Nettverkskompleksitet bør legges til i et laboratorium for læringsformål, ikke i produksjonsnettverk. Produksjonsnettverk bør drives så enkelt, elegant og kostnadseffektivt som mulig.

Med relativt lite innsats kan et lite bedriftsnettverk sannsynligvis utformes til å være både fysisk og logisk veldig enkelt. Målet er selvfølgelig å komme så nær som mulig å skape en enkelt, flat nettverksstruktur der alle enheter er fysiske og logiske likemenn uten unødvendige flaskehalser eller protokollopptrappinger. Dette forbedrer ytelse og pålitelighet, reduserer kostnader og frigjør IT-ressurser til å fokusere på viktigere oppgaver.

Opprinnelig publisert på StorageCraft Blog.