Architectures pour les applications Oracle avec base de données sur les machines virtuelles Azure
Cet article fournit une architecture de référence pour déployer une application Oracle sur Azure IaaS, où se trouve ou est colocalisée aussi la base de données Oracle.
Les charges de travail Oracle comprennent non seulement des bases de données Oracle, mais aussi des applications d’Oracle comme Siebel, PeopleSoft, JD Edwards, E-Business Suite, ou des applications serveur WebLogic personnalisées. Le déploiement d’applications Oracle sur Azure IaaS ( Infrastructure as a Service) est un scénario courant pour les organisations qui cherchent à utiliser le cloud pour leurs charges de travail Oracle avec une base de données Oracle. Microsoft offre des architectures de référence et des meilleures pratiques pour faciliter ce processus.
Instructions générales relatives à la migration d’applications
Quand des applications Oracle sont transférées sur Azure IaaS, des considérations courantes relatives à la conception doivent être respectées, quel que soit le type des applications. Certaines considérations sont spécifiques aux applications. Dans cette section, nous listons les considérations courantes relatives à la conception de toutes les applications, et les considérations spécifiques aux applications sont détaillées sous chaque application.
Réseau et sécurité
Les paramètres réseau fournis pour les applications Oracle sur Azure couvrent différents aspects des considérations relatives au réseau et à la sécurité. Voici une décomposition des paramètres réseau recommandés :
Authentification unique (SSO) avec Microsoft Entra ID et SAML : utilisez Microsoft Entra ID pour l’authentification unique (SSO) avec le protocole SAML (Security Assertions Markup Language). Cette authentification unique permet aux utilisateurs de s’authentifier une seule fois et d’accéder facilement à plusieurs services.
Proxy d’application Microsoft Entra : envisagez d’utiliser le proxy d’application Microsoft Entra, en particulier pour les utilisateurs distants. Ce proxy vous permet d’accéder de façon sécurisée à des applications locales depuis l’extérieur de votre réseau.
Routage des utilisateurs internes via ExpressRoute : pour les utilisateurs internes, routez le trafic via Azure ExpressRoute pour une connexion dédiée et privée aux services Azure, ce qui garantit une latence faible et une communication sécurisée.
Pare-feu Azure : si nécessaire, vous pouvez configurer le Pare-feu Azure devant votre application pour renforcer la sécurité. Le Pare-feu Azure permet de protéger vos ressources contre les accès non autorisés et les menaces.
Application Gateway pour les utilisateurs externes : quand des utilisateurs externes doivent accéder à votre application, envisagez d’utiliser Azure Application Gateway. Il fournit des fonctionnalités de pare-feu d’applications web (WAF) pour protéger vos applications web et l’équilibrage de charge de couche 7 pour distribuer le trafic.
Groupes de sécurité réseau (NSG) : sécurisez vos sous-réseaux en utilisant des groupes de sécurité réseau (NSG). Les groupes de sécurité réseau vous permettent de contrôler le trafic entrant et sortant vers les interfaces réseau, les machines virtuelles et les sous-réseaux en définissant des règles de sécurité.
Contrôle d’accès en fonction du rôle (RBAC) : pour accorder l’accès à des personnes ou des rôles spécifiques, utilisez le RBAC Azure. RBAC offre une gestion précise de l’accès aux ressources Azure en fonction des rôles et des autorisations.
Hôte bastion pour l’accès SSH : utilisez un hôte bastion comme serveur de rebond pour améliorer la sécurité de l’accès SSH. Un hôte Bastion agit comme une passerelle sécurisée permettant aux administrateurs d’accéder à des machines virtuelles dans le réseau virtuel. Cet hôte fournit une couche de sécurité supplémentaire.
Autres considérations :
- Chiffrement des données : vérifiez que les données au repos et en transit sont chiffrées. Azure fournit pour cela des outils comme Azure Disk Encryption et SSL/TLS.
- Gestion des correctifs : mettez à jour et corrigez régulièrement votre environnement EBS pour vous protéger contre les vulnérabilités connues.
- Supervision et journalisation : implémentez Azure Monitor et Azure Defender pour que la sécurité vérifie en permanence votre environnement afin de détecter les menaces et les anomalies de sécurité. Configurez la journalisation pour l’audit et l’analyse légale.
En résumé, ces paramètres réseau et de sécurité visent à fournir un environnement robuste et sécurisé pour l’hébergement d’applications Oracle sur Azure IaaS. Ils intègrent les meilleures pratiques pour l’authentification, le contrôle d’accès et la sécurité réseau, à la fois pour les utilisateurs internes et externes. Ils prennent également en compte la nécessité d’un accès SSH aux serveurs d’applications. Ces recommandations peuvent vous aider à configurer une posture de sécurité mature pour votre déploiement d’applications Oracle sur Azure IaaS.
Couche Web : la couche Web équilibre la charge des requêtes et envoie les requêtes en conséquence au niveau application, au niveau base de données et/ou à la sauvegarde.
Couche Application : la couche Application implique généralement des serveurs d’applications et des systèmes de fichiers partagés.
Pour la mise à l’échelle automatique, les groupes de machines virtuelles identiques peut être un bon choix pour le scale-out de plusieurs machines virtuelles en fonction de la demande avec des règles de mise à l’échelle personnalisées pour s’adapter à votre charge de travail.
Collaborez avec des experts techniques Azure pour effectuer une évaluation approfondie de votre architecture. Ils peuvent vous aider à déterminer les services Azure les plus appropriés en fonction de vos besoins spécifiques, notamment les performances, la disponibilité et la scalabilité. N’oubliez pas d’envisager des facteurs comme le coût, la sécurité des données, la conformité et la récupération d’urgence lors de la conception de votre architecture.
Il est également essentiel de vérifier et d’optimiser vos ressources Azure en continu pour garantir l’efficience et l’efficacité des coûts.
Équilibrage de charge et débit : il est important d’évaluer les caractéristiques des charges de travail des serveurs d’applications. Certains serveurs gèrent plus de tâches et génèrent un débit plus élevé que d’autres. Ces informations sont cruciales lors de la conception de vos groupes de machines virtuelles identiques Azure et de la configuration de l’équilibrage de charge pour garantir que les ressources sont allouées efficacement.
Couche Base de données : des architectures haute disponibilité sont recommandées avec Oracle Data Guard pour Oracle sur Azure IaaS. Les applications nécessitent un type spécifique de configuration de haute disponibilité et elles sont listées sous chaque application.
Sauvegarde : les sauvegardes sont envoyées depuis la couche Application et la couche Base de données. C’est une des nombreuses raisons pour lesquelles ces deux couches ne doivent pas être séparées en deux fournisseurs différents. Les sauvegardes de la base de données sont effectuées par Instantané de volume de Sauvegarde Azure sur des fichiers Premium dans la région secondaire.
Récupération d’urgence : il existe différentes solutions parmi lesquelles vous pouvez choisir. Cela dépend beaucoup de vos exigences. L’architecture est conçue pour offrir une haute disponibilité. Pour répliquer la couche Application, vous pouvez utiliser Azure Site Recovery. Une autre solution que vous pouvez choisir est Options de redondance pour les disques managés. Les deux solutions répliquent vos données. Les options de redondance pour les disques managés sont une solution qui peut simplifier l’architecture, mais qui présente également quelques limitations.
Siebel sur Azure
Oracle Siebel CRM reste une solution CRM de qualité entreprise choisir par de nombreuses entreprises. C’est une des applications les plus complexes du portefeuille d’Oracle, offrant une combinaison de fonctionnalités transactionnelles, analytiques et d’engagements pour gérer les opérations côté client.
Voici l’architecture recommandée d’un déploiement d’application Siebel sur des machines virtuelles Azure pour Innovation Pack 16 et ultérieur :
Voici l’architecture recommandée d’un déploiement d’application Siebel sur des machines virtuelles Azure pour Innovation Pack 17 et ultérieur :
Considérations relatives à la conception pour Oracle Siebel
Sécurité et réseau : paramètres réseau pour Oracle Siebel sur Azure nécessaires pour suivre les considérations générales relatives à la sécurité et au réseau.
La migration doit être effectuée en utilisant le sous-réseau Siebel Tool.
Couche Application
- Version 17 ou ultérieure : la configuration de certains serveurs et utilitaires sur l’application et la base de données est nécessaire.
Couche Base de données
- Vérifiez que les versions de la base de données et de Siebel correspondent.
- Vérifiez que les bases de données primaires et répliquées sont copiées dans une base de données secondaire à l’aide de l’architecture de référence Oracle Data Guard.
E-Business Suite sur Azure
Oracle E-Business Suite (EBS) est une suite d'applications comprenant la gestion de la chaîne d’approvisionnement (SCM) et la gestion de la relation client (CRM). Comme EBS est un système SCM et CRM, il a généralement de nombreuses interfaces avec des systèmes de tiers. L’architecture suivante est conçue pour offrir une haute disponibilité au sein d’une région.
Nous partons du principe que les utilisateurs externes ne traversent pas le réseau d’entreprise dans le diagramme suivant.
Considérations relatives à la conception d’Oracle EBS
Couche Base de données : la base de données primaire et la base de données secondaire doivent se trouver dans un même centre de données. La configuration synchrone doit être utilisée. Si vous installez votre application dans plusieurs centres de données, vous devez configurer Data Guard en mode asynchrone.
JD Edwards sur Azure
JD Edwards d’Oracle est une suite d’applications intégrées de logiciels complets de planification des ressources d’entreprise. Actuellement, JD Edwards est utilisé dans la chaîne logistique, la gestion d’entrepôt, la logistique, la planification des ressources de fabrication, etc. En raison de l’utilisation de l’application, nous voyons que les interfaces vers d’autres systèmes sont également importantes.
L’architecture suivante est conçue pour offrir une haute disponibilité. Nous avons supposé que les utilisateurs externes n’accèdent pas au réseau d’entreprise. Si un utilisateur externe accède à l’application en utilisant le réseau d’entreprise, l’architecture peut être simplifiée comme suit pour la partie réseau.
Considérations relatives à la conception de JD Edwards
Couche Web : la couche Application web se compose généralement de plusieurs serveurs d’applications. Dans JD Edwards, les règles sont souvent enregistrées sur ces serveurs web d’applications.
Couche Présentation : chaque instance de la couche Présentation est associée au stockage. La réduction des dépendances entre les instances peut entraîner des latences élevées : il est donc crucial de les évaluer soigneusement.
Variation des performances des serveurs : certains serveurs gèrent plus de tâches et génèrent un débit plus élevé que d’autres. Pendant la phase de conception, il est essentiel d’évaluer cette variation du débit pour garantir que votre infrastructure peut gérer efficacement les charges de travail lors des crêtes.
Réarchitecture : l’utilisation de groupes de machines virtuelles identiques Azure pour la mise à l’échelle automatique ne nécessite pas une réarchitecture de votre configuration JD Edwards. C’est une solution évolutive qui peut être implémentée sans apporter de modifications importantes à l’architecture de votre application.
Couche Base de données : la base de données primaire et la base de données secondaire se trouvent dans un même centre de données ; la configuration synchrone doit être utilisée. Si vous installez votre application dans plusieurs centres de données, vous devez configurer Data Guard en mode asynchrone. Les données de la couche Base de données sont envoyées directement à un stockage Azure. Le stockage dépend de la configuration de votre architecture actuelle.
PeopleSoft sur Azure
La suite d'applications PeopleSoft d'Oracle contient un logiciel de gestion des ressources humaines et financières. La suite d’applications comporte plusieurs couches et les applications incluent : systèmes de gestion des ressources humaines (HRMS), gestion de la relation client (CRM), gestion financière et de la chaîne logistique (FSCM) et gestion des performances de l’entreprise (EPM).
Considérations relatives à la conception de PeopleSoft
Couche Application : la couche Application contient plusieurs tâches et serveurs. Elle exécute la logique métier et les processus, mais gère également la connexion à la base de données. Dès que cette dépendance est coupée, elle provoque des latences.
Dépendance entre les couches Application et Base de données : il est important de réduire la latence entre les couches Application et Base de données. En plaçant la couche Application et la couche Base de données dans le même fournisseur de cloud (dans le cas présent, Azure), vous réduisez la latence réseau. Azure fournit différentes options et services réseau, comme le peering de réseau virtuel (VNet) ou ExpressRoute, pour garantir des connexions à faible latence entre les couches.
Considérations relatives au système d’exploitation : si le planificateur de processus requiert spécifiquement des systèmes d’exploitation Windows, vous pouvez néanmoins toujours l’exécuter sur des machines virtuelles Azure. Azure prend en charge différentes versions de Windows Server, vous permettant de choisir celle qui répond aux exigences de votre application.
Évaluation de l’architecture : évaluez soigneusement les exigences de votre architecture, notamment la scalabilité, la disponibilité et les performances. Pour garantir la haute disponibilité et la scalabilité, envisagez de configurer plusieurs instances de serveur d’applications dans une configuration à charge équilibrée.
Couche Base de données : la base de données primaire et répliquée sur une base de données secondaire doit rester dans un même centre de données. La configuration synchrone doit être utilisée. Si vous installez votre application dans plusieurs centres de données, vous devez configurer Data Guard en mode asynchrone.
Étapes suivantes
Architecture de référence pour Oracle Database
Migrer une charge de travail Oracle vers des machines virtuelles Azure