Halaman ini diterjemahkan oleh Cloud Translation API.

Metode jaringan

MySQL | PostgreSQL | PostgreSQL ke AlloyDB

Ringkasan

Untuk membuat migrasi di Database Migration Service, konektivitas harus dibuat antara instance sumber dan instance tujuan AlloyDB. Ada berbagai metode yang didukung. Pilih salah satu yang paling sesuai untuk workload tertentu.

Metode jaringan	Deskripsi	Kelebihan	Kekurangan
Daftar IP yang diizinkan	Metode ini berfungsi dengan mengonfigurasi server database sumber agar menerima koneksi dari IP keluar instance Cloud SQL. Jika Anda memilih metode ini, Database Migration Service akan memandu Anda melalui proses penyiapan selama pembuatan migrasi.	Mudah dikonfigurasi. Tidak memerlukan konfigurasi firewall kustom.	Traffic jaringan terjadi melalui internet publik. Kurang aman. Performa menurun.
Proxy melalui VM yang dihosting di cloud - Tunnel SSH terbalik	Membuat konektivitas dari tujuan ke sumber melalui tunnel SSH terbalik yang aman. Memerlukan VM bastion host di project Google Cloud Platform serta mesin (misalnya, laptop di jaringan) yang memiliki konektivitas ke sumber. Database Migration Service mengumpulkan informasi yang diperlukan pada waktu pembuatan migrasi, dan membuat skrip secara otomatis untuk menyiapkan semuanya.	Mudah dikonfigurasi. Tidak memerlukan konfigurasi firewall kustom. Direkomendasikan untuk skenario migrasi jangka pendek (POC atau migrasi database kecil).	Bastion VM dimiliki dan dikelola oleh Anda, dan dapat menimbulkan biaya tambahan.
Proxy melalui VM yang dihosting di cloud - TCP	Membangun konektivitas dari tujuan ke sumber menggunakan proxy TCP melalui VM yang dihosting di cloud. Database Migration Service mengumpulkan informasi yang diperlukan pada waktu pembuatan migrasi, dan membuat skrip secara otomatis untuk menyiapkan semuanya. Relevan pada migrasi AlloyDB saat sumber berada di arsitektur jaringan lama.	Mudah dikonfigurasi. Tidak memerlukan konfigurasi firewall kustom.	Bastion VM dimiliki dan dikelola oleh Anda, dan dapat menimbulkan biaya tambahan.
Peering VPC	Metode ini berfungsi dengan mengonfigurasi VPC agar dapat berkomunikasi satu sama lain.	Solusi Google Cloud Native. Mudah dikonfigurasi. Bandwidth tinggi. Direkomendasikan untuk migrasi yang berjalan lama atau bervolume tinggi.	Berlaku jika database sumber dan tujuan dihosting di Google Cloud, atau jika sumber terhubung ke VPC tujuan menggunakan VPN (dihosting di cloud atau lokal) atau Cloud Interconnect.
Antarmuka Private Service Connect	Antarmuka Private Service Connect memungkinkan instance AlloyDB for PostgreSQL tujuan Anda memulai koneksi ke IP pribadi database sumber Anda tanpa menggunakan kuota peering. Sebagai gantinya, metode konektivitas ini menggunakan lampiran jaringan yang Anda buat di VPC.	Membuat koneksi ke IP pribadi sumber Anda menggunakan lampiran jaringan. Metode ini tidak menggunakan kuota peering di VPC Anda. Metode konektivitas pribadi sumber yang paling mudah dikonfigurasi.	Metode konektivitas ini hanya tersedia saat Anda bermigrasi ke instance yang ada. Memerlukan penyiapan lampiran jaringan dan penyesuaian aturan firewall. Anda tidak dapat mengubah lampiran jaringan setelah membuat koneksi. Untuk mengetahui informasi selengkapnya tentang akses layanan pribadi dan Private Service Connect di AlloyDB untuk PostgreSQL, lihat Ringkasan IP pribadi dalam dokumentasi AlloyDB untuk PostgreSQL.

Batasan konektivitas

Konektivitas PostgreSQL ke AlloyDB memiliki batasan berikut:

AlloyDB mendukung konektivitas pribadi menggunakan akses layanan pribadi. Penetapan alamat IP publik ke cluster tidak didukung.
Anda tidak dapat mengubah VPC yang digunakan untuk peering cluster AlloyDB setelah cluster dibuat.
Karena AlloyDB menggunakan akses layanan pribadi yang secara internal menggunakan peering VPC, peering transitif tidak didukung. Cluster AlloyDB Anda hanya dapat menjangkau alamat IP internal di VPC yang sama dengan yang di-peering. Untuk menjangkau VPC lain, Anda harus menggunakan proxy perantara. Untuk mengetahui detail selengkapnya, lihat bagian berikut.

Skenario dan solusi konektivitas umum

Bermigrasi dari instance Cloud SQL dalam arsitektur jaringan produsen lama

Diagram arsitektur untuk koneksi database pribadi yang menggunakan VM proxy TCP. — **Gambar 1.** Koneksi pribadi yang difasilitasi oleh VM proxy TCP (klik untuk memperbesar)

Untuk bermigrasi dari instance Cloud SQL untuk PostgreSQL dalam arsitektur jaringan produsen lama, Anda harus membuat konektivitas menggunakan proxy perantara. Hal ini karena konektivitas langsung antara instance Cloud SQL sumber dan tujuan AlloyDB tidak dapat dilakukan. Anda dapat menyiapkan solusi proxy sendiri, meskipun sebaiknya siapkan VM proxy TCP dengan skrip yang dibuat otomatis yang disediakan oleh Database Migration Service. Lihat Metode konektivitas proxy TCP.

Bermigrasi dari sumber di Google Cloud project yang sama, tetapi di VPC yang berbeda

Karena VPC tempat cluster AlloyDB berada tidak dapat diubah setelah cluster dibuat, Anda memiliki opsi berikut:

Opsi yang direkomendasikan adalah mengubah VPC instance sumber agar cocok dengan VPC instance tujuan. Misalnya, jika Anda ingin memigrasikan instance Cloud SQL ke AlloyDB, perbarui VPC Cloud SQL agar cocok dengan VPC AlloyDB.

Perhatian: Mengonfigurasi alamat IP pribadi untuk instance Cloud SQL yang sudah ada akan menyebabkan instance dimulai ulang, sehingga menyebabkan periode nonaktif.
Jika VPC instance sumber tidak dapat diubah agar cocok dengan VPC instance tujuan, gunakan virtual machine (VM) perantara sebagai proxy. Anda dapat menyiapkan solusi proxy Anda sendiri, meskipun sebaiknya gunakan metode konektivitas proxy TCP. Setelah Database Migration Service membuat skrip Anda di konsol Google Cloud , tambahkan antarmuka jaringan lain ke perintah untuk membuat instance proxy TCP, dan konfigurasikan agar cocok dengan VPC instance sumber. Dengan cara ini, proxy memiliki konektivitas ke VPC sumber dan tujuan.

Untuk menambahkan antarmuka jaringan lain, tambahkan --network-interface network=SOURCE_NETWORK_NAME ke perintah gcloud compute instances create-with-container yang muncul dalam skrip.

Catatan: Untuk jaringan VPC mode kustom, Anda harus menentukan subnet secara eksplisit. Argumen yang perlu Anda tambahkan adalah --network-interface network=SOURCE_NETWORK_NAME,subnet=SOURCE_SUBNET_NAME.

Contoh perintah untuk membuat proxy:
```
  gcloud compute instances create-with-container … \
  --network-interface subnet=DESTINATION-SUBNET-NAME \
  --network-interface network=SOURCE-NETWORK-NAME
```
Ganti kode berikut:
- DESTINATION-SUBNET-NAME: Nama subnet tujuan.
- SOURCE-NETWORK-NAME: Nama jaringan sumber.

Untuk mengetahui informasi selengkapnya, lihat Membuat instance VM dengan beberapa antarmuka jaringan.

Migrasi melalui internet publik

Metode ini direkomendasikan saat bermigrasi dari instance lokal atau dari penyedia cloud lain, yang tidak memiliki koneksi VPN atau Interconnect yang ada ke Google Cloud. Untuk menggunakan metode ini, Anda perlu mengonfigurasi cluster AlloyDB tujuan agar menggunakan alamat IP publik keluar.

Bermigrasi dari sumber di project Google Cloud lain

Untuk bermigrasi dari sumber di project Google Cloud lain, Anda harus bermigrasi melalui internet, atau, untuk konektivitas Google Cloud internal, menggunakan VPC bersama. Pilih salah satu opsi berikut:

Gunakan VPC bersama tanpa proxy. Jika Anda ingin cluster AlloyDB berada di VPC bersama, cukup pilih VPC tempat sumber Anda berada saat membuat cluster. Dengan cara ini, sumber dan tujuan memiliki konektivitas langsung.
Menggunakan VPC bersama dengan proxy. Jika tidak ingin cluster AlloyDB Anda berada di VPC bersama, Anda harus menggunakan proxy perantara. Anda dapat menyiapkan solusi proxy Anda sendiri, tetapi sebaiknya gunakan metode konektivitas proxy TCP. Ikuti panduan ini untuk membuat proxy TCP dengan antarmuka jaringan tambahan di VPC bersama.

Memigrasikan tanpa mengizinkan tujuan menjangkau jaringan sumber

Metode ini direkomendasikan saat bermigrasi dari jaringan lokal, yang khawatir membuka firewall jaringan untuk traffic Google Cloud masuk. Untuk skenario ini, Anda dapat menyiapkan proxy terbalik menggunakan instance Compute Engine sebagai proxy perantara. Sebaiknya gunakan metode konektivitas SSH terbalik.