Distribuire IBM Maximo Application Suite su Azure

File di Azure
Azure Load Balancer
Azure Red Hat OpenShift
Macchine virtuali di Azure
Rete virtuale di Azure

Questo articolo descrive la distribuzione di IBM Maximo Application Suite (MAS) in Azure. MAS viene eseguito in Red Hat OpenShift. Azure Red Hat OpenShift (ARO) è la piattaforma OpenShift preferita se soddisfa i requisiti operativi, di sicurezza e di rete. Usare Red Hat OpenShift autogestito in Azure solo quando è necessario controllare che ARO non fornisca, ad esempio modelli di distribuzione disconnessi specifici o personalizzazione a livello di cluster.

Questo articolo non illustra in dettaglio come installare MAS. Per altre informazioni sull'installazione, vedere Installazione di Maximo Application Suite.

Architettura

Il diagramma seguente illustra una distribuzione MAS basata su ARO in Azure.

Diagramma dell'architettura che mostra i componenti e i servizi che supportano una distribuzione MAS ARO.

Scaricare un file Visio di questa architettura.

È possibile distribuire il carico di lavoro come distribuzione interna o esterna, a seconda dei requisiti. Questo articolo non prevede un modello di distribuzione ARO pubblico o privato. Scegliere il piano di controllo, l'architettura in ingresso e in uscita in base all'architettura della zona di destinazione Azure, tra cui la topologia di rete, il modello di connettività, i controlli di sicurezza, i requisiti di accesso operativo, i requisiti di conformità e i modelli di accesso utente MAS.

Quando IBM supporta database esterni per le applicazioni MAS distribuite, provare a esternalizzare tali database per ridurre lo stato all'interno del cluster OpenShift e separare la gestione dei database dalla gestione del cluster.

Flusso di lavoro

Dal punto di vista dell'infrastruttura, questa architettura offre le funzionalità seguenti:

  • Un servizio gestito di Azure Red Hat OpenShift per distribuire carichi di lavoro a disponibilità elevata tra zone di disponibilità
  • Un cluster OpenShift integrato con Azure rete e archiviazione
  • File di Azure Premium e File di Azure Standard per i requisiti di archiviazione MAS supportati
  • Istanza gestita di SQL di Azure o IBM Db2 Warehouse basato su contenitori
  • DNS di Azure per la gestione dns (Domain Name System) di OpenShift e dei relativi contenitori
  • Microsoft Entra ID per l'accesso Single Sign-On (SSO) in MAS

Componenti

  • Azure Red Hat OpenShift (ARO) è la piattaforma OpenShift preferita per MAS in Azure. ARO riduce la responsabilità operativa per l'esecuzione di OpenShift rispetto a un cluster autogestito in macchine virtuali Azure.

  • Macchine virtuali di Azure è un'infrastruttura distribuita come servizio (IaaS) che distribuisce risorse di calcolo su richiesta e scalabili. Usare Macchine virtuali anziché ARO per distribuire Red Hat OpenShift autogestito in Azure.

    Facoltativamente, usare Azure macchine virtuali Linux come jump box per l'installazione MAS e l'amministrazione di OpenShift. Se si dispone di connettività di rete privata nell'ambiente Azure, è possibile eseguire l'amministrazione da un computer protetto esistente.

  • Red Hat Enterprise Linux CoreOS fornisce l'immagine del sistema operativo per i nodi OpenShift.

  • Azure Load Balancer fornisce connettività al cluster. Load Balancer è un servizio di bilanciamento del carico di livello 4 con prestazioni elevate e a bassa latenza per tutti i protocolli UDP (User Datagram Protocol) in ingresso e in uscita e TCP (Transmission Control Protocol). Load Balancer può gestire milioni di richieste al secondo assicurando al tempo stesso che la soluzione sia a disponibilità elevata. Load Balancer è con ridondanza della zona, garantendo la disponibilità elevata tra le zone di disponibilità.

  • Rete virtuale di Azure rappresenta il blocco costitutivo delle reti private in Azure. Usare Rete virtuale per la comunicazione tra nodi e servizi di Azure e per la connettività ibrida.

  • File di Azure fornisce condivisioni file completamente gestite nel cloud accessibili tramite i protocolli SMB (Server Message Block) e Network File System (NFS). Usare File di Azure per ospitare i dati con stato per i database e i sistemi all'interno del cluster.

  • DNS di Azure gestisce 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 è un servizio completamente gestito che fornisce l'accesso RDP (Remote Desktop Protocol) e secure shell (SSH) alle macchine virtuali senza alcuna esposizione tramite indirizzi IP pubblici. Facoltativamente, usare Azure Bastion e una subnet per l'accesso alla sicurezza avanzata a uno qualsiasi dei nodi di lavoro o ai jump box machine facoltativi.

  • Istanza gestita di SQL fornisce servizi dati esterni a MAS quando IBM supporta SQL Server per le applicazioni distribuite. È anche possibile scegliere un altro database, ad esempio Oracle Exadata o IBM Db2 Warehouse. database SQL di Azure non è supportato.

  • Twilio SendGrid invia messaggi di posta elettronica da MAS ai relativi consumer. Se la distribuzione MAS richiede un servizio di posta elettronica per scenari di notifica e invio della forza lavoro, facoltativamente incorporare un servizio di posta elettronica come Twilio SendGrid nella progettazione.

