OpenStack 運用ガイド
February 1, 2016
OpenStack 運用ガイド
[FAMILY Given]
製作著作 © 2014 OpenStack Foundation Some rights reserved.
概要
本書は OpenStack クラウドの設計および運用に関する情報を提供します。
Except where otherwise noted, this document is licensed under
Creative Commons Attribution 3.0 License.
http://creativecommons.org/licenses/by/3.0/legalcode
i
OpenStack 運用ガイド
February 1, 2016
謝辞
OpenStack Foundationは、オースチンへの航空券、(暴風後の停電による
ドキドキの夜を含む)宿、そして美味しい食事で、この本の作成をサポー
トしました。約10,000USドルで、Rackspaceのオースチンオフィスの同じ
部屋の中で、私たちは1週間で集中的に共同作業をすることができまし
た。著者たちはすべて OpenStack Foundation のメンバーであり、あな
たも OpenStack Foundation に参加できます。Foundationのウェブサイ
ト (http://openstack.org/join) に行ってみてください。
私たちは、オースチンの Rackspace での素晴らしいホスト Rackersに感
謝したい:
• Rackspace ゲストリレーションズの Emma Richards は、私たちのラン
チの注文を素晴らしく面倒を見てくれて、更に壁から剥がれ落ちた付
箋紙の山を脇においてくれました。
• 熱狂的なエグゼクティブアシスタントの Betsy Hagemeier は、部屋の
改造の面倒を見てくれて、1週間で解決する手助けをしてくれました。
• 「The Victors」としても知られている、オースチンの Rackspace の
不動産チームは、素晴らしい応答をしてくれました。
• Rackspace IT部門 の Adam Powell は、私たちに毎日のネットワー
ク帯域を提供してくれました。また、より多くのスクリーンが必要と
なったため、セカンドモニタを提供してくれました。
• 水曜日の夜、オースチン OpenStack ミートアップグループと楽しく幸
せな時間を過ごし、Racker Katie Schmidt は私たちのグループを素晴
らしい世話をしてくれました。
私たちは部屋の外から、いくつかの素晴らしいインプットを得ました。
• CERNの Tim Bell は、私たちが作業を開始する前に、その概要につい
てフィードバックを与えてくれて、週の半ばにはレビューをしてくれ
ました。
• Sébastien Han は素晴らしいブログを書いてくれて、寛大にも再利用
の許可を与えてくれました。
• Oisin Feeley は、このマニュアルを読んで、いくつかの編集をし、私
たちが問い合わせをした際には、E-mailでのフィードバックをくれま
した。
iii
OpenStack 運用ガイド
February 1, 2016
私たちは、ブックスプリント部屋の中で、ファシリテーターの Adam
Hyde と毎日過ごしました。彼の精力的なサポートと励ましがなければ、
この範囲のドキュメントを 5 日間で作成できなかったでしょう。Adam
は、ブックスプリントの手法が効果的であることを何回も実証しまし
た。彼は、www.booksprints.net にあるコラボレーションにおいて、
ツールと信念の両方を作成しました。
私たちは、これらの多大な協力的な援助と励まし無しには、これを成し
遂げることはできなかったでしょう。
iv
OpenStack 運用ガイド
February 1, 2016
目次
はじめに .................................................... xv
OpenStack の概要 ....................................... xv
はじめての OpenStack .................................. xvi
この本の対象読者 ...................................... xvii
この本の構成 ........................................... xix
この本をなぜ書いたか？どうやって書いたか？ ........... xxiii
この本の作成に参加するには ........................... xxvii
このドキュメントに使用される規則 ...................... xxix
I. アーキテクチャー .......................................... 1
1. アーキテクチャー例 ................................... 3
アーキテクチャー例: レガシーネットワーク (nova) ...... 3
アーキテクチャー例: OpenStack Networking ........... 10
アーキテクチャー例についての章の結び ................ 27
2. プロビジョニングとデプロイメント ..................... 29
自動デプロイメント ................................. 29
自動環境設定 ....................................... 33
リモート管理 ....................................... 33
OpenStack のプロビジョニングおよびデプロイメントの
概念 ............................................... 34
まとめ ............................................. 34
3. クラウドコントローラーのデザインとクラウド管理 ....... 37
ハードウェアの考慮事項 ............................. 39
サービスの分離 ..................................... 40
データベース ....................................... 40
メッセージキュー ................................... 41
コンダクターサービス ............................... 41
Application Programming Interface (API) ............ 42
API 拡張 ........................................... 42
スケジューリング ................................... 43
イメージ ........................................... 43
ダッシュボード ..................................... 44
認証と認可 ......................................... 44
ネットワークの考慮事項 ............................. 45
4. コンピュートノード .................................. 47
CPU の選択 ......................................... 47
ハイパーバイザーの選択 ............................. 48
インスタンスストレージのソリューション .............. 49
オーバーコミット ................................... 53
ロギング ........................................... 54
ネットワーク ....................................... 55
まとめ ............................................. 55
v
OpenStack 運用ガイド
February 1, 2016
5. スケーリング ........................................ 57
出発点 ............................................. 57
クラウドコントローラーノードの追加 .................. 59
クラウドの分離 ..................................... 60
スケーラブルハードウェア ........................... 64
6. ストレージ選定 ...................................... 67
一時ストレージ ..................................... 67
永続ストレージ ..................................... 67
ストレージのコンセプト ............................. 72
ストレージバックエンドの選択 ....................... 73
まとめ ............................................. 80
7. ネットワーク設計 .................................... 81
管理ネットワーク ................................... 81
パブリックアドレスの選択肢 ......................... 82
IP アドレス計画 .................................... 82
ネットワークトポロジー ............................. 84
ネットワーク関係のサービス ......................... 86
まとめ ............................................. 87
II. 運用 .................................................... 89
8. 環境の把握 .......................................... 91
管理目的での OpenStack Dashboard の使用 ............ 91
コマンドラインツール ............................... 91
ネットワークの検査 ................................. 99
ユーザーとプロジェクト ............................ 100
稼働中のインスタンス .............................. 100
概要 .............................................. 101
9. プロジェクトとユーザーの管理 ........................ 103
プロジェクトかテナントか? ......................... 103
プロジェクトの管理 ................................ 104
クォータ .......................................... 106
ユーザー管理 ...................................... 116
新規ユーザーの作成 ................................ 116
プロジェクトへのユーザーの割り当て ................. 118
概要 .............................................. 123
10. ユーザーによる運用 ................................. 125
イメージ .......................................... 125
フレーバー ........................................ 128
セキュリティグループ .............................. 130
ブロックストレージ ................................ 140
Shared File Systems サービス ...................... 142
インスタンス ...................................... 157
セキュリティグループの割り当て .................... 162
Floating IP ....................................... 162
vi
OpenStack 運用ガイド
11.
12.
13.
14.
February 1, 2016
ブロックストレージの接続 ..........................
スナップショットの取得 ............................
データベースにあるインスタンス ....................
グッドラック！ ....................................
メンテナンス、故障およびデバッグ ...................
クラウドコントローラーとストレージプロキシの故障と
メンテナンス ......................................
コンピュートノードの故障とメンテナンス .............
ストレージノードの故障とメンテナンス ...............
完全な故障の対処 ..................................
構成管理 ..........................................
ハードウェアの取り扱い ............................
データベース ......................................
HDWMY .............................................
故障しているコンポーネントの特定 ..................
アンインストール ..................................
ネットワークのトラブルシューティング ...............
「ip a」を使ってインタフェース状態をチェックする ...
クラウド上の nova-network 通信の仮想化 ............
クラウド上の OpenStack Networking サービス通信の仮
想化 ..............................................
経路上の障害を見つける ............................
tcpdump ...........................................
iptables ..........................................
nova-network 用データベースにあるネットワーク設定 ..
nova-network の DHCP 問題の デバッグ ..............
DNS の問題をデバッグする ..........................
Open vSwitch のトラブルシューティング .............
ネットワーク名前空間への対応 ......................
概要 ..............................................
ロギングと監視 ....................................
ログはどこにあるのか？ ............................
ログの読み方 ......................................
インスタンスリクエストの追跡 ......................
カスタムログの追加 ................................
RabbitMQ Web管理インターフェイス および rabbitmqctl
...................................................
ログの集中管理 ....................................
監視 ..............................................
概要 ..............................................
バックアップとリカバリー ...........................
バックアップ対象 ..................................
データベースのバックアップ ........................
vii
163
164
169
170
171
171
173
180
181
182
183
184
185
186
189
191
191
192
193
201
201
203
204
205
209
210
212
213
215
215
215
217
218
219
219
221
229
231
231
232
OpenStack 運用ガイド
February 1, 2016
ファイルシステムバックアップ ......................
バックアップのリカバリー ..........................
概要 ..............................................
15. カスタマイズ ......................................
OpenStack 開発環境の作成 ..........................
Object Storage (Swift) ミドルウェアのカスタマイズ ..
OpenStack Compute (nova) スケジューラーのカスタマイ
ズ ................................................
Dashboard (Horizon) のカスタマイズ ................
まとめ ............................................
16. OpenStack コミュニティー ..........................
助けを得る ........................................
バグ報告 ..........................................
OpenStack コミュニティーに参加する ................
ドキュメント作成への貢献の仕方 ....................
セキュリティー情報 ................................
さらに情報を見つける ..............................
17. 高度な設定 ........................................
ドライバーによる違い ..............................
定期タスクの実装 ..................................
設定に関する個別のトピック ........................
18. アップグレード ....................................
アップグレード前の考慮事項 ........................
アップグレード手順 ................................
失敗したアップグレードのロールバック ...............
A. 事例 ....................................................
NeCTAR .................................................
MIT CSAIL .............................................
DAIR ..................................................
CERN ..................................................
B. ハリウッド^H^H^H^H^Hクラウドナイトメア ...................
二重 VLAN .............................................
「あの問題」 ...........................................
イメージの消失 .........................................
バレンタインデーのコンピュートノード大虐殺 .............
ウサギの穴に落ちて .....................................
Havana 死者の幽霊 .....................................
C. ロードマップの取り扱い ..................................
利用できる情報 .........................................
ロードマップへの影響 ...................................
ウォッチの観点 .........................................
分散仮想ルーター .......................................
viii
232
234
235
237
237
240
246
252
252
253
253
254
257
258
258
259
261
261
262
263
265
265
269
272
277
277
278
279
280
283
283
286
288
290
292
293
297
298
299
300
302
OpenStack 運用ガイド
February 1, 2016
Modular Layer 2 プラグインによる Open vSwitch プラグイン
の置換 .................................................
新しい API ............................................
OpenStack on OpenStack (TripleO) ......................
Data processing service for OpenStack (sahara) .........
Bare metal Deployment (ironic) ........................
Database as a Service (trove) .........................
Message Service (zaqar) ...............................
DNS service (designate) ...............................
スケジューラーの改善 ...................................
D. 情報源 ..................................................
OpenStack ..............................................
Cloud (General) .......................................
Python .................................................
ネットワーク ...........................................
システム管理 ...........................................
仮想化 .................................................
構成管理 ...............................................
用語集 .....................................................
索引 .......................................................
ix
302
302
303
303
303
303
303
304
304
305
305
305
305
305
306
306
306
307
375
OpenStack 運用ガイド
February 1, 2016
図の一覧
1. OpenStack 論理アーキテクチャー () ......................... 2
1.1. 基本ノードデプロイメント ............................... 17
1.2. パフォーマンスノードのデプロイメント .................... 18
1.3. コントローラーノード ................................... 19
1.4. コンピュートノード ..................................... 20
1.5. ネットワークノード ..................................... 21
1.6. ストレージノード ....................................... 22
2.1. ドライブのパーティション設定 ........................... 31
9.1. Dashboard のプロジェクトの作成フォーム ................ 105
9.2. プロジェクトメンバーの編集 タブ ....................... 119
12.1. ping パケットの通信ルート ............................ 192
12.2. Neutron ネットワーク経路 ............................. 195
C.1. リリースサイクル図 .................................... 298
xi
OpenStack 運用ガイド
February 1, 2016
表の一覧
1.1. ノードのタイプ ......................................... 13
1.2. サードパーティーコンポーネントの設定 .................... 22
1.3. OpenStack component configuration ...................... 25
3.1. クラウドコントローラーのハードウェアサイジングに関する
考慮事項 .................................................... 39
3.2. 構成シナリオ ........................................... 40
5.1. OpenStack デフォルトのフレーバー ....................... 58
5.2. OpenStack 分離の手法 ................................... 60
6.1. OpenStack ストレージ ................................... 72
6.2. 永続ファイルベースのストレージサポート .................. 74
7.1. ネットワーク構成オプション ............................. 84
9.1. Compute のクォータの説明 .............................. 107
9.2. Block Storage のクォータの説明 ........................ 113
10.1. フレーバーのパラメーター ............................. 129
11.1. サービス復旧優先度一覧の例 ........................... 181
13.1. OpenStack のログの場所 ............................... 215
xiii
OpenStack 運用ガイド
February 1, 2016
はじめに
OpenStack の概要 ............................................ xv
はじめての OpenStack ....................................... xvi
この本の対象読者 .......................................... xvii
この本の構成 ............................................... xix
この本をなぜ書いたか？どうやって書いたか？ ................ xxiii
この本の作成に参加するには ............................... xxvii
このドキュメントに使用される規則 ........................... xxix
OpenStack はオープンソースプラットフォームで、OpenStack を使う
と、コモディティハードウェア上で動作する Infrastructure as a
Service (IaaS) クラウドを自分で構築できます。
OpenStack の概要
OpenStack は、オープンソース、オープン設計、オープン開発を信じて
います。すべては、あらゆる人の参加を奨励するオープンコミュニティ
により行われています。OpenStack の長期ビジョンは、規模によらず、
パブリッククラウドやプライベートクラウドのプロバイダーの要求を
満たす、ユビキタスなオープンソースのクラウドコンピューティングソ
フトウェアを作成することです。OpenStack のサービスは、データセン
ター全体のコンピュート、ストレージ、ネットワークの大規模なリソー
スプールを制御します。
OpenStack の背後にある技術は、クラウドインフラストラクチャーソ
リューション向けのさまざまなコンポーネントを提供する、一連の相互
に関連するプロジェクトから構成されます。各サービスは、これらのリ
ソースをすべてダッシュボードから管理できるよう、オープンな API を
提供します。これは、権限を与えられたユーザーが、API をサポートす
る Web インターフェース、コマンドラインクライアント、ソフトウェア
開発キット (SDK) 経由でリソースを配備する管理者権限を与えます。多
くの OpenStack API は拡張できます。API 拡張経由でより多くのリソー
スにアクセスして革新しながら、コアなコール群の互換性を保つことが
できます。OpenStack プロジェクトは、開発者とクラウドコンピュー
ティング技術者のグローバルなコラボレーションです。プロジェクト
は、パブリッククラウドおよびプライベートクラウド向けのオープン標
準なクラウドコンピューティングプラットフォームを生産します。実装
のしやすさ、大規模なスケーラビリティ、さまざまな豊富な機能、もの
すごい拡張性に注力することにより、プロジェクトはあらゆる種類の組
織に対して実践的かつ信頼できるクラウドソリューションを提供するこ
とを目指しています。
xv
OpenStack 運用ガイド
February 1, 2016
はじめての OpenStack
OpenStack は、オープンソースプロジェクトとして、ユニークな点があ
ります。その 1 つは、さまざまなレベルで OpenStack に携わりはじめ
ることができる点です。すべてを自分自身で行う必要はありません。
OpenStack の使い方
「まだクラウドを構築する必要がありますか?」と質問したことでしょ
う。クレジットカードを使うだけで、コンピュートサービスやスト
レージサービスを使いはじめたい場合、eNovance、HP、Rackspace な
どのパブリック OpenStack クラウドを使うことができます。それらの
OpenStack クラウドのリソースを使うことは、パブリックにアクセスで
きる Amazon Web Services Elastic Compute Cloud (EC2) や Simple
Storage Solution (S3) にアクセスすることと同じです。
プラグアンドプレイ OpenStack
しかしながら、OpenStack の魅力的な部分は、自分のプライベートクラ
ウドを構築することかもしれません。この目標を達成するいくつかの
方法があります。おそらく最も簡単な方法は、アプライアンス形式の
ソリューションです。アプライアンスを購入し、それを展開し、電源と
ネットワークを接続します。そして、最小限の設定だけで OpenStack ク
ラウドが構築されていくことを見ていてください。
また一方、ハードウェアの選択が多くのアプリケーションにとって
重要です。そのため、アプライアンスを適用する場合、自分で選択
したサーバー、ストレージ、ネットワークの製品で実行できる、ソ
フトウェアディストリビューションがいくつかあることを考慮してく
ださい。Canonical (2011 年に標準のクラウド製品を Eucalyptus か
ら OpenStack に置き換えました)、Red Hat、SUSE は、エンタープラ
イズレベルの OpenStack ソリューションとサポートを提供していま
す。Rackspace、Piston、SwiftStack、Cloudscaling などの専門的な
ディストリビューションも見たいかもしれません。
代わりに、ベースとするハードウェアやアプリケーション、いくつかの
新機能の追加、コンポーネントをくみ上げる方法を判断するために、誰
かに支援してほしい場合、Mirantis や Metacloud などの OpenStack の
経験豊富なシステムインテグレーターに連絡することを検討してくださ
い。
自分たち内部の OpenStack 専門性を高めることを優先する場合、それ
を始める良い方法は、トレーニングに参加または手配することかもし
xvi
OpenStack 運用ガイド
February 1, 2016
れません。OpenStack Foundation は、お近くのイベントを見つけられ
る Training Marketplace を開いています。また、OpenStack コミュニ
ティーは、オープンソースのトレーニング教材を作成するグループがあ
ります。
自分の OpenStack の展開
しかしながら、このガイドは別の想定読者もいます。独自の自作ソ
リューションを導入することにより、OpenStack フレームワークの柔軟
性を求めている人々です。
OpenStack は水平的にスケールするよう設計されているため、クラウド
の拡大に合わせて新しいコンピュート、ネットワーク、ストレージのリ
ソースを簡単に追加できます。大規模 OpenStack パブリッククラウドの
広播性に加えて、PayPal、Intel、Comcast などの多くの組織が大規模な
プライベートクラウドを構築しています。OpenStack は、クラウドを構
築するためのいくつかの異なる技術を統合できるので、一般的なソフト
ウェアよりも多くのものを提供します。このアプローチにより、素晴ら
しい柔軟性を提供しますが、始めは数多くのオプションにより圧倒され
るかもしれません。
この本の対象読者
この本は、OpenStack クラウドの運用を始めようとして人も、運用中の
OpenStack クラウドを引き継ぎ、うまく動かし続けようとしている人も
対象にしています。おそらく、あなたは devops チームの一員であった
り、クラウドを始めたばかりのシステム管理者なのでしょう。あなたの
会社の OpenStack クラウドチームに入ろうとしているのかもしれませ
ん。この本はそのような皆さん全員に向けたものです。
このガイドは、OpenStack をサポートする Linux ディストリビューショ
ン、SQL データベースや仮想化に関してよく知っていることを前提にし
ています。複数台の Linux マシンのネットワーク設定・管理にも慣れて
いる必要があります。SQL データベースのインストールと管理を行い、
場合によってはデータベースに対してクエリーを実行することもありま
す。
OpenStack クラウドの最も複雑な点の一つにネットワーク設定がありま
す。DHCP、Linux ブリッジ、VLAN、iptables といった考え方をよく理解
していなければなりません。OpenStack クラウドで必要となるスイッチ
やルータを設定できるネットワークハードウェアの専門家と話をする必
要もあります。
xvii
OpenStack 運用ガイド
February 1, 2016
ヒント
クラウドコンピューティングは非常に高度な話題です。ま
た、本書は多くの基礎知識を必要とします。しかしながら、
クラウドコンピューティングに慣れていない場合、本書の最
後にある用語集 [307]、OpenStack のオンラインドキュメン
ト、付録D 情報源 [305]にある本書で参照されている参考資
料を使うことを推奨します。
参考資料
作業を完了するために役立つ、その他のガイドはOpenStack ドキュメン
ト Web サイトにあります。
OpenStack の各種ガイド
OpenStack インストールガイド
自動化せずに、手動で行う場合のイ
ンストール手順について説明していま
す。パッケージングシステムがある複
数のディストリビューション向けのイ
ンストールガイドがあります。
• インストールガイド openSUSE
13.2、SUSE Linux Enterprise
Server 12 版
• インストールガイド Red Hat
Enterprise Linux 7、CentOS 7 版
• インストールガイド Ubuntu 14.04
(LTS) Server 版
OpenStack 設定レファレンス
リリースバージョン毎に、OpenStack
のコアサービス、統合されたサービ
スのすべての設定オプションの一覧が
載っています
OpenStack クラウド管理者ガイ
ド
あなたのユースケースに合わせ
て、ストレージ、コンピューティン
グ、Software-defined-networking な
ど OpenStack クラウドを管理する方
法が書かれています
xviii
OpenStack 運用ガイド
February 1, 2016
OpenStack 高可用性ガイド
OpenStack サービス、関連するコント
ローラやデータストアを高可用にする
ために取りうる方策に説明しています
OpenStack セキュリティガイド
OpenStack クラウドを安全にするため
のベストプラクティスと基本的な考え
方について書かれています
仮想マシンイメージガイド
OpenStack で利用可能な仮想マシンイ
メージを取得、作成、更新する方法に
ついて説明されています
OpenStack エンドユーザーガイ
ド
OpenStack のエンドユーザー
が、OpenStack Dashboard と
OpenStack クライアントコマンドを
使って、OpenStack クラウドのリソー
スの作成・管理を行う方法を説明して
います
OpenStack 管理ユーザーガイド
OpenStack の管理者が、OpenStack
Dashboard と OpenStack クライアン
トコマンドを使って、OpenStack クラ
ウドのリソースの作成・管理を行う方
法を説明しています。
ネットワークガイド
このガイドは、OpenStack Networking
(neutron) を導入して管理する方法を
探している、OpenStack 管理者を対象
にしています。
OpenStack API Guide
OpenStack サービスのエンドポイント
に REST API リクエストをどのように
送信するかについての概要が説明され
ています
この本の構成
この本は 2つの部分から構成されています。1 つは OpenStack クラウド
設計においてアーキテクチャーの決定に関してで、もう 1 つは稼働中の
OpenStack クラウドで繰り返し行う運用に関してです。
パート I:
1章アーキテクチャー例 [3]
他の章で議論するすべての判断によ
り、本章はこのドキュメントのために
xix
OpenStack 運用ガイド
February 1, 2016
行われる判断、アーキテクチャー例の
正当性について説明します。
2章プロビジョニングとデプロ
イメント [29]
本書はインストールについて説明して
いませんが、本章に記載されているよ
うに、配備と設定を自動化することを
強く推奨します。
3章クラウドコントローラーの
デザインとクラウド管理 [37]
クラウドコントローラーとは、各ノー
ドで実行するサービスを集約して説明
するための便宜的なものです。この章
は、ハードウェア、ネットワーク、お
よびパフォーマンスとサービスの分離
のためにクラウドコントローラーを設
定する方法について議論します。
4章コンピュートノード [47]
この章は、仮想マシンを実行するため
のコンピュートノードについて記載し
ます。いくつかのハードウェアの選択
肢があります。ロギングとネットワー
クについても説明しています。
5章スケーリング [57]
この章は、規模の拡張および分離にお
ける検討を通して、クラウドの拡大に
ついて議論します。
6章ストレージ選定 [67]
他のアーキテクチャーの判断と同じよ
うに、OpenStack におけるストレージ
の概念は、さまざまな選択肢がありま
す。この章は選択肢を提示します。
7章ネットワーク設計 [81]
OpenStack クラウドのネットワーク
は、既存のネットワークに適合する必
要があります。また、ユーザーや管理
者にとって最良の設定をできる必要も
あります。この章は、ネットワークの
判断に関する深い情報を提供します。
パート II:
8章環境の把握 [91]
この章は、コマンドラインツールを用
いてお使いの OpenStack クラウド全
体を理解できるようにするために書か
れました。また、お使いのクラウドに
xx
OpenStack 運用ガイド
February 1, 2016
すでにセットアップされているものを
理解することもできます。
9章プロジェクトとユーザーの
管理 [103]
この章は、すべての管理者がユーザー
を管理し、リソースを小さくまとめる
クォータを設定するために必ず直面す
る、ユーザー有効化のプロセスを詳細
に説明します。
10章ユーザーによる運用 [125]
この章は、OpenStack リソースの使用
方法、ユーザーの教育方法について説
明します。
11章メンテナンス、故障および
デバッグ [171]
この章は、執筆者がこれまで本番環境
を運用してきて、トラブルシューティ
ングする中で見てきた、一般的な障害
について詳細に検討します。
12章ネットワークのトラブル
シューティング [191]
ネットワークのトラブルシューティン
グは、仮想リソースでとくに難しくな
ります。この章は、ネットワーク通信
の追跡、ネットワーク障害の根本原因
の調査、DHCP や DNS などの関連サー
ビスのデバッグに関するヒントとコツ
がたくさん詰まっています。
13章ロギングと監視 [215]
この章は、OpenStack のログ保存場
所、監視目的にログを参照および管理
する最良の方法について説明します。
14章バックアップとリカバ
リー [231]
この章は、OpenStack 中でバックアッ
プする必要があるもの、バックアップ
のリカバリーのベストプラクティスに
ついて説明します。
15章カスタマイズ [237]
OpenStack に特別な機能を追加したい
読者向けに、この章は、カスタムミド
ルウェアやカスタムスケジューラーを
書いて、リソースを再配置するため
に、DevStack を使用する方法につい
て説明します。
16章OpenStack コミュニ
ティー [253]
OpenStack は非常にオープンであるた
め、この章は、コミュニティーを案内
する手助けになり、支援したり支援さ
xxi
OpenStack 運用ガイド
February 1, 2016
れたりできる場所を見つけることに専
念します。
17章高度な設定 [261]
ほとんどの OpenStack は、ドライ
バーを用いて動作します。そのため、
サービスの基本セットに別のソリュー
ションをプラグインできます。この章
は、いくつかの高度な設定に関する話
題を取り扱います。
18章アップグレード [265]
この章は、本書で使用されるアーキテ
クチャーに基づいて、アップグレード
に関する情報を提供します。
xxii
OpenStack 運用ガイド
February 1, 2016
後付:
付録A 事例 [277]
OpenStack コミュニティーのユース
ケースをいくつか参照できます。少
しの技術的な詳細と参考資料もありま
す。
付録B ハリウッド^H^H^H^H^Hク
ラウドナイトメア [283]
これらは、得がたい教訓や知見を得ら
れた、イメージの消失、仮想マシンの
大虐殺、クレイジーなトラブルシュー
ティング技術に関する伝説的な公開物
語です。
付録C ロードマップの取り扱
い [297]
オープンかつ透明な OpenStack の開
発プロセスからロードマップを把握す
る方法をまとめています。
付録D 情報源 [305]
プロジェクトの急速な成熟のため、数
多くの OpenStack の情報源がオンラ
インで利用可能ですが、執筆者が学習
している間に有用だったリソースを一
覧化しています。
用語集 [307]
この本で使われている用語の一覧。オ
ンライン上にある OpenStack 用語集
のサブセットです。
この本をなぜ書いたか？どうやって書い
たか？
私たちは少なくとも1年以上 OpenStack クラウドを構築し運用してきま
した。そこで得られた知識を多くの人と共有するために、この本を書き
ました。 OpenStack クラウドの責任者として数ヶ月がたつと、そのド
キュメントを渡しておけば、システム管理者に日々のクラウドの運用を
どのように行なえばよいかが分かるようなドキュメントが欲しくなりま
した。また、クラウドを構築する際に選択したやり方のより詳細な技術
情報を共有したいと思いました。
次のような場面であなたの助けとなるように、この本を書きました。
• 初めての本格的な OpenStack クラウドのアーキテクチャーの設計と構
築。この本を読み終えると、コンピュート、ネットワーク、ストレー
ジのリソースを選ぶにはどんな質問を自分にすればよいのか、どのよ
xxiii
OpenStack 運用ガイド
February 1, 2016
うに組み上げればよいのかや、どんなソフトウェアパッケージが必要
かが分かることでしょう。
• クラウドを管理する上で必要となる日々のタスクの実行。
私たちはこの本を Book Sprint で執筆しました。 Book Sprint は短
い期間で本を建設的に作成できるメソッドです。詳しい情報は、Book
Sprint のサイト を参照して下さい。著者らは2013年2月の5日間でこの
本をまとめあげました。カフェインと、テキサス州オースティンの素晴
らしいテイクアウトの食事は力になりました。
最初の日に、アイデアを色とりどりのポストイットでホワイトボード
いっぱいに書き出し、クラウドを設計し運用するという漠然とした話題
を扱った本の作成を開始しました。
私たちは一心不乱に自分たちの経験に基づき執筆を行い、互いに意見を
ぶつけ合いました。一定の間隔で、本の現在の状況や構成をレビュー
し、本を作り上げていき、今皆さんが見ているものができあがりまし
た。
以下が執筆チームのメンバーです。
Tom Fifield
CERN の Large Hadron Collider (LHC) で
ATLAS のような素粒子物理学実験でコン
ピューティングのスケーラビリティの経
xxiv
OpenStack 運用ガイド
February 1, 2016
験を積んだ後、現在はオーストラリアの
公的な研究部門を支援するプロダクション
の OpenStack クラウドに携わっていまし
た。現在は OpenStack のコミュニティマ
ネージャーを務めており、空いた時間で
OpenStack ドキュメントプロジェクトに参
加しています。
Diane Fleming
Diane は OpenStack API ドキュメントプ
ロジェクトで非常に熱心に活動していま
す。このプロジェクトでは自分ができると
ころであれば、どこでも取り組んでくれま
した。
Anne Gentle
Anne は OpenStack のドキュメントコー
ディネーターで、2011年の Google Doc
Summit では individual contributor
（個人コントリビュータ） を努め Open
Street Maps チームとともに活動しま
した。Adam Hyde が進めていた FLOSS
Manuals の以前の doc sprint にも参加し
ています。テキサス州オースティンに住ん
でいます。
Lorin Hochstein
アカデミック出身のソフトウェア開発者・
運用者である彼は、Nimbis Services で
クラウドサービスの Lead Architect と
して働いていました。Nimbis Service で
は彼は技術計算アプリケーション用の
OpenStack を運用しています。 Cactus
リリース以来 OpenStack に携わってい
ます。以前は、University of Southern
California's Information Sciences
Institute (USC-ISI) で OpenStack の
high-performance computing 向けの拡張
を行いました。
Adam Hyde
Adam は今回の Book Sprint をリードし
ました。 Book Sprint メソッドを創設者
でもあり、一番経験豊富な Book Sprint
のファシリテーターです。詳しい情報は
http://www.booksprints.net を見てくだ
さい。 3000人もの参加者がいるフリーソ
フトウェアのフリーなマニュアルを作成
するコミュニティである FLOSS Manuals
xxv
OpenStack 運用ガイド
February 1, 2016
の創設者です。また、Booktype の創設
者でプロジェクトマネージャーです。
Booktype はオンラインで本の執筆、編
集、出版を行うオープンソースプロジェク
トです。
Jonathan Proulx
Jon は MIT Computer Science and
Artificial Intelligence Lab で上級技術
アーキテクトとして OpenStack クラウド
を運用し、研究者が必要なだけの計算能力
を使えるようにしています。 OpenStack
の勉強を加速しようと思い、OpenStack ド
キュメントへの貢献とドキュメントのレ
ビューを始めました。
Everett Toews
Everett は Rackspace の Developer
Advocate で、OpenStack や Rackspace
Cloud を使いやすくする仕事をして
います。ある時は開発者、ある時は
advocate、またある時は運用者です。彼
は、ウェブアプリケーションを作成し、
ワークショップを行い、世界中で公演を
行い、教育界やビジネスでプロダクション
ユースとして使われる OpenStack を構築
しています。
Joe Topjian
Joe は Cybera で複数のクラウドの設計と
構築を行って来ました。 Cybera は、非営
利でカナダのアルバータ州の起業家や研究
者を支援する電子情報インフラを構築して
います。また、システムアーキテクトとし
てこれらのクラウドの維持・運用を活発に
行なっており、その経験からクラウド環境
でのトラブルシューティングの豊富な知識
を持っています。
OpenStack コミュニティー
メンバー
数多くの方々の努力がコミュニティのド
キュメントを維持しています。私たちの
コミュニティーのメンバーは、一年を通
じて、このドキュメントの内容を更新し
ました。また、最初のスプリントの 1 年
後、Jon Proulx さんが 2 回目となる 2
日間のミニスプリントを主催しました。
これは、MIT で行われ、最新リリースに
向けた更新を目標としました。ドキュメ
xxvi
OpenStack 運用ガイド
February 1, 2016
ント作成以降、30 人以上の貢献者がこの
ドキュメントをサポートしてきました。レ
ビュー、継続的ビルド、翻訳のツールチェ
インがあります。執筆者や開発者は継続的
に、パッチをレビューし、ドキュメントバ
グを記入し、内容を編集し、そのバグを修
正します。その方々の努力を認めたいと思
います。
以下の方々がこのドキュメントに貢献し
ています: Akihiro Motoki, Alejandro
Avella, Alexandra Settle, Andreas
Jaeger, Andy McCallum, Benjamin
Stassart, Chandan Kumar, Chris
Ricker, David Cramer, David Wittman,
Denny Zhang, Emilien Macchi, Gauvain
Pocentek, Ignacio Barrio, James E.
Blair, Jay Clark, Jeff White, Jeremy
Stanley, K Jonathan Harker, KATO
Tomoyuki, Lana Brindley, Laura Alves,
Lee Li, Lukasz Jernas, Mario B.
Codeniera, Matthew Kassawara, Michael
Still, Monty Taylor, Nermina Miller,
Nigel Williams, Phil Hopkins, Russell
Bryant, Sahid Orentino Ferdjaoui,
Sandy Walsh, Sascha Peilicke, Sean
M. Collins, Sergey Lukjanov, Shilla
Saebi, Stephen Gordon, Summer Long,
Uwe Stuehler, Vaibhav Bhatkar,
Veronica Musso, Ying Chun "Daisy" Guo,
Zhengguang Ou, ZhiQiang Fan.
この本の作成に参加するには
この本の元は人が集まったイベントで作成されましたが、今やこの本は
みなさんも貢献できる状態になっています。 OpenStack のドキュメン
ト作成は、バグ登録、調査、修正を繰り返して行うというコーディング
の基本原則に基いて行われています。我々はこの本のソースコンテンツ
を GitHub にも置いており、レビューシステムである OpenStack Gerrit
経由で協力をお待ちしています。この本の O'Reilly 版では、我々は
O'Reilly の Atlas システムを使用していますが、ソースコンテンツは
GitHub にも格納され、コントリビュータ間での共同作業ができるように
なっています。
xxvii
OpenStack 運用ガイド
February 1, 2016
Learn more about how to contribute to the OpenStack docs at
OpenStack Documentation Contributor Guide.
バグを見つけたが、どのように直せばよいか分からない場合や本当にド
キュメントのバグか自信が持てない場合は、OpenStack Manuals にバグ
を登録して、バグの Extra オプションで ops-guide タグを付けて下さ
い。 ops-guide タグは、そのバグがこのガイドに関するものであること
を示します。どのように直せばよいか分かる場合には、そのバグの担当
者を自分に割り当てることもできます。また、OpenStack doc-core チー
ムのメンバーがドキュメントバグを分類することもできます。
xxviii
OpenStack 運用ガイド
February 1, 2016
このドキュメントに使用される規則
以下の表記規則がこのドキュメントで使用されます。
斜体
新しい用語、URL、電子メール、ファイル
名、ファイルの拡張子を意味します。
等幅
プログラム一覧に使用されます。文中でも、
変数名、関数名、データベース、データ形
式、環境変数、宣言文、キーワードなどの
プログラム要素を参照するために使用されま
す。
Constant width bold
ユーザーにより書いてあるとおりに入力され
るべきコマンドや文字列を表します。
等幅・斜体
ユーザーが指定した値、または文脈により決
められる値で置き換えるべき文字列を表しま
す。
コマンドプロンプト
# プロンプトから始まるコマンドは、root
ユーザーにより実行すべきです。これらの例
は、sudo コマンドが利用できる場合、それ
を使用することもできます。
$ プロンプトから始まるコマンドは、root
を含む、すべてのユーザーにより実行できま
す。
ヒント
この要素はヒントや提案を意味します。
注記
この要素は一般的な注記を意味します。
警告
この要素は警告や注意を意味します。
xxix
パート I. アーキテクチャー
OpenStack クラウドの設計は重要な作業です。クラウドのユーザーの要件とニーズ
を確実に理解して、それらに対応するために可能な限り最良の構成を決定する必要
があります。OpenStack は、ユーザーのニーズを満たすための優れた柔軟性を提供
します。本セクションでは、このようなプロセスで行う必要のある数多くの決定事
項を明確に説明することを目的としています。
OpenStack の設計、デプロイ、および構成を行うにあたって、管理者は論理アーキ
テクチャーを理解するが必要があります。OpenStack 内で統合される全サービスお
よびそれらがどのように相互作用するかについての構想を立てるには、図が役立ち
ます。
OpenStack のモジュールは、以下の種別のいずれかです。
デーモン
バックグラウンドプロセスとして実行されま
す。Linux プラットフォームでは、デーモンは通常
サービスとしてインストールされます。
スクリプト
仮想環境をインストールし、テストを実行します。
コマンドラインインター
フェース (CLI)
ユーザーはコマンドを使用して API コールを
OpenStack サービスに送信できます。
下図に示したように、エンドユーザーはダッシュボード、CLI、および API を使用
して対話することができます。サービスはすべて、共通の Identity service を
介して認証を行い、またサービス相互間の対話は、特権のある管理者がコマンド
を実行する必要がある場合を除いてパブリック API を使用して行われます。図
1「OpenStack 論理アーキテクチャー ()」 [2] には、OpenStack の最も一般的
な論理アーキテクチャーを示しています。ただし、これは唯一のアーキテクチャー
ではありません。
OpenStack 運用ガイド
February 1, 2016
図1 OpenStack 論理アーキテクチャー (http://docs.openstack.org/
openstack-ops/content/figures/2/figures/osog_0001.png)
2
OpenStack 運用ガイド
February 1, 2016
第1章 アーキテクチャー例
アーキテクチャー例: レガシーネットワーク (nova) ............... 3
アーキテクチャー例: OpenStack Networking .................... 10
アーキテクチャー例についての章の結び ......................... 27
OpenStack が提供する可能性を理解するには、確実に信頼できる、本番
環境での検証済みの基本アーキテクチャーから開始するのが最善の方法
です。本ガイドでは、ベースオペレーティングシステム (Ubuntu および
Red Hat Enterprise Linux) 上に基本ピボットとネットワークアーキテ
クチャを備えた基本アーキテクチャーの例を 2 つ紹介しています。この
ガイドは、それぞれの選択理由を提供します。
OpenStack は、多数の異なるバックエンドおよびネットワーク設定オプ
ションを利用して高度に設定することが可能です。可能な OpenStack デ
プロイメントをすべて網羅するドキュメントを執筆するのは難しいた
め、本ガイドではアーキテクチャーの例を定義することによって文書
化の作業を簡素化すると共に、本書のスコープを規定します。以下に紹
介するアーキテクチャーの例はいずれも本番環境で現在実行中であり、
ユーザーにサービスを提供しています。
ヒント
これらのアーキテクチャー例で言及されている用語が明確に
理解できない場合には、通常通り 用語集 [307] を参照して
ください。
アーキテクチャー例: レガシーネット
ワーク (nova)
この特定のアーキテクチャー例は、Grizzly から Havana にアップグ
レードされており、複数のインスタンスに割り当てるためのパブリック
IP アドレスが多数利用可能な本番環境でテスト済みです。このセクショ
ンの次には、OpenStack Networking (neutron) を使用する第 2 のアー
キテクチャー例を紹介しています。各例では高可用性を提供していま
す。これは、特定のノードが停止した場合には同じ設定の別のノードが
タスクを引き継いでサービスを引き続き提供できることを意味します。
概要
Compute 用の基盤となる最もシンプルなアーキテクチャーは、単一
のクラウドコントローラーと複数のコンピュートノードで構成されま
3
OpenStack 運用ガイド
February 1, 2016
す。Object Storage 用の最もシンプルなアーキテクチャーは、ユーザー
を識別して API への要求をプロキシするノード 1 つと、最終的な一貫
性を確保するのに十分なレプリケーションを提供する、ストレージ自体
のためのノード 4つを合わせた 5 つのノードで構成されます。このアー
キテクチャーの例では、特定のノード数は決まっていませんが、この
アーキテクチャーを選択するにあたって考慮 および検討した点 (どのよ
うな機能を提供するかなど) をお分かりいただけます。
コンポーネント
コンポーネント
詳細
OpenStack リリース
Havana
ホストのオペレーティングシステム
Ubuntu 12.04 LTS または Red Hat Enterprise Linux
6.5 (CentOS および Scientific Linux などの派生物を
含む)
OpenStack パッケージリポジトリ
Ubuntu Cloud Archive、RDO*
ハイパーバイザー
KVM
データベース
MySQL*
メッセージキュー
Ubuntu には RabbitMQ、Red Hat Enterprise Linux に
は Qpid、 および派生物
ネットワークサービス
nova-network
ネットワークマネージャー
FlatDHCP
単一の nova-network またはマルチ
ホスト?
マルチホスト*
Image service (glance) バックエン file
ド
Identity (keystone) ドライバー
SQL
Block Storage (cinder) バックエン LVM/iSCSI
ド
ライブマイグレーションのバックエ
ンド
NFS を使用する共有ストレージ*
オブジェクトストレージ
OpenStack Object Storage (swift)
アスタリスク (*) は、アーキテクチャーの例がデフォルトインストール
の設定から逸脱している箇所を示しています。この逸脱については、次
のセクションで説明します。
注記
以下にあげる OpenStack の機能は、本ガイドに記載のアーキ
テクチャーではサポートされていますが、必須項目ではあり
ません。
4
OpenStack 運用ガイド
February 1, 2016
• ダッシュボード: ダッシュボードの提供を考慮されている
かもしれませんが、ユーザーは API アクセスのみの方に対
する関心の方が高い可能性があります。
• ブロックストレージ: ユーザーのユースケースでコン
ピュートノード上などの一時的なストレージのみが必要と
される場合は、ブロックストレージを提供する必要はあり
ません。
• Floating IP アドレス: Floating IP アドレスとは、仮想
マシンの起動時に事前定義されたプールから確保される
パブリック IP アドレスです。Floating IP アドレスによ
り、インスタンスの起動時には常にパブリック IP アドレ
スが利用できます。すべての組織が何千ものインスタンス
に何千ものパブリック Floating IP アドレスを提供でき
るとは限らないので、この機能はオプションと考えられま
す。
• ライブマイグレーション: サービスをほとんどまたは全く
停止せずに実行中の仮想マシンをホスト間で移動する必要
がある場合には、ライブマイグレーションを有効化するこ
とになりますが、この機能はオプションと考えられます。
• Object Storage: OpenStack Object Storage が提供するレ
プリケーションと冗長化に必要な追加のハードウェアがな
い場合には、マシンイメージをファイルシステムに保存す
るように選択することが可能です。
設定指針
このアーキテクチャーの例は、OpenStack Havana の現在のデフォルト
機能セットをベースに、安定性に重点を置いて選択しています。現在
OpenStack を本番環境で実行しているクラウドの多くは、同様の選択を
しているものと推定されます。
まず最初に、物理ノード上で実行するオペレーティングシステムを選択
する必要があります。OpenStack は複数の Linux ディストリビューショ
ンでサポートされていますが、開発コミュニティの大半で使用されてい
る Ubuntu 12.04 LTS (Long Term Support) を使用しました。このディ
ストリビューションは、他のディストリビューションと比較した場合、
機能の完全性が高く、将来のサポートプランが明確に立てられていま
す。
5
OpenStack 運用ガイド
February 1, 2016
デフォルトの Ubuntu OpenStack インストールパッケージは使用せず
に、Ubuntu Cloud Archive を使用することをお勧めします。Cloud
Archive は、Canonical がサポートするパッケージリポジトリです。こ
れにより、Ubuntu 12.04 を維持した状態で将来の OpenStack リリース
にアップグレードすることができます。
KVM は ハイパーバイザー として Ubuntu の選択を補完します。これら
はサポート面で対応する一対であり、OpenStack 開発コミュニティ (主
に KVM を使用する作成者) から集まる注目度が高いのも理由です。ま
た、機能が完全で、ライセンスの料金や制限がありません。
MySQL も同様の傾向に沿っています。最近所有権が移転したにも関わら
ず、このデータベースは OpenStack での使用では最も検証されており、
十分に文書化されています。SQLite は本番環境での使用には適してない
ため、デフォルトのデータベースでは対象外とします。
OpenStack では AMQP 互換の選択肢として ZeroMQ や Qpid などのサ
ポートが進んでいますが、RabbitMQ を選んだのは、その使いやすさと
本番環境で十分にテストされているのが理由です。また、RabbitMQ は
Compute Cell といった機能でサポートされている唯一の選択肢です。
メッセージキューは OpenStack システムで不可欠のコンポーネント
で、RabbitMQ 自体で元々サポートされているため、極めて簡単に実装で
きます。このため、RabbitMQ は クラスター構成にすることを推奨しま
す。
前章で述べたように、OpenStack Compute のネットワークにはいくつ
かの選択肢がありますが、高可用性には FlatDHCP で マルチホスト
ネットワークモードを使用して、OpenStack Compute ホスト毎に novanetwork デーモンを 1 つ実行することを推奨します。これにより、ネッ
トワーク障害が確実に各コンピュートホスト内に隔離される堅牢性の高
いメカニズムが提供され、各ホストはハードウェアのネットワークゲー
トウェイと直接通信することが可能となります。
ライブマイグレーション は、共有ストレージを使用することによってサ
ポートされます。分散ファイルシステムには NFS を使用します。
多くの小規模なデプロイメントでは、 Object Storage を仮想マシン
イメージのストレージのみに使用するとコストがかかり過ぎることが分
かっているため、OpenStack Image service (Glance) 内のファイルバッ
クエンドを選択しました。設計対象のクラウド環境に Object Storage
が含まれる場合には、バックエンドとして容易に追加できます。
Identity には SQL バックエンド を他のバックエンド (例: LDAP など)
よりも優先して選択しました。このバックエンドは、インストールが簡
単な上、頑強です。本ガイドの執筆者は、多くのインストールで既存の
6
OpenStack 運用ガイド
February 1, 2016
ディレクトリサービスをバインディングする必要があることを認識して
おり、利用可能な数々の選択肢 に記載の内容を慎重に理解するように警
告しています。
Block Storage (cinder) は、外部ストレージノードにネイティブで
インストールされ、LVM/iSCSI plug-in を使用します。大半の Block
Storage プラグインは、特定のベンダーの製品や実装と関連付けられて
おり、使用はそれらのハードウェアプラットフォームのユーザーに制限
されていますが、LVM/iSCSI はコモディティハードウェア上で堅牢性お
よび安定性があります。
7
OpenStack 運用ガイド
February 1, 2016
クラウドは OpenStack Dashboard がなくても稼働させることは可能です
が、クラウドとの対話だけでなく運用担当者のツールとしても不可欠な
要素と判断しました。また、ダッシュボードに採用されている Django
により、拡張機能 のための柔軟なフレームワークとなります。
OpenStack Networking を使用しない理由
このアーキテクチャー例では、OpenStack Networking は使用していませ
ん。neutron はマルチホストネットワークをまだサポートしておらず、
また対象となる組織 (大学/政府機関) ではパブリックでアクセス可能な
IPv4 アドレスを広範囲で利用できるのが理由です。
マルチホストネットワークを使用する理由
デフォルトの OpenStack デプロイメントでは、単一の nova-network
サービスがクラウド内 (通常はクラウドコントローラー) で実行され、
ネットワークアドレス変換 (NAT)、DHCP、DNS などのサービスをゲスト
インスタンスにd提供します。nova-network サービスを実行する単一の
ノードが停止した場合には、インスタンスにアクセスできなくなり、
またインスタンスはインターネットにアクセスできません。クラウドで
ネットワークトラフィックが過剰に送受信されると、nova-network サー
ビスを実行する単一ノードがボトルネックとなる可能性があります。
ヒント
マルチホスト とは、ネットワーク設定の高可用性オプション
です。このオプションでは、nova-network サービスが単一
のノードだけではなく、各コンピュートノードで実行されま
す。
詳細な説明
この参照アーキテクチャーは、複数のコンピュートノード、クラウドコ
ントローラー 1 台、インスタンスストレージ用の外部 NFS ストレー
ジサーバー 1 台、volume ストレージ用の OpenStack Block Storage
サーバー 1 台で構成されます。 ネットワークタイムサービス (Network
Time Protocol / NTP) は全ノードの時刻を同期します。ネットワークに
は、マルチホストモードの FlatDHCPManager を使用しています。この
アーキテクチャー例の論理図には、各ノードで実行されているサービス
が示されています。
8
OpenStack 運用ガイド
February 1, 2016
クラウドコントローラーは、ダッシュボード、API サービス、データ
ベース (MySQL)、メッセージキューサーバー (RabbitMQ)、コンピュー
トリソースを選択するスケジューラー (nova-scheduler)、Identity
Service (keystone、nova-consoleauth)、Image Service (glance-api、
glance-registry)、ゲストのコンソールアクセスのためのサービス、
ストレージリソースのスケジューラーを含む Block Storage Service
(cinder-api および cinder-scheduler) を実行します。
コンピュートノードには、コンピューティングリソースが保持されま
す。このアーキテクチャー例では、コンピュートノードで、ハイパー
バイザー (KVM)、libvirt (ノード間でのライブマイグレーションを可
能にするハイパーバイザー用ドライバー)、nova-compute、 nova-apimetadata (通常はマルチホストモードの場合のみ使用され、インスタン
ス固有のメタデータを取得する)、nova-vncproxy、nova-network を実行
します。
9
OpenStack 運用ガイド
February 1, 2016
ネットワークは、2 つのスイッチで構成され、1 つは管理/プライベート
トラフィック用、もう 1 つは Floating IP を含むパブリックアクセス
が対象です。この構成に対応するために、クラウドコントローラーおよ
びコンピュートノードで NIC を 2 枚を装備します。OpenStack Block
Storage および NFS ストレージサーバーは、プライベートネットワーク
にのみアクセスする必要があるので、必要な NIC は 1 枚ですが、可能
な場合には複数の NIC をボンディング構成で動作させることを推奨しま
す。Floating IP のアクセスは、インターネットに直結ですが、Flat IP
のアクセスは NAT 経由となります。ネットワークトラフィックの構想に
は、以下の図を利用してください。
さらなる拡張
この参照アーキテクチャーは、以下のように拡張することが可能です:
• 追加でクラウドコントローラーを増やす (11章メンテナンス、故障お
よびデバッグ [171] を参照)。
• OpenStack Storage Service を追加する (お使いのディストリビュー
ション向けの OpenStack インストールガイド で Object Storage の
章を参照してください)
• 追加で OpenStack Block Storage ホストを増やす (see 11章メンテナ
ンス、故障およびデバッグ [171] 参照)。
アーキテクチャー例: OpenStack
Networking
本章には、OpenStack Networking (別称: Neutron プロジェクト) を高
可用性環境で使用するアーキテクチャーの例を記載します。
10
OpenStack 運用ガイド
February 1, 2016
概要
高可用性環境は、水平スケールが可能な環境が必要な場合や、ノードに
障害が発生した場合にもクラウドの稼働を継続させたい場合に設置する
ことができます。以下のアーキテクチャー例では、 OpenStack Havana
の現在のデフォルト機能セットをベースとし、高可用性に重点を置いて
記載しました。
コンポーネント
コンポーネント
詳細
OpenStack リリース
Havana
ホストのオペレーティングシステム
Red Hat Enterprise Linux 6.5
OpenStack パッケージリポジトリ
Red Hat Distributed OpenStack (RDO)
ハイパーバイザー
KVM
データベース
MySQL
メッセージキュー
Qpid
ネットワークサービス
OpenStack Networking
テナントネットワークの分離
VLAN
Image service バックエンド
GlusterFS
Identity driver
SQL
Block Storage バックエンド
GlusterFS
設定指針
このアーキテクチャ例は、OpenStack Havana の現在のデフォルト機能
セットをベースに、高可用性に重点を置いて選択しています。このアー
キテクチャーは、現在 Red Hat の 企業内 OpenStack クラウドでデプロ
イされており、ホステッド共有サービスの運用に使用されています。ホ
ステッド共有サービスは、その性質上、高可用性が要求されます。
このアーキテクチャーコンポーネントは、以下のような理由で選択され
ています。
Red Hat Enterprise Linux
全物理ノードで実行可能なオペレー
ティングシステムを選択する必要が
あります。このアーキテクチャー例
は、信頼性、長期的なサポート、認
定テストが提供され、セキュリティ
強化されている Red Hat Enterprise
Linux をベースにしています。現
11
OpenStack 運用ガイド
February 1, 2016
在、OpenStack の採用に向けて移行中
の企業顧客には、通常このような利点
が要求されます。
RDO
Red Hat Distributed OpenStack パッ
ケージは、Red Hat Enterprise Linux
プラットフォーム用に構築された最新
の OpenStack リリースを容易にダウ
ンロードする方法を提供します。
KVM
KVM は、Red Hat Enterprise Linux
に最適なサポート対象ハイパーバイ
ザーです (また、ディストリビュー
ションにも含まれます)。機能が完成
されており、ライセンスの料金や制限
は課せられません。
MySQL
MySQL は、OpenStack 環境の全データ
ベースのデータベースバックエンド
として使用されます。MySQL は、Red
Hat Enterprise Linux に最適なサ
ポート対象データベースです (また、
ディストリビューションにも同梱さ
れています)。このデータベースは、
オープンソースで、拡張が可能な上、
メモリーの処理を効率的に行います。
Qpid
Apache Qpid は、Advanced Message
Queuing Protocol の標準との 100%
の互換性を提供し、ブローカーは C++
と Java の両方で利用可能です。
OpenStack Networking
OpenStack Networking は、レイヤー
2 (L2) ネットワークの分離やプロバ
イダーネットワークを含む高度なネッ
トワーク機能を提供します。
VLAN
仮想ローカルエリアネットワークを使
用してブロードキャスト制御、セキュ
リティ、物理レイヤーの透過性を提供
します。必要な場合には、VXLAN を使
用してアドレス空間を拡張します。
GlusterFS
GlusterFS は拡張可能なストレージを
提供します。環境の拡大に応じて、
12
OpenStack 運用ガイド
February 1, 2016
(高額なストレージアレイなどによる
制約を受けずに) ストレージノードを
継続的に追加することが可能です。
詳細な説明
ノードのタイプ
本セクションでは、OpenStack 環境を構成する異なるノードの内訳を記
載します。 ノードとは、オペレーティングシステムがプロビジョニング
された物理マシンで、その上に定義済みソフトウェアスタックを実行し
ます。 表1.1「ノードのタイプ」 [13] には、ノードの説明と仕様を記
載しています。
表1.1 ノードのタイプ
種別
説明
ハードウェアの例
コント
コントローラーノードは、 OpenStack 環境が機能するた モデル: Dell R620
ローラー めに必要な管理ソフトウェアサービスを実行します。これ
CPU: 2x Intel® Xeon®
らのノードは、以下のような役割を果たします。
CPU E5-2620 0 @ 2.00
• ユーザーがアクセスするフロントドアに加えて、環境内 GHz
その他すべてのコンポーネントが通信する API サービ
メモリー: 32 GB
スを提供します。
• 全コントローラーノードが使用されるように Pacemaker ディスク: 300 GB 10000
と HAProxy を利用して仮想 IP および負荷分散機能を RPM SAS ディスク x 2
提供して、多数のサービスを高可用性で実行します。
ネットワーク: 10G の
ネットワークポート x 2
• 高可用性の「インフラストラクチャー」サービス (全
サービスの基盤となる MySQL や Qpid など) を提供し
ます。
• ホストでも実行されるサービスを介して、いわゆる「永
続ストレージ」を提供します。この永続ストレージは、
信頼性のためにストレージノードにバッキングされま
す。
図1.3「コントローラーノード」 [19] を参照してくださ
い。
コン
コンピュートノードは、OpenStack 内の仮想マシンインス モデル: Dell R620
ピュート タンスを実行します。コンピュートノードは、以下のよう
CPU: 2x Intel® Xeon®
な役割を果たします。
CPU E5-2650 0 @ 2.00
• それらのインスタンスを円滑に稼働するために必要な最 GHz
低限のサービスを実行します。
メモリー: 128 GB
• ノードの障害発生時に仮想マシンの移行やインスタンス
のリカバリができないように、仮想マシンにノード上の ディスク: 600 GB 10000
RPM SAS ディスク x 2
ローカルストレージを使用します。
ネットワーク: 10G ネッ
トワークポート x 4 (将
13
OpenStack 運用ガイド
種別
February 1, 2016
説明
ハードウェアの例
図1.4「コンピュートノード」 [20] を参照してくださ
い。
来を保証する拡張性のた
め)
ストレー ストレージノードは、環境に必要な全データを保管しま
ジ
す。これには、Image service ライブラリ内のディスク
イメージや、Block Storage によって作成された永続ス
トレージボリュームが含まれます。ストレージノードは
GlusterFS テクノロジーを使用してデータの高可用性とス
ケーラビリティを確保します。
図1.6「ストレージノード」 [22] を参照してください。
モデル: Dell R720xd
CPU: 2x Intel® Xeon®
CPU E5-2620 0 @ 2.00
GHz
メモリー: 64 GB
ディスク: 500 GB 7200
RPM SAS ディスク x 2
および 600 GB 10000
RPM SAS ディスク x 24
RAID コントローラー:
PERC H710P Integrated
RAID Controller、1 GB
NV キャッシュ
ネットワーク: 10G の
ネットワークポート x 2
ネット
ワーク
ネットワークノードは、ユーザーがパブリックまたはプラ
イベートネットワークを作成し、仮想マシンを外部ネット
ワークにアップリンクするために必要なすべての仮想ネッ
トワーキングを実行する役割を果たします。ネットワーク
ノードは以下のような操作を実行します。
モデル: Dell R620
CPU: 1x Intel® Xeon®
CPU E5-2620 0 @ 2.00
GHz
• OpenStack 上で実行されているインスタンス用の唯一の メモリー: 32 GB
送受信ポイントを形成します。
ディスク: 300 GB 10000
• 環境の全ネットワークサービスを実行します。ただし、 RPM SAS ディスク x 2
ネットワーク API サービス (コントローラーノードで
ネットワーク: 10G ネッ
実行される) を除きます。
トワークポート x 5
図1.5「ネットワークノード」 [21] を参照してくださ
い。
ユーティ ユーティリティノードは、環境を稼働させ、その環境を実 モデル: Dell R620
リティ
行しているハードウェア/OS/ソフトウェアを維持管理する
のに必要な多数の基本的なシステム管理機能を提供するた CPU: 2x Intel® Xeon®
CPU E5-2620 0 @ 2.00
めに、内部管理スタッフのみが使用します。
GHz
これらのノードは、プロビジョニング、設定管理、モニタ
リング、GlusterFS 管理ソフトウェアなどのサービスを実 メモリー: 32 GB
行します。拡張の必要はありませんが、これらのマシンは
ディスク: 500 GB 7200
通常バックアップされます。
RPM SAS ディスク x 2
ネットワーク: 10G の
ネットワークポート x 2
ネットワークのレイアウト
ネットワークには、環境内の全ハードウェア用の管理デバイスがすべて
含まれます (例: ハードウェアノード用の Dell iDrac7 デバイスやネッ
14
OpenStack 運用ガイド
February 1, 2016
トワークスイッチ用の管理インターフェースの追加による) 。ネット
ワークは、ハードウェア問題の診断またはリカバリを実行する場合にの
み内部スタッフがアクセスします。
OpenStack 内部ネットワーク
このネットワークは、OpenStack の管理機能およびトラフィックに使用
されます。これには、物理ノードのプロビジョニングに必要なサービス
(pxe、tftp、kickstart)、OpenStack API およびメッセージを使用する
様々な OpenStack ノードタイプの間のトラフィック (例: nova-compute
から keystone への通信や　cinder-volume から nova-api への通信な
ど)、 Gluster プロトコルによる配下のストレージ層へのストレージ
データの全トラフィックなどが含まれます。全物理ノードで、少なくと
も 1 つのネットワークインターフェース (通常は eth0) がこのネット
ワークに設定されます。他の VLAN からのこのネットワークへのアクセ
スは、ポート 22 でのみで可能です (マシンを管理するための ssh アク
セス)。
15
OpenStack 運用ガイド
February 1, 2016
パブリックネットワーク
このネットワークは、以下の要素の組み合わせです:
• コントローラーノード上のパブリックインターフェースの IP アドレ
ス (エンドユーザーが OpenStack サービスにアクセスするのに使用)
• OpenStack Networking が Floating IP に使用する、パブリックに
ルーティング可能な IPv4 ネットワークアドレスの範囲。IPv4 アドレ
スへのアクセスは制限される可能性があります。IPv4 アドレスの範囲
を大きくする必要はありません。
• OpenStack 内に作成されるプライベートネットワーク用のルーター
このネットワークは、ユーザーが OpenStack インターフェースにアクセ
スできるようするためにコントローラーノードに接続され、パブリック
でルーティング可能なトラフィックの機能を仮想マシンに提供するため
にネットワークノードに接続されます。また、このネットワークは、公
開する必要のある任意のユーティリティサービス (システムの監視など)
にアクセスできるようにするために、ユーティリティマシンにも接続さ
れます。
仮想マシントラフィックネットワーク
これは、パブリックにはルーティングできない閉じたネットワークで、
単に OpenStack 内の仮想マシン間のトラフィックや、パブリックネット
ワークへの外向きの L3 ルート (および仮想マシンに戻る接続のための
Floating IP) を提供するネットワークノードと仮想マシンと間 のトラ
フィックのためのプライベートの内部ネットワークに使用されます。こ
のネットワークは閉じているため、他とは異なるアドレス空間を使用し
て、その区別を明確に定義しています。このネットワークに接続する必
要があるのは、Compute ノードと OpenStack Networking ノードのみで
す。
ノードの接続性
以下のセクションでは、ノードを異なるネットワークに接続する方法 (
「ネットワークのレイアウト」 [14] を参照) と、ノードをネットワー
クに接続する際に他に考慮すべき点 (例: ボンディング) について説明
します。
初期デプロイメント
デプロイメントの複雑度と所要時間を最小限に抑えるためには、初め
に、接続性を単純かつ簡潔に保つことを中心に接続の設定を展開する必
16
OpenStack 運用ガイド
February 1, 2016
要があります。図1.1「基本ノードデプロイメント」 [17] に示したデ
プロイメントでは、全コンピュートノードに 10G の接続を 1 つずつ提
供する一方で、適切なノードにはボンディングを活用してパフォーマン
スを最大化することを目的としています。
図1.1 基本ノードデプロイメント
パフォーマンスを最大化するための接続性
基本レイアウトのネットワークパフォーマンスが十分でない場合に
は、図1.2「パフォーマンスノードのデプロイメント」 [18] に移行す
ることができます。このレイアウトでは、環境内の全インスタンスに
10G のネットワークリンクを 2 つ提供するだけでなく、ストレージ層
にさらなるネットワーク帯域幅を提供し、パフォーマンスを最大化しま
す。
17
OpenStack 運用ガイド
February 1, 2016
図1.2 パフォーマンスノードのデプロイメント
ノードの図
以下の図 (図1.3「コントローラーノード」 [19] through 図1.6「スト
レージノード」 [22]) には、異なるタイプのノードについての論理的
情報が含まれます。この図には、実行されるサービスやそれらがどのよ
うに相互に対話するかが示されています。また、サービスの可用性とス
ケーラビリティがどのように実現されるかについても図示しています。
18
OpenStack 運用ガイド
February 1, 2016
図1.3 コントローラーノード
19
OpenStack 運用ガイド
February 1, 2016
図1.4 コンピュートノード
20
OpenStack 運用ガイド
February 1, 2016
図1.5 ネットワークノード
21
OpenStack 運用ガイド
February 1, 2016
図1.6 ストレージノード
コンポーネントの設定例
表1.2「サードパーティーコンポーネントの設定」 [22] と 表
1.3「OpenStack component configuration」 [25] にサードパーティー
と OpenStack のコンポーネント両方に関する設定例と考慮事項がありま
す。
表1.2 サードパーティーコンポーネントの設定
コン
ポーネ
ント
チューニング
可用性
拡張性
MySQL
binlog-format = row
マスター/マスターレプリ
ケーション。しかしなが
ら、両方のノードは同時
に使用されません。レプ
リケーションは、すべて
のノードができる限り最
新状態を維持します (非
同期のレプリケーション
は、完全な状態が維持でき
Not heavily considered.
Once load on the MySQL
server increases enough
that scalability needs
to be considered,
multiple masters or a
master/slave setup can
be used.
22
OpenStack 運用ガイド
コン
ポーネ
ント
チューニング
February 1, 2016
可用性
拡張性
ないことを意味します)。
データベースへの接続
は、Pacemaker の仮想 IP
のみに行われます。これに
より、マスター/マスター
レプリケーションで発生す
るほとんどの問題を避けら
れます。
Qpid
maxconnections=1000workerthreads=20connectionbacklog=10, sasl
security enabled
with SASL-BASIC
authentication
Qpid is added as
a resource to the
Pacemaker software that
runs on Controller nodes
where Qpid is situated.
This ensures only one
Qpid instance is running
at one time, and the
node with the Pacemaker
virtual IP will always
be the node running
Qpid.
Not heavily considered.
However, Qpid can
be changed to run on
all controller nodes
for scalability and
availability purposes,
and removed from
Pacemaker.
HAProxy maxconn 3000
HAProxy is a software
layer-7 load balancer
used to front door all
clustered OpenStack
API components and
do SSL termination.
HAProxy can be added
as a resource to the
Pacemaker software that
runs on the Controller
nodes where HAProxy is
situated. This ensures
that only one HAProxy
instance is running
at one time, and the
node with the Pacemaker
virtual IP will always
be the node running
HAProxy.
Not considered. HAProxy
has small enough
performance overheads
that a single instance
should scale enough for
this level of workload.
If extra scalability
is needed, keepalived
or other Layer-4
load balancing can be
introduced to be placed
in front of multiple
copies of HAProxy.
MemcachedMAXCONN="8192"
CACHESIZE="30457"
Memcached is a fast
in-memory key-value
cache software that
is used by OpenStack
components for caching
data and increasing
performance. Memcached
runs on all controller
nodes, ensuring that
should one go down,
another instance of
Memcached is available.
Not considered. A
single instance of
Memcached should be
able to scale to the
desired workloads. If
scalability is desired,
HAProxy can be placed
in front of Memcached
(in raw tcp mode)
to utilize multiple
Memcached instances for
scalability. However,
23
OpenStack 運用ガイド
コン
ポーネ
ント
チューニング
February 1, 2016
可用性
拡張性
this might cause cache
consistency issues.
PacemakerConfigured to use
corosync andcman as a
cluster communication
stack/quorum manager,
and as a two-node
cluster.
Pacemaker とは、コント
ローラーノードおよびネッ
トワークノードで実行され
ているサービスの可用性を
確保するために使用するク
ラスタリングソフトウェア
です:
If more nodes need to
be made cluster aware,
Pacemaker can scale to
64 nodes.
• Pacemaker は、クラスタ
リングソフトウェアで
あるため、基盤となる
corosync および cman
を活用して、ソフトウェ
ア自体が自らの可用性を
処理します。
• GlusterFS ネイティブ
クライアントを使用する
場合には、そのクライア
ントは初回接続後にノー
ドに関する全情報を認識
し、クライアント側の障
害を迂回するように自動
的にルーティングするた
め、仮想 IP は必要あり
ません。
• NFS または SMB のアダ
プターを使用する場合に
は、GlusterFS ボリュー
ムをマウントする仮想
IP が必要となります。
GlusterFSglusterfs performance
profile "virt" enabled
on all volumes. Volumes
are setup in two-node
replication.
Glusterfs is a clustered
file system that is run
on the storage nodes
to provide persistent
scalable data storage
in the environment.
Because all connections
to gluster use the
gluster native mount
points, the gluster
instances themselves
provide availability and
failover functionality.
24
The scalability of
GlusterFS storage can
be achieved by adding in
more storage volumes.
OpenStack 運用ガイド
February 1, 2016
表1.3 OpenStack component configuration
Component
Node
type
Tuning
Availability
Scalability
Dashboard
Controller
Configured to
(horizon)
use Memcached
as a session
store, neutron
support is enabled,
can_set_mount_point
= False
The dashboard is run on
all controller nodes,
ensuring at least
one instance will be
available in case of
node failure. It also
sits behind HAProxy,
which detects when
the software fails and
routes requests around
the failing instance.
The dashboard is run
on all controller
nodes, so scalability
can be achieved with
additional controller
nodes. HAProxy allows
scalability for the
dashboard as more nodes
are added.
Identity
Controller
Configured to
(keystone)
use Memcached for
caching and PKI for
tokens.
Identity is run on
all controller nodes,
ensuring at least
one instance will be
available in case of
node failure. Identity
also sits behind
HAProxy, which detects
when the software fails
and routes requests
around the failing
instance.
Identity is run on
all controller nodes,
so scalability can
be achieved with
additional controller
nodes. HAProxy allows
scalability for Identity
as more nodes are added.
Image Controller
/var/lib/glance/
service
images is a
(glance)
GlusterFS native
mount to a Gluster
volume off the
storage layer.
The Image service is
run on all controller
nodes, ensuring at
least one instance will
be available in case of
node failure. It also
sits behind HAProxy,
which detects when
the software fails and
routes requests around
the failing instance.
The Image service is
run on all controller
nodes, so scalability
can be achieved with
additional controller
nodes. HAProxy allows
scalability for the
Image service as more
nodes are added.
ComputeController,
Qpid を使用
(nova) Computeするように設
定、qpid_heartbeat
= 10、 Memcached を
キャッシュに使用する
ように設定、 libvirt
を使用するように設
定、 neutron を使用
するように設定
nova
The nova API, scheduler,
API、scheduler、objectstore、cert、consoleauth、conductor、
objectstore, cert,
および vncproxy のサー consoleauth, conductor,
ビスは、全コントロー
and vncproxy services
ラーノードで実行され、 are run on all
ノードに障害が発生し
controller nodes,
た場合には少なくとも
so scalability can
1 インスタンスが利用
be achieved with
可能となるようにしま
additional controller
す。Compute は、ソフ
nodes. HAProxy allows
nova-consoleauth が トウェアの障害を検出し scalability for Compute
セッション管理に
て、障害の発生したイン as more nodes are added.
Memcached を使用す
スタンスを迂回するよう The scalability of
るように設定 (複数の に要求をルーティングす services running on the
コピーが存在可能で、 る HAProxy の背後に配置 compute nodes (compute,
ロードバランサーで実 されます。
conductor) is achieved
行できる)。
25
OpenStack 運用ガイド
Component
Node
type
February 1, 2016
Tuning
Block Controller
Configured to use
Storage
Qpid, qpid_heartbeat
(cinder)
= 10, configured
to use a Gluster
volume from the
storage layer as
the back end for
Block Storage, using
the Gluster native
client.
Availability
Scalability
コンピュートノード
上で実行される novacompute サービスと
nova-conductor サービ
スは、そのノード上での
みサービスを実行する必
要があるので、これらの
サービスの可用性はその
ノードの稼働状態と密接
に連結しています。コン
ピュートノードが稼働し
ている限りは、そのノー
ド上で必要なサービスが
実行されます。
linearly by adding in
more compute nodes.
Block Storage API,
scheduler, and volume
services are run on
all controller nodes,
ensuring at least
one instance will be
available in case of
node failure. Block
Storage also sits
behind HAProxy, which
detects if the software
fails and routes
requests around the
failing instance.
Block Storage API,
scheduler and volume
services are run on
all controller nodes,
so scalability can
be achieved with
additional controller
nodes. HAProxy allows
scalability for Block
Storage as more nodes
are added.
OpenStack
Controller,
Configured
OpenStack Networking
Networking
Compute,
to use QPID,
Service は、全コント
(neutron)
Networkqpid_heartbeat =
ローラーノード上で実行
10, kernel namespace され、ノードの障害が発
support enabled,
生した場合に少なくとも
tenant_network_type 1 インスタンスが利用可
= vlan,
能となるようにします。
allow_overlapping_ips また、このサービスは、
= true,
ソフトウェアの障害を検
tenant_network_type 出して、障害の発生した
= vlan,
インスタンスを迂回する
bridge_uplinks
ように要求をルーティン
= br-ex:em2,
グする HAProxy の背後に
bridge_mappings =
配置されます。
physnet1:br-ex
OpenStack Networking
の ovs-agent、l3agent、dhcp-agent、お
よび metadata-agent の
サービスは、ネットワー
クノード上で Pacemaker
内の lsb リソースとし
て稼働します。これは、
ネットワークノードに障
害が発生した場合にサー
ビスが別のノードで稼働
26
The OpenStack Networking
server service is run
on all controller
nodes, so scalability
can be achieved with
additional controller
nodes. HAProxy allows
scalability for
OpenStack Networking as
more nodes are added.
Scalability of services
running on the network
nodes is not currently
supported by OpenStack
Networking, so they are
not be considered. One
copy of the services
should be sufficient
to handle the workload.
Scalability of the ovsagent running on compute
nodes is achieved by
adding in more compute
nodes as necessary.
OpenStack 運用ガイド
Component
Node
type
February 1, 2016
Tuning
Availability
Scalability
し続けることを意味しま
す。最後に ovs-agent
サービスも全コンピュー
トノードで稼働し、コン
ピュートノードに障害が
発生した場合に、その他
のノードが、そこで実行
されているサービスのコ
ピーを使用して機能し続
けます。
アーキテクチャー例についての章の結び
数多くの考慮事項およびオプションがあるため、本セクションで
は、OpenStack をお試しいただくための明確に記載した検証済みの方
法を提供するように構成しています。本セクションに記載した以外の情
報をお探しの場合には、付録A 事例 [277]、OpenStack Installation
Guides、または OpenStack User Stories page をご確認ください。
27
OpenStack 運用ガイド
February 1, 2016
第2章 プロビジョニングとデプロ
イメント
自動デプロイメント ..........................................
自動環境設定 ................................................
リモート管理 ................................................
OpenStack のプロビジョニングおよびデプロイメントの概念 .......
まとめ ......................................................
29
33
33
34
34
クラウドのスケーラビリティにおける重要な部分の一つは、クラウドを
運用するのに必要な労力にあります。クラウドの運用コストを最小化す
るために、Puppet や Chef などの設定管理システムを使用して、自動化
されたデプロイメントおよび設定インフラストラクチャーを設定、使用
してください。これらのシステムを統合すると、工数やオペレーターの
ミスを大幅に減らすことができます。
このインフラストラクチャーには、オペレーティングシステ
ムの初期設定を自動にインストールするシステムや、全サー
バーを自動的かつ一元的に連携、設定するシステムが含まれて
おり、手作業やエラーの発生する可能性を減らします。例え
ば、Ansible、CFEngine、Chef、Puppet、Salt などのシステムで
す。OpenStack を使用して、OpenStack をデプロイすることも可能で
す。これは、TripleO (OpenStack 上の OpenStack) という愛称で呼ばれ
ています。
自動デプロイメント
自動のデプロイメントシステムは、物理ラッキング、MAC から IP アド
レスの割当、電源設定など、必要最小限の手作業のみで、介入なしに新
規サーバー上にオペレーティングシステムのインストールと設定を行い
ます。ソリューションは通常、PXE ブートや TFTP サーバー関連のラッ
パーに依存して基本のオペレーティングシステムをインストールして、
次に自動設定管理システムに委譲されます。
Ubuntu と Red Hat Enterprise Linux にはいずれも、ネットワークブー
ト後に使用可能なpreseed や kickstart といった、オペレーティングシ
ステムを設定するための仕組みがあります。これらは、典型的には自動
環境設定システムのブートストラップに使用されます。他の方法として
は、systemimager のようなイメージベースのオペレーティングシステ
ムのデプロイメント手法を使うこともできます。これらの手法はどちら
29
OpenStack 運用ガイド
February 1, 2016
も、物理インフラストラクチャーと制御サービスを分離するために仮想
マシンを実行する場合など、仮想化基盤と合わせて使用できます。
デプロイメントプランを作成する場合、デプロイメント後の修正は困難
であるため、いくつかの重要な分野にフォーカスを当ててください。次
の 2 章で以下の設定内容について説明していきます。
• スケーラビリティ確保に向けたディスクのパーティショニングおよび
ディスク配列設定
• PXE ブート用のネットワーク設定
ディスクのパーティショニングと RAID
オペレーティングシステムの基盤は、オペレーティングシステムがイン
ストールされるハードドライブです。
サーバーのハードディスクに対して、以下の環境設定を完了させなけれ
ばなりません。
• パーティショニング。以下に説明されている通り、オペレーティング
システムと Swap 領域のレイアウトにおける柔軟性がはるかに高くに
なります。
• 使用可能なディスクの数をもとに、RAID 配列 (RAID は Redundant
Array of Independent Disks の略) に追加します。 こうすること
で、クラウドが大きくなった場合も容量を追加できます。オプション
は、以下で詳しく説明しています。
最もシンプルに使用を開始できるオプションは、１台のハードディスク
を２つのパーティションに分割することです。
• ファイルやディレクトリを格納するファイルシステム。システムを起
動、実行する root パーティションなど、全データが設置される場
所。
• プロセス用にメモリーを空ける Swap 領域。物理ディスクから独立し
た、スワップのみに使用される領域。
通常、本番環境のクラウドでは、1 つのディスクに問題が発生した場
合、別のディスクが必ず稼働するようにするため、RAID は、このシン
プルな、ドライブ 1 つの設定では使用されません。本番環境では、ディ
スクを 1 つ以上使用します。ディスク数により、どのようなタイプの
RAID 配列を構築するか決定します。
30
OpenStack 運用ガイド
February 1, 2016
以下に挙げる複数のディスクの選択肢から選ぶことを推奨します。
オプショ
ン 1
図2.1「ドライブのパーティション設定」 [31] にあるよう
に、すべてのドライブを同じように並列してパーティショニ
ングにします。
このオプションでは、パーティションごとに異なる RAID ア
レイにおくことができます。例えば、ディスク 1 とディス
ク 2 のパーティション 1 を /boot パーティションのミラー
として、すべてのディスクのパーティション 2 をルートパー
ティションのミラーとして、すべてのディスクのパーティ
ション 3 を RAID10 アレイの上の cinder-volumes の LVM
パーティションとして割り当てることができます。
図2.1 ドライブのパーティション設定
この例では、ディスク 3 と 4 のパーティション 1 のように
未使用のパーティションが残る可能性もありますが、このオ
プションにより、ディスク領域の使用状況を最大化すること
ができます。すべてのディスクがすべてのタスクで利用され
るため、I/O のパフォーマンスが問題になる可能性がありま
す。
オプショ
ン 2
すべてのローディスクを 1 つの大きな RAID 配列に追
加します。ここでは、ソフトウェアベースでもハード
ウェアベースでも構いません。この大きなRAID 配列を
boot、root、swap、LVM 領域に分割します。この選択肢はシ
ンプルですべてのパーティションを利用することができます
が、I/O性能に悪影響がでる可能性があります。
オプショ
ン 3
全ディスク領域を特定のパーティションに割り当てます。
例えば、ディスク 1 と 2 すべてを RAID 1 ミラーとして
boot、root、swapパーティションに割り当てます。そして、
ディスク 3 と 4 すべてを、同様に RAID 1 ミラーとしてLVM
パーティションに割り当てます。I/O は専用タスクにフォー
31
OpenStack 運用ガイド
February 1, 2016
カスするため、ディスクの I/O は良くなるはずです。しか
し、LVM パーティションははるかに小さくなります。
ヒント
パーティショニング自体を自動化可能であることが分かりま
す。例えば、MIT は Fully Automatic Installation (FAI)
を使用して、初期の PXE ベースのパーティション分割を行
い、min/max およびパーセントベースのパーティショニング
を組み合わせてインストールしていきます。
多くのアーキテクチャーの選択肢と同様に、環境により適切なソリュー
ションは変わって来ます。既存のハードウェアを使用する場合、サー
バーのディスク密度を把握し、上記のオプションをもとに意思決定して
いきます。調達プロセスを行っている場合、ユーザー要件などもハード
ウェア購入決定の一助となります。ここでは AT&T の Web 開発者にカス
タムの環境を提供するプライベートクラウドの例をあげています。この
例は、特定のデプロイメントであるため、既存のハードウェアや調達機
会はこれと異なる可能性があります。AT&T は、デプロイメントに 3 種
類のハードウェアを使用しています。
• コントローラーノードのハードウェア。ステートレスの OpenStack
API サービスすべてに使用します。メモリー約 32-64GB、接続された
容量の小さいディスク、プロセッサー 1 つ、6-12 個程度のコア。
• コンピュートノードのハードウェア。通常、メモリー 256 GB または
144 GB、プロセッサー 2 個、コア 24 個、通常 RAID 5 設定のダイレ
クトアタッチストレージ (DAS)。
• ストレージノードのハードウェア。通常、ラックスペース効率を確保
しつつも、ディスク容量のコストが GB ベースで最も低く最適化され
ています。
ここでも、環境によって適したソリューションが変わります。スペース
使用状況、シンプルさ、I/O パフォーマンスの長所、短所をベースに意
思決定していく必要があります。
ネットワーク設定
ネットワーク設定は、本書でも複数の箇所で取り上げられている大きい
トピックです。ここでは、お使いのサーバが PXEブートでき、デプロイ
メントサーバと正常に通信できることを確認しておいてください。.
例えば、PXE ブートの際には、通常は VLAN の設定は行えません。さら
に、通常は bonding された NIC から PXE ブートを行うこともできませ
32
OpenStack 運用ガイド
February 1, 2016
ん。このような状況の場合、クラウド内でのみ通信できるネットワーク
で、シンプルな 1Gbps のスイッチを使うことを検討してください。
自動環境設定
自動環境設定管理の目的は、人間の介在なしにシステムの一貫性を確
保、維持することにあります。毎回、同じクラウド環境を繰り返し作る
ために、デプロイメントにおける一貫性を確保します。自動環境設定管
理ツールを正しく利用することによって、デプロイメントと環境設定の
変更を伝搬する作業を簡素化するだけでなく、クラウドシステムのコン
ポーネントが必ず特定の状態にあるようにすることができます。
These tools also make it possible to test and roll back changes,
as they are fully repeatable. Conveniently, a large body of work
has been done by the OpenStack community in this space. Puppet, a
configuration management tool, even provides official modules for
OpenStack projects in an OpenStack infrastructure system known
as Puppet OpenStack . Chef configuration management is provided
within https://git.openstack.org/cgit/openstack/openstack-chefrepo. Additional configuration management systems include Juju,
Ansible, and Salt. Also, PackStack is a command-line utility for
Red Hat Enterprise Linux and derivatives that uses Puppet modules
to support rapid deployment of OpenStack on existing servers over
an SSH connection.
設定管理システムの不可欠な部分は、このシステムが制御する項目で
す。自動管理をする項目、しない項目をすべて慎重に検討していく必要
があります。例えば、ユーザーデータが含まれるハードドライブは自動
フォーマットは必要ありません。
リモート管理
経験上、多くのオペレーターはクラウドを動かすサーバのそばにいるわ
けではありませんし、多くの人が必ずしも楽しんでデータセンターに訪
問してるわけではありません。OpenStackは、完全にリモート設定できる
はずですが、計画通りにいかないこともあります。
この場合、OpenStack が動くノードに対して外側からアクセスできるよ
うにすることが重要です。ここでは、IPMIプロトコルが事実上標準と
なっています。完全自動のデータセンタを実現するために、IPMIをサ
ポートしたハードウェアを入手することを強く推奨します。
さらに、リモート電源管理装置も検討してください。通常、IPMI はサー
バーの電源状態を制御しますが、サーバーが接続されている PDU にリ
33
OpenStack 運用ガイド
February 1, 2016
モートアクセスできれば、すべてが手詰まりに見えるような状況で非常
に役に立ちます。
OpenStack のプロビジョニングおよびデ
プロイメントの概念
作成するクラウドのユースケースを理解することで時間を節約すること
あできます。OpenStack のユースケースはさまざまで、オブジェクト
ストレージのみのもの、開発環境設定を加速するために事前設定された
コンピュートリソースが必要なもの、プライベートネットワークでテナ
ントごとにセキュリティが確保されたコンピュートリソースの迅速にプ
ロビジョニングするものもあります。ユーザーは、レガシーアプリケー
ションが継続して実行されるように、非常に冗長化されたサーバーが必
要な場合もあります。おそらく、時間をかけてこれらのクラスターを追
加するのが目的ではなく、クラウドの耐障害性を確保したかたちで、複
数のインスタンス上で実行するために、レガシーのアプリケーションを
構築するのが目的の場合もあります。ユーザーによっては、負荷の高い
Windows サーバーを使用するため、スケーリングを考慮する必要がある
と指定する場合もあるでしょう。
すでに設置済みのハードウェアに最適な方法で使用されていることを
チェックすることで、リソースを節約することができます。高濃度のス
トレージハードウェアがあるとします。このハードウェアをフォーマッ
トして、OpenStack Object Storage 用にサーバーの用途を変更すること
ができます。ユーザーからのこのような検討やインプットすべてをベー
スにすることで、ユースケースやデプロイメントプランの作成が容易に
なります。
ヒント
OpenStack の導入に関する詳細は、Canonical, Cisco,
Cloudscaling, IBM, Metacloud, Mirantis, Piston,
Rackspace, Red Hat, SUSE, SwiftStack などの企業の、サ
ポートされドキュメント化された事前設定およびパッケージ
化済みのインストーラーを確認してください。
まとめ
プロビジョニングやデプロイメントでの意思決定は、クラウドの日次、
週次、月次のメンテナンスに影響を与えます。設定管理は時が経つにつ
れ進化することができます。しかし、デプロイメント、ディスクのパー
34
OpenStack 運用ガイド
February 1, 2016
ティショニング、ネットワーク設定を事前に選択するには、さらに検
討、設計が必要になります。
35
OpenStack 運用ガイド
February 1, 2016
第3章 クラウドコントローラーの
デザインとクラウド管理
ハードウェアの考慮事項 ......................................
サービスの分離 ..............................................
データベース ................................................
メッセージキュー ............................................
コンダクターサービス ........................................
Application Programming Interface (API) .....................
API 拡張 ....................................................
スケジューリング ............................................
イメージ ....................................................
ダッシュボード ..............................................
認証と認可 ..................................................
ネットワークの考慮事項 ......................................
39
40
40
41
41
42
42
43
43
44
44
45
OpenStackはすべてのサービスが広く分散できるよう水平方向に大規模に
スケーリングできるように設計されています。しかし、このガイドでは
シンプルにクラウドコントローラーの利用についてより中心的な性質を
持つサービスについて議論する事にしました。クラウドコントローラー
という言葉はその概念をシンプルに表現した物に過ぎません。実際には
あなたはクラウドコントローラーは冗長構成としてどのノードが障害と
なっても他のノードで運用ができるような設計にデザインします。実際
にはクラウドコントローラーのタスクは1つ以上のノードにまたがって展
開されます。
クラウドコントローラは、複数ノードで構成されるOpenStack構成に対す
る集中管理機能を提供します。典型的には、クラウドコントローラは認
証および、メッセージキューを通じたメッセージのやりとりを管理しま
す。
多くの構成では、クラウドコントローラーはシングルノードで構成され
ています。しかし、高可用性のためには、この章で取り上げるいくつか
の事項を考慮する必要があります。
クラウドコントローラーはクラウドの次のサービスを管理します:
データベース
ユーザとインスタンスの現在の状態をトラッ
キングします。例えば、一般的なデータベー
スでは1つのデータベースインスタンスは
サービス毎に管理されます。
37
OpenStack 運用ガイド
February 1, 2016
メッセージキューサービ
ス
サービスのためのすべてのAMQP（Advavnced
Message Queue Protocol）メッセージは
キューブローカーによって送受信されます。
コンダクターサービス
データベースリクエストのプロクシ
アイデンティティ管理の
ための認証と認可
ある特定のクラウドリソースで誰が何をしよ
うとしているか示します。しかし、クオータ
管理は全体のサービスに展開されます。
イメージ管理サービス
クラウド内で起動するための各メタデータが
付属したイメージデータを蓄え、提供します
スケジュールサービス
どのリソースを最初に使用するかを示しま
す。例えば、インスタンスをどこで起動する
かをアルゴリズムに乗っ取って展開します。
ユーザーダッシュボード
利用ユーザ用のOpenStackクラウドサービス
のウェブインターフェースを提供します。
APIエンドポイント
それぞれのサービス用のAPIアクセスを提供
します。APIエンドポイントカタログの場所
は Identity サービスが管理しています。
我々の例では、クラウドコントローラはnova-* コンポーネントの集まり
で、それらは認証のようなサービスとのやり取りや、データベース内の
情報の管理、キューを通したストレージ ワーカーコンピュートノードと
のコミュニケーション、APIアクセス、などといったクラウド全体の状態
管理を受け持っています。それぞれのサービスは可用性やスケーラビリ
ティを考慮して別々のノードへ分離する事ができます。
他の例として、コントローラーをクラスタとして構成し1つはアクティ
ブ、もう一つはスタンバイとして冗長ノードが以下のような機能を提供
できるように複数のサーバを使用する事ができます。
• APIリクエスト用のフロントエンドウェブ、インスタンスをどのノード
で起動するかを決定するスケジューラ、Identity サービス、ダッシュ
ボード
• データベースとメッセージキューサーバ（例:MySQL、RabbitMQ）
• イメージ管理のための Image serviceイメージサービス
クラウドコントローラの設計は無数にあります、クラウドコントローラ
の設計の助けとして更なる考慮事項をお読みください。
38
OpenStack 運用ガイド
February 1, 2016
ハードウェアの考慮事項
クラウドの大きさやタイプによってハードウェアを指定したいかもしれ
ませんが、クラウドコントローラーのハードウェアはコンピュートノー
ドと同じ物を利用する事ができます。
クラウドコントローラーが管理するすべての、または一部のサービス、
たとえばメッセージキューに対して仮想マシンを使うことも可能です。
このガイドでは、すべてのサービスが直接クラウドコントローラー上で
実行されるものと仮定します。
表3.1「クラウドコントローラーのハードウェアサイジングに関する考慮
事項」 [39] クラウドコントローラー設計のハードウェアサイジングに
おける一般的な考慮事項
表3.1 クラウドコントローラーのハードウェアサイジングに関
する考慮事項
考慮事項
派生問題
同時に何インスタンス データベースサーバーを負荷に応じてサイジングしてください。も
実行されますか？
し、多数のインスタンスが同時に状態を報告したり、CPU能力が必要な
新規インスタンス起動のスケジューリングを行う場合は、１台のクラ
ウドコントローラーを超えてスケールアウトしてください。
同時にコンピュート
メッセージキューが正しくリクエストを処理することを保証し、適切
ノードが何ノード実行 にサイジングしてください。
されますか？
どのくらいの数のユー もし多数のユーザが複数のリクエストを発行するのであれば、クラウ
ザがAPIにアクセスし ドコントローラーがそれらを扱えるよう、CPU負荷を確認してくださ
ますか？
い。
REST APIに直接アクセ ダッシュボードは、APIアクセスよりもさらに多くのリクエストを発
スに対してどのくらい 行します。そのため、もしユーザに対するインタフェースがダッシュ
多くのユーザが ダッ ボードなのであれば、より多くのCPUを追加してください。
シュボードにアクセス
しますか？
あなたのクラウドで、 サービスごとに１コア割り当ててコントローラーをサイジングする必
何個のnova-apiサービ 要があります。
スを同時に実行します
か？
１つのインスタンスが インスタンスの起動と停止は コンピュートノードに負荷をかけます
どのくらい実行され続 が、それだけでなく、すべてのAPI処理とスケジューリングの必要性の
けますか？
ために、コントローラーノードにも負荷をかけます。
認証システムは外部に LDAPやActive Directoryのような外部認証システムを利用する場合ク
確認を行いますか？
ラウドコントローラと外部認証システムとの間のネットワーク接続性
が良好である必要があります。また、クラウドコントローラがそれら
のリクエストを処理するための十分のCPUパワーが必要です。
39
OpenStack 運用ガイド
February 1, 2016
サービスの分離
この例ではすべての中心的なサービスが1つの場所にありますが、サービ
スを分割してそれぞれ別の物理サーバに配置する事は可能であり、本当
に良いアイデアです。表3.2「構成シナリオ」 [40] は構築のシナリオ
と設計の理由です。
表3.2 構成シナリオ
シナリオ
理由
swift-proxy サーバ
この構成ではオブジェクトストレージプロクシサーバのI/Oの空きが
でglance-*サーバを稼 十分にあり、glance　のイメージ配信部分は物理ハードウェアとオブ
働する
ジェクトストレージのバックエンドに使用している良好なネットワー
ク接続性の恩恵を十分に受ける事ができると感じた。
中央データベースサー この構成では、すべてのサービスに対するデータベースサービスを提
バを構成する
供する専用サーバを設置しました。これにより、データベースサー
バーのアップデートを分離でき、運用がシンプルになりました。ま
た、フェイルオーバーのためのスレーブデータベースサーバーの設置
が単純になりました。
1サービスにつき1つの この構成では中央サーバをKVM上のサーバで実行しました。専用のVMを
VMを稼働させる
それぞれのサービスで用意しました(nova-scheduler, RabbitMQ, デー
タベースなど)。この構成はクラウド管理者が(インストール時によく
推測できないので)それぞれのサービスへの負荷のかかり具合によって
各バーチャルマシンへのリソース割当を変更する事ができる構成でし
た。
外部ロードバランサー この構成は、組織内に高価なハードウェアロードバランサーを持って
の使用
いました。彼らは複数の nova-api とswift-proxy サーバーを異なる
物理サーバーで動作させ、その振り分けにロードバランサーを利用し
増した。
仮想化するかどうかについてはいつも問題になります。 novacompute、swift-proxy 、 swift-object といったいくつかのサーバーは
仮想化にすべきではありません。しかし、制御系のサーバについては仮
想化にすると幸せになります。それによる性能のペナルティは単純によ
り多くのサービスを動かす事で相殺する事ができます。
データベース
OpenStackコンピュートはステートフルな情報を保存、取得するために
SQLデータベースを使用します。MySQLはOpenStackコミュニティでポピュ
ラーな選択です。
データベースの消失はエラーにつながります。結論としては、データ
ベースを冗長化するためにクラスター構成とする事を推奨します。使ク
ラウド環境で使用するデータベースをクラスタ化しをOpenStack外に配置
します。MySQLベースのデータベースではMySQL/Galeraが人気です。
40
OpenStack 運用ガイド
February 1, 2016
メッセージキュー
多くのOpenStackサービスはメッセージキューを使用してお互いと通信を
しています。例えば、コンピュートはメッセージキューを通じてブロッ
クストレージサービスとネットワークサービスと通信をしています。ま
た、どのようなサービスでも通知を有効にする事ができます。メッセー
ジキューサービスの選択としてRabbitMQ、Qpid、0mqがポピュラーです。
一般的には、メッセージキューが障害あるいはアクセス不能となった場
合、クラスターはメッセージを最後に送信した状態のままスタックし
た状態で停止しリードオンリーの状態となります。ですので、メッセー
ジキューはクラスター公正にする事をお勧めします。クラスタ化された
メッセージキューは多くのOpenStack構成で弱点になることを覚えておく
必要があります。RabbitMQは標準でクラスタ対応していますが大規模に
なった場合にいくつかの問題が報告されています。0mqやQPIDといった他
のメッセージングソリューションも存在していますが、0mqはステートフ
ルなキューを提供していません。QpidはRed Hat系ディストリビューショ
ンでのメッセージングシステムの選択となります。Qpidは標準でクラス
タをサポートしておらず、PacemakerやCorosyncといった補助的なサービ
スが必要になります。メッセージキューに関しては、コンピュータの機
能を利用する際にするように許容範囲なデータ損失のレベルとイベント
失敗時に複数のMQホストを試行するOpenStackの機能を利用するかどうか
を決める必要があります。
コンダクターサービス
以前のバージョンのOpenStackではすべてのnova-computeサービスはク
ラウドコントローラーに搭載されたデータベースに直接アクセスする必
要がありました。これはセキュリティとパフォーマンスという2つの問
題を抱えていました。セキュリティに関してはもしコンピュートノード
に侵入された場合、アタッカーはデータベースにアクセスできてしまい
ます。パフォーマンスに関しては、nova-computeはデータベースの呼び
出しをシングルスレッドで行い、他の呼び出しをブロックする点です。
データベースリクエストはシリアルリクエストよりパラレルリクエスト
の方が効率がいいのでこの点はパフォーマンスのボトルネックになりま
す。
コンダクターサービスはnova-computeサービスのプロクシとして次の両
方の問題を解決します。現在は、 nova-computeが直接データベースに
アクセスするのに変わってnova-conductorサービスにアクセスしnovaconductorサービスがnova-computeサービスの代理でデータベースにア
クセスをします。これによりnova-computeはもう直接データベースにア
クセスする必要はなくセキュリティ問題は解消されます。加えて nova41
OpenStack 運用ガイド
February 1, 2016
conductor はノンブロッキングサービスなのですべてのコンピュートか
らのリクエストが並列で処理できます。
注記
あなたのクラウド環境で、nova-networkとマルチホストネッ
トワークを使用している場合、 nova-computeは現在もデータ
ベースへの直接アクセスを必要とします。
nova-conductorサービスは水平方向にスケーラブルです。novaconductorを冗長構成になるためには、nova-conductor プロセスを同一
サーバまたは複数のサーバに渡って複数起動するだけです。
Application Programming Interface
(API)
すべてのパブリックアクセス（直接アクセス、コマンドライン、ウェブ
ベースダッシュボード）はすべてAPIサービスを使用します。APIリファ
レンスはhttp://api.openstack.org/です。
Amazon EC2 互換 API をサポートしたいか、OpenStack API だけなの
か、選択しなければなりません。両方の API を運用する場合、イメージ
とインスタンスを参照する際の見え方が違うことが一つの論点になりま
す。
例えば、EC2 API では、16 進数を含む ID を使ってインスタンスを参
照するのに対して、OpenStack API では名前と数値を使います。同様
に、EC2 API は仮想マシンに接続するのに DNS エイリアスに頼る傾向が
ありますが、OpenStack では典型的には IP アドレスを使います。
もしOpenStakcが正しく構成されていない場合、正しくないDNSエイリア
スしな無いため、ユーザはインスタンスへアクセスできないというシン
プルな事態が生じます。それにもかかわらず、EC2互換はユーザをあなた
のクラウドへ移行することをアシストします。
データベースやメッセージキューのように、１台以上のAPI サーバー を
設置する事は良い案です。nova-api　サービスを高可用にするために、
伝統的な HTTP 負荷分散技術を利用することができます。
API 拡張
API仕様にはOpenStack APIのコアアクション、ケイパビリティ、メタタ
イプについて定義されています。クライアントはいつでもこのコアAPI
の可用性に頼る事ができ、実装者は常にそれら全体をサポートする必要
42
OpenStack 運用ガイド
February 1, 2016
があります。コアAPIの遵守を要求する事は同じAPIで複数の実装と相互
作用する際に、クライアントに機能の最小レベルに依存する事ができま
す。
OpenStack Compute API は拡張可能です。ある拡張は、ある API にコ
ア定義を超えたケイパビリティを追加します。新機能、新しい MIME タ
イプ、アクション、状態、ヘッダ、パラメータ、そしてリソースの導
入は、コア API の拡張によって達成することができます。これによ
り、API に対してバージョンを変更することなく新機能を導入すること
ができ、ベンダー固有の特定の機能を導入することもできます。
スケジューリング
スケジューリングサービスは仮想マシンやブロックストレージのボ
リュームがどのコンピュートあるはストレージノードで生成されるか
を決定する事に責任を持ちます。スケジューリングサービスはメッセー
ジキューからそれらのリソースの生成リクエストを受け、どのリソース
が適切かを決定するプロセスを起動します。このプロセスは利用可能な
ノード郡からユーザが設定したフィルタを適用する事で実行されます。
現在のところ2つのスケジューラがあります：仮想サーバを受け持
つnova-scheduler とブロックストレージボリュームを受け持つcinderscheduler です。それぞれのスケジューラは高可用性目的や、高負荷環
境での実装のために水平方向にスケーリングが可能で、それぞれのスケ
ジューラに対して複数のインスタンスを起動すべきです。スケジューラ
はすべて共有されたメッセージキューをリスンするので特別な負荷分散
は必要ありません。
イメージ
OpenStack Image service はglance-api とglance-registryの2つのパー
トから成り立っています。前者はコンピュートノードがバックエンドか
らイメージをダウンロードする際の、イメージの配信に責任を持ちま
す。後者は仮想マシンに属し、データベースを必要とするメタデータの
情報をメンテナンスします。
glance-api部はバックエンドを選択する事ができる抽象的なレイヤーで
す。現在、以下をサポートしています：
OpenStack オブジェクトス
トレージ
イメージをオブジェクトとして格納する事
を許可します
ファイルシステム
イメージをファイルとして格納するために
一般的なファイルシステムを使用します。
43
OpenStack 運用ガイド
February 1, 2016
S3
Amazon S3からイメージを取得する事を許
可します。
HTTP
イメージをウェブサーバから取得する事を
許可します。このモードではイメージの書
き込みはできません。
OpenStack Storageサービスがある場合は、イメージを保存するためにス
ケーラブルな場所を利用する事を推奨します。また、OpenStackをとおし
て新しいイメージをアップロードする必要がない場合を除いて、十分な
性能を備えたファイルシステムかAmazon S3を使用する事もできます。
ダッシュボード
OpenStackダッシュボード(horizon)は様々なOpenStackコンポーネントの
ウェブベースユーザーインターフェースを提供します。ダッシュボード
にはエンドユーザの仮想インフラを管理するための領域と、OpenStack環
境全体を管理するためのクラウド管理者のための管理者領域が含まれま
す。
ダッシュボードはPythonのウェブアプリケーションとして実装され、通
常はApachehttpdサーバ上で稼働します。したがって、そこから ネット
ワーク経由で (管理者 エンドポイントを含む) API サーバーにアクセス
できるという条件の下、他の任意の Web アプリケーションと同じように
取り扱うことができます。
認証と認可
OpenStackの認証と承認は良く知られ、幅広いシステムで良く利用されて
いる物から来ています。ユーザは認証のためにクレデンシャルを持ち、1
つ以上のグループ(プロジェクトまたはテナントと呼ばれます)のメン
バーとなる事ができます。
例えば、クラウドのユーザは自分の現在のグループに属するインスタン
スのみが見えるのに対して、クラウドの管理者はそのクラウドのすべ
てのインスタンスの一覧をとることができるでしょう。利用可能なコア
数、ディスク容量等のリソースのクォータはプロジェクトに対して関連
づけられています。
OpenStack Identity は、認証の判定とユーザの属性情報を提供する場と
なり、他の OpenStack サービスから認証のために使用されます。ポリ
シーは policy.json で記述されます。これらを設定するための情報に
ついては、9章プロジェクトとユーザーの管理 [103] を参照してくださ
い。
44
OpenStack 運用ガイド
February 1, 2016
Identity は、バックエンド認証と情報保持のために種々のプラグインを
サポートしています。これらの選択肢は、現在は以下の物が含まれてい
ます。
• メモリ内のキーバリュー型ストア（シンプルな内部ストレージ構造）
• SQL データベース (MySQL や PostgreSQL など)
• Memcached (分散メモリーオブジェクトキャッシュシステム)
• LDAP (OpenLDAP や Microsoft の Active Directory)
多くのデプロイメントで SQL データベースが使われていますが、既存の
認証インフラとインテグレーションする必要のある環境では、LDAP もポ
ピュラーな選択肢です。
ネットワークの考慮事項
クラウドコントローラーは非常に多くのサービスを取り扱うため、それ
らすべてのトラフィックを処理できなければなりません。例えば、クラ
ウドコントローラー上に OpenStack Image service を乗せることにした
場合、そのクラウドコントローラーは許容可能な速度でイメージの転送
できなければなりません。
他の例としては、クラウドコントローラーがすべてのインスタンスの
ゲートウェイとなるような単一ホスト・ネットワークモデルを使うこと
にした場合、クラウドコントローラーは外部インターネットとあなたの
クラウドの間でやりとりされるすべてのトラフィックを支えられなけれ
ばなりません。
10GbE のような高速な NIC を使うことを推奨します。また、10GbE NIC
を2枚使って ボンディングすることもできます。束ねられた 20Gbps の
速度をフルに使うことはできないかもしれませんが、異なる送信スト
リームは異なる NIC を使います。例えば、クラウドコントローラーが
2つのイメージを送信する場合、それぞれのイメージが別の NIC を使
い、10Gbps の帯域をフルに使うことができます。
45
OpenStack 運用ガイド
February 1, 2016
第4章 コンピュートノード
CPU の選択 ..................................................
ハイパーバイザーの選択 ......................................
インスタンスストレージのソリューション .......................
オーバーコミット ............................................
ロギング ....................................................
ネットワーク ................................................
まとめ ......................................................
47
48
49
53
54
55
55
本章では、コンピュートノードの構築時に考慮する必要のある選択肢に
ついて説明します。コンピュートノードは、OpenStack Compute クラ
ウドのリソースコアを構成し、プロセッシング、メモリー、ネットワー
ク、ストレージの各リソースを提供してインスタンスを実行します。
CPU の選択
コンピュートノードの CPU タイプを選択することは非常に重要です。ま
ず、Intel チップには VT-x、AMD チップには AMD-v という風に、CPU
が仮想化をサポートするようにします。
ヒント
仮想化サポートがあるかどうかについては、ベンダーの
文書を参照してください。Intel については “Does my
processor support Intel® Virtualization Technology?”
を確認してください。AMD については AMD Virtualization
を確認してください。CPU が仮想化をサポートしていても
無効になっている場合があることに注意してください。ま
た、CPU 機能を有効にする方法はお使いのシステムの BIOS
の文書を参照してください。
CPU のコア数も選択に影響します。現在の CPU では最大 12 コアあるの
が一般的です。さらに、Intel CPU がハイパースレッディングをサポー
トしている場合、12 コアは 2 倍の 24 コアになります。複数の CPU を
サポートするサーバーを購入する場合、コア数はさらに倍になっていき
ます。
47
OpenStack 運用ガイド
February 1, 2016
マルチスレッドの課題
ハイパースレッディングは、Intel 専用の同時マルチスレッド実装
で、CPU の並列化向上に使用されます。マルチスレッドアプリケー
ションのパフォーマンスを改善するには、ハイパースレッディング
を有効にすることを検討してください。
CPU のハイパースレッディングを有効にするかどうかは、それぞ
れのユースケースにより変わってきます。例えば、ハイパースレッ
ディングを無効にすると、負荷の高いコンピューティング環境で有
用です。ハイパースレッディングがオン、オフの両方の状態でロー
カルのワークロードを使用してパフォーマンスのテストを実施し、
各ケースでいずれが適しているか決定するように推奨しています。
ハイパーバイザーの選択
ハイパーバイザーは、仮想マシンの基盤ハードウェアへのアクセスを管
理するソフトウェアを提供します。ハイパーバイザーは仮想マシンを作
成、管理、監視します。 OpenStack Compute は多くのハイパーバイザー
を様々な度合いでサポートしています。
• KVM
• LXC
• QEMU
• VMware ESX/ESXi
• Xen
• Hyper-V
• Docker
おそらく、ハイパーバイザーの選択で最も重要な要素は、現在の使用
法やこれまでの経験でしょう。それ以外では、同等の機能の実用上の懸
念、ドキュメント、コミュニティでの経験量などあると思います。
例えば、 KVM は OpenStack コミュニティーでは最も多く採用されてい
るハイパーバイザーです。KVM 以外では、Xen、LXC、VMware、Hyper-V
を実行するデプロイメントのほうが、他に リストされているハイパー
バイザーよりも多くなっています。しかし、いずれのハイパーバイザー
48
OpenStack 運用ガイド
February 1, 2016
も、機能のサポートがないか、OpenStack を併用する方法に関する文書
が古くなっています。
選択を行う上で参考になるベストな情報は、Hypervisor Support Matrix
や configuration reference で確認いただけます。
注記
ホストアグリゲートやセルを使用すると、1 つのデプロイメ
ントで複数のハイパーバイザーを実行することも可能です。
しかし、個別のコンピュートノードでは 1 度につき 1 つの
ハイパーバイザーしか実行することができません。
インスタンスストレージのソリューショ
ン
コンピュートクラスターの調達の一部として、インスタンス化された
インスタンスを実行するディスクのストレージを指定する必要がありま
す。一時ストレージ提供のアプローチは主に 3 つあり、それぞれのアプ
ローチの含意を理解することは重要です。
次の3つの方法があります。
• コンピュートノード外のストレージ （共有ファイルシステム）
• コンピュートノード上のストレージ （共有ファイルシステム）
• コンピュートノード上のストレージ （非共有ファイルシステム）
一般的に、ストレージを選択する際に以下の点を考慮する必要がありま
す。
• 実現したいプラッター数（ディスク容量）はどれくらいか？
• ネットワークアクセスがあったとしても、ディスク数が多い方が良い
I/O 性能が得られるか？
• 何があなたが目指すコストパフォーマンスのシナリオはどれか？
• 運用上ストレージをどのように管理したいのか？
多くの運用者はコンピュートホストとストレージホストを分離して使用
しています。コンピュートサービスとストレージサービスには異なる
要件があり、コンピュートホストでは通常はストレージホストよりも
49
OpenStack 運用ガイド
February 1, 2016
多くの CPU と RAM が必要です。そのため、一定の予算の中では、コン
ピュートホストとストレージホストの構成が異なることは理にかなって
います。コンピュートホストでは、CPU や RAM を、ストレージノードで
はブロックストレージを多く使用します。
一方、クラウドの構築に使用できる物理ホスト数に制限があり、できる
だけ多くのホストをインスタンスの実行に使えるようにしたい場合は、
同じマシンでコンピュートホストとストレージホストを動作させるのは
理にかなっています。
以降の数セクションでは、 3 つの主要アプローチについて説明します。
50
OpenStack 運用ガイド
February 1, 2016
コンピュートノード外のストレージ （共有ファイ
ルシステム）
このオプションでは、実行中のインスタンスを格納するディスクはコン
ピュートノード外のサーバーでホストされます。
コンピュートホストとストレージホストを分離して使用すると、コン
ピュートホストを「ステートレス」として処理できます。コンピュート
ホストで実行中のインスタンスがなければ、クラウドの他のアイテムに
影響を与えることなく、ノードをオフラインにしたり、完全に消去した
りすることができます。これにより、コンピュートホストのメンテナン
スが簡素化されます。
このアプローチには複数の利点があります。
• コンピュートホストが故障した場合、通常インスタンスは簡単に復旧
できます。
• 専用のストレージシステムを動作させることで、運用がシンプルにな
ります。
• スピンドル数を何個にでもスケールすることができます。
• 外部ストレージを他の用途と共有できる可能性があります。
この方法の主なマイナス面は以下の点です。
• 設計次第では、一部のインスタンスの I/O が非常に多い場合に、無関
係のインスタンスに影響が出る場合があります。
• ネットワークを使用するため、性能低下が起こる可能性があります。
コンピュートノード上のストレージ （共有ファイ
ルシステム）
このオプションでは、各コンピュートノードに、多くのディスク容量が
指定されていますが、分散ファイルシステムにより、それぞれのコン
ピュートノードからのディスクが 1 つのマウントとしてまとめられま
す。
このオプションの主な利点は、追加ストレージが必要な場合、外部スト
レージにスケールアウトできる点です。
しかし、この方法にはいくつかマイナス点があります。
51
OpenStack 運用ガイド
February 1, 2016
• 分散ファイルシステムを実行すると、非共有ストレージに比べデータ
の局所性が失われる可能性があります。
• 複数の物理ホストが関係するため、インスタンスの復旧が複雑になり
ます。
• コンピュートノードの筐体サイズによって、コンピュートノードに搭
載できるディスク数が制限されます。
• ネットワークを使用するため、性能低下が起こる可能性があります。
コンピュートノード上のストレージ （非共有ファ
イルシステム）
このオプションでは、ホストするインスタンスを格納するのに十分な
ディスク容量が各コンピュートノードに指定されます。
このアイデアが良いとされる理由は主に 2 点挙げられます。
• あるコンピュートノード上での I/O が非常に多い場合でも、他のコン
ピュートノードのインスタンスに影響がありません。
• I/O アクセスが直接行われるので、性能向上が図れます。
この方法には次のようなマイナス点があります。
• コンピュートノードが故障すると、そのノードで実行中のインスタン
スが失われてしまいます。
• コンピュートノードの筐体サイズによって、コンピュートノードに搭
載できるディスク数が制限されます。
• ノード間のインスタンスのマイグレーションがより複雑になり、今後
開発が継続されない可能性のある機能に依存することになります。
• 追加ストレージが必要な場合、このオプションはスケールしません。
信頼性と拡張性が最も重要な要因とするクラウドでは、コンピュート
ノードと分離してストレージシステムで共有ファイルシステムを実行す
ることが理想的です。仕様のコントロールをほぼできない、または全
くできない既存のサーバーにデプロイシなければならない場合などは、
コンピュートノード自体で共有ファイルシステムを実行するとベストで
す。また、I/O 要件が高く、信頼性にあまり配慮しなくてもいいクラウ
ドには、コンピュートノード上で非共有ファイルシステムを実行すると
良いでしょう。
52
OpenStack 運用ガイド
February 1, 2016
ライブマイグレーションに関する問題
ライブマイグレーションは、クラウドの運用に不可欠であると考えられ
ます。この機能により、物理ホストから別の物理ホストに、インスタ
ンスをシームレスに移動し、コンピュートホストの再起動を必要とす
るアップグレードができるようになります。しかし、ライブマイグレー
ションは共有ストレージのみで正常に機能します。
ライブマイグレーションは、KVM ライブブロックマイグレーション とい
う機能を使用して、非共有ストレージでも行うことができます。KVM や
QEMU でのブロックベースのマイグレーションは当初、信頼できませんで
したが、OpenStack との互換性もある QEMU 1.4 および libvirt 1.0.2
では、より新しく、信頼性の高いブロックベースのライブマイグレー
ション実装ができるようになっています。ただし、本書の執筆者は、ラ
イブブロックマイグレーションを実際に使用していません。
ファイルシステムの選択
共有ストレージのライブマイグレーションをサポートする場合、分散
ファイルシステムを設定する必要があります。
次のような選択肢があります。
• NFS (Linux でのデフォルト)
• GlusterFS
• MooseFS
• Lustre
すべてのファイルシステムを使用したデプロイメントに触れ、運用にな
れているものを選択するように推奨しました。いずれのファイルシス
テムにも馴染みがない場合は、設定が簡単で、コミュニティのナレッジ
ベースが幅広く存在するため、NFS を選択するようにしてください。
オーバーコミット
OpenStack は、コンピュートノードで CPU および RAM をオーバーコ
ミットすることができます。これにより、インスタンスのパフォーマン
スを落とすことでクラウドで実行可能なインスタンス数を増やすことが
できます。 OpenStack Compute はデフォルトで以下の比率を使用しま
す。
53
OpenStack 運用ガイド
February 1, 2016
• CPU 割当比: 16:1
• RAM 割当比: 1.5:1
デフォルトの CPU 割当比は 16:1 で、これは、物理コア 1 つにつき仮
想コアが最大 16 個までスケジューラーにより割り当てることができる
ことを意味します。例えば、物理ノードにコアが 12 個ある場合、スケ
ジューラーには、使用可能な仮想コアが 192 個あることになります。イ
ンスタンス 1 個に仮想コア 4 個という通常のフレーバーの定義では、
この比率をもとにすると、1 つの物理にインスタンスが 48 個割り当て
らることになります。
コンピュートノード上の仮想インスタンス数の公式は、 (OR*PC)/VC で
す。それぞれ以下を意味します。
OR
CPU オーバーコミット比率 (物理コアごとの仮想コア)
PC
物理コア数
VC
インスタンスごとの仮想コア数
同様に、RAM 割当比のデフォルト1.5:1 は、インスタンスに関連づけら
れた RAM の総量が物理ノードで利用できるメモリ量の1.5倍未満であれ
ば、スケジューラーがその物理ノードにインスタンスを割り当てること
を意味します。
例えば、物理ノードに 48GB の RAM がある場合、そのノード上のイン
スタンスに割り当てられた RAM の合計が 72GB に達するまでは、スケ
ジューラーはそのノードにインスタンスを割り振ることになります (例
えば、各インスタンスのメモリが 8GB であれば、9 インスタンス割り当
てられます)。
あなた自身のユースケースに合わせて、適切な CPU と RAM の割当比を
選択しなければなりません。
ロギング
ロギングの詳細は、13章ロギングと監視 [215] で包括的に記載していま
す。ただし、クラウドの運用を開始する前に、重要な設計に関する事項
について考慮していく必要があります。
OpenStack は、便利なロギング情報を多く生成しますが、運用目的でそ
の情報を有効活用するには、ログの送信先となる中央ロギングサーバー
や、ログの解析/分析システム (logstash など) の導入を検討する必要
があります。
54
OpenStack 運用ガイド
February 1, 2016
ネットワーク
OpenStack でのネットワークは複雑で、多くの課題があります。7章ネッ
トワーク設計 [81]を参照してください。
まとめ
コンピュートノードはクラウドの主なアイテムで、ユーザーのアプリ
ケーションが実行される場所です。何をどのようにデプロイするかユー
ザーの意思決定により、コンピュートノードは影響を受けます。これら
の要件は、意思決定していく際に反映させる必要があります。
55
OpenStack 運用ガイド
February 1, 2016
第5章 スケーリング
出発点 ......................................................
クラウドコントローラーノードの追加 ...........................
クラウドの分離 ..............................................
スケーラブルハードウェア ....................................
57
59
60
64
従来のアプリケーションでは、スケーリングするには、より大きいハー
ドウェアが必要でした (垂直スケーリング) が、クラウドベースのアプ
リケーションは通常、別のハードウェアを必要とします(水平スケーリン
グ)。クラウドを正常に設定できた場合、需要が増すとそれに合うように
リソースを追加する必要がでてきます。
クラウドのパラダイムに合わせるため、OpenStack は水平的にスケーリ
ングできるように設計されています。容量の大きいサーバーに切り替
えるのではなく、サーバーを多く調達して同じように設定したサービス
をインストールするだけです。理想としては、メッセージバスを通信す
る、機能的に同じサービス (例: コンピュートノードや nova-api ノー
ド) グループでスケールアウト、負荷分散します。
出発点
多くのアイテムでバランスを取りながら、クラウドのスケーラビリティ
や改善方法を決定していきます。ソリューション 1 つだけでは、スケー
ラビリティの目的を達成することはできません。しかし、複数のメトリ
クスをトラッキングすると役に立ちます。仮想ハードウェアのテンプ
レート (OpenStack ではフレーバーと呼ばれる) を定義できるため、用
意するフレーバーをもとにスケーリングの意思決定を行うことができま
す。これらのテンプレートは、メモリーのサイズ (RAM)、root ディスク
のサイズ、一時データディスクの空き容量、スターターのコア数を定義
します。
デフォルトの OpenStack フレーバーは 表5.1「OpenStack デフォルトの
フレーバー」 [58] に表示されています。
57
OpenStack 運用ガイド
February 1, 2016
表5.1 OpenStack デフォルトのフレーバー
名前
仮想コア数
メモリ
ディスク
エフェメラル
m1.tiny
1
512 MB
1 GB
0 GB
m1.small
1
2 GB
10 GB
20 GB
m1.medium
2
4 GB
10 GB
40 GB
m1.large
4
8 GB
10 GB
80 GB
m1.xlarge
8
16 GB
10 GB
160 GB
多くの場合、クラウドのコア数から始めます。比率を適用することで、
• 実行する必要のある仮想マシン数。((overcommit fraction
• 必要とされるストレージ容量(flavor disk size
に関する情報を取得できます。これらの比率を使用して、クラウドのサ
ポートに必要なインフラストラクチャーがどの程度必要か判断すること
ができます。
ここでは、期待される仮想マシン数や必要なストレージ数などの拡張性
の情報を収集するために、これらの比率を使用した例を紹介していま
す。以下の数では、 (200 / 2) × 16 = 1600 仮想マシンのインスタン
スをサポートし、/var/lib/nova/instances のストレージ 80 TB が必要
となります。
• 物理コア 200 個
• ほとんどのインスタンスのサイズは m1.medium (仮想コア数2、スト
レージ50GB) とします。
• デフォルトの CPU オーバーコミット比率 (cpu_allocation_ratio in
nova.conf) は 16:1 とします。
しかし、APIサービスやデータベースサーバー、MQサーバーがおそらく遭
遇する負荷を見積もるためには、コア数以外の検討も行う必要がありま
す。クラウドの利用パターンも考慮しなければなりません。
特定の例としては、マネージド Web ホスティングプラットフォームをサ
ポートするクラウドと、コードコミットごとに仮想マシンを１つ作成す
るような開発プロジェクトの統合テストを実行するクラウドを比較して
みましょう。前者では、VMを作成する負荷の大きい処理は数か月に 一度
しか発生しないのに対して、後者ではクラウドコントローラに常に負荷
の大きい処理が発生します。一般論として、VMの平均寿命が長いという
ことは、クラウドコントローラの負荷が軽いことを意味するため、平均
的なVMの寿命を検討する必要があります。
58
OpenStack 運用ガイド
February 1, 2016
仮想マシンの作成、停止以外に、特に nova-api や関連のデータベース
といったサービスにアクセスする際の影響について考慮する必要があり
ます。インスタンスを一覧表示することで膨大な量の情報を収集し、こ
の操作の実行頻度を前提として、ユーザー数の多いクラウドで負荷を大
幅に増加させることができます。これはユーザーには透過的に行われま
す。OpenStack のダッシュボードをブラウザで開いた状態にすると、仮
想マシンの一覧が 30 秒毎に更新されます。
これらの要素を検討した後、クラウドコントローラにどのくらいのコ
ア数が必要なのか決定することができます。上記で説明した留意事項の
下、典型的には、ラック 1 本分のコンピュートノードに対して8 コア、
メモリ 8GB のサーバで充分です。
また、仮想マシンのパフォーマンス、ストレージの性能 (スピンドル/コ
ア)、メモリーの空き容量 (RAM/コア)、ネットワークの帯域幅など、予
算や性能のニーズに関して、主なハードウェアの仕様を考慮する必要も
あります。 (Gbps/コア)、全体的な CPU のパフォーマンス (CPU/コア)
ヒント
クラウドからメトリクスを抽出する方法など、メトリクスの
追跡については、13章ロギングと監視 [215] を参照してくだ
さい。
クラウドコントローラーノードの追加
ノードを追加することで、垂直に拡張するのが容易になります。コン
ピュートノードの追加は単純で、既存のインストール環境から簡単に
ピックアップすることができます。しかし、高可用性のクラスターを設
計するには、重要なポイントを考慮する必要があります。
クラウドコントローラは、異なるサービスを複数実行することを思い
出してください。拡張のための新しいサーバには、nova-scheduler や
nova-console のようなメッセージキューのみを使用して内部通信を行う
サービスをインストールすることができます。しかし、その他の不可欠
な部分はさらに細心の注意が必要です。
ダッシュボード、nova-api、Object Storage プロキシなどのユーザー
が使用するサービスの負荷分散をする必要があります。標準の HTTP
負荷分散メソッド (DNS ラウンドロビン、ハードウェアロードバラン
サー、Pound または HAProxy などのソフトウェア) を使用して下さい。
ダッシュボードに関しては、L7 ロードバランサーで大変困難となる可能
性があるため、VNC プロキシは注意が必要です。Horizon セッションス
トレージも参照してください。
59
OpenStack 運用ガイド
February 1, 2016
nova-api や glance-api などのサービスは、環境設定ファイルのフラ
グを変更することによって複数プロセスで処理させるように設定できま
す。これによって 1 台のサーバー上にある複数のコアの間で処理を共有
できるようになります。
ヒント
MySQL の負荷分散には複数のオプションがあり、サポートさ
れている AMQP ブローカーにはクラスタリングサポートが含
まれています。これらの設定方法やその他多くのサービスに
関する情報は、 パートII「運用」 [89] を参照してくださ
い。
クラウドの分離
法的に考慮したデータストレージ、耐震ラインでの冗長性、低遅延の
API コールを提供する様々なリージョンを提供するには、クラウドを分
割します。セル、リージョン、アベイラビリティゾーン、ホストアグリ
ゲート のいずれかの OpenStack メソッドを使用して、クラウドを分割
します。
メソッド毎に異なる機能を提供しますが、このメソッドは 2 つのグルー
プに分類すると良いでしょう。
• セルおよびリージョン。クラウド全体を分離し、個別にコンピュート
デプロイメントを稼働します。
• アベイラビリティゾーン およびホストアグリゲート。コンピュートの
デプロイメントの分割のみを行います。
表5.2「OpenStack 分離の手法」 [60] では、OpenStack Compute が現
在提供している各分割メソッドの比較ビューを提供しています。
表5.2 OpenStack 分離の手法
セル
リージョン
アベイラビリティ ホスト・アグリ
ゾーン
ゲート
用途
コンピュート資源
に対する単一の
API エンドポイン
ト、もしくは２段
階スケジューリン
グが必要な場合
リージョンごと
に別々のAPIエン
ドポイントが必要
で、リージョン間
で協調する必要が
ない場合
物理的な隔離
や冗長性のため
に、Nova デプロ
イメントの中で論
理的な分離が必要
な場合
例
複数サイトで構
複数サイトで構
分離された電源供 トラステッドコン
成されるクラウド 成されるクラウド 給ラインを持つ設 ピューティング機
60
共通の機能を持っ
たホストのグルー
プに対してスケ
ジューリングした
い場合
OpenStack 運用ガイド
オーバーヘッド
February 1, 2016
セル
リージョン
で、仮想マシンを
「任意のサイト」
または特定のサイ
トにスケジューリ
ングしたい場合
で、仮想マシンを 備で構成される、 能に対応したホス
特定のサイトに対 単一サイトのクラ ト群に対してスケ
してスケジューリ ウド。
ジューリングした
ングでき、かつ共
い場合
有インフラを利用
したい場合
試験として使用
リージョン毎に
別々のAPIエンド
ポイントが必要
新規サービ
ス、nova-cells
アベイラビリティ ホスト・アグリ
ゾーン
ゲート
nova.conf の設定 nova.conf の設定
を変更
を変更
各リージョンに
各セルには nova- フルセットのNova
api　以外の全
サービスが必要
nova 設定が含ま
れています。
共有サービス
Keystone
Keystone
nova-api
Keystone
Keystone
すべての Nova
サービス
すべての Nova
サービス
セルとリージョン
OpenStack Compute のセルによって、より複雑な技術を持ち込むことな
しに、また既存のNovaシステムに悪影響を与えることなしに、クラウド
を分散された環境で運用することができます。１つのクラウドの中のホ
ストは、セル と呼ばれるグループに分割されます。セルは、木構造に
構成されてます。最上位のセル (「API セル」) はnova-apiサービスを
実行するホストを持ちますが、nova-compute サービスを実行するホスト
は持ちません。それぞれの子セルは、nova-apiサービス以外の、普通の
Novaシステムに見られる他のすべての典型的な nova-* サービスを実行
します。それぞれのセルは自分のメッセージキューとデータベースサー
ビスを持ち、またAPIセルと子セルの間の通信を制御する nova-cells
サービスを実行します。
これによって、複数のクラウドシステムに対するアクセスを、１つのAPI
サーバで制御することができます。通常のnova-schedulerによるホスト
の選択に加えて、第二段階のスケジューリング(セルの選択)を導入する
ことにより、仮想マシンを実行する場所の制御の柔軟性が大きく向上し
ます。
単独の API エンドポイントを持つ場合と異なり、リージョンは、クラウ
ドごとに別々のAPIエンドポイントを持ち、より細かい分離を実現できま
す。複数の拠点にまたがってインスタンスを実行するユーザーは、明示
的にリージョンを指定しなければなりません。しかし、新規サービスを
実行するなど、複雑化しなくて済みます。
61
OpenStack 運用ガイド
February 1, 2016
OpenStack dashboard (horizon) は、複数のリージョンを使用するよう
設定できます。これは、AVAILABLE_REGIONS パラメーターにより設定で
きます。
アベイラビリティゾーンとホストアグリゲート
アベイラビリティゾーン、ホストアグリゲート、または両方を使用し
て、nova デプロイメントを分割することができます。
アベイラビリティゾーンは、ホストアグリゲートを利用して実装されて
おり、ホストアグリゲートと同様の方法で設定します。
しかし、アベイラビリティゾーンとホストアグリゲートは別の用途で使
用します。
アベイラビリティゾーン
アベイラビリティゾーンにより、OpenStack Compute ホストを論理グ
ループにまとめて、（独立した電源系統やネットワーク装置を使うこと
などで）他のアベイラビリティゾーンとの物理的な分離や冗長性を実現
できます。
指定したコンピュートホストがローカルでサーバー毎に所属するアベイ
ラビリティゾーンを定義します。アベイラビリティゾーンは一般的に、
共通の属性を持つサーバーを識別するために使用されます。例えば、
データセンターのラックの一部が別の電源を仕様している場合、この
ラックのサーバーを独自のアベイラビリティゾーンに入れることができ
ます。アベイラビリティゾーンは、異なるハードウェアクラスを分割す
ることもできます。
リソースのプロビジョニングの際には、インスタンスを作成するアベイ
ラビリティゾーンを指定することができます。これによって、クラウド
の利用者は、アプリケーションのリソースが異なるマシンに分散して配
置され、ハードウェア故障が発生した場合でも高可用性を達成すること
ができます。
ホストアグリゲートゾーン
これにより、OpenStack コンピュートデプロイメントを負荷分散やイン
スタンスディストリビューション用の論理グループに分割することが
できます。ホストアグリゲートを使用して、アベイラビリティゾーンを
さらに分割することができます。例えば、ホストアグリゲートを使用し
てアベイラビリティゾーンをストレージやネットワークなどの共通のリ
62
OpenStack 運用ガイド
February 1, 2016
ソースを共有するか、信頼済みのコンピューティングハードウェアなど
の特別なプロパティを持つホストグループに分割することができます。
ホストアグリゲートの一般的な用途は nova-scheduler で使用する情報
を提供することです。例えば、ホストアグリゲートを使って、特定の
フレーバーやイメージを共有するホストの集合を作成することができま
す。
この一般的なケースは、アグリゲートメタデータで key-value
ペアを設定して、フレーバーの extra_specs メタデータで
key-value ペアを一致させます。フィルタースケジューラーの
AggregateInstanceExtraSpecsFilter は、強制的にインスタンスが、同
じ値に同じキーが定義されているアグリゲートのホストに対してのみス
ケジューリングするようにします。
この一般的なコンセプトを高度なレベルで使用すると、集中度の高いコ
ンピュートロードや負荷の低い開発やテストシステムが使用量の多いシ
ステムのリソースが不足したり、使用量の低いシステムでリソースを無
駄にしたりしないで、同じクラウドを共有できるように、異なるフレー
バーの種別が、異なる CPU および RAM 割当の比率で実行できるように
なります。 これは、ホストアグリゲートに metadata を設定して、フ
レーバー種別のextra_specs と一致させると機能します。
最初のステップは、cpu_allocation_ratio と ram_allocation_ratio
のアグリゲートメタデータキーを浮動小数点の値に設定しま
す。AggregateCoreFilter と AggregateRamFilter のフィルタースケ
ジューラーは、アグリゲートのホストにスケジューリングしている場
合、nova.conf のグローバルの初期値を仕様するのではなく、この値を
使用します。各ホストは複数のアグリゲートに含まれていますがリソー
スごとに 1 つの割当比率しか指定されていないため、この機能の使用時
は、注意が必要です。同じ リソース に対して別の値が定義されている
複数のアグリゲートにホストを設置しないように注意してください。
これは前半部分です。特定の比率を保証するフレーバー種別を取
得するには、フレーバー種別の extra_specs をアグリゲートで
マッチする key-value ペアに設定する必要があります。たとえ
ば、extra_specscpu_allocation_ratio を 1.0 に定義すると、その
種別のインスタンスは、メタデータキー cpu_allocation_ratio も
1.0 と定義されているアグリゲートのみで実行されます。実際は、
cpu_allocation_ratio または core_allocation_ratio で直接マッチ
させるのではなく、マッチするアグリゲートメタデータに追加の keyvalue ペアを定義すると良いでしょう。これにより抽象化が改善されま
す。たとえば、overcommit キーを定義して、高、中、低の値を設定する
ことで、関連するフレーバー種別をすべて変更する必要なしに、アグリ
ゲートの割合比を調節することができます。
63
OpenStack 運用ガイド
February 1, 2016
注記
以前のバージョンでは、全サービスにアベイラビリティゾー
ンがありました。現在は、nova-compute サービスには独自
のアベイラビリティゾーンがあります。 nova-scheduler、
nova-network、nova-conductor などのサービスは、常にすべ
てのアベイラビリティゾーンに対応します。
以下の操作のいずれかを実行する場合、サー
ビスは独自の内部アベイラビリティゾーン
(CONF.internal_service_availability_zone) に表示されま
す。
• nova host-list (os-hosts)
• euca-describe-availability-zones verbose
• nova-manage サービス一覧
内部のアベイラビリティゾーンは、euca-describeavailability_zones (nonverbose) に隠し設定されていま
す。
CONF.node_availability_zone
は、CONF.default_availability_zone に名前が変更さ
れ、nova-api および nova-scheduler サービスのみで使用さ
れます。
CONF.node_availability_zone は今も機能しますが、非推奨
扱いです。
スケーラブルハードウェア
OpenStack のデプロイやインストールの助けとなるリソースがすでに複
数存在している場合でも、時間に余裕を持ってデプロイメントの系っ
買うを立てることは非常に重要です。本書は、OpenStack クラウド用の
ラックを少なくとも 1 つ用意しているとの前提で、何を度のタイミング
でスケールするかの提案をしていきます。
ハードウェア調達
「クラウド」とは、サーバーを自由に作成、終了でき、不安定な環境と
説明されてきました。これは真実ですが、サーバー自体が不安定なわ
けではありません。クラウドのハードウェアは、安定して正しく設定さ
64
OpenStack 運用ガイド
February 1, 2016
れているようにすることで、クラウド環境は稼動状態を保ちます。基本
的に、安定したハードウェア環境を構築するように努めることで、ユー
ザーが不安定かつ変化しやすいものとして処理を行う可能性のあるクラ
ウドをホストすることができます。
OpenStack は、OpenStack と互換性のある Linux ディストリビューショ
ンによりサポートされているハードウェアにデプロイすることができま
す。
ハードウェアに一貫性を持たせる必要はありませんが、インスタンスの
マイグレーションをサポートできるように、最低限、CPU の種類は同じ
にする必要があります。
OpenStack での使用に推奨しているハードウェアは一般的に、多くの
ハードウェアベンダーが提供している、コストパフォーマンスの高い標
準オファリングです。調達すべきものをコンピュート、オブジェクト
ストレージ、クラウドコントローラなどのビルディングブロックに分類
し、必要に応じ依頼していくと分かりやすいでしょう。また、投資額を
これ以上かけられない場合、既存サーバーがありパフォーマンス要件や
仮想化技術に対応しているのであれば、高い確率で OpenStack をサポー
トしているはずです。
キャパシティプランニング
OpenStack は、直線的に規模が拡大するよう設計されています。本章で
議論したこと、とくにクラウドコントローラーのサイジングを考慮しな
がら、追加のコンピュートノードやオブジェクトストレージノードを必
要に応じて調達できます。新しいノードは、既存のノードと同じ仕様・
ベンダーである必要がありません。
コンピュートノードについては、nova-scheduler がコア数やメモリ量の
サイジングに関する違いを吸収しますが、CPUの速度が違うことによっ
て、ユーザーの使用感が変わることを考慮するべきです。オブジェクト
ストレージノードを追加する際には、 そのノードのcapability を反映
するweight を指定するべきです。
リソース利用状況の監視とユーザー増加の監視によって、（追加機材
の）調達時期を知ることができます。13章ロギングと監視 [215] でいく
つかの有用な監視項目を詳しく解説します。
エージング試験
サーバーハードウェアの故障確率は、そのライフタイムの最初と最後に
高くなります。結論として、初期故障を誘発する適切なエージングテ
65
OpenStack 運用ガイド
February 1, 2016
ストを行うことによって、運用中の故障に対応するための多くの労力を
避けることができます。一般的な原則は、限界まで負荷をかけることで
す。エージング試験の例としては、数日間にわたってCPUやディスクベン
チマークを走行させることが含まれます。
66
OpenStack 運用ガイド
February 1, 2016
第6章 ストレージ選定
一時ストレージ ..............................................
永続ストレージ ..............................................
ストレージのコンセプト ......................................
ストレージバックエンドの選択 ................................
まとめ ......................................................
67
67
72
73
80
ストレージは、OpenStack のスタックの多くの箇所で使用されており、
ストレージの種別が異なると、経験豊かなエンジニアでも混乱する可能
性があります。本章は、お使いのクラウドで設定可能な永続ストレージ
オプションにフォーカスします。一時 ストレージと 永続 ストレージの
相違点を理解することが重要です。
一時ストレージ
OpenStack Compute Service (nova) のみをデプロイする場合、デフォル
トでは、どのような形式の永続ストレージにもアクセスできません。仮
想マシンに関連付けされているディスクは一時的です。つまり、(ユー
ザー視点から) 仮想マシンが終了されるとこのストレージは効率的に表
示がなくなります。
永続ストレージ
永続ストレージとは、実行中のインスタンスの状態が何であっても、ス
トレージリソースが他のリソースよりも長く存在して、常に利用できる
状態のストレージを指します。
今日、OpenStack はオブジェクトストレージ、ブロックストレー
ジ、ファイルシステムストレージという 3 種類の永続ストレージを明示
的にサポートします。
オブジェクトストレージ
オブジェクトストレージでは、REST API を使用してバイナリオ
ブジェクトにアクセスします。オブジェクトストレージで有名
な例として、Amazon S3 は知られています。オブジェクトスト
レージは、OpenStack Object Storage (swift) プロジェクトによ
り、OpenStack に実装されています。ユーザーが、大規模なデータセッ
トをアーカイブまたは管理する場合オブジェクトストレージを提供しま
す。さらに OpenStack では、ファイルシステムにイメージを格納する代
67
OpenStack 運用ガイド
February 1, 2016
わりに、仮想マシン (VM) のイメージを、オブジェクトストレージシス
テムの中に格納できます。
OpenStack Object Storage は、従来のファイルシステムの制約の一部を
緩和することで、高可用性かつ高拡張性のストレージソリューションを
提供します。このようなクラスターの設計、調達には、操作に関する主
なコンセプトを理解することが重要です。基本的に、このタイプのスト
レージハードウェアはすべて、どこかの段階で、どのレベルであっても
故障するというコンセプトをベースに、この種類のストレージは構築さ
れています。 RAID カードやサーバー全体での問題など、他のストレー
ジシステムに影響を与える障害に遭遇することがまれにあります。この
ような場合、OpenStack Object Storageでは滞りなく処理されます。
オブジェクトストレージのアーキテクチャーについて詳しく説明したド
キュメントは the developer documentationにあります。これをまず参
照してください。アーキテクチャーを理解したら、プロキシサーバーの
役割やゾーンの機能について理解できるはずです。しかし、少し見ただ
けでは、頻繁に重要なポイントを逃してしまうことがあります。
クラスターの設計時には、耐久性と可用性を考慮する必要があります。
耐久性や可用性は主に、ハードウェアの信頼性に頼るのではなく、デー
タを分散して設置することで確保されることを理解してください。レプ
リカの数のデフォルト値は 3 である点も考慮します。つまり、オブジェ
クトが書き込みされたとマークされる前でも、少なくともコピーが 2 つ
存在します。1 つのサーバーが書き込みに失敗しても、書き込み操作が
最初に返された時点で、3 番めのコピーが存在する可能性があります。
この数字を変更することで、データの堅牢性を高めることができます
が、利用可能なストレージ数が減少します。次に、サーバーの設置につ
いて見ていきます。データセンターのネットワークや停電ゾーン全体に
設定するようにします。ゾーンには、ラック、サーバー、ディスクのい
ずれを使用していますか？
オブジェクトストレージのネットワークパターンは、最初は見慣れない
かもしれません。これらのメイントラフィックの流れを見てみましょ
う。
• object server 、 container server 、 account server 間
• object/container/account server と proxy server の間
• proxy server と 利用者の間
オブジェクトストレージは、データをホストするサーバーの中で非常に
呼び出しが多く、小さいクラスターでも一秒に MB 単位のトラフィック
があります。「オブジェクトがありますか？はい、あります。」当然、
68
OpenStack 運用ガイド
February 1, 2016
この質問に対する答えがNoの場合、または要求がタイムアウトした場
合、オブジェクトの複製が開始されます。
サーバー全体が停止し、24 TB 分のデータを即時に 3 つのコピーに残る
ように移行するというシナリオを思い浮かべてください。これは、ネッ
トワークに大きな負荷がかかる可能性があります。
69
OpenStack 運用ガイド
February 1, 2016
また、新規ファイルがアップロードされると、プロキシサーバーはレプ
リカの数だけ書き込みが行われ、複数のネットワークトラフィックが発
生するという点も頻繁に忘れられています。 レプリカが３つのクラス
ターでは、受信トラフィックが 10 Gbps とすると、送信トラフィック
は 30 Gbps ということになります。これを以前のレプリカの帯域幅の需
要が 高いことと合わせて考えると、パブリックネットワークよりもプラ
イベートネットワークのほうがはるかに高い帯域幅が必要であることが
分かります。OpenStack Object Storage はパフォーマンスを保つために
内部では、暗号化なし、認証なしの rsync と通信します (プライベート
ネットワークをプライベートに保つため)。
帯域幅に関する残りのポイントは、パブリック側の部分です。swiftproxy サービスは、ステートレスです。ステートレスとは、HTTP 負荷分
散メソッドを簡単に追加、使用して帯域幅や可用性を共有できるという
意味です。
ストレージ側の性能が十分であれば、proxy server の増加は帯域の増加
になります。
ブロックストレージ
Block storage (ボリュームストレージと呼ばれる場合もある) は、ユー
ザーがブロックストレージデバイスにアクセスできるようにします。
ユーザーは、実行中の仮想マシンインスタンスにボリュームを接続する
ことで、ブロックストレージと対話します。
これらのボリュームは永続的であるため、インスタンスから切り離し
て、データをそのまま維持しつつ、別のインスタンスに再接続すること
ができます。ブロックストレージは、ドライバー形式で複数のバックエ
ンドをサポートする、OpenStack Block Storage (Cinder) プロジェク
トで OpenStack に実装されています。お使いのストレージバックエンド
は、Block Storage ドライバーでサポートされている必要があります。
多くのストレージドライバはインスタンスが直接ストレージハードウェ
アのブロックデバイスへアクセスできるようにします。これは リード/
ライト I/O 性能の向上に役立ちます。しかしながら、ボリュームとして
のファイルの利用も、NFS、GlusterFS などの完全サポートとともに、確
立された手法です。
これらのドライバーは従来のブロックストレージドライバとは少々異な
る動作をします。NFSやGlusterFSでは1つのファイルが作成され、イン
スタンスに対して「仮想」ボリュームとしてマッピングされます。この
マッピング/変換は/var/lib/nova/instances 下に保存される、QEMUの
ファイルベースの仮想マシンの、OpenStackによる扱い方と同様です。
70
OpenStack 運用ガイド
February 1, 2016
Shared File Systems サービス
The Shared File Systems service provides a set of services
for management of Shared File Systems in a multi-tenant cloud
environment. Users interact with Shared File Systems service
by mounting remote File Systems on their instances with the
following usage of those systems for file storing and exchange.
Shared File Systems service provides you with shares. A share
is a remote, mountable file system. You can mount a share to and
access a share from several hosts by several users at a time.
With shares, user can also:
• 容量、ファイル共有システムプロトコル、公開レベルを指定した共有
の作成
• 選択したバックエンドのモードに応じて、共有ネットワークの使用有
無を指定して、共有サーバーまたはスタンドアロンで共有を作成しま
す。
• 既存の共有のアクセスルールおよびセキュリティーサービスを指定し
ます。
• Combine several shares in groups to keep data consistency
inside the groups for the following safe group operations.
• Create a snapshot of a selected share or a share group for
storing the existing shares consistently or creating new shares
from that snapshot in a consistent way
• スナップショットから共有を作成します。
• Set rate limits and quotas for specific shares and snapshots
• 共有リソースの使用状況
• 共有を削除します。
Like Block Storage, the Shared File Systems service is
persistent. It can be:
• Mounted to any number of client machines.
• Detached from one instance and attached to another without data
loss. During this process the data are safe unless the Shared
File Systems service itself is changed or removed.
71
OpenStack 運用ガイド
February 1, 2016
Shares are provided by the Shared File Systems service. In
OpenStack, Shared File Systems service is implemented by Shared
File System (manila) project, which supports multiple back-ends
in the form of drivers. The Shared File Systems service can be
configured to provision shares from one or more back-ends. Share
servers are, mostly, virtual machines that export file shares via
different protocols such as NFS, CIFS, GlusterFS, or HDFS.
ストレージのコンセプト
表6.1「OpenStack ストレージ」 [72] は、OpenStack で提供されてい
るさまざまなストレージのコンセプトについて説明しています。
表6.1 OpenStack ストレージ
エフェメラルスト
レージ
ブロックストレー
ジ
オブジェクトスト
レージ
Shared File
System ストレージ
使用目的
OS を起動し、空き 永続的なストレー
領域に記録する
ジを仮想マシン
（VM）へ追加する
データを保存する
（VMイメージも含
む）
永続的なストレー
ジを仮想マシン
（VM）へ追加する
アクセス
方法
ファイルシステム
パーティション分 REST API
割、フォーマッ
ト、マウントが可
能な ブロックデバ
イス (/dev/vdc な
ど)
A Shared File
Systems service
share (either
manila managed
or an external
one registered in
manila) that can
be partitioned,
formatted and
mounted (such
as /dev/vdc)
アクセス
可能な場
所
VM内
VM内
どこからでも
VM内
管理元
OpenStack Compute OpenStack Block
(nova)
Storage (cinder)
OpenStack Object
Storage (swift)
OpenStack Shared
File System
Storage (manila)
データの
残存期間
VM終了まで
ユーザーが削除す
るまで
ユーザーが削除す
るまで
容量の指
定
フレーバー として 初回要求のユー
知られる管理者の ザー仕様
サイズ設定
利用可能な物理
ディスクの総量で
決まる
• 初回要求のユー
ザー仕様
ユーザーが削除す
るまで
• 延長申請
• 利用可能なユー
ザーレベルの
クォータ
• 管理者により適
用される制限
72
OpenStack 運用ガイド
February 1, 2016
エフェメラルスト
レージ
ブロックストレー
ジ
オブジェクトスト
レージ
暗号化の
設定 …
nova.conf のパラ
メーター
管理者が 暗号化ボ まだ利用不可
リューム種別を設
定し、利用者が暗
号化ボリュームを
選択
Shared File
Systems service
does not apply
any additional
encryption above
what the share’s
back-end storage
provides
典型的な
利用例
1 番目のディスク
10 GB、2 番目の
ディスク 30 GB
1TBディスク
Depends
completely on the
size of back-end
storage specified
when a share was
being created.
In case of thin
provisioning it
can be partial
space reservation
(for more details
see Capabilities
and Extra-Specs
specification)
数十TBのデータ
セットストレージ
Shared File
System ストレージ
ファイルレベルのストレージ (ライブマイグレーション用)
ファイルレベルのストレージでは、ユーザーは、オペレーティング
システムのファイルシステムインターフェースを使用して保存した
データにアクセスします。ネットワークストレージソリューション
の使用経験のあるユーザーの多くは、この形式のネットワークスト
レージを使用したことがあります。Unix の分野では、ネットワー
クストレージで最も一般的なものが NFS で、Windows では CIFS
(旧称 SMB) です。
OpenStack クラウドは、ファイルレベルのストレージはエンド
ユーザーには見えませんが、クラウドの設計時に /var/lib/nova/
instances の配下にインスタンスを格納する、ファイルレベルのス
トレージを検討してください。これは、ライブマイグレーションの
サポートには、共有ファイルシステムが必要であるためです。
ストレージバックエンドの選択
クラウドのユースケースごとにニーズが異なります。頻繁に変更が発生
しない多数のオブジェクトに素早くアクセスする必要がある場合、ファ
イルに Time-to-Live (TTL) の値を設定する場合、ファイルシステムの
73
OpenStack 運用ガイド
February 1, 2016
みにマウントされているストレージのみにアクセスするが、新しいイン
スタンスの起動時には即時にそのストレージを複製する場合などがあり
ます。他のシステムの場合は、一時ストレージ (ストレージに接続され
た仮想マシンがシャットダウンされている場合に開放されるストレージ)
がより良い方法です。ストレージのバックエンドの選択時は、ユーザー
の代わりに以下の質問を確認してください。
• ユーザがブロックストレージを必要とするか？
• ユーザがオブジェクトストレージを必要とするか？
• 管理者がライブマイグレーションを必要とするか？
• 永続的ストレージをコンピュートノード内に持つべきか？それとも外
部ストレージに持つべきか？
• 実現可能な容量は？ネットワークアクセスでも、より多くのディスク
がより良い I/O 性能に繋がるか？
• どちらが自分の意図した最高のコストパフォーマンスシナリオを実現
するか？
• ストレージの運用管理をどうするか？
• ストレージの冗長性と分散をどうするか？ストレージノード障害でど
うなるか？災害時、自分のデータ消失をどの程度軽減できるのか？
表6.2「永続ファイルベースのストレージサポート」 [74]で記載されて
いるように、コモディティハードウェアを使用してストレージをデプロ
イする場合、オープンソースのパッケージを使用することができます。
表6.2 永続ファイルベースのストレージサポート
オブジェクトストレー ブロックストレージ
ジ
a
ファイルレベル
Swift
LVM
Ceph
テスト用
Gluster
NFS
ZFS
Sheepdog
a
####################################################################### (MooseFS)###
####################################################################
74
OpenStack 運用ガイド
February 1, 2016
ストレージドライバーズサポート
オープンソースのテクノロジーに加え、OpenStack Block Storage
で正式にサポートされる専用ソリューションが多数存在します。以
下のベンダーによりサポートされています。
• IBM (Storwize family/SVC, XIV)
• NetApp
• Nexenta
• SolidFire
OpenStack wiki で、サポートされている全ブロックストレージド
ライバーが提供する機能一覧を確認いただけます。
クラウド内でオブジェクトストレージの利用を検討する必要がありま
す。コンピュートクラウドで提供されるオブジェクトストレージの一般
的な利用方法は以下の二つです。
• ユーザに永続的ストレージの仕組みを提供する
• スケーラブルで信頼性のある仮想マシンイメージデータストアとして
利用する
コモディティハードウェア上の ストレージ技術
このセクションでは、さまざまな商用ストレージバックエンドテクノロ
ジーにおける相違点をカンタンにまとめます。クラウドユーザーのニー
ズに合わせて、1 つまたは多数のテクノロジーを組み合わせて実装する
ことができます。
OpenStack Object Storage
(swift)
公式の OpenStack Object Store 実
装。Rackspace Cloud Filesのベース
となる技術として、RackSpace によ
り実稼動環境で数年間使用された成
熟テクノロジーです。拡張性が高い
ため、ペタバイトレベルのストレー
ジを管理するのに非常に適していま
す。OpenStack Object Storage の利
点は OpenStack (OpenStack Identity
と統合し、OpenStack Dashboard イ
ンターフェースと連携) と統合でき、
75
OpenStack 運用ガイド
February 1, 2016
非同期のイベントを一貫性を保ちなが
ら複製できるため、複数のデータセン
ターのデプロイメントへのサポートも
向上されています。
そのため、最終的に、複数のデータ
センターにまたがってストレージク
ラスターを分散するように計画した場
合、Compute およびオブジェクトスト
レージ用に統合アカウントが必要な場
合、または OpenStack Dashboard で
オブジェクトストレージを制御する場
合、OpenStack Object Storage を考
慮してみてください。以下のセクショ
ンで OpenStack Object Storage iに
ついて詳しく記載されています。
Ceph
商用ストレージノード全体でデータを
複製する拡張性の高いストレージソ
リューション。Ceph は、DreamHost
の創設者により開発され、現在は実稼
動環境で使用されています。
Ceph は、異なる種類のストレージイ
ンターフェースをエンドユーザーに公
開するように設計されました。Ceph
は、オブジェクトストレージ、ブロッ
クストレージ、ファイルシステムイ
ンターフェースをサポートしています
が、ファイルシステムインターフェー
スは、実稼動環境での使用にはまだ適
していません。Ceph は、オブジェク
トストレージでは swift と同じ API
をサポートしており、cinder ブロッ
クストレージのバックエンド、glance
イメージのバックエンドストレージと
して使用することができます。Ceph
は、copy-on-write を使用して実装さ
れたシンプロビジョニングをサポート
します。
新規ボリュームは非常に早くプロビ
ジョニングされるため、ボリュームか
らの起動に便利です。また、Ceph は
76
OpenStack 運用ガイド
February 1, 2016
keystone ベースの認証 (バージョン
0.56 以降) もサポートするため、デ
フォルトの OpenStack swift 実装と
シームレスに切り替えることができま
す。
Ceph の利点は、管理者がより細かく
データの分散やレプリカのストラテ
ジーを管理できるようになり、オブ
ジェクトとブロックストレージを統合
し、シンプロビジョニングでボリュー
ムから起動するインスタンスを非常
に早くプロビジョニングできるだけ
でなく、分散ファイルシステムのイ
ンターフェースもサポートしている点
です。ただし、このインターフェース
は、Ceph プロジェクトによる実稼動
デプロイメントでの使用には、 推奨
されていません。
単一システムでオブジェクトストレー
ジとブロックストレージを管理する場
合、またはボリュームから素早く起動
するサポートが必要な場合、Ceph の
使用を検討してください。
Gluster
分散型の共有ファイルシステ
ム。Gluster バージョン 3.3 以
降、Gluster を使用して、オブジェ
クトストレージとファイルストレー
ジを1 つの統合ファイルとオブジェ
クトストレージソリューションにまと
めることができるようになりました。
これはGluster For OpenStack (GFO)
と呼ばれます。GFO は、swift のカ
スタマイズバージョンを使用してお
り、Gluster がバックエンドストレー
ジを使用できるようになっています。
通常の swift ではなく GFO を使用す
るのは、主に、分散ファイルシステム
のサポートや、共有ストレージのライ
ブマイグレーションのサポートを提供
したり、エンドユーザーに個別サービ
77
OpenStack 運用ガイド
February 1, 2016
スとして提供したりするためです。単
一システムでオブジェクトとファイル
ストレージを管理する場合は、GFO の
使用を検討してください。
LVM
論理ボリュームマネージャー (LVM)
は Linux ベースのシステムで、物理
ディスク上に抽象層を提供して論理
ボリュームをオペレーティングシス
テムに公開します。LVM バックエンド
は、LVM 論理パーティションとしてブ
ロックストレージを実装します。
ブロックストレージを収容する各ホス
トでは、管理者は事前にブロックスト
レージ専用のボリュームグループを作
成しておく必要があります。ブロック
ストレージはLVM論理ボリュームから
作られます。
注記
LVMはレプリケーション
を提供しません。通常、管
理者はブロックストレージ
としてLVMを利用するホス
ト上にRAIDを構成し、ここ
のハードディスク障害から
ブロックストレージを保護
します。しかしRAIDではホ
ストそのものの障害には対
応できません。
ZFS
OpenStack Block Storage 用の
Solaris iSCSI ドライバーは、ZFS エ
ンティティーとしてブロックを実装し
ます。ZFS は、ボリュームManagerの
機能が備わっているファイルシステ
ムです。これは、ボリュームマネー
ジャー (LVM) およびファイルシステ
ム (ext3、ext4、xfs、btrfs など)
が分離している Linux システムとは
違います。ZFS は、向上されたデータ
78
OpenStack 運用ガイド
February 1, 2016
整合性チェックなど、ext4 よりも多
数利点があります。
OpenStack Block Storage の ZFS
バックエンドは、Illumos などの
Solaris ベースのシステムのみをサ
ポートします。ZFS の Linux ポー
トは存在するものの、標準の Linux
ディストリビューションには含まれ
ておらず、OpenStack Block Storage
ではテストされていません。LVM で
は、ZFS はこれだけではホスト間の複
製ができません。つまり、お使いのク
ラウドでストレージノードの問題を処
理する機能が必要な場合、ZFS に複製
ソリューションを追加する必要があり
ます。
本書は、Linux ベースシステムを
主に使用するユーザーを想定してお
り、Block Storage の ZFS バック
エンドには Solaris ベースのオペ
レーティングシステムが必要であるた
め、ZFS でのデプロイ経験がない場合
は、ZFS は推奨していません。
Sheepdog
Sheepdog は、ユーザー空間の分散ス
トレージシステムです。数百ノード
までスケールします。スナップショッ
ト、複製、ロールバック、シンプロビ
ジョニングなどの高度な仮想ディスク
管理機能を持ちます。
ディスクを管理すること、コモディ
ティーハードウェアでスマートに
ハイパースケールするディスクの容
量および性能を集約することがオブ
ジェクトストレージシステムの本質
です。そのオブジェクトストアの上
で、Sheepdog は伸縮自在なボリュー
ムサービスと HTTP サービスを提供
します。Sheepdog は、カーネルバー
ジョンについて何も前提無く、xattr
79
OpenStack 運用ガイド
February 1, 2016
をサポートするファイルシステムでき
ちんと動作します。
まとめ
今後のクラウドユーザーにストレージのユースケースに関する質問事項
および、懸念点など理解いただけたかと思います。ストレージの決定は
パフォーマンスやセキュリティのニーズにあったネットワーク設計をす
る際に影響を与えます。OpenStack クラウド 設計 について理解したう
えで意思決定が行えるように、本書を読み進めてください。
80
OpenStack 運用ガイド
February 1, 2016
第7章 ネットワーク設計
管理ネットワーク ............................................
パブリックアドレスの選択肢 ..................................
IP アドレス計画 .............................................
ネットワークトポロジー ......................................
ネットワーク関係のサービス ..................................
まとめ ......................................................
81
82
82
84
86
87
OpenStackは様々なネットワーク環境を提供します。この章ではクラウド
を設計する際に必要な事項と慎重に決定すべきオプションの詳細を説明
します。
警告
これがあなたの組織で初めてのクラウド基盤構築であれば、
この章を読んだ後、最初にあなたの（組織の）ネットワー
ク管理チームと相談すべきです。クラウド運用におけるネッ
トワークの使用は伝統的なネットワーク構築とはかなり異な
り、接続性とポリシーレベルの両面で破壊的な結果をもたら
す可能性があります。
例えば、管理インフラだけでなくゲストインスタンス用のIPアドレスの
数も計画しなければなりません。加えて、プロキシサーバーやファイア
ウォールを経由してのクラウドネットワークの接続性を調査・議論する
必要があります。
この章では、いくつかのネットワーク構成の例を挙げながら、OpenStack
を使用したネットワークレイアウトについての情報を提供します。最後
に、安定稼働のたの重要な音とトワークサービスに関する注意事項を記
載します。
管理ネットワーク
管理用ネットワーク (クラウド管理者用の別のネットワーク) は一般的
には別のスイッチ別のNIC(Network Interface Cards)で構成する事が推
奨されます。この構成ではゲストのトラフィックによって監視と管理の
ためのアクセスが妨げられることを防ぎます。
メッセージキューや OpenStack コンピュート といった OpenStack 内部
のコンポーネント間の通信用に別のプライベートネットワークの作成を
検討して下さい。Virtual Local Area Network(VLAN) は1つの物理ネッ
トワークに複数の仮想ネットワークを作成できるのでこのシナリオに非
常に適しています。
81
OpenStack 運用ガイド
February 1, 2016
パブリックアドレスの選択肢
ゲストの仮想マシン用に主に2つのタイプのIPアドレス（固定IPアドレス
とフローティングIPアドレス）があります。固定IPアドレスはインスタ
ンス起動時に割り当てられ、フローティングIPアドレスは、ユーザ操作
によって割当が変更できます。どちらのタイプのIPアドレスも用途に合
わせてパブリックまたはプライベートにする事ができます。
固定 IP アドレスは必須ですが、フローティング IP アドレスはなくて
も OpenStack を実行する事が出来ます。フローティング IP の最も一般
的な用法の１つは、利用可能なIPアドレス数が限られているプライベー
トクラウドにパブリックIPアドレスを提供する事です。他にも、インス
タンスがアップグレード又は移動した際に割り当て可能な「静的」 IP
アドレスを持つパブリック・クラウドユーザ用です。
固定IPアドレスはプライベートクラウドではプライベートに、パブリッ
ククラウドではパブリックにする事が出来ます。インスタンスが削除さ
れる際、そのインスタンスの固定IPは割当を解除されます。クラウドコ
ンピューティングの初心者が一時的にストレスを感じる可能性がある事
に注意しましょう。
IP アドレス計画
OpenStackのインストールでは潜在的に多くのサブネット(IPアドレスの
範囲)　とそれぞれに異なるタイプのサービスを持つ可能性があります。
あるIPアドレスプランは、ネットワーク分割の目的とスケーラビリティ
の共有された理解を手助けします。コントロールサービスはパブリック
とプライベートIPアドレスを持つ事ができ、上記の通り、インスタンス
のパブリックアドレスとして2種類のオプションが存在します。
IPアドレス計画としては次のような用途で分類されるでしょう：
サブネットルーター
パケットが出て行く際に通るIPアド
レスで、これは専用のルータかnovanetwork サービスです。
コントロールサービス用パブ
リックインターフェース
swift-proxy, nova-api, glance-api,
horizon へのパブリックアクセスはこ
れらのアドレス宛にアクセスしてきま
す。これらのアドレスはロードバラン
サの片側か、個々の機器を指していま
す。
82
OpenStack 運用ガイド
February 1, 2016
Object Storage クラスタ内の
通信
オブジェクト/アカウント/コンテ
ナサービスの間とこれらとプロクシ
サーバーのインターフェイス間のト
ラフィックはこのプライベートネット
ワークを利用します。
コンピュートとストレージの通
信
一時ディスクまたはブロックストレー
ジがコンピュートノード以外にある場
合、このネットワークが使用されま
す。
帯域外管理リモート管理
専用のリモートアクセスコントロー
ラーチップがサーバーに搭載されてい
る場合、多くの場合、これらは独立し
たネットワーク上に置かれます。
帯域内リモート管理
システム管理者や監視ツールがパブ
リックインターフェース経由の代わ
りにコンピュートノードやストレージ
ノードのアクセスに使用するための追
加インターフェース(1GBなど)
将来のための余剰
パブリック側に置かれるコントロー
ラーサービスやゲストインスタンスの
IPの追加は、必ずアドレス計画の一部
として入れておくべきです。
例えば、OpenStack コンピュート と オブジェクトストレージ の両
方を使用し、プライベートアドレス範囲として 172.22.42.0/24 と
172.22.87.0/26 が利用できる場面を考えます。一例として、アドレス空
間を以下のように分割することができます。
172.22.42.0/24:
172.22.42.1
- 172.22.42.3 - subnet routers
172.22.42.4
- 172.22.42.20 - spare for networks
172.22.42.21 - 172.22.42.104 - Compute node remote access controllers
(inc spare)
172.22.42.105 - 172.22.42.188 - Compute node management interfaces (inc spare)
172.22.42.189 - 172.22.42.208 - Swift proxy remote access controllers
(inc spare)
172.22.42.209 - 172.22.42.228 - Swift proxy management interfaces (inc spare)
172.22.42.229 - 172.22.42.252 - Swift storage servers remote access controllers
(inc spare)
172.22.42.253 - 172.22.42.254 - spare
172.22.87.0/26:
172.22.87.1 - 172.22.87.3
- subnet routers
172.22.87.4 - 172.22.87.24 - Swift proxy server internal interfaces
(inc spare)
172.22.87.25 - 172.22.87.63 - Swift object server internal interfaces
(inc spare)
パブリックIPアドレスの場合でも同様のアプローチが取れます。但し、
ゲストインスタンス用のIPとして使用する場合には、大きなフラット
なアドレスレンジの方が好まれることに注意した方がよいでしょう。ま
83
OpenStack 運用ガイド
February 1, 2016
た、OpenStack のネットワーク方式によっては、ゲストインスタンス用
のパブリックIPアドレスレンジのうち一つが nova-compute ホストに割
り当てられることも考慮する必要があります。
ネットワークトポロジー
nova-networkを使用したOpenStackコンピュートはいくつかのあらかじめ
定義されたネットワークの実装モデルを提供しますが、それぞれ強みと
弱みがあります。ネットワークマネージャの選択はあなたのネットワー
クトポロジーを変更するので、慎重に選択するべきです。また、実証済
みでレガシーなnova-networkによる設定か、OpenStackネットワーキング
のためのneutronプロジェクトを採用するか決定する必要があります。イ
ンスタンスのネットワークの実装方法それぞれに異なる実装と要件があ
ります。
neutronプロジェクトを使用したOpenStackネットワークのための代表的
な構成は物理ハードウェアを使った物、ソフトウェア定義の環境を使
用して再作成できるものを使ったセットアップ方法を文書化されていま
す。それぞれのテナントはルータやDHCPサービスと言った一般的なネッ
トワーク構成要素を提供する事ができます。
表7.1「ネットワーク構成オプション」 [84] レガシーな novanetworkおオプションとそれと同等なneutron構成オプションについて述
べます。
表7.1 ネットワーク構成オプション
ネットワーク構成
モデル
長所
短所
Neutronでの実装
Flat
極めて単純なトポロ
ジー。
ネットワークインター
フェースの設定にはイン
スタンスへのファイルの
注入が必須です。
インテグレーションブリッジ(brint)として1つのブリッジを構成
し、Open vSwitchをデフォルトとし
て使うModuler Layer2(ML2)プラグ
インでbr-intと物理ネットワークイ
ンターフェースを接続します。
専用の DHCP ブロード
キャストドメインが必
要。
DHCPエージェントとルーティ
ングエージェントを構成しま
す。Network Address Translation
(NAT) によってコンピュートノード
と外部を接続します。一般的に1つ
以上のネットワークノードで成り立
ちます。
少し複雑な構成。
独立テナントネットワークは個々
のネットワーク間のレイヤー2トラ
フィックをいくつかの方法で分離す
る事で実装します。タグVLANはキー
コンセプトでトラフィックをどこに
流すかを”タグ”で決定します。独
DHCPによるオーバー
ヘッドがありません。
FlatDHCP
比較的シンプルな構成
標準的なネットワー
ク。
どんなゲストOSでも動
きます。
VlanManager
それぞれのテナントは
自身のVLANによって独
立しています。
84
専用の DHCP ブロード
キャストドメインが必
要。
OpenStack 運用ガイド
ネットワーク構成
モデル
February 1, 2016
長所
短所
Neutronでの実装
一つのポートに多数の
VLAN をトランクが必
要。
立テナントネットワークにはDHCPや
NAT、ルーティングと言った追加の
サービスが含まれるかもしれません
し、含まれないかもしれません。
標準的な VLAN 数の上
限。
802.1q VLAN タギングに
対応したスイッチが必
要。
高可用性(HA)のた
めのフラットDHCP
マルチホスト構成
ネットワーク障害は影
響を受けるハイパーバ
イザーのVMに限定され
ます。
DHCP トラフィックは
個々のホスト内に閉じ
込めることができる。
ネットワークトラ
フィックをコンピュー
トノード全体に分散で
きる。
少し複雑な構成。
コンピュートノードは概
して外部ネットワークか
らアクセス可能なIPアド
レスが必要です。
ネットワークサービスが
正しく動くようにライブ
マイグレーションを設定
するためには注意してオ
プションを構成する必要
があります。
複数のDHCPおよびレイヤ-3エージェ
ントを持つようなneutronの構成で
は、ネットワークノードは互いに
フェールオーバできませんのでコ
ントローラはDHCPといったネット
ワークサービスを実行します。コン
ピュートノードはOpen vSwitchまた
はLinux Bridgeといったエージェン
トをサポートするML2プラグインを
実行します。
nova-networkとneutronサービスはVM間でのVLANといった似通った可用性
を提供します。また、それぞれのサービスで複数のNICを付与したVMも提
供する事ができます。
OpenStack VM内のVLAN設定
VLAN設定は要求によっては複雑であったり単純であったりする事ができ
ます。VLANを使用すると互いのプロジェクトに専用のサブネットを提供
でき、ブロードキャストドメインを分割するという利点が得られます。
効果的にVLANを使用できるようにするには、VLANの範囲を(それぞれのプ
ロジェクトに1つずつ)割り当て、各コンピュートノードのポートをトラ
ンクポートに変更する必要があります。
例えば、あなたのクラウドでサポートする必要があるプロジェクト数が
最大で100と見込まれる場合、ネットワークインフラで現在使用されてい
ない VLAN の範囲を選んで下さい (例えば VLAN 200 - 299)。この VLAN
の範囲を OpenStack に設定するとともに、この範囲の VLAN トラフィッ
クを許可するようにスイッチポートを設定しなければいけません。
マルチNICプロビジョニング
neutron を用いた OpenStack Networking と nova-network を用いた
OpenStack Compute は、インスタンスに複数の NIC を割り当てる機能
85
OpenStack 運用ガイド
February 1, 2016
を持ちます。nova-network の場合、サブネットや VLAN 全体まで使用で
きる追加 NIC をそれぞれ使用して、これはリクエストごとに実行できま
す。これにより合計プロジェクト数を減らせます。
マルチホストあるいはシングルホストネットワー
キング
nova-networkはマルチホストまたはシングルホストモードで運用する事
ができます。マルチホスト構成はそれぞれのコンピュートノードでnovanetwork の複製とそのコンピュートノードのインスタンスが稼働してい
る時、コンピュートノードをインターネットへのゲートウェイとして利
用します。また、そのコンピュートノードはそこで稼働しているインス
タンスのフローティングIPアドレスとセキュリティグループを受け持ち
ます。シングルホスト構成はクラウドコントローラと言った中央サーバ
がnova-network サービスを受け持ちます。すべてのコンピュートノード
はインターネットへのトラフィックをコントローラに転送します。クラ
ウドコントローラがすべてのコントローラ上のすべてのインスタンスの
フローティングIPアドレスとセキュリティグループを受け持ちます。
どちらのモードにもメリットがあります。シングルホストモードには、
単一障害点というマイナス面があります。クラウドコントローラーが
利用できなくなると、インスタンスはネットワークと通信できなくな
ります。マルチホストモードでは、この状況にはなりませんが、各コン
ピュートノードはインターネットと通信するためのパブリックIPアドレ
スが必要となります。十分な大きさのパブリックIPアドレスブロックを
取得できない場合には、マルチホストモードは選択肢にならないかもし
れません。
ネットワーク関係のサービス
多くのネットワークアプリケーションがそうであるようにOpenStackでも
NTPやDNS と言った適用するための数多くの検討事項があります。
NTP
時刻同期はOpenStackコンポーネントを継続運用する上で非常に重要な要
素です。正確な時間はインスタンスのスケジューリング、ボブジェクト
ストア内のオブジェクトのレプリケーションのエラーの回避や、さらに
はデバッグのためにログのタイムスタンプの一致という意味合いで必要
です。
OpenStack コンポーネントが稼働しているすべてのサーバは適切な
NTPサーバにアクセス可能であるべきです。 Network Time Protocol
86
OpenStack 運用ガイド
February 1, 2016
projectが提供しているパブリックサーバかローカルにNTPサーバを構築
するか決定する必要があるでしょう。
DNS
OpenStackは現在のところ nova-networkホストに起動しているdnsmasq
デーモンに則したDNSサービスの提供はしていません。インスタンスの新
IPアドレスに対するDNSレコードの更新のためにダイナミックDNSの構成
を検討する事ができます。また、インスタンスのIPアドレスに対応する
vm-203-0-113-123.example.comというような一般的な逆引きDNSサービス
の構成も検討する事ができます。
まとめ
IPアドレスレイアウトと利用できるトポロジーおよびサービスの知識を
武器にネットワークを構成する準備をする時が来ました。また、ネット
ワークをセキュアに保つために OpenStack セキュリティガイドを確認す
る事を忘れないでください。ネットワークチームと良い関係をとなる事
を願っています！
87
パート II. 運用
おめでとう！これでクラウドのための設計が固まりました。次は、OpenStack イン
ストールガイド(http://docs.openstack.org/ja/index.html#install-guides) を
見ることをお薦めします。ここには、あなたのクラウドで OpenStack パッケージ
や依存パッケージを手動でインストールする方法が手順を追って説明されていま
す。
オペレーターは OpenStack のデプロイに必要な手順に精通していることは重要で
すが、一方で、 Puppet や Chefといった構成管理ツールの検証評価をすることを
強くお勧めします。これらはデプロイ手順を自動化する手助けとなります。
このガイドの残りの部分では、OpenStack クラウドのデプロイが無事に行われ、イ
メージの追加、インスタンスの起動、ボリュームの追加が行えるようになっている
ものとします。
安定した運用に頭を切り替えるために、この文書の残りの部分をざっくりと読み、
感覚をつかんでおくことをお薦めします。これらの一部はあらかじめ読んでおく
と、長期運用に向けてのベストプラクティスを実践するのに役に立つことでしょ
う。その他の部分は、 (電源障害のような) 予期しないイベントが発生した場合や
特定の問題のトラブルシューティングをする場合に、リファレンスとして役に立つ
でしょう。
OpenStack 運用ガイド
February 1, 2016
第8章 環境の把握
管理目的での OpenStack Dashboard の使用 .....................
コマンドラインツール ........................................
ネットワークの検査 ..........................................
ユーザーとプロジェクト .....................................
稼働中のインスタンス .......................................
概要 .......................................................
91
91
99
100
100
101
本章では、作業環境を設定し、クラウドの全体像を概観するのに役立つ
内容を記載します。
管理目的での OpenStack Dashboard の使
用
クラウドの管理ユーザーとして OpenStack Dashboard を使用して、プ
ロジェクト、ユーザー、イメージ、フレーバーの作成および管理を行う
ことができます。ユーザーは Image service の設定に応じて、指定さ
れたプロジェクト内でイメージを作成/管理したり、共有したりするこ
とができます。通常、ポリシーの設定では、管理ユーザーのみがクォー
タの設定とサービスの作成/管理を行うことができます。ダッシュボード
には 管理 タブがあり、システムパネル と ユーザー管理タブ に分かれ
ています。これらのインターフェースにより、システム情報と使用状況
のデータにアクセスすることができるのに加えて、エンドユーザーが実
行可能な操作を設定することもできます。管理ユーザーとしてダッシュ
ボードを使用する方法についての詳しい説明は OpenStack 管理ユーザー
ガイド を参照してください。
コマンドラインツール
管理には、OpenStack コマンドラインインターフェース (CLI) ツールと
OpenStack Dashboard を組み合わせて使用することをお勧めします。他
のクラウドテクノロジーの使用経験のある一部のユーザーは、EC2 互換
API を使用している可能性があります。この API は、ネイティブの API
とは若干異なる命名規則を採用しています。この相違点について以下に
説明します。
コマンドラインクライアントは、ディストリビューションのパッケージ
からではなく、Python Package Index (PyPI) からインストールする
ことを強く推奨します。これは、クライアントの開発が活発に行われて
91
OpenStack 運用ガイド
February 1, 2016
おり、オペレーティングシステムのベンダーにより配布されたパッケー
ジのバージョンが任意の時点で無効になってしまう可能性が高いためで
す。
pip ユーティリティは、PyPI アーカイブからのパッケージインストール
の管理に使用するツールで、大半の Linux ディストリビューションの
python-pip パッケージに含まれています。各 OpenStack プロジェクト
にはそれぞれ独自のクライアントがあります。サイトで実行するサービ
スに応じて、以下のパッケージの一部またはすべてをインストールして
ください。
• python-novaclient (nova CLI)
• python-glanceclient (glance CLI)
• python-keystoneclient (keystone CLI)
• python-cinderclient (cinder CLI)
• python-swiftclient (swift CLI)
• python-neutronclient (neutron CLI)
ツールの導入
pip を使用して PyPI アーカイブからパッケージをインストール (また
はアップグレード) するには、root として以下のコマンドを実行しま
す。
# pip install [--upgrade] <package-name>
パッケージを削除するには、
# pip uninstall <package-name>
もし新しいバージョンのクライアントが必要な場合、-eフラグを指定す
ることで、アップストリームのgitリポジトリから直接導入できます。そ
の際は、Python egg名を指定しなければいけません。例えば、
# pip install -e \
git+https://git.openstack.org/openstack/python-novaclient#egg=python-novaclient
クラウド上で EC2 API をサポートする場合には、ユーザーと同じビュー
を表示できるように、euca2ools パッケージまたはその他の EC2 API
ツールもインストールする必要があります。EC2 API ベースのツールの
使用に関する内容の大半は本ガイドの対象範囲外となりますが、この
ツールで使用する認証情報の取得方法についての説明は記載していま
す。
92
OpenStack 運用ガイド
February 1, 2016
管理系コマンドラインツール
*-manage のコマンドラインツールも複数あります。これらは、プロジェ
クトのサービスとともにクラウドコントローラーにインストールされる
ので、別途インストールする必要はありません。
• nova-manage
• glance-manage
• keystone-manage
• cinder-manage
前述の CLI ツールとは異なり、*-manage ツールは、/etc/nova/
nova.conf などの設定ファイルへの読み取りアクセスが必要で、かつ
OpenStack に対してではなくデータベースに対して直接クエリーを実行
しなければならないため、クラウドコントローラーから root として実
行する必要があります。API エンドポイント.
警告
*-manage ツールの存在は、レガシーの問題です。OpenStack
プロジェクトでは、最終的には *-manage ツールの残りの機
能をすべて API ベースのツールに移行することを目標として
います。移行が完了するまで、*-manage ツール を必要とす
るメンテナンス操作は、クラウドコントローラーノード に
SSH 接続して実行する必要があります。
認証情報の取得方法
コマンドラインツールを使用して OpenStack クラウドに対してクエ
リーを実行するには、適切な認証情報が必要です。コマンドラインク
ライアントで使用する認証のクレデンシャルを取得する最も簡単な方法
は、OpenStack ダッシュボードを使用する方法です。プロジェクト を
選択し、プロジェクトタブをクリックし、コンピュートカテゴリーに
あるアクセスとセキュリティ をクリックします。アクセスとセキュリ
ティページにおいて、API アクセス タブをクリックして、OpenStack
RC ファイルのダウンロード と EC2 認証情報のダウンロード の 2 つ
のボタンを表示します。これらのボタンにより、コマンドラインツール
がサービスエンドポイントと認証情報の場所を知るのに必要な環境変数
を読み込むために、シェルで元データとして使用することのできるファ
イルを生成することができます。ダッシュボードにログインしたユー
ザーによって、openrc ファイルのファイル名が決定します (例: demo93
OpenStack 運用ガイド
February 1, 2016
openrc.sh)。admin としてログインした場合には、ファイル名は adminopenrc.sh となります。
出力は以下のようになります。
#!/bin/bash
# With the addition of Keystone, to use an openstack cloud you should
# authenticate against keystone, which returns a **Token** and **Service
# Catalog**. The catalog contains the endpoint for all services the
# user/tenant has access to--including nova, glance, keystone, swift.
#
# *NOTE*: Using the 2.0 *auth api* does not mean that compute api is 2.0.
# We use the 1.1 *compute api*
export OS_AUTH_URL=http://203.0.113.10:5000/v2.0
# With the addition of Keystone we have standardized on the term **tenant**
# as the entity that owns the resources.
export OS_TENANT_ID=98333aba48e756fa8f629c83a818ad57
export OS_TENANT_NAME="test-project"
# In addition to the owning entity (tenant), openstack stores the entity
# performing the action as the **user**.
export OS_USERNAME=demo
# With Keystone you pass the keystone password.
echo "Please enter your OpenStack Password: "
read -s OS_PASSWORD_INPUT
export OS_PASSWORD=$OS_PASSWORD_INPUT
警告
この場合には、パスワードがプレーンテキスト形式で保存さ
れないのがこの方法の利点となりますが、このスクリプト
を元データとして使用したり、実行したりする際には、パス
ワードが要求され、その回答は環境変数 OS_PASSWORD に保存
されます。この操作は対話的に実行される必要がある点は、
注意すべき重要なポイントです。 操作を非対話的に行う必要
がある場合には、値をスクリプトに直接に保存することも可
能ですが、その場合にはこのファイルのセキュリティとアク
セス権を極めて慎重に管理する必要があります。,
EC2 互換のクレデンシャルをダウンロードするには、プロジェクト、コ
ンピュート 、アクセスとセキュリティ、API アクセス の順に選択
し、EC2 認証情報のダウンロード ボタンを表示します。このボタンをク
リックすると、 サーバーの x509 証明書とシェルスクリプトフラグメン
トが含まれた ZIP が生成されます。これらのファイルは、デフォルトの
user-openrc とは異なり、クラウドのアイデンティティへのアクセスに
必要なすべての認証情報を含む有効なクレデンシャルなので、セキュリ
ティ保護された場所に新規ディレクトリを作成して、そこで ZIP ファイ
ルを展開します。cacert.pem、cert.pem、ec2rc.sh、および pk.pem が
含まれているはずです。ec2rc.sh には、以下と似たような内容が記述さ
れています:
#!/bin/bash
94
OpenStack 運用ガイド
February 1, 2016
NOVARC=$(readlink -f "${BASH_SOURCE:-${0}}" 2>/dev/null) ||\
NOVARC=$(python -c 'import os,sys; \
print os.path.abspath(os.path.realpath(sys.argv[1]))' "${BASH_SOURCE:-${0}}")
NOVA_KEY_DIR=${NOVARC%/*}
export EC2_ACCESS_KEY=df7f93ec47e84ef8a347bbb3d598449a
export EC2_SECRET_KEY=ead2fff9f8a344e489956deacd47e818
export EC2_URL=http://203.0.113.10:8773/services/Cloud
export EC2_USER_ID=42 # nova does not use user id, but bundling requires it
export EC2_PRIVATE_KEY=${NOVA_KEY_DIR}/pk.pem
export EC2_CERT=${NOVA_KEY_DIR}/cert.pem
export NOVA_CERT=${NOVA_KEY_DIR}/cacert.pem
export EUCALYPTUS_CERT=${NOVA_CERT} # euca-bundle-image seems to require this
alias ec2-bundle-image="ec2-bundle-image --cert $EC2_CERT --privatekey \
$EC2_PRIVATE_KEY --user 42 --ec2cert $NOVA_CERT"
alias ec2-upload-bundle="ec2-upload-bundle -a $EC2_ACCESS_KEY -s \
$EC2_SECRET_KEY --url $S3_URL --ec2cert $NOVA_CERT"
EC2 認証情報を環境に適用するには、ec2rc.sh ファイルを元データとし
ます。
API コールの検査
コマンドラインツールに --debug フラグを渡すことにより、実行する
OpenStack API コールを表示することができます。 例えば、以下のよう
になります。
# nova --debug list
この例は、クライアントからのHTTPリクエストとエンドポイントからの
レスポンスを表示しています。これはOpenStack APIを使ったカスタム
ツールを作る際に役立ちます。
cURL を使用したさらなる検査
コマンドラインツールの使用の根底にあるのは、HTTP を介して実行する
RESTful API である OpenStack API です。API と直接対話を行いたい場
合や、CLI ツールにバグがあることが疑われるために使用する必要があ
る場合があります。この場合の最善の対処方法は、 cURL と jq などの
他のツールを組み合わせて使用し、その応答から JSON を解析すること
です。
まずはじめに、クラウドの認証が必要です。あなたの認証情報を用い
て認証トークンを入手してください。
認証情報はユーザー名、パスワード、テナント (プロジェクト) の組み
合わせです。これらの値は、前述の openrc.sh から抽出することがで
きます。トークンにより、要求ごとに再認証する必要なく他のエンドポ
イントとの対話を行うことができます。トークンは通常 24 時間有効で
す。期限が切れると、401 (Unauthorized) の応答で警告され、トークン
をもう 1 つ要求することができます。
1. それではOpenStack サービスカタログを見てみましょう。
95
OpenStack 運用ガイド
February 1, 2016
$ curl -s -X POST http://203.0.113.10:35357/v2.0/tokens \
-d '{"auth": {"passwordCredentials": {"username":"test-user", \
"password":"test-password"}, \
"tenantName":"test-project"}}' \
-H "Content-type: application/json" | jq .
2. JSONレスポンスを読むことで、カタログを把握することができます。
次の要求での作業をより簡単に行うには、環境変数にトークンを保管
します。
$ TOKEN=`curl -s -X POST http://203.0.113.10:35357/v2.0/tokens \
-d '{"auth": {"passwordCredentials": {"username":"test-user", \
"password":"test-password"}, \
"tenantName":"test-project"}}' \
-H "Content-type: application/json" | jq -r .access.token.id`
これで、コマンドラインでトークンを $TOKEN として参照できるよう
になりました。
3. サービスカタログから、サービスエンドポイント (例: コンピュート)
を選択します。要求を試します。例えば、インスタンス (サーバー)
の一覧表示を行います。
$ curl -s \
-H "X-Auth-Token: $TOKEN" \
http://203.0.113.10:8774/v2/98333aba48e756fa8f629c83a818ad57/servers | jq .
API 要求の構成方法については、OpenStack API Reference を参照して
ください。jq を使用した応答についての詳しい説明は jq Manual を参
照してください。
上記の cURL コマンドで使用している -s flag は、進行状況メーターが
表示されないようにするために使用します。cURL コマンドの実行で問題
が生じた場合には、このオプションを削除してください。また、cURL コ
マンドのトラブルシューティングを行う場合には、-v フラグを指定して
より詳細な出力を表示すると役立ちます。cURL には他にも多数の役立つ
機能があります。全オプションは、man ページで参照してください。
サーバーとサービス
管理者は、利用可能な OpenStack ツールを使用して、OpenStack クラウ
ドが全体像を確認する方法がいくつかあります。本項では、クラウドの
概要、形態、サイズ、現在の状態についての情報を取得する方法につい
て説明します。
まず、あなたのOpenStackクラウドに属し、稼働しているサーバーを把握
することができます。
# nova-manage service list | sort
96
OpenStack 運用ガイド
February 1, 2016
出力は以下のようになります。
Binary
nova-cert
nova-compute
nova-compute
nova-compute
nova-compute
nova-compute
nova-conductor
nova-consoleauth
nova-network
nova-scheduler
Host
cloud.example.com
c01.example.com
c02.example.com
c03.example.com
c04.example.com
c05.example.com
cloud.example.com
cloud.example.com
cloud.example.com
cloud.example.com
Zone
nova
nova
nova
nova
nova
nova
nova
nova
nova
nova
Status State Updated_At
enabled :-) 2013-02-25 19:32:38
enabled :-) 2013-02-25 19:32:35
enabled :-) 2013-02-25 19:32:32
enabled :-) 2013-02-25 19:32:36
enabled :-) 2013-02-25 19:32:32
enabled :-) 2013-02-25 19:32:41
enabled :-) 2013-02-25 19:32:40
enabled :-) 2013-02-25 19:32:36
enabled :-) 2013-02-25 19:32:32
enabled :-) 2013-02-25 19:32:33
出力には、5 つのコンピュートノードと 1 つのクラウドコントローラー
が表示されています。スマイリーフェイス :-) が見えます。これはサー
ビスが稼働中であることを示しています。サービスが利用できなくなる
と、:-) のシンボルが XXX に変わります。これは、サービスが停止し
ている理由をトラブルシューティングする必要があることを示していま
す。
cinder を使用している場合は、次のコマンドを実行して同様の一覧を表
示します。
# cinder-manage host list | sort
host
c01.example.com
c02.example.com
c03.example.com
c04.example.com
c05.example.com
cloud.example.com
zone
nova
nova
nova
nova
nova
nova
これら2つの表で、どのサーバーとサービスがあなたのクラウドを構成し
ているのか、概要を知ることができました。
また、Identity (keystone) を使用してクラウドで利用可能なサービス
と、サービス用に設定済みのエンドポイントを確認することもできま
す。
以下のコマンドを実行するには、管理系の変数を正しく設定したシェル
環境が必要です。
$ openstack catalog list
+----------+------------+---------------------------------------------------------------------------------+
| Name
| Type
| Endpoints
|
+----------+------------+---------------------------------------------------------------------------------+
| nova
| compute
| RegionOne
|
|
|
|
publicURL: http://192.168.122.10:8774/v2/9faa845768224258808fc17a1bb27e5e
|
|
|
|
internalURL: http://192.168.122.10:8774/v2/9faa845768224258808fc17a1bb27e5e |
|
|
|
adminURL: http://192.168.122.10:8774/v2/9faa845768224258808fc17a1bb27e5e
|
|
|
|
|
| cinderv2 | volumev2
| RegionOne
|
|
|
|
publicURL: http://192.168.122.10:8776/v2/9faa845768224258808fc17a1bb27e5e
|
|
|
|
internalURL: http://192.168.122.10:8776/v2/9faa845768224258808fc17a1bb27e5e |
|
|
|
adminURL: http://192.168.122.10:8776/v2/9faa845768224258808fc17a1bb27e5e
|
|
|
|
|
97
OpenStack 運用ガイド
February 1, 2016
上記の出力は、2 つのサービスのみを表示するようにカットされていま
す。クラウドが提供するサービスごとにサービスエントリーが 1 つ表示
されているのがわかります。エンドポイントタイプによってエンドポイ
ントドメインが異なる場合がある点に注意してください。タイプによっ
てエンドポイントドメインを別にする必要はありませんが、エンドポイ
ントのプライバシーやネットワークトラフィックの分離などの異なる理
由で分けることができます。
インストールされている Compute のバージョンを確認するには、novamanagecommand を使用することができます:
# nova-manage version
コンピュートノードの診断
実行中の仮想マシンの CPU 使用状況、メモリー、ディスク I/O、ネット
ワーク I/O などの追加情報を取得するには、nova diagnostics コマン
ドにサーバー ID を指定して実行します:
$ nova diagnostics <serverID>
ハイパーバイザーによってサポートする属性が異なるため、コマンドの
出力はハイパーバイザーによって異なります。 以下の実例は、最もよく
使用されている 2 つのハイパーバイザーの間で出力がどのように異なる
かを示しています。ハイパーバイザーが Xen の場合の例は以下のように
なります:
+----------------+-----------------+
|
Property
|
Value
|
+----------------+-----------------+
| cpu0
| 4.3627
|
| memory
| 1171088064.0000 |
| memory_target | 1171088064.0000 |
| vbd_xvda_read | 0.0
|
| vbd_xvda_write | 0.0
|
| vif_0_rx
| 3223.6870
|
| vif_0_tx
| 0.0
|
| vif_1_rx
| 104.4955
|
| vif_1_tx
| 0.0
|
+----------------+-----------------+
このコマンドは、libvirt によって管理されている任意のハイパーバイ
ザー (例: KVM、QEMU、LXC) で機能するはずですが、KVM でのみテスト
済みです。ハイパーバイザーが KVM の場合の例は以下のようになります
98
OpenStack 運用ガイド
February 1, 2016
+------------------+------------+
| Property
| Value
|
+------------------+------------+
| cpu0_time
| 2870000000 |
| memory
| 524288
|
| vda_errors
| -1
|
| vda_read
| 262144
|
| vda_read_req
| 112
|
| vda_write
| 5606400
|
| vda_write_req
| 376
|
| vnet0_rx
| 63343
|
| vnet0_rx_drop
| 0
|
| vnet0_rx_errors | 0
|
| vnet0_rx_packets | 431
|
| vnet0_tx
| 4905
|
| vnet0_tx_drop
| 0
|
| vnet0_tx_errors | 0
|
| vnet0_tx_packets | 45
|
+------------------+------------+
ネットワークの検査
クラウドでどの Fixed IP ネットワークが設定されているかを確認する
には、 nova コマンドラインクライアントを使用して IP アドレスの範
囲を取得することができます:
$ nova network-list
+--------------------------------------+--------+--------------+
| ID
| Label | Cidr
|
+--------------------------------------+--------+--------------+
| 3df67919-9600-4ea8-952e-2a7be6f70774 | test01 | 10.1.0.0/24 |
| 8283efb2-e53d-46e1-a6bd-bb2bdef9cb9a | test02 | 10.1.1.0/24 |
+--------------------------------------+--------+--------------+
nova-manage ツールは、追加の情報を提供することが可能です:
# nova-manage network list
id IPv4
IPv6 start address DNS1 DNS2 VlanID project
1 10.1.0.0/24 None 10.1.0.3
None None 300
2725bbd
2 10.1.1.0/24 None 10.1.1.3
None None 301
none
uuid
beacb3f2
d0b1a796
この出力は、2 つのネットワークが設定されており、各ネットワークに
は 255 の IP アドレス (/24 サブネットが 1 つ) が含まれていること
を示しています。1 番目のネットワークは、特定のプロジェクトに割り
当て済みですが、2 番目のネットワークはまだ割り当てができる状態で
す。このネットワークは手動で割り当てることができます。手動での割
り当てを行わなかった場合には、プロジェクトで最初のインスタンスが
起動されたときに自動で割り当てられます。
99
OpenStack 運用ガイド
February 1, 2016
クラウドに利用可能な Floating IP アドレスがあるかどうかを確認する
には、以下のコマンドを実行します。
# nova-manage floating list
2725bb...59f43f 1.2.3.4 None
nova vlan20
None
1.2.3.5 48a415...b010ff nova vlan20
この場合は、2 つの Floating IP アドレスが利用可能です。最初の IP
アドレスはプロジェクトに確保されていますが、もう一方は確保されて
いません。
ユーザーとプロジェクト
クラウドに追加されたプロジェクトの一覧を確認するには、以下のコマ
ンドを実行します:
$ openstack project list
+----------------------------------+--------------------+
| ID
| Name
|
+----------------------------------+--------------------+
| 422c17c0b26f4fbe9449f37a5621a5e6 | alt_demo
|
| 5dc65773519248f3a580cfe28ba7fa3f | demo
|
| 9faa845768224258808fc17a1bb27e5e | admin
|
| a733070a420c4b509784d7ea8f6884f7 | invisible_to_admin |
| aeb3e976e7794f3f89e4a7965db46c1e | service
|
+----------------------------------+--------------------+
ユーザーのリストを見るためには、
$ openstack user list
+----------------------------------+----------+
| ID
| Name
|
+----------------------------------+----------+
| 5837063598694771aedd66aa4cddf0b8 | demo
|
| 58efd9d852b74b87acc6efafaf31b30e | cinder
|
| 6845d995a57a441f890abc8f55da8dfb | glance
|
| ac2d15a1205f46d4837d5336cd4c5f5a | alt_demo |
| d8f593c3ae2b47289221f17a776a218b | admin
|
| d959ec0a99e24df0b7cb106ff940df20 | nova
|
+----------------------------------+----------+
注記
ユーザーとグループは、一対一でマッピングさ
れる場合があります。このようなマッピングは
cinder、glance、nova、swift などの標準システムアカウン
トや、グループにユーザーが 1 人しかいない場合に発生しま
す。
稼働中のインスタンス
実行中のインスタンスを確認するには、以下のコマンドを実行します:
$ nova list --all-tenants
100
OpenStack 運用ガイド
February 1, 2016
+-----+------------------+--------+-------------------------------------------+
| ID | Name
| Status | Networks
|
+-----+------------------+--------+-------------------------------------------+
| ... | Windows
| ACTIVE | novanetwork_1=10.1.1.3, 199.116.232.39
|
| ... | cloud controller | ACTIVE | novanetwork_0=10.1.0.6; jtopjian=10.1.2.3 |
| ... | compute node 1
| ACTIVE | novanetwork_0=10.1.0.4; jtopjian=10.1.2.4 |
| ... | devbox
| ACTIVE | novanetwork_0=10.1.0.3
|
| ... | devstack
| ACTIVE | novanetwork_0=10.1.0.5
|
| ... | initial
| ACTIVE | nova_network=10.1.7.4, 10.1.8.4
|
| ... | lorin-head
| ACTIVE | nova_network=10.1.7.3, 10.1.8.3
|
+-----+------------------+--------+-------------------------------------------+
残念ながら、このコマンドは、インスタンスを実行しているコンピュー
トノードやインスタンスのフレーバーなどのような、実行中のインスタ
ンスについての多様な情報は提供しません。個別のインスタンスについ
ての詳しい情報を確認するには以下のコマンドを使用してください:
$ nova show <uuid>
例えば、
# nova show 81db556b-8aa5-427d-a95c-2a9a6972f630
+-------------------------------------+-----------------------------------+
| Property
| Value
|
+-------------------------------------+-----------------------------------+
| OS-DCF:diskConfig
| MANUAL
|
| OS-EXT-SRV-ATTR:host
| c02.example.com
|
| OS-EXT-SRV-ATTR:hypervisor_hostname | c02.example.com
|
| OS-EXT-SRV-ATTR:instance_name
| instance-00000029
|
| OS-EXT-STS:power_state
| 1
|
| OS-EXT-STS:task_state
| None
|
| OS-EXT-STS:vm_state
| active
|
| accessIPv4
|
|
| accessIPv6
|
|
| config_drive
|
|
| created
| 2013-02-13T20:08:36Z
|
| flavor
| m1.small (6)
|
| hostId
| ...
|
| id
| ...
|
| image
| Ubuntu 12.04 cloudimg amd64 (...) |
| key_name
| jtopjian-sandbox
|
| metadata
| {}
|
| name
| devstack
|
| novanetwork_0 network
| 10.1.0.5
|
| progress
| 0
|
| security_groups
| [{u'name': u'default'}]
|
| status
| ACTIVE
|
| tenant_id
| ...
|
| updated
| 2013-02-13T20:08:59Z
|
| user_id
| ...
|
+-------------------------------------+-----------------------------------+
この出力は、devstack という名前のインスタンスが Ubuntu 12.04 イ
メージから m1.small のフレーバーで作成され、コンピュートノード
c02.example.com でホストされていることを示しています。
概要
クラウドとの対話や有用な情報の抽出の方法など、作業環境の概観を確
認する手順を簡単にご紹介しました。役立てていただければ幸いです。
ここで説明した内容よりもさらに詳しい情報は、クラウドの全コマンド
101
OpenStack 運用ガイド
February 1, 2016
ライン機能についての参考資料として管理ユーザーガイドを参照してく
ださい。
102
OpenStack 運用ガイド
February 1, 2016
第9章 プロジェクトとユーザーの
管理
プロジェクトかテナントか? ..................................
プロジェクトの管理 .........................................
クォータ ...................................................
ユーザー管理 ...............................................
新規ユーザーの作成 .........................................
プロジェクトへのユーザーの割り当て ..........................
概要 .......................................................
103
104
106
116
116
118
123
OpenStack クラウドは、ユーザーなしでは特に価値はありません。本章
では、ユーザー、プロジェクト、クォータの管理に関するトピックを記
載します。また、OpenStack Identity API のバージョン 2 で説明され
ているように、ユーザーとプロジェクトについても説明します。
警告
Identity API バージョン 3 が利用できますが、クライアン
トツールにはこれらの呼び出しがまだ実装されておらず、多
くの OpenStack クラウドは Identity API v2.0 を実装して
います。
プロジェクトかテナントか?
OpenStack ユーザーインターフェースとドキュメントでは、ユーザーの
グループは プロジェクト または テナント と呼ばれます。これらの用
語は同義です。
OpenStack Compute の初期実装は独自の認証システムを持ち、プロ
ジェクトという用語を使用していました。認証が OpenStack Identity
(Keystone) プロジェクトに移行したとき、ユーザーのグループを参照
するためにテナントという用語が使用されました。このような経緯のた
め、いくつかの OpenStack ツールはプロジェクトを使用し、いくつかは
テナントを使用します。
ヒント
このガイドはプロジェクトという用語を使用します。テナン
トという用語を使用するツールとやりとりする例もありま
す。
103
OpenStack 運用ガイド
February 1, 2016
プロジェクトの管理
ユーザーは、多数のプロジェクトに所属することは可能ですが、最低で
も 1 つのプロジェクトと関連付ける必要があります。そのため、ユー
ザー追加の前にプロジェクトを 1 つ追加しておく必要があります。
プロジェクトの追加
OpenStack Dashboard でプロジェクトを作成します。
1. 管理ユーザーとしてログインします。
2. 左側にあるナビゲーションバーの ユーザー管理 タブを選択します。
3. ユーザー管理タブの プロジェクト をクリックします。
4. プロジェクトの作成 ボタンをクリックします。
プロジェクト名および任意の説明 (推奨) が要求されます。フォームの
一番下のチェックボックスを選択してこのプロジェクトを有効にしま
す。図9.1「Dashboard のプロジェクトの作成フォーム」 [105]のよう
に、デフォルトでは、有効になっています。
104
OpenStack 運用ガイド
February 1, 2016
図9.1 Dashboard のプロジェクトの作成フォーム
プロジェクトメンバーの追加やプロジェクトのクォータの調節も可能で
す。このようなアクションについては後ほど説明しますが、実際にこれ
らの操作を扱うと非常に便利です。
コマンドラインからのプロジェクト追加する場合、OpenStack コマンド
ラインクライアントを使用する必要があります。
# openstack project create demo
このコマンドは、demo という名前のプロジェクトを作成します。オプ
ションで、--description tenant-description を追加することで、説
105
OpenStack 運用ガイド
February 1, 2016
明の文字列を追加することができ、非常に便利です。また、コマンド
に --disable を追加して、グループを無効な状態で作成することもでき
ます。デフォルトでは、有効化された状態でプロジェクトが作成されま
す。
クォータ
システムの容量が通知なしに完全に消費されないように、クォータ を
設定することができます。クォータとは、運用上の制限値です。たとえ
ば、各テナントに許容される容量 (GB) を制御して、単一のテナントで
全ディスク容量すべてが消費されないようにします。現在、ユーザーレ
ベルではなく、テナント (またはプロジェクト) レベルで、クォータを
有効にすることができます。
警告
妥当なクォータがないと、単一のテナントが利用可能なリ
ソースをすべて使用してしまう可能性があるため、デフォル
トのクォータが OpenStack には含まれています。お使いの
ハードウェア機能には、どのクォータ設定が適切か注意して
ください。
コマンドラインインターフェースを使って、OpenStack Compute と
Block Storage のクォータを管理できます。
テナントには、10 個を超える Block Storage ボリュームまたはコン
ピュートノードで 1 TB 以上が必要であるため、通常クラウドのオペ
レーターはデフォルト値を変更します。
注記
全てのテナントを表示するには、以下のコマンドを実行しま
す。
$ openstack project list
+---------------------------------+----------+
| ID
| Name
|
+---------------------------------+----------+
| a981642d22c94e159a4a6540f70f9f8 | admin
|
| 934b662357674c7b9f5e4ec6ded4d0e | tenant01 |
| 7bc1dbfd7d284ec4a856ea1eb82dca8 | tenant02 |
| 9c554aaef7804ba49e1b21cbd97d218 | services |
+---------------------------------+----------+
106
OpenStack 運用ガイド
February 1, 2016
イメージクォータの設定
プロジェクトのイメージ保存容量を合計バイト数で制限できます。現
在、このクォータはクラウド全体に適用されます。そのため、イメージ
のクォータを 5 GB に設定する場合、クラウドの全プロジェクトが、5
GB 以内のイメージやスナップショットのみを保存できます。
この機能を有効にするには、/etc/glance/glance-api.conf ファイルを
編集して [DEFAULT] セクションに以下を追加します。
user_storage_quota = <bytes>
たとえば、プロジェクトのイメージストレージを 5GB に制限するには、
以下を実行します。
user_storage_quota = 5368709120
注記
イメージごとに許可されるメンバーの数を制限す
る、glance-api.conf の設定オプションがあります。これ
は、image_member_quota であり、デフォルトで 128 です。
その設定は、保存容量のクォータとは別のクォータです。
コンピュートサービスのクォータの設定
管理ユーザーは、既存のテナントの Compute のクォータを更新できま
す。また、新規テナントのクォータのデフォルト値を更新することもで
きます。 表9.1「Compute のクォータの説明」 [107] を参照してくださ
い。
表9.1 Compute のクォータの説明
クォータ
説明
プロパティ名
固定 IP
テナント毎の固定 IP アドレスの最大
数。この数はテナント毎の最大インスタ
ンス数以上にしなければなりません。
fixed-ips
Floating IP
テナントごとの最大 Floating IP 数
floating-ips
注入ファイルの
injected file あたりの最大バイト数
コンテンツ (バイ
ト)
injected-file-content-bytes
注入ファイルのパ injected file のパス長の最大バイト数
ス (バイト)
injected-file-path-bytes
注入ファイル
injected file の最大数
injected-files
インスタンス
テナントごとの最大インスタンス数
instances
107
OpenStack 運用ガイド
February 1, 2016
クォータ
説明
プロパティ名
キーペア
ユーザーごとの最大キーペア数
key-pairs
メタデータ項目
インスタンスごとのメタデータ項目数
metadata-items
メモリー
テナントごとのインスタンスの RAM 容量 ram
（メガバイト単位）
セキュリティグ
ループルール
セキュリティグループごとのセキュリ
ティルール数
security-group-rules
セキュリティグ
ループ
テナントごとのセキュリティグループ数
security-groups
仮想 CPU
テナントごとのインスタンスのコア数
cores
テナント (プロジェクト) のコンピュートクォータの表示/
更新
管理ユーザーは nova quota-* コマンドを使って、テナントのクォータ
を表示したり更新したりできます。コマンドは python-novaclient パッ
ケージに含まれます。
デフォルトのクォータ値の表示と更新
1.
全テナントに対するクォータのデフォルト値を全て表示するには、
以下のようにします。
$ nova quota-defaults
例えば
$ nova quota-defaults
+-----------------------------+-------+
| Property
| Value |
+-----------------------------+-------+
| metadata_items
| 128
|
| injected_file_content_bytes | 10240 |
| ram
| 51200 |
| floating_ips
| 10
|
| key_pairs
| 100
|
| instances
| 10
|
| security_group_rules
| 20
|
| injected_files
| 5
|
| cores
| 20
|
| fixed_ips
| -1
|
| injected_file_path_bytes
| 255
|
| security_groups
| 10
|
+-----------------------------+-------+
2.
新規テナントに対するクォータのデフォルト値を更新するには、以
下のようにします。
108
OpenStack 運用ガイド
February 1, 2016
$ nova quota-class-update default key value
例えば
$ nova quota-class-update default --instances 15
109
OpenStack 運用ガイド
February 1, 2016
テナント (プロジェクト) のクォータ値の表示
1.
テナント ID を変数に格納します。
$ tenant=$(openstack project list | awk '/tenantName/ {print $2}')
2.
テナントの現在のクォータ値を一覧表示します。
$ nova quota-show --tenant $tenant
例えば
$ nova quota-show --tenant $tenant
+-----------------------------+-------+
| Property
| Value |
+-----------------------------+-------+
| metadata_items
| 128
|
| injected_file_content_bytes | 10240 |
| ram
| 51200 |
| floating_ips
| 12
|
| key_pairs
| 100
|
| instances
| 10
|
| security_group_rules
| 20
|
| injected_files
| 5
|
| cores
| 20
|
| fixed_ips
| -1
|
| injected_file_path_bytes
| 255
|
| security_groups
| 10
|
+-----------------------------+-------+
テナント (プロジェクト) のクォータ値の更新
1.
テナント ID を取得します。
$ tenant=$(openstack project list | awk '/tenantName/ {print $2}')
2.
指定したクォータ値を更新します。
# nova quota-update --quotaName quotaValue tenantID
例えば
# nova quota-update --floating-ips 20 $tenant
# nova quota-show --tenant $tenant
+-----------------------------+-------+
| Property
| Value |
+-----------------------------+-------+
| metadata_items
| 128
|
| injected_file_content_bytes | 10240 |
| ram
| 51200 |
| floating_ips
| 20
|
110
OpenStack 運用ガイド
February 1, 2016
| key_pairs
| 100
|
| instances
| 10
|
| security_group_rules
| 20
|
| injected_files
| 5
|
| cores
| 20
|
| fixed_ips
| -1
|
| injected_file_path_bytes
| 255
|
| security_groups
| 10
|
+-----------------------------+-------+
注記
以下を実行して、quota-update コマンドのオプションリ
ストを表示します。
$ nova help quota-update
Object Storage のクォータの設定
現在、Object Storage に対する 2 種類のクォータがあります。
コンテナーの
クォータ
1 つのコンテナーに保存できる、オブジェクトの容量
(バイト単位) や個数の合計を制限します。
アカウントの
クォータ
ユーザーが Object Storage サービス で利用できる合計
容量 (バイト単位) を制限します。
コンテナーのクォータやアカウントのクォータの利点を得るため
に、Object Storage のプロキシーサーバーが container_quotas や
account_quotas (または両方) を [pipeline:main] パイプラインに追
加するする必要があります。各クォータの種類は、proxy-server.conf
ファイルにそれ自身のセクションも必要とします。
[pipeline:main]
pipeline = catch_errors [...] slo dlo account_quotas proxy-server
[filter:account_quotas]
use = egg:swift#account_quotas
[filter:container_quotas]
use = egg:swift#container_quotas
Object Storage クォータを表示および更新するためには、pythonswiftclient パッケージにより提供される swift コマンドを使用しま
す。プロジェクト内のユーザーは誰でも、そのプロジェクトに設定さ
れているクォータを表示できます。プロジェクトの Object Storage
111
OpenStack 運用ガイド
February 1, 2016
クォータを更新する場合、クォータを適用するプロジェクトにおいて
ResellerAdmin ロールを持つ必要があります。
112
OpenStack 運用ガイド
February 1, 2016
プロジェクトのアカウントのクォータを表示します。
$ swift stat
Account: AUTH_b36ed2d326034beba0a9dd1fb19b70f9
Containers: 0
Objects: 0
Bytes: 0
Meta Quota-Bytes: 214748364800
X-Timestamp: 1351050521.29419
Content-Type: text/plain; charset=utf-8
Accept-Ranges: bytes
プロジェクトのアカウントのクォータを適用または更新します。
$ swift post -m quota-bytes:
<bytes>
例として、アカウントに 5 GB のクォータを設定します。
$ swift post -m quota-bytes:
5368709120
再び swift stat コマンドを実行して、クォータを検証します。
$ swift stat
Account: AUTH_b36ed2d326034beba0a9dd1fb19b70f9
Containers: 0
Objects: 0
Bytes: 0
Meta Quota-Bytes: 5368709120
X-Timestamp: 1351541410.38328
Content-Type: text/plain; charset=utf-8
Accept-Ranges: bytes
Block Storage のクォータの設定
管理ユーザーは、既存のテナントの Block Storage のクォータを更新で
きます。また、新規テナントのクォータのデフォルト値を更新すること
もできます。表9.2「Block Storage のクォータの説明」 [113] を参照
してください。
表9.2 Block Storage のクォータの説明
プロパティ名
説明
gigabytes
テナントごとのボリューム容量の最大値（単位はギガバイト）
snapshots
テナントごとのブロックストレージスナップショット数
volumes
テナントごとのブロックストレージボリューム数
113
OpenStack 運用ガイド
February 1, 2016
114
OpenStack 運用ガイド
February 1, 2016
Block Storage サービスのテナント (プロジェクト) の
クォータの表示と更新
管理ユーザーは cinder quota-* コマンドを使って、テナントのクォー
タを表示したり更新したりできます。コマンドは python-cinderclient
パッケージに含まれます。
Block Storage のデフォルトのクォータ値の表示と更新
1.
全テナントに対するクォータのデフォルト値を全て表示するには、
以下のようにします。
$ cinder quota-defaults
例えば
$ cinder quota-defaults
+-----------+-------+
| Property | Value |
+-----------+-------+
| gigabytes | 1000 |
| snapshots |
10 |
| volumes |
10 |
+-----------+-------+
2.
新規テナントのクォータのデフォルト値を更新するには、/etc/
cinder/cinder.conf ファイルの対応する項目を更新します。
プロジェクトの Block Storage クォータの表示方法
•
特定のテナントのクォータを表示するには以下のようにします。
# cinder quota-show tenantName
例えば
# cinder quota-show tenant01
+-----------+-------+
| Property | Value |
+-----------+-------+
| gigabytes | 1000 |
| snapshots |
10 |
| volumes |
10 |
+-----------+-------+
プロジェクトの Block Storage クォータの更新方法
1.
テナント ID を変数に格納します。
115
OpenStack 運用ガイド
February 1, 2016
$ tenant=$(openstack project list | awk '/tenantName/ {print $2}')
2.
指定したクォータ値を更新します。
# cinder quota-update --quotaName NewValue tenantID
例:
# cinder quota-update --volumes 15 $tenant
# cinder quota-show tenant01
+-----------+-------+
| Property | Value |
+-----------+-------+
| gigabytes | 1000 |
| snapshots |
10 |
| volumes |
15 |
+-----------+-------+
ユーザー管理
直接コマンドラインツールを使ってユーザーを管理することは面倒で
す。一つの作業を完了するために、複数のコマンドを実行する必要があ
ります。多くの項目に対して、シンボル名の代わりに UUID を使用しま
す。現実的に、人間はこれらのツールをそのまま使用しません。幸運な
ことに、OpenStack dashboard が便利なインターフェースを提供してい
ます。さらに、多くのサイトは個別の要求を満たすために独自ツールを
作成し、サイト固有のポリシーを適用し、パッケージツールでは実現で
きないレベルのセルフサービスをユーザーに提供しています。
新規ユーザーの作成
ユーザーを作成するには、以下の情報が必要です。
• ユーザー名
• 電子メールアドレス
• パスワード
• 主プロジェクト
• 役割
ユーザー名と電子メールアドレスは見たとおりです。あなたのサイトは
従うべき独自ルールがあるかもしれません。主プロジェクトは単にユー
116
OpenStack 運用ガイド
February 1, 2016
ザーが割り当てられる最初のプロジェクトです。ユーザーを作成する前
に存在している必要があります。役割は多くの場合ずっと "メンバー"
のままになります。標準の状態で、OpenStack は次の 2 つの役割が定義
されています。
117
OpenStack 運用ガイド
February 1, 2016
member
一般的なユーザー
admin
すべてのプロジェクトにわたり全権限を持つ管理ユーザー。非
常に注意して使用する必要があります。
他の役割を定義できますが、一般的にはそうしません。
一度この情報を収集すると、ダッシュボードでのユーザーの作成は、こ
れまでに見てきた他の Web フォームと同じです。"ユーザー管理" ナビ
ゲーションバーの "ユーザー" リンクにあります。そして、右上にある
"ユーザーの作成" ボタンをクリックします。
ユーザー情報の変更は、この "ユーザー” ページから実行することも
できます。かなり多くのユーザーがいるならば、このページにはたくさ
んのユーザーが表示されることでしょう。ページの上部にある "フィル
ター" 検索ボックスを使うと、表示されるユーザーの一覧を絞り込むこ
とができます。変更しようとしているユーザーの行末にあるアクション
ドロップダウンメニューの ”編集” を選択することにより、ユーザー
作成ダイアログと非常に似ているフォームを表示できます。
プロジェクトへのユーザーの割り当て
多くのサイトは一つのプロジェクトのみに割り当てられているユーザー
で実行しています。これは、管理者にとってもユーザーにとっても、よ
り保守的で分かりやすい選択です。管理の面では、ユーザーからインス
タンスやクォータに関する問題の報告があった場合、どのプロジェクト
に関するものかが明確です。ユーザーが一つのプロジェクトのみに所属
している場合、ユーザーがどのプロジェクトで操作しているのかを気に
する必要がありません。ただし、既定の設定では、どのユーザーも同じ
プロジェクトにいる他のユーザーのリソースに影響を与えることができ
ることに注意してください。あなたの組織にとって意味があるならば、
ユーザーを複数のプロジェクトに割り当てることも可能です。
既存のユーザーを追加のプロジェクトに割り当てる、または古いプロ
ジェクトから削除することは、図9.2「プロジェクトメンバーの編集 タ
ブ」 [119] にあるとおり、ダッシュボードのプロジェクトページから、
アクション列のユーザーの変更を選択することにより実行できます。
このビューから、数多くの有用な操作、いくつかの危険な操作を実行で
きます。
"すべてのユーザー (All Users)" という見出しが付けられた、この
フォームの最初の列に、このプロジェクトにまだ割り当てられていな
118
OpenStack 運用ガイド
February 1, 2016
い、クラウドのすべてのユーザーが一覧表示されます。2 列目には、
すべての割り当て済みユーザーが一覧表示されます。これらの一覧は非
常に長い可能性があります。しかし、それぞれの列の上部にあるフィル
ターフィールドに、探しているユーザー名の部分文字列を入力すること
により、表示を絞り込むことができます。
ここから、プロジェクトにユーザーを追加するには + アイコンをクリッ
クします。削除するには - をクリックします。
図9.2 プロジェクトメンバーの編集 タブ
危険な点としては、メンバーの役割を変更する機能があることです。こ
れはプロジェクトメンバー 一覧のユーザー名の後ろにあるドロップダ
ウンリストです。事実上すべての場合で、この値はメンバーに設定され
ています。この例では意図的に、この値が管理者になっている管理ユー
ザーを示しています。
警告
管理者はプロジェクトごとではなく、グローバルです。その
ため、ユーザーに管理者の役割を与えることにより、クラウ
ド全体にわたるユーザー管理権限を与えることになります。
一般的な使用法は、一つのプロジェクトだけに管理ユーザーを所属させ
ることです。慣例により、"admin" プロジェクトがクラウド環境のセッ
トアップ中に標準で作成されます。管理ユーザーもクラウドを使用して
インスタンスの起動、管理を行う場合には、管理アクセスと一般アクセ
ス用に別々のユーザーアカウントを使用し、それらのユーザーを別々の
プロジェクトにすることを強く推奨します。
119
OpenStack 運用ガイド
February 1, 2016
権限のカスタマイズ
デフォルトの認可設定では、管理ユーザーのみが他のプロジェクトのリ
ソースを作成できます。OpenStack では以下の 2 種類の認可ポリシーを
使うことができます。
120
OpenStack 運用ガイド
February 1, 2016
操作ベー
ス
特定の操作に対するアクセス基準を指定するポリシー。特定
の属性に対する詳細な制御も可能です。
リソース
ベース
リソースに対して設定されたパーミッションに基づいて、特
性のリソースに対するアクセスを許可するかを決定する (今
のところネットワークリソースでのみ利用可能)。OpenStack
により強制される実際の認可ポリシーは、導入の仕方により
異なります。
ポリシーエンジンは policy.json ファイルから項目を読み込みます。こ
のファイルの実際の位置はディストリビューションにより異なります。
一般的に Nova 用の設定ファイルは /etc/nova/policy.json にありま
す。システムの実行中に項目を更新でき、サービスを再起動する必要
がありません。今のところ、ポリシーファイルの編集がこのようなポリ
シーを更新する唯一の方法です。
OpenStack サービスのポリシーエンジンがポリシーと直接照合を行いま
す。ルールはそのようなポリシーの要素の評価を意味します。たとえ
ば、compute:create: [["rule:admin_or_owner"]] 文において、ポリ
シーは compute:create で、ルールは admin_or_owner です。
ポリシーのいずれかが OpenStack API 操作、もしくは指定された操作で
使用されている特定の属性に一致する場合、ポリシーが OpenStack ポリ
シーエンジンにより呼び出されます。たとえば、ユーザーが POST /v2/
{tenant_id}/servers リクエストを OpenStack Compute API サーバー
に送信したときに必ず、エンジンが create:compute ポリシーを評価し
ます。ポリシーは特定の API 拡張に関連づけることもできます。たとえ
ば、ユーザーが compute_extension:rescue のような拡張に対して要求
を行った場合、プロバイダー拡張により定義された属性は、その操作に
対するルールテストを呼び出します。
認可ポリシーは、一つまたは複数のルールにより構成できます。複数の
ルールを指定すると、いずれかのルールが成功と評価されれば、評価エ
ンジンが成功になります。API 操作が複数のポリシーに一致すると、す
べてのポリシーが成功と評価される必要があります。認可ルールは再帰
的にもできます。あるルールにマッチした場合、これ以上展開できない
ルールに達するまで、そのルールは別のルールに展開されます。以下の
ルールが定義できます。
ロールに基づ
いたルール
リクエストを出したユーザーが指定された役割を持って
いれば、成功と評価されます。たとえば、リクエストを
出しているユーザーが管理者ならば、"role:admin" が
成功します。
項目に基づい
たルール
現在のリクエストに指定されたリソースの項目が指定さ
れた値と一致すれば、成功と評価されます。たとえば、
121
OpenStack 運用ガイド
February 1, 2016
ネットワークリソースの shared 属性が true に設定さ
れている場合、"field:networks:shared=True" が成功
します。
一般的なルー
ル
リソースの属性をユーザーのセキュリティクレデンシャ
ルから抽出した属性と比較し、一致した場合に成功と評
価されます。たとえば、リソースのテナント識別子がリ
クエストを出したユーザーのテナント識別子と一致すれ
ば、"tenant_id:%(tenant_id)s" が成功します。
これは標準の nova policy.json ファイルの抜粋です。
{
"context_is_admin": [["role:admin"]],
"admin_or_owner": [["is_admin:True"], \
["project_id:%(project_id)s"]],
"default": [["rule:admin_or_owner"]],
"compute:create": [ ],
"compute:create:attach_network": [ ],
"compute:create:attach_volume": [ ],
"compute:get_all": [ ],
"admin_api": [["is_admin:True"]],
"compute_extension:accounts": [["rule:admin_api"]],
"compute_extension:admin_actions": [["rule:admin_api"]],
"compute_extension:admin_actions:pause": [["rule:admin_or_owner"]],
"compute_extension:admin_actions:unpause": [["rule:admin_or_owner"]],
...
"compute_extension:admin_actions:migrate": [["rule:admin_api"]],
"compute_extension:aggregates": [["rule:admin_api"]],
"compute_extension:certificates": [ ],
...
"compute_extension:flavorextraspecs": [ ],
"compute_extension:flavormanage": [["rule:admin_api"]],
}
現在のユーザーが、管理者、またはリクエストで指定されたリソー
スの所有者 (テナント識別子が同じ) であれば、成功であると評価
されるルールを表します。
API 操作が policy.json のどのポリシーとも一致しなかった場合
に、必ず評価される規定のポリシーを表します。
インスタンスタイプを操作する権限を、管理 API を使用する管理者
だけに限定するポリシーを表します。
いくつかの場合では、いくつかの操作を管理者のみに制限すべきです。
そこで、次の例では、ユーザーが自分のフレーバーを作成できるように
するシナリオの場合に、このサンプルのポリシーファイルをどのように
変更すればよいかを示します。
"compute_extension:flavormanage": [ ],
122
OpenStack 運用ガイド
February 1, 2016
他のユーザーに悪影響を与えるユーザー
クラウドのユーザーは他のユーザーに悪影響を与える場合があります。
意図的に悪意を持って行わる場合もあれば、偶然起こる場合もありま
す。状況を理解することにより、このような混乱に対処する方法につい
て、よりよい判断をできるようになります。
例えば、あるユーザーのグループが、非常に計算負荷の高い作業用に大
量のコンピュートリソースを使うインスタンスを持っているとします。
これにより、Compute ノードの負荷が高くなり、他のユーザーに影響を
与えます。この状況では、ユーザーのユースケースを精査する必要があ
ります。計算負荷が高いシナリオがよくあるケースだと判明し、ホスト
集約やリージョンなど、クラウドを適切に分割することを計画すべき場
合もあるでしょう。
別の例は、あるユーザーが非常に多くの帯域を消費することです。繰り
返しですが、ユーザーが実行していることを理解することが重要です。
必ず多くの帯域を使用する必要があれば、他のユーザーに影響を与えな
いように通信帯域を制限する、または、より多くの帯域を利用可能な別
の場所に移動させる必要があるかもしれません。一方、ユーザーのイン
スタンスが侵入され、DDOS 攻撃を行っているボットネットの一部になっ
ているかもしれません。この問題の解決法は、ネットワークにある他の
サーバーが侵入された場合と同じです。ユーザーに連絡し、対応する時
間を与えます。もし対応しなければ、そのインスタンスを停止します。
最後の例は、ユーザーがクラウドのリソースに繰り返し悪影響を与える
場合です。ユーザーと連絡をとり、何をしようとしているのか理解しま
す。ユーザー自身が実行しようとしていることを正しく理解していない
可能性があります。または、アクセスしようとしているリソースに問題
があり、リクエストがキューに入ったり遅れが発生している場合もあり
ます。
概要
システム管理の見過ごされがちな大事な要素の一つに、エンドユーザの
ためにシステム管理者が存在するという点があります。BOFH (Bastard
Operator From Hell; 「地獄から来た最悪の管理者」) の道に入って、
問題の原因となっているユーザーを全員停止させるようなことはしない
でください。ユーザーがやりたいことを一緒になって理解し、どうする
とあなたの環境がユーザーが目的を達成するのにもっと支援できるかを
見つけてください。ユーザーをプロジェクトの中に組織して、ポリシー
を適用して、クォータを管理して、彼らと一緒に作業することにより、
ユーザーのニーズを満たしてください。
123
OpenStack 運用ガイド
February 1, 2016
第10章 ユーザーによる運用
イメージ ...................................................
フレーバー .................................................
セキュリティグループ .......................................
ブロックストレージ .........................................
Shared File Systems サービス ...............................
インスタンス ...............................................
セキュリティグループの割り当て .............................
Floating IP ................................................
ブロックストレージの接続 ...................................
スナップショットの取得 .....................................
データベースにあるインスタンス .............................
グッドラック！ .............................................
125
128
130
140
142
157
162
162
163
164
169
170
このガイドは OpenStack の運用者向けです。ユーザー向けの膨大なリ
ファレンスを目指すものではありません。しかし運用者として、クラウ
ド設備を使用する方法について基本的な理解を持つべきです。本章は、
基本的なユーザーの観点から OpenStack を見ていきます。ユーザーが必
要とすることを理解する手助けになります。また、トラブルのチケット
を受け取ったときに、ユーザーの問題またはサービスの問題のどちらか
を判断する手助けになります。取り扱っている主な概念はイメージ、フ
レーバー、セキュリティグループ、ブロックストレージ、共有ファイル
システムストレージおよびインスタンスです。
イメージ
OpenStack のイメージはしばしば「仮想マシンテンプレート」と考える
ことができます。イメージは ISO イメージのような標準的なインストー
ルメディアの場合もあります。基本的に、インスタンスを起動するため
に使用されるブート可能なファイルシステムを含みます。
イメージの追加
いくつかの構築済みイメージが存在します。簡単に Image service の中
にインポートできます。追加する一般的なイメージは、非常に小さく、
テスト目的に使用される CirrOS イメージです。このイメージを追加す
るには、単に次のようにします。
$ wget http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img
$ glance image-create --name='cirros image' --is-public=true \
--container-format=bare --disk-format=qcow2 < cirros-0.3.4-x86_64-disk.img
125
OpenStack 運用ガイド
February 1, 2016
glance image-create コマンドでは、イメージに指定できる多数のオプ
ションが用意されています。たとえば、min-disk オプションは、特定
の容量のルートディスクを必要とするイメージ (例: 大きな Windows イ
メージ) のために有用です。これらのオプションを表示するには、次の
ようにします:
$ glance help image-create
location オプションは注意する意味があります。Image service にイ
メージ全体のコピーを行わず、そのイメージがある元の位置への参照を
保持します。イメージのインスタンスを起動するとき、Image service
が指定された場所からイメージにアクセスします。
copy-from オプションは、指定された位置から /var/lib/glance/images
ディレクトリの中にコピーします。例に示されたように STDIN リダイレ
クションを使用するときに、同じことが実行されます。
既存のイメージのプロパティを表示するために、以下のコマンドを実行
します。
$ glance image-show <image-uuid>
プロジェクト間のイメージの共有
マルチテナントクラウド環境において、ユーザーはときどき、自分のイ
メージやスナップショットを他のプロジェクトと共有したいことがあり
ます。 これは、イメージの所有者がコマンドラインから glance ツール
を使用することによりできます。
以下のように、イメージやスナップショットを他のプロジェクトと共有
します。
1.
イメージの UUID を取得します。
$ glance image-list
2.
イメージを共有したいプロジェクトの UUID を取得します。残念な
がら、非管理者は、これを実行するために keystone コマンドを使
用できません。最も簡単な解決方法は、クラウドの管理者やそのプ
ロジェクトのユーザーから UUID を教えてもらうことです。
3.
情報がそろったら、glance コマンドを実行します。
$ glance member-create <image-uuid> <project-uuid>
例えば
$ glance member-create 733d1c44-a2ea-414b-aca7-69decf20d810 \
126
OpenStack 運用ガイド
February 1, 2016
771ed149ef7e4b2b88665cc1c98f77ca
これで、プロジェクト 771ed149ef7e4b2b88665cc1c98f77ca がイ
メージ 733d1c44-a2ea-414b-aca7-69decf20d810 にアクセスできま
す。
イメージの削除
イメージを削除する場合、 次のようにします。
$ glance image-delete <image uuid>
注記
イメージを削除しても、そのイメージがベースになっている
インスタンスやスナップショットには影響がありません。
他の CLI オプション
すべてのオプションは、次のように確認できます。
$ glance help
or the Command-Line Interface Reference .
Image service とデータベース
Image service がデータベースに保存しない唯一のものは、イメージ自
体です。Image service のデータベースは、主要なテーブルが 2 つあり
ます。
• images
• image_properties
データベースと SQL クエリーを直接使うことで、イメージの独自のリス
トやレポートを得ることができます。一般には、推奨されませんが、技
術的にはデータベース経由でイメージのプロパティを更新できます。
Image service のデータベースクエリーの例
興味深い例の一つは、イメージとそのイメージの所有者の表の表示内容
を変更することです。これは、所有者のユニーク ID を表示するように
するだけで実現できます。この例はさらに一歩進め、所有者の読みやす
い形式の名前を表示します:
127
OpenStack 運用ガイド
February 1, 2016
mysql> select glance.images.id,
glance.images.name, keystone.tenant.name, is_public from
glance.images inner join keystone.tenant on
glance.images.owner=keystone.tenant.id;
もう一つの例は、特定のイメージに関するすべてのプロパティを表示す
ることです。
mysql> select name, value from
image_properties where id = <image_id>
フレーバー
仮想ハードウェアのテンプレートは、OpenStack において「フレー
バー」と呼ばれます。メモリー、ディスク、CPU コア数などを定義しま
す。デフォルトインストールでは、5 つのフレーバーが存在します。
これらは管理ユーザーにより設定できます。nova-api サーバーにおいて
/etc/nova/policy.json の compute_extension:flavormanage にあるア
クセス制限を再定義することにより、この権限を他のユーザーに委譲す
ることもできます。次のように、お使いのシステムで利用可能なフレー
バーの一覧を取得できます。
$ nova flavor-list
+-----+-----------+-----------+------+-----------+------+------+-------------+-----------+
| ID | Name
| Memory_MB | Disk | Ephemeral | Swap | VCPUs |
| Is_Public |
+-----+-----------+-----------+------+-----------+------+------+-------------+-----------+
| 1
| m1.tiny
| 512
| 1
| 0
|
| 1
|
| True
|
| 2
| m1.small | 2048
| 20
| 0
|
| 1
|
| True
|
| 3
| m1.medium | 4096
| 40
| 0
|
| 2
|
| True
|
| 4
| m1.large | 8192
| 80
| 0
|
| 4
|
| True
|
| 5
| m1.xlarge | 16384
| 160 | 0
|
| 8
|
| True
|
+-----+-----------+-----------+------+-----------+------+------+-------------+-----------+
RXTX_Factor
1.0
1.0
1.0
1.0
1.0
nova flavor-create コマンドにより、権限のあるユーザーが新しいフ
レーバーを作成できます。さらなるフレーバーの操作コマンドは次のコ
マンドを用いて表示できます:
$ nova help | grep flavor
128
OpenStack 運用ガイド
February 1, 2016
フレーバーは、数多くのパラメーターを定義します。これにより、ユー
ザーが実行する仮想マシンの種類を選択できるようになります。ちょ
うど、物理サーバーを購入する場合と同じようなことです。表10.1「フ
レーバーのパラメーター」 [129] は、設定できる要素の一覧です。とく
に extra_specs, に注意してください。これは、メモリー、CPU、ディス
クの容量以外にもかなり柔軟に、自由形式で特徴を定義するために使用
できます。
表10.1 フレーバーのパラメーター
項目
説明
ID
フレーバー向けの一意な ID (整数や UUID)。
名前
慣習として xx.size_name などの内容を表す名前を使用しますが、必
須ではありません。いくつかのサードパーティツールはその名称に依
存しているかもしれません。
Memory_MB
メガバイト単位の仮想マシンメモリー。
ディスク
ギガバイト単位の仮想ルートディスク容量。これはベースイメージが
コピーされる一時ディスクです。永続的なボリュームからブートする
とき、これは使用されません。「0」という容量は特別な値で、一時
ルートボリュームの容量としてベースイメージのネイティブ容量をそ
のまま使用することを意味します。
エフェメラル
二次的な一時データディスクの容量を指定します。これは空の、
フォーマットされていないディスクです。インスタンスの生存期間だ
け存在します。
スワップ
インスタンスに割り当てられるスワップ空間。これはオプションで
す。
仮想 CPU
インスタンスに存在する仮想 CPU 数。
RXTX_Factor
作成したサーバーが接続されたネットワークにおける定義と異なる帯
域制限を持てるようにするプロパティ。これはオプションです。この
要素はネットワークの rxtx_base プロパティの倍数です。既定の値は
1.0 です (つまり、接続されたネットワークと同じです)。
Is_Public
フレーバーがすべてのユーザーに利用可能であるか、プライベートで
あるかを示す論理値。プライベートなフレーバーは、現在のテナント
をそれらに割り当てません。デフォルトは True です。
extra_specs
フレーバーを実行できるコンピュートノードに関する追加の制限。こ
れはオプションです。これは、コンピュートノードにおいて対応する
キーバリューペアとして実装され、コンピュートノードでの対応する
キーバリューペアと一致するものでなければいけません。(GPU ハー
ドウェアを持つコンピュートノードのみにおいて実行するフレーバー
のように) 特別なリソースのようなものを実装するために使用できま
す。
プライベートフレーバー
ユーザーが、取り組んでいるプロジェクト向けに独自にチューニングし
た、カスタムフレーバーを必要とするかもしれません。例えば、ユー
ザーが 128 GB メモリーを必要とするかもしれません。前に記載した
129
OpenStack 運用ガイド
February 1, 2016
とおり、新しいフレーバーを作成する場合、ユーザーがカスタムフレー
バーにアクセスできるでしょう。しかし、クラウドにある他のすべての
クラウドもアクセスできます。ときどき、この共有は好ましくありませ
ん。この場合、すべてのユーザーが 128 GB メモリーのフレーバーにア
クセスでき、クラウドのリソースが非常に高速に容量不足になる可能性
があります。これを防ぐために、nova コマンドを使用して、カスタムフ
レーバーへのアクセスを制限できます。
$ nova flavor-access-add <flavor-id> <project-id>
以下のように、フレーバーのアクセスリストを表示します。
$ nova flavor-access-list <flavor-id>
ベストプラクティス
フレーバーへのアクセスが制限されると、明示的にアクセス
を許可されたプロジェクト以外は、フレーバーを参照できな
くなります。これには admin プロジェクトも含まれます。元
のプロジェクトに加えて、きちんと admin プロジェクトを追
加してください。
カスタムフレーバーとプライベートフレーバーに特別な数値
範囲を割り当てることも有用です。UNIX 系システムでは、シ
ステムアカウント以外は通常 500 から始まります。同様の方
法をカスタムフレーバーにも使用できます。これは、フレー
バーがカスタムフレーバー、プライベートフレーバー、パブ
リックフレーバーであるかをクラウド全体で簡単に識別する
役に立ちます。
どのように既存のフレーバーを変更しますか?
OpenStack dashboard は、既存のフレーバーを削除し、同じ名前の新し
いものを作成することにより、フレーバーを変更する機能を模倣してい
ます。
セキュリティグループ
OpenStack の新しいユーザーがよく経験する問題が、インスタンスを
起動するときに適切なセキュリティグループを設定できず、その結果、
ネットワーク経由でインスタンスにアクセスできないというものです。
セキュリティグループは、インスタンスのネットワークに適用され
る、IP フィルタールールの組です。それらはプロジェクト固有です。
プロジェクトメンバーがそれらのグループの標準ルールを編集でき、新
130
OpenStack 運用ガイド
February 1, 2016
しいルールを追加できます。すべてのプロジェクトが "default" セキュ
リティグループを持ちます。他のセキュリティグループが定義されてい
ないインスタンスには "default" セキュリティグループが適用されま
す。"default" セキュリティグループは、ルールを変更しない限り、す
べての受信トラフィックを拒否します。
一般的なセキュリティグループの設定
nova.conf のオプション allow_same_net_traffic (標準で true) は、
同じネットワークを共有するホストにルールを適用するかを制御しま
す。このオプションはシステム全体に影響するグローバルオプション
です。true に設定したとき、同じサブネットにあるホストはフィル
ターされず、それらの間ですべての種類の通信が通過できるようにな
ります。フラットなネットワークでは、これにより、全プロジェクト
の全インスタンスが通信をフィルターされなくなります。VLAN ネット
ワークでは、これにより、同じプロジェクト内のインスタンス間でア
クセスが許可されます。allow_same_net_traffic が false に設定さ
れていると、セキュリティグループがすべての通信に対して強制されま
す。この場合、既定のセキュリティグループをそれらのサブネットから
のすべての通信を許可するよう設定することにより、プロジェクトが
allow_same_net_traffic をシミュレートできます。
ヒント
前の章で述べたとおり、セキュリティグループごとのルール
数は quota_security_group_rules により制御されます。ま
た、プロジェクトごとに許可されるセキュリティグループ数
は quota_security_groups クォータにより制御されます。
セキュリティグループのエンドユーザー設定
現在のプロジェクトのセキュリティグループが、OpenStack dashboard
の アクセスとセキュリティ にあります。既存のグループの詳細を表示
するには、セキュリティグループの 編集 を選択します。自明ですが、
この 編集 インターフェースから既存のグループを変更できます。新し
いグループを作成するための セキュリティグループの作成 ボタンが、
メインの アクセスとセキュリティ ページにあります。同等のコマンド
ラインを説明するとき、これらの項目において使用される用語について
説明します。
nova コマンドを用いたセットアップ方法
コマンドラインからは、以下の nova コマンドを使って、現在のプロ
ジェクトのセキュリティグループのリストを取得できます:
131
OpenStack 運用ガイド
February 1, 2016
$ nova secgroup-list
+---------+-------------+
| Name
| Description |
+---------+-------------+
| default | default
|
| open
| all ports
|
+---------+-------------+
「open」セキュリティグループの詳細を表示する方法:
$ nova secgroup-list-rules open
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range | Source Group |
+-------------+-----------+---------+-----------+--------------+
| icmp
| -1
| 255
| 0.0.0.0/0 |
|
| tcp
| 1
| 65535
| 0.0.0.0/0 |
|
| udp
| 1
| 65535
| 0.0.0.0/0 |
|
+-------------+-----------+---------+-----------+--------------+
標準で拒否されるので、これらのルールはすべて「許可」形式のルール
です。1 番目の項目は IP プロトコル (icmp, tcp, udp のどれか) で
す。2 番目と 3 番目の項目は対象となるポート番号の範囲を指定しま
す。4 番目の項目は CIDR 形式の IP アドレスの範囲を指定します。こ
の例では、すべてのプロトコルの全ポート番号について、すべての IP
からのトラフィックを許可しています。
新しいセキュリティグループを追加するとき、内容を表す簡潔な名前を
つけるべきです。この名前はインスタンスの簡単な説明など、より長い
説明フィールドが使用されないところで使用されます。インスタンスが
セキュリティグループ http を使っているのを見れば、bobs_group や
secgrp1 よりはずっと理解しやすいことでしょう。
例のとおり、インターネットのどこからでも Web 通信を許可するセキュ
リティグループを作成しましょう。このグループを global_http と呼ぶ
ことにします。許可されるものと許可されるところを要約した、明白で
簡潔な名前になっています。コマンドラインから以下のようにします。
$ nova secgroup-create \
global_http "allow web traffic from the Internet"
+-------------+-------------------------------------+
| Name
| Description
|
+-------------+-------------------------------------+
| global_http | allow web traffic from the Internet |
+-------------+-------------------------------------+
これにより、空のセキュリティグループが作成されます。やりたいこと
を行うために、いくつかのルールを追加する必要があります。
$ nova secgroup-add-rule <secgroup> <ip-proto> <from-port> <to-port> <cidr>
$ nova secgroup-add-rule global_http tcp 80 80 0.0.0.0/0
132
OpenStack 運用ガイド
February 1, 2016
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range | Source Group |
+-------------+-----------+---------+-----------+--------------+
| tcp
| 80
| 80
| 0.0.0.0/0 |
|
+-------------+-----------+---------+-----------+--------------+
引数の順番が決まっていることに注意してください。そして、from-port
と to-port の引数は許可されるローカルのポート範囲を指定し、接続
の送信元ポートと宛先ポートではないことに注意してください。nova
secgroup-add-rule を複数回呼び出すことで、より複雑なルールセット
を構成できます。たとえば、http と https の通信を通過させたい場合:
$ nova secgroup-add-rule global_http tcp 443 443 0.0.0.0/0
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range | Source Group |
+-------------+-----------+---------+-----------+--------------+
| tcp
| 443
| 443
| 0.0.0.0/0 |
|
+-------------+-----------+---------+-----------+--------------+
新しく追加されたルールのみが出力されますが、この操作は追加操作で
す:
$ nova secgroup-list-rules global_http
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range | Source Group |
+-------------+-----------+---------+-----------+--------------+
| tcp
| 80
| 80
| 0.0.0.0/0 |
|
| tcp
| 443
| 443
| 0.0.0.0/0 |
|
+-------------+-----------+---------+-----------+--------------+
逆の操作が secgroup-delete-rule です。secgroup-delete-rule のコ
マンドラインは同じ形式です。セキュリティグループ全体を secgroupdelete を用いて削除できます。
インスタンスのクラスター向けにセキュリティグループのルールを作成
するために、SourceGroups を使用したいかもしれません。
ソースグループは許可されたソースの CIDR を動的に定義する特別な方
法です。ユーザーがソースグループ (セキュリティグループ名) を指定
します。これにより、指定されたソースグループを使用する、ユーザー
の他のインスタンスが動的にすべて選択されます。この動的な選択によ
り、クラスターのそれぞれの新しいメンバーを許可する、個別のルール
の必要性を軽減できます。
コードはこのような形になります。nova secgroup-add-group-rule
<secgroup> <source-group> <ip-proto> <from-port> <to-port>。使用
例は次のとおりです。
$ nova secgroup-add-group-rule cluster global-http tcp 22 22
133
OpenStack 運用ガイド
February 1, 2016
"cluster" ルールにより、global-http グループを使用する他のすべて
のインスタンスから SSH アクセスが許可されます。
neutron コマンドを用いたセットアップ方法
お使いの環境で Neutron を使用している場合、neutron コマンドを使用
して、セキュリティグループを設定できます。以下のコマンドを使用し
て、作業しているプロジェクトのセキュリティグループの一覧を取得し
ます。
$ neutron security-group-list
+--------------------------------------+---------+-------------+
| id
| name
| description |
+--------------------------------------+---------+-------------+
| 6777138a-deb7-4f10-8236-6400e7aff5b0 | default | default
|
| 750acb39-d69b-4ea0-a62d-b56101166b01 | open
| all ports |
+--------------------------------------+---------+-------------+
「open」セキュリティグループの詳細を表示する方法:
$ neutron security-group-show open
+---------------------+------------------------------------------------------------------------------------------------+
| Field
| Value
|
+---------------------+------------------------------------------------------------------------------------------------+
| description
| all ports
| id
|
| 750acb39-d69b-4ea0-a62d-b56101166b01
| name
| open
|
|
| security_group_rules | {"remote_group_id": null, "direction":
"egress", "remote_ip_prefix": null, "protocol": null, "tenant_id":
"607ec981611a4839b7b06f6dfa81317d", "port_range_max": null,
"security_group_id": "750acb39-d69b-4e0-a62d-b56101166b01",
134
OpenStack 運用ガイド
February 1, 2016
"port_range_min": null, "ethertype": "IPv4", "id": "361a1b62-95dd-46e1-8639c3b2000aab60"}
|
|
| {"remote_group_id": null, "direction":
"ingress", "remote_ip_prefix": "0.0.0.0/0", "protocol": "udp",
"tenant_id": "341f49145ec7445192dc3c2abc33500d", "port_range_max":
65535, "security_group_id": "750acb9-d69b-4ea0-a62d-b56101166b01",
"port_range_min": 1, "ethertype": "IPv4", "id": "496ba8b7d96e-4655-920f-068a3d4ddc36"}
|
|
| {"remote_group_id": null, "direction":
"ingress", "remote_ip_prefix": "0.0.0.0/0", "protocol":
"icmp", "tenant_id": "341f49145ec7445192dc3c2abc33500d",
"port_range_max": null, "security_group_id": "750acb9-d69b-4ea0-a62db56101166b01", "port_range_min": null, "ethertype": "IPv4", "id":
"50642a56-3c4e-4b31-9293-0a636759a156"} |
|
| {"remote_group_id": null, "direction":
"egress", "remote_ip_prefix": null, "protocol": null, "tenant_id":
"607ec981611a4839b7b06f6dfa81317d", "port_range_max": null,
"security_group_id": "750acb39-d69b-4e0-a62d-b56101166b01",
"port_range_min": null, "ethertype": "IPv6", "id": "f46f35eb-8581-4ca1-bbc9cf8d0614d067"}
|
|
| {"remote_group_id": null, "direction":
"ingress", "remote_ip_prefix": "0.0.0.0/0", "protocol": "tcp",
"tenant_id": "341f49145ec7445192dc3c2abc33500d", "port_range_max":
65535, "security_group_id": "750acb9-d69b-4ea0-a62d-b56101166b01",
"port_range_min": 1, "ethertype": "IPv4", "id": "fb6f2d5e-8290-4ed8-a23bc6870813c921"}
|
| tenant_id
| 607ec981611a4839b7b06f6dfa81317d
|
+---------------------+----------------------------------------------------------------------------------------+
デフォルトは拒否なので、これらのルールはすべて「許可」形式のルー
ルです。この例は、すべての IP から、すべてのプロトコルの範囲全体
が許可されることを示しています。このセクションは、最も一般的な
security-group-rule のパラメーターを説明します。
方向
セキュリティグループルールが適用される通信方
向。有効な値は ingress と egress です。
remote_ip_prefix
この属性値は、IP パケットの送信元 IP アドレ
スとして、指定された IP プレフィックスと一致
します。
プロトコル
The protocol that is matched by the security
group rule. Valid values are null, tcp, udp,
icmp, and icmpv6.
135
OpenStack 運用ガイド
February 1, 2016
port_range_min
The minimum port number in the range that
is matched by the security group rule. If
the protocol is TCP or UDP, this value must
be less than or equal to the port_range_max
attribute value. If the protocol is ICMP or
ICMPv6, this value must be an ICMP or ICMPv6
type, respectively.
port_range_max
The maximum port number in the range that
is matched by the security group rule. The
port_range_min attribute constrains the
port_range_max attribute. If the protocol is
ICMP or ICMPv6, this value must be an ICMP
or ICMPv6 type, respectively.
ethertype
IPv4 または IPv6 である必要があります。CIDR
形式のアドレスが受信ルールまたは送信ルールに
一致する必要があります。
新しいセキュリティグループを追加するとき、内容を表す簡潔な名前を
つけるべきです。この名前はインスタンスの簡単な説明など、より長い
説明フィールドが使用されないところで使用されます。インスタンスが
セキュリティグループ http を使っているのを見れば、bobs_group や
secgrp1 よりはずっと理解しやすいことでしょう。
この例は、インターネットのどこからでも Web 通信を許可するセキュリ
ティグループを作成します。このグループを global_http と呼ぶことに
します。許可されるものと許可されるところを要約した、明白で簡潔な
名前になっています。コマンドラインから以下のようにします。
$ neutron security-group-create \
global_http --description "allow web traffic from the Internet"
Created a new security_group:
+---------------------+------------------------------------------------------------------------------------------------+
| Field
| Value
|
+---------------------+------------------------------------------------------------------------------------------------+
| description
| allow web traffic from the Internet
136
OpenStack 運用ガイド
February 1, 2016
| id
|
| c6d78d56-7c56-4c82-abcb-05aa9839d1e7
| name
|
| global_http
|
| security_group_rules | {"remote_group_id": null, "direction":
"egress", "remote_ip_prefix": null, "protocol": null, "tenant_id":
"341f49145ec7445192dc3c2abc33500d", "port_range_max": null,
"security_group_id": "c6d78d56-7c56-4c82-abcb-05aa9839d1e7",
"port_range_min": null, "ethertype": "IPv4", "id":
"b2e56b3a-890b-48d3-9380-8a9f6f8b1b36"} |
|
| {"remote_group_id": null, "direction":
"egress", "remote_ip_prefix": null, "protocol": null, "tenant_id":
"341f49145ec7445192dc3c2abc33500d", "port_range_max": null,
"security_group_id": "c6d78d56-7c56-4c82-abcb-05aa9839d1e7",
"port_range_min": null, "ethertype": "IPv6", "id":
"153d84ba-651d-45fd-9015-58807749efc5"} |
| tenant_id
| 341f49145ec7445192dc3c2abc33500d
|
+---------------------+----------------------------------------------------------------------------------------+
作成後すぐでは、セキュリティグループは送信ルールのみを許可しま
す。やりたいことを行うために、いくつかのルールを追加する必要があ
ります。
$ neutron security-group-rule-create [-h]
[-f {html,json,json,shell,table,value,
yaml,yaml}]
[-c COLUMN] [--max-width <integer>]
[--noindent] [--prefix PREFIX]
[--request-format {json,xml}]
[--tenant-id TENANT_ID]
[--direction {ingress,egress}]
[--ethertype ETHERTYPE]
[--protocol PROTOCOL]
[--port-range-min PORT_RANGE_MIN]
[--port-range-max PORT_RANGE_MAX]
[--remote-ip-prefix REMOTE_IP_PREFIX]
[--remote-group-id REMOTE_GROUP]
137
OpenStack 運用ガイド
February 1, 2016
SECURITY_GROUP
$ neutron security-group-rule-create --direction ingress --ethertype IPv4 -protocol tcp --port-range-min 80 --port-range-max 80 --remote-ip-prefix 0.0.
0.0/0 global_http
Created a new security_group_rule:
+-------------------+--------------------------------------+
| Field
| Value
|
+-------------------+--------------------------------------+
| direction
| ingress
|
| ethertype
| IPv4
|
| id
| 88ec4762-239e-492b-8583-e480e9734622 |
| port_range_max
| 80
|
| port_range_min
| 80
|
| protocol
| tcp
|
| remote_group_id
|
|
| remote_ip_prefix | 0.0.0.0/0
|
| security_group_id | c6d78d56-7c56-4c82-abcb-05aa9839d1e7 |
| tenant_id
| 341f49145ec7445192dc3c2abc33500d
|
+-------------------+--------------------------------------+
より複雑なルールセットは、neutron security-group-rule-create の複
数呼び出しにより構築できます。例えば、HTTP 通信と HTTPS 通信を通
過させたい場合、このようにします。
$ neutron security-group-rule-create --direction ingress --ethertype ipv4 -protocol tcp --port-range-min 443 --port-range-max 443 --remote-ip-prefix 0.
0.0.0/0 global_http
Created a new security_group_rule:
+-------------------+--------------------------------------+
| Field
| Value
|
+-------------------+--------------------------------------+
| direction
| ingress
|
| ethertype
| IPv4
|
| id
| c50315e5-29f3-408e-ae15-50fdc03fb9af |
| port_range_max
| 443
|
| port_range_min
| 443
|
| protocol
| tcp
|
| remote_group_id
|
|
| remote_ip_prefix | 0.0.0.0/0
|
| security_group_id | c6d78d56-7c56-4c82-abcb-05aa9839d1e7 |
| tenant_id
| 341f49145ec7445192dc3c2abc33500d
|
+-------------------+--------------------------------------+
新しく追加されたルールのみが出力されますが、この操作は追加操作で
す:
$ neutron security-group-show global_http
+---------------------+------------------------------------------------------------------------------------------------+
138
OpenStack 運用ガイド
| Field
February 1, 2016
| Value
|
+---------------------+----------------------------------------------------------------------------------------+
| description
| allow web traffic from the Internet
| id
|
| c6d78d56-7c56-4c82-abcb-05aa9839d1e7
| name
| global_http
|
|
| security_group_rules | {"remote_group_id": null, "direction":
"egress", "remote_ip_prefix": null, "protocol": null, "tenant_id":
"341f49145ec7445192dc3c2abc33500d", "port_range_max": null,
"security_group_id": "c6d78d56-7c56-4c82-abcb-05aa9839d1e7",
"port_range_min": null, "ethertype": "IPv6", "id":
"153d84ba-651d-45fd-9015-58807749efc5"}
|
|
| {"remote_group_id": null, "direction":
"ingress", "remote_ip_prefix": "0.0.0.0/0", "protocol": "tcp",
"tenant_id": "341f49145ec7445192dc3c2abc33500d", "port_range_max":
80, "security_group_id": "c6d78d56-7c56-4c82-abcb-05aa9839d1e7",
"port_range_min": 80, "ethertype": "IPv4", "id": "88ec4762-239e-492b-8583e480e9734622"}
|
|
| {"remote_group_id": null, "direction":
"egress", "remote_ip_prefix": null, "protocol": null, "tenant_id":
"341f49145ec7445192dc3c2abc33500d", "port_range_max": null,
"security_group_id": "c6d78d56-7c56-4c82-abcb-05aa9839d1e7",
"port_range_min": null, "ethertype": "IPv4", "id":
"b2e56b3a-890b-48d3-9380-8a9f6f8b1b36"}
|
|
| {"remote_group_id": null, "direction":
"ingress", "remote_ip_prefix": "0.0.0.0/0", "protocol": "tcp",
"tenant_id": "341f49145ec7445192dc3c2abc33500d", "port_range_max":
443, "security_group_id": "c6d78d56-7c56-4c82-abcb-05aa9839d1e7",
"port_range_min": 443, "ethertype": "IPv4", "id": "c50315e5-29f3-408eae15-50fdc03fb9af"} |
| tenant_id
| 341f49145ec7445192dc3c2abc33500d
139
OpenStack 運用ガイド
February 1, 2016
|
+---------------------+------------------------------------------------------------------------------------------------+
逆の操作が security-group-rule-delete です。security-group-rule
ID を指定します。セキュリティグループ全体を security-group-delete
を使用して削除できます。
インスタンスのクラスター向けにセキュリティグループのルールを作成
するために、リモートグループ を使用します。
リモートグループは許可されたソースの CIDR を動的に定義する方法で
す。ユーザーがリモートグループ (セキュリティグループ名) を指定し
ます。これにより、指定されたリモートグループを使用する、ユーザー
の他のインスタンスが動的にすべて選択されます。この動的な選択によ
り、クラスターのそれぞれの新しいメンバーを許可する、個別のルール
の必要性を軽減できます。
コードは、上の security-group-rule-create の例と似ていま
す。RemoteGroup を使用するために、--remote-ip-prefix の代わりに
--remote-group-id を指定します。例:
$ neutron security-group-rule-create --direction ingress \
--ethertype IPv4 --protocol tcp --port-range-min 22 --port-range-max
22 --remote-group-id global_http cluster
"cluster" ルールにより、global-http グループを使用する他のすべて
のインスタンスから SSH アクセスが許可されます。
ブロックストレージ
OpenStack のボリュームは、インスタンスから接続および切断できる、
永続的なブロックストレージデバイスです。ただし、一度に接続できる
のは 1 インスタンスだけです。外部ハードディスクと似ています。ネッ
トワークファイルシステムやオブジェクトストアがしているような共有
ストレージは提供されません。ブロックデバイス上にファイルシステム
を構築し、それをマウントするかどうかは、インスタンス内のオペレー
ティングシステムに任されます。
他のリムーバブルディスク技術と同じように、ディスクを取り外す前
に、オペレーティングシステムがそのディスクを使用しないようにする
ことが重要です。Linux インスタンスにおいて、一般的にボリュームか
らマウントされているすべてのファイルシステムをアンマウントする必
要があります。OpenStack Volume Service は、インスタンスから安全
140
OpenStack 運用ガイド
February 1, 2016
にボリュームを取り外すことができるかはわかりません。そのため、指
示されたことを実行します。ボリュームに書き込み中にインスタンスか
らボリュームの切断を、ユーザーが Volume Service に指示すると、何
らかのレベルのファイルシステム破損が起きる可能性があります。それ
だけでなく、デバイスを使用していたインスタンスの中のプロセスがエ
ラーを起こす可能性もあります。
ブロックデバイスにアクセスするために、インスタンスのオペレーティ
ングシステムにおいて必要となる手順に、OpenStack 固有の事項はあり
ません。初めて使用するときにフォーマットが必要になる、デバイスを
取り外すときに注意する、などが考えられます。固有の事項は、新しい
ボリュームを作成し、それらをインスタンスに接続および切断する方法
です。これらの操作は、ダッシュボードの ボリューム ページからすべ
て実行できます。または、cinder コマンドラインクライアントを使用し
ます。
新しいボリュームを追加する際に必要なのは、名前とギガバイト単位の
ボリューム容量だけです。これらを ボリュームの作成 Web フォームに
記入します。または、コマンドラインを使用します:
$ cinder create --display-name test-volume 10
これは test-volume という名前の 10GB のボリュームを作成します。既
存のボリュームの一覧を表示するには以下のようにします。それらが接
続されているインスタンスがあれば、インスタンス情報も表示されます:
$ cinder list
+------------+---------+--------------------+------+------------+-------------+
|
ID
| Status |
Display Name
| Size | Volume Type | Attached
to |
+------------+---------+--------------------+------+------------+-------------+
| 0821...19f | active |
test-volume
| 10 |
None
|
|
+------------+---------+--------------------+------+------------+-------------+
OpenStack Block Storage では、ボリュームのスナップショットを作成
することもできます。これはブロックレベルのスナップショットであ
ることを覚えておいてください。これはクラッシュに対する一貫性が
あります。そのため、スナップショットが取得されるとき、ボリュー
ムがインスタンスに接続されていないことが最良です。ボリュームが
接続されたインスタンスにおいて使用されていなければ、次に良いで
す。ボリュームが高負荷にある場合、スナップショットによりファイ
ルシステムの不整合が起こる可能性があります。実際、デフォルト設定
では、Volume Service はイメージに接続されたボリュームのスナップ
141
OpenStack 運用ガイド
February 1, 2016
ショットを取得しません。ただし、強制的に実行することができます。
ボリュームのスナップショットを取得するには、ダッシュボードの "ボ
リューム” ページにおいて、ボリューム名の隣にあるアクション項目か
らスナップショットの作成を選択します。または、コマンドラインから
次のようにします:
usage: cinder snapshot-create [--force <True|False>]
[--display-name <display-name>]
[--display-description <display-description>]
<volume-id>
Add a new snapshot.
Positional arguments: <volume-id>
ID of the volume to snapshot
Optional arguments: --force <True|False> Optional flag to indicate whether
to
snapshot a volume even if its
attached to an instance.
(Default=False)
--display-name <display-name>
Optional snapshot name.
(Default=None)
--display-description <display-description>
Optional snapshot description. (Default=None)
注記
Block Storage ボリュームの更新に関する詳細は、OpenStack
エンドユーザーガイドを参照してください。
ブロックストレージの作成エラー
ユーザーがボリュームを作成しようとし、すぐにエラー状態になれば、
トラブル解決のために最適な方法は cinder ログファイルをボリューム
の UUID で grep することです。まずクラウドコントローラーにあるロ
グファイルを調べます。次に、ボリュームを作成しようとしたストレー
ジノードのログファイルを調べます:
# grep
903b85d0-bacc-4855-a261-10843fc2d65b /var/log/cinder/*.log
Shared File Systems サービス
Similar to Block Storage, the Shared File System is a persistent
storage, called share, that can be used in multi-tenant
environments. Users create and mount a share as a remote file
system on any machine that allows mounting shares, and has
network access to share exporter. This share can then be used for
storing, sharing, and exchanging files. The default configuration
of the Shared File Systems service depends on the back-end driver
142
OpenStack 運用ガイド
February 1, 2016
the admin chooses when starting the Shared File Systems service.
For more information about existing back-end drivers, see section
"Share Backends" of Shared File Systems service Developer Guide.
For example, in case of OpenStack Block Storage based back-end
is used, the Shared File Systems service cares about everything,
including VMs, networking, keypairs, and security groups.
Other configurations require more detailed knowledge of shares
functionality to set up and tune specific parameters and modes of
shares functioning.
Shares are a remote mountable file system, so users can mount
a share to multiple hosts, and have it accessed from multiple
hosts by multiple users at a time. With the Shared File Systems
service, you can perform a large number of operations with
shares:
• 共有の作成、更新、削除、強制削除
• 共有のアクセスルールの変更、共有状態のリセット
• 既存のユーザまたはテナントのクォータを表示します
• 共有ネットワークの作成
• 新しい共有種別の作成
• Perform operations with share snapshots: create, change name,
create a share from a snapshot, delete
• Operate with consistency groups
• セキュリティサービスを指定する。
For more information on share management see section “Share
management” of chapter “Shared File Systems” in OpenStack
Cloud Administrator Guide. As to Security services, you should
remember that different drivers support different authentication
methods, while generic driver does not support Security Services
at all (see section “Security services” of chapter “Shared
File Systems” in OpenStack Cloud Administrator Guide).
You can create a share in a network, list shares, and show
information for, update, and delete a specified share. You
can also create snapshots of shares (see section “Share
snapshots” of chapter “Shared File Systems” in OpenStack Cloud
Administrator Guide).
143
OpenStack 運用ガイド
February 1, 2016
There are default and specific share types that allow you to
filter or choose back-ends before you create a share. Functions
and behaviour of share type is similar to Block Storage volume
type (see section “Share types” of chapter “Shared File
Systems” in OpenStack Cloud Administrator Guide).
To help users keep and restore their data, Shared File Systems
service provides a mechanism to create and operate snapshots (see
section “Share snapshots” of chapter “Shared File Systems”
in OpenStack Cloud Administrator Guide).
A security service stores configuration information for clients
for authentication and authorization. Inside Manila a share
network can be associated with up to three security types (for
detailed information see section “Security services” of
chapter “Shared File Systems” in OpenStack Cloud Administrator
Guide):
• LDAP
• Kerberos
• Microsoft Active Directory
Shared File Systems service differs from the principles
implemented in Block Storage. Shared File Systems service can
work in two modes:
• Without interaction with share networks, in so called "no share
servers" mode.
• 共有ネットワークに接続する
Networking service is used by the Shared File Systems service to
directly operate with share servers. For switching interaction
with Networking service on, create a share specifying a share
network. To use "share servers" mode even being out of OpenStack,
a network plugin called StandaloneNetworkPlugin is used. In this
case, provide network information in the configuration: IP range,
network type, and segmentation ID. Also you can add security
services to a share network (see section “Networking” of
chapter “Shared File Systems” in OpenStack Cloud Administrator
Guide).
The main idea of consistency groups is to enable you to create
snapshots at the exact same point in time from multiple file
144
OpenStack 運用ガイド
February 1, 2016
system shares. Those snapshots can be then used for restoring
all shares that were associated with the consistency group
(see section “Consistency groups” of chapter “Shared File
Systems” in OpenStack Cloud Administrator Guide).
Shared File System storage allows administrators to set limits
and quotas for specific tenants and users. Limits are the
resource limitations that are allowed for each tenant or user.
Limits consist of:
• レートリミット
• 絶対制限
Rate limits control the frequency at which users can
issue specific API requests. Rate limits are configured by
administrators in a config file. Also, administrator can
specify quotas also known as max values of absolute limits per
tenant. Whereas users can see only the amount of their consumed
resources. Administrator can specify rate limits or quotas for
the following resources:
• Max amount of space awailable for all shares
共有の最大数
共有ネットワークの最大数
共有のスナップショットの最大数
すべてのスナップショットの合計数
Type and number of API calls that can be made in a specific
time interval
User can see his rate limits and absolute limits by running
commands manila rate-limits and manila absolute-limits
respectively. For more details on limits and quotas see
subsection "Quotas and limits" of "Share management" section of
OpenStack Cloud Administrator Guide document.
このセクションは、主要な Shared File Systems サービスの機能を説明
するために、いくつかの重要なユースケースを示します。
• 共有の作成
• 共有の運用
145
OpenStack 運用ガイド
February 1, 2016
• 共有へのアクセス権の管理
• スナップショットの作成
• 共有ネットワークの作成
• 共有ネットワークの管理
注記
Shared File Systems service cannot warn you beforehand
if it is safe to write a specific large amount of data
onto a certain share or to remove a consistency group
if it has a number of shares assigned to it. In such a
potentially erroneous situations, if a mistake happens,
you can expect some error message or even failing of
shares or consistency groups into an incorrect status.
You can also expect some level of system corruption
if a user tries to unmount an unmanaged share while a
process is using it for data transfer.
共有の作成
In this section, we examine the process of creating a simple
share. It consists of several steps:
• Check if there is an appropriate share type defined in the
Shared File Systems service
• If such a share type does not exist, an Admin should create it
using manila type-create command before other users are able to
use it
• Using a share network is optional. However if you need one,
check if there is an appropriate network defined in Shared File
Systems service by using manila share-network-list command. For
the information on creating a share network, see 「共有ネット
ワークの作成」 [154] below in this chapter.
• Create a public share using manila create
• Make sure that the share has been created successfully and is
ready to use (check the share status and see the share export
location)
146
OpenStack 運用ガイド
February 1, 2016
Below is the same whole procedure described step by step and in
more detail.
注記
Before you start, make sure that Shared File Systems
service is installed on your OpenStack cluster and is
ready to use.
By default, there are no share types defined in Shared File
Systems service, so you can check if a required one has been
already created:
$ manila type-list
+------+--------+-----------+-----------+---------------------------------+----------------------+
| ID
| Name
| Visibility| is_default| required_extra_specs
|
optional_extra_specs |
+------+--------+-----------+-----------+---------------------------------+----------------------+
| c0...| default| public
| YES
| driver_handles_share_servers:True|
snapshot_support:True|
+------+--------+-----------+-----------+---------------------------------+----------------------+
If the share types list is empty or does not contain a type you
need, create the required share type using this command:
$ manila type-create netapp1 False --is_public True
This command will create a public share with the following
parameters: name = netapp1, spec_driver_handles_share_servers =
False
You can now create a public share with my_share_net network,
default share type, NFS shared file systems protocol, and 1 GB
size:
$ manila create nfs 1 --name "Share1" --description "My first share" --sharetype default --share-network my_share_net --metadata aim=testing --public
+-----------------------------+--------------------------------------+
| Property
| Value
|
+-----------------------------+--------------------------------------+
| status
| None
|
| share_type_name
| default
|
| description
| My first share
|
| availability_zone
| None
|
| share_network_id
| None
|
| export_locations
| []
|
147
OpenStack 運用ガイド
February 1, 2016
| share_server_id
| None
|
| host
| None
|
| snapshot_id
| None
|
| is_public
| True
|
| task_state
| None
|
| snapshot_support
| True
|
| id
| aca648eb-8c03-4394-a5cc-755066b7eb66 |
| size
| 1
|
| name
| Share1
|
| share_type
| c0086582-30a6-4060-b096-a42ec9d66b86 |
| created_at
| 2015-09-24T12:19:06.925951
|
| export_location
| None
|
| share_proto
| NFS
|
| consistency_group_id
| None
|
| source_cgsnapshot_member_id | None
|
| project_id
| 20787a7ba11946adad976463b57d8a2f
|
| metadata
| {u'aim': u'testing'}
|
+-----------------------------+--------------------------------------+
To confirm that creation has been successful, see the share in
the share list:
$ manila list
+----+-------+-----+------------+-----------+------------------------------+----------------------+
| ID | Name | Size| Share Proto| Share Type| Export location
|
Host
|
+----+-------+-----+------------+-----------+------------------------------+----------------------+
| a..| Share1| 1
| NFS
| c0086... | 10.254.0.3:/shares/share-2d5..
| manila@generic1#GEN..|
+----+-------+-----+------------+-----------+------------------------------+----------------------+
Check the share status and see the share export location. After
creation, the share status should become available:
$ manila show Share1
+-----------------------------+-------------------------------------------+
| Property
| Value
|
+-----------------------------+-------------------------------------------+
| status
| available
|
| share_type_name
| default
|
| description
| My first share
|
| availability_zone
| nova
|
| share_network_id
| 5c3cbabb-f4da-465f-bc7f-fadbe047b85a
|
| export_locations
| 10.254.0.3:/shares/share-2d5e2c0a-1f84... |
| share_server_id
| 41b7829d-7f6b-4c96-aea5-d106c2959961
|
| host
| manila@generic1#GENERIC1
|
| snapshot_id
| None
|
| is_public
| True
|
148
OpenStack 運用ガイド
February 1, 2016
| task_state
| None
|
| snapshot_support
| True
|
| id
| aca648eb-8c03-4394-a5cc-755066b7eb66
|
| size
| 1
|
| name
| Share1
|
| share_type
| c0086582-30a6-4060-b096-a42ec9d66b86
|
| created_at
| 2015-09-24T12:19:06.000000
|
| share_proto
| NFS
|
| consistency_group_id
| None
|
| source_cgsnapshot_member_id | None
|
| project_id
| 20787a7ba11946adad976463b57d8a2f
|
| metadata
| {u'aim': u'testing'}
|
+-----------------------------+-------------------------------------------+
The value is_public defines the level of visibility for the
share: whether other tenants can or cannot see the share. By
default, the share is private. Now you can mount the created
share like a remote file system and use it for your purposes.
ヒント
See subsection “Share Management” of “Shared
File Systems” section of Cloud Administration
Guide document for the details on share management
operations.
共有へのアクセス権の管理
Currently, you have a share and would like to control access
to this share for other users. For this, you have to perform
a number of steps and operations. Before getting to manage
access to the share, pay attention to the following important
parameters. To grant or deny access to a share, specify one of
these supported share access levels:
• rw: 読み書きアクセス。デフォルト。
• ro: 読み取り専用アクセス。
Additionally, you should also specify one of these supported
authentication methods:
• ip: authenticates an instance through its IP address. A valid
format is XX.XX.XX.XX orXX.XX.XX.XX/XX. For example 0.0.0.0/0.
• cert: authenticates an instance through a TLS certificate.
Specify the TLS identity as the IDENTKEY. A valid value is
149
OpenStack 運用ガイド
February 1, 2016
any string up to 64 characters long in the common name (CN)
of the certificate. The meaning of a string depends on its
interpretation.
• user: authenticates by a specified user or group name. A valid
value is an alphanumeric string that can contain some special
characters and is from 4 to 32 characters long.
注記
Do not mount a share without an access rule! This can
lead to an exception.
Allow access to the share with IP access type and 10.254.0.4 IP
address:
$ manila access-allow Share1 ip 10.254.0.4 --access-level rw
+--------------+--------------------------------------+
| Property
| Value
|
+--------------+--------------------------------------+
| share_id
| 7bcd888b-681b-4836-ac9c-c3add4e62537 |
| access_type | ip
|
| access_to
| 10.254.0.4
|
| access_level | rw
|
| state
| new
|
| id
| de715226-da00-4cfc-b1ab-c11f3393745e |
+--------------+--------------------------------------+
Mount the Share:
$ sudo mount -v -t nfs 10.254.0.5:/shares/share-5789ddcf-35c9-4b64a28a-7f6a4a574b6a /mnt/
Then check if the share mounted successfully and according to the
specified access rules:
$ manila access-list Share1
+--------------------------------------+-------------+-----------+--------------+--------+
| id
| access type | access to | access
level | state |
+--------------------------------------+-------------+-----------+--------------+--------+
| 4f391c6b-fb4f-47f5-8b4b-88c5ec9d568a | user
| demo
| rw
| error |
| de715226-da00-4cfc-b1ab-c11f3393745e | ip
| 10.254.0.4 | rw
| active |
+--------------------------------------+-------------+-----------+--------------+--------+
150
OpenStack 運用ガイド
February 1, 2016
注記
Different share features are supported by different
share drivers. In these examples there was used generic
(Cinder as a back-end) driver that does not support
user and cert authentication methods.
ヒント
For the details of features supported by different
drivers see section “Manila share features support
mapping” of Manila Developer Guide document.
共有の管理
There are several other useful operations you would perform when
working with shares.
共有の更新
To change the name of a share, or update its description, or
level of visibility for other tenants, use this command:
$ manila update Share1 --description "My first share. Updated" --is-public
False
Check the attributes of the updated Share1:
$ manila show Share1
+-----------------------------+--------------------------------------------+
| Property
| Value
|
+-----------------------------+--------------------------------------------+
| status
| available
|
| share_type_name
| default
|
| description
| My first share. Updated
|
| availability_zone
| nova
|
| share_network_id
| 5c3cbabb-f4da-465f-bc7f-fadbe047b85a
|
| export_locations
| 10.254.0.3:/shares/share-2d5e2c0a-1f84-... |
| share_server_id
| 41b7829d-7f6b-4c96-aea5-d106c2959961
|
| host
| manila@generic1#GENERIC1
|
| snapshot_id
| None
|
| is_public
| False
|
| task_state
| None
|
| snapshot_support
| True
|
| id
| aca648eb-8c03-4394-a5cc-755066b7eb66
|
| size
| 1
|
| name
| Share1
|
151
OpenStack 運用ガイド
February 1, 2016
| share_type
| c0086582-30a6-4060-b096-a42ec9d66b86
|
| created_at
| 2015-09-24T12:19:06.000000
|
| share_proto
| NFS
|
| consistency_group_id
| None
|
| source_cgsnapshot_member_id | None
|
| project_id
| 20787a7ba11946adad976463b57d8a2f
|
| metadata
| {u'aim': u'testing'}
|
+-----------------------------+--------------------------------------------+
共有状態のリセット
Sometimes a share may appear and then hang in an erroneous
or a transitional state. Unprivileged users do not have the
appropriate access rights to correct this situation. However,
having cloud administrator's permissions, you can reset the
share's state by using
$ manila reset-state [–state state] share_name
command to reset share state, where state indicates which state
to assign the share to. Options include: available, error,
creating, deleting, error_deleting states.
$ manila reset-state Share2 --state deleting
の実行後、共有の状態を確認します。
$ manila show Share2
+-----------------------------+-------------------------------------------+
| Property
| Value
|
+-----------------------------+-------------------------------------------+
| status
| deleting
|
| share_type_name
| default
|
| description
| share from a snapshot.
|
| availability_zone
| nova
|
| share_network_id
| 5c3cbabb-f4da-465f-bc7f-fadbe047b85a
|
| export_locations
| []
|
| share_server_id
| 41b7829d-7f6b-4c96-aea5-d106c2959961
|
| host
| manila@generic1#GENERIC1
|
| snapshot_id
| 962e8126-35c3-47bb-8c00-f0ee37f42ddd
|
| is_public
| False
|
| task_state
| None
|
| snapshot_support
| True
|
| id
| b6b0617c-ea51-4450-848e-e7cff69238c7
|
| size
| 1
|
| name
| Share2
|
| share_type
| c0086582-30a6-4060-b096-a42ec9d66b86
|
| created_at
| 2015-09-25T06:25:50.000000
|
| export_location
| 10.254.0.3:/shares/share-1dc2a471-3d47-...|
| share_proto
| NFS
|
152
OpenStack 運用ガイド
February 1, 2016
| consistency_group_id
| None
|
| source_cgsnapshot_member_id | None
|
| project_id
| 20787a7ba11946adad976463b57d8a2f
|
| metadata
| {u'source': u'snapshot'}
|
+-----------------------------+-------------------------------------------+
共有の削除
共有が必要なくなった場合、次のように manila delete
share_name_or_ID コマンドを使用して削除できます。
$ manila delete Share2
注記
If you specified the consistency group while creating
a share, you should provide the --consistency-group
parameter to delete the share:
$ manila delete ba52454e-2ea3-47fa-a683-3176a01295e6 --consistency-group
ffee08d9-c86c-45e5-861e-175c731daca2
Sometimes it appears that a share hangs in one of transitional
states (i.e. creating, deleting, managing, unmanaging, extending,
and shrinking). In that case, to delete it, you need manila
force-delete share_name_or_ID command and administrative
permissions to run it:
$ manila force-delete b6b0617c-ea51-4450-848e-e7cff69238c7
ヒント
For more details and additional information about other
cases, features, API commands etc, see subsection
“Share Management” of “Shared File Systems” section
of Cloud Administration Guide document.
スナップショットの作成
The Shared File Systems service provides a mechanism of snapshots
to help users to restore their own data. To create a snapshot,
use manila snapshot-create command like:
$ manila snapshot-create Share1 --name Snapshot1 --description "Snapshot of
Share1"
+-------------+--------------------------------------+
| Property
| Value
|
153
OpenStack 運用ガイド
February 1, 2016
+-------------+--------------------------------------+
| status
| creating
|
| share_id
| aca648eb-8c03-4394-a5cc-755066b7eb66 |
| name
| Snapshot1
|
| created_at | 2015-09-25T05:27:38.862040
|
| share_proto | NFS
|
| id
| 962e8126-35c3-47bb-8c00-f0ee37f42ddd |
| size
| 1
|
| share_size | 1
|
| description | Snapshot of Share1
|
+-------------+--------------------------------------+
Then, if needed, update the name and description of the created
snapshot:
$ manila snapshot-rename Snapshot1 Snapshot_1 --description "Snapshot of
Share1. Updated."
To make sure that the snapshot is available, run:
$ manila snapshot-show Snapshot1
+-------------+--------------------------------------+
| Property
| Value
|
+-------------+--------------------------------------+
| status
| available
|
| share_id
| aca648eb-8c03-4394-a5cc-755066b7eb66 |
| name
| Snapshot1
|
| created_at | 2015-09-25T05:27:38.000000
|
| share_proto | NFS
|
| id
| 962e8126-35c3-47bb-8c00-f0ee37f42ddd |
| size
| 1
|
| share_size | 1
|
| description | Snapshot of Share1
|
+-------------+--------------------------------------+
ヒント
For more details and additional information on
snapshots, see subsection “Share Snapshots”
of “Shared File Systems” section of “Cloud
Administration Guide” document.
共有ネットワークの作成
To control a share network, Shared File Systems service requires
interaction with Networking service to manage share servers on
its own. If the selected driver runs in a mode that requires such
kind of interaction, you need to specify the share network when a
share is created. For the information on share creation, see 「共
154
OpenStack 運用ガイド
February 1, 2016
有の作成」 [146] earlier in this chapter. Initially, check the
existing share networks type list by:
$ manila share-network-list
+--------------------------------------+--------------+
| id
| name
|
+--------------------------------------+--------------+
+--------------------------------------+--------------+
If share network list is empty or does not contain a required
network, just create, for example, a share network with a private
network and subnetwork.
$ manila share-network-create --neutron-net-id
5ed5a854-21dc-4ed3-870a-117b7064eb21 --neutron-subnet-id 74dcfb5ab4d7-4855-86f5-a669729428dc --name my_share_net --description "My first share
network"
+-------------------+--------------------------------------+
| Property
| Value
|
+-------------------+--------------------------------------+
| name
| my_share_net
|
| segmentation_id
| None
|
| created_at
| 2015-09-24T12:06:32.602174
|
| neutron_subnet_id | 74dcfb5a-b4d7-4855-86f5-a669729428dc |
| updated_at
| None
|
| network_type
| None
|
| neutron_net_id
| 5ed5a854-21dc-4ed3-870a-117b7064eb21 |
| ip_version
| None
|
| nova_net_id
| None
|
| cidr
| None
|
| project_id
| 20787a7ba11946adad976463b57d8a2f
|
| id
| 5c3cbabb-f4da-465f-bc7f-fadbe047b85a |
| description
| My first share network
|
+-------------------+--------------------------------------+
The segmentation_id, cidr, ip_version, and network_type share
network attributes are automatically set to the values determined
by the network provider.
Then check if the network became created by requesting the
networks list once again:
$ manila share-network-list
+--------------------------------------+--------------+
| id
| name
|
+--------------------------------------+--------------+
| 5c3cbabb-f4da-465f-bc7f-fadbe047b85a | my_share_net |
+--------------------------------------+--------------+
Finally, to create a share that uses this share network, get to
Create Share use case described earlier in this chapter.
155
OpenStack 運用ガイド
February 1, 2016
ヒント
See subsection “Share Networks” of “Shared File
Systems” section of Cloud Administration Guide
document for more details.
共有ネットワークの管理
There is a pair of useful commands that help manipulate share
networks. To start, check the network list:
$ manila share-network-list
+--------------------------------------+--------------+
| id
| name
|
+--------------------------------------+--------------+
| 5c3cbabb-f4da-465f-bc7f-fadbe047b85a | my_share_net |
+--------------------------------------+--------------+
If you configured the back-end with driver_handles_share_servers
= True (with the share servers) and had already some
operations in the Shared File Systems service, you can see
manila_service_network in the neutron list of networks. This
network was created by the share driver for internal usage.
$ neutron net-list
+--------------+------------------------+-----------------------------------+
| id
| name
| subnets
|
+--------------+------------------------+-----------------------------------+
| 3b5a629a-e...| manila_service_network | 4f366100-50... 10.254.0.0/28
|
| bee7411d-d...| public
| 884a6564-01... 2001:db8::/64
|
|
|
| e6da81fa-55... 172.24.4.0/24
|
| 5ed5a854-2...| private
| 74dcfb5a-bd... 10.0.0.0/24
|
|
|
| cc297be2-51... fd7d:177d:a48b::/64
|
+--------------+------------------------+-----------------------------------+
You also can see detailed information about the share network
including network_type, segmentation_id fields:
$ neutron net-show manila_service_network
+---------------------------+--------------------------------------+
156
OpenStack 運用ガイド
February 1, 2016
| Field
| Value
|
+---------------------------+--------------------------------------+
| admin_state_up
| True
|
| id
| 3b5a629a-e7a1-46a3-afb2-ab666fb884bc |
| mtu
| 0
|
| name
| manila_service_network
|
| port_security_enabled
| True
|
| provider:network_type
| vxlan
|
| provider:physical_network |
|
| provider:segmentation_id | 1068
|
| router:external
| False
|
| shared
| False
|
| status
| ACTIVE
|
| subnets
| 4f366100-5108-4fa2-b5b1-989a121c1403 |
| tenant_id
| 24c6491074e942309a908c674606f598
|
+---------------------------+--------------------------------------+
You also can add and remove the security services to the share
network.
ヒント
For details, see subsection "Security Services" of
“Shared File Systems” section of Cloud Administration
Guide document.
インスタンス
インスタンスは OpenStack クラウドの中で実行中の仮想マシンです。こ
のセクションは、インスタンス、インスタンスが使用するイメージ、イ
ンスタンスのネットワークプロパティを扱うための方法について取り扱
います。また、それらがデータベースでどのように表現されているかに
ついて取り扱います。
インスタンスの起動
インスタンスを起動するには、イメージ、フレーバーおよび名前を選択
する必要があります。名前は一意である必要がありませんが、名前が一
意である限りは、多くのツールが UUID の代わりに名前を使用できるの
で、シンプルにできます。インスタンスの起動は、ダッシュボードにお
いて、インスタンスページにある起動ボタン、またはイメージとスナッ
プショットページにあるイメージまたはスナップショットの隣にある起
動アクションから実行できます。
コマンドラインで、このようにします。
$ nova boot --flavor <flavor> --image <image> <name>
157
OpenStack 運用ガイド
February 1, 2016
指定できる多くのオプション項目があります。インスタンスを起動しよ
うとする前に、このセクションを最後まで読んでください。しかし、こ
れが今から説明する詳細の基本となるコマンドです。
ダッシュボードからインスタンスを削除するには、インスタンスページ
においてインスタンスの隣にあるインスタンスの終了アクションを選択
します。または、コマンドラインから次のとおり実行します:
$ nova delete <instance-uuid>
注意すべき大事な点は、インスタンスの電源オフは、OpenStack 的な意
味でのインスタンスの終了ではないということです。
インスタンスの起動失敗
インスタンスの開始に失敗し、すぐにエラー状態になるならば、何が問
題なのかを追跡するために、いくつかの異なる方法があります。いくつ
かの方法は通常のユーザーアクセスで実行でき、他の方法ではログサー
バーやコンピュートノードへのアクセスが必要です。
ノードが起動に失敗する最も簡単な理由は、クォータ違反、またはスケ
ジューラーがインスタンスを実行するのに適したコンピュートノードを
見つけられなかった場合です。これらの場合、失敗したインスタンスに
対して nova show を実行するとエラーが表示されます。
$ nova show test-instance
+------------------------+-----------------------------------------------------\
| Property
| Value
/
+------------------------+-----------------------------------------------------\
| OS-DCF:diskConfig
| MANUAL
/
| OS-EXT-STS:power_state | 0
\
| OS-EXT-STS:task_state | None
/
| OS-EXT-STS:vm_state
| error
\
| accessIPv4
|
/
| accessIPv6
|
\
| config_drive
|
/
| created
| 2013-03-01T19:28:24Z
\
| fault
| {u'message': u'NoValidHost', u'code': 500, u'created/
| flavor
| xxl.super (11)
\
| hostId
|
/
| id
| 940f3b2f-bd74-45ad-bee7-eb0a7318aa84
\
| image
| quantal-test (65b4f432-7375-42b6-a9b8-7f654a1e676e) /
| key_name
| None
\
| metadata
| {}
/
| name
| test-instance
\
| security_groups
| [{u'name': u'default'}]
/
| status
| ERROR
\
| tenant_id
| 98333a1a28e746fa8c629c83a818ad57
/
| updated
| 2013-03-01T19:28:26Z
\
| user_id
| a1ef823458d24a68955fec6f3d390019
/
+------------------------+-----------------------------------------------------\
この場合、fault メッセージに NoValidHost が表示されていま
す。NoValidHost はスケジューラーがインスタンスの要件を満たせな
かったことを意味します。
158
OpenStack 運用ガイド
February 1, 2016
nova show が十分な失敗の理由が表示されていない場合、そのインスタ
ンスがスケジューリングされたコンピュートノードの nova-compute.log
やスケジューラーホストの nova-scheduler.log を、インスタンスの
UUID で検索するのが、より低レベルの問題を調査する良い出発点となり
ます。
管理ユーザーとして nova show を使用すると、インスタンスがスケ
ジュールされたコンピュートノードが hostId として表示されます。イ
ンスタンスがスケジュール中に失敗していれば、この項目が空白です。
インスタンス固有データの使用
インスタンス固有のデータには 2 種類あります。メタデータとユーザー
データです。
インスタンスメタデータ
Compute では、インスタンスのメタデータはインスタンスと関連付
けられたキーバリューペアの集まりです。エンドユーザーがこれらの
キーバリューペアを読み書きするために Compute API を使用すると
き、Compute がインスタンスの生存期間中にインスタンスの内外からこ
れらを読み書きします。しかしながら、Amazon EC2 メタデータサービス
と互換性のあるメタデータサービスを用いて、インスタンスに関連付け
られたキーバリューペアをクエリーできません。
インスタンスのメタデータの場合、ユーザーが nova コマンドを使用し
て SSH 鍵を生成および登録できます。
$ nova keypair-add mykey > mykey.pem
これにより、インスタンスと関連付けられる mykey という名前の鍵が生
成されます。mykey.pem というファイルが秘密鍵です。これは、mykey
鍵が関連付けられたインスタンスに root アクセスできるので、安全な
場所に保存すべきです。
このコマンドを使用して、既存の鍵を OpenStack に登録します。
$ nova keypair-add --pub-key mykey.pub mykey
注記
この鍵と関連付けられたインスタンスにアクセスするため
に、対応する秘密鍵を持つ必要があります。
起動時にインスタンスに鍵を関連付けるには、たとえば、コマンドライ
ンに --key_name mykey を追加します。例えば、
159
OpenStack 運用ガイド
February 1, 2016
$ nova boot --image ubuntu-cloudimage --flavor 2 --key_name mykey myimage
サーバーを起動するとき、他の実行中のインスタンスと区別しやすくす
るために、メタデータを追加することもできます。--meta オプションを
キーバリューペアとともに使用します。ここで、キーとバリューの両方
の文字列を指定することができます。たとえば、説明とサーバーの作成
者を追加できます。
$ nova boot --image=test-image --flavor=1 \
--meta description='Small test image' smallimage
サーバーの情報を表示するとき、metadata 行に含まれるメタデータを参
照できます:
160
OpenStack 運用ガイド
February 1, 2016
$ nova show smallimage
+------------------------+-----------------------------------------+
|
Property
|
Value
|
+------------------------+-----------------------------------------+
| OS-DCF:diskConfig
|
MANUAL
|
| OS-EXT-STS:power_state |
1
|
| OS-EXT-STS:task_state |
None
|
| OS-EXT-STS:vm_state
|
active
|
|
accessIPv4
|
|
|
accessIPv6
|
|
|
config_drive
|
|
|
created
|
2012-05-16T20:48:23Z
|
|
flavor
|
m1.small
|
|
hostId
|
de0...487
|
|
id
|
8ec...f915
|
|
image
|
natty-image
|
|
key_name
|
|
|
metadata
| {u'description': u'Small test image'} |
|
name
|
smallimage
|
|
private network
|
172.16.101.11
|
|
progress
|
0
|
|
public network
|
10.4.113.11
|
|
status
|
ACTIVE
|
|
tenant_id
|
e83...482
|
|
updated
|
2012-05-16T20:48:35Z
|
|
user_id
|
de3...0a9
|
+------------------------+-----------------------------------------+
インスタンスのユーザーデータ
user-data 鍵は、メタデータサービス内の特別キーです。ゲストインス
タンスにあるクラウド対応アプリケーションがアクセス可能なファイル
を保持します。たとえば、cloudinit システムは、Ubuntu 発祥のオープ
ンソースパッケージですが、ほとんどのディストリビューションで利用
可能です。このユーザーデータを使用するクラウドインスタンスの初期
設定を処理します。
このユーザーデータは、ローカルマシンのファイルに保存され、--userdata <user-data-file> フラグを用いてインスタンスの生成時に渡され
ます。たとえば:
$ nova boot --image ubuntu-cloudimage --flavor 1 --user-data mydata.file
mydatainstance
ユーザーデータとメタデータの違いを理解するために、インスタンスが
起動する前に、ユーザーデータが作成されることに気づいてください。
ユーザーデータは、インスタンスの実行時に、インスタンスの中からア
クセスできます。設定、スクリプト、テナントが必要とするものを保存
するために使用できます。
161
OpenStack 運用ガイド
February 1, 2016
ファイルインジェクション
--file <dst-path=src-path> 使用することにより、任意のローカルファ
イルを生成時にインスタンスのファイルシステムの中に置けます。5
ファイルまで保存できます。
例えば、何らかの理由で通常の SSH 鍵の注入ではな
く、special_authorized_keysfile という名前の特別な
authorized_keys ファイルをインスタンスに置きたいと言うとします。
この場合、以下のコマンドを使用できます:
$ nova boot --image ubuntu-cloudimage --flavor 1 \
--file /root/.ssh/authorized_keys=special_authorized_keysfile
authkeyinstance
セキュリティグループの割り当て
セキュリティグループは、前に記載したように、プロジェクトのデフォ
ルトのセキュリティグループがより許可するよう変更されていない限
り、インスタンスへのネットワーク通信を許可するために一般的に必要
となります。
セキュリティグループの追加は、一般的にインスタンスの起動時に実行
されます。ダッシュボードから起動するとき、これはインスタンスの起
動ダイアログのアクセスとセキュリティタブにあります。コマンドライ
ンから起動する場合には、--security-groups にセキュリティグループ
のコンマ区切り一覧を指定します。
インスタンスを実行中にセキュリティグループを追加および削除するこ
ともできます。現在、コマンドラインツールからのみ利用可能です。例:
$ nova add-secgroup <server> <securitygroup>
$ nova remove-secgroup <server> <securitygroup>
Floating IP
Floating IP はクラウド全体で設定されますが、各プロジェクトは
クォータにより Floating IP 数を制限されているでしょう。使用する前
に中央プールからプロジェクトに確保する必要があります。一般的に、
プロジェクトの管理者により行われます。ダッシュボードのアクセスと
セキュリティページのFloating IPタブのFloating IP の確保ボタンを使
用して、Floating IP をプロジェクトに確保します。コマンドラインを
使用することもできます。
$ nova floating-ip-create
162
OpenStack 運用ガイド
February 1, 2016
一度確保すると、Floating IP を実行中のインスタンスに割り当てる
ことができます。ダッシュボードでは、アクセスとセキュリティペー
ジの Floating IPs タブにある IP の隣にある、アクションドロップ
ダウンからFloating IP の割り当てを選択することにより実行できま
す。または、インスタンスページにおいて割り当てたいインスタンス
の隣にある、リストからこれを選択することにより実行できます。逆
の動作 Floating IP の割り当て解除はアクセスとセキュリティページ
のFloating IPs タブから実行できます。インスタンスのページから利用
できません。
以下のコマンドを使用して、コマンドラインからサーバーに Floating
IP アドレスを関連付けまたは関連付け解除します。
$ nova add-floating-ip <server> <address>
$ nova remove-floating-ip <server> <address>
ブロックストレージの接続
ダッシュボードの ボリューム ページから、インスタンスにブロックス
トレージを接続できます。接続したいボリュームの隣にある 接続の編集
をクリックします。
このアクションをコマンドラインから実行するには、以下のコマンドを
実行します
$ nova volume-attach <server> <volume> <device>
nova コマンドラインクライアントに以下のようにオプションを付けて、
インスタンスの起動時にブロックデバイスのマッピングを指定すること
もできます。
--block-device-mapping <dev-name=mapping>
ブロックデバイスマッピングのフォーマットは <devname>=<id>:<type>:<size(GB)>:<delete-on-terminate>、それぞれ、
dev-name
そのボリュームはシステムで /dev/dev_name
に接続されます。
id
起動するボリュームの ID。nova volumelist の出力に表示されます。
type
ボリュームがスナップショットから作成さ
れたことを意味する snap、または snap 以
外の何か (空文字列も有効) です。上の例で
は、ボリュームがスナップショットから作成
163
OpenStack 運用ガイド
February 1, 2016
されていません。そのため、この項目を以下
の例において空白にしてあります。
size (GB)
ボリュームのギガバイト単位の容量。この
フィールドを空欄にして、Compute サービス
に容量を推定させるのが安全です。
delete-on-terminate
インスタンスが終了したときに、ボリューム
が削除されるかどうかを指示する論理値で
す。真は True または 1 として指定できま
す。偽は False または 0 として指定できま
す。
以下のコマンドは、新しいインスタンスを起動して、同時にボリューム
を接続します。ID 13 のボリュームが /dev/vdc として接続されます。
これは、スナップショットではなく、容量を指定せず、インスタンスの
削除時に一緒に削除されます。
$ nova boot --image 4042220e-4f5e-4398-9054-39fbd75a5dd7 \
--flavor 2 --key-name mykey --block-device-mapping vdc=13:::0 \
boot-with-vol-test
ブート可能なファイルシステムイメージでブロックストレージを事前に
準備していると、永続ブロックストレージからブートすることもでき
ます。以下のコマンドは、指定したボリュームからイメージを起動しま
す。前のコマンドに似ていますが、イメージが省略され、ボリュームが
/dev/vda として接続されます。
$ nova boot --flavor 2 --key-name mykey \
--block-device-mapping vda=13:::0 boot-from-vol-test
詳細は、OpenStack エンドユーザーガイドの「ボリュームからのインス
タンスの起動」にある説明を参照してください。
通常通りイメージから起動し、ブロックストレージを接続するため
に、vda 以外のデバイスを対応付けます。OpenStack エンドユーザーガ
イドに、インスタンスを起動して、それにボリュームを接続する方法、
接続されたボリュームにイメージをコピーする方法が説明されていま
す。
スナップショットの取得
OpenStack のスナップショット機能により、実行中のインスタンスから
新しいイメージを作成することもできます。これは、ベースイメージを
アップグレードするため、公開されているイメージをカスタマイズする
ために、非常に便利です。このように CLI を使用して、実行中のインス
タンスをイメージにスナップショットをとります。
164
OpenStack 運用ガイド
February 1, 2016
$ nova image-create <instance name or uuid> <name of new image>
ダッシュボードのインターフェースでは、スナップショットとイメージ
が両方ともイメージのページに表示されるため、まぎらわしいかもし
れません。しかしながら、インスタンスのスナップショットはイメー
ジです。Image service に直接アップロードしたイメージと、スナップ
ショットにより作成したイメージとの唯一の違いは、スナップショット
により作成されたイメージが glance データベースにおいて追加のプロ
パティを持つことです。これらのプロパティは image_properties テー
ブルで確認でき、次の項目を含みます:
名前
値
image_type
スナップショット
instance_uuid
<スナップショットされたインスタンスの
UUID>
base_image_ref
<スナップショットされたインスタンスの元イ
メージの UUID>
image_location
スナップショット
ライブスナップショット
ライブスナップショットは、ユーザーが実行中の仮想マシンのスナップ
ショットを一時停止なしで取得できる機能です。このスナップショット
は単にディスクのみのスナップショットです。現在はインスタンスのス
ナップショットは停止時間なしで実行できます (QEMU 1.3+ と libvirt
1.0+ が使用されていることが前提です)。
ライブスナップショットの無効化
libvirt バージョン 1.2.2 を使用している場合、ライブス
ナップショットの作成において、断続的な問題を経験するか
もしれません。
問題が解決するまでは、libvirt のライブスナップショット
を効果的に無効化するために、以下の設定を nova.conf に追
加します。
[workarounds]
disable_libvirt_livesnapshot = True
Linux ゲストのスナップショットの一貫性の保証
以下のセクションは、Sébastien Han さんの “OpenStack:
Perform Consistent Snapshots” ブログ記事からの引用です。
165
OpenStack 運用ガイド
February 1, 2016
スナップショットは、ファイルシステムの状態をキャプチャーしま
すが、メモリーの状態をキャプチャーしません。そのため、スナッ
プショットに期待するデータが含まれることを確実にするために、
次のことを確実にする必要があります。
• 実行中のプログラムがコンテンツをディスクに書き込んだこと
• ファイルシステムが「ダーティー」バッファーを持たないこと:
「ダーティー」バッファーがあるとは、プログラムがディスクに
書き込むためにコマンドを発行しましたが、オペレーティングシ
ステムがまだ書き込みを完了していないことです。
(データベースのような) 重要なサービスがコンテンツをディスク
に書き込んだことを保証するために、それらのアプリケーションの
ドキュメントを読んで、コンテンツをディスクに同期させるために
どのコマンドを発行する必要があるかを調べることを推奨します。
ディスクに同期させるための方法がはっきり分からない場合、最も
安全な方法は単にこれらの実行中のサービスを通常通り停止するこ
とです。
「ダーティー」バッファーの問題を解決するために、スナップ
ショットの前に sync コマンドを使用することを推奨します。
# sync
sync を実行することにより、ダーティーバッファー (変更された
が、ディスクに書き込まれていないバッファー済みブロック) を
ディスクに書き込みます。
ファイルシステムが一貫性を持つことを保証するためには、単に
sync を実行するだけでは不十分です。fsfreeze ツールを使用する
ことを推奨します。これは、ファイルシステムに対する新規アクセ
スを停止し、スナップショットに適した安定したイメージをディス
クに作成します。fsfreeze は ext3, ext4 および XFS を含むいく
つかのファイルシステムをサポートします。仮想マシンのインスタ
ンスが Ubuntu において実行されていれば、fsfreeze を取得する
ために util-linux パッケージをインストールします:
注記
ベースとするスナップショットが LVM 経由で取得され
ている非常に一般的な場合、ファイルシステムのフリー
ズは、LVM により自動的に処理されます。
# apt-get install util-linux
166
OpenStack 運用ガイド
February 1, 2016
お使いのオペレーティングシステムに利用可能なバージョン
の fsfreeze がなければ、代わりに xfs_freeze を使用できま
す。これは Ubuntu の xfsprogs パッケージにおいて利用可能で
す。"xfs" という名前にもかかわらず、xfs_freeze は Linux カー
ネル 2.6.29 またはそれ以降を使用していれば ext3 や ext4 にお
いても動作します。それは 2.6.29 において開始された仮想ファイ
ルシステム (VFS) レベルで動作するためです。この xfs_freeze
のバージョンは fsfreeze と同じ名前のコマンドライン引数をサ
ポートします。
永続ブロックストレージのスナップショットを取得したい例を検討
します。ゲストオペレーティングシステムにより /dev/vdb として
認識され、/mnt にマウントされているとします。fsfreeze コマン
ドが 2 つの引数を受け取ります:
-f
システムをフリーズします
-u
システムを解凍 (フリーズ解除) します
スナップショットの準備においてボリュームをフリーズするには、
インスタンスの中で root として次のとおり実行します:
# fsfreeze -f /mnt
fsfreeze コマンドを実行する前に、ファイルシステムをマウント
する必要があります。
fsfreeze -f コマンドが発行された場合、ファイルシステム内で進
行中のすべてのトランザクションが完了することが認められます。
新規書き込みのシステムコールは停止されます。そして、ファイル
システムを変更する他のコールは停止されます。最も重要なことと
しては、すべてのダーティーデータ、メタデータ、およびログ情報
がディスクに書き込まれることです。
ボリュームがフリーズ状態になったら、ボリュームの読み書き命令
が止まってしまうので、ボリュームの読み書きを行わないようにし
てください。オペレーティングシステムがすべての I/O 操作を停
止し、すべての I/O 試行がファイルシステムがフリーズ解除され
るまで遅延させられます。
fsfreeze コマンドを発行すると、スナップショットを実行しても
安全です。たとえば、インスタンスが mon-instance という名前
で、mon-snapshot という名前のイメージにスナップショットを取
得したければ、以下のとおり実行します:
$ nova image-create mon-instance mon-snapshot
167
OpenStack 運用ガイド
February 1, 2016
スナップショットの作成が終わったら、インスタンスの中で root
として以下のコマンドを用いて、ファイルシステムをフリーズ解除
できます。
# fsfreeze -u /mnt
ルートファイルシステムをバックアップしたければ、プロンプトが
フリーズしてしますので、上のコマンドを単純に実行できません。
代わりに、インスタンスの中で root として以下の 1 行を実行し
ます。
# fsfreeze -f / && read x; fsfreeze -u /
このコマンドの後、お使いの端末から nova image-create を呼び
出すことが一般的な慣習です。実行した後、インスタンスの中で
Enter キーを押して、フリーズ解除します。もちろん、これを自動
化できますが、少なくとも適切に同期できるようになるでしょう。
Windows ゲストのスナップショットの一貫性の保証
Windows 仮想マシンの一貫性あるスナップショットの取得
は、Linux マシンのスナップショットの場合と同じようなもので
す。ただし、一貫性バックアップを働かせるために、Windows 専用
のサブコマンドと調整するための追加機能を必要とします。
Windows XP 以降は、従順なアプリケーションが動作中のファイル
システムで一貫性のあるバックアップを取得できるようにするフ
レームワークを提供する Volume Shadow Copy Service (VSS) が
含まれます。このフレームワークを使用するために、VSS リクエス
ターが、一貫性バックアップを必要とすることを VSS サービスに
対してシグナルを発行します。VSS サービスは、従順なアプリケー
ション (VSS ライターと言います) に通知して、これらのデータ処
理を休止します。そして、VSS サービスがコピープロバイダーにス
ナップショットを作成するよう指示します。スナップショットが作
成されると、VSS サービスが VSS ライターをフリーズ解除して、
通常の I/O アクティビティーが再開されます。
QEMU は、KVM ハイパーバイザーにおいて動作しているゲストで実
行できるゲストエージェントを提供しています。Windows 仮想マシ
ンの場合、このゲストエージェントは、Windows VSS サービスと連
携して、スナップショットの一貫性を保証する流れを楽にします。
この機能は QEMU 1.7 以降を必要とします。関連するゲストエー
ジェントのコマンドは次のとおりです。
168
OpenStack 運用ガイド
February 1, 2016
guest-file-flush
「ダーティー」バッファーをディスク
に書き出します。Linux の sync 処理
と似ています。
guest-fsfreeze
ディスクへの I/O を一時停止しま
す。Linux の fsfreeze -f 処理と似て
います。
guest-fsfreeze-thaw
ディスクへの I/O を再開しま
す。Linux の fsfreeze -u 処理と似て
います。
Windows 仮想マシンのスナップショットを取得する場合、以下のコ
マンドを連続して実行するスクリプト化できます。ファイルシステ
ムをフラッシュする、ファイルシステムをフリーズする、ファイ
ルシステムのスナップショットを取得する、ファイルシステムをフ
リーズ解除する。Linux 仮想マシンのワークフローと同じように、
そのようなスクリプトを書くときに、注意して使用すべきです。エ
ラー処理を徹底して、ファイルシステムがフリーズ状態のままにな
らないようにします。
データベースにあるインスタンス
インスタンスの情報が数多くのデータベースのテーブルに保存されます
が、ユーザーのインスタンスに関連して参照する必要がありそうなテー
ブルは、instances テーブルです。
インスタンスのテーブルは、実行中および削除済みの両方のインスタン
スに関連する情報のほとんどを保持しています。データベースで完全な
リストを見ると、このテーブルには目が回るほどたくさんのフィールド
があることがわかります。以下に、クエリーを行おうとしている運用者
にとって非常に有用なフィールドを挙げます。
• deleted フィールドは、インスタンスが削除されていると 1 がセット
されます。削除されていなければ NULL です。このフィールドは、ク
エリーから削除済みインスタンスを除外するために重要です。
• uuid フィールドはインスタンスの UUID です。データベースにある他
の表において外部キーとして使用されます。この ID は、インスタン
スを一意に識別するために、ログ、ダッシュボードおよびコマンドラ
インツールにおいて表示されます。
• 外部キーはインスタンスの関連を見つけるために利用可能です。これ
らの中で最も有用なものは、user_id および project_id です。これ
169
OpenStack 運用ガイド
February 1, 2016
らは、インスタンスを起動したユーザー、およびそれが起動されたプ
ロジェクトの UUID です。
• host フィールドは、どのコンピュートノードがインスタンスをホスト
しているかを示します。
• hostname フィールドは、インスタンスが起動したときのインスタン
ス名を保持します。display-name は、最初は hostname と同じです
が、nova rename コマンドを使って再設定することができます。
多くの時刻関連のフィールドは、いつ状態の変化がインスタンスに起
こったかを追跡する際に役に立ちます:
• created_at
• updated_at
• deleted_at
• scheduled_at
• launched_at
• terminated_at
グッドラック！
このセクションは、多くの OpenStack コマンドの中から、いくつかの最
も有用なものを簡単に説明することを意図していました。膨大なリスト
は、管理者ユーザーガイドを参照してください。さらなるヒントやコツ
は、Cloud Admin Guide を参照してください。ユーザーが幸せなままで
あり、あなたのハードワークに気づくことを願います。（さらなるハー
ドワークは、次の章にページを進んでください。システムが直面する運
用、メンテナンス、障害、デバッグについて議論しています。）
170
OpenStack 運用ガイド
February 1, 2016
第11章 メンテナンス、故障および
デバッグ
クラウドコントローラーとストレージプロキシの故障とメンテナン
ス .........................................................
コンピュートノードの故障とメンテナンス ......................
ストレージノードの故障とメンテナンス ........................
完全な故障の対処 ...........................................
構成管理 ...................................................
ハードウェアの取り扱い .....................................
データベース ...............................................
HDWMY ......................................................
故障しているコンポーネントの特定 ............................
アンインストール ...........................................
171
173
180
181
182
183
184
185
186
189
停止時間（計画的なものと予定外のものの両方）はクラウドを運用する
ときに確実に発生します。本章は、プロアクティブまたはリアクティブ
に、これらの出来事に対処するために有用な情報を提供することを目的
としています。
クラウドコントローラーとストレージプ
ロキシの故障とメンテナンス
想定内の場合も想定外の場合も停止時間が発生した場合の挙動が、クラ
ウドコントローラーとストレージプロキシは互いに似ています。クラウ
ドコントローラーとストレージプロキシはそれぞれクラウドで一つ実行
されるので、動作していない場合、非常に目立ちます。
クラウドコントローラーの場合、良いニュースとしては、クラウドが
FlatDHCP マルチホスト HA ネットワークモードを使用していれば、既
存のインスタンスとボリュームはクラウドコントローラーがオフライン
の間も動作を継続するという点があります。しかしながら、ストレージ
プロキシの場合には、サーバーが元に戻され動作状態になるまで、スト
レージとの通信ができません。
計画メンテナンス
クラウドコントローラーやストレージプロキシのメンテナンスを計画す
る一つの方法は、単に午前 1 時や 2 時のような利用の少ない時間帯に
実行することです。この戦略はあまり多くのユーザーに影響を与えませ
ん。クラウドコントローラーやストレージプロキシが、いかなる時間帯
171
OpenStack 運用ガイド
February 1, 2016
においても、サービスが利用できないことによる影響が大きければ、高
可用性オプションについて検討する必要があります。
クラウドコントローラーとストレージプロキシの
再起動
大体の場合、単に「再起動」コマンドを発行します。オペレーティング
システムがサービスを正常にシャットダウンして、その後、自動的に再
起動します。万全を期したい場合、再起動する前にバックアップジョブ
を実行します。
クラウドコントローラーまたはストレージプロキ
シの再起動後
クラウドコントローラーの再起動後、すべての必要なサービスが正常に
起動されたことを確認します。以下のコマンドは、ps と grep を使用
して、nova、glance、keystone が現在動作していることを確認していま
す。
#
#
#
#
ps
ps
ps
ps
aux
aux
aux
aux
|
|
|
|
grep
grep
grep
grep
novaglancekeystone
cinder
また、すべてのサービスが正しく機能していることを確認します。以下
のコマンド群は、openrc ファイルを読み込みます。そして、いくつかの
基本的な glanec、nova、openstack コマンドを実行します。コマンドが
期待したとおりに動作すれば、それらのサービスが動作状態にあると確
認できます。
#
#
#
#
source openrc
glance index
nova list
openstack project list
ストレージプロキシの場合、Object Storage サービスが再開しているこ
とを確認します。
# ps aux | grep swift
また、正しく機能していることを確認します。
# swift stat
全体的なクラウドコントローラーの故障
クラウドコントローラーは、例えばマザーボードがおかしくなった場合
に、完全に故障するでしょう。これはクラウド環境の中核的な機能を提
供しているため、ユーザーはクラウドコントローラーの損失にすぐに気
172
OpenStack 運用ガイド
February 1, 2016
づくでしょう。お使いのインフラ監視機能が、クラウド環境の障害のア
ラートを上げなかった場合でも、ユーザーは絶対に気づきます。残念な
がら、これは大まかな状況です。クラウドコントローラーは、クラウド
の必須部分です。コントローラーが 1 つだけの場合、ダウンした際に多
くのサービスが失われるでしょう。
この状況を避けるために、高可用なクラウドコントローラークラ
スターを作成します。このことは、このドキュメントの範囲外です
が、OpenStack High Availability Guide に情報があります。
次に最も優れているアプローチは、クラウドコントローラーを自動的に
構築するために Puppet のような構成管理ツールを使用することです。
利用可能な予備サーバーがあれば、15 分もかかりません。コントロー
ラーを再構築後、取得したすべてのバックアップを復元します (14章
バックアップとリカバリー [231] の章を参照してください)。
実際には、コンピュートノードの nova-compute サービスが、コント
ローラー上で動作している rabbitmq に正しく再接続されない場合が
あります。時間のかかるリブートから戻ってきた場合や、コンピュート
ノードのnova サービスを再起動する必要がある場合です。
コンピュートノードの故障とメンテナン
ス
コンピュートノードは、予期せずクラッシュしたり、メンテナンスのた
めに再起動が必要になったりすることがときどきあります。
計画メンテナンス
(ソフトウェアやハードウェアのアップグレードのように) 計画されたメ
ンテナンスのために、コンピュートノードを再起動する必要があれば、
まずホストしている全インスタンスがノード外に移動していることを
確認します。クラウドが共有ストレージを利用していれば、nova livemigration コマンドを使用します。初めに、移動させる必要があるイン
スタンスの一覧を取得します。
# nova list --host c01.example.com --all-tenants
次に、それらを一つずつマイグレーションします。
# nova live-migration <uuid> c02.example.com
共有ストレージを使用していない場合、--block-migrate オプションを
使用できます。
# nova live-migration --block-migrate <uuid> c02.example.com
173
OpenStack 運用ガイド
February 1, 2016
すべてのインスタンスをマイグレーションした後、nova-compute サービ
スが停止していることを確認します:
# stop nova-compute
Puppet などの構成管理システムを使って、nova-compute サービスが確
実に実行されているようにしている場合、init ファイルを一時的に移動
します。
# mkdir /root/tmp
# mv /etc/init/nova-compute.conf /root/tmp
# mv /etc/init.d/nova-compute /root/tmp
続けて、コンピュートノードを停止し、メンテナンスを実行し、ノー
ドを元に戻します。先のコマンドを逆に実行することにより、novacompute サービスを再び有効化できます:
# mv /root/tmp/nova-compute.conf /etc/init
# mv /root/tmp/nova-compute /etc/init.d/
そして nova-compute サービスを起動します。
# start nova-compute
インスタンスを元のコンピュートノードにマイグレーションすることも
できます。
コンピュートノードの再起動後
コンピュートノードを再起動した場合、まず正常に起動していることを
検証します。これには、nova-compute サービスの動作を確認することが
含まれます。
# ps aux | grep nova-compute
# status nova-compute
AMQP サーバーに正常に接続できることも確認します。
# grep AMQP /var/log/nova/nova-compute
2013-02-26 09:51:31 12427 INFO nova.openstack.common.rpc.common [-] Connected to AMQP server on 199.
116.232.36:5672
コンピュートノードが正常に実行された後、そのコンピュートノードで
ホストされているインスタンスはどれも動作していないので、そのコン
ピュートノードにおいてホストされているインスタンスを処理する必要
があります。ユーザーや顧客に対する SLA によっては、各インスタンス
を開始し、正常に起動していることを確認する必要がある場合もあるで
しょう。
インスタンス
以下のコマンドを実行して、コンピュートノードにホストしているイン
スタンスの一覧を作成できます。
174
OpenStack 運用ガイド
February 1, 2016
# nova list --host c01.example.com --all-tenants
一覧を取得した後、各インスタンスを起動するために nova コマンドを
使用できます。
# nova reboot <uuid>
注記
予期せずシャットダウンしたときは、ブートに問題があるか
もしれません。たとえば、インスタンスがルートパーティ
ションにおいて fsck を実行する必要があるかもしれませ
ん。もしこうなっても、これを修復するためにダッシュボー
ド VNC コンソールを使用できます。
インスタンスがブートしなければ、つまりブートしようとしても virsh
list がインスタンスを表示しなければ、コンピュートノードにおいて以
下のとおり実行します。
# tail -f /var/log/nova/nova-compute.log
再び nova reboot コマンドを実行してみてください。インスタンスがな
ぜブートできないかについて、エラーメッセージを確認すべきです。
多くの場合、エラーが libvirt の XML ファイル (/etc/libvirt/qemu/
instance-xxxxxxxx.xml) の何かになります。以下のコマンドを実行する
ことにより、インスタンスを再起動するのと同時に、強制的に XML ファ
イルを再作成できます:
# nova reboot --hard <uuid>
故障したインスタンスからの検査とデータ復旧
いくつかのシナリオでは、インスタンスが実行中であるにも関わら
ず、SSH 経由でアクセスできず、あらゆるコマンドに反応がありませ
ん。VNC コンソールがブート失敗やカーネルパニックのエラーメッセー
ジを表示している可能性があります。これは仮想マシン自身において
ファイルシステム破損の意味する可能性があります。ファイルを復旧し
たりインスタンスの中身を調査したりする必要があれば、qemu-nbd を
使ってディスクをマウントできます。
警告
ユーザーのコンテンツやデータを参照したい場合、まず許可
を得ましょう。
インスタンスのディスク (/var/lib/nova/instances/instance-xxxxxx/
disk) にアクセスするには、以下の手順を実行します。
175
OpenStack 運用ガイド
February 1, 2016
1. virsh コマンドを使用して、インスタンスを一時停止します。
2. qemu-nbd デバイスをディスクに接続します。
3. qemu-nbd デバイスをマウントします。
4. 検査後にディスクをアンマウントします。
5. qemu-nbd デバイスを切断します。
6. インスタンスを再開します。
手順 4-6 を省略すると、OpenStack Compute がインスタンスを管理でき
なくなります。OpenStack Compute により発行されるすべてのコマンド
に対する応答が失敗し、シャットダウンしているように見えます。
ディスクファイルをマウントすると、それにアクセスでき、ファイルと
ディレクトリ構造を持つ通常のディレクトリのように取り扱えます。し
かしながら、どのファイルの編集も操作もしないことをお薦めします。
なぜなら、それによりアクセス制御リスト (ACL) が変更されたり、起動
できるインスタンスが起動できなくなる場合があるからです。ACL は、
アカウントがファイルやディレクトリーにどの操作を実行できるのか判
断するために使用されます。
1. virsh コマンドを使用してインスタンスを一時停止します。内部 ID
を記録します。
# virsh list
Id Name
State
---------------------------------1 instance-00000981
running
2 instance-000009f5
running
30 instance-0000274a
running
# virsh suspend 30
Domain 30 suspended
2. qemu-nbd デバイスをディスクに接続します。
# cd /var/lib/nova/instances/instance-0000274a
# ls -lh
total 33M
-rw-rw---- 1 libvirt-qemu kvm 6.3K Oct 15 11:31
-rw-r--r-- 1 libvirt-qemu kvm 33M Oct 15 22:06
-rw-r--r-- 1 libvirt-qemu kvm 384K Oct 15 22:06
-rw-rw-r-- 1 nova
nova 1.7K Oct 15 11:30
# qemu-nbd -c /dev/nbd0 `pwd`/disk
console.log
disk
disk.local
libvirt.xml
3. qemu-nbd デバイスをマウントします。
qemu-nbd デバイスはインスタンスのディスクの個々のパーティショ
ンを別々のデバイスとしてエクスポートしようとします。たとえば、
176
OpenStack 運用ガイド
February 1, 2016
ディスクが vda で、ルートパーティションが vda1 の場合、qemu-nbd
はそれぞれ /dev/nbd0 と /dev/nbd0p1 としてデバイスをエクスポー
トします。
# mount /dev/nbd0p1 /mnt/
これで /mnt の中身にアクセスできます。これは、インスタンスの
ディスクの 1 番目のパーティションに対応します。
セカンダリディスクや一時ディスクを調査する際に、プライマリディ
スクとセカンダリディスクを同時にマウントしたければ、別のマウン
トポイントを使用してください。
# umount /mnt
# qemu-nbd -c /dev/nbd1 `pwd`/disk.local
# mount /dev/nbd1 /mnt/
# ls -lh /mnt/
total 76K
lrwxrwxrwx. 1
dr-xr-xr-x. 4
drwxr-xr-x. 2
drwxr-xr-x. 70
drwxr-xr-x. 3
lrwxrwxrwx. 1
lrwxrwxrwx. 1
drwx------. 2
drwxr-xr-x. 2
drwxr-xr-x. 2
drwxr-xr-x. 2
drwxr-xr-x. 2
dr-xr-x---. 3
drwxr-xr-x. 14
lrwxrwxrwx. 1
drwxr-xr-x. 2
drwxr-xr-x. 2
drwxrwxrwt. 9
drwxr-xr-x. 13
drwxr-xr-x. 17
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
7
4.0K
4.0K
4.0K
4.0K
7
9
16K
4.0K
4.0K
4.0K
4.0K
4.0K
4.0K
8
4.0K
4.0K
4.0K
4.0K
4.0K
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Oct
Feb
Feb
Feb
Oct
Oct
Oct
Oct
Feb
Oct
Oct
Oct
Oct
15
15
15
15
15
15
15
15
3
3
3
15
15
15
15
3
15
15
15
15
00:44
01:07
00:42
11:31
01:07
00:44
00:44
00:42
2012
2012
2012
00:42
21:56
01:07
00:44
2012
00:42
16:29
00:44
00:44
bin -> usr/bin
boot
dev
etc
home
lib -> usr/lib
lib64 -> usr/lib64
lost+found
media
mnt
opt
proc
root
run
sbin -> usr/sbin
srv
sys
tmp
usr
var
4. 調査を完了すると、マウントポイントをアンマウントし、qemu-nbd デ
バイスを解放します。
# umount /mnt
# qemu-nbd -d /dev/nbd0
/dev/nbd0 disconnected
5. virsh を使用して、インスタンスを再開します。
# virsh list
Id Name
State
---------------------------------1 instance-00000981
running
2 instance-000009f5
running
30 instance-0000274a
paused
# virsh resume 30
Domain 30 resumed
177
OpenStack 運用ガイド
February 1, 2016
ボリューム
影響するインスタンスもボリュームを接続していた場合、まずインスタ
ンスとボリュームの UUID の一覧を生成します。
mysql> select nova.instances.uuid as instance_uuid,
cinder.volumes.id as volume_uuid, cinder.volumes.status,
cinder.volumes.attach_status, cinder.volumes.mountpoint,
cinder.volumes.display_name from cinder.volumes
inner join nova.instances on cinder.volumes.instance_uuid=nova.instances.uuid
where nova.instances.host = 'c01.example.com';
以下のような結果を確認できます:
+--------------+------------+-------+--------------+-----------+--------------+
|instance_uuid |volume_uuid |status |attach_status |mountpoint | display_name |
+--------------+------------+-------+--------------+-----------+--------------+
|9b969a05
|1f0fbf36
|in-use |attached
|/dev/vdc | test
|
+--------------+------------+-------+--------------+-----------+--------------+
1 row in set (0.00 sec)
次に、ボリュームを手動で切断し、再接続します。ここで X は適切なマ
ウントポイントです。
# nova volume-detach <instance_uuid> <volume_uuid>
# nova volume-attach <instance_uuid> <volume_uuid> /dev/vdX
上記を実行する前に、インスタンスが正常に起動し、ログイン画面に
なっていることを確認します。
コンピュートノード全体の故障
コンピュートノードは、クラウドコントローラーの障害と同じように故
障します。マザーボードや他の種類のハードウェア障害により、コン
ピュートノード全体がオフラインになる可能性があります。これが発生
した場合、そのコンピュートノードで動作中のインスタンスがすべて利
用できなくなります。ちょうどクラウドコントローラーが発生した場合
のように、インフラ監視機能がコンピュートノードの障害を検知しなく
ても、インスタンスが失われるので、ユーザーが気づくでしょう。
コンピュートノードが故障し、2〜3時間もしくはそれ以上たっても復旧
できないと見込まれる場合、/var/lib/nova/instances に共有ストレー
ジを使用していれば、故障したノードで動作していたインスタンスをす
べて再スタートすることができます。
これを実行するために、nova データベースにおいて以下のクエリーを実
行することにより、故障したノードにおいてホストされているインスタ
ンスの UUID の一覧を生成します。
mysql> select uuid from instances where host = \
'c01.example.com' and deleted = 0;
178
OpenStack 運用ガイド
February 1, 2016
次に、c01.example.com においてホストされていたすべてのインスタ
ンスが、今度は c02.example.com でホストされることを伝えるために
nova データベースを更新します。
mysql> update instances set host = 'c02.example.com' where host = \
'c01.example.com' and deleted = 0;
その後、nova コマンドを使って、c01.example.com にあったすべてのイ
ンスタンスを再起動します。起動する際にインスタンスの XML ファイル
を再生成します:
# nova reboot --hard <uuid>
最後に、ボリュームのセクションで説明されているのと同じ方法を用い
て、ボリュームを再接続します。
/var/lib/nova/instances
コンピュートノードの故障の話題に関連して、このディレクトリについ
ては説明しておく価値があるでしょう。このディレクトリには、コン
ピュートノードにホストされているインスタンス用の libvirt KVM の
ファイル形式のディスクイメージが置かれます。共有ストレージ環境で
クラウドを実行していなければ、このディレクトリはコンピュートノー
ド全体で一つしかありません。
/var/lib/nova/instances には 2 種類のディレクトリがあります。
一つ目は _base ディレクトリです。ここには、そのコンピュートノード
で起動されたそれぞれのイメージに関して、glance から取得したすべて
のベースイメージのキャッシュが置かれます。_20 (または他の番号) で
終わるファイルは一時ディスクのベースイメージです。
もう一つのディレクトリは instance-xxxxxxxx という名前です。これら
のディレクトリはコンピュートノードにおいて実行中のインスタンスと
対応します。中にあるファイルは _base ディレクトリにあるファイルの
どれかと関連があります。これらは基本的に、元々の _base ディレクト
リからの変更点のみ含む、差分ベースのファイルです。
/var/lib/nova/instances にあるすべてのファイルとディレクトリ
は一意に名前が付けられています。_base にあるファイルは元となっ
た glance イメージに対応する一意に名前が付けられています。ま
た、instance-xxxxxxxx という名前が付けられたディレクトリは特定の
インスタンスに対して一意にタイトルが付けられています。たとえば、
あるコンピュートノードにある /var/lib/nova/instances のすべての
データを他のノードにコピーしたとしても、ファイルを上書きすること
はありませんし、また同じ一意な名前を持つイメージにダメージを与え
179
OpenStack 運用ガイド
February 1, 2016
ることもありません。同じ一意な名前を持つものは本質的に同じファイ
ルだからです。
この方法はドキュメントに書かれておらず、サポートされていない方法
ですが、コンピュートノードが完全にオフラインになってしまったが、
インスタンスがローカルに保存されているときに、この方法を使用でき
ます。
ストレージノードの故障とメンテナンス
オブジェクトストレージの高い冗長性のため、オブジェクトストレージ
のノードに関する問題を処理することは、コンピュートノードに関する
問題を処理するよりも簡単です。
ストレージノードの再起動
ストレージノードを再起動する必要がある場合、単に再起動します。そ
のノードに配置されているデータへのリクエストは、そのサーバーが再
起動している間、別のコピーにリダイレクトされます。
ストレージノードのシャットダウン
ストレージノードを少し長い間 ( 1 日以上) シャットダウンする必要が
あれば、ノードをストレージリングから削除することを検討します。例:
#
#
#
#
#
#
swift-ring-builder
swift-ring-builder
swift-ring-builder
swift-ring-builder
swift-ring-builder
swift-ring-builder
account.builder remove <ip address of storage node>
container.builder remove <ip address of storage node>
object.builder remove <ip address of storage node>
account.builder rebalance
container.builder rebalance
object.builder rebalance
次に、ring ファイルを他のノードに再配布します。
#
>
>
>
for i in s01.example.com s02.example.com s03.example.com
do
scp *.ring.gz $i:/etc/swift
done
これらの操作はストレージノードをストレージクラスターから効率的に
外せます。
ノードがクラスターに参加できるようになったら、ただリングに再度追
加するだけです。swift-ring-builder を使用して swift クラスターに
ノードを追加するための構文は、元々クラスターを作成したときに使用
した元々のオプションに強く依存します。作成時に使用したコマンドを
もう一度見てください。
180
OpenStack 運用ガイド
February 1, 2016
Swift ディスクの交換
Object Storage ノードのハードディスクが故障した場合、その交換は比
較的簡単です。Object Storage 環境が正しく設定され、故障したディス
クに保存されているデータが Object Storage 環境内の他のディスクに
も複製されていることを前提にしています。
この例では、/dev/sdb が故障したと仮定します。
まず、ディスクをアンマウントします。
# umount /dev/sdb
次に、ディスクを物理的にサーバーから取り外し、正常なディスクと入
れ替えます。
オペレーティングシステムが新しいディスクを認識していることを確認
します。
# dmesg | tail
/dev/sdb に関するメッセージを確認したほうがいいです。
Swift ディスクではパーティションを使用しないことが推奨されるの
で、単にディスク全体をフォーマットします。
# mkfs.xfs /dev/sdb
最後に、ディスクをマウントします。
# mount -a
Swift は新しいディスクを認識します。また、データが存在しないこと
を認識します。そうすると、他の既存の複製からディスクにデータを複
製しはじめます。
完全な故障の対処
データセンターの電源障害など、完全なシステム障害からリカバリーす
る一般的な方法は、各サービスに優先度を付け、順番に復旧していくこ
とです。表11.1「サービス復旧優先度一覧の例」 [181] に例を示しま
す。
表11.1 サービス復旧優先度一覧の例
優先度
サービス
1
内部ネットワーク接続性
181
OpenStack 運用ガイド
February 1, 2016
優先度
サービス
2
バックエンドのストレージサービス
3
ユーザーの仮想マシンに対するパブリック
ネットワーク接続性
4
nova-compute、nova-network、cinder ホスト
5
ユーザーの仮想マシン
10
メッセージキューとデータベースのサービス
15
Keystone サービス
20
cinder-scheduler
21
イメージカタログとイメージ配信のサービス
22
nova-scheduler サービス
98
cinder-api
99
nova-api サービス
100
ダッシュボードサービス
この例にある優先度一覧を使用すると、きちんと安定した状態になる前
であっても、できる限り早くユーザーに影響するサービスを復旧させる
ことができます。もちろん、1 行の項目として一覧化されていますが、
各ステップは多大な作業が必要です。たとえば、データベースを開始し
た後、その完全性を確認すべきです。また、nova サービスを開始した
後、ハイパーバイザーがデータベースに一致しているかを確認し、不一
致があれば修正すべきです。
構成管理
OpenStack クラウドをメンテナンスするには、複数の物理サーバーを管
理することが必要です。そして、この数は日々増えていきます。ノード
を手動で管理することはエラーを起こしやすいので、構成管理ツールを
使用することを強く推奨します。これらのツールはすべてのノードが適
切に設定されていることを保証するプロセスを自動化します。また、こ
れらを使うことで、(パッケージや設定オプションといった) 構成情報の
バージョン管理されたリポジトリでの管理が行いやすくなります。
ヒント
いくつかの構成管理ツールがあります。このガイドでは特定
のものを推奨しません。OpenStack コミュニティで人気が
あるものは Puppet と Chef の 2 つで、OpenStack 用の設
定集がそれぞれ OpenStack Puppet modules と OpenStack
Chef recipes にあります。比較的新しい他のツールとして
は、Juju、Ansible や Salt があります。もう少し成熟した
ツールとしては CFEngine や Bcfg2 があります。
182
OpenStack 運用ガイド
February 1, 2016
ハードウェアの取り扱い
初期導入時と同じように、本番環境に追加する前に、すべてのハード
ウェアについて適切な通電テストを行うべきでしょう。ハードウェア
を限界まで使用するソフトウェアを実行します。RAM、CPU、ディスク、
ネットワークを限界まで使用します。多くのオプションが利用可能で
あり、通常はベンチマークソフトウェアとの役割も果たします。そのた
め、システムのパフォーマンスに関する良いアイディアを得ることもで
きます。
コンピュートノードの追加
コンピューティングリソースのキャパシティ限界に達した、または達し
そうとわかれば、さらなるコンピュートノードの追加を計画すべきで
す。さらなるコンピュートノードを追加することは簡単です。ノードを
追加する手順は、最初にコンピュートノードをクラウドに導入したとき
と同じです。自動配備システムを使ってベアメタルサーバーにオペレー
ティングシステムのインストールと起動を行い、次に構成管理システム
により OpenStack Compute サービスのインストールと設定を行います。
他のコンピュートノードと同じ方法で Compute サービスのインストール
と設定が終わると、自動的にクラウドに接続されます。クラウドコント
ローラーが新しいノードを検知し、そこにインスタンスを起動するよう
スケジュールし始めます。
OpenStack ブロックストレージノードがコンピュートノードから分離い
る場合、同じキュー管理とポーリングのシステムが両方のサービスで使
用されるので、同じ手順が適用できます。
新しいコンピュートノードとブロックストレージノードには、同じハー
ドウェアを使用することを推奨します。最低限、ライブマイグレーショ
ンが失敗しないように、コンピュートノードでは CPU は同様のものにし
てください。
オブジェクトストレージノードの追加
新しいオブジェクトストレージノードの追加は、コンピュートノードや
ブロックストレージノードの追加とは異なります。サーバーの設定は、
これまで通り自動配備システムと構成管理システムを使って行えます。
完了した後、オブジェクトストレージノードのローカルディスクをオブ
ジェクトストレージリングに追加する必要があります。これを実行する
コマンドは、最初にディスクをリングに追加するのに使用したコマンド
と全く同じです。オブジェクトストレージプロキシサーバーにおいて、
このコマンドを、新しいオブジェクトストレージノードにあるすべての
183
OpenStack 運用ガイド
February 1, 2016
ディスクに対して、再実行するだけです。これが終わったら、リングの
再バランスを行い、更新されたリングファイルを他のストレージノード
にコピーします。
注記
新しいオブジェクトストレージノードのディスク数が元々の
ノードのディスク数と異なる場合には、新しいノードを追加
するコマンドが元々のコマンドと異なります。これらのパラ
メーターは環境により異なります。
コンポーネントの交換
クラウドインフラなどの大規模環境では、ハードウェアの故障はよくあ
ることです。作業内容を考慮し、可用性と時間の節約のバランスを取り
ます。たとえば、オブジェクトストレージクラスターは、十分な容量が
ある場合には、ある程度の期間は死んだディスクがあっても問題なく動
作します。また、(クラウド内の) コンピュートノードに空きがある場
合には、問題に対処する時間が取れるまで、ライブマイグレーションで
RAM が故障したホストから他のホストへインスタンスを移動させること
も考慮するとよいでしょう。
データベース
ほとんどすべての OpenStack コンポーネントは、永続的な情報を保存す
るために内部でデータベースを使用しています。このデータベースは通
常 MySQL です。通常の MySQL の管理方法がこれらのデータベースに適
用できます。OpenStack は特別な方法でデータベースを設定しているわ
けではありません。基本的な管理として、パフォーマンス調整、高可用
性、バックアップ、リカバリーおよび修理などがあります。さらなる情
報は標準の MySQL 管理ガイドを参照してください。
より迅速に情報を取得したり、データ不整合のエラーを修正したりする
ために、データベースでいくつかの小技を実行できます。たとえば、
インスタンスが終了していたが、データベースの状態が更新されていな
かった、という状況です。こうした小技がこのドキュメント全体を通し
て議論されています。
データベース接続性
コンポーネントの設定ファイルを確認して、それぞれの OpenStack コン
ポーネントが対応するデータベースにどのようにアクセスするかを把握
ください。sql_connection またはただの connection を探します。以下
184
OpenStack 運用ガイド
February 1, 2016
のコマンドは、grep を使用して、nova、glance、cinder、keystone の
SQL 接続文字列を表示します。
# grep -hE "connection ?=" /etc/nova/nova.conf /etc/glance/glance-*.conf /etc/cinder/cinder.conf /
etc/keystone/keystone.conf
sql_connection = mysql+pymysql://nova:nova@cloud.alberta.sandbox.cybera.ca/nova
sql_connection = mysql+pymysql://glance:password@cloud.example.com/glance
sql_connection = mysql+pymysql://glance:password@cloud.example.com/glance
sql_connection = mysql+pymysql://cinder:password@cloud.example.com/cinder
connection = mysql+pymysql://keystone_admin:password@cloud.example.com/keystone
connection 文字列は以下の形式をとります。
mysql+pymysql:// <username> : <password> @ <hostname> / <database name>
パフォーマンスと最適化
クラウドが大きくなるにつれて、MySQL がさらに使用されてきま
す。MySQL がボトルネックになってきたことが疑われる場合、MySQL
最適化の調査から始めるとよいでしょう。MySQL のマニュアルで
は、Optimization Overview というセクションがあり、一つのセクショ
ン全部をあててこの話題を扱っています。
HDWMY
これらは、毎時間、日、週、月および年に実行する To Do 項目の簡単な
一覧です。これらのタスクは必要なものでも、絶対的なものでもありま
せんが、役に立つものばかりです。
毎時
• 監視システムのアラートを確認し、それらに対処します。
• チケットキューの新しいチケットを確認します。
日次
• 故障または異常になっているインスタンスを確認し、理由を調査しま
す。
• セキュリティパッチを確認し、必要に応じて適用します。
週次
• クラウドの使用量を確認します:
• ユーザークォータ
185
OpenStack 運用ガイド
February 1, 2016
• ディスク領域
• イメージ使用量
• 大きなインスタンス
• ネットワーク使用量 (帯域および IP 使用量)
• アラート機能が動作していることを確認します。
月次
• この 1 か月における使用量および傾向を確認します。
• 削除すべきユーザーアカウントを確認します。
• 削除すべきオペレーターアカウントを確認します。
四半期ごと
• この四半期における使用量および傾向を確認します。
• 使用量と統計に関する四半期レポートを準備します。
• クラウドの追加の必要性を検討し、計画を立てます。
• OpenStack のメジャーアップグレードの内容を確認し、その計画を立
てます。
1 年に 2 回
• OpenStack をアップグレードします。
• OpenStack のアップグレード後に後始末を行います (未使用または新
しいサービスを把握していますか?)。
故障しているコンポーネントの特定
OpenStack は、異なるコンポーネント同士が互いに強く連携して動作し
ています。たとえば、イメージのアップロードでは、nova-api, glanceapi, glance-registry, keystone が連携する必要があります。 swiftproxy も関係する場合があります。その結果、時として問題が発生して
いる箇所を正確に特定することが難しくなります。これを支援すること
がこのセクションの目的です。
186
OpenStack 運用ガイド
February 1, 2016
最新ログの確認
最初に確認する場所は、実行しようとしているコマンドに関連するログ
ファイルです。たとえば、nova list が失敗していれば、nova ログファ
イルを tail 表示しながら、次のコマンドを再実行してください:
端末 1:
# tail -f /var/log/nova/nova-api.log
端末 2:
# nova list
何らかのエラーまたはトレースをログファイルで探します。詳細は 13章
ロギングと監視 [215] を参照してください。
エラーから問題が他のコンポーネントにあることが分かる場合には、
そのコンポーネントのログファイルに表示を切り替えます。nova が
glance にアクセスできなければ、glance-api ログを確認します:
端末 1:
# tail -f /var/log/glance/api.log
端末 2:
# nova list
問題の根本となる原因を見つけるまで、洗い出し、精査し、繰り返しま
す。
コマンドラインでのデーモンの実行
残念ながら、ときどきエラーがログファイルに表れない場合がありま
す。このような場合、作戦を変更し、違うコマンドを使用します。おそ
らくコマンドラインにおいて直接サービスを実行することです。たとえ
ば、glance-api サービスが起動しなかったり、実行状態にとどまらない
場合は、コマンドラインからデーモンを起動してみます:
# sudo -u glance -H glance-api
これにより、エラーと問題の原因が表示されるかもしれません。
注記
sudo を用いてデーモンを実行するとき、-H フラグが必要
です。いくつかのデーモンは、ユーザーのホームディレクト
187
OpenStack 運用ガイド
February 1, 2016
リーからの相対パスのファイルに書き込みを行うため、-H が
ないと、この書き込みが失敗してしまいます。
複雑な例
ある朝、あるノードでインスタンスの実行がすべて失敗するように
なりました。ログファイルがすこしあいまいでした。特定のインス
タンスが起動できなかったことを示していました。これは最終的に
偽の手掛かりであることがわかりました。単にそのインスタンスが
アルファベット順で最初のインスタンスだったので、nova-compute
が最初に操作したのがそのインスタンスだったというだけでした。
さらなるトラブルシューティングにより、libvirt がまったく
動作していないことがわかりました。これは大きな手がかりで
す。libvirt が動作していないと、KVM によるインスタンスの仮想
化ができません。libvirt を開始させようとしても、libvirt は何
も表示せずすぐに停止しました。libvirt のログでは理由がわかり
ませんでした。
次に、libvirtd デーモンをコマンドラインにおいて実行しまし
た。最終的に次のような役に立つエラーメッセージが得られまし
た。d-bus に接続できませんでした。このため、滑稽に聞こえる
かもしれませんが、libvirt 、その結果として nova-compute も
D-Bus に依存していて、どういう訳か D-Bus がクラッシュしまし
た。単に D-Bus を開始するだけで、一連のプログラムがうまく動
くようになり、すぐに全部が元に戻り動作状態になりました。
188
OpenStack 運用ガイド
February 1, 2016
アンインストール
我々は常に、自動配備システムを使って、まっさらの状態からシステム
を再インストールすることを進めていますが、時として OpenStack を地
道にシステムから削除しなければならない場合もあるでしょう。その場
合には以下の手順となります。
• すべてのパッケージを削除します。
• 残っているファイルを削除します。
• データベースを削除します。
これらの手順はお使いのディストリビューションにより異なります
が、一般には aptitude purge ~c $package のようなパッケージマネー
ジャーの「purge（完全削除）」コマンドを探すとよいでしょう。その後
で、このガイドの中に出てきたディレクトリにある不要なファイルを探
します。データベースを適切にアンインストールする方法については、
使用しているソフトウェアの適切なマニュアルを参照して下さい。
189
OpenStack 運用ガイド
February 1, 2016
第12章 ネットワークのトラブル
シューティング
「ip a」を使ってインタフェース状態をチェックする ............
クラウド上の nova-network 通信の仮想化 .....................
クラウド上の OpenStack Networking サービス通信の仮想化 ......
経路上の障害を見つける .....................................
tcpdump ....................................................
iptables ...................................................
nova-network 用データベースにあるネットワーク設定 ...........
nova-network の DHCP 問題の デバッグ .......................
DNS の問題をデバッグする ...................................
Open vSwitch のトラブルシューティング ......................
ネットワーク名前空間への対応 ...............................
概要 .......................................................
191
192
193
201
201
203
204
205
209
210
212
213
ネットワークのトラブルシューティングは、残念ながら、非常に難
しくややこしい作業です。ネットワークの問題は、クラウドのいく
つかの場所で問題となりえます。論理的な問題解決手順を用いること
は、混乱の緩和や迅速な切り分けに役立つでしょう。この章は、novanetwork、Linux ブリッジや Open vSwitch を用いた OpenStack
Networking (neutron) に関する何らかの問題を識別するために必要とな
る情報を提供することを目的とします。
「ip a」を使ってインタフェース状態を
チェックする
コンピュートノードおよび nova-network を実行しているノードにお
いて、以下のコマンドを使用して、IP、VLAN、起動状態などのインター
フェースに関する情報を参照します。
# ip a
もしあなたがネットワークの問題に直面した場合、まず最初にするとよ
いのは、インターフェイスがUPになっているかを確認することです。例
えば、
$ ip a | grep state
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP
qlen 1000
191
OpenStack 運用ガイド
February 1, 2016
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master br100 state UP qlen 1000
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state
DOWN
5: br100: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
virbr0 の状態は無視することができます。なぜならそれはlibvirtが作
成するデフォルトのブリッジで、OpenStackからは使われないからです。
クラウド上の nova-network 通信の仮想
化
インスタンスにログインして、外部ホスト (例えば Google) に
ping する場合、ping パケットは図12.1「ping パケットの通信ルー
ト」 [192]に示されたルートを通ります。
図12.1 ping パケットの通信ルート
1. インスタンスはパケットを生成し、インスタンス内の仮想NIC、例えば
eth0にそれを渡します。
2. そのパケットはコンピュートホストの仮想NIC、例えば vnet1に
転送されます。vnet NICの構成は、/etc/libvirt/qemu/instancexxxxxxxx.xml を見ることで把握できます。
3. パケットはvnet NICからコンピュートノードのブリッジ、例え
ばbr100に転送されます。
もしFlatDHCPManagerを使っているのであれば、ブリッジはコンピュー
トノード上に一つです。VlanManagerであれば、VLANごとにブリッジが
存在します。
192
OpenStack 運用ガイド
February 1, 2016
下記コマンドを実行することで、パケットがどのブリッジを使うか確
認できます。
$ brctl show
vnet NICを探してください。ま
た、nova.confのflat_interface_bridgeオプションも参考になりま
す。
4. パケットはコンピュートノードの物理NICに送られます。このNIC
はbrctlコマンドの出力から、もしくはnova.confのflat_interfaceオ
プションから確認できます。
5. パケットはこのNICに送られた後、コンピュートノードのデフォルト
ゲートウェイに転送されます。パケットはこの時点で、おそらくあ
なたの管理範囲外でしょう。図には外部ゲートウェイを描いています
が、マルチホストのデフォルト構成では、コンピュートホストがゲー
トウェイです。
ping 応答のパスを確認するために、方向を反転させます。この経路説明
によって、あなたはパケットが4つの異なるNICの間を行き来しているこ
とがわかったでしょう。これらのどのNICに問題が発生しても、ネット
ワークの問題となるでしょう。
クラウド上の OpenStack Networking
サービス通信の仮想化
OpenStack Networking は、バックエンドをプラグインできるの
で、nova-network よりも自由度が大きいです。SDN ハードウェアを制
御するオープンソースやベンダー製品のプラグイン、ホストで動作する
Open vSwitch や Linux Bridge などの Linux ネイティブの機能を使用
するプラグインを用いて設定できます。
OpenStack Cloud Administrator Guide のネットワークの章に、さまざ
まな種類のネットワークのシナリオや接続パスがあります。このセク
ションの目的は、どのようにお使いの環境に一緒に関わっているかによ
らず、さまざまなコンポーネントをトラブルシューティングするための
ツールを提供します。
この例のために、Open vSwitch (OVS) バックエンドを使用します。他
のバックエンドプラグインは、まったく別のフロー経路になるでしょ
う。OVS は、最も一般的に配備されているネットワークドライバーで
193
OpenStack 運用ガイド
February 1, 2016
す。2015 年 10 月の OpenStack User Survey によると、2 番目の
Linux Bridge ドライバーよりも、41% 以上も多くのサイトで使用されて
います。図12.2「Neutron ネットワーク経路」 [195] を参照しながら、
各手順を順番に説明していきます。
1. インスタンスはパケットを生成し、インスタンス内の仮想NIC、例えば
eth0にそれを渡します。
2. そのパケットはコンピュートホストの Test Access Point (TAP)、例
えば tap690466bc-92 に転送されます。TAP の構成は、/etc/libvirt/
qemu/instance-xxxxxxxx.xml を見ることで把握できます。
TAP デバイス名は、ポート ID の先頭 11 文字 (10 桁の16進数とハイ
フン) を使用して作られます。そのため、デバイス名を見つける別の
手段として、neutron コマンドを使用できます。これは、パイプ区切
りの一覧を返し、最初の項目がポート ID です。例えば、次のように
IP アドレス 10.0.0.10 に関連づけられているポート ID を取得しま
す。
# neutron port-list | grep 10.0.0.10 | cut -d \| -f 2
ff387e54-9e54-442b-94a3-aa4481764f1d
この出力から最初の 11 文字をとり、デバイス名 tapff387e54-9e を
作ることができます。
194
OpenStack 運用ガイド
February 1, 2016
図12.2 Neutron ネットワーク経路
195
OpenStack 運用ガイド
February 1, 2016
3. TAP デバイスは統合ブリッジ br-int に接続されます。このブリッジ
は、すべてのインスタンスの TAP デバイスや他のシステム上のブリッ
ジを接続します。この例では、int-br-eth1 と patch-tun がありま
す。int-br-eth1 は、ブリッジ br-eth1 に接続している veth ペアの
片側です。これは、物理イーサネットデバイス eth1 経由でトランク
される VLAN ネットワークを処理します。patch-tun は、GRE ネット
ワークの br-tun ブリッジに接続している Open vSwitch 内部ポート
です。
TAP デバイスと veth デバイスは、通常の Linux ネットワークデバ
イスです。ip や tcpdump などの通常のツールを用いて調査できるで
しょう。patch-tun のような Open vSwitch 内部デバイスは、Open
vSwitch 環境の中だけで参照できます。tcpdump -i patch-tun を実行
しようとした場合、デバイスが存在しないというエラーが発生するで
しょう。
内部インターフェースにおいてパケットを監視することもできます
が、少しネットワークを操作する必要があります。まず、通常の
Linux ツールが参照できるダミーネットワークデバイスを作成する必
要があります。次に、監視したい内部インターフェースを含むブリッ
ジにそれを追加する必要があります。最後に、内部ポートのすべての
通信をこのダミーポートにミラーするよう Open vSwitch に通知する
必要があります。これをすべて終えた後、ダミーインターフェースで
tcpdump を実行して、内部ポートの通信を参照できます。
統合ブリッジ br-int の内部インターフェース patch-tun か
らのパケットをキャプチャーする方法。
1.
ダミーインターフェース snooper0 を作成して起動します。
# ip link add name snooper0 type dummy
# ip link set dev snooper0 up
2.
snooper0 デバイスを br-int ブリッジに追加します。
# ovs-vsctl add-port br-int snooper0
3.
patch-tun のミラーを snooper0 に作成します (ミラーポートの
UUID を返します)。
# ovs-vsctl -- set Bridge br-int mirrors=@m -- --id=@snooper0 \
get Port snooper0 -- --id=@patch-tun get Port patch-tun \
-- --id=@m create Mirror name=mymirror select-dst-port=@patch-tun \
select-src-port=@patch-tun output-port=@snooper0 select_all=1
196
OpenStack 運用ガイド
February 1, 2016
4.
これでうまくいきます。tcpdump -i snooper0 を実行し
て、patch-tun の通信を参照できます。
5.
br-int にあるすべてのミラーを解除して、ダミーインターフェー
スを削除することにより、クリーンアップします。
# ovs-vsctl clear Bridge br-int mirrors
# ovs-vsctl del-port br-int snooper0
# ip link delete dev snooper0
内部ブリッジにおいて、ネットワークサービスがどのように定義され
ているかによらず、ネットワークは内部 VLAN を使用して区別され
ます。これにより、同じホストにあるインスタンスが、仮想、物理、
ネットワークを転送することなく直接通信できるようになります。こ
れらの内部 VLAN ID は、ノードにおいて作成された順番に基づき、
ノード間で異なる可能性があります。これらの ID は、ネットワーク
定義および物理結線において使用されるセグメント ID にまったく関
連しません。
VLAN タグは、ネットワーク設定において定義された外部タグといくつ
かの場所にある内部タグの間で変換されます。br-int において、intbr-eth1 からの受信パケットは、外部タグから内部タグへと変換され
ます。他の変換が他のブリッジにおいても発生します。これらのセク
ションで議論されます。
4. 次の手順は、仮想ネットワークが 802.1q VLAN タグや GRE を使用す
るよう設定しているかどうかに依存します。
a. VLAN ベースのネットワークは、仮想インターフェース int-breth1 経由で統合ブリッジを抜けて、仮想イーサネットペア phybr-eth1 の他のメンバーにあるブリッジ br-eth1 に届きます。こ
のインターフェースのパケットは、内部 VLAN タグとともに届き、
上で説明したプロセスの逆順において外部タグに変換されます。
# ovs-ofctl dump-flows br-eth1|grep 2113
cookie=0x0, duration=184168.225s, table=0, n_packets=0, n_bytes=0,
idle_age=65534, hard_age=65534, priority=4,in_port=1,dl_vlan=7
actions=mod_vlan_vid:2113,NORMAL
パケットは、いま外部 VLAN タグを付けられ、eth1 経由で物理
ネットワークに出ていきます。このインターフェースが接続されて
いる L2 スイッチは、使用される VLAN ID を持つ通信を許可する
よう設定する必要があります。このパケットの次のホップも、同じ
L2 ネットワーク上になければいけません。
197
OpenStack 運用ガイド
February 1, 2016
b. GRE ベースのネットワークは、patch-tun を用いて、patch-int イ
ンターフェースの br-tun トンネルブリッジに渡されます。このブ
リッジは、各 GRE トンネルの 1 つのポートにも含まれます。つま
り、ネットワーク上の各コンピュートノードとネットワークノード
に対して 1 つです。ポートの名前は、gre-1 から順番に増えてい
きます。
gre-<n> インターフェースとトンネルエンドポイントを一致させる
ことは、おそらく Open vSwitch の状態を見ることになります。
# ovs-vsctl show |grep -A 3 -e Port\ \"grePort "gre-1"
Interface "gre-1"
type: gre
options: {in_key=flow, local_ip="10.10.128.21",
out_key=flow, remote_ip="10.10.128.16"}
この場合、gre-1 が IP 10.10.128.21 からリモートの IP
10.10.128.16 へのトンネルです。これは、このノードのローカル
インターフェースと一致します。
これらのトンネルは、ホストにおいて通常のルーティングテーブ
ルを使用して、できあがった GRE パケットを中継します。そのた
め、VLAN カプセル化と異なり、GRE エンドポイントがすべて同じ
L2 ネットワークにあるという要件は必要ありません。
br-tun にあるすべてのインターフェースは、Open vSwitch 内部
のものです。それらの通信を監視する場合、br-int にある patchtun 向けに上で説明したようなミラーポートをセットアップする必
要があります。
このブリッジで GRE トンネルと内部 VLAN の相互変換が行われま
す。
ovs-ofctl コマンドを使用することにより、GRE トンネル向
けに使用されている内部 VLAN タグを検索します。
1.
興味あるネットワークの provider:segmentation_id を探しま
す。これは、VLAN ベースのネットワークにおける VLAN ID に使
用されるものと同じ項目です。
# neutron net-show --fields provider:segmentation_id <network name>
+--------------------------+-------+
| Field
| Value |
+--------------------------+-------+
| provider:network_type
| gre
|
198
OpenStack 運用ガイド
February 1, 2016
| provider:segmentation_id | 3
|
+--------------------------+-------+
2.
この場合、ovs-ofctl dump-flows br-tun の出力で
0x<provider:segmentation_id>, 0x3 を grep します。
# ovs-ofctl dump-flows br-tun|grep 0x3
cookie=0x0, duration=380575.724s, table=2, n_packets=1800,
n_bytes=286104, priority=1,tun_id=0x3
actions=mod_vlan_vid:1,resubmit(,10)
cookie=0x0, duration=715.529s, table=20, n_packets=5,
n_bytes=830, hard_timeout=300,priority=1,
vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:a6:48:24
actions=load:0->NXM_OF_VLAN_TCI[],
load:0x3->NXM_NX_TUN_ID[],output:53
cookie=0x0, duration=193729.242s, table=21, n_packets=58761,
n_bytes=2618498, dl_vlan=1 actions=strip_vlan,set_tunnel:0x3,
output:4,output:58,output:56,output:11,output:12,output:47,
output:13,output:48,output:49,output:44,output:43,output:45,
output:46,output:30,output:31,output:29,output:28,output:26,
output:27,output:24,output:25,output:32,output:19,output:21,
output:59,output:60,output:57,output:6,output:5,output:20,
output:18,output:17,output:16,output:15,output:14,output:7,
output:9,output:8,output:53,output:10,output:3,output:2,
output:38,output:37,output:39,output:40,output:34,output:23,
output:36,output:35,output:22,output:42,output:41,output:54,
output:52,output:51,output:50,output:55,output:33
ここで、この GRE トンネルに関連する 3 つのフローを見つけら
れます。1 番目は、このトンネル ID を持つ受信パケットから
内部 VLAN ID 1 に変換したものです。2 番目は、MAC アドレス
fa:16:3e:a6:48:24 宛のパケットに対する送信ポート 53 番への
ユニキャストフローです。3 番目は、内部 VLAN 表現から、すべ
ての出力ポートにあふれ出した GRE トンネル ID に変換したもの
です。フローの説明の詳細は ovs-ofctl のマニュアルページを参
照してください。前の VLAN の例にあるように、数値ポート ID
は、ovs-ofctl show br-tun の出力を検査することにより、それ
らの名前を付けた表現に対応付けられます。
5. 次に、パケットはネットワークノードで受信されます。L3 エージェン
トや DHCP エージェントへのすべての通信は、それらのネットワーク
名前空間の中のみで参照できます。それらの名前空間の外部にあるす
べてのインターフェースを監視することにより、ネットワーク通信を
転送している場合でも、ARP のようなブロードキャストパケットのみ
が表示されます。しかし、ルーターや DHCP アドレスへのユニキャス
ト通信は表示されません。これらの名前空間の中でコマンドを実行す
る方法の詳細は、Dealing with Network Namespacesを参照してくださ
い。
199
OpenStack 運用ガイド
February 1, 2016
これとは別に、外部ルーターが同じ VLAN にあれば、ここの示されて
いる L3 エージェントの代わりに外部ルーターを使用するよう、VLAN
ベースのネットワークを設定できます。
a. VLAN ベースのネットワークは、この例にある物理ネットワークイ
ンターフェース eth1 においてタグ付きパケットとして受信されま
す。コンピュートノードでは、このインターフェースが br-eth1
ブリッジのメンバーです。
b. GRE ベースのネットワークは、トンネルブリッジ br-tun に転送
されます。これは、コンピュートノードにおいて GRE インター
フェースのように動作します。
6. 次に、何かしらの入力パケットは統合ブリッジ経由で送信されます。
繰り返しますが、コンピュートノードと同じようなものです。
7. そして、パケットが L3 エージェントに到達します。これは実際に
は、ルーターの名前空間の中にある別の TAP デバイスです。ルーター
名前空間は、qrouter-<router-uuid> という形式の名前です。名前空
間の中で ip a を実行することにより、TAP デバイスの名前を表示し
ます。この例では qr-e6256f7d-31 です。
# ip netns exec qrouter-e521f9d0-a1bd-4ff4-bc81-78a60dd88fe5 ip a|grep
state
10: qr-e6256f7d-31: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UNKNOWN
11: qg-35916e1f-36: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
qdisc pfifo_fast state UNKNOWN qlen 500
28: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
8. l3-agent のルーターの名前空間にある qg-<n> インターフェースは、
外部ブリッジ br-ex にある eth2 デバイス経由で次のホップにパケッ
トを送信します。このブリッジは、br-eth1 と同じように作られ、同
じ方法で検査できるでしょう。
9. この外部ブリッジも物理ネットワークインターフェースに含まれま
す。この例では eth2 です。これは、最終的に外部ルーターや送信先
に向けた外部ネットワークのパケットを受け取ります。
10.OpenStack ネットワークで動作している DHCP エージェントは、l3agent と同じような名前空間で動作します。DHCP 名前空間は、qdhcp<uuid> という名前を持ち、統合ブリッジに TAP デバイスを持ちま
す。DHCP の問題のデバッグは、通常この名前空間の中での動作に関連
します。
200
OpenStack 運用ガイド
February 1, 2016
経路上の障害を見つける
ネットワーク経路のどこに障害があるかを素早く見つけるには、pingを
使います。まずあなたがインスタンス上で、google.comのような外部ホ
ストにpingできるのであれば、ネットワークの問題はないでしょう。
もしそれができないのであれば、インスタンスがホストされているコン
ピュートノードのIPアドレスへpingを試行してください。もしそのIPに
pingできるのであれば、そのコンピュートノードと、ゲートウェイ間の
どこかに問題があります。
もしコンピュートノードのIPアドレスにpingできないのであれば、問題
はインスタンスとコンピュートノード間にあります。これはコンピュー
トノードの物理NICとインスタンス vnet NIC間のブリッジ接続を含みま
す。
最後のテストは、2 つ目のインスタンスを起動して、2 つのインスタン
スがお互いに ping できることを確認することです。もしできる場合、
問題はコンピュートノードのファイアウォールに関連するものでしょ
う。
tcpdump
ネットワーク問題の解決を徹底的に行う方法のひとつは、tcpdumpで
す。tcpdumpを使い、ネットワーク経路上の数点、問題のありそうなと
ころから情報を収集することをおすすめします。もしGUIが好みであれ
ば、Wiresharkを試してみてはいかがでしょう。
例えば、以下のコマンドを実行します。
tcpdump -i any -n -v \ 'icmp[icmptype] = icmp-echoreply or icmp[icmptype] =
icmp-echo'
このコマンドは以下の場所で実行します。
1. クラウド外部のサーバー
2. コンピュートノード
3. コンピュートノード内のインスタンス
例では、この環境には以下のIPアドレスが存在します
Instance
10.0.2.24
201
OpenStack 運用ガイド
February 1, 2016
203.0.113.30
Compute Node
10.0.0.42
203.0.113.34
External Server
1.2.3.4
次に、新しいシェルを開いて tcpdump の動いている外部ホストへpingを
行います。もし外部サーバーとのネットワーク経路に問題がなければ、
以下のように表示されます。
外部サーバー上
12:51:42.020227 IP (tos 0x0, ttl
proto ICMP (1), length 84)
203.0.113.30 > 1.2.3.4: ICMP
12:51:42.020255 IP (tos 0x0, ttl
proto ICMP (1), length 84)
1.2.3.4 > 203.0.113.30: ICMP
length 64
61, id 0, offset 0, flags [DF],
echo request, id 24895, seq 1, length 64
64, id 8137, offset 0, flags [none],
echo reply, id 24895, seq 1,
コンピュートノード上
12:51:42.019519 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto ICMP (1), length 84)
10.0.2.24 > 1.2.3.4: ICMP echo request, id 24895, seq 1, length 64
12:51:42.019519 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto ICMP (1), length 84)
10.0.2.24 > 1.2.3.4: ICMP echo request, id 24895, seq 1, length 64
12:51:42.019545 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF],
proto ICMP (1), length 84)
203.0.113.30 > 1.2.3.4: ICMP echo request, id 24895, seq 1, length 64
12:51:42.019780 IP (tos 0x0, ttl 62, id 8137, offset 0, flags [none],
proto ICMP (1), length 84)
1.2.3.4 > 203.0.113.30: ICMP echo reply, id 24895, seq 1, length 64
12:51:42.019801 IP (tos 0x0, ttl 61, id 8137, offset 0, flags [none],
proto ICMP (1), length 84)
1.2.3.4 > 10.0.2.24: ICMP echo reply, id 24895, seq 1, length 64
12:51:42.019807 IP (tos 0x0, ttl 61, id 8137, offset 0, flags [none],
proto ICMP (1), length 84)
1.2.3.4 > 10.0.2.24: ICMP echo reply, id 24895, seq 1, length 64
インスタンス上
12:51:42.020974 IP (tos 0x0, ttl 61, id 8137, offset 0, flags [none],
proto ICMP (1), length 84)
1.2.3.4 > 10.0.2.24: ICMP echo reply, id 24895, seq 1, length 64
外部サーバーはpingリクエストを受信し、pingリプライを送信していま
す。コンピュートノード上では、pingとpingリプライがそれぞれ成功し
ていることがわかります。また、見ての通り、コンピュートノード上で
202
OpenStack 運用ガイド
February 1, 2016
はパケットが重複していることもわかるでしょう。なぜならtcpdumpはブ
リッジと外向けインターフェイスの両方でパケットをキャプチャーする
からです。
iptables
nova-network か neutron に関わらず、OpenStack Compute は自動的に
iptables を管理します。コンピュートノードにあるインスタンスとの
パケット転送、Floating IP 通信の転送、セキュリティグループルール
の管理など。ルールの管理に加えて、(サポートされる場合) コメントが
ルールに挿入され、ルールの目的を理解しやすくします。
以下のコメントが、適切にルールセットに追加されます。
• 送信方向にソース NAT 実行。
• 一致しない通信のデフォルト破棄ルール。
• 仮想マシンインスタンスからセキュリティグループチェインへの直接
通信。
• 仮想マシン固有チェインへのジャンプ。
• 仮想マシンからセキュリティグループチェインへの直接受信。
• 定義済み IP/MAC ペアからの通信許可。
• IP/MAC 許可ルールにない通信の破棄。
• DHCP クライアント通信の許可。
• 仮想マシンによる DHCP スプーフィングの防止。
• 一致しない通信のフォールバックチェインへの送信。
• どの状態にも関連付けられていないパケットの破棄。
• 既知のセッションに関連付けられたパケットの RETURN チェインへの
転送。
• RA パケットを許可するための IPv6 ICMP 通信の許可。
iptablesの現在の構成を見るには、以下のコマンドを実行します。
# iptables-save
203
OpenStack 運用ガイド
February 1, 2016
注記
もしiptablesの構成を変更した場合、次のnovanetworkやneutron-serverの再起動時に前の状態に戻りま
す。iptablesの管理にはOpenStackを使ってください。
nova-network 用データベースにあるネッ
トワーク設定
nova-network を用いると、nova データベーステーブルは、いくつかの
ネットワーク情報を持つテーブルがあります。
fixed_ips
novaに登録されたサブネットで利用可能なIPアドレ
ス。このテーブルは fixed_ips.instance_uuid 列で
instances テーブルと関連付けられます。
floating_ips
Compute に登録された各 Floating IP アドレス。
このテーブルは floating_ips.fixed_ip_id 列で
fixed_ips テーブルと関連付けられます。
instances
ネットワーク特有のテーブルではありません
が、fixed_ipとfloating_ipを使っているインスタンス
の情報を管理します。
これらのテーブルから、Floating IPが技術的には直接インスタンスにひ
も付けられておらず、固定IP経由であることがわかります。
Floating IP の手動割り当て解除
しばしば、フローティングIPを正しく開放しないままインスタンスが終
了されることがあります。するとデータベースは不整合状態となるた
め、通常のツールではうまく開放できません。解決するには、手動で
データベースを更新する必要があります。
まず、インスタンスのUUIDを確認します。
mysql> select uuid from instances where hostname = 'hostname';
次に、そのUUIDから固定IPのエントリーを探します。
mysql> select * from fixed_ips where instance_uuid = '<uuid>';
関連する Floating IP のエントリーが見つかります。
mysql> select * from floating_ips where fixed_ip_id = '<fixed_ip_id>';
204
OpenStack 運用ガイド
February 1, 2016
最後に、floating IPを開放します。
mysql> update floating_ips set fixed_ip_id = NULL, host = NULL where
fixed_ip_id = '<fixed_ip_id>';
また、ユーザプールからIPを開放することもできます。
mysql> update floating_ips set project_id = NULL where
fixed_ip_id = '<fixed_ip_id>';
nova-network の DHCP 問題の デバッグ
よくあるネットワークの問題に、インスタンスが起動しているにも関わ
らず、dnsmasqからのIPアドレス取得に失敗し、到達できないという現象
があります。dnsmasqはnova-networkサービスから起動されるDHCPサーバ
です。
もっともシンプルにこの問題を特定する方法は、インスタンス上のコン
ソール出力を確認することです。もしDHCPが正しく動いていなければ、
下記のようにコンソールログを参照してください。
$ nova console-log <instance name or uuid>
もしインスタンスがDHCPからのIP取得に失敗していれば、いくつかの
メッセージがコンソールで確認できるはずです。例えば、Cirrosイメー
ジでは、以下のような出力になります。
udhcpc (v1.17.2) started
Sending discover...
Sending discover...
Sending discover...
No lease, forking to background
starting DHCP forEthernet interface eth0 [ [1;32mOK[0;39m ]
cloud-setup: checking http://169.254.169.254/2009-04-04/meta-data/instance-id
wget: can't connect to remote host (169.254.169.254): Network is
unreachable
インスタンスが正しく起動した後、この手順でどこが問題かを切り分け
ることができます。
DHCPの問題はdnsmasqの不具合が原因となりがちです。まず、ログを確認
し、その後該当するプロジェクト(テナント)のdnsmasqプロセスを再起動
してください。VLANモードにおいては、dnsmasqプロセスはテナントごと
に存在します。すでに該当のdnsmasqプロセスを再起動しているのであれ
ば、もっともシンプルな解決法は、マシン上の全てのdnsmasqプロセスを
killし、nova-networkを再起動することです。最終手段として、rootで
以下を実行してください。
205
OpenStack 運用ガイド
February 1, 2016
# killall dnsmasq
# restart nova-network
注記
RHEL/CentOS/Fedora の場合は openstack-nova-network を使
用しますが、Ubuntu/Debian の場合は nova-network を使用
します。
nova-networkの再起動から数分後、新たなdnsmasqプロセスが動いている
ことが確認できるでしょう。
206
OpenStack 運用ガイド
February 1, 2016
# ps aux | grep dnsmasq
nobody 3735 0.0 0.0 27540 1044 ? S 15:40 0:00 /usr/sbin/dnsmasq --strictorder
--bind-interfaces --conf-file=
--domain=novalocal --pid-file=/var/lib/nova/networks/nova-br100.pid
--listen-address=192.168.100.1 --except-interface=lo
--dhcp-range=set:'novanetwork',192.168.100.2,static,120s
--dhcp-lease-max=256
--dhcp-hostsfile=/var/lib/nova/networks/nova-br100.conf
--dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro
root 3736 0.0 0.0 27512 444 ? S 15:40 0:00 /usr/sbin/dnsmasq --strict-order
--bind-interfaces --conf-file=
--domain=novalocal --pid-file=/var/lib/nova/networks/nova-br100.pid
--listen-address=192.168.100.1 --except-interface=lo
--dhcp-range=set:'novanetwork',192.168.100.2,static,120s
--dhcp-lease-max=256
--dhcp-hostsfile=/var/lib/nova/networks/nova-br100.conf
--dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro
もしまだインスタンスがIPアドレスを取得できない場合、次はdnsmasqが
インスタンスからのDHCPリクエストを見えているか確認します。dnsmasq
プロセスが動いているマシンで、/var/log/syslogを参照し、dnsmasq
の出力を確認します。なお、マルチホストモードで動作している場合
は、dnsmasqプロセスはコンピュートノードで動作します。もしdnsmasq
がリクエストを正しく受け取り、処理していれば、以下のような出力に
なります。
Feb 27 22:01:36 mynode dnsmasq-dhcp[2438]: DHCPDISCOVER(br100)
fa:16:3e:56:0b:6f
Feb 27 22:01:36 mynode dnsmasq-dhcp[2438]: DHCPOFFER(br100) 192.168.100.3
fa:16:3e:56:0b:6f
Feb 27 22:01:36 mynode dnsmasq-dhcp[2438]: DHCPREQUEST(br100) 192.168.100.3
fa:16:3e:56:0b:6f
Feb 27 22:01:36 mynode dnsmasq-dhcp[2438]: DHCPACK(br100) 192.168.100.3
fa:16:3e:56:0b:6f test
もしDHCPDISCOVERが見つからなければ、dnsmasqが動いているマシンがイ
ンスタンスからパケットを受け取れない何らかの問題があります。もし
上記の出力が全て確認でき、かついまだにIPアドレスを取得できないの
であれば、パケットはインスタンスからdnsmasq稼働マシンに到達してい
ますが、その復路に問題があります。
このようなメッセージも確認できるかもしれません。
Feb 27 22:01:36 mynode dnsmasq-dhcp[25435]: DHCPDISCOVER(br100)
fa:16:3e:78:44:84 no address available
207
OpenStack 運用ガイド
February 1, 2016
これはdnsmasqの、もしくはdnsmasqとnova-network両方の問題です。(例
えば上記では、OpenStack Compute データベース上に利用可能な固定IP
がなく、dnsmasqがIPアドレスを払い出せない問題が発生しています)
もしdnsmasqのログメッセージで疑わしいものがあれば、コマンドライン
にてdnsmasqが正しく動いているか確認してください。
$ ps aux | grep dnsmasq
出力は以下のようになります。
108 1695 0.0 0.0 25972 1000 ? S Feb26 0:00 /usr/sbin/dnsmasq
-u libvirt-dnsmasq
--strict-order --bind-interfaces
--pid-file=/var/run/libvirt/network/default.pid --conf-file=
--except-interface lo --listen-address 192.168.122.1
--dhcp-range 192.168.122.2,192.168.122.254
--dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases
--dhcp-lease-max=253 --dhcp-no-override
nobody 2438 0.0 0.0 27540 1096 ? S Feb26 0:00 /usr/sbin/dnsmasq --strictorder
--bind-interfaces --conf-file=
--domain=novalocal --pid-file=/var/lib/nova/networks/nova-br100.pid
--listen-address=192.168.100.1
--except-interface=lo
--dhcp-range=set:'novanetwork',192.168.100.2,static,120s
--dhcp-lease-max=256
--dhcp-hostsfile=/var/lib/nova/networks/nova-br100.conf
--dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro
root 2439 0.0 0.0 27512 472 ? S Feb26 0:00 /usr/sbin/dnsmasq --strict-order
--bind-interfaces --conf-file=
--domain=novalocal --pid-file=/var/lib/nova/networks/nova-br100.pid
--listen-address=192.168.100.1
--except-interface=lo
--dhcp-range=set:'novanetwork',192.168.100.2,static,120s
--dhcp-lease-max=256
--dhcp-hostsfile=/var/lib/nova/networks/nova-br100.conf
--dhcp-script=/usr/bin/nova-dhcpbridge --leasefile-ro
出力は 3 種類の dnsmasq プロセスを示しています。192.168.122.0 の
DHCP サブネット範囲を持つ dnsmasq プロセスが、libvirt に属してい
ますが、無視できます。他の 2 つのプロセスは実際に関連します。1 つ
は単純なもう一つの親プロセスです。dnsmasq プロセスの引数は、novanetwork に設定した詳細に対応するでしょう。
もし問題がdnsmasqと関係しないようであれば、tcpdumpを使ってパケッ
トロスがないか確認してください。
DHCPトラフィックはUDPを使います。そして、クライアントは68番ポート
からサーバーの67番ポートへパケットを送信します。新しいインスタン
208
OpenStack 運用ガイド
February 1, 2016
スを起動し、機械的にNICをリッスンしてください。トラフィックに現れ
ない通信を特定できるまで行います。tcpdumpでbr100上のポート67、68
をリッスンするには、こうします。
# tcpdump -i br100 -n port 67 or port 68
また、ip a や brctl show などのコマンドを使って、インターフェイス
が実際にUPしているか、あなたが考えたとおりに設定されているか、正
当性を検査をすべきです。
DNS の問題をデバッグする
あなたが SSH を使用してインスタンスにログインできるけれども、プロ
ンプトが表示されるまで長い時間(約1分)を要する場合、DNS に問題があ
るかもしれません。SSH サーバーが接続元 IP アドレスの DNS 逆引きす
ること、それがこの問題の原因です。もしあなたのインスタンスで DNS
が正しく引けない場合、SSH のログインプロセスが完了するには、DNS
の逆引きがタイムアウトするまで待たなければいけません。
DNS問題のデバッグをするとき、そのインスタンスのdnsmasqが動いてい
るホストが、名前解決できるかを確認することから始めます。もしホス
トができないのであれば、インスタンスも同様でしょう。
DNSが正しくホスト名をインスタンス内から解決できているか確認する簡
単な方法は、hostコマンドです。もしDNSが正しく動いていれば、以下
メッセージが確認できます。
$ host openstack.org
openstack.org has address 174.143.194.225
openstack.org mail is handled by 10 mx1.emailsrvr.com.
openstack.org mail is handled by 20 mx2.emailsrvr.com.
もしあなたがCirrosイメージを使っているのであれば、"host"プログラ
ムはインストールされていません。その場合はpingを使い、ホスト名が
解決できているか判断できます。もしDNSが動いていれば、ping結果の先
頭行はこうなるはずです。
$ ping openstack.org
PING openstack.org (174.143.194.225): 56 data bytes
もしインスタンスがホスト名の解決に失敗するのであれば、DNSに問題が
あります。例えば、
$ ping openstack.org
ping: bad address 'openstack.org'
OpenStackクラウドにおいて、dnsmasqプロセスはDHCPサーバに加えてDNS
サーバーの役割を担っています。dnsmasqの不具合は、インスタンスに
209
OpenStack 運用ガイド
February 1, 2016
おけるDNS関連問題の原因となりえます。前節で述べたように、dnsmasq
の不具合を解決するもっともシンプルな方法は、マシン上のすべての
dnsmasqプロセスをkillし、nova-networkを再起動することです。しかし
ながら、このコマンドは該当ノード上で動いているすべてのインスタン
ス、特に問題がないテナントにも影響します。最終手段として、rootで
以下を実行します。
# killall dnsmasq
# restart nova-network
dnsmasq再起動後に、DNSが動いているか確認します。
dnsmasqの再起動でも問題が解決しないときは、tcpdumpで問題がある場
所のパケットトレースを行う必要があるでしょう。DNSサーバーはUDP
ポート53番でリッスンします。あなたのコンピュートノードのブリッジ
(br100など)上でDNSリクエストをチェックしてください。コンピュート
ノード上にて、tcpdumpでリッスンを開始すると、
# tcpdump -i br100 -n -v udp port 53
tcpdump: listening on br100, link-type EN10MB (Ethernet), capture size 65535
bytes
インスタンスに SSH ログインして、ping openstack.org を試すと、以
下のようなメッセージが確認できるでしょう。
16:36:18.807518 IP (tos 0x0, ttl 64, id 56057, offset 0, flags [DF],
proto UDP (17), length 59)
192.168.100.4.54244 > 192.168.100.1.53: 2+ A? openstack.org. (31)
16:36:18.808285 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto UDP (17), length 75)
192.168.100.1.53 > 192.168.100.4.54244: 2 1/0/0 openstack.org. A
174.143.194.225 (47)
Open vSwitch のトラブルシューティング
前の OpenStack Networking の例で使用されていたように、Open
vSwitch は、オープンソースの Apache 2.0 license にてライセンスさ
れている、完全な機能を持つマルチレイヤー仮想スイッチです。ドキュ
メント全体はプロジェクトの Web サイトにあります。実際のところ、前
述の設定を用いた場合、最も一般的な問題は、必要となるブリッジ (brint、br-tun、br-ex) が存在し、それらに接続される適切なポートを持
つことを確認することです。
Open vSwitch ドライバーは、これを自動的に管理すべきです。また、
一般的に管理します。しかし、ovs-vsctl コマンドを用いて、これを手
動で実行する方法を知ることは有用です。このコマンドは、ここで使用
210
OpenStack 運用ガイド
February 1, 2016
している以上に、数多くのサブコマンドがあります。完全な一覧は、マ
ニュアルページを参照するか、ovs-vsctl --help を使用してください。
ovs-vsctl list-br を使用して、システムにあるブリッジを一覧表示し
ます。この例は、内部ブリッジと統合ブリッジを持つコンピュートノー
ドを表します。VLAN ネットワークが eth1 ネットワークインターフェー
ス経由でトランクされます。
# ovs-vsctl list-br
br-int
br-tun
eth1-br
物理インターフェースより内側に取り組むと、ポートとブリッジのチェ
インを確認できます。まず、物理インターフェース eth1 と仮想イン
ターフェース phy-eth1-br を含むブリッジ eth1-br です。
# ovs-vsctl list-ports eth1-br
eth1
phy-eth1-br
次に、内部ブリッジ br-int は int-eth1-br を持ちます。この inteth1-br は、phy-eth1-br とペアになり、前のブリッジ patch-tun で示
された物理ネットワークに接続されます。この patch-tun は、GRE トン
ネルブリッジを接続するために使用され、システムにおいて現在動作し
ているインスタンスに接続される TAP デバイスです。
# ovs-vsctl list-ports br-int
int-eth1-br
patch-tun
tap2d782834-d1
tap690466bc-92
tap8a864970-2d
トンネルブリッジ br-tun は、GRE 経由で接続するお互いの接続相手の
ために patch-int インターフェースと gre-<N> インターフェース、ク
ラスター内で各コンピュートノードとネットワークノードのためのもの
を含みます。
# ovs-vsctl list-ports br-tun
patch-int
gre-1
.
.
.
gre-<N>
211
OpenStack 運用ガイド
February 1, 2016
これらのリンクのどれかが存在しない、または誤っている場合、設定エ
ラーを暗示しています。ブリッジは ovs-vsctl add-br で追加できま
す。ポートは ovs-vsctl add-port でブリッジに追加できます。これら
を手動で実行することはデバッグに有用ですが、維持することを意図し
た手動の変更が設定ファイルの中に反映されなければいけません。
ネットワーク名前空間への対応
Linux のネットワーク名前空間は、ネットワークサービスが、重複する
IP アドレス範囲を持つ、複数の独立した L2 ネットワークをサポートす
るために使用する、カーネルの機能です。この機能のサポートが無効化
されている可能性がありますが、デフォルトで有効になっています。お
使いの環境で有効化されている場合、ネットワークノードが DHCP エー
ジェントと L3 エージェントを独立した名前空間で動作します。ネット
ワークインターフェース、それらのインターフェースにおける通信は、
デフォルトの名前空間で見えなくなります。
ip netns を実行して、名前空間を使用しているかどうかを確認します。
# ip netns
qdhcp-e521f9d0-a1bd-4ff4-bc81-78a60dd88fe5
qdhcp-a4d00c60-f005-400e-a24c-1bf8b8308f98
qdhcp-fe178706-9942-4600-9224-b2ae7c61db71
qdhcp-0a1d0a27-cffa-4de3-92c5-9d3fd3f2e74d
qrouter-8a4ce760-ab55-4f2f-8ec5-a2e858ce0d39
qrouter-<router_uuid> という名前の L3 エージェントのルーター名前
空間および DHCP エージェントの名前空間は、qdhcp-<net_uuid> という
名前です。この出力は、DHCP エージェントを実行している 4 つのネッ
トワークを持つネットワークノードを表しています。また、1 つは L3
エージェントルーターも実行しています。作業する必要のあるネット
ワークを理解することは重要です。既存のネットワークおよび UUID の
一覧は、管理クレデンシャルを持って neutron net-list を実行するこ
とにより得られます。
作業する必要のある名前空間を決めると、コマンドの前に ip netns
exec <namespace> を付けることにより、前に言及したデバッグツールを
すべて使用できます。例えば、上で返された最初の qdhcp 名前空間に存
在するネットワークインターフェースを参照する場合、このように実行
します。
# ip netns exec qdhcp-e521f9d0-a1bd-4ff4-bc81-78a60dd88fe5 ip a
10: tape6256f7d-31: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UNKNOWN
link/ether fa:16:3e:aa:f7:a1 brd ff:ff:ff:ff:ff:ff
212
OpenStack 運用ガイド
February 1, 2016
inet 10.0.1.100/24 brd 10.0.1.255 scope global tape6256f7d-31
inet 169.254.169.254/16 brd 169.254.255.255 scope global tape6256f7d-31
inet6 fe80::f816:3eff:feaa:f7a1/64 scope link
valid_lft forever preferred_lft forever
28: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
ここから、そのネットワークにある DHCP サーバーが tape6256f7d-31
デバイスを使用していて、IP アドレス 10.0.1.100 を持つことを確認し
ます。アドレス 169.254.169.254 を確認することにより、dhcp-agent
が metadata-proxy サービスを実行していることも確認できます。こ
の章の前の部分で言及したコマンドは、すべて同じ方法で実行できま
す。bash などのシェルを実行して、名前空間の中で対話式セッションを
持つこともできます。後者の場合、シェルを抜けることにより、最上位
のデフォルトの名前空間に戻ります。
概要
執筆者は、この情報を読者のために蒸留するために、パケットダンプを
見ることに多大な時間を費やしました。本章に概略をまとめた方法に
従って、より簡単な時間を過ごせると信じています。このツールと上の
手順を扱うことから離れて、ときどき別の人が支援すれば十分であるこ
とを忘れないでください。
213
OpenStack 運用ガイド
February 1, 2016
第13章 ロギングと監視
ログはどこにあるのか？ .....................................
ログの読み方 ...............................................
インスタンスリクエストの追跡 ...............................
カスタムログの追加 .........................................
RabbitMQ Web管理インターフェイス および rabbitmqctl .........
ログの集中管理 .............................................
監視 .......................................................
概要 .......................................................
215
215
217
218
219
219
221
229
OpenStackクラウドは、様々なサービスから構成されるため、多くのロ
グファイルが存在します。この章では、それぞれのログの場所と取り扱
い、そしてシステムのさらなる監視方法について説明します。
ログはどこにあるのか？
多くのサービスは、慣習に従い、ログファイルを /var/log ディレクト
リーのサブディレクトリーに書き込みます。表13.1「OpenStack のログ
の場所」 [215] に一覧化されています。
表13.1 OpenStack のログの場所
ノード種別
サービス
ログの場所
クラウドコントローラー
nova-*
/var/log/nova
クラウドコントローラー
glance-*
/var/log/glance
クラウドコントローラー
cinder-*
/var/log/cinder
クラウドコントローラー
keystone-*
/var/log/keystone
クラウドコントローラー
neutron-*
/var/log/neutron
クラウドコントローラー
horizon
/var/log/apache2/
全ノード
その他 (swift, dnsmasq)
/var/log/syslog
コンピュートノード
libvirt
/var/log/libvirt/
libvirtd.log
コンピュートノード
仮想マシンインスタンスのコ
ンソール (起動メッセージ):
/var/lib/nova/instances/
instance-<instance id>/
console.log
Block Storage ノード
cinder-volume
/var/log/cinder/cindervolume.log
ログの読み方
OpenStack サービスは標準のロギングレベルを利用してい
ます。重要度のレベルは次の通りです(重要度の低い順):
215
OpenStack 運用ガイド
February 1, 2016
DEBUG、INFO、AUDIT、WARNING、ERROR、CRTICAL、TRACE。特定のログレ
ベルより「重要」な場合のみメッセージはログに出力されます。ログレ
ベルDEBUGの場合、すべてのログが出力されます。TRACEの場合、ソフト
ウェアがスタックトレースを持つ場合にのみログに出力されます。INFO
の場合、情報のみのメッセージも含めて出力されます。.
DEBUG レベルのロギングを無効にするには、/etc/nova/nova.conf を以
下のように編集します。
debug=false
Keystoneは少し異なる動作をします。ロギングレベルを変更するた
めには、/etc/keystone/logging.confを編集し、 logger_root と
handler_file を修正する必要があります。
horizon のロギング設定は /etc/openstack_dashboard/
local_settings.py で行います。horizon は Django web アプリケー
ションですので、Django Logging framework conventions に従います。
エラーの原因を見つけるための典型的な最初のステップは、
CRTICAL、TRACE、ERRORなどのメッセージがログファイルの終わりで出力
されていないかを確認することです。
これは、トレース(Pythonのコールスタック)付きのCRITICALなログメッ
セージの例です。
2013-02-25 21:05:51 17409 CRITICAL cinder [-] Bad or unexpected response from
the storage volume backend API: volume group
cinder-volumes doesn't exist
2013-02-25 21:05:51 17409 TRACE cinder Traceback (most recent call last):
2013-02-25 21:05:51 17409 TRACE cinder File "/usr/bin/cinder-volume", line
48, in <module>
2013-02-25 21:05:51 17409 TRACE cinder service.wait()
2013-02-25 21:05:51 17409 TRACE cinder File "/usr/lib/python2.7/distpackages/cinder/service.py", line 422, in wait
2013-02-25 21:05:51 17409 TRACE cinder _launcher.wait()
2013-02-25 21:05:51 17409 TRACE cinder File "/usr/lib/python2.7/distpackages/cinder/service.py", line 127, in wait
2013-02-25 21:05:51 17409 TRACE cinder service.wait()
2013-02-25 21:05:51 17409 TRACE cinder File "/usr/lib/python2.7/distpackages/eventlet/greenthread.py", line 166, in wait
2013-02-25 21:05:51 17409 TRACE cinder return self._exit_event.wait()
2013-02-25 21:05:51 17409 TRACE cinder File "/usr/lib/python2.7/distpackages/eventlet/event.py", line 116, in wait
2013-02-25 21:05:51 17409 TRACE cinder return hubs.get_hub().switch()
2013-02-25 21:05:51 17409 TRACE cinder File "/usr/lib/python2.7/distpackages/eventlet/hubs/hub.py", line 177, in switch
2013-02-25 21:05:51 17409 TRACE cinder return self.greenlet.switch()
216
OpenStack 運用ガイド
February 1, 2016
2013-02-25 21:05:51 17409 TRACE cinder File "/usr/lib/python2.7/distpackages/eventlet/greenthread.py", line 192, in main
2013-02-25 21:05:51 17409 TRACE cinder result = function(*args, **kwargs)
2013-02-25 21:05:51 17409 TRACE cinder File "/usr/lib/python2.7/distpackages/cinder/service.py", line 88, in run_server
2013-02-25 21:05:51 17409 TRACE cinder server.start()
2013-02-25 21:05:51 17409 TRACE cinder File "/usr/lib/python2.7/distpackages/cinder/service.py", line 159, in start
2013-02-25 21:05:51 17409 TRACE cinder self.manager.init_host()
2013-02-25 21:05:51 17409 TRACE cinder File "/usr/lib/python2.7/distpackages/cinder/volume/manager.py", line 95,
in init_host
2013-02-25 21:05:51 17409 TRACE cinder self.driver.check_for_setup_error()
2013-02-25 21:05:51 17409 TRACE cinder File "/usr/lib/python2.7/distpackages/cinder/volume/driver.py", line 116,
in check_for_setup_error
2013-02-25 21:05:51 17409 TRACE cinder raise exception.
VolumeBackendAPIException(data=exception_message)
2013-02-25 21:05:51 17409 TRACE cinder VolumeBackendAPIException: Bad or
unexpected response from the storage volume
backend API: volume group cinder-volumes doesn't exist
2013-02-25 21:05:51 17409 TRACE cinder
この例では、ボリュームのバックエンドがストレージボリュームをセッ
トアップができなかったため、cinder-volumes が起動に失敗し、スタッ
クトレースを出力しています。おそらく、設定ファイルで指定された
LVM ボリュームが存在しないためと考えられます。
これはエラーログの例です。
2013-02-25 20:26:33 6619 ERROR nova.openstack.common.rpc.common [-] AMQP
server on localhost:5672 is unreachable:
[Errno 111] ECONNREFUSED. Trying again in 23 seconds.
このエラーでは、novaサービスがRabbitMQへの接続に失敗していまし
た。接続が拒否されたというエラーが出力されています。
インスタンスリクエストの追跡
インスタンスが正しく動作していない場合、インスタンスに関連したロ
グを調べる必要があります。これらのログは複数のnova-*サービスが出
力しており、クラウドコントローラーとコンピュートノードの両方に存
在します。
一般的な方法はインスタンスのUUIDをキーにして、各サービスのログを
追跡することです。
次のような例を考えてみましょう。
217
OpenStack 運用ガイド
February 1, 2016
$ nova list
+--------------------------------+--------+-------+--------------------------+
| ID
| Name
| Status | Networks
|
+--------------------------------+--------+-------+--------------------------+
| fafed8-4a46-413b-b113-f1959ffe | cirros | ACTIVE | novanetwork=192.168.100.
3|
+--------------------------------------+--------+-------+--------------------+
ここで、インスタンスのUUIDは faf7ded8-4a46-413b-b113f19590746ffeです。クラウドコントローラー上の /var/log/nova*.logファイルをこの文字列で検索すると、nova-api.logと novascheduler.logで見つかります。同様にコンピュートノードで検索し
た場合、nova-network.log と nova-compute.logで見つかります。も
し、ERRORやCRITICALのメッセージが存在しない場合、最後のログエント
リが、何が悪いかのヒントを示しているかもしれません。
カスタムログの追加
十分な情報が既存のログにない場合、独自のロギング宣言を nova-*
サービスに追加する必要があるかもしれません。
ソースファイルは /usr/lib/python2.7/dist-packages/nova にありま
す。
ログステートメントを追加するには、次の行をファイルの先頭に置きま
す。ほとんどのファイルでは、これらは既に存在します。
from nova.openstack.common import log as logging
LOG = logging.getLogger(__name__)
DEBUGログステートメントを追加するには次のようにします。
LOG.debug("This is a custom debugging statement")
以下に例を示しますが、全てのログメッセージはアンダースコアで始ま
り、括弧で括られていることに気づいたでしょうか?
LOG.debug(_("Logging statement appears here"))
このフォーマットは、ログメッセージを異なる言語に翻訳するために
gettext 国際化ライブラリーを利用しているためです。カスタムログに
は必要ありませんが、もし、OpenStackプロジェクトにログステートメ
ントを含むコードを提供する場合は、アンダースコアと括弧でログメッ
セージを囲わなければなりません。
218
OpenStack 運用ガイド
February 1, 2016
RabbitMQ Web管理インターフェイス およ
び rabbitmqctl
接続エラーは別として、RabbitMQ のログファイルは一般的に OpenStack
関連の問題をデバッグするために役立ちません。代わりに、RabbitMQ の
Web 管理インターフェースを使用することを推奨します。 Enable it on
your cloud controller:
# /usr/lib/rabbitmq/bin/rabbitmq-plugins enable rabbitmq_management
# service rabbitmq-server restart
RabbitMQ Web管理インターフェイスは、クラウドコントローラーから
http://localhost:55672 でアクセスできます。
注記
Ubuntu 12.04はRabiitMQのバージョン2.7.1を55672番ポート
を使うようにインストールします。RabbitMQバージョン3.0
以降では15672が利用されます。Ubuntuマシン上でどのバー
ジョンのRabbitMQが実行されているかは次のように確認でき
ます。
$ dpkg -s rabbitmq-server | grep "Version:"
Version: 2.7.1-0ubuntu4
RabbitMQ Web 管理インターフェイスを有効にするもう一つの方法と
しては、 rabbitmqctl コマンドを利用します。例えば rabbitmqctl
list_queues| grep cinder は、キューに残っているメッセージを表示し
ます。メッセージが存在する場合、CinderサービスがRabbitMQに正しく
接続できてない可能性があり、再起動が必要かもしれません。
RabbitMQで監視すべき項目としては、各キューでのアイテムの数と、
サーバーでの処理時間の統計情報があります。
ログの集中管理
クラウドは多くのサーバーから構成されるため、各サーバー上にあるイ
ベントログを繋ぎあわせて、ログをチェックしなければなりません。よ
い方法は全てのサーバーのログを一ヶ所にまとめ、同じ場所で確認でき
るようにすることです。
Ubuntuはrsyslog をデフォルトのロギングサービスとして利用しま
す。rsyslog はリモートにログを送信する機能を持っているので、何か
219
OpenStack 運用ガイド
February 1, 2016
を追加でインストールする必要はなく、設定ファイルを変更するだけで
す。リモート転送を実施する際は、盗聴を防ぐためにログが自身の管理
ネットワーク上を通る、もしくは暗号化VPNを利用することを考慮する必
要があります。
rsyslog クライアント設定
まず始めに、全てのOpenStackコンポーネントのログを標準ログに加えて
syslogに出力するように設定します。また、各コンポーネントが異なる
syslogファシリティになるように設定します。これによりログサーバー
上で、個々のコンポーネントのログを分離しやすくなります。
nova.conf:
use_syslog=True
syslog_log_facility=LOG_LOCAL0
glance-api.conf、glance-registry.conf:
use_syslog=True
syslog_log_facility=LOG_LOCAL1
cinder.conf:
use_syslog=True
syslog_log_facility=LOG_LOCAL2
keystone.conf:
use_syslog=True
syslog_log_facility=LOG_LOCAL3
デフォルトで Object Storage は syslog にログを出力します。
次に、/etc/rsyslog.d/client.conf を作成して、以下の行を書き込みま
す。
*.* @192.168.1.10
これは、rsyslogに全てのログを指定したIPアドレスに送るように命令し
ています。この例では、IPアドレスはクラウドコントローラーを指して
います。
rsyslog サーバー設定
集中ログサーバーとして使用するサーバーを決めます。ログ専用のサー
バーを利用するのが最も良いです。/etc/rsyslog.d/server.conf を次の
ように作成します。
220
OpenStack 運用ガイド
February 1, 2016
# Enable UDP
$ModLoad imudp
# Listen on 192.168.1.10 only
$UDPServerAddress 192.168.1.10
# Port 514
$UDPServerRun 514
# Create logging templates for nova
$template NovaFile,"/var/log/rsyslog/%HOSTNAME%/nova.log"
$template NovaAll,"/var/log/rsyslog/nova.log"
# Log everything else to syslog.log
$template DynFile,"/var/log/rsyslog/%HOSTNAME%/syslog.log"
*.* ?DynFile
# Log various openstack components to their own individual file
local0.* ?NovaFile
local0.* ?NovaAll
& ~
これはnovaサービスのみを扱っています。はじめに rsyslog を UDP 514
番ポートで動作するサーバーとして設定します。次に一連のログテンプ
レートを作成します。ログテンプレートは受け取ったログをどこに保管
するかを指定します。最後の例を用いると、c01.example.comから送られ
るnovaのログは次の場所に保管されます。
• /var/log/rsyslog/c01.example.com/nova.log
• /var/log/rsyslog/nova.log
c02.example.comから送られたログはこちらに保管されます。
• /var/log/rsyslog/c02.example.com/nova.log
• /var/log/rsyslog/nova.log
全てのノードからのnovaのログを含む集約されたログだけでなく、個々
のコンピュートノードのログも持つことになります。
監視
二つの監視のタイプがあります。問題の監視と、利用傾向の監視です。
前者は全てのサービスが動作していることを保証するものであり、後
者は時間に沿ったリソース利用状況を監視することで、潜在的なボトル
ネックの発見とアップグレードのための情報を得るものです。
221
OpenStack 運用ガイド
February 1, 2016
Nagios
Nagios は、オープンソースソフトウェアの監視サービスです。任
意のコマンドを実行して、サーバーやネットワークサービスの状態
を確認できます。また、任意のコマンドをリモートのサーバーで直
接実行できます。サーバーが受動的な監視形態で通知を送信するこ
ともできます。Nagios は 1999 年ごろにできました。より当たら
し監視サービスがありますが、Nagios は実績豊富なシステム管理
ツールです。
プロセス監視
基本的なアラーム監視は、単に要求されたプロセスが稼働しているかど
うかを確認することです。 例えば、nova-api サービスがクラウドコン
トローラーで稼働しているかどうかを確認します。
# ps aux | grep nova-api
nova 12786 0.0 0.0 37952 1312 ? Ss Feb11 0:00 su -s /bin/sh -c exec nova-api
--config-file=/etc/nova/nova.conf nova
nova 12787 0.0 0.1 135764 57400 ? S Feb11 0:01 /usr/bin/python
/usr/bin/nova-api --config-file=/etc/nova/nova.conf
nova 12792 0.0 0.0 96052 22856 ? S Feb11 0:01 /usr/bin/python
/usr/bin/nova-api --config-file=/etc/nova/nova.conf
nova 12793 0.0 0.3 290688 115516 ? S Feb11 1:23 /usr/bin/python
/usr/bin/nova-api --config-file=/etc/nova/nova.conf
nova 12794 0.0 0.2 248636 77068 ? S Feb11 0:04 /usr/bin/python
/usr/bin/nova-api --config-file=/etc/nova/nova.conf
root 24121 0.0 0.0 11688 912 pts/5 S+ 13:07 0:00 grep nova-api
NagiosとNRPEを使って、クリティカルなプロセスの自動化されたアラー
トを作成することが可能です。nova-compute プロセスがコンピュート
ノードで動作していることを保証するために、Nagiosサーバー上で次の
ようなアラートを作成します。
define service {
host_name c01.example.com
check_command check_nrpe_1arg!check_nova-compute
use generic-service
notification_period 24x7
contact_groups sysadmins
service_description nova-compute
}
そして、対象のコンピュートノードにおいて、次のようなNRPE設定を作
成します。
\command[check_nova-compute]=/usr/lib/nagios/plugins/check_procs -c 1: \
-a nova-compute
222
OpenStack 運用ガイド
February 1, 2016
Nagiosは常に 1 つ以上の nova-compute サービスが動作しているかを
チェックします。
リソースのアラート
リソースアラート機能は、1 つ以上のリソースが致命的に少なくなった
際に通知します。閾値監視がお使いの OpenStack 環境で有効化されてい
るべきですが、リソース使用状況の監視は、まったく OpenStack 固有の
ことではありません。あらゆる汎用のアラート機能が適切に動作するで
しょう。
監視項目に含む幾つかのリソースをあげます。
• ディスク使用量
• サーバー負荷
• メモリー使用量
• ネットワーク I/O
• 利用可能な vCPU 数
例として、コンピュートノード上のディスク容量をNagiosを使って監視
する場合、次のようなNagios設定を追加します。
define service {
host_name c01.example.com
check_command check_nrpe!check_all_disks!20% 10%
use generic-service
contact_groups sysadmins
service_description Disk
}
コンピュートノード上では、次のようなNRPE設定を追加します。
command[check_all_disks]=/usr/lib/nagios/plugins/check_disk -w $ARG1$ -c \
$ARG2$ -e
Naigosは、80%のディスク使用率でWARNING、90%でCRITICALを警告しま
す。
StackTach
StackTachはRackspaceによって作られたツールで、novaから送られた通
知を収集してレポートします。通知は本質的にはログと同じですが、よ
223
OpenStack 運用ガイド
February 1, 2016
り詳細な情報を持ちます。通知の概要のよい資料は、System Usage Data
にあります。
nova で通知の送信を有効化するには次の行を nova.conf に追加しま
す。
notification_topics=monitor
notification_driver=messagingv2
Once nova is sending notifications, install and configure
StackTach. Since StackTach is relatively new and constantly
changing, installation instructions would quickly become
outdated. Please refer to the StackTach Git repo for instructions
as well as a demo video. Additional details on the latest
developments can be discovered at the official page
OpenStack Telemetry
OpenStack の統合プロジェクト (コード名 ceilometer) は、OpenStack
のサービスに関連するメータリングとイベントデータを収集しま
す。Telemetry モジュールにより収集されるデータは、課金のために
使用できます。環境の設定によっては、ユーザーが設定に基づいて収
集したデータにアクセスできるかもしれません。Telemetry サービス
は、http://developer.openstack.org/api-ref-telemetry-v2.html に
ドキュメント化されている REST API を提供します。このモジュー
ルの詳細は、OpenStack Cloud Administrator Guide や developer
documentation にあります。
OpenStack 固有のリソース
メモリ、ディスク、CPUのような一般的なリソースは、全てのサーバー
(OpenStackに関連しないサーバーにも)に存在するため、サーバーの状
態監視において重要です。OpenStackの場合、インスタンスを起動する
ために必要なリソースが確実に存在するかの確認という点でも重要で
す。OpenStackのリソースを見るためには幾つかの方法が存在します。 1
番目は nova コマンド経由です。
# nova usage-list
このコマンドはテナント上で実行されるインスタンスのリストと、イン
スタンス全体の簡単な利用統計を表示します。クラウドの簡単な概要を
得るのに便利なコマンドですが、より詳細な情報については表示しませ
ん。
次に nova データベースは 利用情報に関して3つのテーブルを持ってい
ます。
224
OpenStack 運用ガイド
February 1, 2016
nova.quotas と nova.quota_usages テーブルはクォータの情報が保管
されています。もし、テナントのクォータがデフォルト設定と異なる場
合、nova.quotas テーブルに保管されます。以下に例を示します。
mysql> select project_id, resource, hard_limit from quotas;
+----------------------------------+----------------------------+------------+
| project_id
| resource
|
|
+----------------------------------+----------------------------+------------+
| 628df59f091142399e0689a2696f5baa | metadata_items
|
|
| 628df59f091142399e0689a2696f5baa | injected_file_content_bytes |
|
| 628df59f091142399e0689a2696f5baa | injected_files
|
|
| 628df59f091142399e0689a2696f5baa | gigabytes
|
|
| 628df59f091142399e0689a2696f5baa | ram
|
|
| 628df59f091142399e0689a2696f5baa | floating_ips
|
|
| 628df59f091142399e0689a2696f5baa | instances
|
|
| 628df59f091142399e0689a2696f5baa | volumes
|
|
| 628df59f091142399e0689a2696f5baa | cores
|
|
+----------------------------------+----------------------------+------------+
hard_limit
128
10240
5
1000
51200
10
10
10
20
nova.quota_usagesテーブルはどのくらいリソースをテナントが利用して
いるかを記録しています。
mysql> select project_id, resource, in_use from quota_usages where project_id
like '628%';
+----------------------------------+--------------+--------+
| project_id
| resource
| in_use |
+----------------------------------+--------------+--------+
| 628df59f091142399e0689a2696f5baa | instances
| 1
|
| 628df59f091142399e0689a2696f5baa | ram
| 512
|
| 628df59f091142399e0689a2696f5baa | cores
| 1
|
| 628df59f091142399e0689a2696f5baa | floating_ips | 1
|
| 628df59f091142399e0689a2696f5baa | volumes
| 2
|
| 628df59f091142399e0689a2696f5baa | gigabytes
| 12
|
| 628df59f091142399e0689a2696f5baa | images
| 1
|
+----------------------------------+--------------+--------+
テナントのハード制限と現在の使用量を比較することにより、それらの
使用割合を確認できます。例えば、このテナントが Floating IP を 10
225
OpenStack 運用ガイド
February 1, 2016
個中 1 個使用している場合、Floating IP クォータの 10% を使用して
いることになります。手動で計算するより、SQL やお好きなスクリプト
言語を使用して、定型化されたレポートを作成できます。
+----------------------------------+------------+------------+---------------+
| some_tenant
|
+-----------------------------------+------------+-----------+---------------+
| Resource
| Used
| Limit
|
|
+-----------------------------------+------------+-----------+---------------+
| cores
| 1
| 20
|
|
| floating_ips
| 1
| 10
|
|
| gigabytes
| 12
| 1000
|
|
| images
| 1
| 4
|
|
| injected_file_content_bytes
| 0
| 10240
|
|
| injected_file_path_bytes
| 0
| 255
|
|
| injected_files
| 0
| 5
|
|
| instances
| 1
| 10
|
|
| key_pairs
| 0
| 100
|
|
| metadata_items
| 0
| 128
|
|
| ram
| 512
| 51200
|
|
| reservation_expire
| 0
| 86400
|
|
| security_group_rules
| 0
| 20
|
|
| security_groups
| 0
| 10
|
|
| volumes
| 2
| 10
|
|
+-----------------------------------+------------+-----------+---------------+
5 %
10 %
1 %
25 %
0 %
0 %
0 %
10 %
0 %
0 %
1 %
0 %
0 %
0 %
20 %
前の情報は GitHub にあるカスタムスクリプトを使用して生成されまし
た。
226
OpenStack 運用ガイド
February 1, 2016
注記
このスクリプトは特定のOpenStackインストール環境向けなの
で、自身の環境に適用する際には変更しなくてはいけません
が、ロジックは簡単に変更できるでしょう。
インテリジェントなアラート
インテリジェントなアラート機能により、ある種の運用の継続的インテ
グレーションと考えることができます。例えば、glance-api プロセスと
glance-registry プロセスが動作していること、または glace-api が
9292 ポートで応答していることを確認することにより、Image service
が起動して動作していることを簡単に確認できます。
しかし、Image service にイメージが正しくアップロードされたことを
どのように知ればいいのでしょうか? もしかしたら、Image service が
保管しているイメージのディスクが満杯、もしくは S3 のバックエンド
がダウンしているかもしれません。簡易的なイメージアップロードを行
なうことでこれをチェックすることができます。
227
OpenStack 運用ガイド
February 1, 2016
#!/bin/bash
#
# assumes that reasonable credentials have been stored at
# /root/auth
. /root/openrc
wget http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img
glance image-create --name='cirros image' --is-public=true
--container-format=bare --disk-format=qcow2 < cirros-0.3.4-x8
6_64-disk.img
このスクリプトを(Nagiosのような)監視システムに組込むことで、イ
メージカタログのアップロードが動作していることを自動的に確認する
ことができます。
注記
毎回テスト後にイメージを削除する必要があります。イメー
ジサービスからイメージが削除できるかのテストにしてしま
えば、さらによいです。
インテリジェントなアラートは、この章で述べられているの他のアラー
トよりも計画、実装にかなり時間を要します。インテリジェントなア
ラートを実装する流れは次のようになります。
• 構築したクラウドにおいて一般的なアクションをレビューする
• それらのアクションに対して自動テストを作成する
• それらのテストをアラートシステムに組み込む
インテリジェントなアラートのその他の例としては以下があります。
• インスタンスの起動と削除が可能か?
• ユーザの作成は可能か?
• オブジェクトの保存と削除は可能か?
• ボリュームの作成と削除は可能か?
トレンド
傾向は、あなたのクラウドが日々どのように動作しているかについて、
素晴らしい洞察を与えられます。例えば、忙しい日が単純にほとんど発
生していないかどうか、新しいコンピュートノードを追加しはじめるべ
きかどうかを学習できます。
228
OpenStack 運用ガイド
February 1, 2016
トレンドはアラートとは全く異なったアプローチです。アラートは0か
1かの結果(チェックが成功するか失敗するか)に注目しているのに対し
て、トレンドはある時点での状態を定期的に記録します。十分な量が記
録されれば、時系列でどのように値が変化するかを確認できます。
これまでに示した全てのアラートタイプは、トレンドレポートに利用可
能です。その他のトレンドの例は以下の通りです。
• 各コンピュートノード上のインスタンス数
• 使用中のフレーバー
• 使用中のボリューム数
• 1時間あたりの Object Storage リクエスト数
• 1時間あたりの nova-api リクエスト数
• ストレージサービスの I/O の統計
例として、nova-apiの使用を記録することでクラウドコントローラーを
スケールする必要があるかを追跡できます。nova-apiのリクエスト数に
注目することにより、nova-apiプロセスを追加するか、もしくは、novaapiを実行するための新しいサーバーを導入することまで行なうかを決定
することができます。リクエストの概数を取得するには/var/log/nova/
nova-api.logのINFOメッセージを検索します。
# grep INFO /var/log/nova/nova-api.log | wc
成功したリクエストを検索することで、更なる情報を取得できます。
# grep " 200 " /var/log/nova/nova-api.log | wc
このコマンドを定期的に実行し結果を記録することで、トレンドレポー
トを作ることができます。これにより/var/log/nova/nova-api.logの使
用量が増えているのか、減っているのか、安定しているのか、を知るこ
とができます。
collectdのようなツールはこのような情報を保管することに利用できま
す。collectdはこの本のスコープから外れますが、collectdでCOUNTER
データ形として結果を保存するのがよい出発点になります。より詳しい
情報は collectd のドキュメント を参照してください。
概要
安定運用のために、障害を即座に検知して、原因を効率的に見つけたい
と思います。分散システムを用いると、目標サービスレベルを満たす
229
OpenStack 運用ガイド
February 1, 2016
ために、適切な項目を追跡することがより重要になります。ログが保
存されるファイルシステムの場所、API が与える利点を学びます。本章
は、OpenStack のサービスを効率的に監視できるよう、それらからの情
報を読み、解釈し、操作する方法も説明しました。
230
OpenStack 運用ガイド
February 1, 2016
第14章 バックアップとリカバリー
バックアップ対象 ...........................................
データベースのバックアップ .................................
ファイルシステムバックアップ ...............................
バックアップのリカバリー ...................................
概要 .......................................................
231
232
232
234
235
OpenStackバックアップポリシーを作成する際、標準的なバックアップの
ベストプラクティスが適用できます。例えば、どの程度の頻度でバック
アップを行なうかは、どのくらい早くデータロスから復旧させる必要が
あるかに密接に関連しています。
注記
すべてのデータをまったく失いたくない場合、高可用性を持
たせた導入に注力すべきです。OpenStack High Availability
Guide は、システム停止につながる可能性がある、単一障害
点の削減に向けた提案があります。完全に規定されたドキュ
メントではありませんが、停止時間やデータ損失を避けるた
めの方法や技術を提供しています。
さらにバックアップの考慮点として以下があげられます。
• いくつのバックアップを持つべきか?
• オフサイトにバックアップを置くべきか?
• どの程度の頻度でバックアップをテストすべきか?
バックアップポリシーと同じくらい大事なことは、リカバリーポリシー
です (少なくともリカバリーのテストは必要です)。
バックアップ対象
OpenStackは多くのコンポーネントから構成され、注意を払うべき箇所も
たくさんありますが、大事なデータのバックアップは非常に単純です。
この章では、OpenStackコンポーネントを動作させるのに必要な設定ファ
イルとデータベースについてのバックアップ方法のみを説明します。オ
ブジェクトストレージ内のオブジェクトや、ブロックストレージ内の
データのバックアップについては説明していません。一般的にこれらの
領域はユーザー自身でバックアップを行います。
231
OpenStack 運用ガイド
February 1, 2016
データベースのバックアップ
参考アーキテクチャーでは、クラウドコントローラーを MySQL サーバ
にしています。この MySQL サーバーは nova, glance, cinder, そして
keystone のデータベースを保持しています。全てのデータベースが一か
所にある場合、データベースバックアップは非常に容易となります。
# mysqldump --opt --all-databases > openstack.sql
もし、単一のデータベースのみバックアップする場合は次のように実行
します。
# mysqldump --opt nova > nova.sql
ここで nova はバックアップ対象のデータベースです。
以下のようなcronジョブを一日に一度実行することで、簡単に自動化す
ることも出来ます。
#!/bin/bash
backup_dir="/var/lib/backups/mysql"
filename="${backup_dir}/mysql-`hostname`-`eval date +%Y%m%d`.sql.gz"
# Dump the entire MySQL database
/usr/bin/mysqldump --opt --all-databases | gzip > $filename
# Delete backups older than 7 days
find $backup_dir -ctime +7 -type f -delete
このスクリプトは MySQL データベース全体をダンプし、7日間より古い
バックアップを削除します。
ファイルシステムバックアップ
このセクションは、サービスにより整理される、定期的にバックアップ
すべきファイルやディレクトリーについて議論します。
コンピュート
クラウドコントローラーとコンピュートノードの /etc/nova ディレクト
リーは、定期的にバックアップすべきです。
/var/log/nova については、全てのログをリモートで集中管理している
のであれば、バックアップの必要はありません。ログ集約システムの導
入か、ログディレクトリのバックアップを強く推奨します
/var/lib/nova がバックアップする他の重要なディレクトリです。これ
の例外がコンピュートノードにある /var/lib/nova/instances サブディ
レクトリです。このサブディレクトリには実行中のインスタンスの KVM
232
OpenStack 運用ガイド
February 1, 2016
イメージが置かれます。このディレクトリをバックアップしたいと思う
のは、すべてのインスタンスのバックアップコピーを保持する必要があ
る場合だけでしょう。多くの場合において、これを実行する必要があり
ません。ただし、クラウドごとに異なり、サービスレベルによっても異
なる可能性があります。稼働中の KVM インスタンスのバックアップは、
バックアップから復元したときでも、正しく起動しない可能性があるこ
とに気をつけてください。
イメージカタログと配布
/etc/glanceと/var/log/glanceはnovaの場合と同じルールに従います。
/var/lib/glanceもバックアップすべきです。 /var/lib/glance/
imagesには特段の注意が必要です。もし、ファイルベースのバックエン
ドを利用しており、このディレクトリがイメージの保管ディレクトリな
らば特にです。
このディレクトリの永続性を保証するために二つの方法があります。一
つ目はRAIDアレイ上にこのディレクトリを置くことで、ディスク障害時
にもこのディレクトリが利用できます。二つ目の方法はrsyncのような
ツールを用いてイメージを他のサーバーに複製することです。
# rsync -az --progress /var/lib/glance/images \
backup-server:/var/lib/glance/images/
認証
/etc/keystone と /var/log/keystone は他のコンポーネントの場合と同
じルールに従います。
/var/lib/keystoneは、使用されるデータは含まれていないはずですが、
念のためバックアップします。
ブロックストレージ
/etc/cinder と /var/log/cinder は他のコンポーネントの場合と同じ
ルールに従います。
/var/lib/cinderもまたバックアップされるべきです。
オブジェクトストレージ
/etc/swiftは非常に重要ですのでバックアップが必要です。このディレ
クトリには、swiftの設定ファイル以外に、RingファイルやRingビルダー
233
OpenStack 運用ガイド
February 1, 2016
ファイルが置かれています。これらのファイルを消失した場合はクラス
ター上のデータにアクセスできなくなります。ベストプラクティスとし
ては、ビルダーファイルを全てのストレージノードにringファイルと共
に置くことです。この方法でストレージクラスター上にバックアップコ
ピーが分散されて保存されます。
バックアップのリカバリー
バックアップのリカバリーは単純です。始めにリカバリー対象のサー
ビスが停止していることを確認します。例を挙げると、クラウドコント
ローラー上の nova の完全リカバリーを行なう場合、最初に全ての nova
サービスを停止します。
234
OpenStack 運用ガイド
#
#
#
#
#
#
stop
stop
stop
stop
stop
stop
February 1, 2016
nova-api
nova-cert
nova-consoleauth
nova-novncproxy
nova-objectstore
nova-scheduler
以前にバックアップしたデータベースをインポートします。
# mysql nova < nova.sql
バックアップされた nova ディレクトリーもリストアできます。
# mv /etc/nova{,.orig}
# cp -a /path/to/backup/nova /etc/
ファイルをリストア後、サービスを起動します。
# start mysql
# for i in nova-api nova-cert nova-consoleauth nova-novncproxy
nova-objectstore nova-scheduler
> do
> start $i
> done
他のサービスもそれぞれのディレクトリとデータベースで同じ処理とな
ります。
概要
バックアップ、その後のリカバリーは、最初に学習するシステム管理の
1 つです。しかしながら、各システムは、それぞれ注意を必要とする項
目が異なります。データベース、Image service、適切なファイルシステ
ムの場所に注意することにより、リカバリーを必要とするすべてのイベ
ントを処理できることが保証されます。
235
OpenStack 運用ガイド
February 1, 2016
第15章 カスタマイズ
OpenStack 開発環境の作成 ...................................
Object Storage (Swift) ミドルウェアのカスタマイズ ...........
OpenStack Compute (nova) スケジューラーのカスタマイズ .......
Dashboard (Horizon) のカスタマイズ .........................
まとめ .....................................................
237
240
246
252
252
OpenStack はあなたが必要とするすべてのことをしてくれるわけではな
いかもしれません。新しい機能を追加するために、いくつかの方法に従
うことができます。
まず最初に、貢献方法を学び、Code Review Workflow に従って、あなた
の修正をアップストリームの OpenStack プロジェクトへコントリビュー
トしてください。もし、あなたが必要な機能が既存のプロジェクトと密
にインテグレーションする必要がある場合、これが推奨される選択肢で
す。コミュニティは、いつでも貢献に対して開かれていますし、機能開
発ガイドラインに従う新機能を歓迎します。
2 番目の方法として、新機能を書き、設定ファイルを変更して、それら
をプラグインすることもできます。もし、あなたの機能が必要とされ
るプロジェクトが Python Paste フレームワークを使っているのであれ
ば、そのための ミドルウェアを作成し、環境設定を通じて組み込めば
よいのです。例えば、Compute の新しいスケジューラーや dashboard の
カスタムタブなど、プロジェクトをカスタマイズする を作成するといっ
た、プロジェクトをカスタマイズする具体的な方法もあるかもしれませ
ん。
本章は、新しい機能を書くために 2 つの例を提供することによ
り、OpenStack をカスタマイズするための 2 つ目のパスに焦点を
当てます。1 番目の例は、新しい機能を追加するために Object
Storage (swift) ミドルウェアを変更する方法を示します。2 番目の例
は、OpenStack Compute (nova) に新しいスケジューラー機能を提供しま
す。このように OpenStack をカスタマイズするために、開発環境が必要
になります。迅速に環境を準備して動作させる最良の方法は、クラウド
内で DevStack を実行することです。
OpenStack 開発環境の作成
開発環境を作成するために、DevStack を使用できます。DevStack は本
質的に、OpenStack の開発環境を構築する、シェルスクリプトと設定
237
OpenStack 運用ガイド
February 1, 2016
ファイルの塊です。新しい機能を開発するために、そのような環境を構
築するために使用します。
すべてのドキュメントは DevStack の Web サイトにあります。
お使いの OpenStack クラウド上のインスタンスで DevStack を
動作させるために:
1.
ダッシュボード、または nova のコマンドラインインタフェース
(CLI)から、以下のパラメータでインスタンスを起動してください。
• 名前: devstack
• イメージ: Ubuntu 14.04 LTS
• メモリー容量: 4 GB RAM
• ディスクサイズ: 最低 5 GB
nova コマンドを使っているのであれば、適切なメモリ量とディスク
サイズを得るために nova boot コマンドに --flavor 3 を指定して
ください。
2.
ログインして、DevStack をセットアップします。これは、仮想マシ
ンに DevStack をセットアップするために使用できるコマンドの例
です。
a.
インスタンスにログインします:
$ ssh ユーザー名@my.instance.ip.address
b.
仮想マシンのオペレーティングシステムを更新します:
# apt-get -y update
c.
git をインストールします:
# apt-get -y install git
d.
devstack リポジトリーをクローンします:
$ git clone https://git.openstack.org/openstack-dev/devstack
e.
devstack リポジトリーに移動します:
$ cd devstack
3.
(オプション) インスタンスに root としてログインした場合、
「stack」ユーザーを作成する必要があります。そうしなければ、
238
OpenStack 運用ガイド
February 1, 2016
パーミッションの問題に遭遇するでしょう。root 以外のユーザーと
してログインしている場合、これらの手順をスキップできます。
a.
DevStack のスクリプトを実行して、stack ユーザーを作成しま
す。
# tools/create-stack-user.sh
b.
devstack ディレクトリーの所有者を stack ユーザーに変更し
ます。
# chown -R stack:stack /root/devstack
c.
後から DevStack の画面を表示するために使用できるよう、い
くつかのパーミッションを設定します。
# chmod o+rwx /dev/pts/0
d.
stack ユーザーに変更します。
$ su stack
4.
DevStack が配備するものを制御する local.conf 設定ファイルを編
集します。このセクションの最後にある local.conf ファイル例を
コピーします (例15.1「local.conf」 [240])。
$ vim local.conf
5.
OpenStack をインストールする stack スクリプトを実行します。
$ ./stack.sh
6.
stack スクリプトが完了すると、起動した screen セッションを開
いて、すべての動作中の OpenStack サービスを表示できます。
$ screen -r stack
7.
Ctrl+A に続けて 0 を押して、1 番目の screen ウィンドウに移動
します。
注記
• stack.sh スクリプトは、実行にしばらく時間がかかりま
す。おそらく、この機会に OpenStack Foundation に参
加できます。
• Screen は、多くの関連するサービスを同時に見るための便
利なプログラムです。GNU screen quick reference を参照
してください。
239
OpenStack 運用ガイド
February 1, 2016
以上で OpenStack の開発環境を準備できましたので、運
用環境にダメージを与えることを心配せずに自由にハック
できます。例15.1「local.conf」 [240] は、手始めとし
て OpenStack Identity、Compute、Block Storage、Image
service、dashboard、Object Storage を実行するための作業環境を提供
します。
例15.1 local.conf
[[local|localrc]]
FLOATING_RANGE=192.168.1.224/27
FIXED_RANGE=10.11.12.0/24
FIXED_NETWORK_SIZE=256
FLAT_INTERFACE=eth0
ADMIN_PASSWORD=supersecret
DATABASE_PASSWORD=iheartdatabases
RABBIT_PASSWORD=flopsymopsy
SERVICE_PASSWORD=iheartksl
SERVICE_TOKEN=xyzpdqlazydog
Object Storage (Swift) ミドルウェアの
カスタマイズ
OpenStack Object Storage は、コード参照時に swift としても知ら
れ、Python Paste フレームワークに基づいています。そのアーキテク
チャーは、A Do-It-Yourself Framework から始めると最も良いでしょ
う。swift プロジェクトはこのフレームワークを使用しているので、コ
アのコードを変更することなく、プロジェクトのパイプラインにカスタ
ムコードをいくつか配置することにより、プロジェクトに機能を追加で
きます。
お使いのコンテナーの 1 つにパブリックにアクセスできるシナリオを
想像してください。しかし、本当にやりたいことは、ホワイトリストに
基づいてアクセスできる IP を制限することです。この例では、コンテ
ナーのメタデータ項目により決められるよう、ある IP アドレス群だけ
からコンテナーにアクセスを許可する、swift 向けのミドルウェア部品
を作成します。コンテナーのメタデータを使用して、明示的にホワイト
リストに入っている IP アドレスのみが、コンテナーにアクセスできま
す。
警告
この例は実証目的のみのためにあります。さらなる作りこみ
と広範なセキュリティテストなしにコンテナのIPホワイトリ
スト・ソリューションとして使用するべきではありません。
240
OpenStack 運用ガイド
February 1, 2016
stack.sh が screen -r stack で作成したセッションに join すると、
動作中の各サービスのスクリーンを参照できます。これは、DevStack が
実行するよう設定したサービスの数に依存して、いくつかあるでしょ
う。
アスタリスク (*) は、表示している screen ウィンドウを表していま
す。この例は、keystone 用の key という screen ウィンドウを表示し
ていることを表しています。
0$ shell
account
1$ key*
2$ horizon
3$ s-proxy
4$ s-object 5$ s-container 6$ s-
screen ウィンドウの目的は、以下のとおりです。
shell
作業を行うためのシェル
key*
keystone サービス
horizon
horizon dashboard Web アプリケーション
s-{name}
swift サービス
ミドルウェアを作成して Paste の環境設定を通して組み込むた
めには：
すべての OpenStack のコードは /opt/stack にあります。shell セッ
ションの screen の中で swift ディレクトリに移動し、あなたのミドル
ウェアモジュールを編集してください。
1.
Object Storage がインストールされるディレクトリーを変更しま
す。
$ cd /opt/stack/swift
2.
ip_whitelist.py Python ソースコードファイルを作成します。
$ vim swift/common/middleware/ip_whitelist.py
3.
例15.2「ip_whitelist.py」 [242] にあるコードを
ip_whitelist.py にコピーします。以下のコードは、このセク
ションの初めに説明されたように、IP アドレスに基づいてコンテ
ナーへのアクセスを制限するミドルウェアの例です。ミドルウェア
は、他のアプリケーションへのリクエストを通過させます。この例
は、swift "swob" ライブラリーを使用して、swift が通信するオブ
ジェクトに関する Web Server Gateway Interface (WSGI) のリクエ
ストとレスポンスをラップします。これを実行したとき、ファイル
を保存して閉じます。
241
OpenStack 運用ガイド
February 1, 2016
例15.2 ip_whitelist.py
# vim: tabstop=4 shiftwidth=4 softtabstop=4
# Copyright (c) 2014 OpenStack Foundation
# All Rights Reserved.
#
#
Licensed under the Apache License, Version 2.0 (the "License"); you may
#
not use this file except in compliance with the License. You may obtain
#
a copy of the License at
#
#
http://www.apache.org/licenses/LICENSE-2.0
#
#
Unless required by applicable law or agreed to in writing, software
#
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
#
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
#
License for the specific language governing permissions and limitations
#
under the License.
import socket
from swift.common.utils import get_logger
from swift.proxy.controllers.base import get_container_info
from swift.common.swob import Request, Response
class IPWhitelistMiddleware(object):
"""
IP Whitelist Middleware
Middleware that allows access to a container from only a set of IP
addresses as determined by the container's metadata items that start
with the prefix 'allow'. E.G. allow-dev=192.168.0.20
"""
def __init__(self, app, conf, logger=None):
self.app = app
if logger:
self.logger = logger
else:
self.logger = get_logger(conf, log_route='ip_whitelist')
self.deny_message = conf.get('deny_message', "IP Denied")
self.local_ip = socket.gethostbyname(socket.gethostname())
def __call__(self, env, start_response):
"""
WSGI entry point.
Wraps env in swob.Request object and passes it down.
:param env: WSGI environment dictionary
:param start_response: WSGI callable
"""
req = Request(env)
try:
version, account, container, obj = req.split_path(1, 4, True)
242
OpenStack 運用ガイド
February 1, 2016
except ValueError:
return self.app(env, start_response)
container_info = get_container_info(
req.environ, self.app, swift_source='IPWhitelistMiddleware')
remote_ip = env['REMOTE_ADDR']
self.logger.debug("Remote IP: %(remote_ip)s",
{'remote_ip': remote_ip})
meta = container_info['meta']
allow = {k:v for k,v in meta.iteritems() if k.startswith('allow')}
allow_ips = set(allow.values())
allow_ips.add(self.local_ip)
self.logger.debug("Allow IPs: %(allow_ips)s",
{'allow_ips': allow_ips})
if remote_ip in allow_ips:
return self.app(env, start_response)
else:
self.logger.debug(
"IP %(remote_ip)s denied access to Account=%(account)s "
"Container=%(container)s. Not in %(allow_ips)s", locals())
return Response(
status=403,
body=self.deny_message,
request=req)(env, start_response)
def filter_factory(global_conf, **local_conf):
"""
paste.deploy app factory for creating WSGI proxy apps.
"""
conf = global_conf.copy()
conf.update(local_conf)
def ip_whitelist(app):
return IPWhitelistMiddleware(app, conf)
return ip_whitelist
env と conf には、リクエストについて何をするのか判断するのに
使える有用な情報が多数含まれています。どんなプロパティが利用
可能なのかを知るには、以下のログ出力文を __init__ メソッドに
挿入してください。
self.logger.debug("conf = %(conf)s", locals())
そして以下のログ出力分を __call__ メソッドに挿入してくださ
い。
self.logger.debug("env = %(env)s", locals())
4.
このミドルウェアを swift Paste のパイプラインに組み込むには、
設定ファイル /etc/swift/proxy-server.conf を編集します。
243
OpenStack 運用ガイド
February 1, 2016
$ vim /etc/swift/proxy-server.conf
5.
/etc/swift/proxy-server.conf の [filter:ratelimit] セクション
を探し、その後ろに以下の環境定義セクションを貼り付けてくださ
い。
[filter:ip_whitelist]
paste.filter_factory = swift.common.middleware.ip_whitelist:filter_factory
# You can override the default log routing for this filter here:
# set log_name = ratelimit
# set log_facility = LOG_LOCAL0
# set log_level = INFO
# set log_headers = False
# set log_address = /dev/log
deny_message = You shall not pass!
6.
/etc/swift/proxy-server.conf [pipeline:main] セクションを探
し、このように ip_whitelist リストを ratelimit の後ろに追加し
てください。完了したら、ファイルを保存して閉じてください。
[pipeline:main]
pipeline = catch_errors gatekeeper healthcheck proxy-logging cache bulk tempurl
ratelimit ip_whitelist ...
7.
8.
swift proxy にこのミドルウェアを使わせるために、Swift プロキ
シサービスを再起動します。swift-proxy の screen セッションに
切り替えてはじめてください。
a.
Ctrl+A に続けて 3 を押します。
b.
Ctrl+C を押し、サービスを強制停止します。
c.
上矢印キーを押し、最後のコマンドを表示させます。
d.
Enter キーを押し、実行します。
swift の CLI でミドルウェアのテストをしてください。shell の
screen セッションに切り替えてテストを開始し、swift-proxy の
screen セッションにもどってログ出力をチェックして終了します。
a.
Ctrl+A に続けて 0 を押します。
b.
devstack ディレクトリーにいることを確認します。
$ cd /root/devstack
c.
openrc を読み込み、CLI の環境変数を設定します。
$ source openrc
244
OpenStack 運用ガイド
d.
February 1, 2016
middleware-test という名前のコンテナーを作成します。
$ swift post middleware-test
e.
9.
Ctrl+A に続けて 3 を押して、ログ出力を確認します。
ログの中に以下の行があるでしょう。
proxy-server Remote IP: my.instance.ip.address (txn: ...)
proxy-server Allow IPs: set(['my.instance.ip.address']) (txn: ...)
これらの２行は、このミドルウェアによって出力されており、リク
エストが DevStack インスタンスから送られており、許可されてい
ることを示しています。
10. DevStack 環境の外の、DevStack 用インスタンスにアクセス可能な
リモートマシンからミドルウェアをテストします。
a.
ローカルマシンに keystone と swift クライアントをインス
トールします。
# pip install python-keystoneclient python-swiftclient
b.
middleware-test コンテナーにあるオブジェクトを一覧表示し
ようとします。
$ swift --os-auth-url=http://my.instance.ip.address:5000/v2.0/ \
--os-region-name=RegionOne --os-username=demo:demo \
--os-password=devstack list middleware-test
Container GET failed: http://my.instance.ip.address:8080/v1/AUTH_..
./
middleware-test?format=json 403 Forbidden You shall not pass!
11. Ctrl+A に続けて 3 を押して、ログ出力を確認します。再び swift
のログを確認すると、ログの中に以下の行があるでしょう。
proxy-server Authorizing from an overriding middleware (i.e: tempurl)
(txn: ...)
proxy-server ... IPWhitelistMiddleware
proxy-server Remote IP: my.local.ip.address (txn: ...)
proxy-server Allow IPs: set(['my.instance.ip.address']) (txn: ...)
proxy-server IP my.local.ip.address denied access to Account=AUTH_... \
Container=None. Not in set(['my.instance.ip.address']) (txn: ...)
ここで、リモートIPアドレスが、許可されたIPアドレスの中にな
かったため、リクエストが拒否されていることがわかります。
245
OpenStack 運用ガイド
February 1, 2016
12. シェル画面において DevStack 用インスタンスに戻り、リモートマ
シンからのリクエストを許可するようなコンテナのメタデータを追
加します。
a.
Ctrl+A に続けて 0 を押します。
b.
メタデータをコンテナーに追加して、IP を許可します。
$ swift post --meta allow-dev:my.local.ip.address middleware-test
c.
ここで手順 10 のコマンドを再び試みて、続行します。コンテ
ナーにオブジェクトがありません。そのため、一覧には何もあ
りません。しかしながら、レポートするエラーもありません。
警告
このような機能テストは、適切な機能テストや結合テストを
置き換えるものではありませんが、取り掛かりに良いでしょ
う。
Python Paste フレームワークを使う他のすべてのプロジェクトで、類
似のパターンに従うことができます。単純にミドルウェアモジュール
を作成し、環境定義によって組み込んでください。そのミドルウェアは
プロジェクトのパイプラインの一部として順番に実行され、必要に応じ
て他のサービスを呼び出します。プロジェクトのコア・コードは一切修
正しません。Paste を使っているプロジェクトを確認するには、/etc/
<project> に格納されている、プロジェクトの conf または ini 環境定
義ファイルの中で　pipeline 変数を探してください。
When your middleware is done, we encourage you to open source it
and let the community know on the OpenStack mailing list. Perhaps
others need the same functionality. They can use your code,
provide feedback, and possibly contribute. If enough support
exists for it, perhaps you can propose that it be added to the
official swift middleware.
OpenStack Compute (nova) スケジュー
ラーのカスタマイズ
多くの OpenStack のプロジェクトでは、ドライバ・アーキテクチャーを
使うことによって、特定の機能をカスタマイズすることができます。特
定のインターフェースに適合するドライバを書き、環境定義によって組
み込むことができます。例えば、簡単に Compute に新しいスケジュー
ラーを組み込むことができます。Compute の既存のスケジューラーは、
246
OpenStack 運用ガイド
February 1, 2016
完全な機能を持ち、Scheduling によくまとめられています。しかし、あ
なたのユーザのユース・ケースに依存して、既存のスケジューラで要件
が満たせないかもしれません。この場合は、新しいスケジューラーを作
成する必要があるでしょう。
スケジューラーを作成するには、nova.scheduler.driver.Scheduler ク
ラスを継承しなければなりません。オーバーライド可能な５つのメソッ
ドのうち、以下のアスタリスク (*) で示される２つのメソッドをオー
バーライドしなければなりません。
• update_service_capabilities
• hosts_up
• group_hosts
• * schedule_run_instance
• * select_destinations
OpenStack のカスタマイズをデモするために、リクエストの送信元IPア
ドレスとホスト名のプレフィックスに基づいてインスタンスを一部のホ
ストにランダムに配置するような Compute のスケジューラーの例を作
成します。この例は、１つのユーザのグループが１つのサブネットにお
り、インスタンスをホスト群の中の一部のサブネットで起動したい場合
に有用です。
警告
この例は実証目的のみのためにあります。さらなる作りこみ
とテストなしで、Compute のスケジューラーとして使用する
べきではありません。
stack.sh が screen -r stack で作成したセッションに join すると、
多数の screen ウィンドウが見えます。
0$ shell*
1$ key
2$ horizon
...
9$ n-api
... 14$ n-sch ...
shell
作業を行うためのシェル
key
keystone サービス
horizon
horizon dashboard Web アプリケーション
n-{name}
nova サービス
n-sch
nova スケジューラーサービス
247
OpenStack 運用ガイド
February 1, 2016
スケジューラーを作成して、設定を通して組み込むためには：
1.
OpenStack のコードは /opt/stack にあるので、nova ディレクトリ
に移動してあなたのスケジューラーモジュールを編集します。nova
をインストールしたディレクトリーに移動します。
$ cd /opt/stack/nova
2.
ip_scheduler.py Python ソースコードファイルを作成します。
$ vim nova/scheduler/ip_scheduler.py
3.
例15.3「ip_scheduler.py」 [248] にあるコードはドライバー
です。セクションの最初に説明されているように IP アドレスに
基づいて、サーバーをホストにスケジュールします。コードを
ip_scheduler.py にコピーします。完了すると、ファイルを保存し
て閉じます。
例15.3 ip_scheduler.py
# vim: tabstop=4 shiftwidth=4 softtabstop=4
# Copyright (c) 2014 OpenStack Foundation
# All Rights Reserved.
#
#
Licensed under the Apache License, Version 2.0 (the "License"); you may
#
not use this file except in compliance with the License. You may obtain
#
a copy of the License at
#
#
http://www.apache.org/licenses/LICENSE-2.0
#
#
Unless required by applicable law or agreed to in writing, software
#
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
#
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
#
License for the specific language governing permissions and limitations
#
under the License.
"""
IP Scheduler implementation
"""
import random
from oslo.config import cfg
from
from
from
from
from
nova.compute import rpcapi as compute_rpcapi
nova import exception
nova.openstack.common import log as logging
nova.openstack.common.gettextutils import _
nova.scheduler import driver
CONF = cfg.CONF
CONF.import_opt('compute_topic', 'nova.compute.rpcapi')
LOG = logging.getLogger(__name__)
class IPScheduler(driver.Scheduler):
"""
Implements Scheduler as a random node selector based on
IP address and hostname prefix.
"""
248
OpenStack 運用ガイド
February 1, 2016
def __init__(self, *args, **kwargs):
super(IPScheduler, self).__init__(*args, **kwargs)
self.compute_rpcapi = compute_rpcapi.ComputeAPI()
def _filter_hosts(self, request_spec, hosts, filter_properties,
hostname_prefix):
"""Filter a list of hosts based on hostname prefix."""
hosts = [host for host in hosts if host.startswith(hostname_prefix)]
return hosts
def _schedule(self, context, topic, request_spec, filter_properties):
"""Picks a host that is up at random."""
elevated = context.elevated()
hosts = self.hosts_up(elevated, topic)
if not hosts:
msg = _("Is the appropriate service running?")
raise exception.NoValidHost(reason=msg)
remote_ip = context.remote_address
if remote_ip.startswith('10.1'):
hostname_prefix = 'doc'
elif remote_ip.startswith('10.2'):
hostname_prefix = 'ops'
else:
hostname_prefix = 'dev'
hosts = self._filter_hosts(request_spec, hosts, filter_properties,
hostname_prefix)
if not hosts:
msg = _("Could not find another compute")
raise exception.NoValidHost(reason=msg)
host = random.choice(hosts)
LOG.debug("Request from %(remote_ip)s scheduled to %(host)s" % locals())
return host
def select_destinations(self, context, request_spec, filter_properties):
"""Selects random destinations."""
num_instances = request_spec['num_instances']
# NOTE(timello): Returns a list of dicts with 'host', 'nodename' and
# 'limits' as keys for compatibility with filter_scheduler.
dests = []
for i in range(num_instances):
host = self._schedule(context, CONF.compute_topic,
request_spec, filter_properties)
host_state = dict(host=host, nodename=None, limits=None)
dests.append(host_state)
if len(dests) < num_instances:
raise exception.NoValidHost(reason='')
return dests
def schedule_run_instance(self, context, request_spec,
admin_password, injected_files,
requested_networks, is_first_time,
filter_properties, legacy_bdm_in_spec):
"""Create and run an instance or instances."""
instance_uuids = request_spec.get('instance_uuids')
for num, instance_uuid in enumerate(instance_uuids):
request_spec['instance_properties']['launch_index'] = num
try:
host = self._schedule(context, CONF.compute_topic,
249
OpenStack 運用ガイド
February 1, 2016
request_spec, filter_properties)
updated_instance = driver.instance_update_db(context,
instance_uuid)
self.compute_rpcapi.run_instance(context,
instance=updated_instance, host=host,
requested_networks=requested_networks,
injected_files=injected_files,
admin_password=admin_password,
is_first_time=is_first_time,
request_spec=request_spec,
filter_properties=filter_properties,
legacy_bdm_in_spec=legacy_bdm_in_spec)
except Exception as ex:
# NOTE(vish): we don't reraise the exception here to make sure
#
that all instances in the request get set to
#
error properly
driver.handle_schedule_error(context, ex, instance_uuid,
request_spec)
context と request_spec と filter_propertiesには、どこにイン
スタンスをスケジュールするのか決定するのに使える有用な情報が
多数含まれています。どんなプロパティが利用可能なのかを知るに
は、以下のログ出力文を上記の schedule_run_instance メソッドに
挿入してください。
LOG.debug("context = %(context)s" % {'context': context.__dict__})
LOG.debug("request_spec = %(request_spec)s" % locals())
LOG.debug("filter_properties = %(filter_properties)s" % locals())
4.
このスケジューラーを nova に追加するために、設定ファイル /
etc/nova/nova.conf を編集します。
$ vim /etc/nova/nova.conf
5.
scheduler_driver 設定を見つけ、このように変更してください。
scheduler_driver=nova.scheduler.ip_scheduler.IPScheduler
6.
Nova にこのスケジューラーを使わせるために、Nova スケジュー
ラーサービスを再起動します。 n-sch screen セッションに切り替
えてはじめてください。
a.
Ctrl+A に続けて 9 を押します。
b.
n-sch 画面が表示されるまで、Ctrl+A に続けて N を押しま
す。
c.
Ctrl+C を押し、サービスを強制停止します。
d.
上矢印キーを押し、最後のコマンドを表示させます。
e.
Enter キーを押し、実行します。
250
OpenStack 運用ガイド
7.
February 1, 2016
nova の CLI でスケジューラーのテストをしてください。shell
の screen セッションに切り替えてテストを開始し、n-sch screen
セッションにもどってログ出力をチェックして終了します。
a.
Ctrl+A に続けて 0 を押します。
b.
devstack ディレクトリーにいることを確認します。
$ cd /root/devstack
c.
openrc を読み込み、CLI の環境変数を設定します。
$ source openrc
d.
インストール済みイメージのみのイメージ ID を環境変数に設
定します。
$ IMAGE_ID=`nova image-list | egrep cirros | egrep -v "kernel|
ramdisk" | awk '{print $2}'`
e.
テストサーバーを起動します。
$ nova boot --flavor 1 --image $IMAGE_ID scheduler-test
8.
n-sch 画面に切り替えます。ログ出力の中に、以下の行を見つけら
れます。
2014-01-23 19:57:47.262 DEBUG nova.scheduler.ip_scheduler \
[req-... demo demo] Request from 162.242.221.84 \
scheduled to devstack-havana \
_schedule /opt/stack/nova/nova/scheduler/ip_scheduler.py:76
警告
このような機能試験は、正しいユニットテストと結合テスト
の代わりになるものではありませんが、作業を開始すること
はできます。
ドライバ・アーキテクチャーを使う他のプロジェクトで、類似のパター
ンに従うことができます。単純に、そのドライバーインタフェースに
従うモジュールとクラスを作成し、環境定義によって組み込んでくださ
い。あなたのコードはその機能が使われた時に実行され、必要に応じて
他のサービスを呼び出します。プロジェクトのコアコードは一切修正し
ません。ドライバーアーキテクチャーを使っているプロジェクトを確認
するには、/etc/<project> に格納されている、プロジェクトの .conf
設定ファイルの中で　driver 変数を探してください。
251
OpenStack 運用ガイド
February 1, 2016
When your scheduler is done, we encourage you to open source it
and let the community know on the OpenStack mailing list. Perhaps
others need the same functionality. They can use your code,
provide feedback, and possibly contribute. If enough support
exists for it, perhaps you can propose that it be added to the
official Compute schedulers.
Dashboard (Horizon) のカスタマイズ
dashboard は、Python Django Web アプリケーションフレームワーク
を利用しています。カスタマイズする最高のガイドがすでに書かれてい
て、Building on Horizon にあります。
まとめ
OpenStack クラウドの運用時、ユーザーが非常に要望している可能性が
あることに気が付くかもしれません。OpenStack がユーザーの必要とす
るものを実施していない場合、それらの要求を満たすことをあなたに任
せるかもしれません。本章は、いくつかのカスタマイズの選択肢を提供
し、始めるために必要となるツールを提供します。
252
OpenStack 運用ガイド
February 1, 2016
第16章 OpenStack コミュニティー
助けを得る .................................................
バグ報告 ...................................................
OpenStack コミュニティーに参加する .........................
ドキュメント作成への貢献の仕方 .............................
セキュリティー情報 .........................................
さらに情報を見つける .......................................
253
254
257
258
258
259
OpenStack は非常に活発なコミュニティに支えられており、あなたの参
加をいつでも待っています。この章では、コミュニティーの他の人と交
流する方法について詳しく説明します。
助けを得る
助けを探すために利用できる方法がいくつかあります。最も早い方法
は、あなたを手伝ってくれるコミュニティーを支援することです。あな
たの問題に近いものについて、Q&A サイト、メーリングリストの過去ロ
グ、バグ一覧を検索します。何も見つけられなければ、バグを報告して
指示に従うか、以下のリストにまとまっているサポートチャンネルのど
れかを使用します。
最初に確認すべき場所は OpenStack の公式ドキュメントです。 http://
docs.openstack.org にあります。また、http://ask.openstack.org で
質問と回答を参照することができます。
メーリングリスト もアドバイスをもらうのに素晴らしい場所です。
Wiki ページにメーリングリストの詳しい情報が載っています。運用者と
して確認しておくべき主要なメーリングリストは以下です。
一般向けメーリ
ングリスト
openstack@lists.openstack.org。このリスト
は、OpenStack の現行リリースに関する話題を取り
扱います。流量が非常に多く、1 日にとてもたくさ
んのメールが流れます。
運用者向けメー
リングリスト
openstack-operators@lists.openstack.org.。こ
のメーリングリストは、あなたのように、実際に
OpenStack クラウドを運用している人々での議論を
目的としています。現在のところ、メールの流量は
比較的少なく、1 日に 1 通くらいです。
開発者向けメー
リングリスト
openstack-dev@lists.openstack.org。このリスト
は、OpenStack の今後についての話題を扱います。
流量が多く、1 日に複数のメールが流れます。
253
OpenStack 運用ガイド
February 1, 2016
一般向けリストと運用者向けリストを購読するのがお薦めです。一般向
けリストの流量に対応するにはフィルタを設定する必要があるとは思
いますが。 Wiki のメーリングリストのページにはメーリングリストの
アーカイブへのリンクがあり、そこで議論の過程を検索することができ
ます。
一般的な質問用や開発者の議論用など、 複数の IRC チャネルがありま
す。一般の議論用のチャネルは irc.freenode.net の #openstackです。
バグ報告
運用者として、あなたは、あなたのクラウドでの予期しない動作を報告
できる非常によい立場にいます。 OpenStack は柔軟性が高いので、ある
特定の問題を報告するのはあなた一人かもしれません。すべての問題は
重要で修正すべきものです。そのためには、簡単にバグ報告を登録する
方法を知っておくことは欠かせません。
全ての OpenStack プロジェクトでは、バグ管理に Launchpad を使って
います。バグ報告を行う前に、Launchpad のアカウントを作る必要があ
ります。
Launchpad のアカウントを作った後は、バグを報告するのは、問題の原
因となったプロジェクトを特定するのと同じくらい簡単です。場合に
よっては、思っていたよりも難しいこともありますが、最初のバグ報告
が適切な場所でなかったとしても、バグの分類を行う人がバグ報告を適
切なプロジェクトに割り当て直してくれます。
• nova のバグ報告。
• python-novaclient のバグ報告。
• swift のバグ報告。
• python-swiftclient のバグ報告。
• glance のバグ報告。
• python-glanceclient のバグ報告。
• keystone のバグ報告。
• python-keystoneclient のバグ報告。
• neutron のバグ報告。
254
OpenStack 運用ガイド
February 1, 2016
• python-neutronclient のバグ報告。
• cinder のバグ報告。
• python-cinderclient のバグ報告。
• manila のバグ報告。
• python-manilaclient のバグ報告。
• python-openstackclient のバグ報告。
• horizon のバグ報告。
• ドキュメント のバグ報告。
• API ドキュメント のバグ報告。
よいバグ報告を書くには、次に述べる手順を踏むことが不可欠です。ま
ず、バグを検索し、同じ問題に関してすでに登録されているバグがない
ことを確認します。見つかった場合は、"This bug affects X people.
Does this bug affect you?" (このバグは X 人に影響があります。あ
なたもこのバグの影響を受けますか?) をクリックするようにして下さ
い。同じ問題が見つからなかった場合は、バグ報告で詳細を入力して下
さい。少なくとも以下の情報を含めるべきです。
• 実行しているソフトウェアのリリースやマイルストーン、コミット ID
• あなたがバグを確認したオペレーティングシステムとそのバージョン
• バグの再現手順。何がおかしいかも含めてください
• 期待される結果の説明 (出くわした現象ではなく)
• 関連部分のみを抜粋したログファイル
バグ報告をすると、バグは次のステータスで作成されます。
• Status: New
バグのコメントでは、既知のバグの修正方法に関して案を出したり、バ
グの状態を Triaged (有効な報告か、対応が必要かなどを分類した状態)
にセットすることができます。バグを直接修正することもできます。そ
の場合は、バグを自分に割り当てて、状態を In progress (進行中) に
セットし、コードのブランチを作り、マージしてもらうように変更を提
案するという流れになります。でも、先走りし過ぎないようにしましょ
う。バグを分類するという仕事もありますから。
255
OpenStack 運用ガイド
February 1, 2016
バグの確認と優先付け
このステップでは、バグが実際に起こるかのチェックやその重要度の判
定が行われます。これらのステップを行うには、バグ管理者権限が必要
なものがあります (通常、バグ管理権限はコア開発者チームだけが持っ
ています)。バグ報告に、バグを再現したりバグの重要度を判定したりす
るのに必要な情報が不足している場合、バグは
• Status: Incomplete
にセットされます。問題を再現できた場合 (もしくはこの報告がバグで
あると 100％ 確信を持てる場合) で、セットする権限を持っている場合
には、
• Status: Confirmed
にセットして下さい。
• Importance: <バグ影響度>
バグ影響度は以下のカテゴリに分かれています。
256
OpenStack 運用ガイド
February 1, 2016
1. Critical このバグにより、目玉となる機能が全てのユーザで正常に動
作しない場合 (または簡単なワークアラウンドでは動作しない場合)、
データロスにつながるような場合
2. High このバグにより、目玉となる機能が一部のユーザで正常に動作し
ない場合 (または簡単なワークアラウンドで動作する場合)
3. Medium このバグにより、ある程度重要な機能が正常に動作しない場合
4. Low このバグが多くの場合で軽微な場合
5. Wishlist 実際にはバグではないが、そのように動作を変更した方よい
ものの場合
バグ報告に解決方法やパッチが書かれている場合、そのバグの状態は
Triaged にセットされます。
バグ修正
この段階では、開発者が修正を行います。修正を行っている間、作業の
重複を避けるため、バグの状態を以下のようにセットすべきです。
• Status: In Progress
• Assignee: <あなた自身>
修正が用意できたら、開発者は変更を提案し、レビューを受けます。
変更が受理された後
変更がレビューされ、受理されて、マスターブランチにマージされる
と、バグの状態は自動的に以下のようになります。
• Status: Fix Committed
修正がマイルストーンやリリースブランチに取り込まれると、バグの状
態は自動的に以下のようになります。
• Milestone: このバグの修正が入ったマイルストーン
• Status: Fix Released
OpenStack コミュニティーに参加する
この本をここまで読んで来たので、あなたはコミュニティーの正式な
個人メンバーになって、OpenStack Foundation に加入する (https://
257
OpenStack 運用ガイド
February 1, 2016
www.openstack.org/join/) ことを考えていることでしょう。 OpenStack
Foundation は、共有リソースを提供し OpenStack の目的の達成を支援
する独立組織で、OpenStack ソフトウェア、およびユーザ、開発者、エ
コシステム全体といった OpenStack を取り巻くコニュニティーを守り、
活力を与え、普及の促進を行います。我々全員がこのコミュニティーを
できる限りよいものにしていく責任を共有します。メンバーになること
はコミュニティーに参加する最初のステップです。ソフトウェア同様、
OpenStack Foundation の個人会員は無料で誰でもなることができます。
ドキュメント作成への貢献の仕方
OpenStack のドキュメント作成活動は、運用管理ドキュメント、API ド
キュメント、ユーザドキュメントなどに渡ります。
この本の元は人が集まったイベントで作成されましたが、今やこの本は
みなさんも貢献できる状態になっています。 OpenStack のドキュメント
作成は、バグ報告、調査、修正を繰り返し行うというコーディングの基
本原則に基いて行われています。
Just like the code, http://docs.openstack.org is updated
constantly using the Gerrit review system, with source stored
in git.openstack.org in the openstack-manuals repository and the
api-site repository.
公開される前にドキュメントのレビューを行うには、OpenStack Gerrit
サーバー http://review.openstack.org に行って、project:openstack/
openstack-manuals や project:openstack/api-site を検索して下さ
い。
ドキュメントのレビューや変更を最初に行うのに必要な手続きについて
の詳しい情報は、Wiki の How To Contribute ページを参照して下さ
い。
セキュリティー情報
我々は、コミュニティーとして、セキュリティーを非常に重要だと考
えており、潜在的な問題の報告は決められたプロセスに基いて処理さ
れます。修正を用心深く追跡し、定期的にセキュリティー上の問題点
を取り除きます。あなたは発見したセキュリティー上の問題をこの決
められたプロセスを通して報告できます。OpenStack 脆弱性管理チーム
は、OpenStackコミュニティーから選ばれた脆弱性管理の専門家で構成さ
れるごく少人数のグループです。このチームの仕事は、脆弱性の報告を
手助けし、セキュリティー上の修正の調整を行い、脆弱性情報の公開を
続けていくことです。特に、このチームは以下の役割を担っています。
258
OpenStack 運用ガイド
February 1, 2016
脆弱性管理
コミュニティメンバー (やユーザー)
が発見した全ての脆弱性はこのチーム
に報告されます。
脆弱性追跡
このチームはバグ追跡システムに登録
された脆弱性に関連する問題の管理を
行います。問題の中にはこのチームお
よび影響を受けるプロジェクトの責任
者のみが参照できるものありますが、
問題の修正が用意されると、全ての脆
弱性は公開されます。
Responsible Disclosure（責任
ある情報公開）
セキュリティーコミュニティーと仕
事をする責務の一つとして、セキュリ
ティー情報の公開が、確実に、そして
OpenStack のセキュリティー問題を責
任をもって扱うセキュリティ研究者の
適切なお墨付きを得て行われるように
します。
OpenStack 脆弱性管理チームに問題を報告する方法は 2 種類用意されて
おり、問題の重要度に応じて使い分けて下さい。
• Launchpad でバグ報告を行い、「security bug」のマークを付ける。
マークを付けると、そのバグは一般には公開されなくなり、脆弱性管
理チームだけが参照できるようになります。
• 問題が極めて慎重に扱うべき情報の場合は、脆弱性管理チームのメン
バーの誰かに暗号化したメールを送って下さい。メンバーの GPG 鍵は
OpenStack Security で入手できます。
あなたが参加できるセキュリティー関連のチームのリストは セキュリ
ティーチーム にあります。脆弱性管理プロセスはすべてドキュメントに
まとめられており、脆弱性管理 で参照できます。
さらに情報を見つける
この本以外にも、OpenStack に関する情報源はたくさんあります。
OpenStack ウェブサイト は最初に見るといいでしょう。ここに
は、OpenStack ドキュメント と OpenStack API ドキュメント があ
り、OpenStack に関する技術情報が提供されています。OpenStack wiki
には、OpenStack の各プロジェクトの範囲にとどらまらない汎用的な情
報が多数あり、例えば 推奨ツール といった情報も載っています。最後
に、Planet OpenStack には多くのブログが集められています。
259
OpenStack 運用ガイド
February 1, 2016
第17章 高度な設定
ドライバーによる違い .......................................
定期タスクの実装 ...........................................
設定に関する個別のトピック .................................
261
262
263
OpenStack は、非常に小さなプライベートクラウドから大規模なパブ
リッククラウドまで様々な構成でうまく動くことを意図して作られてい
ます。これを実現するため、開発者はコードに設定オプションを用意
し、要件にあわせて種々のコンポーネントの振る舞いを細かく調整でき
るようにしています。しかし、残念ながら、デフォルトの設定値ですべ
てのデプロイメントに対応することはできません。
執筆時点では、OpenStack は 3,000 以上の設定オプションがありま
す。OpenStack configuration reference guide にドキュメント化され
ています。本章は、これらのすべてをドキュメント化できませんが、ど
の情報を掘り下げて調べるかを理解できるよう、重要な概念を紹介した
いと考えています。
ドライバーによる違い
多くの OpenStack プロジェクトではドライバー層が実装され、各ドラ
イバーはドライバー固有の設定オプションが実装されています。例え
ば、OpenStack Compute (nova) では、libvirt, xenserver, hyper-v,
vmware などの種々のハイパーバイザードライバーが実装されています
が、これらのハイパーバイザードライバーすべてが同じ機能を持ってい
る訳ではなく、異なるチューニング要件もドライバー毎に異なります。
注記
現在実装されているハイパーバイザーは、OpenStack ドキュ
メントの Web サイトに一覧化されています。the Hypervisor
support matrix page にある OpenStack wiki に、OpenStack
Compute (nova) ハイパーバイザーのドライバーにおけるさま
ざまな機能の組み合わせ表があります。
ここで言っておきたいことは、オプションが存在するからといって、そ
のオプションがあなたが選んだドライバーに関係するとは限らないとい
うことである。通常は、ドキュメントには、その設定オプションが適用
されるドライバーについての記載があります。
261
OpenStack 運用ガイド
February 1, 2016
定期タスクの実装
様々な OpenStack プロジェクトに共通する別の考え方として、周期的タ
スク (periodic task) があります。周期的タスクは伝統的な Unix シス
テムの cron ジョブに似ていますが、OpenStack プロセスの内部で実行
されます。例えば、OpenStack Compute (nova) はローカルキャッシュか
らどのイメージを削除できるかを決める必要がある際に、これを行うた
めに周期的タスクを実行します。
周期的タスクは、OpenStack が使用しているスレッドモデルにおける制
限を理解する上で重要です。OpenStack は Python の協調スレッドを使
用しています。このことは、何か長く複雑な処理が実行された場合、そ
の処理が自発的に別の協調スレッドに実行を譲らない限り、そのプロセ
ス内の他のタスクの実行が停止されることを意味します。
これの具体的な例が nova-compute プロセスです。libvirt でイメージ
キャッシュを管理するために、nova-compute はイメージキャッシュの
内容をスキャンする周期的なプロセスを用意します。このスキャンの中
で、各イメージのチェックサムを計算し、チェックサムが nova-compute
が期待する値と一致することを確認します。しかしながら、イメージは
非常に大きく、チェックサムを生成するのに長い時間がかかる場合があ
ります。このことがバグとして報告され修正される前の時点では、novacompute はこのタスクで停止し RPC リクエストに対する応答を停止して
しまっていました。この振る舞いは、インスタンスの起動や削除などの
操作の失敗としてユーザーに見えていました。
これから分かることは、OpenStack のプロセスが少しの間「停止」した
ように見えて、それから通常通りの動作を継続するような状況を見つけ
た場合、周期的タスクが問題になっていないかを確認すべきだというこ
とです。取りうる一つの方法は、間隔を 0 に設定して周期的タスクを無
効にすることです。また、周期的タスクの実行頻度を設定することもで
きます。デフォルトとは異なる頻度で周期的タスクを実行する方が意味
がある場合もあります。
実行頻度は周期的タスク別に定義されています。したがって、OpenStack
Compute (nova) ではすべての周期的タスクは無効にするためには、多く
の設定オプションを 0 に設定する必要があることでしょう。現在のとこ
ろ 0 に設定する必要がある設定オプションの一覧は以下のとおりです。
• bandwidth_poll_interval
• sync_power_state_interval
• heal_instance_info_cache_interval
262
OpenStack 運用ガイド
February 1, 2016
• host_state_interval
• image_cache_manager_interval
• reclaim_instance_interval
• volume_usage_poll_interval
• shelved_poll_interval
• shelved_offload_time
• instance_delete_interval
設定オプションを 0 に設定するには、nova.conf に
image_cache_manager_interval=0 のような行を入れてください。
上記のリストはリリース間で変更されることもあります。最新の情報に
ついては設定ガイドを参照してください。
設定に関する個別のトピック
この節では、調整を検討した方がよい設定オプションの個別の具体例を
扱います。決して完全なリストではありません。
Compute、Networking、Storage のセキュリティ設
定
OpenStack Security Guide は、OpenStack クラウドのセキュア化に関
する深い考察を提供します。SSL/TLS、鍵管理、PKI および証明書管理、
データ転送およびプライバシーの懸念事項、コンプライアンスなど。
高可用性
OpenStack High Availability Guide は、システム停止につながる可能
性がある、単一障害点の削減に向けた提案があります。完全に規定され
たドキュメントではありませんが、停止時間やデータ損失を避けるため
の方法や技術を提供しています。
IPv6 サポートの有効化
neutron IPv6 Subteam at work を確認して、進行状況を確認し続けられ
ます。
263
OpenStack 運用ガイド
February 1, 2016
セットアップした設定を変更することにより、ネットワークに novanetwork を使用している場合に、IPv6 をセットアップできます。テ
ストされたセットアップ環境が FlatDHCP とマルチホストの設定向け
にドキュメント化されています。重要な点は、radvd を正常に実行さ
れたと、nova-network が考えるようにすることです。設定全体の詳細
は、Cybera のブログ記事 “An IPv6 enabled cloud” にあります。
Object Storage の地理的考慮事項
オブジェクトストレージサーバーのグローバルクラスターが、すべての
サポートされているリリースで利用できます。自然災害の発生時に備え
て地理的な地域をまたがって確実に複製するために、またユーザーが最
も近いデータセンターに基づいてより迅速にオブジェクトにアクセスで
きるようにするために、これらのグローバルクラスターを導入できるで
しょう。各クラスターに 1 つのゾーンを持つデフォルトのリージョン
を設定します。しかし、より多くのゾーンを追加して、より多くのゾー
ンを処理するリングを構築するので、お使いのネットワーク (WAN) が、
ゾーン間の追加リクエストとレスポンスの負荷を処理できることを確認
してください。詳細は Geographically Distributed Clusters にあるド
キュメントを参照してください。
264
OpenStack 運用ガイド
February 1, 2016
第18章 アップグレード
アップグレード前の考慮事項 ................................. 265
アップグレード手順 ......................................... 269
失敗したアップグレードのロールバック ........................ 272
Object Storage 以外は、OpenStack のあるバージョンから別のバージョ
ンにアップグレードすることは非常に難しいことです。本章は運用観点
でいくつかのガイドラインを提供します。これは、基本的なアーキテク
チャー向けにアップグレードを実行する際の考慮すべきことです。
アップグレード前の考慮事項
アップグレードの計画
• 全体的にリリースノートを確認して、新機能、更新された機能、非推
奨の機能について調べてください。バージョン間の非互換を確認して
ください。
• アップグレードによるユーザーへの影響を考慮してください。アップ
グレードプロセスは、ダッシュボードを含む、環境の管理機能を中断
します。このアップグレードを正しく準備する場合、既存のインスタ
ンス、ネットワーク、ストレージは通常通り動作し続けるべきです。
しかしながら、インスタンスがネットワークの中断を経験するかもし
れません。
• お使いの環境をアップグレードする方法を検討します。運用中のイン
スタンスがある状態でアップグレードを実行できます。しかし、これ
は非常に危険なアプローチです。アップグレードの実行中は、ライブ
マイグレーションを使用して、インスタンスを別のコンピュートノー
ドに一時的に再配置することを考慮すべきでしょう。しかしながら、
プロセス全体を通して、データベースの整合性を担保する必要があ
ります。そうでなければ、お使いの環境が不安定になるでしょう。ま
た、ユーザーに十分に注意を促すことを忘れてはいけません。バック
アップを実行するために時間の猶予を与えることも必要です。
• このサービス設定ファイルから構造とオプションを適用して、既存の
設定ファイルにマージすることを検討してください。ほとんどのサー
ビスは、OpenStack Configuration Reference に新しいオプション、
更新されたオプション、非推奨になったオプションがあります。
• すべてのシステムのメジャーアップグレードと同じく、いくつかの理
由により、アップグレードに失敗する可能性があります。データベー
ス、設定ファイル、パッケージなど、お使いの環境をロールバック
265
OpenStack 運用ガイド
February 1, 2016
できるようにしておくことにより、この状況に備えるべきです。お使
いの環境をロールバックするためのプロセス例が「失敗したアップグ
レードのロールバック」 [272]にあります。
• アップグレード手順を作成し、本番環境と同じようなテスト環境を使
用して、全体を評価します。
テスト環境の事前アップグレード
すべて中で最も大切なステップは事前のアップグレードテストです。新
しいバージョンのリリース後すぐにアップグレードする場合、未発見の
バグによってアップグレードがうまくいかないこともあるでしょう。管
理者によっては、最初のアップデート版が出るまで待つことを選ぶ場合
もあります。しかしながら、重要な環境の場合には、リリース版の開発
やテストに参加することで、あなたのユースケースでのバグを確実に修
正することもできるでしょう。
このガイドに記載されているような、理想的なアーキテクチャーに近い
と思われる場合でも、各 OpenStack クラウドはそれぞれ異なります。
そのため、お使いの環境の適切なクローンを使用して、お使いの環境の
バージョン間でアップグレードをテストする必要があります。
しかしながら、言うまでもなく、本番環境と同じ大きさや同一のハード
ウェアを使用する必要がありません。アップグレードするクラウドの
ハードウェアや規模を考慮することは重要です。以下のヒントにより予
測不能なコストを最小化する役に立つでしょう。
自身のクラウドの使用
OpenStack の次のバージョンをテスト
するための一番簡単な方法は、お使い
のクラウドの中に新しい環境をセット
アップすることです。これは奇妙に思
えるかもしれません。とくに、動作中
のコンピュートノードで使用される二
重仮想化です。しかし、お使いの設定
を非常に手軽にテストする確実な方法
です。
パブリッククラウドの利用
お使いのクラウドコントローラーの設
定に関するスケーラビリティーの限界
をテストするために、パブリッククラ
ウドを使用することを考慮します。多
くのパブリッククラウドは時間単位で
課金されます。つまり、多くのノード
を用いてテストしても、それほど費用
がかかりません。
266
OpenStack 運用ガイド
February 1, 2016
同じシステムに別のストレージ
エンドポイントの作成
クラウドに外部ストレージプラグイン
や共有ファイルシステムを使用してい
る場合、2 つ目の共有やエンドポイン
トを作成することにより、正常に動作
するかどうかをテストできます。これ
により、ストレージに新しいバージョ
ンを信頼させる前に、システムをテス
トできるようになります。
ネットワークの監視
より小規模なテストにおいてさえも、
過剰なネットワークパケットを探し
て、コンポーネント間の通信で何かと
てつもなくおかしくなっていないかど
うかを判断します。
テスト環境をセットアップする場合、いくつかの方法を使用できます。
• お使いのプラットフォーム用の OpenStack Installation Guide を使
用して、完全な手動インストールを実行する。最終的な設定ファイル
とインストールされたパッケージをレビューします。
• 変更したパッケージリポジトリー URL を用いて、自動化された設定イ
ンフラストラクチャーのクローンを作成する。
正常に動作するまで設定を変更する。
どのアプローチも有効です。あなたの経験に合うアプローチを使用して
ください。
アップグレード前テストシステムは、設定を動作させるために優れてい
ます。しかしながら、システムの歴史的な使用法やユーザー操作におけ
る違いにより、アップグレードの成否に影響することに注意することが
重要です。
可能ならば、本番環境のデータベースのテーブルをダンプして、この
データを使用して開発環境においてアップグレードをテストすることを
非常に強く推奨します。MySQL バグのいくつかは、新規インストールと
旧バージョンから移行したバージョンのテーブルの間のわずかな違いに
よる、データベース移行中に取り扱われません。これは大規模な実デー
タセットにおいてのみ影響するでしょう。本番環境の停止中に遭遇した
くないでしょう。
人工的なスケールテストは、あくまである程度のものです。クラウドを
アップグレードした後、クラウドのパフォーマンス観点で十分に注意す
る必要があります。
267
OpenStack 運用ガイド
February 1, 2016
アップグレードレベル
アップグレードレベルは、OpenStack Compute の Grizzly リリースで
追加された機能です。これは、さまざまな Compute サービス間の RPC
(メッセージキュー) 通信においてバージョンを固定できます。
この機能は、ライブアップグレードするということになると、パズルの
重要な部品になります。異なるバージョンの OpenStack サービスが問題
なく通信できるようにするために、既存の API バージョンと概念的に同
じになります。
アップグレードレベルに関係なく、X+1 のバージョンの Compute サー
ビスが X バージョンの RPC メッセージを受信して理解できますが、X
+1 のバージョンの RPC メッセージのみを送信できます。例えば、novaconductor プロセスが 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 のバージョンロックを削除でき
ます。
268
OpenStack 運用ガイド
February 1, 2016
アップグレード手順
このセクションは、OpenStack インストールガイドにある、基本的な
2 ノードアーキテクチャーを参照しています。すべてのノードでは、サ
ポートする Linux ディストリビューションで、最新のカーネルとカレン
トのリリースパッケージが実行されている必要があります。
前提
• 確実に一貫性のある状態にするために、アップグレード作業を始める
前にいくつか環境のクリーンアップを実行します。例えば、削除後に
完全削除されていないインスタンスにより、不確実な挙動を引き起こ
す可能性があります。
• 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-kilo; \
done
# for i in keystone glance nova neutron openstack-dashboard cinder heat
ceilometer; \
do cp -r /etc/$i/* $i-kilo/; \
done
注記
さまざまなサービスを処理するために、各ノードでこの
サンプルスクリプトを修正できます。
2.
本番データの完全バックアップを取得します。Kilo 時点では、デー
タベースのダウングレードはサポートされません。以前のバージョ
ンのデータベースに戻す唯一の方法は、バックアップからリストア
することです。
# mysqldump -u root -p --opt --add-drop-database --all-databases >
icehouse-db-backup.sql
269
OpenStack 運用ガイド
February 1, 2016
注記
OpenStack インストールガイド に記載されているよう
に、SQL サーバーの設定の更新を考慮してください。
リポジトリーの管理
すべてのノード:
1.
旧リリースのパッケージのリポジトリーを削除します。
2.
新リリースのパッケージのリポジトリーを追加します。
3.
リポジトリーデータベースを更新します。
各ノードにおけるパッケージのアップグレード
お使いの設定によっては、すべてのパッケージを更新することによ
り、OpenStack 環境の補助サービスを再起動または破壊するかもしれま
せん。例えば、Block Storage ボリューム向けに TGT iSCSI フレーム
ワークを使用していて、それの新しいパッケージがアップグレードに含
まれる場合、パッケージマネージャーが TGT iSCSI サービスを再起動し
て、ボリュームへの接続性に影響を与えるかもしれません。
パッケージマネージャーがさまざまな設定ファイルの更新をプロンプト
で確認する場合、変更を拒否します。パッケージマネージャーは、新
しいバージョンの設定ファイルにサフィックスを追加します。これらの
ファイルの内容を確認して適用することを検討してください。
注記
ipset パッケージが、お使いのディストリビューションにお
いて、依存関係でインストールされていない場合、それを明
示的にインストールする必要があるかもしれません。
サービスの更新
各ノードにおいてサービスをアップグレードする場合、一般的には 1 つ
以上の設定ファイルの変更、サービスの停止、データベーススキーマの
同期、サービスの起動を行います。いくつかのサービスは、違う手順を
必要とします。次のサービスに進む前に、各サービスの動作を検証する
ことを推奨します。
270
OpenStack 運用ガイド
February 1, 2016
サービスをアップグレードすべき順番、一般的なアップグレード手順と
の違いは、以下に示す通りです。
コントローラーノード
1. OpenStack Identity - データベースの同期前に期限切れのトークンを
削除します。
2. OpenStack Image service
3. OpenStack Compute、ネットワークコンポーネントを含む。
4. OpenStack Networking
5. OpenStack Block Storage
6. OpenStack dashboard - 一般的な環境では、ダッシュボードを更新す
るのに必要な作業は Apache HTTP サービスの再起動のみです。
7. OpenStack Orchestration
8. OpenStack Telemetry - 一般的な環境では、Telemetry を更新するた
めに、サービスの再起動のみが必要となります。
9. OpenStack Compute - 設定ファイルを編集して、サービスを再起動し
ます。
10.OpenStack Networking - 設定ファイルを編集して、サービスを再起動
します。
コンピュートノード
• OpenStack Block Storage - Block Storage サービスの更新は、サー
ビスの再起動のみを必要とします。
ストレージノード
• OpenStack Networking - 設定ファイルを編集して、サービスを再起動
します。
最終手順
すべてのディストリビューションにおいて、アップグレードプロセスを
完了するために、いくつかの最終作業を実行する必要があります。
271
OpenStack 運用ガイド
February 1, 2016
1.
コンピュートノードにおいて /etc/nova/nova.conf を変更すること
により、DHCP タイムアウトを元の環境の値に減らして戻します。
2.
すべての .ini ファイルを更新して、お使いの環境で OpenStack リ
リース向けに必要となるパスワードおよびパイプラインと一致させ
ます。
3.
移行後、ユーザーは nova image-list と glance image-list
から異なる結果を見ることになります。ユーザーが一覧コマン
ドにおいて同じイメージをきちんと見るために、/etc/glance/
policy.json と /etc/nova/policy.json ファイルを編集し
て、"context_is_admin": "role:admin" を含めます。これは、プロ
ジェクトのプライベートイメージへのアクセスを制限します。
4.
お使いの環境が正常に動作することを検証します。そして、クラウ
ドが再び通常どおり動作していることをユーザーに知らせます。
失敗したアップグレードのロールバック
アップグレードは、複雑な処理が関連して、失敗する可能性がありま
す。何かしらのアップグレードを実行する前に、本番データの完全バッ
クアップを取得すべきです。Kilo 時点では、データベースのダウング
レードはサポートされません。以前のバージョンのデータベースに戻す
唯一の方法は、バックアップからリストアすることです。
このセクションは、前のリリースの OpenStack にロールバックするため
のガイドを提供します。すべてのディストリビューションは、同様の手
順に従います。
一般的なシナリオは、アップグレードの準備で本番の管理サービスを分
解して、アップグレード手順の一部分を完了して、テスト中には遭遇し
なかった 1 つ以上の問題に遭遇することです。環境を元の「万全な」
状態にロールバックする必要があります。続けて、アップグレードプロ
セスを試行した後、新しいインスタンス、ネットワーク、ストレージボ
リュームなど、何も状態を変更していないことを確実にしてください。
これらの新しいリソースはすべて、データベースがバックアップからリ
ストアされた後、フリーズ状態になります。
この範囲内で、これらの手順を完了して、正常に環境をロールバックす
る必要があります。
1. 設定ファイルをロールバックします。
2. バックアップからデータベースを
3. パッケージをロールバックします。
272
OpenStack 運用ガイド
February 1, 2016
リストアするために必要なバックアップがあることを確認すべきです。
ディストリビューションは、ダウングレードよりもアップグレードをテ
ストすることにかなりの労力をかける傾向があるため、ローリングバッ
クアップグレードは扱いにくいプロセスです。失敗したダウングレード
は、失敗したアップグレードよりトラブルシューティングと解決に非常
により多くの労力を必要とします。失敗したアップグレードを前に進め
続けるリスク、ロールバックするリスクを比較して重み付けすることだ
けができます。一般的に、かなり最後の選択肢としてロールバックを検
討してください。
以下の手順は、Ubuntu 向けに記載しています。少なくとも 1 つの本番
環境で動作しましたが、すべての環境で動作するとは限りません。
ロールバック方法
1.
すべての OpenStack サービスを停止します。
2.
アップグレード作業中に作成した、設定ディレクトリーのバック
アップの中身を /etc/<service> にコピーします。
3.
アップグレードプロセス中に mysqldump コマンドを用いて作成し
た、RELEASE_NAME-db-backup.sql バックアップファイルからデータ
ベースを復元します。
# mysql -u root -p < RELEASE_NAME-db-backup.sql
4.
OpenStack パッケージをダウングレードします。
警告
パッケージのダウングレードは、かなり最も複雑な手順
です。ディストリビューション、システム管理全体に非
常に依存します。
a.
お使いの環境にインストールされている OpenStack パッケー
ジを判断します。dpkg --get-selections コマンドを使用し
ます。OpenStack パッケージをフィルターします。再びフィル
ターして、明示的に deinstall 状態になっているパッケージを
省略します。最終出力をファイルに保存します。例えば、以下
のコマンドは、keystone、glance、nova、neutron、cinder を
持つコントローラーノードを取り扱います。
# dpkg --get-selections | grep -e keystone -e glance -e nova -e
neutron \
-e cinder | grep -v deinstall | tee openstack-selections
cinder-api
install
cinder-common
install
273
OpenStack 運用ガイド
February 1, 2016
cinder-scheduler
cinder-volume
glance
glance-api
glance-common
glance-registry
neutron-common
neutron-dhcp-agent
neutron-l3-agent
neutron-lbaas-agent
neutron-metadata-agent
neutron-plugin-openvswitch
neutron-plugin-openvswitch-agent
neutron-server
nova-api
nova-cert
nova-common
nova-conductor
nova-consoleauth
nova-novncproxy
nova-objectstore
nova-scheduler
python-cinder
python-cinderclient
python-glance
python-glanceclient
python-keystone
python-keystoneclient
python-neutron
python-neutronclient
python-nova
python-novaclient
install
install
install
install
install
install
install
install
install
install
install
install
install
install
install
install
install
install
install
install
install
install
install
install
install
install
install
install
install
install
install
install
注記
サーバーの種類に応じて、パケット一覧の内容や順
番がこの例と異なるかもしれません。
b.
apt-cache policy コマンドを使用して、バージョンを戻すため
に利用できるパッケージのバージョンを確認できます。Grizzly
のリポジトリーを削除した場合、それらを再インストールし
て、apt-get update を実行する必要があります。
# apt-cache policy nova-common
nova-common:
Installed: 1:2013.2-0ubuntu1~cloud0
Candidate: 1:2013.2-0ubuntu1~cloud0
Version table:
*** 1:2013.2-0ubuntu1~cloud0 0
500 http://ubuntu-cloud.archive.canonical.com/ubuntu/
274
OpenStack 運用ガイド
February 1, 2016
precise-updates/havana/main amd64 Packages
100 /var/lib/dpkg/status
1:2013.1.4-0ubuntu1~cloud0 0
500 http://ubuntu-cloud.archive.canonical.com/ubuntu/
precise-updates/grizzly/main amd64 Packages
2012.1.3+stable-20130423-e52e6912-0ubuntu1.2 0
500 http://us.archive.ubuntu.com/ubuntu/
precise-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu/
precise-security/main amd64 Packages
2012.1-0ubuntu2 0
500 http://us.archive.ubuntu.com/ubuntu/
precise/main amd64 Packages
これにより、パッケージの現在インストールされているバー
ジョン、候補となる最新バージョン、各バージョンを含むリポ
ジトリーにある全バージョンを把握できます。適切な Grizzly
バージョン、この場合 1:2013.1.4-0ubuntu1~cloud0 を探しま
す。このパッケージ一覧から手動で探し当てる手順は、むしろ
退屈で間違えやすいです。この手順を支援するために、以下の
スクリプトを使用することを検討すべきです。
# for i in `cut -f 1 openstack-selections | sed 's/neutron/quantum/
;'`;
do echo -n $i ;apt-cache policy $i | grep -B 1 grizzly |
grep -v Packages | awk '{print "="$1}';done | tr '\n' ' ' |
tee openstack-grizzly-versions
cinder-api=1:2013.1.4-0ubuntu1~cloud0
cinder-common=1:2013.1.4-0ubuntu1~cloud0
cinder-scheduler=1:2013.1.4-0ubuntu1~cloud0
cinder-volume=1:2013.1.4-0ubuntu1~cloud0
glance=1:2013.1.4-0ubuntu1~cloud0
glance-api=1:2013.1.4-0ubuntu1~cloud0
glance-common=1:2013.1.4-0ubuntu1~cloud0
glance-registry=1:2013.1.4-0ubuntu1~cloud0
quantum-common=1:2013.1.4-0ubuntu1~cloud0
quantum-dhcp-agent=1:2013.1.4-0ubuntu1~cloud0
quantum-l3-agent=1:2013.1.4-0ubuntu1~cloud0
quantum-lbaas-agent=1:2013.1.4-0ubuntu1~cloud0
quantum-metadata-agent=1:2013.1.4-0ubuntu1~cloud0
quantum-plugin-openvswitch=1:2013.1.4-0ubuntu1~cloud0
quantum-plugin-openvswitch-agent=1:2013.1.4-0ubuntu1~cloud0
quantum-server=1:2013.1.4-0ubuntu1~cloud0
nova-api=1:2013.1.4-0ubuntu1~cloud0
nova-cert=1:2013.1.4-0ubuntu1~cloud0
nova-common=1:2013.1.4-0ubuntu1~cloud0
nova-conductor=1:2013.1.4-0ubuntu1~cloud0
nova-consoleauth=1:2013.1.4-0ubuntu1~cloud0
nova-novncproxy=1:2013.1.4-0ubuntu1~cloud0
nova-objectstore=1:2013.1.4-0ubuntu1~cloud0
275
OpenStack 運用ガイド
February 1, 2016
nova-scheduler=1:2013.1.4-0ubuntu1~cloud0
python-cinder=1:2013.1.4-0ubuntu1~cloud0
python-cinderclient=1:1.0.3-0ubuntu1~cloud0
python-glance=1:2013.1.4-0ubuntu1~cloud0
python-glanceclient=1:0.9.0-0ubuntu1.2~cloud0
python-quantum=1:2013.1.4-0ubuntu1~cloud0
python-quantumclient=1:2.2.0-0ubuntu1~cloud0
python-nova=1:2013.1.4-0ubuntu1~cloud0
python-novaclient=1:2.13.0-0ubuntu1~cloud0
注記
これらの手順を手動で続けることを決定した場合、
適切なところにある neutron を quantum に変更す
ることを忘れないでください。
c.
apt-get install コマンドに <package-name>=<version> を
指定して、各パッケージの特定のバージョンをインストー
ルします。前の手順にあるスクリプトは、利便性のために
package=version のペアの一覧を作成しました。
# apt-get install `cat openstack-grizzly-versions`
この手順は、ロールバックの手順を完了します。アップグレー
ドするリリースのリポジトリーを作成し、apt-get update を実
行して、環境をロールバックすることになった問題を解決する
まで、偶然アップグレードすることを防ぎます。
276
OpenStack 運用ガイド
February 1, 2016
付録A 事例
目次
NeCTAR .....................................................
MIT CSAIL ..................................................
DAIR .......................................................
CERN .......................................................
277
278
279
280
この付録ではコミュニティからを事例をいくつか紹介します。これら
では通常より多くの技術的詳細情報が提供されています。他の事例は
OpenStack ウェブサイト で探して下さい。
NeCTAR
利用者：オーストラリアの公的資金による研究部門からの研究者。用途
は、シンプルな Web サーバー用のインスタンスから高スループットコン
ピューティング用の数百のコア使用まで、多種多様な専門分野に渡りま
す。
デプロイ
OpenStack Compute セルを使用して、NeCTAR Research Cloud は８サイ
トに及び、１サイトあたり約4,000コアがあります。
各サイトは（OpenStack Compute のセル設定におけるリソースセルとし
て）異なる設定で実行されています。数サイトは複数データセンター
に渡り、コンピュートノード外のストレージを共有ストレージで使用し
ているサイトもあれば、コンピュートノード上のストレージを非共有型
ファイルシステムで使用しているサイトもあります。各サイトは Object
Storage バックエンドを持つ Image service をデプロイしています。
中央の Identity、dashboard、Compute API サービスが使用されてい
ます。dashboard へのログインが Shibboleth の SAML ログインのトリ
ガーになり、SQL バックエンドの Identity サービスのアカウントを作
成します。Object Storage Global Cluster は、いくつかの拠点をまた
がり使用されます。
コンピュートノードは 24〜48コアがあり、１コアあたり 4GB 以上の
RAM があり、１コアあたり約 40GB 以上の一時ストレージがあります。
277
OpenStack 運用ガイド
February 1, 2016
全サイトは Ubuntu 14.04 をベースにしており、ハイパーバイザとして
KVM を使用しています。使用している OpenStack のバージョンは基本的
に安定バージョンであり、5〜10%のコードが開発コードからバックポー
トされたか、修正されています。
情報源
• OpenStack.org ケーススタディー
• NeCTAR-RC GitHub
• NeCTAR Web サイト
MIT CSAIL
利用者：MIT Computer Science and Artificial Intelligence Lab から
の研究者。
デプロイ
CSAIL クラウドは現在 64 物理ノード、768 物理コア、3,456 GB のメモ
リがあります。クラウドリソースがコンピュータリソースに焦点をあて
ているため、永続データストレージの大部分は、クラウド外の NFS 上に
あります。40 以上のプロジェクトに 130 以上のユーザーがいます。一
般的に、300 〜 400 インスタンスで 2,000 〜 2,500 仮想 CPU が動作
しています。
最初は、Ubuntu 12.04 に OpenStack Essex を導入しました。FlatDHCP
マルチホストネットワークを使用しています。
ソフトウェアスタックは Ubuntu 12.04 LTS と Ubuntu Cloud Archive
からの OpenStack Havana です。KVM がハイパーバイザで、FAI と
Puppet を設定管理に使用してデプロイされています。FAI と Puppet の
組み合わせはOpenStack のみならず研究所全体で使用されています。単
一のクラウドコントローラーノードがあり、これはネットワークコント
ローラーとしても動作しますが、他のコンピュータ・ハードウェアはコ
ンピュートノードに使用されています。
ホストアグリゲートとインスタンス種別の追加スペックが使用され、2
種類の割り当て倍率を提供します。私たちが使用するデフォルトのリ
ソース割り当ては、4:1 CPU と 1.5:1 RAM です。コンピュート中心の
処理は、cpu_ratio と ram_ratio をどちらも 1.0 に設定されている、
オーバーサブスクライブしていないホストを必要とするインスタンス種
別を使用します。コンピュートノードでハイパースレッディングを有
278
OpenStack 運用ガイド
February 1, 2016
効化しているので、これは CPU スレッドごとに 1 つの仮想 CPU、また
は、物理 CPU ごとに 2 つの仮想 CPU を提供します。
2013 年 8 月に Grizzly へとアップグレードしたときに、OpenStack
Networking に移行しました。コンピュートノードは、2 個の GbE NIC
を持ち、IPMI 管理専用のマネジメントカードを持ちます。1 つの NIC
は、ノード間通信のために使用されます。もう 1 つは、OpenStack が
管理する VLAN のトランクポートとして使用されます。コントローラー
ノードは、パブリック IP 通信のために、ボンドした 2 つの 10 GbE
NICを持ちます。イメージがこのポート経由で使用されるため、ビッグ
パイプがここで使用されます。また、イメージストレージとデータベー
スのバックエンドとなる iSCSI ストレージに接続するためにも使用さ
れます。コントローラーノードは、OpenStack が管理する VLAN 通信の
ためにトランクモードで使用される GbE NIC も持ちます。このポート
は、DHCP エージェントとメタデータプロキシーへの通信も処理します。
インスタンスが既存のパブリックにアクセスできるネットワークに直接
接続され、デフォルトゲートウェイとして既存の物理ルーターを使用
する、プロバイダー VLAN ネットワークを使用した、より古い novanetwork のマルチホスト HA セットアップに近づいています。このこと
は、ネットワークコントローラーが停止した場合に、実行中のインスタ
ンスがネットワークを利用可能であり続けること、単独の Linux ホスト
が通信のボトルネックにならないことを意味します。すべてのインスタ
ンスの IPv4 アドレスを十分に提供でき、NAT が必要なく、Floating IP
アドレスを使用しないので、これを実行できます。単独の汎用的なパブ
リックネットワークをすべてのプロジェクトに提供し、必要に応じてプ
ロジェクト単位に追加で既存の VLAN を提供します。個々のプロジェク
トは、自身のプライベートな GRE ネットワークを作成することもできま
す。
情報源
• CSAIL ホームページ
DAIR
利用者：DAIR は新しい情報通信技術（ICT）と他のデジタル技術を開
発・評価するための CANARIE ネットワークを活用した統合仮想環境で
す。このシステムは、先進的なネットワーク、クラウドコンピューティ
ング、ストレージといったデジタルインフラから構成されており、革新
的な ICT アプリケーション、プロトコル、サービス、の開発・評価環境
の作成、デプロイのスケールに関する実験の実施、市場へのより早期の
投入促進を目的としています。
279
OpenStack 運用ガイド
February 1, 2016
デプロイ
DAIR はカナダの2つの異なるデータセンタ（１つはアルバータ州、もう
1つはケベック州）でホスティングされています。各拠点にはそれぞれク
ラウドコントローラがありますが、その１つが「マスター」コントロー
ラーとして、認証とクォータ管理を集中して行うよう設計されていま
す。これは、特製スクリプトと OpenStack の軽微な改造により実現され
ています。DAIR は現在、Havana で運営されています。
オブジェクトストレージ用に、各リージョンには swift 環境がありま
す。
各リージョンでは、ブロックストレージとインスタンスストレージの両
方でNetApp アプライアンスが使用されています。これらのインスタン
スを NetApp アプライアンスから Ceph または GlusterFS といった分散
ファイルシステム上に移動する計画があります。
ネットワーク管理は VlanManager が広範囲に使用されています。全ての
サーバーは２つの冗長化（bonding）された 10GbE NIC があり、２つの
独立したスイッチに接続されています。DAIR はクラウドコントローラー
が全コンピュートノード上の全インスタンス用のゲートウェイとなる、
単一ノードのネットワーキングを使用する設定がされています。内部の
OpenStack 通信（例：ストレージ通信）はクラウドコントローラーを経
由していません。
情報源
• DAIR ホームページ
CERN
利用者: 高エネルギー物理学の研究を指揮している CERN (European
Organization for Nuclear Research) の研究者。
デプロイ
この環境は、大部分は Red Hat 互換の Scientific Linux 6 ベースで
す。主なハイパーバイザとして KVM を使用していますが、一方 Windows
Server 2008 上の Hyper-V を使用したテストも進行中です。
我々は Compute、Image service、Identity、dashboard の設定に
Puppet Labs のOpenStack モジュールを使用しています。Puppet は、イ
280
OpenStack 運用ガイド
February 1, 2016
ンスタンスの設定に幅広く使用されます。Foreman は、レポートおよび
インスタンスの配備の GUI として使用されます。
ユーザとグループは Active Directory で管理され、LDAP を使用して
Identity にインポートされます。CLI は nova と euca2ools が使用可
能です。
CERN では現在 3 つのクラウドが稼働しており、合計で約 4,700 台の
コンピュートノード、120,000 コアがあります。 CERN IT クラウドは
2015年までに 300,000 コアにまで拡張される予定です。
情報源
• “OpenStack in Production: A tale of 3 OpenStack Clouds”
• “Review of CERN Data Centre Infrastructure”
• “CERN Cloud Infrastructure User Guide”
281
OpenStack 運用ガイド
February 1, 2016
付録B ハリウッド^H^H^H^H^Hクラ
ウドナイトメア
目次
二重 VLAN ..................................................
「あの問題」 ...............................................
イメージの消失 .............................................
バレンタインデーのコンピュートノード大虐殺 ..................
ウサギの穴に落ちて .........................................
Havana 死者の幽霊 ..........................................
283
286
288
290
292
293
ここにあるのは、OpenStack クラウドオペレータ達の苦闘の抜粋であ
る。これを読み、彼らの叡智を学ぶが良い。
二重 VLAN
私は、新しい OpenStack クラウドのセットアップをするため、カナダの
ブリティッシュコロンビア州ケロウナの現地にいた。デプロイ作業は完
全に自動化されていた。Cobbler が物理マシンに OS をデプロイし、そ
れを起動し、その後は Puppet が引き継いだ。私は練習で幾度もデプロ
イシナリオを実行してきたし、もちろん全て正常であった。
ケロウナの最終日、私はホテルから電話会議に参加していた。その裏
で、私は新しいクラウドをいじっていた。私はインスタンスを１つ起動
し、ログインした。全ては正常に思えた。退屈しのぎに、私は ps aux
を実行したところ、突然そのインスタンスがロックアップしてしまっ
た。
これは単なる１回限りの問題と思ったので、私はインスタンスを削除し
て、新しいインスタンスを起動した。その後電話会議は終了し、私は
データセンターを離れた。
データセンターで、私はいくつかの仕事を済ませると、ロックアップの
ことを思い出した。私は新しいインスタンスにログインし、再度 ps aux
を実行した。コマンドは機能した。ふぅ。私はもう一度試してみること
にした。今度はロックアップした。
何度か問題が再現した後、私はこのクラウドが実は問題を抱えていると
いう不幸な結論に至った。更に悪いことに、私がケロウナから出発する
時間になっており、カルガリーに戻らなければならなかった。
283
OpenStack 運用ガイド
February 1, 2016
どこかであなたはこのような障害調査を行ったことがあるだろうか？イ
ンスタンスはコマンドを打つ度に全くランダムにロックアップしてしま
う。元になったイメージの問題か？No－全てのイメージで同じ問題が発
生する。コンピュートノードの問題か？No－全てのノードで発生する。
インスタンスはロックアップしたのか？No！新しいSSH接続は問題なく機
能する！
我々は助けを求めた。ネットワークエンジニアは、これは MTU の問題で
はないかというのだ。素晴らしい！MTU! 事態は動き始めた! MTU とは何
で、何故それが問題になるのだろうか？
MTU とは最大転送単位（Maximum Transmission Unit）である。これは、
各パケットに対してそのインターフェースが受け取る最大バイト数を指
定する。もし２つのインターフェースが異なる MTU であった場合、バイ
トは尻切れトンボとなって変なことが起こり始める…例えばセッション
のランダムなロックアップとか。
注記
すべてのパケットサイズが 1500 に収まるわけではない。SSH
経由の ls コマンド実行は 1500 バイト未満のサイズのパ
ケット１つで収まるかもしれない。しかし、 ps aux のよう
に多大な出力を行うコマンドを実行する場合、1500 バイトの
パケットが複数必要とある。
OK。では MTU の問題はどこから来るのか？なぜ我々は他のデプロイでこ
の問題に遭遇しなかったのか？この状況は何が新しいのか？えっと、新
しいデータセンター、新しい上位リンク、新しいスイッチ、スイッチの
新機種、新しいサーバー、サーバーの新機種…つまり、基本的に全てが
新しいものだった。素晴らしい。我々は様々な領域で MTU の増加を試し
てみた。スイッチ、コンピュータのNIC、インスタンスの仮想NIC、デー
タセンターの上位リンク用のインターフェースのMTUまでいじってみた。
いくつかの変更ではうまくいったが、他はダメだった。やはり、この線
の障害対策はうまくいってないようだった。我々はこれらの領域のMTUは
変更すべきではないようだ。
結局、我々のネットワーク管理者（Alvao）と私自身は４つのターミナル
ウィンドウ、１本の鉛筆と紙切れを持って座った。１つのウインドウで
我々は ping を実行した。２つ目のウインドウではクラウドコントロー
ラー上の tcpdump、３つ目ではコンピュートノード上の tcpdump、４つ
目ではインスタンス上の tcpdump を実行した。前提として、このクラウ
ドはマルチノード、非マルチホスト構成である。
１つのクラウドコントローラーが全コンピュートノードのゲートウェイ
の役割を果たしていた。ネットワーク設定には VlanManager が使われて
284
OpenStack 運用ガイド
February 1, 2016
いた。これは、クラウドコントローラーと全コンピュートノードで、各
OpenStack プロジェクトが異なる VLAN を持つことを意味する。パケッ
トサイズ変更のため、ping の -s オプションを使用していた。パケッ
トが全て戻ってくる時もあれば、パケットが出ていったきり全く戻って
来ない時もあれば、パケットはランダムな場所で止まってしまう時もあ
る、という状況だった。tcpdump を変更し、パケットの16進ダンプを表
示するようにした。外部、コントローラー、コンピュート、インスタン
スのあらゆる組み合わせの間で ping を実行した。
遂に、Alvaro が何かを掴んだ。外部からのパケットがクラウドコント
ローラーを叩いた際、パケットは VLAN で設定されるべきではない。
我々はこれが正しいことを検証した。パケットがクラウドコントロー
ラーからコンピュートノードに行く際、パケットはインスタンス宛の場
合にのみ VLAN を持つべきである。これもまた正しかった。ping のレス
ポンスがインスタンスから送られる際、パケットは VLAN 中にいるべき
である。ＯＫ。クラウドコントローラーからインターネットにパケット
が戻る際、パケットには VLAN を持つべきではない。ＮＧ。うぉっ。ま
るで パケットの VLAN 部分が削除されていないように見える。
これでは意味が無かった。
このアイデアが我々の頭を駆け巡る間、私はコンピュートノード上でコ
マンドをランダムに叩いていた。
$ ip a
10: vlan100@vlan20: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue
master br100 state UP
「Alvaro、VLAN 上に VLAN って作れるのかい？」
「もしやったら、パケットに余計に４バイト追加になるよ」
やっと事の全容が判明した…
$ grep vlan_interface /etc/nova/nova.conf
vlan_interface=vlan20
nova.conf 中で、vlan_interface は OpenStack が全ての VLAN をア
タッチすべきインターフェースがどれかを指定する。正しい設定はこう
だった。
vlan_interface=bond0
これはサーバーの冗長化された（bonded）NIC であるべきだからだ。
vlan20 はデータセンターが外向けのインターネットアクセス用に我々に
付与した VLAN である。これは正しい VLAN で bond0 にアタッチされて
いる。
285
OpenStack 運用ガイド
February 1, 2016
ミスにより、私は全てのテナント VLAN を bond0 の代わりに vlan20 に
アタッチするよう OpenStack を設定した。これにより１つの VLAN が別
の VLAN の上に積み重なり、各パケットに余分に４バイトが追加され、
送信されるパケットサイズが 1504 バイトになる原因となった。これが
パケットサイズ 1500 のみ許容するインターフェースに到達した際、問
題の原因となったのだった！
全力でこの問題を修正した結果、全てが正常に動作するようになった。
「あの問題」
2012年8月の終わり、カナダ アルバータ州のある大学はそのインフラを
OpenStack クラウドに移行した。幸か不幸か、サービスインから1〜2日
間に、彼らのサーバーの1台がネットワークから消失した。ビッ。いなく
なった。
インスタンスの再起動後、全ては元通りに動くようになった。我々はロ
グを見直し、問題の箇所（ネットワーク通信が止まり、全ては待機状態
になった）を見た。我々はランダムな事象の原因はこのインスタンスだ
と判断した。
数日後、それは再び起こった。
我々はログのセットを両方見直した。頻発したログの１つは DHCP だっ
た。当時、OpenStack はデフォルトでは DHCP リース期間を 1分に設定
していた (現在は 2分)。これは、各インスタンスが固定 IP アドレスを
更新するためにクラウドコントローラー（DHCP サーバー）に接続するこ
とを意味する。幾つかの理由で、このインスタンスはその IP アドレス
を更新できなかった。インスタンスのログとクラウドコントローラー上
のログを突き合わせ、並べてやりとりにしてみた。
1. インスタンスはIPアドレスを更新しようとする。
2. クラウドコントローラーは更新リクエストを受信し、レスポンスを返
す。
3. インスタンスはそのレスポンスを「無視」して、更新リクエストを再
送する。
4. クラウドコントローラーは２度めのリクエストを受信し、新しいレス
ポンスを返す。
5. インスタンスはクラウドコントローラーからのレスポンスを受信しな
かったため、更新リクエストを255.255.255.255に送信し始める。
286
OpenStack 運用ガイド
February 1, 2016
6. クラウドコントローラーは 255.255.255.255 宛のリクエストを受信
し、３番めのレスポンスを返す。
7. 最終的に、インスタンスはIPアドレス取得を諦める。
この情報により、我々は問題が DHCP 実行に起因するものと確信した。
何らかの理由でインスタンスが新しいIPアドレスを取得できず、その結
果IPアドレスがなくなり、インスタンスは自分自身をネットワークから
切り離した、と考えた。
ちょっと Google 検索した結果、これを見つけた。VLAN モードで
の DHCPリースエラー (https://lists.launchpad.net/openstack/
msg11696.html) 。この情報はその後の我々の DHCP 方針の支えになっ
た。
最初のアイデアは、単にリース時間を増やすことだった。もしインスタ
ンスが毎週１回だけIPアドレスを更新するのであれば、毎分更新する場
合よりこの問題が起こる可能性は極端に低くなるだろう。これはこの問
題を解決しないが、問題を単に取り繕うことはできる。
我々は、このインスタンス上で tcpdump を実行して、操作で再びこの現
象に遭遇するか見てみることにした。実際、我々はやってみた。
tcpdump の結果は非常に奇妙だった。一言で言えば、インスタンスが IP
アドレスを更新しようとする前に、まるでネットワーク通信が停止して
いるように見えた。１分間のリース期間で大量の DHCP ネゴシエーショ
ンがあるため、確認作業は困難を極めた。しかし、パケット間のたっ
た数ミリ秒の違いであれ、あるパケットが最初に到着する際、そのパ
ケットが最初に到着し、そのパケットがネットワーク障害を報告した場
合、DHCP より前にネットワーク障害が発生していることになる。
加えて、問題のインスタンスは毎晩非常に長いバックアップジョブを
担っていた。「あの問題」（今では我々はこの障害をこう呼んでいる）
はバックアップが行われている最中には起こらなかったが、（数時間
たっていて）「あの問題」が起こるまであと少しのところだった。
それから何日か過ぎ、我々は「あの問題」に度々遭遇した。我々は「あ
の問題」の発生後、dhclient が実行されていないことを発見した。
今、我々は、それが DHCP の問題であるという考えに立ち戻った。/etc/
init.d/networking restart を実行すると、全ては元通りに実行される
ようになった。
探し続けてきた Google の検索結果が突然得られたという事態をお分か
りだろうか？えっと、それがここで起こったことだ。私は dhclient の
情報と、何故 dhclient がそのリースを更新できない場合に死ぬのか
287
OpenStack 運用ガイド
February 1, 2016
を探していて、我々が遭遇したのと同じ問題についての OpenStack と
dnsmasq の議論の束を突然発見した。
高負荷ネットワークIOとdnsmasqの問題 (http://www.gossamerthreads.com/lists/openstack/operators/18197)
DHCPOFFERが送信されない事による、起動中のインスタンスのIPアド
レスの消失 (http://www.gossamer-threads.com/lists/openstack/
dev/14696)
マジ？Google。
このバグ報告は、すべてに対して重要です: KVMイメージがブリッ
ジネットワークで接続を失う (https://bugs.launchpad.net/ubuntu/
+source/qemu-kvm/+bug/997978)
レポートを読むのは楽しかった。同じ奇妙なネットワーク問題にあった
人々であふれていたが、全く同じ説明はなかった。
つまり、これは qemu/kvm のバグである。
バグ報告を発見すると同時に、同僚が「あの問題」を再現することに成
功した！どうやって？彼は iperf を使用して、インスタンス上で膨大な
ネットワーク負荷をかけた。30分後、インスタンスはネットワークから
姿を消した。
パッチを当てた qemu と再現方法を携えて、我々は「あの問題」を最終
的に解決したかを確認する作業に着手した。インスタンスにネットワー
ク負荷をかけてから丸48時間後、我々は確信していた。その後のことは
知っての通りだ。あなたは、joe へのバグ報告を検索し、私のコメント
と実際のテストを見つけることができる。
イメージの消失
2012年の終わり、Cybera （カナダ アルバータ州にある、サイバーイン
フラのデプロイを監督する権限を持つ非営利団体）が、彼らの DAIR プ
ロジェクト (http://www.canarie.ca/en/dair-program/about) 用に新し
い OpenStack クラウドをデプロイした。サービスインから数日後、ある
コンピュートノードがロックアップした。問題のノードの再起動にあた
り、私は顧客の権限でインスタンスを起動するため、そのノード上で何
のインスタンスがホスティングされていたかを確認した。幸運にも、イ
ンスタンスは１つだけだった。
nova reboot コマンドは機能しなかったので、virsh を使用したが、す
ぐに仮想ディスクが見つからないとのエラーが返ってきた。この場合、
288
OpenStack 運用ガイド
February 1, 2016
仮想ディスクは Glance イメージで、イメージが最初に使用する際に /
var/lib/nova/instances/_base にコピーされていた。何故イメージが見
つからないのか？私はそのディレクトリをチェックし、イメージがない
ことを知った。
私は nova データベースを見直し、nova.instances テーブル中の当該イ
ンスタンスのレコードを見た。インスタンスが使用しているイメージは
virsh が報告したものと一致した。よって、ここでは矛盾は発見されな
かった。
私は Glance をチェックし、問題のイメージがそのユーザの作成したス
ナップショットであることに注目した。最終的に、それはグッドニュー
スだった。このユーザが影響を受けた唯一のユーザだった。
最後に、私は StackTack をチェックし、ユーザのイベントを見直した。
彼らはいくつかのスナップショットを作ったり消したりしていた－あり
そうな操作ではあるが。タイムスタンプが一致しないとはいえ、彼らが
インスタンスを起動して、その後スナップショットを削除し、それが何
故か /var/lib/nova/instances/_base から削除されたというのが私の
結論だった。大した意味は無かったが、それがその時私が得た全てだっ
た。
コンピュートノードがロックアップした原因はハードウェアの問題だっ
たことが判明した。我々はそのハードウェアを DAIR クラウドから取
り外し、修理するよう Dell に依頼した。Dell が到着して作業を開始
した。何とかかんとか（あるいはタイプミス）で、異なるコンピュート
ノードを落としてしまい、再起動した。素晴らしい。
そのノードが完全に起動した際、インスタンスが起動した時に何が起こ
るのかを見るため、私は同じシナリオを実行して、インスタンスを復旧
した。インスタンスは全部で４つあった。３つは起動し、１つはエラー
になった。このエラーは以前のエラーと同じだった。「unable to find
the backing disk.」マジ、何で？
再度、イメージがスナップショットであることが判明した。無事に起動
した他の３インスタンスは標準のクラウドイメージであった。これはス
ナップショットの問題か？それは意味が無かった。
DAIR のアーキテクチャーは /var/lib/nova/instances が共有 NFS マウ
ントであることに注意したい。これは、全てのコンピュートノードがそ
のディレクトリにアクセスし、その中に _base ディレクトリが含まれる
ことを意味していた。その他の集約化エリアはクラウドコントローラー
の /var/log/rsyslog だ。このディレクトリは全コンピュートノードの
全ての OpenStack ログが収集されていた。私は、virsh が報告したファ
イルに関するエントリがあるのだろうかと思った。
289
OpenStack 運用ガイド
February 1, 2016
dair-ua-c03/nova.log:Dec 19 12:10:59 dair-ua-c03
2012-12-19 12:10:59 INFO nova.virt.libvirt.imagecache
[-] Removing base file:
/var/lib/nova/instances/_base/7b4783508212f5d242cbf9ff56fb8d33b4ce6166_10
あっはっは！じゃぁ、OpenStack が削除したのか。でも何故？
Essex で、_base 下の任意のファイルが使用されていないかどうか定期
的にチェックして確認する機能が導入された。もしあれば、OpenStack
Compute はそのファイルを削除する。このアイデアは問題がないように
見え、品質的にも良いようだった。しかし、この機能を有効にすると最
終的にどうなるのか？Essex ではこの機能がデフォルトで無効化されて
いた。そうあるべきであったからだ。これは、Folsom で有効になること
が決定された (https://bugs.launchpad.net/nova/+bug/1029674)。私は
そうあるべきとは思わない。何故なら
何かを削除する操作はデフォルトで有効化されるべきではない。
今日、ディスクスペースは安価である。データの復元はそうではない。
次に、DAIR の共有された /var/lib/nova/instances が問題を助長し
た。全コンピュートノードがこのディレクトリにアクセスするため、全
てのコンピュートノードは定期的に _base ディレクトリを見直してい
た。あるイメージを使用しているインスタンスが１つだけあり、そのイ
ンスタンスが存在するノードが数分間ダウンした場合、そのイメージが
使用中であるという印を付けられなくなる。それゆえ、イメージは使用
中に見えず、削除されてしまったのだ。そのコンピュートノードが復帰
した際、そのノード上でホスティングされていたインスタンスは起動で
きない。
バレンタインデーのコンピュートノード
大虐殺
この物語のタイトルは実際の事件よりかなりドラマティックだが、私は
タイトル中に「バレンタインデーの大虐殺」を使用する機会が再びある
とは思わない（し望まない）。
この前のバレンタインデーに、クラウド中にあるコンピュートノードが
最早動いていないとの警告を受け取った。つまり、出力で、この特定の
ノードの状態が XXX になっていた。
実に奇妙なことだが、私はクラウドコントローラーにログインし、問題
のコンピュートノードに ping と SSH の両方を実行できた。通常、この
290
OpenStack 運用ガイド
February 1, 2016
種の警告を受け取ると、コンピュートノードは完全にロックしていてア
クセス不可になる。
数分間のトラブル調査の後、以下の詳細が判明した。
• 最近、あるユーザがそのノード上で CentOS のインスタンスを起動し
ようとした。
• このユーザはそのノード（新しいノード）上の唯一のユーザだった。
• 私が警告を受け取る直前、負荷率は８に急増した。
• 冗長化された 10Gb ネットワークデバイス(bond0）は DOWN 状態だっ
た。
• 1Gb NICはまだ生きていて、有効だった。
私は bonding ペアの両方の NIC の状態を確認し、両方ともスイッチ
ポートへの通信ができないことを知った。bond 中の各 NIC が異なるス
イッチに接続されていることを知り、私は、各スイッチのスイッチポー
トが同時に死ぬ可能性はまずないと思った。私は 10Gb デュアルポー
ト NIC が死んで、交換が必要だと結論づけた。私は、そのノードがホ
スティングされているデータセンターのハードウェアサポート部門に宛
てたチケットを作成した。私は、それが新しいノードで、他のインスタ
ンスがまだそのノード上でホスティングされていないことを幸運に思っ
た。
１時間後、私は同じ警告を受信したが、別のコンピュートノードだっ
た。拍手。OK、問題は間違いなく現在進行中だ。元のノードと全く同様
に、私は SSH でログインすることが出来た。bond0 NIC は DOWN だった
が、1Gb NIC は有効だった。
そして、最も重要なこと。同じユーザが CentOS インスタンスを作成し
ようとしたばかりだった。何だと？
私はこの時点で完全に混乱した。よって、私はネットワーク管理者に対
して、私を助けられるか聞いてみるためメールした。彼は両方のスイッ
チにログインし、すぐに問題を発見した。そのスイッチは２つのコン
ピュートノードから来たスパニングツリーパケットを検出し、スパニン
グツリーループを回避するため、即時にそれらのポートをダウンさせた
のだ。
Feb 15 01:40:18 SW-1 Stp: %SPANTREE-4-BLOCK_BPDUGUARD: Received BPDU packet
on Port-Channel35 with BPDU guard enabled. Disabling interface. (source mac
fa:16:3e:24:e7:22)
Feb 15 01:40:18 SW-1 Ebra: %ETH-4-ERRDISABLE: bpduguard error detected on
Port-Channel35.
291
OpenStack 運用ガイド
February 1, 2016
Feb 15 01:40:18 SW-1 Mlag: %MLAG-4-INTF_INACTIVE_LOCAL: Local interface PortChannel35 is link down. MLAG 35 is inactive.
Feb 15 01:40:18 SW-1 Ebra: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Port-Channel35 (Server35), changed state to down
Feb 15 01:40:19 SW-1 Stp: %SPANTREE-6-INTERFACE_DEL: Interface Port-Channel35
has been removed from instance MST0
Feb 15 01:40:19 SW-1 Ebra: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Ethernet35 (Server35), changed state to down
彼はスイッチポートを再度有効にしたところ、２つのコンピュートノー
ドは即時に復活した。
不幸にも、この話にはエンディングがない…我々は、なぜ CentOS イ
メージがスパニングツリーパケットを送信し始める原因をいまだ探して
いる。更に、我々は障害時にスパニングツリーを軽減する正しい方法を
調査している。これは誰かが思うより大きな問題だ。スパニングツリー
ループを防ぐことはスイッチにとって非常に重要であるが、スパニング
ツリーが起こった際に、コンピュートノード全体がネットワークから切
り離されることも大きな問題である。コンピュートノードが 100 イン
スタンスをホスティングしていて、そのうち１つがスパニングツリーパ
ケットを送信した場合、そのインスタンスは事実上他の 99 インスタン
スを DDoS（サービス不能攻撃）したことになる。
これはネットワーク業界で進行中で話題のトピックである（特に仮想マ
シンと仮想スイッチで発生する）。
ウサギの穴に落ちて
稼働中のインスタンスからコンソールログを取得可能なユーザはサポー
トの恩恵となる（インスタンスの中で何が起こっているのか何度も確認
できるし、あなたが悩まずに問題を修正することができる）。不幸なこ
とに、過剰な失敗の記録は時々、自らの問題となり得る。
報告が入った。VM の起動が遅いか、全く起動しない。標準のチェック
項目は？nagios 上は問題なかったが、RabbitMQ クラスタの現用系に向
かうネットワークのみ高負荷を示していた。捜査を開始したが、すぐに
RabbitMQ クラスタの別の部分がざるのようにメモリリークを起こしてい
ることを発見した。また警報か？RabbitMQ サーバーの現用系はダウンし
ようとしていた。接続は待機系にフェイルオーバーした。
この時、我々のコントロールサービスは別のチームによりホスティング
されており、我々には現用系サーバー上で何が起こっているのかを調
査するための大したデバッグ情報がなく、再起動もできなかった。この
チームは警報なしで障害が起こったと連絡してきたが、そのサーバーの
再起動を管理していた。１時間後、クラスタは通常状態に復帰し、我々
はその日は帰宅した。
292
OpenStack 運用ガイド
February 1, 2016
翌朝の継続調査は別の同様の障害でいきなり始まった。我々は急いで
RabbitMQ サーバーを再起動し、何故 RabbitMQ がそのような過剰なネッ
トワーク負荷に直面しているのかを調べようとした。nova-api のデバッ
グログを出力することにより、理由はすぐに判明した。tail -f /var/
log/nova/nova-api.log は我々が見たこともない速さでスクロールして
いた。CTRL+C でコマンドを止め、障害を吐き出していたシステムログの
内容をはっきり目にすることが出来た。－我々のユーザの１人のインス
タンスからのシステムログだった。
インスタンスIDの発見後、console.log を探すため /var/lib/nova/
instances にアクセスした。
adm@cc12:/var/lib/nova/instances/instance-00000e05# wc -l console.log
92890453 console.log
adm@cc12:/var/lib/nova/instances/instance-00000e05# ls -sh console.log
5.5G console.log
思った通り、ユーザはダッシュボード上のコンソールログページを定期
的に更新しており、ダッシュボードに向けて5GB のファイルが RabbitMQ
クラスタを通過していた。
我々はユーザを呼び、しばらくダッシュボードの更新を止めるよう申し
入れた。すると、恐ろしい VM の破壊は止み、彼らは大いに喜んだ。そ
の後、我々はコンソールログのサイズを監視するようになった。
今日に至るまで、この問題 (https://bugs.launchpad.net/nova/
+bug/832507) には完全な解決策がないが、我々は次回のサミットの議論
に期待している。
Havana 死者の幽霊
台湾の Academia Sinica Grid Computing Centre の Felix Lee さんが
この話を提供してくれました。
RDO リポジトリーを使用して Grizzly から Havana 2013.2-2 に
OpenStack を単にアップグレードしました。そして、すべてのものが
EC2 API で非常に良く動作していました。
この API は、RunInstances などの特定の EC2 リクエストに対して、高
負荷になり、応答が遅くなることに気がつきました。
Havana における /var/log/nova/nova-api.log の出力:
2014-01-10 09:11:45.072 129745 INFO nova.ec2.wsgi.server
293
OpenStack 運用ガイド
February 1, 2016
[req-84d16d16-3808-426b-b7af-3b90a11b83b0
0c6e7dba03c24c6a9bce299747499e8a 7052bd6714e7460caeb16242e68124f9]
117.103.103.29 "GET
/services/Cloud?AWSAccessKeyId=[something]&Action=RunInstances&ClientToken=
[something]&ImageId=ami-00000001&InstanceInitiatedShutdownBehavior=terminate.
..
HTTP/1.1" status: 200 len: 1109 time: 138.5970151
このリクエストは、処理に 2 分以上かかりました。しかし、同じハード
ウェアとシステム設定を使用している、他の一緒に動いている Grizzly
環境は迅速に実行されました。
Grizzly における /var/log/nova/nova-api.log の出力:
2014-01-08 11:15:15.704 INFO nova.ec2.wsgi.server
[req-ccac9790-3357-4aa8-84bd-cdaab1aa394e
ebbd729575cb404081a45c9ada0849b7 8175953c209044358ab5e0ec19d52c37]
117.103.103.29 "GET
/services/Cloud?AWSAccessKeyId=[something]&Action=RunInstances&ClientToken=
[something]&ImageId=ami-00000007&InstanceInitiatedShutdownBehavior=terminate.
..
HTTP/1.1" status: 200 len: 931 time: 3.9426181
システムリソースを監視しているうちに、EC2 API がこのリクエストを
処理している間、メモリー消費量が非常に増えていることに気が付き
ました。これは、メモリが開放されず、正常に処理されていないと気
づきました。API がこれらのいくつかのリクエストを受け取ると、シ
ステムがメモリー不足になり、スワップを使い始めるまで、メモリー消
費がすぐに大きくなります。各ノードは 48GB メモリーを持ち、"novaapi" プロセスが数分以内にそれらをすべて消費します。これが発生する
と、nova-api サービスを再起動するまで、システム全体が使えなくなる
ほど遅くなります。
そのため、この問題を引き起こしているかもしれない、Havana で EC2
API に行われた変更を自分で探しはじめました。これはバグなのか、回
避策が必要となる通常の動作なのか?
nova (OpenStack Compute) のコードを深堀りすると、私のシステムに影
響を与える可能性がある 2 つの領域を api/ec2/cloud.py で見つけまし
た。
instances = self.compute_api.get_all(context,
search_opts=search_opts,
sort_dir='asc')
sys_metas = self.compute_api.get_all_system_metadata(
context, search_filts=[{'key': ['EC2_client_token']},
{'value': [client_token]}])
294
OpenStack 運用ガイド
February 1, 2016
データベースに 100 万以上のメタデータおよび 300,000 インスタン
スのレコードが「削除済み」または「エラー」状態で含まれていまし
た。MySQL クライアントを使用して、まずバックアップを取得し、デー
タベースをクリーンアップし、いくつか削除を実行することにしまし
た。例えば、以下の SQL コマンドを実行して、1 年以上の間に削除され
たインスタンスの行を削除しました。
mysql> delete from nova.instances where deleted=1 and terminated_at < (NOW()
- INTERVAL 1 YEAR);
古いレコードの削除後、パフォーマンスが大幅に向上しました。新しい
環境は順調に動作しつづけています。
295
OpenStack 運用ガイド
February 1, 2016
付録C ロードマップの取り扱い
目次
利用できる情報 .............................................
ロードマップへの影響 .......................................
ウォッチの観点 .............................................
分散仮想ルーター ...........................................
Modular Layer 2 プラグインによる Open vSwitch プラグインの置
換 .........................................................
新しい API .................................................
OpenStack on OpenStack (TripleO) ...........................
Data processing service for OpenStack (sahara) .............
Bare metal Deployment (ironic) .............................
Database as a Service (trove) ..............................
Message Service (zaqar) ....................................
DNS service (designate) ....................................
スケジューラーの改善 .......................................
298
299
300
302
302
302
303
303
303
303
303
304
304
良いお知らせ: OpenStack は、次に行われることに関する情報を提供す
る際に、前例がないくらいにオープンです。悪いお知らせ: 各リリース
が非常に迅速に行われます。この付録の目的は、参照しておく価値のあ
るページをいくつか紹介すること、次のリリースやその先に起こること
を根拠を持って推測することです。
OpenStack は6ヶ月のリリースサイクルを取っており、通常は4/5
月と10/11月にリリースが行われます。各リリースサイクルの最初
に、OpenStack コミュニティは一ヶ所に集まりデザインサミットを行
います。サミットでは、次のリリースでの機能が議論され、優先度付
けと計画が行われます。図C.1「リリースサイクル図」 [298] は、リ
リースサイクルの一例で、サミットが行われて以降のマイルストーンリ
リース、Code Freeze、String Freeze などが記載されています。マイ
ルストーンはリリースサイクル内での中間リリースで、テスト用にパッ
ケージが作成され、ダウンロードできるようになります。 Code Freeze
では、そのリリースに向けての新機能の追加が凍結されます。String
Freeze は、ソースコード内の文字列の変更が凍結されることを意味しま
す。
297
OpenStack 運用ガイド
February 1, 2016
図C.1 リリースサイクル図
利用できる情報
OpenStack 環境の要望を把握するために使用できる、いくつかの良い情
報源があります。
リリースノートは OpenStack Wiki で管理され、以下で公開されていま
す。
シリーズ
状態
リリース番号
リリース日
Liberty
開発中
2015.2
2012年10月
Kilo
現在の安定版リリー
2015.1
ス、セキュリティアッ
プデート対象
2015年4月
Juno
セキュリティサポート 2014.2
2014年10月16日
Icehouse
エンドオブライフ
2014.1
2014年4月17日
2014.1.1
2014年6月9日
2014.1.2
2014年8月8日
2014.1.3
2014年10月2日
2013.2
2013年4月4日
2013.2.1
2013年12月16日
2013.2.2
2014年2月13日
2013.2.3
2014年4月3日
2013.2.4
2014年9月22日
2013.2.1
2013年12月16日
2013.1
2013年4月4日
2013.1.1
2013年5月9日
2013.1.2
2013年6月6日
Havana
Grizzly
エンドオブライフ
エンドオブライフ
298
OpenStack 運用ガイド
シリーズ
Folsom
Essex
Diablo
February 1, 2016
状態
エンドオブライフ
エンドオブライフ
非推奨
リリース番号
リリース日
2013.1.3
2013年8月8日
2013.1.4
2013年10月17日
2013.1.5
2015年3月20日
2012.2
2012年9月27日
2012.2.1
2012年11月29日
2012.2.2
2012年12月13日
2012.2.3
2013年1月31日
2012.2.4
2013年4月11日
2012.1
2012年4月5日
2012.1.1
2012年6月22日
2012.1.2
2012年8月10日
2012.1.3
2012年10月12日
2011.3
2011年9月22日
2011.3.1
2012年1月19日
Cactus
非推奨
2011.2
2011年4月15日
Bexar
非推奨
2011.1
2011年2月3日
Austin
非推奨
2010.1
2010年10月21日
これは他のいくつかのリソースです。
• 現在の開発中の機能、それらの目標マイルストーンの詳細
• まだ開発中ではないものを含む、すべての機能の一覧
• 直近のデザインサミットからの大まかな設定に関する議論 (etherpad)
• レビュー中の個々のコードの変更の一覧
ロードマップへの影響
OpenStack は、あなたのアイディア (およびコントリビューション) を
本当に歓迎しています。また、実世界のソフトウェアのユーザーからの
フィードバックに高い価値をおきます。機能開発を推進するプロセスに
ついて少し理解することにより、参加でき、あなたの要望を追加できる
かもしれません。
機能追加リクエストは、通常 Etherpad で始まります。Etherpad は共同
編集ツールで、デザインサミットのその機能に関するセッションで議論
を整理するのに使われます。続けて、プロジェクトの Launchpad サイト
に blueprint が作成され、blueprint を使ってよりきちんとした形で機
能が規定されていきます。 この後、blueprint はプロジェクトメンバー
によって承認され、開発が始まります。
299
OpenStack 運用ガイド
February 1, 2016
あなたの機能追加リクエストを新機能として検討してもらうのに一番早
い方法は、アイデアを書いた Etherpad を作成し、デザインサミットの
セッションを提案することです。デザインサミットが終わっている場合
には、blueprint を直接作成することもできます。 Victoria Martínez
の blueprint での開発の進め方についてのブログを是非読んでくださ
い。 OpenStack 開発者のインターンの視点で書かれた記事です。
開発されている次のリリースのロードマップは Releases にあります。
将来のリリースで検討されている機能を確認したり、過去に実装された
機能を見るには、OpenStack Compute (nova) Blueprints, OpenStack
Identity (keystone) Blueprints などの既存の Blueprint やリリース
ノートを見て下さい。
開発ロードマップに影響を与えるために、直接ブループリントに関わる
道以外に、非常に高く評価された別の方法があります。ユーザー調査で
す。http://openstack.org/user-survey にあります。基本的に匿名で、
お使いの環境の詳細、要望を送ることができます。各サイクルで、ユー
ザーコミッティーが結果を分析して、報告書を作成します。具体的な情
報を TC や PTL に提供することを含みます。
ウォッチの観点
OpenStack の中で改善されている領域を注目しつづけたいでしょう。各
プロジェクトのロードマップを「ウォッチ」する最善の方法は、今のマ
イルストーンリリースにおいて取り組むために承認されたブループリン
トを確認することです。1 年に 2 回開催されている OpenStack サミッ
トの PTL によるウェビナーからも知ることができます。
ドライバー品質の改善
主要な品質は、Block Storage、Compute、Networking におけるドライ
バーやプラグインをまたがり発生しています。とくに、プロプライエタ
リーやハードウェア製品を必要とする Compute と Networking のドライ
バー開発者は、開発プロセス中に使用するために、自動化された外部テ
ストシステムを提供する必要があります。
より簡単なアップグレード
より簡単なアップグレードは、OpenStack の開始以来、もっとも要望さ
れている機能の 1 つです。Object Storage 以外のコンポーネントは
「作業中」です。最近のリリースでは、内部メッセージ通信がバージョ
ン付けされています。サービスが理論的には後方互換性の動作まで戻れ
300
OpenStack 運用ガイド
February 1, 2016
ることを目的としています。これにより、古いバージョンをいくつか残
しながら、いくつかのコンポーネントの新しいバージョンを実行できる
ようになります。
さらに、データベースの移行が Turbo Hipster ツールを用いてテストさ
れます。このツールは、実世界のユーザーのデータベースのコピーにお
いて、データベースの移行パフォーマンスをテストします。
これらの変更は、18章アップグレード [265] にある OpenStack アップ
グレードガイドを促進しました。次のリリースにおいて継続的に改善さ
れつづけています。
nova-network の非推奨
Folsom リリースにおいて OpenStack Networking (neutron) により提
供された完全な SDN スタックの導入により、Compute のコンポーネン
トの一部に残っている、初期のネットワークのコードにおける開発の
努力が徐々に少なくなってきました。まだたくさん本番環境で novanetwork を使用していますが、より柔軟で完全な機能を持つ OpenStack
Networking に移行して、そのコードを削除する長期的な計画がありまし
た。
Havana リリース中に nova-network を廃止しようという試みがあり
ました。これは、このガイドで言及した FlatDHCP マルチホスト高可
用性モードなどの同等機能の不足、バージョン間の移行パスの不足、
不十分なテスト、伝統的にサポートされる nova-network のより簡
単なユースケースに使用する場合のシンプルさ、などの理由により中
断されました。甚大な努力によりこれらの心配事を解決してきました
が、nova-network は Juno リリースにおいて廃止されませんでした。さ
らに、Juno においてネットワークごとの設定機能や SR-IOV の追加など
の限定された範囲で、nova-network へのパッチが再び受け入れられてき
ました。
これは、クラウドを設計するときに、重要な判断ポイントを残しま
す。OpenStack Networking は、いくつかのシナリオにおける性能問
題、L3 システムの基本的な高可用性のみなど、少しの制限を持ちます
が、十分使用できる堅牢さを持ちます。nova-network よりも多くの機能
を提供します。しかしながら、より完全な SDN の機能から利益を得る、
より複雑なユースケースを持たない場合、または新しく導入された概念
になじめない場合、nova-network は次の 12 か月間の主要な選択肢であ
り続けるかもしれません。
同様に、既存のクラウドを持ち、nova-network から OpenStack
Networking にアップグレードするつもりである場合、この期間中のアッ
301
OpenStack 運用ガイド
February 1, 2016
プグレードを遅らせる選択肢もあるでしょう。しかしながら、OpenStack
の各リリースは新しい重要なイノベーションをもたらします。ネット
ワークの使用法によらず、各リリースの合理的な時間枠の中でアップグ
レードの計画を始めることが最も良いでしょう。
言及されたとおり、nova-network から neutron にきれいに移行する方
法は現在ありません。適切な移行パスがリリースされるまで、移行を心
に留めておき、そのプロセスに関わることを推奨します。
分散仮想ルーター
OpenStack Networking を長く取り巻く不満の 1 つは、L3 コンポーネン
トの高可用性の不足でした。Juno リリースは、これを解決することを目
指した、分散仮想ルーター (DVR) を導入しました。
初期の目安は、ML2 プラグインと Open vSwitch、1 つのフラット
な外部ネットワークと VXLAN のテナントネットワークなど、基本
的なシナリオに対してこれをうまく実行することです。しかしなが
ら、VLAN、IPv6、Floating IP、大量のノース・サウス通信のシナリオ、
大量のコンピュートノードなどで問題が発生しはじめます。これらは次
のリリースで大幅に改善されることが期待されていますが、特定の問題
におけるバグ報告が強く望まれています。
Modular Layer 2 プラグインによる Open
vSwitch プラグインの置換
Modular Layer 2 プラグインは、OpenStack Networking が複雑な実世
界のデータセンターに見られるさまざまな L2 ネットワーク技術を同
時に利用できるようにするフレームワークです。現在、既存の Open
vSwitch、Linux Bridge、Hyper-V L2 エージェントと一緒に動作しま
す。それらの L2 エージェントと関連付けられたモノリシックなプラグ
インを置き換えて廃止することを意図しています。
新しい API
Compute API の 3 番目のバージョンが幅広く議論され、Havana と
Icehouse のリリースサイクル期間中に取り組まれました。現在の議論
は、V2 API が多くのリリースのために残され、次の API の繰り返しは
v2.1 と表示されます。これは、完全に新しい v3 API ではなく、既存の
v2.0 と同じようなプロパティーを持ちます。これは、すべての API を
評価するための良い機会です。次世代の API が定義されるまでにコメン
302
OpenStack 運用ガイド
February 1, 2016
トを出します。新しいワーキンググループが特別に形成され、OpenStack
API を改善して、設計のガイドラインを作成します。あなたの参加も歓
迎されています。
OpenStack on OpenStack (TripleO)
このプロジェクトは改善を続けています。greenfield の導入のために使
用することを検討する可能性があります。最新のユーザー調査の結果に
よると、大幅な理解が得られたままです。
Data processing service for OpenStack
(sahara)
ビッグデータの問題に対する最も要望された回答です。専門チームが
Hadoop-as-a-Service プロジェクトに安定した進捗を実現しました。
Bare metal Deployment (ironic)
ベアメタル配備は幅広く叫ばれていて、開発が続いています。Juno リ
リースは、OpenStack Bare metal ドライブを Compute プロジェクトの
中に持ち込みました。Kilo において、既存のベアメタルドライバーを目
指していました。現在ベアメタルドライバーを使用している場合、従う
べき具体的なブループリントは Deprecate the bare metal driver で
す。
Database as a Service (trove)
OpenStack コミュニティーは、何回か開発中の database-as-aservice ツールがありました。Icehouse において最初の統合リ
リースがありました。そのリリース以降、高可用な方法でそのま
ま使えるデータベースサーバーを配備できます。最初は MySQL の
みをサポートしていました。Juno では、Mongo (クラスターを含
む)、PostgreSQL、Couchbase、MySQL の複製機能をサポートしまし
た。Kilo では、さらに高度なクラスター機能が導入されました。ま
た、Networking などの他の OpenStack コンポーネントとより統合され
ました。
Message Service (zaqar)
メッセージと通知のキューを提供するサービスが提供されました。
303
OpenStack 運用ガイド
February 1, 2016
DNS service (designate)
長く要望されていたサービスです。配下を収集した OpenStack リ
ソースを関連付けられた DNS エントリーを操作する機能を提供しま
す。designate プロジェクトもリリースされました。
スケジューラーの改善
Compute と Block Storage はどちらも、仮想マシンやボリュームを
配置する場所を決めるためにスケジューラーに頼っています。Havana
では、Compute のスケジューラーが大幅に改善されました。これ
は、Icehouse において支援を受けた Block Storage におけるスケ
ジューラーでした。さらに掘り下げて追跡すると、どちらも取り扱う全
体的なスケジューラーを作成することを目指した、このサイクルを始め
た努力が実を結ぶでしょう。Kilo において実行されたいくつかの作業
は、Gantt projectにあります。
Block Storage の改善
Block Storage は、品質ドライバーの幅広い理解と長く取られている記
録を持つ、安定したプロジェクトと考えられています。このチームは、
よりよいエラー報告、自動探索、シンプロビジョニング機能など、さま
ざまな領域の作業をサミットで議論しました。
Python SDK へ
OpenStack と通信するための効率的な SDK として、さまざまな python*client コードを使用してとても成功していますが、プロジェクト間の
一貫性とドキュメントの入手可能性は満ち欠けがあります。これを取
り除くために、エクスペリエンスを改善するための取り組みが開始され
ました。OpenStack におけるクロスプロジェクトの取り組みは、いくつ
かの失敗から始まった統一クライアントのプロジェクトなど、波乱の歴
史があります。しかしながら、SDK プロジェクトの初期の目安が約束さ
れ、Juno サイクル中に結果を見ることを期待しています。
304
OpenStack 運用ガイド
February 1, 2016
付録D 情報源
目次
OpenStack ..................................................
Cloud (General) ............................................
Python .....................................................
ネットワーク ...............................................
システム管理 ...............................................
仮想化 .....................................................
構成管理 ...................................................
305
305
305
305
306
306
306
OpenStack
• インストールガイド openSUSE 13.2、SUSE Linux Enterprise Server
12 版
• インストールガイド Red Hat Enterprise Linux 7、CentOS 7、Fedora
22
• インストールガイド Ubuntu 14.04 (LTS) Server 版
• OpenStack クラウド管理者ガイド
• OpenStack Cloud Computing Cookbook (Packt Publishing)
Cloud (General)
• “The NIST Definition of Cloud Computing”
Python
• Dive Into Python (Apress)
ネットワーク
• TCP/IP Illustrated, Volume 1: The Protocols, 2/E (Pearson)
• The TCP/IP Guide (No Starch Press)
305
OpenStack 運用ガイド
February 1, 2016
• “A tcpdump Tutorial and Primer”
システム管理
• UNIX and Linux Systems Administration Handbook (Prentice Hall)
仮想化
• The Book of Xen (No Starch Press)
構成管理
• Puppet Labs ドキュメント
• Pro Puppet (Apress)
306
OpenStack 運用ガイド
February 1, 2016
用語集
この用語集は、OpenStack 関連の概念の語彙を定義するために、用語や定義の一覧
を提供します。
OpenStack 用語集に追加する場合、OpenStack の貢献プロセスに沿っ
て、openstack/openstack-manuals リポジトリー をクローンし、ソースファイル
doc/glossary/glossary-terms.xml を更新してください。
数字
6to4
IPv6 パケットを IPv4 ネットワーク経由で送信するための機構。IPv6 に移行
する手段を提供する。
A
絶対制限
ゲスト仮想マシンの超えられない制限。合計メモリー容量、最大仮想 CPU 数、
最大ディスク容量の設定。
アクセス制御リスト
オブジェクトに対する権限の一覧。オブジェクトに対して、アクセスできる
ユーザーやシステムプロセスを特定する。また、特定のオブジェクトに対して
どのような操作が行えるかを定義する。アクセス制御リスト（ACL）の一般的な
項目では対象項目と操作を指定する。例えば、1つのファイルに対して(Alice,
delete)というACL項目が定義されると、Aliceにファイルを削除する権限が与え
られる。
アクセスキー
Amazon EC2 アクセスキーの別名。EC2 アクセスキー参照。
アカウント
Object Storage のアカウントのコンテキスト。Active Directory、/etc/
passwd、OpenLDAP、OpenStack Identity などの認証サービスのユーザーアカウ
ントと混同しないこと。
account auditor
バックエンドの SQLite データベースに問い合わせることにより、指定された
Object Storage のアカウントに、レプリカの欠損やオブジェクトの不整合・破
損がないかを確認する。
307
OpenStack 運用ガイド
February 1, 2016
アカウントデータベース
Object Storage のアカウントと関連メタデータを保持し、アカウントサーバー
がアクセスする、SQLite データベース。
account reaper
アカウントサーバーが削除する印を付けた、アカウントデータベースをスキャ
ンし、削除する、Object Storage のワーカー。
account server
Object Storage にあるコンテナーを一覧表示し、コンテナーの情報をアカウン
トデータベースに保存する。
account service
一覧表示、作成、変更、監査などのアカウントサービスを提供する、Object
Storage のコンポーネント。OpenStack Identity、OpenLDAP、類似のユーザー
アカウントサービスなどと混同しないこと。
アカウンティング
Compute サービスは、イベント通知やシステム使用状況データ機能からアカウ
ンティング情報を提供する。
ACL
「アクセス制御リスト」参照。
アクティブ/アクティブ設定
アクティブ/アクティブ設定を用いた高可用構成の場合、複数のシステムが処理
を一緒に分担する。また、あるシステムが故障した場合、処理が残りのシステ
ムに分散される。
Active Directory
Microsoft が提供する認証サービス。LDAP に基づいている。OpenStack でサ
ポートされる。
アクティブ/パッシブ設定
アクティブ/パッシブ設定を用いた高可用性セットアップでは、故障したシステ
ムを置き換えるために、システムが追加リソースをオンラインにするようセッ
トアップされる。
アドレスプール
プロジェクトに割り当てられ、プロジェクトの仮想マシンインスタンスに使用
できる、固定 IP アドレスと Floating IP アドレスのグループ。
管理 API
認可された管理者がアクセスでき、一般的にエンドユーザーとパブリックなイ
ンターネットがアクセスできない、API コールのサブセット。専用のサービス
(keystone) が存在し、他の API (nova) のサブセットになる可能性がある。
308
OpenStack 運用ガイド
February 1, 2016
管理サーバー
Identity の領域で、管理 API へのアクセスを提供するワーカープロセス。
Advanced Message Queuing Protocol (AMQP)
インフラサービス通信のために OpenStack コンポーネントにより使用される
オープンな標準メッセージングプロトコル。RabbitMQ、Qpid、ZeroMQ により提
供される。
Advanced RISC Machine (ARM)
モバイル機器や組み込みデバイスによく利用される低消費電力 CPU。OpenStack
はサポートしている。
アラート
Compute のサービスは、通知システム経由で警告を送信できる。カスタム通知
ドライバーを作成する機能がある。警告は、送信したり、ダッシュボードに表
示したりできる。
確保
アドレスプールから Floating IP アドレスを取得するプロセス。ゲスト仮想マ
シンインスタンスに固定 IP を関連付けられるようにする。
Amazon Kernel Image (AKI)
仮想マシンのコンテナー形式とディスク形式の両方。Image service によりサ
ポートされる。
Amazon Machine Image (AMI)
仮想マシンのコンテナー形式とディスク形式の両方。Image service によりサ
ポートされる。
Amazon Ramdisk Image (ARI)
仮想マシンのコンテナー形式とディスク形式の両方。Image service によりサ
ポートされる。
Anvil
DevStack という名前のシェルスクリプトベースのプロジェクトを Python に移
植するプロジェクト。
Apache
The Apache Software Foundation は、オープンソースソフトウェアプロジェク
トの Apache コミュニティーをサポートする。これらのプロジェクトは、公共
財のためにソフトウェア製品を提供する。
Apache License 2.0
すべての OpenStack コアプロジェクトは Apache License 2.0 ライセンスの条
件で提供されている。
309
OpenStack 運用ガイド
February 1, 2016
Apache Web Server
現在インターネットにおいて使用されている最も一般的な Web サーバーソフト
ウェア。
API エンドポイント
クライアントが API にアクセスするために通信するデーモン、ワーカーまた
はサービス。API エンドポイントは、認証、売上データ、パフォーマンス統
計、Compute 仮想マシンコマンド、センサスデータなどのような数多くのサー
ビスを提供できます。
API 拡張
いくつかの OpenStack コア API を拡張するカスタムモジュール。
API 拡張プラグイン
Networking プラグインや Networking API 拡張の別名。
API キー
API トークンの別名。
API サーバー
API エンドポイントを提供するデーモンまたはワーカーを実行するあらゆる
ノード。
API トークン
クライアントが要求した操作を実行する権限を持つことを検証するために、API
リクエストに渡され、OpenStack により使用される。
API バージョン
OpenStack では、プロジェクトの API バージョンが URL の一部となる。例:
example.com/nova/v1/foobar。
アプレット
Web ページの中に組み込める Java プログラム。
Application Programming Interface (API)
サービス、アプリケーション、プログラムへのアクセスに使用される仕様の集
合。サービス呼出、各呼出に必要なパラメーター、想定される戻り値を含む。
アプリケーションカタログ
ユーザーがアプリケーションのライフサイクルを管理しながら、アプリケー
ションの抽象的なレベルで合成環境を作成して配備できるよう、アプリケー
ションカタログサービスを提供する OpenStack プロジェクト。このプロジェク
トのコード名は murano。
アプリケーションサーバー
他のソフトウェア部品をネットワーク経由で利用可能にするソフトウェア部
品。
310
OpenStack 運用ガイド
February 1, 2016
Application Service Provider (ASP)
企業や組織を支援する特定のアプリケーションを貸し出す会社が、より低いコ
ストで追加サービスを提供する。
Address Resolution Protocol (ARP)
L3 IP プロトコルが L2 リンクローカルアドレスに解決されるプロトコル。
arptables
Linux カーネルファイアウォールモジュールで ARP パケットフィルタールール
を維持するために使用されるツール。仮想マシン向けのファイアウォールサー
ビスを提供するために、Compute で iptables、ebtables、ip6tables と一緒に
使用される。
割り当て
Compute の Floating IP アドレスと固定 IP アドレスを関連づけるプロセス。
Asynchronous JavaScript and XML (AJAX)
非同期 Web アプリケーションを作成する為にクライアント側で使用される相互
関係のある Web 開発技術の集合。Horizon で広く使用されている。
ATA over Ethernet (AoE)
Ethernet 内をトンネルされるディスクストレージプロトコル。
接続
Networking において、仮想インターフェースや仮想 NIC を L2 ネットワーク
に接続するプロセス。Compute の文脈では、ストレージボリュームをインスタ
ンスに接続するプロセス。
アタッチ（ネットワーク）
論理ポートへのインターフェースIDの紐付け。インターフェースをポートに差
し込む。
監査
システム使用状況データ機能経由で Compute において提供される。
auditor
Object Storage のオブジェクト、コンテナー、アカウントの完全性を検証する
ワーカープロセス。auditor は、Object Storage アカウント auditor、コンテ
ナー auditor、オブジェクト auditor の総称。
Austin
OpenStack の初期リリースのコード名。最初のデザインサミットは、アメリカ
合衆国テキサス州オースチンで開催された。
認可ノード
Object Storage 認可ノードの別名。
311
OpenStack 運用ガイド
February 1, 2016
認証
ユーザー、プロセスまたはクライアントが、秘密鍵、秘密トークン、パスワー
ド、指紋または同様の方式により示されている主体と本当に同じであることを
確認するプロセス。
認証トークン
認証後にクライアントに提供されるテキスト文字列。API エンドポイントに続
くリクエストにおいて、ユーザーまたはプロセスにより提供される必要があ
る。
AuthN
認証サービスを提供する Identity のコンポーネント。
認可
ユーザー、プロセス、クライアントが操作を実行する権限を持つかどうかを確
認すること。
認可ノード
認可サービスを提供する Object Storage ノード。
AuthZ
高レベルの認可サービスを提供する Identity のコンポーネント。
自動 ACK
メッセージ ACK を有効化または無効化する、RabbitMQ 内の設定。デフォルト
で有効。
自動宣言
メッセージ交換がプログラム起動時に自動的に作成されるかどうかを決め
る、Compute の RabbitMQ の設定。
アベイラビリティゾーン
耐障害性のために使用されるエリアを分離する Amazon EC2 の概念。OpenStack
Compute のゾーンやセルと混同しないこと。
AWS
Amazon Web Services。
AWS CloudFormation テンプレート
AWS CloudFormation により、AWS ユーザーは関連するリソース群を作成し、管
理できるようになる。オーケストレーションサービスは CloudFormation 互換
形式 (CFN) をサポートする。
312
OpenStack 運用ガイド
February 1, 2016
B
バックエンド
Compute のボリュームのマウント、デーモンによる iSCSI ターゲットへのデー
タ転送、Object Storage のオブジェクトの完全性検査など、ユーザーから見え
にくい操作や処理。
バックエンドカタログ
クライアントが利用可能な API エンドポイントに関する情報を保存、取得する
のに、Identity サービスのカタログサービスが使用する保存方式。SQL データ
ベース、LDAP データベース、KVS バックエンドなどがある。
バックエンドストア
Object Storage のオブジェクトの一覧、ゲスト仮想マシンの現在の状態、ユー
ザー名の一覧など、サービスに関する情報を保存および取得するために使用さ
れる永続データストア。また、Image service が仮想マシンイメージを取得お
よび保存するために使用する方式。Object Storage、ローカルファイルシステ
ム、S3、HTTP などの選択肢がある。
backup restore and disaster recovery as a service
ファイルシステム、インスタンス、データベースバックアップのバックアッ
プ、リストア、リカバリー用の統合ツールを提供する OpenStack プロジェク
ト。プロジェクト名は freezer。
帯域
インターネットなどの通信リソースにより使用される、利用可能なデータ量。
何かをダウンロードするために使用されるデータの合計量、またはダウンロー
ドするために利用可能なデータの合計量を表す。
barbican
OpenStack の key management サービスのコード名。
bare
仮想マシンイメージ用のコンテナーが存在しないことを意味する、Image
service のコンテナー形式。
Bare metal service
マシンを仮想とみなして、ベアメタルに展開する OpenStack のプロジェクト。
このプロジェクトのコード名は ironic です。
ベースイメージ
OpenStack が提供するイメージ。
Bell-LaPadula モデル
データの機密性、および区分けした情報へのアクセスの制御に注力したセキュ
リティーモデル。このモデルは、エンティティーをサブジェクト (主体) とオ
313
OpenStack 運用ガイド
February 1, 2016
ブジェクト (対象) に分ける。サブジェクトが特定のアクセスモードを許可さ
れるかどうかを判断するために、サブジェクトの権限がオブジェクトの区分と
比較される。権限や区分のスキーマは、格子モデルで表現される。
Benchmark サービス
各 OpenStack コンポーネント、本番の OpenStack 環境のパフォーマンス分析
とベンチマーク向けにフレームワークを提供する OpenStack プロジェクト。こ
のプロジェクトの名前は rally。
Bexar
OpenStack に関連するプロジェクトをグループ化したリリース。2011 年 2 月
に公開された。Compute (nova) と Object Storage (swift) のみが含まれる。
Bexar は OpenStack の 2 番目のコード名。デザインサミットは、アメリカ合
衆国テキサス州サンアントニオで開催された。ベア郡の郡庁所在地。
バイナリ
1 と 0 だけから構成される情報。コンピューターの言語。
ビット
ビットは、2 を基数とする単一のデジタル数値 (0 または 1)。帯域使用量は、
ビット毎秒 (bps) で計測される。
bps
データがある場所から別の場所にどのくらい速く転送されるかの普遍的な計測
基準。
ブロックデバイス
ブロック状態のデータを移動するデバイス。これらのデバイスノードにはハー
ドディスク、CD-ROM ドライブ、フラッシュドライブ、その他のアドレス可能な
メモリの範囲等がある。
ブロックマイグレーション
ユーザー操作によりあるホストから別のホストに切り替え中、わずかな停止時
間でインスタンスを退避するために、KVM により使用される仮想マシンのライ
ブマイグレーションの方法。共有ストレージ不要。Compute によりサポートさ
れる。
Block Storage
ボリューム、ボリュームのスナップショット、ボリューム種別を管理す
る、OpenStack のコアプロジェクト。Block Storage のプロジェクト名は
cinder。
Block Storage API
コンピュート VM 用のブロックストレージの作成、接続、接続解除を行うため
の API で、独立したエンドポイントとして提供される。
314
OpenStack 運用ガイド
BMC
February 1, 2016
ベースボード・マネジメント・コントローラー。IPMI アーキテクチャーにおけ
る管理機能。コンピューターのマザーボードに埋め込まれ、サーバーとして動
作する、特別なマイクロコントローラーである。システム管理ソフトウェアと
プラットフォームハードウェアの間の通信を管理する。
ブータブルディスクイメージ
単独の、ブート可能なファイルとして存在する仮想マシンイメージの形式。
Bootstrap Protocol (BOOTP)
管理サーバーから IP アドレスを取得するために、ネットワーククライアント
により使用されるネットワークプロトコル。FlatDHCP マネージャーや VLAN マ
ネージャー使用時、dnsmasq デーモン経由で Compute で提供される。
Border Gateway Protocol (BGP)
Border Gateway Protocol は、自律システムを接続する、動的ルーティングプ
ロトコルである。インターネットのバックボーンと比べて、このプロトコル
は、より大きなネットワークを形成するために、異なるネットワークを接続す
る。
ブラウザー
コンピューターやデバイスがインターネットにアクセスできる、何らかのクラ
イアントソフトウェア。
ビルダーファイル
リングを再設定するため、深刻な障害の後に最初から再作成するため
に、Object Storage が使用する設定情報を含む。
超過利用
主環境がリソース制限されたとき、要求時に応じてインスタンスを伸縮自在に
構築するために、副環境を利用する慣習。
ボタンクラス
Horizon 内で関連するボタン種別のグループ。仮想マシンを起動、停止、休止
するボタンは、1 つのクラスにある。Floating IP アドレスを関連付ける、関
連付けを解除するボタンは、別のクラスにある。
バイト
1 つの文字を構成するビットの組。通常は 8 ビットで 1 バイトになる。
C
CA
認証局。暗号において、電子証明書を発行するエンティティー。電子証明書
は、証明書の発行先の名前により公開鍵の所有者を証明する。これにより、他
315
OpenStack 運用ガイド
February 1, 2016
の信頼される機関が証明書を信頼できるようになる。また、証明された公開鍵
に対応する秘密鍵による表明を信頼できるようになる。この信頼関係のモデル
において、CA は証明書の発行先と証明書を信頼している機関の両方に対する信
頼された第三者機関である。CA は、多くの公開鍵基盤 (PKI) スキームの特徴
である。
cache pruner
Image service の仮想マシンイメージキャッシュを設定した最大値以下に保つ
プログラム。
Cactus
2011年春に登場した OpenStack 関連のプロジェクトリリース。Compute
(Nova), Object Storage (Swift), Image Service (Glance) が含まれていた。
Cactus は、アメリカ合衆国テキサス州の都市であり、OpenStack の 3 番目の
リリースのコード名である。OpenStack のリリース間隔が 3 か月から 6 か月
になったとき、リリースのコード名が前のサミットと地理的に近いところにな
るように変更された。
CADF
Cloud Auditing Data Federation (CADF) は、監査イベントデータの仕様であ
る。CADF は OpenStack Identity によりサポートされる。
CALL
OpenStack のメッセージキューソフトウェアにより使用される、RPC プリミ
ティブの 1 つ。メッセージを送信し、応答を待つ。
キャパシティ
CPU、ストレージ、ネットワークを含むセルのリソースを定義する。１セルやセ
ル全体に含まれる特定のサービスに適用可能。
capacity cache
Computeバックエンドデータベースのテーブルには現在のワークロード、RAMの
空き量、各ホストで起動しているVMの数が含まれている。VMがどのホストで開
始するのかを決めるのに利用される。
capacity updater
VM インスタンスを監視し、必要に応じて容量キャッシュを更新する通知ドライ
バ。
CAST
OpenStack メッセージキューソフトウェアにより使用される RPC プリミティブ
の 1 つ。メッセージを送信し、応答を待たない。
カタログ
Identity による認証後、ユーザーが利用可能な API エンドポイントの一覧。
316
OpenStack 運用ガイド
February 1, 2016
カタログサービス
ユーザーが Identity で認証後、利用可能な API エンドポイントを一覧表示す
る、Identity のサービス。
ceilometer
Telemetry サービスのプロジェクト名。OpenStack 向けにメータリングと計測
機能を提供する、統合プロジェクト。
セル
親子関係で Compute リソースの論理パーティションを提供する。親セルが要求
されたリソースを提供できない場合、親セルからのリクエストは子セルに渡さ
れる。
セルフォワーディング
親が要求されたリソースを提供できない場合、親セルがリソース要求を子セル
に渡す事を可能にする Compute のオプション。
セルマネージャー
セル内にある各ホストの現在のキャパシティー一覧を持ち、リクエストを適切
にルーティングする、Compute のコンポーネント。
CentOS
OpenStack と互換性のある Linux ディストリビューション。
Ceph
オブジェクトストア、ブロックストア、および POSIX 互換分散ファイルシステ
ムから構成される大規模スケール可能分散ストレージシステム。OpenStack 互
換。
CephFS
Ceph により提供される POSIX 互換ファイルシステム。
認証局
cloudpipe VPN と仮想マシンイメージの復号のために、Compute により提供さ
れる簡単な認証局。
Challenge-Handshake Authentication Protocol (CHAP)
Compute によりサポートされる iSCSI の認証方式。
チャンススケジューラー
利用可能なホストをプールからランダムに選択する、Compute により使用され
るスケジューリング方式。
changes since
Compute API のパラメーター。古いデータと比較するために、新しいデータ群
をダウンロードする代わりに、最後に要求した後に実行された、要求した項目
への変更をダウンロードする。
317
OpenStack 運用ガイド
February 1, 2016
Chef
OpenStack の導入をサポートするオペレーティングシステムの設定管理ツー
ル。
子セル
CPU 時間、ディスクストレージ、メモリ等の要求されたリソースが親セルで利
用不可の場合、リクエストは親セルに紐付けられた子セルに転送される。子セ
ルがリクエストに対応可能な場合、子セルはそのリクエストを処理する。対応
不可の場合、そのリクエストを自分の子セルに渡そうとする。
cinder
ブロックストレージサービスを仮想マシンに提供する、OpenStack のコアプロ
ジェクト。
CirrOS
OpenStack などのクラウドでテストイメージとして使用するために設計された
最小の Linux ディストリビューション。
Cisco neutron プラグイン
UCS や Nexus などの Cisco デバイスや技術の Networking プラグイン。
クラウドアーキテクト
クラウドの作成を計画、設計および監督する人。
クラウドコンピューティング
ネットワーク、サーバー、ストレージ、アプリケーション、サービスなどの設
定可能なコンピューティングリソースの共有プールにアクセスできるモデル。
最小限の管理作業やサービスプロバイダーとのやりとりで、迅速に配備できて
リリースできる。
クラウドコントローラー
クラウドの全体状況を表す Compute コンポーネント群。キュー経由
で、Identity の認証、Object Storage、ノード/ストレージワーカーなどの
サービスと通信する。
クラウドコントローラーノード
ネットワーク、ボリューム、API、スケジューラー、イメージサービスなどを実
行するノード。各サービスは、スケーラビリティーや可用性のために、別々の
ノードに分割することもできます。
クラウドデータ管理インターフェース (CDMI:Cloud Data Management Interface)
クラウドにあるオブジェクトを管理するための RESTful API を定義する SINA
標準。現在 OpenStack ではサポートされていない。
Cloud Infrastructure Management Interface (CIMI)
策定中のクラウド管理の仕様。現在、OpenStack では未サポート。
318
OpenStack 運用ガイド
February 1, 2016
cloud-init
メタデータサービスから取得した、SSH 公開鍵やユーザーデータなどの情報を
使用して、インスタンスの起動後に初期化を実行する、一般的に仮想マシンイ
メージにインストールされるパッケージ。
cloudadmin
Compute RBAC システムにおけるデフォルトのロールの 1 つ。システムの完全
なアクセス権を付与する。
Cloudbase-Init
cloud-init 同様のゲスト初期化機能を提供する Windows プロジェクト。
cloudpipe
プロジェクトごとの VPN を作成するコンピュートのサービス。
cloudpipe イメージ
cloudpipe サーバとしてサービスを行う為の、予め用意された VM イメージ。
本質的には Linux 上で実行される OpenVPN。
Clustering
クラスタリングサービスと、他の OpenStack サービスにより公開された均質な
オブジェクトグループを管理するためのライブラリーを実現する OpenStack プ
ロジェクト。このプロジェクトのコード名は senlin。
CMDB
構成管理データベース。
congress
Governance service を提供する OpenStack プロジェクト。
コマンドフィルター
Compute rootwrap 機能内で許可されるコマンドの一覧。
Common Internet File System (CIFS)
ファイル共有プロトコル。 Microsoft が開発し使用している Server Message
Block (SMB) プロトコルが公開されオープンになったものです。 SMB プロト
コルと同様に、 CIFS は上位レイヤーで動作し、TCP/IP プロトコルを使用しま
す。
コミュニティープロジェクト
OpenStack Foundation で公認されていないプロジェクト。プロジェクトが充分
成功した場合、育成プロジェクトに昇格し、その後コアプロジェクトに昇格す
る事がある。あるいはメインの code trunk にマージされる事もある。
圧縮
特別なエンコーディングによりファイル容量を減らすこと。このファイルは、
元の内容に展開できます。OpenStack は、Linux ファイルシステムレベルの圧
319
OpenStack 運用ガイド
February 1, 2016
縮をサポートしますが、Object Storage のオブジェクトや Image service の
仮想マシンイメージなどの圧縮をサポートしません。
Compute
コンピュートサービスを提供する OpenStack のコアプロジェクト。Compute の
プロジェクト名は nova。
Compute API
nova-api デーモンは nova サービスへのアクセスを提供する。Amazon EC2 API
など、他の API と通信できる。
コンピュートコントローラー
仮想マシンインスタンスを起動するために適切なホストを選択する Compute の
コンポーネント。
コンピュートホスト
コンピュートノード実行専用の物理ホスト。
コンピュートノード
nova-compute デーモンを実行するノード。Web アプリケーションや分析などの
幅広いサービスを提供する。
Compute サービス
仮想マシンを管理する Compute のコンポーネントの名称。
コンピュートワーカー
各ノードで動作し、仮想マシンインスタンスのライフサイクル (実行、再起
動、終了、ボリュームの接続や切断など) を管理する、Compute のコンポーネ
ント。nova-compute デーモンにより提供される。
連結オブジェクト
Object Storage が結合し、クライアントに送信する、オブジェクトの断片の
塊。
コンダクター
Compute において、コンピュートプロセスからのデータベース要求をプロキ
シーする処理。コンダクターを使用することにより、コンピュートノードが
データベースに直接アクセスする必要がなくなるので、セキュリティーを向上
できる。
一貫性ウインドウ
Object Storage の新規オブジェクトがすべてのクライアントからアクセス可能
になるまでにかかる時間。
コンソールログ
Compute の Linux 仮想マシンコンソールからの出力を含む。
320
OpenStack 運用ガイド
February 1, 2016
コンテナー
Object Storage でオブジェクトを整理して保存する。Linux のディレクトリと
似ているが、入れ子にできない。Image service のコンテナー形式の別名。
コンテナーオーディター
SQLite バックエンドデータベースへの問い合わせにより、指定した Object
Storage コンテナーにおいてレプリカの欠損やオブジェクトの不整合がないか
を確認する。
コンテナーデータベース
Object Storage コンテナーとコンテナーメタデータを保存する SQLite データ
ベース。コンテナーサーバーは、このデータベースにアクセスする。
コンテナーフォーマット
仮想マシンイメージ、および、マシンの状態や OS ディスク容量などの関連メ
タデータを含む、Image サービスにより使用されるラッパー。
コンテナーサーバー
コンテナーを管理する Object Storage サーバー。
Containers サービス
マルチテナントクラウド環境において、アプリケーションコンテナーの管理
サービスを提供する、OpenStack のプロジェクト。プロジェクトのコード名は
magnum です。
コンテナーサービス
作成、削除、一覧表示などのコンテナーサービスを提供する Object Storage
のコンポーネント。
コンテンツ配信ネットワーク (CDN)
コンテンツ配信ネットワークは、クライアントにコンテンツを配信するために
使用される特別なネットワーク。一般的に、パフォーマンス改善のために、ク
ライアントの近くに置かれる。
コントローラーノード
クラウドコントローラーノードの別名。
コアAPI
コア API は、文脈に応じて OpenStack API または特定のコアプロジェクトの
メイン API を意味する。コアプロジェクトは、Compute、Networking、Image
service などがある。
コアプロジェクト
OpenStack の公式プロジェクト。現在、 Compute (nova), Object Storage
(swift), Image service (glance), Identity (keystone), Dashboard
321
OpenStack 運用ガイド
February 1, 2016
(horizon), Networking (neutron), and Block Storage (cinder), Telemetry
(ceilometer), Orchestration (heat), Database service (trove), Bare
Metal service (ironic), Data processing service (sahara) がある。しかし
ながら、この定義は「Big Tent」に関するコミュニティーの議論に基づき変更
されてきている。
コスト
Compute の分散スケジューラーにおいて、要求している仮想マシンインスタン
スのフレーバーに関連する、各ホストのキャパシティーにより計算される。
クレデンシャル
ユーザーのみが知っている、またはアクセスできるデータ。ユーザーが正当で
あることを検証するために使用される。クレデンシャルは、認証中にサーバー
に提示される。例えば、パスワード、秘密鍵、電子証明書、フィンガープリン
トなどがある。
Cross-Origin Resource Sharing (CORS)
Web ページのさまざまなリソース (例: フォント、JavaScript) を、リソース
のあるドメインの外部から要求できるようになる機能。とくに、JavaScript の
AJAX コールが XMLHttpRequest 機能を使用できる。
Crowbar
クラウドの迅速なデプロイ用に全ての必要なサービスを提供する用途の、Dell
によるオープンソースコミュニティプロジェクト。
カレントワークロード
指定されたホスト上で現在進行中の build, snapshot, migrate, resize の操
作数を元に計算される、Compute のキャパシティキャッシュの１要素。
カスタマー
テナントの別名。
カスタムモジュール
ダッシュボードのルックアンドフィールを変更する為に Horizon がロードす
る、ユーザが作成した Python モジュール。
D
デーモン
バックグラウンドで動作し、リクエストを待機するプロセス。TCP ポートや
UDP ポートをリッスンする可能性がある。ワーカーとは異なる。
DAC
任意アクセス制御。サブジェクトがオブジェクトにアクセスする機能を統制す
る。ユーザーがポリシーを決定し、セキュリティー属性を割り当てられる。伝
322
OpenStack 運用ガイド
February 1, 2016
統的な UNIX システムのユーザー、グループ、読み書き権限が、DAC の例であ
る。
ダッシュボード
OpenStack 用 Web ベース管理インターフェース。Horizon の別名。
データ暗号化
Image service と Compute は、どちらも仮想マシンイメージ (イン
スタンスではない) の暗号化をサポートする。転送中のデータ暗号
は、HTTPS、SSL、TLS、SSH などの技術を使用して、OpenStack においてサポー
トされる。Object Storage は、アプリケーションレベルでオブジェクト暗号化
をサポートしませんが、ディスク暗号化を使用するストレージをサポートする
可能性がある。
データベース ID
Object Storage データベースの各レプリカに与えられる一意な ID。
データベースレプリケーター
アカウント、コンテナー、オブジェクトデータベースを他のノードに変更点を
コピーする Object Storage コンポーネント。
Database サービス
リレーショナルデータベースと非リレーショナルデータベースの両エンジンに
対して、スケール可能かつ信頼できるクラウド Database-as-a-Service を提供
する統合プロジェクト。この Database service の名前は trove。
Data processing サービス
スケールアウト可能なデータ処理基盤と関連する管理インターフェースを提供
する、OpenStack のプロジェクト。プロジェクトのコード名は sahara です。
データストア
Database サービスがサポートしているデータベースエンジン。
割り当て解除
Floating IP アドレスと固定 IP アドレスの関連付けを解除する処理。この関
連付けが解除されると、Floating IP はアドレスプールに戻されます。
Debian
OpenStack と互換性のある Linux ディストリビューション。
重複排除
ディスク使用を最小化するために、ディスクブロック、ファイル、オブジェク
トレベルにあるデータの重複を見つけるプロセス。現在 OpenStack 内では未サ
ポート。
323
OpenStack 運用ガイド
February 1, 2016
デフォルトパネル
ユーザーがダッシュボードにアクセスした際に表示されるデフォルトのパネ
ル。
デフォルトテナント
ユーザーを作成したときに、テナントを指定していない場合、新規ユーザーは
このテナントに割り当てられる。
デフォルトトークン
特定のテナントに関連づけられていない、スコープ付きトークンのために交換
される、Identity のトークン。
遅延削除
イメージをすぐに削除する代わりに、事前定義した秒数経過後に削除するため
の、Image service 内のオプション。
デリバリーモード
Compute RabbitMQ メッセージ配信モード用設定。transient（一時）又は
persistent（永続）のいずれかを設定できる。
サービス妨害 (DoS)
DoS は、サービス妨害攻撃の省略形である。正当なユーザーがサービスを使用
することを妨害するための悪意のある試み。
非推奨認証
管理者が、Identity を使用する代わりに、nova-manage コマンド経由でユー
ザーを作成および管理できる、Compute 内のオプション。
Designate
OpenStack の DNS サービスプロジェクトのコード名。
Desktop-as-a-Service
デスクトップ環境群を提供するプラットフォーム。ユーザーがどこからでも
デスクトップを利用するためにアクセスする可能性がある。一般的な使用、開
発、同種のテスト環境さえも提供できる。
developer
Compute RBAC システムにあるデフォルトのロールの 1 つ。新規ユーザーに割
り当てられるデフォルトのロール。
デバイス ID
Object Storage パーティションの物理ストレージデバイスへの対応付け
デバイスウェイト
各デバイスのストレージキャパシティに基づき、Object Storage デバイスをま
たがりパーティションを比例分配する。
324
OpenStack 運用ガイド
February 1, 2016
DevStack
シェルスクリプトを使用して、完全な OpenStack 導入環境を迅速に構築するた
めのコミュニティープロジェクト。
DHCP
Dynamic Host Configuration Protocol。ネットワークに接続されたデバイス
が、そのネットワーク上で IP を使用して通信できるよう、ネットワークデバ
イスを設定するネットワークプロトコル。このプロトコルは、クライアントサ
イドモデルで実装されている。DHCP クライアントは、IP アドレス、デフォル
トルート、1 つ以上の DNS サーバーアドレス設定データを要求する。
DHCP エージェント
仮想ネットワーク向けに DHCP サービスを提供する OpenStack Networking
エージェント。
Diablo
2011年秋に登場した OpenStack 関連プロジェクトのリリース。Compute (nova
2011.3), Object Storage (swift 1.4.3), Image service (glance) が含まれ
る。
Diablo は、OpenStack の 4 番目のリリースのコード名である。デザインサ
ミットが、アメリカ合衆国カリフォルニア州サンタクララ近郊の湾岸エリアで
開催された。Diablo は近郊の都市である。
直接使用者
RPC コールが実行されるとき、開始される Compute RabbitMQ の要素。一意な
排他キュー経由で直接交換者に接続し、メッセージを送信し、終了します。
直接交換
RPC コール中に Compute RabbitMQ 内で作成されるルーティングテーブル。関
連する各 RPC コールに対して作成されるもの。
直接発行者
送信されてきた MQ メッセージに応答する RabbitMQ の要素。
関連付け解除
Floating IP アドレスと固定 IP の関連付けを削除する処理。これによ
り、Floating IP アドレスをアドレスプールに返す。
ディスク暗号化
ファイルシステム、ディスクパーティション、ディスク全体を暗号化する機
能。Compute の仮想マシン内でサポートされる。
ディスクフォーマット
仮想マシンのディスクイメージが Image service のバックエンドストア内で保
存される、バックエンドの形式。AMI、ISO、QCOW2、VMDK などがある。
325
OpenStack 運用ガイド
February 1, 2016
dispersion
Object Storage　で、フォールトトレラントの確認の為に、オブジェクトとコ
ンテナの分散をテスト、確認するツール。
分散仮想ルーター (DVR)
OpenStack Networking (neutron) の使用時、高可用なマルチホストルーティン
グのための機構。
Django
horizon で広範囲に使用している Web フレームワーク。
DNS
ドメインネームシステム。インターネットやプライベートネットワークに接続
されるコンピューター、サービス、リソースの名前を管理する階層化分散シス
テム。人間が理解しやすい名前を IP アドレスに関連付ける。
DNS レコード
特定のドメインに関する情報を指定し、ドメインに所属するレコード。
DNS サービス
技術によらない方法で、権威 DNS サービスへの拡張可能、オンデマンド、セル
フサービスのアクセスを提供する OpenStack プロジェクト。このプロジェクト
のコード名は designate。
dnsmasq
仮想ネットワーク向けに DNS、DHCP、BOOTP、TFTP サービスを提供するデーモ
ン。
ドメイン
Identity v3 API のエンティティーで、プロジェクト、グループ、ユーザーの
集合で、OpenStack Identity のエンティティーを管理する管理権限の範囲を規
定するものである。
インターネット上で Web サイトを他のサイトから分離する。ドメイ
ン名はよく、ドットにより区切られた 2 つ以上の部分を持つ。例え
ば、yahoo.com、usa.gov、harvard.edu、mail.yahoo.com。
ドメインは、1 つ以上のレコードを含む、すべて DNS 関連の情報のエンティ
ティーやコンテナーである。
Domain Name System (DNS)
インターネットのドメイン名からアドレス、アドレスからドメイン名に名前解
決するシステム。
DNS は、IP アドレスを人間が覚えやすいアドレスに変換することにより、イン
ターネットを参照しやすくする。例えば、111.111.111.1 を www.yahoo.com に
変換する。
326
OpenStack 運用ガイド
February 1, 2016
すべてのドメイン、メールサーバーなどのコンポーネントは、DNS を利用し
て、適切な場所を解決する。DNS サーバーは、マスターの障害がスレーブによ
り助けられるよう、一般的にマスターとスレーブの関係で構築する。DNS サー
バーは、ある DNS サーバーへの変更が他の動作中のサーバーに自動的に反映さ
れるよう、クラスター化やレプリケーションされることもある。
Compute において、ホスト名が再起動後も同じになるよう、DNS エンティ
ティーを Floating IP アドレス、ノード、セルに関連付けできる。
ダウンロード
あるコンピューターから他のコンピューターへのデータの転送。通常はファイ
ルの形式。
DRTM
Dynamic root of trust measurement.
永続交換
サーバーの再起動時に有効なままになる Compute の RabbitMQ メッセージ交
換。
永続キュー
サーバーの再起動時に有効なままとなる、Compute RabbitMQ メッセージ
キュー。
動的ホスト設定プロトコル（DHCP）
ホストの起動時にネットワークを自動的に設定する方式。Networking と
Compute により提供される。
Dynamic HyperText Markup Language (DHTML)
ユーザーが Web ページと通信したり、簡単なアニメーションを表示したりする
ために、HTML、JavaScript、CSS を使用するページ。
E
イースト・ウエスト通信
同じクラウドやデータセンターにあるサーバー間のネットワーク通信。ノー
ス・サウス通信も参照。
EBS ブートボリューム
ブート可能な仮想マシンイメージを含む Amazon EBS ストレージボリューム。
現在 OpenStack では未サポート。
ebtables
Linux ブリッジのファイアウォール用のフィルタリングツール。Linux
ブリッジを通過するネットワーク通信のフィルタリングできる。
327
OpenStack 運用ガイド
February 1, 2016
ネットワーク通信を分離するために、OpenStack Compute において
arptables、iptables、ip6tables と一緒に使用される。
EC2
Amazon の商用コンピュート製品。Compute と似ている。
EC2 アクセスキー
Compute EC2 API にアクセスするために、EC2 秘密鍵と一緒に使用される。
EC2 API
OpenStack は、Compute 経由で Amazon EC2 API へのアクセスをサポートす
る。
EC2 互換API
OpenStack が Amazon EC2 を利用できるようにするための Compute のコンポー
ネント。
EC2 シークレットキー
Compute EC2 API 利用時に EC2 アクセスキーと一緒に使用される。各リクエス
トを電子署名するために使用される。
Elastic Block Storage (EBS)
Amazon のブロックストレージの商用製品。
暗号化
OpenStack は、HTTPS、SSH、SSL、TLS、電子証明書、データ暗号化などの暗号
化技術をサポートします。
エンドポイント
API エンドポイントを参照。
エンドポイントレジストリ
Identity サービスカタログの別名。
カプセル化
データを抽象化やセキュア化する目的で、あるパケット形式を別の形式の中に
入れるための方法。例えば、GRE、MPLS、IPsec などがある。
エンドポイントテンプレート
URL やポート番号のエンドポイントの一覧。Object
Storage、Compute、Identity などのサービスがアクセスできる場所を意味す
る。
エンティティー
Networking により提供されるネットワークサービス、ネットワーク接続性サー
ビスに接続したい、ハードウェアやソフトウェアの部品。エンティティーは、
仮想インターフェースを実装することにより Networking を使用できる。
328
OpenStack 運用ガイド
February 1, 2016
一時イメージ
ボリュームへの変更が保存されない仮想マシンイメージ。インスタンスの終了
後、元の状態に戻される。
一時ボリューム
変更が保存されないボリューム。現在のユーザーが制御を解放したとき、元の
状態に戻される。
Essex
2012年４月に登場した OpenStack 関連プロジェクトのリリース。Compute
(nova 2012.1), Object Storage (swift 1.4.8), Image (glance), Identity
(keystone), Dashboard (horizon) が含まれる。
Essex は、OpenStack の 5 番目のリリースのコード名。デザインサミットは、
アメリカ合衆国マサチューセッツ州ボストンで開催された。Essex は近くの都
市。
ESXi
OpenStack がサポートするハイパーバイザーの１つ。
ETag
Object Storage 内のオブジェクトの MD5 ハッシュ。データの完全性を確認す
るために使用される。
euca2ools
仮想マシンを管理するためのコマンドラインツール群。ほとんどは OpenStack
と互換性がある。
Eucalyptus Kernel Image (EKI)
EMI を作成するために、ERI と一緒に使用する。
Eucalyptus Machine Image (EMI)
Image service によりサポートされる仮想マシンイメージのコンテナー形式。
Eucalyptus Ramdisk Image (ERI)
EMI を作成するために、EKI と一緒に使用する。
退避
１つまたは全ての仮想マシン（VM）インスタンスをあるホストから別のホスト
にマイグレーションする処理。共有ストレージのライブマイグレーションとブ
ロックマイグレーション両方と互換がある。
交換
RabbitMQ メッセージ交換の別名。
交換種別
Compute RabbitMQ におけるルーティングアルゴリズム。
329
OpenStack 運用ガイド
February 1, 2016
排他キュー
RabbitMQ—Compute において直接利用者により接続される。メッセージは、現
在の接続だけにより使用される。
拡張属性 (xattr)
所有者、グループ、パーミッション、変更時間など以外の追加情報を保存でき
るようにする、ファイルシステムのオプション。Object Storage のバックエン
ドのファイルシステムは、拡張属性をサポートする必要がある。
エクステンション
API 拡張やプラグインの別名。Identity service では、OpenID のサポートの
追加など、特定の実装を意味する。
外部ネットワーク
一般的にインスタンスのインターネットアクセスに使用されるネットワークセ
グメント。
拡張仕様
Compute が新しいインスタンスを起動する場所を判断するとき、追加の要件を
指定する。例えば、ネットワーク帯域の最小量、GPU などがある。
F
FakeLDAP
Identity と Compute のテスト目的でローカルな LDAP ディレクトリーを作成
するための簡易な方法。Redis が必要。
ファンアウト交換
RabbitMQ と Compute の中で、コンピュートノード、ボリュームノード、ネッ
トワークノードからのメッセージを受け付ける機能のために、スケジューラー
サービスにより使用されるメッセージングインターフェース。
連合認証
認証プロバイダーと　OpenStack クラウド間で信頼を確立する方法。
Fedora
OpenStack と互換性のある Linux ディストリビューション。
ファイバーチャネル
TCP/IP に似た概念のストレージプロトコル。SCSI コマンドとデータをカプセ
ル化する。
Fibre Channel over Ethernet (FCoE)
イーサネットでトンネルされるファイバーチャネルプロトコル。
330
OpenStack 運用ガイド
February 1, 2016
充填優先スケジューラー
様々なホスト上で新しい VM を起動するよりも、なるべく一つのホストを埋め
ようとする Compute スケジューリング手法。
フィルター
VM を実行できないホストを排除し、選択されないようにする Compute のスケ
ジューリング処理の段階。
ファイアウォール
ホストノード間の通信を制限する為に使用される。iptables, arptables,
ip6tables, ebtables を使用して Compute により実装される。
FWaaS
境界ファイアウォール機能を提供する Networking 拡張。
fixed IP アドレス
インスタンス起動時に毎回同じインスタンスに割当られるIPアドレス（一般
に、エンドユーザやパブリックインターネットからはアクセス出来ない）。イ
ンスタンスの管理に使用される。
Flat マネージャー
認可されたノードに IP アドレスを割り当てる Compute のコンポーネン
ト。DHCP、DNS、ルーティングの設定とサービスが別の何かにより提供されるこ
とを仮定している。
フラットモードインジェクション
インスタンスの起動前に、OS のネットワーク設定情報を仮想マシンイメージ内
に注入する、Compute のネットワーク方式。
フラットネットワーク
テナントの通信を分離するために、VLAN もトンネルも使用しない仮想ネット
ワーク方式。各フラットネットワークは、一般的にブリッジマッピングにより
定義された、バックエンドに専用の物理インターフェースを必要とする。しか
しながら、フラットネットワークは複数のサブネットを含められる。
FlatDHCP マネージャー
dnsmasq (DHCP、DNS、BOOTP、TFTP) や radvd (ルーティング) のサービスを提
供する Compute のコンポーネント。
フレーバー
VM インスタンスタイプの別名。
フレーバー ID
Compute や Image service の仮想マシンの各フレーバーやインスタンスタイプ
の UUID。
331
OpenStack 運用ガイド
February 1, 2016
Floating IP アドレス
インスタンスを起動するたびに同じパブリック IP アドレスを持てるように、
プロジェクトが仮想マシンに関連付けられる IP アドレス。DNS 割り当てを維
持するために、Floating IP アドレスのプールを作成し、インスタンスが起動
するたびにそれらをインスタンスに割り当て、一貫した IP アドレスを維持し
ます。
Folsom
2012年秋に登場した OpenStack 関連プロジェクトのリリース。Compute
(nova), Object Storage (swift), Identity (keystone), Networking
(neutron), Image service (glance)、Volumes 又は Block Storage (cinder)
が含まれる。
Folsom は、OpenStack の 6 番目のリリースのコード名である。デザイン
サミットが、アメリカ合衆国カリフォルニア州サンフランシスコで開催され
た。Folsom は近郊の都市である。
FormPost
Web ページのフォームからイメージをアップロード (投稿) する、Object
Storage のミドルウェア。
freezer
バックアップリストアとディザスターリカバリーをサービスとして提供する
OpenStack プロジェクト。
フロントエンド
ユーザーがサービスと通信する箇所。API エンドポイント、ダッシュボード、
コマンドラインツールの可能性がある。
G
ゲートウェイ
異なるネットワーク間でネットワーク通信を中継する、IP アドレス。一般的に
はルーターに割り当てられる。
generic receive offload (GRO)
カーネルの IP スタックに届ける前に、多くの小さな受信パケットを大きなパ
ケットに結合する、特定のネットワークインターフェースドライバーの機能。
generic routing encapsulation (GRE)
仮想のポイントツーポイントリンク内で、さまざまなネットワーク層のプロト
コルをカプセル化するプロトコル。
glance
OpenStack Image サービスを提供するコアプロジェクト。
332
OpenStack 運用ガイド
February 1, 2016
glance API サーバー
仮想マシンに対するクライアントリクエスト、レジストリーサーバーにおけ
る Image サービスのメタデータの更新、バックエンドストアから仮想マシンイ
メージをアップロードするためのストアアダプターを用いた通信を処理する。
Glance レジストリ
Image service イメージレジストリの別名。
グローバルエンドポイントテンプレート
すべてのテナントが利用可能なサービスを含む、Identity のエンドポイントテ
ンプレート。
GlusterFS
NAS ホストを集約するために設計されたファイルシステム。OpenStack と互換
性がある。
ゴールデンイメージ
最終的なディスクイメージが作成され、すべてのノードで変更することなく使
用される、オペレーティングシステムのインストール方法。
Governance service
動的なインフラストラクチャー全体でポリシーを監視、強制、監査するため
に、さまざまなクラウドサービス群にわたり、Governance as a Service を提
供する OpenStack プロジェクト。このプロジェクトのコード名は congress。
Graphic Interchange Format (GIF)
Web ページのアニメーション画像によく使用される画像ファイルの形式。
Graphics Processing Unit (GPU)
GPU の有無によりホストを選択することは、現在 OpenStack で未サポート。
Green Threads
Python により使用される協調スレッドモデル。特定のライブラリーコールが発
行されるときの競合状態とコンテキストスイッチを減らす。各 OpenStack サー
ビスは自身のスレッドである。
Grizzly
OpenStack の 7 番目のリリースのコード名。デザインサミットがアメリカ合衆
国カリフォルニア州サンディエゴで開催された。Grizzly は、カリフォルニア
州の州旗に使われている。
グループ
Identity v3 API のエンティティーで、特定のドメイン内のユーザーの集合を
表す。
333
OpenStack 運用ガイド
February 1, 2016
ゲスト OS
ハイパーバイザーの管理下で実行しているオペレーティングシステムのインス
タンス。
H
Hadoop
Apache Hadoop は、データインテンシブな分散アプリケーションをサポートす
る、オープンソースソフトウェアフレームワークである。
Hadoop Distributed File System (HDFS)
低価格のコモディティーサーバー上で動作することを念頭に設計された、耐故
障性に優れた分散ファイルシステム。
handover
ドライブ故障により、オブジェクトの新しい複製が自動的に作成され
た、Object Storage のオブジェクトの状態。
ハードリブート
きちんとした正常なOSのシャットダウンを行わず、物理又は仮想電源ボタンを
押すタイプの再起動。
Havana
OpenStack の 8 番目のリリースのコード名。デザインサミットがアメリカ合衆
国オレゴン州ポートランドで開催された。Havana は、オレゴン州の非法人コ
ミュニティーである。
heat
OpenStack に複数のクラウドアプリケーションをオーケストレーションする為
に開発されたプロジェクト。
Heat Orchestration Template (HOT)
OpenStack 固有形式の Heat の入力データ。
ヘルスモニター
仮想 IP プールのバックエンドメンバーがリクエストを処理できるかどうかを
判断する。プールは、それに関連づけられた複数のヘルスモニターを持てる。
すべてのモニターは、プールのメンバーをお互いに確認する。すべてのモニ
ターは、その稼働状況の健全性であることをメンバーに宣言する必要がある。
高可用性
高可用性システムの設計手法および関連サービスの実装により、契約された計
測期間中、合意された運用レベルを満たします。高可用性システムは、システ
ムの停止時間とデータ損失を最小化しようとします。
334
OpenStack 運用ガイド
February 1, 2016
Horizon
ダッシュボードを提供する OpenStack プロジェクト。Web インターフェース。
horizon プラグイン
OpenStack dashboard (horizon) のプラグイン。
ホスト
物理コンピューター。仮想マシンインスタンス (ノード) ではない。
ホストアグリゲート
アベイラビリティーゾーンをさらに小さいハイパーバイザープールに分割する
ための方法。一般的なホスト群。
Host Bus Adapter (HBA)
ファイバーチャネルやネットワークカードなどの PCI スロット内に挿入される
デバイス。
ハイブリッドクラウド
ハイブリッドクラウドは、複数のクラウド (プライベート、コミュニティー、
パブリック) の組み合わせ。別々のエンティティーのままですが、一緒にまと
められる。複数の配備モデルの利点を提供する。ハイブリッドクラウドは、コ
ロケーション、マネージドサービス、専用サービスをクラウドのリソースに接
続する機能を意味することもある。
Hyper-V
OpenStack によりサポートされるハイパーバイザーの一つ。
ハイパーリンク
どこか別のサイトへのリンクを含む、ある種のテキスト。一般的に、別の Web
サイトを開く言葉をクリックするドキュメントに見られる。
Hypertext Transfer Protocol (HTTP)
分散、協調、ハイパーメディア情報システム用のアプリケーションプロト
コル。WWW のデータ通信の基盤。ハイパーテキストは、ノード間でのテキス
トを含む論理リンク (ハイパーリンク) を使った構造化テキストのことであ
る。HTTP は、ハイパーテキストを交換したり転送したりするためのプロトコ
ル。
Hypertext Transfer Protocol Secure (HTTPS)
コンピューターネットワークで、とくにインターネットで広く使われている、
安全に通信を行うための暗号化通信プロトコル。技術的には、プロトコルで
はなく、むしろシンプルに SSL/TLS プロトコルの上に Hypertext Transfer
Protocol (HTTP) を重ねているものである。そのため、SSL や TLS プロトコル
のセキュリティー機能を標準的な HTTP 通信に追加したものである。ほとんど
335
OpenStack 運用ガイド
February 1, 2016
の OpenStack API エンドポイントや多くのコンポーネント間通信で、 HTTPS
通信がサポートされている。
ハイパーバイザー
VM のアクセスを実際の下位ハードウェアに仲介して制御するソフトウェア。
ハイパーバイザープール
ホストアグリゲートにより一緒にグループ化されたハイパーバイザーの集合。
I
IaaS
Infrastructure-as-a-Service。IaaS は、ストレージ、ハードウェア、サー
バー、ネットワークなど、データセンターの物理コンポーネントをアウトソー
スする組織の配備モデル。サーバープロバイダーは、設備を所有し、ハウジン
グ、運用、メンテナンスに責任を持つ。クライアントは、一般的に使用量に応
じて費用を払う。IaaS は、クラウドサービスを提供するモデル。
Icehouse
OpenStack の 9 番目のリリースのコード名。デザインサミットは、香港で開催
された。Ice House は、その近くにある通りである。
ICMP
インターネット制御メッセージプロトコル。制御メッセージ用にネットワーク
デバイスにより使用される。例えば、ping は接続性をテストするために ICMP
を使用する。
ID 番号
Identity で各ユーザーと関連付けられた一意な数値 ID。概念として、Linux
や LDAP の UID を同じ。
Identity API
Identity service API の別名。
Identity バックエンド
ユーザー情報を取得するために、Identity により使用されるソース。例え
ば、OpenLDAP。
識別情報プロバイダー
ユーザーがユーザー名とパスワードを用いてログインできるようにする、ディ
レクトリーサービス。認証トークンの一般的な情報源。
Identity
ユーザーがアクセスできる OpenStack サービスに対応付けられた、ユーザー
の中央ディレクトリーを提供する、OpenStack コアプロジェクト。OpenStack
336
OpenStack 運用ガイド
February 1, 2016
サービスのエンドポイントも登録する。一般的な認証システムとして動作す
る。Identity のプロジェクト名は keystone。
Identity service API
Keystone が提供する OpenStack Identity サービスアクセスに使用される
API。
IDS
侵入検知システム。
イメージ
サーバーの作成、再構築に使用する特定のオペレーティングシステム（OS）用
のファイルの集合。OpenStack は構築済みイメージを提供する。起動したサー
バーからカスタムイメージ（又はスナップショット）を作成できる。
Image API
仮想マシンイメージの管理用の Image service API エンドポイント。
イメージキャッシュ
イメージが要求されたときに、イメージサーバーから再ダウンロードするので
はなく、ローカルホストにあるイメージを取得するために、Image service に
より使用される。
イメージ ID
Image API 経由で Image service の仮想マシンイメージにアクセスするために
使用される、URI や UUID の組み合わせ。
イメージメンバーシップ
Image service 内で指定した仮想マシンイメージにアクセスできるテナントの
一覧。
イメージ所有者
Image サービスの仮想マシンイメージを所有するテナント。
イメージレジストリー
Image service 経由で利用可能な仮想マシンイメージの一覧。
Image サービス
ディスクやサーバーイメージ向けのサービスの検索、登録、配信を提供する
OpenStack コアプロジェクト。Image service のプロジェクト名は glance。
Image サービス API
Glance イメージ API の別名。
イメージ状態
Image service における仮想マシンイメージの現在の状態。実行中のインスタ
ンスの状態と混同しないこと。
337
OpenStack 運用ガイド
February 1, 2016
イメージストア
仮想マシンイメージを保存するために、Image service により使用されるバッ
クエンドストア。オプションとして、Object Storage、ローカルファイルシス
テム、S3、HTTP がある。
イメージ UUID
各仮想マシンイメージを一意に識別するために Image service により使用され
る UUID。
インキュベートプロジェクト
コミュニティプロジェクトがこの状態に昇格する事があり、その後コアプロ
ジェクトに昇格する。
イングレスフィルタリング
入力ネットワーク通信をフィルタリングする処理。Compute によりサポートさ
れる。
INI
OpenStack 設定ファイルは、オプションやその値を記述するために、INI 形式
を使用する。セクションとキーバリューペアから構成される。
インジェクション
インスタンスが起動する前に、仮想マシンイメージ中にファイルを配置する処
理。
インスタンス
実行中の仮想マシン。または、一時停止などの既知の状態にある仮想マシン。
ハードウェアサーバーのように使用できる。
インスタンス ID
インスタンス UUID の別名。
インスタンス状態
ゲスト仮想マシンイメージの現在の状態。
インスタンストンネルネットワーク
コンピュートノードとネットワークノード間で、インスタンスのトラフィック
をトンネルするために使用されるネットワークセグメント。
インスタンスタイプ
ユーザが利用可能な様々な仮想マシンイメージのパラメーター（CPU、ストレー
ジ、メモリ等を含む）を示す。フレーバーの別名。
インスタンスタイプ ID
フレーバー ID の別名。
338
OpenStack 運用ガイド
February 1, 2016
インスタンス UUID
各ゲスト仮想マシンインスタンスに割り当てられる一意な ID。
インターフェース
他のデバイスやメディアに接続する物理デバイスまたは仮想デバイス。
インターフェース ID
Networking 仮想インターフェースや vNIC 用の一意な UUID 形式の ID。
インターネットプロトコル (IP)
ネットワーク境界を越えてデータグラムを中継するための、インターネットプ
ロトコルにおける中心的な通信プロトコル。
Internet Service Provider (ISP)
個人や組織にインターネットアクセスを提供する何らかのビジネス。
Internet Small Computer System Interface (iSCSI)
IP ネットワーク上で転送するために、SCSI フレームをカプセル化するスト
レージプロトコル。
ironic
マシンを仮想とみなして、ベアメタルに展開する OpenStack のプロジェクト。
IOPS
IOPS (Input/Output Operations Per Second) は、ハードディスク、SSD、SAN
などのストレージデバイスをベンチマークするために使用される、一般的なパ
フォーマンス指標である。
IP アドレス
インターネットにあるすべてのコンピューターシステムを一意にする番
号。Internet Protocol (IP) は、IPv4 と IPv6 の 2 つのバージョンがアドレ
ス付けのために使用中です。
IP Address Management (IPAM)
IP アドレスの割り当て、割り当て解除、管理を自動化するプロセス。現
在、Compute、melange、Networking により提供される。
IPL
Initial Program Loader。初期プログラムローダー。
IPMI
Intelligent Platform Management Interface。IPMI は、コンピューターシス
テムのアウトオブバンド管理、運用監視のために、システム管理者により使用
される標準的なコンピューターシステムインターフェース。平たく言うと、電
339
OpenStack 運用ガイド
February 1, 2016
源状態によらず、ネットワークの直接通信を使用してコンピューターを管理す
る方法。オペレーティングシステムやログインシェルではなく、ハードウェア
に接続する。
ip6tables
Linux カーネルで IPv6 パケットフィルタールールのテーブルをセットアッ
プ、維持、検査するために使用されるツール。OpenStack Compute では、ノー
ドと仮想マシンの両方に対するファイアウォールを作成するために、ip6tables
が arptables、ebtables、iptables と一緒に使用される。
ipset
連続する IP アドレスの全体に一致するファイアウォールルールを作成でき
る、iptables の拡張。これらのセットは、効率化するためにインデックス化さ
れたデータ構造、とくに大量のルールを持つシステムにあります。
iptables
Compute においてファイアウォールを作成す
る、arptables、ebtables、iptables と一緒に使用される。iptables
は、Linux カーネルファイアウォール (別の Netfilter モジュール) により
提供されるテーブル、それを保存するチェインやルール。複数のカーネルモ
ジュールとプログラムが、別々のプロトコルに対して使用される。iptables は
IPv4、ip6tables は IPv6、arptables は ARP、ebtables は Ethernet フレー
ムに適用される。操作すうために root 権限が必要になる。
IQN
iSCSI Qualified Name (IQN) は iSCSI の名前として最も広く使われて
いる形式で、 iSCSI ネットワークで一意にノードを識別するのに使われ
ます。すべての IQN は iqn.yyyy-mm.domain:identifier という形式で
す。ここで、 'yyyy-mm' はそのドメインが登録された年と月、 'domain'
は発行組織の登録されたドメイン名、 'identifier' は同じドメイン内
の各 IQN 番号を一意なものにするためのオプション文字列です。例えば
'iqn.2015-10.org.openstack.408ae959bce1'
iSCSI
イーサネット内でトンネルされる SCSI ディスクプロトコル。Compute、Object
Storage、Image service によりサポートされる。
ISO9660
Image service によりサポートされる、仮想マシンイメージディスク形式の 1
つ。
itsec
あらゆるプロジェクトにあるインスタンスを検疫できる、Compute RBAC システ
ムにおけるデフォルトのロール。
340
OpenStack 運用ガイド
February 1, 2016
J
Java
ネットワーク経由で複数のコンピューターが関連するシステムを作成するため
に使用されるプログラミング言語。
JavaScript
Web ページを構築するために使用されるスクリプト言語。
JavaScript Object Notation (JSON)
OpenStack でサポートされる応答形式の 1 つ。
Jenkins
OpenStack 開発のためにジョブを自動的に実行するために使用されるツール。
ジャンボフレーム
約 9000 バイトまでのフレームをサポートする最近のイーサネット上の機能。
Juno
OpenStack の 10 番目のリリースのコード名。デザインサミットはアメリカ合
衆国ジョージア州アトランタにて開催された。Juno は、ジョージア州の非公式
コミュニティー。
K
Kerberos
チケットベースで機能するネットワーク認証プロトコル。 Kerberos により、
安全でないネットワークを通したノード通信ができ、ノードは安全な方法で互
いに本人確認ができるようになります。
kernel-based VM (KVM)
OpenStack がサポートするハイパーバイザー。KVM は、仮想化拡張 (Intel
VT や AMD-V) を持つ x86 ハードウェア、ARM、IBM Power、IBM zSeries 上の
Linux 向けの完全仮想化ソリューション。
Key management サービス
暗号化機能を有効化したいサービスに鍵管理機能を提供する機能を持つ、シー
クレットストレージと生成システムを開発する OpenStack プロジェクト。この
プロジェクトの名前は barbican。
keystone
OpenStack Identity サービスを提供するプロジェクト。
341
OpenStack 運用ガイド
February 1, 2016
Kickstart
Red Hat、Fedora、CentOS 系の Linux ディストリビューションにおいて、シス
テム設定とインストールを自動化するためのツール。
Kilo
OpenStack の 11 番目のリリースのコード名。デザインサミットは、フランス
のパリで開催された。名前選定の遅れにより、このリリースは K のみで知られ
ていた。k はキロを表す単位記号であり、その原器がパリ近郊の Pavillon de
Breteuil in Sèvres に保存されているので、コミュニティーはリリース名とし
て Kilo を選択した
L
ラージオブジェクト
5GB より大きい Object Storage 内のオブジェクト。
Launchpad
OpenStack 用コラボレーションサイト。
L2 ネットワーク
OSI ネットワークアーキテクチャーにおけるデータリンク層に使用される用
語。データリンク層は、メディアアクセス制御、フロー制御、物理層で発生す
る可能性のあるエラー検知、できる限りエラー訂正に責任を持つ。
L3 ネットワーク
OSI ネットワークアーキテクチャーにおけるネットワーク層に使用される用
語。ネットワーク層は、パケット転送、あるノードから別のノードへのルー
ティングに責任を持つ。
L2 エージェント
仮想ネットワーク向けに L2 接続性を提供する OpenStack Networking エー
ジェント。
L3 エージェント
仮想ネットワーク向けに L3 (ルーティング) サービスを提供する OpenStack
Networking エージェント。
Liberty
OpenStack の 12 番目のリリースのコード名。デザインサミットは、カナダの
バンクーバーで開催された。Liberty は、サスカチュワン州にある村の名前。
libvirt
多くのサポートハイパーバイザーと通信するために、OpenStack により使用さ
れる仮想化 API ライブラリー。
342
OpenStack 運用ガイド
February 1, 2016
Lightweight Directory Access Protocol (LDAP)
IP ネットワーク上の分散ディレクトリー情報サービスへのアクセスと管理を行
うためのアプリケーションプロトコル。
Linux ブリッジ
複数の仮想マシンが Compute 内で単一の物理 NIC を共有するためのソフト
ウェア。
Linux Bridge neutron プラグイン
Linux ブリッジが、Networking のポート、インターフェース接続、他の抽象化
を理解できるようにする。
Linux コンテナー （LXC）
OpenStack がサポートするハイパーバイザーの１つ。
ライブマイグレーション
切り替え中のわずかなサービス中断のみで、実行中の仮想マシンをあるホスト
から別のホストに移動する、Compute 内の機能。
負荷分散装置
負荷分散装置は、クラウドアカウントに属する論理デバイスである。その設定
に定義されている基準に基づき、複数のバックエンドのシステムやサービス間
でワークロードを分散するために使用される。
負荷分散
パフォーマンスや可用性を向上するために、2 つ以上のノード間でクライアン
トリクエストを分散する処理。
LBaaS
Networking により、受信リクエストを指定されたインスタンス間で均等に分散
できるようになる。
論理ボリュームマネージャー (LVM)
伝統的なパーティションスキーマよりも柔軟に、大規模ストレージデバイスに
領域を割り当てる方式を提供する。
M
magnum
コンテナーサービスを提供する OpenStack プロジェクトのコード名。
マネジメント API
管理 API（admin API）の別名。
343
OpenStack 運用ガイド
February 1, 2016
管理ネットワーク
管理のために使用されるネットワークセグメント。パブリックなインターネッ
トからアクセスできない。
マネージャー
Block Storage のボリュームマネージャーやネットワークマネージャーなど、
関連するコードの論理的なグループ。
マニフェスト
Object Storage 内で大きなオブジェクトを管理するために使用される。
マニフェストオブジェクト
大きなオブジェクト向けのマニフェストを含む、特別な Object Storage のオ
ブジェクト。
manila
共有ファイルシステムをアプリケーションに提供する OpenStack のプロジェク
ト。
最大転送単位 (MTU)
特定のネットワークメディア向けの最大フレームやパケットサイズ。一般的
に、イーサネット向けは 1500 バイト。
メカニズムドライバー
仮想インスタンス向けに L2 接続性を提供する、ML2 neutron プラグイン向け
のドライバー。単一の OpenStack インストール環境が、複数のメカニズムドラ
イバーを使用できます。
melange
OpenStack Network Information Service のプロジェクト名。Networking と統
合予定。
メンバーシップ
Image service の仮想マシンイメージとテナント間の関連。イメージを特別な
テナントと共有できるようになる。
メンバーシップリスト
Image service 内で指定した仮想マシンイメージにアクセスできるテナントの
一覧。
memcached
Object Storage がキャッシュのために使用する、メモリーオブジェクトの分散
キャッシュシステム。
344
OpenStack 運用ガイド
February 1, 2016
メモリーオーバーコミット
実行中の各インスタンスが利用可能と考えている RAM 量に基づく判断をベース
にする代わりに、ホスト上の実際のメモリ使用量をベースにした、新しい VM
インスタンスを起動する機能。
メッセージブローカー
Compute 内で AMQP メッセージング機能を提供するために使用されるソフト
ウェアパッケージ。標準のパッケージは RabbitMQ。
メッセージバス
Compute 内でクラウド内通信のためにすべての AMQP メッセージにより使用さ
れるメインの仮想通信ライン。
メッセージキュー
クライアントからのリクエストを適切なワーカーに渡す。ジョブ完了後、出力
をクライアントに返す。
Message サービス
効率的、拡張可能、高可用な方法で、さまざまな分散アプリケーションのパ
ターンを提供する、OpenStack messaging service を開発することを目指して
いる OpenStack プロジェクト。また、関連する Python ライブラリーやドキュ
メントを作成してメンテナンスする。このプロジェクトのコード名は zaqar。
メタデータエージェント
インスタンスにメタデータサービスを提供する OpenStack Networking エー
ジェント。
Meta-Data Server (MDS)
CephFS メタデータを格納する。
マイグレーション
VM インスタンスをあるホストから別のホストに移動させる処理。
mistral
ワークフローサービスを提供する OpenStack プロジェクト。
Mitaka
OpenStack の 13 番目のリリースのコード名。デザインサミットは、日本の東
京で開催された。三鷹は、東京にある都市です。
monasca
モニタリングサービスを提供する OpenStack プロジェクト。
マルチホスト
レガシーネットワーク (nova) の高可用性モード。各コンピュートノード
は、NAT と DHCP を処理し、すべての仮想マシンのゲートウェイとして動作す
345
OpenStack 運用ガイド
February 1, 2016
る。あるコンピュートノードにおけるネットワーク障害は、他のコンピュート
ノードにある仮想マシンに影響しません。
マルチ NIC
各仮想マシンインスタンスが複数の仮想インターフェースに接続できるように
なる、Compute における機能。
murano
アプリケーションカタログを提供する OpenStack のプロジェクト。
Modular Layer 2 (ML2) neutron プラグイン
Networking において、802.1Q や VXLAN などの複数の L2 ネットワーク技術を
同時に使用できる。
モニター (LBaaS)
ping コマンド、TCP、HTTP/HTTPS GET を使用してモニタリングする機能を提供
する LBaaS の機能。
モニター (Mon)
外部クライアントと通信し、データの状態と整合性を確認し、クォーラム機能
を実行する、Ceph コンポーネント。
Monitoring
マルチテナントで、高いスケーラビリティーを持ち、高性能で、耐障害性の
ある、Monitoring-as-a-Service ソリューションを提供する OpenStack プロ
ジェクト。 計測情報、複合イベント処理 (complex event processing)、ログ
監視が対象。オペレーター、テナントの両者が利用できる、高度なモニタリン
グサービスに対応できる拡張性のあるプラットフォームを開発しており、可用
性と安定性を確保しながら、運用上の問題の特定や可視化を実現できる。プロ
ジェクト名は monasca。
多要素認証
パスワードと秘密鍵など、2 つ以上のクレデンシャルを使用する認証方
式。Identity では現在サポートされていない。
MultiNic
各仮想マシンインスタンスが複数の仮想インターフェースに接続できるように
なる、Compute における機能。
N
Nebula
2010 年に NASA によりオープンソースとしてリリースされた。Compute の基に
なった。
346
OpenStack 運用ガイド
February 1, 2016
netadmin
Compute RBAC システムにおけるデフォルトのロールの 1 つ。ユーザーが、パ
ブリックにアクセス可能な IP アドレスをインスタンスに割り当てられ、ファ
イアウォールルールを変更できるようになる。
NetApp ボリュームドライバー
Compute が NetApp OnCommand Provisioning Manager 経由で NetApp ストレー
ジデバイスと通信できるようにする。
Network
エンティティ間の接続性を提供する仮想ネットワーク。例えば、ネットワーク
接続性を共有する仮想ポート群。Networking の用語では、ネットワークは必ず
L2 ネットワークを意味する。
NAT
ネットワークアドレス変換。IP アドレス情報を転送中に変更する処
理。Compute と Networking によりサポートされる。
ネットワークコントローラー
IP アドレス、VLAN、ブリッジなど、ノードのネットワーク設定をオーケスト
レーションする Compute のデーモン。また、パブリックネットワークとプライ
ベートネットワークのルーティングを管理する。
Network File System (NFS)
ネットワーク経由でファイルシステムを利用可能にある方式。OpenStack によ
りサポートされる。
ネットワーク ID
Networking 内の各ネットワークセグメントに割り当てられる一意な ID。ネッ
トワーク UUID と同じ。
ネットワークマネージャー
ファイアウォールのルール、IP アドレスの割り当てなど、さまざまなネット
ワークのコンポーネントを管理する、Compute のコンポーネント。
ネットワーク名前空間
別々のルーティングテーブルとインターフェースを持つ単一のホストにおい
て、独立した仮想ネットワークインターフェースを提供する Linux カーネル機
能。物理ネットワーク環境における仮想ルーティングおよびフォワーディング
(VRF) サービスと似ている。
ネットワークノード
ネットワークワーカーデーモンを実行するコンピュートノードすべて。
ネットワークセグメント
Networking における仮想の分離された OSI L-2 サブネットを表す。
347
OpenStack 運用ガイド
February 1, 2016
Newton
OpenStack の 14 番目のリリースのコード名。デザインサミットは、アメリ
カ合衆国テキサス州オースチンで開催される。リリースの名前は、テキサス州
オースチンの 1013 E. Ninth St. にある「Newton House」にちなんでいる。こ
れはアメリカ合衆国国家歴史登録財に登録されている。
NTP
ネットワーク時刻プロトコル。信頼された、正確な時刻源と通信することによ
り、ホストやノードの時刻を正確に保つ方法。
ネットワーク UUID
Networking のネットワークセグメントの一意な ID。
ネットワークワーカー
nova-network のワーカーデーモン。起動中の nova インスタンスに IP アドレ
スを提供するなどのサービスを提供する。
Networking
ネットワーク接続性の抽象化レイヤーを OpenStack Compute に提供す
る、OpenStack コアプロジェクト。Networking のプロジェクト名は neutron。
Networking API
OpenStack Networking にアクセスするために利用する API。独自プラグインを
作成できる拡張性を持ったアーキテクチャーになっている。
neutron
OpenStack のコアプロジェクトで、OpenStack Compute に対してネットワーク
接続の抽象化レイヤーを提供する。
neutron API
Networking API の別名。
neutron マネージャー
Compute と Networking の統合を可能にする。Networking がゲスト仮想マシン
用のネットワークを管理できるようになる。
neutron プラグイン
組織が QoS、ACL、IDS などの高度な機能向けのカスタムプラグインを作成でき
るようにする、Networking 内のインターフェース。
Nexenta ボリュームドライバー
Compute において NexentaStor デバイスのサポートを提供する。
No ACK
Compute RabbitMQ において、サーバーサイドメッセージ交換を無効化する。性
能を向上されるが、信頼性を低下させる。
348
OpenStack 運用ガイド
February 1, 2016
node
ホストで動作する仮想マシンインスタンス。
非永続交換
サービスの再起動時に削除されるメッセージ交換。このデータは永続ストレー
ジに書き込まれない。
非永続キュー
サービスの再起動時に削除されるメッセージキュー。このデータは永続スト
レージに書き込まれない。
非永続ボリューム
エフェメラルボリュームの別名。
ノース・サウス通信
ユーザーやクライアント (ノース)、とサーバー (サウス) 間のネットワーク通
信、クラウド (サウス) とクラウド外 (ノース) 内の通信。イースト・サウス
通信も参照。
nova
コンピュートサービスを提供する OpenStack プロジェクト。
Nova API
Compute API の別名。
nova-network
IP アドレス割り当て、ファイアウォール、その他ネットワーク関連タスク
を管理する Compute のコンポーネント。レガシーネットワークのオプショ
ン。Networking の代替。
O
オブジェクト
Object Storage により保持されるデータの BLOB。あらゆる形式の可能性があ
る。
オブジェクトオーディター
あるオブジェクトサーバー用の全オブジェクトを開き、各オブジェクトの MD5
ハッシュ、サイズ、メタデータを検証する。
オブジェクト有効期限
指定された時間経過後、又は指定日になった際に自動的にオブジェクトを削除
するための Object Storage の設定オプション。
オブジェクトハッシュ
Object Storage オブジェクト用の一意な ID。
349
OpenStack 運用ガイド
February 1, 2016
オブジェクトパスハッシュ
リング内でオブジェクトの場所を判断するために、Object Storage により使用
される。オブジェクトをパーティションに対応付ける。
オブジェクトレプリケーター
耐障害性のためにオブジェクトをリモートパーティションをコピーする Object
Storage コンポーネント。
オブジェクトサーバー
オブジェクトの管理に責任を持つ Object Storage のコンポーネント。
オブジェクトストレージ
結果整合性（eventually consistent）、ストレージ冗長化、静的デジタル
コンテンツ取得、といった機能を提供する、OpenStack のコアプロジェク
ト。OpenStack Object Storage のプロジェクト名は swift。
Object Storage API
OpenStack Object Storage にアクセスするために使用する API。
Object Storage Device (OSD)
Ceph ストレージデーモン。
オブジェクトバージョニング
コンテナー内のすべてのオブジェクトがバージョンを付けられるように、ユー
ザーが Object Storage のコンテナーにフラグを設定できる。
Ocata
OpenStack の 14 番目のリリースのコード名。デザインサミットは、スペイン
のバルセロナで開催される。Ocata はバルセロナ北部のビーチ。
Oldie
長時間動作している Object Storage のプロセスを指す用語。ハングしたプロ
セスを意味する可能性もある。
Open Cloud Computing Interface (OCCI)
コンピュート、データ、ネットワークのリソースを管理するための標準的なイ
ンターフェース。現在 OpenStack でサポートされない。
Open Virtualization Format (OVF)
仮想マシンイメージのパッケージ化の標準。OpenStack でサポートされる。
Open vSwitch
Open vSwitch は、商用品質、複数階層の仮想スイッチ。オープンソー
スの Apache 2.0 license に基づき許諾される。標準的な管理イン
ターフェースやプロトコルと使用ながら、プログラム拡張により大
350
OpenStack 運用ガイド
February 1, 2016
規模なネットワーク自動化を実現できるよう設計されている (例え
ば、NetFlow、sFlow、SPAN、RSPAN、CLI、LACP、802.1ag)。
Open vSwitch (OVS) エージェント
Networking のプラグインに対して、バックエンドの Open vSwitch サービスへ
のインターフェースを提供する。
Open vSwitch neutron プラグイン
Networking で Open vSwitch のサポートを提供する。
OpenLDAP
オープンソース LDAP サーバー。Compute と Identity によりサポートされ
る。
OpenStack
OpenStack は、データセンター全体のコンピュートリソース、ストレージリ
ソース、ネットワークリソースの大規模なプールを制御する、クラウドオペ
レーティングシステム。管理者はすべてダッシュボードから制御できる。ユー
ザーは Web インターフェースからリソースを配備できる。Apache License 2.0
に基づき許諾されるオープンソースのプロジェクト。
OpenStack コード名
各 OpenStack リリースはコード名を持つ。コード名はアルファベット順にな
ります。Austin, Bexar, Cactus, Diablo, Essex, Folsom, Grizzly, Havana,
Icehouse, Juno, Kilo、Liberty、Mitaka。コード名は、対応する OpenStack
デザインサミットが開催された場所の近くにある都市または国である。Waldon
例外と言われる例外は、非常に格好良く聞こえる、状態フラグの要素に保証さ
れる。コード名は、一般的な投票により選択される。
openSUSE
OpenStack と互換性のある Linux ディストリビューション。
運用者
OpenStack インストールを計画し、管理する責任者。
Orchestration
OpenStack 向けに複数のクラウドアプリケーションをオーケストレーションす
る統合プロジェクト。Orchestration のプロジェクト名は heat。
orphan
Object Storage の文脈において、サービスの更新、再起動、再読み込みの後に
終了しないプロセス。
Oslo
OpenStack プロジェクトに共有されるコードを含む Python ライブラリー群を
作成する OpenStack プロジェクト。
351
OpenStack 運用ガイド
February 1, 2016
P
親セル
要求されたリソース（CPU時間、ディスクストレージ、メモリ）が親セルで利用
不可の場合、そのリクエストは紐付けられた子セルに転送される。
パーティション
オブジェクトを保存するために使用される、Object Storage 内の保存単位。デ
バイスの上位に存在し、耐障害のために複製される。
パーティションインデックス
リング内にあるすべての Object Storage のパーティションの場所を含む。
パーティションシフト値
パーティションデータが配置されるべき場所を決めるために、Object Storage
により使用される。
path MTU discovery (PMTUD)
エンド間の MTU を検出し、パケットサイズを適切に調整するための IP ネット
ワークにおける機構。
一時停止
変更が発生しない (メモリーの変更なし、ネットワーク通信の停止など)、仮想
マシンの状態。仮想マシンは停止するが、シャットダウンしない。
PCI パススルー
ゲスト仮想マシンが PCI デバイスに排他的にアクセスされる。OpenStack
Havana 以降でサポートされる。
永続メッセージ
メモリーとディスクの両方に保存されているメッセージ。メッセージは、故障
や再起動した後も失われません。
永続ボリューム
この種類のディスクボリュームに変更すると、データが保存される。
パーソナリティーファイル
Compute インスタンスをカスタマイズするために使用されるファイル。SSH 鍵
や特定のネットワーク設定を注入するために使用できます。
Platform-as-a-Service (PaaS)
クラウドプラットフォームプロバイダーによりサポートされるプログラミン
グ言語やツールを用いてアプリケーションを配備する機能を利用者に提供す
352
OpenStack 運用ガイド
February 1, 2016
る。PaaS の例は、ダウンロードする必要がない、Eclipse/Java プログラミン
グプラットフォームです。
プラグイン
利用形態に応じた、Networking API や Compute API の具体的な実装を提供す
るソフトウェアコンポーネント。
ポリシーサービス
ルール管理インターフェースやルールベースの認可エンジンを提供する
Identity のコンポーネント。
プール
Web サーバーなどのデバイスの論理的な集合。一緒にトラフィックを受け、処
理するために、グループ化する。負荷分散機能は、プール内のどのメンバー
が仮想 IP アドレスで受信した新規リクエストや接続を処理するかを選択しま
す。各仮想 IP は 1 つのプールを持ちます。
プールメンバー
負荷分散システムでバックエンドサーバーで動作するアプリケーション。
ポート
Networking 内の仮想ネットワークポート。仮想インターフェースや仮想 NIC
は、ポートに接続されます。
ポート UUID
Networking ポートのユニーク ID。
preseed
Debian 系の Linux ディストリビューションでシステム設定やインストールを
自動化するツール。
プライベートイメージ
指定したテナントのみで利用可能な Image service の仮想マシンイメージ。
プライベート IP アドレス
管理のために使用される IP アドレス。パブリックなインターネットから利用
できません。
プライベートネットワーク
ネットワークコントローラーは、コンピュートサーバー間、およびコンピュー
トサーバーとパブリックネットワークとの通信を行う仮想ネットワークを用
意する。すべての物理マシンにはパブリック側とプライベート側のネットワー
クインタフェースが必要。プライベートネットワークインターフェースは、
フラットネットワークまたは VLAN ネットワークインターフェースにでき
る。フラットネットワークインターフェースは、フラットマネージャーを用い
353
OpenStack 運用ガイド
February 1, 2016
て flat_interface により制御される。VLAN ネットワークインターフェース
は、VLAN マネージャーの vlan_interface オプションにより制御される。
プロジェクト
プロジェクトは OpenStack における「所有権」の基本的な単位で、OpenStack
におけるあらゆるリソースは何らかのテナントに属する。 OpenStack Identity
では、プロジェクトは特定のドメインに何らかのドメインに属する。
プロジェクト ID
Compute でユーザーが定義した英数文字列。プロジェクトの名前。
プロジェクト VPN
cloudpipe の別名。
プロミスキャスモード
ネットワークインターフェースが、そこを指定されたフレームだけではなく、
ホストに届いたすべての通信を渡すようにする。
保護プロパティー
クラウド管理者のみがアクセスできる、Image service のイメージの追加プロ
パティー。どのユーザーロールがそのプロパティーにおいて CRUD 操作を実行
できるかを制限する。クラウド管理者は、保護されたイメージのプロパティー
をすべて設定できる。
プロバイダー
すべてのホストやインスタンスへアクセス権を持つ管理者。
プロキシノード
Object Storage プロキシサービスを提供するノード。
プロキシサーバー
Object Storage のユーザーは、リング中にあるリクエストされたデータの場所
を参照してユーザに結果を返すプロキシサーバーを介して、このサービスに通
信する。
パブリック API
サービス間通信やエンドユーザーの操作などに使用される API エンドポイン
ト。
パブリックイメージ
すべてのテナントが利用できる Image service の仮想マシンイメージ。
パブリック IP アドレス
エンドユーザがアクセス可能な IP アドレス。
公開鍵認証
パスワードの代わりに鍵を使用する認証方式。
354
OpenStack 運用ガイド
February 1, 2016
パブリックネットワーク
compute サーバーがパブリックネットワークと相互通信できるよう、ネット
ワークコントローラーが仮想ネットワークを提供する。全マシンにはパブリッ
クとプライベートのネットワークインターフェースがなければならない。パブ
リックネットワークインターフェースは public_interface オプションにより
制御される。
Puppet
OpenStackがサポートするオペレーティングシステム構成管理ツール。
Python
OpenStack において幅広く使用されるプログラミング言語。
Q
QEMU Copy On Write 2 (QCOW2)
Image service によりサポートされる、仮想マシンイメージディスク形式の 1
つ。
Qpid
OpenStack によりサポートされるメッセージキューソフトウェア。RabbitMQ の
代替。
隔離
Object Storage が壊れたオブジェクト、コンテナー、アカウントを見つけた
際に、そのデータはこの状態にセットされる。この状態にセットされたデータ
は、複製されず、クライアントが読み出すこともできなくなり、正しいコピー
が再複製される。
Quick EMUlator (QEMU)
QEMUはオープンソースのマシンエミュレーターと仮想化ツールである。
OpenStack がサポートするハイパーバイザーの一つ。一般に、開発目的で使用
される。
クォータ
プロジェクト単位を基本として使用できるリソース上限を設定できる、Compute
と Block Storage の機能。
R
RabbitMQ
OpenStackでデフォルトで採用されているメッセージキューのソフトウェア。
355
OpenStack 運用ガイド
February 1, 2016
Rackspace Cloud Files
Rackspace により 2010 年にオープンソースとして公開された。Object
Storage のベース。
RADOS Block Device (RBD)
Linux ブロックデバイスが複数の分散データストアにわたり分割できるように
する、Ceph のコンポーネント。
radvd
ルーター通知デーモン。仮想マシンインスタンスにルーティングサービスを提
供するために、Compute の VLAN マネージャーと FlatDHCP マネージャーによ
り使用される。
rally
Benchmark service を提供する OpenStack プロジェクト。
RAM フィルター
RAM オーバーコミットを有効化または無効化する Compute の設定。
RAM オーバーコミット
実行中の各インスタンスが利用可能と考えている RAM 量に基づく判断をベース
にする代わりに、ホスト上の実際のメモリ使用量をベースにした、新しい VM
インスタンスを起動する機能。
レートリミット
アカウントごと、コンテナーごとにデータベースへの書き込みを制限するため
の、Object Storage 内の設定オプション。
raw
Image service によりサポートされる仮想マシンイメージのディスク形式の 1
つ。
リバランス
リング内のすべてのドライブにわたり、Object Storage のパーティションを分
散させる処理。初期リング作成中、リング再設定後に使用される。
リブート
サーバーのソフトリブートまたはハードリブート。ソフトリブートの場合、オ
ペレーティングに再起動のシグナルが送信されます。これにより、すべてのプ
ロセスを穏やかにシャットダウンできます。ハードリブートは、サーバーの強
制再起動と同じです。仮想化プラットフォームは、ベースの仮想マシンが一時
停止中の場合や停止中の場合でも、きちんとリブート動作を正常に完了させる
べきです。
リビルド
サーバからすべてのデータを消去し、特定のイメージで置き換える。サーバの
IDとIPアドレスは変更されない。
356
OpenStack 運用ガイド
February 1, 2016
recon
計測項目を収集する Object Storage のコンポーネント。
レコード
特定のドメインに属し、ドメインに関する情報を指定するために使用される。
いくつかの種類の DNS レコードがある。各レコード種別は、そのレコードの
目的を説明するために使用される特定の情報を含む。例えば、mail exchange
(MX) レコードは、特定のドメインのメールサーバーを指定する。name server
(NS) レコードは、ドメインの権威ネームサーバーを指定する。
レコード ID
変更が行われる度に増加するデータベース内の数値。Object Storage が複製を
行う際に使用する。
Red Hat Enterprise Linux (RHEL)
OpenStack と互換性のある Linux ディストリビューション。
リファレンスアーキテクチャー
OpenStack クラウドの推奨アーキテクチャー。
リージョン
専用の API エンドポイントを持つ、分離した OpenStack 環境。一般的に
Identity (keystone) のみを他のリージョンと共有する。
レジストリー
Image service レジストリの別名。
レジストリサーバー
クライアントに仮想マシンイメージメタデータ情報を提供する Image
service。
Reliable, Autonomic Distributed Object Store (RADOS)
Ceph 内にオブジェクトストレージを提供するコンポーネント群。OpenStack
Object Storage に似ている。
Remote Procedure Call (RPC)
内部サービス通信のために Compute RabbitMQ により使用される方法。
レプリカ
Object Storage のオブジェクト、アカウント、コンテナーのコピーを作成する
ことで、データ冗長性や耐障害性を実現する。これにより、バックエンドのス
トレージが故障した場合でもデータは失わない。
レプリカ数
Object Storage リングにおけるデータ複製数。
357
OpenStack 運用ガイド
February 1, 2016
レプリケーション
別の物理デバイスにデータをコピーする処理。耐障害性や性能のために行われ
る。
レプリケーター
オブジェクトの複製を作成および管理する Object Storage のバックエンドプ
ロセス。
リクエスト ID
Compute に送られる各リクエストに割り振られる一意な ID。
レスキューイメージ
インスタンスがレスキューモード時に起動する、特別な種類の仮想マシンイ
メージ。管理者が問題を修正するために、インスタンスのファイルシステムを
マウントできる。
リサイズ
既存のサーバーを別のフレーバーに変更する。サーバーをスケールアップまた
はスケールダウンする。元のサーバーは、問題発生時にロールバックできるよ
う保存される。すべてのリサイズは、元のサーバーを削除するときに、テスト
され、明示的に確認される必要がある。
RESTful
REST を使用する Web サービス API の 1 種。REST は、WWW 向けに使用され
る、ハイパーメディアシステム向けのアーキテクチャーの形式である。
リング
Object Storage データのパーティションへのマッピングを行う。アカウント、
オブジェクト、コンテナーというサービス単位に別々のリングが存在する。
リングビルダー
Object Storage のリングの作成、管理を行い、パーティションのデバイスへの
割り当てを行い、他のストレージノードに設定を転送する。
Role Based Access Control (RBAC)
仮想マシンの起動や停止、パスワードの初期化など、ユーザーが実行できる操
作の事前定義済み一覧を提供する。Identity と Compute においてサポートさ
れる。ダッシュボードを使用して設定できる。
ロール
ユーザーが特定の操作の組を実行すると仮定する人格。ロールは一組の権利と
権限を含みます。そのロールを仮定しているユーザーは、それらの権利と権限
を継承します。
ロール ID
各 Identity service ロールに割り当てられる英数 ID。
358
OpenStack 運用ガイド
February 1, 2016
rootwrap
非特権の「nova」ユーザーが Linux の root ユーザーとして指定したコマンド
一覧を実行できるようにする、Compute の機能。
ラウンドロビンスケジューラー
利用可能なホスト間でインスタンスを平等に分散させる、Compute のスケ
ジューラーの一種。
ルーター
異なるネットワーク間でネットワーク通信を転送する、物理または仮想のネッ
トワークデバイス。
ルーティングキー
Compute の直接交換、ファンアウト交換、トピック交換は、このキーを使用し
て、メッセージを処理する方法を判断する。処理内容は交換形式に応じて変化
する。
RPC ドライバー
Compute が利用するメッセージキューソフトウェアを変更できるようにする仕
組み。例えば、 RabbitMQ を ZeroMQ や Qpid に変更できる。
rsync
オブジェクトの複製をプッシュするために Object Storage により使用され
る。
RXTX キャップ
Compute の仮想マシンインスタンスが送受信できるネットワーク通信量の絶対
制限。
RXTX クォータ
Compute の仮想マシンインスタンスが送受信できるネットワーク通信量のソフ
ト制限。
S
S3
Amazon により提供されるオブジェクトストレージ。Object Storage の機能に
似ている。Image service の仮想マシンイメージのバックエンドとして利用で
きる。
sahara
スケールアウト可能なデータ処理基盤と関連する管理インターフェースを提供
する、OpenStack のプロジェクト。
359
OpenStack 運用ガイド
February 1, 2016
SAML アサーション
認証プロバイダーにより提供されたとおり、ユーザーに関する情報を含む。
ユーザーが認証済みであることを意味する。
スケジューラーマネージャー
仮想マシンインスタンスが起動する場所を決める、Compute のコンポーネン
ト。さまざまな種類のスケジューラーをサポートするために、モジュール型設
計を使用する。
スコープ付きトークン
特定のテナントに関連付けられた Identity service API アクセストークン。
スクラバー
未使用の仮想マシンを確認し、削除する。遅延削除を実装する、Image service
のコンポーネント。
シークレットキー
ユーザーのみが知っているテキスト文字列。リクエストを Compute API に発行
するために、アクセスキーと一緒に使用される。
secure shell (SSH)
暗号化した通信チャネル経由でリモートホストにアクセスするために使用され
るオープンソースのツール。SSH 鍵インジェクションが Compute によりサポー
トされる。
セキュリティーグループ
Compute のインスタンスに適用される、ネットワーク通信のフィルタリング
ルールの集合。
分割オブジェクト
部品に分割された Object Storage の大きなオブジェクト。再構築されたオブ
ジェクトは、連結オブジェクトと呼ばれる。
セルフサービス
IaaS の場合、管理者が介することなく、通常の (特権を持たない) ユーザーが
ネットワークなどの仮想インフラのコンポーネントを管理する機能。
SELinux
アクセス制御ポリシーをサポートするための機構を提供する Linux カーネルセ
キュリティーモジュール。
senlin
クラスタリングサービスを提供する OpenStack プロジェクト。
360
OpenStack 運用ガイド
February 1, 2016
サーバー
そのシステムにおいて動作しているクライアントソフトウェアに具体的なサー
ビスを提供するコンピューター。さまざまなコンピューター処理を管理するこ
ともある。
サーバーは、Compute システムにおける仮想マシンインスタンスである。フ
レーバーとイメージが、サーバーの作成時に必須の要素である。
サーバーイメージ
VM イメージの別名。
サーバー UUID
各ゲスト仮想マシンインスタンスに割り当てられる一意な ID。
サービス
Compute、Object Storage、Image service などの OpenStack のサービス。
ユーザーがリソースにアクセスしたり、操作を実行したりできる 1 つ以上のエ
ンドポイントを提供する。
サービスカタログ
Identity サービスカタログの別名。
サービス ID
Identity のサービスカタログで利用可能な各サービスに割り当てられる一意な
ID。
サービスプロバイダー
サービスを他のシステムエンティティーに提供するシステム。連合認証の場
合、OpenStack Identity がサービスプロバイダーとなる。
サービス登録
自動的にカタログに登録するために、Compute などのサービスを有効化す
る、Identity の機能。
サービステナント
カタログに一覧化される全サービスを含む特別なテナント。
サービストークン
Identity と安全に通信するために Compute により使用される、管理者により
定義されたトークン。
セッションバックエンド
クライアントのセッションを管理するために、horizon により使用される保存
方法。ローカルメモリー、クッキー、データベース、memcached など。
361
OpenStack 運用ガイド
February 1, 2016
セッション持続性
負荷分散サービスの機能の 1 つ。ノードがオンラインである限り、強制的に一
連の接続を同じノードにリダイレクトしようとする。
セッションストレージ
クライアントセッションの保持と追跡を行う Horizon のコンポーネント。
Django のセッションフレームワークを用いて実装されている。
共有
Shared File System サービスにおいて、リモートのマウント可能なファイルシ
ステムのこと。同時に、複数のユーザーが複数のホストから、共有をマウント
したり、アクセスしたりできる。
共有ネットワーク
Shared File System サービスにおいて、Networking サービスとのやり取りを
抽象化するエンティティー。選択したドライバーが Networking サービスとの
やり取りを必要とするモードで動作している場合、共有を作成する際にネット
ワーク共有 (share network) を指定する必要がある。
Shared File Systems API
安定版の RESTful API を提供する Shared File Systems サービス。 Shared
File Systems サービスへのすべてのリクエストの認証と転送を行う。この API
と通信するための python-manilaclient が提供されています。
Shared File Systems サービス
マルチテナントのクラウド環境で共有ファイルシステムを管理するためのサー
ビス群を提供する OpenStack サービス。 OpenStack がブロックベースのスト
レージ管理を、 OpenStack Block Storage サービスプロジェクトとして提供し
ているのと類似している。 Shared File Systems サービスを使うと、リモート
ファイルシステムを作成し、自分のインスタンスからそのファイルシステムを
マウントし、インスタンスからそのファイルシステムの読み書きを行える。こ
のプロジェクトのコード名は manila。
共有 IP アドレス
共有 IP グループ内の仮想マシンインスタンスに割り当てられる IP アドレ
ス。パブリック IP アドレスは、さまざまな高可用性のシナリオで使用する
ために複数サーバーにまたがり共有できる。IP アドレスが別のサーバーと共
有されるとき、クラウドのネットワーク制限が変更され、各サーバーがリッ
スンでき、その IP アドレスに応答できるようになる。オプションとして、
対象サーバーの変更するネットワーク設定を指定できる。共有 IP アドレス
は、keepalive などの多くの標準的なハートビート機能と一緒に使用でき、エ
ラーをモニターし、IP のフェイルオーバーを管理しる。
共有 IP グループ
グループの他のメンバーと IP を共有できるサーバー群。グループ内のサー
バーは、そのグループ内の他のサーバーと 1 つ以上のパブリック IP を共有で
362
OpenStack 運用ガイド
February 1, 2016
きる。共有 IP グループにおける 1 番目のサーバーを除き、サーバーは共有
IP グループの中で起動する必要があります。サーバーは、共有 IP グループ 1
つだけのメンバーになれます。
共有ストレージ
複数のクライアントにより同時にアクセス可能なブロックストレージ。例えば
NFS。
Sheepdog
OpenStack によりサポートされる、QEMU 用の分散ブロックストレージシステ
ム。
Simple Cloud Identity Management (SCIM)
クラウドで認証情報を管理するための仕様。現在、OpenStack によりサポート
されていない。
Single-root I/O Virtualization (SR-IOV)
物理 PCIe デバイスにより実装されるとき、複数の別々の PCIe デバイスとし
て見えるようにできる仕様。これにより、複数の仮想化ゲストが物理デバイス
への直接アクセスを共有できるようになる。同等の仮想デバイス経由より性能
を改善できる。OpenStack Havana 以降のリリースでサポートされている。
サービス水準合意 (SLA; Service Level Agreement)
サービスの可用性を保証する契約上の義務。
SmokeStack
コア OpenStack API に対して自動テストを実行する。Rails で書かれている。
スナップショット
OpenStack ストレージボリュームやイメージの、ある時点でのコピー。スト
レージのボリュームスナップショットは、ボリュームをバックアップするた
めに使用する。イメージスナップショットは、データのバックアップを行っ
たり、新しいサーバー用の「ゴールド」イメージ（設定済みイメージ）として
バックアップしたりするのに使用する。
ソフトリブート
オペレーティングシステムのコマンド経由で、仮想マシンインスタンスが正常
に再起動する、制御された再起動。
ソフトウェア開発ライフサイクル自動化サービス
クラウドサービスをより簡単に利用し、アプリケーション開発プロセスと統合
することを目的とする OpenStack プロジェクト。ソースからイメージまでの手
順を自動化し、アプリケーション中心の開発を単純化します。プロジェクト名
は solum。
363
OpenStack 運用ガイド
February 1, 2016
SolidFire Volume Driver
SolidFire iSCSI ストレージアプライアンス向けの Block Storage ドライ
バー。
solum
ソフトウェア開発ライフサイクル自動化サービスを提供する OpenStack プロ
ジェクト。
SPICE
Simple Protocol for Independent Computing Environments (SPICE) は、ゲス
ト仮想マシンに対するリモートデスクトップアクセスを提供する。VNC の代替
品。SPICE は OpenStack によりサポートされる。
分散優先スケジューラー
新規仮想マシンを合計負荷の最も低いホストで起動しようとする、Compute 仮
想マシンスケジューリングアルゴリズム。
SQL-Alchemy
OpenStack で使われている、オープンソースの Python 用 SQL ツールキット。
SQLite
軽量 SQL データベース。多くの OpenStack サービスでデフォルトの永続スト
レージとして使用されている。
スタック
指定されたテンプレート (AWS CloudFormation テンプレートまたは Heat
Orchestration Template (HOT)) に基づいて、Orchestration により作成、管
理される OpenStack リソース群。
StackTach
Compute AMQP 通信をキャプチャーする、コミュニティーのプロジェクト。デ
バッグに有用。
静的 IP アドレス
固定 IP アドレスの別名。
StaticWeb
コンテナーデータを静的 Web ページとして取り扱う Object Storage の WSGI
ミドルウェアコンポーネント。
ストレージバックエンド
サービスが、iSCSI、NFS、ローカルディスクなどの永続ストレージを使用する
方式。
364
OpenStack 運用ガイド
February 1, 2016
ストレージノード
コンテナーサービス、アカウントサービス、オブジェクトサービスを提供する
Object Storage のノード。アカウントデータベース、コンテナーデータベー
ス、オブジェクトデータベースを制御する。
ストレージマネージャー
さまざまな種類の永続ストレージバックエンドをサポートするために、プラグ
イン可能なインターフェースを提供する XenAPI コンポーネント。
ストレージマネージャーバックエンド
iSCSI や NFS など、XenAPI によりサポートされる永続ストレージ方式。
ストレージサービス
Object Storage のオブジェクトサービス、コンテナーサービス、アカウント
サービスの集合名。
ストラテジー
Image サービスや Identity サービスが使用する認証元を指定する。 Database
サービスでは、データストア用に実装された拡張を指す。
サブドメイン
親ドメイン内のドメイン。サブドメインは登録できない。サブドメインにより
ドメインを委譲できる。サブドメインは、サブドメインを持てるので、第 3 階
層、第 4 階層、第 5 階層と深い階層構造にできる。
サブネット
IP ネットワークの論理分割。
SUSE Linux Enterprise Server (SLES)
OpenStack と互換性のある Linux ディストリビューション。
休止
一時停止された仮想マシンインスタンスの別名。
スワップ
システムにおいて実際に利用可能なメモリーより多くのメモリーをオペレー
ティングシステムにより使用されるディスクベースの仮想メモリー。
swauth
Object Storage の認証と認可のサービス。WSGI ミドルウェア経由で実装され
る。バックエンドの永続的なデータストアとして、Object Storage 自身を使用
する。
swift
オブジェクトストレージサービスを提供する OpenStack コアプロジェクト。
365
OpenStack 運用ガイド
February 1, 2016
swift All in One (SAIO)
単一の仮想マシンに一通りの Object Storage 開発環境を作成すること。
swift ミドルウェア
追加機能を提供する Object Storage のコンポーネントの総称。
swift プロキシサーバー
Object Storage へのゲートとして動作する。ユーザーの認証に責任を持つ。
swift ストレージノード
Object Storage のアカウントサービス、コンテナーサービス、オブジェクト
サービスを実行するノード。
同期ポイント
最新のコンテナーとアカウントのデータベースが Object Storage 内のノード
間で同期された基準時間。
sysadmin
Compute RBAC システムにおけるデフォルトのロールの 1 つ。ユーザーが他の
ユーザーをプロジェクトに追加でき、プロジェクトに関連付けられた仮想マシ
ンイメージを操作でき、仮想マシンインスタンスを起動および終了できるよう
になる。
システム使用状況
通知システムと一緒に動作し、計測項目と使用状況を収集する、Compute のコ
ンポーネント。この情報は課金のために使用できる。
T
Telemetry
OpenStack にメータリングと計測の機能を提供する、統合プロジェク
ト。Telemetry のプロジェクト名は ceilometer。
TempAuth
Object Storage 自身が認証と認可を実行できるようになる、Object Storage
内の認証機能。テストや開発によく使用される。
Tempest
OpenStack コアプロジェクトの trunk ブランチに対してテストを実行するため
に設計された自動ソフトウェアテストスイート。
TempURL
一時的なオブジェクトアクセスのために URL を作成できる Object Storage ミ
ドルウェアコンポーネント。
366
OpenStack 運用ガイド
February 1, 2016
テナント
ユーザーのグループ。Compute リソースへのアクセスを分離するために使用さ
れる。プロジェクトの別名。
テナント API
テナントにアクセス可能な API。
テナントエンドポイント
1 つ以上のテナントと関連付けられた Identity service API エンドポイン
ト。
テナント ID
Identity 内で各テナントに割り当てられる一意な ID。プロジェクト ID は、
テナント ID に対応付けられる。
トークン
OpenStack API やリソースへのアクセスに使用される英数字文字列。
トークンサービス
ユーザーやテナントが認証された後、トークンを管理し、検証する Identity
のコンポーネント。
tombstone
Object Storage のオブジェクトが削除済みであることを示す印をつけるために
使用される。オブジェクトの削除後、他のノードにおいて更新されないことを
保証する。
トピック発行者
RPC コールが実行されるときに作成されるプロセス。メッセージをトピック交
換者にプッシュするために使用される。
Torpedo
OpenStack API に対して自動テストを実行するために使用されるコミュニ
ティープロジェクト。
トランザクション ID
Object Storage の各リクエストに割り当てられる一意な ID。デバッグやト
レースに使用される。
一時
非永続の別名。
一時交換
非永続交換の別名。
367
OpenStack 運用ガイド
February 1, 2016
一時メッセージ
メモリーに保存され、サービスの再起動後に失われるメッセージ。
一時キュー
非永続キューの別名。
TripleO
OpenStack-on-OpenStack プログラム。OpenStack Deployment プログラムの
コード名。
trove
データベースサービスをアプリケーションに提供する OpenStack のプロジェク
ト。
U
Ubuntu
Debian ベースの Linux ディストリビューション。
スコープなしトークン
Identity service デフォルトトークンの別名。
アップデーター
キュー済みや失敗した、コンテナーやオブジェクトに対する更新を処理す
る、Object Storage のコンポーネントのグループの総称。
ユーザー
OpenStack Identity では、エンティティーは個々の API 利用者を表す、特定
のドメインに属する。OpenStack Compute では、ユーザーはロール、プロジェ
クトもしくはその両者と関連付けることができる。
ユーザーデータ
インスタンス起動時にユーザが指定できる BLOB データ。インスタンスはこの
データにメタデータサービスやコンフィグドライブ経由でアクセスできる。 通
常、インスタンスがブート時に実行するシェルスクリプトを渡すために使用さ
れる。
User Mode Linux (UML)
OpenStack がサポートするハイパーバイザーの１つ。
V
VIF UUID
各 Networking VIF に割り当てられる一意な ID。
368
OpenStack 運用ガイド
February 1, 2016
仮想 IP
主たる負荷分散の設定オブジェクト。クライアント通信を受け付ける仮想 IP
とポートを指定する。使用する負荷分散方式、プロトコルなどの詳細も定義す
る。このエンティティは、virtual server、vserver、listener のような負荷
分散製品においても知られている。
仮想CPU (vCPU)
物理 CPU を分割する。インスタンスは、これらの分割したものを使用できる。
Virtual Disk Image (VDI)
Image service によりサポートされる、仮想マシンイメージディスク形式の 1
つ。
VXLAN
大規模なクラウドコンピューティング環境に関連するスケーラビリティー問題
を削減するためのネットワーク仮想化技術。VLAN のようなカプセル化技術を使
用して、Ethernet フレームを UDP パケット内にカプセル化する。
Virtual Hard Disk (VHD)
Image service によりサポートされる、仮想マシンイメージディスク形式の 1
つ。
仮想 IP
負荷分散するサービスへのクライアント接続に使用される負荷分散装置におい
て設定される IP アドレス。受信の接続が、負荷分散の設定に基づいて、バッ
クエンドのノードに分散される。
仮想マシン (VM)
ハイパーバイザー上で動作するオペレーティングシステムインスタンス。一台
の物理ホストで同時に複数の VM を実行できる。
仮想ネットワーク
Networking 内の L2 ネットワークセグメント。
仮想ネットワーク
複数の仮想マシンを使用して、物理ネットワーク上にオーバーレイされる、ス
イッチング、ルーティング、負荷分散、セキュリティーなどのネットワーク機
能の仮想化に関する一般的な用語。
Virtual Network Computing (VNC)
仮想マシンへのリモートコンソールアクセスに使用される、オープンソースの
GUI / CUI ツール。
仮想ネットワークインタフェース (VIF)
Networking のネットワークにおけるポートに差し込まれるインターフェース。
一般的に、仮想マシンに設定された仮想ネットワークインターフェース。
369
OpenStack 運用ガイド
February 1, 2016
仮想ポート
仮想ネットワークへの仮想インタフェースの接続ポイント。
仮想プライベートネットワーク (VPN)
Compute では cloudpipe の形で提供される。 cloudpipe では、特別なインス
タンスを使って、プロジェクト毎を基本として VPN が作成される。
仮想サーバー
仮想マシンやゲストの別名。
仮想スイッチ (vSwitch)
ホストやノードで実行され、ハードウェアのネットワークスイッチの機能を提
供するソフトウェア。
仮想 VLAN
仮想ネットワークの別名。
VirtualBox
OpenStack がサポートするハイパーバイザーの１つ。
VLAN マネージャー
dnsmasq と radvd を提供し、cloudpipe インスタンスとの転送処理をセット
アップする、Compute のコンポーネント。
VLAN ネットワーク
ネットワークコントローラーは、コンピュートのサーバーが、お互いに通信し
たり、パブリックなネットワークと通信したりできるようにするために、仮
想ネットワークを提供する。すべてのマシンは、パブリックネットワークイ
ンターフェースとプライベートネットワークインターフェースを持つ必要が
ある。VLAN ネットワークは、VLAN マネージャーを用いた vlan_interface オ
プションにより制御される、プライベートネットワークインターフェースであ
る。
VM disk (VMDK)
Image service によりサポートされる、仮想マシンイメージディスク形式の 1
つ。
仮想マシンイメージ
イメージの別名。
VM Remote Control (VMRC)
Web ブラウザーを使用して仮想マシンインスタンスのコンソールにアクセスす
る方法。Compute によりサポートされる。
VMware API
Compute で VMware 製品の操作をサポートする。
370
OpenStack 運用ガイド
February 1, 2016
VMware NSX Neutron プラグイン
Neutron における VMware NSX サポートを提供する。
VNC プロキシ
ユーザーが VNC や VMRC 経由で仮想マシンインスタンスのコンソールにアクセ
スできるようにする Compute のコンポーネント。
ボリューム
ディスクを用いたデータストレージ。一般的に、拡張属性をサポートするファ
イルシステムを持つ、iSCSI ターゲットとして利用される。永続的なものと一
時的なものがある。
Volume API
Block Storage API の別名。
ボリュームコントローラー
ストレージボリュームの操作を監督、調整する、Block Storage のコンポーネ
ント。
ボリュームドライバー
ボリュームプラグインの別名。
ボリューム ID
Block Storage の管理下にある各ストレージボリュームに適用される一意な
ID。
ボリュームマネージャー
永続ストレージボリュームを作成、接続、切断する Block Storage コンポーネ
ント。
ボリュームノード
cinder-volume デーモンを実行する Block Storage ノード。
ボリュームプラグイン
Block Storage のボリュームマネージャーに対して、新しい特別な種類のバッ
クエンドストレージのサポートを提供する。
ボリュームワーカー
ボリュームの作成や削除、コンピュートボリュームの作成を管理するために、
バックエンドのストレージと相互作用する cinder のコンポーネント。cindervolume デーモンにより提供される。
vSphere
OpenStack がサポートするハイパーバイザーの１つ。
371
OpenStack 運用ガイド
February 1, 2016
W
重み付け
特定のホストがあるジョブ向けの仮想マシンインスタンスに対して適切かどう
かを判断する、Compute の処理。例えば、ホストのメモリー不足、ホストの
CPU 過剰など。
ウェイト
どのストレージデバイスがジョブに対して適切であるかを判断するため
に、Object Storage デバイスにより使用される。デバイスは容量により重み付
けされる。
重み付けコスト
Compute で新しい仮想マシンを起動する場所を判断するときに使用される各コ
ストの合計。
ワーカー
キューをリッスンし、メッセージに応じたタスクを実行するデーモン。例え
ば、cinder-volume ワーカーは、ストレージにおけるボリュームの作成と削除
を管理します。
Workflow サービス
ワークフロー、タスク、状態遷移ルールを書くための YAML ベースの言語を提
供し、それらをアップロード、編集できるサービス、それらを大規模かつ高可
用に実行できるサービス、ワークフローの実行状態および個々のタスクの状態
を管理および監視できるサービスを提供する OpenStack プロジェクト。このプ
ロジェクトのコード名は mistral。
X
Xen
Xen は、マイクロカーネル設計を使用したハイパーバイザー。複数のコン
ピューターオペレーティングシステムを同じコンピューターハードウェアで同
時に実行できるようになるサービスを提供する。
Xen API
Xen 管理 API。Compute によりサポートされる。
Xen Cloud Platform (XCP)
OpenStack がサポートするハイパーバイザーの１つ。
Xen Storage Manager Volume Driver
Xen Storage Manager API と通信できる Block Storage ボリュームプラグイ
ン。
372
OpenStack 運用ガイド
February 1, 2016
XenServer
OpenStack がサポートするハイパーバイザーの１つ。
XFS
Silicon Graphics 社により作成された、高性能な 64 ビットファイルシステ
ム。並列 I/O 処理とデータ一貫性に優れる。
Z
zaqar
メッセージサービスをアプリケーションに提供する OpenStack のプロジェク
ト。
ZeroMQ
OpenStack によりサポートされるメッセージキューソフトウェア。RabbitMQ の
代替。0MQ とも表記。
Zuul
OpenStack 開発で使用されているツールで、変更のテストを正しい順番を保証
しながら並列に実行する。
373
OpenStack 運用ガイド
February 1, 2016
索引
定義,
インスタンストンネルネットワーク,
シンボル
インターネットプロトコル (IP),
インターフェース,
インターフェース ID,
イースト・ウエスト通信,
ウェイト,
エンティティー, 定義,
エンドポイント
API エンドポイント, 60, 93,
エンドポイントテンプレート,
エンドポイントレジストリ,
グローバルエンドポイントテンプ
レート,
テナントエンドポイント,
オブジェクト
Object Storage, 4
オブジェクトオーディター,
オブジェクトサーバー, 83,
オブジェクトハッシュ,
オブジェクトバージョニング,
オブジェクトパスハッシュ,
オブジェクトレプリケーター,
オブジェクト有効期限,
マニフェストオブジェクト,
分割オブジェクト,
定義,
連結オブジェクト,
オブジェクトストレージ
Object Storage API,
Object Storage Device (OSD),
オーバーコミット, 53
カスタマー (参照 テナント)
カスタムモジュール,
カタログ, 95,
カタログサービス,
カプセル化,
カレントワークロード,
キャパシティ
定義,
キュー
一時キュー,
*-manage コマンドラインツール, 93
/var/lib/nova/instances directory,
179
0mq, 41
6to4,
アカウンティング,
アカウント, 76,
アカウントサーバー, 68, 83
アカウントデータベース,
アクセスキー, 94,
アクセス制御リスト (ACL),
アクティブ/アクティブ設定,
アクティブ/パッシブ設定,
アタッチ（ネットワーク）,
アップデーター,
アドレスプール,
アプリケーションカタログ
murano,
アプリケーションサーバー,
アプレット,
アベイラビリティゾーン, 62,
アラート
定義,
アーキテクチャー例 (参照 レガシー
ネットワーク; OpenStack Networking)
イメージ
定義,
追加, 125
イメージサービス
設計上の考慮事項, 43
イングレスフィルタリング,
インジェクション,
インスタンス
インスタンス ID,
インスタンス UUID,
インスタンスタイプ,
インスタンスタイプ ID,
インスタンス状態,
ストレージ・ソリューション, 49
375
OpenStack 運用ガイド
排他キュー,
クォータ, 106-116,
クラウドアーキテクト,
クラウドコントローラー
コンセプト, 37
スケーラビリティ, 58
ネットワークトラフィック, 45
ハードウェアサイジングに関する考
慮事項, 39
役割, 9
管理対象サービス, 37
クラウドコントローラーノード
コマンドラインツール, 93
追加, 59
クラウドコンピューティング
VS. 伝統的実装, 81
クラウドコントローラー,
クラウドコントローラーノード,
コストの最小化, 29
定義,
クラウドデータ管理インターフェー
ス (CDMI:Cloud Data Management
Interface),
クレデンシャル, 44,
グループ,
グローバルエンドポイントテンプレー
ト,
ゲスト OS,
ゲートウェイ,
コア, 47
コアAPI,
コアプロジェクト,
コスト,
コマンドフィルター,
コマンドラインインターフェース
(CLI), 1
コマンドラインツール
API コールの検査, 95
Python Package Index (PyPI), 92
インストール, 92
コンピュートノードの診断, 98
管理系, 93
認証情報の取得, 94
February 1, 2016
コミュニティープロジェクト,
コンソールログ,
コンダクター, 41,
コンテナ
コンテナサーバー, 83
コンテナー
コンテナーオーディター,
コンテナーサーバー,
コンテナーサービス,
コンテナーデータベース,
コンテナーフォーマット,
ストレージの決定, 68
定義,
コンテンツ配信ネットワーク (CDN),
コントローラーノード (参照 アンダー
クラウドコンピューティング)
コンピュートノード
CPU の選択, 47
インスタンスストレージソリュー
ション, 49
オーバーコミット, 53
ネットワーキング, 55
ハイパーバイザーの選択, 48
ファイルシステムの選択, 53
ライブマイグレーション, 53
ロギング, 54
定義,
診断, 98
追加, 59
コンフィグドライブ, 101,
ゴールデンイメージ,
サブドメイン,
サブネット,
サーバー, 96
アプリケーションサーバー,
サーバー UUID,
プロキシサーバー,
レジストリサーバー,
仮想,
定義,
サーバーイメージ,
サービス
376
OpenStack 運用ガイド
February 1, 2016
分離, 40
定義,
概観の取得, 96
サービス ID,
サービスの分離, 40
サービスカタログ,
サービステナント,
サービストークン,
サービスプロバイダー,
サービス妨害 (DoS),
サービス水準合意 (SLA; Service Level
Agreement),
サービス登録,
システム使用状況,
シングルホストネットワーク, 86
シークレットキー,
ジャンボフレーム,
スクラバー,
スクリプトモジュール, 1
スケジューラー
ラウンドロビン,
分散優先,
設計上の考慮事項, 43
スケジューラーマネージャー,
スケーリング
アベイラビリティゾーン, 62
オブジェクトストレージ, 68
クラウドコントローラーノードの追
加, 59
クラウド分割, 60
セルとリージョン, 61
ハードウェア調達, 65
ファイルシステムの選択, 52
ホストアグリゲート, 63
メトリクス, 57
垂直 vs 水平, 57
スコープなしトークン,
スコープ付きトークン,
スタック (参照 Heat Orchestration
Template (HOT))
ストラテジー,
ストレージ
Object Storage, 4
oコンセプトの概要, 72
swift ストレージノード,
ストレージサービス,
ストレージドライバーのサポート,
75
ストレージマネージャー,
ストレージマネージャーバックエン
ド,
バックエンドの選択, 74
ファイルシステムの選択, 53
ブロックストレージ, 4, 70
ライブマイグレーション, 53
一時, 67
ストレージノード,
ストレージバックエンド, 74,
スナップショット,
スワップ, 定義,
セキュリティグループ, 130
セキュリティーグループ,
セキュリティ上の問題
パスワード, 94
セッション
セッションストレージ,
セッションバックエンド,
セッション持続性,
セル
クラウド分割, 61
セルフォワーディング,
セルマネージャー,
子セル,
定義,
親セル,
セルフサービス,
ソフトウェア開発ライフサイクル自動化
サービス,
ソフトリブート,
ダウンロード, 定義,
ダッシュボード, 4, 39, 44, 91,
チャンススケジューラー,
テナント
テナント API,
テナント ID,
テナントエンドポイント,
377
OpenStack 運用ガイド
定義, 103
ディスクパーティショニング, 30
ディスクフォーマット,
ディスク暗号化,
デバイス ID,
デバイスウェイト,
デフォルトテナント,
デフォルトトークン,
デフォルトパネル,
デプロイメント (参照 プロビジョニン
グ/デプロイメント)
デリバリーモード,
データ
データ暗号化,
データストア, 定義,
データベース
データベース ID,
データベースレプリケーター,
設計上の考慮事項, 40
デーモン
基本, 1
定義,
トピック発行者,
トラブルシューティング
DNS 問題, 42
トランザクション ID,
トークン,
トークンサービス,
ドメイン, 定義,
ドライバー
RPC ドライバー,
ネットワーク
Network File System (NFS),
Network Time Protocol (NTP),
VLAN, 85,
ネットワーク ID,
ネットワーク UUID,
ネットワークアドレス変換 (NAT),
ネットワークコントローラー,
ネットワークセグメント,
ネットワークタイムプロトコル
(NTP), 86
February 1, 2016
ネットワークノード,
ネットワークマネージャー,
ネットワークワーカー,
パブリック,
プライベートネットワーク,
マルチホスト, 8, 86
仮想,
定義,
検査, 99
絵ネットワークマネージャ, 84
設定, 32
設計上の考慮事項, 45
開発オプション, 84
ネットワークデザイン
ネットワークサービス, 86
ネットワークトポロジー
deployment options, 84
マルチvsシングルホストネット
ワーク, 86
管理ネットワーク, 81
ネットワーク名前空間,
ネットワーク設計
IPアドレス計画, 82
ネットワークトポロジー
OpenStack VMとVLAN, 85
パブリックアドレスオプション, 82
第1段階, 81
ノース・サウス通信,
ノード
swift ストレージノード,
ストレージノード,
プロキシノード,
定義,
ハイパースレッディング, 47
ハイパーバイザー
KVM, 6
コンピュートノードの診断, 98
ハイパーバイザープール,
定義,
選択, 48
ハイパーリンク,
ハイブリッドクラウド,
ハードウェア
378
OpenStack 運用ガイド
仮想ハードウェア, 57
拡張性プランニング, 65
設計上の考慮事項, 39
ハードリブート,
バイト, 定義,
バイナリ
バイナリオブジェクト, 68
定義,
バックエンドの対話
store, 74
バックエンド操作
カタログ,
ストア,
定義,
パスワード, 94
パブリック API,
パブリック IP アドレス,
パブリックイメージ,
パブリックネットワーク,
パーソナリティーファイル,
パーティション
ディスクパーティショニング, 30
パーティションインデックス,
パーティションインデックス値,
定義,
ビット, 定義,
ビルダーファイル,
ファイアウォール,
ファイバーチャネル,
ファイルシステム
共有, 51
選択, 53
非共有, 52
ファンアウト交換,
フィルタリング
イングレスフィルタリング,
定義,
フラットネットワーク,
フラットモードインジェクション,
フレーバー, 57,
フレーバー ID,
フロントエンド, 定義,
ブラウザー, 定義,
February 1, 2016
ブロックストレージ, 4, 70
ブロックデバイス, 72,
ブロックマイグレーション, 53,
ブータブルディスクイメージ,
プライベート IP アドレス,
プライベートイメージ,
プライベートネットワーク,
プラグイン, 定義,
プロキシサーバー,
プロキシノード,
プロジェクト
プロジェクト ID,
プロジェクト VPN,
定義, 103,
現在の一覧の取得, 100
プロバイダー,
プロビジョニング/デプロイメント
tips for, 34
ネットワークでプロ忌めんとオプ
ション, 84
自動デプロイメント, 29
自動設定, 33
遠隔管理, 33
プロビジョニング/構築
構築シナリオ, 40
プロミスキャスモード,
プール,
プールメンバー,
ヘルスモニター,
ベースイメージ,
ホスト, 定義,
ホストアグリゲート, 63,
ボタンクラス,
ボリューム
Volume API,
ボリューム ID,
ボリュームコントローラー,
ボリュームドライバー,
ボリュームノード,
ボリュームプラグイン,
ボリュームマネージャー,
ボリュームストレージ, 70
ボリュームワーカー,
379
OpenStack 運用ガイド
ポリシーサービス,
ポート
ポート UUID,
仮想,
定義,
マイグレーション, 4, 53,
マニフェスト
マニフェストオブジェクト,
定義,
マネジメント API (参照 管理 API)
マネージャー,
マルチスレッド, 47
マルチホスト,
マルチホストネットワーク, 8, 42, 86
メカニズムドライバー,
メタデータ
OpenStack イメージサービス, 43
メタデータエージェント,
メッセージ
一時メッセージ,
永続メッセージ,
設計上の考慮事項, 41
非永続キュー,
非永続交換,
メッセージキュー, 41,
メッセージバス,
メッセージブローカー,
メモリーオーバーコミット,
メンバーシップ,
メンバーシップリスト,
モジュール、タイプ, 1
モニター (LBaaS),
モニター (Mon),
ユーザー, 定義,
ユーザーデータ,
ユーザートレーニング
セキュリティグループ, 130
ユーザー管理
クォータ, 106
プロジェクトの追加, 104
ユーザーの一覧表示, 100
用語, 103
February 1, 2016
ライブマイグレーション, 4, 53, 73,
ラウンドロビンスケジューラー,
ラージオブジェクト,
リクエスト ID,
リサイズ,
リバランス,
リビルド,
リファレンスアーキテクチャー,
リブート
ハード対ソフト,
,
リング
リングビルダー,
定義,
リージョン, 61,
ルーター,
ルーティングキー,
レガシーネットワーク (nova)
vs. OpenStack Networking
(neutron), 8
オプションの拡張機能, 10
コンポーネントの概要, 4
サポート対象機能, 4
詳しい説明, 8
選択の理由, 5
レガシーネットワーク(nova)
マルチホストネットワークの利点, 8
レコード
basics of,
レコード ID,
レジストリサーバー,
レジストリー (参照 Image サービス)
レスキューイメージ,
レプリケーション
レプリカ数,
レプリケーター,
定義,
レートリミット,
ロール
ロール ID,
定義,
ワーカー, 38,
一時イメージ,
380
OpenStack 運用ガイド
一時キュー,
一時ボリューム,
一時メッセージ,
一時交換 (参照 非永続交換)
一時停止,
一貫性ウインドウ,
交換,
交換種別,
仮想 IP,
,
仮想 VLAN,
仮想CPU (vCPU),
仮想サーバー,
仮想スイッチ (vSwitch),
仮想ネットワーク,
,
仮想ネットワークインタフェース
(VIF),
仮想プライベートネットワーク (VPN),
仮想ポート,
仮想マシン, 57
仮想マシン (VM),
仮想マシンイメージ,
仮想化技術, 47
休止, 定義,
作業環境
users and projects, 100
コマンドラインツール, 91
ダッシュボード, 91
ネットワークの検査, 99
実行中のインスタンス, 100
保護プロパティー,
充填優先スケジューラー,
公開鍵認証,
共有,
共有 IP アドレス,
共有 IP グループ,
共有ストレージ, 51,
共有ネットワーク,
分割オブジェクト,
分割メソッド, 60
分散仮想ルーター (DVR),
分散優先スケジューラー,
割り当て, 定義,
February 1, 2016
割り当て解除, 定義,
同期ポイント,
固定 IP アドレス,
固定IPアドレス, 82, 82
圧縮,
外部ネットワーク, 定義,
多要素認証,
子セル,
帯域
制限, 129
定義,
帯域幅
ハードウェアの仕様, 59
承認, 44
拡張
定義,
拡張仕様, 定義,
拡張属性 (xattr),
拡張機能
設計上の考慮事項, 43
排他キュー,
接続, 定義,
暗号化, 定義,
最大転送単位 (MTU),
永続キュー,
永続ボリューム,
永続メッセージ,
永続交換,
監査,
直接交換,
直接使用者,
直接発行者,
確保, 定義,
管理 API,
管理サーバー,
管理ネットワーク, 81,
絶対制限,
育成プロジェクト,
自動 ACK,
自動宣言,
自動設定, 33
親セル,
設定オプション
381
OpenStack 運用ガイド
高可用性, 59
設計上の考慮事項
API サポート, 42
イメージ, 43
コンダクターサービス, 41
サービスの分離, 40
スケジューリング, 43
ダッシュボード, 44
データベースの選択, 40
ネットワーク, 45
ネットワーク設計, 81
ハードウェアの考慮点, 39
メッセージキュー, 41
拡張機能, 43
認証/承認, 44
設計上の考慮点
クラウドコントローラーサービス,
37
認可,
認可ノード,
,
認証, 38, 44, 94,
認証トークン, 95,
認証局 (Compute),
認証情報, 94
論理ボリュームマネージャー (LVM),
識別情報プロバイダー
basics of,
負荷分散,
超過利用,
退避, 定義,
連合認証,
連結オブジェクト,
遅延削除,
運用者,
重み付け,
重み付けコスト,
重複排除,
関連付け解除,
隔離,
静的 IP アドレス,
非推奨認証,
非永続キュー,
February 1, 2016
非永続ボリューム (参照 一時ボリュー
ム)
非永続交換,
高可用性, 59,
A
access control list (ACL), 176
account auditor,
account quotas, 111
account reaper,
account server,
account service,
accounts, 119
ACL (参照 アクセス制御リスト)
Active Directory, 39,
address pool, 162
Address Resolution Protocol (ARP),
admin API, 122
advanced configuration (参照
configuration options)
Advanced Message Queuing Protocol
(AMQP), 6, 38, 60,
Advanced RISC Machine (ARM),
alerts
intelligent, 227
(参照 logging/monitoring)
resource, 223
Amazon Kernel Image (AKI),
Amazon Machine Image (AMI),
Amazon Ramdisk Image (ARI),
AMD 仮想化, 47
Anvil,
Apache, 44,
Apache License 2.0,
Apache Web Server,
API (application programming
interface)
API エンドポイント,
API キー,
API サーバー,
API トークン,
API バージョン,
382
OpenStack 運用ガイド
February 1, 2016
API 拡張,
API 拡張プラグイン,
パブリック API,
設計上の考慮事項, 42
API (Application Programming
Interface)
API エンドポイント, 93
API コール、検査, 95
Application Service Provider (ASP),
rally,
Bexar,
binary
binary results in trending, 229
block device, 163
Block Storage, 113, 233,
block storage, 140, 163
Block Storage API,
BMC (Baseboard Management
Controller),
Bootstrap Protocol (BOOTP),
Border Gateway Protocol (BGP),
bps,
bugs, reporting, 254
builder files, 234
burn-in testing, 66
arptables,
Asynchronous JavaScript and XML
(AJAX),
ATA over Ethernet (AoE),
auditor,
Austin,
AuthN,
authorization, 120
AuthZ,
AWS (Amazon Web Services),
AWS CloudFormation テンプレート,
B
C
backup restore and disaster recovery
as a service,
backup/recovery
considerations, 231
databases, 232
file systems, 232
items included, 231
recovering backups, 234
bandwidth
design considerations for, 45
recognizing DDOS attacks, 123
プライベート vs. パブリックネット
ワークの推奨事項, 70
barbican,
Bare metal service
ironic,
bare, 定義,
base image, 129
Bell-LaPadula モデル,
Benchmark サービス
CA (認証局),
cache pruner,
Cactus,
CALL,
capability
scaling and, 65
capacity cache,
capacity planning, 65
capacity updater,
CAST (RPC プリミティブ),
ceilometer, 224,
CentOS, 4,
Ceph, 76,
CephFS,
CERN (European Organization for
Nuclear Research), 280
Challenge-Handshake Authentication
Protocol (CHAP),
changes since,
Chef, 29, 89,
cinder, 92,
CirrOS,
Cisco neutron プラグイン,
cloud controllers
enabling RabbitMQ, 219
383
OpenStack 運用ガイド
file system backups and, 232
log information, 215
new compute nodes and, 183
planned maintenance of, 172
process monitoring and, 221
rebooting, 172
scalability and, 266
total failure of, 173
Cloud Infrastructure Management
Interface (CIMI),
cloud-init,
cloudadmin,
Cloudbase-Init (参照 cloud-init)
cloudpipe
cloudpipe イメージ,
定義,
Clustering,
CMDB (構成管理データベース),
Command-line interface (CLI), 187
Common Internet File System (CIFS),
Compute
Compute API,
Compute サービス, 107,
コンピュートコントローラー,
コンピュートホスト,
コンピュートワーカー,
定義,
最もシンプルなアーキテクチャー, 4
compute nodes
adding, 183
backup/recovery of, 232
failures, 178
maintenance, 173
config drive, 158
configuration management, 182
configuration options
geographical storage
considerations, 264
high availability, 263
IPv6 support, 263
periodic task implementation, 262
security, 263
February 1, 2016
wide availability of, 261
congress,
containers
quota setting, 111
Containers サービス
magnum,
cooperative threading, 262
CPU (central processing unit)
overcommitting, 53
ハイパースレッディングをオンにす
る, 48
選択, 47
Cross-Origin Resource Sharing
(CORS),
Crowbar,
CSAIL (Computer Science and
Artificial Intelligence Lab), 278
cURL, 95
customization
custom log statements, 218
dashboard, 252
development environment creation
for, 238
Object Storage, 240
OpenStack Compute (nova)
Scheduler, 247
paths available, 237
D
DAC (discretionary access control),
128
DAC (任意アクセス制御),
daemons
running on CLI, 187
DAIR, 279
dashboard, 252
data
inspecting/recovering failed
instances, 175
preventing loss of, 231
Data processing サービス
sahara,
Database サービス,
384
OpenStack 運用ガイド
databases
backup/recovery of, 232
Image service, 127
instance information in, 169
maintenance/debugging, 184
nova-network troubleshooting, 204
Debian,
debugging (参照 logging/monitoring;
maintenance/debugging)
Designate,
Desktop-as-a-Service,
developer,
development environments, creating,
238
DevStack
customizing dashboard, 252
customizing Object Storage
(swift), 240
customizing OpenStack Compute
(nova) scheduler, 247
development environment creation,
238
定義,
DHCP (Dynamic Host Configuration
Protocol)
basics of,
debugging, 205
DHCP エージェント,
DHTML (Dynamic HyperText Markup
Language),
Diablo,
dispersion,
Django, 252,
DNS
DNS レコード,
DNS (Domain Name Server, Service or
System)
debugging, 209
DNS エイリアス, 42
DNS (Domain Name Serverサービス、シ
ステム)
DNS サービスの選択, 87
February 1, 2016
DNS (ドメインネームシステム、サー
バー、サービス)
定義,
DNS サービス
designate,
dnsmasq,
Docker, 48
drivers
differences between, 261
DRTM (dynamic root of trust
measurement),
E
EBS ブートボリューム,
ebtables,
EC2
EC2 API,
EC2 アクセスキー,
EC2 シークレットキー,
EC2 互換 API,
Elastic Block Storage (EBS),
Essex,
ESX ハイパーバイザー, 48
ESXi ハイパーバイザー, 48,
ETag,
euca2ools,
Eucalyptus Kernel Image (EKI),
Eucalyptus Machine Image (EMI),
Eucalyptus Ramdisk Image (ERI),
F
FakeLDAP,
Fedora,
Fibre Channel over Ethernet (FCoE),
file injection, 162
file systems
backup/recovery of, 232
Firewall-as-a-Service (FWaaS),
Flat マネージャー,
FlatDHCP マネージャー,
flavor, 128
floating IP address, 4, 204
385
OpenStack 運用ガイド
February 1, 2016
Floating IP アドレス,
Folsom,
FormPost,
freezer,
Fully Automatic Installation (FAI),
32
functional testing, 246
G
Hyper-V, 48,
hypervisors
differences between, 261
複数実行, 49
I
generic receive offload (GRO),
generic routing encapsulation (GRE),
glance
glance API サーバ, 43
glance API サーバー,
glance registry, 43
Glance レジストリ,
python-glanceclient, 92
GlusterFS, 77,
Governance service
congress,
Graphic Interchange Format (GIF),
Graphics Processing Unit (GPU),
Green Threads,
Grizzly, 3,
H
Hadoop,
Hadoop Distributed File System
(HDFS),
handover,
hard drives, replacing, 181
hardware
maintenance/debugging, 183
Havana, 3,
heat,
Heat Orchestration Template (HOT),
help, resources for, 253
high availability, 263
horizon プラグイン,
Host Bus Adapter (HBA),
IaaS (Infrastructure-as-a-Service)
basics of,
Icehouse
定義,
ID 番号,
Identity
backup/recovery, 233
basics of,
Identity バックエンド,
イメージ ID,
プラグインサポート, 44
認証の判定, 44
Identity service
Identity service API, 103
サービスおよびエンドポイントの表
示, 97
Identity サービス
Identity service API,
IDS (Intrusion Detection System),
image quotas, 107
Image service
backup/recovery of, 233
database tables, 127
quota setting, 107
データベースクエリー, 127
Image サービス
Image サービス API,
イメージ UUID,
イメージキャッシュ,
イメージストア,
イメージメンバーシップ,
イメージレジストリー,
イメージ所有者,
イメージ状態,
パブリックイメージ,
images
386
OpenStack 運用ガイド
CLI options for, 127
deleting, 127
sharing between projects, 126
INI,
instances
boot failures, 158
database information, 169
instance-specific data, 159
maintenance/debugging, 174
starting, 157
実行中の一覧, 100
Intel 仮想化技術/primary>, 47
intelligent alerting, 227
interface states, checking, 191
Internet Control Message Protocol
(ICMP),
Internet Service Provider (ISP),
Internet Small Computer System
Interface (iSCSI),
IOPS
定義,
ip a command, 191
IP Address Management (IPAM),
IP addresses
floating, 162, 204
IP アドレス
floating, 4
Floating,
shared,
パブリック,
プライベート,
固定,
定義,
静的,
ip6tables,
IPL (Initial Program Loader),
IPMI (Intelligent Platform
Management Interface),
ipset,
iptables, 203,
IPv6, enabling support for, 263
IPアドレス
アドレス計画, 82
February 1, 2016
パブリックアドレスオプション, 82
分類, 82
固定, 82, 82
ironic,
iSCSI Qualified Name (IQN),
iSCSI プロトコル,
ISO9660 形式,
itsec,
J
Java,
JavaScript,
JavaScript Object Notation (JSON),
Jenkins,
Juno,
database-as-a-service tool, 303
nova network deprecation, 301
K
Kerberos,
kernel-based VM (KVM) ハイパーバイ
ザー, 6, 48,
Key management サービス
barbican,
keystone, 92,
Kickstart,
Kilo,
Compute bare-metal deployment,
303
Compute V3 API, 303
scheduler improvements, 304
upcoming release of, 297
upgrades in, 301
L
L2 エージェント,
L2 ネットワーク,
L3 エージェント,
L3 ネットワーク,
Launchpad,
Liberty,
IPv6 support, 263
387
OpenStack 運用ガイド
libvirt,
Lightweight Directory Access
Protocol (LDAP),
Linux コンテナ (LXC), 48
Linux コンテナー （LXC）,
Linux ブリッジ
neutron プラグイン,
live snapshots, 165
Load-Balancer-as-a-Service (LBaaS),
logging/monitoring
adding custom log statements, 218
ceilometer project, 224
central log management, 219
intelligent alerting, 227
log location, 215
logging levels, 216
OpenStack-specific resources, 224
process monitoring, 222
RabbitMQ web management
interface, 219
reading log messages, 216, 217
resource alerting, 223
StackTack tool, 224
tailing logs, 186
trending, 228
コンピュートノードおよび, 54
LVM (Logical Volume Manager), 78
M
magnum,
mailing lists, 253
maintenance/debugging, 171-189
(参照 troubleshooting)
/var/lib/nova/instances, 179
cloud controller planned
maintenance, 172
cloud controller total failure,
173
complete failures, 181
compute node planned maintenance,
173
compute node reboot, 174
February 1, 2016
compute node total failures, 178
configuration management, 182
databases, 184
determining component affected,
186
hardware, 183
instances, 174
rebooting following, 172
reporting bugs, 254
schedule of tasks, 185
storage node reboot, 180
storage node shut down, 180
swift disk replacement, 181
uninstalling, 189
volumes, 178
manila,
melange,
memcached,
Message サービス
zaqar,
Meta-Data Server (MDS),
metadata
instance metadata, 159
metering/telemetry, 224
migration, 73
mistral,
MIT CSAIL (Computer Science and
Artificial Intelligence Lab), 278
Mitaka,
Modular Layer 2 (ML2) neutron プラグ
イン,
monasca,
monitoring
intelligent alerting, 227
metering and telemetry, 224
OpenStack-specific resources, 224
process monitoring, 222
resource alerting, 223
trending, 228
(参照 logging/monitoring)
Monitoring,
MultiNic, 86,
murano,
388
OpenStack 運用ガイド
N
February 1, 2016
Nagios, 222
namespaces, troubleshooting, 212
Nebula,
NeCTAR Research Cloud, 277
netadmin,
NetApp ボリュームドライバー,
network design
network topology
multi-NIC provisioning, 86
network namespaces, troubleshooting,
212
Networking API,
networks
configuration management, 182
neutron
Networking API,
neutron プラグイン,
neutron マネージャー,
python-neutronclient, 92
Newton,
Nexenta ボリュームドライバー,
NIC (network interface cards), 81
No ACK,
nodes
adding, 183
storage nodes, 180
nova
Compute API,
deprecation of, 301
nova-network,
python-novaclient, 92
O
Object Storage
adding nodes, 184
backup/recovery of, 234
customization of, 240
geographical considerations, 264
Object Storage API, 67
quota setting, 111
最もシンプルなアーキテクチャー, 4
objects
persistent storage of, 67
ストレージの決定, 68
Ocata,
Oldie,
Open Cloud Computing Interface
(OCCI),
Open Virtualization Format (OVF),
Open vSwitch,
neutron プラグイン,
troubleshooting, 210
Open vSwitch (OVS) エージェント,
OpenLDAP,
OpenStack
basics of,
documentation, 253
コード名,
モジュールタイプ, 1
OpenStack community
additional information, 259
contributing to, 258
customization and, 237
getting help from, 253
reporting bugs, 254
security information, 258
use cases
CERN, 280
DAIR, 279
MIT CSAIL, 278
NeCTAR, 277
working with roadmaps
aspects to watch, 300-304
influencing, 299
release cycle, 297
OpenStack Networking (neutron)
third-party component
configuration, 22
コンポーネント概要, 11
設定指針, 11
詳細, 13
OpenStack コミュニティー
参加, 258
openSUSE,
389
OpenStack 運用ガイド
February 1, 2016
Orchestration,
orphan,
Oslo,
cloud controller or storage
proxy, 172
compute node, 174
recon,
recovery, 234
(参照 backup/recovery)
Red Hat Enterprise Linux (RHEL),
Reliable, Autonomic Distributed
Object Store (RADOS),
Remote Procedure Call (RPC),
resources
generic vs. OpenStack-specific,
224
resource alerting, 223
RESTful Web サービス,
rings
ring builders, 234
Role Based Access Control (RBAC),
P
Paste framework, 240
path failures, 201
path MTU discovery (PMTUD),
PCI パススルー,
periodic tasks, 262
persistent storage, 67
ping packets, 192
pip ユーティリティ, 92
Platform-as-a-Service (PaaS),
preseed, 定義,
process monitoring, 222
Project Members tab, 118
projects
sharing images between, 126
Puppet, 29, 89,
Python, 240, 252,
Python Package Index (PyPI), 92
rollbacks
preparing for, 266
process for, 272
rootwrap,
RPC ドライバー,
rsync,
rsyslog, 220
RXTX キャップ/クォータ,
Q
QEMU Copy On Write 2 (QCOW2),
Qpid, 41,
Quick EMUlator (QEMU), 48,
R
S
RabbitMQ, 41, 219,
Rackspace Cloud Files,
RADOS Block Device (RBD),
radvd,
RAID (Redundant Array of Independent
Disks), 30
rally,
RAM オーバーコミット, 53,
RAM フィルター,
raw 形式,
RDO (Red Hat Distributed OpenStack),
4, 11
reboot
S3 ストレージサービス,
sahara,
SAML アサーション,
scaling
burn-in testing, 66
capacity planning, 65
schedulers
customization of, 247
secure shell (SSH),
security groups, 162
security issues
configuration options, 263
failed instance data inspection,
175
390
OpenStack 運用ガイド
February 1, 2016
middleware example, 240
reporting/fixing vulnerabilities,
258
scheduler example, 247
SELinux,
senlin,
servers
不安定性の回避, 65
service restoration, 181
shared file system storage
shared file systems service, 67
Shared File Systems API,
Shared File Systems サービス,
Sheepdog, 79,
Simple Cloud Identity Management
(SCIM),
Single-root I/O Virtualization (SRIOV),
SmokeStack,
SolidFire Volume Driver,
solum,
SPICE (Simple Protocol for
Independent Computing Environments),
SQL-Alchemy,
SQLite,
StackTach, 224,
StaticWeb,
storage
block storage, 140, 163, 233
commodity storage, 75
geographical considerations, 264
object storage, 67
storage proxy maintenance, 172
インストーラーストレージ・ソ
リューション, 49
ストレージワーカー, 38
ファイルレベル, 73
storage node, 180
SUSE Linux Enterprise Server (SLES),
swauth,
swift
Object Storage API, 67,
python-swiftclient, 92
swift middleware, 240
swift ストレージノード,
swift プロキシサーバー,
swift ミドルウェア,
swift All in One (SAIO),
sysadmin,
systems administration (参照 user
management)
T
tailing logs, 187
tcpdump, 201
Telemetry,
telemetry/metering, 224
TempAuth,
Tempest,
TempURL,
testing
burn-in testing, 66
functional testing, 246
tombstone,
Torpedo,
trending
monitoring cloud performance
with, 228
report examples, 229
vs. alerts, 229
TripleO,
troubleshooting
burn-in testing, 66
checking interface states, 191
detecting path failures, 201
DNS issues, 209
getting help, 253
iptables, 203
network namespaces, 212
nova-network database, 204
nova-network DHCP, 205
nova-network traffic, 192
Open vSwitch, 210
OpenStack traffic, 193-200
391
OpenStack 運用ガイド
trove,
U
Ubuntu, 4,
uninstall operation, 189
upgrading
controlling cost of, 266
final steps, 271
pre-upgrade testing, 266
preparation for, 266
process overview, 266
rolling back failures, 272
use cases
CERN, 280
DAIR, 279
MIT CSAIL, 278
NeCTAR, 277
user data, 161
user management
associating users with projects,
118
creating new users, 116
handling disruptive users, 123
User Mode Linux (UML),
user training
block storage, 140, 163
flavors, 128
floating IPs, 162
images, 125
instances, 157, 169
security groups, 162
February 1, 2016
VM Remote Control (VMRC),
VMware API, 48,
VNC プロキシ,
volume
maintenance/debugging, 178
vSphere,
vulnerability tracking/management,
258
W
weight, 65
Workflow サービス
mistral,
X
Xen,
Xen API
Xen Cloud Platform (XCP),
Xen Storage Manager Volume
Driver,
XenServer ハイパーバイザー, 48,
XFS,
Z
zaqar,
ZeroMQ,
ZFS, 78
Zuul,
V
VIF UUID,
Virtual Disk Image (VDI),
virtual extensible LAN (VXLAN),
Virtual Hard Disk (VHD),
Virtual Network Computing (VNC),
VirtualBox,
VLAN ネットワーク,
VLAN マネージャー,
VLANネットワーク, 85
VM disk (VMDK),
392

OpenStack ディストリビューションの比較調査

2016秋・冬のおすすめメニュー

使いたい写真を選ぶ デザインテンプレートを決める 写真

Yahoo! JAPAN はLBaaS をどのようにつくったのか？ ～実

Arup Newsletter 2016-3

ヤフー株式会社：OpenStack [日本語：PDF：1.72MB]