[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
実務で OpenStack をやっているのだが、バージョンアップを上手くやれるビジョンがあまりない。コツとして「KeyStone から上げろ」「バージョンは1つずつ上げろ」「無停止バージョンアップは諦めろ」「サービス間はバージョン1つ差まではサポートされるから順番に上げてけ」等が挙げられている。
ひよこの環境は Ubuntu14.04LTS 上に Liberty を入れているのだが、同 OS では Mitaka までしかサポートされない。この記事を書いている時点での最新、Ocata は Ubuntu16.04 に OS も上げないとうごかない。考えることが倍くらいに増えてつらい……
やらないわけにもいかないので、進展があったら何か書くかも。
この記事は Creative Commons by-by 3.0 で公開されている記事を翻訳したものです。その為、この記事も同じライセンスとなります。
What is the difference between Cinder, Glance and Swift? - Ask OpenStack: Q&A Site for OpenStack Users and Developers の翻訳です。Swift と Cinder の違いがよくわからなかった時期が私にもあったので、翻訳してみた。
OpenStack を先日学び始めました。手始めに各コンポーネントについて知ろうと思っています。
Cinder、Glance、Swift がストレージであることは理解できたのですがこれらは実際どう違うのでしょうか? 格納されるモノの種類が違うのでしょうか?
Cinder はブロックストレージを提供します。このストレージは各インスタンスに接続し、利用できます。Glance は OS のイメージを格納し、このイメージから (補足：インスタンスを) 復旧させることができます (イメージはテナント内限定で共有することも、テナントを超えてサービス全体で共有することもできます)。Swift は(補足：各レプリケーションノード間の)ファイルの一貫性を保ったオブジェクトストレージです。(補足：Glance の) イメージは Swift ないしはコントローラノードのファイルシステムに保存できます(補足：Cinder や Amazon S3、他ベンダーのオブジェクトストレージにも対応している)。OpenStack のどこにイメージを補完するのかはよくよく考えてから決めると良いでしょう。 もっと詳しく学ぶには http://docs.openstack.org/ops-guide/ をご覧ください。
回答日時 2014年5月23日 22:47
回答者 annegentle
上の説明で Glance と Cinder は分かると思う。Cinder はインスタンス (仮想マシン) につける外付けハードディスクなり USB フラッシュメモリ、フロッピーディスクといったような働きをする。Glance は Amazon でいう所の AMI を管理する何かである。
Swift は分かりにくい。これは Amazon でいう所の S3 であり、ファイルをアップロードする。運用中のデータのバックアップをとったり、ファイル共有したりするのに使える。
新しくサーバが届いたのでコンピュートノードを増やそうとした。インストールを行った結果、nova-computeを nova-conductor に認識してもらえなかった。
他に確認したこととしては
neutron-plugin-linuxbridge-agentは認識してもらえているnova-compute 自体は起動している。service nova-compute status で確認済WARNING nova.virt.libvirt.driver [req-a8aad900-321c-491a-a61e-986fd2040227 - - - - -] Cannot update service status on host "myNewComputeNode" since it is not registered.
読みやすくするために若干成型済み
ERROR oslo_db.sqlalchemy.exc_filters [req-2e3cdcf7-f518-49c3-b15f-4ca8ac47d271 - - - - -]
DBAPIError exception wrapped from (pymysql.err.InternalError)
(1241, u'Operand should contain 1 column(s)')
[SQL: u'SELECT migrations.created_at AS migrations_created_at,
migrations.updated_at AS migrations_updated_at,
migrations.deleted_at AS migrations_deleted_at,
migrations.deleted AS migrations_deleted, migrations.id AS migrations_id,
migrations.source_compute AS migrations_source_compute,
migrations.dest_compute AS migrations_dest_compute,
migrations.source_node AS migrations_source_node,
migrations.dest_node AS migrations_dest_node,
migrations.dest_host AS migrations_dest_host,
migrations.old_instance_type_id AS migrations_old_instance_type_id,
migrations.new_instance_type_id AS migrations_new_instance_type_id,
migrations.instance_uuid AS migrations_instance_uuid,
migrations.status AS migrations_status,
migrations.migration_type AS migrations_migration_type,
migrations.hidden AS migrations_hidden
FROM migrations
WHERE migrations.deleted = %s AND migrations.status = %s AND migrations.source_compute = %s AND migrations.migration_type = %s']
[parameters: (0, [u'accepted', u'done'], u'myNewComputeNode', u'evacuation')]
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 1139, in _execute_context
context)
File "/usr/lib/python2.7/dist-packages/sqlalchemy/engine/default.py", line 450, in do_execute
cursor.execute(statement, parameters)
File "/usr/lib/python2.7/dist-packages/pymysql/cursors.py", line 132, in execute
result = self._query(query)
File "/usr/lib/python2.7/dist-packages/pymysql/cursors.py", line 271, in _query
conn.query(q)
File "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 726, in query
self._affected_rows = self._read_query_result(unbuffered=unbuffered)
File "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 861, in _read_query_result
result.read()
File "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 1064, in read
first_packet = self.connection._read_packet()
File "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 826, in _read_packet
packet.check_error()
File "/usr/lib/python2.7/dist-packages/pymysql/connections.py", line 370, in check_error
raise_mysql_exception(self._data)
File "/usr/lib/python2.7/dist-packages/pymysql/err.py", line 116, in raise_mysql_exception
_check_mysql_exception(errinfo)
File "/usr/lib/python2.7/dist-packages/pymysql/err.py", line 112, in _check_mysql_exception
raise InternalError(errno, errorvalue)
InternalError: (1241, u'Operand should contain 1 column(s)')
compute node down, db error - Ask OpenStack: Q&A Site for OpenStack Users and Developers でこの話を扱っていた。次のようにある。
I ended up fixing it, my versions were incorrect. I had installed 2:12.03 on the new compute node, and have 2:12.01 versions on my controller node. By upgrading my controller, and existing nodes, it solved my issues.
すなわち、直せた。バージョンの食い違いが原因。新しいコンピュートノードは 2:12.03 だったけど、コントローラノード (つまり nova-conductor とか) は2:12.01 だった。コントローラを更新したら解決したよとのこと。実際、試したら (apt-get upgrade したら) 解決した。なお、古いコンピュートノードは更新せずとも問題なく動いた模様。
でも、末尾番号ってパッチバージョンよね……? そこは変わっても動いてくれてもいいと思ったひよこでした。
OpenStack はいくつかのモジュール (サービスと呼ばれる) が互いに通信をしあって何かをやっていく、という作りになっている。Keystone ももちろん例外ではない。というよりは、そのような作りの中心に Keystone があると言える。
Keystone は認証・認可を OpenStack において担うが、設定によって Keystone 以外の認証認可モジュールを使うこともできる。 Keystone 以外に何を採用するのかはちょっと疑問だが……
Keystone は認証・認可の機能を他のモジュールから使われるわけである。そこでひよこは思った。OpenStack と全然関係ないアプリを作る時に Keystone を使えば認証認可作らなくていいんじゃね？
OpenStack のユーザをまとめて追加したり、権限を付与/剥奪するアプリを書いた。OpenStack のために作られた Horizon というウェブコンソールを追加するモジュールは既存なのだが、こいつの権限管理機能が私にはちょっと使いにくかったのである。
Keystone は Web API を提供している。それをたたくだけで簡単に機能を使えるので実装そのものは簡単だった。手元に勝手にアクセスしてもよい Keystone があればぜひ curl で試してみてほしい所。
CINDER は仮想ストレージを管理する OpenStack のサービス。
NOVA は仮想サーバを管理する OpenStack のサービス。
どちらも次の順序で動く。
***-scheduler というコンポーネントがfilters と weights を使って決める。driver がなんとかしてくれるからだ。CINDER に関するドキュメントがほとんど見つからない。しょんぼり。
質問日時 2014年5月17日 03:41
質問者 azendale