Questo documento aiuta gli architetti cloud e i professionisti delle operazioni a decidere come collegare Google Cloud ad altri fornitori di servizi cloud (CSP) come Amazon Web Services (AWS) e Microsoft Azure. In una progettazione multi-cloud, le connessioni tra CSP consentono i trasferimenti di dati tra le reti virtuali. Il presente documento fornisce inoltre informazioni su come implementare l'opzione che scegliere.
Molte organizzazioni operano su più piattaforme cloud, come misura temporanea durante una migrazione o perché hanno una strategia multi-cloud a lungo termine.
Per lo scambio di dati tra Google Cloud e altri fornitori di servizi cloud, in questo documento sono descritte diverse opzioni:
- Trasferimento di dati tramite indirizzi IP pubblici su internet.
- Utilizzo di un servizio VPN gestito tra Google Cloud e l'altro CSP.
- Utilizzo di Partner Interconnect su Google Cloud per connettersi a un partner in grado di connettersi direttamente con l'altro CSP.
- Utilizzo di Dedicated Interconnect su Google Cloud per trasferire i dati all'altro CSP tramite un punto di presenza (POP) comune.
- Utilizzo di Cross-Cloud Interconnect su Google Cloud per una connessione gestita a un altro CSP.
Queste opzioni differiscono in termini di velocità di trasferimento, latenza, affidabilità, contratti di livello di servizio (SLA), complessità e costi. Questo documento descrive ogni l'opzione e i suoi vantaggi e svantaggi nel dettaglio e termina con un confronto di tutte le opzioni.
Questo documento illustra i trasferimenti di dati tra macchine virtuali in Google Cloud e le reti virtuali di altri fornitori di servizi cloud. Per i dati archiviati in altre Prodotti Google Cloud come Cloud Storage e BigQuery vedi la sezione relativa a questi prodotti.
Questo documento può fungere da guida per valutare le opzioni per trasferire i dati tra Google Cloud e uno o più altri CSP, in base ai tuoi requisiti e capacità.
I concetti esposti in questo documento si applicano a più casi:
- Quando prevedi di trasferire grandi quantità di dati per un breve periodo di tempo, ad esempio per un progetto di migrazione dei dati.
- Se esegui trasferimenti continui di dati tra più cloud provider, ad esempio perché i carichi di lavoro di computing vengono eseguiti su un altro CSP mentre carichi di lavoro di big data utilizzano Google Cloud.
Considerazioni iniziali
Prima di scegliere come collegare i tuoi ambienti cloud, è importante esaminare le regioni che scegli in ogni ambiente e avere una strategia per trasferire i dati che non risiedono in ambienti di rete virtuali.
Scegli le regioni cloud
Se sia Google Cloud che le altre risorse di CSP si trovano in regioni in geograficamente vicini tra loro, c'è un vantaggio in termini di costi e latenza i trasferimenti di dati tra cloud provider.
Il seguente diagramma illustra il flusso di dati tra Google Cloud
e altri CSP.
Indipendentemente dal metodo di trasferimento, i dati passano da Google Cloud altri CSP come segue:
- Dalla regione Google Cloud in cui sono ospitate le risorse al POP perimetrale di Google.
- Tramite una struttura di terze parti tra Google Cloud e l'altro CSP.
- Dal POP perimetrale dell'altro CSP alla regione in cui si trovano le risorse all'interno della rete dell'altro CSP.
I dati che fluiscono dall'altro CSP a Google Cloud percorrono lo stesso percorso, ma nella direzione opposta.
Il percorso end-to-end determina la latenza del trasferimento dei dati. Per alcune soluzioni, i costi di rete aumentano anche quando i POP di entrambi i fornitori non si trovano nella stessa area metropolitana. I dettagli sono elencati nei prezzi seguenti di ciascuna soluzione.
Assicurati di scegliere regioni adatte in ogni cloud che possano ospitare le tue regioni carichi di lavoro con scale out impegnativi. Visita il Località per Google Cloud e pagine simili per altri CSP, come Tabella delle regioni AWS o Prodotti Azure per regione. Per assistenza generica per la selezione di una o più località in Google Cloud, recensione Best practice per la scelta della regione per Compute Engine.
Trasferimento di dati in Cloud Storage e BigQuery
Per impostazione predefinita, solo i dati all'interno di un ambiente VPC Google Cloud passano un tunnel Cloud VPN o una connessione Cloud Interconnect.
Se vuoi trasferire dati da e verso altri servizi Google, puoi utilizzare Private Service Connect e Private Google Access per gli host on-premise dall'ambiente dell'altro CSP.
Se vuoi trasferire l'object storage, il database, il data warehouse o altri prodotti di un altro fornitore di servizi cloud, controlla la documentazione per verificare se i dati possono passare attraverso il suo prodotto VPN gestito o di interconnessione. In caso contrario, potresti riuscire a passare questi dati tramite macchine virtuali proxy che hai configurato nel rispettivo ambiente CSP per farlo passare attraverso la connessione che desideri.
Per trasferire i dati in Cloud Storage o BigQuery, puoi anche usare Servizio di trasferimento dello spazio di archiviazione o BigQuery Transfer Service.
Trasferisci tramite indirizzi IP esterni su internet
Il modo più semplice per trasferire dati tra Google Cloud e un altro fornitore di servizi cloud è utilizzare internet e trasferire i dati tramite indirizzi IP esterni.
Il seguente diagramma illustra gli elementi di questa soluzione.
Tra il perimetro della rete di Google e quello dell'altro CSP, i dati vengono trasmessi tramite internet o utilizzando un peering diretto tra Google Cloud e altro CSP. I dati possono passare solo tra risorse che hanno indirizzi IP pubblici assegnati.
Modalità di connessione di Google ad altre reti
I POP perimetrali di Google sono i punti in cui la rete di Google si connette ad altre reti che formano collettivamente internet. Google sta presente in numerose località in tutto il mondo.
Su internet, a ogni rete è assegnato un numero di sistema autonomo (ASN) che comprende le route e l'infrastruttura di rete interna della rete. L'ASN principale di Google è 15169.
Esistono due modi principali in cui una rete può inviare o ricevere traffico da o verso Google:
- Acquista un servizio internet da un provider di servizi internet (ISP) che già dispone di connettività a Google (AS15169). Questa opzione è generalmente indicata come transito IP ed è simile all'acquisto da parte di consumatori e aziende presso le loro case e le loro attività.
- Collegati direttamente a Google (AS15169). Questa opzione, chiamata peering, consente a una rete di inviare e ricevere direttamente traffico verso Google (AS15169) senza utilizzare una rete di terze parti. Su larga scala, il peering è generalmente preferito al transito perché gli operatori di rete hanno un maggiore controllo su come e dove viene scambiato il traffico, il che consente di ottimizzare le prestazioni e i costi. Il peering è una sistema volontario; nella scelta del peering, gli operatori di rete decidono congiuntamente quale connessione, quanta larghezza di banda per il provisioning, come suddividere i costi dell'infrastruttura e qualsiasi altro dettaglio richiesto per configurare le connessioni. L'AS15169 ha un criterio di peering aperto, il che significa che, a condizione che una rete soddisfi i requisiti tecnici, Google eseguirà il peering con essa.
Il peering è un accordo privato e vantaggioso per entrambe le parti e, di conseguenza, generalmente le reti non divulgano in determinate località, la quantità di larghezza di banda disponibile ecc. Tuttavia, a causa su scala e una politica aperta, Google è direttamente in peering con quasi tutti i principali ISP cloud e cloud in più località e regioni. La Il team della Rete Google collabora direttamente con le controparti di queste reti per forniscono una capacità di peering sufficiente per soddisfare la domanda.
Per ulteriori informazioni sul funzionamento del peering internet, consulta la guida pratica al peering internet.
Implementazione
In questa configurazione, tutte le macchine virtuali che trasferiscono dati tra Google Cloud e gli altri provider di servizi cloud devono avere un IP pubblico . Da un lato, il firewall deve essere aperto per consentire una connessione dall'indirizzo IP pubblico dell'altro provider cloud. Non sono necessari passaggi aggiuntivi perché lo scambio di dati avviene sulla connettività internet esistente.
Velocità e latenza di trasferimento
Sebbene non vi siano velocità e latenza garantite lungo il percorso internet, in genere i principali CSP e Google scambiano dati direttamente località in tutto il mondo. La capacità è condivisa con altri clienti e ma, spesso a causa della connessione diretta tra entrambi i provider, la latenza è simile o inferiore rispetto alle altre opzioni.
Ti consigliamo di testare la latenza e la larghezza di banda tra Google Cloud e gli altri CSP nelle regioni che hai scelto. Puoi creare un rapido benchmark utilizzando strumenti come iperf o netperf o eseguire un benchmark personalizzato più completo in base alla tua app. Mentre le condizioni potrebbe cambiare nel tempo, il benchmark può fornire un'indicazione il rendimento atteso e se questa soluzione soddisfa le tue esigenze. Se hai bisogno di una larghezza di banda dedicata tra entrambi gli ambienti, devi scegliere un'altra soluzione.
Tieni presente che i prodotti di fornitori diversi possono avere caratteristiche in termini di rendimento che potrebbero non corrispondere sempre. Ad esempio, la capacità VPN IPsec per tunnel potrebbe variare da un fornitore all'altro.
Sicurezza
Il traffico su internet non è criptato e potrebbe passare tramite provider di servizi internet (ISP), sistemi autonomi e strutture di terze parti. Pertanto, devi criptare il traffico sensibile a livello di applicazione o scegliere un'altra soluzione.
Affidabilità e SLA
In genere, Google Cloud dispone di più percorsi diversi per la connettività internet dalle regioni e sono presenti connessioni di peering diretto con altri importanti fornitori di servizi cloud in più località in tutto il mondo.
Tuttavia, Google Cloud non fornisce SLA per la connettività ad altri fornitori di servizi cloud tramite internet. Sebbene tu debba controllare gli SLA per gli altri tuoi fornitori di servizi cloud, tipicamente si riferiscono solo alla connettività a internet nel suo complesso e non a fornitori specifici.
I fornitori potrebbero avere criteri di routing diversi che possono influire sulla disponibilità. Ad esempio, nella relativa pagina peeringdb, Amazon spiega che molte regioni AWS annunciano solo route locali, perché I VPC sono solo a livello di regione (i VPC Google Cloud sono globali). Ciò significa che i clienti potrebbero basandosi sui link in una singola località di peering, poiché il traffico che esce da Google Cloud può utilizza questi link per raggiungere la destinazione. Non è un problema se funziona normalmente con traffico scambiato all'interno della regione, ma è consigliabile ai clienti per deployment multiregionali per tollerare gli errori regionali. Questo potrebbe puoi configurare gateway, VPN ad alta disponibilità, peering di rete virtuale altre topologie multiregionali nel cloud di terze parti.
Le applicazioni devono inoltre essere create in modo da "funzionare in caso di errore", come consigliato da Google SRE nel libro SRE. Ad esempio, se crei un'applicazione che si basa sulla possibilità di raggiungere servizio di terze parti tramite routing Internet, assicurati che l'applicazione o almeno restituisce utili messaggi di errore all'utente nell'evento dei problemi di connettività.
In caso di problemi con il routing a internet, il team della rete Google tenterà per ripristinare la connettività con la terza parte. Tuttavia, non tutti i problemi saranno sotto il controllo di Google. Quindi, in alcuni casi, la riparazione potrebbe dipendere da terze parti (ISP o cloud provider) intraprendendo un'azione ristoratrice. I clienti hanno la maggiore influenza sulla modalità di risposta degli operatori alle interruzioni, quindi assicurati di avere una copertura dell'assistenza con tutti i fornitori e un piano per la riassegnazione dei problemi in caso di problemi. Esegui inoltre esercitazioni periodiche del BCP (business continuity) per garantire la resilienza delle applicazioni progettate su multi-cloud.
Prezzi
Per i trasferimenti di dati su internet, si applicano le normali tariffe di uscita da internet per il traffico che esce da Google Cloud. Se la latenza non è critica, l'utilizzo del livello di servizio di rete standard offre un livello di prezzo inferiore.
Gli altri fornitori di servizi cloud hanno i propri costi per i trasferimenti di dati. In molti casi, addebita solo il traffico in uscita dalla rete. Consulta il listino prezzi del tuo CSP. Per esempio, per AWS, consulta Addebiti per il trasferimento dei dati EC2 e per Azure, consulta Dettagli sui prezzi della larghezza di banda.
VPN gestita tra cloud provider
Puoi utilizzare i servizi VPN gestiti di entrambi i cloud provider, che hanno due vantaggi dell'IA. Fornisce un canale criptato tra le reti virtuali ambienti cloud e consente di trasferire i dati utilizzando indirizzi IP privati. Si tratta di un'estensione della soluzione precedente di trasferimento tramite internet senza richiedere hardware o partner.
Il seguente diagramma illustra gli elementi di questa soluzione.
Con questa soluzione, i dati vengono criptati su Google Cloud tramite Cloud VPN e una soluzione VPN per l'altro CSP. Il trasferimento dei dati tra Google Cloud e gli altri CSP utilizza internet come soluzione precedente.
Implementazione
Google offre Cloud VPN come servizio VPN gestito per i tunnel IPsec criptati, che possono essere utilizzati da Google. Altri CSP offrono soluzioni gestite Prodotti VPN, che puoi utilizzare per creare tunnel VPN IPsec tra ambienti cloud-native. Ad esempio, AWS offre VPN site-to-site di AWS e le offerte di Azure Gateway VPN di Azure. Puoi connettere le tue reti virtuali tra gli ambienti utilizzando i tunnel VPN.
gli indirizzi IP nei due ambienti non devono sovrapporsi poiché non c'è Network Address Translation (NAT) di archiviazione disponibili in Cloud VPN. Attivato Router Cloud le route sovrapposte potrebbero essere rimosse dallo scambio tra ambienti, ma poi nessuna comunicazione tra i servizi che utilizzano questi indirizzi IP possibile.
Con Cloud Router in modalità di routing dinamico globale, puoi raggiungere tutte le regioni di una rete VPC globale utilizzando solo i tunnel VPN per quella regione. Per altri fornitori di servizi cloud, potresti aver bisogno di tunnel VPN per regione. Se disponi in un ambiente cloud non connesse in peering, è necessario connettere tutte le reti virtuali che hanno bisogno di comunicare tra loro in modo indipendente usando una VPN.
Google Cloud offre guide all'interoperabilità con istruzioni dettagliate per la configurazione di tunnel VPN con altri importanti cloud provider:
- Gateway VPN Alibaba Cloud senza ridondanza: supporta solo le route statiche.
- Gateway VPN Alibaba Cloud con ridondanza: supporta solo le route statiche.
- AWS: supporta il routing dinamico con il router Cloud.
- Microsoft Azure: supporta il routing dinamico con Cloud Router.
Velocità e latenza di trasferimento
Quando utilizzi tunnel VPN gestiti, i dati seguono comunque lo stesso percorso internet come se I dati sono stati scambiati direttamente tramite indirizzi IP pubblici. La latenza osservata dovrebbe essere simile a quella dell'opzione precedente, con solo un piccolo sovraccarico di latenza per il tunnel VPN. La larghezza di banda disponibile è limitata dalla larghezza di banda massima per tunnel VPN su Google Cloud, dalla larghezza di banda massima dei tunnel degli altri fornitori di servizi cloud e dalla larghezza di banda disponibile sul percorso internet.
Per una larghezza di banda superiore, puoi eseguire il deployment di più tunnel in parallelo. Per maggiori informazioni informazioni su come eseguire il deployment di una soluzione di questo tipo, vedi Creazione di VPN a velocità effettiva elevata.
Puoi testare la latenza e la larghezza di banda come descritto nella sezione precedente, ma possono variare nel tempo e non vi sono garanzie in termini di latenza e la larghezza di banda.
Sicurezza
Il traffico sui tunnel VPN IPsec viene criptato tramite crittografie accettate da entrambi CSP. Per ulteriori informazioni, vedi Crittografia IKE supportata da Cloud VPN, Domande frequenti sulla VPN AWS e Parametri IPsec/IKE VPN di Azure.
Affidabilità e SLA
Cloud VPN offre SLA (accordo sul livello del servizio) del 99,9%-99,99% a seconda che sia selezionata la VPN classica o la VPN ad alta disponibilità. Altri CSP a volte offrono SLA per il proprio prodotto VPN gestito, ad esempio AWS Site-to-Site VPN SLA e Azure SLA per VPN Gateway. Tuttavia, questi SLA coprono solo la disponibilità dei gateway VPN e non includono ad altri CSP su internet, per cui non è previsto uno SLA (accordo sul livello del servizio) soluzione end-to-end.
Per aumentare l'affidabilità, ti consigliamo di utilizzare più gateway e tunnel VPN sia su Google Cloud sia sugli altri fornitori di servizi cloud.
Prezzi
Per il servizio VPN gestito si applicano degli addebiti. Per Google Cloud, si applica un addebito orario. Consulta i prezzi di Cloud VPN. Per altri fornitori di servizi cloud, consulta i relativi listini prezzi, ad esempio consulta Prezzi delle connessioni VPN Site-to-Site di AWS o Prezzi di Azure VPN Gateway.
Oltre al prezzo orario per il servizio VPN, devi pagare i dati trasferiti tramite i gateway VPN. Per Google Cloud e molti fornitori di servizi cloud, si applicano gli addebiti standard per il trasferimento di dati su internet, come descritto in Trasferimento tramite indirizzi IP esterni su internet. In molti casi, i costi del trasferimento di dati superano il costo fisso di questa soluzione.
Partner Interconnect con partner abilitati multi-cloud
Partner Interconnect ti consente di connettere un Virtual Private Cloud alle reti virtuali di un altro CSP tramite la rete di alcuni partner selezionati che offrono soluzioni multicloud dirette. Ti connetti tramite eseguendo il deployment di una o più istanze di routing virtuali che si occupano delle Border Gateway Protocol (BGP) configurazione.
Il seguente diagramma mostra una configurazione ridondante che utilizza due Connessioni Partner Interconnect.
Le route vengono scambiate tra il router Cloud e il gateway dell'altro fornitore di servizi cloud tramite un'istanza di routing virtuale gestita dal partner che fornisce l'interconnessione. Il traffico passa attraverso la rete del partner tra Google Cloud e l'altro CSP.
Implementazione
Questa soluzione richiede la configurazione di più componenti:
- Sul lato di Google Cloud, configuri Partner Interconnect con un provider di servizi di interconnessione che serve le tue regioni Google Cloud e offre connettività multicloud all'altro CSP.
- Nell'altro CSP, devi utilizzare il relativo prodotto di interconnessione per collegarti allo stesso partner. Ad esempio, su AWS puoi utilizzare Collegamento diretto e su Azure puoi usare ExpressRoute.
- Per quanto riguarda i fornitori di servizi, devi configurare lo spazio l'apparecchiatura di routing che fornisce le sessioni BGP a Google Cloud l'altro CSP.
Se lo spazio di indirizzi IP tra i due ambienti CSP si sovrappone, il partner potrebbe offrono la funzionalità NAT per l'apparecchiatura di routing virtuale. Scopri i partner documentazione per i dettagli.
Velocità e latenza di trasferimento
Questa soluzione offre capacità dedicata tra Google Cloud e altri CSP. A seconda del partner e dell'altro CSP, l'allegato disponibile può variare. Per quanto riguarda Google Cloud, Partner Interconnect è disponibile con una capacità di collegamento tra 50 Mbit/s e 50 Gbps.
La latenza per questa soluzione è la somma di quanto segue:
- Latenza tra la regione in cui le risorse sono ospitate su Google Cloud e la località di interconnessione in cui il partner si connette a Google Cloud.
- Latenza nella rete dei partner da, verso e tramite la rete virtuale di routing dell'istanza verso l'altro CSP.
- Latenza dalla località perimetrale dell'altro CSP in cui l'interconnessione con il partner si svolge nella regione in cui le risorse sono ospitate nel CSP.
Per ottenere la latenza più bassa possibile, le località sul perimetro di Google Cloud l'altro CSP deve trovarsi nella stessa area metropolitana, insieme di routing. Ad esempio, potresti avere una connessione a bassa latenza se entrambi Le regioni cloud di CSP, così come il POP perimetrale e l'istanza di routing virtuale sono nell'area di Ashburn, in Virginia.
Sebbene Google Cloud e molti altri fornitori di servizi cloud non offrano garanzie sulla latenza per il traffico verso l'edge della rete, in quanto esiste un percorso e una capacità dedicati tramite il partner, in genere la latenza in questa soluzione è meno variabile rispetto all'utilizzo di indirizzi IP esterni o di una soluzione VPN.
Sicurezza
Il traffico su Partner Interconnect non è criptato per impostazione predefinita. Per contribuire a proteggere il traffico, puoi implementare la VPN ad alta disponibilità su Cloud Interconnect sul lato Google Cloud della connessione. Alcuni altri CSP ti consentono di usare i loro un servizio VPN gestito su un'interconnessione; ad esempio AWS Site-to-Site VPN da utilizzare su AWS Direct Interconnect. In alternativa, puoi anche utilizzare una macchina virtuale che cripta il traffico sul lato altro CSP.
Un'altra opzione è criptare il traffico a livello di applicazione anziché utilizzare la VPN.
Affidabilità e SLA
Questa soluzione prevede tre diversi SLA: uno di Google, l'altro di interconnessione e uno dall'altro CSP.
Quando utilizzi Partner Interconnect in modo ridondante, Google offre SLA mensili del 99,9% - 99,99% a seconda della topologia scelta. Non è previsto alcun SLA per una singola connessione Partner Interconnect.
Consulta la documentazione dell'altro CSP per lo SLA sul proprio prodotto di interconnessione, ad esempio lo SLA di AWS Direct Connect o su Azure lo SLA per ExpressRoute.
Consulta la documentazione o i termini del fornitore di servizi partner per Partner Interconnect per lo SLA (accordo sul livello del servizio) sulla disponibilità di connettività e routing virtuale. Ad esempio, consulta il Megaport Global Services Agreement.
Prezzi
Da parte di Google Cloud, è prevista una tariffa mensile per ogni collegamento Partner Interconnect, a seconda della larghezza di banda. Il traffico in uscita tramite Partner Interconnect viene addebitato a una tariffa inferiore rispetto al traffico internet. Per ulteriori informazioni, consulta Pagina dei prezzi di Partner Interconnect.
Consulta la pagina dei prezzi dell'altro CSP per il suo prodotto di interconnessione, ad esempio i prezzi di AWS Direct Connect o i prezzi di Azure ExpressRoute. In genere, i prezzi prevedono anche un addebito mensile per l'interconnessione e i servizi il costo del trasferimento di denaro attraverso l'interconnessione è inferiore a quello sulla rete internet.
Il partner fornisce gli addebiti per i servizi di interconnessione in base ai propri prezzi, che puoi trovare sul suo sito web o consultando il suo team di vendita per richiedere un preventivo. In genere, se tutti i trasferimenti di dati avvengono nella stessa area metropolitana, i costi sono molto più bassi rispetto a quelli che si applicano se i dati devono percorrere una distanza maggiore su una rete partner.
Quando i dati vengono trasferiti regolarmente a volumi sufficientemente elevati, a seconda dei prezzi degli altri fornitori di servizi cloud, a volte questa soluzione può offrire il costo totale più basso a causa delle tariffe di uscita scontate. Anche se vengono aggiunti i costi mensili per l'interconnessione per Partner Interconnect, l'altro CSP e il partner fornitore di servizi, l'utilizzo di questa soluzione può offrire risparmi significativi. Poiché i prezzi dei partner e di altri CSP possono cambiare senza fai un confronto usando le citazioni aggiornate di tutte le persone coinvolte parti.
Dedicated Interconnect tramite un POP comune
Utilizzando uno o più dispositivi di routing fisici in una struttura di interconnessione comune tra Google Cloud e gli altri CSP, puoi connettere i provider utilizzando Dedicated Interconnect lato Google Cloud e un prodotto equivalente presso l'altro CSP. La località di interconnessione non si trova necessariamente nella stessa località in cui si trovano le risorse.
Il seguente diagramma mostra una configurazione ridondante che utilizza due connessioni Dedicated Interconnect:
Le route vengono scambiate tra il router Cloud e il gateway sull'altro Il lato CSP attraverso un router fisico posizionato in un'interconnessione comune completamente gestita. Il traffico passa attraverso questo router tra Google Cloud e altro CSP.
Implementazione
Questa soluzione richiede di ospitare e gestire dispositivi di instradamento fisici in una struttura di colocation in cui sono presenti Google e il fornitore di servizi cloud a cui vuoi connetterti. Da questo dispositivo di instradamento, ordini due connessioni fisiche con la struttura: una verso Google Cloud utilizzando Dedicated Interconnect, e una verso l'altro fornitore di servizi utilizzando un prodotto equivalente, ad esempio AWS Direct Connect o Azure ExpressRoute. Sul dispositivo di routing, devi configurare BGP per consentire gli scambi di route tra i due ambienti cloud.
Controlla il Elenco delle località delle strutture di colocation di Google Cloud e l'altro CSP, ad esempio Località per il collegamento diretto AWS o Località di peering di Azure ExpressRoute, per identificare le località adatte per questa configurazione.
Gli intervalli di indirizzi IP tra le reti virtuali non devono si sovrappongono, a meno che il dispositivo di routing fisico sia in grado di eseguire NAT tra o limiti alcuni scambi di routing tra gli ambienti.
Questa soluzione è efficace se utilizzi la connettività dedicata anche per connetterti all'ambiente on-premise, oltre alla connessione a un'altra CSP.
In altri casi, questa soluzione è complessa perché richiede di possedere e manutenere l'attrezzatura fisica e di avere un contratto con una struttura di colocation. Ti consigliamo di utilizzare questa soluzione solo se almeno una delle seguenti condizioni è vera:
- Hai già attrezzature in una struttura adatta per un altro scopo e un contratto esistente con la struttura.
- Trasferisci regolarmente grandi quantità di dati, quindi si tratta di un metodo conveniente o se esistono requisiti di larghezza di banda che i partner non sono in grado di soddisfare.
Velocità e latenza di trasferimento
Questa soluzione offre capacità dedicata tra Google Cloud e un altro provider di servizi cloud. Sul lato di Google Cloud, Dedicated Interconnect è disponibile utilizzando una o più connessioni fisiche da 10 o 100 Gbps.
La latenza di questa soluzione è la somma di quanto segue:
- Latenza tra la regione in cui le risorse sono ospitate su Google Cloud e la località di interconnessione in cui esegui l'interconnessione con Google Cloud.
- Latenza attraverso la struttura e le apparecchiature fisiche, che è solitamente trascurabile se confrontata con la latenza dovuta alla lunghezza delle fibre.
- La latenza dalla località di interconnessione attraverso la rete dell'altro CSP a la regione in cui le risorse sono ospitate nel CSP.
Sebbene non vengano offerte garanzie sulla latenza, in genere questa soluzione consente la latenza più bassa e le velocità di trasferimento più elevate tra Google Cloud e altri ambienti cloud tramite indirizzi IP privati.
Sicurezza
Il traffico su Dedicated Interconnect non è criptato per impostazione predefinita. Per proteggere il traffico, puoi eseguire il deployment VPN ad alta disponibilità su Cloud Interconnect sul lato Google Cloud della connessione. Alcuni altri CSP ti consentono di usare i loro un servizio VPN gestito su un'interconnessione; ad esempio AWS Site-to-Site VPN da utilizzare su AWS Direct Interconnect. In alternativa, puoi anche utilizzare un'appliance virtuale che cripta il traffico lato dell'altro fornitore di servizi cloud.
Un'altra opzione è criptare il traffico a livello dell'applicazione anziché usando la VPN.
Affidabilità e SLA
Quando si utilizza Dedicated Interconnect in modo ridondante, Google offre SLA mensili dal 99,9% al 99,99% a seconda del modello scelto topologia. Non è previsto alcun SLA per una singola connessione Dedicated Interconnect.
Per ulteriori informazioni, consulta la documentazione dell'altro fornitore di servizi cloud per lo SLA sul suo prodotto di interconnessione, ad esempio lo SLA di AWS Direct Connect o lo SLA di Azure per ExpressRoute.
La struttura di colocation o il fornitore di hardware per l'apparecchiatura di routing fisico potrebbe anche offrire SLA per i propri servizi.
Prezzi
Sul lato Google Cloud, è prevista una tariffa mensile per ogni Porta Dedicated Interconnect e per ogni collegamento VLAN che si connette a un ambiente VPC. Traffico in uscita attraverso Dedicated Interconnect ha una tariffa inferiore rispetto a internet per via del traffico. Per ulteriori informazioni, consulta la pagina dei prezzi di Dedicated Interconnect.
Consulta la pagina dei prezzi dell'altro fornitore di servizi cloud per il suo prodotto di interconnessione, ad esempio i prezzi di AWS Direct Connect o i prezzi di Azure ExpressRoute. In genere, i prezzi includono anche un addebito mensile per l'interconnessione e i costi di trasferimento dei dati tramite l'interconnessione a una tariffa inferiore rispetto a quella di internet.
Inoltre, devi tenere conto degli addebiti per i servizi della struttura di colocation che forniscono spazio, energia elettrica e connessioni fisiche a entrambi gli ambienti cloud, nonché eventuali costi e contratti di servizio in corso con il fornitore per l'apparecchiatura di instradamento fisico. Se la connessione tra i due CSP non può avvenire nella stessa struttura e devi procurarti la connettività tra le strutture, i prezzi potrebbero essere molto più elevati per questi servizi.
Connessioni gestite da Cross-Cloud Interconnect
Puoi connettere le tue reti VPC Google Cloud reti virtuali in un altro CSP sulla struttura di rete di Google. In un certo senso, questa configurazione funziona come Partner Interconnect, ma con lo SLA di Google che copre sia le reti di Google che le interconnessioni stesse.
Il seguente diagramma mostra una connessione Cross-Cloud Interconnect la configurazione con il numero minimo di connessioni.
Le route vengono scambiate tra il router Cloud e il gateway sull'altro Il lato di CSP sulla struttura di rete di Google. Il traffico passa attraverso questa infrastruttura tra Google Cloud e l'altro CSP.
Implementazione
Quando acquisti Cross-Cloud Interconnect, Google esegue il provisioning connessione fisica dedicata tra la rete Google e quella di un altro provider di servizi cloud. Puoi utilizzare questa connessione per eseguire il peering della tua rete VPC (Virtual Private Cloud) Google Cloud con una rete ospitata da un provider di servizi cloud supportato.
Dopo il provisioning della connessione, Google supporta la connessione fino al punto in cui raggiunge la rete dell'altro provider di servizi cloud. Google non garantisce l'uptime da parte dell'altro servizio cloud o il provider di servizi di terze parti. Tuttavia, Google rimane il punto di contatto principale per il servizio completo e ti informerà se dovrai aprire una richiesta di assistenza con l'altro fornitore di servizi cloud.
Questa soluzione richiede di seguire la procedura di configurazione per l'altro CSP, inclusa la scelta del punto di interconnessione delle due reti. Sono supportati solo alcuni CSP.
Velocità e latenza di trasferimento
Questa soluzione offre capacità dedicata tra Google Cloud e un altro provider di servizi cloud. Sul lato Google Cloud, Dedicated Interconnect disponibili utilizzando una o più coppie di Connessioni fisiche a 10 Gbps o 100 Gbps.
La latenza per questa soluzione è la somma di quanto segue:
- Latenza tra la regione in cui sono ospitate le risorse tra Google Cloud e la località cross-cloud.
- Latenza tra la località perimetrale di Google e quella dell'altro CSP (spesso nella stessa struttura)
- Latenza dalla località perimetrale dell'altro CSP in cui è distribuito Cross-Cloud Interconnect alla regione in cui le risorse sono ospitate nel CSP.
Sebbene non vengano offerte garanzie sulla latenza, in genere questa soluzione consente la minima latenza possibile e le massime velocità di trasferimento tra Google Cloud e altri ambienti cloud tramite indirizzi IP privati.
Sicurezza
Poiché il traffico su Cross-Cloud Interconnect non è criptato, consigliamo di utilizzare la crittografia a livello di applicazione per il traffico sensibile.
Se tutto il traffico deve essere criptato, disponibili dai partner Google Cloud in Cloud Marketplace possono fornire soluzioni per criptare il traffico verso gli altri CSP completamente gestito di Google Cloud.
Affidabilità e SLA
Cross-Cloud Interconnect utilizza Cloud Interconnect SLA. Per poter usufruire dello SLA, la configurazione di Cross-Cloud Interconnect deve utilizzare una o più coppie di connessioni, come descritto nella sezione Accordo sul livello del servizio della panoramica di Cross-Cloud Interconnect.
Il contratto di livello del servizio copre tutto ciò che si trova sul lato di Google fino al perimetro della rete dell'altro provider cloud. Non copre la rete dell'altro CSP. Per ulteriori informazioni, consulta la documentazione dell'altro fornitore di servizi cloud per lo SLA sul proprio prodotto di interconnessione, ad esempio lo SLA di AWS Direct Connect o lo SLA di Azure per ExpressRoute.
Prezzi
È prevista una tariffa oraria per ogni Cross-Cloud Interconnect e per ogni collegamento VLAN che si connette a un ambiente VPC. Il traffico in uscita tramite Cross-Cloud Interconnect viene addebitato a una tariffa inferiore rispetto al traffico internet. Per ulteriori informazioni, consulta i prezzi di Cross-Cloud Interconnect.
Consultare la pagina dei prezzi dell'altro CSP per il relativo prodotto di interconnessione, per un esempio, Prezzi di Connessione diretta AWS o Prezzi di Azure ExpressRoute. In genere, è previsto un addebito mensile per l'interconnessione. Addebiti per i dati i trasferimenti attraverso l'interconnessione sono generalmente inferiori ai costi per i dati trasferire i dati tramite internet.
Non sono previsti costi separati per le sedi o le attrezzature di interconnessione.
Confronto delle opzioni
Le opzioni presentate variano in termini di velocità, disponibilità, complessità, sicurezza e i prezzi. Ti consigliamo di valutare attentamente tutte le opzioni in base alle tue esigenze.
Il seguente diagramma ti guida nella procedura di scelta di uno dei soluzioni menzionate in questo documento tramite un semplice diagramma di flusso.
In genere, possiamo consigliare le seguenti opzioni:
- Per molti scenari in cui i dati vengono scambiati occasionalmente o a basso il volume e i trasferimenti non sono fondamentali, perché il trasferimento dei dati tramite internet è l'opzione più semplice, ma offre comunque una latenza relativamente bassa e e la larghezza di banda.
- Se è obbligatoria la crittografia o il trasferimento di quantità minori di dati utilizzando indirizzi IP privati, valuta la possibilità di utilizzare Cloud VPN e un servizio VPN gestito sul lato dell'altro fornitore di servizi cloud.
- Se trasferisci grandi quantità di dati, Partner Interconnect con un partner multi-cloud abilitato Offre diversi vantaggi: capacità dedicata, costi ridotti per i dati e, a seconda della topologia, uno SLA (accordo sul livello del servizio) per ogni parte della soluzione. La capacità di Partner Interconnect è normalmente inferiore superiore a 10 Gbps per connessione.
- Se connetti le tue apparecchiature on-premise a più cloud, utilizzando Dedicated Interconnect tramite un POP comune è un . Offre un'ulteriore complessità nella gestione del tuo hardware e le relazioni con una struttura di colocation. A meno che tu non abbia già dell'infrastruttura, questa soluzione è riservata ai casi in cui velocità di trasferimento dati pari o superiori a 10 Gbps.
- Se non vuoi occuparti dell'overhead associato alla gestione delle connessioni incrociate apparecchiature di routing nei POP remoti, Cross-Cloud Interconnect offre una soluzione gestita in cui Google gestisce tutto questo per te.
Passaggi successivi
- Rivedi la serie su modelli e procedure per ambienti ibridi e multi-cloud.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Centro architetture cloud.