Informazioni su Hybrid Subnets

Le subnet ibride ti aiutano a eseguire la migrazione dei carichi di lavoro da un'altra rete, la rete di origine, a una subnet Virtual Private Cloud (VPC) senza dover modificare alcun indirizzo IP. Questa procedura di migrazione è chiamata Migrazione del movimento. Combinando una subnet nella rete di origine con una subnet VPC, crei una singola subnet logica che ti consente di eseguire la migrazione di singoli workload e istanze di macchine virtuali (VM) nel tempo. Dopo aver eseguito la migrazione di tutti i workload e le VM, puoi ritirare la subnet di origine.

In una subnet ibrida, un router in una rete di origine e un router Cloud in una rete VPC pubblicizzano le route utilizzando il protocollo BGP (Border Gateway Protocol) (fai clic per ingrandire).

Opzioni di migrazione

Ti consigliamo di utilizzare Migrate to Virtual Machines con le subnet ibride per automatizzare il processo di migrazione delle VM da un'origine VMware o da un'origine Google Cloud VMware Engine.

Le subnet ibride non supportano Google Cloud VMware Engine come destinazione della migrazione. Se VMware Engine è la destinazione della migrazione, ti consigliamo di migrare le VM VMware utilizzando VMware HCX. Non è necessario configurare le subnet ibride quando utilizzi VMware HCX per eseguire la migrazione a Google Cloud VMware Engine.

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 ulteriori informazioni sulle opzioni di migrazione, vedi Risorse per la migrazione.

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

Specifiche

  • Le subnet ibride richiedono un prodotto di connettività di rete come Cloud VPN o Cloud Interconnect.
  • Proxy ARP deve essere configurato nella rete di origine.
  • La rete di origine deve essere configurata per annunciare l'intervallo di indirizzi IP della subnet ibrida.
  • L'intervallo di indirizzi IPv4 principale della subnet VPC deve corrispondere all'intervallo di indirizzi IP della subnet di origine.
  • Devi abilitare il flag allow-cidr-routes-overlap di una subnet VPC per configurarla come subnet ibrida. Quando allow-cidr-routes-overlap è abilitato, Trusted Cloud consente alle route personalizzate di sovrapporsi agli intervalli di indirizzi IP delle subnet.
  • Il flag allow-cidr-routes-overlap si applica agli intervalli di subnet IPv4 principali e secondari.
  • La connettività interna viene mantenuta tra tutte le VM e i workload in una subnet ibrida.
  • Utilizzi le route pubblicizzate personalizzate del router Cloud per annunciare in modo selettivo gli indirizzi IP delle VM durante la migrazione alla subnet VPC.
  • Man mano che esegui la migrazione dei carichi di lavoro da una rete di origine a Trusted Cloud, aggiorni le route personalizzate annunciate dal 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 che contiene la subnet ibrida deve essere configurata per esportare route personalizzate. La configurazione del peering per l'altra rete VPC deve essere configurata per importare route personalizzate.

Limitazioni

  • Le reti VPC che utilizzano subnet ibride presentano le seguenti limitazioni delle risorse:

    Queste limitazioni delle risorse non vengono applicate da limiti o quote. Trusted Cloud by S3NS Il superamento di questi limiti potrebbe causare problemi di connettività e stabilità.

  • Il router Cloud di una subnet ibrida non può superare il numero massimo di route personalizzate annunciate per sessione BGP.

  • Il traffico di broadcast e multicast all'interno di una subnet 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 subnet ibride non possono ospitare carichi di lavoro indirizzi IP riservati nelle subnet IPv4.

  • L'inoltro in entrata di Cloud DNS non risponde alle richieste DNS dei carichi di lavoro nella rete di origine.

  • I carichi di lavoro nella rete di origine non possono raggiungere le API e i servizi di Google utilizzando l'accesso privato Google.

  • I workload nella rete di origine non possono raggiungere gli endpoint Private Service Connect per le API di Google.

  • I carichi di lavoro nella rete di origine non possono essere endpoint per i gruppi di endpoint di rete con connettività ibrida che utilizzano controlli di integrità centralizzati.

  • Le subnet ibride non supportano il trasferimento di dati site-to-site.

  • Non puoi connettere una subnet ibrida a un'altra subnet ibrida.

  • Le subnet ibride non rilevano conflitti di indirizzi IP tra la rete di origine e le parti VPC di una subnet ibrida. Assicurati che ogni indirizzo IP (ad eccezione del gateway predefinito) venga utilizzato una sola volta.

  • Le subnet ibride non supportano Google Cloud VMware Engine come destinazione della migrazione.

  • Le subnet ibride non supportano la migrazione di VM da un'origine Azure o AWS.

  • Le subnet ibride non supportano la migrazione dei carichi di lavoro da altri provider di servizi cloud.

  • Le subnet ibride non supportano Network Connectivity Center.

Considerazioni sull'utilizzo di Hybrid Subnets

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

Proxy ARP e subnet ibride

Le subnet ibride richiedono che il proxy ARP sia configurato sul dispositivo di primo hop della rete di origine. Un dispositivo di primo hop è il punto in cui un host invia per la prima volta traffico con una destinazione al di fuori della sua rete locale. Il proxy ARP consente al dispositivo di rispondere con il proprio indirizzo MAC quando riceve richieste ARP per le VM che si trovano nella parte VPC di una subnet ibrida. Il dispositivo può quindi inoltrare i pacchetti alle VM nella subnet VPC utilizzando i blocchi CIDR che ha appreso dalle route personalizzate pubblicizzate della sessione BGP (Border Gateway Protocol) sul router Cloud.

Il dispositivo di primo hop può essere un router, un'appliance virtuale, un firewall o una VM che esegue una soluzione software come choparp.

Ti consigliamo quanto segue per l'utilizzo di ARP proxy nella rete di origine:

  • Consulta il fornitore del fabric di rete di origine per le best practice relative all'attivazione di proxy ARP e alla protezione dell'ambiente di rete.
  • Disattiva il proxy ARP dopo aver completato la migrazione a Trusted Cloud.

Prestazioni di rete

Le subnet ibride utilizzano il livello 3 del modello OSI per instradare i pacchetti tra la rete di origine e le parti VPC di una subnet ibrida. Questo approccio aiuta Hybrid Subnets a evitare problemi di latenza, jitter e velocità effettiva che possono verificarsi durante le migrazioni quando alcuni carichi di lavoro esistono su una rete di origine, ma altri sono stati migrati nel cloud.

In particolare, evitare il tunneling di livello 2 aiuta a prevenire 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 subnet 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 le destinazioni che possono essere vicine al punto di origine del traffico. Questo problema è talvolta chiamato tromboning di rete.

L'approccio di Hybrid Subnets al routing significa che puoi aspettarti prestazioni da una subnet ibrida simili o uguali a quelle di una rete che non utilizza Hybrid Subnets.

Firewall e subnet ibride

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

Non sono necessarie considerazioni speciali per utilizzare firewall e regole firewall esistenti con le subnet ibride. Tuttavia, potresti dover configurare le regole firewall per assicurarti che le VM possano comunicare con i carichi di lavoro nella rete di origine. Trusted Cloud

Passaggi successivi