Documentation sur Oracle Cloud Infrastructure

Configuration du réseau pour les instances Exadata Cloud Infrastructure

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

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

Rubrique parent : Préparation pour Exadata Cloud Infrastructure

Réseaux en nuage virtuels et sous-réseaux

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

Pour lancer une instance Exadata Cloud Infrastructure, vous devez disposer d'un réseau en nuage virtuel, d'au moins deux sous-réseaux et sélectionner le type de résolveur DNS à utiliser :

  • Un réseau en nuage virtuel dans la région où vous voulez l'instance Exadata Cloud Infrastructure
  • Au moins deux sous-réseaux dans le réseau VCN. Les deux sous-réseaux sont :
    • Sous-réseau client
    • Sous-réseau de sauvegarde
  • Choisissez la méthode de résolution de nom DNS que vous utiliserez. Voir Choix pour le DNS dans votre VCN
Note

Pour les instances Exadata Cloud Infrastructure utilisant le nouveau modèle de ressource Exadata Cloud Infrastructure, le réseau est configuré sur la ressource de grappe de machines virtuelles en nuage.

Le sous-réseau client peut être configuré avec un réseau à pile double IPv4 ou IPv4/IPv6.

En général, Oracle recommande d'utiliser des sous-réseaux régionaux, qui couvrent tous les domaines de disponibilité de la région. Pour plus d'informations, voir Aperçu des réseaux en nuage virtuels et des sous-réseaux.

Vous allez créer des tables de routage personnalisées pour chaque sous-réseau. Vous créerez également des règles de sécurité pour contrôler le trafic vers et depuis le réseau client et le réseau de sauvegarde des noeuds de calcul Exadata (pour la ressource de grappe de machines virtuelles en nuage, les noeuds sont appelés machines virtuelles). Plus d'informations sur ces éléments suivent.

Rubriques connexes

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

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

Cette option peut être utile lors d'un travail de démonstration de faisabilité ou de développement.

Vous pouvez utiliser cette configuration en production si vous souhaitez utiliser une passerelle Internet avec le réseau VCN ou si vous avez des services qui s'exécutent uniquement sur un réseau public et ont besoin d'un accès à la base de données. Voir le diagramme et la description suivants.

Description de network_exa_public_client.png
Description de l'illustration network_exa_public_client.png

Vous configurez les éléments suivants :

Note

Important Voir ce problème connu pour plus d'informations sur la configuration des règles de routage en désignant la passerelle de service comme cible de ces tables associées à des sous-réseaux publics.

Rubrique parent : Réseau VCN et sous-réseaux

Option 2 : Sous-réseaux privés

Oracle recommande des 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. Voir le diagramme et la description suivants.

Description de network_exa_private_client.png
Description de l'illustration 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 VCN :

  • 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 place et la cible = DRG.
      • Règle d'étiquette CIDR de service appelée Tous les services de <region> dans Oracle Services Network et cible = la passerelle de service. Oracle Services Network est un réseau conceptuel dans Oracle Cloud Infrastructure qui est réservé aux services Oracle. La règle permet au sous-réseau client d'atteindre le référentiel régional d'Oracle YUM pour les mises à jour du système d'exploitation. Voir aussi Option 2 : Accès par la passerelle de service au service de stockage d'objets et aux référentiels YUM.
      • Facultativement, une règle pour 0.0.0.0/0 et cible = passerelle NAT.
    • Table de routage personnalisée distincte pour le sous-réseau de sauvegarde privé, avec une règle :
      • La même règle que pour le sous-réseau client : pour l'étiquette CIDR de service appelée Tous les services de <region> dans Oracle Services Network et cible = la passerelle de service. Cette règle permet au sous-réseau de sauvegarde d'accéder au service de stockage d'objets régional pour les sauvegardes.
  • Règles de sécurité pour permettre le trafic souhaité vers et depuis les noeuds Exadata. Voir Règles de sécurité pour l'instance du service Exadata Cloud.
  • Facultativement, ajoutez un routage statique sur les noeuds de calcul à d'autres services OCI (pour les grappes de machines virtuelles, les machines virtuelles) pour permettre l'accès, si les services ne sont accessibles que sur le sous-réseau de sauvegarde et non au moyen du sous-réseau client, par exemple, lors de l'utilisation d'une passerelle NAT.

Rubrique parent : Réseau VCN et sous-réseaux

Exigences pour l'espace d'adresses IP

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

Si vous configurez des grappes de machines virtuelles Exadata Cloud Infrastructure (et ainsi des réseaux en nuage virtuels) dans plusieurs régions, assurez-vous que les espaces d'adresses IP de ces derniers ne se chevauchent pas. Cette condition est importante si vous voulez configurer la récupération après sinistre avec Oracle Data Guard.

Pour Exadata X8 et les versions inférieures, les deux sous-réseaux que vous créez pour les grappes 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 entre noeuds et ne doivent pas être utilisées pour les réseaux en nuage virtuels de client ou de sauvegarde, ni pour les clients de base de données.

