Editar

Compartir a través de

Implementación de aplicaciones web mediante Red Hat OpenShift en Azure con redundancia de zona

Red Hat OpenShift en Azure
Azure Cosmos DB
Azure Front Door

En este artículo se proporciona información general completa sobre una carga de trabajo de aplicación web en Red Hat OpenShift en Azure en una configuración con redundancia de zona. Los servicios con redundancia de zona replican los servicios y datos en todas las zonas de disponibilidad para protegerse frente a puntos únicos puntos de error y proporcionar alta disponibilidad .

Antes de crear un entorno de producción con Red Hat OpenShift en Azure, lea Acelerador de zonas de aterrizaje de Red Hat OpenShift en Azure.

Architecture

Diagrama de la arquitectura de una aplicación web con alta disponibilidad.

Descargue un archivo Visio de esta arquitectura.

Flujo de trabajo

  • Un usuario envía una solicitud a Azure.
  • Azure Front Door recibe la solicitud y enruta la solicitud a una aplicación web hospedada en Red Hat OpenShift en Azure.
  • La aplicación web ejecuta la solicitud mediante Azure Key Vault, Azure Cosmos DB y Azure Container Registry.
  • La aplicación web devuelve una respuesta al usuario.

Componentes

  • Microsoft Entra ID o Azure AD B2C autentica a los usuarios. En esta arquitectura, microsoft Entra ID proporciona acceso seguro y granular a los recursos externos.
  • Azure Front Door es la interfaz pública de todas las solicitudes de Internet. Actúa como un proxy inverso HTTP global y una memoria caché para los servicios back-end. Azure Front Door mejora la seguridad y el rendimiento de esta arquitectura, como agregar protección frente a ataques de denegación de servicio distribuido (DDoS) de nivel 4.
  • Red Hat OpenShift en Azure es el orquestador de contenedores basado en Kubernetes que hospeda las aplicaciones y servicios de API y proporciona una interfaz para los servicios back-end. Red Hat OpenShift en Azure actúa como plataforma de proceso principal en esta arquitectura.
  • Container Registry admite imágenes de contenedor compatibles con Docker y Open Container Initiative (OCI). Container Registry admite redundancia de zona, lo que hace que sea altamente disponible y resistente al error de zona. También admite la replicación geográfica, que replica el servicio en varias regiones. En esta arquitectura, Container Registry proporciona acceso privado del clúster de ARO a imágenes de contenedor administradas localmente que forman parte de la carga de trabajo.
  • Red Hat OpenShift en Azure usa la integración de red virtual para conectarse a servicios back-end a través de una red virtual privada. La integración de red virtual proporciona una red segura con Red Hat OpenShift de Azure y otros servicios de Azure en esta arquitectura.
  • Azure Cosmos DB proporciona bases de datos de documentos NoSQL para los servicios de aplicaciones front-end. La carga de trabajo de esta arquitectura usa Azure Cosmos DB para almacenar datos de usuario.
  • Los puntos de conexión privados permiten conexiones a servicios de PaaS de Azure desde redes virtuales privadas y permiten deshabilitar los puntos de conexión públicos en estos servicios. En esta arquitectura, los puntos de conexión privados con integración de red virtual mantienen el tráfico de red de Red Hat OpenShift privado de Azure mientras se comunican con los servicios PaaS.
  • El DNS privado de Azure configura y actualiza los registros DNS que necesitan los servicios de puntos de conexión privados. En esta arquitectura, Azure DNS privado se usa para la resolución de nombres en redes privadas.
  • La Key Vault almacena de manera segura secretos y certificados a los que acceden los servicios de Azure. En esta arquitectura, Azure Key Vault almacena de forma segura secretos para las aplicaciones que se ejecutan en Red Hat OpenShift en Azure.
  • Azure Monitor y Application Insights recopilan registros de servicio y métricas de rendimiento de aplicaciones para la observabilidad. En esta arquitectura, Azure Monitor es la sincronización de registros para los registros de plataforma y carga de trabajo. Application Insights está específicamente para registros y métricas que se originan en el código de carga de trabajo.

