Pemutakhiran besar¶

This guide provides information about the upgrade process from 2024.1 to 2024.2 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 Upgrading to master is not recommended. Master is under heavy development, and is not stable. ini pada lingkungan pengembangan terlebih dahulu.

Memutakhirkan dengan menggunakan skrip¶

The 2024.2 release series of OpenStack-Ansible contains the code for migrating from 2024.1 to 2024.2.

Menjalankan skrip pemutakhiran¶

To upgrade from 2024.1 to 2024.2 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 master
# ./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.2 melepaskan¶

Pastikan kode OpenStack-Ansible Anda ada di 2024.2 terbaru rilis yang ditandai.

# git checkout master

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-2024.1.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 openstack.osa.setup_hosts --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 openstack.osa.setup_hosts -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.

Peringatan

Please make sure you are running RabbitMQ version 3.13 or later before proceeding to this step. Upgrade of RabbitMQ to version 4.0 (default for 2024.2) from prior version will result in playbook failure.

At this point you can minorly upgrade RabbitMQ with the following command:

openstack-ansible openstack.osa.rabbitmq_server -e rabbitmq_upgrade=true -e rabbitmq_package_version=3.13.7-1

Also ensure that you have migrated from mirrored queues (HA queues) to Quorum queues before the upgrade, as mirrored queues are no longer supported after upgrade.

# openstack-ansible openstack.osa.setup_infrastructure -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 openstack.osa.setup_openstack -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 openstack.osa.setup_infrastructure and openstack.osa.setup_openstack 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

Pemutakhiran besar

Pemutakhiran besar¶

Pengantar¶

Memutakhirkan dengan menggunakan skrip¶

Menjalankan skrip pemutakhiran¶

Memutakhirkan secara manual¶

Pemeriksaan preflight¶

Lihat 2024.2 melepaskan¶

Mempersiapkan variabel shell¶

Cadangkan konfigurasi OpenStack-Ansible yang ada¶

Bootstrap peran Ansible dan OSA yang baru¶

Ubah ke direktori playbook¶

Terapkan perubahan pada konfigurasi OSA¶

Upgrade host (tingkatkan host)¶

Upgrade infrastruktur¶

Memutakhirkan OpenStack¶

Upgrade Ceph¶

openstack-ansible 30.0.0.0b2.dev31

Page Contents