Cet article est un article du 3 décembre de OpenStack Advent Calendar 2015.
L'autre jour, j'ai immédiatement mis à niveau l'environnement OpenStack de Juno vers Liberty.
La raison pour laquelle j'ai fait cela était parce que lorsque j'ai vu une session à OpenStack Summit Tokyo l'autre jour où PayPal est passé de Folsom à Kilo, j'ai pensé que je pouvais le faire moi-même.
Non, en conséquence, j'ai pu mettre à niveau.
Eh bien, c'est pourquoi je pense que je suis devenu un pilier des gens, alors j'ai décidé d'écrire sur cette période ici.
Cliquez ici pour la session PayPal.
PayPal's Cloud Journey From Folsom to Kilo -- What We Learned in the Upgrade
| Component | Type |
|---|---|
| OS | Ubuntu 14.04 |
| OpenStack | Juno |
| Hypervisor | KVM |
| Neutron Driver | VLAN + OVS (L'agent L3 ne fonctionne pas) |
| Cinder | Je sais pas |
Je pense qu'il est courant de le faire dans l'ordre Keystone-> Glance-> Nova-> Neutron. Lors du Design Summit, certaines entreprises ont déclaré que les versions de chaque composant étaient différentes, donc la commande est juste pour référence, mais si vous souhaitez mettre à niveau tous les composants, cette commande est bonne.
À propos, la mise à niveau non-stop est absolument impossible, donc Akira Melon. C'est ce que les oncles des hackers du Design Summit ont dit.
Tu as raison.
. .. _ Conversation silencieuse _ .. .
Relâchez le lien vers le port 5000 de l'équilibreur de charge à l'avant de Keystone et arrêtez complètement la communication depuis l'extérieur. Il semble qu'il n'y ait aucun problème avec le port 35357 tel quel.
Tout d'abord, placez le référentiel de versions Liberty sur chaque serveur.
$ sudo echo "deb http://ubuntu-cloud.archive.canonical.com/ubuntu trusty-updates/liberty main" > /etc/apt/sources.list.d/cloudarchive-liberty.list
$ sudo apt-get update
Supprimez les jetons accumulés dans la base de données Keystone. De Liberty, Memcached est utilisé par défaut à des fins de jeton, j'ai donc décidé de l'utiliser. En d'autres termes, il est nécessaire de préparer un serveur pour Memcached à l'avance.
$ sudo su -s /bin/sh -c "keystone-manage token_flush" keystone
Après avoir effacé proprement le jeton DB, le prochain arrêt est Cron, qui fonctionnait régulièrement.
$ sudo crontab -e -u keystone
Supprimez la ligne suivante.
@hourly /usr/bin/keystone-manage token_flush > /var/log/keystone/keystone-tokenflush.log 2>&1
Soyez gracieux et arrêtez Keystone.
$ sudo service keystone stop
Connectez-vous au serveur de base de données et effectuez une sauvegarde de la base de données avec la commande suivante.
$ sudo mysqldump -uroot -p --opt --add-drop-database --single-transaction --master-data=2 keystone > liberty-keytone-db-backup.sql
$ sudo mysqldump -uroot -p --opt --add-drop-database --single-transaction --master-data=2 glance > liberty-glance-db-backup.sql
$ sudo mysqldump -uroot -p --opt --add-drop-database --single-transaction --master-data=2 nova > liberty-nova-db-backup.sql
$ sudo mysqldump -uroot -p --opt --add-drop-database --single-transaction --master-data=2 neutron > liberty-neutron-db-backup.sql
Mettez maintenant à niveau Keystone. Divers paramètres sont nouvellement ajoutés ou obsolètes, mais je ne peux pas écrire à leur sujet, veuillez donc utiliser Configuration Reference. Veuillez vous y référer. La mise à jour elle-même est aussi simple que ʻapt-get install XXXX puis réécrire keystone.conf` pour démarrer le processus. En gros, il n'y a aucun problème si vous suivez la Procédure d'installation.
En passant, si vous mettez l'option DEBUG dans conf, toutes les valeurs définies dans chaque élément de conf seront affichées dans le journal immédiatement après le démarrage du processus. Veuillez également signaler les éléments qui seront supprimés. Il s'agit d'un mécanisme commun à tous les composants, il convient donc de le rappeler. En parlant de cela, dans l'élément appelé ʻusername de Nova, ʻusername doit être aboli, donc j'ai arrêté de l'utiliser et il a été enregistré en utilisant ʻuser-name, donc si j'arrête de l'utiliser et utilise ʻuser-name, je vais lancer une erreur. Nova coincé. Est-ce Tundere?
L'histoire a mal tourné.
Après avoir placé keystone.conf, migrez le schéma de base de données jusqu'à la version Liberty avec la commande suivante. Depuis Kilo, Keystone fonctionne sur Apache, alors assurez-vous que le processus Keystone est arrêté à l'avance et démarrez Apache.
$ sudo service keystone stop
$ sudo service apache2 restart
$ sudo su -s /bin/sh -c "keystone-manage db_sync" keystone
S'il n'y a pas d'erreur, la mise à niveau Keystone est terminée.
Pour le moment, vérifions si la commande openstack peut être exécutée.
$ ADMIN_TOKEN=${keystone.admin répertorié dans conf_chaîne de jeton}
$ export OS_TOKEN=${ADMIN_TOKEN}
$ export OS_URL=http://${Adresse IP de tout serveur exécutant Keystone}:35357/v3
$ export OS_IDENTITY_API_VERSION=3
$ openstack service list
Comme pour Keystone, vérifiez la Configuration Reference et le guide d'installation officiel, et placez les fichiers glance-api.conf et glance-registry.conf qui correspondent à votre environnement.
Ensuite, faites la db sync de Glance.
$ sudo service glance-api restart
$ sudo service glance-registry restart
$ sudo su -s /bin/sh -c "glance-manage db_sync" glance
S'il n'y a pas d'erreur, la mise à niveau de Glance est terminée.
Le plus grand défi. Si vous parvenez à migrer la base de données de Nova vers Liberty, vous pouvez la mettre à niveau. Cependant, la réalité ne s'est pas si bien déroulée.
Donc, dans cette section, j'ai décidé de décrire la situation où la mise à niveau ne s'est pas bien déroulée.
Tout d'abord, j'ai mis à niveau nova-api vers Liberty sur le serveur exécutant nova-api.
$ sudo apt-get install nova-api python-novaclient
Après cela, faites db sync, et s'il n'y a pas de problème, mettez à niveau les autres composants tels quels et ce sera terminé (devrait être).
Alors, j'ai frappé la commande suivante,
$ sudo su -s /bin/sh -c "nova-manage db sync" nova
Erreur est survenue: (
Le contenu de l'erreur est
nova-manage db migrate_flavor_data avant de faire db syncEst.
Cependant, __En fait, la commande nova-manage de la version Liberty n'inclut pas cette option __. J'ai lu le code source et je l'ai recherché, mais ce n'était pas vraiment là. Je pensais que c'était stupide, mais à ce stade, le schéma DB lui-même avait été modifié à mi-chemin.
Dans cet état, ce qui suit a été fait.
La prochaine chose que je soupçonnais était la sortie de Kilo. J'ai donc fait ce qui suit:
nova-api pour la version Kilonova-manage db migrate_flavor_datanova-manage db syncNova-api, qui a été installé en ajoutant le référentiel de version Kilo, avait migrate_flavor_data comme option pour nova-manage. Kitakore! J'ai immédiatement lancé nova-manage db migrate_flavor_data. Ensuite, cela a réussi, j'ai donc décidé de le publier dans la version Kilo, puis dans la version Liberty, donc j'ai db sync jusqu'à la version Kilo.
Ensuite, j'ai eu une autre erreur: (
L'erreur était que le schéma de la table dans flavor était incorrect. Je pensais que c'était un mensonge, mais c'était sérieux. Pour résumer la nature et l'état de l'erreur, exécutez nova-manage db migrate_flavor_data après Kilo release db sync et avant Liberty release db sync.
En d'autres termes, la bonne réponse est la suivante.
nova-api pour la version Kilonova-manage db syncnova-manage db migrate_flavor_datanova-apinova-manage db syncÀ ce stade, le schéma de la base de données avait de nouveau été modifié à mi-chemin, je suis donc retourné à l'époque de la publication de Juno, et j'ai supprimé et restauré à nouveau la base de données. Après cela, j'ai essayé de revenir à nova-api au moment de la sortie de Juno, mais _ce fois apt s'est cassé .....
J'ai dû faire des allers-retours entre Juno, Kilo et Liberty tellement de fois que les packages dépendants étaient étranges et ne pouvaient pas être installés ou supprimés. Je n'ai pas pu m'en empêcher, j'ai donc utilisé la commande dpkg pour supprimer tous les packages dépendants qui dépendent de Nova pour les trois versions (Juno, Kilo, Liberty). Ensuite, apt a commencé à fonctionner, je devrais donc revenir à la version Juno et réessayer.
En fait, pendant que je faisais ça, la douce chanson du globe "Allons à l'école!" Que je faisais à la télé l'autre jour tournait dans mon cerveau.
"C'est stupide" "C'est vrai, c'est stupide"
C'est un chef d'oeuvre.
. .. _ Conversation silencieuse _ .. .
Sur la base de ce qui précède, je décrirai la procédure réussie.
Installez la version Kilo.
$ sudo echo "deb http://ubuntu-cloud.archive.canonical.com/ubuntu trusty-updates/kilo main" > /etc/apt/sources.list.d/cloudarchive-kilo.list
$ sudo apt-get update
$ sudo apt-get install nova-api python-novaclient
Migrez vers le schéma au moment de la publication de Kilo.
$ sudo service nova-api restart
$ sudo su -s /bin/sh -c "nova-manage db sync" nova
$ sudo su -s /bin/sh -c "nova-manage db migrate_flavor_data" nova
Puis passez à la libération Liberty.
$ sudo echo "deb http://ubuntu-cloud.archive.canonical.com/ubuntu trusty-updates/liberty main" > /etc/apt/sources.list.d/cloudarchive-liberty.list
$ sudo apt-get update
$ sudo apt-get install nova-api python-novaclient
Migrez vers le schéma au moment de la publication de Liberty.
$ sudo service nova-api restart
$ sudo su -s /bin/sh -c "nova-manage db sync" nova
Ceci termine la mise à niveau de nova-api et la migration de Nova DB.
À propos, cette procédure de migration de base de données a en fait été décrite en une seule ligne dans la note de publication de Kilo. Cependant, ce n'est toujours pas très gentil, donc je pense que j'en ai été accro même si je l'ai vérifié à l'avance.
Après la mise à jour de nova-api, mettez à niveau neutron-server.
Comme pour Keystone, consultez la Configuration Reference et le guide d'installation officiel, et placez neutron.conf et d'autres éléments qui conviennent à votre environnement. Notez qu'Open vSwitch a un fichier de configuration ml2 distinct.
Ensuite, faites db sync de Neutron.
$ sudo service neutron-server restart
$ sudo su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron
S'il n'y a pas d'erreur, la base de données de Neutron a été migrée vers le schéma au moment de la publication de Liberty.
Une fois que vous avez fait cela, mettez à niveau tous les packages restants. À partir de maintenant, il ne devrait pas y avoir de problème particulier (devrait). Ce qu'il faut mettre à niveau et comment mettre à niveau dépend de chaque environnement, je ne le décrirai donc pas ici.
Associez un vrai serveur au port 5000 de l'équilibreur de charge en façade de Keystone.
Horizon n'a pas d'importance si la version est incohérente avec d'autres composants, il est donc possible de mettre à niveau à chaque fois qu'OpenStack est publié.
Cependant, en ce qui concerne la version Liberty, __, ou le package deb de la version Liberty, la mise à niveau échoue.
Aucun détail n'est connu pour expliquer pourquoi cela n'a pas fonctionné. Pour le moment, j'ai décidé d'écrire ce qui s'était passé. Je suis désolé.
Cette fois, j'ai rencontré un événement où le package deb se comportait différemment lors d'une nouvelle installation et d'une mise à niveau. Normalement (probablement) ce n'est pas le cas, mais en ce qui concerne la version Liberty du package deb d'Horizon, elle se comporte différemment.
Sur un serveur Horizon qui fonctionnait dans la version Juno, si j'ai mis à niveau la version d'Horizon avec ʻapt-get upgrade ou ʻapt-get install openstack-dashboard, le CSS ne s'est pas chargé et Horizon n'a rien fait vers 2000 Il sera conçu comme une simple page Web.
Horizon avait également plus de composants et était en panne, alors j'ai pensé un instant que j'avais changé le design en disant Simple is Best, mais ce n'était pas du tout le cas. Peu importe à quel point cela va à l'encontre du temps.
. .. _ Conversation silencieuse _ .. .
Je me suis demandé s'il y avait un problème avec le processus de mise à niveau pour le moment, j'ai donc ajouté la ligne deb-src de la version Liberty au référentiel pour le découvrir et j'ai laissé tomber le paquet deb de openstack-dashboard.
$ sudo echo "deb-src http://ubuntu-cloud.archive.canonical.com/ubuntu trusty-updates/liberty main" >> /etc/apt/sources.list.d/cloudarchive-liberty.list
$ sudo apt-get update
$ sudo apt-get source openstack-dashboard
$ tar zxvf horizon_8.0.0-0ubuntu2~cloud0.debian.tar.gz
$ cd debian
Quand j'ai ouvert README.source, ce qui suit a été immédiatement écrit.
During the Juno/14.10 development cycle, use of xstatic packages was introduced
so that CSS, JS and other static assets did not have to be embedded in the
horizon source tree.
Suspect, très suspect.
Au fait, lorsque je retourne à la version Icehouse et que je laisse tomber la source, cette fois, ce qui suit est écrit dans le fichier README.compression.
Until this can be scripted and integrated into package build, updating the
pre-compressed static CSS and JS requires a some manual steps:
sudo apt-get install python-lesscpy python-openstack-auth python-compressor
quilt pop top
./debian/rules refresh-static-assets
HM.
Si vous lisez correctement le fichier rules, vous en trouverez la cause.
Mais j'étais complètement épuisé à ce stade.
La seule chose que je sais, c'est qu'une fois que vous supprimez tous les packages de la version Juno Horizon (y compris Django) et réinsérez les packages de la version Liberty, cela fonctionne très bien. Cet événement ne se produit pas lors du passage de Juno à Kilo. Cela ne se produit que lorsque vous passez de Juno à Liberty ou de Kilo à Liberty.
Donc, si quelqu'un connaît les détails, faites-le moi savoir;)
De plus, si vous êtes dans Canonical, veuillez faire quelque chose à propos de ce paquet deb :-(
Ceci termine la mise à niveau de l'environnement OpenStack. Bien sûr, si je faisais ce genre de travail manuellement, j'aurais éventuellement une inflammation de la gaine ténale __. Si vous n'aimez pas cela, vous devriez utiliser Chef, Puppet, Ansible, etc. peut être.
Je vous remercie pour votre travail acharné:-)
C'est l'histoire de "neutron-dhcp-agent". Connaissez-vous la RFC3442? Je ne savais pas jusqu'à récemment (désolé). Fondamentalement, la distribution des adresses et des routes reposera sur DHCP. Par conséquent, un mécanisme a été introduit pour étendre les spécifications DHCP et distribuer une table de routage statique en même temps lors de l'attribution d'une adresse IP. C'est la "route statique sans classe" (RFC3442).
Il semble que l'implémentation RFC3442 était prise en charge au moment de la publication de Juno, mais apparemment elle ne fonctionnait pas correctement. Il y avait un correctif de bogue au moment de la sortie de Kilo, et cela fonctionnait bien avec la version Liberty.
Ce qui n'a pas fonctionné, c'est que cette implémentation a si bien fonctionné qu'il s'est avéré que les sous-réseaux du réseau externe que j'utilisais étaient mal configurés. Je ne mentionnerai pas comment j'ai fait une erreur, mais une chose que je peux dire, c'est que c'était difficile.
En ce qui concerne le sous-réseau, il a été constaté que la modification du CIDR du réseau résoudrait l'événement, mais il a également été constaté que le CIDR ne pouvait pas être modifié à partir de l'API Neutron. Je ne pouvais pas m'en empêcher, alors je l'ai résolu en prenant le dernier recours en exécutant l'instruction UPDATE directement sur la table des sous-systèmes de la base de données Neutron (hey).
Au moment où la mise à niveau a été effectuée dans l'environnement de production, une nouvelle construction Liberty avec la même configuration que la production a été effectuée une fois, et un environnement de vérification avec la même configuration que Juno a été créé à l'avance, et un test de mise à niveau à partir de là a été effectué une fois. À propos, cette histoire est une histoire qui s'est produite dans l'environnement de vérification. Grâce à cela, j'ai pu évoluer en douceur dans l'environnement de production.
Chaque version d'OpenStack atteindra EOL environ 14 mois après sa sortie. En d'autres termes, Bugfix sera rétroporté pendant environ 14 mois après sa sortie, ce qui peut rendre le thé boueux. Vous pouvez également mettre à niveau uniquement Keystone pour chaque liaison de version et pour les autres composants, définir correctement Region et créer un petit cluster OpenStack. Naturellement, il est nécessaire de définir l'EOL du cluster OpenStack construit lui-même.
Il existe également de nombreux problèmes qui ne sont remarqués qu'après la mise à niveau. C'est une bonne idée de vérifier à l'avance le Launchpad pour les bogues et les problèmes connus et de les utiliser comme critères pour décider de la mise à niveau ou non. Cependant, en ce qui concerne la mise à niveau peu de temps après la sortie, ce n'est qu'un pilier, et parfois les bogues ne sont pas enregistrés dans Launchpad en premier lieu.
Au fait, c'est aujourd'hui mon anniversaire.
Recommended Posts