Opis Przedmiotu Zamówienia

Załącznik nr 2.2 do SIWZ

Sprawa numer: 14/SISP/PN/2013

Opis Przedmiotu Zamówienia

Przedmiotem zamówienia jest rozbudowa środowiska sprzętowo-systemowego o elementy  infrastruktury oraz oprogramowanie systemowe i narzędziowe, na potrzeby realizacji zadań Projektu SISP tj. Systemu Informacyjnego Intranet, Rejestru REGON, Rejestru TERYT, Systemu Metadanych Statystycznych wraz z Systemem wspierającym organizację i monitorowanie Projektowania Badań Statystycznych, Portalu Sprawozdawczego, Systemu Edukacyjnego, Hurtowni Danych Statystycznych wraz Publiczną Hurtownią Danych oraz Bankiem Danych Lokalnych, Systemu Pozyskiwania, Przetwarzania i Integracji Danych Statystycznych, Systemu Wspomagania Analiz i Decyzji oraz Systemu Prezentacji Informacji.

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

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

2. Dostarczenie oraz wdrożenie oprogramowania systemowego i bazodanowego

3. Rozbudowa i wykonanie konsolidacji sieci SAN dla potrzeb projektu SISP

4. Aktualizacja i rekonfiguracja zwirtualizowanego uniwersalnego środowiska pracującego na potrzeby projektu SISP

5. Dostarczenie oraz wdrożenie oprogramowania do backupu zwirtualizowanego uniwersalnego środowiska oraz rozbudowa, konsolidacja i centralizacja systemu backup środowiska SISP

6. Dostarczenie oraz wdrożenie oprogramowania umożliwiającego monitorowanie zwirtualizowanego uniwersalnego środowiska pracującego na potrzeby projektu SISP oraz integracja tego rozwiązania z systemem monitorowania Zamawiającego

7. Realizacja szkoleń

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

Większość prac wdrożeniowych i rekonfiguracyjnych będzie realizowana w Podstawowym Centrum Przetwarzania Danych GUS w Warszawie – Xx. Xxxxxxxxxxxxxx 000. Niektóre czynności dotyczące zadania 1 i zadania 3 będą realizowane w Zapasowym Centrum Przetwarzania w CIS Radom – xx. Xxxxxx 00/00. Z uwagi na fakt, iż prace 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 minimalizacjia przestojów.

Zamawiający do realizacji projektu SISP udostępnia system usług katalogowych bazujący na Microsoft Active Directory w wersji Windows 2008 R2.

Zakres usług realizowanych przez ten system jest następujący:

• Centralny katalog informacji o użytkownikach, komputerach i zasobach,

• Uwierzytelnienie użytkowników, stacji roboczych i serwerów,

• Autoryzacja użytkowników przy dostępie do aplikacji i zasobów,

• Zarządzanie konfiguracją oprogramowania na stacjach i serwerach.

Zamawiający wykorzystuje następujące komponenty infrastruktury informatycznej:

• Usługę aktualizacji systemu operacyjnego, która jest zbudowana na bazie oprogramowania Microsoft WSUS 3.0,

• Moduł monitorowania wydajności oraz dostępności aplikacji i usług zbudowany na bazie systemu zarządzającego Microsoft System Center Operations Manager 2007 w wersji R2,

• Moduł zarządzania konfiguracją dla serwerów stworzony w oparciu o oprogramowanie Microsoft System Center Configuration Manager 2007,

• System PKI zbudowany w oparciu o usługi certyfikacji stanowiące komponent systemu operacyjnego MS Windows Server 2008 R2,

• System ochrony antywirusowej z oprogramowaniem McAfee VirusSCAN w wersji 8.8.0 SP2,

• Serwery bazodanowe z oprogramowaniem Microsoft SQL Server 2008.

1. Opis posiadanego środowiska serwerowego

Infrastruktura serwerowa w centrach przetwarzania danych Zamawiającego kształtowała się na przestrzeni kilku lat w miarę realizacji kolejnych funkcjonalnych projektów IT. W wielu wypadkach, w związku z bieżącymi wymaganiami, środowiska sprzętowe projektowano w oparciu o wydzielone struktury. Jednak potrzeby użytkowe wymagają od środowiska IT elastyczności w zakresie możliwości bieżącej rekonfiguracji wybranych zasobów fizycznych serwerów.

W ramach projektów prowadzonych w statystyce, w latach 2008-2010, zasoby serwerowe zostały poszerzone o serwery blade HP ProLiant BL680c G5, HP ProLiant BL460c G1, HP ProLiant BL460c G6,HP ProLiant BL480c G1, rozmieszczone w infrastrukturach blade HP C7000.

Infrastruktury serwerów blade są monitorowane za pomocą systemu HP Insight Manager.

2. Opis posiadanego środowiska SAN Zamawiającego

Środowisko sieci SAN w centrach przetwarzania danych Głównego Urzędu Statystycznego kształtowało się na przestrzeni kilku lat w miarę realizacji kolejnych projektów IT. W niektórych projektach środowisko sprzętowe pamięci masowych projektowano w oparciu o wydzielone struktury sieci SAN. Aktualne potrzeby wymagają większej elastyczności w zakresie możliwości bieżącej rekonfiguracji wybranych zasobów fizycznych serwerów, zarówno w zakresie dostępu do zasobów macierzy dyskowych jak również bibliotek taśmowych dostępnych w sieci SAN. Potrzeby te muszą być zrealizowane w oparciu o modernizację istniejącej infrastruktury SAN poprzez konsolidację SAN środowiska SISP z innymi elementami SAN Zamawiającego.

Opis aktualnego środowiska sieci SAN przeznaczonego do konsolidacji:

1. Sieć SAN znajdująca się w serwerowni na I-szym piętrze powstała w latach 2008-2009 w ramach projektu SISP. Składa się z następujących elementów:

- macierzy SAN HP EVA 8100

- biblioteki taśmowej MSL 8096 z 2 napędami LTO 4

- 5 infrastruktur blade C7000 z redundantnymi 24 portowymi przełącznikami HP AE372A Brocade 4/24 San Switch i HP AJ821A B-series 8/24c Blade System San Switch (połączenia pomiędzy przełącznikami to głównie 4Gb, jedno 8Gb)

Wszystkie serwery blade mają dostęp do zasobów macierzy oraz bibliotek taśmowych. Topologia architektury połączeń SAN to tzw. układ full-mesh.

2. Sieć SAN znajdująca się w serwerowni na parterze powstała w roku 2010 jako środowisko analityczne . Składa się z następujących elementów:

- macierzy SAN HP EVA 8400

- 2 bibliotek taśmowych HP MSL 8096 z 4 napędami LTO 5 każda

- 2 infrastruktur blade C7000 z urządzeniami HP Virtual Connect

- 2 przełączników HP AM870A 8/40 PowerPack+ 24-ports SAN switch (aktywne 24 porty)

- infrastruktury serwerowej z dodatkowej szafy (N1) poprzez urządzenia HP Virtual Connect

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 16 portów na każdym z przełączników. Wolne porty nie są wyposażone we wkładki SFP.

3. Sieć SAN znajdująca się w serwerowni na parterze powstała w roku 2011 w ramach projektu SISP. Składa się z następujących elementów:

- macierzy SAN HP EVA 8400

- macierzy SAN NetApp3240

- biblioteki taśmowej HP MSL 8096 z 2 napędami LTO 4

- 5 infrastruktur blade C7000 (z czego jedna znajduje się w serwerowni na I-szym piętrze) z redundantnymi przełącznikami HP AJ821A B-series 8/24c Blade System SAN Switch

- infrastruktury serwerowej z dodatkowych szaf (N1, N2 i N3) poprzez urządzenia HP Virtual Connect

