Planification de votre déploiement

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

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

Les implémentations suivantes sont décrites dans cette section :

  • Oracle Database@Azure Oracle Autonomous Database
  • 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é sous la forme d'une carte d'interface réseau virtuelle dans un sous-réseau Azure délégué à Oracle.Database/networkAttachments. Lors du provisionnement du service, un réseau cloud virtuel (VCN) avec la même plage 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. OCI Object Storage est utilisé pour sauvegarder la base de données.


Description de l'image réseau-adb-azure.png
Description de l'illustration network-adb-azure.png

réseau-adb-azure-oracle.zip

Pour déployer Oracle Autonomous Database sur Microsoft Azure, procédez comme suit :

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

    Réservez le bloc CIDR pour le sous-réseau sur lequel Autonomous Database sera déployé. Ce bloc CIDR ne doit pas chevaucher ceux déjà utilisés sur site ou dans le déploiement Azure en cours. Mais aussi :

    • 13 adresses IP sont réservées aux services 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 9 à 16, et la dernière adresse IP.
    • La taille minimale de 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 allouées au sous-réseau client.

    Prévoyez toujours l'expansion future de l'environnement et envisagez d'allouer un bloc CIDR plus grand que celui nécessaire. 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 globales 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 indiquer le réseau virtuel et le sous-réseau délégué.

  3. Comprendre le DNS (Domain Name Service, service de nom de domaine).

    Autonomous Database aura un nom de domaine qualifié complet provenant 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 vers une zone DNS privée correspondante dans Azure. Les applications d'Azure qui se connectent à Autonomous Database résolvent le nom de domaine qualifié complet à l'aide de la zone DNS privée Azure.

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

    1. Dans la console Azure, accédez à la console de service Oracle Autonomous Database et notez l'adresse IP privée de base de données répertoriée sous Réseau. Cliquez sur Accéder à OCI.
    2. Connectez-vous à la location OCI, affichez la page de détails d'Autonomous Database, et notez le VCN où la base de données est déployée et le groupe de sécurité réseau utilisé pour approuver le trafic réseau vers Autonomous Database.
    3. Cliquez sur le lien Réseau cloud 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 du domaine.
    7. Dans la console Azure, accédez au service DNS Azure, localisez la zone DNS privée que vous avez identifiée dans la console OCI et 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, affichez la page de détails d'Autonomous Database, puis cliquez sur le lien Groupes de sécurité réseau.
    2. Assurez-vous que les applications se connectant à Autonomous Database disposent de l'approbation requise (tcp 1521 ou tcp 1522).

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

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 cloud virtuel (VCN) avec la même plage 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 puisse être lancé automatiquement dans diverses zones, Oracle Exadata Database Service a une affinité pour une zone spécifique.


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

network-exadata-azure-oracle.zip

Pour déployer Oracle Exadata Database Service sur Microsoft Azure, procédez comme suit :

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

    Oracle Exadata Database Service requiert deux plages 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 site ou dans le déploiement Azure en cours.

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

    • Chaque machine virtuelle (VM) requiert 4 adresses IP. Les clusters de machines virtuelles contiennent au moins 2 machines virtuelles. Par conséquent, un cluster de machines virtuelles avec 2 machines virtuelles requiert 8 adresses IP dans le sous-réseau client. Chaque machine virtuelle supplémentaire ajoutée à un cluster de machines virtuelles augmente le nombre d'adresses IP nécessaires dans le sous-réseau client de 4 adresses IP.
    • Chaque cluster de machines virtuelles requiert 3 adresses IP pour les noms SCAN (Single Client Access Names), quel que soit le nombre de machines virtuelles présentes dans le cluster de machines virtuelles.
    • 13 adresses IP sont réservées aux services 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 9 à 16, et la dernière adresse IP.
    • La taille minimale de 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 allouées au sous-réseau client.
    • Un sous-réseau client peut héberger des clusters de machines virtuelles à partir d'infrastructures Exadata différentes s'ils proviennent de la même zone de disponibilité.

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

    • Chaque machine virtuelle (VM) requiert 3 adresses IP. Les clusters de machines virtuelles contiennent au moins 2 machines virtuelles. Par conséquent, un cluster de machines virtuelles avec 2 machines virtuelles requiert 6 adresses IP dans le sous-réseau de sauvegarde. Chaque machine virtuelle supplémentaire ajoutée à un cluster de machines virtuelles augmente le nombre d'adresses IP nécessaires dans le sous-réseau de sauvegarde de 3 adresses IP.
    • Les services réseau nécessitent 3 adresses IP pour le sous-réseau de sauvegarde, quel que soit le nombre de clusters de machines virtuelles présents dans le sous-réseau de sauvegarde.
    • La taille minimale de bloc CIDR est /28.

    Prévoyez toujours l'expansion future de l'environnement et envisagez d'allouer un bloc CIDR plus grand que celui nécessaire. 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 le cluster 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 globales 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 indiquer le sous-réseau client délégué et le sous-réseau de sauvegarde.

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

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

  3. Comprendre le DNS.

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

    • Entièrement géré

      Il s'agit de l'option par défaut dans laquelle Oracle gère la configuration DNS pendant le processus de provisionnement. Oracle crée des enregistrements A pour le cluster de machines virtuelles. Le nom SCAN utilise le nom de domaine qualifié 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. De plus, 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 le départ.

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

    • Nom de domaine qualifié complet personnalisé

      Avec le DNS géré, le nom de domaine qualifié complet généré suit le format *.oraclevcn.com, ce qui peut ne pas être idéal pour certains clients, en particulier ceux qui l'utilisent déjà dans OCI et qui ne peuvent pas l'implémenter dans Azure. Sinon, Oracle permet aux clients d'indiquer un nom de domaine qualifié complet personnalisé lors du processus de provisionnement. Cependant, cette approche manque de 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 vers le DNS privé OCI vers le DNS privé Azure.

      Etant donné que les clusters de machines virtuelles utilisent le DNS privé OCI pour la résolution, les utilisateurs doivent créer un nom de domaine qualifié complet personnalisé avant de provisionner le cluster de machines virtuelles. Pour ce faire, accédez au résolveur DNS attaché au VCN et créez une nouvelle zone privée avec une vue privée et attachez ce nouveau résolveur privé au résolveur DNS.

      Une fois cette étape terminée, l'interface utilisateur Azure affiche automatiquement la nouvelle zone personnalisée lorsque l'option Nom de domaine qualifié complet personnalisé est sélectionnée lors du processus de création du cluster 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 le DNS privé Azure. Vous pouvez également créer une adresse d'écoute DNS OCI pour transférer les demandes vers le DNS privé OCI.

    • DNS personnalisé

      Vous pouvez également configurer un DNS personnalisé. Par exemple, si vous voulez utiliser un DNS tiers, tel qu'Infoblox, avec Oracle Exadata Database Service, ils peuvent suivre le même processus qu'avec un nom de domaine qualifié complet personnalisé. Ensuite, 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é.