Bereitstellen von IBM Maximo Application Suite auf Azure

In diesem Artikel wird die BEREITSTELLUNG von IBM Maximo Application Suite (MAS) auf Azure beschrieben. MAS läuft auf Red Hat OpenShift. Azure Red Hat OpenShift (ARO) ist die bevorzugte OpenShift-Plattform, wenn sie Ihre Betrieblichen, Sicherheits- und Netzwerkanforderungen erfüllt. Verwenden Sie selbstverwaltete Red Hat OpenShift auf Azure nur, wenn Sie kontrolle benötigen, die ARO nicht bereitstellt, z. B. bestimmte getrennte Bereitstellungsmuster oder Anpassungen auf Clusterebene.

In diesem Artikel wird nicht ausführlich erläutert, wie MAS installiert wird. Weitere Informationen zur Installation finden Sie unter Installing Maximo Application Suite.

Aufbau

Das folgende Diagramm veranschaulicht eine ARO-basierte MAS-Bereitstellung auf Azure.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Sie können die Workload je nach Ihren Anforderungen als interne oder externe Bereitstellung bereitstellen. Dieser Artikel schreibt kein öffentliches oder privates ARO-Bereitstellungsmodell vor. Wählen Sie die Steuerungsebenen-, Eingangs- und Ausgangsarchitektur basierend auf Ihrer Azure Zielzonenarchitektur aus, einschließlich der Netzwerktopologie, des Konnektivitätsmodells, der Sicherheitskontrollen, der Betriebszugriffsanforderungen, der Complianceanforderungen und des MAS-Benutzerzugriffsmusters.

Wenn IBM externe Datenbanken für die von Ihnen bereitgestellten MAS-Anwendungen unterstützt, versuchen Sie, diese Datenbanken zu externalisieren, um den Zustand innerhalb des OpenShift-Clusters zu reduzieren und die Datenbankverwaltung vom Clustermanagement zu entkoppeln.

Arbeitsablauf

Aus Infrastruktursicht bietet diese Architektur die folgenden Funktionen:

• Ein Azure Red Hat OpenShift verwalteter Dienst zum Bereitstellen hochverfühbarer Workloads über Verfügbarkeitszonen hinweg
• Ein openShift-Cluster, der in Azure Netzwerk und Speicher integriert ist
• Azure Files Premium und Azure Files Standard für unterstützte MAS-Speicheranforderungen
• Azure SQL Managed Instance oder containerbasierte IBM Db2 Warehouse
• Azure DNS für die DNS-Verwaltung (Domain Name System) von OpenShift und deren Containern
• Microsoft Entra ID für einmaliges Anmelden (Single Sign-On, SSO) bei MAS

Komponenten

• Azure Red Hat OpenShift (ARO) ist die bevorzugte OpenShift-Plattform für MAS auf Azure. ARO reduziert ihre operative Verantwortung für die Ausführung von OpenShift im Vergleich zu einem selbstverwalteten Cluster auf Azure virtuellen Computern (VMs).

• Azure Virtual Machines ist eine Infrastruktur als Dienst (IaaS), die On-Demand-, skalierbare Computerressourcen bereitstellt. Verwenden Sie Virtual Machines anstelle von ARO, um selbstverwaltete Red Hat OpenShift auf Azure bereitzustellen.

  Optional können Sie Azure Linux-VMs als Sprungfelder für die MAS-Installation und die OpenShift-Verwaltung verwenden. Wenn Sie über eine private Netzwerkkonnektivität in Ihrer Azure Umgebung verfügen, können Sie die Verwaltung von einem vorhandenen gesicherten Computer ausführen.

• Red Hat Enterprise Linux CoreOS stellt das Betriebssystemimage für OpenShift-Knoten bereit.

• Azure Load Balancer stellt Verbindungen mit dem Cluster bereit. Load Balancer ist ein leistungsstarker, extrem niedriger Latenz-Layer-4-Lastenausgleichsdienst für alle eingehenden und ausgehenden Benutzerdatengrammprotokoll (UDP) und TCP-Protokolle (Transmission Control Protocol). Load Balancer können Millionen von Anforderungen pro Sekunde verarbeiten und gleichzeitig sicherstellen, dass Ihre Lösung hoch verfügbar ist. Load Balancer ist zonenredundant und stellt eine hohe Verfügbarkeit in allen Verfügbarkeitszonen sicher.

• Azure Virtual Network ist der grundlegende Baustein für private Netzwerke in Azure. Verwenden Sie Virtual Network für die Kommunikation zwischen Knoten und Azure-Diensten und für hybride Konnektivität.

• Azure Files bietet vollständig verwaltete Dateifreigaben in der Cloud, auf die über die Protokolle Server Message Block (SMB) und Network File System (NFS) zugegriffen werden kann. Verwenden Sie Azure Files, um die zustandsbehafteten Daten für die Datenbanken und Systeme innerhalb des Clusters zu hosten.

• Azure DNS verwaltet die DNS-Auflösung für die Container innerhalb und außerhalb der Lösung. Azure DNS unterstützt alle gängigen DNS-Einträge und stellt eine hohe Verfügbarkeit bereit.

• Azure Bastion ist ein vollständig verwalteter Dienst, der Remotedesktopprotokoll (RDP) und secure Shell (SSH)-Zugriff auf VMs ohne Gefährdung durch öffentliche IP-Adressen bereitstellt. Verwenden Sie optional Azure Bastion und ein Subnetz für den erweiterten Sicherheitszugriff auf einen der Arbeitsknoten oder optionalen Sprungfeldcomputer.

• SQL Managed Instance stellt mas externe Datendienste bereit, wenn IBM SQL Server für die von Ihnen bereitgestellten Anwendungen unterstützt. Sie können auch eine andere Datenbank auswählen, z. B. Oracle Exadata oder IBM Db2 Warehouse. Azure SQL-Datenbank wird nicht unterstützt.

