Un server de 1,5 TB pentru o muncă de 45 GB

Caietul PNI cere, pe ansamblul celor douăsprezece componente, ordinul 1,5 terabyte de memorie RAM cumulată — însumând cerințele pe fiecare nod, multiplicate cu clusterele de înaltă disponibilitate și cu replicile de recuperare după dezastru. O arhitectură echivalentă, dimensionată realist, se încadrează în 25 până la 45 GB RAM pentru toate cele douăsprezece componente la un loc. Raportul e de aproximativ 30 la 1. Întrebarea care se ridică nu e dacă hardware-ul cerut poate face treaba. Întrebarea e inversă: de ce ceri de 30 de ori mai multă putere decât cere sarcina reală, și cine plătește diferența din bani publici.

Volumul real al traficului

PNI trebuie să servească, conform caietului, aproximativ 3.000 de instituții publice românești pe un orizont de 24 de luni după recepție. Traficul real pe care îl generează asta se poate estima simplu: o instituție medie — o primărie de comună, o direcție județeană — interoghează alte instituții de câteva zeci, maximum câteva sute de ori pe zi. În vârf, pentru instituții mari (ANAF, CNAS, MAI), ordinul e de câteva mii pe zi. Agregat pe 3.000 de instituții, estimarea realistă a încărcării medii e între 500.000 și 5 milioane de mesaje pe zi la maturitate. Chiar un scenariu optimist — toate instituțiile active simultan, vârfuri duble față de mediu — se oprește sub 10 milioane de tranzacții pe zi.

Cifra asta nu e abstractă. Platforma pe care am livrat-o în Moldova în 2014 — MConnect, prima platformă națională de interoperabilitate a republicii — rula, la echipa pe care am condus-o, aproximativ un milion de mesaje pe zi pe 8 GB RAM. Configurația era modestă: două noduri WSO2 ESB în cluster, 8 GB alocat per nod, fără optimizări speciale. Răspundea în timp sub secundă pentru operațiile interactive și în câteva secunde pentru cele batch. Nu a căzut. Nu a fost niciodată nevoie să mărim hardware-ul pentru capacitate.

Proiectat pe scara românească: chiar dacă trafficul PNI ar fi de 30 de ori mai mare decât cel al MConnect Moldova — adică 30 de milioane de mesaje pe zi, un scenariu deja generos — încărcarea ar încăpea liniștit pe 8 până la 16 GB RAM per nod într-un cluster de trei noduri. Totalul pe componenta de interoperabilitate: sub 50 GB RAM.

Aici intervine observația fundamentală. O platformă națională de interoperabilitate transportă date, nu le stochează. Datele sunt, prin design, la instituțiile sursă — ANAF păstrează datele fiscale, Casa de Pensii păstrează pensiile, Primăria păstrează registrele ei. Platforma centrală mediază conversația: primește o întrebare, o rutează, returnează răspunsul, scrie un log de audit. Nu calculează matrici științifice. Nu ține cache-uri masive de conținut. Nu rulează simulări. Platforma e o țeavă cu contor.

Pentru o asemenea sarcină, cerința de RAM masiv per nod nu se justifică prin fizica problemei. Memoria e folosită doar pentru buffere de mesaje în tranzit, tabele de rutare și conexiuni deschise. Ordinele de mărime relevante sunt megabytes, nu zeci de gigabytes.

Surse: experiență directă MConnect Moldova 2014-2020 · caietul de sarcini PNI · referința Enterprise Integration Patterns (Hohpe & Woolf, 2003).

Ce cere caietul, în cifre brute

Pentru comparație, iată ce cere caietul PNI pe principalele componente, extras din specificațiile hardware:

• Componenta ESB (interoperabilitate): configurații care implică 128-256 GB RAM per nod, în cluster activ-activ cu replicare geografică — cumulat pe 4-6 noduri între producție și DR.
• Baza de date: configurație Enterprise Edition cu RAC (cluster multi-master), Label Security, Advanced Security — estimat 256-512 GB RAM total pe noduri de bază de date.
• Portal + DMS + BI: WebCenter Portal, WebCenter Content, Oracle Analytics Server — fiecare pe WebLogic, fiecare cu 16-32 GB RAM per nod, în cluster HA — cumulat încă 150-200 GB RAM.
• Identity Management: OIM + OAM + OID, fiecare pe WebLogic separat, cluster HA — 60-100 GB RAM cumulat.
• SIEM + monitorizare + PAM + VPN + DR: împachetate în stack-uri de clasă enterprise, fiecare cu consumul propriu de memorie — încă 100-200 GB cumulat.

Adunate, totalul cerut trece de 1 terabyte RAM și se apropie de 1,5 TB când se includ și replicile DR cerute explicit în caiet.

Comparat cu necesarul real dimensionat pe stack deschis:

• ESB (WSO2 Micro Integrator): 2-4 GB RAM per nod
• Bază de date (PostgreSQL + Patroni HA): 8-16 GB RAM per nod
• Portal (implementare custom, lean): 50-150 MB RAM
• DMS (Alfresco Community): 4-8 GB RAM
• Identity Management (FusionAuth): 512 MB - 1 GB RAM
• Restul componentelor (SIEM, monitorizare, PAM, logging, VPN, DR): încă 10-15 GB cumulat

Total: 25-45 GB RAM pentru toate cele douăsprezece componente la un loc.

Fiecare cerință, luată izolat, ar putea fi justificabilă pentru alt tip de sistem. Un data warehouse analitic care procesează petabytes de date, o platformă tranzacțională bancară cu milioane de tranzacții pe secundă, un motor de calcul științific — toate ar putea avea nevoie legitimă de 256 GB RAM per nod. Un bus de mesaje care rutează între instituții nu. Problema nu e că cifrele individual sunt imposibile. Problema e că sunt calibrate pentru o paradigmă greșită.

De unde vine bugetul

Supradimensionarea nu rămâne pe hârtie. Trece direct în factură, pe trei paliere.

Hardware. Serverele de clasă enterprise cu 256 GB+ RAM, procesoare multi-socket, rețea redundantă, costă între 25.000 și 60.000 de euro per unitate. Pentru un cluster PNI dimensionat conform caietului — cu noduri dedicate pentru fiecare componentă, cu redundanță HA, cu DR geografic — costul hardware brut ajunge la 1,5 până la 2,5 milioane de euro. Dimensionat corect, același cluster s-ar putea construi pe câteva sute de mii de euro în hardware standard.

Licențe software per-core. Aici e capcana ascunsă, mult mai scumpă decât hardware-ul. Multe produse proprietare — incluzând suita de baze de date cerută în caiet, middleware-ul pe care rulează componentele Portal/DMS/Analytics, serverele de aplicație dedicate — sunt licențiate pe număr de procesoare sau core-uri. Un server cu 256 GB RAM are, tipic, 4-8 procesoare, adică 32-64 core-uri. Produsul proprietar care rulează pe el e licențiat pe fiecare core activ. Hardware supradimensionat înseamnă automat licențe pe mai multe core-uri — costul crește exponențial, nu liniar.

Cifrele cumulate pe cinci ani, comparând un stack proprietar supradimensionat cu un stack deschis dimensionat corect:

• Licențe stack proprietar (5 ani): 7,3 - 11,8 milioane EUR (baza de date Enterprise + RAC + Label Security + module SOA + IdM + portal + analytics + monitorizare + SIEM + PAM comercial).
• Licențe stack deschis dimensionat realist (5 ani): 0,6 - 1,6 milioane EUR (suport comercial pe componente open source, unde există — WSO2 MI, FusionAuth, EDB/Percona, Teleport, Veeam, Pritunl).

Raportul e de șapte până la zece ori mai mic pe licențe, la aceeași funcționalitate utilă.

Operare. Un stack supradimensionat consumă proporțional mai multă electricitate, ocupă mai mult spațiu în data center, produce mai multă căldură de evacuat, și cere mai mult personal pentru mentenanță — un stack proprietar cu 12-18 componente complexe operat corect are nevoie de 5-6 specialiști certificați pe tehnologia respectivă; un stack deschis lean se operează cu 2-3 oameni. Diferența pe cinci ani: câteva sute de mii până la un milion de euro în plus pentru stack-ul greu.

Surse: analiza comparativă internă · Regulamentul (UE) 2021/1060 · prețuri publice de piață (enterprise hardware + licențe per-core 2025-2026).

Legătura cu vendor lock-in

Supradimensionarea nu e un accident contabil. Se hrănește reciproc cu cerințele vendor-specific analizate în Episodul 02.

Cerințele hardware masive sunt calibrate pentru tehnologia unui singur producător. Baza de date proprietară cerută în caiet cere singură, în configurația de bază, resurse considerabile — mai ales cu toate modulele opționale pe care caietul le cere explicit: componenta de securitate pe etichete, motorul de workflow de tip BPEL, directorul de identități, componenta pentru portal, componenta pentru analytics. Fiecare modul suplimentar adaugă la memoria ocupată și la numărul de procesoare pe care trebuie să le licențiezi.

Un caiet care cere, în același document, BPEL (disponibil nativ doar la un anumit furnizor) și baza de date proprietară (a aceluiași furnizor) și 256 GB RAM per nod (necesari ca să ruleze stack-ul acestui furnizor cu toate modulele cerute) nu e o listă de trei cerințe independente. E aceeași alegere exprimată în trei moduri diferite. Fiecare cerință o întărește pe celelalte două.

Reciproca e tot adevărată. Dacă caietul s-ar scrie neutru — cerând EIP în loc de BPEL, LDAP v3 în loc de numele unui director specific, PostgreSQL cu Row Level Security în loc de Label Security, SQL:2011 temporal tables în loc de Flashback — cerințele de RAM ar cădea natural la 8-16 GB per nod. Nu pentru că cineva ar fi plafonat artificial performanța, ci pentru că stack-ul deschis e mai eficient la aceeași sarcină. Între specificația juridică și specificația hardware există o relație cauzală pe care un cititor neexperimentat o pierde la o primă lectură.

Ce pățește cineva care a făcut dimensionare corectă

Scenariul concret. Un ofertant propune o arhitectură open source dimensionată realist: 45 GB RAM total pentru toate cele douăsprezece componente, cost licențe pe cinci ani aproximativ 1 milion EUR, hardware standard de 300.000-500.000 EUR. Funcțional, acoperă toate cerințele din caiet exprimate ca funcționalitate. Tehnic, a dovedit în alte implementări naționale (MConnect Moldova, Trembita Ucraina, X-Road Estonia) că stack-ul ține.

Ce se întâmplă la evaluare: ofertantul e descalificat tehnic pentru că nu atinge specificațiile hardware literale ale caietului. Nu pentru că soluția lui nu funcționează. Pentru că specificațiile cer hardware pe care soluția lui nu îl folosește. Singura lui opțiune e să umfle artificial configurația — să cumpere servere cu 256 GB RAM pe care rulează un stack care folosește 4 GB — crescând prețul ofertei cu milioane de euro doar ca să atingă conformitatea formală.

Efectul: ofertantul corect tehnic nu poate câștiga fără să cheltuie inutil bani publici. Ofertantul supradimensionat pe stack proprietar câștigă automat, pentru că e singurul a cărui soluție are nevoie reală de hardware-ul cerut. Caietul nu a eliminat concurența prin interdicție directă. A eliminat-o prin geometria propriilor cerințe.

Puntea spre episodul următor

O supradimensionare cu factor 10 până la 30, pe o platformă finanțată din fonduri europene, nu e o opțiune neutră de politică internă. E fix tipul de neregularitate pe care Comisia Europeană o poate sancționa prin mecanismul de corecție financiară — reducerea sau anularea plăților UE către România când se demonstrează că achiziția nu a respectat principiul proporționalității între cerințe și scop. Nu e amenințare teoretică. Proporționalitatea e un principiu european explicit, scris în Regulamentul (UE) 2021/1060, aplicat sistematic în auditurile de țară. Episodul 04 arată cum a fost folosit în alte state, cu ce sume, și ce ar însemna aplicarea lui pe PNI.