Freigeben über

Migrieren von WebSphere-Anwendungen zu Azure Virtual Machines

  • Artikel

Diese Anleitung beschreibt, was Sie beachten sollten, wenn Sie eine vorhandene traditionelle WebSphere Application Server (WAS) Anwendung migrieren möchten, um sie auf Azure Virtual Machines auszuführen. Einen Überblick über die verfügbaren traditionellen WAS-Lösungen im Azure Marketplace finden Sie unter Welche Lösungen gibt es, um die IBM WebSphere-Produktfamilie auf Azure auszuführen?

Vor der Migration

Führen Sie vor Beginn einer Migration die in den folgenden Abschnitten beschriebenen Schritte zur Bewertung und Bestandsermittlung aus, um eine erfolgreiche Migration zu gewährleisten.

Definieren der Bedeutung von „Migration abgeschlossen“

Diese Anleitung und die entsprechenden Angebote im Azure Marketplace sind ein Ausgangspunkt, um die Migration Ihrer traditionellen WAS Workloads zu Azure zu beschleunigen. Es ist wichtig, den Umfang Ihres Migrationsablaufs zu definieren. Führen Sie beispielsweise einen strikten „Lift & Shift“-Vorgang aus Ihrer vorhandenen Infrastruktur auf Azure Virtual Machines durch? Wenn ja, kann es verlockend sein, während der Migration auch nach dem Motto „Lift & Improve“ vorzugehen.

Es ist aber besser, möglichst nah am „Lift & Shift“-Ansatz zu bleiben und die erforderlichen Änderungen vorzunehmen, die in diesem Leitfaden beschrieben werden. Definieren Sie, was genau mit „Migration abgeschlossen“ gemeint ist, damit Sie wissen, wann dieser Meilenstein erreicht ist. Wenn Sie das Ziel „Migration abgeschlossen“ erreicht haben, können Sie einen Snapshot Ihrer virtuellen Maschinen erstellen, wie in Erstellen eines Snapshots einer virtuellen Festplatte beschrieben. Nachdem Sie sich vergewissert haben, dass Sie von Ihrem Snapshot aus erfolgreich wiederherstellen können, können Sie die Verbesserungen vornehmen, ohne befürchten zu müssen, dass der bis dahin erzielte Migrationsfortschritt verloren geht.

Stellen Sie sicher, dass das Ziel das richtige Ziel für Ihre Migration ist

Der erste Schritt für eine erfolgreiche Migration einer WAS-Anwendung zu Azure ist die Auswahl des am besten geeigneten Ziels für die Migration.

WAS lässt sich traditionell gut auf Azure Virtual Machines ausführen. Das Ziel der virtuellen Maschine (VM) ist die einfachste Wahl, da es einer on-premises Bereitstellung am nächsten kommt. Die Verwaltung und Bereitstellung virtueller Maschinen erfolgt analog zu der on-premises.

Eine weitere Möglichkeit ist die Migration zu Containern, indem Sie WAS traditionelles Workload in Anwendungscontainer umwandeln. Sie können das Container-Ziel auf Azure Kubernetes Service (AKS) und Azure Red Hat OpenShift ausführen. Der Kompromiss für diese Erleichterung sind die wirtschaftlichen Kosten.

Allgemein gesprochen sind die Kosten pro Minute bei einer VM-basierten Lösung höher als bei Containern. Eine Container-basierte Lösung ist zwar kostengünstiger auszuführen, aber Sie müssen Ihre Anwendung so einschränken, dass sie in die Anforderungen der Plattform für die Orchestrierung von Containern passt.

Wenn die Minimierung von Änderungen der wichtigste Faktor für Ihre Migrationsbemühungen ist, sollten Sie eine VM-basierte Migration in Betracht ziehen. In diesem Fall siehe Migration von WebSphere-Anwendungen zu Azure Virtual Machines.

Wenn Sie es tolerieren können, dass Ihre Anwendung in Containern ausgeführt wird, um die Laufzeitkosten zu senken, ziehen Sie eine AKS-basierte oder Azure Red Hat OpenShift-basierte Migration in Betracht.

