Im Interview zur Hochverfügbarkeit: Ash Giddings, Maxava: „Fünf Neunen müssen es sein“

Wo beginnt die Hochverfügbarkeit (High Availability, HA) und welche Vorkehrungen im Umfeld der IBM i sind dazu nötig – auf diese Fragen hat Ash Giddings gegenüber Midrange.de (MM) Stellung bezogen. Er ist Product Manager bei Maxava und Mitglied des CEAC (IBM i Common Europe Advisory Council) sowie ein „IBM Champion“.

MM: Welche Formen von HA gibt es für IBM i?
Giddings: Damit etwas als hochverfügbar gilt, muss es „fünf Neunen“ oder 99,999 Prozent% der Zeit verfügbar sein – das bedeutet weniger als 5 Minuten Ausfallzeit pro Jahr. Bei einem höheren Wert gilt die Anwendung oder der Dienst nicht als hochverfügbar. Es gibt zwei verschiedene Arten von HA für IBM Power Systems, auf denen IBM i läuft, und diese lassen sich sauber in hardware- und softwarebasierte Lösungen einteilen. Zu den hardwarebasierten Lösungen gehören Produkte wie PowerHA oder LPM (Live Partition Mobility), die beide einen aktiven/passiven Ansatz verfolgen.

MM: Wie sieht es bei den softwarebasierten Lösungen aus?
Giddings: Die meisten softwarebasierte Lösungen, wie etwa Maxava HA, basieren fast ausschließlich auf Remote Journaling, das seit 1998 ein fester Bestandteil des IBM i-Betriebssystems ist. Remote Journaling wurde von IBM einige Jahre nach dem Local Journaling eingeführt und mit dem Ziel der Hochverfügbarkeit entwickelt, nachdem mehrere große Umgebungen begonnen hatten, diese Art von Anforderungen für kritische Anwendungen zu stellen.

MM: Was sind die wichtigsten Vor- und Nachteile von hardwarebasierten HA-Methoden?
Giddings: IBM i gehört zu den modernen Servern, und die zunehmende Nutzung externer Speicher hat dazu geführt, dass immer mehr hardwarebasierte Lösungen für die Plattform implementiert werden. PowerHA, das vor allem bei Kunden mit kleineren IBM Power Systems beliebt ist, basiert auf Clustering-Technologie und ist über ein lizenziertes Programm (5770-HAS) in das Betriebssystem integriert, um sowohl Daten als auch Anwendungen zu schützen. PowerHA basiert auf IASPs (Independent Auxiliary Storage Pools), und alle Anwendungsdaten müssen sich in einem IASP befinden, damit PowerHA sie schützen und verwalten kann. Bevor Sie PowerHA implementieren, müssen Sie daher Ihre Daten von *SYSBAS in einen IASP migrieren. Diese Aufgabe erfordert eine sorgfältige Planung und sollte in Zusammenarbeit mit Drittanbietern von Software durchgeführt werden, von denen viele Verfahren für die Durchführung dieser Migration veröffentlicht haben. Dieser umschaltbare IASP gehört dann einem der beiden Knoten im Cluster, und obwohl beide Knoten aktiv sein können, sind die Daten nur für einen verfügbar. Für PowerHA-Benutzer ist dies ein attraktives Merkmal, da Wartungsarbeiten ohne Ausfallzeiten auf dem Knoten durchgeführt werden können, der den IASP derzeit nicht besitzt.

MM: Kann alles auf einer IBM i in einem IASP untergebracht werden?
Giddings: Nein, es gibt etwa 36 Objekttypen, die nicht in einem IASP residieren können – sie müssen weiterhin in *SYSBAS liegen. Dabei werden einige dieser Objekte häufig verwendet, und dies kann eine Herausforderung für Umgebungen darstellen. Bei PowerHA gibt es ein Konzept namens Administrative Domain, in der einige dieser Objekte liegen können, allerdings nicht alle. Die administrative Domäne ist sehr einfach und weist einige Einschränkungen auf, sowohl was die Verwendung als auch die Anzahl der Objekte betrifft, die unter Wahrung der Konsistenz zwischen den Knoten im Cluster gehandhabt werden können. Möglicherweise müssen Sie auch Code für die Schnittstelle zum Verwaltungsbereich schreiben, um einige Aufgaben zu automatisieren, die der softwarebasierten Replikation immanent sind.

