[ English | English (United Kingdom) | Deutsch | русский | español | Indonesia ]
Pemutakhiran besar¶
This guide provides information about the upgrade process from 2023.2 or 2023.1 to 2024.1 for OpenStack-Ansible.
Catatan
You can upgrade between sequential releases or between releases marked as SLURP.
Pengantar¶
Untuk upgrade di antara versi utama, repositori OpenStack-Ansible menyediakan playbooks dan skrip untuk upgrade suatu lingkungan. Skrip run-upgrade.sh` menjalankan setiap playbook upgrade dalam urutan yang benar, atau playbook dapat dijalankan secara individual jika perlu. Atau, seorang deployer dapat upgrade secara manual.
Untuk informasi lebih lanjut tentang proses pemutakhiran utama, lihat Memutakhirkan dengan menggunakan skrip dan Memutakhirkan secara manual.
Peringatan
Uji The upgrade is always under active development. ini pada lingkungan pengembangan terlebih dahulu.
Memutakhirkan dengan menggunakan skrip¶
The 2024.1 release series of OpenStack-Ansible contains the code for migrating from 2023.2 or 2023.1 to 2024.1.
Menjalankan skrip pemutakhiran¶
To upgrade from 2023.2 or 2023.1 to
2024.1 by using the upgrade script, perform the
following steps in the openstack-ansible directory:
Ubah direktori ke direktori root clone repositori:
# cd /opt/openstack-ansible
Jalankan perintah berikut:
# git checkout 29.1.0 # ./scripts/run-upgrade.sh
Untuk informasi lebih lanjut tentang langkah-langkah yang dilakukan oleh skrip, lihat Memutakhirkan secara manual.
Memutakhirkan secara manual¶
Upgrade secara manual berguna untuk membatasi perubahan dalam proses upgrade (misalnya, dalam deployments yang sangat besar dengan persyaratan SLA yang ketat), atau melakukan otomatisasi upgrade lain di luar yang disediakan oleh OpenStack-Ansible.
Langkah-langkah yang dijelaskan di sini cocok dengan yang dilakukan oleh skrip run-upgrade.sh. Anda dapat dengan aman menjalankan langkah-langkah ini beberapa kali.
Pemeriksaan preflight¶
Sebelum memulai dengan upgrade, lakukan pemeriksaan kesehatan preflight untuk memastikan lingkungan Anda stabil. Jika salah satu dari pemeriksaan itu gagal, pastikan bahwa masalah tersebut diselesaikan sebelum melanjutkan.
Lihat 2024.1 melepaskan¶
Pastikan kode OpenStack-Ansible Anda ada di 2024.1 terbaru rilis yang ditandai.
# git checkout 29.1.0
Mempersiapkan variabel shell¶
Tentukan variabel-variabel ini untuk mengurangi pengetikan saat menjalankan tugas pemutakhiran yang tersisa. Karena variabel lingkungan ini adalah pintasan (shortcut), langkah ini opsional. Jika Anda suka, Anda dapat mereferensikan file secara langsung selama pemutakhiran.
# cd /opt/openstack-ansible
# export MAIN_PATH="$(pwd)"
# export SCRIPTS_PATH="${MAIN_PATH}/scripts"
Cadangkan konfigurasi OpenStack-Ansible yang ada¶
Buat cadangan dari konfigurasi lingkungan:
# source_series_backup_file="/openstack/backup-openstack-ansible-2023.2.tar.gz"
# tar zcf ${source_series_backup_file} /etc/openstack_deploy /etc/ansible/ /usr/local/bin/openstack-ansible.rc
Bootstrap peran Ansible dan OSA yang baru¶
Untuk memastikan bahwa saat ini tidak ada yang menetapkan ANSIBLE_INVENTORY untuk mengganti lokasi inventaris default, kami membatalkan variabel lingkungan.
# unset ANSIBLE_INVENTORY
Bootstrap Ansible dilakukan lagi untuk memastikan bahwa semua dependensi peran OpenStack-Ansible sudah ada sebelum Anda menjalankan playbook dari pelepasan|current_release_formal_name|.
# ${SCRIPTS_PATH}/bootstrap-ansible.sh
Ubah ke direktori playbook¶
Ubah ke direktori playbook untuk menyederhanakan perintah CLI dari sini dalam prosedur, mengingat sebagian besar playbook yang dieksekusi ada di direktori ini.
# cd playbooks
Terapkan perubahan pada konfigurasi OSA¶
Jika ada perubahan nama variabel OSA atau perubahan lingkungan/inventaris, ada buku pedoman untuk menangani perubahan itu untuk memastikan kesinambungan layanan di lingkungan saat buku pedoman baru dijalankan. Playbook ini ditandai untuk memastikan bahwa setiap bagian dari itu dapat dieksekusi sendiri atau dilewati. Harap tinjau isi buku pedoman untuk informasi lebih lanjut.
# openstack-ansible "${SCRIPTS_PATH}/upgrade-utilities/deploy-config-changes.yml"
Catatan
With upgrade to 2024.1 (Caracal) release usage of RabbitMQ Quorum Queues is enabled by default. Migration to usage of Quorum Queues results in prolonged downtime for services during upgrade.
To reduce downtime you might want to set
oslomsg_rabbit_quorum_queues: false at this point and migrate to
Quorum Queues usage after OpenStack upgrade is done.
Please, check RabbitMQ maintenance for more information about switching between Quourum and HA Queues.
Upgrade host (tingkatkan host)¶
Sebelum memasang infrastruktur dan OpenStack, perbarui mesin host.
Peringatan
Usage of non-trusted certificates for RabbitMQ is not possible
due to requirements of newer amqp versions.
After that you can proceed with standard OpenStack upgrade steps:
# openstack-ansible setup-hosts.yml --limit '!galera_all:!rabbitmq_all' -e package_state=latest
Perintah ini sama mengatur host pada instalasi baru. Grup host galera_all dan rabbitmq_all dikecualikan untuk mencegah konfigurasi ulang dan memulai kembali container mana pun karena perlu diperbarui, tetapi tidak dimulai kembali.
Setelah selesai, upgrade grup host terakhir dengan flag untuk mencegah restart kontainer.
# openstack-ansible setup-hosts.yml -e 'lxc_container_allow_restarts=false' --limit 'galera_all:rabbitmq_all'
Upgrade infrastruktur¶
We can now go ahead with the upgrade of all the infrastructure components. To ensure that rabbitmq and mariadb are upgraded, we pass the appropriate flags.
# openstack-ansible setup-infrastructure.yml -e 'galera_upgrade=true' -e 'rabbitmq_upgrade=true' -e package_state=latest
Dengan lengkap ini, kita sekarang dapat me-restart kontainer mariadb satu per satu, memastikan bahwa masing-masing dimulai, merespons, dan disinkronkan dengan node lain di cluster sebelum melanjutkan ke langkah berikutnya. Langkah ini memungkinkan konfigurasi kontainer LXC yang Anda terapkan sebelumnya berlaku, memastikan bahwa kontainer diaktifkan kembali secara terkendali.
# openstack-ansible "${SCRIPTS_PATH}/upgrade-utilities/galera-cluster-rolling-restart.yml"
Memutakhirkan OpenStack¶
Kita sekarang dapat melanjutkan dengan upgrade semua komponen OpenStack.
# openstack-ansible setup-openstack.yml -e package_state=latest
Upgrade Ceph¶
With each OpenStack-Ansible version we define default Ceph client version
that will be installed on Glance/Cinder/Nova hosts and used by these services.
If you want to preserve the previous version of the ceph client during an
OpenStack-Ansible upgrade, you will need to override a variable
ceph_stable_release in your user_variables.yml
If Ceph has been deployed as part of an OpenStack-Ansible deployment using the roles maintained by the Ceph-Ansible project you will also need to upgrade the Ceph version. Each OpenStack-Ansible release is tested only with specific Ceph-Ansible release and Ceph upgrades are not checked in any Openstack-Ansible integration tests. So we do not test or guarantee an upgrade path for such deployments. In this case tests should be done in a lab environment before upgrading.
Peringatan
Ceph related playbooks are included as part of setup-infrastructure.yml
and setup-openstack.yml playbooks, so you should be cautious when
running them during OpenStack upgrades.
If you have upgrade_ceph_packages: true in your user variables or
provided -e upgrade_ceph_packages=true as argument and run
setup-infrastructure.yml this will result in Ceph package being upgraded
as well.
In order to upgrade Ceph in the deployment you will need to run:
# openstack-ansible /etc/ansible/roles/ceph-ansible/infrastructure-playbooks/rolling_update.yml
