Men-debug konektivitas
Anda telah menyiapkan konektivitas antara database sumber dan tujuan, tetapi bagaimana cara mengetahui bahwa database tersebut terhubung? Jika komunikasi Anda gagal di antara keduanya, bagaimana cara Anda mengetahui masalahnya dan di mana?
Alat yang paling dasar adalah ping
dan traceroute
.
Ping
Ping
melakukan pengujian dasar untuk menentukan apakah tujuan
("host jarak jauh") tersedia dari sumber. Ping
mengirim
paket ICMP Echo Request
ke host jarak jauh, dan mengharapkan
ICMP Echo Reply
sebagai balasannya. Jika ping
tidak berhasil,
tidak ada rute dari sumber ke tujuan. Namun, keberhasilan
tidak berarti paket Anda dapat melewatinya, hanya bahwa secara umum,
host jarak jauh dapat dijangkau.
Meskipun ping
dapat mengetahui apakah host aktif dan merespons, hal ini tidak
dijamin dapat diandalkan. Beberapa penyedia jaringan memblokir ICMP
sebagai
langkah pengamanan, yang dapat mempersulit proses debug konektivitas.
Traceroute
Traceroute
menguji rute lengkap yang diambil paket jaringan dari satu host
ke host lainnya. Diagram ini menunjukkan semua langkah ("hop") yang dilakukan paket
sepanjang perjalanan, dan berapa lama setiap langkah tersebut. Jika paket tidak sampai
ke tujuan, traceroute
tidak akan selesai, tetapi
berakhir dengan serangkaian tanda bintang. Dalam hal ini, cari alamat IP terakhir yang
berhasil dijangkau di sepanjang jalan. Di sinilah konektivitas mengalami gangguan.
Traceroute
dapat habis waktunya. Proses ini juga dapat gagal diselesaikan jika gateway
di sepanjang jalan tidak dikonfigurasi dengan benar untuk meneruskan paket ke hop
berikutnya.
Jika traceroute
gagal diselesaikan, Anda mungkin dapat mengetahui
tempatnya berhenti. Temukan alamat IP terakhir yang tercantum dalam output traceroute
, lalu lakukan penelusuran browser untuk who owns [IP_ADDRESS]
. Hasilnya
mungkin menampilkan atau tidak menampilkan pemilik alamat, tetapi tidak ada salahnya untuk mencoba.
mtr
Alat mtr
adalah bentuk traceroute
yang tetap
aktif dan terus diperbarui, mirip dengan cara kerja perintah top
untuk proses lokal.
Menemukan alamat IP lokal Anda
Jika Anda tidak mengetahui alamat lokal host, jalankan perintah
ip -br address show
.
Di Linux, hal ini menunjukkan antarmuka jaringan,
status antarmuka, IP lokal, dan alamat MAC.
Contoh:
eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64
.
Atau, Anda dapat menjalankan ipconfig
atau ifconfig
untuk melihat
status antarmuka jaringan.
Menemukan alamat IP keluar
Jika Anda tidak mengetahui alamat IP yang digunakan database sumber dan tujuan untuk berkomunikasi satu sama lain (alamat IP keluar), selesaikan langkah-langkah berikut:
Buka halaman Instance SQL di konsol Google Cloud.
Klik nama instance yang terkait dengan tugas migrasi yang Anda debug.
Scroll ke bawah hingga panel Connect to this instance muncul. Di panel ini, alamat IP keluar akan muncul.
Buka port lokal
Untuk memverifikasi bahwa host memproses port yang menurut Anda benar, jalankan perintah
ss -tunlp4
.
Ini memberitahu Anda port apa
yang terbuka dan mendengarkan.
Misalnya, jika Anda memiliki database PostgreSQL yang berjalan, port 5432 harus
aktif dan memproses. Untuk SSH, Anda akan melihat port 22.
Semua aktivitas port lokal
Gunakan perintah netstat
untuk melihat semua aktivitas port lokal.
Misalnya,
netstat -lt
menampilkan semua port yang saat ini aktif.
Menghubungkan ke host jarak jauh menggunakan telnet
Untuk memverifikasi bahwa Anda dapat terhubung ke host jarak jauh menggunakan TCP
, jalankan
perintah telnet
. Telnet mencoba terhubung ke alamat IP
dan port yang Anda berikan.
telnet 35.193.198.159 5432
.
Jika berhasil, Anda akan melihat hal berikut:
Trying 35.193.198.159...
Connected to 35.193.198.159.
.
Jika gagal, Anda akan melihat telnet
berhenti merespons hingga Anda menutup percobaan tersebut secara paksa:
Trying 35.193.198.159...
^C.
.
Autentikasi klien
Autentikasi klien dikontrol oleh file konfigurasi, yang diberi nama
pg_hba.conf
(HBA adalah singkatan dari host-based authentication).
Pastikan bagian koneksi replikasi file pg_hba.conf
pada database sumber telah diupdate untuk menerima koneksi dari
rentang alamat IP VPC Cloud SQL.
Cloud Logging
Database Migration Service dan Cloud SQL menggunakan Cloud Logging. Lihat dokumentasi Cloud Logging untuk mengetahui informasi selengkapnya dan tinjau contoh kueri Cloud SQL.Lihat log
Anda dapat melihat log untuk instance Cloud SQL dan project Google Cloud lainnya, seperti instance Cloud VPN atau Compute Engine. Untuk melihat log yang berisi entri log instance Cloud SQL Anda:Konsol
- Buka Logs Explorer
- Pilih project Cloud SQL yang sudah ada di bagian atas halaman.
- Di Builder kueri, tambahkan hal berikut:
- Resource: Pilih Database Cloud SQL. Pada dialog, pilih instance Cloud SQL.
- Nama log: Scroll ke bagian Cloud SQL dan pilih
file log yang sesuai untuk instance Anda.
Contoh:
- cloudsql.googleapis.com/postgres.log
- Tingkat keparahan: Pilih level log.
- Rentang waktu: Pilih preset atau buat rentang kustom.
gcloud
Gunakan perintah gcloud logging
untuk melihat entri log. Pada contoh di bawah, ganti PROJECT_ID
.
Flag limit
adalah parameter opsional yang menunjukkan jumlah entri maksimum yang akan
ditampilkan.
gcloud logging read "projects/[PROJECT_ID]/logs/cloudsql.googleapis.com/postgres.log" --limit=10
Alamat IP pribadi
Koneksi ke instance Cloud SQL yang menggunakan alamat IP pribadi akan
otomatis diizinkan untuk rentang alamat IP
RFC 1918. Rentang alamat IP Non-RFC 1918 harus dikonfigurasi
di Cloud SQL sebagai jaringan
yang diizinkan.
Anda juga harus memperbarui peering jaringan ke Cloud SQL untuk
mengekspor rute Non-RFC 1918.
Misalnya:
gcloud compute networks peerings update cloudsql-postgres-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT
Rentang IP 172.17.0.0/16 dicadangkan untuk jaringan bridge Docker. Setiap instance Cloud SQL yang dibuat dengan alamat IP dalam rentang tersebut tidak akan dapat dijangkau. Koneksi dari alamat IP apa pun dalam rentang tersebut ke instance Cloud SQL yang menggunakan alamat IP pribadi akan gagal.
Pemecahan masalah VPN
Lihat halaman Pemecahan masalah Cloud VPN diGoogle Cloud
Memecahkan masalah tunnel SSH terbalik
Tunneling SSH adalah metode untuk meneruskan beberapa komunikasi di atas koneksi SSH. Tunneling SSH terbalik memungkinkan penyiapan tunnel SSH, tetapi mempertahankan bahwa jaringan tujuan adalah jaringan yang memulai koneksi tunnel. Hal ini berguna jika Anda tidak ingin membuka port di jaringan Anda sendiri untuk tujuan keamanan.
Yang Anda coba capai adalah menyiapkan hal berikut: Cloud SQL DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB
Diasumsikan bahwa:
Compute Engine VM bastion dapat mengakses Cloud SQL DB.
source network bastion dapat mengakses source DB (hal ini dicapai dengan melakukan peering jaringan Cloud SQL ke jaringan VM Compute Engine).
Kemudian, Anda menyiapkan tunnel SSH dari source network bastion ke Compute Engine VM bastion, yang merutekan koneksi masuk ke beberapa port di Compute Engine VM bastion melalui tunnel ke source DB.
Setiap link dalam skenario di atas dapat disiapkan dengan tidak benar dan mencegah seluruh alur berfungsi. Pecahkan masalah setiap link, satu per satu:
source network bastion ---> source DB
- Hubungkan ke source network bastion menggunakan SSH, atau dari terminal jika mesin lokal.
- Uji konektivitas ke DB sumber menggunakan salah satu metode berikut:
telnet [source_db_host_or_ip] [source_db_port]
- Anda akan melihat string koneksi telnet, yang diakhiri denganConnected to x.x.x.x
.[db_client] -h[source_db_host_or_ip] -P[source_db_port]
- Anda akan melihat akses ditolak
Jika gagal, Anda harus memverifikasi bahwa Anda telah mengaktifkan akses dari bastion ini ke DB sumber.
Compute Engine VM bastion ---> source DB
- SSH ke Compute Engine VM bastion (menggunakan
gcloud compute ssh VM_INSTANCE_NAME
) - Uji konektivitas ke DB sumber menggunakan salah satu metode berikut:
telnet 127.0.0.1 [tunnel_port]
- Anda akan melihat string koneksi telnet, yang diakhiri denganConnected to x.x.x.x
.[db_client] -h127.0.0.1 -P[tunnel_port]
- akan melihat akses ditolak
Jika gagal, Anda harus memastikan bahwa tunnel sudah aktif dan berjalan dengan benar.
Menjalankan sudo netstat -tupln
akan menampilkan semua proses pemrosesan di VM ini, dan Anda akan melihat sshd listening on the tunnel_port
.
Cloud SQL DB ---> source DB
Hal ini paling baik diuji oleh testing the migration job
dari Database Migration Service.
Jika gagal, berarti ada beberapa masalah dengan peering atau perutean VPC
antara jaringan Cloud SQL dan jaringan
Compute Engine VM bastion.
Firewall server database sumber harus dikonfigurasi untuk mengizinkan seluruh rentang IP internal yang dialokasikan untuk koneksi layanan pribadi jaringan VPC yang akan digunakan oleh instance tujuan Cloud SQL sebagai kolom privateNetwork dari setelan ipConfiguration-nya.
Untuk menemukan rentang IP internal di konsol:
Buka halaman jaringan VPC di konsol Google Cloud .
Pilih jaringan VPC yang ingin Anda gunakan.
Pilih tab PRIVATE SERVICE CONNECTION.
Anda juga dapat melihat traffic antara instance Cloud SQL dan instance VM Compute Engine di
konsol Cloud Logging di
project Cloud VPN gateway
. Di log VM Compute Engine,
cari traffic yang berasal dari instance Cloud SQL. Di log instance Cloud SQL, cari traffic dari VM Compute Engine.