Wymagania sprzętowe EZD RP: serwer i konfiguracja sieci

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: 2× 480 GB SSD SATA w RAID 1
Dysk na dane aplikacji: 2× 960 GB SSD NVMe w RAID 1
Karta sieciowa: Dual-port Gigabit Ethernet (1 GbE), z obsługą LACP
Zasilanie: Redundantne zasilacze 550W Platinum
Forma: Serwer rack 1U lub tower

Ś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: 2× 960 GB SSD NVMe w RAID 1
Dysk na bazę danych: 4× 3.84 TB SSD NVMe w RAID 10
Karta sieciowa: Dual-port 10 GbE z możliwością rozbudowy do 25 GbE
Kontroler RAID: Sprzętowy z cache 4 GB oraz bateryjnym backupem (BBU)
Zasilanie: Redundantne zasilacze 1100W Platinum
Forma: Serwer rack 2U

Ś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
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)
Storage: Dedykowana macierz SAN/NAS z minimum 50 TB pojemności użytkowej, replikacja geograficzna do ośrodka DR
Sieć: 25 GbE lub 40 GbE z redundantnymi switchami core oraz firewallem NGFW
Load Balancer: Sprzętowy (F5 BIG-IP, Citrix ADC) z funkcją SSL offloading
Backup: Dedykowany serwer backupowy z robotem taśmowym LTO-9

3. Specyfikacja sieci i wymagania połączeniowe

Przepustowość łącza: Min. 100 Mbps symetryczne dla jednostek do 100 użytkowników, 500 Mbps dla większych, 1 Gbps dla miast i powiatów
Jakość połączenia (QoS): Latencja < 50 ms, packet loss < 0.1%, jitter < 10 ms
Firewall: Stateful firewall z obsługą deep packet inspection (DPI) oraz IPS/IDS
VPN: Dla pracy zdalnej – IPsec VPN lub SSL VPN z 2FA
VLAN Segmentation: Separacja ruchu produkcyjnego, administracyjnego i backupowego
DNS: Redundantne serwery DNS (preferowane własne zamiast publicznych)

4. Konfiguracja systemu operacyjnego

EZD RP oficjalnie wspiera:

Ubuntu Server 22.04 LTS: Zalecany dla większości instalacji (długi cykl wsparcia do 2027 z możliwością przedłużenia ESM)
Red Hat Enterprise Linux (RHEL) 9: Dla środowisk z komercyjnym wsparciem technicznym
Windows Server 2022 Standard/Datacenter: Dla jednostek z licencjami Microsoft

Hardening systemu operacyjnego (Ubuntu)

Po instalacji bazowej należy przeprowadzić hardening zgodny z CIS Benchmarks:

sudo apt update && sudo apt upgrade -y
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

# UFW Firewall
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

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

Konfiguracja parametrów jądra Linux

Edytuj /etc/sysctl.conf:

net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 8192
kernel.shmmax = 17179869184
kernel.shmall = 4194304
fs.file-max = 2097152
net.ipv6.conf.all.disable_ipv6 = 1

Zastosuj: sudo sysctl -p

5. Konfiguracja sieci – najlepsze praktyki

Bonding interfejsów (LACP) — 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-rate: fast
        mii-monitor-interval: 100

Zastosuj: sudo netplan apply

Konfiguracja DNS i hostów

Edytuj /etc/hosts:

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

SELinux / AppArmor

Powinny być włączone w trybie enforcing:

getenforce       # RHEL
sudo aa-status   # Ubuntu

fail2ban — ochrona przed brute-force

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

Konfiguracja jail dla SSH w /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

Niska wydajność I/O dysku

Objawy: Długie czasy odpowiedzi aplikacji, wysokie wartości iowait w top. Diagnoza: sudo iostat -x 1. Rozwiązanie: SSD NVMe zamiast HDD, scheduler I/O none lub mq-deadline dla SSD.

Wyczerpanie pamięci RAM

Objawy: OOM Killer zabija procesy, intensywne użycie swap. Diagnoza: free -h, vmstat 1. Rozwiązanie: Zwiększ RAM lub dostosuj parametry JVM (-Xmx).

8. Optymalizacja wydajności środowiska

Tunning PostgreSQL dla 128 GB RAM

shared_buffers = 32GB
effective_cache_size = 96GB
work_mem = 256MB
maintenance_work_mem = 4GB
random_page_cost = 1.1
autovacuum_max_workers = 4
autovacuum_naptime = 15s

Monitoring i alerting

Wdróż Prometheus + Grafana do śledzenia:

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 (p50, p95, p99)
Liczba aktywnych sesji użytkowników

9. Wskazówki dla administratorów JST

Planuj pojemność z zapasem: 30-50% rezerwy CPU/RAM/storage na przyszły wzrost
Testuj przed produkcją: Środowisko staging identyczne z produkcyjnym
Dokumentuj wszystko: Szczegółowa dokumentacja konfiguracji i procedur awaryjnych
Szkolenia dla zespołu: PostgreSQL, Linux hardening, Java performance tuning
Backupy i DR: Testuj restore co najmniej raz na kwartał

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.

Następne kroki dla administratorów JST:

Audyt obecnej infrastruktury IT
Projekt techniczny środowiska EZD RP
Akceptacja budżetu na sprzęt i licencje
Harmonogram wdrożenia z testami i szkoleniami
Współpraca z certyfikowanym partnerem wdrożeniowym

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