Supersygehus i Skejby får fibernetværk styret med to store switche

Sådan så Det Nye Universitetshospital i Aarhus ud i februar. De sidste etaper skal stå færdig i 2019. Foto: Region Midtjylland
Mindst 40.000 fiberkabler ud til de mange lokaler på det nye universitetshospital i Skejby er blot en del af et stort netværk, der også skal bruges til klimastyring.

Allerede inden det nye universitetshospital i Skejby uden for Aarhus tager imod de første patienter, vil supersygehusets enorme netværk have haft travlt. Det skal nemlig ikke kun overføre journaldata og røntgenbilleder, men også styre bygningerne.

Sygehuset er så stort, at netværksfolkene er endt med at vælge et netværk med fiberkabler ud til alle lokaler.

»Det er et ret stort sygehus med så langt mellem de to fjerneste steder, at vi snakker flere kilometer. Det betyder, at fiberkabler bliver til at have med at gøre, når afstandene er så store,« forklarer it-arkitekt Hans Ole Sandberg Andersen fra Region Midtjylland til Version2.

Fiberkabling betyder til gengæld, at netværket for det store område kan samles i blot to switchrum, Nord og Syd, hvor det hele styres af to store switche med hver 384 porte, som håndterer netværket på lag 2.

Ude i de enkelte lokaler sidder mikroswitche med hver fire porte, som kan koble udstyr op via almindelige netværkskabler og også giver mulighed for at forsyne de opkoblede enheder med strøm via netværkskablet.

Hvert lokale får flere switche, og switchene forbindes med begge switchrum. Med 10.000 planlagte mikroswitches bliver der trukket mindst 40.000 fiberkabler rundt i sygehuset.

Netværket skal også bruges af det bygningstekniske udstyr som eksempelvis temperaturmålere, styring af lys og sensorer, der kan registrere, om et vindue står åbent.

»Vi har været omhyggelige med at dele netværket op i blokke og segmenter for ikke at få for mange enheder på samme net. Når man kører Ethernet kan man få broadcast-storme, så der må kun én blok være nede. Tilgængelighed, tilgængelighed og tilgængelighed har været udgangspunktet,« forklarer Hans Ole Sandberg Andersen.

Medikoteknisk udstyr kobles på netværket

Ud over det bygningstekniske udstyr, så skal netværket ikke blot betjene pc'er og servere. Der er også en masse medikoteknisk udstyr, som skal forbindes til netværket.

Det har vist sig at give visse udfordringer, fordi noget af udstyret eksempelvis forventer at sidde på et VLAN, som netværksfolkene helst vil undgå at bruge, fordi det giver problemer på den netværkstopografi, der er valgt til sygehuset.

Det medikotekniske udstyr kører i visse tilfælde også stadigvæk Windows XP, og derfor vil det være adskilt fra de almindelige pc'er med firewalls, fordi Windows XP ikke længere får sikkerhedsopdateringer.

Udstyret vil som regel ikke kunne opdateres til eksempelvis Windows 10, fordi det tager flere år at få udstyret godkendt med så væsentlig en ændring.

For netværksfolkene er det primært det store antal enheder på netværket, der giver udfordringer. Selvom udstyr som fMRI-scannere genererer store mængder data, så lagres det i første omgang lokalt på udstyret.

»Vi regner ikke med, at vi kommer i problemer med datamængderne,« siger Hans Ole Sandberg Andersen.

Det vil også være muligt at opgradere netværket. Alle fiberkabler er lagt i rør, så der kan skydes nye kabler ind, eller de eksisterende kan erstattes af tyndere kabler, så der bliver plads til flere.

Med to switchrum er det desuden nemmere for netværksfolkene at servicere og opgradere netværksudstyret.

En særlig udfordring kan derimod blive det netværk, der ikke løber gennem fiberoptiske kabler, men sendes som radiobølger uden kabler.

»Vi skal blandt andet lave netværk til patienter og besøgende, og trådløst er en begrænset ressource, fordi vi kun har de kanaler, der nu en gang er,« fortæller Hans Ole Sandberg Andersen.

Senge kobles på wifi

Mens der kan trækkes flere fiberkabler, så er det vanskeligere at øge kapaciteten på et trådløst netværk. På supersygehuset skal det trådløse netværk desuden også bruges til mere end blot internetadgang til patienter og pårørende.

Eksempelvis vil sengene blive udstyret med en wifi-enhed, så et centralt system kan holde styr på, hvor hver seng befinder sig, og om den for eksempel skal gøres ren.

Det skal reducere behovet for at have ekstra tomme senge stående rundt om på de enkelte afdelinger på sygehuset, fordi der altid vil være styr på, hvor de ledige senge befinder sig.

Tilsvarende skal det transportable medikoudstyr udstyres med RFID-tags, som kan registreres af RFID-scannere ved dørene, så der også er styr på, hvor et apparat står, og om det er i brug.

»It er en helt central del af at drive et sygehus. Der er også et besparelsespotentiale, fordi man ikke behøver have så meget udstyr i overskud,« siger Hans Ole Sandberg Andersen.

Netværksarkitekturen på det nye universitetshospital i Skejby vil også blive brugt på Region Midtjyllands nye supersygehus i Gødstrup i Vestjylland.

Her vil fiberkablerne dog også få selskab af et noget mere håndgribeligt pakkebaseret netværk i form af rørpost, der skal bruges til at sende prøver og medicin rundt på sygehuset via en central rørpostswitch.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk

Kommentarer (27)

Nikolaj Brinch Jørgensen

Det har vist sig at give visse udfordringer, fordi noget af udstyret eksempelvis forventer at sidde på et VLAN, som netværksfolkene helst vil undgå at bruge, fordi det giver problemer på den netværkstopografi, der er valgt til sygehuset.

Det kunne være rart at vide, hvorfor der er valgt en netværkstopologi der ikke decideret understøtter det udstyr der skal være tilsluttet netværket?
Er det ikke som at bygge veje der ikke understøtter de biler der skal køre på dem?

Søren Dideriksen

Der er tale om 480 porte pr. aggregerings switch og ikke 384, som angivet i artiklen. Desuden er der ikke tale om 1 "stor switch", men om - 10000/480 ~ 20ish aggreringsswitche pr. hovedkrydsfelt. Hver switch-sæt udgør et særskilt L2-domæne.

Søren Dideriksen

Netværkstopologien er designet ud fra de krav der blev stillet oprindeligt, både mht til fleksibilitet, skalerbarhed, etc, og de krav der skulle stilles til endeudstyret. Når kravene så sidenhen ændrer sig på forskellig vis, så kræver det jo tilpasning inden for de rammer der lader sig gøre.

Hvis du bygger en motorvej og der kommer en fyr med et sejlbåd, så har du flere muligheder.

1: Bed ham om at købe en bil.
2: Køb en lastbil hvorpå hans båd kan køres frem.
3: Fjern et spor på motorvejen og grav en kanal i det spor til hans båd.

Man går sjældent med 3'eren, hvis det kan undgås.

Det er selvfølgeligt forenklet, men det er lidt derhenad. Bygge/flytte-processen er en lang process og der sker en masse udvikling i den tid, både organisatorisk, økonomisk og teknisk.

Casper Thomsen

> noget af udstyret (...) forventer at sidde på et VLAN, som netværksfolkene helst vil undgå at bruge

Hvordan bliver det så løst? Er der faktisk to separate fysiske netværk (ønskværdigt, tænker jeg)?

Må jeg være så fri at spørge om mere "teknisk kød" på historien, eller får vi en follow-up?

Jens Skov

Ja, det er da anderledes at opgradere WiFi end at udskifte et kabel :-)
Men umuligt er det da ikke.

"...og trådløst er en begrænset ressource, fordi vi kun har de kanaler, der nu en gang er..."
Ja, men det er jo her et godt design kommer ind.

Jens Skov

God sammenligning Søren :-)
Jeg studser også noget over at der er valgt en topologi, som spænder ben for VLAN. Der er helt sikker en god historisk grund, men det kunne være sjovt at høre lidt mere om løsningen.

Søren Dideriksen

Med hensyn til VLANs. Jeg kan godt se, at det der står i artiklen, kan forstås som om vi slet ikke 802.1q tagger. Men sådan skal det ikke forstås. Det handler mere om hvor mange VLANs der skal være og deres udbredelse i nettet.

Jeg kan godt prøve at uddybe lidt mere teknik og hvilke tanker der ligger bag de valg der er taget - senere. Om der kommer en decideret follow-up ved jeg ikke.

Nikolaj Brinch Jørgensen
Jn Madsen

at Q-in-Q og MST kan få tingene til at skalere bedre.
I den størrelse kan man godt løbe tør for vlans, så det er med at være forudseende.

Og hold jer for guds skyld fra producent-proprietære teknologier.

Baldur Norddahl

Jeg fatter ikke hvorfor universiteter og åbenbart også hospitaler holder fast i at køre kæmpe layer 2 netværk. Hvor stort skal et broadcast domæne være? Svar: en enkelt maskine.

Klienterne skal slet ikke kommunikere direkte med hinanden. Trafikken skal ind centralt og filtreres i firewall og sniffes af network intrusion detection software. Det gør man ved at køre klienterne med et vlan per klient. Alternativt kan man bruge private vlan https://en.wikipedia.org/wiki/Private_VLAN.

Trafikken kan samles op af en decentral layer 3 switch og herefter routes. Så slipper man for uhyrligheder som spanning tree protocol og kan køre OSPF i stedet. Man kan også overveje MPLS og udnytte VRF/L3VPN og i specielle tilfælde L2VPN i stedet for vlans. Hvad er det for noget udstyr der skal have nogle sjove vlans? - ind i et L2VPN så er den løst (i et layer 2 net er det dog også trivielt bare at rename vlans, det kan næsten alt udstyr).

Det er ikke godt nok med en firewall ud imod internettet. Man må antage at vilkårlige klienter er overtaget af onde kræfter, så derfor bør klienterne beskyttes imod hinanden. Der bør være firewall på alt trafik også den interne trafik. Og det er faktisk ikke så svært.

Man må huske på at der ikke findes en ISP der vil overveje at køre kunderne på et layer 2 domæne. Det er altid en eller anden variant af ovenstående, så derfor er der også tonsvis af udstyr og løsninger der supporterer det.

Troels Christensen

"Nord og Syd, hvor det hele styres af to store switche med hver 384/480 porte"

"Hvert lokale får flere switche, og switchene forbindes med begge switchrum. Med 10.000 planlagte mikroswitches "

Det vil sige 800-900 porte til 10.000 switche, eller hvad ?

Nikolaj Brinch Jørgensen

Det er ikke godt nok med en firewall ud imod internettet. Man må antage at vilkårlige klienter er overtaget af onde kræfter, så derfor bør klienterne beskyttes imod hinanden. Der bør være firewall på alt trafik også den interne trafik. Og det er faktisk ikke så svært.


Jeg har endnu til gode at se et sted hvor dette ikke både er svært for organisationen, og meget dyrt i administration og hardware.
Jeg går ud fra at når du taler intern trafik, mener du også trafik i serverrummet mellem serverne?

Baldur Norddahl

Jeg går ud fra at når du taler intern trafik, mener du også trafik i serverrummet mellem serverne?

Det kommer nok an på hvor tæt på idealet du vil. Serverne kan formodes at være under bedre kontrol, men trafikken bør stadig sniffes af network intrusion detection software og serverne inddeles i zoner. Det er faktisk et krav hvis man vil certificeres efter PCI DSS sikkerhedsstandarden til kreditkortbetalinger - men penge er måske vigtigere end menneskeliv på et hospital?

Baldur Norddahl

Det lyder da enormt ineffektivt, hvorfor skal trafikken ind centralt? Kan man ikke da lave network intrusion detection decentralt?

Jo det er da fint nok hvis det er billigere. Nu er det bare temmeligt billigt at transportere trafik ind centralt og trafik mellem klienter er traditionelt tæt på nul i forvejen. Så hvorfor ikke bare tage det ind i serverrummet hvor 99% af trafikken skal hen under alle omstændigheder?

Nikolaj Brinch Jørgensen

Det kommer nok an på hvor tæt på idealet du vil. Serverne kan formodes at være under bedre kontrol, men trafikken bør stadig sniffes af network intrusion detection software og serverne inddeles i zoner. Det er faktisk et krav hvis man vil certificeres efter PCI DSS sikkerhedsstandarden til kreditkortbetalinger - men penge er måske vigtigere end menneskeliv på et hospital?


Jeg er helt enig i at servere skal inddeles i zoner, og specielt skal produktionsmiljøer helt adskilles fra de andre mindre kritiske miljøer. Jeg har bare alt for ofte i driftsorganisationer siddet og skrevet lange requests om at få åbnet en port mellem 2 servere der pine død skal kommunikere. Det er for langt at gå - app server 1 og 2 er en del af samme løsning, og de driftes sammen, der er absolut ingen grund til at der skal sættes en dør mellem dem.
Ellers er jeg stort set enig i dit indlæg.

Jn Madsen

Her har Baldur faktisk lidt ret.

Mange falder alt for ofte i gryden med enorme L2 broadcast domæner.
Kæmpe store DHCP puljer, lidt beskyttelse imod DHCP snooping, en default gateway der futter igennem en firewall,- og man tror det hele ånder fred og ro.
Indtil et NIC får en hjerneblødning og dræber hele domænet i støj,- eller noget andet sjov.

Men,- rent praktisk kan man ikke altid køre med en client/server til en routed port. Der er variationer. Serverfarme med 1000'vis af VM'er er ofte heftige L2 netværk. (men stadig på forskellige vlans)

At tingene bliver bøvlet og tungt at administrere, det skyldes man ofte glemmer at designe efter gyldne regler som:

Simplificer
Standardiser
Automatiser
Abstraher

(og hold fingrene fra producent-proprietære løsninger, eller vær i det mindste meget vidende om dem, og hav en plan klar for at komme ud af dem)

Nikolaj Brinch Jørgensen

At tingene bliver bøvlet og tungt at administrere, det skyldes man ofte glemmer at designe efter gyldne regler som:

Simplificer
Standardiser
Automatiser
Abstraher

(og hold fingrene fra producent-proprietære løsninger, eller vær i det mindste meget vidende om dem, og hav en plan klar for at komme ud af dem)


Korrekt. Dog er der enormt mange netværk der designes ud fra netværksafdelingens præferencer (og kompetencer) og ikke fra krav om hvad de rent faktisk skal bruges til. Her kan det være svært at opnå enighed om dine 4 regler.

En ting, som er enddog meget svært i mange netværksorganisationer jeg er stødt på, er fornuftig brug af DNS. Jeg er blevet udstukket servere med md5 hash navne (så er det altså nemmere at huske ip adresser), brug af .local navne på server-infrastruktur, som så ikke kan nås via navne fra alt andet end Windows maskiner, navne der er så lange, fordi man ikke bruger subdomains (alias), at det er næsten umuligt at huske og skrive - osv.
Det ser ud til, ud fra ovenstående fra Baldur og Jn Madsen, at der stadigt er meget at lære omkring fornuftig omgang med netværk, og planlægning heraf.
Jeg har også været i organisationer, hvor man virkelig er god til at organisere det, og løbende ændrer netværket, efter opgaverne, og skaleringen ud fra hvordan netværket vokser.

Søren Dideriksen

Ja, Baldur har nemlig ret. Hvilket også er grunden til at vi har segmenteret kraftigt, der er ikke nogen store L2-domæner i nettet (jeg ved ikke hvor den antagelse kommer fra).

Nettet er designet ud fra at alt skal kunne routes. Det er så bare her vi kommer i clinch med leverandørerne af ende-udstyr. Det kan de nemlig typisk ikke leve med.
(det er alt fra PC'er til plantevandingssystemer og andet godt fra teknik-verdenen der skal serviceres)

Vi er ikke gået all-in med helt isolerede klienter, men l2-domænerne er reduceret, netop for at sikre stabilitet. Fra fiber-aggregering og opefter bliver nettetne samlet op og routet de enkelte net i passende routnings instanser som bliver centralt filtreret.

Jn Madsen

For mange år siden (Åhh nej, tænker i nu:)

Første gang skønheden i systematik ramte mig, var som tekniker i KTAS/TeleDanmark,- nu TDC.

For 20-25 år siden kunne en kunde gå ind i en telebutik, snakke med en medarbejder i starten af tyverne (uden den mindste tekniske forståelse), fortælle sin adresse og de blev enige om et telefonnummer.
Det virkede 99% af gangene når kunden kom hjem.

Hvad skete der?

Adresse,- databaser undersøger om der er registrerede ledningsveje mellem central og kundens adresse.
Målerobot tjekker lige om kobbertrådenes kapacitive, induktive og ohm'ske værdier er indenfor det acceptable.
Databaser tjekker for konflikter med andet udstyr, det være sig mønttelefoner/tyverialarmer og andet der kan være frekvensområder i konflikt.

Hvis der er mangler, f.eks. en krydstråd der skal trækkes på en central eller en splidsning i en muffe,- så defineres arbejdet på millisekunder, og arbejdsordre sendes til rette personale.

Nå, men der tjekkes også personoplysninger, Ribers mv,- lineiekortet på centralen aktiveres, konfiguration med telefonnummer, regnings-aktivering, overvågning startes.
Måske aktiveres kapacitetsalarmer, hvis kabler/centraler/transmissionssystemer når en grænse,- nye procedurer sættes i gang.

Alt dette skete mellem kunden sagde hvor han skulle bo, og hvad telefonnummeret skulle være. Medarbejderen tastede ind, systemet sagde ok,- og han/hun trykkede på "OK". Et par sekunder efter spillede det.

Det er på samme måde med netværk i dag, hvis man ikke tænker i systemer og sikkerhed, så bliver man ristet på et tidspunkt.
Og det gælder ikke kun store systemer, jeg har set små systemer der på kort tid har udviklet sig til helvedes administrative forgård :-)

Paw Møller

Hvordan fungerer separate VLANs ved WiFI?
Hvis brugeren skal kunne gå mellem de forskellige APs uden at tabe forbindelse, skal hver enkelt AP vel være på samme subnet/VLAN(jeg antager samme SSID)?
Med mange besøgende må det give et meget stort subnet; er der nogen vej uden om det?

Maciej Szeliga

Det kunne jo være at det insisterer på at leve i VLAN1 eller det IP segment som VLAN1 har eller at det kun understøtter den gamle klasseinddeling og så er det ret svært at gøre noget.

Søren Dideriksen

Det vil sige, at jeres bærbare problemfrit kan flyttes fra dock til wifi,- uden at medarbejderen bliver smidt af servere og andet??

Nej, det vil sige, at der kan roames imellem AP'er der ikke har adgang til samme VLAN til at offloade i. F.eks en læge eller portør der vandrer rundt med en tablet. Hvis du klapper den i docken, og den vælger (det kan OS'et jo vælge) at benytte det fortrådede kort, så ryger dine IP-baserede sessioner.

Log ind eller opret en konto for at skrive kommentarer