Kjøpsavtale datalagringskomponenter Bilag 1, kjøpsavtalen Kundens kravspesifikasjon Sak 201000157 Versjon 1.0
INNHOLDSFORTEGNELSE 1 GENERELT...3 2 BAKGRUNN...3 3 BEGREPER...3 4 BESVARELSE AV...3 4.1 MERKING AV...3 4.2 LEVERANDØRENS SVAR...3 4.3 FORMÅL...4 4.4 LEVERANSEOMFANG...5 5...5 5.1 BESKRIVELSE AV...5 6 FELLES...6 7 ARKITEKTUR OG FUNKSJONALITET...8 8 EKSEMPELKONFIGURASJONER...11 8.1 EKSEMPELKONFIGURASJON 1 MIDDLERANGE SAN...11 8.2 EKSEMPELKONFIGURASJON 2 ENTERPRISE SAN...16 8.3 EKSEMPELKONFIGURASJON 3 DISKBASERT BACKUPLØSNING...20
1 Generelt Dette dokumentet er bilag 1 til kjøpsavtalen. 2 Bakgrunn DSS har pr dags dato ingen avtale om kjøp av lagringskomponenter, samt at vedlikeholdsavtalen, for eksisterende løsningen avsluttes medio 2010. I tillegg er eksisterende lagringsløsningen 4 år gammel, kapasiteten på denne er snart brukt opp, og det er kostbart å utvide og vedlikeholde. 3 Begreper I kravspesifikasjonen benyttes et sett med sentrale begreper som beskrevet i tabellen nedenfor. Begrep DSS Kunde Departementsfellesskapet DSS:IKT Nedetid Forklaring Departementenes servicesenter - Betegnelse på Kunde. DSS Alle departementene og DSS. Informasjons- og kommunikasjonsteknologiavdelingen i DSS. Alle situasjoner der et LUN oppleves som utilgjengelig for en host, uavhengig av varighet. Netto TB Forbrukt TB IOPS Totalt antall allokert TB sett fra host Totalt antall benyttet TB sett fra host Input Output Operations per Second
Etter inngåelse av denne rammeavtalen ønsker DSS å avrope en ny løsning for erstatning av Dersom Leverandøren utelater å svare på et krav, vil DSS tolke dette som NEI. Hvis svaret er JA skal dette beskrives med utfyllende kommentarer. Hvis svaret er NEI skal dette beskrives med utfyllende kommentarer om hvorfor. Hvis svaret er DELVIS skal dette beskrives med utfyllende kommentarer. Det skal opplyses om det benyttes underleverandører for å oppfylle kravene/tjenestene. Det er kun data angitt i Leverandørens løsningsbeskrivelse som danner grunnlaget for evalueringen. Svarene gies i bilag 2 til avtalen, der kravtabellen er kopiert inn. Hvis utfyllende informasjon finnes i et bilag, må eksakt referanse oppgis. Kravene er beskrevet i to tabeller i pkt. 5.1.1 og består av skal krav (SK) og bør krav (BK), men er for øvrig ikke listet i prioritert rekkefølge. 4.3 Formål Formålet med denne anskaffelsen er å etablere en rammeavtale som dekker anskaffelse av lagringsmedier og infrastruktur for lagring av data under administrasjon av departementenes servicesenter: lagringsprodukter inklusivt SAN, NAS og hardware for laging av backup tilhørende infrastruktur tilhørende software produkter tilhørende tjenester Avtalen skal dekke lagringsbehovene til DSS, og de departementer som knytter seg til avtalen, i avtaleperioden på opptil 4 år, samt vedlikehold av lagringsutstyr og relatert software, regulert i egen vedlikeholdsavtale. Eksisterende USP skal avvikles og erstattes med ny lagringsløsning, alt annet enn USP skal videreføres inntil det blir erstattet ved endt livssyklus.
Løsningen skal kunne utvides i takt med behovene til departementenes IT-løsninger, ved oppretting av nye systemer, og naturlig lagringsvekst Kunne driftes på en effektiv måte, gjennom gode egenskaper og verktøy i løsningen som sikrer minst mulig nedetid 4.4 Leveranseomfang I dette tilbudsgrunnlaget har vi utarbeidet flere eksempelkonfigurasjoner. Formålet med disse er å sammenligne tilbudene i tråd med evalueringskriteriene. De vil kunne legges til grunn for eventuelle avrop på avtalen. 5 Krav 5.1 Beskrivelse av krav Krav består av skal krav (SK) og eventuelt bør krav (BK). Dersom leverandøren ikke oppfyller skal kravene, vil tilbudet kunne bli avvist. Tabell under skal benyttes i Bilag 2 som leverandørens svar på Kundens krav. Alle forutsetninger og informasjon i dette dokument er gjeldende.
6 Felleskrav Felleskrav SK1 SK2 SK3 BK1 SK4 Tilbudte produkter må kunne fungere med eksisterende SANinfrastruktur (se bilag 3). Leverandøren er ansvarlig for at produkter og løsninger som tilbys gjennom rammeavtalen samspiller med DSS sin eksisterende løsning. Eventuell tid som Leverandøren måtte bruke på å kvalitetssikre og teste dette, betegnes kvalifisering og skal være inkludert i prisene i rammeavtalen. Kvalifisering skal være gjennomført før levering, og skal være inkludert i de leveransetider som Leverandøren tilbyr. Modulære løsninger skal kunne installeres i DSS sin egne Rittal rack. Leverandøren bør tilrettelegge for en innbytteordning. Leverandøren må dokumentere denne pante/innbytteordningen. Tilbudte produkter skal beskrives mht. følgende miljøfaktorer: Renhet; Minimal bruk av giftsstoffer Stråling; Lavest mulig varmeutstråling fra produktet Energi; Lavest mulig strømforbruk Leverandøren bes også beskrive annen relevant informasjon knyttet til miljø, som for eksempel eventuelle miljøsertifiseringer eller miljøstandarder. Side 6 av 21
SK5 Leverandør skal kaste defekt utstyr på forskriftsmessig måte. Det skal senest ved kontraktinngåelse fremlegges dokumentasjon for at leverandøren er medlem i en returordning eller oppfyller forpliktelsen gjennom egen returordning med egen ordning for sluttbehandling hvor emballasjen blir tatt hånd om på en miljømessig forsvarlig måte (Grønt Punkt Norge AS eller tilsvarende ordning). SK6 Leverandøren skal gi DSS sine beste leveringstider. SK7 Leverandøren skal beskrive hvordan Kunden kan tilegne seg kompetanse og sertifiseringer på tilbudt løsning. Side 7 av 21
7 Arkitektur og funksjonalitet Arkitektur SK8 Gi en overordnet beskrivelse av tilbudt produktspekter, og hvordan disse produktene kan bidra til å realisere Kundens mål. Benytt eventuelt eget vedlegg SK9 Gi en oversiktlig, overordnet og kortfattet beskrivelse av funksjonalitet, oppbygging, virkemåte og administrasjon for tilbudte produkter. Benytt eventuelt eget vedlegg SK10 Gi en kortfattet beskrivelse av hvordan tilbudte produktfamilier utvides og skaleres i ytelse og volum for å tilpasses fremtidige behov. Benytt eventuelt eget vedlegg. For produktene som tilbys i eksempelkonfigurasjon 1 skal komponenter for videre skalering markeres med kryss i egen kolonne i kjøpsavtalen bilag 7, under fanen eksempelkonfigurasjon 1. SK11 Gi en overordnet beskrivelse av hvordan Kunden kan migrere til Eksempelkonfigurasjon 1 Midrange SAN fra dagens løsning med minst mulig nedetid. Inkluder en kortfattet prosjektplan og et overslag av tidsforbuk på hver hovedaktivitet. Benytt eventuelt vedlegg Side 8 av 21
SK12 Gi en samlet oversikt over funksjonalitet i tilbudte lagringsprodukter som ikke er etterspurt i spesifikke krav i eksempelkonfigurasjonene, men som leverandøren mener kan være til nytte for Kunden. Benytt eventuelt eget vedlegg Side 9 av 21
Funksjonalitet BK2 Produktporteføljen bør ha komponenter som støtter virtualisering eller clustring av LUNs, enten ved bruk av funksjonalitet i diskkabinettene eller ved bruk av eksternt virtualiseringslag. Et minimumskrav til funksjonalitet ved virtualisering/clustring er at to speilede LUN på to ulike lokasjoner kan fremstå som et LUN for en host uten at noen agenter eller scripts må konfigureres på host. Speilingen av det virtuelle LUNet mot de to bakenforliggende LUNene må skje synkront. En hver form for failover som må gjøres ved feil på en site må skje automatisk uten nedetid for hosten. BK3 Det er ønskelig at løsningen skal kunne administreres av et felles grensesnitt. Dette vil forenkle administrasjon og således minske driftskostnader og øke stabilitet. Administrasjonsverktøyet bør støtte: - Soning av svitsjer - Oppretting av LUNs - Tildeling av LUNs til tjenere Gi en kort beskrivelse av verktøyet og hvilke produktfamilier som kan administreres av løsningen. Side 10 av 21
8 Eksempelkonfigurasjoner 8.1 Eksempelkonfigurasjon 1 Middlerange SAN Hovedmålet med denne konfigurasjonen er å bygge opp en to-site arkitektur, med clustrede miljøer og synkron speiling av data. Ved feil på diskkabinett eller SAN infrastruktur på en site skal en failover skje automatisk. I denne eksempelkonfigurasjonen tas det utgangspunkt i at alle tilknyttede klienter allerede er konfigurert med Symantec Storage Foundation som håndterer all speiling av data og failover mellom sitene. Eksempelkonfigurasjonen skal dekke følgende behov for volum og ytelse: Netto TB Forbrukt TB IOPS kl 08-16 IOPS kl 16-08 MB/s kl 08-16 MB/s kl 16-08 Exchange 4 2,5 2600 4700 12 100 SQL / Oracle 4 1 2000 4800 35 200 Fil 10 7 650 3500 15 60 Vmware 5 1,5 500 900 30 30 Responstid skal ikke gå over 6 ms mellom 8-16 og 12 ms mellom 16-08. Løsningen settes opp med vedlikeholdsnivå 1 ref vedlikeholdsavtalen bilag 1. Løsningen skal benytte enten SAS, FC eller SD disker. SK13 Kravene i beskrivelsen over er oppfylt av konfigurasjonen. Opplys hvor mange netto TB løsningen omfatter i kommentarer. Side 11 av 21
SK14 Leverandøren skal opplyse om alle komponenter, lisenser etc med priser og vedlikeholdspriser som inngår i denne eksempelkonfigurasjonen i hhv bilag 7 for kjøpsavtalen og bilag 7 for vedlikeholdsavtalen. Hver eksempelkonfigurasjon har sin egen fane i bilaget. SK15 Kunden ønsker å standardisere i så stor grad som mulig for å forenkle administrasjon og driftsrutiner samt unngå eventuelle kompatibilitetsproblemer i fremtiden. I eksempelkonfigurasjonen skal alle hovedkomponenter i løsningen leveres fra samme produktfamilie. I de tilfeller hvor mindre komponenter fra andre produsenter eller familier benyttes, må dette spesifiseres eksplisitt. Side 12 av 21
SK16 Løsningen skal teoretisk kunne levere minimum 99,999% oppetid når den er satt opp etter Leverandørens spesifikasjoner. Kontrollere er redundante, slik at én kan svikte uten å påvirke tilgjenglighet. All bytting av deler og generelt vedlikehold, som oppdatering av mikrokode på kontroller og disker, skal kunne gjøres uten driftsbrudd. Der utbytting av deler eller oppgradering av mikrokode påvirker ytelsen skal det spesifiseres. Løsningen skal kunne bygges ut uten nedetid. Under ingen omstendigheter skal interne komponenter eller eksterne faktorer som strøm eller kjøling kunne føre til korrupsjon eller datatap de første 48 timer. Eneste unntak er fysisk skade som følger av brann, vannlekkasje etc. Løsningen skal kunne overvåkes av leverandør, passivt. Det vil si at enheten rapporterer ut til leverandør. Overvåkingen skal kunne monitoreres 24/7. SK17 Speiling skal kunne gjøres synkront på dedikert / svart fiber mellom enheter av samme modell, forutsatt at avstanden mellom enhetene er innen anbefalte grenser. Se spesielt punkt for bruk av klientbasert speiling i innledningen til denne eksempelkonfigurasjonen. Side 13 av 21
SK18 Utvidelser av LUN på tilkoblede LUNs må kunne gjøres fra diskkabinettet uten at det påvirker tilgjengelighet eller ytelse på eksisterende LUN. Dette forutsetter at hosten håndterer utvidelse av LUN og volume. SK19 Det skal være mulig å ta snapshots av LUNs. Snapshots av et LUN skal kunne gjøres uten brudd i tilgjengelighet. Hvis snapshot påvirker ytelsen på LUNet bes leverandøren spesifisere dette. Snapshotet skal kunne legges tilbake som en skrivbar klone. SK20 Tilbudt løsning skal støtte tilkobling av LUNs med multipath for følgende operativsystemer: Windows Server 2000, 2003, 2008 VMware ESX 4 SK21 Diskkabinettene skal ha støtte for multipath oppsett mot host, med et minimum krav til aktiv/passiv konfigurasjon. Failover til passiv path skal ikke føre til nedetid på LUNet. SK22 LUNs skal kunne tildeles med thin provisioning. LUNs som er tildelt med thin provisioning må kunne overvåkes av medfølgende programvare, slik at lagringsansvarlig til en hver tid har status på ledig kapasitet og mulighet for varsler (e-post, snmp eller tilsvarende) ved angitte terskelverdier. SK23 Leverandøren skal oppgi leveringstid på de komponenter som trengs for å skalere løsningen etter initielt oppsett; diskhyller, og disker med medfølgende utstyr. Side 14 av 21
SK24 Leverandøren skal kunne levere og produksjonssette løsningen før utgangen av Q3 2010, forutsatt at signert kontrakt og avrop er gjort slik som beskrevet i tentativ plan i konkurransegrunnlaget. Side 15 av 21
8.2 Eksempelkonfigurasjon 2 Enterprise SAN Hovedmålet med denne konfigurasjonen er å bygge opp en to-site arkitektur, med clustrede miljøer og synkron speiling av data. Ved feil på diskkabinett eller SAN infrastruktur på en site skal en failover skje automatisk. I denne eksempelkonfigurasjonen tas det utgangspunkt i at alle tilknyttede klienter allerede er konfigurert med Symantec Storage Foundation som håndterer all speiling av data og failover mellom sitene. Eksempelkonfigurasjonen skal dekke følgende behov for volum og ytelse: Netto TB Forbrukt TB IOPS kl 08-16 IOPS kl 16-08 MB/s kl 08-16 MB/s kl 16-08 SQL / Oracle 4 1 2000 4800 35 200 Responstiden skal ikke gå over 5 ms mellom 8-16 og ikke over 10 ms mellom 16-08. Løsningen settes opp med vedlikeholdsnivå 1 ref vedlikeholdsavtalen bilag 1. Løsningen skal benytte enten SAS, FC eller SD disker. SK25 Kravene i beskrivelsen over er oppfylt av konfigurasjonen. Opplys hvor mange netto TB løsningen omfatter i kommentarer. Side 16 av 21
SK26 Leverandøren skal opplyse om alle komponenter, lisenser etc med priser og vedlikeholdspriser som inngår i denne eksempelkonfigurasjonen i hhv bilag 7 for kjøpsavtalen og bilag 7 for vedlikeholdsavtalen. Hver eksempelkonfigurasjon har sin egen fane i bilaget. SK27 Kunden ønsker å standardisere i så stor grad som mulig for å forenkle administrasjon og driftsrutiner samt unngå eventuelle kompatibilitetsproblemer i fremtiden. I eksempelkonfigurasjonen skal alle hovedkomponenter i løsningen leveres fra samme produktfamilie. I de tilfeller hvor mindre komponenter fra andre produsenter eller familier benyttes, må dette spesifiseres eksplisitt. SK28 Speiling skal kunne gjøres synkront på dedikert / svart fiber mellom enheter av samme modell, forutsatt at avstanden mellom enhetene er innen anbefalte grenser. Se spesielt punkt for bruk av klientbasert speiling i innledningen til denne eksempelkonfigurasjonen. Side 17 av 21
SK29 Løsningen skal teoretisk kunne levere 100% oppetid når den er satt opp etter Leverandørens spesifikasjoner. Samtlige komponenter (for eksempel CPU) i diskkabinettet er redundante, fra fiberport til den fysiske disk, slik at enhver enkeltkomponent kan svikte uten å påvirke tilgjenglighet. All bytting av deler og generelt vedlikehold, som oppdatering av mikrokode på kontroller og disker, skal kunne gjøres uten driftsbrudd. Der utbytting av deler eller oppgradering av mikrokode påvirker ytelsen skal det spesifiseres. Løsningen skal kunne bygges ut uten nedetid. Under ingen omstendigheter skal interne komponenter eller eksterne faktorer som strøm eller kjøling kunne føre til korrupsjon eller datatap de første 48 timer. Eneste unntak er fysisk skade som følger av brann, vannlekkasje etc. Løsningen skal kunne overvåkes av leverandør, passivt. Det vil si at enheten rapporterer ut til leverandør. Overvåkingen skal kunne monitoreres 24/7. SK30 Det skal være mulig å flytte LUNs transparent internt på lagringsenheten. Med transparent menes at tilknyttede hosts ikke må konfigureres mot nytt LUN etter migrering og ikke opplever noe nedetid på LUNet under migreringen.. Migreringen må kunne gjøres på kryss av RAID-grupper/diskpools. Side 18 av 21
SK31 Utvidelser av LUN på tilkoblede LUNs må kunne gjøres fra diskkabinettet uten at det påvirker tilgjengelighet eller ytelse på eksisterende LUN. Dette forutsetter at hosten håndterer utvidelse av LUN og volume. SK32 Utvidelser av LUN på tilkoblede LUNs må kunne gjøres fra diskkabinettet uten at det påvirker tilgjengelighet eller ytelse på eksisterende LUN. Dette forutsetter at hosten håndterer utvidelse av LUN og volume. SK33 Tilbudt løsning skal støtte tilkobling av LUNs med multipath for følgende operativsystemer: Windows Server 2000, 2003, 2008 VMware ESX 4 SK34 Diskkabinettene skal ha støtte for multipath oppsett mot host, med et minimum krav til aktiv/passiv konfigurasjon. Failover til passiv path skal ikke føre til nedetid på LUNet. SK35 LUNs skal kunne tildeles med thin provisioning. LUNs som er tildelt med thin provisioning må kunne overvåkes av medfølgende programvare, slik at lagringsansvarlig til en hver tid har status på ledig kapasitet og mulighet for varsler (e-post, snmp eller tilsvarende) ved angitte terskelverdier. SK36 Kontrollerne skal ha støtte for lastbalansering med aktiv/aktiv konfigurasjon for tjenere med multipath. Side 19 av 21
8.3 Eksempelkonfigurasjon 3 Diskbasert backupløsning Hovedmålet med denne konfigurasjonen er å bygge løsning for diskbasert håndtering av backupdata fra produksjonsmiljøene til ett site. Eksempelkonfigurasjonen skal dekke følgende behov for volum og ytelse: Netto TB Forbrukt TB IOPS kl 08-16 IOPS kl 16-08 MB/s kl 08-16 MB/s kl 16-08 Backup 30 30 3000 3000 240 240 Løsningen settes opp med vedlikeholdsnivå 2 ref vedlikeholdsavtalen bilag 1. SK37 Kravene i beskrivelsen over er oppfylt av konfigurasjonen. Opplys hvor mange netto TB løsningen omfatter i kommentarer. SK38 Leverandøren skal opplyse om alle komponenter, lisenser etc med priser og vedlikeholdspriser som inngår i denne eksempelkonfigurasjonen i hhv bilag 7 for kjøpsavtalen og bilag 7 for vedlikeholdsavtalen. Hver eksempelkonfigurasjon har sin egen fane i bilaget. Side 20 av 21
SK39 Løsningen skal teoretisk kunne levere minimum 98% oppetid når den er satt opp etter Leverandørens spesifikasjoner. Kontrollere er redundante, slik at en kan svikte uten å påvirke tilgjenglighet. All bytting av deler og generelt vedlikehold, som oppdatering av mikrokode på kontroller og disker, bør kunne gjøres uten driftsbrudd. Det er aksept for ytelsestap ved planlagt vedlikehold eller feil på sentrale komponenter. Løsningen skal kunne overvåkes av Kunden. SK40 Kunden ønsker å standardisere i så stor grad som mulig for å forenkle administrasjon og driftsrutiner samt unngå eventuelle kompatibilitetsproblemer i fremtiden. I eksempelkonfigurasjonen skal alle hovedkomponenter i løsningen leveres fra samme produktfamilie. I de tilfeller hvor mindre komponenter fra andre produsenter eller familier benyttes, må dette spesifiseres eksplisitt. SK41 Diskkabinettet skal ha innebygget støtte for deduplisering. Side 21 av 21