Mengaktifkan Jaringan Virtual
Aktivasi dilakukan melalui wizard pada pusat data: Pusat Data › Jaringan Virtual › Aktifkan. Wizard ini menjalankan lima langkah yang sama untuk setiap mode; langkah 2 adalah bagian yang berbeda.
Lisensi
Aktivasi memerlukan hak (entitlement) Jaringan Virtual pada lisensi Cockpit Anda. Jika belum ada, tambahkan ke langganan Anda dan impor lisensi yang diperbarui sebelum Anda mulai — lihat catatan di ikhtisar.
Sebelum memulai, setiap host di pusat data harus terhubung di Cockpit. Wizard akan memeriksa kemampuan masing-masing host, dan host yang tidak dapat dihubungi tidak dapat disertakan.
Langkah 1 — Nama dan mode
Beri nama untuk deployment dan pilih salah satu dari tiga mode yang dijelaskan di ikhtisar. Mode tidak dapat diubah setelahnya; untuk beralih, Anda harus menonaktifkan lalu mengaktifkannya kembali.
Langkah 2 — Kebutuhan masing-masing mode
Bentuk deployment OVN native Vapor
Pilih central: host-host yang akan menjalankan basis data OVN sebagai klaster RAFT.
- 1, 3, atau 5. Wizard menolak jumlah 2 dan 4. Jumlah genap secara mendasar lebih buruk daripada jumlah ganjil di bawahnya: dua central tidak dapat saling mengungguli dalam pemungutan suara (vote), sehingga kehilangan salah satu akan menjatuhkan seluruh klaster.
- Tersebar di beberapa klaster. Jika pusat data memiliki tiga klaster atau lebih, wizard secara bawaan memilih satu central per klaster. Sebuah klaster biasanya mewakili satu rak atau domain kegagalan (failure domain); tiga central dalam satu rak dapat bertahan dari kegagalan host tetapi tidak dari kegagalan rak.
- Basis data yang sudah ada. Jika central yang dipilih telah memiliki berkas basis data OVN sebelumnya, pemeriksaan preflight akan memberitahukannya (lihat di bawah). Berkas-berkas tersebut mungkin berisi seluruh konfigurasi logis dari fungsi sebelumnya. Wizard tidak akan menggantinya tanpa konfirmasi eksplisit dari Anda.
Setiap host lain di pusat data akan bergabung sebagai chassis. Deployment dengan satu central dapat berfungsi tanpa redundansi; gunakan ini hanya untuk lingkungan lab.
Bergabung dengan deployment OVN eksternal yang ada
Masukkan alamat basis data northbound dan southbound, misalnya tcp:10.0.0.1:6641 dan tcp:10.0.0.1:6642.
Jika basis data eksternal berbentuk klaster, cantumkan semua anggota yang dipisahkan dengan koma: tcp:10.0.0.1:6641,tcp:10.0.0.2:6641,tcp:10.0.0.3:6641. Klien OVN hanya berbicara dengan pemimpin (leader) klaster, sehingga satu alamat saja akan berhenti berfungsi saat kepemimpinan beralih ke anggota lain. Gunakan ssl: sebagai pengganti tcp: jika basis data memerlukan TLS.
Pemetaan bridge bersifat opsional dan berlaku untuk setiap host; biarkan kosong kecuali deployment eksternal memerlukan provider network.
Bergabung dengan klaster Kube-OVN yang ada
Tidak ada yang perlu diketik di sini. Wizard menampilkan apa yang ditemukan pada setiap host:
| Kolom | Arti |
|---|---|
| Kube-OVN | Apakah kube-ovn berjalan di host tersebut. Terdeteksi melalui API Kubernetes jika host memiliki kubeconfig, atau dari daemon kube-ovn di host jika tidak (node worker biasanya tidak memilikinya). |
| Node | Nama node Kubernetes. |
| --enable-external-vpc | Flag controller kube-ovn. Lihat peringatan bahaya di bawah. |
| Northbound (terdeteksi) | Alamat basis data yang dilaporkan oleh kube-ovn. |
Alamat deployment diisi secara otomatis dari host pertama yang melaporkannya dan ditampilkan sebagai hanya baca. Centang Override the discovered addresses hanya jika Anda benar-benar yakin melebihi deteksi CNI. Jika host melaporkan alamat yang berbeda-beda, berarti mereka berada di klaster kube-ovn yang berbeda, dan satu pusat data hanya dapat bergabung ke satu klaster.
Host yang bukan node kube-ovn akan dikecualikan
Host yang bukan merupakan node kube-ovn tidak dapat bergabung dalam mode ini. Jika dipaksakan bergabung, host tersebut akan terdaftar di basis data southbound kube-ovn sebagai chassis yang tidak dikenal oleh kube-ovn — dan controller kube-ovn akan menghapus chassis yang tidak dikenal setiap kali ia dimulai ulang. Hal yang sama berlaku untuk node yang Vapor-nya tidak memiliki perkakas klien OVN, karena node tersebut tidak akan pernah bisa membaca basis data yang dimasukinya.
Host semacam itu dicatat sebagai excluded (dikecualikan) beserta alasannya, dan tidak ada konfigurasi yang diterapkan padanya. Untuk menyertakannya nanti, perbaiki penyebabnya (pasang kube-ovn, atau pasang paket ovn-common dan openvswitch-switch) lalu gunakan Sync.
Flag --enable-external-vpc
Controller kube-ovn menganggap basis data northbound adalah miliknya sepenuhnya. Objek apa pun yang tidak dapat dipetakan ke resource Kubernetes dianggap sebagai kebocoran yang harus dibersihkan: port switch logis dibersihkan dengan timer 360 detik, serta switch dan router logis dibersihkan sekaligus setiap kali controller dimulai ulang. Opsi yang mengecualikan objek luar dari pembersihan ini adalah --enable-external-vpc=true pada deployment kube-ovn-controller, dan nilai bawaannya adalah false.
Tanpa flag ini, setiap jaringan yang Anda buat melalui Cockpit hanya bertahan hingga controller dimulai ulang dan kemudian menghilang — yang bisa terjadi berminggu-minggu kemudian, ketika tidak ada lagi yang menghubungkan kedua peristiwa tersebut. Preflight akan melaporkan status flag ini; wizard tidak akan melanjutkan tanpa persetujuan eksplisit jika flag belum diatur. Sebaiknya atur flag tersebut terlebih dahulu.
Langkah 3 — Host dan enkapsulasi
Setiap host di pusat data ditampilkan dalam satu baris beserta IP enkapsulasi yang akan digunakan untuk tunnel Geneve. Wizard mengisinya berdasarkan apa yang diusulkan oleh host itu sendiri; edit baris jika host memiliki antarmuka yang lebih baik untuk lalu lintas tunnel (misalnya jaringan penyimpanan atau overlay khusus).
Dua aturan yang ditegakkan oleh wizard:
- Satu alamat per host. Dua host yang berbagi IP enkapsulasi yang sama akan menghasilkan fabric di mana tunnel tidak akan pernah aktif.
- Jangan pernah menyalin alamat satu host ke host lain. Setiap baris adalah milik host itu sendiri.
Pada mode native-Vapor, IP enkapsulasi milik central juga menjadi alamat basis data yang dihubungi oleh setiap host.
Langkah 4 — Preflight
Wizard memeriksa seluruh pusat data sebelum mengubah apa pun. Setiap pemeriksaan ditampilkan per host beserta rinciannya; hasil fail memblokir aktivasi, sedangkan warn membutuhkan konfirmasi persetujuan.
| Pemeriksaan | Yang diverifikasi |
|---|---|
| Central quorum | 1, 3, atau 5 central (native-Vapor). |
| Encapsulation path | Setiap host dapat menjangkau IP enkapsulasi host lainnya. Ini adalah pengujian nyata antar-host, bukan sekadar perbandingan subnet. |
| Geneve MTU headroom | Pengujian yang sama dengan paket berukuran frame guest 1500 byte yang ditunnelkan. Peringatan warn di sini berarti jalur berfungsi tetapi guest pada fabric ini harus memakai MTU lebih kecil (1442 dengan underlay 1500 byte) atau underlay harus dinaikkan ke 1558. Mengabaikan hal ini menyebabkan VM dapat terhubung namun gagal melewatkan paket berukuran penuh. |
| Existing OVN databases | Calon central sudah memiliki berkas basis data. Jika berkas tersebut milik klaster yang sedang berjalan, pemeriksaan ini lolos; jika berupa basis data mandiri, akan muncul peringatan dan konfirmasi replace databases ditampilkan — cadangkan (backup) terlebih dahulu. |
| Kube-OVN membership | Status partisipasi tiap host; host yang dikecualikan dicantumkan beserta alasannya. |
| Kube-OVN external VPC | Flag controller, sebagaimana dijelaskan di atas. |
| Per-host checks | Preflight dari Vapor pada masing-masing host: paket terpasang, basis data dapat dijangkau, IP enkapsulasi valid di host tersebut, dan central yang bergabung dapat menjangkau anggota klaster yang akan diikutinya. |
Aktivasi dapat dilakukan setelah tidak ada yang gagal dan semua peringatan telah dikonfirmasi.
Langkah 5 — Terapkan dan verifikasi
Wizard menampilkan status tiap host saat proses berjalan. Pada mode native-Vapor, ini berlangsung secara berurutan: central pertama melakukan bootstrap, central lainnya bergabung satu per satu, kemudian seluruh chassis diproses secara paralel — sehingga membutuhkan waktu puluhan detik, bukan instan.
Setiap host dilaporkan dalam dua tingkatan: applied (Vapor menerima konfigurasi) dan registered (host benar-benar muncul di basis data southbound sebagai chassis). Sebuah host bisa berada di satu tahap tanpa mencapai tahap berikutnya; wizard akan menunjukkan statusnya secara jelas.
Setelah selesai:
- Active — semua host berhasil masuk. Klik Finish untuk menuju ke halaman deployment.
- Partial atau Error — beberapa host belum berhasil. Galat tercantum pada masing-masing host. Tombol Retry failed hosts akan menerapkan ulang ke semua anggota dan mendorong ulang daftar anggota; tombol Close membiarkan deployment apa adanya, dan tab Jaringan Virtual akan menampilkan status serta opsi coba lagi yang sama.
Penyebab paling umum dari hasil parsial adalah host yang tidak dapat dihubungi saat waktu penerapan. Perbaiki penyebabnya, lalu coba lagi — tidak ada yang perlu dibatalkan terlebih dahulu.
Setelah aktivasi
Setiap host sekarang melaporkan chassis-nya di bawah Host › Konfigurasi › Jaringan › Jaringan Virtual, dan tab pusat data menampilkan inventaris fabric. Dari sini, pengelolaan harian dijelaskan dalam Mengoperasikan Jaringan Virtual.