Distribuera IBM Maximo Application Suite på Azure

IBM Maximo Application Suite (MAS) 8.x körs på OpenShift och det är bra att bekanta dig med OpenShift och de föreslagna mönstren för installation i Azure. Mer information finns i Förbereda installation på Azure. Den här arkitekturen illustrerar ett OpenShift-kluster. Det går inte in i detalj på hur du installerar MAS. Mer information om installationsprocessen finns i Installera Maximo Application Suite från OperatorHub.

Arkitektur

Ladda ned en Visio-fil med den här arkitekturen.

Arbetsbelastningen kan distribueras internt eller externt, beroende på dina krav.

Arbetsflöde

När det gäller infrastruktur tillhandahåller den här arkitekturen följande:

• En containervärdplattform för att distribuera arbetsbelastningar med hög tillgänglighet mellan tillgänglighetszoner
• En privatiserad distribution av arbets- och kontrollnoder som är integrerade med lagring
• Azure Files Premium- och standardfiler för lagring (OpenShift Data Foundation krävs inte)
• SQL Server på virtuella Azure-datorer eller containerbaserat IBM Db2 Warehouse
• Azure DNS för DNS-hantering av OpenShift och dess containrar
• Microsoft Entra ID för enkel inloggning (SSO) i MAS

Komponenter

• Azure Virtual Machines som värd för OpenShift-plattformen och kör Maximo-containrarna. Virtual Machines är ett IaaS-erbjudande (infrastructure-as-a-service). Du kan använda virtuella datorer för att distribuera skalbara beräkningsresurser på begäran.

• Red Hat Enterprise Linux CoreOS för att tillhandahålla en anpassad VM-avbildning för OpenShift.

• Azure Load Balancers för att tillhandahålla anslutning till klustret. Azure Load Balancer är en högpresterande layer 4-tjänst med mycket låg svarstid (inkommande och utgående) för alla UDP- och TCP-protokoll. Den är byggd för att hantera miljontals begäranden per sekund samtidigt som du ser till att din lösning är mycket tillgänglig. Azure Load Balancer är zonredundant, vilket säkerställer hög tillgänglighet i Tillgänglighetszoner.

• Virtuellt nätverk för kommunikation mellan noder, Azure-tjänster och hybridanslutningsbehov. Virtuellt nätverk är den grundläggande byggstenen för privata nätverk i Azure.

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

• Azure DNS för att hantera 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 (valfritt) och ett undernät för förbättrad säkerhetsåtkomst till någon av arbetsnoderna eller valfria JumpBox-datorer. Azure Bastion är en fullständigt hanterad tjänst som ger sömlös rdp-åtkomst med förbättrad säkerhet och SSH-åtkomst till virtuella datorer utan exponering via offentliga IP-adresser.

• SQL Server på Azure Virtual Machines (valfritt) för att tillhandahålla datatjänster till MAS. Databasen kan också vara en annan, till exempel Oracle Exadata eller IBM Db2 Warehouse. Azure SQL Database och Azure SQL Managed Instance stöds inte just nu.

• Twilio Send Grid (valfritt) för att skicka e-postmeddelanden från MAS till dina konsumenter.

• Virtuella Linux-datorer i Azure (valfritt) för att tillhandahålla en hoppruta för installation av OpenShift. Du kan också använda den här virtuella datorn för att ansluta och hantera OpenShift-klustret eftersom det innehåller Kubernetes-konfigurationsfilen efter installationen. Om du har nätverksanslutning till din Azure-miljö kan du utföra installationen från en befintlig dator.

Alternativ

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

• Azure NetApp Files som ersättning för Azure Files. Azure NetApp Files stöder alla typer av arbetsbelastningar med hög tillgänglighet och höga prestanda.
• Oracle Database på Azure om du föredrar det för SQL Server eller Db2 Warehouse.
• OpenShift Data Foundation om du vill använda Db2 Warehouse på OpenShift Data Foundation.

Information om scenario

