Lösningsförslag och leverans

Transkript

1 Bilaga A Lösningsförslag och leverans A.1 Lösningsförslag Referens till gällande ramavtal skall anges. Om tekniska brister kan förutses eller om leverantören kan föreslå kostnadseffektivare lös- ningar än de skisserade utan att göra avkall på prestanda och robusthet med utrustning som kan levereras inom befintliga avtal, bör leverantören presentera förslag som tar hänsyn till sådana förbättringar. Angivna skall- krav skall dock vara uppfyllda. A.1.1 Prisuppgifter Delsummor för varje del i den tekniska specifikationen skall anges. Alternativa lösningsförslag skall vara prissatta. Installationskostnader skall anges separat. Om ytterligare komponenter erfordras utöver de som ingår i lösningsförslag, skall dessa tyd- ligt specificeras med prisuppgift. Totalsumman skall inkludera alla fraktkostnader, kostnader för installation av hårdvara, samt kostnader för att på ett miljövänligt sätt transportera bort och ta hand om allt trans- portmaterial som använts för leverans av hårdvaran. A.1.2 Information Följande information skall anges: Tillverkare av ingående delar och teknisk specifikation för dessa. Konfigurationsförslag: antal rack och placering av komponenter i rack. Krav på installationslokal: golvyta, höjd, plats i rack, vikt, mm. Krav på anslutningar: el- och nätverksanslutningar, lufttemperaturer och flöden. Krav på transportvägar: höjd, bredd och vikt på kolli. En realistisk uppskattning på elförbrukning/kylbehov vid max last och tomgångslast. Hur aggregerad läs och skrivhastighet tagits fram (program, konfiguration, paramet- rar). Antalet I/O- operationer per sekund (IOPS) angivet per volym och per lagringschas- si/diskserver eller motsvarande samt hur det tagits fram (program, konfiguration, pa- 1(16)

2 rametrar). Metadataprestanda enligt avsnitt A.2.3, vilket bör anges per lagringschassi/diskserver eller motsvarande. Information om vilken hårdvara och hur den var konfigurerad samt använd mjukvara och filsystem skall också anges. Läs och skrivprestanda enligt avsnitt A.2.4. För detaljerad teknisk information om ingående komponenter bifogas datablad. Istället för datablad kan referenser till webbsidor lämnas, under förutsättning att innehållet i dessa webbsidor inte ändras på ett betydande sätt under den tid som avropssvaret gäller. A.2 Utvärdering A.2.1 Bedömningskriterier Inkomna lösningsförslag kommer att bedömas enligt följande kriterier: Totalkostnad. I totalkostnad ingår kostnader för hårdvara, installation samt driftkost- nader (lokaler, el, kyla, mm). Lagringens livstid beräknas till fyra år. Beräkning av rör- liga driftkostnader baseras på angiven strömförbrukning 1. Total användbar lagringsyta med formaterat filsystem. Antalet I/O- operationer per sekund (IOPS). Metadataprestanda enligt avsnitt A.2.3. Läs och skrivprestanda enligt avsnitt A.2.4. Leveranstid. Uppfyllande av bör- krav. Arbetsinsats som krävs för administration vid drift, felsökning och service. A.2.2 Processhantering Baserat på bedömningskriterierna enligt ovan görs en utvärdering av inkomna förslag. För- tydliganden av inkomna förslag kan komma att begäras. A.2.3 Metadataprestanda Följande test skall användas för utvärdering av metadataprestanda. I vilken situation det skall köras anges i bilagan för respektive lagringstyp. 1 Ett elpris om 1 kr/kwh används vid uppskattning av driftkostnad. 2(16)

3 Testprocedur: i. En filstruktur skapas genom att nedanstående skript (create- files.sh) körs och tiden för detta noteras. (time create- files.sh) #!/bin/bash mkdir metadata_test cd metadata_test for i in {1..100} do mkdir level1-$i cd level1-$i for j in {1..100} do mkdir level2-$j cd level2-$j for k in {1..100} do dd if=/dev/zero bs=1024 count=1 of=level3-$k done cd.. done cd.. done exit 0 ii. Resultatet för ls enligt time (ls - lr metadata_test wc - l) noteras. iii. Resultatet för find enligt time (find metadata_test - type f - print0 xargs - 0 chmod g+w) noteras. A.2.4 Skriv och läsprestanda Följande test skall användas för utvärdering av skriv och läsprestanda. I vilken situation det skall köras anges i bilagan för respektive lagringstyp. För att skapa och läsa filer används SOB. Källkod finns att hämta på Testprocedur: i. Sob körs enligt date ; sob - w - n s 1G ; date ; sob - V - n s 1G ; date ii. Prestanda övervakas samtidigt med iostat med sampling var 5:e sekund. iii. Resultaten från sob och iostat rapporteras. 3(16)

4 A.3 Leveranskontroll Leveranskontroll sker genom systemkontroll. Systemkontroll omfattar en period om 22 ar- betsdagar och påbörjas tidigast den dag då all hårdvara är installerad på plats och är ström- satt. All installerad utrustning betraktas som en enhet. Under systemkontrollperioden sker installation av mjukvara samt kontroll att alla kompo- nenter, hårdvara såväl som mjukvara fungerar tillsammans enligt avtalad specifikation. Leverantören svarar för felsökning och reparation av hårdvara och dessutom, vid behov, ut- byte av firmware på all utrustning. Leverantör kan avbryta systemkontroll för att utföra preventiv service och förbättrande åt- gärder. Systemkontroll återupptas och fortsätter att löpa efter det att service är avklarad. Systemkontrollperioden förlängs i motsvarande grad. Leverantör kan, då det kan anses mo- tiverat, återstarta systemkontrollen från början efter service. Under systemkontrollperioden finns en mätperiod om trettio (30) dagar där komponenters felfrekvens ej får överstiga avtalade gränsvärden tillgängligheten ej får understiga avtalade gränsvärden Mätperioden är en kontinuerlig, rullande period om 30 kalenderdagar. Avbrott i tillgängligheten som kan härledas vara orsakade av systemprogramvara som instal- lerats av kund eller på annat sätt är hänförligt förhållande på kundens sida påverkar varken felfrekvens eller tillgänglighet. A.3.1 Kriterier för leveransgodkännande Krav rörande funktion och prestanda ställda i avropsförfrågan och bemötta i lösningsförslag kan verifieras på installerad utrustning. Energiförbrukningen på installerad utrustning får ej överskrida det värde som angivits i lös- ningsförslag. Antalet fel får under systemkontrollperioden ej överstiga gränsvärdet 2 fel, räknat separat för varje typ av lagringssystem som specificeras i separata bilagor. Med fel avses händelse som resulterar i driftstopp och kräver reparationsingripande, utbyte av enhet, programvara, firmware eller motsvarande från leverantören. På redundanta komponenter får ytterligare högst tre fel inträffa under systemkontrollperio- den. 4(16)

5 Tillgängligheten för varje separat lagringssystem ska vara sådan att den överskrider 50% momentan tillgänglighet och 99% kontinuerlig tillgänglighet. 2 A.4 Garanti och service Generellt gäller följande för garanti och service. En högre servicenivå kan begäras på vissa delar. Detta specificeras i så fall i den tekniska bilagan. Garantin skall omfatta minst fyra år på systemets samtliga delar. Garantitiden räknas från det att hela systemet godkänts i systemkontroll (se avsnitt iii ovan). För systemet skall som lägsta servicenivå NBD på platsen (Next Business Day on site) tilläm- pas. Systemet bör vara konstruerat så att personal vid centret själva kan byta felaktiga diskar, el- ler delar av systemet som innehåller en felaktig disk. Leverantören skall svara för avancerad felsökning av komponenter och system. A.5 Definitioner Nettolagringsyta är den yta som är tillgänglig för operativsystemet att skapa filsystem på, dvs. ytan efter att redundans för RAID och spare räknats bort. Om så önskas kan istället yta tillgänglig i filsystem anges som nettolagringsyta. Storlekar för lagringsytor baseras på basen 1000 (dvs. 1 GB = 1000³ B = 10⁹ B). Övriga storle- kar (primärminne, bandbredd etc.) baseras på basen 1024 (dvs. 1 GB = 1024³ B = 2³⁰ B). 2 För att en lagringsenhet skall anses vara tillgänglig skall den vara funktionsduglig, anslutna till samtliga nät- verk och kunna leverera sin lagring till anslutna klienter. 5(16)

6 Bilaga B Specifikation dcache-pooler B.1 dcache-lagring En dcache- installation är ett distribuerat lagringssytem där själva filinnehållet finns på ett antal fristående servrar med lokal lagring, så kallade pooler, medan metadata hanteras av en central tjänst. I detta avrop är det bara de distribuerade delarna som är aktuella. I dagens befintliga system, som nu ska expanderas, används geografiskt spridda PC- baserade Linux- eller Solaris- lagringsservrar med eller utan externa disklådor. Då en lokal Java- baserad pro- gramvara används för att accessa datat är inte NAS- lösningar aktuella. Yta/pris är en viktig faktor utan att man kan ge för mycket avkall på datasäkerhet och prestanda. B.2 Kravspecifikation B.2.1 Övergripande krav B1: Servrarna med ingående komponenter skall vara anpassade för kontinuerlig drift dygnet runt. B2: Optioner på både redundant och icke- redundant strömförsörjning skall anges om sådana finns. B3: Servrarna bör vara utrustade med lågenergivarianter av ingående komponenter där sådana finns tillgängliga. B4: Fjärradministration via nätverk via standardprogramvara (IPMI/webläsare/SSH) skall vara möjlig, minimikrav är att kunna slå av/på strömmen. Åtkomst till serie- konsol över nätverk skall vara möjlig. B5: Rackmonteringskit skall ingå. Servrarna kommer att monteras i rack enligt specifika- tion i avropsförfrågans huvuddokument. B.2.2 Krav på kompabilitet med operativsystem B6: Servrar med ingående komponenter skall vara certifierade för det operativsystem som specificeras i avropsförfrågans huvuddokument. B7: Inga extra drivrutiner skall behövas på serversidan för att erhålla en fungerande lösning. Det skall räcka med det som distribueras av operativsystemet. Detta för att säkerställa att uppgraderingar och säkerhetsuppdateringar fungerar. B.2.3 Lagring För uppgift om önskad total storlek på nettolagringsyta, se avropsförfrågans huvuddoku- ment. Servrarna kommer att använda lagring med dubbelparitet (ZFS RAIDZ2, RAID6 etc.), med maximalt 12 diskar i varje RAID- set. Detta innebär att 10 TB nettolagringsyta kan fås ur 12 st. 1 TB diskar. 6(16)

7 B8: Prestandatester (se Bilaga A) skall utföras på server. B9: Varje server skall tillhandahålla minst 10 TB nettolagringsyta. B10: Varje server skall tillhandahålla högst 100 TB nettolagringsyta. B11: Den totala densiteten, räknat på hela lösningen inklusive servrar och eventuella disklådor, skall vara minst 10 TB nettolagringsyta per rackenhet (U). B12: Enskilda hårddiskar skall vara utbytbara under drift (hot- swap). B13: Hårddiskarna bör vara av typen SAS eller SATA. B14: Servrarnas läs och skrivprestanda mot diskarna skall vara minst 200 MB/s vid upp till och med 20 TB nettolagringsyta, med ytterligare 150 MB/s för varje påbörjad 20 TB nettolagringsyta överstigande 20 TB. Exempelvis 650 MB/s vid 80 TB. B15: I det fall att separata disklådor används skall dessa kunna administreras via nät- verksanslutning (out- of- band) och/eller serie- interface. B16: Samtliga diskar bör kunna hanteras direkt av operativsystemet, eventuell RAID- kontroller bör kunna konfigureras för JBOD/pass- through. Om dessa saker kan göras på ett enkelt och effektivt sätt eller ej skall framgå i den föreslagna lösningen. B.2.4 Processorer och Primärminne B17: I varje server skall finnas minst 4 cores. Om den nettolagringsytan i servern översti- ger 40 TB skall det finnas minst 8 cores fördelade på minst två CPUer. B18: Varje server skall vara utrustad med minst 8 GB primärminne. Ytterligare 8 GB skall finnas för varje påbörjad 20 TB nettolagringsyta. Exempelvis 32 GB primärminne vid 80 TB nettolagringsyta. B19: Levererat minne skall vara jämnt fördelat över alla tillgängliga minneskanaler för optimal prestanda. B.2.5 Systemdisk B20: Operativsystem skall kunna installeras på redundant media. B.2.6 Nätverk B21: Varje server skall vara utrustad med minst dubbla Gigabit Ethernet (1000Base- T) nätverksinterface. Om nettolagringsytan i servern överstiger 40 TB skall det finnas minst fyra Gigabit Ethernet nätverksinterface. B22: Servrarna skall kunna bootas via PXE. B23: Managementnätverksport skall vara separat från ovanstående och skall ej vara åt- komlig från operativsystemet som ett normalt nätverksinterface. 7(16)

8 B24: Om nettolagringsytan i servern överstiger 20 TB skall servern kunna uppgraderas till 10Gbit Ethernet nätverksinterface (t.ex. genom att ha en ledig PCIe kortplats). Detta bör i så fall finnas med som option. 8(16)

9 Bilaga C Specifikation gridcache C.1 Gridcache En gridcache användas för mellanlagring av stora datamängder som behövs för vissa typer av beräkningsjobb. Gridcachen består av ett eller flera fristående filsystem som skall finnas till- gängliga på beräkningsnoderna. Då gridcachen ska hantera ett stort antal samtidiga filacces- ser från beräkningsjobb ställs det höga krav på förmågan att hantera många samtidiga läs- ningar (IOPS). Dessa läsningar sker från Linux- baserade beräkningsnoder (t.ex. via NFS) och sprids över gridcachens filsystemen. I dagens befintliga system används PC- baserade Linux- eller Solaris- lagringsservrar med eller utan externa disklådor. Filsystemen exporteras via NFS till beräkningsnoderna. Andra lös- ningar med mer specialiserad hård- och mjukvara (NAS) kan vara aktuell i avropet. Kraven är ställda för att kunna omfatta båda typerna av lagring. Vissa skall- krav är dock satta för ende- ra typen. C.2 Kravspecifikation C.2.1 Övergripande krav C1: Servrarna med ingående komponenter skall vara anpassade för kontinuerlig drift dygnet runt. C2: Servrarna och eventuella disklådor skall vara utrustade med redundant strömför- sörjning. C3: Servrarna bör vara utrustade med lågenergivarianter av ingående komponenter där sådana finns tillgängliga. C4: Fjärradministration via nätverk via standardprogramvara (IPMI/webläsare/SSH) skall vara möjlig, minimikrav är att kunna slå av/på strömmen. Åtkomst till serie- konsol över nätverk skall vara möjlig. C5: Rackmonteringskit skall ingå. Servrarna kommer att monteras i rack enligt specifika- tion i avropsförfrågans huvuddokument. C6: Klienter, dvs. beräkningsnoder, skall kunna använda det operativsystem som anges i huvuddokumentet. C.2.2 Krav på kompatibilitet med operativsystem C7: Om en lösning med generella servrar offereras, skall dessa med ingående kompo- nenter vara certifierade för det operativsystem som specificeras i avropsförfrågans huvuddokument. 9(16)

10 C8: Inga extra drivrutiner skall behövas på serversidan för att erhålla en fungerande lösning. Det skall räcka med det som distribueras av operativsystemet. Detta för att säkerställa att uppgraderingar och säkerhetsuppdateringar fungerar. Dessa skall- krav behöver inte beaktas för NAS- lösningar. C.2.3 Lagring C9: För uppgift om önskad storlek på nettolagringsyta, se avropsförfrågans huvuddo- kument. C10: Lagring med paritet (ZFS RAIDZ, RAID5 eller motsvarande) och spegling (RAID1 eller RAID10) skall kunna användas. I avropssvaret skall storleken på nettolagringsyta och prestandasiffror anges vid paritet och maximalt 6 diskar i varje RAID- set. C11: Prestandatester (se bilaga A) skall utföras på klient med monterat filsystem. C12: Varje server skall tillhandahålla minst 10 TB nettolagringsyta. C13: Varje server skall tillhandahålla högst 100 TB nettolagringsyta. C14: Enskilda hårddiskar skall vara utbytbara under drift (hot- swap). C15: Hårddiskarna bör vara av typen SAS eller SATA. C16: För generella servrar gäller att lokal sekventiell läs och skrivprestanda mot lagrings- utrymmet skall vara minst 200 MB/s. För varje påbörjad 20 TB nettolagringsyta överstigande 10 TB skall detta ökas med 100 MB/s, dvs. 10 TB 200 MB/s, 20 TB 300 MB/s, 40 TB 400 MB/s etc. C17: För NAS- lösningar gäller att sekventiell läs och skrivprestanda skall vara tillräcklig för att fylla de nätverksinterface som specificeras i avsnitt C.2.6 Nätverk. C18: Den levererade lösningens aggregerade prestanda för slumpvis läsning skall översti- ga 800 IOPS per 10 TB nettolagringsyta. C19: I det fall att separata disklådor används skall dessa kunna administreras via nät- verksanslutning (out- of- band) och/eller serie- interface. C20: Samtliga diskar bör kunna hanteras direkt av operativsystemet, eventuell RAID- kontroller bör kunna konfigureras för JBOD/pass- through. Om dessa saker kan göras på ett enkelt och effektivt sätt eller ej skall framgå i den föreslagna lösningen. C.2.4 Processorer och primärminne C21: I varje server skall finnas minst 4 cores. Om nettolagringsytan i servern överstiger 40 TB skall det finnas minst 8 cores fördelade på minst två CPUer. C22: Varje server skall vara utrustad med minst 8 GB primärminne. Om nettolagringsytan i servern överstiger 40 TB skall det finnas minst 16 GB primärminne. 10(16)

11 C23: Levererat minne skall vara jämnt fördelat över alla tillgängliga minneskanaler för optimal prestanda. Dessa skall- krav behöver inte beaktas för NAS- lösningar. C.2.5 Systemdisk C24: Operativsystem skall kunna installeras på redundant media. C.2.6 Nätverk C25: Varje server skall vara utrustad med minst dubbla Gigabit Ethernet (1000Base- T) nätverksinterface. Om nettolagringsytan i servern överstiger 40 TB skall det finnas minst fyra Gigabit Ethernet nätverksinterface. C26: Generella servrar skall kunna bootas via PXE. C27: Managementnätverksport skall vara separat från ovanstående och skall ej vara åt- komlig från operativsystemet som ett normalt nätverksinterface. C28: Om nettolagringsytan i servern överstiger 20 TB skall servern kunna uppgraderas till 10Gbit Ethernet nätverksinterface (t.ex. genom att ha en ledig PCIe kortplats). Detta bör i så fall finnas med som option. 11(16)

12 Bilaga D Specifikation centrumlagring D.1 Centrumlagring Centrumlagringen kommer att användas på samma sätt som man traditionellt använt klus- terlagring, dvs. alla beräkningsnoder arbetar mot denna lagring 3. Skillnaden här är att samt- liga kluster och andra användarresurser vid det enskilda centret ska kunna använda denna lagring samtidigt. Att samtliga resurser samtidigt ska kunna arbeta mot centrumlagringen ställer givetvis höga krav både på prestanda och på tillförlitlighet för lösningen. Att data lagras säkert vad avser korruption och användarmisstag är en sökt egenskap. Att data har hög tillgänglighet är en annan. Prestandan bör kunna vidstå att många användare samtidigt läser och skriver från denna lagring. Snabbhet är av vikt här men att systemet skall vara tolerant mot höga laster är än viktigare. D.2 Kravspecifikation D.2.1 Övergripande krav D1: Lösningen skall kunna integreras i ett centrums befintliga miljö. Den skall vara PO- SIX kompatibel. D2: En så kallad global namnrymd (global namespace) bör användas. D3: Lösningen skall kunna lastbalansera mellan de olika ingående delarna. Vad som kan lastbalanseras och på vilket sätt detta sker skall anges. D4: Access via parallellt filsystem och access via NFS skall båda kunna användas, detta bör kunna ske samtidigt och till samma volym. D5: Quota för minst 600 användare skall hanteras, lösningen bör hantera över 1000 st. Quota för grupper bör hanteras. D6: Lösningen skall kunna skötas via ett kommandogränssnitt (CLI) med hjälp av ssh el- ler telnet, men bör även kunna skötas och övervakas via ett grafiskt gränssnitt. D7: Klienter som använder Redhat Enterprise Linux 5.4 (eller senare) eller derivat därav skall kunna används. D8: Systemet skall kunna anslutas med Gigabit Ethernet (1000Base- T) men bör kunna anslutas med 10Gbit Ethernet och/eller Infiniband, vilket i så fall bör finnas med som option. 3 Exempelvis som centrumvid hemmakatalog för användare och projekt. 12(16)

13 D9: Integration med backuptjänst av typ IBM- TSM bör kunna ske på ett enkelt sätt. En beskrivning av hur detta görs skall då ges. D10: Support i fyra år på det parallella filsystemet skall finnas med som option. D11: Alla nödvändiga och rekommenderade licenser som kan behövas för effektiv an- vändning av systemet bör vara inkluderade. De skall finnas med som option. D.2.2 Storlek och prestanda D12: Nettolagringsytan skall vara minst 60 TB och skall vara lätt att expandera när behov uppstår. Detta skall kunna ske utan att det påverkar tillgängligheten på systemet. D13: Lagringslösningen skall ha en aggregerad prestanda på minst 350 MB/s för läsning och 350 MB/s för skrivning, per 20 TB nettolagringsyta. Om tekniskt möjligt bör op- tion ges för aggregerad prestanda på minst 600 MB/s för läsning och skrivning per 20 TB nettolagringsyta. D14: Prestandatester (se Bilaga A) skall utföras på klienter som ansluter dels via NFS, dels via det i förslaget ingående parallella filsystemet. Dessa tester bör utföras med 1, 2, 4, 8 osv. om möjligt upp till 256 samtidiga instanser. Hur många maskiner dessa var fördelades på skall då anges. D.2.3 Redundans och tillgänglighet D15: Lösningen skall ha en redundans som tillåter att en godtycklig lagringsenhet 4 går ner utan förlust av data. Rekonstruktion av data skall kunna ske utan att tillgänglig- heten på systemet begränsas och utan att systemets prestanda underskrider de specificerade gränsvärdena ovan med mer än 20 %. D16: En godtycklig systemkomponent 5 skall kunna går ner utan att det påverkar tillgäng- ligheten. D.2.4 Dataskydd D17: Lösningen skall ha möjlighet för snapshots som användare lätt kommer åt. Den bör klara av 50 samtidiga snapshots per volym 6 under uppfyllande av prestandakraven ovan. D18: Stöd för end- to- end data checksums bör finnas. På vilket sätt detta är implemen- terat skall beskrivas. D19: Det bör finnas stöd för att detektera silent corruption. Hur detta hanteras skall beskrivas. 4 Med lagringsenhet menas här disk, diskchassi etc. 5 Med systemkomponent menas här server, switch eller liknande. 6 Med volym avses en enhet som monteras som ett filsystem på klient. 13(16)

14 D.2.5 Garanti och service D20: För systemet skall som lägsta servicenivå NBD på platsen (Next Business Day on site) tillämpas. D21: För kritiska delar skall en servicenivå med högst 4 timmars inställelsetid (kontorstid vardagar) tillämpas. Som kritisk del räknas en enhet i systemet som gör att tillgäng- ligheten för andra delar än enheten själv påverkas. 14(16)

15 Bilaga E Specifikation LBIC lagring E.1 Virtualisering och lagringslösning för LBIC Lösningen skall användas för att erbjuda användare vid Lund Bioimaging Center (LBIC) tjäns- ter och lagring för medicinska skannrar som installeras under våren- sommaren Lös- ningen skall bestå av 2 fysiska servrar som i en redundant konfiguration skall leverera en vir- tuell miljö. Servrarna ansluts till en lagringslösning som skall erbjuda lagring för den virtuella miljön samt lagring för rådata från de medicinska skannrarna. Utrustningen kommer att an- slutas till ett internt nätverk samt existerande nätverk på LBIC via Gigabit Ethernet alterna- tivt 10Gbit Ethernet. Att data lagras säkert vad avser korruption och användarmisstag är en sökt egenskap. Att data har hög tillgänglighet är en annan. Prestandan bör kunna vidstå att många användare samtidigt läser och skriver från denna lagring. Snabbhet är av vikt här men att systemet skall vara tolerant mot höga laster är än viktigare. E.2 Kravsepcifikation E.2.1 Övergripande krav E1: Lösningen skall kunna integreras i ett centrums befintliga miljö. Den skall vara PO- SIX kompatibel. E2: Lösningen skall vara certifierad för VMWare. E3: Access via SMB (Windows file sharing) och access via NFS skall båda kunna använ- das, detta bör kunna ske samtidigt och till samma volym. E4: Lagringsutrustningen skall kunna skötas via ett kommandogränssnitt (CLI) med hjälp av ssh eller telnet, men bör även kunna skötas och övervakas via ett grafiskt gräns- snitt. E5: Systemet skall kunna anslutas med Gigabit Ethernet (1000Base- T) men bör kunna anslutas med 10Gbit Ethernet, vilket i så fall bör finnas med som option. E6: Alla nödvändiga och rekommenderade licenser som kan behövas för effektiv an- vändning av systemet bör finnas med men skall finnas med som option. E.2.2 Storlek och prestanda E7: Nettolagringsytan skall vara minst 40 TB, och skall vara lätt att expandera när behov uppstår. Detta skall kunna ske utan att det påverkar tillgängligheten på systemet. 15(16)

16 E.2.3 Redundans och tillgänglighet E8: Lösningen skall ha en redundans som tillåter att en godtycklig lagringsenhet 7 går ner utan förlust av data. Rekonstruktion av data skall kunna ske utan att tillgänglig- heten på systemet begränsas och utan att systemets prestanda försämras med mer än 20 %. E9: En godtycklig systemkomponent 8 skall kunna går ner utan att det påverkar tillgäng- ligheten. E.2.4 Dataskydd E10: Stöd för end- to- end data checksums bör finnas. På vilket sätt detta är implemen- terat skall beskrivas. E11: Det bör finnas stöd för att detektera silent corruption. E.2.5 Garanti och service E12: För systemet skall som lägsta servicenivå NBD på platsen (Next Business Day on site) tillämpas. E13: För kritiska delar skall en servicenivå med högst 4 timmars inställelsetid (kontorstid vardagar) tillämpas. Som kritisk del räknas en enhet i systemet som gör att tillgäng- ligheten för andra delar än enheten själv påverkas. 7 Med lagringsenhet menas här disk, diskchassi etc. 8 Med systemkomponent menas här server, switch eller liknande. 16(16)