アップグレード¶

アップグレードの計画¶

• 全体的に リリースノート を確認して、新機能、更新された機能、非推奨の機能について調べてください。バージョン間の非互換を確認してください。
• アップグレードによるユーザーへの影響を考慮してください。アップグレードプロセスは、ダッシュボードを含む、環境の管理機能を中断します。このアップグレードを正しく準備する場合、既存のインスタンス、ネットワーク、ストレージは通常通り動作し続けるべきです。しかしながら、インスタンスがネットワークの中断を経験するかもしれません。
• お使いの環境をアップグレードする方法を検討します。運用中のインスタンスがある状態でアップグレードを実行できます。しかし、これは非常に危険なアプローチです。アップグレードの実行中は、ライブマイグレーションを使用して、インスタンスを別のコンピュートノードに一時的に再配置することを考慮すべきでしょう。しかしながら、プロセス全体を通して、データベースの整合性を担保する必要があります。そうでなければ、お使いの環境が不安定になるでしょう。また、ユーザーに十分に注意を促すことを忘れてはいけません。バックアップを実行するために時間の猶予を与えることも必要です。
• このサービス設定ファイルから構造とオプションを適用して、既存の設定ファイルにマージすることを検討してください。ほとんどのサービスは、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+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 のバージョンロックを削除できます。

サービス固有のアップグレード手順¶

特定の OpenStack サービスのアップグレードに関する情報は、以下のアップグレードノートを参照してください。

• Networking サービス (neutron) のアップグレード
• Compute サービス (nova) のアップグレード
• Identity サービス (keystone) のアップグレード
• Block Storage サービス (cinder) のアップグレード
• Image サービス (glance) の無停止データベースアップグレード
• Image サービス (glance) のローリングアップグレード
• Bare Metal サービス (ironic) のアップグレード
• Object Storage サービス (swift) のアップグレード
• Telemetry サービス (ceilometer) のアップグレード

前提¶

• 確実に整合性のある状態にするために、アップグレード作業を始める前にいくつか環境のクリーンアップを実行します。例えば、削除後に完全削除されていないインスタンスにより、不確実な挙動を引き起こす可能性があります。

• 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
  

バックアップの実行¶

1. すべてのノードで設定ファイルを保存します。例:

   # 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
   

   注釈

   さまざまなサービスを処理するために、各ノードでこのサンプルスクリプトを修正できます。

2. 本番データの完全バックアップを取得します。Kilo 以降のリリースでは、データベースのダウングレードはサポートされません。バックアップからリストアすることが、以前のバージョンのデータベースに戻す唯一の方法です。

   # mysqldump -u root -p --opt --add-drop-database --all-databases > RELEASE_NAME-db-backup.sql
   

   注釈

   Installation Tutorials and Guides に記載されているように、SQL サーバーの設定の更新を考慮してください。

リポジトリーの管理¶

すべてのノード:

1. 旧リリースのパッケージのリポジトリーを削除します。
2. 新リリースのパッケージのリポジトリーを追加します。
3. リポジトリーデータベースを更新します。

各ノードにおけるパッケージのアップグレード¶

お使いの設定によっては、すべてのパッケージを更新することにより、OpenStack 環境の補助サービスを再起動または破壊するかもしれません。例えば、Block Storage ボリューム向けに TGT iSCSI フレームワークを使用していて、それの新しいパッケージがアップグレードに含まれる場合、パッケージマネージャーが TGT iSCSI サービスを再起動して、ボリュームへの接続性に影響を与えるかもしれません。

パッケージマネージャーがさまざまな設定ファイルの更新をプロンプトで確認する場合、変更を拒否します。パッケージマネージャーは、新しいバージョンの設定ファイルにサフィックスを追加します。これらのファイルの内容を確認して適用することを検討してください。

サービスの更新¶

各ノードにおいてサービスをアップグレードする場合、一般的には 1 つ以上の設定ファイルの変更、サービスの停止、データベーススキーマの同期、サービスの起動を行います。いくつかのサービスは、違う手順を必要とします。次のサービスに進む前に、各サービスの動作を検証することを推奨します。

サービスをアップグレードすべき順番、一般的なアップグレード手順との違いは、以下に示す通りです。

コントローラーノード

1. Identity サービス - データベースの同期前に期限切れのトークンを削除します。
2. Image サービス
3. Compute サービス。ネットワークコンポーネントも含む。
4. ネットワークサービス
5. Block Storage サービス
6. Dashboard - 一般的な環境では、 Dashboard を更新するのに必要な作業は Apache HTTP サービスの再起動のみです。
7. Orchestration サービス
8. Telemetry サービス - 一般的な環境では、 Telemetry サービスを更新するために、Apache HTTP サービスの再起動のみが必要となります。
9. Compute サービス - 設定ファイルを編集して、サービスを再起動します。
10. Networking サービス - 設定ファイルを編集して、サービスを再起動します。

ストレージノード

• Block Storage サービス - Block Storage サービスの更新は、サービスの再起動のみを必要とします。

コンピュートノード

• Networking サービス - 設定ファイルを編集して、サービスを再起動します。

最終手順¶

すべてのディストリビューションにおいて、アップグレードプロセスを完了するために、いくつかの最終作業を実行する必要があります。

1. コンピュートノードにおいて /etc/nova/nova.conf ファイルを変更することにより、DHCP タイムアウトを元の環境の値に減らして戻します。
2. すべての .ini ファイルを更新して、お使いの環境で OpenStack リリース向けに必要となるパスワードおよびパイプラインと一致させます。
3. 移行後、ユーザーは openstack image list と glance image-list から異なる結果を見ることになります。ユーザーが一覧コマンドにおいて同じイメージをきちんと見るために、 /etc/glance/policy.json と /etc/nova/policy.json ファイルを編集して、 "context_is_admin": "role:admin" を含めます。これは、プロジェクトのプライベートイメージへのアクセスを制限します。
4. お使いの環境が正常に動作することを検証します。そして、クラウドが再び通常どおり動作していることをユーザーに知らせます。