IBM:s Maximo Application Suite (MAS), även kallat Maximo, är en plattform för företagshantering av tillgångar med AI-baserat tillgångsunderhåll. MAS fokuserar på driftåterhämtning och tillförlitlighet. Sviten består av en grundläggande programplattform, MAS och program och branschspecifika lösningar ovanpå plattformen. Varje program ger en specifik fördel:

• Hantera. Minska nedtid och kostnader genom att använda tillgångshantering för att förbättra driftprestandan.
• Övervaka. Använd IoT för avancerad AI-baserad övervakning av fjärrtillgångar i stor skala.
• Hälsotillstånd. Hantera tillgångshälsa med hjälp av IoT-data från sensorer, tillgångsdata och underhållshistorik.
• Visuell kontroll. Träna maskininlärningsmodeller för att använda visuell inspektion för visuell analys av nya problem.
• Förutsäga. Förutsäga framtida fel med hjälp av maskininlärning och dataanalys.
• Hjälp. Hjälp tekniker genom att ge AI-baserad vägledning till en kunskapsbas av underhållsdata för utrustning och genom att ge dem fjärråtkomst till experter.
• Säkerhet. Samla in och analysera data från sensorer, tillhandahålla kontextuella data och härled meningsfull analys.
• Civilt. Integrera 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.

Dessa program och MAS 8.x testas för användning i Azure. Microsoft och IBM Maximo-teamet samarbetade för att säkerställa att den här lösningen är konfigurerad att köras optimalt i Azure. Den här artikeln innehåller en design för att köra MAS 8.x på Azure för kunder som har support från IBM och en partner för installation. Kontakta IBM-teamet för produktspecifika frågor. Azure Marketplace erbjuder en alternativ installation 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)).

Potentiella användningsfall

Många branscher och sektorer använder lösningarna i MAS, till exempel:

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

Mer information om användningsfall för MAS finns på IBM:s webbplats på IBM Maximo Application Suite.

Rekommendationer

Vi rekommenderar att du installerar den senaste stabila versionen av MAS eftersom den ger de bästa integreringsalternativen med Azure. Var uppmärksam på vilka versioner av OpenShift som stöds eftersom de versioner som stöds varierar med den specifika versionen av MAS.

Användning av tidigare eller senare större versioner av OpenShift kan leda till att det inte finns något officiellt stöd för MAS. Innan du skapar en egen distribution rekommenderar vi att du använder snabbstartsguiden för att distribuera MAS så att du förstår hur distributionen och konfigurationen fungerar. Att veta hur detta görs påskyndar skapandet av designkraven för din implementering. Mer information finns i Snabbstartsguide: Maximo Application Suite på Azure.

Vi har ett nära samarbete med IBM och andra partner för att säkerställa att vägledningen, arkitekturen och snabbstartsguiden ger dig den bästa upplevelsen i Azure. De följer metodtipsen enligt beskrivningen i Microsoft Azure Well-Architected Framework. Kontakta IBM-kontoteamet för support utöver den här dokumentationen.

Innan du fortsätter med distributionen måste du svara på följande frågor om design:

• Vilka MAS-program behöver du?
• Vilka beroenden har dina program?
• Vilken version av OpenShift krävs?
• Vilken metod för installation av OpenShift ska du använda?
• Vilka databaser behövs?
• Vilket antal och storlekar på virtuella datorer behöver du?
• Kommer användarna att ansluta från externa nätverk?

Maximo Application Suite

Microsoft har testat MAS-versionerna 8.5 och senare i Azure. Vår rekommendation är att använda den senaste versionen av MAS, som är version 8.7.

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. Vart och ett av programmen kan behöva separata databaser. Vi har testat och stöder följande databaser i Azure:

• SQL Server på Azure Virtual Machines version 2019 med Windows eller Linux
• IBM Db2 Warehouse på Cloud Pak för Data 3.5

Du kan också välja att köra Oracle Exadata på en virtuell dator eller på Oracle Cloud Infrastructure med hjälp av sammankoppling, men det här är inte en testad konfiguration. Mer information om sammankoppling finns i Ansluta Oracle Cloud till Microsoft Azure. För närvarande stöds inte Azure SQL Database, Azure SQL Managed Instance och Azure Cosmos DB.

MAS och vissa av dess program har beroenden för MongoDB och Kafka. Bestäm hur du distribuerar de här lösningarna baserat på prestanda- och driftöverväganden. Standardvärdena är att distribuera MongoDB Community Edition och Strimzi Kafka i klustren. Några av kraven för MAS, till exempel BAS, använder databaser som inte kan externaliseras men som kräver att beständiga lagring tillhandahålls till OpenShift-klustret.

För tillståndsbaserade tjänster som körs i OpenShift-klustret är det nödvändigt att ofta säkerhetskopiera data och flytta säkerhetskopiorna till en annan region. Utforma och planera en återställningsstrategi i händelse av haveri och bestäm därefter, 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 (extern Azure Platform as a Service) när det är möjligt. Detta förbättrar supporten under ett avbrott.

Vissa av tjänsterna kan kräva andra IBM-verktyg och -tjänster, till exempel IBM Watson Machine Learning och IBM App Connect. Du kan distribuera alla verktyg och tjänster i samma OpenShift-kluster.

OpenShift

Innan du installerar OpenShift måste du bestämma vilken metod du ska använda:

• Installer Provisioned Infrastructure (IPI). Den här metoden använder ett installationsprogram för att distribuera och konfigurera OpenShift-miljön i Azure. IPI är den vanligaste metoden för distribution i Azure och du bör använda IPI om inte dina säkerhetskrav är för strikta för att göra det.

• User Provisioned Infrastructure (UPI). Med den här metoden får du detaljerad kontroll över distributionen. UPI kräver fler steg och överväganden för att skapa din miljö. Använd UPI om IPI inte uppfyller dina behov. Ett vanligt användningsfall för UPI är för privat, luftgapad installation. Välj UPI när du inte har någon utgående internetåtkomst när du skapar miljön.

Vi rekommenderar att du använder IPI när det är möjligt, eftersom det avsevärt minskar mängden arbete som krävs för att slutföra installationen av OpenShift.

När du installerar OpenShift måste du lösa följande överväganden:

• Val av region. Vi rekommenderar att du använder en region med tillgänglighetszoner. Under distributionen försöker OpenShift automatiskt skapa noder mellan zoner baserat på konfigurationen i konfigurationsfilen install-config.yaml. Som standard balanserar OpenShift arbetsbelastningar över alla tillgängliga noder och mellan tillgänglighetszonerna. Om det uppstår ett avbrott i en zon kan din lösning fortsätta att fungera genom att ha noder i andra zoner som kan ta över arbetet.

• Säkerhetskopiering och återställning. Du kan använda anvisningarna för Azure Red Hat OpenShift för säkerhetskopiering och återställning. Mer information finns i Skapa en Azure Red Hat OpenShift 4-klusterprogramsäkerhetskopia. 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.

• Redundans. Ö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 dem och Internet för att omdirigera trafik till lämpligt kluster när det uppstår ett avbrott i en region. I sådana fall måste du också migrera programtillstånd och beständiga volymer.

Luftgapade installationer

I vissa fall, till exempel för regelefterlevnad, kan du 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 installationsberoendena vid körning för installationen av MAS eller OpenShift.

Vi rekommenderar inte att du gör en luftgapad installation om det inte är ett säkerhetskrav. Ett luftgap ger betydande komplexitet i driften av din lösning. Aktiviteter som att installera programvara, spegla containrar, uppdatera en spegling för att skydda mot säkerhetsrisker och hantera en brandvägg kan bli mycket tidskrävande.

Mer information om luftgapade installationer finns i följande OpenShift-dokumentation:

• Speglingsbilder för en frånkopplad installation
• Installera ett privat kluster i Azure

När du har installerat OpenShift läser du MAS-dokumentationen för liknande vägledning.

Ändra storlek på din miljö

För alla arbetsbelastningar (utom visuell kontroll) rekommenderar vi att du använder de senaste virtuella datorerna i Ds-serien som arbetsnoder. Exempel är Dsv3, Dasv4, Dsv4, Dasv5 eller Dsv5. Vi rekommenderar att du använder de senaste versionerna när det är möjligt eftersom de ger bättre prestanda. Använd endast virtuella datorer som har premiumlagring.

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. De rekommenderade typerna av virtuella datorer är NCv3 och NCasT4_v3. Om du behöver träna med YOLOv3 behöver du Ampere-baserade GPU:er. Använd NVadsA10 v5 eller NC A100 v4 för större träningsuppgifter.

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

För alla andra datorer rekommenderar vi att du konfigurerar virtuella datorer i olika tillgänglighetszoner för att stödja hög tillgänglighet. Konfigurera noderna på följande sätt:

• Kontrollera noder. Minst en virtuell dator per tillgänglighetszon i den valda regionen. Vi rekommenderade ett vCPU-antal på minst 4. Vår referens använder 3x Standard_D8s_v4 noder.

• Arbetsnoder. Minst två datorer per tillgänglighetszon i den valda regionen. Vi rekommenderar ett vCPU-antal på minst 8. Vår referens använder 6x Standard_D8s_v4 noder.

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ö. Hantera för 10 användare kräver till exempel ytterligare 2 vCPU:er. Vi rekommenderar att du granskar systemkraven för IBM Maximo Application Suite för att få en bra storleksuppskattning.

Försök att behålla de typer av virtuella datorer som liknar varandra för att ge närhet till var och en av tillgänglighetszonerna mellan arbets- och kontrollnoder. Om du använder en virtuell v4-dator för dina kontrollnoder använder du alltså även en virtuell v4-dator för dina arbetsnoder.

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 dator som kör Red Hat Enterprise Linux version 8.4.

Nätverk

Med OpenShift använder vi CNI-standardprovidern (Container Network Interface) för OpenShifts programvarudefinierade nätverk (SDN). Mer information om standard-CNI för OpenShift finns i Klusternätverksoperator i OpenShift Container Platform. Du måste ange storleken på nätverket för det antal OpenShift-kontroll- och arbetsnoder som du behöver, och även för andra krav, till exempel databaser och lagringskonton.

För en standardinstallation av MAS-produktion rekommenderar vi ett virtuellt nätverk med adressutrymmet som ett CIDR-prefix (classless inter-domain routing) för /24 tillhandahåller. Det virtuella nätverket har tre eller fyra undernät (för Azure Bastion). För OpenShift har undernätet för arbetsnoderna ett CIDR-prefix på /25 och kontrollnoderna har prefixet /27. Ett undernät för slutpunkter och en valfri extern databasserver bör ha prefixet /27. Om du distribuerar Azure Bastion, vilket är valfritt, behöver du ett undernät med namnet AzureBastionSubnet med prefixet /26. Mer information om kraven för Azure Bastion finns i Arkitektur.

Om du har ont om IP-adresser kan du implementera en konfiguration med hög tillgänglighet med ett minsta prefix på /27 för undernätet för kontrollnoder och /27 för undernätet för arbetsnoder.

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

Databasinformation

Olika komponenter i MAS använder MongoDB som ett metadatalager. Standardvägledningen är att distribuera MongoDB Community Edition i klustret. Om du distribuerar den med 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 i Azure eftersom det tillhandahåller ett externt lager, säkerhetskopior, skalning med mera. 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. Under en haveriberedskap går data i Strimzi troligen förlorade. Om dataförlust i Kafka är oacceptabelt bör du överväga att använda Confluent Kafka i Azure. För närvarande stöds inte Azure Event Hubs med Kafka-slutpunkter.

