Modifier

Partager via

Déployer des applications web avec Azure Red Hat OpenShift redondant interzone

Azure Red Hat OpenShift
Azure Cosmos DB
Azure Front Door

Cet article apporte une vue d’ensemble complète sur une charge de travail d’application web sur Azure Red Hat OpenShift dans une configuration redondante interzone. Les services redondants interzones permettent de répliquer vos services et vos données dans des zones de disponibilité pour les protéger contre les points de défaillance uniques et assurer la haute disponibilité.

Avant d’utiliser Azure Red Hat OpenShift pour créer un environnement de production, lisez l’article Accélérateur de zone d’atterrissage Azure Red Hat OpenShift.

Architecture

Diagramme représentant l’architecture de référence pour une application web avec haute disponibilité.

Téléchargez un fichier Visio de cette architecture.

Workflow

  • Un utilisateur envoie une requête à Azure.
  • Azure Front Door reçoit la requête et l’achemine vers une application web hébergée sur Azure Red Hat OpenShift.
  • L’application web exécute la requête avec Azure Key Vault, Azure Cosmos DB et Azure Container Registry.
  • L’application web envoie une réponse à l’utilisateur.

Composants

  • Microsoft Entra ID ou Azure AD B2C authentifie les utilisateurs. Dans cette architecture, Microsoft Entra ID fournit un accès sécurisé et granulaire aux ressources externes.
  • Azure Front Door est l’interface publique pour toutes les requêtes Internet. Il agit comme un proxy inverse HTTP global et un cache pour les services back-end. Azure Front Door améliore la sécurité et les performances de cette architecture, comme l’ajout d’une protection contre les attaques par déni de service distribué de couche 4 (DDoS).
  • Azure Red Hat OpenShift est l’orchestrateur de conteneurs basé sur Kubernetes qui héberge les applications et services d’API. Il assure l’interface des services back-end. Azure Red Hat OpenShift sert de plateforme de calcul principale dans cette architecture.
  • Azure Container Registry prend en charge les images conteneurs conformes à Docker et Open Container Initiative (OCI). Container Registry prend en charge la redondance de zone, ce qui le rend hautement disponible et résilient face aux défaillances zonales. Il propose également la géoréplication, qui réplique le service dans plusieurs régions. Dans cette architecture, Container Registry fournit l’accès privé au cluster ARO aux images conteneur gérées localement qui font partie de la charge de travail.
  • Azure Red Hat OpenShift utilise l’intégration de réseau virtuel pour se connecter aux services back-end sur un réseau virtuel privé. L’intégration de réseau virtuel fournit un réseau sécurisé avec Azure Red Hat OpenShift et d’autres services Azure dans cette architecture.
  • Azure Cosmos DB fournit les bases de données de documents NoSQL pour les services d’application front-end. Azure Cosmos DB est utilisé par la charge de travail dans cette architecture pour stocker les données utilisateur.
  • Les points de terminaison privés activent les connexions aux services Azure PaaS à partir de réseaux virtuels privés et vous permettent de désactiver les points de terminaison publics sur ces services. Dans cette architecture, les points de terminaison privés avec intégration de réseau virtuel conservent le trafic réseau d’Azure Red Hat OpenShift privé tout en communiquant avec les services PaaS.
  • Azure Private DNS configure et met à jour les enregistrements DNS requis par les services de point de terminaison privé. Dans cette architecture, Azure DNS privé est utilisé pour la résolution de noms dans les réseaux privés.
  • Azure Key Vault stocke en toute sécurité les secrets et les certificats auxquels les services Azure accèdent. Dans cette architecture, Azure Key Vault stocke en toute sécurité les secrets pour les applications s’exécutant sur Azure Red Hat OpenShift.
  • Azure Monitor et Application Insights collectent les journaux de service et les métriques de performances des applications pour l’observabilité. Dans cette architecture, Azure Monitor est la synchronisation des journaux de journal pour les journaux de plateforme et de charge de travail. Application Insights est spécifiquement destiné aux journaux d’activité et aux métriques provenant du code de charge de travail.

Autres solutions

  • Même s’il est recommandé de choisir un DNS managé Azure, vous pouvez utiliser votre propre fournisseur DNS.
  • Vous devez utiliser Azure Application Gateway au lieu d’Azure Front Door si la plupart de vos utilisateurs se trouvent à proximité de la région Azure qui héberge votre charge de travail et si vous n’avez pas besoin de mise en cache de contenu. Utilisez Azure DDoS Protection pour protéger les services Application Gateway accessibles sur Internet.
  • Déployez une instance Azure API Management premium qui propose la redondance de zone comme solution alternative pour héberger les API front-end et/ou back-end. Pour plus d’informations sur la redondance de zone API Management, consultez l’article Migration d’Azure API Management vers la prise en charge des zones de disponibilité.
  • Vous pouvez utiliser OpenShift Container Platform (OCP) ou la distribution de la communauté d’origine de Kubernetes (OKD) sur Azure Machines Virtuelles au lieu d’Azure Red Hat OpenShift. OCP ou OKD sont des alternatives IaaS (infrastructure-as-a-service) à un service entièrement géré par la plateforme, comme Azure Red Hat OpenShift. Vous devez utiliser des groupes de machines virtuelles identiques Azure pour la redondance de zone. Pour plus d’informations, consultez Azure Red Hat OpenShift.

Détails du scénario

Cette architecture décrit comment composer des services redondants interzones dans une solution qui garantit la haute disponibilité et la résilience aux défaillances zonales.

Les zones de disponibilité sont des emplacements physiques individuels au sein d’une région Azure. Les zones de disponibilité répartissent une solution sur plusieurs zones indépendantes au sein d’une région, de sorte qu’une application peut continuer à fonctionner en cas de défaillance zonale. Cette architecture repose sur l’infrastructure des zones de disponibilité qui se trouve dans de nombreuses régions. Pour obtenir la liste des régions qui prennent en charge les zones de disponibilité, consultez l’article Régions Azure avec prise en charge des zones de disponibilité.

Il est souvent difficile de garantir la haute disponibilité des plateformes d’hébergement à grande échelle. Historiquement, la haute disponibilité nécessite des déploiements multirégions complexes et coûteux, qui imposent des compromis en termes de cohérence des données et de performances élevées. Les zones de disponibilité résolvent un grand nombre de ces problèmes. La plupart des services Azure standard et de nombreux services Azure spécialisés prennent en charge les zones de disponibilité. Tous les services Azure de cette architecture sont redondants interzones, ce qui simplifie le déploiement et la gestion. Pour plus d’informations, consultez l’article sur les services Azure prenant en charge les zones de disponibilité.

Pour gérer les contrats de niveau de service (SLA), Azure Red Hat OpenShift redondant interzone gère et atténue les défaillances, y compris les défaillances zonales. La redondance de zone garantit un temps de récupération de zéro en cas de défaillance zonale. Si une zone d’une région n’est pas disponible, vous ne perdez aucune donnée et la charge de travail continue de s’exécuter. La redondance de zone est configurée au moment du déploiement. Elle est gérée par les services, de sorte que vous n’avez pas à gérer l’épinglage de zone ni les déploiements zonaux.

Dans cette architecture, un cluster Azure Red Hat OpenShift est déployé dans trois zones de disponibilité, dans les régions Azure compatibles. Un cluster se compose de trois nœuds de plan de contrôle et d’au moins trois nœuds Worker. Pour améliorer la redondance, les nœuds sont répartis entre les zones.

Azure Front Door, Microsoft Entra ID et Azure DNS sont des services disponibles globalement qui sont résilients aux pannes à l’échelle de la zone et de la région. Tous les autres services de l’architecture sont redondants interzones.

Cas d’usage potentiels

Azure Red Hat OpenShift est un service d’orchestration de conteneurs qui utilise Kubernetes. Il convient à de nombreux cas d’usage, comme les suivants :

  • Opérations bancaires
  • Négociation d’actions
  • E-commerce
  • Médias sociaux
  • Applications web
  • Applications mobiles
  • Applications de traitement par lots
  • Streaming multimédia
  • Charges de travail Machine Learning

Recommandations

Les recommandations suivantes s’appliquent à la plupart des scénarios.

Azure Front Door

  • Utilisez les certificats managés Azure sur toutes les applications front-end afin d’empêcher les problèmes de configuration et d’expiration des certificats.
  • Activez la mise en cache sur les itinéraires pour améliorer la disponibilité. Le cache Azure Front Door distribue votre contenu dynamique ainsi que le contenu statique aux nœuds de périphérie de point de présence (POP) Azure. La mise en cache allège la charge sur les serveurs d’origine et améliore les performances.
  • Déployez Azure Front Door Premium et configurez une stratégie de pare-feu d’applications web (WAF) avec un ensemble de règles géré par Microsoft. Appliquez la stratégie à tous les domaines personnalisés. Utilisez le mode de prévention pour atténuer les attaques web qui peuvent entraîner la défaillance d’un service d’origine.

Azure Red Hat OpenShift

  • Vérifiez que la région Azure utilisée pour le déploiement d’Azure Red Hat OpenShift prend en charge les zones de disponibilité. Pour plus d’informations, consultez Régions Azure avec prise en charge des zones de disponibilité.
  • Un cluster Azure Red Hat OpenShift dépend de plusieurs services. Assurez-vous que ces services prennent en charge la redondance de zone et sont configurés en ce sens. Pour plus d’informations, consultez Services Azure prenant en charge les zones de disponibilité.
  • Supprimez l’état des conteneurs, et utilisez les services de stockage ou de base de données Azure à la place.
  • Configurez plusieurs réplicas dans les déploiements et choisissez la configuration de budget d’interruption qui convient pour assurer le service d’application en continu, en dépit des interruptions (défaillances matérielles dans les zones, p. ex.).
  • Sécurisez l’accès à Azure Red Hat OpenShift. Pour vous assurer que les demandes ne peuvent pas contourner le WAF Azure Front Door, autorisez uniquement le trafic Azure Front Door. Pour plus d’informations sur la restriction d’accès d’une instance Azure Front Door spécifique, consultez l’article Sécuriser l’accès à Azure Red Hat OpenShift avec Azure Front Door.

Container Registry

Pour plus d’informations, consultez les articles Activer la redondance de zone dans Azure Container Registry à des fins de résilience et de haute disponibilité et Utiliser Azure Container Registry avec Azure Red Hat OpenShift.

Azure Cosmos DB

Key Vault

Key Vault est redondant interzone dans n’importe quelle région où les zones de disponibilité sont disponibles. Dans cette architecture, Key Vault est déployée avec un point de terminaison privé activé et un point de terminaison public désactivé. Pour plus d’informations sur les points de terminaison privés pour Key Vault, consultez l’article Intégrer Key Vault avec Azure Private Link.

Zones Azure DNS privées

Pour simplifier la gestion DNS, intégrez des points de terminaison privés à des zones Azure DNS privées. Pour plus d’informations, consultez Configuration DNS des points de terminaison privés Azure.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Azure Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

Cette architecture garantit la fiabilité, puisqu’elle fournit la disponibilité, la résilience et des fonctionnalités de service global sûres.

Disponibilité

Lorsque l’infrastructure de la zone de disponibilité est correctement implémentée, cette architecture offre une excellente disponibilité pour des coûts et des frais opérationnels inférieurs à ceux d’autres solutions. Cette architecture atténue le risque de défaillance zonale dans une région Azure. En effet, les services redondants interzones résistent à la défaillance et continuent de fonctionner au SLA défini.

Même si elles sont peu probables, les défaillances régionales restent possibles. En cas de défaillance régionale, les services sont indisponibles dans toutes les zones de disponibilité de la région. Pour atténuer le risque de défaillance régionale, combinez cette architecture redondante interzone avec une architecture multirégion. Planifiez votre architecture multirégion pour réduire le temps de récupération lorsqu’une région entière est indisponible.

Les conceptions multirégions sont plus complexes et souvent plus coûteuses que les conceptions multizones au sein d’une seule région. Toutefois, elles offrent la possibilité d’optimiser davantage la disponibilité et la fiabilité globale.

Notes

Menez une évaluation des risques pour déterminer si votre solution nécessite une architecture multirégion.

Résilience

Les conceptions multizones basées sur des zones de disponibilité offrent une disponibilité et une résilience qui répondent, voire dépassent les exigences métier de la plupart des organisations. Mais pour répliquer des données vers une région secondaire à des fins de récupération d’urgence, les options disponibles dépendent des services Azure que vous utilisez.

Par exemple, Stockage Azure prend en charge la réplication d’objets pour les objets blob de blocs. Les services de données Azure (comme Azure Cosmos DB) offrent une réplication des données vers d’autres régions Azure avec une sauvegarde continue. Vous pouvez utiliser ces fonctionnalités pour restaurer votre solution en cas de sinistre. Pour plus d’informations, voir Sauvegarde continue avec restauration à un instant dans le passé dans Azure Cosmos DB.

Services globaux

Même si les défaillances des services globaux (comme Azure Front Door et Microsoft Entra ID) sont rares, leur impact peut être important. Pour améliorer la récupération en cas de défaillance, préparez et répétez les runbooks.

Vous pouvez ainsi réduire les temps d’arrêt Azure Front Door en utilisant un runbook pour déployer Azure Application Gateway et modifier les enregistrements DNS afin de rediriger le trafic jusqu’à ce qu’Azure Front Door soit restauré.

Pour plus d’informations, consultez l’article Renforcer la résilience de votre infrastructure de gestion des identités et des accès.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

  • Envisagez de déployer un cluster privé.
  • Utilisez les points de terminaison privés sur des services Azure qui ne sont pas accessibles depuis l’Internet public.
  • Par défaut, toutes les communications de service à service sont chiffrées en TLS (Transport Layer Security) dans Azure. Configurez Azure Front Door pour accepter uniquement le trafic HTTPS et définissez la version TLS minimale.
  • Les identités managées permettent d’authentifier la communication de service à service Azure, le cas échéant. Pour plus d’informations, consultez Que sont les identités managées pour les ressources Azure ?
  • Pour gérer et protéger les secrets, certificats et chaîne de connexion de votre cluster, connectez le cluster Azure Red Hat OpenShift à Kubernetes avec Azure Arc. Utilisez l’extension de fournisseur de secrets Azure Key Vault pour récupérer les secrets.
  • Configurez Microsoft Defender pour les conteneurs afin d’assurer la sécurité des clusters, des conteneurs et des applications. Microsoft Defender pour les conteneurs est pris en charge dans le cadre de Kubernetes avec Azure Arc. Analysez vos images à la recherche de vulnérabilités avec Microsoft Defender ou toute autre solution d’analyse d’images.
  • Configurez l’intégration de Microsoft Entra pour utiliser l’ID Microsoft Entra pour authentifier les utilisateurs (par exemple, SRE, SecOps ou développeurs d’applications) dans votre cluster Azure Red Hat OpenShift.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Les architectures redondantes interzones sont moins coûteuses que les alternatives multirégions, vous pouvez déployer ces services dans une seule région. Vous devez toutefois tenir compte des coûts qui en résultent :

  • Certains services nécessitent un nombre minimal d’instances ou de réplicas à déployer pour obtenir une redondance de zone.
  • Le tarif du stockage redondant interzone (ZRS) et celui du stockage localement redondant (LRS) sont différents. Pour plus d’informations, consultez Tarification du stockage.
  • Les points de terminaison privés sont principalement disponibles sur les références SKU de service Azure premium. Les points de terminaison privés entraînent des frais horaires et de bande passante. Pour plus d’informations, consultez Tarification de Private Link.

Optimisez les coûts en réservant vos ressources en amont. De nombreux services de l’architecture sont éligibles aux tarifs de la capacité de réserve. Pour plus d’informations, consultez la page Réservations.

Utiliser la calculatrice de prix Azure pour estimer les coûts.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.

Tous les services PaaS (plateforme en tant que service) d’Azure sont intégrés à Azure Monitor. Suivez les meilleures pratiques d’Azure Monitor (fiabilité, sécurité, optimisation des coûts, excellence opérationnelle et efficacité des performances) pour :

  • Créer un modèle d’intégrité pour quantifier l’intégrité des applications dans le contexte des exigences métier.
  • Configurer le volume de collecte de données de journal approprié.
  • Créer des tableaux de bord Azure pour unifier les données dans une vue unifiée pour les équipes opérationnelles.
  • Créer une stratégie d’alerte réussie.
  • Intégrer Application Insights dans des applications pour suivre les métriques de performances des applications.
  • Générer des notifications lorsqu’une action directe est nécessaire et utiliser un système d’alertes (comme les alertes de métrique Container Insights ou l’interface utilisateur d’alerte Azure Red Hat OpenShift).
  • Étudier les différentes méthodes pour surveiller et journaliser Azure Red Hat OpenShift en vue d’obtenir des insights sur l’intégrité de vos ressources et d’anticiper les problèmes potentiels.
  • Passer en revue la matrice de responsabilités Azure Red Hat OpenShift en vue de comprendre comment Microsoft, Red Hat et les clients partagent les responsabilités liées aux clusters.
  • Automatiser les déploiements de service avec Bicep, un langage de gabarit permettant de déployer une infrastructure en tant que code (IaC). Étant donné que les services Azure de cette architecture ont des points de terminaison privés, vous ne pouvez pas utiliser des agents hébergés par Microsoft d’Azure Pipelines ou des exécuteurs hébergés par GitHub. Utilisez plutôt des solutions telles que des agents auto-hébergés d’Azure Pipelines ou des exécuteurs hébergés par GitHub.
  • Valider en continu la charge de travail en vue de tester les performances et la résilience de l’ensemble de la solution à l’aide de services comme Azure Load Testing et Azure Chaos Studio.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.

  • Mettez en cache vos ressources dans Azure Front Door afin de distribuer les charges de travail sur les emplacements périphériques.
  • Passez en revue les limites et quotas d’abonnement pour vous assurer que les services sont mis à l’échelle à la demande.
  • Surveillez les performances des applications à l’aide d’Application Insights.
  • Menez des tests de performance sur les charges de travail afin de mesurer la latence causée par les connexions interzones.
  • Choisissez une taille de machine virtuelle adaptée à votre charge de travail. Optez pour une taille qui soit suffisante pour bénéficier des avantages d’une densité accrue, mais pas trop importante. En effet, votre cluster ne peut pas gérer la charge de travail d’un nœud défaillant.
  • Utilisez des demandes et des limites de pods pour gérer les ressources de calcul au sein d’un cluster. Les demandes et les limites de pods informent le planificateur Kubernetes, qui affecte des ressources de calcul à un pod. Limitez la consommation des ressources d’un projet en utilisant les plages de limites.
  • Définissez les requêtes et les limites de ressources des pods dans les manifestes de déploiement d’application, puis appliquez-l’es avec Azure Policy.
  • Optimisez les valeurs de requête de processeur et de mémoire. Améliorez l’efficacité des ressources de cluster avec l’outil de mise à l’échelle automatique verticale des pods.
  • Mettez à l’échelle les pods pour répondre à la demande avec l’outil de mise à l’échelle automatique horizontale des pods.
  • Définissez ClusterAutoScaler et MachineAutoScaler pour mettre à l’échelle les machines quand votre cluster manque de ressources pour prendre en charge davantage de déploiements.

Déployer ce scénario

Pour déployer cette architecture, consultez l’article Accélérateur de zone d’atterrissage Azure Red Hat OpenShift et le dépôt GitHub associé.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

Autres contributeurs :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes