Controlador dual, caché y BBU en sistemas de almacenamiento: por qué son necesarios y cómo afectan a la tolerancia a fallos.

Un sistema de almacenamiento con dos controladoras, caché protegida y un módulo BBU o supercondensador en buen estado es más fiable que una cabina básica no porque tenga “más hardware”, sino porque dispone de rutas redundantes para acceder a los datos y de un mecanismo para proteger las operaciones de escritura. Para virtualización, bases de datos, ERP, almacenamiento de archivos y otros servicios críticos, conviene elegir un sistema de almacenamiento con al menos dos controladoras, pero también es imprescindible revisar toda la cadena, no solo la configuración física: controladoras, caché, módulo de protección de caché, firmware, puertos, multipathing y registros de errores.

El almacenamiento empresarial rara vez falla “de un solo golpe”. Más a menudo, el problema empieza en un componente concreto: una controladora, un puerto, un cable, una batería de caché, una fuente de alimentación, el firmware o un grupo de discos. Una buena arquitectura sirve para que un fallo de este tipo no detenga un sistema de negocio.

Por eso, al elegir un sistema de almacenamiento de datos, es importante mirar más allá de la capacidad y del número de discos. Dos cabinas con la misma capacidad pueden diferir mucho en su tolerancia real a fallos si una tiene dos controladoras, caché protegida y rutas verificadas hacia los servidores, mientras que la otra tiene una sola controladora y un estado de batería desconocido.

Our most popular storage systems

Qué hace una controladora de almacenamiento

La controladora es el módulo de gestión del sistema de almacenamiento. Recibe solicitudes de los servidores, trabaja con discos, grupos RAID o pools, gestiona volúmenes, caché, puertos externos y la lógica interna de la cabina.

Dicho de forma sencilla, en una cabina de almacenamiento completa, el servidor no “habla” directamente con cada disco. Se comunica con la controladora de almacenamiento, y esta decide cómo procesar la solicitud dentro de la cabina.

La controladora se encarga de varias tareas importantes:

• recibir comandos de lectura y escritura de los servidores;
• distribuir operaciones entre discos, SSD, grupos RAID o pools;
• gestionar volúmenes, snapshots, replicación y otras funciones de almacenamiento;
• atender la caché de lectura y escritura;
• trabajar con puertos de acceso, como Fibre Channel, iSCSI, SAS u otros;
• enviar datos a la interfaz de gestión;
• registrar errores en los logs de eventos;
• participar en actualizaciones de firmware y en la conmutación de carga durante fallos.

Por eso no conviene tratar una controladora como una simple tarjeta RAID. En una cabina empresarial realiza muchas más funciones y tiene un impacto mucho mayor en la disponibilidad de los datos.

Si solo hay una controladora, se convierte en un posible punto único de fallo. Los discos pueden estar sanos y las fuentes de alimentación pueden funcionar, pero si falla la única controladora, los servidores perderán el acceso a los volúmenes.

Una controladora o dos: cuál es la diferencia real

Una cabina de almacenamiento con una sola controladora puede ser una opción razonable para tareas no críticas. Por ejemplo, puede servir para un entorno de pruebas, un laboratorio, un archivo temporal o un nivel adicional de almacenamiento donde el tiempo de inactividad sea aceptable.

Las ventajas de este diseño son claras:

• menor coste;
• configuración más simple;
• menos componentes que mantener;
• configuración inicial más sencilla.

Pero las limitaciones también son importantes:

• un fallo de la controladora suele significar parada;
• una actualización de firmware puede requerir apagado;
• es más difícil sustituir una controladora sin afectar a los servicios;
• no es posible construir un diseño completo con rutas redundantes;
• algunas funciones de alta disponibilidad no están disponibles o están limitadas.

Una cabina con dos controladoras está diseñada de otra manera. Tiene dos módulos de gestión y, con la configuración correcta, la segunda controladora puede asumir parte de la carga o continuar funcionando si falla la primera.

Dos controladoras ofrecen varias ventajas:

• los servidores pueden conectarse a la cabina por rutas físicas diferentes;
• el fallo de una controladora no tiene por qué provocar la pérdida de acceso a los datos;
• algunas tareas de mantenimiento pueden realizarse sin apagar por completo la cabina;
• aumenta la resistencia frente al fallo de un puerto, cable, adaptador o switch;
• la caché de escritura puede espejarse entre controladoras.