Le tableau suivant répertorie les tailles de sous-réseau minimales requises, selon l'infrastructure de machines virtuelles Exadata pour chaque taille de grappe de machines virtuelles. Pour le sous-réseau client, chaque noeud requiert quatre adresses IP. De plus, trois adresses sont réservées aux noms d'accès unique au client ( SCAN). Pour le sous-réseau de sauvegarde, chaque noeud requiert trois adresses.

Taille du bâti Sous-réseau de client : Nombre d'adresses IP requises Sous-réseau client : Taille minimale Note Sous-réseau de sauvegarde : Nombre d'adresses IP requises Sous-réseau de sauvegarde : Taille minimale Note
Système de base ou quart de bâti par grappe de machines virtuelles (4 adresses * 2 noeuds) + 3 pour des noms SCAN = 11 /28 (16 adresses IP) 3 adresses * 2 noeuds = 6 /28 (16 adresses IP)
Demi-bâti par grappe de machines virtuelles (4 * 4 noeuds) + 3 = 19 /27 (32 adresses IP) 3 * 4 noeuds = 12 /28 (16 adresses IP)
Bâti complet par grappe 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 plus) par grappe de machines virtuelles 4 adresses par noeud de base de données (au minimum 2 noeuds) + 3 pour des noms SCAN Taille minimale déterminée par le nombre total d'adresses IP nécessaires pour les noeuds de base de données 3 adresses par noeud de base de données (au minimum 2 noeuds) Taille minimale déterminée par le nombre total d'adresses IP nécessaires pour les noeuds de base de données
Note

Le service de réseau réserve trois adresses IP dans chaque sous-réseau. L'affectation au sous-réseau d'un espace supérieur au minimum requis (par exemple, au moins /25 au lieu de /28) peut limiter l'incidence relative de ces adresses réservées sur l'espace disponible du sous-réseau.

Rubrique parent : Réseau VCN et sous-réseaux

Configuration d'un routage statique pour l'accès au magasin d'objets

Tout le trafic dans une instance Exadata Cloud Infrastructure est, par défaut, acheminé par le réseau de données. Pour acheminer le trafic de sauvegarde vers l'interface de sauvegarde (BONDETH1), vous devez configurer un routage statique pour chaque noeud de calcul de la grappe.

Pour les instructions, voir Accès des noeuds au stockage d'objets : Routage statique.

Rubrique parent : Réseau VCN et sous-réseaux

Configuration du DNS pour une instance Exadata Cloud Infrastructure

DNS vous 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 VCN (fonction DNS intégrée au VCN), comme décrit dans DNS dans votre réseau en nuage virtuel. Oracle recommande d'utiliser un résolveur VCN pour la résolution de nom DNS pour le sous-réseau client. Il résout automatiquement les points d'extrémité Swift requis pour la sauvegarde des bases de données, l'application de correctifs et la mise à jour des outils en nuage sur une instance Exadata.

Rubrique parent : Réseau VCN et sous-réseaux

DNS : Noms abrégés pour le réseau en nuage virtuel, les sous-réseaux et l'instance Exadata Cloud Infrastructure

Pour que les noeuds communiquent, le VCN doit utiliser le résolveur Internet et de réseau VCN. Le résolveur Internet et de réseau VCN permet l'affectation de noms d'hôte aux noeuds et la résolution DNS de ceux-ci par ressources dans le réseau VCN.

Le résolveur Internet et de réseau VCN permet la résolution à tour de rôle des SCAN de la base de données. Il permet également la résolution de points d'extrémité de service importants requis pour la sauvegarde des bases de données, l'application de correctifs et la mise à jour des outils en nuage sur une instance Exadata Cloud Infrastructure. Le Résolveur Internet et de réseau VCN est le choix par défaut de DNS dans le réseau VCN. Pour plus d'informations, voir DNS dans votre réseau en nuage virtuel et Options DHCP.

Lorsque vous créez le réseau VCN, les sous-réseaux et Exadata, vous devez définir avec soin les identificateurs suivants, qui sont liés à DNS dans le réseau VCN :

  • Étiquette de domaine VCN
  • Étiquette de sous-réseau
  • Préfixe du nom d'hôte pour la ressource de grappe de machines virtuelles en nuage ou de système de base de données de l'instance Exadata Cloud Infrastructure

Ces valeurs constituent le nom de domaine complet (FQDN) du noeud :

<hostname_prefix>-######.<subnet_domain_label>.<vcn_domain_label>.oraclevcn.com

Par exemple :

exacs-abcde1.clientpvtad1.acmevcniad.oraclevcn.com (en anglais)

Dans cet exemple, vous affectez exacs comme préfixe de nom d'hôte lorsque vous créerez la grappe de machines virtuelles en nuage ou le système de base de données. Le service Base de données ajoute automatiquement un tiret 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 pour le préfixe de nom d'hôte :

  • Maximum recommandé : 12 caractères. Pour plus d'informations, voir l'exemple sous la section suivante, "Exigences pour les étiquettes de domaine VCN et de sous-réseau".
  • Ne peut pas être la chaîne localhost

