Le applicazioni internet possono riscontrare estreme fluttuazioni nell'utilizzo. Sebbene la maggior parte le applicazioni aziendali non affrontano questa sfida, molte aziende devono con un diverso tipo di carico di lavoro bursty: 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 sia possibile gestire carichi di lavoro intensivi in un ambiente di computing basato su data center di overprovisioning delle risorse, questo approccio potrebbe non essere un costo efficace. 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.
Nel diagramma precedente, quando la capacità dei dati è al limite in un ambiente on-premise in un ambiente privato, il sistema può acquisire capacità aggiuntiva dell'ambiente Google Cloud quando 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 l'overprovisioning della tua 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 per 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. Quando hai a che fare con carichi di lavoro interattivi, ma devi stabilire 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 il bilanciatore del carico o un altro sistema in esecuzione nel data center esistente per monitorare anche le risorse allocati 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 tue soluzioni di bilanciamento del carico e, di conseguenza, aumentare la complessità complessiva.
Invece di implementare meccanismi per monitorare le risorse, puoi utilizzare Cloud Load Balancing con una connettività ibrida Gruppo di endpoint di rete (NEG) di un backend cloud. Utilizza questo bilanciatore del carico per inoltrare 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. Puoi anche scalare i backend in base 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 traffico aggiuntivo.
Come evidenziato in Portabilità del carico di lavoro, il deployment di un'applicazione portabilità in un ambiente diverso con modifiche minime da raggiungere la coerenza del carico di lavoro, ma questo non significa che l'applicazione la stessa in entrambi gli ambienti. Differenze nell'elaborazione di base, le funzionalità di sicurezza dell'infrastruttura o l'infrastruttura di rete, vicinanza a servizi dipendenti, in genere determinano le prestazioni. Grazie ai test, puoi avere una visibilità più accurata e comprendere le aspettative relative al rendimento.
Puoi utilizzare i servizi dell'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:
- Utilizzare strumenti coerenti per monitorare e gestire questi due ambienti.
- Garantisci un controllo delle versioni coerente dei carichi di lavoro e che le origini dati sono attuali.
- 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 cloud dovrebbe accettare le richieste dei client per la tua applicazione.
Se intendi arrestare tutte le risorse Google Cloud durante periodi di bassa domanda, 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 il bilanciatore del carico di rete passthrough interno e per il bilanciatore del carico delle applicazioni interno. 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à 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 il bilanciatore del carico delle applicazioni 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à di DNS.
Puoi anche utilizzare orizzonte di suddivisione 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 cloud si presta in genere meglio ai carichi di lavoro batch rispetto a quelli interattivi.
Vantaggi
I vantaggi chiave del modello di architettura di cloud bursting includono:
- Il cloud bursting consente di riutilizzare gli investimenti esistenti nei data center e ambienti di computing privati. Il riutilizzo può essere permanente o finché non sarà prevista la sostituzione dell'apparecchiatura esistente, puoi prendere in considerazione una migrazione completa.
- Perché non è più necessario mantenere la capacità in eccesso per soddisfare i picchi richieste, potresti essere in grado di aumentare l'uso e la convenienza dei nei tuoi ambienti di computing privati.
- Il cloud bursting consente di eseguire job batch in modo tempestivo senza necessarie per l'overprovisioning delle risorse di computing.
Best practice
Quando implementi l'esplosione cloud, considera le seguenti best practice:
- Per garantire che i carichi di lavoro in esecuzione nel cloud possano accedere alle risorse in come i carichi di lavoro eseguiti in un ambiente on-premise, il motivo mesh con il principio di accesso di sicurezza con privilegi minimi. Se la progettazione dei carichi di lavoro lo consente, tu puoi consentire l'accesso di computing on-premise, e non il contrario.
- Per ridurre al minimo la latenza per le comunicazioni tra ambienti, scegli un'opzione Regione Google Cloud geograficamente vicino al tuo ambiente di computing privato. Per ulteriori informazioni, vedi Best practice per la selezione delle regioni di Compute Engine.
- Quando utilizzi l'esplosione cloud solo per i carichi di lavoro batch, riduci la superficie di attacco della sicurezza mantenendo private tutte le risorse Google Cloud. Non consentire alcun accesso diretto a queste risorse da internet, anche se stai utilizzando il bilanciamento del carico esterno di Google Cloud per fornire 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 il design 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 scenari di utilizzo per i criteri di routing DNS basati sulla 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 lo stesso DNS puoi usare il DNS a orizzonte di suddivisione, ad esempio query sia interni che esterni.
Per ulteriori informazioni, vedi architetture di riferimento per DNS ibrido
Per assicurarti che le modifiche al DNS vengano propagate rapidamente, configura il DNS con un numero ragionevolmente breve valore della durata in modo da poter reindirizzare gli utenti ai sistemi in standby quando hai bisogno di utilizzando ambienti cloud.
Per i job che non sono molto critici in termini di tempo e non memorizzano dati localmente, valuta la possibilità di utilizzare istanze VM spot, che sono notevolmente più economiche delle normali istanze VM. Prerequisito se il job VM viene prerilasciato, il sistema deve essere in grado di riavvia automaticamente il job.
Utilizza i container per ottenere la portabilità dei carichi di lavoro, ove applicabile. Inoltre, GKE Enterprise può essere una tecnologia chiave che abilita questo la progettazione. Per ulteriori informazioni, vedi Architettura di riferimento dell'ambiente ibrido di GKE Enterprise.
Monitora qualsiasi traffico inviato da Google Cloud a un altro ambiente di calcolo. Questo traffico è soggetto a addebiti 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ò aiutare a ottimizzare le prestazioni di connettività e ridurre i costi per il trasferimento di dati in uscita per il traffico che soddisfa determinati le condizioni di traffico. Per maggiori informazioni, consulta i prezzi di Cloud Interconnect.
Quando utilizzi Cloud Load Balancing, devi usare i suoi delle funzionalità di ottimizzazione della capacità dell'applicazione dove applicabile. 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 Creazione di un'identità comune tra gli ambienti in modo che i sistemi possano eseguire l'autenticazione sicura confini ambientali.
Per proteggere le informazioni sensibili, crittografando tutte le comunicazioni in il trasporto pubblico è vivamente consigliato. Se è richiesta la crittografia di connettività, sono disponibili varie opzioni in base soluzione di connettività ibrida. Queste opzioni includono tunnel VPN, VPN ad alta disponibilità su Cloud Interconnect e MACsec per Cloud Interconnect.