Ett stort platt nätverk

Det finns en naturlig tendens hos nätverk att bli onödigt komplicerade. Men det finns ett stort värde i att hålla nätverk rena och enkla. Enkla nätverk är lättare att hantera, mer prestandastarka och mer tillförlitliga samtidigt som de i allmänhet är billigare. Varje nätverk behöver en annan grad av komplexitet och stora nätverk kommer förvisso att behöva en omfattande grad av den, men småföretag kan ofta hålla nätverk extremt enkla, vilket är en del av det som gör mindre företag mer smidiga och billigare och ger dem ett försprång gentemot sina större motsvarigheter. Detta är ett försprång som de måste utnyttja eftersom de saknar storföretagens fördel av skala.

Det finns två sätt att betrakta nätverkskomplexitet. Det första är det fysiska nätverket – den faktiska uppsättningen av switchar och routrar som utgör nätverket. Det andra är det logiska nätverket – hur IP-adressintervall segmenteras, var routningsgränser finns, och så vidare. Båda är viktiga att beakta när man ser på komplexiteten i sitt nätverk.

Det bör vara målet för varje nätverk att vara så enkelt som möjligt samtidigt som det fortfarande uppfyller alla nätverkets mål och krav.

Den första aspekten vi kommer att behandla är det fysiskt platta nätverket. Att reducera ett fysiskt nätverk till att vara platt kan ha en verkligt häpnadsväckande effekt på prestandan och tillförlitligheten hos det nätverket. I ett mycket litet nätverk kan detta innebära att man arbetar utifrån en enda switch för alla anslutningar. Vanligtvis är detta endast möjligt för de allra minsta nätverken eftersom switchar sällan finns tillgängliga med fler än fyrtioåtta eller möjligen femtiotvå portar. Men för många småföretag är detta fullt möjligt. Det kan kräva ytterligare kabeldragning i en byggnad för att kunna föra samtliga anslutningar tillbaka till en central plats, men kan ofta uppnås – åtminstone på platsbasis. Många företag har idag flera platser eller personal som arbetar hemifrån, och detta kan göra nätverksutmaningarna betydligt större, även om varje plats kan sträva efter sin egen enkelhet i sådana fall.

När ett nätverk växer kan konceptet med den enda switchen också utökas med hjälp av konceptet switchstapling. Staplade switchar delar en enda switchväv eller bakplan. När de staplas beter de sig som en enda switch men med fler portar. (Vissa switchar gör verklig delning av bakplan och vissa efterliknar detta med mycket höghastighetsupplänkportar med delad hantering via den porten.) En switchstapel hanteras som en enda switch, vilket gör nätverkshanteringen varken svårare, mer komplex eller mer tidskrävande för en stapel än för en enda switch. Det är vanligt att en switchstapel växer till minst trehundra portar om inte fler. Detta möjliggör mycket större fysisk tillväxt på en plats innan man behöver lämna metoden med en enda switch.

I vissa fall kommer vissa kapslingar med stora moduler och en enda switch att växa ännu större än så och möjliggöra fyrahundra eller fler portar i en enda switch, men i en “bladeliknande” switchkapsling för storföretag.

Genom att vara kreativ och se till enkla, eleganta lösningar är det fullt möjligt att hålla även ett måttligt stort nätverk begränsat till en enda switchväv, vilket gör att alla nätverksanslutningar kan dela ett enda bakplan.

Det andra området som vi måste undersöka är nätverkets logiska komplexitet. Även i fysiskt enkla nätverk är det vanligt att finna småföretag som investerar en betydande mängd tid och energi i att implementera onödiga subnät eller VLAN och all den administrativa börda som följer med dessa.

Subnätsindelning är sällan nödvändig i ett litet eller ens ett mindre medelstort företag. Traditionellt, om vi går tillbaka till 1990-talet, var det mycket vanligt att vilja begränsa subnät till maximalt 256 enheter (eller ett /24-subnät) på grund av paketkollisioner, broadcaster och andra praktiska problem. Detta var mycket vettigt under den eran då hubbar användes i stället för switchar och broadcaster var vanliga och nätverksbandbredden var lyckligt lottad om den nådde 10 Mb/s på en delad buss. Dagens nätverk med få broadcaster, utan kollisioner och med dedikerade kanaler på 1 Gb/s upplever nätverksbelastning på ett helt annat sätt. Där 256 enheter på ett subnät var ett extremt stort nätverk då, är det att ha fler än 1 000 enheter på ett enda subnät en icke-fråga idag.

