opz cz 2bip.stat.gov.pl/download/gfx/bip/pl/zamowieniapublicz… · web viewtitle opz cz 2 subject...

Projekt 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

BENEFICJENT:GŁÓWNY URZĄD STATYSTYCZNYal. Niepodległości 20800-925 Warszawa

Załącznik nr 1.2 do SIWZ Sprawa numer: 14/SISP-2/PN/2014

Opis Przedmiotu Zamówienia- część 2

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

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

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

2. Rozbudowę i wykonanie konsolidacji sieci SAN 3. Dostawę oraz wdrożenie oprogramowania systemowego, bazodanowego i

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

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

zwirtualizowanego 6. Dostawę oraz wdrożenie oprogramowania umożliwiającego monitorowanie

zbudowanego środowiska zwirtualizowanego oraz integrację tego rozwiązania z systemem monitorowania Zamawiającego

7. Realizację szkoleń

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

.

Zasadnicze prace wdrożeniowe i konfiguracyjne będą realizowane w Zapasowym Centrum Przetwarzania Danych GUS w Radomiu – ul. Planty 39/45, niektóre czynności będą realizowane również w Podstawowym Centrum Przetwarzania Danych GUS w Warszawie – Al. Niepodległości 208.Z uwagi na fakt, iż prace wdrożeniowe i rekonfiguracyjne będą prowadzone na działającym środowisku sprzętowo–systemowo–aplikacyjnym, wymagane jest zachowanie ciągłości działania tego środowiska oraz minimalizacja przestojów.

1




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

1. Systemu usług katalogowych bazującego na Microsoft Active Directory w wersji Windows 2008 R2. 2. Modułu monitorowania wydajności oraz dostępności aplikacji i usług zbudowanego na bazie systemu Microsoft System Center Operations Manager 2007 R2.3. Modułu zarządzania konfiguracją dla serwerów stworzonego w oparciu o oprogramowanie Microsoft System Center Configuration Manager 2007 R3.4. Systemu poczty Microsoft Exchange 2010.5. Środowisk do wirtualizacji serwerów bazujących na oprogramowaniu VMware vCenter 5.1 6. Serwerów bazodanowych z oprogramowaniem Microsoft SQL Server 2008 oraz 2012.

1) Opis posiadanej infrastruktury sprzętowej

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

Zasoby serwerowe w Zapasowym Centrum Przetwarzania Danych w Radomiu zostały poszerzone o serwery blade serwery blade HP ProLiant BL680c G5, HP ProLiant BL460c G1, HP ProLiant BL460c G6,HP ProLiant BL480c G1, rozmieszczone w infrastrukturach blade HP C7000..Środowisko sprzętowe pamięci masowych zostało oparte na bazie macierzy dyskowych SAN HP EVA 8100, SAN HP EVA 8400.Serwery blade mają dostęp do zasobów macierzowych oraz bibliotek taśmowych HP MSL 8096 z napędami LTO 4.

2) Opis posiadanego środowiska sieci SAN

Infrastruktura sieci SAN w Zapasowym Centrum Przetwarzania Danych kształtowała się w latach 2009-2013, w miarę realizacji kolejnych funkcjonalnych projektów SISP. W ten sposób powstało kilka środowisk sieci SAN, które nie są całkowicie ze sobą skonsolidowane.

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

- macierz SAN HP EVA 8100,- biblioteka taśmowa MSL 8096 z dwoma napędami LTO4,- trzy infrastruktury blade C7000 z redundantnymi 24 portowymi przełącznikami HP AJ821A

2




B-series 8/24c Blade System San Switch (połączenia pomiędzy przełącznikami : 8Gb, pomiędzy serwerami i zasobami SAN: 4Gb)

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

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

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

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

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

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

3




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

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

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

Zamawiający wymaga dostarczenia sprzętu:

fabrycznie nowego objętego gwarancyjną posiadającego najnowszą dostępną w dniu składania ofert wersję oprogramowania

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

Typ sprzętu Ilość szt. Numer tabeli

Macierz dyskowa 1 Tabela 2

Infrastruktura blade 2 Tabela 3

Serwer blade typ 1 (4 procesory) 7 Tabela 4

Serwer blade typ 2 (2 procesory) 6 Tabela 5

UPS do infrastruktury 2 Tabela 6

UPS do macierzy 1 Tabela 7

Serwer stelażowy typ 3 1 Tabela 8

Szafa Rack 1 Tabela 9

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

Moduł zasilania PDU 2 Tabela 11

Dyski zapasowe – typ 1 10 Tabela 12





4




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

Zamawiający wymaga dostarczenia systemu pamięci masowej, który musi być kompatybilny z VMware na poziomie ESXi 5.1 U2 i nowszym oraz posiadać certyfikację VMware vSphere Metro Storage Cluster lub równoważną. Praca macierzy ma być zabezpieczona za pomocą UPS-a wyspecyfikowanego w Tabeli 6.

Na serwerach typ 1 i typ 2, wyspecyfikowanych odpowiednio w Tabeli 4 i 5 Wykonawca zainstaluje systemy operacyjne dostarczone w zadaniu 3. Na serwerze stelażowym typ 3, wyspecyfikowanym w Tabeli 8, Wykonawca zainstaluje system operacyjny dostarczony w zadaniu 3 oraz potrzebne oprogramowanie narzędziowe.

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

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

Tabela 2. Macierz dyskowa

Lp. Parametr Wymagania minimalne

1. Nazwa producenta

2. Typ produktu, model

3. Obudowa Macierz dyskowa zainstalowana w pojedynczej, kompletnej szafie przemysłowej 19” o wysokości 42U wyposażonej w redundantne zasilanie oraz wszystkie niezbędne kable połączeniowe (zasilające i logiczne, w tym kable FC o długości 5m).

4. Pojemność Przestrzeń dyskowa zbudowana za pomocą min. 216 dysków w technologii SAS 2,5” o pojemności co najmniej 600GB i prędkości obrotowej min. 10k obr/min. oraz min. 24 dysków w technologii SSD 2,5” o pojemności co najmniej 400GB.

5




Jeśli obsługa przestrzeni dyskowej jest osobno licencjonowana, wymagane jest dostarczenie licencji na zarządzanie przestrzenią dyskową dla całej przestrzeni dyskowej.

5. Skalowalność rozwiązania

Liniowa skalowalność parametrów wydajnościowych zasobów dyskowych poprzez możliwość rozbudowy do 4 kontrolerów macierzowych.

Macierz z zainstalowanymi 4 kontrolerami musi umożliwiać obsługę do 480 dysków wewnętrznych.

6. Obsługa dysków Obsługa dysków SSD, SAS i Nearline SAS. Możliwość mieszania napędów dyskowych SSD, SAS i Nearline SAS w obrębie pojedynczej półki dyskowej. Możliwość obsługi dysków 2,5” jak również 3,5” w ramach jednej macierzy. Obsługa dysków SSD o pojemnościach 200GB, 400GB, dysków SAS o pojemnościach 300GB, 450GB, 600GB, 900GB, 1,2TB jak również dysków Nearline SAS o pojemności minimum 1TB

7. Sposób zabezpieczenia danych

Macierz powinna obsługiwać mechanizmy RAID zgodne z RAID1lub RAID10, RAID5, RAID6 realizowane sprzętowo za pomocą dedykowanego układu, z możliwością dowolnej ich kombinacji w obrębie oferowanej macierzy.

8. Zabezpieczenie dyskami spare

Możliwość definiowania globalnych dysków spare lub odpowiedniej zapasowej przestrzeni dyskowej dla różnych grup RAID.

9. Interfejsy dysków Dyski twarde typu „Hot-Plug” z dwoma interfejsami SAS 6Gb zarówno 2,5” jak i 3,5”.

10. Tryb pracy kontrolerów macierzowych

Minimum dwa kontrolery macierzowe obsługujące ruch blokowy po protokole Fibre Channel, pracujące w trybie active/active.

Równoczesny, aktywny dostęp (odczyt/zapis) do każdego dysku logicznego (LUN) ze wszystkich kontrolerów macierzy dla lepszego rozłożenia obciążenia.

11. Pamięć cache Minimalna wielkość zainstalowanej pamięci cache 16GB na kontroler.

12. Zabezpieczenie pamięci cache

Musi istnieć funkcjonalność Cache dla procesu

6




odczytu oraz Mirrored Cache dla procesu zapisu.

Podtrzymanie pamięci cache kontrolerów macierzowych przez minimum 90h lub czas potrzebny do zapisu zawartości cache na nośnik nieulotny.

13. Interfejsy zewnętrzne

Co najmniej 12 zewnętrznych interfejsów FC z możliwością rozbudowy do 24 przy dodaniu 2 kolejnych kontrolerów macierzowych, o prędkości minimum 8Gb.

14. Interfejsy wewnętrzne

SAS o prędkości min. 6Gb.

15. Zarządzanie grupami dyskowymi oraz dyskami logicznymi

Możliwość dynamicznego zwiększania oraz zmniejszania pojemności woluminów logicznych oraz wielkości grup dyskowych z poziomu kontrolera macierzowego bez przerywania dostępu do danych.

Możliwość definiowania woluminów logicznych o pojemności co najmniej 16 TB.

16. Ochrona danych w środowiskach heterogenicznych

Możliwość ochrony danych w heterogenicznych środowiskach sieci SAN – maskowanie LUN. Jeżeli dla zapewnienia izolacji LUN-ów dla różnych serwerów lub różnych grup serwerów potrzebne są dodatkowe komponenty (np.licencje) wymagane jest dostarczenie tych komponentów bez limitów na ilość separowanych maszyn.

17. Podłączanie zewnętrznych systemów operacyjnych

Możliwość jednoczesnego podłączenia do macierzy co najmniej 60 serwerów (VMware ESX 5.1.0 i starszych, MS Windows 2012, HP-UX, AIX) w trybie wysokiej dostępności (co najmniej dwoma ścieżkami) bez konieczności dokupowania dodatkowych licencji.

Obsługa wielu kanałów I/O (Multipathing). Automatyczne przełączanie kanału I/O w wypadku awarii ścieżki dostępu serwerów do macierzy z utrzymaniem ciągłości dostępu do danych. Wymaga się, aby macierz była wyposażona w odpowiednie licencje do obsługi ww. funkcjonalności.

Wsparcie co najmniej dla posiadanych przez Zamawiającego systemów : MS Windows 2008, VMware ESX wraz z oprogramowaniem Site Recovery Manager, RedHat Linux 6.5 SUSE/SLES 10, HP-UX, AIX.

7




18. Serwisowalność i redundancja

Możliwość uaktualniania oprogramowania (firmware’u) macierzy bez przerywania pracy systemu.

Wymiana elementów systemu w trybie „Hot-Swap”, a w szczególności takich, jak: kontroler(y), zasilacz(e), wentylatory.

Macierz przystosowana do napraw w miejscu zainstalowania oraz wymiany elementów bez konieczności jej wyłączania.

Brak pojedynczego punktu awarii, który powodowałby brak dostępu do danych. Pełna redundancja macierzy, w szczególności zdublowanie kontrolerów, zasilaczy i wentylatorów.

Macierz musi umożliwiać zdalne zarządzanie macierzą oraz automatyczne informowanie centrum serwisowego o awarii.

Producent macierzy musi posiadać lokalną organizację serwisową dysponującą certyfikatem ISO 9001. lub równoważnym. Za równoważny Zamawiający uzna certyfikat potwierdzający, że organizacja serwisowa prowadzi działalność w oparciu o wdrożony system zarządzania jakością

19. Zarządzanie Zarządzanie macierzą z poziomu pojedynczego interfejsu graficznego. Wymagane jest stałe monitorowanie stanu macierzy oraz możliwość konfigurowania jej zasobów dyskowych.

Monitorowanie wydajności macierzy według parametrów takich jak: przepustowość oraz liczba operacji I/O dla interfejsów, grup dyskowych, dysków logicznych (LUN). Wymaga się, aby macierz była wyposażona w odpowiednie licencje do obsługi ww. funkcjonalności.

20. Wewnętrzne kopie danych

Możliwość dokonywania na żądanie tzw. migawkowej kopii danych (snapshot, point-in time) w ramach macierzy za pomocą wewnętrznych kontrolerów macierzowych. Kopia migawkowa wykonuje się bez alokowania całej przestrzeni dyskowej na potrzeby kopii. Zajmowanie dodatkowej przestrzeni dyskowej następuję w momencie zmiany danych na dysku źródłowym lub na jego kopii.

8




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.


21. Możliwość migracji danych w obrębie macierzy

Macierz musi umożliwiać migrację danych, bez przerywania do nich dostępu, pomiędzy różnymi warstwami technologii dyskowych: SASD, SAS i Nearline SAS oraz różnych poziomów RAID. Zmiany te muszą się odbywać wewnętrznymi mechanizmami macierzy.

Aktualnie dostarczenie licencji na tę funkcjonalność nie jest wymagane. Możliwość rozbudowy o taką funkcjonalność w przyszłości.

Macierz musi umożliwiać zdefiniowanie zasobu LUN, który fizycznie będzie znajdował się na minimum 3 typach dysków obsługiwanych przez macierz (SSD, SAS, NL SAS), a jego części będą automatycznie i transparentnie dla korzystającego z tego LUNa serwera realokowane w trybie online na podstawie analizy ruchu w segmentach nie większych niż 128MB.Aktualnie licencja na tę funkcjonalność nie jest wymagana. Możliwość rozbudowy o taką funkcjonalność w przyszłości.

22. Mechanizm typu Thin Provisioning

Macierz musi mieć możliwość udostępniania zasobów dyskowych do serwerów w trybie tradycyjnym, jak i w trybie typu Thin Provisioning.


23. Replikacja danych Możliwość zdalnej replikacji danych typu on-line do 9




innej macierzy tej samej rodziny. Replikacja wykonywana na poziomie kontrolerów, bez obciążania serwerów oraz innych urządzeń podłączonych do macierzy. Dostępna replikacja w trybie synchronicznym i asynchronicznym.

Aktualnie licencja na tę funkcjonalność nie jest wymagana. Możliwość rozbudowy o taką funkcjonalność w przyszłości.

24. Dodatkowe Usługi do wykonania:- instalacja i konfiguracja półek dyskowych- instalacja dysków twardych- aktualizacja FW półek dyskowych i dysków (zgodnie z najnowszą dostępną w dniu składania ofert wersją)- konfiguracja grup dyskowych i wirtualnych dysków, wg. wskazań Zamawiającego

26. Gwarancja 3 letnia gwarancja obejmująca całość dostarczonego sprzętu oraz oprogramowania w trybie 24h/7 dni w tygodniu.

Gwarantowany czas naprawy dla sprzętu – 6 godzin.

W przypadku uszkodzenia nośnika danych (dysku), uszkodzone nośniki przechodzą na własność Zamawiającego.

Wymagane jest prawo do nowych wersji oraz poprawek oprogramowania dostarczonego wraz ze sprzętem przez cały okres gwarancji

Tabela 3. Infrastruktura blade


1. Nazwa producenta


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

10




obudowach, zasilacze i wentylatory).

5.

Rodzaj obsługiwanych serwerów

Możliwość umieszczania w ramach jednej infrastruktury wszystkich dostarczanych typów serwerów blade wyspecyfikowanych w Tabeli 5 i Tabeli 6 w układzie mieszanym, także serwerów blade z procesorami o architekturze RISC lub EPIC (serwery takie nie są przedmiotem zamówienia, ale muszą być dostępne do rozbudowy).

6. Sposób agregacji/ wyprowadzeń sygnałów LAN

Każda infrastruktura musi posiadać minimum 2 przełączniki typu 10Gb Ethernet wyprowadzające sygnały z minimum 2 portów sieciowych 10Gb na serwerach. Urządzenia te muszą umożliwiać agregację połączeń LAN w infrastrukturze blade i muszą umożliwiać wyprowadzenie sygnałów LAN z infrastruktury z zachowaniem redundancji połączeń. Każdy przełącznik powinien posiadać minimum 8 portów 10Gb przygotowanych do obsadzenia wkładkami SFP+. Wraz z przełącznikami należy dostarczyć minimum 16 wkładek SFP 10Gb RJ45 (po 8 sztuk na przełącznik).

Jeśli w serwerze znajdują się dodatkowe karty LAN (oprócz wymaganych portów 10Gb), należy uwzględnić odpowiednie przełączniki LAN w celu wyprowadzenia dodatkowych portów na zewnątrz obudowy.

7. Sposób agregacji/ wyprowadzeń sygnałów FC

Każda infrastruktura musi posiadać minimum dwa przełączniki typu 8Gb Fibre-Channel wyprowadzające sygnały z minimum 2 portów FC na serwerach. Urządzenia te muszą umożliwiać agregację połączeń SAN w infrastrukturze blade i muszą umożliwiać wyprowadzenie sygnałów SAN z infrastruktury z zachowaniem redundancji połączeń. Każdy przełącznik musi posiadać minimum 6 zewnętrznych portów. Wszystkie porty muszą być aktywne.

Wraz z przełącznikami należy dostarczyć minimum 12 wkładek SFP+ 8Gb (po 6 sztuk na przełącznik).

8. Zarządzanie połączeniami LAN i SAN z serwerów blade

Możliwość przydzielania adresów MAC i WWN predefiniowanych przez producenta rozwiązania blade dla poszczególnych wnęk na serwery w infrastrukturze. Przydzielenie adresów musi powodować zastąpienie fizycznych adresów kart

11




Ethernet i Fibre-Channel na serwerze. Musi istnieć także możliwość przenoszenia przydzielonych adresów pomiędzy wnękami w obudowie. Funkcjonalność ta może być realizowana zarówno poprzez moduły LAN i SAN w infrastrukturze jak i poprzez dodatkowe oprogramowanie producenta serwerów blade. Dodatkowo dla sieci LAN musi istnieć możliwość stworzenia niezależnych połączeń VLAN tak aby między wydzielonymi sieciami nie było komunikacji. Wymagana jest możliwość boot’owania systemów operacyjnych zainstalowanych na poszczególnych serwerach blade bezpośrednio z macierzy w środowisku SAN. Wymagane wszystkie niezbędne licencje na opisaną funkcjonalność dla całej infrastruktury blade.

W przypadku sieci LAN, musi istnieć możliwość określenia pasma przepustowości pojedynczego portu LAN na serwerze od 100Mb/s do 10Gb/s.

9. Chłodzenie Każda z obudów na serwery wyposażona w zestaw redundantnych wiatraków (typ hot plug, czyli możliwość wymiany podczas pracy urządzenia) zapewniających chłodzenie dla maksymalnej liczby serwerów i urządzeń I/O zainstalowanych w obudowie blade. Wentylatory niezależne od zasilaczy, wymiana wentylatora (wentylatorów) nie może powodować konieczności wyłączenia zasilacza/zasilaczy.

10. Zasilanie Każda z obudów wyposażona w zestaw zasilaczy redundantnych typu Hot Plug. System zasilania zdolny do obsługi awarii połowy z zainstalowanych zasilaczy (dowolne N zasilaczy przy założeniu konfiguracji N + N), wymagane ciągłe dostarczenie mocy niezbędnej do zasilenia maksymalnej liczby serwerów i urządzeń I/O zainstalowanych w obudowie. Procesory serwerów winny pracować z nominalną, maksymalną częstotliwością.

Wymiana zasilacza nie może powodować konieczności odłączenia zewnętrznej infrastruktury zasilania (kabla zasilającego), jak również nie może powodować konieczności wyjęcia lub odłączenia wentylatorów (pojedynczego wentylatora lub modułu wentylatorów)

12




11. Inne standardy komunikacyjne

Możliwość instalacji switchy w standardzie InfiniBand.

12. Moduły zarządzające

Dwa redundantne, sprzętowe moduły zarządzające, moduły typu Hot Plug.

13. Kompatybilność Możliwość monitorowania infrastruktury serwerów blade za pomocą posiadanego przez Zamawiającego systemu monitorowania HP (Zamawiający nie wymaga licencji).

Pełna kompatybilność z istniejącą infrastrukturą SAN Zamawiającego, na którą składają się:

– przełączniki HP 8/40 SAN Switch HP AM870A 8/40 PowerPack+ 24-ports SAN switch

- przełączniki HP 8/24 SAN switch HP AJ821A B-series 8/24c Blade System San Switch

14. Gwarancja 3 letnia gwarancja w trybie 24/7 w miejscu instalacji na wszystkie elementy obudowy z gwarantowanym czasem naprawy 6h. Czas naprawy liczony jest od momentu zgłoszenia awarii.

15. Podstawowe operacje

Zdalne włączanie/wyłączanie/restart niezależnie dla każdego serwera

16. Udostępnianie napędów, CD-ROM, USB

Zdalne udostępnianie napędu CD-ROM/DVD/ISO na potrzeby każdego serwera z możliwością bootowania z w/w napędów

17. Sposób zarządzania Zdalny z poziomu przeglądarki internetowej, bez konieczności instalacji specyficznych komponentów programowych producenta sprzętu

18. Liczba jednoczesnych sesji zarządzania

Niezależny, równoległy dostęp do konsol tekstowych i graficznych wszystkich serwerów w ramach infrastruktury.

19. Zdalna identyfikacja Zdalna identyfikacja fizycznego serwera i obudowy za pomocą sygnalizatora optycznego

20. Dodatkowe cechy oprogramowania do zarządzania serwerami blade

• zautomatyzowane instalacje systemu operacyjnego z wykorzystaniem mechanizmu PXE (bootowanie z sieci)

• zautomatyzowane, personalizowane, zrównoleglone instalacje systemów operacyjnych oraz aplikacji z

13




wykorzystaniem tzw. plików odpowiedzi dostarczanych przez producenta oprogramowania użytkowego

• zautomatyzowane, zrównoleglone kopiowanie środowisk, połączone z natychmiastową personalizacją systemu

• zdalna dystrybucja oprogramowania,

• automatyczne wykrywanie i identyfikacja urządzeń zainstalowanych w ramach infrastruktury (serwery, obudowy blade, karty zarządzające) i prezentacja infrastruktury w postaci graficznej

• monitorowanie utylizacji następujących podzespołów serwera: procesor, pamięć, dyski twarde, interfejsy sieciowe

• Integracja z oprogramowaniem do wirtualizacji, w zakresie wykrywania hostów, wirtualnych maszyn na nich pracujących, możliwości sterowania wirtualnymi maszynami (start, stop, przejęcie konsoli graficznej)

21. Licencje Licencje na powyższą funkcjonalność na wszystkie serwery blade dostarczone w ramach zamówienia.

22. Dokumentacja Dokumentacja techniczna w języku polskim lub angielskim wystarczająca do użytkowania urządzenia.

Tabela 4. Serwer blade typ 1


1. Nazwa producenta


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 www.spec.org Zamawiający nie wymaga złożenia wraz z ofertą wyników w/w testów.

14




4. Pamięć RAM 1TB RAM

5. Sterownik dysków wewnętrznych

Macierzowy, RAID 0 ,1.

6. Dyski twarde Minimum dwa wewnętrzne dyski o sumarycznej pojemności użytkowej , 600GB, w RAID 1, 10K, 6Gbps, SAS 2.5" SFF. Możliwość obsługi dysków 2,5” o pojemności 146GB, 300GB, 600GB, 900GB.

7. Interfejsy sieciowe (LAN)

Minimum 4 Interfejsy sieciowe 10GbE z możliwością podzielenia każdego interfejsu na 4 karty sieciowe (posiadające własne adresy MAC oraz będące widoczne z poziomu systemu operacyjnego jako fizyczne karty sieciowe). Podział musi być niezależny od zainstalowanego na serwerze systemu operacyjnego/platformy wirtualizacyjnej.

8. Interfejsy FibreChannel SAN

Zainstalowane dwa interfejsy Fibre-Channel o prędkości 8Gb lub szybsze

9. Wspierane systemy operacyjne

- Microsoft Windows Server 2008 - Microsoft Windows Server 2008 R2, - Microsoft Windows Server 2012- Microsoft Windows Server 2012 R2- Red Hat Enterprise Linux 6 Server x64 Edition- SUSE LINUX Enterprise Server 10 for AMD64/EM64T- SUSE LINUX Enterprise Server 11 for AMD64/EM64T- SUSE LINUX Enterprise Server 11 with Xen for AMD64/EM64T- VMware ESX 4.1- VMware ESXi 4.1-VMware vSphere 5.0 (ESXi)- VMware vSphere 5.1 (ESXi)



