SMLOUVA‌

Xxxxx Xxxxxxx MF

19/906/0027

Toto číslo uvádějte při fakturaci

SMLOUVA ‌

o dodávce diskových polí, SAN switchů a o zajištění technické a servisní podpory

uzavřená dle ustanovení § 1746 odst. 2, zákona č. 89/2012 Sb., občanského zákoníku, v platném znění (dále jen „Občanský zákoník“) a v souladu se zákonem č. 134/2016 Sb., o zadávání veřejných zakázek, ve znění pozdějších předpisů (dále jen „ZZVZ“),

č.j.: MF-158/2020/6602

Evidenční číslo: 9006/037/2019

(dále jen „Smlouva“)

Česká republika – Ministerstvo financí se sídlem: Letenská 15, 110 00 Praha 1 za niž jedná: xxxxxxxxxx

IČO: 00006947 DIČ: CZ00006947

ID datové schránky: xzeaauv bankovní spojení: xxxxxxxxxx číslo účtu: xxxxxxxxxx

ID datové schránky: xzeaauv (dále jen „Objednatel“)

GAPP System, spol. s r.o.

se sídlem: Petržílkova 2565/23, 158 00 Praha 5 zastoupena: Ing. Xxxxxx Xxxxxxxx

společnost zapsaná v obchodním rejstříku vedeném u Městského soudu v Praze, oddíl C, vložka 27177

IČO: 60487291 DIČ: CZ60487291

bankovní spojení: xxxxxxxxxx číslo účtu: xxxxxxxxxx

ID datové schránky: q5a7pm7 (dále jen „Poskytovatel“)

(Objednatel a Poskytovatel společně dále též jen jako „Smluvní strany“ a jednotlivě jako „Smluvní strana“)

PREAMBULE

Tato Xxxxxxx se uzavírá na základě veřejné zakázky „Dynamický nákupní systém na prostředky ICT v resortu Ministerstva financí – Výzva 1-2020“, která je zadávána v rámci Dynamického nákupního systému na prostředky ICT v resortu Ministerstva financí, systémové číslo DNS: P18V00000050, uveřejněno ve Věstníku veřejných zakázek dne 4. 6. 2018 pod ev. č. Z2018-018121 (dále jen „Veřejná zakázka“) (to vše dále jen „Zadávací řízení“), kdy nabídka Poskytovatele byla vybrána jako nejvhodnější. Pokud se v této Smlouvě odkazuje na zadávací podmínky, zadávací dokumentaci či nabídku Poskytovatele, míní se tím dokumenty související se Zadávacím řízením (dále jen

„Dokumenty Zadávacího řízení“).

I. ÚČEL SMLOUVY

Účelem této Smlouvy je pořízení a implementace funkčních SAN technologií a diskových polí z důvodu zajištění kompletní obměny nevyhovujícího, zastaralého, potenciálně nebezpečného a výrobci již nepodporovaného stávajícího IT prostředí Objednatele.

II. PŘEDMĚT SMLOUVY

1) Předmětem této Smlouvy je závazek Poskytovatele zajistit pro Objednatele kompletní obměnu Diskových polí a SAN switchů, včetně jejich Implementace a konfigurace do prostředí TFO clusteru, související migrace dat a poskytnutí Servisní a Technické podpory.

Předmět plnění zahrnuje tyto dílčí služby:

(a) Dodávku hardware (dále jen „Hardware“), software a potřebných licencí v rozsahu:

• 2 kusy primárních diskových polí kategorie Enterprise a 1 kus backup (záložní) pole kategorie Enterprise (dále jen „Disková pole“), jejichž bližší specifikace je uvedena v Příloze č. 1 této Smlouvy,

• 8 kusů SAN switchů (přepínače) (dále jen „SAN switch“), jejichž bližší specifikace je uvedena v Příloze č. 2 této Smlouvy.

• zajištění příslušného software včetně licenčních oprávnění k Diskovým polím a SAN switch (dále jen „Licence“), jejichž specifikace je součástí Přílohy č. 1 a Přílohy č. 2 této Smlouvy (společně také „Systém“).

(b) Zajištění implementace a integrace Diskových polí a SAN switch do stávajícího prostředí Objednatele (dále jen „Implementace“). Bližší specifikace Implementace je uvedena v Příloze č. 3 této Smlouvy.

„Testování“). Specifikace Testování je uvedena v Příloze č. 4. této Smlouvy.

(d) Zajištění migrace dat ze stávajících diskových polí Objednatele na dodaná Disková pole (dále jen „Migrace“). Obecná specifikace migrovaných dat je uvedena v Příloze č. 5. této Smlouvy.

(e) Zajištění školení v rozsahu pěti (5) MD zaměřených na SAN technologie a školení v rozsahu pěti (5) MD zaměřených na disková pole (dále jen „Školení“) s lektorem v českém jazyce na území ČR.

(f) Zajištění poskytování technické podpory výrobce na dodaná Disková pole a SAN switch (dále jen „Technická podpora“). Bližší specifikace poskytování Technické podpory, včetně uvedení kategorizace vad a konkrétních časů je uvedena v Příloze č. 6 této Smlouvy.

(g) Poskytnutí servisní podpory na dodaná Disková pole a SAN switch dle specifikace uvedené v Příloze č. 7 této Smlouvy (dále jen „Servisní podpora“).

(h) V případě požadavku Objednatele zajištění rozšíření diskové kapacity dodaných Diskových polí dodávkou HW a potřebného SW včetně zajištění technické podpory a dále též v případě požadavku Objednatele zajištění podpory dodatečně dodaných disků (dále jen „Rozšíření“). Specifikace požadovaného Rozšíření Diskového pole tvoří Přílohu č. 8 této Smlouvy.

(dále společně jen „Předmět plnění“).

2) Předmětem této Smlouvy je dále povinnost Objednatele za řádně a včas dodaný Předmět plnění uhradit Poskytovateli smluvní cenu dle článku VI. této Smlouvy.

3) Poskytovatel se zavazuje při dodávce Hardware, jak je specifikován v odst. 1 písm. a) tohoto

článku zohlednit stávající implementovanou DWDM technologii Objednatele, jak je specifikována v Příloze č. 14 této Smlouvy a zajistit, že dodaný Hardware bude s touto DWDM technologií plně kompatibilní.

4) Poskytovatel se zavazuje poskytovat Předmět plnění v souladu s touto Smlouvou, veškerými přílohami k této Smlouvě a s Dokumenty Zadávacího řízení. V případě rozporu vyjmenovaných podkladů mají přednost ustanovení této Smlouvy. V případě rozporu příloh této Smlouvy a Dokumentů Zadávacího řízení, mají přednost ustanovení příloh.

III. MÍSTO, DOBA A ZPŮSOB PLNĚNÍ SMLOUVY

1) Místem plnění jsou následující objekty Objednatele:

(a) sídlo Objednatele na adrese: Xxxxxxxx 000/00, 000 00 Xxxxx 0,

(b) pracoviště Objednatele na adrese: Xxxxxxxxx 0000/00, 000 00 Xxxxx 0,

Na Vápence 915/14, 130 00 Praha 3, (dále společně „Místa plnění“ nebo jednotlivě „Místo plnění“).

2) Předmět plnění uvedený v čl. II. odst. 1 písm. (a) (Disková pole, SAN switch a Licence) je Poskytovatel povinen dodat na Místa plnění nebo realizovat v Místech plnění nejpozději do čtyřiceti pěti (45) kalendářních dnů ode dne účinnosti této Smlouvy. Předmět plnění uvedený v čl. II. odst. 1 písm. (b) (Implementace) a písm. (c) (Testování) je Poskytovatel povinen dodat na Místa plnění nebo realizovat v Místech plnění nejpozději do šedesáti (60) kalendářních dní od podpisu předávacího protokolu (viz. Příloha č. 9 – Předávací protokol).

3) Předmět plnění uvedený v čl. II. odst. 1 písm. (d) (Migrace) a písm. (e) (Školení) je Poskytovatel povinen realizovat v případě Migrace v Místech plnění, v případě Školení na území v ČR nejpozději do devadesáti (90) kalendářních dní ode dne podpisu Akceptačního protokolu k části Předmětu plnění Testování bez výhrad.

4) Předmět plnění uvedený v čl. II. odst. 1 písm. (f) (Technická podpora) bude poskytován po dobu šedesáti (60) měsíců ode dne podpisu Akceptačního protokolu k části Předmětu plnění Migrace a Školení bez výhrad.

5) Předmět plnění uvedený v čl. II. odst. 1 písm. (g) (Servisní podpora) bude poskytován pouze na základě požadavku Objednatele odeslaném prostřednictvím e-mailu oprávněné osobě Poskytovatele, a to v maximálním rozsahu dvaceti pěti (25) MD za celou dobu trvání této Smlouvy. Uvedený počet MD lze čerpat i na Servisní podporu dodatečného Rozšíření Hardware dle odst. 6 tohoto článku.

6) Předmět plnění uvedený v čl. II. odst. 1 písm. (h) (Rozšíření) bude poskytován pouze na základě požadavku Objednatele vzneseným kdykoliv po dobu trvání této Smlouvy.

Objednatel si vyhrazuje ve smyslu § 100 odst. 1 ZZVZ ve spojení s § 222 odst. 2 ZZVZ smluvní opci pro zajištění Rozšíření Předmětu plnění uvedeného v čl. II odst. 1. písm. (h) této Smlouvy a to v maximálním rozsahu, který odpovídá svou hodnotou částce 15 000 000 Kč včetně DPH.

7) Poskytovatel včas dohodne s Objednatelem datum a čas předání Systému a provedení Implementace, Testování, Migrace a Školení a rovněž Místo plnění, kde bude Systém předán a Implementace, Migrace a Školení provedeny. Nedohodnou-li se Smluvní strany na oboustranně vyhovujícím datu a čase předání, platí, že Systém bude předán a Implementace, Migrace a Školení budou provedeny poslední den příslušné lhůty v 14.00 hod.

8) Před zajištěním Předmětu plnění nebo jeho části bude Poskytovatel včas prokazatelně informovat Oprávněnou osobu Objednatele uvedenou v této Smlouvě v čl. XII. o jeho připravenosti k dodání

nebo k realizaci Předmětu plnění nebo jeho části.

9) Vlastnické právo (resp. právo užívání u SW komponent) k Systému se převádí dnem jeho předání na Objednatele.

10) Smluvní strany se dohodly, že Poskytovatel bude plnit Předmět plnění ve 4 fázích:

10.1. První fáze plnění spočívá v dodání nebo realizaci dílčích částí Předmětu plnění uvedených v čl. II. odst. 1 písm. (a), (b), a (c) do Místa plnění, o čemž bude sepsán Předávací protokol (pro plnění uvedené v čl. II. odst. 1 písm. (a) jejichž vzory tvoří Přílohu č. 9) nebo Akceptační protokol Implementace a Testování (pro plnění uvedené v čl. II. odst. 1 písm. (b) a (c) jejichž vzory tvoří Přílohu č. 10 této Smlouvy, v rámci kterých Objednatel uvede případné výhrady k provedení první fáze plnění (dále jen „První fáze plnění“). Případné výhrady uvedené v Předávacím protokolu se Poskytovatel zavazuje odstranit neodkladně, nejpozději do pěti (5) pracovních dnů od podpisu daného protokolu. Případné výhrady uvedené v Akceptačním protokolu se Poskytovatel zavazuje odstranit neodkladně, nejpozději do třiceti (30) pracovních dnů od podpisu daného protokolu. Po odstranění případných výhrad Smluvní strany sepíší nový Předávací nebo Akceptační protokol k První fázi plnění bez výhrad. Pokud nedojde k odstranění výhrad Objednatele uvedených v Akceptačním (resp. Předávacím) protokolu ve stanovené lhůtě třiceti (30) dnů jedná se o podstatné porušení této Smlouvy Poskytovatelem a Objednatel je v takovém případě oprávněn od této Smlouvy odstoupit dle ustanovení čl. XIII. odst.

6. této Smlouvy.

10.2. Druhá fáze plnění spočívá v provedení dílčí části Předmětu plnění uvedené v čl. II. odst. písm. 1(d), (e) (dále jen „Druhá fáze plnění“). O ukončení Druhé fáze plnění bude provedeno akceptační řízení a bude podepsán Akceptační protokol, jehož vzor tvoří Přílohu č. 11 této Smlouvy (dále jen „Akceptační protokol Migrace a Školení“), přičemž případné výhrady uvedené v Akceptačním protokolu Migrace a Školení se Poskytovatel zavazuje odstranit neodkladně, nejpozději do pěti (5) pracovních dnů od jeho podpisu. Po odstranění případných výhrad Smluvní strany sepíší nový Akceptační protokol Migrace a Školení k Druhé fázi plnění bez výhrad.

10.3. Za podmínky podepsání Předávacích protokolů a Akceptačních protokolů k První fázi plnění a Druhé fázi plnění bez výhrad, bude zahájena třetí fáze plnění, spočívající v poskytování dílčí části Předmětu plnění uvedené v čl. II. odst. 1(f) Technická Podpora a odst. 1 (g) Servisní podpora (dále jen „Třetí fáze plnění“). O realizaci třetí fáze bude vystaven Protokol o poskytnutém dílčím plnění Technické podpory (Příloha č. 12) a Servisní podpory (Příloha č. 13) (dále společně také jen „Podpora“) dle čl. II. odst. 1.(f) a 1. (g) a dle čl. III. odst. 13 za každé ukončené kalendářní čtvrtletí účinnosti této Smlouvy (dále jen „Čtvrtletní protokol“), obsahující přesný seznam úkonů Podpory, poskytnutých v rámci plnění této Smlouvy v daném čtvrtletí. Ve Čtvrtletním protokolu Poskytovatel uvede postup při poskytování Podpory podle této Smlouvy a jejích Příloh č. 6 a 7 a rozpis jednotlivých položek poskytované Podpory, včetně jejich popisu a vynaloženého času. Čtvrtletní protokol bude vyhotoven v listinné nebo elektronické podobě dle požadavku Objednatele, bude obsahovat podpis Poskytovatele, a po jeho schválení bude podepsán též Oprávněnou osobou Objednatele. Objednatel se zavazuje vyjádřit se k Čtvrtletnímu protokolu, tedy schválit a podepsat jej, resp. uvést k němu své připomínky, bez zbytečného odkladu po jeho obdržení.

10.4. V případě požadavku Objednatele na poskytnutí dílčího plnění dle čl. II. odst. 1(h) Rozšíření kdykoliv v průběhu trvání této Smlouvy, se bude jednat o čtvrtou fázi plnění (dále jen „Čtvrtá fáze plnění“). V případě poskytování Čtvrté fáze plnění bude postupováno analogicky dle odst. 10.1. a 10.3. tohoto článku.

11) První a Čtvrtá fáze plnění budou probíhat v pracovní době Objednatele, která je od pondělí do pátku od 8.00 hod. do 18.00 hod. (dále jen „Pracovní doba“). Za pracovní dny se nepovažují soboty, neděle a státem uznané svátky.

12) Druhá fáze plnění bude probíhat v místě a době definované Objednatelem, která může být v režimu 24 hodin 7 dní v týdnu a to na základě požadavku Objednatele, který Poskytovatel obdrží nejpozději 48 hodin před požadovaným plněním prostřednictvím e-mailu.

13) Třetí fáze plnění bude probíhat non-stop (režim 24 hodin denně a 7 dní v týdnu) na základě požadavku Objednatele. Poskytovatel se zavazuje, že po celou dobu trvání Druhé a Třetí fáze plnění bude Objednateli k dispozici na telefonním čísle 251 081 731 a na adrese elektronické pošty xxxxxxx@xxxx.xx. Poskytovatel potvrdí nahlášení problému a při řešení problému postupuje v termínech zakotvených v Příloze č. 6 této Smlouvy.

14) Okamžikem podpisu Předávacího protokolu oběma Smluvními stranami dochází k převodu vlastnického práva k Předmětu plnění a k udělení licenčního oprávnění k Předmětu plnění ve prospěch Objednatele.

15) Předmět plnění musí vyhovovat bezpečnostním standardům, jejichž použití je obvyklé u obdobných produktů, a musí svou technickou úrovní odpovídat zadávacím podmínkám Objednatele v oblasti bezpečnosti a provozu informačních a komunikačních technologií a závazným i doporučujícím technickým a bezpečnostním normám platným v České republice.

IV. POVINNOSTI OBJEDNATELE

1) Objednatel se zavazuje za řádné a včasné poskytnutí Předmětu plnění uhradit Poskytovateli smluvní cenu ve výši a způsobem uvedeným v článku VI. této Smlouvy.

2) Objednatel se zavazuje poskytovat Poskytovateli řádně a včas maximální potřebnou součinnost, která je nezbytná pro řádné a včasné plnění povinností Poskytovatele podle této Smlouvy.

3) Objednatel je povinen umožnit Poskytovateli přístup na Místa plnění dle článku III. odst. 1. této Smlouvy. Současně Objednatel dohodne s Poskytovatelem rozsah jeho oprávnění ke vstupu a vjezdu do Míst plnění.

4) Objednatel se zavazuje vyjadřovat se bez zbytečného odkladu k požadavkům Poskytovatele předkládaným v průběhu realizace plnění této Smlouvy a je povinen předávat každý svůj požadavek k poskytování Technické a servisní podpory dle této Smlouvy pomocí komunikačních kanálů uvedených čl. III odst. 13 této Smlouvy.

5) Objednatel je povinen potvrdit řádné předání a poskytnutí Předmětu plnění formou jednotlivých protokolů, vztahujících se ke konkrétnímu dílčímu plnění.

V. POVINNOSTI POSKYTOVATELE

1) Poskytovatel je povinen zejména:

(a) řádně plnit Předmět plnění ve lhůtách a rozsahu stanovém touto Smlouvou;

(b) poskytovat plnění dle této Smlouvy s vynaložením odborné péče a znalostí.

2) Poskytovatel se zavazuje, že poskytování Předmětu plnění bude svou technickou úrovní odpovídat zadávacím podmínkám Objednatele v oblasti bezpečnosti a provozu informačních a komunikačních technologií.

3) Poskytovatel je povinen po řádném provedení Předmětu plnění předložit Objednateli k podpisu jednotlivé protokoly vztahující se ke konkrétnímu dílčímu plnění.

4) Poskytovatel se zavazuje, že jeho zaměstnanci budou při plnění této Smlouvy dodržovat veškeré obecně závazné právní předpisy České republiky, vztahující se k vykonávané činnosti, a budou se řídit organizačními pokyny Oprávněných osob Objednatele.

VI. CENOVÉ A PLATEBNÍ PODMÍNKY

1) Cena za Předmět plnění poskytnutý dle podmínek této Smlouvy se člení na Dílčí ceny za celé období trvání této Smlouvy jednotlivé části Předmětu plnění následovně:

1.1 DISKOVÁ POLE	Počet kusů	Cena za 1 kus bez DPH	Celkem za počet kusů bez DPH
Primární diskové pole	2	7 525 132,00 Kč	15 050 264,00 Kč
Backup pole	1	8 606 198,00 Kč	8 606 198,00 Kč
SW licence	3	0,00 Kč	0,00 Kč
Celkem:		16 131 330,00 Kč	23 656 462,00 Kč
1.2 SAN switch	Počet kusů	Cena za 1 kus bez DPH	Celkem za počet kusů bez DPH
48-port SAN switch	8	344 002,00 Kč	2 752 016,00 Kč
SW licence	8	181 359,00 Kč	1 450 872,00 Kč
Celkem:		525 361,00 Kč	4 202 888,00 Kč
1.3 IMPLEMENTACE	Celek	Celkem za celek bez DPH
Implementace a integrace zakoupených diskových polí do stávajícího prostředí ICT MF	1	598 000,00 Kč	598 000,00 Kč
Implementace a integrace zakoupených SAN switchů do stávajícího prostředí ICT MF	1	130 000,00 Kč	130 000,00 Kč
Celkem:		728 000,00 Kč	728 000,00 Kč
1.4 TESTOVÁNÍ	Celek	Celkem za celek bez DPH
Testování	1	166 400,00 Kč	166 400,00 Kč
1.5 MIGRACE A ŠKOLENÍ	Celek	Celkem za celek bez DPH
Migrace dat ze starých diskových polí na nová pole	1	428 000,00 Kč	428 000,00 Kč
Školení v rozsahu 5 MD zaměřených na SAN technologie a školení v rozsahu 5 MD zaměřených na disková pole	1	265 000,00 Kč	265 000,00 Kč
Celkem:		693 000,00 Kč	693 000,00 Kč
1.6 TECHNICKÁ PODPORA	Počet kusů	Za 1 kus a 1 rok bez DPH	Celkem za 5 let bez DPH
Primární diskové pole	2	839 946,00 Kč	8 399 460,00 Kč
Backup pole	1	960 514,00 Kč	4 802 570,00 Kč
SW licence disková pole	3	0,00 Kč	0,00 Kč
48-port SAN switch	8	11 401,00 Kč	456 040,00 Kč
SW licence SAN switch	8	20 903,00 Kč	836 120,00 Kč
Celkem:		1 832 764,00 Kč	14 494 190,00 Kč

1.7 SERVISNÍ PODPORA	Počet MD za 5 let	Cena za 1 MD bez DPH	Celkem za 5 let bez DPH
Cena za 1 MD (8 hodin) servisní podpory.	25	12 000,00 Kč	300 000,00 Kč
Celkem:		12 000,00 Kč	300 000,00 Kč
1.8 ROZŠÍŘENÍ	Velikost 1 disku v TiB	Cena za kus bez DPH
Disk (včetně nutných licencí)	6,99	266 830,00 Kč
Technická podpora za 1 rok		24 305,00 Kč

2) Daň z přidané hodnoty bude účtována k Dílčím cenám v souladu se zákonem č. 235/2004 Sb.,

o dani z přidané hodnoty, ve znění pozdějších předpisů, ke dni uskutečnění zdanitelného plnění.

3) Výše uvedené Dílčí ceny jsou sjednány dohodou Smluvních stran podle zákona č. 526/1990 Sb.,

o cenách, ve znění pozdějších předpisů, a jsou cenami maximálními a nepřekročitelnými, které zahrnují veškeré náklady spojené s realizací Předmětu plnění (tj. včetně nákladů na dopravu do Míst plnění, datové nosiče, zajištění uznávaného elektronického podpisu, pojištění apod.).

4) Dílčí ceny budou hrazeny dle jednotlivých fází plnění uvedených v čl. III. odst. 10.1. – 10.4. na základě daňových dokladů (dále jen „Faktury“) následovně:

(a) za První fázi plnění (Předmět plnění uvedený v čl. II. odst. 1 písm. (a) – písm. (c)) bude Dílčí cena hrazena jednorázově na základě vystavené Faktury ve výši součtu Dílčí ceny uvedené v odst. 1 v tabulce bod 1.1 až 1.4 tohoto článku. Poskytovatel je oprávněn fakturovat Dílčí ceny nejdříve den následující po dni podpisu Předávacího a Akceptačního protokolu Objednatelem dle čl. III odst. 10.1. Kopie protokolů bude přílohou Faktury.

(b) za Druhou fázi plnění (Předmět plnění uvedený v čl. II. odst. 1 písm. (d), písm. (e)) bude Dílčí cena hrazena jednorázově ve výši Dílčí ceny uvedené v odst. 1 v tabulce bod 1.5 tohoto článku na základě vystavené Faktury. Poskytovatel je oprávněn fakturovat Dílčí cenu nejdříve den následující po dni podpisu Akceptačního protokolu Objednatelem. Kopie Akceptačního protokolu bude přílohou Faktury.

(c) za Třetí fázi plnění (Předmět plnění uvedený v čl. II. odst. 1 písm. (f) a písm. (g)) bude Dílčí cena hrazena čtvrtletně ve výši součtu jedné dvacetiny (1/20) Dílčí ceny („Celkem za 5 let bez DPH“) uvedené v odst. 1 v tabulce bod 1.6 tohoto článku a počtu MD dle ceny uvedené v odst. 1 v tabulce bod 1.7 tohoto článku na základě vystavené Faktury. Poskytovatel je oprávněn fakturovat Cenu nejdříve den následující po dni podpisu Čtvrtletního protokolu Objednatelem. Kopie Čtvrtletního protokolu bude přílohou Faktury. Smluvní strany se dohodly, že v případě neposkytování Servisní podpory po celý den, tj. 8 člověkohodin, se Cena za Člověkoden poměrně krátí.

(d) za Čtvrtou fázi plnění (Předmět plnění uvedený v čl. II. odst. 1 písm. (h)) bude Dílčí cena hrazena na základě vystavené Faktury u dodatečně dodaných disků analogicky dle odst. 4 písm. (a) tohoto článku a u podpory dodatečně dodaných disků analogicky dle odst. 4 písm.

5) Vystavená Faktura musí obsahovat:

(a) přesnou identifikaci Předmětu plnění podle této Smlouvy,

(b) uvedení Dílčí ceny,

(d) specifikace období, za které se fakturuje, pokud půjde o Fakturu na Cenu za Podporu,

(e) úplné bankovní spojení Poskytovatele, přičemž číslo účtu bude odpovídat číslu účtu uvedenému v záhlaví této Smlouvy a současně číslu účtu v registru plátců DPH, popř. řádně oznámenému číslu účtu postupem dle této Smlouvy

(f) veškeré náležitosti dle § 29 zákona č. 235/2004 Sb., o dani z přidané hodnoty, ve znění pozdějších předpisů,

(g) informace povinně uváděné na obchodních listinách na základě § 435 Občanského zákoníku.

6) Faktura je splatná do třiceti (30) dnů od doručení řádně vystavené Faktury Objednateli.

7) Objednatel má právo Fakturu Poskytovateli před uplynutím lhůty splatnosti vrátit, aniž by došlo k prodlení s její úhradou, obsahuje-li nesprávné náležitosti nebo údaje, chybí-li na faktuře některá z náležitostí nebo údajů nebo chybí-li originál řádného Protokolu nebo obsahuje jiné cenové údaje nebo jiný Předmět plnění než dohodnutý v této Smlouvě. Ode dne doručení opravené Faktury běží Objednateli nová lhůta splatnosti v délce třiceti (30) kalendářních dnů.

8) Platby budu probíhat výhradně v korunách českých a rovněž veškeré cenové údaje budou uvedeny v této měně. K platbě dojde bezhotovostně převodem na účet uvedený v záhlaví této Smlouvy a podle údajů na vystavené faktuře. Poskytovatel se zavazuje uvést na faktuře účet zveřejněný správcem daně způsobem umožňujícím dálkový přístup. V případě rozporu bankovních údajů uvedených na faktuře s bankovními údaji uvedenými v záhlaví této Smlouvy, mají přednost údaje uvedené v záhlaví této Smlouvy.

9) V roce, v němž je poskytován Předmět plnění, musí být všechny Faktury za předmětný rok doručeny Objednateli nejpozději do 19. 12., nedohodnou-li se Smluvní strany jinak. Objednatel nebude v prodlení, pokud Fakturu, doručenou v příslušném kalendářním roce po tomto datu, zaplatí do 28. 2. následujícího kalendářního roku. Poskytovatel bere toto na vědomí a výslovně souhlasí, že v takových případech není Objednatel v prodlení.

10) Smluvní strany se dohodly, že je-li Poskytovatel plátcem DPH a je v okamžiku uskutečnění zdanitelného plnění veden v rejstříku nespolehlivých plátců DPH, anebo nastane některá z jiných skutečností rozhodných pro ručení Objednatele, je Objednatel oprávněn zaplatit Poskytovateli pouze dohodnutou cenu bez DPH a DPH odvést příslušnému správci daně dle platných právních předpisů, nedohodnou-li se smluvní strany jinak. O provedené úhradě DPH správci daně bude Objednatel Poskytovatele informovat kopií oznámení pro správce daně dle §109a zákona č. 235/2004 Sb. o dani z přidané hodnoty, ve znění pozdějších předpisů, bez zbytečného odkladu.

VII. SANKCE A NÁHRADA ŠKODY

1) V případě nedodržení lhůty v čl. III. odst. 2 této Smlouvy stanovené ve dnech ze strany Poskytovatele je Objednatel oprávněn požadovat smluvní pokutu ve výši 200.000,- Kč (slovy: dvě stě tisíc korun českých) za každý, byť započatý, den prodlení.

2) V případě nedodržení lhůt v čl. III. odst. 3 této Smlouvy stanovené pro Migraci ve dnech ze strany Poskytovatele je Objednatel oprávněn požadovat smluvní pokutu ve výši 30.000,- Kč (slovy: třicet tisíc korun českých) za každý, byť i započatý den prodlení a za každé takové porušení.

3) V případě nedodržení lhůt v čl. III. odst. 3 této Smlouvy stanovené pro Školení ve dnech ze strany Poskytovatele je Objednatel oprávněn požadovat smluvní pokutu ve výši 10.000,- Kč (slovy: deset tisíc korun českých) za každý, byť i započatý den prodlení a za každé takové porušení.

4) V případě nedodržení lhůt v Příloze č. 6 této Smlouvy stanovených v hodinách ze strany Poskytovatele (Vada kategorie A – Velmi kritická) je Objednatel oprávněn požadovat smluvní pokutu ve výši 100.000,- Kč (slovy: sto tisíc korun českých) za každou, byť i započatou hodinu prodlení a každé takové porušení.

5) V případě nedodržení lhůt v Příloze č. 6 této Smlouvy stanovených ve dnech ze strany Poskytovatele (Vada typu B – Kritická) je Objednatel oprávněn požadovat smluvní pokutu ve výši 1.000.000,- Kč (slovy: jeden milion korun českých) za každý, byť i započatý den prodlení a každé takové porušení. Pro Vady kategorie C až E je smluvní pokuta stanovena ve výši 100.000,- Kč (jedno sto tisíc korun českých) za každý, byť i započatý den prodlení a každé takové porušení.

6) V případě nedodržení lhůty k vypracování Exitového plánu dle čl. XIV odst. 3 této Smlouvy ze strany Poskytovatele je Objednatel oprávněn požadovat smluvní pokutu ve výši 10.000,- Kč (slovy: deset tisíc korun českých) za každý, byť i započatý den prodlení.

7) V případě, že Poskytovatel poruší některou z povinností vyplývajících z článku VIII. této Smlouvy, je Objednatel oprávněn požadovat úhradu smluvní pokuty ve výši 100.000,- Kč (slovy: jedno sto tisíc korun českých) za každý případ porušení.

8) Není-li stanoveno jinak, řídí se odpovědnost Smluvních stran příslušnými ustanoveními Občanského zákoníku.

9) Při nedodržení termínu splatnosti řádně vystavené Faktury Objednatelem je Poskytovatel oprávněn požadovat zaplacení úroku z prodlení ve výši stanovené platnými právními předpisy.

10) Smluvní pokuta je splatná ve lhůtě sedmi (7) kalendářních dnů od doručení písemné výzvy oprávněné Smluvní strany povinné Smluvní straně.

11) Zaplacením smluvní pokuty není dotčeno právo na náhradu škody, a to v plné výši.

12) Zaplacení smluvní pokuty nezbavuje dotčenou Smluvní stranu povinnosti splnit závazek utvrzený smluvní pokutou.

13) Jakákoliv ustanovení týkající se omezení výše či druhu náhrady škody se nepřipouští.

14) Škodu hradí škůdce v penězích, nežádá-li poškozený uvedení do předešlého stavu.

VIII. OCHRANA INFORMACÍ

1) Smluvní strany souhlasí s tím, že tato podepsaná Smlouva (včetně příloh), jakož i její text, může být v elektronické podobě zveřejněn v registru smluv, na internetových stránkách Objednatele, na profilu Objednatele ve smyslu ZZVZ, a dále v souladu s povinnostmi vyplývajícími z jiných právních předpisů, a to bez časového omezení. Objednatel se zavazuje, že tuto Smlouvu v souladu se zákonem č. 340/2015 Sb., o registru smluv, uveřejní v registru smluv.

2) Obě Smluvní strany se zavazují udržovat v tajnosti a znepřístupnit třetím osobám diskrétní informace (jak jsou vymezeny níže). Povinnost poskytovat informace podle zákona č. 106/1999 Sb., o svobodném přístupu k informacím, ve znění pozdějších předpisů, není tímto ustanovením dotčena.

3) Za diskrétní informace se považují veškeré následující informace:

(a) veškeré informace poskytnuté Smluvními stranami v souvislosti s plněním této Smlouvy;

(b) informace, na které se vztahuje zákonem uložená povinnost mlčenlivosti;

4) Povinnost zachovávat mlčenlivost uvedená v tomto článku se nevztahuje na informace:

(a) které je Objednatel povinen poskytnout třetím osobám podle zákona č. 106/1999 Sb.,

o svobodném přístupu k informacím, ve znění pozdějších předpisů;

(b) které jsou nebo se stanou všeobecně a veřejně přístupnými jinak, než porušením právních povinností ze strany Poskytovatele;

(c) u nichž je Smluvní strana schopna prokázat, že jí byly známy ještě před přijetím těchto informací od druhé Smluvní strany, avšak pouze za podmínky, že se na tyto informace nevztahuje povinnost mlčenlivosti z jiných důvodů;

(d) které budou Smluvní straně po uzavření této Smlouvy sděleny bez závazku mlčenlivosti třetí stranou, jež rovněž není ve vztahu k nim nijak vázána;

(e) jejichž sdělení vyžaduje jiný právní předpis.

5) Smluvní strany se zavazují, že nezpřístupní jakékoliv třetí osobě diskrétní informace druhé Smluvní strany bez jejího předchozího písemného souhlasu, a to v jakékoliv formě, a že podniknou všechny nezbytné kroky k zabezpečení těchto informací. Poskytovatel je povinen zabezpečit veškeré diskrétní informace Objednatele proti odcizení nebo jinému zneužití.

6) Poskytovatel se zavazuje, že diskrétní informace užije pouze za účelem plnění této Smlouvy. Jiná použití nejsou bez předchozího písemného svolení Objednatele přípustná.

7) Poskytovatel je povinen svého případného subdodavatele zavázat povinností mlčenlivosti a respektováním práv Objednatele nejméně ve stejném rozsahu, v jakém je v tomto závazkovém vztahu zavázán sám.

8) Trvání povinnosti mlčenlivosti podle tohoto článku je stanoveno na dobu neurčitou.

9) Za prokázané porušení ustanovení v tomto článku má druhá Smluvní strana právo požadovat náhradu takto vzniklé škody.

IX. PRÁVA DUŠEVNÍHO VLASTNICTVÍ

1) Předmětem plnění dle této Smlouvy je mimo jiné i poskytnutí licencí k softwarovým komponentům Sytému.

2) Poskytovatel prohlašuje, že poskytování Předmětu plnění bude bez právních vad, zejména nebude zatíženo žádnými právy třetích osob, z nichž by pro Objednatele vyplynul finanční nebo jakýkoliv jiný závazek ve prospěch třetí strany nebo která by jakkoliv omezovala užívání Předmětu plnění. V případě porušení tohoto závazku je Poskytovatel v plném rozsahu odpovědný za případné následky takového porušení, přičemž právo Objednatele na případnou náhradu škody a smluvní pokutu zůstává nedotčeno.

3) Poskytovatel se zavazuje, že při poskytování Předmětu plnění bude postupovat tak, aby nedošlo k neoprávněnému zásahu do autorských či licenčních práv třetích osob.

4) Poskytovatel poskytuje Objednateli právo k užívání software, jenž je součástí Předmětu plnění a k veškerým jeho budoucím verzím (dále jen „Licence“). Licence je poskytnuta jako místně neomezená, na celou dobu trvání autorských majetkových práv, ke všem způsobům užití, a to ode dne jeho předání Objednateli. Objednatel není povinen Licenci využít. Licence je udělena jako licence nevýhradní ve smyslu § 2361 Občanského zákoníku. Odměna za poskytnutí Licence dle tohoto článku je zahrnuta v Ceně dle čl. VI odst. 1. této Smlouvy.

X. ROZHODNÉ PRÁVO A ŘEŠENÍ SPORŮ

1) Xxxx Xxxxxxx se řídí právním řádem České republiky. V záležitostech touto Smlouvou neupravených se právní vztah mezi Smluvními stranami řídí Občanským zákoníkem.

2) Veškeré případné spory mezi Smluvními stranami, které by v budoucnu vyplynuly z této Smlouvy nebo v souvislosti s ní budou rozhodovány obecnými soudy České republiky.

XI. ZÁRUČNÍ PODMÍNKY

1) S ohledem na to, že Předmět plnění je svou podstatou zajištěním dodávky a poskytnutím služeb, záruční doba činí šedesát (60) měsíců a počíná běžet ve vztahu k jednotlivým částem Předmětu plnění okamžikem schválení příslušného Předávacího protokolu, Akceptačního protokolu či Čtvrtletního protokolu Objednatelem s výjimkou jednotlivých částí Předmětu plnění, u kterých byl příslušný protokol Objednatelem schválen ve čtyřicátém devátém (49) až šedesátém (60) měsíci. V takovém případě činí záruční doba dvanáct (12) měsíců a počíná běžet okamžikem schválení příslušného Předávacího protokolu, Akceptačního protokolu či Čtvrtletního protokolu Objednatelem.

2) V případě výskytu vady na Předmětu plnění v záruční době se bude postupovat analogicky dle Přílohy č. 6 - Specifikace Technické podpory.

3) Pokud Poskytovatel vady neodstraní ve lhůtě a způsobem uvedeným v odst. 2 tohoto článku, je Objednatel oprávněn odstranit vady sám nebo prostřednictvím třetích osob a požadovat po Poskytovateli úhradu nákladů účelně vynaložených v souvislosti s odstraňováním vad. Uplatněním práva podle tohoto článku není dotčeno právo Objednatele na odstoupení od této Smlouvy.

4) V případě prodlení Poskytovatele s plněním práv Objednatele z vad je Poskytovatel povinen uhradit Objednateli smluvní pokutu dle čl. VII. této Smlouvy.

5) Poskytovatel je povinen vady odstranit opravou, opětovným provedením nebo jiným způsobem stanoveným právními předpisy, a to podle volby Objednatele.

6) Objednatel je oprávněn uplatnit vady u Poskytovatele kdykoliv během záruční doby bez ohledu na to, kdy Objednatel takové vady zjistil nebo mohl zjistit. Pro vyloučení pochybností se sjednává, že převzetím jednotlivých částí Předmětu plnění není dotčeno právo Objednatele uplatňovat práva z vad, které byly zjistitelné, ale nebyly zjištěny při převzetí.

7) Právy vyplývajícími z tohoto článku nejsou dotčena ani omezena práva Objednatele vůči Poskytovateli z vadného plnění vyplývající z právních předpisů.

XII. OPRÁVNĚNÉ OSOBY

1) Každá ze Smluvních stran je povinna jmenovat osobu oprávněnou jednat ve věcech této Smlouvy (dále jen „Oprávněné osoby“).

2) Oprávněné osoby nejsou zmocněny k jednání, jež by mělo za přímý následek změnu nebo ukončení této Smlouvy nebo změnu jejího předmětu.

3) Smluvní strany jsou oprávněny změnit Oprávněné osoby i bez nutnosti uzavření dodatku k této Smlouvě, jsou však povinny na takovou změnu druhou Smluvní stranu písemně prokazatelně upozornit. Změna Oprávněných osob je účinná dnem prokazatelného doručení oznámení druhé Smluvní straně, není-li v oznámení uvedeno datum pozdější.

4) Smluvní strany se dohodly na dále uvedených Oprávněných osobách, které budou za Smluvní strany jednat ve věcech obchodních, technických, ekonomických a kybernetické bezpečnosti:

Za Objednatele:

Ve věcech obchodních a ekonomických: Jméno: xxxxxxxxxx

tel.: xxxxxxxxxx

e-mail: xxxxxxxxxx

Ve věcech technických:

Jméno: xxxxxxxxxx

tel.: xxxxxxxxxx

e-mail: xxxxxxxxxx

Ve věcech kybernetické bezpečnosti: Jméno: xxxxxxxxxx

tel.: xxxxxxxxxx

e-mail: xxxxxxxxxx

Za Poskytovatele:

Ve věcech obchodních:

Jméno: xxxxxxxxxx

tel.: xxxxxxxxxx

e-mail: xxxxxxxxxx

Ve věcech technických:

Jméno: xxxxxxxxxx

tel.: xxxxxxxxxx

e-mail: xxxxxxxxxx

Ve věcech zajištění technické a servisní podpory:

1. Jméno: xxxxxxxxxx

tel.: xxxxxxxxxx

e-mail: xxxxxxxxxx

2. Jméno: xxxxxxxxxx

tel.: xxxxxxxxxx

e-mail.: xxxxxxxxxx

XIII. DOBA TRVÁNÍ a UKONČENÍ SMLOUVY

1) Xxxx Xxxxxxx se uzavírá na dobu určitou uvedenou v čl. III. odst. 4 této Smlouvy.

2) Smluvní vztah založený touto Smlouvou lze ukončit před termínem uvedeným v odst. 1. tohoto článku písemnou dohodou obou Smluvních stran a dalšími způsoby stanovenými právními předpisy.

3) Objednatel je oprávněn tuto Smlouvu vypovědět bez udání důvodu. Výpovědní doba činí dvanáct

(12) měsíců a začíná běžet prvním dnem měsíce následujícího po měsíci, ve kterém bylo písemné vyhotovení výpovědi prokazatelně doručeno Poskytovateli.

4) Smluvní strany jsou oprávněny odstoupit od této Smlouvy z důvodů uvedených v této Smlouvě a dále z důvodů uvedených v zákoně, zejména v případě podstatného porušení této Smlouvy.

5) Objednatel je mimo jiné oprávněn od této Smlouvy odstoupit v následujících případech:

(a) bude rozhodnuto o likvidaci Poskytovatele;

(b) Poskytovatel podá insolvenční návrh jako dlužník a bude následně rozhodnuto o úpadku Poskytovatele nebo bude ve vztahu k Poskytovateli vydáno jiné rozhodnutí s obdobnými účinky;

6) Za podstatné porušení této Smlouvy Poskytovatelem, které je důvodem pro odstoupení od této Smlouvy ze strany Objednatele, se považuje zejména:

(a) prodlení Poskytovatele s dodáním předmětu plnění o více jak čtyřicetpět (45) kalendářních dní po termínu plnění;

(b) porušení povinnosti Poskytovatele odstranit vady předmětu plnění ve lhůtě třiceti (30) kalendářních dní od jejich oznámení Objednatelem;

(c) porušení povinnosti Poskytovatele odstranit výhrady uvedené v Akceptačním protokolu ve stanovené lhůtě třiceti (30) kalendářních dní dle čl. III. odst. 10.1. této Smlouvy;

(d) realizace předmětu této Smlouvy v rozporu s touto Smlouvou či právními předpisy;

(e) nedodržování jiných závazných dokumentů či předpisů Poskytovatelem,

(f) jiné porušení povinností Poskytovatele, které nebude odstraněno ani do třiceti (30) kalendářních dní od prokazatelného doručení výzvy Objednatele.

7) Za podstatné porušení této Smlouvy Objednatelem, které je důvodem pro odstoupení od této Smlouvy ze strany Poskytovatele, se považuje:

(a) prodlení Objednatele s úhradou Faktury – daňového dokladu o více jak třicet (30) kalendářních dní, přičemž nárok na úrok z prodlení není tímto ustanovením dotčen;

(b) prodlení Objednatele s poskytnutím součinnosti o více než třicet (30) kalendářních dní od prokazatelného doručení písemné výzvy Poskytovatele.

8) V případě odstoupení podle odst. 6 písm. a), b), c) či f) tohoto článku je po marném uplynutí příslušné lhůty Objednatel oprávněn od této Smlouvy jednostranně odstoupit, a to bez jakýchkoliv sankcí ze strany Poskytovatele.

9) Odstoupení od této Smlouvy musí být písemné a musí v něm být uveden odkaz na ustanovení této Smlouvy či právních předpisů, které zakládá oprávnění od této Smlouvy odstoupit.

10) Smluvní vztah skončí dnem doručení oznámení o odstoupení od této Smlouvy druhé Smluvní straně, nebo dnem uvedeným v oznámení.

11) Odstoupení od této Smlouvy či jiné ukončení smluvního vztahu založeného touto Smlouvou se nedotýká práva na zaplacení smluvní pokuty nebo úroku z prodlení, pokud již dospěl, práva na náhradu škody, ujednání o mlčenlivosti a ochraně informací ani ujednání, které má vzhledem ke své povaze zavazovat Smluvní strany i po odstoupení od této Smlouvy, zejména ujednání

o způsobu řešení sporů.

XIV. KYBERNETICKÁ BEZPEČNOST A SOUVISEJÍCÍ POVINNOSTI

1) Poskytovatel se zavazuje při plnění této Smlouvy postupovat v souladu se zákonem č. 181/2014 Sb., o kybernetické bezpečnosti a o změně souvisejících zákonů (zákon o kybernetické bezpečnosti), v platném znění (dále též „ZoKB“), jakož i v souladu se souvisejícími prováděcími předpisy.

2) Poskytovatel se zavazuje v průběhu plnění této Smlouvy písemně upozornit Objednatele na případný zjištěný nesoulad plnění dle článku II této Smlouvy a s povinnostmi definované ZoKB a případné nedostatky zjištěné auditem kybernetické bezpečnosti.

3) Poskytovatel bere na vědomí, že Předmět plnění dle této Smlouvy může souviset s užitím, správou, či rozvojem Kritické informační infrastruktury ve smyslu ustanovení § 2 písm. b) ZoKB.

4) V případě kybernetického bezpečnostního incidentu (dále též „KBI“) vzniklého na Předmětu plnění dle této Smlouvy, se Poskytovatel zavazuje tento KBI neprodleně oznámit Objednavateli, a následně pracovat na jeho odstranění s cílem uvést Předmět plnění dle této Smlouvy do stavu s užitím, správou, či rozvojem Kritické informační infrastruktury ve smyslu ustanovení

§ 2 písm. b) ZoKB bez rizika vzniku KBI a to vše na vlastní náklady. Poskytovatel informuje Objednavatele o odstranění nahlášeného KBI a sepíše akceptační protokol (viz. Příloha č. 12 – Čtvrtletní protokol o poskytnuté technické podpoře), o odstranění KBI, který bude obsahovat mimo jiné popis závady, případně důvod jejího vzniku, způsob odstranění závady, a po tom, co Objednatel akceptuje, že je závada kompletně odstraněna, podpisy Poskytovatele a Objednatele, přičemž Objednatele bude ve věcech kybernetické bezpečnosti zastupovat Manažer kybernetické bezpečnosti Ministerstva financí, který bude Poskytovateli písemně sdělen do 3 pracovních dnů od podpisu této Smlouvy. Poskytovatel se zavazuje umožnit Objednateli provést kontrolu procesu odstraňování KBI a vypořádat se s případnými připomínkami Objednatele k procesu odstraňování KBI.

5) Kontrola zavedení a užití bezpečnostních opatření a procesů:

(a) Poskytovatel se na výzvu zavazuje umožnit Objednateli provedení kontroly v rozsahu zavedení a realizace bezpečnostních opatření, jejichž zavedení a užití je vyžadováno ZoKB, prováděcími předpisy k tomuto zákonu. Výzva na Poskytovatele bude zaslána minimálně 1 měsíc před první takovou kontrolou. První kontrola proběhne po dodávce diskových polí, SAN switchů a zajištění technické a servisní podpory. Druhá a popřípadě další kontroly mohou následovat v intervalu maximálně 12 – ti měsíců. Poskytovatel v této věci poskytne Objednateli, nebo jím určené třetí straně, nutnou součinnost. Z kontroly vyhotoví Objednavatel dokument s názvem „Zápis z kontroly Poskytovatele“ (dále též „Zápis“).

(b) Při každé kontrole bude vždy přihlédnuto k rozsahu plnění dle této Smlouvy.

(c) Pokud bude během kontroly zjištěno, že Poskytovatel, v některé předepsané oblasti, nesplňuje povinné náležitosti, tj. bezpečnostní organizační a technická opatření nejsou zavedena nebo užita, nebo jsou zavedena či užita v nedostatečném rozsahu, je tato skutečnost zapsána do Zápisu Seznamu zásahů (Příloha č. 12 – Čtvrtletní protokol o poskytnuté technické podpoře). Objednavatel v Zápisu stanoví závazný termín pro jejich nápravu. Při určení tohoto termínu bude vždy přihlédnuto k povaze bezpečnostního opatření, které není zavedeno či užito, nebo je zavedeno či užito v nedostatečném rozsahu. Překročení tohoto termínu bude posuzováno podle čl. VII odst. 4) a 5), v opakovaném případě podle čl. VII odst. 4) a 5) této Smlouvy.

(d) Jmenovitě se jedná o tyto kontrolované oblasti a bezpečnostní opatření v prostředí Poskytovatele nebo související s Předmětem plnění dle této Smlouvy:

• Existence a rozsah bezpečnostních politik a bezpečnostní dokumentace;

• Zavedení procesů organizační bezpečnosti včetně zavedení bezpečnostních rolí;

• Zavedení procesů řízení dodavatelů v souladu s Přílohou č. 7 vyhlášky č. 82/2018

o kybernetické bezpečnosti;

• Zavedení procesů bezpečnosti lidských zdrojů včetně doložení stavu bezpečnostního povědomí pracovníků Poskytovatele a plán jeho dalšího rozvoje;

• Zavedení procesů a nástroje pro řízení přístupu na základě předaných přístupových oprávnění od Objednatele;

• Zavedení procesů zvládání kybernetických bezpečnostních událostí a incidentů;

• Zavedení procesů a nasazení nástroje pro řízení změn včetně zpracování incidentů, servisních požadavků, problémů či změnových požadavků;

• Zavedení procesů řízení kontinuity činností včetně zavedení procesů a nasazení

nástroje pro zajištění úrovně dostupnosti informací (zálohování, plán a principy testování obnovy dat);

• Nasazení nástroje a procesů pro správu a ověřování identit pracovníků Poskytovatele (koncových uživatelů i administrátorů) včetně nasazení nástroje a souvisejících procesů pro řízení přístupových oprávnění a ověření, zda daný pracovník Poskytovatele disponuje právě těmi právy, která jsou nutná pro jeho pracovní zařazení;

• Nasazení a provoz nástroje pro ochranu před škodlivým kódem, antivirové kontroly a implementace antimalwaru a antispywaru na koncových zařízeních Poskytovatele;

6) Poskytovatel akceptuje, že veškeré náklady, které mu v průběhu plnění dle této Smlouvy, v souvislosti s výše uvedenými kontrolami, zavedením a plněním požadavků dle ZoKB či užitím definovaných bezpečnostních opatření vzniknou, jsou plně k jeho tíži.

7) Seznam vyžadovaných bezpečnostních opatření se může měnit buď v souvislosti se změnou povahy a rozsahu plnění dle této Smlouvy nebo v návaznosti na povinnosti Objednatele vyplývající z § 13 ZoKB. Pokud Národní úřad pro kybernetickou a informační bezpečnost (dále též „NÚKIB“) Objednateli uloží povinnost, v návaznosti na výskyt kybernetické bezpečnostní události či incidentu, zavést či užívat určité bezpečnostní opatření, dotýká-li se toto jakkoliv povahy či rozsahu plnění dle této Smlouvy, má Poskytovatel povinnost toto bezpečnostní opatření zavést či užívat, nebo Objednateli poskytnout nutnou součinnost.

XV. EXITOVÝ PLÁN

1) Poskytovatel se zavazuje při ukončení této Xxxxxxx poskytnout Objednateli veškerou potřebnou součinnost, dokumentaci a informace, účastnit se jednání s Objednatelem a popřípadě třetími osobami určenými Objednatelem za účelem plynulého a řádného převedení činností spojených s poskytováním Předmětu plnění dle této Smlouvy na Objednatele nebo nového dodavatele, ke kterému dojde po skončení účinnosti této Smlouvy (dále jen „Exit“)

2) Za tímto účelem se Poskytovatel zavazuje ve lhůtách, uvedených v následujícím odstavci vypracovat na základě pokynu Objednatele dokumentaci vymezující postup provedení Exitu (dále je „Exitový plán“), a poskytnout plnění nezbytná k realizaci tohoto Exitového plánu za přiměřeného použití vhodných ustanovení této Smlouvy. Povinnost dle tohoto ustanovení platí i po uplynutí doby trvání této Smlouvy, a to nejdéle jeden rok po jejím ukončení.

3) Objednatel je oprávněn požádat Poskytovatele o vypracování Exitového plánu nejdříve dvanáct

(12) měsíců před řádným ukončením účinnosti této Smlouvy, kdykoliv spolu s odstoupením Objednatele od této Smlouvy, nebo i po odstoupení Poskytovatele od této Smlouvy. Poskytovatel se zavazuje vypracovat Exitový plán a poskytnout plnění nezbytná k jeho realizaci do jednoho

(1) měsíce od doručení takového požadavku Objednatele, nestanoví-li Objednatel jinak. Vypracováním Exitového plánu se rozumí jeho schválení Objednatelem. Cena vypracování Exitového plánu se stanoví dle výše ceny MD za Servisní podporu, uvedené v čl. 1.7. této Smlouvy a počtu MD, potřebných k vypracování Exitového plánu. Celková cena Exitového plánu musí být předem schválena Objednatelem a nesmí přesáhnout 90 000 Kč včetně DPH.

4) Detailní specifikace Exitového plánu je uvedena v Příloze č. 15 této Smlouvy.

XVI. ZÁVĚREČNÁ USTANOVENÍ

1) Tato Smlouva obsahuje úplnou dohodu Smluvních stran ve věci předmětu této Smlouvy a nahrazuje veškeré předešlé písemné či ústní dohody učiněné ve věci předmětu této Smlouvy.

2) Pokud by se kterékoliv ustanovení této Smlouvy ukázalo být neplatným nebo nevynutitelným, nebo se jím stalo po uzavření této Smlouvy, pak tato skutečnost nepůsobí neplatnost ani

nevynutitelnost ostatních ustanovení této Smlouvy, nevyplývá-li z donucujících ustanovení právních předpisů jinak. Smluvní strany se zavazují bez zbytečného odkladu po výzvě kterékoliv Smluvní strany takové neplatné či nevynutitelné ustanovení nahradit platným a vynutitelným ustanovením, které je svým obsahem nejbližší účelu neplatného či nevynutitelného ustanovení.

3) Žádná ze Smluvních stran nemůže bez předchozího písemného souhlasu druhé Smluvní strany postoupit svá práva a povinnosti plynoucí z této Smlouvy třetí straně, a to ani částečně.

