Informazioni sulla migrazione live
La migrazione live consente di controllare l'annuncio BGP dei prefissi delegati pubblici regionali v1. La migrazione live non è disponibile per impostazione predefinita. Per richiedere l'accesso, contatta il tuo Customer Engineer di Google Cloud.
Per le nuove configurazioni, ti consigliamo di creare un prefisso v2 annunciato pubblicamente, che consente di creare prefissi delegati pubblici regionali per il provisioning più rapido e un migliore controllo sull'annuncio BGP.
Per ulteriori informazioni sulla differenza tra i prefissi delegati pubblici v1 e v2, consulta Introduzione delle configurazioni IP personalizzate.
Migrazione live
La migrazione live è una funzionalità potente che richiede pianificazione ed esecuzione dettagliate.
Utilizza la migrazione live per importare un prefisso BYOIP quando una qualsiasi parte del prefisso è già pubblicizzata pubblicamente. L'importazione di un prefisso annunciato senza utilizzare Live Migration potrebbe causare una perdita imprevista di routing e di pacchetti.
La migrazione live ha una disponibilità limitata. Contatta il tuo Customer Engineer di Google Cloud per ottenere l'accesso prima di creare un prefisso delegato pubblico con la migrazione live abilitata.
Abilita la migrazione live quando crei un prefisso delegato pubblico. Per impedire a Google di pubblicizzare il prefisso annunciato pubblicamente ai peer, devi verificare quanto segue:
Tutti i prefissi delegati pubblici all'interno del prefisso annunciato pubblicamente sono configurati con un ambito regionale, non globale. Per ulteriori informazioni, leggi i consigli sulla migrazione live.
Alle risorse non viene assegnato nessun indirizzo IP nell'intervallo del prefisso annunciato pubblicamente.
La figura 2 mostra lo stesso progetto con configurazioni diverse, una delle quali impedisce la pubblicazione del prefisso e due che causano la pubblicazione del prefisso pubblicizzato dal pubblico.
La Figura 2 illustra i seguenti scenari:
Nel primo esempio di progetto, tutti i prefissi delegati pubblici nel prefisso pubblico pubblicizzato sono configurati con la migrazione live abilitata. Nessuna VM è configurata con indirizzi IP da questo prefisso.
Risultato: il prefisso annunciato pubblicamente non è annunciato.
Nel secondo esempio di progetto, tutti i prefissi delegati pubblici nel prefisso pubblico pubblicizzato sono configurati con la migrazione live abilitata. Una VM è configurata con un indirizzo IP da questo prefisso.
Risultato: il prefisso annunciato pubblicamente è pubblicizzato.
Nel terzo esempio, un prefisso delegato pubblico all'interno del prefisso pubblicizzato pubblicamente non è configurato con la migrazione live abilitata. Nessuna VM è configurata con indirizzi IP da questo prefisso.
Risultato: il prefisso annunciato pubblicamente è pubblicizzato.
Puoi controllare il momento in cui la pubblicità viene avviata assegnando indirizzi IP dal tuo prefisso delegato pubblico alle risorse Google Cloud. Per maggiori informazioni, consulta Utilizzare la migrazione live.
Al termine della migrazione live, contatta il Customer Engineer di Google Cloud in modo che possa disabilitare la migrazione live per il prefisso. Per impostazione predefinita, la migrazione live viene disattivata 30 giorni dopo l'avvio della pubblicità del prefisso annunciato pubblicamente. Se hai bisogno dell'opzione di migrazione live per più di 30 giorni, contatta il tuo Customer Engineer.
Limitazioni della migrazione live
Quando pianifichi una migrazione live, è importante comprendere i requisiti e le limitazioni seguenti:
La creazione di un prefisso delegato pubblico con la migrazione live abilitata non è supportata se l'ambito è impostato su globale. Consulta i suggerimenti per la migrazione live per informazioni su come gestire la migrazione live per le risorse globali.
Il prefisso più lungo di cui è possibile eseguire la migrazione è
/24, perché/24è la lunghezza massima del prefisso instradabile su internet.Non dare per scontato che tutti i peer di Google rispettino il prefisso più lungo tra due siti. Alcuni peer potrebbero non avere tabelle di routing complete. Di conseguenza, un prefisso più breve pubblicizzato da Google per queste app peer è l'unico (e quindi anche il più lungo) che vede il peer. Di conseguenza, l'esistenza di qualsiasi prefisso di Google ha la precedenza, anche se stai pubblicizzando una route più specifica dalla tua località on-premise.
Ad esempio:
Un cliente ha un
/23che viene instradato attivamente dalla sua località on-premise. Il cliente prevede di separare/23in due prefissi/24e annunciare le route più specifiche dalla sua posizione on-premise. A seguito della disaggregazione, pianifica di configurare un prefisso/23pubblicizzato per BYOIP. Presuppongono che le route più specifiche dalla loro località on-premise abbiano la precedenza sul prefisso BYOIP più breve e che il traffico continui a essere instradato ai prefissi on-premise più specifici.Purtroppo questo piano funziona solo parzialmente:
I peer Google che hanno tabelle di routing complete preferiscono i prefissi
/24on-premise più specifici.I peer di Google che non hanno tabelle di routing complete preferiscono il prefisso pubblicizzato pubblico annunciato da Google, poiché le loro tabelle di routing non includono i prefissi più specifici.
Il tuo traffico non viene recapitato se Google riceve traffico per un prefisso valido annunciato pubblicamente per il quale non hai eseguito il provisioning dei servizi, anche se è presente una pubblicità on-premise attiva per il prefisso.
Ad esempio:
Un cliente ha una rete on-premise che include due prefissi
/24. Il prefisso annunciato pubblicamente è il valore aggregato/23.Il cliente esegue la migrazione di un singolo
/24a Google e ritira il prefisso on-premise, ma lascia attivi gli altri/24nella località on-premise.Questa configurazione determina il routing del traffico verso Google per l'intero prefisso
/23, anche se esiste ancora un prefisso/24più specifico annunciato dalla località on-premise. Questo scenario è difficile da diagnosticare, poiché vari sistemi autonomi inoltrano il traffico alla tua località on-premise, mentre altri lo consegnano a Google, nel qual caso il traffico viene interrotto.
Suggerimenti sulla migrazione live
Come best practice, segui questi suggerimenti quando utilizzi la migrazione live.
Separa tutti i prefissi della migrazione live nei prefissi più lunghi che rispecchiano il modo in cui vuoi pubblicizzarli durante la migrazione. Negli esempi precedenti,
/23deve essere disaggregato in due prefissi/24e annunciato come tale dalla relativa località on-premise prima di creare il prefisso pubblicizzato pubblicamente.Crea richieste ROA con lunghezza esatta del prefisso e non fare affidamento sul parametro di lunghezza massima da rispettare.
Assicurati che esistano richieste ROA RPKI sia per l'ASN di origine on-premise che per l'ASN di origine di Google. Se il ROA non è disponibile per il prefisso on-premise, la creazione di un ROA di origine Google potrebbe indurre gli ISP di terze parti a filtrare questi prefissi on-premise se utilizzano il filtro RPKI automatico.
Crea prefissi annunciati pubblicamente separati per le risorse globali e le risorse regionali se devi utilizzare la migrazione live. Quando abiliti la migrazione live su un prefisso delegato pubblico, devi specificare una regione per l'ambito. Non è possibile specificare l'ambito globale per un prefisso delegato pubblico in cui è abilitata la migrazione live. Se crei un prefisso delegato pubblico con ambito globale e migrazione live abilitata, il prefisso viene pubblicizzato immediatamente.
Avere prefissi regionali in un prefisso annunciato pubblicamente e prefissi globali in un altro prefisso annunciato pubblicamente ti consente di gestirli separatamente. Puoi gestire la migrazione live delle risorse di regione e contattare il tuo Customer Engineer di Google Cloud per gestire la migrazione live delle risorse globali.