- 2 przełączników HP AM872A 8/80 PowerPack+ 48-ports SAN switch (aktywne 48 portów)

Topologia architektury połączeń SAN to tzw. układ core-edge. W chwili obecnej na każdym przełączniku HP AM872A 8/80 jest zajętych po 27 portów. W 17 wolnych portach, w każdym przełączniku HP AM872A 8/80, znajdują się wkładki SFP AJ716A. Pozostałe porty nie są wyposażone we wkładki SFP.

4. Dwa urządzenia: macierz EVA 4400 oraz VLS 12000, znajdujące się w serwerowni na parterze, podłączone obecnie do wydzielonej sieci SAN, które należy włączyć do powstającej sieci SAN bezpośrednio do przełączników HP AM872A 8/80

5. Dwie biblioteki taśmowe HP MSL 8096 z 4 napędami LTO 4 każda, znajdujące się w serwerowni w lokalizacji CIS Xxxxx xx. Xxxxxx 00/00 podłączone obecnie do wydzielonej sieci SAN, które należy przewieźć do Warszawy i włączyć do powstającej sieci SAN bezpośrednio do przełączników HP AM872A 8/80

Dodatkowo na potrzeby konsolidacji Zamawiający posiada:

- trakt światłowodowy multimode 50 (długość 176 m) do komunikacji pomiędzy serwerowniami zakończony panelami w szafach. Użyto kabla typu XG/OM4 odpowiedniego do przenoszenia danych z prędkością do 200MBps.

- do wykorzystania następujące licencje (nie zainstalowane)

T5519A HP 8/40 SAN Switch 8Gb 8-port Upgrade LTU - 2 sztuki

T5520A HP8/80 SAN Switch 8 Gb 16-port Upgrade LTU - 1 sztuka

3. Opis posiadanego zwirtualizowanego uniwersalnego środowiska Zamawiającego.

Infrastruktura wirtualizacyjna w GUS oparta jest o VMware i składa się z kilku środowisk vCenter, powstałych w różnych okresach i na różnych zestawach sprzętowych.

1. Infrastruktura VMware , uniwersalna nr 1, znajduje się w serwerowni na parterze i

składa z następujących elementów:

• 2 infrastruktury blade C7000 zawierające po 15 serwerów, rozmieszczone w osobnych szafach,

• macierz SAN HP EVA 8400 o łącznej pojemności rzędu 90 TB,

• połączenia LAN Ethernet oraz SAN.

Wszystkie serwery blade mają dostęp do zasobów macierzy.

Wszystkie 30 serwerów blade to HP ProLiant BL460c G6 o parametrach:

- CPU: 2 x 6 core Intel Xeon 2933 MHz, RAM: 64 GB,

- HDD: 2 x 300 GB, NIC: 4 x 1 Gb, FC: 2 x 8 Gb.

Każdy z powyższych serwerów jest hostem ESXi 4.1. Cała infrastruktura jest zarządzana serwerem fizycznym VMware vCenter Server 4.1, łączącym wszystkie hosty w jeden klaster DRS i HA.

Backup maszyn wirtualnych jest wykonywany na macierz dyskową przy użyciu mechanizmów VMware Data Recovery 2.0.

Na potrzeby przetargu SISP określono maksymalne zasoby przydzielane jednej maszynie wirtualnej na 8 vCPU i 32 GB RAM.

2. Infrastruktura VMware , uniwersalna nr 2, znajduje się w serwerowni na parterze i

składa z następujących elementów:

- 2 infrastruktury blade C7000 zawierające po 10 serwerów, rozmieszczone w osobnych szafach, oznaczonych jako N2 i N3,

- połączenia z macierzą SAN HP EVA 8400, należącej do systemu analitycznego, połączenie to w ramach konsolidacji SAN zostanie zlikwidowane, przestrzeń dyskowa będzie dostarczona ze skonsolidowanego SAN projektu SISP

- połączenia LAN Ethernet oraz SAN.

Wszystkie serwery blade mają dostęp do zasobów macierzy.

Wszystkie 20 serwerów blade to HP ProLiant BL460c G6 o parametrach:

- CPU: 2 x 6 core Intel Xeon 2933 MHz, RAM: 96 GB,

- HDD: 2 x 146 GB, NIC: 8 x, FC: 2 x 4 Gb.

Z tej infrastruktury wyodrębniono 5 serwerów w środowisko terminalowe VMware View, pozostawiając je fizycznie w tej samej obudowie N3. Środowisko to jest opisane w punkcie 3.

Każdy z pozostałych 15 serwerów jest hostem ESX 4.1. Cała infrastruktura jest zarządzana serwerem fizycznym VMware vCenter Server 4.1, łączącym wszystkie hosty w jeden klaster DRS i HA.

Backup maszyn wirtualnych jest wykonywany na macierz dyskową przy użyciu mechanizmów VMware Data Recovery 1.2.

3. Infrastruktura VMware środowiska terminalowego VMware View to 5 serwerów, wyodrębnionych z infrastruktury uniwersalnej nr 2, podłączonych do macierzy SAN - NetApp3240, zawierającej 60 dysków po 600 GB. Każdy serwer jest hostem ESXi 5.0.

Do zarządzania tą infrastrukturą służą posadowione na niej następujące maszyny wirtualne: VMware vCenter Server 5.0, VMware View Connection Manager i jego replika, Teradici PCoIP Management Console - zarządzanie terminalami, McAfee Move dla VMware View, VMware Data Recovery 2.0 x 3. Maszyn wirtualnych dla terminali jest obecnie 150.

Backup maszyn wirtualnych jest wykonywany najpierw na dyski serwera McAfee Move przy użyciu mechanizmów VMware Data Recovery 2.0, a następnie na taśmy przez system HP Data Protector.

4. Infrastruktura VMware, uniwersalna nr 3, znajdująca się w serwerowni na I piętrze składa z następujących elementów:

- 3 infrastruktury blade C7000 zawierające łącznie 7 serwerów ESX (oraz kilkanaście innych serwerów), rozmieszczone w osobnych szafach, oznaczonych jako Rack1, Rack3, i Rack7.

- macierz SAN HP EVA 8100 o łącznej pojemności rzędu 90 TB (dyski FC: 33 TB, FATA: 55 TB),

- połączenia LAN Ethernet oraz SAN.

Wszystkie serwery blade mają dostęp do zasobów macierzy.

Sześć serwerów blade to HP ProLiant BL480c G5 o parametrach:

- CPU: 4 x 6 core Intel Xeon 2400 MHz, RAM: 64 GB,

- HDD: 2 x 72 GB, NIC: 4 x, FC: 2 x 4 Gb.

Serwery te są hostami ESX 4.1, zgrupowanymi w dwa klastry (4 i 2 węzły).

Siódmy serwer to HP ProLiant BL460c G5 o parametrach:

- CPU: 4 x 6 core Intel Xeon 2800 MHz, RAM: 32 GB,

- HDD: 2 x 72 GB, NIC: 2 x, FC: 2 x 8 Gb.

Serwer ten jest hostem ESX 4.1, stanowiącym osobny klaster.

Cała infrastruktura jest zarządzana serwerem fizycznym VMware vCenter Server 4.1.

Backup maszyn wirtualnych jest wykonywany na macierz dyskową przy użyciu mechanizmów VMware Data Recovery 1.2.

4. Opis posiadanego środowiska backupowego

Urządzenia (biblioteki taśmowe MSL i VLS) obecnie używane oraz przeznaczone do backupu są wymienione w opisie posiadanego środowiska SAN.

Polityką backupu zarządzają trzy serwery z zainstalowanym Cell Managerem.

Backup maszyn wirtualnych w środowisku VMware odbywa się na zasób macierzowy narzędziem VDR a następnie jest kopiowany na bibliotekę taśmową LTO.

