Opis przedmiotu zamówienia

Transkrypt

Część III SIWZ
Opis przedmiotu zamówienia
1 Wymagania
w
zakresie
dostaw
Oprogramowania Systemowego
Standardowego
Przedmiotem zamówienia jest dostawa oprogramowania wraz licencjami oraz prawami do uaktualniania
oprogramowania – dalej łącznie nazywanych Produktami.
Produkty objęte przedmiotowym zamówieniem mają charakter powszechnie dostępnych na rynku (typu
Commercial off-the-shelf - COTS).
W ramach przedmiotu zamówienia Wykonawca może zaoferować oprogramowanie używane przez
Zamawiającego, wymienione w pkt. 6, ppkt. 1.1-1.4. („Charakterystyka środowiska Zamawiającego”) lub
inne równoważne, tj. spełniające niżej opisane wymagania dla tych oprogramowań.
Zamawiający wymaga dostawy Produktów na warunkach opisanych w SIWZ.
2 Specyfikacja ilościowa
Tabela 1. Lista wymaganego oprogramowania.
L.P.
Oprogramowanie
1.
Oprogramowanie serwerowe
portalu wielofunkcyjnego
2.
relacyjnej bazy danych
3.
Serwerowy system operacyjny z
elementami zarządzania typ I
4.
Serwerowy system operacyjny z
elementami zarządzania typ II
5.
platformy usług integracyjnych
Opis wymagań
Typ licencji
Rozdział 4.1.
Licencja na 4 serwery.
Rozdział 4.2.
Licencja na 8 rdzeni procesora przy
założeniu, że 1 instalacja będzie
dysponowała min. 2 rdzeniami.
Rozdział 4.3.
Licencja na dwa serwery
dwuprocesorowe, sześciordzeniowe.
Rozdział 4.4.
Licencja na osiem serwerów
dwuprocesorowych,
dziesięciordzeniowych.
Rozdział 4.5.
Licencja na dwa serwery
dwuprocesorowe, czterordzeniowe.
3 Licencje
Oferowane oprogramowanie powinno spełniać co najmniej poniższe warunki licencyjne.
1. Postanowienia ogólne
1.1. Uprawnienia z licencji na korzystanie ze Standardowego Oprogramowania Systemowego
Zamawiający nabywa z chwilą jego Odbioru.
1.2. Wykonawca oświadcza i gwarantuje, że warunki korzystania z Oprogramowania nie wymagają
ponoszenia dodatkowych opłat na rzecz Wykonawcy lub producentów takiego
Oprogramowania. Wynagrodzenie obejmuje całość wynagrodzenia za korzystanie z
Oprogramowania.
1.3. Wykonawca oświadcza i gwarantuje, że jeżeli w ramach opłat należnych producentowi
Oprogramowania mieści się opłata za jakiekolwiek dodatkowe świadczenia, w szczególności
dostarczanie aktualizacji lub poprawek błędów lub inne usługi serwisowe, nieprzedłużenie
korzystania z tych świadczeń przez Zamawiającego nie może powodować ustania licencji na
korzystanie z Oprogramowania lub uprawniać do wypowiedzenia umowy licencyjnej.
1.4. Wykonawca dostarczy Oprogramowanie na informatycznych nośnikach danych lub w innej
postaci umożliwiającej prawidłową instalację tego Oprogramowania oraz certyfikaty
autentyczności, klucze instalacyjne oraz inne dokumenty i zabezpieczenia najpóźniej w dacie
Odbioru tego Oprogramowania, chyba że z Umowy wynika inna data przekazania.
1.5. Informatyczne nośniki danych, kopie, certyfikaty autentyczności, klucze instalacyjne oraz inne
dokumenty i zabezpieczenia, o których mowa w poprzednim ustępie, powinny być zgodne
z wymaganiami określonymi przez producenta Oprogramowania. Zamawiający jest uprawniony
do weryfikacji, czy certyfikaty autentyczności, klucze instalacyjne oraz inne dokumenty
i zabezpieczenia są wystarczające i zgodne z wymogami określonymi przez producenta. W tym
celu Zamawiający może zwracać się do osób trzecich, w tym producenta Oprogramowania.
1.6. Wykonawca zapewnia, że korzystanie z Oprogramowania podczas realizacji i na cele Umowy,
w szczególności w okresie testów, nie będzie naruszać praw osób trzecich i nie będzie
wymagało żadnych opłat na rzecz takich osób. Gdyby okazało się to konieczne, Wykonawca w
ramach Wynagrodzenia udzieli lub zapewni udzielenie stosownej licencji na czas realizacji
Umowy obejmującej prawo korzystania z Oprogramowania na potrzeby realizacji Umowy do
czasu uzyskania – odpowiednio – praw majątkowych lub docelowych licencji opisanych Umową.
Prawo do korzystania obejmuje w szczególności trwałe lub czasowe zwielokrotnianie
Oprogramowania w całości lub w części, a także tłumaczenie, przystosowywanie, zmiany układu
lub wprowadzanie jakichkolwiek innych zmian do Oprogramowania.
1.7. Wykonawca jest odpowiedzialny, względem Zamawiającego, za wszelkie wady prawne,
a w szczególności za ewentualne roszczenia osób trzecich wynikające z naruszenia praw
własności intelektualnej, w tym praw wynikających z ustawy o prawie autorskim i prawach
pokrewnych.
1.8. Zamawiający będzie jedynym właścicielem autorskich praw majątkowych do utworów, które
wytworzy przy wykorzystaniu dostarczonego przez Wykonawcę Oprogramowania.
1.9. Licencja nie jest ograniczona terytorialnie. Zamawiający może użytkować oprogramowanie na
terenie oraz za granicami RP.
2. Postanowienia szczegółowe
2.1. Zakres licencji obejmuje następujące pola eksploatacji:
2.1.1. Przenoszenie Oprogramowania pomiędzy urządzeniami komputerowymi(np. w
przypadku wymiany stacji roboczej lub serwera).
2.1.2. Instalacja Oprogramowania poprzez wykorzystanie wspólnych i jednolitych procedur
masowej instalacji, uaktualniania, zarządzania, monitorowania i wsparcia technicznego.
2.1.3. Korzystanie z wcześniejszych-starszych wersji zamawianego Oprogramowania (tzw.
Downgrade).
2.1.4. Korzystania z kopii zamiennych (możliwość instalacji Oprogramowania na wielu
urządzeniach przy wykorzystaniu jednego standardowego obrazu tzw.„image”), z
2
2.1.5.
2.1.6.
2.1.7.
2.1.8.
prawem do wielokrotnego użycia jednego obrazu w procesie instalacji i tworzenia kopii
zapasowych.
Używania i korzystania z Oprogramowania oraz ich pojedynczych elementów przez
Zamawiającego,
Trwałego lub czasowego utrwalania lub zwielokrotniania Oprogramowania w całości lub
w części, jakimikolwiek środkami i w jakiejkolwiek formie, niezależnie od formatu,
systemu lub standardu, w tym wprowadzania do pamięci komputera i serwerów sieci
komputerowych oraz trwałego lub czasowego utrwalania lub zwielokrotniania takich
zapisów, włączając w to sporządzanie ich kopii oraz dowolnego korzystania i
rozporządzania tymi kopiami.
Tłumaczenia, przystosowywania, zmiany układu lub jakichkolwiek innych zmian
w Oprogramowaniu.
Rozpowszechniania, w tym użyczania Oprogramowania podmiotom współpracującym z
Zamawiającym (w tym Wojewódzkie Fundusze Ochrony Środowiska i Gospodarki
Wodnej, Centrum Koordynacji Projektów Środowiskowych, właściwe ministerstwa).
3. Postanowienia pozostałe
3.1. Aktualizacje (tzw. Upgrade)oferowanego oprogramowania do najnowszych wersji
udostępnionych przez producenta oprogramowania przez okres 3 lat od daty odbioru
oprogramowania wymienionego w tabeli nr 1 (Lista wymaganego oprogramowania),w tym
także aktualizacji bezpieczeństwa.
3.2. Aktualizacje, poprawki, rozszerzenia do ostatniej wersji oprogramowania udostępnionej przez
producenta oprogramowania, przez okres co najmniej kolejnych 2 lat od daty otrzymania przez
Zamawiającego tej wersji o ile, w chwili otrzymania przez Zamawiającego tej wersji nie upłynął
termin, o którym mowa w ustępie powyżej.
3.3. Wykonawca zapewni dostęp do spersonalizowanej strony internetowej(tzw. Konto Zakupowe
Zamawiającego) pozwalającej Zamawiającemu na:
3.3.1.pobieranie zakupionego oprogramowania,
3.3.2.pobieranie kluczy aktywacyjnych do zakupionego oprogramowania,
3.3.3.sprawdzanie liczby zakupionych licencji w wykazie zakupionych produktów,
3.3.4.jeżeli nowa wersja oprogramowania zawiera bardziej restrykcyjne prawa licencyjne do
używania niż wersja, która była oferowana na dzień wyznaczony, jako termin składania
ofert, te bardziej restrykcyjne prawa do używania nie będą miały zastosowania do
korzystania z tego oprogramowania przez Zamawiającego.
3.4. Konto Zakupowe Zamawiającego musi pozwalać na tworzenie niezależnie zarządzanych
subkont dla jednostek Zamawiającego, z nadawaniem odpowiednich uprawnień wskazanym
przedstawicielom tych jednostek.
3.5. Po zakończenia okresu o którym mowa w pkt. 3.1, jeżeli Strony umowy nie postanowią inaczej,
nastąpi wyłączenie konta na spersonalizowanej stronie Zamawiającego i usunięcie jego danych.
4. Czas trwania umowy licencyjnej
4.1. intencją Stron jest zbliżenie udzielenia licencji przez Wykonawcę do Oprogramowania do
umowy o charakterze jednorazowej transakcji podobnej do sprzedaży – w związku z tym w
zamian za uiszczoną opłatę licencyjną (stanowiącą w przypadku Umowy element
Wynagrodzenia) Zamawiający otrzymuje ciągłe, stałe i niewypowiadalne prawo do
korzystania z takiego Oprogramowania w zakresie określonym w Umowie.
4.2. W przypadku gdyby postanowienie o nie wypowiadalności licencji na Oprogramowanie
przewidziane w poprzednim ustępie okazało się nieskuteczne lub nieważne, a Wykonawca
3
4.3.
4.4.
4.5.
4.6.
byłby uprawniony do wypowiedzenia licencji, Strony uzgadniają dla Wykonawcy 10-letni
(słownie: dziesięcioletni) termin jej wypowiedzenia ze skutkiem na koniec roku
kalendarzowego, z zastrzeżeniem ustępu następnego.
Wykonawca zobowiązuje się nie korzystać z uprawnienia do wypowiedzenia licencji
z wyjątkiem przypadków, w których Zamawiający przekroczy warunki udzielonej licencji i
naruszy autorskie prawa majątkowe przysługujące Wykonawcy oraz nie zaniecha
naruszenia mimo wezwania Wykonawcy i wyznaczenia mu w tym celu odpowiedniego
terminu, nie krótszego niż 30 dni. Wezwanie musi być wystosowane w formie pisemnej pod
rygorem braku skutków i musi zawierać wyraźne zastrzeżenie, że Wykonawca będzie
uprawniony do wypowiedzenia licencji w przypadku niezaprzestania dopuszczania się przez
Zamawiającego wyraźnie i precyzyjnie wymienionych naruszeń. W przypadku
wypowiedzenia licencji z tej przyczyny termin wypowiedzenia licencji wynosi 1 (słownie:
jeden) rok, ze skutkiem na koniec roku kalendarzowego.
W przypadku gdy podmiotem udzielającym licencji jest podmiot trzeci, Wykonawca
oświadcza i gwarantuje, że podmiot trzeci będzie przestrzegał powyższych zobowiązań.
Wykonawca zapewnia i gwarantuje, że podmiot trzeci nie wypowie udzielonych licencji.
Wykonawca oświadcza i gwarantuje, że licencja udzielana przez podmiot trzeci będzie
zawierać zasady wypowiedzenia analogiczne do opisanych w poprzednich ustępach.
W przypadku gdy Wykonawca lub podmiot trzeci, mimo zobowiązania, o którym mowa w
poprzednim ustępie, wypowie licencję, Wykonawca będzie zobowiązany do zapłaty na
rzecz Zamawiającego, na jego żądanie, kwoty odpowiadającej sumie opłaty licencyjnej za
standardowe Oprogramowanie aplikacyjne określonej w Umowie oraz rzeczywiście
poniesionych przez Zamawiającego kosztów zapewnienia (w tym uzyskania licencji
i wdrożenia) rozwiązania zastępczego, umożliwiającego dalszą eksploatację systemu.
4 Oprogramowanie serwerowe
4.1 Oprogramowanie serwerowe portalu wielofunkcyjnego
1. Serwery portali wielofunkcyjnych (PW) muszą realizować następujące funkcje i wymagania poprzez
wbudowane mechanizmy:
1.1.
Publikację dokumentów, treści i materiałów multimedialnych na witrynach wewnętrznych
i zewnętrznych.
1.2.
Zarządzanie strukturą portalu i treściami WWW.
1.3.
Uczestnictwo Internautów w forach dyskusyjnych, ocenie materiałów, publikacji własnych
treści.
1.4.
Udostępnianie spersonalizowanych witryn i przestrzeni roboczych dla poszczególnych ról w
systemie wraz z określaniem praw dostępu na bazie usługi katalogowej.
1.5.
Udostępnienie formularzy elektronicznych, w tym przygotowanych w narzędziach
wchodzących w skład pakietu biurowego.
1.6.
Tworzenie repozytoriów wzorów dokumentów.
1.7.
Tworzenie repozytoriów dokumentów.
4
1.8.
1.9.
1.10.
1.11.
1.12.
1.13.
1.14.
1.15.
1.16.
1.17.
Wspólną, bezpieczną pracę nad dokumentami.
Wersjonowanie dokumentów (dla wersji roboczych).
Organizację pracy grupowej.
Wyszukiwanie treści.
Dostęp do danych w relacyjnych bazach danych.
Analizy danych wraz z graficzną prezentacją danych.
Możliwość wykorzystania mechanizmów portalu do budowy systemu zarządzania
e-szkoleniami (e-learning).
Serwery portali muszą umożliwiać zaprojektowanie struktury portalu tak, by mogła
stanowić zbiór wielu niezależnych portali, które w zależności od nadanych uprawnień mogą
być zarządzane niezależnie.
PW muszą udostępniać mechanizmy współpracy między działami/zespołami, udostępniać
funkcje zarządzania zawartością, zaimplementować procesy przepływu dokumentów
i spraw oraz zapewnić dostęp do informacji niezbędnych do realizacji założonych celów
i procesów.
Serwery PW muszą posiadać następujące cechy dostępne bezpośrednio, jako wbudowane
właściwości produktu:
1.17.1. Interfejs użytkownika:
1.17.1.1. praca z dokumentami typu XML w oparciu o schematy XML
przechowywane w repozytoriach portalu bezpośrednio z aplikacji
pakietu biurowego (otwieranie, zapisywanie dokumentów, podgląd
wersji, mechanizmy ewidencjonowania i wyewidencjonowania
dokumentów, edycja metryki dokumentu),
1.17.1.2. wbudowane zasady realizujące wytyczne dotyczące ułatwień w
dostępie do publikowanych treści zgodne z WCAG 2.0,
1.17.1.3. praca bezpośrednio z aplikacji pakietu biurowego z portalowymi
rejestrami informacji typu kalendarze oraz bazy kontaktów,
1.17.1.4. tworzenie witryn w ramach portalu bezpośrednio z aplikacji pakietu
biurowego,
1.17.1.5. możliwość pracy off-line z plikami przechowywanymi w repozytoriach
portalu,
1.17.1.6. umożliwienie uruchomienia prezentacji stron w wersji pełnej oraz w
wersji dedykowanej i zoptymalizowanej dla użytkowników urządzeń
mobilnych PDA, telefon komórkowy).
1.17.2. Uwierzytelnianie – wbudowane mechanizmy wspierające uwierzytelnianie na
bazie:
1.17.2.1. oświadczeń (claim-based authentication) wykorzystywane przez
Zamawiającego, tj:
1.17.2.1.1. open Authorization 2.0 dla uwierzytelniania aplikacji,
1.17.2.1.2. uwierzytelniania w trybie server-to-server,
1.17.2.1.3. SAML,
1.17.2.1.4. Windows claims,
1.17.2.1.5. pojedynczego logowania domenowego (single-sign on),
1.17.2.1.6. na bazie formularzy (Form-based).
1.17.3. Projektowanie stron:
1.17.3.1. wbudowane intuicyjne narzędzia projektowania wyglądu stron,
1.17.3.2. umożliwienie stosowania edytorów HTML,
5
1.18.
1.17.3.3. umożliwienie stosowania ASP.NET, Apache, C#, Java i PHP,
1.17.3.4. możliwość osadzania elementów iFrame w polach HTML na stronie.
1.17.4. Integracja z pozostałymi modułami rozwiązania oraz innymi systemami:
1.17.4.1. wykorzystanie poczty elektronicznej do rozsyłania przez system
wiadomości, powiadomień, alertów do użytkowników portalu
w postaci maili,
1.17.4.2. dostęp poprzez interfejs portalowy do całości bądź wybranych
elementów skrzynek pocztowych użytkowników w komponencie
poczty elektronicznej, z zapewnieniem podstawowej funkcjonalności
pracy z tym systemem w zakresie czytania, tworzenia, przesyłania
elementów,
1.17.4.3. możliwość wykorzystania oferowanego systemu poczty elektronicznej
do umieszczania dokumentów w repozytoriach portalu poprzez
przesyłanie ich w postaci załączników do maili,
1.17.4.4. integracja z systemem obsługującym serwis WWW w zakresie
publikacji treści z repozytoriów wewnętrznych firmy na zewnętrzne
strony serwisu WWW (pliki, strony),
1.17.4.5. integracja z usługą katalogową w zakresie prezentacji informacji
o pracownikach. Dane typu: imię, nazwisko, stanowisko, telefon,
adres, miejsce w strukturze organizacyjnej mają stanowić źródło dla
systemu portalowego,
1.17.4.6. wsparcie dla standardu wymiany danych z innymi systemami
w postaci XML, z wykorzystaniem komunikacji poprzez XML Web
Services,
1.17.4.7. mechanizm jednokrotnej identyfikacji (single sign-on) pozwalający na
autoryzację użytkowników portalu i dostęp do danych w innych
systemach biznesowych, niezintegrowanych z systemem LDAP,
1.17.4.8. przechowywanie całej zawartości portalu (strony, dokumenty,
konfiguracja) we wspólnym dla całego serwisu podsystemie
bazodanowym z możliwością wydzielenia danych.
Zarządzanie treścią i wyglądem portalu musi wykorzystywać narzędzia umożliwiające
prostą i intuicyjną publikację treści w formacie HTML w trybie WYSIWYG, bez konieczności
znajomości języka HTML i innej wiedzy technicznej przez autorów treści:
1.18.1. Możliwość formatowania tekstu w zakresie zmiany czcionki, rozmiaru, koloru,
pogrubienia, wyrównania do prawej oraz lewej strony, wyśrodkowania,
wyjustowania,
1.18.2. Osadzenie i formatowanie plików graficznych, łącz (linków) różnych typów, tabel,
paragrafów, wypunktowań itp. w treści artykułów publikowanych
w intranecie (stron HTML),
1.18.3. Spójne zarządzanie wyglądem stron intranetu, głównie pod kątem formatowania
tekstu: możliwość globalnego zdefiniowania krojów tekstu, które mogą być
wykorzystywane przez edytorów treści, możliwość wklejania treści przy publikacji
stron
intranetu
z
plików
tekstowych
lub
edytorów
tekstu
z zachowaniem lub z usunięciem formatowania oryginalnego,
1.18.4. Zarządzanie galeriami zasobów elektronicznych (pliki graficzne, filmy video,
dokumenty),
wykorzystywanymi
przy
tworzeniu
stron
intranetu
i przechowywanymi w intranetowym repozytorium treści. Możliwość
6
1.19.
współdzielenia tych zasobów na potrzeby stron umiejscowionych w różnych
obszarach portalu intranetowego,
1.18.5. Podstawowe funkcjonalności związane z wersjonowaniem i wyszukiwaniem tych
zasobów,
1.18.6. Definiowanie szablonów dla układów stron (tzw. layout’ów), określających ogólny
układ stron intranetu oraz elementy wspólne dla stron opartych na tym samym
szablonie. Możliwość stworzenia wielu szablonów na potrzeby różnych układów
stron w zależności od potrzeb funkcjonalnych w różnych częściach intranetu.
Możliwość generalnej zmiany wyglądu utworzonych już stron poprzez
modyfikację szablonu, na którym zostały oparte.
1.18.7. Możliwość wielokrotnego wykorzystania elementów zawartości intranetu (części
treści publikowanych na stronach) w różnych częściach portalu, tzn. modyfikacja
zawartości w jednym miejscu powoduje jej faktyczną zmianę na wszystkich
stronach intranetu, gdzie dana treść została opublikowana,
1.18.8. Możliwość odwzorowania w systemie CMS przyjętej wizualizacji portalu
intranetowego (projekt graficzny i funkcjonalny),
1.18.9. Możliwość osadzania na stronach narzędzia do odtwarzania materiałów audio
i wideo.
Organizacja i publikacja treści:
1.19.1. Wersjonowanie treści stron intranetu, działające automatycznie przy
wprowadzaniu kolejnych modyfikacji przez edytorów treści.
1.19.2. Zastosowanie procesów zatwierdzania zawartości przed publikacją, tzn.
udostępnieniem jej dla szerokiego grona pracowników. Możliwość zdefiniowania
przynajmniej dwóch poziomów uprawnień edytorów (edytor i recenzent), przy
czym treści publikowane przez edytorów muszą uzyskać pozytywną akceptację
recenzenta przed udostępnieniem jej wszystkim użytkownikom intranetu.
1.19.3. Możliwość budowania hierarchicznej struktury stron portalu z prostym
przenoszeniem stron i sekcji w ramach struktury nawigacji.
1.19.4. Automatyczne tworzenie nawigacji na stronach intranetu, odwzorowujące
obecną hierarchię.
1.19.5. Automatyczne generowanie mapy stron portalu.
1.19.6. Możliwość definiowania nawigacji w oparciu o centralne zarządzanie
metadanymi.
1.19.7. Umożliwienie zarządzania poszczególnymi obszarami portalu osobom
nietechnicznym, pełniącym rolę edytorów bądź administratorów merytorycznych.
Istotne jest nieangażowanie zespołu IT w proces zarządzania treścią intranetu.
1.19.8. Definiowanie uprawnień użytkowników niezależnie do poszczególnych sekcji
i stron intranetu, np. do obszarów poszczególnych departamentów, wydziałów,
zespołów roboczych. Dotyczy to zarówno uprawnień do odczytu zawartości, jak
i edycji oraz publikacji (różni edytorzy zawartości intranetu w zależności od jego
części). Definiowanie uprawnień musi być dostępne dla administratorów
merytorycznych poszczególnych obszarów portalu w sposób niezależny od
pracowników działu IT.
1.19.9. Automatyczne dołączanie do publikowanych stron informacji o autorze (edytorze)
i dacie publikacji.
1.19.10. Możliwość personalizacji i filtrowania treści w intranecie w zależności od roli lub
innych atrybutów pracownika (np. stanowiska, wydziału, departamentu, biura).
7
1.20.
1.21.
Funkcjonalność ta ma być niezależna od mechanizmów zarządzania
uprawnieniami użytkownika do zawartości, i ma mieć na celu dostarczenie
pracownikowi adekwatnych, skierowanych do niego informacji.
1.19.11. Wsparcie dla obsługi wersji językowych (min. j. polski, angielski, niemiecki,
francuski, włoski, hiszpański), wybranych zawartości intranetu oraz zapewnienie
automatycznego tłumaczenia na wybrane języki.
Repozytoria dokumentów:
1.20.1. Możliwość prostej publikacji dokumentów w intranecie przez edytorów portalu.
Prosty sposób publikacji dokumentów, funkcjonalny dostęp użytkowników
intranetu do opublikowanych dokumentów.
1.20.2. Wykorzystanie do publikacji, edycji i przeglądania dokumentów w repozytorium
powszechnie wykorzystywanych narzędzi np. pakiety biurowe czy przeglądarkę
internetową.
1.20.3. Możliwość tworzenia wielu tematycznych repozytoriów dokumentów w różnych
częściach intranetu.
1.20.4. Możliwość publikacji plików w strukturze katalogów.
1.20.5. Możliwość publikacji materiałów wideo oraz audio.
1.20.6. Możliwość definiowania metryki dokumentu, wypełnianej przez edytora przy
publikacji pliku.
1.20.7. Możliwość nawigacji po repozytorium dokumentów (lub całym portalu)
w oparciu o metadane z metryk dokumentów.
1.20.8. Prosty, elastyczny i niezależny od działu IT mechanizm zarządzania uprawnieniami
do publikowanych dokumentów w ramach istniejących uprawnień. Możliwość
definiowania różnych poziomów uprawnień przez administratorów
merytorycznych, np. uprawnienia do odczytu, publikacji, usuwania.
1.20.9. Zarządzanie wersjonowaniem dokumentów: obsługa głównych oraz roboczych
wersji (np.: 1.0, 1.1, 1.x… 2.0), automatyczna kontrola wersji przy publikacji
dokumentów.
1.20.10. Możliwość zdefiniowania w systemie procesu zatwierdzania nowych lub
modyfikowanych dokumentów. System informuje użytkowników recenzujących
materiały o oczekujących na nich elementach do zatwierdzenia i pozwala podjąć
decyzję o ich publikacji lub odrzuceniu.
1.20.11. Możliwość tworzenia specjalnych repozytoriów lub katalogów przeznaczonych do
przechowywania specyficznych rodzajów treści, np. galerie obrazów dla plików
graficznych.
1.20.12. Możliwość definiowania polityk cyklu życia dokumentu oraz retencji
dokumentów.
1.20.13. Możliwość tworzenia specjalnych repozytoriów przeznaczonych na raporty
osadzone w arkuszach kalkulacyjnych w formacie umożliwiającym oglądanie ich
przez przeglądarkę Internetową bez zainstalowanych dodatkowych narzędzi
klienckich.
1.20.14. Możliwość automatyzacji usuwania duplikatów dokumentów.
Wyszukiwanie treści:
1.21.1. Pełno tekstowe indeksowanie zawartości intranetu w zakresie różnych typów
treści publikowanych w portalu, tj. stron portalu, dokumentów tekstowych
(w szczególności dokumentów XML), innych baz danych oraz danych dostępnych
przez webservice.
8
1.21.2.
1.21.3.
1.22.
Centralny mechanizm wyszukiwania treści dostępny dla użytkowników intranetu.
Opcja wyszukiwania zaawansowanego, np. wyszukiwanie wg typów treści,
autorów, oraz zakresów dat publikacji.
1.21.4. Możliwość budowania wielu wyszukiwarek w różnych częściach portalu, służących
do przeszukiwania określonych obszarów intranetu wg zadanych kryteriów, np.
wg typów dokumentów.
1.21.5. Możliwość definiowania słownika słów wykluczonych (często używanych).
1.21.6. Możliwość tworzenia „linków sponsorowanych”, prezentowanych wysoko
w wynikach wyszukiwania w zależności od słów wpisanych w zapytaniu.
1.21.7. Podświetlanie w wynikach wyszukiwania odnalezionych słów kluczowych
zadanych w zapytaniu.
1.21.8. Przedstawianie w wynikach duplikatów plików.
1.21.9. Statystyki wyszukiwanych fraz.
Administracja intranetem i inne funkcje:
1.22.1. Możliwość definiowania ról / grup uprawnień, w ramach których definiowane
będą uprawnienia i funkcje użytkowników. Przypisywanie użytkowników do ról w
oparciu o ich konta w LDAP lub poprzez grupy domenowe. Funkcjonalność
zarządzania uprawnieniami dostępna dla administratorów merytorycznych
intranetu, niewymagająca szczególnych kompetencji technicznych.
1.22.2. Możliwość określania uprawnień do poszczególnych elementów zawartości
intranetu tj. sekcja, pojedyncza strona, repozytorium dokumentów, katalogu
dokumentów, pojedynczego dokumentu.
1.22.3. Generowanie powiadomień pocztą elektroniczną dla użytkowników intranetu
z informacją o publikacji najbardziej istotnych treści.
1.22.4. Definiowanie metryk opisujących dokumenty w poszczególnych repozytoriach
portalu oraz centralnie zarządzanego zbioru metadanych z wyznaczonym
administratorem merytorycznym.
1.22.5. Możliwość definiowania zewnętrznych źródeł danych takich jak bazy danych
i webservice oraz wykorzystywania ich do opisywania dokumentów.
1.22.6. Konfigurowanie procesów zatwierdzania publikowanych stron i dokumentów.
Możliwość odrębnej konfiguracji w poszczególnych częściach portalu tj.
definiowanie różnych edytorów i recenzentów w ramach różnych obszarów
intranetu.
1.22.7. Statystyki odwiedzin poszczególnych części i stron intranetu – analiza liczby
odsłon w czasie. Opcjonalnie zaawansowane statystyki i analizy.
1.22.8. Funkcjonalności wspierające pracę grupową - do wykorzystania na najniższym
poziomie intranetu do celów pracy działów i zespołów zadaniowych.
Funkcjonalności wspierające gromadzenie dokumentów, wsparcie komunikacji,
planowanie zadań i wydarzeń.
1.22.9. Funkcjonalność publikowania na portalu formularzy elektronicznych XML
i przetwarzanych na aplikację webową dostępną dla użytkowników przez
przeglądarkę Internetową. Dane z wypełnionego formularza mają być zapisywane
w formacie XML zgodnie z definicją formularza.
1.22.10. Mechanizmy wspierające przepływy pracy (workflow) wraz z funkcjonalnością
definiowania procesów obiegu dokumentów, integracji przepływów z webservices, wywoływania web-services z poziomu workflow bez konieczności
kodowania przy wykorzystaniu prostych w obsłudze narzędzi portalu.
9
4.2 Oprogramowanie serwerowe relacyjnej bazy danych
System bazodanowy (SBD) musi spełniać następujące wymagania poprzez wbudowane mechanizmy:
1. Możliwość wykorzystania SBD jako silnika relacyjnej bazy danych, analitycznej, wielowymiarowej
bazy danych, platformy bazodanowej dla wielu aplikacji. Musi zawierać serwer raportów, narzędzia
do: definiowania raportów, wykonywania analiz biznesowych, tworzenia procesów ETL.
2. Zintegrowane narzędzia graficzne do zarządzania systemem – SBD musi dostarczać zintegrowane
narzędzia do zarządzania i konfiguracji wszystkich usług wchodzących w skład systemu (baza
relacyjna, usługi analityczne, usługi raportowe, usługi transformacji danych). Narzędzia te muszą
udostępniać możliwość tworzenia skryptów zarządzających systemem oraz automatyzacji ich
wykonywania.
3. Zarządzanie serwerem za pomocą skryptów - SBD musi udostępniać mechanizm zarządzania
systemem za pomocą uruchamianych z linii poleceń skryptów administracyjnych, które pozwolą
zautomatyzować rutynowe czynności związane z zarządzaniem serwerem.
4. Dedykowana sesja administracyjna - SBD musi pozwalać na zdalne połączenie sesji administratora
systemu bazy danych w sposób niezależny od normalnych sesji klientów.
5. Wykonywanie typowych zadań administracyjnych w trybie on-line - SBD musi umożliwiać
wykonywanie typowych zadań administracyjnych (np. backup) bez konieczności przerywania pracy
systemu lub przechodzenia w tryb jednoużytkownikowy.
6. Możliwość automatycznej aktualizacji systemu - SBD musi umożliwiać automatyczne ściąganie
i instalację wszelkich poprawek producenta oprogramowania (redukowania zagrożeń
powodowanych przez znane luki w zabezpieczeniach oprogramowania).
7. Możliwość dodawania procesorów bez restartu systemu – SBD musi umożliwiać dodanie procesora
do systemu bez konieczności restartu silnika bazy danych.
8. Możliwość dodawania pamięci bez restartu systemu – SBD musi umożliwiać dodanie pamięci do
systemu bez konieczności restartu silnika bazy danych.
9. SBD musi umożliwiać tworzenie klastrów niezawodnościowych.
10. Wysoka dostępność – SBD musi posiadać mechanizm pozwalający na duplikację bazy danych między
dwiema lokalizacjami (podstawowa i zapasowa) przy zachowaniu następujących cech:
10.1. bez specjalnego sprzętu (rozwiązanie tylko programowe oparte o sam SBD),
10.2. niezawodne powielanie danych w czasie rzeczywistym (potwierdzone transakcje
bazodanowe),
10.3. klienci bazy danych automatycznie korzystają z bazy zapasowej w przypadku awarii bazy
podstawowej bez zmian w aplikacjach,
10.4. Duplikacja danych w trybie synchronicznym lub asynchronicznym,
10.5. Kompresja danych przesyłanych między serwerem podstawowym i zapasowym (w celu
minimalizacji obciążenia sieci).
11. Kompresja kopii zapasowych - SBD musi pozwalać na kompresję kopii zapasowej danych (backup)
w trakcie jej tworzenia. Musi to być cecha SBD niezależna od funkcji systemu operacyjnego ani od
sprzętowego rozwiązania archiwizacji danych.
12. Możliwość automatycznego szyfrowania kopii bezpieczeństwa bazy danych przy użyciu między
innymi certyfikatów lub kluczy asymetrycznych. Mechanizm ten nie może wymagać konieczności
uprzedniego szyfrowania bazy danych.
13. Możliwość szyfrowania przechowywanych danych - SBD musi pozwalać na szyfrowanie
przechowywanych danych. Szyfrowane musi być cechą SBD i nie może wymagać jakichkolwiek zmian
w aplikacjach korzystających z danych. Zaszyfrowanie lub odszyfrowanie danych nie może
10
14.
15.
16.
17.
18.
19.
20.
21.
powodować przerwy w dostępie do danych. Kopia bezpieczeństwa szyfrowanej bazy danych musi
być automatycznie zaszyfrowana.
Możliwość zastosowania reguł bezpieczeństwa obowiązujących u Zamawiającego - wsparcie dla
zdefiniowanej polityki bezpieczeństwa (np. automatyczne wymuszanie zmiany haseł użytkowników,
zastosowanie mechanizmu weryfikacji dostatecznego poziomu komplikacji haseł wprowadzanych
przez użytkowników), możliwość zintegrowania uwierzytelniania użytkowników z usługą
katalogową.
Możliwość definiowania reguł administracyjnych dla serwera lub grupy serwerów - SBD musi mieć
możliwość definiowania reguł wymuszanych przez system i zarządzania nimi. Przykładem takiej
reguły jest uniemożliwienie użytkownikom tworzenia obiektów baz danych o zdefiniowanych przez
administratora szablonach nazw. Dodatkowo wymagana jest możliwość rejestracji i raportowania
niezgodności działającego systemu ze wskazanymi regułami, bez wpływu na jego funkcjonalność.
W celu zwiększenia wydajności przetwarzania system bazy danych musi posiadać wbudowaną
funkcjonalność pozwalającą na rozszerzenie cache’u przetwarzania w pamięci RAM o dodatkową
przestrzeń na dysku.
System SBD musi zapewniać wersjonowanie wierszy w tabelach przechowywanych w pamięci RAM.
Rejestrowanie zdarzeń silnika bazy danych w czasie rzeczywistym – SBD musi posiadać możliwość
rejestracji zdarzeń na poziomie silnika bazy danych w czasie rzeczywistym w celach diagnostycznych,
bez ujemnego wpływu na wydajność rozwiązania, pozwalać na selektywne wybieranie
rejestrowanych zdarzeń. Wymagana jest rejestracja zdarzeń:
18.1. odczyt/zapis danych na dysku dla zapytań wykonywanych do baz danych (w celu
wychwytywania zapytań znacząco obciążających system),
18.2. wykonanie zapytania lub procedury trwające dłużej niż zdefiniowany czas (wychwytywanie
długo trwających zapytań lub procedur),
18.3. para zdarzeń zablokowanie/zwolnienie blokady na obiekcie bazy (w celu wychwytywania
długotrwałych blokad obiektów bazy).
Zarządzanie pustymi wartościami w bazie danych - SBD musi efektywnie zarządzać pustymi
wartościami przechowywanymi w bazie danych (NULL). W szczególności puste wartości
wprowadzone do bazy danych powinny zajmować minimalny obszar pamięci.
Definiowanie nowych typów danych - SBD musi umożliwiać definiowanie nowych typów danych
wraz z definicją specyficznej dla tych typów danych logiki operacji. Jeśli np. zdefiniujemy typ do
przechowywania danych hierarchicznych, to obiekty tego typu muszą udostępnić operacje dostępu
do „potomków” obiektu, „rodzica” itp. Logika operacji nowych, niestandardowych typów danych
musi być implementowana w zaoferowanym przez Wykonawcę języku programowania. Nowe typy
danych nie mogą być ograniczone wyłącznie do okrojenia typów wbudowanych lub ich kombinacji.
Wsparcie dla danych przestrzennych - SBD musi zapewniać wsparcie dla geometrycznych
i geograficznych typów danych pozwalających w prosty sposób przechowywać i analizować
informacje o lokalizacji obiektów, dróg i innych punktów orientacyjnych zlokalizowanych na kuli
ziemskiej, a w szczególności:
21.1. zapewniać możliwość wykorzystywania szerokości i długości geograficznej do opisu lokalizacji
obiektów,
21.2. oferować wiele metod, które pozwalają na łatwe operowanie kształtami czy bryłami,
testowanie ich wzajemnego ułożenia w układach współrzędnych oraz dokonywanie obliczeń
takich wielkości, jak pola figur, odległości do punktu na linii, itp.,
21.3. obsługa geometrycznych i geograficznych typów danych musi być dostępna z poziomu języka
zapytań do systemu SBD,
11
22.
23.
24.
25.
26.
27.
28.
29.
30.
21.4. typy danych geograficznych powinny być konstruowane na podstawie obiektów
wektorowych, określonych w formacie Well-KnownText (WKT) lub Well-KnownBinary (WKB),
(powinny być to m.in. takie typy obiektów jak: lokalizacja (punkt), seria punktów, seria
punktów połączonych linią, zestaw wielokątów, itp.).
Wsparcie dla technologii XML - SBD musi udostępniać mechanizmy składowania i obróbki danych w
postaci struktur XML. W szczególności musi:
22.1. udostępniać typ danych do przechowywania kompletnych dokumentów XML w jednym polu
tabeli,
22.2. udostępniać mechanizm walidacji struktur XML-owych względem jednego lub wielu
szablonów XSD,
22.3. udostępniać język zapytań do struktur XML,
22.4. udostępniać język modyfikacji danych (DML) w strukturach XML (dodawanie, usuwanie
i modyfikację zawartości struktur XML),
22.5. udostępniać możliwość indeksowania struktur XML-owych w celu optymalizacji
wykonywania zapytań.
Możliwość przechowania dużych obiektów binarnych – SBD musi umożliwiać przechowywani i
zarządzanie dużymi obiektami binarnymi (pliki graficzne, multimedialne, dokumenty, itp.). Obiekty
te nie powinny być przechowywane w plikach bazy danych, ale w systemie plików. Jednocześnie pliki
te powinny być zarządzane przez SBD (kontrola dostępu na podstawie uprawnień nadanych w SBD).
Dodatkowo dane binarne muszą być dostępne dla użytkowników bazy danych jako standardowa
kolumna tabeli (dostęp z poziomu zapytań języka SQL obsługiwanego przez SBD).
Audyt dostępu do danych – SBD musi pozwalać na rejestrację operacji takich jak: logowanie,
wylogowanie użytkownika, zmiany w definicji obiektów bazy danych, wykonywanie przez
wskazanego użytkownika takich jak: SELECT, INSERT, UPDATE, DELETE. Rozwiązanie musi być
niezależne od aplikacji, wbudowane w SBD.
Możliwość tworzenia funkcji i procedur w innych językach programowania - SBD musi umożliwiać
tworzenie procedur i funkcji z wykorzystaniem innych języków programowania niż standardowo
obsługiwany język zapytań danego SBD. System musi umożliwiać tworzenie w tych językach m.in.
agregujących funkcji użytkownika oraz wyzwalaczy. Dodatkowo musi udostępniać środowisko do
debuggowania.
Możliwość tworzenia rekursywnych zapytań do bazy danych - SBD musi udostępniać wbudowany
mechanizm umożliwiający tworzenie rekursywnych zapytań do bazy danych bez potrzeby pisania
specjalnych procedur i wywoływania ich w sposób rekurencyjny.
Obsługa błędów w kodzie zapytań - język zapytań i procedur w SBD musi umożliwiać zastosowanie
mechanizmu przechwytywania błędów wykonania procedury (na przykład na zasadzie bloku
instrukcji TRY/CATCH).
Raportowanie zależności między obiektami - SBD musi udostępniać informacje o wzajemnych
zależnościach między obiektami bazy danych.
Mechanizm zamrażania planów wykonania zapytań do bazy danych - SBD musi udostępniać
mechanizm pozwalający na zamrożenie planu wykonania zapytania przez silnik bazy danych
(w wyniku takiej operacji zapytanie jest zawsze wykonywane przez silnik bazy danych w ten sam
sposób). Mechanizm ten daje możliwość zapewnienia przewidywalnego czasu odpowiedzi na
zapytanie po przeniesieniu systemu na inny serwer (środowisko testowe i produkcyjne), migracji do
innych wersji SBD, wprowadzeniu zmian sprzętowych serwera.
System transformacji danych - SBD musi posiadać narzędzie do graficznego projektowania
transformacji danych. Narzędzie to musi pozwalać na przygotowanie definicji transformacji w
postaci pliku, które potem mogą być wykonywane automatycznie lub z asystą operatora.
12
31.
32.
33.
34.
35.
36.
Transformacje muszą posiadać możliwość graficznego definiowania zarówno przepływu sterowania
(program i warunki logiczne) jak i przepływu strumienia rekordów poddawanych transformacjom.
Musi być także zapewniona możliwość tworzenia własnych transformacji. Środowisko tworzenia
transformacji danych musi udostępniać m.in.:
30.1. mechanizm debuggowania tworzonego rozwiązania,
30.2. mechanizm stawiania „pułapek” (breakpoints),
30.3. mechanizm logowania do pliku wykonywanych przez transformację operacji,
30.4. możliwość wznowienia wykonania transformacji od punktu, w którym przerwano jej
wykonanie (np. w wyniku pojawienia się błędu),
30.5. możliwość cofania i ponawiania wprowadzonych przez użytkownika zmian podczas edycji
transformacji (funkcja undo/redo),
30.6. mechanizm analizy przetwarzanych danych (możliwość podglądu rekordów przetwarzanych
w strumieniu danych oraz tworzenia statystyk, np. histogram wartości w przetwarzanych
kolumnach tabeli),
30.7. mechanizm automatyzacji publikowania utworzonych transformacji na serwerze bazy
danych (w szczególności tworzenia wersji instalacyjnej pozwalającej automatyzować proces
publikacji na wielu serwerach),
30.8. mechanizm tworzenia parametrów zarówno na poziomie poszczególnych pakietów, jak też
na poziomie całego projektu, parametry muszą umożliwiać uruchamianie pakietów
podrzędnych i przesyłanie do nich wartości parametrów z pakietu nadrzędnego,
30.9. mechanizm mapowania kolumn wykorzystujący ich nazwę i typ danych do automatycznego
przemapowania kolumn w sytuacji podmiany źródła danych.
Wbudowany system analityczny - SBD musi posiadać moduł pozwalający na tworzenie rozwiązań
służących do analizy danych wielowymiarowych (kostki OLAP). Musi być możliwe tworzenie:
wymiarów, miar. Wymiary powinny mieć możliwość określania dodatkowych atrybutów będących
dodatkowymi poziomami agregacji. Musi być możliwość definiowania hierarchii w obrębie wymiaru.
Przykład: wymiar Lokalizacja Geograficzna. Atrybuty: miasto, gmina, województwo. Hierarchia:
Województwo->Gmina.
Wbudowany system analityczny musi mieć możliwość wyliczania agregacji wartości miar dla
zmieniających się elementów (członków) wymiarów i ich atrybutów. Agregacje powinny być
składowane w jednym z wybranych modeli (MOLAP – wyliczone gotowe agregacje rozłącznie
w stosunku do danych źródłowych, ROLAP – agregacje wyliczane w trakcie zapytania z danych
źródłowych). Pojedyncza baza analityczna musi mieć możliwość mieszania modeli składowania, np.
dane bieżące ROLAP, historyczne – MOLAP w sposób przezroczysty dla wykonywanych zapytań.
Dodatkowo musi być dostępna możliwość drążenia danych z kostki do poziomu rekordów
szczegółowych z bazy relacyjnych (drill to detail).
Wbudowany system analityczny musi pozwalać na dodanie akcji przypisanych do elementów kostek
wielowymiarowych (np. pozwalających na przejście użytkownika do raportów kontekstowych lub
stron WWW powiązanych z przeglądanym obszarem kostki).
Wbudowany system analityczny musi posiadać narzędzie do rejestracji i śledzenia zapytań
wykonywanych do baz analitycznych.
Wbudowany system analityczny musi umożliwiać rejestrowanie zapytań wykonywanych przez
użytkowników, a następnie umożliwiać na podstawie zgromadzonych informacji automatyczną
optymalizację wydajności systemu.
Wbudowany system analityczny musi obsługiwać wielojęzyczność (tworzenie obiektów
wielowymiarowych w wielu językach – w zależności od ustawień na komputerze klienta).
13
37. Wbudowany system analityczny musi udostępniać mechanizm zapisu danych przez użytkownika do
kostek wielowymiarowych.
38. Wbudowany system analityczny musi udostępniać rozwiązania Data Mining, m.in.: algorytmy reguł
związków (AssociationRules), szeregów czasowych (Time Series), drzew regresji (RegressionTrees),
sieci neuronowych (NeuralNets oraz Naive Bayes). Dodatkowo system musi udostępniać narzędzia
do wizualizacji danych z modelu Data Mining oraz język zapytań do odpytywania tych modeli.
39. System analityczny musi pozwalać na dodawanie własnych algorytmów oraz modułów wizualizacji
modeli Data Mining.
40. Tworzenie głównych wskaźników wydajności KPI (Key Performance Indicators - kluczowe czynniki
sukcesu) - SBD musi udostępniać użytkownikom możliwość tworzenia wskaźników KPI (Key
Performance Indicators) na podstawie danych zgromadzonych w strukturach wielowymiarowych. W
szczególności musi pozwalać na zdefiniowanie takich elementów, jak: wartość aktualna, cel, trend,
symbol graficzny wskaźnika w zależności od stosunku wartości aktualnej do celu.
41. System raportowania - SBD musi posiadać możliwość definiowania i generowania raportów.
Narzędzie do tworzenia raportów musi pozwalać na ich graficzną definicję. Raporty powinny być
udostępnianie przez system protokołem HTTP (dostęp klienta za pomocą przeglądarki), bez
konieczności stosowania dodatkowego oprogramowania po stronie serwera. Dodatkowo system
raportowania musi obsługiwać:
41.1. raporty parametryzowane,
41.2. cache raportów (generacja raportów bez dostępu do źródła danych),
41.3. cache raportów parametryzowanych (generacja raportów bez dostępu do źródła danych,
z różnymi wartościami parametrów),
41.4. współdzielenie predefiniowanych zapytań do źródeł danych,
41.5. wizualizację danych analitycznych na mapach geograficznych ,
41.6. możliwość opublikowania elementu raportu (wykresu, tabeli) we współdzielonej bibliotece,
z której mogą korzystać inni użytkownicy tworzący nowy raport,
41.7. możliwość wizualizacji wskaźników KPI,
42. Środowisko raportowania musi być osadzone i administrowane z wykorzystaniem mechanizmu Web
Serwisów (Web Services).
43. Wymagane jest generowanie raportów w używanych przez Zamawiającego formatach: XML, PDF,
Microsoft Excel (od wersji 1997 do 2016), Microsoft Word (od wersji 1997 do 2016), HTML, TIFF.
44. SBD musi umożliwiać rozbudowę mechanizmów raportowania m.in. o dodatkowe formaty eksportu
danych, obsługę nowych źródeł danych dla raportów, funkcje i algorytmy wykorzystywane podczas
generowania raportu (np. nowe funkcje agregujące), mechanizmy zabezpieczeń dostępu do
raportów.
45. SBD musi umożliwiać wysyłkę raportów drogą mailową w wybranym formacie (subskrypcja).
46. Wbudowany system raportowania musi posiadać rozszerzalną architekturę oraz otwarte interfejsy
do osadzania raportów oraz do integrowania rozwiązania z różnorodnymi środowiskami IT.
4.3 Serwerowy system operacyjny z elementami zarządzania typ I
Serwerowy system operacyjny (SSO)
1. Liczba rdzeni procesorów i ilość pamięci nie mogą mieć wpływu na liczbę wymaganych licencji.
Licencja musi uprawniać do uruchamiania serwerowego systemu operacyjnego (SSO)
14
w środowisku fizycznym i dwóch wirtualnych środowisk serwerowego systemu operacyjnego za
pomocą wbudowanych mechanizmów wirtualizacji.
2. Serwerowy system operacyjny (SSO) typ I musi posiadać następujące, wbudowane cechy:
2.1. Możliwość wykorzystania, do 320 logicznych procesorów oraz co najmniej 4 TB pamięci RAM
w środowisku fizycznym,
2.2. Możliwość wykorzystywania 64 procesorów wirtualnych oraz 1TB pamięci RAM i dysku
o pojemności do 64TB przez każdy wirtualny serwerowy system operacyjny,
2.3. Możliwość budowania klastrów składających się z 64 węzłów, z możliwością uruchamiania do
7000 maszyn wirtualnych,
2.4. Możliwość migracji maszyn wirtualnych bez zatrzymywania ich pracy między fizycznymi
serwerami z uruchomionym mechanizmem wirtualizacji (hypervisor) przez sieć Ethernet, bez
konieczności stosowania dodatkowych mechanizmów współdzielenia pamięci,
2.5. Wsparcie (na umożliwiającym to sprzęcie) dodawania i wymiany pamięci RAM bez
przerywania pracy,
2.6. Wsparcie (na umożliwiającym to sprzęcie) dodawania i wymiany procesorów bez
przerywania pracy,
2.7. Automatyczna weryfikacja cyfrowych sygnatur sterowników w celu sprawdzenia, czy
sterownik przeszedł testy jakości przeprowadzone przez producenta systemu operacyjnego,
2.8. Możliwość dynamicznego obniżania poboru energii przez rdzenie procesorów
niewykorzystywane w bieżącej pracy. Mechanizm ten musi uwzględniać specyfikę
procesorów wyposażonych w mechanizmy Hyper-Threading wykorzystywane przez
Zamawiającego,
2.9. Wbudowane wsparcie instalacji i pracy na wolumenach, które:
2.9.1. pozwalają na zmianę rozmiaru w czasie pracy systemu,
2.9.2. umożliwiają tworzenie w czasie pracy systemu migawek, dających użytkownikom
końcowym (lokalnym i sieciowym) prosty wgląd w poprzednie wersje plików
i folderów,
2.9.3. umożliwiają kompresję "w locie" dla wybranych plików i/lub folderów,
2.9.4. umożliwiają zdefiniowanie list kontroli dostępu (ACL).
2.10. Wbudowany mechanizm klasyfikowania i indeksowania plików (dokumentów) w oparciu
o ich zawartość,
2.11. Wbudowany mechanizm szyfrowania dysków,
2.12. Możliwość uruchamiania aplikacji internetowych wykorzystujących technologię ASP.NET,
2.13. Możliwość dystrybucji ruchu sieciowego HTTP pomiędzy kilka serwerów,
2.14. Wbudowana zapora internetowa (firewall) z obsługą definiowanych reguł dla ochrony
połączeń internetowych i intranetowych,
2.15. Graficzny interfejs użytkownika,
2.16. Menu, przeglądarka internetowa, pomoc, komunikaty systemowe – w języku polskim,
2.17. Możliwość zmiany języka interfejsu po zainstalowaniu systemu, dla co najmniej 10 języków
poprzez wybór z listy dostępnych lokalizacji,
2.18. Wsparcie dla większości powszechnie używanych urządzeń peryferyjnych (w szczególności:
drukarek, urządzeń sieciowych, standardów USB, Plug&Play),
2.19. Możliwość zdalnej konfiguracji, administrowania oraz aktualizowania systemu,
2.20. Dostępność bezpłatnych narzędzi producenta systemu umożliwiających badanie i wdrażanie
zdefiniowanego zestawu polityk bezpieczeństwa,
2.21. Możliwość implementacji następujących funkcjonalności:
2.21.1. podstawowe usługi sieciowe: DHCP oraz DNS wspierający DNSSEC,
15
2.21.2. usługi katalogowe oparte o LDAP i pozwalające na uwierzytelnianie użytkowników
stacji roboczych, bez konieczności instalowania dodatkowego oprogramowania na
tych stacjach, pozwalające na zarządzanie zasobami w sieci (użytkownicy,
komputery, drukarki, udziały sieciowe), z możliwością wykorzystania następujących
funkcji:
2.21.2.1. podłączenie SSO do domeny w trybie offline – bez dostępnego
połączenia sieciowego z domeną,
2.21.2.2. ustanawianie praw dostępu do zasobów domeny na bazie sposobu
logowania użytkownika – na przykład typu certyfikatu użytego do
logowania,
2.21.2.3. odzyskiwanie przypadkowo skasowanych obiektów usługi katalogowej z
mechanizmu kosza,
2.21.3. zdalna dystrybucja oprogramowania na stacje robocze,
2.21.4. praca zdalna na serwerze z wykorzystaniem terminala (cienkiego klienta) lub
odpowiednio skonfigurowanej stacji roboczej,
2.21.5. centrum Certyfikatów (CA), obsługa klucza publicznego i prywatnego)
umożliwiające:
2.21.5.1. dystrybucję certyfikatów poprzez http,
2.21.5.2. konsolidację CA dla wielu lasów domeny,
2.21.5.3. automatyczne rejestrowania certyfikatów pomiędzy różnymi lasami
domen,
2.21.5.4. szyfrowanie plików i folderów,
2.21.5.5. szyfrowanie połączeń sieciowych pomiędzy serwerami oraz serwerami i
stacjami roboczymi (IPSec),
2.21.6. możliwość tworzenia systemów wysokiej dostępności (klastry typu fail-over) oraz
rozłożenia obciążenia serwerów,
2.21.7. serwis udostępniania stron WWW,
2.21.8. wsparcie dla protokołu IP w wersji 6 (IPv6),
2.21.9. wbudowane usługi VPN pozwalające na zestawienie nielimitowanej liczby
równoczesnych
połączeń
i niewymagające
instalacji
dodatkowego
oprogramowania na komputerach z systemem Windows,
2.21.10. wbudowane mechanizmy wirtualizacji (Hypervisor) pozwalające na uruchamianie
do 1000 aktywnych środowisk wirtualnych systemów operacyjnych. Wirtualne
maszyny w trakcie pracy i bez zauważalnego zmniejszenia ich dostępności mogą być
przenoszone pomiędzy serwerami klastra typu failover z jednoczesnym
zachowaniem pozostałej funkcjonalności. Mechanizmy wirtualizacji mają zapewnić
wsparcie dla:
2.21.10.1. dynamicznego podłączania zasobów dyskowych typu hot-plug do
maszyn wirtualnych,
2.21.10.2. obsługi ramek typu jumbo frames dla maszyn wirtualnych,
2.21.10.3. obsługi 4-KB sektorów dysków,
2.21.10.4. nielimitowanej liczby jednocześnie przenoszonych maszyn wirtualnych
pomiędzy węzłami klastra,
2.21.10.5. możliwości wirtualizacji sieci z zastosowaniem przełącznika, którego
funkcjonalność może być rozszerzana jednocześnie poprzez
oprogramowanie kilku innych dostawców poprzez otwarty interfejs API,
16
2.21.10.6. możliwości kierowania ruchu sieciowego z wielu sieci VLAN
bezpośrednio do pojedynczej karty sieciowej maszyny wirtualnej (tzw.
trunkmode).
2.22. Możliwość automatycznej aktualizacji w oparciu o poprawki publikowane przez producenta
wraz z dostępnością bezpłatnego rozwiązania producenta SSO umożliwiającego lokalną
dystrybucję poprawek zatwierdzonych przez administratora, bez połączenia z siecią Internet,
2.23. Wsparcie dostępu do zasobu dyskowego SSO poprzez wiele ścieżek (Multipath),
2.24. Możliwość instalacji poprawek poprzez wgranie ich do obrazu instalacyjnego,
2.25. Mechanizmy zdalnej administracji oraz mechanizmy (również działające zdalnie)
administracji przez skrypty,
2.26. Możliwość zarządzania przez wbudowane mechanizmy zgodne ze standardami WBEM oraz
WS-Management organizacji DMTF.
3. Elementy zarządzania:
3.1. Licencja oprogramowania zarządzania środowiskami serwerowymi musi być przypisana do
każdego procesora fizycznego na serwerze zarządzanym. Oprogramowanie musi być
licencjonowane na minimum 2 fizyczne procesory serwera zarządzanego. Liczba rdzeni
procesorów i ilość pamięci nie mogą mieć wpływu na liczbę wymaganych licencji. Każda licencja
na 2 fizyczne procesory serwera musi uprawniać do zarządzania 2 środowiskami systemu
operacyjnego na tym serwerze.
3.2. Zarządzanie serwerem musi obejmować wszystkie funkcje zawarte w opisanych poniżej
modułach:
3.2.1. system zarządzania infrastrukturą i oprogramowaniem,
3.2.2. system zarządzania komponentami,
3.2.3. system zarządzania środowiskami wirtualnymi,
3.2.4. system tworzenia kopii zapasowych,
3.2.5. system automatyzacji zarządzania środowisk IT,
3.2.6. system zarządzania incydentami i problemami,
3.2.7. ochrona antymalware.
4. System zarządzania infrastrukturą i oprogramowaniem musi spełniać następujące wymagania
poprzez wbudowane mechanizmy, bez użycia dodatkowych aplikacji:
4.1. Inwentaryzacja i zarządzanie zasobami:
4.1.1. inwentaryzacja zasobów serwera musi się odbywać w określonych przez
administratora systemu interwałach czasowych. System musi mieć możliwość
odrębnego planowania inwentaryzacji sprzętu i oprogramowania,
4.1.2. inwentaryzacja sprzętu musi się odbywać przez pobieranie informacji z interfejsu
WMI, komponent inwentaryzacyjny musi mieć możliwość konfiguracji w celu
ustalenia informacji, o podzespołach, które będą przekazywane do systemu,
4.1.3. inwentaryzacja oprogramowania musi skanować zasoby dyskowe przekazując dane
o znalezionych plikach do systemu w celu identyfikacji oprogramowania oraz celów
wyszukiwania i gromadzenia informacji o szczególnych typach plików (np. pliki
multimedialne: wav, mp3, avi, xvid, itp.),
4.1.4. system musi posiadać własną bazę dostępnego na rynku komercyjnego
oprogramowania, pozwalającą na identyfikację zainstalowanego i użytkowanego
oprogramowania, system musi dawać możliwość aktualizacji tej bazy przy pomocy
konsoli administratora oraz automatycznie przez aktualizacje ze stron producenta,
4.1.5. informacje inwentaryzacyjne powinny być przesyłane przy pomocy plików
różnicowych w celu ograniczenia ruchu z agenta do serwera.
17
4.2. Użytkowane oprogramowanie – pomiar wykorzystania:
4.2.1. system musi mieć możliwość zliczania uruchomionego oprogramowania w celu
śledzenia wykorzystania,
4.2.2. reguły dotyczące monitorowanego oprogramowania powinny być tworzone
automatycznie przez skanowanie oprogramowania uruchamianego.
4.3. System musi dostarczać funkcje dystrybucji oprogramowania, dystrybucji i zarządzania
aktualizacjami, instalacja, aktualizacja systemów operacyjnych.
4.4. Definiowanie i sprawdzanie standardu serwera:
4.4.1. system musi posiadać komponenty umożliwiające zdefiniowanie i okresowe
sprawdzanie standardu serwera, standard ten musi być określony zestawem reguł
sprawdzających definiowanych z poziomu konsoli administracyjnej,
4.4.2. reguły powinny sprawdzać następujące elementy systemu komputerowego:
4.4.2.1. stan usługi,
4.4.2.2. obecność poprawek (Hotfix),
4.4.2.3. WMI,
4.4.2.4. rejestr systemowy,
4.4.2.5. system plików,
4.4.2.6. Active Directory,
4.4.2.7. SQL (query),
4.4.2.8. Metabase.
4.5. Raportowanie, prezentacja danych:
4.5.1. system musi posiadać komponent raportujący oparty o technologię webową
(wydzielony portal z raportami) i/lub
4.5.2. Wykorzystujący mechanizmy raportujące dostarczane wraz z silnikami
bazodanowymi,
4.5.3. System musi posiadać predefiniowane raport w następujących kategoriach:
4.5.3.1. sprzęt (inwentaryzacja),
4.5.3.2. oprogramowanie (inwentaryzacja),
4.5.3.3. oprogramowanie (wykorzystanie),
4.5.3.4. oprogramowanie (aktualizacje, w tym system operacyjny).
4.5.4. system musi umożliwiać budowanie stron z raportami w postaci tablic (dashboard),
na których może znajdować się więcej niż jeden raport,
4.5.5. system musi posiadać konsolę administratora, w postaci programu do
zainstalowania na stacjach roboczych, obsługującą wszystkie funkcje systemu.
4.6. Analiza działania systemu, logi, komponenty:
4.6.1. konsola systemu musi dawać dostęp do podstawowych logów obrazujących pracę
poszczególnych komponentów, wraz z oznaczaniem stanu (typu: OK, Warning,
Error) w przypadku znalezienia zdarzeń wskazujących na problemy,
4.6.2. konsola systemu musi umożliwiać podgląd na stan poszczególnych usług wraz
z podstawowymi informacjami o stanie usługi, np. ilość wykorzystywanego miejsca
na dysku twardym.
5. System zarządzania komponentami musi udostępniać funkcje pozwalające na budowę bezpiecznych
i skalowalnych mechanizmów zarządzania komponentami IT spełniając następujące wymagania:
5.1. Architektura:
5.1.1. serwery zarządzające muszą mieć możliwość publikowania informacji
o uruchomionych komponentach w usługach katalogowych, informacje te muszą
być dostępne dla klientów systemu w celu automatycznej konfiguracji,
18
5.1.2.
możliwość budowania struktury wielopoziomowej (tiers) w celu separacji pewnych
grup komputerów/usług,
5.1.3. system uprawnień musi być oparty o role (role based security), użytkownicy
i grupy użytkowników w poszczególnych rolach powinny być pobierane z usług
katalogowych,
5.1.4. możliwość definiowania użytkowników do wykonywania poszczególnych zadań na
klientach i serwerze zarządzającym, w tym zdefiniowany użytkownik domyślny,
5.1.5. uwierzytelnianie klientów na serwerze zarządzającym przy pomocy certyfikatów
w standardzie X.509, z możliwością odrzucania połączeń od klientów
niezaakceptowanych,
5.1.6. kanał komunikacyjny pomiędzy klientami a serwerem zarządzającym musi być
szyfrowany,
5.1.7. możliwość budowania systemu w oparciu o łącza publiczne - Internet (bez
konieczności wydzielania kanałów VPN),
5.1.8. wsparcie dla protokołu IPv6,
5.1.9. system musi udostępniać funkcje autodiagnostyczne, w tym: monitorowanie stanu
klientów, możliwość automatycznego lub administracyjnego restartu klienta,
możliwość reinstalacji klienta.
5.2. Audyt zdarzeń bezpieczeństwa:
5.2.1. system musi udostępniać komponenty i funkcje pozwalające na zbudowanie
systemu zbierającego zdarzenia związane z bezpieczeństwem monitorowanych
systemów i gwarantować:
5.2.1.1. przekazywanie zdarzeń z podległych klientów w czasie „prawie”
rzeczywistym (dopuszczalne opóźnienia mogą pochodzić z medium
transportowego – sieć, oraz komponentów zapisujących
i odczytujących),
5.2.1.2. niskie obciążenie sieci poprzez schematyzację parametrów zdarzeń
przed wysłaniem, definicja schematu musi być definiowana w pliku XML
z możliwością dodawania i modyfikacji,
5.2.1.3. obsługę co najmniej 2500 zdarzeń/sek w trybie ciągłym i 100000
zdarzeń/sek w trybie „burst” – chwilowy wzrost ilości zdarzeń, jeden
kolektor zdarzeń musi obsługiwać, co najmniej 100 kontrolerów domen
(lub innych systemów autentykacji i usług katalogowych) lub 1000
serwerów.
6. Konfiguracja i monitorowanie:
6.1. System musi umożliwiać zbudowanie jednorodnego środowiska monitorującego, korzystając
z takich samych zasad do monitorowania różnych komponentów, a w tym:
6.1.1. monitorowane obiekty powinny być grupowane (klasy) w oparciu o atrybuty, które
można wykryć na klientach systemu w celu autokonfiguracji systemu. Powinny być
wykrywane - co najmniej, atrybuty pobierane z:
6.1.1.1. rejestru,
6.1.1.2. WMI,
6.1.1.3. OLEDB,
6.1.1.4. LDAP,
6.1.1.5. skrypty (uruchamiane w celu wykrycia atrybutów obiektu),
6.1.1.6. w definicjach klas powinny być również odzwierciedlone zależności
pomiędzy nimi.
19
6.2. Na podstawie wykrytych atrybutów system musi dokonywać autokonfiguracji klientów, przez
wysłanie odpowiadającego wykrytym obiektom zestawu monitorów, reguł, skryptów, zadań,
itp.
6.3. Wszystkie klasy obiektów, monitory, reguły, skrypty, zadania, itp. elementy służące konfiguracji
systemu muszą być grupowane i dostarczane w postaci zestawów monitorujących, system musi
posiadać w standardzie zestawy monitorujące wykorzystywane przez Zamawiającego, co
najmniej dla:
6.3.1. Windows Server 2003/2008/2008R2/2012R2,
6.3.2. Active Directory 2008/2012R2
6.3.3. Exchange 2013,
6.3.4. Microsoft SharePoint 2013,
6.3.5. Microsoft SharePoint Services 3.0,
6.3.6. SQL 2005/2008/2008R2/2014,
6.3.7. Windows Client OS (XP,7, Windows 8.1, Windows 10) (32/64bit),
6.3.8. Information Worker (Office, IExplorer, Outlook, itp.),
6.3.9. IIS 6.0/7.0/7.5,
6.3.10. Novell SUSE Linux Enterprise Server 9,
6.4. System musi posiadać możliwość monitorowania, za pomocą agenta lub bez niego.
6.5. System musi pozwalać na wykrycie oraz monitorowanie posiadanych przez Zamawiającego
urządzeń sieciowych (routery, przełączniki sieciowe, itp.) za pomocą SNMP v1, v2c oraz v3.
System monitorowania w szczególności musi mieć możliwość zbierania następujących
informacji:
6.5.1. interfejsy sieciowe,
6.5.2. porty,
6.5.3. sieci wirtualne (VLAN),
6.5.4. grupy Hot Standby Router Protocol (HSRP).
6.6. System zarządzania musi mieć możliwość czerpania informacji z następujących źródeł danych
posiadanych przez Zamawiającego:
6.6.1. SNMP (trap, probe),
6.6.2. WMI Performance Counters,
6.6.3. Log Files (text, text CSV),
6.6.4. Windows Events (logi systemowe),
6.6.5. Windows Services,
6.6.6. Windows Performance Counters (perflib),
6.6.7. WMI Events,
6.6.8. Scripts (wyniki skryptów, np.: WSH, JSH),
6.6.9. Unix/Linux Service,
6.6.10. Unix/Linux Log.
6.7. Na podstawie uzyskanych informacji monitor musi aktualizować status komponentu, musi być
możliwość łączenia i agregowania statusu wielu monitorów.
7. Tworzenie reguł:
7.1. W systemie zarządzania musi być możliwość czerpania informacji z następujących źródeł
danych:
7.1.1. Event based (text, text CSV, NT Event Log, SNMP Event, SNMP Trap, syslog, WMI
Event),
7.1.2. Performance based (SNMP performance, WMI performance, Windows
performance),
20
7.1.3. Probe based (scripts: event, performance).
7.2. System musi umożliwiać przekazywanie zebranych przez reguły informacji do bazy danych w
celu ich późniejszego wykorzystania w systemie, np. raporty dotyczące wydajności
komponentów, alarmy mówiące o przekroczeniu wartości progowych czy wystąpieniu
niepożądanego zdarzenia.
7.3. Reguły zbierające dane wydajnościowe muszą mieć możliwość ustawiania tolerancji na zmiany,
w celu ograniczenia ilości nieistotnych danych przechowywanych w systemie bazodanowym.
Tolerancja musi mieć, co najmniej dwie możliwości:
7.3.1. na ilość takich samych próbek o takiej samej wartości,
7.3.2. na procentową zmianę od ostatniej wartości próbki.
7.4. Monitory sprawdzające dane wydajnościowe w celu wyszukiwania wartości progowych muszą
mieć możliwość – oprócz ustawiania progów statycznych, „uczenia” się monitorowanego
parametru w zakresie przebiegu bazowego „baseline” w zadanym okresie czasu.
7.5. System musi umożliwiać blokowanie modyfikacji zestawów monitorujących, oraz definiowanie
wyjątków na grupy komponentów lub konkretne komponenty w celu ich odmiennej
konfiguracji.
7.6. System musi posiadać narzędzia do konfiguracji monitorów dla aplikacji i usług
wykorzystywanych przez Zamawiającego, w tym:
7.6.1. ASP .Net Application,
7.6.2. ASP .Net Web Service,
7.6.3. OLE DB,
7.6.4. TCP Port,
7.6.5. Web Application,
7.6.6. Windows Service,
7.6.8. Process Monitoring,
7.6.9. Narzędzia te powinny pozwalać na zbudowanie zestawu predefiniowanych
monitorów dla wybranej aplikacji i przyporządkowanie ich do wykrytej/działającej
aplikacji.
7.7. System musi posiadać narzędzia do budowania modeli aplikacji rozproszonych (składających się
z wielu wykrytych obiektów), pozwalając na agregację stanu aplikacji oraz zagnieżdżanie
aplikacji.
7.8. Z każdym elementem monitorującym (monitor, reguła, alarm, itp.) musi być skojarzona baza
wiedzy, zawierająca informacje o potencjalnych przyczynach problemów oraz możliwościach
ich rozwiązania (w tym możliwość uruchamiania zadań diagnostycznych z poziomu
administratora).
7.9. System musi zbierać informacje udostępniane przez systemy operacyjne Windows
o przyczynach krytycznych błędów (crash) udostępnianych potem do celów analitycznych.
7.10. System musi umożliwiać budowanie obiektów SLO (Service Level Object) służących
przedstawianiu informacji dotyczących zdefiniowanych poziomów SLA (Service Level
Agreement) przynajmniej dla: monitora (dostępność), i licznika wydajności (z agregacją dla
wartości – min, max, avg).
8. Przechowywanie i dostęp do informacji:
8.1. Wszystkie informacje operacyjne (zdarzenia, liczniki wydajności, informacje o obiektach,
alarmy, itp.) powinny być przechowywane w bazie danych operacyjnych.
21
8.2. System musi mieć co najmniej jedną bazę danych z przeznaczeniem na hurtownię danych do
celów historycznych i raportowych. Zdarzenia powinny być umieszczane w obu bazach
jednocześnie, aby raporty mogłyby być generowane w oparciu o najświeższe dane.
8.3. System musi mieć osobną bazę danych, do której będą zbierane informacje na temat zdarzeń
security z możliwością ustawienia innych uprawnień dostępu do danych tam zawartych (tylko
audytorzy).
8.4. System musi mieć zintegrowany silnik raportujący niewymagający do tworzenia raportów
używania produktów firm trzecich. Produkty takie mogą być wykorzystanie w celu rozszerzenia
tej funkcjonalności.
8.5. System musi mieć możliwość generowania raportów na życzenie oraz tworzenie zadań
zaplanowanych.
8.6. System musi umożliwiać eksport stworzonych raportów przynajmniej do następujących
formatów:
8.6.1. XML,
8.6.2. CSV,
8.6.3. TIFF,
8.6.4. PDF,
8.6.5. XLS,
8.6.6. Web archive.
9. Konsola systemu zarządzania:
9.1. Konsola systemu musi umożliwiać pełny zdalny dostęp do serwerów zarządzających dając
dostęp do zasobów zgodnych z rolą użytkownika korzystającego z konsoli.
9.2. System musi udostępniać dwa rodzaje konsoli:
9.2.1. w postaci programu do zainstalowania na stacjach roboczych, obsługującą
wszystkie funkcje systemu (konsola zdalna),
9.2.2. w postaci web’owej dla dostępu do podstawowych komponentów monitorujących
z dowolnej stacji roboczej (konsola webowa).
9.3. Konsola zdalna musi umożliwiać definiowanie każdemu użytkownikowi własnych widoków,
co najmniej w kategoriach typu:
9.3.1. Alerts – alarmy,
9.3.2. Events – zdarzenia,
9.3.3. State – stany,
9.3.4. Performance – wydajność,
9.3.5. Diagram – diagramy,
9.3.6. Task Status – status zadań,
9.3.7. Web Page (dla użytkowników, którzy potrzebują podglądu tylko wybranych
elementów systemu).
9.4. Konsola musi umożliwiać budowanie widoków tablicowych (dashboard) w celu prezentacji
różnych widoków na tym samym ekranie.
9.5. Widoki muszą posiadać możliwość filtrowania informacji, jakie się na nich znajdą (po typie,
ważności, typach obiektów, itp.), sortowania oraz grupowania podobnych informacji, wraz
z możliwością definiowania kolumn, jakie mają się znaleźć na widokach „kolumnowych”.
9.6. Z każdym widokiem (obiektem w tym widoku) musi być skojarzone menu kontekstowe,
z najczęstszymi operacjami dla danego typu widoku/obiektu.
9.7. Konsola musi zapewnić dostęp do wszystkich opcji konfiguracyjnych systemu (poza opcjami
dostępnymi w procesie instalacji i wstępnej konfiguracji), w tym:
9.7.1. opcji definiowania ról użytkowników,
22
9.7.2. opcji definiowania widoków,
9.7.3. opcji definiowania i generowania raportów,
9.7.4. opcji definiowania powiadomień,
9.7.5. opcji tworzenia, konfiguracji i modyfikacji zestawów monitorujących,
9.7.6. opcji instalacji/deinstalacji klienta.
9.8. Konsola musi pozwalać na pokazywanie obiektów SLO (Service Level Object) i raportów SLA
(Service Level Agreement) bez potrzeby posiadania konsoli i dostępu do samego systemu
monitorującego, na potrzeby użytkowników biznesowych (właścicieli procesu biznesowego).
10. Pozostałe wymagania:
10.1. System musi dostarczać API lub inny system (web service, connector) z publicznie dostępną
dokumentacją pozwalający m.in. na:
10.1.1. Budowanie konektorów do innych systemów, np. help-desk w celu przekazywania
zdarzeń czy alarmów (dwukierunkowo),
10.1.2. Wykonywanie operacji w systemie z poziomu linii poleceń,
10.1.3. Podłączenie rozwiązań firm trzecich pozwalających na monitorowanie w jednolity
sposób systemów informatycznych niewspieranych natywnie przez system
zarządzania,
10.1.4. Podłączenie do aplikacji biurowych pozwalające na integrację statycznych modeli
(np. diagramów Visio) z monitorowanymi obiektami, pozwalające na wyświetlanie
ich stanu na diagramie.
11. System zarządzania środowiskami wirtualnym musi posiadać następujące cechy:
11.1. Architektura:
11.1.1. System zarządzania środowiskiem wirtualnym musi składać się z:
11.1.1.1. serwera zarządzającego,
11.1.1.2. relacyjnej bazy danych przechowującej informacje o zarządzanych
elementach,
11.1.1.3. konsoli, instalowanej na komputerach operatorów,
11.1.1.4. portalu
self-service
(konsoli
webowej)
dla
operatorów
„departamentowych”,
11.1.1.5. biblioteki, przechowującej komponenty niezbędne do budowy maszyn
wirtualnych,
11.1.1.6. agenta instalowanego na zarządzanych hostach wirtualizacyjnych,
11.1.1.7. „konektora” do systemu monitorującego pracę hostów i maszyn
wirtualnych.
11.1.2. System musi mieć możliwość tworzenia konfiguracji wysokiej dostępności (klaster
typu fail-over),
11.1.3. System musi pozwalać na zarządzanie platformami wirtualizacyjnymi co najmniej
trzech różnych producentów,
11.2. Interfejs użytkownika:
11.2.1. Konsola musi umożliwiać wykonywanie codziennych zadań związanych
z zarządzaniem maszynami wirtualnymi w sposób jak najbardziej intuicyjny,
11.2.2. Konsola musi umożliwiać grupowanie hostów i nadawanie uprawnień
poszczególnym operatorom do grup hostów,
11.2.3. Widoki hostów i maszyn wirtualnych muszą mieć możliwość zakładania filtrów,
pokazując tylko odfiltrowane elementy, np. maszyny wyłączone, maszyny
z systemem operacyjnym X, itp.,
23
11.2.4. Widok szczegółowy elementu w przypadku maszyny wirtualnej musi pokazywać
stan, ilość alokowanej pamięci i dysku twardego, system operacyjny, platformę
wirtualizacyjną, stan ostatniego zadania oraz wykres utylizacji procesora
i podgląd na pulpit,
11.2.5. Konsola musi posiadać odrębny widok z historią wszystkich zadań oraz statusem
zakończenia poszczególnych etapów i całych zadań.
11.3.
Scenariusze i zadania:
11.3.1. Tworzenie maszyn wirtualnych – system musi umożliwiać stworzenie maszyny
wirtualnej w co najmniej dwóch trybach:
11.3.1.1. ad hoc – gdzie wszystkie elementy są wybierane przez operatora podczas
tworzenia maszyny,
11.3.1.2. nadzorowany – gdzie operator tworzy maszynę korzystając z gotowego
wzorca (template), a wzorzec składa się z przynajmniej 3-ech elementów
składowych:
11.3.1.2.1. profilu sprzętowego,
11.3.1.2.2. profilu systemu operacyjnego,
11.3.1.2.3. przygotowanych dysków twardych.
11.3.1.3. predefiniowane elementy muszą być przechowywane w bibliotece
systemu zarządzania,
11.3.1.4. system musi umożliwiać przenoszenie maszyny wirtualnej pomiędzy
zarządzanymi hostami:
11.3.1.4.1. w trybie migracji „on-line” – bez przerywania pracy,
11.3.1.4.2. w trybie migracji „off-line – z zapisem stanu maszyny.
11.3.2. system musi umożliwiać automatyczne, równomierne rozłożenie obciążenia
pomiędzy zarządzanymi hostami,
11.3.3. system musi umożliwiać wyłączenie hosta, gdy jego zasoby nie są konieczne do
pracy, w celu oszczędności energii. System musi również umożliwiać ponowne
włączenie takiego hosta,
11.3.4. system musi umożliwiać przełączenie wybranego hosta w tryb „maintenance”
w przypadku wystąpienia awarii lub w celu przeprowadzenia planowanych prac
serwisowych. Uruchomienie tego trybu musi skutkować migracją maszyn na inne
hosty lub zapisaniem ich stanu,
11.3.5. system musi posiadać możliwość konwersji maszyny fizycznej do wirtualnej,
11.3.6. system musi posiadać (bez potrzeby instalowania dodatkowego oprogramowania)
- możliwość wykrycia maszyny fizycznej w sieci i instalacje na niej systemu
operacyjnego wraz z platformą do wirtualizacji,
12.1. System musi informować operatora o potrzebie migracji maszyn, jeśli wystąpią
nieprawidłowe zdarzenia na hoście lub w innych maszynach wirtualnych mające wpływ na
ich pracę, np. awarie sprzętu, nadmierna utylizacja współdzielonych zasobów przez jedną
maszynę,
12.2. System musi dawać operatorowi możliwość implementacji ww. migracji w sposób
automatyczny bez potrzeby każdorazowego potwierdzania,
12.3. System musi kreować raporty z działania zarządzanego środowiska, w tym:
12.3.1. utylizacja poszczególnych hostów,
12.3.2. trend w utylizacji hostów,
12.3.3. alokacja zasobów na centra kosztów,
24
12.3.4. utylizacja poszczególnych maszyn wirtualnych,
12.3.5. komputery-kandydaci do wirtualizacji.
12.4. System musi umożliwiać skorzystanie z szablonów:
12.4.1. wirtualnych maszyn,
12.4.2. usług,
12.4.3. oraz profili dla:
12.4.3.1. aplikacji,
12.4.3.2. serwera SQL,
12.4.3.3. hosta,
12.4.3.4. sprzętu,
12.4.3.5. systemu operacyjnego gościa.
12.5. System musi umożliwiać tworzenie chmur prywatnych na podstawie dostępnych zasobów
(hosty, sieci, przestrzeń dyskowa, biblioteki zasobów),
12.6. System musi posiadać możliwość przygotowania i instalacji zwirtualizowanej aplikacji
serwerowej,
12.7. System musi pozwalać na skalowalność wirtualnego środowiska aplikacji (poprzez
automatyczne dodanie wirtualnej maszyny z aplikacją).
13. System tworzenia i odtwarzania kopii zapasowych danych (backup) wykorzystujący scenariusze
tworzenia kopii na zasobach taśmowych lub dyskowych musi spełniać następujące wymagania:
13.1. System musi składać się z:
13.1.1. serwera zarządzającego kopiami zapasowymi i agentami kopii zapasowych,
13.1.2. agentów kopii zapasowych instalowanych na komputerach zdalnych,
13.1.3. konsoli zarządzającej,
13.1.4. relacyjnej bazy danych przechowującej informacje o zarządzanych elementach,
13.1.5. wbudowany mechanizm raportowania i notyfikacji poprzez pocztę elektroniczną,
13.1.6. System kopii zapasowych musi wykorzystywać mechanizm migawkowych kopii.
13.2. System kopii zapasowych musi umożliwiać:
13.2.1. zapis danych na puli magazynowej złożonej z dysków twardych,
13.2.2. zapis danych na bibliotekach taśmowych,
13.2.3. System kopii zapasowych musi umożliwiać zdefiniowanie ochrony zasobów
krótkookresowej i długookresowej. Oznacza to, iż krótkookresowe kopie mogą być
tworzone w puli magazynowej, a następnie po zdefiniowanym okresie,
automatycznie przenoszone na biblioteki taśmowe,
13.2.4. System kopii zapasowych musi posiadać kopie danych produkcyjnych w swojej puli
magazynowej,
13.2.5. Dane przechowywane w puli magazynowej muszą używać mechanizmów
oszczędzających wykorzystane miejsce dyskowe, takie jak pojedyncza instancja
przechowywania,
13.2.6. System kopii zapasowych musi w przypadku wykonywania pełnej kopii zapasowej
kopiować jedynie te bloki, które uległy zmianie od ostatniej pełnej kopii,
13.2.7. System kopii zapasowych musi umożliwiać przywrócenie:
13.2.7.1. danych plikowych,
13.2.7.2. danych aplikacyjnych,
13.2.7.3. stanu systemu (Systemstate),
13.2.7.4. obrazu systemu operacyjnego (tzw. Bare Metal Restore).
25
13.3. System kopii zapasowej podczas wykonywania pełnej kopii zapasowej musi uaktualniać
chronione dane o dodatkowy punkt przywracania danych, minimalizując ilość przesyłanych
danych,
13.4. System kopii zapasowych musi umożliwiać rozwiązanie automatycznego przenoszenia
chronionych danych do zdalnej lokalizacji, wykorzystując przy tym mechanizm regulacji
maksymalnej przepustowości,
13.5. Agenci systemu kopii zapasowych muszą posiadać konfiguracje dotyczącą zdefiniowania
godzin pracy, a także dostępnej przepustowości w czasie godzin pracy i poza godzinami pracy,
13.6. System kopii zapasowych musi rozpoznawać aplikacje wykorzystywane przez
Zamawiającego:
13.6.1. ze względu na tworzone logi transakcyjne:
13.6.1.1. Serwer pocztowy,
13.6.1.2. Portal wielofunkcyjny,
13.6.1.3. Serwer bazy danych.
13.6.2. ze względu na zapewnienie nieprzerwalności pracy
13.6.2.1. Środowisko wirtualne.
13.7. Komunikacja z serwerem kopii zapasowych musi odbywać się po jawnie zdefiniowanych
portach,
13.8. Konsola musi umożliwiać wykonywanie i tworzenie określonych harmonogramów
wykonywania kopii zapasowych na chronionych agentach,
13.9. Konsola musi umożliwiać grupowanie chronionych zasobów ze względu na typy chronionych
zasobów,
13.10. Zarządzanie agentami i zadaniami kopii zapasowych musi być możliwe również za pomocą
linii poleceń,
13.11. System kopii zapasowych musi umożliwiać odzyskanie chronionych zasobów plikowych przez
użytkownika końcowego z poziomu zakładki „Poprzednie wersje”,
13.12. Konsola musi posiadać mechanizm kontrolowania wykonywanych zadań kopii zapasowych ,
13.13. Konsola musi posiadać mechanizm notyfikacji administratorów odnośnie zdarzeń
w systemie kopii zapasowych,
13.14. Konsola musi posiadać wbudowany system raportujący (m.in. raporty dotyczące zużycia puli
magazynowej, wykonania kopii zapasowych, itp.),
13.15. System kopii zapasowych musi umożliwiać przechowywanie danych w puli magazynowej do
1 roku,
13.16. System kopii zapasowych musi umożliwiać przechowywanie danych na podłączonych
bibliotekach taśmowych powyżej 25 lat,
13.17. System kopii zapasowych musi umożliwiać synchronizację przechowywanych kopii
zapasowych (kopie inkrementalne) z produkcyjnymi transakcyjnymi bazami danych (bazy
danych, poczta elektroniczna, portale intranetowe) na poziomie poniżej 30 minut. Kopie te
muszą być tworzone w ciągu godzin pracy, w niezauważalny dla użytkowników końcowych
sposób,
13.18. System kopii zapasowych musi umożliwiać odtworzenie dowolnego 30 minutowego kwantu
czasu dla krytycznych aplikacji, takich jak bazy transakcyjne, poczta elektroniczna, portale
intranetowe,
13.19. System kopii zapasowych musi umożliwiać odtworzenie danych do:
13.19.1. lokalizacji oryginalnej,
13.19.2. lokalizacji alternatywnej,
26
13.19.3. w przypadku drugiego serwera kopii zapasowych (w centrum zapasowym) do
pierwszego serwera kopii zapasowych.
14. System automatyzacji zarządzania środowisk IT musi udostępniać bezskryptowe środowisko
standaryzujące i automatyzujące zarządzanie środowiskiem IT.
14.1. System musi umożliwiać testowanie sytuacji krytycznych i występowanie różnych
incydentów w systemie,
14.2. System musi wspomagać automatyzację procesów zarządzania zmianami konfiguracji
środowisk IT,
14.3. System musi wspomagać planowanie i automatyzację wdrażania poprawek,
14.4. System musi umożliwiać zarządzanie życiem środowisk wirtualnych,
14.5. System musi udostępniać mechanizmy workflow automatyzujące zadania administracyjne
wraz z graficznym interfejsem projektowania, budowy i monitorowania workflow,
15. System zarządzania incydentami i problemami musi spełniać następujące wymagania:
15.1. System musi posiadać rozwiązanie help-deskowe umożliwiające użytkownikom zgłaszanie
problemów technicznych oraz zapotrzebowanie na zasoby IT (np. nowa maszyna wirtualna),
15.2. System musi mieć postać zintegrowanej platformy pozwalającej poprzez wbudowane
i definiowane mechanizmy w ramach przyjętej metodyki (np. MOF czy ITIL) na zarządzanie
incydentami i problemami oraz zarządzanie zmianą,
15.3. System musi posiadać bazę wiedzy (CMDB) automatycznie zasilaną z takich systemów jak:
usługa katalogowa, system monitorujący, system do zarządzania desktopami,
15.4. System musi udostępniać narzędzia efektywnego zarządzania dostępnością usług,
umożliwiających dostarczenie użytkownikom systemów SLA na wymaganym poziomie,
15.5. System, poprzez integrację z systemami zarządzania i monitorowania musi zapewniać:
15.5.1. optymalizację procesów i ich prawidłową realizację poprzez predefiniowane
scenariusze, zgodne z najlepszymi praktykami i założoną metodyką,
15.5.2. redukcję czasu rozwiązywania problemów z działaniem systemów poprzez
zapewnienie dotarcia właściwej, zagregowanej informacji do odpowiedniego
poziomu linii wsparcia,
15.5.3. automatyczne generowanie opisu problemów na bazie alarmów i kojarzenie zdarzeń
w różnych komponentach systemu,
15.5.4. wspomaganie procesów podejmowania decyzji poprzez integrację informacji
i logikę ich powiązania,
15.5.5. planowanie działań prewencyjnych poprzez kolekcjonowanie informacji
o zachowaniach systemu w przypadku incydentów,
15.5.6. raportowanie pozwalające na analizy w zakresie usprawnień systemu oraz
usprawnień procesów ich opieki serwisowej,
15.5.7. tworzenie baz wiedzy na temat rozwiązywania problemów,
15.5.8. automatyzację działań w przypadku znanych i opisanych problemów,
15.5.9. wykrywanie odchyleń od założonych standardów ustalonych dla systemu.
16. Ochrona antymalware musi spełniać następujące wymagania:
16.1. Ochrona przed zagrożeniami typu wirusy, robaki, trojany, rootkity, ataki typu phishing czy
exploity zero-day,
16.2. Centralne zarządzanie ochroną serwerów poprzez konsolę System zarządzania infrastrukturą
i oprogramowaniem,
16.3. Centralne zarządzanie politykami ochrony,
16.4. Automatyzacja wdrożenia i wymiany dotychczasowych agentów ochrony,
16.5. Mechanizmy wspomagające masową instalację,
27
16.6. System ma wykrywać wirusy, oprogramowanie szpiegowskie i inne pliki przed ich
uruchomieniem, dając dzięki temu wydajną ochronę przed wieloma zagrożeniami, a
jednocześnie minimalizując zaangażowanie użytkownika końcowego,
16.7. Aparat ochrony przed złośliwym oprogramowaniem ma używać zaawansowanych
technologii wykrywania, takich jak analiza statyczna, emulacja, heurystyka i tunelowanie w
celu identyfikacji złośliwego oprogramowania i ochrony systemu. Ponieważ zagrożenia stają
się coraz bardziej złożone, ważne jest, aby zapewnić nie tylko oczyszczenie systemu, ale
również poprawne jego funkcjonowanie po usunięciu złośliwego oprogramowania. Aparat
ochrony przed złośliwym oprogramowaniem w systemie ma zawierać zaawansowane
technologie oczyszczania, pomagające przywrócić poprawny stan systemu po usunięciu
złośliwego oprogramowania,
16.8. Generowanie alertów dla ważnych zdarzeń, takich jak atak złośliwego oprogramowania czy
niepowodzenie próby usunięcia zagrożenia,
16.9. Tworzenie szczegółowych raportów zabezpieczeń systemów IT o określonych priorytetach,
dzięki którym użytkownik może wykrywać i kontrolować zagrożenia lub słabe punkty
zabezpieczeń. Raporty mają obejmować nie tylko takie informacje, jak ilość ataków wirusów,
ale wszystkie aspekty infrastruktury IT, które mogą wpłynąć na bezpieczeństwo firmy (np.
ilość komputerów z wygasającymi hasłami, ilość maszyn, na których jest zainstalowane konto
„gościa”, itd.),
16.10. Pakiet ma umożliwiać zdefiniowanie jednej zasady konfigurującej technologie
antyszpiegowskie, antywirusowe i technologie monitorowania stanu jednego lub wielu
chronionych komputerów. Zasady obejmują również ustawienia poziomów alertów, które
można konfigurować, aby określić rodzaje alertów i zdarzeń generowanych przez różne grupy
chronionych komputerów oraz warunki ich zgłaszania,
16.11. System ochrony musi być zoptymalizowany pod kątem konfiguracji ustawień agenta
zabezpieczeń przy użyciu Zasad Grupy usługi katalogowej oraz dystrybucji aktualizacji
definicji.
4.4 Serwerowy system operacyjny z elementami zarządzania typ II
Serwerowy system operacyjny (SSO)
1. Liczba rdzeni procesorów i ilość pamięci nie mogą mieć wpływu na liczbę wymaganych licencji.
Licencja musi uprawniać do uruchamiania serwerowego systemu operacyjnego (SSO)
w środowisku fizycznym i nielimitowanej liczby wirtualnych środowisk serwerowego systemu
operacyjnego za pomocą wbudowanych mechanizmów wirtualizacji.
2. Serwerowy system operacyjny (SSO) typ II musi posiadać następujące, wbudowane cechy:
2.1. Możliwość wykorzystania, do 320 logicznych procesorów oraz co najmniej 4 TB pamięci RAM
w środowisku fizycznym,
2.2. Możliwość wykorzystywania 64 procesorów wirtualnych oraz 1TB pamięci RAM i dysku
o pojemności do 64TB przez każdy wirtualny serwerowy system operacyjny,
2.3. Możliwość budowania klastrów składających się z 64 węzłów, z możliwością uruchamiania do
8000 maszyn wirtualnych,
2.4. Możliwość migracji maszyn wirtualnych bez zatrzymywania ich pracy między fizycznymi
serwerami z uruchomionym mechanizmem wirtualizacji (hypervisor) przez sieć Ethernet, bez
konieczności stosowania dodatkowych mechanizmów współdzielenia pamięci,
28
2.5.
2.6.
2.7.
2.8.
2.9.
2.10.
2.11.
2.12.
2.13.
2.14.
2.15.
2.16.
2.17.
2.18.
2.19.
2.20.
2.21.
Wsparcie (na umożliwiającym to sprzęcie) dodawania i wymiany pamięci RAM bez
przerywania pracy,
Wsparcie (na umożliwiającym to sprzęcie) dodawania i wymiany procesorów bez
przerywania pracy,
Automatyczna weryfikacja cyfrowych sygnatur sterowników w celu sprawdzenia, czy
sterownik przeszedł testy jakości przeprowadzone przez producenta systemu operacyjnego,
Możliwość dynamicznego obniżania poboru energii przez rdzenie procesorów
niewykorzystywane w bieżącej pracy. Mechanizm ten musi uwzględniać specyfikę
procesorów wyposażonych w mechanizmy Hyper-Threading wykorzystywane przez
Zamawiającego.
Wbudowane wsparcie instalacji i pracy na wolumenach, które:
2.9.1. pozwalają na zmianę rozmiaru w czasie pracy systemu,
2.9.2. umożliwiają tworzenie w czasie pracy systemu migawek, dających użytkownikom
końcowym (lokalnym i sieciowym) prosty wgląd w poprzednie wersje plików
i folderów,
2.9.3. umożliwiają kompresję "w locie" dla wybranych plików i/lub folderów,
2.9.4. umożliwiają zdefiniowanie list kontroli dostępu (ACL).
Wbudowany mechanizm klasyfikowania i indeksowania plików (dokumentów) w oparciu
o ich zawartość,
Wbudowany mechanizm szyfrowania dysków,
Możliwość uruchamianie aplikacji internetowych wykorzystujących technologię ASP.NET,
Możliwość dystrybucji ruchu sieciowego HTTP pomiędzy kilka serwerów,
Wbudowana zapora internetowa (firewall) z obsługą definiowanych reguł dla ochrony
połączeń internetowych i intranetowych,
Graficzny interfejs użytkownika,
Menu, przeglądarka internetowa, pomoc, komunikaty systemowe – w języku polskim,
Możliwość zmiany języka interfejsu po zainstalowaniu systemu, dla co najmniej 10 języków
poprzez wybór z listy dostępnych lokalizacji,
Wsparcie dla większości powszechnie używanych urządzeń peryferyjnych (w szczególności:
drukarek, urządzeń sieciowych, standardów USB, Plug&Play),
Możliwość zdalnej konfiguracji, administrowania oraz aktualizowania systemu,
Dostępność bezpłatnych narzędzi producenta systemu umożliwiających badanie i wdrażanie
zdefiniowanego zestawu polityk bezpieczeństwa,
Możliwość implementacji następujących funkcjonalności:
2.21.1. podstawowe usługi sieciowe: DHCP oraz DNS wspierający DNSSEC,
2.21.2. usługi katalogowe oparte o LDAP i pozwalające na uwierzytelnianie użytkowników
stacji roboczych, bez konieczności instalowania dodatkowego oprogramowania na
tych stacjach, pozwalające na zarządzanie zasobami w sieci (użytkownicy,
komputery, drukarki, udziały sieciowe), z możliwością wykorzystania następujących
funkcji:
2.21.2.1. podłączenie SSO do domeny w trybie offline – bez dostępnego połączenia
sieciowego z domeną,
2.21.2.2. ustanawianie praw dostępu do zasobów domeny na bazie sposobu
logowania użytkownika – na przykład typu certyfikatu użytego do
logowania,
2.21.2.3. odzyskiwanie przypadkowo skasowanych obiektów usługi katalogowej
z mechanizmu kosza.
29
2.21.3. zdalna dystrybucja oprogramowania na stacje robocze,
2.21.4. praca zdalna na serwerze z wykorzystaniem terminala (cienkiego klienta) lub
odpowiednio skonfigurowanej stacji roboczej,
2.21.5. centrum Certyfikatów (CA), obsługa klucza publicznego i prywatnego umożliwiające:
2.21.5.1. dystrybucję certyfikatów poprzez http,
2.21.5.2. konsolidację CA dla wielu lasów domeny,
2.21.5.3. automatyczne rejestrowania certyfikatów pomiędzy różnymi lasami
domen,
2.21.5.4. szyfrowanie plików i folderów,
2.21.5.5. szyfrowanie połączeń sieciowych pomiędzy serwerami oraz serwerami
i stacjami roboczymi (IPSec),
2.21.5.6. możliwość tworzenia systemów wysokiej dostępności (klastry typu failover) oraz rozłożenia obciążenia serwerów,
2.21.5.7. serwis udostępniania stron WWW,
2.21.5.8. wsparcie dla protokołu IP w wersji 6 (IPv6),
2.21.5.9. wbudowane usługi VPN pozwalające na zestawienie nielimitowanej liczby
równoczesnych połączeń i niewymagające instalacji dodatkowego
oprogramowania na komputerach z systemem Windows,
2.21.6. wbudowane mechanizmy wirtualizacji (Hypervisor) pozwalające na uruchamianie do
1000 aktywnych środowisk wirtualnych systemów operacyjnych. Wirtualne maszyny
w trakcie pracy i bez zauważalnego zmniejszenia ich dostępności mogą być
przenoszone pomiędzy serwerami klastra typu failover z jednoczesnym
zachowaniem pozostałej funkcjonalności. Mechanizmy wirtualizacji mają zapewnić
wsparcie dla:
2.21.6.1. dynamicznego podłączania zasobów dyskowych typu hot-plug do maszyn
wirtualnych,
2.21.6.2. obsługi ramek typu jumbo frames dla maszyn wirtualnych,
2.21.6.3. obsługi 4-KB sektorów dysków,
2.21.6.4. nielimitowanej liczby jednocześnie przenoszonych maszyn wirtualnych
pomiędzy węzłami klastra,
2.21.6.5. możliwości wirtualizacji sieci z zastosowaniem przełącznika, którego
funkcjonalność może być rozszerzana jednocześnie poprzez
oprogramowanie kilku innych dostawców poprzez otwarty interfejs API,
2.21.6.6. możliwości kierowania ruchu sieciowego z wielu sieci VLAN bezpośrednio
do pojedynczej karty sieciowej maszyny wirtualnej (tzw. trunkmode),
2.22. Możliwość automatycznej aktualizacji w oparciu o poprawki publikowane przez producenta
wraz z dostępnością bezpłatnego rozwiązania producenta SSO umożliwiającego lokalną
dystrybucję poprawek zatwierdzonych przez administratora, bez połączenia z siecią Internet,
2.23. Wsparcie dostępu do zasobu dyskowego SSO poprzez wiele ścieżek (Multipath),
2.24. Możliwość instalacji poprawek poprzez wgranie ich do obrazu instalacyjnego,
2.25. Mechanizmy zdalnej administracji oraz mechanizmy (również działające zdalnie)
administracji przez skrypty,
2.26. Możliwość zarządzania przez wbudowane mechanizmy zgodne ze standardami WBEM oraz
WS-Management organizacji DMTF,
3. Elementy zarządzania:
3.1. Licencja oprogramowania zarządzania środowiskami serwerowymi musi być przypisana do
każdego procesora fizycznego na serwerze zarządzanym. Oprogramowanie musi być
30
licencjonowane na minimum 2 fizyczne procesory serwera zarządzanego. Liczba rdzeni
procesorów i ilość pamięci nie mogą mieć wpływu na liczbę wymaganych licencji. Każda
licencja na 2 fizyczne procesory serwera musi uprawniać do zarządzania 2 środowiskami
systemu operacyjnego na tym serwerze.
3.2. Zarządzanie serwerem musi obejmować wszystkie funkcje zawarte w opisanych poniżej
modułach:
3.2.1. system zarządzania infrastrukturą i oprogramowaniem,
3.2.2. system zarządzania komponentami,
3.2.3. system zarządzania środowiskami wirtualnym,
3.2.4. system tworzenia kopii zapasowych,
3.2.5. system automatyzacji zarządzania środowisk IT,
3.2.6. system zarządzania incydentami i problemami,
3.2.7. ochrona antymalware.
4. System zarządzania infrastrukturą i oprogramowaniem musi spełniać następujące wymagania
poprzez wbudowane mechanizmy, bez użycia dodatkowych aplikacji:
4.1. Inwentaryzacja i zarządzanie zasobami:
4.1.1. inwentaryzacja zasobów serwera musi się odbywać w określonych przez
administratora systemu interwałach czasowych. System musi mieć możliwość
odrębnego planowania inwentaryzacji sprzętu i oprogramowania,
4.1.2. inwentaryzacja sprzętu musi się odbywać przez pobieranie informacji z interfejsu
WMI, komponent inwentaryzacyjny musi mieć możliwość konfiguracji w celu
ustalenia informacji, o podzespołach, które będą przekazywane do systemu,
4.1.3. inwentaryzacja oprogramowania musi skanować zasoby dyskowe przekazując dane
o znalezionych plikach do systemu w celu identyfikacji oprogramowania oraz celów
wyszukiwania i gromadzenia informacji o szczególnych typach plików (np. pliki
multimedialne: wav, mp3, avi, xvid, itp.),
4.1.4. system musi posiadać własną bazę dostępnego na rynku komercyjnego
oprogramowania, pozwalającą na identyfikację zainstalowanego i użytkowanego
oprogramowania, system musi dawać możliwość aktualizacji tej bazy przy pomocy
konsoli administratora oraz automatycznie przez aktualizacje ze stron producenta,
4.1.5. informacje inwentaryzacyjne powinny być przesyłane przy pomocy plików
różnicowych w celu ograniczenia ruchu z agenta do serwera.
4.2. Użytkowane oprogramowanie – pomiar wykorzystania:
4.2.1. system musi mieć możliwość zliczania uruchomionego oprogramowania w celu
śledzenia wykorzystania,
4.2.2. reguły dotyczące monitorowanego oprogramowania powinny być tworzone
automatycznie przez skanowanie oprogramowania uruchamianego.
4.3. System musi dostarczać funkcje dystrybucji oprogramowania, dystrybucji i zarządzania
aktualizacjami, instalacja, aktualizacja systemów operacyjnych.
4.4. Definiowanie i sprawdzanie standardu serwera:
4.4.1. system musi posiadać komponenty umożliwiające zdefiniowanie i okresowe
sprawdzanie standardu serwera, standard ten musi być określony zestawem reguł
sprawdzających definiowanych z poziomu konsoli administracyjnej,
4.4.2. reguły powinny sprawdzać następujące elementy systemu komputerowego:
4.4.2.1. stan usługi,
4.4.2.2. obecność poprawek (Hotfix),
4.4.2.3. WMI,
31
4.4.2.4. rejestr systemowy,
4.4.2.5. system plików,
4.4.2.6. Active Directory,
4.4.2.7. SQL (query),
4.4.2.8. Metabase.
4.5. Raportowanie, prezentacja danych:
4.5.1. system musi posiadać komponent raportujący oparty o technologię webową
(wydzielony portal z raportami) i/lub,
4.5.2. wykorzystujący mechanizmy raportujące dostarczane wraz z silnikami
bazodanowymi,
4.5.3. system musi posiadać predefiniowane raport w następujących kategoriach:
4.5.3.1. sprzęt (inwentaryzacja),
4.5.3.2. oprogramowanie (inwentaryzacja),
4.5.3.3. oprogramowanie (wykorzystanie),
4.5.3.4. oprogramowanie (aktualizacje, w tym system operacyjny).
4.5.4. system musi umożliwiać budowanie stron z raportami w postaci tablic (dashboard),
na których może znajdować się więcej niż jeden raport,
4.5.5. System musi posiadać konsolę administratora, w postaci programu do zainstalowania
na stacjach roboczych, obsługującą wszystkie funkcje systemu.
4.6. Analiza działania systemu, logi, komponenty:
4.6.1. konsola systemu musi dawać dostęp do podstawowych logów obrazujących pracę
poszczególnych komponentów, wraz z oznaczaniem stanu (typu OK, Warning, Error)
w przypadku znalezienia zdarzeń wskazujących na problemy,
4.6.2. konsola systemu musi umożliwiać podgląd na stan poszczególnych usług wraz
z podstawowymi informacjami o stanie usługi, np. ilość wykorzystywanego miejsca
na dysku twardym.
5. System zarządzania komponentami musi udostępniać funkcje pozwalające na budowę bezpiecznych
i skalowalnych mechanizmów zarządzania komponentami IT spełniając następujące wymagania:
5.1. Architektura:
5.1.1.
serwery zarządzające muszą mieć możliwość publikowania informacji
o uruchomionych komponentach w usługach katalogowych, informacje te muszą być
dostępne dla klientów systemu w celu automatycznej konfiguracji,
5.1.2.
możliwość budowania struktury wielopoziomowej (tiers) w celu separacji pewnych
grup komputerów/usług,
5.1.3.
system uprawnień musi być oparty o role (role basedsecurity), użytkownicy i grupy
użytkowników w poszczególnych rolach muszą być pobierane z usług katalogowych,
5.1.4.
możliwość definiowania użytkowników do wykonywania poszczególnych zadań na
klientach i serwerze zarządzającym, w tym zdefiniowany użytkownik domyślny,
5.1.5.
uwierzytelnianie klientów na serwerze zarządzającym przy pomocy certyfikatów
w standardzie X.509, z możliwością odrzucania połączeń od klientów
niezaakceptowanych,
5.1.6.
kanał komunikacyjny pomiędzy klientami a serwerem zarządzającym musi być
szyfrowany,
5.1.7.
możliwość budowania systemu w oparciu o łącza publiczne - Internet (bez
konieczności wydzielania kanałów VPN),
5.1.8.
wsparcie dla protokołu IPv6,
32
5.1.9.
system musi udostępniać funkcje autodiagnostyczne, w tym: monitorowanie stanu
klientów, możliwość automatycznego lub administracyjnego restartu klienta,
możliwość reinstalacji klienta.
5.2. Audyt zdarzeń bezpieczeństwa:
5.2.1. system musi udostępniać komponenty i funkcje pozwalające na zbudowanie systemu
zbierającego zdarzenia związane z bezpieczeństwem monitorowanych systemów
i gwarantować:
5.2.1.1. przekazywanie zdarzeń z podległych klientów w czasie „prawie”
rzeczywistym (dopuszczalne opóźnienia mogą pochodzić z medium
transportowego – sieć, oraz komponentów zapisujących i odczytujących),
5.2.1.2. niskie obciążenie sieci poprzez schematyzację parametrów zdarzeń przed
wysłaniem, definicja schematu musi być definiowana w pliku XML
z możliwością dodawania i modyfikacji,
5.2.1.3. obsługę co najmniej 2500 zdarzeń/sek w trybie ciągłym i 100000
zdarzeń/sek w trybie „burst” – chwilowy wzrost ilości zdarzeń, jeden
kolektor zdarzeń musi obsługiwać, co najmniej 100 kontrolerów domen
(lub innych systemów autentykacji i usług katalogowych) lub 1000
serwerów.
6. Konfiguracja i monitorowanie:
6.1. System musi umożliwiać zbudowanie jednorodnego środowiska monitorującego, korzystając z
takich samych zasad do monitorowania różnych komponentów, a w tym:
6.1.1. monitorowane obiekty powinny być grupowane (klasy) w oparciu o atrybuty, które
można wykryć na klientach systemu w celu autokonfiguracji systemu. Muszą być
wykrywane - co najmniej, atrybuty pobierane z:
6.1.1.1. rejestru,
6.1.1.2. WMI,
6.1.1.3. OLEDB,
6.1.1.4. LDAP,
6.1.1.5. skrypty (uruchamiane w celu wykrycia atrybutów obiektu),
6.1.1.6. W definicjach klas powinny być również odzwierciedlone zależności
pomiędzy nimi.
6.2. Na podstawie wykrytych atrybutów system musi dokonywać autokonfiguracji klientów, przez
wysłanie odpowiadającego wykrytym obiektom zestawu monitorów, reguł, skryptów, zadań,
itp.
6.3. Wszystkie klasy obiektów, monitory, reguły, skrypty, zadania, itp. elementy służące konfiguracji
systemu muszą być grupowane i dostarczane w postaci zestawów monitorujących, system musi
posiadać w standardzie zestawy monitorujące, co najmniej dla:
6.3.1. Windows Server 2003/2008/2008R2/2012R2,
6.3.2. Active Directory 2008/2012R2
6.3.3. Exchange 2013,
6.3.4. Microsoft SharePoint 2013,
6.3.5. Microsoft SharePoint Services 3.0,
6.3.6. SQL 2005/2008/2008R2/2014,
6.3.7. Windows Client OS (XP,7, Windows 8.1, Windows 10) (32/64bit),
6.3.8. Information Worker (Office, IExplorer, Outlook, itp.),
6.3.9. IIS 6.0/7.0/7.5,
33
6.4. Novell SUSE Linux Enterprise Server 9/10SP1/11System musi posiadać możliwość
monitorowania za pomocą agenta lub bez niego.
6.5. System musi pozwalać na wykrycie oraz monitorowanie posiadanych przez Zamawiającego
urządzeń sieciowych (routery, przełączniki sieciowe, itp.) za pomocą SNMP v1, v2c oraz v3.
System monitorowania w szczególności musi mieć możliwość zbierania następujących
informacji:
6.5.1. interfejsy sieciowe,
6.5.2. porty,
6.5.3. sieci wirtualne (VLAN),
6.5.4. grupy Hot Standby Router Protocol (HSRP).
6.6. System zarządzania musi mieć możliwość czerpania informacji z następujących źródeł danych
posiadanych przez Zamawiajacego:
6.6.1. SNMP (trap, probe),
6.6.2. WMI Performance Counters,
6.6.3. Log Files (text, text CSV),
6.6.4. Windows Events (logi systemowe),
6.6.5. Windows Services,
6.6.6. Windows Performance Counters (perflib),
6.6.7. WMI Events,
6.6.8. Scripts (wyniki skryptów, np.: WSH, JSH),
6.6.10. Unix/Linux Log.
6.7. Na podstawie uzyskanych informacji monitor musi aktualizować status komponentu, musi być
możliwość łączenia i agregowania statusu wielu monitorów.
7. Tworzenie reguł:
7.1. W systemie zarządzania musi być możliwość czerpania informacji z następujących źródeł
danych:
7.1.1. Event based (text, text CSV, NT Event Log, SNMP Event, SNMP Trap, syslog, WMI
Event),
7.1.2. Performance based (SNMP performance, WMI performance, Windows performance),
7.1.3. Probe based (scripts: event, performance).
7.2. System musi umożliwiać przekazywanie zebranych przez reguły informacji do bazy danych
w celu ich późniejszego wykorzystania w systemie, np. raporty dotyczące wydajności
komponentów, alarmy mówiące o przekroczeniu wartości progowych czy wystąpieniu
niepożądanego zdarzenia.
7.3. Reguły zbierające dane wydajnościowe muszą mieć możliwość ustawiania tolerancji na zmiany,
w celu ograniczenia ilości nieistotnych danych przechowywanych w systemie bazodanowym.
Tolerancja musi mieć, co najmniej dwie możliwości:
7.3.1. na ilość takich samych próbek o takiej samej wartości,
7.3.2. na procentową zmianę od ostatniej wartości próbki.
7.4. Monitory sprawdzające dane wydajnościowe w celu wyszukiwania wartości progowych muszą
mieć możliwość – oprócz ustawiania progów statycznych, „uczenia” się monitorowanego
parametru w zakresie przebiegu bazowego „baseline” w zadanym okresie czasu.
7.5. System musi umożliwiać blokowanie modyfikacji zestawów monitorujących, oraz definiowanie
wyjątków na grupy komponentów lub konkretne komponenty w celu ich odmiennej
konfiguracji.
34
7.6. System musi posiadać narzędzia do konfiguracji monitorów dla aplikacji i usług
wykorzystywanych przez Zamawiającego, w tym:
7.6.1. ASP .Net Application,
7.6.2. ASP .Net Web Service,
7.6.3. OLE DB,
7.6.4. TCP Port,
7.6.5. Web Application,
7.6.6. Windows Service,
7.6.8. Process Monitoring,
7.6.9. Narzędzia te powinny pozwalać na zbudowanie zestawu predefiniowanych monitorów
dla wybranej aplikacji i przyporządkowanie ich do wykrytej/działającej aplikacji.
7.7. System musi posiadać narzędzia do budowania modeli aplikacji rozproszonych (składających
się z wielu wykrytych obiektów), pozwalając na agregację stanu aplikacji oraz zagnieżdżanie
aplikacji.
7.8. Z każdym elementem monitorującym (monitor, reguła, alarm, itp.) musi być skojarzona baza
wiedzy, zawierająca informacje o potencjalnych przyczynach problemów oraz możliwościach
ich rozwiązania (w tym możliwość uruchamiania zadań diagnostycznych z poziomu
administratora).
7.9. System musi zbierać informacje udostępniane przez systemy operacyjne Windows
o przyczynach krytycznych błędów (crash) udostępnianych potem do celów analitycznych.
7.10. System musi umożliwiać budowanie obiektów SLO (Service Level Object) służących
przedstawianiu informacji dotyczących zdefiniowanych poziomów SLA (Service Level
Agreement) przynajmniej dla: monitora (dostępność), i licznika wydajności (z agregacją dla
wartości – min, max, avg).
8. Przechowywanie i dostęp do informacji:
8.1. Wszystkie informacje operacyjne (zdarzenia, liczniki wydajności, informacje o obiektach,
alarmy, itp.) powinny być przechowywane w bazie danych operacyjnych.
8.2. System musi mieć co najmniej jedną bazę danych z przeznaczeniem na hurtownię danych do
celów historycznych i raportowych. Zdarzenia powinny być umieszczane w obu bazach
jednocześnie, aby raporty mogłyby być generowane w oparciu o najświeższe dane.
8.3. System musi mieć osobną bazę danych, do której będą zbierane informacje na temat zdarzeń
security z możliwością ustawienia innych uprawnień dostępu do danych tam zawartych (tylko
audytorzy).
8.4. System musi mieć zintegrowany silnik raportujący niewymagający do tworzenia raportów
używania produktów firm trzecich. Produkty takie mogą być wykorzystanie w celu rozszerzenia
tej funkcjonalności.
8.5. System musi mieć możliwość generowania raportów na życzenie oraz tworzenie zadań
zaplanowanych.
8.6. System musi umożliwiać eksport stworzonych raportów przynajmniej do następujących
formatów:
8.6.1. XML,
8.6.2. CSV,
8.6.3. TIFF,
8.6.4. PDF,
8.6.5. XLS,
8.6.6. Web archive.
35
9. Konsola systemu zarządzania:
9.1. Konsola systemu musi umożliwiać pełny zdalny dostęp do serwerów zarządzających dając
dostęp do zasobów zgodnych z rolą użytkownika korzystającego z konsoli.
9.2. System musi udostępniać dwa rodzaje konsoli:
9.2.1. w postaci programu do zainstalowania na stacjach roboczych, obsługującą wszystkie
funkcje systemu (konsola zdalna),
9.2.2. w postaci web’owej dla dostępu do podstawowych komponentów monitorujących
z dowolnej stacji roboczej (konsola webowa).
9.3. Konsola zdalna musi umożliwiać definiowanie każdemu użytkownikowi własnych widoków,
co najmniej w kategoriach typu:
9.3.1. Alerts – alarmy,
9.3.2. Events – zdarzenia,
9.3.3. State – stany,
9.3.4. Performance – wydajność,
9.3.5. Diagram – diagramy,
9.3.6. Task Status – status zadań,
9.3.7. Web Page (dla użytkowników, którzy potrzebują podglądu tylko wybranych
elementów systemu).
9.4. Konsola musi umożliwiać budowanie widoków tablicowych (dashboard) w celu prezentacji
różnych widoków na tym samym ekranie.
9.5. Widoki powinny mieć możliwość filtrowania informacji, jakie się na nich znajdą (po typie,
ważności, typach obiektów, itp.), sortowania oraz grupowania podobnych informacji, wraz
z możliwością definiowania kolumn, jakie mają się znaleźć na widokach „kolumnowych”.
9.6. Z każdym widokiem (obiektem w tym widoku) musi być skojarzone menu kontekstowe,
z najczęstszymi operacjami dla danego typu widoku/obiektu.
9.7. Konsola musi zapewnić dostęp do wszystkich opcji konfiguracyjnych systemu (poza opcjami
dostępnymi w procesie instalacji i wstępnej konfiguracji), w tym:
9.7.1. Opcji definiowania ról użytkowników,
9.7.2. Opcji definiowania widoków,
9.7.3. opcji definiowania i generowania raportów,
9.7.4. opcji definiowania powiadomień,
9.7.5. opcji tworzenia, konfiguracji i modyfikacji zestawów monitorujących,
9.7.6. opcji instalacji/deinstalacji klienta,
9.8. Konsola musi pozwalać na pokazywanie obiektów SLO (Service Level Object) i raportów SLA
(Service Level Agreement) bez potrzeby posiadania konsoli i dostępu do samego systemu
monitorującego, na potrzeby użytkowników biznesowych (właścicieli procesu biznesowego).
10.1. System musi dostarczać API lub inny system (web service, connector) z publicznie dostępną
dokumentacją pozwalający m.in. na:
10.1.1. Budowanie konektorów do innych systemów, np. help-desk w celu przekazywania
zdarzeń czy alarmów (dwukierunkowo),
10.1.2. Wykonywanie operacji w systemie z poziomu linii poleceń,
10.1.3. Podłączenie rozwiązań firm trzecich pozwalających na monitorowanie w jednolity
sposób systemów informatycznych niewspieranych natywnie przez system
zarządzania,
36
10.1.4. Podłączenie do aplikacji biurowych pozwalające na integrację statycznych modeli (np.
diagramów Visio) z monitorowanymi obiektami, pozwalające na wyświetlanie ich
stanu na diagramie.
11. System zarządzania środowiskami wirtualnym musi posiadać następujące cechy:
11.1. Architektura
11.1.1. System zarządzania środowiskiem wirtualnym musi składać się z:
11.1.1.1. serwera zarządzającego,
11.1.1.2. relacyjnej bazy danych przechowującej informacje o zarządzanych
elementach,
11.1.1.3. konsoli, instalowanej na komputerach operatorów,
11.1.1.4. portalu self-service (konsoli webowej) dla operatorów „departamentowych”,
11.1.1.5. biblioteki, przechowującej komponenty niezbędne do budowy maszyn
wirtualnych,
11.1.1.6. agenta instalowanego na zarządzanych hostach wirtualizacyjnych,
11.1.1.7. „konektora” do systemu monitorującego pracę hostów i maszyn wirtualnych.
11.1.2. System musi mieć możliwość tworzenia konfiguracji wysokiej dostępności (klaster typu
fail-over).
11.1.3. System musi pozwalać na zarządzanie platformami wirtualizacyjnymi co najmniej
trzech różnych producentów.
11.2. Interfejs użytkownika:
11.2.1. Konsola musi umożliwiać wykonywanie codziennych zadań związanych
z zarządzaniem maszynami wirtualnymi w sposób jak najbardziej intuicyjny.
11.2.2. Konsola musi umożliwiać grupowanie hostów i nadawanie uprawnień poszczególnym
operatorom do grup hostów.
11.2.3. Widoki hostów i maszyn wirtualnych powinny mieć możliwość zakładania filtrów,
pokazując tylko odfiltrowane elementy, np. maszyny wyłączone, maszyny z systemem
operacyjnym X, itp.
11.2.4. Widok szczegółowy elementu w przypadku maszyny wirtualnej musi pokazywać stan,
ilość alokowanej pamięci i dysku twardego, system operacyjny, platformę
wirtualizacyjną, stan ostatniego zadania, oraz wykres utylizacji procesora i podgląd na
pulpit.
11.2.5. Konsola musi posiadać odrębny widok z historią wszystkich zadań oraz statusem
zakończenia poszczególnych etapów i całych zadań.
11.3. Scenariusze i zadania
11.3.1. Tworzenie maszyn wirtualnych – system musi umożliwiać stworzenie maszyny
wirtualnej w co najmniej dwóch trybach:
11.3.1.1. ad hoc – gdzie wszystkie elementy są wybierane przez operatora podczas
tworzenia maszyny,
11.3.1.2. nadzorowany – gdzie operator tworzy maszynę korzystając z gotowego
wzorca (template), a wzorzec składa się z przynajmniej 3-ech elementów
składowych:
11.3.1.2.1. profilu sprzętowego
11.3.1.2.2. profilu systemu operacyjnego,
11.3.1.2.3. przygotowanych dysków twardych,
11.3.1.3. Predefiniowane elementy muszą być przechowywane w bibliotece systemu
zarządzania.
37
11.3.1.4.
System musi umożliwiać przenoszenie maszyny wirtualnej pomiędzy
zarządzanymi hostami:
11.3.1.4.1. w trybie migracji „on-line” – bez przerywania pracy,
11.3.1.4.2. w trybie migracji „off-line – z zapisem stanu maszyny.
11.3.2. system musi umożliwiać automatyczne, równomierne rozłożenie obciążenia pomiędzy
zarządzanymi hostami,
11.3.3. system musi umożliwiać wyłączenie hosta, gdy jego zasoby nie są konieczne do pracy,
w celu oszczędności energii. System musi również umożliwiać ponowne włączenie
takiego hosta,
11.3.4. system musi umożliwiać przełączenie wybranego hosta w tryb „maintenance”
w przypadku wystąpienia awarii lub w celu przeprowadzenia planowanych prac
serwisowych. Uruchomienie tego trybu musi skutkować migracją maszyn na inne hosty
lub zapisaniem ich stanu,
11.3.5. system musi posiadać możliwość konwersji maszyny fizycznej do wirtualnej,
11.3.6. system musi posiadać (bez potrzeby instalowania dodatkowego oprogramowania) możliwość wykrycia maszyny fizycznej w sieci i instalacje na niej systemu operacyjnego
wraz z platformą do wirtualizacji.
12.1. System musi informować operatora o potrzebie migracji maszyn, jeśli wystąpią
nieprawidłowe zdarzenia na hoście lub w innych maszynach wirtualnych mające wpływ na
ich pracę, np. awarie sprzętu, nadmierna utylizacja współdzielonych zasobów przez jedną
maszynę,
12.2. System musi dawać operatorowi możliwość implementacji w/w migracji w sposób
automatyczne bez potrzeby każdorazowego potwierdzania,
12.3. System musi kreować raporty z działania zarządzanego środowiska, w tym:
12.3.1.
utylizacja poszczególnych hostów,
12.3.2.
trend w utylizacji hostów,
12.3.3.
alokacja zasobów na centra kosztów,
12.3.4.
utylizacja poszczególnych maszyn wirtualnych,
12.3.5.
komputery-kandydaci do wirtualizacji.
12.4. System musi umożliwiać skorzystanie z szablonów:
12.4.1.
wirtualnych maszyn,
12.4.2.
usług,
12.4.3.
oraz profili dla:
12.4.3.1. aplikacji,
12.4.3.2. serwera SQL,
12.4.3.3. hosta,
12.4.3.4. sprzętu,
12.4.3.5. systemu operacyjnego gościa.
12.5. System musi umożliwiać tworzenie chmur prywatnych na podstawie dostępnych zasobów
(hosty, sieci, przestrzeń dyskowa, biblioteki zasobów).
12.6. System musi posiadać możliwość przygotowania i instalacji zwirtualizowanej aplikacji
serwerowej.
12.7. System musi pozwalać na skalowalność wirtualnego środowiska aplikacji (poprzez
automatyczne dodanie wirtualnej maszyny z aplikacją).
13. System tworzenia i odtwarzania kopii zapasowych danych (backup) wykorzystujący scenariusze
tworzenia kopii na zasobach taśmowych lub dyskowych musi spełniać następujące wymagania:
38
13.1. System musi składać się z:
13.1.1. serwera zarządzającego kopiami zapasowymi i agentami kopii zapasowych,
13.1.2. agentów kopii zapasowych instalowanych na komputerach zdalnych,
13.1.3. konsoli zarządzającej,
13.1.4. relacyjnej bazy danych przechowującej informacje o zarządzanych elementach,
13.1.5. wbudowany mechanizm raportowania i notyfikacji poprzez pocztę elektroniczną,
13.1.6. System kopii zapasowych musi wykorzystywać mechanizm migawkowych kopii.
13.2. System kopii zapasowych musi umożliwiać:
13.2.1. zapis danych na puli magazynowej złożonej z dysków twardych,
13.2.2. zapis danych na bibliotekach taśmowych,
13.2.3. System kopii zapasowych musi umożliwiać zdefiniowanie ochrony zasobów
krótkookresowej i długookresowej. Oznacza to, iż krótkookresowe kopie mogą
być tworzone w puli magazynowej, a następnie po zdefiniowanym okresie,
automatycznie przenoszone na biblioteki taśmowe,
13.2.4. System kopii zapasowych musi posiadać kopie danych produkcyjnych w swojej
puli magazynowej,
13.2.5. Dane przechowywane w puli magazynowej muszą używać mechanizmów
oszczędzających wykorzystane miejsce dyskowe, takie jak pojedyncza instancja
przechowywania,
13.2.6. System kopii zapasowych musi w przypadku wykonywania pełnej kopii zapasowej
kopiować jedynie te bloki, które uległy zmianie od ostatniej pełnej kopii,
13.2.7. System kopii zapasowych musi umożliwiać przywrócenie:
13.2.7.1. danych plikowych,
13.2.7.2. danych aplikacyjnych,
13.2.7.3. stanu systemu (System state),
13.2.7.4. obrazu systemu operacyjnego (tzw. Bare Metal Restore).
13.3. System kopii zapasowej podczas wykonywania pełnej kopii zapasowej musi uaktualniać
chronione dane o dodatkowy punkt przywracania danych, minimalizując ilość przesyłanych
danych,
13.4. System kopii zapasowych musi umożliwiać rozwiązanie automatycznego przenoszenia
chronionych danych do zdalnej lokalizacji, wykorzystując przy tym mechanizm regulacji
maksymalnej przepustowości,
13.5. Agenci systemu kopii zapasowych muszą posiadać konfiguracje dotyczącą zdefiniowania
godzin pracy, a także dostępnej przepustowości w czasie godzin pracy i poza godzinami pracy,
13.6. System kopii zapasowych musi rozpoznawać aplikacje wykorzystywane przez
Zamawiającego:
13.6.1. ze względu na tworzone logi transakcyjne:
13.6.1.1. serwer pocztowy,
13.6.1.2. portal wielofunkcyjny,
13.6.1.3. serwer bazy danych,
13.6.2. ze względu na zapewnienie nieprzerwalności pracy:
13.6.2.1. środowisko wirtualne.
13.7. Komunikacja z serwerem kopii zapasowych musi odbywać się po jawnie zdefiniowanych
portach,
13.8. Konsola musi umożliwiać wykonywanie i tworzenie określonych harmonogramów
wykonywania kopii zapasowych na chronionych agentach,
39
13.9. Konsola musi umożliwiać grupowanie chronionych zasobów ze względu na typy chronionych
zasobów,
13.10. Zarządzanie agentami i zadaniami kopii zapasowych musi być możliwe również za pomocą
linii poleceń,
13.11. System kopii zapasowych musi umożliwiać odzyskanie chronionych zasobów plikowych przez
użytkownika końcowego z poziomu zakładki „Poprzednie wersje”,
13.12. Konsola musi posiadać mechanizm kontrolowania wykonywanych zadań kopii zapasowych,
13.13. Konsola musi posiadać mechanizm notyfikacji administratorów odnośnie zdarzeń
w systemie kopii zapasowych,
13.14. Konsola musi posiadać wbudowany system raportujący (m.in. raporty dotyczące zużycia puli
magazynowej, wykonania kopii zapasowych, itp.),
13.15. System kopii zapasowych musi umożliwiać przechowywanie danych w puli magazynowej do
1 roku,
13.16. System kopii zapasowych musi umożliwiać przechowywanie danych na podłączonych
bibliotekach taśmowych powyżej 25 lat,
13.17. System kopii zapasowych musi umożliwiać synchronizację przechowywanych kopii
zapasowych (kopie inkrementalne) z produkcyjnymi transakcyjnymi bazami danych (bazy
danych, poczta elektroniczna, portale intranetowe) na poziomie poniżej 30 minut. Kopie te
muszą być tworzone w ciągu godzin pracy, w niezauważalny dla użytkowników końcowych
sposób,
13.18. System kopii zapasowych musi umożliwiać odtworzenie dowolnego 30 minutowego kwantu
czasu dla krytycznych aplikacji, takich jak bazy transakcyjne, poczta elektroniczna, portale
intranetowe,
13.19. System kopii zapasowych musi umożliwiać odtworzenie danych do:
13.19.1. lokalizacji oryginalnej,
13.19.2. lokalizacji alternatywnej,
13.19.3. w przypadku drugiego serwera kopii zapasowych (w centrum zapasowym) do
pierwszego serwera kopii zapasowych.
14. System automatyzacji zarządzania środowisk IT musi udostępniać bezskryptowe środowisko
standaryzujące i automatyzujące zarządzanie środowiskiem IT:
14.1. System musi umożliwiać testowanie sytuacji krytycznych i występowanie różnych
incydentów w systemie,
14.2. System musi wspomagać automatyzację procesów zarządzania zmianami konfiguracji
środowisk IT,
14.3. System musi wspomagać planowanie i automatyzację wdrażania poprawek,
14.4. System musi umożliwiać zarządzanie życiem środowisk wirtualnych,
14.5. System musi udostępniać mechanizmy workflow automatyzujące zadania administracyjne
wraz z graficznym interfejsem projektowania, budowy i monitorowania workflow,
15. System zarządzania incydentami i problemami musi spełniać następujące wymagania:
15.1. System musi posiadać rozwiązanie help-deskowe umożliwiające użytkownikom zgłaszanie
problemów technicznych oraz zapotrzebowanie na zasoby IT (np. nowa maszyna wirtualna),
15.2. System musi mieć postać zintegrowanej platformy pozwalającej poprzez wbudowane
i definiowane mechanizmy w ramach przyjętej metodyki na zarządzanie incydentami i
problemami oraz zarządzanie zmianą,
15.3. System musi posiadać bazę wiedzy (CMDB) automatycznie zasilaną z takich systemów jak:
usługa katalogowa, system monitorujący, system do zarządzania desktopami,
40
15.4. System musi udostępniać narzędzia efektywnego zarządzania dostępnością usług,
umożliwiające dostarczenie użytkownikom systemów SLA na wymaganym poziomie,
15.5. System, poprzez integrację z systemami zarządzania i monitorowania musi zapewniać:
15.5.1. optymalizację procesów i ich prawidłową realizację poprzez predefiniowane
scenariusze, zgodne z najlepszymi praktykami i założoną metodyką,
15.5.2. redukcję czasu rozwiązywania problemów z działaniem systemów poprzez
zapewnienie dotarcia właściwej, zagregowanej informacji do odpowiedniego
poziomu linii wsparcia,
15.5.3. automatyczne generowanie opisu problemów na bazie alarmów i kojarzenie
zdarzeń w różnych komponentach systemu,
15.5.4. wspomaganie procesów podejmowania decyzji poprzez integrację informacji
i logikę ich powiązania,
15.5.5. planowanie działań prewencyjnych poprzez kolekcjonowanie informacji
o zachowaniach systemu w przypadku incydentów,
15.5.6. raportowanie pozwalające na analizy w zakresie usprawnień systemu oraz
usprawnień procesów ich opieki serwisowej,
15.5.7. tworzenie baz wiedzy na temat rozwiązywania problemów,
15.5.8. automatyzację działań w przypadku znanych i opisanych problemów,
15.5.9. wykrywanie odchyleń od założonych standardów ustalonych dla systemu.
16. Ochrona antymalware musi spełniać następujące wymagania:
16.1. Ochrona przed zagrożeniami typu wirusy, robaki, trojany, rootkity, ataki typuphishing czy
exploity zero-day,
16.2. Centralne zarządzanie ochroną serwerów poprzez konsolę System zarządzania infrastrukturą
i oprogramowaniem,
16.3. Centralne zarządzanie politykami ochrony,
16.4. Automatyzacja wdrożenia i wymiany dotychczasowych agentów ochrony,
16.5. Mechanizmy wspomagające masową instalację,
16.6. System ma wykrywać wirusy, oprogramowanie szpiegowskie i inne pliki przed ich
uruchomieniem, dając dzięki temu wydajną ochronę przed wieloma zagrożeniami, a
jednocześnie minimalizując zaangażowanie użytkownika końcowego,
16.7. Aparat ochrony przed złośliwym oprogramowaniem ma używać zaawansowanych
technologii wykrywania, takich jak analiza statyczna, emulacja, heurystyka i tunelowanie
w celu identyfikacji złośliwego oprogramowania i ochrony systemu. Ponieważ zagrożenia
stają się coraz bardziej złożone, ważne jest, aby zapewnić nie tylko oczyszczenie systemu, ale
również poprawne jego funkcjonowanie po usunięciu złośliwego oprogramowania. Aparat
ochrony przed złośliwym oprogramowaniem w systemie ma zawierać zaawansowane
technologie oczyszczania, pomagające przywrócić poprawny stan systemu po usunięciu
złośliwego oprogramowania,
16.8. Generowanie alertów dla ważnych zdarzeń, takich jak atak złośliwego oprogramowania czy
niepowodzenie próby usunięcia zagrożenia,
16.9. Tworzenie szczegółowych raportów zabezpieczeń systemów IT o określonych priorytetach,
dzięki którym użytkownik może wykrywać i kontrolować zagrożenia lub słabe punkty
zabezpieczeń. Raporty mają obejmować nie tylko takie informacje, jak ilość ataków wirusów,
ale wszystkie aspekty infrastruktury IT, które mogą wpłynąć na bezpieczeństwo firmy (np.
ilość komputerów z wygasającymi hasłami, ilość maszyn, na których jest zainstalowane konto
„gościa”, itd.),
41
16.10. Pakiet ma umożliwiać zdefiniowanie jednej zasady konfigurującej technologie
antyszpiegowskie, antywirusowe i technologie monitorowania stanu jednego lub wielu
chronionych komputerów. Zasady obejmują również ustawienia poziomów alertów, które
można konfigurować, aby określić rodzaje alertów i zdarzeń generowanych przez różne grupy
chronionych komputerów oraz warunki ich zgłaszania,
16.11. System ochrony musi być zoptymalizowany pod kątem konfiguracji ustawień agenta
zabezpieczeń przy użyciu Zasad Grupy usługi katalogowej oraz dystrybucji aktualizacji
definicji.
4.5.
Oprogramowanie serwerowe platformy usług integracyjnych
1. System aplikacyjnej szyny usług umożliwiający:
1.1. Przetwarzanie wiadomości z wielu źródeł danych,
1.2. Kierowanie wiadomości do odpowiednich odbiorców na podstawie treści oraz zdefiniowanych
reguł,
1.3. Konwersję protokołów przetwarzanych danych,
1.4. Transformację treści (wiadomości) do różnych formatów,
1.5. Obsługę błędów,
1.6. Interakcje wielu usług,
1.7. Kierowanie odpowiedzi od adapterów końcowych zgodnie z ustalonymi regułami,
1.8. Zapewnienie pewności dostarczenia wiadomości,
1.9. Obsługę komunikatów trwałych (zapisywanych w bazie danych),
2. Silnik procesów biznesowych powinien zapewniać poniższe funkcjonalności:
2.1. 2.1 Wykonywanie procesów natychmiastowych i odroczonych,
2.2. obsługę pojawiających się w czasie wykonania wyjątków,
2.3. utrzymywanie różnych wersji procesu biznesowego,
2.4. implementację nowych wersji procesów biznesowych bez przerywania wykonywanych
procesów,
2.5. kompensację procesów długotrwałych i pełną transakcyjność procesów krótkotrwałych,
2.6. routing komunikatów, oparty na treści dokumentów XML i regułach biznesowych,
2.7. filtrowanie komunikatów na podstawie zawartości, przy wykorzystaniu parametrów
definiowanych przez użytkownika,
2.8. szyfrowanie i podpisywanie komunikatów XML.
3. Wbudowane wsparcie dla następujących wzorców projektowych:
3.1. Wzorce kierowania wiadomości
3.1.1. Na podstawie treści,
3.1.2. Dynamiczne,
3.1.3. Do listy odbiorców,
3.1.4. Filtrowanie wiadomości,
3.1.5. Agregacja / podział,
3.1.6. Scatter / Gather.
3.2. Typy przetwarzania:
3.2.1. Sekwencyjne,
3.2.2. Równoległe,
3.2.3. W pętli.
3.3. Wzorce wymiany wiadomości:
3.3.1. Request / response,
3.3.2. One-way,
42
3.3.3. Publish / subscribe,
3.3.4. Request / callback.
3.4. Typy usług
3.4.1. RPC Services,
3.4.2. Document Services,
3.4.3. Event Services.
4. Wbudowane narzędzia dla projektantów umożliwiające:
4.1. Graficzne budowanie procesu z predefiniowanych komponentów,
4.2. Tworzenie komponentów przy pomocy języków programowania w przypadku kiedy jest to
niezbędne.
4.3. Graficzne definiowanie schematów przetwarzanych danych
4.3.1. Elementy,
4.3.2. Atrybuty,
4.3.3. Porządek,
4.3.4. Obowiązkowość pól,
4.3.5. Powtarzalność i krotność pól,
4.3.6. Definiowanie i wykorzystanie typów danych.
4.4. Graficzne definiowanie transformacji danych pomiędzy schematami.
4.4.1. Proste mapowanie pól,
4.4.2. Mapowanie pól z konwersją typu danych,
4.4.3. Mapowanie z przekształceniem (wyliczenie wartości docelowej na podstawie wielu
wartości źródłowych),
4.4.4. Obsługa rekordów powtarzalnych (kompozycja i dekompozycja),
5. Edytor przetwarzania wiadomości
5.1. Kodowanie i dekodowanie,
5.2. Szyfrowanie i deszyfrowanie,
5.3. Walidacja ze schematem,
5.4. Weryfikacja podpisu elektronicznego.
6. Edycję reguł.
7. Tworzenie modeli procesu i ich zapisywanie.
8. Testowanie stworzonych rozwiązań przy pomocy graficznego debuggera.
5. Obsługa komunikatów w formacie JSON, XML, plików płaskich, plików binarnych.
6. Obsługa komunikacji zgodnie z następującymi protokołami wykorzystywanymi przez
Zamawiającego:
6.1.
Pliki płaskie,
6.2.
FTP,
6.3.
http,
6.4.
HTTPS,
6.5.
SFTP (z obsługą PROXY),
6.6.
REST,
6.7.
SOAP,
6.8.
MQSeries,
6.9.
MTOM,
6.10. POP3,
6.11. SMTP,
6.12. JMS,
6.13. SB-Messaging (Windows Azure Service Bus Brokered Messaging),
6.14. WCF-BasicHttpRelay (Windows Azure Service Bus Relay),
6.15. WCF-BasicHttpRelay (Windows Azure Service Bus Relay),
6.16. WCF-WebHttp (REST),
6.17. WCF-WSHttp,
43
6.18. WCF-BasicHttp,
6.19. WCF-NetTcp,
6.20. WCF-NetMsmq,
6.21. WCF-NetNamedPipe,
6.22. WCF-Custom,
6.23. WCF-CustomIsolated.
7. Komunikacja z wykorzystaniem standardów:
7.1. WS-Addressing,
7.2. WS-Security,
7.3. WS-AtomicTransaction.
8. Interfejsy do baz danych posiadanych przez Zamawiającego:
8.1. SQL Server,
8.2. SQL Azure,
9. Możliwość komunikacji z systemami klasy Enterprise posiadanymi przez Zamawiającego:
9.1. SAP
10. Wbudowany adapter do portalu SharePoint Server.
11. Możliwość pracy w środowisku Hyper-V.
12. Wsparcie dla pracy zespołu programistów (automatyczny build, sourcecontrol, zadania, itp.)
13. Zintegrowane SDK umożliwiające tworzenie przy pomocy języka programowania:
13.1. Adapterów dla obsługi niestandardowych źródeł danych (wysyłanie i odbieranie danych),
13.2. Niestandardowych komponentów przetwarzania wiadomości,
13.3. Niestandardowych komponentów reguł biznesowych,
13.4. Niestandardowych komponentów akcji procesu.
14. System musi umożliwiać skalowanie, rekonfigurację, osadzanie nowych usług bez zakłócania pracy
innych aplikacji czy realizowanych operacji biznesowych.
15. System musi zapewniać funkcjonalność silnika reguł biznesowych, pozwalającą na modyfikowanie
parametrów sterujących procesem biznesowym bez konieczności przebudowywania całego
rozwiązania. Dodatkowo silnik ten powinien mieć interfejs umożliwiający modyfikowanie takich
reguł za pomocą oddzielnie tworzonych aplikacji.
16. System musi zapewniać możliwość monitorowania pracy systemu i administrowania zasobami
systemu z jednego, centralnego miejsca.
17. Monitorowanie zdarzeń
17.1. Obsługa wyjątków,
17.2. Analiza zdarzeń,
17.3. Obsługa powiadomień o zdarzeniach.
18. Wbudowane wsparcie dla monitorowania procesów (Business Activity Monitoring) umożliwiające
gromadzenie, agregowanie i prezentację danych (w tym wskaźników jakości procesu).
19. Wbudowane dashboardy prezentujące zdefiniowane wskaźniki dla procesów
20. System musi zapewniać wsparcie dla platform 64 bitowych.
21. System musi umożliwiać odtworzenie stanu po awarii.
22. Zapewnienie funkcjonalności SSO (Single Sign-On) w obrębie proponowanego systemu jest
obligatoryjne. Zachowanie i przeniesienie kontekstu użytkownika (SSO) na inny zintegrowany z
rozwiązaniem system musi być technicznie możliwe.
23. System musi umożliwiać zarządzanie konfiguracją oraz zmianami wersji systemu.
5 Wymagania kompatybilności
44
1. W przypadku zaoferowania przez Wykonawcę co najmniej jednego oprogramowania innego niż
posiadane przez Zamawiającego oprogramowanie wymienione w pkt. 6, ppkt. 1.1-1.4.
(„Charakterystyka środowiska Zamawiającego”), Wykonawca:
1.1. Dokona, w terminie realizacji dostawy, instalacji i testowania każdego produktu
(oprogramowania) w środowisku sprzętowo-programowym Zamawiającego przy udziale
Zamawiającego,
1.2. Dokona transferu wiedzy w zakresie utrzymania i rozwoju rozwiązania opartego o
zaproponowane produkty w postaci:
1.2.1.Szkolenia autoryzowanego przez producenta oprogramowania w ośrodku szkoleniowym
poza siedzibą Zamawiającego dla 5 osób dla każdego oferowanego produktu
1.2.2.Dostarczenie autoryzowanych przez producenta oprogramowania materiałów
szkoleniowych.
2. W przypadku, gdy zaoferowane przez Wykonawcę produkty nie będą właściwie działać ze sprzętem
i oprogramowaniem funkcjonującym u Zamawiającego lub spowodują zakłócenia w
funkcjonowaniu pracy środowiska sprzętowo-programowego Zamawiającego, Wykonawca pokryje
wszystkie koszty związane z przywróceniem i sprawnym działaniem infrastruktury sprzętowoprogramowej oraz na własny koszt dokona niezbędnych modyfikacji przywracających właściwe
działanie środowiska sprzętowo-programowego Zamawiającego również po usunięciu
zaoferowanego produktu.
3. Zaoferowane oprogramowanie nie może powodować utraty kompatybilności oraz wsparcia
producentów innego używanego i współpracującego z nim oprogramowania.
6 Charakterystyka środowiska Zamawiającego
1. W skład produkcyjnego środowiska Zamawiającego wchodzi następujące oprogramowanie
systemowe:
1.1. Oprogramowanie serwerowe portalu wielofunkcyjnego:
a) SharePoint Server 2013 zainstalowany na systemie operacyjnym Windows Server
2012R2 Standard z dostępem do bazy danych SQL Server 2014 Enterprise (Hyper-V)
1.2. Oprogramowanie serwerowe relacyjnej bazy danych:
a) SQL Server 2014 Enterprise zainstalowany na systemie operacyjnym Windows
Server 2012R2 Standard (Hyper-V)
1.3. Serwerowy system operacyjny z elementami zarządzania typ I:
a) Windows Server 2012R2 Standard
1.4. Serwerowy system operacyjny z elementami zarządzania typ II.
a) Windows Server 2012R2 Datacenter
1.5. Używana technologia oprogramowania.
a)
Microsoft Internet Service 8.5
b)
C# (Visual Studio 2012)
45
c)
Microsoft MVC 5.0
d)
Java Script
e)
Platforma .Net Framework 4.0
f)
Microsoft SQL Server 2014
g)
Microsoft SQL Server Reporting Services / Report Builder
h)
Virtual Machine Manager
46

Opis przedmiotu zamówienia

Transkrypt

Podobne dokumenty

Dostawa i wdrożenie oprogramowania do robienia kopii

pobierz

Zarządzenie Nr 42 /2015 Starosty Kraśnickiego z dnia 17 listopada

Specyfikacja strony internetowej

Załacznik nr 2 do SIWZ

kopia zapasowa - instrukcja wykonywania

I. ZAŁOŻENIA PROJEKTOWE System musi być

Reprodukcje

załącznik nr 1 - założenia funkcjonalne systemu