4. Szczegółowe Wymagania w zakresie instalacji, konfiguracji i integracji ze środowiskiem Zamawiającego. Załącznik nr 2 (część 2)

Transkrypt

1 Załącznik nr 2 (część 2) Szczegółowe wymagania dotyczące budowy/rozbudowy systemów infrastrukturalnych oraz integracji ze środowiskiem Zamawiającego w ramach budowy usługi odtworzenia po katastrofie 4. Szczegółowe Wymagania w zakresie instalacji, konfiguracji i integracji ze środowiskiem Zamawiającego Wszystkie wdrażane komponenty sprzętu i oprogramowania muszą posiadać możliwość integracji z usługą katalogową Microsoft Active Directory. AI_01 - Mechanizmy replikacji i zabezpieczenia danych w CPD MF Dostawa nowych macierzy a) Montaż, podłączenie oraz konfiguracja wszystkich dostarczonych elementów w pomieszczeniu wskazanym przez Zamawiającego. Zamawiający wymaga instalacji macierzy w dwóch lokalizacjach zgodnie z poniższą tabelą: Lp. Nazwa komponentu Identyfikator komponentu Minimalna liczba komponentów Lokalizacja Macierz dyskowa C.STO.UNI 1 Macierz dyskowa flash C.STO.FLS 1 Macierz dyskowa C.STO.UNI 1 Macierz dyskowa flash C.STO.FLS 1 Dostawa wirtualizatora macierzy dyskowych Centrum Przetwarzania Danych Ministerstwa Finansów Ośrodek Przetwarzania Danych w Radomiu, ul. Samorządowa 1 Centrum Przetwarzania Danych Ministerstwa Finansów Ośrodek Przetwarzania Danych w Radomiu, ul. Samorządowa 1 Narodowy Bank Polski - Centrala NBP Warszawa, ul. Świętokrzyska 11/21 Narodowy Bank Polski - Centrala NBP Warszawa, ul. Świętokrzyska 11/21 b) Montaż, podłączenie oraz konfiguracja wszystkich dostarczonych elementów w pomieszczeniu wskazanym przez Zamawiającego. Zamawiający wymaga instalacji wirtualizatorów w dwóch lokalizacjach zgodnie z poniższą tabelą:

2 Lp. Nazwa komponentu Identyfikator komponentu Minimalna liczba komponentów Lokalizacja 1. Wirtualizacja macierzy dyskowych C.STO.VRT 1 Centrum Przetwarzania Danych Ministerstwa Finansów Ośrodek Przetwarzania Danych w Radomiu, ul. Samorządowa 1 Wirtualizacja macierzy dyskowych C.STO.VRT 1 Narodowy Bank Polski - Centrala NBP Warszawa, ul. Świętokrzyska 11/21 c) Dostarczenie i podłączenie okablowania FC, LAN oraz zasilania do istniejącej infrastruktury Zamawiającego d) Niezbędna konfiguracja środowiska SAN Zamawiającego (aliasy, zony itp.) e) Wykonanie podziału logicznego dostarczanej przestrzeni, konfiguracja puli dyskowych i funkcji tieringu pomiędzy różnymi typami dysków (dotyczy komponentu C.STO.UNI). f) Wykreowanie i wystawienie przestrzeni do wirtualizatora macierzy dyskowych (dotyczy komponentu C.STO.VRT) i do serwerów systemu wirtualizacji (C.PSR.R.X86). AI_05 System backupowy w CPD MF 1. Warunki równoważności dla oprogramowania IBM Spectrum Protect. Lp. Minimalne parametry techniczne 1. Oferowane oprogramowanie backupu musi być licencjonowane na wielkość danych źródłowych podlegających zabezpieczeniu oraz nielimitowaną ilość kopii tych danych składowanych w systemie backupu. Wymagane jest dostarczenie licencji oprogramowania backupowego umożliwiających zabezpieczanie 200 TiB danych źródłowych. 2. W ramach dostarczonej licencji pojemnościowej wymagana jest realizacja poniższych funkcjonalności na nieograniczoną ilość klientów zabezpieczanych oferowanym systemem backupu: Nieograniczona ilość klientów podłączonych do systemu backupu (Windows, Linux, AIX, HP-UX, Solaris, NAS) systemy fizyczne i wirtualne Backup przez LAN oraz sieć SAN Backup systemu plików (plikowy oraz blokowy) Backup urządzeń NAS za pomocą protokołu NDMP Backup systemów wirtualnych VMware oraz Hyper-V (z zewnątrz typu image oraz ze środka) z możliwością uruchamiania odtwarzania maszyn VM z poziomu konsoli vcenter dla VMware oraz Microsoft System Center Virtual Machine Manager dla Hyper-V Możliwość odtwarzania pojedynczych plików z pełnego obrazu maszyny wirtualnej (bez zainstalowanego agenta systemu backupu wewnątrz maszyny VM)

