Statens It standard driftsplatform Beskrivelsen af datacenter kapaciteter og standarder 12. august 2011
Indhold 1 Indledning 3 1.1 Versionshistorik 3 2 Statens It s datacenter grundlæggende arkitektur 5 2.1 Baggrund 5 2.2 Datacenter - netværksinfrastruktur 5 2.2.1 Firewall kapacitet 6 2.2.2 Principtegning 7 2.3 Serverhosts 8 2.4 Storagesystemer 8 3 Standarder for serverkonfigurationer og basisprogrammel 9 3.1 Serverkonfigurationer 9 3.2 Basisprogrammel 10 3.3 Backuppolitik 10 4 Applikationsdrift standarder og snitflader 14 4.1 Installationsmodel 15 4.2 Standard applikationsprogrammel 16
1 Indledning 12. august 2011 Version 1.0 Dette dokument beskriver arkitekturen i Statens It s datacenter samt de specifikke standarder for basisprogrammel, kapaciteter og driftsprocedurer. Formålet med dokumentet er at tilvejebringe kunderne og deres udviklingsleverandører nødvendige informationer om Statens It s standarder for it-drift bl.a. til brug for udvikling af nye fagapplikationer. Dokumentet er et supplement til beskrivelserne i aftalekomplekset mellem kunderne og Statens It, herunder i servicekatalog. Fremadrettet vil de i dokumentet og i aftalekomplekset indeholdte standarder, som udgangspunkt, udstikke de driftsmæssige rammer for kundernes udviklingsprojekter både i forbindelse med nyudvikling af systemer og i forbindelse med større omlægninger af eksisterende systemer. Der er dog ikke tale om ufravigelig krav, idet der i helt særlige tilfælde kan være saglige argumenter for at fravige standarderne. Ønsker om afvigelse fra standard skal aftales med Statens it i regi af den almindelige samarbejdsorganisation. Dokumentet vil løbende blive udvidet og revideret - dels fordi den tekniske udvikling med tiden stiller nye krav til kapacitet og produkter, dels fordi der er områder, der endnu ikke er beskrevet i dokumentet - det gælder fx AD, Exchange og Citrix. 1.1 Versionshistorik Nedenstående tabel indeholder oplysninger om versioner af dokumentet Version Ansvarlig Dato Beskrivelse 1.0 OL 12-08-2011 Dokument udsendt i første version
2 Statens It s datacenter grundlæggende arkitektur I dette kapitel beskrives konceptuelt den grundlæggende arkitektur i Statens It s datacenter. Kapitlet har 4 afsnit baggrund, netværk, serverplatform og storage 2.1 Baggrund Statens It blev dannet 1. januar 2010 med henblik på at skabe fundamentet for den videre digitalisering af staten samt at samle driften af ministerområdernes it og derved skabe stordriftsfordele ved sammenlægning, standardisering og harmonisering. Statens It s mission er at drive og udvikle statens fælles itløsninger effektivt og professionelt og skabe fundament for den videre digitalisering af staten I dag servicerer Statens It 8 ministerområder, og Statens It implementerer i den forbindelse et datacenter med 3 lokationer. De 2 lokationer bruges til serverdrift og lagerkapacitet, og den 3. til backup af data. Lokationerne er placeret centralt beliggende i København, og er netværksmæssigt forbundet via sort fiber. De to lokationer til drift af server- og lagerkapacitet er koblet sammen med henblik på sikkerhed, skalerbarhed, stabilitet og tilgængelighed. Et af formålene med etablering af datacentret har blandt andet været konsolidering af serverrum placeret hos Statens It s kunder. Datacentret skal sikre kundernes tilgængelighed af services, skabe vedvarende sikker og stabil drift efter behov 24 timer i døgnet, 7 dage om ugen, 365 dage om året. 2.2 Datacenter - netværksinfrastruktur WAN Core niveau Alle eksterne forbindelser foregår via WAN Core niveau. Interne kunder tilgår datacentret via Statens It s lukkede kundenet baseret på redundante 10Gbit MPLS forbindelser. Forbindelser mellem Statens It s primære lokationer er baseret på n * 10 Gbit på sort fiber. Forbindelse mellem Statens It s 2 primære lokationer og backupcenteret er baseret på n * 10 Gbit på sort fiber. Eksterne leverandører kan få adgang via VPN-forbindelser. Internetbaserede services er placeret på DMZ-net. Internetadgang er for Statens It s kunder baseret på redundante 10Gbit forbindelser.
DC Core-, Distribution- og Accessniveau Princippet i opbygningen er, at Accessniveauet er bestykket med mange switches, hvortil servere er opkoblet. Hver fysisk server koblet til netværket med redundant tilslutning, enten 10 Gbit fiber eller 100/1000 Mbit Ethernet. Accessniveauet aggregeres i et Distributionsniveau, som i princippet kun samler det underliggende Access niveau. Distributionsniveauet kan udvides i takt med, at Accessniveauet udvides med antallet af servere og switche. Distributionsniveauet er samlet i et DC Core niveau, som vil være relativt statisk i forhold til antal porte, men kapacitetsudvidelse kan udføres efter behov. De to lokationer i datacentret er netværksmæssigt bygget op med fuld redundans på alle komponenter, og er baseret på princippet aktiv/aktiv, hvor alt udstyr er en aktiv del af netværket, med henblik på udnyttelse af kapacitet og tilgængelighed i netværket. 2.2.1 Firewall kapacitet Nedenstående tabel viser antallet af firewall porte, deres kapacitet og det data throughput hver firewall kan levere. Netværkslag Antal porte, samt hastigheder og throughput der skal leveres Formål med port WAN Core Internet 2*10 Gb/s Forbindelse mod internet (ISP) WAN Core- kundeadgang 2*10 Gb/s Forbindelse til MPLS WAN Core- internet 1 * 10 Gb/s Forbindelse til Backup Center Firewall VPN 4*10 Gb/s Forbindelse mod WAN Coreinternet Firewall Internet 4*10 Gb/s Forbindelse mod WAN Core internet Firewall kundeadgang 4*10Gb/s Forbindelse mod WAN Core kundeadgang WAN Core internet 2 * 1000Mb/s Forbindelse til Content Filter løsning WAN Core- internet 6*10 Gb/s Forbindelse til andet driftscenter WAN Core 10 Gb/s mod DC Core - oversubscription max 2:1
Netværkslag DC Core Antal porte, samt hastigheder og throughput der skal leveres 10 Gb/s porte mod Distribution oversubscription max 4:1 Distribution 10 Gb/s porte mod Access oversubscription max 8:1 Access 96 10Gb/s porte, baseret på SFP+ Twinax (DAC) Formål med port Opkobling af blade server miljø 3 blade enclosures med hver 32 10Gb/s porte Access 150 100/1000 Mb/s porte Opkobling af legacy server WAN Core - Backupcenter WAN Core Backupcenter Ovenstående er pr. lokation i datacentret 16 100/1000 Mb/s porte 16 10Gb/s porte 2.2.2 Principtegning Denne principtegningviser, hvorledes corenetværket er etableret L1 KUNDER MPLS L3 (L2) Leverandør & partner net leverandør@ intern@ @ ISP L3 (L2) Borgervendte @-services IPv4 & IPv6 Leverandør & partnernet leverandør@ intern@ @ ISP Borgervendte @-services IPv4 & IPv6 VPN FW @ FW VPN FW @ FW L3 (L2) FW FW FW FW FW FW FW FW KUNDER MPLS L3 (L2) L2 Kunde FW FW FW WAN CORE WAN CORE L2/L3 WAN CORE WAN CORE Kunde FW FW FW DC CORE LAG Layer3 Layer2 DC CORE LAG Layer3 Layer2 DISTR.LAG Layer2 DISTR.LAG Layer2 ACCESS LAG Layer2 Rack Blade (TopOfRack-EndOfRow) Passthrough etc. L2 LOOP-frit ACCESS LAG Layer2 Rack Blade (TopOfRack-EndOfRow) Passthrough etc. L2-L3 SWITCH L2-L3 SWITCH Tunnel/Kryptering L2 LOOP-frit SAN/BACKUP MILJØ BACKUPCENTER SIT-DC Overview.vsd
2.3 Serverhosts Statens It anvender som standard, virtuelle servere og har etableret en solid og driftssikker virtuel serverplatform. Der er på hver af datacentrets to lokationer placeret 32 stk. HP BL465c G7 blade servere med hver 2 stk 12 core CPU, 256GB ram, 2 x 8Gbit Fibre Channel Host Bus Adapter og interne RAID 1 diske. Serverne er jævnt fordelt i 6 stk. HP c7000 blade enclosure, som er administrationsmæssigt koblet sammen. Hvert enclosures er tilført 2 x 8Gbit 24 ports SAN switch - 16 interne og 8 eksterne, 2 x 10GbE Pass-Through moduler og 32 x bladesystem 10 Gbit LR SFP+ kabler 2.4 Storagesystemer Statens It konsoliderer løbende SAN systemer fra de ministerområder, som indgår i Statens It. For at sikre en stabil og effektiv drift og administration af disse SAN systemer, har Statens It anskaffet en SAN virtualiseringsløsning, således at SAN systemer af forskelligt fabrikat fremstår som ét samlet SAN. SAN virtualiseringsløsningen understøtter anvendelsen af synkron replikering mellem SAN på lokationerne i datacentret, deduplikering på SAN niveau, automatisk path fail-over, thin provisioning, automatisk tiering, klonteknologier som fx snapshot og image samt krypteringsfaciliteter.
3 Standarder for serverkonfigurationer og basisprogrammel 3.1 Serverkonfigurationer Statens It anvender som standard, virtuelle servere til applikations- og webservere, mens der som standard anvendes en konsolideret databaseplatform, hvor der oprettes databaseimages. Fysiske servere oprettes kun på baggrund af særlige behov. Serverkonfigurationsområde Standard CPU Der anvendes CPU med 2,2 GHz processorer og en virtuel server tildeles som standard 1 CPU. Ved særlige behov kan mere end 1 CPU anvendes. RAM Servere oprettes som standard med 4 GB RAM, og dette kan udvides efter behov. Disk drev Det etableres diskdrev som beskrevet i nedenstående tabel som kan variere efter serverens anvendelse dog vil drev C, D, E, F og H altid blive oprettet. Der oprettes på forespørgsel drev i henhold til aktuelle behov, idet et drev dog af hensyn til restoretider som som standard kan tildeles 500 GB storage. Et drev kan maksimalt tildeles 2000 GB storage.. Drev Anvendes til Raid Størrelse (Gb) Cluster Allocation Units C: OS 1 40 GB 8Kb D: Virtuelt CD-ROM E: Applikation 1 30 GB 8Kb F: OS Swap 0 Memory * 2,5 4Kb G: Database Data 5 Variabel (5GB) 64Kb H: Reserveret virtuel USB K: Database Log 1 Variabel (5GB) 64Kb L: Database SystemDB 5 Variabel (2GB) 64Kb M: Database SystemDB Log 1 Variabel (2GB) 64Kb T: Database TempDB data CPU1 0 Variabel (2GB) 64Kb U: Database TempDB data CPU2 0 Variabel (2GB) 64Kb V: Database TempDB data CPU3 0 Variabel (2GB) 64Kb X: Database TempDB data CPU4 0 Variabel (2GB) 64Kb Y: Database TempDB Log 0 Variabel (2GB) 64Kb
3.2 Basisprogrammel Statens It anvender nedenstående basisprogrammel. Basisprogrammel Standard Operativsystem Som standard anvendes Windowsserver 2008 R2 eller Linux Redhat version 5 Backup Der anvendes TSM version 6.2 Overvågning Basisovervågningen består af: Pingtester for hver 600 sek. og sender alarm efter 5 fejl Disk måles for hver 600 sek. og sender alarm efter 6 fejl, threshold warning 95 % og threshold full 98 % Antivirus På fysiske servere anvendes F-Secure og på virtuelle servere anvendes TrendMicro Software Statens It anvender SCCM til distribution af software. Software og installation applikationsprogrammel forventes derfor leveret i format (MSI) så scriptet installation med SCCM kan foretages ensartet i alle miljøer. Patch Management Til installation af sikkerheds- og funktionspatche anvendes SCCM. Installation af sikkerhedspatche vil som standard blive foretaget i førstkommende ordinære servicevindue efter frigivelse fra leverandøren. Funktionelle patche vil blive installeret i forbindelse med fejlsager eller i først kommende ordinære servicevindue efter beslutning om installation. For Linux Redhat servere gælder dog, at rolling patches installeres løbende. Ordinære servicevinduer er beskrevet i afsnit 4. 3.3 Backuppolitik Politikken beskriver Statens It s baseline for backup afvikling for systemerne i datacenteret. Statens It tilbyder at gemme nogle backups længere eller foretage dem oftere, men det er forbundet med en ekstra omkostning, som beregnes på baggrund af den ønskede backuppolitik og oplyses forud for implementeringen. Backuppolitikken tager udgangspunkt i anvendelsen af Tivoli Storage Manager.
BACKUP OMRÅDE Server virtuel BASELINE BACKUP Backup af VMDK image Daglig Gemmes 45 dage DATATAB (RPO) RESTORE (RTO) RPO: Op til 24 timers datatab RTO: Restore cirka 40GB/time RESTORE/RECOVERY Det vil være muligt at restore en virtuel server (OS) tilbage til en tidligere version, såfremt den er blevet ødelagt. Dette gøres ved hjælp af VMware image backups eller TSM VE. Applikationsdata på serveren gemmes ikke i denne backuptype. Hvis der er specielle data, skal der køres separat backup af disse data (kræver evt. TSM BA eller TSM TDP installation) Server fysisk Backup af server system image Daglig Gemmes 45 dage RPO: Op til 24 timers datatab RTO: Restore cirka 40 GB/time Det vil være muligt at restore en fysisk server tilbage til en tidligere version, såfremt den er blevet ødelagt. Dette gøres ved hjælp af en traditionel image backup. Applikationsdata på serveren gemmes ikke i denne backup type. Hvis der er specielle data, skal der køres separat backup af disse data (kræver evt. TSM TDP installation)
BACKUP OMRÅDE BASELINE BACKUP DATATAB (RPO) RESTORE (RTO) RESTORE/RECOVERY Fil shares/ fil server Der tages backup af selve filserveren ifølge politik for virtuel eller fysisk server. Backup af fil shares som separat konfigureret backup RPO: Op til 24 timers datatab RTO: Restore cirka 25 GB/time Det vil være muligt at restore filer, mapper og hele shares, såfremt disse er ødelagt, slettet eller tilsvarende enten grundet system fejl, eller grunder brugerens egen fejl. Datamængderne er væsentlige i forhold til RTO. Daglig Gemmes 60 dage Implementering i TSM via TSM BA incremental forever Exchange Backup via Exchange agent Daglig incremental 4 gange/dag Ugentlig full backup RPO: op til 6 timers datatab RTO: Restore cirka 80 GB/time Det vil være muligt at restore Exchange database og dermed enkelte elementer, f.eks. mailboxes. Gemmes 60 dage Database Vigtig Database agent backup Daglig incremental + logs RPO: op til 1 timer datatab RTO: Restore cirka 80 GB/time Databaser vil kunne restores via full backup med efterfølgende restore af incremental og logs, således at restore kan foretages point in time.
BACKUP OMRÅDE BASELINE BACKUP Ugentlig full Gemmes 35 dage DATATAB (RPO) RESTORE (RTO) RESTORE/RECOVERY Implementering i TSM via TSM TDP agent. Database Normal Database agent backup Daglig incremental Ugentlig full RPO: op til 24 timers datatab RTO: Restore cirka 40-80 GB/time Databaser vil kunne restores via full/incremental backup, enten via TDP agent eller via database dump til fil. Gemmes 35 dage Applikations data Applikationsdata som ikke er dækket af nogen af ovenstående områder vil der kunne etableres daglig backup af. RPO: op til 24 timers datatab RTO: Restore cirka 40 GB/time Samme backup metode som for filshares Gemmes i 35 dage RTO tider er baseret på restore fra LTO3 tapes via et tapedrev. I nogen tilfælde vil det være muligt at benytte flere tapedrev og dermed øge restore hastigheden.
4 Applikationsdrift standarder og snitflader I samarbejdet mellem systemejere på ministerområderne og Statens It er aftalt en opgave- og ansvarsfordeling, ligesom snitflader i dagligdagen søges gjort ensartet for systemer, som driftes hos Statens It eller hos 3. part. Til hver applikation, som driftes af Statens It, skal der, med anvendelse af en standardskabelon, udarbejdes driftsvejledninger. Som systemleverandør skal man være særlig opmærksom på nedenstående forhold. Område Standard Installationsvejledning Der skal foreligge en installationsvejledning, som trin for trin beskriver, hvorledes applikationen installeres. Installationsvejledningen skal tage udgangspunkt i, at den skal kunne bruges af medarbejder, som har kendskab til operativsystemet på administratorniveau. Installationsvejledningen skal udarbejdes ved anvendelse af Statens It s skabelon. Driftsvejledning Driftsvejledningen indeholder den nødvendige driftsdokumentation, som gør det muligt for Statens It at udføre de forventede og aftalte driftsopgaver. Driftsvejledningen skal udarbejdes med anvendelse af Statens It s standardskabelon. Verifikationsprocedure Der skal foreligge en vejledning i, hvorledes applikationen startes og stoppes, samt hvorledes driftspersonalet kan verificere, at applikationen er stoppet og startet. Verifikationsproceduren kan suppleres med vejledning i, hvorledes driftspersonale, som ikke er brugere af applikationen, kan kontrollere, at applikationen er klar til brugeranvendelse. Verifikationsproceduren skal indgå i driftsvejledningen, som baseres på Statens It s standardskabelon. Daglige driftsopgaver Der skal foreligge en liste over de regelmæssige og tilbagevendende driftsopgaver vedrørende applikationen, som det forventes, at driftspersonalet udfører. Det kan fx være kontrol af batchkørsler, filforsendelser m.v. Daglige driftsopgaver skal indgå i driftsvejledningen, som baseres på Statens It s standardskabelon. Changeproces Ændringer til applikationen følger Statens It s til enhver tid gældende changeproces og registreres i Statens It s sagsregistreringssystem. Ændringer i den basale infrastruktur gennemføres i de aftalte standard servicevinduer, pt. den tredje torsdag i måneden fra kl. 18 til 06. Ændringer i applikationsprogrammellet foretages efter nærmere aftale i en releaseplan for applikationen. Releaseplanen vil tage udgangspunkt i installationsmodellen beskrevet i afsnit 4.1. herunder.
Ændringsstyringen skal indgå i driftsvejledningen, som baseres på Statens It s standardskabelon. 4.1 Installationsmodel For at sikre et robust driftsmiljø benytter Statens It følgende model i forbindelse med installation og ændring afapplikationer. Miljø Beskrivelse Obligatorisk Produktion Produktionsmiljøet er det miljø hvor selve Ja produktionen afvikles. Præproduktion Præproduktionsmiljøet er det miljø hvor Statens It Ja afprøver installationspakker leveret af udvikler. Test Testmiljøet er det miljø hvor udvikler tester Nej applikationen sammen med kunden. Udvikling Udviklingsmiljøet er det miljø, hvor udvikler har fuld kontrol over alle elementer af applikationen. Nej I forbindelse med idriftsættelse af nye applikationer etableres som standard et produktionsmiljø og et præproduktionsmiljø. Etablering af udviklingsmiljø og testmiljø er ikke obligatorisk, men kan etableres på baggrund af en bestilling fra kunden.. Proces for installation af applikationer og ændringer til applikationer Sammenhængen mellem de enkelte dele i modellen kan grafisk beskrives som vist i fig. 1. Principielt skal der til enhver applikation, der skal tages i drift, etableres et udviklingsmiljø, et testmiljø, præproduktionsmiljø og et produktionsmiljø. Hvis der er tale om en førstegangsinstallation gennemføres processerne i modellen således, at Statens It installerer (eventuelt i samarbejde med udvikler) applikationen på præproduktionsmiljøet. Figur 1 Når installationen er godkendt af kunden og Statens It, overføres installationen til produktionsmiljøet.
I princippet anvendes samme proces til opgradering af en eksisterende installation. Det vil selvfølgelig være muligt efter aftale at få etableret flere parallelle test- og udviklingsmiljøer, hvis der er behov for det. Såfremt ovenstående model ikke følges kan det påvirke SLA-niveau og forbruget af timer til applikationsdrift. Omfanget vil blive vurderet i den enkelte afvigelse. 4.2 Standard applikationsprogrammel Applikationsprogrammel Standard Databaser Microsoft SQL 2008 Oracle 11g PostgreSQL 9.0 CMS-systemer Microsoft Sharepoint 2010 SiteCore 6.4 Drupal 7.0 IIS Følger Windows Server versionen, for Windows Server 2008 er standarden 7.0