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

27 фев 2025, 09:22

În secțiunea privind verificarea performanței, se solicită furnizarea de rezultate detaliate ale benchmark-urilor pentru dimensiuni specifice de blocuri (16KB, 32KB, 64KB) folosind instrumente standardizate (IOmeter, FIO). În același timp, în secțiunea privind monitorizarea și optimizarea, se cere ca sistemul să includă instrumente pentru monitorizarea și optimizarea dinamică a performanței în timp real.

Vă rugăm să clarificați următoarele aspecte: Cum se vor corela rezultatele statice ale benchmark-urilor cu capacitățile de monitorizare și optimizare dinamică în timp real? Este necesar ca rezultatele benchmark-urilor să fie obținute în condiții similare cu cele care vor fi monitorizate și optimizate în timp real? Ce nivel de granularitate este așteptat pentru datele furnizate de instrumentele de monitorizare dinamică, în comparație cu rezultatele detaliate ale benchmark-urilor? Cum se va evalua conformitatea cu cerințele de performanță în timpul funcționării reale, având în vedere atât rezultatele statice ale benchmark-urilor, cât și datele dinamice de monitorizare? Aceste clarificări sunt esențiale pentru a ne asigura că ofertele noastre sunt conforme cu cerințele dumneavoastră și pentru a evita interpretări eronate."

27 фев 2025, 09:28

"În specificațiile tehnice pentru Lotul nr. 3, se solicită utilizarea de 'Enterprise-grade SAS SSDs' și se menționează explicit excluderea soluțiilor NVMe. Cu toate acestea, în secțiunea referitoare la toleranța la defecțiuni, se menționează că sistemul trebuie să suporte defecțiuni simultane ale dispozitivelor de stocare, inclusiv 'drives, NVMe, or flash modules'.

Vă rugăm să clarificați următoarele aspecte: Este permisă includerea soluțiilor NVMe în ofertele pentru Lotul nr. 3, având în vedere contradicția dintre cerința specifică pentru SAS SSD și menționarea NVMe în contextul toleranței la defecțiuni? Dacă soluțiile NVMe sunt permise, vă rugăm să confirmați dacă cerințele de performanță și fiabilitate specificate pentru SAS SSD-uri se aplică și la soluțiile NVMe propuse. Dacă soluțiile NVMe nu sunt permise, vă rugăm să explicați de ce sunt menționate în contextul toleranței la defecțiuni și cum se va asigura conformitatea cu această cerință folosind exclusiv SAS SSD-uri. Clarificarea acestor aspecte este crucială pentru a asigura o ofertare corectă și conformă cu cerințele dumneavoastră."

27 фев 2025, 09:39

Software și licențiere „Toate licențele necesare trebuie să fie incluse pe o bază perpetuă”

Vă rugăm să clarificați următoarele aspecte: Soluțiile moderne (ex. VMware) oferă modele de licențiere bazate pe subscripție, prin urmarea aceasta cerinta restrictiva crează premize artificiale de descalificare a soluțiilor ce oferă solutții bazate pe subscripție. O solutie corecta ar fi acceptare modele flexibile de licențiere cu reformulare: „Licențiere perpetuă sau subscripție pe termen lung (min. 5 ani)", prin umrare vă rugăm să efectuați modificarile necesare in cazul in care se acccepta sau să argumntați cum anume aceasta cerintă afectează cheltuirea eficientă a banilor publici.

27 фев 2025, 13:58

Justificarea utilizării SAS în locul NVMe – tehnologie depășită pentru sisteme de stocare enterprise moderne

Documentația specifică utilizarea exclusivă a unităților de stocare bazate pe interfața SAS (Serial Attached SCSI), în ciuda faptului că această tehnologie este considerată depășită în comparație cu standardul NVMe (Non-Volatile Memory Express). SAS are un număr semnificativ mai mare de limitări tehnice față de NVMe, inclusiv latență mai mare, rată de transfer inferioară și un număr semnificativ mai mic de cozi de comandă, ceea ce duce la performanță mai slabă în aplicații cu IOPS ridicat. Având în vedere că NVMe oferă multiple avantaje tehnice, inclusiv o scalabilitate superioară, latență redusă și performanță mult mai mare, solicităm modificarea cerințelor tehnice pentru a schimba tehnologia SAS pe NVMe.

27 фев 2025, 14:02

Justificarea utilizării exclusiv a tehnologiei TLC/eTLC pentru SSD-uri – risc major asupra continuității registrelor critice ale ASP

În specificațiile tehnice se solicită utilizarea exclusivă a SSD-urilor bazate pe tehnologia TLC (Triple-Level Cell) sau eTLC (Enhanced TLC), fără a permite alternative mai fiabile și performante precum MLC (Multi-Level Cell) sau SLC (Single-Level Cell). TLC este cunoscută ca fiind cea mai slabă tehnologie de stocare NAND în termeni de durabilitate și fiabilitate, având un număr semnificativ mai mic de cicluri de scriere/ștergere comparativ cu MLC și SLC. Pentru un sistem critic, precum cel destinat Agenției Servicii Publice (ASP), care gestionează registre fundamentale ale statului (evidența populației, cadastru, acte oficiale etc.), utilizarea SSD-urilor TLC reprezintă un risc inacceptabil pentru continuitatea operațională și integritatea datelor. În condiții de utilizare intensivă, SSD-urile bazate pe TLC se degradează rapid, necesitând înlocuire frecventă și expunând datele critice ale statului la riscul de pierdere sau corupere. În plus, având în vedere că acest sistem este achiziționat din fonduri publice, selecția unei tehnologii inferioare poate duce la prejudicii semnificative atât prin costuri de mentenanță ridicate (înlocuiri frecvente), cât și prin eventuale pierderi de date. Solicităm: 1. Excluderea TLC/eTLC ca tehnologie obligatorie și introducerea posibilității de utilizare a MLC sau SLC, care oferă o durată de viață de până la 30 de ori mai mare și fiabilitate superioară. 2. Modificarea cerinței astfel încât să se permită utilizarea SSD-urilor NVMe bazate pe MLC/SLC, asigurând astfel un sistem optim pentru aplicațiile critice guvernamentale. Nerespectarea acestor ajustări crește semnificativ riscul ca ASP să fie afectată de indisponibilități frecvente, generând pierderi economice și vulnerabilități critice pentru infrastructura digitală națională.

27 фев 2025, 14:07

Metodologia de testare a performanței de 300.000 IOPS – cerință neconformă cu bunele practici

Specificarea actuală impune demonstrarea performanței de **minimum 300.000 IOPS** prin **teste efectuate cu IOmeter** pe soluția livrată. Această metodologie nu este conformă cu **bunele practici** în achizițiile publice și **nu reflectă standardele industriei**, din următoarele motive: 1. **Factori externi care influențează testele la fața locului** – Performanța unui sistem de stocare nu este determinată doar de echipamentul în sine, ci și de infrastructura în care este integrat (rețea, servere, configurația HBA/NIC, mediul software etc.). Testele realizate după livrare **nu pot fi considerate obiective**, deoarece performanța poate fi influențată de factori care nu țin de soluția de stocare în sine. 2. **Lipsa unui standard de testare uniform** – IOmeter este un instrument de testare flexibil, dar **nu garantează un rezultat unitar** între diferite implementări. Fără specificarea exactă a parametrilor de testare (queue depth, block size, read/write mix, numărul de conexiuni FC/iSCSI etc.), rezultatele pot varia semnificativ, ceea ce face imposibilă o evaluare comparativă corectă. 3. **Practică neuzuală în achizițiile de soluții enterprise** – Standardul industriei este ca performanța să fie **garanția producătorului**, confirmată prin **teste interne de laborator** realizate în condiții controlate. Vendorii de soluții de stocare enterprise furnizează **rapoarte oficiale** ale testelor realizate pe echipamente identice, validate de echipe de inginerie, ceea ce reprezintă **o metodologie mult mai fiabilă și predictibilă**. Solicităm modificarea cerinței astfel încât **demonstrarea performanței să fie garantată de vendor**, prin: - Furnizarea **rapoartelor interne oficiale** ale producătorului care certifică atingerea valorii minime de 300.000 IOPS în condiții similare de utilizare. - Confirmarea și asumarea acestei performanțe printr-un **angajament scris** al producătorului privind respectarea indicatorilor de performanță specificați. Această abordare asigură transparență și corectitudine în evaluarea performanței soluției și elimină riscul unor teste subiective influențate de factori externi.

27 фев 2025, 14:10

Clarificare privind cerința de cache – definiția termenului „per node”

