macierzowej dla Szpitala Wojewódzkiego

Transkrypt

Załącznik nr 7 do SIWZ
PARAMETRY TECHNICZNE I EKSPLOATACYJNE
na zakup infrastruktury serwerowo - macierzowej dla
Nowego Szpitala Wojewódzkiego
1. Specyfikacja techniczna sieci Storage Area Network
a. Wymagania ogólne
Zamawiający wymaga wdrożenia sieci SAN w architekturze "dual fabric" tj. dwóch
niezależnych od siebie sieci "fabric". Każde urządzenie korzystające z sieci SAN (serwer,
macierz dyskowa) musi zostać podłączone zarówno do jednej jak i do drugiej sieci w celu
zapewnienia redundancji połączeń na wypadek awarii. Podstawą działania sieci mają być dwa
niezależne od siebie przełączniki zabezpieczające sieć w przypadku awarii jednego z
przełączników.
b. Wymagania techniczne dla przełączników sieci SAN
Tabela 1.1 Specyfikacja techniczna przełączników i sieci SAN
Lp.
wymaganie
Opis
1.
Opis
Przełącznik FC musi być wykonany w technologii FC minimum 16
Gb/s i zapewniać możliwość pracy portów FC z prędkościami 16,
8, 4, 2 Gb/s w zależności od rodzaju zastosowanych wkładek SFP
2.
3.
Ilość sztuk
Ilość portów
4.
Typ portów
5.
Wydajność / prędkość
portów
Przełącznik FC musi mieć możliwość wymiany i aktywacji wersji
firmware’u (zarówno na wersję wyższą jak i na niższą) w czasie
pracy urządzenia.
Minimum dwa przełączniki SAN FC.
Minimum 24 porty fiber channel, 24 porty aktywne, gotowe do
pracy, obsadzone wkładkami 16 Gbps SFP+, SW, LC, multi
mode, gotowych do użycia (do podłączenia urządzeń serwerowomacierzowych do portów FC)
Możliwość konfiguracji portów typu : D_Port, E_Port, F_Port,
M_Port; Przełącznik musi mieć obsługę trybu NPIV.
2,4,8,16 Gbps. Automatyczne wykrywanie prędkości
podłączonego urządzenia
W przypadku obsadzenia portu FC za pomocą wkładki SFP
16Gb/s przełącznik musi umożliwiać pracę tego portu z
prędkością 16, 8 lub 4 Gb/s, przy czym wybór prędkości musi być
możliwy w trybie autonegocjacji.
W przypadku obsadzenia portu FC za pomocą wkładki SFP 8Gb/s
przełącznik musi umożliwiać pracę tego portu z prędkością 8, 4
lub 2 Gb/s, przy czym wybór prędkości musi być możliwy w trybie
autonegocjacji.
Wszystkie zaoferowane porty przełącznika FC muszą umożliwiać
działanie bez tzw. oversubscrypcji gdzie wszystkie porty w
maksymalnie rozbudowanej konfiguracji przełącznika mogą
pracować równocześnie z pełną prędkością 8Gb/s lub 16Gb/s w
zależności do zastosowanych wkładek FC
6.
Maksymalna
Minimum 384 Gbps w trybie end to end full-duplex
Nazwa zamówienia: „Dostawa wraz z instalacją infrastruktury serwerowo – macierzowej” – znak postępowania:
ZP/PN/35/2014
7.
zagregowana
Przepustowość
przełącznika
Agregacja połączeń
pomiędzy
przełącznikami
8.
Mechanizm
balansowania ruchu
9.
10.
Ilość buforów
Wkładki FC
11.
Port USB
12.
Zarządzanie
13.
Diagnostyka
14.
Mechanizmy
bezpieczeństwa
Możliwość agregacji do 8 połączeń 16 Gbps pomiędzy
przełącznikami
Maksymalna przepustowość : 128 Gbps dla zagregowanego
połączenia 8 linków 16 Gbps. W ramach zagregowanego
połączenia przełącznik musi zapewniać mechanizmy
równoważenia obciążenia portów.
Przełącznik FC musi wspierać mechanizm balansowania ruchu,
pomiędzy różnymi połączeniami o tym samym koszcie wewnątrz
wielodomenowych sieci fabric, przy czym balansowanie ruchu
musi odbywać się w oparciu o 3 parametry nagłówka ramki FC:
DID, SID i OXID
Przełącznik FC musi zapewniać jednoczesną obsługę
mechanizmów ISL Trunk oraz balansowania ruchu w oparciu o
DID/SID/OXID
8192 dynamicznie alokowanych buforów
Możliwość montażu i wymiany wkładek FC bez wyłączania
przełącznika
Obsługa wkładek :
16 Gbps SFP+, LC, SWL, LWL,ELWL
8Gbps SFP+, LC, SWL,LWL,ELWL
Dostarczone wkładki muszą być oryginalne certyfikowane przez
producenta przełącznika. Niedopuszczalne jest dostarczenie
niecertyfikowanych przez producenta urządzenia wkładek,
których montaż mógłby spowodować utratę gwarancji producenta
lub jakiekolwiek problemy konfiguracyjne.
Port USB umożliwiający zgranie logów przełącznika oraz wgranie
nowych wersji firmware przełącznika
Poprzez HTTP/HTTPS, poprzez SSH, obsługa SNMP v1/v3,
możliwość wysyłania logów na zewnętrzny serwer syslog,
Osobny interfejs sieciowy 10/100 Mbps Ethernet RJ-45
pozwalający na zarządzanie przełącznikiem
Port szeregowy (RJ-45) pozwalający na bezpośrednie
podłączenie się do przełącznika
Możliwość diagnozowania z poziomu przełącznika połączeń
światłowodowych, Możliwość pomiaru połączenia (prędkość,
opóźnienia, dystans), wbudowany generator przepływu danych,
możliwość wykonywania poleceń FC ping, Pathinfo (FC
traceroute), możliwość podglądu ramek, monitorowanie stanu
łącz, monitorowanie stanu urządzenia
Przełącznik FC musi wspierać następujące mechanizmy
zwiększające poziom bezpieczeństwa:
 mechanizm tzw. Fabric Binding, który umożliwia
zdefiniowanie listy kontroli dostępu regulującej prawa
przełączników FC do uczestnictwa w sieci fabric
 uwierzytelnianie (autentykacja) przełączników w sieci Fabric
za pomocą FCAP
 uwierzytelnianie (autentykacja) urządzeń końcowych w sieci
Fabric za pomocą protokołu DH-CHAP
 szyfrowanie połączenia z konsolą administracyjną. Wsparcie
dla SSHv2.
 definiowanie wielu kont administratorów z możliwością
ograniczenia ich uprawnień za pomocą mechanizmu tzw.
RBAC (Role Based Access Control)
 definiowane kont administratorów w środowisku RADIUS i
ZP/PN/35/2014





16.
Zajętość U w szafie
RACK
Pobór prądu
17.
Zasilanie
18.
Licencje na przełącznik
19.
Konfiguracja
przełączników
20.
Dokumentacja
powykonawcza
15.
LDAP
szyfrowanie komunikacji narzędzi administracyjnych za
pomocą SSL/HTTPS
obsługa SNMP v1 oraz v3
IP Filter dla portu administracyjnego przełącznika
wgrywanie nowych wersji firmware przełącznika FC z
wykorzystaniem bezpiecznych protokołów SCP oraz SFTP
wykonywanie kopii bezpieczeństwa konfiguracji przełącznika
FC z wykorzystaniem bezpiecznych protokołów SCP oraz
SFTP
Wysokość 1U
Max 80 W przy obsadzonych wszystkich portach FC wkładkami
16Gbit SW
Zamontowane dwa redundantne zasilacze, które można
wymieniać w przypadku awarii bez wyłączania przełącznika
Licencja pozwalająca na połączenie przełączników w stos
Licencja pozwalająca na agregację kilku połączeń FC w jedno
logiczne połączenie
Każdy przełącznik w sieci SAN musi mieć nadany unikalny
identyfikator ID (domain ID). Interfejsy zarządzające muszą być
wpięte do odrębnego VLAN-u zarządzającego. Adres IP interfejsu
zarządzającego oraz ustawienia sieciowe zostaną wskazane
wykonawcy na etapie instalacji i wdrożenia. Nazwa przełącznika
musi zostać ustalona z Zamawiającym na etapie wdrożenia.
Wykonawca zobowiązany jest do opisania przełączników poprzez
naklejenie czytelnej nalepki z nadaną nazwą urządzenia.
Dla każdego podłączonego urządzenia musi zostać
stworzony alias urządzenia. Zamawiający wymaga korzystania w
konfiguracji z zon opartych o wwn-y urządzeń i aliasy. Nie
dopuszcza tworzenia zon opartych o numery portów. Konfiguracja
musi zostać wykonana wg. wytycznych producenta sprzętu oraz
dobrych zasad producenta.
Dokumentacja musi zawierać zwięzły techniczny opis
o
konfiguracji przełączników (min. : nazwa, konfiguracja sieciowa,
model, numer seryjny przełącznika, numery seryjne wkładek,
informację o tym gdzie przełącznik został zamontowany,
informację o urządzeniach podpiętych do poszczególnych portów
FC, jeżeli zostały zmienione jakieś parametry domyślne sieci
fabric to powinna być informacja co zostało zmienione, jeżeli
zagregowano porty FC to też powinna być informacja itp.).
W dokumentacji powykonawczej musi być zawarta
informacja dotycząca tego gdzie i jak zgłaszać problemy z
urządzeniem w okresie gwarancji (telefon do wykonawcy, osoba
kontaktowa, telefon oraz adres e-mail producenta do zgłaszania
problemów, kontakt do opiekuna ze strony producenta).
W dokumentacji powykonawczej musi zostać załączone
potwierdzenie producenta, że sprzęt jest nowy objęty gwarancją.
Musi być wskazany termin do kiedy sprzęt jest objęty gwarancją
producenta.
Jeżeli producent urządzenia umożliwia utworzenie konta
na swojej stronie i rejestrację urządzenia to wykonawca
zobowiązany jest wskazać adres strony www na której można
założyć konto. W przypadku problemów z rejestracją urządzeń
wykonawca zobowiązany jest pomóc Zamawiającemu podczas
ZP/PN/35/2014
21.
Konta użytkowników
22.
Instalacja
23.
Warsztaty
24.
Kable światłowodowe
25.
Dodatkowe wkładki
SAN
rejestracji urządzenia.
Na etapie wdrożenia Wykonawca zobowiązany jest do zmiany
domyślnego hasła administratora oraz innych domyślnych
użytkowników. Na czas wdrożenia oraz do późniejszych celów
gwarancyjnych Wykonawca zobowiązany jest używać kont
imiennych z uprawnieniami administracyjnymi.
Zmienione hasło administratora musi zostać przekazane
Zamawiającemu wraz z innymi hasłami administracyjnymi do
systemów (np. w zaszyfrowanym pliku programu Keepass lub w
innej bezpiecznej uzgodnionej formie).
Instalacja oraz konfiguracja sprzętu musi być przeprowadzona na
miejscu w obecności wyznaczonego pracownika Zamawiającego.
Wykonawca zobowiązany jest przeszkolić wyznaczonego
pracownika w zakresie podstawowej konfiguracji przełącznika.
Zakres przeszkolenia :
- informacja jak podłączyć nowe urządzenie, odczytać wwn
urządzenia (serwer, macierz)
- informacja jak stworzyć, skasować, zmienić alias (zarówno z
poziomu www jak również z poziomu command line przełącznika)
- informacja jak stworzyć, zmodyfikować oraz skasować nową
zonę (www oraz command line)
- informacja jak utworzyć config, dodać lub usunąć z konfiguracji
zonę.
- informację jak włączyć wyłączyć, przełączyć config
- informację jak wykonać backup konfiguracji przełącznika i
ewentualnie go odtworzyć.
- informację jak monitorować stan przełącznika (www)
- przekazać inne ważne informacje na co najbardziej uważać
podczas konfiguracji urządzeń.
Zamawiający wymaga dostarczenia następujących kabli
światłowodowych:
 30 kabli światłowodowych wielomodowych o dł. 5m
Zamawiający wymaga dostarczenia dodatkowych wkładek SAN:
 4 wkładki jednomodowe LC, o prędkości 16Gbit, dystans
minimalny 1km
 4 wkładki jednomodowe LC, o prędkości 8Gbit, dystans
minimalny 1km
Wymaganiem zamawiającego jest, aby wkładki były oryginalne
certyfikowane do pracy z urządzeniem (muszą być na oficjalnej
liście kompatybilności producenta przełącznika sieci SAN). Jeżeli
producent przełącznika nie posiada listy kompatybilności,
zamawiający wymaga dostarczenia potwierdzenia
kompatybilności, wystawionego przez producenta przełącznika
SAN (potwierdzenie producenta przełącznika, że przełącznik
współpracuje z oferowanym modelem wkładki SAN).
ZP/PN/35/2014
2. Specyfikacja techniczna dla obudowy serwerowej
a. Obudowa dla serwerów kasetowych
Zamawiający wymaga dostarczenia, montażu oraz konfiguracji obudowy dla serwerów
kasetowych. Obudowa serwerowa ma zostać dostarczona z kompletem kabli podłączeniowych
oraz kompletem niezbędnych elementów wymaganych do montażu w szafie RACK. Wszelkie
prace mające na celu podłączenie do zasilania i uruchomienie obudowy serwerowej leżą po
stronie wykonawcy. W celu podłączenia obudowy do sieci zarządzającej LAN zamawiający
wymaga zastosowania okablowania ze świetlną identyfikacją połączeń w kategorii min 6.
W przypadku gdyby dedykowana szafa RACK w serwerowni zamawiającego okazała się
zbyt mała do montażu obudowy serwerowej, Wykonawca zobowiązany jest dostarczyć
dedykowaną szafę RACK, która umożliwi montaż obudowy w serwerowni.
Wymaganiem Zamawiającego jest ustalenie jednolitej koncepcji nazewniczej serwerów,
sieci, zasobów dyskowych oraz innych elementów którym będą przypisywane nazwy na etapie
wdrożenia poszczególnych systemów.
Tabela 2.1 Specyfikacja techniczna obudowy serwerowej
Lp.
Wymaganie
Opis
1. Ilość sztuk
1 sztuka
2. Wysokość w szafie RACK
10U
3. Typ obudowy
Dostosowana do montażu w szafie 19” Możliwość instalacji
co najmniej 4 obudów w jednej szafie rack 19” o wysokości
42U
4. Ilość serwerów
Możliwość instalacji 16 serwerów w pojedynczej obudowie
serwerowej
5. Moduł zarządzający
Redundantny (nadmiarowy) moduł zarządzający obudową
serwerową zapewniający:
 dostęp i zarządzanie obudową z poziomu przeglądarki
WWW,
 Podgląd stanu wszystkich komponentów wchodzących
w skład obudowy (modułów sieciowych, modułów SAN,
zamontowanych serwerów, zasilaczy, wentylatorów,
ilość aktualnie pobieranego prądu, temperaturę na
poszczególnych czujnikach).
 pełen zdalny dostęp konsolowy umożliwiający: pracę na
wybranym serwerze bez pośrednictwa systemu
operacyjnego (w tym dostęp do BIOS) oraz
przekierowanie standardowej konsoli graficznej i
tekstowej.
 Zdalne udostępnianie napędu DVD-ROM, FDD na
potrzeby każdego serwera z możliwością bootowania z
w/w napędów. Możliwość zdalnego podłączenia
pamięci USB,
 zdalne włączanie/wyłączanie/restart niezależnie dla
każdego serwera. Zdalna identyfikacja fizycznego
serwera za pomocą sygnalizatora optycznego.
 Zamawiający wymaga aby moduły zarządzające były
niezależne. Awaria modułów zarządzających nie może
wpłynąć na działanie serwerów zainstalowanych w
obudowie serwerowej (systemy zainstalowane na
serwerach muszą normalnie pracować i komunikować
się z siecią LAN oraz SAN)
6. Zasilacze
Dostarczona obudowa blade ma być wyposażona w
komplet redundantnych zasilaczy, typu Hot Plug,
ZP/PN/35/2014
podłączonych do 2 obwodów zasilania. System zasilania
zdolny do obsługi następujących typów awarii:
- Awaria połowy z zainstalowanych zasilaczy pracujących
w układzie nadmiarowym.
- W przypadku awarii jednego z obwodów źródła
zasilania wymagane jest ciągłe dostarczenie mocy
niezbędnej do zasilenia obudowy w pełni obsadzonej
serwerami.
7.
Wentylatory
8.
Łączność LAN
9.
Łączność SAN
10. Miejsce na dodatkowe moduły
11. Licencje
12. Wymagania dodatkowe
Nadmiarowy (redundantny) system chłodzenia typu hotswap (z możliwością wymiany wentylatorów podczas
pracy), zapewniający chłodzenie obudowy w pełni
obsadzonej serwerami i wszystkimi dodatkowymi
komponentami. Obudowa powinna być wyposażona w
komplet wentylatorów chłodzących.
Minimum 2 moduły sieci LAN zamontowane
i skonfigurowane w sposób eliminujący pojedynczy punkt
awarii od strony sieci LAN (wymagania opisane w tabeli
2.2)
Minimum 2 moduły sieci SAN zamontowane
i skonfigurowane w sposób eliminujący pojedynczy punkt
awarii od strony sieci SAN (wymagania opisane w tabeli
2.3)
Obudowa powinna mieć możliwość dodatkowych modułów
sieciowych lub SAN (dodatkowe miejsca w obudowie).
Komplet licencji pozwalający na montaż maksymalnej ilości
serwerów, na przejęcie konsoli graficznej serwera przez
sieć dla wszystkich 16 slotów serwerowych, Inne
niezbędne licencje potrzebne do prawidłowego działania
serwerów.
Zamawiający wymaga zamontowania obudowy serwerowej
we wskazanej przez Zamawiającego szafie RACK ze
szczególną dbałością o ułożenie kabli i porządek w szafie
RACK. Tam gdzie zajdzie potrzeba należy ułożyć kable
zasilające, sieciowe i światłowodowe, pospinać je
opaskami rzepowymi. Długość kabli ma zostać dobrana tak
aby w szafie nie było zbyt dużych nadmiarów kabli
światłowodowych oraz kabli LAN. Zamawiający wymaga
opisania kabli światłowodowych oraz sieciowych wg
wytycznych, które przekaże na etapie wdrożenia.
Tabela 2.2 Specyfikacja techniczna modułów sieciowych
Lp. Wymaganie
1.
2 moduły pracujące w technologii minimum 10Gb Ethernet zamontowanie w obudowie
serwerowej w sposób eliminujący pojedynczy punkt awarii.
2.
Urządzenia te muszą umożliwiać agregację wychodzących połączeń LAN w obrębie
pojedynczego modułu, muszą umożliwiać wyprowadzenie sygnałów LAN z obudowy
serwerowej z zachowaniem redundancji połączeń.
3.
Każdy moduł musi posiadać minimum 16 portów wewnętrznych minimum 10Gb do
podłączenia serwerów kasetowych. Każdy serwer musi być podłączony jednym portem
minimum 10 Gbit do jednego modułu, drugim portem minimum 10 Gbit do drugiego modułu
sieciowego. Każdy moduł musi posiadać minimum 10 zewnętrznych portów 10Gb
umożliwiających podłączenie obudowy do przełączników sieci LAN w serwerowni.
4.
W raz z każdym modułem sieciowym Wykonawca zobowiązany jest dostarczyć minimum 3
wkładki SFP+ 10Gbit jednomodowe, krótkodystansowe(minimalny dystans 300m). Oraz 2
wkładki SFP RJ45, 1Gbit (łącznie 6 wkładek 10Gbit oraz 4 wkładki 1Gbit)
ZP/PN/35/2014
5.
6.
7.
8.
9.
10.
11.
12.
Z poziomu zarządzania modułami sieciowymi musi być możliwość utworzenia konfiguracji
sieciowej dla poszczególnych serwerów w postaci profili sieciowych przypisywanych zatokom
serwerowym. Dla każdego serwera musi być możliwość podziału łącznego pasma na
poszczególne karty sieciowe. Wymaganiem zamawiającego jest aby dla każdego serwera była
możliwość utworzenia do 8 kart sieciowych. Jeżeli oferowane przez danego producenta
moduły mają lub będą miały możliwość tworzenia większej ilości kart sieciowych to
zamawiający dopuszcza takie rozwiązanie.
Wymaganiem zamawiającego jest aby przydzielona prędkość dla karty sieciowej była
widoczna w systemie operacyjnym (np. utworzono kartę 100Mbit i przypisano ją do serwera
ESXi - w konfiguracji serwera powinna być widoczna karta o prędkości 100 Mbit).
Wymaganiem zamawiającego jest aby moduły sieciowe miały możliwość: obsługi sieci VLAN,
obsługę portów trunk, obsługę agregacji IEEE 802.3ad na portach wyprowadzających sygnał
na zewnątrz obudowy. Dla wewnętrznych połączeń do serwerów zamawiający wymaga obsługi
sieci VLAN.
Wymaganiem zamawiającego jest aby dla poszczególnych sieci VLAN była możliwość
ograniczenia pasma (chodzi o ustawienie przepustowości maksymalnej i minimalnej dla
określonej sieci VLAN). Ustawienie wartości minimalnej powinno musi wiązać się z
zarezerwowaniem określonego pasma dla wybranej sieci VLAN.
Moduł sieciowy musi umożliwiać skonfigurowanie poszczególnych połączeń obudowy w taki
sposób, aby wypięcie kabla sieciowego powodowało powiadomienie serwera o odpiętym kablu
sieciowym (serwer musi dostać i zalogować informację o wypiętym kablu sieciowym (widoczny
brak połączenia z poziomu systemu operacyjnego). System powinien zasygnalizować brak
połączenia sieciowego jeżeli wszystkie połączenia sieciowe "obudowa - sieć LAN"
skonfigurowane do obsługi określonej sieci zostaną odpięte.
W przypadku odpięcia tylko połowy połączeń skonfigurowanych redundantnie serwer musi
działać normalnie, informacja o problemach z siecią musi być widoczna z poziomu
oprogramowania zarządzającego modułem sieciowym
Zarządzanie modułem LAN musi odbywać się za pomocą strony WWW, wymaganiem
zamawiającego jest to żeby konfigurację portów oraz innych ustawień modułu sieciowego
wykonywać na jednym module. Po zapisaniu ustawień muszą się one zreplikować na drugi
moduł sieciowy. Wymiana danych musi odbywać się w trybie online bez przerywania pracy
modułów sieciowych.
W konsoli zarządzającej obudowy musi być link to wejścia na konsolę zarządzającą modułem
sieciowym, lub musi być możliwość bezpośredniej konfiguracji modułu sieciowego.
Moduł sieciowy na którym wprowadzana jest konfiguracja musi mieć możliwość wykonywania
kopii zapasowej ustawień.
Moduł sieciowy musi mieć możliwość wgrywania nowych wersji firmware w trybie online.
Wymaganiem zamawiającego jest aby dostęp do nowych wersji firmware był darmowy.
Tabela 2.3 Specyfikacja techniczna modułów sieci SAN
Lp.
Wymaganie
1.
2 moduły sieci SAN działające w technologii 16Gb zamontowanie w obudowie blade w
sposób eliminujący pojedynczy punkt awarii w sieci SAN
2.
Moduły sieci SAN muszą być certyfikowane do pracy z obudową serwerową przez
producenta obudowy
3.
Moduły sieci SAN muszą być w pełni kompatybilne z siecią SAN (konfiguracja zoningu,
konfiguracja sieci fabric muszą ściągać się z innych przełączników w poszczególnych
sieciach fabric), musi być zapewniona możliwość agregacji portów w jedno połączenie o
większej przepustowości. Moduł przełącznika FC musi zapewniać mechanizm ISL Trunk
oraz mechanizmy balansowania ruchu.
4.
Każdy moduł musi posiadać minimum 16 portów wewnętrznych, o prędkości minimum 16
Gbit, do podłączenia serwerów kastetowych. Każdy serwer musi być podłączony jednym
interfejsem SAN do jednego modułu, drugim interfejsem do drugiego. Wszystkie porty
wewnętrzne do podłączenia serwerów muszą być aktywne i umożliwiać podłączenie
serwera
5.
Każdy moduł musi posiadać minimum 12 portów zewnętrznych, o prędkości minimum 16
ZP/PN/35/2014
6.
7.
8.
9.
10.
11.
12.
Gbit do wyprowadzenia sygnału sieci SAN na zewnątrz obudowy.
Każdy moduł musi mieć aktywnych (gotowych do pracy), obsadzonych wkładkami FC
minimum 4 porty zewnętrzne. Porty muszą być obsadzone wkładami o prędkości minimum
16Gbit, wielomodowymi, krótkodystansowymi.
Wkładki SAN zamontowane w portach zewnętrznych muszą być, nowe, objęte gwarancją
producenta, oryginalne, certyfikowane przez producenta modułu sieciowego pracy w sieci
SAN. Wkładki nie mogą powodować utraty gwarancji i wsparcia technicznego na moduły
sieci SAN.
Wymaganiem zamawiającego jest, aby wszystkie porty wewnętrzne były aktywne, gotowe
do zamontowania serwerów. Montaż dodatkowego serwera nie może wiązać się z
koniecznością dokupowania licencji dla modułu SAN.
Za pomocą portów zewnętrznych musi być możliwość podłączenia obudowy do sieci SAN
( moduł SAN musi obsługiwać połączenia między przełącznikami SAN), jak również musi
być możliwość podłączania do modułu SAN urządzeń zewnętrznych (np. macierzy
dyskowej)
Moduł musi mieć możliwość obsługi obydwu trybów jednocześnie.
W raz z każdym modułem SAN wykonawca zobowiązany jest dostarczyć minimum 4
wkładki SAN 16Gbit wielomodowe, krótkodystansowe (łącznie 8 wkładek SAN 16Gbit)
Zarządzanie modułem musi być możliwe zarówno za pomocą strony WWW jak również za
pomocą konsoli SSH. Konfiguracja sieci fabric (np. nowy alias, zona, lub zmiana w
konfiguracji sieci fabric) wprowadzona na module zamontowanym w obudowie musi
rozpropagować się na inne przełączniki działające w sieci SAN (w danej sieci fabric)
W konsoli zarządzającej obudowy musi być link to wejścia na konsolę zarządzającą
modułem sieciowym, lub musi być możliwość bezpośredniej konfiguracji modułu
sieciowego.
Moduł sieci SAN musi mieć możliwość wgrywania nowych wersji firmware w trybie online.
Na każdym module SAN powinna być wgrana dodatkowa licencja pozwalająca na
agregację kilku połączeń zewnętrznych w jedno połączenie o większej przepustowości
oraz licencja pozwalająca na łączenie przełączników w stos.
a. Konfiguracja obudowy serwerowej
W ramach wdrożenia wykonawca zobowiązany jest przygotować obudowę do pracy oraz
instalacji serwerów i systemów operacyjnych. Obudowa musi mieć nadaną nazwę sieciową,
musi być podłączona do sieci zarządzającej, dla urządzeń zamonowanych wewnątrz obudowy
musi zostać przypisany zakres adresów IP z sieci zarządzającej (dla modułów zarządzających
obudową, dla modułów sieciowych, dla modułów SAN, dla interfejsów zarządzających
serwerami oraz innych urządzeń niezbędnych do prawidłowego działania środowiska). Moduły
zarządzające oraz moduły sieciowe i SAN muszą mieć wgraną najnowszą stabilną na dzień
wdrożenia wersję firmware. Obudowa musi być oklejona (nazwa obudowy). Każdy element
mający zarządzalny adres IP powinien mieć przypisaną nazwę DNS za pomocą której będzie
można połączyć się z urządzeniem. Przypisana nazwa musi być widoczna z poziomu
oprogramowania do zarządzania obudową. W miarę możliwości dotyczących ilości wolnego
miejsca na obudowie oraz urządzeniach, każde urządzenie (dotyczy głównie serwerów oraz
modułów sieciowych oraz SAN) powinno zostać oznaczone poprzez naklejenie nalepki z
przypisaną w systemie zarządzającym nazwą sieciową urządzenia. Jeżeli na obudowie nie
będzie dostatecznej ilości miejsca do przyklejenia nalepki identyfikacyjnej to informacje takie
muszą znaleźć się w dokumentacji powykonawczej.
Konfiguracja modułów sieciowych obejmuje konfigurację połączeń do przełącznika LAN
w serwerowni, utworzenie niezbędnych sieci VLAN, przypisanie ich do poszczególnych połączeń
sieciowych. Moduł sieciowy ma zostać podłączony i skonfigurowany tak aby uniknąć
pojedynczych punktów awarii. Wypięcie kabla sieciowego z jednego modułu bądź awarii modułu
sieciowego lub wkładki LAN nie może przerwać pracy serwera. W ramach konfiguracji modułu
sieciowego wykonawca zobowiązany jest utworzyć profile sieciowe serwerów. Konfiguracja
profili sieciowych musi zostać dobrana do potrzeb jaką serwer będzie w systemie (serwer
wirtualizacji, węzeł klastra bazodanowego lub inny). Konfiguracja sieciowa musi być zgodna z
ZP/PN/35/2014
zaleceniami i najlepszymi praktykami producenta systemu operacyjnego oraz oprogramowania
bazodanowego (dotyczy konfiguracji sieciowej hostów wirtualizacji oraz konfiguracji węzłów
klastrów bazodanowych np. sieci zarządzające, interfejsy do wymiany informacji w obrębie
klastra tzw. heartbeat i inne).
Na etapie konfiguracji Wykonawca zobowiązany jest zmienić domyślne hasła
administratora na urządzeniach zarządzalnych i przekazać je wyznaczonej przez
Zamawiającego osobie. Do celów wdrożeniowych oraz później do celów gwarancyjnych
Wykonawca zobowiązany jest do utworzenia kont imiennych z uprawnieniami administratora.
Moduły sieci SAN muszą być podłączone każdy do innej sieci fabric. Konfiguracja sieci
SAN musi ściągnąć się na moduł w obudowie serwerowej z innego przełącznika SAN
działającego w sieci fabric. Zmiana w konfiguracji SAN w obrębie jednej sieci fabric wykonana
na dowolnym przełączniku SAN bądź module w obudowie serwerów kasetowych musi
rozpropagować się do innych przełączników SAN działających w obrębie danej sieci fabric.
Wykonawca zobowiązany jest do podłączenia obudowy serwerowej do sieci SAN (rozszerzenie
poszczególnych sieci fabric) oraz do wykonania takiej konfiguracji, która pozwoli na
prezentowanie zasobów dyskowych z macierzy dyskowej do poszczególnych serwerów.
Wykonawca zobowiązany jest także do utworzenia innych konfiguracji w sieci SAN niezbędnych
do prawidłowego działania pozostałych systemów korzystających z sieci SAN (np. System
backupu jeżeli będzie wykonywał backupy przy użyciu sieci SAN).
Konfiguracja obudowy serwerowej oraz modułów sieciowych oraz SAN musi odbywać się
na miejscu w obecności wyznaczonego pracownika ze strony Zamawiającego.
b. Dokumentacja powykonawcza
Wykonawca zobowiązany jest dostarczyć dokumentację powykonawczą w której zawarty
będzie techniczny opis tego co i jak zostało wdrożone i skonfigurowane w ramach obudowy
serwerowej, modułów sieciowych oraz modułów SAN. Dokumentacja musi zawierać zwięzły
techniczny opis konfiguracji obudowy (numery seryjne urządzeń, konfiguracja sieciowa
obudowy oraz interfejsów zarządzających).
W dokumentacji powykonawczej musi być zawarta informacja o fizycznych połączeniach
sieciowych i połączeniach FC w szczególności :
 do którego portu w którym przełączniku sieciowym jest podłączony poszczególny port
modułu sieciowego obudowy serwerowej (jakie sieci VLAN są przypisane do połączenia
na przełączniku)
 opis profili sieciowych (ilość interfejsów sieciowych w profilu i jakie sieci zostały
przypisane do poszczególnych interfejsów, jakie prędkości zostały określone dla
poszczególnych sieci VLAN)
 opis jak podłączone są moduły SAN do zewnętrznych przełączników sieci SAN.
W dokumentacji powykonawczej musi być zawarta informacja dotycząca tego gdzie i jak
zgłaszać problemy z urządzeniem w okresie gwarancji (telefon do wykonawcy, osoba
kontaktowa, telefon oraz adres e-mail producenta do zgłaszania problemów, kontakt do
opiekuna ze strony producenta).
W dokumentacji powykonawczej musi zostać załączone potwierdzenie producenta, że
sprzęt jest nowy objęty gwarancją. Musi być wskazany termin do kiedy sprzęt jest objęty
gwarancją producenta.
Jeżeli producent urządzenia umożliwia utworzenie konta na swojej stronie i rejestrację
urządzenia to wykonawca zobowiązany jest wskazać adres strony www na której można
założyć konto. W przypadku problemów z rejestracją urządzeń wykonawca zobowiązany jest
pomóc Zamawiającemu podczas rejestracji urządzenia.
ZP/PN/35/2014
3. Serwery kasetowe
Zamawiający wymaga aby serwery kasetowe dla poszczególnych systemów miały
możliwość montażu w obudowie serwerowej, której wymagania zostały opisane w punkcie 2.
Serwery muszą być certyfikowane do pracy w obudowie przez producenta obudowy oraz
muszą w pełni współpracować z oprogramowaniem zarządzającym obudową, z modułami
sieciowymi oraz modułami SAN zamontowanymi w obudowie.
a. Serwery dla systemu bazodanowego Oracle
Tabela 3.1 Specyfikacja techniczna serwerów dla klastra systemu bazodanowego Oracle
Lp. Wymaganie
Opis
1.
Ilość sztuk
2 serwery
2.
Zgodność z obudową
Dostarczane serwery muszą być certyfikowane do
serwerową
pracy z dostarczaną obudową serwerów kasetowych.
3.
Wspierane systemy
Wsparcie dla systemów RedHat Enterprise Linux 5/6,
operacyjne
Oracle Enterprise Linux 5/6. Poprzez wsparcie
producenta serwera dla systemów operacyjnych
zamawiający rozumie bezpłatne wydawanie nowych
wersji sterowników oraz oprogramowania układowego
dla serwera dostępne bezpłatnie także po
zakończeniu gwarancji na serwer.
4.
Procesor
Minimum dwa procesory zamontowane w każdym
serwerze, minimum dziesięciordzeniowe x86-64 bity,
Intel E5-2690 v2 lub równoważne procesory minimum
dziesięciordzeniowe,
osiągające
w
testach
SPECint_rate2006 wynik nie gorszy niż 900 punktów.
W
przypadku
zaoferowania
procesora
równoważnego, 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.
Ilość pamięci RAM
Minimum 64 GB w każdym serwerze
6.
Ilość interfejsów sieciowych
Minimum dwa interfejsy minimum 10Gbit
7.
Ilość interfejsów SAN
Minimum dwa interfejsy minimum 16 Gbit
8.
Ilość dysków twardych
Minimum dwa dyski twarde "hot-swap", minimum 300
GB, minimum 15 krpm, skonfigurowanych do pracy w
RAID 1.
9.
Zarządzanie
Dedykowany adres karty zarządzania w sieci
zarządzającej przydzielany z poziomu obudowy
serwerowej.
Konsola zdalnego zarządzania musi umożliwiać :
włączenie, wyłączenie i restart serwera, podgląd
logów sprzętowych serwera i konsoli zarządzającej,
przejęcie pełnej konsoli tekstowej serwera niezależnie
od jego stanu (także podczas startu, restartu systemu
operacyjnego).
Konsola zdalnego zarządzania musi mieć możliwość
zdalnego przejęcia konsoli graficznej i podłączania
wirtualnych napędów CD/DVD/ISO i FDD. Konsola
zarządzająca musi być rozwiązaniem sprzętowym,
niezależnym od systemu operacyjnego
zainstalowanego na serwerze.
Zakres wdrożenia serwerów kasetowych dla klastra systemu bazodanowego Oracle obejmuje:
 wykonanie czynności niezbędnych do instalacji systemu operacyjnego na serwerze, po
stronie obudowy, modułów sieciowych i SAN oraz serwerów kasetowych.
ZP/PN/35/2014



instalację systemów operacyjnych wg zaleceń producenta bazy danych (przygotowanie
systemu do instalacji i konfiguracji klastra bazodanowego)
prezentację zasobów dyskowych z macierzy dla klastra bazodanowego wg zaleceń
producenta bazy danych (min. dysk quorum, osobne dyski na pliki danych, osobne
zasoby na pliki dziennika powtórzeń)
konfigurację sieciową systemów operacyjnych dla klastra
W ramach wdrożenia wykonawca zobowiązany jest dostarczyć dokumentację
powykonawczą obejmującą opis konfiguracji systemu operacyjnego, która została wykonana.
Wykonawca zobowiązany jest przekazać zamawiającemu komplet haseł administracyjnych. W
szczególności powinno być przekazane hasło użytkownika root oraz innych użytkowników, jeżeli
tacy zostali utworzeni na etapie wdrożenia
b. Serwery dla systemu bazodanowego MSSQL
Tabela 3.2 Specyfikacja techniczna serwerów dla klastra systemu bazodanowego MSSQL
Lp. Wymaganie
Opis
1.
Ilość sztuk
2 serwery
2.
serwerową
3.
Wspierane systemy
Wymagane wsparcie dla systemów operacyjnych
operacyjne
rodziny Windows 2008/2008R2/2012/2012R2.
Poprzez wsparcie producenta serwera dla systemów
operacyjnych zamawiający rozumie bezpłatne
wydawanie nowych wersji sterowników oraz
oprogramowania układowego dla serwera dostępne
bezpłatnie także po zakończeniu gwarancji na serwer.
4.
Ilość procesorów
1 procesor w każdym serwerze
5.
Procesor
ośmiordzeniowy, x86-64 bity, Intel Xeon E5-2667 v2
lub równoważny procesor ośmiordzeniowy testach
SPECint_rate2006 wynik nie gorszy niż 815 punktów
(wynik 815 punktów dla serwera wyposażonego w
dwa procesory). W przypadku zaoferowania
procesora równoważnego, 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.
6.
7.
Ilość interfejsów sieciowych
Minimum dwa interfejsy minimum 10Gbit
8.
Minimum dwa interfejsy minimum 16 Gbit
9.
RAID 1.
10. Zarządzanie
serwerowej.
operacyjnego).
ZP/PN/35/2014
Zakres wdrożenia serwerów kasetowych dla klastra systemu bazodanowego MSSQL obejmuje:
 wykonanie czynności niezbędnych do instalacji systemu operacyjnego na serwerze, po
stronie obudowy, modułów sieciowych, SAN oraz po stronie serwerów kasetowych
 instalację systemów operacyjnych wg zaleceń producenta bazy danych (przygotowanie
systemu do instalacji i konfiguracji klastra bazodanowego)
 prezentację zasobów dyskowych z macierzy dla klastra bazodanowego wg zaleceń
producenta bazy danych (min. dysk quorum, osobne dyski na pliki danych, osobne
zasoby na pliki dziennika powtórzeń, osobne zasoby na bazę temdb)
 konfigurację sieciową systemów operacyjnych dla klastra
powykonawczą obejmującą opis konfiguracji systemu operacyjnego, która została
wykonana. Wykonawca zobowiązany jest przekazać zamawiającemu komplet haseł
administracyjnych. W szczególności powinno być przekazane hasło lokalnego administratora
do systemu operacyjnego oraz innych użytkowników jeżeli podczas wdrożenia zostali
utworzeni.
c. Serwery dla systemu wirtualizacji
Wymagania techniczne dla serwerów kasetowych przeznaczonych dla systemu
wirtualizacji zostały określone w punkcie opisującym wymagania systemu wirtualizacji
4. Specyfikacja techniczna macierzy dyskowej
a. Macierz dyskowa dla systemów szpitala
Zamawiający wymaga dostarczenia macierzy dyskowej dla produkcyjnych systemów
szpitala. Wymagania techniczne macierzy dyskowej zostały opisane w tabeli 4.1.
Tabela 4.1 Specyfikacja techniczna macierzy dyskowej
Lp Parametr
Opis
1. Minimalna pojemność użytkowa
2 TB na szybkich dyskach SSD
(widoczna w systemie
35 TB na szybkich dyskach SAS lub FC min 15 krpm
operacyjnym)
25 TB na dyskach wolnych 7200 rpm
2.
RAID
Pojemność dla poszczególnych grup należy
oszacować dla poziomu RAID5 z uwzględnieniem
dysków "spare". Ilość dysków w poszczególnych
grupach musi zostać dobrana zgodnie z zaleceniami
producenta.
Zastosowany produkcyjnie poziom RAID dla danych
musi zapewniać takie zabezpieczanie, aby w sytuacji
awarii dwóch dysków twardych w pojedynczej grupie
RAID, była możliwość dostępu do danych.
ZP/PN/35/2014
3.
Bezpieczeństwo danych
4.
Obsługa dysków twardych
5.
Zastosowane dyski
6.
Rozlokowanie dysków twardych
7.
Maksymalna ilość obsługiwanych
dysków twardych
Wszystkie krytyczne komponenty macierzy takie jak:
kontrolery dyskowe, pamięć cache, zasilacze i
wentylatory muszą być redundantne, tak, aby awaria
pojedynczego elementu nie przerywała
funkcjonowania całego systemu (podwójny kontroler
macierzy pracujący w trybie active-active, zasilacze,
wentylatory, podwójne ścieżki między kontrolerem a
dyskami). Komponenty te muszą być wymienialne w
trakcie pracy macierzy (Hot-Swap).
Macierz musi mieć możliwość jednoczesnego
zasilania z dwóch niezależnych źródeł zasilania.
Zanik jednego z nich nie może powodować przerwy w
pracy urządzenia ani zmniejszenia jego wydajności
lub utraty danych.
Awaria dowolnej półki dyskowej (całkowita awaria
urządzenia) nie może powodować przerwania
dostępu do danych zlokalizowanych na pozostałych
półkach dyskowych.
2,5'', 3,5'' możliwość montażu różnych typów dysków
twardych (np dyski SSD, SAS, FC) w obrębie jednej
półki dyskowej przy uwzględnieniu wielkości dysku w
obrębie półki dyskowej (2,5 lub 3,5 cala)
Zamawiający wymaga stosowania następujących
typów dysków :
SSD - 2,5'' minimum 300 GB
SAS lub FC - 2,5'' minimum 300 GB, minimum 15
krpm
Dyski wolne - 2,5'' lub 3,5'', minimum 7200 rpm,
maximum 4 TB
Rozlokowanie dysków w obrębie półek dyskowych
musi być zgodne z zaleceniami producenta sprzętu
dotyczące uzyskania jak największej wydajności i
umożliwiać rozłożenie obciążenia pomiędzy półki
dyskowe.
Maksymalna ilość obsługiwanych dysków >= 480
sztuk
Poprzez możliwość obsługi 480 dysków twardych
zamawiający rozumie możliwość rozbudowy macierzy
wyłącznie o kolejne półki dyskowe oraz dyski twarde
bez konieczności wymiany, klastrowania lub
dokupienia dodatkowych kontrolerów dyskowych.
Mówiąc o obsłudze 480 dysków twardych
zamawiający nie dopuszcza wirtualizowania za
pomocą mechanizmów macierzy innych
zewnętrznych zasobów dyskowych.
8.
Obsługiwane protokoły
iSCSI (IP SAN)
Fibre Channel Protocol (FCP),
(możliwość równoczesnej obsługi przez kontroler
wszystkich protokołów i udostępniania danych
równocześnie przez różne protokoły). Zamawiający
dopuszcza obsługę dodatkowych protokołów.
Zamawiający wymaga aktywowania obsługi minimum
Fiber Channel Protocol.
ZP/PN/35/2014
9.
Ilość kontrolerów dyskowych
10. Ilość portów FC w pojedynczym
kontrolerze
11. Ilość pamięci cache w
pojedynczym kontrolerze
12. Kopie migawkowe (snapshot)
13. Kopie migawkowe dla
poszczególnych systemów
14. Możliwość wykonywania kopii
zasobów w obrębie macierzy
15. Rozmiar woluminów
16. Dystrybucja danych na dyskach
Minimum dwa kontrolery dyskowe działające w trybie
active-active lub multi-mesh. Awaria jednego z
kontrolerów nie może wpłynąć na spójność danych.
W przypadku awarii jednego z kontrolerów macierz
musi nadal zapewniać do danych udostępnionym
serwerom (przy założeniu że serwer obsługuje
minimum dwie różne ścieżki do zasobów)
Min 8 portów FC o prędkości 8 lub 16 Gbit. Wszystkie
porty muszą być aktywne.
Min 20 GB wewnętrznej pamięci w każdym
kontrolerze, pamięć musi być podtrzymywana
bateryjnie. Dane zapisywane w wewnętrznej pamięci
cache jednego z kontrolerów muszą być także
powielane w pamięci cache pozostałych kontrolerów,
tak aby w przypadku uszkodzenia dowolnego
kontrolera zachowana była spójność danych.
Macierz musi być wyposażona w wewnętrzny
(aktywny) system kopii migawkowych, dostępny dla
wszystkich rodzajów danych przechowywanych w
macierzy. Ilość kopii migawkowych nie może być
ograniczona licencyjnie.
Zamawiający wymaga aby oferowana macierz
posiadała możliwość wykonywania spójnych (pod
kątem spójności danych) kopii migawkowych dla :
 systemów bazodanowych Oracle
 systemów Vmware
 systemów bazodanowych MSSQL
Zamawiający nie wymaga aktywowania tej
funkcjonalności
Oferowana macierz musi mieć aktywowane
wewnętrzne mechanizmy pozwalające na wykonanie
pełnej kopii wskazanego zasobu i zaprezentowanie jej
innemu serwerowi (np. do celów testowych, do
wykonania kopii bezpieczeństwa itp.).
Zamawiający wymaga aby macierz posiadała
aktywowaną możliwość definiowania woluminów
większych niż fizycznie dostępna przestrzeń dyskowa
dla dowolnych obsługiwanych systemów
operacyjnych, Macierz musi umożliwiać zmianę
rozmiaru woluminów bez utraty zapisanych tam
danych i bez przerywania dostępu do tych danych.
Macierz powinna być wyposażona w mechanizmy
zwalniające wolne miejsce po skasowaniu danych z
poziomu systemu operacyjnego.
Macierz powinna być wyposażona w mechanizmy
obsługi zapisu „zer”
Zamawiający wymaga aby macierz miała
mechanizmy ostrzegające o kończącym się miejscu
na macierzy.
Zamawiający wymaga, by oferowana macierz
dyskowa umożliwiała dystrybucję (stripe) danych
pojedynczego woluminu logicznego LUN na wielu
napędach dyskowych.
ZP/PN/35/2014
17. Przenoszenie danych w obrębie
macierzy dyskowej
18. Mechanizmy zwiększające ilość
operacji IO przy użyciu dysków
SSD
19. Możliwość replikacji danych na
inną podobną lub taką samą
macierz tego samego producenta
20. Możliwość dynamicznej zmiany
następujących parametrów, bez
przerywania dostępu do danych
znajdujących się na
modyfikowanym wolumenie, lub
grupie dysków
21. Obsługiwane systemy
umożliwiała przenoszenie danych online w obrębie
macierzy dyskowej pomiędzy różnymi grupami
dyskowymi. Wymaganie dotyczy możliwości ręcznego
przeniesienia wolumenu w trybie online,
zaprezentowanego dla serwera, na inny typ nośników
(np. z szybkich dysków na wolniejsze lub na odwrót)
posiadała aktywowane mechanizmy zwiększające
wydajność przy wykorzystaniu dysków SSD
(automatyczne przenoszenie bloków najczęściej
używanych na dyski SSD lub kopiowanie najczęściej
używanych bloków na dyski SSD - macierz musi mieć
mechanizmy automatycznej analizy, które bloki są
najczęściej wykorzystywane. Zamawiający dopuszcza
także zastosowanie innych mechanizmów
zwiększające wydajność przy pomocy dysków SSD,
lub dodatkowych kart rozszerzeń pamięci cache
oferowanych przez różnych producentów).
W przypadku zastosowania dodatkowych kart
rozszerzeń zwiększających pamięć cache,
zamawiający wymaga aby dodatkowa pamięć miała
rozmiar minimum 512 GB.
Wymaganiem zamawiającego jest, aby konfiguracja
macierzy była zoptymalizowana pod kątem uzyskania
jak największej wydajności zasobów dyskowych .
Oferowana macierz musi posiadać mechanizmy
pozwalające na uruchomienie replikacji
synchronicznej lub asynchronicznej na inną macierz
tego samego typu. Zamawiający nie wymaga
aktywowania tej funkcjonalności.
 możliwość dynamicznego dodawania dysków do
istniejących grup RAID;
 możliwość dynamicznego powiększania i
zmniejszania rozmiaru wolumenów logicznych;
 możliwość dynamicznej zmiany rozmiaru
segmentu dla wolumenów logicznych;
 możliwość dodawania kolejnych półek dyskowych
oraz dysków bez przerywania pracy macierzy, dla
dowolnej konfiguracji macierzy;
 możliwość aktualizacji oprogramowania macierzy
(firmware) w trybie online;
 możliwość wymiany uszkodzonych elementów w
trybie online przy założeniu minimum dwóch
niezależnych ścieżek do zasobów dla
pojedynczego hosta.
 Możliwość rozrzucenia danych na wiele dysków
twardych w celu zrównoważenia obciążenia ( np.
po rozbudowie macierzy i dołożeniu zasobów do
puli, grupy dyskowej, grupy raid itp.). Rozrzucenie
danych musi być w miarę możliwości
równomierne.
Macierz dyskowa musi obsługiwać następujące
systemy operacyjne: Microsoft Windows 2003,
Windows 2008 Server, Windows 2008R2, Windows
2012, RedHat Enterprise Linux 5,6, Oracle Enterprise
Linux, VMware ESX/ESXi 4.x, 5.x).
ZP/PN/35/2014
22. Monitoring
Oferowana macierz powinna mieć aktywne
wewnętrzne mechanizmy pozwalające na
monitorowanie stanu macierzy dyskowej :
 monitorowanie stanu podzespołów macierzy
(dyski, zasilacze,baterie, wentylatory i inne)
 monitorowanie parametrów wydajnościowych
(ilość operacji IO/s dla danego zasobu,
opóźnienia, ilość danych zapisywanych
odczytywanych itp.)
 możliwość definiowania powiadomień mailowych
(np. uszkodzenie sprzętowe, uszkodzenie dysku,
brak miejsca itp.)
 możliwość monitorowania poprzez SNMP.
 Możliwość określenia stopnia wykorzystania i
obciążenia macierzy,
23. Obsługa serwerów
Oprogramowanie do obsługi "multi-patch", dla
wszystkich wspieranych systemów operacyjnych,
musi być dołączone do macierzy, lub dostępne na
stronie producenta macierzy bez dodatkowych opłat
Możliwość montażu w szafie rack 19’’. Zamawiający
wymaga dostarczenia wszystkich elementy konieczne
do instalacji – np. prowadnice, szyny, śruby,
Zamawiający wymaga użycia okablowania ethernet
ze świetlną identyfikacją połączeń, światłowody.
Każdy kabel ethernet oraz światłowodowy musi być
oznakowany wg. wytycznych Zamawiającego za
pomocą samo laminujących się nalepek z czytelnym
nadrukiem.
telnet, SSH, HTTP, Web (SSL), SNMP, email alerts
Macierz musi oferować zarządzanie poprzez sieć
LAN. Oprogramowanie do zarządzania musi posiadać
interfejs graficzny oraz CLI (command-line interface).
Przez cały okres gwarancji Zamawiający jest
uprawniony do otrzymywania najnowszych
dostępnych wersji oprogramowania macierzy,
zarówno firmware jak i systemu czy też innego
oprogramowania dostarczonego w ramach tego
zamówienia.
Zamawiający wymaga aby nowe wersje
oprogramowania były wgrywane na macierz przez
serwis producenta macierzy.
uprawniony do korzystania ze wsparcia technicznego
producenta przy rozwiązywaniu napotkanych
problemów. Kontakt w języku polskim.
Przez okres gwarancji Zamawiający wymaga także
wsparcia ze strony wykwalifikowanych inżynierów
Wykonawcy przy rozwiązywaniu problemów lub
trakcie prac związanych z konfiguracją lub
optymalizacją zasobów na macierzy.
24. Montaż
25. Zarządzanie
26. Aktualizacja / nowe wersje
oprogramowania układowego
kontrolerów macierzy
27. Wsparcie
ZP/PN/35/2014
W ramach wdrożenia wykonawca zobowiązany jest
dostarczyć dokumentację powykonawczą obejmującą
opis konfiguracji macierzy obejmujący :
 Numer seryjny macierzy
 Informację o gwarancji (do kiedy świadczona)
 Informację o tym gdzie i jak zgłaszać problemy
z macierzą (numer telefonu do serwisu
producenta i do Wykonawcy)
 Informację o tym jak zostały podzielone
zasoby i jak zostały skonfigurowane
poszczególne funkcjonalności
 Informacje konfiguracyjne : wwn-y, adresację
IP, nazewnictwo i inne istotne informacje
W przypadku potrzeby utworzenia konta
i zarejestrowania urządzenia na stronach producenta
(min. dla celów serwisowych oraz dostępu do nowych
wersji oprogramowania firmware, sterowników dla
systemów operacyjnych i innych) wykonawca
zobowiązany jest pomóc wskazanym pracownikom w
rejestracji urządzenia na stronach producenta.
Wykonawca zobowiązany jest do zmiany
domyślnych haseł administratora oraz innych
domyślnych użytkowników na macierzy i przekazania
listy haseł wskazanym pracownikom Zamawiającego.
Dla celów serwisowych i wdrożeniowych wykonawca
zobowiązany jest utworzyć dedykowane dla siebie
konto z uprawnieniami administracyjnymi.
5. System Backupu
W ramach prowadzonego postępowania przetargowego zamawiający wymaga
dostarczenia i zainstalowania systemu backupu dla Nowego Szpitala Wojewódzkiego.
Wymagania Zamawiającego dotyczące wykonywania się kopii zapasowych:
a. W określonym oknie backupowym kopia zapasowa wykonuje się na dyski serwera
backupowego (lokalne dyski serwera oraz dyski podłączone do serwera z macierzy
backupowej po sieci SAN)
b. W ciągu dnia (lub równolegle jeżeli oferowany system posiada taką możliwość) dane z
dysków serwera backupowego kopiowane są na taśmy w bibliotece.
c. Raz w tygodniu wykonywana jest pełna kopia danych, dzienne kopie wykonywane są
przyrostowo lub różnicowo.
d. Jedna kopia danych pełnych oraz kopie przyrostowe dzienne wykonane po pełnym
backupie tygodniowym znajdują się na dyskach serwera (w celu umożliwienia szybkiego
odzyskania danych w przypadku awarii)
e. Kopie pełne tygodniowe oraz kopie dzienne przyrostowe wykonywane codziennie na taśmy
powinny być przechowywane poza biblioteką w celu zabezpieczenia danych na wypadek
całkowitej awarii serwerowni.
f. System ma możliwość oznaczenia taśm z pełnymi kopiami tygodniowymi, miesięcznymi
i rocznymi jako taśm typu "off-site", ma możliwość zabezpieczenia taśm "off-site" przed
przypadkowym nadpisaniem przed upływem określonego terminu.
g. Pełne kopie tygodniowe, miesięczne, roczne oznaczone jako off-site przechowywane są
poza biblioteką taśmową
h. Kopie tygodniowe zabezpieczone są przed nadpisaniem przez okres miesiąca, kopie
miesięczne przez okres jednego roku, kopie roczne przez okres 5 lat.
i. System jest skalowalny i posiada możliwości rozbudowy wraz ze wzrostem środowiska oraz
ilości danych o :
ZP/PN/35/2014


j.
k.
dodatkowe zasoby dyskowe (rozbudowa macierzy dyskowej)
dodatkowe zasoby taśmowe (rozbudowa biblioteki lub obsługa drugiej
biblioteki taśmowej)

dodatkowe serwery backupu
System jest elastyczny pod względem konfiguracyjnym i umożliwia zmianę konfiguracji w
zależności od sytuacji i zmieniających się potrzeb (np. duży przyrost danych i potrzeba
zmiany konfiguracji bezpośrednio na napędy taśmowe, zmiana harmonogramów i inne.).
Dla kopii zapasowych trzymanych na dyskach twardych system musi mieć aktywną
funkcjonalność deduplikacji danych (dla określonej wielkości danych).
Tabela 5.1 Wymagane elementy składowe systemu backupu danych
Lp Parametr
Opis
1. Serwer backupu
Zamawiający wymaga dostarczenia minimum jednego
serwera do backupu danych. Jeżeli producent
oprogramowania zaleca użycie więcej niż jednego
serwera w celu sprawnego wykonywania kopii
zapasowych zamawiający dopuszcza dostarczenia
większej ilości serwerów, o parametrach nie gorszych
niż serwer wymagany przez zamawiającego.
2. Macierz dyskowa
Jedna macierz dyskowa przeznaczona dla systemu
backupowego
3. Bibliteka taśmowa
Jedna biblioteka taśmowa, wyposażona w dwa
napędy taśmowe LTO6 oraz 48 slotów na taśmy.
4. Oprogramowanie do backupu
Zestaw licencji dla serwera backupu oraz serwerów
danych
backupowanych pozwalający na wykonywanie kopii
zapasowych dla różnych systemów operacyjnych.
Tabela 5.2 Wymagania techniczne dla serwera backupu
Lp. Wymaganie
Opis
1.
Obudowa
Maksymalnie 2U RACK, możliwość montażu w szafie
RACK 19 cali (wraz ze wszystkimi elementami
niezbędnymi do zamontowania serwera w oferowanej
szafie - m. in. dedykowane szyny mocujące w szafie rack,
dedykowane ramię do okablowania)
2.
Ilość sztuk
Minimum 1 serwer backupu. Jeżeli producent systemu
backupu zaleca inne konfiguracje systemu złożone z
większej ilości serwerów zamawiający dopuszcza
dostarczenie więcej serwerów.
3.
Procesor
Minimum dwa procesory minimum ośmiordzeniowe, x86 64 bity, Intel Xeon E5-2667 v2 lub równoważne procesory
minimum ośmiordzeniowe, osiągające w testach
SPECint_rate2006 wynik nie gorszy niż 808 punktów. W
przypadku zaoferowania procesora równoważnego, 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.
Liczba procesorów
Minimum 2.
5.
Pamięć operacyjna
Minimum 64 GB RDIMM DDR3, z możliwością rozbudowy
do minimum 768GB. Minimum 24 sloty na pamięć.
6.
Sloty rozszerzeń
Minimum 3 sloty PCI-Express, w tym jeden slot x16
(szybkość slotu – bus width) oraz minimum jedno gniazdo
pełnej wysokości. Ponadto serwer musi mieć możliwość
instalacji dodatkowo (lub posiadać standardowo) minimum
2 slotów PCI-Express o szybkości x16 (bus width) lub
minimum 4 slotów PCI-Express o szybkości x8 (bus width).
7.
Dysk twardy
8 x dysk 300GB typu Hot Swap, SAS, 15000 obr./min.
2,5”,
ZP/PN/35/2014
8.
Kontrolery dyskowe
9.
Karty sieciowe
10.
Karty SAN
11.
12.
Karta graficzna
Porty
13.
Zasilacz
8 x dysk 600GB typu Hot Swap, SAS, 10000 obr./min 2,5''
Kontroler macierzowy SAS wyposażony w pamięć cache
512MB oraz podtrzymywanie zawartości pamięci typu
flash (FBWC) obsługujący poziomy RAID 0/1/1+0/5.
Serwer musi być dostarczony z takimi kontrolerami aby
mógł obsłużyć wszystkie 16 dysków zamontowanych w
serwerze
Minimum 4 porty Ethernet 10/100/1000 Mb/s z funkcją
Wake-On-LAN, RJ45.
Minimum dwie minimum jednoportowe karty sieci SAN o
prędkości minimum 16Gbit każda umożliwiająca wpięcie
serwera do dwóch niezależnych sieci fabric
Zintegrowana karta graficzna.
1 x szeregowy
7 x USB 2.0 (w tym jeden wewnętrzny).
VGA.
Minimum 2 szt., typ Hot-plug, redundantne.
Tabela 5.3 Wymagania techniczne dla macierzy dyskowej systemu backupu
Lp Parametr
Opis
1. Minimalna dostarczona pojemność 6 TB na szybkich dyskach SAS lub FC min 10 krpm
użytkowa (aktywna, możliwa do
12 TB na dyskach wolnych 7200 rpm
zaprezentowania i widoczna w
systemie operacyjnym dla serwera Pojemność należy oszacować dla poziomu RAID5 z
backupowego)
uwzględnieniem dysków "spare".
2. RAID
Zastosowany poziom RAID dla danych musi
zapewniać takie zabezpieczanie, aby w sytuacji
awarii dwóch dysków twardych w pojedynczej grupie
RAID, była możliwość dostępu do danych.
3. Bezpieczeństwo danych
Wszystkie krytyczne komponenty macierzy takie jak:
kontrolery dyskowe, pamięć cache, zasilacze i
wentylatory muszą być redundantne, tak, aby awaria
pojedynczego elementu nie przerywała
funkcjonowania całego systemu (minimum podwójny
kontroler macierzy pracujący w trybie active-active,
zasilacze, wentylatory, podwójne ścieżki między
kontrolerem a dyskami).
Macierz musi mieć możliwość jednoczesnego
zasilania z dwóch niezależnych źródeł zasilania.
Zanik jednego z nich nie może powodować przerwy w
pracy urządzenia ani zmniejszenia jego wydajności
lub utraty danych.
Awaria dowolnej półki dyskowej (całkowita awaria
urządzenia) nie może powodować przerwania
dostępu do danych zlokalizowanych na pozostałych
półkach dyskowych.
4. Obsługa dysków twardych
2,5'', 3,5'' możliwość montażu różnych typów dysków
twardych (np dyski SSD, SAS, FC) w obrębie jednej
półki dyskowej przy uwzględnieniu wielkości dysku w
obrębie półki dyskowej (2,5 lub 3,5 cala)
5. Zastosowane dyski
SAS lub FC – 2,5'' lub 3,5’’ minimum 300 GB,
minimum 10 krpm
Dyski wolne - 3,5'', minimum 7200 rpm, maximum 3
TB
ZP/PN/35/2014
6.
Maksymalna ilość obsługiwanych
dysków twardych
Maksymalna ilość obsługiwanych dysków większa
bądź równa 144 sztuk
Poprzez możliwość obsługi 144 dysków twardych
zamawiający rozumie możliwość rozbudowy macierzy
wyłącznie o kolejne półki dyskowe oraz dyski twarde
bez konieczności wymiany, klastrowania lub
dokupienia dodatkowych kontrolerów dyskowych.
Mówiąc o obsłudze 144 dysków twardych
zamawiający nie dopuszcza wirtualizowania za
pomocą mechanizmów macierzy innych
zewnętrznych zasobów dyskowych.
7.
Obsługiwane protokoły
8.
Ilość kontrolerów dyskowych
Ilość portów FC w kontrolerze
10. Ilość portów 10Gbit Ethernet w
11. Ilość pamięci cache w
9.
12. Kopie migawkowe (snapshot)
13. Deduplikacja blokowa
14. Rozmiar woluminów
iSCSI (IP SAN)
Fibre Channel Protocol (FCP),
(możliwość równoczesnej obsługi przez kontroler
wszystkich protokołów i udostępniania danych
równocześnie przez różne protokoły). Zamawiający
dopuszcza obsługę innych protokołów. Zamawiający
wymaga aktywowania minimum protokołu FC.
Minimum dwa kontrolery dyskowe działające w trybie
active-active. Awaria jednego z kontrolerów nie może
wpłynąć na spójność danych. W przypadku awarii
jednego z kontrolerów macierz musi nadal zapewniać
do danych udostępnionym serwerom (przy założeniu
że serwer obsługuje minimum dwie różne ścieżki do
zasobów)
Min 4 porty FC o prędkości 8 lub 16 Gbit
Min 2 porty
Min 6 GB wewnętrznej pamięci w każdym
kontrolerze, pamięć musi być podtrzymywana
bateryjnie. Dane zapisywane w wewnętrznej pamięci
cache jednego z kontrolerów muszą być także
powielane w pamięci cache pozostałych kontrolerów,
tak aby w przypadku uszkodzenia dowolnego
kontrolera zachowana była spójność danych.
Macierz musi mieć możliwość wykonywania kopii
migawkowych, dostępną dla wszystkich rodzajów
danych przechowywanych w macierzy. Zamawiający
nie wymaga aktywowania tej funkcjonalności
Macierz musi posiadać funkcjonalność eliminacji
identycznych bloków danych, którą można stosować
na macierzy/danych produkcyjnych dowolnego
rodzaju. Zamawiający nie wymaga aktywowania tej
funkcjonalności.
Zamawiający wymaga aby macierz posiadała
możliwość definiowania woluminów większych niż
fizycznie dostępna przestrzeń dyskowa, możliwość
zmiany rozmiaru woluminów bez utraty zapisanych
tam danych i bez przerywania dostępu do tych
danych.
Zamawiający nie wymaga aktywowania tej
funkcjonalności
ZP/PN/35/2014
15. Dystrybucja danych na dyskach
16. Przenoszenie danych w obrębie
macierzy dyskowej
17. Mechanizmy zwiększające ilość
operacji IO przy użyciu dysków
SSD
18. Możliwość replikacji danych na
inną podobną lub taką samą
macierz tego samego producenta
19. Możliwość dynamicznej zmiany
następujących parametrów, bez
przerywania dostępu do danych
znajdujących się na
modyfikowanym wolumenie, lub
grupie dysków
20. Obsługiwane systemy
Zamawiający wymaga, by oferowana macierz
dyskowa umożliwiała dystrybucję (stripe) danych
pojedynczego woluminu logicznego LUN na wielu
napędach dyskowych.
umożliwiała przenoszenie danych w obrębie macierzy
dyskowej pomiędzy różnymi grupami dyskowymi.
Wymaganie dotyczy możliwości ręcznego
przeniesienia wolumenu zaprezentowanego dla
serwera, na inny typ nośników (np. z szybkich dysków
na wolniejsze)
posiadała mechanizmy zwiększające wydajność przy
wykorzystaniu dysków SSD (np. automatyczne
przenoszenie bloków najczęściej używanych na dyski
SSD - macierz musi mieć mechanizmy automatycznej
analizy, które bloki są najczęściej wykorzystywane,
lub inne mechanizmy zwiększające wydajność
oferowane przez danego producenta). Zamawiający
nie wymaga aktywowania tej funkcjonalności.
Oferowana macierz powinna mieć mechanizmy
pozwalające na uruchomienie replikacji
synchronicznej lub asynchronicznej na inną macierz
tego samego typu. Zamawiający nie wymaga
aktywowania tej funkcjonalności.
 możliwość dynamicznego dodawania dysków do
istniejących grup RAID;
 możliwość dynamicznego powiększania i
zmniejszania rozmiaru wolumenów logicznych;
 możliwość dynamicznej zmiany rozmiaru
segmentu dla wolumenów logicznych;
 możliwość dodawania kolejnych półek dyskowych
oraz dysków bez przerywania pracy macierzy, dla
dowolnej konfiguracji macierzy;
 możliwość aktualizacji oprogramowania macierzy
(firmware) w trybie online;
 możliwość wymiany uszkodzonych elementów w
trybie online przy założeniu minimum dwóch
niezależnych ścieżek do zasobów dla
pojedynczego hosta.
 Możliwość równomiernego rozrzucenia danych
na wiele dysków twardych w celu zrównoważenia
obciążenia ( np. po rozbudowie macierzy i
dołożeniu zasobów do puli, grupy dyskowej, grupy
raid itp.)
Macierz dyskowa musi obsługiwać następujące
systemy operacyjne: Microsoft Windows 2003,
Windows 2008 Server, Windows 2008R2, Windows
2012, RedHat Enterprise Linux 5,6, Oracle Enterprise
Linux, VMware ESX/ESXi 4.x, 5.x).
ZP/PN/35/2014
21. Monitoring
Oferowana macierz powinna mieć aktywne
wewnętrzne mechanizmy pozwalające na
monitorowanie stanu macierzy dyskowej :
 monitorowanie stanu podzespołów macierzy
(dyski, zasilacze,baterie, wentylatory i inne)
 monitorowanie parametrów wydajnościowych
(ilość operacji IO/s dla danego zasobu,
opóźnienia, ilość danych zapisywanych
odczytywanych itp.)
 możliwość definiowania powiadomień mailowych
(np. uszkodzenie sprzętowe, uszkodzenie dysku,
brak miejsca itp.)
 możliwość monitorowania poprzez snmp.
 Możliwość określenia stopnia wykorzystania i
obciążenia macierzy,
22. Obsługa serwerów
Oprogramowanie do obsługi "multi-patch", dla
wszystkich wspieranych systemów operacyjnych,
musi być dołączone do macierzy, lub dostępne na
stronie producenta macierzy bez dodatkowych opłat.
Możliwość montażu w szafie rack 19’’, dostarczone
wszystkie elementy konieczne do instalacji – np.
prowadnice, szyny, śruby, okablowanie ethernet ze
świetlną identyfikacją połączeń, światłowodwe.
Każdy kabel ethernet oraz światłowodowy musi być
oznakowany wg. wytycznych Zamawiającego za
pomocą samolaminujących się nalepek z czytelnym
nadrukiem.
telnet, SSH, HTTP, Web (SSL), SNMP, email alerts
Macierz musi oferować zarządzanie poprzez sieć
LAN. Oprogramowanie do zarządzania musi
posiadać interfejs graficzny oraz CLI (command-line
interface).
uprawniony do otrzymywania najnowszych
dostępnych wersji oprogramowania macierzy
(oprogramowanie układowe oraz oprogramowanie dla
systemów operacyjnych)
uprawniony do korzystania ze wsparcia technicznego
producenta przy rozwiązywaniu napotkanych
problemów. Kontakt w języku polskim.
Przez okres gwarancji Zamawiający wymaga także
wsparcia ze strony wykwalifikowanych inżynierów
Wykonawcy przy rozwiązywaniu problemów lub
trakcie prac związanych z konfiguracją lub
optymalizacją zasobów na macierzy, a w
szczególności podczas wgrywania nowych wersji
firmware.
23. Montaż
24. Zarządzanie
25. Aktualizacja
26. Wsparcie
ZP/PN/35/2014
W ramach wdrożenia wykonawca zobowiązany jest
dostarczyć dokumentację powykonawczą obejmującą
opis konfiguracji macierzy obejmujący:
 Numer seryjny macierzy
 Informację o gwarancji (do kiedy świadczona)
 Informację o tym gdzie i jak zgłaszać
problemy z macierzą (numer telefonu do
serwisu producenta i do Wykonawcy)
 Informację o tym jak zostały podzielone
zasoby i jak zostały skonfigurowane
poszczególne funkcjonalności
 Informacje konfiguracyjne : wwn-y, adresację
IP, nazewnictwo i inne istotne informacje
W przypadku potrzeby utworzenia konta i
zarejestrowania urządzenia na stronach producenta
(min. dla celów serwisowych oraz dostępu do nowych
wersji oprogramowania firmware, sterowników dla
systemów operacyjnych i innych) wykonawca
zobowiązany jest pomóc wskazanym pracownikom w
rejestracji urządzenia na stronach producenta.
Wykonawca zobowiązany jest do zmiany
domyślnych haseł administratora i przekazania listy
haseł wskazanym pracownikom Zamawiającego. Dla
celów serwisowych i wdrożeniowych wykonawca
zobowiązany jest utworzyć dedykowane dla siebie
konto z uprawnieniami administracyjnymi.
Tablea 5.4 Wymagania techniczne dla biblioteki taśmowej
Lp Parametr
Opis
1. Montaż
Biblioteka musi być przystosowana do montażu w szafie 19”.
Biblioteka taśmowa musi być wyposażona w minimum dwa napędy
LTO Ultrium-6 FC o wydajności, co najmniej 160MB/s oraz
pojemności pojedynczej taśmy co najmniej 2500GB – parametry
podane bez kompresji danych. Biblioteka musi posiadać minimum
48 sloty wewnętrzne na taśmy LTO Ultrium-6. Biblioteka musi
2. Napędy taśmowe
posiadać możliwość rozbudowy oferowanej biblioteki o dodatkowe
napędy LTO Ultrium-6 i dodatkowe sloty wewnętrznych na taśmy
LTO Ultrium-6, poprzez dołączenie dodatkowych modułów w celu
utworzenia jednej, większej biblioteki taśmowej ze wspólnym
robotem i modułem zarządzania.
Każdy zainstalowany napęd taśmowy musi posiadać dwa natywne
3. Napędy taśmowe
interfejsy Fibre Channel 8Gb/s.
Napęd taśmowy musi być wyposażony w mechanizm dostosowujący
automatycznie oraz płynnie prędkość przesuwu taśmy magnetycznej
4. Napędy taśmowe
do wartości strumienia danych przekazywanego do napędu w
zakresie co najmniej 55-160MB/s.
5. Montaż
Wysokość oferowanej biblioteki taśmowej nie może przekraczać 4U.
Biblioteka taśmowa musi posiadać możliwość zdalnego zarządzania
6. Zarządzanie
za pośrednictwem przeglądarki internetowej.
Biblioteka taśmowa musi być wyposażona w czytnik kodów
7. Zarządzanie
kreskowych.
Biblioteka musi posiadać możliwość konfiguracji, co najmniej jednego
8. Eksploatacja
slotu umożliwiającego wymianę pojedynczej taśmy bez konieczności
wyjmowania z biblioteki całego magazynka z taśmami.
ZP/PN/35/2014
9.
Funkcjonalność
10. Monitorowanie
11. Zgodność
12. Inne
13. Taśmy LTO6
Napędy LTO Ultrium-6 muszą posiadać wsparcie dla taśm typu
WORM i sprzętową enkrypcję AES 256-bit.
Do biblioteki musi być dołączone oprogramowanie monitorujące,
które jest w stanie przewidzieć i zapobiec awarii poprzez
wygenerowanie powiadomienia i zasugerowanie odpowiednich
działań. Dołączone oprogramowanie musi mieć możliwość oceny
stanu zużycia taśmy LTO Ultrium-6 i dostarczyć informacji na temat
poziomu kompresji, z jakim wykonywane są kopie bezpieczeństwa.
Zamawiający wymaga pełnej zgodności z dostarczanym systemem
do wykonywania kopii zapasowych
Wymaga się dostarczenia wraz z biblioteką wszelkich niezbędnych
elementów potrzebnych do instalacji oraz uruchomienia systemu
backupu danych.
Zamawiający wymaga dostarczenia minimum 100 taśm LTO6,
minimum 10 taśm czyszczących wraz z kompletem nalepek z kodami
kreskowymi rozpoznawanymi przez czytnik kodów w bibliotece oraz
oprogramowanie do wykonywania backupu danych
Tablea 5.5 Wymagania techniczne dla oprogramowania do backupu danych
Lp Parametr
1. Wymaganiem zamawiającego jest aby oferowany system backupu danych posiadał
architekturę : serwer zarządzający/media-serwer/klient. Zamawiający dopuszcza aby
serwer zarządzający oraz media-serwer zainstalowany był na jednym serwerze.
Zamawiający wymaga, aby w przyszłości – w miarę rozwoju środowiska była możliwość
rozdzielenia funkcji serwera zarządzającego od media serwera.
2. Zamawiający wymaga aby dostarczane rozwiązanie było skalowalne, tj. posiadało
architekturę oraz możliwości konfiguracji pozwalające na rozbudowę środowiska
backupowego poprzez dodanie kolejnych serwerów backupu, w celu poprawienia
wydajności, bądź też w celu zapewnienia redundancji systemu backupowego. Rozwiązanie
musi mieć możliwość rozbudowy o dodatkową przestrzeń do przechowywania danych
(dyski lub taśmy).
3. Zamawiający wymaga aby dostarczony system backupu posiadał graficzną konsolę do
zarządzania systemem backupu, z poziomu której była możliwość wykonywania wszystkich
zadań związanych z konfigurowaniem systemu, dodawaniem nowych serwerów,
konfigurowaniem zadań backupowych oraz wykonywaniem innych czynności
administracyjnych. Konsola graficzna musi umożliwiać administratorowi weryfikację czy
zadania backupowe wykonały się poprawnie.
4. Oferowany system backupu musi umożliwiać centralne zarządzanie całym systemem z
poziomu jednej konsoli zarządzania (zarządzanie zadaniami, nośnikami, media-serwerami)
także w przypadku systemu złożonego z większej ilości serwerów
5. Oferowany system nie może posiadać preferowanego dostawcy sprzętu backupowego
(macierze, biblioteki taśmowe itp.) dla którego dostępna jest bogatsza funkcjonalność
systemu. Oferowany system musi umożliwiać wymianę sprzętu backupowego (macierz
backupowa, biblioteka) bez utraty funkcjonalności (musi wspierać wiele różnych bibliotek i
macierzy na takim samym poziomie funkcjonalnym)
6. Oferowany system musi mieć mechanizmy, ułatwiających wykonywanie codziennych
czynności administracyjnych (podgląd zadań, generowanie różnych podsumowań
dotyczących parametrów systemu np. ilości danych w systemie)
7. Oferowany system musi obsługiwać wiele napędów taśmowych oraz dyskowych
jednocześnie. Oferowany system musi być zoptymalizowany do jednoczesnego
wykorzystania jak najmniejszej ilości napędów taśmowych.
8. Oferowany system musi mieć możliwość wykonywania kopii bezpieczeństwa z
wykorzystaniem sieci SAN.
ZP/PN/35/2014
9.
10.
11.
12.
13.
Oferowany system musi mieć możliwość obsługiwania wielu zadań backupowych
jednocześnie niezależnie od stosowanego nośnika (np. zapis na jeden napęd, odczyt odzyskiwanie z innego napędu, zapis na macierz dyskową).
Oferowany system musi mieć możliwość tworzenia harmonogramu zadań backupowych.
Zadania backupowe muszą się uruchamiać automatycznie na podstawie zdefiniowanego
harmonogramu.
System musi mieć możliwość wykonywania wskazanych skryptów zarówno przed
wykonaniem zadania backupowego, jak również po wykonaniu zadania backupowego
Oferowany system musi mieć możliwość wykonywania kopii pełnych, przyrostowych,
różnicowych
Oferowany system musi mieć możliwość wykonywania kopii bezpieczeństwa z systemów
klastrowych – w szczególności klaster bazodanowy MSSQL, klaster bazodanowy Oracle
Database (RAC)
14. System musi być wyposażony w mechanizmy wykonywania kopii zapasowych na dysk
twardy serwera oraz na taśmę. Poza oknem backupowym system musi umożliwiać
kopiowanie danych z dysków twardych na taśmy. System powinien mieć możliwość
powielania określonych danych na różnych nośnikach lub pomiędzy lokalizacjami (np. do
innej lokalizacji). W przypadku gdy dane znajdują się zarówno na dyskach serwera jak
również na taśmach LTO system do odzyskiwania musi wykorzystywać dane znajdujące
się na dyskach twardych serwera w celu szybkiego odzyskania danych.
Po przekopiowaniu danych na taśmy w przypadku potrzeby odzyskania plików lub innych
danych musi być możliwość odzyskania danych bezpośrednio z taśmy (bez potrzeby
kopiowania danych najpierw na dysk twardy serwera backupowego).
ZP/PN/35/2014
15. System musi mieć możliwość skonfigurowania następującej polityki backupowej, którą
administrator będzie mógł później modyfikować i dostosowywać do zmieniających się
potrzeb :
 Raz w tygodniu wykonywany jest pełen backup tygodniowy
 Codziennie wykonywane są backupy przyrostowe lub różnicowe
 Ostatni backup tygodniowy oraz dzienne backupy przyrostowe lub różnicowe
trzymane są na dyskach serwera oraz na taśmach LTO
 Po skopiowaniu danych z dysków na taśmy (pełne backupy tygodniowe – raz w
tygodniu, kopie dzienne – każdego dnia, miesięczne – raz w miesiącu, roczne – raz
w roku) system musi umożliwiać wyjęcie taśm z biblioteki w celu trzymania ich w
bezpiecznym miejscu na wypadek awarii serwerowni (oznaczenie taśm jako tzw.
„off site”) .
 System musi obsługiwać kody kreskowe umieszczone na taśmach oraz numerki
taśm (w przypadku konieczności załadowania do biblioteki odpowiednich taśm musi
wskazywać administratorowi, które taśmy należy włożyć do biblioteki)
 System powinien być wyposażony w mechanizm wspomagający administratora
w procesie zarządzaniu taśmami w zakresie optymalizacji zużycia taśm (taśmy
dzienne używane najczęściej po jakimś czasie stają się taśmami miesięcznymi lub
rocznymi).
 Taśmy wyjęte z biblioteki muszą być zabezpieczone przed przypadkowym
skasowaniem i nadpisaniem (zabezpieczenie przed błędem ludzkim)
o Taśmy z danymi dziennymi – przez okres 7 dni
o Taśmy z pełnymi kopiami tygodniowymi – przez okres miesiąca
o Taśmy z pełnymi kopiami miesięcznymi – przez okres 6 lub 12 miesięcy
o Taśmy z pełnymi kopiami rocznymi – przez okres 5 lat
 Oferowany system musi posiadać funkcje wspomagające administratora w
prowadzeniu kontroli nad nośnikami wyciągniętymi z biblioteki,
o System musi umożliwiać automatyczne przenoszenie taśm do portu
wymiany biblioteki dla taśm przeznaczonych do wyjęcia,
o System musi powiadać mechanizm przypominający o konieczności
ponownego załadowania taśm przechowywanych „off-site” po zakończeniu
okresu ważności backupów.
o Całość konfiguracji musi być dostępna z konsoli zarządzającej backupem.
 W ramach wdrożenia zamawiający wymaga skonfigurowania w systemie backupu
opisanej powyżej polityki startowej
16. Oferowany system backupowy musi mieć możliwość wykonywania kopii zapasowych z
systemów operacyjnych z rodziny:
 Windows 2003,2003R2,2008,2008R2,2012,2012R2 oraz nowsze jeżeli na dzień
wdrożenia będą dostępne nowsze wersje
 Linux : RedHat Enterpise Linux 5/6, Oracle Enterprise Linux 5/6, CentOS, Suse
Enterprise Linux 11, Debian, Ubuntu,
 AIX
Zamawiający dopuszcza rozwiązania wspierające więcej systemów operacyjnych
17. Oferowany system backupowy musi mieć możliwość wykonywania kopii bezpieczeństwa z
systemów wirtualizacji:
 Vmware ESXi 5.x
 Oferowany w ramach postępowania system wirtualizacji
Zamawiający dopuszcza rozwiązania wspierające więcej systemów wirtualizacji
ZP/PN/35/2014
18. W ramach wykonywania kopii bezpieczeństwa z systemów wirtualizacji oferowany system
musi umożliwiać (mieć aktywowaną możliwość) :
 Wykonywania kopii bezpieczeństwa całych maszyn wirtualnych
 Wykonywanie kopii bezpieczeństwa całych maszyn wirtualnych musi być możliwe
zarówno wg. ustalonego harmonogramu jak również na żądanie
 Wykonywanie kopii bezpieczeństwa musi być możliwe zarówno bezpośrednio na
taśmy jak również do określonego katalogu na dysku serwera backupowego
 System musi umożliwiać wykonywanie przyrostowych oraz różnicowych kopii
bezpieczeństwa bezpośrednio z systemu wirtualizacji bez „zaglądania” do systemu
operacyjnego serwera wirtualnego oraz bez instalacji agenta na systemie
wirtualnym
 System musi umożliwiać wykonywanie kopii bezpieczeństwa serwerów wirtualnych
łącząc się bezpośrednio do wirtualizatora lub do serwera zarządzającego
infrastrukturą wirtualizacji.
 W ramach wykonywania backupu przyrostowego lub różnicowego system musi
automatycznie wykonywać kopię bloków danych które uległy zmianie od ostatniego
pełnego backupu lub ostatniego backupu przyrostowego.
 Oferowany system backupu musi umożliwiać odtwarzanie pojedynczych plików bez
potrzeby odtwarzania całej wirtualnej maszyny niezależnie od systemu
operacyjnego (minimum Windows oraz Linux)
 Oferowany system backupu powinien umożliwiać odtwarzanie pojedynczych
elementów maszyn wirtualnych bez potrzeby instalowania agentów na serwerach
wirtualnych dla systemów :
o Microsoft Exchange – pojedyncze wiadomośći pocztowe w skrzynkach
o Microsoft Sharepoint – pojedyncze elementy witryn
o Microsoft SQL – pojedyncze bazy danych
o Microsoft Active Directory – pojedyncze obiekty w strukturze katalogowej
19. Oferowany system wykonywania kopii bezpieczeństwa musi oferować funkcjonalność
polegającą na deduplikacji takich samych danych dla backupów trzymanych na
określonych dyskach twardych serwera backupowego. Funkcjonalność deduplikacji danych
musi być integralną częścią systemu backupowego. Deduplikowanie danych w systemie
archiwizacji musi być dostępne dla systemów operacyjnych: Windows, Linux, Vmware
ESX bądź inny oferowany system wirtualizacji.
W ramach dostarczanego systemu backupu powinna być dostarczona licencja
umożliwiająca trzymanie w systemie minimum 4 TB danych zdeduplikowanych.
20. Ze względu na politykę Zamawiającego związaną z przechowywaniem danych
medycznych oraz ze względu na uwarunkowania prawne dotyczące przechowywania
części danych medycznych, Zamawiający wymaga dostarczenia oprogramowania do
archiwizacji danych, którego licencja umożliwi przechowywanie backupów w
nieograniczonej ilości danych przez nieograniczoną liczbę dni. Jedynym ograniczeniem w
tym wypadku jest pojemność infrastruktury jaką posiada, lub będzie posiadać
Zamawiający. Rozbudowa systemu kopii zapasowych o dodatkową powierzchnię
(dyskową lub dodatkowe taśmy) nie może wiązać się z dokupowaniem dodatkowych
licencji na dodatkową powierzchnię w systemie backupu.
Zamawiający wymaga aby licencja dostarczany system backupu nie ograniczała
pojemności przechowywania backupu na nośnikach wymiennych lub macierzach
dyskowych.
Wymaganie to dotyczy danych niededuplikowanych i oznacza to, że rozmiar
niededuplikowanych danych przechowywanych w systemie archiwizacji nie może być
ograniczony licencyjnie.
21. Zamawiający wymaga aby dostarczona licencja na system kopii zapasowych była
bezterminowa. W okresie wykupionego wsparcia na system backupu Zamawiający musi
mieć możliwość do korzystania z nowych wersji oprogramowania (zarówno nowa wersja
systemu backupowego, jak również nowe wersje klientów dla poszczególnych systemów
operacyjnych)
ZP/PN/35/2014
22. Oferowany system backupu danych powinien mieć możliwość wykonywania kopii
zapasowych bezpośrednio z macierzy (z wolumenów sklonowanych lub ze snapshotów
wykonanych za pomocą mechanizmów macierzy). Zamawiający wymaga aktywowania
takiej funkcjonalności.
23. Oferowany system backupu danych musi być dostarczony z dedykowaną dla siebie bazą
danych, w pełni niezależną od innych systemów backupowanych. Baza danych musi być
zawarta w cenie rozwiązania.
24. Oferowany system backupu danych musi mieć mechanizmy pozwalające na
zabezpieczenie „samego siebie” przed awarią poprzez wykonanie kopii zapasowej
(zarówno kopia systemu operacyjnego z zainstalowanym oprogramowaniem do backupu,
jak również kopia bazy danych). Kopia systemu backupowego powinna wykonywać się
cyklicznie (zgodnie z założoną polityką backupową).
25. Oferowany system backupu musi umożliwiać odzyskiwanie pojedynczych plików, drzew
katalogów, partycji, wolumenów z chronionych systemów operacyjnych zarówno fizycznych
jak i wirtualnych w jednym przebiegu (tzn. bez potrzeby odzyskiwania całych maszyn
wirtualnych).
26. Oferowany system backupu danych musi posiadać funkcjonalność pozwalającą na szybkie
odzyskiwanie systemów operacyjnych (bez potrzeby instalowania i konfigurowania systemu
operacyjnego oraz klienta backupu) – funkcjonalność tzw. „bare metal recovery”
27. Zamawiający wymaga aby funkcjonalność „bare metal recovery” była dostarczona dla :
 Serwera backupu
 Dedykowanego serwera usług katalogowych
 Jednego węzła klastra MSSQL
 Jednego węzła klastra Oracle
 Serwera zarządzającego infrastrukturą wirtualizacji
28. Oferowany system backupu musi mieć możliwość wykorzystywania wewnętrznych
mechanizmów systemu z rodziny MS Windows tzw. „VSS Writer”
ZP/PN/35/2014
29. Zamawiający wymaga dostarczenia następujących licencji dla systemu backupowego
pozwalających na wykonywanie kopii bezpieczeństwa następujących systemów :
1. Wykonywanie kopii bezpieczeństwa/ odzyskiwanie systemów operacyjnych
wchodzących w skład klastra bazodanowego MSSQL (dwa serwery
jednoprocesorowe z rodziny Windows)
2. Wykonywanie kopii bezpieczeństwa/ odzyskiwanie systemów operacyjnych dla
serwerów wchodzących w skład klastra bazodanowego Oracle (dwa serwery
dwuprocesorowe z systemem operacyjnym z rodziny Linux)
3. Wykonywanie kopii bezpieczeństwa /odzyskiwanie danych z fizycznego
dedykowanego serwera usług katalogowych
4. Wykonywanie kopii bezpieczeństwa/ odzyskiwanie danych z fizycznego
dedykowanego serwera zarządzającego infrastrukturą wirtualizacji serwerów
5. Licencja na możliwość wykonywanie kopii bezpieczeństwa/ odzyskiwanie
pojedynczych baz danych z klastra MSSQL.
6. Licencja pozwalające na wykonywanie backupów/odzyskiwanie danych z klastra
bazodanowego Oracle (RAC) – integrację z narzędziami klastra bazodanowego
7. Licencja pozwalająca na wykonywanie kopii bezpieczeństwa/odzyskiwanie
pojedynczych elementów obiektów w usłudze katalogowej.
8. Licencja pozwalająca na wykonywanie kopii bezpieczeństwa ze snapshotów
macierzowych
9. Licencja na wykonywanie kopii bezpieczeństwa/ odzyskiwanie nieograniczonej
liczby serwerów wirtualnych z dostarczonego środowiska wirtualizacji (licencja
powinna umożliwiać wykonywanie kopii serwerów wirtualnych z 6 serwerów 2
procesorowych na których będzie zainstalowany wirtualizator).
10. Licencja na minimum 4 TB danych deduplikowanych
11. Licencja na nieograniczoną liczbę danych niededuplikowanych
12. Dodatkowa licencja do wykorzystania na przyszłość umożliwiająca ochronę
dodatkowych 4 serwerów 2 procesorowych (w sumie 8 procesorów). Licencja
dodatkowa musi umożliwiać ochronę serwerów niezależnie od zainstalowanego
systemu operacyjnego.
13. Wszystkie dostarczone licencje muszą być bezterminowe. W okresie wykupionego
wsparcia na system Zamawiający musi mieć prawo do aktualizacji oprogramowania
do nowszej wersji.
30. W ramach wdrożenia Zamawiający wymaga wykonania następujących prac
konfiguracyjnych :
1. Instalacja systemu backupowego, konfiguracja zasobów dyskowych oraz
taśmowych do obsługi startowej polityki backupu opisanej w wymaganiach systemu
backupu.
2. Konfiguracja backupu na serwerze usług katalogowych
3. Konfiguracja backupu na serwerze zarządzającym infrastrukturą wirtualizacji
4. Konfiguracja backupu na serwerach klastra bazodanowego MSSQL w ustalonym
zakresie
5. Konfiguracja backupu na serwerach klastra Oracle w ustalonym zakresie
6. Konfiguracja backupu na serwerze backupowym (zabezpieczenie samego siebie)
7. Przygotowanie nośników „bare metal recovery” dla serwerów dla których ma być
dostarczona taka funkcjonalność
8. Konfiguracja backupów dla serwerów wirtualnych.
9. Konfiguracja harmonogramu automatycznego wykonywania się zadań
backupowych z systemów chronionych w określonym oknie backupowym
10. Konfiguracja harmonogramu kopiowania danych na taśmy LTO.
11. Inne zadania konfiguracyjne niezbędne do wdrożenia polityki startowej i ochrony
wdrażanych systemów.
ZP/PN/35/2014
Tabela 5.6 Wymagania dodatkowe dla systemu backupu
Lp Opis
1. Zamawiający wymaga aby oprócz wymagań minimalnych określonych w opisie systemu
backupowego Wykonawca dostarczył komplet licencji potrzebnych do uruchomienia
systemu backupowego (np. licencję/subskrypcję na system operacyjny na którym będzie
zainstalowany system backupowy) oraz inne licencje których Zamawiający nie był w stanie
określić na etapie specyfikacji istotnych warunków zamówienia
2. Interfejsy zarządzające urządzeń (serwera, biblioteki, macierzy) muszą być podpięte do
sieci zarządzającej, adresy IP dodane do serwera DNS.
3. Wszystkie połączenia światłowodowe oraz połączenia do sieci LAN muszą być opisane wg.
wytycznych, które na etapie wdrożenia przekaże Wykonawcy Zamawiający.
4. Zamawiający wymaga dostarczenia kompletnej dokumentacji technicznej zawierającej
informacje w postaci zwięzłego technicznego opis tego co zostało wdrożone w ramach
dostarczenia systemu backupu. Opis powinien zawierać w szczególności :
1.
Spis dostarczonych urządzeń zawierających numery seryjne
2.
Informację do kiedy poszczególne urządzenia objęte są gwarancją producenta
sprzętu
3.
Informację gdzie i jak zgłaszać problemy w okresie gwarancyjnym
4.
Opis konfiguracji poszczególnych urządzeń (adresacja IP wszystkich interfejsów,
założeni użytkownicy, nazwy urządzeń itp.)
5.
Spis licencji które zostały dostarczone w ramach dostawy systemu backupu
6.
Opis jak i do których portów w przełącznikach sieciowych zostały podłączone
serwer, biblioteka, macierz dyskowa.
7.
Opis konfiguracyjny serwera backupu
8.
Opis konfiguracyjny macierzy dyskowej
9.
Opis konfiguracyjny biblioteki taśmowej
10.
Opis konfiguracji systemu backupowego (konfiguracja zasobów dyskowych,
konfiguracja zasobów taśmowych, harmonogram wykonywania się kopii zapasowych oraz
inne istotne informacje).
6. System Wirtualizacji
W ramach prowadzonego postępowania przetargowego zamawiający wymaga
dostarczenia i zainstalowania systemu wirtualizacji serwerów dla Szpitala Wojewódzkiego
Założenia przyjęte przez Zamawiającego dla architektury systemu wirtualizacji serwerów :
a. Serwer zarządzający infrastrukturą działa na dedykowanym do tego celu serwerze
fizycznym
b. Baza danych dla serwera zarządzającego działa na fizycznym klastrze bazodanowym
MSSQL
c. Serwer jest objęty backupem danych
d. Serwer zarządzający jest zintegrowany z usługą ActiveDirectory
e. System wirtualizacji wspiera wiele systemów operacyjnych
f. System wirtualizacji jest skalowalny :
 Ma możliwość rozbudowy klastrów o dodatkowe serwery fizyczne (hypervisory)
 Ma możliwość obsługi wielu heterogenicznych systemów operacyjnych
 Ma możliwość rozbudowy na dwa Centra Przetwarzania Danych i budowy
zapasowego klastra, który w przypadku awarii przejmie rolę klastra
podstawowego
g. System korzysta z wydajnej macierzy dyskowej SAN (dane produkcyjnych maszyn
wirtualnych trzymane wyłącznie na macierzy dyskowej)
h. Całość systemu produkcyjnego (z wyjątkiem hypervisorów) objęta backupem danych
i. System wirtualizacji obsługuje możliwie jak najwięcej wirtualnych systemów
operacyjnych.
Tabela 6.1 Elementy składowe systemu wirtualizacji
ZP/PN/35/2014
Lp.
1
Wymaganie
Serwer zarządzający
2
Hypervisory/wirtualizatory
3
Oprogramowanie
Opis
Jeden dedykowany serwer zarządzający
infrastrukturą wirtualizacji
6 serwerów dedykowanych pod hypervisory systemu
wirtualizacji
Komplet oprogramowania potrzebnego do
uruchomienia systemu wirtualizacji
Tabela 6.2 Specyfikacja techniczna dla serwerów kasetowych systemu wirtualizacji
Lp. Wymaganie
Opis
1.
Ilość sztuk
6 serwerów kasetowych dla klastra wirtualizacji
2.
serwerową
3.
Wsparcie dla systemów
Zamawiający wymaga wsparcia producenta serwera
operacyjnych
dla systemów wirtualizacji oferowanych w
postępowaniu.
Poprzez wsparcie producenta serwera zamawiający
rozumie bezpłatne wydawanie nowych wersji
sterowników oraz dedykowanego oprogramowania
układowego dla serwera dostępne bezpłatnie także
po zakończeniu gwarancji na serwer. (do czasu do
kiedy producent będzie wydawał nowe wersje
oprogramowania dla serwera)
4.
Procesor
Minimum dwa procesory zamontowane w każdym
serwerze, minimum dziesięciordzeniowe x86-64 bity
Intel E5-2690 v2, lub inne równoważne procesory
minimum dziesięciordzeniowe, osiągające w testach
SPECint_rate2006 wynik nie gorszy niż 900 punktów.
W
przypadku
zaoferowania
procesora
równoważnego, 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.
6.
Interfejsy sieciowe
Minimum dwa interfejsy minimum 10Gbit w każdym
serwerze. Przepustowość kart sieciowych w serwerze
minimum 2x10 Gbit.
Dostarczany system (obudowa blade, moduły LAN
montowane w obudowie, serwery) muszą umożliwiać
tworzenie z poziomu oprogramowania
zarządzającego obudowy lub modułu sieciowego
minimum 8 kart sieciowych dla każdego serwera.
Zamawiający wymaga aby administrator miał
możliwość definiowania prędkości dla
poszczególnych kart sieciowych. Zdefiniowana przez
administratora prędkość dla kart sieciowych musi być
widoczna z poziomu systemu operacyjnego (np.
administrator tworzy kartę o prędkości 100 Mbit - w
systemie widać kartę sieciową o prędkości 100 Mbit).
Połowa łącznej przepustowości, oraz połowa
zdefiniowanych interfejsów sieciowych serwera musi
być podłączona do jednego przełącznika w obudowie,
a druga połowa kart sieciowych do drugiego
przełącznika. Karty muszą mieć możliwość obsługi
vlanów. Karty muszą mieć możliwość przypisywania
minimalnej prędkości w celi zagwarantowania pasma
dla danej karty sieciowej.
ZP/PN/35/2014
7.
8.
9.
Zarządzanie
Minimum dwa dedykowane interfejsy minimum 16
Gbit w pełni certyfikowane do współpracy z
oferowaną siecią SAN.
RAID 1.
serwerowej.
operacyjnego).
Tabela 6.3 Specyfikacja techniczna dla serwera zarządzającego infrastrukturą wirtualizacji
Lp. Wymaganie
Opis
1.
Obudowa
Maksymalnie 2U RACK 19 cali (wraz ze wszystkimi
elementami niezbędnymi do zamontowania serwera w
oferowanej szafie - m. in. dedykowane szyny mocujące w
szafie rack, dedykowane ramię do okablowania)
2.
Procesor
w/w testów.
3.
Liczba procesorów
Minimum 2.
4.
Pamięć operacyjna
5.
Sloty rozszerzeń
6.
Dysk twardy
2,5”,
7.
Kontrolery dyskowe
Kontrolery macierzowe SAS wyposażony w pamięć cache
8.
Karty sieciowe
Wake-On-LAN, RJ45.
9.
Karty SAN
Minimum dwie minimum jednoportowe karty sieci SAN o
prędkości minimum 8Gbit każda umożliwiająca wpięcie
10. Karta graficzna
11. Porty
1 x szeregowy
ZP/PN/35/2014
12.
13.
Zasilacz
System operacyjny
VGA.
Licencja na system operacyjny pozwalająca na obsługę
całej dostępnej w systemie operacyjnym pamięci RAM.
Tabela 6.4 Specyfikacja techniczna dla oprogramowania systemu wirtualizacji
Lp. Wymaganie
1.
Warstwa wirtualizacji musi być zainstalowana bezpośrednio na sprzęcie fizycznym bez
dodatkowych pośredniczących systemów operacyjnych i zależności od systemów
operacyjnych
2.
Wirtualizator musi posiadać możliwość :
 zwalniania niewykorzystywanej pamięci przez maszynę wirtualną
 deduplikacji stron pamięci
 kompresji stron pamięci
 wykorzystania dysków SSD jako obszaru wymiany do obsługi pamięci operacyjnej
