Załącznik E do SIWZ z dnia 26.08.2016 r.

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) Zamawiający posiada następujące licencje na oprogramowanie:
a) 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) IBM Tivoli Application Dependency Discovery Manager Resource
c)
IBM Tivoli Business Service Manager Tier 1 Resource
d) IBM
BigFixLifecycleResource,
IBM
BigFixComplianceResource,
IBM
BigFixInventoryResource oraz IBM Endpoint Manager for Server AutomationResource
e) IBM SmartCloud Virtual Storage Center (VSC).
f) IBM Spectrum Protect
Zamawiający nie wyraża zgody na wymianę powyższego oprogramowania na inne w ramach realizacji
niniejszego zamówienia. Zamawiający jedynie wymaga rozbudowy Systemu Monitorowania
Infrastruktury oraz Systemu Bazy CMDB o kolejne licencje.
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 wskazany w pkt 1), 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
dla produktów:
Str. 1
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.
W zakresie narzędzia IBM Tivoli Netcool/Impact Base Install oraz IBM Tivoli
Netcool/Impact Tier 1 Resource, narzędzie równoważne musi:
1.
Współpracować z oferowanym rozwiązaniem do przetwarzania zdarzeń.
2.
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
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, „wycinanie” tekstu w oparciu o
wyrażenia regularne, „wycinanie” tekstu w oparciu o pozycję, zamiana tekstu na
liczbę, zamiana tekstu na tablicę
3.
4.
5.
6.
7.
8.
9.
Str. 2




10.
11.
12.
13.
14.
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 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.
Str. 3
18. Dla oferowanego systemu muszą być dostępne dedykowane, dostarczane przez
producenta oprogramowania szkolenia - prowadzone w Polsce
19. System musi mieć możliwość instalacji swoich komponentów serwerowych
(nadzorujących pracę agentów, raportujących i bazodanowych) w środowisku
zwirtualizowanym.
20. System musi obsługiwać nieograniczoną przez zaoferowane licencje liczbę operatorów
(ograniczenie powinno być jedynie na bazie wydajności platformy sprzętowej)
21. 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.
22. Moduł musi posiadać mechanizm pozwalający na wykrycie niedostępności każdego z
komponentów.
ii.
W zakresie narzędzia IBM Netcool Network Management Entry Device Resource,
IBM Netcool Network Management Base Install, narzędzie równoważne musi:
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
Str. 4
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
Pobieranie czasu i daty, konfigurowalna zamiana reprezentacji tekstowej czasu i daty na
wartość numeryczną (np. unixtime)
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
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ą.
9.
10.
11.
12.
13.
14.
15.
Str. 5
16. 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.
17. 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.
18. 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.
19. 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.)
20. 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
21. 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.)
22. Muszą być dostępne mechanizmy eskalacji zdarzeń na bazie wagi zdarzenia, okresu
zalegania w systemie, statusu, treści i kategorii
23. 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.
24. 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.
25. 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.
26. Zdarzenia muszą być prezentowane na ekranach operatorskich co najmniej w formie:
tabelarycznej
graficznej w podkładami z plików graficznych
27. System musi 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
system (ograniczanie zakresu dostępnych danych).
Str. 6
30. Konsola operatorska musi 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.
41. System monitorowania musi posiadać przygotowane przez producenta oprogramowania
podręczniki: użytkownika i administratora.
42. System monitorowania musi mieć możliwość instalacji swoich komponentów
serwerowych (nadzorujących pracę agentów, raportujących i bazodanowych) w
środowisku zwirtualizowanym.
43. System musi udostępniać ekrany przeznaczone dla urządzeń mobilnych, prezentujących
co najmniej podstawowe metryki i informacje.
45. 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.
46. Moduł monitorowania musi posiadać mechanizm pozwalający na wykrycie
niedostępności każdego z komponentów.
47. System monitorowania musi umożliwiać zaszyfrowanie komunikacji w relacji konsolasystem i sonda-system.
48. 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
49. Bramy zdarzeń muszą być konfigurowalne co najmniej w zakresie:
selekcji przekazywanych informacji
Str. 7
operacji wykonywanych po zakończonej synchronizacji (np. ustawienie flagi w rekordzie
zdarzenia
50. 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.
51. System musi pozwalać na automatyczne uruchamianie komponentu który uległ awarii i
się wyłączył (np. sondy).
b) W zakresie IBM Tivoli Application Dependency Discovery Manager Resource,
oprogramowanie równoważne musi realizować co najmniej następujące funkcjonalności:
LP
1.
2.
3.
4.
5.
6.
7.
Wymaganie
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
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)
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
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
skanowania baz danych: DB2, Informix, MS SQL, Oracle, Sybase
Oprogramowanie musi posiadać przygotowane i wspierane przez producenta
oferowanego systemu sensory do skanowania urządzeń: Alteon, BIG-IP, Checkpoint,
Cisco, Extreme, Brocade, IBM BladeCenter, NetScreen, Cisco PIX, EMC, IBM SVC,
XIV storage,
Udostępniać możliwość budowania własnych sensorów
Str. 8
8.
9.
10.
11.
12.
13.
14.
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ą obejmować 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
Wspierać wykrywanie w środowiskach wykorzystujących firewalle – musi udostępniać
komponent pośredniczący w wykrywaniu (proxy).
Możliwość współpracy z bazą CMDB w celu synchronizacji zebranych danych
15. 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.
16. 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.
17. 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.
18. 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.
19. 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.
20. udostępniać integrację z oprogramowaniem wykorzystywanym przez Zamawiającego:
IBM CAM, IBM Omnibus, IBM TBSM
21. Udostępniać dwukierunkową integrację z bazą CMDB
22. Pozwalać na instalację na platformie: AIX (6.1 i 7.1), Linux, Windows (2008 i 2012)
Str. 9
c) W zakresie IBM Tivoli Business Service Manager Tier 1 Resource, oprogramowanie
równoważne 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.
za pomocą odpytywania zewnętrznych baz danych
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.
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
9. 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
10. 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
8.
Str. 10
11. 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 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
Pobieranie czasu i daty, konfigurowalna zamiana reprezentacji tekstowej czasu i daty na
wartość numeryczną (np. unixtime)
12. 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)
13. 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
14. 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.
Moduł monitorowania biznesowego musi oferować śledzenie SLA i KPI.
16. 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
17. Moduł monitorowania biznesowego musi umożliwiać definiowanie i nadzorowanie
parametrów KPI dla każdego z obiektów tworzących drzewo usługi
18. Moduł monitorowania biznesowego musi zapewniać możliwość składowania wartości
SLA i KPI dla późniejszego raportowania historycznego
19.
System musi posiadać konsolę operacyjną (operatorską).
20. Moduł monitorowania biznesowego musi udostępniać interfejs użytkownika (konsolę
operatorską) poprzez przeglądarkę WWW wykorzystującą wyłącznie technologię HTML
Str. 11
21.
22.
23.
24.
25.
26.
27.
28.
29.
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.
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
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.
Str. 12
30.
31.
Tworzenie i modyfikacja raportów nie może wymagać zakupu dodatkowych licencji.
Raporty muszą być renderowane w postaci co najmniej: html, pdf i xls.
32.
Raporty muszą być generowane na żądanie i według wskazanego harmonogramu.
33. Moduł raportowy musi pochodzić od producenta oferowanego systemu i musi być w
pełni przez niego wspierany.
34. System musi posiadać raporty predefiniowane przez producenta systemu.
36. System musi udostępniać ekrany przeznaczone dla urządzeń mobilnych, prezentujących
co najmniej podstawowe metryki i informacje.
38. 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) W zakresie narzędzia IBM BigFixLifecycleResource, IBM BigFixComplianceResource,
IBM
BigFixInventoryResource
oraz
IBM
Endpoint
Manager
forServer
AutomationResource, narzędzie równoważne musi realizować co najmniej następujące
funkcjonalności:
LP
1.
2.
3.
4.
5.
6.
7.
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.
Str. 13
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
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
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
System umożliwia instalację systemów operacyjnych na wielu komputerach jednocześnie
z wykorzystaniem mechanizmu multicast
System musi tworzyć i zapamiętywać wiele wzorcowych obrazów systemów
operacyjnych
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.
23. System umożliwia ustalenia daty i czasu instalacji każdego oprogramowania oddzielnie.
24. 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).
25. System umożliwia grupowanie zadań instalacji oprogramowania w zbiory i instalowania
ich razem w określonej sekwencji.
Str. 14
26. 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.
27. System umożliwia rozrzucenie czasów instalacji oprogramowania na różnych
urządzeniach na zdefiniowany okres czasu tak by zmniejszyć obciążenie sieci.
28. System umożliwia zdefiniowanie komunikatu dla użytkownika informującego o instalacji
oprogramowania dla każdego oprogramowania oddzielnie.
29. System zapewnia mechanizm przejmowania zdalnej konsoli dla systemów Windows i
Linux bez konieczności zakupu dodatkowego oprogramowania bądź sprzętu.
30. System oferuje pełną audytowalność sesji zdalnej pomocy (z możliwością nagrywania
sesji włącznie)
31. System wspiera poufność oferując użytkownikom przejmowanej stacji możliwość
wskazania okien aplikacji, które mają być niewidoczne dla osoby wsparcia technicznego
32. System umożliwia uruchomienie sesji zdalnej konsoli kontekstowo z centralnej konsoli
zarządzającej
33. System umożliwia osobie przejmującej konsolę przelogowanie się na konto innego
użytkownika (np. administratora) bez konieczności rozłączania sesji
34. 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
35. 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.
36. System umożliwia ustalenie zależności pomiędzy poprawkami przed instalacją poprawek
na zarządzanym urządzeniach.
37. System wykrywa fakt zakończenia instalacji poprawki
38. System wykrywa fakt zainstalowania nowej poprawki na urządzeniu i traktować takie
urządzenie, jako zaktualizowane.
39. System jest w stanie stwierdzić czy poprawki zostały zainstalowane poprawnie.
40. System wykrywa, które poprawki są właściwe dla każdego urządzenia indywidualnie w
zależności od ustawień urządzenia.
41. System wykrywa fakt uszkodzenia lub odinstalowania poprawki w urządzeniu.
42. System umożliwia edycję zadań instalacyjnych i dostosowania ich zachowań do polityki
firmy.
43. 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)
44. System zapewnia zarządzanie poprawkami i aktualizacjami dla następującego
oprogramowania stacji roboczych:
Str. 15
Adobe Reader, Adobe Flash Player, Adobe Shockwave Player
Oracle Java
Mozilla Firefox
45. System umożliwia indywidualne ustalenie, które poprawki maja być zainstalowane na
wybranych urządzeniach.
46. System umożliwia ustalenie daty i czasu instalacji każdej poprawki oddzielnie.
47. 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
48. 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.
49. System umożliwia instalowanie wielu poprawek bez konieczności każdorazowego
ponownego uruchamiania sytemu.
50. 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.
51. System zapewnia użytkownikowi możliwość odroczenia instalacji poprawki oraz
ponownego uruchomienia systemu.
52. W przypadku niepowodzenia instalacji poprawki system umożliwia automatyczne
powtórzenie procedury instalacji zadaną ilość razy
53. System umożliwia tworzenie własnych zadań instalacji poprawek.
54. System umożliwia składowanie plików instalacyjnych poprawek na przekaźnikach.
55. System umożliwia zdefiniowanie polityki, która automatycznie dokona instalacji
poprawek na urządzeniach dodanych do systemu już po wydaniu polecenia o instalacji
poprawki
56. System automatycznie usuwa pliki instalacyjne z dysków urządzeń po udanej instalacji.
57. Administrator ma możliwość instalacji wybranej poprawki na wszystkich urządzeniach
spełniających zadane kryterium.
58. Agent przed przystąpieniem do instalacji poprawki każdorazowo sprawdza
odpowiedniość poprawki dla zarządzanego przez niego środowiska.
59. 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.
60. System pozwala na definiowanie procesów wykonujących operacje szeregowo lub
równolegle.
61. System dostarcza funkcjonalność pozwalającą na definiowanie operacji kompensacji
błędu dla każdego kroku procesu.
62. 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
Str. 16
63. 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
64. 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
65. 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.
66. 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).
67. System pozwala na zaplanowanie czasu wykonania definiowanego procesu.
68. System pozwala na wykorzystanie rozwiązania Chef-Solo do realizacji poszczególnych
kroków procesu
69. System udostępnia REST API pozwalające na zdalne wywoływanie operacji związanych
z zarządzaniem procesami.
70. System umożliwia definiowanie polityk bezpieczeństwa i zgodności
71. System umożliwia weryfikowanie zdefiniowanych polityk zarówno na urządzeniach
podłączonych do sieci jak i poza nią
72. 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ń
Str. 17
73. 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)
74. System udostępnia raporty zgodności pokazujące statystyki zgodności zarządzanych
komputerów ze zdefiniowanymi politykami
75. Raporty zgodności przechowują i udostępniają dane historyczne związane z
przestrzeganiem polityk zgodności przez zarządzane komputery.
76. 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
77. Raporty pozwalają na przechodzenie z wyższego poziomu ogólności do niższego
poziomu w celu analizy
78. 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.
79. Raporty zgodności pozwalają na zapisywania konfiguracji filtrów oraz zawartości do
późniejszego użycia.
80. 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.
81. 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
82. System umożliwia przypisywanie posiadanych licencji do grup komputerów i
wykrywanie, jeśli oprogramowanie zostało zainstalowane na komputerach spoza
uprawnionej grupy
83. 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)
84. System zapewnia aktualizowany przynajmniej w cyklu miesięcznym katalog sygnatur
oprogramowania. Katalog zawiera powiązania pakietów oprogramowania (np. Word,
Excel, Powerpoint, Office) jak również hierarchiczną relację wersji oprogramowania
bat Reader 9, Acrobat
Reader X, Adobe Acrobat Redear)
85. 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
86. 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
87. System umożliwia elastyczne filtrowanie danych w interfejsie graficznym poprzez wybór
kolumn oraz określanie filtrów
Str. 18
88. System umożliwia eksportowanie danych do zewnętrznych narzędzi.
89. System udostępnia moduł raportowania dostępny z poziomu przeglądarki internetowej.
90. System umożliwia tworzenia własnych kwerend bazując na dowolnych informacjach
przesłanych przez agentów
91. Uprawnienia dostępu do modułu raportującego są niezależne od uprawnień do
administrowania systemem.
92. 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.
93. Moduł raportujący umożliwia użytkownikowi tworzenie i zapamiętywanie graficznych
raportów.
94. Moduł raportujący oferuje wzorce raportów, które mogą być zmieniane i zapamiętywane
przez użytkownika.
95. Zmienianie i zapamiętywanie stworzonych raportów odbywa się bez konieczności
zakupu dodatkowego oprogramowania bądź sprzętu.
96. Moduł raportujący oferuje filtrowanie informacji w raportach.
97. 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ć.
98. Moduł raportujący oferuje ustawienie czasu, kiedy raporty będą generowane.
99. Moduł raportujący oferuje powiadamiane użytkowników o spełnieniu zadanych
warunków.
100. 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.
101. 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.
102. System zapewnia integralność poleceń wysyłanych do zarządzanych urządzeń poprzez
podpisywane cyfrowe wszystkich poleceń.
103. 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.
104. System oferuje szyfrowanie komunikacji pochodzącej od agentów bez potrzeby zakupu
dodatkowego oprogramowania bądź sprzętu.
105. System zawiera wbudowany mechanizm klucza publicznego PKI nie wymagając zakupu
certyfikatów zewnętrznych.
106. Agent Systemu wykonuje zadane polityki w sposób ciągły bez względu na stan
połączenia z siecią.
107. System posiada wbudowany mechanizm failover dla serwera (umożliwiający
zdefiniowanie serwera zapasowego, który przejmie pracę w razie awarii serwera
podstawowego)
108. System umożliwia elastyczne definiowanie ścieżek komunikacji poprzez definiowanie
hierarchii komunikacji pomiędzy agentami, przekaźnikami oraz serwerem, w
Str. 19
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
szczególności umożliwia ustawienie na agencie automatycznego wyszukiwania
najbliższego przekaźnika
Agent dynamiczne łączy się z najbliższym przekaźnikiem w przypadku, gdy przypisany
mu przekaźnik jest niedostępny.
System umożliwia kontrolę uprawnień użytkownika konsoli do zarządzania określonymi
grupami agentów
System posiada mechanizm silnego uwierzytelnienia wymuszając stosowanie prywatnego
klucza do podpisywania akcji podejmowanych przez administratora.
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ń).
System umożliwia tworzenie zbiorów zadań wykonywanych razem w określonej
sekwencji zawierających wcześniej zdefiniowane polityki.
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.
Każdy z administratorów może posiadać unikalny login, indywidualne hasło oraz klucz
prywatny.
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.
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.
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.
Administrator ma możliwość dostosowania ustawień konsoli do swoich potrzeb poprzez
dodawanie i usuwanie kolumn.
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.
Konsola umożliwia definiowanie grup statyczne oraz dynamicznych w oparciu o
dowolne dane zbierane z agentów.
Konsola umożliwia operatorom tworzenie własnych zadań dla agentów
e) W zakresie narzędzia IBM Smart Cloud Virtual Storage Center, narzędzie równoważne
musi realizować co najmniej następujące funkcjonalności:
LP.
Wymaganie
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
Str. 20
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
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
System musi prawidłowo interpretować metryki pojemnościowe macierzy dyskowych i
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 mapę topologii oraz w postaci tabelarycznej
System musi pozwalać na ustawienie częstotliwości próbkowania i kolekcjonowania danych
oraz 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 długości przechowywanej historii.
System musi automatycznie (zgodnie z harmonogramem) oraz na żądanie inwentaryzować
sprzęt SAN i odczytywać dane pojemnościowe i konfiguracyjne.
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
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 przez interfejs web (http/https).
System musi umożliwiać wizualizację wartości pochodnych (np. średnich, median)
dostępnych metryk.
System musi mieć możliwość eksportu raportów oraz samych danych (metryk) do formatów
- PDF, CSV.
System musi umożliwiać ustawianie progów (trigger/threshold) dla wartości metryk oraz ich
agregatów (np. sum różnych metryk itp.)
System musi umożliwiać automatyczne powiadamianie (e-mail, SNMP trap) o
przekroczeniu progów.
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, Chrome oraz MS IE.
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ń dyskowych (macierzy RAID)
Str. 21
21
22
23
24
25
26
27
28
29
30
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 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 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 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 oprogramowaniem zarządzającym danymi w celu
wykonania kopii zapasowej z jej wykorzystaniem.
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 licencji do klastrów w trakcie działania systemu przy
zachowaniu sumarycznej zakupionej liczby licencji.
System musi się charakteryzować brakiem pojedynczego punktu awarii.
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
podłączonymi hostami.
System musi posiadać funkcjonalność zwiększania i zmniejszania rozmiaru wolumenów.
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
31 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
32 dwoma różnymi typami macierzy dyskowych.
System musi posiadać możliwość wykonywania 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
33 pojedynczego wolumenu), kopii pełnej oraz kopii wskaźników, przy czym dostęp do kopii
Str. 22
musi być możliwy natychmiast po jej zainicjalizowaniu zarówno w odniesieniu do kopii
wskaźników jak i kopii pełnej.
System musi obsługiwać grupy spójności (konsystencji) wolumenów (jeżeli jest wymagana
34 licencja, należy dostarczyć licencje na całość wirtualizowanych zasobów).
System musi posiadać funkcjonalność tworzenia mirrorowanych LUN, dla których awaria
35 jednej kopii 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
36 przewyższy rozmiar przestrzeni 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. Pojedynczy wolumen musi mieć
możliwość rozłożenia pomiędzy 3 różnymi rodzajami dysków: SSD, HDD 15/10 k RPM i
37 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
38 grupy dyskowe 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
39 technologicznie dyskach stałych (FC, SAS, SSD, SATA).
System musi posiadać sterowniki do obsługi wielościeżkowego dostępu do wolumenów,
awarii ścieżki i rozłożenia obciążenia po ścieżkach dostępu dla podłączanych systemów
40 operacyjnych.
System musi posiadać wsparcie min. dla systemów operacyjnych: Microsoft Windows 200841 2012, VMware vSphere 5.x.
System musi posiadać możliwość wirtualizacji zasobów znajdujących się na macierzach
42 różnych 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
43 wirtualizatora mogą być odczytane bez jego udziału.
System musi zostać dostarczony z kompletem licencji wymaganych dla replikacji
synchronicznej i asynchronicznej, wykorzystywania migawek dla wymaganej pojemności
44 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
45 rekomendacji powinno być możliwe zarówno na żądanie jak i w trybie automatycznym.
Str. 23
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
46 (dopuszczalne jest zastosowanie dedykowanych kart kompresujących).
f) W zakresie IBM Spectrum Protect, oprogramowanie równoważne musi realizować co
najmniej następujące funkcjonalności:
Lp.
Wymagane
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.
Str. 24
Lp.
Wymagane
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.
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.
Str. 25
Lp.
Wymagane
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
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
Str. 26
Lp.
Wymagane
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, emaili, 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.
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.
Str. 27
Lp.
Wymagane
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.
Str. 28

Załącznik E do SIWZ z dnia 26.08.2016 r.

Transkrypt

Podobne dokumenty

KOPIARKA TOSHIBA 1370

Aneks 2. Wzór wniosku o metryczkę subwencji

Załącznik nr 2 do umowy ……… Protokół przekazania sprzętu

Jak wykonać kopię bazy danch w celu wysłania jej do serwisu lub w

Zarządzenie nr 2 z dnia 03.11.2015

H1RZ6S - Veeam Certified Engineer (VMCE) v9

Reprodukcje