Distribuire IBM Maximo Application Suite in Azure

IBM Maximo Application Suite (MAS) 8.x e in esecuzione in OpenShift ed è utile acquisire familiarità con OpenShift e i modelli suggeriti per l'installazione in Azure. Per maggiori informazioni, consultare la sezione Preparazione all'installazione su Azure. Questa architettura illustra un cluster OpenShift. Non illustra in dettaglio come installare MAS. Per altre informazioni sul processo di installazione, vedere Installing Maximo Application Suite.

Architettura

Scaricare un file di Visio di questa architettura.

Il carico di lavoro può essere distribuito internamente o esternamente, a seconda dei requisiti.

Workflow

Dal punto di vista dell'infrastruttura, questa architettura offre quanto segue:

• Una piattaforma di hosting di contenitori per distribuire carichi di lavoro a disponibilità elevata tra zone di disponibilità
• Distribuzione privatizzata dei nodi di lavoro e di controllo integrati con l'archiviazione
• File Premium di Azure e file standard per l'archiviazione (OpenShift Data Foundation non richiesto)
• SQL Server in macchine virtuali di Azure o ibm Db2 Warehouse basato su contenitori
• DNS di Azure per la gestione DNS di OpenShift e dei relativi contenitori
• Microsoft Entra ID per Single Sign-On (SSO) a MAS

Componenti

• Azure Macchine virtuali ospitare la piattaforma OpenShift ed eseguire i contenitori Maximo. Macchine virtuali offre una soluzione di infrastruttura come servizio (IaaS, Infrastructure as a Service). È possibile usare Macchine virtuali per distribuire risorse di elaborazione scalabili su richiesta.

• Red Hat Enterprise Linux CoreOS per fornire un'immagine di macchina virtuale personalizzata per OpenShift.

• Servizi di bilanciamento del carico di Azure per fornire connettività al cluster. Azure Load Balancer è un servizio di bilanciamento del carico di livello 4 a elevate prestazioni e bassa latenza (in ingresso e in uscita) per tutti i protocolli UDP e TCP. È progettato per gestire milioni di richieste al secondo assicurando al tempo stesso la disponibilità elevata della soluzione. Azure Load Balancer offre ridondanza della zona, garantendo disponibilità elevata tra zone di disponibilità.

• Rete virtuale per la comunicazione tra nodi, servizi di Azure e esigenze di connettività ibrida. Una rete virtuale rappresenta il blocco costitutivo fondamentale per le reti private di Azure.

• File di Azure che ospita i dati con stato per i database e i sistemi all'interno del cluster. File di Azure offre condivisioni file completamente gestite nel cloud accessibili tramite i protocolli SMB e NFS (Network File System).

• DNS di Azure per gestire la risoluzione DNS per i contenitori all'interno e all'esterno della soluzione. DNS di Azure supporta tutti i record DNS comuni e offre disponibilità elevata.

• Azure Bastion (facoltativo) e una subnet per accedere in modo sicuro a qualsiasi nodo di lavoro o ai computer JumpBox facoltativi. Azure Bastion è un servizio completamente gestito che offre accesso SSH e RDP semplice e affidabile alle VM senza esposizione tramite indirizzi IP pubblici.

• SQL Server in Macchine virtuali di Azure (facoltativo) per fornire servizi dati a MAS. Il database può anche essere un altro, ad esempio Oracle Exadata o IBM Db2 Warehouse. Il database SQL di Azure e Istanza gestita di SQL di Azure non sono attualmente supportati.

• Twilio Send Grid (facoltativo) per inviare messaggi di posta elettronica da MAS ai consumer.

• Macchine virtuali Linux in Azure (facoltativo) per fornire un jump box per l'installazione di OpenShift. È anche possibile usare questa macchina virtuale per connettersi e gestire il cluster OpenShift perché contiene il file di configurazione di Kubernetes dopo l'installazione. Se si ha connettività di rete nell'ambiente Azure, è possibile eseguire l'installazione da un computer esistente.

Alternative

I servizi seguenti in genere non sono necessari, ma sono alternative efficaci:

• Azure NetApp Files come sostituzione di File di Azure. Azure NetApp Files supporta qualsiasi tipo di carico di lavoro con disponibilità elevata e prestazioni elevate.
• Database Oracle in Azure se si preferisce usare SQL Server o Db2 Warehouse.
• OpenShift Data Foundation se si vuole usare Db2 Warehouse in OpenShift Data Foundation.

Dettagli dello scenario

Maximo Application Suite (MAS) di IBM, noto anche come Maximo, è una piattaforma di gestione delle risorse aziendale con la manutenzione degli asset basata sull'intelligenza artificiale. MAS è incentrato sulla resilienza operativa e sull'affidabilità. La suite è costituita da una piattaforma applicativa di base, MAS e applicazioni e soluzioni specifiche del settore oltre alla piattaforma. Ogni applicazione offre un vantaggio specifico:

• Gestire. Ridurre i tempi di inattività e i costi usando la gestione degli asset per migliorare le prestazioni operative.
• Monitoraggio. Usare IoT per il monitoraggio avanzato basato sull'intelligenza artificiale degli asset remoti su larga scala.
• Integrità. Gestire l'integrità degli asset usando i dati IoT dai sensori, dai dati degli asset e dalla cronologia di manutenzione.
• Ispezione visiva. Eseguire il training di modelli di Machine Learning per usare l'ispezione visiva per l'analisi visiva dei problemi emergenti.
• Prevedere. Prevedere gli errori futuri usando l'apprendimento automatico e l'analisi dei dati.
• Assistere. Assistere i tecnici fornendo indicazioni basate sull'IA a una knowledge base dei dati di manutenzione delle apparecchiature e fornendo loro l'accesso remoto agli esperti.
• Sicurezza. Raccogliere e analizzare i dati dai sensori, fornire dati contestuali e derivare analisi significative.
• Civile. Integrare le attività di ispezione, rilevamento dei difetti e manutenzione per migliorare la vita degli asset, mantenere operativi i sistemi critici e ridurre i costi totali di proprietà dell'infrastruttura civile.

Queste applicazioni e MAS 8. x vengono testati per l'uso in Azure. Microsoft e il team IBM Maximo hanno collaborato per garantire che questa soluzione sia configurata per l'esecuzione ottimale in Azure. Questo articolo fornisce una progettazione per l'esecuzione di MAS 8.x e fino ad Azure per i clienti che hanno supporto da IBM e da un partner per l'installazione. Per domande specifiche sul prodotto, contattare il team IBM. Azure Marketplace offre un'installazione alternativa per MAS che supporta l'uso di una licenza personalizzata. Per maggiori informazioni, consultare la sezione IBM Maximo Application Suite (bring your own license (BYOL)). Questa guida descrive in dettaglio come installare Maximo manualmente.

Potenziali casi d'uso

Molti settori e settori usano le soluzioni in MAS, ad esempio:

• Energia elettrica e servizi pubblici
• Petrolio e gas
• Produzione
• Viaggi, automobili e trasporti
• Settore pubblico

Per maggiori informazioni sui casi d'uso per MAS, consultare il sito Web di IBM Maximo Application Suite.

Consigli

È consigliabile installare la versione stabile più recente di MAS perché offre le migliori opzioni di integrazione con Azure. Prestare particolare attenzione alle versioni di OpenShift supportate, perché le versioni supportate variano con la versione specifica di MAS.

L'uso di versioni principali precedenti o successive di OpenShift può causare la caduta del supporto ufficiale per MAS. Prima di creare una distribuzione personalizzata, è consigliabile leggere attentamente le di installazione in Azure e pianificazione per Azure documentazione in modo da comprendere il funzionamento della distribuzione e della configurazione. Conoscere i dettagli di installazione accelera la creazione dei requisiti di progettazione per l'implementazione.

Microsoft collabora con IBM e altri partner per garantire che la documentazione, l'architettura e le linee guida offra la migliore esperienza in Azure. Seguono le procedure consigliate descritte in Microsoft Azure Well-Architected Framework. Per assistenza oltre a questa documentazione, contattare il team dell'account IBM.

Prima di procedere con la distribuzione, è necessario rispondere alle domande seguenti sulla progettazione:

• Quali applicazioni MAS sono necessarie?
• Quali dipendenze hanno le applicazioni?
• Quale versione di OpenShift è necessaria?
• Quale metodo di installazione di OpenShift è necessario usare?
• Quali database sono necessari?
• Qual è il numero e le dimensioni delle macchine virtuali necessarie?
• Gli utenti si connetteranno da reti esterne?

Maximo Application Suite

Microsoft ha testato mas versione 8.7 e successive in Azure. È consigliabile usare la versione più recente di MAS, attualmente versione 9.0. Se si usa versioni precedenti di Maximo Application Suite, è consigliabile eseguire l'aggiornamento per trarre vantaggio da una migliore integrazione con Azure.

Esaminare le applicazioni MAS necessarie per lo scenario aziendale completo e quindi esaminare i requisiti per ognuna delle applicazioni. Per maggiori informazioni, consultare la sezione Requisiti di sistema di IBM Maximo Application Suite. Ognuna delle applicazioni potrebbe richiedere database separati. In Azure sono stati testati e supportati i database seguenti:

• SQL Server in macchine virtuali di Azure versione 2019 con Windows o Linux
• IBM Db2 Warehouse on Cloud Pak for Data 5

È anche possibile scegliere di eseguire Oracle Exadata in una macchina virtuale o in Oracle Cloud Infrastructure usando l'interconnessione, ma questa non è una configurazione testata. Per altre informazioni sull'interconnessione, vedere Interconnessione di Oracle Cloud con Microsoft Azure. Attualmente, database SQL di Azure, Istanza gestita di SQL di Azure e Azure Cosmos DB non sono supportati.

MAS e alcune delle applicazioni hanno dipendenze da MongoDB e Kafka. Decidere come distribuire queste soluzioni in base alle considerazioni relative alle prestazioni e alle operazioni. Le impostazioni predefinite sono distribuire MongoDB Community Edition e Strimzi Kafka all'interno dei cluster. Alcuni dei prerequisiti di MAS, ad esempio BAS, usano database che non possono essere esternalizzati, ma che richiedono l'archiviazione permanente da fornire al cluster OpenShift.

Per i servizi basati su stato eseguiti all'interno del cluster OpenShift, è necessario eseguire spesso il backup dei dati e spostare i backup in un'altra area. Progettare e pianificare una strategia di ripristino in caso di emergenza e decidere di conseguenza, soprattutto quando si esegue Kafka o MongoDB all'interno di OpenShift.

Per i servizi che mantengono lo stato, usare le offerte PaaS (Platform as a Service) esterne, se possibile. In questo modo si migliora il supporto durante un'interruzione.

Alcuni dei servizi potrebbero richiedere altri strumenti e servizi IBM, ad esempio IBM Watson Machine Learning e IBM App Connect. È possibile distribuire tutti gli strumenti e i servizi nello stesso cluster OpenShift.

OpenShift

Prima di installare OpenShift, è necessario determinare quale metodo si userà:

• Infrastruttura di cui è stato effettuato il provisioning (IPI) del programma di installazione. Questo metodo usa un programma di installazione per distribuire e configurare l'ambiente OpenShift in Azure. IPI è il metodo più comune per la distribuzione in Azure ed è consigliabile usare IPI a meno che i requisiti di sicurezza non siano troppo rigidi per farlo.

• Infrastruttura sottoposta a provisioning utente (UPI). Questo metodo consente un controllo granulare sulla distribuzione. L'UPI richiede altri passaggi e considerazioni per creare l'ambiente. Usare l'UPI se IPI non soddisfa le proprie esigenze. Un caso d'uso comune per l'UPI è per l'installazione privata e air-gapped. Scegliere UPI quando non si ha accesso a Internet in uscita durante la compilazione dell'ambiente.

È consigliabile usare IPI quando possibile, perché riduce significativamente la quantità di lavoro necessaria per completare l'installazione di OpenShift.

Quando si installa OpenShift, è necessario risolvere le considerazioni seguenti:

• Selezione dell'area. È consigliabile usare un'area con zone di disponibilità. Durante la distribuzione, OpenShift tenta automaticamente di creare nodi tra zone in base alla configurazione nel file di configurazione install-config.yaml. Per impostazione predefinita, OpenShift bilancia i carichi di lavoro in tutti i nodi disponibili e nelle zone di disponibilità. Se si verifica un'interruzione in una zona, la soluzione può continuare a funzionare avendo nodi in altre zone che possono assumere il controllo del lavoro.

• Backup & ripristino. È possibile usare le istruzioni per Azure Red Hat OpenShift per il backup e il ripristino. Per maggiori informazioni, consultare la sezione Creare un backup applicazione del cluster Azure Red Hat OpenShift 4. Se si usa questo metodo per il backup e il ripristino, è necessario fornire un altro metodo di ripristino di emergenza per il database.

• Eseguire il failover. Valutare la distribuzione di OpenShift in due aree e l'uso di Red Hat Advanced Cluster Management. Se la soluzione include endpoint pubblici, è possibile posizionare Gestione traffico di Azure tra di essi e Internet per reindirizzare il traffico al cluster appropriato quando si verifica un'interruzione di un'area. In una situazione di questo tipo, è anche necessario eseguire la migrazione degli stati delle applicazioni e dei volumi permanenti.

Installazioni air-gapped

In alcuni casi, ad esempio per la conformità alle normative, potrebbe essere necessaria un'installazione air-gapped di MAS in Azure. Air gapped significa che non c'è accesso a Internet in ingresso o in uscita. Senza una connessione Internet, l'installazione non può recuperare le dipendenze di installazione in fase di esecuzione per l'installazione di MAS o OpenShift.

Non è consigliabile eseguire un'installazione air-gapped a meno che non si tratta di un requisito di sicurezza. Un gap d'aria aggiunge una notevole complessità alle operazioni della soluzione. Le attività come l'installazione di software, contenitori di mirroring, l'aggiornamento di un mirror per proteggersi dalle vulnerabilità di sicurezza e la gestione di un firewall possono richiedere molto tempo.

Per maggiori informazioni sulle installazioni air-gapped, consultare la documentazione di OpenShift seguente:

• Immagini di mirroring per un'installazione disconnessa
• Installazione di un cluster privato in Azure

Dopo aver installato OpenShift, vedere la documentazione di MAS per indicazioni simili.

Dimensionamento dell'ambiente

Per tutti i carichi di lavoro (ad eccezione dell'ispezione visiva), è consigliabile usare le macchine virtuali della serie Ds più recenti come nodi di lavoro. Gli esempi sono Dsv3, Dasv4, Dsv4, Dasv5 o Dsv5. È consigliabile usare le versioni più recenti, quando possibile, perché offrono prestazioni migliori. Usare solo macchine virtuali con archiviazione Premium.

Maximo Visual Inspection richiede che i nodi GPU eseguano l'apprendimento automatico. La soluzione usa CUDA e supporta solo GPU NVIDIA. I tipi consigliati di macchine virtuali sono NCv3 e NCasT4_v3. Se è necessario eseguire il training usando YOLOv3, sono necessarie GPU basate su Ampere. Usare NVadsA10 v5 o NC A100 v4 per attività di training più grandi.

Per i computer GPU, è consigliabile iniziare con il nodo più piccolo e aumentare le prestazioni man mano che aumentano i requisiti.

Per tutti gli altri computer, è consigliabile configurare macchine virtuali tra zone di disponibilità per supportare la disponibilità elevata. Configura i nodi come segue:

• Nodi di controllo. Almeno una VM per zona di disponibilità all'interno dell'area selezionata. È consigliabile un conteggio vCPU di almeno 4. Il riferimento usa nodi Standard_D8s_v4 3x.

• Nodi di lavoro, Almeno due computer per zona di disponibilità all'interno dell'area selezionata. È consigliabile un conteggio vCPU di almeno 8. Il riferimento usa nodi Standard_D8s_v4 6x.

Il core MAS richiede 13 vCPU per un'installazione di base di dimensioni standard. Il ridimensionamento per i nodi di lavoro varia in base alle applicazioni MAS distribuite dalla configurazione e al carico nell'ambiente. Ad esempio, Manage for 10 users richiede un'altra 2 vCPU. È consigliabile esaminare i requisiti di sistema di IBM Maximo Application Suite per ottenere una stima del dimensionamento ottimale.

Provare a mantenere i tipi di macchine virtuali simili tra loro per garantire la prossimità con ognuna delle zone di disponibilità tra nodi di lavoro e di controllo. Ovvero, se si usa una macchina virtuale v4 per i nodi di controllo, usare anche una macchina virtuale v4 per i nodi di lavoro.

Se è necessario un jump box per usare l'interfaccia della riga di comando di OpenShift (oc) o per installare MAS, distribuire una macchina virtuale che esegue Red Hat Enterprise Linux versione 8.4.

Rete

Con OpenShift viene usato il provider CNI (Container Network Interface) predefinito della rete software-defined (SDN) di OpenShift. Per altre informazioni su OpenShift CNI predefinito, vedere Understanding Networking in OpenShift Container Platform. È necessario ridimensionare la rete per il numero di nodi di controllo e di lavoro di OpenShift necessari e anche per qualsiasi altro requisito, ad esempio database e account di archiviazione.

Per un'installazione di produzione MAS standard, è consigliabile usare una rete virtuale con lo spazio indirizzi fornito da un prefisso CIDR (Classless Inter-Domain Routing) di /24. La rete virtuale ha tre o quattro subnet (per Azure Bastion). Per OpenShift, la subnet per i nodi di lavoro ha un prefisso CIDR di /25 e i nodi di controllo hanno un prefisso /27. Una subnet per gli endpoint e un server di database esterno facoltativo deve avere un prefisso /27. Se si distribuisce Azure Bastion, facoltativo, è necessaria una subnet denominata AzureBastionSubnet con un prefisso /26. Per maggiori informazioni sui requisiti per Azure Bastion, consultare la sezione Architettura.

Se gli indirizzi IP sono brevi, è possibile implementare una configurazione a disponibilità elevata con un prefisso minimo di /27 per la subnet dei nodi di controllo e /27 per la subnet dei nodi di lavoro.

Se si desidera usare un CNI diverso, ridimensionare le reti di conseguenza. MAS con alcune applicazioni standard distribuisce oltre 800 pod, che probabilmente richiedono un prefisso CIDR di /21 o superiore.

Specifiche del database

Vari componenti di MAS usano MongoDB come archivio di metadati. Le indicazioni predefinite sono la distribuzione di MongoDB Community Edition all'interno del cluster. Se la si distribuisce usando tale metodo, assicurarsi di disporre di una procedura appropriata per il backup e il ripristino del database. Prendere in considerazione l'uso di MongoDB Atlas in Azure, perché fornisce un archivio esterno, backup, scalabilità e altro ancora. Azure attualmente non supporta l'uso delle API MongoDB con Azure Cosmos DB.

Se si distribuiscono i servizi IoT, è necessario fornire anche un endpoint Kafka. Il materiale sussidiario predefinito consiste nell'usare Strimzi per distribuire Kafka all'interno del cluster OpenShift. Durante un ripristino di emergenza, è probabile che i dati all'interno di Strimzi vadano persi. Se la perdita di dati all'interno di Kafka non è accettabile, è consigliabile usare Confluent Kafka in Azure. Attualmente, Hub eventi di Azure con endpoint Kafka non sono supportati.

MAS viene fornito con molti database all'interno dei pod e tali database mantengono i relativi stati nel file system fornito per MAS. È consigliabile usare un meccanismo di archiviazione con ridondanza della zona per mantenere gli stati esterni ai cluster per poter assorbire gli errori della zona. Il modello consigliato consiste nell'usare Archiviazione file di Azure con le configurazioni seguenti:

• Standard. Fornisce condivisioni SMB (Server Message Block) per carichi di lavoro ReadWriteOnce (RWO) e velocità effettiva inferiori. Standard è ideale per le parti dell'applicazione che non scrivono spesso nell'archiviazione e richiedono un singolo volume permanente ( ad esempio, l'archiviazione a livello singolo IBM).

• Premium. Fornisce condivisioni NFS (Network File System) per carichi di lavoro ReadWriteMany (RWX) più elevati. I volumi come questi vengono usati in tutto il cluster per carichi di lavoro RWX, ad esempio Db2 Warehouse in Cloud Pak for Data o Postgres in Gestisci.

Assicurarsi di disabilitare i criteri per applicare il trasferimento sicuro nei Archiviazione BLOB di Azure o esentare gli account da tali criteri. File Premium di Azure con NFS richiede che il trasferimento sicuro sia disabilitato. Assicurarsi di usare un endpoint privato per garantire la connettività privata alle condivisioni.

Per impostazione predefinita, Db2 Warehouse viene distribuito su OpenShift Data Foundation (noto in precedenza come OpenShift Container Storage). Per motivi di costi, prestazioni, scalabilità e affidabilità, è consigliabile usare File Premium di Azure con NFS anziché OpenShift Data Foundation.

Non usare BLOB Storage di Azure con driver CSI, perché non supporta i collegamenti rigidi, necessari. Alcuni pod non possono essere eseguiti senza collegamenti rigidi.

Considerazioni

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

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.

Mantenere l'accesso e la visibilità sul ciclo di vita di manutenzione degli asset può essere una delle maggiori opportunità dell'organizzazione di operare in modo efficiente e mantenere il tempo di attività. Per migliorare il comportamento di sicurezza dell'ambiente, è importante usare l'autenticazione sicura e mantenere aggiornate le soluzioni. Usare la crittografia per proteggere tutti i dati che si spostano all'esterno e all'esterno dell'architettura.

Azure offre MAS usando i modelli di infrastruttura distribuita come servizio (IaaS) e PaaS. Microsoft crea protezioni di sicurezza nel servizio ai livelli seguenti:

• Data center fisico
• Rete fisica
• Host fisico
• Hypervisor

Valutare attentamente i servizi e le tecnologie selezionati per le aree sopra l'hypervisor, ad esempio la versione più recente con patch di OpenShift per una versione principale. Assicurarsi di fornire i controlli di sicurezza appropriati per l'architettura. L'utente è responsabile dell'applicazione di patch e della gestione della sicurezza dei sistemi IaaS. Microsoft assume tale ruolo per i servizi PaaS.

Usare i gruppi di sicurezza di rete per filtrare il traffico di rete da e verso le risorse nella propria rete virtuale. Con questi gruppi è possibile definire regole che concedono o negano l'accesso ai servizi MAS. Alcuni esempi:

• Consentire l'accesso SSH ai nodi OpenShift per la risoluzione dei problemi
• Bloccare l'accesso a tutte le altre parti del cluster
• Controllare quali posizioni possono avere accesso a MAS e al cluster OpenShift

Se è necessario accedere alle macchine virtuali per qualche motivo, è possibile connettersi tramite la connettività ibrida o tramite la console di amministrazione di OpenShift. Se si ha una distribuzione online o non si vuole basarsi sulla connettività, è anche possibile accedere alle macchine virtuali tramite Azure Bastion (facoltativo). Per motivi di sicurezza, non è consigliabile esporre le macchine virtuali a una rete o a Internet senza configurare i gruppi di sicurezza di rete per controllare l'accesso.

La crittografia lato server di Archiviazione su disco di Azure protegge i dati. Consente inoltre di soddisfare gli impegni di sicurezza e conformità dell'organizzazione. Con i dischi gestiti di Azure, SSE crittografa i dati inattivi quando vengono mantenuti nel cloud. Questo comportamento si applica per impostazione predefinita sia ai dischi del sistema operativo che ai dischi dati. OpenShift usa SSE per impostazione predefinita.

Autenticazione

MAS supporta attualmente l'accesso Single Sign-On (SSO) con SAML (Security Assertion Markup Language) nell'ID Microsoft Entra. Questo metodo di autenticazione richiede un'applicazione aziendale all'interno di Microsoft Entra ID e autorizzazioni per modificare l'applicazione. Per altre informazioni, vedere Integrazione SSO di Microsoft Entra con Maximo Application Suite.

Prima di configurare l'autenticazione basata su SAML, è consigliabile passare attraverso la configurazione IBM e la configurazione di Azure. Per informazioni su SAML con MAS, consultare la sezione SAML nella documentazione per MAS. Per informazioni su SAML con Azure, consultare la sezione Avvio rapido: abilitare l'accesso Single Sign-On per un'applicazione aziendale.

È anche consigliabile configurare Open Authorization (OAuth) per OpenShift. Per maggiori informazioni, consultare la sezione Panoramica dell'autenticazione e dell'autorizzazione nella documentazione di OpenShift.

Proteggere l'infrastruttura

Controllare l'accesso alle risorse di Azure da distribuire. Ogni sottoscrizione di Azure ha una relazione di trust con un tenant di Microsoft Entra. Usare il Controllo degli accessi in base al ruolo (RBAC) di Azure per concedere agli utenti interni dell'organizzazione le autorizzazioni corrette per le risorse di Azure. Concedere l'accesso assegnando ruoli di Azure a utenti o gruppi in un determinato ambito. L'ambito può essere una sottoscrizione, un gruppo di risorse o una risorsa. Assicurarsi di controllare tutte le modifiche apportate all'infrastruttura. Per maggiori informazioni sul controllo, consultare la sezione Log attività di Monitoraggio di Azure.

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.

Una distribuzione standard di MAS è costituita dai componenti seguenti:

• 3 VM di controllo
• 6 VM di lavoro
• 3 VM di lavoro per Db2 Warehouse
  • È possibile sostituire SQL Server in macchine virtuali di Azure in alcune configurazioni anziché usare Db2 Warehouse.
• 2 account di archiviazione di Azure
• 2 Zone DNS
• 2 Load Balancer
• Azure Bastion
• 1 VM di ispezione visiva
  • Questa operazione non è necessaria a meno che non si prevede di eseguire l'ispezione visiva all'interno di MAS.

È possibile esaminare una stima di esempio usando il calcolatore dei costi. Le configurazioni variano ed è necessario verificare la configurazione con il team di ridimensionamento IBM prima di finalizzare la distribuzione.

Affidabilità

OpenShift offre funzionalità predefinite per la riparazione automatica, la scalabilità e la resilienza per garantire il corretto funzionamento di OpenShift e MAS. OpenShift e MAS sono stati progettati per parti che hanno esito negativo e ripristino. Un requisito fondamentale per il funzionamento della riparazione automatica consiste nel fatto che sono presenti nodi di lavoro sufficienti. Per eseguire il ripristino da un errore di zona all'interno di un'area di Azure, i nodi di controllo e di lavoro devono essere bilanciati tra le zone di disponibilità.

MAS e OpenShift usano l'archiviazione per rendere persistente lo stato all'esterno del cluster Kubernetes. Per assicurarsi che le dipendenze di archiviazione continuino a funzionare durante un errore, è consigliabile usare l'archiviazione con ridondanza della zona. Questo tipo di spazio di archiviazione rimane disponibile quando una zona ha esito negativo.

Poiché l'errore umano è comune, è consigliabile distribuire MAS usando il maggior numero possibile di automazione. Nella nostra guida all'avvio rapido, vengono forniti alcuni script di esempio per configurare l'automazione completa e end-to-end.

Distribuire lo scenario

Prima di iniziare, è consigliabile esaminare i requisiti di sistema di IBM Maximo Application Suite. Assicurarsi di disporre delle risorse seguenti prima di avviare la distribuzione:

• Accesso a una sottoscrizione di Azure con autorizzazione di Lettore
• Registrazione dell'applicazione o nome dell'entità servizio con autorizzazioni collaboratore e amministratore accesso utenti per la sottoscrizione
• Dominio o sottodominio delegato a una zona DNS di Azure
• Eseguire il pull del segreto da Red Hat per distribuire OpenShift
• Chiave entitlement MAS
• File di licenza MAS (creato dopo l'installazione di MAS)
• Dimensionamento del cluster IBM consigliato
• Rete virtuale esistente o una nuova rete virtuale creata da IPI, a seconda dei requisiti
• Requisiti di disponibilità elevata e ripristino di emergenza per la distribuzione specifica
• File di configurazione, install-config.yaml, per il programma di installazione

Per una guida dettagliata all'installazione di OpenShift e MAS in Azure, inclusa la procedura per soddisfare i prerequisiti, vedere la guida introduttiva su GitHub.

Considerazioni sulla distribuzione

È consigliabile distribuire i carichi di lavoro usando l'infrastruttura come codice (IaC) anziché distribuire manualmente i carichi di lavoro, perché la distribuzione manuale può comportare errori di configurazione. I carichi di lavoro basati su contenitori possono essere sensibili alla configurazione errata, riducendo così la produttività.

Prima di creare l'ambiente, esaminare la documentazione di per Azure fornita da IBM per sviluppare una conoscenza dei parametri di progettazione. La guida all'avvio rapido non è destinata a una distribuzione pronta per la produzione, ma è possibile usare gli asset della guida per passare a un meccanismo di produzione per la distribuzione.

IBM offre servizi specializzati per facilitare l'installazione. Contattare il team IBM per assistenza.

Collaboratori

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

Autori principali:

• David Baumgarten | Senior Cloud Solution Architect
• Roeland Nieuwenhuis | Principal Cloud Solution Architect

Altro collaboratore:

• Gary Moore | Programmatore/writer

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

Passaggi successivi

Per assistenza all'avvio rapido, consultare le risorse seguenti:

• Installazione di OpenShift in Azure
• Guida all'avvio rapido: Maximo Application Suite in Azure
• Guida all'UPI di OpenShift
• Requisiti per Maximo
• IBM Maximo Application Suite (BYOL)

Per maggiori informazioni sulle tecnologie in primo piano, consultare le risorse seguenti:

• IBM Passport Advantage
• Introduzione ad Azure DNS
• Introduzione ad Azure NetApp Files
• Introduzione a Red Hat in Azure
• Red Hat Customer Portal

Risorse correlate

• Condivisione file del cloud aziendale di Azure
• Distribuire un'applicazione Java con JBoss enterprise application platform (EAP) in un cluster ARO