Le applicazioni internet possono subire fluttuazioni estreme nell'utilizzo. Sebbene la maggior parte delle applicazioni aziendali non debba affrontare questa sfida, molte aziende devono gestire un diverso tipo di carico di lavoro burst: batch o CI/CD.
Questo pattern di architettura si basa su un deployment ridondante delle applicazioni in più ambienti di computing. L'obiettivo è aumentare la capacità, la resilienza o entrambe.
Sebbene tu possa gestire carichi di lavoro burst in un ambiente di computing basato su data center eseguendo il provisioning eccessivo delle risorse, questo approccio potrebbe non essere conveniente. Con i job batch, puoi ottimizzare l'utilizzo estendendo 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 cloud bursting è quella di utilizzare un ambiente di computing privato per il carico di base e passare temporaneamente al cloud quando hai bisogno di capacità aggiuntiva.
Nel diagramma precedente, quando la capacità dei dati raggiunge il limite in un ambiente privato on-premise, il sistema può ottenere capacità aggiuntiva da un ambienteGoogle Cloud quando necessario.
I principali fattori di questo pattern sono il risparmio di denaro e la riduzione del tempo e dell'impegno necessari per rispondere alle modifiche dei requisiti di scalabilità. Con questo approccio, paghi solo le risorse utilizzate per gestire i carichi aggiuntivi. Ciò significa che non devi eseguire il provisioning eccessivo dell'infrastruttura. Puoi invece sfruttare le risorse cloud on demand e scalare 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 consenti il deployment dei carichi di lavoro in più ambienti, devi astrarre le differenze tra gli ambienti. Ad esempio, Kubernetes ti offre la possibilità di ottenere coerenza a livello di carico di lavoro in diversi ambienti che utilizzano infrastrutture diverse. Per saperne di più, consulta Architettura di riferimento dell'ambiente ibrido GKE Enterprise.
Considerazioni sulla progettazione
Il pattern di cloud bursting si applica ai carichi di lavoro interattivi e batch. 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 entrata a un bilanciatore del carico che viene eseguito nel data center esistente, 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 bilanciamento del carico o un altro sistema deve anche avviare lo scale up o lo scale down automatico 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 tue soluzioni di bilanciamento del carico e quindi aumentare la complessità complessiva.
Invece di implementare meccanismi per monitorare le risorse, puoi utilizzare Cloud Load Balancing con un backend gruppo di endpoint di rete (NEG) con connettività ibrida. Utilizzi questo bilanciatore del carico per instradare richieste client interni o richieste 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 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 saperne di più, 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, 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à del workload, un'applicazione potrebbe essere portabile in un ambiente diverso con modifiche minime per ottenere la coerenza del workload, ma ciò non significa che l'applicazione funzioni allo stesso modo in entrambi gli ambienti. Le differenze nel calcolo sottostante, nelle funzionalità di sicurezza dell'infrastruttura o nell'infrastruttura di rete, insieme alla vicinanza ai servizi dipendenti, in genere determinano le prestazioni. Grazie ai test, puoi avere una visibilità più accurata e comprendere le aspettative di 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.
- Garantisci un controllo delle versioni coerente dei workload e che le origini dati siano aggiornate.
- Potresti dover aggiungere l'automazione per eseguire il provisioning dell'ambiente cloud e reindirizzare il traffico quando la domanda aumenta e il workload cloud dovrebbe accettare le richieste dei client per la tua applicazione.
Se intendi arrestare tutte le Google Cloud risorse durante i periodi di bassa domanda, l'utilizzo di criteri di routing DNS principalmente per il bilanciamento del carico del traffico potrebbe non essere sempre ottimale. Ciò è dovuto principalmente a quanto segue:
- L'inizializzazione delle risorse può richiedere un po' di tempo prima che possano essere utilizzate dagli 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 temporaneamente all'ambiente on-premise mentre gli aggiornamenti DNS vengono propagati su internet.
Con Cloud DNS, puoi scegliere i criteri DNS e di routing che si allineano all'architettura e al comportamento della tua soluzione, ad esempio i criteri di routing DNS basati sulla 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 configurazione DNS ibrida complessiva 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 del bilanciatore del carico delle applicazioni interno, che a sua volta controlla l'integrità delle istanze di backend. Per saperne di più, consulta Gestire i criteri di routing DNS e i controlli di integrità.
Puoi anche utilizzare Cloud DNS split horizon. Lo split horizon di Cloud DNS è un approccio per configurare risposte o record DNS in base alla posizione o alla rete specifica dell'origine 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 un'esperienza privata e una pubblica, ognuna con funzionalità uniche. Questo approccio consente anche di distribuire il carico di traffico tra gli ambienti.
Tenendo conto di queste considerazioni, il cloud bursting si presta meglio ai carichi di lavoro batch che a quelli interattivi.
Vantaggi
I principali vantaggi del pattern di architettura cloud bursting includono:
- Il cloud bursting ti consente di riutilizzare gli investimenti esistenti in data center e ambienti di computing privati. Questo riutilizzo può essere permanente o in vigore fino a quando le apparecchiature esistenti non devono essere sostituite, a quel punto potresti prendere in considerazione una migrazione completa.
- Poiché non devi più mantenere la capacità in eccesso per soddisfare i picchi di domanda, potresti essere in grado di aumentare l'utilizzo e l'efficacia in termini di costi dei tuoi ambienti di computing privati.
- Il cloud bursting ti consente di eseguire i job batch in modo tempestivo senza la necessità di eseguire l'overprovisioning 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 nello stesso modo dei carichi di lavoro in esecuzione in un ambiente on-premise, utilizza il pattern mesh con il principio di accesso alla sicurezza con privilegi minimi. Se la progettazione del carico di lavoro lo consente, puoi consentire l'accesso solo dal cloud all'ambiente di computing on-premise e non viceversa.
- Per ridurre al minimo la latenza per la comunicazione tra gli ambienti, scegli una regioneGoogle Cloud geograficamente vicina al tuo ambiente di computing privato. Per maggiori informazioni, consulta Best practice per la scelta delle regioni di Compute Engine.
- Quando utilizzi il cloud bursting solo per i carichi di lavoro batch, riduci la superficie di attacco alla sicurezza mantenendo private tutte le risorse. Google Cloud Non consentire l'accesso diretto da internet a queste risorse, anche se utilizzi il bilanciamento del carico esterno Google Cloud per fornire il punto di ingresso al workload.
Seleziona i criteri DNS e di routing che corrispondono al tuo pattern di architettura e al comportamento della soluzione di destinazione.
- Nell'ambito di questo pattern, puoi applicare la progettazione dei criteri DNS in modo permanente o quando hai bisogno di capacità aggiuntiva utilizzando un altro ambiente durante i periodi di picco della domanda.
- Puoi utilizzare le policy di routing DNS basate sulla geolocalizzazione per avere un endpoint DNS globale per i tuoi bilanciatori del carico regionali. Questa tattica ha molti casi d'uso per le policy di routing DNS basate sulla geolocalizzazione, incluse 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 DNS split horizon, ad esempio query da client interni ed esterni.
Per saperne di più, consulta le architetture di riferimento per DNS ibrido.
Per garantire che le modifiche DNS vengano propagate rapidamente, configura il DNS con un valore Time To Live ragionevolmente breve, in modo da poter reindirizzare gli utenti ai sistemi di standby quando hai bisogno di capacità aggiuntiva utilizzando gli ambienti cloud.
Per i job che non sono altamente sensibili al 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 VM viene prerilasciato, il sistema deve essere in grado di riavviarlo automaticamente.
Utilizza i container per ottenere la portabilità del carico di lavoro, ove applicabile. Inoltre, GKE Enterprise può essere una tecnologia abilitante chiave per questo design. Per maggiori informazioni, consulta Architettura di riferimento dell'ambiente ibrido GKE Enterprise.
Monitora il traffico inviato da Google Cloud a un ambiente di computing 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 l'utilizzo di 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 viene utilizzato Cloud Load Balancing, devi utilizzare le relative funzionalità di ottimizzazione della capacità dell'applicazione , se applicabile. In questo modo, puoi affrontare alcune delle sfide 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 sicurezza oltre i confini dell'ambiente.
Per proteggere le informazioni sensibili, è consigliabile 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.