Per creare una migrazione in Database Migration Service, è necessario stabilire la connettività tra l'istanza di origine e l'istanza di destinazione AlloyDB. Sono supportati vari metodi. Scegli quella più adatta
al carico di lavoro specifico.
Metodo di networking
Descrizione
Vantaggi
Svantaggi
Lista consentita di indirizzi IP
Questo metodo funziona configurando il server di database di origine in modo che accetti connessioni
dall'IP in uscita dell'istanza Cloud SQL.
Se scegli questo metodo, Database Migration Service ti guida
nella procedura di configurazione durante la creazione della migrazione.
Facile da configurare.
Non richiede alcuna configurazione firewall personalizzata.
Il traffico di rete avviene tramite la rete internet pubblica.
Meno sicura.
Rendimento ridotto.
Proxy tramite VM con hosting nel cloud - Tunnel SSH inverso
Stabilisce la connettività dalla destinazione all'origine tramite un
tunnel SSH inverso sicuro.
Richiede una VM bastion host nel progetto Google Cloud della piattaforma, nonché una macchina (ad esempio un laptop sulla rete) che abbia la connettività all'origine.
Database Migration Service raccoglie le informazioni richieste al momento della creazione della migrazione e genera automaticamente lo script per configurare tutto.
Facile da configurare.
Non richiede alcuna configurazione firewall personalizzata.
Consigliato per scenari di migrazione di breve durata (POC o piccole
migrazioni di database).
La VM bastion è di tua proprietà e viene gestita da te e potrebbe comportare costi aggiuntivi.
Proxy tramite VM ospitata nel cloud - TCP
Stabilisce la connettività dalla destinazione all'origine utilizzando un proxy TCP tramite una VM ospitata nel cloud.
Database Migration Service raccoglie le informazioni richieste al momento della creazione della migrazione e genera automaticamente lo script per configurare tutto.
Pertinente per le migrazioni AlloyDB in cui l'origine si trova nella vecchia architettura di rete.
Facile da configurare.
Non richiede alcuna configurazione firewall personalizzata.
La VM bastion è di tua proprietà e viene gestita da te e potrebbe comportare costi aggiuntivi.
Peering VPC
Questo metodo funziona configurando i VPC in modo che comunichino tra loro.
Soluzione Google Cloud nativa.
Facile da configurare.
Larghezza di banda elevata.
Consigliato per migrazioni di lunga durata o di grandi volumi.
Applicabile se i database di origine e di destinazione sono ospitati in
Google Cloudo se l'origine è connessa al VPC di destinazione
utilizzando una VPN (ospitata nel cloud o on-premise) o Cloud Interconnect.
Interfacce Private Service Connect
Le interfacce Private Service Connect consentono al database di destinazione
di avviare connessioni all'IP privato del database di origine
senza utilizzare la quota di peering. Questo metodo di connettività
utilizza invece i collegamenti di rete che crei nel tuo VPC.
Stabilisce connessioni all'IP privato di origine utilizzando un collegamento di rete.
Questo metodo non utilizza la quota di peering nel tuo VPC.
Il metodo di connettività privata dell'origine più semplice da configurare.
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.
Per saperne di più sull'accesso privato ai servizi e su
Private Service Connect in
AlloyDB per PostgreSQL,
consulta la panoramica dell'IP privato
nella documentazione di AlloyDB per PostgreSQL.
Limitazioni di connettività
La connettività da PostgreSQL ad AlloyDB presenta le seguenti limitazioni:
AlloyDB supporta la connettività privata utilizzando l'accesso privato ai servizi. L'assegnazione di un indirizzo IP pubblico a un cluster non è supportata.
Non puoi modificare il VPC con cui viene eseguito il peering del cluster AlloyDB dopo la creazione del cluster.
Poiché AlloyDB utilizza l'accesso ai servizi privati che internamente utilizza il peering VPC, il peering transitivo non è supportato. Il cluster AlloyDB può raggiungere solo gli indirizzi IP interni nello stesso VPC con cui è in peering. Per raggiungere altri VPC, devi utilizzare un proxy intermedio. Per ulteriori dettagli, consulta la sezione seguente.
Scenari di connettività comuni e relative soluzioni
Esegui la migrazione da un'istanza Cloud SQL nella vecchia architettura di rete del produttore
Figura 1. Una connessione privata facilitata dalla VM proxy TCP
(fai clic per ingrandire)
Per eseguire la migrazione da un'istanza Cloud SQL per PostgreSQL nella vecchia architettura di rete del produttore, devi stabilire la connettività utilizzando un proxy intermedio. Questo perché non è possibile avere una connettività diretta tra l'istanza Cloud SQL di origine e la destinazione AlloyDB.
Puoi configurare la tua soluzione proxy, anche se ti consigliamo di configurare
la VM proxy TCP con lo script generato automaticamente fornito da Database Migration Service.
Consulta Metodo di connettività del proxy TCP.
Esegui la migrazione da un'origine nello stesso Google Cloud progetto, ma in un VPC diverso
Poiché il VPC in cui si trova il cluster AlloyDB non può essere modificato dopo la creazione del cluster, hai le seguenti opzioni:
L'opzione consigliata è modificare il VPC dell'istanza di origine in modo che corrisponda a quello dell'istanza di destinazione. Ad esempio, se vuoi eseguire la migrazione di un'istanza Cloud SQL ad AlloyDB, aggiorna il VPC Cloud SQL in modo che corrisponda al VPC AlloyDB.
Per aggiungere un'altra interfaccia di rete, aggiungi --network-interface network=SOURCE_NETWORK_NAME al comando gcloud compute instances create-with-container visualizzato nello script.
Eseguire la migrazione da un'origine in un progetto Google Cloud diverso
Per eseguire la migrazione da un'origine in un progetto Google Cloud diverso, devi eseguire la migrazione tramite internet oppure, per la connettività Google Cloud interna, utilizzare un VPC condiviso. Seleziona una delle seguenti opzioni:
Utilizza un VPC condiviso senza proxy. Se vuoi che il cluster AlloyDB si trovi in un VPC condiviso, seleziona semplicemente il VPC in cui si trova l'origine durante la creazione del cluster. In questo modo, l'origine e la destinazione hanno una connettività diretta.
Utilizza un VPC condiviso con un proxy. Se non vuoi che il cluster AlloyDB risieda in un VPC condiviso, devi utilizzare un proxy intermedio. Puoi configurare la tua soluzione proxy, ma ti consigliamo di utilizzare il metodo di connettività proxy TCP. Segui queste linee guida per creare un proxy TCP con un'interfaccia di rete aggiuntiva su un VPC condiviso.
Esegui la migrazione senza consentire alla destinazione di raggiungere la rete dell'origine
Questo metodo è consigliato per la migrazione da una rete on-premise, in cui si teme di aprire il firewall della rete al traffico Google Cloud in entrata. Per questo scenario, puoi configurare un proxy inverso utilizzando un'istanza Compute Engine come proxy intermedio. Ti consigliamo di utilizzare il metodo di connettività SSH inversa.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-05 UTC."],[[["\u003cp\u003eDatabase Migration Service requires establishing connectivity between the source instance and the AlloyDB destination instance for migrations, with several methods available.\u003c/p\u003e\n"],["\u003cp\u003eThe IP allowlist method is suitable for short-lived migrations, offering ease of configuration but transmitting network traffic over the public internet, which affects security and performance.\u003c/p\u003e\n"],["\u003cp\u003eProxy methods via cloud-hosted VMs, using either Reverse-SSH tunnels or TCP proxies, are recommended for short-lived migrations and offer ease of configuration without custom firewall adjustments.\u003c/p\u003e\n"],["\u003cp\u003eVPC peering is a native Google Cloud solution that provides high bandwidth and is ideal for long-running or high-volume migrations, but it is only available if both source and destination are hosted in Google Cloud or are connected to the same VPC.\u003c/p\u003e\n"],["\u003cp\u003eFor sources in different networks or on-premise instances, using a proxy or migrating over the public internet are viable options, and there are guides to aid with this process.\u003c/p\u003e\n"]]],[],null,["# Networking methods\n\n\u003cbr /\u003e\n\n[MySQL](/database-migration/docs/mysql/networking-methods \"View this page for the MySQL version of Database Migration Service.\") \\| [PostgreSQL](/database-migration/docs/postgres/networking-methods \"View this page for the PostgreSQL version of Database Migration Service.\") \\| PostgreSQL to AlloyDB\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\nOverview\n--------\n\nTo create a migration in Database Migration Service, connectivity must be established between the source instance and the AlloyDB destination instance. There are various methods supported. Choose the one that works best for the specific workload. \n\nConnectivity limitations\n------------------------\n\nThe PostgreSQL to AlloyDB connectivity has the following limitations:\n\n- AlloyDB supports private connectivity using [private services access](/alloydb/docs/configure-connectivity). Assigning a public IP address to a cluster is not supported.\n- You can't change the VPC with which the AlloyDB cluster is peered after the cluster is created.\n- Because AlloyDB uses private services access which internally uses VPC peering, [transitive peering](/vpc/docs/vpc-peering#specifications) isn't supported. Your AlloyDB cluster can only reach internal IP addresses in the same VPC with which it is peered. In order to reach other VPCs, you must use an intermediary proxy. For more details, see the following section.\n\nCommon connectivity scenarios and solutions\n-------------------------------------------\n\n### Migrate from a Cloud SQL instance in the old producer network architecture\n\n[](#lightbox-trigger) **Figure 1.** A private connection facilitated by the TCP proxy VM (click to enlarge)\n\nTo migrate from a Cloud SQL for PostgreSQL instance in the old producer\nnetwork architecture, you must establish connectivity using an intermediary\nproxy. This is because it isn't possible to have direct connectivity between\nthe source Cloud SQL instance and the AlloyDB destination.\nYou can set up your own proxy solution, although we recommend setting up\nthe TCP proxy VM with the auto-generated script provided by Database Migration Service.\nSee [TCP proxy connectivity method](/database-migration/docs/postgresql-to-alloydb/configure-connectivity-tcp-proxy-via-cloud-hosted-vm).\n\n### Migrate from a source in the same Google Cloud project but in a different VPC\n\nBecause the VPC in which the AlloyDB cluster resides can't be changed after the cluster is created, you have the following options:\n\n- The recommended option is to change the VPC of the source instance to match the VPC of the destination instance. For example, if you want to migrate a Cloud SQL instance to AlloyDB, [update the Cloud SQL VPC](/sql/docs/postgres/configure-private-ip#existing-private-instance) to match the AlloyDB VPC.\n\n | **Caution:** Configuring a private IP address for an existing Cloud SQL instance causes the instance to restart, resulting in downtime.\n- If it's not possible to change the VPC of the source instance to match the VPC of the destination instance, then use an intermediary virtual machine (VM) as a proxy. You can set up your own proxy solution, although we recommend using the [TCP proxy connectivity method](/database-migration/docs/postgresql-to-alloydb/configure-connectivity-tcp-proxy-via-cloud-hosted-vm). After Database Migration Service generates your script in the Google Cloud console, add another network interface to the command for creating a TCP proxy instance, and configure it to match the VPC of the source instance. This way, the proxy has connectivity to both the source and destination VPCs.\n\n To add another network interface, append `--network-interface network=SOURCE_NETWORK_NAME` to the `gcloud compute instances create-with-container` command that appears in the script.\n | **Note:** For custom mode VPC networks, you have to explicitly specify the subnet. The argument you need to append is `--network-interface network=SOURCE_NETWORK_NAME,subnet=`\u003cvar translate=\"no\"\u003eSOURCE_SUBNET_NAME\u003c/var\u003e.\n\n An example command to create the proxy: \n\n ```bash\n gcloud compute instances create-with-container … \\\n --network-interface subnet=DESTINATION-SUBNET-NAME \\\n --network-interface network=SOURCE-NETWORK-NAME\n ```\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eDESTINATION-SUBNET-NAME\u003c/var\u003e: The name of the destination subnet.\n - \u003cvar translate=\"no\"\u003eSOURCE-NETWORK-NAME\u003c/var\u003e: The name of the source network.\n\nFor more information, see [Create VM instances with multiple network interfaces](/vpc/docs/create-use-multiple-interfaces#creating_virtual_machine_instances_with_multiple_network_interfaces).\n\n### Migrate over the public internet\n\nThis method is recommended when migrating from an on-premise instance or from\nother cloud providers, where there's no existing VPN or Interconnect connection\nto Google Cloud. To use this method, you need to\n[configure your destination AlloyDB cluster to use an outbound public IP address](/alloydb/docs/connect-public-ip#add-outbound-connectivity).\n\n### Migrate from a source in a different Google Cloud project\n\nTo migrate from a source in a different Google Cloud project, you must either migrate over the internet, or, for internal Google Cloud connectivity, use a shared VPC. Select one of the following options:\n\n- Use a shared VPC without a proxy. If you want your AlloyDB cluster to reside in a shared VPC, then simply select the VPC where your source resides when creating the cluster. This way, source and destination have direct connectivity.\n\n- Use a shared VPC with a proxy. If you don't want your AlloyDB cluster to reside in a shared VPC, then you must use an intermediary proxy. You can set up your own proxy solution, but we recommend using the [TCP proxy connectivity method](/database-migration/docs/postgresql-to-alloydb/configure-connectivity-tcp-proxy-via-cloud-hosted-vm). Follow [these guidelines](#intermediaryproxy) to create a TCP proxy with an additional network interface on a shared VPC.\n\n### Migrate without allowing the destination to reach the network of the source\n\nThis method is recommended when migrating from an on-premise network, where there's a concern of opening the network's firewall to incoming Google Cloud traffic. For this scenario, you can set up a reverse proxy using a Compute Engine instance as an intermediary proxy. We recommend using the [reverse SSH connectivity method](/database-migration/docs/postgresql-to-alloydb/configure-connectivity-reverse-ssh-tunnel)."]]
