Déployer Oracle REST Data Services sur Oracle Cloud Infrastructure

Déployez Oracle REST Data Services (ORDS) à haute disponibilité sur Oracle Cloud Infrastructure (OCI) et REST pour activer votre base de données et exposer les avantages de l'architecture et des capacités des microservices.

ORDS relie HTTPS et votre base de données Oracle. En tant qu'application Java de niveau intermédiaire, elle fournit une API REST du service de gestion de bases de données, SQL Developer Web, une passerelle PL/SQL, SODA pour REST et la possibilité de publier des services Web RESTful pour interagir avec les données et les procédures stockées dans votre base de données Oracle.

ORDS offre également une flexibilité accrue en prenant en charge les déploiements qui utilisent Oracle WebLogic Server ou Apache Tomcat, ou qui sont en mode autonome. ORDS simplifie encore le processus de déploiement car aucun répertoire de base Oracle n'est requis, car un pilote JDBC intégré fournit une connectivité.

Cette architecture de référence décrit comment déployer ORDS sur plusieurs instances de calcul de machine virtuelle, créant ainsi un niveau intermédiaire hautement disponible pour vos instances de base de données Oracle.

Architecture

Cette architecture vous montre comment déployer Oracle REST Data Services avec une haute disponibilité sur OCI.

L'architecture commence par un réseau en nuage virtuel (VCN) dans une seule région. Bien que ce VCN puisse couvrir plusieurs domaines de disponibilité, pour cette architecture de référence, il utilise un seul domaine de disponibilité. Ce domaine de disponibilité contient plusieurs domaines d'erreur, c'est-à-dire des domaines dans un domaine de disponibilité qui ont regroupé le matériel et l'infrastructure. Les machines virtuelles de calcul avec ORDS sont déployées dans plusieurs domaines d'erreur pour assurer la haute disponibilité.

Dans le VCN, plusieurs sous-réseaux contiennent des composants architecturaux spécifiques. Elle commence par une passerelle Internet, qui autorise uniquement le trafic sur un port spécifié vers les équilibreurs de charge à l'extrémité avant de ce VCN dans un sous-réseau public. Les équilibreurs de charge ont également une adresse IP publique que vous pouvez utiliser ultérieurement pour appliquer des noms de domaine personnalisés, si nécessaire. L'équilibreur de charge communiquera avec le sous-réseau contenant les niveaux intermédiaires de calcul ORDS. La communication est sécurisée par des listes de sécurité à l'échelle du sous-réseau ainsi que par des groupes de sécurité de réseau. Vous pouvez appliquer ces groupes de sécurité de réseau à un jeu de cartes vNIC sur les équilibreurs de calcul et de charge afin de fournir des règles de sécurité granulaires pour la communication entre ces ressources.

Enfin, en employant de nouveau des listes de sécurité et des groupes de sécurité de réseau, les niveaux intermédiaires ORDS peuvent accéder à une base de données Oracle dans un sous-réseau privé. Les ressources qui utilisent des sous-réseaux privés ne disposent pas d'adresses IP publiques. De cette façon, vous pouvez utiliser les groupes de sécurité de réseau pour une couche de communication sécurisée entre les sous-réseaux publics et privés. L'instance de base de données Oracle de ce sous-réseau privé peut être une instance de base de données sur machine virtuelle, une base de données autonome ou une base de données Exadata Cloud Service.

Le diagramme suivant illustre cette architecture de référence.

Une description de ha-ords-oci3.png suit
Description de l'illustration ha-ords-oci3.png

ha-ords-oci3.zip

Cette architecture comprend les composants suivants :

Région
Une région OCI est une zone géographique localisée qui contient un ou plusieurs centres de données, appelés domaines de disponibilité. Les régions sont indépendantes les unes des autres, et de grandes distances peuvent les séparer (à travers les pays ou même les continents).
Domaines de disponibilité
Les domaines de disponibilité sont des centres de données indépendants et autonomes dans une région. Les ressources physiques de chaque domaine de disponibilité sont isolées des ressources des autres domaines de disponibilité, ce qui garantit la tolérance aux pannes. Les domaines de disponibilité ne partagent pas les éléments d'infrastructure (alimentation ou refroidissement, par exemple) ni le réseau de domaines de disponibilité interne. Il est donc improbable qu'une défaillance d'un domaine de disponibilité ait une incidence sur les autres domaines de disponibilité de la région. Les ressources de cette architecture sont déployées dans un seul domaine de disponibilité.
Domaines d'erreur
Un domaine d'erreur est un regroupement de matériel et d'infrastructure au sein d'un domaine de disponibilité. Chaque domaine de disponibilité comporte trois domaines d'erreur dotés d'une alimentation électrique et d'un matériel indépendants. Lorsque vous répartissez des ressources sur plusieurs domaines d'erreur, vos applications peuvent tolérer la défaillance physique de serveur, la maintenance du système et les pannes de courant dans un domaine d'erreur. Les ressources de cette architecture sont déployées dans plusieurs domaines d'erreur.
Réseau en nuage virtuel (VCN) et sous-réseaux
Un VCN est un réseau défini par logiciel personnalisable que vous configurez dans une région OCI. Comme les réseaux de centre de données traditionnels, les réseaux en nuage virtuels vous offrent un contrôle complet sur votre environnement de réseau. Un VCN peut disposer de plusieurs blocs CIDR sans chevauchement que vous pouvez modifier après avoir créé le VCN. Vous pouvez segmenter un VCN en sous-réseaux, dont la portée peut concerner une région ou un domaine de disponibilité. Un sous-réseau est constitué d'un intervalle contigu d'adresses qui ne chevauchent pas les autres sous-réseaux dans le réseau en nuage virtuel. Vous pouvez modifier la taille d'un sous-réseau après sa création. Un sous-réseau peut être public ou privé.

