はじめに

4月にUbuntu16.04とOpenStack Mitakaがリリースされました。
通常版のUbuntuのサポート期間は9ヶ月ですが、Ubuntu16.04はLTS版であり、サポート期間が5年もあります。また、Canonicalが提供するMitakaパッケージもサポート期間がUbuntu16.04向けには5年間と通常の1.5年よりも長期となっています。

そんなUbuntu16.04+Mitakaの組み合わせは世間的に大きな注目を集めており、今後広く導入されていくことが予想されます。

Mitakaのインストール

VMインスタンスを利用するにあたって中心的な役割を果たすコンポーネントと、それらを操作するダッシュボードという観点で以下6コンポーネントをインストールしました。4/26の段階でCloud Archiveをリポジトリに追加できなかったため、パッケージはUbuntuのリポジトリから取得しています。

ただし、インストールしないコンポーネントのための手順は実施していません。

サーバ構成はcontrollerノードとcomputeノードの仮想マシン2台構成で、storageノードはcontrollerノードに統合しました。いずれもOSはUbuntu Server16.04 64bitです。

参考にした公式ドキュメントはUbuntu14.04にMitakaを構築するためのものですが、Ubuntu16.04であっても基本的には問題なく作業が進みました。

一箇所だけ、controllerノードのデータベース設定には注意が必要です。Ubuntu16.04ではmariaDBの10.0系がインストールされます。mariaDBの10.0系は、Ubuntu14.04でインストールされる5.5系とはデフォルトの設定ファイル構成と設定値が異なっていました。公式ドキュメントのデータベース設定手順に従ったところ、Identityサービスのデータベースを展開する際にエラーが発生したので、データベース設定の手順を変更して対処しました。変更内容については脚注に記載します。

では、作成したインスタンスをhorizonで確認してみましょう。




しっかり稼動していますね。

構築してわかったOpenStack Libertyとの違い

Liberty はMitakaの1つ前のバージョンです。構築を通じて両者のどの様な違いに気付いたか、2点紹介します。

Liberty公式ドキュメント：http://docs.openstack.org/liberty/ja/install-guide-ubuntu/

nova_apiデータベースの追加

availability_zones機能の追加

こちらは機能の追加です。CLIから作成したルータを確認してみましょう。

availability_zonesという欄が増えていますね。図ではデフォルトのnovaが設定されています。

これまでneutronのネットワーク、ルータ等の仮想資源は特定のエージェントに紐付くようになっていましたが、Mitakaからは新しく追加されたavailability zone(AZ)という単位に紐付くようになりました。AZはneutronのエージェントの属性として定義されます。また、このAZは一つの仮想資源に複数設定することもできます。

このAZ機能の追加によって、Mitakaでは資源のスケジューリングが行いやすくなりました。
例えば、従来は2ロケーション各3エージェントの環境に冗長化=3(VRRP)のルータを作成すると、計6エージェントのうちいずれか3エージェントにルータが作成されました。つまり下図のように一方のロケーションにのみルータが作成される可能性があったのです。


マルチロケーションの良さを活かすためにはいずれかのルータに紐付いているエージェントを変更する必要があり、結構な手間がかかります。

Mitakaではルータ作成段階でそういった事態を避けることができます。まず、AZ対応スケジューラーを指定しておきます。

参考：http://docs.openstack.org/mitaka/ja/networking-guide/adv-config-availability-zone.html

その後、ロケーションごとに定めたAZをエージェントの属性に設定し、ルータ作成時にavailability_zone_hintsにそれらのAZを指定します。すると指定されたAZ間で分散された形でルータが作成されます。
下図はロケーションAのエージェントのAZをAZ-1、ロケーションBのエージェントのAZをAZ-2とし、冗長化=3(VRRP)のルータのavailability_zone_hintsにAZ-1, AZ-2を指定した場合の例です。AZを跨いでルータを作成できます。


資源作成直後から、マルチロケーションの良さが活きる配置にできますね。これであれば簡単に拠点単位での高可用性を実現できます。

他にはVMに近いロケーションにNW資源を作成させることで、通信経路の無駄を省くといった使い方も考えられますね。

おわりに

Mitakaリリース直後でもスムーズにインストール・動作確認が行え、OpenStackがかなり成熟してきたことを実感しました。

NTTテクノクロスは今後もUbuntu16.04+Mitakaをはじめ日々生まれる新しい機能やコンポーネントのノウハウを蓄積し、皆様の課題解決に貢献していきます。

今回の記事に関してご質問のある方や、OpenStackの導入や運用にご興味のある方は、ぜひ弊社にお問い合わせください。

OpenStack®はOpenStack, LLCの登録商標又は商標です。

脚注

/etc/mysql/conf.d/openstack.cnfの作成

次の内容を記載します。公式ドキュメントに記載されている設定項目を一部削除しました。

[mysqld]

default-storage-engine = innodb

innodb_file_per_table

/etc/mysql/mariadb.conf.d/50-server.cnfの編集

次の設定項目を編集します。その他の部分は編集不要です。

：

bind-address            = ＜controllerノードの管理ネットワークのIPアドレス＞

：

character-set-server  = utf8

collation-server      = utf8_general_ci

：

/etc/mysql/mariadb.conf.d/50-mysql-clients.cnfの編集

次の設定項目を編集します。その他の部分は編集不要です。

：

default-character-set = utf8

：

/etc/mysql/mariadb.conf.d/50-client.cnfの編集

次の設定項目を編集します。その他の部分は編集不要です。

：

default-character-set = utf8

：

データベースの再起動

# service mysql restart

以上です。

参考文献

Mitaka公式ドキュメント(構築)

Mitaka公式ドキュメント(AZ)

Liberty公式ドキュメント(構築)