Informazioni sulle subnet ibride

Le subnet ibride consentono di combinare una subnet on-premise con una subnet Virtual Private Cloud (VPC) per creare un'unica subnet logica. Puoi eseguire nel tempo singoli carichi di lavoro e istanze di macchine virtuali (VM) dalla subnet on-premise alla subnet VPC senza dover modificare gli indirizzi IP. Al termine della migrazione di tutti i carichi di lavoro e delle VM, puoi dismettere la subnet on-premise.

Figura 1. In una subnet ibrida, i router on-premise e i router Cloud pubblicizzano le route utilizzando il protocollo BGP (Border Gateway Protocol).

Subnet ibride e Migrate to Virtual Machines

Ti consigliamo di utilizzare la funzionalità Esegui la migrazione a macchine virtuali con subnet ibride per automatizzare il processo di migrazione delle VM da un'origine VMware. Migrate to Virtual Machines è supportato da Google.

Per maggiori informazioni sulle opzioni di migrazione, consulta Risorse di migrazione.

In alternativa, puoi utilizzare strumenti di migrazione di terze parti con le subnet ibride, purché siano soddisfatti i relativi requisiti descritti in questo documento.

Per ricevere assistenza in merito alla pianificazione di una migrazione a Google Cloud utilizzando subnet ibride, invia una richiesta di assistenza.

Per informazioni sulla pianificazione di una migrazione con Migrate to VMs, vedi Percorso di migrazione con Migrate to VM.

Specifiche

  • Le subnet ibride richiedono un prodotto per la connettività di rete come Cloud VPN o Cloud Interconnect.
  • Un router on-premise utilizza un ARP proxy per instradare il traffico dalle macchine on-premise alle VM Google Cloud utilizzando le route apprese dagli annunci di route personalizzati del router Cloud.
  • L'intervallo di indirizzi IPv4 principali della subnet Google Cloud deve corrispondere all'intervallo di indirizzi IP della subnet on-premise.
  • Devi abilitare il flag allow-cidr-routes-overlap di una subnet VPC per configurarla come subnet ibrida. Se allow-cidr-routes-overlap è abilitato, Google Cloud consente la sovrapposizione delle route personalizzate agli intervalli di indirizzi IP delle subnet.
  • Il flag allow-cidr-routes-overlap si applica agli intervalli di subnet IPv4 principali, agli intervalli di subnet IPv4 secondari e agli intervalli di subnet IPv6.
  • La connettività interna viene mantenuta tra tutte le VM e i carichi di lavoro in una subnet ibrida.
  • Puoi utilizzare gli annunci di route personalizzate del router Cloud per pubblicizzare selettivamente gli indirizzi IP delle VM durante la migrazione alla subnet VPC.
  • Quando esegui la migrazione dei carichi di lavoro da una rete on-premise a Google Cloud, aggiorni gli annunci di route personalizzati del router Cloud in modo che includano gli indirizzi IP delle VM migrate.
  • Puoi connettere una subnet ibrida a una rete VPC peer utilizzando il peering di rete VPC. La configurazione di peering per la rete VPC che contiene la subnet ibrida deve essere configurata per esportare route personalizzate. La configurazione di peering per l'altra rete VPC deve essere configurata in modo da importare route personalizzate.

Limitazioni

  • Il numero massimo di VM in una rete VPC che utilizza subnet ibride è 130. Il superamento di questo limite può causare problemi di connettività e stabilità.
  • Il router Cloud di una subnet ibrida non può superare il numero massimo di annunci di route personalizzati per sessione BGP.
  • Il traffico Broadcast e multicast all'interno di una subnet ibrida non è supportato.
  • Non puoi utilizzare connessioni di Partner Interconnect di livello 3 che non supportano l'annuncio delle route /32 con subnet ibride.
  • Le subnet ibride non supportano IPv6.
  • Le subnet ibride non supportano Google Cloud VMware Engine. Ti consigliamo di eseguire la migrazione delle VM VMware utilizzando VMware HCX.
  • Se un carico di lavoro on-premise ha lo stesso indirizzo IP del router Cloud, i carichi di lavoro nella parte VPC di una subnet ibrida non possono inviare pacchetti a quell'indirizzo IP. Ad esempio, se l'intervallo di indirizzi IP della subnet ibrida è 192.168.1.0/24, i carichi di lavoro nella subnet VPC non possono raggiungere 192.168.1.1.
  • Le subnet ibride non possono ospitare carichi di lavoro negli indirizzi IP riservati nelle subnet IPv4.
  • L'inoltro in entrata di Cloud DNS non risponde alle richieste DNS dai carichi di lavoro nella parte on-premise di una subnet ibrida.
  • I carichi di lavoro nella parte on-premise di una subnet ibrida non possono raggiungere le API e i servizi Google utilizzando l'accesso privato Google.
  • I carichi di lavoro nella parte on-premise di una subnet ibrida non possono raggiungere gli endpoint Private Service Connect per le API di Google.
  • Le subnet ibride non supportano il trasferimento di dati da sito a sito.
  • Le subnet ibride non supportano la migrazione dei carichi di lavoro da altri fornitori di servizi cloud o la migrazione dei carichi di lavoro all'interno di Google Cloud perché questi ambienti non supportano l'ARP proxy.
  • Una subnet ibride non può connettersi a reti peer utilizzando Network Connectivity Center.

Considerazioni sull'utilizzo di subnet ibride

Le seguenti sezioni descrivono le considerazioni sull'utilizzo delle subnet ibride.

Rendimento della rete

Le subnet ibride utilizzano il livello 3 del modello OSI per instradare i pacchetti tra le parti on-premise e VPC di una subnet ibrida. Questo approccio consente alle subnet ibride di evitare problemi con latenza, tremolio e velocità effettiva che possono verificarsi durante le migrazioni quando alcuni carichi di lavoro esistono su una rete on-premise, ma sono stati migrati al cloud altri carichi di lavoro.

In particolare, evitare il tunneling di livello 2 aiuta a prevenire il degrado delle prestazioni associato all'incapsulamento e alla crittografia di un overlay di livello 2 aggiuntivo. Inoltre, il routing di livello 3 consente alle subnet ibride di evitare un problema comune relativo al tunneling di livello 2, in cui il traffico viene inviato a un nodo centrale prima di raggiungere destinazioni che possono essere vicine al punto di origine del traffico. Questo problema a volte è chiamato tromboning di rete.

L'approccio al routing delle subnet ibride prevede prestazioni da una subnet ibrida simile o uguale a una rete che non utilizza questo tipo di subnet.

ARP proxy e subnet ibride

L'ARP proxy è obbligatorio per le subnet ibride. Consigliamo quanto segue per l'utilizzo dell'ARP proxy nella parte on-premise di una subnet ibrida:

  • Rivolgiti al fornitore della tua struttura di rete on-premise per le best practice relative all'abilitazione dell'ARP del proxy e alla protezione dell'ambiente di rete.
  • Disabilita l'ARP proxy dopo aver completato la migrazione a Google Cloud.

Firewall e subnet ibride

Le subnet ibride evitano problemi legati all'utilizzo di firewall con traffico incapsulato negli overlay di livello 2. Per il traffico di livello 2, i firewall possono esaminare i pacchetti solo presso gli endpoint in overlay o al di fuori, a meno che non vengano adottate misure specifiche come una decriptazione trasparente o ispezioni approfondite del traffico dell'overlay.

Non sono necessarie considerazioni particolari per l'utilizzo di firewall e regole firewall esistenti con le subnet ibride. Tuttavia, potrebbe essere necessario configurare le regole firewall per garantire che le VM Google Cloud possano comunicare con i carichi di lavoro on-premise.

Prezzi

Non è previsto alcun costo aggiuntivo per l'utilizzo delle subnet ibride. Tuttavia, ti vengono addebitati i costi per le risorse e il traffico di rete nella parte Google Cloud di una subnet ibrida.

Per saperne di più, consulta i prezzi di Virtual Private Cloud.

Passaggi successivi