--- title: "Arquitecturas de alta disponibilidad y buenas prácticas de clustering de software" canonical: "https://safekit.eviden.com/es/best-practises/high-availability-architectures-and-best-practices/" description: "Explore las arquitecturas de alta disponibilidad (HA) y las buenas prácticas para clústeres de aplicaciones. Descubra cómo SafeKit implementa clústeres Mirror y Farm sin discos compartidos, evitando la pérdida de datos y ofreciendo conmutación automática por error para aplicaciones críticas." category: "best-practises" lang: "es" topics: "¿Cuáles son las arquitecturas de alta disponibilidad y las buenas prácticas?, Tablas comparativas de arquitecturas de alta disponibilidad y buenas prácticas" --- # Arquitecturas de alta disponibilidad y buenas prácticas de clustering de software {#high-availability-architectures--software-clustering-best-practices} ## ¿Cuáles son las arquitecturas de alta disponibilidad y las buenas prácticas? {#what-are-the-high-availability-architectures-and-the-best-practices} ### Descripción general {#overview} Este artículo presenta distintas arquitecturas de alta disponibilidad y buenas prácticas, y compara las ventajas y desventajas de cada una. ![Arquitecturas de alta disponibilidad y buenas prácticas](https://safekit.eviden.com/wp-content/uploads/2023/03/high-availability-architectures-and-best-practices.png "w:400") Las siguientes tablas comparativas detallan la arquitectura de alta disponibilidad de SafeKit y sus buenas prácticas. SafeKit es un producto de software para alta disponibilidad. ### ¿Cuáles son las arquitecturas de alta disponibilidad? {#what-are-the-high-availability-architectures} Hay dos tipos de [arquitecturas de alta disponibilidad](): las destinadas a aplicaciones de back-end, como las bases de datos, y las destinadas a aplicaciones de front-end, como los servicios web. Las arquitecturas de back-end se basan en dos servidores que comparten o replican datos y realizan una conmutación automática de la aplicación ante fallos de hardware o software. Las arquitecturas de front-end se basan en una granja de dos o más servidores. El equilibrio de carga, por hardware o software, distribuye las sesiones TCP entre los servidores disponibles. También hay que elegir entre alta disponibilidad a nivel de aplicación y a nivel de máquina virtual. ### ¿Cuáles son las buenas prácticas? {#what-are-the-best-practices} Este artículo analiza las buenas prácticas de las arquitecturas de alta disponibilidad mediante la comparación de: * [clustering de software y hardware](), * [arquitectura sin recursos compartidos y con disco compartido](), * [alta disponibilidad de aplicación y de máquina virtual](), * [alta disponibilidad y tolerancia a fallos](), * [replicación síncrona y asíncrona](), * [replicación de archivos y de discos](), * [técnicas de replicación de datos](), * [RPO y RTO con ejemplos](), * [split-brain y quórum](), * [direcciones IP virtuales](). ## Tablas comparativas de arquitecturas de alta disponibilidad y buenas prácticas {#comparative-tables-on-high-availability-architectures-and-best-practices} Elegir la solución de alta disponibilidad (High Availability - HA) adecuada es esencial para garantizar la continuidad del negocio y minimizar el tiempo de inactividad. Esta comparación ofrece una revisión técnica directa de dos enfoques arquitectónicos principales: el clustering por software de arquitectura sin compartición (Shared-Nothing) de SafeKit frente a los métodos de alta disponibilidad tradicionales, que suelen depender de hardware, discos compartidos (como una SAN) y configuraciones complejas. Estas diferencias abarcan la simplicidad de despliegue, los métodos de replicación de datos, la velocidad de recuperación (RTO/RPO) y la complejidad operativa. La siguiente tabla detalla las diferencias fundamentales en los temas clave de alta disponibilidad. **Comparación de alta disponibilidad: Clustering por software SafeKit vs. HA tradicional / Clustering de hardware** Tema | SafeKit (Clustering por software / Enfoque principal) | HA tradicional / Clustering de hardware ---|---|--- [Clustering por software vs. Clustering de hardware](https://safekit.eviden.com/best-practises/clustering-software-vs-hardware-clustering/) | • Un clúster de software sencillo con el paquete SafeKit instalado directamente en solo dos servidores | • Un clustering de hardware complejo que requiere almacenamiento externo o balanceadores de carga de red [Clúster Shared Nothing vs. Clúster de discos compartidos](https://safekit.eviden.com/best-practises/shared-nothing-architecture-vs-shared-disk-architecture/) | • SafeKit es un clúster sin compartición (Shared-Nothing): fácil de desplegar, incluso en sedes remotas | • Un clúster de discos compartidos es muy complejo de desplegar [Alta disponibilidad de aplicaciones vs. Alta disponibilidad completa de máquinas virtuales](https://safekit.eviden.com/es/best-practises/vm-ha-vs-application-ha/) | • La HA de aplicaciones admite fallos de hardware y de software mediante comprobadores (checkers) de aplicaciones.
• Tiempo de recuperación rápido al reiniciar solo la aplicación ([RTO en torno a 1 minuto o menos](https://safekit.eviden.com/best-practises/what-is-rpo-and-rto-with-examples/)).
• La HA de aplicaciones requiere definir scripts de reinicio por aplicación y los directorios a replicar (módulos de aplicación SafeKit). | • La HA completa de VM admite fallos de hardware y algunos fallos de software, como una VM bloqueada.
• Reinicio de la VM en caso de fallo y tiempo de recuperación dependiente del reinicio del sistema operativo.
• No requiere scripts de reinicio en la HA completa de VM (módulos de SafeKit 🛠️ [hyperv.safe](https://safekit.eviden.com/quick-install/safekit-quick-installation-guide-with-hyper-v/) o 🛠️ [kvm.safe](https://safekit.eviden.com/quick-install/safekit-quick-installation-guide-with-kvm/)). Los hipervisores funcionan en activo/activo con múltiples máquinas virtuales. [Alta disponibilidad vs. Tolerancia a fallos (Fault Tolerance)](https://safekit.eviden.com/best-practises/high-availability-cluster-vs-fault-tolerant-system/) | • Sin servidor dedicado en SafeKit. Cada [servidor puede actuar como servidor de conmutación por error (failover) del otro](https://safekit.eviden.com/architectures/active-active-cluster-real-time-replication/).
• Fallo de software con reinicio en otro entorno de sistema operativo.
• Actualización progresiva (rolling upgrade) de la aplicación y del SO posible servidor por servidor (las versiones N y N+1 pueden coexistir). | • Servidor secundario dedicado a ejecutar la misma aplicación sincronizada a nivel de instrucción.
• La excepción de software ocurre en ambos servidores al mismo tiempo.
• No es posible realizar actualizaciones progresivas.
• Requiere hardware o hipervisores específicos tolerantes a fallos. [Replicación síncrona vs. Replicación asíncrona](https://safekit.eviden.com/best-practises/synchronous-replication-vs-asynchronous-replication/) | • SafeKit implementa una replicación síncrona en tiempo real sin ninguna pérdida de datos en caso de fallo.
• Requisito previo indispensable para la alta disponibilidad. | • Con la replicación asíncrona, se produce pérdida de datos en caso de fallo.
• No es adecuada para la alta disponibilidad, sino para soluciones de copia de seguridad (backup). [Replicación de archivos a nivel de byte vs. Replicación de disco a nivel de bloque](https://safekit.eviden.com/best-practises/byte-level-file-replication-vs-block-level-disk-replication/) | • SafeKit implementa una replicación de archivos en tiempo real a nivel de byte y se configura fácilmente indicando los directorios de la aplicación a replicar, incluso en el disco del sistema. | • La replicación de disco a nivel de bloque es compleja de configurar y exige ubicar los datos de la aplicación en un disco dedicado. [Heartbeat, Failover y Quórum para evitar 2 nodos maestros](https://safekit.eviden.com/best-practises/heartbeat-failover-quorum-windows-linux-cluster/) | • Para evitar 2 maestros (Split-Brain), SafeKit propone un comprobador de split-brain sencillo que se configura en un router. | • Para evitar 2 maestros, otros clústeres requieren una configuración compleja con un tercer equipo, un disco de quórum dedicado o un enlace de interconexión exclusivo. [Dirección IP virtual: Primaria/Secundaria, balanceo de carga de red, failover](https://safekit.eviden.com/best-practises/how-a-virtual-ip-address-works/) | • En un clúster SafeKit no se necesitan servidores proxy dedicados ni configuraciones de red especiales para las direcciones IP virtuales. | • Se requieren configuraciones de red especiales en otros clústeres para las direcciones IP virtuales (nota: SafeKit ofrece un chequeo de salud adaptado a balanceadores de carga). **En resumen** , la elección arquitectónica entre el clustering por software (como SafeKit) y el clustering por hardware (arquitecturas tradicionales de disco compartido/SAN) tiene un impacto significativo en la complejidad del despliegue, los costes operativos y la eficacia de la recuperación ante fallos. La principal conclusión de esta comparación es la transición hacia arquitecturas shared-nothing y alta disponibilidad (HA) a nivel de aplicación, que priorizan la rápida recuperación de las aplicaciones (bajo RTO) y la flexibilidad de despliegue (incluso entre sitios remotos). Esto suele dar lugar a una solución más sencilla, eficiente y resiliente que las configuraciones de clúster altamente complejas y dependientes del hardware. Para maximizar la continuidad del negocio con una gestión simplificada, es fundamental evaluar un enfoque basado en software.