Opis Przedmiotu Zamówienia- część 2 – zmieniony 17-06-2014 r.

Załącznik nr 1.2 do SIWZ

Sprawa numer: 14/SISP-2/PN/2014

Opis Przedmiotu Zamówienia- część 2 – zmieniony 17-06-2014 r.

Przedmiotem zamówienia jest rozbudowa posiadanego przez Zamawiającego środowiska sprzętowo-systemowego o elementy  infrastruktury oraz oprogramowanie systemowe, bazodanowe i narzędziowe, na potrzeby realizacji zadań Projektu SISP-2 w Zapasowym Centrum Przetwarzania Danych w Radomiu.

W szczególności przedmiot zamówienia obejmuje następujące zadania do realizacji przez Wykonawcę:

1. Dostawę oraz wdrożenie wyspecyfikowanego sprzętu wraz ze standardową, dołączaną przez producenta danego urządzenia dokumentacją, oraz dostawę dodatkowych elementów infrastruktury, jeśli będą niezbędne, do prawidłowego wdrożenia

2. Rozbudowę i wykonanie konsolidacji sieci SAN

3. Dostawę oraz wdrożenie oprogramowania systemowego, bazodanowego i narzędziowego

4. Dostawę oprogramowania narzędziowego do wirtualizacji i budowa środowiska zwirtualizowanego

5. Dostawę oraz wdrożenie oprogramowania do backupu zbudowanego środowiska zwirtualizowanego

6. Dostawę oraz wdrożenie oprogramowania umożliwiającego monitorowanie zbudowanego środowiska zwirtualizowanego oraz integrację tego rozwiązania z systemem monitorowania Zamawiającego

7. Realizację szkoleń

1. Wspólne uwarunkowania dla zadań oraz opis posiadanego przez Zamawiającego środowiska

.

Zasadnicze prace wdrożeniowe i konfiguracyjne będą realizowane w Zapasowym Centrum Przetwarzania Danych GUS w Radomiu – xx. Xxxxxx 00/00, niektóre czynności będą realizowane również w Podstawowym Centrum Przetwarzania Danych GUS w Warszawie – Xx. Xxxxxxxxxxxxxx 000.

Z uwagi na fakt, iż prace wdrożeniowe i rekonfiguracyjne będą prowadzone na działającym środowisku sprzętowo–systemowo–aplikacyjnym, wymagane jest zachowanie ciągłości działania tego środowiska oraz minimalizacja przestojów.

W Ośrodkach Przetwarzania Danych Zamawiający posiada środowisko serwerowe z zainstalowanym systemem operacyjnym MS Windows Server 2008 R2 stanowiącym platformę systemową dla następujących komponentów infrastruktury informatycznej:

1. Systemu usług katalogowych bazującego na Microsoft Active Directory w wersji Windows 2008 R2.

2. Modułu monitorowania wydajności oraz dostępności aplikacji i usług zbudowanego na bazie systemu Microsoft System Center Operations Manager 2007 R2.

3. Modułu zarządzania konfiguracją dla serwerów stworzonego w oparciu o oprogramowanie Microsoft System Center Configuration Manager 2007 R3.

4. Systemu poczty Microsoft Exchange 2010.

5. Środowisk do wirtualizacji serwerów bazujących na oprogramowaniu VMware vCenter 5.1

6. Serwerów bazodanowych z oprogramowaniem Microsoft SQL Server 2008 oraz 2012.

1. Opis posiadanej infrastruktury sprzętowej

Infrastruktura sprzętowa w Zapasowym Centrum Przetwarzania Danych kształtowała się w latach 2008-2013, w miarę realizacji kolejnych funkcjonalnych projektów SISP.

Zasoby serwerowe w Zapasowym Centrum Przetwarzania Danych w Radomiu zostały poszerzone o serwery blade serwery blade HP ProLiant BL680c G5, HP ProLiant BL460c G1, HP ProLiant BL460c G6,HP ProLiant BL480c G1, rozmieszczone w infrastrukturach blade HP C7000.

.

Środowisko sprzętowe pamięci masowych zostało oparte na bazie macierzy dyskowych SAN HP EVA 8100, SAN HP EVA 8400.

Serwery blade mają dostęp do zasobów macierzowych oraz bibliotek taśmowych

HP MSL 8096 z napędami LTO 4.

2. Opis posiadanego środowiska sieci SAN

Infrastruktura sieci SAN w Zapasowym Centrum Przetwarzania Danych kształtowała się w latach 2009-2013, w miarę realizacji kolejnych funkcjonalnych projektów SISP.

W ten sposób powstało kilka środowisk sieci SAN, które nie są całkowicie ze sobą skonsolidowane.

a) w 2009 i 2010 roku dostarczone zostały poniższe urządzenia, które zostały włączone w sieć SAN1:

- macierz SAN HP EVA 8100,
- biblioteka taśmowa MSL 8096 z dwoma napędami LTO4,
- trzy infrastruktury blade C7000 z redundantnymi 24 portowymi przełącznikami HP AJ821A B-series 8/24c Blade System San Switch (połączenia pomiędzy przełącznikami : 8Gb, pomiędzy serwerami i zasobami SAN: 4Gb)

Wszystkie serwery z obudowy C7000 w tej konfiguracji zoning-u mają dostęp do zasobów SAN (macierz, biblioteka taśmowa). Topologia architektury połączeń SAN1 to topologia full-mesh, z zoningiem po portach.

b) w 2010 roku dostarczone zostały poniższe urządzenia, które zostały włączone w sieć SAN2:

- dwa przełączniki SAN HP AM870A 8/40 Power Pack+ (aktywne 32 porty),
- dwie infrastruktury blade - C7000 i C3000 z redundantnymi modułami FC HP VC 8Gb 24-Port,
- macierz SAN HP EVA 8400,
- dwie biblioteki taśmowe MSL 8096 z 4 napędami LTO-4 każda,

- biblioteka VLS 12000.

Wszystkie urządzenia są wpięte do dwóch sieci fabric opartych na przełącznikach HP AM870A 8/40. Połączenia pomiędzy urządzeniami to 4Gb i 8Gb. W chwili obecnej zajętych jest 20 portów na każdym z przełączników, 12 portów nie jest wyposażonych we wkładki SFP AJ716A. Zoning zrobiony jest po WWN.

c) również w 2010 roku, na potrzeby NSP i PSR, dostarczone zostały poniższe urządzenia, które nie posiadają obecnie odrębnej sieci SAN:

- dwa przełączniki SAN HP StorageWorks 8/8 24-Port,
- 4 serwery z interfejsami FC

2. Szczegółowa specyfikacja i opisy zadań do realizacji przez Wykonawcę.

Harmonogram prac z podziałem na etapy i zadania został określony w załączniku nr 9.2 do SIWZ.

Zadanie 1. Dostawa i wdrożenie sprzętu (serwerów, macierzy, dysków) w ilościach wyspecyfikowanych w Tabeli 1 zgodnych z opisem w Tabelach 2-12

Zamawiający wymaga dostarczenia sprzętu:

• fabrycznie nowego

• objętego gwarancyjną

• posiadającego najnowszą dostępną w dniu składania ofert wersję oprogramowania

Tabela 1. Zbiorcza specyfikacja ilościowa sprzętu dostarczanego w zadaniu

Typ sprzętu	Ilość szt.	Numer tabeli
Macierz xxxxxxx	0	Tabela 2
Infrastruktura blade	2	Tabela 3
Serwer blade typ 1 (4 procesory)	7	Tabela 4
Serwer blade typ 2 (2 procesory)	6	Tabela 5
UPS do infrastruktury	2	Tabela 6
UPS do macierzy	1	Tabela 7
Serwer stelażowy typ 3	1	Tabela 8
Szafa Rack	1	Tabela 9
Konsola zarządzająca do montażu w szafie Rack	1	Tabela 10
Moduł zasilania PDU	2	Tabela 11
Dyski zapasowe – typ 1	10	Tabela 12
Dyski zapasowe – typ 2	10	Tabela 12
Dyski zapasowe – typ 3	10	Tabela 12
Dyski zapasowe – typ 4	5	Tabela 12
Dyski zapasowe – typ 5	5	Tabela 12

Zamawiający oczekuje dostarczenia serwerów zgodnie ze specyfikacją zapisaną w tabelach 4, 5 i 8 przy czym procesory powinny być wyłącznie sześciordzeniowe (wymaganie konieczne ze względu na licencjonowanie oprogramowania).

Zamawiający wymaga dostarczenia systemu pamięci masowej, który musi być kompatybilny z VMware na poziomie ESXi 5.1 U2 i nowszym oraz posiadać certyfikację VMware vSphere Metro Storage Cluster lub równoważną.

Praca macierzy ma być zabezpieczona za pomocą UPS-a wyspecyfikowanego

w Tabeli 6.

Na serwerach typ 1 i typ 2, wyspecyfikowanych odpowiednio w Tabeli 4 i 5 Wykonawca zainstaluje systemy operacyjne dostarczone w zadaniu 3.

Na serwerze stelażowym typ 3, wyspecyfikowanym w Tabeli 8, Wykonawca zainstaluje system operacyjny dostarczony w zadaniu 3 oraz potrzebne oprogramowanie narzędziowe.

Przez macierz dyskową Zamawiający rozumie zestaw dysków twardych kontrolowanych przez kontrolery macierzowe i udostępniający wspólną przestrzeń dyskową bez zastosowania zewnętrznych wirtualizatorów. Za pojedynczą macierz nie można uznać rozwiązania opartego o wiele macierzy dyskowych połączonych przełącznikami SAN lub tzw. wirtualizatorem sieci SAN.

Zamawiający wymaga dostarczenia łącznie 40 szt. dysków twardych, o różnych pojemnościach, przeznaczonych do pracy w posiadanych przez Zamawiającego macierzach HP StorgeWorks EVA 8100 i HP StorgeWorks EVA 8400, zgodnych ze specyfikacją określoną w Tabeli 12.

Wykonawca pozostawi dyski wyspecyfikowane w Tabeli 12 do dyspozycji Zamawiającego,

Tabela 2. Macierz dyskowa

Lp.	Parametr	Wymagania minimalne
1.	Nazwa producenta
2.	Typ produktu, model
3.	Obudowa	Macierz dyskowa zainstalowana w pojedynczej, kompletnej szafie przemysłowej 19” o wysokości 42U wyposażonej w redundantne zasilanie oraz wszystkie niezbędne kable połączeniowe (zasilające i logiczne, w tym kable FC o długości 5m).
4.	Pojemność	Przestrzeń dyskowa zbudowana za pomocą min. 216 dysków w technologii SAS 2,5” o pojemności co najmniej 600GB i prędkości obrotowej min. 10k obr/min. oraz min. 24 dysków w technologii SSD 2,5” o pojemności co najmniej 400GB. Jeśli obsługa przestrzeni dyskowej jest osobno licencjonowana, wymagane jest dostarczenie licencji na zarządzanie przestrzenią dyskową dla całej przestrzeni dyskowej.
5.	Skalowalność rozwiązania	Liniowa skalowalność parametrów wydajnościowych zasobów dyskowych poprzez możliwość rozbudowy do 4 kontrolerów macierzowych. Macierz z zainstalowanymi 4 kontrolerami musi umożliwiać obsługę do 480 dysków wewnętrznych.
6.	Obsługa dysków	Obsługa dysków SSD, SAS i Nearline SAS. Możliwość mieszania napędów dyskowych SSD, SAS i Nearline SAS w obrębie pojedynczej półki dyskowej. Możliwość obsługi dysków 2,5” jak również 3,5” w ramach jednej macierzy. Obsługa dysków SSD o pojemnościach 200GB, 400GB, dysków SAS o pojemnościach 300GB, 450GB, 600GB, 900GB, 1,2TB jak również dysków Nearline SAS o pojemności minimum 1TB
7.	Sposób zabezpieczenia danych	Macierz powinna obsługiwać mechanizmy RAID zgodne z RAID1lub RAID10, RAID5, RAID6 realizowane sprzętowo za pomocą dedykowanego układu, z możliwością dowolnej ich kombinacji w obrębie oferowanej macierzy.
8.	Zabezpieczenie dyskami spare	Możliwość definiowania globalnych dysków spare lub odpowiedniej zapasowej przestrzeni dyskowej dla różnych grup RAID.
9.	Interfejsy dysków	Dyski twarde typu „Hot-Plug” z dwoma interfejsami SAS 6Gb zarówno 2,5” jak i 3,5”.
10.	Tryb pracy kontrolerów macierzowych	Minimum dwa kontrolery macierzowe obsługujące ruch blokowy po protokole Fibre Channel, pracujące w trybie active/active. Równoczesny, aktywny dostęp (odczyt/zapis) do każdego dysku logicznego (LUN) ze wszystkich kontrolerów macierzy dla lepszego rozłożenia obciążenia.
11.	Pamięć cache	Minimalna wielkość zainstalowanej pamięci cache 16GB na kontroler.
12.	Zabezpieczenie pamięci cache	Musi istnieć funkcjonalność Cache dla procesu odczytu oraz Mirrored Cache dla procesu zapisu. Podtrzymanie pamięci cache kontrolerów macierzowych przez minimum 90h lub czas potrzebny do zapisu zawartości cache na nośnik nieulotny.
13.	Interfejsy zewnętrzne	Co najmniej 12 zewnętrznych interfejsów FC z możliwością rozbudowy do 24 przy dodaniu 2 kolejnych kontrolerów macierzowych, o prędkości minimum 8Gb.
14.	Interfejsy wewnętrzne	SAS o prędkości min. 6Gb.
15.	Zarządzanie grupami dyskowymi oraz dyskami logicznymi	Możliwość dynamicznego zwiększania oraz zmniejszania pojemności woluminów logicznych oraz wielkości grup dyskowych z poziomu kontrolera macierzowego bez przerywania dostępu do danych. Możliwość definiowania woluminów logicznych o pojemności co najmniej 16 TB.
16.	Ochrona danych w środowiskach heterogenicznych	Możliwość ochrony danych w heterogenicznych środowiskach sieci SAN – maskowanie LUN. Jeżeli dla zapewnienia izolacji LUN-ów dla różnych serwerów lub różnych grup serwerów potrzebne są dodatkowe komponenty (np.licencje) wymagane jest dostarczenie tych komponentów bez limitów na ilość separowanych maszyn.
17.	Podłączanie zewnętrznych systemów operacyjnych	Możliwość jednoczesnego podłączenia do macierzy co najmniej 60 serwerów (VMware ESX 5.1.0 i starszych, MS Windows 2012, HP-UX, AIX) w trybie wysokiej dostępności (co najmniej dwoma ścieżkami) bez konieczności dokupowania dodatkowych licencji. Obsługa wielu kanałów I/O (Multipathing). Automatyczne przełączanie kanału I/O w wypadku awarii ścieżki dostępu serwerów do macierzy z utrzymaniem ciągłości dostępu do danych. Wymaga się, aby macierz była wyposażona w odpowiednie licencje do obsługi ww. funkcjonalności. Wsparcie co najmniej dla posiadanych przez Zamawiającego systemów : MS Windows 2008, VMware ESX wraz z oprogramowaniem Site Recovery Manager, RedHat Linux 6.5, HP-UX, AIX.
18.	Serwisowalność i redundancja	Możliwość uaktualniania oprogramowania (firmware’u) macierzy bez przerywania pracy systemu. Wymiana elementów systemu w trybie „Hot-Swap”, a w szczególności takich, jak: kontroler(y), zasilacz(e), wentylatory. Macierz przystosowana do napraw w miejscu zainstalowania oraz wymiany elementów bez konieczności jej wyłączania. Brak pojedynczego punktu awarii, który powodowałby brak dostępu do danych. Pełna redundancja macierzy, w szczególności zdublowanie kontrolerów, zasilaczy i wentylatorów. Macierz musi umożliwiać zdalne zarządzanie macierzą oraz automatyczne informowanie centrum serwisowego o awarii. Producent macierzy musi posiadać lokalną organizację serwisową dysponującą certyfikatem ISO 9001. lub równoważnym. Za równoważny Zamawiający uzna certyfikat potwierdzający, że organizacja serwisowa prowadzi działalność w oparciu o wdrożony system zarządzania jakością
19.	Zarządzanie	Zarządzanie macierzą z poziomu pojedynczego interfejsu graficznego. Wymagane jest stałe monitorowanie stanu macierzy oraz możliwość konfigurowania jej zasobów dyskowych. Monitorowanie wydajności macierzy według parametrów takich jak: przepustowość oraz liczba operacji I/O dla interfejsów, grup dyskowych, dysków logicznych (LUN). Wymaga się, aby macierz była wyposażona w odpowiednie licencje do obsługi ww. funkcjonalności.
20.	Wewnętrzne kopie danych	Możliwość dokonywania na żądanie tzw. migawkowej kopii danych (snapshot, point-in time) w ramach macierzy za pomocą wewnętrznych kontrolerów macierzowych. Kopia migawkowa wykonuje się bez alokowania całej przestrzeni dyskowej na potrzeby kopii. Zajmowanie dodatkowej przestrzeni dyskowej następuję w momencie zmiany danych na dysku źródłowym lub na jego kopii. Jeśli w/w funkcjonalność jest osobno licencjonowana, wymagane jest dostarczenie licencji na tę funkcjonalność bez limitu przestrzeni dyskowej.
		Możliwość dokonywania na żądanie pełnej fizycznej kopii danych (clone) w ramach macierzy za pomocą wewnętrznych kontrolerów macierzowych. Wykonana kopia danych musi mieć możliwość zabezpieczenia innym poziomem RAID. Możliwość wykonania kopii w innej grupie dyskowej RAID niż dane oryginalne. Jeśli w/w funkcjonalność jest osobno licencjonowana, wymagane jest dostarczenie licencji na tę funkcjonalność bez limitu przestrzeni dyskowej.
21.	Możliwość migracji danych w obrębie macierzy	Macierz musi umożliwiać migrację danych, bez przerywania do nich dostępu, pomiędzy różnymi warstwami technologii dyskowych: SASD, SAS i Nearline SAS oraz różnych poziomów RAID. Zmiany te muszą się odbywać wewnętrznymi mechanizmami macierzy. Aktualnie dostarczenie licencji na tę funkcjonalność nie jest wymagane. Możliwość rozbudowy o taką funkcjonalność w przyszłości. Macierz musi umożliwiać zdefiniowanie zasobu LUN, który fizycznie będzie znajdował się na minimum 3 typach dysków obsługiwanych przez macierz (SSD, SAS, NL SAS), a jego części będą automatycznie i transparentnie dla korzystającego z tego LUNa serwera realokowane w trybie online na podstawie analizy ruchu w segmentach nie większych niż 128MB. Aktualnie licencja na tę funkcjonalność nie jest wymagana. Możliwość rozbudowy o taką funkcjonalność w przyszłości.
22.	Mechanizm typu Thin Provisioning	Macierz musi mieć możliwość udostępniania zasobów dyskowych do serwerów w trybie tradycyjnym, jak i w trybie typu Thin Provisioning. Jeśli w/w funkcjonalność jest osobno licencjonowana, wymagane jest dostarczenie licencji na tę funkcjonalność bez limitu przestrzeni dyskowej.
23.	Replikacja danych	Możliwość zdalnej replikacji danych typu on-line do innej macierzy tej samej rodziny. Replikacja wykonywana na poziomie kontrolerów, bez obciążania serwerów oraz innych urządzeń podłączonych do macierzy. Dostępna replikacja w trybie synchronicznym i asynchronicznym. Aktualnie licencja na tę funkcjonalność nie jest wymagana. Możliwość rozbudowy o taką funkcjonalność w przyszłości.
24.	Dodatkowe	Usługi do wykonania: - instalacja i konfiguracja półek dyskowych - instalacja dysków twardych - aktualizacja FW półek dyskowych i dysków (zgodnie z najnowszą dostępną w dniu składania ofert wersją) - konfiguracja grup dyskowych i wirtualnych dysków, wg. wskazań Zamawiającego
26.	Gwarancja	3 letnia gwarancja obejmująca całość dostarczonego sprzętu oraz oprogramowania w trybie 24h/7 dni w tygodniu. Gwarantowany czas naprawy dla sprzętu – 6 godzin. W przypadku uszkodzenia nośnika danych (dysku), uszkodzone nośniki przechodzą na własność Zamawiającego. Wymagane jest prawo do nowych wersji oraz poprawek oprogramowania dostarczonego wraz ze sprzętem przez cały okres gwarancji

