Vedlegg: Del III-1. Designdokument Versjon: 1.0

Vedlegg: Del III-1 Beredskapsløsning Designdokument Versjon: 1.0 27.01.2009

Innhold 1 INNLEDNING... 3 1.1 Forkortelser og begreper... 3 1.2 Formål... 3 1.3 Målgruppe... 3 1.4 Referansedokumentasjon... 3 1.5 Krav til løsningen... 4 1.5.1 Katastrofe... 4 1.5.2 Kritisk feil... 4 1.5.3 Kritiske systemer... 4 2 DESIGNSTRATEGI... 5 3 OVERORDNET DESIGN... 6 3.1 Logisk fremstilling... 6 3.2 Oversikt over tjenestene... 7 3.3 VMware... 8 3.4 Hvilke systemer skal virtualiseres... 9 3.5 SAN... 10 3.6 Replikering... 11 3.7 Backup... 12 3.8 Katastrofe-backup for servere... 13 3.8.1 Fysiske servere... 13 3.8.2 Virtuelle servere... 15 3.9 Nettverk... 17 3.9.1 WAN... 17 3.9.2 LAN... 17 3.9.3 Internett... 18 3.9.4 Hjemmekontor... 18 3.9.5 Brannmur... 18 3.9.6 Viruskontroll... 18 3.9.7 Sikkerhet... 18 3.10 Citrix... 19 3.11 Filserver... 20 3.11.1 Katastrofe... 20 3.11.2 Kritisk feil... 20 3.11.3 Skalering... 21 3.12 Databaser... 22 3.13 Exchange... 22 Designdokumentasjon Side 2 av 22 Forsvarsbygg

1 Innledning 1.1 Forkortelser og begreper Forkortelse Beskrivelse AD Active Directory AHF Alternativ datarom (sekundær site) DPM Microsoft System Center Data Protection Manager GWP Grev Wedels plass IR HP Data Protector Instant Recovery ISL Inter-switch link sammenkoblingen av til FC-switcher RDM Raw Device Mapping RPO Recovery Point Objective hvor mye data kan man miste RTO Recovery Time Objective hvor lenge kan en tjeneste være nede SAN Storage Area Network VCB VMware Consolidated Backup VLS HP StorageWorks Virtual Library System ZDB HP Data Protector Zero Downtime Backup 1.2 Formål Dette dokumentet gir en overordnet beskrivelse av hvordan et beredskapsmiljø skal etableres for Forsvarsbygg. Dokumentet er laget for å kunne gi et bilde og en bedre forståelse av hvordan det er planlagt at den fremtidige løsningen skal se ut. Dokumentet skal videre benyttes som underlag for planlegging og implementering av ny driftsløsning. Løsningsforslaget er basert på diskusjoner, ønsker og behov som er avdekket i de gjennomførte arbeidsmøtene i designprosjektet. I tillegg er det tatt hensyn til resultatet etter den gjennomførte virtualiseringsanalysen av dagens løsning. 1.3 Målgruppe Dokumentet er ment for Forsvarsbygg IKT og det er forventet at leseren har en generell teknisk forståelse. Dokumentet er også grunnlag for innhenting av tilbud på implementering av ny IKT driftsløsning i Forsvarsbygg. 1.4 Referansedokumentasjon Virtualiseringsanalyse med rapporter laget med VMware Capacity Planner er lagt til grunn ved vurdering av hvilke servere som kan virtualiseres. Designdokumentasjon Side 3 av 22 Forsvarsbygg

1.5 Krav til løsningen Løsningen skal sikre tilgjengelighet og recovery av systemer og data ved en katastrofe eller kritisk feil. 1.5.1 Katastrofe Feil på datarom eller infrastruktur som gjør at flere kritiske og viktige systemer ikke lenger fungerer. Eksempler på en slik feil kan være feil på lagringssystem, brann på datarommet eller bortfall av infrastruktur som strøm eller kjøling. Ved en katastrofe skal løsningen sikre at de kritiske og viktige systemene skal kunne reetableres i løpet av 24 timer. Samtidig skal løsningen sikre at minimalt med data går tapt. 1.5.2 Kritisk feil Feil på infrastruktur eller logiske feil på data, som gjør at et kritisk eller viktig system ikke lenger fungerer. Eksempler på en slik feil kan være en korrupt database, feil på en server eller filer som ved et uhell blir slettet. Ved en kritisk feil, skal løsningen sikre at de kritiske systemene skal kunne reetableres i løpet av 8 timer. De viktige systemene skal kunne reetableres i løpet av 24 timer. Ved logiske feil på data, skal løsningen sikre at det ikke forsvinner mer enn maksimalt 4 timer data for de kritiske systemene. For de viktige systemene skal løsningen sikre et maksimalt datatap på 24 timer. 1.5.3 Kritiske systemer Agresso, Summarum, MS Exchange og MS Office. Designdokumentasjon Side 4 av 22 Forsvarsbygg

2 Designstrategi Forenkle Sentralisere løsningen til ett sentralt, virtuelt datasenter. Virtualisere servere og konsolidere databaser for økt fleksibilitet og forenklet drift. Standardisere Standardisere maskinvare, både på server- og klientsiden. Benytte like servermodeller (f.eks. Blade-teknologi) og skalere horisontalt. Integrere Ett virtuelt datasenter (som er fordelt på to fysiske lokasjoner). En felles lagringsløsning. En felles og virtuell serverplattform. En felles databaseløsning. En felles katalogtjeneste. En felles driftsløsning. Modularisere Virtualisering av servere gjør serverne fristilte fra maskinvare. Horisontal skalering lettere å kontrollere ytelse. Automatisere Ha fokus på å automatisere flest mulig driftsoppgaver Forenkle nødvendige manuelle driftsoppgaver Designdokumentasjon Side 5 av 22 Forsvarsbygg

3 Overordnet design 3.1 Logisk fremstilling Figuren nedenfor viser en logisk fremstilling av Forsvarsbygg sin nye beredskapsløsning, med hovedkomponenter som fysiske servere, VMware, SAN, LAN og lagring. Løsningen består av to datarom: AHF og GWP. Datarom GWP benyttes til produksjon. Datarom AHF benyttes primært til test og utvikling. I tillegg vil det foregå en begrenset produksjon av kritiske infrastrukturtjenester som redundante domenekontrollere, firewall, Citrix-farm, DNS ol. Ved en katastrofe vil AHF benyttes til produksjon. Begge rommene skal bestykkes med like hardwarekomponenter. De to datarommene er knyttet sammen med dedikerte fiberlinker, slik at man på LAN og SAN siden ender opp med et logisk datarom. Beredskapsløsningen skal dokumenteres. Det skal kjøres beredskapstester av alle løsningene for høytilgjengelighet og recovery, helst så ofte som 2 ganger pr. år. Ved hjelp av disse testene, vil man få sjekket om løsningene fungerer som tiltenkt og dokumentasjonen blir kvalitetssikret. I tillegg vil løsningen bli revidert slik at løsningen til enhver tid fyller gjeldende krav. Designdokumentasjon Side 6 av 22 Forsvarsbygg

3.2 Oversikt over tjenestene Bildet nedenfor viser en logisk fremstilling av tjenestene i løsningen, hvor komponentene finnes og hvordan de to lokasjonene henger sammen. Hovedregelen i løsningen er at systemdisk og data replikeres i SAN til AHF, slik at tjenesten kan startes her ved en katastrofe. Virtuelle maskiner er filer i SANet (via. VMware sitt filsystem), som replikeres. De fysiske maskinene har systemdisken og eventuelle datadisker i SANet, som sørger for replikering til AHF. Noen viktige tjenester som f.eks. domenekontrollere og Citrix farmen, er representert i begge datarommene. Designdokumentasjon Side 7 av 22 Forsvarsbygg

3.3 VMware Virtualisering med VMware benyttes i størst mulig utstrekning for å sikre en enkel, forutsigbar og enhetlig recovery. Bildet nedenfor viser den overordnede oppbygging av VMware miljøet på serversiden. Administrasjon av VMware-miljøet gjøres av ved hjelp av VMware VirtualCenter. For å sikre redundans implementeres to VirtualCenter servere, en for produksjonsmiljøet og en for testmiljøet. VirtualCenter er implementert som en virtuell maskin. Bakgrunnen for dette er at tjenesten da kan sikres på samme måten som de andre virtuelle maskinene (ved hjelp av VMotion, VMware HA og snapshot). Designdokumentasjon Side 8 av 22 Forsvarsbygg

3.4 Hvilke systemer skal virtualiseres Her er listen over alle serverne i dagens miljø. Maskinene som er planlagt virtualisert i første runde, er merket med Ja i kolonne 3. Servernavn Funksjon Virtualiseres Kommentar BZT-H-AHF-01 BizTalk 2004 Nei Integrasjonsserver. BizTalk og WebServices Kritisk. DBS-S-AHF-01 Oracle 9.2 (7 databaser) Nei Skal fases ut DBS-S-AHF-05 Testserver Ja Tjeneste-/WEB-server Agresso TEST DBS-S-AHF-08 Oracle 9.2 (Agresso TEST) Ja OK DBS-S-AHF-09 Agresso 5.45 tjenesteserver Nei Tjeneste-server Agresso Prod INTRANETT Oracle Applications Ja Web-tjeneste og Web-cache for intranettet SRV-APP-01 Tjenester. Ja Diverse tjenester. ArcSDE service, ArcGIS lisensserver (dongel) SRV-APP-02 BizTalk 2006 R2 Ja Efaktura, Ehandel. Biztalk tjenesteserver srv-app-50 TEST-tjenester Ja ArcIMS TEST (kartinnsyn WEB) SRV-APP-51 BizTalk 2004 TEST Ja Biztalk Test-server (tjeneste/db) SRV-APP-66 Agresso 5.5 tjenester Nei Agresso 5.5 Tjenesteserver SRV-APP-90 SCOM 2007, EM10g Ja Server for overvåkningstjenester SRV-APP-91 SCCM 2007 Ja Utrulling av client-images SRV-APP-95 Citrix Licensing + VMWare server Ja Håkon sin. SRV-APP-96 IKT diverse Ja Colorgate (dongel) srv-app-98 WSUS Ja srv-app-99 Norman AV oppdateringer Ja SRV-DBS-01 Oracle 9.2 Nei DocuLive PROD+KURS, GIS, ProArc SRV-DBS-02 Oracle 10g Nei Agresso SRV-DBS-03 MSSQL2000+2005 Ja Infomaker database SRV-DBS-04 MSSQL 2005 Ja Skal bli hovedserver for MSSQL2005 databaser. srv-dbs-50 MSSQL2000 Ja Infomaker TEST SRV-DBS-51 MSSQL2000+2005 Ja BizTalk 2004 TEST + Agr Staging SRV-DBS-64 Oracle 10g Nei Skal fases ut i 2009. Agresso 5.45 PROD SRV-DBS-65 Oracle 10g Nei Ny fysisk server. Skal bli hovedserver for Oracle databaser SRV-DBS-66 Oracle 10g Nei Ny fysisk server. Agresso 5.5 TEST SRV-DHC-01 DHCP server Ja SRV-DOM-01 Domenekontroller Ja SRV-DOM-02 Domenekontroller Ja SRV-EXC-01 Exchange 2003 Ja OK ved redesign av løsningen SRV-FIL-02 Filserver Ja OK ved innføring av arkivering SRV-IMS-01 Spamfilter Ja SRV-MGR-02 IKT management Ja Til eget bruk. Lars sin. SRV-PRN-01 Printerdrivere Ja SRV-PRN-02 Printerdrivere Ja SRV-WEB-01 Webserver Ja DocuLive, ProArc (dongel?), Infomaker SRV-WEB-02 Webserver Ja Agresso 5.45 PROD SRV-WEB-03 Webserver Ja TidBank, ArcIMS PROD (kartinnsyn WEB) SRV-WEB-04 Agresso 5.5 WEB-server Ja TID-H-AHF-01 HP OpenView Ja Servicedesk VPT-H-AHF-01 Webserver Ja ViewPoint, Micromarc, SalesOffice Designdokumentasjon Side 9 av 22 Forsvarsbygg

3.5 SAN Så langt dette er mulig skal alle servere være koblet inn i SANet. For å unngå at feil i SANet skaper problemer for serverne, er det satt opp to helt separate SAN. Alle servere og lagringssystemer er koblet til begge disse SANene for å sikre redundans. De to datarommene i løsningen (GWP og AHF) sammenkobles med fire fiberpar (2 til LAN og 2 til SAN). Disse forbindelsene bør helst benytte forskjellige traseer mellom datarommene, dette for å sikre at det fortsatt er forbindelse selv om det skulle oppstå linjefeil (for eksempel forårsaket av et graveuhell). Med fiberforbindelse mellom datarommene vil man i praksis knytte sammen GWP og AHF til ett logisk datarom, dette forenkler administrasjon. Man oppnår blant annet å kunne knytte sammen datarommene til ett IP-subnet. Det settes opp to SAN kjerne-switcher på hver lokasjon. Til disse kobles lagringssystemene og eventuelle gjenværende rack-servere. I blade-hyllene monteres det to SAN kant-switcher. Disse kobles sammen med kjerne-switchene med nødvendige ISLer. Blade hylla blir som en nøkkelferdig modul, ferdig utstyrt med all nødvendig infrastruktur (servere, SAN og LAN). Designdokumentasjon Side 10 av 22 Forsvarsbygg

3.6 Replikering Alle volum som inneholder primærdata, replikeres mellom de to disksystemene. På grunn av den korte avstanden mellom datarommene, vil det benyttes synkron replikering. Dette sikrer at man ikke mister noe data ved en katastrofe. Synkron replikering fungerer slik: Hvis det ikke er kontakt mellom disksystemene vil endringer journalføres. Det er viktig at det settes av relevant plass til dette i disksystemet. Konsistensgrupper benyttes for å sikre konsistens for volum som har et avhengighetsforhold (for eksempel loggdisken og datadiskene til en database). Det er viktig til enhver tid å vite status på replikeringen, derfor må alarmer og status overvåkes. Designdokumentasjon Side 11 av 22 Forsvarsbygg

3.7 Backup Backup gjøres til VLS, i etterkant (på dagtid) vil disse jobbene klones til tape i biblioteket. VLS vil stå i datarom AHF og tapebiblioteket står i datarom GWP. Serveren med Data Protector vil ha systemdisken sin i SANet. Den blir da beskyttet av replikering og snapshot. Det installeres Data Protector databaseagenter på hver databaseserver. Data Protector vil ha ansvaret for, ved hjelp av sin databaseagent, å sikre konsistent backup av databasene. Recovery av data gjøres også ved hjelp av databaseagenten til Data Protector. Det kjøres backup av kritiske systemer hver 4 time. Av de andre systemene kjøres det backup hver natt. Primært vil all backup gjøres via LAN. For Exchange skal det evalueres bruk av snapshot for backup. Filserveren har så store datavolum at det implementeres snapshot-backup av disse. Dette gjøres ved hjelp av Data Protector ZDB og IR. En forutsetning er at neste versjon av Data Protector (ver. 6.1) blir tilgjengelig innen rimelig tid og at den har støtte for IR med bruk av snapshot. Hvis denne støtten ikke kommer, vil HP StorageWorks Replication Solutions Manager benyttes som et alternativ. Dette verktøyet er gratis og vil gi tilsvarende funksjonalitet som Data Protector. Det er støtte for deduplisering i VLS, noe som vil komprimere data opp til 40 ganger. Det er derfor viktig at dette systemet settes i produksjon så fort som mulig, slik at man kan se hvilken komprimering man i praksis oppnår. Designdokumentasjon Side 12 av 22 Forsvarsbygg

Størrelsen på dagens VLS er 9TB, dette er mest sannsynlig for lite. På det nåværende tidspunkt, ser det ut som om diskplassen i VLSen bør dobles. Avgjørelsen på en slik utvidelse gjøres etter at dagens VLS er satt i produksjon og man har sett resultatet av dedupliseringen. 3.8 Katastrofe-backup for servere Dette kapitlet beskriver anbefalt katastrofeløsning for servere (fysiske og virtuelle). En server er her definert som hardware, operativsystem og installerte applikasjoner. Løsningen beskytter servere mot fysiske feil på hardware og logiske feil i operativsystem og applikasjoner. Løsningen er ikke ment som en optimal løsning for sikring av logiske feil på data, selv om den, spesielt for servere med små datamengder, også kan gjøre dette. Logiske feil på data beskyttes av backup med Data Protector. 3.8.1 Fysiske servere 3.8.1.1 Fysisk feil fysisk server Alle fysiske servere skal om mulig ha systemdisken i SANet. Dette vil medføre at også denne (i tillegg til datadisken), blir replikert mellom de to datarommene. I praksis vil man alltid ha en oppdatert kopi av maskinen i begge datarommene. Det settes opp like servere i datarom AHF, som ved en normalsituasjon benyttes til test. Ved en katastrofe vil disse starte på den replikerte produksjonssystemdisken. Normalsituasjon Katastrofe Alle kritiske komponenter som for eksempel power, disk, HBA osv. skal være redundante. Designdokumentasjon Side 13 av 22 Forsvarsbygg

3.8.1.2 Logisk feil fysisk server En logisk feil på en fysisk server kan for eksempel være at operativsystemet ikke lenger starter eller at applikasjonen som er installert ikke lenger fungerer. For å sikre mot slike feil, lages det snapshot av systemdisken i EVA før endringer i OS eller applikasjonen implementeres. Backup Recovery For de maskinene som har systemdisken i SANet, vil det være meget enkelt å gjennomføre realistiske tester. Man lager snapshot av de replikerte system- og datadiskene og starter en testserver (Server-TEST) på disse kopiene. Man oppnår da en nøyaktig kopi av produksjonssystemet og kan gjennomføre realistiske tester på dette systemet. Designdokumentasjon Side 14 av 22 Forsvarsbygg

3.8.2 Virtuelle servere 3.8.2.1 Fysisk feil virtuelle servere Siden alle VMDK filene (som inneholder operativsystemet, applikasjonene og data) ligger i SANet, blir disse replikert mellom de to datarommene. I praksis vil man alltid da ha en oppdatert kopi av alle de virtuelle maskinene tilstede i begge datarommene. Denne konfigurasjonen vil, ved en normalsituasjon, se ut som figuren under. VMware HA vil beskytte mot feil på en ESX-server (se figuren under). Designdokumentasjon Side 15 av 22 Forsvarsbygg

Ved en katastrofe vil ESX-serverne i datarom AHF få tilgang til de replikerte VMFS volumene og kunne starte de virtuelle maskinene (se figuren under). ESX-serverne i datarom AHF brukes vanligvis til test. Disse virtuelle testmaskinene vil ved en katastrofe måtte skrus av. 3.8.2.2 Logiske feil virtuelle servere En logisk feil på en virtuell server kan for eksempel være at operativsystemet ikke lenger starter eller at applikasjonen som er installert ikke lenger fungerer. De virtuelle maskinene er i praksis filer, det betyr at hvis man har en backup av disse filene, vil en recovery bestå av å kopiere tilbake denne kopien. Backup av de virtuelle diskfilene skal gjøres ved hjelp av VMware Consolidated Backup. Til å administrere en slik backup, skal det benyttes Data Protector eller et annet egnet spesialverktøy. Valg av verktøy gjøres senere. Backup Recovery Designdokumentasjon Side 16 av 22 Forsvarsbygg

3.9 Nettverk 3.9.1 WAN Egen node i Nordicom-nettet for sekundær site. Telenor må rute om ved behov. InterLAN knyttes opp med egen fiber fra bygning AHF 66 til bygning AHF xx. Egen switch settes opp på sekundær site. 3.9.2 LAN Minimum 3 stk. fiber mellom GWP og AHF (sekundær site). Fiber 1: Vanlig LAN-trafikk Fiber 2: SAN-replikering Fiber 3: SAN-replikering Fiber 4: LAN redundans (hvis mulig) Se figuren under for en konseptuel tegning av LANet Alle servere kobles inn i LANet med to nettverkskort som bindes sammen med NIC teaming. Blade serverne kobles til kant-switcher i blade hyllene, mens rack servere kobles direkte til begge kjerne-switchene. Kjerne-switchene på hver lokasjon er koblet sammen. I tillegg er det fiberlinker mellom de to datarommene som kobler kjerne-switchene sammen til ett LAN. Designdokumentasjon Side 17 av 22 Forsvarsbygg

3.9.3 Internett HSRP (Hot Standby Router Protocol). Sekundær ruter tar over internettrafikken autometisk ved avbrudd på primær site. Virussjekk på internettrafikk (http og ftp) kjøres på CSG serveren. Kan være aktiv samtidig på begge siter. 3.9.4 Hjemmekontor Egen CSG server i DMZ på sekundær site. Konfigureres via konfigureringsfiler i SAN. Egen RSA-server på sekundær site. 3.9.5 Brannmur Egen firewall på sekundær site som ved en normalsituasjon er passiv. Ved en katastrofe vil denne manuelt aktiveres. 3.9.6 Viruskontroll Trend/Norman antivirus er installert i en virtuell maskin. Denne beskyttes som de andre virtuelle maskinene ved en katastrofe. 3.9.7 Sikkerhet Må vurdere annen løsning for e-post. F.eks tjenesten levert av Telenor. Virusprogramvare og kontroll av brannmur. Er ikke en del av denne løsningen, men kjøres som eget prosjekt. Designdokumentasjon Side 18 av 22 Forsvarsbygg

3.10 Citrix Hovedfarmen fordeles på begge lokasjonene med litt over 50% kapasitet på hver. Bildet nedenfor viser en skjematisk tegning over en mulig Citrix-løsning. De nødvendige Microsoft-tjenestene som for eksempel AD, DNS og TS Lisensservere er implementert som virtuelle maskiner og er tilgjengelige i begge datarom. XenApp hovedfarmen er implementert som fysiske maskiner og er fordelt mellom datarommene. Eventuelle XenApp spesialfarmer og andre Citrix tjenster som Data Store, XML Broker (Data Collector), Web Interface, Citrix Lisensserver implementeres som virtuelle maskiner. Disse virtuelle maskinene er aktive i datarom GWP ved en normalsituasjon. Ved en katastrofe vil disse tjenestene feiles over til AHF på samme måte som andre virtuelle maskiner. Ved en katastrofe vil ikke lenger XenApp løsningen kunne betjene brukere, da XML Brokeren og Web Interface tjenestene vil forsvinne. Etter en feilover til AHF vil disse tjenestene starte på nytt og XenApp farmen kan igjen betjene brukerne. Ønsker man en mer online løsning, vil man kunne oppnå dette ved å implementere en Citrix NetScaler-løsning, som blant annet vil innføre mulighet for lastballansering av flere Web Interface servere. Citrix miljøet er også avhengig av filserveren. Denne er også implementert som en virtuell maskin og vil feiles over ved en katastrofe. Designdokumentasjon Side 19 av 22 Forsvarsbygg

3.11 Filserver Filserveren til Forsvarsbygg er relativt stor, det er derfor viktig at dataene på denne sikres godt og at recovery-planen er godt dokumentert og testet. Filserveren er implementert som en virtuell maskin og både data og systemdisker ligger i SANet som er speilet mellom datarommene. Datadiskene er implementert som en RDM disk i VMware (det vil si at den virtuelle maskinen snakker direkte med det rå diskvolumet i SANet). Det er valgt å gjøre det på denne måten på grunn av det store volumet med data, da dette forenkler migreringsjobben (både inn og ev. ut av VMware). 3.11.1 Katastrofe Filserveren er replikert mellom de to disksystemene (systemdisk og datadisker). Ved en katastrofe kan denne derfor enkelt startes opp i datarom AHF. Normalsituasjon Etter failover ved en fysisk feil. 3.11.2 Kritisk feil Datadisken til filserveren beskyttes ved hjelp av snapshot i EVA. Disse snapshotene administreres ved hjelp av Data Protector ZDB og IR. Ved feil vil man kunne sette disken tilbake til den status den hadde ved det tidspunktet man tok det aktuelle snapshotet. Designdokumentasjon Side 20 av 22 Forsvarsbygg

3.11.2.1 Enkel bruker-recovery av filer Shadow Copies for Shared Folders enables, og det reserveres 10 % plass til dette i filsystemet. Dette vil gjøre det mulig for brukere selv å kunne administrere recovery av filer. 3.11.3 Skalering Det skal vurderes om filserveren skal deles opp i flere mindre filservere. En slik oppdeling vil sikre god nok skalering på serversiden fremover. Denne oppdelingen gjøres samtidig med overgangen til filservere basert på Windows Server 2008. Denne oppdelingen til flere filservere vil være transparent fra et brukerperspektiv (ved hjelp av logon-script). På lengre sikt vil det bli behov for å innføre en arkiveringsløsning for filserveren, dette for å kunne møte enda større fremtidig lagringsbehov. Arkivering på filserveren gjøres eventuelt senere, hvis arkivering på Exchange blir en suksess. Designdokumentasjon Side 21 av 22 Forsvarsbygg

3.12 Databaser Primært vil databaser bli tatt backup av (via. LAN) ved å benytte Data Protector sine databaseagenter. For databaseservere som har mye data (mer enn 1-300 GB) eller trenger en meget kort recovery-tid (mindre enn 1 time), kan det benyttes backup ved hjelp av snapshot. Det vil være fordelaktig hvis man kan benytte Data Protector ZDB og IR til å automatisere dette. 3.13 Exchange Dagens Exchange 2003 miljø skal konverteres til Exchange 2007. Dette miljøet er planlagt implementert som virtuelle maskiner. Dagens miljø består av en Exchange 2003 server til alle brukerne. I det nye miljøet er det planlagt å fordele brukerne på minimum 2 Exchange 2007 servere. Hovedgrunnen til å implementere det nye Exchange miljøet som virtuelle maskiner, er at de kan inkluderes i samme recovery-løsning som de andre virtuelle maskinene nyter godt av. Dette betyr at Exchange serverne med system, applikasjon og data blir replikert til AHF og ved en katastrofe kan de startes her. Det skal implementeres en arkiveringsløsning for Exchange. Dette vil gjøre Exchange databasene mindre og dermed lette recovery. Arkiveringsløsningen som skal benyttes er Symantec Enterprise Vault. Exchange må også beskyttes mot logiske feil. Dette kan gjøres ved bruk av DataProtector sin Exchange agent, som vil ta en tradisjonell backup av Exchange. Dette vil være den anbefalte backup-metoden så lenge recovery, av en slik backup, møter kravene til RTO. Hvis man trenger raskere recovery, vil man kunne benytte DataProtector sin ZDB og IR funksjonalitet, når dette støtten er på plass i 2009. Hvis integrasjonen med ZDB og IR ikke gir ønsket funksjonalitet eller denne støtten ikke kommer på plass fort nok, vil et annet godt alternativ være å benytte Microsoft sin DPM. Denne er meget godt integrert med Exchange og løsningen vil gi en meget enkel og grei recovery og vil kunne møte et RPOkrav helt ned til 15 minutter. Designdokumentasjon Side 22 av 22 Forsvarsbygg