• Twilio SendGrid sendet E-Mails von MAS an seine Verbraucher. Wenn Ihre MAS-Bereitstellung einen E-Mail-Dienst für Benachrichtigungs- und Mitarbeiterversandszenarien benötigt, integrieren Sie optional einen E-Mail-Dienst wie Twilio SendGrid in Ihr Design.

Alternativen

Die folgenden Dienste sind in der Regel nicht erforderlich, sind aber effektive Alternativen:

• Azure NetApp Files als Ersatz für Azure Files. Azure NetApp Files unterstützt Workloads, die hohe Verfügbarkeit und hohe Leistung benötigen.
• Oracle Database on Azure if supported and you prefer it.
• OpenShift Data Foundation, wenn Sie Db2 Warehouse auf OpenShift Data Foundation verwenden möchten.

Szenario-Details

Die IBM Maximo Application Suite ist eine Enterprise Asset Management-Plattform mit KI-basierter Asset-Wartung. MAS konzentriert sich auf operative Resilienz und Zuverlässigkeit. Die Suite besteht aus der MAS-Kernanwendungsplattform und den folgenden Anwendungen und branchenspezifischen Lösungen, die auf der Plattform basieren.

• Maximo Verwalten. Reduziert Ausfallzeiten und Kosten, indem die Ressourcenverwaltung verwendet wird, um die operative Leistung zu verbessern.
• Maximo Monitor. Verwendet internet of things (IoT) für die erweiterte KI-gestützte Überwachung von Remoteressourcen im großen Maßstab.
• Maximo Health. Verwaltet die Bestandsintegrität mithilfe von IoT-Daten aus Sensoren, Bestandsdaten und Wartungshistorie.
• Maximo Visuelle Inspektion. Trainiert Machine Learning-Modelle, um visuelle Inspektionen zur visuellen Analyse neuer Probleme zu verwenden.
• Maximo Predict. Prognostiziert zukünftige Fehler mithilfe von Maschinellem Lernen und Datenanalyse.
• Maximo Zusammenarbeit. Unterstützt Techniker mit KI-gestützter Anleitung von einer Wissensbasis für Gerätewartungsdaten und bietet Remotezugriff auf Experten.
• Maximo Gesundheit, Sicherheit und Umwelt (HSE) Verbindet Sicherheit, Umweltkonformität und Kontrolle von Arbeitsprozessen mit Ressourcen, Standorten und Arbeitsaufträgen.
• Maximo Civil Infrastructure. Integriert Inspektions-, Fehlernachverfolgungs- und Wartungsaktivitäten, um die Nutzungsdauer von Vermögenswerten zu verbessern, kritische Systeme zu betreiben und die Gesamtbetriebskosten der zivilen Infrastruktur zu senken.
• Maximo Immobilien und Einrichtungen. Verwaltet Immobilienportfolios und Facility Assets mit Raummanagement, Reservierungen, Kapitalprojekten, Anlagebedingungsbewertung, Leasingmanagement, Betrieb und Wartung.

Mögliche Anwendungsfälle

Viele Branchen und Branchen verwenden MAS-Lösungen, z. B. die folgenden Bereiche:

• Energie und Versorgung
• Öl- und Gasanlagen
• Fertigung
• Reisen, Automobil und Transportwesen
• Öffentlicher Sektor

Weitere Informationen zu MAS-Anwendungsfällen finden Sie auf der IBM-Website unter IBM Maximo Application Suite .

Empfehlungen

Dieser Artikel wird für aktuelle unterstützte MAS 9.x-Bereitstellungen auf Azure geschrieben. Microsoft arbeitete mit dem IBM MAS-Team und anderen Partnern zusammen, um sicherzustellen, dass diese Lösung so konfiguriert ist, dass sie optimal ausgeführt wird und die beste Erfahrung auf Azure bietet. Diese Dokumentation, Architektur und Anleitung folgen den bewährten Methoden im Microsoft Azure Well-Architected Framework. Wenden Sie sich an Ihr IBM-Kontoteam für produktspezifische Fragen und Support über diese Dokumentation hinaus.

Verwenden Sie diesen Artikel für Architekturanleitungen, wenn Sie Unterstützung von IBM und einem Partner für die Installation haben. Azure bietet auch einen Installationspfad für MAS an, der das Bringen Ihrer eigenen Lizenz unterstützt. Weitere Informationen finden Sie unter IBM Maximo Application Suite (Bring Your Own License (BYOL)).

Installieren Sie eine unterstützte MAS-Version, die IBM als kompatibel mit Ihren ausgewählten OpenShift-Versionen und MAS-Anwendungen auflistet. Verwenden Sie für neue Azure-Bereitstellungen ARO als bevorzugte OpenShift-Plattform, es sei denn, Sie benötigen einen selbstverwalteten Cluster.

Die OpenShift-Unterstützungskompatibilität hängt von drei überlappenden Supportgrenzen ab: IBM MAS-Kompatibilität, Red Hat OpenShift-Lebenszyklusunterstützung und Verfügbarkeit von ARO-Versionen. Die Verwendung einer OpenShift-Version, die IBM nicht in den Softwareproduktkompatibilitätsberichten (SPCR) auflistet oder die sich außerhalb der Red Hat- oder ARO-Unterstützung befindet, kann Ihre MAS-Bereitstellung nicht unterstützt lassen.

Bevor Sie Ihre Bereitstellung erstellen, lesen Sie die Übersicht über die IBM Maximo Application Suite, die Planung der Installation auf Microsoft Azure und die Dokumentation zu Softwareproduktkompatibilitätsberichten (SPCR), um die aktuellen Bereitstellungs- und Konfigurationsanforderungen zu verstehen.

