Le applicazioni internet possono subire 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 di applicazioni in più ambienti di elaborazione. L'obiettivo è aumentare la capacità, 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 ottimizzarne l'uso estendendone l'esecuzione per periodi di tempo più lunghi, anche se ritardare i job non è pratico se sensibili.
L'idea del pattern di cloud bursting è quella di utilizzare un servizio di computing privato dell'ambiente per il carico di base ed eseguire temporaneamente il burst sul cloud quando richiedono 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 principali fattori alla base di questo modello sono il risparmio di denaro e la riduzione dei tempi e per rispondere alle modifiche dei requisiti di scalabilità. Con questo approccio, paghi solo per le risorse utilizzate per la gestione di carichi extra. Ciò significa che l'overprovisioning della tua infrastruttura. Puoi usufruire invece risorse cloud on demand e scalarle in base alla domanda e a qualsiasi metrics. Di conseguenza, la tua azienda potrebbe evitare interruzioni del servizio durante i periodi di picco in base ai tempi 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 astrae le differenze tra gli ambienti. Ad esempio, Kubernetes consente di ottenere coerenza a livello di carico di lavoro ambienti diversi che usano infrastrutture diverse. Per ulteriori informazioni le informazioni, vedi 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 hai a che fare con carichi di lavoro interattivi, ma devi stabilire 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 poi fare in modo che il bilanciatore del carico distribuisca delle richieste alle 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. Anche il bilanciatore del carico o un altro sistema deve avviano automaticamente l'upscaling o il downscaling delle risorse. Utilizzo di questo è possibile ritirare tutte le risorse cloud nei periodi di attività. Tuttavia, l'implementazione di meccanismi per monitorare le risorse può superare le capacità delle soluzioni dei bilanciatori del carico e, di conseguenza, aumentano e la complessità generale.
Invece di implementare meccanismi per monitorare le risorse, puoi utilizzare Cloud Load Balancing con una connettività ibrida Gruppo di endpoint di rete (NEG) backend. Puoi utilizzare questo bilanciatore del carico per il routing richieste del client interne o richieste di client esterne ai backend situati sia on-premise che Google Cloud e che si basano su diverse metriche, suddivisione del traffico basata sulle ponderazioni. 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, vedi Panoramica della gestione del traffico per il bilanciatore del carico delle applicazioni esterno globale.
Questo approccio offre numerosi vantaggi aggiuntivi, tra cui l'utilizzo di Funzionalità di protezione DDoS di Google Cloud Armor, WAF e la memorizzazione nella cache del contenuto a livello perimetrale del cloud 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ù precisa e comprendere le tue aspettative di 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 del cloud dell'ambiente e reindirizzano il traffico quando la domanda aumenta e il cloud deve accettare richieste del client per la tua applicazione.
Se intendi arrestare tutte le risorse Google Cloud durante in tempi di domanda ridotta, usando principalmente criteri di routing DNS per il bilanciamento del carico del traffico potrebbe non essere sempre ottimale. Questo è principalmente perché:
- Le risorse possono richiedere un po' di tempo per essere inizializzate e offrire il servizio agli utenti.
- Gli aggiornamenti del DNS tendono a propagarsi lentamente su internet.
Di conseguenza:
- Gli utenti potrebbero essere indirizzati all'ambiente Cloud anche quando risorse a disposizione per elaborare le loro richieste.
- Gli utenti potrebbero continuare a essere indirizzati all'ambiente on-premise temporaneamente durante la propagazione degli aggiornamenti DNS su internet.
Con Cloud DNS puoi scegliere Criterio DNS e criteri di routing in linea con l'architettura e il comportamento della tua soluzione, come criteri di routing DNS con geolocalizzazione. Cloud DNS supporta anche i controlli di integrità per il bilanciatore del carico di rete passthrough interno. il bilanciatore del carico delle applicazioni interno. In questo caso, potresti incorporarlo nel tuo insieme configurazione del DNS ibrida basata su questo pattern.
In alcuni scenari, puoi utilizzare Cloud DNS per distribuire i client con controlli di integrità su Google Cloud, ad esempio quando di bilanciatori del carico delle applicazioni interni 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, vedi Gestire i criteri di routing del DNS e i controlli di integrità.
Puoi anche utilizzare Orizzonte di suddivisione di Cloud DNS. L'orizzonte diviso di Cloud DNS è un approccio per configurare il DNS risposte o record alla località o alla rete specifica della query DNS per lo stesso nome di dominio. Questo approccio è comunemente utilizzato soddisfare i requisiti qualora un'applicazione sia progettata per offrire privata e pubblica, ognuna con caratteristiche uniche. L'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 in batch invece che a 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 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 il cloud bursting, 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.
- Se utilizzi il cloud bursting solo per carichi di lavoro batch, riduci la sicurezza e la superficie di attacco 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 il criteri DNS e di routing che sia in linea con il modello di architettura e il comportamento della soluzione target.
- Nell'ambito di questo pattern, puoi applicare il design del tuo DNS in modo permanente o quando hai bisogno di ulteriore capacità utilizzando un altro dell'ambiente nei periodi di picco della domanda.
- Puoi utilizzare i criteri di routing del DNS di geolocalizzazione per avere un Endpoint DNS per i bilanciatori del carico a livello di regione. Questa tattica ha molte casi d'uso per i criteri di routing dei DNS di geolocalizzazione, incluse applicazioni ibride che utilizzano Google Cloud insieme il deployment on-premise dove 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 estremamente critici e che non archiviano i dati localmente, valuta la possibilità di utilizzare istanze VM spot, che sono notevolmente più economiche rispetto alle 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 il traffico inviato da Google Cloud a un'altra nell'ambiente di computing. Questo traffico è soggetto a addebiti per il trasferimento di dati in uscita.
Se prevedi di utilizzare questa architettura a lungo termine con un elevato volume di dati in uscita per il volume di trasferimento, considera l'uso di 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 conditions. Per ulteriori informazioni, vedi Prezzi di Cloud Interconnect.
Quando utilizzi Cloud Load Balancing, devi usare i suoi delle funzionalità di ottimizzazione della capacità dell'applicazione dove applicabile. Questo può aiutarti ad affrontare alcune delle sfide della capacità che possono verificarsi in 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.