Le applicazioni internet possono subire estreme fluttuazioni nell'utilizzo. Anche se la maggior parte delle applicazioni aziendali non affronta questo problema, molte devono gestire un diverso tipo di carico di lavoro con bursty, ovvero job batch o CI/CD.
Questo pattern di architettura si basa su un deployment ridondante di applicazioni in più ambienti di elaborazione. L'obiettivo è aumentare la capacità, la resilienza o entrambe.
Sebbene sia possibile gestire carichi di lavoro intensivi in un ambiente di calcolo basato su data center mediante il provisioning eccessivo delle risorse, questo approccio potrebbe non essere conveniente. Con i job batch, puoi ottimizzare l'uso estendendone l'esecuzione su periodi di tempo più lunghi, anche se ritardare i job non è pratico se sono sensibili al tempo.
L'idea del pattern di cloud bursting consiste nell'utilizzare un ambiente di computing privato per il carico di base ed eseguire temporaneamente il bursting sul cloud quando hai bisogno di capacità aggiuntiva.
Nel diagramma precedente, quando la capacità dei dati è al limite in un ambiente privato on-premise, il sistema può acquisire capacità aggiuntiva da un ambiente Google Cloud quando necessario.
I fattori chiave di questo pattern sono il risparmio di denaro e la riduzione del tempo e dello sforzo necessari per rispondere ai cambiamenti dei requisiti di scalabilità. Con questo approccio paghi solo per le risorse utilizzate per la gestione di carichi aggiuntivi. Ciò significa che non devi eseguire l'overprovisioning della tua infrastruttura. Puoi invece sfruttare le risorse cloud on demand e scalarle in base alla domanda e a qualsiasi metrica predefinita. 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 si consente il deployment dei carichi di lavoro in più ambienti, è necessario astrarre le differenze tra gli ambienti. Ad esempio, Kubernetes offre la possibilità di ottenere coerenza a livello di carico di lavoro in diversi ambienti che utilizzano infrastrutture diverse. Per ulteriori informazioni, consulta Architettura di riferimento dell'ambiente ibrido di GKE Enterprise.
Note sul layout
Il modello di cloud bursting si applica ai carichi di lavoro interattivi e batch. Quando affronti carichi di lavoro interattivi, devi però determinare come distribuire le richieste tra gli ambienti:
Puoi instradare le richieste utente in entrata a un bilanciatore del carico in esecuzione nel data center esistente e quindi fare in modo che il bilanciatore del carico 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 tenga traccia anche delle risorse allocate nel cloud. Il bilanciatore del carico o un altro sistema deve anche avviare l'upscaling o lo scale down automatici delle risorse. Utilizzando questo approccio, puoi ritirare tutte le risorse cloud durante i periodi di bassa attività. Tuttavia, l'implementazione di meccanismi per il monitoraggio delle risorse potrebbe superare le funzionalità delle soluzioni dei bilanciatori del carico e quindi aumentare la complessità complessiva.
Anziché implementare meccanismi per tenere traccia delle risorse, puoi utilizzare Cloud Load Balancing con un backend per la connettività ibrida di gruppo di endpoint di rete (NEG). Puoi utilizzare questo bilanciatore del carico per instradare richieste client interne o richieste client esterne a backend situati sia on-premise che in Google Cloud e basati su diverse metriche, come la suddivisione del traffico basata sul 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 maggiori informazioni, consulta Panoramica della gestione del traffico per il bilanciatore del carico delle applicazioni esterno globale.
Questo approccio presenta numerosi vantaggi aggiuntivi, ad esempio la possibilità di sfruttare le funzionalità di protezione DDoS di Google Cloud Armor, WAF e la memorizzazione nella cache dei contenuti a livello perimetrale del cloud mediante Cloud CDN. Tuttavia, devi dimensionare la connettività di rete ibrida per gestire il traffico aggiuntivo.
Come evidenziato in Portabilità del carico di lavoro, un'applicazione potrebbe essere portabilità in un ambiente diverso con modifiche minime per ottenere la coerenza del carico di lavoro, ma questo non significa che l'applicazione si comporti nello stesso modo in entrambi gli ambienti. Le differenze a livello di calcolo, funzionalità di sicurezza dell'infrastruttura o di rete sottostanti e la vicinanza a servizi dipendenti determinano in genere le prestazioni. Grazie ai test, puoi avere una visibilità più precisa e comprendere le aspettative di rendimento.
Puoi utilizzare i servizi dell'infrastruttura cloud per creare un ambiente in cui ospitare le applicazioni senza portabilità. Utilizza gli approcci seguenti per gestire le richieste dei client quando il traffico viene reindirizzato durante i periodi di picco della domanda:
- Utilizzare strumenti coerenti per monitorare e gestire questi due ambienti.
- Assicurarsi che il controllo delle versioni dei carichi di lavoro e le origini dati siano aggiornati.
- Potresti dover aggiungere l'automazione per eseguire il provisioning dell'ambiente cloud e reindirizzare il traffico quando la domanda aumenta e il carico di lavoro del cloud dovrebbe accettare le richieste del client per la tua applicazione.
Se intendi arrestare tutte le risorse Google Cloud durante i periodi di scarsa domanda, l'utilizzo dei criteri di routing DNS principalmente per il bilanciamento del carico del traffico potrebbe non essere sempre ottimale. Ciò è dovuto principalmente ai seguenti motivi:
- Le risorse possono richiedere un po' di tempo per essere inizializzate prima di poter essere utilizzate dagli utenti.
- Gli aggiornamenti del DNS tendono a propagarsi lentamente su internet.
Di conseguenza:
- Gli utenti potrebbero essere instradati all'ambiente Cloud anche quando non sono disponibili risorse per elaborare le loro richieste.
- Gli utenti potrebbero continuare a essere instradati all'ambiente on-premise durante la propagazione degli aggiornamenti DNS su internet.
Con Cloud DNS, puoi scegliere il criterio DNS e il criterio di routing più in linea con l'architettura e il comportamento della tua soluzione, ad esempio i criteri di routing DNS di geolocalizzazione. Cloud DNS supporta anche i controlli di integrità per il bilanciatore del carico di rete passthrough interno e il bilanciatore del carico delle applicazioni interno. In questo caso, potresti incorporarlo nella tua configurazione DNS ibrida generale basata su questo pattern.
In alcuni scenari, puoi utilizzare Cloud DNS per distribuire le richieste dei client con controlli di integrità su 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 e i controlli di integrità del DNS.
Puoi anche utilizzare l'orizzonte di suddivisione di Cloud DNS. L'orizzonte di suddivisione di Cloud DNS è un approccio per configurare risposte o record DNS per la località o la rete specifiche dell'originatore di 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 che un'esperienza pubblica, ciascuna con funzionalità uniche. Questo approccio aiuta anche a distribuire il carico del traffico tra gli ambienti.
Alla luce di queste considerazioni, il cloud bursting in genere si presta meglio ai carichi di lavoro in batch che ai carichi di lavoro interattivi.
Vantaggi
I vantaggi chiave del modello di architettura di cloud bursting includono:
- Il cloud bursting consente di riutilizzare gli investimenti esistenti in data center e ambienti di computing privati. Il riutilizzo può essere definitivo o efficace fino a quando l'apparecchiatura esistente non dovrà essere sostituita, momento in cui potrebbe essere considerata una migrazione completa.
- Poiché non devi più mantenere una capacità in eccesso per soddisfare le esigenze di picco, potresti essere in grado di aumentare l'utilizzo e l'efficienza in termini di costi dei tuoi ambienti di computing privati.
- Il cloud bursting consente di eseguire job batch in modo tempestivo senza la necessità di eseguire il provisioning eccessivo delle risorse di calcolo.
Best practice
Quando implementi il cloud bursting, considera le seguenti best practice:
- Per garantire che i carichi di lavoro in esecuzione nel cloud possano accedere alle risorse allo stesso modo dei carichi di lavoro in esecuzione in un ambiente on-premise, utilizza il pattern meshted con il principio di accesso alla sicurezza minimo. Se la progettazione del carico di lavoro lo consente, puoi consentire l'accesso solo dal cloud all'ambiente di computing on-premise, e non il contrario.
- Per ridurre al minimo la latenza per le comunicazioni tra gli ambienti, scegli una regione Google Cloud geograficamente vicina al tuo ambiente di computing privato. Per maggiori informazioni, consulta Best practice per la selezione delle regioni di Compute Engine.
- Se utilizzi il cloud bursting solo per carichi di lavoro batch, riduci la superficie di attacco alla sicurezza mantenendo private tutte le risorse Google Cloud. Non consentire alcun accesso diretto da internet a queste risorse, anche se utilizzi il bilanciamento del carico esterno di Google Cloud per fornire il punto di ingresso al carico di lavoro.
Seleziona il criterio DNS e il criterio di routing in linea con il pattern di architettura e il comportamento della soluzione di destinazione.
- Nell'ambito di questo pattern, puoi applicare il design dei tuoi criteri DNS in modo permanente o quando hai bisogno di ulteriore capacità utilizzando un altro ambiente durante i periodi di picco della domanda.
- Puoi utilizzare i criteri di routing del DNS di geolocalizzazione per avere un endpoint DNS globale per i bilanciatori del carico a livello di regione. Questa tattica ha molti casi d'uso per i criteri di routing DNS di geolocalizzazione, tra cui le applicazioni ibride che utilizzano Google Cloud insieme a un deployment 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 di suddivisione, ad esempio query da client interni ed esterni.
Per ulteriori informazioni, consulta Architetture di riferimento per il DNS ibrido
Per garantire che le modifiche al DNS vengano propagate rapidamente, configura il tuo DNS con un valore di durata (TTL) ragionevolmente breve, in modo da poter reindirizzare gli utenti ai sistemi in standby quando hai bisogno di maggiore capacità utilizzando gli ambienti cloud.
Per i job che non sono particolarmente critici e non archiviano i dati localmente, valuta la possibilità di utilizzare le istanze di VM spot, che sono molto più economiche rispetto alle normali istanze VM. Tuttavia, un prerequisito è che, se il job VM viene prerilasciato, il sistema deve essere in grado di riavviare automaticamente il job.
Utilizza i container per ottenere la portabilità dei carichi di lavoro, ove applicabile. Inoltre, GKE Enterprise può essere una tecnologia abilitante fondamentale per questa progettazione. Per maggiori informazioni, consulta Architettura di riferimento dell'ambiente ibrido di GKE Enterprise.
Monitora il traffico inviato da Google Cloud a un ambiente di computing diverso. Questo traffico è soggetto ad addebiti per il trasferimento di dati in uscita.
Se prevedi di utilizzare questa architettura a lungo termine con un volume di trasferimento di dati in uscita elevato, valuta di utilizzare Cloud Interconnect. Cloud Interconnect può aiutare a ottimizzare le prestazioni di connettività e potrebbe ridurre i costi per il trasferimento di dati in uscita per il traffico che soddisfa determinate condizioni. Per ulteriori informazioni, consulta i prezzi di Cloud Interconnect.
Se utilizzi Cloud Load Balancing, devi usare le funzionalità di ottimizzazione della capacità dell'applicazione laddove applicabile. Questo può aiutarti ad affrontare alcune delle sfide della capacità che possono verificarsi nelle applicazioni distribuite a livello globale.
Autentica le persone che utilizzano i tuoi sistemi stabilindo un'identità comune tra gli ambienti, in modo che i sistemi possano eseguire l'autenticazione sicura oltre i confini degli ambienti.
Per proteggere le informazioni sensibili, ti consigliamo vivamente di criptare tutte le comunicazioni in transito. Se è necessaria la crittografia a 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.