Beantworten Sie die folgenden Fragen zum Entwurf, bevor Sie mit Ihrer Bereitstellung fortfahren:

• Welche MAS-Anwendungen benötigen Sie?
• Welche Abhängigkeiten haben Ihre Anwendungen?
• Welche OpenShift-Version unterstützt IBM für Ihre MAS-Version und -Anwendungen?
• Erfüllt ARO Ihre Anforderungen, oder benötigen Sie selbstverwaltete Red Hat OpenShift auf Azure?
• Welche Datenbanken benötigen Sie?
• Welche Anzahl und Größe von VMs benötigen Sie?
• Müssen Benutzer über externe Netzwerke eine Verbindung herstellen?

Maximo Application Suite

Verwenden Sie eine aktuelle unterstützte MAS 9.x-Version, und überprüfen Sie die unterstützten OpenShift-Versionen, Datenbanken und Abhängigkeiten in IBM SPCR, bevor Sie die Architektur abschließen. Wenn Sie eine frühere Version von Maximo Application Suite verwenden, überprüfen Sie den IBM-Lebenszyklusstatus, und planen Sie ein Upgrade auf eine unterstützte MAS 9.x-Version.

Überprüfen Sie die MAS-Anwendungen, die Sie für Ihr vollständiges Geschäftsszenario benötigen, und überprüfen Sie dann die Anforderungen für jede der Anwendungen. Weitere Informationen finden Sie unter IBM Maximo Application Suite – Systemanforderungen.

Jede MAS-Anwendung benötigt möglicherweise eine separate Datenbank. Versuchen Sie, Datenbanken zu externalisieren, wenn IBM eine externe Datenbank für die Anwendung unterstützt, da dieser Ansatz den Zustand reduziert, den Sie innerhalb von OpenShift ausführen müssen. Microsoft und IBM getestet und unterstützen die folgenden Datenbanken für MAS auf Azure:

• SQL Managed Instance
• IBM Db2 Warehouse für Cloud Pak für Daten 5

Azure SQL-Datenbank und Azure Cosmos DB werden nicht unterstützt.

Sie können auch Oracle Exadata auf Oracle Cloud Infrastructure oder auf einer VM mithilfe einer Verbindung ausführen. Diese Konfiguration wird nicht offiziell getestet, ist aber gemeldet erfolgreich. Weitere Informationen zur Verbindung finden Sie unter Interconnecting Oracle Cloud mit Microsoft Azure.

MAS und einige seiner Anwendungen sind von MongoDB und Kafka abhängig. Verwenden Sie die IBM-Standardbereitstellungen mongoDB Community Edition und Strimzi Kafka, wenn sie Ihren Support-, Sicherungs- und Wiederherstellungsanforderungen entsprechen. Diese Option ist geeignet, wenn Kafka und MongoDB interne MAS-Abhängigkeiten sind und Ihre Lösung sie nicht außerhalb von MAS verwendet.

Versuchen Sie, externe verwaltete Dienste wie MongoDB Atlas auf Azure oder confluent Cloud on Azure zu verwenden, wenn Sie eine stärkere Sicherung, Skalierung oder Notfallwiederherstellung benötigen. Einige MAS-Voraussetzungen, z. B. Behavior Analytics Services (BAS), verwenden Datenbanken, die nicht externisiert werden können, erfordern jedoch beständigen Speicher, der für den OpenShift-Cluster bereitgestellt werden muss.

Für zustandsbasierte Dienste, die im OpenShift-Cluster ausgeführt werden, sichern Sie regelmäßig Daten und verschieben Sie die Sicherungen in eine andere Region. Entwerfen, planen und entscheiden Sie sich für eine Wiederherstellungsstrategie für Katastrophen, insbesondere, wenn Sie Kafka oder MongoDB in OpenShift ausführen. Verwenden Sie für Dienste, die den Status beibehalten, externe Azure-Plattform als Service (PaaS)-Angebote, um die Unterstützung während eines Ausfalls zu verbessern.

Einige Dienste erfordern möglicherweise andere IBM-Tools und -Dienste, z. B. IBM Watson Machine Learning und IBM App Connect. Sie können alle diese Tools und Dienste auf demselben OpenShift-Cluster bereitstellen.

Azure Red Hat OpenShift

Verwenden Sie ARO als bevorzugte OpenShift-Plattform für MAS auf Azure. ARO bietet einen verwalteten OpenShift-Dienst auf Azure, wodurch die Betriebslast für die Installation, Das Patchen und Das Betreiben der OpenShift-Plattform reduziert wird. Sie besitzen weiterhin MAS und deren Anwendungskonfiguration, Arbeitskapazitätsplanung, Netzwerkintegration, Identitätsintegration, Speicheroptionen, Datenschutz und Notfallwiederherstellung.

Bevor Sie MAS auf ARO bereitstellen, sollten Sie die folgenden Empfehlungen berücksichtigen:

• Versionskompatibilität. Wählen Sie eine OpenShift-Version aus, die IBM als unterstützt für Ihre MAS-Version und ausgewählte MAS-Anwendungen auflistet. Vergewissern Sie sich, dass die gleiche OpenShift-Version verfügbar und von ARO in Ihrer Zielregion Azure Region unterstützt wird. Wählen Sie nach Möglichkeit eine gerade Nummerierte OpenShift-Version für PRODUKTIONS-MAS-Bereitstellungen aus, da diese Versionen erweiterte Updateunterstützung (Extended Update Support, EUS) sind.

  Cross-validate that IBM supports the selected OpenShift version for all selected MAS applications and dependencies. Wenn eine MAS-Komponente eine neuere ungerade OpenShift-Version als Anforderung in IBM SPCR auflistet, überprüfen Sie die vollständige Komponente, die auf IBM SPCR, Red Hat Lifecycle-Unterstützung und ARO-Versionsverfügbarkeit festgelegt ist, bevor Sie die Clusterversion auswählen.