Für die AKS-basierte Migration können Sie mit dem kostenlosen Tier beginnen. Sie erhalten kostenloses Cluster-Management und zahlen nur für die virtuellen Maschinen, den zugehörigen Storage und die verbrauchten Networking-Ressourcen. In diesem Fall siehe Migrieren Sie WebSphere Anwendungen zu Azure Kubernetes Service.

Bei der auf Red Hat OpenShift basierenden Migration zu Azure fallen für Anwendungsknoten zusätzlich zu den Datenverarbeitungskosten und den Infrastrukturkosten weitere Kosten für die OpenShift-Lizenzkomponente an. Diese Kosten werden auf der Grundlage der Anzahl der Anwendungsknoten und des Instanztyps berechnet. Nutzen Sie On-demand-Preise oder reservierte Instanzen, je nachdem, was den Anforderungen Ihres Workloads und Ihres Unternehmens am besten entspricht. In diesem Fall siehe Websphere-Anwendungen auf Azure Red Hat OpenShift migrieren.

Die Anleitungen in der Azure Red Hat OpenShift-Dokumentation decken einige Aspekte ab, die für die Migration relevant sind. Die vollständige Liste der Anleitungen finden Sie in der Azure Red Hat OpenShift-Dokumentation.

Ermitteln, ob die vordefinierten Azure Marketplace-Angebote ein guter Ausgangspunkt sind

IBM und Microsoft haben gemeinsam eine Reihe von Azure-Lösungsvorlagen für den Azure Marketplace definiert, um einen soliden Ausgangspunkt für die Migration zu Azure zu schaffen. Die Liste der Angebote finden Sie unter Ausführen der WebSphere-Produktfamilie und Liberty auf Microsoft Azure. Wählen Sie dann das Angebot aus, das Ihrer bestehenden Bereitstellung am ehesten entspricht. Die Liste der Angebote finden Sie in dem Übersichtsartikel Welche Lösungen gibt es, um die IBM WebSphere-Produktfamilie auf Azure auszuführen?

Wenn keines der vorhandenen Angebote ein guter Ausgangspunkt ist, müssen Sie die Bereitstellung von Hand mit den Ressourcen von Azure Virtual Machine reproduzieren. Eine Schritt-für-Schritt-Anleitung finden Sie in Tutorial: IBM WebSphere Application Server Network Deployment traditionell auf Azure Virtual Machines manuell installieren. Weitere Informationen finden Sie unter Was ist IaaS?

Stellen Sie fest, ob die traditionelle Version von WAS kompatibel ist

Ihre vorhandene traditionelle WAS-Version muss mit der Version im IaaS-Angebot kompatibel sein. Sie finden die Versionsinformationen auf der Übersichtsseite von IBM WebSphere Application Server Single Instance auf Azure VM und IBM WebSphere Application Server Cluster auf Azure VMs. Wenn Ihre vorhandene traditionelle WAS-Version nicht mit dieser Version kompatibel ist, müssen Sie die Bereitstellung von Hand mit Azure IaaS-Ressourcen reproduzieren. Weitere Informationen finden Sie unter Was ist IaaS?

Inventarisieren der Serverkapazität

Dokumentieren Sie die Hardware (Arbeitsspeicher, CPU, Datenträger) der aktuellen Produktionsserver sowie die durchschnittliche und maximale Anzahl von Anforderungen und die Ressourcennutzung. Diese Informationen beeinflussen die VM-Größe. Weitere Informationen finden Sie unter Größen für Clouddienste.

Bestand: Alle Geheimnisse

Vor der Einführung von „Configuration-as-a-Service“-Technologien, z. B. Azure Key Vault, gab es kein gut definiertes Konzept für „Geheimnisse“. Stattdessen haben Sie über viele unterschiedliche Konfigurationseinstellungen verfügt, die quasi als die nun verwendeten „Geheimnisse“ gedient haben. Bei App-Servern wie z. B. WAS befinden sich diese Secrets in vielen verschiedenen Konfigurationsdateien und Stores. Überprüfen Sie alle Eigenschaften und Konfigurationsdateien auf den Produktionsservern auf Geheimnisse und Kennwörter. Unter Umständen finden Sie in Ihrer Anwendung auch Konfigurationsdateien mit Kennwörtern oder Anmeldeinformationen. WAS speichert die Konfigurationsdaten in mehreren Dokumenten in einer kaskadierenden Hierarchie von Verzeichnissen. Die meisten Konfigurationsdokumente haben XML-Inhalte. Weitere Informationen finden Sie unter Konfigurationsdokumente und Azure Key Vault-Grundkonzepte.

Inventarisieren aller Zertifikate

Dokumentieren Sie alle Zertifikate, die für öffentliche SSL-Endpunkte verwendet werden. Sie können alle Zertifikate auf den Produktionsservern anzeigen, indem Sie den folgenden Befehl ausführen:

keytool -list -v -keystore <path to keystore>

Weitere Informationen finden Sie unter dem IBM Dokument Zertifikatsverwaltung in SSL

Überprüfen, ob die unterstützte Java-Version richtig funktioniert

Die Verwendung von WAS auf Azure Virtual Machines erfordert eine bestimmte Java-Version. Sie müssen also sicherstellen, dass Ihre Anwendung mit dieser unterstützten Version korrekt ausgeführt wird.

IBM Java 8 wird mit der WAS9-Distribution geliefert. Wir empfehlen die Verwendung der von IBM bereitgestellten Java JRE. Weitere Informationen finden Sie unter Java SE 8 in WebSphere Application Server traditional V9.

Wenn Sie zu einem anderen Java-SDK wechseln möchten, folgen Sie dem IBM Dokument Switching the Java SDK in WebSphere Application Server.

Bestand: JNDI-Ressourcen

Inventarisieren Sie alle JNDI-Ressourcen. Datenquellen, z. B. Datenbanken, können beispielsweise über einen zugeordneten JNDI-Namen verfügen, mit dem Instanzen von EntityManager von JPA korrekt an eine bestimmte Datenbank gebunden werden können. Weitere Informationen zu JNDI-Ressourcen und Datenbanken finden Sie unter WebSphere Data Sources in der IBM-Dokumentation. Für andere JNDI-bezogene Ressourcen, z. B. JMS-Nachrichtenbroker, ist ggf. eine Migration oder Neukonfiguration erforderlich. Weitere Informationen zur JMS-Konfiguration finden Sie unter Verwendung von JMS-Ressourcen.

Profilkonfiguration überprüfen

Die wichtigste Konfigurationseinheit in WAS ist das Profil. Als solches enthält die Datei resources.xml eine Fülle von Konfigurationen, die Sie bei der Migration sorgfältig berücksichtigen müssen. Die Datei enthält Verweise auf weitere XML-Dateien, die in Unterverzeichnissen gespeichert sind. IBM rät, dass Sie normalerweise die IBM Console verwenden sollten, um die verwaltbaren Objekte und Dienste von WAS zu konfigurieren und WAS die Möglichkeit zu bieten, den Ordner profile/profile-name zu verwalten. Weitere Informationen finden Sie unter Verwaltung von Profilen auf verteilten und IBM i-Betriebssystemen.

Innerhalb Ihrer Anwendung

Überprüfen Sie die Datei deployment.xml und/oder die Datei WEB-INF/web.xml.

Ermitteln, ob die Sitzungsreplikation verwendet wird

Wenn Ihre Anwendung auf die Replikation von Sitzungen angewiesen ist, haben Sie folgende Möglichkeiten:

  • Für HTTP-Sitzungen können Sie, je nach Ebene der Sitzungsverwaltung, Sitzungsdaten im Speicher oder in einer Datenbank sammeln.
  • Für Verteilte Sitzungen können Sie die Sitzungen in einer Datenbank speichern, indem Sie die Sitzungspersistenz der Datenbank verwenden.
  • Für Dynamischer Cache können Sie Sitzungsdaten in einer Replikation von Speicher zu Speicher oder in einer Datenbank verwalten.
  • Gestalten Sie Ihre Anwendung so um, dass eine Datenbank für die Sitzungsverwaltung verwendet wird.
  • Gestalten Sie Ihre Anwendung so um, dass die Sitzung für den Azure Redis-Dienst externalisiert wird. Weitere Informationen finden Sie unter Azure Cache for Redis.

