Architecture de référence : mise à disposition d’applications basées sur des microservices avec Citrix et Red Hat OpenShift

Vue d’ensemble

L’entreprise A a toujours utilisé des architectures monolithiques pour développer des applications système principalement hébergées sur site. Ils ont souffert de problèmes de disponibilité et de performances incohérentes, en particulier pour les utilisateurs distants, qui ont été exacerbés pendant la pandémie. Dans le cadre de leurs efforts pour passer au cloud, ils ont l’intention d’utiliser une architecture de microservices. Cette architecture leur permet de développer de nouvelles applications avec une résilience et une évolutivité accrues.

L’entreprise A a décidé de créer une paire de clusters multicloud redondants Red Hat OpenShift (RHOS). Ils sont hébergés dans Microsoft Azure et Amazon AWS, Citrix fournissant l’équilibrage de charge pour les instances de microservices. Cela leur permet de fournir un environnement résilient permettant aux utilisateurs distants d’accéder à des services Web professionnels critiques avec des performances toujours bonnes.

Cette architecture de référence explique comment l’entreprise A planifie son environnement, afin d’héberger une plateforme native pour le cloud, de développer de nouvelles applications ou de migrer des applications existantes.

Introduction

La société A a décidé de développer sa mise à disposition d’applications basées sur des microservices natives dans le cloud avec Citrix et RHOS afin d’apporter plusieurs avantages à son entreprise et, au final, d’augmenter sa productivité.

Cloud natif

Les applications natives du cloud sont développées pour tirer parti de la nature distribuée et évolutive du cloud. Il inclut de nombreux avantages concernant la productivité de l’entreprise, l’efficacité opérationnelle et l’expérience utilisateur.

Les avantages du cloud natif

  • Les applications conteneurisées sont portables entre les infrastructures hôtes
  • Permet un développement et une livraison agiles et continus
  • Évolutivité avec les infrastructures hôtes cloud
  • Soutient un processus de développement logiciel efficace

Red Hat OpenShift

Red Hat OpenShift est une plateforme de conteneurs Kubernetes d’entreprise qui aide les entreprises à déployer, exploiter et sécuriser des applications de microservices sur des clouds hybrides.

Avantages de Red Hat OpenShift (RHOS)

  • Gère efficacement les environnements cloud natifs Kubernetes pour le développement et l’exploitation d’applications d’entreprise critiques
  • Améliore la productivité des équipes de développement
  • Augmente le chiffre d’affaires en proposant rapidement de nouveaux services aux clients existants
  • Réduit les dépenses opérationnelles en consacrant moins de temps à l’administration et au support

Pour plus d’informations, voir Qu’est-ce que Red Hat OpenShift ?

Citrix

Citrix fournit des topologies flexibles pour la gestion du trafic dans les environnements de microservices, en fonction des exigences, notamment Full Mesh, ServiceMesh Lite, Single-Tier et Dual-Tier.

Topologies :

  • Full Mesh : les clusters Full Mesh incluent la prise en charge de divers microservices nécessitant une communication est-ouest entre les microservices au sein du cluster et une communication nord-sud (NS) en dehors du cluster.
  • Service Mesh Lite : une solution Ingress exécute généralement des fonctions de proxy L7 pour le trafic nord-sud. L’architecture Service Mesh Lite utilise la même solution Ingress pour gérer le trafic est-ouest (E-W) et surmonter les limites du service intégré de Kubernetes.
  • Niveau unique : les clusters à niveau unique contiennent des microservices qui s’exécutent en tant que duplications redondantes et dont le trafic nord-sud est fourni par des équilibreurs de charge externes.
  • Dual-Tier — Les architectures à deux niveaux ont également un trafic nord-sud fourni par des équilibreurs de charge externes. Cependant, les microservices disposent également d’un composant réseau associé pour prendre en charge la communication à l’aide de protocoles réseau supplémentaires et d’optimisations non fournies par les services de cluster natifs.

Pour plus d’informations, voir : Comment accélérer votre transition vers des applications basées sur des microservices

