Informazioni su Hybrid Subnets

Hybrid Subnets ti consente di combinare una subnet on-premise con una subnet Virtual Private Cloud (VPC) per creare una singola subnet logica. Puoi eseguire la migrazione di singoli carichi di lavoro e istanze di macchine virtuali (VM) dalla subnet on-premise alla subnet VPC nel tempo senza dover cambiare gli indirizzi IP. Dopo aver eseguito la migrazione di tutti i carichi di lavoro e le VM, puoi ritirare la sottorete on-premise.

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

Hybrid Subnets e Migrate to Virtual Machines

Ti consigliamo di utilizzare Migrate to Virtual Machines con le sottoreti ibride per automatizzare il processo di migrazione delle VM da un'origine VMware. Migrate to Virtual Machines è supportato da Google.

Per ulteriori informazioni sulle opzioni di migrazione, consulta Risorse per la migrazione.

In alternativa, puoi utilizzare strumenti di migrazione di terze parti con le subnet ibride, a condizione che vengano soddisfatti i requisiti delle subnet ibride descritti in questo documento.

Per assistenza con la pianificazione di una migrazione a Google Cloud utilizzando le reti sottostanti ibride, invia una richiesta di assistenza.

Per informazioni su come pianificare una migrazione con Migrate to VMs, consulta Percorso di migrazione con Migra a VM.

Specifiche

  • Le sottoreti ibride richiedono un prodotto di connettività di rete come Cloud VPN o Cloud Interconnect.
  • Un router on-premise utilizza ARP proxy per instradare il traffico dalle macchine on-premise alle VM Google Cloud utilizzando le route apprese dalle route pubblicizzate personalizzate del router Cloud.
  • L'intervallo di indirizzi IPv4 principale della subnet Google Cloud deve corrispondere all'intervallo di indirizzi IP della subnet on-premise.
  • Per configurare la subnet come subnet ibrida, devi attivare il flag allow-cidr-routes-overlap di una subnet VPC. Quando allow-cidr-routes-overlap è attivato, Google Cloud consente ai percorsi personalizzati di sovrapporsi agli intervalli di indirizzi IP delle sottoreti.
  • 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 sottorete ibrida.
  • Utilizzi le route annunciate personalizzate del router Cloud per annunciare in modo selettivo gli indirizzi IP delle VM durante la migrazione alla subnet VPC.
  • Durante la migrazione dei carichi di lavoro da una rete on-premise a Google Cloud, aggiorna le route annunciate personalizzate del router Cloud in modo da includere gli indirizzi IP delle VM di cui è stata eseguita la migrazione.
  • Puoi connettere una subnet ibrida a una rete VPC peer utilizzando il peering di rete VPC. La configurazione del peering per la rete VPC contenente la subnet ibrida deve essere configurata per esportare le route personalizzate. La configurazione del peering per l'altra rete VPC deve essere configurata per importare le route personalizzate.

Limitazioni

  • Il numero massimo di VM in una rete VPC che utilizza reti ibridhe è 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 route pubblicizzati personalizzati per sessione BGP.
  • Il traffico broadcast e multicast all'interno di una sottorete ibrida non è supportato.
  • Non puoi utilizzare le connessioni Partner Interconnect di livello 3 che non supportano l'annuncio di route /32 con subnet ibride.
  • Le subnet ibride non supportano IPv6.
  • Le sottoreti ibride non supportano Google Cloud VMware Engine. Ti consigliamo di eseguire la migrazione delle VM VMware utilizzando VMware HCX.
  • Se un workload on-premise ha lo stesso indirizzo IP del router Cloud, i workload 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 i carichi di lavoro agli indirizzi IP riservati nelle subnet IPv4.
  • L'inoltro in entrata di Cloud DNS non risponde alle richieste DNS provenienti dai carichi di lavoro nella parte on-premise di una sottorete 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 workload nella parte on-premise di una sottorete ibrida non possono raggiungere gli endpoint Private Service Connect per le API di Google.
  • Le sottoreti ibride non supportano il trasferimento di dati site-to-site.
  • Le sottoreti ibride non supportano la migrazione dei carichi di lavoro da altri provider di servizi cloud o all'interno di Google Cloud perché questi ambienti non supportano l'ARP proxy.
  • Le subnet ibride non possono connettersi alle reti peer utilizzando Network Connectivity Center.

Considerazioni sull'utilizzo di Hybrid Subnets

Le sezioni seguenti descrivono le considerazioni per l'utilizzo delle sottoreti ibride.

Prestazioni della rete

Hybrid Subnets utilizza il livello 3 del modello OSI per instradare i pacchetti tra le parti on-premise e VPC di una subnet ibrida. Questo approccio consente a Hybrid Subnets di evitare i problemi di latenza, jitter e throughput che possono verificarsi durante le migrazioni quando alcuni carichi di lavoro esistono in una rete on-premise, ma altri sono stati migrati al cloud.

In particolare, evitare il tunneling di livello 2 consente di evitare il peggioramento delle prestazioni associato all'incapsulamento e alla crittografia di un overlay di livello 2 aggiuntivo. Inoltre, il routing di livello 3 consente alle sottoreti ibride di evitare un problema comune con il 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 trombonismo di rete.

L'approccio di Hybrid Subnets al routing ti consente di aspettarti un rendimento da una subnet ibrida simile o uguale a quello di una rete che non utilizza Hybrid Subnets.

Proxy ARP e subnet ibride

ARP proxy è obbligatorio per le subnet ibride. Per l'utilizzo di ARP proxy nella parte on-premise di una sottorete ibrida, consigliamo quanto segue:

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

Firewall e subnet ibride

Le sottoreti ibride evitano i problemi relativi all'utilizzo di firewall con traffico incapsulato negli overlay di livello 2. Per il traffico di livello 2, i firewall possono ispezionare i pacchetti solo agli endpoint o oltre gli endpoint dell'overlay, a meno che non vengano adottate misure specifiche come la decrittografia trasparente o le ispezioni approfondite del traffico overlay.

Non sono necessarie considerazioni speciali per utilizzare i firewall e le regole di firewall esistenti con le subnet ibride. Tuttavia, potrebbe essere necessario configurare le regole del firewall per assicurarti che le VM Google Cloud possano comunicare con i carichi di lavoro on-premise.

Prezzi

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

Per ulteriori informazioni, consulta Prezzi di Virtual Private Cloud.

Passaggi successivi