Migrieren von WebSphere-Anwendungen zu Azure Virtual Machines

  • Artikel

In diesem Handbuch wird beschrieben, was Sie beachten sollten, wenn Sie eine vorhandene herkömmliche WebSphere Application Server (WAS)-Anwendung migrieren möchten, die auf virtuellen Azure-Computern ausgeführt wird. Eine Übersicht über die verfügbaren WAS-herkömmlichen Lösungen in Azure Marketplace finden Sie unter Was sind Lösungen zum Ausführen der IBM WebSphere-Produktfamilie auf Azure?

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“

Dieser Leitfaden und die entsprechenden Azure Marketplace-Angebote sind ein Ausgangspunkt, um die Migration Ihrer herkömmlichen 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 ihre "Migration abgeschlossen" erreicht haben, können Sie eine Momentaufnahme Ihrer virtuellen Computer wie unter Erstellen einer Momentaufnahme einer virtuellen Festplatte beschrieben nehmen. Nachdem Sie sich vergewissert haben, dass Sie ihre Momentaufnahme erfolgreich wiederherstellen können, können Sie die Verbesserungen ausführen, ohne befürchten zu müssen, den bisher erreichten Migrationsfortschritt zu verlieren.

Stellen Sie sicher, dass das Ziel das geeignete Ziel für Ihren Migrationsaufwand ist.

Der erste Schritt bei einer erfolgreichen Migration einer WAS-Anwendung zu Azure ist die Auswahl des am besten geeigneten Migrationsziels.

WAS traditionell gut auf virtuellen Azure-Computern ausgeführt wird. Das Ziel des virtuellen Computers (VM) ist die einfachste Wahl, da es einer lokalen Bereitstellung am ehesten ähnelt. Die Verwaltungs- und Bereitstellungsumgebung für virtuelle Computer entspricht dem, was Sie lokal haben.

Eine weitere Option besteht darin, zu Containern zu migrieren, indem sie DIE herkömmliche Arbeitsauslastung in Anwendungscontainer konvertieren. Sie können das Containerziel für Azure Kubernetes Service (AKS) und Azure Red Hat OpenShift ausführen. Der Kompromiss für diese Erleichterung ist die wirtschaftliche Kosten.

Im Allgemeinen ist die Kosten pro Minute für eine VM-basierte Lösung im Vergleich zu Containern höher. Während eine containerbasierte Lösung weniger ausgeführt werden kann, müssen Sie ihre Anwendung auf die Anforderungen der Container-Orchestrierungsplattform beschränken.

Wenn die Minimierung von Änderungen der wichtigste Faktor für Ihren Migrationsaufwand ist, sollten Sie eine VM-basierte Migration in Betracht ziehen. Informationen hierzu finden Sie unter Migrieren von WebSphere-Anwendungen zu virtuellen Azure-Computern.

Wenn Sie die Konvertierung Ihrer Anwendung in Containern tolerieren können, um die Laufzeitkosten zu reduzieren, sollten Sie eine AKS-basierte oder Azure Red Hat OpenShift-basierte Migration in Betracht ziehen.

Für die AKS-basierte Migration können Sie mit der Kostenlosen Stufe beginnen. Erhalten Sie kostenlose Clusterverwaltung und zahlen Sie nur für die virtuellen Computer, zugeordneten Speicher und Netzwerkressourcen, die verbraucht werden. Informationen hierzu finden Sie unter Migrieren von WebSphere-Anwendungen zu Azure Kubernetes Service.

Für die Azure Red Hat OpenShift-basierte Migration haben Anwendungsknoten zusätzlich zu den Compute- und Infrastrukturkosten weitere Kosten für die OpenShift-Lizenzkomponente. Diese Kosten werden basierend auf der Anzahl der Anwendungsknoten und des Instanztyps in Rechnung gestellt. Verwenden Sie On-Demand-Preise oder reservierte Instanzen, je nachdem, was die Anforderungen Ihrer Workload und Ihres Unternehmens am besten erfüllt. In diesem Fall finden Sie Informationen zum Migrieren von WebSphere-Anwendungen zu Azure Red Hat OpenShift.

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

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

IBM und Microsoft haben eine Reihe von Azure-Lösungsvorlagen in Azure Marketplace bereitgestellt, um einen soliden Ausgangspunkt für die Migration zu Azure zu bieten. Eine Liste der Angebote finden Sie unter Ausführen der WebSphere-Produktfamilie von Produkten und Liberty in Microsoft Azure, und wählen Sie dann das Produkt aus, das Ihrer vorhandenen Bereitstellung am ehesten entspricht. Die Liste der Angebote finden Sie im Übersichtsartikel Was sind Lösungen zum Ausführen der IBM WebSphere-Produktfamilie auf Azure?

Wenn keines der vorhandenen Angebote ein guter Ausgangspunkt ist, müssen Sie die Bereitstellung mithilfe von Azure Virtual Machine-Ressourcen manuell reproduzieren. Die schrittweise Anleitung finden Sie im Lernprogramm: Manuelle Installation von IBM WebSphere Application Server Network Deployment auf virtuellen Azure-Computern. Weitere Informationen finden Sie unter Was ist IaaS?

Ermitteln, ob die herkömmliche WAS-Version kompatibel ist

Ihre vorhandene WAS-traditionelle Version muss mit der Version in den IaaS-Angeboten kompatibel sein. Die Versionsinformationen finden Sie 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 WAS-herkömmliche Version nicht mit dieser Version kompatibel ist, müssen Sie die Bereitstellung mithilfe von Azure IaaS-Ressourcen manuell 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 WAS befinden sich diese geheimen Schlüssel in vielen verschiedenen Konfigurationsdateien und Konfigurationsspeichern. Ü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 Konfigurationsdaten in mehreren Dokumenten in einer kaskadierenden Hierarchie von Verzeichnissen. Die meisten Konfigurationsdokumente weisen XML-Inhalte auf. Weitere Informationen finden Sie unter Konfigurationsdokumente und grundlegende Konzepte von Azure Key Vault.

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 im IBM Document Certificate Management in SSL

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

Für die Verwendung von WAS auf virtuellen Azure-Computern ist eine bestimmte Version von Java erforderlich. Daher müssen Sie bestätigen, dass Ihre Anwendung ordnungsgemäß mit dieser unterstützten Version ausgeführt wird.

IBM Java 8 kommt mit der WAS9-Verteilung. Wir empfehlen die Verwendung der VON IBM bereitgestellten Java JRE. Weitere Informationen finden Sie unter Java SE 8 in der herkömmlichen V9 von WebSphere Application Server.

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 in der IBM-Dokumentation unter WebSphere Data Sources . 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 Verwenden von JMS-Ressourcen.

Überprüfen Der Profilkonfiguration

Die Standard Konfigurationseinheit in WAS ist das Profil. Daher enthält die datei resources.xml eine Fülle von Konfigurationen, die Sie sorgfältig für die Migration berücksichtigen müssen. Die Datei enthält Verweise auf weitere XML-Dateien, die in Unterverzeichnissen gespeichert sind. IBM berät, dass Sie normalerweise die IBM Console verwenden sollten, um die verwaltbaren Objekte und Dienste von WAS zu konfigurieren und WAS zu ermöglichen, den Ordner "Profile/Profilname" zu Standard. Weitere Informationen finden Sie unter Verwalten von Profilen auf verteilten und IBM i-Betriebssystemen.

Innerhalb Ihrer Anwendung

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

Ermitteln, ob die Sitzungsreplikation verwendet wird

Wenn Ihre Anwendung auf der Sitzungsreplikation basiert, haben Sie die folgenden Optionen:

  • Bei HTTP-Sitzungen können Sie gemäß der Sitzungsverwaltungsstufe Arbeitsspeicher oder eine Datenbank verwenden, um Sitzungsdaten zu sammeln.
  • Bei verteilten Sitzungen können Sie Sitzungen in einer Datenbank mithilfe der Persistenz der Datenbanksitzung speichern.
  • Für den dynamischen Cache können Sie Sitzungsdaten in der Speicher-zu-Speicher-Replikation oder 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 ist es ratsam, zu beherrschen, wie WAS die HTTP-Sitzungsstatusreplikation durchführt. Weitere Informationen finden Sie in der IBM-Dokumentation unter Verwalten von Sitzungsbohnen .

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 zu TREIBERN in WAS finden Sie unter VERWENDUNG VON DRIVER Drivers 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 Skripts gehören wsadmin, AdminControl, AdminConfig, AdminApp und AdminTask.
  • Werden an JVM spezifische Parameter übergeben?
  • Werden dem Klassenpfad des Servers JAR-Dateien hinzugefügt?
  • Wurden Anlagen auf Betriebssystemebene verwendet, um systemd zu bewirken, dass WAS-Komponenten nach einem Serverneustart automatisch gestartet werden?

Je nach Antworten auf diese Fragen müssen Sie Überlegungen zur Migration berücksichtigen.

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 Auswählen einer Lösung zum 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 -Themen verwendet, müssen Sie sie zu einem extern gehosteten JMS-Server migrieren. Eine Strategie für diejenigen, die JMS verwenden, ist die Verwendung von Azure Service Bus und das Advanced Message Queuing-Protokoll. Weitere Informationen finden Sie unter Verwenden von Java Message Service (JMS) mit Azure Service Bus und AMQP 1.0.

Wenn Sie beständige JMS-Speicher konfiguriert haben, müssen Sie deren Konfiguration erfassen und nach der Migration anwenden.

Wenn Sie IBM MQ verwenden, können Sie diese Software auf virtuelle Azure-Computer migrieren und wie sie verwenden.

Microsoft verfügt über eine Lösung zur Integration von IBM MQ in 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-Bündel 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 ggf. alle Vorkommen von / oder \ in Dateisystempfaden durch File.Separator oder Paths.get ersetzen.

Ermitteln, 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 in der Dokumentation zu IBM Integration Bus.

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 verpackt ist, überprüfen Sie unbedingt die Dateien "application.xml", "ibm-application-bnd.xmi" und "ibm-application-ext.xmi ", und erfassen Sie ihre Konfigurationen. Weitere Informationen finden Sie unter Building the Enterprise Archive (EAR) package on 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. Sie können den statischen Inhalt auch direkt in einer App im Azure Spring Apps Enterprise-Plan bereitstellen. Weitere Informationen finden Sie unter Bereitstellen statischer Webdateien.

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. Sie können den statischen Inhalt auch direkt in einer App im Azure Spring Apps Enterprise-Plan bereitstellen. Weitere Informationen finden Sie unter Bereitstellen statischer Webdateien.

Ermitteln der Netzwerktopologie

Die aktuelle Gruppe von Azure Marketplace-Angeboten ist ein Ausgangspunkt für Ihre Migration. Wenn das Angebot keine Aspekte Ihrer Architektur abdeckt, die Sie migrieren müssen, müssen Sie die Netzwerktopologie Ihrer vorhandenen Bereitstellung erfassen. Anschließend müssen Sie diese Netzwerktopologie in Azure reproduzieren, auch nachdem Sie das Basisangebot mit einer der Lösungsvorlagen eingerichtet haben.

Die Netzwerktopologie ist ein breites Thema, aber die folgenden Verweise können Ihren Migrationsbemühungen eine Richtung geben:

Berücksichtigen der Verwendung von JCA-Adaptern und Ressourcenadaptern

Wenn Ihre vorhandene Anwendung JCA-Adapter oder andere Ressourcenadapter verwendet, um eine Verbindung mit anderen Unternehmenssystemen herzustellen, stellen Sie sicher, dass Sie die Konfiguration für diese Artefakte auf die WAS anwenden, die auf virtuellen Azure-Computern ausgeführt wird. Weitere Informationen finden Sie in der IBM-Dokumentation unter Relationale Ressourcenadapter und JCA .

Konto für Authentifizierung und Autorisierung

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

Ermitteln, ob WAS-Clustering verwendet wird

Höchstwahrscheinlich haben Sie Ihre Anwendung auf mehreren WAS-Servern bereitgestellt, um eine hohe Verfügbarkeit zu erzielen. Sie können diese Cluster direkt von Ihrer lokalen Installation zu WAS auf virtuellen Azure-Computern migrieren. Weitere Informationen finden Sie in der IBM-Dokumentation unter WebSphere Application Server Network Deployment .

Konto für Lastenausgleichsanforderungen

Der Lastenausgleich ist ein wesentlicher Bestandteil der Migration Ihres WAS-Clusters zu Azure. Die einfachste Lösung besteht darin, die integrierte Unterstützung für Azure-App lication Gateway oder IBM HTTP Server zu verwenden, die im Azure Marketplace-Angebot für IBM WebSphere Application Server Cluster bereitgestellt wird.

Eine Zusammenfassung der Funktionen von Azure-App lication Gateway im Vergleich zu anderen Azure-Lastenausgleichslö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 HERKÖMMLICHEs WAS-Angebot auf virtuellen Azure-Computern aus.

Die folgenden Angebote stehen für WAS auf virtuellen Azure-Computern zur Verfügung.

Während der Bereitstellung eines Angebots werden Sie aufgefordert, die Größe des virtuellen Computers 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 Cloud Services (klassisch)".

  • IBM WebSphere Application Server Single Instance auf azure VM

    Dieses Angebot automatisiert die meisten Textbausteine, um eine einzelne WebSphere-Instanz auf einem virtuellen Azure-Computer bereitzustellen. Es erstellt ein Anwendungsserverprofil mit DER WAS-Verwaltungskonsole.

  • IBM WebSphere Application Server Cluster auf Azure-VMs

    Dieses Angebot automatisiert die meisten Bausteine, um einen WebSphere-Cluster auf Azure-VMs bereitzustellen. Er erstellt einen Bereitstellungs-Manager mit DER WAS-Verwaltungskonsole auf einer Azure-VM und erforderliche Anzahl von Knoten-Agents auf getrennten Azure-VMs.

Bereitstellen des Angebots

Nachdem Sie ausgewählt haben, mit welchem Angebot sie beginnen soll, stellen Sie dieses Angebot bereit, indem Sie die Anweisungen unter Deploy WebSphere Application Server (traditionell) Cluster auf virtuellen Azure-Computern befolgen.

Migrieren der Profile

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

Verbinden der Datenbanken

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

Berücksichtigen von Keystores

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

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 für die Authentifizierung verwenden, können Sie die OpenID-Verbindungsauthentifizierung mit Microsoft Entra ID konfigurieren. Weitere Informationen finden Sie unter OpenID Verbinden Authentifizierung mit Microsoft Entra ID.

Berücksichtigen der Protokollierung

Sie können Elastic Stack konfigurieren, indem Sie die Anweisungen unter Analysieren von WebSphere Application Server-Protokollen mit Elastic Stack in der IBM-Dokumentation befolgen. Azure bietet Unterstützung für Elastic. Weitere Informationen finden Sie unter What is Elastic integration with Azure? Sie können das Wissen in diesen beiden Ressourcen kombinieren, um eine azureoptimierte Protokollierungslösung für WAS auf virtuellen Computern zu erreichen.

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 stark weiterentwickelte 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 virtueller Azure-Computer zum Migrieren von HERKÖMMLICHEn Anwendungen in die Cloud besteht darin, dass Ihre vorhandenen Prozesse weiterhin funktionieren.

Sie müssen die Netzwerksicherheitsgruppe konfigurieren, die das Angebot bietet, um den Zugriff von Ihrer CI/CD-Pipeline oder aus einem manuellen Bereitstellungssystem zu ermöglichen. Weitere Informationen finden Sie unter Netzwerksicherheitsgruppen.

Testen

Sie müssen alle In-Container-Tests für Anwendungen konfigurieren, um auf die neuen Server zuzugreifen, die in Azure ausgeführt werden. 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. Anleitungen zu einigen potenziellen Verbesserungen nach der Migration finden Sie in den folgenden Empfehlungen: