Continuité d’activité et reprise d’activité pour l’accélérateur de zones d’atterrissage de Machines Virtuelles Oracle sur Azure
Cet article se base sur les considérations et recommandations définies dans la zone de conception de la zone d’atterrissage Azure pour la continuité des activités et la récupération d’urgence (BCDR). Cet article suit ces directives et décrit les considérations de conception et les bonnes pratiques concernant les options de BCDR pour les déploiements de charges de travail Oracle sur des machines virtuelles (VM) d’infrastructure Azure.
Azure fournit des services que vous pouvez utiliser pour concevoir des architectures hautement disponibles et résilientes. Ce guide décrit diverses options et bonnes pratiques pour vous aider à concevoir une haute disponibilité et une récupération d’urgence pour les bases de données Oracle sur l’accélérateur de zone d’atterrissage Azure Virtual Machines. Il décrit également comment configurer les services Azure accompagnants pour vous aider à atteindre une disponibilité de bout en bout élevée pour votre solution.
Bien démarrer
Pour construire une architecture résiliente pour votre environnement de charge de travail, déterminez les exigences de disponibilité pour votre solution en fonction de l’objectif de temps de récupération (RTO) et de l’objectif de point de récupération (RPO) pour divers niveaux de défaillance. Le RTO est le temps maximum pendant lequel une application reste indisponible après un incident. Le RPO est la quantité maximale de perte de données pendant une catastrophe. Une fois que vous avez déterminé les exigences pour votre solution, concevez votre architecture pour fournir les niveaux de résilience et de disponibilité établis.
Les charges de travail Oracle sur Azure utilisent principalement Oracle Data Guard, qui est une fonctionnalité intégrée de l’Oracle Database Enterprise Edition utilisant la technologie de réplication. Vous pouvez utiliser Data Guard pour répondre aux besoins de haute disponibilité et de récupération d’urgence. Data Guard offre trois modes de protection : performance maximale, disponibilité maximale et protection maximale. Choisissez votre mode de protection en fonction de votre conception architecturale et de vos exigences spécifiques en matière de RPO et de RTO.
Configurez votre charge de travail pour une haute disponibilité
Les instances Azure Virtual Machines exécutant des charges de travail Oracle bénéficient de l’architecture Azure Virtual Machine Scale Sets, en particulier le mode d’orchestration flexible. Une configuration de haute disponibilité fournit une réplication de données en quasi-temps réel avec des capacités de basculement potentiellement rapides. Une configuration de haute disponibilité ne protège pas contre les défaillances au niveau du datacenter Azure ou de la région.
Choisir l’option de haute disponibilité appropriée
Utilisez le schéma de flux suivant pour choisir la meilleure option de haute disponibilité pour votre base de données Oracle.
Utilisez Data Guard en mode de disponibilité maximale pour une haute disponibilité
Data Guard en mode de disponibilité maximale fournit la disponibilité la plus élevée avec une promesse de perte de données nulle (RPO = 0) pour les opérations normales. Pour une configuration hautement disponible de deux serveurs de base de données Oracle créés dans une orchestration flexible de Virtual Machine Scale Sets, Azure fournit une disponibilité de service de 99,95 % pour un accord de niveau de service (SLA) pour les instances réparties sur des domaines de panne. Azure fournit une disponibilité de service de 99,99 % pour les instances réparties sur des zones de disponibilité. Pour plus d’informations, consultez Haute disponibilité pour les Virtual Machine Scale Sets.
Pour une configuration pas à pas de Data Guard sur Azure, consultez Implémenter Oracle Data Guard sur une VM Azure basée sur Linux.
Utilisez Data Guard en mode de protection maximale pour une haute disponibilité
Si vous avez besoin d’une copie transactionnelle cohérente de votre base de données, envisagez d’utiliser Data Guard en mode de protection maximale. Cependant, le mode de protection maximale ne permet pas aux transactions de continuer lorsque la base de données de secours n’est pas disponible. Par conséquent, malgré l’utilisation de l’orchestration flexible de Virtual Machine Scale Sets, votre SLA est réduit à 99,9 % x 99,9 % = 99,8 % lorsque vous utilisez le mode de protection maximale. Cette configuration assure une copie cohérente des données, mais n’augmente pas nécessairement la disponibilité.
Les autres attributs de cette architecture sont les mêmes que ceux du mode de disponibilité maximale. Par exemple, le RPO est zéro et le RTO est inférieur ou égal à deux minutes.
Envisagez d’autres moyens de mettre en œuvre une haute disponibilité
Les sections suivantes décrivent des considérations spéciales relatives à la haute disponibilité.
Utilisez les zones de disponibilité pour améliorer la haute disponibilité
Les zones de disponibilité Azure sont des datacenters Azure situés dans la même région Azure. Les zones de disponibilité ont une latence aller-retour inférieure à deux millisecondes. Vous utilisez généralement les zones de disponibilité à des fins de récupération d’urgence, mais vous pouvez les utiliser pour améliorer la haute disponibilité. Si vous le faites, vous devez vous assurer que votre solution peut fonctionner avec la latence et le débit que fournissent vos zones de disponibilité.
Un avantage des zones de disponibilité avec une orchestration flexible de Virtual Machine Scale Sets est que votre SLA de disponibilité des VM augmente à 99,99 %.
Utilisez le clustering de stockage partagé pour la haute disponibilité
Les technologies de clustering de stockage partagé fournissent des attributs uniques qui peuvent vous aider à atteindre vos objectifs commerciaux. Par exemple, vous pouvez mettre en œuvre un cluster Pacemaker et Corosync (PCS) avec un stockage partagé. Vous pouvez utiliser des disques gérés ou Azure NetApp Files comme stockage partagé pour les instances de cluster PCS. Un cluster PCS ne duplique pas les données. Il fournit un service IP virtuel avec une adresse IP statique ou un nom de réseau IP qui ne change pas lors des basculements.
Remarque
Un cluster PCS n’est pas une solution certifiée Oracle. Gardez ce facteur à l’esprit lorsque vous choisissez votre architecture de haute disponibilité.
Utiliser des groupes de placements de proximité
Pour fournir la latence la plus faible possible, placez les machines virtuelles aussi proches que possible. Vous pouvez les déployer au sein d’un groupe de placement de proximité. Un groupe de placement de proximité est un regroupement logique qui garantit que les ressources de calcul Azure sont physiquement situées proches les unes des autres. Les groupes de placement de proximité sont utiles pour les charges de travail nécessitant une faible latence.
Configurez votre charge de travail pour la récupération d’urgence
Une architecture de récupération d’urgence fournit une résilience contre les défaillances qui affectent les datacenters ou les régions Azure ou contre les défaillances qui entravent la fonctionnalité des applications dans une région entière. Dans un tel scénario, vous devez déplacer l’ensemble de votre charge de travail vers un autre datacenter ou une autre région.
Choisissez votre architecture de récupération d’urgence en fonction des exigences de votre solution. Vous déterminez vos exigences en fonction de votre RTO et RPO. Les architectures de récupération d’urgence sont pour les cas de défaillance exceptionnels, donc les processus de basculement sont manuels. Dans la conception de haute disponibilité, les processus de basculement sont automatiques. Dans une architecture de récupération d’urgence, vous devez avoir des exigences plus souples pour le RTO et le RPO, ce qui permet d’économiser de l’argent.
Cet article se concentre sur les scénarios dans lesquels le serveur principal et les serveurs secondaires sont tous deux sur Azure. Vous pouvez également avoir un serveur principal sur site et un serveur secondaire sur Azure à des fins de récupération d’urgence. Pour plus d’informations, consultez Site principal sur site et site de récupération d’urgence sur Azure.
Choisir l’option de récupération d’urgence appropriée
Utilisez le schéma de flux suivant pour choisir la meilleure option de récupération d’urgence pour votre base de données Oracle.
Utilisez Data Guard pour la récupération d’urgence
Vous pouvez utiliser Data Guard pour répliquer des données vers votre site de récupération d’urgence. Utilisez ce site comme une autre zone de disponibilité dans la même région ou dans une région différente en fonction de vos besoins en matière de protection des données. Votre configuration dépend également de la structure de la zone de disponibilité sur votre site de production. Une implémentation de Data Guard dans un scénario de récupération d’urgence est similaire au scénario de haute disponibilité discuté précédemment, avec quelques différences importantes. Par exemple :
Lorsque vous basculez vers une réplique secondaire dans le scénario de haute disponibilité, vous configurez Azure Load Balancer pour rediriger les demandes vers la nouvelle instance de base de données principale.
Lorsque vous basculez vers le site de récupération d’urgence, vous basculez l’ensemble de la solution vers le nouveau site. Pour éviter les problèmes de latence, vous devez généralement configurer le basculement pour les services d’application.
Si le site de récupération d’urgence se trouve dans une autre région, vous devez concevoir le site pour le basculement en fonction de vos exigences.
La latence au sein d’un même datacenter est inférieure à celle entre les datacenters séparés et beaucoup moins élevée que celle entre différentes régions. Par conséquent, l’option la moins complexe et la moins coûteuse consiste à utiliser Data Guard en mode performance maximale à des fins de récupération d’urgence. Si la perte de données potentielle en mode performance maximale est trop élevée, vous pouvez utiliser le mode de disponibilité maximale avec le mécanisme Oracle Data Guard Far Sync. Mais une instance Far Sync déclenche la licence Active Data Guard sur l’environnement principal et l’environnement de secours. Pour plus d’informations, consultez détails de la licence Oracle.
De plus, lorsque vous envoyez des données à travers des régions ou des datacenters Azure, vous payez des frais de sortie pour les données, comme les journaux de redo, envoyées vers un site de récupération d’urgence. Si vous n’avez pas besoin de répliquer toutes les données de votre base de données, vous pouvez utiliser la réplication basée sur Oracle Golden Gate pour répliquer uniquement les données partielles nécessaires, ce qui réduit les coûts de sortie.
Pour une configuration pas à pas de Data Guard sur Azure, consultez Implémenter Data Guard sur une VM Azure basée sur Linux.
Utilisez Golden Gate pour la récupération d’urgence
Golden Gate est un logiciel de réplication logique que vous pouvez utiliser pour la réplication en temps réel, le filtrage et la transformation des données d’une base de données source vers une base de données cible ou entre plusieurs bases de données principales. Cette fonctionnalité garantit que les modifications de la base de données source sont répliquées en quasi-temps réel afin que la base de données cible soit à jour avec les dernières données.
Vous pouvez utiliser Golden Gate pour répliquer des données d’une base de données principale vers une base de données secondaire dans une configuration de récupération d’urgence. Golden Gate est particulièrement pratique si vous devez protéger uniquement certaines de vos données. Pour éviter la réplication de données inutiles, utilisez Golden Gate pour répliquer sélectivement des tables et filtrer les lignes de table pendant la réplication.
Pour un guide pas à pas sur la façon d’implémenter Golden Gate sur Azure, consultez Implémenter Golden Gate sur une VM Azure basée sur Linux.
Utilisez la sauvegarde pour la récupération d’urgence
La sauvegarde et la restauration sont une méthode traditionnelle pour une architecture de récupération d’urgence. Il y a deux composants principaux pour la sauvegarde en tant que méthode de récupération d’urgence pour les bases de données Oracle sur Azure :
Extraire et déplacer la sauvegarde des données d’une base de données pour garantir que le site de récupération d’urgence dispose de données à jour.
Assurer un déploiement à jour sur le site de récupération d’urgence. Pour mettre à jour le site, répliquez le même déploiement de tous les composants réseau, des serveurs d’applications et des configurations vers le site de récupération d’urgence.
Il existe plusieurs options de sauvegarde que vous pouvez utiliser pour répliquer des données. Pour plus d’informations, consultez Stratégies de sauvegarde pour Oracle Database sur Azure.
Envisagez d’utiliser l’une des approches suivantes pour maintenir un site de récupération d’urgence :
Approche 1 : Pour éviter des efforts de maintenance supplémentaires et des coûts, ne maintenez aucun déploiement physique sur le site de récupération d’urgence. Vous pouvez utiliser l’infrastructure en tant que code et les pratiques d’ingénierie de fiabilité du site pour développer et maintenir un référentiel. Ce référentiel peut répliquer le déploiement en tant que configuration sur un site de récupération d’urgence au moment du basculement. Cette méthode optimise les coûts car elle n’utilise aucune ressource physique jusqu’à ce que le basculement se produise.
Important
Si vous créez un déploiement complet à partir de zéro lors d’un basculement, vous devez vous assurer que votre déploiement peut répondre aux exigences de RTO de la solution. Pour garantir que le code de déploiement n’est pas cassé, vous devez simuler et tester régulièrement le scénario de récupération d’urgence.
Approche 2 : Déployez et maintenez une version évolutive de votre environnement de production. Ayez une version qui peut fonctionner correctement pour une petite charge de travail et que vous pouvez éventuellement augmenter en cas de besoin lors d’un basculement pour servir la charge de production. Cette méthode est couramment utilisée, en particulier pour les déploiements complexes où vous ne voulez pas risquer de créer un environnement complet ou si vous souhaitez basculer rapidement pour fournir un RTO faible.
Approche 3 : Déployez et maintenez l’intégralité de votre solution sur le site de récupération d’urgence pour des temps de RTO et de basculement les plus rapides. Cette méthode augmente les coûts en raison de l’exploitation d’une infrastructure entièrement redondante.
Envisagez d’autres moyens de mettre en œuvre la récupération d’urgence
Les sections suivantes décrivent des considérations particulières relatives à la récupération d’urgence.
Utilisez Far Sync
Far Sync n’améliore pas les capacités de haute disponibilité, mais vous pouvez l’utiliser pour atteindre des capacités de protection contre la perte de données pour les bases de données Oracle. Votre charge de travail peut nécessiter une perte de données nulle si votre base de données principale échoue. Pour plus d’informations, consultez Architectures de référence Oracle sur Azure.
Choisir la technologie de réplication de données appropriée
En plus des technologies mentionnées dans cet article, vous pouvez utiliser toute technologie qui facilite la réplication des données entre deux bases de données Oracle pour maintenir une réplique de haute disponibilité et une réplique de récupération d’urgence pour vos bases de données Oracle sur Azure. La technologie que vous choisissez doit répondre aux exigences de votre solution dans ces catégories.
Latence : Le temps nécessaire pour répliquer une mise à jour d’une base de données principale vers des bases de données secondaires pour la haute disponibilité et la récupération d’urgence doit respecter les exigences de votre solution.
Largeur de bande : La quantité et le coût de la largeur de bande nécessaires pour répliquer les données vers des bases de données secondaires pour la haute disponibilité et la récupération d’urgence. Azure fournit une infrastructure réseau à haute vitesse entre les zones de disponibilité. Lorsque vous envisagez la réplication vers d’autres régions Azure à des fins de récupération d’urgence, considérez la quantité de bande passante et les coûts de sortie des données qui quittent le datacenter Azure.
Impact : Le niveau d’impact que la réplication a sur le traitement des transactions sur la base de données principale doit respecter les exigences de votre solution.
Perte de données : La quantité de perte de données que vous attendez lors d’une défaillance brutale de la base de données principale doit respecter les exigences de votre solution.
Coût total de possession : Considérez le coût d’acquisition d’une solution de réplication non Microsoft et la quantité d’effort nécessaire pour configurer et maintenir la solution de réplication. Vérifiez que ces facteurs respectent les exigences de votre solution.
Optimisez une instance de basculement
Lorsque vous utilisez Data Guard en mode haute disponibilité ou en mode protection maximale, vous pouvez configurer un basculement automatique pour que lorsque le serveur principal échoue, le serveur secondaire soit automatiquement activé. Lorsque vous configurez correctement les serveurs d’applications, vous pouvez vous assurer que vous n’avez presque pas de temps d’arrêt des applications pendant un basculement.
Dans cette implémentation, une base de données doit fonctionner de la même manière après un basculement. Vous devez donc configurer un serveur secondaire avec la même capacité de processeur, de mémoire et d’entrée/sortie (I/O) que le serveur principal. Vous devez maintenir une haute capacité avec un serveur secondaire, ce qui augmente vos coûts Azure et les coûts de licence Oracle Database. Le serveur secondaire ne traite généralement pas les demandes des utilisateurs.
Azure fournit une disponibilité de 99,9 % pour les machines virtuelles dans une zone de disponibilité. Pour plus d’informations, consultez SLA de disponibilité des VM. Lorsque vous utilisez une technologie de réplication des données pour maintenir une réplique secondaire de votre base de données dans la même zone de disponibilité, une zone de disponibilité différente ou une région différente, vous pouvez optimiser la capacité secondaire.
Avec cette approche, la base de données secondaire est configurée avec la capacité nécessaire pour rester à jour. Lorsqu’une défaillance se produit, la base de données secondaire est redimensionnée à la même capacité que la base de données principale. Cette opération se produit uniquement en cas de défaillance. Ainsi, pendant le fonctionnement normal, vous ne payez qu’une fraction du coût du serveur principal. La base de données principale n’est pas opérationnelle pendant la défaillance, vous n’avez donc pas besoin d’autres licences de base de données Oracle.
La capacité dont vous avez besoin pour exploiter une base de données secondaire en tant que destination de réplication dépend de la technologie de réplication que vous utilisez. Essentiellement, une charge de travail sur un système de traitement transactionnel en ligne (OLTP) transactionnel a principalement des requêtes de lecture. Par exemple, des opérations de lecture à 90 % et des opérations d’écriture à 10 % ou des opérations de lecture à 95 % et des opérations d’écriture à 5 % sont courantes dans les applications OLTP. La réplication des données réplique essentiellement le résultat de l’écriture de requêtes dans la base de données source. Avec cette configuration, vous pouvez vous attendre à ce que la base de données secondaire fonctionne avec 1/10 (si vous avez un ratio de lecture de 90 % et d’écriture de 10 %) de la capacité de la base de données principale.
Automatisez les procédures de basculement pour garantir que vous respectez les normes de l’entreprise pendant le processus de basculement. Vous pouvez configurer les procédures de basculement pour inclure les opérations de redimensionnement des serveurs qui rationalisent le processus de bout en bout.
Configurez votre topologie réseau pour la protection des services et des données
Pour atteindre une haute disponibilité et une récupération d’urgence, vous devez prendre des décisions financières et commerciales qui équilibrent le temps de récupération, ou RTO, et la perte de données potentielle, ou RPO, par rapport aux autres coûts de licence Oracle, de service des VM et de transfert de données. Lorsque vous hébergez une charge de travail sur une seule VM Azure, vous obtenez une protection de base contre les défaillances matérielles courantes à faible coût. Mais une défaillance sur une seule VM est susceptible de causer des temps d’arrêt et une perte de données. Ainsi, dans vos environnements de production, incluez au moins une base de données Oracle secondaire hébergée sur une VM distincte avec Data Guard. En fonction de vos exigences, utilisez une ou plusieurs des configurations Data Guard suivantes pour la réplication des données :
RTO et RPO optimaux. Pour minimiser la latence, incorporez une base de données Oracle secondaire sur une VM distincte au sein de la même orchestration flexible de Virtual Machine Scale Sets et dans la même zone de disponibilité que la base de données principale. Cette configuration fournit une haute disponibilité et une protection contre une défaillance d’instance unique.
Protection des données contre une défaillance du datacenter. Placez la base de données Oracle secondaire dans une deuxième zone de disponibilité pour fournir une configuration de haute disponibilité et une protection en cas de défaillance d’un datacenter entier. Cette configuration peut avoir jusqu’à deux millisecondes de latence entre la base de données principale et la base de données secondaire, ce qui peut affecter les performances, les RTO et les RPO.
Protection des données contre une défaillance régionale. Pour aider à protéger contre la perte de données potentielle due à une défaillance régionale d’Azure, vous pouvez placer la base de données secondaire dans une autre région. Cette configuration peut avoir entre 30 millisecondes et 300 millisecondes de latence entre les régions, de sorte que vous pourriez ne pas atteindre vos objectifs de RTO et de RPO. Cette solution est meilleure pour la récupération d’urgence régionale plutôt que pour la haute disponibilité.
La continuité des activités nécessite une approche intégrée incluant tous les composants d’une charge de travail. L’infrastructure réseau est un composant principal pour toute charge de travail sur Azure. Votre infrastructure réseau doit être alignée avec votre architecture de haute disponibilité ou de récupération d’urgence. Considérez les facteurs d’infrastructure réseau suivants :
Data Guard fournit une haute disponibilité et, dans la plupart des scénarios, fournit un support suffisant pour les défaillances courantes. Vous pouvez placer des VM dans une orchestration flexible de Virtual Machine Scale Sets. Pour réduire la latence du réseau, tous les services d’une seule solution doivent se trouver dans la même zone de disponibilité, et les services doivent partager le même réseau virtuel.
Pour une protection supplémentaire, vous pouvez placer stratégiquement des VM dans des zones de disponibilité distinctes plutôt que dans une seule zone de disponibilité. Cette approche peut prévenir les temps d’arrêt pendant une défaillance de datacenter.
Pour une protection maximale, vous pouvez placer une base de données secondaire dans une région Azure différente de celle de la base de données principale. Pour appliquer des mises à jour continues, vous pouvez utiliser Data Guard pour mettre en œuvre l’appairage de réseaux virtuels mondiaux. Utilisez cette approche pour appliquer des mises à jour de données à la région secondaire en privé via le backbone Microsoft. Les ressources communiquent directement sans passerelles, sauts supplémentaires ou transit par Internet public.
Cette option de mise en réseau fournit une connexion à large bande passante et à faible latence entre les réseaux virtuels appairés dans différentes régions. Vous pouvez utiliser l’appairage de réseaux virtuels mondiaux pour connecter votre site principal à un site de récupération d’urgence dans une autre région via un réseau à haute vitesse.
Résumé de la résilience contre divers types de défaillance
| Scénario de défaillance | Scénario de haute disponibilité ou de récupération d’urgence pour Oracle sur Azure | RPO/RTO |
|---|---|---|
| Défaillance d’un composant unique, comme un hôte, un rack, un refroidissement, un réseau ou une défaillance d’alimentation | Data Guard avec deux nœuds dans la même orchestration flexible de Virtual Machine Scale Sets dans le même datacenter : - Protège contre une défaillance d’instance unique. - Cause des temps d’arrêt si un datacenter entier échoue. |
Si vous utilisez Observer pour un basculement rapide et le mode MAX_AVAILABILITY ou MAX_PROTECTION pour Data Guard : - Le RPO est zéro. - Le RTO est inférieur ou égal à 2 min. |
| Défaillance du datacenter | Data Guard avec deux nœuds dans des zones de disponibilité distinctes : - Protège contre une défaillance du datacenter. - Cause des temps d’arrêt si une région entière échoue. – Nécessite une configuration de basculement supplémentaire pour permettre la gestion de la latence du réseau par les serveurs d’applications. |
- Le RPO est inférieur ou égal à 5 min. - Le RTO est inférieur ou égal à 5 min. Si vous utilisez le mode MAX_PERFORMANCE et le mode MAX_AVAILABILITY pour Data Guard : - Le RPO est zéro. - Le RTO est inférieur ou égal à 5 min. |
| Défaillance au niveau d’une région | Data Guard avec deux nœuds dans des régions Azure distinctes : – Protège contre les défaillances régionales. – Nécessite une configuration de basculement supplémentaire pour permettre la gestion de la latence du réseau par les serveurs d’applications. |
Si vous utilisez le mode MAX_PERFORMANCE pour Data Guard : - Le RPO est supérieur ou égal à 10 min. - Le RTO est supérieur ou égal à 15 min. |
| Tous les scénarios : défaillance d’un composant unique, du datacenter et de la région | Sauvegardes expédiées vers une autre région Azure : - Protège contre les défaillances régionales. - Nécessite la mise en place d’un environnement Azure complet dans la région cible pendant un basculement. |
- Le RPO est supérieur ou égal à 24 h. - Le RTO est supérieur ou égal à 4 h. |
Étape suivante
Apprenez les considérations de conception pour la sécurité de l’accélérateur de zone d’atterrissage Oracle sur Virtual Machines dans un scénario à l’échelle de l’entreprise.