4) Jakékoliv úkony směřující ke zrušení této Smlouvy a oznámení o změně bankovních údajů musí být doručeny datovou schránkou nebo formou doporučeného dopisu. Oznámení nebo jiná sdělení podle této Smlouvy se budou považovat za řádně učiněná, pokud budou učiněna písemně v českém jazyce a doručena osobně, poštou, prostřednictvím datové schránky či kurýrem na adresy uvedené v tomto odstavci (včetně označení jménem příslušné Oprávněné osoby) nebo na jinou adresu, kterou příslušná Smluvní strana v předstihu písemně oznámí adresátovi, není-li v konkrétním případě stanoveno jinak.

(a) Objednatel:

Název: Ministerstvo financí

Adresa: Xxxxxxxx 00, Xxxxx 0 000 10

k rukám: jméno Oprávněné osoby Objednatele Datová schránka: xxxxxxx

(b) Poskytovatel:

Název: GAPP System, spol. s r.o.

Adresa: Petržílkova 2565/23, 158 00 Praha 5

k rukám: Xxx. Xxxx Xxxxxx Datová schránka: q5a7pm7

5) Účinnost oznámení nastává v pracovní den následující po dni doručení tohoto oznámení druhé Smluvní straně, není-li v této Smlouvě výslovně stanoveno jinak.

6) Ke změně této Smlouvy nebo ukončení této Smlouvy je za Objednatele oprávněn ředitel odboru

70 a dále osoby pověřené ministrem financí. Ke změně této Smlouvy nebo ukončení této Smlouvy je za Poskytovatele oprávněn Poskytovatel sám (je-li fyzickou osobou podnikající) nebo statutární orgán Poskytovatele, příp. prokurista, a to dle způsobu jednání uvedeném v obchodním rejstříku. Jiné osoby mohou tato právní jednání činit pouze s písemným pověřením osoby či orgánu vymezených v předchozí větě (dále jen „Oprávněné osoby pro věci smluvní“). Oprávněné osoby pro věci smluvní mají současně všechna oprávnění Oprávněných osob.

7) Jakékoliv změny kontaktních údajů, bankovních údajů a Oprávněných osob je příslušná Smluvní strana oprávněna provádět jednostranně a je povinna tyto změny neprodleně písemně oznámit druhé Smluvní straně.

8) Xxxx Xxxxxxx se řídí právními předpisy České republiky. Smluvní strany pro vyloučení pochybností sjednávají, že tato Xxxxxxx se řídí subsidiárně ustanoveními Občanského zákoníku upravujícími smlouvu o dílo a licenční smlouvu.

9) Změny nebo doplňky této Smlouvy včetně jejích příloh musejí být vyhotoveny písemně formou dodatku, datovány a podepsány oběma Smluvními stranami s podpisy Smluvních stran na jedné listině, ledaže tato Smlouva v konkrétních případech stanoví jinak.

10) Tato Smlouva je vyhotovena v 1 vyhotovení v českém jazyce s platností originálu s elektronickými podpisy obou Smluvních stran v souladu se zákonem č. 297/2016 Sb., o službách vytvářejících důvěru pro elektronické transakce, ve znění pozdějších předpisů.

11) Tato Smlouva nabývá platnosti dnem podpisu oběma Smluvními stranami a účinnosti okamžikem zveřejnění v registru smluv v souladu se zákonem č. 340/2015 Sb., zákon o registru smluv, ve znění pozdějších předpisů.

12) Nedílnou součástí této Smlouvy jsou její přílohy:

Příloha č. 1 – Specifikace dodávaného Hardware Disková pole včetně SW Příloha č. 2 – Specifikace dodávaného Hardware SAN switch včetně SW Příloha č. 3 – Specifikace Implementace

Příloha č. 4 – Specifikace Testování

Příloha č. 5 – Specifikace Migrace a Školení Příloha č. 6 – Specifikace Technické podpory Příloha č. 7 – Specifikace Servisní podpory

Příloha č. 8 – Specifikace požadovaného Rozšíření Diskového pole Příloha č. 9 – Předávací protokol

Příloha č. 10 – Akceptační protokol Implementace a Testování Příloha č. 11 – Akceptační protokol Migrace a Školení

Příloha č. 12 – Čtvrtletní protokol o poskytnuté Technické podpoře Příloha č. 13 – Čtvrtletní protokol o poskytnuté Servisní podpoře Příloha č. 14 – Specifikace DWDM technologie Objednatele Příloha č. 15 – Specifikace Exitového plánu

V Praze dne dle elektronického podpisu

Objednatel

Česká republika – Ministerstvo financí

xxxxxxxxxx, xxxxxxxxxx

Poskytovatel

GAPP System, spol. s r.o.

Xxx. Xxxx Xxxxxx, jednatel společnosti

Za finální znění k č.j. MF- 23875/2019/70: xxxxxxxxxx

Příloha č. 1 – Specifikace dodávaného Hardware Disková pole včetně SW

Dynamický nákupní systém na prostředky ICT v resortu Ministerstva financí - Výzva 1-2020

Požadavky objednatele		Nabídka poskytovatele
Parametr	Primární diskové pole (2 ks)	xxx
Diskové pole	Diskové pole bude dodáno uvnitř vlastní rackové skříně.	Splňuje ANO	xxx
	Redundatní napájení: připouští se možnost 3f nebo 1f připojení do celkového maximálního příkonu na rack 10kW.	Splňuje ANO	xxx
	Nabízené diskové pole musí zcela reflektovat doporučení výrobce pro konfiguraci a dimenzování (sizing - například disk, CPU, cache, porty, architektura, atd.).	Splňuje ANO
	Rozšiřitelnost: minimálně 100 TiB čisté kapacity za podmínek uvedených níže (ochrana RAID, Hot-spare, odpovídající typ a velikost disku) bez nutnosti dokupovat další police.	Splňuje ANO
	Nabízené disky musí být alespoň ze dvou serií a musí být rovnoměrně rozloženy napříč kapacitou. Kapacity a typ disků musí být vždy identické pro celou dodávanou kapacitu.	Splňuje ANO
	Všechny požadované a potřebné funkce musí být zalicencovány na celou kapacitu pole včetně případné redukce dat (např. komprese a deduplikace). (Týká se funkcionalit vyplývajících z Přílohy č. 2 Výzvy - Technická specifikace a Přílohy č. 3 Výzvy - Popis řešení).	Splňuje ANO
Flash Tier	Čistá využitelná kapacita odpovídající RAID 6 (6+2) bez započtení vlivu komprese a deduplikace minimálně 250 TiB (Do kapacity se nezapočítávají hot-spare disky).	Splňuje ANO	xxx

Požadavky objednatele		Nabídka poskytovatele
Parametr	Primární diskové pole (2 ks)	xxx
	Čas obnovy vadného disku při dané ochraně dat maximálně do 16 hodin (viz Příloha č. 4 sml. - Specifikace Testování).	Splňuje ANO
	Raid parita: RAID 6 nebo ekvivalentní zabezpečení proti havarii disků (v uspořádání například 6+2 nebo 8+2) + hotspare (Jiné paritní systémy či zabezpečení typu DualParity či Erasure Coding se pro výkonnostní tier nepřipouští).	Splňuje ANO	xxx
	Typ média: Enterprise SSD nebo Flash o odpovídající úrovni (spotřební technologie typu cMLC se nepřipouštějí).	Splňuje ANO	xxx
	Výrobce udává živostnost média s plným výkonem po dobu plánované životnosti diskového pole, tzn. 5 let. Vadné disky zůstávají vždy v majetku Zadavatele a v případě výměny je Zadavatel nevrací.	Splňuje ANO	xxx
	Počet pracovních médií Flash Tieru: minimálně 32.	Splňuje ANO	xxx
	Počet spare disků Flash Tieru: minimálně 1 Hotspare disk na každých 10 započatých pracovních disků.	Splňuje ANO	xxx
	Vyžadují se dedikované Globální HotSpare disky (HS disk musí v rámci rebuildu nahradit libovolný vadný disk v rámci nabízeného diskového pole). V případě ekvivalentního řešení zabezpečení RAID musí být nabídnut odpovídající počet HS disků, který se nebude započítávat do dodávané kapacity diskového pole. Stále ale platí předcházející požadavek.	Splňuje ANO	xxx
	Výrobcem garantovaná úroveň redukce (např. komprese a deduplikace) dat minimálně v poměru 1,8:1. Struktura dat je uvedena v Příloze č. 3 VÝzvy - Popis řešení. Z nich 20 % tvoří data nekomprimovatelná.	Splňuje ANO	xxx
	Online komprese ukládaných dat, efektivní pro všechny datové struktury (Řešení pracující jen s řetězci opakujících se znaků se nepřipouští).	Splňuje ANO

Požadavky objednatele		Nabídka poskytovatele
Parametr	Primární diskové pole (2 ks)	xxx
	Online deduplikace ukládaných dat, efektivní pro všechny datové struktury (Řešení pracující jen s řetězci opakujících se znaků se nepřipouští).	Splňuje ANO
	Požadované funkce komprese,deduplikace a replikace dat musí být možné použít na libovolném LUN současně. Funkce se nesmí vzájemně vylučovat či omezovat.	Splňuje ANO
	Vybydlení paměťových buněk SSD/Flash média je považováno za vadu, která musí být odstraněna v rámci záruky.	Splňuje ANO
Architektura kontrolerů	Diskové pole musí být plně all-flash, veškerá kapacita musí být realizována prostřednictvím SSD či Flash disky.	Splňuje ANO
	Při výpadku nebo ugrade jednoho kontroleru nesmí dojít k degradaci požadovaného výkonu diskového pole o více než 25%. Požadovaným výkonem se rozumí výkon, který je požadován v rámci této VZ (viz Příloha č. 4 sml. - Specifikace Testování). Každý LUN je plně přístupný pro čtení i zápis přes libovolný kontroler (Řešení typu ALUA či federace řadičů se nepřipouští).	Splňuje ANO	xxx
	Výpadek nebo upgrade jednoho z kontrolerů nesmí způsobit pád nebo failover pole (nesmí dojít k SPOF na úrovni řadičů) a nesmí dojít k nedostupnosti žádného LUN.	Splňuje ANO

Požadavky objednatele		Nabídka poskytovatele
Parametr	Primární diskové pole (2 ks)	xxx
	Pole musí umožňovat online upgrade firmware kontrolerů. Uživatel musí mít možnost zvolit si, kdy dojde k načtení nového firmware a s ním spojeným restartem kontroléru. Během upgradu firmware nesmí dojít k nedostupnosti žádné IO cesty.	Splňuje ANO
	Pole musí umožňovat minimálně RAID 6, RAID 5, RAID 10 nebo ekvivalentní zabezpečení proti havarii disků.	Splňuje ANO	xxx
	Rozšiřitelnost čisté využitelné kapacity pole: min. 1PiB.	Splňuje ANO	xxx
	Diskové pole musí obsahovat řízení kvality služeb QoS minimálně na úrovni IOPs a MB/s.	Splňuje ANO	xxx
Konektivita	FrontEnd konektivita diskového pole musí být Fibre Channel minimálně 512 Gbps.	Splňuje ANO	xxx
	Počet Fibre Channel portů: musí být osazeno minimálně 32x-krát o rychlosti minimálně 16 Gbps typu LC, plně kompatibilní s dodávanou SAN infrastrukturou.	Splňuje ANO
	Licence: Libovolný port může plnit libovolnou roli, tj. Front-End port, Replikační zdroj/target.	Splňuje ANO

Požadavky objednatele		Nabídka poskytovatele
Parametr	Primární diskové pole (2 ks)	xxx
Provisioning	Pole musí podporovat technologii tenkého provisioningu.	Splňuje ANO
	Pole musí obsahovat nástroje pro reklamaci prázdných (tj. nulami obsazených) datových stránek.	Splňuje ANO
	Požadovaný Typ licence pro tenký provisioning: minimálně na dodanou kapacitu pole.	Splňuje ANO
Cache	Cache s bezúdržbovou ochranou paměti při výpadku elektřiny po dobu než dojde k uložení do pro cache dedikované permanentní paměti. Pokud řešení neumožňuje uložení cache do permanentní paměti, musí dodavatel doplnit řešení o zdroj nepřerušitelného napájení s kapacitou a výkonem, který umožní provoz po dobu minimálně 48 hodin. Takovýto zdroj nepřerušitelného napájení musí být v architektuře N+N tedy bez tzv. single point of failure (SPOF).	Splňuje ANO	xxx
	Do kapacity diskového pole se započítává pouze ta kapacita, která je určena pouze pro ukládání dat. Například emulace cache pomocí SSD/Flash je přípustná, ale nezapočítává se do požadované kapacity diskového pole ani do kapacity cache v rámci této VZ. Velikost cache musí odpovídat doporučení výrobce pro daný typ diskového pole, jeho užití a požadovanému výkonu.	Splňuje ANO	xxx
	V případě výpadku napájení nesmí minimálně po dobu 48 hodin dojít ke ztrátě dat uložených v cache a nezapsaných do disků	Splňuje ANO
	V případě výpadku jednoho řadiče nesmí dojít ke ztrátě ochrany dat uložených v cache a to zejména pro zápis.	Splňuje ANO	xxx
	Minimální velikost využitelné cache paměti 128 GB nebo dle doporučení výrobce. Velikost cache musí zároveň odpovídat pořadovaným vlastnostem a výkonu požadovaného diskového pole.	Splňuje ANO	xxx

Požadavky objednatele		Nabídka poskytovatele
Parametr	Primární diskové pole (2 ks)	xxx
Snapshoty a klony	Diskové pole musí umožňovat tvorbu snapshotů a klonů.	Splňuje ANO
	Je požadováno, aby bylo možné tvořit snapshot ze snapshotu, tzn. kaskádovat více snímků po sobě.	Splňuje ANO	xxx
	Je požadován možný rollback až 24 hodin zpětně v kroku nejvýše 5 minut. Například z jednoho Root LUNu musí být možnost automaticky vytvořit minimálně 256 snapshotů v kaskádě.	Splňuje ANO	xxx
	Je požadováno, aby bylo možno kterýkoliv snapshot i v rámci kaskády zkonvertovat na klon. Z tohoto klonu musí být možná tvorba snapshotů.	Splňuje ANO	xxx
	Pole musí plně podporovat VAAI pro VMware - vSphere, přičemž integrační software musí být součástí dodávky.	Splňuje ANO	xxx
	Požadovaný typ licence Snapshoty a klony: minimálně na dodanou kapacitu pole, read-only i read-write snapshoty a klony.	Splňuje ANO
Replikace a Storage Transparent Failover Cluster (dále jen TFO)	Diskové pole musí podporovat režim replikace minimálně do tří datových center.	Splňuje ANO
	Diskové pole musí podporovat režimy replikace: Synchronní, Asynchronní, TFO Cluster, tedy dvě pole v synchronním režimu a zároveň v režimu TFO Active-Active cluster a třetí pole přijímá asynchronně data z primárního páru polí. Každý z režimů replikace musí být možné nastavit per LUN.	Splňuje ANO

Požadavky objednatele		Nabídka poskytovatele
Parametr	Primární diskové pole (2 ks)	xxx
	Mezi oběma primárními poli je vyžadováno zprovoznění TFO Cluster v režimu Active-Active, kdy každé z polí poskytuje Read/Write přístup ke každému TFO Cluster LUN.	Splňuje ANO
	Pro každý TFO Cluster LUN je navíc požadováno on-line udržování Asynchronní repliky dat na Backup pole.	Splňuje ANO	xxx
	IO operace libovolného z členů Storage TFO Clusteru v režimu Active/Active nesmí vyvolat stejnou operaci z druhého nodu clusteru a tuto operaci musí vyřídit daný nod clusteru, tedy bez nadbytečného zatížení propojů mezi lokalitami.	Splňuje ANO	xxx
	Řešení Storage Clusteru v režimu Active/Active, kde čtecí IO operace z diskového pole nevyvolá IO operaci na druhém poli	Splňuje ANO	xxx
	Zápisová operace na libovolný z členů Storage TFO Clusteru v režimu Active/Active nesmí vyvolat mezi členy clusteru obousměrný přenos zapisovaných dat a tím generovat nadbytečné (duplicitní) zatížení propojů mezi lokalitami.	Splňuje ANO	xxx
	K ochraně proti efektu split-brain musí pole implementovat funkci Quorum, které bude umístěno v lokalitě MF a nezbytný HW/SW musí být součástí dodávky.	Splňuje ANO
	Řešení musí umožňovat eliminaci následků split-brain.	Splňuje ANO	xxx

Požadavky objednatele		Nabídka poskytovatele
Parametr	Primární diskové pole (2 ks)	xxx
	Řešení Storage TFO Clusteru musí umožnit optimalizovat prostředky diskového pole prioritní komunikaci s místně příslušným diskovým polem – tj. aby servery v lokalitě „A“ primárně četly a zapisovaly do diskového pole v lokalitě „A“ a servery v lokalitě „B“ primárně četly a zapisovaly do diskového pole v lokalitě „B“.	Splňuje ANO
	V případě výpadku libovolného z polí ve Storage TFO Clusteru nesmí dojít k odpojení LUNu. Z pohledu synchronně replikovaných LUN je při výpadku libovolného jednoho primárního pole požadován proces RTO = 0 a RPO = 0	Splňuje ANO
	V případě výpadku libovolného primárního pole musí být možné zprovoznit funkci Storage TFO Cluster mezi přeživším primárním polem a backup polem. Pro zprovoznění TFO clusteru mezi přeživším primárním polem a backup polem je požadován proces RTO maximálně 120 minut.	Splňuje ANO	xxx
	Je-li k aktivaci Storage TFO Cluster potřeba dodatečný HW/SW, pak tento musí být součástí nabídky.	Splňuje ANO	xxx
	Požadovaný typ licence TFO Cluster: na dodanou kapacitu pole včetně započtení redučního poměru.	Splňuje ANO
	Podpora konzistenčních skupin: diskové pole musí umožnit pro replikaci definovat skupinu LUN, tak aby nemohlo v rámci skupiny dojít k nekonzistentním stavům (zachování pořadí zápisu).	Splňuje ANO	xxx

Požadavky objednatele		Nabídka poskytovatele
Parametr	Primární diskové pole (2 ks)	xxx
Management	Jednotný softwarový nástroj pro centrální management diskových polí, který umožní z jednoho místa spravovat všechna dodaná pole. Takovýto nástroj musí být pro správu funkcí plně zalicencovaný. Zadavatel preferuje instalaci takovéhoto nástroje včetně zajištění všech funkcionalit do prostředí VMware. Pokud toto nabízený nástroj neumožňuje, musí být součástí dodávky i příslušný hardware splňující výrobcem stanovené požadavky na výkon a kapacitu včetně propojovacích kabelů a příslušenství.	Splňuje ANO	xxx
		Splňuje ANO	xxx
		Splňuje ANO	xxx
	Řešení pro pokročilý monitoring a logování s dobou uložení minimálně 18 měsíců musí být schopno logovat minimálně provozní, konfigurační a přístupové události.	Splňuje ANO	xxx
	Musí umožňovat sledovat zatížení minimálně na úrovni vytížení jednotlivých LUN, Cache, Portů, Storage Procesorů, Disků.	Splňuje ANO
	Musí být možnost zpětného pohledu kdykoliv do historie zatížení diskového pole.	Splňuje ANO
	Schopnost monitorovat a sledovat kapacitní a výkonnostní trendy, musí umožňovat predikci čerpání kapacity se zohledněním Thin Provisioning.	Splňuje ANO
	Monitoring musí umožňovat reporting dlouhodobých trendů využití kapacity a výkonu.	Splňuje ANO
	Řešení musí být schopno tvořit krátkodobé i dlouhodobé reporty o výkonových hodnotách diskového pole.	Splňuje ANO

Požadavky objednatele		Nabídka poskytovatele
Parametr	Primární diskové pole (2 ks)	xxx
	Možnost tvorby automaticky generovaných reportů.	Splňuje ANO
	Diskové pole může mít povolenu komunikaci pouze směrem do internetu, nikoliv opačným směrem (z internetu není možné navázat spojení na diskové pole) při splnění podmínek na Požadavky na vzdálený monitoring z Přílohy č.3 Výzvy - Popis řešení.	Splňuje ANO	xxx
	Požadovaný typ licence pro pokročilý monitoring: na dodanou kapacitu pole.	Splňuje ANO	xxx

Požadavky objednatele		Nabídka poskytovatele
Parametr	Backup diskové pole	xxx
Diskové pole	Diskové pole bude dodáno uvnitř vlastní rackové skříně.	Splňuje ANO	xxx
	Redundatní napájení: připouští se možnost 3f i 1f připojení do celkového maximálního příkonu na RACK 10kW.	Splňuje ANO
	Diskové pole je zcela identické jako nabízená primární disková pole a bude konfigurováno podle stejných principů popsaných u primárních polí výše (včetně stejných disků, redundantní konfigurace a konfigurace HSD). Rozdíl je pouze v nabízené kapacitě. Veškeré licence, které se váží na kapacitu, je nutné upravit na nabízenou kapacitu backup diskového pole, vyjma licencí potřebných pro replikaci (které ovšem musejí objemově odpovídat synchronní i asynchronní replikaci veškerého	Splňuje ANO

Požadavky objednatele		Nabídka poskytovatele
Parametr	Backup diskové pole	xxx
	datového obsahu produkčních polí).
	Diskové pole bude používat identický SW/FW jako primární disková pole.	Splňuje ANO
	Diskové pole musí být schopné v případě havárie jednoho z primárních polí provozovat TFO cluster se zbylým primárním diskovým polem bez omezení výkonu celého řešení (celkový čas přechodu backup pole do role primárního pole nesmí být delší než 60 minut).	Splňuje ANO
Flash Tier	Čistá využitelná kapacita odpovídající RAID6 (6+2) bez započtení vlivu komprese a deduplikace minimálně 300 TiB. Do kapacity se nezapočítávají hot-spare disky.	Splňuje ANO	xxx
Licence	Replikace, TFO Cluster a snapshoty licencované minimálně na velikost primárních polí.	Splňuje ANO

Požadavky objednatele		Nabídka poskytovatele
Parametr	Backup diskové pole	xxx
Replikace	Zpoždění asynchronní replikace dat z primárnich polí nesmí překročit 5 minut (RPO).	Splňuje ANO	xxx
	Činnosti vedoucí k obnově asynchronní replikace po jejím selhání (například výpadek, obnova asynchronní replikace z jiného zdroje, dosynchronizace, atd.) nesmí mít za následek nedostupnost LUN na primárních polích (včetně jejich synchronní replikace).	Splňuje ANO	xxx

xxx

Příloha č. 2 – Specifikace dodávaného Hardware SAN switch včetně SW

Dynamický nákupní systém na prostředky ICT v resortu Ministerstva financí - Výzva 1-2020

Požadavky objednatele		Nabídka poskytovatele
Parametr	SAN switch (8 ks)	xxx
Technické požadavky	48 portů s podporou 4, 8, 16, 32 Gbps, veškeré porty musí být licencované a plně osazené SFP moduly.	Splňuje ANO
	SFP moduly pro všechny porty budou mít rychlost 16Gbps a budou typu LC.	Splňuje ANO
	1U rack provedení včetně příslušenství pro montáž do racku podle místa plnění.	Splňuje ANO
	Redundantní napájení.	Splňuje ANO
	Redundantní ventilátory.	Splňuje ANO
	Porty budou směrované do teplé uličky.	Splňuje ANO
	Switche budou vzájemně redundantně propojené - např. formou „ISL trunk“ nebo obdobné technologie.	Splňuje ANO
	Podpora zónování.	Splňuje ANO
	Podpora řízení kvality služeb QoS.	Splňuje ANO
	Switche musí podporovat vyvažování datového provozu minimálně na úrovni source FC ID, destination FC ID a echange ID nebo pomocí Dynamic Path Selection (DPS).	Splňuje ANO

Požadavky objednatele		Nabídka poskytovatele
Parametr	SAN switch (8 ks)	xxx
	Podpora včetně licencí pro propojení SAN switchů na vzdálenosti přesahující Fiber Channel standard 10 km. Dodané switche musí být zalicencovány a nadimenzovány tak, aby při propojení na vzdálenost do 30 km nedocházelo při plné rychlosti 16Gbps k omezení výkonu přenosu.	Splňuje ANO
	Podpora včetně zajištění licencí pro trunking porty, který zajistí vyšší agregovanou propustnost při propojení SAN switchů.	Splňuje ANO
	Podpora šifrování (včetně licencí) na ISL symetrickým algoritmem minimálně AES‐128 popř. jiným symetrickým algoritmem s ekvivalentní silou, s dynamickou výměnou klíčů a s výkonem 16 Gbps.	Splňuje ANO	xxx
Management	Management aplikace s grafickým rozhraním pro kompletní správu SAN prostředí.	Splňuje ANO	xxx
Management	Správa s využitím CLI prostřednictvím SSH, podpora SSH2, AES minimálně 128bit, CTR nebo GCM režimu, HMAC minimálně SHA-256, možnost vypnout jednotlivé algoritmy KEx, MAC a šifrování.	Splňuje ANO	xxx

Požadavky objednatele		Nabídka poskytovatele
Parametr	SAN switch (8 ks)	xxx
	Jednotné prostředí (jediná konzole) pro centrální management všech nabízených switchů, který umožní z jednoho místa (kromě vlastního managementu a správy) výkonnostní monitoring, diagnostiku stavu portů a rychlostí, a to včetně pokročilých nastavení, jako je nastavení routingu, možností konfigurace HW/SW komponent, on-line upgrade a detekcí Congestion stavů. Všechny uvedené funkcionality musí být zalicencované. Zadavatel preferuje instalaci takovéhoto nástroje včetně zajištění všech funkcionalit do prostředí VMware. Pokud toto nabízený nástroj neumožňuje, musí být součástí dodávky i příslušný hardware splňující výrobcem stanovené požadavky na výkon a kapacitu včetně propojovacích kabelů a příslušenství.	Splňuje ANO	xxx
	Možnost vytvoření administrátorských účtů s různými úrovněmi oprávnění – minimálně možnost rozlišení účet pouze pro čtení, plný přístup.	Splňuje ANO
	Podpora logování na syslog servery – UDP i TLS včetně oboustranného ověřování certifikáty.	Splňuje ANO
	Podpora SNMP v3.	Splňuje ANO
	Podpora protokolů: NTP, FTP, SFTP.	Splňuje ANO

xxx

SPECIFIKACE IMPLEMENTACE

Poskytovatel předloží do 20 pracovních dnů po podpisu Smlouvy Objednateli k odsouhlasení vypracovaný popis řešení, použitelný v prostředí Objednatele, včetně harmonogramu postupu Implementace a akceptačních testů, odhadované pracnosti a potřebné součinnosti Objednatele (dále jen „Popis řešení“).

Implementaci Poskytovatel začne realizovat v souladu s Objednatelem odsouhlaseným Harmonogramem Implementace.

Implementace je rozdělena do tří úzce souvisejících oblastí, které budou probíhat v prostorách DC v lokalitách Letenská, Voctářova a Vápenka.

Samostatnou část implementace pak bude představovat požadovaná implementační a provozní dokumentace popsaná v kapitole IV. IMPLEMENTAČNÍ A PROVOZNÍ DOKUMENTACE níže.

I. IMPLEMENTACE SAN

Implementace nových 8 ks SAN switch představuje jejich zprovoznění v prostředí MF obsahující tyto části:

1) Propojení SAN switch redundantními cestami přes technologii DWDM,

2) Instalace a konfigurace management nástrojů pro správu všech 8ks SAN switch z jednoho místa,

3) Základní konfigurace SAN switch pro připojení diskových polí a serverů. Umístění SAN switch:

1) 4 ks SAN switch v lokalitě Letenská (po 2ks ve dvou různých místnostech),

2) 2 ks SAN switch v lokalitě Voctářova,

3) 2 ks SAN switch v lokalitě Vápenka.

II. IMPLEMENTACE DISKOVÝCH POLÍ

Disková pole budou rozložena napříč datovými centry resortu MF (Letenská, Vápenka a Voctářova) tak, že disková pole v Letenské a na Vápence (Primární pole) budou rovnocenná synchronně replikovaná a výpadek kteréhokoliv z nich nebude znamenat výpadek poskytování služeb, anebo nedostupnost dat. Data tedy budou uložena ve formátu vysoké dostupnosti napříč datovými centry. Pod implementací diskových polí a SAN proto současně rozumíme nastavení TFO clusteru v požadovaném rozsahu a otestování jeho funkcí.

Jako třetí lokalita a třetí diskové pole (Backup pole) bude využita lokalita Voctářova, do které bude realizována bezpečnostní replika dat asynchronním způsobem. Tato bezpečnostní replika (záloha) bude dostupná pro rychlou obnovu s nízkým RPO a RTO. V případě havárie některého produktivního pole z původního active-active TFO clusteru bude sestaven nový active-active TFO cluster mezi zbylým produktivním polem a backup polem. RPO se bude odvíjet nanejvýš od maximálního povoleného časového zpoždění asynchronní replikace - tj. 5 minut a RTO plného zprovoznění active-active TFO clusteru mezi backup polem a aktuálně dostupným produktivním polem bude do 120 minut.

Jednotlivé kroky implementace jsou následující:

1) Připojení diskových polí k nově budované SAN,

2) Instalace a konfigurace management nástrojů pro správu všech 3ks diskových polí z jednoho místa,

3) Základní konfigurace diskových polí pro připojení serverů a replikace vytvořených diskových prostor.

III. INTEGRACE SE STÁVAJÍCÍM PROSTŘEDÍ

Integrace bude spočívat v připojení stávajících diskových polí a serverů do nové SAN a pro servery ověření funkčnosti s nově přidělenými diskovými prostory. Integrace bude obsahovat minimálně připojení těchto zařízení:

1) Dvě disková pole EMC VMAX10K,

2) Diskové pole HP EVA8400,

3) Diskové pole HP EVA8100,

4) Diskové pole Hitachi USP-V,

5) 8ks serverů s virtualizační platformou VMware,

6) 10ks serverů s virtualizační platformou Oracle,

7) 7ks serverů s operačním systémem Windows,

8) 2ks deduplikačních zařízení Dell EMC Data Domain DD6300,

9) 1ks páskové knihovny Sun StorageTek L700e,

10) 2ks zálohovacích zařízení Copan.

IV. IMPLEMENTAČNÍ A PROVOZNÍ DOKUMENTACE

Součástí dodávky požadované technologie bude i dokumentace v následujícím rozsahu:

1) Implementační dokumentace:

a) podrobný harmonogram implementace (se zapracovanými intervaly pro provedení požadovaných testů),

b) podrobný popis konfiguračních nastavení HW a SW pro účely implementačních prací a další nezbytné podklady, bez nichž není možná implementace nabízeného předmětu plnění do stávajícího prostředí Zadavatele, včetně detailního popisu způsobu integrace.

2) Provozní dokumentace včetně finální technické a implementační dokumentace:

a) dokumentace bude dodána v rozsahu uvedeném v podkapitole C. Specifikace dokumentace části 3 Migrace + Školení.

Provozní dokumentace bude obsahovat detailní popis prostředí včetně konfiguračních nastavení jak pro prostředí SAN, tak i pro disková pole. Dále bude dokumentace obsahovat zejména běžné pracovní postupy správců:

1) Kroky nutné pro připojení serveru do SAN,

2) Vytvoření nového LUNu na diskovém poli,

3) Nastavení synchronní i asynchronní replikace nově vytvořeného LUNu,

4) Zpřístupnění nového LUN serveru,

5) Odebrání LUN serveru,

6) Zrušení synchronní i asynchronní replikace vybraného LUN,

7) Základní diagnostika závad a postupu jejich řešení.

8) Nastavení a obnova synchronní replikace mezi primárními diskovými poli,

9) Nastavení a obnova asynchronní replikace mezi primárními a backup polem,

10) Nastavení synchronní replikace mezi jedním primárním a backup polem a návrat k původnímu stavu replikace.

Předpokládáme dodání dokumentace nejméně v následujícím rozsahu: Finální technická a implementační dokumentace:

1) finální technická dokumentace (popis předávaného nastavení celého prostředí -SAN, disková pole, TFO cluster, management prostředí),

2) finální technická dokumentace integrace (popis nastavení) stávajícího prostředí,

3) dokumentace implementovaného management prostředí plus popis všech implementovaných alertů a "obrazovek".

Provozní dokumentace celého dodaného prostředí:

1) Krom požadavků uvedených v úvodu kapitoly, bude dokumentace obsahovat popis základních provozních situací a jejich řešení. Dokumentace bude dodána ve formátu step- by-step popisu nezbytných postupů včetně snímků obrazovky nejméně v následujícím rozsahu:

- základní provozní administrátorské postupy správy SAN,

- základní provozní administrátorské postupy správy diskových polí,

- základní provozní administrátorské postupy správy TFO clusteru.

2) provozní dokumentace bude dále obsahovat řešení chybových stavů nejméně v následujícím rozsahu (opět ve formátu step-by-step dokumentace včetně snímků obrazovky):

- řešení výpadku synchronizace směrem k backup poli - a to jak na úrovni jednotlivého LUN, tak i na úrovni případné poruchy celého pole,

- řešení obnovy asynchronní replikace LUN, které bylo přesměrováno (automaticky v důsledku výpadku nebo manuálně) na druhé produkční pole,

- návrat/přesměrování LUN zpět na jeho primární produkční pole včetně obnovení původního stavu asynchronní replikace - tj. návrat do situace, která byla před přesměrováním LUN z předchozího případu,

- řešení výpadku libovolného produkčního pole + návaznost na synchronizaci dat,

- řešení rozpadu/havárie TFO clusteru,

- řešení výpadku backup pole + návaznost na synchronizaci dat,

- postup obnovy synchronního datového obrazu polí,

- řešení havárie jednoho produkčního pole - změna aktivních uzlů TFO clusteru na jedno (po výpadku zbylé) produkční pole a backup pole,

- provedení změny konfigurace prostředí po opravě havarovaného produkčního pole - návrat zpět (do stavu před havárií produkčního pole) na TFO cluster dvou synchronně replikovaných produkčních polí s asynchronní replikací na backup pole.

SPECIFIKACE TESTOVÁNÍ

Návrh skupin testů dodávky diskových polí a TFO active-active clusteru

V ZD jsou specifikované požadované vlastnosti diskových polí včetně celé požadované infrastruktury zajišťující jejich vysokou dostupnost. Níže je uveden seznam testů, které bude požadováno provést pro ověření dostatečného výkonu nabízených / dodávaných polí a především k ověření plné funkcionality požadovaného řešení.

Scénáře jsou rozděleny do tří základních skupin:

1) zátěžové testy dodávaných polí,

2) požadavky ověřitelné na základě prosté demonstrace vlastností, případně dle konfigurace dodávky,

3) testy dostupnosti dodávaného řešení (testy požadovaných vlastností).

Níže uvedené scénáře obsahují základní představu o možném způsobu a průběhu testování. Detailní osnovu scénářů bude však možné připravit teprve až na základě dodaného řešení a jeho konkrétních vlastností. Pokud bude možno testovaný chybový stav demonstrovat jednodušším nebo přesvědčivějším způsobem, bude mu dána přednost. U některých testů je popsán jen požadovaný "chybový" stav, ale způsob jeho dosažení bude konzultován až s Dodavatelem, protože se chceme vyhnout destruktivním postupům. Cílem "alternativy v postupu" je však vždy dosažení konkrétního chybového stavu, jehož zpracování budeme testovat - nikoli změkčení nebo přitvrzení testu samotného. Zde je proto uváděn základní popis požadovaných testů tak, aby Xxxxxxx byl obeznámen s jejich požadovaným rozsahem a byl je schopen zakomponovat do harmonogramu plnění.

Finální provedení testu a dodání potřebného počtu testovacích serverů včetně dalšího potřebného SW a HW vybavení tak, aby řešení splnilo akceptační požadavek, je plně v kompetenci Uchazeče. Vlastní detailní návrh scénářů testů bude probíhat ve spolupráci s pracovníky Objednatele.

Poznámka:

V textu níže na několika místech uvádíme termíny automaticky, automatizovaně a manuálně s následujícím významem:

• automaticky - činnost proběhne bez zásahu operátora plně automaticky

• automatizovaně - operátor/obsluha má k dispozici nějaké manuálně aktivované postupy (skripty/makra)

• manuálně - činnost proběhne po plně manuálním zásahu provedeném s využitím základních příkazů prostředí.

1. Zátěžové testy a zátěž pozadí 2

1.1. Základní požadavky na prostředí 2

1.2. Smíšené zátěžové testy s velikostí záznamu 8kB 3

1.3. Zátěžový test zápisu (8kB záznam) 4