• Bereitstellungspfad. Verwenden Sie einen vorhandenen ARO-Cluster, wenn Sie bereits Azure Zielzone, Netzwerk, Identität, Speicher und Betriebskontrollen vorhanden sind. Verwenden Sie den IBM Azure Marketplace Installationspfad, wenn Ibm bereitgestellte Automatisierung die unterstützte OpenShift-Infrastruktur erstellen oder wiederverwenden soll. Verwenden Sie selbstverwaltete Red Hat OpenShift auf Azure nur, wenn ARO Ihre Anforderungen nicht erfüllt.

• Regionsauswahl. Verwenden Sie nach Möglichkeit eine Region mit Verfügbarkeitszonen . Konfigurieren Sie ARO-Arbeitsknoten über Zonen hinweg, wenn der Zielbereich dieses Muster unterstützt. Konfigurieren Sie für selbstverwaltete OpenShift die Installationsdatei install-config.yaml, sodass OpenShift Knoten über Zonen hinweg platziert. Wenn es einen Ausfall in einer Zone gibt, kann Ihre Lösung weiterhin funktionieren, indem Knoten in anderen Zonen die Arbeit übernehmen.

• Sicherung und Wiederherstellung. Sie können die Azure Red Hat OpenShift Sicherungs- und Wiederherstellungsanweisungen verwenden. Weitere Informationen finden Sie unter Create an Azure Red Hat OpenShift 4 cluster application backup. Wenn Sie diese Methode für Sicherung und Wiederherstellung verwenden, müssen Sie eine andere Methode für die Notfallwiederherstellung für die Datenbank bereitstellen.

• Failover. Berücksichtigen Sie die Bereitstellung von OpenShift in zwei Regionen und die Verwendung von Red Hat Advanced Cluster Management. Wenn Ihre Lösung über öffentliche Endpunkte verfügt, können Sie Azure Traffic Manager zwischen den Endpunkten und dem Internet platzieren, um den Datenverkehr an den entsprechenden Cluster in einem regionalen Ausfall umzuleiten. In diesem Fall müssen Sie auch die Status und persistenten Volumes Ihrer Anwendungen migrieren.

Selbstverwaltetes OpenShift

Verwenden Sie selbstverwaltete Red Hat OpenShift auf Azure, wenn ARO Ihre Anforderungen an Die Steuerung, Isolierung oder getrennte Bereitstellung nicht erfüllt. Wählen Sie für selbstverwaltete Bereitstellungen zwischen den folgenden Installationsmethoden aus:

• Vom Installationsprogramm bereitgestellte Infrastruktur (IPI). Diese Methode verwendet ein Installationsprogramm, um die OpenShift-Umgebung auf Azure bereitzustellen und zu konfigurieren. Verwenden Sie IPI, wenn sie Ihre Sicherheits- und Netzwerkanforderungen erfüllt.

• Benutzerbereitgestellte Infrastruktur (UPI). Mit dieser Methode können Sie ihre Bereitstellung präzise steuern. UPI erfordert weitere Schritte und Überlegungen zum Erstellen Ihrer Umgebung. Verwenden Sie UPI, wenn IPI oder ARO Ihre Anforderungen nicht erfüllen. Eine private oder getrennte Installation ist ein gängiger Anwendungsfall für UPI.

Luftgespaltene Installation

In einigen Fällen, z. B. bei der Einhaltung gesetzlicher Vorschriften, kann eine luftgespaltene Installation von MAS auf Azure erforderlich sein. Air gapped bedeutet, dass kein eingehender oder ausgehender Internetzugang vorhanden ist. Ohne Internetverbindung kann Ihre Installation die Abhängigkeiten für DIE MAS- oder OpenShift-Installation zur Laufzeit nicht abrufen.

Verwenden Sie eine luftgespaltene Installation nur, wenn sie eine Sicherheitsanforderung ist. Ein Luftabstand erhöht die Komplexität bei Lösungsvorgängen. Aktivitäten wie das Installieren von Software, Spiegelungscontainern, Aktualisieren von Spiegelungen zum Schutz vor Sicherheitsrisiken oder das Verwalten von Firewalls können erhebliche Betriebliche Anstrengungen erfordern.

Weitere Informationen zu luftgespaltenen Installationen finden Sie in der folgenden Red Hat OpenShift-Dokumentation zu getrennten Installationen und privaten Clustern auf Azure:

• Spiegeln von Bildern für eine getrennte Installation mit oc-mirror
• Installieren eines privaten Clusters auf Azure

Nach einer air-gapped OpenShift-Installation können Sie mit der MAS-Dokumentation fortfahren, um Anleitungen zu getrennten Umgebungen zu erhalten.

Knoten- und Umgebungsgröße

Beginnen Sie für alle Workloads mit Ausnahme von Maximo Visual Inspection mit vm-Familien der aktuellen Generation ds oder die Serie, z. B. Dsv6, die als Arbeitsknoten in Ihrer ausgewählten Region verfügbar sind. Wählen Sie VM-Größen aus, die Premiumspeicher unterstützen und die CPU-, Speicher- und Speicheranforderungen für die von Ihnen bereitgestellten MAS-Anwendungen erfüllen.

Maximo Visual Inspection erfordert GPU-Knoten zum Ausführen des maschinellen Lernens. Die Lösung verwendet CUDA und unterstützt nur NVIDIA GPUs. Wählen Sie für ARO eine NVIDIA GPU VM-Größe aus der aktuellen Supportliste des ARO-Workerknotens aus, und bestätigen Sie dann, dass IBM sie für Ihre MAS- und OpenShift-Versionen unterstützt. Wählen Sie für selbstverwaltete OpenShift eine NVIDIA GPU VM-Größe aus, die von IBM und Red Hat unterstützt wird.

Beginnen Sie bei GPU-Workerknoten mit dem kleinsten Knoten, und skalieren Sie, wenn Ihre Anforderungen steigen.

Verwenden Sie für ARO und selbstverwaltete OpenShift die gleiche MAS-Workloadanpassungsanleitung für Arbeitsknoten. Konfigurieren Sie Arbeitsknoten über Verfügbarkeitszonen hinweg, um hohe Verfügbarkeit zu unterstützen. Konfigurieren Sie für selbstverwaltete OpenShift auch die Steuerungsebene über Verfügbarkeitszonen hinweg. Verwenden Sie den folgenden Ausgangspunkt:

• Kontrollknoten. Für ARO wird die Steuerungsebene als Teil des Dienstes verwaltet. Verwenden Sie für selbstverwaltete OpenShift mindestens eine VM pro Verfügbarkeitszone innerhalb der ausgewählten Region.

• Workerknoten. Verwenden Sie mindestens zwei Computer pro Verfügbarkeitszone innerhalb der ausgewählten Region. Größe von Workerknoten basierend auf IBM-Anleitungen, ausgewählten MAS-Anwendungen und erwarteter Auslastung.

MAS Core erfordert für eine standardmäßig dimensionierte Basisinstallation 13 vCPUs. Die Dimensionierung für die Workerknoten variiert je nachdem, welche MAS-Anwendungen Ihre Konfiguration implementiert, sowie der Last auf Ihrer Umgebung. Beispielsweise erfordert Maximo Manage für 10 Benutzer weitere 2 vCPUs. Behandeln Sie diese Werte als Ausgangspunkte und überprüfen Sie die Größenanpassung anhand der aktuellen SYSTEManforderungen von IBM Maximo Application Suite für Ihre MAS 9.x-Version, ausgewählte Anwendungen und die erwartete Nutzung.

Für selbstverwaltete OpenShift versuchen Sie, VM-Typen ähnlich zu halten, um näherung mit jedem der Verfügbarkeitszonen zwischen Worker- und Steuerknoten bereitzustellen. Richten Sie für ARO Arbeitsknotenpools an den gleichen ANFORDERUNGEN an die MAS-Workload und Azure regionale Kapazität aus.

Wenn Sie ein Sprungfeld benötigen, um die OpenShift-Befehlszeilenschnittstelle oc zu verwenden oder MAS zu installieren, stellen Sie eine unterstützte Linux-VM bereit, die den administrativen und Sicherheitsanforderungen Ihrer Organisation entspricht.

Netzwerkkonfiguration

Verwenden Sie für ARO die standardmäßige OpenShift-Netzwerkkonfiguration, die ARO bereitstellt, es sei denn, IBM, Red Hat und Ihr Netzwerkteam überprüfen eine andere Option. Planen Sie das virtuelle Netzwerk und separate Subnetze für ARO-Steuerebenenknoten, Arbeitsknoten, Azure Dienstabhängigkeiten, private Endpunkte, Datenbanken und Hybridkonnektivität. Größe der Knotensubnetze für die Anzahl der benötigten OpenShift-Workerknoten, einschließlich Upgradekapazität und zukünftiger Skalierung.

Für selbstverwaltete OpenShift umfassen auch Bootstrap- und installer-erstellte Infrastrukturanforderungen. Behalten Sie den Administratorzugriff auf die OpenShift-API und Knoten auf genehmigte Netzwerkpfade beschränkt, z. B. Hybridkonnektivität, gesicherte Sprunghosts oder andere Steuerelemente, die Ihre Organisation benötigt. Wenn Sie den Clusterausgang einschränken, planen Sie die erforderlichen ausgehenden Abhängigkeiten für OpenShift, MAS-Installation, Containerimage-Pulls, Updates, Überwachung und externe Dienste.

Für eine standardmäßige MAS-Produktionsinstallation auf ARO beginnen Sie nicht mit einem eng verpackten virtuellen Netzwerk. Reservieren Sie einen größeren Adressraum, z. B. ein CiDR-Präfix (Classless Inter-Domain Routing) von /16, wenn Die Zielzone dies zulässt, und weisen Sie dedizierte Subnetze zu. Verwenden Sie mindestens eine /24 Planungsgröße für das Subnetz der ARO-Steuerungsebene und mindestens eine /24-Planungsgröße für das Subnetz des Arbeitsknotens. Fügen Sie ein /27 oder ein größeres Subnetz für private Endpunkte und externe Datenbankdienste hinzu. Wenn Sie optional Azure Bastion bereitstellen, fügen Sie ein Subnetz namens "AzureBastionSubnet" mit dem Präfix "/26" hinzu. Weitere Informationen zu Azure Bastion Anforderungen finden Sie unter Architektur.

Wenn Sie selbstverwaltete OpenShift verwenden und kurz auf IP-Adressen sind, können Sie eine eingeschränkte hoch verfügbare Konfiguration mit dem Mindestpräfix "/27" für das Subnetz des Steuerelementknotens und /27 für das Subnetz des Arbeitsknotens entwerfen. Verwenden Sie diese eingeschränkte Größenanpassung nicht als Ausgangspunkt für eine ARO-Produktionsbereitstellung. Entfernen Sie die Subnetze des virtuellen Netzwerks oder Knotens nicht. Lesen einer OpenShift-Bereitstellung, nachdem die Installation störend ist und möglicherweise eine erneute Bereitstellung erforderlich ist.

Wenn Sie eine andere Containernetzwerkschnittstelle (Container Network Interface, CNI) verwenden möchten, sollten Sie ihre Netzwerke entsprechend anpassen. MAS mit einigen Standardanwendungen stellt über 800 Pods bereit, die wahrscheinlich ein CIDR-Präfix von /21 oder größer erfordern.

Datenbankbesonderheiten

Einige MAS-Komponenten verwenden MongoDB als Metadatenspeicher. Der Standardleitfaden besteht darin, MongoDB Community Edition innerhalb des Clusters bereitzustellen. Wenn Sie diese Methode verwenden, stellen Sie sicher, dass Sie über ein ordnungsgemäßes Verfahren zum Sichern und Wiederherstellen der Datenbank verfügen. Erwägen Sie die Verwendung von MongoDB Atlas auf Azure, um einen externen Speicher, Sicherungen und Skalierung bereitzustellen. Azure unterstützt derzeit die Verwendung von MongoDB-APIs mit Azure Cosmos DB nicht.

Wenn Sie IoT-Dienste bereitstellen, müssen Sie auch einen Kafka-Endpunkt bereitstellen. Der Standardleitfaden ist die Verwendung von Strimzi zum Bereitstellen von Kafka im OpenShift-Cluster, aber Daten innerhalb von Strimzi gehen während der Notfallwiederherstellung wahrscheinlich verloren. Wenn Datenverlust in Kafka inakzeptabel ist, erwägen Sie die Verwendung von Confluent Kafka auf Azure. Derzeit werden Azure Event Hubs nicht mit Kafka-Endpunkten unterstützt.

MAS enthält mehrere Datenbanken in ihren Pods, und diese Datenbanken behalten ihre Zustände auf dem Dateisystem, das für MAS bereitgestellt wird. Um Zonenfehler zu absorbieren, verwenden Sie einen Zonenredundanzspeichermechanismus (ZRS), um die Zustände außerhalb Ihrer Cluster beizubehalten. Das empfohlene Muster besteht darin, Azure Dateispeicher mit den folgenden Konfigurationen zu verwenden:

• Standard stellt SMB-Freigaben für geringeren Durchsatz und ReadWriteOnce (RWO)-Workloads bereit. Verwenden Sie Standard für Teile der Anwendung, die nicht häufig in den Speicher geschrieben werden, und benötigen Sie ein einzelnes persistentes Volume, z. B. IBM Single-Level Storage.

• Premium bietet NFS-Freigaben für höhere Durchsatz- und ReadWriteMany-Workloads (RWX). Volumes wie diese werden im gesamten Cluster für RWX-Workloads verwendet, z. B. Db2 Warehouse in Cloud Pak für Daten oder Postgres in Maximo Manage.

Azure Files NFS unterstützt die Verschlüsselung während der Übertragung. Wenn der MAS OpenShift-Client keine NFS-Verschlüsselung verwenden kann, können Sie das Konto von den Richtlinien für die Durchsetzung sicherer Übertragungen ausschließen. Weitere Informationen finden Sie unter NFS Azure Dateifreigaben: Verschlüsselung. Verwenden Sie einen privaten Endpunkt , um private Verbindungen mit Ihren Freigaben bereitzustellen.

Wenn Sie Db2 Warehouse über Cloud Pak für Daten bereitstellen, verwenden Sie OpenShift Data Foundation. Ein OpenShift Data Foundation-Beispiel, das Ceph File System (CephFS) und RADOS Block Device (Ceph RBD)-Speicherklassen für verschiedene Db2 Warehouse-Datentypen verwendet, finden Sie unter Creating the Db2 instance by using the Cloud Pak for Data console.

Verwenden Sie nicht Azure Blob Storage mit CSI-Treibern (Container Storage Interface), da sie keine harten Links unterstützt, die von einigen Pods ausgeführt werden müssen.

Überlegungen

Diese Überlegungen implementieren die Säulen des Azure Well-Architected-Frameworks, die eine Reihe von Leitsätzen sind, die Sie verwenden können, um die Qualität einer Arbeitsauslastung zu verbessern. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Zuverlässigkeit

OpenShift verfügt über integrierte Funktionen für die Selbstheilung, Skalierung und Resilienz. OpenShift und MAS erwarten, dass Komponenten fehlschlagen und wiederhergestellt werden. Eine wichtige Voraussetzung für die Selbstheilung ist, dass der Cluster über genügend Arbeitsknoten verfügt. Um sich von einem Zonenfehler innerhalb einer Azure-Region zu erholen, müssen Ihre Kontroll- und Arbeitsknoten über Verfügbarkeitszonen hinweg ausgeglichen werden.

MAS und OpenShift verwenden Speicher, um den Zustand außerhalb des Kubernetes-Clusters beizubehalten. Um sicherzustellen, dass die Speicherabhängigkeiten bei einem Ausfall weiterhin funktionieren, sollten Sie möglichst zonenredundanten Speicher verwenden. Zonenredundanter Speicher bleibt verfügbar, wenn eine einzelne Zone fehlschlägt.

Um menschliche Fehler zu vermeiden, stellen Sie MAS mithilfe einer möglichst viel Automatisierung bereit. Verwenden Sie die aktuelle IBM-Installationsdokumentation und unterstützte Automatisierung für Ihre ausgewählte MAS-Version, OpenShift-Plattform und den Bereitstellungspfad.

Sicherheit

Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Entwurfsprüfliste für die Sicherheit.

Die Aufrechterhaltung des Zugriffs und der Sichtbarkeit im Wartungslebenszyklus Ihrer Anlagen kann eine der größten Chancen für Ihre Organisation sein, effizient zu arbeiten und die Betriebszeit aufrechtzuerhalten. Um den Sicherheitsstatus Ihrer Umgebung zu verbessern, ist es wichtig, die sichere Authentifizierung zu verwenden und Ihre Lösungen auf dem neuesten Stand zu halten. Verwenden Sie eine Verschlüsselung, um alle Daten zu schützen, die in Ihre Architektur bzw. aus Ihrer Architektur übertragen werden.

Durch die Verwendung von ARO-Bereitstellungen profitieren Sie vom ARO-Modell für gemeinsame Verantwortung. Azure Red Hat OpenShift wird gemeinsam von Microsoft und Red Hat entwickelt, betrieben und unterstützt, die die verwaltete OpenShift-Plattform in Ihrem Auftrag patchen, aktualisieren und überwachen. Sie bleiben für Bereitstellungen über ARO verantwortlich. Diese Verantwortung umfasst MAS und seine Anwendungskonfiguration, Identitätsintegration, Netzwerkkontrollen, Arbeitskapazitätsplanung, Speicheroptionen, Sicherung und Notfallwiederherstellung, geheime Schlüssel, Datenschutz und Compliance-Anforderungen. Weitere Informationen finden Sie in der Einführung in Azure Red Hat OpenShift und Azure Red Hat OpenShift 4.0-Supportrichtlinie.

Microsoft erstellt Sicherheitsschutz auf der Azure-Plattform auf den folgenden Ebenen:

• Physisches Rechenzentrum
• Physisches Netzwerk
• Physischer Host
• Hypervisor

Verwenden Sie eine OpenShift-Version, die Ihre OpenShift-Plattform unterstützt und von IBM für Ihre MAS-Version und -Anwendungen unterstützt wird. Verwenden Sie nach Möglichkeit eine unterstützte langfristige Supportversion. Wenn Sie selbstverwaltete OpenShift verwenden, sind Sie für das Patchen und Verwalten der OpenShift-Plattform und der zugrunde liegenden VMs verantwortlich. Wenn Sie ARO verwenden, behandelt Microsoft das Patching und die Verwaltung.

Nutzen Sie Netzwerksicherheitsgruppen, um Netzwerkdatenverkehr von und zu Ressourcen in Ihrem virtuellen Netzwerk zu filtern. Mithilfe dieser Gruppen können Sie Regeln definieren, die Den Zugriff auf Ihre MAS-Dienste gewähren oder verweigern, z. B.:

• Zulassen des SSH-Zugriffs auf die OpenShift-Knoten zur Problembehandlung.
• Blockieren des Zugriffs auf alle anderen Teile des Clusters.
• Steuern, welche Speicherorte auf MAS und den OpenShift-Cluster zugreifen können.

Um auf Ihre virtuellen Computer zuzugreifen, können Sie über die Hybridkonnektivität oder über die OpenShift-Verwaltungskonsole eine Verbindung herstellen. Wenn Sie über eine Onlinebereitstellung verfügen oder sich nicht auf die Hybridkonnektivität verlassen möchten, können Sie über Azure Bastion auf Ihre virtuellen Computer zugreifen. Aus Sicherheitsgründen machen Sie VMs nicht für ein Netzwerk oder das Internet verfügbar, ohne Netzwerksicherheitsgruppen für die Steuerung des Zugriffs zu konfigurieren.

Serverseitige Verschlüsselung (SSE) von Azure Disk Storage schützt Ihre Daten und hilft Ihnen bei der Erfüllung von Sicherheits- und Complianceverpflichtungen der Organisation. Mit Azure verwalteten Datenträgern verschlüsselt SSE ruhende Daten beim Speichern in der Cloud. Dieses Verhalten gilt standardmäßig sowohl für Betriebssystem- als auch für Datenträger. OpenShift verwendet standardmäßig SSE.

Authentifizierung

MAS unterstützt SSO mit Security Assertion Markup Language (SAML). Um Microsoft Entra ID als SAML-Identitätsanbieter zu verwenden, erstellen Sie eine Unternehmensanwendung in Microsoft Entra ID und konfigurieren MAS als Dienstanbieter. Weitere Informationen finden Sie unter Microsoft Entra SSO-Integration in Maximo Application Suite.

Überprüfen Sie vor dem Einrichten der SAML-basierten Authentifizierung sowohl die IBM-Konfiguration als auch die Azure-Konfiguration. Informationen zu SAML mit MAS finden Sie unter Konfigurieren der SAML-Authentifizierung. Informationen zu SAML mit Azure finden Sie unter Quickstart: Aktivieren des einmaligen Anmeldens für eine Unternehmensanwendung.

Sie sollten auch OAuth für den administrativen Zugriff von OpenShift konfigurieren. For ARO, see Configure Microsoft Entra authentication for an Azure Red Hat OpenShift cluster. Informationen zu selbstverwalteten OpenShift finden Sie unter Konfigurieren von Identitätsanbietern in openShift Container Platform 4.21.

Ressourcenzugriff und -überwachung

Steuern Sie den Zugriff auf die Azure Ressourcen, die Sie bereitstellen. Jedes Azure-Abonnement verfügt über eine Trust-Beziehung mit einem Microsoft Entra Mandanten. Verwenden Sie Azure rollenbasierte Zugriffssteuerung (Azure RBAC), um Benutzern innerhalb Ihrer Organisation die richtigen Berechtigungen für Azure-Ressourcen zu gewähren. Gewähren Sie Zugriff, indem Sie Benutzern oder Gruppen Azure Rollen in einem bestimmten Bereich zuweisen, z. B. einem Abonnement, einer Ressourcengruppe oder einer einzelnen Ressource. Überwachen Sie alle Änderungen an der Infrastruktur. Weitere Informationen zur Überwachung finden Sie unter Azure Monitor Aktivitätsprotokoll.

Kostenoptimierung

Die Kostenoptimierung konzentriert sich auf Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Design Review-Checkliste für die Kostenoptimierung.

Eine standardmäßige MAS-Bereitstellung auf Azure umfasst die folgenden primären Kostentreiber:

