Protezione del piano dati del servizio dagli errori del piano di controllo

L'architettura del servizio IBM Cloud separa i componenti per il piano dati e il piano di controllo.

I componenti del piano dati sono responsabili della fornitura delle funzioni primarie del servizio. I componenti del piano dati elaborano le richieste degli utenti e delle applicazioni client, ad esempio implementando l'elaborazione dei dati, la persistenza, il bilanciamento del carico e altro ancora.

Ad esempio, le responsabilità del piano dati sono le seguenti:

• Esecuzione e hosting dell'istanza del server virtuale (VSI)
• Lettura e scrittura su volumi di archiviazione a blocchi
• Ottenere e impostare gli oggetti nei bucket Object Storage
• Esecuzione, elaborazione di query e aggiornamenti su IBM Cloud Databases for PostgreSQL

I componenti del piano di controllo sono responsabili dell'amministrazione e della configurazione dei componenti del piano dati. I componenti del piano di controllo elaborano le richieste degli amministratori per gestire il ciclo di vita del piano dati attraverso le fasi di creazione, configurazione, aggiornamento e dismissione delle istanze di servizio.

Ad esempio, le responsabilità del piano di controllo sono le seguenti:

• Elencare il VSI nell'account e fare il provisioning di un nuovo VSI, orchestrando la creazione di macchine virtuali da un'immagine del sistema operativo, la creazione di storage a blocchi, il collegamento e la configurazione degli endpoint di rete
• Configurazione, ridimensionamento e montaggio dei volumi di archiviazione a blocchi
• Creazione di nuovi bucket Object Storage

Per migliorare la resilienza e la continuità operativa, i piani dati dei servizi sono progettati per continuare a svolgere la loro funzione primaria anche in caso di guasti del piano di controllo. Ad esempio, l'accesso del piano dati alle risorse dell'infrastruttura, quando viene effettuato il provisioning, non dipende dal piano di controllo e quindi non è influenzato da alcun problema del piano di controllo.

I guasti del piano di controllo possono influire sulla capacità di creare, modificare o eliminare risorse, ma non hanno alcun impatto sulle risorse esistenti che rimangono disponibili.

Indipendenza del servizio zonale

I servizi zonali consentono di richiedere istanze di servizio da distribuire in una zona specifica di una regione multizona o in un centro dati specifico.

Queste istanze di servizio distribuite in una zona specifica o in un centro dati specifico sono implementate e gestite in modo indipendente all'interno della propria regione, senza dipendere da componenti dei servizi in altre zone o centri dati. Pertanto, i guasti in una zona possono avere un impatto sull'istanza ospitata in quella zona, ma non su nessuna istanza in altre zone della stessa regione o di altre regioni.

Le architetture di servizio zonali utilizzano un piano dati zonale distribuito in ogni zona di una regione e gestito dal componente del piano di controllo locale della regione.

L'utente o l'applicazione interagisce con la funzione di istanza del servizio utilizzando un endpoint API zonale situato in ciascuna zona di destinazione.

Il piano di controllo del servizio, con alcune eccezioni descritte in Ridondanza globale del servizio, è situato nella stessa regione del piano dati e distribuito in 3 zone delle regioni. È indipendente dai piani di controllo di altre regioni. Pertanto, un guasto del piano di controllo in una regione potrebbe avere un impatto solo sulle funzioni di servizio in quella regione, ma non sulle funzioni di servizio in altre regioni.

Se si verifica un guasto del piano di controllo in una zona o se una zona non è disponibile, le richieste dell'amministratore per gestire le fasi del ciclo di vita del piano dati, come la creazione, la configurazione, l'aggiornamento e la disattivazione delle risorse, vengono eseguite dal piano di controllo nelle due zone rimanenti.

Nei casi eccezionali in cui il piano di controllo è distribuito a livello globale, viene comunque distribuito in più regioni per garantire un'elevata disponibilità. Pertanto, i guasti in una regione non influirebbero sulle funzioni del servizio nelle altre regioni.

Per ulteriori informazioni sulle opzioni specifiche di distribuzione dei carichi di lavoro che utilizzano un servizio zonale, vedere Posizioni per la distribuzione delle risorse e Considerazioni sull'alta disponibilità.

Ridondanza del servizio regionale

I servizi regionali consentono di richiedere istanze di servizio da distribuire in una regione specifica nel suo complesso, senza specificare una singola zona o centro dati di destinazione.

Queste istanze di servizio distribuite in una regione sono implementate e gestite con componenti ridondanti distribuiti in più zone all'interno della stessa regione. In questo modo, non esiste un singolo punto di guasto in una zona specifica all'interno di una regione.

L'architettura del servizio regionale utilizza un piano dati regionale distribuito su 3 zone in ogni regione e gestito dal piano di controllo locale nella regione. Se si verifica un guasto del piano dati in una zona o se una zona non è disponibile, le richieste degli utenti e delle applicazioni client vengono automaticamente reindirizzate al piano dati delle altre due zone.

L'utente o l'applicazione interagisce con la funzione di istanza del servizio utilizzando un endpoint API regionale che si trova in ogni regione di destinazione.

Il piano di controllo del servizio, con alcune eccezioni descritte in Ridondanza globale del servizio, è situato nella stessa regione del piano dati e distribuito in 3 zone delle regioni, indipendente dai piani di controllo delle altre regioni. In questo modo, i guasti del piano di controllo in una regione potrebbero avere un impatto solo sulle funzioni di servizio in quella regione e non sulle funzioni di servizio in altre regioni.

In caso di guasto del piano di controllo in una zona, o addirittura di perdita completa, la richiesta degli amministratori di gestire il ciclo di vita del piano dati attraverso le fasi di creazione delle risorse, configurazione, aggiornamento e dismissione delle istanze di servizio viene eseguita dal piano di controllo sulle zone rimanenti.

Anche nei casi eccezionali in cui il piano di controllo è distribuito a livello globale, viene comunque distribuito in più regioni per contribuire ad assicurare un'elevata disponibilità e garantire che i guasti in una regione non abbiano un impatto sulle funzioni di servizio in altre regioni.

Per ulteriori informazioni sulle opzioni specifiche per la distribuzione dei carichi di lavoro che utilizzano un servizio regionale, vedere Posizioni per la distribuzione delle risorse e Considerazioni sull'alta disponibilità.

Ridondanza globale del servizio

Un sottoinsieme di servizi IBM Cloud utilizza un modello di distribuzione globale con componenti distribuiti in più regioni in luoghi e aree geografiche diverse. Questi servizi forniscono funzioni comuni da cui dipendono altri servizi zonali o regionali. Esistono anche componenti specifici del piano di controllo all'interno di un servizio che forniscono funzioni globali.

I servizi che utilizzano un modello di distribuzione globale implementano un'architettura distribuita con componenti replicati in più regioni. I componenti sono bilanciati su queste regioni con un design di failover automatico per mantenere i servizi attivi e funzionanti senza l'intervento di un operatore.

Le sezioni seguenti illustrano i servizi che utilizzano un modello di distribuzione globale e il loro impatto interregionale sulle dipendenze da altri servizi zonali o regionali.

Questo approccio aiuta a eliminare i singoli punti di guasto nell'architettura, ma potrebbe rappresentare un potenziale impatto interregionale, anche quando si opera in una regione diversa da quella in cui è ospitato il piano di controllo del servizio globale.

Ridondanza della dorsale di rete

La rete IBM Cloud è progettata in modo tale che non si verifichi mai un singolo punto di guasto. In ogni punto della rete esiste una connettività diversificata e ridondante, grazie all'utilizzo di diversi fornitori di telecomunicazioni per lo stesso servizio di connettività, quando possibile all'interno di ogni regione.

IBM Cloud utilizza diversi fornitori di fibra oscura per collegare i siti edge a tutte le strutture di calcolo regionali. Inoltre, ogni sito edge dispone di una dorsale ridondante di connettività verso altre regioni e di peer con più provider, direttamente e indirettamente attraverso una centrale locale.

Isolamento dei servizi zonali e regionali dalle dipendenze interregionali

In generale, se un evento ha un impatto sulla disponibilità in una regione, solo i servizi zonali e regionali di quella regione ne risentono. I servizi nelle altre regioni non sono interessati.

I piani dati dei servizi zonali e regionali si basano su risorse all'interno della stessa regione, comprese le dipendenze essenziali come l'infrastruttura, l'orchestrazione dei container, i database, la sicurezza e altro ancora.

Il piano dati di un servizio che si trova in una regione dipende anche dalle istanze di servizio fornite dall'utente per supportare le seguenti funzioni da servizio a servizio:

• istanza Key Protect per il supporto della crittografia bring-your-own-key (BYOK).
• istanza di Hyper Protect Crypto Services per il supporto della crittografia keep-your-own-key (KYOK).
• i bucket Object Storage per l'archiviazione dei backup, delle prove e dei risultati Control Center della sicurezza, dei registri archiviati e così via, e in generale per qualsiasi funzione che supporti l'archiviazione o l'elaborazione di grandi quantità di dati nei o dai bucket Object Storage.

Selezionare con cura la regione di assegnazione del servizio per garantire la disponibilità. Si raccomanda di collocare i servizi nella stessa regione dei servizi dipendenti per evitare l'impatto di un guasto interregionale.

La documentazione di ogni servizio fornisce chiare indicazioni su come utilizzarli, sulle scelte di localizzazione e configurazione, sull'architettura delle applicazioni per il livello di resilienza desiderato.