Il modello di architettura multi-cloud partizionato combina più istanze gestiti da diversi provider di servizi cloud. Questo offre la flessibilità necessaria per eseguire il deployment di un'applicazione di computing che tiene conto i driver multi-cloud e le considerazioni discusse nella prima parte di questo Google Cloud.
Il seguente diagramma mostra un'architettura multi-cloud partizionata pattern.
Questo modello di architettura può essere creato in due modi diversi. Il primo approccio si basa sul deployment dei componenti dell'applicazione in diversi cloud pubblico ambienti cloud-native. Questo approccio è anche noto come architettura composita ed è lo stesso approccio utilizzato modello di architettura ibrida a più livelli. Invece di utilizzare un ambiente on-premise con un servizio cloud, tuttavia, utilizza almeno due ambienti cloud. In un elemento composito un'architettura, un singolo carico di lavoro o una singola applicazione utilizza componenti in un solo cloud. Il secondo approccio esegue il deployment di diverse applicazioni ambienti cloud pubblico. Il seguente elenco non esaustivo descrive alcuni dei fattori che favoriscono l'attività secondo approccio:
- Per integrare completamente le applicazioni ospitate in ambienti cloud disparati nel corso di uno scenario di fusione e acquisizione tra due imprese.
- Per promuovere la flessibilità e soddisfare le diverse preferenze del cloud all'interno dell'organizzazione. Adotta questo approccio per incoraggiare le unità organizzative a scegliere il cloud provider più adatto alle sue esigenze specifiche preferenze.
- Operare in un deployment multiregionale o globale. Se di un'azienda è tenuta ad aderire alle normative sulla residenza dei dati in regioni o paesi, dovrà scegliere tra quelli disponibili dai provider di servizi cloud in quella località se il loro cloud provider principale non una regione cloud.
Con il pattern dell'architettura multi-cloud partizionata, puoi facoltativamente hanno la possibilità di spostare i carichi di lavoro in base alle esigenze da un cloud pubblico ambiente a un altro. In questo caso, la portabilità dei carichi di lavoro diventa un requisito chiave. Quando esegui il deployment dei carichi di lavoro in più ambienti di computing, e vuoi mantenere la capacità di spostare i carichi di lavoro tra gli ambienti, devono astrarre le differenze tra gli ambienti. Utilizzando GKE Enterprise, puoi progettare e creare una soluzione complessità multi-cloud con governance, operazioni e sicurezza coerenti le posture. Per ulteriori informazioni, vedi GKE Multi-Cloud.
Come detto in precedenza, in alcune situazioni potrebbero verificarsi per motivi aziendali e tecnici per combinare Google Cloud con un altro cloud del cloud privato e di partizionare i carichi di lavoro tra questi ambienti cloud. Soluzioni multi-cloud offrono la flessibilità necessaria per migrare, creare e ottimizzare le applicazioni la portabilità in ambienti multi-cloud, riducendo al minimo i vincoli e aiutando per soddisfare i requisiti normativi. Ad esempio, connettere Google Cloud a Oracle Cloud Infrastructure (OCI) per creare una soluzione multi-cloud che sfrutti le funzionalità di ogni di Google Cloud utilizzando una connessione Cloud Interconnect privata per combinare i componenti in esecuzione OCI con risorse in esecuzione su Google Cloud. Per ulteriori informazioni, vedi Google Cloud e Oracle Cloud Infrastructure: sfruttare al meglio il multi-cloud. Inoltre, Cross-Cloud Interconnect facilita la connettività dedicata a elevata larghezza di banda tra Google Cloud e altro provider di servizi cloud supportati, che ti consente di progettare e creare soluzioni multi-cloud per gestire volume di traffico tra cloud.
Vantaggi
L'utilizzo di un'architettura multi-cloud offre numerosi vantaggi vantaggi, come spiegato in Fattori chiave, considerazioni, strategia e approcci, è essenziale eseguire una valutazione dettagliata di fattibilità vantaggio. La valutazione deve considerare attentamente tutti i fattori diretti o indiretto sfide o potenziali ostacoli e la tua capacità di gestirli in modo efficace. Inoltre, tieni presente che la crescita a lungo termine delle tue applicazioni o dei tuoi servizi può possono introdurre complessità che potrebbero superare i vantaggi iniziali.
Ecco alcuni vantaggi chiave dell'architettura multi-cloud partizionata motivo:
In scenari in cui potrebbe essere necessario ridurre al minimo l'impegno puoi distribuire le applicazioni su più cloud di Google Cloud. Di conseguenza, potresti ridurre relativamente i vincoli al fornitore utilizzando la possibilità di cambiare piano (in una certa misura) tra i vari cloud provider. Cloud aperto aiuta a integrare le funzionalità di Google Cloud, come di GKE Enterprise in località fisiche diverse. Di l'estensione delle funzionalità di Google Cloud on-premise, in più aree cloud e a livello perimetrale, offre flessibilità, agilità e promuove la trasformazione.
Per motivi normativi, puoi pubblicare annunci per un determinato segmento di utenti e i dati di un paese in cui Google Cloud non dispone di regione cloud.
Il modello di architettura multi-cloud partizionata può aiutare a ridurre latenza e migliorare la qualità complessiva dell'esperienza utente nelle località in cui il cloud provider principale non abbia una regione cloud o punto di presenza. Questo pattern è particolarmente utile quando si utilizzano alta capacità e bassa latenza la connettività multi-cloud, come Cross-Cloud Interconnect e Interconnessione CDN con una rete CDN distribuita.
Puoi eseguire il deployment delle applicazioni su più cloud provider in modo che ti permette di scegliere tra i migliori servizi che gli altri cloud provider offerta.
Il modello di architettura multi-cloud partizionata può facilitare e accelerare gli scenari di fusione e acquisizione, in cui le applicazioni e delle due aziende potrebbero essere ospitati in diversicloud pubblicoi, ambienti cloud-native.
Best practice
- Per iniziare, esegui il deployment di un carico di lavoro non mission critical. Questa iniziale il deployment nel cloud secondario può fungere da modello per il futuro, deployment o migrazioni. Tuttavia, questo approccio probabilmente non è applicabile in situazioni in cui il carico di lavoro specifico è legalmente o regolamentato devono risiedere in una specifica regione cloud, mentre il cloud Il provider non dispone di una regione nel territorio richiesto.
- Riduci al minimo le dipendenze tra sistemi in esecuzione in diversi in ambienti cloud pubblico, in particolare quando la comunicazione in modo sincrono. Queste dipendenze possono rallentare le prestazioni e diminuire in generale e potrebbero incorrere in costi aggiuntivi per il trasferimento di dati in uscita.
- Per astrarre le differenze tra gli ambienti, valuta la possibilità di utilizzare i container e Kubernetes, laddove supportato e fattibile dalle applicazioni.
- Assicurati che le pipeline CI/CD e gli strumenti per il deployment e il monitoraggio sono coerenti tra gli ambienti cloud.
- Seleziona il pattern di architettura di rete ottimale che fornisca
soluzione di comunicazione efficiente ed efficace per le applicazioni
che utilizzano.
- La comunicazione deve essere capillare e controllata. Usa la sicurezza API per esporre i componenti dell'applicazione.
- Prendi in considerazione l'utilizzo di Pattern di architettura mesh o uno dei pattern di networking gated, in base ai tuoi requisiti tecnici e aziendali specifici.
- Per soddisfare le tue aspettative di disponibilità e prestazioni, progetta per alta disponibilità end-to-end (HA), bassa latenza e velocità effettiva appropriata diversi.
Per proteggere le informazioni sensibili, ti consigliamo di criptare tutte comunicazioni in transito.
- Se è necessaria la crittografia a livello di connettività, in base alla connettività ibrida selezionata soluzione. Queste opzioni includono tunnel VPN, VPN ad alta disponibilità su Cloud Interconnect MACsec per Cross-Cloud Interconnect.
Se utilizzi più CDN come parte il tuo modello di architettura partizionata multi-cloud e stai compilando l'altra CDN con file di dati di grandi dimensioni di Google Cloud, utilizzando Interconnessione CDN e i collegamenti tra Google Cloud e fornitori supportati per ottimizzare questo traffico e, potenzialmente, le sue costo.
Estendi la tua soluzione di gestione delle identità tra gli ambienti in modo che i sistemi possano eseguire l'autenticazione sicura confini ambientali.
Per bilanciare efficacemente le richieste tra Google Cloud e un altro Google Cloud, puoi usare Cloud Load Balancing. Per ulteriori informazioni, vedi Routing del traffico a una località on-premise o a un altro cloud.
- Se il volume di trasferimento di dati in uscita da Google Cloud verso altri ambienti è elevato, valuta la possibilità Cross-Cloud Interconnect.
Per superare incoerenze nei protocolli, nelle API e nell'autenticazione in backend diversi, consigliamo, ove applicabile, eseguire il deployment di un gateway API o di un proxy come facade (facade). Questo gateway o proxy agisce come punto di controllo centralizzato ed esegue misure correttive:
- Implementa misure di sicurezza aggiuntive.
- Protegge le app client e altri servizi dalle modifiche al codice del backend.
- facilita gli audit trail per la comunicazione tra tutti delle applicazioni cross-environment e dei relativi componenti disaccoppiati.
- Agisce come
livello di comunicazione intermedio
tra servizi legacy e moderni.
- Apigee e Apigee ibrido consente di ospitare e gestire gateway di livello enterprise e ibridi in ambienti on-premise, perimetrali, in altri cloud ambienti Google Cloud.
In alcuni dei seguenti casi, l'utilizzo Cloud Load Balancing con un gateway API può fornire una soluzione solida e sicura per la gestione, la che distribuisce il traffico delle API su larga scala in più regioni:
- Deployment del failover multiregionale per l'API Apigee in diverse regioni.
Aumento del rendimento con Cloud CDN.
Protezione WAF e DDoS tramite Google Cloud Armor.
Utilizza strumenti coerenti per il logging e il monitoraggio nel cloud ove possibile. Potresti considerare l'utilizzo dell'open source sistemi di monitoraggio di rete. Per ulteriori informazioni, vedi Pattern di logging e monitoraggio ibridi e multi-cloud
Se esegui il deployment dei componenti delle applicazioni in modo distribuito il deployment dei componenti di una singola applicazione in più consulta l'ambiente best practice per il modello di architettura ibrida a più livelli.