Aktiv/Aktiv

Multi-Tenant-Komponenten unterstützen mehrere Kunden und werden mit mehreren Replikaten über Verfügbarkeitszonen hinweg konfiguriert, um die Verfügbarkeit sicherzustellen. Diese Kategorie besteht aus den meisten watsonx.data-Komponenten. MDS ist im Enterprise-Plan aktiv-aktiv.

Nur aktiv

Single-Tenant-Komponenten in dieser Kategorie sind einem einzelnen Kunden zugeordnet. Diese Kategorie besteht aus der Presto-Engine und dem Metaspeicher. Diese Komponenten werden während eines Fehlers in einer neuen Zone erneut gestartet. MDS ist im Lite-Plan nur aktiv.

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 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

mit den Mechanismen IBM® watsonx.data können Sie Ihre Daten schützen und Dienstfunktionen wiederherstellen. Es bestehen Business-Continuity-Pläne, um die angestrebte Zielsetzung für den Wiederherstellungspunkt (Recovery Point Objective, RPO) und die Zielsetzung für die Wiederherstellungszeit (Recovery Time Objective, RTO) für den Service zu erreichen. Die folgende Tabelle gibt einen Überblick über die Ziele für watsonx.data.

Das Sicherungsintervall wird für den Dienst Milvus in SaaS reduziert, um das Wiederherstellungs-RPO von 24 Stunden auf 2 Stunden zu verbessern.

Standorte