Consideraciones sobre la continuidad empresarial y la recuperación ante desastres para Red Hat Enterprise Linux en Azure
En este artículo se describe cómo mejorar la continuidad empresarial y la preparación para la recuperación ante desastres (BCDR) para un entorno basado en Red Hat Enterprise Linux (RHEL) en Azure. Se proporcionan recomendaciones que puede usar para admitir cargas de trabajo de RHEL e implementar componentes de administración de plataformas de RHEL. La suscripción de Red Hat Management contiene componentes de plataforma que ayudan a administrar cargas de trabajo en una o varias zonas de aterrizaje de RHEL. Estos componentes ofrecen sus propias configuraciones de BCDR.
Consideraciones de diseño
Implemente las siguientes consideraciones para mejorar la resistencia de las cargas de trabajo de RHEL.
Objetivos de tiempo de recuperación
Un objetivo de tiempo de recuperación (RTO) es la cantidad de tiempo que debe tardar el sistema en recuperarse a su estado original después de un desastre. El RTO incluye el tiempo necesario para:
- Restaurar la funcionalidad mínima de las máquinas virtuales (VM) y las aplicaciones.
- Restaurar los datos que requieren las aplicaciones.
En términos empresariales, el RTO representa la cantidad de tiempo que un proceso de negocio está fuera de servicio. Un RTO bajo es ideal para cargas de trabajo críticas para que los procesos empresariales puedan reanudarse rápidamente. Para aquellas cargas de trabajo de prioridad baja, es posible que un nivel superior de RTO no afecte notablemente al rendimiento de la empresa.
Objetivos de punto de recuperación
Para operar correctamente un entorno en la nube, debe implementar copias de seguridad, replicación o ambos para proteger los datos frente a errores. El objetivo de punto de recuperación (RPO) se refiere a la última vez que se capturaron los datos. Cuando se produce un error en un sistema, solo se puede restaurar al punto de recuperación más reciente.
Mida el RPO desde el punto de recuperación más reciente hasta el momento en que se produzca una interrupción. Si mide el RPO en horas, un error del sistema provoca la pérdida de datos durante las horas transcurridas entre el último punto de recuperación y la interrupción. Si mide el RPO en días, un error del sistema provoca la pérdida de datos durante los días transcurridos entre el último punto de recuperación y la interrupción. En teoría, un RPO de 1 día da lugar a la pérdida de todas las transacciones del día en que se produjo el error.
En el caso de los sistemas de misión crítica, mida el RPO en minutos o segundos para ayudar a evitar la pérdida de ingresos o beneficios. Un RPO corto generalmente da lugar a un aumento de los costes de administración. Para ayudar a reducir estos costes, debe crear una línea base de administración que se centre en el RPO más largo aceptable. A continuación, puede disminuir el RPO de las plataformas o cargas de trabajo específicas que justifiquen una mayor inversión.
Consideraciones sobre el BDCR de la carga de trabajo
Las consideraciones de diseño de alta disponibilidad y recuperación ante desastres para las cargas de trabajo basadas en RHEL dependen de las tecnologías que admiten esas cargas de trabajo. Muchas cargas de trabajo modernas pueden aprovechar los servicios nativos de Azure para proporcionar redundancia entre zonas de disponibilidad y entre regiones. Use los servicios de Azure para administrar la replicación de datos, escalar automáticamente conjuntos de disponibilidad y controlar la actualización y los dominios de error. Estas prácticas facilitan la disponibilidad de las implementaciones de RHEL.
Es posible que las soluciones de base de datos y otras aplicaciones con estado necesiten soluciones centradas en el sistema operativo para proporcionar alta disponibilidad y recuperación ante desastres. Consulte con el desarrollador o el proveedor de aplicaciones para comprobar las soluciones que admiten las aplicaciones. Para más información, consulte Alta disponibilidad y recuperación ante desastres para aplicaciones IaaS.
| Característica o servicio de Azure | Definición | Consideraciones |
|---|---|---|
| Regiones | Un grupo de centros de datos que se encuentran cerca entre sí para proporcionar retrasos de red bajos. Para garantizar una transferencia rápida de datos, una red regional específica conecta los centros de datos. | Al elegir una región de Azure, tenga en cuenta la ubicación de los centros de datos, los usuarios y los datos de back-end. Compruebe la disponibilidad de los servicios que necesita en las regiones que seleccione. En el caso de las implementaciones de RHEL, es posible que tenga una región para empezar y, a continuación, puede agregar más regiones en el futuro con fines de BCDR. |
| Azure ExpressRoute | Un servicio de Azure que puede usar para establecer conexiones privadas desde los centros de datos de Microsoft a su propia infraestructura o a una instalación de colocación. | ExpressRoute omite la red pública de Internet y proporciona una conexión privada dedicada. Esta configuración es un requisito común para las implementaciones de RHEL a gran escala. ExpressRoute es un servicio compartido, por lo que debe planificar cuidadosamente la capacidad de ancho de banda para satisfacer las necesidades generales de ancho de banda de la empresa. Si no tiene ancho de banda suficiente, puede poner en peligro la experiencia del usuario o el acceso a los servicios críticos del centro de datos. Asegúrese de implementar ExpressRoute de forma resistente entre regiones y ubicaciones de emparejamiento. |
| Zonas de disponibilidad | Separe grupos de centros de datos que tengan su propio sistema de alimentación, refrigeración y redes dentro de una región de Azure. Las zonas de disponibilidad proporcionan alta disponibilidad y resistencia a errores del centro de datos. | Para garantizar un acuerdo de alto nivel de servicio (SLA), use zonas de disponibilidad con la infraestructura de RHEL siempre que sea posible. Las zonas de disponibilidad ofrecen redundancia del centro de datos dentro de una región. Pero no todas las regiones tienen zonas de disponibilidad, por lo que debe planificar cuidadosamente. Los servicios de RHEL, como Red Hat OpenShift en Azure y los servicios de administración de zonas de aterrizaje, admiten zonas de disponibilidad. |
| Conjuntos de disponibilidad | Agrupación lógica de máquinas virtuales. Al menos una máquina virtual siempre está en funcionamiento durante eventos de mantenimiento planificados o no planificados. Un dominio de error es un subconjunto de un conjunto de disponibilidad que comparte una infraestructura física común, como energía o red. Al distribuir máquinas virtuales entre distintos dominios de error, un conjunto de disponibilidad reduce el impacto de los errores de hardware en la disponibilidad de la máquina virtual. | Los conjuntos de disponibilidad proporcionan un Acuerdo de Nivel de Servicio elevado. Los conjuntos de disponibilidad son adecuados para una infraestructura de RHEL cuando una región carece de zonas de disponibilidad. Los conjuntos de disponibilidad solo tienen redundancia de hardware, que es similar a las reglas de antiafinidad del hipervisor. Por lo tanto, si sus regiones no tienen zonas de disponibilidad, necesita una estrategia de varias regiones para la redundancia geográfica y del centro de datos. |
| Equilibrador de carga de Azure | Servicio de equilibrio de carga de red. Puede configurar Load Balancer para proporcionar tráfico de red de gran volumen de forma eficaz en varios servidores de Red Hat Enterprise. El servicio funciona con baja latencia y alto rendimiento, lo que mejora el rendimiento y la disponibilidad de las aplicaciones. Load Balancer se puede escalar automáticamente según la demanda. Para promover una implementación híbrida de las aplicaciones, Load Balancer puede distribuir el tráfico de red entre varias regiones de Azure y también entre entornos locales y Azure. |
Load Balancer distribuye el tráfico de red entre varios servidores para proporcionar disponibilidad ininterrumpida de la aplicación y evitar errores de punto único. Si se produce un desastre, Load Balancer redirige el tráfico a los servidores operativos para proporcionar una rápida conmutación por error y recuperación. Esta operación minimiza el tiempo de inactividad y mantiene las operaciones empresariales. Load Balancer puede equilibrar el tráfico entre los servidores locales a la nube de Azure o a los servidores de varias regiones de Azure. Para obtener más información, consulte Opciones de equilibrio de carga. |
| Discos administrados | Discos virtualizados que Azure administra. Elija el tamaño y el tipo de disco. Azure distribuye discos en varias unidades de almacenamiento para proteger los datos frente a errores de hardware. | Los discos administrados son la mejor opción para toda la infraestructura de RHEL. No use discos no administrados. Para obtener más información, consulte SLA para máquinas virtuales. Los distintos tipos de discos tienen diferentes costes y rendimiento. Para las máquinas de infraestructura de RHEL se recomienda SSD Premium de Azure. Considere el coste, el rendimiento y la disponibilidad al elegir el tipo de disco. Al desasignar un sistema, se quitan los discos SSD locales y efímeros. Realice una copia de seguridad de los datos en estos discos según corresponda. |
| Azure Backup | Servicio que proporciona soluciones rentables para realizar copias de seguridad de los datos y recuperarlos desde la nube de Azure. | La copia de seguridad es una solución confiable y rentable que protege la infraestructura de RHEL frente a errores o daños de máquina virtual. Use Backup para restaurar fácilmente toda la máquina virtual o archivos y carpetas específicos desde la nube, sin tener que volver a crear la máquina virtual ni perder ningún dato. También puede usar otras soluciones de asociados compatibles. |
| Azure Arc | Plataforma que amplía los servicios de Azure para que se ejecuten en diversos entornos, incluidos los centros de datos, los dispositivos perimetrales y las arquitecturas multinube. Use Azure Arc para proporcionar un desarrollo, operaciones y administración de seguridad coherentes para aplicaciones y servicios. | Use Azure Arc para implementar copias de seguridad y supervisión automatizadas y centralizadas, lo que aumenta la resistencia desde una perspectiva de BCDR. |
| Azure Site Recovery | Servicio que proporciona funcionalidades de recuperación ante desastres para garantizar la continuidad empresarial. Puede replicar y administrar cargas de trabajo, incluidas las máquinas virtuales de Azure y las máquinas virtuales locales, en distintas regiones. Con Site Recovery puede configurar los procesos de replicación, conmutación por error y recuperación para salvaguardar las aplicaciones durante las interrupciones planificadas e imprevistas. | Use Site Recovery para minimizar los problemas de recuperación, reducir los costes de infraestructura y garantizar una recuperación segura y confiable entre regiones de Azure o desde ubicaciones locales a Azure. |
| Bloqueos de recursos | Característica de Azure que puede usar para restringir usuarios y roles en su organización. Proteja los recursos críticos frente a cambios accidentales o malintencionados. Puede bloquear un recurso en varios niveles de ámbito, como la suscripción, el grupo de recursos o los niveles de recursos individuales. Según el tipo de bloqueo, puede impedir que los usuarios eliminen o modifiquen un recurso, pero pueden seguir leyendo su configuración. | Para proteger todas las máquinas virtuales de la infraestructura de RHEL y las imágenes base, use bloqueos de recursos. Para evitar la pérdida accidental de máquinas importantes, aplique el bloqueo Delete como mínimo. Aplique el bloqueo ReadOnly a las máquinas de infraestructura de RHEL, ya que no suelen cambiar. Realice cambios solo durante las ventanas de control de cambios adecuadas. |
Consideraciones de BCDR para la plataforma de RHEL
Para obtener más información sobre las funcionalidades de BCDR para una infraestructura de plataforma RHEL, consulte:
- Arquitectura de alta disponibilidad de Satellite.
- Arquitectura de alta disponibilidad de Ansible Automation Platform.
- Arquitectura de alta disponibilidad de administración de identidades.
Recomendaciones de diseño
En el caso de las aplicaciones nativas de la nube en contenedores de Linux, use una plataforma basada en Kubernetes para garantizar la escalabilidad, la alta disponibilidad y la redundancia. Considere la posibilidad de usar la plataforma Red Hat OpenShift en Azure o una implementación autoadministrada de OpenShift con almacenamiento replicado o con replicación geográfica.
Para front-end de aplicaciones web nativas y aplicaciones sin estado, puede usar muchos de los servicios nativos de Azure que proporcionan disponibilidad de la aplicación. Para ver las arquitecturas que usan estos servicios, consulte:
- Aplicación web redundante por zonas de alta disponibilidad de línea de base.
- Aplicación web de varias regiones de alta disponibilidad.
Las arquitecturas anteriores usan varios servicios de Azure para zonas de disponibilidad. La arquitectura multiregión usa características de replicación geográfica para contenido y Azure Front Door como servicio de equilibrio de carga.
Para muchas aplicaciones con estado tradicionales que requieren alta disponibilidad, RHEL ofrece el complemento de alta disponibilidad Pacemaker. Puede obtener sistemas que tengan esta característica desde Azure Marketplace o puede implementar una imagen personalizada con los componentes de software necesarios insertados. Para obtener más información, consulte Configuración de un clúster de alta disponibilidad de Red Hat en Microsoft Azure.
Los problemas de disponibilidad afectan a las interrupciones del servicio y a los tiempos de respuesta del servicio. Puede producirse una degradación del servicio, lo que puede degradar la experiencia de servicio del cliente. Para asegurarse de mantener los niveles de rendimiento y la capacidad suficiente dentro de las regiones necesarias, use la característica de reserva de capacidad a petición de Azure.
Confiabilidad
Muchos de los conceptos que se aplican a las infraestructuras de máquina virtual de servicio como servicio también se aplican a las arquitecturas de RHEL. Para obtener más información, consulte Principios de diseño de confiabilidad.
Clústeres
Azure no admite la combinación de Application Server Central Services y la alta disponibilidad de bases de datos dentro de un único clúster de RHEL Pacemaker. Para solucionar esta limitación, sepárelos en clústeres individuales. Puede combinar hasta cinco clústeres de servicios centrales en un par de máquinas virtuales.
Para BCDR en SAP, considere los siguientes servicios para ejecutar clústeres de servicios centrales de SAP:
- Clúster de RHEL Pacemaker: no se admiten dispositivos de bloque STONITH, pero puede confiar en el agente de barrera de Azure.
- Software de clúster no certificado por SAP: explore esta opción si se ajusta a sus requisitos.
Elija el servicio adecuado en función de sus necesidades específicas y su sistema operativo.
Para más información, vea:
- Configuración de un clúster de alta disponibilidad de Red Hat en Microsoft Azure para RHEL 9.
- Configuración y administración de clústeres de alta disponibilidad para RHEL 9.
- Documentación de RHEL 8
Réplicas de Azure Compute Gallery
Puede usar Compute Gallery para almacenar imágenes base para las implementaciones. Use estas imágenes para la recuperación ante desastres de aplicaciones y herramientas. Compute Gallery puede usar recursos de alta disponibilidad con cuentas de almacenamiento con redundancia de zona (ZRS) en las regiones donde se admiten zonas de disponibilidad. ZRS ofrece resistencia a errores de zona. También puede replicar imágenes de la galería en otras regiones o zonas geográficas.
Nota:
Se recomienda tener al menos dos galerías en regiones diferentes.
Recuperación de sitios
Site Recovery puede mejorar la resistencia de algunos componentes de RHEL. Para obtener una lista de los servidores de recuperación de sitios de RHEL admitidos, consulte Matriz de compatibilidad para la recuperación ante desastres de máquinas virtuales de Azure con Site Recovery. También puede configurar Site Recovery como conmutación por error desde entornos locales a la nube. Para obtener una estimación de los costes de Site Recovery, use Site Recovery Deployment Planner.
Nodos de clúster de recuperación
Para reducir los RTO y aumentar la resistencia, puede usar nodos de clúster de recuperación remota activos o en espera. Debe configurar manualmente los elementos del clúster de recuperación ante desastres. Por ejemplo, debe aplicar configuraciones para configurar recursos y copiar datos.