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 in dettaglio ogni opzione, i relativi vantaggi e svantaggi, e termina con un confronto di tutte le opzioni.
Questo documento illustra i trasferimenti di dati tra macchine virtuali che risiedono in Google Cloud e altre reti virtuali di CSP. 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 di trasferimento dei dati tra Google Cloud e uno o più altri fornitori di servizi cloud, in base alle tue esigenze e alle tue funzionalità.
I concetti descritti in questo documento si applicano in 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 le risorse di Google Cloud e di altri fornitori di servizi cloud si trovano in regioni geograficamente vicine, si ottiene un vantaggio in termini di costi e latenza per i trasferimenti di dati tra i fornitori di servizi cloud.
Il seguente diagramma illustra il flusso di dati tra Google Cloud
e altri fornitori di servizi cloud.
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 alcuni di rete, i costi di rete aumentano anche quando i POP perimetrali di entrambi i provider non si trovano in un'area metropolitana. I dettagli sono riportati nella sezione relativa ai prezzi di ciascuna soluzione.
Assicurati di scegliere regioni adatte in ogni cloud che possano ospitare i carichi di lavoro previsti. Visita il Località per Google Cloud e pagine simili per altri CSP, come Tabella delle regioni AWS o Prodotti Azure per regione. Per assistenza generale sulla selezione di una o più località in Google Cloud, consulta le best practice per la scelta dell'area geografica per Compute Engine.
Trasferimento dei dati in Cloud Storage e BigQuery
Solo i dati che risiedono all'interno di un ambiente VPC di Google Cloud passano un Cloud VPN tunnel o un Cloud Interconnect per impostazione predefinita.
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 usare anche 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 CSP è di utilizzare internet e trasferire i dati usando 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.
Come Google si connette 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 viene 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 di Google:
- Acquista un servizio internet da un provider di servizi internet (ISP) che ha già connettività con Google (AS15169). Questa opzione è in genere indicata come transito IP ed è simile a quella acquistata da consumatori e aziende dai fornitori di servizi di accesso nelle loro case e 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 rispetto al transito perché gli operatori di rete hanno un maggiore controllo su come e dove il traffico scambiato, consentendo l'ottimizzazione di prestazioni e 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. AS15169 ha un criterio di peering aperto, vale a dire che finché una rete soddisfa requisiti tecnici, esegue il peering di questi dati.
Il peering è un accordo privato e vantaggioso per entrambe le parti e, di conseguenza, le reti di solito non divulgano pubblicamente chi sono 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à di trasferimento e latenza
Sebbene non sia garantita la velocità e la latenza sul percorso tramite internet, in genere i principali fornitori di servizi cloud e Google scambiano dati direttamente in più località in tutto il mondo. La capacità è condivisa con altri clienti e servizi, ma spesso, a causa della connessione diretta tra i due fornitori, la latenza è simile o inferiore rispetto ad 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 può variare da fornitore a fornitore.
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 (accordo sul livello del servizio)
Google Cloud in genere prevede più percorsi diversi per internet connettività da regioni ed esistono connessioni in peering diretto con altre i principali fornitori di servizi per i creator in varie sedi in tutto il mondo.
Tuttavia, Google Cloud non fornisce SLA per la connettività ad altri fornitori di servizi cloud tramite internet. Sebbene sia necessario controllare gli SLA per gli altri CSP, questi di solito si riferisce alla connettività internet nel suo complesso e non in modo specifico di Google Cloud.
I provider potrebbero avere criteri di routing diversi che possono influire sulla disponibilità. Ad esempio, nella pagina peeringdb, Amazon spiega che molte regioni AWS annunciano solo route locali, perché i VPC AWS 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. Questo è accettabile in condizioni di normale funzionamento con il traffico scambiato all'interno della regione, ma è consigliabile che i clienti progettino i deployment multiregionali in modo da tollerare i guasti regionali. Ciò potrebbe includere la configurazione di gateway aggiuntivi, VPN ad alta disponibilità, peering di reti virtuali o altre topologie multiregione 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 sulla SRE. Ad esempio, se crei un'applicazione che si basa sulla possibilità di raggiungere un servizio di terze parti tramite il routing di internet, assicurati che l'applicazione funzioni ancora o almeno restituisca all'utente messaggi di errore utili in caso di 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) che eseguono azioni ristoratrici. I clienti hanno più influenzerà il modo in cui gli operatori reagiscono alle interruzioni, quindi assicurati di avere supporto la copertura con tutti i fornitori e un piano per riassegnare eventuali problemi sbagliato. Esegui anche esercitazioni periodiche BCP (Business Continuity Process) per garantire la resilienza delle applicazioni progettate su multicloud.
Prezzi
Per i trasferimenti di dati su internet, normale tariffe del traffico in uscita da internet per il traffico che esce da Google Cloud. Nei casi in cui la latenza fondamentale, utilizzando Livello di servizio di rete standard fornisce un livello di prezzo inferiore.
Gli altri fornitori di servizi cloud hanno i propri costi per i trasferimenti di dati. In molti casi, fanno pagare solo il traffico in uscita dalla loro rete. Consultare il listino prezzi del CSP ad esempio per AWS, Addebiti per il trasferimento di dati EC2 e per Azure, vedi 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 servizi IPsec che possono essere usati sul lato 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 perché in Cloud VPN non è disponibile la funzionalità di Network Address Translation (NAT). Su Cloud Router, le route sovrapposte potrebbero essere rimosse dallo scambio tra ambienti, ma non sarà possibile alcuna comunicazione tra i servizi che utilizzano questi indirizzi IP.
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 CSP, potrebbero essere necessari 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 sull'interoperabilità, contenenti istruzioni dettagliate per configurare i tunnel VPN verso altri importanti con i cloud provider:
- Gateway VPN Alibaba Cloud senza ridondanza: supporta solo le route statiche.
- Gateway Alibaba Cloud VPN con ridondanza: supporta solo route statiche.
- AWS: supporta il routing dinamico con il router Cloud.
- Microsoft Azure: supporta il routing dinamico con il router Cloud.
Velocità di trasferimento e latenza
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 alla precedente con un piccolo overhead di latenza il tunnel VPN. La larghezza di banda disponibile è limitata dalla larghezza di banda massima per Tunnel VPN su Google Cloud, la larghezza di banda massima dei tunnel degli altri CSP e la larghezza di banda disponibile sul percorso internet.
Per una maggiore larghezza di banda, puoi implementare 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 attraverso i tunnel VPN IPsec viene criptato utilizzando le crittografie accettate da entrambi i fornitori di servizi cloud. Per ulteriori informazioni, consulta Cifrari IKE supportati da Cloud VPN, Domande frequenti sulla VPN AWS e Parametri IPsec/IKE di Azure VPN.
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 for 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à, valuta la possibilità di utilizzare più gateway e tunnel VPN sia su Google Cloud sia sugli altri fornitori di servizi cloud.
Prezzi
Si applicano i costi del servizio VPN gestito. 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 del servizio VPN, devi pagare per i dati trasferiti attraverso i gateway VPN. Per Google Cloud e molti CSP, si applicano le tariffe standard per il trasferimento di dati internet, come descritto in Trasferisci tramite indirizzi IP esterni su internet. In molti casi, gli addebiti per il trasferimento dei 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. Esegui la connessione tramite il deployment di una o più istanze di routing virtuali che si occupano della configurazione necessaria del Border Gateway Protocol (BGP).
Il seguente diagramma mostra una configurazione ridondante che utilizza due connessioni Partner Interconnect.
Le route vengono scambiate tra il router Cloud e il gateway sull'altro Lato di CSP attraverso 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 Google Cloud, puoi configurare Partner Interconnect con un provider di servizi di interconnessione che gestisce le tue regioni Google Cloud e offre e la connettività all'altro CSP.
- Nell'altro CSP, devi usare il prodotto di interconnessione per la connessione allo stesso partner. Ad esempio, su AWS puoi utilizzare Direct Connect e su Azure puoi utilizzare ExpressRoute.
- Sul lato del partner fornitore di servizi, devi configurare l'apparecchiatura di routing virtuale che fornisce le sessioni BGP a Google Cloud e all'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. Per maggiori dettagli, consulta la documentazione dei partner.
Velocità di trasferimento e latenza
Questa soluzione offre capacità dedicata tra Google Cloud e altri Provider di servizi cloud. A seconda del partner e dell'altro CSP, l'allegato disponibile può variare. Sul lato di Google Cloud, Partner Interconnect è disponibile con una capacità di collegamento tra 50 Mbps 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.
- La latenza nella rete del partner verso, da e attraverso l'istanza di routing virtuale verso l'altro fornitore di servizi cloud.
- La latenza dalla posizione perimetrale dell'altro CSP in cui avviene l'interconnessione con il partner alla 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 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. A per proteggere il traffico, puoi eseguire VPN ad alta disponibilità su Cloud Interconnect sul lato Google Cloud della connessione. Alcuni altri CSP ti consentono di utilizzare il loro servizio VPN gestito tramite un'interconnessione; ad esempio, la VPN site-to-site AWS può essere utilizzata tramite 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
Questa soluzione prevede tre diversi SLA: uno di Google, uno del partner di interconnessione e uno dell'altro CSP.
Quando utilizzi Partner Interconnect in modo ridondante, Google offre SLA mensili del 99,9% - 99,99% a seconda della topologia scelta. Non esiste uno SLA (accordo sul livello del servizio) su una singola Partner Interconnect connessione.
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 conoscere lo SLA sulla disponibilità della connettività e dell'istanza di 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 attraverso Partner Interconnect viene addebitato a una velocità inferiore rispetto al traffico internet. Per ulteriori informazioni, consulta la pagina dei prezzi di Partner Interconnect.
Consulta la pagina dei prezzi dell'altro CSP per il 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 dati 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 nello stesso area metropolitana, gli addebiti sono molto più bassi rispetto al caso in cui i dati debbano percorrere una distanza maggiore su un partner in ogni rete.
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 fornitori di servizi cloud possono variare senza preavviso, effettua il tuo confronto utilizzando le offerte aggiornate di tutte le parti coinvolte.
Dedicated Interconnect tramite un POP comune
Utilizzando uno o più dispositivi di routing fisici in una struttura di interconnessione comune tra Google Cloud e l'altro CSP, puoi collegare entrambi i provider cloud utilizzando Dedicated Interconnect lato Google Cloud e un prodotto equivalente lato altro CSP. La località dell'interconnessione non è necessariamente la stessa della regione 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 l'hosting e la gestione dei dispositivi di routing fisici in un struttura di colocation in cui sono presenti Google e il CSP a cui vuoi connetterti. Da questo dispositivo di routing, puoi ordinare due connessioni fisiche con la struttura: una verso Google Cloud Dedicated Interconnect e una verso l'altro fornitore di servizi che usano un prodotto equivalente, ad un esempio, Collegamento diretto AWS o Azure ExpressRoute. Sul dispositivo di routing, devi configurare BGP per consentire gli scambi di routing 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 sovrapporsi, a meno che il dispositivo di routing fisico non sia in grado di eseguire la NAT tra gli ambienti o che tu non limiti alcuni scambi di route 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 che tu possieda mantenere le apparecchiature fisiche e avere un contratto con una struttura di colocation. Me consiglia 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à di trasferimento e latenza
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 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 esegui l'interconnessione con Google Cloud.
- La latenza della struttura e delle tue apparecchiature fisiche, che solitamente è trascurabile rispetto alla latenza dovuta alla lunghezza della fibra.
- La latenza dalla posizione dell'interconnessione attraverso la rete dell'altro CSP alla regione in cui le risorse sono ospitate nel CSP.
Anche se non vengono offerte garanzie di latenza, questa soluzione in genere consente latenza più bassa e velocità di trasferimento più elevate tra Google Cloud e altri in ambienti cloud su 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 utilizzare il loro servizio VPN gestito tramite un'interconnessione; ad esempio, la VPN site-to-site AWS può essere utilizzata tramite 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 di applicazione anziché utilizzare 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 degli altri CSP per lo SLA (accordo sul livello del servizio) sul loro un prodotto di interconnessione, ad esempio SLA (accordo sul livello del servizio) per il collegamento diretto (AWS) o 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 prevedono anche un addebito mensile per l'interconnessione e i dati il costo del trasferimento di denaro attraverso l'interconnessione è inferiore a quello sulla rete internet.
Inoltre, devi tenere conto degli addebiti per i servizi della struttura di colocation che forniscono spazio, energia elettrica e connessioni fisiche sia ambienti, nonché eventuali costi e contratti di servizio in corso con il fornitore per l'attrezzatura fisica per i percorsi. 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 alle tue reti virtuali in un altro CSP tramite la 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 attraversa questa struttura 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 provider di servizi cloud. Tuttavia, Google rimane il punto di contatto principale per l'intero e ti informerà se devi aprire una richiesta di assistenza con l'altra CSP.
Questa soluzione richiede di seguire le procedura di configurazione per gli altri CSP, inclusa la scelta della destinazione interconnessioni. Solo alcuni I CSP sono supportati.
Velocità di trasferimento e latenza
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ù coppie di connessioni fisiche da 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à edge dell'altro CSP in cui è disegnato 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, consiglia di utilizzare la crittografia a livello di applicazione per il traffico sensibile.
Se tutto il traffico deve essere criptato, le appliance virtuali disponibili dai partner di Google Cloud in Cloud Marketplace possono fornire soluzioni per criptare il traffico nell'ambiente dell'altro fornitore di servizi cloud.
Affidabilità e SLA (accordo sul livello del servizio)
Cross-Cloud Interconnect utilizza Cloud Interconnect SLA. Per l'idoneità allo SLA (accordo sul livello del servizio), il tuo servizio Cross-Cloud Interconnect deve utilizzare una o più coppie di connessioni, come descritto in Accordo sul livello del servizio (SLA) 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, vedi 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, per l'interconnessione viene addebitato un costo mensile. 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. Valuta attentamente tutte le opzioni in base alle tue esigenze.
Il seguente diagramma illustra la procedura per scegliere una delle soluzioni indicate 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 . Inoltre, comporta una maggiore complessità nella gestione del tuo hardware e dei rapporti con una struttura di colocation. A meno che non abbiate già implementato l'infrastruttura, questa soluzione è riservata ai casi in cui le velocità di trasferimento dei dati tipiche sono 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.