Tabela 3. Infrastruktura blade

Lp.	Parametr	Wymagania minimalne
1.	Nazwa producenta
2.	Typ produktu, model
3.	Typ obudowy	Do montażu w szafie 19”, maksymalna wysokość pojedynczej obudowy 10U.
4.	Liczba zamontowanych serwerów blade	Umożliwiająca rozbudowę do min.14 dwuprocesorowych serwerów bez potrzeby rozbudowy środowiska o dodatkowe elementy (obudowy blade, moduły LAN/SAN instalowane w obudowach, zasilacze i wentylatory).
5.	Rodzaj obsługiwanych serwerów	Możliwość umieszczania w ramach jednej infrastruktury wszystkich dostarczanych typów serwerów blade wyspecyfikowanych w Tabeli 5 i Tabeli 6 w układzie mieszanym, także serwerów blade z procesorami o architekturze RISC lub EPIC (serwery takie nie są przedmiotem zamówienia, ale muszą być dostępne do rozbudowy).
6.	Sposób agregacji/ wyprowadzeń sygnałów LAN	Każda infrastruktura musi posiadać minimum 2 przełączniki typu 10Gb Ethernet wyprowadzające sygnały z minimum 2 portów sieciowych 10Gb na serwerach. Urządzenia te muszą umożliwiać agregację połączeń LAN w infrastrukturze blade i muszą umożliwiać wyprowadzenie sygnałów LAN z infrastruktury z zachowaniem redundancji połączeń. Każdy przełącznik powinien posiadać minimum 8 portów 10Gb przygotowanych do obsadzenia wkładkami SFP+. Wraz z przełącznikami należy dostarczyć minimum 16 wkładek SFP 10Gb RJ45 (po 8 sztuk na przełącznik). Jeśli w serwerze znajdują się dodatkowe karty LAN (oprócz wymaganych portów 10Gb), należy uwzględnić odpowiednie przełączniki LAN w celu wyprowadzenia dodatkowych portów na zewnątrz obudowy.
7.	Sposób agregacji/ wyprowadzeń sygnałów FC	Każda infrastruktura musi posiadać minimum dwa przełączniki typu 8Gb Fibre-Channel wyprowadzające sygnały z minimum 2 portów FC na serwerach. Urządzenia te muszą umożliwiać agregację połączeń SAN w infrastrukturze blade i muszą umożliwiać wyprowadzenie sygnałów SAN z infrastruktury z zachowaniem redundancji połączeń. Każdy przełącznik musi posiadać minimum 6 zewnętrznych portów. Wszystkie porty muszą być aktywne. Wraz z przełącznikami należy dostarczyć minimum 12 wkładek SFP+ 8Gb (po 6 sztuk na przełącznik).
8.	Zarządzanie połączeniami LAN i SAN z serwerów blade	Możliwość przydzielania adresów MAC i WWN predefiniowanych przez producenta rozwiązania blade dla poszczególnych wnęk na serwery w infrastrukturze. Przydzielenie adresów musi powodować zastąpienie fizycznych adresów kart Ethernet i Fibre-Channel na serwerze. Musi istnieć także możliwość przenoszenia przydzielonych adresów pomiędzy wnękami w obudowie. Funkcjonalność ta może być realizowana zarówno poprzez moduły LAN i SAN w infrastrukturze jak i poprzez dodatkowe oprogramowanie producenta serwerów blade. Dodatkowo dla sieci LAN musi istnieć możliwość stworzenia niezależnych połączeń VLAN tak aby między wydzielonymi sieciami nie było komunikacji. Wymagana jest możliwość boot’owania systemów operacyjnych zainstalowanych na poszczególnych serwerach blade bezpośrednio z macierzy w środowisku SAN. Wymagane wszystkie niezbędne licencje na opisaną funkcjonalność dla całej infrastruktury blade. W przypadku sieci LAN, musi istnieć możliwość określenia pasma przepustowości pojedynczego portu LAN na serwerze od 100Mb/s do 10Gb/s.
9.	Chłodzenie	Każda z obudów na serwery wyposażona w zestaw redundantnych wiatraków (typ hot plug, czyli możliwość wymiany podczas pracy urządzenia) zapewniających chłodzenie dla maksymalnej liczby serwerów i urządzeń I/O zainstalowanych w obudowie blade. Wentylatory niezależne od zasilaczy, wymiana wentylatora (wentylatorów) nie może powodować konieczności wyłączenia zasilacza/zasilaczy.
10.	Zasilanie	Każda z obudów wyposażona w zestaw zasilaczy redundantnych typu Hot Plug. System zasilania zdolny do obsługi awarii połowy z zainstalowanych zasilaczy (dowolne N zasilaczy przy założeniu konfiguracji N + N), wymagane ciągłe dostarczenie mocy niezbędnej do zasilenia maksymalnej liczby serwerów i urządzeń I/O zainstalowanych w obudowie. Procesory serwerów winny pracować z nominalną, maksymalną częstotliwością. Wymiana zasilacza nie może powodować konieczności odłączenia zewnętrznej infrastruktury zasilania (kabla zasilającego), jak również nie może powodować konieczności wyjęcia lub odłączenia wentylatorów (pojedynczego wentylatora lub modułu wentylatorów)
11.	Inne standardy komunikacyjne	Możliwość instalacji switchy w standardzie InfiniBand.
12.	Moduły zarządzające	Dwa redundantne, sprzętowe moduły zarządzające, moduły typu Hot Plug.
13.	Kompatybilność	Możliwość monitorowania infrastruktury serwerów blade za pomocą posiadanego przez Zamawiającego systemu monitorowania HP (Zamawiający nie wymaga licencji). Pełna kompatybilność z istniejącą infrastrukturą SAN Zamawiającego, na którą składają się: –  przełączniki HP 8/40 SAN Switch  HP AM870A 8/40 PowerPack+ 24-ports SAN switch - przełączniki HP 8/24 SAN switch HP AJ821A B-series 8/24c Blade System San Switch
14.	Gwarancja	3 letnia gwarancja w trybie 24/7 w miejscu instalacji na wszystkie elementy obudowy z gwarantowanym czasem naprawy 6h. Czas naprawy liczony jest od momentu zgłoszenia awarii.
15.	Podstawowe operacje	Zdalne włączanie/wyłączanie/restart niezależnie dla każdego serwera
16.	Udostępnianie napędów, CD-ROM, USB	Zdalne udostępnianie napędu CD-ROM/DVD/ISO na potrzeby każdego serwera z możliwością bootowania z w/w napędów
17.	Sposób zarządzania	Zdalny z poziomu przeglądarki internetowej, bez konieczności instalacji specyficznych komponentów programowych producenta sprzętu
18.	Liczba jednoczesnych sesji zarządzania	Niezależny, równoległy dostęp do konsol tekstowych i graficznych wszystkich serwerów w ramach infrastruktury.
19.	Zdalna identyfikacja	Zdalna identyfikacja fizycznego serwera i obudowy za pomocą sygnalizatora optycznego
20.	Dodatkowe cechy oprogramowania do zarządzania serwerami blade	• zautomatyzowane instalacje systemu operacyjnego z wykorzystaniem mechanizmu PXE (bootowanie z sieci) • zautomatyzowane, personalizowane, zrównoleglone instalacje systemów operacyjnych oraz aplikacji z wykorzystaniem tzw. plików odpowiedzi dostarczanych przez producenta oprogramowania użytkowego • zautomatyzowane, zrównoleglone kopiowanie środowisk, połączone z natychmiastową personalizacją systemu • zdalna dystrybucja oprogramowania, • automatyczne wykrywanie i identyfikacja urządzeń zainstalowanych w ramach infrastruktury (serwery, obudowy blade, karty zarządzające) i prezentacja infrastruktury w postaci graficznej • monitorowanie utylizacji następujących podzespołów serwera: procesor, pamięć, dyski twarde, interfejsy sieciowe • Integracja z oprogramowaniem do wirtualizacji, w zakresie wykrywania hostów, wirtualnych maszyn na nich pracujących, możliwości sterowania wirtualnymi maszynami (start, stop, przejęcie konsoli graficznej)
21.	Licencje	Licencje na powyższą funkcjonalność na wszystkie serwery blade dostarczone w ramach zamówienia.
22.	Dokumentacja	Dokumentacja techniczna w języku polskim lub angielskim wystarczająca do użytkowania urządzenia.

Tabela 4. Serwer blade typ 1

Lp.	Parametr	Wymagania minimalne
1.	Nazwa producenta
2.	Typ produktu, model
3.	Procesory (ilość i typ)	Cztery procesory sześciordzeniowe x86 - 64 bity, osiągające w testach SPECint_rate2006 wynik nie gorszy niż 850 punktów. Wynik testu musi być publikowany na stronie xxx.xxxx.xxx Zamawiający nie wymaga złożenia wraz z ofertą wyników w/w testów.
4.	Pamięć RAM	1TB RAM
5.	Sterownik dysków wewnętrznych	Macierzowy, RAID 0 ,1.
6.	Dyski twarde	Minimum dwa wewnętrzne dyski o sumarycznej pojemności użytkowej , 600GB, w RAID 1, 10K, 6Gbps, SAS 2.5" SFF. Możliwość obsługi dysków 2,5” o pojemności 146GB, 300GB, 600GB, 900GB.
7.	Interfejsy sieciowe (LAN)	Minimum 4 Interfejsy sieciowe 10GbE z możliwością podzielenia każdego interfejsu na 4 karty sieciowe (posiadające własne adresy MAC oraz będące widoczne z poziomu systemu operacyjnego jako fizyczne karty sieciowe). Podział musi być niezależny od zainstalowanego na serwerze systemu operacyjnego/platformy wirtualizacyjnej.
8.	Interfejsy FibreChannel SAN	Zainstalowane dwa interfejsy Fibre-Channel o prędkości 8Gb lub szybsze
9.	Wspierane systemy operacyjne	- Microsoft Windows Server 2008 - Microsoft Windows Server 2008 R2, - Microsoft Windows Server 2012 - Microsoft Windows Server 2012 R2 - Red Hat Enterprise Linux 6 Server x64 Edition - VMware ESXi 4.1 -VMware vSphere 5.0 (ESXi) - VMware vSphere 5.1 (ESXi) Posiadane przez Zamawiającego
10.	Gwarancja	3 letnia gwarancja w trybie 24/7 w miejscu instalacji na wszystkie elementy obudowy z gwarantowanym czasem naprawy 6h. Czas naprawy liczony jest od momentu zgłoszenia awarii.
11.	Dokumentacja	Dokumentacja techniczna w języku polskim lub angielskim wystarczająca do użytkowania urządzenia.

Tabela 5. Serwer blade typ 2

Lp.	Parametr	Wymagania minimalne
1.	Nazwa producenta
2.	Typ produktu, model
3.	Procesory (ilość i typ)	Dwa procesory sześciordzeniowe , x86 - 64 bity, osiągające w testach SPECint_rate2006 wynik nie gorszy niż 460 punktów. Wynik testu musi być publikowany na stronie xxx.xxxx.xxx Zamawiający nie wymaga złożenia wraz z ofertą wyników w/w testów.
4.	Pamięć RAM	512 GB RAM
5.	Sterownik dysków wewnętrznych	Macierzowy, RAID 0 ,1.
6.	Dyski twarde	Minimum dwa wewnętrzne dyski o sumarycznej pojemności użytkowej , 600GB, w RAID 1, 10K, 6Gbps, SAS 2.5" SFF Możliwość obsługi dysków 2,5” o pojemności 146GB, 300GB, 600GB, 900GB.
7.	Interfejsy sieciowe (LAN)	Minimum 2 Interfejsy sieciowe 10GbE z możliwością podzielenia każdego interfejsu na 4 karty sieciowe (posiadające własne adresy MAC oraz będące widoczne z poziomu systemu operacyjnego jako fizyczne karty sieciowe). Podział musi być niezależny od zainstalowanego na serwerze systemu operacyjnego/platformy wirtualizacyjnej.
8.	Interfejsy FibreChannel SAN	Zainstalowane dwa interfejsy Fibre-Channel o prędkości 8Gb lub szybsze
9.	Wspierane systemy operacyjne	- Microsoft Windows Server 2008 - Microsoft Windows Server 2008 R2, - Microsoft Windows Server 2012 - Microsoft Windows Server 2012 R2 - Red Hat Enterprise Linux 6 Server x64 Edition - - VMware ESXi 4.1 -VMware vSphere 5.0 (ESXi) - VMware vSphere 5.1 (ESXi) Posiadane przez Zamawiającego
10.	Gwarancja	3 letnia gwarancja w trybie 24/7 w miejscu instalacji na wszystkie elementy obudowy z gwarantowanym czasem naprawy 6h. Czas naprawy liczony jest od momentu zgłoszenia awarii.
11.	Dokumentacja	Dokumentacja techniczna w języku polskim lub angielskim wystarczająca do użytkowania urządzenia.

Tabela 6. UPS do infrastruktury

Lp.	Parametr	Wymagania minimalne
1.	Nazwa producenta
2.	Typ produktu, model
3.	Nominalne napięcie wyjściowe (V)	230V AC
4.	Częstotliwość wejściowa (auto sensing)	50/60 Hz + / - 3 Hz
5.	Moc rzeczywista:	6000 VA / 5600W
6.	Złącza wyjściowe	Cztery C19 Sześć C13 lub równoważne
7.	Zakres nominalnego napięcie wyjściowe	208-253V (230V)
8.	Czas ładowania	<3 godzin do 80% użytecznego naładowania, <48 godzin do całkowitego naładowania
9.	Możliwość zastosowania dodatkowych Zewnętrznych modułów baterii (EBM)	Minimum 1 zewnętrzny moduł baterii (EBM)
10.	Komunikacja i zarządzanie
	Port USB	TAK
	Port szeregowy RS-232	TAK
	Port Ethernet	Moduł umożliwiający zarządzanie, monitoring oraz diagnostykę poprzez sieć
	Ochrona przed przepięciami i filtracja	TAK
11.	Czas podtrzymania w zależności od obciążenia -przewidywany okres, w którym UPS będzie działać wyłącznie na baterii	min 15 minut przy 100 % obciążeniu- 6000VA
12.	Wysokość (podana w jednostkach EIA)	4U (max. 7U z modułem rozszerzeń)
13.	Gwarancja	3 letnia gwarancja w trybie 24/7 w miejscu instalacji z gwarantowanym czasem naprawy 72h. Czas naprawy liczony jest od momentu zgłoszenia awarii.

Tabela 7. UPS do macierzy

Lp.	Parametr	Wymagania minimalne
1.	Nazwa producenta
2.	Typ produktu, model
3.	Nominalne napięcie wyjściowe (V)	230V AC
4.	Częstotliwość wejściowa (auto sensing)	50/60 Hz + / - 3 Hz
5.	Moc rzeczywista:	7000 VA / 6300W
6.	Złącza wyjściowe	Sześć C19 lub równoważne
7.	Zakres nominalnego napięcie wyjściowe	208-253V (230V)
8.	Czas ładowania	<3 godzin do 80% użytecznego naładowania, <48 godzin do całkowitego naładowania
9.	Możliwość zastosowania dodatkowych Zewnętrznych modułów baterii (EBM)	Minimum 1 zewnętrzny moduł baterii (EBM)
10.	Komunikacja i zarządzanie
	Port USB	TAK
	Port szeregowy RS-232	TAK
	Port Ethernet	Moduł umożliwiający zarządzanie, monitoring oraz diagnostykę poprzez sieć
	Ochrona przed przepięciami i filtracja	TAK
11.	Czas podtrzymania w zależności od obciążenia -przewidywany okres, w którym UPS będzie działać wyłącznie na baterii	min 15 minut przy 100 % obciążeniu- 6000VA
12.	Wysokość (podana w jednostkach EIA)	5U (max. 8U z modułem rozszerzeń)
13.	Gwarancja	3 letnia gwarancja w trybie 24/7 w miejscu instalacji z gwarantowanym czasem naprawy 72h. Czas naprawy liczony jest od momentu zgłoszenia awarii.

Tabela 8. Serwer typ 3 - stelażowy