Zainstalowane wersje oprogramowania HP Data Protector na serwerach to 6.11 i 6.20.

Wykaz i ilość posiadanych licencji:

• Cell Manager for Windows / Linux 3 szt.

• Drive Extension for SAN / all platforms 4 szt.

• Manager-of-Managers Extension for Windows / Linux 1 szt.

• On-line Extension for ONE Windows / Linux system 11szt.

• Extension for ONE 61-250 Slot Library 2 szt.

• Drive Extension for Windows / NetWare / Linux 2 szt.

• Tape drive for SAN / all platforms 8 szt.

• VLS Gateway Base Capacity Licenses 33 szt.

• HP StorageWorks VLS data deduplication capacity LTU 33 szt.

Liczba hostów obecnie backupowanych to 101 szt.

Łączna orientacyjna ilość miejsca zajętego przez backup to 107 TB.

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 16.2 do SIWZ.

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

Zamawiający wymaga dostarczenia sprzętu:

• fabrycznie nowego

• objętego gwarancyjną

• posiadającego najnowszą dostępną wersję oprogramowania

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

Typ sprzętu	Ilość szt.	Numer tabeli
Infrastruktura blade	3	Tabela 2
Serwer blade typ 1 (4 procesory)	9	Tabela 3
Serwer blade typ 2 (2 procesory)	11	Tabela 4
Serwer blade typ 3 (2 procesory)	7	Tabela 5
Serwer stelażowy typ 4	1	Tabela 6
Szafa Rack 19”	2	Tabela 7
Konsola zarządzająca do montażu w szafie Rack	1	Tabela 8
Moduł zasilania PDU	6	Tabela 9
UPS do infrastruktur blade	3	Tabela 10
UPS do macierzy	2	Tabela 11
Macierz xxxxxxx	0	Tabela 12
Rozbudowa macierzy HP EVA 8400 w Centrum Podstawowym	1	Tabela 13
Rozbudowa macierzy HP EVA 8400 w Centrum Zapasowym	1	Tabela 14

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

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 rozbudowy macierzy dyskowej przeznaczonej do projektów SISP HP EVA 8400 znajdującej się w Centrum Podstawowym, zakupionej przez Zamawiającego w ramach projektu SISP w 2011 roku, zgodnie ze specyfikacją określoną w Tabeli 13. Alternatywnie, Zamawiający dopuszcza dostawę nowej macierzy, o co najmniej takich samych parametrach wydajnościowych oraz takiej samej pojemności dyskowej o jaką miała być rozbudowana macierz HP EVA 8400, zamiast rozbudowy istniejącej. Specyfikacja nowej macierzy określona jest w Tabeli 12.

Zamawiający wymaga rozbudowy macierzy dyskowej przeznaczonej do projektów SISP HP EVA 8400 znajdującej się w Centrum Zapasowym zgodnie ze specyfikacją określoną w Tabeli 14.

Rozbudowa polega na zwiększeniu przestrzeni istniejących macierzy HP EVA 8400, o nowe półki dyskowe wraz z dyskami i niezbędną infrastrukturą potrzebną do prawidłowej pracy macierzy (w tym dodatkową szafą rack na nowe półki dyskowe).

Podczas rozbudowy muszą być spełnione poniższe warunki:

1. Półki dyskowe muszą być fabrycznie nowe,

2. Półki dyskowe muszą być kompatybilne z posiadaną przez Zamawiającego macierzą HP EVA 8400,

3. Półki dyskowe i ich komponenty muszą być oznakowane w taki sposób, aby możliwa była identyfikacja zarówno produktu jak i producenta,

4. Do każdej półki dyskowej musi być dostarczony komplet standardowej dokumentacji dla użytkownika w formie papierowej lub elektronicznej,

5. Półki dyskowe muszą być dostarczone Zamawiającemu w oryginalnych opakowaniach fabrycznych i muszą być objęte 3-letnią gwarancją 24x7 z czasem naprawy 6 godzin,

6. Półki dyskowe muszą współpracować z siecią energetyczną o parametrach : 230 V ± 10% , 50 Hz,

7. Wymagane jest dołączenie do oferty oświadczenia, że oferowane urządzenia będą fabrycznie nowe oraz ich instalacja nie spowoduje utraty przez Zamawiającego gwarancji na rozbudowywane urządzenia

8. Dyski i półki muszą znajdować się na liście kompatybilności w oficjalnych dokumentacjach produktu producenta macierzy.

Uwaga: W tabelach od 2 do 14 należy wypełnić kolumnę „Oferta wykonawcy” i załączyć do Formularza ofertowego

Tabela 2. Infrastruktura blade

Lp.	Parametr	Wymagania minimalne	Oferta wykonawcy
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 w układzie mieszanym. , także serwerów blade w 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 12 wkładek SFP 1Gb RJ45 (po 6 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 wyjęcia 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).
14.	Gwarancja	3 letnia gwarancja w trybie 24/7 w miejscu instalacji na wszystkie elementy obudowy z czasem naprawy 24h.
Zarządzanie infrastrukturą serwerów blade
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 3. Serwer blade typ 1

Lp.	Parametr	Wymagania minimalne	Oferta wykonawcy
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	256 GB RAM z możliwością rozbudowy do 1TB, w tym do 384 GB bez konieczności wymiany dostarczonych modułów
5.	Sterownik dysków wewnętrznych	Macierzowy, RAID 0 ,1.
6.	Dyski twarde	Minimum dwa wewnętrzne dyski o sumarycznej pojemności użytkowej 146GB w RAID 1, dyski SAS 15k lub SSD.
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	MS Windows Server, Red Hat Enterprise Linux, SUSE Linux Enterprise Server, VMware .
10.	Gwarancja	3 letnia gwarancja w trybie 24/7 w miejscu instalacji z czasem naprawy 24h.
11.	Dokumentacja	Dokumentacja techniczna w języku polskim lub angielskim wystarczająca do użytkowania urządzenia.

Tabela 4. Serwer blade typ 2

Lp.	Parametr	Wymagania minimalne	Oferta wykonawcy
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	256 GB RAM z możliwością rozbudowy do 768 GB, w tym do 384 GB bez konieczności wymiany dostarczonych modułów
5.	Sterownik dysków wewnętrznych	Macierzowy, RAID 0 ,1.
6.	Dyski twarde	Minimum dwa wewnętrzne dyski o sumarycznej pojemności użytkowej 146GB w RAID 1, dyski SAS 15k lub SSD.
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	MS Windows Server, Red Hat Enterprise Linux, SUSE Linux Enterprise Server, VMware .
10.	Gwarancja	3 letnia gwarancja w trybie 24/7 w miejscu instalacji z czasem naprawy 24h.
11.	Dokumentacja	Dokumentacja techniczna w języku polskim lub angielskim wystarczająca do użytkowania urządzenia.

Tabela 5. Serwer blade typ 3

Lp.	Parametr	Wymagania minimalne	Oferta wykonawcy
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	128 GB RAM z możliwością rozbudowy do 512 GB, w tym do 192 GB bez konieczności wymiany dostarczonych modułów
5.	Sterownik dysków wewnętrznych	Macierzowy, RAID 0 ,1.
6.	Dyski twarde	Minimum dwa wewnętrzne dyski o sumarycznej pojemności użytkowej 146GB w RAID 1, dyski SAS 15k lub SSD.
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	MS Windows Server, Red Hat Enterprise Linux, SUSE Linux Enterprise Server, VMware .
10.	Gwarancja	3 letnia gwarancja w trybie 24/7 w miejscu instalacji z czasem naprawy 24h.
11.	Dokumentacja	Dokumentacja techniczna w języku polskim lub angielskim wystarczająca do użytkowania urządzenia.

Tabela 6. Serwer stelażowy typ 4