Exigences pour les étiquettes de domaine VCN et de sous-réseau :

  • Maximum recommandé : 14 caractères chacun. L'exigence sous-jacente réelle est un total de 28 caractères pour les deux étiquettes de domaine (à l'exception du point entre les étiquettes). Par exemple, ces deux étiquettes sont acceptables : subnetad1.verylongvcnphx ou verylongsubnetad1.vcnphx. Par simplicité, la recommandation indique 14 caractères chacune.
  • Aucun tiret ni trait de soulignement.

  • Recommandation : Incluez le nom de la région dans l'étiquette de domaine du réseau VCN et le nom du domaine de disponibilité dans celle du sous-réseau.

  • En général, le nom de domaine complet ne doit pas dépasser 63 caractères. Voici une règle générale sûre :

    <12_chars_max>-######.<14_chars_max>.<14_chars_max>.oraclevcn.com

Les valeurs maximum précédentes ne sont pas appliquées lors de la création du réseau VCN et des sous-réseaux. En revanche, si les étiquettes dépassent le maximum, le déploiement d'Exadata échoue.

Rubrique parent : Réseau VCN et sous-réseaux

DNS : Entre le réseau sur place et le réseau VCN

Oracle recommande d'utiliser un résolveur DNS privé pour permettre l'utilisation de noms d'hôte lorsque des hôtes sur place et des ressources de réseau VCN communiquent entre eux.

Voir Résolveurs privés de DNS pour obtenir des informations sur la création et l'utilisation de résolveurs privés. Pour une architecture de référence, voir Utilisation de DNS privé dans votre VCN dans le centre d'architectures Oracle.

Rubrique parent : Réseau VCN et sous-réseaux

Configurer un DNS privé

Préalables pour utiliser un 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 de détails, voir Résolveurs DNS privés.
  • Le transfert vers un autre serveur DNS doit être préalablement configuré dans la console DNS. Pour ce faire, allez au résolveur du VCN et créez le point d'extrémité, puis les règles. Pour plus de détails, voir DNS dans le réseau en nuage virtuel.
  • Le nom de la zone privée ne peut pas contenir plus de 4 étiquettes. Par exemple, a.b.c.d est autorisé alors que 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, voir Ajout d'une vue privée à un résolveur.
  • Lors du provisionnement d'une grappe de machines virtuelles Exadata à l'aide de la fonction DNS privée, Exadata doit créer des zones DNS inverses dans le compartiment de la grappe de machines virtuelles Exadata. Si le compartiment a défini des marqueurs ou des valeurs par défaut de marqueur, des politiques supplémentaires liées à la gestion des marqueurs sont nécessaires. Pour plus de détails, consultez :

Rubrique parent : Réseau VCN et sous-réseaux

Accès des noeuds au stockage d'objets : Routage statique

Pour pouvoir sauvegarder des bases de données, appliquer des correctifs et des mises à jour à des outils en nuage sur une instance Exadata Cloud Infrastructure, vous devez configurer l'accès au service de stockage d'objets pour Oracle Cloud Infrastructure. Même si vous configurez le réseau VCN avec cet accès (par exemple, avec une passerelle de service), vous devez configurer un routage statique vers le service de stockage d'objets pour chaque noeud de calcul de la grappe. Cette opération n'est nécessaire que si vous n'utilisez pas de sauvegarde automatique. Si vous utilisez des sauvegardes personnalisées à l'aide des API de sauvegarde, vous devez acheminer le trafic destiné au service de stockage d'objets par l'interface de sauvegarde (BONDETH1). Ceci n'est pas nécessaire si vous utilisez les sauvegardes automatiques créées avec la console, les API ou les interfaces CLI.

Attention :

Vous devez configurer une route statique pour l'accès au service de stockage d'objets sur chaque noeud de calcul dans une instance Exadata Cloud Infrastructure si vous ne créez pas de sauvegardes automatiques avec la console, les API ou les interfaces de ligne de commande. Sinon, les tentatives de sauvegarde de bases de données, d'application de correctifs ou de mise à jour d'outils sur le système risquent d'échouer.
Note

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

Si vous voulez appliquer des correctifs au service avant de créer une base de données, le routage statique manuel est requis pour pouvoir appliquer des correctifs à Oracle Grid Infrastructure ou au répertoire de base de base de données.

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

Affectations d'adresses IP au service de stockage d'objets

Le service de stockage d'objets pour Oracle Cloud Infrastructure utilise l'intervalle d'adresses IP du bloc CIDR 134.70.0.0/16 pour toutes les régions.

À compter du 1er juin 2018, le service de stockage d'objets ne prend plus en charge les intervalles d'adresses IP abandonnés suivants. Oracle recommande de supprimer ces anciennes adresses IP des listes de contrôle d'accès, des règles de pare-feu et des autres règles après avoir adopté les nouveaux intervalles d'adresses IP.

