Elevata disponibilità (HA, High Availability)

IBM® watsonx.data utilizza le regioni multizona (MZR) sia su IBM Cloud che su AWS per fornire un'elevata disponibilità. I vari componenti di watsonx.data sono distribuiti in configurazione Active-Active e Active-Only per garantire un'elevata disponibilità e resilienza.

Attivo-attivo

In una configurazione attiva-attiva, più istanze di un componente sono in esecuzione simultaneamente in diverse zone di disponibilità (AZ). Queste istanze sono bilanciate e possono gestire le richieste in parallelo.

Caratteristiche principali:

• Ridondanza - Se un'istanza o un AZ si guasta, gli altri continuano a servire il traffico senza interruzioni.
• Distribuzione del carico - Il traffico viene distribuito su tutte le istanze attive, migliorando le prestazioni e riducendo la latenza.
• Failover automatico - Non è necessario alcun intervento manuale; il sistema reindirizza il traffico automaticamente.

Vantaggi:

• Elevata tolleranza ai guasti.
• Esperienza utente senza problemi durante le interruzioni di zona.
• Migliore utilizzo delle risorse.

In watsonx.data la maggior parte dei componenti è distribuita in configurazione attiva-attiva con repliche in più zone per garantire la disponibilità continua. Ad esempio, Metadata Services (MDS) nel piano Enterprise.

Solo attivo

In una configurazione Active-Only, un componente viene eseguito in una sola Availability Zone alla volta. Se la zona si guasta, il componente deve essere riavviato o distribuito nuovamente in un'altra zona.

Caratteristiche principali:

• Singola istanza attiva per componente.
• Riavvio automatico in una nuova zona in caso di guasto.
• Leggero ritardo durante il failover dovuto al tempo di riavvio.

Vantaggi:

• Architettura più semplice.
• Riduzione del consumo di risorse.
• Resilienza con un breve tempo di inattività durante il failover.

In watsonx.data, i componenti single-tenant sono distribuiti in configurazione Active-Only. Questi componenti single-tenant, che includono il motore Presto e i componenti del metastore, sono distribuiti strategicamente su tre AZ per garantire capacità e failover. Questi componenti vengono riavviati in una nuova zona durante l'errore. Ad esempio, Metadata Services (MDS) nel piano Lite.

Nelle regioni multizona (MZR), Presto e MDS sono distribuiti in zone diverse.

Quando si verifica un malfunzionamento di una singola zona di disponibilità in un MZR o si verifica un errore hardware in una qualsiasi regione, i carichi di lavoro hanno automaticamente esito negativo e si riavviano in altre zone all'interno di tale regione. Ogni istanza watsonx.data viene fornita con un bucket di metadati interregionale predefinito e un bucket di prova facoltativo (10 GB). Entrambi i bucket sono abilitati con IBM Cloud® Object Storage Versioning. Il backup dei dati viene eseguito attivando la replica su un account IBM Cloud Object Storage separato. Tuttavia, per qualsiasi bucket esterno che il cliente porta nell'istanza watsonx.data, il cliente è responsabile di tali backup.

In un disastro regionale, ricevi un'e-mail che include tutti i passi che devi seguire. Vedi le responsabilità per watsonx.data. I componenti a singolo tenant operano su un modello 'Solo attivo', garantendo un riavvio immediato su nuovi nodi che forniscono lo stesso servizio in caso di errore.

I componenti a singolo tenant sono strategicamente distribuiti in 3 zone di sicurezza per migliorare l'affidabilità. Quando una AZ ha esito negativo, è garantita una capacità sufficiente per avviare i servizi richiesti sulle AZ disponibili. Questo riduce al minimo l'impatto causato da un'interruzione AZ.

Responsabilità

Alta disponibilità a livello di applicazione

Le applicazioni che comunicano sulle reti e i servizi cloud sono soggette ad errori di connessione temporanei. Progetta le tue applicazioni per ritentare le connessioni quando una perdita temporanea di connettività alla tua distribuzione o a IBM Cloud, causa errori. Poiché watsonx.data è un servizio gestito, gli aggiornamenti e la manutenzione regolari si verificano come parte delle normali operazioni. Tale manutenzione occasionalmente causa un'interruzione temporanea del servizio.

Le tue applicazioni devono essere progettate per gestire le interruzioni temporanee del servizio, implementare la gestione degli errori per i comandi non riusciti e implementare la logica dei tentativi per il recupero da un'interruzione temporanea.

Di seguito sono riportati alcuni dei codici di errore che potrebbero essere previsti durante le interruzioni temporanee del servizio:

Se un nodo coordinatore Presto viene riavviato, per motivi di manutenzione o a causa di un errore di sistema, le applicazioni devono ristabilire la connessione con il motore Presto.

Non sono previsti diversi minuti di indisponibilità o interruzioni della connessione. Apri un ticket di supporto con i dettagli se hai periodi di tempo più lunghi di un minuto senza connettività in modo che le interruzioni vengano esaminate.

Strategia di disaster recovery

L'obiettivo del tempo di recupero (RTO) si riferisce alla durata massima accettabile di un sistema o di un servizio che non può essere disponibile dopo un guasto. Definisce la velocità con cui il sistema deve essere ripristinato per evitare interruzioni significative delle operazioni. La RTO in watsonx.data dipende dai seguenti aspetti:

• Il punto di backup più recente.
• Stato dell'archiviazione dei registri.
• Sono necessari passaggi manuali per il ripristino dei metadati.

Il Recovery Point Objective (RPO) si riferisce alla quantità massima accettabile di perdita di dati in caso di guasto. Indica quanto indietro nel tempo il sistema può ripristinare i dati, sulla base del backup o dell'istantanea più recente che ha avuto successo. Il ripristino si basa sull'ultimo backup dei metadati e sull'ultimo archivio dei registri. Potrebbe esserci un ritardo tra il guasto e lo stato ripristinato.

Per rafforzare la resilienza dei dati e ridurre al minimo le perdite potenziali, è stata aumentata la frequenza di backup per il servizio Milvus nell'ambiente SaaS. Questa modifica riduce il Recovery Point Objective (RPO) a sole 2 ore, garantendo il ripristino dei dati da un punto molto più recente in caso di guasto.

Ubicazioni