Informazioni sulla migrazione live
La migrazione live consente di controllare l'annuncio BGP della versione 1 pubblica a livello di regione prefissi delegati. La migrazione live non è disponibili per impostazione predefinita. Per richiedere l'accesso, contatta il tuo team Google Cloud Customer Engineer.
Per le nuove configurazioni, ti consigliamo di creare un annuncio pubblico v2 che ti consente di creare delegazioni pubbliche a livello di regione prefissi che eseguono il provisioning più rapidamente e offrono controllo dell'annuncio BGP.
Per ulteriori informazioni sulla differenza tra v1 e v2 con delega pubblica prefissi, consulta l'articolo Aggiungere il tuo indirizzo IP configurazioni.
Migrazione live
La migrazione live è una potente funzionalità che richiede una pianificazione dettagliata e dell'esecuzione.
Utilizza la migrazione live per importare un prefisso BYOIP se una sua parte è sono già stati annunciati pubblicamente. Importare un prefisso annunciato senza utilizzare live potrebbe causare una perdita imprevista di routing e di pacchetti.
La migrazione live ha una disponibilità limitata. Contatta il tuo team Google Cloud Customer Engineer per ottenere l'accesso prima di creare un prefisso delegato pubblico con Migrazione live abilitata.
Abilita la migrazione live quando crei un prefisso delegato pubblico. Per evitare a Google di pubblicizzare il prefisso annunciato pubblicamente ai peer, devi assicurarti le seguenti:
Tutti i prefissi delegati pubblici all'interno del prefisso annunciato pubblicamente sono configurato con un ambito regionale, non globale. Consulta la sezione sulla migrazione live raccomandazioni per ulteriori informazioni.
Nessun indirizzo IP assegnato nell'intervallo del prefisso annunciato pubblicamente Google Cloud.
La Figura 2 mostra lo stesso progetto con diverse configurazioni, una delle quali impediscono al prefisso di essere pubblicizzato, mentre due, che causano la pubblicazione prefisso annunciato da pubblicizzare.
La Figura 2 illustra i seguenti scenari:
Nel primo esempio di progetto, tutti i prefissi delegati pubblici nel pubblico Il prefisso annunciato è configurato con la migrazione live abilitata. Nessuna VM è configurate con indirizzi IP da questo prefisso.
Risultato: il prefisso annunciato pubblicamente non è annunciato.
Nel secondo esempio, tutti i prefissi delegati pubblici nel pubblico Il prefisso annunciato è configurato con la migrazione live abilitata. Una VM è configurate con un indirizzo IP da questo prefisso.
Risultato: il prefisso annunciato pubblicamente è pubblicizzato.
Nel terzo esempio, un prefisso delegato pubblico all'interno Il prefisso annunciato non è configurato con la migrazione live abilitata. Nessuna VM è configurate con indirizzi IP da questo prefisso.
Risultato: il prefisso annunciato pubblicamente è pubblicizzato.
Puoi controllare quando inizia l'annuncio assegnando indirizzi IP dal tuo prefisso delegato pubblico alle risorse Google Cloud. Per ulteriori informazioni le informazioni, vedi Utilizzare la migrazione live.
Al termine della migrazione live, contatta il tuo cliente Google Cloud che possa disabilitare la migrazione live per il tuo prefisso. Per impostazione predefinita, la migrazione live viene disattivata 30 giorni dopo l'avvio della pubblicità al pubblico prefisso annunciato. Se l'opzione di migrazione live sia disponibile per più di 30 giorni, contatta il Customer Engineer.
Limitazioni della migrazione live
Quando pianifichi una migrazione live, è importante comprendere le i seguenti requisiti e limitazioni:
La creazione di un prefisso delegato pubblico con la migrazione live abilitata non è supportati se l'ambito è impostato su globale. Consulta la sezione sulla migrazione live di Google Cloud per ottenere informazioni per la gestione della migrazione live delle risorse globali.
Il prefisso più lungo di cui è possibile eseguire la migrazione è
/24perché/24è lunghezza massima del prefisso di routing 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, viene generato pubblicizzato da Google per i peer è l'unico (e, di conseguenza, anche più lungo) visibile dal peer. Di conseguenza, l'esistenza di qualsiasi prefisso di Google ha la precedenza, anche se pubblicizzi un percorso più specifico dalla località on-premise.
Ad esempio:
Un cliente ha un
/23che viene instradato attivamente dalle sue strutture on-premise in ogni località. Il cliente prevede di separare/23in due/24e annunciano le route più specifiche dalle loro infrastrutture in ogni località. A seguito della disaggregazione, pianifica di configurare un/23pubblico Prefisso pubblicizzato per BYOIP. Partono dal presupposto che i percorsi più specifici la loro posizione on-premise ha la precedenza sul prefisso BYOIP più breve e che il traffico continui a essere instradato verso prefissi on-premise più specifici.Purtroppo questo piano funziona solo parzialmente:
I peer di Google che hanno tabelle di routing complete preferiscono
/24prefissi on-premise.I peer Google che non hanno tabelle di routing complete preferiscono il pubblico prefisso annunciato annunciato da Google, poiché le relative tabelle di routing non includi i prefissi più specifici.
Il traffico non viene recapitato se Google riceve traffico per un prefisso annunciato pubblicamente per il quale non hai eseguito il provisioning di servizi, anche se esiste un annuncio on-premise attivo 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
/24su Google e ritira l'offerta on-premise ma lascia attivo l'altro/24nella località on-premise.Questa configurazione determina l'indirizzamento di una parte del traffico a Google per prefisso
/23intero, anche se esiste ancora un prefisso/24più specifico annunciato dalla località on-premise. Questo scenario è difficile da diagnostica, poiché diversi Sistemi autonomi distribuiscono il traffico ai server di destinazione, mentre altri la consegnano a Google e in questo 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 che riflettano il modo in cui vuoi pubblicizzare questi prefissi durante la migrazione. Nella esempi precedenti,
/23deve essere disaggregato in due prefissi/24e annunciate come tali dalla loro posizione on-premise prima di creare prefisso annunciato.Crea richieste ROA con lunghezza esatta del prefisso e non fare affidamento sulla lunghezza massima. parametro da rispettare.
Assicurati che esistano richieste ROA RPKI sia per l'ASN di origine on-premise che per l'ASN L'ASN di origine di Google. Se non esiste un ROA per il prefisso on-premise, la creazione di un ROA di origine Google potrebbero indurre gli ISP di terze parti a filtrare questi on-premise che usano il filtro RPKI automatico.
Crea prefissi annunciati pubblicamente separati per le risorse globali e a livello di regione se devi usare la migrazione live. Quando abiliti la migrazione live su un prefisso delegato pubblico, devi specificare una regione per l'ambito. Specificare l'ambito globale per un prefisso delegato pubblico con la migrazione live abilitata è non supportati. 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. Tu gestire la migrazione live delle risorse di regione e contattare il tuo Customer Engineer di Google Cloud per la gestione della migrazione live nell'ambiente globale Google Cloud.