Nowa architektura EZD PUW Omwienie i prezentacja Agenda

Nowa architektura EZD PUW Omówienie i prezentacja

Agenda • • Wstęp Nowa architektura EZD cz. 1 Cztery modele referencyjne Nowa architektura EZD cz. 2 Architektura niskopoziomowa Architektura wysokopoziomowa Warunki licencjonowania

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 • •

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

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

Nowa architektura EZD Nowe moduły EZD

Nowa architektura EZD Omówienie modułów

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

Modele referencyjne • • Funkcja referencyjna modeli Modele w chmurze prywatnej Modele udostępniane w modelu Saa. S (lub Paa. S) Model lokalny

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 • •

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.

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 • •

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 Regionalny 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.

Modele referencyjne Model Saa. S 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 • •

Modele referencyjne Model Saa. S - 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.

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

Modele referencyjne Porównanie modeli Model centralny Model rozproszony Model Saa. S Model Lokalny Oczekiwana wydajność Średnia Duża Bardzo duża Mała Oczekiwany poziom SLA Wysoki Bardzo wysoki Średni Poziom bezpieczeństwa Standardowy, skalowalny Wysoki Standardowy, skalowalny Koszt utrzymania Średni Wysoki Bardzo niski Niski Koszt wdrożenia Średni Wysoki Bardzo niski Niski Wymagania administracyjne Standardowe Wysokie Bardzo niskie Standardowe

Modele referencyjne Porównanie modeli koszty wdrożenia Model centralny Model rozproszony Model Saa. S Model Lokalny Sprzęt serwerowy Średnie Duże Brak Niski Storage Średnie Brak Niski Standardowy Niski Enviroment Software Średni Wysoki Brak Średni Datacenter Software Średni Wysoki Brak Szkolenia Średni Wysoki Niski Infrastruktura komunikacyjna

Modele referencyjne Porównanie modeli obowiązki administracyjne Model centralny Model rozproszony Model Saa. S Model Lokalny Administracja merytoryczna EZD Partner Administracja techniczna EZD Partner Dostawca Partner Środowisko uruchomieniowe Partner Dostawca Partner Storage Partner Dostawca Partner Sprzęt serwerowy Partner Dostawca Partner Infrastruktura komunikacyjna

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

Architektura wysokopoziomowa Środowisko uruchomieniowe EZD • Microsoft Server 2012 R 2 • Microsoft SQL Server 2014 • Zapis danych do bazy FILESTREAM • Framework. NET 4. 5 • Aktualne JRE (Java) • Dowolny storage

Architektura wysokopoziomowa Podstawy konstrukcji EZD • • • System webowy Technologia. NET Terminale „cienki klient” Budowa modułowa Komunikacja zewnętrzna: ▫ Szyna usług ▫ API systemowe

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 Biz. Talk Server, Oracle ESB, Mule ESB (open source), Fuse ESB (open source), WSO 2 ESB (open source).

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

Architektura wysokopoziomowa Logowanie SSO Jednokrotne logowanie do EZD, systemów dziedzinowych, oraz zasobów LAN. 1. 2. 3. 4. 5. Logowanie użytkownika Przekazany ticket Wysłany ticket Potwierdzony ticket Wysłanie zakresu uprawnień

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

Architektura wysokopoziomowa Wirtualizacja / Hypervisor • Heterogeniczność • Możliwość rozwijania systemów dziedzinowych w dowolnych technologiach • Określenie wymagań • Skalowalność

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)

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

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

Architektura niskopoziomowa Specyfikacje referencyjne • Specyfikacje Minimalne vs Optymalne • Specyfikacje referencyjne dla modeli: ▫ ▫ • • Chmurowy centralny Chmurowy rozproszony Chmurowy Saa. S Lokalny Users: Max Ilość użytkowników pracujących równolegle Docs: Max ilość dokumentów generowanych per miesiąc Data. Growth: Max przyrost danych per miesiąc w % Doc. Weight: Średnia waga dokumentu

Architektura niskopoziomowa Model chmury centralnej Parametr Zasoby storage Zasoby serwerowe Rekomendancja Uwagi Pojemność: 1. 3*1 TB*(1+Data. Growth/12)M Minimalna pojemność 1 TB 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%. onths*Data. Growth IOPS: 500 + Docs Zakładany IOPS przy modelu 80/20 (80% zapisu/ 20% odczytu) 1 lub 2 (replika) serwery o parametrach: Ilość rdzeni = users/10 Minimalna rezerwacja mocy CPU na poziomie odpowiednika 1 GHz dla generacji procesów Intela (E 5 -2650 v 3). RAM: 4 GB dla users < 100, 8 GB dla Users > 100 Maksymalnie 200 użytkowników per 1 serwer (powyżej wymagane są kolejne serwery).

Architektura niskopoziomowa Model chmury rozproszonej Parametr Zasoby storage Zasoby serwerowe Rekomendancja Uwagi Pojemność: 1. 3*1 TB*(1+Data. Growth/12)M Minimalna pojemność 1 TB 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%. onths*Data. Growth IOPS: 500 + Docs Zakładany IOPS przy modelu 80/20 (80% zapisu/ 20% odczytu) x serwerów o parametrach: Ilość rdzeni = users/10 Minimalna rezerwacja mocy CPU na poziomie odpowiednika 1 GHz dla generacji procesów Intela (E 5 -2650 v 3). RAM: 4 GB dla users < 100, 8 GB dla Users > 100 Maksymalnie 200 użytkowników per 1 serwer (powyżej wymagane są kolejne serwery).

Architektura niskopoziomowa Chmura w modelu Saa. S Parametr Zasoby storage Zasoby serwerowe Rekomendancja Uwagi Pojemność: 1. 3*1 TB*(1+Data. Growth/12)M Minimalna pojemność 1 TB 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%. onths*Data. Growth IOPS: 500 + Docs Zakładany IOPS przy modelu 80/20 (80% zapisu/ 20% odczytu). 2 redundantne serwery o parametrach: Minimalna rezerwacja mocy CPU na poziomie odpowiednika 1 GHz dla generacji procesów Intela (E 5 -2650 v 3). Ilość rdzeni = Max. Users/10 RAM: 32 GB RAM Maksymalnie 200 użytkowników per 1 serwer (powyżej wymagane są kolejne serwery).

Architektura niskopoziomowa Serwer dla modelu lokalnego Parametr Zasoby storage Zasoby serwerowe Rekomendancja Uwagi Pojemność: 1. 3*1 TB*(1+Data. Growth/12)M Minimalna pojemność 1 TB 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%. onths*Data. Growth IOPS: 500 + Docs Zakładany IOPS przy modelu 80/20 (80% zapisu/ 20% odczytu) 1 lub 2 (replika) serwery o parametrach: Ilość rdzeni = users/10 Minimalna rezerwacja mocy CPU na poziomie odpowiednika 1 GHz dla generacji procesów Intela (E 5 -2650 v 3). RAM: 4 GB dla users < 100, 8 GB dla Users > 100 Maksymalnie 200 użytkowników per 1 serwer (powyżej wymagane są kolejne serwery).

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

Warunki licencjonowania 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

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 Saa. S, • Utrzymanie usługi w modelu Saa. S (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

Warunki licencjonowania Obowiązki partnera • Zapewnienie infrastruktury serwerowej w każdym z modeli instalacji EZD za wyjątkiem modelu Saa. S, • 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 Help. Desk, • Zorganizowanie zespołu wdrożeniowego i przeprowadzenie działań wdrożeniowych, • Integracje z oprogramowaniem zewnętrznym poprzez API