Modifica

Ospitare un carico di lavoro Murex MX.3 in Azure con Oracle

Firewall di Azure
Azure ExpressRoute
Insieme di credenziali chiave di Azure
Archiviazione di Azure
Monitoraggio di Azure

L'obiettivo di questo articolo è fornire dettagli tecnici per implementare carichi di lavoro Murex in Azure.

Architettura

I carichi di lavoro Murex MX.3 possono essere eseguiti in database come Oracle, Sybase o SQL Server. Questa architettura è incentrata sui dettagli per l'implementazione dell'applicazione MX.3 usando Oracle come database.

Diagramma che mostra un'architettura di Azure per un'applicazione Murex MX.3.

Scaricare un file di Visio di questa architettura.

Workflow

  • Accedere al componente del livello presentazione MX.3 del livello applicazione ospitato in Azure usando una connessione Azure ExpressRoute o VPN tra Azure e l'ambiente locale. La connessione è protetta tramite Firewall di Azure.
  • Accedere al livello di presentazione usando soluzioni VDI (Virtual Desktop Infrastructure), ad esempio Citrix. È anche possibile accedere direttamente al livello tramite un'applicazione desktop o usando l'interfaccia Web fornita dall'applicazione MX.3.
  • Il livello applicazione contiene il livello presentazione, il livello business, il livello di orchestrazione e il livello griglia. Accede al database Oracle per l'archiviazione e il recupero dei dati.
  • Il livello presentazione accede ai componenti del livello business, del livello di orchestrazione e del livello griglia per completare il processo aziendale.
  • Il database Oracle usa l'unità SSD Premium di Azure o Azure NetApp Files come meccanismo di archiviazione per un accesso più rapido.
  • Il livello dell'applicazione accede ai servizi di Azure Key Vault per archiviare in modo sicuro chiavi di crittografia e segreti.
  • Amministrazione gli utenti accedono in modo sicuro ai server Murex MX.3 usando il servizio Azure Bastion.

Componenti

  • Azure Bastion: Azure Bastion è un servizio completamente gestito che offre un accesso RDP (Remote Desktop Protocol) e SSH (Secure Shell Protocol) più sicuro e trasparente alle macchine virtuali senza alcuna esposizione tramite indirizzi IP pubblici.
  • Monitoraggio di Azure: Monitoraggio di Azure consente di raccogliere, analizzare e agire sui dati di telemetria dagli ambienti Azure e locali.
  • Firewall di Azure: Firewall di Azure è un servizio di sicurezza del firewall di rete intelligente e nativo del cloud che offre la migliore protezione dalle minacce per i carichi di lavoro cloud in esecuzione in Azure.
  • Azure ExpressRoute: usare Azure ExpressRoute per creare connessioni private tra i data center di Azure e l'infrastruttura in locale o in un ambiente di condivisione.
  • File di Azure: condivisioni file completamente gestite nel cloud accessibili tramite i protocolli SMB e NFS standard del settore.
  • Azure Disk Archiviazione: Azure Disk Archiviazione offre un'archiviazione a blocchi durevole e a prestazioni elevate per le applicazioni cruciali e aziendali.
  • Azure Site Recovery: distribuire processi di replica, failover e ripristino tramite Site Recovery per mantenere le applicazioni in esecuzione durante interruzioni pianificate e non pianificate.
  • Azure NetApp Files: Azure NetApp Files è un servizio di archiviazione file a consumo di livello aziendale e ad alte prestazioni.
  • Azure Key Vault: usare Azure Key Vault per archiviare e accedere in modo sicuro ai segreti.
  • Azure Gateway VPN: Gateway VPN invia traffico crittografato tra una rete virtuale di Azure e una posizione locale tramite Internet pubblico.
  • Criteri di Azure: usare Criteri di Azure per creare, assegnare e gestire definizioni di criteri nell'ambiente Azure.
  • Backup di Azure: Backup di Azure è una soluzione di backup conveniente e sicura con un clic scalabile in base alle esigenze di archiviazione di backup.

Dettagli dello scenario

Murex è un fornitore globale di software di trading, gestione dei rischi, operazioni di elaborazione e soluzioni post-trade per i mercati dei capitali. Molte banche distribuiscono la piattaforma MX.3 di terza generazione di Murex per gestire i rischi, accelerare la trasformazione e semplificare la conformità, tutto mentre guida la crescita dei ricavi. La piattaforma Murex consente ai clienti di ottenere un maggiore controllo delle proprie operazioni, migliorare l'efficienza e ridurre i costi operativi.

MX.3 è un'applicazione client/server basata su una struttura di architettura a tre livelli. Le banche usano MX.3 per i requisiti aziendali, ad esempio vendite e trading, gestione dei rischi aziendali e collaterali e investimenti.

Microsoft Azure offre ai clienti Murex un modo rapido e semplice per creare e ridimensionare un'infrastruttura MX.3. Azure consente un ambiente sicuro, affidabile ed efficiente per sistemi di produzione, sviluppo e test. Riduce significativamente il costo dell'infrastruttura necessario per gestire l'ambiente MX.3.

Per informazioni dettagliate sui vari livelli e livelli dell'applicazione Murex MX.3, sui requisiti di calcolo e archiviazione, contattare il team tecnico murex.

Linux è un marchio della rispettiva società. Nessuna verifica dell'autenticità è implicita nell'uso di questo marchio.

Potenziali casi d'uso

Questa soluzione è ideale per l'uso nel settore finanziario. Di seguito sono riportati alcuni casi d'uso potenziali.

  • Ottenere un migliore controllo delle operazioni, migliorare l'efficienza e ridurre i costi dell'infrastruttura.
  • Creare un ambiente sicuro, affidabile ed efficiente per la produzione e lo sviluppo.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Framework ben progettato di Microsoft Azure.

Murex MX.3 è un carico di lavoro complesso con memoria elevata, bassa latenza e requisiti di disponibilità elevata. Questa sezione descrive alcune considerazioni tecniche da analizzare durante l'implementazione di un carico di lavoro Murex MX.3 in Azure.

  • MX.3 usa un'architettura client/server. Quando viene implementato in Azure, è necessario seguire un'architettura IaaS (Infrastructure as a Service). Analizzare attentamente tutti i servizi nativi di Azure per assicurarsi che soddisfino i requisiti tecnici per Murex.
  • È possibile distribuire completamente la soluzione MX.3 in Azure oppure distribuire un set parziale di componenti di Azure usando un modello ibrido. Questo articolo non tratta i modelli ibridi. È consigliabile analizzare attentamente l'architettura e i requisiti tecnici prima di usare un modello ibrido di distribuzione. I modelli ibridi di distribuzione per MX.3 sono soggetti a una revisione tecnica del team Murex.
  • È possibile accedere al livello client MX.3 direttamente dal desktop dell'utente o tramite soluzioni VDI come Citrix.
  • I carichi di lavoro Murex MX.3 in vari livelli richiedono tipi specifici di risorse di calcolo per soddisfare i requisiti funzionali e tecnici. Vedere l'architettura Murex MX.3 per comprendere i requisiti di calcolo, memoria e archiviazione per un carico di lavoro MX.3.
  • L'applicazione MX.3 richiede connettività esterna (Internet) e interna (locale) per eseguire attività. L'architettura di Azure per l'applicazione MX.3 deve supportare un modello di connettività sicura per l'integrazione con servizi interni ed esterni. Usare una VPN da sito a sito di Azure o ExpressRoute (scelta consigliata) per connettersi ai servizi locali.
  • Per il backup, è possibile usare i servizi di backup nativi di Azure combinati con Archiviazione di Azure. Usare questi servizi per backup giornalieri, settimanali o mensili delle macchine virtuali dell'applicazione o per altri requisiti di backup/archiviazione specifici del livello applicazione. Per i requisiti del database, usare la replica nativa del database o gli strumenti di backup.
  • Per ottenere disponibilità elevata e resilienza delle soluzioni Murex in Azure, è necessario eseguire ogni livello del livello applicazione in almeno due macchine virtuali. È possibile usare una configurazione del set di disponibilità di Azure per ottenere disponibilità elevata tra più macchine virtuali. È anche possibile usare Azure set di scalabilità di macchine virtuali per la ridondanza e migliorare le prestazioni delle applicazioni distribuite tra più istanze. È possibile ottenere disponibilità elevata per il livello di orchestrazione ospitandoli in più istanze e richiamando le istanze usando script personalizzati. È possibile usare le funzionalità di disponibilità elevata del database, ad esempio Oracle Data Guard o SQL Server AlwaysOn, per soddisfare i requisiti di disponibilità elevata.
  • Per ottenere le metriche delle prestazioni necessarie per i carichi di lavoro Murex, è consigliabile archiviare la directory e i database dell'applicazione MX.3 in Managed Disks di Azure con unità SSD Premium. Per operazioni di input/output elevate al secondo e requisiti di bassa latenza, è possibile usare Azure NetApp Files come opzione di archiviazione. È possibile usare un gruppo di posizionamento di prossimità e l'accelerazione di rete in Azure per ottenere una velocità effettiva di rete elevata tra i livelli.
  • È possibile usare Monitoraggio di Azure per monitorare i componenti dell'infrastruttura di Azure. È possibile usare il meccanismo di avviso per eseguire qualsiasi azione preventiva, ad esempio il ridimensionamento automatico o la notifica.
  • Usare servizi come Azure Key Vault per soddisfare i requisiti di sicurezza dell'applicazione MX.3 in Azure archiviando chiavi e certificati. È possibile usare reti virtuali di Azure, gruppi di sicurezza di rete e gruppi di sicurezza delle applicazioni per controllare l'accesso tra diversi livelli e livelli. È possibile usare Firewall di Azure, protezione DDoS e app Azure lication Gateway o servizi web application firewall per proteggere il livello front-end a seconda dei requisiti di sicurezza.
  • È possibile ottenere l'automazione dell'infrastruttura usando servizi IaC (Infrastructure as Code), ad esempio modelli di Azure Resource Manager o script Terraform. È possibile usare gli strumenti Murex DevOps per soddisfare i requisiti devOps a livello di applicazione.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Panoramica del pilastro dell'affidabilità.

  • Tutti i livelli del livello applicazione sono ospitati in almeno due macchine virtuali o set di scalabilità di macchine virtuali all'interno di ogni zona di disponibilità per supportare la resilienza elevata.
  • I livelli business e grid del livello applicazione sono ospitati in set di scalabilità di macchine virtuali. Questi set di scalabilità supportano la scalabilità automatica delle macchine virtuali in base alle condizioni preconfigurati.
  • Per i livelli di orchestrazione, i server possono essere distribuiti tra macchine virtuali diverse, se necessario. Se si verificano problemi con una delle macchine virtuali, è possibile configurare script di automazione (modello di Resource Manager o Terraform) e notifiche di avviso per effettuare automaticamente il provisioning di più macchine virtuali.
  • Per il livello di persistenza, è possibile ottenere una disponibilità elevata del database Oracle tramite una soluzione Oracle Data Guard. In questa soluzione più macchine virtuali vengono eseguite tra le zone di disponibilità con la replica attiva configurata tra di esse.
  • Per il livello applicazione, le macchine virtuali ridondanti sono ospitate per ognuno dei livelli. Se si verifica un'emergenza in una delle macchine virtuali, Azure garantisce che venga eseguito automaticamente il provisioning di un'altra istanza della macchina virtuale per supportare il livello di ripristino di emergenza richiesto.
  • Per il ripristino di emergenza, è necessario eseguire il sito di ripristino di emergenza in un'area di Azure diversa. È possibile usare configurazioni di ripristino di emergenza attivo/attivo/attivo/passivo in base ai requisiti dell'obiettivo del punto di ripristino e del tempo di ripristino. È possibile usare Site Recovery per automatizzare il processo di ripristino di emergenza e la replica nativa del database. È anche possibile usare gli strumenti di backup per ottenere il livello richiesto di metriche RPO.
  • Per il livello di persistenza, è necessario configurare Oracle DataGuard con prestazioni massime (commit sincrono) per evitare qualsiasi impatto su MX.3. Le istanze di database Oracle tra zone di disponibilità assicurano che l'applicazione venga ripristinata con una perdita minima di dati.
  • In caso di errore dell'area, è possibile usare script di automazione (Resource Manager o Terraform) o servizi di Site Recovery per effettuare rapidamente il provisioning dell'ambiente in un'area di Azure abbinata.
  • A seconda dei requisiti dell'obiettivo del punto di ripristino, è possibile usare soluzioni di backup Oracle native come Gestione ripristino (RMAN) per eseguire periodicamente il backup del database e ripristinarlo.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Panoramica del pilastro della sicurezza.

  • È possibile usare Firewall di Azure per proteggere la rete virtuale MX.3. Consente di intelligence sulle minacce e di controllare il traffico in ingresso al livello di presentazione e al traffico in uscita dal livello applicazione a Internet.
  • La presenza di gruppi di sicurezza di rete nella subnet dell'applicazione e nella subnet del database in un'applicazione MX.3 può fornire il controllo sul traffico di rete in ingresso e in uscita dal database, dall'azienda e dal livello di orchestrazione.
  • È possibile usare il servizio Azure Key Vault per archiviare in modo sicuro eventuali informazioni e certificati sensibili.

Ottimizzazione dei costi

L'ottimizzazione dei costi riguarda l'analisi dei modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Panoramica del pilastro di ottimizzazione dei costi.

  • È possibile ospitare le risorse dell'infrastruttura per soluzioni VDI come Citrix in Azure. Il livello client usa soluzioni VDI per accedere al livello applicazione e ottimizzare il costo complessivo e le prestazioni della soluzione.
  • Per il calcolo, usare prenotazioni di Azure e piano di risparmio di Azure per il calcolo e ottenere risparmi significativi sui prezzi con pagamento in base al consumo.

È possibile usare il calcolatore prezzi di Azure per stimare i costi.

Eccellenza operativa

L'eccellenza operativa copre i processi operativi che distribuiscono un'applicazione e la mantengono in esecuzione nell'ambiente di produzione. Per altre informazioni, vedere Panoramica del pilastro dell'eccellenza operativa.

  • È possibile usare Monitoraggio di Azure per monitorare la piattaforma e usare i log di Monitoraggio di Azure per monitorare l'applicazione. Tuttavia, è anche possibile configurare uno strumento personalizzato per monitorare la piattaforma e l'applicazione, se necessario.
  • È possibile usare l'assegnazione di tag alle risorse per etichettare le risorse ed estendere il monitoraggio degli avvisi e delle notifiche usando l'integrazione efficace di un sistema di gestione dei servizi IT.
  • È possibile usare strumenti IaC come modelli di Resource Manager o script Terraform per automatizzare il processo di provisioning dell'infrastruttura. È possibile usare gli strumenti di Azure DevOps per integrare gli strumenti IaC con la catena di strumenti Murex DevOps.
  • È possibile usare i criteri di Azure per codificare i requisiti di sicurezza o conformità e per convalidare l'ambiente di Azure per i requisiti di controllo e conformità.

È possibile effettuare il provisioning delle macchine virtuali nel livello di orchestrazione del livello applicazione usando script personalizzati.

Efficienza prestazionale

L'efficienza delle prestazioni è la capacità di dimensionare il carico di lavoro per soddisfare in modo efficiente le richieste poste dagli utenti. Per altre informazioni, vedere Panoramica dell'efficienza delle prestazioni.

  • È possibile ottenere una velocità effettiva di archiviazione elevata per un server di database usando l'archiviazione Ultra di Azure NetApp Files per ospitare il database Oracle. Tuttavia, è anche possibile usare una macchina virtuale di Azure con un disco gestito per ridurre la velocità effettiva di archiviazione, ad esempio l'archiviazione SSD Premium.
  • Per scenari a bassa latenza, usare i gruppi di posizionamento di prossimità di Azure tra l'applicazione e il livello di persistenza.
  • Per migliorare le prestazioni e l'affidabilità, usare ExpressRoute per connettersi a un sistema locale.
  • È possibile usare File di Azure per archiviare i file usati dal livello applicazione MX.3, ad esempio file di configurazione, file di log e file binari.

Modello hub-spoke di rete

Una considerazione fondamentale quando si implementano carichi di lavoro MX.3 in Azure è la definizione dell'architettura della zona di destinazione. Questa architettura contiene la sottoscrizione, il gruppo di risorse, l'isolamento della rete virtuale e la connettività tra vari componenti della soluzione. Questa sezione illustra l'architettura della zona di destinazione per implementare un carico di lavoro MX.3 in Azure, basato su Microsoft Cloud Adoption Framework.

Il diagramma seguente mostra una visualizzazione generale di una zona di destinazione che usa la topologia di rete hub-spoke in Azure.

Diagramma che mostra un esempio di modello hub-spoke con i servizi di Azure.

  • L'uso di questo modello consente un forte isolamento delle reti spoke usate per eseguire ambienti diversi. Il modello mantiene anche l'accesso sicuro al controllo e un livello di servizio condiviso nella rete hub.
  • È possibile usare lo stesso modello hub-spoke in un'altra area di una soluzione in più aree. È possibile creare un hub per ogni area, seguito da spoke diversi per la non produzione e la produzione.
  • È possibile usare questa zona di destinazione per una singola sottoscrizione o più sottoscrizioni a seconda del modo in cui l'organizzazione classifica le applicazioni.

Di seguito viene illustrato ogni componente nella zona di destinazione.

Hub: l'hub è una rete virtuale che funge da posizione centrale per gestire la connettività esterna alla rete locale di un client MX.3 e i servizi di hosting usati da più carichi di lavoro.

Spoke: gli spoke sono reti virtuali che ospitano i carichi di lavoro di Azure MX.3 e si connettono all'hub centrale tramite il peering di rete virtuale.

Peering di rete virtuale: le reti virtuali hub-spoke sono connesse tramite peering di rete virtuale, che supporta connessioni a bassa latenza tra le reti virtuali.

Gateway: un gateway viene usato per inviare il traffico da una rete locale di un client MX.3 alla rete virtuale di Azure. È possibile crittografare il traffico prima dell'invio.

Subnet del gateway: il gateway che invia il traffico dall'ambiente locale ad Azure usa una subnet specifica denominata subnet del gateway. La subnet del gateway è inclusa nell'intervallo di indirizzi IP della rete virtuale specificato durante la configurazione della rete virtuale. Contiene gli indirizzi IP usati dai servizi e dalle risorse del gateway di rete virtuale.

Macchina virtuale Jumpbox di Azure: Jumpbox connette le macchine virtuali di Azure dei livelli di persistenza e dell'applicazione usando l'INDIRIZZO IP dinamico. Jumpbox impedisce che tutte le macchine virtuali dell'applicazione e del database vengano esposte al pubblico. Questa connessione è il punto di ingresso per connettersi tramite RDP dalla rete locale.

Firewall di Azure: è necessario instradare qualsiasi connettività in ingresso e in uscita tra le macchine virtuali MX.3 e Internet tramite Firewall di Azure. Esempi tipici di tale connettività sono la sincronizzazione dell'ora e l'aggiornamento delle definizioni antivirus.

Azure Bastion: usando Azure Bastion, è possibile connettere in modo sicuro le macchine virtuali dell'applicazione e del database tramite portale di Azure. Distribuire l'host Azure Bastion all'interno della rete virtuale hub e quindi accedere alle macchine virtuali nelle reti virtuali spoke con peering. Questo componente è facoltativo ed è possibile usarlo in base alle esigenze.

Subnet di Azure Bastion: Azure Bastion richiede una subnet dedicata: AzureBastionSubnet. È necessario creare questa subnet nell'hub ed è necessario distribuire l'host Bastion in questa subnet.

Subnet di gestione di Azure: Azure Jumpbox deve trovarsi nella subnet di gestione. Jumpbox contiene macchine virtuali che implementano funzionalità di gestione e monitoraggio per le macchine virtuali dell'applicazione e del database nella rete virtuale spoke.

Subnet dell'applicazione: è possibile posizionare tutti i componenti al livello applicazione qui. La presenza di una subnet dell'applicazione dedicata consente anche di controllare il traffico verso i livelli aziendali, di orchestrazione e di servizi tecnici tramite gruppi di sicurezza di rete.

Subnet del database: è possibile inserire i componenti nella subnet del database in una subnet dedicata per gestire il traffico intorno al database.

Collegamento privato: i servizi di Azure come insiemi di credenziali di Servizi di ripristino, cache di Azure per Redis e File di Azure sono tutti connessi tramite un collegamento privato alla rete virtuale. La presenza di un collegamento privato tra questi servizi e la rete virtuale protegge la connessione tra gli endpoint in Azure eliminando l'esposizione dei dati a Internet.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

Altri contributori:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi