Partager via

Concevoir des applications Oracle

  • Article

La migration d’applications Oracle vers le cloud est un processus complexe. Vous devez comprendre les fonctionnalités prises en charge par chaque version d’une application afin d’éviter les problèmes pendant la migration ou même d’éviter un échec de migration. Les organisations ne veulent pas simplement lift-and-shift d’applications. Ils souhaitent également moderniser l’architecture et s’aligner sur les exigences fonctionnelles et non fonctionnelles. Vous devez examiner ces exigences en même temps que les principaux modèles de conception d’applications cloud pour vous assurer que vous atteignez vos objectifs de migration.

Siebel, E-Business Suite, JD Edwards et PeopleSoft sont des exemples d’applications Oracle populaires. Ces applications ont des dépendances fortes entre la couche Application et la couche Base de données. La séparation des deux niveaux entre différents fournisseurs cloud introduit des latences qui peuvent entraîner une expérience médiocre pour les clients. Vous devez toujours effectuer une évaluation technique appropriée avant de décider comment héberger les deux niveaux.

Pour chaque application, vous devez noter les considérations de conception que le fournisseur de l’application fournit et prendre en compte les caractéristiques des services Azure que vous utilisez pour chaque conception. Le cloud Azure offre de nombreuses fonctionnalités et fonctionnalités qui peuvent conduire à une solution performante, fiable, sécurisée et hautement disponible.

Pour obtenir des conseils d’architecture plus spécifiques, consultez Architectures pour les applications Oracle avec une base de données sur Azure Machines Virtuelles.

Recommandations

Utilisez les recommandations suivantes pour planifier la migration de vos applications Oracle vers le cloud.

Réseau et sécurité

  • Envisagez de configurer l’authentification unique (SSO) à l’aide de Microsoft Entra ID. Les clients peuvent utiliser l’authentification unique pour se connecter aux applications Oracle via leur navigateur Internet. Pour plus d’informations, consultez Activer l’authentification unique pour une application d’entreprise.
  • Envisagez d’utiliser une connexion privée à l’installation cloud. Azure fournit des fonctionnalités de connectivité privée telles que les connexions Azure ExpressRoute et les connexions VPN de site à site.
  • Si un client accède à l’application à partir d’Internet, envisagez une passerelle Application Gateway. Azure Application Gateway fournit deux fonctionnalités intégrées. Il fonctionne comme un pare-feu d’applications web et dispose d’un équilibreur de charge de couche 7 intégré. Application Gateway prend uniquement en charge l’accès sur le port 443 (HTTPS).
  • Une autre option pour sécuriser votre réseau est Pare-feu Azure. Ce composant protège les services web contre les attaques et les vulnérabilités courantes. Il maintient la haute disponibilité des applications Oracle et vous aide à répondre aux exigences de conformité.
  • Envisagez de configurer des groupes de sécurité réseau au niveau du sous-réseau pour vous assurer que le réseau autorise le trafic sur des ports et des adresses IP spécifiques uniquement.
  • Si votre application nécessite le protocole SSH (Secure Shell) ou le protocole RDP (Remote Desktop Protocol), déployez un hôte Azure Bastion en tant que serveur de rebond pour fournir une sécurité supplémentaire pour une posture de sécurité approfondie et mature.

Niveaux Web et Application

  • Déployez votre application sur des machines virtuelles. Regroupez ces machines virtuelles dans des groupes à haute disponibilité pour améliorer la disponibilité globale.
  • Si vous avez besoin que votre application soit mise à l’échelle automatiquement, envisagez d’utiliser Azure Virtual Machine Scale Sets.
  • Placez les machines virtuelles dans une seule zone de disponibilité pour les rapprocher physiquement. Toutefois, gardez à l’esprit qu’à mesure que l’empreinte Azure augmente, une seule zone de disponibilité peut s’étendre sur plusieurs centres de données physiques. La distance entre les centres de données physiques peut entraîner une latence réseau qui affecte votre application. Pour obtenir des machines virtuelles aussi proches que possible et obtenir la latence la plus faible possible, déployez-les dans un groupe de placement de proximité.

Couche base de données

  • Envisagez de déployer la couche base de données en tant que serveur principal répliqué sur un serveur secondaire à l’aide d’Oracle Data Guard.
  • Si vous utilisez deux zones pour déployer les serveurs principal et secondaire dans une région, envisagez d’utiliser la configuration de réplication synchrone Data Guard après avoir vérifié la latence réseau entre les zones de la région.
  • Si vous déployez les serveurs principal et secondaire dans deux régions, envisagez d’utiliser la configuration de réplication asynchrone Data Guard.
  • Si vous avez besoin d’une stratégie de réplication sans perte de données, envisagez d’utiliser la configuration de réplication asynchrone.
  • En plus de Data Guard, d’autres options d’intégration incluent Striim, Qlik, GoldenGate ou Active Data Guard.

Sauvegarde et protection des données

  • Envisagez d’utiliser Sauvegarde Azure pour sauvegarder vos machines virtuelles d’application et de base de données.
  • Envisagez de placer vos sauvegardes dans une autre région que celle de votre région primaire pour fournir une protection supplémentaire contre les défaillances régionales.
  • Envisagez de sauvegarder la base de données à l’aide de composants de stockage qui ont des fonctionnalités de réplication intégrées.

Récupération d'urgence

Étape suivante

Principes de conception d’une charge de travail Oracle sur Azure