1.4. Zátěžový test čtení (8kB záznam) 4

2. Kontrola ověřitelných vlastností 4

2.1. Zálohování cache 4

2.2. Ověřování vlastností management prostředí 4

2.3. Pořizování snapshotů a klonů 5

2.4. RAS vlastnosti 6

3. Testy dostupnosti 6

3.1. Primární testy TFO clusteru v konfiguraci active-active 6

3.2. Testy havarijní situace se změnou active-active konfigurace 10

1. Zátěžové testy a zátěž pozadí

1.1. Základní požadavky na prostředí

Požadovaný výkon Dodavatel potvrdí testem realizovaným produktem: MS DiskSpd, FIO, IOmeter nebo VDBench - nebo jiným produktem, který dokáže generovat požadovanou zátěž v požadovaném rozložení.

Níže rozlišujeme zátěžové testy a zátěž na pozadí.

Zátěžové testy požadujeme provádět nad celým objemem diskového pole zaplněným na 90% s náhodným přístupem a velikostí bloku 8kB. Bližší podmínky jednotlivých zátěžových testů jsou popsány níže.

Ve většině ostatních testů budeme vyžadovat zátěž na pozadí, u které předpokládáme rozdělení zátěže 60% náhodné čtení a 40% náhodný zápis, přičemž budou používány "testovací soubory" s velikostí záznamu 8kB (60% výskytu), 4kB(20% výskytu) a "soubory" s velikostí záznamu 64kB(20% výskytu).

Zátěž bude generována nad redundantně konfigurovaným diskovým objemem (ve stejné redundantní konfiguraci, jako nabízená konfigurace pole) o celkové velikosti nejméně 64TiB (nebo více), který bude zaplněn alespoň z 70%. Nad ním bude vytvořeno nejméně 64 LUN (logických diskových objemů) s obsahem dle následujícího seznamu. Celková velikost testovacích dat musí být alespoň 2x větší než je konfigurovaná velikost cache diskového pole. V závislosti na dodané konfiguraci je možné, že se velikost logických objemů bude ještě finálně upravovat.

Pro testy bude připraveno celkem 64 logických diskových objemů následujících vlastností:

1) skupina TA - 32 LUN o velikosti nejméně 500GB každý s velikostí záznamu 8kB,

2) skupina TB - 16 LUN o velikosti nejméně 500GB každý s velikostí záznamu 4kB,

3) skupina TC - 16 LUN o velikosti nejméně 500GB každý s velikostí záznamu 64kB.

To znamená celkem cca 16TiB + 8TiB + 8TiB = 32TiB testovacích dat (celkově však bude použitý diskový objem zaplněn na 80% - tj. testovací logické disky plus další logické disky, jejichž účelem je vytvořit obsazenost diskového objemu - tzv. balastní data.).

Zátěž na pozadí bude trvale generována při všech funkčních testech (s výjimkou zátěžových testů). Budou použity všechny skupiny vytvořených LUN (nikoli ovšem nutně všech 64 možných LUN najednou) tak, aby bylo dosaženo agregované zátěže nejméně 30k náhodných IOPS. Objednatel předpokládá rozdělení zátěže v poměru 60% čtení a 40% zápis nad všemi použitými LUN, přičemž budou používány testovací soubory/LUN s velikostí záznamu až 32x 8kB (celkem 60% I/O), až 16x 4kB(celkem 20% I/O) a soubory/LUN s velikostí záznamu až 16x 64kB(celkem 20% I/O).

Zátěž bude podle typu prováděného testu generována nad jedním nebo současně nad oběma aktuálně "produkčními" poli (podle typu testu) nejméně ze dvou samostatných fyzických serverů. Zátěž nebude generována jako maximální, ale jako víceméně vyrovnaná agregovaná zátěž testovaného prostředí zpravidla kolem 30k IOPS při výše definovaném rozložení dat (viz popis testů). Příslušná LUN budou aktivována před počátkem odpovídajícího testu.

Účelem zátěže na pozadí je jednak generování vlastních IO operací v požadovaném poměru čtení a zápisu, jednak existence aktivních globálních LUN, u kterých bude sledována nepřerušená činnost v active-active TFO clusteru a asynchronní synchronizace na záložní pole.

Poznámka:

Existence 64 LUN neznamená, že všechna budou využita ve všech testech. Umožňuje však pružnou konfiguraci zátěže na pozadí a její rozdělení mezi dvě lokace při zachování poměru IO operací čtení a zápisu a při zachování poměru velikosti záznamu testovacích souborů.

OBJEDNATEL POŽADUJE, ABY ZÁTĚŽOVÉ A FUNKČNÍ TESTY BYLY PROVÁDĚNÉ CO NEJDŘÍVE PO INSTALACI POLE/POLÍ TAK, ABY JEJICH PŘÍPADNÉ NESPLNĚNÍ NEBYLO DETEKOVÁNO AŽ PO INSTALACI CELÉHO PROSTŘEDÍ.

OBJEDNATEL DÁLE POŽADUJE, ABY TESTOVÁNÍ BYLO ZAŘAZENO DO HARMONOGRAMU PRŮBĚŽNĚ DO JEDNOTLIVÝCH ETAP IMPLEMENTACE.

1.2. Smíšené zátěžové testy s velikostí záznamu 8kB

Navrhovaný způsob provedení testu:

Nad celým konfigurovaným diskovým objemem zaplněným z 90% budou paralelně probíhat operace náhodného čtení a náhodného zápisu v rozložení 65% čtení a 35% zápisů se záznamy/bloky o velikosti 8kB. Objednatel předpokládá, že zátěž bude generována ideálně ze dvou serverů po dobu 20 minut v každém běhu testu.

Každý test bude kontinuálně opakován 4x po sobě a výsledky posledních tří testů budou zprůměrovány.

Očekávaný výsledek:

a) 200 000 IOPS celkem,

b) z toho alespoň 70k IOPS pro náhodný zápis,

c) 95% operací musí být vyřízeno do 3ms,

d) 70% operací musí být vyřízeno do 1ms.

1.3. Zátěžový test zápisu (8kB záznam)

Navrhovaný způsob provedení testu:

Nad celým konfigurovaným diskovým objemem zaplněným z 90% budou paralelně probíhat operace náhodného zápisu. Objednatel předpokládá, že zátěž bude generována ideálně ze dvou serverů po dobu 20 minut v každém běhu testu.

Každý test bude kontinuálně opakován 4x po sobě a výsledky posledních tří testů budou zprůměrovány.

Očekávaný výsledek:

a) 200 000 IOPs za podmínek 100% náhodného zápisu při velikosti bloku 8kB, kde 95% operací musí být vyřízeno do 3 ms,

b) Vzhledem ke specifikovaným požadavkům VZ bude test opakován s vypnutým jedním řadičem pole, přičemž výkon nesmí klesnout o více než 25%, tj. pod 150 000 IOPs.

1.4. Zátěžový test čtení (8kB záznam)

Navrhovaný způsob provedení testu:

Nad celým konfigurovaným diskovým objemem zaplněným z 90% budou paralelně probíhat operace náhodného čtení. Objednatel předpokládá, že zátěž bude generována ideálně ze dvou serverů po dobu 20 minut v každém běhu testu.

Každý test bude kontinuálně opakován 4x po sobě a výsledky posledních tří testů budou zprůměrovány.

Očekávaný výsledek:

a) požadovaný výkon za podmínek 100% náhodného čtení alespoň 800 000 IOPs při velikosti bloku 8kB, kde 95% operací musí být vyřízeno do 1 ms,

b) Vzhledem ke specifikovaným požadavkům VZ bude test opakován s vypnutým jedním řadičem pole, přičemž výkon nesmí klesnout o více než 25%, tj. pod 600 000 IOPs.

2. Kontrola ověřitelných vlastností

Navrhovaný způsob provedení testů:

Tato skupina testů sestává z prostého ověřování dodané konfigurace, jednoduchých testů nebo z testů, jejichž výsledky jsou hodnoceny na základě výstupu monitorovacího prostředí.

2.1. Zálohování cache

Očekávaný výsledek:

Zálohování cache, které bude ověřeno dle dokumentace v průběhu testů.

2.2. Ověřování vlastností management prostředí

1) Jednotný softwarový nástroj pro centrální management diskových polí, který umožní z jednoho místa spravovat všechna dodaná pole.

Očekávaný výsledek:

a) bude ověřeno monitoringem dalších testů včetně podpory požadovaných funkcí,

b) monitoring a management diskových polí a celkového dodávaného prostředí bude součástí jednotlivých testů dostupnosti.

2) Vlastnosti management rozhraní ověřované při testech a demonstrované při školení.

Očekávaný výsledek:

a) sledování zátěže LUN, Cache, Portů, Storage procesorů atd.,

b) pokročilý monitoring s ukládáním historie,

c) procházení historie zátěže pole v rozsahu požadavku ZD,

d) predikce kapacitních a výkonových trendů,

e) tvorba automatických a speciálních reportů.

3) Odpojení jednoho SFP na SAN switch

Očekávaný výsledek:

Management nástroj musí zobrazit daný problém.

2.3. Pořizování snapshotů a klonů

1) Testy snapshotů a klonů:

Očekávaný výsledek:

a) při aktivní zátěži na pozadí bude vytvořeno 10 snapshotů nad 5 LUNy. Z pěti bude vytvořen klon a následně tři snapshoty nad každým klonem. Kontrola funkcí komprese, deduplikace a šifrování,

b) nastavení služby QoS na 5x LUN,

c) při aktivní zátěži na pozadí bude v pětiminutovém intervalu vytvořen kaskádový snapshot zvoleného LUN nejméně do hloubky 6,

d) při aktivní zátěži na pozadí bude ze třetího snapshotu předchozího testu vytvořen samostatný klon, následně bude klon přimontován a otestován (ideálně též v rámci školení),

e) vytvoření snapshotu na platformě VMware a práce s ním - bude též součástí školení.

2) Zpětné rolování:

Očekávaný výsledek:

a) bude demonstrován požadavek zpětného rolování v intervalu 5 minut (nebo méně) do

24 hodin v minulosti. V závislosti na způsobu řešení lze případně použít i kaskádování klonů,

b) postup bude demonstrován nad vybraným LUN v rámci testů,

c) postup bude součástí školení včetně přesného popisu dodatečných efektů takového monitoringu (růst alokovaného prostoru, navyšování interní IO zátěže, omezení atd.).

2.4. RAS vlastnosti

Navrhovaný způsob provedení testu:

Při aktivní zátěži na pozadí bude demonstrován rozsah možností zásahu do konfigurace pole bez pádu aktivních LUN (při timeoutu IO operací odpovídajícímu standardním požadavkům DB). Scénář testu bude vytvořen až na základě dodaného řešení.

1) Výměna disku v diskové skupině - rebuild skupiny.

Očekávaný výsledek:

Test bude spojen s rebuildem diskové skupiny po výpadku jednoho disku. Rebuild skupiny musí být dokončen do 16 hodin při běžné zátěži na pozadí (nejméně 30k IOPS při daném rozložení). Typ a velikost logické diskové skupiny bude odpovídat dodávané konfiguraci a skupina bude obsazena nejméně ze 70%.

2) Výměna nebo odstavení řadiče (případně jeho front-end a back-end části) bez výpadku libovolného aktivního LUN.

Očekávaný výsledek:

Scénář bude vytvořen až podle možností dodaného řešení. Test bude zahrnovat i demonstraci "upgrade" firmware řadiče! Test bude spojen s monitoringem zátěže pole. Na pozadí musí být generována zátěž nejméně 30k IOPS. Protože však bude po dobu testu zařízení podrobeno jen definované zátěži na pozadí (viz výše), Objednatel předpokládá, že se odstavení řadiče nebo jeho částí a provedení upgrade firmware projeví jen minimální degradací výkonu! Případné překročení limitu ztráty 25% výkonu při zátěži na pozadí bude považováno za nevyhovující výsledek.

3) Výpadek jednoho zdroje.

Očekávaný výsledek:

Výpadek zdroje se neprojeví na funkci pole. Bude demonstrován alert vzniklé situace. Test bude připraven po dohodě s Dodavatelem.

3. Testy dostupnosti

3.1. Primární testy TFO clusteru v konfiguraci active-active

Cíl testu:

Ověřit činnost funkcionalitu prostředí active-active TFO clusteru.

Navrhované počáteční podmínky provedení testu:

Testují se lokace, mezi kterými je vytvořen active-active TFO cluster (metrocluster). Lokace i příslušná pole budou níže označovány jako lokace A (implicitně lokace, ze které se budou provádět testy) a lokace B (vzdálená).

V prostředí active-active TFO clusteru pracujeme s globálními LUN (GLUN) transparentně přístupnými z obou polí. V popisu testů však potřebujeme rozlišit, z jakého pole je ke globálnímu LUN přistupováno. Je proto zavedena symbolika GLUN-A resp. GLUN-B pro LUN, ke kterým je v počátečním stavu testu přistupováno na poli A nebo B. Jde o primární stav přístupu k danému globálnímu LUN, takže i po "přesměrování IO na druhou lokaci" bude mít GLUN pro účely popisu označení stejné - například GLUN-A na poli B znamená, že se jedná o přesměrované IO na GLUN, ke kterému se přistupuje z lokality A.

Všechny testy budou prováděny při aktivní zátěži na pozadí. Výše uvedená LUN (nejméně 64 LUN dle popisu výše) pro generování zátěže na pozadí budou vytvořena jako globální (transparentně přístupná z obou lokalit), přičemž polovina bude primárně využívána jako GLUN-A a druhá polovina jako GLUN-B (jde o primární přístup) Zátěž na pozadí bude generována ze dvou serverů, které budou "konfigurovány" každý v jiném centru tak, aby každý mohl využívat GLUN "svého" centra.

Všechna GLUN se nemusejí účastnit všech testů - obecně však předpokládáme, že na každé lokalitě bude v průběhu testu aktivních 8 GLUN.

Způsob plnění/postupu testu bude sledován prostřednictvím dodávaného monitorovacího prostředí! Současně budou demonstrovány možnosti implementovaného monitorovacího a management prostředí.

Přehled Primárních testů TFO clusteru v konfiguraci active-active

1) Výpadek SAN switche

Navrhovaný způsob provedení testu:

V centru A se „vypne/zablokuje“ jeden SAN switch. Po stabilizaci prostředí (interval cca 5 minut) bude činnost switche obnovena a (po stabilizaci cca 5 minut) dojde k "výpadku" druhého switche. Po stabilizačním intervalu (cca 5 minut) bude činnost switche obnovena. Vše se děje v rámci jednoho cyklu.

Očekávaný výsledek:

Všechna LUN budou pokračovat bez přerušení činnosti a bez přesměrování. Činnost clusteru nebude ovlivněna.

2) Odolnost proti výpadku řadiče nebo poloviny SAN v centru

Navrhovaný způsob provedení testu:

V centru A bude odpojena/blokována polovina portů (blokování všech portů (pole-switch) na SAN přepínačích, které vedou na konkrétní řadič pole nebo blokování odpovídajících portů na řadiči pole), případně bude jinak navozen stav, který odpovídá výpadku řadiče. Následně (cca po 5 minutách) budou porty obnoveny a bude simulován výpadek druhé části cesty a po určité době (nejméně cca 5 minut) opět přechod do původního stavu. Test projde postupně (bez přestávky) všechny konfigurované řadiče. V závislosti na konstrukci dodávaných řadičů (kompaktní vs. front+back-end) budou testy upřesněny.

Očekávaný výsledek:

Všechna LUN budou pokračovat bez poruchy, bez přesměrování a bez změny průchodnosti! Výpadek se neprojeví ani na celkové zátěži pole. Prostředí "ustojí" i opakovaný přesun IO mezi jednotlivými řadiči.

3) Lokální nedostupnost pole

Navrhovaný způsob provedení testu:

V centru A dojde k simulování výpadku řadičů pole - ale nikoli k totální nedostupnosti pole z pohledu storage clusteru. Postup bude upřesněn dle možností dodaného řešení - například budou na všech SAN switchích lokality A zablokovány všechny konfigurované porty (switch-pole) nebo všechny odpovídající externí IO porty na řadičích pole. Xxxxx pro replikaci mezi poli zůstanou aktivní! Dojde k nefunkčnosti externího rozhraní pole v lokaci, ale nikoli k jeho plnému výpadku. Pole bude dosažitelné i z quora.

Očekávaný výsledek:

Postižená GLUN-A budou transparentně "přesměrována" na pole v lokalitě B. Očekáváme, že GLUN budou přesunuta bez výpadku. To znamená, že veškerá zátěž bude nyní generována primárně na poli v lokaci B. Komunikace mezi poli zůstala při blokování jen odpovídajících IO portů na SAN switchích nebo na řadičích zachována, a proto dojde u "postižených" LUN transparentně k přesměrování (všechna GLUN budou přistupována v B). Současně bude monitorována IO zátěž obou polí a nemělo by v součtu dojít k jejímu navýšení.

Předpokládáme, že dojde transparentně také k pokračování/obnovení asynchronní replikace všech LUN na pole C. Bude demonstrován monitoring situace a způsob řešení tak, aby pole C opět plnilo svou původní funkci a v rámci nastaveného okna bylo datově zasynchronizované.

Na management úrovni bude demonstrován způsob oznámení vzniklé situace a možnosti monitoringu a správy dané situace.

4) Návrat k "normálnímu" stavu

Navrhovaný způsob provedení testu:

Obnova činnosti blokovaných portů - obnova činnosti řadičů pole. Očekávaný výsledek:

V závislosti na vlastnostech dodaného řešení dojde k indikaci obnovení činnosti lokace/pole A (management rozhraní). V závislosti na vlastnostech dodaného řešení a na jeho implementaci dojde k bezvýpadkovému přesměrování přístupu původních GLUN-A zpět na pole v lokaci A (z hlediska testu nerozhoduje, zda půjde o přesměrování automatické nebo automatizované (spojené s manuálním zásahem)). Prostředí bude opět v původním stavu včetně asynchronní replikace na pole C.

Současně bude demonstrován způsob monitoringu a správy dané situace a obnovení všech asynchronních replikací do původního nastavení.

5) Simulovaný výpadek pole A

Navrhovaný způsob provedení testu:

Simulace totální nedostupnosti pole A bude provedena na základě vlastností dodaného řešení.

Očekávaný výsledek:

Prostředí storage clusteru musí detekovat totální nedostupnost pole A a provést transparentní automatické přesměrování všech GLUN-A na pole B. Nedojde k výpadku postižených GLUN-A ani GLUN-B. Současně bude přerušena replikace všech LUN mezi poli B a A. Veškerá zátěž na pozadí bude nyní provozována jen na poli B a budou vznikat rozdíly mezi obsahem polí B a A. Všechna LUN budou opět asynchronně replikována na C.

Předpokládáme, že přesměrování všech GLUN-A na B včetně asynchronních replikací bude bezvýpadkové - nebo (v případě asynchronní replikace) bude případné přerušení obnoveno automaticky.

Bude demonstrován monitoring a postup řešení/obnovy u asynchronně replikovaných LUN na pole C. Současně bude demonstrován způsob oznámení, monitoringu a správy dané situace.

6) Obnova činnosti pole A po "výpadku"

Navrhovaný způsob provedení testu:

Dojde k odstranění simulace nedostupnosti pole A. Očekávaný výsledek:

Dodavatel bude demonstrovat postup přechodu do "normálního" stavu včetně opětné synchronizace obsahu replikovaných entit. To znamená dosynchronizování obsahu pole A, rozložení GLUN-A a GLUN-B dle situace před testem a plná obnova asynchronní replikace na pole C. Z hlediska testu nerozhoduje, zda v tomto případě půjde o přesměrování LUN automatické nebo automatizované (spojené s manuálním zásahem).

Současně bude demonstrován způsob monitoringu a správy dané situace.

Poznámka:

Testy 5 a 6 výše se podobají následujícím testům havarijní situace. Rozdíly jsou ovšem následující:

1. zde se demonstruje jen výpadek pole A bez následné aktivace TFO active- active clusteru mezi B a C

2. demonstruje se návrat do původního stavu clusterování A-B v situaci, kdy došlo jen k odpojení replikací mezi A-B. To znamená snazší způsob dosynchronizování obsahu pole A po výpadku,

7) Simulace situace split-brain

Navrhovaný způsob provedení testu:

Konkrétní způsob simulace stavu split-brain bude navržen až na základě vlastností dodaného řešení.

Očekávaný výsledek:

Řídící jednotka quorum musí zasáhnout a jedno z polí bude automaticky označeno jako primární a funkční. Druhé pole musí přejít do neaktivního stavu a v závislosti na způsobu indikace split-brain stavu by měla být postižená GLUN transparentně (a pokud možno

bezvýpadkově) přesměrována na zbylé pole. Konkrétní způsob testu a požadovaný cíl (viz podtržené části předchozí věty) bude upřesněn na základě dodaného řešení.

Bude demonstrován monitoring a postup řešení (automatický) u asynchronní replikace všech LUN na pole C. Současně bude demonstrován způsob oznámení, monitoringu a správy dané situace.

3.2. Testy havarijní situace se změnou active-active konfigurace

Cíle testů:

Ověřit postupy změny prostředí active-active TFO clusteru v lokalitách A, B a C. Navrhované počáteční podmínky provedení testu:

Testují se lokace A a B, mezi kterými je nastaven active-active TFO cluster a lokace C, na kterou je prováděna asynchronní replikace všech provozovaných LUN. Lokace i příslušná pole budeme níže označovat jako lokaci A (implicitně lokaci, ze které budeme provádět testy resp. lokaci, ze které je prováděna asynchronní replikace na C - viz Poznámka I níže), lokaci B (vzdálenou) - obě zpočátku v konfiguraci active-active v rámci TFO clusteru a záložní lokaci C s asynchronní replikací vybraných LUN.

V popisu testů je zavedena symbolika GLUN-A resp. GLUN-B podle popisu v kapitole 3.1

Všechny testy budou prováděny při aktivní zátěži na pozadí. Protože jde o poměrně náročný test s demonstrací celého havarijního postupu, nebudou používána připravená LUN v plném rozsahu a tím i zátěž na pozadí bude příslušně snížena. V tomto případě jde především o to, aby byla GLUN řádně aktivní. Požadujeme využití celkem nejméně 8 GLUN (6 x TA, a 2x TC) zpočátku přistupovaných po čtyřech z každého pole - to znamená nejméně 4x GLUN-A a 4x GLUN-B. Zátěž na pozadí bude generována ze dvou serverů, které budou "konfigurovány" každý v jiném centru A/B tak, aby každý mohl využívat "domovská" pole svého centra a prostředí TFO aby pracovalo v režimu active-active.

Všechna aktivní globální LUN v testu (minimálně tedy alespoň 4 GLUN-A a alespoň 4 GLUN-B) budou současně asynchronně replikována na pole C!! .

Způsob plnění/postupu testu bude sledován prostřednictvím monitorovacího prostředí! Současně budou demonstrovány možnosti implementovaného monitorovacích prostředí.

Přehled Testů havarijní situace se změnou active-active konfigurace

1) Simulovaný výpadek pole A (A je zde míněno pole dle poznámky I výše)

Navrhovaný způsob provedení testu:

Simulace totální nedostupnosti pole A. Obecně akceptujeme jakýkoli způsob simulace nedostupnosti pole A. Výpadek se provádí při aktivní zátěži dle popisu výše!

Očekávaný výsledek:

Prostředí storage clusteru musí detekovat totální nedostupnost pole A a provést transparentní bezvýpadkové přesměrování GLUN-A na pole B. Současně bude přerušena replikace všech LUN mezi poli B a A. Veškerá zátěž bude nyní provozována jen na poli B a budou vznikat rozdíly mezi obsahem polí B a A.

Na úrovni monitorovacího a management prostředí bude demonstrován způsob oznámení,

monitoring a správa dané situace.

Dodavatel bude dále demonstrovat následující chování:

a) informace/alert o vzniklém problému, monitoring stavu a administrátorské možnosti,

b) finální stav asynchronní replikace původních GLUN na pole C - jak je porucha alertována a obsloužena

c) provoz všech globálních LUN původního clusteru A-B by měl být pro tuto fázi testu ještě bezvýpadkový

d) postup zasynchronizování obsahu obou "zbylých" polí (B a C) s přihlédnutím k předešlé asynchronní replikaci všech GLUN na C - viz následující test,

2) Změna active-active konfigurace prostředí

Navrhovaný způsob provedení testu:

Po předchozím testu je aktivní jen pole B (viz poznámka I výše) a pole C, které ovšem v okamžiku havárie nemusí mít zcela dosynchronizovaný datový obsah. Cílem testu je vytvoření nové active-active TFO clusterované dvojice polí B a C. Po celou dobu testu bude aktivní zátěž na pozadí - respektive až do doby, kdy bude případně nutné pozastavit činnost všech LUN při konfiguraci clusteru B-C.

Očekávaný výsledek:

Dodavatel bude prakticky demonstrovat postup vytvoření active-active TFO clusteru B-C. Jde především o následující body:

a) Xxxxxxxxx předvede a provede postup (do)synchronizace obsahu pole C,

b) vytvoření TFO active-active clusteru mezi poli B a C,

c) nastartování globálních LUN mezi poli B a C (protože na lokaci C nebude k dispozici testovací server, mohou být v daném případě všechna LUN typu GLUN-B, prostředí však bude schopno pracovat v režimu active-active),

d) předvedení správy, monitoringu a řízení nově vytvořeného active-active TFO clusteru B-C, manuální přesměrování alespoň jednoho GLUN-B na C.

3) Změna konfigurace celého prostředí zpět do původního stavu

Navrhovaný způsob provedení testu:

Pole A se opět uvede do provozního stavu a Dodavatel předvede postup převodu active- active TFO clusteru B-C zpět na cluster A-B s asynchronní replikací do pole C (respektive přechod zpět do původní konfigurace)

Očekávaný výsledek:

Dodavatel bude prakticky demonstrovat postup vytvoření/obnovy TFO active-active clusteru A-B, přesměrování LUN zpět do konfigurace GLUN-A a GLUN-B a opětné nastavení asynchronní replikace obsahů všech LUN do pole C. Jde především o následující body a jejich provedení (pokud nebudou prováděny například na pozadí):

a) dosynchronizování obsahu pole A - postup nepředjímáme,

b) vytvoření/obnova TFO active-active clusteru mezi poli B a A včetně začlenění quora,

c) přesměrování všech GLUN zpět na pole B a A,

d) nastartování původního typu přístupu k používaným GLUN v TFO clusteru A-B (tj. GLUN-A a GLUN-B),

e) nastartování asynchronní replikace všech LUN do pole C,

f) předvedení správy, monitoringu a řízení nově vytvořeného prostředí.

Součástí SPECIFIKACE TESTOVÁNÍ je i následující příloha: Příloha č. 1 – TABULKA PLNĚNÍ TESTŮ

Příloha č. 1 - TABULKA PLNĚNÍ TESTŮ

Uvedená tabulka je seznamem všech testů, které musí dodavatel v rámci testování provést. Splnění každého testu zapíše do barevně označeného pole „ANO“, v opačném případě zapíše

„NE“, resp. „S VÝHRADOU“. Dodavatel je povinen provést a splnit všechny požadované testy způsoby uvedenými výše v textu. V případě, že dodavatel nesplní některý test, budou v AKCEPTAČNÍM PROTOKOLU k předmětu plnění IMPLEMENTACE a TESTOVÁNÍ

uvedeny výhrady. Objednatel bude dále postupovat v souladu s uzavřenou smlouvou.

OZNAČENÍ DLE TEXTU			POPIS TESTU	SPLNĚNO (ANO/NE/S VÝHRADOU)
1.			Zátěžové testy a zátěž pozadí
	1.2.		Smíšené zátěžové testy s velikostí záznamu 8kB
	1.3.		Zátěžový test zápisu (8kB záznam)
	1.3.		Zátěžový test čtení (8kB záznam)
2.			Kontrola ověřitelných vlastností
	2.1.		Zálohování cache
	2.2.		Ověřování vlastností management prostředí
		1.	Jednotný softwarový nástroj pro centrální management diskových polí
		2.	Vlastnosti management rozhraní ověřované při testech a demonstrované při školení
		3.	Odpojení jednoho SFP na SAN switch
	2.3.		Pořizování snapshotů a klonů
		1.	Testy snapshotů a klonů
		2.	Zpětné rolování
	2.4.		RAS vlastnosti
		1.	Výměna disku v diskové skupině - rebuild skupiny
		2.	Výměna nebo odstavení řadiče (případně jeho front-end a back- end části) bez výpadku libovolného aktivního LUN
		3.	Výpadek jednoho zdroje
3.			Testy dostupnosti
	3.1.		Primární testy TFO clusteru v konfiguraci active-active
		1.	Výpadek SAN switche
		2.	Odolnost proti výpadku řadiče nebo poloviny SAN v centru
		3.	Lokální nedostupnost pole
		4.	Návrat k "normálnímu" stavu
		5.	Simulovaný výpadek pole A
		6.	Obnova činnosti pole A po "výpadku"
		9.	Simulace situace split-brain
	3.2	Testy havarijní situace se změnou active-active konfigurace
		1.	Simulovaný výpadek pole A
		2.	Změna active-active konfigurace prostředí
		3.	Změna konfigurace celého prostředí zpět do původního stavu

SPECIFIKACE MIGRACE

Migrace dat ze starých na nová disková pole bude probíhat na pozadí (např. za použití virtualizace na úrovni diskových polí – potřebný HW zajistí Poskytovatel). Přípustný výpadek jednotlivých informačních systémů jsou maximálně 2 hodiny (doba, kdy není služba dostupná) mimo pracovní dobu, která je v pracovních dnech stanovena od 6 do 18 hodin. Celková délka migrace může být maximálně dle smlouvy 90 kalendářních dní. Všechny servery mají plně funkční multipathing, který umožní bezvýpadkové přepojení stávajících diskových polí a serverů do nové SAN při současném provozu ve stávajícím SAN prostředí. Objednatel neplánuje ani dočasné zapojení nových diskových polí do stávající SAN, ani vzájemné propojení stávající a nové SAN.

Poskytovatel před podpisem smlouvy připraví popis řešení včetně harmonogramu postupu implementace a akceptačních testů, odhadované pracnosti a potřebné součinnosti Objednatele. Dané řešení musí být použitelné v prostředí Objednatele a před podpisem smlouvy odsouhlasené Objednatelem.

Migrovaná data nesmí opustit prostředí Objednatele.

Migrace bude probíhat v lokalitě Letenská a bude znamenat přenesení dat o celkovém objemu 200TB.

Přibližná struktura dat:

1) VMware 120TB

2) Solaris/Oracle 30TB

3) Samostatné Windows servery 5TB

4) Media záznamy (kamery) 45TB

SPECIFIKACE ŠKOLENÍ

Školení v rozsahu 5 MD zaměřených na SAN technologie a školení v rozsahu 5 MD zaměřených na disková pole s lektorem v českém jazyce v prostředí Zadavatele.

SPECIFIKACE TECHNICKÉ PODPORY

Technická podpora je dílčím předmětem plnění Smlouvy dle čl. II odst. 1 písm. (f). V případě nedodržení lhůt a termínů zde uvedených bude Poskytovatel pokuto- ván dle čl. VII Smlouvy.

Definice pojmů:

Název parametru	Vysvětlení
Vada	Poškození, výpadek provozu, kybernetická bezpečnostní událost (KBU) a incident (KBI), selhání funkce nebo neplnění Předmětu plnění Smlouvy
Nahlášení Vady	Telefonická komunikace Objednatele s pověřenou osobou Poskytovatele, které budou sděleny veškeré informace k vzniklé Vadě včetně kate- gorie závažnosti Vady. Tyto informace včetně času telefonického nahlášení Vady budou Objednatelem neprodleně zaslány přímo Poskytova- teli elektronicky e-mailem nebo budou Objednatelem zadány prostřednictvím odpovídající webové aplikace Poskytovatele (např. Service Desk). Poskytovatel je povinen v době odezvy potvrdit přijetí tohoto e-mailu nebo zadání prostřednictvím webové aplikace a podle kategorie závažnosti Vady zahájit její odstranění.
Odstranění Vady	Je (jsou) úkon(y) technické podpory, kdy dojde k odstranění Vady formou výměny vadného zařízení nebo odstranění Vady opravou až do jejího úplného vyřešení (zprovoznění). Nahlášena Vada bude odstraněna Poskytovatelem, jakožto smluvním partnerem a garantem zajištění technické podpory, případně, je-li to z technických důvodů opodstatněné a stane-li se tak na základě dohody Objednatele s Poskytovatelem, přímo výrobcem zařízení. Zabezpečení úkonů technické podpory výrobcem zařízení nezbavuje Poskytovatele odpovědnosti za dodržení tech- nické podpory dle podmínek Smlouvy.
Limitní doba	Časový údaj specifikující časový interval.
Systém	SAN infrastruktura a disková pole, která byla Předmětem plnění Smlouvy.
Reakční doba	Limitní doba pro zahájení odstraňování Vady.
Doby vyřešení	Limitní doba pro odstranění Vady.
Profylaxe	Pravidelná údržba Systému, jejímž podnětem není Vada, a která je klasifikována jako Servisní podpora (Příloha č. 7, odst. 2). Profylaxe je prováděna v předem stanoveném rozsahu a čase, je prováděna vždy pouze se souhlasem Objednatele.
Smluvní pokuta	Sankce za nedodržení lhůt a povinností Poskytovatele uvedená v čl. VII Smlouvy.

Požadavky a parametry Technické podpory jsou následující:

1) Zajištění možnosti telefonické komunikace 24x7 přímo s technickou podporou výrobce a to v českém, případně slovenském jazyce,

2) Nahlášení Vady telefonicky, zasláním e-mailem Poskytovateli, resp. zadáním prostřednictvím odpovídající webové aplikace Poskytovatele,

3) Zajištění telefonického kontaktu na servisní linku výrobce umožňující komunikaci v českém jazyce

4) Zajištění odstranění Vady dle Tabulky Vad, reakční doby a odstranění Vady bez dalších poplatků Objednatele (výměna je prováděna autorizovaným techni- kem), vadné vyměněné pevné disky zůstanou ve vlastnictví Objednatele,

5) Zajištění dostupnosti 99,909 % celého systému dle Tabulky dostupnosti systému v kalendářním roce, tj. 8 hodin.

6) Evidence Vad podle Xxxxxxx evidence zásahů v Čtvrtletním protokolu technické podpory,

7) Objednatel má nárok na bezpečnostní záplaty i veškeré nové verze SW/FW přímo od výrobce, na základě zaregistrování čísla aktivovaného servisního kon- traktu,

8) Objednatel má zajištěn časově neomezený přístup na webový portál výrobce s přístupem do znalostní databáze, service-deskem, best practices a veškerou doku- mentací k produktům výrobce.

Tabulka Vad, reakční doby a odstranění Vady

Kategorie závažnosti Vady

Stav

Popis

Možnost odstranění Vady objednatelem

Reakční doba

Způsob odstranění Vady poskytovatelem

Doba vyřešení

Velmi kri- tický

Závažná Vada představující ha- varijní poruchu části (celého) systému vedoucí k úplnému vý- padku systému.

KBI – s kritickými dopady na do- stupnost jednotlivé části, důvěr- nost části uložených dat nebo konfigurace, nebo integritu ulo- žených dat nebo konfigurace

Objednatel nemá možnost obejít vzniklou Vadu do- časným řešením.

1 hodina od nahlášení Vady

Odstranění Vady formou výměny vadného zařízení nebo odstranění Vady opravou až do jejího úplného vyřešení.

Okamžitá součinnost s kybernetickou bezpečností Objednatele a poskytnutí podkladů pro analýzu pří- čin KBI

8 hodin od na- hlášení Vady

Kritický

Závažná Vada představující ha- varijní poruchu části systému ve- doucí k částečnému výpadku sys- tému nebo k nedostupnosti části dat.

KBI – s kritickými dopady na do- stupnost jednotlivé části, důvěr- nost části uložených dat nebo konfigurace, nebo integritu ulo- žených dat nebo konfigurace

Objednatel nemá možnost obejít vzniklou Vadu do- časným řešením.

4 hodiny od nahlášení Vady

Odstranění Vady formou výměny vadného zařízení nebo odstranění Vady opravou až do jejího úplného vyřešení.

Okamžitá Součinnost s kybernetickou bezpečností Objednatele a poskytnutí podkladů pro analýzu pří- čin KBI

Do konce ná- sledujícího ka- lendářního dne ode dne nahlá- šení Vady

Velmi zá- važný

Závažná Vada, která činí nor- mální využívání Předmětu plnění

ANO, částečně

8 hodin od na- hlášení Vady

Odstranění Vady formou výměny vadného zařízení nebo odstranění Vady opravou až do jejího úplného

Do 5 pracov- ních dní ode

Smlouvy obtížným a nespolehli- vým.

KBU – se závažnými dopady na dostupnost jednotlivé části, dů- věrnost části uložených dat nebo konfigurace, nebo integritu ulo- žených dat nebo konfigurace.

Možné překlasifikovat na KBI

Objednatel má možnost obejít vzniklou Vadu do- časným náhradním řešením.

vyřešení. V případě náhradního řešení realizované Objednatelem je nutné posouzení spolehlivosti, funkčnosti a dohoda o jeho případném zachování.

Součinnost s kybernetickou bezpečností Objedna- tele a poskytnutí podkladů pro analýzu příčin KBU nebo KBI

dne nahlášení Vady

Méně zá- važný

Méně závažná Vada, která zne- možňuje Objednateli plné využití všech funkcí Předmětu plnění Smlouvy.

KBU – se méně závažnými do- pady na dostupnost jednotlivé

části, důvěrnost části uložených dat nebo konfigurace, nebo inte- gritu uložených dat nebo konfi- gurace.

ANO, částečně Objednatel má možnost obejít

vzniklou Vadu

s minimálním naru- šením standardních pracovních po- stupů.

24 hodin od nahlášení Vady

Odstranění Vady formou výměny vadného zařízení nebo odstranění Vady opravou až do jejího úplného vyřešení. V případě náhradního řešení realizované Objednatelem je nutné posouzení spolehlivosti, funkčnosti a dohoda o jeho případném zachování.

Součinnost s kybernetickou bezpečností Objedna- tele a poskytnutí podkladů pro analýzu příčin KBU

Do 15 pracov- ních dní ode dne nahlášení Vady

Nezávažný

Vada s minimálním dopadem na Předmět plnění Smlouvy, dotazy na speciální funkcionality, pří- padně řešení základních Vad typu

„how-to“.

Není KBU ani KBI

ANO

Objednatel má možnost obejít vzniklou Vadu

s minimálním naru- šením standardních pracovních po- stupů.

24 hodin od nahlášení Vady

Odstranění Vady až do jejího úplného vyřešení. Není požadována součinnost s kybernetickou bez- pečností Objednatele.

Do 20 pracov- ních dní ode dne nahlášení Vady

Tabulka dostupnosti systému v kalendářním roce

Dostupnost vyjádřena v procentech
99,989%	99,977%	99,966%	99,954%	99,943%	99,932%	99,920%	99,909%		99,897%	99,886%	99,875%	99,863%	99,852%
Počet hodin nedostupnosti v kalendářním roce
1	2	3	4	5	6		7	8		9	10	11	12	13

15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	Pořadové číslo
															Datum nahlášení
															Čas nahlášení
															Kategorie závažnosti Vady
															Popis Vady
															Byla dodržena Reakční doba (ANO/NE)
															Pokud nebyla dodržena Reakční doba, Uveďte, proč o kolik byla překročena
															Uveďte popis způsobu odstranění Vady.
															Byla dodržena doba ře- šení (ANO/NE)
															Pokud nebyla dodržena Reakční doba, uveďte proč a o kolik byla překročena
															Vada odstraněna: (ANO / NE / S VÝHRADOU)
															Pokud Vada nebyla od- traněna nebo byla odstra něna s výhradou, uveďte ter- mín, do kdy dojde k ná- pravě.
															Celková doba poruchy / vady

Příloha č. 6 – Specifikace Technické podpory

Tabulka evidence zásahů při technické podpoře pro Čtvrtletní protokol technické podpory (Příloha č. 12)

SPECIFIKACE SERVISNÍ PODPORY

Servisní podporou se rozumí služba údržby a podpory v režimu Pracovní doby, za kterou se pro účely této Smlouvy považuje každý pracovní den od 6,00 do 18,00 hod.

Servisní podpora bude poskytována pouze na základě požadavku Objednatele odeslaném prostřednictvím e-mailu oprávněné osobě Poskytovatele, a to v maximálním rozsahu dvaceti pěti (25) MD za celou dobu trvání Smlouvy. Uvedený počet MD lze čerpat i na Servisní podporu dodatečného Rozšíření Hardware dle článku III. odst. 6 Smlouvy.

Servisní podpora musí být vykonávána osobou/osobami s dostatečnými technickými znalostmi a zkušenostmi v oblasti provozování Hardware.

V rámci Servisní podpory bude v rámci ceny uvedené v čl. VI, odst. 4 písm. c) Xxxxxxx zajištěno:

1) Konzultace prostřednictvím telefonu, a to pouze Oprávněným osobám Objednatele. Tato konzultace bude poskytována v Pracovní době. Předmětem konzultace mohou být

jakékoli aspekty související s provozem Hardware.

2) 2x ročně profylaxe Předmětu plnění uvedeného v čl. II. odst. 1 a) Smlouvy dle termínů požadovaných Objednatelem, v rozsahu fyzické kontroly stavu Hardware, jeho čištění, provedení diagnostických testů, zajištění správného nastavení, kontroly aktuálnosti ovladačů, firmware atd.),

3) Aktualizace provozní dokumentace v případě požadavků Objednatele nespadajících do jiných částí Předmětu plnění

SPECIFIKACE POŽADOVANÉHO ROZŠÍŘENÍ DISKOVÉHO POLE

Na základě potřeby Objednatele a v době platnosti této smlouvy si Objednatel vyhrazuje právo na opci z důvodu Rozšíření diskových polí v lokalitách Letenská, Voctářova a Vápenka a to na základě následujících parametrů.

I. TECHNICKÁ SPECIFIKACE

Požadavky Objednatele		Nabídka Poskytovatele
Volitelné Rozšíření		Označení výrobku (označení výrobce a typu zařízení pro volitelné Rozšíření).
Parametr	Požadavek Objednatele	Popis konkrétního splnění požadavku
Základní parametry	Uveďte minimální počet disků, které je nutné zakoupit pro funkční rozšíření pole.	xxx
	Uveďte, kolik disků se vejde do jedné rozšiřující police.	xxx
	Uveďte doporučení výrobce na poměr datových a spare disků.	xxx
	Uveďte velikost disků v TiB v hrubé kapacitě (raw kapacitě) bez formátování a bez započtení komprese a deduplikace.	xxx
	Uveďte počet disků (včetně nutných licencí), které je možné zakoupit v závislosti na finančním limitu uvedeném v čl. III odst. 6) Smlouvy.	xxx

Poznámka:

1. Objednatel si je vědom, že vyčerpání volných diskových pozic v dodaných diskových polích bude v případě potřeby dalšího Rozšíření nutné dokoupit i další rozšiřující polici.

2. Cena musí obsahovat práci technika na Rozšíření, která obsahuje i konfiguraci diskového pole tak, aby bylo možné novou kapacitu používat a replikovat.

3. Cena musí zahrnovat náklady na SW licence.

PŘEDÁVACÍ PROTOKOL

Objednatel: Česká republika – Ministerstvo financí

se sídlem: Letenská 15, 110 00 Praha 1, Česká republika za niž jedná: xxxxxxxxxx

IČO: 00006947 DIČ: CZ00006947

Poskytovatel: GAPP System, spol. s r.o.

se sídlem Petržílkova 2565/23, 158 00 Praha 5

zapsaný v obchodním rejstříku vedeném u Městského soudu v Praze, oddíl C, vložka 27177

zastoupený: Ing. Xxxxxx Xxxxxxxx IČO: 60487291

DIČ: CZ60487291

Objednatel:

a) potvrzuje tímto převzetí a základní instalaci HW a SW (dále jen „Zboží“), uvedeného v nedílné příloze tohoto protokolu, do prostředí Objednatele v souladu se smlouvou MF č. 19/906/0027 (dále jen „Smlouva“);

b) prohlašuje, že toto Zboží splňuje požadavky Objednatele a technické parametry uvedené ve Smlouvě.

Poskytovatel:

a) zaručuje, že Zboží je funkční a nainstalováno tak, aby vyhovovalo technickým a bezpečnostním normám platným v ČR, jakož i účelu, k němuž bylo objednáno.

Dnem podpisu tohoto předávacího protokolu se zahajuje v souladu se Smlouvou cílová konfigurace a zkušební provoz, který zahrnuje:

a) implementaci,

c) testování,

d) migraci,

e) školení,

f) uvedení systému do rutinního provozu.

Po ukončení zkušebního provozu následuje rutinní provoz s pětiletou technickou a servisní podporou. Seznam příloh: 1. Xxxxxx převzatého zboží

V Praze dne ................... V Praze dne ...................

Za Objednatele: Za Poskytovatele:

Jméno:xxxxxxxxxx		Jméno:xxxxxxxxxx		Jméno: Xxx. Xxxx Xxxxxx
Funkce:xxx		Funkce:xxx		Funkce: Jednatel společnosti

Příloha Předávacího protokolu ke smlouvě MF č. 19/906/0027: SOUPIS PŘEVZATÉHO ZBOŽÍ

Název položky	Výrobní/sériové číslo	Poznámka/výhrada

(…)

AKCEPTAČNÍ PROTOKOL

k předmětu plnění

IMPLEMENTACE a TESTOVÁNÍ

Objednatel: Česká republika – Ministerstvo financí

se sídlem: Letenská 15, 110 00 Praha 1, Česká republika za niž jedná:xxxxxxxxxx

IČO: 00006947 DIČ: CZ00006947

Poskytovatel: GAPP System, spol. s r.o.

se sídlem Petržílkova 2565/23, 158 00 Praha 5

zapsaný v obchodním rejstříku vedeném u Městského soudu v Praze, oddíl C, vložka 27177

zastoupený: Ing. Xxxxxx Xxxxxxxx IČO: 60487291

DIČ: CZ60487291

Objednatel a Poskytovatel tímto potvrzují úspěšné ukončení Testování a Implementace v rozsahu ……..

kalendářních dní od převzetí, instalace a konfigurace Zboží, uvedeného v Příloze č. 9 – Předávací protokol v souladu se Smlouvou.

Splatnost Dílčí ceny podle čl. VI odst. 4 písm. a) Xxxxxxx ve výši 28 753 750, 00 Kč (slovy: dvacet osm milionů sedm set padesát tři tisíc sedm set padesát korun českých) z celkové ceny uvedené v čl. VI odst. 1 Smlouvy, navýšené o DPH, činí v souladu s čl. VI odst. 6) 30 (slovy: třicet) dnů od doručení faktury, vystavené po podpisu tohoto Akceptačního protokolu Implementace a testování.

POZNÁMKY / VÝHRADY:

V Praze dne ................... V Praze dne ...................

Za Objednatele: Za Poskytovatele:

AKCEPTAČNÍ PROTOKOL

k předmětu plnění

MIGRACE a ŠKOLENÍ

Objednatel: Česká republika – Ministerstvo financí

se sídlem: Letenská 15, 110 00 Praha 1, Česká republika za niž jedná: xxxxxxxxxx

IČO: 00006947 DIČ: CZ00006947

Poskytovatel: GAPP System, spol. s r.o.

se sídlem Petržílkova 2565/23, 158 00 Praha 5

zapsaný v obchodním rejstříku vedeném u Městského soudu v Praze, oddíl C, vložka 27177

zastoupený: Ing. Xxxxxx Xxxxxxxx IČO: 60487291

DIČ: CZ60487291

Objednatel a Poskytovatel tímto potvrzují úspěšné ukončení Migrace dat v rozsahu 90 kalendářních dní probíhajících od ukončení Implementace a Testování, uvedených v Příloze č. 10 – Akceptační protokol Testování a Implementace v souladu se Smlouvou.

Objednatel a Poskytovatel tímto potvrzují úspěšné ukončení Školení v rozsahu 5 MD zaměřených na SAN technologie a školení v rozsahu 5 MD zaměřených na disková pole v době 90 kalendářních dní probíhajících od ukončení Implementace a Testování, uvedených v Příloze č. 10 – Akceptační protokol Testování a Implementace v souladu se Smlouvou.

Splatnost Dílčí ceny podle čl. VI odst. 4 písm. b) smlouvy ve výši 693 000,00 Kč (slovy šest set devadesát tři tisíc korun českých) z celkové ceny uvedené v čl. VI odst. 1 Smlouvy, navýšené o DPH, činí 30 (slovy: třicet) dnů od doručení faktury, vystavené po podpisu tohoto Akceptačního protokolu Migrace.

POZNÁMKY / VÝHRADY:

V Praze dne ................... V Praze dne ...................

Za Objednatele: Za Poskytovatele:

ČTVRTLETNÍ PROTOKOL

O POSKYTNUTÉ TECHNICKÉ PODPOŘE

Objednatel: Česká republika – Ministerstvo financí

se sídlem: Letenská 15, 110 00 Praha 1, Česká republika za niž jedná: xxxxxxxxxx

IČO: 00006947; DIČ:CZ00006947

Poskytovatel: GAPP System, spol. s r.o.

se sídlem Petržílkova 2565/23, 158 00 Praha 5

zapsaný v obchodním rejstříku vedeném u Městského soudu v Praze, oddíl C, vložka 27177 zastoupený: Ing. Xxxxxx Xxxxxxxx

IČO: 60487291 DIČ: CZ60487291

Objednatel a Poskytovatel tímto potvrzují, že v rámci smlouvy MF č.19/906/0027 byla od <<datum>> do <<datum>> poskytována technická podpora, v rámci které došlo k následujícímu SEZNAMU ZÁSAHŮ:

Pořadové číslo

Datum nahlášení

Čas nahlášení

Kategorie závažnosti Vady

Popis Vady

Byla dodržena

Reakční doba (ANO/NE)

Pokud nebyla dodržena Reakční doba,

Uveďte, proč

o kolik byla překročena

Uveďte popis způsobu odstranění Vady.

Byla dodržena doba řešení (ANO/NE)

Pokud nebyla dodržena Reakční doba, uveďte proč

a o kolik byla překročena

Vada odstraněna: (ANO / NE /

S VÝHRADOU)

Pokud Vada nebyla odstraněna nebo byla odstraněna

s výhradou, uveďte termín, do kdy dojde k nápravě.

Celková doba poruchy / vady

7
8
9
10
11
12
13
14
15

V Praze dne ………………………… V Praze dne …………………………

Za objednatele: Za Poskytovatele:

Jméno:xxxxxxxxxx

Jméno: xxxxxxxxxx

Jméno: Xxx. Xxxx Xxxxxx

Funkce:xxx

Funkce: Jednatel společnosti

Příloha č. 13 – Čtvrtletní protokol o poskytnuté Servisní podpoře

ČTVRTLETNÍ PROTOKOL

O POSKYTNUTÉ SERVISNÍ PODPOŘE

Objednatel: Česká republika – Ministerstvo financí

se sídlem: Letenská 15, 110 00 Praha 1, Česká republika za niž jedná: xxxxxxxxxx

IČO: 00006947 DIČ: CZ00006947

Poskytovatel: GAPP System, spol. s r.o.

se sídlem Petržílkova 2565/23, 158 00 Praha 5

zapsaný v obchodním rejstříku vedeném u Městského soudu v Praze, oddíl C, vložka 27177

zastoupený: Ing. Xxxxxx Xxxxxxxx IČO: 60487291

DIČ: CZ60487291

Objednatel a Poskytovatel tímto potvrzují, že v rámci smlouvy MF č.19/906/0027 byla od <<datum>> do

<<datum>> poskytována v rozsahu << počet MD>> servisní podpora, v rámci které došlo k následujícím zásahům:

<<seznam zásahů>>

V Praze dne ................... V Praze dne ...................

Za Objednatele: Za Poskytovatele:

Jméno:xxxxxxxxxx		Jméno: xxxxxxxxxx		Jméno: Xxx. Xxxx Xxxxxx
Funkce:xxx		Funkce: xxx		Funkce: Jednatel společnosti

SPECIFIKACE DWDM technologie Objednatele

xxx

Vzdálenosti a latence na linkách mezi jednotlivými lokalitami jsou tyto:

LINKA	VZDÁLENOST	LATENCE
xxx	xxx	xxx
xxx	xxx	xxx
xxx	xxx	xxx
xxx	xxx	xxx
xxx	xxx	xxx
xxx	xxx	xxx
xxx	xxx	xxx
xxx	xxx	xxx

xxx xxx xxx

xxx
xxx	xxx	xxx

xxx

LINKA	POČTY PORTŮ
xxx	xxx
xxx	xxx
xxx	xxx
xxx	xxx
xxx	xxx
xxx	xxx

xxx

Poskytovatelem dodané a implementované řešení (Systém) musí být s touto DWDM technologií plně kompatibilní.

SPECIFIKACE EXITOVÉHO PLÁNU

Exitovým plánem se rozumí povinnost Poskytovatele poskytnout Objednateli veškerou nezbytnou součinnost při řádném i předčasném ukončení Smlouvy, jejímž cílem je skutečná možnost Objednatele provozovat nadále Hardware (včetně souvisejícího plnění) bez větších obtíží samostatně či ve spolupráci s třetí osobou.

Poskytovatel se tak v rámci Exitového plánu především zavazuje Objednateli poskytnout:

1. Podrobný seznam dodaného HW a SW,

2. Záruční listy k dodanému HW,

3. Licence a licenční ujednání pro dodaný SW,

4. Licenční klíče včetně odkazů na příslušné weby, kde se nacházejí další informace k danému SW,

5. Dokumentace k HW a SW,

6. Příslušné manuály,

7. Informace o přístupových právech,

8. Informace o výrobcích HW a SW včetně kontaktů,

9. Zdrojový kód, pokud je ve smlouvě zahrnuté předání zdrojového kódu,

10. Předávací protokoly a evidenci zásahů při technické a softwarové podpoře vždy v nejaktuálnější a bezchybné verzi.

Součástí Exitového plánu dále musí být:

1. Ustanovení o rozsahu součinnosti Poskytovatele a Objednatele nezbytné pro dosažení cíle Exitového plánu.

2. Časový rozvrh předání HW, SW, dokumentace a dalších smluvně dodaných částí.

3. Ustanovení ohledně dalšího postupu, pokud by se ukázalo, že některé výše uvedené kroky jsou neproveditelné (např. některá část potřebné dokumentace schází).

Document Metadata

Table of Contents

SMLOUVA‌

Document Metadata