Dessa förändringar i hur nätverk beter sig innebär att små och medelstora företag nästan aldrig behöver subnätsindela av skalskäl och bekvämt kan använda ett enda subnät för hela sin verksamhet, vilket minskar komplexiteten och underlättar nätverkshanteringen. Fler än ett enda subnät kan vara nödvändigt för att stödja specifik nätverkssegmentering, som att separera produktions- och gästnätverk, men skala, det skäl som traditionellt anförts för subnätsindelning av nätverk, blir en fråga enbart för större företag.

Det är frestande att vilja implementera VLAN i varje småföretagsmiljö också. Subnätsindelning och VLAN är ofta relaterade och förväxlas ofta, men subnät existerar ofta utan VLAN, medan VLAN inte existerar utan subnät.

I stora miljöer är VLAN en självklarhet och det antas helt enkelt att de kommer att finnas. Denna mentalitet sipprar ofta ner till mindre organisationer som ofta frestas att tillämpa detta på företag som saknar den skala som gör VLAN-hantering meningsfull. VLAN bör vara relativt ovanliga i ett småföretagsnätverk.

Den vanligaste platsen där jag ser VLAN användas när de inte behövs är i nätverk för Voice over IP eller VoIP. Det är ett vanligt antagande att VoIP har särskilda behov som kräver VLAN-stöd. Detta är inte sant. VoIP och den QoS som det ibland behöver finns tillgängliga utan VLAN och fungerar ofta bättre utan dem.

VLAN blir egentligen bara viktiga antingen när hantering behövs i stor skala (där skalan är större än vad ett enda subnät kan tillhandahålla) och inte kan segregeras fysiskt, eller när specifik säkerhet på nätverkslagret behövs, vilket är relativt sällsynt på SMB-marknaden. VLAN är mycket användbara och har sin plats. VLAN används ofta om ett dedikerat gästnätverk behövs, men i allmänhet tillhandahålls gäståtkomst i ett småföretag via en direkt gästanslutning till internet snarare än via ett karantänsatt nätverk för gäster.

Den vanligaste praktiska användningen av ett VLAN i ett SMB är sannolikt en avskärmad DMZ utformad för karantänsatt fjärråtkomst för BYOD, där BYOD-enheter ansluter ungefär som gäster men har möjlighet att komma åt fjärråtkomstresurser som protokollen RDP, ICA eller PCoIP. VLAN skulle också vara populära för att bygga traditionella DMZ:er för externt riktade publika tjänster såsom webb- och e-postservrar – bortsett från att dessa tjänster i dagens SMB inte längre vanligen hålls på det lokala nätverket för hosting, så denna klassiska användning av VLAN i SMB håller snabbt på att blekna bort.

Ett annat användningsfall där VLAN ofta används på ett olämpligt sätt är för ett Storage Area Network eller SAN. Det är bästa praxis att ett SAN ska vara ett helt oberoende (luftgapat), fysiskt unikt nätverk utan koppling till den vanliga switchinfrastrukturen. Det rekommenderas i allmänhet inte att ett SAN skapas med hjälp av VLAN eller subnät utan i stället placeras på dedikerade switchar.

Det är frestande att lägga till komplexa switchuppsättningar, ytterligare subnät och VLAN eftersom vi hör talas om dessa saker från större miljöer, de är roliga och spännande, och de förefaller skapa anställningstrygghet genom att göra nätverket svårare att underhålla. Komplexa nätverk kräver mer avancerade färdigheter och kan verka som ett utmärkt sätt att använda det där nätverkscertifikatet. Men i längden är detta en dålig karriär- och IT-strategi. Nätverkskomplexitet bör läggas till i ett labb i inlärningssyfte, inte i produktionsnätverk. Produktionsnätverk bör drivas så enkelt, elegant och kostnadseffektivt som möjligt.

Med relativt liten ansträngning kan ett småföretagsnätverk sannolikt utformas till att vara både fysiskt och logiskt mycket enkelt. Målet är naturligtvis att komma så nära som möjligt att skapa en enda, platt nätverksstruktur där alla enheter är fysiska och logiska jämlikar utan onödiga flaskhalsar eller protokolleskaleringar. Detta förbättrar prestanda och tillförlitlighet, minskar kostnader och frigör IT-resurser till att fokusera på viktigare uppgifter.

Ursprungligen publicerad på StorageCraft-bloggen.