Bearbeiten

Freigeben über

Verwenden von LzLabs Software Defined Mainframe (SDM) in einer Azure-VM-Bereitstellung

Azure Virtual Machines
Azure Database for PostgreSQL
Azure Virtual Network
Azure Resource Manager

LzLabs Software Defined Mainframe (SDM) verringert das Risiko und die Komplexität des Rehostings von Legacyworkloads erheblich, da der Quellcode von Legacyanwendungen bei Verwendung dieser Plattform nicht gesucht, geändert und neu kompiliert werden muss. Dank dieses Ansatzes können z/Architecture-Programme mit ausführbarer Binärdatei auf Computern mit x86_64-Architektur und einem Softwarestapel für offene Systeme mit nativer Geschwindigkeit ausgeführt werden, was den Weg für die Legacymodernisierung ebnet.

Aufbau

Diagramm: Architektur und Datenfluss (ausführlich beschrieben im zugehörigen Artikeltext).Eine SVG-Datei dieser Architektur herunterladen.

Workflow

  1. Der Zugriff auf LzLabs SDM-Anwendungen erfolgt genau wie bei normalen Mainframeanwendungen über ein 3270-Terminal. Sie können einen beliebigen Terminalemulator verwenden. Für die Verwaltung, Pflege und andere Aktivitäten wird der LzWorkbench-Client verwendet. Die Serverkomponente wird auf dem virtuellen SDM-Computer ausgeführt.
  2. Die Konfiguration des Portzugriffs wird in der Regel an die Sicherheitsanforderungen des Kunden angepasst.
  3. Für eine sichere Implementierung von SDM sollte ein Webdienste-Front-End mit folgenden Komponenten implementiert werden:
  4. SDM kann für Failover mit VNET-Peering mit den Regionen „Sicherung“, „Notfallwiederherstellung“ (Disaster Recovery, DR) und „Sekundäre Azure-Region“ konfiguriert werden. Dadurch verbessert sich die Verfügbarkeit von SDM für Produktionsworkloads, da Azure bei einem Ausfall des ursprünglichen virtuellen Computers über ein konsistentes Replikat verfügt.
  5. Der virtuelle SDM-Computer in der Produktionsumgebung wird durch Azure Site Recovery repliziert und mit der Failoverregion synchronisiert. Der Dienst synchronisiert den Hauptbetriebssystemdatenträger für die Produktion sowie die angefügten Datenträgerimages mit der SDM-Instanz der sekundären Region. Dies wird für alle angefügten Datenträger durchgeführt. Einzige Ausnahme ist der Datenträger, der für die Indexdateiverarbeitung verantwortlich ist (siehe Punkt 10). Site Recovery wird ebenfalls verwendet, um alle anderen VM-Images mit der sekundären Region zu synchronisieren.
  6. Die Datenbank in dieser Architektur ist PostgreSQL (IaaS). Da der Azure PostgreSQL-Dienst derzeit nicht verwendet werden kann, muss in Bereitstellungen PostgreSQL (IaaS) mit SDM verwendet werden. Der Grund ist eine Einschränkung in Azure PostgreSQL im Zusammenhang mit der Verarbeitung benutzerdefinierter Datentypen (User-defined Data Types, UDTs). Die Datenbankinstanz in der sekundären Region wird mithilfe des Write-Ahead-Transaktionsprotokolls auf dem neuesten Stand gehalten. Dies ermöglicht regionsübergreifende Failover. Im Falle eines Failovers wird der Modus auf „Aktiv“ festgelegt. Der gleiche Prozess wird verwendet, um die Transaktionskonsistenz der Produktionsfailoverdatenbank innerhalb der Produktionsregion zu gewährleisten. Dank der Synchronisierung der beiden Replikate mithilfe des Write-Ahead-Transaktionsprotokolls ist die Datenbankebene hochverfügbar. Hinweis: Um eine optimale Leistung zu erzielen, müssen der virtuelle Datenbankcomputer und der virtuelle SDM-Computer in einer Azure-Näherungsplatzierungsgruppe platziert werden.
  7. Für die DR-Region muss ein Webdienste-Front-End bereitgestellt werden, um sicheren Zugriff auf das System zu gewährleisten. Viele Mainframeworkloads verfügen über eine API-Webdienstebene für den Zugriff auf CICS-Transaktionen und DB2-Daten.
  8. Für die Integration von RACF- und Top Secret-Identitäten mit Active Directory-Erweiterungen bietet LzVault Authentifizierung und Autorisierung in Azure für die aus dem Mainframe migrierten Sicherheitsregeln.
  9. Der Barman-Server wird auf der Datenebene konfiguriert. Dadurch werden Momentaufnahmereplikate der PostgreSQL-Datenbank für die Point-in-Time-Wiederherstellung in der Produktionsregion und in der sekundären Region bereitgestellt.
  10. Wie in Punkt 5 erwähnt, muss der Datenträger, der die indizierte Dateiverarbeitung für SDM verwaltet, regionsübergreifend mithilfe einer Datenbankspiegelungslösung synchronisiert werden. Der Grund: Von Azure Site Recovery kann die für eine Datenbank nötige Transaktionskonsistenz nicht garantiert werden. Da die indizierte Dateiverarbeitung nicht in PostgreSQL erfolgt, muss eine dafür geeignete Lösung verwendet werden.
  11. Für die Planung der Batchauftragsverarbeitung muss ein Planer wie Azure Logic Apps oder SMA verwendet werden.
  12. Aus Verfügbarkeitsgründen werden zwei virtuelle SDM-Computer in einer Azure-Verfügbarkeitsgruppe bereitgestellt. Azure Load Balancer bietet Lastenausgleichsdienste für die beiden virtuellen Computer. Der Zustand wird zwischen den beiden virtuellen Computern mithilfe eines freigegebenen Azure-Datenträgers geteilt. Dies wird per DRDB in der DR-Instanz repliziert.

Komponenten

  • Virtuelle Azure-Computer sind eine von mehreren bedarfsgesteuerten, skalierbaren Computerressourcen, die von Azure angeboten werden. Mit einem virtuellen Azure-Computer (VM) erhalten Sie eine flexible Virtualisierung, ohne Zeit und Mittel für den Kauf und die Verwaltung der physischen Hardware aufwenden zu müssen, auf der der virtuelle Computer ausgeführt wird.
  • Virtuelle Netzwerke (VNets) sind der Grundbaustein für Ihr privates Netzwerk in Azure Virtual Network. Virtuelle Netzwerke ermöglichen zahlreichen Azure-Ressourcen (einschließlich virtuellen Computern) die sichere Kommunikation mit dem Internet und lokalen Netzwerken sowie eine sichere Kommunikation der Ressourcen untereinander. Ein virtuelles Netzwerk ähnelt einem herkömmlichen Netzwerk, das Sie in Ihrem eigenen Rechenzentrum betreiben, bietet jedoch zusätzliche Vorteile der Infrastruktur von Azure wie Skalierbarkeit, Verfügbarkeit und Isolation.
  • Die Schnittstelle von Azure Virtual Network ist ein Netzwerkschnittstellencontroller, der es einem virtuellen Azure-Computer ermöglicht, mit dem Internet, mit anderen Ressourcen in Azure sowie mit lokalen Ressourcen zu kommunizieren. Wie in dieser Architektur zu sehen, können einem virtuellen Azure-Computer weitere NICs hinzugefügt werden, sodass die untergeordneten virtuellen Solaris-Computer über ein eigenes dediziertes Netzwerkschnittstellengerät und über eine eigene IP-Adresse verfügen.
  • Verwaltete Azure-SSD-Datenträger sind Speichervolumes auf Blockebene, die von Azure verwaltet und mit virtuellen Azure-Computern verwendet werden. Verfügbare Datenträgertypen sind „Disk Ultra“, „SSD Premium“, „SSD Standard“ und „HDD Standard“. Für diese Architektur wird entweder SSD Premium oder SSD Ultra empfohlen.
  • Azure Storage und Azure Files bieten vollständig verwaltete Dateifreigaben in der Cloud, auf die über das branchenübliche SMB-Protokoll (Server Message Block) zugegriffen werden kann. Azure-Dateifreigaben können gleichzeitig durch die Cloud oder lokale Bereitstellungen von Windows, Linux und macOS eingebunden werden.
  • Mit Azure ExpressRoute können Sie Ihre lokalen Netzwerke über eine private Verbindung, die von einem Konnektivitätsanbieter bereitgestellt wird, auf die Cloud von Microsoft ausdehnen. Mit ExpressRoute können Sie Verbindungen mit Microsoft-Clouddiensten herstellen, z. B. Microsoft Azure und Office 365.
  • Azure SQL-Datenbank ist eine vollständig verwaltete PaaS-Datenbank-Engine (Platform-as-a-Service), bei der die meisten Funktionen für die Datenbankverwaltung wie etwa Upgrades, Patches, Sicherungen und Überwachung ohne Benutzereingriff erfolgen. Azure SQL-Datenbank wird immer in der aktuellen stabilen Version der SQL Server-Datenbank-Engine und unter einem gepatchten Betriebssystem mit 99,99-prozentiger Verfügbarkeit ausgeführt. Dank der in Azure SQL-Datenbank integrierten PaaS-Funktionen können Sie sich auf die domänenspezifischen Datenbankverwaltungs- und -optimierungsaktivitäten konzentrieren, die für Ihr Unternehmen entscheidend sind.

Szenariodetails

LzLabs Software Defined Mainframe (SDM) ist eine Plattform für Workload-Rehosting und zur Modernisierung von Mainframeanwendungen. SDM ermöglicht das Ausführen von Mainframe-Legacyanwendungen auf offenen Systemen ohne Quellcodeänderungen, Neukompilierung oder Konvertierung von Datentypen. Darüber hinaus verfügt SDM über Features, mit denen sich Legacyanwendungen kontrolliert auf moderne Sprachen und Implementierungen umstellen lassen, ohne die Integrität oder den Betrieb des Systems als Ganzes zu gefährden.

SDM verringert das Risiko und die Komplexität des Rehostings von Legacyworkloads erheblich, da der Quellcode von Legacyanwendungen bei Verwendung dieser Plattform nicht gesucht, geändert und neu kompiliert werden muss. Dank dieses Ansatzes können z/Architecture-Programme mit ausführbarer Binärdatei auf Computern mit x86_64-Architektur und einem Softwarestapel für offene Systeme mit nativer Geschwindigkeit ausgeführt werden, was den Weg für die Legacymodernisierung ebnet.

Mögliche Anwendungsfälle

  • Kein Quellcode: LzLabs ist eine Lösung für Kunden mit Mainframeworkloads, die nicht über den Quellcode für die ausgeführten Anwendungen verfügen. Dies kann der Fall sein, wenn eine COTS-Lösung (Customizable Off-The-Shelf) von einem unabhängigen Softwareanbieter erworben wurde, der den Quellcode nicht für die IP-Adresse bereitgestellt hat. Viele dieser COBOL-basierten Anwendungen wurden außerdem vor langer Zeit geschrieben. Daher kann es sein, dass der Quellcode inzwischen verloren gegangen oder nicht mehr auffindbar ist. LzLabs löst dieses Problem, da für die Ausführung in SDM lediglich die Lademodule (Binärdateien) benötigt werden.
  • Der Kunde verfügt über den Quellcode und möchte ein Rehosting durchführen: Der Kunde verfügt möglicherweise noch über den Quellcode und möchte seine Mainframeworkloads einfach neu hosten, um Kosten zu sparen und von den Vorteilen einer Cloudplattform wie Azure zu profitieren. Der COBOL-Code kann in SDM in einer modernen DevOps verwaltet werden.
  • Failover: Kunden können LzLabs SDM für eine Failoverumgebung verwenden, um die Uptime zu erhöhen und potenzielle Beeinträchtigungen der Geschäftskontinuität zu vermeiden. In diesem Fall werden die Lademodule in SDM geladen und als sekundäre Umgebung verwendet, wenn die Produktionsumgebung nicht mehr verfügbar ist.

Überlegungen

Für diese Lösung sind aufgrund des Azure Well-Architected Framework folgende Punkte zu berücksichtigen:

Verfügbarkeit

Die Verfügbarkeit für die Logikschicht wird mithilfe von Site Recovery bereitgestellt, wie im Diagramm zu sehen. Da von LzLabs SDM PostgreSQL für die Datenbankebene genutzt wird, wird die Verfügbarkeit mit einem Write-Ahead-Transaktionsprotokoll bereitgestellt. Dadurch wird sichergestellt, dass die sekundäre Datenbank mit der Produktionsdatenbank transaktionskonsistent ist.

Vorgänge

Die Azure-Umgebung im Diagramm wird entweder über das Azure-Portal oder mithilfe von Azure Resource Manager-Vorlagen und Skripts verwaltet. Dies ermöglicht die Verwaltung von Ressourcen (beispielsweise das Anpassen der Größe) sowie von Sicherheit und Zugriff. Die eigentliche SDM-Umgebung kann über das LzWorkbench-Verwaltungstool verwaltet werden. Dies ermöglicht die Erstellung und Verwaltung von Ausführungsumgebungen in SDM.

Effiziente Leistung

Beachten Sie bei der Migration von Mainframeworkloads zu Azure, dass das Verhältnis von MIPS pro vCPU zwischen 50 und 150 MIPS pro vCPU liegt. Dies kann je nach Art der Workload variieren. Sie müssen ein Profil für die Mainframeworkload für Online- und Batchumgebungen erstellen und dann die Ressourcen entsprechend dimensionieren.

Skalierbarkeit

Derzeit besteht die Lösung zum Skalieren von SDM darin, die virtuellen Computer durch Hinzufügen von mehr vCPUs und Arbeitsspeicher hochzuskalieren.

Sicherheit

Der Zugriff auf Azure-Ressourcen wird über das Azure-Portal und/oder über Azure Resource Manager verwaltet. Die Sicherheit für SDM wird mithilfe der Tresorkomponente von SDM verwaltet. Dadurch werden die Sicherheit und die Berechtigungen von RACF oder Top Secret in eine LDAP-basierte Umgebung für die Verwaltung in Azure migriert.

Kostenoptimierung

Wenn Sie eine Kostenschätzung für Azure-Produkte und -Konfigurationen benötigen, besuchen Sie den Azure-Preisrechner.

Weitere Informationen zu den Preisen für LzLabs Software Defined Mainframe-Produkte und die zugehörigen Dienste finden Sie auf der Website von LzLabs.

Beitragende

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

Hauptautor:

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

Nächste Schritte

  • Wenden Sie sich an legacy2azure@microsoft.com, um weitere Informationen zu erhalten

Sehen Sie sich die folgenden Ressourcen aus LzLabs an:

Weitere Informationen finden Sie in der folgenden Dokumentation von Microsoft:

Weitere Informationen finden Sie in den folgenden verwandten Artikeln zum Azure Architecture Center: