Sådan virtualiserede vi

Efter at have haft en håndfuld servere kørende virtuelt i et par år, besluttede vi for godt et år siden at vores server-strategi fremover skulle være baseret på virtuelle miljøer, nærmere betegnet VMwares ESX-server.

Det var flere årsager til at vi valgte at virtualisere. Blandt de banale, som de fleste andre sikkert også har med i overvejelserne, var en reduktion af strøm-forbruget og bedre udnyttelse at vore servere.

Blandt de mere kritiske årsager var, at vi havde mange gamle servere. Og det gjaldt både hardware og software.

En hel del af de Linux-operativsystemer vi kørte vores servere på blev ikke længere supporteret med sikkerheds-opdateringer og jeg anbefalede derfor en to-strenget strategi.

At vi samtidig med at vi virtualiserede serveren også opgraderede serverens operativsystem.

Det betød af vi ikke kunne benytte os af værtøjer til at flytte serverne fra en fysisk platform og til en virtuel platform, men derimod måtte gøre det hele fra bunden af.

Fordele og ulemper

Umiddelbart er det god latin ikke at indføre mere end en stor ændring af gangen, men jeg følte at fordelene denne gang klart opvejede eventuelle ulemper.

Vi kunne sikre os at serveren var installeret efter de korrekte foreskrifter ved at bruge den samme template til alle servere.

En anden meget stor fordel var at vi kunne nedbringe antallet af forskellige operativsystemer voldsomt. Det ville lette vores
support-opgaver at køre på en mere harmoniseret platform.

Og samtidig ville det også give os en mulighed for at tage stilling til alle de services vi havde kørende og finde ud af om vi rent faktisk skulle bruge/tilbyde dem fremover.

Sidst men ikke mindst så er det min erfaring at det giver bedre ydelse at virtualisere fra bunden af, i stedet for at hive en fysisk server over på en virtuel platform. Selvom fordelen selvfølgelig varierer meget fra server til server.

Blandt ulemperne var at projektet ville tage længere tid og vi risikerede at vi med de mange ændringer ville have svært ved at finde ud af hvorfor eventuelle problemer opstod.

Og det forløb da heller ikke problemfrit.

Når nye versioner er dårligere

Langt hovedparten af serverene blev flyttet over meget nemt og uden problemer.

Men der var to servere som drillede.

Den ene var en Linux-maskine med en web-server der fra tid til anden holdt op med at svare. Når man tjekkede servicen fra konsollen
så den ud til at køre, men cpu'en hang på 99 procent og web-serveren holdt efter et stykke tid op med at svare på forespørgelser.

I tilfælde af problemer havde vi inden starten på projektet besluttet at vi skulle beholde det gamle fysiske jern, så vi blot kunne starte serveren op igen i tilfælde af store problemer. Og det blev vi nødt til her.

Det viste sig at problemet med den nyere version af OS'et og web-serveren var kendt og desværre venter man stadig på en opdatering, der kan løse problemet.

Vi overvejede om vi kunne genstarte servicen periodisk, men af forskellige årsager ville det være en meget dårlig ide. Løsningen blev at vi alligevel gjorde serveren virtuel og satte en alarm på cpu'ens orbrug. Det giver os nemlig nok tid at få genstartet servicen inden den trækker serveren helt ned.

Glemte databaser

Et andet problem vi rendte ind i var en gammel database-server som vi også drifter. Her blev vi enige om at finde ud af hvilke databaser der rent faktisk skulle flyttes med over.

Efter flere ugers detektiv-arbejde af en af mine kollegaer viste det sig at vi rent faktisk kunne fjerne 2/3 af de databaser der lå på de to database-servere, der kørte på maskinen. Vi hoster de fleste af databaserne for andre og bruger derfor ikke meget tid på serverne i det daglige.

Den første database-server flyttede vi nemt over, men den anden udviklede sig til lidt af et mareridt.

For det første var der ingen i afdelingen der kendte til database-serveren. De folk, der i sin tid havde sat den op var for længst holdt op og dokumentationen var enten aldrig blevet skrevet eller også var den gået tabt på de evige digitale jagtmarker.

Flytningen af databasen gik galt og medførte et par hektiske dage hvor der ikke var rigtigt hul igennem til et par af databaserne.

Samtidig var der ingen der kendte databasens administrator password, hvilket gjorde det det svært at rette i de fejl der opstod undervejs. Passwordet blev i øvrigt senere gravet ud af nogle javascript på serveren.

Efter en uge med problemer gav vi op og i dag kører den sidste database-server derfor stadig på det fysiske jern.

Vi måtte nemlig melde ud at vi ikke kunne bruge mere tid på opgaven og den skulle enten gøres virtuel eller lukkes ned. Eller de kunne flytte den over på en af de databaser som vi har erfaring med.

Den afdeling vi hoster denne database for (og som selv satte den op i sin tid) er nu selv i gang med at opgradere deres kompetance så de selv kan flytte den over på den virtuelle database-server.

Men overordnet set er det faktisk gået nemmere at flytte de eksisterende servere end jeg havde regnet med.

Næste skridt bliver at kigge på at flytte de servere som vi i denne omgang sprang over. Det drejer sig om vores directory-service
og primære web-servere. Vi er i gang med at teste om det kan lade sig gøre og umiddelbart ser det rigtigt fornuftigt ud.

De eneste servere vi ikke overvejer at virtualisere er post-serverne. Serverne er nye (halvandet år) og det ville kræve en større udskrivning hvis vi skulle købe storage-hylder nok til at kunne smide posten ligeså hurtigt afsted som i dag.

Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Lars Hansen

Spændende indlæg.

Jeg håber du undervejs vil fortælle lidt mere om jeres overvejelser/erfaringer omkring emner som f.eks. fordele/ulemper mht. driftsstabilitet, muligheden for mere dynamisk at tildele ressourcer til de virtuelle servere og måske også om virtualisering betyder noget udenfor IT (dvs. om virtualisering betyder noget ift. bedre at kunne svare på opståede krav i forretningen)

  • 0
  • 0
#3 Klaus Agnoletti

Den vigtigste øvelse jeg kan se i har gjort jer - som i øvrigt ikke har så meget med selve virtualiseringen at gøre - er at i har været ALLE servere og services igennem, risikovurderet dem, og har så kun flyttet dem over der har nogen driftsmæssig betydning.. Og så antager jeg at i har haft travlt med at dokumentere de services i har flyttet over, så i ikke skal igennem det store detektivarbejde igen næste gang noget ikke virker?

Super spændende indlæg - fortæl endeligt mere :)

  • gerne omkring den mere sikkerheds-agtige del af det.. Har i fulgt nogle VMWare baselines? Hvordan sørger i for at patche hosts og guests?

/klaus

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