Distribuera IBM Maximo Application Suite på Azure

Den här artikeln beskriver DISTRIBUTIONen av IBM Maximo Application Suite (MAS) på Azure. MAS körs på Red Hat OpenShift. Azure Red Hat OpenShift (ARO) är den bästa OpenShift-plattformen om den uppfyller dina drift-, säkerhets- och nätverkskrav. Använd självhanterad Red Hat OpenShift på Azure endast när du behöver kontroll som ARO inte tillhandahåller, till exempel specifika frånkopplade distributionsmönster eller anpassning på klusternivå.

Den här artikeln går inte in i detalj på hur du installerar MAS. Mer information om installation finns i Installera Maximo Application Suite.

Arkitektur

Följande diagram illustrerar en ARO-baserad MAS-distribution på Azure.

Ladda ned en Visio fil i den här arkitekturen.

Du kan distribuera arbetsbelastningen som en intern eller extern distribution, beroende på dina krav. Den här artikeln föreskriver inte någon offentlig eller privat ARO-distributionsmodell. Välj kontrollplanet, ingress- och utgående arkitekturen baserat på arkitekturen för din Azure landningszon, inklusive nätverkstopologi, anslutningsmodell, säkerhetskontroller, krav på driftåtkomst, efterlevnadskrav och MAS-användaråtkomstmönster.

När IBM har stöd för externa databaser för MAS-program som du distribuerar kan du försöka externalisera dessa databaser för att minska tillståndet i OpenShift-klustret och frikoppla databashantering från klusterhantering.

Arbetsflöde

Ur ett infrastrukturperspektiv tillhandahåller den här arkitekturen följande funktioner:

• En Azure Red Hat OpenShift hanterad tjänst för att distribuera arbetsbelastningar med hög tillgänglighet mellan tillgänglighetszoner
• Ett OpenShift-kluster integrerat med Azure nätverk och lagring
• Azure Files Premium och Azure Files Standard för maslagringskrav som stöds
• Azure SQL Managed Instance eller containerbaserat IBM Db2 Warehouse
• Azure DNS för DNS-hantering (Domain Name System) av OpenShift och dess containrar
• Microsoft Entra ID för enkel inloggning (SSO) i MAS

Komponenter

• Azure Red Hat OpenShift (ARO) är den föredragna OpenShift-plattformen för MAS på Azure. ARO minskar ditt operativa ansvar för att köra OpenShift, jämfört med ett självhanterat kluster på Azure virtuella datorer (VM).

• Azure Virtual Machines är en infrastruktur som en tjänst (IaaS) som distribuerar skalbara beräkningsresurser på begäran. Använd Virtual Machines i stället för ARO för att distribuera självhanterade Red Hat OpenShift på Azure.

  Du kan också använda Azure virtuella Linux-datorer som hopprutor för MAS-installation och OpenShift-administration. Om du har en privat nätverksanslutning till din Azure miljö kan du utföra administration från en befintlig skyddad dator.

• Red Hat Enterprise Linux CoreOS tillhandahåller operativsystemavbildningen för OpenShift-noder.

• Azure Load Balancer ger anslutning till klustret. Load Balancer är en belastningsutjämningstjänst med höga prestanda och extremt låg latens layer-4 för alla inkommande och utgående PROTOKOLL för Användardatagram (UDP) och TCP (Transmission Control Protocol). Load Balancer kan hantera miljontals begäranden per sekund samtidigt som lösningen är mycket tillgänglig. Load Balancer är zonredundant, vilket säkerställer hög tillgänglighet mellan tillgänglighetszoner.

• Azure Virtual Network är den grundläggande byggstenen för privata nätverk i Azure. Använd Virtual Network för kommunikation mellan noder och Azure tjänster och för hybridanslutning.

• Azure Files tillhandahåller fullständigt hanterade filresurser i molnet som är tillgängliga via protokollen Server Message Block (SMB) och Network File System (NFS). Använd Azure Files för att vara värd för tillståndskänsliga data för databaser och system i klustret.

• Azure DNS hanterar DNS-matchning för containrarna i och utanför lösningen. Azure DNS stöder alla vanliga DNS-poster och ger hög tillgänglighet.

• Azure Bastion är en fullständigt hanterad tjänst som ger fjärrskrivbordsprotokoll (RDP) och SSH-åtkomst (Secure Shell) åtkomst till virtuella datorer utan någon exponering via offentliga IP-adresser. Du kan också använda Azure Bastion och ett undernät för förbättrad säkerhetsåtkomst till någon av arbetsnoderna eller valfria jump box-datorer.

