Définir les exigences de charge de travail
Exigences de communication
Passerelles de communication OCI
Sélectionnez les passerelles de communication appropriées en fonction des exigences de votre charge de travail dans le tableau suivant :
| Fonction | Passerelle recommandée | Commentaires |
|---|---|---|
| Le trafic entrant et sortant d'OCI peut être lancé à partir d'OCI ou d'Internet | Passerelle Internet | Besoin d'un sous-réseau public et d'une ressource avec une adresse IP publique |
| Ressources dans l'Internet avec accès OCI en toute sécurité | Passerelle NAT | Seul le trafic lancé à partir du sous-réseau est autorisé au moyen de la passerelle NAT |
| Accès à Oracle Cloud Infrastructure Object Storage ou à d'autres services dans Oracle Service Network | Passerelle de service | Des exemples de services sont le service de gestion du système d'exploitation, Oracle Linux ou Yum Service. Voir la section Explorer pour obtenir la liste complète des services pris en charge dans OSN
|
| Connexion entre OCI et sur place et entre les réseaux en nuage virtuels | DRG | Un routeur virtuel connecte des réseaux en nuage virtuels et des emplacements sur place au moyen d'un point de connexion central et se connecte également entre des régions et différentes locations |
Connectivité inter-VCN
Oracle recommande d'utiliser des passerelles DRG pour la connectivité inter-VCN. La passerelle DRG fournit un chemin évolutif pour la connectivité, non seulement entre les réseaux en nuage virtuels, mais aussi depuis les environnements sur place et d'autres nuages. L'importation dynamique de routes réduit la complexité de la gestion. Pour des besoins de routage particuliers entre deux réseaux en nuage virtuels, utilisez une passerelle d'appairage local (LPG). Vous pouvez utiliser à la fois des passerelles DRG et des passerelles LPG en fonction de vos besoins.
Les trois exemples suivants de connectivité inter-VCN utilisent une passerelle LPG ou DRG :
Passerelle d'appairage local (LPG)
L'image suivante présente une région avec deux réseaux en nuage virtuels utilisant des passerelles LPG pour l'appairage local :
Les deux réseaux en nuage virtuels doivent se trouver dans la même région OCI et vous pouvez avoir jusqu'à 10 passerelles LPG par VCN.
Passerelle de routage dynamique (DRG)
Les passerelles de routage dynamique connectent les réseaux en nuage virtuels à l'intérieur ou entre des régions et permettent jusqu'à 300 attachements par passerelle de routage dynamique. Les passerelles DRG fournissent des options de routage simples, en plus des routes statiques. Les routes des réseaux attachés sont importées de manière dynamique dans des tables de routage DRG à l'aide de répartitions de route d'importation.
L'image suivante présente une région avec deux réseaux en nuage virtuels connectés par une passerelle DRG dans la même région :
L'image suivante présente une région avec deux réseaux en nuage virtuels utilisant la passerelle DRG avec deux réseaux en nuage virtuels connectés entre des régions distinctes :
Accéder à Oracle Services Network (OSN)
OSN est un réseau conceptuel dans OCI qui est réservé aux services Oracle.
L'architecture suivante présente un VCN accédant à OSN sans que le trafic passe par Internet au moyen d'une passerelle de service :
Tenez compte des options suivantes et décidez de la façon dont vous souhaitez acheminer votre trafic :
- Utilisez une passerelle de service pour acheminer le trafic privé vers OSN sans passer par Internet.
- Les services (comme le service de stockage d'objets) ont des adresses IP publiques qui peuvent être atteintes sur Internet. Utilisez des points d'extrémité privés pour conserver le trafic au sein du réseau OCI.
- Lors de l'ajout d'une route à OSN, décidez si vous voulez permettre au réseau d'utiliser tous les services OCI ou simplement le stockage d'objets OCI pour les sauvegardes de base de données.
- Envisagez les points d'extrémité privés pour un accès direct et privé à partir des réseaux en nuage virtuels ou des centres de données sur place. Par exemple, vous pouvez configurer le stockage d'objets OCI avec une adresse IP privée accessible à partir d'un VCN ou d'une région sur place.
Exigences en matière de connectivité hybride et multinuage
Connecter OCI aux réseaux sur place en fonction de vos besoins à l'aide de l'une des options de connectivité suivantes :
- OCI FastConnect utilise une connexion dédiée pour la bande passante et la latence fixes. Oracle recommande d'utiliser des connexions redondantes pour la résilience.
- Le RPV site à site pour OCI utilise Internet comme transporteur et peut également utiliser FastConnect. La bande passante, la latence et la disponibilité peuvent varier en fonction des circuits Internet publics. Oracle recommande d'utiliser des tunnels redondants.
Le diagramme suivant présente un exemple d'architecture de connexion d'un environnement sur place à OCI à l'aide d'un RPV site-à-site ou FastConnect :
Oracle recommande d'utiliser FastConnect pour les connexions principales avec RPV en tant que sauvegarde pour les charges de travail de production. FastConnect est disponible à des vitesses variables allant jusqu'à 400 Gbit/s, selon la région et les partenaires.
Pour configurer votre connectivité, procédez de la façon suivante :
- Configurez un circuit virtuel avec un appairage public pour un accès OSN uniquement.
- Utilisez l'appairage privé pour une connexion privée aux ressources des réseaux en nuage virtuels.
- Utilisez un RPV site à site (avec IPSec) pour le chiffrement du trafic au sein de l'appairage privé FastConnect.
Note :
Oracle recommande d'utiliser du matériel redondant pour toutes les connexions.Se connecter aux réseaux sur place à l'aide d'OCI FastConnect
Oracle recommande d'utiliser FastConnect avec RPV comme connexion principale pour les charges de travail de production. Utilisez un RPV site à site en tant que connexion de sauvegarde pour FastConnect. La connexion principale est donc FastConnect et la sauvegarde est un RPV. Les vitesses de connexion disponibles sont 1 Gbit/s, 10 ou 100 Gbit/s.
- Configurez un circuit virtuel avec un appairage public, si vous avez seulement besoin d'accéder à OSN.
- Utilisez un RPV site à site pour OCI, qui utilise IPSec pour le chiffrement du trafic en plus de l'appairage public FastConnect.
- Utilisez un appairage privé lorsque vous avez besoin d'une connexion privée aux ressources des réseaux en nuage virtuels OCI.
Note :
Oracle recommande d'utiliser deux fois l'équipement à des fins de redondance.Se connecter aux réseaux sur place à l'aide d'un RPV site à site OCI
Le diagramme suivant présente une architecture avec un équipement local d'abonné (CPE) redondant et une connexion OCI à l'aide d'un RPV site à site :
Les performances d'un RPV site à site peuvent varier en fonction du trafic Internet. Comme pour FastConnect, configurez un RPV site à site avec des tunnels redondants et, dans la mesure du possible, également avec des appareils CPE redondants. Oracle fournit deux points d'extrémité de RPV pour chaque connexion de RPV site à site.
Oracle Interconnect pour Microsoft Azure
Le diagramme suivant présente un exemple d'architecture d'une base de données Oracle dans une région OCI et l'application dans Azure :
La latence est importante pour une bonne expérience utilisateur avec de meilleurs temps de réponse. Oracle et Azure ont des points d'intégration à différents endroits dans le monde. Cela facilite l'intégration et réduit également la latence, ce qui permet d'avoir une solution qui s'étend entre les nuages à l'aide de FastConnect et d'Azure ExpressRoute.
Vous pouvez activer l'accès entre les nuages en configurant à partir du portail Azure, ExpressRoute et la console OCI, FastConnect. Vous n'avez qu'à configurer le circuit virtuel 1x car l'interconnexion Azure comporte une redondance intégrée en utilisant la diversité physique du matériel et de l'emplacement, lorsque cela est possible. Il n'y a aucun coût pour le trafic entre Azure et OCI (coût de trafic sortant) si vous utilisez une UDS locale et sélectionnez la vitesse de connexion minimale de 1 Gbit/s Azure ExpressRoute. Les interconnexions sont construites là où Azure et OCI sont situés à proximité les uns des autres pour permettre une faible latence entre les nuages.
Note :
Toutes les régions ne disposent pas de cette fonctionnalité. Utiliser un fournisseur de services réseau dans d'autres régions.Si vous recherchez une connexion à Microsoft Azure, voir Accès à Microsoft Azure.
Oracle Interconnect for Google Cloud
Le diagramme d'architecture suivant présente une connexion entre OCI et Google Cloud.
Se connecter à AWS et à d'autres plates-formes en nuage
Le diagramme suivant présente une connexion entre OCI et AWS à l'aide de notre partenaire de connexion Megaport :
Vous pouvez également envisager une connexion RPV directe entre AWS et OCI.
Exigences en matière de résilience
Évaluez votre besoin de résilience régionale en cas de pannes et envisagez un déploiement dans plusieurs régions.
Déploiement multirégion
Le diagramme suivant présente la réplication des données entre une région principale et une région de secours :
Description de l'illustration multi-region-deployment-full-arch.png
Service d'équilibrage de charge
Utilisez un équilibreur de charge (public ou privé) pour optimiser la répartition du trafic. Plusieurs serveurs dorsaux.
Équilibreur de charge
Un équilibreur de charge standard pour les serveurs Web publics peut interrompre le trafic SSL ou le transmettre au serveur dorsal. Utilisez des formes flexibles entre la bande passante minimale et maximale en fonction du trafic.
Vous pouvez configurer un équilibreur de charge public ou privé sur la couche 4/7, TCP/HTTP.
Équilibreur de charge de réseau
Service gratuit offrant un service d'équilibrage de charge sans mandataire à très faible latence et à débit élevé. Les équilibreurs de charge de réseau sont optimisés pour les connexions de longue durée sur plusieurs jours ou mois avec des connexions au même serveur dorsal, ce qui est optimal pour la base de données.
Les équilibreurs de charge de réseau garantissent la disponibilité continue de vos services en dirigeant le trafic uniquement vers des serveurs sains en fonction des données de couche 3/de couche 4 (protocole IP).
Pour en savoir plus, consultez la rubrique Comparaison de l'équilibreur de charge et de l'équilibreur de charge de réseau dans la documentation OCI liée à En savoir plus.
Exigences de sécurité
Service de pare-feu d'application Web OCI
- Contrôle d'accès
- Gestion des robots
- Règles de protection
- Limites de débit
- Applications client
Note :
Utilisez le service WAF pour protéger les points d'extrémité accessibles sur Internet et assurer une application uniforme des règles de sécurité sur l'ensemble des applications.Pour en savoir plus, consultez la politique OCI WAF (solution régionale) et la politique de périphérie de réseau (solution globale).
Service de pare-feu de réseau pour OCI
Le diagramme suivant présente une conception d'insertion de pare-feu de réseau OCI prise en charge qui permet l'utilisation d'un seul pare-feu de réseau OCI pour gérer à la fois les modèles de trafic nord-sud (Internet-bound) et est-ouest (inter-VCN et sur place) :
Dans cette architecture, un pare-feu de réseau OCI déployé dans un VCN central Hub inspecte et sécurise les flux de trafic entrants à partir d'Internet, sortants vers Internet et d'une région sur place.
ZPR (Zero Trust Packet Routing)
Le diagramme suivant présente les politiques de sécurité de réseau gérées indépendamment de l'architecture de réseau sous-jacente afin de réduire le risque d'accès non autorisé :
Les administrateurs de la sécurité peuvent rapidement définir des politiques d'accès basées sur une intention. Seul le trafic explicitement autorisé est autorisé, ce qui rend l'accès non autorisé impossible. Cette approche simplifie les processus de gestion et d'audit de la sécurité du réseau.