Konektivitas jaringan untuk migrasi PostgreSQL homogen standar

Halaman ini memberikan ringkasan konsep yang terkait dengan konfigurasi konektivitas jaringan untuk migrasi PostgreSQL homogen standar ke AlloyDB untuk PostgreSQL. Untuk mengetahui informasi tentang konektivitas migrasi mulai cepat, lihat panduan Menggunakan migrasi mulai cepat.

Setelah memahami berbagai metode konektivitas dan persyaratannya, Anda dapat menggunakan diagram pohon keputusan untuk memilih solusi yang tepat untuk skenario Anda.

Komponen jaringan yang terlibat dalam proses migrasi

Untuk migrasi PostgreSQL homogen ke AlloyDB untuk PostgreSQL, Database Migration Service terhubung ke cluster AlloyDB untuk PostgreSQL tujuan, lalu mengelola proses migrasi atas namanya. Cluster tujuanlah yang membuat koneksi ke instance sumber Anda, sementara Database Migration Service mengawasi prosesnya.

Ringkasan alur migrasi PostgreSQL
Gambar 1. Pergerakan data selama migrasi Database Migration Service untuk PostgreSQL. (klik untuk memperbesar)
Ringkasan alur migrasi PostgreSQL

Saat Anda merencanakan penyiapan konektivitas jaringan untuk migrasi, penting untuk mempertimbangkan persyaratan infrastruktur dengan cermat, termasuk batasan yang mungkin ditimbulkan oleh keputusan jaringan Anda terhadap status akhir cluster database yang dimigrasikan. Misalnya, jika ingin menggunakan koneksi pribadi untuk konektivitas jaringan, Anda harus menggunakan cluster AlloyDB untuk PostgreSQL tujuan yang dikonfigurasi dengan akses layanan pribadi atau Private Service Connect.

Ketersediaan metode konektivitas

Berbagai metode konektivitas tersedia untuk database sumber yang berbeda, tergantung pada apakah Anda bermigrasi ke cluster tujuan baru atau yang sudah ada. Tabel berikut memberikan ringkasan tentang skenario yang mendukung metode tertentu:

Penawaran database sumber Metode untuk migrasi ke cluster tujuan baru Metode untuk migrasi ke cluster tujuan yang ada
Dihosting sendiri Daftar IP yang diizinkan, tunnel SSH terbalik, peering VPC, proxy TCP melalui VM yang dihosting di cloud Daftar IP yang diizinkan, tunnel SSH terbalik, peering VPC (memerlukan cluster tujuan PSA), proxy TCP melalui VM yang dihosting di cloud, antarmuka PSC (memerlukan cluster tujuan yang mendukung PSC)
Amazon Aurora, Amazon RDS Daftar IP yang diizinkan, tunnel SSH terbalik, peering VPC Daftar IP yang diizinkan, tunnel SSH terbalik, peering VPC (memerlukan cluster tujuan PSA), antarmuka PSC (memerlukan cluster tujuan yang mendukung PSC)
Cloud SQL untuk PostgreSQL Daftar IP yang diizinkan (tidak direkomendasikan), peering VPC, proxy TCP melalui VM yang dihosting di cloud Daftar IP yang diizinkan (tidak direkomendasikan), peering VPC, proxy TCP melalui VM yang dihosting di cloud, antarmuka PSC (memerlukan cluster tujuan yang mendukung PSC)

Perbandingan metode konektivitas

Setiap metode konektivitas memiliki manfaat dan persyaratan yang berbeda. Gunakan tabel berikut untuk membandingkannya secara sekilas, lalu pelajari lebih lanjut detailnya di bagian yang dikhususkan untuk setiap metode.

Metode jaringan Kelebihan Kekurangan
Daftar IP yang diizinkan
  • Metode konektivitas yang paling mudah disiapkan.
  • Berguna jika database sumber Anda tidak dapat dijangkau melalui jaringan pribadi di Google Cloud.
  • Mengharuskan Anda mengekspos alamat IPv4 server database sumber ke internet publik. Hal ini memerlukan tindakan keamanan tambahan. Misalnya, sebaiknya gunakan sertifikat TLS dan aturan firewall untuk mengamankan koneksi.
  • Mengonfigurasi aturan firewall mungkin memerlukan bantuan dari departemen keamanan jaringan atau IT.
Tunnel SSH terbalik
  • Lebih aman daripada menghubungkan melalui IP publik dengan daftar IP yang diizinkan.

    Koneksi awal dibuat melalui port Secure Shell (SSH) melalui internet publik. Setelah koneksi aktif, semua traffic akan melewati tunnel pribadi yang aman ke port 5432 PostgreSQL.

  • Berguna jika database sumber Anda tidak dapat dijangkau melalui jaringan pribadi di Google Cloud, tetapi Anda tidak ingin mengekspos server database sumber secara langsung ke internet publik.
  • Menggunakan server perantara (mesin tunnel SSH terbalik) untuk konektivitas dapat menyebabkan latensi tambahan.
  • Anda harus menyiapkan dan mengelola server host SSH terbalik. Server harus tetap online selama seluruh durasi migrasi Anda.
Antarmuka Private Service Connect
  • 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 dan direkomendasikan untuk dikonfigurasi.
  • Hanya didukung untuk migrasi ke cluster tujuan AlloyDB untuk PostgreSQL yang ada. Jika ingin menggunakan metode ini, Anda harus membuat cluster tujuan langsung di AlloyDB untuk PostgreSQL.
  • Memerlukan penyiapan lampiran jaringan dan penyesuaian aturan firewall.
  • Anda tidak dapat mengubah lampiran jaringan setelah membuat koneksi.
Proxy TCP melalui VM yang dihosting di cloud
  • Menjembatani konektivitas pribadi saat perutean langsung tidak memungkinkan karena peering VPC non-transitif (seperti saat bermigrasi dari sumber Cloud SQL untuk PostgreSQL yang menggunakan arsitektur jaringan produsen lama atau saat menjembatani jaringan VPC terpisah).
  • Database Migration Service otomatis membuat skrip penyiapan untuk men-deploy dan mengonfigurasi VM proxy.
  • Anda harus menyiapkan dan mengelola VM proxy Compute Engine, yang dapat menimbulkan biaya komputasi tambahan.
Konektivitas pribadi dengan peering Virtual Private Cloud Koneksi dibuat ke alamat IP pribadi database sumber Anda melalui peering VPC. Jika VPC Anda tidak memiliki kuota peering yang cukup, mungkin akan sulit untuk menggunakan metode konektivitas ini. Untuk sebagian besar skenario saat Anda bermigrasi ke cluster AlloyDB untuk PostgreSQL yang ada, sebaiknya gunakan Konektivitas pribadi dengan antarmuka Private Service Connect.

Daftar IP yang diizinkan untuk konektivitas database sumber

Saat Anda menggunakan metode konektivitas daftar IP yang diizinkan, AlloyDB untuk PostgreSQL akan mencoba membuat koneksi ke alamat IP yang tersedia secara publik dari server database sumber Anda di port PostgreSQL 5432.

Diagram yang menunjukkan konektivitas daftar IP publik yang diizinkan untuk migrasi homogen.
Gambar 2. Diagram konektivitas jaringan daftar IP yang diizinkan untuk migrasi PostgreSQL homogen. (klik untuk memperbesar)
Diagram yang menunjukkan konektivitas daftar IP publik yang diizinkan untuk migrasi homogen.

Persyaratan untuk konektivitas daftar IP yang diizinkan

Secara umum, untuk menggunakan metode konektivitas ini, Anda harus memastikan hal berikut:

  • Anda harus mengekspos alamat IP database sumber ke internet publik (baik secara langsung, atau dengan nama host yang dikenali secara publik melalui Server Nama Domain (DNS)).

  • Instance utama AlloyDB untuk PostgreSQL tujuan Anda harus mengaktifkan IP publik keluar. Database sumber Anda harus mengizinkan koneksi masuk dari kedua alamat IP publik keluar dari instance utama tujuan.

Mengonfigurasi konektivitas daftar IP yang diizinkan

Mengonfigurasi konektivitas IP publik memerlukan langkah-langkah yang berbeda, bergantung pada jenis database sumber Anda. Untuk informasi selengkapnya, lihat:

Konektivitas database tunnel SSH terbalik

Metode konektivitas ini adalah campuran dari konektivitas jaringan publik dan pribadi. Koneksi itu sendiri dibuat melalui port Secure Shell (SSH) ke alamat IP publik server host tunnel. Setelah koneksi aktif, semua traffic akan dikirim melalui tunnel yang aman ke alamat IP pribadi database sumber Anda di port 5432.

Untuk sumber Cloud SQL atau solusi yang dihosting sendiri yang berada di dalam Google Cloud, sebaiknya gunakan metode konektivitas pribadi dengan antarmuka Private Service Connect atau konektivitas pribadi dengan peering Virtual Private Cloud.

Diagram jaringan yang menunjukkan penyiapan konektivitas tingkat tinggi melalui server SSH khusus.
Gambar 3. Contoh jaringan migrasi: konektivitas sumber melalui tunnel SSH. (klik untuk memperbesar)
Diagram jaringan yang menunjukkan penyiapan konektivitas tingkat tinggi melalui server SSH khusus.

Persyaratan untuk tunnel SSH terbalik

Untuk membuat koneksi, Anda harus mengekspos port SSH ke internet publik di server tunnel (juga dikenal sebagai bastion host). Saat konektivitas dibuat, semua traffic dirutekan melalui koneksi tunnel pribadi.

Metode ini memerlukan komponen jaringan tambahan:

  • Virtual Machine (VM) di Google Cloud untuk berfungsi sebagai mesin SSH terbalik.
  • Mesin tambahan di jaringan Anda yang memiliki konektivitas ke database sumber.

Mengonfigurasi konektivitas tunnel SSH terbalik

Database Migration Service dapat membuat skrip penyiapan untuk membuat VM SSH terbalik, tetapi proses menyeluruhnya berbeda-beda, bergantung pada jenis database sumber Anda. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi konektivitas reverse-SSH.

Konektivitas pribadi dengan antarmuka Private Service Connect

Metode konektivitas ini memungkinkan Anda terhubung ke IP pribadi database sumber tanpa menggunakan kuota peering VPC. Antarmuka Private Service Connect adalah metode yang direkomendasikan untuk konektivitas IP pribadi, tetapi hanya tersedia saat Anda melakukan migrasi ke cluster yang ada.

Saat Anda menggunakan antarmuka Private Service Connect, cluster tujuan Anda tidak menggunakan lebih banyak kuota peering. Sebagai gantinya, layanan ini memanfaatkan antarmuka Private Service Connect untuk menjangkau Virtual Private Cloud tempat IP pribadi database sumber Anda dapat dijangkau. Bergantung pada arsitektur jaringan, Anda mungkin perlu menggunakan komponen tambahan seperti Cloud VPN atau Cloud Interconnect.

Diagram yang menunjukkan konektivitas Private Service Connect dengan Cloud VPN untuk migrasi homogen.
Gambar 4. Konektivitas jaringan dengan antarmuka Private Service Connect untuk migrasi homogen dari sumber yang berada di luar Google Cloud. (klik untuk memperbesar)
Diagram yang menunjukkan konektivitas Private Service Connect dengan Cloud VPN untuk migrasi homogen.

Untuk migrasi dari instance Cloud SQL untuk PostgreSQL, instance sumber Anda harus diaktifkan untuk Akses Layanan Pribadi dan di-peering dengan Virtual Private Cloud tempat Anda membuat lampiran jaringan, tetapi cluster AlloyDB untuk PostgreSQL tujuan tidak menggunakan lebih banyak kuota peering. Sebagai gantinya, layanan ini memanfaatkan antarmuka Private Service Connect.

Diagram yang menunjukkan konektivitas jaringan untuk migrasi dengan antarmuka Private Service Connect.
Gambar 5. Konektivitas jaringan dengan antarmuka Private Service Connect untuk migrasi homogen dari Cloud SQL untuk PostgreSQL. (klik untuk memperbesar)
Diagram yang menunjukkan konektivitas jaringan untuk migrasi dengan antarmuka Private Service Connect.

Persyaratan untuk antarmuka Private Service Connect

Metode konektivitas ini memerlukan hal-hal berikut:

  • Cluster database tujuan Anda harus berupa cluster AlloyDB untuk PostgreSQL dengan PSC yang diaktifkan.

  • Anda harus memiliki jaringan Virtual Private Cloud dengan akses layanan pribadi yang diaktifkan.

    Ini adalah jaringan tempat Anda membuat lampiran jaringan. IP database sumber Anda harus dapat dijangkau dari Virtual Private Cloud tersebut. Misalnya, untuk sumber Cloud SQL untuk PostgreSQL, ini adalah jaringan yang Anda peering dengan instance Cloud SQL sumber yang mendukung PSA.

Mengonfigurasi konektivitas IP pribadi dengan antarmuka Private Service Connect

Untuk menggunakan konektivitas IP pribadi dengan antarmuka Private Service Connect, IP pribadi database sumber Anda harus dapat dijangkau dari Virtual Private Cloud Anda. Bergantung pada arsitektur jaringan, Anda mungkin perlu menggunakan komponen tambahan seperti Cloud VPN atau Cloud Interconnect.

Untuk mempelajari lebih lanjut cara mengonfigurasi konektivitas IP pribadi untuk berbagai sumber database, lihat:

Proxy TCP melalui VM yang dihosting di cloud

Metode konektivitas ini adalah alternatif jika Anda ingin menggunakan konektivitas pribadi melalui peering Virtual Private Cloud, tetapi peering VPC non-transitif mencegah perutean langsung antara database sumber dan cluster AlloyDB untuk PostgreSQL tujuan.

Skenario ini paling sering terjadi saat bermigrasi dari instance Cloud SQL untuk PostgreSQL yang menggunakan arsitektur jaringan produsen lama ke cluster AlloyDB untuk PostgreSQL tujuan yang dikonfigurasi dengan Akses Layanan Pribadi (PSA). Karena kedua layanan berada di jaringan produsen terpisah yang dikelola Google dan peering VPC tidak transitif, traffic tidak dapat mengalir langsung di antara keduanya. Hal ini juga berlaku jika database sumber yang dihosting sendiri dan cluster AlloyDB untuk PostgreSQL tujuan berada di Jaringan VPC yang di-peering secara terpisah, atau jika persyaratan kebijakan keamanan perusahaan mengharuskan perutean traffic migrasi melalui satu alamat IP internal statis.

VM Compute Engine perantara di jaringan VPC Anda bertindak sebagai jembatan, yang menerima koneksi replikasi masuk di port 5432 dari instance utama AlloyDB untuk PostgreSQL tujuan dan meneruskannya ke database sumber.

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

Persyaratan untuk konektivitas proxy TCP

Metode konektivitas ini memerlukan hal-hal berikut:

  • VM Compute Engine di jaringan Virtual Private Cloud yang di-peering dengan cluster AlloyDB untuk PostgreSQL tujuan Anda untuk menjalankan container proxy TCP.
  • Keterjangkauan jaringan dari VM proxy ke instance database sumber Anda.

Mengonfigurasi konektivitas proxy TCP

Saat Anda membuat tugas migrasi di konsol Google Cloud , Database Migration Service akan mengumpulkan parameter yang diperlukan dan membuat skrip gcloud yang membuat VM container proxy Compute Engine dan aturan firewall ingress yang diperlukan di VPC Anda. Untuk mengetahui petunjuk langkah demi langkah, lihat Mengonfigurasi konektivitas menggunakan proxy TCP melalui VM yang dihosting di cloud.

Konektivitas pribadi dengan peering VPC

Metode ini memungkinkan Anda terhubung ke sumber melalui alamat IP pribadi di Virtual Private Cloud (VPC) Anda. Anda tidak perlu mengekspos antarmuka apa pun ke internet publik untuk menggunakan metode ini, tetapi alamat IP atau nama host database sumber Anda harus dapat dijangkau dari VPC Google Cloud . Untuk sumber yang berada di luar Google Cloud, Anda mungkin memerlukan komponen jaringan tambahan, seperti Cloud VPN atau Cloud Interconnect.

Diagram yang menunjukkan konektivitas peering Virtual Private Cloud untuk migrasi PostgreSQL homogen.
Gambar 7. Konektivitas jaringan dengan peering Virtual Private Cloud untuk migrasi PostgreSQL homogen. (klik untuk memperbesar)
Diagram yang menunjukkan konektivitas peering Virtual Private Cloud untuk migrasi PostgreSQL homogen.

Persyaratan untuk konektivitas IP pribadi dengan peering VPC

Konektivitas IP pribadi dengan peering VPC memerlukan hal berikut:

Mengonfigurasi konektivitas IP pribadi dengan peering VPC

Untuk menggunakan konektivitas IP pribadi dengan peering Virtual Private Cloud, IP pribadi database sumber Anda harus dapat dijangkau dari Virtual Private Cloud Anda. Bergantung pada arsitektur jaringan, Anda mungkin perlu menggunakan komponen tambahan seperti Cloud VPN atau Cloud Interconnect.

Untuk mempelajari lebih lanjut cara mengonfigurasi konektivitas IP pribadi untuk berbagai sumber database, lihat:

Pohon keputusan konektivitas jaringan

Setelah memahami semua metode konektivitas yang didukung dan persyaratannya, Anda dapat mengikuti pertanyaan dalam diagram untuk membantu memilih metode konektivitas yang tepat untuk skenario Anda.

Diagram pohon keputusan dengan pertanyaan panduan untuk membantu Anda memilih metode konektivitas yang tepat.
Gambar 8. Pohon keputusan konektivitas jaringan sumber.

Langkah berikutnya