Service Level Agreement VDC
Service Level Agreement VDC
Nærværende Service Level Agreement (herefter også kaldet ”SLA”) klarlægger Leverandørens serviceforpligtelser for produktet ”VDC”. Forpligtelserne er gældende forudsat, at den tilhørende Aftale henviser til nærværende dokument.
Ved eventuel uoverensstemmelse mellem Aftalen og nærværende SLA har Aftalens bestemmelser forrang.
Version 7.1
d. 11. oktober 2021
INDHOLDSFORTEGNELSE
10 KOMPENSATION (kun gældende for SLA ”Pro”) 11
1 DEFINITIONER
1.1 Definitionerne angivet i Aftalen har samme betydning i nærværende bilag, medmindre defineret anderledes heri.
1.2 ”Løsning” definerer den løsning, Leverandøren leverer i henhold til Aftalen. En Løsning består af én eller flere Services i én eller flere Produktionsenheder.
1.3 ”VDC” er en forkortelse for produktet ’Virtual Datacenter’.
1.4 ”Service” henviser til den specifikt berørte del af Løsningen i tilfælde af et Incident, f.eks. Storage, firewall og Cluster. Én Service leveres kun fra én Produktionsenhed. To ens Services kan derimod leveres fra to forskellige Produktionsenheder.
1.5 ”Produktionsenhed” henviser til en isoleret enhed i et datacenter. En Produktionsenhed er uafhængig af andre Produktionsenheder og består bl.a. af dedikeret internetforbindelse, netværksudstyr, Storage og servere.
1.6 ”Incident” betegnes som enhver hændelse, der afbryder en Service, herunder afbryder forretningskontinuiteten, hvor dette ikke skyldes en SLA-undtagelse.
1.7 ”Nedetid” er perioden hvor Løsningen er utilgængelig, og hvor dette ikke skyldes en SLA-undtagelse (nærmere beskrevet i afsnit 4).
1.8 ”Oppetid” betegnes som den tid, hvor Løsningen og/eller en Service er tilgængelig (nærmere beskrevet i afsnit 4).
1.9 ”Oppetidsprocent” er beregnet som det procentuelle forhold mellem realiseret nedetid i forhold til teoretisk maksimal oppetid (nærmere beskrevet i afsnit 4).
1.10 ”Månedlig Oppetidsprocent” angiver procentsatsen for Løsningens Oppetid i en given kalendermåned (nærmere beskrevet i afsnit 4).
1.11 ”Garanteret Oppetidsprocent” angiver Leverandørens garanterede Månedlige Oppetidsprocent, som nærmere fremgår af afsnit 12.
1.12 “Effektiv SLA-procent” henviser til den laveste fællesnævner for Leverandørens Garanterede Oppetid, såfremt Kundens Løsning består af flere Services med forskellige Garanterede Oppetidsprocenter, som fremgår nærmere af afsnit 12.
1.13 ”Service Level Objectives” angiver Leverandørens performancemål.
1.14 ”Responstid” betegner, hvornår Kunden kan forvente, at Leverandøren påbegynder sin fejlsøgning på Løsningen, i tilfælde af et Incident.
1.15 ”Host” betegnes som en visualiseringshost, der indgår i et Cluster, hvorved workloads er beskyttet i tilfælde af et Incident.
1.16 ”Cluster” betegnes som en gruppering af Hosts, som leverer en pulje af kapacitet, f.eks. memory, CPU eller SDS.
1.17 ”Standalone Host” betyder en Host, der ikke indgår i et Cluster, og som derved ikke er beskyttet i tilfælde af et Incident.
1.18 ”Storage” betegnes som lagringsplads for data.
1.19 ”Shared Storage” betegner Storage, der indgår i et redundant setup, og som leveres fra enten et SAN, et NAS eller som SDS.
1.20 “Storage Area Network” eller ”SAN” betegnes som en enhed, hvorfra der kan leveres Shared Storage.
1.21 “Network Attached Storage” eller ”NAS” betegnes som en enhed, hvorfra der kan leveres Shared Storage.
1.22 ”Software Defined Storage ” eller ”SDS” betegner den metode, Shared Storage leveres på, hvorved diskene, der leverer Storage-kapaciteten, sidder direkte i de enkelte Hosts i det pågældende Cluster.
1.23 ”Local Storage” betegner Storage, der leveres direkte fra en lokal disk i en Standalone Host.
1.24 ”SLA-undtagelse” er forhold, der anses som værende uden for Leverandørens kontrol og dermed undtagelser til Leverandørens SLA-forpligtelser (nærmere beskrevet i afsnit 11).
1.25 ”Kompensation” udgør som det beløb, som Kunden er berettiget til at kræve krediteret i tilfælde af Leverandørens manglende overholdelse af den Garanterede Oppetidsprocent (nærmere beskrevet i afsnit 10).
2 DATACENTRE
2.1 Leverandøren leverer Løsningen fra en række professionelt driftede datacentre, herunder inergen brandslukningsanlæg, redundant internetforbindelse, redundant netværks backbone og redundant UPS strøm-backup. Datacentrene driftes uden spejling eller redundans på tværs af andre datacentre og kontrolleres løbende af Leverandøren for at sikre en stabil og kvalitetssikret leverance.
2.2 Leverandøren har et Network Operations Center (NOC), bemandet døgnet rundt alle ugens dage, der håndterer alarmer på overvågningssystemer.
3 SERVICEVINDUE
3.1 Det tilstræbes, at opdateringer, systemarbejde og vedligehold så vidt muligt udføres i tidsrummet kl. 00.00-05.00, såfremt Leverandøren vurderer, at det vil have en påvirkning på Kundens Løsning.
3.2 Vurderer Leverandøren, at det ikke vil have en påvirkning på Kundens Løsning kan opdateringer, systemarbejde og vedligehold udføres i tidsrummet kl. 18.00-06.00.
4 MÅLING AF OPPETID
4.1 Leverandørens måling af Oppetidsprocent følger af bilag 3.1 - Måling af Oppetid.
4.2 Månedlig Oppetidsprocent beregnes efter følgende model:
𝑂𝑝𝑝𝑒𝑡𝑖𝑑 % =
Maksimal Oppetid − Nedetid
𝑀𝑎𝑘𝑠𝑖𝑚𝑎𝑙 𝑂𝑝𝑝𝑒𝑡𝑖𝑑
∗ 100
Maksimal Oppetid = den maksimale Oppetid (i minutter) for en given periode, hvilket er 60 minutter x 24 timer (i minutter) x antallet af dage i den pågældende kalendermåned.
”Nedetid” er perioden af akkumulerede minutter, hvor Løsningen er utilgængelig. Månedlig Oppetidsprocent omfatter ikke nedetid, der direkte eller indirekte følger af én eller flere SLA-undtagelser.
Leverandørens måling af Oppetid foretages med maksimalt 5 minutters intervaller.
5 SERVICE LEVEL OBJECTIVES
5.1 Generelt
Service Level Objectives er kun gældende for scenarier og metrikker anført i nærværende dokument.
Leverandøren skal overholde nedenstående Service Level Objectives alle ugens dage fra kl. 05:00 til kl. 00:00, medmindre den manglende overholdelse skyldes en SLA-undtagelse.
Overholder Leverandøren ikke nedenstående Service Level Objectives, er Leverandøren forpligtet til at forsøge at afhjælpe problemet. Afsnit 10 finder ikke anvendelse på manglende overholdelse af Service Level Objectives.
5.2 Service Level Objectives (Storage)
Leverandørens Service Level Objectives på Storage måles ud fra følgende metrikker:
• IO/sec
• Latency (ms) pr. IO på read/write
Der testes og valideres imod tre scenarier, som fremgår af nedenstående oversigt:
Service Level Objectives (Storage) | |||||
Scenarie: | R/W Split | Block Size | Queue Depth | Threads | % Random |
Scenarie 1 | 50/50 | 4K | 8 | 8 | 0 |
Scenarie 2 | 50/50 | 16K | 8 | 8 | 0 |
Scenarie 3 | 50/50 | 64K | 8 | 8 | 0 |
Test af ovenstående scenarier foretages alene på en virtuel maskine (VM) med følgende konfiguration:
Konfiguration af test-VM | |
OS: | Windows Server 2019 Standard |
Memory: | 16 GB |
CPU: | 8 Cores |
Harddisk: | C: 50 GB (kun OS) D: 100 GB (testdisk)* |
Disk Controller | LSI Logic SAS |
Andet | GPT Layout, NTFS Filsystem, formatering matcher test block size |
Test Applikation | IOMeter |
* 50 GB anvendes til at foretage testen
Xxxxxxxx for udvalgte tests af tiers:
• Tier 1 og tier 2 er udvalgt til test, da disse er tiltænkt forretningskritisk produktionsbrug, hvor der forventes et vist niveau af performance.
• Tier 3 er ikke udvalgt til test, da dette er tiltænkt mass-Storage eller arkivbrug, som dermed ikke er forbundet med et vist niveau af performancekrav.
Service Level Objectives på udvalgte tiers (inklusive scenarier) fremgår af følgende oversigt:
Scenarie 1 Scenarie 2 Scenarie 3 Tier IO/sec R/W IO/sec R/W IO/sec R/W Latency Latency Latency | ||||||
1 | 11000 | 2 ms / 2 ms | 10000 | 2 ms / 2 ms | 8000 | 6 ms / 4 ms |
2 | 10000 | 8 ms / 8 ms | 10000 | 8 ms / 8 ms | 10000 | 8 ms / 8 ms |
3 | N/A | N/A | N/A | N/A | N/A | N/A |
Målinger foretages for hver enkelt harddisk. Throughput/latency kan, alt efter applikationen, være afhængig af CPU, hvorfor det ikke kan garanteres, at en VM med f.eks. 4 harddiske opnår 4 gange det, der vises i ovenstående oversigt.
Aflæsning foregår via ”Monitor” i vCenter. Her vælges “Advanced” hvorefter følgende metrikker i “Virtual Disk”-afsnittet vælges: “Average Read Request per Second”, “Average Write Request per Second”, “Read Latency” og “Write Latency”.
Storage Latency
5.2.8.1 Leverandørens Service Level Objectives på Storage latency er, indenfor den enkelte tier, at opretholde en latency indenfor rammerne af ovenstående oversigt, hvilket er under eller tilsvarende det viste niveau. Leverandørens måling er baseret på metrikker fra VMware, som modtages i interval af 20 sekunder. Målingen foretages på tværs af 180 punkter (point in time), der svarer til en værdi af 60 minutters metrikker, hvoraf der beregnes et gennemsnit, som holdes op mod ovenstående oversigt.
Storage IO/sec
5.2.9.1 Leverandørens Service Level Objectives på Storage IO/sec angiver, hvad Kunden bør kunne forvente. Det er imidlertid ikke givet, at en applikation kan gøre brug af alt IO, idet applikationen i sig selv kan udgøre en begrænsning herfor, f.eks. i tilfælde af, at applikationen ikke er designet hertil.
5.3 Service Level Objectives (CPU)
Service Level Objectives på CPU fremgår af følgende oversigt:
Service Level Objectives (CPU) |
CPU Ready < 1000 ms (5%) pr. core |
Leverandørens Service Level Objectives på CPU Ready er at opretholde en CPU Ready under niveauet defineret i pkt. 5.3.1. Leverandørens måling er baseret på metrikker fra VMware, som modtages i interval af 20 sekunder. Målingen foretages på tværs af 180 punkter (point in time), der svarer til en værdi af 60 minutters metrikker, hvoraf der beregnes et gennemsnit, som holdes op mod ovenstående oversigt.
Leverandøren er ikke ansvarlig for overholdelse af ovenstående Service Level Objectives for CPU Ready, herunder høj CPU Ready (>1000 ms), såfremt høj CPU Ready er opstået som følge af enten:
• Ikke hensigtsmæssig/suboptimal sizing på VM-niveau (tildeling af
vCPU’er/vCores).
• Højt CPU-forbrug på Host-niveau (+90%).
Leverandøren vil imidlertid, på opfordring fra Kunden, være behjælpelig med løsningsforslag samt forslag til sizing af VMs.
Leverandøren leverer alle Hosts konfigureret med “Default CPU Scheduler”. Kunden kan imidlertid vælge, at dette ændres til “Side Channel Aware Scheduler v1” eller “Side Channel Aware Scheduler v2”.
Leverandøren leverer alle Hosts og/eller Clusters uden en garanti for forholdet mellem fysiske CPU-kerner og virtuelle CPU’er. Såfremt en applikation kræver garanteret forhold mellem fysiske CPU-kerner og virtuelle CPU’er, vil dette være et specialiseret design, og dette skal aftales med Leverandøren.
5.4 Service Level Objectives (Network)
Leverandøren er forpligtet til at levere en redundant netværksinfrastruktur uden pakketab.
Såfremt der skulle forekomme pakketab på Leverandørens netværks- infrastruktur, er det Leverandørens ansvar at udbedre dette.
Nærværende forpligtelse er kun gældende inden for Leverandørens datacentre.
Leverandøren er yderligere forpligtet til at levere et redundant netværk inklusive internetforbindelser.
5.5 Service Level Objectives (Local storage)
Leverandøren leverer kun Service Level Objectives på tilgængelighed af Local Storage-kapacitet og dermed ikke på den faktiske data, der er lagret derpå. Årsagen hertil er, at såfremt der forekommer simultane fejl på multiple komponenter, kan dette forårsage Nedetid indtil, komponenterne er erstattet med nye komponenter. Desuden kan integriteten af data være kompromitteret.
Leverandørens genopbygning af en disk, kan have en påvirkning på performance af Local Storage, så længe genopbygning foretages.
Performance på Local Storage er ikke indeholdt i Leverandørens Service Level Objectives, idet performance varierer med antallet samt type af diske.
6 CONFIGURATION MANAGEMENT
6.1 Management Consoles
Leverandøren er forpligtet til at stille én vCenter-Server til rådighed for Kunden, som Leverandøren skal sikre er tilgængelig på et eksternt isoleret miljø, og som løbende opdateres på samme vilkår som hypervisors.
6.2 Cluster Configuration Management
Leverandøren er forpligtet til at opretholde n+X, som beskrevet i Aftalen.
Medfører Kundens øgede forbrug af kapacitet, at n+X ikke er overholdt, har Leverandøren 72 timer til at genoprette n+x fra det punkt, hvor n+X ikke var overholdt. Dette er ikke gældende, såfremt Kunden har et individuelt tilpasset Cluster, der afviger fra Leverandørens standardkonfiguration af hardware.
I alle andre tilfælde end det i pkt. 6.2.2 nævnte, er Leverandøren forpligtet til, inden for 24 timer, at genoprette n+X fra det punkt, hvor n+X ikke var overholdt.
6.3 Host Configuration Management
Leverandøren er forpligtet til at sikre, at samtlige Hosts i et Cluster, på OS-niveau, er identisk konfigureret på Storage- og netværksadgange.
Leverandøren er forpligtet til at sikre, at samtlige Hosts i et Cluster, hardwaremæssigt, er identisk konfigureret i henhold til ovenstående oversigt.
7 LOCAL STORAGE
Såfremt der er fejl på Storage-komponenter, skal Leverandøren fejlmelde senest næste Arbejdsdag.
Leverandøren er forpligtet til, senest førstkommende Arbejdsdag efter dagen for fejlmelding, at levere reservedele på Storage-komponenter (RAID-Controllers, Diske etc), såfremt der skulle opstå problemer hermed, medmindre andet fremgår af Aftalen.
Leverandøren er forpligtet til, senest førstkommende Arbejdsdag efter dagen for fejlmelding (jf. pkt. 7.1.1), at skifte fejlede Storage-komponenter, medmindre andet fremgår af Aftalen.
Såfremt Løsningen leveres via et RAID-set (Redundant Array of Independent Disks), er Leverandøren forpligtet til at sikre, at én fysisk disk i RAID-settet kan mistes uden, at dette har påvirkning på tilgang eller integritet af data.
På Kundens Løsning er Leverandøren forpligtet til udelukkende at bruge datacenter-/enterpriseudstyr designet til at drifte datacentre døgnet rundt, alle ugens dage, hele året (24/7/365).
8 BACKUP
8.1 Generelt
Leverandøren tager som udgangspunkt ikke backup af Kundens Løsning, medmindre Kunden særskilt har tilkøbt backup, og dette derved fremgår af bilag 1 - Løsningsbeskrivelsen.
Såfremt Xxxxxx har tilkøbt backup henvises til Leverandørens gældende Backup SLA.
9 PATCH MANAGEMENT
9.1 Generelt
Leverandørens ansvar for patch management udgør den del af Kundens Løsning, herunder den underliggende infrastruktur, som Leverandøren har driftsansvaret for.
Såfremt det er muligt, vil Leverandøren implementere opdateringer, patches og ændringer til systemer i tidsrummet 04.00 – 06.00 på tirsdage og onsdage.
9.2 Datacenter Scope
9.2.1.1 Leverandørens scope for datacenter patch management er Storage og network.
Timing og patchvindue
9.2.2.1 Leverandøren vurderer løbende sårbarheder og security patches på områder, der ligger inden for Leverandørens ansvarsområde.
9.2.2.2 Patchvindue afhænger af den enkelte enhed, der skal patches og kan derfor variere fra gang til gang i både tidspunkt og længde.
For henholdsvis Storage og network vurderer Leverandøren, hvorvidt security patches, der er relevante for den nuværende version, har relevans for datacentrets drift.
Såfremt der er lav risiko for, at en security patch vil forårsage Nedetid, tilstræber Leverandøren at varsle patchvinduet over for Kunden 7 dage forinden, patching påbegyndes.
Såfremt der er høj risiko for, eller Leverandøren med sikkerhed ved, at en security patch vil forårsage Nedetid, forpligter Leverandøren sig til at varsle patchvinduet over for Kunden senest 14 dage forinden, patching påbegyndes.
9.2.2.3 I særlige tilfælde hvor der opstår kritiske sårbarheder i et datacenters infrastruktur, og dette medfører høj risiko for at forårsage Nedetid, er Leverandøren berettiget til, med kort varsel, at foretage ekstraordinær patching.
9.3 VDC
Scope
9.3.1.1 Leverandørens scope for VDC patch management er hypervisors og vCenter.
Timing og patchvindue
9.3.2.1 Leverandøren vurderer løbende sårbarheder og security patches på områder, der ligger inden for Leverandørens ansvarsområde.
9.3.2.2 Leverandøren overvåger producentens frigivelse af kritiske security patches med henblik på at vurdere disse. Leverandøren tilstræber at fuldføre denne vurderingsproces hurtigst muligt efter frigivelse af ekstra kritiske patches (remotely exploitable) og senest inden for 30 dage.
9.3.2.3 En security patch installeres så vidt muligt på interne systemer først, for at nedsætte risikoen for, at patchen indeholder ændringer, der vil ødelægge funktionaliteten i Kundens Løsning.
9.3.2.4 Såfremt der er risiko for, at en security patch på VDC’ets infrastruktur vil forårsage Nedetid for de virtuelle maskiner, tilstræber Leverandøren at varsle patchvinduet over for Kunden 7 dage forinden, at patching påbegyndes.
9.3.2.5 Undtagelsesvis kan Leverandøren udføre ændringer straks, uden varsel, såfremt Leverandøren vurderer, at det vil medføre høj risiko for Nedetid, hvis patching ikke foretages straks.
9.3.2.6 I særlige tilfælde hvor der opstår kritiske sårbarheder i VDC’ets infrastruktur, og dette medfører høj risiko for Nedetid, er Leverandøren berettiget til, med kort varsel, at foretage ekstraordinært patching.
10 KOMPENSATION (kun gældende for SLA ”Pro”)
10.1 Kompensation – Månedlige Oppetidsprocent
Såfremt Leverandøren ikke overholder Leverandørens Garanterede Oppetidsprocent, og dette ikke skyldes én eller flere SLA-undtagelser, er Kunden berettiget til at kræve Kompensation i henhold til nærværende afsnit.
Består Kundens Løsning imidlertid af flere Services med forskellige Garanterede Oppetidsprocenter, udgøres Kundens Garanterede Oppetidsprocent af den Effektive SLA-procent. Har Kunden f.eks. (ikke-udtømmende) en Datacenter Service (Garanteret Oppetidsprocent på 99,95 %), der er en Standalone Host (Garanteret Oppetidsprocent på 99,00 %), der har Local Storage (Garanteret Oppetidsprocent på 99,00 %), vil Kundens garanterede Effektive SLA-procent være på 99,00 %. Overholder Leverandøren ikke den Effektive SLA-procent, og dette ikke skyldes én eller flere SLA-undtagelser, er Xxxxxx berettiget til at kræve Kompensation i henhold til nærværende afsnit.
Kunden kan ikke kræve Kompensation for andet end Leverandørens manglende overholdelse af Månedlige Oppetidsprocenter.
Kompensation beregnes for den pågældende kalendermåned, hvor Leverandøren ikke har overholdt den Garanterede Oppetidsprocent eller den Effektive SLA-procent jf. pkt. 10.1.2, som en procentdel af vederlaget for de akkumulerede fakturaer, der vedrører den specifikt berørte Service (eksklusive omkostninger til éngangsinstallationer).
Kompensation gives som servicekredit og fratrækkes næstkommende faktura, forudsat der ikke foreligger bestridte og/eller forfaldne fakturaer for den pågældende Service. Ved Kompensationsprocent over 10% fordeles Kompensationen over de følgende 3 faktureringsmåneder. Kunden er under ingen omstændigheder berettiget til at få Kompensation udbetalt. Kompensation gives udelukkende ved henvendelse fra Kunden og skal skriftligt være meddelt Leverandøren senest 30 dage efter, den manglende serviceforpligtelse har fundet sted.
Kompensationsprocenter for Leverandørens manglende overholdelse af Garanterede Oppetidsprocent (som angivet i pkt. 12) og Effektive SLA-procent (som angivet i pkt. 12) følger nedenstående oversigt.
Månedlig Oppetidsprocent – Effektiv SLA 99,95 % | Kompensation % |
Mellem 99,95 % og 99,5 % | 5 % |
Mellem 99,4 % og 99,0 % | 10 % |
Mellem 98,9 % og 97,0 % | 30 %* |
Mellem 96,9 % og 95, 0 % | 50 %* |
Lavere end 95,0 % | 75 %* |
*Ved Kompensation over 10 % fordeles Kompensationen over de 3 følgende faktureringsmåneder. | |
Månedlig Oppetidsprocent – Effektiv SLA 99,00% | Kompensation % |
Mellem 99,0 % og 98,5 % | 5 % |
Mellem 98,4 % og 98,0 % | 10 % |
Mellem 97,9 % og 96,0 % | 30 %* |
Mellem 95,9 % og 94, 0 % | 50 %* |
Lavere end 94,0 % | 75 %* |
*Ved Kompensation over 10 % fordeles Kompensationen over de 3 følgende faktureringsmåneder.
Kompensation er under alle omstændigheder begrænset til det samlede vederlag for den specifikt berørte Service (eksklusive omkostninger til éngangsinstallationer), for den kalendermåned, hvori den manglende serviceforpligtelse har fundet sted.
11 SLA-UNDTAGELSER
11.1 Nærværende SLA er ikke gældende ved nogen form for mangelfuld performance eller utilgængelighed, hvis dette skyldes et af nedenstående oplistede forhold eller forhold, der er uden for Leverandørens kontrol;
• Kundens, Kundens kunder eller Xxxxxxx tredjeparters selvforskyldte Incident, herunder forårsaget ved manglende handling.
• Fejl eller sikkerhedsbrister, som skyldes applikationer eller anden software, som Kunden har installeret uden Leverandørens skriftlige samtykke.
• Hardware- eller softwarefejl, som ikke er omfattet af Leverandørens driftsansvar.
• Leverandørens planlagte opdateringer/patch, vedligehold i servicevinduet (nærmere beskrevet i pkt. 3.1) og systemarbejde.
• DDos angreb – Distributed Denial of Service.
• Lovmæssige krav.
• Force Majeure.
12 SLA-MATRIX
Cluster Standalone Host
Infrastruktur - Datacenter | Basic | Pro | Basic | Pro |
Responstid (påbegyndt fejlsøgning) | 30 min | 30 min | 30 min | 30 min |
Garanteret Oppetidsprocent | 99.95% | 99.95% | 99.95% | 99.95% |
Infrastruktur - Virtualisering | ||||
Responstid (påbegyndt fejlsøgning) | Næste Arbejdsdag | 30 min | Næste Arbejdsdag | 30 min |
Garanteret Oppetidsprocent | 90.00% | 99,95% | 90.00% | 99.00% |
Overvågning på Hypervisor-niveau | ✓ | ✓ | ✓ | ✓ |
Infrastruktur – Shared Storage | ||||
Responstid (påbegyndt fejlsøgning) | 30 min | 30 min | 30 min | 30 min |
Garanteret Oppetidsprocent | 99,95% | 99,95% | 99,95% | 99,95% |
Overvågning på SAN-niveau | ✓ | ✓ | ✓ | ✓ |
Infrastruktur – Local Storage | ||||
Responstid (påbegyndt fejlsøgning) | Ikke tilgængelig | Ikke tilgængelig | Næste Arbejdsdag | 30 min |
Garanteret Oppetidsprocent | Ikke tilgængelig | Ikke tilgængelig | 99.00% | 99.00% |
Overvågning på hardware-niveau | Ikke tilgængelig | Ikke tilgængelig | ✓ | ✓ |
Kompensation | ||||
Målgruppe | Test & Dev | Produktion | Test & Dev | Produktion |
Kompensation (jf. afsnit 9) | ✓ | ✓ | ||
Effektiv SLA-procent | 90.00% | 99.95% | 90.00% | 99.00% |
Helpdesk | ||||
Normal arbejdstid: Mandag – Torsdag, Telefon: 08:00 – 16:00 (ekskl. helligdage) | ✓ | ✓ | ✓ | ✓ |
Normal arbejdstid: Fredag, Telefon: 08:00 – 15:00 (ekskl. helligdage) | ✓ | ✓ | ✓ | ✓ |
Vagttelefon 24/7 | ✓ | ✓ | ||
Services | ||||
In-Guest Mulighed for ServiceDesk | ✓ | ✓ |
Backup
Mulighed for Managed Image-Based Backup (Opsætning, overvågning, restores, rådgivning)* ✓ ✓ ✓ ✓
Ekspertrådgivning ✓ ✓
Adgang til rådgivning fra tekniker ✓ ✓
Overvågning
Mulighed for unmanaged overvågning** ✓ ✓ ✓ ✓
* kræver ServiceDesk
** via Leverandørens overvågningssystem
Bilag 3.1 - Måling af Oppetid
Nærværende dokument er tilknyttet Leverandørens Service Level Agreement for produktet ”VDC” og klarlægger Leverandørens måling af Oppetid.
Version 1.1
d. 11. oktober 2021
1 OPPETIDSMÅLING
1.1 Leverandøren måler Oppetid på følgende komponenter:
Oppetidsmåling | |||
Komponent | Beskrivelse | Monitoreringsparametre | Nedetidsvægtning |
Firewall | Den firewall som alt internettrafik til og fra VDC- miljøet passerer igennem. | Ping, Sessions, CPU, Hardware | Den forholdsmæssige del af Kundens Løsningsvederlag, baseret på de *direkte berørte VMs, grundet et Incident på firewallen |
VM | Den virtuelle maskine som eksisterer i Kundens VDC- miljø. | Ingen monitorering | Den forholdsmæssige del af Kundens Løsningsvederlag, baseret på den *direkte berørte VM. |
Cluster | Virtualiseringsteknologien, der muliggør drift af virtuelle maskiner på Kundens dedikerede miljø - ud fra de fysiske ressourcer, som er tilgængelige i de hosts, som indgår i Kundens VDC-miljø. | VMware services | Den forholdsmæssige del af Kundens Løsningsvederlag, baseret på de *direkte berørte VMs, grundet et incident på et Cluster. |
Host | Den fysiske server hvis RAM, CPU og evt. Storage ressourcer indgår i VDC miljøet. | Ping, SSH, Hardware | Den forholdsmæssige del af Kundens Løsningsvederlag, baseret på de *direkte berørte VMs, grundet et Incident på en Host. |
Storage | Den lagerplads som Kundens VM’s benytter. SAN storage benytter infrastruktur, som er delt med andre kunder. Et VDC-miljø har ofte flere forskellige instanser af SAN Storage. Local Storage er lokal lagerplads, som Kundens VM’s i særlige tilfælde benytter. Local Storage er dedikeret til Kunden og deles ikke med andre kunder. | Ping, Hardware, Utilization | Den forholdsmæssige del af Kundens Løsningsvederlag, baseret på de *direkte berørte VMs, grundet et Incident på en Storage platform |
Netværks- infrastruktur | Den fysiske netværksinfrastruktur (f.eks. kabler, switche og routere) der forbinder bla. Hypervisor, SAN storage og firewall. | Ping, Hardware, Utilization, Services | Den forholdsmæssige del af Kundens Løsningsvederlag, baseret på de *direkte berørte VMs, grundet et Incident på netværksinfrastruktur. |
*En VM er direkte berørt af et Incident, såfremt maskinen er påvirket på et niveau, der er under OS-niveau.
Dermed er en VM indirekte berørt af et Incident, såfremt maskinen er påvirket på et niveau, der er på OS-niveau eller over.
1.2 En Kundes Løsning består af flere forbrugskomponenter. Det fremgår af Kundens faktura, hvilke forbrugsenheder, der benyttes for den pågældende Løsning.
Typisk forbruger en VM følgende (dette kan dog variere):
Oppetidsmåling | ||
Komponent Scope Beregning | ||
Firewall Cluster | Alle direkte berørte VM’s | Samlet omkostning for direkte berørte VM’s |
Unmanaged VDOM* | Ikke i scope | - |
Co-managed VDOM | Alle direkte berørte VM’s såfremt Leverandøren har forårsaget fejlen | Samlet omkostning for direkte berørte VM’s |
Managed VDOM** | Alle direkte berørte VM’s | Samlet omkostning for direkte berørte VM’s |
Storage | Alle direkte berørte VM's | Samlet omkostning for direkte berørte VM's |
Memory | Alle VM's i det direkte berørte Cluster | Omkostning for det direkte berørte Cluster |
Network | Alle direkte berørte VM's | Samlet omkostning for direkte berørte VM's |
*Kundeadministreret firewall
** Kun relevant ved tilkøb
1.3 Såfremt en eller flere af ovenstående forbrugskomponenter fejler, kan dette forårsage, at en eller
flere VM’s bliver utilgængelige.
1.4 Bliver Kunden berettiget til kompensation, beregnes kompensationen pr. VM, der har været direkte berørt af et givent Incident.