Arquitectura de referencia: entrega de aplicaciones basadas en microservicios con Citrix y Red Hat OpenShift

Información general

CompanyA siempre ha utilizado arquitecturas monolíticas para desarrollar aplicaciones de sistema alojadas predominantemente en las instalaciones. Han sufrido problemas con el tiempo de actividad y el rendimiento inconsistente, especialmente para los usuarios remotos, que se agravaron durante la pandemia. Como parte de su esfuerzo por migrar a la nube, tienen la intención de utilizar una arquitectura de microservicios. Esta arquitectura les permite desarrollar nuevas aplicaciones con mayor resiliencia y escalabilidad.

CompanyA decidió crear un par de clústeres Red Hat OpenShift (RHOS) multinube redundantes. Están alojados en Microsoft Azure y Amazon AWS, y Citrix proporciona equilibrio de carga para las instancias de microservicios. Esto les permite proporcionar un entorno resiliente para que los usuarios remotos accedan a servicios web empresariales críticos con un buen rendimiento constante.

Esta arquitectura de referencia explica cómo CompanyA planifica su entorno para alojar una plataforma nativa de la nube, desarrollar nuevas aplicaciones o migrar aplicaciones heredadas.

Introducción

La empresa A decidió desarrollar su entrega de aplicaciones basadas en microservicios nativos de la nube con Citrix y RHOS para aportar varios beneficios a su empresa y, en última instancia, aumentar la productividad.

Nativo de nube

Las aplicaciones nativas de la nube se desarrollan para aprovechar la naturaleza distribuida y escalable de la nube. Incluye muchos beneficios en torno a la productividad empresarial, la eficiencia operativa y la experiencia del usuario.

Beneficios de la nube nativa

  • Las aplicaciones en contenedores son portátiles entre infraestructuras de host
  • Permite el desarrollo y la entrega ágiles y continuos
  • Escala con infraestructuras de host de nube
  • Admite un proceso de desarrollo de software eficiente

Red Hat OpenShift

Red Hat OpenShift es una plataforma empresarial de contenedores de Kubernetes que ayuda a las empresas a implementar, operar y proteger aplicaciones de microservicios en nubes híbridas.

Beneficios de Red Hat OpenShift (RHOS)

  • Administra de manera eficiente los entornos nativos de la nube de Kubernetes para el desarrollo y la operación de aplicaciones empresariales críticas para el negocio
  • Mejora la productividad de los equipos de desarrollo
  • Aumenta los ingresos mediante la introducción rápida de nuevos servicios a los clientes existentes
  • Reduce los gastos operativos al dedicar menos tiempo a la administración y el soporte

Para obtener más información, consulte ¿Qué es Red Hat OpenShift?

Citrix

Citrix proporciona topologías flexibles para la administración del tráfico en entornos de microservicios, según los requisitos, incluidos Full Mesh, ServiceMesh Lite, Single-Tier y Dual-Tier.

Topologías:

  • Malla completa: los clústeres de malla completa incluyen soporte para varios microservicios que necesitan comunicación este-oeste entre los microservicios dentro del clúster y comunicación norte-sur (N-S) fuera del clúster.
  • Service Mesh Lite: una solución de Ingress que normalmente realiza funciones de proxy L7 para el tráfico norte-sur. La arquitectura Service Mesh lite utiliza la misma solución de Ingress para administrar el tráfico este-oeste (E-W) y superar las limitaciones del servicio integrado de Kubernetes.
  • Nivel único: los clústeres de un solo nivel contienen microservicios que se ejecutan como réplicas redundantes y tienen tráfico de norte a sur proporcionado por balanceadores de carga externos.
  • Las arquitecturas de doble nivel y de doble nivel también tienen tráfico norte-sur proporcionado por balanceadores de carga externos. Sin embargo, los microservicios también tienen un componente de red adjunto para admitir la comunicación mediante protocolos de red adicionales y optimizaciones que no proporcionan los servicios de clúster nativos.

Para obtener más información, consulte: Cómo acelerar su transición a las aplicaciones basadas en microservicios

