Část 2 zadávací dokumentace Technická dokumentace a specifikace předmětu koupě Úvod k technickému zadání Zadavatel požaduje nabídku na níže specifikované řešení. Specifikace řešení se skládá z pěti částí (kapitol): první část popisuje datová úložiště včetně souvisejících komponent (část A). druhá část popisuje serverovou část včetně souvisejících komponent (část B). třetí část popisuje software pro serverovou virtualizaci (část C). pátá část (část E) popisuje akceptační testy. Čtvrtá část (část D) popisuje technologické prostředí, do něhož bude plnění poskytnuto. Součástí jednotlivých částí je textový popis a případně specifikace dílčích komponent pomocí tabulek. Údaje uvedené v jednotlivých částech této technické dokumentace a specifikace vymezují závazné požadavky zadavatele na plnění této veřejné zakázky. Tyto požadavky musí uchazeč plně respektovat při tvorbě své nabídky. Pro celé řešení (tj. všechny jeho části) požaduje zadavatel dodání originálních a nových zařízení, licencovaných na jméno zákazníka (zadavatele) a podle pravidel výrobce tak, aby bylo možné eskalovat případné závady přímo na technickou podporu výrobce. Zadavatel požaduje, aby všechny licence, které budou dodány v rámci tohoto řešení, byly časově neomezené (bez exspirace). Plnění veřejné zakázky je včetně dodávky, instalace a zprovoznění (uvedení do řádného provozu) potřebného software (licencí), potřebného specifikovaného zaškolení IT personálu a dalšího potřebného příslušenství a poskytnutí rozšířené záruky a servisu a dalších souvisejících služeb v lokalitě Vestec. Pokud jsou v technické specifikaci obsaženy požadavky nebo odkazy na jednotlivé obchodní firmy, názvy nebo jména a příjmení, specifická označení zboží a služeb, která platí pro určitou osobu nebo 1/32
organizační složku za příznačné, popř. patenty na vynálezy, užitné vzory, průmyslové vzory, ochranné známky nebo označení původu, jsou uvedeny pouze pro upřesnění a přiblížení technických parametrů a zadavatel umožňuje použití i kvalitativně a technicky obdobného řešení s plně srovnatelnými nebo i převyšujícími parametry. V případě potřeby může chtít zadavatel doložit (vyžádat si) oficiální potvrzení zastoupení výrobce o určení dodávaného HW (resp. seznam sériových čísel všech dodávaných zařízení) pro český trh či v rámci EU a koncového zákazníka Biotechnologické a biomedicínské centrum Akademie věd a Univerzity Karlovy ve Vestci (BIOCEV). Zadavatel v rámci nabídky uchazeče, požaduje dodat kompletní technický popis (specifikaci) všech komponent (zařízení) u všech částí řešení. K veškeré funkcionalitě požadované v této zadávací dokumentaci musí v době podání nabídky existovat uživatelská dokumentace v anglickém nebo českém jazyku, kterou uchazeč na vyžádání zadavatele neprodleně předloží, a která tuto funkcionalitu jednoznačně deklaruje (popisuje). Definice záručních skupin dle délky záruky Záruční skupiny: 3 roky 5 let U jednotlivých částí řešení jsou tyto záruční skupiny dále upřesněny. Po dobu záruky se očekává bezplatné provedení servisu dle požadované servisní skupiny. Definice servisních skupin dle rychlosti reakce a opravy: Popis: Servis je předpokládán v místě plnění, tj. tam kde jsou instalována zařízení. Použité termíny (zkratky) jsou NBD (Next business day), tj. "další pracovní den", a BD (Business day), tj. "pracovní den". Skupiny: skupina č. 1: dostupnost 5x8 (po-pá, od 8-16h) + reakce do NBD + oprava do 21 BD (na místě u zákazníka) skupina č. 2: dostupnost 5x8 (po-pá, od 8-16h) + reakce do NBD + oprava do 5 BD (na místě u zákazníka) skupina č. 3: dostupnost 5x9 (po-pá, od 8-17h) + reakce do NBD + oprava do NBD (na místě u zákazníka) skupina č. 4: dostupnost 24x7x365 (24 hodin + po-ne + po celý kalendářní rok) + reakce do 8 hodin + oprava do 24 hodin (na místě u zákazníka) 2/32
skupina č. 5: dostupnost 24x7x365 (24 hodin + po-ne + po celý kalendářní rok) + reakce do 4 hodin + oprava do 24 hodin (na místě u zákazníka) U jednotlivých částí řešení jsou tyto servisní skupiny dále upřesněny. Technické konzultace Součástí řešení jsou také technické konzultace, jejichž předmětem je níže uvedené. Dodavatel bude připraven poskytovat tyto konzultace od předání řešení (podepsání akceptačního protokolu) do provozu po dobu min. 12 následujících měsíců. Reakční doba na zahájení technické konzultace jsou maximálně 4 pracovní dny ode dne výzvy zadavatele. Definice konzultací je následující: Provádění konzultačních a poradenských služeb technicky vysoce odborného charakteru (a to členy realizačního týmu uvedených v příloze č. 6 smlouvy) na dodaných technologických celcích na základě požadavků zadavatele v rozsahu do 20 hodin za měsíc (celkem 240 hodin za 12 měsíců) v místě instalace nebo prostřednictvím vzdáleného přístupu. 1. Základní popis Část A Je požadováno dodání kompletního řešení hierarchického datového úložiště (Hierarchical Storage Management - HSM) a současně samostatného diskového pole pro IT infrastrukturu budovanou v rámci projektu BIOCEV. Řešení musí splnit níže uvedená technická kritéria. Hlavními částmi řešení jsou: 1. Tier-1: diskové pole pro souborový přístup, 2. Tier-2: diskové pole pro souborový přístup, 3. Tier-3: pásková knihovna (páskový robot), 4. servery pro řídící systém-software pro správu a řízení HSM (front-end, head node servery), a zabezpečení provozu datového úložiště včetně uživatelského rozhraní. 5. aktivní prvky síťové infrastruktury pro zajištění SAN (Storage Area Network) v návaznosti na aktivní prvky lokální sítě - LAN (aktivní prvky pro LAN tedy nejsou součástí tohoto řešení, resp. předmětem smlouvy), 6. řídící software a operační systémy nezbytné pro jeho provoz, 7. samostatné diskové úložiště pro služby blokového přístupu (pro základní provozní 3/32
systémy), 8. systém pro management identit, 9. jakékoliv další potřebné příslušenství ke zprovoznění sestavy datového úložiště (kabely, adaptéry, rack mount kit atd.) 10. časově neomezené licence na všechny dodané programové produkty. Řešení je naznačeno na následujícím obrázku. 4/32
Předpokládané využití datových úložišť Předpokládáme využití úložiště ve třech hlavních kategoriích: 1. Úložiště pro zálohy uživatelů Půjde o datové úložiště sloužící jako back-end nebo backup pro již existující zálohovacího software uživatelů. 2. Souborový systém Půjde o nabízení datového úložiště formou souborového systému. Předpokládáme nasazení protokolů NFSv4, SMB 2.0, HTTP(S), SFTP, FTP(S), SCP a dále protokolu rsync. Z hlediska HSM půjde o lokálně připojený souborový systém. 3. Blokové služby (samostatné diskové pole) Blokový přístup k úložným kapacitám bude poskytován pro aplikace podporující IT provoz, a to na základě konkrétních potřeb. Na blokové úrovni lze zpřístupnit pouze základní diskovou kapacitu, bez možnosti implementovat další nadstavbové služby (jako např. HSM funkcionalitu). Uživateli se vytvoří a zpřístupní LUN odpovídající velikosti. Veškeré další operace, jako je vytvoření souborového systému a následná údržba dat, je již plně v kompetenci uživatele. Nepožadujeme, aby výše uvedené kategorie sdílely data mezi sebou. Požadavky kladené na datové úložiště Pokud není uvedeno jinak, veškeré kapacity jsou uvedeny v dekadických násobcích (desítková soustava), tj. 1TB = 10 12 B, 1PB = 10 15 B, atd. Využitelná kapacita diskových polí je definována jako kapacita po režii RAID, hot-spare disků či jiných případných režijních kapacit pole, ale před režií souborového systému. Využitelná kapacita páskové(ých) knihovny(en) je definována jako součet nativních kapacit (bez komprese dat, bez deduplikace dat apod.) všech využitelných dodávaných páskových médií. V následujícím textu jsou použity následující zkratky a pojmy: FC - Fibre channel 1GE - 1Gbit Ethernet 10GE - 10 Gbit Ethernet 5/32
1. Datové úložiště typu HSM vychází z modelu hierarchicky uspořádaných úložných vrstev, je to technika ukládání dat, která automaticky přesune data mezi dražšími-rychlejšími (high-cost) a levnějšími-pomalejšími (low-cost) paměťovými médii. Jednotlivé vrstvy mají různou kapacitu úložného prostoru a zároveň poskytují vzájemně odlišný výkon. Úložiště bude obsahovat níže uvedené tiery (vrstvy): a) Tier-1: Diskové pole osazené disky minimálně o využitelné kapacitě 291 TB. Tato vrstva může být (ale i nemusí) případně sestavena i z více samostatných diskových polí, ta však musí být možné vhodným nástrojem (např. distribuovaným souborovým systémem) prezentovat front-end serverům jako jeden svazek. Veškeré požadavky na Tier-1 se týkají každého případného dalšího diskového pole umístěného v rámci Tier- 1. Požadavek na rychlost disků v Tier-1 je 10,000 rpm. Minimální celkový počet disků v Tieru-1 musí být 310. b) Tier-2: Diskové pole o minimální využitelné kapacitě alespoň 649 TB. Tato vrstva může být (ale i nemusí) případně sestavena i z více samostatných diskových polí, ta však musí být možné vhodným nástrojem (např. distribuovaným souborovým systémem) prezentovat front-end serverům jako jeden svazek. Veškeré požadavky na Tier-2 se týkají každého případného dalšího diskového pole umístěného v rámci Tier-2. Požadavek na rychlost disků v Tier-2 je 7,200 rpm. Minimální celkový počet disků v Tieru-2 musí být 210. c) Tier-3: Pásková knihovna s celkovou minimální kapacitou 6,200 TB. Pro tuto kapacitu musí být součástí knihovny veškeré potřebné licence a příslušný počet slotů. Tzn. v dodané knihovně musí být takový počet páskových slotů, aby tuto kapacitu pojala bez přidání dalších expanzí či licencí. Dodaná minimální využitelná kapacita páskových médií musí být 1120 TB. Požadovaná kapacita knihovny i pásek se uvažuje nativní, bez komprese. Součástí dodávky budou všechny nezbytné licence pro všechny dodané fyzické sloty knihovny. Licence nebudou časově omezeny. Součástí dodávky musí být také adekvátní počet čistících pásek. Minimální počet čistících pásek musí být dva kusy per tape drive. Pásková média musí být dodána s čárovým identifikačním kódem (labelem), musí také obsahovat čip umožňující provádět životní cyklus-management médií (Media Lifecycle Management). Potřebný ovládací software pro centrální management drives a médií musí být součástí dodávky. d) Vedle úložných kapacit musí sestava obsahovat všechny případné řídící serverysystémy pro zajištění HSM funkcionality včetně zajištění chodu sestavy datového úložiště (front-end, head node servery). 2. Vedle diskových polí a serverů požadujeme i odpovídající síťovou infrastrukturu včetně propojení diskových polí, páskové knihovny a řídících serverů. Toto propojení musí být realizováno přes FC SAN switche, které jsou nutnou součástí dodávky. Požadujeme 6/32
minimální rychlost 16 Gbs. Každý switch propojovací infrastruktury musí po konečném zapojení všech prvků včetně řešení obsahovat navíc minimálně 30% volných portů, přitom se zaokrouhluje nahoru. Navíc počet volných portů v každém switchi musí být alespoň 6. (např. je-li použito 7 portů na daném switchi, celkový počet portů na tomto switchi musí být alespoň 13.) Všechny obsazené i volné sloty musí být osazeny transceiverem a zalicencovány (aktivovány). Nabídka musí obsahovat kabeláž pro propojení jednotlivých částí úložiště, tato kabeláž nesmí být typu Direct Attach. Zároveň je nutné dodat navíc 4 kabely každého typu jako rezervu. Optické kabely pro připojení front-end serverů do vnitřní sítě LAN musí mít délku minimálně 10 metrů. 3. HSM musí poskytovat souborový systém (dle standardu POSIX) připojitelný na front-end servery. HSM musí umožnit vytvoření alespoň 100 souborových systémů (oddílů), každý oddíl musí být možno nezávisle na ostatních zvětšit (přidáním disků) a zmenšit. 4. Diskové pole v Tier-1 musí být zabezpečeno technologií RAID (či ekvivalentní technologií poskytující stejné či lepší zabezpečení, dále jen RAID) proti ztrátě dat při současném výpadku libovolných dvou disků v rámci jedné RAID skupiny. Počet disků (včetně paritních disků) v jedné takové RAID skupině nesmí být vyšší než 10. Přitom rebuild (návrat do redundantního stavu zajišťujícího opět ochranu proti výpadku dvou disků ve skupině) libovolné takto vytvořené RAID skupiny nesmí trvat déle než 8 hodin. Výpadek disku musí mít minimální vliv na výkonnost diskového pole. Požadovaný výkon musí být dosažitelný v této konfiguraci, měřen bude při stabilní konfiguraci pole (ne při rebuildu). 5. Na každých i započatých 30 disků v Tier-1 požadujeme alespoň 1 další samostatný hotspare disk a to pro každé jedno diskové pole, které je umístěno v rámci Tier-1 (např. při počtu celkem 280 disků zapojených v RAID svazcích a počtu 4 diskových polí je při rovnoměrném rozložení disků třeba navíc 12 hot-spare disků, celkem tedy 292 disků). Používá-li nabízená technologie tzv. hot-spare space, musí být pro tento prostor alokována alespoň ekvivalentní kapacita. 6. Diskové pole v Tier-1 musí podporovat a být vybaveno licencí na funkcionalitu LUN maskingu pro maximální možnou konfiguraci (maximální konfiguraci pole, maximální počet storage partitions). 7. Diskové pole v Tier-2 musí být zabezpečeno technologií RAID (či ekvivalentní technologií poskytující stejné či lepší zabezpečení, dále jen RAID) proti ztrátě dat při současném výpadku libovolných dvou disků v rámci jedné RAID skupiny. Počet disků (včetně paritních disků) v jedné takové RAID skupině nesmí být vyšší než 10. Přitom rebuild (návrat do redundantního stavu zajišťujícího opět ochranu proti výpadku dvou disků ve skupině) libovolné takto vytvořené RAID skupiny (ve všech případech zabezpečení) nesmí trvat déle než 24 hodin. 8. Na každých i započatých 30 disků v Tier-2 požadujeme alespoň 1 samostatný hot-spare 7/32
disk a to pro každé samostatné diskové pole, které je umístěno v rámci Tier-2 (např. při počtu celkem 280 disků zapojených v RAID svazcích a počtu 4 diskových polí je při rovnoměrném rozložení disků třeba navíc 12 hot-spare disků, celkem tedy 292 disků). Používá-li nabízená technologie tzv. hot-spare space, musí být pro tento prostor alokována alespoň ekvivalentní kapacita. 9. Write-back cache řadičů diskového pole musí být zabezpečena proti všem následujícím jevům: ztrátě dat, poškození dat při výpadku napájení (např. baterií) a poruše řadiče (např. zrcadlením cache redundantních řadičů). Požadovaný výkon musí být dosažitelný se zapnutou funkcionalitou zabezpečení dle tohoto bodu. 10. Velikost Write-back cache řadičů diskového pole v Tier-1 a Tier-2 musí být minimálně 24 GB na každý jeden řadič. Například pokud se sestava úložiště bude skládat ze čtyř dualcontroller diskových polí, celková velikost cache bude minimálně 192 GB. 11. Pásková knihovna musí obsahovat dva páskové roboty (tj. zařízení pro přenášení pásek mezi sloty knihovny a páskovými mechanikami). Ovládání knihovny musí být redundantní (control path failover). Páskové mechaniky musí podporovat a obsahovat redundantní cesty (data path failover). Minimální počet mechanik je definován minimální celkovou nativní propustností (bez komprese) specifikovanou viz níže - podkapitola 3. Výkonové požadavky (bod č. 4). 12. Centrální ovládací software pro páskovou knihovnu musí obsahovat funkce pro administraci knihovny, monitoring, reporting, policy-based řízení přidělování mechanik a médií, centrální media lifecycle management a funkce pro řízení přístupu a cest. Páskové mechaniky musí podporovat nativní šifrování dat. 13. Pro vnější reprezentaci úložiště požadujeme minimálně 6 plně zastupitelných front-end (head node) serverů. Souborový systém poskytovaný HSM musí být možno sdílet pro čtení i zápis mezi všemi front-endy najednou. Zadavatel požaduje přístup s plnými administrátorskými (root) právy na všechny front-end servery. 14. Každý front-end server musí mít připojení k Tier-1/2 úložiště technologií minimálně 16 Gbps FC a to minimálně dvěma aktivními cestami (tj. min. 2x 16Gbps FC). Každý řadič pole Tier-1/2 musí mít minimálně 4 odpovídající porty. 15. Všechny front-end servery musí být provozuschopné pod 64bitovým operačním systémem na bázi Linux operačního systému na architektuře x86_64. 16. Pokud je na front-endech nutné provozovat jakýkoli komerční software, musí být všechny potřebné licence pro všechny front-endy součástí nabídky (například operační systém). Jsou-li součástí dodávky instalace komerčních distribucí Linuxu, požadujeme, aby v nich byly nakonfigurovány zdroje pro vývojové (development) balíky a všechny závislosti pro rekompilaci libovolného balíčku, který dodavatel OS poskytuje. Zadavatel požaduje 8/32
přístup s plnými administrátorskými (root) právy na všechny front-end servery. 17. Každý front-end server musí mít minimálně 128 GB RAM. 18. Všechny front-end servery musí být z hlediska operačního systému nakonfigurovány jako plně zastupitelné (High Availability). a) Všechny front-end servery budou exportovat všechna HSM data v režimu active-active pomocí protokolů: SCP, FTP(S), CIFS/SAMBA. Export CIFS/SAMBA musí být nakonfigurován jako klastrový. b) Dále musí front-end servery exportovat HSM data protokolem NFSv4 nebo vyšší verze. Pět front-end serverů bude exportovat všechny HSM souborové systémy tímto protokolem tak, že žádné dva front-endy neexportují stejný HSM souborový systém. Šestý front-end server bude nakonfigurován jako pasivní NFSv4 server. V případě výpadku libovolného z front-endů exportujícího NFSv4 musí pasivní front-end plně převzít veškerou NFSv4 funkcionalitu bez nutnosti administrativního zásahu jak na serveru, tak na klientech. Implementace NFSv4 pro klienta může být dodána dodavatelem. c) Funkcionalita všech požadavků v tomto bodě bude ověřena v akceptačních testech. 19. Aktivní prvky pro lokální počítačovou síť (LAN) nejsou součástí této veřejné zakázky. Zadavatel předpokládá připojení front-end serverů do vnitřní sítě (LAN) a to: 2x typu 10GE, 2x typu 1GE (pro každý z těchto serverů). Zadavatel požaduje, aby byl každý frontend server rozšířitelný v budoucím období o minimálně jednu další PCIe (PCI Express) kartu. 20. Všechna datová (ne management porty) síťová Ethernet rozhraní front-end serverů musí podporovat jumbo rámce (alespoň 9000 bytů). 21. Diskové pole v Tier-1 a Tier-2 musí podporovat vytváření LUN o velikosti více než 16 TB. 22. Systém úložiště (diskové a páskové kapacity, jejich řadiče, SAN infrastruktura, servisní stroje HSM a páskové knihovny a vzájemné propoje těchto komponent) musí být plně redundantní, výpadek jakékoliv jedné komponenty nesmí způsobit nedostupnost úložiště, může ale vést k dočasné degradaci výkonu. Tento požadavek se týká i jednoho samostatného front-end či obslužného serveru, kdy při jejich výpadku nesmí dojít k nedostupnosti funkcionality, kterou poskytují. Všechny typy serverů musí mít redundantní napájecí zdroje, disky a karty zajišťující SAN a LAN připojení (alespoň dual port). Pásková knihovna, SAN a 10GE switche musí mít také redundantní napájení. 23. Výměna jakékoliv části HW musí být možná za chodu (nesmí být nutné převést úložiště do stavu, kdy jsou některá data nedostupná). Upgrade software (firmware) pole a páskové knihovny musí být možný taktéž za chodu. V případě poruchy jednoho z robotů páskové 9/32
knihovny připouštíme následné plánované odstavení páskové knihovny na dobu nejvýše 60 minut. 24. Z hlediska zajištění provozu musí být všechny prvky datového úložiště vybaveny managementem kontroly funkčnosti a provozních parametrů (např. teplota, napájení, ) a možností vzdálené správy. U všech dodaných serverů požadujeme možnost vzdáleného managementu včetně grafické konzole, možnosti využití virtuálních médií pro boot serverů a vzdáleného přístupu do BIOS/UEFI. Veškerý management musí být možný z prostředí OS UNIX/Linux nebo ekvivalentního OS (spňujícíh související technické podmínky). BMC kontrolery serverů musí být připojeny samostatným kabelem, není možné sdílet fyzické porty s datovými rozhraními serverů. 25. Všechny front-end servery musí být stejného typu. 26. Datové úložiště musí mít automatický systém hlášení poruch na bázi protokolu SNMP. Zprávy systému hlášení poruch musí být možno zpracovat na stroji s operačním systémem Linux, z těchto zpráv musí být rozpoznatelná chybující komponenta v lidsky čitelné podobě. 27. Veškerý management HSM musí být ovladatelný ze stroje s operačním systémem UNIX/Linux nebo ekvivalentního OS (splňujícího všechny související technické podmínky uvedené v této dokumentaci). 28. HSM musí být schopno pojmout minimálně dvě miliardy souborů. 29. Exporty HSM z front-endů ve smyslu základního popisu řešení (začátek části A) musí být realizovatelné přes všechna rozhraní, tj. 10GE, 1GE. 2. Požadavky na HSM a souborový systém 1. Systém pro správu migrací dat mezi tiery HSM musí správci umožňovat nastavit minimálně níže popsané typy migračních politik. 2. Akce přesunu souborů mezi tiery mohou být nastaveny na základě: a) času vzniku, poslední modifikace, posledního použití souborů, b) velikosti souborů, c) logické funkce vytvořené z pravidel a) a b) alespoň pomocí and, d) pravidla podle zaplnění jednotlivých vrstev (např. začni přesouvat na pásky nejdéle nepoužité soubory, pokud zaplnění disků je větší než 70% ) a explicitního příkazu správce nebo autorizovaného uživatele. 10/32
Pro soubory odpovídající výše uvedeným pravidlům musí být možné provést alespoň následující akce: e) přesun na zvolený tier, f) vytvoření kopie na zvoleném tieru (např. soubor se zapíše zároveň na pásky, zpoždění zápisu na pásky dané technologií je tolerováno), g) řízení počtu kopií na archivním tieru (Tier-3), alespoň tři kopie (např. soubor zapisovat na dvě samostatné sady pásek). 3. HSM musí umožňovat migraci dat na vzdálené úložiště minimálně pomocí protokolů NFS nebo FTP. 4. HSM musí poskytovat GUI a CLI nástroje (obojí), které umožňují explicitně řídit migraci a zjišťovat aktuální umístění a stav souborů a adresářů. 5. Je požadované, aby v rámci systému řízení (administrace) byly k dispozici i statistické souhrny (přes GUI). 6. Systém nastavování pravidel musí poskytovat CLI rozhraní, je preferovanější, aby pravidla bylo možno nastavovat přes GUI. 7. HSM software musí obsahovat funkcionalitu pro automatické periodické provádění kontrol konzistence dat na páskách. Kontrola dat nesmí vyžadovat migraci dat z pásek na diskové pole. 8. Systém musí podporovat kvóty na velikost uživatelských dat na základě identifikace uživatelů a jejich skupin. 9. Součástí dodávky je licence HSM software tak, aby pokryla veškerou dodanou kapacitu Tier-1 a Tier-2 a dvojnásobek kapacity Tier-3 (pro páskovou knihovnu) a minimálně 6 front-end serverů. 10. V rámci funkcionality souborového systému musí být možné vytvářet snapshoty a to jak celého filesystému, tak na úrovni file sets, případně jednotlivých souborů. 11. HSM filesystém musí podporovat online přidání i odebrání dalších front-end uzlů s možností zahrnout řádově až tisíce uzlů. Dále musí podporovat online přidání i odebrání LUNů z kapacitních úložišť. Filesystém musí mít rovněž funkcionalitu pro online rebalancing. 12. Souborový systém HSM musí podporovat nativní šifrování dat. 13. Uchazeč předloží rovněž roadmap nabízeného filesystému. 11/32
3. Výkonové požadavky 1. Výkony disků uveďte ve dvojkových násobcích, tj. 1MiB = 2 20 B, 1TiB = 2 40 B, výkony u páskové knihovny uveďte v desítkových násobcích, tj. 1MB = 10 6 B, 1TB = 10 12 B. 2. Rychlost čtení a zápisu dat na datového úložiště musí být měřena na identické sestavě, která je předmětem nabídky, a musí být v našich podmínkách reprodukovatelný. V případě, že nepůjde v nabídce deklarovaná čísla reprodukovat, dostane dodavatel možnost provést optimalizaci zařízení. 3. Výkonové požadavky pro Tier-1: a) Test bude prováděn ze všech dodaných front-end serverů. Velikost testovaného oddílu není omezena, musí být však umístěn na HSM. V případě využití více diskových polí je nutné test spouštět na takovém svazku či svazcích, který zahrnuje všechna disková pole najednou. b) Rychlost čtení a zápisu dat u disků na Tier-1, pokud tato bude přístupná přes souborové rozhraní, bude měřena nástrojem iozone (doporučujeme verzi 3.347, dostupný na: http://www.iozone.org) pomocí příkazu: iozone -Mce t50 -smemg -r512k -i0 -i1 -+mnodes cesta_k_souborům MEM je velikost paměti jednoho front-end serveru vynásobená dvěma a NODES je soubor obsahující: v případě Tier-1: hostnames všech front-end serverů a cesty dle dokumentace programu iozone (popis volby -+m), Rozložení souborů na jednotlivé servery, ze kterých budou prováděny testy, musí být rovnoměrné. c) Jako výsledek testu pro zápis respektive pro čtení je brána průměrná hodnota tří testů udaná výstupem programu iozone jako Children see throughput for X initial writers, respektive, Children see throughput for X readers. d) Požadované rychlosti pro čtení a zápisu jsou minimálně 4000 MiB/s. Program iozone používá jednotky v dvojkových násobcích (KiB, MiB) apod. 4. Výkonové požadavky pro páskovou knihovnu v Tier-3: Souhrnná rychlost lineárního zápisu dat bez zapnutí komprese na všechny mechaniky páskové knihovny a stejně tak i souhrnná rychlost lineárního čtení ze všech mechanik páskové knihovny musí dosáhnout alespoň 8.9 TB/h. Výpočet vychází z celkové nativní nominální rychlosti všech dodaných páskových mechanik bez zahrnutí komprese 12/32
přepočítaný na TB/h při použití decimálních jednotek. 5. Výkonové požadavky pro front-end servery: Pro všechny front-end servery požadujeme minimální skóre získané aplikací SPEC2006 (nebo ekvivalentní hodnocení) ve variantě int (integer), rate, no-autoparalel, base 300 bodů. Hodnota SPEC2006 pro servery musí být v nabídce uvedena. 4. Požadavky na blokové služby - samostatné diskové úložiště 1. Samostatné datové úložiště pro blokové služby vychází z modelu tierované storage. Úložiště bude obsahovat níže uvedené tiery (vrstvy): a) Tier-1: osazené disky s rychlostí 15,000 rpm a s minimální využitelnou kapacitou 16 TB. Ochrana dat typu RAID5 s maximálně 8 disky v RAID skupině. Navíc minimálně 1 hotspare na každých i započatých 30 disků. b) Tier-2: osazené disky s rychlostí 10,000 rpm a s minimální využitelnou kapacitou 70 TB. Ochrana dat typu RAID6 s maximálně 12 disky v RAID skupině. Navíc minimálně 1 hotspare na každých i započatých 30 disků. 2. Typ přístupu k datům je blokový s protokoly FC a iscsi/fcoe. Diskové pole musí obsahovat front-end porty typu 16Gbit FC a zároveň 10Gbit iscsi/fcoe. Minimální počet jsou 2x 16Gb FC porty per řadič a 2x 10GbE porty per řadič. 3. Všechny disky musí být typu SAS s rozhraním minimálně 6Gb či rychlejší. Velikost Writeback cache řadičů diskového pole musí být minimálně 64 GB na každý jeden řadič. 4. Požadujeme základní funkcionalitu diskového pole v rozsahu alespoň: vytváření virtuálních disků, transparentní migrace dat mezi diskovými prostory, thin provisioning, remote mirroring synchronní a asynchronní, snapshoty a klony, vícenásobné kaskádované inkrementální snapshoty/klony, reverzní snapshoty, upgrade software a hardware u řadičů musí být proveditelné za chodu a bez ztráty přístupu hostitelských serverů k datům, inteligentní správa výkonnostních charakteristik virtualizovaných diskových prostorů (sub-volume level tierieng). Diskové pole musí podporovat externí virtualizaci, tzn. připojení externích diskových polí od různých výrobců. Seznam podporovaných diskových systému musí být veřejně dostupný pro kontrolu. Podpora virtualizovaných serverových prostředí. Diskové pole musí obsahovat funkcionalitu komprese dat. Požadujeme, aby diskové pole mělo možnost nativního šifrování dat. 5. Výše uvedená funkcionalita musí být licencována na veškerou dodanou kapacitu diskového pole. Případný SW support (podpora) musí být na 5 let. 6. Součástí samostatného datového úložiště musí být nástroje (software) pro zálohování dat 13/32
v Tier-1 a Tier-2, které zajistí v případě hardwarového nebo softwarového výpadku Tier-1 (nebo Tier-2) nebo kterékoliv jeho části (např. výpadek pole, volumu, rozpad souborového systému) plnou obnovu dat (dostupnost všech dat v systému). 5. Požadavky na systém pro management identit Zadavatel v rámci části A požaduje řízení (management) identity uživatelů. Hlavním cílem je docílit vysoce granulárního řízení přístupu uživatelů na datová úložiště (zejména HSM) prostřednictvím autentizace a autorizace (prostřednictvím vhodných rolí). Dále snížit náklady na správu, zjednodušit údržbu, automatizovanější řízení životního cyklu uživatele, ochránit hlavní aktiva (data jednotlivých uživatelů, skupin, teamů apod.) před neautorizovaným přístupem. Požaduje se následující funkcionalita: 1. Administrátorské a uživatelské rozhraní by měly být úplně odděleny. 2. Přehledné uživatelské webovské rozhraní musí umožnit uživateli samostatně obsloužit základní potřeby jako je např. změna hesla, obnovení zapomenutého hesla, změna osobních údajů, požádání o přístup ke službě. 3. Adresářový server pro správu identit musí provozován v modelu vysoké dostupnosti. Je požadována komunikace prostřednictvím protokolu LDAP (RFC 2251). 4. Pokud bude uchazečem navrhované řešení vyžadovat běh identity managementu na daném operačním systému (např. Linux), potom systém musí být provozován v prostředí serverové virtualizace (bez licenčního omezení pro instalovatelnost v tomto prostředí). 5. V případě licencování je požadován licenční model na uživatele (nikoliv počet zařízení), je požadováno, aby bylo licenčně pokryto min. 700 uživatelů. 6. Podpora zabezpečené komunikace identity management systému a spravovanou službou, uživatelskými aplikacemi apod. například pomocí SSL, SSH atd. 7. Funkce správy uživatelských identit a rolí, současně nástroje pro návrh, management uživatelských rolí spolu s možností tvorby analýz (typu "what-if") při změnách parametrů rolí. Dále možnost tvorby vnořených rolí. 8. Flexibilita při definici atributů, např. možnost uživateli přiřadit hodnotu specifického atributů při udělení role. 9. Široké portfolio adaptérů (agentů, konektorů) pro aplikace (v základní licenci). Dále i možnost (nástroj) pro tvorbu vlastních uživatelských konektorů. 10. Funkce pro snadnou definici workflow schvalovacích procesů, včetně možnosti vytváření vlastních webovských formulářů. 11. Možnost zasílání emailových zpráv při vzniku dané události (např. nástup nového uživatele 14/32
- identity). 12. Možnost delegování administrace, například na určitou roli, skupinu identit apod. 13. Reportovací (audit) modul (engine), s možností více formátů výstupu, včetně předpřipravené (předkonfigurované) sady standardních reportů (výstupů). 14. Dostupnost programovatelného rozhraní (Application programming interface - API), včetně potřebné dokumentace k API. 6. Požadavky na zaškolení IT personálu zadavatele Zadavatel požaduje výrobcem certifikované zaškolení třech osob (IT specialistů) v architektuře a správě dodaného datového úložiště určeného pro HSM a managementu identit. Školení je požadováno v rozsahu minimálně pěti pracovních dnů. Obsahem školení musí být všechna aktivní zařízení a software použitý při implementaci datového úložiště určeného pro HSM. Zadavatel jako součást školení požaduje také přípravu na řešení nestandardních situací, zejména neřízené vypnutí HSM úložiště a jeho následné oživení HSM, postup při rozšiřování o další dodatečnou kapacitu atd. Dále zadavatel požaduje separátní zaškolení v používání systému pro řízení identit třech osob (IT specialistů) v rozsahu minimálně dvou pracovních dnů. 7. Požadavky na záruku a servis Zadavatel požaduje pro tuto část řešení (část A) záruku a současně servis podle specifikace v úvodu tohoto dokumentu, a to konkrétně: Záruku a servisní skupinu č.4 na 5 let. Záruku je nutné v této části chápat i jako požadavek zadavatele na maintenance, tj. přímý support výrobce software a bezplatný nárok na nové verze produktu po dobu pěti let. 1. Základní popis Část B V rámci řešení je požadováno dodání serverového vybavení. Toto vybavení (zařízení) bude využito jak pro vědecké, tak pro provozní účely. Podle daného účelu jsou i jednotlivá zařízení kategorizována a specifikovaná. Podrobné technické specifikace (tabulky) jednotlivých zařízení jsou uvedeny v příloze k části B (včetně počtu kusů každého typu, požadované záruky a servisu), současně k této technické specifikaci doplní uchazeč skutečné specifikace parametrů nabízeného zboží. 15/32
2. Kompatibilita v rámci řešení Zadavatel požaduje dokonalou kompatibilitu a interoperabilitu s ostatními částmi (A,C,D) tohoto řešení. Zejména u části A je nutné dodržet požadavek kompatibility v připojení na datové úložiště HSM pomocí síťového rozhraní 10GE a na připojení k samostatnému diskovému úložišti pomocí rozhraní FC. U části C je nutné dodržet kompatibilitu se software pro serverovou virtualizaci. V poslední řadě je nutné dodržet kompatibilitu s částí D, kde jsou definovány požadavky na napájení - energetickou zátěž, umístění v rámci serverovny atd. 3. Požadavky na zaškolení IT personálu zadavatele Zadavatel požaduje výrobcem certifikované zaškolení třech osob (IT specialistů) v architektuře a správě blade server zařízení, které je částí tohoto řešení. Školení je požadováno v rozsahu minimálně dvou pracovních dnů. 4. Požadavky na záruku a servis Zadavatel specifikuje jednotlivé požadavky na záruku a servisní skupiny pro jednotlivé komponenty této části v příloze podrobných technických specifikací k části B. 1. Základní popis Část C V rámci řešení je požadováno dodání software a licencí pro serverovou virtualizaci. Toto vybavení bude využito jak pro vědecké tak pro provozní účely. Serverová virtualizace umožní zadavateli efektivně, ekonomicky a flexibilně využít fyzickou serverovou infrastrukturu. 2. Kompatibilita v rámci řešení Zadavatel požaduje dokonalou kompatibilitu dodaného software s částí B tohoto řešení. Tj. zadavatel očekává doložení certifikace výrobce serverového hardwaru (část B) pro daný virtualizační serverový software. 3. Požadavky na zaškolení IT personálu zadavatele Zadavatel požaduje výrobcem certifikované zaškolení třech osob (IT specialistů) v architektuře a správě software pro serverovou virtualizaci, která je částí tohoto řešení. Školení je požadováno v rozsahu minimálně dvou pracovních dnů. 16/32
4. Požadavky na záruku a servis Zadavatel požaduje pro tuto část řešení (část C) záruku a současně servis podle specifikace v úvodu tohoto dokumentu a to konkrétně: Záruku a servisní skupinu č.3 na 5 let. Záruku je nutné v této části chápat i jako požadavek zadavatele na maintenance, tj. přímý support výrobce software a bezplatný nárok na nové verze produktu po dobu pěti let. 5. Požadavky na funkce a vlastnosti Hypervisor nainstalovaný přímo na hardware, umožňující virtualizaci x86 stroje. Umístění kompletního prostředí včetně OS a aplikací do virtuálních strojů bez závislosti na provozovaném hardware. Centralizované řízení zajišťující automatický provoz, optimalizaci zdrojů a vysokou dostupnost IT prostředí. Inteligentní alokace zdrojů na základě předdefinovaných pravidel. Podpora operačních systémů různých distribucí Unix/Linux (např. Debian, Redhat, CentOS, SuSE), MS Windows server 2012 a novější verze. 6. Požadavky na počet dodaných licencí Zadavatel požaduje dodání licencí pro serverovou virtualizaci celkem na 5 fyzických serverů (zařízení), které jsou v části B (Příloha podrobných technických specifikací k části B - serverová část) označeny jako Blade server, Rack server provozní. V případě licenčního modelu na 1 fyzický CPU socket jde celkem o 10ks licencí (zadavatel požaduje licence ke všem CPU socketům, bez ohledu na to zda budou či nebudou osazené). 1. Požadavek na energetickou zátěž a UPS Část D 1. V serverovně je (bude) k dispozici zdroj napětí zálohovaného pomocí centrální UPS a diesel agregátu. Součástí dodávky dále není UPS. 2. Elektrické rozvody v serverovně budou přichystány. V rámci stojanu (racku) budou instalovány vždy minimálně dvě tyto PDU (Power Distribution Unit) lišty, ve většině stojanů čtyři PDU lišty v rámci hlavní serverovny bude každá napájena z jiného zdroje UPS tak, aby i při ztrátě napájení z jedné UPS zůstala polovina stojanu pod napětím. Součástí dodávky dále není PDU. 3. Snahou zadavatele je rovnoměrné zatížení jednotlivých fází. Rovnoměrné zapojení PDU a jednotlivých zařízení řešení na jednotlivé fáze je odpovědnost dodavatele. 17/32
4. PDU lišty jsou vybaveny dostatečným množstvím napájecích zásuvek IEC 320 C13 a C19. 5. Maximální výkon přenášený jednou PDU lištou je 7,36 kw. 6. Maximální příkon datového úložiště pro HSM nesmí překročit v součtu 9 kw na jeden rack. 7. V nabídce musí být uveden celkový deklarovaný peak příkon a maximální příkon řešení. 8. Všechna zařízení musí být k elektrické síti připojena tak, aby platilo: a) Napájení musí být realizováno tak, že výpadek napájecí větve s UPS nesmí způsobit výpadek datového úložiště pro HSM či výpadek poskytované funkcionality (může dojít k degradaci výkonu). Dále výpadek nezálohovaného napájení (při funkci všech dotčených UPS) nesmí způsobit výpadek datového úložiště pro HSM či výpadek poskytované funkcionality (může dojít k degradaci výkonu). b) Výpadek napájení v době do spuštění diesel agregátu nezpůsobí výpadek zařízení či výpadek poskytované funkcionality (může dojít k degradaci výkonu). c) Požadavkům vyhovuje například zapojení, kdy je každé zařízení s redundantním napájením připojené k UPS minimálně jedním přívodem a druhým přívodem přímo do napájecí větve mimo UPS. Podobně pro dvojice zařízení poskytující stejnou funkcionalitu. Toto zapojení zadavatel preferuje. d) K a) až c) bodu č. 8 zadavatel poskytne nutnou součinnost a kooperaci při realizaci dodávky. 2. Prostorové, hmotnostní a hygienické požadavky Řešení datového úložiště pro HSM musí splňovat a respektovat následující omezení. 1. Rozměry jednotlivých dále nedělitelných technologických dílů sestavy datového úložiště musí umožnit transport zařízení do serverovny takovým způsobem, který neporuší záruční podmínky výrobce těchto zařízení. K serverovně existuje více přístupových tras, zadavatel doporučuje využít možnosti referenční návštěvy pro možnost přesného vyjasnění si prostorových možností. 2. Plošná nosnost podlahy v hlavní serverovně pod racky je 1800 kg/m 2. 3. Rozměry pro umístění zařízení sestavy datového úložiště pro HSM musí splňovat dispoziční možnosti podle plánku serverovny na obrázku č. 1 níže. Využití této plochy je ponecháno na dodavateli, musí být však zachována následující omezení. a) S již zakreslenými zařízeními nelze manipulovat (rozvody pro kabeláž, rozvodné skříně pro elektřinu, SHZ, UPS). 18/32
b) Dodaná zařízení (mimo páskové knihovny) lze umisťovat jen do rack skříní s následujícími parametry: V prostoru serveroven budou instalovány 19 stojany, které budou sloužit pro umístění a provoz technologií IT. Použity budou stojany s výškou 42U, hloubkou 120 cm, variantně 107 cm a šířkou 60 cm, variantně 75 cm. c) Umístění jednotlivých zařízení musí respektovat manipulační prostory v rámci serverovny. Umístění zařízení musí dovolovat jeho stabilní dlouhodobý provoz. Dále musí respektovat nezbytnost zachování únikových tras ze sálu naznačenými dveřmi. 4. Součástí nabídky musí být předběžný návrh rozmístění komponent v serverovně. Detailní umístění komponent bude nicméně upřesněno před realizací dohodou zadavatele a uchazeče. 19/32
Obr. č. 1. Plán hlavní serverovny 20/32
Část E 1. Akceptační testy Po dodávce a instalaci HSM datového úložiště (část A) požaduje zadavatel v rámci zkušebního provozu provést akceptační testy. Zkušební provoz musí být zahájen nejpozději 10 pracovních dnů před skončením stanovené doby plnění podle čl. IV. odst. 1 kupní smlouvy. Tyto testy budou minimálně zahrnovat: a) Ověření funkcí a vlastností všech dodaných zařízení a komponent v souladu s deklarovanými parametry v nabídce; b) Ověření funkčnosti managementu SW, komunikačních protokolů a přístupových rozhraní. Detailní popis akceptace funkčnosti přístupových protokolů je uveden níže. c) Výkonové testy podle specifikace viz níže (test active-passive režimu front-end serverů). Dále v rámci akceptace budou požadované výkonové testy popsané v části A, podkapitola č.3 Výkonové požadavky. Test active-passive režimu front-end serverů proběhne následovně. Předpokládáme, že klient má připojen souborový systém přes NFSv4.0 z front-endu A. Během akceptačního testu musí úspěšně proběhnout následující dílčí testy: 1. Na klientu bude spuštěn iozone test podobně jako při měření výkonu na plně sestaveném a funkčním úložišti, bude spouštěn opakovaně v nekonečné smyčce. 2. Z front-endu A budou odpojeny všechny napájecí kabely (IPMI v tomto případě bude nedostupné a je tedy nezbytné zajistit funkcionalitu failoveru i takto, např. pomocí sekundárního fencingu na switchích). Funkci front-endu A musí automaticky (bez administrativního zásahu) převzít pasivní front-end. Po převzetí funkce pasivním front-endem musí klient pokračovat v měření výkonu bez administrativního zásahu (tj. nepřipouští se ruční rekonfigurace serveru ani klienta). 3. Test bude zopakován pro CIFS/SMB export analogicky s předchozím bodem č.2. 4. Test funkčnosti vysoké dostupnosti (High Availability) konfigurace bude dále ověřena následovně a v každém případě musí být klient schopen připojit a používat CIFS a NFSv4.0 export bez přerušení a zásahu administrátora 4.1 vypnutí libovolného jednoho switche 4.2 shození libovolného síťového rozhraní na front-endu (např. ifdown ethx) 4.3 odpojení libovolného jednoho FC, GE, 10GE kabelu. 21/32
4.4 reboot front-endu používaného klientem 4.5 power off front-endu používaného klientem (přes IPMI rozhraní) Ve všech těchto případech musí běžící test dle popisu v bodu 1. pokračovat v činnosti, tj. nesmí skončit chybou. Nebyl-li klient připojen v okamžiku provedení akcí 4.1 až 4.5, musí být schopen se připojit na funkční server a pracovat. 5. Pro NFSv4.0 export musí dále uspět test zámků dostupný na: http://nfsv4.bullopensource.org/tools/tests/locktest.php a to jak v rámci jednoho klienta, tak i pro více klientů (test je k dispozici zde: http://nfsv4.bullopensource.org/tools/tests_tools/locktests-net.tar.gz). Test bude spuštěn na klientovi, který má připojený NFSv4.0 svazek z některého z front-endů lokálně do /mnt/nfs4. Spouštěný příkaz bude:./locktests -n 10 -f /mnt/nfs4/lockfile. Žádná část testu nesmí skončit chybou. 6. Síťový test bude spuštěn na dvou klientech, kteří mají připojený stejný NFSv4.0 svazek z některého z front-endů lokálně do /mnt/nfs4. Spouštěný příkaz bude: Klient A:./locktests -n 10 -f /mnt/nfs4/lockfile -c 1 Klient B:./locktests --server Klient_A_FQDN Žádná část testu nesmí skončit chybou. 7. Test výpadku disku v rámci jedné RAID skupiny pro Tier-1 a i pro Tier-2 a dodržení podmínek z části A (1. Základní popis, Požadavky kladené na datové úložiště), tj.: pro Tier-1 rebuild (návrat do redundantního stavu zajišťujícího opět ochranu proti výpadku dvou disků ve skupině) libovolné takto vytvořené RAID skupiny nesmí trvat déle než 8 hodin. A současně pro Tier-2 rebuild (návrat do redundantního stavu zajišťujícího opět ochranu proti výpadku dvou disků ve skupině) libovolné takto vytvořené RAID skupiny nesmí trvat déle než 24 hodin. Zadavatel současně požaduje připravit akceptační protokol, ve smyslu ust. čl. IV., odst. 3 této smlouvy, a to ke všem akceptačním testům (zpracuje dodavatel). Tento protokol bude obsahovat: a. v podobě příloh výstupy jednotlivých testů, b. oficiální potvrzení zastoupení výrobce o určení dodávaného HW (resp. seznam sériových čísel dodávaných zařízení) pro český trh či trh EU a koncového zákazníka Biotechnologické a biomedicínské centrum Akademie věd a Univerzity Karlovy ve Vestci (BIOCEV), c. v podobě přílohy k tomuto akceptačnímu protokolu výpis všech případných licencí dodaných k daným zařízením nebo samostatně (název, popis-účel, počet). 22/32
Nedostatky a jejich řešení V případě prokazatelných nedostatků vzniklých či zjištěných v době zkušebního provozu je uchazeč povinen je odstranit, a to nejpozději do 5 pracovních dní od okamžiku, kdy tyto nedostatky zadavatel, prostřednictvím osoby oprávněné za něj jednat dle čl. VIII. kupní smlouvy, písemně uplatnil. Zkušební provoz bude v případě úspěchu zakončen podpisem akceptačního protokolu. 23/32
Příloha podrobných technických specifikací k části B - serverová část K této technické specifikaci doplní uchazeč skutečné specifikace parametrů nabízeného zboží. Specifikace vzorku Rack server - Vědecký server typ 1 Parametr Minimální požadavek zadavatele Skříň Paměť RAM Disky CPU Display Diskový řadič montáž do racku 19" - včetně rackmount kitu, výška max. 8U, možný přístup ke všem komponentám serveru bez nářadí, vizuálně odlišitelné hot-plug vnitřní komponenty 1,5 TB typu DDR3, rozšiřitelnost alespoň na 12TB min. 2ks hot-plug Enterprise SSD 240GB a 2ks hot-plug SAS 600GB 10krpm přednastavené v RAID-1 osmi-socketový systém, osazený osmi CPU, minimálně typu E7-8870 v2 (nebo min. stejně výkonný ekvivalent), nebo alternativně požadujeme dodržet hodnocení dle SPEC CPU2006 (http://www.spec.org/cpu2006/results) výsledky s minimálními hodnotami (sloupec Baseline) u SPECint2006 Rates=3800 a SPECfp2006 Rates=2900. zapojení přes KVM switch typu SAS, 8-mi portový, 1GB zálohovaná Flash cache, podpora hot-plug disků SAS a SSD, podpora RAID - 0, 1, 5, 10, cache funkce - podpora on-line capacity expansion, podpora globálního hot-spare disku 24/32
Rozšiřitelnost alespoň 20x PCIe 3.0 sloty pro rozšiřující karty Ethernet konektivita 4x Ethernet porty 1Gbps a 2x 10 Gbps SFP+ Ethernet, s podpora TOE a iscsi Offload, WOL, iscsi boot, IPv4, IPv6. Optické porty osazené SFP+ SR moduly. Fiber channel konektivita Porty USB Podpora a kompatibilita s daným OS minmálně 2x port Fiber channel 16Gbps na dvou nezávislých kartách min. 4x USB 2.0, alespoň 2 v přední části Microsoft Windows Server 2012 x64, Standard a DataCenter, Red Hat RHEL, SUSE Linux Podpora virtualizace Red Hat RHEV (KVM), VMware ESX, Microsoft Hyper-V, XenServer Napájecí zdroje Management a vzdálená správa redundantní síťové napájecí zdroje management serveru nezávislý na operačním systému - požadované funkce a vlastnosti: Web GUI a dedikovaná IP adresa, firmware update/rollback pro jednotlivé hardware komponenty, podpora OS Deploymentu, logování událostí, monitoring hardwarových sensorů (teplota, napětí, stav, chybové sensory), alerty (server reset, kritické senzorové hodnoty, atd.) za použití emailu, podpora IPv4 a IPv6, IPMI funkcionalita, přístup k nainstalovanému operačnímu systému přes funkci managementu, konfigurace hardware komponent a RAID, server reset, reboot, poweron/off/cyclepower management vlastnosti, security vlastnosti 25/32
(podpora AD, encryption), BIOS recovery Počet serverů tohoto 1ks typu Servisní skupina č. 3 Skupina délky záruky 3 roky Specifikace vzorku Rack server - Vědecký server typ 2 Parametr Minimální požadavek zadavatele Skříň Paměť RAM Disky CPU Display montáž do racku 19" - včetně rackmount kitu, výška max. 4U, možný přístup ke všem komponentám serveru bez nářadí, vizuálně odlišitelné hot-plug vnitřní komponenty 1 TB typu DDR3, rozšiřitelnost alespoň na 6TB min. 2ks hot-plug SAS 600GB 10krpm přednastavené v RAID-1 čtyř-socketový systém, osazený čtyřmi CPU, minimálně typu E7-4830 v2 (nebo min. stejně výkonný ekvivalent), nebo alternativně požadujeme dodržet hodnocení dle SPEC CPU2006 (http://www.spec.org/cpu2006/results) výsledky s minimálními hodnotami (sloupec Baseline) u SPECint2006 Rate=1200 a SPECfp2006 Rate=1000. zapojení přes KVM switch 26/32
Diskový řadič typu SAS, 8-mi portový, podpora hotplug disků SAS a SSD, podpora RAID - 0, 1, 5, 10, cache funkce - podpora on-line capacity expansion, podpora globálního hot-spare disku Rozšiřitelnost alespoň 10x PCIe 2.0 sloty pro rozšiřující karty Ethernet konektivita 2x Ethernet porty 1Gbps a 2x 10 Gbps SFP+ Ethernet, s podpora TOE a iscsi Offload, WOL, iscsi boot, IPv4, IPv6. Optické porty osazené SFP+ SR moduly. Fiber channel konektivita Porty USB Podpora a kompatibilita s daným OS minmálně 2x port Fiber channel 16Gbps na dvou nezávislých kartách min. 4x USB 2.0, alespoň 2 v přední části Microsoft Windows Server 2012 x64, Standard a DataCenter, Red Hat RHEL, SUSE Linux Podpora virtualizace Red Hat RHEV (KVM), VMware ESX, Microsoft Hyper-V, XenServer Napájecí zdroje redundantní síťové napájecí zdroje 27/32
Management a vzdálená správa Počet serverů tohoto typu Servisní skupina č. 3 Skupina délky záruky management serveru nezávislý na operačním systému - požadované funkce a vlastnosti: Web GUI a dedikovaná IP adresa, firmware update/rollback pro jednotlivé hardware komponenty, podpora OS deploymentu, logování událostí, monitoring hardwarových sensorů (teplota, napětí, stav, chybové sensory), alerty (server reset, kritické senzorové hodnoty, atd.) za použití emailu, podpora IPv4 a IPv6, IPMI funkcionalita, přístup k nainstalovanému operačnímu systému přes funkci managementu, konfigurace hardware komponent a RAID, server reset, reboot, poweron/off/cyclepower management vlastnosti, security vlastnosti (podpora AD, encryption), BIOS recovery 1ks 3 roky Specifikace vzorku Parametr Architektura Montáž Pozice na servery Switch moduly šasi Blade server šasi Minimální požadavek zadavatele Blade do racku 19" - včetně rackmount kitu, výška max. 10U min. 14 pozic na zadní straně šasi min. 4 pozice pro aktivní prvky 28/32
Ethernet konektivita Fiber channel konektivita Chladící systém šasi Napájecí zdroje Management a vzdálená správa Počet šasi tohoto typu redundantni ethernet switche, každý min. 24 portů 10Gbps, propustnost aspoň 1,28Tbps, možnost škálování až na 56x 10Gb a 2x 40Gb ethernet portů na switch, podpora stackingu přes 10Gb a 40Gb porty. Každý switch osazený minimálně 8x 10Gbps SFP+ SR moduly. redundantní Fiber channel 16Gbps switche, možnost škálování až do 48 portů. Každý switch osazený minimálně 8x 16Gbps SFP+ moduly. redundantní chladící systém redundantní síťové napájecí zdroje, plně osazené v maximální výkonnostní konfiguraci, EU 230/400V redundatní management modul (možnost ovládání i přeš Web GUI), kompletní vzdálená zpráva šasi a blade serverů a síťových modulů, logování událostí, monitoring hardwarových sensorů (teplota, napětí, stav, chybové sensory), možnost předávání informací pomocí emailu, podpora IPv6, podpora šifrování a autorizace uživatelů, možnost upgrade firmware, možnost vzdáleného namapování lokálního prostředků 1ks Servisní skupina č. 5 Délka záruky 5let 29/32