1. Configurer la récupération après sinistre d'Oracle Fusion Middleware sur Oracle Cloud avec une base de données autonome
  2. Planifier la configuration

Planifier la configuration

Planifiez les ressources et la configuration sur le système principal sur Oracle Cloud Infrastructure avant de créer le système secondaire.

Choisir une base de secours cliché ou un clone actualisable distant

Consultez les éléments suivants pour déterminer si vous souhaitez utiliser une base de secours instantanée ou un clone actualisable à distance.

Remarque :

Le clone actualisable distant est uniquement disponible avec Oracle Autonomous Database Serverless.

Si vous utilisez Oracle Autonomous Database on Dedicated Exadata Infrastructure, utilisez la fonctionnalité de secours d'instantané pour la configuration et le cycle de vie. Oracle Autonomous Database on Dedicated Exadata Infrastructure n'implémente pas la fonctionnalité de clone actualisable à distance.

Si vous utilisez Oracle Autonomous Database Serverless, vous pouvez utiliser le clone actualisable à distance ou la fonctionnalité de secours cliché pour la configuration et le cycle de vie. Tenez compte des points suivants :

Base de données de secours cliché

  • Avantages:
    • Les opérations de configuration et de cycle de vie sont plus faciles. Vous n'avez pas besoin de modifier le portefeuille dans le répertoire secondaire lorsque vous convertissez la base de données de secours en cliché ou en base de données de secours physique.
    • La base de données de secours instantanée ne nécessite pas de base de données supplémentaire dans la région de secours. Il n'existe que la base de données de secours, que vous pouvez convertir en cliché et revenir à une base de données de secours physique.
    • Lorsque vous utilisez la base de données de secours instantanée pour valider la base de données secondaire, vous utilisez réellement la même base de données autonome que celle utilisée en cas de permutation. Par conséquent, votre validation est plus réaliste en termes de connectivité, car vous utilisez le même portefeuille que celui que vous allez utiliser en cas de permutation.
  • Inconvénients:
    • Pendant que la base de données de secours est en mode de secours instantanée, la base de données de secours reçoit mais ne s'applique pas, redo provenant de la base de données principale. Si vous devez effectuer un basculement ou une permutation urgent pendant que vous testez le secondaire, vous devez d'abord le convertir en base de données de secours physique afin qu'il soit synchronisé avec le serveur principal. Cela peut retarder la permutation.

Clone actualisable distant

  • Avantages:
    • Le clone actualisable distant est une base de données autonome distincte. Vous n'interagissez pas directement avec la base de données de secours lorsque vous configurez le niveau intermédiaire de secours ou lorsque vous testez le niveau secondaire pendant le cycle de vie.
  • Inconvénients:
    • Comme il s'agit d'une base de données autonome distincte, elle est facturée en tant qu'instance de base de données autonome supplémentaire.
    • Les opérations de configuration et de cycle de vie sont plus complexes. Vous devez basculer le portefeuille entre la base de données de secours réelle et le clone actualisable distant à chaque fois pour pointer vers l'une ou l'autre.

Choisir une approche ou une autre ne vous force pas à utiliser la même approche tout au long de la vie du système. Tant que vous utilisez les étapes appropriées, vous pouvez utiliser une approche différente au cours du cycle de vie de l'approche que vous utilisez pour la configuration de la récupération après sinistre. Vous pouvez également combiner une base de données de secours instantanée pour certaines opérations avec des clones actualisables pour d'autres tests. Par exemple, utilisez l'instantané pour les vérifications de provisionnement et de charge globale sur secondaire, mais utilisez un clone actualisable pour les tests dispersés pendant que le système est soumis à une charge importante. De cette façon, vous pouvez éviter la surcharge (et les éventuels retards de permutation) causée par la conversion massive de redo apply du cliché en base de données de secours physique.

Remarques concernant le système principal

Il est supposé que le système Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace ou Oracle Fusion Middleware principal est créé et utilise le service Oracle Autonomous Database. Lors de la planification de l'implémentation d'un système secondaire dans Oracle Cloud Infrastructure (OCI), vérifiez les points suivants pour le système principal :
  • Sous-réseau privé

    Oracle Autonomous Database et Oracle SOA Suite on Marketplace sont tous deux placés dans un sous-réseau privé.

  • Adresse privée lors de l'utilisation d'Oracle Autonomous Database Serverless

    Le système Oracle Autonomous Database Serverless est exposé via une adresse privée (PEP).

  • Oracle Cloud Infrastructure Load Balancing

    Un équilibreur de charge OCI frontal expose le système Oracle WebLogic Server pour OCI, Oracle SOA Suite on Marketplace ou Oracle Fusion Middleware.

    L'équilibreur de charge OCI peut être public ou privé, en fonction des exigences d'accès client. Pour les fonctionnalités de haute disponibilité implicites dans les régions à plusieurs domaines de disponibilité, placez l'équilibreur de charge OCI dans un sous-réseau régional.

  • Oracle Cloud Infrastructure File Storage

    Le système de récupération après sinistre du système Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace ou Oracle Fusion Middleware utilise un montage Oracle Cloud Infrastructure File Storage partagé par les différents noeuds des clusters WebLogic. Le montage est utilisé pour répliquer la configuration entre les régions.

    • Le système Oracle SOA Suite on Marketplace vous permet de créer un stockage de fichiers ou de réutiliser un stockage de fichiers existant. Il est monté dans le répertoire /u01/soacs/dbfs/share/. Malgré le nom de ce répertoire, il ne s'agit PAS d'un répertoire monté sur un système de fichiers Oracle Database (DBFS) pour Oracle Autonomous Database. Veillez à sélectionner Configurer File Storage dans la pile Oracle SOA Suite on Marketplace. Vous pouvez sélectionner cette option lors du provisionnement ou du post-provisionnement.
    • Le système Oracle WebLogic Server for Oracle Cloud Infrastructure vous permet de créer un stockage de fichiers ou de réutiliser le stockage de fichiers existant (monté dans le répertoire /u01/shared). Veillez à sélectionner Ajouter un système de fichiers dans vos piles Oracle WebLogic Server pour OCI. Vous pouvez sélectionner cette option lors du provisionnement ou du post-provisionnement.
    • Pour les autres services, vous devrez peut-être créer manuellement le montage OCI File Storage dans les noeuds de niveau intermédiaire principal et secondaire. Si vous n'utilisez pas Oracle WebLogic Server for Oracle Cloud Infrastructure ou Oracle SOA Suite on Marketplace, reportez-vous à la documentation OCI File Storage pour obtenir des détails et des étapes de création du stockage.