Planifier votre déploiement

Oracle Database@Azure utilise le matériel de grappe Oracle Exadata, les réseaux RDMA, ainsi que les plus récents logiciels et Oracle Database, tous directement installés dans le centre de données Microsoft Azure.

Cette architecture vous permet d'utiliser le même service Oracle Database qui s'exécute de manière native sur Oracle Cloud Infrastructure, mais sur Microsoft Azure.

Les mises en oeuvre suivantes sont décrites dans cette section :

• Oracle Autonomous Database pour Oracle Database@Azure
• Oracle Database@Azure Oracle Exadata Database Service

Conception de réseau pour Oracle Database@Azure Autonomous Database

Cette architecture présente Oracle Autonomous Database déployé sur Microsoft Azure.

Autonomous Database est présenté en tant que carte d'interface réseau virtuelle (VNIC) dans un sous-réseau Azure délégué à Oracle.Database/networkAttachments. Lors du provisionnement du service, un réseau en nuage virtuel (VCN) avec le même intervalle de blocs CIDR que le sous-réseau délégué est créé. Le VCN est une construction régionale qui s'étend du site enfant à la région Oracle Cloud Infrastructure (OCI) la plus proche. Le service Stockage d'objets pour OCI est utilisé pour sauvegarder la base de données.

Description de l'illustration network-adb-azure.png

réseau-adb-azure-oracle.zip

Pour déployer Oracle Autonomous Database sur Microsoft Azure, utilisez les étapes de haut niveau suivantes :

1. Planifiez le bloc CIDR (routage interdomaine sans classe) pour le sous-réseau délégué au client.

   Réservez le bloc CIDR pour le sous-réseau où Autonomous Database sera déployé. Ce bloc CIDR ne doit pas chevaucher ceux déjà utilisés sur place ou dans le déploiement Azure courant. De plus :

   • 13 adresses IP sont réservées aux services de réseau dans le sous-réseau client, quel que soit le nombre d'instances Autonomous Database présentes dans le sous-réseau client. Les 13 adresses sont les 4 premières, les 9e à 16e et la dernière adresse IP.
   • La taille minimale du bloc CIDR est /27.
   • Les adresses IP 100.106.0.0/16 et 100.107.0.0/16 sont réservées à la connectivité interne et ne peuvent pas être affectées au sous-réseau client.

   Prévoyez toujours une expansion future de l'environnement et envisagez d'allouer un bloc CIDR plus grand que celui dont vous avez besoin. Une fois le service provisionné, le bloc CIDR ne peut pas être redimensionné.

2. Créez le sous-réseau délégué.

   Dans le réseau virtuel qui hébergera Autonomous Database, créez un sous-réseau et déléguez-le àOracle.Database/networkAttachments. Dans le sous-réseau délégué, seules les charges de travail Oracle Database@Azure sont autorisées et vous ne pouvez pas provisionner d'autres services Azure ou de calcul dans ce sous-réseau.

   Lorsque vous provisionnez Oracle Database@Azure, vous devez spécifier le réseau virtuel et le sous-réseau délégué.

3. Comprendre le DNS (service de noms de domaine).

   Autonomous Database aura un nom de domaine complet du domaine oraclecloud.com. Cette zone est une zone DNS privée qui réside dans OCI. Les enregistrements de cette zone sont répliqués dans une zone DNS privée correspondante dans Azure. Les applications d'Azure qui se connectent à Autonomous Database résolvent le nom de domaine complet à l'aide de la zone DNS privée d'Azure.

   Pour vérifier le nom de domaine complet, naviguez d'abord jusqu'à la location OCI et vérifiez la zone DNS, puis vérifiez le DNS dans la console Azure :

   1. Dans la console Azure, naviguez jusqu'à la console de service Oracle Autonomous Database et notez l'adresse IP privée de la base de données indiquée sous Réseau. Cliquez sur Aller à OCI.
   2. Connectez-vous à la location OCI, consultez la page de détails pour Autonomous Database et notez le VCN où la base de données est déployée et le groupe de sécurité de réseau utilisé pour approuver le trafic réseau vers Autonomous Database.
   3. Cliquez sur le lien Réseau en nuage virtuel.
   4. Cliquez sur le lien Résolveur DNS.
   5. Cliquez sur le lien Vue privée par défaut.
   6. Localisez la zone DNS utilisée par Autonomous Database et vérifiez l'adresse IP de l'enregistrement A. Notez le nom de domaine.
   7. Dans la console Azure, naviguez jusqu'au service DNS Azure, localisez la zone DNS privée que vous avez identifiée dans la console OCI, puis cliquez sur Liens de réseau virtuel. Notez qu'il est identique au nom de domaine de la console OCI
4. Approuvez le trafic réseau vers Autonomous Database.
   1. Connectez-vous à la location OCI, consultez la page des détails pour Autonomous Database, puis cliquez sur le lien Groupes de sécurité de réseau.
   2. Assurez-vous que les applications se connectant à Autonomous Database ont l'approbation requise (soit tcp 1521, soit tcp 1522).

Conception de réseau pour Oracle Exadata Database Service pour Oracle Database@Azure

Cette architecture présente Oracle Exadata Database Service déployé sur Microsoft Azure.

Le service est présenté sous la forme d'une série de cartes d'interface réseau virtuelles (vNIC) dans un sous-réseau Azure délégué à Oracle.Database/networkAttachments. Lors du provisionnement du service, un réseau en nuage virtuel (VCN) avec le même intervalle de blocs CIDR que le sous-réseau délégué est créé. Le VCN est une construction régionale qui s'étend du site enfant à la région OCI la plus proche.

Bien qu'Oracle Autonomous Database soit un service régional et qu'il puisse être lancé automatiquement sur différentes zones, Oracle Exadata Database Service présente une affinité pour une zone spécifique.

Description de l'illustration network-exadata-azure.png

network-exadata-azure-oracle.zip

Pour déployer Oracle Exadata Database Service sur Microsoft Azure, utilisez les étapes de haut niveau suivantes :

1. Planifiez le bloc CIDR pour le sous-réseau délégué au client.

   Oracle Exadata Database Service nécessite deux intervalles de blocs CIDR : un bloc CIDR pour le sous-réseau client utilisé pour provisionner un sous-réseau délégué dans Azure et un autre bloc CIDR facultatif pour le sous-réseau de sauvegarde. Les blocs CIDR ne doivent pas chevaucher ceux déjà utilisés sur place ou dans le déploiement Azure courant.

   Le sous-réseau client a les exigences suivantes :

   • Chaque machine virtuelle nécessite 4 adresses IP. Les grappes de machines virtuelles ont un minimum de 2 machines virtuelles. Par conséquent, une grappe de machines virtuelles avec 2 machines virtuelles nécessite 8 adresses IP dans le sous-réseau client. Chaque machine virtuelle supplémentaire ajoutée à une grappe de machines virtuelles augmente de 4 adresses IP le nombre d'adresses IP nécessaires dans le sous-réseau client.
   • Chaque grappe de machines virtuelles nécessite 3 adresses IP pour les noms SCAN (Single Client Access Names), quel que soit le nombre de machines virtuelles présentes dans la grappe de machines virtuelles.
   • 13 adresses IP sont réservées aux services de réseau dans le sous-réseau client, quel que soit le nombre d'instances Autonomous Database présentes dans le sous-réseau client. Les 13 adresses sont les 4 premières, les 9e à 16e et la dernière adresse IP.
   • La taille minimale du bloc CIDR est /27.
   • Les adresses IP 100.106.0.0/16 et 100.107.0.0/16 sont réservées à la connectivité interne et ne peuvent pas être affectées au sous-réseau client.
   • Un sous-réseau client peut héberger des grappes de machines virtuelles de différentes infrastructures Exadata si elles proviennent de la même zone de disponibilité.

   Le sous-réseau de sauvegarde a les exigences suivantes :

   • Chaque machine virtuelle nécessite 3 adresses IP. Les grappes de machines virtuelles ont un minimum de 2 machines virtuelles. Par conséquent, une grappe de machines virtuelles avec 2 machines virtuelles nécessite 6 adresses IP dans le sous-réseau de sauvegarde. Chaque machine virtuelle supplémentaire ajoutée à une grappe de machines virtuelles augmente de 3 adresses IP le nombre d'adresses IP nécessaires dans le sous-réseau de sauvegarde.
   • Les services de réseau nécessitent 3 adresses IP pour le sous-réseau de sauvegarde, quel que soit le nombre de grappes de machines virtuelles présentes dans le sous-réseau de sauvegarde.
   • La taille minimale du bloc CIDR est /28.

   Prévoyez toujours une expansion future de l'environnement et envisagez d'allouer un bloc CIDR plus grand que celui dont vous avez besoin. Une fois le service provisionné, le bloc CIDR ne peut pas être redimensionné.

2. Créez le sous-réseau délégué.

   Dans le réseau virtuel qui hébergera la grappe de machines virtuelles Exadata, créez un sous-réseau et déléguez-le à Oracle.Database/networkAttachments. Dans le sous-réseau délégué, seules les charges de travail Oracle Database@Azure sont autorisées et vous ne pouvez pas provisionner d'autres services Azure ou de calcul dans ce sous-réseau.

   Lorsque vous provisionnez Oracle Exadata Database Service, vous devez spécifier le sous-réseau client délégué et le sous-réseau de sauvegarde.

   Si aucun bloc CIDR n'est indiqué pour le sous-réseau de sauvegarde, l'intervalle 192.168.252.0/22 par défaut est utilisé. Le sous-réseau de sauvegarde n'est pas utilisé dans Azure et le bloc CIDR ne fait pas partie du bloc CIDR du réseau virtuel. Si vous envisagez un scénario de récupération après sinistre avec plusieurs déploiements Exadata (zone inter-disponibilité ou inter-région), le bloc CIDR du sous-réseau de sauvegarde doit être fourni et ne doit pas chevaucher tout autre bloc CIDR utilisé.

   Après avoir créé la grappe de machines virtuelles, configurez votre base de données à l'aide de la documentation standard du produit. Voir Explorer davantage.

3. Comprendre le DNS.

   Il existe trois scénarios possibles pour la configuration DNS lors du provisionnement du service Oracle Exadata Database Service :

   • Gestion totale

     Il s'agit de l'option par défaut où Oracle gère la configuration DNS lors du processus de provisionnement. Oracle crée des enregistrements A pour la grappe de machines virtuelles et SCAN utilisera le nom de domaine complet *.oraclevcn.com. Cette intégration est essentielle car le plan de contrôle Exadata fonctionne sur OCI, qui utilise le service DNS privé d'OCI pour le provisionnement. En outre, le processus de provisionnement synchronise automatiquement ces enregistrements A avec le DNS privé d'Azure. Par conséquent, si vous utilisez le DNS privé d'Azure, la configuration DNS est entièrement automatisée et transparente dès sa création.

     Après le provisionnement des entrées DNS dans le DNS privé OCI et Azure, le nom de domaine complet *.oraclevcn.com

   • Nom de domaine complet personnalisé

     Avec le DNS géré, le nom de domaine complet généré suit le format *.oraclevcn.com, qui peut ne pas être idéal pour certains clients, en particulier ceux qui l'utilisent déjà dans OCI et ne peuvent pas le mettre en oeuvre dans Azure. Au lieu de cela, Oracle permet aux clients de spécifier un nom de domaine complet personnalisé lors du processus de provisionnement. Toutefois, cette approche n'offre pas la synchronisation unidirectionnelle entre OCI et Azure fournie par le DNS géré. Par conséquent, les clients doivent répliquer manuellement les enregistrements A de leur zone personnalisée dans le DNS privé OCI vers le DNS privé Azure.

     Comme les grappes de machines virtuelles utilisent le DNS privé OCI pour la résolution, les utilisateurs doivent créer un nom de domaine complet personnalisé avant de provisionner la grappe de machines virtuelles. Pour ce faire, naviguez jusqu'au résolveur DNS attaché au VCN et créez une nouvelle zone privée avec une vue privée et associez ce nouveau résolveur privé au résolveur DNS.

     Une fois cette étape terminée, l'interface utilisateur Azure affiche automatiquement la zone personnalisée nouvellement créée lorsque l'option de nom de domaine complet personnalisé est sélectionnée lors du processus de création de grappe de machines virtuelles.

     Après le provisionnement, les ressources Azure peuvent accéder aux entrées DNS de plusieurs façons. La méthode la plus simple consiste à répliquer les entrées de zone privée OCI dans Azure Private DNS. Vous pouvez également créer un point d'extrémité d'écoute DNS OCI pour transmettre les demandes au DNS privé OCI.

   • DNS personnalisé

     Vous pouvez également configurer un DNS personnalisé. Par exemple, si vous voulez utiliser un DNS de tierce partie, tel qu'Infoblox, avec Oracle Exadata Database Service, ils peuvent suivre le même processus qu'avec un nom de domaine complet personnalisé. Par la suite, vous devez dupliquer les enregistrements DNS pertinents dans le DNS personnalisé. Cela garantit que les applications et les utilisateurs peuvent résoudre l'URL SCAN à l'aide du DNS personnalisé.