Lp.	Parametr	Wymagania minimalne	Oferta wykonawcy
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 minimum 2 procesorów.
6.	Pamięć RAM	128 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.	Karty HBA	Minimum jedna dwuportowa karta FC 8Gb
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, SUSE Linux Enterprise Server, VMware .
19.	Gwarancja	3 letnia gwarancja w trybie 24/7 w miejscu instalacji z czasem naprawy 24h.
20.	Dokumentacja	Dokumentacja techniczna w języku polskim lub angielskim wystarczająca do użytkowania urządzenia.

Tabela 7. Szafa Rack 19”

Lp.	Parametr	Wymagania minimalne	Oferta wykonawcy
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 8. Konsola zarządzająca do montażu w szafie Rack

Lp.	Parametr	Wymagania minimalne	Oferta wykonawcy
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, itp...). 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 z czasem naprawy 72h.

Tabela 9. Moduł zasilania PDU

Lp.	Parametr	Wymagania minimalne	Oferta wykonawcy
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 czasem naprawy 72h.

Tabela 10. UPS do infrastruktury blade

Lp.	Parametr	Wymagania minimalne	Oferta wykonawcy
1.	Nazwa producenta
2.	Typ produktu, model
3.	Napięcie wejściowe	220, 230, 240V
4.	Zakres częstotliwości napięcia wejściowego:	50-60Hz
5.	Moc rzeczywista:	Minimum 4500W
6.	Złącze wejścia elektrycznego	IEC 309 32A
7.	Min. ilość i rodzaj złącz połączeń wyjściowych	4 x IEC 320-C13 4 x IEC 320-C19
8.	Czas ładowania	<3 godzin do 80% użytecznego naładowania, <48 godzin do całkowitego naładowania
9.	Możliwość zastosowania dodatkowych akumulatorów w modułach rozszerzeń	Minimum 4 sztuki.
10.	Czas podtrzymania w zależności od obciążenia	Min. 19 minut przy 100 % obciążeniu Dopuszcza się zaoferowanie dodatkowych baterii do modułu UPS w celu spełnienia wymogów czasu podtrzymania.
11.	Wymagania dodatkowe	Moduł umożliwiający zarządzanie, monitoring oraz diagnostykę poprzez sieć Możliwość integracji z dostarczonym oprogramowaniem zarządzającym infrastrukturą serwerów.
12.	Wysokość (podana w jednostkach EIA)	4U (max. 7U z modułami rozszerzeń)
13.	Gwarancja	3 letnia gwarancja w trybie 24/7 w miejscu instalacji z czasem naprawy 72h.

Tabela 11. UPS do macierzy

Lp.	Parametr	Wymagania minimalne	Oferta wykonawcy
1.	Nazwa producenta
2.	Typ produktu, model
3.	Napięcie wejściowe	220, 230, 240V
4.	Zakres częstotliwości napięcia wejściowego:	50-60Hz
5.	Moc rzeczywista:	Minimum 6300W
6.	Złącze wejścia elektrycznego	IEC 309 32A
7.	Min. ilość i rodzaj złącz połączeń wyjściowych	6 x IEC 320-C19
8.	Czas ładowania	<3 godzin do 80% użytecznego naładowania, <48 godzin do całkowitego naładowania
9.	Możliwość zastosowania dodatkowych akumulatorów w modułach rozszerzeń	Minimum 4 sztuki.
10.	Czas podtrzymania w zależności od obciążenia	min 15 minut przy 100 % obciążeniu Dopuszcza się zaoferowanie dodatkowych baterii do modułu UPS w celu spełnienia wymogów czasu podtrzymania.
11.	Wymagania dodatkowe	Moduł umożliwiający zarządzanie, monitoring oraz diagnostykę poprzez sieć Możliwość integracji z dostarczonym oprogramowaniem zarządzającym infrastrukturą serwerów i macierzy.
12.	Wysokość (podana w jednostkach EIA)	5U (max. 8U z modułami rozszerzeń)
13.	Gwarancja	3 letnia gwarancja w trybie 24/7 w miejscu instalacji z czasem naprawy 72h.

Tabela 12. Nowa macierz dyskowa

Lp.	Parametr	Wymagania minimalne	Oferta wykonawcy
1.	Nazwa producenta
2.	Typ produktu, model
3.	Obudowa	Macierz dyskowa zainstalowana w 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. 192 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 200GB. Jeśli obsługa przestrzeni dyskowej jest osobno licencjonowana, wymagane jest dostarczenie licencji na zarządzanie przestrzenią dyskową dla całej przestrzeni dyskowej.
5.	Rozbudowa	Możliwość podwojenia liczby dysków w ramach oferowanego modelu macierzy.
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, 600GB, 900GB jak również dysków Nearline SAS o pojemnościach 1TB, 2TB i 3TB.
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	Praca 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 8GB na kontroler.
12.	Zabezpieczenie pamięci cache	Mirrorowanie pamięci cache kontrolerów macierzowych. 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 8 zewnętrznych interfejsów FC 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 32 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, MS Windows 2008, 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: MS Windows 2008, VMware ESX wraz z oprogramowaniem Site Recovery Manager, RedHat Linux 5, SUSE/SLES 10, 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.
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. Jeśli w/w funkcjonalność jest osobno licencjonowana, wymagane jest dostarczenie licencji na tę funkcjonalność bez limitu przestrzeni dyskowej.
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 aktualną wersją ) - konfiguracja grup dyskowych i wirtualnych dysków, wg. Wskazań Zamawiającego
25.	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.
26	Wirtualizacja zasobów	Macierz musi mieć możliwość rozbudowy o funkcjonalność wirtualizacji zasobów znajdujących się na innych macierzach dyskowych, w szczególności pochodzących od różnych dostawców. W ramach tej funkcjonalności musi istnieć możliwość wykonywania replikacji synchronicznej i asynchronicznej wolumenów logicznych pomiędzy różnymi typami wirtualizowanych macierzy dyskowych, gdzie zasoby źródłowe kopii zdalnej oraz docelowe kopii zdalnej mogą być zabezpieczone różnymi poziomami RAID i egzystować na różnych technologicznie dyskach stałych (FC, SATA). W ramach funkcjonalności wirtualizacji musi istnieć możliwość wykonania migracji wolumenów logicznych pomiędzy różnymi typami macierzy dyskowych, oraz wewnątrz samej macierzy, bez zatrzymywania aplikacji korzystającej z tych wolumenów. Wymaga się, aby zasoby źródłowe podlegające migracji oraz zasoby do których są migrowane mogły być zabezpieczone różnymi poziomami RAID i egzystować na różnych technologicznie dyskach stałych (FC, SATA).

Tabela 13. Rozbudowa macierzy HP EVA 8400 w Centrum Podstawowym

Lp.	Parametr	Wymagania minimalne	Oferta wykonawcy
1.	Dodatkowe półki dyskowe	Półka dyskowa z możliwością instalacji: do 12 dysków typu FC lub FATA. Wymagane jest dostarczenie min. 15 półek mogących pomieścić napędy dyskowe wyspecyfikowane w punkcie 2 a) do 8 dysków typu SSD. Wymagane jest dostarczenie min. 1 półki mogących pomieścić napędy dyskowe wyspecyfikowane w punkcie 2 b)
2.	Wymagana przestrzeń fizyczna	Fizyczna przestrzeń dyskowa rozbudowywana za pomocą dysków: 180 dysków 600GB/15krpm w technologii Fibre Channel. 8 dysków w technologii SSD o pojemności co najmniej 400GB. Jeśli obsługa przestrzeni dyskowej jest osobno licencjonowana, wymagane jest dostarczenie licencji na zarządzanie przestrzenią dyskową bez limitu przestrzeni dyskowej.
3.	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 aktualną wersją FW macierzy ( XCS 9.3.4) - konfiguracja grup dyskowych i wirtualnych dysków, wg. wskazań Zamawiającego - rekonfiguracja macierzy rozbudowywanej macierzy EVA w monitoringu z poziomu HP Storege Essentials 9.4.1
4.	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.

Tabela 14. Rozbudowa macierzy HP EVA 8400 w Centrum Zapasowym

Lp.	Parametr	Wymagania minimalne	Oferta wykonawcy
1.	Dodatkowe półki dyskowe	Półka dyskowa z możliwością instalacji: do 12 dysków typu FC lub FATA. Wymagane jest dostarczenie min. 1 półek mogących pomieścić napędy dyskowe wyspecyfikowane w punkcie 2 b) do 8 dysków typu SSD.
2.	Wymagana przestrzeń fizyczna	Fizyczna przestrzeń dyskowa rozbudowywana za pomocą dysków: 7 dysków 600GB/15krpm w technologii Fibre Channel. Jeśli obsługa przestrzeni dyskowej jest osobno licencjonowana, wymagane jest dostarczenie licencji na zarządzanie przestrzenią dyskową bez limitu przestrzeni dyskowej.
3.	Dodatkowe	Usługi do wykonania: - instalacja i konfiguracja półek dyskowych - do podłączenia nowej półeki należ użyć Cable FC Cooper SFP 2m All - instalacja dysków twardych - aktualizacja FW półek dyskowych i dysków (zgodnie z aktualną wersją FW macierzy ( XCS 9.3.4) - konfiguracja grup dyskowych i wirtualnych dysków, wg. Wskazań Zamawiającego - rekonfiguracja macierzy rozbudowywanej macierzy EVA w monitoringu z poziomu HP Storege Essentials 9.4.1
4.	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.

Zadanie 2. Dostarczenie oraz wdrożenie oprogramowania systemowego i bazodanowego w ilościach wyspecyfikowanych w Tabeli 15 i zgodnych z opisanymi poniżej wymaganiami

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

Typ oprogramowania	Liczba licencji
Serwerowy system operacyjny (licencjonowany na procesor)	90
System bazodanowy dla środowiska testowo-rozwojowego (dla 100 użytkowników)	1
System bazodanowy pomocniczy (licencjonowany na rdzeń procesora)	12
System bazodanowy główny (licencjonowany na rdzeń procesora)	108

Przedmiotem zamówienia jest dostarczenie oprogramowania wraz z bezterminowymi licencjami w ramach umowy licencyjnej na użytkowanie wyspecyfikowanego oprogramowania.

Wymagania ogólne w zakresie licencji:

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 statystyki publicznej podległych Prezesowi GUS.

2. Licencjonowanie musi uwzględniać prawo do (w okresie przynajmniej 5 lat) bezpłatnej instalacji udostępnianych przez producenta poprawek krytycznych i opcjonalnych do zakupionej wersji oprogramowania, z wyłączeniem licencji podlegających subskrypcji.

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

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

5. 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 oraz bazodanowych 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,

• Na wskazanych przez Zamawiającego serwerach przeprowadzi instalację i konfigurację oprogramowania do zapewnienia wielościeżkowości (multipathingu) dla wskazanej przez Zamawiającego macierzy,

• 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

Serwerowy system operacyjny spełniający poniższe wymagania.

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.

W Centrum Przetwarzania Danych Zamawiający posiada zainstalowane systemy operacyjne MS Windows Serwer 2008R2 zakupione w ramach projektu SISP. Zamawiający posiada możliwość uaktualnienia użytkowanego systemu operacyjnego do najnowszej wersji systemu MS Windows 2012 zgodnie z posiadaną umową z firmą Microsoft. Zakup licencji oprogramowania jest uzupełnieniem stanu licencyjnego dla systemów w środowisku Zamawiającego.

Dopuszcza się zaoferowanie produktów równoważnych do produktów wykorzystywanych przez Zamawiającego.

Wykonawca oferujący produkt równoważny musi wykazać spełnienie wszystkich warunków poniżej.

Równoważność serwerowego systemu operacyjnego oznacza, że:

1. Warunki licencji w każdym aspekcie licencjonowania są nie gorsze niż licencja każdego z produktów wymienionych powyżej,

2. Nabycie licencji oprogramowania równoważnego pozwala na legalne używanie posiadanych przez Zamawiającego licencji oprogramowania,

3. Funkcjonalność oprogramowania równoważnego nie może być gorsza od funkcjonalności oprogramowania wykorzystywanego przez Zamawiającego, przy czym pod pojęciem funkcjonalności Zamawiający rozumie zbiór funkcji oprogramowania określających zakres jego wykorzystania z wyłączeniem wyglądu interfejsu,

4. Oprogramowanie równoważne musi być kompatybilne i w sposób niezakłócony współdziałać ze sprzętem i oprogramowaniem funkcjonującym u Zamawiającego,

5. Oprogramowanie równoważne nie może zakłócić pracy środowiska systemowo-programowego Zamawiającego,

6. Oprogramowanie równoważne musi w pełni współpracować z systemami już eksploatowanymi u Zamawiającego (tzn. Active Directory 2008 R2 i MS WSUS v3 SP2 obsługujących ponad 460 serwerów z systemem Windows 2008 lub wyższej wersji, MS SCOM 2007 R2 monitorujący ponad 380 serwerów fizycznych i wirtualnych, MS SCCM 2007 R2 SP 2 zarządzający konfiguracją ponad 540 serwerów fizycznych i wirtualnych),

7. Oprogramowanie równoważne musi zapewniać pełną, równoległą współpracę w czasie rzeczywistym i pełną funkcjonalną zamienność produktu produktami stosowanymi przez Zamawiającego.

System bazodanowy dla środowiska testowo-rozwojowego

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

System bazodanowy pomocniczy 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 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) pomocniczy 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).

System bazodanowy główny 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 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) główny 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, itp.). 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.

Zadanie 3. Rozbudowa i wykonanie konsolidacji sieci SAN dla potrzeb projektu SISP zgodnie z poniższymi wymaganiami

W ramach konsolidacji sieci SAN dla potrzeb projektu SISP 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 realizujących zadania z projektu SISP.

Po konsolidacji powinna powstać:

- uniwersalna, bezpieczna (redundantna), elastyczna, skalowalna infrastruktura jednej sieci SAN

- ujednolicona konfiguracja portów na przełącznikach

- możliwość dołączania kolejnych urządzeń do nowej struktury

- możliwość wykorzystania w przyszłości wolnych portów (muszą być objęte licencją i wyposażone w odpowiednie wkładki - SFP/SFP+) na każdym przełączniku szkieletowym – HP AM872A 8/80 PowerPack+ 48-ports SAN switch wszystkich dostępnych fizycznych portów, na każdym HP AM870A 8/40 PowerPack+ 24-ports SAN switch min. po 32 porty

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 w ramach infrastruktury dostarczonej na potrzeby projektów SISP2009 i SISP2011 oraz środowiska analitycznego;

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. Przeprowadzi niezbędne prace montażowe, w tym przeniesienie urządzeń należących do Zamawiającego w ramach poszczególnych pomieszczeń serwerowni w GUS i lokalizacji CIS Radom;

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

6. Wykona podniesienie wersji mikrokodów urządzeń;

7. Wykona aktualizację oprogramowania do zarządzania środowiskiem SAN;

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

9. 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 (środowisko analityczne), każdy z 16 wkładkami HP AJ716A 8Gb Shortwave B-series FC SFP+ 1 pack, dołożenie po 16 szt. wkładek 8Gb FC SFP w celu wypełnienia slotów, na które posiadamy licencje.

Do posiadanych przez Zamawiającego 2 przełączników HP AM872A 8/80 PowerPack+ 48-ports SAN switch (projekt SISP2011), każdy z 44 wkładkami HP AJ716A 8Gb Shortwave B-series FC SFP+ 1 pack, dołożenie po 36 szt. wkładek 8Gb FC SFP w celu wypełnienia wszystkich dostępnych slotów i przygotowania w ten sposób szkieletu sieci SAN w serwerowni na parterze do obsługi kolejnych urządzeń.

Xxxxxxxxx 0 przełączników HP AM872A 8/80 PowerPack+ 48-ports SAN switch o dodatkowe licencje aktywujące wszystkie 80 portów.

Dostarczenie 2 przełączników SAN z odpowiednimi licencjami do podłączenia środowiska SISP2009 do przełączników HP AM872A 8/80 zgodnie ze specyfikacją zamieszczoną w tabeli 16.

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 typu FC LC-LC OM-3 to 40 szt. kabli o długości 15m i 40 szt. kabli o długości 30m.

Wszystkie objęte rozbudową przełączniki SAN oraz wyspecyfikowane elementy rozbudowy tych przełączników - sprzętowe i licencje, powinny być objęte gwarancją do maja 2015 r. na poziomie nie niższym niż 24/7 z czasem naprawy 24h.

Obecnie przełączniki ze środowiska:

- analitycznego posiadają gwarancję do czerwca 2013

- SISP 2011 posiadają gwarancję do 3 maja 2015 r.

Jeżeli w wyniku działania Wykonawcy zostanie utracona gwarancja, którą obecnie posiadamy Wykonawca obejmie te elementy gwarancją.

Uwaga: W tabeli wypełnić kolumnę „Oferta wykonawcy” i załączyć do Formularza ofertowego

Tabela 16. Przełącznik SAN

Lp.	Parametr	Wymagania minimalne	Oferta wykonawcy
1.	Nazwa producenta
2.	Typ produktu, model
3.	Obudowa	Obudowa przeznaczona do montażu w szafie przemysłowej 19”, o wysokość maksymalnie 1U.
4.	Porty FC	Przełącznik wyposażony w minimum 24 fizyczne porty (sloty na moduły SFP), w tym minimum 24 porty aktywne, wyposażone we wkładki SFP SW 8Gb. Możliwość konfiguracji aktywnych portów do pracy w trybach: E-port, F-port oraz FL-port. Możliwość dynamicznej aktywacji nieaktywnych portów za pomocą zakupionych kluczy licencyjnych. Przełącznik wykonany w technologii FC 8 Gb, umożliwiający pracę portów FC z prędkościami 8, 4, 2 Gb z funkcją autonegocjacji prędkości.
5.	Obsługa modułów SFP	Wymiana w trybie „na gorąco” modułów portów FC.Możliwość instalacji jednomodowych modułów SFP umożliwiających bezpośrednie połączenie (bez dodatkowych urządzeń pośredniczących) z innymi przełącznikami na odległość minimum 10km.
6.	Architektura	Przełącznik FC musi być wykonany w tzw. architekturze „non-blocking” uniemożliwiającej blokowanie się ruchu wewnątrz przełącznika przy pełnej prędkości pracy wszystkich portów.
7.	Przepustowość	Zsumowana przepustowość przełącznika minimum 384 Gb full duplex.
8.	Agregacja połączeń	Możliwość agregacji połączeń pomiędzy przełącznikami (trunking) na poziomie poszczególnych ramek – licencja wymagana. Możliwość utworzenia połączenia typu „trunk” o przepustowości minimum 64Gb - aktualnie taka licencja (jeśli potrzebna dodatkowa) nie jest wymagana – możliwość rozbudowy o taką funkcjonalność w przyszłości.
9.	Serwisowalność i redundancja	Możliwość uaktualniania oprogramowania (firmware’u) przełącznika w czasie pracy urządzenia, bez wymogu ponownego uruchomienia urządzeń w sieci SAN. Redundantne wentylatory.
10.	Zarządzanie	Możliwość konfiguracji przez komendy tekstowe w interfejsie znakowym oraz przez przeglądarkę internetową z interfejsem graficznym. Możliwość zarządzania przez zintegrowany port Ethernet i RS232.
11.	Dodatkowe funkcjonalności	Przełącznik powinien posiadać jako opcję do przyszłego rozszerzenia możliwość konfiguracji minimum 484 tzw. „buffer credits” dla portów przełącznika wybranych do połączeń na dalekie odległości.
12.	Kompatybilność	Pełna kompatybilność z istniejącą infrastrukturą SAN Zamawiającego – 2 przełączniki HP 8/40 SAN Switch 2 przełączniki HP 8/80 SAN Switch 8 przełączników HP 4/24 SAN switch 14 przełączników HP 4/24c SAN switch
13.	Gwarancja	3 letnia gwarancja w trybie 24/7 w miejscu instalacji na wszystkie elementy obudowy z czasem naprawy 24h.

Zadanie 4. Aktualizacja i rekonfiguracja zwirtualizowanego uniwersalnego środowiska pracującego na potrzeby projektu SISP

W ramach rekonfiguracji środowiska VMware w GUS Wykonawca przeprowadzi projekt infrastrukturalny, który zapewni:

• wysoką dostępność i optymalną pracę serwerów i stacji wirtualnych w GUS,

• możliwość przypisywania maszynom wirtualnym zasobów z różnych macierzy dyskowych,

• możliwość dołączania kolejnych urządzeń do nowej infrastruktury,

• bezpieczeństwo maszyn wirtualnych i danych,

• aktualną wersję oprogramowania hostów i oprogramowania zarządzającego.

W ramach zadania Wykonawca zrealizuje:

1. W odniesieniu do infrastruktury VMware środowiska uniwersalnego nr 2:

1. Przeprowadzi analizę obecnego środowiska VMware oraz opracuje i uzgodni Koncepcję rekonfiguracji.

2. Przygotuje szczegółowy Projekt techniczny realizacji uzgodnionej koncepcji uwzględniający dobre praktyki i rekomendacje eksploatacyjne publikowane przez firmę VMware.

3. 12 serwerów ESX skonfiguruje jako osobne vCenter podłączone do macierzy dyskowej w skonsolidowanej sieci SAN, zmieniając ich wersję z ESX na ESXi, na co licencje posiada Zamawiający, i aktualizując firmware sprzętu, w tym obudów blade.

2. W odniesieniu do posiadanej infrastruktury VMware Zamawiającego:

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

2. Wykona aktualizację oprogramowania hostów ESX i ESXi.

3. Wykona aktualizację oprogramowania do zarządzania środowiskiem VMware.

4. Przeprowadzi rekonfigurację podłączenia do macierzy dyskowych i przełączników Virtual Connect.

5. Uwzględni w projekcie zadanie backupowe realizowane w zadaniu 5.

6. Wykona testy akceptacyjne:

- testy niezawodnościowe dla wybranych serwerów,

- testy funkcjonalne.

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

Całe oprogramowanie środowiska VMware objętego rekonfiguracją, zarówno hosty ESX i ESXi jak i oprogramowanie zarządzające, ma być w wersji najnowszej na dzień rozpoczęcia realizacji projektu, ale z ograniczeniami sprzętowymi i wynikającymi z licencji posiadanych przez Zamawiającego.

Zadanie 5. Dostarczenie oraz wdrożenie oprogramowania do backupu uniwersalnego środowiska zwirtualizowanego oraz rozbudowa, konsolidacja i centralizacja systemu backup środowiska SISP

W ramach rozbudowy, konsolidacji i centralizacji środowiska backupu w GUS Wykonawca zaprojektuje oraz wykona centralizację backupu umożliwiającą zarządzanie politykami backupowymi z jednego miejsca oraz zapewni optymalną, zgodną z najlepszymi praktykami pracę urządzeń, oprogramowania oraz wykorzystanie licencji posiadanych przez Zamawiającego.

Wymagane oprogramowanie powinno zapewnić spójność i wydajność kopiowanych danych w środowisku uniwersalnym infrastruktury wirtualnej VMWare. Wykonany backup infrastruktury uniwersalnej powinien być kopiowany na biblioteki taśmowe przy użyciu posiadanego przez zamawiającego oprogramowania HP Data Protector zakupionego w ramach projektu SISP.

W ramach zadania Wykonawca dostarczy licencje i wdroży oprogramowanie do backupu środowiska infrastruktury uniwersalnej VMware dla 136 procesorów, spełniające poniższe wymagania:

1. Oprogramowanie do archiwizacji powinno współpracować z infrastrukturą wirtualizacji opartą na VMware ESX oraz ESXi w wersjach 3.5, 4.0, 4.1 i 5 oraz Hyper-V

2. Rozwiązanie powinno współpracować z hostami ESX i ESXi zarządzanymi przez VMware vCenter jak i hostami nie zarządzanymi (standalone)

3. Rozwiązanie powinno współpracować z hostami Hyper-V zarządzanymi przez System Center Virtual Machine Manager, zgrupowanymi w klastry jak i nie zarządzanymi (standalone)

4. Rozwiązanie nie może instalować żadnych swoich komponentów (agent) w archiwizowanych maszynach wirtualnych i na hostach ESX jak i na hostach Hyper-V.

5. Rozwiązanie musi wspierać backup wszystkich systemów operacyjnych w wirtualnych maszynach, które są wspierane przez VMware i Hyper-V

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

1. Microsoft Windows XP SP3

2. Microsoft Windows Server 2003 SP2

3. Microsoft Windows Vista SP2

4. Microsoft Windows Server 2008 SP2

5. Microsoft Windows Server 2008 R2

6. Microsoft Windows 7 SP1

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

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

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

9. Rozwiązanie powinno umożliwiać odzyskiwanie bezpośrednie odzyskiwanie obiektów z takich usług jak Active Directory (użytkownicy i grupy), Microsoft Exchange (emaile i kontakty) i Microsoft SQL (tabele i rekordy) z maszyn wirtualnych środowiska VMware

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

11. Rozwiązanie powinno w pełni korzystać z mechanizmów zawartych w VMware vStorage API for Data Protection a w szczególności być zgodnym z mechanizmem Changed Block Tracking

12. Rozwiązanie powinno mieć wbudowane mechanizmy podobne do technologii CBT również dla platformy Hyper-V w celu przyśpieszenia procesu backupu.

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

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

15. Rozwiązanie powinno mieć możliwość instalacji centralnej konsoli do zarządzania większą ilością serwerów archiwizujących oraz jednoczesnego zarządzania backupami środowiska VMware i Hyper-V

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

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

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

19. Rozwiązanie powinno mieć wbudowaną możliwość replikacji wirtualnych maszyn pomiędzy hostami ESX i ESXi oraz w tym możliwość replikacji ciągłej

20. Rozwiązanie powinno mieć wbudowaną możliwość replikacji maszyn wirtualnych pomiędzy hostami Hyper-V

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

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

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

24. Rozwiązanie powinno być zgodne z konfiguracją rozproszonego przełącznika VMware (Distributed Virtual Switch)

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

W ramach zadania integracji środowiska HP Data Protector Wykonawca:

1. Przygotuje szczegółowy Projekt Techniczny wprowadzanych zmian.

2. Wdroży bibliotekę VLS do sieci SAN skonfigurowanie z zasobami dyskowymi wskazanymi przez zamawiającego.

3. Zaktualizuje oprogramowanie HP Data Protector na serwerach Cell Manager oraz na wskazanych serwerach klienckich do najnowszej wersji (zgodnie z licencjami posiadanym przez zamawiającego):

   1. Sprawdzi spójność i backupu lokalnych baz danych Data Protectora

   2. Zaktualizuje serwery Cell Manager do najnowszej wersji

   3. Zainstaluje poprawki do pozostałych serwerów Cell Manger i Installation Server

   4. Zaktualizuje środowisko – agentów Data Protectora na backupowanych hostach

4. Przeprowadzi centralizację wszystkich lokalnych serwerów Cell Manager do środowiska HP Data Protector MOM wraz z dostawą niezbędnych licencji i instalacją na serwerach Cell Manager (włączanych do środowiska MOM) licencji typu „Manager of Mgmt. LTU”.

5. Przeprowadzi migrację lokalnych baz danych mediów – MMDB z serwerów Cell Manager do centralnej bazy danych mediów:

   1. Wykonanie kopii lokalnych baz danych;

   2. Zmiana puli mediów na serwerach;

   3. Migracja danych z lokalnych baz MMDB do centralnej CMDB.

6. Wykona rekonfigurację napędów po zmianie w SAN - dodanie brakujących napędów do serwerów z zainstalowanym media agentem.

7. Wykona rekonfigurację polityk backupowych z uwzględnieniem dostarczonego oprogramowania backupu środowiska VMware.

8. Wykona konfigurację generowanych raportów.

9. Opracuje Dokumentację powykonawczą

10. Przygotuje instrukcje oraz procedury dla Administratora HP Data Protector MOM

Zadanie 6. Dostarczenie oraz wdrożenie oprogramowania umożliwiającego monitorowanie całego środowiska zwirtualizowanego pracującego na potrzeby projektu SISP oraz integracja tego rozwiązania z systemem monitorowania Zamawiającego

W ramach zadania Wykonawca dostarczy licencje i wdroży system umożliwiający monitorowanie środowiska VMware dla 136 procesorów spełniający poniższe wymagania oraz zintegruje to rozwiązanie z systemem monitorowania 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 zapewnić monitorowanie przez MS SCOM środowiska opartego o Vmware 3.0.1, 3.0.2, 3.0.3, 3.5.x, 4.0, 4.1, 5.0 zarówno w wersji płatnej jak i pojedynczych hostów pracujących w oparciu o edycję darmową

3. System powinien korzystać z wbudowanych w infrastrukturę VMware mechanizów monitorowania (VMware API) i nie może instalować na infrastrukturze żadnych agentów

4. System musi być certyfikowany przez VMware (certyfikat VMware Ready) oraz przez Microsoft (pakiet umieszczony na Microsoft System Center Marketplace)

5. System musi zapewnić możliwość monitorowania i raportowania o problemach wszystkich elementów infrastruktury VMware takich jak vCenter Server, klastry, hosty, wirtualne maszyny, wirtualne switche, podsystem dyskowy, hardware

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

7. W system powinny być wbudowane łącza do bazy wiedzy VMware skorelowane z obsługiwanymi alertami i wydarzeniami

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

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

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

11. Rozwiązanie musi zapewnić monitorowanie między innymi następujących metryk z infrastruktury VMware 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ę VMware (datastore) plików nie związanych z wirtualizacją

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

    5. Zdarzenie przepełnienia partycji VMFS

    6. Zdarzenie braku połączenia do serwera NFS

Zadanie 7. Szkolenia

Wykonawca zapewni szkolenia dla osób pracujących w Warszawie, za wyjątkiem 2 osób przewidzianych na szkolenie dla administratorów systemów bazodanowych Projektowanie i optymalizacja.

Jeśli szkolenie będzie przeprowadzane poza miejscem pracy osób biorących udział w szkoleniu, Wykonawca zapewni tym osobom zakwaterowanie i całodzienne wyżywienie.

Jeśli szkolenie będzie przeprowadzane poza Warszawą, wykonawca zapewni transport z siedziby GUS do miejsca szkolenia.

Wszystkie szkolenia poza 2 c) i 2 f) powinny być autoryzowanie przez producenta danego 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.

Wykonawca przedłoży Zamawiającemu do akceptacji szczegółowy harmonogram i zakres szkoleń w terminie 8 tygodni po podpisaniu Umowy.

Wykonawca zobowiązany jest powielić, w liczbie odpowiadającej liczbie uczestników każdego szkolenia wzór kwestionariusza AIOS i przedłożyć go do wypełnienia uczestnikowi na koniec szkolenia. Wykonawca przygotuje na podstawie wypełnionych kwestionariuszy AIOS zbiorcze zestawienie zawierające analizę danych zawartych w ankietach ewaluacyjnych obrazującą stopień zadowolenia uczestników oraz użyteczność przeprowadzonych szkoleń.

W terminie do 5. dnia od dnia szkolenia, wykonawca przekaże Zamawiającemu wypełnione przez uczestników kwestionariusze AIOS wraz ze zbiorczym zestawieniem. W przypadku niezadowalającej oceny całości szkolenia - ponad 50% ocen negatywnych w zakresie realizacji programu szkolenia, wykonawca przeprowadzi dodatkowe szkolenie na koszt własny. Organizacja dodatkowych sesji szkoleniowych będzie wymagała uzgodnienia z Zamawiającym terminów, programów sesji, zawartości materiałów szkoleniowych oraz wyboru trenerów.

1) Szkolenie dla administratorów zwirtualizowanego uniwersalnego środowiska

Administrowanie zwirtualizowanym uniwersalnym środowiskiem Zamawiającego - dla 3 osób, 5 dni

2) Szkolenia dla administratorów kupowanych lub rozbudowywanych produktów

1. Administracja oferowanej macierzy - dla 5 osób, 5 dni,

2. Sieć SAN z uwzględnieniem środowiska posiadanego przez Zamawiającego - dla 3 osób, 5 dni,

3. Obsługa systemów diagnostycznych oferowanych serwerów i macierzy - dla 3 osób, 3 dni

4. Administrowanie oprogramowaniem do zarządzania biblioteką wirtualną posiadaną przez Zamawiającego - dla 4 osób, 3 dni,

5. Administrowanie oprogramowaniem do zarządzania środowiskiem backupowym posiadanym przez Zamawiającego - dla 4 osób, 3 dni,

6. Administracja produktami do backupu i monitorowania zwirtualizowanego uniwersalnego środowiska – dla 4 osób, 5 dni

3) Szkolenia dla administratorów systemów bazodanowych

1. Administrowanie oferowanym systemem bazodanowym - dla 5 osób, 5 dni,

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

2. Projektowanie i optymalizacja oferowanego systemu bazodanowego - dla 5 osób, 5 dni, (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)

4) Szkolenia sieciowe

1. Budowa, konfiguracja, diagnoza, obsługa danych, głosu i wideo w sieci LAN. Przełączanie na poziomie warstwy drugiej, trzeciej i czwartej modelu ISO/OSI. Implementacja Vlanów i wybranych cech bezpieczeństwa w sieci LAN dla 3 osób, 5 dni,

2. Zarządzanie sieciami średniej wielkości złożonych z posiadanych przez zamawiającego routerów Cisco - dla 3 osób, 5 dni.

W szkoleniu muszą być omówione zagadnienia dotyczące konfiguracji i rozwiązywania problemów w sieci, metody rozbudowy sieci z wieloma przełącznikami, sieciami wirtualnymi, połączeniami "trunk" i drzewem rozpinającym (Spanning Tree),koncepcje routingu w sieciach średniej wielkości oraz aspektów branych pod uwagę przy jego implementacji, podstawowe konfiguracje i diagnostyki protokołu EIGRP, sposoby użycia list dostępu (ACL) przy zadanych założeniach oraz ich konfiguracja i diagnostyka, okoliczności wymagające zastosowania translacji adresów (NAT i PAT) w sieci średniej wielkości oraz jej konfiguracji na routerach.

3. Przewidywane przeznaczenie dostarczonego sprzętu, oprogramowania i usług do realizacji poszczególnych zadań projektu SISP

W tabeli 17 przedstawione jest potencjalne wykorzystanie zakupionego w zamówieniu sprzętu i oprogramowania w podziale na poszczególne zadania projektu SISP.

Tabela 17. Przydział zasobów na zadania projektu SISP

Zadanie projektu SISP	Funkcja - opis			Ilość serwerów blade			typ systemu bazodanowego licencje na rdzeń procesora (szt.)	Zasoby dyskowe w TB (RAID5)
				Typ1	Typ 2	Typ 3
PS, SPDS, SMS, PE, SII, Regon, Teryt	współdzielony - produkcja klaster active-active-passive (2 instancje bazodanowe)				3		24 szt. - główny	27
wszystkie zadania	współdzielony- deweloperka klaster active-passive						środowisko testowo-rozwojowe dla 100 użytkowników	3
wszystkie zadania	współdzielone - serwery aplikacyjne			3				35
HDS, PHD	produkcyjny HDS klaster active-passive + rezerwa (1 instancja bazodanowa)			3			24 szt. - główny	60
HDS, PHD	produkcyjny PHD klaster active-passive (1 instancja bazodanowa)				2		12 szt. - główny	20
HDS, PHD	repozytorium klaster active-passive (1 instancja bazodanowa)				2		12 szt. - pomocniczy	20
PS	aplikacyjne							3
SPDS	aplikacyjne							9
SWAiD	aplikacyjne i bazodanowy (użycie współdzielonego zasobu z HDS)				4			3
SPI	aplikacyjne na CMS					2		10
SMS, SPBS	aplikacyjne							2
PE	aplikacyjne
SII	aplikacyjne							2
Regon, Teryt	bazodanowe, aplikacyjne, klaster active-active-passive			3		5	48 szt. - główny	6
RAZEM				9	11	7		200

Serwerowy system operacyjny jest przeznaczony dla zakupionych serwerów blade wszystkich trzech typów (4 x 9 + 2 x 11 + 2 x 7 razem 72 szt.), dla serwera stelażowego do zarządzania (2 szt.) oraz dla serwerów SISP będących w posiadaniu Zamawiającego, które były zakupione ze starszymi licencjami systemu operacyjnego a są przeznaczone do zadań projektu SISP (2 x 8 razem 16 szt.).

System bazodanowy dla środowiska testowo-rozwojowego jest przeznaczony dla serwerów SISP będących w posiadaniu Zamawiającego, środowisko będzie przeznaczone dla wszystkich zadań projektu SISP oraz obecnych systemów eksploatowanych przez Zamawiającego.

System bazodanowy pomocniczy jest przeznaczony tylko dla zadania HDS, PHD.

System bazodanowy główny jest przeznaczony do pozostałych zadań projektu SISP jako serwery współdzielone lub przeznaczone dla konkretnego zadania zgodnie z zapisami w tabeli 17

Zakupiona przestrzeń dyskowa będzie rozdzielona na poszczególne zadania zgodnie z zapisami w tabeli 17.

Rozbudowa macierzy EVA 8400 w Radomiu jest elementem niezbędnym do rekonfiguracji backupu za pomocą urządzeń VLS 12000 niezbędnych do wykonywania replikacji pomiędzy Podstawowym a Zapasowym Centrum Przetwarzania.

Realizacja zadań od 3 do 6 wraz z dostarczonym oprogramowaniem i niezbędnym sprzętem zwiększą funkcjonalność całej infrastruktury oraz przygotują uniwersalne, wydajne, spójne i bezpieczne środowisko do realizacji wszystkich zadań projektu SISP.

64

_________________________________________________________________________________

Projekt SISP  współfinansowany przez Unię Europejską z Europejskiego  Funduszu Rozwoju Regionalnego oraz ze środków budżetu państwa. 7. Oś Priorytetowa: Społeczeństwo informacyjne – budowa elektronicznej administracji .