En savoir plus sur la conception réseau

Les composants d'infrastructure réseau OCI, tels que les réseaux cloud virtuels, les sous-réseaux et les passerelles, créés sans planification appropriée à l'aide des paramètres par défaut peuvent entraîner des problèmes difficiles à résoudre après le déploiement. Une conception de réseau bien planifiée permet de mettre en place une implémentation réussie et facilite l'utilisation par votre équipe et votre organisation.

Réalisez votre conception réseau tôt

La conception complète de votre réseau avant le déploiement vous permet de détecter les problèmes plus tôt et d'éliminer les obstacles à la réussite du déploiement. Bien qu'il soit possible de modifier certains éléments de conception de réseau OCI ultérieurement, cela peut nécessiter un effort important et peut perturber temporairement le flux métier.

Oracle recommande ce qui suit pour la conception de votre réseau OCI :

1. Planifiez le temps approprié et allouez suffisamment de ressources dans votre plan de projet pour concevoir correctement votre réseau OCI.
2. Incluez au minimum la disposition, la topologie, le dimensionnement des réseaux cloud virtuels et des sous-réseaux, le service de noms de domaine (DNS) et toute connectivité réseau externe à des fournisseurs de services cloud locaux ou autres.
3. Envisagez de travailler avec votre équipe de compte Oracle pour voir si Oracle peut fournir des spécialistes du réseau OCI pour vous aider.

Voici un exemple de diagramme de conception réseau.

Description de l'illustration vcn-network-design-example.png

Conseil :

Recherchez des architectures de référence pertinentes pour votre déploiement spécifique à utiliser comme point de départ. Par exemple, Oracle dispose de nombreuses architectures de référence pour les déploiements Oracle OCI courants tels qu'Oracle E-Business Suite, Siebel et ExaCS sur Oracle Architecture Center.

Envisager une conception Hub-and-Spoke VCN

La meilleure pratique et la recommandation d'Oracle pour la plupart des déploiements OCI consiste à utiliser une conception VCN multiple dans une topologie hub-and-spoke utilisant le DRG pour la connectivité.

Voici les avantages d'une conception en étoile à plusieurs canaux VCN à l'aide du DRG :

• Isoler et segmenter différents environnements.
• Fournissez des services communs au sein du VCN hub que tous les réseaux cloud virtuels spoke peuvent partager, tels que le serveur de journal, le DNS et le partage de fichiers.
• Adapter votre réseau facilement car le DRG vous permet de connecter jusqu'à 300 réseaux cloud virtuels. Une fois que vous disposez d'une conception VCN hub-and-spoke, il est facile d'ajouter des réseaux cloud virtuels supplémentaires.
• Placez des appliances de sécurité réseau telles que des pare-feu dans le VCN hub pour inspecter le trafic destiné aux réseaux cloud virtuels spoke ou provenant de ces réseaux.

Le schéma suivant illustre l'utilisation d'une architecture réseau hub-and-spoke :

Description de l'illustration hub-and-spoke-topology.png

Oracle fournit les conseils suivants :

• Déterminez comment et où vous souhaitez segmenter différents environnements réseau et envisagez de les placer dans son propre VCN. Voici des exemples de clients courants pour l'utilisation de réseaux cloud virtuels distincts pour les environnements :
  • Environnements de production et non-production
  • Clients internes et externes
• Si vous disposez d'un déploiement OCI très simple ou de petite taille, tel qu'une preuve de concept (POC), et que vous n'avez besoin d'aucun des avantages abordés ici, l'utilisation d'un seul VCN est une bonne approche. Même avec un seul VCN, vous pouvez toujours placer un environnement dans un autre VCN à l'avenir pour tirer parti de ces recommandations.

Utiliser les conventions de dénomination OCI standard

Lors du provisionnement des ressources réseau nécessaires dans OCI, telles que les réseaux cloud virtuels, les sous-réseaux, les listes de sécurité et les passerelles de routage dynamique, vous êtes invité à saisir un nom de ressource. L'utilisation d'une convention de dénomination standard pour vos ressources OCI vous aide, ainsi que d'autres utilisateurs OCI, à comprendre l'objectif et l'emplacement des ressources, et indique également comment une ressource se différencie des autres.

Certains de ces noms de ressource peuvent être modifiés ultérieurement, mais pas certains, tels que les libellés DNS. D'autres noms tels que VCN doivent être modifiés à l'aide de l'interface de ligne de commande (CLI).

Oracle fournit les conseils suivants :

1. Utilisez un acronyme descriptif quelque part dans le nom pour décrire l'objectif d'une ressource. Exemple :
   • vcn quelque part dans le nom du VCN (nom du VCN : vcn-prod-ashburn)
   • drg quelque part dans le nom DRG (nom DRG : drg-ashburn)
   • sl quelque part dans le nom de votre liste de sécurité (nom de la liste de sécurité : web-sn-sl)
2. Assurez-vous que la convention de dénomination des ressources réseau OCI fait partie de la convention de dénomination globale des ressources OCI.
3. Envisagez d'utiliser des balises pour ajouter des informations de métadonnées aux ressources.

Concevoir un DNS hybride avec OCI Private DNS

Le comportement par défaut d'OCI est limité à l'exécution de la résolution DNS interne au VCN en utilisant oraclevcn.com comme domaine par défaut. Cela peut entraîner des problèmes de connectivité ultérieurement, car vous ne pouvez pas résoudre les noms DNS des ressources d'autres réseaux cloud virtuels ou d'environnements sur site.

Le service DNS privé OCI permet de résoudre facilement le DNS entre OCI et l'infrastructure sur site :

• Créer et tenir à jour des domaines et des enregistrements DNS personnalisés dans vos réseaux cloud virtuels (tels que oci.customer.com).
• Intégrer la résolution DNS entre les réseaux cloud virtuels, avec le DNS on-premise et d'autres environnements tels que les fournisseurs de services cloud ou les services de service cloud partenaires de confiance.

Oracle fournit les conseils suivants :

• Incluez DNS dans le cadre de votre première conception réseau et impliquez vos administrateurs DNS.
• Prenez en compte tous les environnements dans lesquels vous souhaitez une résolution de nom DNS transparente (vers ou depuis des environnements sur site, des réseaux cloud virtuels OCI, d'autres fournisseurs de services cloud, etc.) et utilisez le DNS privé OCI pour activer une solution DNS hybride.
• Considérez les avertissements plus tôt et déterminez la direction que vous souhaitez suivre. Décidez si vous voulez utiliser le nom de domaine oraclevcn.com par défaut ou un nom de domaine personnalisé.

Le diagramme suivant présente un exemple d'architecture avec des noms de domaine personnalisés utilisant un résolveur DNS privé pour la résolution de ressources internes locales avec des noms de domaine personnalisés :

Description de l'illustration architecture-deploy-private-dns.png

Conseil :

Lorsque vous utilisez un nom de domaine OCI personnalisé, la gestion des zones et des enregistrements personnalisés est manuelle. La valeur par défaut oraclevcn.com est automatique.

Décider des types de sous-réseau avant le provisionnement

Les CIDR VCN doivent être divisés en un ou plusieurs sous-réseaux pour organiser les ressources. Les sous-réseaux peuvent être régionaux ou propres au domaine de disponibilité. Ils peuvent également être publics ou privés.

Les décisions concernant les sous-réseaux régionaux par rapport aux sous-réseaux propres à un domaine de disponibilité, et les sous-réseaux publics par rapport aux sous-réseaux privés ne peuvent pas être modifiées ultérieurement. Assurez-vous qu'elles sont correctes lorsque vous les provisionnez initialement pour minimiser les perturbations et la complexité à un stade ultérieur.

Oracle fournit les conseils suivants :

• Déterminez si vous avez besoin de sous-réseaux publics ou privés avant de les créer. Tenez compte des flux de trafic potentiels et de l'origine ou de la destination du trafic.
• Placez les ressources nécessitant une connectivité Internet entrante dans des sous-réseaux publics et toutes les autres ressources dans des sous-réseaux privés.
• Provisionnez des sous-réseaux régionaux, sauf si vous avez une exigence spécifique nécessitant l'utilisation de sous-réseaux propres à un domaine de disponibilité.

Conseil :

Pour apporter des modifications ultérieurement, vous devez mettre fin aux sous-réseaux, puis les reprovisionner. Vous devez également mettre fin aux ressources déployées dans les sous-réseaux, puis reprovisionner les ressources dans les nouveaux sous-réseaux.

Conception et taille des sous-réseaux

Concevez et dimensionnez vos sous-réseaux pour répondre aux exigences actuelles et futures. Le dimensionnement approprié des réseaux cloud virtuels et des sous-réseaux au cours de la conception vous aidera à :

• Préparer la croissance et l'expansion futures
• Simplifiez votre allocation IP en utilisant un espace d'adressage IP contigu et résumable

Oracle fournit les conseils suivants :

• Avant de créer un VCN, déterminez le nombre de blocs CIDR requis et la taille de chaque bloc en fonction du nombre de ressources et de sous-réseaux que vous prévoyez de déployer dans le VCN.
• Veillez à prévoir une certaine croissance future au sein des sous-réseaux et des réseaux cloud virtuels.
• De préférence, penchez-vous vers la création d'un CIDR plus grand que trop petit.
• Vous pouvez ajouter jusqu'à cinq CIDR à un VCN, mais l'ajout ultérieur pour prendre en charge la croissance peut entraîner des CIDR non contigus en fonction de l'allocation de votre adresse IP.
  • Par exemple, vous avez alloué 10.0.0.0/24 à un VCN pour commencer à tester une charge globale. Après un test réussi, si vous souhaitez étendre la charge globale en davantage de machines virtuelles, elle a besoin de davantage d'adresses IP et de sous-réseaux. Cependant, le bloc IP suivant 10.0.1.0/24 a été alloué dans votre outil d'adresse IP à une autre fin. Par conséquent, vous êtes obligé d'ajouter un CIDR non contigu au VCN.
• Si possible, utilisez des blocs CIDR qui se trouvent dans l'espace d'adressage IP privé RFC 1918 standard.
• Evitez d'utiliser l'espace d'adressage IP 169.254.0.0/16. De nombreux fournisseurs, y compris Oracle, utilisent ce même espace IP dans leur réseau et cela peut causer des problèmes.
• Sélectionnez des blocs CIDR uniques qui ne chevauchent aucun autre réseau (dans OCI, vos centres de données sur site ou un autre fournisseur de services cloud).
• Lorsque vous concevez les sous-réseaux, tenez compte de vos exigences en matière de flux de trafic et de sécurité. Attachez toutes les ressources d'un niveau ou d'un rôle spécifique au même sous-réseau.

Utiliser des tables de routage personnalisées et des listes de sécurité pour chaque sous-réseau

Lors du provisionnement des sous-réseaux, vous serez invité à choisir une table de routage VCN et une liste de sécurité à utiliser avec chaque sous-réseau.

OCI fournit une table de routage par défaut et une liste de sécurité par défaut qui, si elle est utilisée, est partagée avec tous les sous-réseaux qui leur sont associés. L'utilisation des options par défaut est utile pour un déploiement simple ou pour vous lancer, mais pas pour une conception de production comprenant plusieurs sous-réseaux. L'utilisation de tables de routage VCN et de listes de sécurité spécifiques à chaque sous-réseau vous permet de maintenir un routage granulaire et un contrôle de sécurité sur les sous-réseaux individuels au lieu de les faire partager ces ressources.

Exemple :

• Vous pouvez souhaiter qu'un sous-réseau privé dispose d'un routage par défaut vers une passerelle NAT et qu'un sous-réseau public dispose d'un routage par défaut vers une passerelle Internet, ce qui nécessiterait des tables de routage VCN distinctes.
• Vous pouvez autoriser un flux de trafic spécifique vers un sous-réseau, mais pas vers un autre, ce qui nécessite d'avoir des listes de sécurité distinctes

Oracle fournit les conseils suivants :

• Créer et associer une table de routage VCN unique pour chaque sous-réseau
• Créer et associer une liste de sécurité unique pour chaque sous-réseau

Conseil :

Créez et associez ces tables de routage VCN uniques et ces listes de sécurité lorsque vous provisionnez les sous-réseaux, car il sera plus difficile de les modifier ultérieurement.