15




Tabela 5. Serwer blade typ 2


1. Nazwa producenta


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 www.spec.org

Zamawiający nie wymaga złożenia wraz z ofertą wyników w/w testów.

4. Pamięć RAM 512 GB RAM

5. Sterownik dysków wewnętrznych

Macierzowy, RAID 0 ,1.

6. Dyski twarde Minimum dwa wewnętrzne dyski o sumarycznej pojemności użytkowej , 600GB, w RAID 1, 10K, 6Gbps, SAS 2.5" SFF Możliwość obsługi dysków 2,5” o pojemności 146GB, 300GB, 600GB, 900GB.

7. Interfejsy sieciowe (LAN)

Minimum 2 Interfejsy sieciowe 10GbE z możliwością podzielenia każdego interfejsu na 4 karty sieciowe (posiadające własne adresy MAC oraz będące widoczne z poziomu systemu operacyjnego jako fizyczne karty sieciowe). Podział musi być niezależny od zainstalowanego na serwerze systemu operacyjnego/platformy wirtualizacyjnej.




- Microsoft Windows Server 2008 - Microsoft Windows Server 2008 R2, - Microsoft Windows Server 2012- Microsoft Windows Server 2012 R2- Red Hat Enterprise Linux 6 Server x64 Edition- SUSE LINUX Enterprise Server 10 for AMD64/EM64T- SUSE LINUX Enterprise Server 11 for AMD64/EM64T- SUSE LINUX Enterprise Server 11 with Xen for AMD64/EM64T- VMware ESX 4.1- VMware ESXi 4.1

16




-VMware vSphere 5.0 (ESXi)- VMware vSphere 5.1 (ESXi)



Tabela 6. UPS do infrastruktury


1. Nazwa producenta


3. Nominalne napięcie wyjściowe (V)

230V AC

4. Częstotliwość wejściowa (auto sensing)

50/60 Hz + / - 3 Hz

5. Moc rzeczywista: 6000 VA / 5600W

6. Gniazda wyjściowe Cztery IEC 320 C19 Sześć IEC 320 C13

7. Zakres nominalnego napięcie wyjściowe

208-253V (230V)

8. Czas ładowania <3 godzin do 80% użytecznego naładowania,

<48 godzin do całkowitego naładowania

9. Możliwość zastosowania dodatkowych Zewnętrznych modułów baterii (EBM)

Minimum 1 zewnętrzny moduł baterii (EBM)

10. Komunikacja i zarządzanie

17




Port USB TAK

Port szeregowy RS-232

TAK

Port Ethernet Moduł umożliwiający zarządzanie, monitoring oraz diagnostykę poprzez sieć

Ochrona przed przepięciami i filtracja

TAK

11. Czas podtrzymania w zależności od obciążenia -przewidywany okres, w którym UPS będzie działać wyłącznie na baterii

min 15 minut przy 100 % obciążeniu- 6000VA

12. Wysokość (podana w jednostkach EIA)

4U (max. 7U z modułem rozszerzeń)

13. Gwarancja 3 letnia gwarancja w trybie 24/7 w miejscu instalacji z gwarantowanym czasem naprawy 72h. Czas naprawy liczony jest od momentu zgłoszenia awarii.

Tabela 7. UPS do macierzy


1. Nazwa producenta


3. Nominalne napięcie wyjściowe (V)

230V AC

4. Częstotliwość wejściowa (auto sensing)

50/60 Hz + / - 3 Hz

5. Moc rzeczywista: 7000 VA / 6300W

6. Gniazda wyjściowe Sześć IEC 320 C19

7. Zakres nominalnego 208-253V (230V)

18




napięcie wyjściowe

8. Czas ładowania <3 godzin do 80% użytecznego naładowania,

<48 godzin do całkowitego naładowania

9. Możliwość zastosowania dodatkowych Zewnętrznych modułów baterii (EBM)

Minimum 1 zewnętrzny moduł baterii (EBM)

10. Komunikacja i zarządzanie

Port USB TAK

Port szeregowy RS-232

TAK

Port Ethernet Moduł umożliwiający zarządzanie, monitoring oraz diagnostykę poprzez sieć

Ochrona przed przepięciami i filtracja

TAK

11. Czas podtrzymania w zależności od obciążenia -przewidywany okres, w którym UPS będzie działać wyłącznie na baterii

min 15 minut przy 100 % obciążeniu- 6000VA


5U (max. 8U z modułem rozszerzeń)


Tabela 8. Serwer typ 3 - stelażowy


19




1. Nazwa producenta


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 www.spec.org

Zamawiający nie wymaga złożenia wraz z ofertą wyników w/w testów

5. Liczba zainstalowanych procesorów

1, możliwość rozbudowy do 2 procesorów.

6. Pamięć RAM 256 GB RAM z możliwością rozbudowy do 512 GB, w tym do 192GB bez konieczności wymiany dostarczonych modułów

7. Sloty rozszerzeń Minimum 2 sloty PCI-Express Generacji 3, w tym jeden slot x16 (prędkość slotu – bus width) oraz minimum jedno gniazdo pełnej wysokości.

8. Dyski twarde 2 x dysk 300GB typu Hot Swap, SAS, 15 000 obr./min., możliwość rozbudowy do 8 dysków wewnątrz serwera.

9. Kontroler Kontroler macierzowy SAS wyposażony w pamięć cache 512MB oraz podtrzymywanie zawartości pamięci, zapewniający obsługę 8 napędów dyskowych SAS oraz obsługujący poziomy RAID 0/1/1+0/5

10. Interfejsy sieciowe LAN

Minimum 4 porty Ethernet 10/100/1000 Mb/s z funkcją Wake-On-LAN, RJ45



12. Napęd optyczny Wewnętrzny napęd DVD-ROM

13. Karta graficzna Zintegrowana karta graficzna

14. Porty 1 x szeregowy

20




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)


MS Windows Server, Red Hat Enterprise Linux, SUSE Linux Enterprise Server, VMware – posiadane przez Zamawiającego

21






Tabela 9. Szafa Rack 19”


1. Nazwa producenta



Minimum 42U

4. Wyposażenie Szafa wyposażona w zdejmowane drzwi przednie i tylne zamykane na klucz, zdejmowane panele boczne oraz elementy stabilizujące, zabezpieczające szafę przed wywróceniem, elementy uziemiające, zestaw do optymalizacji przepływu powietrza w szafie.Dodatkowo wymagane jest dostarczenie „zaślepek” wypełniających puste miejsce w szafie o łącznej wysokości 20U.

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


1. Nazwa producenta


3. Konsola zarządzająca

Konsola składająca się z monitora (minimum 17’’), klawiatury i urządzenia wskazującego (track ball, touchpad). Zajmująca w szafie nie więcej niż 1U.

4. Przełącznik KVM Minimum 8 portów RJ45 do podłączenia z serweramiMożliwość instalacji za oferowaną konsolą zarządzającą, tak, aby całość rozwiązania zajmowała w szafie rack wysokość 1UMożliwość stackowania oferowanego switch’a KVM w

22




celu podłączenia do minimum 256 serwerów

5. Adaptery do przełącznika KVM

8 sztuk adapterów RJ45 do USB/VGA

6. Gwarancja 3 letnia gwarancja w trybie 24/7 w miejscu instalacji w miejscu instalacji z gwarantowanym czasem naprawy 72h. Czas naprawy liczony jest od momentu zgłoszenia awarii.

Tabela 11. Moduł zasilania PDU


1. Nazwa producenta


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


Tabela 12. Dyski zapasowe

23





I. Do posiadanej przez Zamawiającego macierzy HP StorgeWorks EVA 8100 S/N:GB8092239M

I.1. Dyski twarde typ 1 – 10 szt.

I.1.1 Nazwa producenta dysku

I.1.2 Part Number :

AG883A lub AG883ARlub równoważny, znajdujący się na liście podzespołów współpracujących z macierzą HP StorgeWorks EVA 8100

I.1.3 Interfejs dysku twardego

Fiber Channel ATA (FATA)

I.1.4 Pojemność dysku twardego

1.0TB

I.1.5 Typ dysku twardego

3,5 inch

I.1.6 Szybkość obrotowa 7 200RPM

I.1.7 Hot - swap Tak.

I.1.8 Dysk wewnętrzny w kasecie

Tak

I.1.9 Gwarancja 3 letnia gwarancja producenta w trybie 24/7 w miejscu instalacji



I.2.2 Part Number :

AG425A lub AG425AR lub równoważny, znajdujący się na liście podzespołów współpracujących z macierzą HP StorgeWorks EVA 8100


Fibre Channel

2.4 Pojemność dysku twardego

300GB


3,5 inch


24






Tak




I.3.2 Part Number :

AG804A lub AG804AR lub równoważny, znajdujący się na liście podzespołów współpracujących z macierzą HP StorgeWorks EVA 8100


Fibre Channel

I.3.4 Pojemność dysku twardego

450GB


3,5 inch




Tak


II. Do posiadanej przez Zamawiającego macierzy HP StorgeWorks EVA 8400 S/N: GB8101614N

II.1. Dyski twarde typ 4 – 5 szt.

II.1.1 Nazwa producenta dysku

II.1.2 Part Number :

AJ872Blub równoważny współpracujących z macierzą HP StorgeWorks EVA 8400

II.1.3 Interfejs dysku twardego

Fibre Channel

II.1.4 Pojemność dysku twardego

600GB

II.1.5 Typ dysku 3,5 inch

25




twardego

II.1.6 Szybkość obrotowa 15 000RPM

II.1.7 Hot - swap Tak.

II.1.8 Dysk wewnętrzny w kasecie

Tak

II.1.9 Gwarancja 3 letnia gwarancja producenta w trybie 24/7 w miejscu instalacji

II.2. Dyski twarde typ 5 – 5 szt.

II.2.1 Nazwa producenta dysku

II.2.2 Part Number :

AG803B lub równoważny współpracujących z macierzą HP StorgeWorks EVA 8400

II.2.3 Interfejs dysku twardego

Fibre Channel

II.2.4 Pojemność dysku twardego

450GB

II.2.5 Typ dysku twardego

3,5 inch

II.2.6 Szybkość obrotowa 15 000RPM

II.2.7 Hot - swap Tak.

II.2.8 Dysk wewnętrzny w kasecie

Tak

II.2.9 Gwarancja 3 letnia gwarancja producenta w trybie 24/7 w miejscu instalacji

26




Zadanie 2. Rozbudowa i wykonanie konsolidacji sieci SAN

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

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

W ramach zadania Wykonawca zrealizuje:

A. W odniesieniu do konsolidacji

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

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

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

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

5) Wykona podniesienie wersji mikrokodów switchy FC;6) Wykona podniesienie mikrokodów procesorów macierzy HP EVA 8100 i dysków;7) Przeprowadzi rekonfigurację przełączników sieci SAN;8) Wykona testy akceptacyjne:

a. testy niezawodnościowe dla wybranej grupy serwerów i macierzy dyskowych;b. testy funkcjonalne.

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

B. W odniesieniu do rozbudowy środowiska SAN.

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

27




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

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

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

28




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

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

Typ oprogramowania Liczba licencji

Serwerowy system operacyjny (licencjonowany na procesor) dedykowany dla środowisk o wysokim stopniu wirtualizacji 16Serwerowy system operacyjny (licencjonowany na procesor) dedykowany dla środowisk o niskim stopniu wirtualizacji 26Pakiet produktów narzędziowych do zarządzania i monitorowania serwerów oraz zarządzania wirtualizacją serwerów (licencjonowany na procesor) dedykowany dla środowisk o wysokim stopniu wirtualizacji

16

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

26

System bazodanowy dla środowiska testowo-rozwojowego (dla 100 użytkowników)

1

System bazodanowy typ 1 (licencjonowany na rdzeń procesora) 48System bazodanowy typ 2 (licencjonowany na rdzeń procesora) 36

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

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

Zamawiający nie ogranicza możliwości zaoferowania różnych licencji ale wymaga aby

spełniały następujące warunki:

29




1. Licencje muszą pozwalać na swobodne przenoszenie pomiędzy stacjami roboczymi

i serwerami (np. w przypadku wymiany sprzętu) oraz możliwość sublicencjonowania dla

jednostek organizacyjnych służb statystyki publicznej podległych Prezesowi GUS.

2. Licencjonowanie musi uwzględniać prawo do (w okresie przynajmniej 3 lat) bezpłatnej

instalacji udostępnianych przez producenta oprogramowania poprawek krytycznych

i opcjonalnych do zakupionej wersji oprogramowania.

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

4. Z uwagi na szeroki zakres funkcjonalny i terytorialny wdrożenia planowanego na bazie

zamawianego oprogramowania oraz konieczności minimalizacji kosztów związanych

z wdrożeniem, szkoleniami i eksploatacją systemów, Zamawiający wymaga oferty

zawierającej licencje, umożliwiające wykorzystanie wspólnych i jednolitych procedur

masowej instalacji, uaktualniania, zarządzania i monitorowania.

5. Wymagane jest zapewnienie możliwości korzystania z wcześniejszych wersji

zamawianego oprogramowania i korzystania z kopii zamiennych (możliwość kopiowania

oprogramowania na wiele urządzeń przy wykorzystaniu jednego standardowego obrazu

uzyskanego z nośników dostępnych w programach licencji grupowych), z prawem do

wielokrotnego użycia jednego obrazu dysku w procesie instalacji i tworzenia kopii

zapasowych.

6. W ramach umowy Wykonawca ma zapewnić udzielanie uprawnień na witrynie

producenta oprogramowania wskazanym przez Zamawiającego osobom (pracownikom

Zamawiającego) do pobierania kodu zamówionego oprogramowania i kluczy

licencyjnych.

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

W ramach zadania Wykonawca:

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

Przeprowadzi instalację systemu operacyjnego, Wykona instalację poprawek systemowych, Wykona instalację oprogramowania i sterowników dedykowanych dla danego typu

serwera przez producenta sprzętu,

30




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

Podłączy wskazane przez Zamawiającego zasoby macierzowe, Wykona instalację i konfigurację oprogramowania klienckiego modułu monitorowania

wydajności i dostępności, Wykona instalację i konfigurację oprogramowania klienckiego modułu zarządzania

konfiguracją

Wykona instalację i konfigurację oprogramowania bazodanowego

Opracuje Dokumentację powykonawczą

Serwerowy system operacyjny dedykowany dla środowisk o wysokim stopniu wirtualizacji

Licencja na oprogramowanie musi być przypisana do każdego procesora fizycznego na

serwerze. Liczba rdzeni procesorów i ilość pamięci nie mogą mieć wpływu na liczbę

wymaganych licencji. Licencja musi uprawniać do uruchamiania serwerowego systemu

operacyjnego (SSO) w środowisku fizycznym i nielimitowanej liczby wirtualnych środowisk serwerowego systemu operacyjnego za pomocą wbudowanych mechanizmów

wirtualizacji.

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

1. Możliwość wykorzystania co najmniej 2 logicznych procesorów oraz co najmniej 4

TB pamięci RAM w środowisku fizycznym.

2. Możliwość wykorzystywania 64 procesorów wirtualnych oraz 1TB pamięci RAM i

dysku o pojemności do 64TB przez każdy wirtualny serwerowy system

operacyjny.

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

uruchamiania do 2000 maszyn wirtualnych.

4. Możliwość migracji maszyn wirtualnych bez zatrzymywania ich pracy między

fizycznymi serwerami z uruchomionym mechanizmem wirtualizacji (hypervisor)

przez sieć Ethernet, bez konieczności stosowania dodatkowych mechanizmów

współdzielenia pamięci.

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

bez przerywania pracy.

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

przerywania pracy.

31




7. Automatyczna weryfikacja cyfrowych sygnatur sterowników w celu sprawdzenia,

czy sterownik przeszedł testy jakości przeprowadzone przez producenta systemu

operacyjnego.

8. Możliwość dynamicznego obniżania poboru energii przez rdzenie procesorów

niewykorzystywane w bieżącej pracy. Mechanizm ten musi uwzględniać specyfikę

procesorów wyposażonych w mechanizmy Hyper-Threading.

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

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

b. umożliwiają tworzenie w czasie pracy systemu migawek, dających

użytkownikom końcowym (lokalnym i sieciowym) prosty wgląd w poprzednie

wersje plików i folderów,

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

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

10. Wbudowany mechanizm klasyfikowania i indeksowania plików (dokumentów) w

oparciu o ich zawartość.

11. Wbudowane szyfrowanie dysków przy pomocy mechanizmów posiadających

certyfikat FIPS 140-2 lub równoważny wydany przez instytucję lub firmę

upoważnioną do wydawania certyfikatu bezpieczeństwa danych. Za równoważny

Zamawiający uzna certyfikat potwierdzający bezpieczeństwo danych .

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

ASP.NET.

13. Wbudowana zapora internetowa (firewall) z obsługą definiowanych reguł dla

ochrony połączeń internetowych i intranetowych.

14. Graficzny interfejs użytkownika.

15. Zlokalizowane w języku polskim, co najmniej następujące elementy: menu,

przeglądarka internetowa, pomoc, komunikaty systemowe.

16. Możliwość zmiany języka interfejsu po zainstalowaniu systemu, dla co najmniej 4

języków poprzez wybór z listy dostępnych lokalizacji.

17. Wsparcie dla większości powszechnie używanych urządzeń peryferyjnych

(drukarek, urządzeń sieciowych, standardów USB, Plug&Play).

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

19. Dostępność bezpłatnych narzędzi producenta systemu umożliwiających badanie i

wdrażanie zdefiniowanego zestawu polityk bezpieczeństwa.

20. Pochodzący od producenta systemu serwis zarządzania prawami do informacji w

dokumentach (Digital Rights Management).32




21. Możliwość implementacji następujących funkcjonalności bez potrzeby

instalowania dodatkowych produktów (oprogramowania) innych producentów

wymagających dodatkowych licencji:

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

b. Usługi katalogowe oparte o LDAP i pozwalające na uwierzytelnianie

użytkowników stacji roboczych, bez konieczności instalowania dodatkowego

oprogramowania na tych stacjach, pozwalające na zarządzanie zasobami w

sieci (użytkownicy, komputery, drukarki, udziały sieciowe) z możliwością

wykorzystania następujących funkcji:

a. Podłączenie SSO do domeny w trybie offline – bez dostępnego połączenia

sieciowego z domeną,

b. Ustanawianie praw dostępu do zasobów domeny na bazie sposobu

logowania użytkownika – na przykład typu certyfikatu użytego do

logowania,

c. Odzyskiwanie przypadkowo skasowanych obiektów usługi katalogowej z

mechanizmu kosza.

c. Zdalna dystrybucja oprogramowania na stacje robocze,

d. Praca zdalna na serwerze z wykorzystaniem terminala (cienkiego klienta) lub

odpowiednio skonfigurowanej stacji roboczej,

e. Centrum Certyfikatów (CA), obsługa klucza publicznego i prywatnego

umożliwiające:

a. Dystrybucję certyfikatów poprzez http,

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

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

domen.

f. Szyfrowanie plików i folderów,

g. Szyfrowanie połączeń sieciowych pomiędzy serwerami oraz serwerami i

stacjami roboczymi (IPSec),

h. Możliwość tworzenia systemów wysokiej dostępności (klastry typu failover)

oraz rozłożenia obciążenia serwerów,

i. Serwis udostępniania stron WWW,

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

k. Wbudowane usługi VPN pozwalające na zestawienie nielimitowanej liczby

równoczesnych połączeń i niewymagające instalacji dodatkowego

33




oprogramowania na komputerach z systemem Windows posiadanych przez

Zamawiającego,

l. Wbudowane mechanizmy wirtualizacji (Hypervisor) pozwalające na

uruchamianie do 1000 aktywnych środowisk wirtualnych systemów

operacyjnych. Wirtualne maszyny w trakcie pracy i bez zauważalnego

zmniejszenia ich dostępności mogą być przenoszone pomiędzy serwerami

klastra typu failover z jednoczesnym zachowaniem pozostałej funkcjonalności.

Mechanizmy wirtualizacji mają zapewnić wsparcie dla:

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

wirtualnych,

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

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

d. Nielimitowanej liczby jednocześnie przenoszonych maszyn wirtualnych

pomiędzy węzłami klastra,

e. Możliwości wirtualizacji sieci z zastosowaniem przełącznika, którego

funkcjonalność może być rozszerzana jednocześnie poprzez

oprogramowanie kilku innych dostawców poprzez otwarty interfejs API,

f. Możliwości kierowania ruchu sieciowego z wielu sieci VLAN bezpośrednio

do pojedynczej karty sieciowej maszyny wirtualnej (tzw. trunk mode).

22. Możliwość automatycznej aktualizacji w oparciu o poprawki publikowane przez

producenta wraz z dostępnością bezpłatnego rozwiązania producenta SSO

umożliwiającego lokalną dystrybucję poprawek zatwierdzonych przez

administratora, bez połączenia z siecią Internet.

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

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

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

administracji przez skrypty.

26. Możliwość zarządzania przez wbudowane mechanizmy zgodne ze standardami

WBEM oraz WS-Management organizacji DMTF.

Serwerowy system operacyjny dedykowany dla środowisk o niskim stopniu wirtualizacji


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 34




operacyjnego (SSO) w środowisku fizycznym i dwóch wirtualnych środowisk serwerowego systemu operacyjnego za pomocą wbudowanych mechanizmów

wirtualizacji.

Serwerowy system operacyjny (SSO) musi posiadać wbudowane cechy takie jak podano

w opisie przeznaczonym dla serwerowego systemu operacyjnego dla środowisk o

wysokim stopniu wirtualizacji.

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


serwerze zarządzanym. Liczba rdzeni procesorów i ilość pamięci nie mogą mieć wpływu na

liczbę wymaganych licencji. Licencja musi uprawniać do zarządzania i monitorowania

nielimitowaną liczbą wirtualnych środowisk serwerowego systemu operacyjnego. za

pomocą wbudowanych mechanizmów wirtualizacji.

Pakiet narzędziowy musi obejmować wszystkie funkcje zawarte w opisanych poniżej

modułach:

1) System zarządzania infrastrukturą i oprogramowaniem

2) System zarządzania komponentami

3) System zarządzania środowiskami wirtualnym

4) System tworzenia kopii zapasowych

5) System automatyzacji zarządzania środowisk IT

6) System zarządzania incydentami i problemami

7) Ochrona antymalware

1) System zarządzania infrastrukturą i oprogramowaniem

System zarządzania infrastrukturą i oprogramowaniem musi spełniać następujące

wymagania poprzez natywne dla niego mechanizmy, bez użycia dodatkowych aplikacji.

1. Inwentaryzacja i zarządzanie zasobami:

35




b. Inwentaryzacja zasobów serwera powinna się odbywać w określonych przez

administratora systemu interwałach czasowych. System powinien mieć możliwość

odrębnego planowania inwentaryzacji sprzętu i oprogramowania,

c. Inwentaryzacja sprzętu powinna się odbywać przez pobieranie informacji

z interfejsu WMI, komponent inwentaryzacyjny powinien mieć możliwość

konfiguracji w celu ustalenia informacji, o jakich podzespołach będą

przekazywane dane do systemu ,

d. Inwentaryzacja oprogramowania powinna skanować zasoby dyskowe przekazując

dane o znalezionych plikach do systemu w celu identyfikacji oprogramowania

oraz celów wyszukiwania i gromadzenia informacji o szczególnych typach plików

(np. pliki multimedialne: wav, mp3, avi, xvid),

e. System powinien posiadać własną bazę dostępnego na rynku komercyjnego

oprogramowania, pozwalającą na identyfikację zainstalowanego i użytkowanego

oprogramowania. System powinien dawać możliwość aktualizacji tej bazy przy

pomocy konsoli administratora oraz automatycznie przez aktualizacje ze stron

producenta,

f. Informacje inwentaryzacyjne powinny być przesyłane przy pomocy plików

różnicowych w celu ograniczenia ruchu z agenta do serwera.

2. Użytkowane oprogramowanie – pomiar wykorzystania

a. System powinien mieć możliwość zliczania uruchomionego oprogramowania

w celu śledzenia wykorzystania,

b. Reguły dotyczące monitorowanego oprogramowania powinny być tworzone

automatycznie przez skanowanie oprogramowania uruchamianego.

3. System powinien dostarczać funkcje dystrybucji oprogramowania, dystrybucji

i zarządzania aktualizacjami, instalacji/aktualizacji systemów operacyjnych.

4. Definiowanie i sprawdzanie standardu serwera:

a. System powinien posiadać komponenty umożliwiające zdefiniowanie i okresowe

sprawdzanie standardu serwera, standard ten powinien być określony zestawem

reguł sprawdzających definiowanych z poziomu konsoli administracyjnej,

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

- stan usługi

- obecność poprawek (Hotfix)

- WMI

- rejestr systemowy

36




- system plików

- Active Directory

- SQL (query)

- Metabase

5. Raportowanie, prezentacja danych:

a. System powinien posiadać komponent raportujący oparty o technologie webową

(wydzielony portal z raportami) i/lub wykorzystujący mechanizmy raportujące

dostarczane wraz z silnikami bazodanowymi, np. SQL Reporting Services,

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

- Sprzęt (inwentaryzacja)

- Oprogramowanie (inwentaryzacja)

- Oprogramowanie (wykorzystanie)

- Oprogramowanie (aktualizacje, w tym system operacyjny)

c. System powinien umożliwiać budowanie stron z raportami w postaci tablic

(dashboard), na których może znajdować się więcej niż jeden raport,

d. System powinien posiadać konsolę administratora, w postaci programu

do zainstalowania na stacjach roboczych, obsługującą wszystkie funkcje systemu,

2) System zarządzania komponentami

System zarządzania komponentami musi udostępniać funkcje pozwalające na budowę

bezpiecznych i skalowalnych mechanizmów zarządzania komponentami IT spełniając

następujące wymagania:

1. Architektura:

a. Serwery zarządzające muszą mieć możliwość publikowania informacji

o uruchomionych komponentach w usługach katalogowych, informacje te powinny

być dostępne dla klientów systemu w celu automatycznej konfiguracji,

b. Możliwość budowania struktury wielopoziomowej (tiers) w celu separacji pewnych

grup komputerów/usług,

c. System uprawnień musi być oparty o role (role based security), użytkownicy

i grupy użytkowników w poszczególnych rolach powinny być pobierane z usług

katalogowych,

d. Możliwość definiowania użytkowników do wykonywania poszczególnych zadań

na klientach i serwerze zarządzającym, w tym zdefiniowany użytkownik domyślny,

37




e. Uwierzytelnianie klientów na serwerze zarządzającym przy pomocy certyfikatów

w standardzie X.509, z możliwością odrzucania połączeń od klientów

niezaakceptowanych,

f. Kanał komunikacyjny pomiędzy klientami a serwerem zarządzającym powinien

być szyfrowany,

g. Możliwość budowania systemu w oparciu o łącza publiczne - Internet (bez

konieczności wydzielania kanałów VPN),

h. Wsparcie dla protokołu Ipv6,

i. System powinien udostępniać funkcje autodiagnostyczne, w tym: monitorowanie

stanu klientów, możliwość automatycznego lub administracyjnego restartu klienta,

możliwość reinstalacji klienta,

2. Audyt zdarzeń bezpieczeństwa

System musi udostępniać komponenty i funkcje pozwalające na zbudowanie systemu

zbierającego zdarzenia związane z bezpieczeństwem monitorowanych systemów

i gwarantować:

a. Przekazywanie zdarzeń z podległych klientów w czasie jak najbardziej zbliżonym

do rzeczywistego (dopuszczalne opóźnienia mogą pochodzić z medium

transportowego – sieć, oraz komponentów zapisujących i odczytujących),

b. Niskie obciążenie sieci poprzez schematyzację parametrów zdarzeń przed

wysłaniem, definicja schematu powinna być definiowana w pliku XML

z możliwością dodawania i modyfikacji,

3. Konfiguracja i monitorowanie

System musi umożliwiać zbudowanie jednorodnego środowiska monitorującego,

korzystając z takich samych zasad do monitorowania różnych komponentów,

a w tym:

a. Monitorowane obiekty powinny być grupowane (klasy) w oparciu o atrybuty, które

można wykryć na klientach systemu w celu autokonfiguracji systemu. Powinny

być wykrywane - co najmniej, atrybuty pobierane z:

- rejestru

- WMI

- OLEDB

- LDAP

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

38




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

nimi,

b. Na podstawie wykrytych atrybutów system powinien dokonywać autokonfiguracji

klientów, przez wysłanie odpowiadającego wykrytym obiektom zestawu

monitorów, reguł, skryptów, zadań,

c. Wszystkie klasy obiektów, monitory, reguły, skrypty, zadania i inne elementy

służące konfiguracji systemu muszą być grupowane i dostarczane w postaci

zestawów monitorujących, system powinien posiadać w standardzie zestawy

monitorujące, co najmniej dla:

- Windows Server /2008/2008R2/2012

- Active Directory 2008/2012

- Exchange 2007/2010

- Microsoft SharePoint 2003/2007/2010

- Microsoft SharePoint Services 3.0

- Microsoft SharePoint Foundation 2010

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

- Information Worker (Office, IExplorer, Outlook)

- IIS 6.0/7.0/7.5

- HP-UX 11i v2/v3

- Sun Solaris 9 (SPARC) oraz Solaris 10 (SPARCi x86)

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

- Novell SUSE Linux Enterprise Server 9, 10SP1, 11

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

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

niego,

e. System musi pozwalać na wykrycie oraz monitorowanie urządzeń sieciowych

(routery, przełączniki sieciowe) za pomocą SNMP v1, v2c oraz v3. System

monitorowania w szczególności powinien mieć możliwość zbierania

następujących informacji:

- interfejsy sieciowe

- porty

- sieci wirtualne (VLAN)

- grupy Hot Standby Router Protocol (HSRP)

39




f. System zarządzania musi mieć możliwość czerpania informacji z następujących

źródeł danych:

- SNMP (trap, probe)

- WMI Performance Counters

- Log Files (text, text CSV)

- Windows Events (logi systemowe)

- Windows Services

- Windows Performance Counters (perflib)

- WMI Events

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

- Unix/Linux Service

- Unix/Linux Log

g. Na podstawie uzyskanych informacji monitor powinien aktualizować status

komponentu, powinna być możliwość łączenia i agregowania statusu wielu

monitorów

4. Tworzenie reguł

a. w systemie zarządzania powinna mieć możliwość czerpania informacji

z następujących źródeł danych:

- Event based (text, text CSV, NT Event Log, SNMP Event, SNMP Trap, syslog,

WMI Event)

- Performance based (SNMP performance, WMI performance, Windows

performance)

- Probe based (scripts: event, performance)

b. System musi umożliwiać przekazywanie zebranych przez reguły informacji

do bazy danych w celu ich późniejszego wykorzystania w systemie, np. raporty

dotyczące wydajności komponentów, alarmy mówiące o przekroczeniu wartości

progowych czy wystąpieniu niepożądanego zdarzenia,

c. Reguły zbierające dane wydajnościowe muszą mieć możliwość ustawiania

tolerancji na zmiany, w celu ograniczenia ilości nieistotnych danych

przechowywanych w systemie bazodanowym. Tolerancja powinna mieć,

co najmniej dwie możliwości:

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

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

40




d. Monitory sprawdzające dane wydajnościowe w celu wyszukiwania wartości

progowych muszą mieć możliwość – oprócz ustawiania progów statycznych,

„uczenia” się monitorowanego parametru w zakresie przebiegu bazowego

„baseline” w zadanym okresie czasu,

e. System musi umożliwiać blokowanie modyfikacji zestawów monitorujących, oraz

definiowanie wyjątków na grupy komponentów lub konkretne komponenty w celu

ich odmiennej konfiguracji,

f. System powinien posiadać narzędzia do konfiguracji monitorów dla aplikacji

i usług, w tym:

- ASP .Net Application

- ASP .Net Web Service

- OLE DB

- TCP Port

- Web Application

- Windows Service

- Unix/Linux Service

- Process Monitoring

Narzędzia te powinny pozwalać na zbudowanie zestawu predefiniowanych

monitorów dla wybranej aplikacji i przyporządkowanie ich do wykrytej/działającej

aplikacji,

g. System musi posiadać narzędzia do budowania modeli aplikacji rozproszonych

(składających się z wielu wykrytych obiektów), pozwalając na agregację stanu

aplikacji oraz zagnieżdżanie aplikacji,

h. Z każdym elementem monitorującym (monitor, reguła, alarm) powinna być

skojarzona baza wiedzy, zawierająca informacje o potencjalnych przyczynach

problemów oraz możliwościach jego rozwiązania (w tym możliwość uruchamiania

zadań diagnostycznych),

i. System musi zbierać informacje udostępniane przez systemy operacyjne

Windows o przyczynach krytycznych błędów (crash) udostępnianych potem

do celów analitycznych,

j. System musi umożliwiać budowanie obiektów SLO (Service Level Object)

służących przedstawianiu informacji dotyczących zdefiniowanych poziomów SLA

(Service Level Agreement) przynajmniej dla: monitora (dostępność), i licznika

wydajności (z agregacją dla wartości – min, max, avg),41




5. Przechowywanie i dostęp do informacji:

a. Wszystkie informacje operacyjne (zdarzenia, liczniki wydajności, informacje

o obiektach, alarmy) powinny być przechowywane w bazie danych operacyjnych,

b. System musi mieć co najmniej jedną bazę danych z przeznaczeniem

na hurtownię danych do celów historycznych i raportowych. Zdarzenia powinny

być umieszczane w obu bazach jednocześnie, aby raporty mogłyby być

generowane w oparciu o najświeższe dane,

c. System musi mieć osobną bazę danych, do której będą zbierane informacje

na temat zdarzeń security z możliwością ustawienia innych uprawnień dostępu

do danych tam zawartych (tylko audytorzy),

d. System powinien mieć zintegrowany silnik raportujący niewymagający

do tworzenia raportów używania produktów firm trzecich. Produkty takie mogą być

wykorzystanie w celu rozszerzenia tej funkcjonalności,

e. System powinien mieć możliwość generowania raportów na życzenie oraz

tworzenie zadań zaplanowanych,

f. System powinien umożliwiać eksport stworzonych raportów co najmniej

do następujących formatów:

- XML

- CSV

- TIFF

- PDF

- XLS

- Web archive

6. Konsola systemu zarządzania:

a. Konsola systemu musi umożliwiać pełny zdalny dostęp do serwerów

zarządzających dając dostęp do zasobów zgodnych z rolą użytkownika

korzystającego z konsoli,

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

- w postaci programu do zainstalowania na stacjach roboczych, obsługującą

wszystkie funkcje systemu (konsola zdalna)

- w postaci web’owej dla dostępu do podstawowych komponentów

monitorujących z dowolnej stacji roboczej (konsola webowa).

42




c. Konsola zdalna powinna umożliwiać definiowanie każdemu użytkownikowi

własnych widoków, co najmniej w kategoriach:

- Alerts

- Events

- State

- Performance

- Diagram

- Task Status

- Web Page (dla użytkowników, którzy potrzebują podglądu tylko wybranych

elementów systemu).

d. Konsola musi umożliwiać budowanie widoków tablicowych (dashboard) w celu

prezentacji różnych widoków na tym samym ekranie,

e. Widoki powinny mieć możliwość filtrowania informacji, jakie się na nich znajdą

(po typie, ważności, typach obiektów), sortowania oraz grupowania podobnych

informacji, wraz z możliwością definiowania kolumn, jakie mają się znaleźć na

widokach „kolumnowych”,

f. Z każdym widokiem (obiektem w tym widoku) powinno być skojarzone menu

kontekstowe, z najczęstszymi operacjami dla danego typu widoku/obiektu,

g. Konsola musi zapewnić dostęp do wszystkich opcji konfiguracyjnych systemu

(poza opcjami dostępnymi w procesie instalacji i wstępnej konfiguracji), w tym:

- opcji definiowania ról użytkowników

- opcji definiowania widoków

- opcji definiowania i generowania raportów

- opcji definiowania powiadomień

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

- opcji instalacji/deinstalacji klienta

7. Wymagania dodatkowe

a. System musi dostarczać API lub inny system (web service, connector)

z publicznie dostępną dokumentacją pozwalający m.in. na:

- Budowanie konektorów do innych systemów, np. help-desk w celu

przekazywania zdarzeń czy alarmów (dwukierunkowo),

- Wykonywanie operacji w systemie z poziomu linii poleceń,

43




- Podłączenie rozwiązań innych producentów pozwalających na monitorowanie

w jednolity sposób systemów informatycznych niewspieranych natywnie przez

system zarządzania,

- Podłączenie do aplikacji biurowych pozwalające na integrację statycznych

modeli (np. diagramów Visio) z monitorowanymi obiektami, pozwalające

na wyświetlanie ich stanu na diagramie

3) System zarządzania środowiskami wirtualnym

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

1. Architektura

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

- serwera zarządzającego

- relacyjnej bazy danych przechowującej informacje o zarządzanych

elementach

- konsoli, instalowanej na komputerach operatorów

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

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

wirtualnych

- agenta instalowanego na zarządzanych hostach wirtualizacyjnych

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

b. System musi mieć możliwość tworzenia konfiguracji wysokiej dostępności (klaster

typu fail-over),

c. System musi pozwalać na zarządzanie platformami wirtualizacyjnymi co najmniej

trzech różnych dostawców.

2. Interfejs użytkownika

a. Konsola musi umożliwiać wykonywanie codziennych zadań związanych

z zarządzaniem maszynami wirtualnymi w sposób jak najbardziej intuicyjny,

b. Konsola musi umożliwiać grupowanie hostów i nadawanie uprawnień

poszczególnym operatorom do grup hostów,

c. Widoki hostów i maszyn wirtualnych powinny mieć możliwość zakładania filtrów,

pokazując tylko odfiltrowane elementy, np. maszyny wyłączone, maszyny

z systemem operacyjnym X,

d. Widok szczegółowy elementu w przypadku maszyny wirtualnej musi pokazywać

stan, ilość alokowanej pamięci i dysku twardego, system operacyjny, platformę 44




wirtualizacyjną, stan ostatniego zadania, oraz wykres utylizacji procesora

i podgląd na pulpit,

e. Konsola musi posiadać odrębny widok z historią wszystkich zadań oraz statusem

zakończenia poszczególnych etapów i całych zadań.

3. Scenariusze i zadania

a. Tworzenie maszyn wirtualnych – system musi umożliwiać stworzenie maszyny

wirtualnej w co najmniej dwóch trybach:

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

tworzenia maszyny,

2. Nadzorowany – gdzie operator tworzy maszynę korzystając z gotowego

wzorca (template), a wzorzec składa się z przynajmniej 3-ech elementów

składowych:

- profilu sprzętowego

- profilu systemu operacyjnego,

- przygotowanych dysków twardych,

b. Predefiniowane elementy muszą być przechowywane w bibliotece systemu

zarządzania,

c. System musi umożliwiać przenoszenie maszyny wirtualnej pomiędzy

zarządzanymi hostami:

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

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

d. System musi umożliwiać automatyczne, równomierne rozłożenie obciążenia

pomiędzy zarządzanymi hostami,

e. System musi umożliwiać wyłączenie hosta, gdy jego zasoby nie są konieczne

do pracy, w celu oszczędności energii. System powinien również umożliwiać

ponowne włączenie takiego hosta,

f. System musi umożliwiać przełączenie wybranego hosta w tryb „maintenance”

w przypadku wystąpienia awarii lub w celu przeprowadzenia planowanych prac

serwisowych. Uruchomienie tego trybu musi skutkować migracją maszyn na inne

hosty lub zapisaniem ich stanu,

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

h. System musi posiadać (bez potrzeby instalowania dodatkowego

oprogramowania) - możliwość wykrycia maszyny fizycznej w sieci i instalacje

na niej systemu operacyjnego wraz z platformą do wirtualizacji.

45




4. Wymagania dodatkowe

a. System musi informować operatora o potrzebie migracji maszyn, jeśli wystąpią

nieprawidłowe zdarzenia na hoście lub w innych maszynach wirtualnych mające

wpływ na ich pracę, np. awarie sprzętu, nadmierna utylizacja współdzielonych

zasobów przez jedną maszynę,

b. System musi dawać operatorowi możliwość implementacji w/w migracji w sposób

automatyczny bez potrzeby każdorazowego potwierdzania,

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

- utylizacja poszczególnych hostów,

- trend w utylizacji hostów,

- alokacja zasobów na centra kosztów,

- utylizacja poszczególnych maszyn wirtualnych,

- komputery-kandydaci do wirtualizacji

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

- wirtualnych maszyn

- usług

oraz profili dla:

- aplikacji

- serwera SQL

- hosta

- sprzętu

- systemu operacyjnego gościa

e. System musi umożliwiać tworzenie chmur prywatnych na podstawie dostępnych

zasobów (hosty, sieci, przestrzeń dyskowa, biblioteki zasobów),

f. System musi posiadać możliwość przygotowania i instalacji zwirtualizowanej

aplikacji serwerowej,

g. System musi pozwalać na skalowalność wirtualnego środowiska aplikacji

(poprzez automatyczne dodanie wirtualnej maszyny z aplikacją).

4) System tworzenia kopii zapasowych

System tworzenia i odtwarzania kopii zapasowych danych (backup) wykorzystujący

scenariusze tworzenia kopii na zasobach taśmowych lub dyskowych musi spełniać

następujące wymagania:

46




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

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

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

c. konsoli zarządzającej,

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

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

f. System kopii zapasowych musi wykorzystywać mechanizm migawkowych kopii –

VSS (Volume ShadowCopy Service).

2. System kopii zapasowych musi umożliwiać:

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

b. zapis danych na bibliotekach taśmowych.

3. System kopii zapasowych musi umożliwiać zdefiniowanie ochrony zasobów

krótkookresowej i długookresowej.

4. Oznacza to, iż krótkookresowe kopie mogą być tworzone w puli magazynowej,

a następnie po zdefiniowanym okresie, automatycznie przenoszone na biblioteki

taśmowe.

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

magazynowej.

6. Dane przechowywane w puli magazynowej muszą używać mechanizmów

oszczędzających wykorzystane miejsce dyskowe, takie jak pojedyncza instancja

przechowywania.

7. System kopii zapasowych powinien w przypadku wykonywania pełnej kopii

zapasowej kopiować jedynie te bloki, które uległy zmianie od ostatniej pełnej kopii.

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

a. danych plikowych,

b. danych aplikacyjnych,

c. stanu systemu (Systemstate),

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

9. System kopii zapasowej podczas wykonywania pełnej kopii zapasowej musi

uaktualniać chronione dane o dodatkowy punkt przywracania danych, minimalizując

ilość przesyłanych danych.

10. System kopii zapasowych musi umożliwiać rozwiązanie automatycznego

przenoszenia chronionych danych do zdalnej lokalizacji, wykorzystując przy tym

mechanizm regulacji maksymalnej przepustowości.

47




11. Agenci systemu kopii zapasowych muszą posiadać konfiguracje dotyczącą

zdefiniowania godzin pracy, a także dostępnej przepustowości w czasie godzin pracy

i poza godzinami pracy.

12. System kopii zapasowych musi rozpoznawać co najmniej aplikacje:

a. ze względu na tworzone logi transakcyjne:

- Microsoft Exchange Server

- Microsoft Office Sharepoint Server

- Microsoft SQL Server

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

- Microsoft Virtual Server 2005

- Microsoft Hyper-V server

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

zdefiniowanych portach.

14. Konsola powinna umożliwiać wykonywanie tworzenie określonych harmonogramów

wykonywania kopii zapasowych na chronionych agentach.

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

chronionych zasobów.

16. Zarządzanie agentami i zadaniami kopii zapasowych powinno być możliwe również

za pomocą linii poleceń.

17. System kopii zapasowych musi umożliwiać odzyskanie chronionych zasobów

plikowych przez użytkownika końcowego z poziomu zakładki „Poprzednie wersje”.

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

zapasowych.

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

w systemie kopii zapasowych.

20. Konsola powinna posiadać wbudowany system raportujący (m.in. raporty dotyczące

zużycia puli magazynowej, wykonania kopii zapasowych).

21. System kopii zapasowych musi umożliwiać przechowywanie danych w puli

magazynowej do 1 roku.

22. System kopii zapasowych musi umożliwiać przechowywanie danych na podłączonych

bibliotekach taśmowych powyżej 25 lat.

23. System kopii zapasowych musi umożliwiać synchronizacje przechowywanych kopii

zapasowych (kopie inkrementalne) z produkcyjnymi transakcyjnymi bazami danych

(bazy danych, poczta elektroniczna, portale intranetowe) na poziomie poniżej

48




30 minut. Kopie te muszą być tworzone w ciągu godzin pracy, w niezauważalny

dla użytkowników końcowych sposób.

24. System kopii zapasowych musi umożliwiać odtworzenie dowolnego 30 minutowego

kwantu czasu dla krytycznych aplikacji, takich jak bazy transakcyjne, poczta

elektroniczna, portale intranetowe.

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

a. lokalizacji oryginalnej

b. lokalizacji alternatywnej

c. w przypadku drugiego serwera kopii zapasowych (w centrum zapasowym)

do pierwszego serwera kopii zapasowych

5) System automatyzacji zarządzania środowisk IT

System automatyzacji zarządzania środowisk IT musi udostępniać bezskryptowe środowisko

standaryzujące i automatyzujące zarządzanie środowiskiem IT na bazie najlepszych praktyk.

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

incydentów w systemie.

2. System musi wspomagać automatyzację procesów zarządzania zmianami

konfiguracji środowisk IT.

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

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

5. System musi udostępniać mechanizmy workflow automatyzujące zadania

administracyjne wraz z graficznym interfejsem projektowania, budowy i

monitorowania worklow.

6. Wbudowane konektory zapewniające integrację narzędzi Microsoft System Center,

HP OpenView, IBM Tivoli i BMC Patrol do zarządzania oprogramowaniem i sprzętem.

7. Wbudowane (gotowe) workflow:

- Active Directory Password Reset

- Microsoft Cluster Patching

- Microsoft SQL Server Cluster Patching

- Microsoft SQL: Server Dump Copy Load

- Operations Manager Event Remediation

- Operations Manager Event Remediation and Enrichment

- Operations Manager Service Alert Testing

- VM Provisioning 49




- Working with FTP

- Operations Manager Tool Integration

- Operations Manager: Manager of Managers

- Operations Manager: Maintenance Windows

- Active Directory: New Employee Onboarding

- Operations Manager: Multi-Service Desk Integration

6) System zarządzania incydentami i problemami

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

1. System powinien posiadać rozwiązanie help-deskowe umożliwiające użytkownikom

zgłaszanie problemów technicznych oraz zapotrzebowanie na zasoby IT (np. nowa

maszyna wirtualna).

2. System musi mieć postać zintegrowanej platformy pozwalającej poprzez wbudowane

i definiowane mechanizmy w ramach przyjętej metodyki (np. MOF czy ITIL)

na zarządzanie incydentami i problemami oraz zarządzanie zmianą.

3. System powinien posiadać bazę wiedzy (CMDB) automatycznie zasilaną z takich

systemów jak: usługa katalogowa, system monitorujący, system do zarządzania

desktopami.

4. System musi udostępniać narzędzia efektywnego zarządzania dostępnością usług,

umożliwiających dostarczenie użytkownikom systemów SLA na wymaganym

poziomie.

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

zapewniać:

- Optymalizację procesów i ich prawidłową realizację poprzez predefiniowane

scenariusze, zgodne z najlepszymi praktykami i założoną metodyką

- Redukcję czasu rozwiązywania problemów z działaniem systemów poprzez

zapewnienie dotarcia właściwej, zagregowanej informacji do odpowiedniego

poziomu linii wsparcia

- Automatyczne generowanie opisu problemów na bazie alarmów i kojarzenie

zdarzeń w różnych komponentach systemu

- Wspomaganie procesów podejmowania decyzji poprzez integrację informacji

i logikę ich powiązania

50




- Planowanie działań prewencyjnych poprzez kolekcjonowanie informacji

o zachowaniach systemu w przypadku incydentów

- Raportowanie pozwalające na analizy w zakresie usprawnień systemu oraz

usprawnień procesów ich opieki serwisowej

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

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

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

7) Ochrona antymalware

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

1. Ochrona przed zagrożeniami typu wirusy, robaki, Trojany, rootkity, ataki typu phishing

czy exploity zero-day.

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

infrastrukturą i oprogramowaniem

3. Centralne zarządzanie politykami ochrony.

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

5. Mechanizmy wspomagające masową instalację.

6. Pakiet ma wykorzystywać platformę skanowania, dzięki której dostawcy

zabezpieczeń stosować mogą technologię „minifiltrów”, skanujących w czasie

rzeczywistym w poszukiwaniu złośliwego oprogramowania. Dzięki użyciu technologii

minifiltrów, system ma wykrywać wirusy, oprogramowanie szpiegowskie i inne pliki

przed ich uruchomieniem, dając dzięki temu wydajną ochronę przed wieloma

zagrożeniami, a jednocześnie minimalizując zaangażowanie użytkownika

końcowego.

7. Aparat ochrony przed złośliwym oprogramowaniem ma używać zaawansowanych

technologii wykrywania, takich jak analiza statyczna, emulacja, heurystyka

i tunelowanie w celu identyfikacji złośliwego oprogramowania i ochrony systemu.

Ponieważ zagrożenia stają się coraz bardziej złożone, ważne jest, aby zapewnić

nie tylko oczyszczenie systemu, ale również poprawne jego funkcjonowanie

po usunięciu złośliwego oprogramowania. Aparat ochrony przed złośliwym

oprogramowaniem w systemie ma zawierać zaawansowane technologie

oczyszczania, pomagające przywrócić poprawny stan systemu po usunięciu

złośliwego oprogramowania.

51




8. Generowanie alertów dla ważnych zdarzeń, takich jak atak złośliwego

oprogramowania czy niepowodzenie próby usunięcia zagrożenia.

9. Tworzenie szczegółowych raportów zabezpieczeń systemów IT o określonych

priorytetach, dzięki którym użytkownik może wykrywać i kontrolować zagrożenia

lub słabe punkty zabezpieczeń. Raporty mają obejmować nie tylko takie informacje,

jak ilość ataków wirusów, ale wszystkie aspekty infrastruktury IT, które mogą wpłynąć

na bezpieczeństwo firmy (np. ilość komputerów z wygasającymi hasłami, ilość

maszyn, na których jest zainstalowane konto „gościa”, itd.).

10. Pakiet ma umożliwiać zdefiniowanie jednej zasady konfigurującej technologie

antyszpiegowskie, antywirusowe i technologie monitorowania stanu jednego lub wielu

chronionych komputerów. Zasady obejmują również ustawienia poziomów alertów,

które można konfigurować, aby określić rodzaje alertów i zdarzeń generowanych

przez różne grupy chronionych komputerów oraz warunki ich zgłaszania.

11. System ochrony musi być zoptymalizowany pod kątem konfiguracji ustawień agenta

zabezpieczeń przy użyciu Zasad Grupy usługi katalogowej oraz dystrybucji

aktualizacji definicji.

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

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

kluczowych.

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


serwerze zarządzanym. Liczba rdzeni procesorów i ilość pamięci nie mogą mieć wpływu na

liczbę wymaganych licencji. Licencja musi uprawniać do zarządzania i monitorowania

dwoma wirtualnymi środowiskami serwerowego systemu operacyjnego. za pomocą

wbudowanych mechanizmów wirtualizacji.

Pakiet narzędziowy musi obejmować wszystkie funkcje zawarte w opisie dla pakietu

narzędziowego przeznaczonego dla środowisk o wysokim stopniu wirtualizacji.

52




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

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

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

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

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

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

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

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

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

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

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

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

53




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

54




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

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

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

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

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

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

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

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

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

23. SBD musi umożliwiać tworzenie procedur i funkcji z wykorzystaniem innych języków programowania (np. Java, C#), niż standardowo obsługiwany język zapytań danego SBD. System powinien umożliwiać tworzenie w tych językach m.in. 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.

55




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

56




- 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 m.in. 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).

57




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, m.in.: 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 m.in. 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).

58




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

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

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

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

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

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

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

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

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

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

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

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

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

59




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 m.in. 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).

60




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 m.in. 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).

61




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

W ramach zadania Wykonawca dostarczy licencje oprogramowania narzędziowego do wirtualizacji i wdroży to oprogramowanie na serwerach wskazanych przez Zamawiającego.Licencje powinny umożliwiać uruchomianie wirtualizacji na serwerach fizycznych o łącznej liczbie 16 procesorów fizycznych oraz uruchomienie jednej centralnej konsoli do zarządzania całym środowiskiem wirtualnym.

Zamawiający posiada w Podstawowym Centrum Przetwarzania Danych w budynku GUS trzy współpracujące ze sobą środowiska wirtualizacyjne VMware tworzące prywatną chmurę obliczeniową, zawierające łącznie ponad 150 serwerów wirtualnych.Podstawową wersją oprogramowania jest VMWare vSphere 5.1. Licencje tego systemu zostały zakupione w wyniku rozstrzygnięcia postępowań o zamówienie publiczne w trybie przetargów nieograniczonych między innymi w przetargu nr COIS-2/2010/SISP. Środowisko zwirtualizowane zostało, w ramach realizacji przetargu nr 14/SISP/PN/2013, zaktualizowane zgodnie z posiadanymi uprawnieniami licencyjnymi na zakupione oprogramowanie.

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

W ramach zadania Zamawiający wymaga :

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

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

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

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

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

62




Tabela 14. Wymagania funkcjonalne dotyczące oprogramowania wirtualizacyjnego

Lp.Charakterystyka

/Wymagania minimalneKonsolidacja:

1

Warstwa wirtualizacji powinna być rozwiązaniem systemowym tzn. powinna być zainstalowana bezpośrednio na sprzęcie fizycznym.

2

Rozwiązanie powinno zapewnić możliwość obsługi wielu instancji systemów operacyjnych na jednym serwerze fizycznym i powinno się charakteryzować maksymalnym możliwym stopniem konsolidacji sprzętowej.

3

Oprogramowanie do wirtualizacji musi zapewnić możliwość skonfigurowania maszyn wirtualnych z możliwością dostępu do 255GB pamięci operacyjnej.

4Oprogramowanie do wirtualizacji musi zapewnić możliwość skonfigurowania maszyn wirtualnych 1, 2, 3, 4, 5, 6, 7 i 8 procesorowych.

5

Rozwiązanie powinno umożliwiać łatwą i szybką rozbudowę infrastruktury o nowe usługi bez spadku wydajności i dostępności pozostałych wybranych usług.

6Rozwiązanie powinno w możliwie największym stopniu być niezależne od producenta platformy sprzętowej.

7

Rozwiązanie powinno wspierać następujące systemy operacyjne: Windows 7, Windows 8, Windows Server 2000, Windows Server 2003, Windows Server 2008, Windows Server 20012, SLES 10, SLES9, SLES8, Ubuntu 7.04, RHEL 5, RHEL 6, NetWare 6.5, Debian, CentOS, FreeBSD, Asianux, SCO OpenServer, SCO Unixware.

8

Rozwiązanie powinno umożliwiać przydzielenie większej ilości pamięci RAM dla maszyn wirtualnych niż fizyczne zasoby RAM serwera w celu osiągnięcia maksymalnego współczynnika konsolidacji.

9Rozwiązanie powinno posiadać centralną konsolę graficzną do zarządzania maszynami wirtualnymi usługami.

63




10Rozwiązanie powinno zapewnić możliwość monitorowania wykorzystania zasobów fizycznych infrastruktury wirtualnej.

11

Oprogramowanie do wirtualizacji powinno zapewnić możliwość wykonywania kopii zapasowych instancji systemów operacyjnych oraz ich odtworzenia w możliwie najkrótszym czasie.

12

Oprogramowanie do wirtualizacji powinno zapewnić możliwość wykonywania kopii migawkowych instancji systemów operacyjnych na potrzeby tworzenia kopii zapasowych bez przerywania ich pracy.

13

Oprogramowanie do wirtualizacji powinno zapewnić możliwość klonowania systemów operacyjnych wraz z ich pełną konfiguracją i danymi.

14

Oprogramowanie zarządzające musi posiadać możliwość przydzielania i konfiguracji uprawnień z możliwością integracji z usługami katalogowymi Microsoft Active Directory.

15

Oprogramowanie do wirtualizacji musi obsługiwać przełączenie ścieżek SAN (bez utraty komunikacji) w przypadku awarii jednej z dwóch ścieżek.

16Platforma wirtualizacyjna musi umożliwiać wykorzystanie procesorów fizycznych do 12 rdzeni na procesor.

17Rozwiązanie musi umożliwiać udostępnienie maszynie wirtualnej większej ilości zasobów dyskowych aniżeli fizycznie zarezerwowane.

18

System musi umożliwiać tworzenie standardowej konfiguracji dla hostów i zautomatyzowanie zgodności dla tych konfiguracji.

19

System powinien posiadać funkcjonalność wirtualnego przełącznika (switch) umożliwiającego tworzenie sieci wirtualnej w obszarze hosta i pozwalającego połączyć maszyny wirtualne w obszarze jednego hosta, a także na zewnątrz sieci fizycznej.

20 System powinien umożliwiać podłączenie wirtualnych przełączników firm trzecich.

21 Wirtualny przełącznik musi dostarczać usługę 64




prywatnych sieci VLAN (Private VLAN).Wysoka dostępność:

22Rozwiązanie powinno mieć możliwość przenoszenia maszyn wirtualnych w czasie ich pracy pomiędzy serwerami fizycznymi.

23

Rozwiązanie powinno zapewnić ciągłą pracę usług. Usługi krytyczne biznesowo powinny działać bez przestoju, czas niedostępności innych usług nie powinien przekraczać kilkunastu minut.

24

Powinna zostać zapewniona odpowiednia redundancja i nadmiarowość zasobów tak, by w przypadku awarii np. serwera fizycznego usługi na nim świadczone zostały przełączone na inne serwery infrastruktury.

25

Rozwiązanie powinno umożliwiać łatwe i szybkie ponowne uruchomienie systemów/usług w przypadku awarii poszczególnych elementów infrastruktury. Należy opisać wykorzystywany mechanizm.

26

Rozwiązanie powinno zapewnić bezpieczeństwo danych mimo poważnego uszkodzenia lub utraty sprzętu lub oprogramowania. Należy opisać wykorzystywany mechanizm.

27

Rozwiązanie powinno zapewniać mechanizm bezpiecznego uaktualniania warstwy wirtualizacyjnej, hostowanych systemów operacyjnych (np. wgrywania patch-y) i aplikacji tak, aby zminimalizować ryzyko awarii systemu na skutek wprowadzenia zamiany. Należy opisać wykorzystywany mechanizm.

28

Rozwiązanie powinno zapewnić możliwość szybkiego wykonywania kopii zapasowych oraz odtwarzania usług. Proces ten nie powinien mieć wpływu na utylizację zasobów fizycznych infrastruktury wirtualnej. Należy opisać wykorzystywany mechanizm.

29 Rozwiązanie powinno zapewniać pracę bez przestojów dla wybranych maszyn wirtualnych, niezależnie od systemu operacyjnego oraz aplikacji, podczas awarii serwerów fizycznych, bez utraty danych i dostępności danych

65




podczas awarii serwerów fizycznych.

30

Rozwiązanie musi umożliwiać dodawanie i rozszerzanie dysków wirtualnych, procesorów i pamięci RAM podczas pracy wybranych systemów.Równoważenie obciążenia i przestoje serwisowe:

31

Czas planowanego przestoju usług związany z koniecznością prac serwisowych (np. rekonfiguracja serwerów, macierzy, switchy) powinien być ograniczony do minimum. Wymagana jest możliwość przenoszenia usług pomiędzy serwerami fizycznymi oraz wolumenami dyskowymi, bez przerywania pracy usług. Należy opisać wykorzystywany mechanizm.

32

Rozwiązanie powinno umożliwiać automatyczne równoważenie obciążenia serwerów fizycznych pracujących jak platforma dla infrastruktury wirtualnej. Należy opisać wykorzystywany mechanizm.Obsługa potrzeb biznesu:

33

Rozwiązanie powinno zapewnić możliwość szybkiego tworzenia i uruchamiania nowych usług wraz z ich pełną konfiguracją i preinstalowanymi narzędziami systemowymi w celu efektywnej obsługi wymagań biznesowych.

34

Rozwiązanie powinno zapewnić mechanizm wykonywania kopii – klonów systemów operacyjnych wraz z ich pełną konfiguracją i danymi.

66




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

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

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

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

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

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

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

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

a. Microsoft Windows Server 2003 SP2 b. Microsoft Windows Vista SP2 c. Microsoft Windows Server 2008 SP2 d. Microsoft Windows Server 2008 R2 e. Microsoft Windows Server 2012f. Microsoft Windows 7 SP1 g. Microsoft Windows 8

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

a. Linux - ext2, ext3, ext4, ReiserFS (Reiser3), JFS, XFS b. Unix - JFS, XFS, UFS c. BSD - UFS, UFS2 d. Solaris - UFS, ZFS e. Mac - HFS, HFS+ f. Windows - NTFS, FAT, FAT32

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

67




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

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

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

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

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

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

14. Dostęp do tej konsoli powinien być realizowany przez przeglądarkę WWW15. Rozwiązanie powinno mieć wbudowany mechanizm informowania o pomyślnym lub

niepomyślnym zakończeniu procesu archiwizacji poprzez email, zapis do Event Log’u Windows lub wysłanie komunikatu SNMP.

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

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

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

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

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

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

68




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

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

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

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

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

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

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

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

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

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

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

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

a. Ilość pamięci wirtualnych maszyn skompresowanej w locie przez hostyb. Wiek plików kopii migawkowych wirtualnych maszync. Zdarzenie zapisania na dysku obsługiwanym przez infrastrukturę

wirtualizacyjną (datastore) plików nie związanych z wirtualizacjąd. Zdarzenie utraty połączenia pomiędzy hostem a macierzą dyskowąe. Zdarzenie przepełnienia partycji file systemuf. Zdarzenie braku połączenia do serwera NFS

69




Zadanie 7. Realizacja szkoleń

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

a. Szkolenie dla administratorów serwerowego systemu operacyjnego

i) 7 osób

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

iii) program szkolenia - instalacja i konfiguracja serwerów opartych na zamawianym

systemie; monitorowanie i utrzymanie systemu; zarządzanie platformą

systemową za pomocą wbudowanego interpretera poleceń; implementacja usług

sieciowych oraz klastrów pracy bezawaryjnej; wdrożenie wbudowanych

mechanizmów wirtualizacji; implementacja usług katalogowych; konfigurowanie

bezpiecznego dostępu do danych.

b. Szkolenie dla administratorów oferowanej macierzy

i) 4 osoby

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

iii) program szkolenia - architektura, konfiguracja, zarządzanie, tworzenie

wolumenów, monitorowanie.

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

i) 4 osoby


iii) program szkolenia - zarządzanie i monitorowanie sprzętem, interpretacja logów,

uaktualnianie oprogramowania układowego, wgrywanie poprawek.

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

i) 4 osoby


iii) program szkolenia - instalacja i konfiguracja dostarczonego systemu zarządzania

infrastrukturą i oprogramowaniem; wykrywanie i organizacja zasobów;

70




zarządzanie ustawieniami klienta systemu; tworzenie zapytań i raportowanie

danych.

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

i) 4 osoby


iii) program szkolenia - architektura systemu zarządzania komponentami,

monitorowanie systemów serwerowych Windows i Linux; wykorzystanie

wbudowanych raportów; tworzenie własnych widoków.

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

i) 4 osoby


iii) program szkolenia - architektura instalacja i konfiguracja serwera baz danych;

omówienie baz danych i praca z plikami; opis obiektów bazy danych; tworzenie

kopii zapasowych, odtwarzanie i replikacja baz danych; bezpieczeństwo;

zarządzanie użytkownikami; optymalizacja; monitorowanie pracy.

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

i) 8 osób


iii) program szkolenia - projektowanie modeli bazy danych: koncepcyjnego,

logicznego, fizycznego; optymalizacja wydajności i zapytań do baz danych;

projektowanie transakcji; projektowanie obsługi danych xml; projektowanie

strategii bezpieczeństwa dotyczącej: programowania, wdrażania, działania

systemów bazodanowych.

h. Szkolenie dla administratorów środowiska wirtualizacyjnego

i) 4 osoby


71




iii) program szkolenia - instalacja i konfiguracja wirtualnego środowiska, zarządzanie

i administrowanie środowiskiem, wykonywanie kopii zapasowych.

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

i) 4 osoby


iii) program szkolenia - instalacja i konfiguracja produktów, zarządzanie i

administrowanie środowiskiem, wykonywanie backupu.

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

k. wszyscy uczestnicy szkolenia muszą otrzymać materiały szkoleniowe w języku

polskim, w formie papierowej lub elektronicznej w formacie PDF.

l. wszystkie szkolenia powinny być autoryzowanie przez producenta oferowanego

produktu (sprzętu lub oprogramowania). Zamawiający dopuszcza szkolenia

równoważne tj. zapewniające pozyskanie wiedzy i umiejętności na poziomie

zgodnym z określonymi w programach i materiałach szkoleniowych producenta.

m. wszyscy uczestnicy szkolenia otrzymają zaświadczenia potwierdzające ukończenie

szkolenia i posiadania odpowiednich kompetencji administratora.

n. Wykonawca pokryje wszelkie koszty związane z dojazdem, pobytem oraz

wyżywieniem i zakwaterowaniem wykładowców, którzy będą prowadzili szkolenie.

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

i. Szkolenia zostaną zorganizowane w hotelu/hotelach o standardzie co

najmniej 3-gwiazdkowym lub w ośrodku/ośrodkach konferencyjno-

szkoleniowych odpowiadających standardem hotelowi standardu co najmniej

3-gwiazdkowego, zgodnie z rozporządzeniem Ministra Gospodarki i Pracy z

dnia 19 sierpnia 2004 r. w sprawie obiektów hotelarskich i innych obiektów, w

których są świadczone usługi hotelarskie (Dz. U. z 2006 r. Nr 22, poz. 169, z

późn. zm.) oraz spełniające wymagania dla budynków zamieszkania

zbiorowego zgodnie z rozporządzeniem Ministra Infrastruktury z dnia 12

kwietnia 2002 r. w sprawie warunków technicznych, jakim powinny

odpowiadać budynki i ich usytuowanie (Dz. U. Nr 75, poz. 690, z późn. zm.).

72




ii. Wykonawca każdego dnia trwania szkolenia zapewni: dwie przerwy kawowe,

każda trwająca ok. 10 minut oraz jedną przerwę obiadową trwającą ok. 40

minut.

iii. Wykonawca zapewni każdego dnia szkolenia wyżywienie dla wszystkich

uczestników:

a. dostępne przez cały czas trwania szkolenia: kawa, herbata, butelkowana

woda mineralna gazowana i niegazowana, naturalne soki owocowe

(butelkowane lub w kartonach) oraz ciastka.

b. obiad – zupa, danie główne, surówki, owoce, herbata, kawa, butelkowana

woda mineralna, naturalne soki owocowe (butelkowane lub w kartonach);

czyste sztućce i zastawa (nie mogą być jednokrotnego użytku) – podany

w oddzielnym pomieszczeniu (strefie przeznaczonej do podawania

posiłków), które:

spełnia wymagania sanitarne wynikające z obowiązujących

przepisów,

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

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

mebli,

c. wykonawca zapewni każdemu uczestnikowi odpowiednio danie mięsne,

wegetariańskie lub bezglutenowe zgodnie ze zgłoszonym

zapotrzebowaniem w harmonogramie szkoleń.

p. Jeżeli wykonawca zaoferuje szkolenie poza Radomiem:

i. Wykonawca zapewni transport uczestników szkolenia spod siedziby CIS

Radom do miejsca przeprowadzenia szkolenia.

ii. Szkolenia zostaną zorganizowane w hotelu/hotelach o standardzie co

najmniej 3-gwiazdkowym lub w ośrodku/ośrodkach konferencyjno-

szkoleniowych odpowiadających standardem hotelowi standardu co najmniej

3-gwiazdkowego, zgodnie z rozporządzeniem Ministra Gospodarki i Pracy z

dnia 19 sierpnia 2004 r. w sprawie obiektów hotelarskich i innych obiektów, w

których są świadczone usługi hotelarskie (Dz. U. z 2006 r. Nr 22, poz. 169, z

późn. zm.) oraz spełniające wymagania dla budynków zamieszkania

zbiorowego zgodnie z rozporządzeniem Ministra Infrastruktury z dnia 12

kwietnia 2002 r. w sprawie warunków technicznych, jakim powinny

odpowiadać budynki i ich usytuowanie (Dz. U. Nr 75, poz. 690, z późn. zm.).

73




iii. Wykonawca każdego dnia trwania szkolenia zapewni: dwie przerwy kawowe,

każda trwająca ok. 10 minut oraz jedną przerwę obiadową trwającą ok. 40

minut.

iv. Wykonawca zapewni każdego dnia szkolenia wyżywienie dla wszystkich

uczestników:

a. dostępne przez cały czas trwania szkolenia: kawa, herbata, butelkowana

woda mineralna gazowana i niegazowana, naturalne soki owocowe

(butelkowane lub w kartonach) oraz ciastka.

b. obiad – zupa, danie główne, surówki, owoce, herbata, kawa, butelkowana

woda mineralna, naturalne soki owocowe (butelkowane lub w kartonach);

czyste sztućce i zastawa (nie mogą być jednokrotnego użytku) – podany

w oddzielnym pomieszczeniu (strefie przeznaczonej do podawania

posiłków), które:

spełnia wymagania sanitarne wynikające z obowiązujących

przepisów,

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

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

mebli,

c. wykonawca zapewni każdemu uczestnikowi odpowiednio danie mięsne,

wegetariańskie lub bezglutenowe zgodnie ze zgłoszonym

zapotrzebowaniem w harmonogramie szkoleń.

v. Wykonawca zapewni noclegi dla uczestników szkolenia, pomiędzy każdym z

dni szkolenia w hotelu/ ośrodku konferencyjno – szkoleniowym, w którym

realizowane będzie szkolenie, wraz ze śniadaniem oraz kolacją (pokoje

jednoosobowe lub dwuosobowe do pojedynczego wykorzystania, z węzłem

sanitarnym).

2. 14 dni od daty podpisania Umowy Wykonawca przedstawi Zamawiającemu do

akceptacji – harmonogram szkoleń przygotowany w porozumieniu z Zamawiającym

obejmujący:

a. programy szkoleń zawierające szczegółowe informacje o zakresie tematycznym i

rozkładzie zajęć dla poszczególnych szkoleń,

b. metodę i formę prowadzenia szkoleń,

74




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

szkolenia.

3. Wykonawca zobowiązany będzie do przeprowadzenia szkoleń zgodnie

z zatwierdzonym przez zamawiającego szczegółowym zakresem tematycznym

i harmonogramem szkoleń.

4. Zamawiający zastrzega sobie prawo do modyfikacji harmonogramu szkoleń,

z wytypowaniem na poszczególne cykle mniejszej lub większej liczby uczestników,

z zachowaniem ilości cykli szkoleń i sumarycznej liczby uczestników.

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

Zamawiającemu:

a. materiały szkoleniowe,

b. listy obecności,

c. listę wydanych zaświadczeń i komplet imiennych zaświadczeń dla wszystkich

uczestników, którzy ukończą szkolenia, pod warunkiem uczestnictwa w pełnym

wymiarze zajęć.

75

opz cz 2bip.stat.gov.pl/download/gfx/bip/pl/zamowieniapublicz… · web viewtitle opz cz 2 subject...

Documents