SMLOUVA

SMLOUVA

o dodávce diskových kapacit, software a poskytování podpory

uzavřená podle § 1746 odst. 2 zákona č. 89/2012 Sb., občanský zákoník, ve znění pozdějších předpisů (dále jen „občanský zákoník“) a zákona č. 121/2000 Sb., o právu autorském,

o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon), ve znění pozdějších předpisů (dále jen „autorský zákon“),

mezi:

Českou národní bankou

Na Příkopě 28, 115 03 Praha 1

zastoupenou: Ing. Xxxxxxx Xxxxxxxxx, ředitelem sekce informatiky a

Ing. Xxxxxxx Xxxxxxxx, ředitelem sekce správní IČO: 48136450

DIČ: CZ48136450

(dále jen „objednatel“ nebo „ČNB“)

a

0X.xx, s.r.o.

zapsanou v obchodním rejstříku vedeném Krajským soudem v Brně, spisová značka C51803

Xxxxxxxx 1055/25, 616 00 Brno

zastoupenou: Ing. Xxxxx Xxxxxxxx, prokuristou IČO: 27683273

DIČ: CZ27683273

číslo účtu 35-0000000000, kód banky 0100 (dále jen „zhotovitel“)

Článek I Předmět plnění

1. Zhotovitel se zavazuje dodat, nainstalovat a zprovoznit technické a programové prostředky pro ukládání a zpracování dat důležitých informačních systémů objednatele, vypracovat dokumentaci dle specifikace uvedené v příloze č. 2 smlouvy a zaškolit zaměstnance objednatele, a to za podmínek uvedených dále v této smlouvě (dále jen

„dílo“). Dílo musí splňovat závazné požadavky objednatele uvedené v příloze č. 5 smlouvy a musí být realizováno v souladu s návrhem technického řešení obsaženým v příloze č. 7 smlouvy. Technické a programové prostředky musí splňovat specifikaci uvedenou v příloze č. 1 smlouvy.

2. Dílo dle odst. 1 bude realizováno ve dvou dílčích plněních takto:

a) první dílčí plnění zahrnuje:

- dodávku technických a programových prostředků dle specifikace uvedené v příloze č. 1 smlouvy, instalaci technických prostředků a jejich implementaci do prostředí objednatele (zapojení do SAN/LAN), zprovoznění “zrcadleného disku“,

- připojení nejméně 2 serverů objednatele a instalaci programových prostředků

na tyto servery, instalaci SW pro management dodaných technických prostředků,

- konfiguraci 5 LUNů, přiřazení k serverům, testovací provoz v délce 2 týdnů zahrnující ukázky základních operací s diskovým polem. V testovacím provozu objednatel vytvoří s dodanými prostředky MS cluster server mezi lokalitami a prověří jeho funkčnost. Předmětem testovacího provozu bude i vypínání diskového pole a další testy funkčnosti související s reakcí na výpadky jednotlivých komponent dodaných prostředků (FC port, celé pole, arbitr, …),

- dodání dokumentace výrobce technických a programových prostředků,

- školení 6 odborných zaměstnanců objednatele v délce, kterou určí zhotovitel tak, aby zaměstnanci byli vyškoleni v rozsahu dle přílohy č. 2 smlouvy. Školení musí být provedeno certifikovaným/i lektorem/lektory. Zhotovitel zajistí i příslušné školící materiály (v češtině nebo angličtině). Součástí školení musí být prostředí, kde bude možné prakticky zkoušet probíranou látku (přístup může být vzdálený). V případě, že školení bude mimo Prahu, musí zhotovitel na své náklady zajistit dopravu do místa školení a zpět, ubytování a celodenní stravování pro zaměstnance objednatele po dobu školení. Školícím jazykem bude čeština nebo angličtina. V případě, že školení bude mimo Prahu, je nutné školení organizovat pro 2 skupiny zaměstnanců. O provedeném školení bude zhotovitelem zpracován protokol;

b) druhé dílčí plnění zahrnuje:

- zkušební provoz v délce 4 týdnů,

- vypracování realizační dokumentace, v níž bude zachycen popis konečného stavu a provozních postupů a jejíž součástí bude i havarijní plán. Realizační dokumentace bude zaslána e-mailem pověřeným osobám objednatele dle čl. IV odst. 2 k připomínkám,

- předání zbývající dokumentace dle přílohy č. 2 smlouvy pověřeným osobám objednatele dle čl. IV odst. 2.

3. Dodané technické prostředky podle této smlouvy budou nové a nepoužité (maximálně z továrny zahořelé z výroby nebo zapnuté pro ověření funkčnosti v rámci kompletace prostředků zhotovitelem před dodáním). Uvedené se týká i všech komponent (zejména všech typů disků, SFP modulů, zdrojů apod.).

4. Zhotovitel bude zajišťovat průběžně nebo v rámci příslušného dílčího plnění činnosti uvedené v příloze č. 2 smlouvy.

5. Zhotovitel se dále zavazuje poskytovat za podmínek uvedených dále v této smlouvě

podporu:

a) technických prostředků a programových prostředků, které jsou nedílnou součástí

technických prostředků,

b) programových prostředků, které nejsou nedílnou součástí technických prostředků.

6. Objednatel se zavazuje za poskytnutá plnění uhradit ceny dle čl. III.

Článek II

Lhůty, místo a způsob předání dílčích plnění

1. Smluvní strany vzájemně dohodly pro jednotlivá dílčích plnění následující lhůty:

a) zhotovitel předá první dílčí plnění do 12 týdnů ode dne nabytí účinnosti smlouvy,

b) zhotovitel předá druhé dílčí plnění do 19 týdnů ode dne nabytí účinnosti smlouvy.

2. Lhůta uvedená v odst. 1 písm. a) a/nebo b) tohoto článku bude prodloužena na žádost zhotovitele o dobu, po kterou zhotovitel objektivně nemohl pokračovat v plnění dle této smlouvy na základě skutečností, které zhotovitel nemohl, byť jednal s náležitou péčí, předvídat a které sám nezpůsobil (včetně např. z důvodu na straně výrobce, výpadku či zdržení v dodavatelsko-odběratelském řetězci). Žádost, včetně řádného zdůvodnění, zašle zhotovitel na e-mailové adresy pověřených osob objednatele dle čl. IV odst. 2, a to před uplynutím příslušné lhůty. O prodloužení příslušné lhůty/lhůt bude sepsán zápis, který bude podepsán alespoň jednou pověřenou osobou za každou smluvní stranu, bez povinnosti uzavření dodatku k této smlouvě.

3. Podpora všech dodaných technických a programových prostředků bude zahájena ke dni podpisu protokolu o předání a převzetí 1. dílčího plnění. V případě, že s ohledem na podmínky výrobce dodávaných technických a programových prostředků nebude možné zahájení poskytování podpory až k datu předání a převzetí 1. dílčího plnění, objednatel akceptuje zahájení podpory v průběhu 1. dílčího plnění.

4. Objednatel se zavazuje umožnit zhotoviteli vykládku a úschovu technických prostředků určených k instalaci v prostorách objednatele v termínu, o kterém bude pověřená osoba zhotovitele informovat e-mailem pověřené osoby objednatele dle čl. IV odst. 2 nejméně tři pracovní dny předem.

5. Objednatel převezme technické prostředky do úschovy a zajistí jejich bezpečné uskladnění do zahájení instalace. O předání a převzetí prostředků do úschovy bude sepsán zhotovitelem protokol, který podepíše alespoň 1 pověřená osoba za každou smluvní stranu dle čl. IV odst. 2.

6. Výsledek testovacího a zkušebního provozu bude uveden v zápise, který bude podepsán alespoň jednou pověřenou osobou za každou smluvní stranu. Objednatel (pověřené osoby objednatele) není povinen prodloužit dobu trvání testovacího či zkušebního provozu, budou-li zjištěny skutečnosti uvedené v odst. 7 tohoto článku.

7. O předání jednotlivých dílčích plnění sepíše zhotovitel protokol, který podepíše alespoň jedna pověřená osoba za každou smluvní stranu dle čl. IV odst. 2 a jehož přílohou bude zápis dle odst. 6 tohoto článku. Žádné z dílčích plnění nemůže být objednatelem převzato, pokud bude zjištěno, že technické a programové prostředky neodpovídají specifikaci dle přílohy č. 1, dílo nesplňuje veškeré závazné požadavky objednatele dle přílohy č. 5 smlouvy či není realizováno v souladu s přílohou č. 7 smlouvy.

8. Místem plnění budou prostory výpočetního střediska v objektech objednatele

na adresách: Xxxxx 0, Xxxxxxxxx xx. 0 x Xxxxx 0, Xxxxxxxxxxxx 000.

Článek III

Cena plnění a platební podmínky

1. Ceny plnění uvedené v odst. 2 až 5 tohoto článku byly stanoveny dohodou smluvních

stran a zahrnují veškeré náklady zhotovitele spojené s plněním podle této smlouvy.

2. Cena díla dle čl. I odst. 1 činí celkem 4 312 945,- Kč bez DPH, z toho cena prvního dílčího plnění činí 4 288 945,- Kč bez DPH, cena druhého dílčího plnění činí 24 000,- Kč bez DPH. Bližší specifikace cen (včetně ceny za zaškolení) je uvedena v příloze č. 8 smlouvy.

3. Cena za 60 měsíců podpory technických prostředků činí 94 170,- Kč bez DPH a cena za 60 měsíců podpory programových prostředků, které jsou nedílnou součástí technických prostředků, činí 44 111,- Kč bez DPH.

4. Paušální cena za podporu programových prostředků, které nejsou nedílnou součástí technických prostředků činí ročně 0,- Kč bez DPH (technické řešení takové programové prostředky nezahrnuje).

5. Paušální cena za podporu technických prostředků a programových prostředků, které jsou nedílnou součástí technických prostředků, po uplynutí 60 měsíců činí ročně 37 170,- Kč bez DPH.

6. K cenám bude účtována DPH v sazbě platné v den uskutečnění příslušného zdanitelného plnění.

7. Ceny dílčích plnění dle odst. 2 tohoto článku budou hrazeny na základě daňového dokladu vystaveného zhotovitelem nejdříve v den podpisu protokolu o převzetí příslušného dílčího plnění dle čl. II odst. 7.

8. Cena podpory podle odst. 3 a cena podpory dle odst. 4 za prvních 12 měsíců budou

uhrazeny na základě daňového dokladu vystaveného nejdříve po podpisu protokolu

o převzetí 1. dílčího plnění dle čl. II odst. 7 a po doložení, že zhotovitel u výrobce uhradil částku za podporu technických a programových prostředků. Za doložení lze uznat, že na www stránkách výrobce bude uvedeno datum platnosti podpory na 60 měsíců u technických a programových prostředků, které jsou nedílnou součástí technických prostředků, a na 12 měsíců u programových prostředků, které nejsou nedílnou součástí technických prostředků, od data podpisu protokolu o převzetí 1. dílčího plnění, popř. v souladu s čl. II odst. 3 ode dne nastalého v průběhu prvního dílčího plnění.

9. Paušální cena podpory dle odst. 4 tohoto článku na další roční období a paušální cena podpory dle čl. 5 na další (roční) období budou hrazeny předem na základě daňového dokladu vystaveného nejdříve první den ročního období, ve kterém bude příslušné plnění poskytováno. Paušální ceny podpory zahrnují veškeré náklady zhotovitele spojené s jejich poskytováním (včetně náhradních dílů, práce, dopravného, cestovného, plnění dle čl. V odst. 3, apod.).

10. V případě, že smlouva skončí před uplynutím doby, na kterou je uzavřena, vrátí zhotovitel objednateli alikvotní část předplacené ceny podpory, pokud tato nebude poskytována přímo výrobcem, případně jím pověřenou společností (osobou).

11. Doklady k úhradě zasílá zhotovitel elektronicky jako přílohu e-mailové zprávy na adresu xxxxxxx@xxx.xx ve formátu ISDOC. Pokud není možné vytvořit doklad ve formátu ISDOC, je možné zasílat jej ve formátu PDF. V jedné e-mailové zprávě smí být pouze jeden doklad k úhradě. Mimo vlastní doklad k úhradě může být přílohou e-mailové zprávy jedna až sedm příloh k dokladu ve formátech PDF, DOC, DOCX, XLS, XLSX. Přijaty budou i doklady k úhradě v jiném formátu, který bude v souladu s evropským standardem elektronické faktury. Nebude-li možné zaslat doklad k úhradě elektronicky, zašle jej zhotovitel v analogové formě na adresu:

Česká národní banka

sekce rozpočtu a účetnictví odbor účetnictví

Na Příkopě 28

115 03 Praha 1

12. Doklad k úhradě bude obsahovat údaje podle § 435 občanského zákoníku a bankovní účet, na který má být placeno a který je uveden v záhlaví této smlouvy nebo který byl později aktualizován zhotovitelem (dále jen „určený účet“). Daňový doklad bude nadto obsahovat náležitosti stanovené v zákoně o dani z přidané hodnoty. Nezbytnou náležitostí

každého dokladu je také číslo této smlouvy (ve formátu ISDOC v poli ID ve skupině Contract References). Pokud doklad bude postrádat některou ze stanovených náležitostí nebo bude obsahovat chybné údaje, je objednatel oprávněn jej vrátit zhotoviteli, a to až do lhůty splatnosti. Nová lhůta splatnosti začíná běžet dnem doručení bezvadného dokladu.

13. V případě, že bude v dokladu k úhradě uveden jiný než určený účet, je pověřená osoba zhotovitele povinna na základě výzvy objednatele sdělit na e-mailovou adresu, ze které byla výzva odeslána, zda má být zaplaceno na bankovní účet uvedený v dokladu, nebo na určený účet. V tomto případě se doklad k úhradě nevrací s tím, že lhůta splatnosti začíná běžet až dnem doručení sdělení zhotovitele podle předchozí věty.

14. Splatnost dokladu k úhradě činí 14 dnů ode dne jejich doručení objednateli. Povinnost zaplatit je splněna odepsáním příslušné částky z účtu objednatele ve prospěch účtu zhotovitele.

15. Smluvní strany se dohodly, že objednatel je oprávněn započíst jakoukoli svou peněžitou pohledávku za zhotovitelem, ať splatnou či nesplatnou, oproti jakékoli peněžité pohledávce zhotovitele za objednatelem, ať splatné či nesplatné.

Článek IV

Součinnost, pověřené osoby smluvních stran, prohlášení a závazky zhotovitele