În specificațiile tehnice, cerința referitoare la memoria cache prevede: > *„If the storage system includes a cache mechanism, the system must provide a minimum of 512 GB of dedicated cache memory per node, ensuring high-speed data processing and optimal system performance.”* Termenul „**per node**” necesită clarificare, deoarece nu este specificat dacă această valoare se referă la: 1. **Cache per sistem de stocare (per storage system)** – Adică valoarea totală minimă de 512 GB se aplică întregii soluții de stocare livrate. 2. **Cache per cluster** – Se referă la întregul cluster de stocare (format din mai multe sisteme). Solicităm clarificarea exactă a acestei cerințe și, dacă termenul „per node” implică o configurație mai complexă (de ex. sistem multi-node sau cluster), ajustarea specificațiilor pentru a elimina ambiguitatea.

27 фев 2025, 14:15

Lot 3/4 Clarificare privind regimul Active-Active – nivelul de aplicare: controlere locale sau cluster distribuit?

În specificațiile tehnice, cerințele privind controlerele din sistemul de stocare menționează: „The storage system must include minimum one node equipped with a minimum of two fully redundant controllers configured in High Availability (HA) mode.” Urmat de precizarea: „Operate in an Active-Active configuration, ensuring balanced workload distribution and seamless failover capabilities without performance degradation.” Această formulare ridică o ambiguitate majoră, întrucât nu este clar dacă regimul Active-Active se aplică doar la nivel de controlere în cadrul fiecărui sistem de stocare sau dacă trebuie să fie implementat și la nivel de cluster între cele 4 sisteme achiziționate. Dacă cerința se referă la controlerele fiecărui sistem, atunci fiecare unitate trebuie să funcționeze cu două controlere în regim Active-Active, ceea ce este o caracteristică standard pentru soluțiile enterprise. Însă, dacă cerința implică funcționarea în cluster Active-Active între cele 4 sisteme de stocare achiziționate, acest lucru presupune: Implementarea unei soluții de tip Metro-Cluster Active-Active, ceea ce impune cerințe suplimentare de arhitectură și compatibilitate. Necesitatea unei licențe dedicate pentru Metro-Storage Active-Active, care să permită acces simultan la date în ambele locații fără întreruperi și cu replicare sincronă bidirecțională. Solicităm clarificarea următoarelor aspecte: Regimul Active-Active se aplică doar la nivelul controlerelor fiecărui sistem de stocare sau este necesar un cluster distribuit Active-Active între cele 4 sisteme achiziționate? În cazul în care se solicită cluster Active-Active între sisteme, trebuie inclusă și licența Metro-Storage Active-Active pentru gestionarea volumelor și sincronizarea în timp real? Această clarificare este critică, deoarece o implementare de tip Metro-Cluster necesită hardware, software și licențiere suplimentară, iar cerințele actuale nu precizează aceste aspecte esențiale.

27 фев 2025, 14:16

Lot 3/4 Clarificare privind termenul „Backups” în contextul deduplicării și compresiei

În specificațiile tehnice, secțiunea „Deduplication and compression requirements”, punctul 2, menționează: „Deduplication and compression features must operate seamlessly without introducing limitations or restrictions on simultaneous use of other critical functionalities, including but not limited to: Data replication, Thin provisioning, Backups, Volume cloning.” Termenul „Backups” necesită clarificare, întrucât nu este specificat dacă se referă la: Backup la nivel de storage array (snapshot-based backups) sau Backup external către o soluție separată de arhivare (de ex. Veeam, Commvault etc.) Solicităm clarificarea exactă a termenului „Backups” și a modului în care deduplicarea și compresia trebuie să interacționeze cu acest proces.

27 фев 2025, 14:18

Clarificare privind licențierea pentru deduplicare și compresie – acoperire pentru viitoarele extinderi?

În specificațiile tehnice, secțiunea **„Deduplication and compression requirements”**, punctul 4, menționează: > *„Fully licensed (if required by vendor provisions) and included in the offer, eliminating additional licensing costs for essential functionality.”* Nu este clar dacă această cerință se aplică **strict configurației ofertate** sau dacă trebuie să includă și o **licență scalabilă**, care să permită extinderea viitoare a capacității de stocare fără costuri suplimentare pentru deduplicare și compresie. Solicităm clarificarea: - Licența trebuie să acopere doar configurația actuală sau și **maximul de capacitate suportat de sistem** pentru viitoarele extinderi? - În cazul adăugării ulterioare de discuri, vor fi necesare licențe suplimentare sau soluția trebuie să permită extinderea doar prin achiziția de hardware (fără licențe adiționale)?

27 фев 2025, 14:20

Clarificare privind utilizarea exclusivă a interfețelor Fibre Channel (FC) – lipsa alternativelor pentru Metro Cluste

În specificațiile tehnice, secțiunea „NICs included per controller”, se menționează: „Min. x 1GE for management; Min. 2 x 32G FC SFP28 (850nm SFP+ SR MM module included) for data transfer; Min. 2 x 32G FC dedicated for replication (metro cluster).” Observăm că pentru replicare în Metro Cluster sunt specificate exclusiv interfețe FC, însă fiecare vendor are propria tehnologie de replicare, care poate utiliza și alternative precum Ethernet (iSCSI, RDMA, RoCE, InfiniBand etc.). Solicităm: Clarificarea motivului pentru care se impune doar FC pentru replicare, fără a permite tehnologii alternative ale vendorilor. Modificarea cerinței astfel încât să fie acceptate interfețe dedicate pentru replicare, indiferent de tehnologia utilizată, în conformitate cu specificațiile producătorului.

27 фев 2025, 14:21

Clarificare privind lipsa interfețelor necesare pentru protocolul solicitat

În specificațiile tehnice, secțiunea „Supported protocols” menționează suport pentru iSCSI, dar interfețele specificate pentru controlere sunt doar FC. Solicităm clarificarea dacă: Este o omisiune și trebuie incluse interfețe compatibile cu iSCSI. iSCSI este menționat ca protocol suportat, dar nu este necesar în configurația livrată. Dacă iSCSI trebuie utilizat, cerem modificarea cerințelor pentru a include interfețele necesare funcționării acestuia.

27 фев 2025, 14:23

Clarificare privind cerința de extindere a memoriei și capacității de stocare fără limitări hardware/software

În specificațiile tehnice, secțiunea „Termeni și condiții”, se menționează: „Extinderea memoriei (RAM) și a capacității de stocare nu trebuie să includă limitări hardware sau software.” Această cerință este vag formulată și poate fi interpretată în mai multe moduri. Solicităm clarificarea exactă a ceea ce se înțelege prin „fără limitări hardware sau software”.

28 фев 2025, 11:51

Justificarea necesității cerințelor pentru drive bays, RAID Controller și SSD SAS

Conform specificațiilor minime, fiecare server trebuie să includă: - Min. drive bays:Min. 8 bays 2.5 for data Support Hot-Swappable; - Storage installed: Min. 2 x min. 240Gb SSD SAS - RAID Controller: Support Pass-through mode; RAID 1,5,6,10,50,60; Cache min. 4GB; Având în vedere că în soluția proiectului aceste servere vor avea doar 2x SSD pentru OS/Hypervisor, solicităm clarificarea necesității următoarelor cerințe: 1. Necesitatea a 8 bays hot-swappable, deși sunt utilizate doar 2 SSD-uri pentru boot. 2. Obligativitatea utilizării SSD-urilor SAS, în condițiile în care soluții alternative, precum M.2 SATA/NVMe drives, 7mm SATA/NVMe HotSwap sau Boot Optimized Storage Solutions (BOSS), ar putea oferi aceeași fiabilitate la un cost mai redus. 3. Existența unui RAID Controller cu cache de 4GB și suport pentru RAID-5,6,10,50,60, ceea ce nu este justificat pentru o configurație de boot, unde RAID 1 ar fi suficient și mai eficient din punct de vedere al costurilor. Propunere de modificare: • Alternativă pentru boot storage: Acceptarea soluțiilor precum BOSS card, M.2 sau 7mm in RAID-1 care sunt utilizate de majoritatea vendorilor pentru boot (ex: Dell BOSS-S1, HPE NS204i-u). • Eliminarea obligativității RAID Controller-ului cu functional RAID- 5,6,10,50,60 si Cache 4GB, în cazul în care nu se utilizează HDD/SSD-uri pentru storage de date. • Reducerea numărului minim de drive bays, astfel încât să fie proporțional cu necesitățile soluției implementate. Prin aceste ajustări, costul total al soluției poate fi redus considerabil, fără impact asupra fiabilității și performanței necesare.