Por ejemplo, en muchos sistemas de almacenamiento Dell EMC, la tolerancia a fallos se basa precisamente en dos controladoras, varios puertos y un diseño correcto de conexión a los servidores. Pero la frase dual controller por sí sola no garantiza la continuidad del servicio. Si un servidor está conectado con un solo cable a una sola controladora, la segunda controladora existe físicamente, pero la ruta hacia ella no se utiliza.

Dual controller no protege contra todo. No sustituye las copias de seguridad ni evita problemas como:

• eliminación de datos por parte de un usuario;
• corrupción del sistema de archivos;
• ransomware;
• error del administrador;
• actualización incorrecta de firmware;
• fallo de un grupo de discos más allá del nivel RAID tolerable;
• configuración incorrecta de rutas en el servidor.

Es más correcto ver las dos controladoras como la base de un diseño tolerante a fallos, no como una garantía lista para usar de ausencia de paradas.

Qué ocurre cuando falla una controladora

El escenario más claro es el fallo de una de las dos controladoras. Puede tratarse de una avería de hardware, un bloqueo, un fallo de firmware o un reinicio forzado durante el mantenimiento.

En un diseño correctamente configurado, el proceso se ve así:

1. Una controladora deja de atender operaciones.
2. La cabina transfiere sus recursos a la controladora restante.
3. Los servidores siguen viendo los volúmenes a través de otras rutas disponibles.
4. El multipathing en el lado del servidor selecciona una ruta operativa.
5. Las aplicaciones pueden notar una pausa o un aumento de latencia, pero no deberían perder por completo el acceso a los datos.

En la práctica, mucho depende del diseño de conexión. Si cada servidor tiene dos adaptadores, dos rutas independientes y una política correcta de selección de rutas, el fallo de una controladora normalmente no provoca una parada total. Pero si el servidor estaba conectado solo a la controladora que ha fallado, la segunda controladora no ayudará automáticamente: no existe una ruta física hacia ella.

Lo mismo ocurre con el mantenimiento. En cabinas de doble controladora, a menudo es posible sustituir o reiniciar las controladoras de una en una. Por ejemplo, en la documentación de Dell PowerVault ME5, el procedimiento de sustitución del módulo de controladora incluye comprobar el estado de la controladora, confirmar que está lista para retirarse y etiquetar los cables antes de desconectarlos. Es un buen ejemplo de por qué incluso el mantenimiento “en caliente” requiere disciplina y no debe hacerse al azar: Dell PowerVault ME5: sustitución de una controladora.

Antes de sustituir o actualizar una controladora, conviene comprobar:

• si los servidores ven todas las rutas hacia los volúmenes;
• si ya existen errores en la segunda controladora;
• si la caché está sincronizada;
• si las versiones de firmware coinciden;
• si hay advertencias de fuentes de alimentación, ventiladores o discos;
• si existe una copia de seguridad actualizada;
• si se ha elegido una ventana de baja carga.

Aunque el proveedor permita realizar el mantenimiento sin un apagado completo, sigue siendo razonable planificar una ventana de trabajo. Una arquitectura tolerante a fallos reduce el riesgo de parada, pero no convierte cualquier operación en segura por defecto.

Pérdida de ruta: cable, puerto, adaptador o switch

En la infraestructura real, es más frecuente que falle una ruta concreta que una controladora completa. Por ejemplo:

• falla un módulo SFP;
• se daña un cable;
• falla un puerto de la controladora;
• se bloquea un switch SAN;
• aparece un problema en el adaptador de red del servidor;
• cambia la configuración de la VLAN o de la red iSCSI.

Si las rutas están bien diseñadas, el servidor continúa accediendo al mismo volumen por otra ruta. Para ello se utiliza multipathing: un mecanismo por el que el sistema operativo o el hipervisor ve varias rutas físicas hacia un mismo almacenamiento y las trata como un único disco lógico.

Para Fibre Channel, un diseño típico se ve así:

• el servidor tiene dos adaptadores HBA;
• hay dos switches SAN independientes;
• cada servidor está conectado a ambas fabrics;
• la cabina tiene puertos en la controladora A y en la controladora B;
• el volumen está disponible a través de varias rutas.

Para iSCSI, la lógica es similar, pero en lugar de fabrics FC se utilizan interfaces de red clásicas y redes aisladas:

• al menos dos puertos de red en el servidor;
• dos redes iSCSI o VLAN separadas;
• switches diferentes;
• puertos de almacenamiento diferentes;
• MPIO activado en Windows, Linux o en el hipervisor.

Microsoft señala que MPIO ayuda a proporcionar alta disponibilidad y tolerancia a fallos para el almacenamiento en entornos Hyper-V, de clúster y de virtualización, pero los errores de configuración pueden provocar pérdida de rutas, problemas de rendimiento y paradas inesperadas.

Errores comunes en este tipo de diseños:

• ambos cables están conectados a una sola controladora;
• ambas rutas pasan por un solo switch;
• MPIO no está instalado o no está activado;
• el servidor ve un volumen como varios discos diferentes;
• la política de selección de rutas está configurada al azar;
• el tráfico iSCSI circula junto con la red de usuarios habitual;
• jumbo frames está activado solo en una parte de la ruta;
• una controladora está sobrecargada y la segunda casi no se utiliza.

Por eso, dual controller debe evaluarse junto con las rutas. Dos controladoras en una cabina y un solo cable hacia el servidor no son un diseño tolerante a fallos; son solo una posibilidad de construirlo más adelante.

Active-active, active-passive y ALUA en términos sencillos

En las descripciones de cabinas de almacenamiento suelen aparecer los términos active-active y active-passive. Conviene entenderlos no como etiquetas de marketing, sino como una descripción de cómo las controladoras atienden los volúmenes.

En modo active-active, ambas controladoras pueden participar en el procesamiento de operaciones. Es útil porque los recursos de la cabina se aprovechan mejor. Pero esto no siempre significa que cualquier ruta sea igual de buena para cualquier volumen. En algunas cabinas, un volumen sigue teniendo una controladora preferida a través de la cual las operaciones se ejecutan más rápido.

En modo active-passive, una controladora atiende activamente el volumen, mientras la segunda espera un fallo o un cambio de rol. Este diseño es más simple, pero la conmutación puede notarse más. El rendimiento depende de dónde se encuentre el propietario del volumen y de cómo estén configuradas las rutas.

ALUA es un mecanismo que ayuda al servidor a entender qué rutas hacia un volumen son óptimas y cuáles están disponibles, pero son menos preferibles. Por ejemplo, el servidor puede ver el mismo volumen a través de ambas controladoras, pero la mejor ruta irá por la controladora que actualmente posee ese volumen.

Broadcom VMware señala que, cuando ALUA está soportado, la política Round Robin utiliza por defecto rutas activas optimizadas, mientras que forzar el uso de rutas no optimizadas puede degradar el rendimiento.

En la práctica, esto significa lo siguiente:

• no todas las rutas visibles son igual de útiles;
• la E/S no debe distribuirse a ciegas entre todas las rutas;
• para VMware, Windows y Linux conviene estudiar las recomendaciones concretas del proveedor de la cabina;
• cuando cambia la controladora propietaria del volumen, la política de rutas debe reaccionar correctamente;
• los errores de ALUA pueden parecer “latencias extrañas” sin un fallo evidente.

Si el rendimiento después de conectar una cabina de doble controladora es inferior al esperado, merece la pena revisar no solo los discos y la red, sino también qué rutas transportan realmente la carga.

Por qué una cabina de almacenamiento necesita caché

La caché es memoria rápida dentro de la controladora. Sirve para suavizar la diferencia entre la velocidad de los servidores y la velocidad del subsistema de discos.

La caché puede usarse para lecturas, cuando los datos utilizados con frecuencia se entregan directamente desde la caché, pero la caché de escritura es todavía más interesante.

Los servidores pueden enviar muchas operaciones pequeñas de escritura. Para los discos, e incluso para algunos SSD, estas operaciones no siempre son rápidas: generan carga aleatoria, colas y latencia. La controladora de almacenamiento acepta estas operaciones, las coloca temporalmente en la caché y luego las escribe en los medios de forma más eficiente.

La caché ayuda a:

• confirmar operaciones de escritura más rápido;
• combinar escrituras pequeñas en operaciones más convenientes para la cabina;
• suavizar picos de carga;
• acelerar lecturas repetidas;
• reducir la latencia durante ráfagas cortas de actividad;
• mantener un funcionamiento más estable de máquinas virtuales y bases de datos.

Pero la caché no convierte un grupo de discos lento en infinitamente rápido. Si la carga supera durante mucho tiempo las capacidades de los discos, la caché se llena y la cabina empieza a trabajar a la velocidad real del conjunto. Por eso, la caché es especialmente útil con cargas variables: cuando hay picos, colas, muchas operaciones pequeñas y ráfagas periódicas de escritura.

Para bases de datos, virtualización y servicios de archivos, la caché de escritura suele ser más importante de lo que parece en una especificación seca. Dos cabinas con discos similares pueden comportarse de forma distinta si una tiene más caché, está protegida y funciona en el modo correcto, mientras que en la otra la caché está desactivada por un error de batería.

Write-back y write-through: por qué el modo de caché es tan importante

Las cabinas de almacenamiento suelen tener dos modos básicos de escritura: write-through y write-back.

Write-through es el modo más prudente. La cabina confirma la escritura al servidor solo después de que los datos se hayan escrito realmente en discos o SSD. Es seguro, pero más lento.

Write-back es el modo de mayor rendimiento. La cabina confirma la escritura cuando los datos llegan a la caché de la controladora. La escritura física en los discos se realiza más tarde. Este modo acelera el funcionamiento, pero requiere caché protegida.

La documentación de Dell PowerVault ME5 indica que, en un sistema de doble controladora con ambas controladoras operativas, write-back está activado por defecto, mientras que con una sola controladora o un fallo de controladora se utiliza write-through como modo más seguro. La misma documentación explica la función del supercondensador en la protección de la caché durante una pérdida de alimentación.

La diferencia entre los modos se nota especialmente en cargas con muchas escrituras:

• bases de datos;
• virtualización;
• logs de aplicaciones;
• servidores de terminales;
• VDI;
• servidores de archivos con muchos usuarios;
• backup con deduplicación;
• videovigilancia con flujo constante de escritura.

Si la caché está protegida, write-back suele ofrecer mejor capacidad de respuesta. Si la protección de caché falla, la cabina puede cambiar automáticamente a write-through. Desde el punto de vista del administrador, esto parece una caída brusca de la velocidad de escritura. Pero desde el punto de vista de la cabina, no es un “capricho”; es una reacción de protección: el sistema deja de confirmar escrituras rápidamente hasta estar seguro de que los datos en caché no se perderán.

BBU, supercondensador y CacheVault: qué protegen

BBU, o Battery Backup Unit, es un módulo de alimentación de respaldo para la caché. En sistemas antiguos se usaban más a menudo baterías, mientras que en los más nuevos se utilizan supercondensadores y memoria no volátil. La finalidad es la misma: proteger los datos que la cabina ya ha aceptado, pero que todavía no se han escrito en los medios.

Es importante entender que una BBU no alimenta toda la cabina y no sustituye a un UPS. No sirve para que la cabina siga funcionando durante horas después de un corte eléctrico. Su tarea es más concreta: conservar el contenido de la caché de escritura o dar a la controladora tiempo para mover esos datos a memoria no volátil.

Una batería clásica:

• alimenta la caché durante un fallo;
• tiene una vida útil limitada;
• se degrada con el tiempo;
• puede requerir sustitución;
• a menudo desactiva write-back cuando está en estado de error.

Hoy en día se usan con más frecuencia supercondensadores en lugar de baterías, y funcionan de forma ligeramente distinta:

• proporcionan una reserva breve de energía;
• ayudan a guardar rápidamente los datos de la caché;
• normalmente no están diseñados para alimentar durante mucho tiempo;
• a menudo se usan junto con memoria flash;
• duran más que las baterías, pero también requieren revisiones periódicas y sustitución cuando sea necesario.

CacheVault es una de estas opciones de protección de caché: en caso de pérdida de alimentación, los datos se transfieren desde la RAM de caché a memoria flash no volátil. Cuando vuelve la alimentación, la controladora puede restaurar los datos y completar correctamente la escritura.

La descripción de HPE Smart Storage Battery vincula el módulo de batería con el soporte de protección de datos en caché para controladoras y dispositivos de almacenamiento.

Al comprar o mantener una cabina, es importante mirar no solo el nombre de la tecnología, sino también el estado real:

• si la caché está protegida o no;
• si la batería está cargada o en error;
• si el supercondensador supera el diagnóstico;
• si hay eventos de cambio a write-through;
• si aparecen mensajes de dirty cache;
• si coinciden las versiones de firmware de las controladoras;
• si el módulo puede sustituirse sin una parada prolongada;
• si hay una pieza de repuesto compatible disponible.

Si la BBU está defectuosa, la cabina puede seguir funcionando, pero ya no es la misma configuración por la que se pagó al comprarla. Formalmente, los volúmenes están disponibles, pero el rendimiento de escritura puede disminuir y algunos modos de caché no estarán disponibles.

Espejado de caché entre controladoras

En cabinas de doble controladora, la caché de escritura suele duplicarse entre controladoras. Esto es necesario para protegerse de una situación en la que una controladora acepta datos en caché, confirma la escritura al servidor, pero no llega a mover los datos a los discos.

El proceso puede representarse así:

1. El servidor envía una escritura a la controladora A.
2. La controladora A coloca los datos en su caché.
3. Los datos se copian a la caché de la controladora B.
4. La cabina confirma la escritura al servidor.
5. Si falla la controladora A, la controladora B completa la operación.

Por eso, en una cabina tolerante a fallos, no importan solo las dos controladoras como placas físicas, sino también una conexión sana entre ellas. Si la caché no se sincroniza, si una controladora está en error, si las versiones de firmware difieren o si el canal entre controladoras es inestable, la tolerancia a fallos se vuelve cuestionable.

En los logs de eventos conviene comprobar:

• errores de sincronización de caché;
• mensajes de dirty cache;
• advertencias de batería o supercondensador;
• cambios a write-through;
• reinicios de controladoras;
• pérdida de comunicación entre controladoras;
• errores de puertos y rutas.

Para cabinas reacondicionadas, esto es especialmente importante. Una cabina puede encenderse, mostrar los discos e incluso pasar una prueba básica, pero seguir teniendo un historial de eventos críticos de caché. Este riesgo no puede detectarse solo mirando una foto del panel frontal.

Fallo de alimentación: qué salva la BBU y qué debe salvar el UPS

Un fallo de alimentación debe dividirse en varios niveles.

1. Alimentación de todo el rack o sala de servidores. Aquí ayudan los UPS, dos líneas de alimentación, distintos PDU, una carga correcta por fases y un procedimiento adecuado de apagado.
2. Alimentación de la propia cabina. Aquí son importantes dos fuentes de alimentación conectadas a fuentes distintas. Si ambas fuentes están conectadas a un único PDU, la redundancia real es menor de lo que parece.
3. Datos en caché. Aquí es exactamente donde se necesita una BBU, un supercondensador o una protección similar.

Si se pierde completamente la alimentación, la cabina deja de aceptar nuevas operaciones. Pero para los datos que ya se han confirmado al servidor y aún están en caché, la pregunta crítica es otra: ¿puede la controladora conservarlos hasta que vuelva la alimentación?

BBU y UPS no se sustituyen entre sí:

• un UPS protege la infraestructura frente a un corte eléctrico instantáneo;
• una BBU protege la caché de la controladora;
• dos fuentes de alimentación protegen frente al fallo de una PSU o de una línea eléctrica;
• una copia de seguridad protege frente a errores lógicos y corrupción de datos.

Un diseño fiable utiliza todos estos niveles. Es peligroso pensar que, si hay un UPS en el rack, el estado de la BBU en la cabina no importa. El UPS puede estar sobrecargado, mal conectado, descargado o desconectado durante mantenimiento. La protección de la caché es local, dentro de la cabina.

Fallo de BBU y caída del rendimiento de escritura

Un caso común y poco evidente es cuando una cabina empieza de repente a escribir lentamente, aunque los discos estén sanos, la red no esté sobrecargada y los servidores funcionen con normalidad.

La causa puede estar en la caché. Si la batería o el supercondensador no supera una comprobación, la cabina puede desactivar write-back y cambiar las escrituras a write-through. En este modo, cada escritura debe confirmarse solo después de haberse escrito realmente en los medios, por lo que aumenta la latencia.

Esto se nota especialmente donde hay muchas escrituras pequeñas:

• logs de bases de datos;
• máquinas virtuales con discos activos;
• granjas de terminales;
• VDI;
• sistemas contables;
• recursos compartidos de archivos con muchos usuarios;
• backup con gran cantidad de metadatos.

Desde fuera, puede parecer lo siguiente:

• los usuarios se quejan de “congelaciones”;
• las máquinas virtuales responden más despacio;
• la base de datos confirma transacciones más lentamente;
• suben las gráficas de latencia de escritura;
• la utilización de discos parece alta, aunque antes no existía ese problema.

En una situación así, no conviene sustituir discos o ampliar la red de inmediato. Primero hay que comprobar:

• el estado de la batería o del supercondensador;
• el modo de caché en los volúmenes;
• eventos auto write-through;
• errores de dirty cache;
• el estado de ambas controladoras;
• la sincronización de caché;
• actualizaciones recientes de firmware.

Si la cabina ha desactivado write-back por sí sola, es mejor eliminar la causa que forzar el modo de alto rendimiento a cualquier precio. Las escrituras rápidas sin protección de caché pueden ser más peligrosas que una degradación temporal, porque pueden provocar datos inválidos.

Actualizaciones de firmware y mantenimiento sin parada

Dos controladoras ayudan a realizar el mantenimiento con más cuidado. Pero eso no significa que el firmware pueda actualizarse en cualquier momento de la jornada laboral.

Panel trasero de una cabina de almacenamiento. Fuente de la imagen: documentación de DELL

Durante una actualización, una controladora puede reiniciarse y la carga pasa temporalmente a la otra. Después, el proceso se repite para la segunda controladora. Sobre el papel, los servicios siguen funcionando. En la práctica, puede haber pausas, aumento de latencia, reconexiones de rutas y errores si el multipathing está mal configurado.

Antes de una actualización, conviene comprobar:

• si hay errores activos en la cabina;
• si ambas controladoras están sanas;
• si la caché está sincronizada;
• si la BBU o el supercondensador están en buen estado;
• si todas las rutas son visibles en los servidores;
• si los drivers y módulos DSM/MPIO son compatibles;
• si existe una copia de seguridad actualizada;
• si hay un plan de reversión o instrucciones del proveedor.

Actualizar el firmware en una cabina ya degradada es arriesgado. Si una controladora lleva tiempo en estado de advertencia, la batería está defectuosa, algunas rutas no están disponibles y los logs están llenos de errores, primero hay que investigar el estado de la cabina. De lo contrario, un mantenimiento planificado puede convertirse fácilmente en una recuperación de emergencia.

Cómo saber si una cabina es realmente tolerante a fallos

La tolerancia a fallos no es una única casilla en una especificación. Se construye a partir de varias capas.

Una buena configuración suele incluir:

• dos controladoras;
• dos fuentes de alimentación;
• caché de escritura protegida;
• BBU o supercondensador en buen estado;
• redundancia de discos a nivel RAID o pool;
• dos rutas independientes desde cada servidor;
• dos switches SAN o dos redes iSCSI aisladas;
• multipathing activado;
• política correcta de selección de rutas;
• firmware actualizado y compatible;
• monitorización de eventos;
• revisión periódica de logs;
• failover probado;
• copias de seguridad.

Cualquier configuración que parezca perfecta sobre el papel no puede considerarse fiable hasta que se hayan realizado pruebas y simulacros de fallo.

Una mala configuración también suele resultar familiar:

• la cabina tiene dos controladoras, pero el servidor está conectado con un solo cable;
• ambos cables van a un único switch;
• la segunda controladora está instalada, pero no participa en el servicio de los volúmenes;
• write-back está desactivado, pero el administrador no lo ha notado;
• la BBU está en estado de advertencia;
• las versiones de firmware de las controladoras difieren;
• algunos puertos no se han comprobado;
• los logs no se exportaron después de la entrega;
• nunca se ha probado la desconexión de una ruta.

Por eso, al elegir una cabina para una empresa, conviene preguntar no “¿tiene dual controller?”, sino “¿cómo está construida exactamente toda la cadena de acceso a los datos?”.

Comprobación de una cabina reacondicionada antes de comprar

Al comprar una cabina de almacenamiento reacondicionada, no conviene basarse solo en el modelo, el número de discos y el precio. En estos sistemas es especialmente importante el estado de los componentes responsables de la tolerancia a fallos: controladoras, caché, módulos de protección, puertos, firmware y logs de errores.

En cabinas reacondicionadas, los detalles pequeños son especialmente importantes. Por ejemplo, una cabina puede tener dos controladoras, pero un puerto puede estar defectuoso. O puede tener una batería instalada, pero que ya no mantiene la carga. O la caché puede estar formalmente activada, pero los logs pueden contener eventos regulares de cambio a modo seguro.

Antes de comprar, conviene aclarar:

1. ¿La cabina tiene una controladora o dos?
2. ¿Ambas controladoras pasan el diagnóstico?
3. ¿Coinciden las versiones de firmware?
4. ¿Cuál es el estado de la caché?
5. ¿Está activado write-back?
6. Si write-back está desactivado, ¿por qué?
7. ¿Cuál es el estado de la BBU, del supercondensador o de CacheVault?
8. ¿Hay errores de dirty cache?
9. ¿Se han comprobado todos los puertos?
10. ¿Existe un log de eventos después de las pruebas?
11. ¿Se realizó una prueba de desconexión de una ruta?
12. ¿Se realizó una prueba de desconexión de una controladora?
13. ¿Hay garantía para controladoras y módulos de batería?
14. ¿Se puede sustituir por separado la BBU, la PSU, el ventilador o la controladora?
15. ¿Qué componentes son nuevos y cuáles son reacondicionados?

Para tareas de entrada y gama media, las empresas suelen considerar cabinas de almacenamiento HP, Dell PowerVault, Dell Unity, NetApp y otras plataformas. Pero la marca por sí sola no resuelve la cuestión de fiabilidad. Importan más el estado concreto de la unidad, su configuración y los resultados del diagnóstico.

Storage systems

Qué tareas necesitan especialmente dos controladoras

Dual controller debe considerarse casi obligatorio allí donde una parada se vuelve rápidamente costosa.

Estas tareas incluyen:

• virtualización;
• clústeres de bases de datos;
• ERP y sistemas contables;
• servidores de terminales;
• almacenamiento de archivos de negocio;
• VDI;
• videovigilancia con grabación constante;
• backup, si la cabina es el sitio principal de almacenamiento de copias;
• sistemas de producción;
• aplicaciones médicas, financieras y contables.

En estos escenarios, la disponibilidad del servicio es tan importante como la conservación de los datos. A veces, perder el acceso al almacenamiento durante 10–15 minutos ya basta para detener un departamento, interrumpir un turno o incumplir un SLA.

Una cabina con una sola controladora puede ser aceptable para:

• bancos de pruebas;
• laboratorios;
• almacenamiento temporal;
• archivos sin requisitos estrictos de disponibilidad;
• un tercer nivel de copias de seguridad;
• tareas donde la parada ya se ha aceptado como un riesgo permitido.

Pero si la cabina alojará máquinas virtuales de producción, bases de datos, perfiles de usuarios o carpetas compartidas de la empresa, ahorrar en la segunda controladora suele ser cuestionable.

Por qué dos controladoras no siempre significan más velocidad

Un error común es pensar que, si hay dos controladoras, la cabina debe funcionar el doble de rápido. A veces la segunda controladora realmente ayuda a distribuir la carga, pero la mejora de rendimiento depende de la arquitectura de la cabina.

El rendimiento está influido por:

• el tipo de discos o SSD;
• el nivel RAID o la estructura del pool;
• el tamaño y modo de la caché;
• el número de puertos;
• la velocidad de la red o SAN;
• la política de multipathing;
• la distribución de volúmenes entre controladoras;
• el perfil de carga;
• el estado de la batería o del supercondensador.

Si todos los volúmenes son atendidos en la práctica por una sola controladora, la segunda puede quedar inactiva. Si las rutas están mal configuradas, algunas operaciones pueden ir por una ruta no optimizada. Si write-back está desactivado, las escrituras pueden ser lentas incluso con buenos discos.

Por eso, al diagnosticar rendimiento, hay que mirar no solo el “hardware”, sino también la lógica de funcionamiento:

• qué controladora posee el volumen;
• qué rutas están activas;
• qué rutas están optimizadas;
• cómo se distribuye la E/S;
• si la caché de escritura está activada;
• si hay errores de protección de caché;
• si un puerto concreto está sobrecargado.

Dos controladoras son una herramienta para tolerancia a fallos y balanceo, no una garantía automática de duplicar la velocidad.

Conceptos erróneos comunes sobre dual controller, caché y BBU

“Dual controller protege los datos contra la pérdida”

Aumenta la disponibilidad, pero no sustituye las copias de seguridad. Si un usuario elimina un archivo, una base de datos se corrompe lógicamente o el ransomware cifra un recurso compartido, la segunda controladora no recuperará los datos. Para eso se necesitan copias de seguridad, snapshots, replicación y procedimientos de recuperación.

“Si hay un UPS, la batería de caché no hace falta”

UPS y BBU resuelven tareas distintas. Un UPS mantiene la alimentación del equipo. Una BBU o un supercondensador protege los datos que ya se han confirmado al servidor y siguen en caché. Un diseño fiable usa ambas capas.

“Write-back siempre es mejor”

Write-back es más rápido, pero solo con caché protegida. Si la protección de caché falla, es más seguro trabajar más despacio en write-through que confirmar escrituras rápidamente sin garantía de conservación e integridad de los datos (!).

“Las cabinas reacondicionadas son peligrosas por definición”

El riesgo no depende de la palabra reacondicionado, sino del diagnóstico. Una cabina reacondicionada con controladoras probadas, caché sana, logs limpios y garantía puede ser una opción razonable. Pero comprar una cabina así sin comprobar BBU, firmware y puertos es una mala idea.

“Basta con comprar una cabina con dos controladoras”

No. Todavía hay que conectar correctamente los servidores, configurar multipathing, comprobar ALUA, probar fallos de ruta y de controladora, asegurarse de que la caché está sana y vigilar los logs.

Cómo describir correctamente la tolerancia a fallos en una especificación

La frase “la cabina es tolerante a fallos porque tiene dual controller” es demasiado general. No dice nada sobre cómo está conectada la cabina, si la caché está protegida, si los puertos están sanos o si las rutas están configuradas.

Una formulación más precisa sería:

“La cabina está equipada con dos controladoras, dos fuentes de alimentación, caché de escritura protegida y un módulo BBU o supercondensador en buen estado. Los servidores se conectan a la cabina por dos rutas independientes con multipathing configurado. Antes de la puesta en producción se comprueban el fallo de controladora, la pérdida de ruta, el estado de caché, las versiones de firmware y los logs de eventos”.

Esta formulación refleja mejor la realidad. La tolerancia a fallos no es un componente aislado, sino el resultado de todo el diseño: cabina, servidores, adaptadores, switches, cables, firmware y ajustes del sistema operativo.

Qué comprobar primero

Si necesitas evaluar rápidamente una cabina, empieza no por la capacidad, sino por las preguntas sobre riesgos de fallo.

Comprueba:

• si hay dos controladoras instaladas;
• si ambas controladoras están sanas;
• si la caché de escritura está protegida;
• en qué modo funciona la caché;
• si la BBU o el supercondensador están en buen estado;
• si existe dirty cache;
• si coinciden las versiones de firmware;
• si todos los puertos funcionan;
• si hay dos rutas independientes desde los servidores;
• si el multipathing está configurado;
• si se ha realizado una prueba de fallo de ruta;
• si hay logs recientes sin errores críticos.

Para servicios críticos, es mejor elegir una cabina con menos capacidad, pero con dos controladoras sanas, caché protegida y un diseño de conexión verificado, que un sistema de mayor capacidad con un estado poco claro de batería, puertos y logs de eventos. En el almacenamiento de datos, la fiabilidad no se determina solo por el número de terabytes, sino por lo que ocurre en el momento del fallo.