• ARO-Clusterkosten, einschließlich Arbeitsknoten und alle abrechnenden Steuerebenen- oder Clustergebühren
• Größe der Arbeitsknotenpools für MAS Core und die von Ihnen bereitgestellten MAS-Anwendungen
• Optionale GPU-Workerknoten für maximo Visuelle Inspektion
• Datenbankdienste wie SQL Managed Instance, Db2 Warehouse oder eine andere von IBM unterstützte Datenbank
• Speicherkonten oder verwaltete Speicherdienste für persistente Volumes, Sicherungen und Installationsartefakte
• DNS-Zonen, Lastenausgleich, private Endpunkte und eine optionale Instanz von Azure Bastion

Für ARO und selbstverwaltete OpenShift verwendet eine standardmäßige MAS-Bereitstellung in der Regel den gleichen Basisplan für die Größe des Arbeitsknotens. Verwenden Sie den folgenden Bestand als Ausgangspunkt für die Kostenschätzung:

• Sechs Arbeits-VMs.
• Drei Arbeits-VMs für Db2 Warehouse. Sie können SQL Managed Instance in einigen Konfigurationen ersetzen, anstatt Db2 Warehouse zu verwenden.
• Zwei Azure Storage Konten.
• Zwei DNS-Zonen.
• Zwei Lastenausgleichsgeräte.
• Azure Bastion
• Ein Maximo Visual Inspection GPU-Workerknoten, wenn Sie beabsichtigen, Maximo Visual Inspection in MAS auszuführen.

Die Kosten für die Steuerungsebene unterscheiden sich je nach Bereitstellungsmodell. Für selbstverwaltete OpenShift-Bereitstellungen, die IPI oder UPI verwenden, umfassen auch drei Steuerelement-VMs. Berücksichtigen Sie für ARO die verwaltete Steuerungsebene und alle ARO-spezifischen Clustergebühren, anstatt vom Kunden verwaltete Steuerelement-VMs hinzuzufügen.

Sie können eine Beispielschätzung mithilfe des Kostenrechners überprüfen. Konfigurationen variieren. Überprüfen Sie daher Ihre Konfiguration mit Ihrem IBM-Größenteam, bevor Sie die Bereitstellung abschließen.

Dieses Szenario bereitstellen

Bevor Sie beginnen, lesen Sie die Systemanforderungen von IBM Maximo Application Suite und IBM SPCR für Ihre MAS-Version und -Anwendungen. Stellen Sie die folgenden Ressourcen zur Verfügung, bevor Sie die Bereitstellung starten:

• Zugriff auf ein Azure-Abonnement mit Leseberechtigung
• Ein Anwendungsregistrierungs- oder Dienstprinzipalname, der über Berechtigungen für mitwirkende und Benutzerzugriffsadministratoren für das Abonnement verfügt
• Eine Domäne oder delegierte Unterdomäne an eine Azure DNS Zone
• Ein unterstützter ARO-Cluster oder die Berechtigungen und Voraussetzungen zum Erstellen eines
• Ein Pullschlüssel von Red Hat, wenn Ihr Bereitstellungspfad OpenShift-Infrastruktur erstellt oder verwaltet
• Ein MAS-Berechtigungsschlüssel
• Eine MAS-Lizenzdatei, die Sie nach der MAS-Installation erstellen
• IBM-empfohlene Clusterdimensionierung
• Ein vorhandenes virtuelles Netzwerk oder ein neues virtuelles Netzwerk, das die Anforderungen von ARO und MAS erfüllt
• Hohe Verfügbarkeits- und Notfallwiederherstellungsanforderungen für Ihre spezifische Bereitstellung
• Konfigurationsdetails für den ausgewählten Bereitstellungspfad, z. B. ARO-Clusterdetails oder selbstverwaltete OpenShift-Installationsparameter

Bevor Sie Ihre Umgebung erstellen, lesen Sie die IBM Planning für die Installation in Microsoft Azure Dokumentation, um die Entwurfsparameter zu verstehen. Aktuelle Azure Installationsanleitungen finden Sie unter Maximo Application Suite auf Microsoft Azure Übersicht. Überprüfen Sie Ihren Bereitstellungsprozess anhand der aktuellen IBM-Dokumentation und der Supportmatrix für Ihre MAS-Version.

Überlegungen zur Bereitstellung

Stellen Sie Workloads mithilfe der Infrastruktur als Code (IaC) und nicht manuell bereit. Die manuelle Bereitstellung kann zu einer Fehlkonfiguration führen. Containerbasierte Workloads können empfindlich auf Fehlkonfigurationen reagieren, was die Produktivität verringern kann.

IBM bietet fachspezifische Dienstleistungen, die Ihnen bei der Installation helfen. Wenden Sie sich an Ihr IBM-Team, um Support zu erhalten.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautoren:

• David Baumgarten | Chefarchitekt
• Roeland Nieuwenhuis | Chefarchitekt

Um nicht öffentliche LinkedIn-Profile zu sehen, melden Sie sich bei LinkedIn an.

Nächste Schritte

Um Ihnen den Einstieg zu erleichtern, finden Sie in den folgenden Ressourcen Hilfe:

• Azure Red Hat OpenShift
• Maximo Application Suite auf Microsoft Azure Übersicht
• Planen der Installation auf Microsoft Azure
• Installieren von OpenShift auf Azure
• OpenShift UPI Handbuch
• Anforderungen für Maximo
• IBM Software Product Compatibility Reports
• IBM Maximo Application Suite (BYOL)

Weitere Informationen zu den vorgestellten Technologien finden Sie in den folgenden Artikeln:

• IBM Passport Advantage
• Introduktion zum Azure DNS
• Einführung zu Azure NetApp Files
• Einführung in Azure Red Hat OpenShift
• Red Hat Kundenportal

Zugehörige Ressourcen

• Azure Enterprise Cloud File Share
• Stellen Sie eine Java-Anwendung mit der JBoss Enterprise Application Platform (EAP) in einem ARO-Cluster bereit