[ English | Indonesia | Deutsch | 日本語 ]
Upgrade¶
Dengan pengecualian Object Storage, memutakhirkan dari satu versi OpenStack ke yang lain dapat membutuhkan banyak usaha. Bab ini memberikan beberapa panduan tentang aspek operasional yang harus Anda pertimbangkan untuk melakukan peningkatan (upgrade) untuk lingkungan OpenStack.
Pertimbangan pra-upgrade¶
Upgrade perencanaan¶
Tinjau sepenuhnya release notes <https://releases.openstack.org/> _ untuk mempelajari tentang fitur-fitur baru, yang diperbarui, dan usang. Temukan ketidaksesuaian antar versi.
Pertimbangkan dampak upgrade ke pengguna. Proses upgrade mengganggu manajemen lingkungan Anda termasuk dasbor. Jika Anda mempersiapkan upgrade dengan benar, instance yang ada, jaringan, dan penyimpanan harus terus beroperasi. Namun, instance mungkin mengalami gangguan jaringan terputus putus (intermittent).
Pertimbangkan pendekatan untuk upgrade lingkungan Anda. Anda dapat melakukan upgrade dengan instance operasional, tetapi ini adalah pendekatan yang berbahaya. Anda mungkin mempertimbangkan menggunakan migrasi langsung untuk memindahkan sementara instance ke node komputasi lain saat melakukan upgrade. Namun, Anda harus memastikan konsistensi database selama proses berlangsung; jika tidak, lingkungan Anda mungkin menjadi tidak stabil. Juga, jangan lupa untuk memberikan pemberitahuan yang cukup kepada pengguna Anda, termasuk memberi mereka banyak waktu untuk melakukan backup sendiri.
Pertimbangkan untuk mengadopsi struktur dan opsi dari file konfigurasi layanan dan menggabungkannya dengan file konfigurasi yang ada. OpenStack Configuration Reference <https://docs.openstack.org/ocata/config-reference/> _ berisi opsi baru, yang diperbarui, dan tidak digunakan lagi untuk sebagian besar layanan.
Seperti semua upgrade sistem utama, upgrade Anda bisa gagal karena satu atau beberapa alasan. Anda dapat mempersiapkan diri untuk situasi ini dengan memiliki kemampuan untuk memutar kembali lingkungan Anda ke rilis sebelumnya, termasuk database, file konfigurasi, dan paket. Kami memberikan contoh proses untuk mengembalikan lingkungan Anda di Mengembalikan upgrade yang gagal.
Kembangkan prosedur upgrade dan nilai secara menyeluruh dengan menggunakan lingkungan pengujian yang serupa dengan lingkungan produksi Anda.
Pra-upgrade lingkungan pengujian¶
Langkah paling penting adalah pengujian pra-upgrade. Jika Anda upgrade segera setelah rilis versi baru, bug yang belum ditemukan mungkin menghambat kemajuan Anda. Beberapa penyebar lebih suka menunggu sampai rilis poin pertama diumumkan. Namun, jika Anda memiliki penyebaran yang signifikan, Anda dapat mengikuti pengembangan dan pengujian rilis untuk memastikan bahwa bug untuk kasus penggunaan Anda diperbaiki.
Setiap cloud OpenStack berbeda bahkan jika Anda memiliki arsitektur yang hampir sama seperti yang dijelaskan dalam panduan ini. Akibatnya, Anda masih harus menguji upgrade antar versi di lingkungan Anda menggunakan klon perkiraan lingkungan Anda.
Namun, itu tidak berarti bahwa ukurannya harus sama atau menggunakan perangkat keras yang identik dengan lingkungan produksi. Penting untuk mempertimbangkan perangkat keras dan skala cloud yang sedang Anda upgrade. Kiat-kiat berikut dapat membantu Anda meminimalkan biaya:
- Gunakan cloud Anda sendiri
Tempat paling sederhana untuk mulai menguji versi OpenStack berikutnya adalah dengan mengatur lingkungan baru di dalam cloud Anda sendiri. Ini mungkin tampak aneh, terutama virtualisasi ganda yang digunakan dalam menjalankan node komputasi. Tetapi ini adalah cara yang pasti untuk menguji konfigurasi Anda dengan sangat cepat.
- Gunakan cloud publik
Pertimbangkan untuk menggunakan cloud publik untuk menguji batas skalabilitas konfigurasi pengontrol cloud Anda. Sebagian besar awan publik menagih per jam, yang berarti tidak mahal untuk melakukan bahkan pengujian dengan banyak node.
- Buat endpoint penyimpanan lain pada sistem yang sama
Jika Anda menggunakan plug-in penyimpanan eksternal atau sistem file bersama dengan cloud Anda, Anda dapat menguji apakah itu berfungsi dengan membuat share atau endpoint kedua. Ini memungkinkan Anda untuk menguji sistem sebelum mempercayakan versi baru ke penyimpanan Anda.
- Amati jaringannya
Bahkan pada pengujian skala kecil, cari paket jaringan berlebih untuk menentukan apakah ada sesuatu yang salah dalam komunikasi antar-komponen.
Untuk mengatur lingkungan pengujian, Anda dapat menggunakan salah satu dari beberapa metode:
Lakukan instalasi manual lengkap dengan menggunakan Installation Tutorials and Guides <https://docs.openstack.org/rocky/install/> _ untuk platform Anda. Tinjau file konfigurasi akhir dan paket yang diinstal.
Buat klon dari infrastruktur konfigurasi otomatis Anda dengan URL repositori paket yang diubah.
Ubah konfigurasi hingga berfungsi.
Semua pendekatan ini valid. Gunakan pendekatan yang sesuai dengan pengalaman Anda.
Sistem pra-testing upgrade sangat baik untuk membuat konfigurasi berfungsi. Namun, penting untuk dicatat bahwa penggunaan historis sistem dan perbedaan dalam interaksi pengguna dapat mempengaruhi keberhasilan upgrade.
Jika memungkinkan, kami sangat menyarankan Anda membuang tabel database produksi Anda dan menguji upgrade di lingkungan pengembangan Anda menggunakan data ini. Beberapa bug MySQL telah ditemukan selama migrasi basis data karena sedikit perbedaan tabel antara instalasi baru dan tabel yang dimigrasikan dari satu versi ke versi lain. Ini akan berdampak pada kumpulan data nyata besar, yang Anda tidak ingin temui selama penghentian (outage) produksi.
Pengujian skala buatan hanya bisa sejauh ini. Setelah cloud Anda ditingkatkan (upgraded), Anda harus memperhatikan aspek kinerja cloud Anda.
Tingkat Upgrade¶
Tingkat upgrade adalah fitur yang ditambahkan ke OpenStack Compute sejak rilis Grizzly untuk menyediakan penguncian versi pada komunikasi RPC (Message Queue) antara berbagai layanan Compute.
Fungsionalitas ini adalah bagian penting dari teka-teki (puzzle) ketika datang ke peningkatan langsung dan secara konsep mirip dengan versi API yang ada yang memungkinkan layanan OpenStack dari berbagai versi untuk berkomunikasi tanpa masalah.
Tanpa tingkat upgrade, layanan Compute versi X + 1 dapat menerima dan memahami pesan RPC versi X, tetapi hanya dapat mengirim pesan RPC versi X+1. Misalnya, jika proses nova-conductor telah ditingkatkan ke versi X+1, maka layanan konduktor akan dapat memahami pesan dari proses penghitungan nova versi X, tetapi layanan komputasi tersebut tidak akan dapat memahami pesan yang dikirim oleh layanan konduktor.
Selama upgrade, operator dapat menambahkan opsi konfigurasi ke nova.conf yang mengunci versi pesan RPC dan memungkinkan upgrade langsung layanan tanpa gangguan yang disebabkan oleh ketidakcocokan versi. Opsi konfigurasi memungkinkan spesifikasi nomor versi RPC jika diinginkan, tetapi nama alias rilis juga didukung. Sebagai contoh:
[upgrade_levels]
compute=X
conductor=X
scheduler=X
will keep the RPC version locked across the specified services to the
RPC version used in X. As all instances of a particular service are
upgraded to the newer version, the corresponding line can be removed
from nova.conf.
Dengan menggunakan fungsi ini, idealnya seseorang akan mengunci versi RPC ke versi OpenStack yang upgraded dari pada nova-compute nodes, untuk memastikan bahwa, misalnya X+1 versi proses nova-compute akan terus bekerja dengan versi X proses nova-conductor sementara upgrade selesai. Setelah upgrade proses nova-compute selesai, operator dapat beralih ke upgrading nova-conductor dan menghapus penguncian versi untuk nova-compute di nova.conf.
Proses Upgrade¶
Bagian ini menjelaskan proses untuk upgrade penyebaran OpenStack dasar berdasarkan arsitektur two-node dasar di Installation Tutorials and Guides <https://docs.openstack.org/rocky/install/> _. Semua node harus menjalankan distribusi Linux yang didukung dengan kernel terbaru dan paket rilis saat ini.
Instruksi upgrade layanan khusus¶
Lihat catatan upgrade berikut untuk informasi tentang upgrade layanan OpenStack tertentu:
Prasyarat¶
Lakukan pembersihan lingkungan sebelum memulai proses upgrade untuk memastikan kondisi yang konsisten. Misalnya, instance yang tidak sepenuhnya dibersihkan dari sistem setelah penghapusan dapat menyebabkan perilaku tak tentu.
Untuk lingkungan yang menggunakan layanan OpenStack Networking (neutron), verifikasi versi rilis dari database. Sebagai contoh:
# su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf \ --config-file /etc/neutron/plugins/ml2/ml2_conf.ini current" neutron
Lakukan pencadangan¶
Simpan file konfigurasi di semua node. Sebagai contoh:
# for i in keystone glance nova neutron openstack-dashboard cinder heat ceilometer; \ do mkdir $i-RELEASE_NAME; \ done # for i in keystone glance nova neutron openstack-dashboard cinder heat ceilometer; \ do cp -r /etc/$i/* $i-RELEASE_NAME/; \ done
Catatan
Anda dapat memodifikasi skrip contoh ini di setiap node untuk menangani layanan yang berbeda.
Buat cadangan database lengkap dari data produksi Anda. Sejak rilis Kilo, penurunan versi database tidak didukung, dan memulihkan dari cadangan adalah satu-satunya metode yang tersedia untuk mengambil versi database sebelumnya.
# mysqldump -u root -p --opt --add-drop-database --all-databases > RELEASE_NAME-db-backup.sql
Catatan
Pertimbangkan memperbarui konfigurasi server SQL Anda seperti yang dijelaskan dalam Installation Tutorials and Guides.
Kelola repositori¶
Di semua node:
Hapus repositori untuk paket rilis sebelumnya.
Tambahkan repositori untuk paket rilis baru.
Update basis data repositori.
Upgrade paket pada setiap node¶
Bergantung pada konfigurasi spesifik Anda, upgrading semua paket mungkin restart atau merusak (break) layanan tambahan ke lingkungan OpenStack Anda. Misalnya, jika Anda menggunakan framework TGT iSCSI untuk volume Block Storage dan upgrade termasuk paket-paket baru untuk itu, manajer paket mungkin restart layanan TGT iSCSI dan berdampak konektivitas ke volume.
Jika manajer paket meminta Anda untuk update file konfigurasi, tolak perubahannya. Manajer paket menambahkan akhiran ke versi yang lebih baru dari file konfigurasi. Pertimbangkan untuk meninjau dan mengadopsi konten dari file-file ini.
Catatan
Anda mungkin perlu menginstal paket ipset secara eksplisit jika distribusi Anda tidak menginstalnya sebagai dependensi.
Update layanan¶
Untuk update layanan pada setiap node, Anda biasanya memodifikasi satu atau lebih file konfigurasi, menghentikan layanan, menyinkronkan skema database, dan memulai layanan. Beberapa layanan memerlukan langkah-langkah berbeda. Kami merekomendasikan verifikasi operasi setiap layanan sebelum melanjutkan ke layanan berikutnya.
Urutan yang harus Anda upgrade layanan, dan setiap perubahan dari proses upgrade umum dijelaskan di bawah ini:
Controller node
Layanan Identity - Hapus token yang kedaluwarsa sebelum menyinkronkan database.
Layanan Image
Layanan Compute, termasuk komponen jaringan.
Layanan Networking
Layanan Block Storage
Dasbor - Dalam lingkungan umum, memperbarui Dasbor hanya membutuhkan restarting layanan HTTP Apache.
Layanan Orchestration
Layanan Telemetry - Dalam lingkungan tipikal, update layanan Telemetry hanya membutuhkan restarting layanan.
Layanan Compute - Edit file konfigurasi dan restart layanan.
Layanan Networking - Edit file konfigurasi dan restart layanan.
Storage nodes
Layanan Block Storage - Update layanan Block Storage hanya membutuhkan restarting layanan.
Compute nodes
Layanan Networking - Edit file konfigurasi dan restart layanan.
Langkah terakhir¶
Di semua distribusi, Anda harus melakukan beberapa tugas akhir untuk menyelesaikan proses upgrade.
Kurangi waktu tunggu DHCP dengan memodifikasi file
/etc/nova/nova.confpada komputasi nodes kembali ke nilai asli untuk lingkungan Anda.Update semua file
.iniuntuk mencocokkan kata sandi dan pipeline seperti yang diperlukan untuk rilis OpenStack di lingkungan Anda.Setelah migrasi, pengguna melihat hasil yang berbeda dari openstack image list dan glance image-list. Untuk memastikan pengguna melihat image yang sama dalam perintah daftar, edit file
/etc/glance/policy.jsondan file/etc/nova/policy.jsonyang berisi"context_is_admin": "role:admin", yang membatasi akses ke image pribadi untuk proyek.Verifikasi pengoperasian lingkungan Anda dengan benar. Lalu, beri tahu pengguna Anda bahwa cloud mereka beroperasi secara normal lagi.
Mengembalikan upgrade yang gagal¶
Bagian ini memberikan panduan untuk memutar kembali (rolling back) ke rilis OpenStack sebelumnya. Semua distribusi mengikuti prosedur serupa.
Peringatan
Mengembalikan lingkungan Anda harus menjadi tindakan terakhir karena Anda kemungkinan kehilangan data yang ditambahkan sejak cadangan.
Skenario umum adalah menghapus layanan manajemen produksi dalam persiapan untuk upgrade, menyelesaikan bagian dari proses upgrade, dan menemukan satu atau lebih masalah yang tidak ditemukan selama pengujian. Sebagai akibatnya, Anda harus memutar kembali (roll back) lingkungan Anda ke keadaan "known good" yang asli. Anda juga memastikan bahwa Anda tidak membuat perubahan keadaan setelah mencoba proses upgrade; tidak ada instance baru, jaringan, volume penyimpanan, dan sebagainya. Sumber daya baru ini akan dalam keadaan beku setelah database dipulihkan dari cadangan.
Dalam lingkup ini, Anda harus menyelesaikan langkah-langkah ini untuk berhasil mengembalikan lingkungan Anda:
Roll back file konfigurasi.
Restore databases dari backup.
Roll backpaket.
Anda harus memverifikasi bahwa Anda memiliki backup yang diperlukan untuk restore. Rolling back upgrade adalah proses yang sulit karena distribusi cenderung berupaya lebih banyak untuk menguji upgrade daripada downgrade versi. Downgrade rusak membutuhkan upaya lebih besar untuk memecahkan masalah dan, menyelesaikan daripada upgrade yang rusak. Hanya Anda yang dapat mempertimbangkan risiko mencoba mendorong upgrade yang gagal ke depan dibandingkan mengembalikannya. Secara umum, pertimbangkan rolling back sebagai opsi terakhir.
Langkah-langkah berikut yang dijelaskan untuk Ubuntu telah bekerja pada setidaknya satu lingkungan produksi, tetapi mereka mungkin tidak bekerja untuk semua lingkungan.
To perform a rollback
Hentikan semua layanan OpenStack.
Salin konten direktori cadangan konfigurasi yang Anda buat selama proses upgrade kembali ke
/etc/<service>directory.Pulihkan basis data dari file cadangan
RELEASE_NAME-db-backup.sqlyang Anda buat dengan perintah mysqldump selama proses upgrade:# mysql -u root -p < RELEASE_NAME-db-backup.sql
Downgrade paket OpenStack.
Peringatan
Paket penurunan versi sejauh ini merupakan langkah paling rumit; sangat tergantung pada distribusi dan administrasi keseluruhan sistem.
Tentukan paket OpenStack mana yang diinstal pada sistem Anda. Gunakan perintah dpkg --get-selections. Saring untuk paket OpenStack, saring lagi untuk menghilangkan paket yang secara eksplisit ditandai dalam keadaan
deinstall, dan simpan hasil akhir ke file. Misalnya, perintah berikut ini mencakup node pengontrol dengan keystone, glance, nova, neutron, dan cinder:# dpkg --get-selections | grep -e keystone -e glance -e nova -e neutron \ -e cinder | grep -v deinstall | tee openstack-selections cinder-api install cinder-common install cinder-scheduler install cinder-volume install glance install glance-api install glance-common install glance-registry install neutron-common install neutron-dhcp-agent install neutron-l3-agent install neutron-lbaas-agent install neutron-metadata-agent install neutron-plugin-openvswitch install neutron-plugin-openvswitch-agent install neutron-server install nova-api install nova-common install nova-conductor install nova-consoleauth install nova-novncproxy install nova-objectstore install nova-scheduler install python-cinder install python-cinderclient install python-glance install python-glanceclient install python-keystone install python-keystoneclient install python-neutron install python-neutronclient install python-nova install python-novaclient install
Catatan
Bergantung pada jenis server, isi dan urutan daftar paket Anda mungkin berbeda dari contoh ini.
Anda dapat menentukan versi paket yang tersedia untuk pembalikan dengan menggunakan perintah
apt-cache policy. Sebagai contoh:# apt-cache policy nova-common nova-common: Installed: 2:14.0.1-0ubuntu1~cloud0 Candidate: 2:14.0.1-0ubuntu1~cloud0 Version table: *** 2:14.0.1-0ubuntu1~cloud0 500 500 http://ubuntu-cloud.archive.canonical.com/ubuntu xenial-updates/newton/main amd64 Packages 100 /var/lib/dpkg/status 2:13.1.2-0ubuntu2 500 500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 2:13.0.0-0ubuntu2 500 500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
Catatan
Jika Anda menghapus repositori rilis, Anda harus menginstalnya kembali dan menjalankan perintah apt-get update
Output perintah mencantumkan versi paket yang saat ini diinstal, versi kandidat terbaru, dan semua versi beserta repositori yang berisi setiap versi. Cari versi rilis yang sesuai—
2:14.0.1-0ubuntu1~cloud0dalam kasus ini. Proses memilih secara manual daftar paket ini agak membosankan dan rentan terhadap kesalahan. Anda harus mempertimbangkan untuk menggunakan skrip untuk membantu proses ini. Sebagai contoh:# for i in `cut -f 1 openstack-selections | sed 's/neutron/;'`; do echo -n $i ;apt-cache policy $i | grep -B 1 RELEASE_NAME | grep -v Packages | awk '{print "="$1}';done | tr '\n' ' ' | tee openstack-RELEASE_NAME-versions cinder-api=2:9.0.0-0ubuntu1~cloud0 cinder-common=2:9.0.0-0ubuntu1~cloud0 cinder-scheduler=2:9.0.0-0ubuntu1~cloud0 cinder-volume=2:9.0.0-0ubuntu1~cloud0 glance=2:13.0.0-0ubuntu1~cloud0 glance-api=2:13.0.0-0ubuntu1~cloud0 500 glance-common=2:13.0.0-0ubuntu1~cloud0 500 glance-registry=2:13.0.0-0ubuntu1~cloud0 500 neutron-common=2:9.0.0-0ubuntu1~cloud0 neutron-dhcp-agent=2:9.0.0-0ubuntu1~cloud0 neutron-l3-agent=2:9.0.0-0ubuntu1~cloud0 neutron-lbaas-agent=2:9.0.0-0ubuntu1~cloud0 neutron-metadata-agent=2:9.0.0-0ubuntu1~cloud0 neutron-server=2:9.0.0-0ubuntu1~cloud0 nova-api=2:14.0.1-0ubuntu1~cloud0 nova-common=2:14.0.1-0ubuntu1~cloud0 nova-conductor=2:14.0.1-0ubuntu1~cloud0 nova-consoleauth=2:14.0.1-0ubuntu1~cloud0 nova-novncproxy=2:14.0.1-0ubuntu1~cloud0 nova-objectstore=2:14.0.1-0ubuntu1~cloud0 nova-scheduler=2:14.0.1-0ubuntu1~cloud0 python-cinder=2:9.0.0-0ubuntu1~cloud0 python-cinderclient=1:1.9.0-0ubuntu1~cloud0 python-glance=2:13.0.0-0ubuntu1~cloud0 python-glanceclient=1:2.5.0-0ubuntu1~cloud0 python-neutron=2:9.0.0-0ubuntu1~cloud0 python-neutronclient=1:6.0.0-0ubuntu1~cloud0 python-nova=2:14.0.1-0ubuntu1~cloud0 python-novaclient=2:6.0.0-0ubuntu1~cloud0 python-openstackclient=3.2.0-0ubuntu2~cloud0
Gunakan perintah apt-get install untuk menginstal versi spesifik dari setiap paket dengan menentukan
<package-name>=<version>. Script pada langkah sebelumnya dengan mudah membuat daftar pasanganpackage=versionuntuk Anda:# apt-get install `cat openstack-RELEASE_NAME-versions`
Langkah ini melengkapi prosedur rollback. Anda harus menghapus repositori rilis upgrade dan menjalankan :command:`apt-get update`untuk mencegah upgrade yang tidak disengaja sampai Anda memecahkan masalah apa pun yang menyebabkan Anda roll back lingkungan Anda.
