Servere și sisteme de stocare (perioada 2024-2026)

19 dec 2025, 10:48

Metode acceptate pentru constituirea garantiilor solicitate

Avand in vedere prevederile pct. 18 si pct. 19 din Anuntul de participare, referitoare la constituirea: – garantiei pentru oferta in cuantum de 2% din valoarea ofertei fara TVA; – garantiei de buna executie a contractului in cuantum de 5% din valoarea contractului cu TVA, care prevad constituirea acestora prin garantie bancara sau prin transfer la contul autoritatii contractante, va rugam sa confirmati ca, pentru constituirea garantiilor mentionate, autoritatea contractanta accepta si utilizarea unei polite de asigurare de garantie, emisa de o societate de asigurari autorizata, ca instrument de garantare echivalent din punct de vedere juridic si financiar cu garantia bancara, cu respectarea cerintelor privind irevocabilitatea, neconditionarea si plata la prima cerere. Mentionam ca utilizarea politelor de asigurare de garantie este recunoscuta de cadrul normativ national privind activitatea de asigurare, precum si de practica achizitiilor publice la nivel international, inclusiv in contextul procedurilor aflate sub incidenta Acordului privind achizitiile guvernamentale (GPA) al Organizatiei Mondiale a Comertului, la care Republica Moldova este parte. Totodata, apreciem ca includerea expresa a acestei modalitati de constituire a garantiilor contribuie la asigurarea unui tratament egal si nediscriminatoriu al operatorilor economici, la extinderea concurentei si la evitarea unor potentiale interpretari restrictive care ar putea genera contestatii, in masura in care legislatia aplicabila nu interzice utilizarea unor instrumente de garantare alternative echivalente. In acest context, va rugam sa precizati expres faptul ca autoritatea contractanta confirma acceptarea politelor de asigurare de garantie pentru constituirea garantiilor solicitate sau, dupa caz, sa indicati temeiul legal expres care limiteaza utilizarea acestora exclusiv la formele prevazute in documentatia de atribuire.

19 dec 2025, 13:27

Securitate

În conformitate cu nivelul de securitate, corect înțelegem, că SSD defectate NU vor fi returnate la producător, iar ASP-ul va fi responsabil de distrugerea lor?

19 dec 2025, 13:29

Anexa 2 si 3 la Anunțul de participare

Vă rugăm respectuos să încărcați pe platforma de achiziții.md, Anexa 2 și Anexa 3 la Anunțul de participare în format Word, pentru a facilita completarea acestora. Mulțumesc

20 dec 2025, 10:14

Cerinta privind existenta unui partener de suport local in Republica Moldova

Avand in vedere cerintele prevazute in Anuntul de participare si Anexa nr. 2, referitoare la obligatia ofertantului de a detine un Service Centru local autorizat in Republica Moldova sau de a prezenta un contract cu un Service Centru local autorizat pentru asigurarea serviciilor de suport, mentenanta si garantie, va rugam sa confirmati faptul ca autoritatea contractanta accepta si participarea operatorilor economici nerezidenti, respectiv a ofertantilor care nu sunt si nici nu detin un contract cu un partener de suport local in Republica Moldova, cu conditia asumarii integrale si demonstrabile a respectarii tuturor cerintelor de SLA, timp de raspuns si timp de solutionare, in aceleasi conditii solicitate in documentatia de atribuire. Mentionam ca documentatia de atribuire stabileste cerinte clare si masurabile privind nivelurile de serviciu (SLA), timpii de interventie, disponibilitatea 24x7, personalul certificat si obligatiile contractuale ale Furnizorului, fara a conditiona in mod explicit indeplinirea acestor cerinte exclusiv de localizarea geografica a partenerului de suport. In acest context, apreciem ca impunerea obligatiei de a fi sau a contracta un partener local, independent de capacitatea reala a ofertantului de a asigura serviciile solicitate conform SLA, poate avea ca efect restrangerea nejustificata a concurentei, prin limitarea accesului operatorilor economici din alte state, contrar principiilor tratamentului egal, nediscriminarii si proportionalitatii prevazute de legislatia nationala si de acordurile internationale aplicabile achizitiilor publice. Totodata, subliniem ca responsabilitatea respectarii SLA-ului, a timpilor de interventie si a tuturor obligatiilor contractuale revine exclusiv Furnizorului, indiferent de modul de organizare interna sau de localizarea resurselor utilizate pentru executarea contractului, aspect care poate fi acoperit inclusiv prin angajamente contractuale ferme, planuri de interventie si penalitati contractuale. In consecinta, va rugam sa confirmati faptul ca autoritatea contractanta accepta ofertele depuse de operatori economici care nu sunt sau dispun de partener de suport local in Republica Moldova, cu conditia demonstrarii clare si verificabile a capacitatii de a respecta integral cerintele de suport, mentenanta si SLA prevazute in documentatia de atribuire, sau, dupa caz, sa indicati temeiul legal expres care justifica limitarea acestei cerinte exclusiv la operatorii economici cu parteneri localizati in Republica Moldova.

22 dec 2025, 19:34

10. REPLICATION & CLUSTERING

Cap. 10.1 – Synchronous replication for Active-Active between 2 locations up to 300m Cap. 10.2 – Zero RPO (Recovery Point Objective) Întrebare de clarificare: Vă rugăm să clarificați dacă cerințele privind replicarea sincronă Active-Active cu Zero RPO implică obligativitatea unei arhitecturi de tip „metro-cluster” (sau echivalent), cu acces simultan activ la date din ambele locații, și dacă această funcționalitate trebuie să fie: - nativă la nivel de sistem de stocare (fără soluții externe), - inclusă integral în ofertă, fără licențe suplimentare sau opțiuni comerciale separate, - disponibilă pentru toate volumele/LUN-urile configurate.

22 dec 2025, 19:36

Active-Active real vs. Active-Passive mascat

Context: Cap. 2.1 – Symmetric Active-Active controller architecture Cap. 5.2 – Active-Active configuration with balanced workload Întrebare de clarificare: Vă rugăm să confirmați dacă arhitectura Active-Active solicitată presupune procesarea simultană a operațiilor de citire/scriere pe ambele controllere, cu balansare activă a workload-ului, fără scenarii de tip Active-Passive sau Preferred Controller.

22 dec 2025, 19:37

Performanță declarată cu toate funcțiile active

Context: Cap. 8.1 – Minimum 300,000 IOPS with inline data reduction Cap. 11.1 / 11.2 – Inline deduplication & inline compression Cap. 13.1–13.3 – Encryption Întrebare: Vă rugăm să clarificați dacă performanța minimă de 300.000 IOPS trebuie îndeplinită cu toate funcționalitățile enterprise activate simultan, inclusiv deduplicare inline, compresie inline, criptare AES-256 și mecanisme de protecție a datelor. Dar in cazul in care 1 sau mai multe controllere sunt offline(down)?

22 dec 2025, 19:40

Security

Context: Cap. 13 – SECURITY Corelat cu Cap. 12 – Snapshots și Cap. 11 – Data Reduction Întrebare: Având în vedere cerințele de securitate și protecție a datelor, vă rugăm să confirmați dacă soluția trebuie să includă mecanisme native de protecție împotriva ransomware, precum: - snapshot-uri imutabile, - protecție WORM / retention lock, - prevenirea ștergerii/modificării malițioase a datelor, și dacă aceste funcționalități trebuie incluse fără licențe suplimentare.

22 dec 2025, 19:43

Cerința 10.3 – Replicare flexibilă

Vă rugăm să clarificați dacă, în contextul cerinței 10.3 „Flexible replication for 1 or more LUNs”, se acceptă solutii ce implementeaza replicarea la un nivel mai jos, cum ar fi la nivel de grupuri de discuri?

23 dec 2025, 14:28

Inconsecvență cerințe

În urma analizei Caietului de sarcini / Anexei nr. 3 – Matricea de conformitate pentru Enterprise Storage Systems, constatăm existența unor necorelări și ambiguități tehnice care pot conduce la interpretări diferite ale cerințelor și, implicit, la oferte necomparabile. Rugam sa răspundeți daca intenția dvs este din nou de a organiza jocuri pina va câștiga cine aveți nevoie? poate este mai simplu deja sa scrieți cerința exacta ce companie trebuie sa livreze? dar in speță, clarificați un simplu exemplu: La secțiunea 9 – Supported Protocols, punctul 9.1, se solicită explicit suport pentru protocolul iSCSI, protocol care, prin definiție, funcționează exclusiv peste conectivitate Ethernet. În schimb, la secțiunea 15 – Connectivity, sunt menționate explicit doar: - interfețe de management 1×1GbE (15.1); - interfețe 32Gb Fibre Channel (15.2, 15.3), fără a fi specificate cerințe minime privind interfețele Ethernet de date necesare pentru iSCSI (număr de porturi, viteză minimă – 10/100/1000 mb sau 10GbE/25GbE/100GbE etc.). prin urmare înțelegem daca vom include 1 interfață de 100Mb o sa fie suficient si acceptabil? acesta clarificare de mai sus este doar un simplu exemplu ca personalul tehnic fie este incompetent, fie joaca jocuri si duce in eroare conducerea? dar oare aceasta nu va genera întrebări de ordin legal?

23 dec 2025, 14:35

Aрхитектура репликации и лицензирование

В технической спецификации предусмотрены требования по репликации данных, при этом из условий процедуры следует, что предполагается поставка четырёх систем хранения данных. В этой связи просим разъяснить архитектурный замысел Заказчика: 1. Предполагается ли объединение всех четырёх систем хранения в единый кластер (общий storage-кластер), или 2. Системы должны функционировать как отдельные (standalone) массивы с настроенной репликацией между ними, или 3. Речь идёт о реализации архитектуры Metro-Storage / Active-Active между площадками? Кроме того, обращаем внимание, что выбранная архитектура напрямую влияет на: - состав и количество лицензий; - необходимость дополнительных аппаратных компонентов (интерконнекты, специальные контроллеры, репликационные модули и т.п.); - корректность и полноту поставки в целом. В связи с этим просим подтвердить, что в рамках данной процедуры требуется включение всех лицензий и аппаратных компонентов, необходимых для полноценного функционирования репликации в запрашиваемой архитектуре, без каких-либо скрытых или подразумеваемых опций. Отсутствие данных разъяснений делает требования неоднозначными и не позволяет однозначно сформировать корректное и сопоставимое коммерческое предложение.

23 dec 2025, 14:41

Вопрос о разъяснении – масштабируемость и расширяемость систем хранения

В технической спецификации упоминаются требования, связанные с возможностью расширения систем хранения, однако параметры и границы такой расширяемости описаны недостаточно ясно. В этой связи просим разъяснить: Предусматривается ли возможность расширения систем хранения в процессе эксплуатации, и если да, то какие элементы должны поддерживать расширение: ресурсы системы; ёмкость хранения; производительность; интерфейсы подключения. Должно ли такое расширение осуществляться: без остановки системы и перерыва в обслуживании, и с использованием компонентов, сертифицированных производителем? Следует ли учитывать указанные возможности расширения как обязательное требование при формировании предложения, либо они рассматриваются как потенциальные/опциональные? Отсутствие чёткого определения параметров расширяемости не позволяет однозначно определить архитектуру решения и может привести к различной интерпретации требований.

23 dec 2025, 14:51

Вопрос о разъяснении – репликация, тип хранилища и носители данных

В технической спецификации ряд критически важных аспектов, характерных для систем класса Enterprise Storage, сформулированы недостаточно однозначно, что допускает различную интерпретацию требований. В этой связи просим разъяснить следующее: 1. Механизм репликации: o допускается ли реализация репликации по Ethernet, o либо репликация должна осуществляться исключительно через выделенные каналы / специализированные интерфейсы (FC)? 2. Тип системы хранения: o рассматривается ли система как исключительно block-level storage, o либо требуется также поддержка file-level (NAS) функциональности, учитывая заявленный enterprise-класс решения? 3. Типы накопителей - допускается ли использование SSD SAS либо требуется SSD NVMe? 4. В формулировке „Enterprise SSD with TLC/eTLC technology or equivalent”: o что именно подразумевается под термином „equivalent”; o допускается ли применение QLC SSD ? Отсутствие чётких разъяснений по указанным вопросам не позволяет однозначно определить целевую архитектуру решения и может привести к предложениям с существенно различающимися техническими характеристиками при формальном соблюдении требований. Просим предоставить соответствующие разъяснения.

25 dec 2025, 13:20

Clarificare Cerinte

**În contextul cerințelor care sunt formulate într-o manieră generală, vă rugăm să clarificați următoarele aspecte, respectiv ce presupun concret și care sunt criteriile exacte de evaluare aplicabile:** **1.2 – Product level (Enterprise-grade)** Vă rugăm să precizați ce criterii obiective definesc în mod concret nivelul *enterprise-grade*: * se evaluează exclusiv producătorul (vendorul) ca fiind recunoscut internațional; * există o listă de producători acceptați sau certificări specifice; * sau sunt avute în vedere caracteristici tehnice minime, portofoliu de clienți enterprise, poziționare pe piață (ex. Gartner, IDC etc.)? **1.3 – Compatibility (Manufacturer certified)** Vă rugăm să clarificați dacă cerința de „manufacturer certified” se aplică: * întregului sistem de stocare ca soluție integrată; * fiecărei componente în parte (controller, discuri, SSD-uri etc.); * și dacă este acceptată o soluție în care sistemul este produs de un vendor (ex. Cisco), iar mediile de stocare de alt producător (ex. Seagate), cu condiția existenței certificării oficiale de compatibilitate între acestea. **1.5 – Mounting (Complete mounting kit)** Vă rugăm să confirmați dacă această cerință presupune exclusiv livrarea kitului fizic de montare (railuri, console), sau dacă include implicit și servicii de instalare și configurare în rack. **10.1 – Synchronous replication, Active-Active configuration** Înțelegem că se solicită un cluster de tip metro-storage, activ-activ, în care ambele locații deservesc workload-uri și, în caz de indisponibilitate a unuia dintre site-uri, celălalt preia automat întreaga sarcină fără pierderi de date (Zero RPO). Vă rugăm să clarificați următoarele: * infrastructura de servere va avea acces simultan la storage din ambele locații; * există deja o rețea SAN inter-site disponibilă sau aceasta trebuie furnizată ca parte a soluției; * unde revine responsabilitatea pentru conectivitatea SAN dintre site-uri (beneficiar sau ofertant)? **Suport și mentenanță – perioada de 5 ani** Vă rugăm să precizați dacă cerința de suport pe 5 ani se referă: * exclusiv la suport direct de la producătorul/vendoul sistemului; * sau se acceptă și suport prin partener local autorizat; * și dacă sunt acceptate componente (ex. discuri) acoperite prin mecanisme de tip „replacement/spare/ZIP” fără contract de suport direct cu producătorul sistemului de stocare.

25 dec 2025, 16:12

Clarificare Răspuns (24 dec 2025, 09:40)

Având în vedere cerința privind existența unei arhitecturi de stocare de tip Active-Active, cu procesare simultană a operațiilor de citire și scriere pe ambele controllere, fără utilizarea unui Preferred Controller sau a unei arhitecturi Active-Passive, vă rugăm să precizați dacă sunt considerate conforme soluțiile de stocare în care, din punct de vedere al implementării interne, fiecare grup de discuri este deținut la un moment dat de un singur controller, iar operațiunile fizice de scriere pe acel grup de discuri sunt efectuate exclusiv de controllerul owner, în timp ce: - în regim normal de funcționare, ambele controllere sunt active simultan, pot primi și procesa cereri I/O de citire și scriere din partea host-urilor; - operațiunile I/O recepționate pe controllerul non-owner sunt redirecționate intern, în mod transparent, către controllerul owner al grupului de discuri, fără impact funcțional asupra host-urilor; - în cazul indisponibilității controllerului owner, ownership-ul grupului de discuri și procesarea operațiunilor I/O sunt preluate automat de celălalt controller, fără întreruperea serviciilor. În acest context, în regim indirect nu este Active-Active, vă rugăm să confirmați dacă evaluarea conformității se realizează din perspectiva comportamentului funcțional observabil (acces activ pe ambele controllere, procesare I/O, balansare a workload-ului și continuitate a serviciilor) și nu din perspectiva mecanismelor interne de ownership și redirecționare a I/O-ului la nivel de implementare.

25 dec 2025, 16:22

Clarificare Cerinte Symmetric Active-Active

Vă rugăm să confirmați dacă prin „Symmetric Active-Active – Load balanced operation” se înțelege că toate controllerele din sistem participă simultan și în mod egal la procesarea operațiilor I/O de citire și scriere pentru toate volumele/grupele de discuri, fără segmentarea volumelor în grupuri fixe de controllere (de tip I/O Groups sau echivalent).

25 dec 2025, 16:22

performanța garantată < 1 ms „under full load”

Vă rugăm să precizați dacă cerința privind latența maximă de 1 ms sub sarcină maximă se aplică inclusiv în scenarii de funcționare degradată, respectiv în cazul defectării unui controller sau al reconstrucției grupurilor de discuri.

25 dec 2025, 16:24

LICENȚIERE PERPETUĂ

Vă rugăm să confirmați dacă toate funcționalitățile solicitate, inclusiv replicarea Active-Active, data reduction inline și funcțiile de disponibilitate, trebuie sa fie incluse integral în oferta de bază, pe durată nelimitată, fără opțiuni suplimentare, subscripții sau costuri recurente.

27 dec 2025, 22:13

Solicitare de clarificare critică – riscuri tehnologice și de securitate privind integrarea storage–backup

Stimată Autoritate Contractantă, În contextul cerințelor tehnice aferente procedurii de achiziție pentru sistemul de stocare, dorim să aducem în atenție un aspect tehnologic esențial, devenit standard de facto în arhitecturile enterprise moderne, în special pentru organizații cu rol și responsabilitate de importanță națională, care gestionează și procesează volume semnificative de date cu caracter personal, date critice și informații utilizate interinstituțional (ex. fisc, vamă, organe de drept). În arhitecturile IT actuale, integrarea nativă a sistemelor de stocare cu soluțiile de backup enterprise, la nivel de snapshot-uri (prin mecanisme dedicate și API-uri oficiale, certificate și suportate de producători), reprezintă o cerință fundamentală de securitate, performanță și continuitate operațională, nu o opțiune. Această integrare permite: realizarea backup-urilor fără impact asupra mediilor de producție, eliminând degradarea performanței sistemelor operaționale; reducerea drastică a ferestrei de backup (backup window), aspect critic pentru sisteme cu disponibilitate ridicată; utilizarea frecventă a snapshot-urilor consistente la nivel de aplicație, permițând atingerea unui RPO extrem de redus, inclusiv apropiat de „RPO = 0” din perspectiva protecției datelor; implementarea eficientă a mecanismelor moderne de protecție anti-ransomware (immutability, snapshot locking, integrare cu soluții de backup pentru detectare, izolare și recuperare rapidă). Dorim totodată să subliniem, în mod explicit, că replicarea datelor la nivel de storage între două centre de date, inclusiv replicarea sincronă, nu este echivalentă cu backup-ul datelor. Orice eroare logică, corupere de date sau atac cibernetic este replicat automat și pe sistemul secundar, ceea ce face ca replicarea și backup-ul să fie procese complementare, dar fundamental diferite ca scop și rol în strategia de protecție a datelor. În lipsa unei cerințe explicite privind integrarea sistemului de stocare cu soluții de backup enterprise la nivel de snapshot-uri, Autoritatea Contractantă își asumă o serie de riscuri semnificative, printre care: acceptarea în procedură a unor sisteme de stocare care nu sunt recunoscute sau acceptate tehnologic pentru integrare de către marea majoritate a producătorilor internaționali de soluții enterprise (backup, securitate, virtualizare, analiză, automatizare); imposibilitatea, pe termen mediu și lung, de a integra sistemul de stocare achiziționat într-un ecosistem enterprise modern, în care instituția va dori implementarea sau extinderea unor soluții de securitate, anti-ransomware, virtualizare, analiză, guvernanță sau automatizare a datelor; apariția unui blocaj tehnologic (vendor lock-in negativ), care limitează opțiunile viitoare ale instituției și conduce la creșterea costurilor totale de operare și modernizare; expunerea infrastructurii IT și a datelor de importanță națională la riscuri operaționale și de securitate, cu impact direct asupra continuității serviciilor publice și asupra imaginii instituției și a statului. Totodată, în contextul parcursului european al Republicii Moldova și al alinierii progresive la standardele și practicile Uniunii Europene, este relevant de menționat că, la nivel european, există o tendință clară de restricționare sau inadmisibilitate a utilizării anumitor producători în organizațiile publice, din considerente ce țin de securitatea datelor, riscuri de ingerință, existența unor ecosisteme tehnologice insuficient dezvoltate și slab integrate cu soluții enterprise consacrate. În acest context, lipsa cerinței menționate mai sus conduce și la o tratare neechitabilă a producătorilor enterprise consacrați, care oferă această funcționalitate în mod standard fără costuri aditionale, demonstrat și validat de-a lungul anilor, în raport cu producători care nu dispun de aceste capabilități, dar care ar putea participa la procedură în condiții aparent egale, deși soluțiile lor nu satisfac cerințele reale de securitate, interoperabilitate și sustenabilitate pe termen lung. Dorim să subliniem că evidențierea acestor riscuri nu are ca scop restrângerea sau constrângerea participării operatorilor economici ori a producătorilor la procedura de achiziție, având în vedere că funcționalitatea menționată este disponibilă în mod standard la majoritatea producătorilor enterprise consacrați, inclusiv la peste șapte vendori activi pe piața Republicii Moldova. Scopul acestei clarificări este acela de a permite Autorității Contractante o evaluare obiectivă și responsabilă a maturității tehnologice a soluțiilor ofertate, precum și de a asigura selectarea unor sisteme de stocare care se integrează într-un ecosistem enterprise modern, interoperabil și sustenabil, reducând riscurile tehnologice și operaționale pe termen lung. Având în vedere cele expuse, vă rugăm ca Autoritatea Contractantă să includă în caietul de sarcini cerința explicită privind compatibilitatea și integrarea nativă a sistemului de stocare cu soluții de backup enterprise, la nivel de snapshot-uri, prin mecanisme certificate și suportate oficial de producători. Considerăm că această clarificare este esențială pentru asigurarea unui nivel maxim de securitate a datelor, obiectivitate tehnologică, echilibru concurențial și aliniere la cele mai bune practici internaționale și europene în domeniul protecției informațiilor critice, corespunzător statutului unei instituții de importanță națională.

