Technická dokumentace a specifikace p edm tu koup

BIOTECHNOLOGICKÉABIOMEDICÍNSKÉCENTRUM AKADEMIEV DAUNIVERZITYKARLOVY VEVESTCI

ýá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): x

x

x

x

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 ve jménu 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í jména, zvláštní oznaþení podniku, zvláštní oznaþení výrobkĤ, výkonĤ anebo obchodních materiálĤ,

Ústav molekulární genetiky AV ýR, v. v. i., Útvar BIOCEV budova City Point, HvČzdova 1689/2a, 140 62 Praha 4 – Pankrác

tel: +420 226 201 526 | mobil: +420 774 798 102 e-mail: [email protected] | web: www.biocev.eu

1/30


která platí pro urþitý podnik nebo organizaþní jednotku za pĜíznaþné, popĜ. patenty a užitné vzory, 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: x x

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) se rozumí "další pracovní den" a BD (Business day) se rozumí "pracovní den". Skupiny: x

x x

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)



2/30


x x

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) 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 cca 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.

ýást A 1. Základní popis 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),



3/30


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í 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.

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Ĥ



4/30


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. nasazení protokolĤ NFSv4, SMB 2.0, HTTP(S), SFTP, FTP(S), SCP rsync. Z hlediska HSM pĤjde o lokálnČ pĜipojený souborový systém. 3.

PĜedpokládáme a dále protokolu

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 = 1012B, 1PB = 1015B, 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

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):



5/30


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 Tier1. Požadavek na rychlost diskĤ v Tier-1 je 10,000 rpm.

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 Tier2. Požadavek na rychlost diskĤ v Tier-1 je 7,200 rpm.

c)

Tier-3: Pásková knihovna osazená páskami o minimální využitelné kapacitČ 1120 TB. Požadovaná kapacita 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 minimální rychlost 8 Gbs. Switche však musí podporovat i osazení SFP transceivery o rychlosti 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Ĥ.



6/30


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 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ý



7/30


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Č 12 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Č 96 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. 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Č 8Gbps FC a to minimálnČ dvČma aktivními cestami (tj. min. 2x 8Gbps 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 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Č 96 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 activeactive pomocí protokolĤ: SCP, FTP(S), CIFS/SAMBA. Export CIFS/SAMBA musí být nakonfigurován jako klastrový.



8/30


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ý front-end 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é 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



9/30


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.

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).



10/30


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. Uchazeþ pĜedloží rovnČž roadmap nabízeného filesystému.

3. Výkonové požadavky 1.

Výkony diskĤ uvećte ve dvojkových násobcích, tj. 1MiB = 220B, 1TiB = 240B, výkony u páskové knihovny uvećte v desítkových násobcích, tj. 1MB = 106B, 1TB = 1012B.

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í. V pĜípadČ, že se ani tak nepodaĜí výkonu dosáhnout, vyhrazujeme si právo odstoupení od smlouvy.

3.

Výkonové požadavky pro Tier-1:



11/30


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 Program iozone používá jednotky v dvojkových násobcích (KiB, MiB) apod.

4.

MiB/s.

Výkonové požadavky pro pĜípadnou 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Ė 5.5 TB/h.

5.

Výkonové požadavky pro front-end serverĤ: Pro všechny front-end servery požadujeme minimální skóre získané aplikací SPEC2006 (nebo ekvivalentní hodnocení) ve variantČ int (integer), rate, noautoparalel, 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.



12/30


Ú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 hot-spare 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 hot-spare 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 8Gbit FC a zároveĖ 10Gbit iSCSI/FCoE. Minimální poþet jsou 4x 8Gb FC porty per Ĝadiþ a 2x 10GbE porty per Ĝadiþ.

3.

Všechny disky musí být typu SAS s rozhraním 6Gb. Velikost Write-back cache ĜadiþĤ diskového pole musí být minimálnČ 8 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.

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 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



13/30


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 - 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.



14/30


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í 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 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. ýást B 1. Základní popis 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 podrobných technických specifikací 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 parametru nabízeného zboží.

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 s 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.



15/30


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. ýást C 1. Základní popis 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Ĥ.

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 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.



16/30


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é). ýást D 1. Požadavek na energetickou zátČž a UPS 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.

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:



17/30


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/m2.

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).

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.



18/30


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.

Obr. þ. 1. Plán hlavní serverovny



19/30


ýá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.



20/30


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).



21/30


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.



22/30


PĜíloha podrobných technických specifikací k þásti B - serverová þást

Specifikace vzorku Parametr

Rack server - VČdecký server typ 1 Minimální požadavek zadavatele

SkĜíĖ

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 6TB

PamČĢ RAM Disky

min. 2ks hot-plug SSD 128GB a 2ks hot-plug SAS 600GB 10krpm pĜednastavené v RAID-1

CPU

Display

osmi-socketový systém, osazený osmi CPU, minimálnČ typu E7-8870 (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 result - base) u SPECint2006=38 a SPECfp2006=45. zapojení pĜes KVM switch

Diskový Ĝadiþ

typu SAS, 8-mi portový, 512MB bateriovČ zálohovaná 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

RozšiĜitelnost

alespoĖ 7x PCIe 2.0 sloty pro rozšiĜující karty



23/30


Ethernet konektivita

Fiber channel konektivita

2x Ethernet porty 1Gbps a 2x 10 Gbps Ethernet, s podpora TOE a iSCSI Offload, WOL, iSCSI boot, IPv4, IPv6 minmálnČ 2x port Fiber channel 16Gbps na dvou nezávislých kartách

Porty USB

min. 4x USB 2.0, alespoĖ 2 v pĜední þásti

Podpora a kompatibilita s daným OS

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

Management a vzdálená správa

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

Poþet serverĤ tohoto



24/30


typu Skupina délky záruky

þ. 3 3 roky


Rack server - VČdecký server typ 2 Minimální požadavek zadavatele

SkĜíĖ

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 3TB

Servisní skupina

PamČĢ RAM Disky

min. 2ks hot-plug SAS 600GB 10krpm pĜednastavené v RAID-1

CPU

þtyĜ-socketový systém, osazený þtyĜmi CPU, minimálnČ typu E7-4830 (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 result - base) u SPECint2006=30 a SPECfp2006=50. zapojení pĜes KVM switch

Display 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




25/30




2x Ethernet porty 1Gbps a 2x 10 Gbps Ethernet, s podpora TOE a iSCSI Offload, WOL, iSCSI boot, IPv4, IPv6 minmálnČ 2x port Fiber channel 16Gbps na dvou nezávislých kartách

Porty USB






Napájecí zdroje

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 (podpora AD, encryption), BIOS recovery 1ks

Poþet serverĤ tohoto



26/30


typu Skupina délky záruky

þ. 3 3 roky


Blade server šasi Minimální požadavek zadavatele

Architektura

Blade

Montáž

do racku 19" - vþetnČ rackmount kitu, výška max. 10U

Pozice na servery

min. 14 pozic

Switch moduly šasi

na zadní stranČ šasi min. 4 pozice pro moduly


redundantni ethernet switche, každý min. 24 portĤ 10Gbps, propustnost aspoĖ 1,28Tbps, možnost škálování až na 56x 10Gb ethernet portĤ na switch, podpora stackingu pĜes 10Gb a 40Gb porty


redundantní Fiber channel 16Gbps switche, možnost škálování až do 48 portĤ

Chladící systém šasi

redundantní chladící systém

Napájecí zdroje

redundantní síĢové napájecí zdroje, plnČ osazené v maximální výkonnostní konfiguraci, EU 230/400V

Servisní skupina



27/30



Poþet šasi tohoto typu

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


Blade server Minimální požadavek zadavatele

Architektura

Blade

Montáž

osaditelný do blade šasi

Poþet CPU patic

minimálnČ 2

Poþet jader na fyzický procesor

minimálnČ 8 jader

CPU

dvouprocesorový systém, tj. osazený dvČma CPU. MinimálnČ typu E5-2690 (nebo min. stejnČ výkonným 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 result - base) u SPECint2006=58 a SPECfp2006=90.



28/30


PamČĢ RAM

128 GB typu DDR3, rozšiĜitelnost alespoĖ na 768 GB, minimálnČ 24 DIMM slotĤ


minimálnČ dual-port ethernet 10Gbps, redundantní pĜipojení do sítČ, podpora virtualizace portĤ

Fiber channel konektivita Management a vzdálená správa

2-portová Fiber channel karta 16Gbps Ano, pĜes management blade šasi

Disky

Ano, možnost osazení 2x pevný disk, typu SAS, hot-plug





Napájecí zdroje

Souþástí blade šasi a plnČ kompatibilní s blade serverem


Ano, pĜes management blade šasi, s vlastnostmi kompletní vzdálené zprávy, požadován monitoring stavu serveru 3ks

Poþet serverĤ tohoto typu Servisní skupina Délka záruky

þ. 4 5 let


Rack server - provozní Minimální požadavek zadavatele

SkĜíĖ

montáž do racku 19" - vþetnČ rackmount kitu, výška max. 2U



29/30


PamČĢ RAM

32 GB typu DDR3, rozšiĜitelnost alespoĖ na 64GB

Disky

min. 2ks 500GB SATA HDD

CPU

Display

minimálnČ dvou-socketový systém, osazený min. jedním CPU, minimálnČ typu E5-2620 (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 result - base) u SPECint2006=38 a SPECfp2006=64. zapojení pĜes KVM switch

Diskový Ĝadiþ

s podporou RAID 0, 1, 10

RozšiĜitelnost



2x Ethernet porty 1Gbps

Porty USB






Poþet serverĤ tohoto typu Servisní skupina

2ks

Skupina délky záruky

þ. 3 3 roky



30/30

Technická dokumentace a specifikace p edm tu koup

Recommend Documents