Lp.	Parametr	Wymagania minimalne
1.	Nazwa producenta
2.	Typ produktu, model
3.	Obudowa	Maksymalnie 4U RACK 19 cali (wraz ze wszystkimi elementami niezbędnymi do zamontowania serwera w oferowanej szafie)
4.	Procesor	Jeden procesor sześciordzeniowy , x86 - 64 bity, osiągający w testach SPECint_rate2006 wynik nie gorszy niż 460 punktów (dla konfiguracji dwuprocesorowej). Wynik testu musi być publikowany na stronie xxx.xxxx.xxx Zamawiający nie wymaga złożenia wraz z ofertą wyników w/w testów
5.	Liczba zainstalowanych procesorów	1, możliwość rozbudowy do 2 procesorów.
6.	Pamięć RAM	256 GB RAM z możliwością rozbudowy do 512 GB, w tym do 192GB bez konieczności wymiany dostarczonych modułów
7.	Sloty rozszerzeń	Minimum 2 sloty PCI-Express Generacji 3, w tym jeden slot x16 (prędkość slotu – bus width) oraz minimum jedno gniazdo pełnej wysokości.
8.	Dyski twarde	2 x dysk 300GB typu Hot Swap, SAS, 15 000 obr./min., możliwość rozbudowy do 8 dysków wewnątrz serwera.
9.	Kontroler	Kontroler macierzowy SAS wyposażony w pamięć cache 512MB oraz podtrzymywanie zawartości pamięci, zapewniający obsługę 8 napędów dyskowych SAS oraz obsługujący poziomy RAID 0/1/1+0/5
10.	Interfejsy sieciowe LAN	Minimum 4 porty Ethernet 10/100/1000 Mb/s z funkcją Wake-On-LAN, RJ45
11.	Interfejsy FibreChannel SAN	Zainstalowane dwa interfejsy Fibre-Channel o prędkości 8Gb lub szybsze
12.	Napęd optyczny	Wewnętrzny napęd DVD-ROM
13.	Karta graficzna	Zintegrowana karta graficzna
14.	Porty	1 x szeregowy 7 x USB 2.0 (w tym jeden wewnętrzny). VGA
15.	Zasilacz	Minimum 2 szt., typ Hot-plug, redundantne.
16.	Chłodzenie	Zestaw wentylatorów redundantnych typu hot-plug
17.	Zarządzanie i obsługa techniczna	Serwer musi być wyposażony w kartę zdalnego zarządzania (konsoli) pozwalającej na: włączenie, wyłączenie i restart serwera, podgląd logów sprzętowych serwera i karty, przejęcie pełnej konsoli tekstowej serwera niezależnie od jego stanu (także podczas startu, restartu OS). Możliwość przejęcia zdalnej konsoli graficznej i podłączania wirtualnych napędów CD/DVD/ISO i FDD. Rozwiązanie sprzętowe, niezależne od systemów operacyjnych, zintegrowane z płytą główną lub jako karta zainstalowana w gnieździe PCI. Dodatkowe funkcjonalności: zautomatyzowane instalacje systemu operacyjnego z wykorzystaniem mechanizmu PXE (bootowanie z sieci) zautomatyzowane, personalizowane, zrównoleglone instalacje systemów operacyjnych oraz aplikacji z wykorzystaniem tzw. plików odpowiedzi dostarczanych przez producenta oprogramowania użytkowego zautomatyzowane, zrównoleglone kopiowanie środowisk, połączone z natychmiastową personalizacją systemu zdalna dystrybucja oprogramowania, automatyczne wykrywanie i identyfikacja elementów sprzętowych serwera monitorowanie utylizacji następujących podzespołów serwera: procesor, pamięć, dyski twarde, interfejsy sieciowe Integracja z oprogramowaniem do wirtualizacji, w zakresie wykrywania hostów, wirtualnych maszyn na nich pracujących, możliwości sterowania wirtualnymi maszynami (start, stop, przejęcie konsoli graficznej)
18.	Wspierane systemy operacyjne	MS Windows Server, Red Hat Enterprise Linux, VMware – posiadane przez Zamawiającego
19.	Gwarancja	3 letnia gwarancja w trybie 24/7 w miejscu instalacji z gwarantowanym czasem naprawy 24h. Czas naprawy liczony jest od momentu zgłoszenia awarii.
20.	Dokumentacja	Dokumentacja techniczna w języku polskim lub angielskim wystarczająca do użytkowania urządzenia.

Tabela 9. Szafa Rack 19”

Lp.	Parametr	Wymagania minimalne
1.	Nazwa producenta
2.	Typ produktu, model
3.	Wysokość (podana w jednostkach EIA)	Minimum 42U
4.	Wyposażenie	Szafa wyposażona w zdejmowane drzwi przednie i tylne zamykane na klucz, zdejmowane panele boczne oraz elementy stabilizujące, zabezpieczające szafę przed wywróceniem, elementy uziemiające, zestaw do optymalizacji przepływu powietrza w szafie. Dodatkowo wymagane jest dostarczenie „zaślepek” wypełniających puste miejsce w szafie o łącznej wysokości 20U.

Tabela 10. Konsola zarządzająca do montażu w szafie Rack

Lp.	Parametr	Wymagania minimalne
1.	Nazwa producenta
2.	Typ produktu, model
3.	Konsola zarządzająca	Konsola składająca się z monitora (minimum 17’’), klawiatury i urządzenia wskazującego (track ball, touchpad). Zajmująca w szafie nie więcej niż 1U.
4.	Przełącznik KVM	Minimum 8 portów RJ45 do podłączenia z serwerami Możliwość instalacji za oferowaną konsolą zarządzającą, tak, aby całość rozwiązania zajmowała w szafie rack wysokość 1U Możliwość stackowania oferowanego switch’a KVM w celu podłączenia do minimum 256 serwerów
5.	Adaptery do przełącznika KVM	8 sztuk adapterów RJ45 do USB/VGA
6.	Gwarancja	3 letnia gwarancja w trybie 24/7 w miejscu instalacji w miejscu instalacji z gwarantowanym czasem naprawy 72h. Czas naprawy liczony jest od momentu zgłoszenia awarii.

Tabela 11. Moduł zasilania PDU

Lp.	Parametr	Wymagania minimalne
1.	Nazwa producenta
2.	Typ produktu, model
3.	Dostarczane okablowanie	Dla wszystkich dostarczanych urządzeń Wykonawca zapewni odpowiednią ilość (o odpowiednich parametrach), kabli zasilających, kabli KVM, kabli FC, kabli Ethernet oraz modułów dystrybuujących zasilanie w szafach Rack (tzw. PDU) niezbędną do przeprowadzenia instalacji urządzeń zgodnie w wymogami producentów
4.	Sposób zasilania szaf Rack	Zasilanie do szaf Rack podłączane z dwóch niezależnych zewnętrznych źródeł zasilania jednofazowego kablami dostarczonymi przez Wykonawcę (220-240V 63A IEC 309 P+N+G).
5.	Dystrybucja zasilania	Zasilanie wewnątrz szaf Rack musi być dystrybuowane przy pomocy PDU w sposób redundantny do osobnych zasilaczy w poszczególnych urządzeniach.
6.	Sposób zasilania	Jeden obwód zasilania powinien przechodzić przez UPS a drugi bezpośrednio do urządzeń.
7.	Gwarancja	3 letnia gwarancja w trybie 24/7 w miejscu instalacji z gwarantowanym czasem naprawy 72h. Czas naprawy liczony jest od momentu zgłoszenia awarii.

Tabela 12. Dyski zapasowe

Lp.	Parametr	Wymagania minimalne
I.	Do posiadanej przez Zamawiającego macierzy HP StorgeWorks EVA 8100 S/N:GB8092239M, dostarczone dyski nie mogą pogorszyć żadnego z parametrów pracy macierzy
I.1.	Dyski twarde typ 1 – 10 szt.
I.1.1	Nazwa producenta dysku
I.1.2	Part Number :	współpracujący z macierzą HP StorgeWorks EVA 8100 posiadaną przez Zamawiającego
I.1.3	Interfejs dysku twardego	Fiber Channel ATA (FATA)
I.1.4	Pojemność dysku twardego	1.0TB
I.1.5	Typ dysku twardego	3,5 inch
I.1.6	Szybkość obrotowa	7 200RPM
I.1.7	Hot - swap	Tak.
I.1.8	Dysk wewnętrzny w kasecie	Tak
I.1.9	Gwarancja	3 letnia gwarancja producenta w trybie 24/7 w miejscu instalacji
I.2.	Dyski twarde typ 2 – 10 szt.
I.2.1	Nazwa producenta dysku
I.2.2	Part Number :	współpracujący z macierzą HP StorgeWorks EVA 8100 posiadaną przez Zamawiającego
I.2.3	Interfejs dysku twardego	Fibre Channel
2.4	Pojemność dysku twardego	300GB
I.2.5	Typ dysku twardego	3,5 inch
I.2.6	Szybkość obrotowa	15 000RPM
I.2.7	Hot - swap	Tak.
I.2.8	Dysk wewnętrzny w kasecie	Tak
I.2.9	Gwarancja	3 letnia gwarancja producenta w trybie 24/7 w miejscu instalacji
I.3.	Dyski twarde typ 3 – 10 szt.
I.3.1	Nazwa producenta dysku
I.3.2	Part Number :	współpracujący z macierzą HP StorgeWorks EVA 8100 posiadaną przez Zamawiającego
I.3.3	Interfejs dysku twardego	Fibre Channel
I.3.4	Pojemność dysku twardego	450GB
I.3.5	Typ dysku twardego	3,5 inch
I.3.6	Szybkość obrotowa	15 000RPM
I.3.7	Hot - swap	Tak.
I.3.8	Dysk wewnętrzny w kasecie	Tak
I.3.9	Gwarancja	3 letnia gwarancja producenta w trybie 24/7 w miejscu instalacji
II.	Do posiadanej przez Zamawiającego macierzy HP StorgeWorks EVA 8400 S/N: GB8101614N, dostarczone dyski nie mogą pogorszyć żadnego z parametrów pracy macierzy
II.1.	Dyski twarde typ 4 – 5 szt.
II.1.1	Nazwa producenta dysku
II.1.2	Part Number :	współpracujący z macierzą HP StorgeWorks EVA 8400 posiadaną przez Zamawiającego
II.1.3	Interfejs dysku twardego	Fibre Channel
II.1.4	Pojemność dysku twardego	600GB
II.1.5	Typ dysku twardego	3,5 inch
II.1.6	Szybkość obrotowa	15 000RPM
II.1.7	Hot - swap	Tak.
II.1.8	Dysk wewnętrzny w kasecie	Tak
II.1.9	Gwarancja	3 letnia gwarancja producenta w trybie 24/7 w miejscu instalacji
II.2.	Dyski twarde typ 5 – 5 szt.
II.2.1	Nazwa producenta dysku
II.2.2	Part Number :	współpracujący z macierzą HP StorgeWorks EVA 8400 posiadaną przez Zamawiającego
II.2.3	Interfejs dysku twardego	Fibre Channel
II.2.4	Pojemność dysku twardego	450GB
II.2.5	Typ dysku twardego	3,5 inch
II.2.6	Szybkość obrotowa	15 000RPM
II.2.7	Hot - swap	Tak.
II.2.8	Dysk wewnętrzny w kasecie	Tak
II.2.9	Gwarancja	3 letnia gwarancja producenta w trybie 24/7 w miejscu instalacji

Zadanie 2. Rozbudowa i wykonanie konsolidacji sieci SAN

W ramach konsolidacji sieci SAN Wykonawca przeprowadzi projekt infrastrukturalny, którego celem jest rozbudowa oraz takie połączenie istniejących sieci SAN, aby zapewnić z jednej strony wysoką dostępność i optymalną pracę urządzeń pamięci masowych, z drugiej elastyczną możliwość przypisywania zasobów do odpowiednich serwerów.

Po konsolidacji powinna powstać uniwersalna, bezpieczna (redundantna), elastyczna, skalowalna infrastruktura jednej sieci SAN oraz ujednolicona konfiguracja portów na przełącznikach.

W ramach zadania Wykonawca zrealizuje:

1. W odniesieniu do konsolidacji

1. Przeprowadzi analizę obecnego środowiska SAN oraz opracuje i uzgodni koncepcję konsolidacji istniejących sieci SAN oraz podłączenia dostarczonego sprzętu do sieci SAN;

2. Przygotuje szczegółowy Projekt Techniczny realizacji uzgodnionej koncepcji uwzględniający dobre praktyki i rekomendacje eksploatacyjne publikowane przez producenta urządzeń, w tym przygotuje kompletny plan wdrożenia zoningu w oparciu o adresy WWN urządzeń;

3. Opracuje i uzgodni szczegółowy harmonogram realizacji prac uwzględniający specyfikę organizacji Zamawiającego;

4. Wykona niezbędne połączenia zgodnie z zaakceptowanym Projektem Technicznym konsolidacji;

5. Wykona podniesienie wersji mikrokodów switchy FC;

6. Wykona podniesienie mikrokodów procesorów macierzy HP EVA 8100 i dysków;

7. Przeprowadzi rekonfigurację przełączników sieci SAN;

8. Wykona testy akceptacyjne:

1. testy niezawodnościowe dla wybranej grupy serwerów i macierzy dyskowych;

2. testy funkcjonalne.

1. Opracuje Dokumentację Powykonawczą zawierającą schemat i opis wdrożonej konfiguracji oraz procedury eksploatacyjne w zakresie uzgodnionym z Zamawiającym.

2. W odniesieniu do rozbudowy środowiska SAN.

Do posiadanych przez Zamawiającego 2 przełączników HP AM870A 8/40 PowerPack+ 24-ports SAN switch, każdy z 28 wkładkami HP AJ716A 8Gb Shortwave B-series FC SFP+ 1 pack, dołoży po 12 szt. wkładek 8Gb FC SFP w celu wypełnienia wszystkich portów (razem 24 wkładki).

Rozbuduje 2 przełączniki HP AM870A 8/40 PowerPack+ 24-ports SAN switch (32 aktywne porty na każdym z przełączników) o dodatkowe licencje aktywujące wszystkie 40 portów. Zamawiający nie ogranicza możliwości zaoferowania różnych licencji ale wymaga aby umożliwiały one uzyskanie pełnej funkcjonalności uaktywnianych portów przełączników

Wykonawca dostarczy wszystkie dodatkowe elementy i licencje , których nie posiada Zamawiający, a będą potrzebne do realizacji projektu konsolidacji w tym odpowiednie kable światłowodowe. Minimalna ilość dostarczanych kabli, o długości 15 m, typu FC LC-LC OM-3/OM-4 to 32 szt.

Wszystkie wyspecyfikowane elementy rozbudowy przełączników SAN - sprzętowe i licencje, powinny być objęte gwarancją 3 letnią na poziomie nie niższym niż 24/7 z czasem naprawy 24h.

Zadanie 3. Dostawa oraz wdrożenie oprogramowania systemowego, bazodanowego i narzędziowego

Tabela 13. Zbiorcza specyfikacja ilościowa licencji dostarczana w zadaniu

Typ oprogramowania	Liczba licencji
Serwerowy system operacyjny (licencjonowany na procesor) dedykowany dla środowisk o wysokim stopniu wirtualizacji	16
Serwerowy system operacyjny (licencjonowany na procesor) dedykowany dla środowisk o niskim stopniu wirtualizacji	26
Pakiet produktów narzędziowych do zarządzania i monitorowania serwerów oraz zarządzania wirtualizacją serwerów (licencjonowany na procesor) dedykowany dla środowisk o wysokim stopniu wirtualizacji	16
Pakiet produktów narzędziowych do zarządzania i monitorowania serwerów oraz zarządzania wirtualizacją serwerów (licencjonowany na procesor) dedykowany dla środowisk o niskim stopniu wirtualizacji	26
System bazodanowy dla środowiska testowo-rozwojowego (dla 100 użytkowników)	1
System bazodanowy typ 1 (licencjonowany na rdzeń procesora)	48
System bazodanowy typ 2 (licencjonowany na rdzeń procesora)	36

Dostawa oprogramowania i zakup licencji jest uzupełnieniem stanu licencyjnego oprogramowania eksploatowanego w środowisku serwerowym Zamawiającego, zakupionego w wyniku rozstrzygnięcia postępowań o zamówieniach publicznych w trybie przetargu nieograniczonego x.xx. COIS-22/2009/SISP, COIS-2/2010/SISP, 14/SISP/PN/2013.

Systemy MS XXXX 2007 R2 i MS SCCM 2007 R3 zostały zakupione z usługą Software Assurance. W roku 2012 producent oprogramowania zmienił sposób licencjonowania produktów i obecnie Zamawiający posiada licencje na pakiety narzędziowe do monitorowania, zarządzania serwerów i zarządzania wirtualizacją serwerów zgodne z nowym trybem licencjonowania.

Zamawiający nie ogranicza możliwości zaoferowania różnych licencji ale wymaga aby spełniały następujące warunki:

1. Licencje muszą pozwalać na swobodne przenoszenie pomiędzy stacjami roboczymi i serwerami (np. w przypadku wymiany sprzętu) oraz możliwość sublicencjonowania dla jednostek organizacyjnych służb statystyki publicznej podległych Prezesowi GUS.

2. Licencjonowanie musi uwzględniać prawo do (w okresie przynajmniej 3 lat) bezpłatnej instalacji udostępnianych przez producenta oprogramowania poprawek krytycznych i opcjonalnych do zakupionej wersji oprogramowania.

3. Zamawiający nie wymaga subskrypcji na zamawiane oprogramowanie.

4. Z uwagi na szeroki zakres funkcjonalny i terytorialny wdrożenia planowanego na bazie zamawianego oprogramowania oraz konieczności minimalizacji kosztów związanych z wdrożeniem, szkoleniami i eksploatacją systemów, Zamawiający wymaga oferty zawierającej licencje, umożliwiające wykorzystanie wspólnych i jednolitych procedur masowej instalacji, uaktualniania, zarządzania i monitorowania.

5. Wymagane jest zapewnienie możliwości korzystania z wcześniejszych wersji zamawianego oprogramowania i korzystania z kopii zamiennych (możliwość kopiowania oprogramowania na wiele urządzeń przy wykorzystaniu jednego standardowego obrazu uzyskanego z nośników dostępnych w programach licencji grupowych), z prawem do wielokrotnego użycia jednego obrazu dysku w procesie instalacji i tworzenia kopii zapasowych.

6. W ramach umowy Wykonawca ma zapewnić udzielanie uprawnień na witrynie producenta oprogramowania wskazanym przez Xxxxxxxxxxxxx osobom (pracownikom Zamawiającego) do pobierania kodu zamówionego oprogramowania i kluczy licencyjnych.

W ramach wdrożenia systemów operacyjnych Wykonawca przeprowadzi instalację systemów operacyjnych wraz z konfiguracją niezbędnych składników potrzebnych do prawidłowej pracy serwerów w środowisku Zamawiającego oraz instalację i konfigurację systemów bazodanowych.

W ramach zadania Wykonawca:

• Opracuje i uzgodni szczegółowy harmonogram realizacji prac uwzględniający specyfikę organizacji Zamawiającego,

• Przeprowadzi instalację systemu operacyjnego,

• Wykona instalację poprawek systemowych,

• Wykona instalację oprogramowania i sterowników dedykowanych dla danego typu serwera przez producenta sprzętu,

• Wykona instalację i konfigurację oprogramowania do zarządzania i monitoringu sprzętowego dostarczanego przez producenta serwerów,

• Podłączy wskazane przez Zamawiającego zasoby macierzowe,

• Wykona instalację i konfigurację oprogramowania klienckiego modułu monitorowania wydajności  i dostępności,

• Wykona instalację i konfigurację oprogramowania klienckiego modułu zarządzania konfiguracją 

• Wykona instalację i konfigurację oprogramowania bazodanowego

• Opracuje Dokumentację powykonawczą

Serwerowy system operacyjny dedykowany dla środowisk o wysokim stopniu wirtualizacji

Licencja na oprogramowanie musi być przypisana do każdego procesora fizycznego na serwerze. Liczba rdzeni procesorów i ilość pamięci nie mogą mieć wpływu na liczbę wymaganych licencji. Licencja musi uprawniać do uruchamiania serwerowego systemu operacyjnego (SSO) w środowisku fizycznym i nielimitowanej liczby wirtualnych środowisk serwerowego systemu operacyjnego za pomocą wbudowanych mechanizmów wirtualizacji.

Serwerowy system operacyjny (SSO) musi posiadać następujące, wbudowane cechy:

1. Możliwość wykorzystania co najmniej 2 logicznych procesorów oraz co najmniej 4 TB pamięci RAM w środowisku fizycznym.

2. Możliwość wykorzystywania 64 procesorów wirtualnych oraz 1TB pamięci RAM i dysku o pojemności do 64TB przez każdy wirtualny serwerowy system operacyjny.

