IBM Maximo Application Suite implementeren op Azure

In dit artikel wordt de implementatie van IBM Maximo Application Suite (MAS) op Azure beschreven. MAS wordt uitgevoerd op Red Hat OpenShift. Azure Red Hat OpenShift (ARO) is het favoriete OpenShift-platform als het voldoet aan uw operationele, beveiligings- en netwerkvereisten. Gebruik zelfbeheerde Red Hat OpenShift alleen op Azure wanneer u controle nodig hebt dat ARO niet biedt, zoals specifieke niet-verbonden implementatiepatronen of aanpassingen op clusterniveau.

In dit artikel wordt niet nader ingegaan op het installeren van MAS. Zie Maximo Application Suite installeren voor meer informatie over de installatie.

Architectuur

In het volgende diagram ziet u een op ARO gebaseerde MAS-implementatie op Azure.

Download een Visio-bestand van deze architectuur.

U kunt de workload implementeren als een interne of externe implementatie, afhankelijk van uw vereisten. In dit artikel wordt geen openbaar of persoonlijk ARO-implementatiemodel voorgeschreven. Kies het besturingsvlak, inkomend en uitgaand verkeer op basis van de architectuur van uw Azure landingszone, waaronder de netwerktopologie, het connectiviteitsmodel, beveiligingscontroles, operationele toegangsvereisten, nalevingsvereisten en mas-gebruikerstoegangspatronen.

Wanneer IBM externe databases ondersteunt voor de MAS-toepassingen die u implementeert, probeert u deze databases te externaliseren om de status binnen het OpenShift-cluster te verminderen en databasebeheer los te koppelen van clusterbeheer.

Werkproces

Vanuit het oogpunt van de infrastructuur biedt deze architectuur de volgende mogelijkheden:

• Een Azure Red Hat OpenShift beheerde service voor het implementeren van maximaal beschikbare workloads in beschikbaarheidszones
• Een OpenShift-cluster geïntegreerd met Azure netwerken en opslag
• Azure Files Premium en Azure Files Standard voor ondersteunde MAS-opslagvereisten
• Azure SQL Managed Instance of op containers gebaseerde IBM Db2 Warehouse
• Azure DNS voor DNS-beheer (Domain Name System) van OpenShift en de bijbehorende containers
• Microsoft Entra ID voor eenmalige aanmelding (SSO) bij MAS

Onderdelen

• Azure Red Hat OpenShift (ARO) is het favoriete OpenShift-platform voor MAS op Azure. ARO vermindert uw operationele verantwoordelijkheid voor het uitvoeren van OpenShift, vergeleken met een zelfbeheerd cluster op Azure virtuele machines (VM's).

• Azure Virtuele Machines is een IaaS (Infrastructure as a Service) waarmee schaalbare computingresources op aanvraag worden geïmplementeerd. Gebruik Virtual Machines in plaats van ARO om zelfbeheerde Red Hat OpenShift te implementeren op Azure.

  Gebruik eventueel Azure Virtuele Linux-machines als jumpboxen voor mas-installatie en OpenShift-beheer. Als u een privénetwerkverbinding hebt in uw Azure-omgeving, kunt u beheer uitvoeren vanaf een bestaande beveiligde computer.

• Red Hat Enterprise Linux CoreOS biedt de installatiekopieën van het besturingssysteem voor OpenShift-knooppunten.

• Azure Load Balancer biedt connectiviteit in het cluster. Load Balancer is een high-performance laag-4 load balancing-service voor alle inkomende en uitgaande UDP-protocollen (User Datagram Protocol) en Transmission Control Protocol (TCP). Load Balancer kan miljoenen aanvragen per seconde verwerken en ervoor zorgen dat uw oplossing maximaal beschikbaar is. Load Balancer zone-redundant is, waardoor hoge beschikbaarheid in beschikbaarheidszones mogelijk is.

• Azure Virtual Network is de fundamentele bouwsteen voor privénetwerken in Azure. Gebruik Virtual Network voor communicatie tussen knooppunten en Azure-services en voor hybride connectiviteit.

• Azure Files biedt volledig beheerde bestandsshares in de cloud die toegankelijk zijn via de protocollen Server Message Block (SMB) en Network File System (NFS). Gebruik Azure Files om de stateful gegevens voor de databases en systemen in het cluster te hosten.

• Azure DNS beheert DNS-omzetting voor de containers binnen en buiten de oplossing. Azure DNS ondersteunt alle algemene DNS-records en biedt hoge beschikbaarheid.

• Azure Bastion is een volledig beheerde service die EXTERN BUREAUBLAD-protocol (RDP) en SSH-toegang (Secure Shell) biedt tot VM's zonder blootstelling via openbare IP-adressen. U kunt eventueel Azure Bastion en een subnet gebruiken voor verbeterde beveiligingstoegang tot een van de werkknooppunten of optionele jumpbox-machines.

• SQL Managed Instance biedt externe gegevensservices aan MAS wanneer IBM ondersteuning biedt voor SQL Server voor de toepassingen die u implementeert. U kunt ook een andere database kiezen, zoals Oracle Exadata of IBM Db2 Warehouse. Azure SQL Database wordt niet ondersteund.

• Twilio SendGrid verzendt e-mailberichten van MAS naar de consumenten. Als uw MAS-implementatie een e-mailservice nodig heeft voor scenario's voor meldingen en werknemers, moet u eventueel een e-mailservice zoals Twilio SendGrid opnemen in uw ontwerp.

Alternatieven

De volgende services zijn doorgaans niet nodig, maar zijn effectieve alternatieven:

• Azure NetApp Files als vervanging voor Azure Files. Azure NetApp Files ondersteunt workloads die hoge beschikbaarheid en hoge prestaties nodig hebben.
• Oracle Database op Azure indien ondersteund en u wilt deze.
• OpenShift Data Foundation als u Db2 Warehouse wilt gebruiken in OpenShift Data Foundation .

Details van het scenario

Ibm Maximo Application Suite is een enterprise asset management-platform met op AI gebaseerde assetonderhoud. MAS richt zich op operationele tolerantie en betrouwbaarheid. De suite bestaat uit het MAS Core-toepassingsplatform en de volgende toepassingen en branchespecifieke oplossingen die op het platform zijn gebouwd.

• Maximo Manage. Vermindert downtime en kosten door assetbeheer te gebruiken om de operationele prestaties te verbeteren.
• Maximo Monitor. Maakt gebruik van Internet of Things (IoT) voor geavanceerde ai-bewaking van externe assets op schaal.
• Maximo Health. Beheert de assetstatus met behulp van IoT-gegevens van sensoren, assetgegevens en onderhoudsgeschiedenis.
• Maximo Visuele inspectie. Hiermee traint u machine learning-modellen om visuele inspectie te gebruiken voor visuele analyse van opkomende problemen.
• Maximo Predict. Voorspelt toekomstige fouten met behulp van machine learning en gegevensanalyse.
• Maximo Collaborate. Ondersteunt technici met ai-richtlijnen van een knowledge base met onderhoudsgegevens voor apparatuur en biedt externe toegang tot experts.
• Maximo Health, Safety and Environment (HSE). Verbindt veiligheid, omgevingsnaleving en controle van werkprocessen met assets, locaties en werkorders.
• Maximo Civil Infrastructure. Integreert inspectie-, defecttracerings- en onderhoudsactiviteiten om de levensduur van activa te verbeteren, kritieke systemen operationeel te houden en de totale eigendomskosten van civiele infrastructuur te verlagen.
• Maximo Real Estate en Faciliteiten. Beheert vastgoedportefeuilles en faciliteitactiva met ruimtebeheer, reserveringen, kapitaalprojecten, evaluatie van faciliteitvoorwaarde, leasebeheer, bewerkingen en onderhoud.

Potentiële gebruikscases

Veel branches en sectoren maken gebruik van MAS-oplossingen, zoals de volgende gebieden:

• Nutsbedrijven
• Olie en gas
• Productie
• Reizen, auto's en vervoer
• Openbare sector

Zie IBM Maximo Application Suite op de website van IBM voor meer informatie over MAS-use cases.

Aanbevelingen

Dit artikel is geschreven voor huidige ondersteunde MAS 9.x-implementaties op Azure. Microsoft heeft samengewerkt met het IBM MAS-team en andere partners om ervoor te zorgen dat deze oplossing optimaal wordt uitgevoerd en de beste ervaring biedt op Azure. Deze documentatie, architectuur en richtlijnen volgen de best practices zoals beschreven in het Microsoft Azure Well-Architected Framework. Neem contact op met uw IBM-accountteam voor productspecifieke vragen en ondersteuning buiten deze documentatie.

Gebruik dit artikel voor architectuurrichtlijnen wanneer u ondersteuning hebt van IBM en een partner voor installatie. Azure biedt ook een installatiepad voor MAS dat ondersteuning biedt voor het meenemen van uw eigen licentie. Zie IBM Maximo Application Suite (Bring Your Own License (BYOL)) voor meer informatie.

Installeer een ondersteunde MAS-versie die IBM vermeldt als compatibel met uw geselecteerde OpenShift-versie en MAS-toepassingen. Voor nieuwe Azure-implementaties gebruikt u ARO als het gewenste OpenShift-platform, tenzij u een zelfbeheerd cluster nodig hebt.

OpenShift-ondersteuningscompatibiliteit is afhankelijk van drie overlappende ondersteuningsgrenzen: IBM MAS-compatibiliteit, ondersteuning voor red Hat OpenShift-levenscyclus en beschikbaarheid van ARO-versies. Als u een OpenShift-versie gebruikt die IBM niet vermeldt in de softwareproductcompatibiliteitsrapporten (SPCR) of die zich buiten Red Hat- of ARO-ondersteuning bevindt, kan uw MAS-implementatie niet worden ondersteund.

Voordat u uw implementatie bouwt, raadpleegt u het overzicht van IBM Maximo Application Suite, de planning om te installeren op Microsoft Azure en documentatie over softwareproductcompatibiliteitsrapporten (SPCR) om inzicht te hebben in de huidige implementatie- en configuratievereisten.

Voordat u verdergaat met uw implementatie, beantwoordt u de volgende vragen over uw ontwerp:

• Welke MAS-toepassingen hebt u nodig?
• Welke afhankelijkheden hebben uw toepassingen?
• Welke OpenShift-versie biedt IBM ondersteuning voor uw MAS-versie en -toepassingen?
• Voldoet ARO aan uw vereisten of hebt u zelfbeheerde Red Hat OpenShift nodig op Azure?
• Welke databases hebt u nodig?
• Welk aantal en grootten van VM's hebt u nodig?
• Moeten gebruikers verbinding maken vanuit externe netwerken?

Maximo Application Suite

Gebruik een huidige ondersteunde MAS 9.x-release en valideer de ondersteunde OpenShift-versies, -databases en -afhankelijkheden in IBM SPCR voordat u de architectuur voltooit. Als u een eerdere versie van Maximo Application Suite gebruikt, controleert u de status van de IBM-levenscyclus en plant u een upgrade naar een ondersteunde MAS 9.x-release.

Bekijk de MAS-toepassingen die u nodig hebt voor uw volledige bedrijfsscenario en controleer vervolgens de vereisten voor elk van de toepassingen. Zie systeemvereisten voor IBM Maximo Application Suite voor meer informatie.

Elke MAS-toepassing heeft mogelijk een afzonderlijke database nodig. Probeer databases te externaliseren als IBM een externe database voor de toepassing ondersteunt, omdat deze aanpak de hoeveelheid status vermindert die u moet uitvoeren in OpenShift. Microsoft en IBM hebben de volgende databases voor MAS getest en ondersteund op Azure:

• SQL Managed Instance
• IBM Db2 Warehouse on Cloud Pak for Data 5

Azure SQL Database en Azure Cosmos DB worden niet ondersteund.

U kunt er ook voor kiezen om Oracle Exadata uit te voeren op Oracle Cloud Infrastructure of op een VIRTUELE machine met behulp van een interconnectie. Deze configuratie wordt niet officieel getest, maar wordt gerapporteerd succesvol. Zie Interconnecting Oracle Cloud met Microsoft Azure voor meer informatie over interconnectie.

MAS en sommige toepassingen zijn afhankelijk van MongoDB en Kafka. Gebruik de standaard mongoDB Community Edition van IBM en strimzi Kafka-implementaties wanneer ze voldoen aan uw ondersteunings-, back-up- en herstelvereisten. Deze keuze is geschikt wanneer Kafka en MongoDB interne MAS-afhankelijkheden zijn en uw oplossing deze niet buiten MAS gebruikt.

Probeer externe beheerde services te gebruiken, zoals MongoDB Atlas op Azure of Confluent Cloud op Azure, wanneer u sterkere back-up-, schaal- of noodherstelbewerkingen nodig hebt. Sommige MAS-vereisten, zoals Behavior Analytics Services (BAS), gebruiken databases die niet kunnen worden ge externaliseerd, maar waarvoor permanente opslag moet worden verstrekt aan het OpenShift-cluster.

Voor statusservices die worden uitgevoerd in het OpenShift-cluster, maakt u regelmatig een back-up van gegevens en verplaatst u de back-ups naar een andere regio. Ontwerp, plan en beslis over een herstelstrategie voor noodgevallen, met name wanneer u Kafka of MongoDB uitvoert in OpenShift. Gebruik voor services die status behouden, indien mogelijk externe Azure PaaS-aanbiedingen (Platform as a Service) om de ondersteuning te verbeteren tijdens een storing.

Voor sommige services zijn mogelijk andere IBM-hulpprogramma's en -services vereist, zoals IBM Watson Machine Learning en IBM App Connect. U kunt al deze hulpprogramma's en services implementeren in hetzelfde OpenShift-cluster.

Azure Red Hat OpenShift

Gebruik ARO als het gewenste OpenShift-platform voor MAS op Azure. ARO biedt een beheerde OpenShift-service op Azure, waardoor uw operationele belasting voor het installeren, patchen en bedienen van het OpenShift-platform wordt verminderd. U bent nog steeds eigenaar van MAS en de bijbehorende toepassingsconfiguratie, planning van werkcapaciteit, netwerkintegratie, identiteitsintegratie, opslagkeuzen, gegevensbescherming en herstel na noodgevallen.

Voordat u MAS op ARO implementeert, moet u rekening houden met de volgende aanbevelingen:

• Versiecompatibiliteit. Selecteer een OpenShift-versie die IBM vermeldt als ondersteund voor uw MAS-versie en geselecteerde MAS-toepassingen. Controleer of dezelfde OpenShift-versie beschikbaar is en wordt ondersteund door ARO in uw doelregio Azure. Selecteer indien mogelijk een even genummerde OpenShift-versie voor productie-MAS-implementaties, omdat deze versies EUS-releases (Extended Update Support) zijn.

  Valideer kruislings of IBM de geselecteerde OpenShift-versie ondersteunt voor alle geselecteerde MAS-toepassingen en afhankelijkheden. Als een MAS-onderdeel een nieuwere oneven OpenShift-release als vereiste in IBM SPCR vermeldt, valideert u het volledige onderdeel dat is ingesteld op IBM SPCR, red hat-levenscyclusondersteuning en beschikbaarheid van ARO-versies voordat u de clusterversie kiest.

• Implementatiepad. Gebruik een bestaand ARO-cluster wanneer u vooraf Azure landingszone, netwerken, identiteit, opslag en operationele besturingselementen hebt. Gebruik het installatiepad van IBM Azure Marketplace wanneer u door IBM geleverde automatisering wilt gebruiken om ondersteunde OpenShift-infrastructuur te maken of opnieuw te gebruiken. Gebruik zelfbeheerde Red Hat OpenShift alleen op Azure wanneer ARO niet aan uw vereisten voldoet.

• Regioselectie. Gebruik indien mogelijk een regio met beschikbaarheidszones . Configureer ARO-werkknooppunten tussen zones wanneer de doelregio dat patroon ondersteunt. Voor zelfbeheerde OpenShift configureert u het installatiebestand install-config.yaml, zodat OpenShift knooppunten in zones plaatst. Als er een storing in een zone is, kan uw oplossing blijven functioneren door knooppunten in andere zones het werk over te nemen.

• Back-up en herstel. U kunt de instructies voor back-up en herstel van de Azure Red Hat OpenShift gebruiken. Zie Maak een Azure Red Hat OpenShift 4-clustertoepassingsback-up voor meer informatie. Als u deze methode gebruikt voor back-up en herstel, moet u een andere methode voor herstel na noodgevallen opgeven voor de database.

• Failover. Overweeg OpenShift in twee regio's te implementeren en Red Hat Advanced Cluster Management te gebruiken. Als uw oplossing openbare eindpunten heeft, kunt u Azure Traffic Manager tussen de eindpunten en internet plaatsen om verkeer om te leiden naar het juiste cluster in een regionale storing. In dat geval moet u ook de statussen en permanente volumes van uw toepassingen migreren.

Zelfbeheerde OpenShift

Gebruik zelfbeheerde Red Hat OpenShift op Azure als ARO niet voldoet aan uw vereisten voor beheer, isolatie of niet-verbonden implementatie. Voor zelfbeheerde implementaties kiest u tussen de volgende installatiemethoden:

• IPI (Provisioned Infrastructure) van het installatieprogramma. Deze methode maakt gebruik van een installatieprogramma voor het implementeren en configureren van de OpenShift-omgeving op Azure. Gebruik IPI wanneer deze voldoet aan uw beveiligings- en netwerkvereisten.

• Door de gebruiker ingerichte infrastructuur (UPI). Met deze methode kunt u gedetailleerde controle over uw implementatie uitvoeren. UPI vereist meer stappen en overwegingen om uw omgeving te bouwen. Gebruik UPI als IPI of ARO niet aan uw behoeften voldoet. Een privé- of niet-verbonden installatie is een veelvoorkomend gebruiksvoorbeeld voor UPI.

Air-gapped installatie

In sommige gevallen, zoals naleving van regelgeving, is mogelijk een installatie met een air-gapped van MAS op Azure vereist. Air-gapped betekent dat er geen inkomende of uitgaande internettoegang is. Zonder internetverbinding kan uw installatie de afhankelijkheden voor MAS- of OpenShift-installatie tijdens runtime niet ophalen.

Gebruik alleen een air-gapped-installatie als dit een beveiligingsvereiste is. Een luchtgat voegt aanzienlijke complexiteit toe aan oplossingsbewerkingen. Activiteiten zoals het installeren van software, het spiegelen van containers, het bijwerken van mirrors om bescherming te bieden tegen beveiligingsproblemen of het beheren van firewalls kan aanzienlijke operationele inspanningen vergen.

Zie de volgende Red Hat OpenShift-documentatie voor niet-verbonden installaties en privéclusters op Azure voor meer informatie over air-gapped-installaties:

• Installatiekopieën spiegelen voor een niet-verbonden installatie met oc-mirror
• Een privécluster installeren op Azure

Na een openshift-installatie met air-gapped kunt u doorgaan met de MAS-documentatie voor hulp bij niet-verbonden omgevingen.

Grootte van knooppunt en omgeving

Voor alle workloads behalve Maximo Visual Inspection begint u met Ds- of Das-serie VM-families van de huidige generatie, zoals Dsv6, die beschikbaar zijn als werkknooppunten in uw gekozen regio. Kies VM-grootten die premium-opslag ondersteunen en voldoen aan de CPU-, geheugen- en opslagvereisten voor de MAS-toepassingen die u implementeert.

Maximo Visual Inspection vereist GPU-knooppunten om de machine learning uit te voeren. De oplossing maakt gebruik van CUDA en ondersteunt alleen NVIDIA GPU's. Voor ARO kiest u een NVIDIA GPU VM-grootte in de huidige ondersteuningslijst voor ARO-werkknooppunten en bevestigt u vervolgens dat IBM deze ondersteunt voor uw MAS- en OpenShift-versies. Kies voor zelfbeheerde OpenShift een NVIDIA GPU VM-grootte die wordt ondersteund door IBM en Red Hat.

Voor GPU-werkknooppunten begint u met het kleinste knooppunt en schaalt u omhoog naarmate uw vereisten toenemen.

Gebruik voor ARO en zelfbeheerde OpenShift dezelfde richtlijnen voor de grootte van mas-werkbelastingen voor werkknooppunten. Configureer werkknooppunten in beschikbaarheidszones ter ondersteuning van hoge beschikbaarheid. Voor zelfbeheerde OpenShift configureert u ook het besturingsvlak tussen beschikbaarheidszones. Gebruik het volgende uitgangspunt:

• Besturingsknooppunten. Voor ARO wordt het besturingsvlak beheerd als onderdeel van de service. Voor zelfbeheerde OpenShift gebruikt u minimaal één VM per beschikbaarheidszone binnen de geselecteerde regio.

• Werkknooppunten. Gebruik minimaal twee machines per beschikbaarheidszone binnen de geselecteerde regio. Werkknooppunten aanpassen op basis van IBM-richtlijnen, geselecteerde MAS-toepassingen en verwachte belasting.

MAS-kern vereist 13 vCPU's voor een standaardbasisinstallatie. De grootte van de werkknooppunten varieert op basis van de MAS-toepassingen die uw configuratie implementeert en de belasting van uw omgeving. Maximo Manage voor 10 gebruikers vereist bijvoorbeeld nog 2 vCPU's. Behandel deze waarden als uitgangspunten en valideer de grootte op basis van de huidige systeemvereisten van IBM Maximo Application Suite voor uw MAS 9.x-versie, geselecteerde toepassingen en verwacht gebruik.

Probeer voor zelfbeheerde OpenShift VM-typen op elkaar te houden om nabijheid te bieden met elk van de beschikbaarheidszones tussen werkrol- en besturingsknooppunten. Voor ARO kunt u werkknooppuntgroepen uitlijnen op dezelfde vereisten voor MAS-werkbelastingen en Azure regionale capaciteit.

Als u een jumpbox nodig hebt om de OpenShift-opdrachtregelinterface oc te gebruiken of MAS te installeren, implementeert u een ondersteunde Linux-VM die voldoet aan de beheer- en beveiligingsvereisten van uw organisatie.

Netwerkconfiguratie

Gebruik voor ARO de standaardconfiguratie voor OpenShift-netwerken die ARO implementeert, tenzij IBM, Red Hat en uw netwerkteam een andere optie valideren. Plan het virtuele netwerk en afzonderlijke subnetten voor ARO-besturingsvlakknooppunten, werkknooppunten, Azure serviceafhankelijkheden, privé-eindpunten, databases en hybride connectiviteit. Wijzig de grootte van de knooppuntsubnetten voor het aantal OpenShift-werkknooppunten dat u nodig hebt, inclusief upgradecapaciteit en toekomstige uitschalen.

Voor zelfbeheerde OpenShift moet u ook bootstrap- en door het installatieprogramma gemaakte infrastructuurvereisten opnemen. Houd beheerderstoegang tot de OpenShift-API en knooppunten beperkt tot goedgekeurde netwerkpaden, zoals hybride connectiviteit, beveiligde jumphosts of andere besturingselementen die uw organisatie nodig heeft. Als u het uitgaand verkeer van clusters beperkt, plant u de vereiste uitgaande afhankelijkheden voor OpenShift, MAS-installatie, pulls, updates, bewaking en externe services voor containerinstallatiekopieën.

Voor een standaard-MAS-productie-installatie op ARO begint u niet met een strak verpakt virtueel netwerk. Reserveer een grotere adresruimte, zoals een CIDR-voorvoegsel (Classless Inter-Domain Routing) van /16 wanneer uw landingszone dit toestaat en wijs toegewezen subnetten toe. Gebruik ten minste een /24-planningsgrootte voor het subnet van het ARO-besturingsvlak en ten minste een /24-planningsgrootte voor het subnet van het werkknooppunt. Voeg een /27 of groter subnet toe voor privé-eindpunten en externe databaseservices. Als u optioneel Azure Bastion implementeert, voegt u een subnet met de naam AzureBastionSubnet toe met een voorvoegsel van /26. Zie Architectuur voor meer informatie over Azure Bastion vereisten.

Als u zelfbeheerde OpenShift gebruikt en ip-adressen kort is, kunt u een beperkte configuratie met hoge beschikbaarheid ontwerpen met een minimumvoorvoegsel van /27 voor het subnet van het beheerknooppunt en /27 voor het subnet van het werkknooppunt. Gebruik deze beperkte grootte niet als uitgangspunt voor een ARO-productie-implementatie. Besize het virtuele netwerk of de subnetten van het knooppunt niet. Leesbewerking van een OpenShift-implementatie nadat de installatie verstorend is en kan herimplementatie vereisen.

Als u een andere CNI (Container Network Interface) wilt gebruiken, moet u de grootte van uw netwerken dienovereenkomstig aanpassen. MAS met sommige standaardtoepassingen implementeert meer dan 800 pods, waarvoor waarschijnlijk een CIDR-voorvoegsel van /21 of groter is vereist.

Databasespecifieke gegevens

Sommige MAS-onderdelen gebruiken MongoDB als metagegevensarchief. De standaardrichtlijnen zijn het implementeren van MongoDB Community Edition in het cluster. Als u deze methode gebruikt, moet u ervoor zorgen dat u een juiste procedure hebt voor het maken van back-ups en het herstellen van de database. Overweeg om MongoDB Atlas op Azure te gebruiken om een extern archief, back-ups en schaalaanpassing te bieden. Azure biedt momenteel geen ondersteuning voor het gebruik van MongoDB-API's met Azure Cosmos DB.

Als u IoT-services implementeert, moet u ook een Kafka-eindpunt opgeven. De standaardrichtlijnen zijn het gebruik van Strimzi om Kafka in het OpenShift-cluster te implementeren, maar gegevens in Strimzi gaan waarschijnlijk verloren tijdens herstel na noodgevallen. Als gegevensverlies in Kafka onaanvaardbaar is, kunt u overwegen Confluent Kafka te gebruiken op Azure. Momenteel wordt Azure Event Hubs niet ondersteund met Kafka-eindpunten.

MAS bevat verschillende databases in de pods en die databases behouden hun statussen op het bestandssysteem dat voor MAS is opgegeven. Als u zonefouten wilt opvangen, gebruikt u een ZRS-mechanisme (Zone-redundante opslag) om de statussen buiten uw clusters te behouden. Het aanbevolen patroon is om Azure File Storage te gebruiken met de volgende configuraties:

• Standard biedt SMB-shares voor lagere doorvoer- en READWriteOnce-workloads (RWO). Gebruik Standard voor onderdelen van de toepassing die niet vaak naar de opslag schrijven en waarvoor één permanent volume is vereist, zoals IBM-opslag op één niveau.

• Premium biedt NFS-shares voor hogere doorvoer- en READWriteMany-workloads (RWX). Volumes zoals deze worden gebruikt in het cluster voor RWX-workloads, zoals Db2 Warehouse in Cloud Pak for Data of Postgres in Maximo Manage.

Azure Files NFS ondersteunt versleuteling tijdens overdracht. Als de MAS OpenShift-client geen NFS-versleuteling kan gebruiken, kunt u het account uitsluiten van beveiligingsbeleid voor overdracht afdwingen. Zie NFS Azure bestandsshares voor meer informatie: Versleuteling. Gebruik een privé-eindpunt om privéconnectiviteit met uw shares te bieden.

Als u Db2 Warehouse implementeert via Cloud Pak for Data, gebruikt u OpenShift Data Foundation. Voor een OpenShift Data Foundation-voorbeeld dat gebruikmaakt van Ceph File System (CephFS) en RADOS Block Device (Ceph RBD) opslagklassen voor verschillende Db2 Warehouse-gegevenstypen, raadpleegt u Het db2-exemplaar maken met behulp van de Cloud Pak for Data-console.

Gebruik geen Azure Blob Storage met CSI-stuurprogramma's (Container Storage Interface), omdat deze geen ondersteuning biedt voor harde koppelingen, waarvoor sommige pods moeten worden uitgevoerd.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die u kunt gebruiken om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Betrouwbaarheid

OpenShift heeft ingebouwde mogelijkheden voor zelfherstel, schalen en tolerantie. OpenShift en MAS verwachten dat onderdelen mislukken en herstellen. Een belangrijke vereiste voor zelfherstel is dat het cluster voldoende werkknooppunten heeft. Als u wilt herstellen van een zonefout binnen een Azure regio, moeten uw besturings- en werkknooppunten worden verdeeld over beschikbaarheidszones.

MAS en OpenShift maken gebruik van opslag om de status buiten het Kubernetes-cluster te behouden. Gebruik waar mogelijk zone-redundante opslag om ervoor te zorgen dat de opslagafhankelijkheden blijven werken tijdens een storing. Zone-redundante opslag blijft beschikbaar wanneer één zone uitvalt.

Implementeer MAS door zoveel mogelijk automatisering te gebruiken om menselijke fouten te voorkomen. Gebruik de huidige IBM-installatiedocumentatie en ondersteunde automatisering voor uw geselecteerde MAS-versie, OpenShift-platform en implementatiepad.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Ontwerpcontrolelijst voor beveiliging voor meer informatie.

Het onderhouden van toegang en zichtbaarheid in de onderhoudslevenscyclus van uw assets kan een van de grootste mogelijkheden van uw organisatie zijn om efficiënt te werken en uptime te behouden. Om de beveiligingsstatus van uw omgeving te verbeteren, is het belangrijk om veilige verificatie te gebruiken en uw oplossingen up-to-date te houden. Gebruik versleuteling om alle gegevens te beveiligen die in en uit uw architectuur worden verplaatst.

Met behulp van ARO-implementaties profiteert u van het ARO-model voor gedeelde verantwoordelijkheid. Azure Red Hat OpenShift wordt gezamenlijk ontworpen, beheerd en ondersteund door Microsoft en Red Hat, die namens u het beheerde OpenShift-platform patchen, bijwerken en bewaken. U blijft verantwoordelijk voor implementaties boven op ARO. Deze verantwoordelijkheid omvat MAS en de toepassingsconfiguratie, identiteitsintegratie, netwerkcontroles, planning van werkcapaciteit, opslagkeuzes, back-up en herstel na noodgevallen, geheimen, gegevensbescherming en nalevingsvereisten. Zie Inleiding tot Azure Red Hat OpenShift en Azure Red Hat OpenShift 4.0-ondersteuningsbeleid voor meer informatie.

Microsoft bouwt beveiligingsbeveiligingen op het Azure platform op de volgende niveaus:

• Fysiek datacenter
• Fysiek netwerk
• Fysieke host
• Hypervisor

Gebruik een OpenShift-versie die door uw OpenShift-platform wordt ondersteund en die IBM ondersteunt voor uw MAS-versie en -toepassingen. Gebruik indien mogelijk een ondersteunde langetermijnondersteuningsrelease. Als u zelfbeheerde OpenShift gebruikt, bent u verantwoordelijk voor het patchen en onderhouden van het OpenShift-platform en de onderliggende VM's. Als u ARO gebruikt, Microsoft de patching en het beheer afhandelt.

Gebruik netwerkbeveiligingsgroepen om netwerkverkeer naar en van resources in uw virtuele netwerk te filteren. Met behulp van deze groepen kunt u regels definiëren waarmee toegang tot uw MAS-services wordt verleend of geweigerd, zoals:

• SSH-toegang tot de OpenShift-knooppunten toestaan voor probleemoplossing.
• Toegang tot alle andere onderdelen van het cluster blokkeren.
• Bepalen welke locaties toegang hebben tot MAS en het OpenShift-cluster.

Voor toegang tot uw VM's kunt u verbinding maken via hybride connectiviteit of via de OpenShift-beheerconsole. Als u een onlineimplementatie hebt of niet wilt vertrouwen op hybride connectiviteit, hebt u toegang tot uw VM's via Azure Bastion. Maak vm's om veiligheidsredenen niet beschikbaar voor een netwerk of internet zonder netwerkbeveiligingsgroepen te configureren om de toegang te beheren.

Versleuteling aan de serverzijde (SSE) van Azure Disk Storage beschermt uw gegevens en helpt u te voldoen aan de beveiligings- en nalevingsverplichtingen van de organisatie. Met Azure beheerde schijven versleutelt SSE data-at-rest bij het persistent maken van gegevens in de cloud. Dit gedrag is standaard van toepassing op zowel besturingssysteem- als gegevensschijven. OpenShift maakt standaard gebruik van SSE.

Verificatie

MAS ondersteunt eenmalige aanmelding met Security Assertion Markup Language (SAML). Als u Microsoft Entra ID wilt gebruiken als de SAML-id-provider, maakt u een bedrijfstoepassing in Microsoft Entra ID en configureert u MAS als serviceprovider. Zie Microsoft Entra SSO-integratie met Maximo Application Suite voor meer informatie.

Voordat u verificatie op basis van SAML instelt, controleert u zowel de IBM-configuratie als de Azure-configuratie. Zie SAML-verificatie configureren voor meer informatie over SAML met MAS. Zie Quickstart: Eenmalige aanmelding inschakelen voor een bedrijfstoepassing voor informatie over SAML met Azure.

U moet ook OAuth configureren voor OpenShift-beheerderstoegang. Zie Microsoft Entra-verificatie configureren voor een Azure Red Hat OpenShift-cluster voor ARO. Zie Id-providers configureren in OpenShift Container Platform 4.21 voor zelfbeheerde OpenShift.

Toegang en controle van resources

Beheer de toegang tot de Azure resources die u implementeert. Elk Azure-abonnement heeft een vertrouwensrelatie met een Microsoft Entra-tenant. Gebruik op Azure-rollen gebaseerd toegangsbeheer (Azure RBAC) om gebruikers binnen uw organisatie de juiste machtigingen voor Azure-resources te verlenen. Verwijs toegang door Azure rollen toe te wijzen aan gebruikers of groepen binnen een bepaald bereik, zoals een abonnement, resourcegroep of één resource. Controleer alle wijzigingen in de infrastructuur. Zie Azure Monitor activiteitenlogboek voor meer informatie over controle.

Kostenoptimalisatie

Kostenoptimalisatie richt zich op manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie controlelijst ontwerpbeoordeling voor kostenoptimalisatievoor meer informatie.

Een standaard MAS-implementatie op Azure bevat de volgende primaire kostenfactoren:

• ARO-clusterkosten, inclusief werkknooppunten en eventuele factureerbare besturingsvlak- of clusterkosten
• Werkknooppuntgroepen van grootte voor MAS Core en de MAS-toepassingen die u implementeert
• Optionele GPU-werkknooppunten voor Maximo-visuele inspectie
• Databaseservices, zoals SQL Managed Instance, Db2 Warehouse of een andere door IBM ondersteunde database
• Opslagaccounts of beheerde opslagservices voor permanente volumes, back-ups en installatieartefacten
• DNS-zones, taakverdeling, privé-eindpunten en een optioneel exemplaar van Azure Bastion

Voor zowel ARO als zelfbeheerde OpenShift gebruikt een standaard MAS-implementatie doorgaans dezelfde basislijn voor het aanpassen van de grootte van werkknooppunten. Gebruik de volgende inventaris als uitgangspunt voor kostenramingen:

• Zes werkrol-VM's.
• Drie werkrol-VM's voor Db2 Warehouse. U kunt SQL Managed Instance in sommige configuraties vervangen in plaats van Db2 Warehouse te gebruiken.
• Twee Azure Storage accounts.
• Twee DNS-zones.
• Twee load balancers.
• Azure Bastion.
• Eén Maximo Visual Inspection GPU-werkknooppunt, als u Maximo Visual Inspection binnen MAS wilt uitvoeren.

De kosten van het besturingsvlak verschillen per implementatiemodel. Voor zelfbeheerde OpenShift-implementaties die gebruikmaken van IPI of UPI, bevatten ook drie besturings-VM's. Voor ARO moet u rekening houden met het beheerde besturingsvlak en eventuele ARO-specifieke clusterkosten in plaats van door de klant beheerde beheer-VM's toe te voegen.

U kunt een voorbeeldschatting bekijken met behulp van de kostencalculator. Configuraties variëren, dus controleer uw configuratie met uw IBM-grootteteam voordat u de implementatie voltooit.

Dit scenario implementeren

Voordat u begint, controleert u de systeemvereisten van IBM Maximo Application Suite en IBM SPCR voor uw MAS-versie en -toepassingen. Zorg ervoor dat de volgende resources beschikbaar zijn voordat u de implementatie start:

• Toegang tot een Azure-abonnement met de machtiging Lezer
• Een toepassingsregistratie of service-principalnaam met de machtigingen Inzender en Beheerder voor gebruikerstoegang voor het abonnement
• Een domein of gedelegeerd subdomein naar een Azure DNS zone
• Een ondersteund ARO-cluster of de machtigingen en vereisten om er een te maken
• Een pull-geheim van Red Hat als uw implementatiepad OpenShift-infrastructuur maakt of beheert
• Een MAS-rechtensleutel
• Een MAS-licentiebestand dat u maakt na de installatie van MAS
• Ibm-aanbevolen clustergrootte
• Een bestaand virtueel netwerk of een nieuw virtueel netwerk dat voldoet aan de ARO- en MAS-vereisten
• Vereisten voor hoge beschikbaarheid en herstel na noodgevallen voor uw specifieke implementatie
• Configuratiedetails voor het geselecteerde implementatiepad, zoals ARO-clusterdetails of zelfbeheerde OpenShift-installatieparameters

Voordat u uw omgeving bouwt, raadpleegt u de IBM-planning om te installeren op Microsoft Azure documentatie om inzicht te hebben in de ontwerpparameters. Zie Maximo Application Suite in Microsoft Azure overzicht voor de huidige Azure-installatierichtlijnen. Valideer uw implementatieproces op basis van de huidige IBM-documentatie en de ondersteuningsmatrix voor uw MAS-versie.

Implementatieoverwegingen

Implementeer workloads met behulp van infrastructuur als code (IaC) in plaats van handmatig. Handmatige implementatie kan leiden tot onjuiste configuratie. Workloads op basis van containers kunnen gevoelig zijn voor onjuiste configuratie, waardoor de productiviteit kan worden verminderd.

IBM biedt gespecialiseerde diensten om u te helpen bij de installatie. Neem contact op met uw IBM-team voor ondersteuning.

Bijdragers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.

Belangrijkste auteurs:

• David Baumgarten | Hoofdarchitect
• Roeland Nieuwenhuis | Hoofdarchitect

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

Zie de volgende bronnen voor hulp bij het aan de slag gaan:

• Azure Red Hat OpenShift
• Overzicht van Maximo Application Suite op Microsoft Azure
• Plannen om te installeren op Microsoft Azure
• OpenShift installeren in Azure
• OpenShift UPI Guide
• Vereisten voor Maximo
• Compatibiliteitsrapporten voor IBM-softwareproduct
• IBM Maximo Application Suite (BYOL)

Zie de volgende bronnen voor meer informatie over de aanbevolen technologieën:

• IBM Passport Advantage
• Invoer voor Azure DNS
• Invoer voor Azure NetApp Files
• Inleiding tot Azure Red Hat OpenShift
• Red Hat-klantportal

Verwante bronnen

• Azure enterprise-cloudbestandsshare
• Een Java-toepassing implementeren met JBoss Enterprise Application Platform (EAP) op een ARO-cluster