1. Objednatel se zavazuje vytvořit zhotoviteli k instalaci potřebné podmínky, zejména:

a) zajistit nezbytné provozní odstávky, i když je v té fázi objednatel nepředpokládá,

b) poskytnout plán stávajícího propojení objektů, informace o používaném označení portů stávajících zařízení (DWDM, patch panely, servery, …), případně používaných konvencí pro tvorbu jejich označování, používané konvence pro označování portů v serverech a na paměťových zařízeních,

c) umožnit prohlídky míst plnění s ohledem na fyzické umístění dodávaných prostředků,

d) zajistit potřebné rekonfigurace všech technických a programových systémů dotčených přechodem na dodávané prostředky,

e) přidělit IP adresy pro dodávané prostředky pro potřeby managementu,

f) přidělit porty na FC switchích (SAN),

g) zajistit přístup odborných pracovníků zhotovitele na příslušná pracoviště objednatele.

2. Pověřenými osobami smluvních stran pro poskytování součinnosti pro zajištění řádného plnění smlouvy, technická jednání a k předání a převzetí jednotlivých plnění a zápisů dle této smlouvy jsou:

za objednatele:

za zhotovitele:

3. Smluvní strany se zavazují ohlásit změnu pověřených osob smluvních stran nebo jejich

kontaktních údajů uvedených v odst. 2 tohoto článku nejpozději následující pracovní den

po provedení změny na e-mailové adresy pověřených osob druhé smluvní strany, bez

nutnosti uzavřít dodatek ke smlouvě.

4. Zhotovitel prohlašuje, že bude mít po celou dobu trvání smlouvy sjednáno pojištění pro případ vzniku odpovědnosti za škodu způsobenou třetí osobě v souvislosti s plněním této smlouvy, a to s pojistným plněním ve výši nejméně 5 000 000,- Kč s tím, že jeho spoluúčast nepřevyšuje 5 %. Zhotovitel se zavazuje, že pojištění v uvedené výši a rozsahu zůstane účinné po celou dobu účinnosti této smlouvy a do 5 pracovních dnů od výzvy objednatele je zhotovitel povinen toto objednateli prokázat.

5. Xxxxxxxxxx je povinen zajistit, aby pracovníci, kteří se budou podílet na plnění této smlouvy, po celou dobu trvání smlouvy splňovali kvalifikační kritéria, která objednatel stanovil v bodě 7.3 písm. b) zadávací dokumentace veřejné zakázky na plnění předmětu této smlouvy. Zhotovitel je povinen na vyžádání objednatele splnění kvalifikace jednotlivých pracovníků doložit, a to do 5 pracovních dnů ode dne doručení žádosti.

6. Použije-li zhotovitel při své činnosti podzhotovitele, nahradí škodu jím způsobenou stejně, jakoby ji způsobil sám.

Článek V

Podpora technických a programových prostředků

1. Zhotovitel se zavazuje poskytovat objednateli podporu všech dodaných technických a programových prostředků za podmínek uvedených níže v této smlouvě, a to dnem podpisu protokolu o převzetí 1. dílčího plnění dle čl. II odst. 7, popř. v souladu s čl. II odst. 3 zahájit poskytování podpory v průběhu 1. dílčího plnění.

2. Podmínky pro podporu dodaných technických a programových prostředků jsou

následující:

a) pro uskutečnění servisního zásahu techniků zhotovitele platí nepřetržitý režim, tj. technici zhotovitele budou dostupní po dobu 24 hodin a 7 dnů v týdnu. Tento režim platí pro technické i programové prostředky;

b) odstraňování kritických závad:

Za kritickou závadu se považuje taková závada, kdy uložená data nejsou dostupná na úrovni operačního systému serveru alespoň v jedné z lokalit. Mezi kritické závady dále patří také:

- přerušení vzdáleného zrcadlení mezi lokalitami, které není způsobené na komunikační trase zajišťované objednatelem;

- zásadní výkonnostní problémy (zejména snížení výkonu o více než 50 %).

Odstranění kritických závad musí být ukončeno do 24 hodin od nahlášení závady.

c) odstraňování nekritických závad technických prostředků:

Za nekritickou závadu se považuje taková závada dodaných technických prostředků, která neohrožuje vlastní provoz těchto prostředků, zejména:

- závady na managementu diskových polí;

- výpadek první z redundantních komponent.

Odstranění nekritické závady musí být ukončeno do 168 hodin od nahlášení.

d) při vzniku nekritické závady programových prostředků bude zahájeno řešení závady nejpozději do 4 hodin po jejím ohlášení zhotoviteli. Na jejím odstranění musí

zhotovitel pracovat bez zbytečného odkladu a přerušení a musí využít všech prostředků k dosažení nápravy.

3. Zhotovitel v rámci zajištění podpory zajistí náhradní díly dodaných technických prostředků, a to bez omezení a nové a opravné verze všech dodaných programových prostředků včetně jejich implementace. Součástí podpory je také:

- informování objednatele o nových nebo opravných verzích;

- konzultace k plánovaným změnám.

4. Pokud závadu zjistí zhotovitel, oznámí ji neprodleně objednateli a další postup se řídí ustanoveními tohoto článku.

5. Zhotovitel je srozuměn s tím, že veškerá komunikace při hlášení a řešení závad bude mezi objednatelem a pracovníky zhotovitele probíhat v českém jazyce.

6. Služby poskytované zhotovitelem musí vyhovovat technickým specifikacím a požadavkům výrobce příslušného technického prostředku.

7. Požadavky na odstranění závad a na poskytnutí konzultací k plánovaným změnám budou předávány způsobem uvedeným v příloze č. 3 smlouvy. Kritické závady objednatel současně oznámí telefonicky. Přijetí požadavku na odstranění kritické závady je zhotovitel povinen potvrdit e-mailem na adresu osob uvedených v příloze č. 3 smlouvy nejpozději do 1 hodiny od obdržení požadavku. Obdržení požadavku na odstranění ostatních závad a provedení ostatních služeb je zhotovitel povinen potvrdit e-mailem na adresu osob uvedených v příloze č. 3 smlouvy nejpozději do 2 hodin od obdržení požadavku. Potvrzení e-mailem není nutné v případě, kdy dojde k jinému prokazatelnému zahájení odstraňování závad nebo plnění ostatních služeb (např. telefonický kontakt, příjezd technika, e-mail od dopravce o odeslání náhradního dílu apod.).

8. Xxxxxxxxxx se zavazuje převzít od objednatele vyměněné vadné díly a zajistit jejich

odpovídající ekologickou likvidaci podle platných právních předpisů.

9. Zhotovitel souhlasí s tím, že při výměně jakékoliv komponenty, na které jsou/byla data objednatele (typicky HDD/SSD/Flash technologie apod.), nebude tato komponenta po opravě vrácena zhotoviteli a objednatel zajistí její odpovídající likvidaci.

10. Zhotovitel prohlašuje, že ke dni podpisu protokolu dle čl. II odst. 3 pověřenými osobami smluvních stran bude u výrobce sjednána podpora na období 60 měsíců u technických a programových prostředků, které jsou nedílnou součástí technických prostředků a na 12 měsíců u programových prostředků, které nejsou nedílnou součástí technických prostředků a že v krajním případě je možné čerpání této podpory v rozsahu dle této smlouvy včetně nároků na nové verze FW a SW přímo u výrobce (nebo jím pověřené společnosti/osoby), a to bez finančních nákladů pro objednatele.

11. Zhotovitel prohlašuje, že je oprávněn poskytovat podporu technických a programových prostředků, které jsou předmětem plnění podle této smlouvy, aniž by došlo k omezení/ztrátě podpory od výrobce. Zhotovitel dále prohlašuje, že veškeré technické a programové prostředky (HW a SW), včetně všech jejich součástí, které zhotovitel zamýšlí dodat objednateli v rámci plnění dle této smlouvy, jsou určeny výrobcem pro evropský trh, pokud výrobce takové určení provádí. V případě nepravdivosti prohlášení dle tohoto odstavce je zhotovitel uhradit objednateli škodu v plné výši.

Článek VI

Smluvní pokuty, úrok z prodlení

1. V případě prodlení zhotovitele má objednatel právo požadovat smluvní pokutu:

a) ve výši 1 000 Kč za každý den prodlení ve lhůtě dle čl. II odst. 1 písm. a),

b) ve výši 1 000 Kč za každý den prodlení ve lhůtě dle čl. II odst. 1 písm. b),

c) ve výši 1 000 Kč za každý den prodlení se zahájením poskytování podpory ve lhůtě dle čl. II odst. 3.

2. V případě prodlení zhotovitele má objednatel právo požadovat smluvní pokutu:

a) ve výši 1 000 Kč za každou hodinu nedostupnosti ani jednoho z kontaktů zhotovitele uvedených v příloze č. 3 smlouvy v době dle čl. V odst. 2 písm. a),

b) ve výši 1 000 Kč za každou hodinu prodlení zhotovitele v kterékoli lhůtě dle

čl. V odst. 7,

c) ve výši 1 000 Kč za každou hodinu prodlení ve lhůtě dle čl. V odst. 2 písm. b),

d) ve výši 500 Kč za každou hodinu prodlení ve lhůtě dle čl. V odst. 2 písm. c),

e) ve výši 500 Kč za každou hodinu prodlení ve lhůtě pro zahájení odstraňování závady nebo neodůvodněného přerušení odstraňování závady dle čl. V odst. 2 písm. d).

7. V případě, že se po dobu 2 let od podpisu protokolu o převzetí 2. dílčího plnění dle čl. II odst. 7 ukáže, že dílo nesplňuje některý ze závazných požadavků objednatele uvedených v příloze č. 5 smlouvy, má objednatel právo požadovat po zhotoviteli smluvní pokutu ve výši 0,5 % z celkové ceny díla uvedené v čl. III odst. 2, nejméně však 50 000 Kč, a to za každý případ nedodržení závazného požadavku, a to i opakovaně. Tím není dotčeno právo na odstoupení od smlouvy ani na náhradu vzniklé škody v plné výši.

8. V případě prodlení zhotovitele ve lhůtě dle čl. IV odst. 4 nebo 5 je objednatel oprávněn požadovat smluvní pokutu ve výši 2 000 Kč za každý pracovní den prodlení.

9. V případě porušení povinnosti mlčenlivosti zhotovitelem či jeho pracovníky má objednatel právo požadovat smluvní pokutu ve výši 5 000 Kč za každý jednotlivý zjištěný případ porušení této povinnosti, a to i opakovaně.

10. V případě prodlení objednatele s uhrazením daňového dokladu je zhotovitel oprávněn požadovat úrok z prodlení podle nařízení vlády č. 351/2013 Sb.

11. Strany se dohodly, že odpovědnost za škodu zhotovitele v její plné výši není smluvní pokutou vyloučena.

Článek VII

Vlastnictví, nebezpečí škody na věci, licenční ujednání

1. Vlastnictví k technickým prostředkům dle této smlouvy přechází na objednatele dnem podpisu protokolu o převzetí 1. dílčího plnění dle čl. II odst. 7. Právo užívání programových prostředků dodaných dle této smlouvy přechází na objednatele dnem jejich instalace.

2. Dnem převzetí technických prostředků objednatelem do úschovy přechází nebezpečí škody na těchto prostředcích na objednatele.

3. Zhotovitel poskytuje objednateli nevýhradní, nepřevoditelnou a časově neomezenou licenci umožňující užívat dle této smlouvy dodané programové prostředky pouze pro vnitřní potřebu objednatele.

4. Licenční odměna za licenční oprávnění v rozsahu dle odst. 3 tohoto článku je zahrnuta

v cenách uvedených v čl. III této smlouvy.

5. Objednatel není povinen využít licenci ani z části.

6. Zhotovitel prohlašuje, že práva, která touto smlouvou poskytuje, mu náleží bez jakýchkoliv omezení a že odpovídá za škodu, která by objednateli vznikla, pokud by se kdykoliv později zjistilo, že toto prohlášení bylo nepravdivé.

Článek VIII

Mlčenlivost, bezpečnostní požadavky objednatele

1. Xxxxxxxxxx se zavazuje zajistit, že jeho pracovníci, kteří se budou na plnění podle této smlouvy podílet, zachovají mlčenlivost o všech skutečnostech, se kterými se u objednatele seznámí a které nejsou veřejně známy. Povinnost mlčenlivosti není časově omezena. Na pracovníky podzhotovitele se pohlíží jako na pracovníky zhotovitele.

2. Zhotovitel se zavazuje v plném rozsahu dodržovat bezpečnostní požadavky objednatele, které jsou uvedeny v příloze č. 6 smlouvy.

Článek IX

Odstoupení od smlouvy

1. Xxxxxxxxxx bere na vědomí, že pro objednatele je nezbytné, aby veškeré dodané technické a programové prostředky dle této smlouvy splňovaly veškeré závazné požadavky objednatele uvedené v příloze č. 5 smlouvy. Objednatel je oprávněn odstoupit od smlouvy z důvodu nesplnění (byť částečného) kteréhokoli ze závazných požadavků objednatele uvedených v příloze 5 smlouvy.

2. Objednatel je oprávněn odstoupit od smlouvy rovněž v případě, že:

a) zhotovitel bude v prodlení s předáním kteréhokoliv dílčího plnění ve lhůtě dle čl. I odst. 2 písm. a) nebo b) nebo se zahájením poskytování podpory po dobu delší než 30 dnů od podpisu protokolu o převzetí 1. dílčího plnění dle čl. II odst. 7,

b) v rámci zkušebního provozu dle čl. I odst. 2 písm. b) se vyskytnou takové chyby, které objednatel vyhodnotí jako zásadní a tyto nebudou odstraněny ani v objednatelem určené dodatečné přiměřené lhůtě,

c) po uplynutí testovacího či zkušebního provozu bude zjištěno, že technické či programové prostředky neodpovídají specifikaci dle přílohy č. 1, dílo nesplňuje veškeré závazné požadavky objednatele dle přílohy č. 5 smlouvy či není realizováno v souladu s přílohou č. 7 smlouvy,

d) zhotovitel neodstraní kritickou závadu dle čl. V odst. 2 písm. b) ani do 48 hodin od

nahlášení,

e) zhotovitel neodstraní nekritickou závadu v souladu s čl. V odst. 2 písm. c) technických prostředků ani do 14 dní od nahlášení,

