DODATEČNÉ INFORMACE č. 15 k zadávacím podmínkám

Transkript

1 MĚSTSKÁ ČÁST PRAHA 4 ÚŘAD MĚSTSKÉ ČÁSTI Odbor právní Oddělení veřejných zakázek DODATEČNÉ INFORMACE č. 5 k zadávacím podmínkám v zadávacím řízení č. VZN/5/004 vedeném v užším řízení k zadání nadlimitní veřejné zakázky na služby uveřejněné ve věstníku veřejných zakázek pod evid. číslem 56945: Zajištění externího správce, tj. outsourcing informačních technologií a služeb Níže uvedený zadavatel tímto sděluje dodatečné informace v souladu s ust. 49 zákona č. 37/2006 Sb., o veřejných zakázkách, v platném znění (dále jen zákon): Identifikační údaje veřejného zadavatele: Název zadavatele: Městská část Praha 4 Sídlo zadavatele: Praha 4, Antala Staška 2059/80b IČ: DIČ: CZ Právní forma: městská část hlavního města Prahy Osoba oprávněná jednat jménem zadavatele: JUDr. Pavel Šimice, vedoucí odboru právního Zadavatel obdržel dne následující dotazy dodavatele k zadávacím podmínkám ve shora uvedeném zadávacím řízení a sděluje tímto své odpovědi na tyto dotazy. Dotaz č. (přesné znění): V dokumentu Rámcová smlouva, kapitola III., odst. 3 zadavatel uvádí: Obě strany vycházejí z toho, že součástí povinností poskytovatele je i péče o zařízení umístěné v prostorách, k nimž bude mít přístup pouze poskytovatel. Zadavatel je povinen zajistit, aby k těmto prostorám neměl přístup nikdo jiný, tj. ani jeho zaměstnanci či jiné osoby, které pracují pro zadavatele; klíče a jiné přístupové prostředky předá poskytovateli. Chápe uchazeč správně, že žlutě označené doplní zadavatel před podpisem smlouvy? Odpověď zadavatele na dotaz č. : Ano, zadavatel tento údaj doplní před podpisem smlouvy. Dotaz č. 2 (přesné znění): V příloze č. 3 Zadávací dokumentace - Technická specifikace v tabulkách H. Firewall - serverová zóna a I. Firewall - internetová zóna v řádcích 3 zadavatel požaduje min. x expansion slot. Jakou funkci má získat firewall prostřednictvím osazeného expanzního slotu, resp. k jakému účelu hodlá zadavatel expanzní slot využívat? Stránka z 37

2 Odpověď zadavatele na dotaz č. 2: Zadavatel míní v budoucnu využít expanzní slot pro navýšení výkonu tohoto prvku, bez nutnosti náhrady. Tento požadavek je definován v přímé souvislosti s ochranou investic zadavatele. Dotaz č. 3 (přesné znění): V příloze č. 3 Zadávací dokumentace - Technická specifikace v kapitole.3 HelpDesk je provozovaný Help Desk popisován jako jediný nástroj. Jaký přibližně počet požadavků za měsíc zadavatel předpokládá? Pokud není možné tento údaj odhadnout, je možné poskytnout průměrný počet nynějších požadavků? Odpověď zadavatele na dotaz č. 3: Zadavatel na základě současných zkušeností předpokládá přibližný počet požadavků do výše 500 požadavků za období jednoho měsíce. Dotaz č. 4 (přesné znění): V dokumentu Rámcová smlouva v kapitole VI. - Výkonové standardy systémů je v tabulce uveden požadavek na správu systémového vybavení a systémového software. Není již toto zahrnuto v administraci hardware, síťového prostředí, operačních systémů, databází, informačních systémů a aplikací (Administrace systémů) a provozu hardware, síťového prostředí, operačních systémů, databází, informačních systémů a aplikací (Administrace systémů)? Může zadavatel vysvětlit co správou systémového vybavení a systémového software myslí, např. uvést konkrétní případ? Odpověď zadavatele na dotaz č. 4: Zadavatel opravuje chybu psaní. Nahrazuje v Rámcové smlouvě v kapitole VI. - Výkonové standardy systémů v tabulce současný text: správa systémového vybavení a systémového software textem: správa programového vybavení v souvislosti s poskytováním dodatečných rozvojových činností Dotaz č. 5 (přesné znění): V dokumentu Zadávací dokumentace, v kapitole 2..c) hodnotící subkritérium ad ) Kvalita, technické úroveň navrhovaného řešení, Zadavatel uvádí: Za nejlépe hodnocené bude považováno to řešení, které bude v souhrnu nejlépe a nejúplněji pokrývat rozsah potřeb a požadavků zadavatele. Takové řešení musí svými funkčními vlastnostmi jako celek, jednak splnit požadavky zadavatele a vytvoří užitné vlastnosti pro technologicky vyšší úroveň provozního prostředí. Dotazy uchazeče: Technické a funkční vlastnosti řešení nabízeného uchazečem je hodnoceno v rámci hodnotícího kritéria 2..b). Uchazeč žádá zadavatele o potvrzení, že nedochází k průniku hodnotících kritérií 2..b) a 2..c), subkritérium. Hodnotící kritérium 2..c), subkritérium je definováno velice obecně. Uchazeč žádá zadavatele o jasnou definici, co a jak bude zadavatelem v rámci tohoto hodnotícího subkritéria vyhodnocováno, vč. způsobu přidělování bodů. Odpověď zadavatele na dotaz č. 5: Zadavatel ujišťuje uchazeče, že při nedochází k průniku. Na základě odstavce 2.. b) jsou hodnoceny dílčí vybrané technické parametry nabízeného řešení (dle naplnění jednotlivých kritérií v tabulkách) obsahující specifikaci požadovaných parametrů HW a SW. U kritéria 2.. c) - 2/37 -

3 subkritéria ) je hodnoceno řešení navrhované uchazečem, které vytváří užitné vlastnosti pro technologicky vyšší úroveň provozního prostředí. Zadavatel uvádí, že řešení navrhovaná uchazeči budou hodnocena v oblastech plynoucích ze zadávací dokumentace (za každou oblast 0 bodů): logické řešení funkcí síťové vrstvy řešení přístupové vrstvy serverové zóny řešení SAN infrastruktury řešení serverové infrastruktury řešení Disaster Recovery řešení datových úložišť řešení zálohovacího systému řešení archivního systému Nejvýhodnější nabídka v daném dílčím hodnotícím subkritériu získá maximální dosažitelný počet bodů, ostatní nabídky získají poměrný počet bodů vyjadřující kvalitu nabídky oproti nejlepší nabídce v daném dílčím hodnotícím subkritériu, Získané body budou poměrově přepočteny na hodnotu váhy subkritéria. Dotaz č. 6 (přesné znění): V dokumentu Zadávací dokumentace, v kapitole 2..c) hodnotící subkritérium ad 2) Kvalita navrhovaného řešení z pohledu vysoké dostupnosti, Zadavatel uvádí: Za nejlépe hodnocené řešení bude považováno to řešení, jehož technologická úroveň pokryje co nejvíce slabých míst (SPoF - Single Point of Failure) způsobující provozní rizika a jejich eliminací nejlépe zajistí vysokou provozní dostupnost. Dotazy uchazeče: Dostupnost řešení nabízeného uchazečem je dle názoru uchazeče již hodnocena v rámci hodnotícího kritéria 2..b) Technické a funkční vlastnosti dodávaného hardware a software. Uchazeč žádá zadavatele o potvrzení, že nedochází k průniku hodnotících kritérií 2..b) a 2..c), sukrtitérium 2. Hodnotící kritérium 2..c), subkritérium 2 je definováno velice obecně. Uchazeč žádá zadavatele o jasnou definici, co a jak bude zadavatelem v rámci tohoto hodnotícího subkritéria vyhodnocováno (např. požadované SLA) vč. způsobu přidělování bodů. Odpověď zadavatele na dotaz č. 6: Zadavatel ujišťuje uchazeče, že při nedochází k průniku. Na základě tohoto subkritéria, bude řešení předložené uchazečem hodnoceno jako celek, a to z pohledu uvedeného v bodě 2) Kvalita navrhovaného řešení z pohledu vysoké dostupnosti, v bodové stupnici 30 bodů. Nejvýhodnější nabídka v daném dílčím hodnotícím subkritériu získá maximální dosažitelný počet bodů, ostatní nabídky získají poměrný počet bodů vyjadřující kvalitu nabídky oproti nejlepší nabídce v daném dílčím hodnotícím subkritériu. Získané body budou přepočteny na hodnotu váhy subkritéria. Dotaz č. 7 (přesné znění): V dokumentu Zadávací dokumentace, v kapitole 2..c) hodnotící subkritérium ad 3) Návrh způsobu implementace, Zadavatel uvádí: Za nejlépe hodnocené bude považováno řešení, které bude mít zpracován reálný projektový plán implementace dodávaných systémů v rámci technického konceptu řešení, obsahující jednotlivé dílčí realizační kroky, jejich logické vazby, obecné požadavky na součinnost. Za nejlepší řešení bude považován projektový plán s nejkratším termínem realizace. Dotazy uchazeče: - 3/37 -

4 nebo Uchazeč žádá zadavatele o sdělení, které řešení bude lépe hodnocené řešení, které: o bude mít zpracován reálný projektový plán implementace s množstvím dílčích kroků, logických vazeb, apod. o bude mít zpracován obecný projektový plán s nejkratším termínem realizace Hodnotící kritérium 2..c), subritérium 3 je definováno velice obecně. Uchazeč žádá zadavatele o jasnou definici, co a jak bude zadavatelem v rámci tohoto hodnotícího subkritéria vyhodnocováno vč. způsobu přidělování bodů. Dle výše uvedené formulace uchazeč usuzuje, že projektovým plánem je myšlen pouze harmonogram implementace, nikoli metodický dokument projektového řízení. Usuzuje uchazeč správně? Odpověď zadavatele na dotaz č. 7: Zadavatel požaduje zpracování projektového plánu (harmonogram implementace) s tím, že nejlépe hodnocený návrh způsobu implementace v rámci nabídky uchazeče bude řešení, které bude mít odraz ve zpracovaném reálném projektovém plánu implementace dodávaných systémů v rámci technického konceptu řešení, obsahující jednotlivé dílčí realizační kroky, jejich logické vazby, obecné požadavky na součinnost a současně dosáhne nejkratšího termínu realizace. Za reálný projektový plán je považován takový postup, který minimálně omezí chod úřadu zadavatele. V bodové stupnici 20 bodů bude hodnocen projektový plán obsahující komplexnost postupů a vzájemných vazeb implementace v rámci nejkratšího času, v daném dílčím hodnotícím subkritériu získá maximální dosažitelný počet bodů, ostatní nabídky získají poměrný počet bodů vyjadřující kvalitu nabídky oproti nejlepší nabídce v daném dílčím hodnotícím subkritériu. Získané body budou přepočteny na hodnotu váhy subkritéria. Dotaz č. 8 (přesné znění): Uchazeč po uskutečněné prohlídce na lokalitě Jílovská podotýká, že požadovaný systém zhášení (SHZ) by v případě své aktivace mohl poškodit některé konstrukční prvky dané serverové místnosti (zejména se jedná o celou stěnu se vstupními dveřmi). Uchazeč se táže zadavatele, zda zvažoval při vytváření technických podmínek ZD i tuto stránku, tedy nutnou stavební rekonstrukci výše zmíněné části a pokud ne, jak hodlá tuto skutečnost řešit (je nutné mít konstrukčně postavenou místnost tak, aby SHZ dávala smysl). Odpověď zadavatele na dotaz č. 8: Zadavatel předpokládá stavebně konstrukční úpravu místnosti v závislosti na vítězné nabídce uchazeče. Dotaz č. 9 (přesné znění): Uchazeči není jasné rozdělování bodů u některých řádků v tabulkách Přílohy č. 3 Zadávací dokumentace - Technická specifikace. Může zadavatel uchazeči vysvětlit postup rozdělování bodů u těchto požadavků: a) Tabulka F. Přepínače DISTRIBUTION vrstvy - 4/37 -

5 2 Architektura: 5 6 Feature: Plně redundantní GE LAN infrastruktura - 2 redundantní stacky min MAC min IPv4 položek směrovací tabulky 7 podpora IEEE802.q 8 podpora IEEE 802.X - Port Based Network Access Control 9 min. počet VLAN podpora jumbo rámců podpora QoS 2 podpora DHCP relay 3 4 Integrovaná funkcionalita WiFi kontroleru Podpora distribuovaných bezdrátových vlastností (mobility) v přepínači, řízených centrálním kontrolerem 5 podpora technologie stack 6 podpora IEEE 802.3ad, LACP 7 podpora multicast, IGMP v, v2, v3 8 podpora RMON 9 podpora spanning tree, PVST podpora směrovacích protokolů RIP v-v2, OSPFv2-v3, BGPv4 IEEE 802.x autentizace i autorizace více koncových zařízení na jednom portu IEEE 802.x autentizace přepínače vůči nadřazenému přepínači, sdílení ověření koncových stanic konfigurovatelná kombinace pořadí postupného ověřování zařízení na portu (IEEE 802.x, MAC adresou, Web autentizací) ověřování dle IEEE 802.x volitelně bez omezování přístupu (pro monitoring a snadné nasazení 802.x) Klasifikace bezpečnostní role přistupujícího uživatele nebo koncového zařízení a její propagace sítí (např. Security Group Exchange Protocol dle RFC draft-smithkandula-sxp-0 nebo funkčně ekvivalentní). Detekce parametrů připojovaného koncového zařízení a jejich sdílení s policy serverem Měření a ovládání spotřeby energie připojených koncových zařízení a infrastruktury Podpora určování polohy klienta, rozšíření WiFi systému pro určování polohy klienta i v pevné LAN síti (například Network Mobility Service Protocol - NMSP) Zadavatel svým minimální požadavkem jasně stanovil, jak si představuje architekturu. Vzhledem k tomu, že zadavatel musí zvažovat i ekonomickou stránku věci, není uchazeči jasné, jakým způsobem by měl nabídnout takovou nabídku, která v tomto bodě bude nejlepší a navrhuje zadavateli změnu z na posouzení. V případě, že zadavatel trvá na, uchazeč žádá o jasné vysvětlení cíle zadavatele, a jak hodlá posuzovat nejlepší řešení mezi uchazeči. Uchazeči není jasné, jakým způsobem bude zadavatel vyhodnocovat nejlepší nabídku mezi uchazeči. Jelikož se jedná o minimální požadavky, všichni uchazeči je musí splnit. V případě, že jeden uchazeč nabídne jednu feature, která zde není popsána navíc a druhý uchazeč nabídne jinou feature nad rámec minimálních požadavků, uchazeči není jasno, jakým způsobem a na základě čeho zadavatel vyhodnotí nejlepší nabídku. Uchazeč doporučuje zadavateli změnit z na posouzení. V případě, že zadavatel na trvá, uchazeč žádá o vysvětlení způsobu. - 5/37 -

