Achiziție - Soluție de stocare a datelor de tip enterprise
Achiziție Serviciul Tehnologia Informaţiei şi Securitate Cibernetică
Informație generală
Soluție de stocare a datelor de tip enterprise
Surse de finanțare
suma planificată 27,500,000.00 MDL
Detalii achiziție
| Valoare | CPV | Titlu achiziției | Cantitate | Livrare |
|---|---|---|---|---|
| 27,500,000.00 MDL | 48800000-6 | Soluție de stocare a datelor de tip enterprise | 1 Bucata | Lot anulat |
Documente
Persoană de contact
Clarificări
Solicităm clarificare privind cerința de RAID cu paritate triplă: Această cerință se referă la o tehnologie specifică (de exemplu, RAID-TP de la Huawei) sau acceptați tehnologii echivalente cu un nivel similar de redundanță și protecție, cum ar fi Dynamic Disk Pool (DDP), RAID-DP, RAID-3D, Distributed RAID 6 sau alte arhitecturi proprietare care oferă protecție echivalentă sau superioară împotriva pierderii multiple a discurilor?
Cerința ca beneficiarul să aibă acces independent la documentație, licențe, subscripții «inclusiv după expirarea perioadei de 5 ani» — solicităm clarificare: Această cerință include accesul perpetual la actualizări software după 5 ani, sau doar accesul la versiunile existente la momentul expirării? Această distincție este critică pentru calcularea TCO-ului.
Având în vedere complexitatea soluției și impactul deciziei asupra continuității serviciilor critice STISC, solicităm prelungirea termenului de depunere a ofertelor cu minim 14 zile calendaristice, pentru a permite tuturor ofertanților potențiali să obțină ofertele de la producători, să efectueze validări tehnice și să pregătească documentația completă conform tuturor cerințelor (C1-C3).
Având în vedere că soluțiile moderne enterprise utilizează discuri NVMe cu capacități variate (3.84TB, 7.68TB, 15.36TB, 30.72TB), solicităm clarificare: Capacitatea minimă a discului de 7.68TB este o cerință strict obligatorie sau acceptați configurații echivalente cu discuri de capacitate mai mare sau mai mică, atâta timp cât volumul total de 60TB NVMe RAW este respectat? Limitarea la o capacitate specifică a discului poate restricționa nejustificat concurența.
Cerința de 1.100.000 IOPS la latență de 2ms este formulată pentru întregul sistem propus. Solicităm clarificare: Aceste valori trebuie atinse în configurația minimă livrată (60TB RAW, 1 nod cu 2 controllere) sau în configurația maximă scalabilă? În plus, ce metodologie standard de testare va fi acceptată: SPC-1, SNIA SSS PTS, sau rapoarte interne ale producătorului? Diferiți producători raportează IOPS-uri prin metodologii diferite.
Cerința de 1TB Cache per Node se referă strict la DRAM cache, sau include și SSD cache, NVDIMM, sau alte arhitecturi moderne de tiering? Soluțiile moderne folosesc adesea o combinație de DRAM (mai mic, ex. 256-512GB) și NVMe/SCM ca acceleratoare, oferind performanță echivalentă sau superioară unui DRAM cache de 1TB. Acceptați configurații echivalente funcțional?
Cerința de suport simultan pentru protocoale FC, iSCSI, NVMe over TCP, NVMe over FC, NFS, S3, CIFS/SMB pe același sistem este o cerință strict obligatorie? Soluțiile modulare (Dell PowerStore, Pure FlashArray, HPE Alletra) oferă protocoale specializate la nivel de cluster sau prin gateway-uri dedicate, ceea ce reprezintă o arhitectură industrială preferată pentru izolare și securitate. Acceptați soluții care îndeplinesc cerințele funcționale prin nodes/gateways dedicate?
Confirmați vă rog dacă cerința de NFS Kerberos Authentication este obligatorie sau opțională. În cazul în care soluția propusă suportă alte mecanisme echivalente sau superioare de autentificare (NTLM, LDAP/AD direct, OAuth2, SAML, Active Directory native integration), acestea sunt acceptate?
Cerința de 500 unități logice izolate (multi-tenancy) este formulată ca minim. Solicităm clarificare: Beneficiarul preconizează utilizarea efectivă a acestui număr de tenants, sau este o cerință de scalabilitate teoretică? În cazul în care numărul real de tenants utilizați va fi semnificativ mai mic (ex. 50-100), considerați acceptabilă o soluție care suportă un număr mai mic, dar suficient pentru necesitățile reale operaționale?
Solicităm clarificări privind modulele QSFP: pentru partea Storage-site (C2.42) sunt acceptate module originale ale producătorului storage-ului, dar pentru Switch-site (C2.43) se cer module compatibile Cisco. De ce această asimetrie? Acceptați module compatibile pe ambele părți (de la producători terți acreditați), care funcționează identic la fracțiune de cost? În plus, ce model specific de switch Cisco este utilizat la beneficiar (Nexus 9000, MDS 9700, alt), pentru a asigura compatibilitatea fără ambiguități?
Cerința de integrare cu Nakivo backup și suport oficial «de la ambii vendori» — vă rugăm să confirmați dacă lista oficială Nakivo Storage Integration Matrix (publicată pe site-ul nakivo.com) este acceptată ca dovadă suficientă, sau este necesară confirmarea bilaterală scrisă separată? Acest aspect afectează semnificativ termenul de pregătire a documentației.
Pentru garanția hardware de 5 ani și subscripțiile de 5 ani — vă rugăm să clarificați: Este acceptabil ca garanția să fie furnizată prin SLA-ul ofertantului certificat ca partener autorizat al producătorului (cu confirmare scrisă de la producător privind acoperirea), sau este obligatoriu un contract direct între STISC și producător? Această clarificare este importantă pentru ofertanții care lucrează prin distribuitori regionali.