Nowa architektura EZD PUW

Prezentacja na temat: "Nowa architektura EZD PUW"— Zapis prezentacji:

1 Nowa architektura EZD PUW
Omówienie i prezentacja

2 Agenda Wstęp Nowa architektura EZD cz.1 Cztery modele referencyjne
Architektura niskopoziomowa Architektura wysokopoziomowa Warunki licencjonowania W ramach wprowadzenia do nowej architektury zostanie omowiona struktura nowych modułów, oraz relacje między nimi, wymagania co do środowiska uruchomieniowego, wybrane podsystemy takie jak SSO, API, szyna usług w standardzie ESB, czy nowe modele chmurowe Zagadnienie nowych modeli chmurowych zostanie szerzej omowione w kolejnej czesci, w ramach ktorej zostana przedstawione zarówno modele chmurowe oraz model lokalny. Kolejnym elemente architektury niezbednym do uruchomienia systemu EZD, jest infrastruktura chmurowa, która została podizelona na dwie warstwy. Warstwe niskiego poziomu, czyli warstwe hardware, obejmująca sprzęt serwerowy, storage, oraz infrastrukture sieciową umożliwiającą komunikację w farstwie fizycznej modelu ISO/OSI W ramach punktu dot. waerstwy wysokopoziomowej zostana omowione wymagania, co do uslug utrzymania i zarzadzania srodowiskiem chmurowym W koncowej czesci prezentacji zostana omowione warunki licencjonowania, oraz obszary odpowiedzialnosci za wdrozenie po obu stronach: partnera i dewelopera w postaci urzedu wojewodzkiego w bialymstoku Calosc nie powinna zajac wiecej niż 50-60min.

3 Powody stworzenia nowej architektury
Nowa architektura EZD Powody stworzenia nowej architektury Dynamika ekspansji EZD Wymagania kolejnych partnerów Optymalizacja interfejsu Przygotowanie EZD do integracji z systemami dziedzinowymi Ograniczony potencjał obecnej wersji Głownym powodem przebudowy EZD jest niespodziewanie szybki wzrost ilosci wdrozen, oraz idace za tym wymagania co do nowych funkcjonalnosci, co zwiazane jest przede wszystkim z roznorodnoscia instytucji i podmiotow , które planuja wdrozenie EZD. Wielu partnerów zaangazowalo się również aktywnie w rozwoj systemu, w zwiazku z czym powstało wiele nowych koncepcji rozwoju mechaniki systemowej, oraz obszerna lista zapotrzebowania na nowe funkcjonalnosci, i moduły, które nie były pierwotnie planowane. W zwiazku z powyższym trzeba było przemyslec na nowo architekture sysetmu, a nastepnie przemodelwoac ja w celu zwiekszenia potencjalu rozwoju, aby sprostac obecnym znanym wymaganiom, oraz przygotowac sysetm na przyszle nowe potrzeby partnerow Jednym z wazniejszych aspektow przebudowy było otwarcie systemu na zewnatrrz, glownie poprzez stworzenie podsystemu API, oraz dwóch szyn usług. Każdy z tych elementów pozwala na rozbudowe i dostosowwywanie systemu do potrzeb kolejnych partnerow, tworzenie zewnetrznych systemow dziedzinowych zintegroowancyh z EZD w sposób, który nie narusza głównego pryuncypium rozwoju systemu jakim jest jednolitosc wersji. Pryncypioum to zabrania rozbudowy podstawy systemu poprzez jego modyfikacje. Pryncypium wynika z tego ze bardzo duza roznorodnosc partnerow powoduje koniecznosc dostosowywania szczegolnych funkcjonalnosci pod konkretne wdrozenia. Proba dostosowywania pod kazdego partnera skonczyla by się niemozliwoscia zarzadzania i aktualizacji tak duzej ilosci roznorodnych systemow, co w konsekwencji prowadziloby do wielu problemow. Takich jak niestabilne aktualizacje, koniecznaosc zarzadzania zbyt duza iloscia dokumentacji, itd.. Aby uniknac tych klopotow zdecydowano się zaprojektowac architekture w ktorej dostosowanie sa realizaowane porpzez API i dwie szyny usług. Kolejnym powodem do przebudowania ezd była koniecznosc ujednolicenia interfejsu , który w obecnej wersji jest oglednie mowiąć nieoptymalny. Nowy interfejs obejmuje nowy layout, oraz jest budowany wg scislej logiki w zakresie komponentow, ukladu komponentow, sposobu komunikowania z uzytkownikiem, kolorystyki, uwzglednia przy tym obsluge poprzez interfejs dotykowy, oraz wprowadza szereg zmian poprawiajacych usability.

4 Wymagania nowego EZD Otwarcie API na systemy dziedzinowe
Nowa architektura EZD Wymagania nowego EZD Otwarcie API na systemy dziedzinowe Rozszerzenie EZD o nowe niezbędne moduły Zwiększenie elastyczności systemu Obsługa EZD w modelu chmurowym i lokalnym Poprawa usability Dostarczenie kompletnej dokumentacji: API Wdrożeniowej Użytkowej Referencyjnej specyfikacji infrastruktury Cele jakie postawiono przed projektantami systemu obejmowaly glownie: Wspomniane wczesniej otwarcie na sytemu zewnetrzne Rozszerzenie podstawy EZD o nowe niezbedne moduly, takie jak np. moduł archiwalny, moduł KP (czyli kadry place), modul procesowosci Zwiekszenie elastycznosci systemu rozumiane jako zdolnosci do przebudowy, co wiaze się ze stworzeniem spojnej dokumentacji projektowej, przygotowaniem nowej struktury danych przygotowanych do rozbudowy, przepisaniem kodu w zgodzie z dobrymi praktykami, co w perspektywie umozliwi dalej idace zmiany niż pozwla na to obecna wersja. Wprowadzenie EZD do srodowiska chmurowego , stworzenie mozliwosci wdrożenia i użytkowania EZD w modelu SaaS, czyli jako uslugi hostowanej na infrastrukturze dewelopera Poprawienie usability, poprzez modyfikacje interfejsu, o czy m była mowa wczewsniej Nowa wersja systemu jest udokumentowana w stopniu zdecydowanie wiekszym niż porpzednia wersja, dzieki temu liczymy na obnizenie kosztow rozwoju i utrzymania sytemu, nawet w scenariuszach którech na obecną chwile trudno sobie wyobrazic.

5 15 min. Nowa architektura EZD Wstęp Nowa architektura EZD cz.1
Modele referencyjne Architektura niskopoziomowa Architektura wysokopoziomowa Warunki licencjonowania 15 min. Nowa architektura EZD

6 Nowe moduły EZD Nowa architektura EZD Nowe moduły
Docelowo lokalizacja modułu może się rówżnić, tak jak np. jest z modułem archiwalnym, który będzei jednak zintegrowany z EZD jako zewnetrzny moduł poprzez API

7 Omówienie modułów Nowa architektura EZD Modul archiwalny
ostatecznie będzie porpzez API – modul będzie wspomagal realizzcje instrukcji kancelaryjnej w zakresie obowiązków wykonywanych przeez archiwistów. Moduł umożliwiający przekazywanie elektronicznych akt sprawy do Archiwum Cyfrowego. Moduł zostanie także rozbudowany o elementy umożliwiające archiwizację rejestrów prowadzonych w systemie EZD, i dokumentację nietworzącą akt sprawy, procedurę brakowania, itd. Moduł podpisu elektronicznego – Moduł ma stanowić narzędzie do automatycznej weryfikacji dokumentów elektronicznych opatrzonych podpisem kwalifikowanym, obsłużyc listy TSL, i ma być całkowicie zintegrowany z systemem EZD. Będzie posiadał również możliwość weryfikacji podpisów kwalifikowanych obowiązujących w państwach Unii Europejskiej. Celami bezpośrednimi modułu są: Udostępnienie funkcji automatycznej weryfikacji dokumentów podpisanych cyfrowo bez konieczności podejmowania akcji przez użytkownika. Stworzenie możliwości ręcznej weryfikacji podpisanego cyfrowo dokumentu na żądanie uprawnionego użytkownika. Zapewnienie kontroli dostępu do funkcji autoryzacji dokumentów podpisanych cyfrowo. elektroniczny moduł udostepniania akt sprawy – zewnetrzne webowa aplikacja ktora ma swoje API i wymienia dane z EZD poprzez swoje API - z modulu generowany jest token i haslo i mozna uzyskac dostep do zanonimizowanych danych.moze korzystac z chmury zalacznikow. Moduł umożliwiający wgląd do akt spraw klientom administracji oraz innym podmiotom (np. kontrolnym, sądom) - usługa dostępna także via ePUAP. Szczególną rolą Architekta będzie analiza prawna funkcjonowania modułu w świetle ochrony danych osobowych i wrażliwych oraz opracowanie koncepcji bezpiecznego udostępniania danych bezpośrednio z systemu EZD PUW. integracja z uotlookiem – Moduł będzie pozwalał w sposób zautomatyzowany przenieść wiadomości mailowe z programu pocztowego MS Outlook do EDZ PUW oraz ich rejestrację w rejestrze przesyłek wpływających, prowadzonym w systemie EZD PUW. Dodatkowo moduł będzie umożliwiał realizację wysyłki maili bezpośrednio z akt spraw dokumentowanych w systemie, z jednoczesną, obligatoryjną rejestracją tej czynności w rejestrze przesyłek wychodzących z EZD PUW. moduł procesowaości – Opracowanie i udostępnienie procesów w systemie EZD PUW, automatyzujących wykonywanie czynności kancelaryjnych przy realizacji zadań zewnętrznych i wewnętrznych. Na podstawie analizy procesów poszczególnych partnerów zostaną opracowane zmiany do wykonania w systemie EZD PUW prowadzące do usprawnienia procesów realizowanych przez punkty kancelaryjne. Przygotowanie procesów na żądanie – prosimy o zgłaszanie potrzeb. udostepnienie API – Rozbudowa dostępnych interfejsów oraz przygotowanie API systemu EZD PUW na potrzeby realizacji zadań w projekcie oraz na przyszłość, umożliwiając zarówno integrację z systemami dziedzinowymi, jak też przygotowywanie własnych rozwiązań będących integralną częścią EZD PUW. Moduł BIP – integracja EZD PUW z „centralnym BIP” – SSDIP. Moduł ma umożliwiać bezpośrednie przesyłanie danych i informacji podlegających publikacji z systemu EZD do SSDIP. Dodatkowe interfejsy umożliwiające integrację systemu EZD z własnymi stronami BIP. Ponadto moduł ma zapewnić przesyłanie do Biuletynu Informacji Publicznej Urzędu informacji o stanie konkretnych spraw prowadzonych w urzędzie. Moduł powiadamiania klientów urzędów. – Zintegrowany z EZD PUW poprzez centralną szynę usług z możliwością wykorzystania przez inne systemy urzędu. Moduł z możliwością wysyłania powiadomień mailowych oraz z przygotowanym API do wysyłania powiadomień oraz SMS. modul raportujacy Moduł umożliwi centralizację generowania wszelkich raportów w systemie EZD PUW. Moduł umożliwi zlecanie wykonywania raportów oraz ich cyklicznego zamawiania (np. na maila). Dodatkowo zostanie wprowadzony mechanizm udostępniania raportów na portalach zewnętrznych (np. ezd.gov.pl). Moduł umożliwi centralizację generowania wszelkich raportów w systemie EZD PUW, z możliwością ich planowania oraz cyklicznego zamawiania (np. na maila) lub udostępniania na zewnętrznych portalach czy systemach. Będzie stanowił samodzielną aplikacja wykorzystującą własny serwer z możliwością udostępnienia modułu jako usługi w chmurze. Logowanie zdarzeń Opracowanie i udostępnienie modułu centralnego logowania zdarzeń systemowych EZD PUW, gromadzącego zdarzenia systemowe w pojedynczej lokalizacji i dostarczanie tych informacji do systemu centralnego (PUW). Moduł umożliwi monitorowanie i prowadzenie audytu nad instalacjami systemu EZD PUW. Moduł centralizuje gromadzenie informacji na temat zachowania się systemu w rozproszonych instalacjach EZD PUW. Wyszukiwanie pełnotekstowe. Moduł wyszukiwania pełnotekstowego, umożliwiający szybkie przeszukanie akt spraw dokumentowanych w EZD PUW, w celu odnalezienia szukanej frazy czy dokumentu. Formularze ePUAP do przeglądania on-line publicznych rejestrów prowadzonych w EZD. Opracowanie i udostępnienie formularzy ePUAP do przeglądania on-line publicznych rejestrów prowadzonych w EZD, umożliwiających przeglądanie rejestrów publicznych, prowadzonych indywidualnie przez Partnerów w systemie EZD PUW. CAR – centralna aplikacja raportujaca przez API obustronne po stronie EZD i CARA System CAR zostanie rozbudowany o moduł integracyjny, który będzie umożliwiał wprowadzanie i pobieranie informacji, znajdującej się w systemie CAR przez inne systemy, w szczególności EZD PUW. Rezultatem będzie opracowanie interfejsu/API, które będą umożliwiały innym systemom na pobieranie, edytowanie i usuwanie informacji, obsługiwanej przez system CAR. e-kontrola Na drugim równoległym panelu odbywa się szzegółowa prezentacja tego modułu Moduł e-kontroli będzie stanowić narzędzie informatyczne wspierające proces kontroli realizowanych przez urzędy administracji publicznej użytkujące system EZD PUW. Moduł będzie zintegrowany z systemem EZD PUW, ale jednocześnie będzie stanowił niezależne narzędzie. - Wsparcie całej procedury kontrolnej – od planowania kontroli, poprzez czynności kontrolne, aż do sporządzania niezbędnych raportów i zestawień. - Ułatwienie monitorowania realizacji zadań kontrolnych i zarządzania kadrą kontrolerską. - Zapewnienie zgodności dokumentacji kontrolnej z wymogami prawnymi, w tym w szczególności z postanowieniami ustawy o kontroli w administracji rządowej oraz Standardami kontroli w administracji rządowej. moduł geodezyjno kartograficzny – Moduł będzie zrealizowany w dwóch postaciach: Moduł komunikujący się ze źródłęm danych (źródlem danych będzie geoportal.gov.pl) moduł bedzie zasilal EZD danymi, będzie pozwalal na pobieranie i przetwaarzanie mapek geodezyjnych, planów zagospodarowania przestrzennego, itd.. druga postac, to forma modułu gis – biblioteki w celu integeracji modułu z EZD chmura zalacznikow, „Chmura załączników” to repozytorium do bezpiecznego przechowywania załączników i innych zasobów na potrzeby e-usług oraz elektronicznej komunikacji pomiędzy urzędami. Moduł będzie działał m.in. w „standardzie” ePUAP, tak, aby można było go wykorzystać do pism wysyłanych z EZD PUW przez portal ePUAP. modul kadrowo placowy – osobna alpikacja web - Udostępnienie do końca br. modułów kadrowego i płacowego, zintegrowanych z EZD PUW. portal licencyjny – guest moze przekgladac tylko tresci publiczne partner w postaci administrator lokalnego może generowanie licencje, ktore recznie trzeba przeniesc do EZD administrator lokalny wspomagający, to administrator o ograniczonych prawach. portal będzie tez epelnil funkcje CRM - czyli komunikatora, miedzy partnerami, statystyki

8 10 min. Nowa architektura EZD Wstęp Nowa architektura EZD cz.1
Modele referencyjne Architektura niskopoziomowa Architektura wysokopoziomowa Warunki licencjonowania 10 min. Nowa architektura EZD

9 Modele referencyjne Funkcja referencyjna modeli
Modele w chmurze prywatnej Modele udostępniane w modelu SaaS (lub PaaS) Model lokalny Funkcja referencyjna oznacza, że nie są to wytyczne obligatoryjne, ale zalecenia, oraz modele wymagań minimalnych i optymalnych , bedace punktem odniesienia dla wlasciwych konfiguracji. Będzie to widac to np. w jenym z kolejnych punktow dot. szacunkowych wycen, ktorew dla wieklszosci partnmerow będą z pewnoscia mocno przeszcowane, ponieważ wiele wdrozen będzie możliwych do realziacji na bazie obecnych posiadanych przez partnera komponentow infrastruktury

10 Model centralny Chmura prywatna Architektura klient-serwer
Modele referencyjne Model centralny Chmura prywatna Architektura klient-serwer Centralna baza danych Infrastruktura i środowisko utrzymania chmury po stronie partnera Infrastruktura lokalna po stronie partnera Model przeznaczony dla średnich instytucji

11 Model centralny - administracja
Modele referencyjne Model centralny - administracja Centralny Administrator Merytoryczny Nadaje uprawnienia Raporty centralne Definiuje globalne szablony, raporty, JRWA Centralny Administrator Techniczny Zarządza infrastrukturą sprzętową Tworzy instancje dla jednostek Zarządza kopiami bezpieczeństwa Tworzy instancje testowe Monitoruje system Lokalny Administrator Merytoryczny Zarządza użytkownikami Tworzy lokalne szablony, raporty itp.

12 Model rozproszony Chmura prywatna Architektura klient-serwer
Modele referencyjne Model rozproszony Chmura prywatna Architektura klient-serwer Rozproszona baza danych Infrastruktura i środowisko utrzymania chmury po stronie partnera Infrastruktura lokalna po stronie partnera Model przeznaczony dla dużych instytucji rozproszonych terytorialnie

13 Model rozproszony - administracja
Modele referencyjne Model rozproszony - administracja Centralny Administrator Merytoryczny Nadaje uprawnienia Raporty centralne Definiuje globalne szablony, raporty, JRWA Regionalny Administrator Techniczny Zarządza centralną replikacją danych Centralny monitoring bezpieczeństwa Zarządza infrastrukturą sprzętową Tworzy instancje dla jednostek Zarządza kopiami bezpieczeństwa Tworzy instancje testowe Monitoruje system Lokalny Administrator Merytoryczny Zarządza użytkownikami Tworzy lokalne szablony, raporty itp.

14 Model SaaS Chmura publiczna Architektura klient-serwer
Modele referencyjne Model SaaS Chmura publiczna Architektura klient-serwer Centralna baza danych Infrastruktura i środowisko utrzymania chmury po stronie dostawcy (PUW) Infrastruktura lokalna po stronie partnera Model przeznaczony dla małych instytucji rozproszonych terytorialnie Maksymalizacja SLA

15 Model SaaS - administracja
Modele referencyjne Model SaaS - administracja Centralny Administrator Merytoryczny Nadaje uprawnienia Konfiguruje raporty centralne Definiuje globalne szablony, słowniki, rejestry JRWA, etc. Lokalni Administratorzy Techniczni Administrują terminalami oraz sprzętem peryferyjnym Konfigurują przeglądarki Zapewniają dostęp do sieci WAN Lokalni Administratorzy Merytoryczni Zarządzają kontami użytkowników Tworzą lokalne szablony, raporty itp.

16 Model lokalny Architektura klient-serwer Lokalna baza danych
Modele referencyjne Model lokalny Architektura klient-serwer Lokalna baza danych Serwer i storage po stronie partnera Infrastruktura lokalna po stronie partnera Model przeznaczony dla małych instytucji nie posiadających oddziałów

17 Poziom bezpieczeństwa Wymagania administracyjne
Modele referencyjne Porównanie modeli Model centralny Model rozproszony SaaS Lokalny Oczekiwana wydajność Średnia Duża Bardzo duża Mała Oczekiwany poziom SLA Wysoki Bardzo wysoki Średni Poziom bezpieczeństwa Standardowy, skalowalny Koszt utrzymania Bardzo niski Niski Koszt wdrożenia Wymagania administracyjne Standardowe Wysokie Bardzo niskie Porownanie cech szczegolnych – szczebli, wymagan dot administrowania, SLA, downtime, redundancji, bezpieczenistwa danych

18 Porównanie modeli Modele referencyjne koszty wdrożenia Średnie Duże
centralny Model rozproszony SaaS Lokalny Sprzęt serwerowy Średnie Duże Brak Niski Storage Infrastruktura komunikacyjna Standardowy Enviroment Software Średni Wysoki Datacenter Software Szkolenia Porownanie cech szczegolnych – szczebli, wymagan dot administrowania, SLA, downtime, redundancji, bezpieczenistwa danych

19 Porównanie modeli Modele referencyjne obowiązki administracyjne
centralny Model rozproszony SaaS Lokalny Administracja merytoryczna EZD Partner Administracja techniczna EZD Dostawca Środowisko uruchomieniowe Storage Sprzęt serwerowy Infrastruktura komunikacyjna Porownanie cech szczegolnych – szczebli, wymagan dot administrowania, SLA, downtime, redundancji, bezpieczenistwa danych

20 10 min. Nowa architektura EZD Wstęp Modele referencyjne
Nowa architektura EZD cz.2 Architektura wysokopoziomowa Architektura niskopoziomowa Warunki licencjonowania 10 min. Nowa architektura EZD

21 Środowisko uruchomieniowe EZD
Architektura wysokopoziomowa Środowisko uruchomieniowe EZD Microsoft Server 2012 R2 Microsoft SQL Server 2014 Zapis danych do bazy FILESTREAM Framework .NET 4.5 Aktualne JRE (Java) Dowolny storage

22 Podstawy konstrukcji EZD
Architektura wysokopoziomowa Podstawy konstrukcji EZD System webowy Technologia.NET Terminale „cienki klient” Budowa modułowa Komunikacja zewnętrzna: Szyna usług API systemowe Warstwy architektury EZD. Kazda z warstw może stanowi integralna czesc architektury, ale może byc rekonfigurowana w pewnym okreslonym zakresie. Np.. Konfiguracja sprzetowa może być wyskalowana i rozszerzana pod potrzeby i mozliwosci partnera Srodowisko uruchomieniowe może być prenoszone z instalacji lokalnejk do chmury - system ezd może być modyfimowany w zakresie modulow , i konfiguracji instancji Systemy zewnetrzne mogą być swobodnie dolaczane lub odlaczane od szyny uslug i API komunikacyjnego Calosc ma dzialac sprawnie zarówno w duzych konfuguracjach , takich jak LP , oraz w małych lokalnych konfuiguracjach, jak np. szkoły

23 Szyna usług EZD Zdolność do integracji Szyna wewnętrzna
Architektura wysokopoziomowa Szyna usług EZD Zdolność do integracji Szyna wewnętrzna Szyna zewnętrzna Komunikacja między szynami Standard ESB Kompatybilność m.in. Microsoft BizTalk Server, Oracle ESB, Mule ESB (open source), Fuse ESB (open source), WSO2 ESB (open source). Szyna usług, to dodatkowa zewnętrzn warstwa pośrednia w wielowarstwowej architekturze EZD umożliwiająca realizująca założenia architektury SOA w jego środowisku. Umożliwia dynamiczne przyłączanie i odłączanie usług wchodzących w skład ssytemu. Nowa architektura zakłąda funkcjonowanie dwóch powiązanych ze soba szyn: Zewnętrznej Wewnetrznej Szyna zewnętrzna , jak nawzwa sama wskazuje, służy do integracji usług/modułów zewnętrznych, natomiast szyna wewnętrzna służy do podłaczania modułów wewnętrznych. De facto poprzez szyne wewnętrzna system będzie rozbudowywany. Komunikacja z rdzeniem systemu , oraz komunikacja międzymodułowa, będą realizowane poprzez ten własnie interfejs. Zalozeznia architektury przewidują również mozliwosc komunikowania się obu podsystemów: szyny zew i szyny wew. Dzieki temu możliwy będzie routing usług pomiędzy modułami zewnętrznymi i modułami wewnętrznymi. Sdzyna będzie komunikowała się w standardzie ESB, ddzieki czemu uzyskamy wysoki poziom interoperacyjnosci z oprogramowaniem zewnętrznym, i otwieramy w tem sposób mozliwosc rozwoju modulow zewnetrznych w dowolnej technologii. Zewnet6rzna Szyna usług umozliwi również integracjje poprzez dowolna z popularnych platform integracyjnych takich jak Biztalk server Oracle esb, lub z rozwiazan opensoursowych np. popularne mule ESB Szuna danych jest podystemem, który w znaczacy sposób otwiera EZD na swiat zewnetrzny i zwieksza interoperacyjnosc.

24 Architektura wysokopoziomowa
Interfejs API Komunikacja z systemami zewnętrznymi oraz modułami dodatkowymi EZD Bezpieczeństwo transmisji danych poprzez szyfrowanie komunikacji Administracja i zarządzanie dostępem Rejestrowanie aktywności modułów oraz systemów zewnętrznych Omowiony zostanie tylko ogolny zarys podsystemu API, ponieważ szczegolowe informacje zostana przekazane w dniu na jutrzejszym panelu o godz. 9:30. Ogólnie rzecz ujmując interfejs umożliwia komunikacje systemu z otoczeniem, i jest modułem nadrzędnym w stosunku do szyny usług. Dzięki opracowaniu API możliwe będzie tworzenie dodatkowych modułów rozszerzających funkcjonalność systemu EZD PUW bez ingerencji w sam system (architekturę, kod źródłowy, itp.) , zapewniając jednocześnie bezpieczeństwo danych oraz rejestracje wszystkich połączeń z systemów lub modułów zewnętrznych. Moduł będzie też regulował dostęp użytkowników do systemów udostępniających zasoby na podstawie stanowiska zajmowanego w jednostce administracyjnej.

25 Architektura wysokopoziomowa
Logowanie SSO Jednokrotne logowanie do EZD, systemów dziedzinowych, oraz zasobów LAN. Logowanie użytkownika Przekazany ticket Wysłany ticket Potwierdzony ticket Wysłanie zakresu uprawnień Single sign-on pozwoli użytkownikom na korzystanie ze wszystkich systemów i zasobów za pomocą jednorazowego logowania się do usługi sieciowej i uzyskania w ten sposób dostępu do całego środowiska EZD , systemów dziedzinowych, oczywiście samego EZD, usług katalogowych LDAP i dowolnych innych zgodnych z tym mechanizmem.. SSO pozwala również na zdefiniowanie uprawień użytkownika na poziomie domeny w ramach Active Directory. Oczywiście zarzadzadzanie rolami i grupami uprawnien pozostaje ciagle w gestii systemu EZD. Wszyscy użytkownicy posiadają swoje dane uwierzytelniającew tej strukturze. mogą one być przechowywane np. w katalogu LDAP, Generalnie mechanizm jest zaprojektowany w celu skrócenia czasu poświęcanego na logowanie i przelogowywanie użytkownika do kolejnych systemów. Proces uwierzytelniania odbywa się w pieciu krokach: 1. uzytkownik loguje się do domeny poprzez uruchomienie systemu Windows na swoim komputerze 2. Serwer domeny po poprawnej autoryzacji zwraca użytkownikowi ticket, który będzie wykorzystywany do automatycznej autoryzacji do kolejnych systemów W przypadku uruchomienia EZD , komputer użytkownika wysyła automatycznie ticket do systemu EZD w celu zalogowania EZD (lub dowolny inny system) potwierdza na serwerze domenowym uprawnienia uzytkownika, a nastepnie… Wysyla zestaw uprawnien uzytkownika do EZD Taka sama procedura nastepuje dla kolejnych systemow dziedzinowych. Generalnie dzieki temu mechanzimowi użytkownik loguje się tylko jeden raz do systemu windows, a dalej jego dane logowania oraz uprawnienia sa automatycznie przekazywane do kolejnych ssytemow.

26 10 min. Nowa architektura EZD Wstęp Nowa architektura EZD cz.2
Modele referencyjne Architektura wysokopoziomowa Architektura niskopoziomowa Warunki licencjonowania 10 min. Nowa architektura EZD

27 Wirtualizacja / Hypervisor
Architektura wysokopoziomowa Wirtualizacja / Hypervisor Heterogeniczność Możliwość rozwijania systemów dziedzinowych w dowolnych technologiach Określenie wymagań Skalowalność Zastosowanie wirtualizacji ma sens w każdym przypadku, choćby w celu wytworzenia wygodnych autonomicznych instancji szkoleniowych. Oczywiście w przypadku gdy nie chemy kozystac z zalet wirtualizacji instancje mogą być również postawione na jednym IIS’ie (lub innym serwerze) , lub na roznych fizycznych serwerach. Natomiast decydując się na srodowisko wirtualizowane powinnismy zadbac aby wybrane rozwiazanie: Posiadalo zdolniosc do uruchamiania różnych OS możliwość rozwijania narzędzia niezależnie od platformy: .NET , java, php, itd. Integrowało się z oprogramowaniem zarzadzajacym chmura, np. w celu monitoringu Było skalowalne, aby w przypadku potrzeby rozszerzenia zakresu uslug moglo sprostac rosnacym wymaganiom I oczywiście obslugiwalo architekture x86 , x64 oraz pochodne W zwiazku z tym ze platformą uruchomieniową dla EZD jest windows serwver , to naturalnym wyborem staje się Hyper-V , ale z innymi rozwiazaniami takimi jak VMWare ,VirtualBox czy Xen również będzie działać jeśli spelnia minimalne wymagania.

28 Wymagania infrastruktury chmurowej
Architektura wysokopoziomowa Wymagania infrastruktury chmurowej System zarządzania infrastrukturą i oprogramowaniem System zarządzania komponentami System zarządzania środowiskami wirtualnym System tworzenia kopii zapasowych System automatyzacji zarządzania środowisk IT System zarządzania incydentami i problemami (monitoring) Zarządzanie serwerem musi obejmować wszystkie funkcje zawarte w opisanych poniżej modułach: System zarządzania infrastrukturą i oprogramowaniem Inwentaryzacja i zarzadzanie zasobami serwera Monitoring wykorzystania zasobow Raportowanie i prezentacja statystyk System zarządzania komponentami Możliwość budowania struktury wielopoziomowej (tiers) w celu separacji pewnych grup komputerów/usług. Kanał komunikacyjny pomiędzy klientami a serwerem zarządzającym powinien być szyfrowany. System musi udostępniać komponenty i funkcje pozwalające na zbudowanie systemu zbierającego zdarzenia związane z bezpieczeństwem monitorowanych systemów Automatyzacja porzez tworzenie reguł i skryptów wyzwalanych przez triggery monitoringu Zalecana obsługa obiektów SLO (Service Level Object) służących przedstawianiu informacji dotyczących zdefiniowanych poziomów SLA (Service Level Agreement). W przyszłości być może EZD będzie posiadało triggery do tej funkcjonalnosci. I oczywiście podstawowa funkcja Przechowywania i dostępu do informacji System zarządzania środowiskami wirtualnym System musi mieć możliwość tworzenia konfiguracji wysokiej dostępności (klaster typu fail-over). Konsola musi umożliwiać wykonywanie codziennych zadań związnych z zarządzaniem maszynami wirtualnymi w sposób jak najbardziej intuicyjny Tworzenie maszyn wirtualnych z szablonów System musi umożliwiać przenoszenie maszyny wirtualnej pomiędzy zarządzanymi hostami: w trybie migracji „on-line” – bez przerywania pracy, w trybie migracji „off-line – z zapisem stanu maszyny System musi umożliwiać automatyczne, równomierne rozłożenie obciążenia pomiędzy zarządzanymi hostami. System musi umożliwiać przełączenie wybranego hosta w tryb „maintenance” w przypadku wystąpienia awarii lub w celu przeprowadzenia planowanych prac serwisowych. Uruchomienie tego trybu musi skutkować migracją maszyn na inne hosty lub zapisaniem ich stanu. System musi pozwalać na skalowalność wirtualnego środowiska aplikacji (poprzez automatyczne dodanie wirtualnej maszyny z aplikacją) System tworzenia kopii zapasowych System kopii zapasowych musi umożliwiać: zapis danych na puli magazynowej złożonej z dysków twardych zapis danych na bibliotekach taśmowych Obsługa backupów przyrostowych System kopii zapasowych powinien umożliwiać przywrócenie: danych plikowych danych aplikacyjnych stanu systemu (Systemstate) obrazu systemu operacyjnego (tzw. Bare Metal Restore) Harmonogramowanie backupów System automatyzacji zarządzania środowisk IT System automatyzacji zarządzania środowisk IT musi udostępniać środowisko standaryzujące (bezskryptowe – oparte o reguły) i automatyzujące zarządzanie środowiskiem: System musi umożliwiać testowanie sytuacji krytycznych i występowanie różnych incydentów w systemie. System musi wspomagać automatyzację procesów zarządzania zmianami konfiguracji środowisk IT. System musi wspomagać planowanie i automatyzację wdrażania poprawek. System musi umożliwiać zarządzanie życiem środowisk wirtualnych. System musi udostępniać mechanizmy workflow automatyzujące zadania administracyjne wraz graficznym interfejsem projektowania, budowy i monitorowania worklow. System zarządzania incydentami i problemami System, poprzez integrację z systemami zarządzania i monitorowania musi zapewniać: Optymalizację procesów i ich prawidłową realizację poprzez predefiniowane scenariusze, zgodne z najlepszymi praktykami i założoną metodyką, Redukcję czasu rozwiązywania problemów z działaniem systemów poprzez zapewnienie dotarcia właściwej, zagregowanej informacji do odpowiedniego poziomu linii wsparcia, Automatyczne generowanie opisu problemów na bazie alarmów i kojarzenie zdarzeń w różnych komponentach systemu, Wspomaganie procesów podejmowania decyzji poprzez integrację informacji i logikę ich powiązania, Planowanie działań prewencyjnych poprzez kolekcjonowanie informacji o zachowaniach systemu w przypadku incydentów, Raportowanie pozwalające na analizy w zakresie usprawnień systemu oraz usprawnień procesów ich opieki serwisowej, Tworzenie baz wiedzy na temat rozwiązywania problemów, Automatyzację działań w przypadku znanych i opisanych problemów, Wykrywanie odchyleń od założonych standardów ustalonych dla systemu. Ochrona antymalware Ochrona przed zagrożeniami typu wirusy, robaki, Trojany, rootkity, ataki typu phishing czy exploity zero-day Automatyzacja , tak jak np. orchestrator w Microsoft Datacenter Data Protection Manager 2012 – komponent zapewniający ochronę hosta, maszyn wirtualnych, aplikacji – tworzenie backupu wszystkich elementów infrastruktury

29 10 min. Nowa architektura EZD Wstęp Nowa architektura EZD cz.2
Modele referencyjne Architektura wysokopoziomowa Architektura niskopoziomowa Warunki licencjonowania 10 min. Nowa architektura EZD

30 Wymagania infrastruktury lokalnej
Architektura niskopoziomowa Wymagania infrastruktury lokalnej Dostęp zdalny do EZD Terminale z przeglądarką Drukarki kodów kreskowych Czytniki kodów Skanery dokumentów Oprogramowanie skanujące Zainstalowany dodatek Addin zaczniemy w odwrotnej kolejnosci, od najnizszej warstwy infrastruktury lokalnej W kazdym z modeli chmurowych musi zostac zapewniony sprzet i oprogramowanie dla uzytkownikow koncowych w oddzialach

31 Specyfikacje referencyjne
Architektura niskopoziomowa Specyfikacje referencyjne Specyfikacje Minimalne vs Optymalne Specyfikacje referencyjne dla modeli: Chmurowy centralny Chmurowy rozproszony Chmurowy SaaS Lokalny Na kolejnych slajdach zostana przedstawione rozne modele OPTYMALNE. Sa to tylko konfiguracje referencyjne ,dodatkwowo w wielu przypadkach zapewne nadmiarowe, ponieważ zakładamy, że serwerownia jest budowana od zera . Zazwyczaj można wykorzystać już użytkowaną infrastrukturę, co znacząco obniża koszt wdrożenia. Docelowo w dokuemntacji wdrozeniowej będzie zawarty kalkulator pozwalajacy wyliczyc szacunkowy koszt wdrozenia pod konkretne wymagania. Jeśli chodzi o parametryzacje , to do skonfigurowania rozwiązania niskopoziomowego należy zdefiniowanc parametry takie jak np. pokazane na slajdzie, a dodatkwowo.. Należy także wziąć pod uwage wymagany poziomu dostępności usługi oraz wrażliwość na potencjalną utratę danych. Należy zdefiniować miejsce przechowywania informacji oraz kopii zapasowych. W przypadku gdy krytyczne staje się wysokie SLA, to należy wprowadzic rozwiązania redundantne i skonfigurowac uslugi monitoringu i bezpieczenstwa, aby migracje systemu na serwery zapasowe mogły być wykonywane w sposób niezauwazalny przez uzytkownika. Rozwiązanie może być od dowolnego dostawcy. Nie narzucamy rozwiązania. W dokumentacji wdrozeniowej rekomendujemy tylko specyficzne cechy które powinno zawierać wybrane rozwiązanie. Podane szacunkowe koszty sa oparte o uśrednione ceny dostawców: Cisco, IBM, Lenovo, HP. Users: Max Ilość użytkowników pracujących równolegle Docs: Max ilość dokumentów generowanych per miesiąc DataGrowth: Max przyrost danych per miesiąc w % DocWeight: Średnia waga dokumentu

32 Model chmury centralnej
Architektura niskopoziomowa Model chmury centralnej Parametr Rekomendancja Uwagi Zasoby storage Pojemność: 1.3*1TB*(1+DataGrowth/12)M onths*DataGrowth IOPS: Docs Minimalna pojemność 1TB DAS/SAN lub NAS, dostępna dla użytkownika po uwzględnieniu redundancji np. RAID 5/6 lub innych. Należy dodatkowo uwzględnić nadmiarowość dla operacji na danych na poziomie 30%. Zakładany IOPS przy modelu 80/20 (80% zapisu/ 20% odczytu) Zasoby serwerowe 1 lub 2 (replika) serwery o parametrach: Ilość rdzeni = users/10 RAM: 4GB dla users < 100, 8GB dla Users > 100 Minimalna rezerwacja mocy CPU na poziomie odpowiednika 1GHz dla generacji procesów Intela (E v3). Maksymalnie 200 użytkowników per 1 serwer (powyżej wymagane są kolejne serwery). Założenia co do ilosci danych, dokumentów, i jednoczesnych userów 1000 użytkowników jednoczesnie online dokumentów wpływających rocznie Miesieczny przyrost danych na poziomie 1GB Przeznaczenie co do podmiotu który powinien wdrażac ten model Srednie i duze podmioty posiadajace oddzialy terenowe Centralne datacenter musi być zbudowane aby obsluzyc caly ruch, wiec dodatkwoe wymaganie jest zwiazane z potrzeba zapewnienia reduntnantnego łacza internetowego o odpowiedznich parametrach i niskim wspolczynniku downtime.

33 Model chmury rozproszonej
Architektura niskopoziomowa Model chmury rozproszonej Parametr Rekomendancja Uwagi Zasoby storage Pojemność: 1.3*1TB*(1+DataGrowth/12)M onths*DataGrowth IOPS: Docs Minimalna pojemność 1TB DAS/SAN lub NAS, dostępna dla użytkownika po uwzględnieniu redundancji np. RAID 5/6 lub innych. Należy dodatkowo uwzględnić nadmiarowość dla operacji na danych na poziomie 30%. Zakładany IOPS przy modelu 80/20 (80% zapisu/ 20% odczytu) Zasoby serwerowe x serwerów o parametrach: Ilość rdzeni = users/10 RAM: 4GB dla users < 100, 8GB dla Users > 100 Minimalna rezerwacja mocy CPU na poziomie odpowiednika 1GHz dla generacji procesów Intela (E v3). Maksymalnie 200 użytkowników per 1 serwer (powyżej wymagane są kolejne serwery). Założenia co do ilosci danych, dokumentów, i jednoczesnych userów 15000 użytkowników jednoczesnie online dokumentów wpływających rocznie Miesieczny przyrost danych na poziomie 10GB Przeznaczenie co do podmiotu który powinien wdrażac ten model duze podmioty posiadajace rozbudowana hierarchie, oraz liczne oddzialy terenowe Dopuszcalny jest model w ramach którego struktura jest homogeniczna i sklada się z takich samych datacenter musi być zbudowane aby obsluzyc caly ruch, wiec dodatkwoe wymaganie jest zwiazane z potrzeba zapewnienia reduntnantnego łacza internetowego o odpowiedznich parametrach i niskim wspolczynniku downtime.

34 Chmura w modelu SaaS Architektura niskopoziomowa
Parametr Rekomendancja Uwagi Zasoby storage Pojemność: 1.3*1TB*(1+DataGrowth/12)M onths*DataGrowth IOPS: Docs Minimalna pojemność 1TB DAS/SAN lub NAS, dostępna dla użytkownika po uwzględnieniu redundancji np. RAID 5/6 lub innych. Należy dodatkowo uwzględnić nadmiarowość dla operacji na danych na poziomie 30%. Zakładany IOPS przy modelu 80/20 (80% zapisu/ 20% odczytu). Zasoby serwerowe 2 redundantne serwery o parametrach: Ilość rdzeni = MaxUsers/10 RAM: 32GB RAM Minimalna rezerwacja mocy CPU na poziomie odpowiednika 1GHz dla generacji procesów Intela (E v3). Maksymalnie 200 użytkowników per 1 serwer (powyżej wymagane są kolejne serwery). Model jest przeznaczony dla podmiotó które chcą hostować system EZD dla mniejszych partnerów. Na chwilę obecną tylko urząd wojewodzki w bialymstoku będzie pelnil role hosta, i będzie udostepnial innych partnerom EZD w usłudze SaaS Partnerzy którzy będą korzystali z tego modelu dostęu do EZD to instytucje małe, lub instytucje dla których sysetm EZD nie bedzei sysetmem podstawowym. W modelu tym koszt infrastruktury niskopoziomowej dla partnera wynoisi okrągłe zero złotych, ponieważ nie płaci on za infrastrukturę, ani za jej utrzymanie, nie płaci również za licencje na oprogramiowanie serwerowe, ani za licencje na Aplikacje. Jedyne koszty jakie ponosi partner są zwiazane z kosztami wdrozenia.

35 Serwer dla modelu lokalnego
Architektura niskopoziomowa Serwer dla modelu lokalnego Parametr Rekomendancja Uwagi Zasoby storage Pojemność: 1.3*1TB*(1+DataGrowth/12)M onths*DataGrowth IOPS: Docs Minimalna pojemność 1TB DAS/SAN lub NAS, dostępna dla użytkownika po uwzględnieniu redundancji np. RAID 5/6 lub innych. Należy dodatkowo uwzględnić nadmiarowość dla operacji na danych na poziomie 30%. Zakładany IOPS przy modelu 80/20 (80% zapisu/ 20% odczytu) Zasoby serwerowe 1 lub 2 (replika) serwery o parametrach: Ilość rdzeni = users/10 RAM: 4GB dla users < 100, 8GB dla Users > 100 Minimalna rezerwacja mocy CPU na poziomie odpowiednika 1GHz dla generacji procesów Intela (E v3). Maksymalnie 200 użytkowników per 1 serwer (powyżej wymagane są kolejne serwery). Model lokalny jest przeznaczony dla małych podmiotów zlokalizowanych w jednej siedzibie i skomuniklowanych poprzez LAN

36 5 min. Nowa architektura EZD Wstęp Nowa architektura EZD cz.2
Modele referencyjne Architektura wysokopoziomowa Architektura niskopoziomowa Warunki licencjonowania 5 min. Nowa architektura EZD

37 Warunki Licencjonowania
Licencja na użytkowanie jest darmowa Możliwość uruchomienia dowolnej ilości instancji: Produkcyjna Szkoleniowa Testowa Darmowe aktualizacje Pełna możliwość rozbudowywania EZD poprzez API Zakaz modyfikowania EZD poprzez zmiany w kodzie Założenia co do ilosci danych, dokumentów, i jednoczesnych userów Przeznaczenie co do podmiotu który powinien wdrażac ten model

38 Obowiązki Dewelopera (PUW)
Warunki licencjonowania Obowiązki Dewelopera (PUW) Udostępnienie systemu EZD do użytkowania, Zapewnienie wsparcia powdrożeniowego dla Partnerów w postaci aktualizacji, Dostarczenie dokumentacji systemu, użytkownika, administratora, API Dostarczenie szablonów konfiguracji systemu EZD, Oddelegowanie zespołu wspierającego wdrożenie u Partnera, Utrzymanie i udostępnienie zespołu konsultantów wsparcia merytorycznego, Zapewnienie infrastruktury sprzętowej w przypadku instalacji EZD w modelu SaaS, Utrzymanie usługi w modelu SaaS (konserwacje sprzętu serwerowego, aktualizacje, zapewnienie ciągłości działania usługi), Niewielkie dostosowania systemu do potrzeb Partnera, ze szczególnym uwzględnieniem pryncypium jednolitości systemu Założenia co do ilosci danych, dokumentów, i jednoczesnych userów Przeznaczenie co do podmiotu który powinien wdrażac ten model

39 Warunki licencjonowania
Obowiązki partnera Zapewnienie infrastruktury serwerowej w każdym z modeli instalacji EZD za wyjątkiem modelu SaaS, Zapewnienie infrastruktury w oddziałach i jednostkach lokalnych, Zapewnienie infrastruktury komunikacyjnej na wszystkich szczeblach (centralnym, regionalnym i lokalnym), Utrzymanie infrastruktury sprzętowej i komunikacyjnej, Konfiguracja szczegółowa środowiska pracy serwera systemu EZD, oraz środowisk pracy końcówek użytkowników, Przeszkolenie użytkowników, Zorganizowanie, uruchomienie i utrzymanie działu wsparcia HelpDesk, Zorganizowanie zespołu wdrożeniowego i przeprowadzenie działań wdrożeniowych, Integracje z oprogramowaniem zewnętrznym poprzez API Założenia co do ilosci danych, dokumentów, i jednoczesnych userów Przeznaczenie co do podmiotu który powinien wdrażac ten model