Fem gyldne regler for netværksarkitektur

Af Andreas Frøland

Ofte er dårligt design den direkte årsag til, at netværket ikke yder som ønsket – og måske endda er ustabilt. Korrekt, omhyggeligt udført netværksdesign er med til at sikre, at netværksløsningen fungerer optimalt med høj ydelse og god stabilitet.
I forbindelse med design af en ny netværksinfrastruktur er der mindst fem vigtige parametre, man bør holde for øje: Non-blocking backbone, lav ”end-to-end” forsinkelse, eliminering af flaskehalse, redundans og endelig drift og overvågning.

Non-blocking backbone
Talrige netværk er blevet ustabile på grund af overdreven brug af workgroup-switche i stedet for hubber. Når hubber udskiftes med switche, er det meget vigtigt, at den samlede backbone-kapacitet følger med, ellers kan det gå galt.
Det svarer lidt til at installere flere toiletter til samme faldstamme uden at udvide faldstammens kapacitet
- og så kan man levende forestille sig, hvad dette medfører!
I dag er de fleste netværksdesign opbygget over en central backboneløsning, hvortil workgroup-switche og de primære netværksressourcer er tilsluttet. Det er meget vigtigt, at backbonen har rigeligt med kapacitet. Har den ikke det, kan man risikere, at backbonen begynder at tabe pakker. Hvis backbonen på grund af belastning taber pakker, vil de arbejdsstationer, der ikke får svar på grund af de tabte pakker, begynde at re-transmittere pakkerne. Det betyder endnu højere belastning – og så går det først rigtigt galt.
Et korrekt udført design vil altid bestå af en non-blocking kerne, der har samme eller højere kapacitet end det samlede båndbreddekrav, som summen af workgroup-switche kan stille.
Forestiller man sig for eksempel et netværk med 600 brugere fordelt på 25 workgroup-switche alle tilsluttet til backbonen med 155 Mbit/s ATM, så bør backbonen have en kapacitet på 25 gange 155 Mbit/s, altså i alt 3,8 Gbit/s.
Desto større netværket er, desto større fordel har man kapacitetsmæssigt. Det er jo en selvfølge, at ikke alle brugerne benytter netværket samtidig. Men man må ikke glemme, at producenterne af workgroupswitche allerede har taget højde for det. Ser man på Ethernet workgroup-switche, er det meget normalt, at en 24 ports 10 Mbit/s workgroup-switch bliver tilsluttet backbonen med 100 Mbit/s.
Allerede her er der tale om en gearing på 2,4:1, og med 10/100-switche bliver det endnu værre. En typisk 24 ports 10/100-switch bliver ofte forbundet til backbonen med 100 Mbit/s, Gigabit Ethernet eller 155 Mbit/s ATM, gearingsforholdet er henholdsvis 24:1, 2,4:1, og 15:1. I mange tilfælde stackes disse switche endda med tre eller fire switche i én stack, der alle deler en og samme forbindelse til backbonen, hvorfor forholdene tilsvarende forværres med faktor 3 eller 4.

Lav ”end-to-end”- forsinkelse
Alle netværksenheder, der er placeret mellem en arbejdsstation og en server, tilfører en eller anden form for forsinkelse – de kan dårligt gøre andet! Spørgsmålet er, hvor stor en forsinkelse af pakkerne hver enhed tilføjer.
Den forsinkelse, som for eksempel en switch tilføjer, kan måles i mikrosekunder, mens den forsinkelse, en router tilføjer, typisk kan måles i millisekunder. Ingen af delene lyder af meget, men lav forsinkelse er en meget vigtig parameter for, at man kan opnå en tilfredsstillende ydelse.
Netop lav forsinkelse er en af de vigtigste grunde til, at lag 3-switche er blevet så populære i det lokale netværk frem for routere. Den laveste forsinkelse opnås ved ikke at benytte nogle netværksenheder overhovedet ud over hubber. Dette er desværre ikke praktisk muligt i netværk med mere end en håndfuld brugere.
Lag 2-switche tilbyder den laveste forsinkelse, men har desværre ingen lag 3-funktioner (routing). Har man behov for lag 3-funktionalitet, er lag 3-switche klart at foretrække frem for almindelige backboneroutere, medmindre man har helt specifikke behov, der kun kan løses med en router.

Eliminering af flaskehalse
I ethvert netværk vil der altid være flaskehalse. Øvelsen går på inden for de økonomiske muligheder at få dem reduceret så meget, at de i det daglige ikke er til gene for brugerne.
Første skridt i jagten på flaskehalse er at få et overblik over, hvor flaskehalsene er placeret og hvor store de eventuelt er. Overblik ved hjælp af netværksmålinger eller RMON-overvågning er her et nøgleord. Man skal endvidere være opmærksom på, at der kan være stor forskel mellem den nominelle hastighed, som en given forbindelse har, og det throughput (byte i sekundet), som den kan levere. Denne forskel kan skyldes den grundlæggende access-metode og/eller det overhead, der er i teknikken.

Redundans
Redundante netværk var før i tiden forbeholdt pengeinstitutter og forsikringsselskaber. I de senere år er redundante netværk også blevet ganske populære i andre sektorer, herunder industri og produktion. Det skyldes blandt andet små lagre og ”just in time” produktion.
Redundante netværk er et ekstra krydderi, når netværket skal designes, idet kompleksiteten stiger væsentligt. Opbygges netværket på lag 2, kræves der et dybtgående kendskab til Spanning Tree, ellers kan det gå gruelig galt. Hvis netværket opbygges på lag 3, gælder det samme for OSPF.
Redundans sætter også krav til, at netværket er vel dokumenteret, og at der findes en backup af konfigurationerne af de enkelte netværksenheder. Ellers kan udskiftningen af en enkelt boks være skyld i, at netværket bliver ustabilt på grund af forkerte Spanning Tree- eller OSPF-parametre.

Drift og overvågning
Det efterfølgende arbejde med drift og overvågning af netværket må ikke undervurderes. Hvis netværksenhederne understøtter RMON-standarden, er det muligt at få et særdeles godt overblik over netværkets helbredstilstand. Det er ligeledes muligt at fastlægge forskellige grænseværdier, der vil udløse en alarm, hvis de overskrides.
Denne form for proaktiv overvågning sikrer så få ubehagelige overraskelser som overhovedet muligt, hvilket i sidste ende er til glæde for både netværksafdelingen og brugerne. Vær dog opmærksom på, at RMON-standarden er stor og omfattende samt meget CPU-krævende, hvorfor en del netværksenheder kun har en delvis RMON-implementering. Det udelukker i nogle tilfælde desværre brug af de mere smarte RMON-funktioner.