[ English | English (United Kingdom) | español | Deutsch | Indonesia | русский | français ]
Wichtige Upgrades¶
Dieses Handbuch enthält Informationen zum Aktualisierungsvorgang von Yoga zu Zed für OpenStack-Ansible.
Bemerkung
Sie können nur zwischen sequenziellen Releases upgraden.
Einführung¶
For upgrades between major versions, the OpenStack-Ansible repository provides
playbooks and scripts to upgrade an environment. The run-upgrade.sh
script runs each upgrade playbook in the correct order, or playbooks can be run
individually if necessary. Alternatively, a deployer can upgrade manually.
Weitere Informationen zum Hauptaktualisierungsprozess finden Sie unter Aktualisierung mit einem Script und Manuelle Aktualisierung.
Warnung
The upgrade is always under active development. Testen Sie dies zunächst in einer Entwicklungsumgebung.
Aktualisierung mit einem Script¶
Der Zed Release-Reihe von OpenStack-Ansible enthält den Code für die Migration von Yoga zu Zed.
Ausführen des Upgrade-Skripts¶
So aktualisieren Sie von Yoga zu Zed. Führen Sie mit dem Upgrade-Skript die folgenden Schritte im Verzeichnis openstack-ansible durch:
Wechseln Sie in das Stammverzeichnis des Repository-Klons:
# cd /opt/openstack-ansible
Führen Sie die folgenden Befehle aus:
# git checkout 26.5.2 # ./scripts/run-upgrade.sh
Für mehr Informationen über die Schritte, die das Script ausführt, schauen Sie Manuelle Aktualisierung.
Manuelle Aktualisierung¶
Manuelle Aktualisierungen sind nützlich, wenn die Änderungen des Aktualisierungsprozesses im Fokus stehen (z.B. in sehr grossen Bereitstellungen mit strikten SLA Anforderungen) oder andere durchgeführte Aktualisierungsautomatisierungen hinter OpenStack-Ansible.
Die hier aufgeführten Schritte stimmen mit denen überein, die das Skript `` run-upgrade.sh`` ausführt. Sie können diese Schritte mehrmals sicher ausführen.
Preflight Prüfung¶
Before starting with the upgrade, perform preflight health checks to ensure your environment is stable. If any of those checks fail, ensure that the issue is resolved before continuing.
Überprüfen Sie die Zed Freisetzung¶
Stellen Sie sicher, dass sich Ihr OpenStack-Ansible-Code auf latest Zed befindet markierte Version.
# git checkout 26.5.2
Bereiten Sie die Shell-Variablen vor¶
Definieren Sie diese Variablen, um beim Ausführen der verbleibenden Upgrade-Aufgaben die Eingabe zu reduzieren. Da es sich bei diesen Umgebungsvariablen um Verknüpfungen handelt, ist dieser Schritt optional. Wenn Sie möchten, können Sie während des Upgrades direkt auf die Dateien verweisen.
# cd /opt/openstack-ansible
# export MAIN_PATH="$(pwd)"
# export SCRIPTS_PATH="${MAIN_PATH}/scripts"
Backup der existierenden OpenStack-Ansible Konfiguration¶
Machen Sie ein Backup der Konfiguration der Umgebung:
# source_series_backup_file="/openstack/backup-openstack-ansible-yoga.tar.gz"
# tar zcf ${source_series_backup_file} /etc/openstack_deploy /etc/ansible/ /usr/local/bin/openstack-ansible.rc
Bootstrappen der neuen Ansible und OSA Rollen¶
To ensure that there is no currently set ANSIBLE_INVENTORY to override the default inventory location, we unset the environment variable.
# unset ANSIBLE_INVENTORY
Ansible erneut boostrappen, um sicherzustellen, dass alle OpenStack-Ansible-Rollenabhängigkeiten vorhanden sind, bevor Sie Playbooks von Zed ausführen.
# ${SCRIPTS_PATH}/bootstrap-ansible.sh
Wechseln Sie in das Verzeichnis der Playbooks¶
Change to the playbooks directory to simplify the CLI commands from here on in the procedure, given that most playbooks executed are in this directory.
# cd playbooks
Implement changes to OSA configuration¶
If there have been any OSA variable name changes or environment/inventory changes, there is a playbook to handle those changes to ensure service continuity in the environment when the new playbooks run. The playbook is tagged to ensure that any part of it can be executed on its own or skipped. Please review the contents of the playbook for more information.
# openstack-ansible "${SCRIPTS_PATH}/upgrade-utilities/deploy-config-changes.yml"
Ensure that you have defined all required variables for current Neutron plugin
# openstack-ansible "${SCRIPTS_PATH}/upgrade-utilities/define-neutron-plugin.yml"
Aktualisieren Sie Hosts¶
Aktualisieren Sie die Host-Computer, bevor Sie die Infrastruktur und OpenStack installieren.
Warnung
Usage of non-trusted certificates for RabbitMQ is not possible
due to requirements of newer amqp versions.
The SSH certificate authority must be updated for the upgraded release version. SSH certificates are used for nova live migration and keystone credential synchonrisation in the new release. This step ensures that the required CA is generated and available for other playbooks.
# openstack-ansible certificate-ssh-authority.yml
Once CA is generated, we can proceed with standard OpenStack upgrade steps:
# openstack-ansible setup-hosts.yml --limit '!galera_all:!rabbitmq_all' -e package_state=latest
This command is the same setting up hosts on a new installation. The
galera_all and rabbitmq_all host groups are excluded to prevent
reconfiguration and restarting of any of those containers as they need to
be updated, but not restarted.
Once that is complete, upgrade the final host groups with the flag to prevent container restarts.
# openstack-ansible setup-hosts.yml -e 'lxc_container_allow_restarts=false' --limit 'galera_all:rabbitmq_all'
Aktualisieren der 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. We also skip upgrading haproxy re-configuration at this step, since some services will become unavailable right after running haproxy role, which we want to avoid
# openstack-ansible setup-infrastructure.yml -e 'galera_upgrade=true' -e 'rabbitmq_upgrade=true' -e 'package_state=latest' --skip-tags haproxy-config
Mit diesem Abschluss können wir nun alle mariadb-Container einzeln nacheinander neu starten und sicherstellen, dass jeder Container gestartet wird, antwortet und mit den anderen Knoten im Cluster synchronisiert wird, bevor mit den nächsten Schritten fortgefahren wird. Durch diesen Schritt kann die zuvor angewendete LXC-Containerkonfiguration wirksam werden, um sicherzustellen, dass die Container kontrolliert neu gestartet werden.
# openstack-ansible "${SCRIPTS_PATH}/upgrade-utilities/galera-cluster-rolling-restart.yml"
Aktualisieren Sie OpenStack¶
Wir können jetzt weitermachen mit der Aktualisierung aller OpenStack Komponenten.
# openstack-ansible setup-openstack.yml -e package_state=latest
Run haproxy re-configuration¶
Now, once all services are being re-configured, we can run haproxy role to apply new configuration for the backends
# openstack-ansible haproxy-install.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.
Warnung
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
