Sådan kan du spare på database-drift og -licenser

"Vi havde meget store omkostninger forbundet med driften af serverne. Både licensmæssigt og til det løbende vedligeholdelsesarbejde."

If Forsikring havde omkring 200 databaseservere kørende i organisationen.

Mange af dem var ældre SQL Server-versioner, der kørte på forskellige Windows-versioner; nogle så gamle som Windows 2000.

Det store antal fysiske maskiner med tilhørende software krævede meget vedligeholdelsesarbejde i form af opdateringer og lignende, ligesom licensudgifterne til softwaren var store.
Efter et renoveringsprojekt blev udgifter til licenser og operationelle omkostninger i forbindelse med databaserne reduceret med 80 procent.

If Forsikrings projektleder Johan Bernalt fortæller sammen med SQL Server-eksperten Raoul Ilyés fra Guideline over de næste par dage, hvordan If Forsikring sparer millioner ved at konsolidere de 200 databaseservere på et par håndfulde fysiske maskiner.

Grundig forberedelse
"Vi startede tilbage i maj 2009. Forberedelserne stod vi selv for og så hentede vi ekstern ekspertise fra Guideline, Miracle og Tieto ind for at hjælpe med det tekniske, da vi ikke havde den specialiserede ekspert-viden in-house," beretter Johan Bernalt, der fremhæver vigtigheden af, at få lavet et godt forarbejde inden man kaster sig ud i den mere teknisk specialiserede del af et konsolideringsprojekt. Med 200 databaseservere, der tilsammen rummede omkring 4000 databaser, var der da også tale om et stort koordinerings- og planlægnings-arbejde.

"Som regel er det lidt af et opklaringsarbejde at finde ud af, hvem der ejer databasen, hvem der anvender databasen og hvilke applikationer, der trækker på databasen. Det er ikke enkelt at holde styr på, hvordan det hele hænger sammen," siger Johan Bernalt.

If Forsikring gjorde derfor et stort forarbejde med at opbygge et inventory, der gav et overblik over alle If Forsikrings databaser og tilhørende systemer.

"Inventory er meget vigtigt at få etableret i starten for at få et overblik og klassificere databaserne. Det gælder om at knytte databaserne til systemerne og finde systemejerne," siger Johan Bernalt.

Brikkerne samles til et planlægningspuslespil
Da alle systemejerne var identificeret, startede et større planlægningspuslespil. Konsolidering af databaser til et databasehotel vil nemlig uundgåeligt medføre nedetid for systemer, hvilket systemejere helst vil undgå.

"Det var en udfordring at sammensætte den samlede plan, så den passede alle. Hvis der eksempelvis var 10 applikationer, der anvendte en database, så skulle det koordineres med alle 10 systemejere," forklarer Johan Bernalt.

For at få konsolideringsarbejdet til at glide lettere ned hos systemejerne, udarbejdede Johan Bernalts gruppe en lille manual, der forklarede, hvad konsolideringsprojektet indebar og hvilke fordele, det ville give systemejerne.

"Vi etablerede et framework og skrev en lille bibel - en manual - der beskrev, hvordan en database kører på den nye platform. Det var gjort meget operationelt. Det var vigtigt at gøre det meget klart, hvilken betydning det ville få for systemerne, at databaserne blev flyttet til et databasehotel," siger Johan Bernalt.