Legacy nova-network ke OpenStack Networking (neutron)¶

Dua model jaringan ada di OpenStack. Yang pertama disebut legacy networking (nova-network) dan itu adalah sub-process tertanam dalam proyek Compute (nova). Model ini memiliki beberapa keterbatasan, seperti dalam pembuatan topologi jaringan yang kompleks, peluasan implementasi back-end untuk teknologi vendor-specific, dan penyediaan elemen jaringan project-specific. Keterbatasan ini adalah alasan utama model OpenStack Networking (neutron) dibuat.

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

Proses saat seperti yang dirancang adalah migrasi minimal yang layak dengan tujuan mencela (deprecating) dan kemudian menghapus (removing) jaringan legacy. Tim Compute maupun Networking setuju bahwa proses migrasi one-button dari warisan jaringan untuk OpenStack Networking (neutron) bukan merupakan persyaratan penting untuk depresiasi dan penghapusan warisan jaringan di masa mendatang. Bagian ini mencakup proses dan alat-alat yang dirancang untuk memecahkan migrasi use case migration yang sederhana.

Pengguna didorong untuk mengambil alat-alat ini, menguji alat mereka, memberikan umpan balik, dan kemudian memperluas pada pengaturan fitur yang sesuai dengan deployment mereka sendiri; deployers yang menahan diri dari berpartisipasi dalam proses ini berniat untuk menunggu jalan yang lebih baik sesuai dengan use case 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 bagi cloud dan semua pengguna.

Dampak manajemen¶

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

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

Komputasi kebutuhan per-hypervisor “has_transitioned” perubahan boolean 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 disini membutuhkan restart hypervisors rolling. 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 layanan Networking, dan Compute API tetap berfungsi secara penuh. Hypervisors individu dapat digulung kembali (rolled back) ke jaringan legacy 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 pre-migration API ataupun post-migration API

ikhtisar proses migrasi¶

Mulailah neutron-server di config akhir yang ditujukan, kecuali dengan REST API yang terbatas untuk hanya read-write dengan nova-api.
Buatlah Compute REST API read-only.
Jalankan alat dump/restore DB yang menciptakan struktur data Networking yang mewakili konfigurasi jaringan legacy saat ini.
Aktifkan proxy nova-api yang menciptakan objek Compute internal dari informasi Networking (melalui Networking REST API).
Buat Compute REST API read-write lagi. Ini berarti legacy networking DB sekarang tidak terpakai, perubahan baru sekarang disimpan di Networking DB, dan tidak ada rollback adalah mungkin dari sini tanpa kehilangan perubahan baru.

Catatan

Pada saat ini Networking DB adalah sumber kebenaran (source of truth), tetapi nova-api adalah satu-satunya public read-write API.

Berikutnya, Anda akan perlu memigrasikan setiap hypervisor. Untuk melakukannya, ikuti langkah berikut:

Nonaktifkan hypervisor. Ini akan menjadi saat yang tepat untuk bermigrasi secara langsung (live) atau mengevakuasi node komputasi, jika didukung.
Nonaktifkan nova-compute.
Aktifkan agen Networking.
Atur 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, aktifkan OpenStack Networking dengan mengikuti langkah-langkah ini:

Munculkan Networking (l3) node. Router baru akan memiliki MAC+IP identik seperti gateway Compute tua dan juga beberapa jenis immediate cutover memungkinkan, kecuali untuk masalah koneksi stateful seperti NAT.
Membuat Networking API read-write dan menonaktifkan legacy networking.

Migrasi Selesai!