3. Możliwość budowania klastrów składających się z 16 węzłów, z możliwością uruchamiania do 2000 maszyn wirtualnych.

4. Możliwość migracji maszyn wirtualnych bez zatrzymywania ich pracy między fizycznymi serwerami z uruchomionym mechanizmem wirtualizacji (hypervisor) przez sieć Ethernet, bez konieczności stosowania dodatkowych mechanizmów współdzielenia pamięci.

5. Wsparcie (na umożliwiającym to sprzęcie) dodawania i wymiany pamięci RAM bez przerywania pracy.

6. Wsparcie (na umożliwiającym to sprzęcie) dodawania i wymiany procesorów bez przerywania pracy.

7. Automatyczna weryfikacja cyfrowych sygnatur sterowników w celu sprawdzenia, czy sterownik przeszedł testy jakości przeprowadzone przez producenta systemu operacyjnego.

8. Możliwość dynamicznego obniżania poboru energii przez rdzenie procesorów niewykorzystywane w bieżącej pracy. Mechanizm ten musi uwzględniać specyfikę procesorów wyposażonych w mechanizmy Hyper-Threading.

9. Wbudowane wsparcie instalacji i pracy na wolumenach, które:

   1. pozwalają na zmianę rozmiaru w czasie pracy systemu,

   2. umożliwiają tworzenie w czasie pracy systemu migawek, dających użytkownikom końcowym (lokalnym i sieciowym) prosty wgląd w poprzednie wersje plików i folderów,

   3. umożliwiają kompresję "w locie" dla wybranych plików i/lub folderów,

   4. umożliwiają zdefiniowanie list kontroli dostępu (ACL).

10. Wbudowany mechanizm klasyfikowania i indeksowania plików (dokumentów) w oparciu o ich zawartość.

11. Wbudowane szyfrowanie dysków przy pomocy mechanizmów posiadających certyfikat FIPS 140-2 lub równoważny wydany przez instytucję lub firmę upoważnioną do wydawania certyfikatu bezpieczeństwa danych. Za równoważny Zamawiający uzna certyfikat potwierdzający bezpieczeństwo danych .

12. Możliwość uruchamiania aplikacji internetowych wykorzystujących technologię XXX.XXX.

13. Wbudowana zapora internetowa (firewall) z obsługą definiowanych reguł dla ochrony połączeń internetowych i intranetowych.

14. Graficzny interfejs użytkownika.

15. Zlokalizowane w języku polskim, co najmniej następujące elementy: menu, przeglądarka internetowa, pomoc, komunikaty systemowe.

16. Możliwość zmiany języka interfejsu po zainstalowaniu systemu, dla co najmniej 4 języków poprzez wybór z listy dostępnych lokalizacji.

17. Wsparcie dla większości powszechnie używanych urządzeń peryferyjnych (drukarek, urządzeń sieciowych, standardów USB, Plug&Play).

18. Możliwość zdalnej konfiguracji, administrowania oraz aktualizowania systemu.

19. Dostępność bezpłatnych narzędzi producenta systemu umożliwiających badanie i wdrażanie zdefiniowanego zestawu polityk bezpieczeństwa.

20. Pochodzący od producenta systemu serwis zarządzania prawami do informacji w dokumentach (Digital Rights Management).

21. Możliwość implementacji następujących funkcjonalności bez potrzeby instalowania dodatkowych produktów (oprogramowania) innych producentów wymagających dodatkowych licencji:

1. Podstawowe usługi sieciowe: DHCP oraz DNS wspierający DNSSEC,

2. Usługi katalogowe oparte o LDAP i pozwalające na uwierzytelnianie użytkowników stacji roboczych, bez konieczności instalowania dodatkowego oprogramowania na tych stacjach, pozwalające na zarządzanie zasobami w sieci (użytkownicy, komputery, drukarki, udziały sieciowe) z możliwością wykorzystania następujących funkcji:

1. Podłączenie SSO do domeny w trybie offline – bez dostępnego połączenia sieciowego z domeną,

2. Ustanawianie praw dostępu do zasobów domeny na bazie sposobu logowania użytkownika – na przykład typu certyfikatu użytego do logowania,

3. Odzyskiwanie przypadkowo skasowanych obiektów usługi katalogowej z mechanizmu kosza.

3. Zdalna dystrybucja oprogramowania na stacje robocze,

4. Praca zdalna na serwerze z wykorzystaniem terminala (cienkiego klienta) lub odpowiednio skonfigurowanej stacji roboczej,

5. Centrum Certyfikatów (CA), obsługa klucza publicznego i prywatnego umożliwiające:

1. Dystrybucję certyfikatów poprzez http,

2. Konsolidację CA dla wielu lasów domen,

3. Automatyczne rejestrowanie certyfikatów pomiędzy różnymi lasami domen.

6. Szyfrowanie plików i folderów,

7. Szyfrowanie połączeń sieciowych pomiędzy serwerami oraz serwerami i stacjami roboczymi (IPSec),

8. Możliwość tworzenia systemów wysokiej dostępności (klastry typu failover) oraz rozłożenia obciążenia serwerów,

9. Serwis udostępniania stron WWW,

10. Wsparcie dla protokołu IP w wersji 6 (IPv6),

11. Wbudowane usługi VPN pozwalające na zestawienie nielimitowanej liczby równoczesnych połączeń i niewymagające instalacji dodatkowego oprogramowania na komputerach z systemem Windows posiadanych przez Zamawiającego,

12. Wbudowane mechanizmy wirtualizacji (Hypervisor) pozwalające na uruchamianie do 1000 aktywnych środowisk wirtualnych systemów operacyjnych. Wirtualne maszyny w trakcie pracy i bez zauważalnego zmniejszenia ich dostępności mogą być przenoszone pomiędzy serwerami klastra typu failover z jednoczesnym zachowaniem pozostałej funkcjonalności. Mechanizmy wirtualizacji mają zapewnić wsparcie dla:

1. Dynamicznego podłączania zasobów dyskowych typu hot-plug do maszyn wirtualnych,

2. Obsługi ramek typu jumbo frames dla maszyn wirtualnych,

3. Obsługi 4-KB sektorów dysków,

4. Nielimitowanej liczby jednocześnie przenoszonych maszyn wirtualnych pomiędzy węzłami klastra,

5. Możliwości wirtualizacji sieci z zastosowaniem przełącznika, którego funkcjonalność może być rozszerzana jednocześnie poprzez oprogramowanie kilku innych dostawców poprzez otwarty interfejs API,

6. Możliwości kierowania ruchu sieciowego z wielu sieci VLAN bezpośrednio do pojedynczej karty sieciowej maszyny wirtualnej (tzw. trunk mode).

22. Możliwość automatycznej aktualizacji w oparciu o poprawki publikowane przez producenta wraz z dostępnością bezpłatnego rozwiązania producenta SSO umożliwiającego lokalną dystrybucję poprawek zatwierdzonych przez administratora, bez połączenia z siecią Internet.

23. Wsparcie dostępu do zasobu dyskowego SSO poprzez wiele ścieżek (Multipath).

24. Możliwość instalacji poprawek poprzez wgranie ich do obrazu instalacyjnego.

25. Mechanizmy zdalnej administracji oraz mechanizmy (również działające zdalnie) administracji przez skrypty.

26. Możliwość zarządzania przez wbudowane mechanizmy zgodne ze standardami WBEM oraz WS-Management organizacji DMTF.

Serwerowy system operacyjny dedykowany dla środowisk o niskim stopniu wirtualizacji

Licencja na oprogramowanie musi być przypisana do każdego procesora fizycznego na serwerze. Liczba rdzeni procesorów i ilość pamięci nie mogą mieć wpływu na liczbę wymaganych licencji. Licencja musi uprawniać do uruchamiania serwerowego systemu operacyjnego (SSO) w środowisku fizycznym i dwóch wirtualnych środowisk serwerowego systemu operacyjnego za pomocą wbudowanych mechanizmów wirtualizacji.

Serwerowy system operacyjny (SSO) musi posiadać wbudowane cechy takie jak podano w opisie przeznaczonym dla serwerowego systemu operacyjnego dla środowisk o wysokim stopniu wirtualizacji.

Pakiet produktów narzędziowych do zarządzania i monitorowania serwerów oraz zarządzania wirtualizacją serwerów dedykowany dla środowisk o wysokim stopniu wirtualizacji

Licencja na oprogramowanie musi być przypisana do każdego procesora fizycznego na serwerze zarządzanym. Liczba rdzeni procesorów i ilość pamięci nie mogą mieć wpływu na liczbę wymaganych licencji. Licencja musi uprawniać do zarządzania i monitorowania nielimitowaną liczbą wirtualnych środowisk serwerowego systemu operacyjnego. za pomocą wbudowanych mechanizmów wirtualizacji.

Pakiet narzędziowy musi obejmować wszystkie funkcje zawarte w opisanych poniżej modułach:

1. System zarządzania infrastrukturą i oprogramowaniem

2. System zarządzania komponentami

3. System zarządzania środowiskami wirtualnym

4. System tworzenia kopii zapasowych

5. System automatyzacji zarządzania środowisk IT

6. System zarządzania incydentami i problemami

7. Ochrona antymalware

1. System zarządzania infrastrukturą i oprogramowaniem

System zarządzania infrastrukturą i oprogramowaniem musi spełniać następujące wymagania poprzez natywne dla niego mechanizmy, bez użycia dodatkowych aplikacji.

1. Inwentaryzacja i zarządzanie zasobami:

1. Inwentaryzacja zasobów serwera powinna się odbywać w określonych przez administratora systemu interwałach czasowych. System powinien mieć możliwość odrębnego planowania inwentaryzacji sprzętu i oprogramowania,

2. Inwentaryzacja sprzętu powinna się odbywać przez pobieranie informacji
   z interfejsu WMI, komponent inwentaryzacyjny powinien mieć możliwość konfiguracji w celu ustalenia informacji, o jakich podzespołach będą przekazywane dane do systemu ,

3. Inwentaryzacja oprogramowania powinna skanować zasoby dyskowe przekazując dane o znalezionych plikach do systemu w celu identyfikacji oprogramowania oraz celów wyszukiwania i gromadzenia informacji o szczególnych typach plików (np. pliki multimedialne: wav, mp3, avi, xvid),

4. System powinien posiadać własną bazę dostępnego na rynku komercyjnego oprogramowania, pozwalającą na identyfikację zainstalowanego i użytkowanego oprogramowania. System powinien dawać możliwość aktualizacji tej bazy przy pomocy konsoli administratora oraz automatycznie przez aktualizacje ze stron producenta,

5. Informacje inwentaryzacyjne powinny być przesyłane przy pomocy plików różnicowych w celu ograniczenia ruchu z agenta do serwera.

2. Użytkowane oprogramowanie – pomiar wykorzystania

1. System powinien mieć możliwość zliczania uruchomionego oprogramowania
   w celu śledzenia wykorzystania,

2. Reguły dotyczące monitorowanego oprogramowania powinny być tworzone automatycznie przez skanowanie oprogramowania uruchamianego.

2. System powinien dostarczać funkcje dystrybucji oprogramowania, dystrybucji
   i zarządzania aktualizacjami, instalacji/aktualizacji systemów operacyjnych.

3. Definiowanie i sprawdzanie standardu serwera:

1. System powinien posiadać komponenty umożliwiające zdefiniowanie i okresowe sprawdzanie standardu serwera, standard ten powinien być określony zestawem reguł sprawdzających definiowanych z poziomu konsoli administracyjnej,

2. Reguły powinny sprawdzać następujące elementy systemu komputerowego:

• stan usługi

• obecność poprawek (Hotfix)

• WMI

• rejestr systemowy

• system plików

• Active Directory

• SQL (query)

• Metabase

2. Raportowanie, prezentacja danych:

1. System powinien posiadać komponent raportujący oparty o technologie webową (wydzielony portal z raportami) i/lub wykorzystujący mechanizmy raportujące dostarczane wraz z silnikami bazodanowymi, np. SQL Reporting Services,

2. System powinien posiadać predefiniowane raporty w następujących kategoriach:

• Sprzęt (inwentaryzacja)

• Oprogramowanie (inwentaryzacja)

• Oprogramowanie (wykorzystanie)

• Oprogramowanie (aktualizacje, w tym system operacyjny)

3. System powinien umożliwiać budowanie stron z raportami w postaci tablic (dashboard), na których może znajdować się więcej niż jeden raport,

4. System powinien posiadać konsolę administratora, w postaci programu
   do zainstalowania na stacjach roboczych, obsługującą wszystkie funkcje systemu,

2. System zarządzania komponentami

System zarządzania komponentami musi udostępniać funkcje pozwalające na budowę bezpiecznych i skalowalnych mechanizmów zarządzania komponentami IT spełniając następujące wymagania:

1. Architektura:

1. Serwery zarządzające muszą mieć możliwość publikowania informacji
   o uruchomionych komponentach w usługach katalogowych, informacje te powinny być dostępne dla klientów systemu w celu automatycznej konfiguracji,

2. Możliwość budowania struktury wielopoziomowej (tiers) w celu separacji pewnych grup komputerów/usług,

3. System uprawnień musi być oparty o role (role based security), użytkownicy
   i grupy użytkowników w poszczególnych rolach powinny być pobierane z usług katalogowych,

4. Możliwość definiowania użytkowników do wykonywania poszczególnych zadań
   na klientach i serwerze zarządzającym, w tym zdefiniowany użytkownik domyślny,

5. Uwierzytelnianie klientów na serwerze zarządzającym przy pomocy certyfikatów
   w standardzie X.509, z możliwością odrzucania połączeń od klientów niezaakceptowanych,

6. Kanał komunikacyjny pomiędzy klientami a serwerem zarządzającym powinien być szyfrowany,

7. Możliwość budowania systemu w oparciu o łącza publiczne - Internet (bez konieczności wydzielania kanałów VPN),

8. Wsparcie dla protokołu Ipv6,

9. System powinien udostępniać funkcje autodiagnostyczne, w tym: monitorowanie stanu klientów, możliwość automatycznego lub administracyjnego restartu klienta, możliwość reinstalacji klienta,

2. Audyt zdarzeń bezpieczeństwa

System musi udostępniać komponenty i funkcje pozwalające na zbudowanie systemu zbierającego zdarzenia związane z bezpieczeństwem monitorowanych systemów
i gwarantować:

1. Przekazywanie zdarzeń z podległych klientów w czasie jak najbardziej zbliżonym do rzeczywistego (dopuszczalne opóźnienia mogą pochodzić z medium transportowego – sieć, oraz komponentów zapisujących i odczytujących),

2. Niskie obciążenie sieci poprzez schematyzację parametrów zdarzeń przed wysłaniem, definicja schematu powinna być definiowana w pliku XML
   z możliwością dodawania i modyfikacji,

3. Konfiguracja i monitorowanie

System musi umożliwiać zbudowanie jednorodnego środowiska monitorującego, korzystając z takich samych zasad do monitorowania różnych komponentów,
a w tym:

1. Monitorowane obiekty powinny być grupowane (klasy) w oparciu o atrybuty, które można wykryć na klientach systemu w celu autokonfiguracji systemu. Powinny być wykrywane - co najmniej, atrybuty pobierane z:

• rejestru

• WMI

• OLEDB

• LDAP

• skrypty (uruchamiane w celu wykrycia atrybutów obiektu),

W definicjach klas powinny być również odzwierciedlone zależności pomiędzy nimi,

2. Na podstawie wykrytych atrybutów system powinien dokonywać autokonfiguracji klientów, przez wysłanie odpowiadającego wykrytym obiektom zestawu monitorów, reguł, skryptów, zadań,

3. Wszystkie klasy obiektów, monitory, reguły, skrypty, zadania i inne elementy służące konfiguracji systemu muszą być grupowane i dostarczane w postaci zestawów monitorujących, system powinien posiadać w standardzie zestawy monitorujące, co najmniej dla poniższych systemów posiadanych przez Zamawiającego:

• Windows Server /2008/2008R2/2012

• Active Directory 2008/2012

• Exchange 2007/2010

• Microsoft SharePoint 2003/2007/2010

• Microsoft SharePoint Services 3.0

• Microsoft SharePoint Foundation 2010

• SQL 2005/2008/2008R2/2012 (x86/x64/ia64)

• Information Worker (Office, IExplorer, Outlook)

• IIS 6.0/7.0/7.5

• HP-UX 11i v2

• Red Hat Enterprise Linux 4/5/6 (x86/x64)

• IBM AIX v5.3 i v6.1/v7.1 (POWER)

4. System powinien posiadać możliwość monitorowania za pomocą agenta lub bez niego,

5. System musi pozwalać na wykrycie oraz monitorowanie urządzeń sieciowych (routery, przełączniki sieciowe) za pomocą SNMP v1, v2c oraz v3. System monitorowania w szczególności powinien mieć możliwość zbierania następujących informacji:

• interfejsy sieciowe

• porty

• sieci wirtualne (VLAN)

• grupy Hot Standby Router Protocol (HSRP)

6. System zarządzania musi mieć możliwość czerpania informacji z następujących źródeł danych:

• SNMP (trap, probe)

• WMI Performance Counters

• Log Files (text, text CSV)

• Windows Events (logi systemowe)

• Windows Services

• Windows Performance Counters (perflib)

• WMI Events

• Scripts (wyniki skryptów, np.: WSH, JSH)

• Unix/Linux Service

• Unix/Linux Log

7. Na podstawie uzyskanych informacji monitor powinien aktualizować status komponentu, powinna być możliwość łączenia i agregowania statusu wielu monitorów

4. Tworzenie reguł

1. w systemie zarządzania powinna mieć możliwość czerpania informacji
   z następujących źródeł danych:

• Event based (text, text CSV, NT Event Log, SNMP Event, SNMP Trap, syslog, WMI Event)

• Performance based (SNMP performance, WMI performance, Windows performance)

• Probe based (scripts: event, performance)

2. System musi umożliwiać przekazywanie zebranych przez reguły informacji
   do bazy danych w celu ich późniejszego wykorzystania w systemie, np. raporty dotyczące wydajności komponentów, alarmy mówiące o przekroczeniu wartości progowych czy wystąpieniu niepożądanego zdarzenia,

3. Reguły zbierające dane wydajnościowe muszą mieć możliwość ustawiania tolerancji na zmiany, w celu ograniczenia ilości nieistotnych danych przechowywanych w systemie bazodanowym. Tolerancja powinna mieć,
   co najmniej dwie możliwości:

• na ilość takich samych próbek o takiej samej wartości

• na procentową zmianę od ostatniej wartości próbki

4. Monitory sprawdzające dane wydajnościowe w celu wyszukiwania wartości progowych muszą mieć możliwość – oprócz ustawiania progów statycznych, „uczenia” się monitorowanego parametru w zakresie przebiegu bazowego „baseline” w zadanym okresie czasu,

5. System musi umożliwiać blokowanie modyfikacji zestawów monitorujących, oraz definiowanie wyjątków na grupy komponentów lub konkretne komponenty w celu ich odmiennej konfiguracji,

6. System powinien posiadać narzędzia do konfiguracji monitorów dla aplikacji
   i usług, w tym:

• ASP .Net Application

• ASP .Net Web Service

• OLE DB

• TCP Port

• Web Application

• Windows Service

• Unix/Linux Service

• Process Monitoring

Narzędzia te powinny pozwalać na zbudowanie zestawu predefiniowanych monitorów dla wybranej aplikacji i przyporządkowanie ich do wykrytej/działającej aplikacji,

7. System musi posiadać narzędzia do budowania modeli aplikacji rozproszonych (składających się z wielu wykrytych obiektów), pozwalając na agregację stanu aplikacji oraz zagnieżdżanie aplikacji,

8. Z każdym elementem monitorującym (monitor, reguła, alarm) powinna być skojarzona baza wiedzy, zawierająca informacje o potencjalnych przyczynach problemów oraz możliwościach jego rozwiązania (w tym możliwość uruchamiania zadań diagnostycznych),

9. System musi zbierać informacje udostępniane przez systemy operacyjne Windows o przyczynach krytycznych błędów (crash) udostępnianych potem
   do celów analitycznych,

10. System musi umożliwiać budowanie obiektów SLO (Service Level Object) służących przedstawianiu informacji dotyczących zdefiniowanych poziomów SLA (Service Level Agreement) przynajmniej dla: monitora (dostępność), i licznika wydajności (z agregacją dla wartości – min, max, avg),

5. Przechowywanie i dostęp do informacji:

1. Wszystkie informacje operacyjne (zdarzenia, liczniki wydajności, informacje
   o obiektach, alarmy) powinny być przechowywane w bazie danych operacyjnych,

2. System musi mieć co najmniej jedną bazę danych z przeznaczeniem
   na hurtownię danych do celów historycznych i raportowych. Zdarzenia powinny być umieszczane w obu bazach jednocześnie, aby raporty mogłyby być generowane w oparciu o najświeższe dane,

3. System musi mieć osobną bazę danych, do której będą zbierane informacje
   na temat zdarzeń security z możliwością ustawienia innych uprawnień dostępu
   do danych tam zawartych (tylko audytorzy),

4. System powinien mieć zintegrowany silnik raportujący niewymagający
   do tworzenia raportów używania produktów firm trzecich. Produkty takie mogą być wykorzystanie w celu rozszerzenia tej funkcjonalności,

5. System powinien mieć możliwość generowania raportów na życzenie oraz tworzenie zadań zaplanowanych,

6. System powinien umożliwiać eksport stworzonych raportów co najmniej
   do następujących formatów:

• XML

• CSV

• TIFF

• PDF

• XLS

• Web archive

6. Konsola systemu zarządzania:

1. Konsola systemu musi umożliwiać pełny zdalny dostęp do serwerów zarządzających dając dostęp do zasobów zgodnych z rolą użytkownika korzystającego z konsoli,

2. System powinien udostępniać dwa rodzaje konsoli:

• w postaci programu do zainstalowania na stacjach roboczych, obsługującą wszystkie funkcje systemu (konsola zdalna)

• w postaci web’owej dla dostępu do podstawowych komponentów monitorujących z dowolnej stacji roboczej (konsola webowa).

3. Konsola zdalna powinna umożliwiać definiowanie każdemu użytkownikowi własnych widoków, co najmniej w kategoriach:

• Alerts

• Events

• State

• Performance

• Diagram

• Task Status

• Web Page (dla użytkowników, którzy potrzebują podglądu tylko wybranych elementów systemu).

4. Konsola musi umożliwiać budowanie widoków tablicowych (dashboard) w celu prezentacji różnych widoków na tym samym ekranie,

5. Widoki powinny mieć możliwość filtrowania informacji, jakie się na nich znajdą
   (po typie, ważności, typach obiektów), sortowania oraz grupowania podobnych informacji, wraz z możliwością definiowania kolumn, jakie mają się znaleźć na widokach „kolumnowych”,

6. Z każdym widokiem (obiektem w tym widoku) powinno być skojarzone menu kontekstowe, z najczęstszymi operacjami dla danego typu widoku/obiektu,

7. Konsola musi zapewnić dostęp do wszystkich opcji konfiguracyjnych systemu (poza opcjami dostępnymi w procesie instalacji i wstępnej konfiguracji), w tym:

• opcji definiowania ról użytkowników

• opcji definiowania widoków

• opcji definiowania i generowania raportów

• opcji definiowania powiadomień

• opcji tworzenia, konfiguracji i modyfikacji zestawów monitorujących

• opcji instalacji/deinstalacji klienta

7. Wymagania dodatkowe

1. System musi dostarczać API lub inny system (web service, connector)
   z publicznie dostępną dokumentacją pozwalający x.xx. na:

• Budowanie konektorów do innych systemów, np. help-desk w celu przekazywania zdarzeń czy alarmów (dwukierunkowo),

• Wykonywanie operacji w systemie z poziomu linii poleceń,

• Podłączenie rozwiązań innych producentów pozwalających na monitorowanie w jednolity sposób systemów informatycznych niewspieranych natywnie przez system zarządzania,

• Podłączenie do aplikacji biurowych pozwalające na integrację statycznych modeli (np. diagramów Visio) z monitorowanymi obiektami, pozwalające
  na wyświetlanie ich stanu na diagramie

3. System zarządzania środowiskami wirtualnym

System zarządzania środowiskami wirtualnymi musi posiadać następujące cechy:

1. Architektura

1. System zarządzania środowiskiem wirtualnym powinien składać się z:

• serwera zarządzającego

• relacyjnej bazy danych przechowującej informacje o zarządzanych elementach

• konsoli, instalowanej na komputerach operatorów

• portalu self-service (konsoli webowej) dla operatorów „departamentowych”

• biblioteki, przechowującej komponenty niezbędne do budowy maszyn wirtualnych

• agenta instalowanego na zarządzanych hostach wirtualizacyjnych

• „konektora” do systemu monitorującego pracę hostów i maszyn wirtualnych

2. System musi mieć możliwość tworzenia konfiguracji wysokiej dostępności (klaster typu fail-over),

3. System musi pozwalać na zarządzanie platformami wirtualizacyjnymi co najmniej trzech różnych dostawców.

2. Interfejs użytkownika

1. Konsola musi umożliwiać wykonywanie codziennych zadań związanych
   z zarządzaniem maszynami wirtualnymi w sposób jak najbardziej intuicyjny,

2. Konsola musi umożliwiać grupowanie hostów i nadawanie uprawnień poszczególnym operatorom do grup hostów,

3. Widoki hostów i maszyn wirtualnych powinny mieć możliwość zakładania filtrów, pokazując tylko odfiltrowane elementy, np. maszyny wyłączone, maszyny
   z systemem operacyjnym X,

4. Widok szczegółowy elementu w przypadku maszyny wirtualnej musi pokazywać stan, ilość alokowanej pamięci i dysku twardego, system operacyjny, platformę wirtualizacyjną, stan ostatniego zadania, oraz wykres utylizacji procesora
   i podgląd na pulpit,

5. Konsola musi posiadać odrębny widok z historią wszystkich zadań oraz statusem zakończenia poszczególnych etapów i całych zadań.

3. Scenariusze i zadania

1. Tworzenie maszyn wirtualnych – system musi umożliwiać stworzenie maszyny wirtualnej w co najmniej dwóch trybach:

1. Ad hoc – gdzie wszystkie elementy są wybierane przez operatora podczas tworzenia maszyny,

2. Nadzorowany – gdzie operator tworzy maszynę korzystając z gotowego wzorca (template), a wzorzec składa się z przynajmniej 3-ech elementów składowych:

• profilu sprzętowego

• profilu systemu operacyjnego,

• przygotowanych dysków twardych,

2. Predefiniowane elementy muszą być przechowywane w bibliotece systemu zarządzania,

3. System musi umożliwiać przenoszenie maszyny wirtualnej pomiędzy zarządzanymi hostami:

• w trybie migracji „on-line” – bez przerywania pracy,

• w trybie migracji „off-line – z zapisem stanu maszyny

4. System musi umożliwiać automatyczne, równomierne rozłożenie obciążenia pomiędzy zarządzanymi hostami,

5. System musi umożliwiać wyłączenie hosta, gdy jego zasoby nie są konieczne
   do pracy, w celu oszczędności energii. System powinien również umożliwiać ponowne włączenie takiego hosta,

6. System musi umożliwiać przełączenie wybranego hosta w tryb „maintenance”
   w przypadku wystąpienia awarii lub w celu przeprowadzenia planowanych prac serwisowych. Uruchomienie tego trybu musi skutkować migracją maszyn na inne hosty lub zapisaniem ich stanu,

7. System musi posiadać możliwość konwersji maszyny fizycznej do wirtualnej,

8. System musi posiadać (bez potrzeby instalowania dodatkowego oprogramowania) - możliwość wykrycia maszyny fizycznej w sieci i instalacje
   na niej systemu operacyjnego wraz z platformą do wirtualizacji.

4. Wymagania dodatkowe

1. System musi informować operatora o potrzebie migracji maszyn, jeśli wystąpią nieprawidłowe zdarzenia na hoście lub w innych maszynach wirtualnych mające wpływ na ich pracę, np. awarie sprzętu, nadmierna utylizacja współdzielonych zasobów przez jedną maszynę,

2. System musi dawać operatorowi możliwość implementacji w/w migracji w sposób automatyczny bez potrzeby każdorazowego potwierdzania,

3. System musi kreować raporty z działania zarządzanego środowiska, w tym:

• utylizacja poszczególnych hostów,

• trend w utylizacji hostów,

• alokacja zasobów na centra kosztów,

• utylizacja poszczególnych maszyn wirtualnych,

• komputery-kandydaci do wirtualizacji

4. System musi umożliwiać skorzystanie z szablonów:

• wirtualnych maszyn

• usług

oraz profili dla:

• aplikacji

• serwera SQL

• hosta

• sprzętu

• systemu operacyjnego gościa

5. System musi umożliwiać tworzenie chmur prywatnych na podstawie dostępnych zasobów (hosty, sieci, przestrzeń dyskowa, biblioteki zasobów),

6. System musi posiadać możliwość przygotowania i instalacji zwirtualizowanej aplikacji serwerowej,

7. System musi pozwalać na skalowalność wirtualnego środowiska aplikacji (poprzez automatyczne dodanie wirtualnej maszyny z aplikacją).

4. System tworzenia kopii zapasowych

System tworzenia i odtwarzania kopii zapasowych danych (backup) wykorzystujący scenariusze tworzenia kopii na zasobach taśmowych lub dyskowych musi spełniać następujące wymagania:

1. System musi składać się z:

1. serwera zarządzającego kopiami zapasowymi i agentami kopii zapasowych,

2. agentów kopii zapasowych instalowanych na komputerach zdalnych,

3. konsoli zarządzającej,

4. relacyjnej bazy danych przechowującej informacje o zarządzanych elementach,

5. wbudowany mechanizm raportowania i notyfikacji poprzez pocztę elektroniczną,

6. System kopii zapasowych musi wykorzystywać mechanizm migawkowych kopii – VSS (Volume ShadowCopy Service).

2. System kopii zapasowych musi umożliwiać:

1. zapis danych na puli magazynowej złożonej z dysków twardych,

2. zapis danych na bibliotekach taśmowych.

3. System kopii zapasowych musi umożliwiać zdefiniowanie ochrony zasobów krótkookresowej i długookresowej.

4. Oznacza to, iż krótkookresowe kopie mogą być tworzone w puli magazynowej,
   a następnie po zdefiniowanym okresie, automatycznie przenoszone na biblioteki taśmowe.

5. System kopii zapasowych musi posiadać kopie danych produkcyjnych w swojej puli magazynowej.

6. Dane przechowywane w puli magazynowej muszą używać mechanizmów oszczędzających wykorzystane miejsce dyskowe, takie jak pojedyncza instancja przechowywania.

7. System kopii zapasowych powinien w przypadku wykonywania pełnej kopii zapasowej kopiować jedynie te bloki, które uległy zmianie od ostatniej pełnej kopii.

8. System kopii zapasowych powinien umożliwiać przywrócenie:

1. danych plikowych,

2. danych aplikacyjnych,

3. stanu systemu (Systemstate),

4. obrazu systemu operacyjnego (tzw. Bare Metal Restore).

9. System kopii zapasowej podczas wykonywania pełnej kopii zapasowej musi uaktualniać chronione dane o dodatkowy punkt przywracania danych, minimalizując ilość przesyłanych danych.

10. System kopii zapasowych musi umożliwiać rozwiązanie automatycznego przenoszenia chronionych danych do zdalnej lokalizacji, wykorzystując przy tym mechanizm regulacji maksymalnej przepustowości.

11. Agenci systemu kopii zapasowych muszą posiadać konfiguracje dotyczącą zdefiniowania godzin pracy, a także dostępnej przepustowości w czasie godzin pracy i poza godzinami pracy.

12. System kopii zapasowych musi rozpoznawać co najmniej aplikacje posiadane przez Zamawiającego:

1. ze względu na tworzone logi transakcyjne:

• Microsoft Exchange Server

• Microsoft Office Sharepoint Server

• Microsoft SQL Server

2. ze względu na zapewnienie nieprzerwalności pracy

• Microsoft Hyper-V server

13. Komunikacja z serwerem kopii zapasowych musi odbywać się po jawnie zdefiniowanych portach.

14. Konsola powinna umożliwiać wykonywanie tworzenie określonych harmonogramów wykonywania kopii zapasowych na chronionych agentach.

15. Konsola powinna umożliwiać grupowanie chronionych zasobów ze względu na typy chronionych zasobów.

16. Zarządzanie agentami i zadaniami kopii zapasowych powinno być możliwe również za pomocą linii poleceń.

17. System kopii zapasowych musi umożliwiać odzyskanie chronionych zasobów plikowych przez użytkownika końcowego z poziomu zakładki „Poprzednie wersje”.

18. Konsola powinna posiadać mechanizm kontrolowania wykonywanych zadań kopii zapasowych.

19. Konsola powinna posiadać mechanizm notyfikacji administratorów odnośnie zdarzeń w systemie kopii zapasowych.

20. Konsola powinna posiadać wbudowany system raportujący (x.xx. raporty dotyczące zużycia puli magazynowej, wykonania kopii zapasowych).

21. System kopii zapasowych musi umożliwiać przechowywanie danych w puli magazynowej do 1 roku.

22. System kopii zapasowych musi umożliwiać przechowywanie danych na podłączonych bibliotekach taśmowych powyżej 25 lat.

23. System kopii zapasowych musi umożliwiać synchronizacje przechowywanych kopii zapasowych (kopie inkrementalne) z produkcyjnymi transakcyjnymi bazami danych (bazy danych, poczta elektroniczna, portale intranetowe) na poziomie poniżej
    30 minut. Kopie te muszą być tworzone w ciągu godzin pracy, w niezauważalny
    dla użytkowników końcowych sposób.

24. System kopii zapasowych musi umożliwiać odtworzenie dowolnego 30 minutowego kwantu czasu dla krytycznych aplikacji, takich jak bazy transakcyjne, poczta elektroniczna, portale intranetowe.

25. System kopii zapasowych musi umożliwiać odtworzenie danych do:

1. lokalizacji oryginalnej

2. lokalizacji alternatywnej

3. w przypadku drugiego serwera kopii zapasowych (w centrum zapasowym)
   do pierwszego serwera kopii zapasowych

5. System automatyzacji zarządzania środowisk IT

System automatyzacji zarządzania środowisk IT musi udostępniać bezskryptowe środowisko standaryzujące i automatyzujące zarządzanie środowiskiem IT na bazie najlepszych praktyk.

1. System musi umożliwiać testowanie sytuacji krytycznych i występowanie różnych incydentów w systemie.

2. System musi wspomagać automatyzację procesów zarządzania zmianami konfiguracji środowisk IT.

3. System musi wspomagać planowanie i automatyzację wdrażania poprawek.

4. System musi umożliwiać zarządzanie życiem środowisk wirtualnych.

5. System musi udostępniać mechanizmy workflow automatyzujące zadania administracyjne wraz z graficznym interfejsem projektowania, budowy i monitorowania worklow.

6. Wbudowane konektory zapewniające integrację narzędzi, posiadanych przez Zamawiającego, Microsoft System Center, HP OpenView i IBM Tivoli do zarządzania oprogramowaniem i sprzętem.

7. Wbudowane (gotowe) workflow:

• Active Directory Password Reset

• Microsoft Cluster Patching

• Microsoft SQL Server Cluster Patching

• Microsoft SQL: Server Dump Copy Load

• Operations Manager Event Remediation

• Operations Manager Event Remediation and Enrichment

• Operations Manager Service Alert Testing

• VM Provisioning

• Working with FTP

• Operations Manager Tool Integration

• Operations Manager: Manager of Managers

• Operations Manager: Maintenance Windows

• Active Directory: New Employee Onboarding

• Operations Manager: Multi-Service Desk Integration

6. System zarządzania incydentami i problemami

System zarządzania incydentami i problemami musi spełniać następujące wymagania:

1. System powinien posiadać rozwiązanie help-deskowe umożliwiające użytkownikom zgłaszanie problemów technicznych oraz zapotrzebowanie na zasoby IT (np. nowa maszyna wirtualna).

2. System musi mieć postać zintegrowanej platformy pozwalającej poprzez wbudowane i definiowane mechanizmy w ramach przyjętej metodyki (np. MOF czy ITIL)
   na zarządzanie incydentami i problemami oraz zarządzanie zmianą.

3. System powinien posiadać bazę wiedzy (CMDB) automatycznie zasilaną z takich systemów jak: usługa katalogowa, system monitorujący, system do zarządzania desktopami.

4. System musi udostępniać narzędzia efektywnego zarządzania dostępnością usług, umożliwiających dostarczenie użytkownikom systemów SLA na wymaganym poziomie.

5. System, poprzez integrację z systemami zarządzania i monitorowania musi zapewniać:

• Optymalizację procesów i ich prawidłową realizację poprzez predefiniowane scenariusze, zgodne z najlepszymi praktykami i założoną metodyką

• Redukcję czasu rozwiązywania problemów z działaniem systemów poprzez zapewnienie dotarcia właściwej, zagregowanej informacji do odpowiedniego poziomu linii wsparcia

• Automatyczne generowanie opisu problemów na bazie alarmów i kojarzenie zdarzeń w różnych komponentach systemu

• Wspomaganie procesów podejmowania decyzji poprzez integrację informacji
  i logikę ich powiązania

• Planowanie działań prewencyjnych poprzez kolekcjonowanie informacji
  o zachowaniach systemu w przypadku incydentów

• Raportowanie pozwalające na analizy w zakresie usprawnień systemu oraz usprawnień procesów ich opieki serwisowej

• Tworzenie baz wiedzy na temat rozwiązywania problemów

• Automatyzację działań w przypadku znanych i opisanych problemów

• Wykrywanie odchyleń od założonych standardów ustalonych dla systemu

7. Ochrona antymalware

Oprogramowanie antymalware musi spełniać następujące wymagania:

1. Ochrona przed zagrożeniami typu wirusy, robaki, Trojany, rootkity, ataki typu phishing czy exploity zero-day.

2. Centralne zarządzanie ochroną serwerów poprzez konsolę System zarządzania infrastrukturą i oprogramowaniem

3. Centralne zarządzanie politykami ochrony.

4. Automatyzacja wdrożenia i wymiany dotychczasowych agentów ochrony.

5. Mechanizmy wspomagające masową instalację.

6. Pakiet ma wykorzystywać platformę skanowania, dzięki której dostawcy zabezpieczeń stosować mogą technologię „minifiltrów”, skanujących w czasie rzeczywistym w poszukiwaniu złośliwego oprogramowania. Dzięki użyciu technologii minifiltrów, system ma wykrywać wirusy, oprogramowanie szpiegowskie i inne pliki przed ich uruchomieniem, dając dzięki temu wydajną ochronę przed wieloma zagrożeniami, a jednocześnie minimalizując zaangażowanie użytkownika końcowego.

7. Aparat ochrony przed złośliwym oprogramowaniem ma używać zaawansowanych technologii wykrywania, takich jak analiza statyczna, emulacja, heurystyka
   i tunelowanie w celu identyfikacji złośliwego oprogramowania i ochrony systemu. Ponieważ zagrożenia stają się coraz bardziej złożone, ważne jest, aby zapewnić
   nie tylko oczyszczenie systemu, ale również poprawne jego funkcjonowanie
   po usunięciu złośliwego oprogramowania. Aparat ochrony przed złośliwym oprogramowaniem w systemie ma zawierać zaawansowane technologie oczyszczania, pomagające przywrócić poprawny stan systemu po usunięciu złośliwego oprogramowania.

8. Generowanie alertów dla ważnych zdarzeń, takich jak atak złośliwego oprogramowania czy niepowodzenie próby usunięcia zagrożenia.

9. Tworzenie szczegółowych raportów zabezpieczeń systemów IT o określonych priorytetach, dzięki którym użytkownik może wykrywać i kontrolować zagrożenia
   lub słabe punkty zabezpieczeń. Raporty mają obejmować nie tylko takie informacje, jak ilość ataków wirusów, ale wszystkie aspekty infrastruktury IT, które mogą wpłynąć na bezpieczeństwo firmy (np. ilość komputerów z wygasającymi hasłami, ilość maszyn, na których jest zainstalowane konto „gościa”, itd.).

10. Pakiet ma umożliwiać zdefiniowanie jednej zasady konfigurującej technologie antyszpiegowskie, antywirusowe i technologie monitorowania stanu jednego lub wielu chronionych komputerów. Zasady obejmują również ustawienia poziomów alertów, które można konfigurować, aby określić rodzaje alertów i zdarzeń generowanych przez różne grupy chronionych komputerów oraz warunki ich zgłaszania.

11. System ochrony musi być zoptymalizowany pod kątem konfiguracji ustawień agenta zabezpieczeń przy użyciu Zasad Grupy usługi katalogowej oraz dystrybucji aktualizacji definicji.

12. Możliwość natywnego współdziałania z systemami typu „rights-management”

13. Możliwość filtrowania i blokowania zabronionych przez polityki treści czy słów kluczowych.

Pakiet produktów narzędziowych do zarządzania i monitorowania serwerów oraz zarządzania wirtualizacją serwerów dedykowany dla środowisk o niskim stopniu wirtualizacji

Licencja na oprogramowanie musi być przypisana do każdego procesora fizycznego na serwerze zarządzanym. Liczba rdzeni procesorów i ilość pamięci nie mogą mieć wpływu na liczbę wymaganych licencji. Licencja musi uprawniać do zarządzania i monitorowania dwoma wirtualnymi środowiskami serwerowego systemu operacyjnego. za pomocą wbudowanych mechanizmów wirtualizacji.

Pakiet narzędziowy musi obejmować wszystkie funkcje zawarte w opisie dla pakietu narzędziowego przeznaczonego dla środowisk o wysokim stopniu wirtualizacji.

System bazodanowy dla środowiska testowo-rozwojowego

Licencje uprawniające do wykorzystania Systemu bazodanowego o funkcjonalności Systemu bazodanowego typ 1 wyłącznie do celów testowo-rozwojowych dla 100 użytkowników.

System bazodanowy typ 1 zapewniający dostęp do systemu nieograniczonej liczbie użytkowników.

W Centrum Przetwarzania Danych Zamawiający posiada zainstalowane systemy bazodanowe MS SQL 2008 Enterprise oraz MS SQL 2012 zakupione w ramach projektu SISP. Dopuszcza się zaoferowanie produktów równoważnych do produktów wykorzystywanych przez Zamawiającego.

Równoważny system bazodanowy (SBD) typ 1 musi spełniać poniższe wymagania:

1. Możliwość wykorzystania SBD jako silnika relacyjnej bazy danych, analitycznej, wielowymiarowej bazy danych, platformy bazodanowej dla wielu aplikacji. Powinien zawierać serwer raportów, narzędzia do definiowania raportów, wykonywania analiz biznesowych oraz tworzenia procesów ETL.

2. Zarządzanie, konfigurowanie i monitorowanie wszystkich usług/modułów środowiska bazy danych powinno być zrealizowane w oparciu o dostarczone narzędzia graficzne. Narzędzia te muszą udostępniać możliwość automatyzacji wykonywania zadań związanych z zarządzaniem, konfigurowaniem i monitorowaniem wszystkich usług/modułów środowiska bazy danych.

3. SBD musi udostępniać graficzne narzędzia do diagnozowania wydajności bazy danych. SBD musi również udostępniać graficzne narzędzia do strojenia wydajności bazy danych z funkcją śledzenia wykonywanych zapytań SQL.

4. SBD musi udostępniać mechanizm zarządzania systemem za pomocą uruchamianych z linii poleceń skryptów administracyjnych, które pozwolą zautomatyzować rutynowe czynności związane z zarządzaniem serwerem.

5. SBD musi pozwalać na zdalne połączenie sesji administratora systemu bazy danych w sposób niezależny od normalnych sesji klientów.

6. SBD musi umożliwiać wykonywanie typowych zadań administracyjnych (indeksowanie, backup,) bez konieczności przerywania pracy systemu lub przechodzenia w tryb jednoużytkownikowy .

7. SBD powinien umożliwiać tworzenie w dowolnym momencie kopii bazy danych tylko do odczytu zawierającej stan bazy z bieżącego momentu czasu. Wiele takich kopii może być równolegle użytkowanych w celu wykonywania z nich zapytań.

8. SBD musi umożliwiać tworzenie klastrów niezawodnościowych. Powinien również umożliwiać tworzenie klastrów niezawodnościowych, których węzły znajdują się w różnych podsieciach komputerowych.

9. SBD powinien pozwalać na transakcyjną replikację wybranych danych z bazy danych między wieloma węzłami. Dodanie lub usunięcie węzła nie powinno wpływać na funkcjonowanie i spójność systemu replikacji, ani nie powinno przerywać procesu replikacji. Dane mogą w takim schemacie replikacji być modyfikowane w dowolnym węźle (ale tylko w jednym węźle w danym momencie). System powinien zawierać narzędzie do nadzorowania i wizualizacji topologii oraz stanu procesu replikacji. Dodatkowo SBD powinien umożliwiać kompresję przesyłanych danych między serwerami uczestniczącymi w replikacji, aby minimalizować obciążenie łączy sieciowych.

10. SBD musi pozwalać na kompresję kopii zapasowej danych (backup) w trakcie jej tworzenia. Powinna to być cecha SBD niezależna od funkcji systemu operacyjnego ani od sprzętowego rozwiązania archiwizacji danych.

11. SBD musi pozwalać na szyfrowanie przechowywanych danych. Szyfrowanie musi być cechą SBD i nie może wymagać jakichkolwiek zmian w aplikacjach korzystających z danych. Zaszyfrowanie lub odszyfrowanie danych nie powinno powodować przerwy w dostępie do danych. Kopia bezpieczeństwa szyfrowanej bazy także powinna być automatycznie zaszyfrowana.

12. SBD musi posiadać możliwość rejestracji zdarzeń na poziomie silnika bazy danych w czasie rzeczywistym w celach diagnostycznych, pozwalać na selektywne wybieranie rejestrowanych zdarzeń.

13. SBD musi umożliwiać tworzenie procedur składowanych, które mogą być udostępnione i wywoływane jako WebServices,

14. SBD musi umożliwiać definiowanie nowych typów danych wraz z definicją specyficznej dla tych typów danych logiki operacji. Jeśli np. zdefiniujemy typ do przechowywania danych hierarchicznych, to obiekty tego typu powinny udostępnić operacje dostępu do “potomków” obiektu, “rodzica” itp. Logika operacji nowego typu danych powinna być implementowana w zaproponowanym przez Dostawcę języku programowania. Nowe typy danych nie mogą być ograniczone wyłącznie do okrojenia typów wbudowanych lub ich kombinacji.

15. SBD musi udostępniać mechanizmy składowania i obróbki danych w postaci struktur XML. (wsparcie dla technologii XML) W szczególności musi:

• udostępniać typ danych do przechowywania kompletnych dokumentów XML w jednym polu tabeli,

• udostępniać mechanizm walidacji struktur XML-owych względem jednego lub wielu szablonów XSD,

• udostępniać język zapytań do struktur XML,

• udostępniać język modyfikacji danych (DML) w strukturach XML (dodawanie, usuwanie i modyfikację zawartości struktur XML),

• udostępniać możliwość indeksowania struktur XML-owych w celu optymalizacji wykonywania zapytań.

16. SBD musi zapewniać wsparcie dla danych przestrzennych (geometrycznych i geograficznych typów danych) pozwalających w prosty sposób przechowywać i analizować informacje o lokalizacji obiektów, dróg i innych punktów orientacyjnych zlokalizowanych na kuli ziemskiej, a w szczególności:

• zapewniać możliwość wykorzystywania szerokości i długości geograficznej do opisu lokalizacji obiektów,

• obsługa geometrycznych i geograficznych typów danych powinna być dostępna z poziomu języka zapytań do systemu SBD,

17. SBD powinien umożliwiać przechowywanie i efektywne zarządzanie dużymi obiektami binarnymi (pliki graficzne, multimedialne, dokumenty). Obiekty te nie powinny być przechowywane w plikach bazy danych, ale w systemie plików . Jednocześnie pliki te powinny być zarządzane przez SBD (kontrola dostępu na podstawie uprawnień nadanych w SBD).

18. SBD powinien udostępniać wbudowany mechanizm kompresji zgromadzonych danych w celu osiągnięcia lepszej wydajności przy niezmienionej konfiguracji sprzętowej. SBD powinien umożliwiać kompresję danych i indeksów.

19. SBD powinien pozwalać na rejestrację zmian w danych włącznie z zapamiętaniem stanu pojedynczego rekordu danych sprzed modyfikacji. Rozwiązanie powinno być konfigurowalne bez wpływu na istniejące aplikacje korzystające z danych. Rozwiązanie powinno rejestrować także zmiany w definicji struktur danych.

20. SBD powinien pozwalać na rejestrację operacji takich jak: logowanie, wylogowanie użytkownika, zmiany w definicji obiektów bazy danych (tabele, procedury), wykonywanie przez wskazanego użytkownika operacji takich jak SELECT, INSERT, UPDATE, DELETE. Rozwiązanie powinno być niezależne od aplikacji, wbudowane w SBD.

21. SBD powinien umożliwiać partycjonowanie danych poprzez podział danych w jednej tabeli między różne fizyczne pamięci masowe zgodnie ze zdefiniowanymi warunkami podziału. Powinien udostępniać mechanizm równoległego (wielowątkowego) dostępu do danych umieszczonych w różnych partycjach.

22. SBD powinien umożliwiać tworzenie indeksów na podzbiorze danych z tabeli określonym poprzez wyrażenie filtrujące.

23. SBD musi umożliwiać tworzenie procedur i funkcji z wykorzystaniem innych języków programowania (np. Java, C#), niż standardowo obsługiwany język zapytań danego SBD. System powinien umożliwiać tworzenie w tych językach x.xx. agregujących funkcji użytkownika oraz wyzwalaczy. Dodatkowo powinien udostępniać środowisko do debuggowania.

24. Język zapytań i procedur w SBD musi umożliwiać zastosowanie mechanizmu przechwytywania i obsługi błędów wykonania procedury (na zasadzie bloku instrukcji TRY/CATCH) – tak jak w klasycznych językach programowania.

25. SBD musi udostępniać mechanizm pozwalający na zamrożenie planu wykonania zapytania przez silnik bazy danych (w wyniku takiej operacji zapytanie jest zawsze wykonywane przez silnik bazy danych w ten sam sposób).

26. SBD musi posiadać narzędzie do graficznego projektowania transformacji danych. Narzędzie to powinno pozwalać na przygotowanie definicji transformacji w postaci pliku, które potem mogą być wykonywane automatycznie lub z asystą operatora. Transformacje powinny posiadać możliwość graficznego definiowania zarówno przepływu sterowania (program i warunki logiczne) jak i przepływu strumienia rekordów poddawanych transformacjom. Zestaw standardowych dostępnych transformacji powinien obejmować takie transformacje jak: sortowanie, wyszukiwanie wartości według klucza w tabelach słownikowych, automatyczna obsługa SCD (Slowly Changing Dimension) w zasilaniu hurtowni danych. Powinna być także zapewniona możliwość tworzenia własnych transformacji.

27. SBD musi posiadać moduł pozwalający na tworzenie rozwiązań służących do analizy danych wielowymiarowych (hurtownia danych). System powinien umożliwiać pracę w dwóch trybach: wielowymiarowym (tworzenie kostek wielowymiarowych), tabelarycznym (wykorzystującym technologię in-memory BI). Powinno być możliwe tworzenie: wymiarów, miar. Wymiary powinny mieć możliwość określania dodatkowych atrybutów będących dodatkowymi poziomami agregacji. Powinna być możliwość definiowania hierarchii w obrębie wymiaru.

28. Moduł analityczny musi mieć możliwość wyliczania agregacji wartości miar dla zmieniających się elementów (członków) wymiarów i ich atrybutów. Agregacje powinny być składowane w jednym z wybranych modeli (MOLAP, ROLAP). Pojedyncza baza analityczna musi mieć możliwość mieszania modeli składowania .

29. SBD powinien posiadać narzędzia do zarządzania jakością danych w organizacji. W ramach tych funkcji powinien:

    • udostępniać funkcje do profilowania danych (analiza i raporty dot. jakości danych),

    • udostępniać funkcje do deduplikacji danych,

    • określać stopień poprawności wartości atrybutu i w przypadku błędnej wartości sugerować wartość poprawną do akceptacji przez użytkownika,

    • umożliwiać definiowanie osobnych reguł czyszczenia dla wybranych domen (typów atrybutów),

    • umożliwiać definiowanie złożonych domen (zestawu kilku atrybutów) oraz ocenę jakości danych na podstawie powiązań między tymi atrybutami (np. weryfikację poprawności danych adresowych złożonych z kodu pocztowego, miasta i ulicy),

    • pozwalać na ręczną korektę nieprawidłowych danych w dedykowanej aplikacji (bez konieczności programowania),

    • umożliwiać eksport wyników badania (poprawnych i sugerowanych wartości) do pliku tekstowego lub bazy relacyjnej, eksport powinien obejmować wartości po korekcie oraz ewentualnie te przed korektą,

    • przechowywać reguły walidujące i oceniające jakość danych w dedykowanej bazie danych (bazie wiedzy),

    • umożliwiać uzupełnianie i rozszerzanie bazy wiedzy o dane referencyjne pochodzące z systemów zewnętrznych,

    • zapewniać mechanizmy “uczenia się” bazy wiedzy – czyli w miarę realizacji kolejnych procesów ręcznego czyszczenia danych baza wiedzy powinna umożliwiać gromadzenie tych informacji na potrzeby kolejnych procesów,

    • umożliwiać wykorzystanie bazy wiedzy w automatycznym procesie czyszczenia danych (powinien integrować się z narzędziami do ekstrakcji, transformacji i ładowania danych, dzięki czemu będzie można wykorzystać te mechanizmy w automatycznym procesie ładowania danych).

30. Możliwość zarządzania centralnymi słownikami danych - SBD powinien dostarczać narzędzia do przechowywania i zarządzania centralnym słownikiem danych (Master Data Management - MDM). System MDM powinien:

    • udostępniać narzędzia do wprowadzania, modyfikacji i wyszukiwania danych w słownikach,

    • umożliwiać wersjonowanie danych (śledzenie zmian wprowadzonych przez użytkowników z możliwością ich cofnięcia do wybranej wersji),

    • udostępniać mechanizm tworzenia i uruchamiania reguł walidujących poprawność danych w słownikach,

    • udostępniać narzędzia do administracji i kontroli uprawnień dostępu do danych w MDM,

    • udostępniać zestaw bibliotek (API programistyczne) z funkcjonalnościami MDM do wykorzystania w aplikacjach użytkownika,

    • umożliwiać eksport danych zgromadzonych w systemie MDM,

    • umożliwiać zarządzanie danymi podstawowymi z poziomu programu Microsoft Excel.

31. Moduł analityczny powinien umożliwiać rejestrowanie zapytań wykonywanych przez użytkowników do baz analitycznych, a następnie umożliwiać na podstawie zgromadzonych informacji automatyczną optymalizację wydajności systemu (np. automatyczne projektowanie agregacji pozwalające na przyspieszenie wykonywania najczęściej wykonywanych zapytań do bazy danych).

32. Moduł analityczny powinien umożliwiać tworzenie perspektyw na bazie wielowymiarowej pozwalających ograniczyć widok dla użytkownika tylko do pewnego podzbioru obiektów dostępnych w całej bazie danych.

33. Moduł analityczny powinien umożliwiać użytkownikom tworzenie analiz In-Memory, czyli przetwarzanie dużej liczby rekordów skompresowanych w pamięci RAM. Powinien umożliwiać tworzenie modeli wykorzystujących tabele pochodzące z wielu niezależnych źródeł danych i łączone między sobą relacjami.

34. Moduł analityczny powinien udostępniać dedykowany język do tworzenia logiki biznesowej w modelu. Język ten powinien x.xx. obsługiwać relacje utworzone między tabelami, mechanizmy operacji na datach i okresach, oraz zapewniać mechanizmy kontroli bezpieczeństwa i dostępu do danych na poziomie poszczególnych wierszy.

35. SBD powinien udostępniać mechanizmy optymalizacji zapytań w modelu gwiazdy (tabela faktów łączona z tabelami wymiarów).

36. SBD powinien udostępniać wbudowane mechanizmy pozwalające w łatwy i szybki sposób aktualizować zawartość tabel faktów (wykorzystywanych w modelach wielowymiarowych). Mechanizm ten powinien być dostępny z poziomu zapytań języka SQL obsługiwanego przez silnik bazy danych.

37. Moduł analityczny musi udostępniać rozwiązania Data Mining, x.xx.: algorytmy reguł związków , szeregów czasowych , drzew regresji , sieci neuronowych . Dodatkowo system powinien umożliwiać tworzenie własnych algorytmów, udostępniać narzędzia do wizualizacji danych z modelu Data Mining oraz język zapytań do odpytywania tych modeli.

38. SBD musi udostępniać użytkownikom możliwość tworzenia wskaźników KPI (Key Performance Indicators) na podstawie danych zgromadzonych w strukturach wielowymiarowych. W szczególności powinien pozwalać na zdefiniowanie takich elementów, jak: wartość aktualna, cel, trend, symbol graficzny wskaźnika w zależności od stosunku wartości aktualnej do celu. System powinien umożliwiać tworzenie takich wskaźników również w modelach danych wykorzystujących technologię in-memory BI.

39. Moduł raportowania SBD musi posiadać możliwość definiowania i generowania raportów. Narzędzie do tworzenia raportów powinno pozwalać na ich graficzną definicję. Raporty powinny być udostępnianie przez serwer raportów protokołem HTTP (dostęp klienta za pomocą przeglądarki),. Dodatkowo system raportowania powinien obsługiwać:

• raporty parametryzowane,

• cache raportów i raportów parametryzowanych,

• współdzielenie predefiniowanych zapytań do źródeł danych,

• wizualizację danych analitycznych na mapach geograficznych (w tym import map w formacie ESRI Shape File),

• możliwość opublikowania elementu raportu (wykresu, tabeli) we współdzielonej bibliotece, z której mogą korzystać inni użytkownicy tworzący nowy raport ,

• możliwość wizualizacji wskaźników KPI,

• możliwość wizualizacji danych w postaci obiektów sparkline.

40. Wymagane jest generowanie raportów w formatach: XML, PDF, Microsoft Excel (od wersji 1997 do 2010), Microsoft Word (od wersji 1997 do 2010), HTML, TIFF. Dodatkowo raporty powinny być eksportowane w formacie Atom data feeds, które można będzie wykorzystać jako źródło danych w innych aplikacjach.

41. SBD musi umożliwiać rozbudowę mechanizmów raportowania x.xx. o dodatkowe formaty eksportu danych, obsługę nowych źródeł danych dla raportów, funkcje i algorytmy wykorzystywane podczas generowania raportu (np. nowe funkcje agregujące).

42. SBD musi umożliwiać wysyłkę raportów drogą mailową w formacie wybranym spośród udostępnianych formatów (subskrypcja) do dynamicznej listy odbiorców (pobieranej z bazy danych np. zapytaniem SQL).

43. SBD powinien udostępniać narzędzia do tworzenia raportów ad-hoc przez niezaawansowanych użytkowników. Tworzenie raportów powinno odbywać się w środowisku graficznym. Użytkownicy powinni mieć możliwość na publikowanie stworzonych raportów na serwerze w celu udostępnienia ich szerszemu gronu osób.

System bazodanowy typ 2 zapewniający dostęp do systemu nieograniczonej liczbie użytkowników.

W Centrum Przetwarzania Danych Zamawiający posiada zainstalowane systemy bazodanowe MS SQL 2008 Standard oraz MS SQL 2012 Standard zakupione w ramach projektu SISP. Dopuszcza się zaoferowanie produktów równoważnych do produktów wykorzystywanych przez Zamawiającego.

Równoważny system bazodanowy (SBD) typ 2 musi spełniać następujące wymagania:

1. Możliwość wykorzystania SBD jako silnika relacyjnej bazy danych, platformy bazodanowej dla wielu aplikacji. Powinien zawierać serwer raportów, narzędzia do definiowania raportów oraz tworzenia procesów ETL.

2. Zarządzanie, konfigurowanie i monitorowanie wszystkich usług/modułów środowiska bazy danych powinno być zrealizowane w oparciu o dostarczone narzędzia graficzne. Narzędzia te muszą udostępniać możliwość automatyzacji wykonywania zadań związanych z zarządzaniem, konfigurowaniem i monitorowaniem wszystkich usług/modułów środowiska bazy danych.

3. SBD musi udostępniać graficzne narzędzia do diagnozowania wydajności bazy danych. SBD musi również udostępniać graficzne narzędzia do strojenia wydajności bazy danych z funkcją śledzenia wykonywanych zapytań SQL.

4. SBD musi udostępniać mechanizm zarządzania systemem za pomocą uruchamianych z linii poleceń skryptów administracyjnych, które pozwolą zautomatyzować rutynowe czynności związane z zarządzaniem serwerem.

5. SBD musi pozwalać na zdalne połączenie sesji administratora systemu bazy danych w sposób niezależny od normalnych sesji klientów.

6. SBD musi umożliwiać tworzenie klastrów niezawodnościowych.

7. SBD musi pozwalać na kompresję kopii zapasowej danych (backup) w trakcie jej tworzenia. Powinna to być cecha SBD niezależna od funkcji systemu operacyjnego ani od sprzętowego rozwiązania archiwizacji danych.

8. SBD musi posiadać możliwość rejestracji zdarzeń na poziomie silnika bazy danych w czasie rzeczywistym w celach diagnostycznych, pozwalać na selektywne wybieranie rejestrowanych zdarzeń.

9. SBD musi umożliwiać tworzenie procedur składowanych, które mogą być udostępnione i wywoływane jako WebServices.

10. SBD musi umożliwiać definiowanie nowych typów danych wraz z definicją specyficznej dla tych typów danych logiki operacji. Jeśli np. zdefiniujemy typ do przechowywania danych hierarchicznych, to obiekty tego typu powinny udostępnić operacje dostępu do “potomków” obiektu, “rodzica” itp. Logika operacji nowego typu danych powinna być implementowana w zaproponowanym przez Dostawcę języku programowania. Nowe typy danych nie mogą być ograniczone wyłącznie do okrojenia typów wbudowanych lub ich kombinacji.

11. SBD musi udostępniać mechanizmy składowania i obróbki danych w postaci struktur XML (wsparcie dla technologii XML). W szczególności musi:

• udostępniać typ danych do przechowywania kompletnych dokumentów XML w jednym polu tabeli,

• udostępniać mechanizm walidacji struktur XML-owych względem jednego lub wielu szablonów XSD,

• udostępniać język zapytań do struktur XML,

• udostępniać język modyfikacji danych (DML) w strukturach XML (dodawanie, usuwanie i modyfikację zawartości struktur XML),

• udostępniać możliwość indeksowania struktur XML-owych w celu optymalizacji wykonywania zapytań.

12. SBD musi zapewniać wsparcie dla danych przestrzennych (geometrycznych i geograficznych typów danych) pozwalających w prosty sposób przechowywać i analizować informacje o lokalizacji obiektów, dróg i innych punktów orientacyjnych zlokalizowanych na kuli ziemskiej, a w szczególności:

• zapewniać możliwość wykorzystywania szerokości i długości geograficznej do opisu lokalizacji obiektów,

• obsługa geometrycznych i geograficznych typów danych powinna być dostępna z poziomu języka zapytań do systemu SBD,

13. SBD musi umożliwiać tworzenie procedur i funkcji z wykorzystaniem innych języków programowania (np. Java, C#), niż standardowo obsługiwany język zapytań danego SBD. System powinien umożliwiać tworzenie w tych językach x.xx. agregujących funkcji użytkownika oraz wyzwalaczy. Dodatkowo powinien udostępniać środowisko do debuggowania.

14. Język zapytań i procedur w SBD musi umożliwiać zastosowanie mechanizmu przechwytywania i obsługi błędów wykonania procedury (na zasadzie bloku instrukcji TRY/CATCH) – tak jak w klasycznych językach programowania.

15. SBD musi udostępniać mechanizm pozwalający na zamrożenie planu wykonania zapytania przez silnik bazy danych (w wyniku takiej operacji zapytanie jest zawsze wykonywane przez silnik bazy danych w ten sam sposób).

16. SBD musi posiadać narzędzie do graficznego projektowania transformacji danych. Narzędzie to powinno pozwalać na przygotowanie definicji transformacji w postaci pliku, które potem mogą być wykonywane automatycznie lub z asystą operatora. Transformacje powinny posiadać możliwość graficznego definiowania zarówno przepływu sterowania (program i warunki logiczne) jak i przepływu strumienia rekordów poddawanych transformacjom. Powinna być także zapewniona możliwość tworzenia własnych transformacji..

17. Moduł raportowania SBD musi posiadać możliwość definiowania i generowania raportów. Narzędzie do tworzenia raportów powinno pozwalać na ich graficzną definicję. Raporty powinny być udostępnianie przez serwer raportów protokołem HTTP (dostęp klienta za pomocą przeglądarki),. Dodatkowo system raportowania powinien obsługiwać:

• raporty parametryzowane,

• cache raportów i raportów parametryzowanych,

• współdzielenie predefiniowanych zapytań do źródeł danych,

• możliwość opublikowania elementu raportu (wykresu, tabeli) we współdzielonej bibliotece, z której mogą korzystać inni użytkownicy tworzący nowy raport ,

18. Wymagane jest generowanie raportów w formatach: XML, PDF, Microsoft Excel (od wersji 1997 do 2010), Microsoft Word (od wersji 1997 do 2010), HTML, TIFF. Dodatkowo raporty powinny być eksportowane w formacie Atom data feeds, które można będzie wykorzystać jako źródło danych w innych aplikacjach.

19. SBD musi umożliwiać rozbudowę mechanizmów raportowania x.xx. o dodatkowe formaty eksportu danych, obsługę nowych źródeł danych dla raportów, funkcje i algorytmy wykorzystywane podczas generowania raportu (np. nowe funkcje agregujące).

20. SBD musi umożliwiać wysyłkę raportów drogą mailową w formacie wybranym spośród udostępnianych formatów (subskrypcja).

Zadanie 4. Dostawa oprogramowania narzędziowego do wirtualizacji i budowa środowiska zwirtualizowanego

W ramach zadania Wykonawca dostarczy licencje oprogramowania narzędziowego do wirtualizacji i wdroży to oprogramowanie na serwerach wskazanych przez Xxxxxxxxxxxxx.

Licencje powinny umożliwiać uruchomianie wirtualizacji na serwerach fizycznych o łącznej liczbie 16 procesorów fizycznych oraz uruchomienie jednej centralnej konsoli do zarządzania całym środowiskiem wirtualnym.

Zamawiający posiada w Podstawowym Centrum Przetwarzania Danych w budynku GUS trzy współpracujące ze sobą środowiska wirtualizacyjne VMware tworzące prywatną chmurę obliczeniową, zawierające łącznie ponad 150 serwerów wirtualnych.

Podstawową wersją oprogramowania jest VMWare vSphere 5.1. Licencje tego systemu zostały zakupione w wyniku rozstrzygnięcia postępowań o zamówienie publiczne w trybie przetargów nieograniczonych między innymi w przetargu nr COIS-2/2010/SISP. Środowisko zwirtualizowane zostało, w ramach realizacji przetargu nr 14/SISP/PN/2013, zaktualizowane zgodnie z posiadanymi uprawnieniami licencyjnymi na zakupione oprogramowanie.

Zamawiający przewiduje, że Zapasowe Centrum Przetwarzania Danych w Radomiu będzie stanowić centrum zapasowe dla wybranych serwerów wirtualnych z Podstawowego Centrum Przetwarzania Danych w budynku GUS. Zamawiający przewiduje również rozszerzenie prywatnej chmury obliczeniowej na zasoby znajdujące się w Zapasowym Centrum Przetwarzania Danych w Radomiu pozwalające na przenoszenie maszyn wirtualnych pomiędzy tymi Ośrodkami bez ich zatrzymywania.

.

W ramach zadania Zamawiający wymaga :

1. Dostarczenia licencji oprogramowania warstwy wirtualizacyjnej dla 4 czteroprocesorowych serwerów (razem 16 procesorów fizycznych) z rocznym wsparciem producenta

2. Dostarczenia licencji oprogramowania zarządzającego dla dwuprocesorowego serwera z rocznym wsparciem producenta

3. Wykonania instalacji dostarczonego oprogramowania wirtualizacyjnego na 4 serwerach dostarczonych w Zadaniu 1 - typ 1

4. Wykonania instalacji dostarczonego oprogramowania zarządzającego na serwerze wskazanym przez Zamawiającego

5. Opracowanie Dokumentacji powykonawczej zawierającą opis wdrożonej konfiguracji oraz procedury administracyjne i eksploatacyjne w zakresie uzgodnionym z Zamawiającym

Tabela 14. Wymagania funkcjonalne dotyczące oprogramowania wirtualizacyjnego

Lp.	Charakterystyka /Wymagania minimalne
	Konsolidacja:
1	Warstwa wirtualizacji powinna być rozwiązaniem systemowym tzn. powinna być zainstalowana bezpośrednio na sprzęcie fizycznym.
2	Rozwiązanie powinno zapewnić możliwość obsługi wielu instancji systemów operacyjnych na jednym serwerze fizycznym i powinno się charakteryzować maksymalnym możliwym stopniem konsolidacji sprzętowej.
3	Oprogramowanie do wirtualizacji musi zapewnić możliwość skonfigurowania maszyn wirtualnych z możliwością dostępu do 255GB pamięci operacyjnej.
4	Oprogramowanie do wirtualizacji musi zapewnić możliwość skonfigurowania maszyn wirtualnych 1, 2, 3, 4, 5, 6, 7 i 8 procesorowych.
5	Rozwiązanie powinno umożliwiać łatwą i szybką rozbudowę infrastruktury o nowe usługi bez spadku wydajności i dostępności pozostałych wybranych usług.
6	Rozwiązanie powinno w możliwie największym stopniu być niezależne od producenta platformy sprzętowej.
7	Rozwiązanie powinno wspierać następujące systemy operacyjne posiadane przez Zamawiającego: Windows 7, Windows 8, Windows Server 2000, Windows Server 2003, Windows Server 2008, Windows Server 20012, RHEL 5, RHEL 6, Debian, CentOS, FreeBSD, SCO OpenServer
8	Rozwiązanie powinno umożliwiać przydzielenie większej ilości pamięci RAM dla maszyn wirtualnych niż fizyczne zasoby RAM serwera w celu osiągnięcia maksymalnego współczynnika konsolidacji.
9	Rozwiązanie powinno posiadać centralną konsolę graficzną do zarządzania maszynami wirtualnymi usługami.
10	Rozwiązanie powinno zapewnić możliwość monitorowania wykorzystania zasobów fizycznych infrastruktury wirtualnej.
11	Oprogramowanie do wirtualizacji powinno zapewnić możliwość wykonywania kopii zapasowych instancji systemów operacyjnych oraz ich odtworzenia w możliwie najkrótszym czasie.
12	Oprogramowanie do wirtualizacji powinno zapewnić możliwość wykonywania kopii migawkowych instancji systemów operacyjnych na potrzeby tworzenia kopii zapasowych bez przerywania ich pracy.
13	Oprogramowanie do wirtualizacji powinno zapewnić możliwość klonowania systemów operacyjnych wraz z ich pełną konfiguracją i danymi.
14	Oprogramowanie zarządzające musi posiadać możliwość przydzielania i konfiguracji uprawnień z możliwością integracji z usługami katalogowymi Microsoft Active Directory.
15	Oprogramowanie do wirtualizacji musi obsługiwać przełączenie ścieżek SAN (bez utraty komunikacji) w przypadku awarii jednej z dwóch ścieżek.
16	Platforma wirtualizacyjna musi umożliwiać wykorzystanie procesorów fizycznych do 12 rdzeni na procesor.
17	Rozwiązanie musi umożliwiać udostępnienie maszynie wirtualnej większej ilości zasobów dyskowych aniżeli fizycznie zarezerwowane.
18	System musi umożliwiać tworzenie standardowej konfiguracji dla hostów i zautomatyzowanie zgodności dla tych konfiguracji.
19	System powinien posiadać funkcjonalność wirtualnego przełącznika (switch) umożliwiającego tworzenie sieci wirtualnej w obszarze hosta i pozwalającego połączyć maszyny wirtualne w obszarze jednego hosta, a także na zewnątrz sieci fizycznej.
20	System powinien umożliwiać podłączenie wirtualnych przełączników firm trzecich.
21	Wirtualny przełącznik musi dostarczać usługę prywatnych sieci VLAN (Private VLAN).
	Wysoka dostępność:
22	Rozwiązanie powinno mieć możliwość przenoszenia maszyn wirtualnych w czasie ich pracy pomiędzy serwerami fizycznymi.
23	Rozwiązanie powinno zapewnić ciągłą pracę usług. Usługi krytyczne biznesowo powinny działać bez przestoju, czas niedostępności innych usług nie powinien przekraczać kilkunastu minut.
24	Powinna zostać zapewniona odpowiednia redundancja i nadmiarowość zasobów tak, by w przypadku awarii np. serwera fizycznego usługi na nim świadczone zostały przełączone na inne serwery infrastruktury.
25	Rozwiązanie powinno umożliwiać łatwe i szybkie ponowne uruchomienie systemów/usług w przypadku awarii poszczególnych elementów infrastruktury. Należy opisać wykorzystywany mechanizm.
26	Rozwiązanie powinno zapewnić bezpieczeństwo danych mimo poważnego uszkodzenia lub utraty sprzętu lub oprogramowania. Należy opisać wykorzystywany mechanizm.
27	Rozwiązanie powinno zapewniać mechanizm bezpiecznego uaktualniania warstwy wirtualizacyjnej, hostowanych systemów operacyjnych (np. wgrywania patch-y) i aplikacji tak, aby zminimalizować ryzyko awarii systemu na skutek wprowadzenia zamiany. Należy opisać wykorzystywany mechanizm.
28	Rozwiązanie powinno zapewnić możliwość szybkiego wykonywania kopii zapasowych oraz odtwarzania usług. Proces ten nie powinien mieć wpływu na utylizację zasobów fizycznych infrastruktury wirtualnej. Należy opisać wykorzystywany mechanizm.
29	Rozwiązanie powinno zapewniać pracę bez przestojów dla wybranych maszyn wirtualnych, niezależnie od systemu operacyjnego oraz aplikacji, podczas awarii serwerów fizycznych, bez utraty danych i dostępności danych podczas awarii serwerów fizycznych.
30	Rozwiązanie musi umożliwiać dodawanie i rozszerzanie dysków wirtualnych, procesorów i pamięci RAM podczas pracy wybranych systemów.
	Równoważenie obciążenia i przestoje serwisowe:
31	Czas planowanego przestoju usług związany z koniecznością prac serwisowych (np. rekonfiguracja serwerów, macierzy, switchy) powinien być ograniczony do minimum. Wymagana jest możliwość przenoszenia usług pomiędzy serwerami fizycznymi oraz wolumenami dyskowymi, bez przerywania pracy usług. Należy opisać wykorzystywany mechanizm.
32	Rozwiązanie powinno umożliwiać automatyczne równoważenie obciążenia serwerów fizycznych pracujących jak platforma dla infrastruktury wirtualnej. Należy opisać wykorzystywany mechanizm.
	Obsługa potrzeb biznesu:
33	Rozwiązanie powinno zapewnić możliwość szybkiego tworzenia i uruchamiania nowych usług wraz z ich pełną konfiguracją i preinstalowanymi narzędziami systemowymi w celu efektywnej obsługi wymagań biznesowych.
34	Rozwiązanie powinno zapewnić mechanizm wykonywania kopii – klonów systemów operacyjnych wraz z ich pełną konfiguracją i danymi.

Zadanie 5. Dostawa oraz wdrożenie oprogramowania do backupu zbudowanego środowiska zwirtualizowanego

Wymagane oprogramowanie powinno zapewnić spójność i wydajność kopiowania danych w utworzonym środowisku zwirtualizowanym. Wykonany backup infrastruktury powinien być docelowo kopiowany na biblioteki taśmowe przy użyciu posiadanego przez Zamawiającego oprogramowania HP Data Protector.

W ramach zadania Wykonawca dostarczy licencje i wdroży oprogramowanie do backupu środowiska wirtalizacyjnego dla 16 procesorów oraz opracuje Dokumentację powykonawczą. Oprogramowanie to musi spełniać poniższe wymagania:

1. Oprogramowanie do archiwizacji musi współpracować z infrastrukturą wirtualizacji zbudowaną w Zadaniu 4.

2. Rozwiązanie powinno współpracować z hostami zarządzanymi centralnie jak i hostami nie zarządzanymi (standalone)

3. Rozwiązanie nie może instalować żadnych swoich komponentów (agent) w archiwizowanych maszynach wirtualnych i na hostach

4. Rozwiązanie musi wspierać backup wszystkich systemów operacyjnych w wirtualnych maszynach, które są wspierane przez dostarczone oprogramowanie wirtualizacyjne

5. Rozwiązanie powinno mieć możliwość instalacji na następujących posiadanych przez Zamawiającego systemach operacyjnych zarówno w wersji 32 jak i 64 bitowej:

1. Microsoft Windows Server 2003 SP2

2. Microsoft Windows Vista SP2

3. Microsoft Windows Server 2008 SP2

4. Microsoft Windows Server 2008 R2

5. Microsoft Windows Server 2012

6. Microsoft Windows 7 SP1

7. Microsoft Windows 8

6. Rozwiązanie powinno dawać możliwość odzyskiwania całych obrazów maszyn wirtualnych z obrazów, pojedynczych plików z systemu plików znajdujących się wewnątrz wirtualnej maszyny. Rozwiązanie musi umożliwiać odzyskanie plików na zasadzie „one-click restore”. Rozwiązanie musi umożliwiać odzyskiwanie plików z następujących systemów plików wykorzystywanych przez Zamawiającego:

1. Linux - ext2, ext3, ext4, ReiserFS (Reiser3), JFS, XFS

2. Unix - JFS, XFS, UFS

3. BSD - UFS, UFS2

4. Solaris - UFS, ZFS

5. Mac - HFS, HFS+

6. Windows - NTFS, FAT, FAT32

7. Rozwiązanie powinno umożliwiać natychmiastowe odzyskanie wirtualnej maszyny i jej uruchomienie bez kopiowania na storage podłączony do hostów (wbudowana funkcjonalność NFS Server)

8. Rozwiązanie powinno umożliwiać bezpośrednie odzyskiwanie obiektów z takich usług posiadanych przez Zamawiającego jak Active Directory (użytkownicy i grupy), Microsoft Exchange (e-maile i kontakty) i Microsoft SQL (tabele i rekordy) z maszyn wirtualnych

9. Rozwiązanie powinno umożliwiać indeksowanie plików zawartych w archiwach maszyn wirtualnych z systemem operacyjnym Windows w celu szybkiego ich przeszukiwania

10. Rozwiązanie powinno w pełni korzystać z mechanizmów Changed Block Tracking lub równoważnych

11. Rozwiązanie powinno korzystać z mechanizmów VSS (Windows Volume Shadowcopy) wbudowanych w najnowsze systemy operacyjne z rodziny Windows.

12. Rozwiązanie powinno mieć wbudowane mechanizmy deduplikacji i kompresji archiwum w celu redukcji zajmowanej przez archiwa przestrzeni dyskowej

13. Rozwiązanie powinno mieć możliwość instalacji centralnej konsoli do zarządzania większą ilością serwerów archiwizujących

14. Dostęp do tej konsoli powinien być realizowany przez przeglądarkę WWW

15. Rozwiązanie powinno mieć wbudowany mechanizm informowania o pomyślnym lub niepomyślnym zakończeniu procesu archiwizacji poprzez email, zapis do Event Log’u Windows lub wysłanie komunikatu SNMP.

16. Rozwiązanie powinno mieć możliwość rozbudowy procesu archiwizacji o dowolne skrypty tworzone przez administratora i dołączane do zadań archiwizacyjnych

17. Rozwiązanie powinno mieć wbudowaną możliwość replikacji wirtualnych maszyn pomiędzy hostami, w tym możliwość replikacji ciągłej

18. Rozwiązanie powinno mieć możliwość tworzenia środowiska wirtualnego laboratorium w środowisku wirtualizacyjnym

19. Rozwiązanie powinno mieć możliwość występowania i zatwierdzania wniosków o tworzenie środowisk w wirtualnym laboratorium

20. Rozwiązanie powinno zapewnić możliwość sprawdzenia poprawności wykonania archiwum poprzez odtworzenie wirtualnej maszyny w izolowanym środowisku i jej uruchomienie w środowisku macierzystym

21. Rozwiązanie powinno mieć możliwość automatycznej zmiany numeracji IP maszyn przywracanych w środowiskach centrum zapasowego w przypadku awarii centrum podstawowego

Zadanie 6. Dostawa oraz wdrożenie oprogramowania umożliwiającego monitorowanie zbudowanego środowiska zwirtualizowanego oraz integracja tego rozwiązania z systemem monitorowania Zamawiającego

W ramach zadania Wykonawca dostarczy licencje i wdroży system umożliwiający monitorowanie zbudowanego środowiska zwirtualizowanego dla 16 procesorów spełniający poniższe wymagania oraz zintegruje to rozwiązanie z systemem monitorowania posiadanym przez Zamawiającego MS SCOM 2007.

1. Dostarczony system powinien być zgodny i całkowicie integrować się z Microsoft System Center Operations Manager 2007 i Microsoft System Center Operations Manager 2012

2. System powinien korzystać z wbudowanych w infrastrukturę wirtualizacyjną mechanizmów monitorowania i nie może instalować na infrastrukturze żadnych agentów

3. System musi być certyfikowany przez producenta dostarczonego oprogramowania wirtualizacyjnego oraz przez Microsoft (pakiet umieszczony na Microsoft System Center Marketplace)

4. System musi zapewnić możliwość monitorowania i raportowania o problemach wszystkich elementów infrastruktury wirtualizacyjnej w tym: stację zarządzającą, klastry, hosty, wirtualne maszyny, wirtualne switche, podsystem dyskowy, hardware

5. Dane przesyłane podczas monitoringu powinny być zaszyfrowane i przesyłane przy pomocy protokołu HTTPS

6. W system powinny być wbudowane łącza do bazy wiedzy producenta oprogramowania wirtualizacyjnego skorelowane z obsługiwanymi alertami i wydarzeniami

7. System musi mieć możliwość skalowania poprzez instalację wielu instancji komponentów monitorujących i kolekcjonujących wydarzenia z infrastruktury wirtualizacyjnej

8. System powinien zawierać centralną konsolę zarządzającą w celu konfiguracji tych komponentów i zarządzania ich licencjami

9. System musi mieć możliwość integracji z Microsoft System Center Virtual Machine Manager

10. Rozwiązanie musi zapewnić monitorowanie między innymi następujących metryk z infrastruktury wirtualizacyjnej i alarmowanie o następujących wydarzeniach:

1. Ilość pamięci wirtualnych maszyn skompresowanej w locie przez hosty

2. Wiek plików kopii migawkowych wirtualnych maszyn

3. Zdarzenie zapisania na dysku obsługiwanym przez infrastrukturę wirtualizacyjną (datastore) plików nie związanych z wirtualizacją

4. Zdarzenie utraty połączenia pomiędzy hostem a macierzą dyskową

5. Zdarzenie przepełnienia partycji file systemu

6. Zdarzenie braku połączenia do serwera NFS

Zadanie 7. Realizacja szkoleń

1. Wykonawca przeprowadzi szkolenia zgodnie z następującymi wymaganiami:

1. Szkolenie dla administratorów serwerowego systemu operacyjnego

   1. 7 osób

   2. czas trwania szkolenia: 5 dni roboczych (40 godzin zegarowych)

   3. program szkolenia - instalacja i konfiguracja serwerów opartych na zamawianym systemie; monitorowanie i utrzymanie systemu; zarządzanie platformą systemową za pomocą wbudowanego interpretera poleceń; implementacja usług sieciowych oraz klastrów pracy bezawaryjnej; wdrożenie wbudowanych mechanizmów wirtualizacji; implementacja usług katalogowych; konfigurowanie bezpiecznego dostępu do danych.

2. Szkolenie dla administratorów oferowanej macierzy

   1. 4 osoby

   2. czas trwania szkolenia: 3 dni robocze (24 godziny zegarowe)

   3. program szkolenia - architektura, konfiguracja, zarządzanie, tworzenie wolumenów, monitorowanie.

3. Szkolenie z obsługi systemów diagnostycznych oferowanych serwerów i macierzy

   1. 4 osoby

   2. czas trwania szkolenia: 3 dni robocze (24 godziny zegarowe)

   3. program szkolenia - zarządzanie i monitorowanie sprzętem, interpretacja logów, uaktualnianie oprogramowania układowego, wgrywanie poprawek.

4. Szkolenie dotyczące pakietu produktów narzędziowych - Szkolenie dla administratorów systemu zarządzania infrastrukturą i oprogramowaniem

   1. 4 osoby

   2. czas trwania szkolenia: 5 dni roboczych (40 godzin zegarowych)

   3. program szkolenia - instalacja i konfiguracja dostarczonego systemu zarządzania infrastrukturą i oprogramowaniem; wykrywanie i organizacja zasobów; zarządzanie ustawieniami klienta systemu; tworzenie zapytań i raportowanie danych.

5. Szkolenie dotyczące pakietu produktów narzędziowych - Szkolenie dla operatorów systemu zarządzania komponentami

   1. 4 osoby

   2. czas trwania szkolenia: 5 dni robocze (40 godziny zegarowe)

   3. program szkolenia - architektura systemu zarządzania komponentami, monitorowanie systemów serwerowych Windows i Linux; wykorzystanie wbudowanych raportów; tworzenie własnych widoków.

6. Szkolenie dla administratorów systemów bazodanowych - Administrowanie oferowanym systemem bazodanowym

   1. 4 osoby

   2. czas trwania szkolenia: 5 dni roboczych (40 godzin zegarowych)

   3. program szkolenia - architektura instalacja i konfiguracja serwera baz danych; omówienie baz danych i praca z plikami; opis obiektów bazy danych; tworzenie kopii zapasowych, odtwarzanie i replikacja baz danych; bezpieczeństwo; zarządzanie użytkownikami; optymalizacja; monitorowanie pracy.

7. Szkolenie dla projektantów baz danych - Projektowanie i optymalizacja baz danych w oferowanym środowisku bazodanowym

   1. 8 osób

   2. czas trwania szkolenia: 5 dni roboczych (40 godzin zegarowych)

   3. program szkolenia - projektowanie modeli bazy danych: koncepcyjnego, logicznego, fizycznego; optymalizacja wydajności i zapytań do baz danych; projektowanie transakcji; projektowanie obsługi danych xml;  projektowanie strategii bezpieczeństwa dotyczącej: programowania, wdrażania, działania systemów bazodanowych.

8. Szkolenie dla administratorów środowiska wirtualizacyjnego

   1. 4 osoby

   2. czas trwania szkolenia: 5 dni roboczych (40 godzin zegarowych)

   3. program szkolenia - instalacja i konfiguracja wirtualnego środowiska, zarządzanie i administrowanie środowiskiem, wykonywanie kopii zapasowych.

9. Szkolenie dla administratorów dostarczonych produktów do backupu i monitorowania środowiska zwirtualizowanego

   1. 4 osoby

   2. czas trwania szkolenia: 3 dni robocze (24 godziny zegarowe)

   3. program szkolenia - instalacja i konfiguracja produktów, zarządzanie i administrowanie środowiskiem, wykonywanie backupu.

10. Wykonawca zapewni szkolenia dla osób pracujących w Radomiu.

11. wszyscy uczestnicy szkolenia muszą otrzymać materiały szkoleniowe w języku polskim, w formie papierowej lub elektronicznej w formacie PDF.

12. wszystkie szkolenia powinny być autoryzowanie przez producenta oferowanego produktu (sprzętu lub oprogramowania). Zamawiający dopuszcza szkolenia równoważne tj. zapewniające pozyskanie wiedzy i umiejętności na poziomie zgodnym z określonymi w programach i materiałach szkoleniowych producenta.

13. wszyscy uczestnicy szkolenia otrzymają zaświadczenia potwierdzające ukończenie szkolenia i posiadania odpowiednich kompetencji administratora.

14. Wykonawca pokryje wszelkie koszty związane z dojazdem, pobytem oraz wyżywieniem i zakwaterowaniem wykładowców, którzy będą prowadzili szkolenie.

15. Jeżeli wykonawca zaoferuje szkolenie w Radomiu poza siedzibą CIS Radom:

1. Szkolenia zostaną zorganizowane w hotelu/hotelach o standardzie co najmniej 3-gwiazdkowym lub w ośrodku/ośrodkach konferencyjno-szkoleniowych odpowiadających standardem hotelowi standardu co najmniej 3-gwiazdkowego, zgodnie z rozporządzeniem Ministra Gospodarki i Pracy z dnia 19 sierpnia 2004 r. w sprawie obiektów hotelarskich i innych obiektów, w których są świadczone usługi hotelarskie (Dz. U. z 2006 r. Nr 22, poz. 169, z późn. zm.) oraz spełniające wymagania dla budynków zamieszkania zbiorowego zgodnie z rozporządzeniem Ministra Infrastruktury z dnia 12 kwietnia 2002 r. w sprawie warunków technicznych, jakim powinny odpowiadać budynki i ich usytuowanie (Dz. U. Nr 75, poz. 690, z późn. zm.).

2. Wykonawca każdego dnia trwania szkolenia zapewni: dwie przerwy kawowe, każda trwająca ok. 10 minut oraz jedną przerwę obiadową trwającą ok. 40 minut.

3. Wykonawca zapewni każdego dnia szkolenia wyżywienie dla wszystkich uczestników:

1. dostępne przez cały czas trwania szkolenia: kawa, herbata, butelkowana woda mineralna gazowana i niegazowana, naturalne soki owocowe (butelkowane lub w kartonach) oraz ciastka.

2. obiad – zupa, danie główne, surówki, owoce, herbata, kawa, butelkowana woda mineralna, naturalne soki owocowe (butelkowane lub w kartonach); czyste sztućce i zastawa (nie mogą być jednokrotnego użytku) – podany w oddzielnym pomieszczeniu (strefie przeznaczonej do podawania posiłków), które:

• spełnia wymagania sanitarne wynikające z obowiązujących przepisów,

• jest wyposażone w sprawną i wydajną wentylację oraz klimatyzację,

• jest posprzątane i uporządkowane bez zbędnych przedmiotów lub mebli,

1. wykonawca zapewni każdemu uczestnikowi odpowiednio danie mięsne, wegetariańskie lub bezglutenowe zgodnie ze zgłoszonym zapotrzebowaniem w harmonogramie szkoleń.

1. Jeżeli wykonawca zaoferuje szkolenie poza Radomiem:

1. Wykonawca zapewni transport uczestników szkolenia spod siedziby CIS Radom do miejsca przeprowadzenia szkolenia.

2. Szkolenia zostaną zorganizowane w hotelu/hotelach o standardzie co najmniej 3-gwiazdkowym lub w ośrodku/ośrodkach konferencyjno-szkoleniowych odpowiadających standardem hotelowi standardu co najmniej 3-gwiazdkowego, zgodnie z rozporządzeniem Ministra Gospodarki i Pracy z dnia 19 sierpnia 2004 r. w sprawie obiektów hotelarskich i innych obiektów, w których są świadczone usługi hotelarskie (Dz. U. z 2006 r. Nr 22, poz. 169, z późn. zm.) oraz spełniające wymagania dla budynków zamieszkania zbiorowego zgodnie z rozporządzeniem Ministra Infrastruktury z dnia 12 kwietnia 2002 r. w sprawie warunków technicznych, jakim powinny odpowiadać budynki i ich usytuowanie (Dz. U. Nr 75, poz. 690, z późn. zm.).

3. Wykonawca każdego dnia trwania szkolenia zapewni: dwie przerwy kawowe, każda trwająca ok. 10 minut oraz jedną przerwę obiadową trwającą ok. 40 minut.

4. Wykonawca zapewni każdego dnia szkolenia wyżywienie dla wszystkich uczestników:

1. dostępne przez cały czas trwania szkolenia: kawa, herbata, butelkowana woda mineralna gazowana i niegazowana, naturalne soki owocowe (butelkowane lub w kartonach) oraz ciastka.

2. obiad – zupa, danie główne, surówki, owoce, herbata, kawa, butelkowana woda mineralna, naturalne soki owocowe (butelkowane lub w kartonach); czyste sztućce i zastawa (nie mogą być jednokrotnego użytku) – podany w oddzielnym pomieszczeniu (strefie przeznaczonej do podawania posiłków), które:

• spełnia wymagania sanitarne wynikające z obowiązujących przepisów,

• jest wyposażone w sprawną i wydajną wentylację oraz klimatyzację,

• jest posprzątane i uporządkowane bez zbędnych przedmiotów lub mebli,

3. wykonawca zapewni każdemu uczestnikowi odpowiednio danie mięsne, wegetariańskie lub bezglutenowe zgodnie ze zgłoszonym zapotrzebowaniem w harmonogramie szkoleń.

5. Wykonawca zapewni noclegi dla uczestników szkolenia, pomiędzy każdym z dni szkolenia w hotelu/ ośrodku konferencyjno – szkoleniowym, w którym realizowane będzie szkolenie, wraz ze śniadaniem oraz kolacją (pokoje jednoosobowe lub dwuosobowe do pojedynczego wykorzystania, z węzłem sanitarnym).

2. 14 dni od daty podpisania Umowy Wykonawca przedstawi Zamawiającemu do akceptacji – harmonogram szkoleń przygotowany w porozumieniu z Zamawiającym obejmujący:

1. programy szkoleń zawierające szczegółowe informacje o zakresie tematycznym i rozkładzie zajęć dla poszczególnych szkoleń,

2. metodę i formę prowadzenia szkoleń,

3. listę wykładowców i informacje o wykładowcach którzy przeprowadzą poszczególne szkolenia.

3. Wykonawca zobowiązany będzie do przeprowadzenia szkoleń zgodnie
   z zatwierdzonym przez zamawiającego szczegółowym zakresem tematycznym i harmonogramem szkoleń.

4. Zamawiający zastrzega sobie prawo do modyfikacji harmonogramu szkoleń, z wytypowaniem na poszczególne cykle mniejszej lub większej liczby uczestników, z zachowaniem ilości cykli szkoleń i sumarycznej liczby uczestników.

5. Wykonawca w ramach prowadzonych szkoleń zobowiązany jest przekazać Zamawiającemu:

1. materiały szkoleniowe,

2. listy obecności,

3. listę wydanych zaświadczeń i komplet imiennych zaświadczeń dla wszystkich uczestników, którzy ukończą szkolenia, pod warunkiem uczestnictwa w pełnym wymiarze zajęć.

76