La funzionalità di trasferimento di dati da sito a sito consente di connettere i tuoi siti esterni utilizzando la rete Google. In questo contesto, un sito esterno è qualsiasi rete che gestisci al di fuori di Google Cloud. Ad esempio, un sito esterno potrebbe essere la tua rete on-premise o la tua rete in un altro provider di servizi cloud.
Il trasferimento di dati site-to-site è supportato solo in determinate località. Tuttavia, potrebbe essere necessario gestire una risorsa di connettività in una regione non supportata per il trasferimento di dati site-to-site. Se hai questo tipo di topologia di rete e vuoi eseguire il trasferimento di dati da sito a sito, utilizza la configurazione descritta in questa pagina. In caso contrario, la connettività da sito a sito potrebbe non riuscire.
Il trasferimento di dati da sito a sito fa parte di Network Connectivity Center, che ti consente di gestire la tua rete utilizzando un'architettura hub e spoke. Per utilizzare il trasferimento di dati da sito a sito, devi stabilire la connettività a ogni rete esterna utilizzando una risorsa di connettività supportata. Successivamente, associ ogni risorsa di connettività a uno spoke di Network Connectivity Center (NCC), collegato a un hub NCC. L'NCC stabilisce quindi la connettività mesh completa tra tutti i siti esterni associati agli spoke.
Topologia di esempio
In questo esempio, un'organizzazione utilizza il trasferimento dati site-to-site per connettere due reti on-premise:
Rete A, in India
Rete B, in Australia
Queste reti si connettono a Google Cloud utilizzando
i collegamenti VLAN Dedicated Interconnect e i tunnel Cloud VPN
(VPN ad alta disponibilità). Queste risorse si trovano in due regioni supportate per il trasferimento di dati site-to-site: asia-south1 e australia-southeast1. Entrambi questi collegamenti VLAN sono associati a
spoke NCC con la funzionalità di trasferimento di dati site-to-site
abilitata.
Questa topologia inserisce anche le macchine virtuali (VM) Compute Engine in
australia-southeast1. Queste VM eseguono servizi a cui accedono regolarmente i sistemi on-premise che si trovano nella rete A.
Tuttavia, questa topologia è stata progettata in modo che le risorse Dedicated Interconnect abbiano una disponibilità del 99,99%. Per avere una disponibilità del 99,99%, devi utilizzare due coppie di connessioni Dedicated Interconnect in due regioni. Ogni connessione deve avere il proprio collegamento VLAN.
Per soddisfare questo requisito, la topologia di esempio posiziona una coppia ridondante di collegamenti VLAN in una regione ipotetica non supportata (region-unsupported1). La rete A è equidistante tra asia-south1 e region-unsupported1. Tuttavia, la regione non supportata è più vicina a
australia-southeast1 rispetto a asia-south1.
Questa configurazione pone un potenziale problema per il trasferimento dei dati site-to-site. Poiché
region-unsupported1 è più vicino a australia-southeast1, il router Cloud
in australia-southeast1 vede la risorsa in region-unsupported1 come
il percorso ottimale per la rete A. Tuttavia, poiché questo percorso non è associato
a NCC, il router Cloud non ripubblica i prefissi della rete A
nella rete B.
Opzioni di configurazione
Nello scenario di esempio, puoi controllare il routing del traffico configurando il router esterno per la rete A. Utilizza una delle opzioni descritte nelle sezioni seguenti.
Entrambe queste opzioni prevedono l'utilizzo di MED. Per capire come router Cloud utilizza MED, consulta Indicazioni per le priorità di base.
Opzione 1: ottimizza per il trasferimento di dati site-to-site
Se il trasferimento di dati site-to-site è fondamentale, forza tutto il traffico a dare la preferenza
alle risorse associate agli spoke NCC. Puoi ottenere
questo comportamento utilizzando valori MED diversi per asia-south1 e
region-unsupported1.
Ad esempio, configura il router per la rete on-premise A in modo che annunci
10.1/16 utilizzando quanto segue:
- Un MED da
100aasia-south1 - Un MED da
20000aregion-unsupported1
In questo caso, il router Cloud in australia-southeast1 considera
la pubblicità proveniente da asia-south1 come il percorso migliore. Inoltre, ripubblica
10.1/16 alla rete on-premise B.
Il vantaggio di questo approccio è che ti consente di utilizzare il trasferimento dei dati site-to-site in modo coerente. Lo svantaggio è che aumenta la latenza per i
sistemi della rete A che devono accedere alle VM in australia-southeast1.
Opzione 2: ottimizza per il traffico da sito a cloud
Se il trasferimento dati site-to-site non è fondamentale, forza tutto il traffico a dare
la preferenza a region-unsupported1. Puoi ottenere questo comportamento utilizzando gli stessi valori MED per asia-south1 e region-unsupported1.
Ad esempio, configura il router per la rete on-premise A in modo che annunci
10.1/16 utilizzando quanto segue:
- Un MED da
100aasia-south1 - Un MED da
100aregion-unsupported1
In questo scenario, il router cloud in australia-southeast1 considera
la pubblicità proveniente da region-unsupported1 come il percorso migliore perché è
geograficamente più vicino di asia-south1.
Poiché questo percorso non è associato a NCC,
router Cloud non riannuncia 10.1/16 alla rete on-premise B.
Il vantaggio di questo approccio è che, per i sistemi nella rete A che devono accedere alle VM in australia-southeast1, viene data la preferenza alla route con latenza inferiore. Lo svantaggio di questo approccio è che causa il mancato
trasferimento dei dati da sito a sito.
Passaggi successivi
- Per scoprire di più su come NCC consente la connettività full mesh tra siti esterni, consulta Scambio di route con trasferimento di dati tra siti.
- Per visualizzare una topologia di esempio, vedi Topologia di esempio per il trasferimento di dati site-to-site.
- Per scoprire di più sui requisiti di alta disponibilità, consulta Requisiti di alta disponibilità per le risorse spoke.
- Per creare hub e spoke, vedi Utilizzo di hub e spoke.