Les intervalles d'adresses IP abandonnés sont les suivants :

  • Allemagne - Centre (Francfort) : 130.61.0.0/16
  • Royaume-Uni - Sud (Londres) : 132.145.0.0/16
  • États-Unis - Est (Ashburn) : 129.213.0.0/16
  • États-Unis - Ouest (Phoenix) : 129.146.0.0/16

Pour configurer un routage statique pour l'accès au service de stockage d'objets

  1. Accédez par 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'opc, puis accédez à la racine avec les privilèges de superviseur. Utilisez sudo su - avec un tiret pour appeler le profil de l'utilisateur racine. 

    
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 du fichier de l'étape précédente sont appliquées 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 dans l'instance Exadata Cloud Infrastructure.

Passerelle de service pour le réseau VCN

Votre réseau en nuage virtuel doit pouvoir accéder au service de stockage d'objets pour les sauvegardes et aux référentiels Oracle YUM pour les mises à jour du système d'exploitation.

Selon que vous utilisez l'option 1 : Sous-réseau client public avec passerelle Internet ou l'option 2 : Sous-réseaux privés décrite précédemment, vous utilisez la passerelle de service différemment. Voir les deux sections suivantes.

Rubriques connexes

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

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

Vous configurez le sous-réseau de sauvegarde pour utiliser la passerelle de service pour accéder uniquement au service de stockage d'objets.

Rappel : Voici le diagramme de l'option 1 :

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

En général, vous devez :

  • Effectuer les tâches de configuration d'une passerelle de service sur un VCN et activer spécifiquement l'étiquette CIDR du service appelée OCI <region> Stockage d'objets.
  • 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, utiliser OCI <region> Stockage d'objets et cible = la passerelle de service.
  • Effectuer la tâche de mise à jour des règles de sécurité dans le sous-réseau sur le groupe de sécurité du réseau de sauvegarde ou sur la liste de sécurité personnalisée. Configurer une règle de sécurité avec le service de destination réglé à OCI <region> Stockage d'objets. Voir Règle requise spécifiquement pour le réseau de sauvegarde Règle requise spécifiquement pour le réseau de sauvegarde.

Option 2 : Accès par la passerelle de service au service de stockage d'objets et aux référentiels YUM

Vous configurez à la fois le sous-réseau client et le sous-réseau de sauvegarde pour qu'ils utilisent la passerelle de service pour accéder à Oracle Services Network, qui inclut à la fois le service de stockage d'objets et les référentiels Oracle YUM.

Note

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

Rappel : Voici le diagramme de l'option 2 :

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

En général, vous devez :

  • Effectuer les tâches de configuration d'une passerelle de service sur un VCN et activer spécifiquement l'étiquette CIDR du service appelée Tous les services de <region> dans Oracle Services Network.
  • Dans la tâche de mise à jour du routage dans chaque sous-réseau, ajoutez une règle à chaque table de routage personnalisée du sous-réseau. Pour le service de destination, utilisez Tous les services de <region> dans Oracle Services Network et cible = la passerelle de service.
  • Effectuer la tâche de mise à jour des règles de sécurité dans le sous-réseau sur le groupe de sécurité du réseau de sauvegarde ou de la liste de sécurité personnalisée. Configurer une règle de sécurité avec le service de destination réglé à OCI <region> Stockage d'objets. Voir Règles de sécurité pour Oracle Exadata Cloud Service Règles de sécurité pour Oracle Exadata Database Service sur une infrastructure dédiée. Notez que le sous-réseau du client a déjà une règle de trafic sortant globale qui couvre l'accès aux référentiels YUM.

Voici quelques détails supplémentaires concernant 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, mais pour accéder à d'autres services. Vous ne pouvez pas activer en même temps l'étiquette OCI <region> Stockage d'objets et l'étiquette Tous les services <region> dans Oracle Services Network pour la passerelle de service. Pour couvrir les besoins des deux sous-réseaux, vous devez activer Tous les services de <region> dans Oracle Services Network pour la passerelle de service. Le réseau VCN ne peut avoir qu'une seule passerelle de service.
  • Toute règle de routage qui cible une passerelle de service indiquée doit utiliser une étiquette CIDR de service activée et non un bloc CIDR comme destination de la règle. Cela signifie que pour l'option 2, les tables de routage des deux sous-réseaux doivent utiliser Tous les services de <region> 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 toutes les étiquettes CIDR de service (que le réseau VCN ait une passerelle de service ou non) ou un bloc CIDR comme CIDR source ou de destination. Par conséquent, même si le sous-réseau de sauvegarde comporte une règle de routage qui utilise Tous les services <region> dans Oracle Services Network, le sous-réseau peut avoir une règle de sécurité utilisant le service OCI <region> Stockage d'objets. Voir Règles de sécurité pour l'instance du service Exadata Cloud.

Règles de sécurité pour le service Oracle Exadata Database sur une infrastructure dédiée

Cette section liste 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 d'Exadata. Les règles sont divisées en trois sections.

Il existe différentes façons de mettre en oeuvre ces règles. Pour plus d'informations, voir Méthodes de mise en oeuvre des règles de sécurité.
Note

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

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 pairs Data Guard dans le même VCN, toutes les grappes de machines virtuelles de la configuration VCN et Data Guard doivent avoir le même attribut de sécurité ZPR. Les pairs Data Guard qui se trouvent dans un VCN ou une région différente doivent être spécifiés par CIDR dans la configuration ZPR.

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

Cette section comporte plusieurs règles générales qui permettent une connectivité essentielle pour les hôtes du VCN.

Si vous utilisez des listes de sécurité pour mettre en oeuvre vos règles de sécurité, sachez que les règles suivantes sont incluses dans la liste de sécurité par défaut. Mettez à jour ou remplacez la liste selon vos besoins de sécurité particuliers. Les deux règles ICMP (règles de trafic entrant générales 2 et 3) sont requises pour gérer correctement le trafic réseau dans l'environnement Oracle Cloud Infrastructure. Ajustez la règle de trafic entrant générale 1 (règle SSH) et la règle de trafic sortant générale 1 pour autoriser le trafic uniquement vers et depuis les hôtes qui ont besoin de communiquer avec les ressources de votre réseau VCN.

Règle de trafic entrant générale 1 : Autorise le trafic SSH depuis n'importe où

  • Sans état : Non (toutes les règles doivent être avec état)
  • Type de source : CIDR
  • CIDR source : 0.0.0.0/0 (IPv4), : :/0 (IPv6)
  • Protocole IP : SSH
  • Intervalle de ports sources : Tous
  • Intervalle de ports de destination : 22

Règle de trafic entrant générale 2 : Autorise les messages de fragmentation de détection d'unité de transmission maximale de chemin

Cette règle permet aux hôtes dans le VCN de recevoir des messages de fragmentation de détection d'unité de transmission maximale de chemin. Sans accès à ces messages, les hôtes dans le VCN peuvent avoir de la difficulté à communiquer avec des hôtes à l'extérieur du VCN.

  • Sans état : Non (toutes les règles doivent être avec état)
  • Type de source : CIDR
  • CIDR source : 0.0.0.0/0 (IPv4), : :/0 (IPv6)
  • Protocole IP : ICMP
  • Type : 3
  • Code : 4

Règle de trafic entrant générale 3 : Autorise les messages d'erreur de connectivité dans le VCN

Cette règle permet aux hôtes dans le VCN de recevoir des messages d'erreur de connectivité l'un de l'autre.

  • Sans état : Non (toutes les règles doivent être avec état)
  • Type de source : CIDR
  • CIDR source : IPv4 : CIDR IPv4 CIDR de votre VCN, IPv6 : CIDR IPv6 de votre VCN
  • Protocole IP : ICMP
  • Type : TOUT
  • Code : Tout

Règle de trafic sortant générale 1 : Autorise tout le trafic sortant

  • Sans état : Non (toutes les règles doivent être avec état)
  • 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.

Note

  • Les règles de trafic entrant de client 1 et 2 ne couvrent que les connexions lancées à partir du sous-réseau client. Si vous avez un client qui réside en dehors du réseau VCN, Oracle recommande de configurer deux règles similaires supplémentaires, dont l'adresse CIDR source est réglée à l'adresse IP publique du client.
  • Les règles de trafic sortant client 1 et 2 dans la configuration du réseau client autorisent le trafic TCP et ICMP, ce qui permet une communication noeud à noeud sécurisée au sein du réseau client. Ces règles sont critiques, car elles facilitent la connectivité TCP essentielle entre les nœuds. Si la connectivité TCP échoue entre les noeuds, le provisionnement de la ressource de grappe de machines virtuelles Exadata Cloud échouera.

Règle de trafic entrant de client 1 : Autorise le trafic ONS et FAN à partir du sous-réseau client

La première règle est recommandée et permet aux services d'avis Oracle (ONS) de communiquer sur les événements d'avis rapide des applications (FAN).

  • Sans état : Non (toutes les règles doivent être avec état)
  • Type de source : CIDR
  • CIDR source : IPv4 : CIDR IPv4 CIDR du sous-réseau client, IPv6 : CIDR IPv6 du sous-réseau client
  • Protocole IP : TCP
  • Intervalle de ports sources : Tous
  • Intervalle de ports de destination : 6200
  • Description : Description facultative de la règle.

Règle de trafic entrant de client 2 : Autorise le trafic SQL*NET à partir du sous-réseau client

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

  • Si vous devez activer les connexions de client à la base de données
  • Si vous envisagez d'utiliser Oracle Data Guard
  • Sans état : Non (toutes les règles doivent être avec état)
  • Type de source : CIDR
  • CIDR source : IPv4 : CIDR IPv4 CIDR du sous-réseau client, IPv6 : CIDR IPv6 du sous-réseau client
  • Protocole IP : TCP
  • Intervalle de ports sources : Tous
  • Intervalle de ports de destination : 1521
  • Description : Description facultative de la règle.

