Partager via

Architectures pour base de données Oracle sur les machines virtuelles Azure

  • Article

S’applique à : ✔️ Machines virtuelles Linux

Cet article inclut des informations détaillées sur le déploiement d'une base de données Oracle à haut niveau de disponibilité sur Azure. Il comprend également des informations sur la récupération d'urgence. Ces architectures ont été créées à partir de déploiements clients. Ce guide s'applique uniquement à Oracle Database Enterprise Edition.

Si vous souhaitez en savoir plus sur l'optimisation des performances de votre base de données Oracle, consultez Créer et implémenter une base de données Oracle sur Azure.

Prérequis

  • Des connaissances sur les différents concepts d'Azure, comme les zones de disponibilité
  • Oracle Database Enterprise Edition 12c ou version ultérieure
  • Avoir conscience des implications inhérentes à l'utilisation des solutions mentionnées dans cet article en matière de licences et vous les acceptez
  • Exigences définies pour les RPO et RTO

Haute disponibilité des bases de données Oracle

Quelle que soit l'organisation, la haute disponibilité dans le cloud est un aspect important de la planification et de la conception. Azure fournit des zones de disponibilité et des groupes à haute disponibilité à utiliser dans les régions où les zones de disponibilité ne sont pas prises en charge. Pour plus d’informations sur la conception pour le cloud, consultez Options de disponibilité pour les machines virtuelles Azure.

Outre les outils et offres natifs du cloud, Oracle fournit des solutions à haut niveau de disponibilité qui peuvent être configurées sur Azure :

Ce guide propose des architectures de référence pour chacune de ces solutions.

Lorsque vous migrez ou créez des applications pour le cloud, nous vous recommandons d’utiliser des modèles natifs cloud tels que le modèle de nouvelle tentative et le modèle de disjoncteur. Pour obtenir d’autres modèles susceptibles de rendre votre application plus résiliente, consultez le Guide des modèles de conception cloud.

Oracle RAC dans le cloud

Oracle Real Application Cluster (RAC) est une solution Oracle qui permet aux clients de bénéficier de débits élevés en utilisant plusieurs instances qui accèdent à un même espace de stockage de base de données. Ce modèle est une architecture partagée. Le RAC Oracle peut être utilisé pour une haute disponibilité locale, mais ne peut pas être utilisé seul pour une haute disponibilité sur le cloud. Oracle RAC protège uniquement contre les défaillances de niveau instance et non contre les défaillances au niveau du rack ou du centre de données. C'est la raison pour laquelle Oracle vous recommande d'utiliser Oracle Data Guard avec votre base de données, qu'il s'agisse d'une instance unique ou RAC, pour la haute disponibilité.

Les clients ont généralement besoin d'un contrat de niveau de service (SLA) de niveau élevé pour exécuter leurs applications stratégiques. Oracle ne certifie pas ou ne prend pas en charge Oracle RAC sur Azure. Cependant, Azure vous propose des fonctionnalités telles que les zones de disponibilité et les fenêtres de maintenance planifiée pour vous protéger contre les défaillances au niveau de l’instance. En plus de ces offres, vous pouvez utiliser Oracle Data Guard, Oracle GoldenGate et Oracle Sharding pour des performances et une résilience élevées. Ces technologies peuvent vous aider à protéger vos bases de données contre les défaillances au niveau du rack, au niveau du centre de données et de la géopolitique.

Lorsque vous exécutez Oracle Databases sur plusieurs zones de disponibilité avec Oracle Guard ou GoldenGate, vous pouvez bénéficier d'un contrat de niveau de service (SLA) garantissant un temps d'activité de 99,99 %. Dans les régions Azure où les zones de disponibilité ne sont pas encore prises en charge, vous pouvez utiliser des groupes à haute disponibilité et bénéficier d'un contrat de niveau de service (SLA) garantissant un temps d'activité de 99,95 %.

Notes

vous pouvez viser un temps d'activité bien plus élevé que le contrat de niveau de service (SLA) fourni par Microsoft.

Récupération d'urgence pour les bases de données Oracle

Lorsque vous hébergez vos applications stratégiques dans le cloud, il est impératif de prévoir une haute disponibilité et une récupération d'urgence.

Pour Oracle Database Enterprise Edition, Oracle Data Guard est une fonctionnalité utile en termes de récupération d'urgence. Vous pouvez mettre en place une base de données de secours dans une région Azure couplée et configurer le basculement Data Guard pour la récupération d'urgence. Pour ne perdre aucune donnée, nous vous recommandons de déployer une instance d'Oracle Data Guard Far Sync en plus d'Active Data Guard.

Pour la réplication de données de longue distance, il est recommandé d’utiliser Far Sync. Far Sync est une fonctionnalité Oracle Active Data Guard.

Remarque

Si vous activez Far Sync, une licence Active Data Guard est nécessaire. Contactez votre représentant Oracle pour discuter des implications des licences.

