Modifier

Héberger une charge de travail Murex MX.3 sur Azure à l'aide d'Oracle sur Azure.

Pare-feu Azure
Azure ExpressRoute
Azure Key Vault
Stockage Azure
Azure Monitor

L’objectif de cet article est de fournir des détails techniques pour implémenter des charges de travail Murex dans Azure.

Architecture

Les charges de travail Murex MX.3 peuvent s’exécuter sur des bases de données telles qu’Oracle, Sybase ou SQL Server. Cette architecture se concentre sur les détails de l’implémentation de l’application MX.3 avec Oracle comme base de données.

Diagramme qui montre une architecture Azure pour une application Murex MX.3.

Téléchargez un fichier Visio de cette architecture.

Workflow

  • Accédez au composant de couche de présentation MX.3 de la couche Application hébergé dans Azure à l’aide d’une connexion Azure ExpressRoute ou VPN entre Azure et votre environnement local. La connexion est protégée à l’aide du Pare-feu Azure.
  • Accédez à la couche de présentation à l’aide de solutions VDI (Virtual Desktop Infrastructure), comme Citrix. Vous pouvez également accéder directement à la couche via une application de bureau ou à l’aide de l’interface web fournie par l’application MX.3.
  • La couche Application contient la couche de présentation, la couche métier, la couche d’orchestration et la couche de grille. Elle accède à la base de données Oracle pour stocker et récupérer des données.
  • La couche de présentation accède aux composants de la couche métier, de la couche d’orchestration et de la couche de grille pour effectuer le processus métier.
  • Pour fournir un accès plus rapide, la base de données Oracle utilise des disques SSD Premium Azure ou Azure NetApp Files comme mécanisme de stockage.
  • La couche Application accède aux services Azure Key Vault pour stocker les clés de chiffrement et les secrets de manière sécurisée.
  • Les utilisateurs administrateurs bénéficient d’un accès sécurisé aux serveurs Murex MX.3 en utilisant le service Azure Bastion.

Components

  • Azure Bastion : Azure Bastion est un service complètement managé qui offre un accès RDP (Remote Desktop Protocol) et SSH (Secure Shell Protocol) plus sécurisé et ininterrompu aux machines virtuelles sans aucune exposition via des adresses IP publiques.
  • Azure Monitor : Azure Monitor vous permet de collecter, d’analyser et d’exploiter les données de télémétrie de vos environnements Azure et locaux.
  • Pare-feu Azure : Le Pare-feu Azure est un service de sécurité de pare-feu réseau natif cloud intelligent qui offre la meilleure protection contre les menaces pour vos charges de travail cloud s’exécutant dans Azure.
  • Azure ExpressRoute : Utilisez Azure ExpressRoute pour créer des connexions privées entre les centres de données Azure et l’infrastructure d’environnement local ou de colocation.
  • Azure Files : Partages de fichiers complètement managés dans le cloud, accessibles via les protocoles SMB et NFS standard du secteur.
  • Azure Disk Storage : Le Stockage sur disque Azure est un stockage de bloc hautes performances durable destiné à vos applications stratégiques et critiques pour l’entreprise.
  • Azure Site Recovery : Déployez des processus de réplication, de basculement et de récupération grâce à Site Recovery pour assurer le fonctionnement de vos applications lors de pannes planifiées ou non planifiées.
  • Azure NetApp Files : Azure NetApp Files est un service de stockage de fichiers limité, hautes performances et de qualité professionnelle.
  • Azure Key Vault : Utilisez Azure Key Vault pour stocker des secrets et y accéder de manière sécurisée.
  • Passerelle VPN Azure  : La passerelle VPN Azure envoie du trafic chiffré entre un réseau virtuel Azure et un emplacement local via l’Internet public.
  • Azure Policy : Utilisez Azure Policy pour créer, affecter et gérer les définitions de stratégie dans votre environnement Azure.
  • Sauvegarde Azure : La Sauvegarde Azure est une solution de sauvegarde en un clic, économique et sécurisée qui est évolutive en fonction de vos besoins de stockage de sauvegarde.

Détails du scénario

Murex est un fournisseur de logiciels mondial majeur de solutions commerciales, de gestion des risques, des opérations de traitement et post-transactions pour les marchés financiers. De nombreuses banques déploient la plateforme de troisième génération MX.3 de Murex pour gérer les risques, accélérer la transformation et simplifier la conformité, tout en favorisant la croissance du chiffre d’affaires. La plateforme Murex permet aux clients de mieux contrôler leurs opérations, d’améliorer leur efficacité et de réduire les coûts opérationnels.

MX.3 est une application client/serveur basée sur une structure d’architecture à trois niveaux. Les banques utilisent MX.3 pour leurs besoins métier, comme les ventes et les transactions, la gestion des risques d’entreprise, ainsi que le nantissement et l’investissement.

Microsoft Azure fournit aux clients Murex un moyen rapide et facile de créer et de mettre à l’échelle une infrastructure MX.3. Azure permet un environnement sécurisé, fiable et efficace pour la production, le développement et les systèmes de test. Il réduit considérablement les coûts d’infrastructure nécessaires pour exploiter l’environnement MX.3.

Pour plus d’informations sur les différents niveaux et les différentes couches de l’application Murex MX.3, les exigences de calcul et les exigences de stockage, contactez l’équipe technique Murex.

Linux est une marque appartenant à la société à laquelle elle est associée. L’utilisation de cette marque n’implique aucune approbation de sa part.

Cas d’usage potentiels

Cette solution est idéale pour une utilisation dans le secteur financier. Voici quelques cas d’utilisation potentiels.

  • Contrôlez mieux les opérations, améliorez l’efficacité et réduisez les coûts d’infrastructure.
  • Créez un environnement sécurisé, fiable et efficace pour la production et le développement.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d'informations, consultez Microsoft Azure Well-Architected Framework.

Murex MX.3 est une charge de travail complexe avec des exigences de mémoire élevée, de faible latence et de haute disponibilité. Cette section décrit certaines des considérations techniques à analyser lors de l’implémentation d’une charge de travail Murex MX.3 dans Azure.

  • MX.3 utilise une architecture client/serveur. Lorsque vous l’implémentez dans Azure, vous devez suivre une architecture IaaS (Infrastructure as a Service). Analysez attentivement les services Azure natifs pour garantir qu’ils répondent aux exigences techniques de Murex.
  • Vous pouvez déployer complètement la solution MX.3 sur Azure, ou déployer un ensemble partiel de composants Azure à l’aide d’un modèle hybride. Cet article ne traite pas des modèles hybrides. Vous devez analyser attentivement les spécifications relatives à l’architecture et les exigences techniques avant d’utiliser un modèle hybride de déploiement. Les modèles hybrides de déploiement pour MX.3 sont soumis à un examen technique par l’équipe Murex.
  • Vous pouvez accéder directement au niveau client de MX.3 à partir du bureau de l’utilisateur ou via des solutions VDI comme Citrix.
  • Les charges de travail Murex MX.3 sur différents niveaux nécessitent des types spécifiques de ressources de calcul pour répondre aux spécifications fonctionnelles et techniques. Consultez l’architecture Murex MX.3 pour comprendre les exigences en matière de calcul, de mémoire et de stockage pour une charge de travail MX.3.
  • L’application MX.3 nécessite une connectivité externe (Internet) et interne (locale) pour effectuer des tâches. L’architecture Azure de l’application MX.3 doit prendre en charge un modèle de connectivité sécurisé pour s’intégrer aux services internes et externes. Utilisez un VPN de site à site Azure ou ExpressRoute (recommandé) pour vous connecter avec des services locaux.
  • Pour la sauvegarde, vous pouvez utiliser des services de sauvegarde natifs Azure combinés au stockage Azure. Utilisez ces services pour les sauvegardes quotidiennes, hebdomadaires ou mensuelles des machines virtuelles d’application ou toutes les autres exigences de sauvegarde/archivage spécifiques de la couche Application. Pour les exigences de base de données, utilisez la réplication native ou les outils de sauvegarde de base de données.
  • Pour obtenir une haute disponibilité et une résilience des solutions Murex sur Azure, vous devez exécuter chaque couche de la couche Application dans au moins deux machines virtuelles. Vous pouvez utiliser une configuration de groupe à haute disponibilité Azure pour obtenir une haute disponibilité sur plusieurs machines virtuelles. Vous pouvez également utiliser Azure Virtual Machine Scale Sets pour la redondance et des performances améliorées des applications qui sont distribuées sur plusieurs instances. Vous pouvez obtenir la haute disponibilité pour la couche d’orchestration en les hébergeant dans plusieurs instances et en appelant les instances à l’aide de scripts personnalisés. Vous pouvez utiliser des fonctionnalités de haute disponibilité de base de données telles qu’Oracle Data Guard ou SQL Server Always On pour satisfaire les exigences de haute disponibilité.
  • Pour obtenir les métriques de performances requises pour les charges de travail Murex, envisagez de stocker le répertoire et les bases de données de l’application MX.3 sur des disques managés Azure avec SSD Premium. En cas de nombreuses opérations d’entrée/sortie par seconde et d’exigences de faible latence, vous pouvez utiliser Azure NetApp Files comme option de stockage. Vous pouvez utiliser un groupe de placement de proximité et une accélération réseau dans Azure pour obtenir un débit réseau élevé entre les couches.
  • Vous pouvez utiliser Azure Monitor pour superviser les composants d’infrastructure Azure. Vous pouvez utiliser son mécanisme d’alerte pour effectuer des actions préventives telles que la mise à l’échelle automatique ou la notification.
  • Utilisez des services comme Azure Key Vault pour répondre aux exigences de sécurité de l’application MX.3 dans Azure en stockant des clés et des certificats. Vous pouvez utiliser des réseaux virtuels Azure, des groupes de sécurité réseau (NSG) et des groupes de sécurité d’application pour contrôler l’accès entre différentes couches et différents niveaux. Vous pouvez utiliser le Pare-feu Azure, la protection DDoS et les services Azure Application Gateway ou Web Application Firewall pour protéger la couche front-end en fonction des exigences de sécurité.
  • Vous pouvez obtenir une automatisation de l’infrastructure à l’aide de services d’Infrastructure en tant que code (IaC, Infrastructure as Code), tels que des modèles Azure Resource Manager ou des scripts Terraform. Vous pouvez utiliser les outils Murex DevOps pour répondre aux exigences DevOps au niveau de l’application.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

  • Toutes les couches de la couche Application sont hébergées dans au moins deux machines virtuelles ou groupes de machines virtuelles identiques au sein de chaque zone de disponibilité pour prendre en charge une résilience élevée.
  • Les couches métier et de grille de la couche Application sont hébergées sur des groupes de machines virtuelles identiques. Ces groupes identiques prennent en charge la mise à l’échelle automatique des machines virtuelles en fonction des conditions préconfigurées.
  • Pour les couches d’orchestration, les serveurs peuvent être distribués entre différentes machines virtuelles, si nécessaire. En cas de problèmes avec l’une des machines virtuelles, vous pouvez configurer des scripts d’automatisation (modèle Resource Manager ou Terraform) et des notifications d’alerte pour provisionner automatiquement davantage de machines virtuelles.
  • Pour le niveau de persistance, vous pouvez obtenir une haute disponibilité de la base de données Oracle via une solution Oracle Data Guard. Dans cette solution, plusieurs machines virtuelles s’exécutent sur des zones de disponibilité avec la réplication active configurée entre elles.
  • Pour la couche Application, les machines virtuelles redondantes sont hébergées pour chacune des couches. En cas de sinistre dans l’une des machines virtuelles, Azure garantit qu’une autre instance de la machine virtuelle est automatiquement provisionnée pour prendre en charge le niveau de reprise d’activité requis.
  • Pour la reprise d’activité, vous devez exécuter le site de reprise d’activité d’une autre région Azure. Vous pouvez utiliser des configurations de reprise d’activité actives/actives ou actives/passives en fonction de l’objectif de point de récupération et des exigences de l’objectif de temps de récupération. Vous pouvez utiliser Site Recovery pour automatiser le processus de reprise d’activité et la réplication de base de données native. Vous pouvez également utiliser des outils de sauvegarde pour atteindre le niveau requis de métriques RPO.
  • Pour le niveau de persistance, vous devez configurer Oracle DataGuard avec des performances maximales (validation synchrone) afin d’éviter tout impact sur MX.3. Les instances de base de données Oracle entre les zones de disponibilité garantissent que l’application est récupérée avec une perte de données minimale.
  • En cas de défaillance d’une région, vous pouvez utiliser des scripts d’automatisation (Resource Manager ou Terraform) ou des services Site Recovery pour provisionner rapidement l’environnement dans une région Azure appairée.
  • En fonction des exigences de l’objectif de point de récupération, vous pouvez utiliser des solutions de sauvegarde Oracle natives telles que Recovery Manager (RMAN) pour sauvegarder régulièrement la base de données et la restaurer.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

  • Vous pouvez utiliser le Pare-feu Azure pour protéger le réseau virtuel MX.3. Il est utile dans des renseignements sur les menaces et le contrôle du trafic entrant vers la couche de présentation et du trafic sortant de la couche Application vers Internet.
  • L’utilisation de groupes de sécurité réseau dans le sous-réseau d’application et le sous-réseau de base de données d’une application MX.3 permet de contrôler le trafic réseau entrant et sortant de la couche de base de données, métier et d’orchestration.
  • Vous pouvez utiliser le service Azure Key Vault pour stocker de manière sécurisée toutes les informations sensibles et tous les certificats.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

  • Vous pouvez héberger des ressources d’infrastructure pour des solutions VDI comme Citrix dans Azure. Le niveau client utilise des solutions VDI pour accéder à la couche Application, et optimiser le coût global et les performances de la solution.
  • Pour le calcul, utilisez les réservations Azure et le plan d’économies Azure pour le calcul et réalisez des économies significatives sur les tarifs du paiement à l’utilisation.

Vous pouvez utiliser la calculatrice de prix Azure pour estimer les coûts.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.

  • Vous pouvez utiliser Azure Monitor pour superviser la plateforme et utiliser les journaux Azure Monitor pour superviser l’application. Toutefois, vous pouvez également configurer votre propre outil personnalisé pour superviser la plateforme et l’application, si nécessaire.
  • Vous pouvez utiliser l’identification des ressources pour étiqueter les ressources et étendre le monitoring des alertes et des notifications à l’aide de l’intégration effective d’un système de gestion des services informatiques.
  • Vous pouvez utiliser des outils IaC tels que des modèles Resource Manager ou des scripts Terraform pour automatiser le processus de provisionnement d’infrastructure. Vous pouvez utiliser des outils Azure DevOps pour intégrer des outils IaC à la chaîne d’outils Murex DevOps.
  • Vous pouvez utiliser des stratégies Azure pour codifier les exigences de sécurité ou de conformité, et valider l’environnement Azure concernant les exigences d’audit et de conformité.

Vous pouvez provisionner les machines virtuelles dans la couche d’orchestration de la couche Application à l’aide de scripts personnalisés.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.

  • Vous pouvez obtenir un débit de stockage élevé pour un serveur de base de données à l’aide du stockage Azure NetApp Files Ultra afin d’héberger la base de données Oracle. Toutefois, vous pouvez également utiliser une machine virtuelle Azure avec un disque managé pour réduire le débit de stockage comme un stockage SSD Premium.
  • Pour les scénarios de faible latence, utilisez des groupes de placement de proximité Azure entre la couche Application et le niveau de persistance.
  • Pour améliorer les performances et la fiabilité, utilisez ExpressRoute pour vous connecter à un système local.
  • Vous pouvez utiliser Azure Files pour stocker des fichiers utilisés par la couche Application de MX.3, comme les fichiers de configuration, les fichiers journaux et les fichiers binaires.

Modèle Hub-and-spoke du réseau

Lorsque vous implémentez des charges de travail MX.3 dans Azure, la définition de l’architecture de zone d’atterrissage est un élément clé à prendre en compte. Cette architecture contient l’abonnement, le groupe de ressources, l’isolement du réseau virtuel et la connectivité entre différents composants de la solution. Cette section décrit l’architecture de zone d’atterrissage pour implémenter une charge de travail MX.3 sur Azure, en fonction de Microsoft Cloud Adoption Framework.

Le diagramme ci-dessous montre une vue d’ensemble d’une zone d’atterrissage qui utilise la topologie réseau hub-and-spoke dans Azure.

Diagramme montrant un exemple de modèle hub-and-spoke avec un service Azure.

  • L’utilisation de ce modèle permet une isolation forte des réseaux spoke utilisés pour exécuter différents environnements. Le modèle tient également à jour l’accès avec contrôle sécurisé et une couche de service partagé dans le réseau hub.
  • Vous pouvez utiliser le même modèle hub-and-spoke dans une autre région car il s’agit d’une solution multirégion. Vous pouvez générer un hub pour chaque région, suivi de différents spokes pour les scénarios hors production et de production.
  • Vous pouvez utiliser cette zone d’atterrissage pour un seul abonnement ou plusieurs abonnements en fonction de la façon dont votre organisation classe vos applications.

Chaque composant de la zone d’atterrissage est décrit ci-dessous.

Hub : Le hub est un réseau virtuel qui agit comme un emplacement central pour gérer la connectivité externe au réseau local d’un client MX.3 et les services d’hébergement utilisés par plusieurs charges de travail.

Spoke : Les spokes sont des réseaux virtuels qui hébergent des charges de travail Azure de MX.3 et se connectent au hub central à l’aide du peering de réseaux virtuels.

Peering de réseaux virtuels : Les réseaux virtuels hub-and-spoke sont connectés à l’aide du peering de réseaux virtuels, qui prend en charge les connexions à faible latence entre les réseaux virtuels.

Passerelle : Une passerelle est utilisée pour envoyer du trafic à partir du réseau local d’un client MX.3 vers le réseau virtuel Azure. Vous pouvez chiffrer le trafic avant qu’il ne soit envoyé.

Sous-réseau de passerelle : La passerelle qui envoie le trafic local à Azure utilise un sous-réseau spécifique appelé sous-réseau de passerelle. Le sous-réseau de passerelle fait partie de la plage d’adresses IP du réseau virtuel que vous spécifiez lors de la configuration de votre réseau virtuel. Il contient les adresses IP utilisées par les ressources et les services de passerelle de réseau virtuel.

Machine virtuelle Azure Jumpbox : Jumpbox connecte des machines virtuelles Azure de la couche Application et le niveau de persistance à l’aide d’une adresse IP dynamique. Jumpbox empêche toutes les machines virtuelles d’application et de base de données d’être exposées au public. Cette connexion est votre point d’entrée pour vous connecter via un accès RDP à partir du réseau local.

Pare-feu Azure : Vous devez router toute connectivité entrante et sortante entre des machines virtuelles MX.3 et Internet via le Pare-feu Azure. Les synchronisations horaires et les mises à jour des définitions de l’antivirus sont des exemples classiques de cette connectivité.

Azure Bastion : À l’aide d’Azure Bastion, vous pouvez connecter l’application et les machines virtuelles de base de données de manière sécurisée via le portail Azure. Déployez l’hôte Azure Bastion à l’intérieur du réseau virtuel hub, puis accédez aux machines virtuelles dans les réseaux virtuels spoke appairés. Ce composant est facultatif et vous pouvez l’utiliser en fonction des besoins.

Sous-réseau Azure Bastion : Azure Bastion nécessite un sous-réseau dédié : AzureBastionSubnet. Vous devez créer ce sous-réseau dans le hub et déployer l’hôte Bastion dans ce sous-réseau.

Sous-réseau de gestion Azure : Azure Jumpbox doit se trouver dans le sous-réseau de gestion. Jumpbox contient des machines virtuelles qui implémentent des fonctionnalités de gestion et de monitoring pour les machines virtuelles d’application et de base de données dans le réseau virtuel spoke.

Sous-réseau d’application : Vous pouvez placer tous les composants sous la couche Application ici. La présence d’un sous-réseau d’applications dédié permet également de contrôler le trafic vers les couches métier, d’orchestration et de services techniques via des groupes de sécurité réseau.

Sous-réseau de base de données : Vous pouvez placer les composants présents dans le sous-réseau de base de données dans un sous-réseau dédié pour gérer le trafic autour de la base de données.

Private Link : Les services Azure tels que les coffres Recovery Services, Azure Cache pour Redis et Azure Files sont tous connectés via une liaison privée au réseau virtuel. Une liaison privée entre ces services et le réseau virtuel sécurise la connexion entre les points de terminaison dans Azure en éliminant l’exposition des données à Internet.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

Autres contributeurs :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes