Obowiązek od 1 stycznia 2028 r. Każda jednostka sektora publicznego musi prowadzić sprawy w systemie klasy EZD. EZD RP spełnia ten wymóg bezpłatnie. Sprawdź gotowość

Konfiguracja

Wymagania sprzętowe EZD RP: serwer i konfiguracja sieci

EZD RP Team
6 maja 2026
10 min
Profesjonalna infrastruktura serwerowa z szafami rack w nowoczesnym centrum danych - system zarządzania dokumentami EZD RP

Prawidłowe przygotowanie środowiska uruchomieniowego dla systemu EZD RP to fundament stabilności, bezpieczeństwa oraz wydajności całej platformy elektronicznego zarządzania dokumentacją. Niniejszy artykuł szczegółowo omawia wymagania sprzętowe, konfigurację serwerów oraz najlepsze praktyki wdrożeniowe dla jednostek samorządu terytorialnego.

1. Wprowadzenie do środowiska uruchomieniowego EZD RP

System EZD RP jest rozbudowaną aplikacją typu enterprise, która w zależności od wielkości jednostki może obsługiwać od kilkudziesięciu do kilku tysięcy równoczesnych użytkowników. Architektura systemu opiera się na modelu trójwarstwowym:

  • Warstwa prezentacji: Interfejs webowy dostępny przez przeglądarkę (HTML5 + JavaScript)
  • Warstwa logiki biznesowej: Serwer aplikacyjny Java (Apache Tomcat / WildFly) przetwarzający żądania użytkowników
  • Warstwa danych: Relacyjna baza danych PostgreSQL lub Oracle przechowująca dokumenty, metadane oraz dzienniki audytowe

Dodatkowo system wymaga integracji z infrastrukturą pomocniczą: serwery backupowe, systemy monitoringu, firewalle aplikacyjne (WAF) oraz opcjonalnie systemy cache'ujące (Redis) czy kolejki komunikatów (RabbitMQ).

2. Wymagania sprzętowe – szczegółowa specyfikacja

Środowisko dla małej jednostki (do 100 użytkowników)

Odpowiednie dla gmin wiejskich, małych gmin miejskich oraz jednostek organizacyjnych (np. szkoły, biblioteki).

  • Procesor: Intel Xeon E-2288G (8 rdzeni / 16 wątków, 3.7 GHz) lub AMD EPYC 7232P (8 rdzeni / 16 wątków, 3.2 GHz)
  • Pamięć RAM: 32 GB DDR4 ECC (2933 MHz), możliwość rozbudowy do 64 GB
  • Dysk systemowy: 2x 480 GB SSD SATA w RAID 1 (dla redundancji systemu operacyjnego)
  • Dysk na dane aplikacji: 2x 960 GB SSD NVMe w RAID 1 (dla bazy danych i plików dokumentów)
  • Karta sieciowa: Dual-port Gigabit Ethernet (1 GbE), z obsługą LACP (Link Aggregation)
  • Zasilanie: Redundantne zasilacze 550W Platinum (dla ciągłości pracy)
  • Forma: Serwer rack 1U lub tower w zależności od dostępnej przestrzeni serwerowni

Środowisko dla średniej jednostki (100-500 użytkowników)

Typowe dla gmin miejskich, powiatów oraz średnich urzędów marszałkowskich.

  • Procesor: Intel Xeon Gold 5320 (26 rdzeni / 52 wątki, 2.2 GHz) lub AMD EPYC 7453 (28 rdzeni / 56 wątków, 2.75 GHz)
  • Pamięć RAM: 128 GB DDR4 ECC (3200 MHz), możliwość rozbudowy do 256 GB
  • Dysk systemowy: 2x 960 GB SSD NVMe w RAID 1
  • Dysk na bazę danych: 4x 3.84 TB SSD NVMe w RAID 10 (dla optymalnej wydajności I/O oraz redundancji)
  • Karta sieciowa: Dual-port 10 Gigabit Ethernet (10 GbE) z możliwością rozbudowy do 25 GbE
  • Kontroler RAID: Sprzętowy kontroler RAID z cache 4 GB oraz bateryjnym backupem (BBU)
  • Zasilanie: Redundantne zasilacze 1100W Platinum
  • Forma: Serwer rack 2U z możliwością montażu w szafie rack 42U

Środowisko dla dużej jednostki (500+ użytkowników)

Dedykowane dla miast na prawach powiatu, urzędów wojewódzkich oraz ministerstw.

  • Architektura: Klaster wysokiej dostępności (HA cluster) z minimum 3 węzłami aplikacyjnymi oraz dedykowanym klastrem bazodanowym
  • Procesor (na węzeł): Intel Xeon Platinum 8380 (40 rdzeni / 80 wątków, 2.3 GHz) lub AMD EPYC 7763 (64 rdzenie / 128 wątków, 2.45 GHz)
  • Pamięć RAM (na węzeł): 512 GB DDR4 ECC (3200 MHz) z możliwością rozbudowy do 2 TB
  • Storage: Dedykowana macierz SAN/NAS z minimum 50 TB pojemności użytkowej, replikacja geograficzna do ośrodka DR (Disaster Recovery)
  • Sieć: 25 GbE lub 40 GbE z redundantnymi switchami core oraz firewallem nowej generacji (NGFW)
  • Load Balancer: Sprzętowy load balancer (F5 BIG-IP, Citrix ADC) z funkcją SSL offloading
  • Backup: Dedykowany serwer backupowy z robotem taśmowym LTO-9 (dla długoterminowej archiwizacji)

3. Specyfikacja sieci i wymagania połączeniowe

EZD RP jako system webowy wymaga stabilnego i wydajnego połączenia sieciowego zarówno dla użytkowników wewnętrznych (LAN), jak i zewnętrznych (WAN/Internet). Minimalne wymagania:

  • Przepustowość łącza internetowego: Min. 100 Mbps symetryczne (upload/download) dla jednostek do 100 użytkowników, 500 Mbps dla większych jednostek, 1 Gbps dla miast i powiatów
  • Jakość połączenia (QoS): Latencja < 50 ms, packet loss < 0.1%, jitter < 10 ms (kluczowe dla integracji z systemami zewnętrznymi)
  • Firewall: Stateful firewall z obsługą deep packet inspection (DPI) oraz IPS/IDS (Intrusion Prevention/Detection System)
  • VPN: Dla pracy zdalnej – IPsec VPN lub SSL VPN z dwuskładnikowym uwierzytelnianiem (2FA)
  • VLAN Segmentation: Separacja ruchu produkcyjnego, administracyjnego i backupowego w dedykowanych VLANach
  • DNS: Redundantne serwery DNS (preferowane własne serwery DNS zamiast publicznych Google/Cloudflare ze względu na bezpieczeństwo)

4. Konfiguracja systemu operacyjnego – krok po kroku

Wybór systemu operacyjnego

System EZD RP oficjalnie wspiera następujące platformy:

  • Ubuntu Server 22.04 LTS: Zalecany dla większości instalacji ze względu na długi cykl wsparcia (do 2027 z możliwością przedłużenia ESM)
  • Red Hat Enterprise Linux (RHEL) 9: Wybór dla środowisk wymagających komercyjnego wsparcia technicznego
  • Windows Server 2022 Standard/Datacenter: Opcja dla jednostek posiadających licencje Microsoft i doświadczonych administratorów Windows

Hardening systemu operacyjnego (Ubuntu Server)

Po instalacji bazowej systemu operacyjnego należy przeprowadzić procedury hardeningu zgodne z CIS Benchmarks:

# Aktualizacja pakietów do najnowszych wersji
sudo apt update && sudo apt upgrade -y

# Instalacja automatycznych aktualizacji bezpieczeństwa
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

# Konfiguracja firewalla UFW
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp   # SSH
sudo ufw allow 80/tcp   # HTTP
sudo ufw allow 443/tcp  # HTTPS
sudo ufw enable

# Wyłączenie niepotrzebnych usług
sudo systemctl disable avahi-daemon
sudo systemctl disable cups
sudo systemctl disable bluetooth

Konfiguracja parametrów jądra Linux

Dla optymalnej wydajności EZD RP należy dostosować parametry jądra. Edytuj plik /etc/sysctl.conf:

# Zwiększenie limitów dla połączeń sieciowych
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 8192

# Optymalizacja pamięci współdzielonej (dla PostgreSQL)
kernel.shmmax = 17179869184
kernel.shmall = 4194304

# Zwiększenie limitów otwartych plików
fs.file-max = 2097152

# Wyłączenie IPv6 jeśli nie jest używane
net.ipv6.conf.all.disable_ipv6 = 1

Zastosuj zmiany: sudo sysctl -p

5. Konfiguracja sieci – najlepsze praktyki

Konfiguracja interfejsów sieciowych (bonding)

Dla zapewnienia wysokiej dostępności zaleca się konfigurację bondingu (agregacji łączy). Przykładowa konfiguracja w Netplan (Ubuntu):

network:
  version: 2
  ethernets:
    eno1:
      dhcp4: no
    eno2:
      dhcp4: no
  bonds:
    bond0:
      interfaces: [eno1, eno2]
      addresses: [192.168.10.100/24]
      gateway4: 192.168.10.1
      nameservers:
        addresses: [8.8.8.8, 8.8.4.4]
      parameters:
        mode: 802.3ad  # LACP
        lacp-rate: fast
        mii-monitor-interval: 100

Zastosuj konfigurację: sudo netplan apply

Konfiguracja DNS i hostów

Edytuj /etc/hosts aby dodać wpisy dla wszystkich serwerów w klastrze:

192.168.10.100  ezdrp-app01.local  ezdrp-app01
192.168.10.101  ezdrp-app02.local  ezdrp-app02
192.168.10.110  ezdrp-db01.local   ezdrp-db01

6. Ustawienia bezpieczeństwa – wzmocnienie ochrony

Konfiguracja SELinux / AppArmor

SELinux (RHEL/CentOS) lub AppArmor (Ubuntu) powinny być włączone w trybie enforcing:

# Sprawdzenie statusu SELinux (RHEL)
getenforce
# Powinno zwrócić: Enforcing

# Sprawdzenie statusu AppArmor (Ubuntu)
sudo aa-status

Konfiguracja fail2ban

Instalacja fail2ban dla ochrony przed atakami brute-force:

sudo apt install fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Skonfiguruj jail dla SSH w pliku /etc/fail2ban/jail.local:

[sshd]
enabled = true
port = 22
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600

7. Typowe błędy i ich rozwiązania

Problem: Niska wydajność I/O dysku

Objawy: Długie czasy odpowiedzi aplikacji, wysokie wartości iowait w top

Diagnoza: Sprawdź wydajność dysków: sudo iostat -x 1

Rozwiązanie: Upewnij się, że używasz dysków SSD NVMe zamiast HDD. Sprawdź scheduler I/O: cat /sys/block/nvme0n1/queue/scheduler. Dla SSD zalecany jest none lub mq-deadline.

Problem: Wyczerpanie pamięci RAM

Objawy: Proces OOM Killer zabija procesy, system używa swap intensywnie

Diagnoza: free -h, vmstat 1

Rozwiązanie: Zwiększ ilość RAM fizycznej lub dostosuj parametry JVM dla aplikacji Java (zmniejsz -Xmx heap size). Skonfiguruj swap jako awaryjny buffer, ale nigdy jako podstawowe rozszerzenie RAM.

8. Optymalizacja wydajności środowiska

Tunning PostgreSQL

Najważniejsze parametry do optymalizacji w postgresql.conf:

# Dla serwera z 128 GB RAM:
shared_buffers = 32GB
effective_cache_size = 96GB
work_mem = 256MB
maintenance_work_mem = 4GB
random_page_cost = 1.1  # Dla SSD

# Autovacuum
autovacuum_max_workers = 4
autovacuum_naptime = 15s

Monitoring i alerting

Wdróż system monitoringu (Prometheus + Grafana) do śledzenia kluczowych metryk:

  • Obciążenie CPU i pamięci
  • I/O dysku (IOPS, latencja)
  • Ruch sieciowy (throughput, packet loss)
  • Dostępność usług (HTTP status codes)
  • Czas odpowiedzi aplikacji (percentyle: p50, p95, p99)
  • Liczba aktywnych sesji użytkowników

9. Wskazówki dla administratorów JST

  • Planuj pojemność z zapasem: Przy projektowaniu infrastruktury zakładaj 30-50% zapasu zarówno dla CPU, RAM jak i storage na przyszły wzrost obciążenia
  • Testuj przed produkcją: Zawsze uruchamiaj najpierw środowisko testowe/staging identyczne z produkcyjnym
  • Dokumentuj wszystko: Prowadź szczegółową dokumentację konfiguracji, zmian oraz procedur awaryjnych
  • Szkolenia dla zespołu: Inwestuj w szkolenia administratorów z zakresu PostgreSQL, Linux hardening oraz Java performance tuning
  • Backupy i DR: Testuj procedury restore co najmniej raz na kwartał. Backup, który nie był testowany, to nie jest backup

10. Podsumowanie i kolejne kroki

Prawidłowe przygotowanie środowiska uruchomieniowego dla EZD RP to proces złożony, lecz kluczowy dla długoterminowego sukcesu cyfryzacji jednostki. Inwestycja w odpowiedni sprzęt, rygorystyczna konfiguracja bezpieczeństwa oraz profesjonalne monitorowanie zwracają się wielokrotnie poprzez wysoką dostępność systemu, zadowolenie użytkowników oraz brak kosztownych przestojów.

Następne kroki dla administratorów JST:

  • Przeprowadzenie audytu obecnej infrastruktury IT
  • Opracowanie szczegółowego projektu technicznego środowiska EZD RP
  • Uzyskanie akceptacji budżetu na zakup sprzętu i licencji
  • Przygotowanie harmonogramu wdrożenia z uwzględnieniem testów i szkoleń
  • Nawiązanie współpracy z certyfikowanym partnerem wdrożeniowym

Pamiętaj: solidne fundamenty infrastrukturalne to gwarancja, że EZD RP będzie służyć Twojej jednostce przez wiele lat, wspierając sprawną i bezpieczną administrację publiczną.

Powiązane artykuły