Avantages du Ingress Controller Citrix (CIC)

  • Les solutions Kubernetes Ingress standard fournissent un équilibrage de charge uniquement au niveau de la couche 7 (trafic HTTP ou HTTPS), tandis que le CIC prend également en charge le trafic TCP, TCP-SSL et UDP
  • Le CIC fonctionne de manière transparente sur plusieurs clouds ou centres de données sur site

Avantages de Citrix ADC VPX

  • Citrix ADC VPX fournit des stratégies de gestion du trafic de niveau entreprise, telles que des stratégies de réécriture et de réponse pour un équilibrage de charge efficace du trafic au niveau de la couche 7, ce que Kubernetes ne fournit pas
  • Citrix ADC VPX prend également en charge l’équilibrage de charge global des serveurs (GSLB)

Avantages de Citrix CPX

  • Citrix CPX permet de déployer un Citrix ADC en tant que proxy de plan de données, soit en tant que passerelle d’entrée, soit en tant que side-car dans le service mesh basé sur XDS.
  • Il fournit une gestion du trafic de couche 7 entre les microservices au sein du cluster Kubernetes, tandis que Kubernetes ne prend en charge que la couche 4.

Pour plus d’informations, consultez Citrix Developer Docs

Critères de réussite

L’entreprise A a défini une liste de critères de réussite qui ont constitué la base de la conception globale.

Remarque : L’entreprise A déploie un service Web Apache dans un pilote de production pour la validation utilisateur à distance.

Critères de réussite

Architecture conceptuelle

Sur la base des exigences précédentes, l’entreprise A a créé l’architecture conceptuelle de haut niveau suivante. Cette architecture répond à toutes les exigences initiales tout en donnant à l’entreprise A les bases nécessaires pour étendre davantage de cas d’utilisation à l’avenir.

Architecture conceptuelle

Le cadre d’architecture est divisé en plusieurs couches. Le cadre fournit une base pour comprendre l’architecture technique de l’infrastructure de microservices. Toutes les couches s’unissent pour créer une solution complète de bout en bout.

À un niveau élevé :

Couche utilisateur : La couche utilisateur décrit l’environnement de l’utilisateur final et les terminaux utilisés pour se connecter aux ressources.

Les utilisateurs peuvent se connecter au service Web en toute sécurité à l’aide de l’application Citrix Workspace. Les utilisateurs peuvent également se connecter au service Web à l’aide d’un navigateur standard avec transport HTTP/HTTPS.

Couche d’accès : La couche d’accès décrit comment les utilisateurs accèdent aux services Web et comment les flux nord-sud sont fournis.

  • Le nom de domaine complet principal du service Web est résolu en serveurs de noms hébergés sur Citrix ADC VPX.
  • Les VPX Citrix ADC exécutant GSLB répondent aux requêtes DNS (Domain Name Service) avec une adresse IP publique du serveur virtuel Content Switch avec le moins de connexions.
  • Le serveur virtuel est configuré par le Ingress Controller Citrix pour transférer les connexions au cluster Citrix CPX hébergé par le cluster avec le moins de connexions.
  • Le Citrix CPX hébergé en cluster accepte les connexions et répond au Citrix ADC VPX. Il établit un flux vers le service Web sur lequel la charge utile est fournie.

Couche ressource : La couche de ressources spécifie les applications mises à disposition des utilisateurs sous forme de microservices dans cette architecture de référence.

  • Quatre services Web Apache sont hébergés sous forme de RHOS Pods. Ils sont déployés via le hub opérateur RHOS.

Couche de contrôle : La couche de contrôle définit la façon dont les ressources sont gérées et surveillées.

  • Red Hat OpenShift est utilisé pour créer le cluster et déployer, gérer et surveiller les ressources de microservices.

Couche hôte : La couche d’hébergement définit l’infrastructure sous-jacente qui héberge les ressources, y compris la mémoire, le stockage et le calcul.

  • Microsoft Azure et Amazon AWS sont les IaaS publics utilisés pour héberger le cluster RHOS et les microservices.

Les sections suivantes fournissent plus de détails sur les décisions de conception spécifiques pour la fourniture d’applications basées sur des microservices l’entreprise AS avec Citrix et Red Hat OpenShift.

Couche utilisateur

La couche utilisateur est l’endroit où les utilisateurs demandent et accèdent aux ressources cibles sur les points de terminaison pris en charge.

Couche utilisateur

Les utilisateurs peuvent se connecter au service Web en toute sécurité à l’aide de l’application Citrix Workspace.

  • Citrix Workspace : le service Web est publié en tant qu’application dans Citrix Workspace. L’application Citrix Workspace installée sur le point de terminaison de l’utilisateur démarre une connexion proxy avec l’application publiée dans Citrix Cloud.
  • Citrix Secure Internet Access : la connexion vers le Citrix ADC VPX hébergé dans le cloud est transmise par proxy par Citrix Secure Internet Access pour une inspection complète de la pile, y compris SWG, DLP, CASB et NGFW
  • Protection des applications Web et des API Citrix : la connexion au Citrix ADC VPX hébergé dans le cloud est transmise par proxy et inspectée par les signatures du pare-feu d’application Web Citrix Web Application et API Protection.

Couche d’accès

La couche Access est l’endroit où les composants de mise à disposition réseau sont hébergés pour coordonner et diriger les demandes de sessions utilisateur vers les composants de contrôle et de ressources.

Vue d'ensemble

Citrix CPX

L’entreprise A a décidé de mettre en œuvre une architecture à deux niveaux et d’utiliser Citrix CPX pour gérer la fourniture du trafic de service au sein du cluster. Le CPX reçoit les demandes de trafic utilisateur provenant du Citrix ADC VPX hébergé dans le cloud et équilibre la charge de trafic entre les instances de microservices. Le Citrix CPX est déployé, par l’administrateur du cluster, via une configuration de fichier YAML à l’aide de contrôles RHOS. Citrix CPX est déployé de la même manière dans les clusters AWS et Azure.

Contrôleur d’entrée Citrix

L’entreprise A a décidé d’utiliser le Citrix Ingress Controller (CIC) pour gérer le réseau natif du cloud Citrix au sein de son cluster RHOS. Le Ingress Controller Citrix est utilisé pour gérer le flux de trafic entrant du cluster. Il utilise des domaines de ressources personnalisés (CRD) de cluster global pour obtenir et surveiller Citrix CPX et l’état du service. Sur la base de ces informations, il configure dynamiquement Citrix ADC VPX pour équilibrer la charge et acheminer le trafic vers les CPX Citrix au sein du cluster.

Citrix ADC VPX

L’entreprise A a décidé d’utiliser Citrix ADC VPX pour gérer ses flux de trafic Nord-Sud et pour mettre en œuvre l’équilibrage de charge globale des serveurs (GSLB) entre Azure et les clusters AWS.

Le traficnord-sud est géré par les VPX Citrix ADC hébergés respectivement sur les sites de clusters AWS et Azure. Les informations d’adressage IP et les secrets d’accès sont fournis dans la configuration CIC, ce qui lui permet de configurer les stratégies d’équilibrage de charge et de commutation de contenu

Le traficGSLB est également géré par les VPX Citrix ADC hébergés respectivement sur les sites de clusters AWS et Azure.

  • Le DNS pour le microservice Apache est configuré via le service DNS global de l’entreprise AWS Route 53
  • Les enregistrements CNAME sont mappés aux services DNS faisant autorité (ADNS) respectifs hébergés sur les VPX Citrix ADC dans Azure et AWS, respectivement.
    • apacheservice.CompanyA.com
    • apacheservice.AWS.CompanyA.com
    • apacheservice.Azure.CompanyA.com
  • Méthode d’équilibrage de charge GSLB — Citrix ADC GSLB prend en charge différentes méthodes d’équilibrage de charge. L’entreprise A a décidé d’utiliser la méthode Canary principalement pour assurer une disponibilité élevée dans le cadre de son cycle de développement continu. Options de méthode :
    • Local d’abord : dans un premier déploiement local, lorsqu’une application souhaite communiquer avec une autre application, elle préfère une application locale dans le même cluster. Lorsque l’application n’est pas disponible localement, la demande est dirigée vers d’autres clusters ou régions
    • Canary : La publication de Canary est une technique visant à réduire le risque d’introduction d’une nouvelle version logicielle en production en déployant d’abord la modification à un petit sous-ensemble d’utilisateurs. Dans cette solution, le déploiement Canary peut être utilisé lorsque vous souhaitez déployer de nouvelles versions de l’application sur des clusters sélectionnés avant de la mettre en production.
    • Basculement : un déploiement de basculement est utilisé pour déployer des applications dans une configuration active/passive lorsqu’elles ne peuvent pas être déployées en mode actif/actif
    • Temps d’aller-retour (RTT) : dans un déploiement RTT, l’état en temps réel du réseau est surveillé et dirige dynamiquement la demande du client vers le centre de données ayant la valeur RTT la plus faible
    • Proximité statique : Dans un déploiement de proximité statique, une base de données de proximité statique basée sur une adresse IP est utilisée pour déterminer la proximité entre le serveur DNS local du client et les sites GSLB. Les demandes sont envoyées au site qui correspond le mieux aux critères de proximité
    • Round-robin : Dans un déploiement circulaire, le périphérique GSLB fait tourner en permanence une liste des services qui lui sont liés. Lorsqu’il reçoit une demande, il attribue la connexion au premier service de la liste, puis déplace ce service en bas de la liste
  • Services GSLB — Le Citrix ADC VPX, dans chaque site, surveille et gère la distribution du trafic vers les instances Citrix CPX hébergées dans les clusters respectifs.

Pour plus d’informations, consultez la section Solution d’équilibrage de charge et d’entrée multi-clusters à l’aide du Citrix ingress controller

Couche de ressources

Les ressources comprennent diverses applications de microservices, disponibles via le RHOS Operator Hub, qui peuvent être développées en interne ou obtenues auprès d’un fournisseur tiers, en fonction des besoins. L’entreprise A a décidé de déployer l’application Web Apache.

Pour plus d’informations, voir Understanding RHOS Operator Hub

Couche de contrôle

La couche contrôleur comprend des composants de gestion essentiels pour coordonner la fourniture de microservices.

Red Hat OpenShift l’entreprise A a choisi d’utiliser Red Hat OpenShift, version 4.7, pour déployer et gérer son cluster Kubernetes.

Couche hôte

Les clusters RHOS sont pris en charge sur diverses plateformes d’hébergement sur site, dans le cloud ou dans le cloud hybride.

Azure

L’entreprise A a décidé d’héberger l’un de ses environnements RHOS dans un client Microsoft Azure. Le cluster RHOS a utilisé l’interface de ligne de commande Azure pour créer le cluster.

Principales exigences :

  • Azure Red Hat OpenShift nécessite un minimum de 40 cœurs pour créer et exécuter un cluster OpenShift
  • Un cluster Azure Red Hat OpenShift se compose de 3 nœuds principaux et de trois nœuds de travail ou plus.
  • Azure CLI version 2.6.0 ou ultérieure

Pour plus d’informations, voir Cluster Azure Openshift

AWS

L’entreprise A a décidé d’héberger un deuxième environnement RHOS dans un client AWS. Le cluster RHOS a utilisé le processus de démarrage rapide AWS pour créer le cluster.

Principales exigences :

  • Le processus de démarrage rapide nécessite un abonnement Red Hat. Le locataire doit autoriser le provisionnement de l’instance M4.xlarge Amazon EC2
  • Les limites d’autorisation Red Hat et les limites d’instance AWS ont été définies pour prendre en charge le déploiement de 3 instances maîtres et de 3 nœuds de travail

Pour plus d’informations, voir Red Hat OpenShift on AWS — Reference Deployment

Références

De nombreux liens vers des documents sont disponibles pour mieux comprendre les concepts réseau natifs du cloud Citrix, les microservices Kubernetes et la plateforme Red Hat OpenShift.

Vous trouverez des liens vers les références Red Hat pertinentes ici :

Vous trouverez des liens vers les références Citrix pertinentes ici :

Annexe

Terminologie

Trouvez des descriptions de la terminologie RHOS et microservices courante. Références RHOS

Architecture de référence : mise à disposition d’applications basées sur des microservices avec Citrix et Red Hat OpenShift