In diesem Artikel wird ein Migrationskonzept beschrieben, um Ihre AIX-Workloads in die Cloud zu verschieben. Sie können Azure Functions für eine serverlose Architektur verwenden oder Azure Virtual Machines, um ein servergebundenes Modell beizubehalten.
Ziehen Sie eine Migrationsstrategie mit Zuweisung zu einer neuen Plattform für AIX-Workloads in Betracht, um Ihre Investitionsrendite (ROI) zu maximieren, wenn Sie ältere Anwendungen zu Azure migrieren. Replatforming-Migrationen erfordern minimale Änderungen, bieten aber cloudnative Vorteile, die denen einer Refactoring-Migration ähneln.
Zu den Vorteilen einer Replatforming-Migration gehören:
- Senkung der Gesamtbetriebskosten (TCO).
- Verbesserte geschäftliche Agilität.
- Verbesserte betriebliche Resilienz.
Architektur (mit Replatforming)
Laden Sie eine Visio-Datei dieser Architektur herunter.
Workflow
Dieser Workflow entspricht der vorhergehenden Architektur.
Benutzeranforderungen und eingehende API-Integrationen werden auf TCP/443 (HTTPS) an Azure Application Gateway übertragen, das eine Web Application Firewall (WAF)-Funktionalität bereitstellt. Application Gateway sendet die Anforderungen als Reverse-Proxy-Anforderungen an verschiedene Services, die auf der Red Hat JBoss Enterprise Application Platform (EAP) gehostet werden.
Java Web Services fragt die Oracle-Datenbank ab (TCP/1521). Die synchrone Antwortzeit der Webanforderung beträgt weniger als 50 Millisekunden (ms).
Eine asynchrone Anforderung, z. B. das Planen einer Batchaufgabe, platziert einen Datensatz in einer Datenbanktabelle, die als Warteschlange innerhalb der Anwendungsebene fungiert.
Hinweis
In Zukunft wird Azure Queue Storage die Datenbanktabelle ersetzen, sodass Sie immer Zugriff auf die Ausführung von Analyseaufträgen haben können.
Der Cronjob, der als KornShell (ksh)-Skript geschrieben wurde, wird zu Bash portiert und auf einem separaten Red Hat Enterprise Linux (RHEL)-Server in Azure Virtual Machine Scale Sets ausgeführt. Der Cronjob wird alle 15 Minuten ausgeführt, einschließlich beim Systemstart, um die Warteschlange in der Oracle-Datenbank abzufragen. Aufträge werden jeweils einzeln pro Host ausgeführt. Virtual Machine Scale Sets parallelisiert lang andauernde Analyse-Aufträge. Für diese Lösung ist keine Batchverarbeitung außerhalb von Spitzenzeiten erforderlich, um die Auswirkungen auf die Systemleistung während der Geschäftszeiten zu begrenzen.
Azure Communication Services sendet E-Mail-Benachrichtigungen über das Azure CLI-Tool (Docs). Vom Azure-System zugewiesene verwaltete Identitäten, wie z. B.
az login --identity, authentifizieren den virtuellen Computer (VM).Die Ergebnisse des Analyseauftrags gelangen über sicheres SMBv3 (TCP/445) zu einer Azure Files-Freigabe, die auch vom System zugewiesene verwaltete Identitäten verwendet.
Komponenten
Microsoft Entra ID beseitigt die netzwerkbasierte Vertrauensstellung und stellt vom System zugewiesene verwaltete Identitäten bereit, wodurch die Sicherheit verbessert wird.
Durch Azure App Service entfällt die Notwendigkeit, ein Betriebssystem und einen Server zu verwalten, wodurch die betriebliche Effizienz und die geschäftliche Agilität erhöht werden.
Application Gateway ist ein vollständig verwalteter und skalierbarer Service, der Web Application Firewall und Reverseproxyfunktionen bereitstellt.
Azure Files stellt Datenberichte bereit, die über einen verwalteten Service veröffentlicht werden.
Azure Functions ist eine ereignisgesteuerte, serverlose Computingplattform, die zum effizienten Entwickeln von Code in der angegebenen Programmiersprache verwendet wird.
Ein virtueller Azure-Computer wird von den Oracle-Datenbank- und SAS-Analyseknoten verwendet.
Azure Compute Gallery erstellt und speichert Images für die Oracle-Datenbank und SAS-Analyseknoten. Es gibt zwei Galerien: eine in der primären Region und eine in der Notfallwiederherstellungsregion.
Communication Services sendet E-Mails mit einem CLI-Dienstprogramm. Dieser Dienst ersetzt den
mailx-Befehl auf AIX.
Alternativen
Eine Alternative ist eine vollständige servergebundene Architektur, die alle Middlewarekomponenten beibehält.
Diese Lösung ähnelt der ursprünglichen Architektur, die ein ähnliches Mandat erfüllt, mit dem viele IT-Organisationen operieren. Diese alternative Lösung kostet auch ungefähr genauso viel wie die ursprüngliche Architektur, bietet jedoch nicht die Vorteile der Replatforming-Architektur. Zum Beispiel:
Lizenzierungseinsparungen: Die alternative Lösung behält WebSphere bei und fügt weitere RHEL-Knoten hinzu.
Betriebliche Effizienz: Die alternative Lösung behält die gleiche Anzahl von Servern bei.
Geschäftliche Agilität: Mit der alternativen Lösung bleibt die Erstellung von Berichten auf Nächte beschränkt ohne ganztägige Analysen mit automatischer Skalierung.
Szenariodetails
Wählen Sie je nach Portabilität Ihrer vorhandenen Anwendungen und der Workflowpräferenz und Technologieroadmap Ihres Teams ein serverloses oder servergebundenes Modell aus.
Wie die ursprüngliche Architektur verfügt die Replatforming-Architektur über eine Oracle-Datenbank, wird jedoch auf einem RHEL-Betriebssystem auf Azure Virtual Machines betrieben. Für den vollständig verwalteten Azure App Service in der Replatforming-Architektur ersetzt Red Hat JBoss EAP die WebSphere Java-Anwendung.
Architektur (original)
Laden Sie eine Visio-Datei dieser Architektur herunter.
Workflow
Dieser Workflow entspricht der vorhergehenden Architektur.
Benutzeranforderungen und eingehende API-Integrationen werden auf TCP/443 (HTTPS) an den lokalen F5-Load Balancer übertragen und dann per Reverseproxy zu verschiedenen von IBM WebSphere gehosteten Java Web Services.
Java Web Services fragt die Oracle-Datenbank über TCP/1521 ab. In den meisten Fällen beträgt die synchrone Antwortzeit der Webanforderung weniger als 1 Sekunde, jedoch mehr als 300 ms nach Test- und Webloganalyse.
Eine asynchrone Anforderung, z. B. das Planen einer Batchaufgabe, platziert einen Datensatz in einer Oracle-Datenbanktabelle, die als Warteschlange innerhalb der Anwendungsebene fungiert.
Ein Cronjob, der als ksh-Skript geschrieben wurde, fragt die Warteschlange in der Oracle-Datenbank ab und nimmt SAS-Analyseaufträge zur Ausführung auf. Der Kunde muss die Batchverarbeitung nachts durchführen, um die Auswirkungen auf die Systemleistung während der Geschäftszeiten zu begrenzen.
E-Mail-Benachrichtigungen informieren Benutzer und Administratoren per SMTP (TCP/25) über die Anfangs- und Abschlusszeiten des Auftrags sowie über Erfolgs- oder Fehlschlagergebnisse.
Die Ergebnisse des Analyseauftrags gehen über NFS (TCP+UDP/111.2049) zur Erfassung über SMBv3 (TCP/445) zu einem freigegebenen Laufwerk.
Szenariodetails
Diese ursprüngliche Architektur evaluiert eine monolithische Java-Anwendung, die auf IBM WebSphere ausgeführt wird, und evaluiert die Batchverarbeitung von SAS, die ksh-Skripts orchestrieren. Eine Oracle-Datenbank, die auf einem separaten AIX-Host ausgeführt wird, unterstützt beide Anwendungsworkloads.
Berücksichtigen Sie Ihre ursprünglichen Workloads, die auf AIX ausgeführt werden, um festzustellen, ob eine Replatforming-Migrationsstrategie zu Ihrem Migrationsbudget passt. Arbeiten Sie von den gewünschten Ergebnissen aus rückwärts, um einen transformativen, anwendungsorientierten Migrationspfad zur Cloud zu ermitteln. Stellen Sie sicher, dass der Großteil Ihres Anwendungscodes in einer Sprache geschrieben ist, die cloudnative Dienste wie serverlose Architekturen und Containerorchestratoren unterstützen.
In diesem Szenario analysierte Tidal Accelerator den Java-Anwendungscode und ermittelte die Kompatibilität mit JBoss EAP. Frühzeitig im Projekt werden Azure Pipelines oder GitHub-Aktionen verwendet, um die Anwendung als Pilotprojekt neu zu erstellen. Der Kunde kann dann für Agilität mit kontinuierlichen Integrations- und Ci/CD-Pipelines in einem verwalteten Service, wie z. B. Azure-App Service, sorgen. Diese Funktion kann nicht in der lokalen WebSphere-Umgebung des Kunden genutzt werden.
In diesem Beispiel wird die Oracle-Datenbank in dieser Phase aufgrund des PL/SQL-Umfangs beibehalten, den Tidal Accelerator während der Analysephase ermittelt hat. Die zukünftigen Aktivitäten des Kunden beinhalten die Migration von der Oracle-Datenbank auf RHEL zu einer vollständig verwalteten Azure Database for PostgreSQL, die Übernahme von Azure Queue Storage und das Ausführen vollständiger SAS-Aufträge nach Bedarf. Diese Aktivitäten passen zur Technologieroadmap des Kunden, den Entwicklungszyklen und der geschäftlichen Ausrichtung, die im Gespräch mit dem Anwendungseigentümer ermittelt wurde. Der folgende Screenshot zeigt ein Gespräch in Tidal Accelerator.
Mögliche Anwendungsfälle
Sie können diese Architektur für AIX-zu-Azure-Migrationen verwenden, die Datenanalysen, Customer Relationship Management (CRM), Mainframe-Integrationsebenen in einer Hybrid-Cloud-Konfiguration und andere benutzerdefinierte Softwarelösungen in Bestands- und Lagerverwaltungsszenarien abdecken.
Sie können diese Architektur für herkömmliche Anwendungsworkloads verwenden, mit Technologien wie:
- Oracle Siebel
- Oracle E-Business Suite
- SAS
- IBM BPM
Überlegungen
Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.
Zuverlässigkeit
Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Zuverlässigkeit.
Diese Architektur verwendet Azure Site Recovery, um die Datenbank-Azure-VMs in einer sekundären Azure-Region für ein schnelles Failover und die Notfallwiederherstellung bei Ausfall einer ganzen Azure-Region zu spiegeln. Ebenso verwendet Azure Files georedundanten Speicher.
Datenverarbeitungsknoten verwenden zonenredundante (RA-ZRS) Managed Disks, um Ausfallsicherheit bei Zonenausfällen zu gewährleisten. Während des Ausfalls einer gesamten Region können Sie Datenverarbeitungsknoten in einer anderen Region als der mit Ihrem VM-Image in der redundanten Azure Compute Gallery neu bereitstellen.
Sicherheit
Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Sicherheit.
Diese Architektur verwendet ein Konzept mit unveränderlicher Infrastruktur für Anwendungsbereitstellungen und überprüft proaktiv Code in Azure-Pipelines, um vertrauliche Daten in der Produktion zu sichern. Sie beinhaltet ein Shift-Left-Konzept für die Sicherheitsüberprüfung und führt häufig CI/CD-pipelinefähige Bereitstellungen aus, um die Konformität der Software zu verbessern und technische Probleme zu vermeiden.
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 Erstellen einer Checkliste zur Überprüfung der Kostenoptimierung.
Diese Lösung beseitigt so viele servergebundene Komponenten wie möglich, wodurch die Betriebskosten um mehr als 70 % reduziert werden. Diese Architektur senkt die Computing- und Softwarelizenzierungskosten.
Optimaler Betrieb
Die Säule „Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung des optimalen Betriebs.
Das Produktteam unterstützt sich selbst in Azure, wodurch Lösungszeiten für gemeldete Vorfalltickets verkürzt werden. Darüber hinaus ist die Anzahl der Unzustellbarkeiten für Tickets oder die Anzahl der Tickets, die von einer Gruppe zu einer anderen zugewiesen werden, gleich null, da ein einziges Produktteam den gesamten Anwendungsstapel in Azure unterstützt.
Effiziente Leistung
Leistungseffizienz ist die Fähigkeit Ihrer Workload, eine effiziente Skalierung entsprechend den Anforderungen der Benutzer auszuführen. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Leistungseffizienz.
Der Kunde verwendet nach Möglichkeit Azure App Service, sodass er seine Computinganforderungen automatisch vertikal und horizontal skalieren kann, um den Anforderungen der jeweiligen Anwendung gerecht zu werden. Diese Elastizität sorgt für eine konsistente Anwendungsleistung in Spitzenzeiten. Dazu ist dieses Konzept auch kosteneffizient.
Beitragende
Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:
Hauptautor:
Richard Berry | Sr. Program Manager
Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.
Nächste Schritte
Weitere Informationen zur Verwendung einer Tidal Accelerator-Lösung erhalten Sie vom Microsoft Tidal Cloud-Team.
Weitere Informationen zum Migrieren zu Azure erhalten Sie vom Legacy Migration Engineering-Team.