Bereitstellen von IBM Maximo Application Suite in Azure

IBM Maximo Application Suite (MAS) 8.x wird auf OpenShift ausgeführt. Es empfiehlt sich, sich mit OpenShift und den vorgeschlagenen Mustern für die Installation in Azure vertraut zu machen. Weitere Informationen finden Sie unter Vorbereiten der Installation in Azure. Diese Architektur veranschaulicht einen OpenShift-Cluster. Es wird nicht ausführlich erläutert, wie MAS installiert wird. Weitere Informationen zum Installationsvorgang finden Sie unter Installation der Maximo Application Suite von OperatorHub.

Aufbau

Laden Sie eine Visio-Datei dieser Architektur herunter.

Der Workload kann intern oder extern bereitgestellt werden, je nach Ihren Anforderungen.

Workflow

Aus der Sicht der Infrastruktur stellt diese Architektur Folgendes bereit:

• Eine Containerhostingplattform zum Bereitstellen hoch verfügbarer Workloads in Verfügbarkeitszonen
• Eine privatisierte Bereitstellung von Worker- und Steuerungsknoten, die in den Speicher integriert sind
• Premium- und Standard-Dateien in Azure Files für die Speicherung (OpenShift Data Foundation nicht erforderlich)
• SQL Server auf Azure-VMs oder in containerbasiertem IBM Db2 Warehouse
• Azure DNS für die DNS-Verwaltung von OpenShift und seinen Containern
• Microsoft Entra ID für einmaliges Anmelden (Single Sign-On, SSO) bei MAS

Komponenten

• Azure Virtual Machines, um die OpenShift-Plattform zu hosten und die Maximo-Container auszuführen. Virtual Machines ist ein IaaS-Angebot (Infrastructure-as-a-Service). Sie können mit Virtual Machines skalierbare Computingressourcen bedarfsorientiert bereitstellen.

• Red Hat Enterprise Linux CoreOS, um ein benutzerdefiniertes VM-Image für OpenShift bereitzustellen.

• Azure Load Balancers zum Bereitstellen der Konnektivität mit dem Cluster. Azure Load Balancer ist ein äußerst leistungsfähiger Lastenausgleichsdienst (eingehend und ausgehend) der Ebene 4 mit extrem niedriger Latenz für alle UDP- und TCP-Protokolle. Er ist für die Verarbeitung von Millionen von Anforderungen pro Sekunde konzipiert und stellt sicher, dass Ihre Lösung hochverfügbar ist. Azure Load Balancer ist zonenredundant und gewährleistet Hochverfügbarkeit über mehrere Verfügbarkeitszonen hinweg.

• Virtual Network für die Kommunikation zwischen Knoten, Azure-Diensten und Hybridkonnektivitätsanforderungen. Virtual Networks ist der grundlegende Baustein für private Netzwerke in Azure.

• Azure Files zum Hosten der zustandsbehafteten Daten für die Datenbanken und Systeme innerhalb des Clusters. Azure Files bietet vollständig verwaltete Dateifreigaben in der Cloud, auf die über SMB und NFS-Protokolle (Network File System) zugegriffen werden kann.

• Azure DNS zum Verwalten der 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 (optional) und ein Subnetz für sichereren Zugriff auf einen der Workerknoten oder optionalen JumpBox-Computer. Azure Bastion ist ein vollständig verwalteter Dienst, der ohne Gefährdung durch öffentliche IP-Adressen nahtlosen RDP-Zugriff und SSH-Zugriff auf VMs mit erweiterter Sicherheit bietet.

• SQL Server in Azure Virtual Machines (optional) zum Bereitstellen von Datendiensten für MAS. Die Datenbank kann auch eine andere sein, z. B. Oracle Exadata oder IBM Db2 Warehouse. Azure SQL-Datenbank und Azure SQL Managed Instance werden derzeit nicht unterstützt.

• Twilio Send Grid (optional), um E-Mails von MAS an Ihre Consumer zu senden.

• Virtuelle Linux-Computer in Azure (optional), um eine Jump-Box zur Installation von OpenShift bereitzustellen. Sie können diese VM auch verwenden, um den OpenShift-Cluster zu verbinden und zu verwalten, da er die Kubernetes-Konfigurationsdatei nach der Installation enthält. Wenn Sie über Netzwerkkonnektivität in Ihre Azure-Umgebung verfügen, können Sie die Installation von einem vorhandenen Computer ausführen.