3 Integracja systemu backupu ze środowiskami VMware vsphere oraz vrealize (dostarczenie modułu do konsoli vrealize umożliwiającego definiowanie zadań backupu oraz uruchamianie odtwarzania backupu z samej konsoli vrealize) Backup baz danych poprzez integrację z wewnętrznymi mechanizmami backupu baz Oracle RMAN, DB2 Backup, MSSQL VDI/VSS, Exchange VSS, Sharepoint VSS, Active Directory, SAP Oracle BRTools Możliwość składowania danych backupu na urządzeniach dyskowych lokalnie podłączonych do klientów backupu oraz urządzeniach NAS (CIFS/NFS), urządzeniach taśmowych oraz DataDomain (sieć LAN i SAN) Funkcjonalność jednoczesnego backupu wielu strumieni danych na to to samo urządzenie dyskowe oraz taśmowe Mechanizm de-duplikacji na źródle wbudowany w system backupu i współpracujący natywnie z dostarczonymi wirtualnymi bibliotekami Zarzadzanie snapshotami macierzowymi macierzy blokowych i plikowych Możliwość backupu zdalnych oddziałów przez słabe łącza WAN (opóźnienie 20ms) z funkcją deduplikacji na źródle Możliwość backupu stacji roboczych i laptopów przez słabe łącza WAN z prostym interfejsem WWW lub aplikacją kliencką służącą do odtwarzania danych dla użytkownika końcowego 3. Z uwagi na bezpieczeństwo składowanych danych oraz wydajność oferowany system musi wspierać funkcję szyfrowania kluczem prywatnym oraz posiadać zintegrowany mechanizm de-duplikacji na źródle. 4. Zamawiający udostępni do instalacji serwera systemu backupu maszynę wirtualną w klastrze VMware o parametrach 8 vcpu, 32 GB RAM, 500GB disk, wyłącznie do składowania metadanych systemu backupu. Jeżeli oferowany system backupu wymaga mocniejszego serwera z uwagi np. na konieczność przesyłania przez niego danych backupu, taki serwer musi być dostarczony przez oferenta. Konfiguracja serwera musi obejmować instalację w klastrze rozciągniętym między dwie lokalizacje oraz zawierać mechanizm replikacji danych wewnętrznych baz systemu backupu. Jeżeli oferent zakłada wykorzystanie innych serwerów pośredniczących w procesie backupu, tj. serwery mediów, serwery te muszą również być dostarczone w ramach oferty w konfiguracji HA (do dwóch centrów przetwarzania_. Wraz z licencją na oprogramowanie backupu muszą zostać dostarczone inne niezbędne licencje potrzebne do instalacji oprogramowania, tj. licencja na system operacyjny i bazę danych. 5. Zamawiający w chwili obecnej jest w posiadaniu dwóch urządzeń EMC DataDomain, które muszą być zintegrowane z dostarczonym oprogramowaniem backupu. Parametry posiadanych urządzeń DataDomain 4500 rozbudowywanych w niniejszym postępowaniu są następujące: Model DD4500 o pojemności użytecznej 128 TiB każdy Licencje VTL, BOOST, Replikacja Wydajność 10TB/h przy wykorzystaniu protokołu VTL Wydajność 25TB/h przy wykorzystaniu protokołu BOOST

4 Zamawiający wymaga, aby dostarczone oprogramowanie backupu współpracowało z protokołem DataDomain VTL w sieci SAN. Zamawiający wymaga, aby dostarczone oprogramowanie backupu współpracowało z protokołem DataDomain BOOST umożliwiające de-duplikację na źródle oraz bezpośredni backup z zabezpieczanego klienta na posiadane urządzenia urządzenie DataDomain przez sieć LAN oraz SAN bez pośrednictwa innych serwerów (serwerów mediów). Backup z de-duplikacją na urządzeniu oraz na źródle musi być dostępny dla wszystkich typów danych w ramach oferowanego rozwiązania: pliki, bazy danych, obrazy maszyn wirtualnych. Kompatybilność oferowanego oprogramowania z urządzeniem DataDomain oraz wymienionymi protokołami VTL i BOOST musi być udokumentowana w oficjalnej matrycy kompatybilności oferowanego oprogramowania oraz w matrycy kompatybilności firmy EMC dla urządzeń DataDomain. W przypadku, gdy oferent nie jest w stanie dostarczyć wszystkich wymienionych funkcjonalności z posiadanym przez zamawiającego urządzeniem de-duplikacyjnym DataDomain, funkcjonalności te mogą być dostarczone z własnymi urządzeniami de-duplikującymi o pojemności 200 TiB netto (każde) posiadającymi min. porty Ethernet 1Gb 4szt, 10Gb 2szt, porty FC 8Gb 2szt. (każde). Urządzenia muszą posiadać parametry co najmniej jak opisane w załączniku ARIT-C do Architektury Referencyjnej Środowiska IT CPD MF dla C.STO.VLB. 6. Dostarczone oprogramowanie musi posiadać moduł monitorowania i raportowania wszystkich oferowanych komponentów w tym bibliotek taśmowych oraz urządzeń de-duplikacyjnych (DataDomain lub urządzeń de-duplikacyjnych dostarczonych w niniejszym postępowaniu). Moduł ten musi posiadać pojedynczy graficzny interfejs dla wszystkich wyżej wymienionych komponentów oraz funkcjonalności: Monitorowanie i zawiadamianie o błędach Możliwość definiowania swoich własnych, zaawansowanych raportów Definiowanie parametrów SLA oraz ich monitorowanie Raportowanie wykorzystania zasobów systemu backupu (pojemność, wydajność) Oferent musi dostarczyć minimum następujące raporty dostępne w niniejszym module (wbudowane lub utworzone przez oferenta w ramach wdrożenia systemu): Podsumowanie zadań backupowych (liczba backupów udanych, nieudanych, aktywnych, łączny rozmiar zabezpieczonych danych) Podsumowanie zadań odtworzeniowych (liczba odtworzeń udanych, nieudanych, aktywnych, łączny rozmiar odtworzonych danych danych) Zbiorcze procentowe zestawienie udanych zadań backupowych z poszczególnych serwerów Zbiorcze zestawienie zabezpieczanych serwerów, które w sposób ciągły (kilka razy pod rząd) maja problem z backupami Zestawienie zabezpieczanych systemów plików, które w ogóle nie są zabezpieczane Spodziewany czas odtwarzania zabezpieczanego serwera oraz potencjalnej utraty danych (czas między ostatnim backupem a chwilą awarii) Najmniej wiarygodne zabezpieczane serwery (procent nieudanych backupów) Lista najwolniejszych/najszybszych zabezpieczanych maszyn Poziom SLA (procentowa liczba udanych backupów) w odniesieniu do poziomu założonego

5 Mierzenie poziomu SLA dla poszczególnych zabezpieczanych serwerów przy uwzględnieniu założonego okna backupowego i RPO Liczba danych, zadań backupu dziennie Zużycie zasobów na serwerze backupu (procesor, pamięć, interfejsy sieciowe) Zużycie mediów backupowych i napędów taśmowych Aktualna konfiguracja systemu backupowego oraz historia zmian konfiguracji systemu backupowego Inwentaryzacja licencji systemu backupowego Wykorzystanie systemu backupowego przez poszczególne działy / grupy użytkowników 2. Dostawa i rozbudowa bibliotek wirtualnych. a) Montaż, podłączenie oraz konfiguracja wszystkich dostarczonych elementów w pomieszczeniu wskazanym przez Zamawiającego. Zamawiający wymaga instalacji wirtualnych bibliotek taśmowych w dwóch lokalizacjach zgodnie z poniższą tabelą: Lp. Nazwa komponentu Identyfikator komponentu Minimalna liczba komponentów Lokalizacja 1. Biblioteka wirtualna (rozbudowa posiadanych przez Zamawiającego bibliotek EMC Data Domain DD4500) C.STO.VLB 2 Centrum Przetwarzania Danych Ministerstwa Finansów Ośrodek Przetwarzania Danych w Radomiu, ul. Samorządowa Biblioteka wirtualna C.STO.VLB 1 Biblioteka wirtualna C.STO.VLB 1 Centrum Przetwarzania Danych Ministerstwa Finansów Ośrodek Przetwarzania Danych w Radomiu, ul. Samorządowa 1 Centrum Przetwarzania Danych Ministerstwa Finansów Narodowy Bank Polski - Centrala NBP Warszawa, ul. Świętokrzyska 11/21 b) Dostarczenie i podłączenie okablowania FC, LAN oraz zasilania do istniejącej infrastruktury Zamawiającego c) Niezbędna konfiguracja środowiska systemu backupu Zamawiającego (IBM Spectrum Protect.) Zakres wdrożenia systemu backupu w Ośrodku Przetwarzania Danych w Warszawie (NBP) 1. Zakres systemu Zakłada się, że po zakończeniu wdrożenia w Ośrodku Przetwarzania Danych w Warszawie (NBP) znajdują się:

6 Zabezpieczane dane klienci systemu backupu Podstawowe urządzenia składowania danych macierze dyskowe Urządzenia składowania kopii zapasowych danych urządzenia dyskowe wyposażone w zaawansowane technologie deduplikacji, weryfikacji i replikacji danych backupowych (Biblioteka wirtualna) Pozostałe systemy infrastrukturalne. Oba Ośrodki Przetwarzania traktowane są jako równorzędne i działające w konfiguracji Active-Active. Oznacza to, że m aszyny wirtualne mogą być dynamicznie tworzone, przemieszczane między ośrodkami i kasowane. Klienci systemu backupu to maszyny wirtualne oraz maszyny fizyczne, na których znajdują się zabezpieczane dane. Ośrodki przetwarzania są połączone siecią i możliwa jest między nimi komunikacja za pomocą protokołu IP. Ilość zabezpieczanych klientów backupu oraz ilość danych ma wpływ na wymiarowanie systemu backupu oraz nfrastruktury, ale nie zależą od tego jego funkcjonalności i możliwości operacyjne. i 2. Działanie systemu backupu w ramach Ośrodka Przetwarzania Danych w Warszawie (NBP) Kopie zapasowe zabezpieczanych danych wykonywane będą w następujący sposób: Backup musi być wykonywany na kilka sposobów ze względu na specyfikę backupowych danych: o Kopia migawkowa maszyn wirtualnych podmontowana do maszyny Proxy, nie wymaga instalacji o programowania backup wewnątrz maszyn VM Image Level o Backup on-line danych aplikacji i baz danych ze środka maszyny za pomocą oprogramowania b o ackupowego Guest Level Kopia migawkowa dysków macierzy podmontowana do maszyny Proxy Snapshot Backup o Kopia migawkowa urządzeń NAS/NDMP zarejestrowana jako backup w systemie a następnie s kładowana na urządzeniu backup o Rejestracja wszystkich zapisów na poziomie maszyny wirtualnej lub dysku macierzy i możliwość c ofnięcia w czasie z dokładnością do jednego zapisu Continuous Data Protection (CDP) Wybór najlepszej metody backupu należy do wykonawcy przy czym Zamawiający wymaga aby spełnione były parametry RTO i RPO wskazane w rozdziale 5 Szczegółowe wymagania w zakresie budowy usługi odtworzenia po katastrofie dla kluczowych usług elektronicznych resortu finansów, pkt Parametry DR w tabeli nr. 1 Poziomy DR Systemów Biznesowych. Dla kopii lokalne (w ramach pojedynczego ośrodka przetwarzania. Oznacza to że w przypadku katastrofy w Ośrodku Przetwarzania w Radomiu i przeniesieniu wszystkich wskazanych systemów do Ośrodka Przetwarzania w Warszawie (NBP) czasy RPO i RTO nie mogą przekroczyć parametrów wskazanych w powyższej tabeli. Backup musi być składowany zawsze na lokalnym urządzeniu w Ośrodku Przetwarzania w Warszawie (NBP). Każdy backup musi być deduplikowany na kliencie i na urządzeniu docelowym po sieci przesyłanych jest ok. 5% zabezpieczanych danych. W przypadku zastosowania systemu backupu który nie wspiera mechanizmów d eduplikacji na źródle dla posiadanych przez zamawiającego urządzeń EMC Data Domain (DD BOOST) Wyko nawca zobowiązany jest do dostarczenia dedykowanych macierzy dyskowych zgodnych ze standardem C.STO.UNI pozwalających na przechowywanie zdeduplikowanych danych mechanizmem systemu backupowego. Wy

7 maganie to dotyczy również systemu IBM Spectrum Protect i nie zwalania Wykonawcy z dostarczenia i rozbud owy wirtualnych bibliotek wskazanych w pkt. 2 Dostawa i rozbudowa bibliotek wirtualnych.. Poniżej tabela atrybutów dla macierzy dyskowej niezbędnej dla systemu backupowego nie wspierającego mechanizmów deduplikacji na źródle EMC Data Domain (DD BOOST). Lp. Nazwa komponentu Identyfikator komponentu Minimalna liczba komponentów Atrybuty NETTO CAŁKOWITA TiB (nie mniejsza niż zapewniająca przechowywanie danych backupu z 30 dniową retencją) NETTO SSD 10% pojemności netto całkowitej NETTO SAS 60% pojemności netto całkowitej NETTO NL_SAS 30% pojemności netto całkowitej PAMIĘĆ CACHE 256 GB LICZBA PORTÓW FC 8 szt. 1. Macierz dyskowa C.STO.UNI 2 PRĘDKOŚĆ PORTÓW FC 16 Gb/s LICZBA PORTÓW iscsi brak PRĘDKOŚĆ PORTÓW iscsi - brak ROZBUDOWA DO MIN. LICZBY DYSKÓW 1400 szt. ROZBUDOWA CACHE DO MIN. POJEMNOŚCI 2 TB ROZBUDOWA DO MIN. LICZBY PORTÓW FC FRONTEND 32 szt. MIN WYDAJNOŚĆ MACIERZY IOPS - dostosowane do potrzeb oferowanego systemu backupu MAX ŚREDNI CZAS ODPOWIEDZI dostosowane do potrzeb oferowanego systemu backupu Dane podczas backupu muszą by przesyłane za pośrednictwem sieci IP lub FC. Istnieje możliwość wykorzystania dedykowanej sieci VLAN do backupu. Wymagana jest również możliwość przesyłania danych p o SAN/FC jeśli klient backupu wyposażony jest w port SAN/FC. System backupu musi być elastyczny i pozwalać na dostosowanie konfiguracji do wymaganego poziomu usług. Przykładowo, częstotliwość backupu, poziom backupu, czas ochrony kopii zapasowej oraz ilość klonów /replik musi być dowolnie konfigurowana w zależności od przyjętej polityki ochrony danych wskazanych w ro

8 zdziale 5 Szczegółowe wymagania w zakresie budowy usługi odtworzenia po katastrofie dla kluczowych usłu g elektronicznych resortu finansów, pkt Parametry DR w tabeli nr. 1 Poziomy DR Systemów Bizne sowych. Dla kopii lokalne (w ramach pojedynczego ośrodka przetwarzania. Oznacza to że w przypadku katastr ofy w Ośrodku Przetwarzania w Radomiu i przeniesieniu wszystkich wskazanych systemów do Ośrodka Przet warzania w Warszawie (NBP) czasy RPO i RTO nie mogą przekroczyć parametrów wskazanych w powyższej tabeli. Budowa systemu backupu Architektura systemu wartości minimalne : Centralny Serwer Backup zawierający konfigurację i kontrolujący wszystkie działania systemu. Centralna konsola zarządzania maszyna wirtualna lub fizyczna. Jedna konsola obejmuje wszystkie Serwery Backup. Wirtualna maszyna do montowania kopii migawkowych maszyn wirtualnych. Co najmniej jedna maszyna na l okalizację. Maszyna wirtualna do nagrywania zapisów do krytycznych klientów, CDP. Co najmniej jedna maszyna na lok alizację. Centralny system do raportowania, monitorowania, statystyk 2 maszyny wirtualne, jedna dla bazy danych dr uga dla aplikacji. Fizyczne Węzły Składowania do zapisu na nośniki taśmowe i montowanie kopii migawkowych z macierzy za pośrednictwem protokołu FC. Jedna maszyna na lokalizację. Poniżej przedstawiono schemat architektury logicznej dla systemu backupu w ramach Ośrodka Przetwarzania w Warszawie (NBP) w przypadku zastosowania posiadanego oprogramowania IBM Spectrum Protect. W tym wariancie Wykonawca zobowiązany jest do wdrożenia narzędzia IBM Spectrum Protect oraz do dostarczenia dwóch macierzy dyskowych C.STO.UNI (do każdego z ośrodków przetwarzania po jednej sztuce) na potrzeby destination storage pool oraz dodatkowej przestrzeni na dane meta data wraz z rozbudową i dostarczeniem wirtualnych bibliotek C.STO.VLB na potrzeby virtual library pool.

9 Poniżej przedstawiono schemat architektury logicznej dla systemu backupu w ramach Ośrodka Przetwarzania w Warszawie (NBP) w przypadku zastosowania oprogramowania równoważnego nieposiadającego wsparcia dla mechanizmów deduplikacji na źródle EMC DataDomain (DD BOOST). W tym wariancie Wykonawca zobowiązany jest do wdrożenia narzędzia równoważnego do IBM Spectrum Protect oraz do dostarczenia macierzy dyskowej C.STO.UNI (do każdego z ośrodków przetwarzania po jednej sztuce) na potrzeby deduplication storage pool oraz dodatkowej przestrzeni na dane meta data wraz z rozbudową i dostarczeniem wirtualnych bibliotek C.STO.VLB na potrzeby virtual library pool. Poniżej przedstawiono schemat architektury logicznej dla systemu backupu w ramach Ośrodka Przetwarzania w Warszawie (NBP) w przypadku zastosowania oprogramowania równoważnego posiadającego wsparcie dla mechanizmów deduplikacji na źródle EMC DataDomain (DD BOOST). W tym wariancie Wykonawca zobowiązany jest do wdrożenia narzędzia równoważnego do IBM Spectrum Protect wraz z rozbudową i dostarczeniem wirtualnych bibliotek C.STO.VLB na potrzeby virtual library pool. AI_08 - System wirtualizacji zasobów w CPD MF Zakres prac a) Dostarczenie wszystkich wymaganych licencji na oprogramowanie wymagane w postępowaniu b) Dostarczenie wszystkich komponentów sprzętowych wymaganych w postępowaniu c) Montaż, podłączenie oraz konfiguracja wszystkich dostarczonych elementów w pomieszczeniu wskazanym przez Zamawiającego. d) Dostarczenie i podłączeniem okablowania FC, LAN oraz zasilania do budowanej infrastruktury Zamawiającego e) Niezbędna konfiguracja środowiska SAN Zamawiającego (aliasy, zony itp.)

10 f) Niezbędna konfiguracja środowiska LAN Zamawiającego (nazwy portów, EtherChannel/Team, itp.) g) Aktualizacja oprogramowania Firmware wszystkich komponentów sprzętowych dostarczonych w zamówieniu h) Integracja sprzętu z dostarczanym oprogramowaniem zarządzającym serwerami. i) Instalacja oprogramowania hypervisora i konfiguracja włącznie z integracją z oprogramowaniem zarządzającym Vmware vcenter Server oraz MS Active Directory i system poczty elektronicznej (w zakresie wysyłania maili). Zamawiający wymaga aby konfiguracja serwerów ESX i vcenter wyglądała w następujący sposób: Rysunek 1 - Konfiguracja podziału klastrów vsphere na dostarczonej infrastrukturze. j) Konfiguracja sieciowa w warstwie wirtualizacyjnej (vswitch, dvswitch, portgrupy, vmkernel, vmotion, itp.) Rysunek 2 - Konfiguracja podziału vswitch oraz dvswitch vsphere na dostarczonej infrastrukturze.

11 k) Konfiguracja zasobów pamięci masowej w warstwie wirtualizacyjnej (Datastore) Rysunek 2 - Konfiguracja zasobów dyskowych SAN na dostarczonej infrastrukturze. l) Konfiguracja parametrów hypervisora jak: serwery czasu, serwery logów itp. zgodnie z obowiązującymi w CPD standardami które zostaną przekazane po podpisaniu Umowy.. m) Konfiguracja mechanizmów HA, DRS, vmotion, DPM i Update Manager. Rysunek 3 Zachowanie mechanizmu HA w przypadku uszkodzenia serwera w klastrze..

12 Rysunek 4 Zachowanie mechanizmu DRS w przypadku wzrostu obciążenia na jednym z serwerów fizycznych. Rysunek 5 Zachowanie mechanizmu vmotion. Rysunek 6 Zachowanie mechanizmu DPM w momencie gdy zasoby na kastrze vsphere pozwalają na wyłączenie serwera fizycznego.

13 Rysunek 7 Ogólna architektura funkcjonalności Update Manager odpowiedzialnej za wgrywanie poprawek do serwerów ESXi. n) Instalacja i integracja z systemami ochrony antywirusowej Trend Micro Rysunek 8 Ogólna architektura systemu Trend Micro o) Wymagania techniczne dot. oprogramowania do tworzenia i zarządzania planami Disaster Recovery: Rozwiązanie musi umożliwiać zapewnienie ochrony maszyn wirtualnych niezależnie od architektury DataCenter (Active-Active, Active-Pasive, Streched Cluster). Na obecnym etapie oprogramowanie będzie obsługiwało tylko systemy wskazane do trybu Active-Passive. Rozwiązanie musi umożliwiać przełączanie maszyn wirtualnych z systemami operacyjnymi minimum: Windows XP, Windows Vista, Windows NT, Windows 2000, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, SLES 11, SLES 10, SLES9, SLES8, Ubuntu 7.04, RHEL 5, RHEL 4, RHEL3, RHEL 2.1, Solaris wersja 10 dla platformy x86, NetWare 6.5, NetWare 6.0, NetWare 6.1, Debian, CentOS, FreeBSD, Asianux, Ubuntu 7.04, SCO OpenServer, SCO Unixware, Mac OS X. Rozwiązanie musi umożliwiać integrację z mechanizmami replikacji typu Array-Based (machanizmy replikacji macierzowej), oraz musi integrować się z replikacją natywną wirtualizatora w ten sposób, że zarządzanie procesami DR dla obu mechanizmów musi odbywać się za pomocą jednej centralnej konsoli zarzadzającej całą platformą wirtualizacyjną. Rozwiązanie musi umożliwiać przełączanie usług IT pomiędzy Centrami Przetwarzania Danych bez utraty danych. Rozwiązanie musi umożliwiać zapewnienie ochrony maszyn wirtualnych z dyskami wirtualnymi oraz dyskami udostępnionymi maszynom wirtualnym wprost z macierzy typu Raw Device. Rozwiązanie musi umożliwiać zapewnienie ochrony maszyn wirtualnych zlokalizowanych na macierzach typu FC, iscsi, NFS. Rozwiązanie musi umożliwiać wykonywanie procedur przełączanie usług IT z Podstawowego Centrum Przetwarzania do Zapasowego Centrum Przetwarzania (fail-over) i z powrotem (fail-back) w ramach jednego narzędzia/konsoli. Rozwiązanie musi umożliwiać wykonywanie Planowego przełączenia oraz przełączenie Awaryjnego (podczas awarii).

14 Proces przełączania usług IT pomiedzy Centrami Przetwarzania Danych musi być automatyczny tzn. nie wymagający interwencji administratora w żadnej warstwie infrastruktury CPU, RAM, LAN, SAN. Rozwiązanie musi umożliwiać tworzenie tzw. planów Disaster Recovery, konfigurowanie tych planów i przypisywanie do nich maszyn wirtualnych (pojedynczych lub wielu). Plan DR musi umożliwiać: o Określanie kolejności uruchamiania maszyn wirtualnych w momencie przełączenia, o Zmianę adresaji IP maszyn wirtualnych, o Uruchamianie skryptów konfiguracyjnych w dowolnym momencie procesu przełączenia (w tym w maszynach wirtualnych). Rozwiązanie musi posiadać taką architekturę by umożliwiać wykonanie planu awaryjnego nawet w przypadku całkowitej niedostępności pojedynczego Centrum Przetwarzania. Rozwiązanie musi umożliwiać ochronę maszyn wirtualnych pracujących w Centrach Przetwarzania o następującej architekturze: o Jeden do Jednego, o Wiele do Jednego, o A do B do C do A Rozwiązanie musi umożliwiać wykonywanie tzw. Testowego przełączania pojedynczych maszyn wirtualnych lub grup wirtualnych maszyn, polegające na uruchomieniu wybranych usług w lokalizacji zapasowej, w izolowanej sieci LAN. Proces przełączenia Testowego nie może mieć wpływu na usługi przełączane i muszą być one cały czas dostępne dla użytkowników. Proces przełączenia Testowego nie może mieć wpływu na proces replikacji danych i relacje replikacji danych. Rozwiązanie musi umożliwiać automatyczne generowanie szczegółowych raportów z historycznych przełączeń oraz ich eksportowanie do pliku. AI_11 Bramka internetowa w CPD MF oraz AI_12 - System komunikacji LAN/WAN w CPD MF 1. AI_11 i AI_ Standard budowy infrastruktury sprzętowej dla sieci LAN oraz WAN. W nowym ośrodku przetwarzania zlokalizowanym w NBP sieć LAN musi składać się z następujących węzłów: Węzła bramki internetowej, WAN i extranetowej Węzła rdzeniowego Węzła dystrybucyjnego w skład, którego wchodzą urządzenia dostępowe (ang. access) w technologii Top of the Rack (ToR).

15 Rysunek 5.1 Schemat blokowy infrastruktury w ośrodkach przetwarzania danych Każdy węzeł musi zawierać odpowiednie bloki funkcjonalne, np. blok przełączników dostępowych, blok zapór sieciowych, itp. Każdy blok funkcjonalny musi składać się z dwóch identycznych urządzeń dla zapewnienia redundancji połączeń. Węzeł bramki internetowej i WAN Węzeł bramki internetowej i WAN będzie łączył ośrodek z siecią Internet oraz wewnętrzną siecią WAN Ministerstwa Finansów. Węzeł bramki internetowej i WAN musi być podłączony do węzła rdzeniowego. Zadaniem węzła bramki internetowej i WAN jest: podłączenie sieci LAN w danej lokalizacji do Internetu poprzez blok ruterów; podłączenie sieci LAN w danej lokalizacji do WAN poprzez blok ruterów; filtrowanie ruchu sieciowego przy pomocy bloku zapór sieciowych; śledzenie ruchu danych przy pomocy sond sieciowych; podłączenie lokalnych serwerów proxy poprzez blok przełączników dostępowych; rozdzielanie ruchu sieciowego do serwerów proxy poprzez blok urządzeń równoważących obciążenie (ang. loadbalancer); rozdzielanie ruchu sieciowego pomiędzy ośrodkami przetwarzania danych przy pomocy mechanizmów globalnego balansowania połączeniami; obsługa wydzielonej strefy Proxy (bramka internetowa) na potrzeby serwerów DNS, itp. Węzeł rdzeniowy

16 Węzeł rdzeniowy w postaci pary modularnych przełączników (lub też logicznych urządzeń w postaci wirtualnych kontekstów utworzonych na modularnych przełącznikach) pełni funkcję centralnego punktu sieci LAN którego zadaniem jest szybkie przełączanie pomiędzy podsieciami węzła bramki internetowej i WAN a sieciami warstwy LAN (serwerami aplikacyjnymi). Ponadto zapewnia : dystrybucja sieci pomiędzy warstwą bramki a warstwą LAN przy pomocy protokołu trasowania OSPF; połączenie pomiędzy innymi ośrodkami przetwarzania danych przy pomocy dedykowanej usługi transmisji danych DWDM; Węzeł dystrybucyjny Węzeł dystrybucyjny w postaci pary modularnych przełączników (lub też logicznych urządzeń w postaci wirtualnych kontekstów utworzonych na modularnych przełącznikach), którego zadaniem jest dystrybuowanie sieci LAN poprzez węzeł dostępowy na do infrastruktury serwerowej. Łączy on rdzeń sieci z warstwą dostępową. W przypadku zastosowania urządzeń FEX, węzeł dostępowy będą stanowiły wyniesione moduły przełączników dystrybucyjnych. Zadaniem urządzeń w bloku dystrybucyjnym jest również równoważenie ruchu pomiędzy serwerami aplikacyjnymi i zabezpieczanie dostępu pomiędzy systemami. Zadaniem węzła dystrybucyjnego jest: podłączenie lokalnej grupy zasobów do Węzła rdzeniowego podłączenie serwerów bazodanowych; podłączenie serwerów aplikacyjnych; podłączenie bloków przełączników dostępowych w kasetach (o ile występują) obsługujących serwery aplikacyjne; filtrowanie i inspekcję ruchu sieciowego poprzez blok zapór sieciowych i urządzeń IPS; rozdzielanie ruchu sieciowego do serwerów bazodanowych i aplikacyjnych poprzez blok urządzeń równoważących obciążenie (ang. loadbalancer). Węzeł dostępowe Węzły dostępowe w postaci pary przełączników sieciowych C.LAN.SW.2 (lub wyniesionych modułów FEX przełączników węzła dystrybucyjnego C.LAN.SW.6) będą zlokalizowane w każdej szafie RACK oraz będą podłączone redundantnie do węzła dystrybucyjnego za pomocą połączeń o przepustowości 40Gb/s ( w sumie 4x40Gb/s na szafę). Zadaniem węzła dostępowego jest: podłączenie lokalnej grupy zasobów do Węzła dystrybucyjnego; podłączenie serwerów bazodanowych; podłączenie serwerów aplikacyjnych;

17 podłączenie bloków przełączników kasetowych (o ile występują) obsługujących serwery aplikacyjne; Zakłada się, że przepustowość pojedynczego toru komunikacyjnego pomiędzy ruterem bramkowym a serwerem aplikacyjnym nie może być mniejsza niż 10Gb/s. Połączenia pomiędzy węzłami bramki, rdzenia i dystrybucji muszą być typu full mesh (każdy z każdy) złożone z linków min 10Gb/s. 1.2 Szczegółowe wymagania instalacji, konfiguracji i integracji AI_11. AI_11 opisuję budowę infrastruktury sieciowej bramki. Zgodnie ze standardem opisanym w poprzednim punkcie Wykonawca zobowiązuje się do : a) Przygotowania projektu technicznego infrastruktury w sposób spełniający standard opisany w pkt. Standard budowy infrastruktury sprzętowej dla sieci LAN oraz WAN. b) Dostarczenia sprzętu sieciowego w postaci ruterów dostępowych, przełączników sieciowych, urządzeń równoważących ruch; Lp. Nazwa komponentu Identyfikator komponentu Minimalna liczba komponentów Lokalizacja 1. Rutery C.LAN.RT 6 Narodowy Bank Polski - Centrala NBP Warszawa, ul. Świętokrzyska 11/21 2. Przełączniki dostępowe 24 porty C.LAN.SW.4 6 Narodowy Bank Polski - Centrala NBP Warszawa, ul. Świętokrzyska 11/21 3. Przełączniki dystrybucyjne bramka Internetowa C.LAN.SW.5 2 Narodowy Bank Polski - Centrala NBP Warszawa, ul. Świętokrzyska 11/21 4. Przełączniki dostępowy Top Of the Rack (tor dla ProXY) C.LAN.SW.6 4 Narodowy Bank Polski - Centrala NBP Warszawa, ul. Świętokrzyska 11/21 5. Przełączniki dostępowe 48 portów (Przełącznik dla DMZ) C.LAN.SW.3 4 Narodowy Bank Polski - Centrala NBP Warszawa, ul. Świętokrzyska 11/21 6. Urządzenia równoważące ruch sieciowy typ 2 (globalny LB) C.LAN.LB2 2 Narodowy Bank Polski - Centrala NBP Warszawa, ul. Świętokrzyska 11/21 7. Urządzenia równoważące ruch sieciowy typ 2 (globalny LB) C.LAN.LB2 2 Centrum Przetwarzania Danych Ministerstwa Finansów Ośrodek Przetwarzania Danych w Radomiu, ul. Samorządowa 1 8. Urządzenia równoważące ruch sieciowy typ 1 (lokalny LB) C.LAN.LB1 2 Narodowy Bank Polski - Centrala NBP Warszawa, ul. Świętokrzyska 11/21

18 9. Urządzenia równoważące ruch sieciowy typ 1 (lokalny LB) C.LAN.LB1 2 Centrum Przetwarzania Danych Ministerstwa Finansów Ośrodek Przetwarzania Danych w Radomiu, ul. Samorządowa 1 c) Wyposażenia urządzeń sieciowych w niezbędne do wykonania projektu interfejsy sieciowe z uwzględnieniem 20% zapasu (na każdym z urządzeń sieciowych) każdego rodzaju interfejsu sieciowego przeznaczonego na przyszłą rozbudowę infrastruktury; d) Dostarczenia okablowania sieciowego w postaci patchcordów światłowodowych i miedzianych niezbędnych do połączenia dostarczanej infrastruktury; e) Zainstalowania sprzętu w szafach RACK wskazanych przez Zamawiającego; f) Podłączenia dostarczonych urządzeń sieciowych do instalacji energetycznej zamawiającego w sposób zapewniający redundancję; g) Połączenia poszczególnych urządzeń sieciowych ze sobą według przygotowanego przez Wykonawcę projektu technicznego zaakceptowanego przez Zamawiającego (dopuszcza się zastosowanie C.LAN.SW.6 jako wyniesiony moduł FEX przełącznika C.LAN.SW5); h) Integracji dostarczanych urządzeń z systemami zarządzania posiadanymi przez Zamawiającego; i) Przygotowania scenariuszy testów sprawdzających niezawodność działania infrastruktury w przypadku awarii urządzenia sieciowego z każdego bloku architektonicznego (naprzemiennie), jednego z dwóch torów zasilających (naprzemiennie), połączeń sieciowych pomiędzy warstwami infrastruktury; j) Przeprowadzenia testów sprawdzających niezawodność infrastruktury na wypadek pojedynczego punktu awarii według scenariuszy przygotowanych przez Wykonawcę i zatwierdzonych przez Zamawiającego; k) Przygotowania dokumentacji powykonawczej infrastruktury sieciowej z uwzględnieniem opisu połączeń fizycznych, połączeń logicznych, opisu mechanizmów i funkcjonalności zastosowanych w rozwiązaniu, konfiguracji urządzeń; Wszystkie bloki architektoniczne, z których zbudowana będzie infrastruktura sieciowa muszą być redundantne pod względem zasilania energetycznego, okablowania sieciowego. Pojedynczy punkt awarii jak i działania serwisowe(np. aktualizacji oprogramowania, restart urządzenia) prowadzone na jednym urządzeniu nie może zakłócić działania komunikacji sieciowej wymaganej do prawidłowej pracy systemów. 1.3 Szczegółowe wymagania instalacji, konfiguracji i integracji AI_12. AI_12 opisuję budowę infrastruktury sieciowej węzła rdzenia, węzła dystrybucyjnego i węzła dostępowego. Zgodnie ze standardem opisanym w poprzednim pkt. Standard budowy infrastruktury sprzętowej dla sieci LAN oraz WAN Wykonawca zobowiązuje się do : a) Przygotowanie projektu technicznego infrastruktury w sposób spełniający standard opisany w pkt. Standard budowy infrastruktury sprzętowej dla sieci LAN oraz WAN; b) Dostarczenia sprzętu sieciowego w postaci przełączników sieciowych, urządzeń równoważących ruch;

19 Lp. Nazwa komponentu Identyfikator komponentu Minimalna liczba komponentów Lokalizacja Przełączniki rdzeniowe LAN/WAN 1. Urządzenia równoważące ruch sieciowy typ 1 2. (lokalny LB) Przełączniki dystrybucyjne LAN/WAN 3. Przełączniki dostępowy Top Of the 4. Rack Przełączniki dostępowe 48 portów 5. Przełączniki rdzeniowe 6. (Karta liniowa) C.LAN.SW.1 2 C.LAN.LB.1 2 C.LAN.SW.2 2 C.LAN.SW.6 24 C.LAN.SW.3 6 C.LAN.SW.1 2 Narodowy Bank Polski - Centrala NBP Warszawa, ul. Świętokrzyska 11/21 Narodowy Bank Polski - Centrala NBP Warszawa, ul. Świętokrzyska 11/21 Narodowy Bank Polski - Centrala NBP Warszawa, ul. Świętokrzyska 11/21 Narodowy Bank Polski - Centrala NBP Warszawa, ul. Świętokrzyska 11/21 Narodowy Bank Polski - Centrala NBP Warszawa, ul. Świętokrzyska 11/21 Centrum Przetwarzania Danych Ministerstwa Finansów Ośrodek Przetwarzania Danych w Radomiu, ul. Samorządowa 1 c) Wyposażenia urządzeń sieciowych w niezbędne do wykonania projektu interfejsy sieciowe z uwzględnieniem 20% zapasu (na każdym z urządzeń sieciowych) każdego rodzaju interfejsu sieciowego przeznaczonego na przyszłą rozbudowę infrastruktury; d) Dostarczenia okablowania sieciowego w postaci patchcordów światłowodowych i miedzianych niezbędnych do połączenia dostarczanej infrastruktury; e) Zainstalowanie sprzętu w szafach RACK wskazanych przez Zamawiającego; f) Podłączenia dostarczonych urządzeń sieciowych do instalacji energetycznej zamawiającego w sposób zapewniający redundancję; g) Połączenia poszczególnych urządzeń sieciowych ze sobą według przygotowanego przez Wykonawcę projektu technicznego zaakceptowanego przez Zamawiającego; h) Integracji dostarczanych urządzeń z systemami zarządzania posiadanymi przez Zamawiającego; i) Przygotowania scenariuszy testów sprawdzających niezawodność działania infrastruktury w przypadku awarii urządzenia sieciowego z każdego bloku architektonicznego (naprzemiennie), jednego z dwóch torów zasilających (naprzemiennie), połączeń sieciowych pomiędzy warstwami infrastruktury; j) Przeprowadzenia testów sprawdzających niezawodność infrastruktury na wypadek pojedynczego punktu awarii według scenariuszy przygotowanych przez Wykonawcę i zatwierdzonych przez Zamawiającego; k) Przygotowania dokumentacji powykonawczej infrastruktury sieciowej z uwzględnieniem opisu połączeń fizycznych, połączeń logicznych, opisu mechanizmów i funkcjonalności zastosowanych w rozwiązaniu, konfiguracji urządzeń; Wszystkie bloki architektoniczne, z których zbudowana będzie infrastruktura sieciowa muszą być redundantne pod względem zasilania energetycznego, okablowania sieciowego. Pojedynczy punkt awarii jak i działania serwisowe(w postaci np. aktualizacji

20 oprogramowania, restart urządzenia) prowadzone na jednym urządzeniu nie może zakłócić działania komunikacji sieciowej wymaganej do prawidłowej pracy systemów. AI_17 - System komunikacji SAN w CPD MF a) Dostarczenie i instalacja fizycznych elementów urządzeń SAN- przełączników i okablowania do Ośrodka Przetwarzania w Warszawie (NBP) Narodowy Bank Polski - Centrala NBP Warszawa, ul. Świętokrzyska 11/21. b) Montaż, podłączenie oraz konfiguracja wszystkich dostarczonych elementów przełączników w szafach w pomieszczeniu wskazanym przez Zamawiającego. c) Uruchomienie i konfiguracja przełączników, wykonanie Zone w tym LSAN Zone zgodnie z Projektem Technicznym, d) Dostarczenie i podłączenie okablowania FC oraz modułów SFP. e) Dostarczenie i instalacja licencji na przełącznikach SAN- Warszawa (NBP) f) Dostarczenie i podłączenie niezbędnego okablowania FC - Radom g) Dostarczenie i instalacja licencji na przełącznikach SAN HP SN 8000B- Ośrodek Przetwarzania Radom Centrum Przetwarzania Danych Ministerstwa Finansów Ośrodek Przetwarzania Danych w Radomiu, ul. Samorządowa 1 h) Wykonanie pomiarów dla dostarczonych połączeń światłowodowych. i) Integracja z istniejącą infrastrukturą SB_01Architektura zabezpieczeń sieci 1.1 Standard budowy infrastruktury sprzętowej Wdrożeniem Architektury zabezpieczeń sieci CPD MF jest objęty ośrodek CPD MF Warszawa oraz integracja z ośrodkiem CPD OP Radom. Wdrożony system bezpieczeństwa będzie miał za zadanie kontrolować i separować ruch sieciowy zgodnie z wymaganiami, weryfikować podatności komponentów infrastruktury i systemów biznesowych oraz chronić przed potencjalnymi zagrożeniami, które mogą doprowadzić do naruszenia bezpieczeństwa CPD MF. Główna funkcja realizowana przez system bezpieczeństwa to ochrona urządzeń, systemów i aplikacji w CPD MF poprzez: Ograniczenie ruchu sieciowego do urządzeń, systemów i aplikacji oraz pomiędzy nimi tylko do wymaganych adresów i portów; Monitorowanie i filtrowanie ruchu sieciowego w celu wykrycia anomalii i prób ataku; Zapewnienie dostępu do urządzeń, systemów i aplikacji tylko dla uprawnionych osób posiadających odpowiednie poświadczenia bezpieczeństwa. Zapewnienie wysokiej dostępności poprzez zastosowanie urządzeń redundantnych

21 Spis wymagań dla systemu SB_01 Architektura zabezpieczeń sieci, wraz ze sposobem ich realizacji znajduje się w poniższej tabeli. Lp. Nazwa funkcji Opis funkcjonalności 1. Ograniczenie ruchu sieciowego do wymaganych adresów i portów 2. Klasyfikacja systemów i strefy bezpieczeństwa 3. Monitorowanie ruchu w celu wykrycia ataku Funkcja zostanie zrealizowana poprzez firewalle zewnętrzne i wewnętrzne. Dopuszczony zostanie jedynie ruch sieciowy wymagany do poprawnego działania systemów i aplikacji. Urządzenia zostaną uruchomione w trybie wysokiej dostępności High Availability. Systemy zostały sklasyfikowane i rozmieszczone w różnych strefach bezpieczeństwa, pomiędzy którymi ruch sieciowy jest filtrowany przez firewall. Wszystkie strefy bezpieczeństwa w środowisku CPD MF będą monitorowane przez systemy IDS/IPS (Intrusion Detection System / Intrusion Prevention System). Systemy IDS/IPS będą pracować jako dedykowane urządzenia. 4. Zestawianie tuneli VPN Bezpieczny dostęp zdalny dla administratorów zostanie zapewniony poprzez funkcjonalność tunelu VPN, który można zestawić pomiędzy pracownikiem MF, a systemem CPD MF. 5. Skanowanie podatności Skanowanie podatności urządzeń oraz serwerów w środowisku CPD MF będzie odbywał się przy użyciu dedykowanych urządzeń. Poniżej znajduje się rysunek przedstawiający proponowaną strukturę blokową zawierającą system SB_01 będącą przedmiotem realizacji w CPD MF OP Warszawa.

22 1.2 Szczegółowe wymagania instalacji, konfiguracji i integracji SB_01 opisuje budowę infrastruktury systemu zabezpieczeń sieci. Zgodnie ze standardem opisanym w poprzednim punkcie Wykonawca zobowiązuje się do: a) Przygotowania projektu technicznego infrastruktury; b) Dostarczenia sprzętu sieciowego w postaci Firewall zewnętrzny, Firewall zewnętrzny z funkcjonalnością VPN IPSec Gateway, Firewall wewnętrzny, IPS, System badania podatności, dedykowane konsole do zarządzania urządzeniami Firewall i IPS;

23 c) Wyposażenia urządzeń zabezpieczeń sieci w niezbędne do wykonania projektu interfejsy sieciowe z uwzględnieniem 20% zapasu (na każdym z urządzeń) każdego rodzaju interfejsu sieciowego przeznaczonego na przyszłą rozbudowę infrastruktury; d) Dostarczenia okablowania sieciowego w postaci patchcordów światłowodowych i miedzianych niezbędnych do połączenia dostarczanej infrastruktury; e) Zainstalowania sprzętu w szafach RACK wskazanych przez Zamawiającego; f) Podłączenia dostarczonych urządzeń do instalacji energetycznej zamawiającego w sposób zapewniający redundancję; g) Połączenia poszczególnych urządzeń ze sobą według przygotowanego przez Wykonawcę projektu technicznego zaakceptowanego przez Zamawiającego; h) Integracji dostarczanych urządzeń z systemem SIEM posiadanym przez Zamawiającego; i) Integracji dostarczonych urządzeń Firewall wewnętrzny z istniejącymi w CPD MF OP Radom polegającej na budowie klastra geograficznego złożonego z dwóch klastrów HA pracującego w trybie active-active zarządzanego z jednej konsoli zarządzającej. Zamawiający dopuszcza zastosowanie równoważnego rozwiązania innego producenta niż wdrożone w CPD MF OP Radom. j) Przygotowania scenariuszy testów sprawdzających niezawodność działania infrastruktury w przypadku awarii urządzenia z każdego bloku architektonicznego (naprzemiennie), jednego z dwóch torów zasilających (naprzemiennie), połączeń sieciowych pomiędzy warstwami infrastruktury; k) Przeprowadzenia testów sprawdzających niezawodność infrastruktury na wypadek pojedynczego punktu awarii według scenariuszy przygotowanych przez Wykonawcę i zatwierdzonych przez Zamawiającego; l) Przygotowania dokumentacji powykonawczej infrastruktury systemu zabezpieczeń sieci z uwzględnieniem opisu połączeń fizycznych, połączeń logicznych, opisu mechanizmów i funkcjonalności zastosowanych w rozwiązaniu, konfiguracji urządzeń; Wszystkie bloki architektoniczne z których zbudowana będzie infrastruktura systemu zabezpieczeń sieci muszą być redundantne pod względem zasilania energetycznego, okablowania sieciowego. Pojedynczy punkt awarii jak i działania serwisowe (np. aktualizacji oprogramowania, restart urządzenia) prowadzone na jednym urządzeniu nie może zakłócić działania komunikacji sieciowej wymaganej do prawidłowej pracy systemów. 5. Szczegółowe wymagania w zakresie budowy usługi odtworzenia po katastrofie dla kluczowych usług elektronicznych Resortu Finansów 5.1 Disaster Recovery Disaster Recovery (odtwarzanie po katastrofie) jest częścią Bussiness Countinuity Zapewnienia Ciągłości. W ogólności, dotyczy to ciągłości działania danego przedsiębiorstwa lub instytucji. Żywotną częścią przedsiębiorstwa lub instytucji jest oczywiście IT. Rozwiązania Disaster Recovery skupiają się na przywróceniu przetwarzania po awarii (katastrofie) uniemożliwiającej pracę w Ośrodku Podstawowym. Ośrodek Podstawowy rozumiany jest jako infrastruktura informatyczna (pomieszczenia, zasilanie, serwery, sieć, obsługa itp.) używana w czasie normalnej pracy przedsiębiorstwa lub instytucji.

24 5.2 Disaster Recovery Plan Disaster Recovery Plan (Plan Odtworzenia po Katastrofie)) jest najważniejszym dokumentem w rozwiązaniu DR. Proces tworzenia tego dokumentu jest zasadniczym i nieustającym działaniem w ramach projektu DR. DR Plan opisuje całość rozwiązania i zawiera: analizę ryzyka i wymagań biznesowych, katalog procesów i aplikacji objętych projektem z określeniem ich parametrów DR schemat organizacyjny dla projektu DR w rozróżnieniu na czas zwykłej pracy i czas katastrofy i czas testów przełączenia, scenariusze działania w przypadku katastrofy. Plan Awaryjny jest dokumentem żywym i podlega cyklicznym rewizjom jak również zmianom będącym wynikiem ewolucji organizacyjno technologicznej przedsiębiorstwa Parametry DR Rysunek nr. 1 Parametry DR RTO Recovery Time Objective - Czas, który upływa od katastrofy do odtworzenia przetwarzania; RPO Recovery Point Objective - Aktualność danych odtworzonych po katastrofie, np. dane odtworzone z backupu wykonywanego co noc mają RPO równe 24 godziny; BWO Backup Window Objective - Zaburzenie dostępności systemu produkcyjnego, inaczej mówiąc, jak długa i jak częsta przerwa w przetwarzaniu (jeśli w ogóle) jest możliwa aby wykonać kopię DR; NRO Network Recovery Objective - Czas, który upływa od katastrofy do nawiązania awaryjnych połączeń sieciowych: koniecznych do rozpoczęcia odtwarzania, koniecznych do wznowienia przetwarzania, docelowych po katastrofie; MDL Maximum Data Loss - Maksymalna utrata danych z uwzględnieniem dodatkowych możliwości odtwarzania (logi transakcji, wprowadzenie dokumentów papierowych itp.). Podstawowymi parametrami, którymi operuje się w klasyfikacji poziomów DR są RTO i RPO.

25 W tym zakresie Zamawiający dokonał klasyfikacji systemów biznesowych które będą objęte usługą odtworzenia po katastrofie i wymaga od Wykonawcy aby po zakończeniu wdrożenia usługi odtworzenia po katastrofie poniższe parametry RTO i RPO były zachowane. System biznesowy Poziom DR RTO (h) RPO (min) Zefir2 AS 8 ~0 ES AS 4 ~0 AESAIS AS 8 ~0 HERMES2 AB NCTS2 AB 4 ~0 ISZTAR4 AB 4 ~0 SASISC AB 4 ~0 EMCS2PL AB 4 ~0 edeklaracje Podatnik (Bramka) AA ~0 ~0 edeklaracje Urzędnik AS 12 ~0 TREZOR AS VIES/MOSS AS 12 ~0 epodatki TAP GenTax (PFR) AS 4 ~0 GenTax AS 4 ~0 epodatki/ubd AS 4 ~0 PI AS PDR AS 4 ~0 SZPROT AS 4 ~0 OSOZ2 AS 4 ~0 ZISAR AB 4 ~0 PKI AB 4 ~0 SERCE AB Tabela nr. 1 Poziomy DR Systemów Biznesowych Gdzie oznaczenia AA, AS, AB wskazują na poziom usługi DR: AA Active-Active AS Active-Standby AB Active-Backup Zamawiający poprzez powyższe poziomy rozumie: - AA Active-Active poziom, w którym system biznesowy działa operacyjnie w dwóch ośrodkach przetwarzania. Oznacza to że użytkownicy (klienci) usługi są kierowani za pośrednictwem urządzenia balansującego ruch (GTM) do obu ośrodków przetwarzania na podstawie skonfigurowanych parametrów dotyczących obciążenia infrastruktury systemu w obu ośrodkach. Następnie w obu ośrodkach znajdują się serwery WEB/PROXY (farma), Aplikacyjne (farma) oraz Bazodanowe (klaster) odpowiedzialne za świadczenie danej usługi.

26 Najwyższe wymagania Disaster Avoidance Plan Awaryjny jest zdefiniowany, istnieją udokumentowane procedury testy przełączenia polegają na wyłączeniu z przetwarzania jednego z dwóch aktywnych ośrodków. Dane są stale aktualizowane poprzez mechanizm jednoczesnego zapisu na macierzach w obu ośrodkach (replikacja synchroniczna). Odtwarzanie jest automatyczne. Dane są aktualne. Ośrodek Zapasowy na bieżąco uczestniczy w obciążeniu produkcyjnym. Wyposażenie i personel obu ośrodków są kompletne. Czas odtwarzania zwykle wynosi poniżej 5 minut. Musi istnieć połączenie sieciowe pomiędzy Ośrodkami zapewniające nieznaczące opóźnienia (do 5 ms) dla komunikacji FC. Muszą istnieć połączenia sieciowe umożliwiające działanie produkcyjne w obu ośrodkach oraz rozciągnięta sieć LAN L2. - AS Active-Standby poziom, w którym system biznesowy działa operacyjnie w jednym z dwóch ośrodków przetwarzania. Oznacza to że użytkownicy (klienci) usługi są kierowani za pośrednictwem urządzenia balansującego ruch (GTM) do jednego z dwóch ośrodków przetwarzania. Następnie w aktywnym ośrodku znajdują się serwery WEB/PROXY (farma), Aplikacyjne (farma) oraz Bazodanowe odpowiedzialne za świadczenie danej usługi. W drugim pasywnym ośrodku przetwarzania znajduje się infrastruktura systemu w trybie Standby co oznacza że dane są replikowane synchronicznie a serwery są gotowe do uruchomienia w przypadku przeprowadzenia testów planu awaryjnego lub w przypadku wystąpienia prawdziwej awarii skutkującej przełączeniem do ośrodka pasywnego. Najwyższe wymagania Disaster Recovery Plan Awaryjny jest zdefiniowany, istnieją udokumentowane procedury - testy przełączenia polegają na przełączeniu obsługi systemu z aktywnego ośrodka przetwarzania do pasywnego za pomocą dedykowanego narzędzia (orchestratora). Dane są stale aktualizowane poprzez mechanizm jednoczesnego zapisu na macierzach w obu ośrodkach (replikacja synchroniczna). Odtwarzanie jest automatyczne. Dane są aktualne. Ośrodek Zapasowy nie uczestniczy na bieżąco w obciążeniu produkcyjnym. Wyposażenie i personel Ośrodka są kompletne. Czas odtwarzania zwykle wynosi poniżej czterech godzin. Musi istnieć połączenie sieciowe pomiędzy Ośrodkami zapewniające nieznaczące opóźnienia (do 5 ms) dla komunikacji FC. Muszą istnieć połączenia sieciowe umożliwiające działanie produkcyjne w obu ośrodkach oraz rozciągnięta sieć LAN L2. Muszą być zaimplementowane mechanizmy (orchestrator) automatycznego zarządzania DR. AB Active-Backup - poziom w którym system biznesowy działa operacyjnie w jednym z dwóch ośrodków przetwarzania. Oznacza to że użytkownicy (klienci) usługi są kierowani za pośrednictwem urządzenia balansującego ruch (GTM) do jednego z dwóch ośrodków przetwarzania. Następnie w aktywnym ośrodku znajdują się serwery WEB/PROXY (farma), Aplikacyjne (farma) oraz Bazodanowe odpowiedzialne za świadczenie danej usługi. W drugim pasywnym ośrodku przetwarzania znajdują się zreplikowane asynchronicznie poprzez system backupowy CPD dane systemu i serwery umożliwiające odtworzenie tych danych. W przypadku przeprowadzenia testów planu awaryjnego dane są odtwarzane w drugim ośrodku przetwarzania lub w przypadku wystąpienia prawdziwej awarii skutkującej przełączeniem do drugiego ośrodka. Podwyższone wymagania Disaster Recovery. Plan Awaryjny jest zdefiniowany, istnieją udokumentowane procedury - testy przełączenia polegają na odtworzeniu danych w zapasowym ośrodku przetwarzania za pomocą systemu backupowego CPD. Dane są zabezpieczone kopią zdalną bezpośrednio w Ośrodku Zapasowym Odtwarzanie jest szybkie. Ośrodek Zapasowy musi mieć przynajmniej odpowiednia przestrzeń dyskową (do odbioru kopii zdalnej) Czas odtwarzania zwykle wynosi poniżej czterech godzin Musi istnieć połączenie sieciowe pomiędzy Ośrodkami zapewniające wykonanie asynchronicznej kopii zdalnej zapewniające nieznaczące opóźnienia (do 5 ms) dla komunikacji FC. Muszą istnieć połączenia sieciowe umożliwiające działanie produkcyjne systemu backupu w obu ośrodkach.

27 Rysunek nr. 2 Implementacja procesów DR Procesy Odtwarzania Procesy odtwarzania realizowane są w następujących przypadkach: cykliczne przygotowanie do WERYFIKACJI, testy Planu Awaryjnego, katastrofa ODTWARZANIE / TESTY Proces odtwarzania opisuje czynności niezbędne do podjęcia przetwarzania produkcyjnego w Ośrodku Zapasowym lub przygotowania kopii do weryfikacji. DISASTER RECOVERY PLAN - Podstawowy proces realizacji rozwiązania DR. polegający na przygotowaniu i utrzymaniu Planu Awaryjnego. Scenariusze odtwarzania po katastrofie muszą być ćwiczone według ustalonego harmonogramu. Przyjmuje się, że testy scenariuszy odtwarzania według Planu Awaryjnego powinny być ćwiczone co 6 miesięcy Procesy Wspierające DR Ta grupa procesów ma za zadanie wspomagać realizację zasadniczych procesów DR (wykonania i utrzymywania kopii DR i Odtwarzania). Wdrażanie tych procesów może odbywać się stopniowo i nie musi wystartować od początku projektu. AUTOMATYZACJA Proces realizujący automatyzację procesów przełączenia DR. RAPORTOWANIE I MONITOROWANIE - Proces realizujący raportowanie i monitorowanie przebiegu zasadniczych procesów DR

28 5.2.5 Procesy Wspierające Ośrodka Zapasowego (z punktu widzenia systemu biznesowego) Zamawiający oczekuje aby Ośrodek Zapasowy (z punktu widzenia systemu biznesowego) przygotowany był do realizacji wysokiego poziomu rozwiązania DR. Dlatego istotne jest, aby był wykorzystywany również do celów innych niż tylko DR. I tak, zasoby Ośrodka Zapasowego muszą być wykorzystane do: przejęcia części obciążenia produkcyjnego, testów nowych wersji oprogramowania, testów wydajnościowych i innych. W szczególności, do różnego rodzaju testów nie związanych z DR może być wykorzystana KOPIA PIT (Point in Time), która stanowi replikę środowiska produkcyjnego (po WERYFIKACJI). Procesy Wspierające Ośrodka Zapasowego muszą być wdrażane tak, aby nie zaburzyć podstawowych procesów DR. Musza być też ujęte w Planie Awaryjnym, tak aby na wypadek katastrofy wyłączyć te z nich, które zajmują zasoby potrzebne do przejęcia produkcji przez Ośrodek Zapasowy. Mając powyższe na uwadze Zamawiający oczekuje że część systemów biznesowych wskazanych w tabeli Poziomy DR Systemów Biznesowych będzie działała w ośrodku przetwarzania w Radomiu a część w Warszawie. Wykonawca jest zobowiązany do migracji systemów pomiędzy ośrodkami zgodnie z poniższą tabelą: Nazwa Systemu Lokalizacja edeklaracje Podatnik (Bramka) Radom edeklaracje Urzędnik Radom epodatki TAP GenTax (PFR) Radom GenTax Radom epodatki/ubd Radom SERCE Radom Zefir2 Radom ES Radom TREZOR Radom VIES/MOSS Radom PI Radom SZPROT Radom edeklaracje Podatnik (Bramka) Warszawa AESAIS Warszawa HERMES2 Warszawa NCTS2 Warszawa ISZTAR4 Warszawa EMCS2PL Warszawa PDR Warszawa OSOZ2 Warszawa ZISAR Warszawa PKI Warszawa SASISC Warszawa Tabela nr. 2 Lokalizacja Systemów Biznesowych w trybie operacyjnym Zestawienie bloków architektonicznych składających się na powyższe systemy biznesowe zostało zawarte w załączniku Bloki architektoniczne systemów biznesowych DR.xls. Projekty techniczne ww. systemów znajdują się w załączniku Projekty Techniczne Systemów Biznesowych DR.zip.

29 Jednocześnie Zamawiający informuje że są to systemu żyjące i informacje zawarte w ww. załącznikach mogą ulec zmianie. W szczególności lista wirtualnych maszyn i ich zasobów na poziomie +/- 20 %. 6. Zarządzanie Ciągłością Działania Zarządzanie ryzykiem Wykonawca zobowiązany jest do przeprowadzenia analizy procesów i oceny ryzyka dla systemów biznesowych wskazanych w Tabeli nr. 1 Poziomy DR Systemów Biznesowych. Wynikiem analizy ma być określenie Kluczowych Wskaźników Ryzyka. Kluczowe Wskaźniki Ryzyka to: 1. Zidentyfikowana liczba słabych punków ochrony informacji. 2. Liczba incydentów naruszenia bezpieczeństwa informacji. 3. Udział czasu niedostępności systemu informatycznego. Na podstawie powyższych danych Wykonawca zobowiązany jest do zbudowania bazy danych strat operacyjnych zawierającą ustalony system raportowania strat powstałych w wyniku zaistniałych incydentów operacyjnych oraz określenie sposobu postępowania z ryzykiem. Dane te muszą być są gromadzone poprzez dedykowany system informatyczny (np. hurtownia danych), bądź też, specjalną aplikację raportującą straty z systemów produkcyjnych Analiza ryzyka związanego z krytycznymi zasobami Inwentaryzacja zasobów i grup zasobów będzie realizowana w oparciu o wizje lokalne, informacje zebrane w trakcie wywiadów, analizę infrastruktury technicznej, oraz analizę istniejącej dokumentacji. Inwentaryzacja zakładać będzie następujące podejście: w przypadku zasobów o charakterze unikalnym będą one podlegały jednostkowej inwentaryzacji, w pozostałych przypadkach wyróżniane będą grupy zasobów. Określenie potencjalnych strat, krytycznych procesów i dopuszczalnych czasów przestoju (określenie wpływu ryzyka) obejmować będzie następujące działania: 1. Analizę potencjalnych strat wynikłych z przerwania realizacji działań na wybranych blokach architektonicznych (procesów biznesowych) traktowanych jako funkcja czasu, w tym: - Określenie bezpośrednich i pośrednich strat finansowych, - Określenie materialnych skutków awarii, - Określenie niematerialnych skutków awarii. 2. Określenie propozycji akceptowalnych poziomów strat, 3. Wyróżnienie krytycznych działań (procesów biznesowych), 4. Określenie krytycznych zasobów niezbędnych do realizacji działań (procesów biznesowych), 5. Określenie dopuszczalnego czasu przestoju w realizacji krytycznych działań (procesów biznesowych), uwzględniając poziom RTO i RPO wskazany przez Zamawiającego. Prace analityczne opierać się będą na informacjach zebranych przy użyciu poniżej określonych metod: 1. Analiza istniejącej dokumentacji, 2. Wywiady (przeprowadzane z osobami odpowiedzialnymi za realizację procesów biznesowych), 3. Ankiety i kwestionariusze stanowiące uzupełnienie wywiadów, 4. Analiza wpływu środowiska na wybrane bloki architektoniczne, Straty będą analizowane w funkcji czasu przestoju realizacji procesów, co w konsekwencji pozwoli na określenie dopuszczalnego czasu przestoju. Analizowane przedziały czasowe zostaną ustalone w porozumieniu z Zamawiającym tak, aby odpowiadały one specyfice Zamawiającego.

30 Następnym krokiem w trakcie analizy będzie określenie zasobów krytycznych. Zidentyfikowane zostaną te zasoby informatyczne, które są niezbędne do realizacji określonych w poprzednich krokach procesów mogących zostać uznane za krytyczne. Jako kryterium uznania procesu za krytyczny zostanie przyjęte wystąpienie strat wynikających z przerwania procesu na poziomie nieakceptowanym dla Zamawiającego, przy czym analizowane będą różne scenariusze poziomu strat nieakceptowanych. Ostateczne poziomy strat nieakceptowanych zostaną określone przez Zamawiającego w oparciu o dostarczone przez Wykonawcę dane. W ramach realizacji projektu zostanie przeprowadzona analiza ryzyka w kontekście możliwości utraty dostępności zasobów krytycznych. Podejście takie pozwoli zoptymalizować prace analityczne i skoncentrować się wyłącznie na tych zasobach, które mają lub mogą mieć krytyczne znaczenie dla funkcjonowania systemów wskazanych przez Zamawiającego. Analiza ryzyka obejmować będzie identyfikację: 1. Zagrożeń mogących mieć negatywny wpływ na możliwość realizacji krytycznych procesów przez wybrane bloki architektoniczne (w tym na możliwość zastosowania zasobów krytycznych), 2. Prawdopodobieństwa (lub częstotliwości) wystąpienia tych zagrożeń, 3. Podatności o charakterze organizacyjnym lub technicznym, 4. Ryzyka jako funkcji zagrożeń, podatności i możliwych strat. Prawdopodobieństwo (lub częstotliwość) występowania zagrożeń będzie oceniane przy użyciu miar jakościowych, określających przedziały prawdopodobieństwa występowania zagrożenia (lub częstości występowania zagrożenia). Zalec jest zastosowanie pięciostopniowej skali jakościowej do oceny częstości występowania zagrożeń. Prawdopodobieństwo wystąpienia strat jest oceniane według tej samej skali, jak prawdopodobieństwo wystąpienia zagrożeń, według poniżej określonego algorytmu: 1. W przypadku występowania podatności prawdopodobieństwo wystąpienia strat jest takie samo jak prawdopodobieństwo wystąpienia zagrożenia. 2. W przypadku, gdy podatność ujawnia się tylko w pewnych specyficznych sytuacjach prawdopodobieństwo wystąpienia strat jest mniejsze od prawdopodobieństwa wystąpienia zagrożenia, wartość prawdopodobieństwa wystąpienia strat jest uzależniona od prawdopodobieństwa wystąpienia podatności. 3. W przypadku, gdy podatność nie występuje, straty związane z daną podatnością nie wystąpią. Na bazie opisanej powyżej analizy (określającej prawdopodobieństwo wystąpienia strat), jak również analizy wpływu na biznes (określającej ryzyko wystąpienia strat) określany zostanie zgodnie z modelem przedstawionym w normie AS/NZS 4360, poziom ryzyka przy użyciu następującej skali: Wyniki analizy ryzyka określą jednocześnie zalecenia związane z postępowaniem z ryzykiem. W wyniku analizy ryzyka zostanie określone hierarchia zagrożeń według wartości oszacowanego ryzyka Organizacja zarządzania ciągłością działania W ramach tego obszaru Wykonawca musi przygotować: