Legacy nova-network to OpenStack Networking (neutron)¶

Dua model jaringan ada di OpenStack. Yang pertama disebut legacy networking (:term: nova-network) dan itu adalah sub-proses tertanam dalam Compute project (nova). Model ini memiliki beberapa keterbatasan, seperti membuat topologi jaringan yang kompleks, memperluas implementasi back-end untuk teknologi khusus vendor, dan menyediakan elemen jaringan tenant-specific. Keterbatasan ini adalah alasan utama OpenStack Networking (neutron) Model dibuat.

Bagian ini menjelaskan proses migrasi cloud didasarkan pada model jaringan legacy ke model OpenStack Networking. Proses ini membutuhkan perubahan tambahan baik untuk perhitungan maupun jaringan untuk mendukung migrasi. Dokumen ini menjelaskan proses secara keseluruhan dan fitur yang diperlukan baik Networking maupun Compute.

Proses saat seperti yang dirancang adalah migrasi minimal yang layak dengan tujuan depresiasi dan kemudian menghapus jaringan legacy. Kedua tim Compute dan Networking setuju bahwa proses migrasi satu tombol dari legacy networking untuk OpenStack Networking (neutron) bukan merupakan persyaratan penting untuk depresiasi dan penghapusan legacy networking di masa mendatang. Bagian ini mencakup proses dan alat-alat yang dirancang untuk memecahkan migrasi kasus penggunaan sederhana.

User didorong untuk mengambil alat-alat ini, menguji mereka, memberikan umpan balik, dan kemudian memperluas pada set fitur yang sesuai dengan pengerahan mereka sendiri; deployers yang menahan diri dari berpartisipasi dalam proses ini berniat untuk menunggu jalan yang lebih baik sesuai dengan kasus penggunaan mereka mungkin akan kecewa.

Dampak dan keterbatasan¶

Proses migrasi dari layanan jaringan nova-network legacy ke OpenStack Networking (neutron) memiliki beberapa keterbatasan dan dampak pada keadaan operasional cloud. Hal ini penting untuk memahami mereka untuk memutuskan apakah proses ini dapat diterima atau tidak untuk cloud dan semua user.

Dampak manajemen¶

Networking REST API adalah publicly read-only sampai setelah migrasi selesai. Selama migrasi, Networking REST API merupakan read-write only untuk nova-api, dan perubahan Networking hanya diperbolehkan melalui nova-api.

Compute REST API tersedia di seluruh seluruh proses, meskipun ada periode singkat di mana itu dibuat read-only selama migrasi database. Networking REST API perlu untuk mengekspos (ke nova-api) semua rincian yang diperlukan untuk merekonstruksi informasi yang sebelumnya diadakan di database jaringan legacy.

Compute membutuhkan per-hypervisor perubahan boolean “has_transitioned” dalam model data yang akan digunakan selama proses migrasi. Flag ini tidak lagi diperlukan setelah proses selesai.

Dampak operasi¶

Dalam rangka mendukung berbagai opsi pengerahan, proses migrasi dijelaskan di sini membutuhkan rolling restart of hypervisor. Tingkat dan waktu restart hypervisor tertentu berada di bawah kendali operator.

Migrasi dapat berhenti, bahkan untuk jangka waktu (misalnya, saat uji coba atau menyelidiki masalah) dengan beberapa hypervisors pada jaringan legacy dan beberapa di Networking, dan Compute API tetap berfungsi penuh. Hypervisors individu dapat dikembalikan ke legacy networking selama tahap ini migrasi, meskipun ini membutuhkan restart tambahan.

Dalam rangka mendukung jangkauan terluas kebutuhan deployer, proses yang dijelaskan di sini adalah mudah untuk mengotomatisasi tetapi belum otomatis. Deployers harus berharap untuk melakukan beberapa langkah-langkah manual atau menulis beberapa script sederhana untuk melakukan migrasi ini.

Dampak kinerja¶

Selama migrasi, panggilan nova-network API akan melalui konversi internal tambahan untuk panggilan Networking. Ini akan memiliki karakteristik kinerja yang berbeda dan mungkin lebih buruk dibandingkan dengan baik pra-migrasi atau pasca-migrasi API.

Sekilas proses migrasi¶

Start neutron-server dalam configurasi akhir yang diharapkan, kecuali dengan REST API terbatas untuk read-write only dengan nova-api.
Membuat Compute REST API read-only.
Menjalankan alat DB dump/restore yang menciptakan struktur data Networking mewakili konfigurasi jaringan legacy saat ini.
Aktifkan proxy nova-api yang recreates objects internal Compute dari informasi Networking (lewat Networking REST API).
Membuat Compute REST API read-write lagi. Ini berarti legacy networking DB sekarang tidak terpakai, perubahan baru sekarang disimpan di DB Networking, dan tidak ada rollback mungkin dari sini tanpa kehilangan perubahan-perubahan baru.

Catatan

Pada saat ini Networking DB adalah sumber kebenaran, tapi nova-api adalah satu-satunya publik read-write API.

Berikutnya, Anda perlu bermigrasi untuk setiap hypervisor. Untuk melakukannya, ikuti langkah berikut:

Menonaktifkan hypervisor. Ini menjadi saat yang tepat untuk live migrate atau mengevakuasi compute node, jika didukung.
Menonaktifkan nova-compute.
Aktifkan agen Networking.
Mengatur flag “has_transitioned” di Compute hypervisor database/config.
Reboot hypervisor (atau menjalankan alat transisi hidup “smart” jika tersedia).
Aktifkan kembali hypervisor.

Pada titik ini, semua node komputasi telah bermigrasi, namun mereka masih menggunakan nova-api API dan gateway Compute. Akhirnya, mengaktifkan OpenStack Networking dengan mengikuti langkah-langkah ini:

Memunculkan node Networking (l3). Router baru akan memiliki MAC+IP identik sebagai gateway Compute tua jadi semacam cutover segera mungkin, kecuali ada masalah koneksi stateful seperti NAT.
Membuat Networking API read-write dan menonaktifkan legacy networking.

Migrasi Selesai!