f) zhotovitel nezahájí práce na odstraňování nekritické závady programových prostředků v souladu s čl. V odst. 2 písm. d) ani do 5 pracovních dní od nahlášení, nebo pokud ani přes výzvu objednatele nebude zhotovitel pokračovat v pracích na odstraňování vady po jejich přerušení,

g) zjištění jakéhokoliv rozporu mezi licencemi uvedenými v příloze č. 1 smlouvy a licencemi skutečně dodanými. Jedná se zejména o rozpory ve způsobu licencování nebo v jejich množství.

3. Zhotovitel je oprávněn odstoupit od smlouvy v případě, že objednatel bude v prodlení

s úhradou oprávněně vystaveného daňového dokladu delším než 30 dnů.

4. Odstoupení od smlouvy je účinné dnem doručení oznámení o odstoupení od smlouvy druhé smluvní straně. Odstoupením od smlouvy se smlouva ruší od samého počátku a smluvní strany si vzájemně vypořádají již poskytnutá plnění. Odstoupením od smlouvy nezaniká nárok objednatele na smluvní pokuty dle čl. VI, ani nárok na náhradu škody.

5. Zhotovitel je povinen do 30 dnů od účinnosti odstoupení odvézt veškeré dodané plnění,

nestanoví-li objednatel jinak, či nedomluví-li se smluvní strany jinak.

6. Pro účely náhrady škody v případě odstoupení od smlouvy se stanovuje cena práce každého ze zástupců zhotovitele na plnění této smlouvy ve výši maximálně 1 300 Kč/hod bez DPH.

Článek X

Uveřejnění smlouvy a skutečně uhrazené ceny za plnění smlouvy

1. Xxxxxxxxxx si je vědom zákonné povinnosti objednatele uveřejnit na svém profilu tuto smlouvu včetně všech jejích případných změn a dodatků a výši skutečně uhrazené ceny za plnění této smlouvy.

2. Profilem objednatele je elektronický nástroj, prostřednictvím kterého objednatel, jako veřejný zadavatel dle zákona č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů (dále jen „ZZVZ“) uveřejňuje informace a dokumenty ke svým veřejným zakázkám způsobem, který umožňuje neomezený a přímý dálkový přístup, přičemž profilem objednatele v době uzavření této smlouvy je xxxxx://xxxx.xxx.xx/.

3. Povinnost uveřejňování dle tohoto článku je objednateli uložena § 219 ZZVZ.

4. Uveřejňování bude prováděno dle ZZVZ a příslušného prováděcího předpisu k ZZVZ.

Článek XI Závěrečná ustanovení

1. Smlouva nabývá platnosti a účinnosti dnem podpisu oprávněnými zástupci obou smluvních stran.

2. Smlouva se v části týkající se podpory uzavírá na dobu neurčitou. Smlouvu lze v části týkající se podpory vypovědět písemnou výpovědí, která musí být doručena druhé smluvní straně nejpozději 6 měsíců přede dnem uplynutí předplacené doby podpory technických prostředků a programových prostředků, které jsou nedílnou součástí technických prostředků s tím, že závazky týkající se poskytování podpory zanikají uplynutím posledního dne předplacené doby podpory.

3. Smluvní strany se dohodly, že objednatel je oprávněn kdykoliv v průběhu insolvenčního řízení zahájeného na majetek zhotovitele vypovědět tuto smlouvu v části týkající se podpory, a to ve 14denní výpovědní době, která počíná běžet dnem následujícím po doručení písemné výpovědi zhotoviteli. Zhotovitel je povinen vystavit nejpozději poslední den trvání smlouvy opravný daňový doklad na vrácení alikvotní části předplacené podpory, nebude-li tato čerpána u výrobce, či jím pověřené společnosti (osoby).

4. Smluvní strany se dohodly, že případný spor, který vznikne z této smlouvy nebo v souvislosti s ní bude rozhodován výlučně podle českého práva obecnými soudy v České republice.

5. Tato smlouva a práva a povinnosti z ní vzniklá se řídí občanským zákoníkem a autorským zákonem.

6. Smlouva může být měněna a doplňována pouze formou písemných chronologicky číslovaných dodatků podepsaných oprávněnými zástupci obou smluvních stran, není-li touto smlouvou stanoveno jinak.

7. Smlouva je vyhotovena v elektronické podobě, přičemž každá ze smluvních stran obdrží vyhotovení smlouvy opatřené elektronickými podpisy

Přílohy:

č. 1 – Specifikace technických a programových prostředků č. 2 – Specifikace činností

č. 3 – Kontakty pro poskytování podpory, konzultací a řešení problémů při implementaci č. 4 – Seznam zařízení objednatele

č. 5 – Technická specifikace předmětu plnění č. 6 – Bezpečnostní požadavky objednatele č. 7 – Návrh technického řešení

č. 8 – Cenová tabulka

V Praze

16. 2. 2022

V Brně

11. 2. 2022

za objednatele: za zhotovitele:

Česká národní banka 0X.xx, s.r.o.

Xxx. Xxxxx Xxxxxxx Xxx. Xxxx Xxxxxx

ředitel sekce informatiky prokurista

podepsáno elektronicky podepsáno elektronicky

Xxx. Xxxxxx Xxxxxx ředitel sekce správní podepsáno elektronicky

Evidenční číslo smlouvy ČNB: 00-000-00

Příloha č. 1

Specifikace technických a programových prostředků

Specifikace technických prostředků a programových prostředků, které jsou nedílnou součástí technických prostředků

Název	Rozlišení: HW *)	Množství (u HW počet ks, u SW počet licenčních jednotek)
Diskové pole VSP G370 - HW	Diskové pole VSP G370 Cache 256 GB VSP GXX0 2.4TB SAS HDD VSP G/F XX0 Drive Box (SFF) VSP G/FXX0 Host I/O Module FC 16/32G 4port VSP G SFP for 16Gbps Shortwave POWER CORD IEC C14 TO IEC C13 250VAC 10A WORLDWIDE APPROVALS 1.5M SVP processor Příslušenství pro realizaci zakázky v požadovaném rozsahu	2x 1ks 2x 1ks 2x 138ks 2x 5ks 2x 2ks 2x 16ks 2x 12ks 1ks 1ks
Diskové pole VSP G370 – nedílný SW	VSP G370 Foundation Base Package G370 Global Active Device Base License Hitachi VMware Software No-Charge Sales package Hitachi Microsoft Software No-Charge Sales package	2x 1ks 2x 1ks 2x 1ks 2x 1ks
Stojan pro lokalitu Zličín (standardní 19“ stojan s nosností minimálně 1000 kg, šíře 800 mm, hloubka 900-1200 mm, výška 30-42 U	Rozvaděč stojanový serverový 42U 800x1200 - černý	1

Specifikace programových prostředků

Název	Rozlišení HW/SW *)	Množství (u HW počet ks, u SW počet licenčních jednotek)
Dodávka neobsahuje programové prostředky, které nejsou nedílnou součástí technických prostředků

*) U položek technických prostředků uveďte „HW“ u programových prostředků uveďte „SW“. U položek programových prostředků uveďte typ (jednotky) licencování např. „kapacita-TB“, „na storage“, „na server“, „na počet připojených zařízení“, „na CPU“, „na uživatele“ apod. Lze doplnit i textem pod tabulkou.

12

Příloha č. 2

Specifikace činností

Detailní specifikace požadovaných činností zhotovitele

Činnost	Poznámka
Instalace HW/SW	Instalace diskových polí a základní konfigurace, instalace dohledového SW, zaškolení obsluhy.
Zapojení do datových struktur ČNB a testovací provoz	Zapojení do SAN, zprovoznění vzdáleného zrcadlení a “zrcadleného disku“, připojení nejméně 2 serverů, instalace management SW
Konfigurace polí	Asistence při konfiguraci jednotlivých disků pro servery rozsahu do 10 LUNů.
Instalace SW	Zajištění instalace veškerého dodaného SW na všech serverech. Instalace SW pro ovládání pole z příkazové řádky na všech serverech. V případě potřeby zhotovitel zajistí i odinstalování stávajícího SW.
Asistence při testování	Spolupráce při testovacím a zkušebním provozu.
Školení	Před implementací zajistí zhotovitel školení pro 6 odborných zaměstnanců ČNB v rozsahu nezbytném pro zajištění provozu dodaných prostředků v ČNB (konfigurace, administrace, běžná správa). Školení je požadováno v ČR, nejlépe v Praze. Školícím jazykem může být čeština a angličtina. Preferován je český jazyk.
Dokumentace	- vedení deníku o instalaci, tj. průběžné zaznamenávání provedených změn v celém průběhu implementace *; - zajišťování zápisů z jednání a protokolů o předání funkčních celků; - zpracování realizační dokumentace (skutečný stav zapojení, nastavení systému, postupů při provozu, nastavení vzdáleného přístupu,…); - zpracování havarijního plánu**; - zpracování protokolu o provedeném školení zaměstnanců objednatele;
Další povinné součásti dodávky	optická kabeláž mezi dodanými zařízeními a prvním prvkem, do kterého budou zapojena (FC switch, maximální délka 25 m);

* Instalační deník by měl být veden formou notesu/knihy, kde se průběžně (pokud možno okamžitě) zaznamenávají provedené akce a nastavení.

** Havarijní plán bude obsahovat všechny nezbytné informace pro zaměstnance objednatele, jak mají postupovat v případě závady, tj. informace:

- o umístění nezbytných záznamů (logů) vedoucí k bližší identifikaci závady a základní informace o tom, jak logy analyzovat (případně informaci, že konkrétní log je určen pro analýzu ve vyšších stupních podpory a jak se tento log dá uložit do souboru, aby mohl být odeslán např. e-mailem)

- o postupech při typických závadách a chybových hlášeních a popis postupu/ů jak blíže identifikovat závadu. V této části by měl být uveden popis typických závad, které mohou nastat a mohou být odstraněny zaměstnanci objednatele (např. při výpadku

„portu xy“ -> je potřeba uvést port do stavu on-line příkazem „abcd“; nefunguje

komunikace mezi serverem a diskovým polem po jedné z FC tras-> je potřeba ověřit zda je příslušný port diskového pole a serveru zalogován do SAN a následně provést akci „xyz“; atd.). Rozsah těchto typických závad bude záviset na složitosti navrženého řešení. Mezi typické „závady“ je považován i postup při vypínání a zapínání systému jak po předchozím korektním vypnutí, tak i po neočekávaném vypnutí,

- o postupech při atypických závadách (např. informaci o tom, že se má kontaktovat servisní podpora),

- o postupu při havárii lokality, tj. zejména postup jak zprovoznit systémy na druhém zrcadleném systému.

Kontakty pro poskytování podpory, konzultací a řešení problémů při implementaci Kontaktní osoby objednatele:

Kontaktní osoby/centrum zhotovitele:

• pro poskytování konzultací nebo pro řešení problémů při implementaci:

• pro poskytování podpory technických i programových prostředků:

• způsob předávání požadavků objednatelem:

Telefonické kontakty musí být telefonní čísla v rámci ČR nebo musí být volání objednatele

v režimu volání na účet volaného.

Případná změna v osobách či údajích, či způsobu předávání požadavků objednatelem dle této přílohy bude zaslána bezodkladně e-mailem pověřeným osobám druhé smluvní strany dle čl. IV odst. 2, bez potřeby uzavření dodatku.

Seznam typových zařízení objednatele

Pozn: pokud některý z uvedených operačních systémů již není podporován výrobcem tohoto OS, předpokládá se automaticky použití následovníka.

Hardware*)	FC HBA	cluster SW*)
DWDM CISCO ONS 15 454	vzdálenost cca 25 km
CISCO MDS-9396T	Kombinace 16 a 32 Gbit/s
HPE ProLiant DL380 Gen10	HPE SN1200E 16Gb Dual Port Fibre Channel Host Bus Adapter	Microsoft Cluster Server / Windows 2016 a 2019

*) pro správnou funkci clusterů („stěhování“ IP adres clusterových skupin) jsou lokality propojeny protokolem TCP/IP na úrovni L2 z hlediska rozhraní Ethernet.

Příloha č. 5

Technická specifikace předmětu plnění

Terminologie

Cache – vyrovnávací paměť zařazená mezi dvěma systémy vyrovnávající jejich rozdílnou rychlost. V případě diskového pole je cache umístěna na cestě mezi (frontend) portem a fyzickým diskem diskového pole. Z pohledu ČNB se jedná o paměť na bázi RAM (např. xxxxx://xx.xxxxxxxxx.xxx/xxxx/XXX) s přístupovou dobou v řádu desítek nanosekund nikoliv o tierování na bázi Flash/SSD technologií.

Cluster lokální - skupina zařízení (zpravidla serverů a diskových polí), která umožňuje zajistit obnovu zpracování v řádu jednotek minut po výpadku některé z komponent. Vzájemná vzdálenost zařízení od sebe může být do desítek metrů.

Cluster geografický/geocluster - obdoba lokálního clusteru s tím rozdílem, že i data jsou zdvojená a tato technologie umožňuje kompletní obnovu zpracování ve fyzicky jiné lokalitě (vzdálenost desítky kilometrů). V různých lokalitách jsou nejen servery a i diskové prostory.

Clone/klon, Snapshot – jedná se o různé způsoby autonomního vytvoření nezávislých kopií dat (disků). V případě „clone“ je vždy vytvořena plná kopie dat uvnitř diskového pole. Pro tento způsob vytváření kopií musí být vždy k dispozici plná kapacita. V případě „snapshotu“ se vytváří jen vnitřní tabulka. Až v případě zápisu konkrétní stopy na disk je vytvářena příslušná kopie „starších“ dat. Výhodou je, že po určitý čas (než dojde k přepsání celého prostoru disku) není potřeba celá kapacita, ale jen kapacita na udržení změn. Nevýhodou je zpravidla poměrně značná režie spojená s „evidencí“ a realizací změn.

High Availability – řešení, které zajišťuje dohodnutou spolehlivost zpracování nebo systémů. V tomto řešení je typicky zajištěno, že při výpadku jedné (nebo i více komponent) není zpracování narušeno.

IOPS (Input/Output Operations Per Second) – počet I/O operací za sekundu.

IS (Informační systém/aplikace) - je funkční celek, který slouží k získávání, uchovávání, přenášení, zpracovávání a poskytování informací pomocí informačních technologií. Zahrnuje informační technologie, data, správu informačního systému a zaměstnance, kteří ji zajišťují, uživatele a vzájemné vazby mezi nimi.

Fyzický disk – disková jednotka, která je fyzicky výměnná v rámci diskového pole (označováno též jako HDD).

Logický disk – část fyzického disku nebo více částí fyzických disků, která je vytvořena konfiguračními prostředky diskového pole.

LUN – jeden nebo skupina logických disků, které jsou prezentovány směrem k serveru a z pohledu serveru se tváří jako jeden disk.

LUN Masking - proces zajišťující, aby určitý disk (LUN) byl přístupný určitému serveru, tj. aby všechny servery neměly přístupné všechny disky připojené do SAN, resp. na stejný port

diskového pole. Lze řešit na úrovni diskového zařízení, HBA (Host Bus Adapter) serveru

nebo FC switche.

MSCS (Microsoft Cluster Service) – SW dodávaný firmou Microsoft zajišťující funkci clusteru. Tento SW je součástí MS Windows Enterprise Edition.

MP (MultiPath) – technologie, kdy je mezi počítačovým systémem (server) a úložným zařízením více cest, které jsou všechny využívány. Technologie tak umožňuje zvýšit spolehlivost (odolnost proti výpadku cest/y) a výkonnost (zvýšení kapacity spojení). Technologie je „obsluhována“ vrstvou operačního systému a pro uživatelskou aplikaci je zcela transparentní.

RHEL (Red Hat Enterprise Linux) – zkratka pro operační systém typu Linux vyvinutý

firmou RedHat.

Synchronní/Asynchronní přenos - pojmem synchronní přenos je označován typ přenosu, kdy odesilateli je doručeno potvrzení o zpracování jeho požadavku až v okamžiku dokončení zpracování (tím vzniká časové zpoždění). Naproti tomu asynchronní přenos považuje operaci za ukončenou v okamžiku ukončení odeslání požadavku bez ohledu na to, zda operace je již dokončena a bez ohledu na to, zda byla ukončena korektně.

ZP – záložní pracoviště ČNB v Praze - Zličín.

Zrcadlení lokální/lokální zrcadlení – je technologie zajišťující zápis dat na 2 nebo více disků současně, které jsou umístěny v jednom systému (diskovém poli). Zpravidla bývá označováno jako RAID-1 nebo mirroring.

Zrcadlení vzdálené/vzdálené zrcadlení - je technologie zajišťující zápis dat do více diskových polí souběžně s tím, že nejméně jedno z těchto diskových polí umístěno v jiném objektu (vzdálenost v kilometrech). Rozlišujeme synchronní a asynchronní zrcadlení. V rámci této technologie obvykle bývá jedna z kopií dat určena pro čtení i zápis a druhá kopie je v normálním stavu nepřístupná (obvykle pro zápis). Teprve po provedení konfiguračních/řídících operací je tato kopie zpřístupněna (typicky pro čtení i zápis).

Zrcadlený disk – kombinace lokálního a vzdáleného zrcadlení, kdy server „vidí“ disk ze dvou různých diskových polí jako disk z jednoho pole a je tedy možné na něj aplikovat multipath. Zrcadlení dat je pak prováděno na úrovni diskových polí.

Pojmy poplatné technologii Hitachi Data Systems a IBM, která je v současnosti používána

v ČNB:

TrueCopy/RemoteCopy – vzdálené zrcadlení disků mezi diskovými poli.

HDLM (Hitachi Dynamic Link Manager)/Mutlipath - SW pro multipath

In-systém repliaction/Copy on Write/Flashpshot – technologie Hitachi pro realizaci clone a

snapshotů.

Popis současného stavu a infrastruktury ČNB

Obecné informace

V ČNB jsou v provozu dvě výpočetní střediska. Obě tato střediska jsou provozována systémem aktiv-aktiv, tj. v obou střediscích jsou zpracovávány různé informační systémy. Běžný uživatel není schopen rozlišit, ve kterém středisku je jeho požadavek zpracován. V případě potřeby (havárie, údržba,….) je zpracování konkrétního informačního systému přesunuto na jiný uzel.

Do prostředí (geografických) clusterů jsou umísťovány IS přímo podporující jednu nebo více kritických činností ČNB. Jiné IS se do tohoto prostředí umisťují jen výjimečně (např. z licenčních důvodů, striktního požadavku na shodnost akceptačního a provozního prostředí apod.).

V případě havárie je výpadek ve zpracování (doba mezi zastavením IS a jeho nastartováním na jiném serveru) v délce do 5 minut pro ČNB akceptovatelný. V případě plánované údržby je nutné konkrétní dobu přesunu zpracování individuálně dohodnout se správcem příslušného IS (liší se dle IS, zpravidla na počátku nebo konci pracovní doby).

Komunikační infrastruktura/SAN

Jedno výpočetní středisko je umístěno v budově ústředí v Praze 1 a druhé v Praze 5 – Zličín (dále jen ZP). Obě střediska jsou plnohodnotně vybavena jak po stránce komunikační (LAN, SAN), tak i po stránce zpracování a uložení dat (servery, disková pole, magnetopáskové knihovny). Z kapacitního hlediska převažuje (počty serverů, objemy dat) objekt ústředí, ve kterém jsou také umístěny systémy nevyžadující zdvojení (méně významné IS, systémy pro testování a vývoj apod.).

Obě výpočetní střediska jsou propojena optickými vlákny (single mode) dvěma nezávislými trasami. Jedna z tras je dlouhá 22,0 km, druhá trasa je dlouhá 24,4 km. Obě trasy jsou rovnocenné z hlediska přenášených protokolů (TCP/IP, FC) a přibližně i objemu přenášených dat. Na obou koncích jsou umístěny multiplexory DWDM (specifikace viz příloha č. 4 smlouvy).

Obecné schéma zapojení SAN je v následujícím obrázku:

Všechny prvky SAN (FC switche) jsou ve shodné HW a SW konfiguraci (viz příloha č. 4 smlouvy). Jsou vytvořeny dva vzájemně oddělené fabricy, každý z nich je tvořen dvěma

FC switchi umístěnými v jiné lokalitě (v obrázku jsou prvky fabricu propojeny vždy stejným typem čáry). Každý z fabriců využívá obě optické komunikační trasy mezi objekty.

Páteřní optické rozvody v rámci objektu ústředí jsou 62,5 um, v objektu ZP Zličín jsou

50 um (typ vlákna OM3). Multimode páteřní optická kabeláž je zpravidla zakončena konektory typu SC na patch panelech v objektu ústředí. Ostatní kabeláž je zakončena konektory typu LC (patch panely v objektu ZP Zličín, prvky SAN v obou objektech).

Prostředí HighAvailability (HA)

V ČNB je několik typů prostředí HA. V zásadě jej lze rozdělit na prostředí, kde je HA podporováno na úrovni celých virtuálních strojů a na prostředí na úrovni jednotlivých aplikací uvnitř serveru (virtuálního nebo fyzického). Obě tyto úrovně mají různý stupeň automatizace.

V současné době jsou v ČNB provozovány dvě virtualizační platformy – VMware a Oracle VM. U obou platforem jsou využívány funkcionality typu FailOver (přesun celého virtuálního stroje (VM) při havárii hypervizoru) a u VMware je využíváno SRM (VMware Site Recovery Manager).

V prostředí operačního systému Windows je provozován Microsoft Cluster Server

(MSCS) s využitím funkcionality Hitachi Global Active Device.

V prostředí Oracel VM je používáno pouze aplikační zabezpečení. V případě havárie je administrátorským postupem (script) zajištěn přesun aplikace do druhé lokality (zastavení aplikace, zrušení IP adresy, odmontování disků, otočení zrcadlení, příprava disků a IP adresy, start aplikace).

Prostředí výpočetních středisek

Obě výpočetní střediska jsou vybavena:

- zdvojenou podlahou;

- redundantním systémem udržování provozního prostředí (teplota, vlhkost);

- napájením prostřednictvím redundantních UPS (zdvojené přívody do prostor výpočetních středisek, přepěťové ochrany, z rozvaděčů ke spotřebičům rozvod 230V). Do rozvaděčů jsou přívody 400V, ale pro připojení zařízení s 3fázovým vstupem by byla nutná úprava rozvaděče;

- požární signalizací;

- samozhášecím systémem na bázi inertního plynu;

- detekcí úniku kapalin ve zdvojené podlaze;

- zabezpečením proti neoprávněnému vstupu.

Ostatní informace o výpočetních střediscích:

- zdvojená podlaha v objektu ústředí a v objektu ZP;

- vstup do obou výpočetních středisek má maximální výšku 197 cm;

- transportní trasy do výpočetních středisek v ústředí i ZP mají omezení s ohledem na nosnost v transportní trase nebo rozměry transportní trasy. V objektu ústředí je transport možný až po 18. hod.

- v objektu ústředí je k dispozici 1 standardní počítačový stojan 42U šíře 80 cm. Je zde

vytvořen systém tzv. „teplé uličky“

- v objektu ZP je k dispozici pouze prostor 20U v rámci jednoho stojanu.

- Pro účely managementu bude k dispozici jeden fyzický server (32 GB RAM, 8x CPU,

200 GB disky).

- Případně je možné využít stávající instalaci STOR2RRD verze 7. V tomto případě však musí být řádně placena podpora odpovídající dodanému rozšíření o další pole (firma XORUX).

Standardy ČNB

Standardní komunikační vybavení:

• Páteřní LAN – Gigabit Ethernet;

• aktivní síťové prvky – platforma CISCO, plně přepínaná síť;

• Protokol TCP/IP;

Páteřní síťové služby:

• DNS

o primární DNS pro domény xxx.xx, xxxxxxx.xxx.xx – provozováno v prostředí HP- UX nebo GNU Linux;

o primární DNS pro doménu xx.xxx.xx - provozováno v prostředí MS Windows;

• DHCP (v doméně xx.xxx.xx)

o provozováno na platformě MS Windows 2008 Serveru (ústředí i pobočky);

• MTA

o provozováno na HP-UX, sendmail;

• Přesný čas – NTP

Jako zdroj přesného času je použit SNTP (Simple Network Time Protocol) server. Server je synchronizován externím časovým signálem s GPS (Global Positioning System). Protokolem NTP (Network Time Protocol) se pak synchronizují další síťová zařízení. Struktura synchronizace je hierarchická.

Závazné požadavky objednatele

V následující tabulce jsou uvedeny požadavky, které musí být zhotovitelem splněny. U jednoho „požadavku“ (=řádku tabulky) může být současně i několik požadovaných vlastností (viz např. požadavek „spolehlivost“), které musí být splněny všechny.

Použité výrazy jsou poplatné obecné terminologii a nejrozšířenějším technologiím. V některých místech se však mohou lišit od technologie nabízené zhotovitelem (vše není možné popsat zcela obecně). V tom případě musí zhotovitel jasně vysvětlit vzájemný vztah nabídnutého řešení a požadavku objednatele a zdůvodnit způsob splnění požadavku. Rozhodující je splnění příslušné funkce nebo vlastnosti po její funkční/výkonové stránce nikoliv způsob jakým je výsledku dosaženo.

Požadavek	Popis
Dostupnost	Pro potřeby ČNB je důležitá spolehlivost a bezvýpadkovost systému nejen jako celku, ale i jednotlivých komponent; zařízení jako celek musí být konstruováno pro provoz 24x7.
Spolehlivost	Je vyžadováno: - zajištění dostupnosti dat na úrovni operačního systému serveru alespoň v jedné lokalitě do 24 hodin. V tomto případě není rozhodující, zda se jedná o chybu HW nebo SW; - výměna libovolné jedné vadné komponenty za provozu (bez

přerušení přístupu k datům, výkonnost může být částečně snížena);

- upgrade všech komponent diskového pole za provozu (je povoleno

snížení výkonnosti nejvýše o 50 %);

- upgrade FW/mikrokódu na všech komponentách bez narušení přístupu k datům a bez výpadku jakékoliv funkcionality diskového pole (výkonnost může být snížena nejvýše o 50 %) tj.

o po celou dobu provádění upgrade musí být zachovány všechny funkcionality (jako je např. snapshot, clone, vzdálené zrcadlení, zrcadlený disk atd.) v plném rozsahu činnosti a to v obou lokalitách (na obou diskových polích). V případě zrcadlených funkcí (vzdálené zrcadlení, vzdálený disk) musí být navíc data dostupná pro servery z obou diskových polí v libovolném okamžiku;

- pole nesmí mít SPOF (Single Point of Failure);

- konfigurační změny online (viz dále);

- minimálně 1 rezervní (spare) disk/kapacita v každém diskovém poli podle pokynů výrobce, minimálně musí být pro každý provozní typ disku dostupný alespoň 1 spare disk, který jej může nahradit;

- zajištění funkce kontroly uložených dat, tj. diskové pole musí v době nižší aktivity autonomně provádět kontrolu čitelnosti uložených dat;

- zajištění podpory výrobce zařízení tak, aby v případě vážné chyby mohl být výrobcem vytvořen fix pro tuto vážnou chybu, která se vyskytla v ČNB;

- zajištění výměny potencionálně vadných komponent při překročení limitního počtu opravitelných i neopravitelných chyb stanovených výrobcem zařízení v rámci záruky/pozáruční podpory (v některých případech se tak bude dít ještě před vyřazením příslušné komponenty z provozu). Tento požadavek se samozřejmě týká i případných SSD/flash komponent a limitního počtu odstavených paměťových bloků.

- žádná z dodaných komponent nesmí být limitována počtem provedených operací (např. počet zápisů) z hlediska poskytování podpory, tj. zhotovitel po dobu trvání smlouvy opravuje/vyměňuje komponenty bez omezení;

- dodávané technické i programové prostředky musí být vyráběny sériově, nesmí být vyvíjeny pro potřeby této konkrétní zakázky. Dodaná verze FW/mikrokódu v době instalace musí být stabilní provozní verze instalovaná ve světě nejméně u 50 zákazníků v jejich produkčním prostředí.

Vysoká spolehlivost provozu je součástí zajištění dostupnosti dat. Případné odstávky při výměně vadných komponent, upgrade FW/mikrokódu nebo konfigurační změny mající dopad na provoz systému jsou v ČNB organizačně náročné a znamenají významné náklady na pracnost zaměstnanců ČNB. I pouhé riziko výpadku je v ČNB potřeba ošetřit minimálně organizačně a činnosti přesouvat na mimopracovní dobu.

Zajištění bezchybného uložení dat je pro ČNB jedním z prioritních požadavků.

	Požadavek na zajištění dostupnosti dat do 24 hod je možné u SW problémů řešit i např. dočasným odinstalováním některé SW komponenty (např. vzdálené zrcadlení, snapshot apod.) ovšem za předpokladu, že budou data stále někde dostupná. Zhotovitel musí na základě svých kontraktů s výrobce/distributorem zajistit takovou úroveň podpory, aby bylo možné problém/závadu eskalovat k výrobci (případně pověřené společnosti/osobě), kde se tímto problémem budou seriózně zabývat. Výsledné stanovisko samozřejmě může být závislé na konkrétní situaci (bude/nebude vytvořen fix, bude implementováno do nové verze FW apod.). S ohledem na význam diskových polí není naprosto přípustné, aby zhotovitel prováděl jakékoliv ladění FW/mikrokódu nebo jiného dodaného SW v prostředí ČNB.
Vzdálené zrcadlení – zrcadlený disk (synchronní)	Diskové pole musí být schopno zajistit synchronní zrcadlení dat mezi dvěma různými lokalitami (vzdálenost cca 25 km). Zaslání potvrzení serveru smí nastat až po korektním zápisu dat do obou míst (synchronní režim). Technologie vzdáleného zrcadlení musí být transparentní a nesmí vyžadovat zásah do IS. Je vyžadována možnost uživatelského (CLI) otočení směru zrcadlení (určení primárního a sekundárního zrcadla, pokud v tomto smyslu existují). Otočení zrcadlení musí být dynamické bez potřeby plné synchronizace a bez nutnosti zrušení a znovu vytvoření zrcadleného páru. Zrcadlení musí probíhat vzájemně mezi oběma lokalitami – obě lokality jsou v režimu active/active. Stanovení směru zrcadlení (tj. stanovení, který z disků (LUNů) je primární a který sekundární) musí být možné provádět na uživatelské úrovni (bez nutnosti oprávnění na změnu konfigurace pole).
	Po dobu, kdy probíhá vzdálené zrcadlení, je nezbytné, aby vzdálená zrcadla (LUNy vzdáleného diskového pole) byla stále „viditelná“ příslušným záložním serverem. Tato funkce je nezbytná z důvodu realizace clusteru na platformě RHEL, kdy nelze provádět dynamický scan sběrnice, ale je nutný reboot serveru.
	Je požadována funkcionalita, kdy se jednotlivé LUNy shodné velikosti ze dvou diskových polí umístěných ve dvou vzdálených lokalitách (vzdálenost cca 25 km) budou serverům prezentovat jako LUN z jednoho pole. Dva servery ve standardním clusteru (např. MSCS) se tedy budou chovat jako běžný lokální cluster, který sdílí tento zrcadlený disk. Obdobně VMware, resp. Oracle VM budou pracovat nad jedním repository, které je trvale přístupné pro zápis. Takový LUN není nutné (s odstávkou aplikace) přepínat z režimu ReadOnly do režimu ReadWrite. Zrcadlení LUNů mezi jednotlivými poli musí být v synchronním režimu. Při výpadku jednoho pole/loklaity tedy bude docházet ke standardnímu recovery na úrovni operačního systému, ale nebudou ztracena žádná uložená data. V zásadě vznikne virtuální cluster.
	Z důvodu zajištění majority (pro případ Disaster Recovery) objednatel předpokládá umístění dalšího arbitračního uzlu v budově ČNB. Uzel bude umístěn ve stejné budově, bude však umístěn v jiné místnosti než bude umístěno diskové pole. Dostupnost po TCP/IP je možná, pro

FibreChannel je potřeba počítat s délkou optické kabeláže přibližně 200 m (optická kabeláž 62,5um; komunikace 4 Gbit/s je funkční, 8 Gbit/s má již problémy).

Arbitrační uzel musí být součástí dodávky, ČNB poskytne pouze připojení do LAN nebo SAN, prostor ve stojanu (max. 4U), napájení a připojení ke KVM. V případě technologie GAD je možné využít stávající server, pokud je to technologicky a výkonnostně možné.

Pokud je tato funkcionalita licencována na TB, je licence požadována po celkovou dodávanou kapacitu.

S využitím této technologie se disková pole z obou lokalit budou prezentovat jako jedno pole a bude možné na ně aplikovat standardní

„lokální“ clustery včetně technologií jak „live migration“ (VMware)

apod.

Technologie tak umožní vyklizení výpočetního střediska bez nutnosti masivních odstávek IS.

Technologie vzdáleného zrcadlení nesmí vyžadovat zásadní změny v komunikační infrastruktuře ČNB (viz popis současného stavu, viz poznámka vpravo).

Z důvodu výkonnosti a maximální platformní nezávislosti nesmí být

na úrovni operačního systému připojených serverů.

Dodaný systém musí umožnit vytvoření minimálně 300 párů vzdáleně zrcadlených LUNů, které budou v provozu současně. Z hlediska objemu a licencování je pro vzdálené zrcadlení požadována plná kapacita pole, i když poměr zrcadlených a nezrcadlených dat bude kolísat. Viz také požadavek „Celková kapacita“.

Je požadováno vytvoření minimálně 30 „konzistentních skupin disků“, tj. skupin vzdáleně zrcadlených LUNů, které budou obsahovat více než 1 disk a manipulace se „zrcadlem“ na nich musí proběhnout na všech společně (současně) z důvodu zachování konzistence dat. Ostatní vzdáleně zrcadlené disky mohou být samostatně.

Výkonnostní dopad na realizaci vzdáleného zrcadlení nesmí být větší než 30 %, tj. požadavky na zápis dat včetně vzdáleného zrcadlení mohou být zpomaleny nejvýše o 30 % oproti požadavkům na zápis bez vzdáleného zrcadlení (viz také požadavek „Výkonnost“).

Po případném přerušení vzdáleného zrcadlení (ať již havárií nebo operátorsky přerušením zrcadlení jednoho nebo více LUNů) musí proběhnout pouze „rozdílové“ dorovnání stavu. Není tedy přípustná plná synchronizace všech dat.

V současné době je „Update Copy Response“ v průměru 2 ms (celkový čas pro zápis do primárního systému včetně přenosu dat a potvrzení zápisu druhým systémem). Převážná většina požadavků je vyřízena do 1 ms. Občas se objevují výkyvy do 4 ms. Zcela výjimečně je překročena

	hodnota 6 ms. Nový systém nesmí být pomalejší než současný stav. Vzdáleně zrcadlené disky (=vzdálené kopie) musí být trvale dostupné (=viditelné) záložními servery. Zda budou ve stavu ReadOnly nebo ReadWrite není rozhodující. Je požadováno synchronní zrcadlené, protože provozované informační systémy nejsou schopny se automaticky zotavit ze stavu, kdy přijdou o částa již zpracovaných dat.
Zabezpečení dat (disků)	Z důvodu zabezpečení dat je vyžadováno lokální zabezpečení dat. Typ RAID je na zhotoviteli. Důrazně však upozorňujeme na vysoký poměr zápisových operací – v poměru I/O tvoří zápisové operace cca 50 % aktivity (další podrobnosti v požadavku „Výkonnost“). Stejně tak zdůrazňujeme nutnost dodržení všech výkonnostních požadavků.
Ochrana investic	Požadované funkce diskového pole musí být aplikačně nezávislé (změna verze IS nesmí mít vliv na funkce poskytované diskovým polem). Všechny funkce poskytované diskovým polem musí být nezávislé na provozovaných informačních systémech. Pro všechny informační systémy musí být poskytované služby transparentní, tj. nesmí existovat vazba mezi informačními systémy a diskovým polem ve smyslu nutnosti certifikace výrobcem dodaného HW nebo SW (netýká se HW a OS serverů a clusterových komponent).
Celková kapacita	Celková kapacita pole/polí musí být: - celková kapacita pro data (v každé lokalitě): nejméně 250 TiB =prostor „viditelný“ servery. Nezahrnuje lokální zabezpečení. Tato kapacita v sobě zahrnuje požadavek na vzdálené zrcadlení (viz „vzdálené zrcadlení“). Celková kapacita je chápána tak, že po vytvoření 250 LUNů s velikostí 1 TiB a jejich přiřazení serverům bude možné na tyto LUNy celkově zapsat nejméně 225 TiB jedinečných dat (pozn: „jedinečná data“ jsou např. chápana jako náhodně generovaná data). Zbývající prostor cca 25 TB je považován za režii operačního systému, resp. filesystému (cca 10 %); Další informace též v požadavku „komprese a deduplikace“. V případě, že z navrženého řešení nebude zřejmé splnění požadavku na kapacitu, musí zhotovitel doložit výpočtem splnění tohoto parametru. V této souvislosti upozorňujeme na rozdíly MB a MiB a na to, že určitá kapacita je mj. spotřebována interní inicializací disků v poli. Pozn: 1 KiB=1024 byte, 1 MiB=1024 KiB, …
Připojení serverů	Připojení serverů je vyžadováno prostřednictvím SAN protokolem FibreChannel po celé komunikační trase mezi diskovým polem a serverem. Další informace v požadavku „Výkonnost“.

	V ČNB je již vybudovaná infrastruktura SAN, která je v současnosti využívána jak pro připojení serverů, tak i pro zajištění vzdáleného zrcadlení dat. Zásadní zvýšení požadavků na kapacitu jiných komunikačních kanálů (např. TCP/IP protokolem) by vyvolalo nutnost jejich posílení a není proto přípustné.
Diskový limit	Navržená technologie musí umožňovat vytvoření nejméně 700 LUNů v každém z diskových polí.
Výkonnost	Každé diskové pole v nabízené konfiguraci musí být schopno zpracovat dlouhodobě požadavky v rozsahu minimálně 30 000 IOPS a 2000 MB/s po dobu 24 hodin (při maximálně 50% cache hit a velikosti bloku 20 KiB a poměru zápis:čtení 50:50) na front-endu (připojení serverů). Další informace: - cca 60 - 70 % čtecích operací je random - cca 80 % zápisových operací je random Pozn: v denních hodinách je velikost bloku lehce pod 20 KiB, v nočních hodinách se velikost bloku zvětšuje až k průměrným cca 25-30 KiB. Do uvedených požadavků nejsou zahrnuty výkonové kapacity potřebné pro jakékoliv způsob zrcadlení (lokální/vzdálené) ani režie pro snapshot/clone, thin provisioning apod. Do uvedených požadavků není zahrnut ani provoz generovaný vzdáleným zrcadlení druhého pole. Response time u nejméně 90 % čtecích i zápisových operací musí být menší než 4 ms (velikost bloku 20 KiB), ve zbývajících 10 % nesmí responsetime překročit10 ms. Požadavky na propustnost každého pole na vnějším rozhraní (front-end): - všechny FC porty musí být s rychlostí 16 Gbit/s s možností provozu 8 Gbit/s (dnešní SAN má porty 8 Gbit/s); - Počet portů musí být minimálně 10 pro připojení serverů (5+5 do každého fabricu SAN). Případné požadavky na dedikované porty pro zrcadlení apod. nejsou v tomto počtu zahrnuty (detaily viz DMZ a KII); - maximálně bude poskytnuto 16 portů v SAN v každé lokalitě (8+8 z různých FC switchů); - Zařízení musí být rozšiřitelné minimálně o další 4 FC porty. Výkonnost bude měřena SW „IOMETER“ Provedení měření (testu) proběhne na více LUNech, kdy minimální hranice počtu LUNů není stanovena. V provozu musí být funkcionality mající vliv na výkon, tj. minimálně thin provisioning, vzdálené zrcadlení - zrcadlený disk pro všechny disky; pokud bude dodána deduplikace, tak musí být aktivována apod. Bude se měřit na dedikovaných fyzických serverech Win 2016. Virtuální servery nebudou používány. Pro test bude použita aktuální verze IOmeter. Měření (test) bude provedeno pro počet workerů větších než je počet LUNů, velikost bloku 20kiB, poměr čtení a zápisu 50:50, 70 % random/30 % sequential, doba jednoho testu bude nejméně 3 hodiny.

	Write IO Data Pattern bude minimálně na úrovni Pseudo Random. Parametr „Ramp Up Time“ bude v defaultní hodnotě, tedy 0. Test bude opakován vícekrát, avšak s rozestupem nejméně 24 hodin. Po dosažení dvou výsledků splňujících požadované parametry bude testování ukončeno. V případě nesplnění požadavků bude test opakován nejvýše 6x a pokud ani poté nebudou splněny požadované parametry, bude se mít za to, že dodané technické a programové prostředky nesplňují požadované požadavky/funkce objednatele a bude uplatněn příslušný postup v souladu se smlouvou.
Velikost a zabezpečení cache	Kapacita cache (na bázi RAM) pro data a řídící operace v každém diskovém poli musí být stejná nebo větší než je doporučení výrobce diskových polí pro konkrétní konfiguraci. Minimální velikost objednatel nespecifikuje, jelikož může být závislá na dalších navazujících technologiích. Disková cache musí být sdílitelná všemi host porty (připojenými servery) a všemi disky jak pro čtení, tak i pro zápis. Současně musí být interními algoritmy zajištěno dynamické přerozdělování cache v závislosti na aktuální zátěži jednotlivých portů, disků a v závislosti na aktuálním poměru Read a Write operací. Cache určená pro zápisové operace musí být zajištěna proti výpadku/chybě. Je požadováno zajištění cache tak, aby i při výpadku napájení trvajícím nejvýše 24 hodin nebyla ztracena data uložená v cache (např., baterie pro zálohování cache, vyprázdněním cache na disky včetně SSD technologií apod.). Prostředí v ČNB je poměrně dynamické zejména ve vztahu k zátěži generované jednotlivými IS. Zátěž jednotlivých IS se mění jak v průběhu dne, tak i v rámci měsíce. Každý IS má rozložení zátěže individuální. Těchto IS je více než 90. Proto je vyžadováno dynamické využití cache a nikoliv její statické přidělení jednotlivým host portům, serverům nebo diskům (LUNům, logickým nebo fyzickým diskům). Cache musí být dostatečně dimenzována, aby s postupující zátěží (např. s narůstajícím počtem a objemem disků se vzdáleným zrcadlením, snashoty apod.) nedocházelo k nedostatku cache pro ostatní operace (např. pro lokální zápis nebo běžné předčítání). Tento požadavek vyplývá z aktuálních zkušeností s provozem v ČNB.
Operace s LUNem	Zařízení musí umožnit zvětšení LUNu přiřazeného serveru bez ztráty uložených dat (operace bude prováděna bez aktivity serveru na tomto LUNu). Požadavek se týká operačních systémů Windows 2016 a vyšší a RedHat 7 a vyšší.
LUN masking	Je požadována funkce LUN maskingu, tj. zapojení více serverů na jeden port diskového pole, ale oddělení přístupu na jednotlivé disky (jednotlivé LUNy) pro jednotlivé servery. Tato funkce nesmí být přenesena na SAN ani na HBA. Důležitým požadavkem je, aby změna na portu (přidání/odebrání serveru

	na fyzickém portu nebo přidání/odebrání LUNu u konkrétního serveru) v žádném případě neovlivňovala provoz ostatních zařízení.
Duální FC připojení serverů (MultiPath)	Požadován je minimálně FailOver. Tento požadavek platí pro platformy: Windows 2016 a vyšší, Vmware 7.x a vyšší RedHat 7 a vyšší, RedHat 7 a vyšší. Ztráta některé z cest k diskovému poli nesmí mít dopad na činnost serveru s výjimkou snížení propustnosti, tj. nesmí dojít k činnosti serveru, která povede k jeho nefunkčnosti (např. přesun zpracování aplikací na jiný uzel geoclusteru). Součástí dodávky musí být i MultiPath software pro všechny servery dle tabulky v příloze č. 4 (týká se serverů/OS, kde multipath není integrální součástí OS, v tom případě je součástí dodávky postup/konfigurace nastavení). Ztrátou dostupnosti některé z cest k disku nesmí být ovlivněna řádná činnost operačního systému nebo jiných SW (např. clusterová vrstva). Maximální délka výpadku je specifická pro jednotlivé systémy/platformy.
Homogenita	Navržené řešení musí být homogenní, tzn., že ke všem komponentám musí být přistupováno rovnocenně. Tím je míněno, že veškeré komponenty stejného významu nebo funkce musí mít také stejná privilegia, omezení, stejné funkce a odpovídající výkonnost. Není proto přípustné, aby bylo možné např. mapovat disky z určité paritní (raid) skupiny jen na některé front-end porty, použít např. licence pro vzdálené zrcadlení/přesun LUNů/apod jen pro některé LUNy nebo paritní skupiny, atd. Veškerá požadovaná (datová) cache musí být dostupná pro všechny fyzické disky/raidgroupy, LUNy stejným způsobem. Tento požadavek se vztahuje přiměřeně i na disky, tj. disky stejné kategorie (SATA/SAS/SSD….) musí mít odpovídající použití. Pokud bude navržené řešení obsahovat z hlediska výkonnosti různé typy disků, musí být současní navrženého řešení i online přesouvání (tj. přesun bez dopadu na dostupnost dat na serverech a jen s minimálním odpadem na výkonnost) mezi těmito typy disků. Přesuny musí být automatické a s cyklem nejvýše 6 hodin. Diskový prostor musí být použitelný rovnocenně pro různé typy využití (lokální disk, vzdáleně zrcadlený disk, klony). V tomto případě je zejména míněno, že nesmí být vyhrazen samostatný prostor pro LUNy bez a pro LUNy včetně vzdáleného zrcadlení. Je vyžadováno jednotné řešení z hlediska zajištění správy navrženého řešení. Navržené řešení musí být symetrické (shodné) pro obě lokality.
Komprese a deduplikace	Komprese nebo deduplikace není vyžadována, ale není zakázána. Objednatel však limituje jejich případné použití následovně: - zhotovitel nese plnou zodpovědnost za stanovení deduplikačního poměru. Pokud se po celou dobu trvání smlouvy prokáže, že reálná kapacita diskového pole je menší než požadovaných 250

	TB, musí zhotovitel na své náklady kapacity doplnit - pro stanovení fyzické kapacity nesmí být použit výhodnější poměr než 1 : 1,5 - deduplikace/komprese musí probíhat přímo na řadiči diskového pole; - prohlášení o shodě vzorků je možné jen na základě přímého porovnání vzorků nebo po provedení nejméně 2 kontrolních součtů - případná režie těchto algoritmů je věcí zhotovitele a nesmí být zahrnuta v kapacitách požadovaných objednatelem (zejména snížení kapacity cache).
Bezpečnost	Auditování. Minimální rozsah auditování: • přihlášení a odhlášení administrátorů (uživatelů), • činnosti provedené administrátory, • činnosti vedoucí ke změně přístupových oprávnění, • neprovedení činností v důsledku nedostatku přístupových oprávnění a další neúspěšné činnosti uživatelů, • zahájení a ukončení činností systému, • chybová hlášení systému • změny přihlašovacích údajů (změna hesla a pod.) Centrální sběr logů: Systém musí umět zasílat auditní záznamy syslogem nebo umožnit přímý přístup k auditním záznamům definovanému učtu. Auditní záznamy musí být čitelné a strojově zpracovatelné. Účty a hesla: • automatické uzamykání účtu po opakovaném chybném zadání hesla • automatické odhlášení po definované době neaktivity • vynucování změny hesla • kontrola síly hesla (komplexita) Vzdálený přístup dodavatelů je zakázaný. Kryptografie TCP/IP pro management (protokol TLS 1.2 nebo vyšší) + dvou- faktorová autentizace (nebo silné heslo)“.
Kompatibilita s prostředím ČNB	Navržené řešení musí dodržovat standardy uvedené v části „Popis současného stavu a infrastruktury ČNB“. Pokud bude mít dodané zařízení v sobě integrovány komponenty, které nedodržují výše uvedené standardy, je to možné pouze za předpokladu že: - daná komponenta je bezúdržbová ze strany ČNB; - ze strany ČNB nebude umožněn vzdálený přístup; - budou dodrženy minimálně komunikační a bezpečnostní standardy pokud bude nutné komponentu zapojit do LAN/SAN. Z bezpečnostních standardů zdůrazňujeme zejména povinnost pravidelného patchování a změny hesla. Z důvodů kompatibility/interoperability NENÍ povoleno do SAN ČNB zapojit další zařízení typu FC switch nebo FC director. Obdobně se toto ustanovení použije i pro LAN ČNB. Zařízení zapojovaná do LAN ČNB

	musí respektovat současný IP adresní plán.
Kompatibilita serverů	Navržené řešení musí umožnit připojení serverů na platformách uvedených v tabulce „Seznam zařízení objednatele“. Kompletní seznam serverů včetně používaných HBA je uveden v příloze č. 4 smlouvy. Možnost připojení těchto serverů v kombinaci s operačním systémem k diskovému poli musí být výrobcem pole certifikována. Dodávané pole musí být certifikováno výrobci platforem používaných v ČNB: - MS Windows 2016 a Windows 2019 xxxxx://xxx.xxxxxxxxxxxxxxxxxxxx.xxx/ - pro VMware 7.0 xxxxx://xxx.xxxxxx.xxx/xxxxxxxxx/xxxxxxxxxxxxx/xxxxxx.xxx?xxxxxx Category=io Navržené řešení musí zajistit možnost připojení stávajícího technického vybavení (serverů) a umožňovat i rozvoj do budoucna (přechod na vyšší verze provozovaného programového vybavení-operačních systémů). Změny v této oblasti jsou možné zcela ojediněle (např. výměna velmi zastaralých HBA). Náklady spojené s výměnou takových komponent zhotovitel musí zahrnout do celkových nákladů na realizaci. Změna operačních systémů nebo jejich verzí je v rámci realizace výměny diskových polí zcela vyloučena.
Systém provozu	V obou lokalitách (tj. na obou diskových polích) jsou IS provozovány systémem active-active, tj. v každé lokalitě jsou za běžného provozu zpracovávány samostatné (různé) IS. Tento systém musí být zachován i nadále s tím, že řízení kde poběží daný IS je na úrovni LUNu (tj. disků přidělených serveru a konkrétnímu IS. Zpravidla se tedy bude jednat o skupinu LUNů přidělených IS.) Tento systém umožňuje využití pořízených kapacit v běžném provozu k rozložení zátěže mezi jednotlivé servery a disková pole.
Diagnostika	Diskové pole musí mít zajištěnu trvalou diagnostiku poruch. V případě poruchy musí diskové pole problém zabezpečenou cestou hlásit do diagnostického centra s provozem 24x7 (Provoz tohoto centra NEzajišťuje objednatel) a současně musí být informován i objednatel. Vzdálený přístup zhotovitele ani servisu výrobce do ČNB není povolen.
Zátěž SAN nebo jiných komponent prostředí ČNB	Navržené řešení nesmí neúměrně zvyšovat zátěž prvků stávajícího systémového prostředí ČNB (se zohledněním odpovídajícího nárůstu kapacity): - navýšení zátěže SAN je povoleno nejvýše o 10 % - navýšení zátěže LAN je povoleno nejvýše o 10 % - navýšení každé z ostatních komponent systémového prostředí je povoleno nejvýše o 5 %. Navržené řešení nesmí zcela svévolně, resp. pouze pro zajištění své vlastní režie navyšovat zátěž komponent současného prostředí ČNB. Tím by mohla vzniknout nutnost některé z komponent posílit.

Dohledový nástroj	Dohledový nástroj (GUI) musí zajistit: - evidenci chybových stavů včetně historie; - aktivní zasílání informací o chybách e-mailem nebo alespoň zápisem do syslogu; - sledování zátěže diskových polí o celkového zatížení až po jednotlivé komponenty, tj. disky, porty,.., historii minimálně 7 dnů) o pro jednotlivé LUNy měřit IOPS/MB/s/response time read/response time write: o musí být zajištěna možnost dohledání přetížené komponenty v rozsahu maximálně 20 minut od vzniku události (pozn: stor2rrd toto nesplňuje-viz dále). Zejména je požadována identifikace disku (LUNu), na kterém je vysoká zátěž u může tak ovlivňovat ostatní provoz. o sběr údajů maximálně po 2 minutách v prvních 24 hodinách. Delší historie mohou být již kumulované průměry avšak nejvýše v rozsahu 5 minut v následujících 3 měsících a 5 hodin do 1 roku.
	Dohled je možné rozčlenit na oblast správy/administrace a oblast sledování zátěže. Více nástrojů však není povoleno.
	Dohledový nástroj musí splňovat minimálně tato bezpečnostní kritéria: - klientský přístup protokolem https nebo ssh případně jiným, ale z hlediska bezpečnosti zabezpečeným protokolem; - zajistit autentizaci/autorizaci uživatelů; - zajistit auditing změn (netýká se R/O přístupu); - zajistit možnost přidělování rolí včetně samostatných účtů pro každého uživatele. Z důvodu zajištění správy a minimalizace nároků na správu diskových polí je požadováno zajištění odpovídajícího nástroje s odpovídající úrovní bezpečnosti.
	Pro dohledový nástroj může být ze strany ČNB v každé lokalitě poskytnuto: - 2x LAN port pro diskové pole - 1x Virtuální server (max 4xCPU, 8GB RAM, 200 GB HDD) s připojením do LAN a SAN
	ČNB provozuje produkt STOR2RRD. Tento nástroj je možné použít i pro připojení dodaných technologií. V tom případě, ale zhotovitel musí zajistit pro dodané produkty podporu pro stor2rrd v rozsahu jím dodaných zařízení.
Konfigurační změny	Diskové pole musí umožňovat minimálně tyto uživatelsky (=zaměstnanci ČNB) prováděné operace: - konfigurace jednotlivých disků (LUNů ve vztahu k host systému): - vytváření LUNů s minimální velikostí 1 GiB a maximální velikostí nejméně 20 TiB; - striping přes více logických/fyzických disků pro velké LUNy; - zvětšování LUNů bez ztráty dat; - konfigurace vzdáleného zrcadlení;

	- přiřazovat vytvořené LUNy na port/y diskového pole a k serverům (a odebírat z portu); - provádět LUN masking, tj. vytvářet/mazat na fyzickém portu definici nového serveru/ů a přiřazovat mu LUNy a nastavovat parametry portu (např. z důvodů různých operačních systémů serverů). Provádění všech operací musí být on-line, tj. bez dopadu na provoz (dostupnost) ostatních disků, serverů nebo komponent v diskovém poli (týká se uživatelsky i zhotovitelem prováděných operací). Tyto konfigurační změny musí být možné provádět jak z GUI tak i CLI (týká se uživatelsky prováděných operací). Konfigurační změny je možné provádět pouze za stejných „bezpečnostních kritérií“ jak má „Dohledový nástroj“.
Manipulace v clusteru- funkčnost clusteru	Pro zajištění funkce geografického clusteru musí být zajištěny minimálně tyto funkce: - provedení FailOver/FailBack* na úrovni LUNu; - otočení směru zrcadlení*. Provádění všech operací musí být on-line, tj. bez dopadu na provoz ostatních disků v diskovém poli.
	Tuto manipulaci musí být možné provádět minimálně z CLI pro všechny platformy dle přílohy č. 4. Provedení operace FailOver disků náležejících libovolné clusterové skupině musí být zajištěno do 1 minuty (čas od okamžiku výpadku některé komponenty do okamžiku uvedení příslušných disků v druhé lokalitě do stavu, kdy jsou přístupné operačnímu systému. Tento čas nezahrnuje dobu ukončení aplikace na havarovaném serveru ani čas startu aplikace na jiném uzlu clusteru.
	Přístup k manipulaci s disky musí být bezpečnostně omezen, tj. konkrétní server (cluster) smí provádět manipulace pouze s disky, které mu jsou přiděleny. Způsob realizace objednatel nepředepisuje (může být např. na bázi speciálního přiděleného disku přes FC nebo na bázi rolí při IP přístupu).
	* Pokud bude použita jiná technologie než zrcadlení z jednoho diskového pole (disky ve stavu Read/Write) na druhé (disky ve stavu ReadOnly), není toto podmínkou za předpokladu zajištění zrcadelní dat a zpřístupnění vhodné kopie příslušnému serveru.
Řídící	Komunikace pro řízení diskového pole (např. konfigurační změny,
komunikace	FailOver při havárii atd) může být realizována různými způsoby.
ovládání	V případě, že transport těchto příkazů diskovému poli probíhá jinou
diskového pole	cestou než je přenos dat (FibreChannel/SCSI), musí být pro tuto cestu
	zajištěno zdvojené připojení k diskovému poli. Např. v případě TCP/IP
	musí mít diskové pole v každé lokalitě minimálně 2 LAN porty
	a zhotovitel musí specifikovat používané porty pro tuto komunikaci
	(nastavení lokálních firewallů na serverech, např. IP tables).
	Požadavek na zdvojené připojení se týká veškeré komunikace
	vyžadované při činnosti geoclusteru a při rutinní práci s clonem. Pro
	konfigurační potřeby není vyžadováno zdvojené připojení.

	Řídící komunikace s diskovým polem musí být možná z příkazové řádky (CLI) a současně musí být zajištěn transparentní přenos chyby při vykonávání příkazu, tj. pro zpracování ve scriptu musí být zajištěno korektní navrácení chyby do příslušného shellu (ERRORLEVEL ve Windows resp. $? v UNIX systémech) odpovídající příkazu prováděnému na diskovém poli. Pro ovládání diskového pole v dávkovém zpracování (operace se vzdáleným zrcadlením nebo clonem) je nezbytné zajištění bezvýpadkového řízení diskového pole z příkazové řádky serveru. Tento požadavek se týká serverů, kterým jsou přiřazeny konkrétní LUNy nebo jejich vzdálené kopie případně clony. Pro konfigurační potřeby není nutné bezvýpadkové řízení (případný konfigurační server zajišťuje ČNB).
Auditing	Zajištění možnosti, kdo (jaký účet) jaké změny prováděl a kdy je prováděl (GUI i CLI). Tento požadavek musí být splněn. Minimální rozsah: • přihlášení a odhlášení administrátorů (uživatelů), • činnosti provedené administrátory, • činnosti vedoucí ke změně přístupových oprávnění, • neprovedení činností v důsledku nedostatku přístupových oprávnění a další neúspěšné činnosti uživatelů, • zahájení a ukončení činností systému, • chybová hlášení systému • změny přihlašovacích údajů (změna hesla a pod.)
Migrace dat	Spolupráce zhotovitele na migraci dat se nepředpokládá.
MSCS	Podmínkou realizace je zachování vrstvy MSCS v prostředí Windows Aplikace jsou pro toto prostředí specificky připravovány (zvláště pak např. Exchange Server). Nutnost certifikace na jiné prostředí clusteru by přinášela zásadní problémy a velká časová zpoždění
Licencování	Není rozhodující forma licencování programového vybavení – SW (tj. zda jsou licence na box nebo na kapacitu). Zhotovitel však ve své nabídce musí uvést veškerý dodávaný SW včetně způsobu jeho licencování a včetně počtu dodávaných kusů. Součástí předání dílčího plnění budou i veškeré licenční podmínky a případné licenční klíče.
Hmotnost a chlazení	Dodávané technické prostředky musí být umístitelné ve výpočetních střediscích ČNB. Zařízení bude v objektu ústředí umístěno do jednoho stojanu ČNB (výrobce Triton, řada RDA 42U 800x1000mm). Užitečné zatížení stojanu je povoleno do 450 kg. Případně je možné rozdělení do 2 stojanů (se stejnou celkovou hmotností). Vzhledem k současným rozměrům diskových i serverových zařízení je v krajním případě povolen přesah zařízení a to nejvýše o 20 cm za stojan směrem dozadu. Přesah směrem dopředu není povolen. Pro objekt ZP Zličín bude k dispozici prostor 20U v jednom stojanu. Jedná se o standardní 19” stojan šířky 60 cm.

	V ČNB je vytvořen systém tzv. teplé uličky. Zařízení jsou tedy ve stojanech s přívodem chladného vzduchu před stojan a výdech ohřátého vzduchu je zadem do zastřešené uličky a odtud je odváděn pryč.
Rozměry	Transportní trasy v obou objektech umožňují bezproblémovou dopravu zařízení s těmito parametry: maximální výška 150 cm, maximální základna 80 cm x 110 cm. Pro transport zařízení větších rozměrů je bezpodmínečně nutná prohlídka transportní trasy v době před podáním nabídky.
Napájení	Požadováno zdvojené, s napětím 230V (=jednofázové) s jištěním nejvýše 25A. Ve výpočetních střediscích ČNB jsou rozvaděče připraveny pro připojení systémů s 1 fázovým napájením. Do každého stojanu ČNB (Triton) jsou přivedeny dva přívody 230V/25A (každý z jiného rozvaděče), které jsou ve stojanu zakončené rozvodným panelem (18xC13 + 3xC19). Pro své potřeby může zhotovitel změnit vnitřní vybavení stojanu. ČNB zajistí ukončení pod stojanem rozvodnou krabicí s jištěním 25A.

Příloha č. 6

Bezpečnostní požadavky objednatele

1) Zhotovitel odpovídá za to, že do objektů objednatele (dále jen „ČNB“) budou vstupovat nebo vjíždět pouze ti jeho pracovníci, kteří jsou jmenovitě uvedeni v písemném seznamu schváleném ČNB (dále jen „seznam“). Tato povinnost se vztahuje i na posádky vozidel zhotovitele vjíždějících do garáží ČNB za účelem složení a naložení nákladu. Seznam zhotovitel předloží ČNB nejpozději den před zahájením prací.

2) Seznam bude obsahovat tyto položky: jméno, příjmení a číslo průkazu totožnosti každého z pracovníků zhotovitele. Zhotovitel se zavazuje zajistit, aby všichni jeho pracovníci uvedení v seznamu byli ještě před předložením seznamu ČNB proškoleni o podmínkách zpracování osobních údajů a o právech subjektů údajů ve smyslu obecného nařízení o ochraně osobních údajů - Nařízení Evropského parlamentu a Rady (EU) 2016/679 ze dne

27. dubna 2016 o ochraně fyzických osob v souvislosti se zpracováním osobních údajů a o volném pohybu těchto údajů a o zrušení směrnice 95/46/ES (dále jen „GDPR“). Zhotovitel se zejména zavazuje, že všichni jeho pracovníci uvedení v seznamu budou nejpozději do okamžiku předložení seznamu ČNB poučeni:

- o tom, že zhotovitel předá jejich osobní údaje v rozsahu: jméno, příjmení a číslo průkazu totožnosti České národní bance, sídlem Na Příkopě 28, Praha 1 v rámci plnění této smlouvy, a to za účelem ochrany práv a oprávněných zájmů ČNB (zajištění evidence osob vstupujících do budovy ČNB z důvodu ochrany majetku a osob a správy přístupového systému ČNB);

- o veškerých právech subjektu údajů, která mohou uplatnit vůči zhotoviteli a ČNB, zejména o právu na přístup k osobním údajům, které jsou o nich zpracovávány, právu na námitku proti zpracování osobních údajů, právu požadovat nápravu situace, která je v rozporu s právními předpisy, a to zejména formou zastavení nakládání s osobními údaji, jejich opravou, doplněním či odstraněním, jakož i o právu podat stížnost k Úřadu pro ochranu osobních údajů.

3) Za poučení svých pracovníků ponese zhotovitel vůči ČNB následně odpovědnost. V případě nesplnění povinnosti podle odst. 2 této přílohy nahradí zhotovitel újmu, která v souvislosti s uvedeným ČNB vznikne, a to včetně případné nemajetkové újmy vzniklé poškozením dobrého jména a dobré pověsti, újmy vzniklé v důsledku postihu pravomocně uloženého ČNB správním nebo jiným k tomu oprávněným orgánem veřejné moci a újmy vzniklé ČNB v důsledku úspěšného uplatnění práv pracovníků zhotovitele vůči ČNB.

4) Požadavky na případné doplňky a změny schváleného seznamu je nutno neprodleně oznámit ČNB. Případné doplňky a změny seznamu podléhají schválení ČNB. Osoby neschválené ČNB nemohou vstupovat do objektů ČNB, přičemž ČNB si vyhrazuje právo neuvádět důvody jejich neschválení.

5) Při příchodu do objektů ČNB pracovníci zhotovitele sdělí důvod vstupu, prokáží se osobním dokladem a podrobí se bezpečnostní kontrole. Osoby, které nejsou uvedeny v seznamu, nebudou do objektů ČNB vpuštěny.

6) Schválení pracovníci zhotovitele musí dbát pokynů bankovních policistů, které se týkají režimu vstupu, pohybu a vjezdu do objektu ČNB. Pracovníci zhotovitele budou do prostor ČNB vstupovat a v těchto prostorách se pohybovat v režimu návštěv, to znamená vždy pouze v doprovodu zaměstnance ČNB nebo zaměstnance referátu bankovní policie ČNB.

7) V případě mimořádné události se pracovníci zhotovitele musí řídit pokyny bankovních policistů nebo dozorujícího zaměstnance ČNB, a dále instrukcemi vyhlašovanými vnitřním rozhlasem.

8) Pracovníci zhotovitele nesmí vnášet do prostor ČNB nebezpečné předměty, jako jsou střelné zbraně, výbušniny apod. O tom co je a není nebezpečný předmět, rozhodují bankovní policisté v souladu s vnitřními předpisy ČNB.

9) ČNB si vyhrazuje právo nevpustit do objektů ČNB pracovníka zhotovitele, který je zjevně

pod vlivem alkoholu, drog nebo jiné omamné látky.

10) Bez písemného povolení ČNB je zakázáno fotografování a pořizování videozáznamů

z interiéru objektů ČNB.

11) Ve všech prostorech objektů ČNB je přísný zákaz kouření a používání otevřeného ohně. O povolení práce se zvýšeným požárním nebezpečím požádá zhotovitel písemnou formou vždy nejpozději jeden pracovní den před zahájením prací, dozorujícího zaměstnance ČNB. Dále se pracovníci zhotovitele musí zdržet poškozování či zcizení majetku ČNB, a dále zdržet se nevhodného chování vůči zaměstnancům a návštěvníkům ČNB.

12) Pracovníci zhotovitele uvedení na seznamu se musí před započetím výkonu práce v objektech ČNB prokazatelně seznámit, ve smyslu předpisů o požární ochraně, bezpečnosti a hygieně práce, se specifikami daných objektů ČNB (např. způsob vyhlášení požárního poplachu, určení ohlašovny požáru, seznámení s únikovými cestami, poplachovými směrnicemi, evakuačním plánem, umístěním věcných prostředků požární ochrany apod.). ČNB je oprávněna kdykoliv podrobit kontrole kterékoliv pracovníka zhotovitele uvedeného na seznamu z dodržování těchto předpisů a ustanovení.

Příloha č. 7

Návrh technického řešení

Nabízená generace diskových polí Hitachi „Virtual Storage Platform G370“ přináší špičkové technologie používané v segmentu diskových polí. Diskové pole VSPG370 je dvojkontrolerový systém, kde každý kontroler obsahuje dvojici Storage Procesorů.

Diskové systémy VSP G370 vycházejí z enterprise architektury HiStar, jejíž kořeny pocházejí z éry mainframů. HiStar architektura používá symetrický aktiv/aktiv přístup k datům a má globální cache paměť, která dovoluje zrcadlit data na úrovni jednotlivých IO operací, proto zrcadlí pouze zapisovací IO tzn. je o 100 % efektivnější IO než konvenční midrange diskové pole.

Příklad konfigurace VSPG G370, design přední panel, design zadní panel

Legenda:

1) Kontroler (konfigurace obsahuje 2xkontroler, každý kontroler 2x Storage Procesor)

2) Porty 32Gbps.. Porty z cenových důvodů mohou být osazeny 16Gbps SFP+, které lze v případě potřeby v budoucnu upgradovat na 32Gbps infrastrukturu pouhou výměnou SFP

3) Kontroller LED

4) Battery LED

5) Alarm Kontroler LED

6) Cahce Backup SSD disk (V případě výpadku napětí jej diskové pole využívá k uložení obsahu CACHE na neomezeně dlouhou dobu – aby při výpadku napájení nedošlo ke korupci dat)

7) LAN port (Support)

8) LAN port (Management)

9) UPS port

10) Alarm Cahce LED

11) Batery Backup Modul (Při výpadku napájení slouží ke krátkodobému udržení funkcionality pole,

tak aby mohlo dojít ke kopii dat Cache do interního SSD)

12) Status Battery LED

13) SAS port (Slouží pro připojení expanzních polic a upgrade diskového až na 252 disků)

14) PORT Status LED

15) Dvojice redundantních napájecích zdrojů

Diskový systém VSPG350 disponuje kontrolery s výkonností přesahující 1 200 000 IO operací za sekundu, což ve srovnání se starými generacemi diskových polí představuje významné mezigenerační navýšení výkonu více než o řád.

Velikost Cache

Díky inteligentnímu mikrokódu pole provádí cache několik úrovní optimalitace:

• Diskové pole G350 disponuje již v základu velikostí cache 256GB, což významně převyšuje běžné parametry konkurenčních řešení. Velikost Cache hraje velmi podstatnou roli pro akceleraci Read/Write operací a její velikost je klíčovou pro výkon.

• dochází k inteligentnímu předcachování read operací, díky které se v typických prostředích daří odbavit 60-90% operací přímo z cache rychlostí křemíku, tj. v sub- miisekundových latencích

• Dochází k inteligentnímu sestavování celých RAID bloků při zápisových operací, což minimaizuje zápisové nároky na disky tj. zmenšuje počet back-end diskových operací nutných k obsloužení příchozích front-end operací.

Diskové pole dále disponuje technologií „Active Flash“, která má schopnost využívat instalovanou SSD/Flash kapacitu pro akceleraci diskových operací. Všechny tyto optimalizace mají společného jmenovatele – a tím je schopnost i s relativně nízkým množstvím diskových zdrojů (tj. s nízkým počtem disků) poskytovat excelentní výkonnostní potenciál pro serverovou infrastrukturu.

Tiering

Tierované úložiště je systém, který rozpozná míru využívání různých dat a přiřazuje jej k různým typům médií o různých výkonech a ceně. Smyslem takového konání je vytěžit z diskových médií to nejlepší – ze SSD výkon a z klasických disků jejich dobrou cenu za jednotku uložené kapacity.

Klíčem, který se využívá k rozpoznání kam data uložit, je takzvaný „Heat Index“. Diskové pole si monitoruje, jak často servery přistupují k jednotlivým blokům dat. Bloky, které jsou využívány často, tedy „High Activity Set“, jsou realokovány do rychlých médií a naopak málo často využívané bloky, tedy „Quiet Data Set“, jsou realokovány například do NL-SAS disků. Z hlediska serveru je vše transparentní.

Snapshoty, klony a replikace

Toto řešení poskytuje pohodlné a cenově výhodné kopie místních datových bodů v čase pomocí snímků založených na úložném prostoru, efektivního prostoru a klonů v plném objemu. Vytváří kopie rychleji a častěji než řešení založená na serverové vrstvě, aniž by to mělo dopad na produkční aplikace. Tento softwarový balíček zahrnuje Hitachi Thin Image Snapshot, Hitachi ShadowImage Replication a Hitachi Replication Manager.