Alternativas

  • Se recomienda el DNS administrado por Azure, pero puede usar su propio proveedor de DNS.
  • Debe usar App de Azure lication Gateway en lugar de Azure Front Door si la mayoría de los usuarios se encuentran cerca de la región de Azure que hospeda la carga de trabajo y si no necesita almacenamiento en caché de contenido. Use Azure DDoS Protection para proteger los servicios de Application Gateway accesibles desde Internet.
  • Implemente una instancia premium de Azure API Management con redundancia de zona como alternativa para hospedar API de front-end, API de back-end o ambas. Para más información sobre la redundancia de zona de API Management, consulte Migración de Azure API Management a la compatibilidad con zonas de disponibilidad.
  • Puede usar OpenShift Container Platform (OCP) o Distribución de la comunidad de origen de Kubernetes (OKD) en Azure Virtual Machines en lugar de Red Hat OpenShift en Azure. OCP o OKD son alternativas de infraestructura como servicio (IaaS) a un servicio totalmente administrado por la plataforma, como Red Hat OpenShift en Azure. Debe usar Azure Virtual Machine Scale Sets para la redundancia de zona. Para más información, consulte Red Hat OpenShift en Azure.

Detalles del escenario

Esta arquitectura muestra cómo crear servicios con redundancia de zona en una solución que proporciona alta disponibilidad y es resistente a errores de zona.

Las zonas de disponibilidad son ubicaciones físicas independientes dentro de una región de Azure. Las zonas de disponibilidad distribuyen una solución en varias zonas independientes dentro de una región, lo que permite que una aplicación siga funcionando cuando se produce un error en una zona. Esta arquitectura se basa en la infraestructura de zonas de disponibilidad que se encuentra en muchas regiones. Para obtener una lista de regiones que admiten zonas de disponibilidad de Azure, consulte Regiones de Azure con zonas de disponibilidad.

Cuando las plataformas de hospedaje están a escala, a menudo es difícil mantenerlos con alta disponibilidad. Tradicionalmente, la alta disponibilidad ha requerido implementaciones complejas y costosas de varias regiones, con compensaciones entre la coherencia de los datos y el alto rendimiento. Las zonas de disponibilidad resuelven muchos de estos problemas. La mayoría de los servicios estándar de Azure y muchos servicios especializados de Azure proporcionan compatibilidad con zonas de disponibilidad. Todos los servicios de Azure de esta arquitectura tienen redundancia de zona, lo que simplifica la implementación y la administración. Para obtener más información, consulte Servicios de Azure compatibles con zonas de disponibilidad.

Para mantener los contratos de nivel de servicio (SLA), Red Hat OpenShift en Azure con redundancia de zona administra y mitiga los errores, incluidos los errores de zona. La redundancia de zona proporciona un tiempo de recuperación de cero para el error de zona. Si una sola zona de una región no está disponible, no pierde ningún dato y la carga de trabajo continúa ejecutándose. La redundancia de zona se configura en el momento de la implementación y los servicios la administran, por lo que no es necesario administrar el anclaje ni las implementaciones de zonas.

En esta arquitectura, un clúster de Red Hat OpenShift en Azure se implementa en tres zonas de disponibilidad en regiones de Azure que las admiten. Un clúster consta de tres nodos de plano de control y tres o más nodos de trabajo. Para mejorar la redundancia, los nodos se distribuyen entre las zonas.

Azure Front Door, Microsoft Entra ID y Azure DNS son servicios disponibles globalmente que son resistentes a interrupciones en zonas y regiones. Todos los demás servicios de esta arquitectura tienen redundancia de zona.

Posibles casos de uso

Red Hat OpenShift en Azure es un servicio de orquestación de contenedores que usa Kubernetes. Es adecuado para muchos casos de uso, como:

  • Banca
  • Trading de acciones
  • Comercio electrónico
  • Redes sociales
  • Aplicaciones web
  • Aplicaciones móviles
  • Aplicaciones de procesamiento por lotes
  • Streaming multimedia
  • Cargas de trabajo de Machine Learning

Recomendaciones

Las siguientes recomendaciones aplican para la mayoría de los escenarios.

Azure Front Door

  • Use certificados administrados de Azure en todas las aplicaciones front-end para evitar problemas de configuración y expiración de certificados.
  • Para mejorar la disponibilidad, habilite el almacenamiento en caché en las rutas. La caché de Azure Front Door distribuye el contenido dinámico, así como el contenido estático a los nodos perimetrales de punto de presencia (POP) de Azure. El almacenamiento en caché reduce la carga en los servidores de origen y mejora el rendimiento.
  • Implemente Azure Front Door Premium y configure una directiva de firewall de aplicaciones web (WAF) con un conjunto de reglas administrado por Microsoft. Aplique la directiva a todos los dominios personalizados. Use el modo de prevención para mitigar los ataques web que pueden causar un fallo del servicio de origen.

Red Hat OpenShift en Azure

  • Asegúrese de que la región de Azure donde se implementa Red Hat OpenShift en Azure admite zonas de disponibilidad. Para más información, consulte Regiones de Azure con compatibilidad con zonas de disponibilidad.
  • Un clúster de Red Hat OpenShift en Azure depende de algunos servicios. Asegúrese de que esos servicios admiten y están configurados para la redundancia de zona. Para más información, consulte Servicios de Azure con compatibilidad con zonas de disponibilidad.
  • Quite el estado de los contenedores y, en su lugar, use Azure Storage o los servicios de base de datos.
  • Configure varias réplicas en implementaciones con la configuración de presupuesto de interrupciones adecuada para proporcionar continuamente el servicio de aplicaciones a pesar de las interrupciones, como los errores de hardware en las zonas.
  • Proteger el acceso a Red Hat OpenShift en Azure. Para asegurarse de que las solicitudes no pueden omitir el WAF de Azure Front Door, permita solo el tráfico de Azure Front Door. Para más información sobre cómo restringir el acceso a una instancia específica de Azure Front Door, consulte Protección del acceso a Red Hat OpenShift en Azure con Azure Front Door.

Container Registry

Para más información, consulte Habilitación de la redundancia de zona en Container Registry para lograr resistencia y alta disponibilidad y Uso de Container Registry con Red Hat OpenShift en Azure.

Azure Cosmos DB

Key Vault

Key Vault tiene redundancia de zona en cualquier región en la que estén disponibles las zonas de disponibilidad. En esta arquitectura, Key Vault se implementa con un punto de conexión privado habilitado y un punto de conexión público deshabilitado. Para obtener información sobre puntos de conexión privados para Key Vault, consulte Integración de Key Vault con Private Link.

Zonas DNS privadas de Azure

Para simplificar la administración de DNS, integre puntos de conexión privados con Azure DNS Private Zones. Para más información, consulte Configuración de DNS para puntos de conexión privados de Azure.

Consideraciones

Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para obtener más información, consulte Marco de buena arquitectura de Azure.

Confiabilidad

La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para más información, consulte Resumen del pilar de fiabilidad.

Esta arquitectura garantiza la confiabilidad al proporcionar características de servicio globales confiables, resistentes y disponibles.

Disponibilidad

Cuando se implementa correctamente la infraestructura de zona de disponibilidad, esta arquitectura proporciona una excelente disponibilidad con un costo y una sobrecarga operativa menores que otras soluciones. Esta arquitectura mitiga el riesgo de un error de zona en una región de Azure porque los servicios con redundancia de zona resisten el error mientras siguen funcionando dentro del Acuerdo de Nivel de Servicio definido.

Es poco probable que se produzcan errores de regiones, pero puede ocurrir. En los errores de región los servicios no están disponibles en todas las zonas de disponibilidad de una región. Combine esta arquitectura con redundancia de zona con una arquitectura de varias regiones para mitigar el riesgo de error de región. Planee la arquitectura de varias regiones a fin de reducir el tiempo de recuperación en el supuesto de que una región completa no está disponible.

Los diseños de varias regiones son más complejos y, a menudo, más caros que los diseños de varias zonas dentro de una sola región, pero brindan la oportunidad de optimizar aún más la disponibilidad y la confiabilidad general.

Nota:

Realice una evaluación de riesgos para determinar si la solución requiere una arquitectura de varias regiones.

Resistencia

Los diseños de varias zonas que se basan en zonas de disponibilidad ofrecen disponibilidad y resistencia que cumple o supera los requisitos empresariales de la mayoría de las organizaciones. Pero si quiere replicar datos en una región secundaria para la recuperación ante desastres, las opciones dependen de los servicios de Azure que use.

Por ejemplo, Azure Storage admite la replicación de objetos para blobs en bloques. Los servicios de datos de Azure, como Azure Cosmos DB, ofrecen replicación de datos en otras regiones de Azure con copia de seguridad continua. Puede usar estas características para restaurar la solución si se produce un desastre. Para obtener más información, consulte Copia de seguridad continua con la característica de restauración a un momento dado de Azure Cosmos DB.

Servicios globales

Los errores en los servicios globales, como Azure Front Door y Microsoft Entra ID, son poco frecuentes, pero el efecto de un error puede ser alto. Para mejorar la recuperación si se produce un error, prepare y ensaye runbooks.

Por ejemplo, puede reducir el tiempo de inactividad de Azure Front Door mediante un runbook para implementar Azure Application Gateway y cambiar los registros DNS para redirigir el tráfico hasta que se restaure Azure Front Door.

Para obtener más información, consulte Creación de resistencia en la infraestructura de administración de identidades y acceso.

Seguridad

La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.

  • Considere la posibilidad de implementar un clúster privado.
  • Use puntos de conexión privados en los servicios de Azure a los que no se accede desde la red pública de Internet.
  • Toda la comunicación entre servicios en Azure está cifrada con TLS (seguridad de la capa de transporte) de manera predeterminada. Configure Azure Front Door para que acepte solo el tráfico HTTPS y establezca la versión mínima de TLS.
  • Las identidades administradas autentican la comunicación entre servicios de Azure donde está disponible. Para obtener más información, consulte ¿Qué son las identidades administradas para recursos de Azure?
  • Para administrar y proteger secretos, certificados y cadena de conexión en el clúster, conecte el clúster de Red Hat OpenShift de Azure a Kubernetes habilitado para Azure Arc. Use la extensión del proveedor de secretos de Key Vault para recuperar secretos.
  • Configure Microsoft Defender para contenedores para proporcionar seguridad para clústeres, contenedores y aplicaciones. Defender para contenedores se admite a través de Kubernetes habilitado para Azure Arc. Examine las imágenes en busca de vulnerabilidades con Microsoft Defender o cualquier otra solución de análisis de imágenes.
  • Configure la integración de Microsoft Entra para usar el identificador de Microsoft Entra para autenticar a los usuarios (por ejemplo, SRE, SecOps o desarrolladores de aplicaciones) en el clúster de Red Hat OpenShift de Azure.

Optimización de costos

La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.

Las arquitecturas con redundancia de zona son menos costosas que las alternativas de varias regiones, ya que los servicios se implementan en una sola región. Pero hay varios costos asociados que se deben conocer:

  • Algunos servicios requieren que se implemente un número mínimo de instancias o réplicas para lograr redundancia de zona.
  • El almacenamiento con redundancia de zona (ZRS) y el almacenamiento con redundancia local (LRS) tienen precios diferentes. Para obtener más información, consulte Precios de Storage.
  • Los puntos de conexión privados están disponibles principalmente en las SKU de servicio de Azure Premium. Los puntos de conexión privados incurren en cargos por hora y ancho de banda. Para obtener más información, consulte Precios de Private Link.