6 29 Inzerce služeb pomocí Apple Bonjour protokolu i mezi VLANy 30 Ports: Osazení min. 24 x SFP GE port, 2 x 0 GE SFP+ Zadavatel svým minimální požadavkem jasně stanovil, jak si představuje architekturu. Vzhledem k tomu, že zadavatel musí zvažovat i ekonomickou stránku věci, není uchazeči jasné, jakým způsobem by měl nabídnout takovou nabídku, která v tomto bodě bude nejlepší a navrhuje zadavateli změnu z na posouzení. V případě, že zadavatel trvá na, uchazeč žádá o jasné vysvětlení cíle zadavatele, a jak hodlá posuzovat nejlepší řešení mezi uchazeči. - 6/37 -

7 b) Tabulka G. Směrovače CORE vrstvy 2 Architektura: 4 5 Plně redundantní 0GE LAN infrastruktura - 2 redundantní switche min MAC min IPv4 položek směrovací tabulky 6 podpora IEEE802.q 7 podpora IEEE 802.X - Port Based Network Access Control min. počet VLAN podpora jumbo rámců Zadavatel svým minimální požadavkem jasně stanovil, jak si představuje architekturu. Vzhledem k tomu, že zadavatel musí zvažovat i ekonomickou stránku věci, není uchazeči jasné, jakým způsobem by měl nabídnout takovou nabídku, která v tomto bodě bude nejlepší a navrhuje zadavateli změnu z na posouzení. V případě, že zadavatel trvá na, uchazeč žádá o jasné vysvětlení cíle zadavatele, a jak hodlá posuzovat nejlepší řešení mezi uchazeči. 9 podpora QoS 0 podpora DHCP relay podpora technologie stack 2 podpora IEEE 802.3ad, LACP 3 podpora multicast, IGMP v, v2, v3 4 Feature: podpora RMON 5 podpora spanning tree, PVST Ports: podpora směrovacích protokolů RIP v-v2, OSPFv2-v3, BGPv4 Klasifikace bezpečnostní role přistupujícího uživatele nebo koncového zařízení a její propagace sítí (např. Security Group Exchange Protocol dle RFC draft-smith-kandulasxp-0 nebo funkčně ekvivalentní). Detekce parametrů připojovaného koncového zařízení a jejich sdílení s policy serverem Měření a ovládání spotřeby energie připojených koncových zařízení a infrastruktury Inzerce služeb pomocí Apple Bonjour protokolu i mezi VLANy min. 48 metalic 0/00/ min. 4 x 0 GB SFP+ Uchazeči není jasné, jakým způsobem bude zadavatel vyhodnocovat nejlepší nabídku mezi uchazeči. Jelikož se jedná o minimální požadavky, všichni uchazeči je musí splnit. V případě, že jeden uchazeč nabídne jednu feature, která zde není popsána navíc a druhý uchazeč nabídne jinou feature nad rámec minimálních požadavků, uchazeči není jasno, jakým způsobem a na základě čeho zadavatel vyhodnotí nejlepší nabídku. Uchazeč doporučuje zadavateli změnit z na na trvá, uchazeč žádá o vysvětlení způsobu. Uchazeč vychází z domněnky, že zadavatel hodlá hodnotit jednotlivé nabídky na základě počtu portů (čím více, tím lepší o). V případě, že tomu tak je, uchazeč však podotýká, že na základě počtu portů, které pak zadavatel nebude schopen nikdy ani využít je vlastně zcela nelogické a je v rozporu s dalším hlediskem a to ekonomickým. Pokud stejně budou uvažovat ostatní uchazeči, budou nabídky totožné. Jak pak hodlá zadavatel tyto jednotlivé body hodnotit? Pokud je předpoklad uchazeče mylný, uchazeč žádá o jasné vysvětlení těchto bodů. Uchazeč žádá zadavatele o - 7/37 -

8 23 min. 2 x Gb SFP zvážení změny z na posouzení. c) Tabulka H. Firewall - serverová zóna Zadavatel svým minimální požadavkem jasně stanovil, jak si představuje architekturu. Vzhledem k tomu, že zadavatel musí zvažovat i ekonomickou stránku věci, není 2 Architektura: uchazeči jasné, jakým způsobem by Plně redundantní infrastruktura - 2 měl nabídnout takovou nabídku, která redundantní firewall v tomto bodě bude nejlepší a navrhuje zadavateli změnu z na posouzení. V případě, že zadavatel trvá na, uchazeč žádá o jasné vysvětlení cíle zadavatele, a jak hodlá posuzovat nejlepší řešení mezi uchazeči. 3 Stateful inspection min. 2,5 Gb.) Uchazeč nerozumí postupu zadavatele, proč jednotlivé vlastnosti 4 IPS min 800Mbps u Firewally v těchto bodech posuzuje zvlášť a obdobně vlastnosti u jiných 5 IPSEC VPN peerů min 2000 prvků (jako např. switche) hodnotí 6 Concurency spojení min dohromady. Jedná se o vlastnosti daných prvků a jednou je a zadavatel hodnotí dohromady a podruhé zvlášť. Čeho tím zadavatel chce docílit a co je přínosem? Sjednotí zadavatel tento způsob? Propustnost 7 redundance A/A, A/S 3 Expansions: min. x expansion slot 2.) Uchazeč dále nechápe, jaký přínos bude mít nabídek mezi sebou na základě "čím větší, tím lepší". Takové je v rozporu s ekonomickým pohledem, nehledě na to, že větší hodnoty zadavatel ve skutečnosti pak ani nikdy nebude moct využít. Uchazeč považuje tyto hodnoty jako hodnoty k posouzení a ne k a žádá zadavatele o zvážení změny z na posouzení. V případě, že zadavatel trvá na, uchazeč žádá o jasné vysvětlení cíle (proč tak chce hodnotit) a jak bude jednotlivé nabídky posuzovat, aby mohl nabídnout co nejlepší řešení. Uchazeč vychází z domněnky, že zadavatel hodlá hodnotit jednotlivé nabídky na základě počtu (čím více, tím lepší o). Dle názoru uchazeče má být tento požadavek brán jako povinný pro splnění a ne jako minimální a má být čistě k posouzení, jelikož čím větší počet v rámci tohoto bodu uchazeči nabídnou, tím dražší řešení bude zadavateli nabízeno a bude v rozporu s ekonomickým pohledem a přínosem pro celou infrastrukturu (jinak řečeno, větší počty by mohli být naprosto zbytečné). Uchazeč žádá zadavatele zvážení tohoto bodu z na posouzení. V případě, že zadavatel trvá na, uchazeč žádá o jasné vysvětlení cíle (proč tak chce hodnotit) a jak bude jednotlivé nabídky posuzovat, aby mohl nabídnout co nejlepší řešení. - 8/37 -

9 4 Ports min. 8 x Gb Uchazeč vychází z domněnky, že zadavatel hodlá hodnotit jednotlivé nabídky na základě počtu (čím více, tím lepší o). Dle názoru uchazeče má být tento požadavek brán jako povinný pro splnění a ne jako minimální a má být čistě k posouzení, jelikož čím větší počet v rámci tohoto bodu uchazeči nabídnou, tím dražší řešení bude zadavateli nabízeno a bude v rozporu s ekonomickým pohledem a přínosem pro celou infrastrukturu (jinak řečeno, větší počty by mohli být naprosto zbytečné). Uchazeč žádá zadavatele zvážení tohoto bodu z na trvá na, uchazeč žádá o jasné vysvětlení cíle (proč tak chce hodnotit) a jak bude jednotlivé nabídky posuzovat, aby mohl nabídnout co nejlepší řešení. d) Tabulka I. Firewall - internetová zóna Zadavatel svým minimální požadavkem jasně stanovil, jak si představuje architekturu. Vzhledem k tomu, že zadavatel musí zvažovat i ekonomickou stránku věci, není 2 Architektura: uchazeči jasné, jakým způsobem by Plně redundantní infrastruktura - 2 měl nabídnout takovou nabídku, která redundantní firewall v tomto bodě bude nejlepší a navrhuje zadavateli změnu z na posouzení. V případě, že zadavatel trvá na, uchazeč žádá o jasné vysvětlení cíle zadavatele, a jak hodlá posuzovat nejlepší řešení mezi uchazeči. 3 Stateful inspection min.,5 Gb.) Uchazeč nerozumí postupu zadavatele, proč jednotlivé vlastnosti 4 IPS min. 500Mbps u Firewally v těchto bodech posuzuje zvlášť a obdobně vlastnosti u jiných 5 IPSEC VPN peerů min. 700 prvků (jako např. switche) hodnotí 6 Concurency spojení min dohromady. Jedná se o vlastnosti daných prvků a jednou je zadavatel hodnotí dohromady a podruhé zvlášť. Čeho tím zadavatel chce docílit a co je přínosem? Sjednotí zadavatel tento způsob? Propustnost 7 redundance A/A, A/S 2.) Uchazeč dále nechápe, jaký přínos bude mít nabídek mezi sebou na základě "čím větší, tím lepší". Takové je v rozporu s ekonomickým pohledem, nehledě na to, že větší hodnoty zadavatel ve skutečnosti pak ani nikdy nebude moct využít. Uchazeč považuje tyto hodnoty jako hodnoty k posouzení a ne k a žádá zadavatele o zvážení změny z na trvá na, uchazeč žádá o jasné vysvětlení cíle (proč tak chce hodnotit) a jak bude jednotlivé nabídky posuzovat, aby mohl nabídnout co nejlepší řešení. - 9/37 -

10 3 Expansions: min. x expansion slot 4 Ports min. 8 x Gb Uchazeč vychází z domněnky, že zadavatel hodlá hodnotit jednotlivé nabídky na základě počtu (čím více, tím lepší o). Dle názoru uchazeče má být tento požadavek brán jako povinný pro splnění a ne jako minimální a má být čistě k posouzení, jelikož čím větší počet v rámci tohoto bodu uchazeči nabídnou, tím dražší řešení bude zadavateli nabízeno a bude v rozporu s ekonomickým pohledem a přínosem pro celou infrastrukturu (jinak řečeno, větší počty by mohli být naprosto zbytečné). Uchazeč žádá zadavatele zvážení tohoto bodu z na trvá na, uchazeč žádá o jasné vysvětlení cíle (proč tak chce hodnotit) a jak bude jednotlivé nabídky posuzovat, aby mohl nabídnout co nejlepší řešení. Uchazeč vychází z domněnky, že zadavatel hodlá hodnotit jednotlivé nabídky na základě počtu (čím více, tím lepší o). Dle názoru uchazeče má být tento požadavek brán jako povinný pro splnění a ne jako minimální a má být čistě k posouzení, jelikož čím větší počet v rámci tohoto bodu uchazeči nabídnou, tím dražší řešení bude zadavateli nabízeno a bude v rozporu s ekonomickým pohledem a přínosem pro celou infrastrukturu (jinak řečeno, větší počty by mohli být naprosto zbytečné). Uchazeč žádá zadavatele zvážení tohoto bodu z na trvá na, uchazeč žádá o jasné vysvětlení cíle (proč tak chce hodnotit) a jak bude jednotlivé nabídky posuzovat, aby mohl nabídnout co nejlepší řešení. - 0/37 -

11 e) Tabulka J. Přepínač - WAN 3 min MAC 4 podpora IEEE 802.q 5 podpora IEEE 802.X - Port Based Network Access Control 6 min. počet VLAN podpora jumbo rámců 8 podpora IEEE 802.3ad, LACP 9 podpora multicast, IGMP v, v2, v3 0 podpora spanning tree, PVST 2 3 QoS minimální počet přepínačů ve stohu - 8 IP alias (více IP sítí na jednom rozhraní) 4 QoS i na stohovacím propoji 5 DHCP relay 6 Certifikace IPv6 ready logo Phase II 7 IPv6 ACL 8 IPv6 QoS 9 IPv6 services ( DNS, Telnet, SSH, Syslog, ICMP) 20 HTTP, SNMP over IPv6 2 RADIUS, TACACS+ over IPv6 22 IPv6 MLDv2 snooping 23 Feature: IPv6 Port ACL 24 IPv6 First Hop Security RA guard IPv6 First Hop Security DHCPv6 guard IPv6 First Hop Security IPv6 Binding Integrity Guard IEEE 802.x autentizace i autorizace více koncových zařízení na jednom portu IEEE 802.x autentizace přepínače vůči nadřazenému přepínači, sdílení ověření koncových stanic konfigurovatelná kombinace pořadí postupného ověřování zařízení na portu (IEEE 802.x, MAC adresou, Web autentizací) ověřování dle IEEE 802.x volitelně bez omezování přístupu (pro monitoring a snadné nasazení 802.x) Klasifikace bezpečnostní role přistupujícího uživatele nebo koncového zařízení a její propagace sítí (např. Security Group Exchange Protocol dle RFC draft-smith-kandulasxp-0 nebo funkčně ekvivalentní). Detekce parametrů připojovaného koncového zařízení a jejich sdílení s policy serverem Měření a ovládání spotřeby energie připojených koncových zařízení a infrastruktury NetFlow v9 (nebo IPFIX RFC 397, RFC 3955) Uchazeči není jasné, jakým způsobme, bude zadavatel vyhodnocovat nejlepší nabídku mezi uchazeči. Jelikož se jedná o minimální požadavky, všichni uchazeči je musí splnit. V případě, že jeden uchazeč nabídne jednu feature, která zde není popsána navíc a druhý uchazeč nabídne jinou feature nad rámec minimálních požadavků, uchazeči není jasno, jakým způsobem a na základě čeho zadavatel vyhodnotí nejlepší nabídku. Uchazeč doporučuje zadavateli změnit z na posouzení. V případě, že zadavatel na trvá, uchazeč žádá o vysvětlení způsobu. - /37 -

12 DHCP server Sběr dat pro NetFlow nebo IPFIX export z každého portu přepínače Detailní flexibilní definice "flow" dle L2, L3 i L4 parametrů 38 Ports: min. 24 x 0/00/000 Uchazeč vychází z domněnky, že zadavatel hodlá hodnotit jednotlivé nabídky na základě počtu (čím více, tím lepší o). Dle názoru uchazeče má být tento požadavek brán jako povinný pro splnění a ne jako minimální a má být čistě k posouzení, jelikož čím větší počet v rámci tohoto bodu uchazeči nabídnou, tím dražší řešení bude zadavateli nabízeno a bude v rozporu s ekonomickým pohledem a přínosem pro celou infrastrukturu (jinak řečeno, větší počty by mohli být naprosto zbytečné). Uchazeč žádá zadavatele zvážení tohoto bodu z na trvá na, uchazeč žádá o jasné vysvětlení cíle (proč tak chce hodnotit) a jak bude jednotlivé nabídky posuzovat, aby mohl nabídnout co nejlepší řešení. f) Tabulka K. Směrovač - WAN 2 Architektura: 5 Plně redundantní infrastruktura - 2 redundantní směrovače podpora VRRP 6 podpora 802.q 7 podpora OSPFv2, RIP v, v2, BGPv4, 8 4 byte AS numbers in BGP 9 Feature: podpora SNMP, 0 podpora multicast, PIM podpora IPv4, IPv6 2 podpora QoS 3 podpora policy routing Zadavatel svým minimální požadavkem jasně stanovil, jak si představuje architekturu. Vzhledem k tomu, že zadavatel musí zvažovat i ekonomickou stránku věci, není uchazeči jasné, jakým způsobem by měl nabídnout takovou nabídku, která v tomto bodě bude nejlepší a navrhuje zadavateli změnu z na posouzení. V případě, že zadavatel trvá na, uchazeč žádá o jasné vysvětlení cíle zadavatele, a jak hodlá posuzovat nejlepší řešení mezi uchazeči. Uchazeči není jasné, jakým způsobme, bude zadavatel vyhodnocovat nejlepší nabídku mezi uchazeči. Jelikož se jedná o minimální požadavky, všichni uchazeči je musí splnit. V případě, že jeden uchazeč nabídne jednu feature, která zde není popsána navíc a druhý uchazeč nabídne jinou feature nad rámec minimálních požadavků, uchazeči není jasno, jakým způsobem a na základě čeho zadavatel vyhodnotí nejlepší nabídku. Uchazeč doporučuje zadavateli změnit z na posouzení. V případě, že zadavatel na trvá, uchazeč žádá o vysvětlení způsobu. - 2/37 -

13 4 Ports 4 x Gb Zadavatel tento bod nehodlá posuzovat ani hodnotit, přičemž v předchozích tabulkách počet portů hodnotit chce. Uchazeč předpokládá, že se jedná o písařskou chybu a žádá zadavatele o nápravu. V případě, že zadavatel chce i tento bod hodnotit (ne pouze posuzovat), uchazeč pokládá následující hodnotu již předem: Uchazeč vychází z domněnky, že zadavatel hodlá hodnotit jednotlivé nabídky na základě počtu (čím více, tím lepší o). Dle názoru uchazeče má být tento požadavek brán jako povinný pro splnění a ne jako minimální a má být čistě k posouzení, jelikož čím větší počet v rámci tohoto bodu uchazeči nabídnou, tím dražší řešení bude zadavateli nabízeno a bude v rozporu s ekonomickým pohledem a přínosem pro celou infrastrukturu (jinak řečeno, větší počty by mohli být naprosto zbytečné). Uchazeč žádá zadavatele zvážení tohoto bodu z na trvá na, uchazeč žádá o jasné vysvětlení cíle (proč tak chce hodnotit) a jak bude jednotlivé nabídky posuzovat, aby mohl nabídnout co nejlepší řešení. g) Tabulka L. 0GE infrastruktura přístupová vrstva serverové zóny - Primární lokalita 2 Architektura: Plně redundantní 0GE LAN infrastruktura - 2 redundantní switche Pokrytí potřeb odpovídajícího redundantního propojení min. 8 ks blade serverů a primárního datového úložiště s minimálně 6x 0GE porty pro venkovní komunikaci, podpora implementovaného virtualizačního prostředí, replikaci do DR lokality a replikaci zálohování, Zadavatel svým minimální požadavkem jasně stanovil, jak si představuje architekturu. Vzhledem k tomu, že zadavatel musí zvažovat i ekonomickou stránku věci, není uchazeči jasné, jakým způsobem by měl nabídnout takovou nabídku, která v tomto bodě bude nejlepší a navrhuje zadavateli změnu z na posouzení. V případě, že zadavatel trvá na, uchazeč žádá o jasné vysvětlení cíle zadavatele, a jak hodlá posuzovat nejlepší řešení mezi uchazeči. h) Tabulka M. 0GE infrastruktura - přístupová vrstva serverové zóny - záložní lokalita 2 Architektura: Plně redundantní 0GE LAN infrastruktura - 2 redundantní switche Zadavatel svým minimální požadavkem jasně stanovil, jak si - 3/37 -

14 Pokrytí potřeb odpovídajícího redundantního propojení min. 8 ks blade serverů a primárního datového úložiště s minimálně 6x 0GE porty pro venkovní komunikaci, podpora implementovaného virtualizačního prostředí, replikaci do DR lokality a replikaci zálohování, představuje architekturu. Vzhledem k tomu, že zadavatel musí zvažovat i ekonomickou stránku věci, není uchazeči jasné, jakým způsobem by měl nabídnout takovou nabídku, která v tomto bodě bude nejlepší a navrhuje zadavateli změnu z na posouzení. V případě, že zadavatel trvá na, uchazeč žádá o jasné vysvětlení cíle zadavatele, a jak hodlá posuzovat nejlepší řešení mezi uchazeči. i) Tabulka N. FC SAN infrastruktura - primární lokalita 2 Architektura: Plně redundantní min. 8 Gbit FC SAN infrastruktura - 2 redundantní switche Pokrytí potřeb odpovídajícího redundantního propojení min. 8 ks blade serverů a primárního datového úložiště přes dvě nezávislé redundantní SAN sítě a napojení magnetopáskové knihovny s FC LTO6 mechanikami Zadavatel svým minimální požadavkem jasně stanovil, jak si představuje architekturu. Vzhledem k tomu, že zadavatel musí zvažovat i ekonomickou stránku věci, není uchazeči jasné, jakým způsobem by měl nabídnout takovou nabídku, která v tomto bodě bude nejlepší a navrhuje zadavateli změnu z na posouzení. V případě, že zadavatel trvá na, uchazeč žádá o jasné vysvětlení cíle zadavatele, a jak hodlá posuzovat nejlepší řešení mezi uchazeči. j) Tabulka O. FC SAN infrastruktura - záložní lokalita 2 Architektura: Plně redundantní FC SAN infrastruktura - 2 redundantní switche - min. 8 Gbit FC porty s možností konvergovaných 0Gb FCoE portů Pokrytí potřeb odpovídajícího redundantního propojení min. 8 ks blade serverů a záložního datového úložiště přes dvě nezávislé redundantní SAN sítě a napojení diskového zálohovacího zařízení, včetně dalších volných min. 4x FC portů pro napojení dalších komponent Zadavatel svým minimální požadavkem jasně stanovil, jak si představuje architekturu. Vzhledem k tomu, že zadavatel musí zvažovat i ekonomickou stránku věci, není uchazeči jasné, jakým způsobem by měl nabídnout takovou nabídku, která v tomto bodě bude nejlepší a navrhuje zadavateli změnu z na posouzení. V případě, že zadavatel trvá na, uchazeč žádá o jasné vysvětlení cíle zadavatele, a jak hodlá posuzovat nejlepší řešení mezi uchazeči. - 4/37 -

15 k) Tabulka P. Serverová infrastruktura primární lokalita - Blade chassi Provedení: 2 Napájení: 4 Maximální příkon: 2 ks Blade chassi (po jednom pro primární a záložní lokalitu), každé pro minimálně 8 serverů typu blade Redundantní zdroje minimálně v režimu N+ Maximální příkon (šasi včetně 8 ks blade serverů) 3500W, maximálně 2000 BTU/hod Zadavatel svým minimální požadavkem jasně stanovil, jak si představuje architekturu. Vzhledem k tomu, že zadavatel musí zvažovat i ekonomickou stránku věci, není uchazeči jasné, jakým způsobem by měl nabídnout takovou nabídku, která v tomto bodě bude nejlepší a navrhuje zadavateli změnu z na posouzení. V případě, že zadavatel trvá na, uchazeč žádá o jasné vysvětlení cíle zadavatele, a jak hodlá posuzovat nejlepší řešení mezi uchazeči. Jakým způsobem bude zadavatel hodnotit nabídky uchazečů? Co je pro zadavatele cílem v této oblasti a co bude považovat za nejlepší řešení? Uchazeč se domnívá, že bez popsaného maximálního cílového stavu by měl být tento bod pouze posuzován v rámci požadovaných kritérií, jinak nebude objektivní. Změní zadavatel tento bod z na posouzení, nebo doupřesní požadované parametry, tak aby uchazeč mohl nabídnout nejlepší řešení? Uchazeč nerozumí způsobu tohoto bodu. Bude se jednat čistě o ve stylu "čím menší, tím lepší"? Jak zadavatel vyhodnotí nabídky uchazečů, kdy jeden uchazeč maximální příkon 2000W a maximální BTU/hod 2000 a druhý uchazeč nabídne maximální příkon 3500W a maximální BTU/hod 0000? Jaké hodnoty jsou pro zadavatele nejpodstatnější a cílové? Uchazeč navrhuje zadavateli změnu z na posouzení. V případě, že zadavatel trvá na, uchazeč žádá o jasné vysvětlení cíle zadavatele, a jak hodlá posuzovat nejlepší řešení mezi uchazeči. - 5/37 -

16 l) Tabulka Q. Serverová infrastruktura - Blade servery.) Zadavatel neuvedl, kolik RAM mají servery obsahovat. Doplní zadavatel tento požadavek? 4 5 Provedení serveru: Operační systém: Počet procesorů/ jader: Blade, Redundantní SD karta pro hypervizor, minimálně 64GB Podporuje minimálně operační systémy a virtualizační software: Windows, RHEL, SLES, OEL, Solaris, NetWare, VMware a Citrix XenServer 2 procesory, minimální výkon CPU dle nezávislého srovnávacího PassMark 5000 bodů, minimálně 0 jader/20 vláken 2.) Zadavatel v rámci tohoto bodu chce bodově hodnotit minimální požadavky, kde jediné kritérium, kde se uchazeči mohou lišit je pouze v kapacitě (GB) pro SD kartu. Dle zkušeností uchazeče bude takové absolutně irelevantní, jelikož pro běh systému je minimální kapacita stanovená zadavatelem naprosto dostačující. Zadavatel by se navíc uchýlil k pouze jednoho z vyjmenovaných bodů, jelikož ostatní body se nedají hodnotit. Dle názoru uchazeče se jedná o bod, který má být čistě posuzován, jako splnění minimálních požadavků zadavatele. Změní zadavatel z na posouzení? Pokud bude zadavatel trvat na, uchazeč žádá o jasné specifikování tohoto. Uchazeči není jasný postup tohoto bodu. Jak zadavatel bude hodnotit nabídky uchazečů? Co když například dva uchazeči nabídnou ještě další systém (nad uvedené minimální) a oba se budou lišit? Která nabídka pak bude vyhodnocena jako nejlepší? Uchazeč žádá zadavatele o změnu z na posouzení. V případě, že zadavatel trvá na, uchazeč žádá o jasný popis způsobu. Uchazeči není jasný postup tohoto bodu. Zadavatel jasně definoval, že počet procesorů má být 2 s minimálním výkonem CPU dle programu PassMark s minimálním počtem jader/vláken. Co zadavatel bude vyhodnocovat jako nejlepší řešení? Bude se čistě orientovat dle programu PassMark a hodnotit lepší dosažené hodnoty v tomto programu? Nebo bude pro zadavatele podstatnější vyšší počet jader/vláken? Každý den se aktualizuje databáze společnosti PassMark Software. Jaký den se tedy má zakotvit, ke kterému se budou hodnoty porovnávat? Jak bude zadavatel postupovat v případě, že v den podání nabídky bude hodnota minimálně 5000 a v den zadavatelem bude hodnota pod touto hranicí? Z pohledu uchazeče se opětovně jedná o bod, který má být pouze posuzován, jelikož uchazeči musejí nabízet HW i s ohledem na finanční stránku (která je hodnocena ze 60%). Popíše zadavatel jasně co je pro něj nejdůležitější v rámci tohoto hodnotícího bodu a stanoví den, ke kterému se budou porovnávat hodnoty PassMarku? Nebo zadavatel změní způsob z na posouzení? - 6/37 -

17 6 Ethernet: min. 2x0GbE síťový adaptér s podporou DCB s možností vytvořit HBA a zároveň alespoň 6 ethernetových rozhraní s podporou iscsi boot 7 SAN: min. x8gb FibreChannel Dual Port Uchazeč nerozumí u obou bodů (Ethernet, SAN)jak bude zadavatel vyhodnocovat nejlepší nabídky. Bude zadavatel hodnotit na základě způsobu "čím více, tím lépe?" Proč by uchazeč, který nabídne největší počet portů, měl být v takovém případě vyhodnocen jako nejlepší, když by takové řešení bylo předimenzované a neekonomické? Uchazeč doporučuje zadavateli změnit z na na trvá, uchazeč žádá o vysvětlení způsobu m) Tabulka R. Správa řešení serverové infrastruktury Minimální požadavky Jednotná redundantní integrovaná správa pro serverovou infrastrukturu, součástí správy musí být i správa ostatních prvků, tedy zdrojů, ventilátorů, přepínačů v šasí atd. Možnost zasílat hlášení o chybách na uživatelsky definovatelné ové adresy Přístup k managementu přes HTTP, HTTPS (WWW) a zároveň přes SSH (CLI) XML api pro přístup ke správě serverové infrastruktury 5 Software pro správu musí podporovat minimálně OS Windows Vista/7/8, Linux RedHat a VMware 6 Software pro správu musí umožnit oddělení pravomocí pro správu více logickým dílčím organizacím na všech úrovních managementu (WWW i CLI) Práva musí umožňovat řízení přístupových práv k řídicím modulům, KVM přepínačům a dalším částem správy systému prostřednictvím účtů v LDAP struktuře provozované zadavatelem KVM musí podporovat textovou i grafickou konzoli serveru a zajistí přenos povelů z klávesnice a myši vzdáleného počítače bez ohledu na stav operačního sytému serveru, požadujeme také možnosti sdílení více uživateli současně, možnost mapování vzdálených medií, souborů či adresářů fyzickému serverovému modulu a přístup protokolem Serial over LAN Musí umožnit další členění a automatické přiřazování serverů do skupin, které budou opravňovat dle nadřazené Active Directory (LDAP) nebo lokální skupiny uživatele k využití zdrojů serverové infrastruktury (Procesor, paměť, využití diskového systému) Možnost definice serverového profilu, které je možné na server aplikovat například při výměně HW nebo migraci, musí minimálně obsahovat verze firmware BMC, BIOS, MB a sítových rozhraní, Dále pak nastavení BIOS, IMPI, síťové karty, HBA, nastavení lokálního RAID, boot pořadí (lokální nebo SAN/LAN target). Měření a řízení spotřeby, řízení na základě definovatelné priority důležitých aplikací, monitorování teploty a historický záznam teplot. Automatická konfigurace serveru na základě připraveného serverového profilu. Uchazeči není jasné u všech bodů tabulky, jakým způsobem bude zadavatel vyhodnocovat nejlepší nabídku mezi uchazeči. Jelikož se jedná o minimální požadavky, všichni uchazeči je musí splnit. Jedná se o minimální požadavky, které musejí uchazeči splnit, pokud nesplní, budou vyloučeni. Co je tedy cílem a jak hodlá zadavatel jednotlivé body hodnotit? Vzhledem k povaze textů doporučuje uchazeč zadavateli změnit z na posouzení. V případě, že zadavatel na trvá, uchazeč žádá o jasné vysvětlení způsobu těchto bodů. 3 Podpora protokolů IEEE 802.3ad, 802.q, 802.ab 4 Podpora QoS a prioritizování provozu 5 Podpora protokolů IEEE 802.Qbb a 802.Qaz - 7/37 -

18 6 7 Podpora připojení k nadřazenému síťovému prvku s centrálním managementem celého řešení. Podpora SNMP v rozsahu SNMPv, SNMPv2c a SNMPv3 n) Tabulka S. VMware licence Minimální požadavky Licence musí umožňovat plnohodnotný monitoring celé Virtuální infrastruktury, sledování a analýzu výkonnosti infrastruktury a Capacity Management, a to i pro stávající Virtuální infrastrukturu. Licence musí být přenositelné na jiný HW. Součástí dodávky musí být i podpora výrobce (na všech úrovních). Licence pro Primární virtulizační cluster v rozsahu min. 5 serverů / 0 CPU socketů. Licence pro Záložní virtulizační cluster v rozsahu min. 4 serverů / 8 CPU socketů. Licence pro automatickou replikaci minimálně 70 virtuálních serverů z Primární virtualizačního clusteru na Záložní virtualizačního clusteru s podporou využití prostředků diskového pole. Aplikace společných politik na skupinu chráněných virtuálních serverů. Využití prostředků diskového pole pro replikaci virtuálních strojů. Nezávislý management Primárního i Záložního virtualizačního clusteru. Uchazeči není jasné u všech bodů tabulky, jakým způsobem bude zadavatel vyhodnocovat nejlepší nabídku mezi uchazeči. Jelikož se jedná o minimální požadavky, všichni uchazeči je musí splnit. Jedná se o minimální požadavky, které musejí uchazeči splnit, pokud nesplní, budou vyloučeni. Co je tedy cílem a jak hodlá zadavatel jednotlivé body hodnotit? Vzhledem k povaze textů doporučuje uchazeč zadavateli změnit z na posouzení. V případě, že zadavatel na trvá, uchazeč žádá o jasné vysvětlení způsobu těchto bodů. o) Tabulka T. Datové úložiště primární lokalita Primární datové úložiště: 3 Cache: Rozhraní pro napojení disků: Rozhraní pro host systémy: Disková kapacita (hrubá): 7 SSD cache: uvést typ a počet dodávaných kusů Minimálně 64GB RAM cache na řadičích Minimálně 8x 24Gbit SAS disk kanál Minimálně 8x GbE host kanál Minimálně 4x 0GbE host kanál s možností zdvojnásobení počtu Minimálně 8x 6Gb FC host kanál s možností zdvojnásobení počtu Minimálně 7TB s min. 36ks SSD - prostor pro transakčně náročné aplikace a pro akceleraci kapacity na rotačních discích Minimálně 60TB s min. 68ks 0KRPM HDD Minimálně 60TB s min. 40ks 7,2KRPM HDD Okamžitá výkonová akcelerace aplikací s daty uloženými na rotačních discích pro operace čtení i zápisu formou výkonné SSD cache s využitím požadovaných SSD a s možností kapacitního rozšíření cache na minimálně 32TB Zadavatel jasně popsal minimální požadavky na datové uložiště. Uchazeč tak vychází z domněnky, že má zadavatel rozmyšlenu architekturu řešení a cokoliv nabídnuto navíc nad rámec minimálních požadavků bude celý systém zbytečně prodražovat a nebude tak k řešení přistupováno s ohledem na ekonomickou stránku věci. Vychází uchazeč ze správné domněnky, že zadavatel chce hodnotit jednotlivé body datového uložiště na základě toho, že kdo nabídne více, ten bude vyhodnocen jako nejlepší, i když bude takové řešení předimenzované? Dle názoru uchazeče se opět jedná pouze o body, které každý uchazeč musí splnit a mělo by se tak jednat čistě o posuzování těchto bodů a ne. Uchazeč tedy navrhuje zadavateli změnu z na trvá na, uchazeč žádá o jasný popis způsobu a jeho cíl. - 8/37 -

19 p) Tabulka U. Datová úložiště záložní lokalita Záložní datové úložiště: 3 Cache: 4 5 Rozhraní pro napojení disků: uvést typ a počet dodávaných kusů Minimálně 32GB RAM cache ma řadičích Minimálně 4x 24Gbit SAS disk kanál Minimálně 4x GbE host kanál 6 Rozhraní pro Minimálně 2x 0GbE host kanál host systémy: Minimálně 2x 6Gb FC host kanál 7 nebo 2x 0Gb FCoE kanál 8 Disková kapacita (hrubá): 0 SSD cache: Minimálně,6TB s min. 8ks SSD - prostor pro transakčně náročné aplikace a pro akceleraci kapacity na rotačních discích Minimálně 60TB s min. 40ks 7,2KRPM HDD Okamžitá výkonová akcelerace aplikací s daty uloženými na rotačních discích pro operace čtení i zápisu formou výkonné SSD cache s využitím požadovaných SSD a s možností kapacitního rozšíření cache na minimálně 6TB Zadavatel jasně popsal minimální požadavky na datové uložiště. Uchazeč tak vychází z domněnky, že má zadavatel rozmyšlenu architekturu řešení a cokoliv nabídnuto navíc nad rámec minimálních požadavků bude celý systém zbytečně prodražovat a nebude tak k řešení přistupováno s ohledem na ekonomickou stránku věci. Vychází uchazeč ze správné domněnky, že zadavatel chce hodnotit jednotlivé body datového uložiště na základě toho, že kdo nabídne více, ten bude vyhodnocen jako nejlepší, i když bude takové řešení předimenzované? Dle názoru uchazeče se opět jedná pouze o body, které každý uchazeč musí splnit a mělo by se tak jednat čistě o posuzování těchto bodů a ne. Uchazeč tedy navrhuje zadavateli změnu z na trvá na, uchazeč žádá o jasný popis způsobu a jeho cíl. q) Tabulka V. Datová úložiště - společné požadavky Unified storage řešení koncipováno jako HW, SW a FW od jednoho výrobce Plně redundantní datové úložiště, včetně redundance datových cest pro komunikaci s jednotlivými HDD/SSD disky i pro data v souborové i blokové host komunikaci Jednotný centrální monitoring a management všech HW komponent, host komunikačních protokolů a všech požadovaných funkcionalit storage systému pro primární i záložní lokalitu formou CLI i web-base rozhraní Upgrade software/firmware musí být proveditelný za chodu a bez ztráty konektivity připojených zařízení Host komunikace přes FC, iscsi, NFS (včetně NFS- 4), CIFS (včetně SMB-3) nativně datovým úložištěm, bez dodatečných zařízení nebo serverů, které zpřístupní data jiným protokolem Podpora RAID režimu s jednoduchou nebo dvojnásobnou paritou a zrcadlením Automatická kontrola integrity uložených dat s případnou automatickou opravou detekovaných nekonzistencí 8 Online rozšiřování jednotlivých Volumů a LUNů 9 Online migrace jednotlivých Volumů a LUNů mezi jednotlivými RAIDy, skupinami disků a nadřízenými storage controllery 0 Thin Provisioning Snapshoty pro data v souborové i blokové host komunikaci v minimálním počtu 200 snapshotů na jeden Volume/LUN Uchazeči není jasné u všech bodů tabulky, jakým způsobem bude zadavatel vyhodnocovat nejlepší nabídku mezi uchazeči. Jelikož se jedná o minimální požadavky, všichni uchazeči je musí splnit. Jedná se o minimální požadavky, které musejí uchazeči splnit, pokud nesplní, budou vyloučeni. Co je tedy cílem a jak hodlá zadavatel jednotlivé body hodnotit? Vzhledem k povaze textů doporučuje uchazeč zadavateli změnit z na posouzení. V případě, že zadavatel na trvá, uchazeč žádá o jasné vysvětlení způsobu těchto bodů. - 9/37 -

20 Automatická, shedulovaná tvorba aplikačně konzistentních snapshotů pro aplikace Oracle, SQL, Exchange a SharePoint s grafickým managementem, včetně možnosti point-in-time rychlého obnovení provozu aplikace na historických aplikačně konzistentních datech v případě výskytu narušení konzistence dat, SW chyby nebo lidské chyby Automatická, shedulovaná tvorba konzistentních snapshotů souborových struktur, včetně možnosti tansparentního přístupu každého klienta ke svým historickým datům Automatická, shedulovaná tvorba konzistentních snapshotů virtuálních serverů integrovaná do řídícího prostředí serverové virtualizace v prostředí Vmware a Hyper-V Transparentní automatická integrace souborových struktur do adresářových služeb ActiveDirectory, LDAP, NIS Deduplikace primárních dat určených pro souborovou i blokovou host komunikaci Komprese primárních dat určených pro souborovou i blokovou host komunikaci Multitenance - možnost prezentovat datové prostory formou několika zabezpečených doménově oddělených virtuálních datových úložišť QoS řízení priorit, výkonu a průchodnosti jednotlivých datových oblastí storage systému Výkonová transparentní automatická okamžitá akcelerace zvolených datových oblastí (v souborové i blokové host komunikaci) prostřednictvím SSD/flash cache pro čtení i zápis R/W cache NDMP zálohování blokových i souborových struktur pro integraci s backup řešeními Asynchronní replikace formou periodického přenosu rozdílových deduplikovaných a komprimovaných bloků. Replikace s automatickou vazbou na prováděné aplikačně konzistentní snapshoty a s nutností uchování historických snapshotů blokových i souborových dat jak na primárním, tak i záložním datovém úložišti. Možnost obrácení směru replikace a souběžného provozu jako zdoj i cíl replikací mezi dvěma úložišti. Kompatibilita s operačními systémy MS Windows, Linux, Unix Kompatibilita s hypervizory Vmware (včetně vsphere 6) a Hyper-V, včetně integrace tvorby konzistentních snapshotů jednotlivých VM Kompatibilita s Vmware Site Recovery Manager (SRM) - nástrojem pro řízení DR fail-over a fail-backp procesů mezi lokalitami Možnost on-line upgrade datového úložiště na nové typy řídících jednotek a on-line migrace dat na nové diskové úložiště bez přerušení provozu kritických aplikací Veškeré požadované SW funkcionality musí být licencované na plnou kapacitu datového úložiště (maximální kapacita dostupná datovým úložištěm) pro minimálně 30 připojených fyzických serverů nebo serverů určených pro serverovou/vdi virtualizaci a virtualizaci pracovních stanic - 20/37 -

21 r) Tabulka W. Zálohovací systém - magnetopásková knihovna 2 3 Počet LTO6 media slotů Počet LTO6 mechanik Rozšiřitelnost: 4 Počet mail slotů 6 Spolehlivost 7 Variabilita 8 Management 9 0 Počet datových médií Počet čistících médií Minimálně 500 osazených slotů pro média s nativní kapacitou pro LTO6 média.250 TB, s minimálně 250 media sloty aktivovanými a s možností COD (Capacity On Demand) upgrade dle aktuálních potřeb Minimálně 2 ks LTO6 mechanik s redundantním FC host rozhraním Minimálně na 000 slotů pro pásková média a 20 páskových mechanik Minimálně 5 mail slotů pro výměnu LTO médií Spolehlivost robotiky min. 4 mil. MCBF Možnost vytváření logických knihoven Podpora vzdáleného managementu a diagnostiky knihovny, včetně vzdáleného upgrade firmware knihovny Minimálně 00 ks LTO6 datových médií Minimálně 5 ks LTO čistících médií Zadavatel jasně popsal minimální požadavky na zálohovací systém. Uchazeč tak vychází z domněnky, že má zadavatel rozmyšlenu architekturu řešení a cokoliv nabídnuto navíc nad rámec minimálních požadavků bude celý systém zbytečně prodražovat a nebude tak k řešení přistupováno s ohledem na ekonomickou stránku věci. Vychází uchazeč ze správné domněnky, že zadavatel chce hodnotit jednotlivé body datového uložiště na základě toho, že kdo nabídne více, ten bude vyhodnocen jako nejlepší, i když bude takové řešení předimenzované? Dle názoru uchazeče se opět jedná pouze o body, které každý uchazeč musí splnit a mělo by se tak jednat čistě o posuzování těchto bodů a ne. Uchazeč tedy navrhuje zadavateli změnu z na trvá na, uchazeč žádá o jasný popis způsobu a jeho cíl. s) Tabulka X. Zálohovací systém - Diskové zálohovací zařízení 3 Kapacita Výkon Paralelismus 4 Host rozhraní Komunikační protokioly Ekonomické ukládání záloh Stabilita zabezpečení a Minimálně 96 TB datově využitelné kapacity pro zálohovaná data bez započtení komprese a deduplikace Minimální propustnost zálohy 0 TB/hodinu Minimálně podpora pro 50 paralelních zálohovacích úloh per fyzický systém Minimálně 2x 0GE a 4xGE host rozhraní s možností upgrade o další 0GE a FC host rozhraní Podpora CIFS, NFS, VTL, FC a jejich souběžné použití Integrovaná in-line deduplikace s proměnnou délkou bloku In-line komprimace deduplikovaných bloků Zařízení musí zajišťovat ochranu dat alespoň na úrovni duální diskové parity Zařízení musí zahrnovat hot-spare disky Zadavatel jasně popsal minimální požadavky na zálohovací systém. Uchazeč tak vychází z domněnky, že má zadavatel rozmyšlenu architekturu řešení a cokoliv nabídnuto navíc nad rámec minimálních požadavků bude celý systém zbytečně prodražovat a nebude tak k řešení přistupováno s ohledem na ekonomickou stránku věci. Vychází uchazeč ze správné domněnky, že zadavatel chce hodnotit jednotlivé body datového uložiště na základě toho, že kdo nabídne více, ten bude vyhodnocen jako nejlepší, i když bude takové řešení předimenzované? Dle názoru uchazeče se opět jedná pouze o body, které každý uchazeč musí splnit a mělo by se tak jednat čistě o posuzování těchto bodů a ne. Uchazeč tedy navrhuje zadavateli změnu z na trvá na, uchazeč žádá o jasný popis způsobu a jeho cíl. Uchazeči není jasné u všech bodů tabulky, jakým způsobem bude zadavatel vyhodnocovat nejlepší nabídku mezi uchazeči. Jelikož se jedná o minimální požadavky, všichni uchazeči je musí splnit. Jedná se o minimální požadavky, které musejí uchazeči splnit, pokud nesplní, budou vyloučeni. Co je tedy cílem a jak hodlá zadavatel jednotlivé body hodnotit? Vzhledem k povaze textů - 2/37 -