Postępowanie prowadzone w trybie przetargu nieograniczonego pn

Transkrypt

Postępowanie prowadzone w trybie przetargu nieograniczonego pn. Usługa zintegrowanego
środowiska teleinformatycznego dla nowych rozwiązań biznesowych
Załącznik E
Opis Wymagań Równoważnych dla Zadania 2
Jeżeli Zamawiający określił w SIWZ wymagania z użyciem nazw własnych produktów lub
marek producentów, w szczególności w obszarze specyfikacji przedmiotu zamówienia, to
należy traktować wskazane produkty jako rozwiązania wzorcowe. W każdym takim
przypadku Zamawiający oczekuje dostarczenia produktów wzorcowych lub równoważnych,
spełniających poniższe warunki równoważności.
1. W przypadku dostarczania oprogramowania, równoważnego względem wyspecyfikowanego
przez Zamawiającego w SIWZ, Wykonawca musi na swoją odpowiedzialność i swój koszt
udowodnić, że dostarczane oprogramowanie
spełnia wszystkie wymagania i warunki
określone SIWZ, w szczególności w zakresie:
1) warunków
licencji
/
sublicencji
w
każdym
aspekcie
licencjonowania
/
sublicencjonowania, które nie mogą być gorsze niż dla oprogramowania wymienionego
w SIWZ,
2) funkcjonalności równoważnej oprogramowania , która nie może być gorsza od
funkcjonalności wymienionych w SIWZ,
3) oprogramowania, które musi być kompatybilne i w sposób niezakłócony współdziałać ze
sprzętem i oprogramowaniem funkcjonującym u Zamawiającego,
4) oprogramowania, które nie może zakłócić pracy środowiska systemowo-programowego
Zamawiającego,
5) oprogramowania, które musi w pełni współpracować z systemami Zamawiającego,
opartymi o dotychczas użytkowane oprogramowanie,
6) oprogramowania, które musi zapewniać pełną, równoległą współpracę w czasie
rzeczywistym i pełną funkcjonalną zamienność oprogramowania
równoważnego z
oprogramowaniem określonym w SIWZ,
7) warunków
i
zakresu
świadczenia
usług
gwarancyjnych,
asysty
technicznej
oprogramowania równoważnego, muszą być nie gorsze niż dla wymienionego w SIWZ.
2. W przypadku zaoferowania przez Wykonawcę produktu równoważnego Wykonawca dokona
wspólnie z Zamawiającym instalacji i testowania produktu równoważnego w środowisku
sprzętowo-programowym Zamawiającego.
3. W przypadku zaoferowania przez Wykonawcę oprogramowania równoważnego Wykonawca
będzie zobowiązany do przeprowadzenia autoryzowanych przez producenta oprogramowania
szkoleń dla 7 administratorów umożliwiających pełne poznanie produktu równoważnego oraz
dla 90 użytkowników systemu. Wykonawca zobowiązuje się w ramach świadczeń
gwarancyjnych do przeprowadzenia corocznych instruktaży ze sposobu licencjonowania
Oprogramowania. Pierwszy instruktaż musi odbyć się w terminie 30 dni od dnia zawarcia
Umowy, termin każdego kolejnego instruktażu (po roku/latach) zostanie ustalony przez
Przedstawicieli Stron. Szkolenia muszą być przeprowadzone w autoryzowanym przez
producenta oprogramowania centrum szkoleniowym. Uczestnicy szkoleń muszą otrzymać
każdorazowo certyfikat lub inny dokument imienny ukończenia szkolenia, certyfikat lub inny
dokument imienny musi być wystawiony przez producenta oprogramowania. Wykonawca w
ramach autoryzowanych szkoleń zapewni salę szkoleniową na terenie Warszawy wraz z
wyżywieniem w postaci jednego gorącego posiłku (obiad) i napojów w czasie przerw każdego
dnia dla każdego uczestnika.
4. W przypadku, gdy zaoferowane przez Wykonawcę oprogramowanie równoważne nie będzie
właściwie współdziałać ze sprzętem i oprogramowaniem funkcjonującym u Zamawiającego
i/lub spowoduje zakłócenia w funkcjonowaniu pracy środowiska sprzętowo-programowego u
Zamawiającego, Wykonawca pokryje wszystkie koszty związane z przywróceniem i
sprawnym działaniem infrastruktury sprzętowo-programowej Zamawiającego 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
oprogramowania
równoważnego.
5. Oprogramowanie równoważne dostarczane przez Wykonawcę nie może powodować utraty
kompatybilności oraz wsparcia producentów innego używanego i współpracującego z nim
oprogramowania.
6. Oprogramowanie równoważne zastosowane przez Wykonawcę nie może w momencie
składania przez niego oferty mieć statusu zakończenia wsparcia technicznego producenta.
Niedopuszczalne jest zastosowanie oprogramowania równoważnego, dla którego producent
ogłosił zakończenie jego rozwoju w terminie 3 lat licząc od momentu złożenia oferty.
Niedopuszczalne jest użycie oprogramowania równoważnego, dla którego producent
oprogramowania współpracującego ogłosił zaprzestanie wsparcia w jego nowszych wersjach.
W przypadku Dostawy oprogramowania równoważnego Wykonawca zobowiązany jest:
1. Przeprowadzić 5 (pięć) autoryzowanych Warsztatów dla 4 administratorów Zamawiającego z
zakresu
instalacji,
konfiguracji
i
zarządzania
oprogramowaniem
równoważnym,
umożliwiających pełne poznanie produktu równoważnego, Wykonawca w terminie 14 dni od
dnia zawarcia Umowy przedstawi do zatwierdzenia Zamawiającemu harmonogram
Warsztatów, Wykonawca w ramach Warsztatów zapewni salę szkoleniową na terenie
Warszawy wraz z wyżywieniem w postaci jednego gorącego posiłku (obiad) i napojów w
czasie przerw każdego dnia dla każdego uczestnika. Czas trwania każdego z Warsztatów nie
może być krótszy niż 5 (pięć) Dni Roboczych w następujących po sobie Dniach Roboczych.
2. Opracowanie przez Wykonawcę Projektu Technicznego, zawierającego wszystkie elementy
dostarczonego oprogramowania równoważnego oraz jego Integracji, Wykonawca w terminie
21 dni od dnia zawarcia Umowy przedstawi do odbioru Zamawiającemu Projekt Techniczny
3. Realizacja przez Wykonawcę Integracji i wdrożenia oprogramowania równoważnego,
Wykonawca przed upływem terminu, o którym mowa w § 2 ust. 1 wzoru Umowy, dokona
Integracji i wdrożenia oferowanego Oprogramowania,
4. Opracowanie przez Wykonawcę aktualizacji Dokumentacji Technicznej infrastruktury
systemu Platformy Integracji, Wykonawca nie później niż z upływem terminu 14 dni po
wdrożeniu oprogramowania równoważnego, przedstawi do odbioru Zamawiającemu
zaktualizowaną Dokumentację Techniczną systemu Platformy Integracji
5. Dostarczenie
wszelkich
dodatkowych
licencji
-
niezbędnych
do
prawidłowego
funkcjonowania oprogramowania równoważnego.
I.
W przypadku zaoferowania oprogramowania
równoważnego Wykonawca będzie zobowiązany do
przeprowadzenia autoryzowanych przez producenta oprogramowania szkoleń dla 7 administratorów
umożliwiających pełne poznanie produktu równoważnego oraz dla 90 użytkowników systemu. Szkolenia
muszą być przeprowadzone w autoryzowanym przez producenta oprogramowania centrum szkoleniowym.
Uczestnicy szkoleń muszą otrzymać każdorazowo certyfikat lub inny dokument imienny
ukończenia
szkolenia, certyfikat lub inny dokument imienny musi być wystawiony przez producenta oprogramowania.
Oprogramowanie
równoważne musi integrować się i w pełni współdziałać z, posiadanym przez
Zamawiającego oprogramowaniem, a w szczególności wymieniać i przetwarzać w czasie rzeczywistym
dane. Liczba udzielonych licencji na oprogramowanie równoważne musi zapewniać co najmniej możliwość
instalacji i korzystania z oprogramowania w liczbie i rodzaju odpowiadającym liczbie łącznej (obejmującej
również posiadane licencje) licencji, które zamawiający posiadał by gdyby zostały udzielone licencje
wskazane powyżej. Oprogramowanie równoważne nie może ograniczać funkcjonalności posiadanego przez
zamawiającego oprogramowania, z którym się integruje. Szkolenie musi być autoryzowane przez
producenta oferowanego oprogramowania, o ile producent autoryzuje szkolenia i swoim zakresem
obejmować szczegółowo wszystkie czynności administracyjne oferowanego oprogramowania.
Gwarancja dla oprogramowania równoważnego musi być nie gorsza niż wyspecyfikowana w SIWZ.
II.
Oprogramowanie równoważne musi:
1) realizować odpowiednio do oprogramowania wobec którego jest równoważne funkcjonalności:
a)
oprogramowania IBM Netcool Network Management Entry Device Resource, IBM Netcool
Network Management Base Install, IBM Netcool Network Management Event EMS Resource,
IBM Tivoli Netcool/Impact Base Install oraz IBM Tivoli Netcool/Impact Tier 1 Resource,
b) oprogramowania IBM Tivoli Application Dependency Discovery Manager Resource
c)
oprogramowania IBM Tivoli Business Service Manager Tier 1 Resource
d) oprogramowania
IBM
BigFixLifecycleResource,
IBM
BigFixComplianceResource,
IBM
BigFixInventoryResource oraz IBM Endpoint Manager forServer AutomationResource
e)
oprogramowania IBM SmartCloud Virtual Storage Center (VSC).
f)
oprogramowania IBM Spectrum Protect
2) Oprogramowanie równoważne musi spełniać następujące wymagania:
Nabycie licencji oprogramowania równoważnego i użytkowanie tego oprogramowania wspólnie z
oprogramowaniem, do którego Zamawiający posiada prawa licencyjne, składającym się na rozwiązanie Systemu
Monitorowania Infrastruktury oraz Systemu Bazy CMDB, musi pozwalać na legalne używanie tego
oprogramowania. W przypadku dostarczenia oprogramowania równoważnego
3) warunki licencji - pola eksploatacji i uprawnienia zamawiającego nie mogą ograniczać uprawnień
zamawiającego do korzystania z oprogramowania, wynikających odpowiednio z licencji wymienionych
powyżej w szczególności nie mogą ograniczać pól eksploatacji, prawa zależnego jeśli obejmują, oraz
możliwości stosowania – nie mogą ograniczać liczby użytkowników rodzaju użytkowników, liczby
procesorów Oprogramowanie równoważne do:
a)
IBM Netcool Network Management Entry Device Resource, IBM Netcool Network Management
Base Install, IBM Tivoli Netcool/Impact Base Install oraz IBM Tivoli Netcool/Impact Tier 1
Resource, musi realizować co najmniej następujące funkcjonalności:
i.
Narzędzia IBM Tivoli Netcool/Impact Base Install oraz IBM Tivoli Netcool/Impact Tier 1
Resource:
1.
2.
System musi współpracować z oferowanym rozwiązaniem do przetwarzania zdarzeń.
System musi pozwalać na wzbogacanie i korelację zdarzeń w oparciu o informacje dostępne w:
zewnętrznych bazach danych – min. Oracle, DB2, MSSQL, MySQL
innych systemach przetwarzania zdarzeń
źródłach LDAP – MS Active Directory, OpenLDAP
źródłach SNMP, XML, HTML
źródłach JMS
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Moduł musi pozwalać na:
modyfikację treści zdarzeń
dodawanie wartości do rekordu opisującego zdarzenie
usuwanie zdarzeń
tworzenie nowych zdarzeń
modyfikację zawartości zewnętrznych źródeł danych
usuwanie danych z zewnętrznych źródeł danych
dodawanie danych do zewnętrznych źródeł danych
generowanie zawartości dynamicznych i aktywnych stron WWW, zawierających m.in. informacje
pochodzące z zewnętrznych źródeł danych oraz zdarzeń
Dla źródeł typu SQL system musi pozwalać na budowę logicznego modelu danych – definiowanie
wykorzystywanych pól tabel, linków pomiędzy tabelami, pól kluczowych.
Mechanizmy wzbogacania i korelacji muszą być w pełni konfigurowalne w:
wewnętrznym języku programowania oferowanym przez proponowany system
języku Java Script
Operacje wykonywane przez oferowany system muszą być konfigurowane poprzez „programy”
pisane wewnątrz oferowanego rozwiązania, mające dostęp do wszystkich wspieranych przez
rozwiązanie źródeł danych
Wbudowany wewnętrzny język programowania musi być wykonywany przez system bezpośrednio,
bez uruchamiania dodatkowych zewnętrznych procesów (script/program exec).
Programy w języku java script muszą być wykonywany przez system bezpośrednio, bez
uruchamiania dodatkowych zewnętrznych procesów (script/program exec).
Wewnętrzny język programowania musi mieć możliwość wykorzystania funkcji:
kontrola przepływu: if, while
Operacje matematyczne: +,-, *, /, %
Operacje na tekście: łączenie ciągów, zliczanie znaków, porównywanie ciągów, porównywanie
ciągów w oparciu o wyrażenia regularne, zamiana fragmentów ciągu w oparciu o wyrażenia
regularne, „wycianie” tekstu w oparciu o wyrażenia regularne, „wycinanie” tekstu w oparciu o
pozycję, zamiana tekstu na liczbę, zamiana tekstu na tablicę
Operatory porównania: ==, !=, <, >, <=, >=
Operatory logiczne: OR, AND, NOT
Możliwość logowania dowolnych komunikatów z przetwarzania
Pobieranie wartości z baz danych: poprzez klucz, poprzez filtr, poprzez zdefiniowany link oraz w
oparciu o dowolne zapytanie SQL.
Pobieranie wartości z XML
Pobieranie wartości ze strony HTML
Pobieranie wartości z WebService
Pobieranie wartości poprzez SNMP
Pobieranie czasu i daty, konfigurowalna zamiana reprezentacji tekstowej czasu i daty na wartość
numeryczną (np. unixtime)
Wykonanie dodatkowych operacji na zewnętrznych klasach java (JavaCall)
Wysyłanie wiadomości email
Hibernację programu
System musi pozwalać na zwiększanie wydajności poprzez dołączanie kolejnych instancji
oprogramowania. Dystrybucja zadań musi się w takim przypadku odbywać automatycznie, bez
jakiejkolwiek interwencji operatora,
Konsola operatorska musi udostępniać w jednym i tym samym interfejsie pełną edycję źródeł danych
oraz tworzonych w systemie programów, ich uruchamianie i wdrażanie do cyklu produkcji – z
funkcją kolorowania składni, wskazywania miejsca wystąpienia błędu w kodzie, podglądem
zawartości poszczególnych tabel i innych źródeł danych, generowanych logów. Powyższa
funkcjonalność musi być integralnym elementem rozwiązania, nie może opierać się o dodatkowe
zewnętrzne oprogramowanie czy też sesje terminalowe.
Konsola operatorska musi pozwalać na generowanie treści strony dla użytkownika w wyniku
działania „programów” przygotowanych w wewnętrznym języku oferowanego rozwiązania (o
funkcjonalności opisanej we wcześniejszych wymaganiach), mających dostęp do zdarzeń i źródeł
danych. Każdorazowe wywołanie danego URLa musi skutkować wykonaniem danego programu i
wygenerowaniem strony. Strony takie muszą wspierać pełną interakcję. Mechanizm ten musi być
implementowany bezpośrednio wewnątrz oferowanego rozwiązania, musi być elementem
standardowo dostępnym i przygotowanym przez producenta systemu. W szczególności nie jest
14.
akceptowalna realizacja w oparciu o skrypty php/perl itp. osadzone wewnątrz serwera WWW.
Dostęp do takich stron musi być realizowany w oparciu o standardową autoryzację i autentykację
wbudowaną w oferowane rozwiązanie. Administrator musi mieć możliwość tworzenia nowych
„programów” i modyfikowania istniejących z poziomu standardowego interfejsu WWW
oferowanego systemu.
Moduł musi udostępniać interfejs linii poleceń CLI dla głównych funkcji systemu:
eksport/import konfiguracji
uruchamianie „programów” napisanych w oferowanym rozwiązaniu
sprawdzenie składni
System musi posiadać wbudowany system kontroli wersji (np. SVN)
15.
System musi wspierać autoryzację użytkowników i ich grupowanie.
16.
Moduł musi mieć możliwość instalacji w trybie zapewniającym odporność na awarie.
17.
Oferowane licencje muszą być przechodnie - musi być możliwość ich przenoszenia na nowe serwery
w ramach wymiany starych technologii na nowe.
Dla oferowanego systemu muszą być dostępne dedykowane, dostarczane przez producenta
oprogramowania szkolenia - prowadzone w Polsce
Zamawiający wymaga posiadania przez Oferenta autoryzacji na sprzedaż oferowanego
oprogramowania wystawionej przez producenta – o ile jego dystrybucja na terenie Polski jest w ten
sposób limitowana
System musi posiadać przygotowane przez producenta oprogramowania podręczniki: użytkownika i
administratora.
Oferowany system musi być dostępny w oficjalnej dystrybucji na terenie Polski.
13.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
Oferowany system musi posiadać oficjalne wsparcie producenta oprogramowania, nie jest
akceptowalne wsparcie typu „community support”, oferowane przez społeczność jego użytkowników
lub wsparcie oferowane wyłącznie przez dostawcę.
Oferowany system musi posiadać wsparcie, którego co najmniej pierwsza linia jest świadczona w
języku polskim.
Zamawiający musi mieć możliwość zgłaszania problemów z oprogramowaniem bezpośrednio do
producenta oprogramowania. Pośrednictwo firmy, która wdrażała system nie może być wymagane
do skorzystania z przywileju uzyskania wsparcia.
System musi być produktem aktualnie dostępnym w ofercie producenta, bez określonego terminu
wycofania ze sprzedaży. Wymóg nie dotyczy "wygaszania" konkretnej wersji oprogramowania, o ile
będzie dostępny jej następca.
System musi mieć możliwość instalacji swoich komponentów serwerowych (nadzorujących pracę
agentów, raportujących i bazodanowych) w środowisku zwirtualizowanym.
Podczas okresu ważności wsparcia producenta dla systemu powinny być zapewnione bezpłatne
aktualizacje do nowych wersji produktu (wszystkich, które się pojawią). Wymóg ten nie dotyczy
konieczności zapewnienia usługi aktualizacji, a jedynie praw Zamawiającego w zakresie licencji
wykupionej u producenta systemu.
System musi obsługiwać nieograniczoną przez zaoferowane licencje liczbę operatorów (ograniczenie
powinno być jedynie na bazie wydajności platformy sprzętowej)
Oferowane licencje nie mogą być okresowe, tymczasowe lub współdzielone, muszą one po zakupie
stać się własnością Zamawiającego.
Moduł musi posiadać mechanizmy definiowania portów po których będzie odbywała się
komunikacja systemu z konsolami. Komunikacja taka powinna być możliwa również jeśli na ścieżce
będzie się znajdował odpowiednio skonfigurowany firewall.
Moduł musi posiadać mechanizm pozwalający na wykrycie niedostępności każdego z komponentów.
ii.
Narzędzia IBM Netcool Network Management Entry Device Resource, IBM Netcool
Network Management Base Install:
1.
2.
3.
4.
5.
6.
Oferowany produkt musi obsługiwać warstwowy model monitorowania składający się z:
Sond, niezależnych od miejsca instalacji serwera centralnego, komunikujących się z nim za
pośrednictwem sieci i pozwalających na wstępną selekcję i translację treści przesyłanych
komunikatów.
Centralnego serwera przetwarzającego, korelującego i prezentującego odebrane przez sondy
zdarzenia.
System musi pozwalać na instalację dowolnej ilości sond i musi wspierać rozproszoną ich
architekturę (np. sondy regionalne)
Sposób licencjonowania systemu nie może limitować ilości zainstalowanych w środowisku sond dla
urządzeń sieciowych i serwerów. Wymóg nie ma zastosowania do integracji elementów typu EMS i
systemów monitorowania firm trzecich.
System musi pozwalać na budowę hierarchicznego systemu serwerów centralnych, z możliwością
budowy architektury odpornej na awarię działającej w trybie active-active.
System musi pozwalać na budowę warstwowego systemu monitorowania – z oddzielnymi
warstwami akwizycji, korelacji i prezentacji informacji.
System musi posiadać aktywne sondy zbierające zdarzenia z całego środowiska IT. W ramach
obsługiwanych przez oferowane rozwiązanie systemów i technologii muszą być dostępne
(przygotowane i wspierane bezpośrednio przez producenta systemu) integracje pozwalające na
odbieranie wiadomości poprzez:
SNMP (v1, v2c, v3) trap,
Syslog message, Wykonanie skryptu (STDOUT, EXEC, PIPE)
email (odbieranie i przetwarzanie treści), JDBC/ODBC
Log file, Windows Logfile
tcp socket (nasłuch na porcie)
XML over JMS, HTTP/HTTPS, MQTT
integrację z BMC patrol
integrację z CA Spectrum
integrację z Cisco APIC, Cisco CTM
integrację z HP NNM, HP NNMi, HP Operations Manager
protokół Tivoli EIF
integrację z MS SCOM
7.
Wstępne przetwarzanie zdarzeń musi być konfigurowalne już na etapie ich pobierania ze źródła
(warstwa sond) – za pomocą plików z regułami przetwarzania. Musi istnieć możliwości
selektywnego, automatycznego usuwania zdarzeń (co najmniej na bazie wyrażeń regularnych,
przenoszonych w treści zdarzenia wartości numerycznych i opisowych, kategorii zdarzenia),
modyfikacji ich treści (np. zamiana wartości symbolicznych na ich opis tekstowy), uzupełniania np.
na podstawie zawartości plików tekstowych.
8.
Pliki reguł muszą obsługiwać opisane poniżej mechanizmy przetwarzania – muszą być wyposażone
w interpretowany lub kompilowany przy uruchomieniu język konfiguracyjny. Wszystkie poniżej
wymienione operacje muszą być standardowym, wspieranym przez producenta systemiu elementem
funkcjonalności sond i nie mogą być realizowane w połączeniu z elementami zewnętrznymi w
stosunku do sondy (w szczególności nie jest dopuszczalne wykonywanie zewnętrznych skryptów i
programów realizujące wymienione funkcje).
kontrola przepływu: if, foreach, switch
Operacje matematyczne: +,-, *, /, zmiana kodowania bin, hex, dec
Operacje na tekście: łączenie ciągów, zliczanie znaków, zamiana wielkości liter, usuwanie znaków
„whitespace”, porównywanie ciągów, porównywanie ciągów w oparciu o wyrażenia regularne,
zamiana fragmentów ciągu w oparciu o wyrażenia regularne, „wycianie” tekstu w oparciu o
wyrażenia regularne, „wycinanie” tekstu w oparciu o pozycję, zamiana tekstu na liczbę
Operatory porównania: ==, !=, <, >, <=, >=, sprawdzanie istnienia zmiennej
Wykorzystanie zewnętrznych plików z tabelami konwersji klucz-wartość.
Możliwość logowania „surowej” treści odbieranych komunikatów
Monitorowania poziomu obciążenia sondy i uwzględnianie tego parametru w algorytmie
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
przetwarzania
Pobieranie nazwy węzła na którym rezyduje sonda
Debugowanie przetwarzania.
Wysyłanie zdarzeń do różnych serwerów centralnych w zależności od treści zdarzenia.
Sondy muszą mieć możliwość wykrywania tzw. sztormu zdarzeń i modyfikowania swojego sposobu
działania gdy zajdzie taka sytuacja.
System powinien zawierać predefiniowane reguły dla zdarzeń pochodzących z typowych urządzeń
sieciowych i systemów infrastrukturalnych.
Sposób przetwarzania zdarzeń (algorytm działania sond, reguły) powinien być konfigurowalny bez
użycia dodatkowych narzędzi zewnętrznych w stosunku do oferowanego rozwiązania.
Sondy muszą mieć możliwość automatycznej dystrybucji ich konfiguracji (reguł) z lokalizacji
centralnej (pojedyncze repozytorium). W przypadku braku dostępu do repozytorium powinny
używać ostatnio pobraną wersję plików z regułami.
Sondy muszą wspierać wieloplikowe reguły – np. takie gdzie każda z obsługiwanych przez daną
sondę technologii jest obsługiwana przez oddzielny plik.
System musi posiadać mechanizm „heartbeat” pozwalający na wykrycie niedostępności każdej z
sond.
Oferowany system musi cechować się wydajnością większą niż 200 zdarzeń na sekundę (w trybie
ciągłym) bez utraty informacji, z pełną korelacją.
Zdarzenia muszą być przechowywane w relacyjnej bazie danych o otwartej strukturze. Musi istnieć
możliwość dodawania nowych pól i modyfikacji istniejących. Czynności te nie mogą powodować
konieczności zatrzymania systemu.
Zdarzenia muszą być poddawane procesom deduplikacji („sklejania” takich samych komunikatów z
zachowaniem informacji o sumarycznej ich ilości, czasie wystąpienia pierwszego i ostatniego z
nich). Procesy te powinny być konfigurowalne dla administratorów.
Zdarzenia muszą być poddawane procesom korelacji, z możliwością tworzenia nowych zdarzeń na
bazie korelacji (np. zdarzenie dla usługi wygenerowane na bazie zdarzeń technicznych). Procesy te
powinny być konfigurowalne dla administratorów. System musi pozwalać na korelację dowolnych
zdarzeń, w tym zdarzeń z różnych serwerów i różnych systemów monitorowania. Administratorzy
powinni mieć możliwość tworzenia własnych korelacji dla przychodzących urządzeń bez
konieczności zakupu dodatkowych licencji.
Mechanizmy korelacji zdarzeń powinny być wyzwalane co najmniej w następujący sposób:
okresowo, w momencie wykonywania operacji na bazie danych (np.. insert zdarzenia), w odpowiedzi
na sygnał (np. backup, shutdown itp.)
Wszystkie wbudowane korelacje i mechanizmy przetwarzania zdarzeń (np.. deduplikacja, usuwanie
zdarzeń przeterminowanych) muszą być edytowalne dla administratorów systemu bez konieczności
zakupu dodatkowych licencji
Korelacje powinny być wyzwalane co najmniej w następujący sposób: okresowo, w momencie
wykonywania operacji na bazie danych (np.. insert zdarzenia), w odpowiedzi na sygnał (np. backup,
shutdown itp.)
Muszą być dostępne mechanizmy eskalacji zdarzeń na bazie wagi zdarzenia, okresu zalegania w
systemie, statusu, treści i kategorii
Korelacje muszą być wykonywane wewnątrz systemu (na serwerach centralnych) i muszą być jego
integralną częścią, w pełni wspieraną przez producenta oferowanego systemu. Nie jest dopuszczalne
wywoływanie w tym celu zewnętrznych programów – np. skryptów perl, php itp., skompilowanych
podprogramów czy też skryptów napisanych w językach powłoki.
Eskalacja zdarzeń musi umożliwiać automatyczną modyfikację zdarzenia (np. podniesienie poziomu
krytyczności, przypisane do operatora itp.) lub wykonanie czynności zewnętrznej – wysłanie maila,
wywołanie skryptu.
System musi wspierać autoryzację użytkowników i ich grupowanie, Dla każdego użytkownika
powinno być możliwe określanie filtrów na zdarzenia prezentowane przez system (ograniczenie
dostępnych informacji stosownie do poziomu uprawnień użytkownika). W tym celu system musi
pozwalać na tworzenie wewnętrznej bazy użytkowników i uprawnień, musi również pozwalać na
integrację z systemami usług katalogowych.
Zdarzenia powinny być prezentowane na ekranach operatorskich co najmniej w formie:
tabelarycznej
graficznej w podkładami z plików graficznych
System powinien wspierać przeglądarki WWW: Internet Eksplorer i Firefox.
28. Do pracy interfejsu mogą być wykorzystywane wyłącznie wbudowane, wewnętrzne mechanizmy
przeglądarki wraz z modułem Oracje Java. Nie jest dopuszczalne stosowanie technologii flash,
silverlight i tym podobnych.
29. System powinien wspierać autoryzację użytkowników i ich grupowanie, Dla każdego użytkownika
powinno być możliwe określanie filtrów na zdarzenia prezentowane przez system (ograniczanie
zakresu dostępnych danych).
30. Konsola operatorska powinna mieć możliwość prezentacji aktywnych mapek np. reprezentujących
monitorowane systemy, na których ikony zmieniają kolor zgodnie z priorytetami przypisanych do
nich zdarzeń
31. Konsola operatorska musi udostępniać możliwość wykonywania akcji inicjowanych przez operatora
(narzędzia dostępne w menu głównym i kontekstowym, uruchamianym prawym przyciskiem
myszki) Uruchamiane narzędzia powinny mieć możliwość zapytania operatora o parametry
wykonania. Administratorzy systemu powinni mieć możliwość tworzenia nowych i modyfikacji
istniejących narzędzi.
32. Konsola operatorska musi zapewniać możliwość nadzoru i rejestracji czynności wykonywanych
przez operatora na danym zdarzeniu – np. w formie dziennika przypisanego do zdarzenia.
33. System musi posiadać bazę informacji historycznych
34. System musi posiadać moduł raportowania, z możliwością modyfikacji wbudowanych raportów i
tworzenia nowych.
35. Tworzenie i modyfikacja raportów nie może wymagać zakupu dodatkowych licencji.
36. Raporty muszą być renderowane w postaci co najmniej: html, pdf i xls.
37. Raporty muszą być generowane na żądanie i według wskazanego harmonogramu.
38. Moduł raportowy musi pochodzić od producenta oferowanego systemu i musi być w pełni przez
niego wspierany.
39. System musi posiadać raporty predefiniowane przez producenta systemu.
40. Oferowane licencje muszą być przechodnie - musi być możliwość ich przenoszenia na nowe serwery
41. Dla oferowanego systemu muszą być dostępne dedykowane, dostarczane przez producenta
42. Zamawiający wymaga posiadania przez Oferenta autoryzacji na sprzedaż oferowanego
sposób limitowana
43. System monitorowania musi posiadać przygotowane przez producenta oprogramowania podręczniki:
użytkownika i administratora.
44. Oferowany system musi być dostępny w oficjalnej dystrybucji na terenie Polski.
45. Oferowany system musi posiadać oficjalne wsparcie producenta oprogramowania, nie jest
46. Oferowany system musi posiadać wsparcie, którego co najmniej pierwsza linia jest świadczona w
języku polskim.
47. Zamawiający musi mieć możliwość zgłaszania problemów z oprogramowaniem bezpośrednio do
48. System monitorowania musi być produktem aktualnie dostępnym w ofercie producenta, bez
określonego terminu wycofania ze sprzedaży. Wymóg nie dotyczy "wygaszania" konkretnej wersji
oprogramowania, o ile będzie dostępny jej następca.
49. System monitorowania musi mieć możliwość instalacji swoich komponentów serwerowych
(nadzorujących pracę agentów, raportujących i bazodanowych) w środowisku zwirtualizowanym.
50. System musi udostępniać ekrany przeznaczone dla urządzeń mobilnych, prezentujących co najmniej
podstawowe metryki i informacje.
51. Podczas okresu ważności wsparcia producenta dla systemu powinny być zapewnione bezpłatne
52. System musi obsługiwać nieograniczoną przez zaoferowane licencje liczbę operatorów (ograniczenie
53. Oferowane licencje nie mogą być okresowe, tymczasowe lub współdzielone, muszą one po zakupie
54. System monitorowania musi posiadać mechanizmy definiowania portów po których będzie odbywała
się komunikacja systemu z konsolami. Komunikacja taka powinna być możliwa również jeśli na
ścieżce będzie się znajdował odpowiednio skonfigurowany firewall.
55. Moduł monitorowania musi posiadać mechanizm pozwalający na wykrycie niedostępności każdego z
komponentów.
56. System monitorowania musi umożliwiać zaszyfrowanie komunikacji w relacji konsola-system i
sonda-system.
57. Oferowany system monitorowania musi obsługiwać integrację poprzez dedykowane do tego celu
komponenty (bramy zdarzeń) w zakresie przesyłania informacji o wykrytych nieprawidłowościach
do:
systemu przetwarzania komunikatów
systemów Help-Desk
plików
58. Bramy zdarzeń muszą być konfigurowalne co najmniej w zakresie:
selekcji przekazywanych informacji
operacji wykonywanych po zakończonej synchronizacji (np. ustawienie flagi w rekordzie zdarzenia
59. Bramy zdarzeń muszą pozwalać zarówno na jednostronną komunikację (wysyłanie), jak i na pełną
dwustronną wymianę danych – w tym na dopisywanie do istniejących zdarzeń identyfikatora tzw.
ticketu w systemie Help-Desk.
60. System musi pozwalać na automatyczne uruchamianie komponentu który uległ awarii i się wyłączył
(np. sondy).
b) IBM Tivoli Application Dependency Discovery Manager Resource musi realizować co najmniej
następujące funkcjonalności:
LP
1.
2.
3.
4.
5.
Wymaganie
Oprogramowanie musi pozwalać na:
automatyczne wykrywanie komponentów infrastruktury IT
automatyczne wykrywanie konfiguracji komponentów infrastruktury IT
automatyczne wykrywanie relacji i powiązań pomiędzy komponentami
automatyczne wykrywanie i śledzenie zmian w zasobach i ich konfiguracji
Oprogramowanie musi wspierać w ramach tego samego produktu, wspólnego modelu danych
pojedynczej konsoli:
serwery i systemy operacyjne
aplikacje middleware
aplikacje użytkowe
infrastrukturę techniczną
usługi sieciowe (np. LDAP, NFS, DNS)
Oprogramowanie musi posiadać przygotowane i wspierane przez producenta oferowanego systemu
sensory do skanowania systemów:
AIX, HPUX, Linux, Solaris, Tru64 Unix, Windows, FreeBSD, OpenVMS,
IBM DataPower Applicance, HP BladeSystem, HP Non-Stop, IBM HMC, VmWare ESX i ESXi
sensory do skanowania
Active Directory, Microsoft HIS, Microsoft Cluster, Microsoft Exchange server, Microsoft Hyper-V,
usługi sieciowe Windows (SMB)
Apache Web Server, Cisco Works, Citrix, DNS,
IBM Cluster Systems Management, IBM Lotus Domino, IBM Tivoli Monitoring, IBM Composite
Application Manager, IBM WebSphere, IBM WebSphere eXtreme Scale, IBM WebSphere Message
Broker, IBM WebSphere MQ Server
iPlanet Web server, JBOSS, KVM, Oracle Application Server, SAP ccms, SAP sld, , Veritas Cluster,
VmWare Virtual Center, WebLogic
sensory do skanowania baz danych: DB2, Informix, MS SQL, Oracle, Sybase
6.
7.
sensory do skanowania urządzeń: Alteon, BIG-IP, Checkpoint, Cisco, Extreme, Brocade, IBM
BladeCenter, NetScreen, Cisco PIX, EMC, IBM SVC, XIV storage,
Oprogramowanie musi udostępniać możliwość budowania własnych sensorów
21.
Zakres i szczegółowość wykrywanych przez sensory informacji musi być modyfikowalny przez
administratorów oferowanego systemu bez konieczności zakupu dodatkowych licencji lub usług
Kolekcjonowane elementy konfiguracji muszą obejmowć co najmniej
statyczną i dynamiczną konfigurację danego obiektu
zasoby niezbędne do działania komponentu (np. pule połączeń JDBC, kolejki JMS, patche itp.)
zainstalowane w danym obiekcie komponenty dodatkowe (jak np. EJB, JSP).
Kolekcjonowane informacje o zależnościach muszą obejmować co najmniej:
zależności transakcyjne: logiczne połączenia pomiędzy obiektem a komponentami współpracującymi
(np. powiązane bazy danych)
kontenery: relacje typu serwer-aplikacja, wirtualizator-serwer-aplikacja, przynależność obiektów do
aplikacji biznesowej
infrastruktura: usługi sieciowe itp.
Wykrywanie informacji musi odbywać się bez konieczności instalowania agentów, za pomocą
standardowych protokołów (np. SNMP, SSH, JMX, WMI)
Proces wykrywania musi odbywać się za pomocą sieci IP przy wykorzystaniu standardowych
mechanizmów komunikacyjnych wbudowanych w systemy operacyjne i urządzenia
System musi wspierać wykrywanie w środowiskach wykorzystujących firewalle – musi udostępniać
komponent pośredniczący w wykrywaniu (proxy).
Oprogramowanie musi mieć możliwość współpracy z bazą CMDB w celu synchronizacji zebranych
danych
Oprogramowanie musi być zaprojektowane do współpracy z dużymi serwerowniami. Wymagana jest
możliwość sprawnego i efektywnego działania w środowiskach o wielkości rzędu 10000 serwerów.
Wymagana jest deklaracja producenta (np.w postaci odniesienia do odpowiedniego paragrafu
dokumentacji produktowej) lub informacja o wykonanych z sukcesem wdrożeniach o tej skali.
System musi mieć możliwość instalacji warstwowej: z serwerami „regionalnymi” i serwerem
centralnym nadzorującym i konsolidującym całość środowiska. Rozwiązanie takie musi stanowić
całość – nie mogą to być rozproszone i niepowiązane ze sobą oddzielne serwery skanujące.
Informacje związane z bezpieczeństwem (np. hasła, informacje dostępowe do skanowanych
zasobów) muszą być szyfrowane algorytmem nie gorszym niż AES 128bit.
System musi mieć konsolę operatorską opartą na technologii WWW z obsługą szyfrowania SSL
(hpps). Jedynym elementem dodatkowym wymaganym do działania konsoli może być środowisko
Java. W szczególności nie jest dopuszczalne stosowanie technologii flash czy też sliverlight.
Konsola operatorska musi udostępniać automatycznie generowane, graficzne obrazowanie topologii i
zależności. Zamawiający uznaje, iż prezentacja w postaci tabelarycznej czy też tekstowej nie spełnia
niniejszego wymogu.
System musi udostępniać integrację z oprogramowaniem wykorzystywanym przez Zamawiającego:
IBM CAM, IBM Omnibus, IBM TBSM
System musi udostępniać dwukierunkową integrację z bazą CMDB
22.
System musi pozwalać na instalację na platformie: AIX (6.1 i 7.1), Linux, Windows (2008 i 2012)
23.
sposób limitowana
System monitorowania musi posiadać przygotowane przez producenta oprogramowania podręczniki:
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
24.
25.
26.
27.
28.
29.
30.
31.
32.
języku polskim.
System monitorowania musi być produktem aktualnie dostępnym w ofercie producenta, bez
System monitorowania musi mieć możliwość instalacji swoich komponentów serwerowych
c)
IBM Tivoli Business Service Manager Tier 1 Resource musi realizować co najmniej następujące
funkcjonalności:
LP
1.
2.
3.
4.
5.
6.
Wymaganie
Moduł monitorowania biznesowego musi być ściśle zintegrowany z:
Modułem monitorowania
Modułem przetwarzania zdarzeń
Systemem Help-Desk Zamawiającego
Moduł monitorowania biznesowego musi oferować funkcjonalność analizy zdarzeń i metryk
dotyczących dowolnego obiektu infrastruktury IT monitorowanego przez system zarządzania w
kontekście usług świadczonych na rzecz klient wewnętrznego i zewnętrznego.
Moduł musi pozwalać na przyjmowanie metryk i zdarzeń pochodzących z infrastruktury za
pośrednictwem systemu zarządzania zdarzeniami.
Moduł musi pozwalać na przyjmowanie metryk i zdarzeń pochodzących z infrastruktury za pomocą
odpytywania zewnętrznych baz danych
Moduł musi pozwalać na przyjmowanie metryk i zdarzeń pochodzących z infrastruktury za pomocą
odpytywania zewnętrznych WebService
Moduł musi pozwalać na mapowanie odebranych informacji na obiekty stanowiące tzw. drzewo
świadczenia usługi (usługa i jej komponenty).
7.
8.
9.
10.
11.
Moduł musi pozwalać na określanie aktualnego stanu danej usługi i jej komponentów.
Moduł monitorowania biznesowego musi umożliwiać ustalanie aktualnego stanu danej usługi i
podusługi na podstawie:
Odebranych zdarzeń informacyjnych (np. działa/nie działa)
Odebranych zdarzeń z wartością liczbową (np. czas odpowiedzi)
Zapytań do baz danych (np. o liczbę zalogowanych użytkowników, liczbę otwartych zgłoszeń
serwisowych)
Wyniku zapytań do zewnętrznych usług Web Service
Statusu obiektów podrzędnych
Ilości obiektów podrzędnych
Metryk złożonych będących kombinacją elementów wymienionych powyżej
Wartości poszczególnych metryk pobieranych przez agentów modułu monitorowania
Definiowanie stanu usługi i jej komponentów na podstawie obiektów podrzędnych powinno
oferować reguły (dla obiektów zwracających stan informacyjny):
Najwyższy/ najniższy status informacyjny
% obiektów podrzędnych (np. <30% w stanie krytycznym)
Operacji na wartościach numerycznych
Definiowanie stanu usługi i jej komponentów na podstawie obiektów podrzędnych powinno
oferować reguły (dla obiektów zwracających stan liczbowy):
Przeniesienie wartości z obiektu podrzędnego
Wyliczenie wartości: sumy, średniej, max, min, średnia ważona
System musi umożliwiać definiowanie własnych mechanizmów przetwarzania informacji (w tym
przeliczania modelu usług) za pomocą wbudowanego, wewnętrznego języka pozwalającego co
12.
13.
14.
najmniej na wykorzystanie:
kontrola przepływu: if, while
Operacje matematyczne: +,-, *, /, %
Operacje na tekście: łączenie ciągów, zliczanie znaków, porównywanie ciągów, porównywanie
ciągów w oparciu o wyrażenia regularne, zamiana fragmentów ciągu w oparciu o wyrażenia
regularne, „wycianie” tekstu w oparciu o wyrażenia regularne, „wycinanie” tekstu w oparciu o
pozycję, zamiana tekstu na liczbę, zamiana tekstu na tablicę
Operatory porównania: ==, !=, <, >, <=, >=
Pobieranie wartości z baz danych
Pobieranie wartości z XML
Pobieranie wartości ze strony HTML
Pobieranie wartości z WebService
Każdy obiekt (reprezentacja usługi i jej komponentów) musi posiadać atrybut bieżącego statusu
przyjmujący co najmniej 3 wartości:
Prawidłowy
Akceptowalny
Nieprawidłowy (krytyczny)
Moduł monitorowania biznesowego musi umożliwiać definiowanie struktury usług złożonych
(model drzewa usługi) poprzez:
Konsolę operatorską
Interfejs linii poleceń CLI
Automatyczne kreowanie obiektów na podstawie otrzymanych zdarzeń
Automatyczne pobranie danych z zewnętrznych systemów, np. z bazy konfiguracji CMDB
Automatyczne kreowanie obiektów w oparciu o otrzymane zdarzenia powinno bazować na dowolnie
tworzonych regułach – np. wzorcu nazwy obiektu, przynależności do domeny DNS, etc
15.
16.
17.
18.
Moduł monitorowania biznesowego musi oferować śledzenie SLA i KPI.
Moduł monitorowania biznesowego musi umożliwiać definiowanie parametrów SLA co najmniej dla
następujących warunków:
Czas przestoju dla pojedynczej awarii
Sumaryczny czas przestoju dla okna czasowego
Ilość awarii w oknie czasowym
Moduł monitorowania biznesowego musi umożliwiać definiowanie i nadzorowanie parametrów KPI
dla każdego z obiektów tworzących drzewo usługi
Moduł monitorowania biznesowego musi zapewniać możliwość składowania wartości SLA i KPI dla
późniejszego raportowania historycznego
19.
20.
21.
22.
System musi posiadać konsolę operacyjną (operatorską).
Moduł monitorowania biznesowego musi udostępniać interfejs użytkownika (konsolę operatorską)
poprzez przeglądarkę WWW wykorzystującą wyłącznie technologię HTML i/lub java. W
szczególności nie jest dopuszczalne stosowanie rozwiązań flash i sliverlight.
Moduł monitorowania biznesowego musi umożliwiać prezentację na jednym ekranie operatorskim
dowolnych obiektów spośród:
Aktywnego drzewa usług w postaci grafu
Listy usług zawierającej wartości wybranych wskaźników KPI
Listy zdarzeń pochodzącej z podsystemu zdarzeń
Graficznych widoków (dashboard) prezentujące dowolne elementy (np. liczniki dla usługi
najwyższego rzędu)
Wykresów generowanych na podstawie zawartości bazy danych historycznych
Konsola operatorska musi udostępniać możliwość wykonywania akcji inicjowanych przez operatora
(narzędzia dostępne w menu głównym i kontekstowym, uruchamianym prawym przyciskiem
myszki) Uruchamiane narzędzia powinny mieć możliwość zapytania operatora o parametry
wykonania. Administratorzy systemu powinni mieć możliwość tworzenia nowych i modyfikacji
istniejących narzędzi.
23.
24.
25.
26.
27.
28.
29.
Konsola operatorska musi umożliwiać wykonywanie akcji inicjowanych przez operatora (narzędzia
dostępne z menu głównego oraz kontekstowego).
Konsola operatorska musi pozwalać na generowanie treści strony dla użytkownika w wyniku
działania „programów” przygotowanych w wewnętrznym języku oferowanego rozwiązania (o
funkcjonalności opisanej we wcześniejszych wymaganiach), mających dostęp do zdarzeń, modelu
świadczonej usługi, parametrów KPI i SLA. Każdorazowe wywołanie danego URLa musi skutkować
wykonaniem danego programu i wygenerowaniem strony. Strony takie muszą wspierać pełną
interakcję. Mechanizm ten musi być implementowany bezpośrednio wewnątrz oferowanego
rozwiązania, musi być elementem standardowo dostępnym i przygotowanym przez producenta
systemu. W szczególności nie jest akceptowalna realizacja w oparciu o skrypty php/perl itp.
osadzone wewnątrz serwera WWW. Dostęp do takich stron musi być realizowany w oparciu o
standardową autoryzację i autentykację wbudowaną w oferowane rozwiązanie. Administrator musi
mieć możliwość tworzenia nowych „programów” i modyfikowania istniejących z poziomu
standardowego interfejsu WWW oferowanego systemu.
Moduł monitorowania biznesowego musi udostępniać interfejs linii poleceń CLI dla istotnych
funkcji takich jak:
modyfikowanie struktury drzewa usługi,
kreowanie nowych reguł propagacji statusu,
modyfikacja istniejących reguł,
backup konfiguracji
System musi wspierać autoryzację użytkowników i ich grupowanie, Dla każdego użytkownika
powinno być możliwe określanie filtrów na zdarzenia prezentowane przez system (ograniczenie
dostępnych informacji stosownie do poziomu uprawnień użytkownika). W tym celu system musi
pozwalać na tworzenie wewnętrznej bazy użytkowników i uprawnień, musi również pozwalać na
integrację z systemami usług katalogowych.
Moduł monitorowania biznesowego musi mieć możliwość instalacji w trybie zapewniającym
odporność na awarie.
Administrator systemu musi mieć pełną kontrolę nad sposobem analizy drzewa usług, z możliwością
tworzenia dowolnych własnych reguł jego analizy.
System musi posiadać moduł raportowania, z możliwością modyfikacji wbudowanych raportów i
tworzenia nowych.
30.
Tworzenie i modyfikacja raportów nie może wymagać zakupu dodatkowych licencji.
31.
Raporty muszą być renderowane w postaci co najmniej: html, pdf i xls.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
Raporty muszą być generowane na żądanie i według wskazanego harmonogramu.
Moduł raportowy musi pochodzić od producenta oferowanego systemu i musi być w pełni przez
niego wspierany.
System musi posiadać raporty predefiniowane przez producenta systemu.
sposób limitowana
System monitorowania musi posiadać przygotowane przez producenta oprogramowania podręczniki:
języku polskim.
42.
43.
44.
45.
46.
47.
48.
49.
System monitorowania musi być produktem aktualnie dostępnym w ofercie producenta, bez
System monitorowania musi mieć możliwość instalacji swoich komponentów serwerowych
System musi udostępniać ekrany przeznaczone dla urządzeń mobilnych, prezentujących co najmniej
podstawowe metryki i informacje.
Podczas okresu ważności wsparcia producenta dla systemu powinny być zapewnione bezpłatne
System musi obsługiwać nieograniczoną przez zaoferowane licencje liczbę operatorów (ograniczenie
Oferowane licencje nie mogą być okresowe, tymczasowe lub współdzielone, muszą one po zakupie
System monitorowania musi posiadać mechanizmy definiowania portów po których będzie odbywała
się komunikacja systemu z konsolami. Komunikacja taka powinna być możliwa również jeśli na
ścieżce będzie się znajdował odpowiednio skonfigurowany firewall.
d) IBM BigFixLifecycleResource, IBM BigFixComplianceResource, IBM BigFixInventoryResource
oraz IBM Endpoint Manager forServer AutomationResource musi realizować co najmniej
następujące funkcjonalności:
LP
1.
2.
3.
4.
5.
6.
7.
8.
Wymaganie
System umożliwia zarządzanie (ciągłe realizowanie zastosowanych polityk) zarówno na
urządzeniach podłączonych do sieci jak i poza nią.
System umożliwia ciągłe monitorowanie stanu urządzenia (zadanie wykonane, zadanie
nierozpoczęte, wymagany restart, błąd, itp.) Stan wszystkich zadań dla każdego urządzenia jest na
bieżąco aktualizowany na konsoli
System umożliwia obsługiwanie rozproszonego środowiska (lokalizację centralną, rozproszoną
strukturę oddziałową z różnymi typami połączeń) zapewniając zarządzanie XX tysiącami agentów z
poziomu jednego centralnego serwera.
System umożliwia cykliczne wykrywanie urządzeń obecnych w sieci IP z możliwością wskazania
wielu rozproszonych punktów skanowania, określania zakresu skanowanych adresów i portów oraz
centralnego zarządzania zebranymi danymi
Proces umożliwia identyfikację dowolnego urządzenia IP podłączonego do sieci rozpoznając nazwę
hosta, system operacyjny, adres IP, adres MAC, rodzaj urządzenia.
System umożliwia raportowanie różnicowe, tj. prezentowanie na konsoli systemów, które zostały
wykryte w czasie ostatniego skanowania a nie były wykryte wcześniej.
System umożliwia konfigurację agenta tak, aby na bieżąco przekazywał informacje o zmianach
konfiguracji sprzętowej urządzenia do serwera bez konieczności konfigurowania, planowania bądź
wymuszania skanowania sprzętu i bez ingerencji operatora.
Wszelkie informacje o sprzęcie są zapisywane na serwerze obejmując następujące informacje:
Dane z BIOS
Częstotliwość taktowania i typ procesora
Przestrzeń na dysku
Nazwę komputera
Model komputera
Adres IP
System operacyjny
Dołączone urządzenia zewnętrzne
Zainstalowane aplikacje
9.
10.
11.
12.
13.
14.
15.
System umożliwia wykrycie zainstalowanego oprogramowania wraz z informacją o wersjach
zainstalowanych aplikacji.
Wszelkie zmiany w zainstalowanym oprogramowaniu są niezwłocznie i automatycznie wykryte
przez agenta i przesłane na serwer bez ingerencji operatora.
System umożliwia przegląd wszystkich usług uruchomionych na zarządzanym urządzeniu.
System umożliwia sprawdzanie zawartości rejestrów oraz wprowadzanie zmian do rejestrów na
zarządzanych komputerach z systemem Windows.
System umożliwia raportowanie uruchomienia określonych aplikacji na zarządzanych komputerach,
w szczególności na serwerze musi być możliwość określenia ilości równocześnie uruchomionych
aplikacji wskazanego typu.
System zapewnia mechanizm zdalnej instalacji systemów operacyjnych „od zera” na nowym
sprzęcie, jak i reinstalacji systemu operacyjnego na sprzęcie już używanym bez konieczności zakupu
dodatkowego oprogramowania bądź sprzętu.
System wspiera instalację wielu różnych systemów operacyjnych, w szczególności Windows i Linux
17.
System umożliwia instalację systemów operacyjnych na wielu komputerach jednocześnie z
wykorzystaniem mechanizmu multicast
System oferuje gotową procedurę migracji do Windows 7
18.
System oferuje tworzenie i zapamiętywanie wielu wzorcowych obrazów systemów operacyjnych
19.
23.
System umożliwia automatyczne dodawanie do wzorcowych obrazów systemu właściwych
sterowników specyficznych dla sprzętu, na którym odbywa się instalacja
System umożliwia w czasie reinstalacji systemu zapamiętanie danych oraz ustawień użytkownika i
przywrócenie ich na nowym systemie operacyjnym
System umożliwia zdalną instalację oprogramowania bez konieczności zakupu dodatkowego
oprogramowania bądź sprzętu.
System udostępnia z poziomu konsoli łatwy w użyciu mechanizm (kreator) tworzenia własnych
zadań instalacji oprogramowania
System umożliwia zdalną instalację oprogramowania bez ingerencji użytkownika.
24.
System umożliwia ustalenia daty i czasu instalacji każdego oprogramowania oddzielnie.
25.
System umożliwia bieżące monitorowanie procesu instalacji, wszelkie zmiany statusu muszą być
raportowane na serwer w czasie zbliżonym do rzeczywistego (w ciągu pojedynczych minut).
System umożliwia grupowanie zadań instalacji oprogramowania w zbiory i instalowania ich razem w
określonej sekwencji.
System na bieżąco w czasie zbliżonym do rzeczywistego (w ciągu pojedynczych minut) wykrywa,
które urządzenia ukończyły instalacje oprogramowania i czekają na powtórne uruchomienie systemu.
Po ponownym uruchomieniu systemu agent kontynuuje procedurę instalacji tak by wszystkie
wymagane działania zakończyły się powodzeniem i przesłać aktualizacje stanu do serwera.
System umożliwia rozrzucenie czasów instalacji oprogramowania na różnych urządzeniach na
zdefiniowany okres czasu tak by zmniejszyć obciążenie sieci.
System umożliwia zdefiniowanie komunikatu dla użytkownika informującego o instalacji
oprogramowania dla każdego oprogramowania oddzielnie.
System zapewnia mechanizm przejmowania zdalnej konsoli dla systemów Windows i Linux bez
konieczności zakupu dodatkowego oprogramowania bądź sprzętu.
System oferuje pełną audytowalność sesji zdalnej pomocy (z możliwością nagrywania sesji
włącznie)
System wspiera poufność oferując użytkownikom przejmowanej stacji możliwość wskazania okien
aplikacji, które mają być niewidoczne dla osoby wsparcia technicznego
System umożliwia uruchomienie sesji zdalnej konsoli kontekstowo z centralnej konsoli zarządzającej
16.
20.
21.
22.
26.
27.
28.
29.
30.
31.
32.
33.
34.
System umożliwia osobie przejmującej konsolę przelogowanie się na konto innego użytkownika (np.
administratora) bez konieczności rozłączania sesji
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
System posiada wbudowane mechanizmy wykrywania zainstalowanych poprawek bez konieczności
konfigurowania, planowania bądź wymuszania skanowania kontrolowanych urządzeń i bez
ingerencji operatora. Informacja o zmianach w zainstalowanych poprawkach jest niezwłocznie i
automatycznie wykryta przez agenta i przesłana na serwer bez ingerencji operatora w czasie
zbliżonym do rzeczywistego (w ciągu pojedynczych minut).
System korzysta z różnych metod weryfikacji czy poprawka jest zainstalowana na kontrolowanym
urządzeniu, w szczególności przez
Kontrole zawartości rejestru;
Sprawdzenie istnienia stosownych plików;
Kontrolę wersji plików na zarządzanym urządzeniu.
System umożliwia ustalenie zależności pomiędzy poprawkami przed instalacją poprawek na
zarządzanym urządzeniach.
System wykrywa fakt zakończenia instalacji poprawki
System wykrywa fakt zainstalowania nowej poprawki na urządzeniu i traktować takie urządzenie,
jako zaktualizowane.
System jest w stanie stwierdzić czy poprawki zostały zainstalowane poprawnie.
System wykrywa, które poprawki są właściwe dla każdego urządzenia indywidualnie w zależności
od ustawień urządzenia.
System wykrywa fakt uszkodzenia lub odinstalowania poprawki w urządzeniu.
System umożliwia grupowanie poprawek w zbiory np “Krytyczne poprawki czerwcowe”, oraz
grupowania zbiorów w np. „Poprawki pierwszego kwartału”.
System automatycznie pobiera z Internetu informacje o dostępnych nowych poprawkach wraz z
gotowym zadaniem instalacji poprawki, opisem działania, informacją o poziomie ważności oraz
linkiem do strony producenta.
System umożliwia edycję zadań instalacyjnych i dostosowania ich zachowań do polityki firmy.
System zapewnia zarządzanie poprawkami systemowymi dla wszystkich zarządzanych platform
Windows, Mac, Linux (RedHat, SuSE) oraz w przypadku serwerów dla systemu Unix (AIX, Solaris,
HP-UX)
System zapewnia zarządzanie poprawkami i aktualizacjami dla następującego oprogramowania stacji
roboczych:
Adobe Reader, Adobe Flash Player, Adobe Shockwave Player
Oracle Java
Mozilla Firefox
System umożliwia indywidualne ustalenie, które poprawki maja być zainstalowane na wybranych
urządzeniach.
System umożliwia ustalenie daty i czasu instalacji każdej poprawki oddzielnie.
Cały proces instalacji poprawki jest na bieżąco monitorowany i wszelkie zmiany statusu instalacji są
raportowane na serwer w czasie zbliżonym do rzeczywistego (w ciągu pojedynczych minut).
System na bieżąco w czasie zbliżonym do rzeczywistego (w ciągu pojedynczych minut) wykrywa,
które urządzenia ukończyły instalacje poprawki i czekają na powtórne uruchomienie systemu. Po
ponownym uruchomieniu systemu agent kontynuuje procedurę instalacji tak by wszystkie wymagane
działania zakończyły się powodzeniem i przesyła aktualizacje stanu do serwera.
System umożliwia instalowanie wielu poprawek bez konieczności każdorazowego ponownego
uruchamiania sytemu.
System zapewnia możliwość ustawienia szablonu komunikatu dla użytkownika informującego o
instalacji poprawki dla wielu poprawek jak również edycji dla każdej poprawki oddzielnie.
System zapewnia użytkownikowi możliwość odroczenia instalacji poprawki oraz ponownego
uruchomienia systemu.
W przypadku niepowodzenia instalacji poprawki system umożliwia automatyczne powtórzenie
procedury instalacji zadaną ilość razy
System umożliwia tworzenie własnych zadań instalacji poprawek.
57.
System umożliwia składowanie plików instalacyjnych poprawek na przekaźnikach.
58.
System umożliwia zdefiniowanie polityki, która automatycznie dokona instalacji poprawek na
urządzeniach dodanych do systemu już po wydaniu polecenia o instalacji poprawki
System automatycznie usuwa pliki instalacyjne z dysków urządzeń po udanej instalacji.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
Administrator ma możliwość instalacji wybranej poprawki na wszystkich urządzeniach spełniających
zadane kryterium.
Agent przed przystąpieniem do instalacji poprawki każdorazowo sprawdza odpowiedniość poprawki
dla zarządzanego przez niego środowiska.
System umożliwia sekwencjonowanie i kontrolowanie wykonywania operacji na środowiskach
wielowęzłowych jak przykładowo klastry wydajnościowe, klastry wysokiej dostępności, architektury
wielowarstwowe.
System pozwala na definiowanie procesów wykonujących operacje szeregowo lub równolegle.
System dostarcza funkcjonalność pozwalającą na definiowanie operacji kompensacji błędu dla
każdego kroku procesu.
System pozwala na tworzenie procesów uniwersalnych, które są parametryzowane w momencie
uruchomienia w zakresie:
Węzłów, które uczestniczą w procesie
Specyfikację parametrów dla każdego kroku procesu
Definiowanie wartości domyślnych dla poszczególnych parametrów kroków
W przypadku procesów równoległych system pozwala na definiowanie punktów synchronizacji
pozwalających na wiązanie ze sobą poszczególnych operacji równoległych
System posiada wsparcie w automatyzacji zadań wgrywania poprawek dla następujących klastrów:
Microsoft Windows 2003
Microsoft Windows 2008 Release 2
Microsoft Windows 2012 Release 2
Microsoft SQL Server 2008 R2
Microsoft SQL Server 2012
Microsoft SQL Server 2014
Microsoft Exchange 2010
Hiper-V dla Microsoft Windows 2008 Release 2, Microsoft Windows 2012 Release 2
System posiada przykładowe procesy zarządzania, które mogą posłużyć jako wzorce przy tworzeniu
procesów dla innych systemów w zakresie:
Tworzenia serwerów wirtualnych
Tworzenia serwerów fizycznych
Instalacji systemów operacyjnych
Instalacji oprogramowania
Instalacji łat systemu
Instalacji łat oprogramowania
Instalacji środowiska począwszy od wytworzenia maszyny (fizycznej lub wirtualnej), zastosowania
łat systemowych, instalacji oprogramowania i zastosowania łat dla programowania.
System umożliwia w ramach procesów zarządzania środowiskami wielowęzłowymi zarządzanie
zasobami środowiska zwirtualizowanego VMWare w zakresie
Tworzenia, kasowania maszyny wirtualnej z ISO
Modyfikowania parametrów maszyny wirtualnej
Zarządzania obrazami ISO w ramach VMWare
Tworzenia szablonów maszyn wirtualnych poprzez klonowanie lub konwertowanie maszyny do
szablonu
Tworzenie, usuwanie migawek (snapshot)
Przywracania migawki
Zarządzanie stanem maszyny wirtualnej jak: startowanie, stopowanie (soft, hard), restartowanie (soft,
hard), wstrzymywanie (soft, hard).
System pozwala na zaplanowanie czasu wykonania definiowanego procesu.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
System pozwala na wykorzystanie rozwiązania Chef-Solo do realizacji poszczególnych kroków
procesu
System udostępnia REST API pozwalające na zdalne wywoływanie operacji związanych z
zarządzaniem procesami.
System umożliwia definiowanie polityk bezpieczeństwa i zgodności
System umożliwia weryfikowanie zdefiniowanych polityk zarówno na urządzeniach podłączonych
do sieci jak i poza nią
System umożliwia wymuszanie zgodności ze zdefiniowanymi politykami zarówno na urządzeniach
podłączonych do sieci jak i poza nią poprzez kontrolowanie i automatyczne wprowadzanie
odpowiednich ustawień
System umożliwia tworzenie dowolnej liczby zestawów polityk zgodności i przypisywania ich do
odpowiednich grup komputerów statycznie lub dynamicznie, na przykład na podstawie właściwości
komputera lub jego konfiguracji (na przykład podłączenie do określonej sieci)
System udostępnia raporty zgodności pokazujące statystyki zgodności zarządzanych komputerów ze
zdefiniowanymi politykami
Raporty zgodności przechowują i udostępniają dane historyczne związane z przestrzeganiem polityk
zgodności przez zarządzane komputery.
Raporty zgodności zawierają następujące raporty:
Raport główny pokazujący aktualny status zgodności poprzez informacje statystyczne wraz z
informacją o trendach
Raporty zgodności dla poszczególnych zestawów polityk
Raporty zgodności dla poszczególnych komputerów oraz grup komputerów
Raporty zgodności dla pojedynczych punktów weryfikacji zgodności
Raporty o zdefiniowanych wyjątkach
Raporty pozwalają na przechodzenie z wyższego poziomu ogólności do niższego poziomu w celu
analizy
Raporty zgodności pozwalają na filtrowanie danych zarówno czasowe jak i bazujące na
właściwościach wyświetlanych obiektów (polityk, komputerów) jak i zawartości informacyjnej.
Raporty zgodności pozwalają na zapisywania konfiguracji filtrów oraz zawartości do późniejszego
użycia.
System udostępnia moduł skanowania dysków komputerów w poszukiwaniu plików wykonywalnych
i mapowania znalezionych plików na oprogramowanie w oparciu o dostarczoną bazę sygnatur.
System umożliwia podanie liczby posiadanych licencji dla danego oprogramowania (liczonych per
zainstalowana kopia) i raportowanie różnicy pomiędzy stanem posiadanym a zainstalowanymi
kopiami
System umożliwia przypisywanie posiadanych licencji do grup komputerów i wykrywanie, jeśli
oprogramowanie zostało zainstalowane na komputerach spoza uprawnionej grupy
System umożliwia elastyczne definiowanie harmonogramu skanowania, w szczególności określenie
czasu, po jakim dane z danego komputera mają być automatycznie odświeżone (tj. zeskanuj
komputer, jeśli dane były zebrane ostatnio dawniej niż 3 dni temu)
System zapewnia aktualizowany przynajmniej w cyklu miesięcznym katalog sygnatur
oprogramowania. Katalog zawiera powiązania pakietów oprogramowania (np. Word, Excel,
k również hierarchiczną relację wersji oprogramowania (Acrobat Reader 8.1,
91.
Redear)
System udostępnia możliwość przeglądania znalezionego oprogramowania dla każdego komputera,
jak również w formie zagregowanej – np. dla różnych producentów oprogramowania czy różnych
wersji oprogramowania
System umożliwia łatwe dodawanie własnych wpisów do katalogu, w szczególności na podstawie
znalezionych, a niesklasyfikowanych plików wykonywalnych. Umożliwia również tworzenie
własnych pakietów oprogramowania z wykorzystaniem istniejących i nowo dodawanych sygnatur
System umożliwia elastyczne filtrowanie danych w interfejsie graficznym poprzez wybór kolumn
oraz określanie filtrów
System umożliwia eksportowanie danych do zewnętrznych narzędzi.
92.
System udostępnia moduł raportowania dostępny z poziomu przeglądarki internetowej.
88.
89.
90.
93.
94.
95.
96.
97.
98.
99.
System umożliwia tworzenia własnych kwerend bazując na dowolnych informacjach przesłanych
przez agentów
Uprawnienia dostępu do modułu raportującego są niezależne od uprawnień do administrowania
systemem.
Moduł raportujący oferuje gotowe raporty, w szczególności zapewniające informacje o:
Zainstalowanych i brakujących poprawkach
Pełnej liści zarządzanych urządzeń wraz z rozbiciem i sortowaniem po właściwościach ustawionych
na konsoli zarządzającej
Konfiguracji sprzętu i oprogramowania na wszystkich zarządzanych urządzeniach.
Moduł raportujący umożliwia użytkownikowi tworzenie i zapamiętywanie graficznych raportów.
Moduł raportujący oferuje wzorce raportów, które mogą być zmieniane i zapamiętywane przez
użytkownika.
Zmienianie i zapamiętywanie stworzonych raportów odbywa się bez konieczności zakupu
Moduł raportujący oferuje filtrowanie informacji w raportach.
100. Moduł raportujący oferuje „poziomowanie” raportów tak by było możliwe przechodzenie z ogólnego
widoku do widoku bardziej szczegółowego poprzez wskazanie na kategorie, która chcemy
dokładniej zdiagnozować.
101. Moduł raportujący oferuje ustawienie czasu, kiedy raporty będą generowane.
102. Moduł raportujący oferuje powiadamiane użytkowników o spełnieniu zadanych warunków.
103. Moduł raportujący oferuje obrazowanie wybranych urządzeń innym kolorem w zależności od
zadanego kryterium np. ilość miejsca na dysku, wykryta podatność itp.
104. Moduł raportujący oferuje hierarchiczną wizualizację zarządzanych urządzeń bazując na
odczytanych właściwościach takich jak ścieżka AD, podsieć IP itp.
105. System zapewnia integralność poleceń wysyłanych do zarządzanych urządzeń poprzez podpisywane
cyfrowe wszystkich poleceń.
106. System chroni integralność przesyłanych treści poprzez sumy kontrolne tak by istniała pewność, iż
binaria pobrane przez urządzenia zarządzane nie zostały zmodyfikowane bądź uszkodzone.
107. System oferuje szyfrowanie komunikacji pochodzącej od agentów bez potrzeby zakupu
108. System zawiera wbudowany mechanizm klucza publicznego PKI nie wymagając zakupu
certyfikatów zewnętrznych.
109. Agent Systemu wykonuje zadane polityki w sposób ciągły bez względu na stan połączenia z siecią.
110. System posiada wbudowany mechanizm failover dla serwera (umożliwiający zdefiniowanie serwera
zapasowego, który przejmie pracę w razie awarii serwera podstawowego)
111. System umożliwia elastyczne definiowanie ścieżek komunikacji poprzez definiowanie hierarchii
komunikacji pomiędzy agentami, przekaźnikami oraz serwerem, w szczególności umożliwia
ustawienie na agencie automatycznego wyszukiwania najbliższego przekaźnika
112. Agent dynamiczne łączy się z najbliższym przekaźnikiem w przypadku, gdy przypisany mu
przekaźnik jest niedostępny.
113. System umożliwia kontrolę uprawnień użytkownika konsoli do zarządzania określonymi grupami
agentów
114. System posiada mechanizm silnego uwierzytelnienia wymuszając stosowanie prywatnego klucza do
podpisywania akcji podejmowanych przez administratora.
115. System umożliwia konfigurację uprawnień administratorów tak by mogli tworzyć własne polityki i
akcje dla agentów, bądź mogli jedynie korzystać z polityk stworzonych bądź zatwierdzonych przez
innych administratorów. (Mechanizm podziału uprawnień).
116. System umożliwia tworzenie zbiorów zadań wykonywanych razem w określonej sekwencji
zawierających wcześniej zdefiniowane polityki.
117. System umożliwia tworzenie zbiorów zadań zaaprobowanych tak, aby tylko zadania zaaprobowane
mogły być wysłane do agentów przez administratorów uprawnionych do zarządzania agentami.
118. Każdy z administratorów może posiadać unikalny login, indywidualne hasło oraz klucz prywatny.
119. System posiada możliwość przeglądania i eksportu wszystkich działań podjętych na wszystkich
konsolach zarządzających przez wszystkich administratorów/operatorów.
120. System oferuje zarządzanie wszystkimi agentami z jednej konsoli. Dostępne zadania obejmują:
Zdalne odinstalowanie agentów;
Konfiguracje wszelkich ustawień agenta;
Przypisanie agentów do przekaźników (relay);
Podnoszenie wersji agentów.
121. System oferuje monitorowanie wszystkich agentów z jednej konsoli. Monitoring obejmuje:
Czas ostatniego raportu przekazanego przez agenta;
Dostępność każdego agenta;
Przekaźnik przypisany do każdego agenta;
Wersję każdego agenta.
122. Administrator ma możliwość dostosowania ustawień konsoli do swoich potrzeb poprzez dodawanie i
usuwanie kolumn.
123. Konsola umożliwia definiowanie dowolnych danych, które mają być zbierane z agentów i które będą
dostępne w interfejsie umożliwiając np. dynamiczne grupowanie agentów.
124. Konsola umożliwia definiowanie grup statyczne oraz dynamicznych w oparciu o dowolne dane
zbierane z agentów.
125. Konsola umożliwia operatorom tworzenie własnych zadań dla agentów
e)
IBM SmartCloud Virtual Storage Center musi realizować co najmniej następujące funkcjonalności:
Wymaganie
LP.
System musi umożliwiać pełną analizę (wykrywanie przyczyn źródłowych) problemów
1 dostępnościowych, wydajnościowych i pojemnościowych na systemach pamięci masowej
System musi wspierać monitorowanie i konfigurowanie urządzeń różnych producentów
2 wykorzystując standardowe protokoły i specyfikacje: SNIA/ SMI-S oraz SNMP
System musi wspierać wykrywanie topologii i zarządzanie środowiskami pamięci masowych
3 wykorzystującymi protokoły FC, FCoE oraz iSCSI
System musi zbierać, monitorować oraz wizualizować wszelkie udostępniane za pomocą
4 standardowych protokołów metryki pojemnościowe, wydajnościowe i dostępnościowe
System musi prawidłowo interpretować metryki pojemnościowe macierzy dyskowych i
5 wirtualizatorów (np. SVC) w przypadku trybu Thin Provisioning
System musi rozwiązywać pełną ścieżkę dostępu do danych od hosta do dysku z uwzględnieniem
wirtualizatorów (SVC,ESX itp.) znajdujących się po drodze. Informacja o poszczególnych
urządzeniach, WWN i numerach portów biorących udział w danej ścieżce musi być dostępna przez
6 mapę topologii oraz w postaci tabelarycznej
System musi pozwalać na ustawienie częstotliwości próbkowania i kolekcjonowania danych oraz
7 tworzenia agregatów danych z uśrednianiem po zadanym oknie czasowym
System musi rejestrować zmiany konfiguracji i umożliwiać raportowanie o zmianach w zadanym
przedziale czasowym. Musi istnieć możliwość zdefiniowania częstotliwości rejestrowania zmian oraz
8 długości przechowywanej historii.
System musi automatycznie (zgodnie z harmonogramem) oraz na żądanie inwentaryzować sprzęt
9 SAN i odczytywać dane pojemnościowe i konfiguracyjne.
10
System musi rozpoznawać automatycznie topologię połączeń, wizualizować ją w postaci mapy oraz
tabel. Na mapie muszą być wizualizowane alerty, awarie oraz musi ona umożliwiać przeglądanie w
trybie drill-down, czyli podgląd szczegółowych statystyk wybranych na mapie urządzeń
System musi posiadać predefiniowane raporty umożliwiające analizę przyczyn źródłowych
11 problemów oraz raporty typu top N dla różnych kategorii metryk.
System musi umożliwiać samodzielne tworzenie raportów. Funkcjonalność ta musi być dostępna
12 przez interfejs web (http/https).
System musi umożliwiać wizualizację wartości pochodnych (np. średnich, median) dostępnych
13 metryk.
System musi mieć możliwość eksportu raportów oraz samych danych (metryk) do formatów - PDF,
14 CSV.
System musi umożliwiać ustawianie progów (trigger/threshold) dla wartości metryk oraz ich
15 agregatów (np. sum różnych metryk itp.)
16 System musi umożliwiać automatyczne powiadamianie (e-mail, SNMP trap) o przekroczeniu progów.
17 System musi przewidywać przyszłe wartości (dopasowanie trendów do danych) na wykresach.
System musi udostępniać interfejs przez przeglądarki web/http. Wspierane muszą być min. Firefox,
18 Chrome oraz MS IE.
19 System musi umożliwiać określenie uprawnień użytkowników do poszczególnych funkcji.
System musi umożliwiać zdefiniowanie min. 10 klas wydajnościowych (ang. tiers) oznaczonych
kolejnymi numerami od 0-9 lub od 1-10 do których można przypisywać pule fizycznych urządzeń
20 dyskowych (macierzy RAID)
System musi umożliwiać zdefiniowanie co najmniej 30 klas usługowych dostarczania przestrzeni
dyskowej identyfikowanych tekstowymi etykietami, czyli pre-definiowanych zestawów parametrów
takich jak zakres klas wydajnościowych, rodzaj alokacji (thin/thick), poziom zabezpieczenia RAID,
optymalizacja I/O dla określonego typu obciażenia (np. odczyt/zapis; losowy/sekwencyjny). W
momencie tworzenia zasobu dyskowego dla określonego hosta musi być możliwe wybranie
21 zdefiniowanej wcześniej klasy usługowej.
System musi umożliwiać analizę wydajnościową woluminów (LUN) w poszczególnych klasach
wydajnościowych i generować rekomendację ich optymalnego przypisania do tych klas. Wdrożenie
tak wygenerowanych rekomendacji musi być możliwe zarówno na żądanie jak i w trybie
22 automatycznym.
System musi umożliwiać analizę wydajnościową grup dyskowych i generować rekomendację migracji
woluminów (LUN) w obrębie tych samych klas wydajnościowych aby osiągnąć zrównoważenie
obciążenia grup dyskowych w obrębie danej klasy wydajnościowej. Wdrożenie tak wygenerowanych
23 rekomendacji powinno być możliwe zarówno na żądanie jak i w trybie automatycznym.
System mu zawierać moduł sterujący wykonywaniem migawkowych kopii dysków SAN wspierający
woluminy obsługiwane przez następujące urządzenia: SVC, Storwize7000, IBM DS8000. Moduł ten
musi zapewniać wykonywanie kopii migawkowych przy działającym oprogramowaniu RDBMS
server zawierających spójny obraz bazy danych DB2, Oracle, MS SQL, MS Exchange. Powinien
również sterować zamontowaniem powstałej kopii migawkowej do dodatkowego systemu z
24 oprogramowaniem zarządzającym danymi w celu wykonania kopii zapasowej z jej wykorzystaniem.
25 System musi zawierać moduł wirtualizacji pamięci masowych.
System wirtualizacji musi umożliwiać stworzenie co najmniej 4 niezależnych instacji klastra
rozmieszczonych w różnych serwerowniach z dowolnym/elastycznym przypisaniem zakupionych
licencji na pojemność klastra. Musi również istnieć możliwość dynamicznej zmiany ilości
przypisanych licenncji do klastrów w trakcie działania systemu przy zachowaniu sumarycznej
26 zakupionej liczby licencji.
27 System musi się harakteryzować brakiem pojedynczego punktu awarii.
28
System musi mieć możliwość zarządzania całością dostępnych zasobów dyskowych w ramach klastra
z jednej konsoli administracyjnej, funkcjonalność zarządzania poprzez interfejs WWW oraz interfejs
linii poleceń (Command Line Interface) - dostęp do linii poleceń poprzez połączenie szyfrowane.
System musi posiadać funkcjonalność separacji przestrzeni dyskowych pomiędzy różnymi
29 podłączonymi hostami.
30 System musi posiadać funkcjonalność zwiększania i zmniejszania rozmiaru wolumenów.
31
System musi posiadać funkcjonalność zarządzania ilością operacji wejścia wyjścia wykonywanych na
danym wolumenie - zarządzanie musi być możliwe zarówno poprzez określenie ilości operacji I/O na
sekundę jak również przepustowości określonej w MB/s.
System musi posiadać możliwość rozłożenia wolumenu logicznego pomiędzy co najmniej dwoma
32 różnymi typami macierzy dyskowych.
System musi posiadać możliwość wykonanywania kopii danych typu snapshot (PIT) pomiędzy
różnymi typami macierzy dyskowych. Zasoby źródłowe kopii PiT oraz docelowe kopii PiT mogą być
zabezpieczone różnymi poziomami RAID i egzystować na różnych technologicznie dyskach stałych
(FC, SAS, SSD, SATA), pracujących pod kontrolą różnych systemów dyskowych zarządzanych przez
system wirtualizacji. Kopie danych typu PIT muszą być tworzone w trybach incremental, multitarget
(co najmniej 256 kopii z pojedynczego wolumenu), kopii pełnej oraz kopii wskaźników, przy czym
dostęp do kopii musi być możliwy natychmiast po jej zainicjalizowaniu zarówno w odniesieniu do
33 kopii wskaźników jak i kopii pełnej.
System musi obsługiwać grupy spójności (konsystencji) wolumenów (jeżeli jest wymagana licencja,
34 należy dostarczyć licencje na całość wirtualizowanych zasobów).
System musi posiadać funkcjonalność tworzenia mirrorowanych LUN, dla których awaria jednej kopii
35 lustra musi być niezauważalna dla systemu hosta.
System musi posiadać funkcjonalność tworzenia wolumenów (LUN) typu Thin provisioned tzn.
prezentujących dla hostów większą przestrzeń dyskową niż rzeczywiście dostępna przestrzeń
fizyczna, z możliwością automatycznego zwiększenia fizycznej zajętości przestrzeni dyskowej w
sytuacji, gdy rozmiar wymaganej do zapisu danych przestrzeni przewyższy rozmiar przestrzeni
36 zaalokowanej przy tworzeniu wolumenu.
System musi posiadać funkcjonalność optymalizacji wykorzystania dysków SSD i HDD poprzez
automatyczną identyfikacje najbardziej obciążonych fragmentów wolumenów, a następnie migrację
tych fragmentów na szybszy nośnik. Pojedyńczy wolumen musi mieć możliwość rozłożenia pomiędzy
37 3 różnymi rodzajami dysków: SSD, HDD 15/10 k RPM i HDD 10/7,2 k RPM.
System musi posiadać funkcjonalność optymalizacji wykorzystania dysków SSD/HDD, tak aby w
ramach tego samego rodzaju dysków (pojemności/prędkości) wszystkie składowe grupy dyskowe
38 były utylizowane w równym stopniu.
System musi posiadać możliwość wykonania migracji wolumenów logicznych pomiędzy różnymi
typami macierzy dyskowych, bez zatrzymywania aplikacji korzystającej z tych wolumenów - zasoby
źródłowe podlegające migracji oraz zasoby do których są migrowane mogą być zabezpieczone
różnymi poziomami RAID i egzystować na różnych technologicznie dyskach stałych (FC, SAS, SSD,
39 SATA).
System musi posiadać sterowniki do obsługi wielościeżkowego dostępu do wolumenów, awarii
40 ścieżki i rozłożenia obciążenia po ścieżkach dostępu dla podłączanych systemów operacyjnych.
System musi posiadać wsparcie min. dla systemów operacyjnych:Microsoft Windows 2008-2012,
41 VMware vSphere 5.x.
System musi posiadać możliwość wirtualizacji zasobów znajdujących się na na macierzach różnych
42 producentów, minimum: EMC; NetApp; HDS; IBM; HP.
System musi posiadać możliwość wirtualizacji zasobów znajdujących się na macierzach różnych
producentów w trybie natywnym tzn. takim, w którym dane w przypadku awarii wirtualizatora mogą
43 być odczytane bez jego udziału.
System musi zostać dostarczony z kompletem licencji wymaganych dla replikacji synchronicznej i
44 asynchronicznej, wykorzystywania migawek dla wymaganej pojemności zwirtualizowanej.
System wirtualizacji musi umożliwiać analizę wydajnościową zasobów dyskowych. System w
przypadku wykrycia problemów wydajnościowych musi generować rekomendacje do migracji LUNów do mniej obciążonych grup dyskowych. Wdrożenie tak wygenerowanych rekomendacji powinno
45 być możliwe zarówno na żądanie jak i w trybie automatycznym.
Oferowany system musi posiadać funkcjonalność kompresji danych w trybie inline dla dostępu
blokowego na 20TiB danych po kompresji. Uruchomienie funkcjonalność kompresji danych w trybie
inline nie może wpływać negatywnie na wydajność wirtualizatora (dopuszczalne jest zastosowanie
46 dedykowanych kart kompresujących).
f)
Lp.
IBM Spectrum Protect musi realizować co najmniej następujące funkcjonalności:
Minimalne parametry techniczne
1.
Obsługa urządzeń taśmowych i dyskowych do przechowywania kopii zapasowych i archiwizacji
danych.
2.
Przechowywanie konfiguracji polityk zabezpieczeń oraz informacji o wykonanych kopiach,
harmonogramach oraz nośnikach w relacyjnej bazie danych. Proces tworzenia kopii zapasowej oraz
odtwarzania danych powinien być procesem transakcyjnym. Ze względów bezpieczeństwa system
powinien mieć możliwość wykonania mirroring’u tej bazy danych, przynamniej na poziomie logów
transakcyjnych. Jednocześnie musi istnieć możliwość wykonani kopii zapasowej na urządzenia
taśmowe oraz dyskowe w trakcie pracy systemu bez konieczności ograniczania jego funkcjonalności.
3.
System backupu musi w sposób automatyczny i bezobsługowy optymalizować parametry pracy
swojej bazy danych.
4.
Możliwość definiowania w sposób centralny polityki tworzenia kopii zapasowych, tj. określenia, jakie
dane, kiedy i gdzie powinny być składowane (definiowanie harmonogramu Backup’u).
5.
Możliwość realizowanie raz zdefiniowanej polityki backupu w sposób automatyczny, bez
konieczności ingerencji operatora. System powinien umożliwić także wykonywanie określonej akcji
(uruchomienie polecenia lub skryptu) na zabezpieczanym systemie, przed i po zadaniu backupowym
(np. zatrzymanie procesów, wykonanie backupu i ponowne uruchomienie).
6.
Wykonywanie kopii zapasowych w sposób przyrostowy – pierwsza kopia powinna być kopią
całkowitą a kolejne powinny zawierać jedynie dane, które uległy modyfikacji.
7.
Możliwość zdefiniowania czasu ważności kopii danych, tj. czasu po którym kopie te zostaną
automatycznie usunięte.
8.
Możliwość jednoczesnego tworzenia kopii zapasowych na różnego rodzaju nośniki (taśmy, dyski).
9.
Możliwość definiowanie maksymalnej ilości wersji zabezpieczanych plików. W razie przekroczenia
limitu z repozytorium powinny być usuwane wersje najstarsze.
10.
Możliwość jednoczesnego tworzenia kopii zapasowych z wielu klientów (zasobów) na urządzenia
dyskowe. System bez ingerencji operatora powinien przenieść dane z dysków na taśmy w przypadku
osiągnięcia zdefiniowanego poziomu wypełnienia przestrzeni dyskowej serwera kopii zapasowych.
11.
Możliwość wykorzystania wielu strumieni zapisu podczas procesu tworzenia kopii zapasowej bazy
danych serwera kopii zapasowych
12.
Wbudowana możliwość stosowania kompresji kopii zapasowych bazy danych serwera kopii
zapasowych.
13.
Możliwość automatycznego wykonywania uaktualnienia oprogramowania klienta backupu i
zarządzania tym procesem z centralnej konsoli
14.
Możliwość zapisu danych podczas wykonywania kopii zapasowej na co najmniej 2 urządzenia (dwa
obszary składowania danych).
15.
Automatyczne defragmentowanie danych na taśmach.
Lp.
16.
Możliwość utworzenia dodatkowego obszaru składowania danych na wybranym urządzeniu
(systemie dyskowym, bibliotece taśmowej lub wirtualnej bibliotece taśmowej - VTL), zawierającego
wyłącznie aktualne (lub najnowsze) wersje istniejących plików na zabezpieczanych systemach.
Proces uaktualniania tego dodatkowego składowiska kopii powinien odbywać się automatycznie,
bez konieczności komunikacji pomiędzy serwerem backupów i systemem zabezpieczanym
(korzystając z danych już zeskładowanych w systemie kopii zapasowych). W przypadku
przechowywania danych na taśmach system powinien umożliwiać przeprowadzenie tego procesu
bez konieczności wykorzystania (tymczasowego lub stałego) przestrzeni dyskowej.
17.
Tworzenie dodatkowych instancji kopii zapasowych oraz archiwalnych w celu zabezpieczenia przed
uszkodzeniem urządzenia dyskowego lub nośnika magnetycznego używanego do przechowywania
kopii zapasowych.
18.
Zarządzanie politykami retencji na poziomie grup systemów, pojedynczych systemów, systemów
plików/woluminów dyskowych, katalogów, pojedynczych plików i obiektów, wzorców nazw plików i
ścieżek dyskowych.
19.
Możliwość odzyskania danych dostępnych na chronionym systemie w określonym punkcie w czasie
(w zakresie polityki retencji).
20.
Możliwość wznowienia przerwanego zadania odtwarzania z pominięciem już odtworzonych danych.
21.
System oprócz backupu i odtwarzania danych musi realizować funkcje archiwizacji danych –
tworzenia kopii przechowywanej przez określony czas niezależnie od zmian na systemie chronionym,
z możliwością przeniesienia danych do systemu kopii zapasowych (skasowania danych na systemie
chronionym po utworzeniu ich kopii archiwalnej w systemie kopii zapasowych).
22.
Odtwarzanie danych na inny niż źródłowy system, katalog lub z nową nazwą pliku.
23.
Tworzenie i odtwarzanie kopii zapasowych z wykorzystaniem SAN (Storage Area Network) – dane
będą przesyłane do i z- serwera kopii zapasowych bez obciążania LAN (sieci TCP/IP).
24.
Możliwość integracji z mechanizmami sprzętowego szyfrowania nośników taśmowych
25.
Możliwość nieodwracalnego usunięcia kopii danych z systemu przez zamazanie nośników
magnetycznych.
26.
Możliwość komunikacji z klientem systemu kopii zapasowych za pomocą protokołu SSL.
27.
Możliwość jednoczesnego zapisu i odczytu danych z dyskowych urządzeń składowania.
28.
Możliwość odtworzenia pojedynczego obiektu z Microsoft Active Directory bez restartu serwera
29.
Możliwość minimalizacji redundancji danych przesyłanych z klientów systemu kopii zapasowych
(twz. deduplikacja danych na systemie źródłowym) – mechanizm musi być wbudowany w
oprogramowanie
30.
Możliwość automatycznej minimalizacji redundancji danych składowanych po stronie serwera (tzw.
deduplikacja danych na systemie docelowym) – mechanizm musi być wbudowany w
oprogramowanie
31.
Monitorowanie i raportowanie o zadaniach (harmonogramach) oraz o wykorzystaniu zasobów
systemowych i zarządzanych pamięci masowych.
32.
Możliwość definiowania kryteriów alarmów na podstawie dowolnych danych systemu backupu.
33.
Możliwość tworzenie kopii zapasowych bez wstrzymywania dostępu (on-line) dla baz danych DB2,
Informix
Lp.
34.
System powinien obsługiwać wykonywanie zapasowych kopii danych składowanych na urządzeniach
typu NAS, używających protokołu NDMP
35.
Możliwość replikowania danych (kopii zapasowych i archiwów) zgromadzonych na serwerze kopii
zapasowych na zdalny serwer kopii zapasowych w trybie przyrostowym, za pośrednictwem sieci
TCP/IP.
36.
Możliwość zastosowania innych parametrów retencji dla repliki opisanej w poprzednim punkcie niż
dla podstawowej instancji zarządzanych kopii i archiwów.
37.
Automatyczne przełączanie klienta kopii zapasowych do serwera zawierającego replikę jego kopii w
razie braku dostępności serwera głównego lub braku dostępu do kopii przez niego obsługiwanych.
38.
Możliwość tworzenia zapasowego zestawu danych (tzw. kopii off-site) pozwalających na
odtworzenie z nich kompletnego środowiska systemu archiwizacji i zarządzania kopiami zapasowymi
w przypadku awarii serwera tego środowiska. Automatyczne zarządzanie tym procesem w celu
utrzymania aktualności danych. W przypadku użycia nośników wymiennych (taśm magnetycznych) –
zarządzanie rotacją on-site/off-site oraz rejestrowanie etykiet użytych nośników w celu ułatwienia
odzyskania konfiguracji serwera kopii zapasowych i zarządzanych przez niego danych w razie jego
awarii.
39.
Możliwość tworzenie kopii zapasowych bez wstrzymywania dostępu (on-line) dla baz danych
MSSQL, Oracle
40.
Możliwość tworzenie kopii zapasowych tzw. On-linie z serwera pocztowego MS Exchange, bez
konieczności zatrzymywania pracy serwera
41.
Możliwość odzyskiwania pojedynczych obiektów MS-Exchange (skrzynek pocztowych, e-maili,
załączników) bez konieczności odtwarzania całych baz danych.
42.
Możliwość ciągłego zabezpieczenia danych ze stacji roboczych (tworzenia kopii zapasowej w
momencie modyfikacji pliku).
43.
Możliwość integracji z VCB (VMware Consolidated Backup), vStorage API oraz możliwość
odtworzenia wirtualnych maszyn z poziomu klienta systemu backupu.
44.
Możliwość integracji z technologią CBT (changed block trakcing) środowiska vSphere oraz VMware
ESX.
45.
Możliwość wykonywania wyłącznie przyrostowych kopii zapasowych maszyn wirtualnych środowiska
VMware/vSphere, bez konieczności okresowego wykonywania kopii pełnych.
46.
W przypadku wykonywania kopii zapasowych danych serwerów MS Exchange oraz MS SQL
obsługiwanych przez serwery wirtualne VMware/vSphere, oprogramowanie musi zapewniać, jako
integralną funkcję, czyszczenie logów transakcyjnych serwerów zarządzających danymi
(odpowiednio MS Exchange lub MS SQL) w wypadku poprawnego wykonania kopii maszyny
wirtualnej obejmującej spójną kopię baz danych.
47.
W przypadku wykonywania kopii zapasowych danych serwerów MS Exchange oraz MS SQL
obsługiwanych przez serwery wirtualne VMware/vSphere, oprogramowanie musi zapewniać, jako
integralną funkcję granularne odzyskiwanie danych z dokładnością - odpowiednio, co do tabel
MSSQL lub pojedynczych wiadomości zarządzanych przez MS Exchange, z kopii zapasowych obrazów
całych maszyn wirtualnych wykonywanych za pomocą VADP - bez konieczności wykorzystywania w
procesie wykonywania kopii zapasowych oprogramowania klienckiego instalowanego na maszynach
wirtualnych.
Lp.
48.
Możliwość testowego uruchomienia maszyny wirtualnej z obrazu znajdującego się w repozytorium
kopii zapasowych - z wykorzystaniem montowania obrazu za pomocą iSCSI, bez przesyłania czy
odtwarzania danych na dyski ("data store") zarządzane przez VMware ESX/vSphere.
49.
Możliwość szybkiego uruchomienia odtwarzanej maszyny wirtualnej zanim jej dane zostaną
przeniesione na dyski ("data store") zarządzane przez VMware ESX/vSphere, poprzez wykorzystanie
montowania wirtualnych woluminów iSCSI oraz technologii vMotion.
50.
Możliwość zarządzania wykonywaniem kopii zapasowych maszyn wirtualnych VMware/vSphere za
pomocą dodatku ("plug-in") instalowanego w konsoli graficznej vCenter.
51.
Możliwość zarządzania wykonywaniem kopii zapasowych maszyn wirtualnych VMware/vSphere za
pomocą interfesju WWW.
52.
Możliwość wykonywania kopii maszyn wirtualnych zarządzanych przez Microsoft Hyper-V w trybie
przyrostowym.
53.
Dostarczone licencje muszą umożliwiać obsługę co najmniej 200 napędów taśmowych,
54.
Dostarczone licencje muszą umożliwiać obsługę co najmniej 5000 slotów w bibliotece taśmowej
55.
Dostarczone licencje muszą zapewnić możliwość składowania danych w ilości 65 TB po stronie
danych źródłowych bez ograniczenia ilości backupowanych serwerów.
56.
Wszystkie ww. funkcjonalności muszą być objęte licencjami (w ramach limitu rozmiaru
składowanych kopii zapasowych).

Postępowanie prowadzone w trybie przetargu nieograniczonego pn

Transkrypt

Podobne dokumenty

Tworzenie kopii zapasowych

Untitled

PLAN TWORZONYCH KOPII BEZPIECZEŃSTWA Nazwa

KOPIARKA TOSHIBA 1370

Kopie zapasowe i archiwizacja

Wydawnictwo Helion

upoważnienie do wydania wyniku / kopii dokumentacji medycznej

Kopie zapasowe w PostgreSQL (kod: PgSQL Backup)