Règle de trafic sortant de client 1 : Permet le trafic TCP SSH dans le sous-réseau du client

  • Sans état : Non (toutes les règles doivent être avec état)
  • Type de destination : CIDR
  • CIDR de destination : 0.0.0.0/0 (IPv4), : :/0 (IPv6)
  • Protocole IP : TCP
  • Intervalle de ports sources : Tous
  • Intervalle de ports de destination : 22
  • Description : Description facultative de la règle.

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

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

  • Sans état : Non (toutes les règles doivent être avec état)
  • 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

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 le service de stockage d'objets au moyen de la passerelle de service (et au besoin, les référentiels d'Oracle YUM si le réseau client n'a pas accès à ceux-ci). Elle est redondante avec la règle de trafic sortant générale dans cette rubrique (et dans la liste de sécurité par défaut). Elle est facultative mais recommandée si la règle de trafic sortant générale (ou liste de sécurité par défaut) est modifiée par inadvertance.

Règle de trafic sortant de sauvegarde : Permet l'accès au service de stockage d'objets

  • Sans état : Non (toutes les règles doivent être avec état)
  • Type de destination : Service

  • Service de destination :

    • Étiquette CIDR du service appelée OCI <region> Stockage d'objets
    • Si le réseau client n'a pas accès aux référentiels Oracle YUM, utilisez l'étiquette CIDR du service appelée Tous les services de <region> dans Oracle Services Network
  • Protocole IP : TCP
  • Intervalle de ports sources : Tous
  • Intervalle de ports de destination : 443 (HTTPS)
  • Description : Description facultative de la règle.

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

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

Cette rubrique présente plusieurs règles générales permettant une connectivité essentielle pour les hôtes dans le VCN.

Si vous utilisez des listes de sécurité pour mettre en oeuvre vos règles de sécurité, sachez que les règles suivantes sont incluses dans la liste de sécurité par défaut. Mettez à jour ou remplacez la liste selon vos besoins de sécurité particuliers. Les deux règles ICMP (règles de trafic entrant générales 2 et 3) sont requises pour gérer correctement le trafic réseau dans l'environnement Oracle Cloud Infrastructure. Ajustez la règle de trafic entrant générale 1 (règle SSH) et la règle de trafic sortant générale 1 pour autoriser le trafic uniquement vers et depuis les hôtes qui ont besoin de communiquer avec les ressources de votre réseau VCN.

Règle de trafic entrant générale 1 : Autorise le trafic SSH depuis n'importe où
  • Sans état : Non (toutes les règles doivent être avec état)
  • Type de source : CIDR
  • CIDR source : 0.0.0.0/0 (IPv4), : :/0 (IPv6)
  • Protocole IP : SSH
  • Intervalle de ports sources : Tous
  • Intervalle de ports de destination : 22
Règle de trafic entrant générale 2 : Autorise les messages de fragmentation de détection d'unité de transmission maximale de chemin

Cette règle permet aux hôtes dans le VCN de recevoir des messages de fragmentation de détection d'unité de transmission maximale de chemin. Sans accès à ces messages, les hôtes dans le VCN peuvent avoir de la difficulté à communiquer avec des hôtes à l'extérieur du VCN.

  • Sans état : Non (toutes les règles doivent être avec état)
  • Type de source : CIDR
  • CIDR source : 0.0.0.0/0 (IPv4), : :/0 (IPv6)
  • Protocole IP : ICMP
  • Type : 3
  • Code : 4
Règle de trafic entrant générale 3 : Autorise les messages d'erreur de connectivité dans le VCN

Cette règle permet aux hôtes dans le VCN de recevoir des messages d'erreur de connectivité l'un de l'autre.

  • Sans état : Non (toutes les règles doivent être avec état)
  • Type de source : CIDR
  • CIDR source : IPv4 : CIDR IPv4 CIDR de votre VCN, IPv6 : CIDR IPv6 de votre VCN
  • Protocole IP : ICMP
  • Type : Tout
  • Code : Tout
Règle de trafic sortant générale 1 : Autorise tout le trafic sortant
  • Sans état : Non (toutes les règles doivent être avec état)
  • Type de destination : CIDR
  • CIDR de destination : 0.0.0.0/0 (IPv4), : :/0 (IPv6)
  • Protocole IP : Tout

Si le client active l'avis des événements de machine virtuelle invitée de plan de données, la règle de trafic sortant 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.

Note

  • Pour les systèmes X8M, Oracle recommande que tous les ports du sous-réseau client soient ouverts au trafic entrant et sortant. Il s'agit d'une exigence pour ajouter des serveurs de base de données supplémentaires au système.
  • Les règles de trafic entrant de client 1 et 2 ne couvrent que les connexions lancées à partir du sous-réseau client. Si vous avez un client qui réside en dehors du réseau VCN, Oracle recommande de configurer deux règles similaires supplémentaires, dont l'adresse CIDR source est réglée à l'adresse IP publique du client.
  • Les règles de trafic entrant de client 3 et 4 et les règles de trafic sortant de 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. Si la connectivité TCP échoue pour tous les noeuds, la ressource de grappe de machines virtuelles en nuage Exadata ou le système de base de données ne peut pas effectuer le provisionnement.

Rubrique parent : Règles de sécurité pour le service Oracle Exadata Database sur une infrastructure dédiée

Règle de trafic entrant de client 1 : Autorise le trafic ONS et FAN à partir du sous-réseau client

La première règle est recommandée et permet aux services d'avis Oracle (ONS) de communiquer sur les événements d'avis rapide des applications (FAN).

  • Sans état : Non (toutes les règles doivent être avec état)
  • Type de source : CIDR
  • CIDR source : IPv4 : CIDR IPv4 CIDR du sous-réseau client, IPv6 : CIDR IPv6 du sous-réseau client
  • Protocole IP : TCP
  • Intervalle de ports sources : Tous
  • Intervalle de ports de destination : 6200
  • Description : Description facultative de la règle.
Règle de trafic entrant de client 2 : Autorise le trafic SQL*NET à partir du sous-réseau client

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

  • Si vous devez activer les connexions client à la base de données
  • Si vous envisagez d'utiliser Oracle Data Guard
  • Sans état : Non (toutes les règles doivent être avec état)
  • Type de source : CIDR
  • CIDR source : IPv4 : CIDR IPv4 CIDR du sous-réseau client, IPv6 : CIDR IPv6 du sous-réseau client
  • Protocole IP : TCP
  • Intervalle de ports sources : Tous
  • Intervalle de ports de destination : 1521
  • Description : Description facultative de la règle.
Règle de trafic sortant de client 1 : Autorise tout le trafic TCP dans le sous-réseau du client

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

  • Sans état : Non (toutes les règles doivent être avec état)
  • Type de destination : CIDR
  • CIDR de destination : 0.0.0.0/0 (IPv4), : :/0 (IPv6)
  • Protocole IP : TCP
  • Intervalle de ports sources : Tous
  • Intervalle de ports de destination : 22
  • Description : Description facultative de la règle.
Règle de trafic sortant de client 2 : Autorise tout le trafic sortant (permet les connexions aux référentiels Oracle YUM)

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

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

  • Sans état : Non (toutes les règles doivent être avec état)
  • 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

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 le service de stockage d'objets au moyen de la passerelle de service (et au besoin, les référentiels d'Oracle YUM si le réseau client n'a pas accès à ceux-ci).

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

Règle de trafic sortant de sauvegarde : Permet l'accès au service de stockage d'objets
  • Sans état : Non (toutes les règles doivent être avec état)
  • Type de destination : Service

  • Service de destination :

    • Étiquette CIDR du service appelée OCI <region> Stockage d'objets
    • Si le réseau client n'a pas accès aux référentiels Oracle YUM, utilisez l'étiquette CIDR du service appelée Tous les services de <region> dans Oracle Services Network
  • Protocole IP : TCP
  • Intervalle de ports sources : Tous
  • Intervalle de ports de destination : 443 (HTTPS)
  • Description : Description facultative de la règle.

Règles requises pour le service d'événements

L'instance de calcul doit avoir une adresse IP publique ou une passerelle de service pour pouvoir envoyer des mesures liées aux instances de calcul au service d'événements.

Les règles de trafic sortant par défaut sont suffisantes pour permettre à l'instance de calcul d'envoyer des mesures liées aux instances de calcul au service d'événements.

Si l'instance n'a pas d'adresse IP publique, configurez une passerelle de service sur le réseau en nuage virtuel (VCN). La passerelle de service permet à l'instance d'envoyer des mesures liées aux instances de calcul au service d'événements sans que le trafic passe par Internet. Ci-dessous se trouvent des notes spéciales afin de configurer la passerelle de service pour accéder au service d'événements :

  • Lors de la création de la passerelle de service, activez l'option Tous les services de <region> dans Oracle Services Network. Elle comprend le service d'événements.

  • 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 réglé à Passerelle de service et le service de destination à Tous les services de <region> dans Oracle Services Network.

    Pour des instructions détaillées, voir Accès aux services Oracle : Passerelle de service.

Règles requises pour le service de surveillance

L'instance de calcul doit avoir une adresse IP publique ou une passerelle de service pour pouvoir envoyer des mesures liées aux instances de calcul au service de surveillance.

Les règles de trafic sortant par défaut sont suffisantes pour permettre à l'instance de calcul d'envoyer des mesures liées aux instances de calcul au service de surveillance.

Si l'instance n'a pas d'adresse IP publique, configurez une passerelle de service sur le réseau en nuage virtuel (VCN). La passerelle de service permet à l'instance d'envoyer des mesures liées aux instances de calcul au service de surveillance sans que le trafic passe par Internet. Ci-dessous se trouvent des notes spéciales permettant de configurer la passerelle de service pour accéder au service de surveillance :

  • Lors de la création de la passerelle de service, activez l'option Tous les services de <region> dans Oracle Services Network. Elle comprend le service de surveillance.

  • 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 réglé à Passerelle de service et le service de destination à Tous les services de <region> dans Oracle Services Network.

    Pour des instructions détaillées, voir Accès aux services Oracle : Passerelle de service.

Méthodes de mise en oeuvre des règles de sécurité

Voyez comment mettre en oeuvre des règles de sécurité dans votre VCN à l'aide du service de réseau.

Le service de réseau offre deux façons pour mettre en oeuvre les règles de sécurité à l'intérieur de votre réseau VCN :

Pour une comparaison des deux méthodes, voir Comparaison des listes de sécurité et des groupes de sécurité de réseau.

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

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

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

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

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

Vous pourriez plutôt créer un groupe de sécurité de réseau distinct pour les règles générales. Ensuite, lorsque l'administrateur de base de données choisit les groupes de sécurité de réseau à utiliser pour le réseau client, assurez-vous qu'il sélectionne le groupe de sécurité de réseau général et celui du réseau client. De même, pour le réseau de sauvegarde, veillez à ce qu'il sélectionne à la fois le groupe de sécurité de réseau général et celui de sauvegarde.

Si vous utilisez des listes de sécurité

Voici la marche à suivre pour utiliser des listes de sécurité :

Voici la marche à suivre pour utiliser des listes de sécurité :

  1. Configurez le sous-réseau client pour 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 indiquées dans Règles requises spécifiquement pour le réseau client.

    2. Associez les listes de sécurité suivantes aux services du sous-réseau client :

      • La liste de sécurité par défaut du VCN avec toutes ses règles par défaut. Elle est automatiquement associée au VCN. 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.
      • La nouvelle liste de sécurité personnalisée que vous avez créée pour le sous-réseau client.

  2. Configurez le sous-réseau de sauvegarde pour 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 indiqué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 :

      • La liste de sécurité par défaut du VCN avec toutes ses règles par défaut. Elle est automatiquement associée au VCN. 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.
      • La nouvelle liste de sécurité personnalisée que vous avez créée pour le sous-réseau de sauvegarde.

Ensuite, lorsque l'administrateur de base de données crée l'instance du service Exadata Cloud, il doit choisir plusieurs composants de 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 pour les noeuds créés dans ces sous-réseaux.

AVERTISSEMENT :

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

  • Sans état : Non (toutes les règles doivent être avec état)
  • Type de destination : CIDR
  • CIDR de destination : 0.0.0.0/0
  • Protocole IP : Tout

Exigences relatives au réseau pour Oracle Database Autonomous Recovery Service

Oracle Database Autonomous Recovery Service nécessite un sous-réseau de service de récupération enregistré dédié aux opérations de sauvegarde et de récupération dans votre réseau en nuage virtuel (VCN).

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

Rubriques connexes

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

Créer une passerelle de service vers le stockage d'objets

Dans la console OCI, créez une passerelle de service vers le service de stockage d'objets. 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 Service de réseau, puis sur Réseaux en nuage virtuels.
  2. Sélectionnez le VCN où se trouvent les services de base de données à sauvegarder.
  3. Dans la page Détails du réseau en nuage virtuel qui s'affiche, 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 n'a pas besoin d'être unique. Évitez d'entrer des informations confidentielles.
    2. Compartiment : compartiment où vous voulez créer la passerelle de service, s'il est différent de votre compartiment de travail actuel.
    3. Services : Sélectionnez l'étiquette CIDR du service, All <region> Services in Oracle Services Network, dans la liste déroulante.
    4. Marqueurs : (option avancée) Si vous êtes autorisé à créer une ressource, vous êtes également autorisé à appliquer des marqueurs à structure libre à cette ressource. Pour appliquer un marqueur défini, vous devez être autorisé à utiliser l'espace de noms de marqueur. Pour plus d'informations sur le marquage, voir Marqueurs de ressource. Si vous ne savez pas si vous devez appliquer des marqueurs, ignorez cette option (vous pourrez appliquer des marqueurs plus tard) 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 de VCN spécifique à cette passerelle. Si vous assignez une table de routage, par la suite, la passerelle doit toujours être associée à une table. Vous pouvez modifier les règles figurant dans la table de routage courante ou les remplacer par une autre.

  7. Cliquez sur le nom de la table de routage utilisée par le sous-réseau pour le service de récupération.

  8. Dans la page Détails de la table de routage qui s'affiche, cliquez sur Ajouter des règles de routage dans la section Règles de routage.

    Lorsque vous configurez une passerelle de service pour une étiquette CIDR de service particulière, vous devez également créer une règle de routage qui désigne l'étiquette comme destination et la passerelle de service comme cible. Vous procédez de cette façon pour chaque sous-réseau qui doit accéder à la passerelle.

  9. Dans la boîte de dialogue Ajouter des règles de routage qui s'affiche, entrez les détails suivants :
    1. Type de cible : passerelle de service.
    2. Service de destination : Étiquette CIDR de service activée 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.