• SQL Managed Instance tillhandahåller externa datatjänster till MAS när IBM stöder SQL Server för de program som du distribuerar. Du kan också välja en annan databas, till exempel Oracle Exadata eller IBM Db2 Warehouse. Azure SQL Database stöds inte.

• Twilio SendGrid skickar e-postmeddelanden från MAS till sina konsumenter. Om MAS-distributionen behöver en e-posttjänst för scenarier för aviseringar och personalutskick kan du även lägga till en e-posttjänst som Twilio SendGrid i din design.

Alternativ

Följande tjänster är vanligtvis inte nödvändiga, men är effektiva alternativ:

• Azure NetApp Files som ersättning för Azure Files. Azure NetApp Files stöder arbetsbelastningar som behöver hög tillgänglighet och höga prestanda.
• Oracle Database på Azure om det stöds och du föredrar det.
• OpenShift Data Foundation om du vill använda Db2 Warehouse på OpenShift Data Foundation.

Information om scenario

IBM Maximo Application Suite är en företagsplattform för tillgångshantering med AI-baserat tillgångsunderhåll. MAS fokuserar på driftåterhämtning och tillförlitlighet. Sviten består av MAS Core-programplattformen och följande program och branschspecifika lösningar som bygger på plattformen.

• Maximo Hantera. Minskar stilleståndstiden och kostnaderna genom att använda tillgångshantering för att förbättra driftprestandan.
• Maximo Monitor. Använder Sakernas Internet (IoT) för avancerad AI-baserad övervakning av fjärrtillgångar i stor skala.
• Maximo Health. Hanterar tillgångshälsa med hjälp av IoT-data från sensorer, tillgångsdata och underhållshistorik.
• Maximo Visual Inspection. Tränar maskininlärningsmodeller att använda visuell inspektion för visuell analys av nya problem.
• Maximo Predict. Förutsäger framtida fel med hjälp av maskininlärning och dataanalys.
• Maximo Samarbeta. Stöder tekniker med AI-baserad vägledning från en kunskapsbas med underhållsdata för utrustning och ger fjärråtkomst till experter.
• Maximo Health, Safety and Environment (HSE). Kopplar säkerhet, miljöefterlevnad och kontroll av arbetsprocesser till tillgångar, platser och arbetsorder.
• Maximo Civil Infrastructure. Integrerar inspektions-, defektspårnings- och underhållsaktiviteter för att förbättra tillgångens livslängd, hålla kritiska system i drift och sänka de totala ägandekostnaderna för den civila infrastrukturen.
• Maximo Fastigheter och faciliteter. Hanterar fastighetsportföljer och anläggningstillgångar med utrymmeshantering, reservationer, kapitalprojekt, utvärdering av anläggningsvillkor, leasinghantering, drift och underhåll.

Potentiella användningsfall

Många branscher och sektorer använder MAS-lösningar, till exempel följande områden:

• El, vatten m.m.
• Olja och gas
• Tillverkning
• Resor, fordon och transport
• Offentlig sektor

Mer information om MAS-användningsfall finns i IBM Maximo Application Suite på IBM:s webbplats.

Rekommendationer

Den här artikeln är skriven för aktuella MAS 9.x-distributioner som stöds på Azure. Microsoft arbetat med IBM MAS-teamet och andra partner för att säkerställa att den här lösningen är konfigurerad för att köras optimalt och ge bästa möjliga upplevelse på Azure. Den här dokumentationen, arkitekturen och vägledningen följer de metodtips som beskrivs i Microsoft Azure Well-Architected Framework. Kontakta IBM-kontoteamet för produktspecifika frågor och support utöver den här dokumentationen.

Använd den här artikeln för arkitekturvägledning när du har stöd från IBM och en partner för installation. Azure erbjuder också en installationssökväg för MAS som har stöd för att ta med din egen licens. Mer information finns i IBM Maximo Application Suite (bring your own license (BYOL)).

Installera en MAS-version som stöds och som IBM listar som kompatibel med din valda OpenShift-version och MAS-program. För nya Azure distributioner använder du ARO som önskad OpenShift-plattform om du inte behöver ett självhanterat kluster.

OpenShift-supportkompatibilitet beror på tre överlappande stödgränser: IBM MAS-kompatibilitet, Red Hat OpenShift-livscykelstöd och tillgänglighet för ARO-versioner. Om du använder en OpenShift-version som IBM inte listar i SPCR (Software Product Compatibility Reports) eller som är utanför Red Hat- eller ARO-supporten kan din MAS-distribution inte stödjas.

