Contenido verificado asociado a este RA
Fundamentos de Alta Disponibilidad y Continuidad de Servicio
Esta unidad introduce los conceptos esenciales de la alta disponibilidad (HA) y la continuidad de negocio, analizando escenarios críticos y las soluciones hardware fundamentales para prevenir fallos y asegurar la operación ininterrumpida de los sistemas.
Virtualización y Clustering para la Alta Disponibilidad
Esta unidad explora cómo la virtualización y las tecnologías de clustering son herramientas poderosas para implementar soluciones de alta disponibilidad, permitiendo la migración de máquinas virtuales y la tolerancia a fallos a nivel de software.
Implementación de Servidores Redundantes y Balanceo de Carga
Esta unidad se centra en la implementación práctica de servidores redundantes para garantizar la continuidad de servicios y la configuración de balanceadores de carga para distribuir el tráfico y mejorar el rendimiento y la disponibilidad de las aplicaciones.
Sistemas de Almacenamiento Redundante y Escalabilidad Futura
Esta unidad aborda la implementación de sistemas de almacenamiento redundante para asegurar la integridad y disponibilidad de los datos, y analiza soluciones de futuro para sistemas con demanda creciente, incluyendo estrategias de escalabilidad y documentación de soluciones.
Conceptos clave
Alta Disponibilidad (HA)Continuidad de Negocio (BC)RTO (Recovery Time Objective)RPO (Recovery Point Objective)Single Point of Failure (SPOF)RAID (Redundant Array of Independent Disks)NIC Teaming/BondingFuentes de alimentación redundantesVirtualizaciónHipervisorMáquina Virtual (VM)Migración en vivo (Live Migration/vMotion)HA de VMsTolerancia a fallos (Fault Tolerance - FT)ClusterFailover ClusterLoad Balancing ClusterNodo de clúster
Errores que conviene evitar
- Confundir HA con una simple copia de seguridad: La HA busca minimizar el tiempo de inactividad y la pérdida de datos en tiempo real, mientras que la copia de seguridad es para recuperación a largo plazo. Corrección: Entender que HA es proactiva y backup es reactivo.
- No identificar todos los SPOF: A menudo se olvida la red, el almacenamiento o incluso el personal. Corrección: Realizar un análisis exhaustivo de la infraestructura y los procesos.
- Conectar componentes redundantes a un único punto de fallo: Por ejemplo, dos fuentes de alimentación a la misma regleta. Corrección: Asegurar la independencia total de los caminos redundantes (energía, red, etc.).
- No configurar correctamente la red para el clúster: Las redes de heartbeat, vMotion y de servicio deben estar separadas y redundantes. Corrección: Diseñar una arquitectura de red robusta y segmentada para el clúster.
- Depender solo de la HA de VMs sin considerar la infraestructura subyacente: Si el almacenamiento compartido falla, todo el clúster puede caer. Corrección: Asegurar la redundancia en todos los niveles, incluyendo el almacenamiento y la red.
- Sobredimensionar o subdimensionar el clúster: Un clúster demasiado pequeño no soportará la carga en caso de fallo; uno demasiado grande es un gasto innecesario. Corrección: Realizar un análisis de capacidad y rendimiento para dimensionar adecuadamente el clúster.
- No configurar correctamente el almacenamiento compartido para el clúster: Si el almacenamiento no es accesible por todos los nodos o no es redundante, el clúster fallará. Corrección: Validar la conectividad y redundancia del almacenamiento antes de configurar el clúster.
- Fallo en la configuración de los 'health checks' del balanceador de carga: Si el balanceador no detecta correctamente la caída de un servidor, seguirá enviando tráfico a un servicio no disponible. Corrección: Implementar 'health checks' específicos del servicio (ej. HTTP GET a una página de estado) y no solo un ping de red.