2016年10月14日（JST）にMirantis OpenStack 9.1 がリリースされました。
本稿では、Mirantis OpenStack 9.1 のリリースノートを確認し、何が更新されたか・実際に動かしてみてわかったことを投稿したものです。
Mirantis OpenStack 9.1 - What's NEW !?：
https://docs.mirantis.com/openstack/fuel/fuel-9.1/release-notes/new-features.html
この投稿の目次を上記のWhat's NEWの目次に合わせて紹介してみます。
MOS9.0からMOS9.1にアップデートを実際にやってみた際の投稿は、下記を参照してください。
http://qiita.com/MakitaTatsuro/items/3c45676c983b8c92f59a
What's New overview
1. Mirantis OpenStack アップデート手順
-
FuelSlaveノードを自動アップデート
下記のサイトで紹介したが、確かにUpdate実行コマンドはひとつで自動的に全FuelSlaveノード（OpenStack環境）がアップデートされました。
http://qiita.com/MakitaTatsuro/items/3c45676c983b8c92f59a -
OpenStackソースコードをカスタマイズしていた場合に検知する機能
CudetというパッケージをFuelMasterにインストールすることで、アップデートを実行する前に、FuelSlave上にデプロイ済みのOpenStackのソースコードと、OpenStack本家が公開しているGA版のOpenStackのソースコードを比較して、差分を検出できるようになっています。
それでは実際に試してみます。
下記のような感じでソースコードを変更してみます。
それではCudetを実行してみましょう。
WARNINGがでています。ちょっとGoogleで検索すると下記のバグっぽいです。
https://bugs.launchpad.net/fuel/+bug/1622623
マイルストーンが「Fuel for OpenStack 9.2」で示されているので、絶賛対処中のようです。
なので、この機能はとりあえず、保留にしておきます。(2016.10.20時点) -
コンフィグファイルをカスタマイズしていた場合に検知する機能
→これもソースコード同様に、PuppetのNoopランを利用して、コンフィグファイルの特定の変更点を検出できるようになっています。
試しに、特定のコンフィグファイルを変更して動作確認してみます。
変更したファイルは下記のnova.confです。簡単にデバックモードをONにしました。
それではマニュアルどおりのコマンドで確認してみましょう。
OpenStackノードに出力されたYamlファイルをみてみます。
実行時間に出力されたファイルがないです。
マニュアルを調べたのですが、使い方が間違っているのか、この先は不明・・・でした。
（わかり次第、追記します。）
2. FuelMasterノードのバックアップとリストア
fuel-octaneを利用することで、FuelMasterのバックアップとリストアを自動で行うことができます。
下記のサイトでバックアップを試しましたが、2.5GB以上の空きディスクがあればバックアップすることが可能でした。
http://qiita.com/MakitaTatsuro/items/3c45676c983b8c92f59a
※バックアップ後はバックアップファイルをUSBなどに退避させることをお忘れなく。
では、リストアを試してみます。
Fuel9.0をインストールしたのち、9.1にUpdateしたFuelMasterのバックアップ資材で9.1にリストアしてみます。
リストアのマニュアルはこちら。
http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-install-guide/upgrade/restore-fuel.html#restore-fuel
-
ISOからMOS9.0をインストール
仮想のマシン構成（CPU,MEMORY,Network数,IPアドレスなど）はバックアップ時と同じでインストールすること -
今回は/varにバックアップファイルをコピーしておく。
- octaneインストール（バックアップ・リストアツール）
yum install fuel-octane
- バックアップアーカイブのリストア
cd /var
octane fuel-restore --from <base-archive-name>.tar.gz --admin-password <admin-password>
admin-passwordは、fuelmenuで設定したFUELダッシュボードにアクセスするためのログインユーザ（admin）のパスワードを指定する。デフォルトだとadminです。
このパスワードを間違えると401 Keystoneの認証エラーによってリストアに失敗するのでご注意ください。
実行ログ：
上記のように「Finish restore puppet apply tasks」と表示されていればリストア成功。
- バックアップイメージ・その他のデータのリストア
octane fuel-repo-restore --from <repo-archive-name>.tar.gz
マニュアルには--admin-password <admin-password>を付けるような書きっぷりになっていますが、この引数は指定できせんでした。（そんなオプション無い！といった感じで弾かれます）
リストアできました。
Fuelダッシュボードにアクセスして
・Nodeが認識されているか。
・Environmentが変わってないか。
を確認してみましょう。
ノードが認識されてEnvironmentもバックアップしたものが設定されていますね。
あれ？なぜかDeployが自動で行われているようです。
マニュアルに注意書きがあるのかな？と思って確認したところ、とくにそんな説明ないですね。
fuelコマンドでtask状況を確認してみます。
せんぶ100％で再デプロイは動いてない模様。
ダッシュボードのEnbironmentだけは、リフレッシュできていないようですね。
とりあえず、今回の手順まででリストアできているとしたいと思います。
3. Fuel Dashbordに新しいWebUIが追加
- workflows管理画面
自分で作ったワークフローでデプロイが可能になるそうです。例えば、Fuelプラグインのネットワーク検証タスクを有効にしたり、OpenStackノードのデフォルトイメージを登録するためのHTTPプロトコルを変更（おそらくHTTPSなどに変更）、などなど。
つまり、Fuelでデプロイ後に特定の変更を加えている場合、このワークフローをテキストで管理（JSONまたはYAML）でき、ワークフローでいくらかインストールが楽になるということでしょうか。
WebUIのイメージ：
デフォルトが初めに登録されているので、JSON形式のファイルか、YAML形式のファイルをダウンロードして、自分でカスタマイズしてアップロードすることで利用することができるようになるみたい。
2. FuelSlaveNodeのデプロイ詳細確認画面
履歴画面が追加となりました。
ノード毎にデプロイをいつ、何を行ったが時系列でみることができます。
画面の情報からしてデプロイ時のastuteログファイルから情報を可視化したような感じですね。
ドライランを実行した場合も表示されているようです。
いつ、どのノードにデプロイを実行したの？と聞かれてもこれですぐに正確に答えることができますね。 :)
4. Fuel CLI バージョン統合
Fuel CLIには、fuelとfuel2の2つのコマンドが存在していたのですが、現時点で完全に機能網羅されているコマンドはfuel2です。
fuelコマンドが今後のバージョンアップで使われなくなります。
5. Fuel Plugin の拡張
- Yumリポジトリにプラグインが格納
Fuelプラグインは今まで、MirantisのWebからダウンロードしてインストールコマンドを実行していましたが、これからはyumリポジトリからダウンロード可能になりました。
インストールコマンド：yum install <PLUGIN_NAME>
アップデートコマンド：yum update <PLUGIN_NAME>
お～これで1コマンドでプラグインがインストールできるようになったわけだ！
どんどん便利になりますね。
2. 実行されたEnvironment上でプラグインをデプロイ
すでにデプロイ済みのEnvironmentに対してもプラグインのアップデートをかけることで、環境に適用するための準備をすることができるようです。
手順：
１．プラグインをアップデート
yum update <FUEL_PLUGIN_NAME>
２．プラグインを登録（たぶんこれのことを言ってる）
fuel plugins --sync
3. プラグインフレームワークを介してFuelリリースを定義
FuelプラグインとしてFuelリリースを表現する能力が導入されました。
新しい機能は、定義、維持、カスタマイズされたOpenStackにさまざまなフレーバーを展開することを可能にします。
たとえば、Fuel9.1mitaka（Mirantis OpenStack 9.1）を使って、OpenStackのKiloをリリースすることができます。
または、特定のCephだけリリースするように指定してスタンドアローンなCephEnvironmentをデプロイすることができます。
これについては、先日2016.10.24-28でBalcelona OpenStack Summit でデモンストレーションしていたので、そちらを見ていただくとわかりやすいかと思います。
MirantisOpenStack Balcelona Summit:
Mirantis- Evolve or Die- Enterprise Ready OpenStack Upgrades with Kubernetes
6. データ駆動型のタスクグラフ（for Basic Environment Action）
ノードデプロイタスクグラフに加えて、環境に基本的なアクションのためのタスクグラフを実行する機能が導入されました。
http://docs.openstack.org/developer/fuel-docs/userdocs/fuel-user-guide/configure-environment/workflows.html
ざっとみたところ、データ駆動型とは、JSONまたはYAMLで定義されたファイルでデプロイ構成をお好きに変更できるぞということみたいですね。
tasks.yaml、deployment_tasks.yamlなどを自分で追加、スキップタスク、タスクをグループ化してロール（権限）まで付与することを管理できるようにしたようです。
つまり、YAMLで定義することでデプロイ構成を柔軟に対応できるようにしたということですね。
これを管理して理解するためには、タスクの全体像を理解するとこから始める必要がありそうです。
7. VMware vCenter サーバ証明書の検証
OpenStack ComputeサービスのためのVMware vCenterのサーバ証明書を使って認証局を特定する機能を追加しました。
Fuelのサッシュボードから検証することが可能になりました。
チェックボックスで検証の有無を切り替えができます。デプロイを高速化したい場合は、チェックボックスをオフにすると良いです。
self-signed certificate（自己証明書）を使っている場合は、CAファイル入力欄でCA certificateをアップロードします。また、「Bypass vCenter certificate verification」のチェックを外したままにしましょう。
VMwareの既存のCAを使ってデプロイする場合、GeoTrustは、空のCAファイルのフィールドを残し、バイパスのvCenter証明書の検証チェックを外しましょう。
こちらの機能については、VMwareプラグイン( DVS/NSX )をインストールして、Environment作成時にvCenterをチェックして作成しないとVMwareタブが表示されないようです。
VMwareと連携をお考えの方は、この機能を今後使うシーンが出てくるでしょう。
以前、私がVMwareとOpenStackを連携したときの投稿がありますので、ご参考ください。
第1回 Mirantis OpenStack と VMware との連携実現！（Qiita）：
http://qiita.com/MakitaTatsuro/items/6812bbaa0d7c82654374
8. SSH ブルートフォースアタック対策
Fuelをインストールする際に、アクセス元のIPアドレス見てアクセス拒否できる機能が備わっていましたが、それに加えてブルートフォースアタック対策の機能が拡充されました。ブルートフォースアタックとは、認証が成功するまでパスワードを網羅的に認証を試みてくるDos攻撃に類するアタックですね。
BluePrintを確認したのですが、どうもこれは0.0.0.0/0の場合（SSHのアクセス元をどこからでも許可する）にした場合に、FuelSlaveノードのIptablesにオプションが設定されるようです。
現リリースでは、Restrict SSH access on networkに0.0.0.0/0の場合のみ、設定される実装となっており、リリースの手順書には、WEBUIのチェックボックスで有効にできると説明がありますが、この実装はまだできていないように見えます。
Implemented SSH Brute Force Protection:
https://docs.mirantis.com/openstack/fuel/fuel-9.1/release-notes/new-features/brute-force.html
では、実際に設定を確認してみましょう。
ダッシュボードにログインしてみます。
SSH に関するチェックボックスがないですね。
この件をコミュニティに問い合わせたところ、10.0に取り込まれたようで、9.1ではリリースされていなかったようです。
確かに、上記のパッチがマージされたバージョンは10.0ですね。
私から9.1のリリースノートから削除するようにバグ票（ドキュメントバグとして）を起票しておきました。
https://bugs.launchpad.net/fuel/+bug/1637954
続けて、次のリリース機能を確認してみましょう。
9. 診断スナップショットの作成（Creation of targeted diagnostic snapshots with Timmy）
概要：
簡単に言うと、ログ収集機能ですね。これを使って集めた情報をMirantisのサポートに問い合わせたりすることができます。
Fuelは、OpenStackのトラブルシューティングを簡素化するために、OpenStackの診断スナップショット（ログ収集物）を作成することができます。
WebUIまたはCLIを使用してTimmyがスナップショットを生成します。
・起動中のノードからログ情報を収集します。
・情報を記録する時間枠を指定します。
・指定したサービスのログを取得します。
・指定したフォルダー、フォルダー一覧からログ情報を取得します。
使い方：
timmy --logs --days <NUM>
--daysを指定しない場合、最近の30日間のログを収集します。
特定のノードを指定する場合：
timmy --env <ENV_ID> --id <NODE_ID>
特定のノードのロールを指定する場合：
timmy --role <ROLE_NAME>
いづれもgeneral.tar.gzという名前でスナップショットが生成されます。
しかし、ファイル名を指定することも可能です。
スナップショットのアーカイブ名を指定する場合：
timmy --dest-file <FILE_NAME>
それでは使ってみましょう。
私が持っているEnvironmentは、2ノード構成なので、
2台のノードから3日分のログを取得してみます。
[root@fuel ~]# fuel env
id | status | name | release_id
---+-------------+------------------+-----------
1 | operational | Test Environment | 2
[root@fuel ~]# timmy --env 1 --days 3
Initializing node data: done
Executing commands and scripts: done
Collecting files and filelists: done
Creating outputs and files archive: done
Run complete. Node information:
node-id env ip mac os roles online accessible status name release fqdn
0 0 127.0.0.1 n/a centos fuel True True ready fuel 9.0 n/a
1 1 192.168.114.3 00:0c:29:1e:a4:6c ubuntu controller True True deploying Untitled (a4:6c) 9.0 node-1.domain.tld
2 1 192.168.114.2 00:0c:29:d9:d1:52 ubuntu compute True True deploying Untitled (d1:52) 9.0 node-2.domain.tld
Outputs and/or files available in "/tmp/timmy/info".
Archives available in "/tmp/timmy/archives".
[root@fuel ~]#
所要時間は、30秒程度でした。出力されたアーカイブを確認してみましょう。
/tmp/timmy/archives/general.tar.gz・・・「/tmp/timmy/info」をtar.gzに圧縮したファイルでした。
/tmp/timmy/info/files・・・コンフィグファイルが格納されていました。
/tmp/timmy/info/scripts・・・「nova list」といったCLIを実行した結果がテキストで格納されていました。
あれ？ログファイルどこ？と思ったので、「--dest-file」オプションを付けて実行してみます。
[root@fuel archives]# timmy --env 1 --days 3 --dest-file /tmp/timmy/archives/log_archive.tar.gz
Initializing node data: done
Executing commands and scripts: done
Collecting files and filelists: done
Creating outputs and files archive: done
Run complete. Node information:
node-id env ip mac os roles online accessible status name release fqdn
0 0 127.0.0.1 n/a centos fuel True True ready fuel 9.0 n/a
1 1 192.168.114.3 00:0c:29:1e:a4:6c ubuntu controller True True deploying Untitled (a4:6c) 9.0 node-1.domain.tld
2 1 192.168.114.2 00:0c:29:d9:d1:52 ubuntu compute True True deploying Untitled (d1:52) 9.0 node-2.domain.tld
Outputs and/or files available in "/tmp/timmy/info".
Archives available in "/tmp/timmy/archives".
[root@fuel archives]#
[root@fuel archives]# ls -l
total 7548
-rw-r--r--. 1 root root 3856137 Nov 1 06:35 general.tar.gz
-rw-r--r--. 1 root root 3860424 Nov 1 07:48 log_archive.tar.gz
[root@fuel archives]#
log_archive.tar.gzを展開して中身を確認してみしたが、general.tar.gzと同じファイルでした。
timmyコマンドのヘルプを参照したところ、デフォルトではログは収集対象に含まれないらしい。
「-l」または「--logs」オプションをつければいいらしい。
これはポイントですね。
試してみます。
[root@fuel archives]# timmy --env 1 --days 3 --dest-file /tmp/timmy/archives/log_archive.tar.gz --logs
Initializing node data: done
Calculating logs size: done
Total logs size to collect before compression: 1131MB.
Compressed logs will take less space.
Log collection period: 3 days.
Checking free space: done
Executing commands and scripts: done
Collecting files and filelists: done
Creating outputs and files archive: done
Collecting and packing logs: done
Run complete. Node information:
node-id env ip mac os roles online accessible status name release fqdn
0 0 127.0.0.1 n/a centos fuel True True ready fuel 9.0 n/a
1 1 192.168.114.3 00:0c:29:1e:a4:6c ubuntu controller True True deploying Untitled (a4:6c) 9.0 node-1.domain.tld
2 1 192.168.114.2 00:0c:29:d9:d1:52 ubuntu compute True True deploying Untitled (d1:52) 9.0 node-2.domain.tld
Outputs and/or files available in "/tmp/timmy/info".
Archives available in "/tmp/timmy/archives".
[root@fuel archives]#
[root@fuel archives]# ls -l
total 360580
-rw-r--r--. 1 root root 3856137 Nov 1 06:35 general.tar.gz
-rw-r--r--. 1 root root 3861360 Nov 1 08:18 log_archive.tar.gz
-rw-r--r--. 1 root root 81007590 Nov 1 08:19 logs-fuel.tar.gz
-rw-r--r--. 1 root root 219154098 Nov 1 08:19 logs-node-1-192.168.114.3.tar.gz
-rw-r--r--. 1 root root 61338688 Nov 1 08:19 logs-node-2-192.168.114.2.tar.gz
[root@fuel archives]#
ログファイルが取得できました。
★FuelのWebUIでも動作を確認しておきましょう。
WebUIからは特に指定できないようですね。
ボタンを押したら1分ほどで「Diagonastic Snapshot」と書かれたリンクが表示されて、リンクをクリックするとファイルがダウンロードできました。
ファイル名は「fuel-snapshot-2016-11-01_07-22-53.tar」でした。
335MB程度でした。
解凍してみると、
といった具合にログファイルとコンフィグファイルの2つに分かれて取得できています。
ログファイルを展開してみると、/var/log配下のファイルが取得できています。
nova-compute.logを見たところ、
30日以内ぶんのログは取得できていました。
10. S3API認証でKeystoneを有効にできる機能(S3 API authentication through Keystone)
RadosGW上のS3 APIを認証するためにKeystoneを有効にできるよう実装しました。
これは、Keystoneの負荷を増大にさせる可能性があるので、使う場合は、Mirantisへお問い合わせをと書かれています。
下記のボタンで有効化できるそうです。
「Enable S3 API Authentication via Keystone in Ceph RadosGW」
11. DMZ有効化 (Basic DMZ enablement)
DMZと呼ばれる安全なネットワークセグメントにパブリックAPIエンドポイントとOpenStackのダッシュボードを配置することができるように実装されました。
さらに深追いしてBluePrintを確認してみる。
https://blueprints.launchpad.net/fuel/+spec/separate-public-floating
つまり、PublicネットワークとFloatingネットワークを分けることを可能にしたようです。
どうも、まだダッシュボードでの配備は実装できていないようです。
https://docs.mirantis.com/openstack/fuel/fuel-9.1/assets/MirantisSecurityBestPractices.pdf
上記資料のP52あたりに手順がありますが、DMZのネットワーク設計からDMZ上にReverse Proxyを配置したり、少し手がかかりそうなイメージです。
今回はここまで検証しませんが、手順が複雑なのでダッシュボードで可視化されるまで待ったほうがよさそうです。
これが実現できるようになったということは、さらにセキュリティの向上、Dos攻撃などからもFuelSlaveを守ることができるようになります。
12. ドキュメント改善（User experience and documentation）
Mirantis OpenStack 9.1は、WebSiteのレイアウトでドキュメントを参照することができるようになったようです。
下記のサイトにMOS9.1に関係するドキュメントの一覧があります。
https://docs.mirantis.com/openstack/fuel/fuel-9.1/release-notes/new-features/documentation.html
所感
やはり出たばかりの最新バージョンですのでバグが少なからず存在しているようです。
私が見たバグはドキュメントバグ3件、機能1件ですね。
MOS9.0は安定してきているようですので、取り急ぎ、現時点（2016年10月時点）では、しばらく、MOS9.0をご利用することをお勧めいたします。
特に、FloatingIPとPublicを分離できるようになった機能が拡充されましたが使うユーザは多くなることでしょう。
それに加えて、ローリングアップデートできるようになったことは、とても大きな進展・魅力的な機能なのではないでしょうか。
ローリングアップデートについて、マシンが増えた場合はどれくらい時間が増えるのか、パラレルで更新されるのか、疑問点がまだまだありますので、調査してみたいと考えております。