Documentation Oracle Cloud Infrastructure

Préparation pour Oracle Exadata Database Service sur une infrastructure Exascale

Passez en revue les exigences d'OCI ainsi que celles en matière de site, de réseau et de stockage pour préparer et déployer Oracle Exadata Database Service on Exascale Infrastructure dans votre centre de données.

Exigences d'Oracle Cloud Infrastructure (OCI) pour Oracle Exadata Database Service sur une infrastructure Exascale

Découvrez les concepts de base pour commencer à utiliser Oracle Cloud Infrastructure.

Oracle Exadata Database Service sur Exascale Infrastructure est géré par le plan de contrôle Oracle Cloud Infrastructure (OCI). Les ressources Oracle Exadata Database Service sur l'infrastructure Exascale sont déployées dans votre location OCI.

Pour pouvoir provisionner Oracle Exadata Database Service sur l'infrastructure Exascale Infrastructure, vous devez activer la location Oracle Cloud Infrastructure afin d'utiliser Oracle Exadata Database Service sur l'infrastructure Exascale. Consultez les informations de cette publication pour plus de détails.

Les tâches suivantes sont communes à tous les déploiements OCI. Reportez-vous aux liens de la section Rubriques connexes pour rechercher la documentation Oracle Cloud Infrastructure associée.

  • Introduction à OCI

    Si vous ne connaissez pas OCI, découvrez les concepts de base pour commencer à l'utiliser en suivant le guide d'introduction à OCI.

  • Configuration de votre location

    Une fois qu'Oracle a créé votre location dans OCI, un administrateur de votre société doit effectuer certaines tâches de configuration et établir un plan d'organisation pour les utilisateurs et ressources cloud. Les informations de cette rubrique vous aideront à démarrer.

  • Gestion des régions

    Cette rubrique décrit les notions de base de la gestion de vos abonnements de région.

  • Gestion des compartiments

    Cette rubrique décrit les notions de base de l'utilisation des compartiments.

  • Gestion d'utilisateurs

    Cette rubrique décrit les notions de base de l'emploi des utilisateurs.

  • Gestion de groupes

    Cette rubrique décrit les notions de base de l'utilisation des groupes.

Stratégie IAM requise pour Oracle Exadata Database Service sur une infrastructure Exascale

Consultez la stratégie IAM (Identity Access Management) de provisionnement des systèmes Oracle Exadata Database Service sur une infrastructure Exascale.

Une stratégie est un document IAM indiquant qui dispose de quel type d'accès à vos ressources. Elle est utilisée de différentes manières :
  • instruction individuelle écrite dans le langage de la stratégie,
  • ensemble d'instructions dans un document unique nommé "policy" (auquel est affecté un OCID [ID Oracle Cloud]),
  • corps global des stratégies utilisées par l'organisation en vue de contrôler l'accès aux ressources.

Un compartiment est un ensemble de ressources liées dont l'accès est restreint à certains groupes possédant des droits d'accès accordés par un administrateur au sein de l'organisation.

Pour utiliser Oracle Cloud Infrastructure, vous devez disposer du type d'accès requis dans une stratégie écrite par un administrateur, que vous utilisiez la console ou l'API REST avec un kit de développement logiciel (SDK), une interface de ligne de commande (CLI) ou un autre outil. Si vous essayez d'effectuer une action et qu'un message indique que vous n'y êtes pas autorisé, vérifiez auprès de l'administrateur de location le type d'accès qui vous a été accordé et le compartiment dans lequel vous devez travailler.

Pour les administrateurs : la stratégie dans "Autoriser les administrateurs de base de données à gérer des systèmes de base de données" permet au groupe spécifié d'effectuer toutes les opérations relatives aux bases de données et aux ressources de base de données associées.

Si vous ne connaissez pas les stratégies, reportez-vous à Introduction aux stratégies et à Stratégies courantes. Si vous voulez en savoir plus sur l'écriture des stratégies relatives aux bases de données, reportez-vous à Détails du service Database.

Pour plus d'informations sur l'écriture de stratégies spécifiques aux ressources Exadata Cloud@Customer, reportez-vous à Détails de stratégie pour Oracle Exadata Database Service sur une infrastructure Exascale.

Configuration réseau pour Oracle Exadata Database Service sur des instances d'infrastructure Exascale

Cette rubrique décrit la configuration recommandée pour le VCN et plusieurs exigences associées pour l'instance Oracle Exadata Database Service on Exascale Infrastructure.

Avant de configurer une instance Oracle Exadata Database Service sur une infrastructure Exascale, vous devez configurer un réseau cloud virtuel (VCN) et d'autres composants de service Networking.

Rubrique parent : Préparation d'Oracle Exadata Database Service sur une infrastructure Exascale

VCN et sous-réseaux

Pour lancer un cluster de machines virtuelles Oracle Exadata Database Service sur une infrastructure Exascale, vous devez disposer d'un réseau cloud virtuel et d'au moins deux sous-réseaux.

Pour lancer un cluster de machines virtuelles Oracle Exadata Database Service sur une infrastructure Exascale, vous devez disposer d'un réseau cloud virtuel et d'au moins deux sous-réseaux, et sélectionner le type de résolveur DNS à utiliser :

  • Un VCN dans la région où vous voulez le cluster de machines virtuelles Oracle Exadata Database Service sur une infrastructure Exascale

  • Au moins deux sous-réseaux dans le réseau cloud virtuel, qui sont les suivants :

    • sous-réseau client
    • Sous-réseau de sauvegarde
  • Choisissez la méthode de résolution de noms DNS à utiliser. Reportez-vous à Choix pour DNS dans le réseau cloud virtuel.

En général, Oracle recommande l'utilisation de sous-réseaux régionaux, qui couvrent tous les domaines de disponibilité de la région. Pour plus d'informations, reportez-vous à Présentation des réseaux cloud virtuels et des sous-réseaux.

Vous allez créer des tables de routage personnalisées pour chaque sous-réseau. Vous devez également créer des règles de sécurité pour contrôler le trafic depuis et vers le réseau client et le réseau de sauvegarde des noeuds de calcul Exadata (pour la ressource de cluster de machines virtuelles cloud, les noeuds sont appelés machines virtuelles). Des informations supplémentaires sont fournies ci-après sur ces éléments.

Rubriques connexes

Rubrique parent : Configuration réseau d'Oracle Exadata Database Service sur des instances d'infrastructure Exascale

Option 1 : sous-réseau client public avec passerelle Internet

Cette option est utile lorsque vous réalisez une étude de faisabilité ou que vous développez.

Vous pouvez appliquer cette configuration en production si vous voulez utiliser une passerelle Internet avec le réseau cloud virtuel, ou si vous disposez de services exécutés uniquement sur un réseau public qui ont besoin d'accéder à la base de données. Reportez-vous au diagramme suivant et à sa description.

Description de l'image network_exa_public_client.png
Description de l'image network_exa_public_client.png

Vous pouvez configurer les éléments suivants :

  • S sous-réseaux :

    • Sous-réseau client public (public signifie que les ressources du sous-réseau peuvent disposer d'adresses IP publiques, à votre discrétion).
    • Sous-réseau de sauvegarde privé (privé signifie que les ressources du sous-réseau ne peuvent pas disposer d'adresses IP publiques et ne peuvent donc pas recevoir de connexions entrantes à partir d'Internet).

  • Passerelles pour le réseau cloud virtuel :

  • Tables de routage :

    • Table de routage personnalisée pour le sous-réseau client public, avec un routage pour 0.0.0.0/0 et la passerelle Internet pour cible.
    • Table de routage personnalisée distincte pour le sous-réseau de sauvegarde privé, avec une règle de routage pour les libellés CIDR de service (vous trouverez des informations sur les libellés CIDR sous Présentation des passerelles de service et Libellés CIDR de service disponibles), et la passerelle de service pour cible.
  • Règles de sécurité permettant d'autoriser le trafic souhaité à destination et en provenance des noeuds de calcul des machines virtuelles Exadata.
  • Accès des noeuds à Object Storage : routage statique sur les noeuds de calcul de l'instance Exadata Cloud Service (pour permettre l'accès aux services OCI via le sous-réseau de sauvegarde).
Remarque

Reportez-vous à ce problème connu pour obtenir des informations sur la configuration de règles de routage avec la passerelle de service en tant que cible sur les tables de routage associées aux sous-réseaux publics.
Option 2 : sous-réseaux privés

Oracle recommande les sous-réseaux privés pour un système de production.

Les deux sous-réseaux sont privés et ne sont pas accessibles à partir d'Internet. Reportez-vous au diagramme suivant et à sa description.

Description de l'image network_exa_private_client.png
Description de l'image network_exa_private_client.png

Vous pouvez configurer les éléments suivants :

  • S sous-réseaux :

    • Sous-réseau client privé.
    • Sous-réseau de sauvegarde privé.

  • Passerelles pour le réseau cloud virtuel :

  • Tables de routage :

    • Table de routage personnalisée pour le sous-réseau client privé, avec les règles suivantes :

      • Règle pour le CIDR du réseau sur site, avec la passerelle de routage dynamique pour cible.
      • Règle pour le libellé CIDR de service appelé Tous les services <région> dans Oracle Services Network avec la passerelle de service pour cible. Oracle Services Network est un réseau conceptuel d'Oracle Cloud Infrastructure réservé aux services Oracle. La règle permet au sous-réseau client d'atteindre le référentiel Oracle YUM régional pour les mises à jour de système d'exploitation. Reportez-vous également à Option 2 : accès de la passerelle de service à Object Storage et aux référentiels YUM.
      • (Facultatif) Règle pour 0.0.0.0/0 avec la passerelle NAT pour cible.
    • Table de routage personnalisée distincte pour le sous-réseau de sauvegarde privé avec une règle :
      • Même règle que pour le sous-réseau client : pour le libellé CIDR de service appelé Tous les services <région> dans Oracle Services Network avec la passerelle de service pour cible. Cette règle permet au sous-réseau de sauvegarde d'atteindre le stockage Object Storage régional pour les sauvegardes.
  • Règles de sécurité permettant d'autoriser le trafic souhaité à destination et en provenance des noeuds Exadata. Reportez-vous à Règles de sécurité pour l'instance Exadata Cloud Service.
  • Vous pouvez éventuellement ajouter un routage statique sur les noeuds de calcul vers d'autres services OCI (machines virtuelles pour les clusters de machines virtuelles) pour permettre l'accès, si les services sont accessibles uniquement sur le sous-réseau de sauvegarde et non via le sous-réseau client, par exemple lors de l'utilisation d'une passerelle NAT.
Exigences en matière d'espace d'adresse IP

Vous devez créer un VCN avec deux sous-réseaux et vous assurer qu'il y a suffisamment d'adresses pour la taille de votre cluster de machines virtuelles.

Remarque

Les adresses IP ne doivent pas se chevaucher, en particulier lorsque les instances Exadata Cloud Infrastructure (et donc les réseaux cloud virtuels) se trouvent dans plusieurs régions.

Si vous configurez des clusters de machines virtuelles (et donc des réseaux cloud virtuels) dans plus d'une région, assurez-vous que les espaces d'adresse IP des réseaux cloud virtuels ne se chevauchent pas. Cette étape est importante si vous voulez configurer la récupération après sinistre avec Oracle Data Guard.

Pour le sous-réseau client, chaque noeud requiert quatre adresses IP, et trois adresses sont réservées aux noms SCAN. Pour le sous-réseau de sauvegarde, chaque noeud requiert trois adresses. Le service Networking réserve trois adresses IP dans chaque sous-réseau.

Utilisez la formule suivante pour calculer le nombre minimal d'adresses IP où la variable n est le nombre de machines virtuelles dans le cluster de machines virtuelles :

Nombre minimal d'adresses client = 4*n+6

Nombre minimal d'adresses de sauvegarde = 3*n+3

Remarque

L'allocation au sous-réseau d'un espace supérieur au minimum requis (par exemple au moins /25 au lieu de /28) peut réduire l'impact relatif des adresses réservées sur l'espace disponible du sous-réseau. Pour planifier une croissance future, ajoutez les adresses dont vous prévoyez d'avoir besoin lorsque vous augmentez votre cluster de machines virtuelles, et pas seulement le nombre de machines virtuelles que vous prévoyez de provisionner pour un besoin immédiat.
Configuration d'un routage statique pour l'accès à la banque d'objets
Par défaut, l'ensemble du trafic d'une instance Oracle Exadata Database Service on Exascale Infrastructure est routé via le réseau de données. Pour réacheminer le trafic de sauvegarde vers l'interface de sauvegarde (BONDETH1), vous devez configurer un routage statique sur chacun des noeuds de calcul dans le cluster.

Pour obtenir des instructions, reportez-vous à Accès des noeuds à Object Storage : routage statique.

Configuration d'un DNS pour une instance Oracle Exadata Database Service sur une infrastructure Exascale

Un DNS permet d'utiliser des noms d'hôte plutôt que des adresses IP pour communiquer avec une instance Exadata Cloud Infrastructure.

Vous pouvez utiliser le résolveur Internet et de réseau cloud virtuel (fonction DNS intégrée au réseau cloud virtuel) comme décrit dans DNS dans votre réseau cloud virtuel. Oracle recommande d'utiliser un résolveur de réseau cloud virtuel pour la résolution de noms DNS du sous-réseau client. Il résout automatiquement les adresses Swift requises pour sauvegarder les bases de données, appliquer des patches et mettre à jour les outils cloud sur une instance Exadata.

DNS : noms abrégés pour le VCN, les sous-réseaux et l'instance Oracle Exadata Database Service sur l'infrastructure Exascale
Pour que les noeuds communiquent, le réseau cloud virtuel doit utiliser le résolveur Internet et de réseau cloud virtuel. Le résolveur Internet et VCN permet l'attribution de nom d'hôte aux noeuds et la résolution DNS de ces noms d'hôte par les ressources du VCN.

Le résolveur Internet et VCN permet la résolution par tourniquet des SCAN de la base de données. Il permet également de résoudre les adresses de service importantes requises pour la sauvegarde des bases de données, l'application de patches et la mise à jour des outils cloud sur une instance Oracle Exadata Database Service sur une instance d'infrastructure Exascale. Le résolveur Internet et de réseau cloud virtuel est le choix par défaut du réseau cloud virtuel pour le DNS. Pour plus d'informations, reportez-vous à DNS dans votre réseau cloud virtuel et à Options DHCP.

Lorsque vous créez le réseau cloud virtuel, les sous-réseaux et Exadata, vous devez soigneusement définir les identificateurs suivants, qui sont liés au DNS dans le réseau cloud virtuel :

  • Etiquette de domaine VCN
  • Libellé de domaine de sous-réseau
  • Préfixe de nom d'hôte pour le cluster de machines virtuelles cloud ou la ressource de système de base de données de l'instance Oracle Exadata Database Service on Exascale Infrastructure

Ces valeurs constituent le nom de domaine qualifié complet du noeud :

<préfixe_nomhôte>-######.<libellé_domaine_sous-réseau>.<libellé_domaine_vcn>.oraclevcn.com

Par exemple :

exacs-abcde1.clientpvtad1.acmevcniad.oraclevcn.com

Dans cet exemple, vous affectez le préfixe exacs au nom d'hôte lorsque vous créez le système de base de données ou le cluster de machines virtuelles cloud. Le service Database ajoute automatiquement un trait d'union et une chaîne de cinq lettres avec le numéro de noeud à la fin. Par exemple :

  • Noeud 1 : exacs-abcde1.clientpvtad1.acmevcniad.oraclevcn.com
  • Noeud 2 : exacs-abcde2.clientpvtad1.acmevcniad.oraclevcn.com
  • Noeud 3 : exacs-abcde3.clientpvtad1.acmevcniad.oraclevcn.com
  • Etc

Exigences relatives au préfixe de nom d'hôte :

  • Longueur maximale recommandée : de 12 caractères. Pour plus d'informations, reportez-vous à l'exemple de la section suivante (Exigences relatives aux libellés de réseau cloud virtuel et de domaine de sous-réseau).
  • Ne doit pas être la chaîne localhost.

Exigences relatives aux libellés de réseau cloud virtuel et de domaine de sous-réseau :

  • Longueur maximale recommandée : 14 caractères chacun. L'exigence sous-jacente réelle est de 28 caractères au total pour les deux libellés de domaine (sans compter le point entre les libellés). Exemples de valeurs acceptables : subnetad1.verylongvcnphx ou verylongsubnetad1.vcnphx. Pour plus de simplicité, il est recommandé d'utiliser 14 caractères pour chaque libellé.
  • Aucun trait d'union ni trait de soulignement.

  • Recommandé : incluez le nom de région dans le libellé de domaine du réseau cloud virtuel, et le nom de domaine de disponibilité dans le libellé de domaine du sous-réseau.

  • En général, le nombre total maximal de caractères du nom de domaine qualifié complet est fixé à 63. Voici la règle générale :

    <12_caractères_max>-######.<14_caractères_max>.<14_caractères_max>.oraclevcn.com

Les valeurs maximales précédentes ne sont pas appliquées lorsque vous créez le réseau cloud virtuel et les sous-réseaux. Toutefois, si les libellés dépassent la longueur maximale, le déploiement Exadata échoue.

  • DNS : entre le réseau sur site et le VCN
    Oracle recommande d'utiliser un résolveur DNS privé pour activer l'utilisation des noms d'hôte lorsque les hôtes sur site et les ressources VCN communiquent entre eux.

Rubrique parent : Réseau cloud virtuel et sous-réseaux

DNS : entre le réseau sur site et le réseau cloud virtuel

Oracle vous recommande d'utiliser un résolveur DNS privé pour permettre l'utilisation de noms d'hôte lorsque des hôtes sur site et des ressources de réseau cloud virtuel communiquent.

Pour plus d'informations sur la création et l'utilisation de résolveurs privés, reportez-vous à Résolveurs DNS privés. Pour l'architecture de référence, reportez-vous à Utilisation d'un DNS privé dans votre réseau cloud virtuel dans Oracle Architecture Center.

Configuration d'un DNS privé

Passez en revue les prérequis nécessaires pour utiliser le DNS privé.

  • La vue privée et la zone privée doivent être créées avant le lancement du provisionnement du système de base de données. Pour plus d'informations, reportez-vous à résolveurs DNS privés.
  • La transmission vers un autre serveur DNS doit être configurée au préalable dans la console DNS. Pour ce faire, accédez au résolveur du réseau cloud virtuel et créez l'adresse, puis les règles. Pour plus de détails, reportez-vous à DNS dans votre réseau cloud virtuel.
  • Le nom de la zone privée ne peut pas comporter plus de 4 étiquettes. Par exemple, a.b.c.d est autorisé alors qu'a.b.c.d.e ne l'est pas.
  • Il est également nécessaire d'ajouter la vue privée au résolveur du VCN. Pour plus de détails, reportez-vous à Ajout d'une vue privée à un résolveur.
  • Lors du provisionnement d'un cluster de machines virtuelles Exadata à l'aide de la fonctionnalité DNS privée, Exadata doit créer des zones DNS inverses dans le compartiment du cluster de machines virtuelles Exadata. Si le compartiment contient des balises définies ou des valeurs de balise par défaut, des stratégies supplémentaires liées à la gestion des balises sont nécessaires. Pour plus d'informations, reportez-vous à :

Accès des noeuds à Object Storage : routage statique

Pour pouvoir sauvegarder des bases de données et appliquer des patches et des mises à jour aux outils cloud sur une instance Oracle Exadata Database Service on Exascale Infrastructure, Oracle vous recommande de configurer Autonomous Recovery Service. Quelle que soit la façon dont vous configurez le VCN avec cet accès (par exemple, avec une passerelle de service), si vous utilisez Object Storage, vous devrez peut-être également configurer un routage statique vers Object Storage sur chacun des noeuds de calcul du cluster. Cette opération est requise uniquement si vous n'utilisez pas les sauvegardes automatiques. Si vous utilisez des sauvegardes personnalisées à l'aide des API de sauvegarde, vous devez acheminer le trafic destiné à Object Storage via l'interface de sauvegarde (BONDETH1). Cette opération n'est pas nécessaire si vous utilisez des sauvegardes automatiques créées à l'aide de la console, des API ou des CLI.
Remarque

A compter du 06 août 2025, pour les locations créées dans les régions FRA, PHX ou NRT, Autonomous Recovery Service sera la seule destination de sauvegarde lorsque vous activerez la sauvegarde automatique sur les bases de données.

Attention :

Vous devez configurer un routage statique pour l'accès à Object Storage sur chaque noeud de calcul d'une instance Oracle Exadata Database Service sur l'infrastructure Exascale si vous ne créez pas de sauvegardes automatiques à l'aide de la console, des API ou des interfaces de ligne de commande. Sinon, les tentatives de sauvegarde des bases de données, d'application de patches et de mise à jour des outils sur le système peuvent échouer.
Remarque

Lorsque vous activez la première sauvegarde automatique pour une base de données, la configuration du routage statique est automatiquement effectuée sur le service.

Si vous voulez appliquer des patches au service avant de créer une base de données, le routage statique manuel est requis pour pouvoir appliquer les patches au répertoire de base de base de données ou GI.

Le routage statique peut également être requis pour accéder à d'autres services (IAM, KMS) si ceux-ci ne sont pas accessibles via le sous-réseau client et que seul le sous-réseau de sauvegarde utilise le paramètre permettant d'accéder à tous les services d'une région.

Allocations d'adresses IP Object Storage

Oracle Cloud Infrastructure Object Storage utilise la plage d'adresses IP 134.70.0.0/16 du bloc CIDR pour toutes les régions.

A compter du 1er juin 2018, Object Storage ne prend plus en charge les plages d'adresses IP obsolètes suivantes. Oracle vous recommande d'enlever ces anciennes adresses IP de vos listes de contrôle d'accès, de vos règles de pare-feu et autres règles après avoir adopté les nouvelles plages d'adresses IP.

Les plages d'adresses IP obsolètes sont les suivantes :

  • Allemagne centrale (Francfort) : 130.61.0.0/16
  • Sud du Royaume-Uni (Londres) : 132.145.0.0/16
  • Est des Etats-Unis (Ashburn) : 129.213.0.0/16
  • Ouest des Etats-Unis (Phénix) : 129.146.0.0/16
Procédure de configuration d'un routage statique pour accéder à Object Storage

  1. Connectez-vous via SSH à un noeud de calcul dans l'instance Oracle Exadata Database Service on Exascale Infrastructure. 

    ssh -i <private_key_path> opc@<node_ip_address>

  2. Connectez-vous en tant qu'utilisateur opc et passez à l'utilisateur root à l'aide de la commande sudo. Utilisez sudo su - avec un tiret pour appeler le profil de l'utilisateur root. 

    
login as: opc
			
[opc@dbsys ~]$ sudo su -

  3. Identifiez la passerelle configurée pour l'interface BONDETH1. 

    [root@dbsys ~]# grep GATEWAY /etc/sysconfig/network-scripts/ifcfg-bondeth1 |awk -F"=" '{print $2}'


10.0.4.1

  4. Ajoutez la règle statique suivante pour BONDETH1 au fichier /etc/sysconfig/network-scripts/route-bondeth1 : 

    10.0.X.0/XX dev bondeth1 table 211
default via <gateway> dev bondeth1 table 211
134.70.0.0/17 via <gateway_from_previous_step> dev bondeth1

  5. Redémarrez l'interface. 

    
[root@dbsys ~]# ifdown bondeth1; ifup bondeth1;

    Les modifications apportées au fichier à l'étape précédente prennent effet immédiatement après l'exécution des commandes ifdown et ifup.

  6. Répétez les étapes précédentes sur chaque noeud de calcul de l'instance Oracle Exadata Database Service sur une infrastructure Exascale.

Passerelle de service pour le réseau cloud virtuel

Le réseau cloud virtuel a besoin d'accéder à Object Storage pour les sauvegardes et aux référentiels Oracle YUM pour les mises à jour du système d'exploitation.

Rubrique parent : Configuration réseau d'Oracle Exadata Database Service sur des instances d'infrastructure Exascale

Option 1 : accès de la passerelle de service aux services OCI

Configurez le sous-réseau de sauvegarde de façon à utiliser la passerelle de service uniquement pour accéder à Object Storage.

Pour rappel, voici le diagramme de l'option 1, configuration réseau avec un sous-réseau client public :

Cette image présente la configuration réseau avec un sous-réseau client public, comme décrit précédemment.

En général, vous devez effectuer les tâches suivantes :

  • Effectuez les tâches de configuration d'une passerelle de service sur un réseau cloud virtuel et activez spécifiquement le libellé CIDR de service appelé OCI <région> Object Storage.
  • Dans la tâche de mise à jour du routage, ajoutez une règle de routage à la table de routage personnalisée du sous-réseau de sauvegarde. Pour le service de destination, utilisez OCI <région> Object Storage et la passerelle de service pour cible.
  • Dans la tâche de mise à jour des règles de sécurité dans le sous-réseau, effectuez la tâche sur la liste de sécurité personnalisée ou le groupe de sécurité réseau du réseau de sauvegarde. Configurez une règle de sécurité avec le service de destination défini sur OCI <région> Object Storage. Reportez-vous à "Règle spécifique au réseau de sauvegarde" Règle spécifique au réseau de sauvegarde.
Option 2 : accès de la passerelle de service à Object Storage et au référentiel YUM

Configurez le sous-réseau client et sous-réseau de sauvegarde afin d'utiliser la passerelle du service pour accéder à Oracle Services Network, qui inclut Object Storage et les référentiels Oracle YUM.

Remarque

Reportez-vous à ces problèmes connus pour plus d'informations sur l'accès aux services Oracle YUM via la passerelle de service.

Pour rappel, voici le schéma associé à l'option 2, une configuration réseau avec des sous-réseaux privés :

Cette image présente la configuration réseau avec des sous-réseaux client privés, comme décrit précédemment.

En général, vous devez effectuer les tâches suivantes :

  • Effectuez les tâches de configuration d'une passerelle de service sur un réseau cloud virtuel et activez spécifiquement le libellé CIDR de service appelé Tous les services <région> dans Oracle Services Network.
  • Dans la tâche de mise à jour du routage dans chaque sous-réseau, ajoutez une règle à la table de routage personnalisée de chaque sous-réseau. Pour le service de destination, utilisez Tous les services <region> dans Oracle Services Network et la passerelle de service en tant que cible.
  • Dans la tâche de mise à jour des règles de sécurité pour le sous-réseau, effectuez la tâche sur la liste de sécurité personnalisée ou le groupe de sécurité réseau du réseau de sauvegarde. Configurez une règle de sécurité avec le service de destination défini sur OCI <région> Object Storage. Reportez-vous à Règles de sécurité. Le sous-réseau client comporte déjà une règle sortante à spectre large qui couvre déjà l'accès aux référentiels YUM.

Voici quelques détails supplémentaires sur l'utilisation de la passerelle de service pour l'option 2 :

Remarque

A compter du 06 août 2025, pour les locations créées dans les régions FRA, PHX ou NRT, Autonomous Recovery Service sera la seule destination de sauvegarde lorsque vous activerez la sauvegarde automatique sur les bases de données.
  • Le sous-réseau client et le sous-réseau de sauvegarde utilisent la passerelle de service pour accéder à différents services. Vous ne pouvez pas activer à la fois le libellé CIDR de service OCI <région> Object Storage et le libellé Tous les services <région> dans Oracle Services Network pour la passerelle de service. Pour couvrir les besoins des deux sous-réseaux, vous devez activer Tous les services <région> dans Oracle Services Network pour la passerelle de service. Le réseau cloud virtuel ne peut présenter qu'une seule passerelle de service.
  • Toute règle de routage ciblant une passerelle de service donnée doit utiliser un libellé CIDR de service activé et non un bloc CIDR en tant que destination pour la règle. Autrement dit, pour l'option 2, les tables de routage des deux sous-réseaux doivent utiliser Tous les services <région> dans Oracle Services Network pour leurs règles de passerelle de service.
  • Contrairement aux règles de routage, les règles de sécurité peuvent utiliser n'importe quel libellé CIDR de service (que le réseau cloud virtuel présente ou non une passerelle de service) ou un bloc CIDR en tant que CIDR source ou de destination pour la règle. Par conséquent, même si le sous-réseau de sauvegarde comprend une règle de routage qui utilise Tous les services <région> dans Oracle Services Network, le sous-réseau peut disposer d'une règle de sécurité qui utilise OCI <région> Object Storage. Reportez-vous à Règles de sécurité pour l'instance Exadata Cloud Service.

Règles de sécurité pour Oracle Exadata Database Service sur une infrastructure Exascale

Cette section répertorie les règles de sécurité à utiliser avec Oracle Exadata Database Service sur une infrastructure Exascale.

Les règles de sécurité contrôlent les types de trafic autorisés pour le réseau client et le réseau de sauvegarde des machines virtuelles. Les règles sont divisées en trois sections.

Vous pouvez implémenter ces règles de différentes manières. Pour plus d'informations, reportez-vous à Méthodes d'implémentation des règles de sécurité.
Remarque

Pour les systèmes X8M et X9M, Oracle recommande d'ouvrir tous les ports du sous-réseau client pour le trafic entrant et sortant. Il s'agit d'une exigence pour l'ajout de serveurs de base de données supplémentaires au système.

Règles requises pour le réseau client et le réseau de sauvegarde

Plusieurs règles générales permettent une connectivité essentielle pour les hôtes du VCN.

Si vous utilisez des listes de sécurité pour implémenter vos règles de sécurité, sachez que les règles suivantes sont incluses par défaut dans la liste de sécurité par défaut. Mettez à jour ou remplacez la liste pour qu'elle réponde à vos besoins en matière de sécurité. Les deux règles ICMP (règles entrantes générales 2 et 3) sont nécessaires au bon fonctionnement du trafic réseau au sein de l'environnement Oracle Cloud Infrastructure. Ajustez la règle entrante générale 1 (règle SSH) et la règle sortante générale 1 pour autoriser le trafic uniquement vers et depuis les hôtes qui nécessitent une communication avec les ressources de votre réseau cloud virtuel.

Règle entrante générale 1 : autorise le trafic SSH de toute provenance

  • Sans conservation de statut : non (toutes les règles doivent avoir la conservation de statut)
  • Type de source : CIDR
  • CIDR source : 0.0.0.0/0
  • Protocole IP : SSH
  • Plage de ports source : Tout
  • Plage de ports de destination : 22

Règle entrante générale 2 : autorise les messages de fragmentation de repérage du MTU d'un chemin

Cette règle permet aux hôtes du réseau cloud virtuel de recevoir des messages de fragmentation de repérage du MTU d'un chemin. Sans accès à ces messages, les hôtes du réseau cloud virtuel peuvent rencontrer des problèmes de communication avec les hôtes en dehors du réseau cloud virtuel.

  • Sans conservation de statut : non (toutes les règles doivent avoir la conservation de statut)
  • Type de source : CIDR
  • CIDR source : 0.0.0.0/0
  • Protocole IP : ICMP
  • Type : 3
  • Code : 4

Règle entrante générale 3 : autorise les messages d'erreur de connectivité dans le réseau cloud virtuel

Cette règle permet aux hôtes du réseau cloud virtuel de recevoir des messages d'erreur de connectivité de la part des autres.

  • Sans conservation de statut : non (toutes les règles doivent avoir la conservation de statut)
  • Type de source : CIDR
  • CIDR source : CIDR de votre réseau cloud virtuel
  • Protocole IP : ICMP
  • Type : 3
  • Code : Tout

Règle sortante générale 1 : autorise tout le trafic sortant

  • Sans conservation de statut : non (toutes les règles doivent avoir la conservation de statut)
  • Type de destination : CIDR
  • CIDR de destination : 0.0.0.0/0
  • Protocole IP : tous

Règles requises spécifiquement pour le réseau client

Les règles de sécurité suivantes sont importantes pour le réseau client.

Remarque

  • Les règles entrantes client 1 et 2 couvrent uniquement les connexions lancées à partir du sous-réseau client. Si l'un de vos clients réside en dehors du réseau cloud virtuel, Oracle recommande de configurer deux règles similaires supplémentaires dont le CIDR source est défini sur l'adresse IP publique du client.
  • Les règles entrantes client 3 et 4, et les règles sortantes client 1 et 2 autorisent le trafic TCP et ICMP à l'intérieur du réseau client, et permettent aux noeuds de communiquer entre eux. En cas d'échec de la connectivité TCP sur les noeuds, le provisionnement de la ressource de cluster de machines virtuelles cloud Exadata ou de système de base de données échoue.

Règle entrante client 1 : autorise le trafic ONS et FAN à partir du sous-réseau client

La première règle est recommandée et permet à Oracle Notification Services (ONS) de communiquer à propos des événements FAN (Fast Application Notification).

  • Sans conservation de statut : non (toutes les règles doivent avoir la conservation de statut)
  • Type de source : CIDR
  • CIDR source : CIDR du sous-réseau client
  • Protocole IP : TCP.
  • Plage de ports source : Tout
  • Plage de ports de destination : 6200
  • Description : description facultative de la règle.

Règle entrante client 2 : autorise le trafic SQL*NET à partir du sous-réseau client

Cette règle concerne le trafic SQL*NET et est requise dans les cas suivants :

  • Si vous devez activer les connexions client à la base de données
  • Si vous prévoyez d'utiliser Oracle Data Guard
  • Sans conservation de statut : non (toutes les règles doivent avoir la conservation de statut)
  • Type de source : CIDR
  • CIDR source : CIDR du sous-réseau client
  • Protocole IP : TCP.
  • Plage de ports source : Tout
  • Plage de ports de destination : 1521
  • Description : description facultative de la règle.

Règle entrante client 3 : autorise l'application de patches au trafic à partir du sous-réseau client

  • Sans conservation de statut : non (toutes les règles doivent avoir la conservation de statut)
  • Type de source : CIDR
  • CIDR source : CIDR du sous-réseau client
  • Protocole IP : TCP.
  • Plage de ports source : Tout
  • Plage de ports de destination : 7085
  • Description : ajoutez éventuellement une description explicite de la règle. Par exemple : "Autoriser l'accès à l'adresse privée de mise à jour de parc Exadata dans le sous-réseau".

Règle sortante client 1 : autorise tout le trafic TCP à l'intérieur du sous-réseau client

  • Sans conservation de statut : non (toutes les règles doivent avoir la conservation de statut)
  • Type de destination : CIDR
  • CIDR de destination : 0.0.0.0/0
  • Protocole IP : TCP.
  • Plage de ports source : Tout
  • Plage de ports de destination : 22
  • Description : description facultative de la règle.

Règle sortante client 2 : autorise tout le trafic sortant (autorise les connexions aux référentiels Oracle YUM)

La règle sortante client 3 est importante car elle autorise les connexions aux référentiels Oracle YUM. Elle est redondante par rapport à la règle sortante générale de cette rubrique (et de la liste de sécurité par défaut). Elle est facultative mais recommandée si la règle sortante générale (ou la liste de sécurité par défaut) est modifiée par inadvertance.

  • Sans conservation de statut : non (toutes les règles doivent avoir la conservation de statut)
  • Type de destination : CIDR
  • CIDR de destination : 0.0.0.0/0
  • Protocole IP : tous
  • Description : description facultative de la règle.

Stratégies IAM requises pour l'application de patches à Oracle Database et Oracle Grid Infrastructure

Octroyez des stratégies Identity and Management (IAM) pour accéder aux sous-réseaux, aux cartes d'interface réseau virtuelles (vNICs) et aux adresses IP privées (adresses IP privées) aux utilisateurs ou aux groupes qui gèrent la base de données et Oracle Grid Infrastructure. Par exemple, supposons que le groupe admin-group gère le compartiment ABC. Dans ce cas, vous devez configurer les stratégies suivantes :

  • Autoriser le groupe admin-group à utiliser des sous-réseaux dans le compartiment ABC
  • Autoriser le groupe admin-group à utiliser vNICs dans le compartiment ABC
  • Autoriser le groupe admin-group à utiliser private-ips dans le compartiment ABC

Règle requise spécifiquement pour le réseau de sauvegarde

La règle de sécurité suivante est importante pour le réseau de sauvegarde car elle permet au système de base de données de communiquer avec Object Storage via la passerelle de service (et éventuellement avec les référentiels Oracle YUM si le réseau client n'y a pas accès). Elle est redondante par rapport à la règle sortante générale de cette rubrique (et de la liste de sécurité par défaut). Elle est facultative mais recommandée si la règle sortante générale (ou la liste de sécurité par défaut) est modifiée par inadvertance.

Règle sortante de sauvegarde : autorise l'accès à Object Storage

  • Sans conservation de statut : non (toutes les règles doivent avoir la conservation de statut)
  • Type de destination : Service

  • Service de destination :

    • Libellé CIDR de service appelé OCI <région> Object Storage.
    • Si le réseau client n'a pas accès aux référentiels Oracle YUM, utilisez le libellé CIDR de service appelé Tous les services <région> dans Oracle Services Network.
  • Protocole IP : TCP.
  • Plage de ports source : Tout
  • Plage de ports de destination : 443 (HTTPS)
  • Description : description facultative de la règle.

Rubrique parent : Configuration réseau d'Oracle Exadata Database Service sur des instances d'infrastructure Exascale

Règles requises pour le réseau client et le réseau de sauvegarde

Cette rubrique contient plusieurs règles générales qui activent la connectivité essentielle pour les hôtes dans le réseau cloud virtuel.

Si vous utilisez des listes de sécurité pour implémenter vos règles de sécurité, sachez que les règles suivantes sont incluses par défaut dans la liste de sécurité par défaut. Mettez à jour ou remplacez la liste pour qu'elle réponde à vos besoins en matière de sécurité. Les deux règles ICMP (règles entrantes générales 2 et 3) sont nécessaires au bon fonctionnement du trafic réseau au sein de l'environnement Oracle Cloud Infrastructure. Ajustez la règle entrante générale 1 (règle SSH) et la règle sortante générale 1 pour autoriser le trafic uniquement vers et depuis les hôtes qui nécessitent une communication avec les ressources de votre réseau cloud virtuel.

Règle entrante générale 1 : autorise le trafic SSH de toute provenance
  • Sans conservation de statut : non (toutes les règles doivent avoir la conservation de statut)
  • Type de source : CIDR
  • CIDR source : 0.0.0.0/0 (IPv4), : :/0 (IPv6)
  • Protocole IP : SSH
  • Plage de ports source : Tout
  • Plage de ports de destination : 22
Règle entrante générale 2 : autorise les messages de fragmentation de repérage du MTU d'un chemin

Cette règle permet aux hôtes du réseau cloud virtuel de recevoir des messages de fragmentation de repérage du MTU d'un chemin. Sans accès à ces messages, les hôtes du réseau cloud virtuel peuvent rencontrer des problèmes de communication avec les hôtes en dehors du réseau cloud virtuel.

  • Sans conservation de statut : non (toutes les règles doivent avoir la conservation de statut)
  • Type de source : CIDR
  • CIDR source : 0.0.0.0/0 (IPv4), : :/0 (IPv6)
  • Protocole IP : ICMP
  • Type : 3
  • Code : 4
Règle entrante générale 3 : autorise les messages d'erreur de connectivité dans le réseau cloud virtuel

Cette règle permet aux hôtes du réseau cloud virtuel de recevoir des messages d'erreur de connectivité de la part des autres.

  • Sans conservation de statut : non (toutes les règles doivent avoir la conservation de statut)
  • Type de source : CIDR
  • Source CIDR: IPv4: your VCN's IPv4 CIDR, IPv6: your VCN's IPv6 CIDR
  • Protocole IP : ICMP
  • Type : Tout
  • Code : Tout
Règle sortante générale 1 : autorise tout le trafic sortant
  • Sans conservation de statut : non (toutes les règles doivent avoir la conservation de statut)
  • Type de destination : CIDR
  • CIDR de destination : 0.0.0.0/0 (IPv4), : :/0 (IPv6)
  • Protocole IP : tous

Si le client active les notifications pour les événements de machine virtuelle invitée de plan de données, la règle sortante par défaut est suffisante.

Règles requises spécifiquement pour le réseau client

Les règles de sécurité suivantes sont importantes pour le réseau client.

Remarque

  • Pour les systèmes X8M, Oracle recommande d'ouvrir tous les ports du sous-réseau client pour le trafic entrant et sortant. Il s'agit d'une exigence pour l'ajout de serveurs de base de données supplémentaires au système.
  • Les règles entrantes client 1 et 2 couvrent uniquement les connexions lancées à partir du sous-réseau client. Si l'un de vos clients réside en dehors du réseau cloud virtuel, Oracle recommande de configurer deux règles similaires supplémentaires dont le CIDR source est défini sur l'adresse IP publique du client.
  • Les règles entrantes client 3 et 4, et les règles sortantes client 1 et 2 autorisent le trafic TCP et ICMP à l'intérieur du réseau client, et permettent aux noeuds de communiquer entre eux. En cas d'échec de la connectivité TCP sur les noeuds, le provisionnement de la ressource de cluster de machines virtuelles cloud Exadata ou de système de base de données échoue.

Rubrique parent : Règles de sécurité pour Oracle Exadata Database Service sur une infrastructure Exascale

Règle entrante client 1 : autorise le trafic ONS et FAN à partir du sous-réseau client

La première règle est recommandée et permet à Oracle Notification Services (ONS) de communiquer à propos des événements FAN (Fast Application Notification).

  • Sans conservation de statut : non (toutes les règles doivent avoir la conservation de statut)
  • Type de source : CIDR
  • Source CIDR: IPv4: client subnet's IPv4 CIDR, IPv6: client subnet's IPv6 CIDR
  • Protocole IP : TCP.
  • Plage de ports source : Tout
  • Plage de ports de destination : 6200
  • Description : description facultative de la règle.
Règle entrante client 2 : autorise le trafic SQL*NET à partir du sous-réseau client

Cette règle concerne le trafic SQL*NET et est requise dans les cas suivants :

  • Si vous devez activer les connexions client à la base de données
  • Si vous prévoyez d'utiliser Oracle Data Guard
  • Sans conservation de statut : non (toutes les règles doivent avoir la conservation de statut)
  • Type de source : CIDR
  • Source CIDR: IPv4: client subnet's IPv4 CIDR, IPv6: client subnet's IPv6 CIDR
  • Protocole IP : TCP.
  • Plage de ports source : Tout
  • Plage de ports de destination : 1521
  • Description : description facultative de la règle.
Règle sortante client 1 : autorise tout le trafic TCP à l'intérieur du sous-réseau client

Cette règle concerne le trafic SQL*NET, comme indiqué.

  • Sans conservation de statut : non (toutes les règles doivent avoir la conservation de statut)
  • Type de destination : CIDR
  • CIDR de destination : 0.0.0.0/0 (IPv4), : :/0 (IPv6)
  • Protocole IP : TCP.
  • Plage de ports source : Tout
  • Plage de ports de destination : 22
  • Description : description facultative de la règle.
Règle sortante client 2 : autorise tout le trafic sortant (autorise les connexions aux référentiels Oracle YUM)

La règle sortante client 3 est importante car elle autorise les connexions aux référentiels Oracle YUM.

Elle est redondante par rapport à la règle sortante générale 1 qui autorise tout le trafic sortant (et dans la liste de sécurité par défaut). Elle est facultative mais recommandée si la règle sortante générale (ou la liste de sécurité par défaut) est modifiée par inadvertance.

  • Sans conservation de statut : non (toutes les règles doivent avoir la conservation de statut)
  • Type de destination : CIDR
  • CIDR de destination : 0.0.0.0/0 (IPv4), : :/0 (IPv6)
  • Protocole IP : tous
  • Description : description facultative de la règle.
Règle requise spécifiquement pour le réseau de sauvegarde

La règle de sécurité suivante est importante pour le réseau de sauvegarde car elle permet au système de base de données de communiquer avec Object Storage via la passerelle de service (et éventuellement avec les référentiels Oracle YUM si le réseau client n'y a pas accès).

Elle est redondante par rapport à la règle sortante générale 1 qui autorise tout le trafic sortant. Elle est facultative mais recommandée si la règle sortante générale (ou la liste de sécurité par défaut) est modifiée par inadvertance.

Règles requises pour le service Events

L'instance de calcul doit disposer d'une adresse IP publique ou d'une passerelle de service pour pouvoir envoyer des mesures d'instance de calcul au service Events.

Les règles sortantes par défaut sont suffisantes pour permettre à l'instance de calcul d'envoyer des mesures d'instance de calcul au service Events.

Si l'instance ne dispose pas d'une adresse IP publique, configurez une passerelle de service sur le réseau cloud virtuel. La passerelle de service permet à l'instance d'envoyer des mesures d'instance de calcul au service Events sans que le trafic passe sur Internet. Voici quelques remarques spéciales sur la configuration de la passerelle de service pour l'accès au service Events :

  • Lors de la création de la passerelle de service, activez le libellé de service appelé Tous les services <région> dans Oracle Services Network. Il inclut le service Events.

  • Lors de la configuration du routage pour le sous-réseau qui contient l'instance, configurez une règle de routage dont le type de cible est défini sur Passerelle de service et le service de destination sur Tous les services <région> dans Oracle Services Network.

    Pour obtenir des instructions détaillées, reportez-vous à Accès aux services Oracle : passerelle de service.

Règles requises pour le service Monitoring

L'instance de calcul doit disposer d'une adresse IP publique ou d'une passerelle de service pour pouvoir envoyer des mesures d'instance de calcul au service Monitoring.

Les règles sortantes par défaut sont suffisantes pour permettre à l'instance de calcul d'envoyer des mesures d'instance de calcul au service Monitoring.

Si l'instance ne dispose pas d'une adresse IP publique, configurez une passerelle de service sur le réseau cloud virtuel. La passerelle de service permet à l'instance d'envoyer des mesures d'instance de calcul au service Monitoring sans que le trafic passe sur Internet. Voici quelques remarques spéciales sur la configuration de la passerelle de service pour l'accès au service Monitoring :

  • Lors de la création de la passerelle de service, activez le libellé de service appelé Tous les services <région> dans Oracle Services Network. Il inclut le service Monitoring.

  • Lors de la configuration du routage pour le sous-réseau qui contient l'instance, configurez une règle de routage dont le type de cible est défini sur Passerelle de service et le service de destination sur Tous les services <région> dans Oracle Services Network.

    Pour obtenir des instructions détaillées, reportez-vous à Accès aux services Oracle : passerelle de service.

Méthodes d'implémentation des règles de sécurité

Découvrez comment implémenter des règles de sécurité dans votre VCN à l'aide du service de mise en réseau.

Le service Networking propose deux méthodes d'implémentation des règles de sécurité dans votre réseau cloud virtuel :

Pour consulter une comparaison des deux méthodes, reportez-vous à Comparaison entre les listes de sécurité et les groupes de sécurité réseau.

Si vous utilisez des groupes de sécurité réseau

Si vous choisissez d'utiliser des groupes de sécurité réseau, procédez comme suit :

  1. Créez un groupe de sécurité réseau pour le réseau client. Ajoutez les règles de sécurité suivantes à ce groupe de sécurité réseau :

    • Règles répertoriées dans "Règles requises pour le réseau client et le réseau de sauvegarde"
    • Règles répertoriées dans "Règles requises spécifiquement pour le réseau client"

  2. Créez un groupe de sécurité réseau distinct pour le réseau de sauvegarde. Ajoutez les règles de sécurité suivantes à ce groupe de sécurité réseau :

    • Règles répertoriées dans "Règles requises pour le réseau client et le réseau de sauvegarde"
    • Règles répertoriées dans "Règles requises spécifiquement pour le réseau client"
  3. En tant qu'administrateur de base de données, lorsque vous créez une instance Exadata sur Exadata Database Service on Exascale Infrastructure, vous devez choisir plusieurs composants réseau (par exemple, le VCN et les sous-réseaux à utiliser) :
    • Lorsque vous choisissez le sous-réseau client, vous pouvez également choisir les groupes de sécurité réseau à utiliser. Choisissez le groupe de sécurité réseau du réseau client.
    • Lorsque vous choisissez le sous-réseau de sauvegarde, vous pouvez également choisir les groupes de sécurité réseau à utiliser. Choisissez le groupe de réseau du réseau de sauvegarde.

Vous pouvez également créer un groupe de sécurité réseau distinct pour les règles générales. Ensuite, lorsque les administrateurs de base de données choisissent les groupes de sécurité réseau à utiliser pour le réseau client, ils choisissent le groupe de sécurité réseau général et celui du réseau client. De même, pour le réseau de sauvegarde, il doit sélectionner le groupe de sécurité réseau général et celui du réseau de sauvegarde.

Si vous utilisez des listes de sécurité

Si vous choisissez d'utiliser des listes de sécurité, le processus recommandé est le suivant :

Si vous choisissez d'utiliser des listes de sécurité, le processus recommandé est le suivant :

  1. Configurez le sous-réseau client afin qu'il utilise les règles de sécurité requises :

    1. Créez une liste de sécurité personnalisée pour le sous-réseau client et ajoutez les règles répertoriées dans Règles requises spécifiquement pour le réseau client.

    2. Associez les deux listes de sécurité suivantes au sous-réseau client :

      • Liste de sécurité par défaut du réseau cloud virtuel avec toutes ses règles par défaut. Elle est automatiquement incluse avec le réseau cloud virtuel. Par défaut, elle contient les règles indiquées dans Règles requises pour le réseau client et le réseau de sauvegarde.
      • Liste de sécurité personnalisée créée pour le sous-réseau client.

  2. Configurez le sous-réseau de sauvegarde afin qu'il utilise les règles de sécurité requises :

    1. Créez une liste de sécurité personnalisée pour le sous-réseau de sauvegarde et ajoutez les règles répertoriées dans Règle requise spécifiquement pour le réseau de sauvegarde.

    2. Associez les deux listes de sécurité suivantes au sous-réseau de sauvegarde :

      • Liste de sécurité par défaut du réseau cloud virtuel avec toutes ses règles par défaut. Elle est automatiquement incluse avec le réseau cloud virtuel. Par défaut, elle contient les règles indiquées dans Règles requises pour le réseau client et le réseau de sauvegarde.
      • Liste de sécurité personnalisée créée pour le sous-réseau de sauvegarde.

Par la suite, lorsque l'administrateur de base de données crée l'instance Exadata Cloud Service, il doit choisir plusieurs composants réseau. Lorsqu'il sélectionne le sous-réseau client et le sous-réseau de sauvegarde que vous avez déjà créés et configurés, les règles de sécurité sont automatiquement appliquées aux noeuds créés dans ces sous-réseaux.

Avertissement :

N'enlevez pas la règle sortante par défaut de la liste de sécurité par défaut. Si vous le faites, veillez à inclure à la place la règle sortante de remplacement suivante dans la liste de sécurité du sous-réseau client :

  • Sans conservation de statut : non (toutes les règles doivent avoir la conservation de statut)
  • Type de destination : CIDR
  • CIDR de destination : 0.0.0.0/0
  • Protocole IP : tous

Configuration réseau requise pour Oracle Database Autonomous Recovery Service

Oracle Database Autonomous Recovery Service requiert un sous-réseau Recovery Service inscrit dédié aux opérations de sauvegarde et de récupération dans votre réseau cloud virtuel de base de données (VCN).

Pour utiliser Recovery Service pour les sauvegardes, suivez les étapes décrites dans Configuration du service de récupération.

Rubriques connexes

Rubrique parent : Configuration réseau d'Oracle Exadata Database Service sur des instances d'infrastructure Exascale

Création d'une passerelle de service vers Object Storage

Dans la console OCI, créez une passerelle de service vers Object Storage. La passerelle de service est requise pour les mises à jour d'automatisation et les métadonnées de configuration.

Remarque

A compter du 06 août 2025, pour les locations créées dans les régions FRA, PHX ou NRT, Autonomous Recovery Service sera la seule destination de sauvegarde lorsque vous activerez la sauvegarde automatique sur les bases de données.
  1. Ouvrez le menu de navigation. Cliquez sur Networking, puis sur Réseaux cloud virtuels.
  2. Sélectionnez le VCN où se trouvent les services de base de données à sauvegarder.
  3. Sur la page Détails du réseau cloud virtuel obtenue, sous Ressources, cliquez sur Passerelles de service.
  4. Cliquez sur Créer une passerelle de service et fournissez les détails suivants.
    1. Nom : nom descriptif de la passerelle de service. Il ne doit pas nécessairement être unique. Evitez de saisir des informations confidentielles.
    2. Compartiment : compartiment dans lequel créer la passerelle de service, s'il est différent du compartiment dans lequel vous travaillez actuellement.
    3. Services : sélectionnez le libellé CIDR de service, All <region> Services in Oracle Services Network, dans la liste déroulante.
    4. Balises : (option avancée) si vous êtes autorisé à créer une ressource, vous disposez également des droits d'accès nécessaires pour appliquer des balises de format libre à cette ressource. Pour appliquer une balise définie, vous devez disposer de droits d'accès permettant d'utiliser l'espace de noms de balise. Pour plus d'informations sur le balisage, reportez-vous à Balises de ressource. Si vous n'êtes pas certain d'appliquer des balises, ignorez cette option (vous pouvez les appliquer ultérieurement) ou demandez à l'administrateur.

  5. Cliquez sur Créer une passerelle de service.

    Attendez que la passerelle soit créée avant de passer à l'étape suivante.

  6. Sous Ressources, cliquez sur Tables de routage.

    Association de table de routage : vous pouvez associer une table de routage VCN spécifique à cette passerelle. Si vous associez une table de routage, la passerelle doit ensuite toujours être associée à une table de routage. Vous pouvez modifier les règles de la table de routage en cours ou les remplacer par une autre.

  7. Cliquez sur le nom de la table de routage utilisée par le sous-réseau pour Recovery Service.

  8. Sur la page Détails de la table de routage obtenue, cliquez sur Ajouter des règles de routage dans la section Règles de routage.

    Lorsque vous configurez une passerelle de service pour un libellé CIDR de service particulier, vous devez également créer une règle de routage spécifiant le libellé en tant que destination et la passerelle de service en tant que cible. Vous effectuez cette opération pour chaque sous-réseau devant accéder à la passerelle.

  9. Dans la boîte de dialogue Ajouter des règles de routage qui apparaît, entrez les détails suivants :
    1. Type de cible : passerelle de service.
    2. Service de destination : libellé CIDR de service activé pour la passerelle. All <region> Services in Oracle Services Network
    3. Passerelle de service cible : sélectionnez le nom que vous avez fourni à l'étape 4.
    4. Description : description facultative de la règle.
  10. Cliquez sur Ajouter des règles de routage.

Interopérabilité entre les services ExaDB-D et ExaDB-XS : Data Guard, sauvegarde et restauration

Vous pouvez désormais créer un groupe Oracle Data Guard interservices entre les services de base de données.

Grâce à cette fonctionnalité, vous pouvez établir une capacité de sauvegarde et de restauration interservices pour les configurations suivantes :  

  • Base de données principale sur ExaDB-D avec une ou plusieurs bases de données de secours sur ExaDB-XS ou ExaDB-D.
  • Base de données principale sur ExaDB-XS avec une ou plusieurs bases de données de secours sur ExaDB-D ou ExaDB-XS.
Remarque

Au moment de cette version, Oracle Data Guard entre Exadata Database Service on Dedicated Infrastructure et Exadata Database Service on Exascale Infrastructure ne peut être configuré qu'avec la version Oracle Database 23ai.

Cette fonctionnalité vous permet d'exploiter le potentiel de vos services de base de données dans votre location,

Remarque

Pour garantir la disponibilité maximale, Oracle recommande de placer les clusters de machines virtuelles homologues dans une infrastructure Exadata différente de celle du cluster de machines virtuelles principal.

Options de configuration de la base de données de secours

Lors de l'ajout d'une base de données de secours, vous pouvez indiquer les détails suivants :

  • Détails du cluster de machines virtuelles homologues : si la cible est ExaDB-D, vous pouvez sélectionner l'infrastructure Exadata.
  • Sélection de service cible : choisissez ExaDB-D ou ExaDB-XS. Par défaut, le service qui lance le groupe Data Guard est sélectionné. Si un service n'est pas disponible dans la région sélectionnée, il est désactivé avec le message suivant : "Le service n'est pas disponible dans cette région".
  • Type Data Guard : le groupe peut être configuré avec Data Guard ou Active Data Guard, et chaque base de données de secours peut avoir un type différent.
  • Limitation des groupes Data Guard : une base de données principale est limitée à un groupe Data Guard.
  • Création d'une base de données de secours : une seule base de données de secours peut être ajoutée à la fois. Toutefois, les bases de données de secours peuvent être créées dans l'une des catégories suivantes sans restriction de leur nombre :
    • Dans le même service
    • Dans l'ensemble des services
    • Dans le même domaine de disponibilité
    • Sur l'ensemble des domaines de disponibilité de la même région
    • Dans toutes les régions

Remarques importantes concernant les bases de données principales et de secours interservices

  • Les bases de données principale et de secours doivent utiliser la même solution de gestion des clés.
  • Data Guard peut être configuré en mode de protection Performances maximales ou Disponibilité maximale avec le type de transport Synchronisation ou Asynchrone, selon les règles suivantes :
    • Pour la première base de données de secours :
      • La valeur par défaut est le mode Performances maximales avec transport asynchrone.
      • Le mode de protection et le type de transport ne peuvent pas être modifiés.
    • Pour la deuxième base de données de secours et les bases de données de secours suivantes :
      • Hérite du mode de protection de la première veille.
      • La valeur par défaut est Transport asynchrone.
      • Le mode de protection et le type de transport ne peuvent pas être modifiés.

Afficher et modifier des configurations Data Guard

  • Affichez toutes les bases de données qui font partie du groupe Data Guard dans la table Groupe Data Guard, que vous soyez sur les pages de base de données principale ou de secours.
  • Modifiez la configuration Data Guard pour mettre à jour :
    • Type Data Guard : peut être différent pour chaque base de données de secours. Elle ne peut être modifiée qu'à partir d'une base de données de secours.
    • Mot de passe d'administrateur de base de données : peut être modifié à partir de n'importe quelle base de données.
    • Mode de protection : permet de basculer entre les performances maximales et la disponibilité maximale à partir de la base de données principale ou de toute base de données de secours.
    • Type de transport : peut être basculé entre Async et Sync uniquement à partir d'une base de données de secours.
Remarque

Si le mode de protection est défini sur Disponibilité maximale, le système vérifie qu'au moins une base de données de secours utilise le transport Sync. Si elle est introuvable, un message d'erreur s'affiche :

"Pour éviter toute perte de données, vous avez besoin d'au moins une base de données de secours avec le transport Sync. Il est recommandé d'avoir une base de données de secours avec le transport Sync dans le même service que la base de données principale."

Permutation et basculement de bases de données

  • Permutation (sur n'importe quelle base de données de secours)
    • La permutation est effectuée sans imposer de vérification de version majeure ou de mise à jour de version (RU). Toutefois, un avertissement s'affiche si la base de données de secours présente une configuration asymétrique, telle que des nombres de noeuds, de la mémoire ou un type de service différents.
  • Basculement (sur n'importe quelle base de données de secours)
    • Le basculement est effectué sans imposer de vérification de version majeure ou de mise à jour de version (RU). Toutefois, un avertissement s'affiche si la base de données de secours présente une configuration asymétrique, telle que le nombre de noeuds, la mémoire ou le type de service.

Options de sauvegarde et de restauration de base de données

Remarque

A partir du 06 août 2025, pour les locations créées dans les régions FRA, PHX ou NRT, Autonomous Recovery Service sera la seule destination de sauvegarde lorsque vous activerez la sauvegarde automatique sur les bases de données.

  • Sauvegardes programmées et automatiques
    • Vous pouvez programmer des sauvegardes automatiques sur la base de données principale, la base de données de secours ou les deux.
    • Les sauvegardes Object Storage et Recovery Service sont prises en charge.
    • Si les sauvegardes sont configurées sur les bases de données principale et de secours, elles doivent utiliser le même type de destination de sauvegarde.
  • Restauration sur place de la même base de données dans ExaDB-XS
    Restaurez et récupérez une base de données à l'aide d'une sauvegarde effectuée à partir de la même base de données dans ExaDB-XS :
    • Restaurer la base principale à l'aide d'une sauvegarde effectuée sur la base principale.
    • Restaurez la base de données de secours à l'aide d'une sauvegarde effectuée sur cette base.
  • Restauration sur place d'une base de données homologue dans ExaDB-XS
    Restaurez et récupérez une base de données homologue (sans sauvegarde configurée) à l'aide d'une sauvegarde à partir de la base de données source avec Recovery Service :
    • Scénario 1 : restaurez la base principale à l'aide de la sauvegarde de secours.
      • Base de données principale : ExaDB-XS (aucune sauvegarde configurée)
      • Base de données de secours : ExaDB-XS (sauvegardes configurées pour Recovery Service)
    • Scénario 2 : restaurez l'instance de secours à l'aide de la sauvegarde principale.
      • Base de données principale : ExaDB-XS (sauvegardes configurées pour Recovery Service)
      • Base de données de secours : ExaDB-XS (aucune sauvegarde configurée)
  • Restauration sur place d'une base de données homologue sur l'ensemble des services
    Restaurez et récupérez une base de données dans ExaDB-XS ou ExaDB-D à l'aide d'une sauvegarde à partir de la base de données source dans le service opposé (ExaDB-D ou ExaDB-XS) avec Recovery Service :
    • Scénario 1 : restaurez une base de données homologue dans ExaDB-XS à l'aide d'une sauvegarde à partir de ExaDB-D.
      • Cas d'emploi 1 : restaurez la base principale à l'aide de la sauvegarde de secours.
      • Cas d'emploi 2 : restaurez la base de données de secours à l'aide de la sauvegarde principale.
    • Scénario 2 : restaurez une base de données homologue dans ExaDB-D à l'aide d'une sauvegarde à partir de ExaDB-XS.
      • Cas d'emploi 1 : restaurez la base principale à l'aide de la sauvegarde de secours.
      • Cas d'emploi 2 : restaurez la base de données de secours à l'aide de la sauvegarde principale.

Restauration "out-of-place" (création d'une base de données)

  • Dans ExaDB-XSVous pouvez créer une base de données dans ExaDB-XS à l'aide d'une sauvegarde à partir du même service.
    • Restaurer dans :
      • Le même domaine de disponibilité
      • Un autre domaine de disponibilité dans la même région
      • Une région différente
    • Prend en charge Object Storage ou Recovery Service en tant que destination de sauvegarde.
  • Sur l'ensemble des services
    • Scénario 1 : créez une base de données dans ExaDB-D à l'aide d'une sauvegarde à partir de ExaDB-XS
      • Source : ExaDB-XS (base de données et sauvegardes)
      • Cible : ExaDB-D (toute région ou domaine de disponibilité)
      • Destination de sauvegarde : service Object Storage ou Recovery
    • Scénario 2 : créez une base de données dans ExaDB-XS à l'aide d'une sauvegarde à partir de ExaDB-D
      • Source : ExaDB-D (base de données et sauvegardes)
      • Cible : ExaDB-XS (toute région ou domaine de disponibilité)
      • Destination de sauvegarde : service Object Storage ou Recovery