Informazioni sulle subnet ibride

Le subnet ibride consentono di combinare una subnet on-premise 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.

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

Subnet ibride e Migrate to Virtual Machines

È consigliabile 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, vedi Risorse di 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 ricevere assistenza sulla pianificazione di una migrazione a Google Cloud utilizzando Subnet ibride, invia una richiesta di assistenza.

Per informazioni su come pianificare una migrazione con Migrate to VMs, consulta 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 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 l'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. Se allow-cidr-routes-overlap è abilitato, Google Cloud consente per sovrapporsi agli intervalli di indirizzi IP della subnet.
  • 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 un ambiente ibrido una subnet.
  • 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 che contiene la subnet ibrida deve essere e configurato per esportare route personalizzate. La configurazione del peering La rete VPC deve essere configurata per importare route personalizzate.

Limitazioni

  • Il numero massimo di VM in una rete VPC che utilizza Il numero di subnet ibride è 130. Limite superato di rete 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 di trasmissione e multicast all'interno di una subnet 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, carichi di lavoro nella parte VPC di un modello una subnet non può 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 carichi di lavoro indirizzi IP prenotati nelle subnet IPv4.
  • L'inoltro in entrata di Cloud DNS non risponde alle richieste DNS da 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 di Google e servizi mediante l'accesso privato Google.
  • I carichi di lavoro nella parte on-premise di una subnet ibrida non possono raggiungere 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.
  • Una subnet ibride non può connettersi a reti peer utilizzando Network Connectivity Center.

Considerazioni sull'utilizzo delle subnet ibride

Le seguenti sezioni descrivono considerazioni sull'utilizzo 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 aiuta le subnet ibride a evitare sfide 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 ottenere associato all'incapsulamento e alla crittografia di un overlay aggiuntivo di livello 2. 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.

Subnet ibride di calcolo del percorso significa che puoi aspettarti le prestazioni di una subnet ibrida simile o uguale a una rete non utilizza subnet ibride.

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:

  • Consulta il fornitore della tua infrastruttura di rete on-premise per le best practice relative all'abilitazione dell'ARP proxy e alla protezione dell'ambiente di rete.
  • Disattiva l'ARP del proxy al termine della migrazione a in 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 solo i pacchetti all'interno o all'esterno dell'overlay endpoint, a meno che tu non adotti misure specifiche come la decrittografia trasparente o ispezioni approfondite del traffico in overlay.

Non sono necessarie considerazioni speciali per l'utilizzo di firewall e firewall esistenti con subnet ibride. Tuttavia, potresti dover Configura le regole firewall per garantire che le VM di Google Cloud possano comunicare con gli ambienti on-premise carichi di lavoro con scale out impegnativi.

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 i prezzi di Virtual Private Cloud.

Passaggi successivi