Database I/O bound
SQL Server, PostgreSQL, MySQL su PERC H730 con 1 GB cache e tutti i workload mid-day in code: salire a H755 con 4 GB cache e write-back con BBU spesso porta latency da decine di ms a singole cifre.
Il controller storage è il bottleneck più sottostimato dei server. Passare da un MegaRAID di 8 anni fa con cache 512 MB a un PERC H755 o Smart Array P816i-a con 4 GB di cache write-back può raddoppiare il throughput sequenziale e quadruplicare gli IOPS random. Su workload virtualizzati la differenza è quasi sempre tangibile.
SQL Server, PostgreSQL, MySQL su PERC H730 con 1 GB cache e tutti i workload mid-day in code: salire a H755 con 4 GB cache e write-back con BBU spesso porta latency da decine di ms a singole cifre.
Esigenza di mantenere RAID hardware ma ottenere prestazioni NVMe per database e log. Soluzione: tri-mode controller (PERC H755N, Smart Array MR416i-p) con backplane compatibile.
Migrazione a software-defined storage richiede HBA passthrough. RAID controller esistente va sostituito con HBA puro (PERC HBA350, Smart Array E208i-a) per esporre i dischi singolarmente.
I controller enterprise integrati (PERC su Dell, Smart Array integrato su HPE, RAID 940 su Lenovo) sono spesso "vendor-locked": il PERC H755 fisicamente entra in molti server ma è ufficialmente supportato solo su modelli specifici. Su Supermicro c'è più libertà (Broadcom MegaRAID standard). Verifichiamo HCL prima.
Controller nuovo può richiedere cablaggio SAS diverso (SAS3 vs SAS4, mini-SAS HD vs SlimSAS), backplane con capacità tri-mode (per NVMe). Su upgrade tra famiglie spesso serve cambiare anche i cavi e talvolta il backplane.
I controller write-back operano con BBU (rechargeable battery) o supercap (capacitor). BBU ha vita media 3-5 anni, supercap molto più lunga. Su controller esistente verifichiamo età della BBU: se vicina al fine vita, includiamo la sostituzione nell'intervento.
Controller, BIOS server, sistema operativo, driver: vanno allineati. Su Dell la matrice è gestita da Lifecycle Controller; su HPE da SPP (Service Pack for ProLiant). Aggiornamento prima dello swap fisico è obbligatorio.
Cambio di controller della stessa famiglia (es. LSI a LSI): import foreign config sul nuovo controller, l'array viene riconosciuto e portato online. Famiglie diverse (LSI a HPE Smart Array): metadati on-disk diversi, serve ricreare l'array — backup obbligatorio prima.
Su PERC alcune feature avanzate (RAID 6, cache write-back, FastPath) richiedono license unlock. Su HPE Smart Array idem (license SPP). Verifichiamo che il controller target abbia o supporti l'unlock delle feature richieste.
Snapshot stato controller (RAID level, ordine dischi, strip size, cache policy, write policy, eventuali license attive). Backup completo dei dati o snapshot consistent. Niente intervento senza backup verificato.
Aggiornamento BIOS server, prep firmware controller target, eventuale license unlock pre-configurato. Verifica cablaggio SAS necessario (talvolta da sostituire), eventuale upgrade backplane per tri-mode.
Server spento, rimozione controller esistente, installazione nuovo, ricablaggio se necessario, posizionamento BBU/supercap, ricollegamento.
Boot in setup controller, verifica dischi rilevati, import foreign config (se famiglia compatibile). Cache settings ripristinati conformi alla configurazione iniziale. Avvio sistema operativo, verifica array online.
Benchmark I/O pre/post (fio o iometer), verifica nessun errore SMART sui dischi, baseline performance scritta. Validazione applicativa con il cliente prima della consegna.
Cliente PMI mid-market provincia di Monza, server PowerEdge R740 con SQL Server Standard, database produttivo gestionale 1.2 TB, traffico transazionale costante. Controller PERC H730 con 1 GB cache write-back, 8 dischi SAS 10K 1.8 TB in RAID 10. Picchi latenza in scrittura nei momenti di batch (chiusure giornaliere, fatturazioni di fine mese): da 5 ms in idle a 60-90 ms durante batch.
Diagnosi: cache controller saturata in scrittura. Storage fisico (SAS 10K) può fare meglio se il controller non strozza. Soluzione: upgrade a PERC H755 con 8 GB cache, mantenendo gli stessi dischi e lo stesso RAID 10. Compatibilità famiglia LSI-based identica: foreign config import diretto.
Esecuzione: backup completo del database SQL (full + log) prima dell'intervento. Finestra notturna di 3 ore. Spegnimento server, sostituzione controller, aggiornamento firmware PERC, boot, import foreign config (5 minuti), avvio sistema, verifica integrità SQL (DBCC CHECKDB), test batch sintetico, ritorno in produzione.
Risultato: latenza batch sotto i 15 ms, throughput sequenziale write +120%. Nessuna perdita dati. Cliente continua a operare sugli stessi dischi.
Tre scenari: 1) Workload virtualizzato pesante random I/O con controller vecchio cache piccola — beneficio tangibile passando a 2-4 GB cache write-back. 2) Necessità di NVMe come destinazione protetta (RAID): vecchio controller non supporta NVMe via tri-mode, nuovo sì. 3) Migrazione da HBA passthrough a controller con BBU per workload database che richiedono garanzia di write durability anche su power loss.
Sì, in molti casi. La procedura standard è: snapshot della configurazione attuale (ordine dischi, RAID level, strip size, write policy), sostituzione fisica del controller con modello compatibile, import foreign config dal nuovo controller. Se i modelli sono famiglia simile (es. PERC H730 → H755) la procedura è quasi seamless. Tra famiglie diverse (LSI MegaRAID a HPE Smart Array) i metadati on-disk non sono compatibili: serve backup + ricreazione array.
HBA (Host Bus Adapter) espone i dischi singolarmente al sistema operativo: ideale per soluzioni software-defined (Storage Spaces Direct, vSAN, Ceph, ZFS) che fanno protezione e cache lato OS. RAID controller fa protezione e cache in hardware, presentando volumi virtuali al SO: ideale per server tradizionali con OS che non vuole gestire la complessità. La scelta dipende dallo storage stack del cliente.
Permette al controller di firmare write come 'completata' una volta scritta in cache, anche se il disco è ancora lento — questo dà boost enorme alle prestazioni write. Se manca la corrente, BBU (batteria) o supercap (condensatore) tengono la cache viva fino a flush sui dischi al ritorno della corrente. Senza BBU/supercap il controller passa a write-through, perdendo molto. Sostituire BBU/supercap morto è una manutenzione ricorrente che gestiamo.
Queue depth alta (256+ per porta) permette al controller di tenere in coda molti comandi I/O senza saturarsi. Su workload virtualizzazione moderna con decine di VM che generano migliaia di IOPS aggregati, controller con queue depth basso (32-64) crea code, latenza, throughput plafonato. I controller enterprise moderni (PERC H755, Smart Array P816i-a, Broadcom 9560) sono progettati per queste densità.
Sì, su controller tri-mode di ultima generazione (PERC H755N/H965i, Smart Array MR416i-p, Broadcom 9560). Il tri-mode permette di mescolare SAS, SATA e NVMe sullo stesso controller. Le prestazioni NVMe via tri-mode non eguagliano NVMe diretto su PCIe, ma offrono protezione RAID/cache mantenendo IOPS molto alti — sweet spot per molti workload mid-market.
Inviami brand, modello (Service Tag / Serial / part number motherboard), workload obiettivo. Entro un giorno lavorativo ti rispondo con la fattibilità tecnica, i vincoli che ho visto e una stima onesta.