Bases de datos I/O bound
SQL Server, PostgreSQL, MySQL sobre PERC H730 con 1 GB de caché y todas las cargas de media jornada encoladas: subir a H755 con 4 GB de caché y write-back con BBU suele bajar la latencia de decenas de ms a un solo dígito.
La controladora storage es el cuello de botella más infravalorado de un servidor. Pasar de un MegaRAID de hace 8 años con 512 MB de caché a un PERC H755 o a una Smart Array P816i-a con 4 GB de caché write-back puede duplicar el throughput secuencial y cuadruplicar las IOPS aleatorias. En cargas virtualizadas la diferencia es casi siempre tangible.
SQL Server, PostgreSQL, MySQL sobre PERC H730 con 1 GB de caché y todas las cargas de media jornada encoladas: subir a H755 con 4 GB de caché y write-back con BBU suele bajar la latencia de decenas de ms a un solo dígito.
Necesidad de mantener RAID hardware pero obtener rendimiento NVMe para bases de datos y logs. Solución: controladora tri-mode (PERC H755N, Smart Array MR416i-p) con backplane compatible.
Migrar a software-defined storage exige HBA passthrough. La controladora RAID existente debe sustituirse por un HBA puro (PERC HBA350, Smart Array E208i-a) para exponer los discos de forma individual.
Las controladoras enterprise integradas (PERC en Dell, Smart Array integrada en HPE, RAID 940 en Lenovo) suelen estar "vendor-locked": la PERC H755 encaja físicamente en muchos servidores, pero solo está soportada oficialmente en modelos concretos. En Supermicro hay más libertad (Broadcom MegaRAID estándar). Verificamos la HCL antes.
Una controladora nueva puede exigir un cableado SAS distinto (SAS3 vs SAS4, mini-SAS HD vs SlimSAS) y un backplane con capacidad tri-mode (para NVMe). En upgrades entre familias suele ser necesario cambiar también los cables y, a veces, el backplane.
Las controladoras write-back operan con BBU (rechargeable battery) o supercap (capacitor). La BBU tiene una vida media de 3-5 años; el supercap, mucho más larga. En la controladora existente comprobamos la antigüedad de la BBU: si está cerca del fin de vida, incluimos la sustitución en la intervención.
Controladora, BIOS del servidor, sistema operativo y drivers deben quedar alineados. En Dell la matriz la gestiona el Lifecycle Controller; en HPE, el SPP (Service Pack for ProLiant). Actualizar antes del swap físico es obligatorio.
Cambio de controladora dentro de la misma familia (p. ej. LSI a LSI): import del foreign config en la nueva controladora, el array se reconoce y vuelve online. Entre familias distintas (LSI a HPE Smart Array) los metadatos on-disk difieren y hay que recrear el array: backup obligatorio antes.
En PERC algunas funciones avanzadas (RAID 6, caché write-back, FastPath) requieren license unlock. En HPE Smart Array ocurre lo mismo (license SPP). Verificamos que la controladora de destino tenga o admita el unlock de las funciones necesarias.
Snapshot del estado de la controladora (RAID level, orden de los discos, strip size, cache policy, write policy, licencias activas si las hay). Backup completo de los datos o snapshot consistente. Sin backup verificado no se interviene.
Actualización del BIOS del servidor, preparación del firmware de la controladora de destino y license unlock preconfigurado si procede. Verificación del cableado SAS necesario (a veces hay que sustituirlo) y posible upgrade del backplane para tri-mode.
Servidor apagado, retirada de la controladora existente, instalación de la nueva, recableado si es necesario, colocación de la BBU/supercap y reconexión.
Boot en el setup de la controladora, verificación de los discos detectados, import del foreign config (si la familia es compatible). Cache settings restaurados conforme a la configuración inicial. Arranque del sistema operativo y verificación del array online.
Benchmark de I/O pre/post (fio o iometer), verificación de que no hay errores SMART en los discos y baseline de rendimiento por escrito. Validación aplicativa con el cliente antes de la entrega.
Cliente pyme mid-market de la provincia de Monza, servidor PowerEdge R740 con SQL Server Standard, base de datos de gestión en producción de 1,2 TB y tráfico transaccional constante. Controladora PERC H730 con 1 GB de caché write-back y 8 discos SAS 10K de 1,8 TB en RAID 10. Picos de latencia en escritura durante los batch (cierres diarios, facturación de fin de mes): de 5 ms en idle a 60-90 ms durante el batch.
Diagnóstico: caché de la controladora saturada en escritura. El storage físico (SAS 10K) puede rendir más si la controladora no lo estrangula. Solución: upgrade a PERC H755 con 8 GB de caché, manteniendo los mismos discos y el mismo RAID 10. Compatibilidad de familia LSI-based idéntica: import directo del foreign config.
Ejecución: backup completo de la base de datos SQL (full + log) antes de la intervención. Ventana nocturna de 3 horas. Apagado del servidor, sustitución de la controladora, actualización del firmware PERC, boot, import del foreign config (5 minutos), arranque del sistema, verificación de integridad SQL (DBCC CHECKDB), test de batch sintético y vuelta a producción.
Resultado: latencia de batch por debajo de 15 ms, throughput secuencial de escritura +120%. Sin pérdida de datos. El cliente sigue operando sobre los mismos discos.
Tres escenarios: 1) Carga virtualizada intensa de I/O aleatorio con una controladora antigua de caché pequeña: el beneficio es tangible al pasar a 2-4 GB de caché write-back. 2) Necesidad de NVMe como destino protegido (RAID): la controladora antigua no soporta NVMe vía tri-mode y la nueva sí. 3) Migración de HBA passthrough a controladora con BBU para cargas de base de datos que exigen garantía de write durability incluso ante un power loss.
Sí, en muchos casos. El procedimiento estándar es: snapshot de la configuración actual (orden de los discos, RAID level, strip size, write policy), sustitución física de la controladora por un modelo compatible e import del foreign config desde la nueva controladora. Si los modelos son de familia similar (p. ej. PERC H730 → H755) el proceso es casi seamless. Entre familias distintas (LSI MegaRAID a HPE Smart Array) los metadatos on-disk no son compatibles: hace falta backup + recreación del array.
El HBA (Host Bus Adapter) expone los discos de forma individual al sistema operativo: ideal para soluciones software-defined (Storage Spaces Direct, vSAN, Ceph, ZFS) que gestionan protección y caché en el lado del OS. La controladora RAID hace protección y caché por hardware y presenta volúmenes virtuales al SO: ideal para servidores tradicionales cuyo OS no quiere gestionar esa complejidad. La elección depende del storage stack del cliente.
Permite a la controladora dar una escritura por 'completada' en cuanto entra en caché, aunque el disco siga siendo lento: eso da un impulso enorme al rendimiento de escritura. Si se corta la corriente, la BBU (batería) o el supercap (condensador) mantienen viva la caché hasta hacer flush a los discos cuando vuelve la alimentación. Sin BBU/supercap la controladora pasa a write-through y pierde mucho. Sustituir una BBU/supercap agotada es un mantenimiento recurrente que gestionamos.
Una queue depth alta (256+ por puerto) permite a la controladora mantener en cola muchos comandos de I/O sin saturarse. En cargas de virtualización modernas con decenas de VM que generan miles de IOPS agregadas, una controladora con queue depth baja (32-64) genera colas, latencia y throughput con techo. Las controladoras enterprise actuales (PERC H755, Smart Array P816i-a, Broadcom 9560) están diseñadas para esas densidades.
Sí, en controladoras tri-mode de última generación (PERC H755N/H965i, Smart Array MR416i-p, Broadcom 9560). El tri-mode permite mezclar SAS, SATA y NVMe en la misma controladora. El rendimiento NVMe vía tri-mode no iguala al NVMe directo sobre PCIe, pero ofrece protección RAID/caché manteniendo IOPS muy altas: un sweet spot para muchas cargas mid-market.
Envíame marca, modelo (Service Tag / Serial / part number de la motherboard) y la carga objetivo. En un día laborable te respondo con la viabilidad técnica, las restricciones que he detectado y una estimación honesta.