Externí disková virtualizace

Princip Externí Diskové Virtualizace spočívá v připojení externích diskových polí pod jednotnou správu Hitachi enteprise systému VSP Gxxx. A to včetně diskových polí třetích stran.

Takto lze propůjčit inteligenci diskových systémů Hitachi (replikace napříč lokalitami, tiering, dynamic provisioning, snapshoty, klony a další) i diskovým polím, která tyto funkcionality nemají. Díky tomu umíme důsledně ochránit investice učiněné do úložných prostředků.

Pomocí Diskového pole VSP G370 tak lze tvořit např. klony produkčních dat do starého pole - a to nástroji pole bez jakékoliv nutnosti integrace se serverovými aplikacemi a bez negativních výkonnostních dopadů do produkčního prostředí.

Dohledové centrum výrobce = HiTrack

Hi-Track je cloudová služba vzdáleného monitorování poskytovaná pro všechna zařízení Hitachi, na která se vztahuje údržba. Vzdálené monitorování je bezpečné a zajišťuje proaktivní monitorování a údržbu dříve, než se objeví jakýkoli problém.

Storage MetroCluster

Diskové pole HITACHI G370 přijalo funkcionality známé ze systémů kategorie Enterprise. Např. funkce vytváření virtuálních storage lokálního i globálního typu. Konfigurace Hitachi virtuální storage je plně v rukou storage administrátora a obsahuje následující nastavení:

• Model virtuálního diskového systému

• Sériové číslo virtuálního diskového systému

• Jméno virtuálního diskového systému

• HDD (FMD, SSD, SAS, NLSAS)

• Cache

• Front-End porty

Storage administrátor může za běhu, tzn. online, pro aplikace nejen měnit konfiguraci virtuální storage, ale může také virtuální storage přesouvat z jednoho diskového systému VSP G370 na jiný, nebo ji může rozprostřít mezi více diskových systémů VSP G370

Součástí takovéto Metro/Geo virtuální storage je speciální typ LUNu, tzv. Global Active Device (GAD). XXX využívá oba hostitelské diskové systémy VSP G370 v režimu aktiv/aktiv s preferencí kratší cesty. Server nebo aplikace pracují s takovouto virtuální storage a jejími GAD LUNy zcela normálním způsobem, respektive GAD je pro ně zcela transparentní.

Metro/Geo virtuální storage nabízejí kromě větší výkonnosti také funkci vysoké dostupnosti, která je dalším klíčovým požadavkem enterprise prostředí a jejich zákazníků.

Odolnost proti scénáři „Split Brain“ je zajištěna pomocí Quora Storage (možnost připojení protokoly FC nebo iSCSI).

Obě disková pole jsou v režimu Storage Metro Cluster aktivní, každá ze stran Metro Clusteru je v daný okamžik přístupná pro zápis i čtení. Mezi diskovými poli probíhá obousměrná replikaci, která zajišťuje binárně identický datový obsah obou diskových polí.

Servery tak Storage Metro Cluster identifikují jako jedno vícecestně připojené diskové pole, kde všechny cesty jsou aktivní a mohou být využívány pro read/write operace. V případě potřeby preferovat lokální diskové pole (a minimalizovat tak datové přesuny mezi lokalitami před DWDM spojení), lze tento požadavek realizovat pomocí emulace ALUA SCSI příkazů, kdy diskové pole v rámci inicializace FC konektivity navrhne operačnímu systému preferované datové cesty.

Replikovaná data jsou po replikačních cestách přenášena pouze jednou, tzn. zápis do diskového pole „A“ je přenesen na „B“, respektive zápis do „B“ je přenesen do „A“. Tímto je řešení Hitachi efektivnější, než většina konkurenčních řešení, kde veškeré datové přenosy musejí proběhnot přez takzvaný „master nod“ – to znamená, že zápis do diskového pole „B“ je u konkurečních řešení přesměrován na „A“ (master nod) a odtud zreplikován zpět na „B“ (Slave nod) – což vede k vícenásobným přesunům dat po DWDM linkách.

Primárním arbitrem, podle kterého Storage Metro Cluster posuzuje funkčnost clusteru, je navázané replikační spojení obou diskových polí mezi lokalitami.

V případě rozpadu replikačních cest je odolnost proti scénáři „Split Brain“ realizovaná pomocí komunikace obou diskových polí s Quorem. Z toho vyplývá, že za běžného produkčního stavu, kdy jsou funkční replikační cesty, je řešení odolné proti komunikačnímu drop-outu quora.

Uchazeč v tomto bodě plánuje využít nabízené možnosti zadavatelem využít stávajícího quora zadavatele dle textace uvedené v zadávací dokumentaci:“

V případě technologie GAD je možné využít stávající server, pokud je to technologicky a výkonnostně možné.“

Datová migrace prostřednictvím diskové virtualizace

Kromě datové migrace prostřednictvím serverové virtualizace (např. VMware – Storage vMotion) je možné datové migrace realizovat prostřednictvím tzv. diskové virtualizace.

Disková virtualizace je schopnost diskového systému HITACHI G370 pracovat nejen s interní diskovou kapacitou, ale i s externí kapacitou v podobě připojených diskových polí. A to nejen Hitachi, ale i dalších výrobců. Enteprise diskové pole pak pracuje s touto „podvěšenou“ kapacitou jako s vlastní a umožňuje na ni aplikovat vlastnosti enterprise controllerů – například zde navrhovnou migraci dat z externích LUNů do interních LUNů za provozu

Možnosti migrace dat pomocí diskové virtualizace

• Stávající storage bude i nadále připojena do SAN a na úrovni změny konfigurací v SAN switch dojde k jejímu propojení s nově instalovaným

Hitachi VSP F800, prostřednictvím něhož bude tento storage zvirtualizován a 1:1 vypublikován serverům. Poté on-lina a za provozu bude jeho obsah následně přemigrován do nového prostředí.

• Stávající storage bude napřímo připojena k nově instalovaným VSP G370, prostřednictvím něhož bude tento storage zvirtualizován. Následující postup se shoduje s předcházejícím bodem.

V rámci možných postupů migrace jsou samozřejmě možné i jiné metody a postupy, ale tento navržený postup je z hlediska jeho efektivity a náročnosti výrobcem definovaný jako „best practices“. Výhodou tohoto postupu je minimální náročnost na odstávky stávajících systémů a rozsahy rekonfigurací, kdy v počáteční fázi je pro virtualizaci stávajícího prostředí a rekonfiguraci na úrovni SAN nutná odstávka.

Následná migrace dat ze stávající storage HP do nové storage infrastruktury je pak již možná z pohledu klientů „bezvýpadkově.

Popis způsobu licencování

• Global Active Device:

o Licence zajišťující funkcionalitu Storage Metro Clusteru.

o Název: F700 „Global Active Device Base License“

o Licencování per box

• External Storage License

o Součástí nabídky je 1ks Licence F700 External Storage Base License

o Tyto licence jsou per externí Storage systém (jediná cena za každé pole, které je virtualizované). To se týká pouze ukládacích systémů jiných výrobců než Hitachi.

Systémy úložišť Hitachi mohou být virtualizované na systémech F700 bez licence externího úložiště.

• Foundation Package:

o Balík řady SW funkcionalit licencovaných per box, viz:

Pozn: ShadowImage a ThinImage jsou názvy pro požadovanou funkcionalitu snapshotů a klonů.

Popis vzájemného propojení dodaných komponent a zapojení do struktur ČNB

• Nabízená disková pole VSP G370 budou do infrastruktury ČNB integrováno připojením pomocí protokolu FibreChannel.

• Dvojice diskových polí bude pomocí technologie „Storage Metrocluster“, která je

v terminologii výrobce Hitachi označována zkratkou GAD, tvořit jediný geograficky distribuovaný systém ve dvou lokalitách. Tento koncept je realizací požadavků zadavatele v kapitole

• Pro replikaci se předpokládá vyčlenění samostatných FC portů typu bi-directional, komunikace typu SAN. Z hlediska struktur ČNB tento typ portů nevyžaduje zvláštní set-up, jedná se o standardní FC. Toto vyčlenění není technicky nezbytné, je však doporučené.

• Pro management bude dedikován řídící server, který je v terminologii výrobce označován SVP. Management diskového pole probíhá po síti LAN 1Gbps, kde je prerekvizitou připravenost 4x1Gbps LAN na switchi zadavatele + přidělení IP adre

Popis způsobu lokálního zabezpečení dat (počty disků v RAID skupiných, počty spare disků a pod) a výpočet dosažené kapacity

• Předmětem nabídky je dvojice diskových polí G370 s 138 disky. Možných sestavení paritních vektorů je více a je tak možné reagovat na konkrétní preference zadavatele

• Jednou z možných a uchazečem předpokládaných konfigurací je 17 paritních skupin RAID 5 (7+1) doplněná 2ks paritních disků, typ disků 2,4TB SAS 10krpm.

• Kapacita v TB, výpočet: 17x7x2,4TB =285TB, tj. kapacita 250 TiB po převodu do base2 a započítání režie na každé z diskových polí

Popis způsobu migrace. Nezbytnou součástí musí být popis, jak bude zajištěna minimalizace odstávek s ohledem na daná omezení (např. 4 hodiny a volume o velikosti 10 TB s 50 miliony souborů na fyzickém serveru s Win2008)

• Dle zadávací dokumentace zadavatel neočekává součinnost uchazeče s migračními pracemi

• Jsme však připraveni v případě potřeby vyvinout plnou součinnost počínaje návrhem migračních scénářů po součinnost na jejich realizaci

• V obecné rovině jsou migrační mechanismy korespondující s potřebami zadavatele realizovatelné několika způsoby:

o Pokud to situace umožňuje, tak pomocí služeb hypervizoru, např. technologie sVmotion

o Pomocí funkcionality diskového pole takzvané „externí virtualizace“. Tento mechanismus je detailně popsánv kapitole výše „Datová migrace prostřednictvím diskové virtualizace“

o Migrace pomocí funkce GAD v případě, že původní diskové pole, ze kterého jsou data migrována podporuje tuto technologii. Výhodou tohoto scénáře je možnost bevýpadkové migrace.

Popis managementu včetně performance monitoringu,

• Diskové pole jsou primárně řízena a managována Management Procesorem (SVP), který je součástí dodávky. Diskové pole je možné spravovat tímto nízkoúrovňovým nástrojem Storage Navigator Modular , které je vhodné pro situace kdy set-up diskových polí nepodléhá velmi častým změnám. Tento nástroj obsahuje i nástroje pro monitoring performance v reálném čase.

• Pomocí dodaných programových prostředků lze performance statistiky exportovat pro potřebu integrace s analytickými systémy. Integrace se systémy vužívající tyto mechanismy, například zadavatelem zmíněný stor2rrd je podporována.

• Krom standardního řízení diskového pole komplexním způsobem přes Storage Management Processor je u Systému G370 k dispozici graficky založený aplikační management DevOps umožňující management diskového pole, detailní performance analýzu s možnostmi End-to-End monitoringu a nástroje pro automatizaci úkonů, které pomáhají například zmenšit komplexnost úkonů, jako tvorba storage metrosluster LUNů typu GAD, viz:

Příloha č. 8

Cenová tabulka

Řádek č. Položka Cena v Kč bez DPH

1. dílčí plnění v Kč bez DPH
1.	Cena dodávaných technických prostředků bez podpory	3 231 291,00
2.	Cena dodávaných programových prostředků, které jsou nedílnou součástí technických prostředků bez podpory	987 654,00
3.	Cena dodávaných programových prostředků, které nejsou nedílnou součástí technických prostředků bez podpory	0,00
4.	Cena plnění dle čl. I odst. 2 písm. a) druhá, třetí a čtvrtá odrážka návhu smlouvy (tj. připojení serverů, instalace SW, konfigurace LUNů, dodání dokumentace výrobce technických a programových prostředků, testovací provoz). Za naprosté minimum bude považováno nacenění 20 člověkodnů (MD) pracnosti.	58 000,00
5.	Cena školení 6 odborných pracovníků objedantele dle čl. I odst. 2 písm. a) pátá odrážka návrhu smlouvy	12 000,00
	Cena celkem za 1. dílčí plnění	4 288 945,00

2. dílčí plnění v Kč bez DPH
6.	Zkušební provoz	12 000,00
7.	Dokumentace dle čl. I odst. 2 písm. b) druhá odrážka návrhu smlouvy	12 000,00
	Cena celkem za 2. dílčí plnění	24 000,00

Celková cena za 1. a 2 dílčí plnění 4 312 945,00

Cena podpory technických prostředů a programových prostředků, které jsou nedílnou součástí technických prostředků (čl. III odst. 3 smlouvy) v Kč bez DPH
8.	Cena podpory technických prostředků (viz řádek č. 1 výše) na dobu 60 měsíců (bude uhrazeno jednorázově)	94 170,00
9.	Cena podpory programových prostředků, keré jsou nedílnou součástí technických prostředků (viz řádek č. 2 výše) na dobu 60 měsíců (bude uhrazeno jednorázově)	44 111,00
	Cena jednorázové podpory technických a programových prostředků, které jsou nedílnou součástí technických prostředků celkem	138 281,00

Cena podpory programových prostředků, které nejsou nedílnou součástí technických prostředků (čl. III odst. 4 smlouvy) v Kč bez DPH
		Cena služby za 12 měsíců v Kč bez DPH*
10.	Podpora programových prostředků, které nejsou nedílnou součástí technických prostředků dle řádku č. 3 výše (bude hrazeno ročně)	0,00

Cena podpory technických prostředků a programových prostředků, které jsou nedílnou součástí technických prostředků po uplynutí 60 měsíců předplacené podpory (čl. III odst. 5 smlouvy) v Kč bez DPH**
		Cena služby za 12 měsíců v Kč bez DPH*
11.	Podpora technických prostředků a programových prostředků, které jsou nedílnou součástí technických prostředků za období 12 měsíců (po uplynutí 60 měsíců předplacené podpory) - čl. III odst. 5 smlouvy (bude hrazeno ročně)**	37 170,00

Jednotlivé ceny zahrnují veškeré náklady poskytovatele spojené s plněním veřejné zakázky.

* Smlouva se uzavírá v části týkající se podpory na dobu neurčitou.

** Smlouvu lze vypovědět v souladu s čl. XI odst. 2 smlouvy.