Upgrade

[ English | 日本語 | Deutsch | Indonesia ]

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+1
conductor=X+1
scheduler=X+1

akan membuat versi RPC terkunci di seluruh layanan yang ditentukan ke versi RPC yang digunakan dalam X+1. Karena semua instance layanan tertentu ditingkatkan (upgraded) ke versi yang lebih baru, baris yang sesuai dapat dihapus dari 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.

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

  1. 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.

  2. 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:

  1. Hapus repositori untuk paket rilis sebelumnya.

  2. Tambahkan repositori untuk paket rilis baru.

  3. 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

  1. Layanan Identity - Hapus token yang kedaluwarsa sebelum menyinkronkan database.

  2. Layanan Image

  3. Layanan Compute, termasuk komponen jaringan.

  4. Layanan Networking

  5. Layanan Block Storage

  6. Dasbor - Dalam lingkungan umum, memperbarui Dasbor hanya membutuhkan restarting layanan HTTP Apache.

  7. Layanan Orchestration

  8. Layanan Telemetry - Dalam lingkungan tipikal, update layanan Telemetry hanya membutuhkan restarting layanan.

  9. Layanan Compute - Edit file konfigurasi dan restart layanan.

  10. 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.

  1. Kurangi waktu tunggu DHCP dengan memodifikasi file /etc/nova/nova.conf pada komputasi nodes kembali ke nilai asli untuk lingkungan Anda.

  2. Update semua file .ini untuk mencocokkan kata sandi dan pipeline seperti yang diperlukan untuk rilis OpenStack di lingkungan Anda.

  3. 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.json dan file /etc/nova/policy.json yang berisi "context_is_admin": "role:admin", yang membatasi akses ke image pribadi untuk proyek.

  4. 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:

  1. Roll back file konfigurasi.

  2. Restore databases dari backup.

  3. 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

  1. Hentikan semua layanan OpenStack.

  2. Salin konten direktori cadangan konfigurasi yang Anda buat selama proses upgrade kembali ke /etc/<service> directory.

  3. Pulihkan basis data dari file cadangan RELEASE_NAME-db-backup.sql yang Anda buat dengan perintah mysqldump selama proses upgrade:

    # mysql -u root -p < RELEASE_NAME-db-backup.sql
    
  4. Downgrade paket OpenStack.

    Peringatan

    Paket penurunan versi sejauh ini merupakan langkah paling rumit; sangat tergantung pada distribusi dan administrasi keseluruhan sistem.

    1. 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.

    2. 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~cloud0 dalam 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
      
    3. 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 pasangan package=version untuk 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.

Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.