[ English | Indonesia | Deutsch | 日本語 ]
アップグレード¶
Object Storage 以外は、OpenStack のあるバージョンから別のバージョンにアップグレードすることは非常に難しいことです。本章は運用観点でいくつかのガイドラインを提供します。これは、OpenStack 環境のアップグレードを実行する際の考慮すべきことです。
アップグレード前の考慮事項¶
アップグレードの計画¶
全体的に リリースノート を確認して、新機能、更新された機能、非推奨の機能について調べてください。バージョン間の非互換を確認してください。
アップグレードによるユーザーへの影響を考慮してください。アップグレードプロセスは、ダッシュボードを含む、環境の管理機能を中断します。このアップグレードを正しく準備する場合、既存のインスタンス、ネットワーク、ストレージは通常通り動作し続けるべきです。しかしながら、インスタンスがネットワークの中断を経験するかもしれません。
お使いの環境をアップグレードする方法を検討します。運用中のインスタンスがある状態でアップグレードを実行できます。しかし、これは非常に危険なアプローチです。アップグレードの実行中は、ライブマイグレーションを使用して、インスタンスを別のコンピュートノードに一時的に再配置することを考慮すべきでしょう。しかしながら、プロセス全体を通して、データベースの整合性を担保する必要があります。そうでなければ、お使いの環境が不安定になるでしょう。また、ユーザーに十分に注意を促すことを忘れてはいけません。バックアップを実行するために時間の猶予を与えることも必要です。
このサービス設定ファイルから構造とオプションを適用して、既存の設定ファイルにマージすることを検討してください。ほとんどのサービスは、OpenStack Configuration Reference に新しいオプション、更新されたオプション、非推奨になったオプションがあります。
すべてのシステムのメジャーアップグレードと同じく、いくつかの理由により、アップグレードに失敗する可能性があります。データベース、設定ファイル、パッケージなど、お使いの環境をロールバックできるようにしておくことにより、この状況に備えられます。お使いの環境をロールバックするためのプロセス例が 失敗したアップグレードのロールバック にあります。
アップグレード手順を作成し、本番環境と同じようなテスト環境を使用して、全体を評価します。
テスト環境の事前アップグレード¶
すべて中で最も大切なステップは事前のアップグレードテストです。新しいバージョンのリリース後すぐにアップグレードする場合、未発見のバグによってアップグレードがうまくいかないこともあるでしょう。管理者によっては、最初のアップデート版が出るまで待つことを選ぶ場合もあります。しかしながら、重要な環境の場合には、リリース版の開発やテストに参加することで、あなたのユースケースでのバグを確実に修正することもできるでしょう。
このガイドに記載されているような、理想的なアーキテクチャーに近いと思われる場合でも、各 OpenStack クラウドはそれぞれ異なります。そのため、お使いの環境の適切なクローンを使用して、お使いの環境のバージョン間でアップグレードをテストする必要があります。
しかしながら、言うまでもなく、本番環境と同じ大きさや同一のハードウェアを使用する必要がありません。アップグレードするクラウドのハードウェアや規模を考慮することは重要です。以下のヒントにより予測不能なコストを最小化する役に立つでしょう。
- 自身のクラウドの使用
OpenStack の次のバージョンをテストするための一番簡単な方法は、お使いのクラウドの中に新しい環境をセットアップすることです。これは奇妙に思えるかもしれません。とくに、動作中のコンピュートノードで使用される二重仮想化です。しかし、お使いの設定を非常に手軽にテストする確実な方法です。
- パブリッククラウドの利用
お使いのクラウドコントローラーの設定に関するスケーラビリティーの限界をテストするために、パブリッククラウドを使用することを考慮します。多くのパブリッククラウドは時間単位で課金されます。つまり、多くのノードを用いてテストしても、それほど費用がかかりません。
- 同じシステムに別のストレージエンドポイントの作成
クラウドに外部ストレージプラグインや共有ファイルシステムを使用している場合、2 つ目の共有やエンドポイントを作成することにより、正常に動作するかどうかをテストできます。これにより、ストレージに新しいバージョンを信頼させる前に、システムをテストできるようになります。
- ネットワークの監視
より小規模なテストにおいてさえも、過剰なネットワークパケットを探して、コンポーネント間の通信で何かとてつもなくおかしくなっていないかどうかを判断します。
テスト環境をセットアップする場合、いくつかの方法を使用できます。
お使いのプラットフォーム用の 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
conductor=X
scheduler=X
will keep the RPC version locked across the specified services to the
RPC version used in X. As all instances of a particular service are
upgraded to the newer version, the corresponding line can be removed
from 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 つ以上の設定ファイルの変更、サービスの停止、データベーススキーマの同期、サービスの起動を行います。いくつかのサービスは、違う手順を必要とします。次のサービスに進む前に、各サービスの動作を検証することを推奨します。
サービスをアップグレードすべき順番、一般的なアップグレード手順との違いは、以下に示す通りです。
コントローラーノード
Identity サービス - データベースの同期前に期限切れのトークンを削除します。
Image サービス
Compute サービス。ネットワークコンポーネントも含む。
ネットワークサービス
Block Storage サービス
Dashboard - 一般的な環境では、 Dashboard を更新するのに必要な作業は Apache HTTP サービスの再起動のみです。
Orchestration サービス
Telemetry サービス - 一般的な環境では、 Telemetry サービスを更新するために、Apache HTTP サービスの再起動のみが必要となります。
Compute サービス - 設定ファイルを編集して、サービスを再起動します。
Networking サービス - 設定ファイルを編集して、サービスを再起動します。
ストレージノード
Block Storage サービス - Block Storage サービスの更新は、サービスの再起動のみを必要とします。
コンピュートノード
Networking サービス - 設定ファイルを編集して、サービスを再起動します。
最終手順¶
すべてのディストリビューションにおいて、アップグレードプロセスを完了するために、いくつかの最終作業を実行する必要があります。
コンピュートノードにおいて
/etc/nova/nova.confファイルを変更することにより、DHCP タイムアウトを元の環境の値に減らして戻します。すべての
.iniファイルを更新して、お使いの環境で OpenStack リリース向けに必要となるパスワードおよびパイプラインと一致させます。移行後、ユーザーは openstack image list と glance image-list から異なる結果を見ることになります。ユーザーが一覧コマンドにおいて同じイメージをきちんと見るために、
/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` を実行して、環境をロールバックすることになった問題を解決するまで、偶然アップグレードすることを防ぎます。
