Svartider banket i bund: Sådan cacher Grundfos data til kinesiske medarbejdere

Når medarbejdere hos Grundfos skal dele viden med hinanden på tværs af kontinenter, så bliver svartiderne på netværket en barriere.

Medarbejderne hos danske Grundfos skal oftere arbejde sammen med kolleger i virksomhedens afdelinger i resten af verden, og det giver helt særlige udfordringer, når netværket strækkes ud over hele kloden.

»Vi globaliserer vores udvikling og laver virtuelle kompetencecentre. Så vi har behov for, at medarbejderne kan dele viden på tværs af verden. Og det er altid en udfordring på et WAN,« siger it-driftschef Peter Hvilshøj fra Grundfos til Version2.

Problemet har især været svartiderne på netværket. Derfor valgte Grundfos at se efter en løsning, som kunne nedbringe svartiderne for brugerne. Grundfos endte med at vælge Citrix Branch Repeater, blandt andet fordi Grundfos i forvejen benyttede Citrix.

Løsningen kan dels fungere som cache, så alle medarbejdere på én lokalitet ikke behøver hente de samme data hver gang. Men den kan også nedsætte svartiderne på netværket.

»TCP/IP-handshakes koster en masse tid, og jo længere afstand, jo flere handshakes skal du lave,« forklarer ingeniør Henrik Poulsen fra Citrix til Version2.

Et handshake er routernes indbyrdes håndtering af netværkspakkerne, og jo længere data skal overføres over et netværk, jo flere routere skal pakkerne gennem.

På et globalt netværk kan man derfor med fordel eliminere en del af disse handshakes ved som i Citrix' tilfælde at sætte en ekstra pakke foran den første pakke, så der så at sige kommer en adressemærkat på hele pakkestrømmen mellem to Branch Repeater-bokse på netværket i stedet for på hver enkelt pakke.

På den måde eliminerer man både en del af det overhead, der ellers optager båndbredde med information om, hvor dataene kommer fra og hvor de skal hen, og man reducerer de svartider, brugerne oplever, når de bruger systemerne.

For Grundfos er det vigtigt, at selvom en del af udviklingen er flyttet ud i udlandet, så beholder selskabet alle data centralt.

»Vi ønskede ikke at have tingene distribueret. Men vi må også erkende, at behovet for at dele data ikke bliver mindre, så måske må vi på sigt finde en løsning, hvor vi kan pushe data ud, så vi kan have data til at ligge tæt på brugerne, men stadig have det hele centralt,« siger Peter Hvilshøj fra Grundfos til Version2.

En del af udfordringen for Grundfos er, at de værktøjer, som bruges i udviklingsafdelingerne, skaber meget store mængder data, så når medarbejdere i forskellige lande skal arbejde sammen, så skal der også deles meget store datamængder.

»Vi kan købe os til en masse netværkskapacitet, men det er ikke sikkert, det går hurtigere,« siger Peter Hvilshøj.

»Netværk er historisk ikke lavet til store afstande. Afstanden koster, så du taber båndbredde. På en 2 megabit-forbindelse får du typisk kun 60-70 procent. Du kan købe mere, men afstanden vil stadig være et problem for svartiderne,« siger Henrik Poulsen fra Citrix.

Efter implementeringen af netværkscache på lokalkontorerne har Grundfos fået reduceret svartiderne ifølge Peter Hvilshøj, men præcis hvor stor forbedringen er, afhænger af flere variable, og han vil derfor ikke sætte tal på forbedringen.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (5)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Andreas Plesner

»TCP/IP-handshakes koster en masse tid, og jo længere afstand, jo flere handshakes skal du lave,«

Sikke noget sludder. Jeg går ud fra at der er tale om TCP three-way handshake, og det skal kun laves en enkelt gang mellem to endpoints. Antallet af routere har ingen indflydelse på dette. De har kun indflydelse på hvor lang tid det tager for de tre pakker at nå frem.

  • 4
  • 0
#3 Thomas Anker Carlsen

Hvis data kun sjældent ændres er en (lokal) cache fin. Men data som opdateres ofte kommer let "bagud": - de slipper for at vente 10 ulidelige sekunder på et gammelt (uændret) dokument. - men skal vente 2 timer (cache-opdatering) på at få adgang til et nyt (eller ændret..).

  • 0
  • 1
#4 Rasmus Rask

Jeg har hos en tidligere arbejdsgiver evalueret tre forskellige WAN acceleratorer, så jeg har sat mig lidt ind i tingene, men jeg er bestemt ikke netværksekspert.

»TCP/IP-handshakes koster en masse tid, og jo længere afstand, jo flere handshakes skal du lave,«

Sikke noget sludder. Jeg går ud fra at der er tale om TCP three-way handshake, og det skal kun laves en enkelt gang mellem to endpoints.

Ja, jeg tror Henrik har fået blandet tingene lidt sammen. For det første er der mig bekendt ikke tale om flere handshakes, jo længere afstanden er.

For det andet er det de højere liggende protokollers handshakes/chattiness, der sænker det faktiske throughput (betragteligt) når latency øges.

CIFS/SMB ver. 1 er forfærdelig chatty og bare det at åbne et share med f.eks 50 filer i Explorer over en forbindelse med 300 ms RTT tager mange gange længere tid end en lokal. Throughput ved filkopiering, og i meget høj grad ved mange små, lider også. Det er så voldsomt forbedret i version 2 (Windows 2008/Vista og senere).

Se evt. dette whitepaper fra Intel: http://www.intel.com/it/pdf/optimizing-wan-performance.pdf

WAN acceleratorerne sættes in-line ved internetforbindelsen, lige før firewall'en og fungerer i bund og grund vha. af spoofing i bedste man-in-the-middle stil. Den måde de WAN acceleratorer jeg testede løste "chattiness"- problemet på, var ved at den lokale WA opsnapper når der opsættes forbindelse til en server på et fjernkontor og svarer på vegne af denne. Dermed foregår f.eks. CIFS-protokollens chat kun mellem klient og lokal WA, men klienten tror den har opsat forbindelsen med den ønskede server.

Den nødvendige information om forbindelsen trasmitteres nu komprimeret via en proprietær protokol fra den lokale WA til WA'en på fjernkontoret, som herefter "afspiller" chatten og foregiver at være klienten overfor serveren.

Selvom det måske ikke lyder sådan, så forbedrer dette alene både throughput og brugeroplevelse enormt. Men udover dette bruger de forskellige WAN acceleratorløsninger komprimering og caching.

Hvis data kun sjældent ændres er en (lokal) cache fin. Men data som opdateres ofte kommer let "bagud": - de slipper for at vente 10 ulidelige sekunder på et gammelt (uændret) dokument. - men skal vente 2 timer (cache-opdatering) på at få adgang til et nyt (eller ændret..).

Mindst to af de løsninger jeg testede opdelte trafikken i blokke og cachede de blokke der passeret. Når en WA genkendte en blok fra sin tabel over data der pt. befandt sig i cachen, kan den nøjes med at fortælle WA'en i den anden ende at hente blok nr. X fra sin cache, i stedet for rent faktisk at overføre hele blokken. Efterhånden som cachen fyldtes, skubbedes mindre brugte blokke ud af cachen.

I praksis betød det for os i den endelige implementering, at ingen nogensinde skulle vente på en cache opdatering - det skete kontinuerligt. Bliver en ukendt (ikke-cachet) blok data sendt, bliver den cachet, komprimeret og sendt. Det var intet problem at sidde med et kæmpe Word-dokument åbent på 40 MB (f.eks. fyldt med hi-res billeder og andet skrammel) over en forbindelse med høj latency og lav båndbredde. Lav ændringer og gem - det tog højst et par sekunder.

En anden fordel det gav os var at vi droppede at opsætte lokale "repositories" til opdateringer, som ellers ville være nødvendigt for ikke at dræbe linjerne. Alle hentede (Windows-)opdateringer fra vores centrale WSUS-server. Første gang hver blok af opdateringerne passerede WA'erne blev de cachet og serveret lokalt til alle andre klienter.

Håber det giver mening det jeg skrev. Der er nul overblik i den her 5 linjers memoboks :-)

  • 2
  • 0
#5 Rasmus Rask

Som en lille sidebemærkning kan jeg sige at vi testede produkternes effektivitet ved filoverførsel, da det var vores primære grund til at kigge på WAN acceleratorer.

Vores infrastruktur var Windows, så vi kopierede over CIFS version 1.

Vi testede med to grupper blandede filer - en med små filer på højst et par hundrede kilobyte og en med 1+ MB.

Vi testede både ved at kopiere via. push og pull. Der var overraskende en markant forskel. Kopieringen gik langt hurtigere når vi kopiererede til den samme maskine der foretog operationen (pull), i forhold til at kopiere fra klienten til serveren på det andet site (push).

Vi foretog hver test (push/pull) to gange. Første gang var data nyt for WA'erne og dermed kunne vi se effekten af deres komprimering og protokolspecifik optimering (chat reduktion). Anden gange var data cachet og vi kunne dermed se hvor hurtigt WA'erne opsnapper trafikken, finder ud af at data er cachet og servere data fra den lokale cache.

Vi gentog dette test mønster med de tre forskellige produkter vi kiggede på og sammenlignede med resultatet uden WA.

Efter nogle måneder i produktion kunne vi konstatere at vores faktiske throughput var ca. 4 gange større end den trafik der rent faktisk passerede vores WAN-linjer. Derudover oplevede vores brugere at navigering i shares og håndtering af filer, var omtrent lige snappy om det foregik på en lokal server i DK eller en i Kina (med 300+ ms RTT).

Håber ikke dette opfattes som reklame - har med vilje ikke nævnt nogle firmaer eller produkter ;-)

  • 0
  • 0
Log ind eller Opret konto for at kommentere