Connettività di rete per migrazioni PostgreSQL omogenee standard

Questa pagina fornisce una panoramica dei concetti associati alla configurazione della connettività di rete per le migrazioni PostgreSQL omogenee standard ad AlloyDB per PostgreSQL. Per informazioni sulla connettività della migrazione rapida, consulta la guida Utilizza le migrazioni rapide.

Dopo aver acquisito familiarità con i diversi metodi di connettività e i relativi requisiti, puoi utilizzare il diagramma dell'albero decisionale per scegliere la soluzione giusta per il tuo scenario.

Componenti di rete coinvolti nel processo di migrazione

Per le migrazioni PostgreSQL omogenee ad AlloyDB per PostgreSQL, Database Migration Service si connette al cluster AlloyDB per PostgreSQL di destinazione e poi gestisce il processo di migrazione per suo conto. È il cluster di destinazione che stabilisce la connessione all'istanza di origine, mentre Database Migration Service supervisiona il processo.

Panoramica del flusso di migrazione di PostgreSQL
Figura 1. Spostamento dei dati durante le migrazioni di Database Migration Service per PostgreSQL. (fai clic per ingrandire)
Panoramica del flusso di migrazione di PostgreSQL

Quando pianifichi la configurazione della connessione di rete per la migrazione, è importante considerare attentamente i requisiti dell'infrastruttura, incluse le limitazioni che le tue decisioni di networking potrebbero introdurre nello stato finale del cluster di database di cui è stata eseguita la migrazione. Ad esempio, se vuoi utilizzare una connessione privata per la connettività di rete, devi utilizzare un cluster AlloyDB per PostgreSQL di destinazione configurato con l'accesso privato ai servizi o Private Service Connect.

Disponibilità dei metodi di connettività

Sono disponibili diversi metodi di connettività per i vari database di origine, a seconda che la migrazione venga eseguita verso un cluster di destinazione nuovo o esistente. La tabella seguente fornisce una panoramica di quale scenario supporta quale metodo:

Offerta di database di origine Metodi per le migrazioni a nuovi cluster di destinazione Metodi per le migrazioni ai cluster di destinazione esistenti
Self-hosted Lista consentita di IP, tunnel SSH inverso, peering VPC, proxy TCP tramite una VM ospitata nel cloud Lista consentita di IP, tunnel SSH inverso, peering VPC (richiede un cluster di destinazione PSA), proxy TCP tramite una VM ospitata nel cloud, interfacce PSC (richiede un cluster di destinazione abilitato per PSC)
Amazon Aurora, Amazon RDS Lista consentita di IP, tunnel SSH inverso, peering VPC Lista consentita di IP, tunnel SSH inverso, peering VPC (richiede un cluster di destinazione PSA), interfacce PSC (richiede un cluster di destinazione abilitato per PSC)
Cloud SQL per PostgreSQL Lista consentita IP (non consigliata), peering VPC, proxy TCP tramite una VM ospitata nel cloud Lista consentita IP (non consigliata), peering VPC, proxy TCP tramite una VM ospitata nel cloud, interfacce PSC (richiede un cluster di destinazione abilitato per PSC)

Confronto tra i metodi di connettività

Ogni metodo di connettività offre vantaggi e requisiti diversi. Utilizza le seguenti tabelle per confrontarli a colpo d'occhio e poi scopri maggiori dettagli nelle sezioni dedicate a ciascun metodo.

Metodo di networking Vantaggi Svantaggi
Lista consentita di IP
  • Il metodo di connettività più semplice da configurare.
  • Utile quando non è possibile raggiungere il database di origine tramite reti private in Google Cloud.
  • Richiede l'esposizione di un indirizzo IPv4 del server del database di origine alla rete internet pubblica. Ciò richiede misure di sicurezza aggiuntive. Ad esempio, ti consigliamo di utilizzare certificati TLS e regole firewall per proteggere la connessione.
  • La configurazione delle regole del firewall potrebbe richiedere l'assistenza del reparto IT o della sicurezza di rete.
Tunnel SSH inverso
  • Più sicuro rispetto alla connessione tramite IP pubblico con una lista consentita IP.

    La connessione iniziale viene stabilita tramite porte Secure Shell (SSH) sulla rete internet pubblica. Una volta attiva la connessione, tutto il traffico viaggia attraverso un tunnel privato sicuro verso la porta PostgreSQL 5432.

  • Utile quando il database di origine non è raggiungibile tramite reti private in Google Cloud, ma non vuoi esporre il server del database di origine direttamente alla rete internet pubblica.
  • L'utilizzo di un server intermedio (la macchina del tunnel SSH inverso) per la connettività potrebbe introdurre una latenza aggiuntiva.
  • Devi configurare e gestire il server host SSH inverso. Il server deve rimanere online per l'intera durata della migrazione.
Interfacce Private Service Connect
  • Stabilisce connessioni all'IP privato di origine utilizzando un collegamento di rete. Questo metodo non consuma la quota di peering nel VPC.
  • Il metodo di connettività privata di origine più semplice e consigliato da configurare.
  • Supportato solo per le migrazioni ai cluster di destinazione AlloyDB per PostgreSQL esistenti. Se vuoi utilizzare questo metodo, devi creare il cluster di destinazione direttamente in AlloyDB per PostgreSQL.
  • Richiede la configurazione di un collegamento di rete e la modifica delle regole firewall.
  • Non puoi modificare il collegamento di rete dopo aver stabilito la connessione.
Proxy TCP tramite una VM ospitata nel cloud
  • Collega la connettività privata quando il routing diretto non è possibile a causa del peering VPC non transitivo (ad esempio durante la migrazione da origini Cloud SQL per PostgreSQL che utilizzano l'architettura di rete producer precedente o quando si collegano reti VPC separate).
  • Database Migration Service genera automaticamente uno script di configurazione per eseguire il deployment e configurare la VM proxy.
  • Devi configurare e gestire la VM proxy di Compute Engine, il che potrebbe comportare costi di computing aggiuntivi.
Connettività privata con peering Virtual Private Cloud La connessione viene stabilita all'indirizzo IP privato del database di origine tramite peering VPC. Se il tuo VPC non dispone di una quota di peering sufficiente, potrebbe essere difficile utilizzare questo metodo di connettività. Per la maggior parte degli scenari in cui esegui la migrazione a un cluster AlloyDB per PostgreSQL esistente, ti consigliamo di utilizzare Connettività privata con interfacce Private Service Connect.

Lista consentita di IP per la connettività al database di origine

Quando utilizzi il metodo di connettività con lista consentita di IP, AlloyDB per PostgreSQL tenta di stabilire una connessione a un indirizzo IP disponibile pubblicamente del server del database di origine sulla porta PostgreSQL 5432.

Diagramma che mostra la connettività della lista consentita di IP pubblici per le migrazioni omogenee.
Figura 2. Diagramma della connettività di rete della lista consentita di IP per le migrazioni PostgreSQL omogenee. (fai clic per ingrandire)
Diagramma che mostra la connettività della lista consentita di IP pubblici per le migrazioni omogenee.

Requisiti per la connettività con lista consentita IP

In linea generale, per utilizzare questo metodo di connettività devi assicurarti di quanto segue:

  • Devi esporre l'indirizzo IP del database di origine alla rete internet pubblica (direttamente o con un nome host riconosciuto pubblicamente tramite un Domain Name Server (DNS)).

  • L'istanza principale AlloyDB per PostgreSQL di destinazione deve avere un IP pubblico in uscita abilitato. Il database di origine deve consentire le connessioni in entrata da entrambi gli indirizzi IP pubblici in uscita dell'istanza principale di destinazione.

Configura la connettività della lista consentita IP

La configurazione della connettività IP pubblica richiede passaggi diversi a seconda del tipo di database di origine. Per saperne di più, vedi:

Connettività del database del tunnel SSH inverso

Questo metodo di connettività è una combinazione di connettività di rete pubblica e privata. La connessione stessa viene stabilita tramite le porte Secure Shell (SSH) all'indirizzo IP pubblico del server host del tunnel. Una volta attiva la connessione, tutto il traffico viaggia su un tunnel sicuro verso l'indirizzo IP privato del database di origine sulla porta 5432.

Per le origini Cloud SQL o le soluzioni self-hosted che si trovano all'interno di Google Cloud, ti consigliamo di utilizzare i metodi di connettività privata con interfacce Private Service Connect o di connettività privata con peering Virtual Private Cloud.

Un diagramma di networking che mostra una configurazione di connettività di alto livello su un server SSH dedicato.
Figura 3. Esempio di networking di migrazione: connettività di origine tramite un tunnel SSH. (fai clic per ingrandire)
Un diagramma di networking che mostra una configurazione di connettività di alto livello su un server SSH dedicato.

Requisiti per i tunnel SSH inversi

Per creare la connessione, devi esporre le porte SSH alla rete internet pubblica sul server del tunnel (noto anche come bastion host). Una volta stabilita la connettività, tutto il traffico viene instradato tramite la connessione del tunnel privato.

Questo metodo richiede componenti di rete aggiuntivi:

  • Una macchina virtuale (VM) in Google Cloud che funga da macchina SSH inversa.
  • Un computer aggiuntivo sulla tua rete con connettività al database di origine.

Configura la connettività del tunnel SSH inverso

Database Migration Service può generare uno script di configurazione per creare la VM SSH inversa, ma il processo end-to-end completo varia a seconda del tipo di database di origine. Per saperne di più, consulta Configura la connettività SSH inversa.

Connettività privata con le interfacce Private Service Connect

Questo metodo di connettività ti consente di connetterti all'IP privato del tuo database di origine senza consumare la quota di peering VPC. Le interfacce Private Service Connect sono il metodo consigliato per la connettività IP privata, ma sono disponibili solo quando esegui la migrazione a un cluster esistente.

Quando utilizzi le interfacce Private Service Connect, il cluster di destinazione non consuma ulteriore quota di peering. Utilizza invece l'interfaccia Private Service Connect per raggiungere il Virtual Private Cloud in cui è possibile raggiungere l'IP privato del database di origine. A seconda dell'architettura di rete, potresti dover utilizzare componenti aggiuntivi come Cloud VPN o Cloud Interconnect.

Diagramma che mostra la connettività di Private Service Connect con Cloud VPN per le migrazioni omogenee.
Figura 4. Connettività di rete con interfacce Private Service Connect per migrazioni omogenee da origini che si trovano al di fuori di Google Cloud. (fai clic per ingrandire)
Diagramma che mostra la connettività di Private Service Connect con Cloud VPN per le migrazioni omogenee.

Per le migrazioni da istanze Cloud SQL per PostgreSQL, l'istanza di origine deve essere abilitata per l'accesso privato ai servizi e deve essere in peering con il Virtual Private Cloud in cui crei il collegamento di rete, ma il cluster AlloyDB per PostgreSQL di destinazione non consuma ulteriore quota di peering. Utilizza invece l'interfaccia Private Service Connect.

Diagramma che mostra la connettività di rete per le migrazioni con interfacce Private Service Connect.
Figura 5. Connettività di rete con interfacce Private Service Connect per migrazioni omogenee da Cloud SQL per PostgreSQL. (fai clic per ingrandire)
Diagramma che mostra la connettività di rete per le migrazioni con interfacce Private Service Connect.

Requisiti per le interfacce Private Service Connect

Questo metodo di connettività richiede quanto segue:

  • Il cluster di database di destinazione deve essere un cluster AlloyDB per PostgreSQL con PSC abilitato.

  • Devi disporre di una rete Virtual Private Cloud con accesso privato ai servizi abilitato.

    Questa è la rete in cui crei il collegamento di rete. L'IP del tuo database di origine deve essere raggiungibile da quel Virtual Private Cloud. Ad esempio, per le origini Cloud SQL per PostgreSQL, questa è la rete di cui esegui il peering con l'istanza Cloud SQL di origine abilitata per PSA.

Configura la connettività IP privato con le interfacce Private Service Connect

Per utilizzare la connettività con IP privato con le interfacce Private Service Connect, l'IP privato del database di origine deve essere raggiungibile dal tuo Virtual Private Cloud. A seconda dell'architettura di rete, potresti dover utilizzare componenti aggiuntivi come Cloud VPN o Cloud Interconnect.

Per scoprire di più sulla configurazione della connettività con IP privato per diverse origini di database, consulta:

Proxy TCP tramite una VM ospitata nel cloud

Questo metodo di connettività è un'alternativa quando vuoi utilizzare la connettività privata tramite il peering Virtual Private Cloud, ma il peering VPC non transitivo impedisce il routing diretto tra il database di origine e il cluster AlloyDB per PostgreSQL di destinazione.

Questo scenario si verifica più comunemente durante la migrazione da un'istanza Cloud SQL per PostgreSQL che utilizza la precedente architettura di rete del producer a un cluster AlloyDB per PostgreSQL di destinazione configurato con l'accesso privato ai servizi (PSA). Poiché entrambi i servizi risiedono in reti producer separate gestite da Google e il peering VPC non è transitivo, il traffico non può fluire direttamente tra loro. Si applica anche quando il database di origine in hosting autonomo e il cluster AlloyDB per PostgreSQL di destinazione si trovano in reti VPC in peering separate o quando i requisiti delle norme di sicurezza aziendali richiedono il routing del traffico di migrazione tramite un singolo indirizzo IP interno statico.

Una VM Compute Engine intermedia nella tua rete VPC funge da bridge, accettando le connessioni di replica in entrata sulla porta 5432 dall'istanza principale AlloyDB per PostgreSQL di destinazione e inoltrandole al database di origine.

Un diagramma dell'architettura per una connessione di database privata che utilizza la VM proxy TCP.
Figura 6. Una connessione privata facilitata dalla VM proxy TCP. (fai clic per ingrandire)
Un diagramma dell'architettura per una connessione di database privata che utilizza la VM proxy TCP.

Requisiti per la connettività mediante proxy TCP

Questo metodo di connettività richiede quanto segue:

  • Una VM Compute Engine nella rete Virtual Private Cloud in peering con il cluster AlloyDB per PostgreSQL di destinazione per eseguire il container del proxy TCP.
  • Connettività di rete dalla VM proxy all'istanza del database di origine.

Configura la connettività del proxy TCP

Quando crei un job di migrazione nella console Google Cloud , Database Migration Service raccoglie i parametri richiesti e genera uno script gcloud che crea la VM container proxy di Compute Engine e la regola firewall in entrata necessaria nel tuo VPC. Per istruzioni passo passo, consulta Configura la connettività utilizzando un proxy TCP tramite una VM ospitata nel cloud.

Connettività privata con peering VPC

Questo metodo ti consente di connetterti all'origine tramite gli indirizzi IP privati nel tuo Virtual Private Cloud (VPC). Non è necessario esporre alcuna interfaccia a internet pubblico per utilizzare questo metodo, ma è necessario che l'indirizzo IP o il nome host del database di origine siano raggiungibili dal tuo VPC Google Cloud . Per le origini che si trovano al di fuori di Google Cloud, potresti aver bisogno di componenti di rete aggiuntivi, come Cloud VPN o Cloud Interconnect.

Diagramma che mostra la connettività di peering Virtual Private Cloud per le migrazioni PostgreSQL omogenee.
Figura 7. Connettività di rete con peering Virtual Private Cloud per migrazioni PostgreSQL omogenee. (fai clic per ingrandire)
Diagramma che mostra la connettività di peering Virtual Private Cloud per le migrazioni PostgreSQL omogenee.

Requisiti per la connettività IP privata con peering VPC

La connettività con IP privato con peering VPC richiede quanto segue:

Configura la connettività IP privato con il peering VPC

Per utilizzare la connettività IP privato con il peering Virtual Private Cloud, l'IP privato del database di origine deve essere raggiungibile dal tuo Virtual Private Cloud. A seconda dell'architettura di rete, potresti dover utilizzare componenti aggiuntivi come Cloud VPN o Cloud Interconnect.

Per scoprire di più sulla configurazione della connettività con IP privato per diverse origini di database, consulta:

Albero decisionale della connettività di rete

Una volta acquisita familiarità con tutti i metodi di connettività supportati e i relativi requisiti, puoi seguire le domande nel diagramma per scegliere il metodo di connettività giusto per il tuo scenario.

Un diagramma ad albero decisionale con domande guida per aiutarti a scegliere il metodo di connettività giusto.
Figura 8. Albero decisionale per la connettività di rete di origine.

Passaggi successivi