Hochverfügbarkeit (HA)

IBM® watsonx.data verwendet Multi-Zone Regions (MZRs) sowohl auf IBM Cloud als auch auf AWS, um hohe Verfügbarkeit zu gewährleisten. Die verschiedenen Komponenten von watsonx.data werden in Active-Active- und Active-Only-Konfigurationen eingesetzt, um eine hohe Verfügbarkeit und Ausfallsicherheit zu gewährleisten.

Aktiv/Aktiv

Bei einer aktiv-aktiven Konfiguration werden mehrere Instanzen einer Komponente gleichzeitig in verschiedenen Availability Zones (AZs) ausgeführt. Diese Instanzen sind lastausgleichend und können Anfragen parallel bearbeiten.

Wesentliche Merkmale:

• Redundanz - Wenn eine Instanz oder ein AZ ausfällt, bedienen die anderen den Datenverkehr ohne Unterbrechung weiter.
• Lastverteilung - Der Datenverkehr wird auf alle aktiven Instanzen verteilt, was die Leistung verbessert und die Latenzzeit verringert.
• Automatisches Failover - Es sind keine manuellen Eingriffe erforderlich; das System leitet den Datenverkehr automatisch um.

Vorteile:

• Hohe Fehlertoleranz.
• Nahtlose Benutzererfahrung bei Zonenausfällen.
• Bessere Ressourcennutzung.

In watsonx.data werden die meisten Komponenten in einem Active-Active-Setup mit Replikaten in mehreren Zonen bereitgestellt, um eine kontinuierliche Verfügbarkeit zu gewährleisten. Zum Beispiel die Metadatendienste (MDS) im Plan Enterprise.

Nur aktiv

Bei einer Active-Only-Konfiguration läuft eine Komponente jeweils nur in einer Availability Zone. Wenn diese Zone ausfällt, muss die Komponente neu gestartet oder in einer anderen Zone neu bereitgestellt werden.

Wesentliche Merkmale:

• Eine aktive Instanz pro Komponente.
• Automatischer Neustart in einer neuen Zone bei Ausfall.
• Leichte Verzögerung beim Failover aufgrund der Neustartzeit.

Vorteile:

• Einfachere Architektur.
• Geringerer Ressourcenverbrauch.
• Ausfallsicherheit mit einer kurzen Ausfallzeit während des Failover.

Unter watsonx.data werden mandantenfähige Komponenten im Active-Only-Setup bereitgestellt. Diese Single-Tenant-Komponenten, zu denen auch die Presto Engine und Metastore-Komponenten gehören, sind aus Kapazitäts- und Failover-Gründen strategisch auf drei AZs verteilt. Diese Komponenten werden während eines Fehlers in einer neuen Zone erneut gestartet. Zum Beispiel die Metadatendienste (MDS) im Lite-Plan.

In Multi-Zone-Regionen (MZR) sind Presto und MDS auf verschiedene Zonen verteilt.

Wenn eine einzelne Verfügbarkeitszone in einem MZR ausfällt oder ein Hardwarefehler in einer Region auftritt, schlagen die Workloads automatisch fehl und werden in anderen Zonen innerhalb dieser Region erneut gestartet. Jede watsonx.data-Instanz wird mit einem regionsübergreifenden Standardmetadatenbucket und einem optionalen Testbucket (10 GB) geliefert. Beide Buckets sind mit IBM Cloud® Object Storage Versioning aktiviert. Die Daten werden durch Aktivierung der Replikation auf ein separates IBM Cloud Object Storage Konto gesichert. Für alle externen Buckets, die der Kunde in die watsonx.data-Instanz einbringt, ist der Kunde jedoch für diese Backups verantwortlich.

In einem regionalen Katastrophenfall erhalten Sie eine E-Mail mit allen Schritten, die Sie ausführen müssen. Siehe Zuständigkeiten für watsonx.data. Single-Tenant-Komponenten arbeiten mit einem Modell des Typs 'Nur aktive' und stellen einen sofortigen Neustart auf neuen Knoten sicher, die denselben Service bereitstellen, wenn ein Fehler auftritt.

Single-Tenant-Komponenten werden strategisch auf 3 AZs verteilt, um die Zuverlässigkeit zu verbessern. Wenn ein AZ ausfällt, wird ausreichend Kapazität zum Einleiten der erforderlichen Services auf den verfügbaren Verfügbarkeitszonen sichergestellt. Dies minimiert alle Auswirkungen, die durch einen AZ-Ausfall verursacht werden.

Verantwortlichkeiten

Hochverfügbarkeit auf Anwendungsebene

Anwendungen, die über Netze und Cloud-Services kommunizieren, sind temporären Verbindungsfehlern ausgesetzt. Entwerfen Sie Ihre Anwendungen so, dass Verbindungen wiederholt werden, wenn ein vorübergehender Verlust der Verbindung zu Ihrer Bereitstellung oder zu IBM CloudFehler verursacht. Da es sich bei watsonx.data um einen verwalteten Dienst handelt, sind regelmäßige Aktualisierungen und Wartungsarbeiten Teil des normalen Betriebs. Eine solche Wartung führt gelegentlich zu einer vorübergehenden Serviceunterbrechung.

Ihre Anwendungen müssen so konzipiert sein, dass sie temporäre Unterbrechungen des Service verarbeiten, die Fehlerbehandlung für fehlgeschlagene Befehle implementieren und die Wiederholungslogik implementieren, um eine Wiederherstellung nach einer temporären Unterbrechung durchzuführen.

Im Folgenden sind einige der Fehlercodes aufgeführt, die während der temporären Serviceunterbrechungen erwartet werden können:

Wenn ein Presto-Koordinatorknoten erneut gestartet wird, sei es zu Wartungszwecken oder aufgrund eines Systemfehlers, müssen Anwendungen ihre Verbindung zur Presto-Engine wiederherstellen.

Mehrere Minuten Nichtverfügbarkeit oder Verbindungsunterbrechungen sind nicht zu erwarten. Eröffnen Sie ein Support-Ticket mit Details, wenn Sie länger als eine Minute keine Verbindung haben, damit die Unterbrechungen untersucht werden können.

Disaster-Recovery-Strategie

Recovery Time Objective (RTO) bezieht sich auf die maximal akzeptable Zeitspanne, in der ein System oder ein Dienst nach einem Ausfall nicht verfügbar ist. Sie legt fest, wie schnell das System wiederhergestellt werden muss, um eine erhebliche Störung des Betriebs zu vermeiden. Die RTO auf watsonx.data hängt von den folgenden Aspekten ab:

• Der letzte Sicherungspunkt.
• Status der Protokollarchivierung.
• Manuelle Schritte für die Wiederherstellung von Metadaten erforderlich.

Das Wiederherstellungsziel (Recovery Point Objective, RPO) bezieht sich auf das maximal akzeptable Ausmaß des Datenverlusts im Falle eines Ausfalls. Sie gibt an, wie weit zurück das System Daten wiederherstellen kann, basierend auf der letzten erfolgreichen Sicherung oder dem letzten Snapshot. Die Wiederherstellung basiert auf der letzten erfolgreichen Metadatensicherung und dem Protokollarchiv. Zwischen dem Ausfall und dem wiederhergestellten Zustand kann es eine Verzögerung geben.

Um die Ausfallsicherheit der Daten zu erhöhen und mögliche Verluste zu minimieren, wurde die Häufigkeit der Datensicherung für den Dienst Milvus in der Umgebung SaaS erhöht. Durch diese Änderung wird das Wiederherstellungsziel (Recovery Point Objective, RPO) auf nur 2 Stunden reduziert, so dass die Daten im Falle eines Ausfalls von einem wesentlich aktuelleren Zeitpunkt an wiederhergestellt werden können.

Standorte