Distribuzione a zona singola

Nelle distribuzioni a zona singola, più istanze di applicazione vengono distribuite in una zona. Se un'istanza di applicazione viene eseguita in un singolo server virtuale, i gruppi di collocamento consentono di eseguire il provisioning di questi server virtuali in host fisici separati. La funzione VPC Autoscale può essere utilizzata per consentire la regolazione dinamica della capacità in base alle variazioni del carico di lavoro. Le implementazioni a zona singola forniscono soluzioni economiche con una disponibilità dell'infrastruttura 99.9. Questa distribuzione potrebbe essere appropriata per ambienti non di produzione o per applicazioni non business critical. Tuttavia, le distribuzioni a zona singola non offrono alcuna protezione dalle interruzioni di zona.

Quando si utilizza questo modello di implementazione, è buona prassi evitare squilibri zonali. Si parla di squilibrio tra le zone quando la capacità – ad esempio, le istanze di server virtuali (VSI) di VPC – non è distribuita in modo uniforme tra le zone. Si consideri un esempio in cui un carico di lavoro viene distribuito con il 70% della propria capacità VSI nella zona 1, il 20% nella zona 2 e il 10% nella zona 3. Se la zona 1 dovesse smettere di funzionare, il carico di lavoro potrebbe continuare a essere disponibile, ma solo al 30% della sua capacità. Una soluzione consiste nell'assegnare maggiori risorse qualora si verifichi un'interruzione nella zona 1, ma tale interruzione potrebbe causare un picco anomalo della domanda di capacità nelle zone rimanenti. Una soluzione migliore consiste nell'eliminare lo squilibrio e garantire che la capacità richiesta sia distribuita tra le zone, con un margine aggiuntivo di circa il 17% in ciascuna zona per controbilanciare l'eventuale perdita di una singola zona. Ciò garantisce che il carico di lavoro rimanga disponibile e possa funzionare a piena capacità, qualora si verifichi la perdita di una zona.

Distribuzione multizona e in una singola regione

In un'implementazione multizona a regione singola, più istanze di applicazioni sono distribuite in due o più zone di disponibilità all'interno della regione. Le implementazioni multizona a regione singola possono garantire una disponibilità dell'infrastruttura fino al 99.99 % quando l'applicazione viene distribuita su tre zone di disponibilità. Questa implementazione protegge l'applicazione dai guasti a livello di zona ed è adatta a carichi di lavoro aziendali in ambiente di produzione con requisiti di disponibilità superiori al 99.9 %. La disponibilità effettiva dell'applicazione dipende dal progetto di alta disponibilità dell'applicazione.

Quando si utilizza questo modello di distribuzione, è bene evitare squilibri tra le zone. Si verifica uno squilibrio zonale quando la capacità — ad esempio, i VSI ( IBM Cloud® Virtual Servers for Virtual Private Cloud ) — non è distribuita in modo uniforme tra le zone. Si consideri un esempio in cui un carico di lavoro sia distribuito con il 70% della propria capacità VSI nella zona 1, il 20% nella zona 2 e il 10% nella zona 3. Se la zona 1 dovesse smettere di funzionare, il carico di lavoro potrebbe rimanere disponibile, ma solo al 30% della sua capacità. Si potrebbero allocare ulteriori risorse in caso di interruzione del servizio, ma un’interruzione può causare un picco anomalo della domanda di capacità nelle zone rimanenti. È invece opportuno eliminare lo squilibrio distribuendo la capacità necessaria in modo uniforme tra le zone, con un margine aggiuntivo di circa il 17% per zona, al fine di compensare l'eventuale perdita di una singola zona. Ciò garantisce che il carico di lavoro rimanga disponibile e possa funzionare a piena capacità in caso di guasto di una zona.

Distribuzione multizona e multiregione

Un'implementazione multizona e multiregione offre protezione contro le interruzioni regionali. Questa distribuzione è consigliata per applicazioni mission-critical con requisiti di disponibilità continua o quasi continua. Questa implementazione supporta anche il disaster recovery e la business continuity fuori regione per le applicazioni con requisiti geografici o di distanza di separazione specifici.

Le implementazioni multizona si basano su una replica dei dati consapevole delle applicazioni tra le zone di disponibilità e supportano modelli di architettura attivi-attivi e attivi-standby. Le implementazioni multizona e multiregione supportano i modelli di architettura per le applicazioni aziendali con disponibilità continua e requisiti always-on. Le tabelle seguenti mostrano un confronto tra le diverse opzioni di implementazione e l'uso consigliato.

Il seguente Architecture Framework fornisce considerazioni di progettazione e decisioni di architettura per l'implementazione di applicazioni resilienti sull'infrastruttura IBM Cloud Virtual Private Cloud (VPC). Copre i seguenti aspetti e ambiti di soluzione:

• Reti: Bilanciamento del carico, sistema dei nomi di dominio
• Sicurezza: Sicurezza dei dati
• Resilienza: Alta disponibilità, backup e ripristino, disaster recovery
• Gestione dei servizi: Monitoraggio, registrazione, auditing, allerte

Il Quadro di progettazione dell'architettura fornisce un approccio coerente alla progettazione di soluzioni cloud, affrontando i requisiti attraverso una serie di aspetti e domini. I domini sono aree architettoniche che devono essere prese in considerazione per qualsiasi soluzione aziendale, indipendentemente dalla tecnologia.

Logica di retry del client per applicazioni ad alta disponibilità

Siete responsabili della costruzione di applicazioni client in grado di gestire efficacemente gli errori temporanei. Gli errori temporanei comprendono errori di rete e guasti temporanei introdotti dall'implementazione dell'alta disponibilità di un servizio, come quando un servizio regionale si riprende da un guasto zonale. Per ulteriori informazioni su servizi specifici IBM Cloud, consultare la documentazione del servizio per l'alta disponibilità e il disaster recovery.

Molti degli SDK di IBM Cloud sono basati su IBM Cloud SDK Comune che supporta i tentativi automatici progettati per gestire errori specifici di HTTP, come gli errori 429 e 503. L'SDK non gestisce automaticamente tutti gli errori. Per sfruttare la logica di ripetizione, è necessario configurare correttamente l'SDK.

Alcuni servizi IBM Cloud supportano protocolli open source e può essere opportuno utilizzare SDK open source. Esaminate questi SDK per determinare se sono utili per la vostra applicazione e se offrono funzioni di ripetizione adeguate.

La logica di ripetizione varia a seconda del tipo di servizio IBM Cloud e del tipo di operazione. Alcune operazioni non andate a buon fine producono codici di stato favorevoli alla ripetizione, mentre altre producono codici di stato non favorevoli alla ripetizione. Le operazioni di lettura e HTTP GET non andate a buon fine possono generalmente essere ritentate utilizzando un backoff esponenziale con un periodo di tempo fisso. Il backoff esponenziale è una strategia di ritentativo per gestire i tentativi dopo un'operazione fallita, come una richiesta di rete o una chiamata API. Aumenta gradualmente il ritardo tra i tentativi secondo un modello esponenziale, che riduce il rischio di sovraccarico del sistema. I guasti da riprovare dipendono dal tipo di guasto e dal servizio IBM Cloud specifico. Per ulteriori informazioni, consultare l'SDK e la documentazione dei servizi IBM Cloud.

Le operazioni di scrittura, HTTP PUT, POST, DELETE e di altro tipo non possono essere recuperate utilizzando un semplice meccanismo di ripetizione, a meno che non sia chiaro che l'operazione non è stata completata e la logica documentata del client indichi che una ripetizione è appropriata. Quando un'operazione che modifica lo stato di un sistema, come la creazione di una risorsa, fallisce, spesso non è chiaro quale sia la causa del fallimento. A causa di questa incertezza, non è possibile affidarsi a una semplice logica di riprova per risolvere il problema. Utilizzare invece metodi più avanzati, progettati specificamente per il servizio IBM Cloud.

Il client retry migliora la disponibilità di un singolo client, mentre i carichi di lavoro possono essere composti da molti client. La registrazione dei guasti dei client in un servizio di log centralizzato come IBM Cloud Logs consente di analizzare i guasti e la disponibilità dell'intero carico di lavoro.