IBM DB2 pureScale in Azure

Die IBM DB2 pureScale-Umgebung bietet einen Datenbankcluster für Azure mit hoher Verfügbarkeit und Skalierbarkeit unter Linux-Betriebssystemen. In diesem Artikel wird eine Architektur zum Ausführen von DB2 pureScale in Azure gezeigt.

Übersicht

Unternehmen haben lange Zeit herkömmliche RDBMS-Plattformen (relationales Datenbank-Managementsystem) verwendet, um die jeweiligen Anforderungen der Onlinetransaktionsverarbeitung (OLTP) zu erfüllen. Heutzutage führen viele eine Migration der Mainframe-basierten Datenbankumgebungen zu Azure durch, um so die Kapazität erweitern, Kosten senken und eine stabile Betriebskostenstruktur bewahren zu können. Migration ist häufig der erste Schritt zur Modernisierung einer veralteten Plattform.

Ein Unternehmenskunde hat vor Kurzem seine IBM DB2-Umgebung unter z/OS auf einem neuen Host mit IBM DB2 pureScale in Azure verlagert. Die DB2 pureScale-Umgebung stellt eine Datenbank-Clusterlösung mit hoher Verfügbarkeit und Skalierbarkeit unter Linux-Betriebssystemen zur Verfügung. Der Kunde hat DB2 vor der Installation von DB2-pureScale als eigenständige, zentral hochskalierte Instanz auf einem einzelnen virtuellen Computer (VM) in einem großen hochskalierten System in Azure ausgeführt.

Zwar ist dies nicht mit der ursprünglichen Umgebung identisch, doch bietet IBM DB2 pureScale unter Linux ähnliche Hochverfügbarkeit und Skalierbarkeitsfeatures wie IBM DB2 für z/OS, das in einer Parallel Sysplex-Konfiguration auf dem Mainframe ausgeführt wird. In diesem Szenario ist der Cluster über iSCSI mit einem Cluster mit freigegebenem Speicher verbunden. Dabei wurde das GlusterFS-Dateisystem verwendet, ein kostenloses, skalierbares, verteiltes Open-Source-Dateisystem, das speziell für Cloudspeicher optimiert ist. Diese Lösung wird von IBM jedoch nicht mehr unterstützt. Um die Unterstützung von IBM aufrecht zu erhalten, müssen Sie ein unterstütztes iSCSI-kompatibles Dateisystem verwenden. Microsoft bietet direkte Speicherplätze (S2D) als Option an.

Dieser Artikel beschreibt die Architektur, die für diese Azure-Migration verwendet wurde. Der Kunde hat Red Hat Linux 7.4 zum Testen der Konfiguration verwendet. Diese Version ist im Azure Marketplace verfügbar. Prüfen Sie vor dem Auswählen einer Linux-Distribution die derzeit unterstützten Versionen. Ausführliche Informationen finden Sie in der Dokumentation zu IBM DB2 pureScale und GlusterFS.

Dieser Artikel dient als Ausgangspunkt für Ihren DB2-Implementierungsplan. Zwar sind Ihre Geschäftsanforderungen unterschiedlich, doch gilt das gleiche grundlegende Muster. Dieses Architekturmuster kann auch für Anwendungen zur analytischen Onlineverarbeitung (OLAP) in Azure verwendet werden.

In diesem Artikel werden weder die Unterschiede noch mögliche Migrationsaufgaben zum Verschieben einer IBM DB2 für z/OS-Datenbank zu IBM DB2 pureScale unter Linux behandelt. Es werden auch keine Schätzungen für Größenordnungen oder Workloadanalysen für den Übergang von DB2 z/OS zu DB2 PureScale bereitgestellt.

Damit Sie sich für die optimale DB2 pureScale-Architektur für Ihre Umgebung entscheiden können, wird empfohlen, eine umfassende Schätzung der Größenordnung auszuführen und eine Hypothese aufzustellen. Stellen Sie auf dem Quellsystem sicher, dass DB2 z/OS Parallel Sysplex mit Datenfreigabearchitektur, Coupling Facility-Konfiguration und Distributed Data Facility-Nutzungsstatistiken (DDF) beachtet werden.

Aufbau

Zur Unterstützung von Hochverfügbarkeit und Skalierbarkeit in Azure kann eine Architektur mit gemeinsam genutzten Daten und horizontaler Skalierung für DB2 pureScale verwendet werden. Für die Kundenmigration wurde die folgende Beispielarchitektur verwendet.

Das Diagramm zeigt die logischen Ebenen, die für einen DB2 pureScale-Cluster erforderlich sind. Dazu gehören virtuelle Computer für Client, Verwaltung, Caching, Datenbank-Engine und freigegebenen Speicher.

Zusätzlich zu den Datenbank-Engine-Knoten enthält das Diagramm zwei Knoten, die für Cluster-Caching-Funktionen (CFs) verwendet werden. Mindestens zwei Knoten werden für die Datenbank-Engine selbst verwendet. Ein DB2-Server, der zu einem pureScale-Cluster gehört, wird als „Member“ bezeichnet.

Der Cluster ist über iSCSI mit einem Cluster mit freigegebenem Speicher und drei Knoten verbunden, um Speicher für horizontale Skalierung und Hochverfügbarkeit bereitzustellen. DB2 pureScale wird auf virtuellen Azure-Computern installiert, auf denen Linux ausgeführt wird.

Dieser Ansatz ist eine Vorlage, die Sie der Größe und Skalierung Ihrer Organisation entsprechend ändern können. Sie basiert auf folgenden Voraussetzungen:

• Mindestens zwei Datenbankmember werden mit mindestens zwei CF-Knoten kombiniert. Die Knoten verwalten einen globalen Pufferpool (GBP) für freigegebenen Speicher und globale Sperren-Manager-Dienste (GLM), um den freigegeben Zugriff und Sperrkonflikte zwischen mehreren aktiven Membern zu steuern. Ein CF-Knoten fungiert als primärer Knoten und der andere als sekundärer oder CF-Failoverknoten. Zum Vermeiden eines Single Point of Failure in der Umgebung sind mindestens vier Knoten für einen DB2 pureScale-Cluster erforderlich.

• Freigegebener Hochleistungsspeicher (im Diagramm in Größe P30 dargestellt). Alle Knoten verwenden diesen Speicher.

• Hochleistungsnetzwerk für die Datenmember und freigegebenen Speicher.

Computeaspekte

Bei dieser Architektur werden die Anwendungs-, Speicher- und Datenebenen auf virtuellen Azure-Computern ausgeführt. Die Setupskripts für die Bereitstellung erstellen Folgendes:

• Einen DB2 pureScale-Cluster. Der Typ der in Azure benötigten Computeressourcen hängt von der jeweiligen Einrichtung ab. Im Allgemeinen können zwei Ansätze verwendet werden:

  • Verwendung eines Netzwerks in HPC-Ausführung (High-Performance Computing) mit mehreren Knoten, bei dem kleine bis mittlere Instanzen auf freigegebenen Speicher zugreifen. Für diesen HPC-Konfigurationstyp bieten arbeitsspeicheroptimierte virtuelle Computer der E-Serie oder L-Serie in Azure die erforderliche Computeleistung.

  • Verwendung weniger großer VM-Instanzen für die Daten-Engines. Bei großen Instanzen sind die größten speicheroptimierten virtuellen Computer der M-Serie ideal für arbeitsspeicherintensive Workloads. Je nach Größe der logischen Partition (LPAR), die zum Ausführen von DB2 verwendet wird, kann eine dedizierte Instanz erforderlich sein.

• Die DB2-CF-Instanz verwendet arbeitsspeicheroptimierte virtuelle Computer, z.B. der E-Serie oder L-Serie.

• Ein Cluster mit freigegebenem Speicher verwendet virtuelle Standard_DS4_v2-Computer, auf denen Linux ausgeführt wird.

• Die Verwaltungsjumpbox ist ein virtueller Standard_DS2_v2-Computer, auf dem Linux ausgeführt wird. Eine Alternative ist Azure Bastion, ein Dienst, der eine sichere RDP/SSH-Funktionalität für alle VMs in Ihrem virtuellen Netzwerk bereitstellt.

• Der Client ist ein virtueller Computer des Typs Standard_DS3_v2, auf dem Windows ausgeführt wird (für Tests).

• Optional: Ein Zeugenserver. Dieser ist nur bei bestimmten früheren Versionen von DB2 pureScale erforderlich. In diesem Beispiel wird ein virtueller Standard_DS3_v2-Computer verwendet, auf dem Linux ausgeführt wird (für v2 pureScale).

Speicheraspekt

Wie Oracle RAC ist auch DB2 pureScale eine Hochleistungsdatenbank mit Block-E/A und horizontaler Skalierung. Es wird empfohlen, die größte Azure Premium SSD-Option zu verwenden, die Ihren Anforderungen entspricht. Kleinere Speicheroptionen eignen sich z.B. für Entwicklungs- und Testumgebungen, während Produktionsumgebungen häufig größere Speicherkapazität erfordern. Die Beispielarchitektur verwendet P30 aufgrund des Verhältnisses von IOPS zu Größe und Preis. Verwenden Sie unabhängig von der Größe Storage Premium für eine optimale Leistung.

DB2 pureScale verwendet eine Architektur mit umfassender Freigabe, bei der von allen Clusterknoten auf alle Daten zugegriffen werden kann. Premium-Speicher muss für mehrere Instanzen freigegeben werden – ganz gleich, ob bedarfsgesteuerte oder dedizierte Instanzen.

Ein großer DB2 pureScale-Cluster kann 200 Terabyte (TB) oder mehr freigegebenen Premium-Speicher mit einem IOPS-Wert von 100.000 erfordern. DB2 pureScale unterstützt eine iSCSI-Blockschnittstelle, die in Azure verwendet werden kann. Die iSCSI-Schnittstelle erfordert einen Cluster mit freigegebenem Speicher, der mit S2D oder einem anderen Tool implementiert werden kann. Bei diesem Lösungstyp wird ein Gerät für das virtuelle Storage Area Network (vSAN) in Azure erstellt. DB2 pureScale verwendet das vSAN zum Installieren des gruppierten Dateisystems, mit dem Daten zwischen virtuellen Computern freigegeben werden.

Überlegungen zum Netzwerkbetrieb

IBM empfiehlt InfiniBand-Netzwerkfunktionen für alle Member in einem DB2 pureScale-Cluster. DB2 pureScale verwendet für die CFs außerdem Remotezugriff auf den direkten Speicher (Remote Direct Memory Access, RDMA), sofern dieser verfügbar ist.

Während des Setups erstellen Sie eine Azure-Ressourcengruppe, die dann alle virtuellen Computer enthält. Ressourcen werden allgemein auf der Grundlage ihrer Lebensdauer sowie auf der Grundlage der Benutzer gruppiert, die sie verwalten. Die virtuellen Computer in dieser Architektur erfordern beschleunigten Netzwerkbetrieb. Dies ist ein Azure-Feature, das konsistente, extrem geringe Netzwerklatenz über E/A-Virtualisierung mit Einzelstamm (Single Root I/O Virtualization, SR-IOV) für einen virtuellen Computer bietet.

Jeder virtuelle Azure-Computer wird in einem virtuellen Netzwerk mit mehreren Subnetzen bereitgestellt: Hauptsubnetz, GlusterFS-Front-End (gfsfe), GlusterFS-Back-End (bfsbe), DB2 pureScale (db2be) und DB2 pureScale-Front-End (db2fe). Das Installationsskript erstellt auch die primären NICs auf den virtuellen Computern im Hauptsubnetz.

Mithilfe von Netzwerksicherheitsgruppen werden der Netzwerkdatenverkehr innerhalb des virtuellen Netzwerks eingeschränkt und Subnetze isoliert.

In Azure muss DB2 pureScale TCP/IP als Netzwerkverbindung zum Speicher verwenden.

Nächste Schritte

• Bereitstellen dieser Architektur in Azure