Édition

Share via

Héberger une charge de travail Murex MX.3 à l'aide de SQL

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 Microsoft Azure.

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.

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. Avec la version V3.1.48, SQL Server 2019 Standard est pris en charge pour MX.3, ce qui vous permet de bénéficier des performances, de l'extensibilité, de la résilience et des économies de coûts offertes par SQL Server. MX.3 est disponible uniquement sur les machines virtuelles Azure exécutant le système d’exploitation Windows.

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

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

Workflow

  • La couche de présentation MX.3 est hébergée dans Azure et est accessible à partir d’un environnement local via ExpressRoute ou un VPN site à site.
  • 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 à SQL Server sur une machine virtuelle Windows pour stocker et récupérer des données. Pour renforcer la sécurité, nous vous recommandons d’utiliser Azure Virtual Desktop ou Windows 365 Cloud PC exécutant une application de bureau pour accéder à la couche de présentation. Toutefois, vous pouvez également y accéder via une interface web.
  • 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.
  • 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.

Composants

  • Azure Bastion : il s'agit d'un service complètement managé qui offre un accès RDP (Remote Desktop Protocol) et SSH (Secure Shell Protocol) plus sécurisé et transparent 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 : pour assurer le fonctionnement de vos applications lors de pannes planifiées ou non planifiées, déployez des processus de réplication, de basculement et de récupération grâce à Site Recovery.
  • SQL Server sur les machines virtuelles Windows : SQL Server sur les machines virtuelles Azure vous permet d’utiliser des versions complètes de SQL Server dans le cloud sans devoir gérer du matériel local. Les machines virtuelles SQL Server simplifient également les coûts de licence lorsque vous payez à l’utilisation.
  • 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.

Autres solutions

En guise de solution alternative, vous pouvez utiliser Murex MX.3 avec Oracle comme base de données au lieu de SQL. Pour plus d’informations, consultez Héberger une charge de travail Murex MX.3 sur Azure.

Détails du scénario

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.

Azure fournit un moyen rapide et facile de créer et de mettre à l’échelle une infrastructure MX.3. Il offre un environnement sécurisé, fiable et efficace pour les systèmes de production, de développement et de test, et réduit considérablement le coût d’infrastructure nécessaire 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.

Cas d’usage potentiels

Cette solution est idéale pour le secteur financier, comme par exemple :

  • 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.

Exigences et limitations

Murex MX.3 est une charge de travail complexe avec des exigences de mémoire élevée, de faible latence et de haute disponibilité. Voici quelques-unes des limitations et exigences techniques à prendre en compte lors de l’implémentation d’une charge de travail Murex MX.3 dans Azure.

  • MX.3 utilise une architecture client/serveur. En cas d’implémentation dans Azure, il peut être exécuté sur des machines virtuelles et aucun service PaaS n’est pris en charge pour l’application. Analysez attentivement les services Azure natifs pour garantir qu’ils répondent aux exigences techniques de Murex.
  • 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.
  • 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 (possibilité non abordée dans cet article). 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.

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.

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é.

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 spécifiques de la couche Application. Pour des exigences de base de données, 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 obtenir une haute disponibilité et une résilience de la solution Murex sur Azure, exécutez 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. Pour satisfaire les exigences de haute disponibilité, utilisez des fonctionnalités de haute disponibilité de base de données telles que le groupe de disponibilité SQL Server Always On.

Le groupe de disponibilité SQL Server Always On peut être utilisé pour automatiser le basculement de reprise d’activité en configurant une instance SQL Server principale et une ou plusieurs instances secondaires. Configurez la fonctionnalité de groupe de disponibilité Always On pour chaque instance de serveur.

MX.3 nécessite que DTC soit activé dans SQL Server. Nous vous recommandons d’héberger SQL Server sur des machines virtuelles Windows Server pour prendre en charge les transactions DTC, car la prise en charge de DTC n’est pas encore disponible dans SQL Server sur le système d’exploitation RedHat Linux pour le groupe de disponibilité SQL Server Always On.

Pour la reprise d’activité, vous devez exécuter le site de reprise d’activité d’une autre région Azure. Pour SQL Server, vous pouvez utiliser des configurations de reprise d’activité 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. Les configurations actives/actives ne sont pas une option avec SQL Server, car les écritures multirégions ne sont pas possibles. La perte de données en raison de la latence et du calendrier des sauvegardes doit être prise en compte. 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.

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.

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é.

Accédez au niveau client MX.3 directement à partir du bureau utilisateur ou via des solutions de bureau virtuel telles qu’Azure Virtual Desktop, des PC Cloud Windows 365 ou d’autres solutions autres que Microsoft.

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, 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. Utilisez 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é.

Consultez les fonctionnalités et capacités SQL Server qui offrent une méthode de sécurité au niveau des données. En outre, grâce aux mesures de sécurité d’Azure, il est possible de chiffrer vos données sensibles, de protéger les machines virtuelles contre les virus et les logiciels malveillants, de sécuriser le trafic réseau, d’identifier et de détecter les menaces, de répondre aux exigences de conformité et de fournir une méthode unique d’administration et de création de rapports pour tout besoin de sécurité dans le cloud hybride. Pour plus d’informations sur ces considérations de sécurité, consultez Considérations relatives à la sécurité de SQL Server sur les machines virtuelles Azure.

Pour plus d’informations sur les meilleures pratiques relatives aux machines virtuelles SQL Server, consultez les autres articles de cette série :

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.

Azure Hybrid Benefit vous permet d’échanger vos licences existantes contre des tarifs avantageux sur Azure SQL Database et Azure SQL Instance gérée. Vous pouvez économiser jusqu’à 30 % ou plus sur une instance gérée SQL Database et SQL à l’aide de vos licences de gestion SQL Server Software Assurance sur Azure. La page Azure Hybrid Benefit comporte une calculatrice pour vous aider à déterminer les économies réalisées.

Plusieurs facteurs peuvent avoir un impact sur le coût, et il est important de choisir la référence de machine virtuelle qui offre le bon équilibre entre les coûts et les besoins de l’entreprise.

Virtual Machine Scale Sets peut augmenter automatiquement le nombre d’instances de machines virtuelles à mesure que la demande d’application augmente, et réduire le nombre d’instances de machines virtuelles à mesure que la demande diminue.

La mise à l’échelle automatique réduit également le nombre d’instances de machines virtuelles inutiles qui exécutent votre application lorsque la demande est faible. Les clients continuent de bénéficier d’un niveau de performances acceptable à mesure que la demande augmente et que des instances de machines virtuelles supplémentaires sont ajoutées automatiquement. Cette capacité permet de réduire les coûts et de créer efficacement des ressources Azure en fonction des besoins.

Pour en savoir plus sur la tarification, consultez l’article Conseils de tarification pour SQL Server sur les machines virtuelles Azure. Vous pouvez également utiliser la calculatrice de prix Azure pour estimer vos 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.

Utilisez Azure Monitor pour superviser les composants d’infrastructure Azure. Son mécanisme d’alerte vous permet d'effectuer des actions préventives telles que la mise à l’échelle automatique ou la notification.

Vous pouvez obtenir une automatisation de l’infrastructure à l’aide de services d’Infrastructure en tant que code (IaC), tels que des modèles Azure Resource Manager ou des scripts Terraform.

Azure DevOps vous permet de déployer Azure SQL Server avec n’importe quel IaC pris en charge, tel que Terraform. Vous pouvez utiliser les outils Murex DevOps pour répondre aux exigences DevOps au niveau de l’application. Contactez directement Murex pour obtenir des conseils sur cette approche.

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.

Le fait d'avoir des charges de travail Murex MX.3 sur différents niveaux nécessite 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.

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. 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.

Utilisez le stockage Premium ou Ultra SSD pour SQL sur une machine virtuelle Azure. Pour plus d’informations sur le SSD Premium, consultez l'article Instructions pour la configuration du stockage pour SQL Server sur une machine virtuelle Azure.

D’autre part, SSD Ultra est une autre offre de stockage disponible sur Azure pour les charges de travail stratégiques avec des latences inférieures à une milliseconde à haut débit. Avec Ultra SSD, nous n’avons besoin que d’un seul disque SSD Ultra de 1 To, ce qui permet d'effectuer un scale-up jusqu’à 50 000 IOPS. Le SSD Ultra peut être configuré de manière flexible, et la taille et les IOPS peuvent être mis à l’échelle indépendamment. Pour plus d’informations sur le SSD Ultra, consultez l'article Performances stratégiques avec SSD Ultra pour SQL Server sur une machine virtuelle Azure | Blog Azure | Microsoft Azure.

L'article Liste de vérification : Meilleures pratiques relatives à SQL Server sur les machines virtuelles Azure fournit une check-list rapide des bonnes pratiques et des recommandations pour optimiser les performances de votre serveur SQL Server sur des machines virtuelles Azure. Pour en savoir plus sur les meilleures pratiques en matière de machines virtuelles SQL Server, consultez les autres articles de cette série :

Activez la fonctionnalité SQL Assessment pour SQL Server sur des machines virtuelles Azure pour évaluer votre serveur SQL Server par rapport aux meilleures pratiques connues et consultez les résultats sur la page de gestion des machines virtuelles SQL du portail Azure.

Si vous utilisez Virtual Machine Scale Sets, vous pouvez effectuer un scale-out et créer des machines virtuelles supplémentaires pour répondre à la demande de calcul de la couche métier. Toutefois, pour Murex MX.3, il doit être effectué sans mettre fin aux sessions actives. Les clients Murex MX.3 peuvent contacter leurs ingénieurs de support produit pour connaître les stratégies possibles pour effectuer une mise à l’échelle sécurisée des machines virtuelles.

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.

Ce diagramme 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.

  • Ce modèle fournit 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.
  • Utilisez 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 ici :

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 de l'envoyer.

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.

Principaux auteurs :

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

Étapes suivantes