Elektroniczne Zarządzanie Dokumentacją
w systemie EZD RP

Architektura infrastruktury EZD RP została zaprojektowana z myślą o wysokiej dostępności, skalowalności oraz bezpieczeństwie. Składa się ona z kilku komponentów, wśród których kluczowe są maszyny wirtualne i technologie kontenerowe. Rozwiązania te odpowiednio skonfigurowane tworzą elastyczne, wydajne i niezawodne środowisko do zarządzania elektronicznym obiegiem dokumentów.

Maszyny wirtualne

Maszyny wirtualne (VM) odgrywają kluczową rolę – ich stosowanie zapewnia m.in. izolację zasobów, przekłada się na elastyczność zarządzania infrastrukturą oraz bezpieczeństwo środowiska.

Główne zadania maszyn wirtualnych w architekturze EZD RP:

• VM pozwalają na efektywne wykorzystanie zasobów serwerowych, umożliwiając uruchamianie wielu instancji systemu operacyjnego na tym samym sprzęcie fizycznym. Dzięki temu możliwe jest skalowanie aplikacji oraz utrzymywanie różnych środowisk (np. testowych i produkcyjnych) na tym samym sprzęcie;
• VM wykorzystywane są do hostowania różnorodnych środowisk uruchomieniowych, takich jak bazy danych, systemy kolejkowe oraz inne usługi wspomagające działanie aplikacji EZD RP. Dzięki temu można łatwo zarządzać zasobami oraz dostosowywać środowisko do zmieniających się potrzeb;
• VM zapewniają izolację między różnymi komponentami systemu, co zwiększa bezpieczeństwo i niezawodność infrastruktury. W razie awarii jednego z komponentów inne pozostają nienaruszone. Minimalizuje to ryzyko przerw w działaniu systemu.

Nie rekomendujemy instalacji komponentów bezpośrednio na sprzęcie fizycznym (tzw. bare metal) ze względu na brak izolacji pomiędzy komponentami systemu, mniejszą niż w przypadku zastosowania VM elastyczność w zarządzaniu zasobami oraz trudności związane ze skalowaniem środowiska. Wykorzystanie wirtualizacji należy do zestawu dobrych praktyk stosowanych podczas wdrożeń EZD RP.

Technologie kontenerowe

Technologie kontenerowe, a zwłaszcza środowisko Kubernetes, odgrywają kluczową rolę w nowoczesnej architekturze EZD RP.

Główne funkcje i zadania rekomendowanego rozwiązania kontenerowego:

• platforma Kubernetes umożliwia szybkie i łatwe wdrażanie aplikacji w różnych środowiskach oraz optymalne wykorzystanie zasobów i automatyczne skalowanie aplikacji w zależności od obciążenia. Jest to ważne w przypadku dużych i złożonych systemów, takich jak EZD RP;
• aplikacje uruchamiane w kontenerach są odizolowane od systemu operacyjnego oraz sprzętu, na którym działają. Dzięki izolacji możliwe jest uruchamianie tych samych aplikacji na różnych serwerach lub w chmurze obliczeniowej, co zapewnia elastyczność i przenośność;
• technologie kontenerowe automatyzują takie obszary zarządzania cyklem życia aplikacji jak wdrażanie nowych wersji, monitorowanie stanu aplikacji i zarządzanie zasobami. Daje to pełną kontrolę nad złożonym środowiskiem produkcyjnym EZD RP;
• aplikacje uruchamiane w kontenerach Kubernetes mogą być łatwo rozmieszczane w wielu węzłach, co zapewnia wysoki poziom dostępności i odporności na awarie. W przypadku awarii jednego z węzłów pozostałe węzły mogą przejąć jego obciążenie bez przerwy w działaniu systemu.

EZD RP zostało zaprojektowane jako elastyczne i otwarte rozwiązanie, które może być wdrażane w różnych środowiskach technologicznych. Zapewnia to odbiorcom dużą swobodę w wyborze narzędzi i technologii. System jest neutralny w stosunku do używanej dystrybucji systemu operacyjnego oraz konkretnej implementacji Kubernetes, co umożliwia dostosowanie infrastruktury do potrzeb i kompetencji organizacji.

Wybór systemu operacyjnego

EZD RP współpracuje z różnymi systemami operacyjnymi, dystrybuowanymi zarówno w wersjach komercyjnych, jak i open source. Dzięki temu instytucje wdrażające EZD RP mogą wybrać rozwiązania, które najlepiej odpowiadają ich wymaganiom w zakresie bezpieczeństwa, kompetencji specjalistów IT oraz budżetu:

• organizacje mogą wybrać system operacyjny, który najlepiej spełnia ich standardy bezpieczeństwa, niezależnie czy jest to dystrybucja Linux, Windows, czy inny system zgodny z wdrożoną polityką bezpieczeństwa.
• EZD RP można wdrożyć na systemie operacyjnym, z którym zespół techniczny jest najbardziej zaznajomiony, a na którym działają wymagane komponenty. Usprawnia i obniża to koszty  zarządzania i utrzymania środowiska.
• w zależności od przeznaczonego na projekt budżetu można wykorzystać darmowe systemy open source lub zdecydować się na komercyjne rozwiązania mające wsparcie producenta.

Wybór implementacji platformy Kubernetes

EZD RP jest neutralne również wobec implementacji Kubernetes, co oznacza, że może być wdrażane i zarządzane za pomocą dowolnej platformy Kubernetes, bez względu na jej pochodzenie i sposób instalacji. Zapewnia to elastyczność wyboru, niezależność od infrastruktury i skalowalność:

• organizacje mogą wybrać implementację Kubernetes, która najlepiej odpowiada ich wymaganiom funkcjonalnym i operacyjnym. Może to być komercyjna platforma z pełnym wsparciem lub darmowe rozwiązanie open source;
• aplikacje EZD RP mogą być uruchamiane w środowiskach Kubernetes działających na różnych systemach operacyjnych – zapewnia to niezależność od konkretnego dostawcy technologii;
• niezależnie od wielkości organizacji EZD RP może być wdrożone w klastrze Kubernetes dostosowanym do aktualnych potrzeb podmiotu, z opcją skalowania w miarę wzrostu infrastruktury i zapotrzebowania na zasoby.

Polityka bezpieczeństwa i utrzymania systemów

Indywidualne wybory dotyczące systemów operacyjnych, dystrybucji Kubernetes oraz innych komponentów infrastruktury niezbędnych do uruchomienia i działania środowiska EZD RP zależą od polityki bezpieczeństwa i utrzymania systemów IT w danej organizacji. W zależności od oczekiwanego poziomu bezpieczeństwa oraz posiadanych kompetencji możliwe jest wykorzystanie:

• darmowego oprogramowania open source;
• oprogramowania open source ze wsparciem producenta (odpłatne subskrypcje);
• komercyjnych rozwiązań w zakresie:
  • relacyjnej bazy danych,
  • klastrowego systemu plików lub repozytorium obiektowego (programowego lub sprzętowego),
  • wirtualizacji infrastruktury,
  • środowiska uruchomieniowego kontenerów Kubernetes.

EZD RP to rozwiązanie, które oferuje dużą neutralność w zakresie wyboru komponentów systemowych. Dzięki temu organizacje mają swobodę w dostosowywaniu infrastruktury do określonych potrzeb, bez konieczności uzależniania się od konkretnego dostawcy technologii czy platformy. Decyzje dotyczące rozwiązań implementowanych w ramach wdrożeń powinny uwzględniać wewnętrzne polityki bezpieczeństwa organizacji oraz utrzymania systemów IT.

Do prawidłowego działania aplikacji serwerowej EZD RP konieczne są wymienione usługi i zasoby (niezależnie od środowiska Kubernetes):

• relacyjna baza danych zgodna z PostgreSQL lub MS SQL oraz konto systemowe umożliwiające utworzenie i korzystanie z bazy danych;
• systemy kolejkowe i buforujące dane: Redis, Rabbit;
• usługa składowania plików w postaci udziału sieciowego NFS lub repozytorium obiektowego (programowego lub sprzętowego) zgodnego z protokołem S3 (np. rozwiązanie open-source, takie jak MinIO);
• publikowana nazwa DNS (publicznie lub wewnętrznie) dla serwera aplikacji EZD RP;
• certyfikat SSL typu Wildcard dla domeny w liczbie odpowiadającej uruchamianym instancjom (np. testowa, preprodukcyjna, produkcyjna);
• usługa wysyłki poczty SMTP i konto umożliwiające korzystanie z tej usługi.

Wybór odpowiedniej architektury dla środowiska uruchomieniowego aplikacji EZD RP jest kluczowy dla zapewnienia równowagi między wydajnością, odpornością na awarie i ponoszonymi kosztami. Im bardziej wydajne i/lub odporne na awarie środowisko, tym większa jest jego złożoność. Organizacje muszą dokładnie przeanalizować swoje potrzeby i zasoby, aby wybrać rozwiązania, które najlepiej spełnią ich wymagania.

Wymagania dotyczące architektury procesorów:

• obsługa 64-bitowej architektury x86;
• wsparcie dla technologii wirtualizacji (np. Intel VT-x, AMD-V), które umożliwiają efektywne przydzielanie vCPU w środowiskach zwirtualizowanych;
• stosowanie procesorów nowej generacji, produkowanych w technologii 10 nm lub nowszej, które zapewniają wysoką wydajność i optymalne zarządzanie energią;
• w przypadku intensywnego korzystania z I/O, rekomendowane jest stosowanie  procesorów wspierających standard PCIe 4.0 lub nowszy – zapewnia to szybką komunikację między procesorem i komponentami systemu, takimi jak dyski SSD NVMe.

Dla podanych poniżej konfiguracji zostały przeprowadzone testy na procesorach z wynikiem 71984 punktów w trybie Dual CPU (wg testów dostępnych na www.cpubenchmark.net).

Jednowęzłowe środowisko Kubernetes połączone z zewnętrznymi usługami baz danych i repozytorium plików

Jednowęzłowe środowisko Kubernetes jest stosunkowo prostym rozwiązaniem, które może być wykorzystywane w mniejszych środowiskach, takich jak testowe, ewaluacyjne, edukacyjne lub deweloperskie. Architektura ta nie jest zalecana do zastosowań produkcyjnych, bez względu na liczbę użytkowników ze względu na brak mechanizmów wysokiej dostępności (HA) i odporności na awarie.

Charakterystyka rozwiązania:

• prostota wdrożenia – jednowęzłowe środowisko Kubernetes jest łatwe do wdrożenia i zarządzania, dzięki czemu jest idealnym wyborem dla środowisk nieprodukcyjnych;
• połączenie z zewnętrznymi usługami – baza danych oraz repozytorium plików są hostowane poza środowiskiem Kubernetes, co pozwala na elastyczne zarządzanie danymi i ich przechowywaniem;
• brak mechanizmów wysokiej dostępności – architektura nie zapewnia redundancji ani odporności na awarie, dlatego nie jest odpowiednia dla krytycznych aplikacji produkcyjnych.

Szczegółowy opis instalacji w Podręczniku użytkownika EZD RP:

Instrukcja instalacji EZD RP – środowiska testowe, rozwojowe lub edukacyjne

Topologia:

Minimalne wymagania sprzętowe:

• procesor: 24 vCPU;
• pamięć RAM: 64 GB;
• przestrzeń dyskowa: minimalnie 2 TB (RAW), 100% przestrzeni na dyskach NVMe/SSD lub 30% przestrzeni na szybkich dyskach NVMe/SSD na potrzeby obliczeń i bufora danych plus 70% przestrzeni na dyskach SSD/HDD na potrzeby przechowywania danych. Należy pamiętać, że docelowa przestrzeń dyskowa jest zależna od planowanego przeznaczenia systemu (szkolenia, testy). W przypadku odwzorowania systemu produkcyjnego do celów testowych dostępna przestrzeń dyskowa jest zależna od liczby przetwarzanych dokumentów w jednostce.

Wielowęzłowe klastrowe środowisko Kubernetes połączone z zewnętrznymi usługami baz danych, systemów kolejkowych i repozytorium plików (skalowalne, redundantne)

Wielowęzłowe klastrowe środowisko Kubernetes jest zalecanym rozwiązaniem dla produkcyjnych wdrożeń EZD RP, które wymagają wysokiej dostępności, skalowalności i odporności na awarie. To idealne rozwiązanie dla dużych instytucji z dużą liczbą użytkowników oraz wymaganiami dotyczącymi ciągłości działania. W tym modelu wiele węzłów Kubernetes współpracuje w ramach klastra, co pozwala na rozproszenie obciążenia i zapewnienie nieprzerwanego działania systemu.

Charakterystyka rozwiązania:

• skalowalność – wielowęzłowa struktura umożliwia obsługę dużej liczby użytkowników i łatwe skalowanie środowiska w miarę wzrostu potrzeb,
• redundancja i odporność na awarie – w przypadku awarii jednego z węzłów pozostałe węzły przejmują jego obciążenie, co zapewnia ciągłość działania systemu,
• integracja z zewnętrznymi usługami – bazy danych, systemy kolejkowe oraz repozytorium plików są obsługiwane poza klastrem Kubernetes, umożliwia to optymalizację zarządzania danymi.

Oprócz środowiska Kubernetes należy zaimplementować relacyjne i nierelacyjne bazy danych, systemy kolejkowe i repozytorium plików oraz wskazać aplikacji EZD RP parametry połączenia do uruchomionych usług.

Szczegółowy opis instalacji w Podręczniku użytkownika EZD RP:

Instrukcja instalacji EZD RP – środowisko produkcyjne

Topologia:

Możliwość modyfikacji architektury

Organizacje, które posiadają wypracowane i wdrożone zaawansowane systemy wysokiej dostępności, mogą rozważyć modyfikację zalecanej architektury zgodnie z potrzebami i specyfiką środowiska. Zachowując zalecane standardy architektury, każda organizacja może dostosować swoje środowisko, aby lepiej odpowiadało wdrożonym politykom bezpieczeństwa, zarządzania ryzykiem i specyficznym wymaganiom operacyjnym.

Konfiguracja, wymagania sprzętowe oraz rekomendowana architektura większych instalacji wymaga kontaktu z konsultantami działu wsparcia technicznego EZD RP. W przypadku organizacji przekraczającej 3000 użytkowników zaleca się dołączenie do klastra (w miarę możliwości) dodatkowych workerów kubernetesowych.

Wymagania zależne od liczby osób jednocześnie pracujących w systemie

Liczba osób	Liczba vCPU	Pamięć RAM
1000	42	90
2000	50	116
5000	92	132
10 000	120	196

 

 

 

 

 

 

Wymagane zasoby dyskowe szacowane dla 1000 użytkowników

Zasób	Rodzaj nośnika	Szacowane zużycie*	Potrzebna przestrzeń dyskowa
Repozytorium plików	NVMe/SSD/HDD**	6,7 GB/tydz.	2,5 TB
Baza danych	NVMe/SSD	1 GB/tydz.	500 GB
Obliczenia (działanie środowiska)***	NVMe/SSD	wartość stała	500 GB

* na podstawie obecnie utrzymywanego środowiska produkcyjnego dla różnego typu instytucji (zróżnicowana charakterystyka przetwarzanych danych)
** w zależności od zastosowanego rodzaju pamięci masowej (NFS, S3, itp.)
*** w zależności od użytej liczby workerów

---

Zasoby rekomendowane dla wdrożeń EZD RP nie uwzględniają dodatkowych wymagań sprzętowych, koniecznych do działania środowiska wirtualizacyjnego, systemów bezpieczeństwa oraz infrastruktury sieciowej.

Podczas dokonywania wyborów dotyczących architektury infrastruktury EZD RP istotne jest uwzględnienie polityki organizacji w zakresie backupów i ciągłości działania. Wybór odpowiedniej architektury powinien być zgodny z wymaganiami dotyczącymi ochrony danych oraz planem przywracania systemu w razie awarii. Jest to szczególnie istotne w przypadku usług przechowujących dane wyniesionych poza klaster Kubernetes, takich jak bazy danych, systemy kolejkowe czy repozytoria plików.

Prawidłowe zarządzanie kopiami zapasowymi oraz procesem przywracania systemu jest kluczowe dla zapewnienia ciągłości działania aplikacji EZD RP, szczególnie w kontekście wysokiej dostępności (HA). Wybór strategii backupu oraz mechanizmów przywracania należy zestawić z oczekiwanymi parametrami RPO (Recovery Point Objective) i RTO (Recovery Time Objective). Pozwoli to zminimalizować ryzyko utraty danych i skrócić czas ewentualnych przestojów w przypadku awarii.

Cel backupów w kontekście wysokiej dostępności (HA)

Celem backupów w kontekście wysokiej dostępności jest zapewnienie, że w przypadku nawet poważnej awarii organizacja jest w stanie szybko przywrócić działanie systemu z minimalną utratą danych. RPO określa maksymalną ilość danych, którą można utracić, podczas gdy RTO definiuje maksymalny dopuszczalny czas potrzebny na przywrócenie systemu do pełnej operacyjności.

Osiągnięcie tych celów wymaga:

• implementacji klastrów w trybie active-active lub active-passive – zapewniają one, że w przypadku awarii jednego z węzłów, inny węzeł automatycznie przejmuje jego rolę i zminimalizuje wpływ incydentu na ciągłość działania systemu;
• zastosowania replikacji danych – wybór między replikacją synchroniczną a asynchroniczną wpływa na czas przywracania danych oraz poziom ich utraty. Replikacja synchroniczna gwarantuje pełną zgodność danych między węzłami, ale może wpłynąć na wydajność. Replikacja asynchroniczna jest szybsza, ale jej zastosowanie może przełożyć się na większą stratę danych w przypadku awarii.

Zalecenia dotyczące backupów

W kontekście systemu EZD RP zaleca się wykonywanie kopii zapasowych jedynie danych persystentnych, które są kluczowe dla działania systemu. Należą do nich:

• relacyjna baza danych – regularne backupy baz danych PostgreSQL/MS SQL są kluczowe dla ochrony danych biznesowych;
• systemy kolejkowe i mechanizmy zarządzania danymi – Redis i Rabbit odgrywają kluczową rolę nie tylko jako systemy cache i kolejkowe, ale również zapewniają ciągłość identyfikatorów oraz innych krytycznych mechanizmów systemu. Regularny backup ich zawartości jest niezbędny dla zachowania integralności i ciągłości operacji systemu po awarii;
• repozytorium plików – kopie bezpieczeństwa danych przechowywanych w udziałach NFS lub repozytoriach obiektowych zapobiegają utracie dokumentów i plików.

Proces przywracania systemu

W przypadku awarii proces przywracania systemu EZD RP musi być przebiegać zgodnie z przyjętą w organizacji polityką w tym zakresie. Wykonywane w określonej kolejności kroki zależą od rodzaju uszkodzeń i elementów, które wymagają przywrócenia. Przedstawiamy ogólne zasady dotyczące odtwarzania danych i przywracania pozostałych elementów środowiska EZD RP.

Odtwarzanie danych z backupów:

• Pierwszym krokiem jest odtworzenie wszystkich danych persystentnych z backupów. Dotyczy to relacyjnych baz danych (PostgreSQL/MS SQL), zawartości systemów kolejkowych i mechanizmów zarządzania danymi (Redis, Rabbit), a także repozytoriów plików (NFS lub repozytorium obiektowe). Te dane są kluczowe dla przywrócenia pełnej funkcjonalności systemu.

Przywracanie pozostałych elementów systemu:

• maszyny wirtualne – mogą być przywrócone z backupów lub, w zależności od scenariusza, ponownie zainstalowane przy użyciu narzędzi automatyzujących, takich jak szablony maszyn wirtualnych.
• środowisko Kubernetes: w przypadku awarii, szybkie ponowne zainstalowanie Kubernetes i podłączenie do odtworzonych usług jest kluczowe.  Do odtwarzania środowiska warto wykorzystać narzędzie, które zapewni automatyzację konfiguracji i wdrożenia aplikacji w środowisku Kubernetes.
• HA Proxy i inne elementy sieciowe – komponenty mogą być ponownie zainstalowane lub skonfigurowane zgodnie z wcześniejszymi opisami, np. za pomocą narzędzi takich jak Ansible lub Terraform.
• kontenery aplikacji EZD RP – mogą być odtworzone poprzez ponowne uruchomienie z wcześniej przygotowanych kontenerów zdefiniowanych w HelmChart. Decyzja dotycząca ponownego uruchomienia lub reinstallacji zależy od specyfiki awarii i tego, czy kontenery zostały uszkodzone.