MM: Welche Optionen bestehen bei PowerHA?
Giddings: Zum Beispiel die geografische Spiegelung, bei der die Replikation von der IBM i selbst und nicht vom externen Speicher durchgeführt wird, und die für Umgebungen mit typischerweise weniger als 4 TByte Daten konzipiert ist. Die geografische Spiegelung ist entweder synchron, d. h. beide Kopien sind identisch, und ist für Entfernungen zwischen den Knoten von bis zu 30 Kilometern ausgelegt, oder asynchron, was für größere Entfernungen gedacht ist, allerdings auf Kosten eines weniger aktuellen Wiederherstellungspunkts. Für diejenigen, die externe Speicher verwenden, gibt es die Optionen Metro Mirror, eine synchrone Lösung, bei der beide Kopien der Daten im IASP identisch sind, und Global Mirror für diejenigen, die an bis zu drei geografisch verteilten Standorten replizieren wollen, wo größere Entfernungen eine Rolle spielen. Letzteres ist eine asynchrone Lösung.

MM: Wie lauten weitere Charakteristika von PowerHA?
Giddings: Hardware-basierte Lösungen wie PowerHA erfordern nur einen geringen täglichen Überwachungsaufwand und können eine attraktive Option für diejenigen sein, die allgemeine Vorbehalte bei der Migration ihrer Daten auf einen IASP überwunden haben. PowerHA bietet keinen Mechanismus, der es Ihnen ermöglicht, Ihre Daten auf einem anderen Knoten als dem aktuellen „Besitzer“ sichtbar zu machen, so dass Aufgaben wie Backups, Berichte oder BI auf dem Produktionsserver durchgeführt werden müssen, was sich möglicherweise auf die Systemressourcen auswirkt und Ausfallzeiten erfordert. Eine in der IBM i-Anwendergemeinschaft immer häufiger anzutreffende Kombination aus hardware- und softwarebasierten HA-Lösungen ist z. B. die Verwendung von PowerHA im Rechenzentrum zusammen mit einem softwarebasierten logischen Replikations-Tool wie Maxava HA, um eine Kopie der Daten aus dem Rechenzentrum auf eine Partition in einer Co-Location oder in der Cloud für Disaster Recovery-, Backup-, Reporting- oder BI-Zwecke zu übertragen.

MM: Was zeichnet die softwarebasierten HA-Lösungen aus?
Giddings: Software-basierte Lösungen in Form von logischer Replikation benötigen keinen externen Speicher oder IASPs, obwohl beide von Maxava HA vollständig unterstützt werden, und bauen stattdessen auf Remote Journaling auf. Dieser integrale Bestandteil des IBM i-Betriebssystems ist sowohl zuverlässig, als auch äußerst effizient. Während einige Softwarelösungen das IBM i Audit Journal (QAUDJRN) als Grundlage für die Hochverfügbarkeit nutzen, verfolgt Maxava einen anderen Ansatz. Die primäre Verwendung des Audit-Journals ist, wie der Name schon sagt, die Prüfung und Sicherheit, und die Verwendung für Hochverfügbarkeit kann unerwünschte Auswirkungen auf die Ressourcen des Quell-Servers, wie z. B. die CPU, haben. Außerdem kann das Audit-Journal in stark ausgelasteten Umgebungen ein potenzieller Engpass sein, der zu einer Verzögerung bei der Verarbeitung und Übertragung von Transaktionen führt, bevor sie auf den Zielcomputer angewendet werden, wodurch Sie möglicherweise ungeschützt bleiben.

MM: Wozu wurde Maxavas innovative Command-Intercept-Methode entwickelt?
Giddings: Sie soll einen Großteil der für die Aufrechterhaltung der Hochverfügbarkeit erforderlichen Ressourcen vom Quellserver zu entfernen, wobei der Großteil der Verarbeitung auf dem Zielserver stattfindet, weit weg von der Produktionsauslastung. Im Vergleich zu anderen softwarebasierten Hochverfügbarkeitslösungen sind die Rechenanforderungen von Maxava auf dem Quellserver vernachlässigbar. Die softwarebasierte HA-Lösung von Maxava kann so ziemlich alles auf IBM i replizieren, einschließlich Db2, IFS, IBM MQ und QDLS. Sie bietet auch die Möglichkeit, einen simulierten Rollentausch durchzuführen, bei dem der Zielserver zu Testzwecken in einen simulierten Quellserver umgewandelt wird, ohne dass dies Auswirkungen auf den Quellproduktionsrechner oder die Benutzerbasis hat. Selbstüberwachungs- und Selbstheilungselemente sind ebenfalls standardmäßig enthalten und darauf ausgelegt, die täglichen Überprüfungen durch Systemadministratoren zu minimieren.

MM: Wie unterscheiden sich der synchrone und der asynchrone Modus bei HA-Lösungen?
Giddings: Generell können softwarebasierte Lösungen entweder im synchronen oder im asynchronen Modus betrieben werden. Der synchrone Modus eignet sich normalerweise für Umgebungen, die physisch nahe beieinander liegen und in denen eine Bestätigung empfangen wird, bevor die nächste Transaktion verarbeitet wird, während der asynchrone Modus größere Entfernungen zwischen den Quell- und Zielpartitionen tolerieren kann und sich besser für Co-Location oder den Mix aus On-Prem- und Cloud-Architektur eignet. Der asynchrone Modus ist im Allgemeinen schneller, da die Übertragung der Remote-Journal-Kommunikation gleichzeitig eingeleitet wird, wobei davon ausgegangen wird, dass sie erfolgreich sein wird, und anschließend überprüft und bestätigt wird.

MM: Was ist besser?
Giddings: Die Flexibilität, die softwarebasierte HA-Lösungen bieten, liegt auf der Hand, und obwohl sie in der Vergangenheit vor Ort eingesetzt wurden, können sie auch in der Cloud, zwischen On-Premise und Cloud oder zunehmend als Motor für DRaaS in der Cloud verwendet werden. Wie auch immer Ihre aktuelle und zukünftige IBM i-Umgebung aussieht, die softwarebasierte Replikation mit Maxava HA passt.

MM: Wie sieht das Konkurrenzumfeld aus?
Giddings: Maxava HA konkurriert mit den Produkten Assure Mimix, Assure Quick EDD und Assure iTera von Precisely Holdings, LLC.

MM: Wie wirkt sich die Cloud auf HA/DR aus?
Giddings: Man kann mit Fug und Recht behaupten, dass die Cloud die Landschaft für IBM i-Workloads dramatisch verändert hat. Die meisten Unternehmen beginnen damit, Entwicklungs- oder Testpartitionen in die Cloud zu migrieren, wobei sie auf Nummer sicher gehen wollen. Da jedoch immer mehr Produktions-Workloads migriert werden, sollten Sie Ihren Ansatz in Bezug auf HA/DR anpassen, wenn Sie den Umzug in Erwägung ziehen. Trotz einer sich ständig verändernden Landschaft, in der Hardware-Replikation inzwischen gang und gäbe ist, und mit dem Aufkommen der Cloud sind Maxava HA und softwarebasierte Replikation nach wie vor die Hauptstützen der Hochverfügbarkeit. Aus diesem Grund kann die logische Replikation mit dem Lindy-Effekt beschrieben werden – je länger etwas existiert, desto länger wird es bestehen, vor allem aufgrund ihrer Fähigkeit, sich an verschiedene Epochen und die Vielfalt von Umgebungen anzupassen, die oft die Cloud beinhalten, die wir jetzt sehen.

MM: Wie ist es um die Migration in die Cloud bestellt?
Giddings: Die HA-Suite von Maxava wird nicht nur regelmäßig für Cloud-Migrationen eingesetzt, sondern läuft in der Cloud genauso effizient wie vor Ort, wobei sowohl HA- als auch DR-Optionen verfügbar sind. Um das Risiko zu minimieren, dass alle Ihre Ressourcen bei einem Cloud-Anbieter liegen, empfiehlt es sich, mehrere Anbieter zu verwenden, um Ihre Quell- und Zielpartitionen zu hosten, oder zumindest Partitionen in verschiedenen Regionen zu nutzen, die von Cloud-Anbietern regelmäßig erweitert werden. Die HA-Suite von Maxava unterstützt diese beiden Szenarien. Die meisten öffentlichen Clouds bieten ein 4-Stunden-SLA (Service Level Agreement), das sich auf die Zeitspanne bezieht, innerhalb der das physische IBM Power System, auf dem Ihre Partition gehostet wird, wiederhergestellt wird. Dabei handelt es sich um ein Hardware-SLA, das in der Regel durch eine ähnliche Vereinbarung zwischen dem Cloud-Anbieter und IBM für die Hardware sowie einen SWMA (IBM Software Maintenance Agreement) für den Support des Betriebssystems und lizenzierter Programme untermauert wird. Darüber hinaus bieten Cloud-Anbieter in der Regel Betriebszeitgarantien sowie finanzielle Entschädigungen für Zeiten, in denen die Betriebszeit unter den vereinbarten Wert fällt.

MM: Was bedeutet das für die Anwendungen?
Giddings: Im Falle eines Hardwareausfalls deckt das 4-Stunden-SLA nicht die Zeit ab, die für die Wiederherstellung Ihrer Partition benötigt wird. Sie müssen immer noch Ihre Anwendung und den Zustand, in dem sie sich zum Zeitpunkt des Ausfalls befand, sowie Elemente wie den Wiederaufbau des Zugriffspfads und die Wiederherstellung beschädigter Objekte berücksichtigen. Es ist zu beachten, dass Sie während eines Ausfalls, der Ihre Produktionsumgebung beeinträchtigt, keine Transaktionen durchführen können. Jede längere Ausfallzeit kann auch den Ruf Ihres Unternehmens schädigen. Einer der Vorteile der Cloud ist die Möglichkeit, Ihre Partition auf einem anderen Knoten zu starten. Denken Sie jedoch an die Lizenzierung von Drittanbietern, wenn Sie diese Funktion in Erwägung ziehen, da viele IBM i Softwareschlüssel mit einer Seriennummer verknüpft sind, die sich bei einem Wechsel des Knotens ändert. Um diese Probleme zu umgehen, erlauben Cloud-Provider oft Partitions-Pinning, um zu garantieren, dass Ihre Partition immer auf demselben Knoten (Seriennummer) gestartet wird.

MM: Was ist der Vorteil dieser Funktion?
Giddings: Wenn Partitions-Pinning angeboten wird, können die Cloud-Anbieter diese Ressource nicht an andere Kunden verkaufen, so dass sie Ihnen in Rechnung gestellt wird, unabhängig davon, ob Ihre Partition aktiv oder inaktiv ist. Außerdem wird dadurch einer der Vorteile der Ausführung von Arbeitslasten in der Cloud zunichte gemacht. Die virtuelle Seriennummer für IBM Power Systems ist jetzt verfügbar, obwohl es noch abzuwarten bleibt, wie Cloud-Anbieter dies annehmen werden.

MM: Welche Möglichkeiten bietet eine Cloud-Migrationsinitiative generell?
Giddings: Unternehmen können ihre HA/DR-Anforderungen neu bewerten, und der erste Schritt sollte immer darin bestehen, die nötige RTO (Recovery Time Objective) und passende RPO (Recovery Point Objective) zu ermitteln. Laienhaft ausgedrückt ist RTO die angestrebte Zeitspanne, innerhalb derer ein Geschäftsprozess nach einer Unterbrechung oder einer Katastrophe wiederhergestellt werden muss, um unannehmbare Folgen einer Unterbrechung der Geschäftskontinuität zu vermeiden. RPO ist der maximal angestrebte Zeitraum, in dem Daten aus einem IT-Dienst aufgrund eines größeren Vorfalls verloren gehen könnten. Sowohl die RTO- als auch die RPO-Zahlen müssen unbedingt zur Hand sein, wenn es darum geht, die Architektur sowie die unterstützenden Dienste und die Software für eine HA/DR-Einrichtung zu entwerfen.

MM: Wie halten Sie es mit der Kooperation mit Managed Service Providern?
Giddings: Maxava arbeitet seit langem mit MSPs (Managed Service Providern) zusammen und bietet Lösungen für ihre Power Clouds an, sei es HA zwischen zwei Partitionen, die von einem MSP gehostet werden, oder als Teil eines DRaaS-Angebots (Disaster Recovery as a Service), und erweitert diese Angebote auf Public Cloud-Anbieter wie IBMs Power Virtual Server und Skytap.

MM: Welche Rolle spielt die Live Partition Mobility?
Giddings: LPM (Logical Partition Mobility) ist Teil von PowerVM und ein Tool, das seit 2006 auf dem Markt erhältlich ist. Es ermöglicht es, Power Systems-Partitionen im aktiven Zustand von einem System auf ein anderes zu verschieben, und zwar nahtlos und ohne Ausfallzeiten und völlig transparent für die Benutzer. Es wird von allen Power Systems-Hardwaretypen ab POWER6 unterstützt und setzt unter anderem voraus, dass sich Quell- und Zielsystem im selben Netzwerk befinden, dass sie auf denselben Speicher zugreifen können und dass alle Ressourcen vollständig virtualisiert sind. LPM verschiebt alles, was mit der Partition verbunden ist, einschließlich Benutzer, virtuell angeschlossene Geräte, den Prozessorstatus und den Speicher. Diese Lösung sollte als lokale Rechenzentrumslösung und nicht als HA/DR-Lösung betrachtet werden. LPM schützt Sie nicht vor jeder Art von Datenausfall. Der Vorteil von LPM liegt in der Unterstützung geplanter Wartungsaktivitäten wie Firmware-Upgrades für das Power System oder PTF-Loads (Program Temporary Fix). Die Möglichkeit, Arbeitslasten von einem Power System auf ein anderes zu verschieben, ist unglaublich leistungsfähig und macht Ausfallzeiten für geplante Wartungsarbeiten überflüssig. In IBM i-Umgebungen wird LPM immer häufiger neben einer softwarebasierten HA-Lösung eingesetzt und nicht anstelle einer solchen.

MM: Können hier auch Drittanbieter etwas Sinnvolles beisteuern?
Giddings: Bei LPM lohnt es sich, Anwendungen von Drittanbietern in Betracht zu ziehen, da diese sowohl für die Quell- als auch für die potenziellen Ziel-Power-Systeme autorisiert werden müssen, die natürlich jeweils mit einer anderen Seriennummer laufen. Einige Anbieter berechnen für diese „sekundären“ Lizenzen den vollen Preis, während andere einen Rabatt gewähren. Wenn Sie beabsichtigen, die Arbeitslasten nur sehr selten zu verschieben, können Sie feststellen, dass die Anbieter Ihnen gerne temporäre, auf wenige Tage begrenzte Schlüssel zur Verfügung stellen.

MM: Welchen Platz nimmt Db2 Mirror for i ein?
Giddings: Db2 Mirror for i wurde mit V7R4 angekündigt und richtet sich an Umgebungen, in denen eine kontinuierliche Verfügbarkeit erforderlich ist, nicht nur eine hohe Verfügbarkeit, und bietet eine RTO (Recovery Time Objective) von Null. Db2 Mirror for i ist für zwei nahe beieinander liegende Power Systems-Knoten gedacht, auf denen IBM i läuft, und ermöglicht Anwendungen das gleichzeitige Lesen und Schreiben auf zwei Datenbanken ohne messbare Latenzzeit. Diese Fähigkeit wird durch das Betriebssystem unter Verwendung der Datenbank-Clustering-Technologie, ein lizenziertes Programm IBM Db2 Mirror for i (5770-DBM) und ein Hochgeschwindigkeits-RoCE-Kabel (RDMA over Converged Ethernet) bereitgestellt. Die Knoten können unterschiedliche Hardware-Generationen haben, und sobald die nächste Version des Betriebssystems verfügbar ist, können Sie verschiedene Versionen und Versionsstände mischen, also V7R4 und V7R5.

MM: Welche Vorteile ergeben sich daraus?
Giddings: Workloads können von einem Knoten auf einen anderen verschoben werden, wenn Sie Wartungsarbeiten durchführen müssen, wie z. B. ein Hardware-Upgrade oder ein PTF-Load, bevor der Knoten nach Abschluss der Wartungsarbeiten wieder aktiviert wird. Benutzer und Anwendungen sehen ein einziges System, und ein geplanter oder ungeplanter Ausfall hat keinerlei Auswirkungen. Aufgrund der Begrenzung des RoCE-Kabels ist Db2 Mirror for i eine Hochverfügbarkeitslösung im Rechenzentrum. Die Kombination mit einem logischen Replikationstool wie Maxava HA, das für die Replikation von Daten über große Entfernungen entwickelt wurde, ist ein weiterer Grund, warum die traditionelle Software-Replikation immer noch relevant ist und die aktiv-aktiven Umgebungen mit Db2 Mirror for i ergänzt.

MM: Was hat das Jahr 2022 für IBM i zu bieten?
Giddings: 2022 verspricht ein hochinteressantes Jahr für IBM i-Enthusiasten auf der ganzen Welt zu werden. V7R5 soll im zweiten Quartal verfügbar sein, und wenn man den jüngsten Erfahrungen Glauben schenken darf, können wir mit einem Release voller Funktionen rechnen. Darüber hinaus werden gegen Ende des zweiten Quartals die ersten Power10-Boxen erwartet. Angesichts der Leistung, Sicherheit, KI und der eingebauten Ausfallsicherheit der bereits verfügbaren IBM Power E1080 bin ich sicher, dass diese von der Community sehr gut angenommen werden. Wie bei jeder Hardware-Ankündigung wird auch der Markt für IBM Power Systems für Zweitnutzer belebt werden, die noch ältere Systeme betreiben und eine Leistungssteigerung wünschen oder auf unterstützte Hardware wie POWER9 umsteigen möchten.

MM: Welche langfristigen Trends erkennen Sie im Maxava-Umfeld?
Giddings: Es gibt einige Kunden, die ihren aktuellen Software-Tool-Stack neu bewerten. Softwarelösungen, vor allem in den Bereichen Hochverfügbarkeit und Überwachung, sind oft schon seit einigen Jahren im Einsatz und erfüllen zwar ihre Aufgabe, entsprechen aber möglicherweise nicht mehr den Anforderungen moderner, sich ständig verändernder Umgebungen und wurden im Laufe der Jahre kaum weiterentwickelt. Was früher die richtige Wahl war, muss nicht unbedingt auch heute noch die richtige Wahl sein. Darüber hinaus können durch den Wechsel von Tools erhebliche Kosteneinsparungen erzielt werden. IBM i war einst eine Insel, die auf sich allein gestellt war und nur wenige Schnittstellen zu anderen Servern oder Geschäftsfunktionen besaß und von einem speziellen Team verwaltet wurde. In den letzten Jahren hat sich IBM i zu einem modernen Server entwickelt, der in vielen Unternehmen zu einem festen Bestandteil geworden ist. Da mit jeder neuen Version mehr Open-Source-Pakete darauf portiert werden, passt er nun zu anderen Plattformen und sollte auch als solcher behandelt werden, indem dieselben Überwachungstools verwendet werden.

MM: Wie sieht ein plattformübergreifendes Tool aus?
Giddings: Der Mi8 Monitor von Maxava ist beispielsweise eine moderne Lösung, die für Plattformen wie IBM i, Linux, AIX und Windows entwickelt wurde und über eine OpenAPI-Komponente verfügt, die es einem ermöglicht, neben den genannten Plattformen buchstäblich alles zu überwachen, um einen umfassenden Überblick über Ihre unterschiedlichen Systeme zu erhalten. Die Lösung ist Cloud-basiert, wird mit schnellen Bereitstellungsmethoden geliefert und verfügt über eine integrierte Eskalation und flexible Warnmeldungen. Immer mehr IBM i-Produktions-Workloads werden in öffentliche oder MSP Power Clouds migriert, und wie nicht anders zu erwarten, vertragen diese Arten von Workloads keinerlei Ausfälle. Maxava hat Erfahrung mit Hochverfügbarkeit und bietet kurzfristige Lizenzen und Migrate Live Services an, um Kunden zu unterstützen, die Unterbrechungen vermeiden und die Datenintegrität während der Migration in die Cloud aufrechterhalten wollen. Darüber hinaus nutzen viele Unternehmen die Cloud für Disaster-Recovery-Zwecke. Wir erwarten daher, dass die Zahl der Unternehmen, die Maxava HA, den Eckpfeiler unseres DRaaS-Angebots, nutzen, weiter steigen wird. (rhh)

Maxava