Dans cette architecture de référence, les instances de calcul avec ORDS sont attachées à un sous-réseau public ainsi qu'à l'équilibreur de charge, tandis que les bases de données peuvent utiliser un sous-réseau privé ou public. Les meilleures pratiques de sécurité de base de données placent les instances de base de données dans des sous-réseaux privés lorsque cela est possible.
Équilibreur de charge
Le service Oracle Cloud Infrastructure Load Balancing assure la répartition automatisée du trafic d'un point d'entrée unique vers plusieurs serveurs dans l'élément dorsal. L'adresse IP publique de cet équilibreur de charge servira également d'emplacement où nous pourrons enregistrer des noms de domaine personnalisés, si nécessaire.
Passerelle d'API
Oracle Cloud Infrastructure API Gateway vous permet de publier des API avec des points d'extrémité privés accessibles à partir de votre réseau, et que vous pouvez exposer au réseau Internet public, si nécessaire. Les points d'extrémité prennent en charge la validation, la transformation des demandes et des réponses, la CORS, l'authentification et l'autorisation, ainsi que la limitation des demandes pour les API.
Instances de calcul/hôtes ORDS
Le service Calcul pour Oracle Cloud Infrastructure permet de provisionner et de gérer des hôtes pour les calculs. Vous pouvez lancer des instances de calcul avec des formes qui répondent à vos besoins en ressources (UC, mémoire, bande passante de réseau et stockage). Après avoir créé une instance de calcul, vous pouvez y accéder en toute sécurité, la redémarrer, attacher et détacher des volumes, et y mettre fin lorsque vous n'en avez pas besoin. Les serveurs Web de cette architecture s'exécutent sur des machines virtuelles de calcul à l'aide d'une architecture d'UC x86 ou ARM
Instances de base de données
Le service Database Cloud propose des solutions Oracle Database en nuage, autonomes ou gérées par l'utilisateur. Les bases de données autonomes sont des environnements préconfigurés et entièrement gérés, adaptés aux charges de travail de traitement des transactions ou d'entrepôt de données. Les solutions cogérées sont des systèmes de base de données sans système d'exploitation, sur machine virtuelle et Exadata que vous pouvez personnaliser avec les ressources et les paramètres adaptés à vos besoins.

Cette architecture de référence peut être utilisée pour les bases de données autonomes ou les instances de base de données cogérées.
Groupes de sécurité de réseau
Les groupes de sécurité de réseau servent de pare-feu virtuels pour vos instances de calcul. Avec le modèle de sécurité " confiance zéro " d'OCI, tout le trafic est refusé et vous pouvez contrôler le trafic réseau dans un VCN. Un groupe de sécurité de réseau est composé d'un jeu de règles de sécurité pour les données entrantes et sortantes qui s'appliquent seulement à un jeu spécifié de cartes vNIC dans un seul réseau VCN. Dans cette architecture, des groupes de sécurité de réseau distincts sont utilisés pour l'équilibreur de charge, les serveurs Web et la base de données.
Tables de routage
Les tables de routage virtuelles contiennent des règles pour acheminer le trafic des sous-réseaux vers des destinations en dehors d'un VCN, généralement au moyen de passerelles.
Passerelle Internet
La passerelle Internet permet le trafic entre les sous-réseaux publics d'un VCN et le réseau Internet public.
Listes de sécurité
Les listes de sécurité sont un jeu de règles entrantes et sortantes qui spécifient les types de trafic permis pour toutes les cartes vNIC/instances d'un sous-réseau. Les listes de sécurité sont appliquées au niveau du sous-réseau par rapport aux groupes de sécurité de réseau au niveau de la carte VNIC. Les deux agissent efficacement comme un pare-feu pour une carte VNIC. Avec le modèle de sécurité zéro confiance d'OCI, tout le trafic vers une carte VNIC est refusé. Le SL et le NSG doivent autoriser explicitement le trafic, pour que le trafic soit autorisé à la carte VNIC.
Zero-Trust Packet Routing (ZPR) (Acheminement de paquets zéro confiance)
En plus du SL et du NSG, OCI dispose d'une structure de sécurité de réseau appelée Zero-Trust Packet Routing. ZPR est un réseau sécurisé basé sur l'intention agissant au niveau de la couche 4 et peut être mis en œuvre dans un langage de politique lisible par l'homme. En affectant des attributs de sécurité ("tags" pour ZPR) à vos ressources, vous pouvez créer des contrôles d'accès granulaires pour vous assurer que seules les entités autorisées peuvent communiquer avec des composants sensibles, tels que des bases de données et des serveurs d'applications. Cette approche réduit non seulement le risque d'accès non autorisé, mais simplifie également la gestion des politiques à mesure que votre application évolue. ZPR fonctionne aux côtés des NSG et SL existants, offrant une posture de sécurité plus complète qui s'adapte aux changements de votre architecture réseau. Ici, vous pouvez affecter des attributs de sécurité (marqueurs ZPR spéciaux) aux noeuds de chaque sous-réseau, de manière à ce que seul le trafic requis soit autorisé (direction de flux, protocole et ports), peu importe comment l'architecture réseau change ou change à l'avenir.

Recommandations

Utilisez les recommandations suivantes comme point de départ. Vos exigences peuvent différer de l'architecture décrite ici.

VCN
Lorsque vous créez un VCN, déterminez le nombre de blocs CIDR requis et la taille de chaque bloc en fonction du nombre de ressources que vous prévoyez d'attacher aux sous-réseaux du VCN. Utilisez des blocs CIDR qui se trouvent dans l'espace d'adresses IP privées standard.

Sélectionnez les blocs CIDR qui ne chevauchent aucun autre réseau (dans Oracle Cloud Infrastructure, votre centre de données sur place ou un autre fournisseur de services infonuagiques) auquel vous avez l'intention de configurer des connexions privées.

Après avoir créé un VCN, vous pouvez modifier, ajouter et supprimer ses blocs CIDR.

Lorsque vous concevez les sous-réseaux, tenez compte du flux de trafic et des exigences de sécurité. Attachez toutes les ressources d'un niveau ou d'un rôle spécifique au même sous-réseau, ce qui peut servir de limite de sécurité.

Utiliser des sous-réseaux régionaux.

Envisagez de déployer des pare-feu pour chaque limite de réseau.
Service d'équilibrage de charge
OCI offre un équilibrage de charge flexible. Vous pouvez créer des équilibreurs de charge avec des limites supérieure et inférieure afin qu'ils puissent être ajustés en fonction du nombre de demandes entrantes. Les limites peuvent aller de 10mbps à 8000mbps. Pour les instances nécessitant un équilibrage de charge multidomaine de disponibilité ou multirégion, utilisez DNS Cloud Service avec la capacité de pilotage pour la gestion du trafic.
Sécurité
Utilisez Oracle Cloud Guard pour surveiller et maintenir de manière proactive la sécurité de vos ressources dans Oracle Cloud Infrastructure. Le service de protection d'infrastructure en nuage utilise des recettes de détecteur que vous pouvez définir pour examiner vos ressources afin de détecter les failles de sécurité et pour surveiller les opérateurs et les utilisateurs à la recherche d'activités risquées. Lorsqu'une mauvaise configuration ou une activité non sécurisée est détectée, le service de protection d'infrastructure en nuage recommande des actions correctives et aide à effectuer ces actions, en fonction des recettes de répondant que vous pouvez définir.

Pour les ressources nécessitant une sécurité maximale, Oracle recommande d'utiliser des zones de sécurité. Une zone de sécurité est un compartiment associé à une recette de politiques de sécurité définie par Oracle et basée sur les meilleures pratiques. Par exemple, les ressources d'une zone de sécurité ne doivent pas être accessibles par l'Internet public et doivent être chiffrées à l'aide de clés gérées par le client. Lors de la création et de la mise à jour de ressources dans une zone de sécurité, Oracle Cloud Infrastructure valide les opérations en fonction des politiques de la recette de zone de sécurité et refuse les opérations qui violent l'une des politiques.
Instances de base de données
Pour les applications de production, l'instance de base de données Oracle doit respecter le modèle de déploiement MAA (Maximum Availability Architecture) d'Oracle dans OCI. Le respect de ces directives garantit que la base de données est non seulement hautement disponible, mais également protégée contre les pannes et les sinistres en cas de survenue. Ces architectures permettent également de générer des rapports sur les bases de données qui utilisent l'instance DR.

L'architecture MAA est intégrée aux services Oracle Cloud Infrastructure Database, à la fois cogérés et autonomes. Data Guard, GoldenGate, RAC et les sauvegardes automatiques sont immédiatement disponibles et doivent être utilisés pour l'environnement de production, le cas échéant.

Lorsque vous utilisez RAC avec Oracle Cluster Registry (OCR)Oracle Database, assurez-vous que les informations de connexion à la base de données utilisées par ORDS pointent vers le module d'écoute SCAN et non vers un noeud individuel.

Instances de calcul/ORDS

Pour obtenir des recommandations sur le dimensionnement des niveaux intermédiaires de calcul, consultez le graphique suivant :

Tailles d'architecture de référence (machines virtuelles)

Forme

Nombre maximal d'OCPU

Mémoire minimale

Mémoire maximale

VM.Standard3.Flex