Soluție de stocare a datelor de tip enterprise

Caietul de Sarcini a fost elaborat conform necesităților funcționale și operaționale actuale ale platformei MCloud, cu o rezervă tehnologică pentru asigurarea relevanței soluției pe parcursul mai multor ani de exploatare. Cerințele sunt formulate în termeni de performanță și funcționalitate, fără referire la mărci comerciale, și pot fi satisfăcute de mai multe platforme tehnologice independente. Afirmația privind excluderea altor platforme nu este susținută de argumente concrete — solicitantul nu a identificat cerințe specifice pe care o anumită soluție nu le-ar putea îndeplini. Cu toate acestea, I.P. STISC a analizat observațiile recepționate și a operat ajustări în versiunea actualizată a Caietului de Sarcini, relaxând o serie de cerințe la limita necesităților stricte actuale, în scopul extinderii participării și stimulării concurenței tehnologice. Versiunea actualizată este publicată în cadrul procedurii.

Tipul de echipament este disponibil în portofoliul tuturor producătorilor majori de sisteme de stocare enterprise. Prin urmare, cerințele nu restricționează concurența și este conformă cu prevederile art. 37 din Legea nr. 131/2015 privind achizițiile publice

Cerința a fost dimensionată în raport cu politicile de protecție a datelor aplicabile serviciilor găzduite, care combină puncte de restaurare frecvente pe termen scurt — cu rol de protecție anti-ransomware (C3.13) și de asigurare a unui RPO redus — cu retenție extinsă pe termen mediu.

Tipul de echipament este disponibil în portofoliul tuturor producătorilor majori de sisteme de stocare enterprise. Prin urmare, cerințele nu restricționează concurența și este conformă cu prevederile art. 37 din Legea nr. 131/2015 privind achizițiile publice

Tipul de echipament este disponibil în portofoliul tuturor producătorilor majori de sisteme de stocare enterprise. Prin urmare, cerințele nu restricționează concurența și este conformă cu prevederile art. 37 din Legea nr. 131/2015 privind achizițiile publice

Tipul de echipament este disponibil în portofoliul tuturor producătorilor majori de sisteme de stocare enterprise. Prin urmare, cerințele nu restricționează concurența și este conformă cu prevederile art. 37 din Legea nr. 131/2015 privind achizițiile publice

Tipul de echipament este disponibil în portofoliul tuturor producătorilor majori de sisteme de stocare enterprise. Prin urmare, cerințele nu restricționează concurența și este conformă cu prevederile art. 37 din Legea nr. 131/2015 privind achizițiile publice

Tipul de echipament este disponibil în portofoliul tuturor producătorilor majori de sisteme de stocare enterprise. Prin urmare, cerințele nu restricționează concurența și este conformă cu prevederile art. 37 din Legea nr. 131/2015 privind achizițiile publice

Cerințele referitoare la funcționalitățile NFS se mențin ca obligatorii.

Intenția cerinței C2.7 este de a asigura control manual asupra proceselor necesar în situații operaționale critice.

Cerința privind tehnologia TLC este menținută. Cerințele au fost stabilite în raport cu profilul de utilizare al sistemului, care implică un volum ridicat de scriere susținută la nivelul mediilor fizice de stocare — replicare sincronă și asincronă (C2.6–C2.8), configurație metro activ-activ cu RPO=0 (C2.9), până la 1000 de snapshot-uri per volum (C2.34), precum și deduplicare și compresie inline (C3.8–C3.9). Tehnologia TLC asigură o anduranță la scriere — exprimată prin indicatorii standard DWPD (Drive Writes Per Day) și TBW (Terabytes Written), declarați de producători în specificațiile oficiale ale discurilor — semnificativ superioară tehnologiei QLC. Acest aspect este esențial în condițiile în care garanția și suportul tehnic sunt solicitate pentru o perioadă de minimum 5 ani (C1.6–C1.8), iar discurile defecte nu se returnează producătorului (C1.11). Totodată, cerința nu indică un producător sau un produs anume: discuri NVMe TLC enterprise sunt disponibile în portofoliul tuturor producătorilor majori de sisteme de stocare enterprise.

în conformitate cu cerința C2.2 privind caracterul extensibil și scalabil al sistemului, arhitectura soluției ofertate trebuie să suporte conectarea a unităților de expansiune la extinderile ulterioare. Îndeplinirea acestei condiții se va demonstra prin documentația tehnică oficială a producătorului, depusă odată cu oferta

1. Cu privire la pretinsul caracter restrictiv al cerinței C1.10 Cerința C1.10 nu constituie o restricție tehnică, ci o cerință obligatorie de compatibilitate și integrare, necesară asigurării continuității serviciilor și securității infrastructurii cloud guvernamentale. Soluția ofertată trebuie să susțină integrarea cu soluția de backup Nakivo sau echivalent. Formularea „sau echivalent"" exclude prin ea însăși orientarea către un producător determinat. Cerințele tehnice aplicabile soluțiilor alternative vor fi comunicate oricărui ofertant care le solicită, în funcție de politica de licențiere a soluției alternative propuse, pe baza unei cereri care să indice clar parametrii necesari pentru licențiere. 2. Cu privire la afirmația privind limitarea concurenței Cerința nu limitează concurența, ci reflectă configurația reală, existentă, a infrastructurii cloud guvernamentale. Este o cerință strict tehnică, al cărei unic obiectiv este asigurarea compatibilității cu mecanismul de backup aflat în exploatare. Menținerea acesteia este necesară și obligatorie pentru respectarea politicilor instituționale de Business Continuity și Disaster Recovery, aplicabile serviciilor critice ale statului. Orice soluție care realizează integrarea prin mecanisme tehnice diferite, dar cu+D11 rezultat funcțional echivalent și demonstrabil, este admisibilă. 3. Cu privire la pretinsul refuz de a furniza informații Autoritatea contractantă nu refuză furnizarea informațiilor necesare. Obiectul prezentei achiziții îl constituie soluția de stocare, nu soluția de backup; în consecință, cerințele tehnice specifice soluției de backup nu au făcut obiectul publicării în documentația de atribuire. STISC este disponibilă să furnizeze informațiile solicitate ca răspuns la cereri concrete, formulate punctual, privind parametrii prevăzuți de politica de licențiere a soluției alternative de backup pe care ofertantul intenționează să o propună. 4. Cu privire la modelul de licențiere și la parametrii de dimensionare solicitați Soluția de backup nu face obiectul achiziției. Din considerente de securitate a infrastructurii critice, autoritatea contractantă nu a descris în documentație ansamblul soluției de backup aflate în exploatare. Aceasta nu împiedică însă elaborarea ofertei: la solicitare punctuală, STISC va comunica parametrii concreți și serviciile necesare pentru licențierea și acceptanța unei noi soluții de backup, în măsura în care aceștia sunt relevanți pentru soluția alternativă propusă de ofertant. 5. Cu privire la afirmațiile privind favorizarea anumitor combinații vendor–vendor Aceste afirmații reprezintă insinuări nefondate și nu sunt susținute de niciun element al documentației. Obiectivul autorității contractante este achiziționarea unui echipament performant, la cel mai avantajos preț, fără investiții financiare și operaționale suplimentare și fără modificări de arhitectură, în scopul menținerii continuității și securității serviciilor critice ale statului. Această abordare este pe deplin conformă principiului utilizării eficiente a fondurilor publice, întrucât evită costuri conexe pe care le-ar genera reconfigurarea infrastructurii existente. 6. Concluzie STISC reiterează disponibilitatea de a comunica parametrii minimi necesari, de îndată ce va fi formulată o solicitare punctuală de furnizare a acestora, conform politicii de licențiere a soluției alternative avute în vedere de ofertant. Din motive de securitate a infrastructurii critice, autoritatea contractantă nu are dreptul de a descrie în totalitate infrastructura curentă, aceasta constituind informație confidențială de uz intern.

