Auditoría de CPD y clústeres
La única forma de saber qué ocurre cuando cae un nodo es apagarlo a propósito, en una ventana controlada y con todo el mundo delante.
El problema
Los centros de datos y los clústeres se diseñan para resistir fallos, pero esa resistencia casi nunca se comprueba. La configuración existe, los diagramas dicen que hay redundancia y nadie ha visto jamás qué pasa realmente cuando un nodo desaparece.
Cuando por fin ocurre, aparecen las sorpresas: la carga no cabe en los nodos restantes, el almacenamiento tenía un camino único que nadie había detectado, las dos fuentes de alimentación estaban conectadas a la misma línea, el servicio de directorio vivía en una máquina sin réplica o el clúster se quedó bloqueado esperando un quorum imposible.
Nada de eso se descubre revisando documentación. Se descubre probando.
Qué hace IT Encore
Revisamos el diseño del centro de datos y, cuando el cliente lo autoriza, lo sometemos a pruebas reales: apagado controlado de un nodo, desconexión de un camino de almacenamiento, pérdida de un enlace de red, simulación de fallo de alimentación.
Esas pruebas se hacen en ventana acordada, con procedimiento escrito, con criterios de éxito definidos y con la posibilidad de detener el ensayo en cualquier momento. El objetivo no es demostrar que algo falla, sino saber exactamente qué ocurre y cuánto tarda en recuperarse.
El resultado es un informe que documenta el comportamiento observado ante cada tipo de fallo, la lista de puntos únicos de fallo detectados y las recomendaciones ordenadas por impacto.
Qué se revisa
- Clústeres. Diseño, número de nodos, quorum, políticas de admisión y comportamiento configurado ante fallo.
- Almacenamiento. Tipo, caminos múltiples, replicación, capacidad, rendimiento y salud de los soportes.
- Networking. Separación de tráficos, agregación de enlaces, redundancia de conmutadores y caminos alternativos.
- Alta disponibilidad. Qué está realmente redundado, con qué margen de capacidad y con qué tiempo de conmutación.
- Pruebas de apagado. Ensayo controlado de la caída de un nodo, de un camino de almacenamiento o de un enlace.
- Recuperación. Prueba de restauración desde copia y medición del tiempo real de recuperación.
- Dependencias. Servicios de infraestructura de los que depende todo lo demás: directorio, DNS, licencias, certificados.
- Puntos únicos de fallo. Inventario de SPOF, incluidos los físicos: alimentación, refrigeración y cableado.
- Procedimientos. Existencia y calidad de los procedimientos de intervención, escalado y recuperación.
- Capacidad. Margen disponible y proyección de crecimiento frente a la capacidad instalada.
Cómo se ejecutan las pruebas
- 1
Revisión previa
Análisis de la configuración y del diseño antes de plantear ninguna prueba con impacto.
- 2
Diseño del ensayo
Qué se va a provocar, en qué orden, qué se espera que ocurra y cómo se mide.
- 3
Autorización y ventana
Aprobación expresa del cliente, ventana acordada y comunicación previa a los responsables.
- 4
Preparación
Copia verificada previa, criterios de parada del ensayo y plan de recuperación si algo no responde.
- 5
Ejecución
Provocación del fallo con observación y registro de tiempos y de comportamiento real.
- 6
Restablecimiento
Vuelta al estado normal y verificación de que la plataforma queda íntegra.
- 7
Informe
Comportamiento observado, desviaciones respecto a lo esperado y recomendaciones priorizadas.
Hallazgos que aparecen con más frecuencia
Capacidad sin margen
El clúster funciona al límite y la caída de un nodo no la absorben los restantes.
Quorum mal resuelto
Clúster de dos nodos sin árbitro, con riesgo de bloqueo o de doble maestro.
Camino único de almacenamiento
Redundancia aparente que en realidad pasa por un único controlador o un único conmutador.
Alimentación no redundante
Fuentes duplicadas conectadas a la misma línea o a la misma regleta.
Servicios base sin réplica
Directorio, DNS o servidor de licencias en una única máquina de la que depende todo.
Procedimientos inexistentes
Nadie sabe qué hacer ante un fallo porque nunca se ha escrito ni se ha ensayado.
Preguntas frecuentes
¿Es arriesgado apagar un nodo a propósito?
Menos que descubrir el comportamiento real durante un incidente. Aun así, la prueba se prepara: copia verificada previa, ventana acordada, criterios de parada y plan de recuperación. Y sólo se ejecuta con autorización expresa del cliente.
¿Se puede auditar sin hacer pruebas con impacto?
Sí. La revisión de configuración y de diseño aporta mucho por sí sola. Las pruebas son un alcance ampliado, que muchos clientes contratan después de ver el informe inicial.
¿Sirve para un CPD alojado en un tercero?
Sí. Revisamos la parte que corresponde al cliente —clúster, almacenamiento, red interna, procedimientos— y valoramos la dependencia respecto al operador del centro de datos, aunque su instalación física quede fuera del alcance.
¿Con qué frecuencia conviene repetirlo?
Una revisión anual es razonable en plataformas críticas, y siempre después de un cambio relevante: una ampliación, una migración o una renovación de hardware pueden invalidar un comportamiento que antes era correcto.
Servicios relacionados
Alta disponibilidad (HA)
Clustering, redundancia, quorum y eliminación de puntos únicos de fallo.
Ver servicioAuditoría de infraestructura TI
Servidores, virtualización, almacenamiento, red, backup, HA, obsolescencia y riesgos.
Ver servicioDisaster Recovery
Infraestructura alternativa, runbooks, orquestación y pruebas reales de recuperación.
Ver servicioComprobemos si su CPD resiste
Revisión de diseño y, si lo autoriza, pruebas reales de fallo en ventana controlada.