Optimice los costos reservando recursos de antemano. Varios servicios de esta arquitectura son aptos para los precios de capacidad reservada. Para más información, consulte Reservations.

Puede usar la calculadora de precios de Azure para calcular los costos.

Excelencia operativa

La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para más información, consulte Introducción al pilar de excelencia operativa.

Todos los servicios PaaS (plataforma como servicio) de Azure se integran con Azure Monitor. Siga los procedimientos recomendados de Azure Monitor (confiabilidad, seguridad, optimización de costos, excelencia operativa y eficiencia del rendimiento) para:

  • Cree un modelo de mantenimiento para cuantificar el estado de la aplicación en el contexto de los requisitos empresariales.
  • Configure la cantidad correcta de recopilación de datos de registro.
  • Cree paneles de Azure para unificar los datos en una sola vista para los equipos de operaciones.
  • Cree una estrategia de alertas correcta.
  • Integre Application Insights en aplicaciones para realizar un seguimiento de las métricas de rendimiento de las aplicaciones.
  • Para proporcionar notificaciones cuando se necesite una acción directa, use un sistema de alertas, como alertas de métricas de Container Insights o la interfaz de usuario de alertas de Red Hat OpenShift en Azure.
  • Tenga en cuenta varios métodos para supervisar y registrar Red Hat OpenShift en Azure para obtener información sobre el estado de los recursos y prever posibles problemas.
  • Revise la matriz de responsabilidades de Red Hat OpenShift en Azure para comprender cómo se comparten las responsabilidades de los clústeres entre Microsoft, Red Hat y los clientes.
  • Automatice las implementaciones de servicio con Bicep, un lenguaje de plantilla para implementar infraestructura como código (IaC). Dado que los servicios de Azure de esta arquitectura tienen puntos de conexión privados, no puede usar agentes hospedados por Microsoft de Azure Pipelines ni ejecutores hospedados en GitHub. Use soluciones como agentes autohospedados de Azure Pipelines o ejecutores hospedados en GitHub en su lugar.
  • Valide continuamente la carga de trabajo para probar el rendimiento y la resistencia de toda la solución mediante servicios como Azure Load Testing y Azure Chaos Studio.

Eficiencia del rendimiento

La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan ejercido sobre ella. Para más información, consulte Información general sobre el pilar de eficiencia del rendimiento.

  • Recursos en caché de Azure Front Door para distribuir cargas de trabajo a ubicaciones perimetrales.
  • Revise los límites y las cuotas de la suscripción para garantizar que los servicios se adapten a la demanda.
  • Supervise el rendimiento de las aplicaciones mediante Application Insights.
  • Cargas de trabajo de pruebas de rendimiento para medir cualquier latencia que causan las conexiones entre zonas.
  • Elija tamaños de máquina virtual adecuados para la carga de trabajo. Escoja un tamaño lo suficientemente grande como para obtener las ventajas de aumentar la densidad, pero no tan grande como para que el clúster no pueda controlar la carga de trabajo de un nodo con errores.
  • Use las solicitudes y los límites de pod para administrar los recursos de proceso dentro de un clúster. Las solicitudes y los límites de pod informan al programador de Kubernetes sobre los recursos de proceso que se asignan un pod. Restrinja el consumo de recursos en un proyecto mediante intervalos de límite.
  • Defina las solicitudes y límites de recursos de pod en los manifiestos de implementación de aplicaciones y aplíquelos con Azure Policy.
  • Optimice los valores de solicitud de CPU y memoria y maximice la eficacia de los recursos del clúster mediante el escalador automático de pods vertical.
  • Escale pods para satisfacer la demanda mediante el escalador automático horizontal de pods.
  • Defina ClusterAutoScaler y MachineAutoScaler para escalar máquinas cuando el clúster se queda sin recursos para admitir más implementaciones.

Implementación de este escenario

Para implementar esta arquitectura, consulte el acelerador de zonas de aterrizaje de Red Hat OpenShift en Azure y el repositorio de GitHub asociado.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

Otros colaboradores:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes