Skip to content

Pemecahan Masalah Jaringan Virtual

OVN memiliki satu pola kegagalan yang sering kali membingungkan banyak orang, jadi sangat penting untuk mengetahuinya sebelum hal lain.


Aturan yang Ada Namun Tidak Berfungsi

Database northbound OVN melakukan validasi yang sangat sedikit. Database ini akan menerima aturan yang ekspresinya tidak dapat dikompilasi oleh data plane. Ketika hal itu terjadi:

  • objek berhasil dibuat,
  • API melaporkan sukses,
  • antarmuka web mencantumkannya sebagai sehat/aktif,
  • dan aturan tersebut sama sekali tidak berpengaruh apa pun.

Tidak ada apa pun di Vapor yang dapat memperingatkan Anda tentang hal ini, karena sejauh menyangkut database, objek tersebut tampak baik-baik saja. Satu-satunya bukti ada pada host, di dalam log ovn-controller:

grep -iE "error parsing|Syntax error" /var/log/ovn/ovn-controller.log

Jadikan ini pemeriksaan pertama Anda setiap kali sebuah objek ada tetapi tidak berjalan sebagaimana mestinya. Dua contoh umum yang menyebabkannya:

  • karakter - dalam nama port group atau address set, yang dibaca oleh OVN sebagai operasi pengurangan
  • nilai opsi yang salah bentuk (malformed), seperti daftar server DNS dalam format yang keliru

Sinyal kedua untuk masalah serupa: aturan muncul dalam ovn-sbctl lflow-list tetapi tidak memiliki entri yang sesuai dalam ovs-ofctl dump-flows br-int. Aturan logis berhasil dibuat tetapi switch menolaknya.


Gejala dan Tempat Memeriksa

Mesin virtual tidak mendapatkan alamat DHCP

  • Apakah MAC yang dicatat OVN untuk port cocok dengan MAC yang dikirimkan guest? Keduanya harus sama; penanggap (responder) DHCP OVN mencocokkan berdasarkan sumber MAC.
  • Apakah DHCP aktif pada subnet tersebut, dan apakah opsi DHCP subnet telah terpasang ke port?
  • Periksa ovn-controller.log seperti di atas — opsi DHCP yang salah bentuk akan menghentikan layanan DHCP untuk setiap port pada switch, bukan hanya satu port.
  • Apakah mesin guest benar-benar meminta alamat IP? Antarmuka yang dipasang saat mesin berjalan (hot-plugged) tidak dikonfigurasi secara otomatis.

Mesin dapat menjangkau gateway dan host satu subnet, tetapi tidak ada rute keluar

Hampir selalu disebabkan oleh perutean di dalam guest daripada masalah OVN. Guest dengan antarmuka kedua biasanya memiliki rute default dengan metrik yang lebih rendah di antarmuka tersebut, sehingga lalu lintas yang dirutekan keluar lewat jalur yang salah. Periksa tabel perutean guest sebelum mencurigai jaringan.

Host pada logical switch yang sama tidak dapat saling menjangkau

  • Apakah kedua port sudah terikat (bound)? Port akan berstatus bound pada halaman Logical Switch Ports setelah ovn-controller mengklaimnya.
  • Apakah alamat tunnel kedua chassis berada pada subnet yang sama? Chassis dengan alamat tunnel yang tidak dapat dijangkau akan berhasil mendaftar tetapi tidak pernah membentuk tunnel.
  • Nol port tunnel pada host tanpa port logis adalah normal. OVN membangun tunnel sesuai kebutuhan (on demand).

Memasang mesin ke logical switch gagal saat mesin dinyalakan

Host memerlukan ovs-vsctl, yang digunakan Vapor untuk menempatkan antarmuka pada integration bridge. Tanpanya, mesin akan gagal dinyalakan dengan pesan kesalahan tentang penambahan port ke br-int. Kartu status OVN melaporkan apakah klien ini tersedia.

Load balancer tidak mengembalikan apa pun

  • Pasang pada logical switch, bukan pada distributed router tanpa gateway port. Balancer yang terpasang pada router mentranslasikan lalu lintas masuk tetapi tidak mentranslasikan balasan paket.
  • Berikan VIP alamat di luar subnet klien. VIP di dalam subnet tidak memiliki responder ARP, sehingga koneksi akan hang sebelum paket dikirim.

ACL tidak memblokir lalu lintas yang seharusnya diblokir

  • Periksa aturan penamaan untuk port group dan address set, lalu periksa ovn-controller.log.
  • Pastikan remote benar-benar tercatat. ACL tanpa pembatasan sumber cocok dengan setiap sumber, yang lebih luas dari yang diinginkan dan terlihat seolah-olah aturan "tidak bekerja" padahal kenyataannya aturan bekerja untuk semua hal.
  • allow bersifat stateless. Untuk koneksi yang berorientasi koneksi gunakan allow-related, jika tidak paket balasan akan dibuang (drop).

Objek menghilang setelah beberapa saat

Pada deployment kube-ovn bersama, hal ini disebabkan oleh proses garbage collection milik kube-ovn. Periksa:

kubectl -n kube-system logs deploy/kube-ovn-controller | grep gc.go

dan periksa apakah controller sempat me-restart. Lihat bagian mode 3 pada Mengaktifkan Jaringan Virtual untuk tiga kondisi pencegahannya.

Router menghilang pada deployment kube-ovn

Jika --enable-external-vpc=true disetel, setiap router milik Vapor juga ada sebagai resource Vpc Kubernetes, dan menghapus resource tersebut akan menghapus router di OVN. Periksa apakah ada kakas otomatis yang memangkasnya (pruned).


Pemeriksaan Khusus Klaster

Anggota menolak koneksi pada port klien

Normal pada follower. Klien OVSDB hanya berbicara kepada leader, sehingga kueri yang diarahkan ke satu follower akan ditolak meskipun anggota tersebut sehat. Vapor mengalamatkan klaster melalui semua anggotanya karena alasan ini. Untuk meminta keterangan pada follower secara langsung saat diagnosis, gunakan --no-leader-only.

Kepemimpinan terus berpindah

Normal setelah restart atau gangguan kontak singkat. Deployment tetap dapat digunakan. Kepemimpinan yang berpindah ke anggota yang berbeda dari saat pertama kali di-bootstrap bukanlah suatu kesalahan.

Database central tidak dapat menyala

Periksa urutan startup: ovn-northd memerlukan kedua layanan database aktif, dan menyalakan keduanya secara bersamaan dapat menimbulkan race condition. Nyalakan ovn-ovsdb-server-nb dan ovn-ovsdb-server-sb terlebih dahulu, pastikan keduanya aktif, lalu nyalakan ovn-northd.

Setelah reboot central tidak memiliki database

Parameter klaster tersimpan di dalam konfigurasi unit service OVN dan unit-unit tersebut harus diaktifkan (enabled). Vapor mengaktifkannya selama proses aktivasi dan mencatat peringatan jika gagal melakukannya.


Perintah yang Berguna

Jalankan perintah ini pada host. Pada node kube-ovn, kakas ovn-nbctl dan ovs-vsctl mungkin berada di dalam pod alih-alih langsung di host.

bash
# Mengetahui peran yang dianggap oleh host ini
ovn-nbctl --db=<nb-address> show

# Memeriksa apakah port terikat dan ke chassis mana
ovn-sbctl --db=<sb-address> find Port_Binding logical_port=<port>

# Status keanggotaan klaster untuk satu database
ovs-appctl -t /var/run/ovn/ovnnb_db.ctl cluster/status OVN_Northbound

# Aturan logis yang dibuat untuk sebuah switch
ovn-sbctl lflow-list <switch>

# Aturan flow yang benar-benar dipasang oleh switch
ovs-ofctl dump-flows br-int

# Log yang menjelaskan kegagalan diam-diam
grep -iE "error parsing|Syntax error" /var/log/ovn/ovn-controller.log

Saat Melaporkan Masalah

Sertakan mode aktivasi host ini, sumber mana yang menyediakan alamat database (kartu status menampilkannya), apakah objek ada di database northbound, apakah flow yang sesuai ada di switch, dan setiap baris error parsing dari ovn-controller.log. Kelima jawaban ini akan memisahkan kesalahan konfigurasi dari masalah teknis murni lebih cepat daripada cara lainnya.