Oracle Far Sync traite une longue distance entre la base de données primaire et la base de données secondaire en introduisant un serveur intermédiaire appelé instance Far Sync. Ce serveur reçoit les données de rétablissement de la base de données primaire, puis les transfère à la base de données de secours. Ainsi, l’instance Far Sync est placée plus près du serveur principal pour réduire le temps de communication. Le serveur Far Sync transfère ensuite les données de rétablissement de manière asynchrone à la base de données secondaire.

Remarque

Lorsque vous utilisez des bases de données Oracle Standard Edition, vous pouvez avoir recours à des solutions ISV telles que DBVisit Standby ou Tessell pour configurer la haute disponibilité et la récupération d'urgence.

Architectures de référence

Oracle Data Guard

Oracle Data Guard garantit la haute disponibilité, la protection des données et la récupération d'urgence des données d'entreprise. Data Guard gère les bases de données de secours en tant que copies cohérentes au niveau transactionnel de la base de données primaire. Selon la distance entre les bases de données primaire et secondaires et la tolérance de l'application en termes de latence, vous pouvez mettre en place une réplication synchrone ou asynchrone.

Oracle Data Guard avec Fast-Start Failover

Data Guard peut être déployé à l’aide du basculement de démarrage rapide (FSFO). Fast-Start Failover (FSFO) est une fonctionnalité de la configuration Data Guard Broker permettant un basculement automatique en cas de défaillance. Cette fonctionnalité vous permet de basculer automatiquement en cas de défaillance. Le temps par défaut utilisé par les clients est de 30 secondes, mais peut être ajusté en fonction de vos besoins. Cette opération appelée OperationTimeout fait partie des propriétés Data Guard que vous définissez pendant votre déploiement.

Fonctionnement de Data Guard avec cette propriété

La tâche de Data Guard est de surveiller en continu l'état de santé et le statut des bases de données principale et secondaire. Dès que vous activez le basculement rapide (FSFO), le processus d’observateur est déclenché et passe en revue l’état d’intégrité à intervalles réguliers pour garantir une haute disponibilité à tout moment.

À présent, si la base de données principale devient indisponible, l’observateur et Data Guard Broker détectent cette interruption. Par conséquent, le paramètre OperationTimeout de 30 secondes spécifie la durée pendant laquelle le répartiteur doit attendre une réponse de la base de données primaire avant d’entreprendre une action supplémentaire.

Ce qui aboutit ensuite si le serveur principal ne répond pas dans cette fenêtre de 30 secondes, l’Observateur suppose que le serveur principal est inaccessible et commence le processus de basculement.

Le répartiteur promeut immédiatement la base de données de secours à l’état principal, en basculant les rôles et en veillant à ce que l’application puisse reprendre rapidement à partir du serveur de secours.

Pendant ce temps, le répartiteur garantit également que les transactions sont à jour sur le serveur de secours. Avec le mode que vous configurez, il peut s’agir d’une disponibilité maximale ou d’une protection maximale, une réplication synchrone fournit une perte de données minimale à zéro. Les bases de données Oracle sont placées dans différentes zones de disponibilité pour assurer la haute disponibilité. Chaque zone de disponibilité est composée d'un ou de plusieurs centres de données équipés d'une alimentation, d'un système de refroidissement et d'un réseau indépendants. Pour garantir la résilience, au moins trois zones distinctes sont configurées dans toutes les régions activées. La séparation physique des zones de disponibilité au sein d'une région protège les données contre les défaillances du centre de données. En outre, deux observateurs FSFO sont configurés dans deux zones de disponibilité afin d'initier le basculement vers la base de données secondaire en cas de défaillance. Après le basculement, lorsque votre base de données principale précédente est de nouveau disponible, elle peut être réintégrée. Data Guard Broker facilite ce processus.

En fin de compte, si la base de données primaire n’est pas disponible en raison d’une panne planifiée ou non planifiée, Data Guard bascule ou transfère l'activité vers votre base de données de secours.

Cette fonctionnalité peut fournir une résilience supplémentaire en configurant l’observateur sur une machine virtuelle distincte. Vous déployez ainsi l’observateur sur une machine virtuelle légère. Cette approche permet une haute disponibilité et de la résilience.

Avec Oracle Database 12.2 et versions ultérieures, il est également possible de configurer plusieurs observateurs avec la configuration d'un seul répartiteur Oracle Data Guard. Elle fournit une disponibilité supplémentaire, au cas où un observateur et le temps d’arrêt de la base de données secondaire. Pour plus d’informations sur Data Guard Broker et ses avantages, consultez Concepts d’Oracle Data Guard Broker.

Le diagramme suivant montre une installation d’Oracle Data Guard sans Far Sync avec une durée de récupération inférieure à 5 minutes.

Diagramme montrant une architecture Oracle Data Guard.

Les bases de données Oracle sont placées dans différentes zones de disponibilité pour assurer la haute disponibilité. Chaque zone de disponibilité est composée d'un ou de plusieurs centres de données équipés d'une alimentation, d'un système de refroidissement et d'un réseau indépendants. Pour garantir la résilience, au moins trois zones distinctes sont configurées dans toutes les régions activées. La séparation physique des zones de disponibilité au sein d'une région protège les données contre les défaillances du centre de données. En outre, deux observateurs FSFO sont configurés dans deux zones de disponibilité afin d'initier le basculement vers la base de données secondaire en cas de défaillance.

Remarque

Lorsque vous planifiez un déploiement de Data Guard symétrique, notez que vous aurez besoin d’un observateur supplémentaire dans la zone de disponibilité trois.

Par ailleurs, nous vous recommandons vivement de déployer Oracle Enterprise Manager pour continuer à avoir une vue d’ensemble de la couche de base de données. Azure Monitor est recommandé pour être déployé avec les métriques suivantes : Surveillez les disques :

  • Pourcentage d’IOPS du disque de système d’exploitation consommées
  • Pourcentage d’IOPS du disque de données consommées
  • Octets lus/s sur disque de données
  • Octets écrits/s sur disque de données
  • Longueur de file d’attente de disque
  • Bande passante du disque en % par Lun

En plus des éléments ci-dessus, nous vous recommandons vivement d’activer également VM Insights.

La machine virtuelle est choisie en fonction de votre évaluation AWR. Pour plus d’informations, consultez Planification de la capacité Oracle. Nous vous recommandons vivement d’utiliser des processeurs virtuels au noyau contraint pour économiser sur les coûts de licence et optimiser les performances.

Le choix du type de disque dépend du résultat de votre évaluation AWR.

Comme mentionné ci-dessus, Far Sync est une fonctionnalité principalement utilisée dans les scénarios où vous répliquez entre les régions qui dépassent de longues distances. Dans ce contexte, Oracle Active Data Guard Far Sync offre une capacité de protection avec zéro perte de données pour les bases de données Oracle. L’instance Oracle Far Sync doit être installée sur une machine virtuelle distincte.

Les disques SSD Premium v2 ne sont pas pris en charge pour les fichiers liés au système d'exploitation. Pour plus d’informations, consultez Déployer SSD Premium v2.

Azure Premium Files est utilisé pour la destination de sauvegarde. Cette solution est la plus performante. Vous pouvez également utiliser le stockage Blob Azure comme destination de sauvegarde. Veillez toujours à tester l’option qui vous convient le mieux. Veuillez également consulter Stratégies de sauvegarde Oracle Database.

Oracle Data Guard Far Sync

Comme mentionné ci-dessus, Far Sync est une fonctionnalité principalement utilisée dans les scénarios où vous répliquez entre les régions qui dépassent de longues distances. Dans ce contexte, Oracle Far Sync offre une capacité de protection avec zéro perte de données pour les bases de données Oracle. L'instance Oracle Far Sync doit être installée sur une machine virtuelle (VM) distincte.

Pour la protection contre la perte de données, une communication synchrone doit être établie entre votre base de données primaire et l'instance de Far Sync. L'instance de Far Sync reçoit la restauration de la base de données primaire de manière synchrone et la transmet immédiatement à toutes les bases de données de secours de manière asynchrone. Cette configuration réduit également la surcharge qui pèse sur la base de données primaire, car elle envoie uniquement la restauration à l'instance de Far Sync, et non à toutes les bases de données de secours. En cas de défaillance d'une instance de Far Sync, Active Data Guard utilise automatiquement le transport asynchrone de la base de données primaire vers la base de données secondaire pour que la protection contre la perte de données reste assurée. Afin de renforcer la résilience, les clients peuvent déployer différentes instances de Far Sync pour chaque base de données, notamment primaires et secondaires.

Le diagramme suivant illustre une architecture qui utilise Oracle Active Data Guard FSFO et Far Sync pour bénéficier de la haute disponibilité et de la récupération d'urgence :

Diagramme montrant Oracle Database en utilisant Far Sync dans une configuration Active Data Guard entre les régions.

Remarque

Lorsque vous planifiez un déploiement symétrique de Far Sync, notez que vous aurez besoin d’une autre instance Far Sync dans la deuxième région.

Oracle GoldenGate

GoldenGate permet l'échange et la manipulation de données au niveau des transactions entre différentes plateformes hétérogènes de l'entreprise. Il déplace les transactions validées en garantissant l'intégrité des transactions et en minimisant les frais généraux sur votre infrastructure existante. Son architecture modulaire vous donne la possibilité d'extraire et de répliquer les enregistrements de données sélectionnés, les modifications relatives aux transactions et les modifications apportées au langage de définition de données (DDL) à travers une variété de topologies.

Oracle GoldenGate vous permet de configurer votre base de données pour la haute disponibilité en fournissant une réplication bidirectionnelle. Cette approche vous permet de mettre en place une configuration multimaître ou une configuration active-active qui nécessite une prise de conscience au niveau de l’application. Le diagramme suivant illustre une architecture recommandée pour une configuration active/active d'Oracle GoldenGate sur Azure. Dans l'architecture suivante, la base de données Oracle a été configurée à l'aide d'une machine virtuelle à mémoire optimisée « hyperthreadée » avec des processeurs virtuels à cœur restreint pour économiser sur les coûts de licence et optimiser les performances. Cette architecture utilise différents disques Premium ou Ultra (disques managés) pour les performances et la disponibilité.

Diagramme montrant Oracle Database utilisant des zones de disponibilité avec Data Guard Broker - FSFO.

Notes

Une architecture similaire peut être mise en place à l'aide de groupes à haute disponibilité dans les régions où les zones de disponibilité ne sont actuellement pas prises en charge.

Oracle GoldenGate dispose de processus tels que Extract, Pump et Replicat pour vous aider à répliquer vos données de manière asynchrone d'un serveur de base de données Oracle vers un autre. Ces processus vous permettent de mettre en place une réplication bidirectionnelle pour garantir la haute disponibilité de votre base de données en cas de temps d'arrêt au niveau de la zone de disponibilité.

Dans le diagramme précédent, le processus Extract s’exécute sur le même serveur que votre base de données Oracle. Les processus Data Pump et Replicat s’exécutent sur un autre serveur dans la même zone de disponibilité. Le processus Replicat est utilisé pour recevoir les données de la base de données située dans l'autre zone de disponibilité et valider les données de la base de données Oracle dans sa zone de disponibilité. De même, le processus Data Pump envoie les données qui ont été extraites par le processus Extract au processus Replicat dans l'autre zone de disponibilité.

Bien que le diagramme d'architecture précédent illustre le processus Data Pump et Replicat configuré sur un serveur distinct, vous pouvez configurer tous les processus Oracle GoldenGate sur le même serveur, en fonction de la capacité et de l'utilisation de votre serveur. Consultez toujours votre rapport AWR et les mesures disponibles dans Azure pour identifier le modèle d'utilisation de votre serveur.

Lors de la configuration de la réplication bidirectionnelle Oracle GoldenGate dans différentes zones de disponibilité ou différentes régions, vous devez vous assurer que la latence entre les différents composants est acceptable pour votre application. La latence entre les zones de disponibilité et les régions peut varier. La latence dépend de plusieurs facteurs. Nous vous recommandons de mettre en place des tests de performances entre votre couche Application et votre couche Base de données dans différentes zones de disponibilité ou régions. Les tests peuvent confirmer que la configuration répond aux exigences de performances de votre application.

La couche Application peut être configurée dans son propre sous-réseau et la couche Base de données peut être distincte au sein de son propre sous-réseau. Dans la mesure du possible, tâchez d'utiliser Azure Application Gateway pour équilibrer la charge du trafic entre vos serveurs d'applications. Application Gateway est un équilibreur de charge de trafic web robuste. Il fournit une affinité de session basée sur les cookies qui permet de garder une session utilisateur sur le même serveur, minimisant ainsi les conflits sur la base de données. Les alternatives à Application Gateway sont Azure Load Balancer et Azure Traffic Manager.

Oracle Sharding

Sharding (partitionnement) est un modèle de la couche Données qui a été introduit dans Oracle 12.2. Il vous permet de partitionner horizontalement vos données et de les mettre à l'échelle dans des bases de données indépendantes. Il s’agit d’une architecture sans partage où chaque base de données est hébergée sur une machine virtuelle dédiée. Ce modèle permet un débit de lecture et d’écriture élevé en plus de la résilience et d’une disponibilité accrue.

Ce modèle élimine les points de défaillance uniques, isole les défaillances et permet des mises à niveau propagées sans temps d'arrêt. Les temps d'arrêt d'une partition ou les défaillances au niveau du centre de données n'affectent pas les performances ou la disponibilité des autres partitions dans les autres centres de données.

Le partitionnement convient aux applications OLTP à débit élevé qui ne peuvent se permettre aucun temps d'arrêt. Toutes les lignes ayant la même clé de sharding seront sur la même étendue. Ceci augmente les performances, offrant une cohérence élevée. Les applications qui utilisent le partitionnement doivent disposer d’un modèle de données et d’une stratégie de distribution des données bien définis, comme un hachage cohérent, une plage, une liste ou un composite. La stratégie accède principalement aux données à l’aide d’une clé de partitionnement, par exemple customerId ou accountNum. Le partitionnement vous permet également de stocker des ensembles particuliers de données plus près des clients finaux, ce qui aide à satisfaire les exigences de performances et de conformité.

Nous vous recommandons de répliquer vos partitions pour bénéficier de la haute disponibilité et de la récupération d'urgence. Cette configuration peut être effectuée à l'aide de technologies Oracle telles qu'Oracle Data Guard ou Oracle GoldenGate. Une unité de réplication peut être une partition, une partie d'une partition ou un groupe de partitions. Une panne ou un ralentissement d’une ou plusieurs partitions n’affecte pas la disponibilité d’une base de données partitionnée.

Pour la haute disponibilité, les partitions de secours peuvent être placées dans la même zone de disponibilité que les partitions primaires. Pour la récupération d'urgence, les partitions de secours peuvent se trouver dans une autre région. Vous pouvez également déployer des partitions dans différentes régions pour gérer le trafic de ces régions. Pour en savoir plus sur la configuration de la haute disponibilité et la réplication de votre base de données partitionnée, consultez Haute disponibilité au niveau de la partition.

Oracle Sharding se compose principalement des composants suivants. Pour plus d’informations, consultez Vue d’ensemble du partitionnement Oracle :

  • Catalogue de partition. Base de données Oracle à usage spécifique ; il s'agit d'un magasin persistant contenant toutes les données de configuration des bases de données de partitions. Toutes les modifications de la configuration, telles que l'ajout ou la suppression de partitions, le mappage des données et les modifications apportées aux langages de définition de données (DDL) d'une base de données de partitions, sont initiées à partir du catalogue de partitions. Le catalogue de partitions contient également la copie principale de toutes les tables dupliquées d'une instance de SDB.

    Le catalogue de partitions utilise des vues matérialisées pour répliquer automatiquement les modifications apportées aux tables dupliquées sur toutes les partitions. La base de données du catalogue de partitions joue également le rôle de coordinateur de requêtes pour traiter les requêtes sur plusieurs partitions et les requêtes qui ne spécifient pas de clé de sharding.

    Nous vous recommandons d’utiliser Oracle Data Guard avec des zones de disponibilité ou des groupes à haute disponibilité pour la haute disponibilité du catalogue de partitions. La disponibilité du catalogue de partitions n'a aucun effet sur la disponibilité de la base de données partitionnée. Un temps d'arrêt au niveau du catalogue de partitions affecte uniquement les opérations de maintenance et les requêtes sur plusieurs partitions pendant le bref laps de temps nécessaire au basculement de Data Guard. La SDB continue d’acheminer et d’exécuter des transactions en ligne. Une panne de catalogue ne les affecte pas.

  • Directeurs de partitions. Services allégés qui doivent être déployés dans chacune des régions/zones de disponibilité hébergeant vos partitions. Les directeurs de partitions sont des gestionnaires de services globaux déployés dans le contexte d'Oracle Sharding. Pour la haute disponibilité, nous vous recommandons de déployer au moins un directeur de partition dans chacune des zones de disponibilité où vous disposez de partitions.

    Lors de la connexion initiale à la base de données, le directeur de partitions configure les informations de routage et met en cache les informations pour les demandes suivantes, qui contournent le directeur de partition. Une fois la session établie avec une partition, toutes les requêtes SQL et tous les langages de manipulation de données (DML) sont pris en charge et exécutés dans le cadre de la partition concernée. Ce routage est rapide et il est utilisé pour toutes les charges de travail OLTP qui effectuent des transactions intra-partition. Nous vous recommandons d'utiliser le routage direct pour toutes les charges de travail OLTP qui nécessitent des performances et une disponibilité maximales. Le cache du routage s'actualise automatiquement lorsqu'une partition devient indisponible ou que la topologie de partitionnement est modifiée.

    Pour un routage haute performance dépendant des données, Oracle recommande d'utiliser un pool de connexions lors de l'accès aux données de la base de données partitionnée. Les pools de connexions Oracle, les bibliothèques spécifiques à une langue et les pilotes prennent en charge Oracle Sharding. Pour plus d’informations, consultez Vue d’ensemble du partitionnement Oracle.

  • Service global. Le service global est semblable au service de base de données standard. En plus des propriétés d’un service de base de données, un service global possède les propriétés pour les bases de données partitionnées. Ces propriétés incluent l’affinité de région entre les clients et la tolérance de décalage de la partition et de la réplication. Un seul service global doit être créé pour lire/écrire des données vers/depuis une base de données partitionnée. Lorsque vous utilisez Active Data Guard et que vous configurez les réplicas en lecture seule des partitions, vous pouvez créer un autre service global pour les charges de travail en lecture seule. Le client peut utiliser ces services globaux pour se connecter à la base de données.

  • Bases de données de partitions. Les bases de données de partitions sont vos bases de données Oracle. Chaque base de données est répliquée à l'aide d'Oracle Data Guard dans une configuration de service Broker avec FSFO (Fast-Start Failover) activé. Vous n'avez pas besoin de configurer le basculement et la réplication Data Guard sur chaque partition. Cet aspect est automatiquement configuré et déployé lors de la création de la base de données partagée. En cas de défaillance d'une partition particulière, Oracle Sharing bascule les connexions de base de données de l'instance primaire vers l'instance de secours.

Vous pouvez déployer et gérer des bases de données Oracle partitionnées à l'aide de deux interfaces : Interface graphique utilisateur de contrôle cloud Oracle Enterprise Manager et utilitaire de ligne de commande GDSCTL. Vous pouvez même surveiller la disponibilité et les performances des différentes partitions à l'aide de l'interface de contrôle cloud. La commande GDSCTL DEPLOY crée automatiquement les partitions et leurs écouteurs respectifs. En outre, cette commande déploie automatiquement la configuration de réplication utilisée pour la haute disponibilité de niveau partition spécifiée par l'administrateur.

Différentes méthodes sont disponibles pour partitionner une base de données :

  • Partitionnement managé par le système : répartition automatique entre les partitions
  • Partitionnement défini par l'utilisateur : vous permet de spécifier le mappage des données aux partitions, ce qui fonctionne bien pour les exigences réglementaires ou les exigences de localisation des données
  • Partitionnement composite: combinaison du partitionnement managé par le système et du partitionnement défini par l'utilisateur pour différents espaces de partitionnement
  • Sous-partitions de table : semblable à une table partitionnée standard

Pour plus d’informations, consultez Modèle de partitionnement.

Une base de données partitionnée ressemble à une base de données unique pour les applications et les développeurs. Lorsque vous migrez vers une base de données partitionnée, prévoyez soigneusement de comprendre quelles tables sont dupliquées ou partitionnées.

Les tables dupliquées sont stockées sur toutes les partitions, tandis que les tables partitionnées sont réparties sur différentes partitions. Nous vous recommandons de dupliquer des tables petites et dimensionnées et de distribuer/partitionner les tables de faits. Les données peuvent être chargées dans votre base de données partitionnée en utilisant le catalogue de partitions comme coordinateur central ou en exécutant Data Pump sur chaque partition. Pour plus d’informations, consultez Migration de données vers une base de données partitionnée.

Oracle Sharding avec Data Guard

Oracle Data Guard peut être utilisé pour le partitionnement avec les méthodes de partitionnement managé par le système, de partitionnement défini par l'utilisateur et de partitionnement composite.

Le diagramme suivant illustre une architecture de référence concernant Oracle Sharding avec utilisation d'Oracle Data Guard pour la haute disponibilité de chaque partition. Le diagramme d'architecture présente une méthode de partitionnement composite. Le diagramme d'architecture sera probablement différent pour les applications dont les exigences diffèrent en matière de localisation des données, d'équilibrage de charge, de haute disponibilité, et de récupération d'urgence. Les applications peuvent utiliser une méthode différente pour le partitionnement. Oracle Sharding vous permet de répondre à ces exigences et d'évoluer horizontalement et efficacement grâce à ces options. Une architecture similaire peut même être déployée à l'aide d'Oracle GoldenGate.

Diagramme montrant le partitionnement d'Oracle Database utilisant des zones de disponibilité avec Data Guard Broker - FSFO.

Le partitionnement géré par le système est le plus facile à configurer et à gérer. Le partitionnement défini par l'utilisateur et le partitionnement composite sont bien adaptés aux scénarios dans lesquels vos données et applications sont géo-distribuées ou dans lesquels vous avez besoin de contrôler la réplication de chaque partition.

Dans l'architecture précédente, le partitionnement composite est utilisé pour géo-distribuer les données et faire évoluer horizontalement vos couches Application. Le partitionnement composite, combinaison de partitionnement managé par le système et de partitionnement défini par l'utilisateur, réunit les avantages des deux méthodes. Dans le scénario précédent, les données sont d'abord partitionnées sur plusieurs espaces de partitionnement séparés par région. Les données sont ensuite partitionnées via un hachage cohérent sur différentes partitions de l'espace de partitionnement.

Chaque espace de partitionnement contient différents groupes de partitions. Chaque groupe de partitions possède différentes partitions et constitue une « unité » de réplication. Chaque groupe de partitions contient l'ensemble des données de l'espace de partitionnement. Les groupes de partitions A1 et B1 sont les groupes primaires, tandis que les groupes de partitions A2 et B2 sont des groupes de secours. Vous pouvez opter pour des partitions individuelles comme unité de réplication, plutôt qu'un groupe de partitions.

Dans l'architecture précédente, une carte de partitions globale (GSM)/un directeur de partition est déployé dans chaque zone de disponibilité pour la haute disponibilité. Nous vous recommandons de déployer au moins un directeur de partition/GSM par centre de données/région. En outre, une instance du serveur d'applications est déployée dans chaque zone de disponibilité qui contient un groupe de partitions. Cette configuration permet à l'application de réduire la latence entre le serveur d'applications et la base de données/le groupe de partitions. En cas de défaillance d'une base de données, le serveur d'applications situé dans la même zone que la base de données de secours peut traiter les requêtes une fois la transition de rôle de base de données effectuée. Azure Application Gateway et le directeur de partition assurent le suivi de la latence des requêtes et des réponses, et acheminent les requêtes en conséquence.

Du point de vue de l'application, le système du client adresse une requête à Azure Application Gateway (ou à d'autres technologies d'équilibrage de charge Azure) qui la redirige vers la région la plus proche du client. Azure Application Gateway prend également en charge les sessions persistantes, de sorte que toutes les requêtes provenant du même client sont acheminées vers le même serveur d'applications. Le serveur d'applications utilise le regroupement de connexions dans les pilotes d'accès aux données. Cette fonctionnalité est disponible dans des pilotes tels que JDBC, ODP.NET, et OCI. Les pilotes peuvent reconnaître les clés de sharding spécifiées dans le cadre de la requête. Oracle Universal Connection Pool (UCP) pour clients JDBC peut permettre aux clients d'applications autres qu'Oracle comme Apache Tomcat et IIS de fonctionner avec Oracle Sharding. Pour plus d’informations, consultez Vue d’ensemble du pool partagé UCP pour le partitionnement de base de données.

Lors de la requête initiale, le serveur d'applications se connecte au directeur de partition de sa région pour obtenir des informations de routage pour la partition vers laquelle la requête doit être acheminée. En fonction de la clé de sharding transmise, le directeur achemine le serveur d'applications vers la partition correspondante. Le serveur d'applications met ces informations en cache en générant un mappage et, pour les requêtes suivantes, contourne le directeur de partition et achemine les requêtes directement vers la partition.

Oracle Sharding avec GoldenGate

Le diagramme suivant illustre une architecture de référence concernant Oracle Sharding avec Oracle GoldenGate pour la haute disponibilité dans la région de chaque partition. Contrairement à l'architecture précédente, celle-ci se contente d'illustrer la haute disponibilité au sein d'une seule région Azure, avec plusieurs zones de disponibilité. Vous pouvez déployer une base de données partitionnée haute disponibilité multirégion, comme dans l’exemple précédent, à l’aide d’Oracle GoldenGate.

Diagramme montrant le partitionnement d'Oracle Database utilisant des zones de disponibilité avec GoldenGate.

L'architecture de référence précédente utilise la méthode de partitionnement managée par le système pour partitionner les données. Dans la mesure où la réplication Oracle GoldenGate s'effectue au niveau d'un bloc, la moitié des données répliquées sur une partition peut être répliquée sur une autre partition. L'autre moitié peut être répliquée sur une partition différente.

La façon dont les données sont répliquées dépend du facteur de réplication. Avec un facteur de réplication de deux, vous aurez deux copies de chaque bloc de données sur vos trois partitions du groupe de partitions. De même, avec un facteur de réplication de trois et trois partitions au sein de votre groupe de partitions, toutes les données de chaque partition sont répliquées sur toutes les autres partitions du groupe. Chaque partition du groupe de partitions peut avoir un facteur de réplication différent. Cette configuration vous permet de définir efficacement votre conception de haute disponibilité et de récupération d'urgence au sein d'un groupe de partitions et dans plusieurs groupes de partitions.

Dans l'architecture précédente, le groupe de partitions A et le groupe de partitions B contiennent tous deux les mêmes données mais résident dans des zones de disponibilité différentes. Si les deux groupes de partitions A et B disposent tous deux d'un facteur de réplication de trois, chaque ligne/bloc de votre table partitionnée est répliqué six fois dans les deux groupes de partitions. Si le groupe de partitions A possède un facteur de réplication de trois et le groupe de partitions B un facteur de réplication de deux, chaque ligne/bloc est répliqué cinq fois dans les deux groupes de partitions.

Cette configuration empêche la perte de données en cas de défaillance au niveau de l'instance ou de la zone de disponibilité. La couche Application peut lire et écrire sur chaque partition. Pour minimiser les conflits, Oracle Sharding désigne un bloc principal pour chaque plage de valeurs de hachage. Cette fonctionnalité garantit que les demandes d'écriture relatives à un bloc particulier sont dirigées vers le bloc correspondant. En outre, Oracle GoldenGate fournit une fonctionnalité de détection et de résolution automatiques des conflits afin de gérer les éventuels conflits. Pour plus d'informations et pour connaître les limites relatives à l'implémentation de GoldenGate avec Oracle Sharding, consultez Utiliser Oracle GoldenGate avec une base de données partitionnée.

Dans l'architecture précédente, une carte de partitions globale (GSM)/un directeur de partition est déployé dans chaque zone de disponibilité pour la haute disponibilité. Nous vous recommandons de déployer au moins un directeur de partition/GSM par centre de données ou région. Une instance du serveur d'applications est déployée dans chaque zone de disponibilité qui contient un groupe de partitions. Cette configuration permet à l'application de réduire la latence entre le serveur d'applications et la base de données/le groupe de partitions. En cas de défaillance d'une base de données, le serveur d'applications situé dans la même zone que la base de données de secours peut traiter les requêtes une fois la transition de rôle de base de données effectuée. Azure Application Gateway et le directeur de partition assurent le suivi de la latence des requêtes et des réponses, et acheminent les requêtes en conséquence.

Du point de vue de l'application, le système du client adresse une requête à Azure Application Gateway (ou à d'autres technologies d'équilibrage de charge Azure) qui la redirige vers la région la plus proche du client. Azure Application Gateway prend également en charge les sessions persistantes, de sorte que toutes les requêtes provenant du même client sont acheminées vers le même serveur d'applications. Le serveur d'applications utilise le regroupement de connexions dans les pilotes d'accès aux données. Cette fonctionnalité est disponible dans des pilotes tels que JDBC, ODP.NET, et OCI. Les pilotes peuvent reconnaître les clés de sharding spécifiées dans le cadre de la requête. Oracle Universal Connection Pool (UCP) pour clients JDBC peut permettre aux clients d'applications autres qu'Oracle comme Apache Tomcat et IIS de fonctionner avec Oracle Sharding.

Lors de la requête initiale, le serveur d'applications se connecte au directeur de partition de sa région pour obtenir des informations de routage pour la partition vers laquelle la requête doit être acheminée. En fonction de la clé de sharding transmise, le directeur achemine le serveur d'applications vers la partition correspondante. Le serveur d'applications met ces informations en cache en générant un mappage et, pour les requêtes suivantes, contourne le directeur de partition et achemine les requêtes directement vers la partition.

Mises à jour correctives et maintenance

Lors du déploiement de vos charges de travail Oracle sur Azure, Microsoft s'occupe de toutes les mises à jour correctives du système d'exploitation hôte. Microsoft communique à l’avance toute maintenance planifiée au niveau du système d’exploitation aux clients. Deux serveurs issus de deux zones de disponibilité différentes ne font jamais l'objet d'une mise à jour corrective simultanée. Pour plus d’informations sur la maintenance et la mise à jour corrective des machines virtuelles, consultez Options de disponibilité pour les machines virtuelles Azure.

Les mises à jour correctives du système d’exploitation de vos machines virtuelles peuvent être automatisées à l’aide d’Azure Automation Update Management. Les mises à jour correctives et la maintenance de votre base de données Oracle peuvent être automatisées et planifiées à l’aide d’Azure Pipelines ou d’Azure Automation Update Management afin de minimiser les temps d’arrêt. Pour plus d’informations sur la livraison continue et les déploiements bleu/vert, consultez Techniques d’exposition progressive.

Considérations relatives à l'architecture et à la conception

  • Pensez à utiliser une machine virtuelle à mémoire optimisée « hyperthreadée » avec des processeurs virtuels à cœur restreint pour la machine virtuelle de votre base de données Oracle afin d'économiser sur les coûts de licence et d'optimiser les performances. Utilisez différents disques Premium ou Ultra (disques managés) pour les performances et la disponibilité.
  • Lorsque vous utilisez des disques managés, le nom du disque/de l’appareil peut changer au redémarrage. Nous vous recommandons d’utiliser l’UUID de l’appareil au lieu du nom pour vous assurer que vos montages persistent au redémarrage. Pour plus d’informations, consultez Ajouter le nouveau système de fichiers à /etc/fstab.
  • Utilisez les zones de disponibilité pour bénéficier d'une haute disponibilité au sein de la région.
  • Pensez à utiliser des disques Ultra (le cas échéant) ou des disques Premium pour votre base de données Oracle.
  • Pensez à mettre en place une base de données Oracle de secours dans une autre région Azure à l'aide d'Oracle Data Guard.
  • Pensez à utiliser des groupes de placements de proximité pour réduire la latence entre votre application et la couche Base de données.
  • La bande passante réseau maximale des machines virtuelles Azure est (généralement) supérieure au débit maximal du disque sur la même référence SKU. Vous pouvez obtenir un débit plus élevé sur la même référence SKU de machine virtuelle ou utiliser une référence SKU de machine virtuelle plus petite en utilisant un stockage réseau hautes performances et à faible latence, tel qu’Azure NetApp Files. pour la base de données.
  • Configurez Oracle Enterprise Manager pour la gestion, la surveillance et la journalisation.
  • Pensez à utiliser Oracle Automatic Storage Management (ASM) pour une gestion rationalisée du stockage de votre base de données.
  • Présentation d'Oracle Data Guard
  • Ajustez le code de votre application pour y ajouter des modèles natif Cloud qui peuvent aider votre application à être plus résiliente. Considérez des modèles tels que le modèle de nouvelle tentative, le modèle de disjoncteur et d’autres modèles définis dans le guide Modèles de conception cloud.

Étapes suivantes

Consultez les articles de référence Oracle suivants conformément à votre scénario.