I.P. STISC a examinat observațiile formulate și comunică următoarele: Cerința a fost stabilită în temeiul Legii nr. 131/2015, coroborate cu Anexa nr. 12 din Documentația standard, ca instrument de verificare a capacității tehnice și profesionale a operatorilor economici. Obiectul contractului — soluție de stocare enterprise destinată infrastructurii guvernamentale MCloud, cu termen de livrare de maximum 120 de zile — justifică verificarea experienței în livrări de anvergură comparabilă. Afirmația că experiența ar fi evaluată exclusiv prin valoare financiară nu corespunde documentației: competențele tehnice sunt verificate distinct prin cerințele nr. 12, 13, 16, 4 și 17. Cu toate acestea, ținând cont de creșterea semnificativă a prețurilor pentru soluțiile de stocare enterprise în ultimul an, care a condus la majorarea valorilor contractuale fără o corelație directă cu complexitatea livrărilor, I.P. STISC a decis reducerea pragului în scopul proporționalității: Cerința nr. 8 — pragul se reduce la 13.750.000,00 MDL fără TVA (50% din valoarea estimată). Pragul poate fi atins prin cumulul mai multor contracte executate în perioada de referință. Modificarea va fi operată prin publicarea versiunii actualizate în SIA RSAP MTender. Solicitarea de eliminare integrală nu poate fi reținută — renunțarea la experiența similară ar priva I.P. STISC de un instrument esențial de verificare într-o procedură vizând infrastructură critică de stat, contrar obligației de gestionare prudentă a fondurilor publice. Referitor la solicitarea de a comunica numărul operatorilor economici identificați — I.P. STISC nu are obligația legală de a efectua sau comunica o asemenea analiză, iar o astfel de practică ar contraveni principiului tratamentului egal și caracterului deschis al procedurii.

**Răspuns la solicitarea de clarificare privind cerința nr. 15 – Capacitatea economică și financiară** I.P. STISC a examinat observațiile formulate și comunică următoarele: Cifra de afaceri anuală minimă solicitată — 27.500.000,00 MDL — este egală cu valoarea estimată a contractului (multiplu de 1x), situându-se sub nivelul maxim admis de reglementările și practica în domeniul achizițiilor publice, care permit praguri de până la dublul valorii estimate. Un prag aflat sub limita superioară recunoscută nu poate fi calificat drept disproporționat. Cerința este justificată de condițiile concrete de executare a contractului: livrarea se realizează în maximum 120 de zile, iar plata intervine ulterior recepției. Operatorul economic trebuie să achiziționeze, transporte, vămuiască și livreze echipamente în valoare de 27,5 milioane MDL din resurse proprii sau atrase, înainte de a încasa orice sumă. La aceasta se adaugă garanția pentru ofertă (2%), garanția de bună execuție (5%) și asigurarea garanției bunurilor pentru minimum 5 ani. Un operator a cărui cifră de afaceri anuală este inferioară acestei valori nu poate demonstra că a gestionat un rulaj de asemenea ordin într-un an întreg de activitate, cu atât mai puțin într-un interval de 120 de zile și fără flux de încasări aferent. Obiectul contractului deservește infrastructura cloud guvernamentală MCloud, care găzduiește sisteme informaționale de stat și servicii critice. Eșecul financiar al furnizorului pe parcursul executării nu produce doar un prejudiciu patrimonial recuperabil parțial prin garanția de 5%, ci un impact operațional direct asupra continuității serviciilor critice ale statului. Verificarea prealabilă a solidității financiare este singurul instrument prin care acest risc poate fi prevenit, nu doar compensat. Observația că cerința nr. 15 „nu demonstrează capacitatea tehnică"" este exactă, dar irelevantă: capacitatea economico-financiară și capacitatea tehnico-profesională sunt criterii de calificare distincte, cu funcții diferite. Componenta tehnică este verificată separat prin cerințele nr. 4, 12, 13, 16 și 17 din anunțul de participare. Referitor la solicitarea de a comunica numărul operatorilor economici identificați și de a demonstra evaluarea impactului asupra concurenței — I.P. STISC nu are obligația legală de a identifica anterior lansării procedurii operatorii care ar îndeplini criteriile, iar o astfel de practică ar contraveni caracterului deschis al procedurii și principiului tratamentului egal. Criteriile au fost stabilite prin raportare la obiectul, valoarea, complexitatea și riscurile contractului, în limitele cadrului legal aplicabil. Cerința nr. 15 se menține în forma publicată.

I.P. STISC răspunde la toate întrebările de clarificare, fără excepție, pe măsura disponibilității specialiștilor în domeniu.

Cerința C3.3 este justificată de arhitectura platformei MCloud, care deservește multiple instituții publice și impune izolarea administrativă a resurselor de stocare per entitate. Pragul minim de 100 de entități reflectă necesitățile operaționale actuale ale infrastructurii și nu poate fi redus fără a compromite capacitatea de administrare izolată. Cerința se menține în forma publicată. I.P. STISC precizează că formulări de tipul „un număr suficient pentru exploatarea infrastructurii"" nu pot fi reținute în specificațiile tehnice, întrucât nu constituie un criteriu obiectiv, măsurabil și verificabil la evaluarea ofertelor. Totodată, versiunea actualizată a Caietului de Sarcini prevede evaluarea ca avantaj a capacității maxime de entități izolate suportate de sistemul propus.

Nu pot fi acceptate module criptografice sau discuri SED aflate în procesul de validare. Cerința C3.14 impune explicit certificare FIPS 140-3 validată în cadrul programului NIST CMVP, confirmată prin numărul certificatului CMVP corespunzător. Platforma MCloud constituie infrastructură guvernamentală critică, iar protecția criptografică a datelor statului nu poate fi condiționată de finalizarea ulterioară a unui proces de certificare al cărui rezultat și termen nu sunt garantate. Acceptarea unor soluții „în curs de validare"" ar transforma o cerință de securitate obiectivă și verificabilă într-o declarație de intenție, imposibil de evaluat la momentul depunerii ofertelor. Cerința C3.14 se menține în forma publicată. Ofertantul va indica în ofertă numărul certificatului CMVP activ la data limită de depunere a ofertelor.

Cerința C3.4 vizează capacitatea nativă a sistemului de stocare de a realiza copii instantanee consistente la nivel de aplicație, prin integrare cu aplicații de tip MS SQL Server, Oracle sau echivalent. Cerința se referă la funcționalitatea suportată de platformă, nu la dimensionarea unei soluții separate de Copy Data Management. Informațiile solicitate privind numărul de instanțe, volumul de date și scenariile de utilizare constituie date operaționale interne ale infrastructurii MCloud, a căror comunicare nu este necesară pentru formularea ofertei și nu face obiectul clarificărilor în cadrul procedurii de achiziție. Ofertantul trebuie să demonstreze că sistemul de stocare propus suportă nativ funcționalitatea descrisă în C3.4, iar conform cerinței C3.10, toate funcționalitățile — inclusiv snapshot-urile aplicative — trebuie licențiate și acoperite cu suport pentru întreaga capacitate suportată de sistem în configurație maximă. Aceasta constituie baza unitară și suficientă pentru dimensionarea și comparabilitatea ofertelor.

I.P. STISC ia notă de faptul că implementarea internă a mecanismelor de deduplicare diferă de la o platformă la alta. Cerința C3.8 vizează rezultatul funcțional, nu o anumită arhitectură internă de implementare. În acest sens, se precizează că vor fi acceptate soluții care asigură deduplicare inline pentru volume accesibile la nivel de bloc (LUN-uri iSCSI/FC) și la nivel de fișier (NFS), aplicate la nivelul cel mai larg suportat de arhitectura sistemului propus. Ofertantul va descrie în ofertă domeniul de aplicare al deduplicării (per volum, per grup de volume, per sistem) și va demonstra eficiența mecanismului propus. Celelalte sub-cerințe rămân aplicabile: conform C3.10, funcționalitatea trebuie licențiată pentru întreaga capacitate suportată în configurație maximă, iar conform C3.11, deduplicarea nu va impune restricții pentru utilizarea simultană a altor funcționalități (replicare, thin provisioning, clonare).

Cerința C1.10 prevede explicit posibilitatea utilizării unei soluții de backup enterprise echivalente, formularea „Nakivo sau echivalent"" asigurând deschiderea concurențială. Condiția de validare bilaterală — confirmarea oficială a suportului de către ambii producători (stocare și backup) — se menține, fiind esențială pentru garantarea funcționării corecte a mecanismelor de snapshot-based backup în mediul de producție al platformei MCloud. Validarea unilaterală, doar din partea producătorului sistemului de stocare, nu oferă garanția că soluția de backup va exploata corect și complet mecanismele native de snapshot ale sistemului propus. Într-o infrastructură guvernamentală critică, compatibilitatea declarată fără confirmare reciprocă generează un risc operațional pe care I.P. STISC nu îl poate accepta.

Identificarea soluțiilor conforme cu cerințele din Caietul de Sarcini revine ofertanților.

Identificarea soluțiilor conforme cu cerințele din Caietul de Sarcini revine ofertanților.

Afirmația este generală și nu identifică cerințe tehnice concrete care ar favoriza un anumit producător. I.P. STISC confirmă că cerințele din Caietul de Sarcini sunt formulate în termeni de performanță și funcționalitate, fără referire la mărci comerciale, și pot fi satisfăcute de mai multe platforme tehnologice independente, cu arhitecturi și sisteme de operare distincte.

Cerințele se mențin conform versiunii actualizate a Caietului de Sarcini. I.P. STISC a analizat observațiile recepționate și a operat ajustări, relaxând o serie de cerințe la limita necesităților stricte actuale, în scopul extinderii participării și stimulării concurenței tehnologice. Versiunea actualizată este publicată în cadrul procedurii.

Afirmația nu este susținută de argumente concrete și nu identifică cerințe tehnice specifice care ar favoriza un anumit producător sau operator economic. Specificațiile tehnice sunt formulate în termeni de performanță și funcționalitate, fără referire la mărci comerciale, și pot fi îndeplinite de mai multe platforme tehnologice independente. Cerințele se mențin conform Caietului de Sarcini, cu excepția ajustărilor operate prin răspunsurile la solicitările de clarificare.

Răspunsul I.P. STISC rămâne cel comunicat: afirmația nu este susținută de argumente concrete, cerințele sunt funcționale și pot fi îndeplinite de mai multe platforme independente.

Observațiile reiterate au fost examinate și clarificate prin răspunsurile publicate în cadrul procedurii în perioada 2–8 iulie 2026, privind C1.10, C3.3, C3.8, C2.31 și contestațiile generale de favorizare. Solicitantul nu a prezentat argumente noi față de cele deja examinate. I.P. STISC a operat ajustări semnificative în versiunea actualizată a Caietului de Sarcini, relaxând cerințele la limita necesităților stricte actuale, în scopul extinderii participării. Cerințele se mențin conform versiunii actualizate publicate.

1. Cu privire la C3.3 (100 domenii multi-tenant) Cerința a fost clarificată anterior (răspunsul din 8 iul 2026, 10:08). Arhitectura platformei MCloud deservește multiple instituții publice, iar pragul de 100 reflectă necesitățile operaționale actuale și de perspectivă. Informațiile privind numărul curent și prognozat de tenants constituie date operaționale interne ale infrastructurii guvernamentale, a căror comunicare nu face obiectul clarificărilor în cadrul procedurii de achiziție. 2. Cu privire la C2.31 (1000 snapshot-uri per volum) Cerința a fost clarificată anterior (răspunsul din 7 iul 2026, 14:40). Dimensionarea a fost stabilită în raport cu politicile de protecție a datelor aplicabile serviciilor găzduite, care combină puncte de restaurare frecvente pe termen scurt — inclusiv în contextul protecției anti-ransomware (C3.13) — cu retenție extinsă pe termen mediu. Politicile interne de backup și retenție, inclusiv calculele aferente, constituie documente operaționale interne ale I.P. STISC și nu fac obiectul comunicării în cadrul procedurii. Ambele cerințe se mențin în forma publicată.

1. Cu privire la C2.20 (performanță 250.000 IOPS) Metodologia de verificare este definită în cerința însăși: rata de citire/scriere 70/30%, dimensiunea blocului 4K, I/O aleatoriu, deduplicare/compresie activate. Acești parametri constituie un profil de workload standard în industria de stocare enterprise și sunt utilizați de toți producătorii majori în documentația oficială de performanță. Raportul de performanță validat și semnat electronic de producător este solicitat tocmai pentru a asigura un criteriu obiectiv și verificabil de evaluare, bazat pe date confirmate de producătorul soluției, nu pe estimări proprii ale ofertantului. Producătorii majori de sisteme de stocare enterprise furnizează în mod curent astfel de documente (performance datasheets, validated sizing reports) clienților și partenerilor. 2. Cu privire la C3.5 (impactul snapshot-urilor asupra performanței) Cerința C3.5 stabilește un prag funcțional pe care arhitectura sistemului propus trebuie să îl asigure. Verificarea conformității se realizează prin documentația tehnică oficială a producătorului, care descrie mecanismul de implementare a snapshot-urilor (redirect-on-write, copy-on-write etc.) și impactul asociat, nu prin testare on-site în cadrul procedurii de evaluare. Ofertantul va demonstra în ofertă, pe baza documentației producătorului, că mecanismul de snapshot implementat este de tip performance-efficient și se încadrează în pragul solicitat. Ambele cerințe se mențin în forma publicată.

1. Cu privire la C1.10 (integrarea backup prin storage snapshots) Cerința a fost clarificată anterior (răspunsurile din 8 iul 2026, 09:04 și 10:55). Backup-ul bazat pe snapshot-uri la nivel de storage asigură reducerea impactului asupra mediului de producție, timpi de backup și restaurare substanțial mai reduși și RPO mai granular — necesități operaționale obligatorii pentru o platformă care găzduiește servicii critice ale statului. Formularea „Nakivo sau echivalent"" permite utilizarea oricărei soluții de backup enterprise alternative, conform notei de la C1.10. Cerința nu exclude sisteme de stocare care nu se integrează direct cu Nakivo. 2. Cu privire la C2.33 (volum NFS de minimum 120TB) Cerințele NFS au fost clarificate anterior (răspunsul din 7 iul 2026, 17:13) și se mențin ca obligatorii. Pragul a fost deja redus de la 200TB la 120TB în versiunea actualizată a Caietului de Sarcini. Capacitatea minimă reflectă necesitatea gestionării anumitor seturi de date într-un spațiu de nume unificat, fără fragmentare administrativă. Informațiile privind natura specifică a datelor constituie date operaționale interne ale infrastructurii MCloud și nu fac obiectul comunicării în cadrul procedurii. Ambele cerințe se mențin în forma publicată.

Cerința C2.8 solicită ca sistemul să suporte funcționalitatea de tip metro high-availability. Obiectul prezentei achiziții, conform C2.3, este un sistem compus din cel puțin 1 nod cu 2 controlere în regim HA. Implementarea efectivă a configurației metro între două site-uri nu face parte din scopul prezentei livrări. Ofertantul trebuie să demonstreze, prin documentația tehnică oficială a producătorului, că platforma propusă suportă funcționalitatea metro HA conform parametrilor din C2.8 (active-active sau active-standby sincron, RPO=0, failover automat, distanță minim 100 km). Toate licențele necesare activării acestei funcționalități trebuie incluse în ofertă, conform C1.5 și C1.7. Observațiile privind suficiența bugetului nu fac obiectul clarificărilor tehnice.

1. Cu privire la C3.8 (deduplicare) Cerința a fost clarificată anterior (răspunsul din 8 iul 2026, 10:52): vor fi acceptate soluții care asigură deduplicare inline pentru volume accesibile la nivel de bloc și la nivel de fișier, aplicate la nivelul cel mai larg suportat de arhitectura sistemului propus. Ofertantul va descrie în ofertă domeniul de aplicare al deduplicării și va demonstra eficiența mecanismului propus. Răspunsul rămâne cel comunicat. 2. Cu privire la C3.10 (licențiere pentru capacitatea maximă) Cerința este justificată de principiul protecției investiției publice și al previzibilității costurilor pe termen lung. Sistemul de stocare este extensibil și scalabil (C2.2), iar pe parcursul celor minimum 5 ani de garanție și suport (C1.6–C1.8), capacitatea poate fi extinsă prin adăugarea de discuri și unități de expansiune. Licențierea funcționalităților doar pentru capacitatea livrată inițial ar genera costuri suplimentare neprevăzute la fiecare extindere, ceea ce contravine tocmai principiului utilizării eficiente a fondurilor publice invocat de solicitant. Licențierea pentru capacitatea maximă suportată asigură un cost total predictibil și elimină dependența de politicile comerciale ulterioare ale producătorului. Ambele cerințe se mențin în forma publicată.