Informazioni sulle subnet ibride

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 di istanze di macchine virtuali (VM) da una subnet on-premise alla subnet VPC nel tempo senza cambiare gli indirizzi IP. Dopo la migrazione di tutti i carichi di lavoro e di VM, puoi la subnet 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 Eseguire la migrazione alle macchine virtuali con subnet ibride per automatizzare il processo di migrazione 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 Subnet ibride a condizione che i requisiti delle subnet ibride descritti in questo documento sia stato completato.

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 Migra a VM, consulta Percorso di migrazione con Migra a VM.

Specifiche

  • Le subnet ibride richiedono prodotto per la connettività di rete come Cloud VPN o Cloud Interconnect.
  • Un router on-premise utilizza ARP proxy per il routing il traffico dalle macchine on-premise alle VM Google Cloud utilizzando route apprese dalle route annunciate 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.
  • Devi attivare il flag allow-cidr-routes-overlap di un Subnet VPC per configurare la subnet come subnet ibrida. 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 alla subnet IPv4 principale e intervalli di subnet IPv4 secondari e intervalli di subnet IPv6.
  • La connettività interna viene mantenuta tra tutte le VM e i carichi di lavoro in una sottorete ibrida.
  • Utilizzi il router Cloud route annunciate personalizzate per fare pubblicità selettiva e gli indirizzi IP delle VM quando ne esegui la migrazione nella subnet VPC.
  • Quando esegui la migrazione dei carichi di lavoro da una rete on-premise a Google Cloud, aggiorni le route annunciate personalizzate del router Cloud per includere gli indirizzi IP delle VM migrate.
  • Puoi connettere una subnet ibrida a una rete VPC peer utilizzando 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 Il numero di 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 numero massimo di route annunciate personalizzate 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 supporto dell'annuncio delle route /32 con subnet ibride.
  • Le subnet ibride non supportano IPv6.
  • Le subnet ibride non supportano Google Cloud VMware Engine. Me 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, 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 carichi di lavoro nella parte on-premise di una sottorete ibrida non possono raggiungere gli endpoint Private Service Connect per le API di Google.
  • Le subnet ibride non supportano trasferimento di dati site-to-site.
  • Le subnet ibride non supportano la migrazione di carichi di lavoro da altri o la migrazione di carichi di lavoro all'interno di Google Cloud poiché questi ambienti non supportano l'ARP proxy.
  • Le subnet ibride non possono connettersi alle reti peer utilizzando Network Connectivity Center.

Considerazioni sull'utilizzo delle subnet ibride

Le seguenti sezioni descrivono considerazioni sull'utilizzo Subnet ibride.

Prestazioni 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 aiuta le subnet ibride a evitare problemi di latenza, tremolio e velocità effettiva che possono verificarsi durante le migrazioni, quando alcuni carichi di lavoro su una rete on-premise, ma è stata eseguita la migrazione di altri carichi di lavoro nel 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 Le subnet ibride evitano un problema comune con il tunneling di livello 2, dove il traffico viene inviato a un nodo centrale prima di raggiungere le destinazioni che possono essere vicine al punto di origine del traffico. Questo problema a volte viene chiamato tromboning della 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.

ARP proxy e subnet ibride

ARP proxy corrente per le subnet ibride. Ti consigliamo quanto segue per l'utilizzo dell'ARP proxy nella parte on-premise di una subnet ibrida:

  • Rivolgiti al fornitore della tua infrastruttura 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 subnet ibride evitano le sfide legate all'utilizzo dei 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 l'utilizzo di firewall e firewall esistenti con 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 sono previsti costi aggiuntivi 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 ulteriori informazioni, consulta la pagina Prezzi di Virtual Private Cloud.

Passaggi successivi