Men-debug konektivitas
Anda telah menyiapkan konektivitas antara database sumber dan tujuan, tetapi bagaimana Anda tahu bahwa keduanya terhubung? Jika komunikasi antara keduanya gagal, bagaimana Anda dapat mengetahui apa yang salah 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 mengirimkan paket ICMP Echo Request ke host jarak jauh, dan mengharapkan ICMP Echo Reply sebagai balasannya. Jika ping tidak berhasil, berarti tidak ada rute dari sumber ke tujuan. Namun, keberhasilan tidak berarti paket Anda dapat terkirim, hanya bahwa secara umum, host jarak jauh dapat dijangkau.
Meskipun ping dapat mengetahui apakah host aktif dan merespons, tetapi tidak dijamin dapat diandalkan. Beberapa penyedia jaringan memblokir ICMP sebagai tindakan pencegahan keamanan, yang dapat membuat proses debug konektivitas menjadi lebih sulit.
Traceroute
Traceroute menguji paket jaringan rute lengkap yang diambil dari satu host ke host lainnya. Alat ini menampilkan semua langkah ("hop") yang diambil paket di sepanjang rute, dan berapa lama waktu yang dibutuhkan untuk setiap langkah. Jika paket tidak sampai ke tujuan, traceroute tidak akan selesai, tetapi akan berakhir dengan serangkaian tanda bintang. Dalam hal ini, cari alamat IP terakhir yang berhasil dijangkau di sepanjang rute. Di sinilah konektivitas terputus.
Traceroute dapat mengalami waktu tunggu. Alat ini juga dapat gagal diselesaikan jika gateway di sepanjang rute 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 atau mungkin tidak menampilkan pemilik alamat, tetapi patut dicoba.
mtr
Alat mtr adalah bentuk traceroute yang tetap aktif dan terus diperbarui, mirip dengan cara perintah top berfungsi 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 cluster AlloyDB di Google Cloud console.
Temukan cluster yang terkait dengan tugas migrasi yang Anda debug.
IP keluar akan muncul di samping nama instance utama cluster.
Buka port lokal
Untuk memverifikasi bahwa host memproses port yang menurut Anda benar, jalankan perintah
ss -tunlp4.
Perintah ini menunjukkan port yang terbuka dan
sedang 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 paksa
upaya tersebut:
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 AlloyDB.
Cloud Logging
Database Migration Service dan AlloyDB menggunakan Cloud Logging. Lihat dokumentasi Cloud Logging untuk mengetahui informasi selengkapnya dan tinjau contoh kueri Cloud SQL.Melihat log
Anda dapat melihat log untuk instance AlloyDB dan project lainnya Google Cloud , seperti instance Cloud VPN atau Compute Engine. Untuk melihat log yang berisi entri log instance AlloyDB Anda:Konsol
- Buka Logs Explorer
- Pilih project AlloyDB yang ada di bagian atas halaman.
- Di Builder kueri, tambahkan hal berikut:
- Resource: Pilih Database AlloyDB. Pada dialog, pilih instance AlloyDB.
- Nama log: Scroll ke bagian AlloyDB dan pilih
file log yang sesuai untuk instance Anda. Contoh:
- alloydb.googlapis.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/alloydb.googleapis.com/postgres.log" --limit=10
Pemecahan masalah VPN
Lihat halaman Google Cloud Pemecahan masalah Cloud VPN.
Memecahkan masalah error proxy TCP
Cara proxy TCP disiapkan juga dapat menimbulkan error. Untuk memecahkan masalah error proxy TCP, lihat contoh masalah berikut dan cara penyelesaiannya:
Kegagalan memulai virtual machine (VM)
Anda akan melihat pesan berikut saat memulai instance VM di Compute Engine:
You do not currently have an active account selected.
Hal yang dapat dicoba
Jalankan salah satu perintah berikut untuk mengonfigurasi akun aktif:
Untuk mendapatkan kredensial baru, jalankan perintah berikut:
gcloud auth loginUntuk memilih akun yang sudah diautentikasi, jalankan perintah berikut:
gcloud config set account ACCOUNTGanti ACCOUNT dengan nama akun yang ingin Anda konfigurasi.
Kegagalan menghubungkan ke instance database sumber
Anda akan melihat pesan error berikut saat menguji tugas migrasi:
Failure connecting to the source database. Make sure the connectivity information on the connection profile is correct and the source database is reachable.
Hal yang dapat dicoba
Ulangi langkah-langkah berikut untuk memahami kemungkinan penyebab masalah:
Periksa apakah VM yang menghosting container proxy TCP sedang berjalan:
Di konsol, buka halaman VM instances Compute Engine.
Cari VM yang dibuat sebagai bagian dari proses penyiapan proxy. Jika tidak tercantum atau tidak berjalan, konfigurasikan proxy TCP dari awal, dan perbarui setelan instance sumber dalam tugas migrasi dengan alamat IP yang benar.
Jika VM berjalan, pastikan tidak ada error saat mendownload image container proxy TCP:
- Pilih VM yang dibuat sebagai bagian dari proses penyiapan proxy TCP. Di bagian Logs, klik Port serial 1 (console).
Jika Anda tidak dapat melihat entri
Launching user container 'gcr.io/dms-images/tcp-proxy'di log, masalahnya mungkin karena instance Anda tidak dapat mengambil image dari Container Registry. Untuk memverifikasi apakah ini masalahnya, hubungkan ke VM, dan coba ambil image dari Container Registry secara manual menggunakan perintah berikut:docker pull gcr.io/dms-images/tcp-proxyJika Anda melihat error berikut:
Error response from daemon: Get "https://gcr.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers), artinya VM Anda tidak dapat terhubung ke Container Registry. Jika VM Anda hanya memiliki alamat IP pribadi, Anda harus mengaktifkan Akses Google Pribadi di subnet yang menjadi bagian alamat IP tersebut; jika tidak, VM tidak akan memiliki akses ke Google Enterprise API, seperti Container Registry.
Pastikan container dapat terhubung ke instance sumber:
Pilih VM yang dibuat sebagai bagian dari proses penyiapan proxy. Di bagian Logs, klik Cloud Logging.
Jika Anda melihat pesan berikut:
Connection refused, please verify that the machine you are using to run the script can connect to the source database at, artinya container proxy TCP tidak dapat terhubung ke instance database sumber. Ada beberapa alasan mengapa hal ini dapat terjadi:- Alamat IP instance sumber salah.
- Ada kebijakan firewall yang menolak koneksi dari proxy TCP ke instance sumber.
- Instance sumber berada di jaringan Virtual Private Cloud (VPC) yang berbeda dengan VM yang menghosting proxy TCP.
Anda dapat men-debug masalah konektivitas menggunakan Google CloudUji Konektivitas untuk memastikan ada konektivitas antara database tujuan dan VM yang menghosting proxy TCP:
Di konsol, buka halaman Uji Konektivitas.
Klik Create Connectivity Test.
Masukkan nama untuk pengujian.
Pilih TCP sebagai protokol.
Pilih IP address dari daftar Source endpoint. Masukkan alamat IP publik proxy TCP yang baru dibuat jika database sumber dapat diakses menggunakan alamat IP publik; jika tidak, masukkan alamat IP pribadi proxy TCP.
Pilih IP address dari daftar Destination endpoint, lalu masukkan alamat IP database sumber.
Masukkan nomor port yang digunakan untuk terhubung ke database sumber di kolom Destination port.
Klik Create.
Jalankan uji konektivitas dan atasi masalah konektivitas yang muncul. Setelah Anda memperbaiki masalah konektivitas, pastikan proxy TCP dapat terhubung ke instance sumber:
Buka VM instances di Compute Engine.
Pilih VM yang dibuat sebagai bagian dari proses penyiapan proxy. Di bagian Logs, klik Cloud Logging.
Jika Anda melihat entri log
Connection to source DB verified, artinya proxy TCP kini dapat terhubung ke instance sumber.
Pastikan pengujian migrasi tidak gagal karena masalah koneksi.
Kegagalan menghubungkan ke instance database tujuan
Jika container proxy TCP dapat terhubung ke instance sumber, tetapi pengujian migrasi masih gagal karena masalah koneksi, masalahnya mungkin konektivitas antara instance tujuan dan VM yang menghosting container proxy TCP.
Men-debug masalah
Untuk men-debug masalah, Anda dapat menggunakan Google Cloud's Uji Konektivitas untuk memastikan ada konektivitas antara database tujuan dan VM yang menghosting proxy TCP:
Di konsol, buka halaman Uji Konektivitas.
Klik Create Connectivity Test.
Tetapkan parameter berikut untuk pengujian Anda:
- Masukkan nama untuk pengujian.
- Pilih TCP sebagai protokol.
- Pilih IP address dari daftar Source endpoint, lalu masukkan alamat IP cluster AlloyDB yang baru dibuat.
- Pilih IP address dari daftar Destination endpoint, lalu masukkan alamat IP pribadi proxy TCP.
- Masukkan 5432 di kolom Destination port.
Klik Create.
Jalankan uji konektivitas dan atasi masalah konektivitas yang muncul.
Kemungkinan penyebab
Ada aturan firewall yang menolak komunikasi antara instance tujuan dan VM proxy TCP.
Hal yang dapat dicoba
Tambahkan aturan firewall yang memungkinkan instance tujuan berkomunikasi dengan Proxy TCP menggunakan port 5432.
Kemungkinan penyebab
Ada ketidakcocokan VPC antara instance tujuan dan VM yang menjalankan container proxy TCP.
Hal yang dapat dicoba
Pilih VPC yang sama untuk instance tujuan.
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 ingin Anda capai adalah menyiapkan hal berikut: AlloyDB DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB
Diasumsikan bahwa:
AlloyDB destination dapat mengakses Compute Engine VM bastion.
source network bastion dapat mengakses source DB (hal ini dicapai dengan melakukan peering jaringan AlloyDB 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 merupakan mesin lokal.
- Uji konektivitas ke DB sumber menggunakan salah satu metode berikut:
telnet [source_db_host_or_ip] [source_db_port]- diharapkan melihat string koneksi telnet, yang diakhiri denganConnected to x.x.x.x.[db_client] -h[source_db_host_or_ip] -P[source_db_port]- diharapkan melihat akses ditolak
Jika gagal, Anda harus memverifikasi bahwa Anda 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]- diharapkan melihat string koneksi telnet, yang diakhiri denganConnected to x.x.x.x.[db_client] -h127.0.0.1 -P[tunnel_port]- diharapkan melihat akses ditolak
Jika gagal, Anda harus memverifikasi bahwa tunnel aktif dan berjalan dengan benar.
Menjalankan sudo netstat -tupln akan menampilkan semua proses yang memproses di
VM ini, dan Anda akan melihat sshd listening on the tunnel_port.
AlloyDB DB ---> source DB
Hal ini paling baik diuji dengan testing the migration job dari Database Migration Service.
Jika gagal, berarti ada masalah dengan peering atau perutean VPC
antara jaringan AlloyDB dan Compute Engine VM bastion
jaringan.
Firewall server database sumber harus dikonfigurasi untuk mengizinkan seluruh rentang IP internal yang dialokasikan untuk koneksi layanan pribadi dari jaringan VPC yang akan digunakan instance tujuan AlloyDB sebagai privateNetwork kolom dari setelan ipConfiguration.
Untuk menemukan rentang IP internal di konsol:
Buka halaman VPC networks di Google Cloud konsol.
Pilih jaringan VPC yang ingin Anda gunakan.
Pilih Akses layanan pribadi > Rentang IP yang dialokasikan untuk layanan.
Temukan rentang IP internal yang terkait dengan koneksi yang dibuat oleh servicenetworking-googleapis-com.
Anda juga dapat melihat traffic antara instance AlloyDB dan instance VM Compute Engine di
konsol Cloud Logging dalam
Cloud VPN gateway project. Di log VM Compute Engine, cari traffic yang berasal dari instance AlloyDB. Di log instance AlloyDB, cari traffic dari VM Compute Engine.