クラウド構築・管理ツールのOpenNebulaを開発しているOpenNebula.orgが、2016年6月15日にメジャーバージョンアップとなるOpenNebula 5.0 'Wizard'をリリースしました。続く6月27日にはメンテナンスリリースの5.0.1がリリースされ、細かなバグ修正と機能改善が行われています。ソースはGitHubで公開されており、OpenNebula.orgの公式リポジトリではCentOS 7(RHEL 7)向け、Debian 8向け、そしてUbuntu 14.04 LTSおよび16.04 LTS向けに、OpenNebula 5.0.1のバイナリパッケージが公開されています。
Ubuntu Weekly Recipeでは過去に第345回、346回で2回に分けてOpenNebulaを取り上げました。当時のバージョンは4.8で、バージョン5.0とは一部に差異がありますが、OpenNebulaとはなんぞやという場合はこちらを読んでいただければ雰囲気がつかめるのではないかと思います[1]。
今回のRecipeでは、OpenNebula 5.0について簡単に紹介した後、Ubuntuで構築した旧バージョンのOpenNebula環境を5.0にアップグレードしてみます。OpenNebulaは運用にかかるコストについても比較的よく考慮されており、新バージョンへのアップグレードが比較的容易に行える作りになっています。実運用中の本番環境であっても新しいバージョンに追従したい、という要望にも応えてくれるでしょう。
OpenNebula 5.0の(ごく簡単な)紹介
OpenNebula 5.0では基本的な構成は継承しつつ、大小さまざまな修正が加えられました。Ubuntu Weekly Recipe的には、今バージョンでUbuntu 16.04 LTS向けの対応が進み、最新のOpenNebulaをUbuntu 16.04 LTSに手軽にインストールできるようになった点も見逃せません。リリースノートに主要な新機能や変更がまとまっていますので、いくつか抜粋してみます。
- MarketPlaceの改良
仮想マシンイメージの外部Webサイトからのインポート機能を担ってきたMarketPlaceが改良され、データストア的な扱いとなりました。従来の参照先のOpenNebula AppMarketサイトは「OpenNebula Public」としてデフォルトで登録されており、加えてAmazon S3やローカルに構築したHTTPサーバーを参照先に登録することも可能になっています。OpenNebulaのWebインタフェースSunstone上では、4系列でのMarketPlaceの機能は「Storage」の項目下に移動し、参照先のサイトを設定する「MarketPlace」と、イメージのインポート等を行う「Apps」に分かれています(図2)。
- 仮想ルータのネイティブサポート
仮想マシンによるルータアプライアンスを用いてバーチャルネットワーク間のルーティングを提供する機能が実装されました。
- Sunstoneのラベルによるリソースグルーピング
Sunstone上の各種リソースにラベルを付け、グルーピングして表示できるようになりました。例えば稼働中の仮想マシンを、OSの種類や用途ごとにラベリングして抽出する、ということが可能になっています(図3、図4)。
- 仮想マシンライフサイクルのステート名の変更
仮想マシンライフサイクルのステート名が一部変更されています。これに伴い、CLIにて仮想マシンインスタンスを削除する際のコマンド名が、onevm shutdownからonevm terminateに変更になりました(図5)。4系列までのonevm shutdownというコマンド名は混乱を生じやすく、仮想マシンを一時的に停止するonevm poweroffコマンドと誤ってonevm shutdownを実行し、まだ使うつもりだった仮想マシンインスタンスが削除されてしまうという悲しい事故をよく目にしました。5.0でより実態に即した名称に変わったようです。
- ネットワークドライバの定義箇所の変更
ネットワークドライバの定義箇所が変更されています。4系列まではホストごとに使用するネットワークドライバを定義していました。5.0からは定義箇所がバーチャルネットワークごとに変更され、より柔軟なネットワーク構成が取れるようになっています。
その他、ハイパーバイザに関してはVMware vCenterへの対応強化の他、長らく標準で提供されてきたXenドライバがadd-on扱いとなり、標準ではインストールされなくなっています。
新機能や変更内容の全体像はリリースノートを参照してください。リリースノートを含むドキュメントページの構成も、5.0リリースにあわせて整理されています。
OpenNebula 5.0へのアップグレード
それでは、OpenNebula 4系列の最終リリースであるバージョン4.14で構築した環境を、5.0にアップグレードしてみます。
OpenNebulaの基本的な構成は、複数のサーバープロセスが稼働する「フロントエンド」マシンと、KVM等のハイパーバイザにより仮想マシンが稼働する「ホスト」マシン群から成ります[2]。
OpenNebulaのアップグレード作業は、大まかには以下の流れで行います。
- フロントエンド上のOpenNebulaサーバープロセス停止
- 設定ファイル類のバックアップ
- フロントエンド上でOpenNebulaパッケージをアップグレード、設定ファイルの修正
- データベースのスキーマとコンテンツを新バージョン用にマイグレート
- サーバープロセス起動
- フロントエンドからホストに新バージョンのドライバスクリプトを配布
上記の作業は、すべてフロントエンド上で行います。基本的には、個々のホストにログインして作業することはありません。ホストのセットアップの際にopennebula-nodeパッケージ等をインストールしますが、これらはoneadminアカウントの作成や設定ファイルの変更、依存パッケージのインストール等を行うもので、一度インストールすると以後はアップグレードしなくても問題ありません。
また、ホスト上で仮想マシンが稼働している状態でもアップグレードは可能です。稼働中の仮想マシンの停止や、ホストの再起動の必要はありません。
OpenNebulaに登録したイメージ、バーチャルネットワーク、データストア等のリソース情報は新しいバージョンに引き継がれますが、バージョン間でリソースの扱いに変更が入った場合は、アップグレード中やアップグレード後に新バージョン向けの設定が必要になることがあります。5.0ではネットワークドライバの定義箇所がホストリソースからバーチャルネットワークリソースに変更されており、このケースに該当します。その他、クラスターリソースについても微妙に大きな変更が入っているので注意が必要ですが、ここでは割愛します[3]。
今回アップグレードに取り組む環境は以下の内容で構築しています。
- OpenNebulaは4.14、5.0のいずれも、OpenNebula.orgのリポジトリのパッケージを使用します。
- OSはUbuntu 14.04 LTS serverを使用します[4]。
- データベースはSQLiteを使用します。
- OpenNebulaのFederationやHigh Availabilityといった高度な構成は組んでいません。
アップグレード手順はOpenNebula.orgのUpgradingのページに掲載されています。これに従い作業を進めます。
準備
まずはリリースノートを読みます。特に、Platform NotesとCompatibility Guideはしっかり目を通しましょう。
目を通したら実環境のアップグレード準備にとりかかります。
1. 仮想マシンインスタンスの状態確認
前述のとおり、仮想マシンが稼働した状態でもOpenNebulaのアップグレードは可能です。ただし、アップグレードの際は、仮想マシンインスタンスのステートが確定状態(running、suspended、stopped、done)にある必要があります。もしインスタンスのステートが遷移状態(prolog、migrate、epilog、save)にある場合は、確定状態に移行するのを待ってアップグレード作業にとりかかります。
2. リソース情報の取得
OpenNebula 4系までは、ネットワークドライバはホスト単位で設定していました。OpenNebula 5.0からは、ネットワークドライバはバーチャルネットワーク単位で設定するようになりました。この変更により、4系列の環境から5.0にアップグレードする際、構成によってはネットワークドライバの設定を尋ねられる場合があります。OpenNebulaサーバープロセスのonedを停止するとリソース情報が取得できなくなるので、アップグレードを始める前に既存のリソース情報を収集しておきます。
OpenNebulaサービス停止
OpenNebula関連サービスを全て停止します。
設定ファイルディレクトリのバックアップ
/etc/oneディレクトリをコピーしてバックアップします。etckeeper等で履歴管理しておくのもよいと思います。
OpenNebulaパッケージアップグレード
sources.listを編集し、OpenNebula.org公式リポジトリの参照先を4.14から5.0に切り替えます。ここでは/etc/apt/sources.list.d以下にopennebula.listファイルを作成してリポジトリ情報を定義しているものとします。
以下に変更します。OSのバージョンなどは適宜変更してください[5]。
パッケージインデックスファイルを更新し、インストール候補が5.0.1-1となっていることを確認します。
OpenNebula 5.0をインストール(アップグレード)します。
上記で依存関係にあるパッケージもあわせてアップデートされます。
/etc/oneディレクトリ以下の設定ファイルに手が入っている場合、現在のファイルを残すかどうか尋ねられます。OpenNebulaはバージョンアップによる機能追加等で設定ファイルに変更が入る場合が多く、旧バージョンのファイルは流用せず、新しいファイルに置き換えることを推奨しています。ここでは「パッケージメンテナのバージョンをインストールする」を選択します。
新バージョンの設定ファイルに置き換えた後、事前にバックアップした旧バージョンの設定ファイルとdiff等で比較して、旧バージョンで加えていた変更を新環境に反映させてください。
OpenNebulaが要求するRuby gemもバージョン間で異なるため、5.0にアップグレード後に改めてinstall_gemsスクリプトを実行します。
データベースアップグレード
OpenNebulaはデータベースにSQLiteまたはMySQLを使用します。データベースのスキーマやコンテンツはバージョン間で互換性がありません。OpenNebulaのアップグレードに伴い、データベースもマイグレートする必要があります。これにはonedb upgradeコマンドを使用します。onedb upgradeコマンドはまずデータベースをバックアップした後、マイグレートを行います。以下はデータベースにSQLiteを使用する場合の例です。
前述のとおり、今回のメジャーバージョンアップでは、ネットワークドライバを設定するリソースがホストからバーチャルネットワークに変更になりました。onedb upgradeコマンドでデータベース内の情報をマイグレートする際、既存のバーチャルネットワークリソースがどのネットワークドライバを使用するか、対話式に設定を求められる場合があります。「準備」の節でアップグレード前のリソース情報をnetworks.txt、hosts.txt、vms.txtに取得しましたので、この情報を元に適切なドライバを指定してください。
上記はpool2という名前のバーチャルネットワークが使用するネットワークドライバ(VN_MAD)として'dummy'ドライバを設定しています。バージョン5.0では以下6つのドライバ名からいずれかを設定します。
- 802.1Q
- dummy
- ebtables
- fw
- ovswitch
- vxlan
マイグレート完了後は、念のためoneadminアカウントでonedb fsckコマンドを実行し、エラーがないか確認しておきます。以下はデータベースにSQLiteを使用する場合の例です。
OpenNebulaサーバープロセス起動
これ以降の作業は、OpenNebulaサーバープロセスのうち、少なくともonedが起動している必要があります。新しいバージョンのonedを起動してみましょう。
とりあえず稼働中の仮想マシン情報が取得できるか確認してみます。
問題ないようですね。
ホスト用ドライバスクリプトのアップデート
フロントエンドから各ホストに新しいドライバスクリプトを配布します。これにはonehost syncコマンドを使用します。
これでOpenNebula 4.14から5.0へのアップグレードは完了です。他のOpenNebulaサーバープロセスを立ち上げましょう。
まとめ
OpenNebula 4.14から5.0へのアップグレード作業を追いかけてみました。比較的容易とは言いつつも、気を使う作業はやはり存在します。今回はデータベースのマイグレートでネットワークドライバ周りの変更をケアする必要がありましたが、アップグレードに支障が出ないようコマンドが用意されており、OpenNebula.orgが慎重に機能拡張や変更を加えている様子がうかがえます。
クラウドに限らず、構築した環境はできるだけ長く利用したいものです。運用中の環境を維持したまま新しいバージョンに追従できることも、OpenNebulaの魅力の一つではないかと筆者は考えています。