Bearbeiten

Bereitstellen von IBM Maximo Application Suite in Azure

Azure Files
Azure Load Balancer
Azure Red Hat OpenShift
Azure Virtual Machines
Azure Virtual Network

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

Architekturdiagramm, das die Komponenten und Dienste zeigt, die die Bereitstellung der IBM Maximo Application Suite in Azure unterstützen.

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
  • Azure Premium-Dateien und Standarddateien für den Speicher (OpenShift Data Foundation ist 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 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 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, um sicher auf einen der Workerknoten oder optionalen JumpBox-Computer zuzugreifen. Azure Bastion ist ein vollständig verwalteter Dienst, der sicheren und nahtlosen RDP- und SSH-Zugriff auf VMs ohne Gefährdung über öffentliche IP-Adressen bietet.

  • SQL Server auf Azure Virtual Machines (optional) SQL Server auf Azure Virtual Machines (VMs) 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:

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 an Ihr IBM-Team für produktspezifische Fragen. 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 (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:

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 Informationen zum Verbinden von Oracle Cloud mit Microsoft Azure. Derzeit werden Azure SQL-Datenbank, Azure SQL Managed Instance und Azure Cosmos DB nicht unterstützt.

Hinweis

In einigen Fällen können Sie eine Datenbank für mehrere MAS-Anwendungen aufgrund von widersprüchlichen Datenbankeinstellungen nicht wiederverwenden. Sie können beispielsweise nicht das gleiche IBM Db2 Warehouse für Integrität und Verwaltung in Kombination mit Monitor verwenden. Sie können jedoch verschiedene Datenbankprodukte kombinieren, z. B. die Verwendung von SQL Server für eine Anwendung und IBM Db2 Warehouse für eine andere.

Weitere Informationen zu Datenbankanforderungen für die Integritätsanwendung finden Sie unter Konfigurieren der Datenbank für Maximo Health.

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

Hinweis

IBM Maximo Application Suite unterstützt Azure Red Hat OpenShift, sofern die zugrunde liegenden Versionen von OpenShift und Cloud Pak for Data (CP4D) ausgerichtet sind.

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.

Hinweis

Nachdem Sie OpenShift installiert haben, ist der Besitzer der Steuerelementebene verantwortlich für die Wartung und Skalierung der Workerknoten in Azure. Sie erhöhen die Clustergröße mithilfe von Computersätzen in der Administratorkonsole, nicht über das Azure-Portal. Weitere Informationen finden Sie unter Erstellen eines Computersatzes in Azure.

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.

Hinweis

Air-gapped-Bereitstellungen erfordern UPI für die Installation. Sie wurden jedoch nicht vollständig getestet.

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:

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.

Warnung

Wenn Sie GPU-Computer benötigen, benötigen Sie OpenShift 4.8.22 als Mindestversion, um die GPUs über den NVIDIA GPU-Operator zu aktivieren.

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 von /24 bereitstellt. Das virtuelle Netzwerk verfügt über drei oder vier Subnetze (für 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 zonenredundanten Speichermechanismus 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 nicht mit CSI-Treibern, da es keine festen Links unterstützt, 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 sämtliche Daten zu schützen, die Sie in Ihre Architektur bzw. aus Ihrer Architektur verschieben.

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

Microsoft Audio Stack (MAS) unterstützt derzeit die Verwendung von Security Assertion Markup Language (SAML) über Microsoft Entra ID. Damit dies funktioniert, benötigen Sie eine Unternehmensanwendung in Microsoft Entra ID und entweder die Berechtigung zum Ändern der Anwendung oder die Unterstützung durch ein Mitglied der Rolle „Globaler Administrator“, das die erforderlichen Änderungen vornehmen kann.

Das Schnellstarthandbuch auf GitHub enthält ein Lernprogramm zum Einrichten von SAML mit MAS. Weitere Informationen finden Sie unter Enabling SAML authentication against Microsoft Entra ID (Aktivieren der SAML-Authentifizierung für Microsoft Entra ID).

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 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 von Azure (Azure Role-Based Access Control, Azure 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.

Hinweis

Schnellstarthandbuch: Maximo Application Suite in Azure enthält ein Beispiel für eine install-config.yaml-Datei in /src/ocp/.

Ü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:

Andere Mitwirkende:

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:

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