Alternativen

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

• Azure NetApp Files als Ersatz für Azure Files. Azure NetApp Files unterstützt jede Art von Workload mit hoher Verfügbarkeit und Hochleistung.
• Oracle Database in Azure, wenn Sie diese SQL Server oder Db2 Warehouse vorziehen.
• OpenShift Data Foundation, wenn Sie Db2 Warehouse auf OpenShift Data Foundation verwenden möchten.

Szenariodetails

IBM's Maximo Application Suite (MAS), auch als Maximo bekannt, ist eine Enterprise-Asset Management-Plattform mit KI-basierter Asset-Wartung. MAS konzentriert sich auf operative Resilienz und Zuverlässigkeit. Die Suite besteht aus einer Kernanwendungsplattform, MAS und Anwendungen und branchenspezifischen Lösungen auf der Plattform. Jede Anwendung bietet einen bestimmten Vorteil:

• Verwalten. Reduzieren Sie Ausfallzeit und Kosten, indem Sie die Ressourcenverwaltung verwenden, um die operative Leistung zu verbessern.
• Überwachen. Verwenden Sie IoT für die erweiterte KI-unterstützte Überwachung von Remoteressourcen im großen Stil.
• Integrität: Verwalten Sie die Ressourcenintegrität mithilfe von IoT-Daten aus Sensoren, Ressourcendaten und Wartungsverlauf.
• Visuelle Prüfung. Trainieren Sie Machine Learning-Modelle, um visuelle Inspektionen zur visuellen Analyse neuer Probleme zu verwenden.
• Prognosen. Prognostizieren Sie zukünftige Fehler mithilfe von maschinellem Lernen und Datenanalysen.
• Unterstützung. Unterstützen Sie Techniker, indem Sie KI-gestützte Anleitungen für eine Wissensdatenbank von Gerätewartungsdaten bereitstellen und ihnen Remotezugriff auf Experten gewähren.
• Sicherheit. Sammeln und analysieren Sie Daten aus Sensoren, stellen Kontextdaten bereit und leiten aussagekräftige Analysen ab.
• Zivil. Integrieren Sie Inspektions-, Mängelverfolgungs- und Wartungsaktivitäten, um die Lebensdauer von Ressourcen zu verbessern, kritische Systeme zu betreiben und die Gesamtkosten des Besitzes der zivilen Infrastruktur zu senken.

Diese Anwendungen und MAS 8.x wird für die Verwendung in Azure getestet. Microsoft und das IBM Maximo-Team haben sich zusammengetan, um sicherzustellen, dass diese Lösung so konfiguriert ist, dass sie optimal in Azure ausgeführt wird. Dieser Artikel enthält ein Design für die Ausführung von MAS 8.x in Azure für Kunden, die Unterstützung von IBM und einem Partner für die Installation haben. Wenden Sie sich bei produktspezifischen Fragen an Ihr IBM-Team. Der Azure Marketplace bietet eine alternative Installation für MAS, die das Mitbringen Ihrer eigenen Lizenz unterstützt. Weitere Informationen finden Sie unter IBM Maximo Application Suite (Bring Your Own License (BYOL)).

Mögliche Anwendungsfälle

Viele Branchen und Branchen nutzen die Lösungen in MAS, z. B.:

• Energie und Versorgung
• Öl- und Gasanlagen
• Fertigung
• Automobilindustrie und Transportwesen
• Öffentlicher Sektor

Weitere Informationen zu Anwendungsfällen für MAS finden Sie auf der Website der IBM Maximo Application Suite.

Empfehlungen

Es wird empfohlen, die neueste stabile Version von MAS zu installieren, da sie die besten Integrationsoptionen mit Azure bietet. Achten Sie auf die unterstützten Versionen von OpenShift, da die unterstützten Versionen mit der spezifischen Version von MAS variieren.

Die Verwendung früherer oder höherer Hauptversionen von OpenShift kann dazu führen, dass die offizielle Unterstützung für MAS nicht mehr gegeben ist. Bevor Sie Ihre eigene Bereitstellung erstellen, empfehlen wir die Verwendung des Schnellstarthandbuchs zum Bereitstellen von MAS, damit Sie verstehen, wie die Bereitstellung und Konfiguration funktioniert. Das Wissen, wie dies erfolgt, beschleunigt die Erstellung der Entwurfsanforderungen für Ihre Implementierung. Weitere Informationen finden Sie im Schnellstarthandbuch: Maximo Application Suite in Azure.

Wir arbeiten eng mit IBM und anderen Partnern zusammen, um sicherzustellen, dass die Anleitungen, Architektur und das Schnellstarthandbuch Ihnen die beste Erfahrung in Azure bieten. Sie befolgen die bewährten Methoden wie im Microsoft Azure Well-Architected Framework beschrieben. Wenden Sie sich an Ihr IBM-Kontoteam, um den Support über diese Dokumentation hinaus zu erhalten.

Bevor Sie mit Ihrer Bereitstellung fortfahren, müssen Sie die folgenden Fragen zum Entwurf beantworten:

• Welche MAS-Anwendungen benötigen Sie?
• Welche Abhängigkeiten haben Ihre Anwendungen?
• Welche Version von OpenShift ist erforderlich?
• Welche Methode der Installation von OpenShift sollten Sie verwenden?
• Welche Datenbanken sind erforderlich?
• Welche Anzahl und Größe von VMs benötigen Sie?
• Stellen Benutzer eine Verbindung aus externen Netzwerken her?

Maximo Application Suite

Microsoft hat MAS-Versionen 8.5 und höher in Azure getestet. Unsere Empfehlung besteht darin, die neueste Version von MAS zu verwenden, also die Version 8.7.

Ü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 der Anwendungen benötigt möglicherweise separate Datenbanken. Wir haben die folgenden Datenbanken in Azure getestet und unterstützen sie:

• SQL Server in Azure Virtual Machines Version 2019 unter Verwendung von Windows oder Linux
• IBM Db2 Warehouse on Cloud Pak for Data 3.5

Möglicherweise können Sie auch Oracle Exadata auf einer VM oder in Oracle Cloud Infrastructure ausführen, indem Sie die Verbindung verwenden – aber diese Konfiguration wurde nicht getestet. Weitere Informationen zur Verbindung finden Sie unter Verbinden von Oracle Cloud mit Microsoft Azure. Derzeit werden Azure SQL-Datenbank, Azure SQL Managed Instance und Azure Cosmos DB nicht unterstützt.

MAS und einige seiner Anwendungen verfügen über Abhängigkeiten von MongoDB und Kafka. Entscheiden Sie, wie Sie diese Lösungen basierend auf Überlegungen zur Leistung und Vorgängen bereitstellen. Die Standardwerte sind die Bereitstellung von MongoDB Community Edition und Strimzi Kafka innerhalb der Cluster. Einige der Voraussetzungen von MAS, z. B. BAS, verwenden Datenbanken, die nicht externalisiert werden können, aber die beständigen Speicher erfordern, der für den OpenShift-Cluster bereitgestellt werden müssen.

Für zustandsbasierte Dienste, die im OpenShift-Cluster ausgeführt werden, werden häufig Daten gesichert und die Sicherungen in eine andere Region verschoben. Entwerfen und planen Sie eine Wiederherstellungsstrategie für den Notfall, und treffen Sie entsprechende Entscheidungen, insbesondere wenn Sie Kafka oder MongoDB innerhalb von OpenShift ausführen.

Für Dienste, die den Zustand beibehalten, verwenden Sie externe Azure-Plattform als Dienst (PaaS)-Angebote, wenn möglich. Dadurch wird die Unterstützung während eines Ausfalls verbessert.

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

OpenShift

Bevor Sie OpenShift installieren, müssen Sie bestimmen, welche Methode Sie verwenden:

• Installationsprogramm bereitgestellte Infrastruktur (IPI). Diese Methode verwendet ein Installationsprogramm, um die OpenShift-Umgebung in Azure bereitzustellen und zu konfigurieren. IPI ist die am häufigsten verwendete Methode für die Bereitstellung in Azure, und Sie sollten IPI verwenden, es sei denn, Ihre Sicherheitsanforderungen sind zu streng, um dies zu tun.

• Benutzerbereitgestellte Infrastruktur (UPI). Diese Methode ermöglicht die präzise Steuerung Ihrer Bereitstellung. UPI erfordert weitere Schritte und Überlegungen zum Erstellen Ihrer Umgebung. Verwenden Sie UPI, wenn IPI Ihre Anforderungen nicht erfüllt. Ein gängiger Einsatzfall für UPI ist die private, air-gapped Installation. Wählen Sie UPI aus, wenn Sie beim Erstellen der Umgebung keinen ausgehenden Internetzugriff haben.

Wir empfehlen die Verwendung von IPI wann immer möglich, da die Arbeit, die zum Abschließen der Installation von OpenShift erforderlich ist, erheblich reduziert wird.

Beim Installieren von OpenShift müssen Sie die folgenden Überlegungen auflösen:

• Regionsauswahl. Es wird empfohlen, eine Region mit Verfügbarkeitszonen zu verwenden. Während der Bereitstellung versucht OpenShift automatisch, zonenübergreifende Knoten auf Grundlage der Konfiguration in der Konfigurationsdatei, install-config.yaml, zu erstellen. Standardmäßig gleicht OpenShift Workloads über alle verfügbaren Knoten und über die Verfügbarkeitszonen hinweg aus. Wenn es einen Ausfall in einer Zone gibt, kann Ihre Lösung weiterhin funktionieren, indem Knoten in anderen Zonen vorhanden sind, die die Arbeit übernehmen können.

• Backup und Wiederherstellung. Sie können die Anweisungen für Azure Red Hat OpenShift für Sicherung und Wiederherstellung verwenden. Weitere Informationen finden Sie unter Erstellen einer Sicherung einer Azure Red Hat OpenShift 4-Clusteranwendung. Wenn Sie diese Methode für die 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 ihnen und dem Internet platzieren, um Datenverkehr an den entsprechenden Cluster umzuleiten, wenn es einen Ausfall einer Region gibt. In einer solchen Situation müssen Sie auch die Status und beständigen Volumes Ihrer Anwendungen migrieren.

Air-gapped-Installationen

In einigen Fällen, z. B. für regulatorische Compliance, benötigen Sie möglicherweise eine Air-gapped-Installation von MAS in Azure. Air gapped bedeutet, dass kein eingehender oder ausgehender Internetzugriff vorhanden ist. Ohne eine Internetverbindung kann Ihre Installation die Installationsabhängigkeiten zur Laufzeit für die Installation von MAS oder OpenShift nicht abrufen.

Es wird nicht empfohlen, eine Air-gapped-Installation durchzuführen, es sei denn, dies ist eine Sicherheitsanforderung. Eine air-gap fügt den Vorgängen Ihrer Lösung eine erhebliche Komplexität hinzu. Aktivitäten wie die Installation von Software, Spiegelungscontainer, Aktualisieren eines Spiegels zum Schutz vor Sicherheitsrisiken und das Verwalten einer Firewall können sehr zeitaufwendig werden.

Weitere Informationen zu Air-gapped-Installationen finden Sie in der folgenden OpenShift-Dokumentation:

• Spiegelung von Images für eine getrennte Installation
• Installieren eines privaten Clusters in Azure

Nachdem Sie OpenShift installiert haben, lesen Sie die MAS-Dokumentation für ähnliche Anleitungen.

Dimensionierung Ihrer Umgebung

Für alle Workloads (außer visuelle Überprüfung) empfehlen wir die Verwendung der neuesten Ds-Serien-VMs als Workerknoten. Beispiele sind die Dsv3, Dasv4, Dsv4, Dasv5 oder Dsv5. Wir empfehlen die Verwendung der neuesten Versionen, wenn möglich, da sie eine bessere Leistung bieten. Verwenden Sie nur VMs mit Storage Premium.

Maximo Visual Inspection erfordert GPU-Knoten zum Ausführen des maschinellen Lernens. Die Lösung verwendet CUDA und unterstützt nur NVIDIA GPUs. Die empfohlenen Typen von VMs sind NCv3 und NCasT4_v3. Wenn Sie mithilfe von YOLOv3 trainieren müssen, benötigen Sie Ampere-basierte GPUs. Verwenden Sie die NVadsA10 v5 oder NC A100 v4 für größere Trainingsaufgaben.

Für die GPU-Computer empfehlen wir, mit dem kleinsten Knoten zu beginnen und zu skalieren, wenn sich Ihre Anforderungen erhöhen.

Für alle anderen Computer empfehlen wir, VMs in Verfügbarkeitszonen zu konfigurieren, um hohe Verfügbarkeit zu unterstützen. Konfigurieren Sie die Knoten wie folgt:

• Steuerelementknoten. Mindestens eine VM pro Verfügbarkeitszone innerhalb der ausgewählten Region. Wir empfehlen eine vCPU-Anzahl von mindestens 4. Unsere Referenz verwendet 3x Standard_D8s_v4 Knoten.

• Workerknoten. Mindestens eine VM pro Verfügbarkeitszone innerhalb der ausgewählten Region. Wir empfehlen eine vCPU-Anzahl von mindestens 8. Unsere Referenz verwendet 6x Standard_D8s_v4 Knoten.

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 bereitstellt, und die Last auf Ihrer Umgebung. Beispielsweise erfordert "Verwalten für 10 Benutzer" weitere 2 vCPUs. Bevor Sie beginnen, empfehlen wir Ihnen, die Systemanforderungen der IBM Maximo Application Suite zu überprüfen, um eine geeignete Schätzung für die Dimensionierung zu erhalten.

Versuchen Sie, die Typen von VMs ähnlich zu halten, um für Nähe mit jedem der Verfügbarkeitszonen zwischen Worker- und Steuerelementknoten zu sorgen. Wenn Sie also eine v4-VM für Ihre Steuerelementknoten verwenden, verwenden Sie auch eine v4-VM für Ihre Workerknoten.

Wenn Sie eine JumpBox benötigen, um die OpenShift-Befehlszeilenschnittstelle (oc) oder MAS zu installieren, stellen Sie eine VM bereit, die Red Hat Enterprise Linux Version 8.4 ausführt.

Netzwerk

Mit OpenShift verwenden wir den standardmäßigen Containernetzwerkschnittstellenanbieter (CNI) von OpenShifts softwaredefiniertem Netzwerk (SDN). Weitere Informationen zum standardmäßigen OpenShift CNI finden Sie unter Cluster-Netzwerkoperator in OpenShift Container Platform. Sie müssen Ihr Netzwerk für die Anzahl der benötigten OpenShift-Steuerelement- und Workerknoten und für alle anderen Anforderungen, z. B. Datenbanken und Speicherkonten, anpassen.

Für eine standardmäßige MAS-Produktionsinstallation empfehlen wir ein virtuelles Netzwerk mit dem Adressraum, den ein CIDR-Präfix (Classless Inter-Domain Routing, klassenloses domänenübergreifendes Routing) von /24 bereitstellt. Das virtuelle Netzwerk verfügt über drei oder vier Subnetze (für Azure Bastion). Für OpenShift weist das Subnetz für die Workerknoten ein CIDR-Präfix von /25 auf, und die Steuerelementknoten weisen ein Präfix von /27 auf. Ein Subnetz für Endpunkte und ein optionaler externer Datenbankserver sollte über ein Präfix von /27 verfügen. Wenn Sie Azure Bastion bereitstellen – das optional ist – benötigen Sie ein Subnetz namens AzureBastionSubnet mit dem Präfix "/26". Weitere Informationen zu den Anforderungen für Azure Bastion finden Sie unter Architektur.

Wenn Sie nur wenige IP-Adressen haben, können Sie eine hoch verfügbare Konfiguration mit einem Mindestpräfix von /27 für das Subnetz von Kontrollknoten und /27 für das Subnetz von Workerknoten implementieren.

Wenn Sie einen anderen CNI verwenden möchten, vergrößern Sie Ihre Netzwerke entsprechend. MAS mit einigen Standardanwendungen stellt über 800 Pods bereit, die wahrscheinlich ein CIDR-Präfix von /21 oder höher erfordern.

Datenbankbesonderheiten

Verschiedene Komponenten von MAS verwenden MongoDB als Metadatenspeicher. Der Standardleitfaden besteht darin, MongoDB Community Edition innerhalb des Clusters bereitzustellen. Wenn Sie sie mithilfe dieser Methode bereitstellen, stellen Sie sicher, dass Sie eine ordnungsgemäße Prozedur zum Sichern und Wiederherstellen der Datenbank eingerichtet haben. Erwägen Sie die Verwendung von MongoDB Atlas in Azure, da es einen externen Speicher, Sicherungen, Skalierung und vieles mehr bereitstellt. Azure unterstützt derzeit keine MongoDB-APIs mit Azure Cosmos DB.

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. Während einer Notfallwiederherstellung gehen Daten innerhalb von Strimzi wahrscheinlich verloren. Wenn Datenverlust innerhalb von Kafka inakzeptabel ist, sollten Sie die Verwendung von Confluent Kafka in Azure in Betracht ziehen. Derzeit werden Azure Event Hubs mit Kafka-Endpunkten nicht unterstützt.

MAS ist mit vielen Datenbanken in seinen Pods gepackt, und diese Datenbanken behalten ihre Zustände im Dateisystem bei, das für MAS bereitgestellt wird. Es wird empfohlen, einen Mechanismus für zonenredundanten Speicher (ZRS) zu verwenden, um die Zustände außerhalb Ihrer Cluster beizubehalten, um Zonenfehler zu absorbieren. Unser empfohlenes Muster besteht darin, Azure File Storage mit den folgenden Konfigurationen zu verwenden:

• Standard: Stellt Server Message Block (SMB)-Freigaben für niedrigere Durchsatz- und ReadWriteOnce (RWO)-Workloads bereit. Standard eignet sich hervorragend für Teile der Anwendung, die nicht häufig in den Speicher geschrieben werden und ein einzelnes persistentes Volume erfordern (z. B. IBM Single-Level Storage).

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

Achten Sie darauf, Richtlinien zum Erzwingen der sicheren Übertragung auf der Azure Blob Storage zu deaktivieren oder die Konten von diesen Richtlinien auszunehmen. Azure Premium-Dateien mit NFS erfordern, dass die sichere Übertragung deaktiviert wird. Stellen Sie sicher, dass Sie einen privaten Endpunkt verwenden, um eine private Verbindung mit Ihren Freigaben zu gewährleisten.

Standardmäßig stellt Db2 Warehouse über OpenShift Data Foundation (zuvor als OpenShift Container Storage bezeichnet) bereit. Aus Gründen der Kosten, Leistung, Skalierung und Zuverlässigkeit empfehlen wir die Verwendung von Azure Premium-Dateien mit NFS anstelle von OpenShift Data Foundation.

Verwenden Sie Azure Blob Storage nicht mit CSI-Treibern, da keine festen Links unterstützt werden, die erforderlich sind. Einige Pods können nicht ohne feste Links ausgeführt werden.

Überlegungen

Diese Überlegungen bilden die Säulen des Azure Well-Architected Framework, einer Reihe von Leitprinzipien, die Sie zur Verbesserung der Qualität eines Workloads verwenden können. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

Die Verwaltung des Zugriffs und der Sichtbarkeit im Wartungslebenszyklus Ihrer Ressourcen kann eine der größten Möglichkeiten Ihrer Organisation sein, effizient zu arbeiten und Zeit zu verwalten. 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.

Azure liefert MAS mithilfe der Modelle der Infrastruktur-as-a-Service (IaaS) und PaaS. Auf den folgenden Ebenen wurden Sicherheitsmaßnahmen von Microsoft in den Dienst integriert:

• Physisches Rechenzentrum
• Physisches Netzwerk
• Physischer Host
• Hypervisor

Bewerten Sie sorgfältig die Dienste und Technologien, die Sie für die Bereiche oberhalb des Hypervisors auswählen, z. B. die neueste gepatchte Version von OpenShift für eine Hauptversion. Seien Sie sicher, dass Sie die richtigen Sicherheitskontrollen für Ihre Architektur einsetzen. Sie sind für das Patchen und Verwalten der Sicherheit der IaaS-Systeme verantwortlich. Microsoft übernimmt diese Rolle für die PaaS-Dienste.

Nutzen Sie Netzwerksicherheitsgruppen, um Netzwerkdatenverkehr von und zu Ressourcen in Ihrem virtuellen Netzwerk zu filtern. Mit diesen Gruppen können Sie Regeln definieren, auf deren Grundlage der Zugriff auf Ihre MAS-Dienste gewährt oder verweigert wird. Beispiele:

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

Wenn Sie aus irgendeinem Grund Zugriff auf Ihre VMs benötigen, können Sie eine Verbindung über Ihre Hybridkonnektivität oder über die OpenShift-Administratorkonsole herstellen. Wenn Sie über eine Onlinebereitstellung verfügen oder sich nicht auf die Konnektivität verlassen möchten, können Sie auch über Azure Bastion (optional) auf Ihre VMs zugreifen. Aus Sicherheitsgründen sollten Sie VMs nicht für ein Netzwerk oder Internet verfügbar machen, ohne Netzwerksicherheitsgruppen zu konfigurieren, um den Zugriff auf diese zu steuern.

Die serverseitige Verschlüsselung (Server-Side Encryption, SSE) von Azure Disk Storage schützt Ihre Daten. Die Funktion unterstützt Sie ebenfalls bei der Erfüllung der Sicherheits- und Complianceverpflichtungen Ihrer Organisation. Bei verwalteten Azure-Datenträgern verschlüsselt SSE die ruhenden Daten, wenn diese in der Cloud gespeichert werden. Dieses Verhalten gilt standardmäßig für Betriebssystem- und andere Datenträger. OpenShift verwendet standardmäßig SSE.

Authentifizierung

MAS unterstützt derzeit einmaliges Anmelden (Single Sign-On, SSO) mit Security Assertion Markup Language (SAML) in Microsoft Entra ID. Diese Authentifizierungsmethode erfordert eine Unternehmensanwendung in Microsoft Entra ID und Berechtigungen zum Ändern der Anwendung. Weitere Informationen finden Sie unter Integration des einmaligen Anmeldens von Microsoft Entra mit Maximo Application Suite.

Bevor Sie die SAML-basierte Authentifizierung einrichten, empfehlen wir, die IBM-Konfiguration und die Azure-Konfiguration zu durchlaufen. Weitere Informationen zu SAML mit MAS finden Sie in der Dokumentation zu MAS. Informationen zu SAML mit Azure finden Sie im Schnellstart: Aktivieren des einmaligen Anmeldens für eine Unternehmensanwendung.

Sie sollten auch OAuth (Open Authorization) für OpenShift konfigurieren. Weitere Informationen finden Sie unter Übersicht über Authentifizierung und Autorisierung in der OpenShift-Dokumentation.

Schützen Ihrer Infrastruktur

Kontrollieren Sie den Zugriff auf die von Ihnen bereitgestellten Azure-Ressourcen. Jedes Azure-Abonnement verfügt über eine Vertrauensbeziehung zu einem Microsoft Entra-Mandanten. Verwenden Sie die rollenbasierte Zugriffssteuerung in Azure (Role-Based Access Control, RBAC), um Benutzern in Ihrer Organisation die richtigen Berechtigungen für Azure-Ressourcen zu gewähren. Gewähren Sie Zugriff, indem Sie Benutzern oder Gruppen die entsprechenden Azure-Rollen für einen bestimmten Bereich zuweisen. Bei dem Bereich kann es sich um ein Abonnement, eine Ressourcengruppe oder eine einzelne Ressource handeln. Seien Sie sicher, dass Sie alle Änderungen an der Infrastruktur überwachen. Weitere Informationen zur Überwachung finden Sie im Azure Monitor-Aktivitätsprotokoll.

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

Eine Standardbereitstellung von MAS besteht aus den folgenden Komponenten:

• 3 Steuerelement-VMs
• 6 Worker-VMs
• 3 Worker-VMs für Db2 Warehouse
  • Sie können SQL Server auf Azure-VMs in einigen Konfigurationen ersetzen, anstatt Db2 Warehouse zu verwenden.
• 2 Azure Storage-Konten
• 2 DNS-Zonen
• 2 Lastenausgleichsmodule
• Azure Bastion
• 1 VM zur visuellen Prüfung
  • Dies ist nicht erforderlich, es sei denn, Sie planen, die visuelle Prüfung innerhalb von MAS auszuführen.

Sie können eine Beispielschätzung mithilfe unseres Kostenrechners prüfen. Konfigurationen variieren, und Sie sollten Ihre Konfiguration mit Ihrem IBM-Dimensionierungteam überprüfen, bevor Sie Ihre Bereitstellung abschließen.

Zuverlässigkeit

OpenShift verfügt über integrierte Funktionen für Selbstheilung, Skalierung und Resilienz, um sicherzustellen, dass OpenShift und MAS erfolgreich funktionieren. OpenShift und MAS wurden für Teile entwickelt, die fehlschlagen und wiederherstellen. Eine wichtige Voraussetzung für die Selbstheilung ist, dass genügend Workerknoten vorhanden sind. Um einen Zonenfehler innerhalb einer Azure-Region wiederherzustellen, müssen Ihre Steuerungs- und Workerknoten ü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 während eines Fehlers weiterhin funktionieren, sollten Sie möglichst zonenredundanten Speicher verwenden. Dieser Speichertyp bleibt verfügbar, wenn eine Zone fehlschlägt.

Da der menschliche Fehler üblich ist, sollten Sie MAS mithilfe so viel Automatisierung wie möglich bereitstellen. In unserem Schnellstarthandbuch stellen wir einige Beispielskripts zum Einrichten vollständiger End-to-End-Automatisierung bereit.

Bereitstellen dieses Szenarios

Bevor Sie beginnen, empfehlen wir Ihnen, die Systemanforderungen der IBM Maximo Application Suite zu überprüfen. Stellen Sie sicher, dass Sie über die folgenden Ressourcen verfügen, bevor Sie die Bereitstellung starten:

• Zugriff auf ein Azure-Abonnement mit Leseberechtigung
• Anwendungsregistrierung oder Dienstprinzipalname, der über Berechtigungen für Mitwirkende und Benutzerzugriffsadministratoren für das Abonnement verfügt
• Domäne oder delegierte Unterdomäne an eine Azure DNS-Zone
• Abrufen eines geheimen Schlüssels von Red Hat zum Bereitstellen von OpenShift
• MAS-Berechtigungsschlüssel
• MAS-Lizenzdatei (erstellt nach der MAS-Installation)
• IBM-empfohlene Clusteranpassung
• Vorhandenes virtuelles Netzwerk oder ein neues virtuelles Netzwerk, das von IPI erstellt wurde – je nach Ihren Anforderungen
• Hohe Verfügbarkeits- und Notfallwiederherstellungsanforderungen für Ihre spezifische Bereitstellung
• Konfigurationsdatei, install-config.yaml, für das Installationsprogramm

Eine schrittweise Anleitung zum Installieren von OpenShift und MAS in Azure finden Sie in unserem Schnellstarthandbuch auf GitHub.

Überlegungen zur Bereitstellung

Es ist am besten, Workloads mithilfe der Infrastruktur als Code (IaC) bereitzustellen, anstatt Workloads manuell bereitzustellen, da die manuelle Bereitstellung zu einer Fehlkonfiguration führen kann. Containerbasierte Workloads können bei falscher Konfiguration vertraulich sein, wodurch die Produktivität verringert werden kann.

Bevor Sie Ihre Umgebung erstellen, lesen Sie das Schnellstarthandbuch, um ein Verständnis der Entwurfsparameter zu entwickeln. Das Schnellstarthandbuch ist nicht für eine produktionsbereite Bereitstellung vorgesehen, Sie können jedoch die Ressourcen des Handbuchs verwenden, um zu einem Produktionsmechanismus für die Bereitstellung zu gelangen.

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

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

• David Baumgarten | Senior Cloud Solution Architect
• Roeland Nieuwenhuis | Principal Cloud Solution Architect

Andere Mitwirkende:

• Gary Moore | Programmierer/Autor

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

Hilfe für die ersten Schritte finden Sie in den folgenden Artikeln:

• Installieren von OpenShift auf Azure
• Schnellstarthandbuch: Maximo Application Suite in Azure
• OpenShift UPI Handbuch
• Anforderungen für Maximo
• IBM Maximo Application Suite (BYOL)

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

• IBM Passport Advantage
• Einführung in Azure DNS
• Einführung in Azure NetApp Files
• Einführung in Red Hat in Azure
• Red Hat Kundenportal

Zugehörige Ressourcen

• Azure Enterprise Cloud-Dateifreigabe
• Einführung in Predictive Maintenance in der Fertigung
• Bereitstellen einer Java-Anwendung mit JBoss EAP (Enterprise Application Platform) auf einem ARO-Cluster