Beneficios de Citrix Ingress Controller (CIC)

  • Las soluciones de Kubernetes Ingress estándar proporcionan equilibrio de carga solo en la capa 7 (tráfico HTTP o HTTPS), mientras que el CIC también admite el tráfico TCP, TCP-SSL y UDP
  • El CIC funciona sin problemas en múltiples nubes o centros de datos en las instalaciones

Beneficios de Citrix ADC VPX

  • Citrix ADC VPX proporciona directivas de administración de tráfico de nivel empresarial, como directivas de reescritura y respuesta, para equilibrar de manera eficiente la carga del tráfico en la capa 7, lo que Kubernetes no proporciona
  • Citrix ADC VPX también admite el balanceo de carga de servidor global (GSLB)

Beneficios de Citrix CPX

  • Citrix CPX permite que un Citrix ADC se implemente como proxy del plano de datos, ya sea como una puerta de enlace de Ingress o como sidecar en la malla de servicios basada en xDS.
  • Proporciona administración del tráfico de capa 7 entre microservicios dentro del clúster de Kubernetes, mientras que Kubernetes solo admite la capa 4.

Para obtener más información, consulte Citrix Developer Docs

Criterios

La empresa A ha definido una lista de criterios de éxito que formaron la base del diseño general.

Nota: La empresa A implementa un servicio web Apache en un piloto de producción para la validación remota de usuarios.

Criterios

Arquitectura Conceptual

Sobre la base de los requisitos anteriores, CompanyA creó la siguiente arquitectura conceptual de alto nivel. Esta arquitectura cumple con todos los requisitos iniciales y proporciona a CompanyA la base para expandirse a más casos de uso en el futuro.

Arquitectura Conceptual

El marco de arquitectura se divide en varias capas. El marco proporciona una base para comprender la arquitectura técnica de la infraestructura de microservicios. Todas las capas fluyen juntas para crear una solución completa de extremo a extremo.

A un alto nivel:

Capa de usuarios: La capa de usuarios describe el entorno del usuario final y los dispositivos de punto final que se utilizan para conectarse a los recursos.

Los usuarios pueden conectarse al servicio web de forma segura mediante la aplicación Citrix Workspace. Como alternativa, los usuarios pueden conectarse al servicio web mediante un explorador estándar con transporte HTTP/HTTPS.

Capa de acceso: la capa de acceso describe cómo los usuarios acceden a los servicios web y se entregan los flujos norte-sur.

  • El FQDN principal del servicio web se resuelve en servidores de nombres alojados en Citrix ADC VPX.
  • Las VPX de Citrix ADC que ejecutan GSLB responden a las consultas del Servicio de nombres de dominio (DNS) con una dirección IP pública del servidor virtual de Content Switch con la menor cantidad de conexiones.
  • El servidor virtual está configurado por Citrix Ingress Controller para reenviar conexiones al clúster alojado en Citrix CPX con la menor cantidad de conexiones.
  • El Citrix CPX alojado en clústeres acepta las conexiones y responde al Citrix ADC VPX. Establece un flujo al servicio web a través del cual se entrega la carga útil.

Capa de recursos: la capa de recursos especifica las aplicaciones que se entregan a los usuarios en forma de microservicios en esta arquitectura de referencia.

  • Cuatro servicios web de Apache se alojan como pods de RHOS. Se implementan a través del centro de operadores de RHOS.

Capa de control: la capa de control define cómo se administran y supervisan los recursos.

  • Red Hat OpenShift se utiliza para crear el clúster e implementar, administrar y supervisar los recursos de microservicios.

Capa de host: la capa de alojamiento define la infraestructura subyacente que aloja los recursos, incluidos la memoria, el almacenamiento y el procesamiento.

  • Microsoft Azure y Amazon AWS son la IaaS pública que se utiliza para alojar el clúster y los microservicios de RHOS.

En las siguientes secciones se proporcionan más detalles sobre las decisiones de diseño específicas para la entrega de aplicaciones basadas en microservicios de la empresa con Citrix y Red Hat OpenShift.

Capa de usuarios

La capa de usuarios es donde los usuarios solicitan y acceden a los recursos de destino en los dispositivos de punto final compatibles.

Capa de usuarios

Los usuarios pueden conectarse al servicio web de forma segura mediante la aplicación Citrix Workspace.

  • Citrix Workspace: el servicio web se publica como una aplicación en Citrix Workspace. La aplicación Citrix Workspace instalada en el punto final del usuario inicia una conexión proxy a la aplicación publicada en Citrix Cloud
  • Citrix Secure Internet Access: la conexión con el Citrix ADC VPX alojado en la nube recibe proxy de Citrix Secure Internet Access para una inspección completa de la pila, incluidos SWG, DLP, CASB y NGFW
  • Protección de API y aplicaciones web de Citrix: las firmas de firewall de aplicaciones web de Citrix Application and API Protection controlan mediante proxy la conexión al Citrix ADC VPX alojado en la nube.

Capa de acceso

La capa de acceso es donde se alojan los componentes de entrega de red para coordinar y dirigir las solicitudes de sesiones de usuario a los componentes de control y recursos.

Información general

Citrix CPX

CompanyA decidió implementar una arquitectura de 2 niveles y usar Citrix CPX para administrar la entrega del tráfico de servicio dentro del clúster. El CPX recibe solicitudes de tráfico de usuarios del Citrix ADC VPX alojado en la nube y equilibra la carga de tráfico entre las instancias de microservicios. El administrador del clúster implementa Citrix CPX mediante la configuración de archivos YAML mediante controles RHOS. Citrix CPX se implementa en los clústeres de AWS y Azure de la misma manera.

Controlador de entrada de Citrix

CompanyA decidió usar Citrix Ingress Controller (CIC) para administrar las redes nativas de la nube de Citrix dentro de su clúster RHOS. Citrix Ingress Controller se utiliza para administrar el flujo de tráfico del clúster de entrada. Utiliza dominios de recursos personalizados (CRD) de clústeres globales para obtener y supervisar el estado de los servicios y CPX de Citrix. En función de esta información, configura dinámicamente Citrix ADC VPX para equilibrar la carga y redirigir el tráfico a los Citrix CPX dentro del clúster.

Citrix ADC VPX

CompanyA decidió usar Citrix ADC VPX para administrar sus flujos de tráfico Norte-Sur e implementar el balanceo de carga de servidor global (GSLB) entre los clústeres de Azure y AWS.

El tráficonorte-sur lo administran las VPX de Citrix ADC alojadas en los sitios de clústeres de AWS y Azure, respectivamente. La información de direccionamiento IP y los secretos de acceso se proporcionan en la configuración de CIC, lo que le permite configurar directivas de equilibrio de carga y conmutación de contenido.

El tráfico deGSLB también lo administran las VPX de Citrix ADC alojadas en los sitios de clústeres de AWS y Azure, respectivamente.

  • El DNS para el microservicio Apache se configura a través del servicio DNS global de la empresa, AWS Route 53.
  • Los registros CNAME se asignan a los respectivos servicios de DNS autoritativo (ADNS) alojados en VPX de Citrix ADC en Azure y AWS, respectivamente.
    • apacheservice.CompanyA.com
    • apacheservice.AWS.CompanyA.com
    • apacheservice.Azure.CompanyA.com
  • Método de equilibrio de carga de GSLB: Citrix ADC GSLB admite varios métodos de equilibrio de carga. CompanyA ha decidido utilizar el método Canary principalmente para soportar un alto tiempo de actividad con su ciclo de desarrollo continuo. Opciones de método:
    • Primero local: en una primera implementación local, cuando una aplicación quiere comunicarse con otra aplicación, prefiere una aplicación local en el mismo clúster. Cuando la aplicación no está disponible localmente, la solicitud se dirige a otros clústeres o regiones
    • Canary: La versión de Canary es una técnica para reducir el riesgo de introducir una nueva versión de software en producción al implementar primero el cambio a un pequeño subconjunto de usuarios. En esta solución, la implementación de canary se puede usar cuando quiere implementar nuevas versiones de la aplicación en clústeres seleccionados antes de pasarla a producción.
    • Conmutación por error: se utiliza una implementación de conmutación por error para implementar aplicaciones en una configuración activa/pasiva cuando no se pueden implementar en modo activo/activo
    • Tiempo de ida y vuelta (RTT): en una implementación de RTT, se monitorea el estado de la red en tiempo real y se dirige dinámicamente la solicitud del cliente al centro de datos con el valor de RTT más bajo
    • Proximidad estática: en una implementación de proximidad estática, se utiliza una base de datos de proximidad estática basada en direcciones IP para determinar la proximidad entre el servidor DNS local del cliente y los sitios GSLB. Las solicitudes se envían al sitio que mejor se ajusta a los criterios de proximidad
    • Round-robin: en una implementación por turnos, el dispositivo GSLB rota continuamente una lista de los servicios vinculados a él. Cuando recibe una solicitud, asigna la conexión al primer servicio de la lista y, a continuación, lo mueve al final de la lista
  • Servicios GSLB: Citrix ADC VPX, en cada sitio, supervisa y administra la distribución del tráfico a las instancias de Citrix CPX alojadas en los clústeres respectivos.

Para obtener más información, consulte Solución de ingreso y equilibrio de carga de múltiples clústeres con el Citrix ingress controller

Capa de recursos

Los recursos incluyen varias aplicaciones de microservicios, disponibles a través del RHOS Operator Hub, que se pueden desarrollar internamente u obtener a través de un proveedor externo, según los requisitos. CompanyA ha decidido implementar la aplicación web Apache.

Para obtener más información, consulte Descripción de RHOS Operator Hub

Capa de control

La capa de controlador incluye componentes de administración esenciales para coordinar la prestación de microservicios.

Red Hat OpenShift CompanyA ha decidido usar Red Hat OpenShift, versión 4.7, para implementar y administrar su clúster de Kubernetes.

Capa de host

Los clústeres de RHOS son compatibles con varias plataformas de alojamiento en las instalaciones, en la nube o en la nube híbrida.

Azure

CompanyA decidió alojar uno de sus entornos RHOS en un arrendatario de Microsoft Azure. El clúster de RHOS usó la CLI de Azure para crear el clúster.

Requisitos clave:

  • Azure Red Hat OpenShift requiere un mínimo de 40 núcleos para crear y ejecutar un clúster de OpenShift
  • Un clúster de Azure Red Hat OpenShift consta de 3 nodos maestros y tres o más nodos de trabajo.
  • Azure CLI versión 2.6.0 o posterior

Para obtener más información, consulte Azure Openshift cluster

AWS

CompanyA decidió alojar un segundo entorno RHOS en un arrendatario de AWS. El clúster de RHOS utilizó el proceso de inicio rápido de AWS para crear el clúster.

Requisitos clave:

  • El proceso de inicio rápido requiere una suscripción a Red Hat. El arrendatario debe permitir el aprovisionamiento de la instancia M4.xlarge Amazon EC2
  • Los límites de derechos de Red Hat y los límites de instancias de AWS se establecieron para admitir la implementación de 3 instancias maestras y 3 nodos de trabajo

Para obtener más información, consulte Red Hat OpenShift on AWS — Reference Deployment

Referencias

Hay muchos enlaces a documentos disponibles para comprender mejor los conceptos de redes nativas de la nube de Citrix, los microservicios de Kubernetes y la plataforma Red Hat OpenShift.

Encuentre aquí los enlaces a las referencias pertinentes de Red Hat :

Aquí encontrará enlaces a las referencias pertinentes de Citrix :

Apéndice

Terminología

Encuentre descripciones de la terminología común de RHOS y microservicios. Referencias RHOS

Arquitectura de referencia: entrega de aplicaciones basadas en microservicios con Citrix y Red Hat OpenShift