Alternative

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

Dettagli dello scenario

IBM Maximo Application Suite è una piattaforma di gestione degli asset aziendale con la manutenzione degli asset basata sull'intelligenza artificiale. MAS è incentrato sulla resilienza operativa e sull'affidabilità. La suite è costituita dalla piattaforma applicativa principale MAS e dalle seguenti applicazioni e soluzioni specifiche del settore basate sulla piattaforma.

  • Maximo Manage. Riduce i tempi di inattività e i costi usando la gestione degli asset per migliorare le prestazioni operative.
  • Maximo Monitor. Usa Internet delle cose (IoT) per il monitoraggio avanzato basato sull'intelligenza artificiale degli asset remoti su larga scala.
  • Maximo Health. Gestisce l'integrità degli asset usando i dati IoT dai sensori, dai dati degli asset e dalla cronologia di manutenzione.
  • Maximo Visual Inspection. Esegue il training di modelli di Machine Learning per usare l'ispezione visiva per l'analisi visiva dei problemi emergenti.
  • Maximo Predict. Consente di stimare gli errori futuri usando l'apprendimento automatico e l'analisi dei dati.
  • Maximo Collaborate. Supporta i tecnici con linee guida basate sull'IA da una knowledge base dei dati di manutenzione delle apparecchiature e fornisce l'accesso remoto agli esperti.
  • Maximo Health, Safety and Environment (HSE). Connette processi di sicurezza, conformità ambientale e controllo del lavoro ad asset, sedi e ordini di lavoro.
  • Maximo Civil Infrastructure. Integra 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.
  • Maximo Real Estate e Strutture. Gestisce portafogli immobiliari e asset di strutture con gestione dello spazio, prenotazioni, progetti di capitale, valutazione delle condizioni di struttura, gestione lease, operazioni e manutenzione.

Potenziali casi d'uso

Molti settori e settori usano soluzioni MAS, ad esempio le aree seguenti:

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

Per altre informazioni sui casi d'uso di MAS, vedere IBM Maximo Application Suite nel sito Web IBM.

Consigli

Questo articolo è scritto per le distribuzioni MAS 9.x attualmente supportate in Azure. Microsoft ha collaborato con il team IBM MAS e altri partner per assicurarsi che questa soluzione sia configurata in modo ottimale e offrire la migliore esperienza su Azure. Questa documentazione, architettura e indicazioni seguono le procedure consigliate descritte in Microsoft Azure Well-Architected Framework. Contattare il team dell'account IBM per domande e supporto specifici del prodotto oltre a questa documentazione.

Usare questo articolo per indicazioni sull'architettura quando si dispone del supporto di IBM e di un partner per l'installazione. Azure offre anche un percorso di installazione 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)).

Installare una versione MAS supportata elencata da IBM come compatibile con la versione di OpenShift e le applicazioni MAS selezionate. Per le nuove distribuzioni di Azure, usare ARO come piattaforma OpenShift preferita, a meno che non sia necessario un cluster autogestito.

La compatibilità del supporto di OpenShift dipende da tre limiti di supporto sovrapposti: compatibilità IBM MAS, supporto del ciclo di vita di Red Hat OpenShift e disponibilità della versione ARO. L'uso di una versione OpenShift che IBM non elenca nei report di compatibilità dei prodotti software (SPCR) o che si trova all'esterno del supporto di Red Hat o ARO può lasciare la distribuzione MAS non supportata.

Prima di compilare la distribuzione, vedere la panoramica di IBM Maximo Application Suite, Pianificazione dell'installazione in Microsoft Azure e documentazione di Software Product Compatibility Reports (SPCR) per comprendere i requisiti di distribuzione e configurazione correnti.

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 supporta IBM per la versione e le applicazioni MAS?
  • ARO soddisfa i requisiti o è necessario usare Red Hat OpenShift autogestito in Azure?
  • Quali database sono necessari?
  • Qual è il numero e le dimensioni delle macchine virtuali necessarie?
  • Gli utenti devono connettersi da reti esterne?

Maximo Application Suite

Usare una versione MAS 9.x supportata corrente e convalidare le versioni, i database e le dipendenze di OpenShift supportati in IBM SPCR prima di finalizzare l'architettura. Se si usa una versione precedente di Maximo Application Suite, esaminare lo stato del ciclo di vita IBM e pianificare un aggiornamento a una versione MAS 9.x supportata.

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.

Ogni applicazione MAS potrebbe richiedere un database separato. Provare a esternalizzare i database se IBM supporta un database esterno per l'applicazione, perché questo approccio riduce la quantità di stato che è necessario operare all'interno di OpenShift. Microsoft e IBM hanno testato e supportato i database seguenti per MAS in Azure:

database SQL di Azure e Azure Cosmos DB non sono supportati.

È anche possibile scegliere di eseguire Oracle Exadata in Oracle Cloud Infrastructure o in una macchina virtuale usando un'interconnessione. Questa configurazione non viene ufficialmente testata, ma viene segnalata correttamente. Per altre informazioni sull'interconnessione, vedere Interconnecting Oracle Cloud with Microsoft Azure.

Nota

In alcuni casi, non è possibile riutilizzare un database per più applicazioni MAS a causa di impostazioni del database in conflitto. Ad esempio, non è possibile usare lo stesso database IBM Db2 Warehouse per Maximo Health e Maximo Manage in combinazione con Maximo Monitor. È possibile combinare prodotti di database diversi, ad esempio usando Istanza gestita di SQL e IBM Db2 Warehouse per due applicazioni diverse.

Per maggiori informazioni sui requisiti del database per l'applicazione Health, vedere Configurazione del database per Maximo Health.

MAS e alcune delle applicazioni dipendono da MongoDB e Kafka. Usare le distribuzioni Predefinite ibm in-cluster MongoDB Community Edition e Strimzi Kafka quando soddisfano i requisiti di supporto, backup e ripristino. Questa scelta è appropriata quando Kafka e MongoDB sono dipendenze MAS interne e la soluzione non le usa all'esterno di MAS.

Provare a usare servizi gestiti esterni, ad esempio MongoDB Atlas in Azure o Confluent Cloud in Azure, quando sono necessarie operazioni di backup, ridimensionamento o ripristino di emergenza più avanzate. Alcuni prerequisiti MAS, ad esempio Behavior Analytics Services (BAS), usano database che non possono essere esterni ma richiedono l'archiviazione permanente da fornire al cluster OpenShift.

Per i servizi basati su stato eseguiti all'interno del cluster OpenShift, eseguire regolarmente il backup dei dati e spostare i backup in un'altra area. Progettare, pianificare e decidere una strategia di ripristino per le emergenze, 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 Azure se possibile per migliorare il supporto durante un'interruzione.

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

Azure Red Hat OpenShift

Usare ARO come piattaforma OpenShift preferita per MAS in Azure. ARO offre un servizio OpenShift gestito in Azure, che riduce il carico operativo per l'installazione, l'applicazione di patch e l'uso della piattaforma OpenShift. Si è ancora proprietari di MAS e della configurazione dell'applicazione, della pianificazione della capacità del ruolo di lavoro, dell'integrazione della rete, dell'integrazione delle identità, delle scelte di archiviazione, della protezione dei dati e del ripristino di emergenza.

Prima di distribuire MAS in ARO, prendere in considerazione le raccomandazioni seguenti:

  • Compatibilità delle versioni. Selezionare una versione di OpenShift elencata da IBM come supportata per la versione MAS e le applicazioni MAS selezionate. Verificare che la stessa versione di OpenShift sia disponibile e supportata da ARO nell'area di Azure di destinazione. Quando possibile, selezionare una versione OpenShift numerata pari per le distribuzioni MAS di produzione, perché queste versioni sono versioni eus (Extended Update Support).

    Convalida incrociata che IBM supporti la versione di OpenShift selezionata per tutte le applicazioni e le dipendenze MAS selezionate. Se un componente MAS elenca una versione OpenShift con numeri dispari più recente come requisito in IBM SPCR, convalidare il componente completo impostato in IBM SPCR, il supporto del ciclo di vita di Red Hat e la disponibilità della versione ARO prima di scegliere la versione del cluster.

  • Percorso di distribuzione. Usare un cluster ARO esistente quando si dispone di Azure zona di destinazione, rete, identità, archiviazione e controlli operativi esistenti. Usare il percorso di installazione di IBM Azure Marketplace quando si vuole che l'automazione fornita da IBM crei o riusa l'infrastruttura OpenShift supportata. Usare Red Hat OpenShift autogestito in Azure solo quando ARO non soddisfa i requisiti.

  • Selezione dell'area. Usare un'area con zone di disponibilità , se possibile. Configurare i nodi del ruolo di lavoro ARO tra zone quando l'area di destinazione supporta tale modello. Per OpenShift autogestito, configurare il file di installazione , install-config.yaml, in modo che OpenShift inserisca i nodi tra le zone. Se si verifica un'interruzione in una zona, la soluzione può continuare a funzionare avendo nodi in altre zone che occupano il lavoro.

  • Backup e ripristino. È possibile usare le istruzioni di backup e ripristino Azure Red Hat OpenShift. Per altre informazioni, vedere Creare un backup dell'applicazione 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.

  • 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 gli endpoint e Internet per reindirizzare il traffico al cluster appropriato in un'interruzione a livello di area. In questo caso, è anche necessario eseguire la migrazione degli stati delle applicazioni e dei volumi persistenti.

OpenShift autogestito

Usare Red Hat OpenShift autogestito in Azure se ARO non soddisfa i requisiti di controllo, isolamento o distribuzione disconnessi. Per le distribuzioni autogestito, scegliere tra i metodi di installazione seguenti:

  • 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. Usare IPI quando soddisfa i requisiti di sicurezza e di rete.

  • Infrastruttura provisionata dall'utente (UPI). Questo metodo consente di controllare con granularità fine sulla distribuzione. L'UPI richiede più passaggi e considerazioni per creare il tuo ambiente. Usare l'UPI se IPI o ARO non soddisfano le proprie esigenze. Un'installazione privata o disconnessa è un caso d'uso comune per l'UPI.

Installazione air-gapped

Alcuni casi, ad esempio la conformità alle normative, potrebbero richiedere 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 per l'installazione di MAS o OpenShift in fase di esecuzione.

Nota

Le distribuzioni air-gapped richiedono l'UPI per l'installazione, ma non sono completamente testate.

Usare un'installazione air-gapped solo se 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 mirroring per la protezione da vulnerabilità della sicurezza o la gestione dei firewall possono utilizzare un impegno operativo significativo.

Per altre informazioni sulle installazioni air-gapped, vedere la documentazione di Red Hat OpenShift seguente per installazioni disconnesse e cluster privati in Azure:

Dopo un'installazione di OpenShift con air-gapped, è possibile continuare con la documentazione di MAS per indicazioni sugli ambienti disconnessi.

Dimensionamento dei nodi e dell'ambiente

Per tutti i carichi di lavoro ad eccezione di Maximo Visual Inspection, iniziare con le famiglie di macchine virtuali serie Ds o Das di generazione corrente, ad esempio Dsv6, disponibili come nodi di lavoro nell'area scelta. Scegliere le dimensioni delle macchine virtuali che supportano l'archiviazione Premium e soddisfare i requisiti di CPU, memoria e archiviazione per le applicazioni MAS distribuite.

Maximo Visual Inspection richiede che i nodi GPU eseguano l'apprendimento automatico. La soluzione usa CUDA e supporta solo GPU NVIDIA. Per ARO, scegliere una dimensione di VM GPU NVIDIA dall'elenco di supporto corrente dei nodi di lavoro ARO e quindi verificare che IBM lo supporti per le versioni MAS e OpenShift. Per OpenShift autogestito, scegliere una dimensione di VM GPU NVIDIA supportata da IBM e Red Hat.

Per i nodi di lavoro GPU, iniziare con il nodo più piccolo e aumentare le prestazioni man mano che aumentano i requisiti.

Importante

Se sono necessari computer GPU, verificare che il tipo di nodo GPU, l'operatore GPU NVIDIA, la versione OpenShift e la matrice di supporto dell'applicazione MAS siano compatibili prima della distribuzione. OpenShift 4.21 è la versione più recente elencata da IBM SPCR per Maximo Visual Inspection. Se un altro componente o dipendenza MAS richiede una versione EUS openShift numerata uniforme, scegliere una versione del cluster che soddisfi il set completo di componenti distribuiti. Non fare affidamento sulle linee guida precedenti per la versione minima di OpenShift per l'abilitazione della GPU.

Per ARO e OpenShift autogestito, usare le stesse linee guida per il ridimensionamento del carico di lavoro MAS per i nodi di lavoro. Configurare i nodi di lavoro tra zone di disponibilità per supportare la disponibilità elevata. Per OpenShift autogestito, configurare anche il piano di controllo tra le zone di disponibilità. Usare il punto di partenza seguente:

  • Nodi di controllo. Per ARO, il piano di controllo viene gestito come parte del servizio. Per OpenShift autogestito, usare almeno una macchina virtuale per zona di disponibilità all'interno dell'area selezionata.

  • Nodi di lavoro Usare almeno due computer per zona di disponibilità all'interno dell'area selezionata. Ridimensionare i nodi di lavoro in base alle linee guida IBM, alle applicazioni MAS selezionate e al carico previsto.

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, Maximo Manage per 10 utenti richiede un'altra 2 vCPU. Considerare questi valori come punti di partenza e convalidare il ridimensionamento in base ai requisiti di sistema IBM Maximo Application Suite correnti per la versione MAS 9.x, le applicazioni selezionate e l'utilizzo previsto.

Per OpenShift autogestito, provare a mantenere i tipi di macchina virtuale simili tra loro per garantire la prossimità con ognuna delle zone di disponibilità tra nodi di lavoro e di controllo. Per ARO, allineare i pool di nodi di lavoro agli stessi requisiti del carico di lavoro MAS e Azure capacità a livello di area.

Se è necessario un jump box per usare l'interfaccia della riga di comando di OpenShift oc o per installare MAS, distribuire una macchina virtuale Linux supportata che soddisfi i requisiti amministrativi e di sicurezza dell'organizzazione.

Configurazione di rete

Per ARO, usare la configurazione di rete predefinita di OpenShift distribuita da ARO a meno che IBM, Red Hat e il team di rete non convalidino un'altra opzione. Pianificare la rete virtuale e le subnet separate per nodi del piano di controllo ARO, nodi di lavoro, dipendenze del servizio Azure, endpoint privati, database e connettività ibrida. Ridimensionare le subnet del nodo per il numero di nodi di lavoro OpenShift necessari, inclusa la capacità di aggiornamento e la scalabilità orizzontale futura.

Per OpenShift autogestito, includere anche i requisiti di infrastruttura creati dal programma di installazione e bootstrap. Mantenere l'accesso amministrativo all'API OpenShift e ai nodi limitati ai percorsi di rete approvati, ad esempio connettività ibrida, jump host protetti o altri controlli richiesti dall'organizzazione. Se si limita l'uscita del cluster, pianificare le dipendenze in uscita necessarie per OpenShift, installazione MAS, pull di immagini del contenitore, aggiornamenti, monitoraggio e servizi esterni necessari.

Per un'installazione di produzione MAS standard in ARO, non iniziare con una rete virtuale strettamente compressa. Riservare uno spazio indirizzi più grande, ad esempio un prefisso CIDR (Classless Inter-Domain Routing) di /16 quando la zona di destinazione lo consente e allocare subnet dedicate. Usare almeno una dimensione di pianificazione /24 per la subnet del piano di controllo ARO e almeno una dimensione di pianificazione /24 per la subnet del nodo di lavoro. Aggiungere una subnet /27 o superiore per endpoint privati e servizi di database esterni. Se si distribuisce facoltativamente Azure Bastion, aggiungere una subnet denominata AzureBastionSubnet con un prefisso /26. Per altre informazioni sui requisiti di Azure Bastion, vedere Architettura.

Se si usa OpenShift autogestito e sono brevi negli indirizzi IP, è possibile progettare una configurazione a disponibilità elevata vincolata con un prefisso minimo di /27 per la subnet del nodo di controllo e /27 per la subnet del nodo di lavoro. Non usare questo ridimensionamento vincolato come punto di partenza per una distribuzione di produzione ARO. Non ridimensionare le subnet della rete virtuale o dei nodi. Lettura di una distribuzione OpenShift dopo l'interruzione dell'installazione e potrebbe richiedere la ridistribuzione.

Se si vuole usare un'interfaccia di rete contenitore diversa, 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

Alcuni componenti MAS usano MongoDB come archivio di metadati. Le indicazioni predefinite sono la distribuzione di MongoDB Community Edition all'interno del cluster. Se si usa questo 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 per fornire un archivio, backup e scalabilità esterni. 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, ma è probabile che i dati all'interno di Strimzi vengano persi durante il ripristino di emergenza. Se la perdita di dati all'interno di Kafka non è accettabile, prendere in considerazione l'uso di Confluent Kafka in Azure. Attualmente, Hub eventi di Azure non è supportato con gli endpoint Kafka.

MAS include diversi database nei pod e tali database mantengono i relativi stati nel file system fornito per MAS. Per assorbire gli errori della zona, usare un meccanismo di archiviazione con ridondanza della zona per conservare gli stati all'esterno dei cluster. Il modello consigliato consiste nell'usare Azure Archiviazione file con le configurazioni seguenti:

  • Standard fornisce condivisioni SMB per carichi di lavoro con velocità effettiva inferiore e ReadWriteOnce (RWO). Usare Standard per 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 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 Maximo Manage.

File di Azure NFS supporta la crittografia in transito. Se il client MAS OpenShift non può usare la crittografia NFS, è possibile esentare l'account dai criteri di imposizione del trasferimento sicuro. Per altre informazioni, vedere NFS Azure condivisioni file: Crittografia. Usare un endpoint privato per fornire connettività privata alle condivisioni.

Se si distribuisce Db2 Warehouse tramite Cloud Pak for Data, usare OpenShift Data Foundation. Per un esempio di OpenShift Data Foundation che usa le classi di archiviazione Ceph File System (CephFS) e RADOS Block Device (Ceph RBD) per diversi tipi di dati Db2 Warehouse, vedere Creazione dell'istanza db2 tramite la console Cloud Pak for Data.

Non usare Archiviazione BLOB di Azure con driver CSI (Container Storage Interface), perché non supporta i collegamenti rigidi, che alcuni pod richiedono per l'esecuzione.

Considerazioni

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

Affidabilità

OpenShift offre funzionalità predefinite per la riparazione automatica, la scalabilità e la resilienza. OpenShift e MAS prevedono che i componenti non riescano e si ripristinino. Un requisito fondamentale per la riparazione automatica è che il cluster dispone di nodi di lavoro sufficienti. Per eseguire il ripristino da un errore di zona all'interno di un'area 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 garantire che le dipendenze di archiviazione continuino a funzionare durante un errore, utilizzare l'archiviazione ridondante a zona ogni volta possibile. L'archiviazione con ridondanza della zona rimane disponibile quando una singola zona non riesce.

Per evitare errori umani, distribuire MAS usando il maggior numero possibile di automazione. Usare la documentazione di installazione di IBM corrente e l'automazione supportata per la versione MAS selezionata, la piattaforma OpenShift e il percorso di distribuzione.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'uso improprio dei dati e dei sistemi preziosi. Per maggiori informazioni, consultare la sezione Elenco di controllo per la revisione della progettazione per la sicurezza.

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

Usando le distribuzioni ARO, è possibile trarre vantaggio dal modello di responsabilità condivisa ARO. Azure Red Hat OpenShift è progettato, gestito e supportato congiuntamente da Microsoft e Red Hat, che applica patch, aggiorna e monitora la piattaforma OpenShift gestita per conto dell'utente. L'utente rimane responsabile delle distribuzioni in cima all'ARO. Questa responsabilità include MAS e la configurazione dell'applicazione, l'integrazione delle identità, i controlli di rete, la pianificazione della capacità del ruolo di lavoro, le scelte di archiviazione, il backup e il ripristino di emergenza, i segreti, la protezione dei dati e i requisiti di conformità. Per altre informazioni, vedere Introduction to Azure Red Hat OpenShift and Azure Red Hat OpenShift 4.0 support policy .for more information, see Introduction to Azure Red Hat OpenShift and Azure Red Hat OpenShift 4.0 support policy.

Microsoft crea protezioni di sicurezza nella piattaforma Azure ai livelli seguenti:

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

Usare una versione openshift supportata dalla piattaforma OpenShift e supportata da IBM per la versione e le applicazioni MAS. Quando possibile, usare una versione di supporto a lungo termine supportata. Se si usa OpenShift autogestito, si è responsabili dell'applicazione di patch e della gestione della piattaforma OpenShift e delle macchine virtuali sottostanti. Se si usa ARO, Microsoft gestisce l'applicazione di patch e la gestione.

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

  • Consentire l'accesso SSH ai nodi OpenShift per la risoluzione dei problemi.
  • Blocco dell'accesso a tutte le altre parti del cluster.
  • Controllo delle posizioni che possono accedere a MAS e al cluster OpenShift.

Per accedere alle macchine virtuali, è possibile connettersi tramite connettività ibrida o tramite la console di amministrazione di OpenShift. Se si ha una distribuzione online o non si vuole basarsi sulla connettività ibrida, è possibile accedere alle macchine virtuali tramite Azure Bastion. Per motivi di sicurezza, non 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 (SSE) di archiviazione su disco di Azure protegge i dati e consente di soddisfare gli impegni di sicurezza e conformità dell'organizzazione. Con Azure dischi gestiti, 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 l'accesso SSO con Security Assertion Markup Language (SAML). Per usare Microsoft Entra ID come provider di identità SAML, creare un'applicazione aziendale in Microsoft Entra ID e configurare MAS come provider di servizi. Per altre informazioni, vedere Microsoft Entra integrazione SSO con Maximo Application Suite.

Prima di configurare l'autenticazione basata su SAML, esaminare sia la configurazione IBM che la configurazione Azure. Per informazioni su SAML con MAS, vedere Configurazione dell'autenticazione SAML. Per informazioni su SAML con Azure, vedere Quickstart: Abilitare l'accesso Single Sign-On per un'applicazione aziendale.

È anche consigliabile configurare OAuth per l'accesso amministrativo a OpenShift. Per ARO, vedere Configurare l'autenticazione Microsoft Entra per un cluster Azure Red Hat OpenShift. Per OpenShift autogestito, vedere Configurazione dei provider di identità in OpenShift Container Platform 4.21.

Accesso alle risorse e controllo

Controllare l'accesso alle risorse Azure distribuite. Ogni sottoscrizione Azure ha una relazione trust con un tenant Microsoft Entra. Utilizzare il controllo degli accessi in base al ruolo di Azure (Azure RBAC) per concedere agli utenti dell'organizzazione le corrette autorizzazioni alle risorse di Azure. Concedere l'accesso assegnando Azure ruoli a utenti o gruppi in un determinato ambito, ad esempio una sottoscrizione, un gruppo di risorse o una singola risorsa. Controllare tutte le modifiche apportate all'infrastruttura. Per ulteriori informazioni sull'audit, vedere registro attività di Monitoraggio di Azure.

Ottimizzazione dei costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

Una distribuzione MAS standard in Azure include i driver di costo principali seguenti:

  • Costi del cluster ARO, inclusi i nodi di lavoro e gli eventuali addebiti fatturabili del piano di controllo o del cluster
  • Pool di nodi di lavoro ridimensionati per MAS Core e le applicazioni MAS distribuite
  • Nodi di lavoro GPU facoltativi per Maximo Visual Inspection
  • Servizi di database, ad esempio Istanza gestita di SQL, Db2 Warehouse o un altro database supportato da IBM
  • Account di archiviazione o servizi di archiviazione gestiti per volumi persistenti, backup e artefatti di installazione
  • Zone DNS, bilanciamento del carico, endpoint privati e un'istanza facoltativa di Azure Bastion

Sia per ARO che per OpenShift autogestito, una distribuzione MAS standard usa in genere la stessa baseline di ridimensionamento dei nodi di lavoro. Usare l'inventario seguente come punto di partenza per la stima dei costi:

  • Sei macchine virtuali di lavoro.
  • Tre macchine virtuali di lavoro per Db2 Warehouse. È possibile sostituire Istanza gestita di SQL in alcune configurazioni anziché usare Db2 Warehouse.
  • Due account Archiviazione di Azure.
  • Due zone DNS.
  • Due servizi di bilanciamento del carico.
  • Azure Bastion.
  • Un nodo di lavoro di Maximo Visual Inspection GPU, se si prevede di eseguire Maximo Visual Inspection all'interno di MAS.

Il costo del piano di controllo varia in base al modello di distribuzione. Per le distribuzioni OpenShift autogestito che usano IPI o UPI, includono anche tre macchine virtuali di controllo. Per ARO, tenere conto del piano di controllo gestito e di eventuali addebiti per cluster specifici dell'ARO anziché aggiungere macchine virtuali di controllo gestite dal cliente.

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

Distribuire lo scenario

Prima di iniziare, esaminare i requisiti di sistema di IBM Maximo Application Suite e IBM SPCR per la versione e le applicazioni MAS. Prima di avviare la distribuzione, sono disponibili le risorse seguenti:

  • Accesso a una sottoscrizione Azure con autorizzazione lettore
  • Registrazione dell'applicazione o nome dell'entità servizio con autorizzazioni collaboratore e amministratore accesso utenti per la sottoscrizione
  • Un dominio o un sottodominio delegato a una zona DNS di Azure
  • Un cluster ARO supportato o le autorizzazioni e i prerequisiti per crearne uno
  • Segreto pull da Red Hat se il percorso di distribuzione crea o gestisce l'infrastruttura OpenShift
  • Una chiave entitlement MAS
  • Un file di licenza MAS creato dopo l'installazione di MAS
  • Dimensionamento del cluster IBM consigliato
  • Una rete virtuale esistente o una nuova rete virtuale che soddisfi i requisiti ARO e MAS
  • Requisiti di disponibilità elevata e ripristino di emergenza per la distribuzione specifica
  • Dettagli di configurazione per il percorso di distribuzione selezionato, ad esempio i dettagli del cluster ARO o i parametri di installazione di OpenShift autogestito

Prima di compilare l'ambiente, vedere la documentazione di IBM Planning to install on Microsoft Azure per comprendere i parametri di progettazione. Per informazioni aggiornate sull'installazione di Azure, vedere Panoramica di Maximo Application Suite in Microsoft Azure. Convalidare il processo di distribuzione con la documentazione IBM corrente e la matrice di supporto per la versione MAS.

Considerazioni sulla distribuzione

Distribuire i carichi di lavoro usando l'infrastruttura come codice (IaC) anziché manualmente. 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à.

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

Collaboratori

Microsoft mantiene questo articolo. I seguenti collaboratori hanno scritto questo articolo.

Autori principali:

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

Passaggi successivi

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

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