Innan du skapar distributionen kan du läsa översikten över IBM Maximo Application Suite, Planera installationen på Microsoft Azure och SPCR-dokumentationen (Software Product Compatibility Reports) för att förstå de aktuella distributions- och konfigurationskraven.

Innan du fortsätter med distributionen svarar du på följande frågor om din design:

• Vilka MAS-program behöver du?
• Vilka beroenden har dina program?
• Vilken OpenShift-version stöder IBM för din MAS-version och dina program?
• Uppfyller ARO dina krav eller behöver du självhanterad Red Hat OpenShift på Azure?
• Vilka databaser behöver du?
• Vilket antal och storlekar på virtuella datorer behöver du?
• Behöver användarna ansluta från externa nätverk?

Maximo Application Suite

Använd en aktuell MAS 9.x-version som stöds och verifiera de OpenShift-versioner, databaser och beroenden som stöds i IBM SPCR innan du slutför arkitekturen. Om du har en tidigare version av Maximo Application Suite granskar du dess IBM-livscykelstatus och planerar en uppgradering till en MAS 9.x-version som stöds.

Granska de MAS-program som du behöver för ditt fullständiga affärsscenario och granska sedan kraven för vart och ett av programmen. Mer information finns i IBM Maximo Application Suite systemkrav.

Varje MAS-program kan behöva en separat databas. Försök att externalisera databaser om IBM stöder en extern databas för programmet, eftersom den metoden minskar mängden tillstånd som du måste använda i OpenShift. Microsoft och IBM har testat och stöder följande databaser för MAS på Azure:

• SQL Managed Instance
• IBM Db2 Warehouse på Cloud Pak för Data 5

Azure SQL Database och Azure Cosmos DB stöds inte.

Du kan också välja att köra Oracle Exadata på Oracle Cloud Infrastructure eller på en virtuell dator med hjälp av en sammanlänkning. Den här konfigurationen testas inte officiellt, men har enligt uppgift lyckats. Mer information om sammankoppling finns i Interconnecting Oracle Cloud with Microsoft Azure.

MAS och vissa av dess program är beroende av MongoDB och Kafka. Använd IBM-standarddistributionerna MongoDB Community Edition och Strimzi Kafka i klustret när de passar dina support-, säkerhetskopierings- och återställningskrav. Det här valet är lämpligt när Kafka och MongoDB är interna MAS-beroenden och lösningen inte använder dem utanför MAS.

Försök att använda externa hanterade tjänster, till exempel MongoDB Atlas på Azure eller Confluent Cloud på Azure, när du behöver starkare säkerhetskopierings-, skalnings- eller haveriberedskapsåtgärder. Vissa MAS-krav, till exempel Behavior Analytics Services (BAS), använder databaser som inte kan externaliseras men som kräver att beständig lagring tillhandahålls till OpenShift-klustret.

För tillståndsbaserade tjänster som körs i OpenShift-klustret säkerhetskopierar du regelbundet data och flyttar säkerhetskopiorna till en annan region. Utforma, planera och besluta om en återställningsstrategi för katastrofer, särskilt när du kör Kafka eller MongoDB i OpenShift. För tjänster som behåller tillståndet använder du paaS-erbjudanden (external Azure platform as a service) om möjligt för att förbättra supporten under ett avbrott.

Vissa tjänster kan kräva andra IBM-verktyg och -tjänster, till exempel IBM Watson strojové učenie och IBM App Connect. Du kan distribuera alla dessa verktyg och tjänster i samma OpenShift-kluster.

Azure Red Hat OpenShift

Använd ARO som önskad OpenShift-plattform för MAS på Azure. ARO tillhandahåller en hanterad OpenShift-tjänst på Azure, vilket minskar driftbelastningen vid installation, korrigering och drift av OpenShift-plattformen. Du äger fortfarande MAS och dess programkonfiguration, planering av arbetskapacitet, nätverksintegrering, identitetsintegrering, lagringsalternativ, dataskydd och haveriberedskap.

Innan du distribuerar MAS på ARO bör du överväga följande rekommendationer:

• Versionskompatibilitet. Välj en OpenShift-version som IBM listar som stöds för din MAS-version och valda MAS-program. Bekräfta att samma OpenShift-version är tillgänglig och stöds av ARO i målregionen Azure. När det är möjligt väljer du en jämn numrerad OpenShift-version för mas-distributioner för produktion, eftersom dessa versioner är versioner av Utökad uppdateringssupport (EUS).

  Kontrollera att IBM stöder den valda OpenShift-versionen för alla valda MAS-program och beroenden. Om en MAS-komponent visar en nyare openshift-version med udda nummer som ett krav i IBM SPCR verifierar du den fullständiga komponentuppsättningen mot IBM SPCR, Red Hat-livscykelstöd och tillgänglighet för ARO-version innan du väljer klusterversionen.

• Distributionssökväg. Använd ett befintligt ARO-kluster när du har befintliga Azure landningszon, nätverk, identitet, lagring och driftkontroller. Använd IBM-Azure Marketplace installationssökväg när du vill att IBM-tillhandahållen automatisering ska skapa eller återanvända OpenShift-infrastruktur som stöds. Använd endast självhanterade Red Hat OpenShift på Azure när ARO inte uppfyller dina krav.

• Val av region. Använd en region som har tillgänglighetszoner om möjligt. Konfigurera ARO-arbetsnoder mellan zoner när målregionen stöder det mönstret. För självhanterade OpenShift konfigurerar du installationsfilen install-config.yaml, så OpenShift placerar noder mellan zoner. Om det uppstår ett avbrott i en zon kan din lösning fortsätta att fungera genom att låta noder i andra zoner ta över arbetet.

• Säkerhetskopiering och återställning. Du kan använda instruktionerna för Azure Red Hat OpenShift säkerhetskopiering och återställning. Mer information finns i Skapa en Azure Red Hat OpenShift 4-klusterprogramsäkerhetskopiering. Om du använder den här metoden för säkerhetskopiering och återställning måste du ange en annan metod för haveriberedskap för databasen.

• Failover. Överväg att distribuera OpenShift i två regioner och använda Red Hat Advanced Cluster Management. Om lösningen har offentliga slutpunkter kan du placera Azure Traffic Manager mellan slutpunkterna och Internet för att omdirigera trafik till lämpligt kluster i ett regionalt avbrott. I så fall måste du också migrera programtillstånd och beständiga volymer.

Självhanterad OpenShift

Använd självhanterad Red Hat OpenShift på Azure om ARO inte uppfyller dina krav på kontroll, isolering eller frånkopplad distribution. För självhanterade distributioner väljer du mellan följande installationsmetoder:

• Installer Provisioned Infrastructure (IPI - Infrastruktur som ställs till förfogande av installatören). Den här metoden använder ett installationsprogram för att distribuera och konfigurera OpenShift-miljön på Azure. Använd IPI när det uppfyller dina krav på säkerhet och nätverk.

• Användartillhandahållen infrastruktur (UPI). Med den här metoden kan du få detaljerad kontroll över distributionen. UPI kräver fler steg och överväganden för att skapa din miljö. Använd UPI om IPI eller ARO inte uppfyller dina behov. En privat eller frånkopplad installation är ett vanligt användningsfall för UPI.

Luftgapad installation

Vissa fall, till exempel regelefterlevnad, kan kräva en luftgapad installation av MAS på Azure. Air-gapped innebär att det inte finns någon inkommande eller utgående internetåtkomst. Utan en internetanslutning kan installationen inte hämta beroendena för MAS- eller OpenShift-installationen vid körning.

Använd endast en luftgapad installation om det är ett säkerhetskrav. Ett luftgap ger betydande komplexitet i lösningsåtgärderna. Aktiviteter som att installera programvara, spegla containrar, uppdatera speglar för att skydda mot säkerhetsrisker eller hantera brandväggar kan förbruka betydande driftsinsatser.

Mer information om luftgapade installationer finns i följande Red Hat OpenShift-dokumentation för frånkopplade installationer och privata kluster på Azure:

• Speglingsbilder för en frånkopplad installation med oc-mirror
• Installera ett privat kluster på Azure

Efter en luftgapad OpenShift-installation kan du fortsätta med MAS-dokumentationen för vägledning om frånkopplade miljöer.

Storleksändring för nod och miljö

För alla arbetsbelastningar utom Maximo Visual Inspection börjar du med den aktuella generationenS - eller Das-seriens VM-familjer, till exempel Dsv6, som är tillgängliga som arbetsnoder i din valda region. Välj VM-storlekar som har stöd för premiumlagring och som uppfyller kraven för processor, minne och lagring för de MAS-program som du distribuerar.

Maximo Visual Inspection kräver GPU-noder för att utföra sin maskininlärning. Lösningen använder CUDA och stöder endast NVIDIA GPU:er. För ARO väljer du en NVIDIA GPU VM-storlek från den aktuella supportlistan för ARO-arbetsnoder och bekräftar sedan att IBM stöder den för dina MAS- och OpenShift-versioner. För självhanterad OpenShift väljer du en NVIDIA GPU VM-storlek som stöds av IBM och Red Hat.

För GPU-arbetsnoder börjar du med den minsta noden och skalas upp när dina krav ökar.

För ARO och självhanterade OpenShift använder du samma riktlinjer för MAS-arbetsbelastningsstorlek för arbetsnoder. Konfigurera arbetsnoder mellan tillgänglighetszoner för att stödja hög tillgänglighet. För självhanterade OpenShift konfigurerar du även kontrollplanet mellan tillgänglighetszoner. Använd följande startpunkt:

• Kontrollera noder. För ARO hanteras kontrollplanet som en del av tjänsten. För självhanterade OpenShift använder du minst en virtuell dator per tillgänglighetszon i den valda regionen.

• Arbetsnoder. Använd minst två datorer per tillgänglighetszon i den valda regionen. Ändra storlek på arbetsnoder baserat på IBM-vägledning, valda MAS-program och förväntad belastning.

MAS-kärnan kräver 13 vCPU:er för en basinstallation i standardstorlek. Storleksändringen för arbetsnoderna varierar beroende på vilka MAS-program som konfigurationen distribuerar och belastningen på din miljö. Till exempel kräver Maximo Manage för 10 användare ytterligare 2 vCPU:er. Behandla dessa värden som startpunkter och validera storleksändringen mot de aktuella systemkraven för IBM Maximo Application Suite för din MAS 9.x-version, valda program och förväntad användning.

För självhanterade OpenShift kan du försöka behålla vm-typer som liknar varandra för att ge närhet till var och en av tillgänglighetszonerna mellan arbets- och kontrollnoder. För ARO justerar du arbetsnodpooler efter samma MAS-arbetsbelastningskrav och Azure regional kapacitet.

Om du behöver en jump box för att använda openshift-kommandoradsgränssnittet oc eller för att installera MAS distribuerar du en virtuell Linux-dator som stöds och som uppfyller organisationens administrativa krav och säkerhetskrav.

Konfiguration av nätverk

För ARO använder du standardkonfigurationen för OpenShift-nätverk som ARO distribuerar om inte IBM, Red Hat och ditt nätverksteam verifierar ett annat alternativ. Planera det virtuella nätverket och separata undernät för ARO-kontrollplansnoder, arbetsnoder, Azure tjänstberoenden, privata slutpunkter, databaser och hybridanslutningar. Ange nodundernäten för antalet OpenShift-arbetsnoder som du behöver, inklusive uppgraderingskapacitet och framtida utskalning.

För självhanterade OpenShift inkluderar även krav på bootstrap och installationsprogramskapad infrastruktur. Håll administrativ åtkomst till OpenShift-API:et och noderna begränsade till godkända nätverkssökvägar, till exempel hybridanslutningar, skyddade jump-värdar eller andra kontroller som din organisation behöver. Om du begränsar klustrets utgående trafik planerar du nödvändiga utgående beroenden för OpenShift, MAS-installation, containeravbildningshämtningar, uppdateringar, övervakning och externa tjänster.

För en standardinstallation av MAS-produktion på ARO ska du inte börja med ett tätt packat virtuellt nätverk. Reservera ett större adressutrymme, till exempel prefixet Klasslös Inter-Domain Routning (CIDR) på /16 när landningszonen tillåter det, och allokera dedikerade undernät. Använd minst en /24-planeringsstorlek för ARO-kontrollplanets undernät och minst en /24-planeringsstorlek för arbetsnodens undernät. Lägg till ett /27 eller större undernät för privata slutpunkter och externa databastjänster. Om du vill distribuera Azure Bastion lägger du till ett undernät med namnet AzureBastionSubnet med prefixet /26. Mer information om Azure Bastion krav finns i Arkitektur.

Om du använder självhanterade OpenShift och saknar IP-adresser kan du utforma en begränsad konfiguration med hög tillgänglighet med ett minsta prefix på /27 för undernätet för kontrollnoden och /27 för arbetsnodundernätet. Använd inte den här begränsade storleken som startpunkt för en ARO-produktionsdistribution. Understorleken för det virtuella nätverket eller nodundernäten ska inte underordnas. Att åtgärda en OpenShift-distribution efter installationen är störande och kan kräva omdistribution.

Om du vill använda ett annat CNI (Container Network Interface) ska du ändra storleken på dina nätverk i enlighet med detta. MAS med vissa standardprogram distribuerar över 800 poddar, vilket förmodligen kräver ett CIDR-prefix på /21 eller större.

Databasspecifikationer

Vissa MAS-komponenter använder MongoDB som ett metadatalager. Standardvägledningen är att distribuera MongoDB Community Edition i klustret. Om du använder den metoden kontrollerar du att du har en lämplig procedur för att säkerhetskopiera och återställa databasen. Överväg att använda MongoDB Atlas på Azure för att tillhandahålla ett externt lager, säkerhetskopior och skalning. Azure stöder för närvarande inte användning av MongoDB-API:er med Azure Cosmos DB.

Om du distribuerar IoT-tjänster måste du även ange en Kafka-slutpunkt. Standardvägledningen är att använda Strimzi för att distribuera Kafka i OpenShift-klustret, men data i Strimzi går sannolikt förlorade under haveriberedskap. Om dataförlust i Kafka är oacceptabelt bör du överväga att använda Confluent Kafka på Azure. För närvarande stöds inte Azure Event Hubs med Kafka-slutpunkter.

MAS innehåller flera databaser i sina poddar, och dessa databaser behåller sina tillstånd i filsystemet som tillhandahålls för MAS. Om du vill absorbera zonfel använder du en zonredundant lagringsmekanism (ZRS) för att behålla tillstånden utanför dina kluster. Det rekommenderade mönstret är att använda Azure File Storage med följande konfigurationer:

• Standard tillhandahåller SMB-resurser för arbetsbelastningar med lägre dataflöde och ReadWriteOnce (RWO). Använd Standard för delar av programmet som inte skriver till lagring ofta och kräver en enda beständig volym, till exempel IBM-lagring på en nivå.

• Premium tillhandahåller NFS-resurser för arbetsbelastningar med högre dataflöde och ReadWriteMany (RWX). Volymer som dessa används i hela klustret för RWX-arbetsbelastningar, till exempel Db2 Warehouse i Cloud Pak för data eller Postgres i Maximo Manage.

Azure Files NFS stöder kryptering under överföring. Om MAS OpenShift-klienten inte kan använda NFS-kryptering kan du undanta kontot från principer för säker överföringsframtvingande. Mer information finns i NFS Azure filresurser: Kryptering. Använd en privat slutpunkt för att tillhandahålla privat anslutning till dina resurser.

Om du distribuerar Db2 Warehouse via Cloud Pak for Data använder du OpenShift Data Foundation. Ett OpenShift Data Foundation-exempel som använder Ceph File System (CephFS) och RADOS Block Device (Ceph RBD) lagringsklasser för olika Db2 Warehouse-datatyper finns i Skapa Db2-instansen med hjälp av Cloud Pak för datakonsolen.

Använd inte Azure Blob Storage med CSI-drivrutiner (Container Storage Interface), eftersom det inte stöder hårda länkar, som vissa poddar kräver för att köras.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som du kan använda för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Tillförlitlighet

OpenShift har inbyggda funktioner för självåterställning, skalning och motståndskraft. OpenShift och MAS förväntar sig att komponenterna kommer att misslyckas och återställas. Ett viktigt krav för självåterställning är att klustret har tillräckligt med arbetsnoder. Om du vill återställa från ett zonfel i en Azure region måste dina kontroll- och arbetsnoder balanseras mellan tillgänglighetszoner.

MAS och OpenShift använder lagring för att bevara tillstånd utanför Kubernetes-klustret. Använd zonredundant lagring när det är möjligt för att säkerställa att lagringsberoendena fortsätter att fungera under ett fel. Zonredundant lagring är fortfarande tillgängligt när en enskild zon misslyckas.

För att förhindra mänskliga fel distribuerar du MAS med så mycket automatisering som möjligt. Använd den aktuella IBM-installationsdokumentationen och den automatisering som stöds för den valda MAS-versionen, OpenShift-plattformen och distributionssökvägen.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Checklista för designgranskning för säkerhet.

Att upprätthålla åtkomst och insyn i underhållslivscykeln för dina tillgångar kan vara en av organisationens största möjligheter att arbeta effektivt och upprätthålla drifttid. För att förbättra din miljös säkerhetsstatus är det viktigt att använda säker autentisering och hålla dina lösningar uppdaterade. Använd kryptering för att skydda alla data som flyttas in och ut ur din arkitektur.

Genom att använda ARO-distributioner kan du dra nytta av ARO-modellen för delat ansvar. Azure Red Hat OpenShift är gemensamt utformad, drivs och stöds av Microsoft och Red Hat, som uppdaterar, uppdaterar och övervakar den hanterade OpenShift-plattformen åt dig. Du ansvarar fortfarande för distributioner ovanpå ARO. Det här ansvaret omfattar MAS och dess programkonfiguration, identitetsintegrering, nätverkskontroller, planering av arbetskapacitet, lagringsalternativ, säkerhetskopiering och haveriberedskap, hemligheter, dataskydd och efterlevnadskrav. Mer information finns i Introduktion till Azure Red Hat OpenShift och Azure Red Hat OpenShift 4.0-supportprincip.

Microsoft bygger in säkerhetsskydd i Azure-plattformen på följande nivåer:

• Fysiska datacentra
• Fysiskt nätverk
• Fysisk värd
• Hypervisor

Använd en OpenShift-version som din OpenShift-plattform stöder och som IBM stöder för din MAS-version och dina program. Använd när det är möjligt en långsiktig supportversion som stöds. Om du använder självhanterade OpenShift ansvarar du för att korrigera och underhålla OpenShift-plattformen och de underliggande virtuella datorerna. Om du använder ARO hanterar Microsoft korrigering och hantering.

Använd nätverkssäkerhetsgrupper för att filtrera nätverkstrafik till och från resurser i ditt virtuella nätverk. Genom att använda dessa grupper kan du definiera regler som beviljar eller nekar åtkomst till dina MAS-tjänster, till exempel:

• Tillåta SSH-åtkomst till OpenShift-noderna för felsökning.
• Blockerar åtkomst till alla andra delar av klustret.
• Kontrollera vilka platser som kan komma åt MAS och OpenShift-klustret.

För att få åtkomst till dina virtuella datorer kan du ansluta via hybridanslutningar eller via OpenShift-administratörskonsolen. Om du har en onlinedistribution eller inte vill förlita dig på hybridanslutning kan du komma åt dina virtuella datorer via Azure Bastion. Av säkerhetsskäl ska du inte exponera virtuella datorer för ett nätverk eller internet utan att konfigurera nätverkssäkerhetsgrupper för att kontrollera åtkomsten.

Kryptering på serversidan (SSE) av Azure-disklagring skyddar dina data och hjälper dig att uppfylla organisationens säkerhets- och efterlevnadsåtaganden. Med Azure hanterade diskar krypterar SSE vilande data när de bevaras i molnet. Det här beteendet gäller som standard både os- och datadiskar. OpenShift använder SSE som standard.

Autentisering

MAS stöder enkel inloggning med SAML (Security Assertion Markup Language). Om du vill använda Microsoft Entra ID som SAML-identitetsprovider skapar du ett företagsprogram i Microsoft Entra ID och konfigurerar MAS som tjänstleverantör. Mer information finns i Microsoft Entra SSO-integrering med Maximo Application Suite.

Innan du konfigurerar SAML-baserad autentisering bör du granska både IBM-konfigurationen och konfigurationen för Azure. Information om SAML med MAS finns i Konfigurera SAML-autentisering. Information om SAML med Azure finns i Quickstart: Aktivera enkel inloggning för ett företagsprogram.

Du bör också konfigurera OAuth för administrativ åtkomst i OpenShift. Information om ARO finns i Konfigurera Microsoft Entra autentisering för ett Azure Red Hat OpenShift kluster. Självhanterad OpenShift finns i Konfigurera identitetsprovidrar i OpenShift Container Platform 4.21.

Resursåtkomst och granskning

Kontrollera åtkomsten till de Azure resurser som du distribuerar. Varje Azure-prenumeration har en trust-relation med en Microsoft Entra klientorganisation. Använd rollbaserad Azure-åtkomstkontroll (Azure RBAC) för att ge användarna i organisationen rätt behörighet till Azure-resurser. Bevilja åtkomst genom att tilldela Azure roller till användare eller grupper i ett visst omfång, till exempel en prenumeration, resursgrupp eller en enskild resurs. Granska alla ändringar i infrastrukturen. Mer information om granskning finns i Azure Monitor aktivitetslogg.

Kostnadsoptimering

Kostnadsoptimering fokuserar på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Checklista för designgranskning för kostnadsoptimering.

En standarddistribution av MAS på Azure innehåller följande primära kostnadsdrivrutiner:

• Kostnader för ARO-kluster, inklusive arbetsnoder och eventuella fakturerbara kontrollplans- eller klusteravgifter
• Arbetsnodpooler som är stora för MAS Core och de MAS-program som du distribuerar
• Valfria GPU-arbetsnoder för Maximo Visual Inspection
• Databastjänster, till exempel SQL Managed Instance, Db2 Warehouse eller en annan IBM-databas som stöds
• Lagringskonton eller hanterade lagringstjänster för beständiga volymer, säkerhetskopior och installationsartefakter
• DNS-zoner, belastningsutjämning, privata slutpunkter och en valfri instans av Azure Bastion

För både ARO och självhanterade OpenShift använder en standarddistribution av MAS vanligtvis samma storleksbaslinje för arbetsnoder. Använd följande inventering som utgångspunkt för kostnadsuppskattning:

• Sex virtuella arbetsdatorer.
• Tre virtuella arbetsdatorer för Db2 Warehouse. Du kan ersätta SQL Managed Instance i vissa konfigurationer i stället för att använda Db2 Warehouse.
• Två Azure Storage konton.
• Två DNS-zoner.
• Två lastbalanserare.
• Azure Bastion.
• En Maximo Visual Inspection GPU-arbetsnod om du planerar att köra Maximo Visual Inspection i MAS.

Kostnaden för kontrollplan skiljer sig åt beroende på distributionsmodell. För självhanterade OpenShift-distributioner som använder IPI eller UPI innehåller även tre virtuella kontrolldatorer. För ARO tar du hänsyn till det hanterade kontrollplanet och eventuella ARO-specifika klusteravgifter i stället för att lägga till kundhanterade virtuella kontrolldatorer.

Du kan granska en exempeluppskattning med hjälp av kostnadskalkylatorn. Konfigurationerna varierar, så kontrollera konfigurationen med IBM-storleksteamet innan du slutför distributionen.

Distribuera det här scenariot

Innan du börjar bör du granska IBM Maximo Application Suite-systemkraven och IBM SPCR för din MAS-version och dina program. Ha följande resurser tillgängliga innan du startar distributionen:

• Åtkomst till en Azure-prenumeration med läsbehörighet
• Ett programregistrerings- eller tjänsthuvudnamn som har behörighet som deltagare och administratör för användaråtkomst till prenumerationen
• En domän eller delegerad underdomän till en Azure DNS zon
• Ett ARO-kluster som stöds eller behörigheter och förutsättningar för att skapa ett
• En pull-hemlighet från Red Hat om din distributionssökväg skapar eller hanterar OpenShift-infrastrukturen
• En MAS-berättigandenyckel
• En MAS-licensfil som du skapar efter MAS-installationen
• IBM-rekommenderad klusterstorlek
• Ett befintligt virtuellt nätverk eller ett nytt virtuellt nätverk som uppfyller ARO- och MAS-kraven
• Krav på hög tillgänglighet och haveriberedskap för din specifika distribution
• Konfigurationsinformation för den valda distributionssökvägen, till exempel ARO-klusterinformation eller självhanterade Installationsparametrar för OpenShift

Innan du skapar din miljö kan du läsa IBM Planning to install on Microsoft Azure documentation (IBM Planning to install on Microsoft Azure documentation to understand the design parameters). Aktuell Azure installationsvägledning finns i Maximo Application Suite på Microsoft Azure översikt. Verifiera distributionsprocessen mot aktuell IBM-dokumentation och supportmatrisen för din MAS-version.

Att tänka på vid distribuering

Distribuera arbetsbelastningar med hjälp av infrastruktur som kod (IaC) i stället för manuellt. Manuell distribution kan leda till felkonfiguration. Containerbaserade arbetsbelastningar kan vara känsliga för felkonfiguration, vilket kan minska produktiviteten.

IBM erbjuder specialiserade tjänster som hjälper dig med installation. Kontakta IBM-teamet om du vill ha support.

Deltagare

Microsoft ansvarar för den här artikeln. Följande bidragsgivare skrev den här artikeln.

Huvudsakliga författare:

• David Baumgarten | Chefsarkitekt
• Roeland Nieuwenhuis | Chefsarkitekt

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Nästa steg

För att få hjälp med att komma igång, se följande resurser:

• Azure Red Hat OpenShift
• Översikt över Maximo Application Suite på Microsoft Azure
• Planerar att installeras på Microsoft Azure
• Installera OpenShift på Azure
• OpenShift UPI Guide
• Krav för Maximo
• IBM Software Product Compatibility Reports
• IBM Maximo Application Suite (BYOL)

Mer information om aktuella tekniker finns i följande resurser:

• IBM Passport-fördel
• Introduction till Azure DNS
• Introduction till Azure NetApp Files
• Introduktion till Azure Red Hat OpenShift
• Red Hat-kundportalen

Relaterade resurser

• Azure företagsmolnfildelning
• Distribuera ett Java-program med JBoss Enterprise Application Platform (EAP) i ett ARO-kluster