Informazioni sulla migrazione live
La migrazione live consente di controllare l'annuncio BGP dei prefissi delegati pubblici a livello di regione 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 a livello di regione per eseguire più rapidamente il provisioning e offrire un controllo maggiore sull'annuncio BGP.
Per saperne di più sulla differenza tra i prefissi con delega pubblici v1 e v2, consulta Bring Your Own IP Configurations (Bring le tue configurazioni IP).
Migrazione live
La migrazione live è una potente funzionalità 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 pubblicizzato senza utilizzare la migrazione live potrebbe causare un routing e una perdita di pacchetti imprevisti.
La migrazione live ha una disponibilità limitata. Contatta il Customer Engineer di Google Cloud per ottenere l'accesso prima di creare un prefisso delegato pubblico con migrazione live abilitata.
Puoi abilitare la migrazione live quando crei un prefisso delegato pubblico. Per impedire a Google di pubblicizzare il prefisso annunciato pubblicamente ad app peer, devi garantire quanto segue:
Tutti i prefissi delegati pubblici all'interno del prefisso annunciato pubblico sono configurati con l'ambito regionale, non globale. Per ulteriori informazioni, consulta i suggerimenti per la migrazione live.
Nessun indirizzo IP nell'intervallo del prefisso annunciato pubblico viene assegnato alle risorse.
La Figura 2 mostra lo stesso progetto con configurazioni diverse, una delle quali impedisce la promozione del prefisso e due causa la promozione del prefisso pubblicizzato 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 con questo prefisso.
Risultato: il prefisso annunciato pubblicamente non è pubblicizzato.
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 di questo prefisso.
Risultato: il prefisso annunciato pubblicamente viene pubblicizzato.
Nel terzo esempio di progetto, un prefisso delegato pubblico all'interno del prefisso pubblico annunciato non è configurato con la migrazione live abilitata. Nessuna VM è configurata con indirizzi IP con questo prefisso.
Risultato: il prefisso annunciato pubblicamente viene pubblicizzato.
Puoi stabilire quando inizia la pubblicità assegnando gli indirizzi IP dal prefisso delegato pubblico alle risorse Google Cloud. Per ulteriori informazioni, consulta Utilizzare la migrazione live.
Al termine della migrazione live, contatta il tecnico del cliente Google Cloud in modo che possa disattivare la migrazione live per il prefisso. Per impostazione predefinita, la migrazione live viene disattivata 30 giorni dopo l'avvio della pubblicità del prefisso pubblicizzato pubblico. Se è necessario che l'opzione di migrazione live sia disponibile per più di 30 giorni, contatta il tuo Customer Engineer.
Limitazioni della migrazione live
Quando pianifichi una migrazione live, è importante che tu comprenda i seguenti requisiti e limitazioni:
La creazione di un prefisso delegato pubblico con migrazione live abilitata non è supportata se l'ambito è impostato su globale. Consulta i suggerimenti per la migrazione live per informazioni sulla gestione della migrazione live per le risorse globali.
Il prefisso più lungo di cui è possibile eseguire la migrazione è un
/24perché/24è la lunghezza massima del prefisso instradabile su internet.Non dare per scontato che tutte le app 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 i peer è l'unico (e quindi anche il più lungo) che il peer vede. Di conseguenza, l'esistenza di qualsiasi prefisso da Google ha la precedenza, anche se pubblicizzi 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 località on-premise. A seguito della disaggregazione, pianifica la configurazione di un prefisso/23pubblicizzato pubblicamente per BYOIP. Presumono che le route più specifiche della 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 on-premise
/24più specifici.I peer di Google che non dispongono di tabelle di routing complete preferiscono il prefisso pubblico annunciato da Google, poiché le loro tabelle di routing non includono i prefissi più specifici.
Il 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 comprende due prefissi
/24. Il prefisso annunciato pubblicamente è/23aggregato.Il cliente esegue la migrazione di un singolo
/24a Google e ritira il prefisso on-premise, ma lascia l'altro/24attivo nella località on-premise.Questa configurazione comporta una parte del routing del traffico a Google per l'intero prefisso
/23, anche se viene annunciato un prefisso/24più specifico dalla località on-premise. Questo scenario è difficile da diagnosticare, poiché vari sistemi autonomi consegnano il traffico alla tua località on-premise, mentre altri lo indirizzano a Google, nel qual caso il traffico viene ridotto.
Suggerimenti per la migrazione live
Come best practice, segui questi suggerimenti quando utilizzi la migrazione live.
Disaggrega tutti i prefissi della migrazione live nei prefissi più lunghi che riflettono il modo in cui vuoi pubblicizzare questi prefissi durante la migrazione. Negli esempi precedenti,
/23deve essere separato in due prefissi/24e annunciato come tale a partire dalla sua posizione on-premise prima di creare il prefisso pubblicizzato pubblico.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. In assenza di un ROA per il prefisso on-premise, la creazione di un ROA di origine Google potrebbe far sì che gli ISP di terze parti escludano i prefissi on-premise se utilizzano il filtro RPKI automatico.
Crea prefissi pubblici separati per le risorse globali e per 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 abilitati, il prefisso viene pubblicizzato immediatamente.
Avere prefissi regionali in un prefisso annunciato pubblico e prefissi globali in un altro prefisso annunciato pubblicamente per 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.