Für alle diese Optionen sollten Sie wissen, wie WAS die Replikation des HTTP-Sitzungsstatus durchführt. Weitere Informationen finden Sie unter Verwaltung von Session Beans in der IBM-Dokumentation.

Dokumentdatenquellen

Verwendet Ihre Anwendung Datenbanken, müssen Sie die folgenden Informationen erfassen:

  • Wie lautet der Name der Datenquelle?
  • Wie ist der Verbindungspool konfiguriert?
  • Wo ist die JAR-Datei mit den JDBC-Treibern zu finden?

Weitere Informationen über JDBC-Treiber in WAS finden Sie unter Verwendung von JDBC-Treibern mit WebSphere Application Server.

Ermitteln, ob WAS angepasst wurde

Ermitteln Sie, welche der folgenden Anpassungen vorgenommen wurden, und erfassen Sie sie.

  • Wurden die Startskripts geändert? Zu diesen Skripten gehören wsadmin, AdminControl, AdminConfig, AdminApp und AdminTask.
  • Werden an JVM spezifische Parameter übergeben?
  • Werden dem Klassenpfad des Servers JAR-Dateien hinzugefügt?
  • Wurden Einrichtungen auf Betriebssystemlevel wie z. B. systemd verwendet, damit WAS-Komponenten nach einem Server-Neustart automatisch gestartet werden?

Abhängig von den Antworten auf diese Fragen müssen Sie Migrationsüberlegungen anstellen.

Ermitteln, ob eine Verbindung mit der lokalen Umgebung erforderlich ist

Wenn Ihre Anwendung auf Ihre lokalen Dienste zugreifen muss, müssen Sie einen der Konnektivitätsdienste von Azure bereitstellen. Weitere Informationen finden Sie unter Herstellen einer Verbindung zwischen einem lokalen Netzwerk und Azure. Alternativ müssen Sie Ihre Anwendung so umgestalten, dass öffentlich zugängliche APIs genutzt werden, die von Ihren lokalen Ressourcen verfügbar gemacht werden.

Ermitteln, ob JMS-Warteschlangen oder -Themen (Java Message Service) verwendet werden

Wenn Ihre Anwendung JMS-Warteschlangen oder Topics verwendet, müssen Sie diese auf einen extern gehosteten JMS-Server migrieren. Eine Strategie für diejenigen, die JMS verwenden, ist die Verwendung von Azure Service Bus und dem Advanced Message Queuing Protocol. Weitere Informationen finden Sie unter Verwenden von Java Message Service 1.1 mit Azure Service Bus Standard und AMQP 1.0.

Wenn Sie persistente JMS Stores konfiguriert haben, müssen Sie deren Konfiguration erfassen und nach der Migration anwenden.

Wenn Sie IBM MQ verwenden, können Sie diese Software zu Azure Virtual Machines migrieren und sie so verwenden, wie sie ist.

Microsoft bietet eine Lösung zur Integration von IBM MQ mit Logic Apps. Weitere Informationen finden Sie unter Herstellen einer Verbindung mit einem IBM MQ-Server über einen Workflow in Azure Logic Apps.

Ermitteln Sie, ob Sie eigene benutzerdefinierte freigegebene Java EE-Bibliotheken verwenden

Wenn Sie das Features für freigegebene Java EE-Bibliotheken verwenden, haben Sie zwei Optionen:

  • Gestalten Sie Ihren Anwendungscode um, um alle Abhängigkeiten von Ihren Bibliotheken zu entfernen, und integrieren Sie die Funktionalität stattdessen direkt in Ihre Anwendung.
  • Fügen Sie die Bibliotheken zum Serverklassenpfad hinzu.

Ermitteln, ob OSGi-Pakete verwendet werden

Wenn Sie OSGi-Bundles verwendet haben, die dem WAS hinzugefügt wurden, müssen Sie die entsprechenden JAR-Dateien direkt zu Ihrer Webanwendung hinzufügen.

Ermitteln, ob Ihre Anwendung betriebssystemspezifischen Code enthält

Wenn Ihre Anwendung Code mit Abhängigkeiten vom Hostbetriebssystem enthält, müssen Sie ihn umgestalten, um diese Abhängigkeiten zu beseitigen. Beispielsweise müssen Sie möglicherweise die Verwendung von / oder \ in Dateisystempfaden durch File.Separator oder Paths.get ersetzen, wenn Ihre Anwendung unter Windows ausgeführt wird.

Stellen Sie fest, ob IBM Integration Bus verwendet wird

Wenn Ihre Anwendung IBM Integration Bus verwendet, müssen Sie erfassen, wie IBM Integration Bus konfiguriert ist. Weitere Informationen finden Sie unter IBM Integration Bus-Dokumentation.

Ermitteln, ob Ihre Anwendung aus mehreren WAR-Dateien besteht

Besteht Ihre Anwendung aus mehreren WAR-Dateien, sollten Sie die einzelnen WAR-Dateien als separate Anwendungen behandeln und für jede Datei diese Anleitung ausführen.

Ermitteln, ob Ihre Anwendung als EAR-Datei gepackt ist

Wenn Ihre Anwendung als EAR-Datei gepackt ist, sollten Sie die Dateien application.xml, ibm-application-bnd.xmi und ibm-application-ext.xmi untersuchen und deren Konfigurationen erfassen. Weitere Informationen finden Sie unter Erstellung des Enterprise Archive (EAR)-Pakets auf WebSphere.

Ermitteln aller externen Prozesse und Daemons, die auf den Produktionsservern ausgeführt werden

Werden einige Ihrer Prozesse außerhalb des Anwendungsservers ausgeführt (z. B. die Überwachung von Daemons), müssen Sie sie beseitigen oder zu einem anderen Ort migrieren.

Ermitteln, ob und wie das Dateisystem verwendet wird

VM-Dateisysteme funktionieren in Bezug auf die Persistenz und das Starten und Herunterfahren genauso wie lokale Dateisysteme. Trotzdem ist es wichtig, dass Sie die Anforderungen Ihres Dateisystems kennen und sicherstellen, dass die virtuellen Computer über eine geeignete Speichergröße und Leistung verfügen.

Schreibgeschützter statischer Inhalt

Falls mit Ihrer Anwendung derzeit statischer Inhalt bereitgestellt wird, benötigen Sie dafür einen anderen Speicherort. Sie können beispielsweise erwägen, statischen Inhalt in Azure Blob Storage zu verschieben und Azure CDN hinzuzufügen, um global eine sehr hohe Downloadgeschwindigkeit zu erzielen. Weitere Informationen finden Sie unter Hosten von statischen Websites in Azure StorageundSchnellstart: Integrieren eines Azure-Speicherkontos in Azure CDN.

Dynamisch veröffentlichter statischer Inhalt

Wenn Ihre Anwendung statischen Inhalt zulässt, der von Ihrer Anwendung hochgeladen bzw. produziert wird, nach der Erstellung aber unveränderlich ist, können Sie Azure Blob Storage und Azure CDN wie oben beschrieben nutzen. Hierbei können Sie auch eine Azure-Funktion zum Verarbeiten von Uploads und der CDN-Aktualisierung verwenden. Eine entsprechende Beispielimplementierung finden Sie unter Hochladen und CDN-Vorabladen von statischem Inhalt mit Azure Functions.

Ermitteln der Netzwerktopologie

Das aktuelle Angebot auf dem Azure Marketplace ist ein Ausgangspunkt für Ihre Migration. Wenn das Angebot die Aspekte Ihrer Architektur, die Sie migrieren müssen, nicht abdeckt, müssen Sie die Netzwerktopologie Ihrer bestehenden Bereitstellung erfassen. Anschließend müssen Sie diese Netzwerktopologie in Azure reproduzieren, auch wenn Sie das Basisangebot mit einer der Lösungsvorlagen aufgesetzt haben.

Die Netzwerktopologie ist ein umfangreiches Thema, aber die folgenden Referenzen können Ihnen bei Ihren Migrationsbemühungen eine gewisse Richtung geben:

Konto für die Verwendung von JCA-Adaptern und Ressourcenadaptern

Wenn Ihre bestehende Anwendung JCA-Adapter oder andere Ressourcen-Adapter verwendet, um sich mit anderen Unternehmenssystemen zu verbinden, stellen Sie sicher, dass Sie die Konfiguration für diese Artefakte auf den WAS anwenden, der in virtuellen Maschinen von Azure ausgeführt wird. Weitere Informationen finden Sie unter Relationale Ressourcenadapter und JCA in der IBM Dokumentation.

Konto für Authentifizierung und Autorisierung

Die meisten Anwendungen verfügen über eine Art von Authentifizierung und Autorisierung. Wenn Sie OpenID zur Authentifizierung verwenden, können Sie die OpenID Connect Authentifizierung mit Microsoft Entra ID konfigurieren. Weitere Informationen finden Sie unter OpenID Connect-Authentifizierung mit Microsoft Entra ID.

Feststellen, ob WAS-Cluster verwendet werden

Höchstwahrscheinlich haben Sie Ihre Anwendung auf mehreren WAS-Servern bereitgestellt, um eine hohe Hochverfügbarkeit zu erreichen. Sie können diese Cluster direkt von Ihrer on-premises Installation zu WAS migrieren, das auf Azure Virtual Machines ausgeführt wird. Weitere Informationen finden Sie unter WebSphere Application Server Network Deployment in der IBM-Dokumentation.

Konto für Lastenausgleichsanforderungen

Load-Balancing ist ein wesentliches Element bei der Migration Ihres WAS-Clusters zu Azure. Die einfachste Lösung ist die Nutzung des integrierten Supports für Azure Application Gateway oder IBM HTTP Server, der im Azure Marketplace für IBM WebSphere Application Server-Cluster angeboten wird.

Eine Zusammenfassung der Funktionalitäten von Azure Application Gateway im Vergleich zu anderen Azure Load-Balancing-Lösungen finden Sie unter Load-Balancing-Optionen.

Ermitteln, ob die Java EE-Anwendungsclientfunktion verwendet wird

Verwendet Ihre Anwendung die Java EE-Anwendungsclientfunktion, sollten Sie sie nach der Migration zu Azure Virtual Machines weiterhin unverändert verwenden können. Weitere Informationen finden Sie unter Verwenden von Java EE-Clientanwendungsmodulen.

Migration

Wählen Sie ein Angebot für den traditionellen WAS auf Azure Virtual Machines

Die folgenden Angebote sind für WAS auf Azure Virtual Machines verfügbar.

Während der Bereitstellung eines Angebots werden Sie aufgefordert, die Größe der virtuellen Maschinen für Ihre WAS Knoten auszuwählen. Es ist wichtig, bei der Auswahl der VM-Größe alle Größenaspekte (Arbeitsspeicher, Prozessor, Datenträger) zu berücksichtigen. Weitere Informationen finden Sie unter Größen für Clouddienste (klassisch).

  • Einzelne IBM WebSphere Application Server-Instanz auf Azure VM

    Dieses Angebot automatisiert die meisten Standardschritte zur Bereitstellung einer einzelnen WebSphere Instanz auf einer Azure Virtual Machine. Es erstellt ein Anwendungsserverprofil mit der WAS-Admin-Konsole.

  • IBM WebSphere Application Server-Cluster auf Azure VMs

    Dieses Angebot automatisiert die meisten Standardschritte für die Bereitstellung eines WebSphere Clusters auf Azure VMs. Es erstellt einen Bereitstellungsmanager mit WAS Admin-Konsole auf einer Azure VM und die erforderliche Anzahl von Knoten-Agenten auf separaten Azure VMs.

Bereitstellen des Angebots

Nachdem Sie ausgewählt haben, mit welchem Angebot Sie beginnen möchten, stellen Sie dieses Angebot bereit, indem Sie den Anweisungen unter WebSphere Application Server (traditionell) Cluster auf Azure Virtual Machines bereitstellen folgen.

Profile migrieren

Nachdem Sie das Angebot bereitgestellt haben, können Sie die Profilkonfiguration überprüfen. Weitere Informationen finden Sie unter Profilkonzepte in der IBM-Dokumentation.

Verbinden der Datenbanken

Nachdem Sie die Profile migriert haben, können Sie die Datenbanken verbinden, indem Sie den Anweisungen unter Konfiguration der WebSphere Application Server Datenquelle in der IBM Dokumentation folgen.

Berücksichtigen von Keystores

Sie müssen die Migration der SSL-Keystores berücksichtigen, die von Ihrer Anwendung verwendet werden. Weitere Informationen finden Sie unter Keystore-Konfigurationen für SSL in der IBM-Dokumentation.

Verbinden der JMS-Quellen

Nachdem Sie die Datenbanken verbunden haben, können Sie JMS konfigurieren, indem Sie die Anweisungen unter Einrichten von JMS in IBM WebSphere Application Server in der IBM Dokumentation befolgen.

Konto für Authentifizierung und Autorisierung

Die meisten Anwendungen verfügen über eine Art von Authentifizierung und Autorisierung. Wenn Sie OpenID zur Authentifizierung verwenden, können Sie die OpenID Connect Authentifizierung mit Microsoft Entra ID konfigurieren. Weitere Informationen finden Sie unter OpenID Connect-Authentifizierung mit Microsoft Entra ID.

Berücksichtigen der Protokollierung

Sie können Elastic Stack konfigurieren, indem Sie die Anweisungen unter Analyzing WebSphere Application Server logs with Elastic Stack in der IBM Dokumentation befolgen. Azure unterstützt Elastic. Weitere Informationen finden Sie unter Was ist die Integration von Elastic mit Azure? Sie können das Wissen aus diesen beiden Ressourcen kombinieren, um eine für Azure optimierte Protokollierungslösung für WAS auf VMs zu erhalten.

Migrieren Ihrer Anwendungen

Die verwendeten Verfahren zum Bereitstellen von Anwendungen über das Entwicklungsteam auf Test-, Staging- und Produktionsservern können von Fall zu Fall stark variieren. In einigen Fällen gibt es eine hochentwickelte CI/CD-Plattform, die dazu führt, dass die Anwendungen auf dem WebSphere Application Server bereitgestellt werden. In anderen Fällen kann es sein, dass der Prozess manuell durchgeführt wird. Ein Vorteil der Verwendung von Azure Virtual Machines für die Migration traditioneller WAS-Anwendungen in die Cloud ist, dass Ihre bestehenden Prozesse weiterhin funktionieren.

Sie müssen die Netzwerksicherheitsgruppe konfigurieren, die das Angebot vorsieht, um den Zugriff von Ihrer CI/CD Pipeline oder Ihrem manuellen Bereitstellungssystem aus zuzulassen. Weitere Informationen finden Sie unter Netzwerksicherheitsgruppen.

Testen

Sie müssen alle In-Container-Tests gegen Anwendungen so konfigurieren, dass sie Zugriff auf die neuen in Azure ausgeführten Server haben. Wie bei CI/CD auch, müssen Sie sicherstellen, dass für Ihre Tests gemäß den erforderlichen Netzwerksicherheitsregeln der Zugriff auf die Anwendungen möglich ist, die in Azure bereitgestellt werden. Weitere Informationen finden Sie unter Netzwerksicherheitsgruppen.

Nach der Migration

Nachdem Sie die Migrationsziele erreicht haben, die Sie unter Vor der Migration definiert haben, führen Sie einige End-to-End-Akzeptanztests durch. Hiermit soll sichergestellt werden, dass alles wie gewünscht funktioniert. Eine Anleitung zu einigen möglichen Verbesserungen nach der Migration finden Sie in den folgenden Empfehlungen: