Recuperación del clúster tras un corte total de energía
Procedimiento de recuperación y mejores prácticas para clústeres VergeOS después de una pérdida total de energía no planificada, incluido el orden de encendido, la verificación de la integridad de vSAN y la guía de prevención.
Resumen
Alcance
Esta guía cubre cómo volver a encender un clúster VergeOS después de un apagado no controlado -- en el que el clúster perdió la energía bruscamente debido a un corte eléctrico, agotamiento del SAI/UPS, fallo de la instalación o un evento similar. Para los procedimientos planificados y controlados de apagado y encendido, consulte Procedimiento correcto de apagado del sistema VergeOS y Secuencia correcta de encendido y apagado.
Evitar apagados no controlados siempre que sea posible
Aunque VergeOS incluye múltiples protecciones integradas para preservar la integridad de los datos, ningún sistema de almacenamiento distribuido puede garantizar por completo contra la corrupción de datos cuando los nodos pierden la energía de forma abrupta y simultánea.
Las escrituras en curso en el momento de la pérdida de energía pueden quedar incompletas o inconsistentes entre pares, y en algunos casos la única forma de recuperar la integridad es revertir un volumen a una instantánea reciente.
Además, los problemas de hardware, del sistema operativo invitado y de las aplicaciones son comunes después de apagados no controlados.
Una infraestructura de alimentación adecuada -- cobertura de UPS/SAI dimensionada para un apagado controlado, fuentes de alimentación redundantes y apagado automatizado con batería baja -- es la protección más eficaz; consulte la Prevención sección para obtener orientación.
Cuando se produce un apagado no controlado a pesar de estas precauciones, el procedimiento que sigue está diseñado para volver a poner el clúster en línea de forma segura y detectar cualquier problema de integridad que requiera atención.
Requisitos previos
Acceso físico o IPMI/BMC a cada nodo
Conocimiento de qué nodo es Node1 (Node1 deberá arrancarse primero.)
Confirmación de que la energía aguas arriba, la red (switches principales de la infraestructura) y el IPMI se han restablecido y son estables
Una instantánea reciente local o replicada remotamente en caso de que se detecten problemas de integridad
Familiaridad con el Panel de vSAN Tier / Journal Walks
Pasos
Qué esperar
VergeFS incluye múltiples protecciones integradas para ayudar a preservar la integridad de los datos durante eventos de energía -- incluyendo journaling de escrituras, replicación entre pares, servidores de reparación (ioGuardian) y verificación al iniciar. Al arrancar el controlador, VergeFS desencadena un Journal Walk completo para verificar cada bloque y reconciliarlo con los pares. Estas protecciones son eficaces en la mayoría de los casos, pero ningún sistema de almacenamiento distribuido puede garantizar por completo contra la corrupción causada por una pérdida brusca de energía; la verificación después del inicio es importante, especialmente después de un apagado no controlado.
vSAN requiere Cantidad mínima de nodos en línea antes de montarse (p. ej., en un clúster de 4 nodos con protección N+1, vSAN se monta siempre que 3 nodos estén en línea) Hasta que se alcance ese umbral, el almacenamiento permanece fuera de línea y las VM no se iniciarán.
Node1 arrancará pero se detendrá antes de montar vSAN hasta que se unan suficientes pares.
Un Reparaciones conteo tras la recuperación es normal y debería disminuir a medida que avanza el Walk.
Comprobaciones previas al encendido
Verifique primero que la infraestructura esté lista
Antes de encender cualquier nodo del clúster, confirme que se cumplen dos condiciones críticas. Estas se cubren en los requisitos previos, pero vale la pena repetirlas aquí -- omitirlas puede causar mucho más daño que el apagado original:
La energía de la instalación se ha restablecido por completo y es estable. Levantar el clúster durante una inestabilidad eléctrica en curso -- parpadeos, caídas de tensión o un segundo corte -- corre el riesgo de agravar el problema original y puede provocar más problemas de integridad de los datos.
Los switches principales de la red están encendidos y completamente arrancados. Los switches empresariales pueden tardar varios minutos en completar su proceso de arranque, de forma similar a un servidor. Si los nodos del clúster entran en línea antes de que la red esté lista, no podrán descubrir a sus pares, lo que puede causar problemas de reconciliación.
Confirme la energía aguas arriba es estable. Levantar los nodos con una alimentación inestable supone el riesgo de un segundo corte en medio de la recuperación.
Confirme los switches principales de la red están en línea, completamente arrancados, y la infraestructura entre nodos está activa. vSAN no puede reformarse sin ella, y los switches avanzados pueden tardar varios minutos en terminar de arrancar.
Verifique IPMI/BMC acceso en cada nodo para que pueda supervisar el arranque de forma remota si es necesario.
Anote cualquier nodo con fallos de hardware visibles (PSU defectuosas, LED de discos, alarmas de ventiladores) -- estos pueden requerir atención antes de volver a incorporarlos.
Secuencia de encendido
Una vez que se confirma que la energía y la infraestructura de red están listas:
Encienda Node1.
Observe la consola/IPMI. Node1 arrancará el sistema operativo pero se detendrá antes de montar vSAN hasta que se unan suficientes pares.
Espere de 30 segundos a un minuto.
Esta breve pausa permite que Node1 comience a inicializarse antes de que llegue el resto del clúster. No es necesario esperar a que Node1 alcance por completo su estado de detención antes de continuar.
Encienda los nodos restantes.
Los nodos restantes pueden encenderse juntos (o en rápida sucesión); no es necesario escalonarlos uno por uno.
vSAN se monta automáticamente en cuanto hay un número mínimo de nodos en línea (p. ej., todos menos un nodo en una configuración N+1 predeterminada).
Entornos con varios clústeres: ponga completamente en línea el clúster controlador antes de encender clústeres adicionales.
Consejo
Node1 arranca primero y espera mientras enciende el resto del clúster -- eso es lo esperado, no un estado atascado. vSAN se monta por sí solo en cuanto hay suficientes pares en línea, y VergeOS gestiona la reconciliación automáticamente; no se necesitan comandos manuales de reparación.
Verificación posterior a la recuperación
Una vez que todos los nodos estén en línea y el clúster haya tenido tiempo de estabilizarse, verifique que todo haya vuelto a un estado saludable. Debido a que el clúster se apagó de forma no controlada, realice estas comprobaciones con mayor escrutinio -- una pérdida brusca de energía puede dejar problemas que el clúster no puede resolver por completo por sí mismo. Busque cuidadosamente errores persistentes de vSAN, cargas de trabajo fallidas o en bucle de fallos, y cualquier error del sistema de archivos a nivel de invitado. Si se detecta corrupción irrecuperable, puede ser necesario revertir un volumen a una instantánea reciente.
Confirme el estado general del sistema
La pérdida brusca de energía aumenta el riesgo de problemas de hardware. Es importante comprobar cualquier incidencia:
Revise los Alarmas panel. Confirme que no se hayan activado nuevas alarmas.
Revise registros del sistema (Panel principal) para detectar errores durante el arranque o el montaje inicial.
Verifique el estado de vSAN
Abra el Panel principal -- todas las luces de estado deberían estar Verdes.
Vaya a Sistema → vSAN → Niveles y haga doble clic en cada nivel.
Revise los Estado mosaico en el panel de cada nivel. El artículo de KB Entender los recorridos de estado/registro de nivel de vSAN proporciona una guía para leer los campos de estado de los niveles de vSAN.
Verifique el estado de los discos
Ve a Sistema → vSAN → Discos.
Busque cualquier disco que muestre errores, advertencias o alertas SMART -- esto puede ocurrir cuando los discos no vuelven de forma limpia después de una pérdida brusca de energía.
Reemplace los discos defectuosos con rapidez para mantener la protección de datos de vSAN.
Verifique las cargas de trabajo
Comportamiento de inicio automático de las VM
De forma predeterminada, las VM están configuradas para iniciarse automáticamente cuando se restablece la energía del clúster. Las VM con un En caso de pérdida de energía ajuste alternativo deberán encenderse manualmente.
Verifique las VM críticas: consola respondiendo, SO invitado saludable, servicios de aplicación en funcionamiento. Los apagados no controlados pueden causar problemas dentro del SO invitado y de las aplicaciones instaladas -- esté atento a errores del sistema de archivos, servicios que no logran iniciarse y aplicaciones que se bloquean al arrancar.
Identifique posibles candidatas a reversión lo antes posible -- idealmente antes de que las aplicaciones vuelvan a un uso intensivo.
Las decisiones de reversión a instantánea son sensibles al tiempo
Si el sistema general o las VM individuales muestran signos de daño por el apagado no controlado que no pueden repararse en su lugar, restaurar desde una instantánea anterior al corte puede ser la única forma de volver a un estado saludable. Esta determinación debe hacerse lo antes posible, por dos razones:
La retención de instantáneas es finita. Una instantánea viable anterior al corte puede caducar y dejar de estar disponible si pasa demasiado tiempo antes de tomar la decisión.
Se pierden datos más recientes al revertir. Cuanto más tiempo permanezca la VM afectada en uso de producción después del corte, más trabajo legítimo posterior a la recuperación se descarta cuando se realiza la reversión.
Resolución de problemas
Problemas comunes
Problema: Un nodo no logra reincorporarse al clúster.
Solución: Compruebe la salida de IPMI/consola en busca de errores de arranque. Verifique que la interfaz principal de red del nodo esté activa y sea accesible desde los pares. Revise Sistema → Nodos → [nodo] para ver el estado y las marcas de tiempo de última detección. Si el nodo arranca pero no se une, no no lo elimine a la fuerza -- póngase en contacto con el soporte.
Problema: vSAN no se monta / almacenamiento fuera de línea.
Solución: Confirme Los nodos mínimos de vSAN están en línea en Sistema → Nodos (p. ej., en una configuración predeterminada: 3 de 4 en un clúster de 4 nodos, 5 de 6 en un clúster de 6 nodos). Confirme la conectividad entre nodos (switches principales de la infraestructura, estado del enlace, MTU). Si se cumple el umbral pero el almacenamiento sigue sin montarse, capture un sysdiag y contacte con soporte.
Problema: El conteo de reparaciones está atascado o creciendo.
Solución: Un conteo pequeño y decreciente Reparaciones es normal después de la recuperación. Un conteo que deja de disminuir o aumenta indica bloques que vSAN no puede reconstruir a partir de los pares. No reinicie ningún nodo. Póngase en contacto con soporte antes de tomar medidas de remediación.
Problema: Se sospecha split-brain o un estado inconsistente del clúster.
Solución: Durante la recuperación, un problema de red puede hacer que dos subconjuntos de nodos arranquen sin poder verse entre sí. Si ve indicios de que se están formando dos clústeres independientes (raro, pero posible después de una restauración parcial de la red), no intente fusionarlos usted mismo. Capture sysdiags de cada nodo y contacte con soporte de inmediato.
Prevención/Mitigación
Dimensionamiento y cobertura del UPS/SAI -- dimensione el UPS/SAI para cubrir la duración del apagado controlado más un margen para cada nodo. Incluya los switches principales de la red en la misma cobertura. Pruebe anualmente la autonomía del UPS/SAI -- las baterías se degradan.
Apagado controlado automatizado -- Use software de gestión de UPS/SAI (NUT, scripting de IPMI o el agente de su proveedor de UPS/SAI en un host de gestión) para detectar un evento de batería baja y desencadenar un apagado controlado del clúster -- ya sea mediante la Apagar acción del Panel del clúster, la API de VergeOS (
POST /v4/cluster_actionscon el cuerpo{"cluster": <cluster_id>, "action": "shutdown", "params": "{}"}), o nuestra CLI VRG envoltura, que puede automatizar la misma llamada de apagado desde un host Linux/macOS/Windows. Valide la automatización en una ventana de mantenimiento antes de confiar en ella.Ajustes de VM "Al perder energía" -- configure deliberadamente el comportamiento de cada VM para que el estado posterior a la recuperación sea predecible. Tres opciones:
Último estado -- la VM solo se enciende si estaba encendida en el momento de la pérdida de energía
Dejar apagada -- la VM permanece apagada cuando se restablece la energía, independientemente del estado previo
Encendido -- la VM se enciende cuando se restablece la energía, independientemente del estado previo
Servidor de reparación (ioGuardian) -- un servidor de reparación proporciona a VergeFS una fuente de respaldo para los bloques faltantes si los nodos pares no pueden suministrarlos después de un corte. Se construye a partir de una configuración de sincronización saliente de sitio existente y extrae los bloques necesarios de un sistema remoto de VergeOS sincronizado. Los servidores de reparación se recomiendan encarecidamente para cualquier despliegue de producción.
Rotación de instantáneas adecuada -- mantenga un plan de retención de instantáneas que conserve disponibles instantáneas recientes previas al evento para poder revertir cuando sea necesario. También se recomienda replicar instantáneas a un sitio remoto como parte de una estrategia integral de protección de datos.
Cuándo contactar con soporte
Abra un caso de soporte antes de reiniciar nodos o realizar cualquier otro cambio importante, si se cumple alguna de las siguientes condiciones:
vSAN no se monta después de que N nodos estén en línea (p. ej., el número total de nodos menos uno en una redundancia N+1 predeterminada)
Un nivel muestra Redundante: false durante un período prolongado después de que se completen los Full Walks
El Reparaciones el conteo está atascado o creciendo
Hay una alerta de reparaciones atascadas (VergeOS v26+)
Varios discos informan errores después de la recuperación
Sospecha split-brain o un estado inconsistente del clúster
Algún nodo no logra reincorporarse y la causa no es obviamente de hardware
Generación de un diagnóstico del sistema para soporte
Antes de abrir el caso, capture un sysdiag y adjúntelo (o envíelo directamente al soporte):
Consulte Generación de diagnósticos del sistema y la completa Diagnósticos del sistema referencia.
Recursos adicionales
Comentarios
Última actualización
¿Te fue útil?