Modello di cloud bursting

Last reviewed 2025-01-23 UTC

Le applicazioni internet possono registrare fluttuazioni estreme nell'utilizzo. Sebbene la maggior parte delle applicazioni aziendali non debba affrontare questo problema, molte aziende devono gestire un tipo diverso di carico di lavoro intermittente: job batch o CI/CD.

Questo pattern di architettura si basa su un deployment ridondante delle applicazioni su più ambienti di calcolo. L'obiettivo è aumentare la capacità, la resilienza o entrambe.

Sebbene tu possa gestire carichi di lavoro intermittenti in un ambiente di calcolo basato su data center tramite il provisioning eccessivo delle risorse, questo approccio potrebbe non essere economicamente conveniente. Con i job batch, puoi ottimizzare l'utilizzo allungando la loro esecuzione su periodi di tempo più lunghi, anche se ritardare i job non è pratico se sono sensibili al tempo.

L'idea del pattern di esplosione del cloud è utilizzare un ambiente di computing privato per il carico di base ed eseguire esplosioni temporanee nel cloud quando hai bisogno di una capacità aggiuntiva.

Dati che fluiscono da un ambiente on-premise a Google Cloud in modalità burst.

Nel diagramma precedente, quando la capacità di dati è al limite in un ambiente privato on-premise, il sistema può acquisire capacità aggiuntiva da un ambienteGoogle Cloud se necessario.

I fattori chiave di questo modello sono il risparmio e la riduzione del tempo e dell'impegno necessari per rispondere alle variazioni dei requisiti di scalabilità. Con questo approccio, paghi solo le risorse utilizzate per gestire i carichi aggiuntivi. Ciò significa che non è necessario eseguire il provisioning eccessivo dell'infrastruttura. In alternativa, puoi sfruttare le risorse cloud on demand e scalarle in base alla domanda e a eventuali metriche predefinite. Di conseguenza, la tua azienda potrebbe evitare interruzioni del servizio durante i periodi di picco della domanda.

Un potenziale requisito per gli scenari di cloud bursting è la portabilità dei carichi di lavoro. Quando consenti il deployment dei carichi di lavoro in più ambienti, devi eliminare le differenze tra gli ambienti. Ad esempio, Kubernetes consente di ottenere coerenza a livello di carico di lavoro in diversi ambienti che utilizzano infrastrutture diverse. Per maggiori informazioni, consulta la architettura di riferimento dell'ambiente ibrido GKE Enterprise.

Note sul layout

Il pattern di bursting sul cloud si applica ai carichi di lavoro interattivi e batch. Tuttavia, quando hai a che fare con carichi di lavoro interattivi, devi determinare come distribuire le richieste tra gli ambienti:

  • Puoi instradare le richieste degli utenti in arrivo a un bilanciatore del carico in esecuzione nel data center esistente, in modo che distribuisca le richieste tra le risorse locali e cloud.

    Questo approccio richiede che il bilanciatore del carico o un altro sistema in esecuzione nel data center esistente monitori anche le risorse allocate nel cloud. Il bilanciatore del carico o un altro sistema deve anche avviare lo scale up o lo scale down automatico delle risorse. Con questo approccio puoi ritirare tutte le risorse cloud durante i periodi di bassa attività. Tuttavia, l'implementazione di meccanismi per monitorare le risorse potrebbe superare le funzionalità delle soluzioni di bilanciamento del carico e, di conseguenza, aumentare la complessità complessiva.

  • Anziché implementare meccanismi per monitorare le risorse, puoi utilizzare il bilanciamento del carico Cloud con un backend gruppo di endpoint di rete (NEG) con connettività ibrida. Utilizza questo bilanciatore del carico per instradare richieste dei client interni o richieste dei client esterni ai backend che si trovano sia on-premise sia in Google Cloud e che si basano su metriche diverse, come la suddivisione del traffico in base al peso. Inoltre, puoi scalare i backend in base alla capacità di gestione del bilanciamento del carico per i carichi di lavoro in Google Cloud. Per ulteriori informazioni, consulta la Panoramica della gestione del traffico per il bilanciatore del carico delle applicazioni esterno globale.

    Questo approccio offre diversi vantaggi aggiuntivi, ad esempio la possibilità di sfruttare le funzionalità di protezione DDoS di Google Cloud Armor, il WAF e la memorizzazione nella cache dei contenuti all'edge del cloud utilizzando Cloud CDN. Tuttavia, devi dimensionare la connettività di rete ibrida per gestire il traffico aggiuntivo.

  • Come evidenziato in Portabilità dei carichi di lavoro, un'applicazione potrebbe essere portabile in un ambiente diverso con modifiche minime per ottenere coerenza del carico di lavoro, ma ciò non significa che l'applicazione funzioni allo stesso modo in entrambi gli ambienti. In genere, le prestazioni sono determinate dalle differenze nelle funzionalità di sicurezza dell'infrastruttura, nelle risorse di calcolo sottostanti o nell'infrastruttura di rete, nonché dalla vicinanza ai servizi dipendenti. Grazie ai test, puoi avere una visibilità più accurata e comprendere le aspettative relative al rendimento.

  • Puoi utilizzare i servizi di infrastruttura cloud per creare un ambiente per ospitare le tue applicazioni senza portabilità. Utilizza i seguenti approcci per gestire le richieste dei client quando il traffico viene reindirizzato durante i periodi di picco della domanda:

    • Utilizza strumenti coerenti per monitorare e gestire questi due ambienti.
    • Assicurati che le versioni dei carichi di lavoro siano coerenti e che le origini dati siano aggiornate.
    • Potresti dover aggiungere automazione per eseguire il provisioning dell'ambiente cloud e reindirizzare il traffico quando la domanda aumenta e il carico di lavoro cloud deve accettare le richieste dei client per la tua applicazione.
  • Se intendi arrestare tutte le Google Cloud risorse durante periodi di domanda ridotta, l'utilizzo dei criteri di routing DNS principalmente per il bilanciamento del carico del traffico potrebbe non essere sempre ottimale. Ciò accade principalmente perché:

    • L'inizializzazione delle risorse può richiedere del tempo prima che possano essere messe a disposizione degli utenti.
    • Gli aggiornamenti DNS tendono a propagarsi lentamente su internet.

    Di conseguenza:

    • Gli utenti potrebbero essere indirizzati all'ambiente Cloud anche quando non sono disponibili risorse per elaborare le loro richieste.
    • Gli utenti potrebbero continuare a essere indirizzati all'ambiente on-premise temporaneamente mentre gli aggiornamenti DNS vengono propagati su internet.

Con Cloud DNS, puoi scegliere i criteri DNS e di routing in linea con l'architettura e il comportamento della tua soluzione, ad esempio i criteri di routing DNS per la geolocalizzazione. Cloud DNS supporta anche i controlli di integrità per i bilanciatori del carico di rete passthrough interni e per i bilanciatori del carico delle applicazioni interni. In questo caso, puoi incorporarlo nella configurazione DNS ibrida complessiva basata su questo pattern.

In alcuni scenari, puoi utilizzare Cloud DNS per distribuire le richieste dei client con i controlli di integrità attivati Google Cloud, ad esempio quando utilizzi bilanciatori del carico delle applicazioni interni o bilanciatori del carico delle applicazioni interni tra regioni. In questo scenario, Cloud DNS controlla l'integrità complessiva dell'Application Load Balancer interno, che a sua volta controlla l'integrità delle istanze di backend. Per ulteriori informazioni, consulta Gestire i criteri di routing DNS e i controlli di integrità.

Puoi anche utilizzare l'orizzonte diviso di Cloud DNS. L'orizzonte diviso di Cloud DNS è un approccio per configurare le risposte o i record DNS per la posizione o la rete specifica dell'autore della query DNS per lo stesso nome di dominio. Questo approccio viene comunemente utilizzato per soddisfare i requisiti in cui un'applicazione è progettata per offrire sia un'esperienza privata sia una pubblica, ciascuna con funzionalità uniche. L'approccio contribuisce inoltre a distribuire il carico del traffico tra gli ambienti.

Date queste considerazioni, l'esplosione del cloud si presta in genere meglio ai carichi di lavoro batch rispetto a quelli interattivi.

Vantaggi

I principali vantaggi del pattern di architettura di bursting cloud includono:

  • L'esplosione del cloud ti consente di riutilizzare gli investimenti esistenti in data center e ambienti di calcolo privati. Questo riutilizzo può essere permanente o essere in vigore fino alla data di sostituzione dell'apparecchiatura esistente, a quel punto potresti prendere in considerazione una migrazione completa.
  • Poiché non devi più mantenere una capacità in eccesso per soddisfare le richieste di picco, potresti essere in grado di aumentare l'utilizzo e la convenienza economica dei tuoi ambienti di calcolo privati.
  • L'esplosione cloud ti consente di eseguire job batch in modo tempestivo senza dover eseguire il provisioning eccessivo delle risorse di calcolo.

Best practice

Quando implementi il bursting sul cloud, considera le seguenti best practice:

  • Per assicurarti che i carichi di lavoro in esecuzione nel cloud possano accedere alle risorse nello stesso modo in cui i carichi di lavoro in esecuzione in un ambiente on-premise, utilizza il modello a maglia con il principio di accesso alla sicurezza con il privilegio minimo. Se il design del carico di lavoro lo consente, puoi consentire l'accesso solo dal cloud all'ambiente di calcolo on-premise e non viceversa.
  • Per ridurre al minimo la latenza per la comunicazione tra gli ambienti, scegli una Google Cloud regione che si trovi geograficamente vicino al tuo ambiente di calcolo privato. Per maggiori informazioni, consulta Best practice per la scelta delle regioni di Compute Engine.
  • Quando utilizzi l'esplosione del cloud solo per i carichi di lavoro batch, riduci la superficie di attacco per la sicurezza mantenendo tutte le risorse Google Cloud private. Non consentire l'accesso diretto da internet a queste risorse, anche se utilizzi il Google Cloud bilanciamento del carico esterno per fornire il punto di accesso al carico di lavoro.
  • Seleziona i criteri DNS e di routing in linea con il pattern di architettura e il comportamento della soluzione di destinazione.

    • Nell'ambito di questo pattern, puoi applicare la progettazione dei tuoi criteri DNS in modo permanente o quando hai bisogno di una maggiore capacità utilizzando un altro ambiente durante i periodi di picco della domanda.
    • Puoi utilizzare i criteri di routing DNS per la geolocalizzazione per avere un endpoint DNS globale per i bilanciatori del carico regionali. Questa tattica ha molti casi d'uso per i criteri di routing DNS per la geolocalizzazione, incluse le applicazioni ibride che utilizzano Google Cloud insieme a un implementazione on-premise in cui esiste la regione Google Cloud .
    • Se devi fornire record diversi per le stesse query DNS, puoi utilizzare il DNS con orizzonte diviso, ad esempio per le query provenienti da client interni ed esterni.

      Per ulteriori informazioni, consulta le architetture di riferimento per DNS in un ambiente ibrido.

  • Per assicurarti che le modifiche DNS vengano propagate rapidamente, configura il DNS con un valore TTL ragionevolmente breve in modo da poter reindirizzare gli utenti ai sistemi di riserva quando hai bisogno di una maggiore capacità utilizzando gli ambienti cloud.

  • Per i job che non sono molto critici in termini di tempo e non archiviano dati localmente, valuta la possibilità di utilizzare istanze VM spot, che sono notevolmente più economiche delle normali istanze VM. Un prerequisito, tuttavia, è che se il job della VM viene prelevato, il sistema deve essere in grado di riavviare automaticamente il job.

  • Utilizza i container per ottenere la portabilità dei carichi di lavoro, se applicabile. Inoltre, GKE Enterprise può essere una tecnologia di base fondamentale per questo design. Per ulteriori informazioni, consulta Architettura di riferimento dell'ambiente ibrido GKE Enterprise.

  • Monitora qualsiasi traffico inviato da Google Cloud a un ambiente di calcolo diverso. Questo traffico è soggetto a costi per il trasferimento di dati in uscita.

  • Se prevedi di utilizzare questa architettura a lungo termine con un volume elevato di trasferimento di dati in uscita, valuta la possibilità di utilizzare Cloud Interconnect. Cloud Interconnect può contribuire a ottimizzare le prestazioni della connettività e potrebbe ridurre gli addebiti per il trasferimento di dati in uscita per il traffico che soddisfa determinate condizioni. Per ulteriori informazioni, consulta i prezzi di Cloud Interconnect.

  • Quando utilizzi Cloud Load Balancing, devi utilizzare le sue funzionalità di ottimizzazione della capacità dell'applicazione , ove applicabili. In questo modo, puoi risolvere alcune delle problematiche di capacità che possono verificarsi nelle applicazioni distribuite a livello globale.

  • Autentica le persone che utilizzano i tuoi sistemi stabilendo un'identità comune tra gli ambienti in modo che i sistemi possano autenticarsi in modo sicuro nei confini degli ambienti.

  • Per proteggere le informazioni sensibili, è vivamente consigliata la crittografia di tutte le comunicazioni in transito. Se è richiesta la crittografia a livello di livello di connettività, sono disponibili varie opzioni in base alla soluzione di connettività ibrida selezionata. Queste opzioni includono tunnel VPN, VPN ad alta disponibilità su Cloud Interconnect e MACsec per Cloud Interconnect.