MAS levereras fullspäckad med många databaser i sina poddar, och dessa databaser behåller sina tillstånd i filsystemet som tillhandahålls för MAS. Vi rekommenderar att du använder en zonredundant lagringsmekanism (ZRS) för att behålla tillstånden utanför dina kluster för att kunna absorbera zonfel. Vårt rekommenderade mönster är att använda Azure File Storage med följande konfigurationer:

• Standard. Tillhandahåller SMB-resurser (Server Message Block) för arbetsbelastningar med lägre dataflöde och ReadWriteOnce (RWO). Standard passar bra 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 (Network File System) 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 Hantera.

Se till att inaktivera principer för att framtvinga säker överföring på Azure Blob Storage eller undanta kontona från sådana principer. Azure Premium Files med NFS kräver att säker överföring inaktiveras. Se till att använda en privat slutpunkt för att garantera privat anslutning till dina resurser.

Som standard distribuerar Db2 Warehouse ovanpå OpenShift Data Foundation (tidigare kallat OpenShift Container Storage). Av kostnads-, prestanda-, skalnings- och tillförlitlighetsskäl rekommenderar vi att du använder Azure Premium Files med NFS i stället för OpenShift Data Foundation.

Använd inte Azure Blob Storage med CSI-drivrutiner eftersom det inte stöder hårda länkar, vilket krävs. Vissa poddar kan inte köras utan hårda länkar.

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.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.

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.

Azure levererar MAS med hjälp av modellerna infrastruktur som en tjänst (IaaS) och PaaS. Microsoft bygger in säkerhetsskydd i tjänsten på följande nivåer:

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

Utvärdera noggrant de tjänster och tekniker som du väljer för de områden ovanför hypervisor-programmet, till exempel den senaste korrigerade versionen av OpenShift för en större version. Se till att tillhandahålla rätt säkerhetskontroller för din arkitektur. Du ansvarar för att korrigera och upprätthålla säkerheten för IaaS-systemen. Microsoft tar den rollen för PaaS-tjänsterna.

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

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

Om du av någon anledning behöver åtkomst till dina virtuella datorer kan du ansluta via din hybridanslutning eller via OpenShift-administratörskonsolen. Om du har en onlinedistribution eller inte vill förlita dig på anslutning kan du också komma åt dina virtuella datorer via Azure Bastion (vilket är valfritt). Av säkerhetsskäl bör du inte exponera virtuella datorer för ett nätverk eller internet utan att konfigurera nätverkssäkerhetsgrupper för att styra åtkomsten till dem.

Kryptering på serversidan (SSE) för Azure Disk Storage skyddar dina data. Det hjälper dig också att uppfylla organisationens säkerhets- och efterlevnadsåtaganden. Med Azure-hanterade diskar krypterar SSE de vilande data när de sparas 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 för närvarande enkel inloggning (SSO) med Security Assertion Markup Language (SAML) i Microsoft Entra ID. Den här autentiseringsmetoden kräver ett företagsprogram inom Microsoft Entra-ID och behörigheter för att ändra programmet. Mer information finns i Microsoft Entra SSO-integrering med Maximo Application Suite.

Innan du konfigurerar SAML-baserad autentisering rekommenderar vi att du går igenom IBM-konfigurationen och Azure-konfigurationen. Information om SAML med MAS finns i SAML i dokumentationen för MAS. Information om SAML med Azure finns i Snabbstart: Aktivera enkel inloggning för ett företagsprogram.

Du bör också konfigurera Open Authorization (OAuth) för OpenShift. Mer information finns i Översikt över autentisering och auktorisering i OpenShift-dokumentationen.

Skydda infrastrukturen

Styr åtkomsten till Azure-resurser som du distribuerar. Varje Azure-prenumeration har en förtroenderelation med en Microsoft Entra-klientorganisation. Använd rollbaserad åtkomstkontroll i Azure (RBAC) för att ge användare i din organisation rätt behörigheter till Azure-resurser. Bevilja åtkomst genom att tilldela Azure-roller till användare eller grupper för ett visst omfång. Omfånget kan vara en prenumeration, en resursgrupp eller en enskild resurs. Se till att granska alla ändringar i infrastrukturen. Mer information om granskning finns i Azure Monitor-aktivitetsloggen.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.

En standarddistribution av MAS består av följande komponenter:

• 3 kontroll virtuella datorer
• 6 virtuella arbetsdatorer
• 3 virtuella arbetsdatorer för Db2 Warehouse
  • Du kan ersätta SQL Server på virtuella Azure-datorer i vissa konfigurationer i stället för att använda Db2 Warehouse.
• 2 Azure Storage-konton
• 2 DNS-zoner
• 2 lastbalanserare
• Azure Bastion
• 1 Virtuell dator för visuell inspektion
  • Detta krävs inte om du inte planerar att köra Visual Inspection i MAS.

Du kan granska en exempeluppskattning med hjälp av vår kostnadskalkylator. Konfigurationerna varierar och du bör verifiera konfigurationen med IBM-storleksteamet innan du slutför distributionen.

Tillförlitlighet

OpenShift har inbyggda funktioner för självåterställning, skalning och motståndskraft för att se till att OpenShift och MAS fungerar korrekt. OpenShift och MAS har utformats för delar som misslyckas och återställs. Ett viktigt krav för att självåterställning ska fungera är att det finns 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. För att säkerställa att lagringsberoendena fortsätter att fungera under ett fel bör du använda zonredundant lagring när det är möjligt. Den här typen av lagring är fortfarande tillgänglig när en zon misslyckas.

Eftersom mänskliga fel är vanliga bör du distribuera MAS med så mycket automatisering som möjligt. I vår snabbstartsguide tillhandahåller vi några exempelskript för att konfigurera fullständig automatisering från slutpunkt till slutpunkt.

Distribuera det här scenariot

Innan du börjar rekommenderar vi att du granskar systemkraven för IBM Maximo Application Suite. Se till att du har följande resurser tillgängliga innan du startar distributionen:

• Åtkomst till en Azure-prenumeration med läsbehörighet
• Programregistrering eller tjänstens huvudnamn som har behörighet som deltagare och administratör för användaråtkomst till prenumerationen
• Domän eller delegerad underdomän till en Azure DNS-zon
• Hämta hemlighet från Red Hat för att distribuera OpenShift
• MAS-berättigandenyckel
• MAS-licensfil (skapad efter MAS-installation)
• IBM-rekommenderad klusterstorlek
• Befintligt virtuellt nätverk eller ett nytt virtuellt nätverk som skapats av IPI, beroende på dina krav
• Krav på hög tillgänglighet och haveriberedskap för din specifika distribution
• Konfigurationsfil, install-config.yaml, för installationsprogrammet

En stegvis guide för att installera OpenShift och MAS i Azure, inklusive hur du uppfyller kraven, finns i vår snabbstartsguide på GitHub.

Att tänka på vid distribuering

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

Innan du skapar din miljö kan du läsa snabbstartsguiden för att utveckla en förståelse för designparametrarna. Snabbstartsguiden är inte avsedd för en produktionsklar distribution, men du kan använda guidens tillgångar för att komma till en mekanism i produktionsklass för distribution.

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

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

• David Baumgarten | Senior Cloud Solution Architect
• Roeland Nieuwenhuis | Huvudarkitekt för molnlösning

Annan deltagare:

• Gary Moore | Programmerare/skrivare

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

Mer information om hur du kommer igång finns i följande resurser:

• Installera OpenShift på Azure
• Snabbstartsguide: Maximo Application Suite i Azure
• OpenShift UPI Guide
• Krav för Maximo
• IBM Maximo Application Suite (BYOL)

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

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

Relaterade resurser

• Azure Enterprise-molnfilresurs
• Introduktion till förutsägande underhåll inom tillverkningsindustrin
• Distribuera ett Java-program med JBoss Enterprise Application Platform (EAP) i ett ARO-kluster