Déploiement d'Oracle REST Data Services et de la haute disponibilité sur Oracle Cloud Infrastructure

Déployez Oracle REST Data Services (ORDS) avec une 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 fonctionnalités des microservices.

ORDS fait le lien entre HTTPS et votre base de données Oracle. En tant qu'application Java de niveau intermédiaire, elle fournit une API REST Database Management, 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 davantage 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 explique comment déployer ORDS sur plusieurs instances de calcul de machine virtuelle, en créant un niveau intermédiaire hautement disponible pour vos instances de base de données Oracle.

Architecture

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

L'architecture commence par un réseau cloud virtuel (VCN) au sein d'une seule région. Bien que ce VCN puisse s'étendre sur 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 de pannes : des domaines au sein d'un domaine de disponibilité qui ont regroupé le matériel et l'infrastructure. Les machines virtuelles de calcul avec ORDS sont déployées sur plusieurs domaines de pannes pour contribuer à la haute disponibilité.

Dans le VCN, plusieurs sous-réseaux contiennent des composants architecturaux spécifiques. Il commence par une passerelle Internet, qui autorise uniquement le trafic sur un port spécifié vers les équilibreurs de charge sur l'extrémité avant de ce VCN dans un sous-réseau public. Les équilibreurs de charge disposent également d'une adresse IP publique que vous pourrez 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é réseau. Vous pouvez appliquer ces groupes de sécurité réseau à un ensemble de cartes d'interface réseau virtuelles sur les équilibreurs de charge et de calcul afin de fournir des règles de sécurité affinées pour la communication entre ces ressources.

Enfin, en utilisant à nouveau des listes de sécurité et des groupes de sécurité réseau, les niveaux intermédiaires ORDS peuvent accéder à une base de données Oracle dans un sous-réseau privé. Les adresses IP publiques ne sont pas attribuées aux ressources utilisant des sous-réseaux privés. De cette façon, vous pouvez utiliser les groupes de sécurité 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 dans ce sous-réseau privé peut être une instance de base de données de machine virtuelle, une base de données autonome ou une base de données Exadata Cloud Service.

Le schéma suivant illustre cette architecture de référence.

Description de l'image ha-ords-oci3.png

h-ords-oci3.zip

Cette architecture comprend les composants suivants :

Région
Une région OCI est une zone géographique précise 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 (entre les pays ou même les continents).
Domaines de disponibilité
Les domaines de disponibilité sont des centres de données autonomes indépendants au sein d'une région. Les ressources physiques de chaque domaine de disponibilité sont isolées de celles des autres, ce qui garantit la tolérance aux pannes. Les domaines de disponibilité ne partagent ni infrastructure (par exemple, alimentation, système de refroidissement), ni réseau de domaine de disponibilité interne. Par conséquent, il est peu probable qu'une panne sur un domaine de disponibilité affecte 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 de pannes
Un domaine de pannes est un regroupement de matériel et d'infrastructures au sein d'un domaine de disponibilité. Chaque domaine de disponibilité dispose de trois domaines de pannes avec du matériel et une alimentation indépendants. Lorsque vous répartissez les ressources entre plusieurs domaines de pannes, vos applications peuvent tolérer les pannes physiques du serveur, la maintenance du système et les pannes d'alimentation au sein d'un domaine de pannes. Les ressources de cette architecture sont déployées dans plusieurs domaines de pannes.
Réseau cloud virtuel (VCN) et sous-réseaux
Un VCN est un réseau personnalisable défini par logiciel que vous configurez dans une région OCI. Comme les réseaux de centre de données traditionnels, les réseaux cloud virtuels vous donnent un contrôle total sur l'environnement réseau. Un réseau cloud virtuel peut comporter plusieurs blocs CIDR qui ne se chevauchent pas et que vous pouvez modifier après l'avoir créé. Vous pouvez segmenter un réseau cloud virtuel en plusieurs sous-réseaux ciblant une région ou un domaine de disponibilité. Chaque sous-réseau est composé d'une plage contiguë d'adresses qui ne chevauchent pas celles des autres sous-réseaux du réseau cloud 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 avec l'équilibreur de charge, tandis que les bases de données peuvent utiliser un sous-réseau privé ou public. Les meilleures pratiques en matière de sécurité des bases de données placent les instances de base de données dans des sous-réseaux privés chaque fois que cela est possible.
équilibreur de charge
Le service Oracle Cloud Infrastructure Load Balancing fournit une distribution automatisée du trafic à partir d'un point d'entrée unique vers plusieurs serveurs dans le back-end. L'adresse IP publique de cet équilibreur de charge servira également d'emplacement pour l'enregistrement de noms de domaine personnalisés si nécessaire.
API Gateway
Oracle Cloud Infrastructure API Gateway vous permet de publier des API avec des adresses privées accessibles à partir de votre réseau et que vous pouvez présenter au réseau Internet public, si nécessaire. Les adresses prennent en charge la validation d'API, la transformation des demandes et des réponses, CORS, l'authentification et l'autorisation, ainsi que la limitation des demandes.
Instances de calcul/hôtes ORDS
Oracle Cloud Infrastructure Compute vous permet de provisionner et de gérer des hôtes de calcul. Vous pouvez lancer des instances de calcul avec des formes qui répondent à vos besoins en ressources (UC, mémoire, bande passante 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 sont exécutés 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 offre des solutions cloud Oracle Database autonomes et co-gérées. Les bases de données autonomes sont des environnements préconfigurés et entièrement gérés adaptés aux charges globales de traitement des transactions ou d'entrepôt de données. Les solutions co-gérées sont des systèmes de base de données Bare Metal, de machine virtuelle et Exadata que vous pouvez personnaliser avec les ressources et les paramètres qui répondent à 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 co-gérées.
Groupes de sécurité réseau
Les groupes de sécurité réseau agissent comme des pare-feu virtuels pour vos instances de calcul. Avec le modèle de sécurité zéro confiance d'OCI, tout le trafic est refusé et vous pouvez contrôler le trafic réseau au sein d'un VCN. Un groupe de sécurité réseau se compose d'un ensemble de règles de sécurité entrantes et sortantes qui s'appliquent uniquement à un ensemble spécifié de cartes d'interface réseau virtuelles dans un seul VCN. Dans cette architecture, des groupes de sécurité 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 via des passerelles.
Passerelle Internet
La passerelle Internet autorise le trafic entre les sous-réseaux publics d'un VCN et le réseau Internet public.
Listes de sécurité
La liste de sécurité est un ensemble de règles entrantes et sortantes qui indiquent les types de trafic autorisés vers et vers l'extérieur pour toutes les VNIC/instances d'un sous-réseau. Les listes de sécurité sont appliquées au niveau du sous-réseau et les groupes de sécurité réseau au niveau de la carte d'interface réseau virtuelle. Les deux agissent en tant que pare-feu pour une VNIC. Avec le modèle de sécurité zéro confiance d'OCI, tout le trafic vers une carte d'interface réseau virtuelle est refusé. SL et NSG doivent autoriser le trafic explicitement, pour que le trafic soit autorisé sur la VNIC.
Routage de paquets sans confiance (ZPR)
En plus de SL et NSG, OCI dispose d'une structure de sécurité 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 implémenté dans un langage de stratégie lisible par l'homme. En affectant des attributs de sécurité ("balises" 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 stratégies à mesure que votre application évolue. ZPR fonctionne aux côtés des groupes de sécurité réseau et des bibliothèques de services 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é (balises ZPR spéciales) aux noeuds de chaque sous-réseau, de sorte que seul le trafic requis est autorisé (direction de flux, protocole et ports), quelle que soit la façon dont l'architecture du réseau change / 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 à des sous-réseaux dans le VCN. Utilisez des blocs CIDR qui se trouvent dans l'espace d'adresse IP privée standard.

Sélectionnez les blocs CIDR qui ne chevauchent aucun autre réseau (dans Oracle Cloud Infrastructure, votre centre de données sur site ou un autre fournisseur cloud) 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, 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.
Equilibrage 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 évoluer en fonction du nombre de demandes entrantes. Les limites peuvent aller de 10mbps à 8000mbps. Pour les instances nécessitant un équilibrage de charge multi-domaines ou multi-région, utilisez DNS Cloud Service avec la fonctionnalité de pilotage de 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. Cloud Guard utilise des recettes de détecteur que vous pouvez définir pour examiner les faiblesses de sécurité de vos ressources et pour surveiller les opérateurs et les utilisateurs afin de détecter les activités à risque. Lorsqu'une erreur de configuration ou une activité non sécurisée est détectée, Cloud Guard recommande des actions correctives et vous aide à effectuer ces actions, en fonction des recettes de répondeur que vous pouvez définir.

Pour les ressources nécessitant une sécurité maximale, Oracle vous recommande d'utiliser des zones de sécurité. Une zone de sécurité est un compartiment associé à une recette de stratégies de sécurité définie par Oracle qui repose sur les meilleures pratiques. Par exemple, les ressources d'une zone de sécurité ne doivent pas être accessibles à partir du réseau Internet public et doivent être cryptées à l'aide de clés gérées par le client. Lorsque vous créez et mettez à jour des ressources dans une zone de sécurité, Oracle Cloud Infrastructure valide les opérations par rapport aux stratégies de la recette de zone de sécurité et refuse les opérations qui enfreignent l'une des stratégies.
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 bénéficient également de la génération de rapports sur les bases de données qui utilisent l'instance de récupération après sinistre.

L'architecture MAA est intégrée directement aux services Oracle Cloud Infrastructure Database, à la fois co-gérés et autonomes. Data Guard, GoldenGate, RAC et les sauvegardes automatiques sont immédiatement disponibles et doivent être utilisées 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 processus d'écoute SCAN et non vers un noeud individuel.

Instances Compute/ORDS

Lors du dimensionnement des niveaux intermédiaires de calcul, reportez-vous au graphique suivant pour obtenir des recommandations :

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

Forme

Nombre maximal d'OCPU

Mémoire minimale

Mémoire maximale

VM.Standard3.Flex