Considérations relatives à la continuité d’activité et reprise d’activité pour Red Hat Enterprise Linux sur Azure
Cet article explique comment améliorer la préparation de la continuité d’activité et de la reprise d’activité (BCDR) pour un environnement Red Hat Enterprise Linux (RHEL) sur Azure. Il fournit des recommandations que vous pouvez utiliser pour prendre en charge les charges de travail RHEL et déployer des composants de gestion de plateforme RHEL. L’abonnement Red Hat Management contient des composants de la plateforme qui aident à gérer les charges de travail dans une ou plusieurs zones d’atterrissage RHEL. Ces composants offrent leurs propres configurations BCDR.
Considérations sur la conception
Implémentez les considérations suivantes pour améliorer la résilience de vos charges de travail RHEL.
Objectifs de délai de récupération
Un objectif de délai de récupération (RTO) correspond au temps qu’il faut à votre système pour reprendre son état d’origine après un sinistre. Le RTO comprend le temps nécessaire pour :
- Restaurer les fonctionnalités minimales des machines virtuelles et des applications.
- Restaurer les données dont les applications ont besoin.
En termes commerciaux, le RTO représente la durée pendant laquelle les processus d’entreprise sont hors service. Un RTO faible est idéal pour les charges de travail stratégiques afin que les processus d’entreprise puissent reprendre rapidement. Pour les charges de travail de priorité plus basse, un RTO plus élevé peut ne pas avoir d’effet notable sur le niveau de performance de l’entreprise.
Objectifs de point de récupération
Pour exploiter correctement un environnement cloud, vous devez implémenter des sauvegardes, une réplication ou les deux afin de protéger les données contre les défaillances. L’objectif de point de récupération (RPO) fait référence à la dernière fois que des données ont été capturées. En cas de défaillance d’un système, vous pouvez le restaurer uniquement au point de récupération le plus récent.
Le RPO est mesuré à partir du point de récupération le plus récent jusqu’au moment où une panne se produit. Si vous mesurez le RPO en heures, une défaillance du système entraîne la perte de données pendant les heures écoulées entre le dernier point de récupération et la panne. Si vous mesurez le RPO en jours, une défaillance du système entraîne la perte de données pendant les jours écoulés entre le dernier point de récupération et la panne. Un objectif de point de récupération d’un jour entraîne théoriquement la perte de toutes les transactions de la journée qui précède la défaillance.
Pour les systèmes stratégiques, mesurez le RPO en minutes ou en secondes pour éviter toute perte de revenus ou de bénéfices. Un RPO court entraîne généralement une augmentation des coûts de gestion. Pour réduire ces coûts, vous devez créer une base de référence de gestion qui se concentre sur le RPO le plus long possible. Vous pouvez ensuite réduire le RPO pour des plateformes ou des charges de travail spécifiques qui nécessitent un investissement plus important.
Considérations BCDR relatives à la charge de travail
Les considérations sur la conception de haute disponibilité et de reprise d’activité pour les charges de travail RHEL dépendent des technologies qui prennent en charge ces charges de travail. De nombreuses charges de travail modernes peuvent tirer parti des services Azure natifs pour assurer une redondance au sein des zones de disponibilité et des régions. Utilisez les services Azure pour gérer la réplication de données, mettre automatiquement à l’échelle des groupes à haute disponibilité et contrôler les domaines de mise à jour et d’erreur. Ces pratiques permettent de garantir plus facilement la disponibilité des déploiements RHEL.
Les solutions de base de données et d’autres applications avec état peuvent nécessiter des solutions centrées sur le système d’exploitation pour assurer une haute disponibilité et une reprise d’activité. Consultez le développeur ou le fournisseur des applications pour prendre connaissance des solutions qu’elles prennent en charge. Pour plus d’informations, consultez Haute disponibilité et reprise après sinistre pour les applications IaaS.
| Fonctionnalité ou service Azure | Définition | À propos de l’installation |
|---|---|---|
| Régions | Groupe de centres de données situés à proximité les uns des autres afin de réduire les retards réseau. Un réseau régional spécifique connecte les différents centres de données afin d’assurer un transfert rapide de données. | Lorsque vous choisissez une région Azure, tenez compte de l’emplacement de vos centres de données, de vos utilisateurs et de vos données principales. Vérifiez la disponibilité des services dont vous avez besoin dans les régions que vous sélectionnez. Pour les déploiements RHEL, vous pouvez commencer par une seule région, puis en ajouter d’autres à l’avenir, à des fins BCDR. |
| Azure ExpressRoute | Service Azure que vous pouvez utiliser pour établir des connexions privées depuis des centres de données Microsoft vers votre propre infrastructure ou une installation de colocalisation. | ExpressRoute contourne l’Internet public et fournit une connexion privée dédiée. Cette configuration est une exigence courante pour les déploiements RHEL à grande échelle. ExpressRoute est un service partagé. Vous devez donc planifier soigneusement votre capacité de bande passante pour répondre aux besoins globaux en matière de bande passante de votre entreprise. Si vous avez une bande passante insuffisante, vous risquez de compromettre l’expérience utilisateur ou l’accès à des services critiques dans le centre de données. Veillez à déployer ExpressRoute de manière résiliente au sein des régions et des emplacements de peering. |
| Zones de disponibilité | Groupes distincts de centres de données qui possèdent leur propre système d’alimentation, de refroidissement et de mise en réseau au sein d’une région Azure. Les zones de disponibilité assurent une haute disponibilité et une forte résilience aux défaillances du centre de données. | Pour garantir un contrat de niveau de service (SLA) élevé, utilisez des zones de disponibilité avec une infrastructure RHEL, si possible. Les zones de disponibilité offrent la redondance du centre de données au sein d’une région. Toutefois, toutes les régions ne disposent pas de zones de disponibilité. Vous devez donc les planifier attentivement. Les services RHEL, tels qu’Azure Red Hat OpenShift et les services de gestion des zones d’atterrissage, prennent en charge les zones de disponibilité. |
| Groupes à haute disponibilité | Regroupement logique de machines virtuelles. Au moins une machine virtuelle reste opérationnelle lors d’événements de maintenance planifiés ou non planifiés. Un domaine d’erreur est un sous-ensemble d’un groupe à haute disponibilité qui partage une infrastructure physique commune, telle que l’alimentation ou le réseau. Lorsque vous distribuez des machines virtuelles au sein de différents domaines d’erreur, un groupe à haute disponibilité permet de réduire l’impact des défaillances matérielles sur la disponibilité de la machine virtuelle. | Les groupes à haute disponibilité fournissent un contrat SLA élevé. Les groupes à haute disponibilité conviennent à une infrastructure RHEL dans le cas où une région ne dispose pas de zones de disponibilité. Les groupes à haute disponibilité ne disposent que de la redondance matérielle, qui est semblable aux règles d’anti-affinité de l’hyperviseur. Par conséquent, si vos régions ne disposent pas de zones de disponibilité, vous devez utiliser une stratégie multirégion pour fournir une redondance géographique et de centre de données. |
| Équilibrage de charge Azure | Service d’équilibrage de charge réseau. Vous pouvez configurer Load Balancer pour fournir un trafic réseau à volume élevé de manière efficace au sein de plusieurs serveurs Red Hat Enterprise. Le service fonctionne à faible latence et à haut débit, ce qui améliore les performances et la disponibilité des applications. Load Balancer peut effectuer automatiquement une mise à l’échelle en fonction de la demande. Pour promouvoir un déploiement hybride de vos applications, Load Balancer peut répartir le trafic réseau entre plusieurs régions sur Azure, mais aussi entre des environnements locaux et Azure. |
Load Balancer répartit le trafic réseau entre plusieurs serveurs afin de fournir une disponibilité ininterrompue des applications et d’éviter les défaillances à point unique. En cas de sinistre, Load Balancer redirige le trafic vers des serveurs opérationnels afin d’assurer un basculement et une reprise d’activité rapides. Cette opération permet de réduire les temps d’arrêt et de maintenir l’activité de l’entreprise. Load Balancer peut équilibrer la charge du trafic entre les serveurs locaux vers le cloud Azure ou vers des serveurs dans plusieurs régions Azure. Pour plus d’informations, consultez la page Options d’équilibrage de charge. |
| Disques managés | Disques virtualisés gérés par Azure. Vous choisissez la taille et le type de disque. Azure distribue des disques entre différentes unités de stockage pour protéger vos données contre les défaillances matérielles. | Les disques managés représentent le meilleur choix pour toutes les infrastructures RHEL. N’utilisez pas de disques non managés. Pour plus d’informations, consultez la documentation relative aux contrats SLA pour les machines virtuelles. Les disques de type différent ne présentent pas les mêmes performances ni les mêmes coûts. Pour les machines d’infrastructure RHEL, nous recommandons les SDD Azure Premium. Tenez compte des coûts, des performances et de la disponibilité lorsque vous choisissez un type de disque. Lorsque vous libérez un système, les SSD locaux et éphémères sont supprimés. Sauvegardez les données sur ces disques, le cas échéant. |
| Azure Backup | Service qui fournit des solutions rentables pour sauvegarder vos données et les récupérer à partir du cloud Azure. | La sauvegarde est une solution fiable et économique qui protège votre infrastructure RHEL contre les défaillances ou altérations de la machine virtuelle. Utilisez la sauvegarde pour restaurer facilement l’intégralité de votre machine virtuelle ou des fichiers et dossiers spécifiques à partir du cloud, sans avoir à recréer la machine virtuelle ni perdre certaines données. Vous pouvez également utiliser d’autres solutions de partenaires prises en charge. |
| Azure Arc | Plateforme qui étend les services Azure afin qu’ils s’exécutent dans différents environnements, notamment dans des centres de données, des appareils de périphérie et des architectures multicloud. Utilisez Azure Arc afin d’assurer une gestion cohérente du développement, des opérations et de la sécurité pour les applications et les services. | Utilisez Azure Arc pour implémenter des sauvegardes et des supervisions automatisées et centralisées, ce qui augmente la résilience du point de vue de la BCDR. |
| Azure Site Recovery | Service qui fournit des fonctionnalités de reprise d’activité pour garantir la continuité de l’activité. Vous pouvez répliquer et gérer des charges de travail, notamment des machines virtuelles Azure et des machines virtuelles locales, dans différentes régions. Grâce à Site Recovery, vous pouvez configurer des processus de réplication, de basculement et de récupération pour protéger vos applications lors de pannes planifiées ou non planifiées. | Utilisez Site Recovery pour réduire les problèmes de récupération, diminuer les coûts d’infrastructure et garantir une récupération sécurisée et fiable entre les régions Azure ou depuis des emplacements locaux vers Azure. |
| Verrous de ressources | Fonctionnalité Azure que vous pouvez utiliser pour restreindre les utilisateurs et les rôles de votre organisation. Protégez vos ressources critiques contre les modifications accidentelles ou malveillantes. Vous pouvez verrouiller une ressource à différents niveaux, tels qu’au niveau de l’abonnement, du groupe de ressources ou des ressources individuelles. Selon le type de verrou, vous pouvez empêcher les utilisateurs de supprimer ou de modifier une ressource, mais ils peuvent toujours lire sa configuration. | Pour protéger toutes les infrastructures RHEL et les machines virtuelles de l’image de référence, utilisez des verrous de ressources. Pour éviter de perdre accidentellement des machines importantes, appliquez au moins le verrou Supprimer. Appliquez le verrou ReadOnly aux machines d’infrastructure RHEL, car elles ne changent pas souvent. Veuillez appliquer des modifications uniquement pendant les fenêtres de contrôle des modifications appropriées. |
Considérations BCDR relatives à la plateforme RHEL
Pour plus d’informations sur les fonctionnalités BCDR pour une infrastructure de plateforme RHEL, consultez :
- Architecture satellite à haute disponibilité.
- Architecture de haute disponibilité de la plateforme Ansible Automation.
- Architecture de haute disponibilité de gestion des identités.
Recommandations de conception
Pour les applications cloud natives dans des conteneurs Linux, utilisez une plateforme basée sur Kubernetes pour garantir la scalabilité, la haute disponibilité et la redondance. Envisagez d’utiliser la plateforme Azure Red Hat OpenShift ou un déploiement OpenShift autogéré avec un stockage répliqué ou géorépliqué.
Pour les applications web natives frontales et sans état, vous pouvez utiliser de nombreux services natifs Azure qui assurent la disponibilité des applications. Pour connaître les architectures qui utilisent ces services, consultez :
- Application web redondante interzone de base hautement disponible.
- Application web multirégion hautement disponible.
Les architectures précédentes utilisent différents services Azure pour les zones de disponibilité. L’architecture multirégion utilise des fonctionnalités de géoréplication pour le contenu et Azure Front Door en tant que service d’équilibrage de charge.
Pour de nombreuses applications avec état traditionnelles nécessitant une haute disponibilité, RHEL offre le module complémentaire de haute disponibilité Pacemaker. Vous pouvez obtenir des systèmes dotés de cette fonctionnalité à partir d’Azure Marketplace ou vous pouvez déployer une image personnalisée avec les composants logiciels nécessaires intégrés. Pour plus d’informations, consultez la page Configuration d’un cluster à haute disponibilité Red Hat sur Microsoft Azure.
Les problèmes de disponibilité ont une incidence sur les pannes de service et les temps de réponse du service. Une dégradation de services peut se produire, ce qui peut dégrader l’expérience du service de votre client. Pour vous assurer que vous maintenez les niveaux de performances et une capacité suffisante dans les régions requises, utilisez la fonctionnalité de réservation de capacité à la demande Azure.
Fiabilité
La plupart des concepts qui s’appliquent aux infrastructures des machines virtuelles IaaS (Infrastructure as a Service) s’appliquent également aux architectures RHEL. Pour plus d’informations, consultez la page Principes de conception de la fiabilité.
Clusters
Azure ne prend pas en charge la combinaison des services centraux du serveur d’applications et de la haute disponibilité de la base de données au sein d’un seul cluster Pacemaker RHEL. Pour passer outre cette limitation, séparez-les en clusters individuels. Vous pouvez combiner jusqu’à cinq clusters de services centraux dans une paire de machines virtuelles.
Pour BCDR sur SAP, envisagez les services suivants pour exécuter des clusters de services centraux SAP :
- Cluster Pacemaker RHEL : les appareils de bloc STONITH ne sont pas pris en charge, mais vous pouvez vous appuyer sur l’agent de clôture Azure.
- Logiciel de cluster non Microsoft certifié SAP : explorez cette option si elle correspond à vos besoins.
Choisissez le service approprié en fonction de vos besoins spécifiques et de votre système d’exploitation.
Pour plus d’informations, consultez l’article suivant :
- Configurez un cluster de haute disponibilité Red Hat sur Microsoft Azure pour RHEL 9.
- Configurez et gérez des clusters de haute disponibilité pour RHEL 9.
- Documentation RHEL 8.
Réplicas d’Azure Compute Gallery
Vous pouvez utiliser la galerie de calcul pour stocker des images de référence pour les déploiements. Utilisez ces images pour la reprise d’activité des applications et des outils. La galerie de calcul peut utiliser des ressources hautement disponibles avec des comptes de stockage redondant interzone (ZRS, Zone Redundant Storage) dans les régions qui prennent en charge les zones de disponibilité. Le stockage redondant interzone (ZRS) offre une résilience en cas de défaillances de zones. Vous pouvez également répliquer des images de la galerie vers d’autres régions ou zones géographiques.
Remarque
Nous vous recommandons d’avoir au moins deux galeries dans différentes régions.
Site Recovery
Site Recovery peut renforcer la résilience de certains composants RHEL. Pour obtenir la liste des serveurs de récupération de site RHEL pris en charge, consultez la matrice de prise en charge pour la reprise d’activité des machines virtuelles Azure avec Site Recovery. Vous pouvez également configurer Site Recovery pour effectuer un basculement d’environnements locaux vers le cloud. Pour obtenir une estimation des coûts de Site Recovery, utilisez le planificateur de déploiement Site Recovery.
Nœuds de cluster de récupération
Pour réduire les RTO et augmenter la résilience, vous pouvez utiliser des nœuds de cluster de récupération à distance actifs ou en attente. Vous devez configurer manuellement les éléments du cluster de reprise d’activité. Par exemple, vous devez appliquer des configurations pour configurer des ressources et copier des données.