28 dec 2025, 08:39

SLA

Vă rugăm să precizați ce înseamnă „localizați pe teritoriul RM”: domiciliu, loc de muncă permanent în RM, disponibilitate de intervenție în RM în timpii SLA? (Pentru a evita interpretări arbitrare și respingeri formale.)

28 dec 2025, 08:40

Valoarea estimată fără TVA

Având în vedere volatilitatea prețurilor la echipamente hardware și faptul că listele de preț ale producătorilor/distribuitorilor se pot actualiza la început de an, vă rugăm să clarificați dacă autoritatea contractantă va revizui valoarea estimată sau, alternativ, cum va aplica în mod nediscriminatoriu restricția privind „ofertele care depășesc cu 30% suma estimată”, astfel încât să nu fie excluși operatori economici din motive obiective de piață.”

28 dec 2025, 08:40

ISO

10. Având în vedere că documentația de atribuire pune un accent major pe nivelurile de servicii (SLA) – inclusiv suport 24×7, timpi de răspuns/soluționare și intervenții on-site – vă rugăm să clarificați rațiunea pentru care, la criteriile de calificare, se solicită ISO 9001 și ISO 27001, dar nu se solicită și un standard specific de management al serviciilor IT, cum este ISO/IEC 20000-1, care vizează direct organizarea și controlul proceselor de furnizare a serviciilor IT conform SLA. În acest context, vă rugăm să precizați dacă autoritatea contractantă consideră ISO/IEC 20000-1 relevant pentru asigurarea SLA și, dacă da, de ce nu a fost inclus ca cerință (sau criteriu alternativ/echivalent) și cum intenționează să verifice, în mod obiectiv și nediscriminatoriu, capacitatea ofertantului de a opera și menține un sistem de management al serviciilor compatibil cu nivelurile SLA solicitate.

28 dec 2025, 08:42

Cerința 4.2 – Tipul de unități SSD (TLC/eTLC sau echivalent)

Având în vedere clarificarea anterioară conform căreia SSD QLC nu este acceptat „din considerente de durabilitate”, vă rugăm să detaliați criteriile tehnice concrete pe baza cărora se evaluează această durabilitate, respectiv: a) valoarea minimă acceptată pentru DWPD / TBW, b) perioada de referință (ex. 5 ani), c) corelarea cu profilul de workload solicitat (70% read / 30% write, bloc 16KB – cerința 8.2). În acest context, vă rugăm să clarificați dacă sunt acceptate unități SSD certificate de producător pentru uz enterprise, indiferent de tehnologia celulei (TLC sau QLC), atâta timp cât acestea îndeplinesc sau depășesc valorile minime de durabilitate, performanță și fiabilitate cerute, și sunt utilizate într-o arhitectură de stocare care: 1) minimizează write-amplification prin mecanisme avansate de caching și data placement, 2) utilizează DRAM cache și protecție la scriere (write avoidance), 3) asigură distribuția uniformă a scrierilor la nivel de sistem. Menționăm că, la unii producători enterprise, SSD-urile QLC de generație nouă sunt certificate pentru workload-uri enterprise specifice, având valori DWPD comparabile cu anumite implementări TLC, datorită arhitecturii controlerelor și algoritmilor de protecție a mediului de stocare. Vă rugăm să confirmați dacă evaluarea se face strict pe baza tehnologiei celulei (TLC vs QLC) sau pe baza indicatorilor tehnici măsurabili și certificării producătorului.

28 dec 2025, 08:43

Cerința 4.1 – Capacitate minimă utilizabilă de 200 TB

Vă rugăm să confirmați dacă valoarea de 200 TB capacitate minimă utilizabilă reprezintă spațiul net efectiv disponibil aplicațiilor, calculat: 1) după aplicarea mecanismelor de protecție a datelor (RAID 6 sau echivalent, conform cerinței 6.1), 2) cu asigurarea toleranței la defectarea simultană a minimum două unități de stocare, 3) fără a lua în calcul funcțiile de reducere a datelor (deduplicare și compresie), thin provisioning sau alte mecanisme de optimizare logică a spațiului. De asemenea, vă rugăm să clarificați dacă, pentru determinarea acestei capacități utilizabile, sunt acceptate scheme moderne de protecție a datelor de tip RAID distribuit / erasure coding, atâta timp cât acestea oferă un nivel de reziliență cel puțin echivalent cu RAID 6 și sunt certificate de producător pentru uz enterprise. Această clarificare este necesară pentru a asigura o dimensionare corectă și comparabilă a soluțiilor propuse, evitând interpretări diferite privind capacitatea fizică instalată versus capacitatea logică rezultată în urma reducerii datelor.

28 dec 2025, 08:43

Cerința 7.1 – Memorie cache minim 256GB per controller

Vă rugăm să confirmați că memoria cache minimă de 256 GB menționată la cerința 7.1 este specificată pentru fiecare controller fizic (adică fiecare nod de control să dispună de cel puțin 256 GB memorie cache, rezultând un minim de 512 GB cache total în sistemul cu două controllere). Justificare: Clarificarea asigură o interpretare unitară – că este vorba de 256 GB DRAM cache per controller și nu cumulativ – astfel încât ofertanții să prevadă, dacă este necesar, upgrade-urile de memorie aferente. Unele platforme pot folosi și cache pe suport flash suplimentar, însă precizarea de față se referă la memoria cache principală (RAM) din fiecare controller, pentru alinierea configurațiilor propuse la cerință.

28 dec 2025, 08:44

Cerința 7.2 – Protecția memoriei cache

Având în vedere că cerința 7.2 prevede protecția cache-ului prin mirroring sau mecanisme echivalente în caz de pierdere a alimentării sau defectare de controller, vă rugăm să confirmați că nu este impusă utilizarea unei baterii fizice, ci este acceptată orice soluție tehnică certificată de producător care asigură: a) păstrarea integrală a datelor din write cache în caz de pană de curent, b) restaurarea automată și sigură a cache-ului la repornire, c) un nivel de fiabilitate cel puțin echivalent cu soluțiile clasice bazate pe baterii. În acest sens, sunt considerate conforme implementările moderne utilizate în sistemele enterprise care folosesc supercondensatori și memorie non-volatilă (flash-backed cache) pentru protecția datelor din cache, fără utilizarea bateriilor, având avantajul eliminării componentelor consumabile și a riscurilor de degradare în timp? Solicităm această clarificare pentru a ne asigura că evaluarea se face pe baza funcționalității și nivelului de protecție oferit, și nu pe baza unei tehnologii specifice de implementare.

28 dec 2025, 08:44

Cerința 8.1 – Performanță minimă IOPS

Având în vedere formularea „Minimum IOPS with inline data reduction 300,000 IOPS” din cerința 8.1, vă rugăm să clarificați dacă această valoare de performanță: 1) reprezintă capacitatea minimă de procesare I/O a sistemului de stocare, măsurată în condițiile de workload specificate la cerința 8.2 (70% read / 30% write, bloc 16KB), 2) iar funcțiile de deduplicare și compresie sunt disponibile și suportate de sistem, conform cerințelor din capitolul 11, fără a fi obligatoriu active în timpul testului de performanță. În practică, performanța IOPS este puternic influențată de tipul datelor utilizate în test (date compresibile vs. incompre¬sibile), ceea ce poate conduce la rezultate necomparabile între diferite platforme. Pentru asigurarea unei evaluări corecte și reproductibile între ofertanți, vă rugăm să confirmați dacă este acceptată demonstrarea pragului de 300.000 IOPS: a) pe date neutre / incompre¬sibile, b) cu deduplicarea și compresia disponibile la nivel de sistem, dar dezactivate în timpul benchmark-ului. Această clarificare este necesară pentru a evita interpretări diferite ale cerinței și pentru a permite o comparație obiectivă a capacităților reale ale controlerelor de stocare.

28 dec 2025, 08:45

Cerința 8.3 – Latență maximă 1ms sub sarcină

Rugăm clarificare dacă valoarea de latență de maximum 1 ms menționată la cerința 8.3 se referă la latența medie măsurată sub sarcina specificată sau la un prag de latență absolut (peak) ce nu trebuie depășit. De asemenea, se aplică această cerință în termeni de percentilă (de exemplu, 99% din I/O să aibă sub 1ms latență)? Justificare: Această precizare este importantă pentru a alinia metodologia de testare a performanței cu așteptările autorității. Dacă 1ms este o medie, putem dimensiona corespunzător sistemul astfel încât să mențină timpii medii de răspuns foarte scăzuți la 300k IOPS. Dacă însă este un maximum absolut sau o percentilă strictă, cerința devine și mai exigentă, subliniind necesitatea unei soluții all-flash NVMe cu latență extrem de mică. Confirmarea modului de măsurare ajută la oferirea unei garanții de performanță conforme (de exemplu, majoritatea sistemelor NVMe enterprise pot asigura <1ms latență medie la sarcina dată, însă latența maximă instantanee poate varia ușor; specificarea percentilei ar elimina orice ambiguitate).

28 dec 2025, 08:45

Cerințele 6.1 și 6.2 – Niveluri RAID și protecția datelor

Având în vedere că cerința mandatory din punctul 6.1 prevede suport pentru RAID 6 sau un mecanism echivalent, cu toleranță la defectarea simultană a minimum două unități de stocare, iar punctul 6.2 enumeră RAID 5 și RAID 10 ca opționale, vă rugăm să confirmați următoarele: 1. Criteriul esențial de conformitate este asigurarea toleranței la minimum două discuri defecte simultan, conform cerinței 3.3, indiferent de modul concret de implementare (RAID clasic sau mecanisme moderne echivalente). 2. Sunt acceptate implementări de tip RAID distribuit / erasure coding avansat, utilizate în sistemele enterprise all-flash moderne, atâta timp cât acestea: a) oferă un nivel de protecție cel puțin echivalent cu RAID 6, b) asigură performanță constantă și timpi de reconstrucție reduși, c) sunt certificate de producător pentru medii enterprise. 3. Suportul pentru RAID 5 și/sau RAID 10, fiind specificat ca opțional, nu constituie o condiție obligatorie de eligibilitate, în măsura în care soluția propusă respectă integral cerințele de reziliență și disponibilitate prevăzute la punctele 3.3 și 6.1. Solicităm această clarificare pentru a evita interpretarea eronată conform căreia prezența unor niveluri RAID opționale ar prevala asupra cerinței mandatory privind protecția la defectarea a minimum două unități de stocare.

28 dec 2025, 08:46

Cerințele 9.1 și 15.2 – Conectivitate FC și iSCSI

Având în vedere că la cerința 9.1 este solicitat suport obligatoriu pentru protocoalele Fibre Channel și iSCSI, iar la cerința 15.2 sunt definite explicit doar interfețele Fibre Channel (min. 2 × 32Gb FC per controller), vă rugăm să clarificați următoarele: 1. Dacă suportul pentru iSCSI este considerat o funcționalitate logică obligatorie a sistemului, fără impunerea explicită a unui număr minim sau tip specific de porturi Ethernet dedicate în configurația de bază; 2. Dacă este acceptată furnizarea conectivității iSCSI prin interfețe Ethernet existente sau configurabile, cu condiția respectării cerințelor de performanță, multipathing și disponibilitate prevăzute în caietul de sarcini; 3. Dacă este corectă interpretarea conform căreia cerința 15.2 stabilește minimum obligatoriu pentru conectivitatea Fibre Channel, fără a exclude alte opțiuni de conectivitate pentru iSCSI, care pot fi adaptate în funcție de arhitectura propusă. Solicităm această clarificare pentru a asigura o configurare optimă a interfețelor de date și pentru a evita supra-dimensionarea nejustificată a infrastructurii, în condițiile în care sistemele enterprise moderne oferă flexibilitate ridicată în implementarea protocoalelor SAN.

28 dec 2025, 08:46

Cerința 9.2 – Protocoale opționale NVMe-over-Fabrics

În legătură cu cerința 9.2, care menționează protocoalele NVMe/FC, NVMe/TCP etc. ca fiind opționale, vă rugăm să clarificați dacă: a) suportul pentru aceste protocoale moderne de tip NVMe-over-Fabrics este considerat strict informativ, fără impact asupra procesului de evaluare, b) sau dacă disponibilitatea acestora poate fi considerată un element diferențiator în contextul evaluării tehnice a soluțiilor propuse. Având în vedere că tehnologiile NVMe-over-Fabrics pot oferi latență redusă, eficiență sporită și scalabilitate superioară față de protocoalele SAN tradiționale, această clarificare este necesară pentru a înțelege dacă beneficiarul urmărește exclusiv conformitatea cu cerințele obligatorii sau ia în considerare și nivelul de pregătire al soluției pentru evoluții tehnologice viitoare. Solicităm această precizare pentru a ne asigura că prezentarea caracteristicilor opționale în ofertă este aliniată cu modul de evaluare aplicat.

28 dec 2025, 08:47

Clarificare suplimentară – tratamentul cerințelor opționale în evaluare

Totodată, vă rugăm să precizați în mod general modul în care sunt tratate cerințele marcate ca opționale în documentația tehnică, respectiv: • dacă acestea sunt analizate exclusiv în scop informativ, • sau dacă îndeplinirea lor poate fi luată în considerare calitativ în procesul de evaluare, în special în situația în care mai multe oferte îndeplinesc integral cerințele obligatorii. Solicităm această clarificare pentru a asigura o abordare transparentă și unitară a evaluării ofertelor și pentru a permite ofertanților să dimensioneze corect nivelul de funcționalitate propus.

28 dec 2025, 08:47

Cerința 15.3 – Interfețe pentru replicare sincronă

Referitor la cerința 15.3, care prevede existența a minim 2 × 32G Fibre Channel (sau echivalent) per controller pentru replicare sincronă, vă rugăm să clarificați următoarele aspecte: 1. Dacă aceste interfețe trebuie să fie fizic dedicate exclusiv replicării, sau dacă este acceptată utilizarea unor porturi existente (de exemplu din cele prevăzute la cerința 15.2), cu condiția asigurării separării logice a traficului, a redundanței căilor și a lățimii de bandă necesare pentru replicare sincronă cu Zero RPO; 2. În ce măsură termenul „echivalent” permite utilizarea unor tehnologii alternative de conectivitate, care pot susține replicarea sincronă pe distanțe de până la ~300 m, respectând cerințele de performanță, latență și disponibilitate, chiar dacă implementarea nu se bazează pe porturi Fibre Channel dedicate în sens strict; Solicităm această clarificare pentru a asigura o configurare corectă și eficientă a interfețelor de replicare și pentru a evita interpretări diferite privind cerințele de redundanță și separare a traficului în soluțiile propuse.

28 dec 2025, 08:48

Cerințele 10.1 și 10.2 – Replicare sincronă și configurație Active-Active

Având în vedere că cerința 10.1 menționează explicit o configurație Active-Active pentru replicarea sincronă între două locații (până la 300 m), iar cerința 10.2 prevede Zero RPO, vă rugăm să clarificați dacă: a) se așteaptă ca sistemul de stocare să suporte o arhitectură de tip stretched cluster, în care același volum de date este accesibil simultan din ambele locații, cu continuitate automată a operațiunilor în cazul indisponibilității unuia dintre site-uri; b) sau dacă este considerată suficientă o implementare de replicare sincronă clasică, cu mecanism de failover între site-uri, fără acces concurent la volume. Această clarificare este necesară pentru a alinia arhitectura soluțiilor propuse cu nivelul de disponibilitate și continuitate operațională așteptat, în special în contextul cerinței de disponibilitate de 99.9999% și al obiectivului de Zero RPO.

28 dec 2025, 08:49

Cerința 11.1 – Deduplicare inline (nivel de aplicare)

Referitor la cerința 11.1, care prevede deduplicare inline „la nivel de bloc și volum”, vă rugăm să clarificați dacă: a) se așteaptă ca deduplicarea să fie aplicată global, la nivelul întregului pool de stocare (eliminând datele duplicate inclusiv între volume diferite), b) sau dacă este considerată suficientă deduplicarea aplicată independent la nivelul fiecărui volum/LUN. Această clarificare este necesară pentru interpretarea corectă a cerinței și pentru a asigura o dimensionare adecvată a capacității de stocare, având în vedere că deduplicarea globală poate oferi un nivel superior de eficiență, în special în medii cu volume multiple ce conțin date similare. Solicităm această precizare pentru a ne asigura că soluțiile propuse sunt aliniate cu nivelul de eficiență a stocării așteptat, fără a introduce interpretări diferite ale cerinței.

28 dec 2025, 08:49

Cerința 11.3 – Operare fără restricții a funcțiilor de reducere a datelor

Referitor la cerința 11.3, care prevede operarea fără impact sau restricții a funcțiilor de deduplicare și compresie, vă rugăm să confirmați dacă aceasta înseamnă că: 1) funcțiile de deduplicare și compresie pot fi utilizate simultan și fără limitări împreună cu toate celelalte funcționalități critice ale sistemului, precum replicarea sincronă, snapshot-urile, criptarea datelor la rest, multipathing-ul și mecanismele de înaltă disponibilitate; 2) soluția de stocare nu impune dezactivarea deduplicării sau compresiei pentru a putea utiliza aceste funcții în paralel și nu introduce restricții funcționale (de exemplu, limitări de volum, de număr de snapshot-uri sau de mod de replicare). Această clarificare este necesară pentru a evita interpretări diferite ale cerinței și pentru a asigura că soluțiile propuse oferă un nivel real de funcționalitate enterprise, fără compromisuri sau condiționări între componentele software ale sistemului.

28 dec 2025, 08:50

Cerința 13.3 – Managementul cheilor de criptare

Referitor la cerința 13.3 privind managementul securizat al cheilor de criptare, vă rugăm să clarificați dacă: 1) este considerată suficientă o soluție de management intern al cheilor, implementată la nivelul sistemului de stocare, care asigură stocarea securizată a cheilor, controlul accesului și protecția acestora conform standardelor enterprise; 2) sau dacă se așteaptă în mod explicit posibilitatea de integrare cu un sistem extern de management al cheilor, utilizat la nivelul infrastructurii beneficiarului. Având în vedere că majoritatea platformelor enterprise de stocare implementează managementul intern al cheilor ca mecanism standard, iar integrarea cu sisteme externe este utilizată preponderent în scenarii de conformitate sau politici avansate de securitate, această clarificare este necesară pentru a alinia soluțiile propuse cu nivelul de securitate așteptat, fără a introduce cerințe suplimentare neexplicitate în documentația de achiziție.

28 dec 2025, 08:50

Cerințele 14.3 și 14.4 – Analiză predictivă și operare on-premises

Având în vedere că cerința 14.3 menționează analiza predictivă ca funcționalitate opțională, iar cerința 14.4 prevede că soluția trebuie să funcționeze on-premises, fără dependență obligatorie de conexiune la internet, vă rugăm să clarificați dacă: 1) este considerată conformă o soluție care asigură managementul și monitorizarea completă local, fără necesitatea unei conexiuni la internet pentru funcționarea de bază; 2) iar funcționalitățile de analiză predictivă, dacă există, pot fi furnizate opțional, fără a fi necesare pentru operarea, administrarea sau disponibilitatea sistemului. Această clarificare este necesară pentru a evita interpretarea conform căreia utilizarea facultativă a unor mecanisme de analiză avansată ar contraveni cerinței de operare on-premises, în condițiile în care autonomia locală a sistemului este pe deplin asigurată.

28 dec 2025, 08:51

Clarificare suplimentară – valabilitatea licențelor în cazul upgrade-urilor

Având în vedere clarificările oferite anterior privind licențierea perpetuă a tuturor funcționalităților solicitate, vă rugăm să confirmați dacă, în cazul unor upgrade-uri hardware sau extinderi de capacitate realizate pe durata de viață a sistemului, funcționalitățile deja licențiate rămân valabile și active, fără a necesita achiziționarea unor licențe suplimentare pentru aceleași funcții software. Această clarificare este solicitată pentru a înțelege modul de aplicare a licențelor perpetue în scenarii de extindere a sistemului.

28 dec 2025, 08:51

Clarificare – operare simultană a funcțiilor avansate

Vă rugăm să confirmați dacă se așteaptă ca funcțiile de deduplicare, compresie, snapshot și replicare sincronă Active-Active să poată fi utilizate simultan, fără restricții operaționale, pentru toate volumele configurate.

28 dec 2025, 08:52

Clarificare – snapshot-uri și impact de performanță

Referitor la cerințele privind snapshot-urile (Cap. 12), vă rugăm să precizați dacă „fără impact de performanță” se referă la: – lipsa întreruperilor funcționale, – sau menținerea performanței I/O în limitele specificate la Cap. 8, indiferent de numărul de snapshot-uri configurate per volum.

28 dec 2025, 08:52

Clarificare – comportament în scenarii de reconstrucție

În scenarii de reconstrucție a mediilor de stocare (rebuild RAID sau echivalent), există cerințe minime privind menținerea accesului și predictibilitatea performanței pentru workload-urile active, sau este suficientă exclusiv menținerea disponibilității și integrității datelor?

28 dec 2025, 08:56

Incoterms – DAP vs DDP, import/vămuire

Vă rugăm să confirmați Incoterms-ul aplicabil. Menționăm că DAP înseamnă livrare la locația beneficiarului, însă formalitățile și taxele de import/vămuire rămân în sarcina cumpărătorului, pe când DDP presupune livrare la aceeași locație, dar cu import clearance și taxe achitate de furnizor.

31 dec 2025, 13:10

Next Business Day (NBD)

Vă rog să confirmați cine garantează și susține efectiv SLA-ul Next Business Day (NBD): 1.Vendorul (producătorul) – prin contract de service/garanție cu NBD (inclusiv flux RMA accelerat și livrare piese/înlocuire), sau 2.Furnizorul local – cu instrumentele și resursele proprii disponibile imediat (stoc local de piese/echipamente, echipă tehnică, capacitate de intervenție, proceduri și acces direct la escaladare/RMA). Menționăm că furnizorul local nu poate garanta SLA-ul NBD doar prin intervenții cu forțe proprii, în lipsa unui suport operațional din partea vendorului (RMA accelerat, piese/înlocuire), deoarece dacă nu există piese sau echipamente în stoc local, respectarea termenului NBD devine dependentă de timpii vendorului și nu mai poate fi livrată conform SLA-ului stabilit. În plus, în practica locală, SLA-ul NBD nu este, de regulă, livrat direct de vendor, ci este asumat de furnizor/partenerul local în măsura în care are stoc și capabilități locale, ceea ce confirmă necesitatea unui mecanism clar de suport din partea vendorului pentru cazurile fără stoc.

31 dec 2025, 13:11

Next Business Day (NBD)

Pentru acceptanța clientului (și eventual audit), ce dovadă trebuie furnizată că SLA-ul NBD este inclus și activ: print-screen/confirmare portal, certificat producător, confirmare vendor?

31 dec 2025, 13:11

Clarificare privind criteriul de conformitate al soluției de stocare

Având în vedere clarificările anterioare conform cărora nu sunt stabilite valori minime explicite pentru indicatori de durabilitate (DWPD/TBW), dar că soluția propusă trebuie să îndeplinească cerințele de performanță (Cap. 8) și disponibilitate (Cap. 2) pe întreaga perioadă de garanție și suport, vă rugăm să precizați următoarele: • dacă îndeplinirea continuă a cerințelor din Cap. 2 și Cap. 8, demonstrată prin certificarea producătorului și acoperită integral de garanție și suport pentru scenariul de utilizare solicitat, reprezintă criteriul determinant de acceptare a soluției; • sau dacă evaluarea se realizează exclusiv pe baza clasificării tehnologice a mediilor de stocare, independent de capacitatea soluției de a susține cerințele funcționale pe durata de viață garantată. Această clarificare este necesară pentru a înțelege dacă evaluarea se face la nivel de soluție de stocare ca ansamblu sau la nivel de componentă individuală, în condițiile în care responsabilitatea pentru îndeplinirea cerințelor pe durata garanției revine producătorului soluției.

31 dec 2025, 13:12

Form factor (formulare rafinată, cu 1U introdus voalat)

Având în vedere că documentația de achiziție prevede un form factor de 2U–4U, fără a corela explicit această cerință cu parametri funcționali precum capacitatea minimă utilizabilă, performanța solicitată sau nivelul de disponibilitate, vă rugăm să clarificați dacă, în situația în care o soluție de stocare compactă, de generație actuală, se încadrează într-un spațiu redus în rack și îndeplinește integral cerințele din Cap. 2 (disponibilitate), Cap. 8 (performanță) și toate cerințele funcționale obligatorii, form factorul fizic rămâne un criteriu determinant de acceptare sau dacă evaluarea se realizează la nivelul capacității soluției de a susține cerințele operaționale pe durata garanției și suportului.

31 dec 2025, 13:12

Criteriul real de evaluare a performanței

Vă rugăm să clarificați dacă îndeplinirea cerinței de performanță minimă (300.000 IOPS, conform Cap. 8) este evaluată ca performanță susținută în condiții reale de operare, cu funcțiile solicitate active (replicare sincronă, snapshot-uri, mecanisme de protecție), sau dacă este suficientă demonstrarea acesteia într-un scenariu ideal, independent de modul efectiv de exploatare al soluției.

31 dec 2025, 13:12

Performanță în configurație Active-Active

Având în vedere cerințele 10.1–10.2 privind replicarea sincronă în configurație Active-Active cu Zero RPO, vă rugăm să precizați dacă cerințele de performanță și latență trebuie îndeplinite în mod susținut în această configurație operațională, sau dacă este acceptabil ca acestea să fie îndeplinite exclusiv într-o configurație locală, fără replicare activă între locații.

31 dec 2025, 13:13

Disponibilitate 99.9999% (criteriu arhitectural vs. declarativ)

Vă rugăm să clarificați dacă nivelul de disponibilitate solicitat (99.9999%) este evaluat pe baza arhitecturii tehnice a soluției (Active-Active real, redundanță completă, eliminarea punctelor unice de defect), sau dacă este suficientă o declarație generală a producătorului, independent de mecanismele concrete implementate.

31 dec 2025, 13:13

Comportamentul sistemului în scenarii de reconstrucție

Vă rugăm să precizați dacă, în scenarii de reconstrucție a mediilor de stocare (rebuild sau echivalent), menținerea unui nivel predictibil de performanță pentru workload-urile active reprezintă un criteriu de evaluare, sau dacă este suficientă exclusiv menținerea integrității și disponibilității datelor, chiar și în condițiile unei degradări semnificative de performanță.

31 dec 2025, 13:13

Snapshot-uri și impact operațional real

Referitor la cerința privind configurarea a minimum 365 snapshot-uri per volum, vă rugăm să clarificați dacă mențiunea „fără impact” se referă la menținerea parametrilor de performanță specificați în Cap. 8, sau exclusiv la absența întreruperilor funcționale, fără a lua în considerare impactul asupra I/O-ului.

31 dec 2025, 13:14

Upgrade non-disruptiv în configurație Active-Active

Vă rugăm să precizați dacă cerința privind actualizările non-disruptive se aplică inclusiv în configurații Active-Active cu replicare sincronă funcțională, fără întreruperea accesului la date și fără degradări operaționale perceptibile din niciuna dintre locații.

31 dec 2025, 13:14

Evaluarea soluției ca ansamblu vs. componente individuale

Vă rugăm să clarificați dacă evaluarea conformității tehnice se realizează la nivelul soluției de stocare ca ansamblu integrat, sau la nivelul componentelor individuale (medii de stocare, controllere), independent de comportamentul efectiv al sistemului în exploatare și de capacitatea acestuia de a îndeplini cerințele pe durata garanției.

31 dec 2025, 13:15

Tratamentul cerințelor opționale în evaluare

Vă rugăm să confirmați dacă îndeplinirea cerințelor obligatorii constituie criteriul exclusiv de conformitate, iar cerințele marcate ca opționale sunt analizate doar din perspectivă calitativă, fără a avea caracter eliminatoriu sau a influența negativ evaluarea ofertelor conforme.

31 dec 2025, 13:15

Neutralitatea tehnologică (formulare matură)

Vă rugăm să confirmați dacă evaluarea ofertelor se realizează cu respectarea principiului neutralității tehnologice, criteriul determinant fiind capacitatea soluției de a îndeplini cerințele funcționale, de performanță și disponibilitate pe durata garanției și suportului, independent de arhitectura fizică sau de opțiunile constructive utilizate.

31 dec 2025, 13:18

ISO/IEC 20000-1

În lipsa ISO/IEC 20000-1 (standard dedicat managementului serviciilor IT), ce mecanism concret și verificabil folosește autoritatea contractantă pentru a demonstra că un ofertant poate livra SLA 24×7 și timpii solicitați, dincolo de o declarație de conformitate? Având în vedere rolul direct al ISO/IEC 20000-1 în controlul proceselor SLA, de ce nu a fost inclus ca cerință obligatorie sau criteriu alternativ/echivalent?

31 dec 2025, 13:49

NBD

Vă rugăm să confirmați concret ce document este acceptat ca dovadă că SLA Next Business Day (NBD) este inclus și activ pentru echipamentele livrate (pentru acceptanță/audit)

31 dec 2025, 13:53

Condiții contractuale

În răspuns menționați că dovada pentru SLA NBD se va solicita ‘conform prevederilor/condițiilor contractuale’. Vă rugăm să indicați exact la ce condiții vă referiți: articolul/punctul din contract (sau din proiectul de contract/caietul de sarcini) care stabilește (1) ce documente sunt acceptate ca dovadă și (2) când trebuie prezentate (evaluare, recepție, pe durata garanției).

31 dec 2025, 13:57

Documentație de atribuire

Orice răspuns la clarificări publicat în sistem devine parte integrantă a documentației de atribuire și se aplică uniform tuturor operatorilor economici, pentru a evita interpretări diferite?

31 dec 2025, 14:01

256 GB cache

Având în vedere că arhitecturile moderne de stocare enterprise utilizează mecanisme diferite de caching (RAM unificată, caching dinamic pentru date și metadata, NVMe buffers, read-ahead adaptiv), vă rugăm să confirmați dacă accentul cerinței este pe atingerea performanței minime de 300.000 IOPS la o latență de 1 ms, indiferent de implementarea internă a memoriei cache. În acest context, vă rugăm să precizați dacă cerința de „256 GB cache per controller” poate fi considerată îndeplinită prin demonstrarea performanței solicitate, chiar dacă soluția ofertată nu dispune de un cache dedicat static de 256 GB per controller, ci utilizează o arhitectură diferită de gestionare a memoriei, fără a limita nejustificat competiția între soluțiile enterprise echivalente din punct de vedere funcțional și de performanță.

31 dec 2025, 14:04

Garanție

Vă rugăm să confirmați dacă, pentru garanția de participare, sunt acceptate și alte forme de constituire/depunere decât cea indicată în documentație (ex.: transfer/ordin de plată, scrisoare de garanție bancară, garanție de asigurare etc.). Dacă da, care sunt formele acceptate?