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

Î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?

... afișează tot conținutul

Confirmăm înțelegerea corectă. Conform ”anexa nr. 2 la anunțul de participare.signed” – p. 3.3 din Cerințele pentru prestarea serviciilor de punere în funcțiune, garanție și a serviciilor de support (deservire, mentenanță și reparație) pentru Enterprise Storage (Sisteme de stocare): "Politici speciale - Retenție discuri defecte":
• Toate unitățile de stocare defecte (SSD/NVMe) rămân în posesia ASP
• NU se returnează la producător sau furnizor
• ASP asigură distrugerea conform procedurilor interne de securitate informațională
Această cerință este obligatorie pentru conformarea cu reglementările naționale privind protecția datelor și securitatea informațională aplicabile prestatorilor de servicii esențiale.

... afișează tot conținutul

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

... afișează tot conținutul

Buna ziua, anexele 2 și 3 au fost incarcate pe platforma.

... afișează tot conținutul

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.

... afișează tot conținutul

Se confirmă că cerințele de replicare sincronă Active-Active cu Zero RPO implică o arhitectură de tip metro-cluster sau funcționalitate echivalentă cu prezentarea justificării corespunzătoare de corespundere cu cerința în cauză. Clarificăm următoarele:
• Funcționalitatea trebuie să fie nativă la nivelul sistemului de stocare, fără dependență de soluții externe de replicare.
• Toate licențele necesare pentru această funcționalitate trebuie incluse integral în ofertă, fără costuri sau opțiuni comerciale separate.
Funcționalitatea trebuie să fie disponibilă pentru toate volumele/LUN-urile configurate, conform cerinței 10.3.

... afișează tot conținutul

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.

... afișează tot conținutul

Se confirmă. Arhitectura Active-Active solicitată presupune procesarea simultană a operațiilor I/O (citire/scriere) pe ambele controllere, cu balansare activă și simetrică a workload-ului. Nu se acceptă arhitecturi de tip Active-Passive, Preferred Controller sau ALUA asimetric care ar limita accesul activ la un singur controller la un moment dat pentru un anumit volum.

... afișează tot conținutul

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)?

... afișează tot conținutul

Se confirmă că performanța minimă de 300.000 IOPS trebuie demonstrată cu toate funcționalitățile enterprise activate simultan: deduplicare inline, compresie inline, criptare AES-256 și protecție RAID. Aceasta reprezintă cerința pentru configurația completă cu ambele controllere operaționale.
În situația defectării unui controller (failover), sistemul trebuie să rămână operațional conform cerinței 2.4 (50% controller failure tolerance). În acest scenariu degradat, performanța poate fi redusă proporțional, însă disponibilitatea și integritatea datelor trebuie menținute.

... afișează tot conținutul

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.

... afișează tot conținutul

Specificațiile tehnice actuale nu includ cerințe explicite privind mecanismele de protecție anti-ransomware (snapshot-uri imutabile, WORM/retention lock). Aceste funcționalități sunt considerate opționale și pot fi prezentate ca valoare adăugată în ofertă.
Cerințele minime și obligatorii de securitate rămân cele specificate în Cap. 13: criptare AES-256, accelerare hardware și management securizat al cheilor.

... afișează tot conținutul

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?

... afișează tot conținutul

Cerința 10.3 specifică flexibilitatea replicării pentru „1 sau mai multe LUN-uri", indicând granularitate la nivel de volum logic. Se acceptă soluții care implementează replicarea la nivel de grup de discuri (disk group/consistency group), cu prezentarea justificării corespunzătoare de corespundere cu cerința în cauză și cu condiția ca:
• Granularitatea să permită selectarea și replicarea individuală a volumelor/LUN-urilor necesare, fără obligativitatea replicării întregului sistem.
• Să se asigure consistența datelor pentru volumele replicate (consistency groups).

... afișează tot conținutul

Î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?

... afișează tot conținutul

Cerințele sunt clar și explicit stabilite în documentația de achiziție. Ofertanții trebuie să manifeste diligența necesară în studierea completă a specificațiilor tehnice.
Secțiunea 15 – Connectivity definește exhaustiv interfețele solicitate:
• 15.1 Management interfaces: Min. 1 × 1GbE per controller, inclusiv cablu UTP Cat6/Cat6a (min. 1m)
• 15.2 Data interfaces: Min. 2 × 32Gb FC per controller (module SFP+ incluse), inclusiv cabluri OM4 LC-LC duplex (min. 3m)
• 15.3 Replication interfaces: Min. 2 × 32G FC sau echivalent per controller, inclusiv cabluri OM4 LC-LC duplex (min. 3m)
Protocolul principal de date este Fibre Channel. Cerința 9.1 privind suportul iSCSI reprezintă o cerință de compatibilitate a sistemului de stocare. Interfața 1GbE (15.1) asigură conectivitatea de management, inclusiv pentru protocoale bazate pe IP.

... afișează tot conținutul

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.

... afișează tot conținutul

Operatorii economici, participanți la procedura respectivă, vor depune garanția pentru ofertă și garanția de bună execuție în conformitate cu cerințele stipulate în documentația de atribuire publicată pe platforma electronică SIA RSAP (MTender).

... afișează tot conținutul

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.

... afișează tot conținutul

Operatorii economici care nu îndeplinesc cerințele/criteriile obligatorii de calificare stabilite în documentația de atribuire(anunțul de participare – p. 17) vor fi descalificați și nu se va accepta participarea acestora la evaluarea tehnică și financiară.
Cerințe obligatorii conform Anunțului de participare:
1. Cerința nr. 8 - Service Centru local autorizat:
o Deținerea de Service Centru local autorizat de producător SAU
o Contract cu Service Centru local autorizat
o Se justifică prin Document confirmativ de la producător obligatoriu
2. Cerința nr. 18 - Personal certificat localizat:
o Minim 2 specialiști certificați de producător
o Localizați obligatoriu pe teritoriul Republicii Moldova
o Angajați proprii ai ofertantului
o Certificări valabile pentru marca/tipul/modelul ofertat
Justificare tehnică și legală privind imposibilitatea de participare directă a unui operator economic interesat nerezident:
1. Imposibilitate practică de respectare SLA:
o Timp rezolvare incidente majore: maxim 4 ore(”anexa nr. 2 la anunțul de participare.signed” – p. 2 Niveluri de serviciu(SLA))
o Intervenții hardware exclusiv on-site = la sediul ASP (”anexa nr. 2 la anunțul de participare.signed” - punctele 1.1.1, 3.1, 3.2, 3.2.1, 3.2.2)
o Fizic imposibil de realizat de către un Furnizor nerezident din străinătate
2. Cadru legal național obligatoriu aplicabil măsurilor de securitate:
o Legea nr. 48/2023 privind securitatea cibernetică
o HG nr. 562/2025 cu privire la modul de realizare a obligațiilor de asigurare a securității cibernetice de către furnizorii de servicii în sectoarele critice
o ASP prin prisma normelor legale este identificat ca prestator de servicii esențiale cu cerințe stricte de securitate
3. Operațiuni vamale continue în responsabilitatea exclusivă a Furnizorului:
o Livrare inițială echipamente
o Piese de schimb pe 5 ani – necesită ca compania Furnizor să fie înregistrată local pentru achitarea drepturilor vamale de import/export/re-export/re-import(după caz)
o Aceste operațiuni fiind imposibil de asigurat de Furnizor nerezident neînregistrat la Serviciul Vamal al Republicii Moldova
4. Securitate și acces infrastructură critică:
o Verificări securitate pentru acces fizic (”anexa nr. 2 la anunțul de participare.signed” – p. 6 Securitate și confidențialitate, în speță p.6.1 și 6.1.1., 6.2, 6.2.1)
o Responsabilitate juridică locală
o Conformare cu reglementările naționale
În concluzie, cerințele privind prezența locală sunt absolut obiective și justificate de:
• Natura serviciilor (deservire hardware on-site – la sediul ASP)
• Timpii de intervenție impuși (4 ore pentru cazuri de garanție cu impact major - SLA p.2.1)
• Obligațiile legale naționale (securitate cibernetică, operațiuni vamale)
• Responsabilitatea direct a Furnizorului față de infrastructura critică națională ca parte contractuală pe o durată de 5 ani(60 luni integral)
Aceste cerințe nicidecum nu constituie discriminare sau constrângere, ci reflectă aplicarea criteriilor de eligibilitate proporționale cu obiectul și natura contractului de achiziție și cerințele legale aplicabile.
Operatorii economici nerezidenți interesați, își pot asigura eligibilitatea la cerințele stabilite prin asociere sau alte forme juridice de colaborare pentru corespunderea la cerințele stabilite în documentația de atribuire, cu prezentarea documentală a acestor relaționări cu terțe corespunzător.
Ofertanții trebuie să manifeste diligența necesară în studierea completă a documentației, unde cerințele sunt clar și explicit stabilite.

... afișează tot conținutul

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

... afișează tot conținutul

Evaluarea tehnică a soluțiilor de stocare se va realiza strict în baza cerințelor tehnice specificate în documentația de achiziție. Cerințele privind snapshot-uri sunt definite la Cap. 12, iar cele privind securitatea la Cap. 13.
Specificațiile tehnice nu includ cerințe privind integrarea nativă cu soluții de backup enterprise sau mecanisme specifice anti-ransomware (snapshot-uri imutabile, WORM/retention lock). Aceste funcționalități sunt în afara scopului obiectului de achiziție și nu constituie criterii de evaluare sau eligibilitate.
Ofertanții pot prezenta astfel de capabilități ca valoare adăugată, fără impact asupra evaluării conformității tehnice.

... afișează tot conținutul

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.

... afișează tot conținutul

Cerințele de calificare, inclusiv certificările solicitate, sunt stabilite în documentația de achiziție – anunțul de participare. ISO/IEC 20000-1 nu este inclus ca cerință obligatorie. Capacitatea ofertantului de a respecta nivelurile SLA va fi evaluată pe baza documentelor de calificare solicitate și a propunerii tehnice prezentate suplinită de declarația ofertantului/furnizorului privind îndeplinirea cuprinzătoare a cerințelor stabilite în anexa nr.2.

... afișează tot conținutul

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.

... afișează tot conținutul

Cerințele sunt clar și explicit stabilite în documentația de achiziție. Conform clarificărilor anterioare, SSD QLC nu este acceptat.
Cerința 4.2 specifică „Enterprise SSD with TLC/eTLC technology or equivalent". Evaluarea se realizează pe baza tehnologiei celulei și a certificării enterprise de către producător. Prin „equivalent" se înțeleg tehnologii cu caracteristici similare sau superioare TLC/eTLC în termeni de durabilitate și fiabilitate.
Nu se stabilesc valori minime explicite pentru DWPD/TBW, însă soluția propusă trebuie să îndeplinească cerințele de performanță (Cap. 8) și disponibilitate (Cap. 2) pe întreaga perioadă de garanție și suport.

... afișează tot conținutul

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.

... afișează tot conținutul

Se confirmă. Capacitatea minimă utilizabilă de 200 TB reprezintă spațiul net efectiv disponibil, calculat:
• După aplicarea mecanismelor de protecție (RAID 6 sau echivalent);
• Cu toleranță la defectarea simultană a minimum 2 unități de stocare;
• Fără a lua în calcul funcțiile de reducere a datelor (deduplicare, compresie, thin provisioning).
Se acceptă scheme de protecție de tip RAID distribuit/erasure coding, cu condiția asigurării unui nivel de reziliență cel puțin echivalent cu RAID 6.

... afișează tot conținutul

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ță.

... afișează tot conținutul

Se confirmă. Cerința 7.1 specifică „Minimum cache per controller: min. 256 GB". Aceasta înseamnă minimum 256 GB memorie cache pentru fiecare controller fizic, rezultând minimum 512 GB cache total pentru un sistem cu două controllere.

... afișează tot conținutul

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.

... afișează tot conținutul

Se confirmă. Cerința 7.2 specifică „Mirroring or battery backup in case of power loss or controller failure". Evaluarea se realizează pe baza funcționalității și nivelului de protecție oferit, nu a tehnologiei specifice de implementare.
Sunt acceptate soluții bazate pe supercondensatori și memorie non-volatilă (flash-backed cache), cu condiția asigurării:
• Păstrării integrale a datelor din write cache în caz de pană de curent;
• Restaurării automate și sigure a cache-ului la repornire;
Certificării de către producător pentru uz enterprise cu prezentarea justificării documentale a acesteia.

... afișează tot conținutul

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.

... afișează tot conținutul

Cerința 8.1 specifică „Minimum IOPS with inline data reduction: 300,000 IOPS". Performanța trebuie demonstrată conform cerințelor 8.2 și 8.4:
• Workload: 70% read / 30% write, bloc 16KB;
• Cu funcțiile de deduplicare și compresie active (inline data reduction);
• Raport de performanță conform cerințelor 8.4.
Metodologia de testare și tipul datelor utilizate sunt la latitudinea ofertantului, cu condiția prezentării unui raport valid conform cerinței 8.4.

... afișează tot conținutul

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.

... afișează tot conținutul

Conform clarificărilor anterioare, cerințele 10.1 și 10.2 implică o arhitectură de tip metro-storage/stretched cluster, cu:
• Acces simultan activ la date din ambele locații;
• Continuitate automată în cazul indisponibilității unui site;
• Zero RPO.
O implementare de replicare sincronă clasică cu failover manual nu îndeplinește cerința de configurație „Active-Active".

... afișează tot conținutul

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.

... afișează tot conținutul

Cerința 11.1 specifică deduplicare inline „Block and volume level". Aceasta se referă la nivelul la care operează algoritmul de deduplicare, nu la scopul aplicării.
Se acceptă atât deduplicare globală (la nivel de pool), cât și deduplicare per volum, cu condiția îndeplinirii cerințelor de performanță și disponibilitate. Granularitatea implementării rămâne la latitudinea ofertantului.

... afișează tot conținutul

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.

... afișează tot conținutul

Se confirmă. Conform cerinței 11.3 „Unrestricted operation – No impact on other features", funcțiile de deduplicare și compresie trebuie să poată opera simultan cu toate celelalte funcționalități obligatorii (replicare, snapshots, criptare, multipathing), fără restricții sau dezactivări forțate.

... afișează tot conținutul