Object Storage 以外は、OpenStack のあるバージョンから別のバージョンにアップグレードすることは非常に難しいことです。本章は運用観点でいくつかのガイドラインを提供します。これは、OpenStack 環境のアップグレードを実行する際の考慮すべきことです。
すべて中で最も大切なステップは事前のアップグレードテストです。新しいバージョンのリリース後すぐにアップグレードする場合、未発見のバグによってアップグレードがうまくいかないこともあるでしょう。管理者によっては、最初のアップデート版が出るまで待つことを選ぶ場合もあります。しかしながら、重要な環境の場合には、リリース版の開発やテストに参加することで、あなたのユースケースでのバグを確実に修正することもできるでしょう。
このガイドに記載されているような、理想的なアーキテクチャーに近いと思われる場合でも、各 OpenStack クラウドはそれぞれ異なります。そのため、お使いの環境の適切なクローンを使用して、お使いの環境のバージョン間でアップグレードをテストする必要があります。
しかしながら、言うまでもなく、本番環境と同じ大きさや同一のハードウェアを使用する必要がありません。アップグレードするクラウドのハードウェアや規模を考慮することは重要です。以下のヒントにより予測不能なコストを最小化する役に立つでしょう。
テスト環境をセットアップする場合、いくつかの方法を使用できます。
お使いのプラットフォーム用の Installation Tutorials and Guides を使用して、完全な手動インストールを実行する。最終的な設定ファイルとインストールされたパッケージをレビューします。
変更したパッケージリポジトリー URL を用いて、自動化された設定インフラストラクチャーのクローンを作成する。
正常に動作するまで設定を変更する。
どのアプローチも有効です。あなたの経験に合うアプローチを使用してください。
アップグレード前テストシステムは、設定を動作させるために優れています。しかしながら、システムの歴史的な使用法やユーザー操作における違いにより、アップグレードの成否に影響することに注意することが重要です。
可能ならば、本番環境のデータベースのテーブルをダンプして、このデータを使用して開発環境においてアップグレードをテストすることを非常に強く推奨します。MySQL バグのいくつかは、新規インストールと旧バージョンから移行したバージョンのテーブルの間のわずかな違いによる、データベース移行中に取り扱われません。これは大規模な実データセットにおいてのみ影響するでしょう。本番環境の停止中に遭遇したくないでしょう。
人工的なスケールテストは、あくまである程度のものです。クラウドをアップグレードした後、クラウドのパフォーマンス観点で十分に注意する必要があります。
アップグレードレベルは、OpenStack Compute の Grizzly リリースで追加された機能です。これは、さまざまな Compute サービス間の RPC (メッセージキュー) 通信においてバージョンを固定できます。
この機能は、ライブアップグレードするということになると、パズルの重要な部品になります。異なるバージョンの OpenStack サービスが問題なく通信できるようにするために、既存の API バージョンと概念的に同じになります。
アップグレードレベルに関係なく、X+1 のバージョンの Compute サービスが X バージョンの RPC メッセージを受信して理解できますが、X+1 のバージョンの RPC メッセージのみを送信できます。例えば、 nova-conductor プロセスが X+1 へとアップグレードされている場合、コンダクターサービスは、X バージョンの nova-compute プロセスからのメッセージを理解できるようになります。しかし、それらのコンピュートサービスは、コンダクターサービスにより送信されたメッセージを理解できません。
運用者は、アップグレード中、RPC バージョンをロックして、バージョン不一致により引き起こされる中断なしでサービスのライブアップグレードできるよう、nova.conf
に設定オプションを追加できます。この設定オプションは、使いたければ RPC バージョン番号を指定できます。リリース名のエイリアスもサポートされます。例:
[upgrade_levels]
compute=X+1
conductor=X+1
scheduler=X+1
指定したサービスをまたがり、RPC バージョンを X+1 の RPC バージョンに固定します。特定のサービスのすべてのインスタンスがより新しいバージョンにアップグレードされた後、対応する行を nova.conf
から削除できます。
この機能を使用することにより、理想的には、 nova-compute においてアップグレードされる OpenStack の RPC バージョンを固定します。例えば、X+1 バージョンの nova-compute プロセスが、アップグレード完了まで、X バージョンの nova-conductor プロセスと一緒に動作しつづけることを保証するためです。 nova-compute プロセスのアップグレードが完了すると、運用者は nova-conductor のアップグレードに進み、 nova.conf
において nova-compute のバージョンロックを削除できます。
このセクションは、 Installation Tutorials and Guides にある、基本的な 2 ノードアーキテクチャーを参照しています。すべてのノードでは、サポートする Linux ディストリビューションで、最新のカーネルとカレントのリリースパッケージが実行されている必要があります。
特定の OpenStack サービスのアップグレードに関する情報は、以下のアップグレードノートを参照してください。
確実に整合性のある状態にするために、アップグレード作業を始める前にいくつか環境のクリーンアップを実行します。例えば、削除後に完全削除されていないインスタンスにより、不確実な挙動を引き起こす可能性があります。
OpenStack Networking サービス (neutron) を使用している環境では、リリースバージョンのデータベースを検証します。例:
# 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
すべてのノードで設定ファイルを保存します。例:
# 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
注釈
さまざまなサービスを処理するために、各ノードでこのサンプルスクリプトを修正できます。
本番データの完全バックアップを取得します。Kilo 以降のリリースでは、データベースのダウングレードはサポートされません。バックアップからリストアすることが、以前のバージョンのデータベースに戻す唯一の方法です。
# mysqldump -u root -p --opt --add-drop-database --all-databases > RELEASE_NAME-db-backup.sql
注釈
Installation Tutorials and Guides に記載されているように、SQL サーバーの設定の更新を考慮してください。
お使いの設定によっては、すべてのパッケージを更新することにより、OpenStack 環境の補助サービスを再起動または破壊するかもしれません。例えば、Block Storage ボリューム向けに TGT iSCSI フレームワークを使用していて、それの新しいパッケージがアップグレードに含まれる場合、パッケージマネージャーが TGT iSCSI サービスを再起動して、ボリュームへの接続性に影響を与えるかもしれません。
パッケージマネージャーがさまざまな設定ファイルの更新をプロンプトで確認する場合、変更を拒否します。パッケージマネージャーは、新しいバージョンの設定ファイルにサフィックスを追加します。これらのファイルの内容を確認して適用することを検討してください。
注釈
ipset
パッケージが、お使いのディストリビューションにおいて、依存関係でインストールされていない場合、それを明示的にインストールする必要があるかもしれません。
各ノードにおいてサービスをアップグレードする場合、一般的には 1 つ以上の設定ファイルの変更、サービスの停止、データベーススキーマの同期、サービスの起動を行います。いくつかのサービスは、違う手順を必要とします。次のサービスに進む前に、各サービスの動作を検証することを推奨します。
サービスをアップグレードすべき順番、一般的なアップグレード手順との違いは、以下に示す通りです。
コントローラーノード
ストレージノード
コンピュートノード
すべてのディストリビューションにおいて、アップグレードプロセスを完了するために、いくつかの最終作業を実行する必要があります。
/etc/nova/nova.conf
ファイルを変更することにより、DHCP タイムアウトを元の環境の値に減らして戻します。.ini
ファイルを更新して、お使いの環境で OpenStack リリース向けに必要となるパスワードおよびパイプラインと一致させます。/etc/glance/policy.json
と /etc/nova/policy.json
ファイルを編集して、 "context_is_admin": "role:admin"
を含めます。これは、プロジェクトのプライベートイメージへのアクセスを制限します。このセクションは、前のリリースの OpenStack にロールバックするためのガイドを提供します。すべてのディストリビューションは、同様の手順に従います。
警告
お使いの環境をロールバックすることは、バックアップ以降に追加されたデータが失われることになるので、最終手段にすべきです。
一般的なシナリオは、アップグレードの準備で本番の管理サービスを分解して、アップグレード手順の一部分を完了して、テスト中には遭遇しなかった 1 つ以上の問題に遭遇することです。環境を元の「万全な」状態にロールバックする必要があります。続けて、アップグレードプロセスを試行した後、新しいインスタンス、ネットワーク、ストレージボリュームなど、何も状態を変更していないことを確実にしてください。これらの新しいリソースはすべて、データベースがバックアップからリストアされた後、フリーズ状態になります。
この範囲内で、これらの手順を完了して、正常に環境をロールバックする必要があります。
リストアするために必要なバックアップがあることを確認すべきです。ディストリビューションは、ダウングレードよりもアップグレードをテストすることにかなりの労力をかける傾向があるため、ローリングバックアップグレードは扱いにくいプロセスです。失敗したダウングレードは、失敗したアップグレードよりトラブルシューティングと解決に非常により多くの労力を必要とします。失敗したアップグレードを前に進め続けるリスク、ロールバックするリスクを比較して重み付けすることだけができます。一般的に、かなり最後の選択肢としてロールバックを検討してください。
以下の手順は、Ubuntu 向けに記載しています。少なくとも 1 つの本番環境で動作しましたが、すべての環境で動作するとは限りません。
ロールバック方法
すべての OpenStack サービスを停止します。
アップグレード作業中に作成した、設定ディレクトリーのバックアップの中身を /etc/<service>
にコピーします。
アップグレードプロセス中に mysqldump コマンドを用いて作成した、 grizzly-db-backup.sql
バックアップファイルからデータベースを復元します。
# mysql -u root -p < RELEASE_NAME-db-backup.sql
OpenStack パッケージをダウングレードします。
警告
パッケージのダウングレードは、かなり最も複雑な手順です。ディストリビューション、システム管理全体に非常に依存します。
お使いの環境にインストールされている OpenStack パッケージを判断します。 dpkg --get-selections コマンドを使用します。OpenStack パッケージをフィルターします。再びフィルターして、明示的に deinstall
状態になっているパッケージを省略します。最終出力をファイルに保存します。例えば、以下のコマンドは、keystone、glance、nova、neutron、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
注釈
サーバーの種類に応じて、パケット一覧の内容や順番がこの例と異なるかもしれません。
apt-cache policy
コマンドを使用して、バージョンを戻すために利用できるパッケージのバージョンを確認できます。例:
# 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
注釈
あるリリースのリポジトリーを削除した場合、それらを再インストールして、 apt-get update を実行する必要があります。
コマンド出力の一覧により、パッケージの現在インストールされているバージョン、候補となる最新バージョン、各バージョンを含むリポジトリーにある全バージョンを把握できます。適切なリリースバージョン、この場合 2:14.0.1-0ubuntu1~cloud0
を探します。このパッケージ一覧から手動で探し当てる手順は、むしろ退屈で間違えやすいです。この手順を支援するために、以下のスクリプトを使用することを検討すべきです。例:
# 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
apt-get install コマンドに <package-name>=<version>
を指定して、各パッケージの特定のバージョンをインストールします。前の手順にあるスクリプトは、利便性のために package=version
のペアの一覧を作成しました。
# apt-get install `cat openstack-RELEASE_NAME-versions`
この手順は、ロールバックの手順を完了します。アップグレードするリリースのリポジトリーを作成し、 apt-get update` を実行して、環境をロールバックすることになった問題を解決するまで、偶然アップグレードすることを防ぎます。
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.