Documentation Oracle Cloud Infrastructure

Configuration réseau pour les instances Exadata Cloud Infrastructure

Cette rubrique décrit la configuration recommandée pour le réseau cloud virtuel et plusieurs exigences associées pour l'instance Exadata Cloud Infrastructure.

Avant de configurer une instance Exadata Cloud Infrastructure, vous devez configurer un réseau cloud virtuel et d'autres composants du service Networking.

Rubrique parent : Préparation pour Exadata Cloud Infrastructure

Réseau cloud virtuel et sous-réseaux

Pour lancer une instance Exadata Cloud Infrastructure, vous devez disposer d'un réseau cloud virtuel et d'au moins deux sous-réseaux :

Pour lancer une instance Exadata Cloud Infrastructure, 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 :

  • Réseau cloud virtuel de la région dans laquelle vous souhaitez utiliser l'instance Exadata Cloud Infrastructure
  • 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.
Remarque

Pour les instances Exadata Cloud Infrastructure utilisant le nouveau modèle de ressource Exadata Cloud Infrastructure, les fonctions de réseau est configurées sur la ressource du cluster des machines virtuelles cloud.

Le sous-réseau client peut être configuré avec la mise en réseau double pile IPv4 ou IPv4/IPv6.

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é afin de contrôler le trafic depuis et vers le réseau client et le réseau de sauvegarde des noeuds de calcul Exadata (les noeuds sont appelés machines virtuelles pour la ressource de cluster de machines virtuelles cloud). Des informations supplémentaires sont fournies ci-après sur ces éléments.

Rubriques connexes

Rubrique parent : Configuration réseau pour les instances Exadata Cloud Infrastructure

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

Cette option est utile lorsque vous réalisez une étude de faisabilité ou des tâches de développement.

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 schéma suivant et à sa description.

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

Vous configurez les éléments suivants :

Remarque

Important Reportez-vous à ce problème connu pour obtenir des informations sur la configuration des 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 schéma suivant et à sa description.

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

Vous configurez les éléments suivants :

  • 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 et target = DRG.
      • Règle pour le libellé CIDR de service appelée All <region> Services in Oracle Services Network et target = the service gateway. 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 et target = NAT gateway.
    • 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é All <region> Services in Oracle Services Network et target = the service gateway. 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

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

Si vous configurez des clusters de machines virtuelles Exadata Cloud Infrastructure (et donc des réseaux cloud virtuels) dans plusieurs régions, 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 Exadata X8 et versions antérieures, les deux sous-réseaux créés pour les clusters de machines virtuelles Exadata Cloud Infrastructure ne doivent pas chevaucher 192.168.128.0/20.

Pour Exadata X8M, X9M et X11M, les adresses IP 100.64.0.0/10 sont réservées à l'interconnexion et ne doivent pas être utilisées pour les réseaux cloud virtuels client ou de sauvegarde, ainsi que pour les clients de base de données.

Le tableau suivant répertorie les tailles de sous-réseau minimales requises, en fonction de l'infrastructure de machines virtuelles Exadata pour chaque taille de cluster de machines virtuelles. 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.

Taille de rack Sous-réseau client : nombre d'adresses IP requises Sous-réseau client : taille minimale Remarque Sous-réseau de sauvegarde : nombre d'adresses IP requises Sous-réseau de sauvegarde : taille minimale Remarque
Système de base ou quart de rack par cluster de machines virtuelles (4 adresses * 2 noeuds) + 3 pour les noms SCAN = 11 /28 (16 adresses IP) 3 adresses * 2 noeuds = 6 /28 (16 adresses IP)
Demi-rack par cluster de machines virtuelles (4 * 4 noeuds) + 3 = 19 /27 (32 adresses IP) 3 * 4 noeuds = 12 /28 (16 adresses IP)
Rack complet par cluster de machines virtuelles (4* 8 noeuds) + 3 = 35 /26 (64 adresses IP) 3 * 8 noeuds = 24 /27 (32 adresses IP)
Systèmes d'infrastructure flexibles (X8M et supérieurs) par cluster de machines virtuelles 4 adresses par noeud de base de données (2 noeuds au minimum) + 3 pour les noms SCAN Taille minimale déterminée par le nombre total d'adresses IP requises pour les noeuds de base de données 3 adresses par noeud de base de données (au moins 2 noeuds) Taille minimale déterminée par le nombre total d'adresses IP requises pour les noeuds de base de données
Remarque

Le service Networking réserve trois adresses IP dans chaque sous-réseau. 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.

Configuration d'un routage statique pour l'accès à la banque d'objets

Par défaut, l'ensemble du trafic d'une instance Exadata Cloud Infrastructure est acheminé 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 Exadata Cloud Infrastructure

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 (fonctionnalité 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 réseau cloud virtuel, les sous-réseaux et l'instance Exadata Cloud Infrastructure

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 Exadata Cloud Infrastructure. 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 :

  • Libellé de domaine de réseau cloud virtuel
  • Libellé de domaine de sous-réseau
  • Préfixe du nom d'hôte pour la ressource d'instance Exadata Cloud Infrastructure Cloud VM Cluster

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 exacs comme préfixe de nom d'hôte lorsque vous créez le cluster des 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
  • Et ainsi de suite

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

  • Longueur maximale recommandée : 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 réseau cloud virtuel

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

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é

Prérequis nécessaires à l'utilisation d'un DNS privé.

  • La vue privée et la zone privée doivent être créées avant que le provisionnement du cluster de machines virtuelles ne soit lancé. Pour obtenir des détails, 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, appliquer des patches et mettre à jour des outils cloud sur une instance Exadata Cloud Infrastructure, vous devez configurer l'accès à Oracle Cloud Infrastructure Object Storage. Quelle que soit la façon dont vous configurez le réseau cloud virtuel avec cet accès (par exemple, avec une passerelle de service), 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 les sauvegardes automatiques créées à l'aide de la console, des API ou des interfaces de ligne de commande.

Attention :

Vous devez configurer un routage statique pour l'accès à Object Storage sur chaque noeud de calcul d'une instance Exadata Cloud Infrastructure 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 (Phoenix) : 129.146.0.0/16

Procédure de configuration d'un routage statique pour accéder à Object Storage

  1. Accédez via SSH à un noeud de calcul dans l'instance Exadata Cloud Infrastructure. 

    ssh -i <private_key_path> opc@<node_ip_address>

  2. Connectez-vous en tant qu'utilisateur opc, puis émettez une commande sudo pour l'utilisateur root. 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 Exadata Cloud Infrastructure.

Passerelle de service pour le réseau cloud virtuel

Assurez-vous que votre VCN peut atteindre Oracle Services Network, en particulier Object Storage pour les sauvegardes, les référentiels Oracle YUM pour les mises à jour du système d'exploitation, IAM (Identity and Access Management) et OCI Vault (intégration KMS).

Remarque

Si le VCN n'a pas de connectivité à Oracle Services Network, le provisionnement de nouveaux clusters de machines virtuelles peut échouer et la gestion des clusters de machines virtuelles existants peut également être affectée.

Selon l'option choisie (option Option1 : sous-réseau client public avec passerelle Internet ou option 2 : sous-réseaux personnels), vous utilisez la passerelle de service de différentes manières. Reportez-vous aux deux sections suivantes.

Rubriques connexes

Rubrique parent : Configuration réseau pour les instances Exadata Cloud Infrastructure

Option 1 : accès de la passerelle de service au service OCI pour le sous-réseau de sauvegarde

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 schéma associé à l'option 1 :

Cette image présente la configuration réseau avec un sous-réseau client public.

En général, vous devez effectuer les opérations suivantes :

  • Effectuez les tâches de configuration d'une passerelle de service sur un VCN et activez spécifiquement le libellé CIDR de service appelé OCI <region> 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 <region> Object Storage et target = the service gateway.
  • 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 pour la sécurité avec le service de destination défini sur OCI <region> Object Storage. Reportez-vous à Règle requise spécifiquement pour le réseau de sauvegarde.

Option 2 : accès de la passerelle de service au service OCI pour les sous-réseaux client et de sauvegarde

Vous configurez à la fois le Sous-réseau client et le Sous-réseau de sauvegarde afin d'utiliser la passerelle du service pour accéder à Oracle Services Network, qui inclut Object Storage pour les sauvegardes, les référentiels Oracle YUM pour les mises à jour du système d'exploitation, IAM (Identity and Access Management) et OCI Vault (intégration KMS).

Remarque

Reportez-vous à ce problème connu 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 :

Cette image présente la configuration réseau avec un sous-réseau client privé.

En général, vous devez effectuer les opérations suivantes :

  • Effectuez les tâches de configuration d'une passerelle de service sur un VCN et activez spécifiquement le libellé CIDR de service appelé All <region> Services in 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 All <region> Services in Oracle Services Network et target = the service gateway.
  • 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 pour la sécurité avec le service de destination défini sur OCI <region> Object Storage. Reportez-vous à Règles de sécurité pour Oracle Exadata Cloud Service Règles de sécurité pour Oracle Exadata Database Service on Dedicated Infrastructure. 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 :

  • 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 le libellé OCI <region> Object Storage service CIDR et le libellé All <region> Services in Oracle Services Network pour la passerelle de service. Pour couvrir les besoins des deux sous-réseaux, vous devez activer All <region> Services in 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 pour les deux sous-réseaux doivent utiliser All <region> Services in Oracle Services Network pour leurs règles d'interface 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 comporte une règle d'acheminement qui utilise All <region> Services in Oracle Services Network, le sous-réseau peut disposer d'une règle d'accès qui utilise OCI <region> 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 on Dedicated Infrastructure

Cette section répertorie les règles de sécurité à utiliser avec Exadata Cloud Infrastructure.

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 noeuds de calcul Exadata. 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.
Remarque

Si vous prévoyez d'utiliser le routage de paquets sans confiance pour contrôler les réseaux de vos services de base de données et que vous prévoyez de configurer des homologues Data Guard au sein du même VCN, tous les clusters de machines virtuelles de la configuration VCN et Data Guard doivent avoir le même attribut de sécurité ZPR. Les homologues Data Guard qui se trouvent dans un autre VCN ou une autre région doivent être spécifiés par le CIDR dans la configuration ZPR.

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

Cette section 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 répondre à 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 vers et depuis les hôtes qui requièrent 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 appliquer 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 appliquer 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é les uns des autres.

  • Sans conservation de statut : Non (toutes les règles doivent appliquer 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 : ALL
  • Code : Tout

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

  • Sans conservation de statut : Non (toutes les règles doivent appliquer la conservation de statut)
  • Type de destination : CIDR
  • CIDR de destination : 0.0.0.0/0 (IPv4), : :/0 (IPv6)
  • Protocole IP : Tout

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 sortantes client 1 et 2 de la configuration réseau client autorisent le trafic TCP et ICMP, ce qui permet une communication sécurisée de noeud à noeud au sein du réseau client. Ces règles sont essentielles, car elles facilitent la connectivité TCP essentielle entre les noeuds. En cas d'échec de la connectivité TCP entre les noeuds, le provisionnement de la ressource de cluster de machines virtuelles Exadata Cloud ne se terminera pas.

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 appliquer 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 : tous
  • 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 appliquer 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 : tous
  • Plage de ports de destination : 1521
  • Description : description facultative de la règle

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

  • Sans conservation de statut : Non (toutes les règles doivent appliquer 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 : tous
  • 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 2 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 appliquer la conservation de statut)
  • Type de destination : CIDR
  • CIDR de destination : 0.0.0.0/0 (IPv4), : :/0 (IPv6)
  • Protocole IP : Tout
  • Description : description facultative de la règle

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

Les règles de sécurité suivantes sont importantes pour le réseau d'enregistrement car elles permettent au cluster de machines virtuelles de communiquer avec Object Storage via la passerelle d'assistance (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 appliquer 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 : tous
  • Plage de ports de destination : 443 (HTTPS)
  • Description : description facultative de la règle

Rubrique parent : Configuration réseau pour les instances Exadata Cloud Infrastructure

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 répondre à 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 vers et depuis les hôtes qui requièrent 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 appliquer 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 : tous
  • 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 appliquer 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é les uns des autres.

  • Sans conservation de statut : Non (toutes les règles doivent appliquer 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 appliquer la conservation de statut)
  • Type de destination : CIDR
  • CIDR de destination : 0.0.0.0/0 (IPv4), : :/0 (IPv6)
  • Protocole IP : Tout

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 vous avez un client qui réside en dehors du VCN, Oracle recommande de configurer deux règles similaires supplémentaires pour lesquelles 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 effet, en cas d'échec de la connectivité TCP sur ces noeuds, le provisionnement de l'unité de cluster Exadata échoue.

Rubrique parent : Règles de sécurité pour Oracle Exadata Database Service on Dedicated Infrastructure

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 appliquer 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 : tous
  • 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 appliquer 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 : tous
  • 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 appliquer 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 : tous
  • 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 appliquer la conservation de statut)
  • Type de destination : CIDR
  • CIDR de destination : 0.0.0.0/0 (IPv4), : :/0 (IPv6)
  • Protocole IP : Tout
  • Description : description facultative de la règle

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

Les règles de sécurité suivantes sont importantes pour le réseau d'une sauvegarde car elles permettent au cluster de machines virtuelles de communiquer avec Object Storage via la passerelle d'un service (et éventuellement avec les référentiels d'Oracle YUM si le réseau client n'y a pas accès).

Il est redondant 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ègle sortante de sauvegarde : autorise l'accès à Object Storage
  • Sans conservation de statut : Non (toutes les règles doivent appliquer 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 : tous
  • Plage de ports de destination : 443 (HTTPS)
  • Description : description facultative de la règle

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 offre deux façons d'implémenter 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.

Rubrique parent : Configuration réseau pour les instances Exadata Cloud Infrastructure

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

Si vous choisissez d'utiliser des groupes de sécurité réseau, voici le processus recommandé :

  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 :

  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 :

  3. Lorsque l'administrateur de base de données crée une instance Exadata Cloud Infrastructure, il doit choisir plusieurs composants réseau (par exemple, le réseau cloud virtuel et les sous-réseaux à utiliser) :
    • Lorsqu'il choisit le sous-réseau client, il peut également choisir les groupes de sécurité réseau à utiliser. Assurez-vous qu'il sélectionne le groupe de sécurité réseau du réseau client.
    • Lorsqu'il choisit le sous-réseau de sauvegarde, il peut également choisir les groupes de sécurité réseau à utiliser. Assurez-vous qu'il sélectionne le groupe de sécurité réseau du réseau de sauvegarde.

Vous avez également la possibilité de créer un groupe de sécurité réseau distinct pour les règles générales. Dans ce cas, lorsque l'administrateur de base de données choisit les groupes de sécurité réseau à utiliser pour le réseau client, assurez-vous qu'il sélectionne 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é, voici le processus recommandé :

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

  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 fournie automatiquement 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 fournie automatiquement 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 appliquer la conservation de statut)
  • Type de destination : CIDR
  • CIDR de destination : 0.0.0.0/0
  • Protocole IP : Tout

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 de Recovery Service.

Rubriques connexes

Rubrique parent : Configuration réseau pour les instances Exadata Cloud Infrastructure

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.

  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.