serwera.
3.
Wirtualizator musi posiadać mechanizmy umożliwiające ochronę serwerów wirtualnych na
poziomie hypervisora (np. ochrona antywirusowa, wirtualny firewall)
4.
Wirtualizator musi posiadać możliwość dodawania wirtualnych procesorów oraz pamięci
bez konieczności wyłączania serwera wirtualnego. Musi posiadać możliwość rozszerzania
obszarów dyskowych na których działają serwery wirtualne.
5.
Rozwiązanie musi 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.
6.
Oprogramowanie do wirtualizacji zainstalowane na serwerze fizycznym potrafi obsłużyć i
wykorzystać procesory fizyczne wyposażone dowolną liczbę rdzeni oraz do 2TB pamięci
fizycznej RAM.
7.
Oprogramowanie do wirtualizacji musi zapewnić możliwość skonfigurowania maszyn
wirtualnych z możliwością przydzielenia do 1 TB pamięci operacyjnej RAM.
8.
wirtualnych, z których każda może mieć 1-10 wirtualnych kart sieciowych.
9.
wirtualnych, z których każda może mieć co najmniej 4 porty szeregowe i 3 porty
równoległe i 20 urządzeń USB.
10. Rozwiązanie powinno w możliwie największym stopniu być niezależne od producenta
platformy sprzętowej . Polityka licencjonowania musi umożliwiać przenoszenie licencji na
oprogramowanie do wirtualizacji pomiędzy serwerami różnych producentów z
zachowaniem wsparcia technicznego i zmianą wersji oprogramowania na niższą
(downgrade). Licencjonowanie nie może odbywać się w trybie OEM.
11. Z uwagi na dużą heterogeniczność systemów do obsługi szpitali i jednostek medycznych
oferowane rozwiązanie musi wspierać maksymalnie dużą ilość systemów operacyjnych.
Rozwiązanie musi wspierać następujące systemy operacyjne: Windows 2000, Windows
Server 2003, Windows Server 2008, Windows Server 2012, Windows 7, Windows 8,
SLES 11, SLES 10, SLES 9, SLES 8, RHEL 6, RHEL 5, RHEL 4, RHEL 3, Solaris 11
,Solaris 10, Solaris 9, Solaris 8, OS/2 Warp 4.0, NetWare 6.5, NetWare 6, NetWare 5,
OEL 4, OEL 5, Debian, CentOS, FreeBSD, Asianux, Mandriva, Ubuntu 12.04, SCO
OpenServer,SCO Unixware, Mac OSX
12. W ramach aktywnego wsparcia producenta systemu wirtualizacji musi być zapewnione
wsparcie dla systemów SUSE Enterprise Linux lub innych dostępnych na rynku dla
nieograniczonej ilości zainstalowanych systemów wirtualnych (bez kupowania
dodatkowych subskrypcji).
13. Rozwiązanie musi umożliwiać przydzielenie większej ilości pamięci RAM dla maszyn
wirtualnych niż fizyczne zasoby RAM serwera w celu osiągnięcia maksymalnego
ZP/PN/35/2014
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
współczynnika konsolidacji.
Rozwiązanie musi umożliwiać udostępnienie maszynie wirtualnej większej ilości zasobów
dyskowych niż jest fizycznie zarezerwowane na dyskach lokalnych serwera lub na
macierzy.
Rozwiązanie powinno posiadać centralną konsolę graficzną do zarządzania maszynami
wirtualnymi i do konfigurowania innych funkcjonalności. Centralna konsola graficzna musi
mieć możliwość działania zarówno jako aplikacja na maszynie fizycznej lub wirtualnej jak i
jako gotowa, wstępnie skonfigurowana maszyna wirtualna tzw. virtual appliance.
Rozwiązanie musi oferować także konsolę graficzną do zarządzania systemem
wirtualizacji dostępną poprzez stronę WWW.
Rozwiązanie musi zapewnić możliwość bieżącego monitorowania wykorzystania zasobów
fizycznych infrastruktury wirtualnej (np. wykorzystanie procesorów, pamięci RAM,
wykorzystanie przestrzeni na dyskach/wolumenach) oraz przechowywać i wyświetlać
dane maksymalnie sprzed roku.
Oprogramowanie do wirtualizacji musi zapewnić możliwość wykonywania kopii
migawkowych instancji systemów operacyjnych (tzw. snapshot) na potrzeby tworzenia
kopii zapasowych bez przerywania ich pracy.
Oprogramowanie do wirtualizacji musi zapewnić możliwość klonowania systemów
operacyjnych wraz z ich pełną konfiguracją i danymi.
Oprogramowanie do wirtualizacji oraz oprogramowanie zarządzające musi posiadać
możliwość integracji z usługami katalogowymi Microsoft Active Directory. Uprawnienia w
systemie wirtualizacji muszą być nadane w oparciu o grupy stworzone w usługach
katalogowych.
Rozwiązanie musi zapewniać mechanizm bezpiecznego uaktualniania warstwy
wirtualizacyjnej (hosta, maszyny wirtualnej) bez potrzeby wyłączania wirtualnych maszyn.
Rozwiązanie musi zapewnić dodatkowy (niezależnie od dostarczanego systemu backupu)
zintegrowany mechanizm do bezpiecznej automatycznej archiwizacji i odtwarzania
wskazanych maszyn wirtualnych (zarządzany z poziomu jednej konsoli) Mechanizm ten
musi umożliwiać również odtwarzanie pojedynczych plików z kopii zapasowej oraz
zapewniać stosowanie deduplikacji dla kopii zapasowych, musi mieć możliwość tworzenia
harmonogramów backupowych. Mechanizm musi być dostępny w oferowanym
rozwiązaniu bez ponoszenia dodatkowych kosztów licencyjnych.
Rozwiązanie wirtualizacji serwerów musi być wyposażone w mechanizm replikacji
wskazanych maszyn wirtualnych w obrębie klastra serwerów fizycznych.
Rozwiązanie musi mieć możliwość przenoszenia maszyn wirtualnych w czasie ich pracy
pomiędzy serwerami fizycznymi. Mechanizm powinien umożliwiać 4 lub więcej takich
procesów przenoszenia jednocześnie.
Rozwiązanie musi mieć możliwość przenoszenia zwirtualizowanych dysków maszyn
wirtualnych w czasie ich pracy pomiędzy fizycznymi zasobami dyskowymi.
Musi zostać zapewniona odpowiednia redundancja i taki mechanizm (wysokiej
dostępności HA) aby w przypadku awarii lub niedostępności serwera fizycznego wybrane
przez administratora i uruchomione na nim wirtualne maszyny zostały uruchomione na
innych serwerach z zainstalowanym oprogramowaniem wirtualizacyjnym.
Oprogramowanie do wirtualizacji musi mieć możliwość uruchomienia takiego
zabezpieczenia wybranych przez administratora wirtualnych maszyn, aby w przypadku
awarii lub niedostępności serwera fizycznego maszyny, które na nim pracowały były
bezprzerwowo dostępne na innym serwerze z zainstalowanym i skonfigurowanym
oprogramowaniem wirtualizacyjnym.
System musi posiadać funkcjonalność wirtualnego przełącznika (virtual 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.
Pojedynczy wirtualny przełącznik musi posiadać możliwość przyłączania do niego dwóch i
więcej fizycznych kart sieciowych aby zapewnić bezpieczeństwo połączenia
ethernetowego w razie awarii karty sieciowej w serwerze lub na wypadek awarii innych
urządzeń sieci LAN.
Wirtualne przełączniki musza obsługiwać wirtualne sieci lokalne (VLAN).
Proponowane rozwiązanie wirtualizacji musi być wspierane także przez dostarczany w
ZP/PN/35/2014
ramach postępowania system backupowy.
Tabela 6.5 Inne wymagania dla systemu wirtualizacji
Lp Opis
1. Zakres wdrożenia systemu wirtualizacji obejmuje :
 instalację systemów operacyjnych wirtualizatora,
 konfigurację sieciową serwerów pozwalającą na podłączenie serwera do serwera
zarządzającego systemem wirtualizacji, przypisanie nazwy serwera, wpisanie
nazwy do systemu DNS,
 podłączenie i utworzenie klastra systemu wirtualizacji
 prezentację zasobów dyskowych dla klastra
 konfigurację sieciową klastra - konfiguracja odporna na awarię. Konfiguracja sieci
zarządzającej oraz dedykowanej sieci służącej do migracji maszyn wirtualnych
pomiędzy węzłami klastra
 konfigurację sieci produkcyjnych - utworzenie i dodanie do poszczególnych
serwerów sieci do których dołączane będą później serwery wirtualne. Podobnie jak
dla sieci zarządzającej konfiguracja ma być odporna na awarię.
 konfigurację zasobów dyskowych dla klastra systemu wirtualizacji
2.
powykonawczą obejmującą opis konfiguracji, która została wykonana w ramach wdrożenia
systemu wirtualizacji. Wykonawca zobowiązany jest przekazać zamawiającemu komplet
haseł administracyjnych. W szczególności powinno być przekazane hasło użytkownika za
pomocą którego poszczególne serwery zostały podłączone do serwera zarządzającego.
Dokumentacja powykonawcza musi zawierać także opis dodanych sieci VLAN do klastra
(opis przeznaczenia poszczególnych sieci).
Wdrożenie musi odbywać się na miejscu w obecności pracownika ze strony
Zamawiającego
3.
Zamawiający wymaga dostarczenia i wdrożenia kompletnego środowiska wirtualizacji.
Jeżeli jakieś elementy nie zostały uwzględnione w wymaganiach technicznych (licencje,
sprzęt, zakres prac wdrożeniowych itp.), a są niezbędne do poprawnego wdrożenia i
skonfigurowania systemu wirtualizacji Wykonawca zobowiązany jest te elementy
uwzględnić w ofercie i dostarczyć.
7. System usług katalogowych
Z uwagi na :
a. dużą heterogeniczność systemów do obsługi szpitali i jednostek służby zdrowia
b. wewnętrzny plan rozwoju systemów informatycznych szpitala
c. wymóg dostarczenia i wdrożenia klastra bazodanowego MSSQL,
d. wymóg aby inne systemy integrowały się z usługami katalogowymi (np.
infrastruktura wirtualizacji oraz inne, które zamawiający zamierza wdrożyć w
przyszłości)
Zamawiający wymaga dostarczenia systemu usług katalogowych opartych o rozwiązania
Microsoft Active Directory jako najbardziej uniwersalnej platformy służącej do obsługi stacji
roboczych, wdrożenia usług jednokrotnego logowania oraz integracji z innymi dostępnymi na
rynku systemami w ramach nadawania uprawnień w systemach. Dostarczenie innego systemu
posiadającego równoważne funkcjonalności musi zostać uzgodnione i zaakceptowane przez
Zamawiającego.
ZP/PN/35/2014
Lp
1.
2.
3.
4.
5.
8.
9.
Tabela 7.1 Opis wymagań dla usług katalogowych
Opis
Zamawiający wymaga dostarczenia kompletu licencji dostępowych na 350 jednocześnie
pracujących użytkowników w zakresie pozwalającym na legalny (zgodny z zasadami
licencjonowania producenta) dostęp do wszystkich serwerów Windows pracujących w
domenie ActiveDirectory.
Zamawiający wymaga dostarczenia licencji na serwerowy system operacyjny
zainstalowany na dedykowanym serwerze, na którym będzie działał kontroler usług
katalogowych.
Zamawiający wymaga dostarczenia innych niezbędnych licencji lub dodatkowych
elementów systemu usług katalogowych potrzebnych do prawidłowego działania oraz
legalnego użytkowania systemu.
W ramach dostarczonych licencji Zamawiający musi mieć możliwość instalacji najnowszej
wersji oprogramowania. Jeżeli któryś z systemów szpitala wymagałby starszej wersji usług
katalogowych, zamawiający powinien mieć możliwość wdrożenia starszej wersji lub
zainstalowania systemu w trybie zgodności ze starszą wersją.
Zamawiający wymaga uzgodnienia na etapie wdrożenia jaka wersja systemu ma być
zainstalowana i wdrożona.
Zamawiający wymaga wdrożenia usług katalogowych w następującym zakresie :
1.
Instalacja systemu operacyjnego na dedykowanym serwerze
2.
Konfiguracja roli kontrolera domeny zgodnie z zaleceniami producenta
3.
Instalacja drugiego kontrolera domeny na serwerze wirtualnym
4.
Konfiguracja drugiego kontrolera domeny zgodnie z zaleceniami producenta
5.
Konfiguracja backupu na kontrolerach domeny zgodnie z wymaganiami
dotyczącymi systemu backupu
6.
Konfiguracja domeny Active Directory w zakresie niezbędnym do instalacji i
wdrożenia pozostałych systemów będących przedmiotem postępowania : klaster
bazodanowy MSSQL, serwer zarządzający infrastrukturą wirtualizacji, serwer plików,
utworzenie użytkowników administracyjnych dla poszczególnych systemów, utworzenie
grup zabezpieczeń itp.
7.
Instalacja usługi KMS do aktywacji systemów operacyjnych
Zamawiający wymaga dostarczenia kompletnej dokumentacji technicznej z opisem
składowych systemu oraz z opisem tego co zostało wdrożone
Zamawiający wymaga montażu serwera we wskazanej przez Zamawiającego szafie RACK.
Serwer musi być dostarczony z zestawem kabli zasilających oraz kabli LAN ze świetlną
identyfikacją połączeń kategorii min 6.
Tabela 7.2 Wymagania techniczne dla serwera usług katalogowych
Lp. Wymaganie
Opis
1.
Obudowa
2.
Procesor
w/w testów.
3.
Liczba procesorów
Minimum 2.
4.
Pamięć operacyjna
5.
Sloty rozszerzeń
ZP/PN/35/2014
6.
Dysk twardy
7.
Kontrolery dyskowe
8.
Karty sieciowe
10.
11.
Karta graficzna
Porty
12.
13.
Zasilacz
System operacyjny
2,5”,
Kontrolery macierzowe SAS wyposażony w pamięć cache
Wake-On-LAN, RJ45.
1 x szeregowy
VGA.
Licencja na system operacyjny pozwalająca na obsługę
całej dostępnej w systemie operacyjnym pamięci RAM
oraz na instalację usług katalogowych.
8. Klaster bazodanowy Oracle
W ramach wdrożenia zamawiający wymaga dostarczenia oraz zainstalowania klastra
bazodanowego Oracle Standard Edition.
Tabela 8.1 Wymagania dotyczące wdrożenia klastra bazodanowego Oracle
Lp Opis
1. W ramach prowadzonego postępowania Zamawiający wymaga dostarczenia minimum
dwóch licencji procesorowych typu full use na silnik bazodanowy Oracle Standard Edition z
minimum trzyletnią asystą techniczną pozwalajacą na wgrywanie poprawek
bezpieczeństwa oraz aktualizację do nowszych wersji oprogramowania.
2. W ramach prowadzonego postępowania Zamawiający wymaga dostarczenia licencji na
system operacyjny RedHat Enterpise Linux, Oracle Enterprise Linux lub inny certyfikowany
do pracy z silnikiem bazodanowym z minimum 3 letnią subskrypcją pozwalającą na
aktualizację systemu.
Licencje muszą objąć dwa serwery kasetowe, dwuprocesorowe, na których będą
zainstalowane węzły klastra bazodanowego.
3. Dostarczany system operacyjny musi być wspierany przez dostarczany system backupowy
4. W ramach wdrożenia zamawiający wymaga przeprowadzenia następujących prac
konfiguracyjnych:
 Przygotowanie serwerów kasetowych do instalacji systemów operacyjnych
 Konfiguracja sieci na serwerach kasetowych
 Przygotowanie zasobów dyskowych na macierzy dyskowej
 Instalacja systemów operacyjnych na serwerach kasetowych
ZP/PN/35/2014
5.
6.
W ramach instalacji systemów operacyjnych zamawiający wymaga:
 Zamawiający nie dopuszcza utworzenia jednego dużego obszaru :/ . Zamawiający
wymaga wykorzystania lvm-a i podział obszaru dyskowego na dyskach lokalnych
serwera na oddzielne wolumeny : /, /etc, /opt, /var, /usr, /u01, /home, oraz innych
zalecanych dla systemu .
 Zamawiający nie dopuszcza utworzenia jednego dużego obszaru na pliki bazy danych.
Zamawiający wymaga przygotowania zasobów dyskowych na macierzy dla : plików
bazy danych, plików redo log, plików archive log, obszaru Flash Recovery Area, oraz
innych zoptymalizowanych do uzyskania jak najlepszej wydajności systemu
bazodanowego.
 Obszary na macierzy przeznaczone dla plików bazy danych muszą być skonfigurowane
do zwiększania wydajności poprzez wykorzystanie mechanizmów macierzy i dysków
SSD.
W ramach wdrożenia zamawiający wymaga dostarczenia kompletnej dokumentacji
obejmującej :
 Informację o dostarczonym sprzęcie i licencjach
 Informację jak zostały skonfigurowane serwery (adresacja IP, nazwy serwerów, jakie
VLANy, podział dysków itp.)
 Informację o gwarancjach na sprzęt i wykupionej asyście technicznej na
oprogramowanie bazodanowe oraz systemy operacyjne (certyfikat licencyjny
potwierdzający typ oraz ilość licencji oraz na kogo jest wystawiona)
 Informację o konfiguracji systemów operacyjnych
 Informację o konfiguracji klastra bazodanowego
 Informację o konfiguracji instancji bazodanowej
 Informację o konfiguracji zasobów dyskowych na macierzy i zastosowanych
mechanizmów
 Informację o konfiguracji backupów
9. Klaster bazodanowy MSSSQL
W ramach wdrożenia zamawiający wymaga dostarczenia oraz zainstalowania
oprogramowania bazodanowego jako klastra Microsoft SQL
Tabela 9.1 Wymagania dotyczące wdrożenia klastra bazodanowego MSSQL
Lp Opis
1. W ramach prowadzonego postępowania Zamawiający wymaga dostarczenia kompletu
licencji procesorowych pozwalających na instalację oraz legalne użytkowanie klastra
bazodanowego na dwóch serwerach kasetowych jednoprocesorowych. (licencje
procesorowe dla ośmiordzeniowego procesora, x86-64 bity Intel Xeon E5-2667 v2.
Dostarczana licencja musi mieć wykupione minimum 3 letnie wsparcie producenta
pozwalające na instalację nowych wersji oprogramowania (jeżeli w ciągu 3 lat pojawi się
nowa wersja oprogramowania).
2. W ramach prowadzonego postępowania Zamawiający wymaga dostarczenia licencji na
system operacyjny dla serwerów na których będzie zainstalowane oprogramowanie
bazodanowe (dwa serwery kasetowe jednoprocesorowe). System musi pozwalać na
obsługę całej zainstalowanej pamięci operacyjnej w serwerze na którym będą działały
węzły klastra bazodanowego.
3. Dostarczany system operacyjny musi być wspierany przez dostarczany w ramach
postępowania system backupowy
ZP/PN/35/2014
4.
5.
6.
7.
8.
9.
W ramach wdrożenia zamawiający wymaga przeprowadzenia następujących prac
konfiguracyjnych:
 Przygotowanie serwerów kasetowych do instalacji systemów operacyjnych
 Konfiguracja sieci na serwerach kasetowych i na obudowie serwerowej
 Przygotowanie zasobów dyskowych na macierzy dyskowej
 Instalacja systemów operacyjnych na serwerach kasetowych
 Instalacja usług klastrowych (failover cluster)
 Instalacja klastra bazodanowego
 Utworzenie i podstawowa konfiguracja instancji bazodanowej
 Konfiguracja systemu backupu na systemach operacyjnych
 Konfiguracja systemu backupu do wykonywania kopii bezpieczeństwa bazy danych
(utworzenie skryptów harmonogramów, konfiguracja zadań backupowych)
W ramach instalacji systemów operacyjnych oraz instancji bazodanowej zamawiający
wymaga:
 Utworzenia osobnych obszarów na macierzy dyskowej dla : plików bazy danych, logów
dziennika powtórzeń, bazy danych tempdb
 Zasoby dyskowe muszą być skonfigurowane pod kątem uzyskania jak największej
wydajności podsystemu dyskowego
 Systemy plików na których będą się znajdowały pliki bazy danych muszą być
sformatowane z odpowiednią wielkością bloku (zoptymalizowaną do uzyskania jak
największej wydajności i zminimalizowania operacji IO)
 Obszary na macierzy przeznaczone dla plików bazy danych muszą być skonfigurowane
do zwiększania wydajności poprzez wykorzystanie mechanizmów macierzy i dysków
SSD.
 Zamawiający wymaga użycia nazwanej instancji bazodanowej
 Zamawiający wymaga użycia statycznego portu 1433 dla instancji bazodanowej
 Zamawiający wymaga instalacji pozostałych usług (reporting services, integration
services)
 Zamawiający wymaga instalacji wszystkich pakietów poprawek dostępnych na dzień
instalacji klastra bazodanowego
 Zamawiający wymaga instalacji usług bazodanowych w trybie mixed-mode (możliwość
uwierzytelniania zarówno bazodanowego jak również na podstawie poświadczeń w
domenie Active Directory)
Zamawiający wymaga aby nazwana instancja bazodanowa była zainstalowana i
skonfigurowana w taki sposób, aby możliwa była późniejsza współpraca z systemem
Microsoft Sharepoint.
W ramach wdrożenia zamawiający wymaga dostarczenia kompletnej dokumentacji
obejmującej :
 Informację o dostarczonym sprzęcie i licencjach
 Informację jak zostały skonfigurowane serwery (adresacja IP, nazwy serwerów, jakie
Vlany, podział dysków itp.)
 Informację o gwarancjach na sprzęt i wykupionej asyście technicznej na
oprogramowanie bazodanowe
 Informację o konfiguracji systemów operacyjnych
 Informację o konfiguracji klastra bazodanowego
 Informację o konfiguracji instancji bazodanowej
 Informację o konfiguracji zasobów dyskowych na macierzy i zastosowanych
mechanizmów
 Informację o założonych użytkownikach
 Informację o konfiguracji backupów
Zamawiający wymaga przekazania listy użytkowników oraz haseł do wszystkich
użytkowników założonych podczas wdrożenia klastra bazodanowego zarówno w systemie
operacyjnym jak i w systemie Active Directory dla klastra bazodanowego : administrator,
sa, konta stworzone dla poszczególnych usług
Opis wymagań dla serwerów klastra bazodanowego został opisany w punkcie dotyczącym
wymagań na serwery kasetowe.
ZP/PN/35/2014
10. Serwer na potrzeby aplikacji Windows
W ramach prowadzonego postępowania Zamawiający wymaga dostarczenia dwóch
dodatkowych, dedykowanych serwerów dla aplikacji działających pod kontrolą systemu
Windows Serwer.
Tabela 10.1 Wymagania techniczne dla dodatkowego serwera aplikacji
Wymaganie
Opis
Obudowa
2.
Procesor
w/w testów.
3.
Liczba procesorów
Minimum 2.
4.
Pamięć operacyjna
5.
Sloty rozszerzeń
6.
Dysk twardy
2,5”,
7.
Kontrolery dyskowe
Kontroler macierzowy SAS wyposażony w pamięć cache
8.
Karty sieciowe
Wake-On-LAN, RJ45.
9.
Karty SAN
Minimum dwie minimum jednoportowe karty sieci SAN
o prędkości minimum 8Gbit każda umożliwiająca wpięcie
10. Karta graficzna
11. Porty
1 x szeregowy
VGA.
12. Zasilacz
13. System operacyjny
Licencja na serwerowy system operacyjny Windows
Serwer pozwalająca na obsługę całej dostępnej w
systemie operacyjnym pamięci RAM.
Lp.
1.
ZP/PN/35/2014
11. Inne urządzenia i wymagania
Tabela 11.1 Wymagania techniczne dla pozostałych urządzeń
Lp Opis
1. Zamawiający wymaga dostarczenia dwóch konsoli graficznych KVM o wysokości 1U –
zintegrowana klawiatura wraz z monitorem przeznaczona do montażu w szafie RACK.
2. Zamawiający wymaga dostarczenia dwóch przełączników KVM z możliwością łączenia w
stos, minimum 16 portowych, o wysokości 1U, z możliwością podłączenia się do konsoli
przełącznika i do konsoli graficznej podłączonych serwerów przez sieć LAN dla minimum
jednego użytkownika. Zamawiający wymaga dostarczenia przełącznika KVM, którego
montaż będzie możliwy w tej samej przestrzeni U w szafie RACK co konsola graficzna (z
tyłu konsoli). Przełącznik musi mieć możliwość podłączenia w stack dodatkowych
przełączników tego samego typu. Porty w przełączniku KVM do podłączenia serwerów :
RJ45. Przełącznik musi mieć możliwość zdalnego podłączenie napędów do serwera.
3. Komplet 32 adapterów pozwalający na podłączenie serwerów do przełącznika KVM.
Tabela 11.2 Wymagania dotyczące prac konfiguracyjnych
Opis
Zamawiający wymaga aby w ramach wdrożenia Wykonawca skonfigurował dostarczane
przez siebie systemy do automatycznego wyłączania się w przypadku poważnych awarii
zasilania (dotyczy całkowitych zaników zasilania). Wymaganie dotyczy współpracy z UPS.
Zamawiający wymaga aby podczas wyłączania zachowana była kolejność wyłączania się
systemów, tak aby całość systemów wyłączyła się w sposób czysty.
2. Zamawiający wymaga aby prace wdrożeniowe, instalacyjne oraz konfiguracyjne były
wykonywane przez :
 instalacja i wstępna konfiguracja macierzy dyskowej - serwis producenta macierzy
 konfiguracja macierzy dyskowej - certyfikowany inżynier z zakresu oferowanej
macierzy dyskowej
 instalacja i wstępna konfiguracja obudowy serwerowej - serwis producenta lub
certyfikowany inżynier wykonawcy
 instalacja i konfiguracja systemu wirtualizacji - certyfikowany w zakresie
oferowanego systemu wirtualizacji inżynier
 instalacja i konfiguracja systemu backupu - certyfikowany w zakresie oferowanego
systemu backupu inżynier
 pozostałe prace - inżynierowie Wykonawcy posiadający niezbędne doświadczenie
w zakresie instalacji i konfiguracji poszczególnych systemów
Lp
1.
12. Licencje
W ramach prowadzonego postępowania zamawiający wymaga dostarczenia kompletu
licencji na dostarczane podsystemy (systemy operacyjne, system backupu, systemy
bazodanowe, system wirtualizacji oraz inne oprogramowanie dostarczane w ramach
zamówienia). Zamawiający wymaga, aby wszystkie dostarczane w ramach postępowania
licencje były bezterminowe, objęte minimum 3 letnim wsparciem producenta
oprogramowania, w ramach którego Zamawiający będzie miał prawo do instalacji nowszych
wersji oprogramowania, jeżeli nowe wersje oprogramowania zostaną one wydane w okresie
obejmującym wsparcie techniczne.
Licencje systemów Microsoft powinny zostać zarejestrowane na koncie Zamawiającego.
w firmie Microsoft. Jeżeli w firmie Microsoft Zamawiający nie posiada konta to takie konto
powinno zostać utworzone
W ramach dostawy licencji na oprogramowanie Wykonawca jest zobowiązany do
dostarczenia kluczy licencyjnych oraz certyfikatów licencyjnych potwierdzających typ licencji,
ilość licencji, na kogo jest zarejestrowana licencja, potwierdzenie że na oprogramowanie
zostało wykupione wsparcie techniczne producenta.
Wszystkie dostarczone licencje muszą umożliwiać legalne i nieodpłatne korzystanie z
dostarczonych systemów przez spółkę Nowy Szpital Wojewódzki Sp. z o.o. oraz podmiot
trzeci – dzierżawcę obiektu – Dolnośląski Szpital Specjalistyczny im. T. Marciniaka.
ZP/PN/35/2014
Lp
1.
Tabela 12.1 Wymagania dotyczące dodatkowych licencji
Opis
Dostawa licencji Microsoft Datacenter dla 3 dwuprocesorowych serwerów kasetowych
wchodzących w skład klastra systemu wirtualizacji.
13. Montaż urządzeń
Tabela 13.1 Wymagania dotyczące montażu urządzeń
Opis
Zamawiający wymaga zamontowania urządzeń we wskazanych szafach RACK
Podczas montażu Zamawiający wymaga szczególnej dbałości o porządek i ułożenie kabli
zasilających, LAN oraz światłowodowych (tam gdzie zajdzie potrzeba należy pospinać
kable opaskami rzepowymi lub zastosować poziome lub pionowe organizery kablowe)
3. Zamawiający wymaga zastosowania do podłączenia urządzeń kabli Ethernet ze świetlną
identyfikacją połączeń (okablowanie typu patchsee lub równoważne)
4. W ramach postępowania Zamawiający wymaga dostarczenia minimum 2 dedykowanych
źródeł światła do okablowania ze świetlną identyfikacją połączeń (dwie dedykowane latarki
do kabli Ethernet)
5. Zamawiający wymaga oznaczenia wszystkich kabli sieciowych i światłowodowych (LAN
oraz SAN) samoprzylepnymi (samolaminującymi ) się etykietkami. Wytyczne do
oznaczenia kabli w serwerowi zostaną przekazane na etapie wdrożenia. Nadruki na
nalepkach muszą być czytelne i trwałe.
Jeżeli wykonawca posiada inny system oznaczeń kablowych i chciałby go
wykorzystać do opisu okablowania zamiast nalepek samolaminujących to zobowiązany jest
to uzgodnić z zamawiającym na etapie wdrożenia. Jeżeli zamawiający nie zaakceptuje
zaproponowanego rozwiązania wykonawca zobowiązany jest użyć nalepek
samolaminujących się i wykonania nadruków na nalepkach.
Lp
1.
2.
Wykonawca zobowiązany jest dostarczyć niezbędne kable potrzebne do podłączenia i
prawidłowej pracy urządzeń serwerowo-macierzowych. Długości wszystkich kabli
światłowodowych (SAN) oraz Ethernet (LAN) musi zostać dobrana w sposób optymalny,
tak aby w szafach RACK nie było zbyt długich nadmiarów kabli Ethernet oraz
światłowodowych. Wymaganiem zamawiającego jest aby Wykonawca miał odpowiedni
zapas patchcordów poszczególnego typu
7. Zamawiający wymaga oznaczenia wszystkich dostarczonych urządzeń za pomocą nalepek
z nadaną nazwą urządzenia w celu łatwiejszej identyfikacji w serwerowni. Koncepcja
nazewnicza serwerów oraz urządzeń zostanie uzgodniona na etapie wdrożenia systemu.
8. Zamawiający wymaga podłączenia wszystkich interfejsów zarządzających do dedykowanej
(wskazanej przez Zamawiającego) sieci VLAN
9. Wszędzie tam gdzie zajdzie potrzeba zamawiający wymaga dostarczenia organizerów
kablowych w celu organizacji i ułożenia kabli w szafach RACK. Wymaganiem
zamawiającego jest zamontowanie poziomych organizerów kablowych 1U pod każdym
przełącznikiem sieci SAN, a także z tyłu obudowy blade (tuż nad lub tuż pod obudową).
Dostarczenie dodatkowych organizerów zostanie ustalone na etapie wdrożenia oraz
montażu urządzeń. Wykonawca powinien przewidzieć zapas kilku organizerów kablowych.
10. Przed rozpoczęciem wdrożenia i instalacji urządzeń Zamawiający wymaga uzgodnienia
koncepcji nazewniczej dla dostarczonych urządzeń.
6.
14. Analizator sieci
Dopuszcza się zaoferowanie kilku urządzeń spełniających łącznie podane parametry, pod
warunkiem że zaoferowane urządzenia będą współpracowały z jednym (tym samym)
programem do raportowania.
ZP/PN/35/2014
Tabela 14.1 Wymagania dotyczące analizatora sieci
l.p. Opis
1.
Pomiary sieci:
 miedzianej dla skrętki kat. 6 i kat. 7
 optycznej (długość fali 1310nm)
 WiFi (802.11 a/b/g/n)
2.
Duży kolorowy wyświetlacz LCD min. 3,5”
3.
Graficzna prezentacja wyników pomiarów, np. wykresy
4.
Mapa połączeń
5.
Detekcja uszkodzeń:
 Zwarcia par kabli
 Złego rozszycie par
 Przerwania przewodu (nieciągłość)
6.
Pomiar długości pojedynczych żył kabla, odległości od zwarcia
7.
Wykrycie PoE z pomiarem napięcia i mocy
8.
Obsługa sieci 100/1000 Mb/s
9.
Obsługa protokołów IPv4, IPv6
10.
Obsługa VLAN
11.
Obsługa DHCP
12.
Analiza ruchu sieci VoIP
13.
Tryb pętli dla pomiaru miedzi i światłowodu
14.
Wykrycie aktywnego włókna optycznego
15.
Hub Blink (Miganie diody portu w urządzeniu aktywnym w celu identyfikacji)
16.
Ping i Traceroute
17.
Zapisywanie pomiarów
18.
Eksport pomiarów do zewnętrznych programów raportujących
19.
Graficzna prezentacja wykorzystania pasma sieci WLAN obejmująca:
 Kanały
 Moc sygnału
 Zakłócenia
20.
Oprogramowanie raportujące na PC w zestawie
15. Dokumentacja techniczna
W ramach wdrożenia Zamawiający wymaga dostarczenia kompletnej dokumentacji
powykonawczej z opisem tego co i jak zostało skonfigurowane. Dokumentacja dostarczona
w ramach postępowania powinna zawierać minimum elementy wymienione w tabeli 15.1.
Lp
1.
2.
3.
4.
5.
Tabela 15.1 Wymagania dotyczące dokumentacji powykonawczej
Opis
Spis wszystkich urządzeń łącznie z numerami seryjnymi
Informację dotyczącą tego do kiedy sprzęt objęty jest gwarancją producenta
Informację gdzie i jak zgłaszać problemy oraz usterki techniczne
Informację o rozlokowaniu sprzętu w szafach RACK
Informację o adresacji dla poszczególnych sieci (adres sieci, maska, brama)
ZP/PN/35/2014
Informację w postaci tabelarycznej o nadanej adresacji IP dla wszystkich urządzeń
dostarczonych i zamontowanych w serwerowni
7. Informację o założonych użytkownikach w poszczególnych systemach. Wymaganiem
zamawiającego jest aby na etapie wdrożenia wszystkie domyślne hasła administratora na
urządzeniach zostały zmienione. Do wdrożenia i konfiguracji oraz do celów serwisowych
Wykonawca powinien używać dedykowanych kont z uprawnieniami administratora.
8. Informację o konfiguracji poszczególnych urządzeń
9. W ramach dostarczenia dokumentacji powykonawczej Zamawiający wymaga dostarczenia
haseł do wszystkich założonych na etapie wdrożenia użytkowników (za wyjątkiem
dedykowanych użytkowników założonych na potrzeby wykonawcy). Wymaganiem
zamawiającego jest aby lista założonych użytkowników oraz zmienionych haseł dla
domyślnych użytkowników administracyjnych na poszczególnych urządzeniach została
dostarczona w bezpiecznej formie (np. w formie pliku kepass lub innej uzgodnionej na
etapie wdrożenia). W ramach odbioru zamawiający zweryfikuje zgodność haseł.
10. Procedury disaster recovery – opis procedur dla poszczególnych systemów wdrożonych
przez Wykonawcę (serwer backupowy, kontrolery domeny, klaster SQL, klaster Oracle,
11. Inne istotne opisy konfiguracyjne.
6.
16. Szkolenia
Tabela 16. 1 Lista wymaganych szkoleń certyfikowanych
Lp
Opis
1.
Szkolenie dla trzech osób z instalacji, wdrażania, utrzymania systemu wirtualizacji
a) Instalacja i konfiguracja systemu,
b) Zarządzanie zasobami i infrastrukturą,
c) Kontrola dostępu do wirtualnych maszyn,
d) Monitorowanie i utrzymanie systemu.
2.
Szkolenie dla trzech osób z instalacji, wdrażania, utrzymania systemu backupu
a) Instalacja i konfiguracja systemu,
b) Zarządzanie zasobami i infrastrukturą,
c) Monitorowanie i utrzymanie systemu.
Certyfikowane szkolenia muszą odbywać się w autoryzowanym przez producenta systemu
ośrodku szkoleniowym, muszą zakończyć się wystawieniem imiennego certyfikatu.
Warunki dostawy szkoleń – dostawa asygnat (voucherów) na certyfikowane szkolenia
producenta. Szkolenia musza obejmować zakresem merytorycznym wszystkie wymienione
powyżej obszary merytoryczne. Asygnaty ( voucher-y) muszą być wystawione osobno dla
każdego z dwóch zakresów merytorycznych, ważne przez okres 24 miesięcy. Szkolenia
będą się odbywały po wcześniejszym ustaleniu terminu jednak nie później niż 30 dni przed
planowanym przez producenta szkoleniem.
Lp
1.
2.
3.
4.
5.
Tabela 16.2 Warsztaty dla administratorów
Opis
Po zakończonym wdrożeniu Zamawiający wymaga organizacji przez wykonawcę
warsztatów dla wskazanej grupy administratorów systemów na których zostanie omówiona
konfiguracja wszystkich wdrożonych systemów oraz urządzeń.
Wykonawca zobowiązany jest do odpowiedzi na zadawane pytania i udzielenia
wyczerpujących wyjaśnień.
Zakres warsztatów musi być wcześniej uzgodniony z zamawiającym.
Minimalny czas warsztatów zorganizowanych przez wykonawcę : 5 dni roboczych na
których zostanie omówiony uzgodniony zakres warsztatów
Maksymalny czas warsztatów: 10 dni – w przypadku gdyby okazało się że 5 dni roboczych
to czas zbyt krótki na omówienie konfiguracji poszczególnych urządzeń.
.
ZP/PN/35/2014
17. Warunki odbioru
Tabela 17.1 Warunki odbioru
Lp Opis
1
Dostawa urządzeń fabrycznie nowych spełniających wymagania określone w opisie
przedmiotu zamówienia
2
Montaż urządzeń zgodnie z wytycznymi określonymi w opisie przedmiotu zamówienia
3
Instalacja i konfiguracja systemów zgodnie z wymaganiami określonymi w opisie
przedmiotu zamówienia (systemy muszą spełniać wymagania, muszą być przygotowane do
obsługi szpitala i uruchomienia innych systemów produkcyjnych)
4
Na etapie odbioru Zamawiający zweryfikuje odporność oraz konfigurację systemów na
wystąpienie awarii (dotyczy połączeń sieciowych, światłowodowych, obsługa
wielościeżkowości, konfiguracja klastrów systemu wirtualizacji, przełączanie się klastrów
bazodanowych)
5
Na etapie odbioru Zamawiający zweryfikuje konfigurację systemu backupu (dla losowo
wybranych systemów spróbuje odzyskać z kopii zapasowej określone elementy : pliki,
drzewo plików, bazę danych, poszczególne pliki maszyny wirtualnej, całą maszynę
wirtualną oraz inne elementy zgodne z wymaganiami).
6
Dostarczenie kompletnej dokumentacji technicznej w wersji papierowej oraz elektronicznej
edytowalnej.
7
Dostarczenie voucherów na certyfikowane szkolenia
8
Przeprowadzenie warsztatów dla administratorów
ZP/PN/35/2014

macierzowej dla Szpitala Wojewódzkiego

Transkrypt

Podobne dokumenty

Dot. ZP WORD 2/pojazd + wideo/2015 W oparciu o art. 38 ustawy

Załącznik nr 4 do umowy PROTOKÓŁ ODBIORU* usług

Szczecin, 23.02.2016 r. Dot.: postępowania przetargowego na

Pszczyna, dnia 20

Wyjaśnienie nr5 do SIWZ Orlik2012_3

Polska Telefonia Komórkowa Centertel Sp. z oo ul

WYJAŚNIENIE do zapytania ofertowego nr 12/2016 powodujące

Zawiadomienie o wynikach postępowania (02.06.2014 r.)

strona internetowa