CloudStack 完全ドキュメント - home.apache.org

Apache CloudStack 4.1.0
CloudStack 完全ドキュメント
open source cloud com put ing
CloudStack Apache [FAMILY Given]
CloudStack 完全ドキュメント
Apache CloudStack 4.1.0 CloudStack 完全ドキュメント
著者
CloudStack
Given]
Apache
[FAMILY
Licensed to the Apache Software Foundation (ASF) under one or more contributor license
agreements. See the NOTICE file distributed with this work for additional information regarding
copyright ownership. The ASF licenses this file to you 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.
Apache CloudStack is an effort undergoing incubation at The Apache Software Foundation (ASF).
Incubation is required of all newly accepted projects until a further review indicates that
the infrastructure, communications, and decision making process have stabilized in a manner
consistent with other successful ASF projects. While incubation status is not necessarily a reflection
of the completeness or stability of the code, it does indicate that the project has yet to be fully
endorsed by the ASF.
CloudStack 完全ドキュメント
1. コンセプト
1.1. CloudStack とは ..........................................................................................................
1.2. CloudStack の機能 ......................................................................................................
1.3. 展開アーキテクチャの概要 ..............................................................................................
1.3.1. 管理サーバーについて ........................................................................................
1.3.2. クラウドインフラストラクチャの概要 ........................................................................
1.3.3. ネットワーク ........................................................................................................
1
1
1
2
3
4
5
2. クラウドインフラストラクチャのプロビジョニング
7
2.1. リージョンについて ......................................................................................................... 7
2.2. ゾーンについて .............................................................................................................. 7
2.3. ポッドについて ............................................................................................................... 9
2.4. クラスタについて ........................................................................................................... 9
2.5. ホストについて ............................................................................................................ 10
2.6. プライマリストレージについて ......................................................................................... 11
2.7. セカンダリストレージについて ........................................................................................ 11
2.8. 物理ネットワークについて .............................................................................................. 11
2.8.1. 基本ゾーンのネットワークトラフィックの種類 .......................................................... 12
2.8.2. 基本ゾーンのゲスト IP アドレス .......................................................................... 13
2.8.3. 拡張ゾーンのネットワークトラフィックの種類 .......................................................... 13
2.8.4. 拡張ゾーンのゲスト IP アドレス .......................................................................... 13
2.8.5. 拡張ゾーンのパブリック IP アドレス ..................................................................... 13
2.8.6. システムにより予約済みの IP アドレス ................................................................. 14
3. インストール
3.1. 対象の読者 ................................................................................................................
3.2. インストール手順の概要 ...............................................................................................
3.3. 最小システム要件 ........................................................................................................
3.3.1. 管理サーバー, データベースとストレージシステムの要件 ........................................
3.3.2. ホスト/ハイパーバイザーの要件 ..........................................................................
3.4. リポジトリの設定 .........................................................................................................
3.4.1. DEBパッケージのリポジトリ ................................................................................
3.4.2. RPM package repository ................................................................................
3.5. 管理サーバーのインストール .........................................................................................
3.5.1. 管理サーバーのインストール ..............................................................................
3.5.2. オペレーティングシステムの準備 .........................................................................
3.5.3. 初期ホストへの管理サーバーのインストール .........................................................
3.5.4. Install the database server .............................................................................
3.5.5. About Password and Key Encryption .............................................................
3.5.6. NFS共有の準備 ...............................................................................................
3.5.7. 追加の管理サーバーの準備と起動 ......................................................................
3.5.8. システム仮想マシンテンプレートの準備 ................................................................
3.5.9. インストールが完了したら次の手順に進みます。 .....................................................
3.6. Building RPMs from Source ......................................................................................
3.6.1. Generating RPMS ..........................................................................................
3.7. DEBパッケージのビルド ................................................................................................
3.7.1. APTリポジトリの設定 ........................................................................................
3.7.2. APTリポジトリの設定 ........................................................................................
3.8. Apache CloudStack の構築に必要なもの .....................................................................
15
15
15
15
15
16
17
17
17
18
18
18
19
20
25
26
29
30
31
31
32
33
34
35
35
4. ユーザーインターフェイス
37
4.1. UIへのログイン ........................................................................................................... 37
4.1.1. End User's UI Overview ................................................................................. 37
iii
CloudStack 完全ドキュメント
4.1.2. Root Administrator's UI Overview ..................................................................
4.1.3. ルート管理者としてのログイン .............................................................................
4.1.4. ルートパスワードの変更 .....................................................................................
4.2. Using SSH Keys for Authentication ...........................................................................
4.2.1. Creating an Instance Template that Supports SSH Keys .................................
4.2.2. Creating the SSH Keypair ..............................................................................
4.2.3. Creating an Instance .....................................................................................
4.2.4. Logging In Using the SSH Keypair .................................................................
4.2.5. Resetting SSH Keys .......................................................................................
37
37
38
39
39
40
41
41
41
5. Steps to Provisioning Your Cloud Infrastructure
5.1. プロビジョニングの概要 ................................................................................................
5.2. リージョンの追加 (オプション) ........................................................................................
5.2.1. 1つめのリージョン: デフォルトリージョン ...............................................................
5.2.2. リージョンの追加 ..............................................................................................
5.2.3. 3番めのリージョンの追加 ..................................................................................
5.2.4. リージョンの削除 ..............................................................................................
5.3. ゾーンの追加 ..............................................................................................................
5.3.1. 基本ゾーンの構成 ............................................................................................
5.3.2. 拡張ゾーンの構成 ............................................................................................
5.4. ポッドの追加 ...............................................................................................................
5.5. クラスタの追加 ............................................................................................................
5.5.1. クラスターの追加:KVM または XenServer ..........................................................
5.5.2. クラスターの追加:vSphere ................................................................................
5.6. ホストの追加 ..............................................................................................................
5.6.1. ホストの追加(XenServer または KVM) ...............................................................
5.6.2. ホストの追加 (vSphere) ....................................................................................
5.7. プライマリストレージの追加 ...........................................................................................
5.7.1. プライマリストレージのシステム要件 ....................................................................
5.7.2. プライマリストレージの追加 ................................................................................
5.8. セカンダリストレージの追加 ..........................................................................................
5.8.1. セカンダリストレージのシステム要件 ....................................................................
5.8.2. セカンダリストレージの追加 ...............................................................................
5.9. 初期化とテスト ............................................................................................................
43
43
44
44
44
45
47
47
48
52
56
57
57
57
59
60
62
62
62
62
63
63
64
64
6. Global Configuration Parameters
67
6.1. グローバル構成パラメーターの設定 ............................................................................... 67
6.2. About Global Configuration Parameters ................................................................... 67
7. Hypervisor Installation
7.1. KVM のインストールと構成 ...........................................................................................
7.1.1. KVM ホストのシステム要件 ...............................................................................
7.1.2. KVM インストールの概要s .................................................................................
7.1.3. オペレーティングシステムの準備 .........................................................................
7.1.4. エージェントのインストールと設定 .......................................................................
7.1.5. libvirt の構成とインストール ..............................................................................
7.1.6. Configure the Security Policies ......................................................................
7.1.7. Configure the network bridges ......................................................................
7.1.8. Configure the network using OpenVswitch ....................................................
7.1.9. Configuring the firewall .................................................................................
7.1.10. CloudStack へのホスト追加 ...........................................................................
7.2. CloudStackのためのCitrix XenServerのインストール .....................................................
7.2.1. XenServerホストのシステム要件 ........................................................................
iv
71
71
71
71
72
73
73
74
75
78
81
82
82
82
7.2.2. XenServerのインストール手順 ........................................................................... 83
7.2.3. XenServer ドメイン0のメモリ設定 ...................................................................... 84
7.2.4. ユーザー名とパスワード ..................................................................................... 84
7.2.5. 時刻同期 ........................................................................................................ 84
7.2.6. ライセンス設定 ................................................................................................. 84
7.2.7. CloudStack XenServer Support Pakcage(CSP)のインストール ........................... 85
7.2.8. XenServer 用のプライマリストレージのセットアップ ............................................... 86
7.2.9. XenServer の iSCSI マルチパスのセットアップ(オプション) ..................................... 87
7.2.10. XenServer の物理ネットワーク設定 .................................................................. 87
7.2.11. XenServer バージョンのアップグレード .............................................................. 91
7.3. VMware vSphereのインストールと構成 ......................................................................... 94
7.3.1. vSphere ホストのシステム要件 .......................................................................... 94
7.3.2. VMware 向けチェックリストを用意します。 ............................................................ 96
7.3.3. vSphereのインストール手順 .............................................................................. 97
7.3.4. ESXiホストセットアップ ...................................................................................... 97
7.3.5. 物理ホストのネットワーク ................................................................................... 97
7.3.6. Storage Preparation for vSphere (iSCSI only) ............................................... 102
7.3.7. Add Hosts or Configure Clusters (vSphere) .................................................. 106
7.3.8. Applying Hotfixes to a VMware vSphere Host .............................................. 106
8. Additional Installation Options
8.1. 使用状況測定サーバーのインストール(オプション) ..........................................................
8.1.1. 使用状況測定サーバーのインストール要件 ........................................................
8.1.2. 使用状況測定サーバーのインストール手順 ........................................................
8.2. SSL (Optional) ........................................................................................................
8.3. Database Replication (Optional) .............................................................................
8.3.1. Failover .......................................................................................................
109
109
109
109
109
110
112
9. 展開アーキテクチャの選択
9.1. 小規模な展開 ...........................................................................................................
9.2. 大規模な冗長セットアップ ...........................................................................................
9.3. 別個のストレージネットワーク ......................................................................................
9.4. 複数ノードの管理サーバー ..........................................................................................
9.5. 複数サイトの展開 ......................................................................................................
113
113
114
115
115
115
10. アカウント
10.1. アカウント、ユーザー、およびドメイン ............................................................................
10.2. LDAP サーバーによるユーザー認証 ...........................................................................
10.2.1. Example LDAP Configuration Commands ..................................................
10.2.2. Search Base ..............................................................................................
10.2.3. Query Filter ...............................................................................................
10.2.4. Search User Bind DN ................................................................................
10.2.5. SSL キーストアのパスとパスワード ..................................................................
119
119
119
120
121
121
121
122
11. User Services Overview
123
11.1. Service Offerings, Disk Offerings, Network Offerings, and Templates ..................... 123
12. プロジェクトによるユーザーとリソースの組織化
12.1. プロジェクトの概要 ..................................................................................................
12.2. プロジェクトの構成 ..................................................................................................
12.2.1. 招待状のセットアップ ....................................................................................
12.2.2. Setting Resource Limits for Projects ..........................................................
12.2.3. プロジェクト作成者の権限の設定 ....................................................................
12.3. 新しいプロジェクトの作成 .........................................................................................
125
125
125
125
126
128
128
v
CloudStack 完全ドキュメント
12.4. プロジェクトへのメンバーの追加 ................................................................................
12.4.1. プロジェクトメンバーになるための招待状の送信 ...............................................
12.4.2. ユーザーインターフェイスでのメンバーの追加 ....................................................
12.5. メンバー招待の受理 ................................................................................................
12.6. プロジェクトの一時停止または削除 ............................................................................
12.7. プロジェクトビューの使用方法 ...................................................................................
129
129
129
130
130
130
13. サービスオファリング
13.1. Compute and Disk Service Offerings ....................................................................
13.1.1. 新しいコンピューティングオファリングの作成 .....................................................
13.1.2. ディスクオファリングの作成 .............................................................................
13.1.3. Modifying or Deleting a Service Offering ...................................................
13.2. System Service Offerings ......................................................................................
13.2.1. Creating a New System Service Offering ....................................................
13.3. Network Throttling ...............................................................................................
13.4. Changing the Default System Offering for System VMs .........................................
133
133
133
134
135
135
135
136
138
14. Setting Up Networking for Users
14.1. Overview of Setting Up Networking for Users .......................................................
14.2. 仮想ネットワークについて ..........................................................................................
14.2.1. 分離ネットワーク ...........................................................................................
14.2.2. 共有ネットワーク ...........................................................................................
14.2.3. 仮想ネットワークリソースの実行時割り当て ......................................................
14.3. ネットワークサービスプロバイダー ..............................................................................
14.4. ネットワークオファリング ............................................................................................
14.4.1. 新しいネットワークオファリングの作成 ..............................................................
141
141
141
141
141
142
142
143
144
15. 仮想マシンの操作
15.1. 仮想マシンの操作 ...................................................................................................
15.2. Best Practices for Virtual Machines ......................................................................
15.3. 仮想マシンのライフサイクル ......................................................................................
15.4. VMの作成 ..............................................................................................................
15.5. 仮想マシンへのアクセス ...........................................................................................
15.6. 仮想マシンの停止と起動 ..........................................................................................
15.7. 仮想マシン、OS、グループの名前変更 .........................................................................
15.8. 仮想マシンのサービスオファリングの変更 ....................................................................
15.9. ホスト間の仮想マシンの移動（手動ライブマイグレーション） ............................................
15.10. 仮想マシンの削除 .................................................................................................
15.11. ISO に関わる作業 .................................................................................................
15.11.1. ISO の追加 ...............................................................................................
15.11.2. 仮想マシンへのISOのアタッチ ......................................................................
147
147
147
148
148
149
150
150
151
151
152
152
152
154
16. ホストの操作
16.1. ホストの追加 ..........................................................................................................
16.2. ホストの計画保守と保守モード ..................................................................................
16.2.1. vCenter と保守モード ..................................................................................
16.2.2. XenServer と保守モード ...............................................................................
16.3. ゾーン、ポッド、およびクラスターの無効化と有効化 ........................................................
16.4. ホストの削除 ..........................................................................................................
16.4.1. XenServer および KVM ホストの削除 ............................................................
16.4.2. vSphere ホストの削除 ..................................................................................
16.5. Re-Installing Hosts ...............................................................................................
16.6. ハイパーバイザーホストの維持 ..................................................................................
155
155
155
155
155
156
156
157
157
157
157
vi
16.7. Changing Host Password ......................................................................................
16.8. ホストの割り当て .....................................................................................................
16.8.1. オーバープロビジョニングとサービスオファリングの制限 .....................................
16.9. VLAN プロビジョニング ............................................................................................
157
158
158
159
17. テンプレートと動作
17.1. テンプレートの作成:概要 ..........................................................................................
17.2. テンプレートの要件 ..................................................................................................
17.3. テンプレートのベストプラクティス ...............................................................................
17.4. デフォルトのテンプレート ..........................................................................................
17.5. プライベートテンプレートとパブリックテンプレート .........................................................
17.6. 既存の仮想マシンからのテンプレートの作成 ...............................................................
17.7. スナップショットからのテンプレートの作成 ...................................................................
17.8. テンプレートのアップロード ........................................................................................
17.9. テンプレートのエクスポート .......................................................................................
17.10. Windows テンプレートの作成 ................................................................................
17.10.1. Windows Server 2008 R2 の Sysprep ......................................................
17.10.2. Windows Server 2003 R2 用システム準備 ................................................
17.11. AMI のインポート ..................................................................................................
17.12. Hyper-V 仮想マシンのテンプレートへの変換 ............................................................
17.13. テンプレートへのパスワード管理機能の追加 .............................................................
17.13.1. Linux オペレーティングシステムのインストール ...............................................
17.13.2. Window オペレーティングシステムのインストール ...........................................
17.14. テンプレートの削除 ................................................................................................
161
161
161
161
161
162
162
163
163
165
165
165
169
170
173
175
175
175
176
18. Working With Storage
18.1. ストレージについて ..................................................................................................
18.2. プライマリストレージ .................................................................................................
18.2.1. Best Practices for Primary Storage .............................................................
18.2.2. Runtime Behavior of Primary Storage ........................................................
18.2.3. ハイパーバイザーのプライマリストレージサポート ...............................................
18.2.4. ストレージタグ ..............................................................................................
18.2.5. プライマリストレージの保守モード ...................................................................
18.3. セカンダリストレージ ................................................................................................
18.4. Working With Volumes .........................................................................................
18.4.1. 新しいボリュームの作成 .................................................................................
18.4.2. Uploading an Existing Volume to a Virtual Machine ...................................
18.4.3. ボリュームのアタッチ .....................................................................................
18.4.4. Detaching and Moving Volumes ................................................................
18.4.5. VM Storage Migration ................................................................................
18.4.6. ボリュームのサイズ変更 .................................................................................
18.4.7. ボリュームの削除とガベージコレクション ..........................................................
18.5. スナップショットに関わる作業 ....................................................................................
18.5.1. Snapshot Job Throttling ............................................................................
18.5.2. スナップショットの自動作成と保持 ...................................................................
18.5.3. 増分スナップショットとバックアップ ...................................................................
18.5.4. ボリュームの状態 .........................................................................................
18.5.5. スナップショットの復元 ...................................................................................
177
177
177
177
177
177
178
178
179
179
179
180
181
182
182
183
184
184
185
185
186
186
186
19. ネットワークとトラフィックの管理
19.1. ゲストトラフィック ....................................................................................................
19.2. Networking in a Pod ............................................................................................
19.3. Networking in a Zone ...........................................................................................
187
187
187
189
vii
CloudStack 完全ドキュメント
19.4. 基本ゾーンの物理ネットワーク構成 ............................................................................
19.5. Advanced Zone Physical Network Configuration ..................................................
19.5.1. 拡張ゾーンのゲストトラフィックの構成 ..............................................................
19.5.2. 拡張ゾーンのパブリックトラフィックの構成 .........................................................
19.6. Using Multiple Guest Networks ............................................................................
19.6.1. ゲストネットワークの追加 ...............................................................................
19.6.2. ゲストネットワーク上のネットワークオファリングの変更 ........................................
19.7. セキュリティグループ ................................................................................................
19.7.1. セキュリティグループについて .........................................................................
19.7.2. セキュリティグループの追加 ...........................................................................
19.7.3. Security Groups in Advanced Zones (KVM Only) .......................................
19.7.4. Enabling Security Groups ..........................................................................
19.7.5. Adding Ingress and Egress Rules to a Security Group ................................
19.8. External Firewalls and Load Balancers .................................................................
19.8.1. About Using a NetScaler Load Balancer ....................................................
19.8.2. Configuring SNMP Community String on a RHEL Server .............................
19.8.3. 外部ファイアウォールとロードバランサーの初期セットアップ .................................
19.8.4. Ongoing Configuration of External Firewalls and Load Balancers ...............
19.8.5. Configuring AutoScale ...............................................................................
19.9. 負荷分散のルール ..................................................................................................
19.9.1. ロードバランサールールの追加 ......................................................................
19.9.2. Sticky Session Policies for Load Balancer Rules .........................................
19.10. Guest IP Ranges .................................................................................................
19.11. 新しい IP アドレスの取得 .......................................................................................
19.12. IP アドレスの開放 .................................................................................................
19.13. 静的 NAT ............................................................................................................
19.13.1. スタティック NAT の有効化、無効化 ..............................................................
19.14. IP Forwarding and Firewalling ............................................................................
19.14.1. Creating Egress Firewall Rules in an Advanced Zone ...............................
19.14.2. ファイアウォールルール ................................................................................
19.14.3. ポート転送 ................................................................................................
19.15. IP Load Balancing ..............................................................................................
19.16. DNSとDHCP .......................................................................................................
19.17. VPN ....................................................................................................................
19.17.1. VPN の構成 ..............................................................................................
19.17.2. Windows での VPN の使用方法 .................................................................
19.17.3. Using VPN with Mac OS X ......................................................................
19.17.4. Setting Up a Site-to-Site VPN Connection ...............................................
19.18. About Inter-VLAN Routing ..................................................................................
19.19. VPC の構成 .........................................................................................................
19.19.1. VPC(Virtual Private Cloud) の概要 ............................................................
19.19.2. VPC の追加 ..............................................................................................
19.19.3. 層の追加 ..................................................................................................
19.19.4. Configuring Access Control List ...............................................................
19.19.5. VPC へのプライベートゲートウェイの追加 ......................................................
19.19.6. 層への仮想マシンの展開 .............................................................................
19.19.7. VPC に対しての新しい IP アドレスの取得 ......................................................
19.19.8. VPC に割り当てられた IP アドレスの開放 ......................................................
19.19.9. VPC での静的 NAT の有効化、無効化 ..........................................................
19.19.10. VPC への負荷分散ルールの追加 ...............................................................
19.19.11. VPC へのポート転送ルールの追加 .............................................................
viii
189
190
190
191
191
191
192
192
192
193
193
193
194
195
195
196
197
198
198
203
203
204
204
204
205
205
205
206
206
207
208
209
209
209
210
210
211
211
218
220
220
222
223
224
226
227
228
228
229
230
231
19.19.12. 層の削除 ................................................................................................
19.19.13. VPC の編集と再起動、削除 .......................................................................
19.20. Persistent Networks ...........................................................................................
19.20.1. Persistent Network Considerations ..........................................................
19.20.2. Creating a Persistent Guest Network .......................................................
232
233
233
234
234
20. システム仮想マシンの操作
20.1. システム仮想マシンテンプレート ................................................................................
20.2. VMware のための複数のシステム仮想マシンのサポート ..............................................
20.3. コンソールプロキシー ...............................................................................................
20.3.1. Using a SSL Certificate for the Console Proxy ............................................
20.3.2. コンソールプロキシの SSL 証明書とドメインの変更 ............................................
20.4. 仮想ルーター ..........................................................................................................
20.4.1. 仮想ルーターの構成 .....................................................................................
20.4.2. システムサービスオファリングによる仮想ルーターのアップグレード .......................
20.4.3. 仮想ルーターのベストプラクティス ...................................................................
20.5. セカンダリストレージ VM ..........................................................................................
237
237
237
237
238
238
239
240
240
240
240
21. システムの信頼性と高可用性
21.1. HA for Management Server ..................................................................................
21.2. Management Server Load Balancing ....................................................................
21.3. 高可用性が有効な仮想マシン ...................................................................................
21.4. ホストの高可用性 ....................................................................................................
21.4.1. Dedicated HA Hosts ..................................................................................
21.5. プライマリストレージの停止とデータ損失 .....................................................................
21.6. セカンダリストレージの停止とデータ損失 ....................................................................
243
243
243
243
243
244
244
244
22. クラウドの管理
22.1. Using Tags to Organize Resources in the Cloud ...................................................
22.2. Changing the Database Configuration ..................................................................
22.3. Changing the Database Password ........................................................................
22.4. 管理者アラート .......................................................................................................
22.5. ネットワークドメイン名のカスタマイズ ..........................................................................
22.6. Stopping and Restarting the Management Server .................................................
245
245
246
246
247
247
248
23. CloudStack API
23.1. プロビジョニングと認証 API ......................................................................................
23.2. アロケーター ...........................................................................................................
23.3. ユーザーデータとメタデータ ......................................................................................
249
249
249
249
24. チューニング
24.1. 性能監視 ...............................................................................................................
24.2. 管理サーバーの最大メモリの増設 ..............................................................................
24.3. データベースのバッファープールサイズの設定 .............................................................
24.4. ホスト毎の仮想マシン数制限の設定と監視 .................................................................
24.5. XenServer の dom0 メモリの構成 ...........................................................................
251
251
251
251
252
252
25. Troubleshooting
25.1. イベント ..................................................................................................................
25.1.1. イベントログ .................................................................................................
25.1.2. Event Notification ......................................................................................
25.1.3. 標準イベント ................................................................................................
25.1.4. 長期間実行するジョブのイベント .....................................................................
25.1.5. Event Log Queries .....................................................................................
253
253
253
253
254
255
255
ix
CloudStack 完全ドキュメント
25.2.
25.3.
25.4.
25.5.
25.6.
25.7.
25.8.
サーバーログに関わる作業 .......................................................................................
エクスポートしたプライマリストレージのデータ損失 .......................................................
喪失した仮想ルーターの復旧 ....................................................................................
vCenter が動作しない際の保守モード .......................................................................
アップロードした vSphere 用テンプレートが展開できない場合 .......................................
VMware 上で仮想マシンの電源が入らない ................................................................
負荷分散ルールがネットワークオファリングを変更すると失敗する ....................................
255
256
256
257
257
258
258
26. Introduction to the CloudStack API
26.1. ロール ...................................................................................................................
26.2. API リファレンス ......................................................................................................
26.3. Getting Started .....................................................................................................
259
259
259
259
27. What's New in the API?
27.1. What's New in the API for 4.1 ..............................................................................
27.1.1. Reconfiguring Physical Networks in VMs ...................................................
27.1.2. IPv6 Support in CloudStack ......................................................................
27.1.3. Additional VMX Settings ............................................................................
27.1.4. Resetting SSH Keys to Access VMs ............................................................
27.1.5. Changed API Commands in 4.1 .................................................................
27.1.6. Added API Commands in 4.1-incubating ...................................................
27.2. What's New in the API for 4.0 ..............................................................................
27.2.1. 4.0.0-incubating で変更された API コマンド ..................................................
27.2.2. Added API Commands in 4.0.0-incubating ................................................
27.3. What's New in the API for 3.0 ..............................................................................
27.3.1. Enabling Port 8096 ...................................................................................
27.3.2. Stopped VM ..............................................................................................
27.3.3. Change to Behavior of List Commands ......................................................
27.3.4. 削除された API コマンド ...............................................................................
27.3.5. 3.0 にて追加された API コマンド ...................................................................
27.3.6. Added CloudStack Error Codes .................................................................
261
261
261
262
265
265
265
267
268
268
271
273
273
273
273
274
274
276
28. CloudStack API の呼び出し
28.1. API リクエストを作成します。 .....................................................................................
28.2. Signing API Requests ...........................................................................................
28.2.1. How to sign an API call with Python ..........................................................
28.3. Enabling API Call Expiration .................................................................................
28.4. Limiting the Rate of API Requests ........................................................................
28.4.1. Configuring the API Request Rate .............................................................
28.4.2. Limitations on API Throttling .....................................................................
28.5. Responses ............................................................................................................
28.5.1. Response Formats: XML and JSON ............................................................
28.5.2. Maximum Result Pages Returned ..............................................................
28.5.3. Error Handling ...........................................................................................
28.6. Asynchronous Commands ....................................................................................
28.6.1. ジョブの状態 ...............................................................................................
28.6.2. 例 ..............................................................................................................
279
279
279
281
282
283
283
283
284
284
284
285
285
285
285
29. Working With Usage Data
29.1. Usage Record Format ...........................................................................................
29.1.1. Virtual Machine Usage Record Format ......................................................
29.1.2. Network Usage Record Format ..................................................................
29.1.3. IP Address Usage Record Format ..............................................................
289
289
289
290
290
x
29.1.4. Disk Volume Usage Record Format ...........................................................
29.1.5. Template, ISO, and Snapshot Usage Record Format ..................................
29.1.6. Load Balancer Policy or Port Forwarding Rule Usage Record Format ..........
29.1.7. Network Offering Usage Record Format ....................................................
29.1.8. VPN User Usage Record Format ................................................................
29.2. 使用状況データの種類 ............................................................................................
29.3. Example response from listUsageRecords ............................................................
29.4. Dates in the Usage Record ..................................................................................
29.5. Globally Configured Limits ...................................................................................
290
291
292
292
293
293
294
295
295
A. タイムゾーン
297
B. イベントの種類
299
C. Alerts
301
xi
xii
コンセプト
1.1. CloudStack とは
CloudStack はオープンソースのソフトウェアプラットフォームで、コンピューティングリソースをプールすること
により、パブリック、プライベート、およびハイブリッドの IaaS(Infrastructure as a Service)クラウドを構築す
ることができます。CloudStack で、クラウドインフラストラクチャを構成するネットワーク、ストレージ、およびコン
ピューティングノードを管理します。 CloudStack を使用して、クラウドコンピューティング環境を展開、管理、お
よび構成します。
本製品の主なユーザーはサービスプロバイダーと企業です。CloudStack を使用すると、次のタスクを実行でき
ます。
• オンデマンドで弾力的なクラウドコンピューティングサービスをセットアップする。サービスプロバイダーはイン
ターネットを経由して、セルフサービスの仮想マシンインスタンス、ストレージボリューム、およびネットワーク
構成を販売できます。
• 従業員が使用するオンプレミスなプライベートクラウドをセットアップする。企業は物理マシンと同じ方法で仮
想マシンを管理せずに、IT 部門を介さずにセルフサービスの仮想マシンをユーザーに提供することができま
す。
1.2. CloudStack の機能
複数のハイパーバイザーのサポート
1
第1章コンセプト
CloudStack はさまざまなハイパーバイザーと連動します。単一のクラウド環境に、ハイパーバイザーの実装を
複数含められます。現在の CloudStack リリースでは、エンタープライズクラスのハイパーバイザーである
Citrix XenServer や VMware vSphere も CentOS, Ubuntu 上の KVM, Xen と同様にサポートされます。
高度にスケーラブルなインフラストラクチャ管理
CloudStack では、地理的に分散した複数のデータセンターに設置される、何万台ものサーバーを管理するこ
とができます。集中型の管理サーバーを直線的に拡張できるので、中間のクラスターレベルの管理サーバーが
不要です。単一のコンポーネントに障害が発生しても、クラスターまたはクラウド全体が停止することはありま
せん。クラウドで実行中の仮想マシンの機能に影響を与えずに、管理サーバーの定期保守を実行できます。
自動的な構成管理
CloudStack では、各ゲスト仮想マシンのネットワークとストレージの設定が自動的に構成されます。
CloudStack では、クラウド自体をサポートする仮想アプライアンスのプールが内部的に管理されます。これら
のアプライアンスにより、ファイアウォール、ルーティング、DHCP、VPN アクセス、コンソールプロキシ、ストレー
ジアクセス、およびストレージ複製などのサービスが提供されます。仮想アプライアンスを幅広く使用することに
よって、クラウド環境のインストール、構成、および継続的な管理を大いに単純化します。
グラフィカルユーザーインターフェイス
CloudStack offers an administrator's Web interface, used for provisioning and managing the cloud,
as well as an end-user's Web interface, used for running VMs and managing VM templates. The UI
can be customized to reflect the desired service provider or enterprise look and feel.
標準 API のサポート
CloudStack はユーザーインターフェイスで使用できるすべての管理機能にプログラムでアクセスするための
API を提供します。API は継続的に保守され、文書化されています。この API を使用すると、個々のニーズに
合ったコマンドラインツールや新しいユーザーインターフェイスを作成できます。『Developer’s Guide』と『API
1
Reference』を参照してください。それぞれ、 Apache CloudStack Guides と Apache CloudStack API
2
Reference から参照できます。
CloudStack のプラッガブルなアロケーターのアーキテクチャはホストやストレージに対する新しいタイプの割
り当てを許容しています。以下のアロケーター実装ガイドも参照して下さい。http://docs.cloudstack.org/
CloudStack_Documentation/Allocator_Implementation_Guide
高可用性
CloudStack は可用性を高めるためシステムに幾つかの機能を持っています。管理サーバーを複数ノードにイ
ンストールし、サーバー間でロードバランシングをすることが出来ます。MySQLをデータベースの障害時に手動
でフェイルオーバーするためレプリケーションの設定をすることも可能でしょう。ホストに対しては CloudStack
はNICのボンディングやiSCSIのマルチパスのようにストレージ通信を分割することをサポートしています。
1.3. 展開アーキテクチャの概要
CloudStack のインストールは、管理サーバーおよび管理サーバーで管理するクラウドインフラストラクチャの 2
つの部分に分けられます。CloudStack クラウドのセットアップと管理においては、ホスト、ストレージデバイス、
および IP アドレスのようなリソースを管理者が管理サーバーに準備し、管理サーバーがそれらのリソースを管
理します。
1
2
http://cloudstack.apache.org/docs/en-US/index.html
http://cloudstack.apache.org/docs/api/index.html
2
管理サーバーについて
最小構成でインストールする場合は、CloudStack 管理サーバーを実行する 1 台のマシンとクラウドインフラ
ストラクチャとして動作するもう 1 台のマシンをセットアップします。この場合のクラウドインフラストラクチャは非
常に単純で、ハイパーバイザーソフトウェアを実行する 1 台のホストで構成されます。最小の展開では 1 台の
マシン上で管理サーバーとハイパーバイザーホストの両方を担うことができます。(その場合、KVM ハイパーバ
イザーを利用します)
A more full-featured installation consists of a highly-available multi-node Management Server
installation and up to tens of thousands of hosts using any of several advanced networking setups.
For information about deployment options, see the "Choosing a Deployment Architecture" section
of the $PRODUCT; Installation Guide.
1.3.1. 管理サーバーについて
管理サーバーは、クラウドリソースを管理する CloudStack ソフトウェアです。ユーザーインターフェイスまたは
API を介して管理サーバーを操作することにより、クラウドインフラストラクチャを構成し管理できます。
管理サーバーは専用のサーバーまたは仮想マシンです。ホストに対する仮想マシンの割り当てを制御し、スト
レージと IP アドレスを仮想マシンインスタンスに割り当てます。CloudStack 管理サーバーは Tomcat コンテ
ナー内で動作し、データ保持のために MySQL データベースを必要とします。
このマシンは「4.3: 最小システム要件」にあるシステム要件を満たしている必要があります。
管理サーバー
• 管理者とエンドユーザーに Web ユーザーインターフェイスを提供します。
• CloudStack プラットフォームの API を提供します。
• 特定ホストに対するゲスト仮想マシンの割り当てを管理します。
• 特定アカウントに対するパブリックおよびプライベート IP アドレスの割り当てを管理します。
• ゲストに対する仮想ディスクとしてのストレージの割り当てを管理します。
• スナップショット、テンプレート、および ISO イメージを管理し、場合によっては複数のデータセンターの間でそ
れらを複製します。
• クラウド構成のための単一の場を提供します。
3
第1章コンセプト
1.3.2. クラウドインフラストラクチャの概要
名前が示すとおり、管理サーバーで 1 つ以上のゾーンを管理します。ゾーンは通常データセンターに相当し、
ゲスト仮想マシンが動作するホストコンピューターを含みます。クラウドインフラストラクチャは次のように組織さ
れます。
• ゾーン:通常、1 つのゾーンは単一のデータセンターに相当します。ゾーンは 1 つ以上のポッドとセカンダリス
トレージから構成されます。
• ポッド:普通、ポッドはレイヤー2スイッチと1つ以上のクラスターを含む1ラック分のハードウェアです。
• クラスター:クラスターは 1 つ以上のホストとプライマリストレージから構成されます。
• ホスト:クラスター内の単一のコンピューティングノードです。実際のクラウドサービスは、ゲスト仮想マシンの
形式でホストから提供されます。
• プライマリストレージはクラスターと関連付けられ、そのクラスター内のホスト上で動作するすべての仮想マ
シンのディスクボリュームを格納します。
• セカンダリストレージはゾーンと関連付けられ、テンプレート、ISO イメージ、およびディスクボリュームのスナッ
プショットを格納します。
4
ネットワーク
詳細情報
より詳細な情報はドキュメントの「クラウドインフラストラクチャコンセプト」を参照してください。
1.3.3. ネットワーク
CloudStack では基本と拡張の 2 種類のネットワーク設定を提供します。
• 基本ネットワーク。基本ネットワーク設定では、AWSスタイルのネットワークの単一共有ネットワークを提供し
ます。セキュリティグループ(発信元 IP アドレスのフィルター) のようなレイヤー3 レベルの方法でゲストを分離
できます。
• 拡張ネットワーク。拡張ネットワー
ク設定は、より洗練されたネットワーク技術をサポートします。このネット
ワークモデルを選択すると、より柔軟にゲストのネットワークを定義できます。
詳しくは、「ネットワークセットアップ」を参照してください。
5
6
クラウドインフラストラクチャのプロビジョニング
2.1. リージョンについて
クラウドの信頼性を高めるために、複数の地理的に異なったリージョンにリソースを分けて配置することができ
ます。\nリージョンは、 CloudStack を構成する要素の中で最も大きい単位です。\nリージョンは、データセン
ターとほぼ同意であるアベイラビリティゾーンにより構成されます。\nそれぞれのリージョンは、リージョン内の1
つのゾーンにある管理サーバ群により管理されます。\nリージョン内の各ゾーンは、地理的に近い場所に配置
します。\nリージョンは、フォールトトレランスとディザスタリカバリを実現する上で有効です。
ゾーンをリージョンとしてグループ化にすることにより、より高い可用性とスケーラビリティを実現することができ
ます。\nユーザアカウントはリージョンをまたいで使用できるため、分散された複数のリージョンにVMを作成す
ることができます。\nリージョンのいずれかが使用できなくなった場合でも、他のリージョンのVMを使ってサー
ビスを継続することができます。\nまた、管理サーバから近いゾーンをグループ化することで、分散された複数
のゾーンを1つの管理サーバ群で管理するのに比べ、クラウド内のレイテンシを軽減できます。
使用状況データもまたリージョンレベルでまとめることができ、リージョンごとのレポート情報が作成できます。
リージョン情報はエンドユーザからも参照できます。ユーザはゲストVMを作成する際、起動させるリージョンを
選択する必要があります。ユーザはまた、選択したリージョン上でゲストVMを作成するためにプライベートテン
プレートをコピーする処理が必要になるかもしれません。
2.2. ゾーンについて
ゾーンは CloudStack 環境内で2番目に大きい組織単位です。1 つのデータセンター内に複数のゾーンを持た
せることはできますが、通常、ゾーンは単一のデータセンターに相当します。インフラストラクチャをゾーンに組織
化すると、ゾーンを物理的に分離して冗長性を持たせることができます。たとえば、各ゾーンに電源とネットワー
クアップリンクを配備します。必須ではありませんが、ゾーンは遠隔地に分散することができます。
7
第2章クラウドインフラストラクチャのプロビジョニング
ゾーンは次のものから構成されます。
• 1つ以上のポッド。各ポッドはホストを含む1つ以上のクラスターと、1つ以上のプライマリストレージサーバー
から構成されます。
• セカンダリストレージ。ゾーン内のすべてのポッドで共有されます。
ゾーンはユーザーが確認することができ、ユーザーがゲストVMを起動させた際ゾーンを選択する必要がありま
す。また、ユーザーは追加ゾーンでプライベートのテンプレートを利用する場合追加ゾーンに対してテンプレート
のコピーを実施する必要があります。
ゾーンはパブリック、プライベートを選択でき、パブリックゾーンは全てのユーザーに対して公開されます。これは
どのユーザーもゾーンに対してゲストVMを作成することを意味します。プライベートゾーンは特定のドメインに
対し予約され、対象ドメインもしくはそのサブドメインのユーザーのみがゾーンに対してゲストVMを作成できま
す。
同一ゾーンのホストはファイアウォールを介さず直接互いにアクセス可能であり、異種ゾーン間のホストは静的
に設定されたVPNトンネルを介して通信します。
各ゾーンに対して管理者は以下について設計する必要があります。
• いくつのポッドをゾーンに配置するか。
8
ポッドについて
• いくつのクラスターを各ポッドに配置するか。
• いくつのホストを各クラスターに配置するか。
• いくつのプライマリストレージサーバーを各クラスターに配置し、総容量をどうするか。
• いくつのセカンダリストレージサーバーをゾーンに配置するか。
新しいゾーンを追加した際は、まずゾーンに対し物理ネットワークや第一のポッド、クラスター、ホスト、プライマリ
ストレージ、セカンダリストレージを設定します。
2.3. ポッドについて
通常、1
つのポッドは単一のラックを表します。同じポッド内のホストは同じサブネットに含まれます。ポッドは
CloudStack� 環境内の 2 番目に大きな組織単位です。ポッドはゾーンに含まれます。各ゾーンは 1 つ以上の
ポッドを含むことができます。基本インストールでは、ゾーン内のポッドは 1 つです。
2.4. クラスタについて
クラスターはホストをグループ化する方法です。これは XenServer のサーバープール、KVM サーバーのセット
もしくは vCenter で事前用意された VMware cluster に相当します。クラスター内の全てのホストはすべて同
一のハードウェアから構成され、同じハイパーバイザーを実行し、同じサブネット上にあり、同じ共有プライマリ
ストレージにアクセスします。仮想マシンインスタンスはクラスター内のあるホストから他のホストにユーザーへ
のサービスを中断せずにライブマイグレーションすることができます。
クラスタはCloudStackの3番目に大きい管理単位です。クラスタはポッドに格納され、ポッドはゾーンに格納さ
れます。クラスタ内のホスト台数は、基盤のハイパーバイザーにより制限されますが、ほとんどの場合
CloudStackはより少ない台数を推奨しますので、ベストプラクティスを確認してください。
クラスタは1つ以上のホストと1つ以上のプライマリストレージから成り立ちます。
9
第2章クラウドインフラストラクチャのプロビジョニング
CloudStackは1つのクラウドに複数のクラスタを含めることを認めています。
ローカルストレージを利用している場合クラスター毎にホストが1つしかない場合でもクラスターを組織化する
必要があります。
VMware を使用する場合、すべての VMware クラスタは vCenter Server に管理されます。管理者は vCenter
を CloudStack に登録する必要があります。1つのゾーンには複数の vCenter Server が存在する可能性があ
ります。それぞれの vCenter Server の配下には、複数の VMware クラスタが存在する可能性があります。
2.5. ホストについて
ホストは単一のコンピューターです。ホストは、ゲスト仮想マシンを実行するコンピューティングリソースを提供し
ます。各ホストにはゲスト仮想マシンを管理するためのハイパーバイザーソフトウェアをインストールします。たと
えば、KVM が有効な Linux サーバー、Citrix XenServer が動作するサーバー、および ESXi サーバーがホス
トです。
ホストは CloudStack 環境内の最小の組織単位です。ホストはクラスターに含まれ、クラスターはポッドに含ま
れ、ポッドはゾーンに含まれます。
CloudStack 環境内のホストには次の機能があります。
• 仮想マシンをホストするために必要な CPU、メモリ、ストレージ、およびネットワークリソースを提供します。
• 高帯域幅の TCP/IP ネットワークに相互接続して、インターネットに接続します。
• 地理的に異なる複数データセンターに横断的に配置されています。
• 1 つのクラスター内のホストはすべて同種である必要がありますが、CPU 速度や RAM サイズなど、能力が
異なる可能性があります。
ゲストVMの能力を向上させるためにいつでもホストを追加できます。
CloudStack は自動的にホストのCPU、メモリのリソースを検出します。
ホストはユーザーに対し不可視であり、ユーザーはどのホストに対しゲストVMが割り当てられているかわかり
ません。
CloudStack 内のホストを機能させるには、次の作業が必要です。
• ホストにハイパーバイザーソフトウェアをインストールする。
• ホストに IP アドレスを割り当てる。
10
プライマリストレージについて
• ホストが CloudStack 管理サーバーに接続していることを確認する。
2.6. プライマリストレージについて
プライマリストレージはクラスターと関連付けられ、そのクラスター内のホスト上で動作するすべての仮想マシン
のディスクボリュームを格納します。複数のプライマリストレージをクラスターに追加することができ、少なくとも1
つのプライマリストレージが必要です。通常はパフォーマンス向上のため、ホストの近くに配置します。
CloudStack は利用するハイパーバイザーでサポートされている全ての標準規格に沿ったiSCSI、NFSに対応
するよう設計されています。それは次にしめすデバイスを含みます。
• Dell EqualLogic� for iSCSI
• Network Appliances filers for NFS and iSCSI
• Scale Computing for NFS
もし、ローカルディスクのみを使ってインストールを進める場合、次のセカンダリストレージにスキップすることが
できます。
2.7. セカンダリストレージについて
セカンダリストレージはゾーンと関連付けられ、次の項目を格納します。
• テンプレート – 仮想マシンの起動に使用できるオペレーティングシステムイメージで、アプリケーションのイン
ストールなど追加の構成を含めることができます。
• ISO イメージ – データまたはオペレーティングシステムの起動可能なメディアを含むディスクイメージです。
• ディスクボリュームのスナップショット – 仮想マシンデータの保存コピーです。データの復元または新しいテン
プ\nレートの作成に使用できます。
セカンダリストレージ内の項目は、ゾーン内のすべてのホストで使用できます。CloudStack は特定のプライマ
リストレージデバイスに対するゲストVMの仮想ディスクを管理します。
セカンダリストレージ内の項目をクラウドを介して全てのホストで利用可能にするには OpenStack オブジェク
1
トストレージ(Swift, swift.openstack.org ) をセカンダリストレージに追加することができます。Swiftを使う場
合、Swiftストレージを CloudStack 全体で構成します。通常通りセカンダリストレージを各ゾーンで設定する
と、各ゾーンのセカンダリストレージは全てのテンプレートや他のセカンダリストレージのデータをSwiftに中継
します。Swiftストレージはクラウド全体に渡るリソースとして動作し、作成されたテンプレートやその他のデータ
がクラウド上のあらゆるゾーンから利用可能になります。Swiftストレージは階層的な構造ではなく、ストレージ
オブジェクト毎に単一のSwiftコンテナーが用意されます。クラウド上の全てのセカンダリストレージは必要に応
じSwiftからコンテナーを取得します。その際、あるゾーンから他のゾーンに対してテンプレートやスナップショッ
トをコピーする必要はなく、単一のNFSのように扱うことができ、全てのデータはあらゆる場所から利用可能に
なります。
2.8. 物理ネットワークについて
ゾーン追加時に物理ネットワークを設定します。拡張ゾーンにおいて1つもしくは複数の物理ネットワークを各
ゾーン関連付けることができます。これはホストのハイパーバイザーにおけるNICに相当し、各物理ネットワーク
は1つもしくは複数のネットワークのトラフィックタイプを転送します。各ネットワークに対するトラフィックタイプの
選択はゾーン作成時に基本ネットワーク、拡張ネットワークのどちらを選択したかに強く依存します。
1
http://swift.openstack.org
11
第2章クラウドインフラストラクチャのプロビジョニング
物理ネットワークはゾーンにおけるネットワークハードウェアやケーブルの配線に相当し、複数の物理ネットワー
クを持たせることができます。管理者は次のようなことができます。
• ゾーン内の物理ネットワークの追加/削除/更新
• 物理ネットワークのVLAN設定
• ハイパーバイザーからネットワークを認識するための名前の設定
• 物理ネットワーク上で利用可能なサービスプロバイダーの設定(ファイアウォール、ロードバランサー等)
• 物理ネットワークに渡すIPアドレスの設定
• 物理ネットワークで流れるトラフィックタイプの指定
2.8.1. 基本ゾーンのネットワークトラフィックの種類
基本ネットワーク設定を使用する場合は、ゾーンで使用できる物理ネットワークは 1 つだけです。その物理ネット
ワークでは、次の 3 種類のトラフィックが伝送されます。
• ゲスト : エンドユーザーが仮想マシンを実行すると、ゲストトラフィックが生成されます。ゲスト仮想マシンは、
ゲストネットワークと呼ばれるネットワークを介して互いに通信します。基本ゾーンの各ポッドはブロードキャス
トドメインなので、ゲストネットワークに対してそれぞれ異なる IP アドレス範囲を持ちます。管理者は、各ポッド
の IP アドレス範囲を構成する必要があります。
• Management. When CloudStack's internal resources communicate with each other, they
generate management traffic. This includes communication between hosts, system VMs (VMs
used by CloudStack to perform various tasks in the cloud), and any other component that
communicates directly with the CloudStack Management Server. You must configure the IP range
for the system VMs to use.
注記
�管理トラフィックとゲストトラフィックに別々の NIC を使用することを強くお勧めします。
• パブリック : パブリックトラフィックはクラウド上の仮想マシンがインターネットにアクセスする際に生成されま
す。これには外部からアクセス可能な IP が割り当てられなければいけません。「新規 IP アドレスの取得」に
記述されているようにエンドユーザーはこれらの IP を CloudStack ユーザーインターフェースから取得しゲ
ストネットワークとパブリックネットワーク間の NAT を実現できます。
• Storage. While labeled "storage" this is specifically about secondary storage, and doesn't affect
traffic for primary storage. This includes traffic such as VM templates and snapshots, which
is sent between the secondary storage VM and secondary storage servers. CloudStack uses a
separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use
of a storage NIC that always operates on a high bandwidth network allows fast template and
snapshot copying. You must configure the IP range to use for the storage network.
基本ネットワークの場合は、物理ネットワークの構成はごく簡単です。多くの場合、’構成する必要があるのはゲ
スト仮想マシンが生成するトラフィックを伝送するための 1 つのゲストネットワークだけです。もしNetScaler
ロードバランサーを用い、エラスティック IP やエラスティックロードバランサー(EIP, ELB) 機能を利用する場
合はパブリックトラフィックを転送するためのネットワークを設定しなければなりません。CloudStack ではユー
ザーインターフェースから新しいゾーンを追加する際に必要なネットワーク設定に注意を払う必要があります。
12
基本ゾーンのゲスト IP アドレス
2.8.2. 基本ゾーンのゲスト IP アドレス
基本ネットワーク設定を使用する場合は、CloudStack はポッドの CIDR の IP アドレスをそのポッドのゲストに
割り当てます。管理者は、そのためにポッドの直接 IP アドレスの範囲を追加する必要があります。これらの IP ア
ドレスはホストと同じ VLAN に含まれます。
2.8.3. 拡張ゾーンのネットワークトラフィックの種類
拡張ネットワーク設定を使用する場合は、ゾーンで複数の物理ネットワークを使用できます。各物理ネットワーク
で 1 つまたは複数の種類のトラフィックを伝送できます。各ネットワークで伝送するネットワークトラフィックの種
類を、CloudStack に識別させる必要があります。拡張ゾーンのトラフィックには次の種類があります。
• ゲスト : エンドユーザーが仮想マシンを実行すると、ゲストトラフィックが生成されます。ゲスト仮想マシンは、
ゲストネットワークと呼ばれるネットワークを介して互いに通信します。このネットワークは、分離することも共
有することもできます。分離されたゲストネットワークの場合は、管理者は各 CloudStack アカウントのネット
ワークを分離するための VLAN 範囲を予約する必要があります(多数の VLAN が必要になる可能性があり
ます)。共有されたゲストネットワークでは、すべてのゲスト仮想マシンが 1 つのネットワークを共有します。こ
の場合は、セキュリティグループなどのレイヤー3 のネットワーク分離技術を使用して分離を提供できます。
• 管理 : CloudStack の内部リソースが互いに通信すると、管理トラフィックが生成されます。これには、ホスト、
システム仮想マシン(クラウド内のさまざまなタスクを実行するために CloudStack によって使用される仮想
マシン)、および CloudStack 管理サーバーと直接通信するほかのコンポーネントの間の通信が含まれます。
使用するシステム仮想マシンの IP 範囲を構成する必要があります。
• パブリック : パブリックトラフィックは、クラウド内の仮想マシンがインターネットにアクセスすると生成されます。
このために、パブリックにアクセスできる IP アドレスを割り当てる必要があります。エンドユーザーは、「新規
IP アドレスの取得」にあるように CloudStack ユーザーインターフェイスを使用してそれらの IP アドレスを取
得して、ゲストネットワークとパブリックネットワークの間に NAT を実装できます。
• Storage. While labeled "storage" this is specifically about secondary storage, and doesn't affect
traffic for primary storage. This includes traffic such as VM templates and snapshots, which
is sent between the secondary storage VM and secondary storage servers. CloudStack uses a
separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use
of a storage NIC that always operates on a high bandwidth network allows fast template and
snapshot copying. You must configure the IP range to use for the storage network.
これらのトラフィックは、それぞれ異なる物理ネットワークで伝送することも、一定の制限の下に同じ物理ネット
ワークで伝送することもできます。ユーザーインターフェイスでゾーンの追加ウィザードを使用して新しいゾーン
を作成すると、有効な選択肢のみが提示されます。
2.8.4. 拡張ゾーンのゲスト IP アドレス
拡張ネットワーク設定を使用する場合は、ゲストが使用するための追加のネットワークを作成できます。それら
のネットワークは、ゾーン全体を対象にしてすべてのアカウントが使用できるようにすることも、単一のアカウント
を対象にすることもできます。後者の場合、それらのネットワークに接続するゲストを作成できるのはそのアカウ
ントだけになります。ネットワークは、VLAN ID、IP アドレス範囲、およびゲートウェイによって定義されます。管理
者は、こうしたネットワークを必要に応じて何千もプロビジョニングできます。
2.8.5. 拡張ゾーンのパブリック IP アドレス
拡張ネットワーク設定を使用する場合は、ゲストが使用するための追加のネットワークを作成できます。それら
のネットワークは、ゾーン全体を対象にしてすべてのアカウントが使用できるようにすることも、単一のアカウント
を対象にすることもできます。後者の場合、それらのネットワークに接続するゲストを作成できるのはそのアカウ
13
第2章クラウドインフラストラクチャのプロビジョニング
ントだけになります。ネットワークは、VLAN ID、IP アドレス範囲、およびゲートウェイによって定義されます。管理
者は、こうしたネットワークを必要に応じて何千もプロビジョニングできます。
2.8.6. システムにより予約済みの IP アドレス
各ゾーンで、管理ネットワーク用に予約済みの IP アドレスの範囲を構成する必要があります。このネットワーク
は、CloudStack 管理サーバーとさまざまなシステム仮想マシン(セカンダリストレージ仮想マシン、コンソール
プロキシ仮想マシン、DHCP など)の間の通信に使用されます。
予約済みの IP アドレスは、クラウド全体で一意である必要があります。たとえば、2 つのゾーンのホストに同じプ
ライベート IP アドレスを使用することはできません。
ポッド内のホストにはプライベート IP アドレスが割り当てられます。これは通常、RFC1918 アドレスです。コン
ソールプロキシとセカンダリストレージのシステム仮想マシンにも、それらが作成されたポッドの CIDR のプライ
ベート IP アドレスが割り当てられます。
コンピューティングサーバーと管理サーバーはシステム予約 IP 範囲外の IP アドレスを利用します。例として、シ
ステム予約 IP 範囲が 192.168.154.2 から始まり 192.168.154.7 で終わる場合、CloudStack は .2 から .7
をシステム仮想マシンに利用できます。これはポッドの CIDR とは別になり .8 から .254 を管理サーバーやハ
イパーバイザーホストに利用できます。
全てのゾーンで :
各ポッドのシステムにプライベート IP アドレスを割り当てて、CloudStack で準備します。
KVM と XenServer で推奨されるポッドあたりのプライベート IP アドレスの数は、ホストごとに 1 つです。ポッド
の拡張が予想される場合は、拡張に対応できるだけの数のプライベート IP アドレスをあらかじめ追加しておき
ます。
拡張ネットワーク設定を使用するゾーンで :
For zones with advanced networking, we recommend provisioning enough private IPs for your
total number of customers, plus enough for the required CloudStack System VMs. Typically, about
10 additional IPs are required for the System VMs. For more information about System VMs, see
Working with System Virtual Machines in the Administrator's Guide.
拡張ネットワーク設定を使用する場合は、各ポッドで使用できるプライベート IP アドレスの数は、そのポッドの
ノードで実行するハイパーバイザーによって異なります。Citrix XenServer と KVM ではリンクローカルアドレ
スが使用されるため、理論上は、アドレスブロック内で 65,000 を超える数のプライベート IP アドレスを使用で
きます。次第にポッドが拡張されても、ホストやゲスト仮想ルーターの IP アドレスが足りなくなることはまずあり
ません。一方、VMWare ESXi では、管理者が指定するサブネット方式が使用されるため、一般的なポッドあた
りの IP アドレスの数は 255 個のみです。これらのアドレスは、物理マシン、ゲスト仮想ルーター、およびそのほ
かのエンティティに割り当てられるため、ノードで ESXi が実行されているポッドを拡張するときには、プライベー
ト IP アドレスが足りなくなる可能性があります。
拡張ネットワーク設定を使用する ESXi ポッドでプライベート IP 領域を拡張するための適切な余裕を確保する
には、次のどちらか、または両方の方法を使用します。
• サブネットに対してより大きい CIDR ブロックを指定する。サフィックスが/20 のサブネットマスクでは、4,000
個を超える IP アドレスを提供できます。
• 複数のポッドを、それぞれ独自のサブネットを指定して作成する。たとえば、10 個のポッドを作成し、各ポッド
に 255 個の IP を持たせる場合、2,550 個の IP アドレスを提供できます。
14
インストール
3.1. 対象の読者
クラウドの設計フェーズや、精巧な展開計画を経験した人、あるいはトライアルの規模を拡大する準備ができて
いる人。以下の手順では、VLANを使った拡張ネットワーク、高可用性、ロードバランサーやファイアウォールなど
の外部機器との連携、Citrix XenServer、KVM、VMware vSphereなどマルチハイパーバイザーのサポートな
ど、CloudStackのさらに高度な機能を利用できます。
3.2. インストール手順の概要
簡単な試用インストール以上のことを行うには、構成のさまざまな選択肢についてガイダンスが必要になりま
す。次の項目を参照することを強くお勧めします。
• 展開アーキテクチャの選択
• ハイパーバイザーの選択 : サポートされる機能
• ネットワークのセットアップ
• ストレージのセットアップ
• ベストプラクティス
1. 必要なハードウェアの準備ができたかどうかの確認。�� を参照してください。
2. 管理サーバーのインストール(単一ノードか複数ノードかを選択します)。�� を参照してください。
3. ユーザーインターフェイスへのログイン。4�� を参照してください。
4. ゾーンの追加。最初のポッド、クラスター、およびホストの設定。�� を参照してください。
5. ポッドの追加(オプション)。�� を参照してください。
6. クラスターの追加(オプション)。�� を参照してください。
7. ホストの追加(オプション)。�� を参照してください。
8. プライマリストレージの追加(オプション)。�� を参照してください。
9. セカンダリストレージの追加(オプション)。�� を参照してください。
10. クラウドの使用。�� を参照してください。
3.3. 最小システム要件
3.3.1. 管理サーバー, データベースとストレージシステムの要件
管理サーバーとMySQLデータベースを動作させるため以下の要件を満たすサーバー。同一サーバー上でロー
カルディスクやNFSを利用してプライマリストレージ、セカンダリストレージを提供することも可能です。管理サー
バーは仮想マシン上で動作させることもできます。
• オペレーティングシステム:
15
第3章インストール
• 推奨: CentOS/RHEL 6.3以上、もしくは Ubuntu 12.04(.1)
• 64-bit x86 CPU(多くのコアを用意することでパフォーマンスの向上が見込まれます)
• 4GBのメモリ
• 250GB以上のストレージ(多くの実績から500GB以上を推奨)。
• 最少1つ以上のNIC
• 静的に割り当てられたIPアドレス
• hostnameコマンドで完全修飾ホスト名が返される
3.3.2. ホスト/ハイパーバイザーの要件
ゲストVMを構成するクラウドサービスを動作させるホスト。各ホストは一つの物理筐体であり、次の要件を満た
す必要があります。
• ハードウェア仮想マシン(Intel-VTまたはAMD-Vが有効であること)をサポートする必要があります。
• 64-bit x86 CPU(多くのコアを用意することでパフォーマンスの向上が見込まれます)
• 完全仮想化のサポートが必要。
• 4GBのメモリ
• 36 GBのローカルディスク
• 最少1つ以上のNIC
•
注記
もし、ホストに対し DHCP を利用する場合、DHCP サーバーがこれらホストに配布する IP
とCloudStack によって作成された仮想ルーターの DHCP が競合しないことを確認してく
ださい。
• 最新のホットフィックスが適用されたハイパーバイザー。
• CloudStack が展開された際、ハイパーバイザーホストに既に動作しているVMが存在していない。
• クラスター内にあるホストは全て同スペックでなければいけません。CPU の種類や数、機能フラグが同じでな
ければいけません。
ホストはハイパーバイザーに依存した追加要件を満たす必要があります。インストールの章の上部にある要件
リストからあなたの選択したハイパーバイザーを確認してください。
警告
加えてハイパーバイザーの要件とガイドに記述されているインストール手順を満たす必要が
あります。ハイパーバイザーホストは CloudStack と連携する出来るよう適切に準備しなけれ
ばなります。例として XenServerの要件を以下のCitrix XenServer インストールに記述しま
す。
16
リポジトリの設定
• �KVM ��
• �XenServer��
• �vSphere ��
3.4. リポジトリの設定
CloudStack は、公式ミラーサイトからソースの形でのみ提供されます。しかしながら、CloudStackのコミュニ
ティメンバーがバイナリを提供してくれると思うので、ユーザはソースからビルドする事なくApache
CloudStackをインストールできるでしょう。
If you didn't follow the steps to build your own packages from source in the sections for �Building
RPMs from Source� or �DEB�� you may find pre-built DEB and RPM packages for your
1
convenience linked from the downloads page.
注記
これらのリポジトリには管理サーバとKVMハイパーバイザーのパッケージが含まれます。
3.4.1. DEBパッケージのリポジトリ
次のコマンドで、apt sources にDEBパッケージのリポジトリ情報を追加できます。現時点では、Ubuntu 12.04
LTS (precise) 用のパッケージのみ用意されています。
好きなエディタで /etc/apt/sources.list.d/cloudstack.list を開いて(または作成して)下さい。コミュニ
ティが提供するレポジトリ情報をファイルに追加します。
deb http://cloudstack.apt-get.eu/ubuntu precise 4.0
公開鍵をtrustedキーに追加します。
$ wget -O - http://cloudstack.apt-get.eu/release.asc|apt-key add -
ローカルのaptキャッシュを更新します。
$ apt-get update
DEBパッケージリポジトリが設定され、使用できるようになりました。
3.4.2. RPM package repository
There is a RPM package repository for CloudStack so you can easily install on RHEL based platforms.
If you're using an RPM-based system, you'll want to add the Yum repository so that you can install
CloudStack with Yum.
Yum repository information is found under /etc/yum.repos.d. You'll see several .repo files in this
directory, each one denoting a specific repository.
1
http://cloudstack.apache.org/downloads.html
17
第3章インストール
To add the CloudStack repository, create /etc/yum.repos.d/cloudstack.repo and insert the
following information.
[cloudstack]
name=cloudstack
baseurl=http://cloudstack.apt-get.eu/rhel/4.0/
enabled=1
gpgcheck=0
Now you should be able to install CloudStack using Yum.
3.5. 管理サーバーのインストール
3.5.1. 管理サーバーのインストール
ここでは管理サーバーのインストール手順について説明します。インストールには2種類の手順があり、あなた
のクラウド環境にいくつの管理サーバーを用意するかによって異なります。
• 単一ホストでの管理サーバーと MySQL。
• 物理的に分けられた複数ホストへの管理サーバーと MySQL。
どちらの場合でもこれらのマシンは「システム要件」に記載されているシステム要件を満たしている必要があり
ます。
警告
セキュリティのため、パブリックインターネットから管理サーバー上のポート 8096 または
8250 にアクセスできないようにする必要があります。
管理サーバーインストールの手順:
1. オペレーティングシステムの準備
2. (XenServer のみ) vhd-util をダウンロードしてインストールしてください。
3. 最初の管理サーバーのインストール
4. MySQLのインストールと設定
5. NFS共有の準備
6. 追加の管理サーバーの準備と起動(オプション)
7. システム仮想マシンテンプレートの準備
3.5.2. オペレーティングシステムの準備
管理サーバーをホストするために、次の手順に従ってオペレーティングシステムを準備する必要があります。こ
れらの手順は各管理サーバーノードで実行する必要があります。
1. オペレーティングシステムにルートユーザーとしてログオンします。
18
初期ホストへの管理サーバーのインストール
2. 完全修飾ホスト名を確認します。
hostname --fqdn
This should return a fully qualified hostname such as "management1.lab.example.org". If it does
not, edit /etc/hosts so that it does.
3. 管理サーバーからインターネットに接続できることを確認します。
ping www.cloudstack.org
4. 時刻を同期するために NTP を有効にします。
注記
クラウドのサーバーのクロックを同期するために NTP が必要です。
a. NTPのインストール
yum install ntp
apt-get install openntpd
5. これらの手順を管理サーバーがインストールされた全てのホストで実行します。
3.5.3. 初期ホストへの管理サーバーのインストール
最初のインストールでは管理サーバーのインストールを単一か複数ホストに対して行うかに関わらず単一ホス
トに対してのソフトウェアインストールを行います。
注記
もし高可用性のため管理サーバーを複数ノードにインストール場合ホストの追加は実施せず
この後のステップを完了してから行なってください。
CloudStack 管理サーバーは RPM か DEB パッケージを利用してインストールできます。これらのパッケージは
管理サーバーを動かすために必要な全てを含んでいます。
3.5.3.1. CentOS/RHEL でのインストール
まず、必要なパッケージをインストールします。
yum install cloud-client
3.5.3.2. Ubuntu でのインストール
apt-get install cloud-client
19
第3章インストール
3.5.3.3. vhd-util をダウンロードします。
次の手順はハイパーバイザーホストとして XenServer をインストールした場合のみ必要となります。
2
管理サーバーをセットアップする前に、vhd-util から vhd-util をダウンロードしてください。
管理サーバーに RHEL もしくは CentOS を利用している場合は vhd-util を /usr/lib64/cloud/common/
scripts/vm/hypervisor/xenserver にコピーしてください。
管理サーバーに Ubuntu を利用している場合は vhd-util を /usr/lib/cloud/common/scripts/vm/
hypervisor/xenserver にコピーしてください。
3.5.4. Install the database server
The CloudStack management server uses a MySQL database server to store its data. When you are
installing the management server on a single node, you can install the MySQL server locally. For
an installation that has multiple management server nodes, we assume the MySQL database also
runs on a separate node.
CloudStack has been tested with MySQL 5.1 and 5.5. These versions are included in RHEL/CentOS
and Ubuntu.
3.5.4.1. 管理サーバーノード上でのデータベースインストール
この章では管理サーバーと同一のノードにどのように MySQL をインストールするかを説明しています。これは
単一の管理サーバーノードの展開を想定しています。もし、複数ノードへの管理サーバーの展開を実施している
場合、一般的には MySQL 用に別ノードを用意します。詳細は �Install the Database on a Separate Node� を
参照して下さい。
1. Install MySQL from the package repository of your distribution:
yum install mysql-server
apt-get install mysql-server
2. Open the MySQL configuration file. The configuration file is /etc/my.cnf or /etc/mysql/my.cnf,
depending on your OS.
3. Insert the following lines in the [mysqld] section.
You can put these lines below the datadir line. The max_connections parameter should be
set to 350 multiplied by the number of Management Servers you are deploying. This example
assumes one Management Server.
注記
On Ubuntu, you can also create a file /etc/mysql/conf.d/cloudstack.cnf and
add these directives there. Don't forget to add [mysqld] on the first line of the
file.
innodb_rollback_on_timeout=1
2
http://download.cloud.com.s3.amazonaws.com/tools/vhd-util
20
Install the database server
innodb_lock_wait_timeout=600
max_connections=350
log-bin=mysql-bin
binlog-format = 'ROW'
4. 新しい構成情報を反映させるため MySQL を起動、もしくは再起動します。
On RHEL/CentOS, MySQL doesn't automatically start after installation. Start it manually.
service mysqld start
Unbuntu の場合 MySQL を再起動します。
service mysqld restart
5. (CentOS と RHEL のみ。Ubuntu では必要ありません。)
警告
RHEL と CentOS の場合、デフォルトで MySQL にルートパスワードが設定されません。
セキュリティ上の予防のためルートパスワードを設定することを強く推奨します。
Run the following command to secure your installation. You can answer "Y" to all questions.
mysql_secure_installation
6. CloudStack can be blocked by security mechanisms, such as SELinux. Disable SELinux to
ensure + that the Agent has all the required permissions.
Configure SELinux (RHEL and CentOS):
a. Check whether SELinux is installed on your machine. If not, you can skip this section.
In RHEL or CentOS, SELinux is installed and enabled by default. You can verify this with:
$ rpm -qa | grep selinux
b. Set the SELINUX variable in /etc/selinux/config to "permissive". This ensures that the
permissive setting will be maintained after a system reboot.
RHELもしくはCentOSの場合:
vi /etc/selinux/config
Change the following line
SELINUX=enforcing
to this:
SELINUX=permissive
21
第3章インストール
c. Set SELinux to permissive starting immediately, without requiring a system reboot.
$ setenforce permissive
7. Set up the database. The following command creates the "cloud" user on the database.
• In dbpassword, specify the password to be assigned to the "cloud" user. You can choose to
provide no password although that is not recommended.
• In deploy-as, specify the username and password of the user deploying the database. In the
following command, it is assumed the root user is deploying the database and creating the
"cloud" user.
• (オプション) encryption_type にはデータベースのパスワードの暗号化方式として file か web を指定
できます。詳細は �About Password and Key Encryption� を参照してください。
• (オプション) management_server_key には CloudStack プロパティファイル上で機密パラメーターを
暗号化する際のデフォルト鍵を変更できます。デフォルトでは "password" になりますが、より安全な値に
変更することを強く推奨します。詳細は�About Password and Key Encryption�を参照してください。
• (オプション) database_key には CloudStack データベース上で機密パラメーターを暗号化する際のデ
フォルト鍵を変更できます。デフォルトでは "password" になりますが、より安全な値に変更することを強
く推奨します。詳細は�About Password and Key Encryption� を参照してください。
• (Optional) For management_server_ip, you may explicitly specify cluster management server
node IP. If not specified, the local IP address will be used.
cloudstack-setup-databases cloud:<dbpassword>@localhost \
--deploy-as=root:<password> \
-e <encryption_type> \
-m <management_server_key> \
-k <database_key> \
-i <management_server_ip>
このスクリプトが完了すると「Successfully initialized the database.」のようなメッセージが表示されま
す。
8. 管理サーバーと同一のマシンで KVM ハイパーバイザーを動作させている場合は /etc/sudoers を変更し
以下の行を追加してください。
Defaults:cloud !requiretty
9. これでデータベースがセットアップされました。管理サーバーのオペレーティングシステムの構成は完了で
す。このコマンドにより iptables と sudoers がセットアップされ、管理サーバーが起動します。
# cloudstack-setup-management
"CloudStack 管理サーバーのセットアップが完了しました。" といったメッセージを確認できます。
22
Install the database server
3.5.4.2. Install the Database on a Separate Node
This section describes how to install MySQL on a standalone machine, separate from the
Management Server. This technique is intended for a deployment that includes several
Management Server nodes. If you have a single-node Management Server deployment, you will
typically use the same node for MySQL. See ��.
注記
The management server doesn't require a specific distribution for the MySQL node.
You can use a distribution or Operating System of your choice. Using the same
distribution as the management server is recommended, but not required. See ��
��, ��.
1. ディストリビューションのパッケージリポジトリから MySQL をインストールします。
yum install mysql-server
apt-get install mysql-server
2. Edit the MySQL configuration (/etc/my.cnf or /etc/mysql/my.cnf, depending on your OS) and
insert the following lines in the [mysqld] section. You can put these lines below the datadir
line. The max_connections parameter should be set to 350 multiplied by the number of
Management Servers you are deploying. This example assumes two Management Servers.
注記
On Ubuntu, you can also create /etc/mysql/conf.d/cloudstack.cnf file and add
these directives there. Don't forget to add [mysqld] on the first line of the file.
innodb_rollback_on_timeout=1
innodb_lock_wait_timeout=600
max_connections=700
log-bin=mysql-bin
binlog-format = 'ROW'
bind-address = 0.0.0.0
3. 新しい構成情報を反映させるため MySQL を起動、もしくは再起動します。
On RHEL/CentOS, MySQL doesn't automatically start after installation. Start it manually.
service mysqld start
Unbuntu の場合 MySQL を再起動します。
service mysqld restart
4. (CentOS と RHEL のみ。Ubuntu では必要ありません。)
23
第3章インストール
警告
RHEL と CentOS の場合、デフォルトで MySQL にルートパスワードが設定されません。
セキュリティ上の予防のためルートパスワードを設定することを強く推奨します。
Run the following command to secure your installation. You can answer "Y" to all questions
except "Disallow root login remotely?". Remote root login is required to set up the databases.
mysql_secure_installation
5. If a firewall is present on the system, open TCP port 3306 so external MySQL connections can
be established.
On Ubuntu, UFW is the default firewall. Open the port with this command:
ufw allow mysql
On RHEL/CentOS:
a. Edit the /etc/sysconfig/iptables file and add the following line at the beginning of the
INPUT chain.
-A INPUT -p tcp --dport 3306 -j ACCEPT
b. Now reload the iptables rules.
service iptables restart
6. Return to the root shell on your first Management Server.
7. Set up the database. The following command creates the cloud user on the database.
• In dbpassword, specify the password to be assigned to the cloud user. You can choose to
provide no password.
• In deploy-as, specify the username and password of the user deploying the database. In the
following command, it is assumed the root user is deploying the database and creating the
cloud user.
• (オプション) encryption_type にはデータベースのパスワードの暗号化方式として file か web を指定
できます。詳細は �About Password and Key Encryption� を参照してください。
• (Optional) For management_server_key, substitute the default key that is used to encrypt
confidential parameters in the CloudStack properties file. Default: password. It is highly
recommended that you replace this with a more secure value. See About Password and Key
Encryption.
• (オプション) database_key には CloudStack データベース上で機密パラメーターを暗号化する際のデ
フォルト鍵を変更できます。デフォルトでは "password" になりますが、より安全な値に変更することを強
く推奨します。詳細は�About Password and Key Encryption� を参照してください。
24
About Password and Key Encryption
• (Optional) For management_server_ip, you may explicitly specify cluster management server
node IP. If not specified, the local IP address will be used.
cloudstack-setup-databases cloud:<dbpassword>@<ip address mysql server> \
--deploy-as=root:<password> \
-e <encryption_type> \
-m <management_server_key> \
-k <database_key> \
-i <management_server_ip>
このスクリプトが完了すると「Successfully initialized the database.」のようなメッセージが表示されま
す。
3.5.5. About Password and Key Encryption
CloudStack stores several sensitive passwords and secret keys that are used to provide security.
These values are always automatically encrypted:
• Database secret key
• Database password
• SSH keys
• Compute node root password
• VPN password
• User API secret key
• VNC password
CloudStack uses the Java Simplified Encryption (JASYPT) library. The data values are encrypted and
decrypted using a database secret key, which is stored in one of CloudStack’s internal properties
files along with the database password. The other encrypted values listed above, such as SSH keys,
are in the CloudStack internal database.
Of course, the database secret key itself can not be stored in the open – it must be encrypted.
How then does CloudStack read it? A second secret key must be provided from an external source
during Management Server startup. This key can be provided in one of two ways: loaded from a file
or provided by the CloudStack administrator. The CloudStack database has a new configuration
setting that lets it know which of these methods will be used. If the encryption type is set to
"file," the key must be in a file in a known location. If the encryption type is set to "web," the
administrator runs the utility com.cloud.utils.crypt.EncryptionSecretKeySender, which relays the
key to the Management Server over a known port.
The encryption type, database secret key, and Management Server secret key are set during
CloudStack installation. They are all parameters to the CloudStack database setup script
(cloudstack-setup-databases). The default values are file, password, and password. It is, of course,
highly recommended that you change these to more secure keys.
25
第3章インストール
3.5.6. NFS共有の準備
CloudStack には、プライマリストレージとセカンダリストレージを保持するための場所が必要です(「クラウドイ
ンフラストラクチャの概要」を参照)。双方には NFS 共有を用いることができ、これらのストレージは両方とも
NFS 共有にできます。ここでは、ストレージを CloudStack に追加する前に NFS 共有をセットアップする方法に
ついて説明します。
代替ストレージ
NFS だけがプライマリストレージ、セカンダリストレージのオプションではありません。たとえ
ば、Ceph RBD や GlusterFS、iSCSI なども利用できます。どのストレージシステムを利用す
るかはどのハイパーバイザーを選択したかやプライマリストレージ、セカンダリストレージのど
ちらに言及しているかに依存します。
プライマリストレージとセカンダリストレージの要件は以下の通り:
• ��
• ��
商用環境でのインストールでは一般的にNFSサーバーを別に用意します。参照 �Using a Separate NFS
Server�
また、管理サーバーと同じノードにセットアップすることもできます。これはより一般的なトライアルインストールと
なりますが大規模環境の展開も技術的には可能です。参照 �Using the Management Server as the NFS
Server�
3.5.6.1. Using a Separate NFS Server
This section tells how to set up NFS shares for secondary and (optionally) primary storage on an
NFS server running on a separate node from the Management Server.
The exact commands for the following steps may vary depending on your operating system version.
警告
(KVM only) Ensure that no volume is already mounted at your NFS mount point.
1. On the storage server, create an NFS share for secondary storage and, if you are using NFS for
primary storage as well, create a second NFS share. For example:
# mkdir -p /export/primary
# mkdir -p /export/secondary
2. To configure the new directories as NFS exports, edit /etc/exports. Export the NFS share(s)
with rw,async,no_root_squash. For example:
# vi /etc/exports
Insert the following line.
26
NFS共有の準備
/export
*(rw,async,no_root_squash)
3. Export the /export directory.
# exportfs -a
4. On the management server, create a mount point for secondary storage. For example:
# mkdir -p /mnt/secondary
5. Mount the secondary storage on your Management Server. Replace the example NFS server
name and NFS share paths below with your own.
# mount -t nfs nfsservername:/nfs/share/secondary /mnt/secondary
3.5.6.2. Using the Management Server as the NFS Server
This section tells how to set up NFS shares for primary and secondary storage on the same node
with the Management Server. This is more typical of a trial installation, but is technically possible
in a larger deployment. It is assumed that you will have less than 16TB of storage on the host.
The exact commands for the following steps may vary depending on your operating system version.
1. On RHEL/CentOS systems, you'll need to install the nfs-utils package:
$ sudo yum install nfs-utils
2. On the Management Server host, create two directories that you will use for primary and
secondary storage. For example:
# mkdir -p /export/primary
# mkdir -p /export/secondary
3. To configure the new directories as NFS exports, edit /etc/exports. Export the NFS share(s)
with rw,async,no_root_squash. For example:
# vi /etc/exports
Insert the following line.
/export
*(rw,async,no_root_squash)
4. Export the /export directory.
# exportfs -a
5. Edit the /etc/sysconfig/nfs file.
27
第3章インストール
# vi /etc/sysconfig/nfs
Uncomment the following lines:
LOCKD_TCPPORT=32803
LOCKD_UDPPORT=32769
MOUNTD_PORT=892
RQUOTAD_PORT=875
STATD_PORT=662
STATD_OUTGOING_PORT=2020
6. Edit the /etc/sysconfig/iptables file.
# vi /etc/sysconfig/iptables
Add the following lines at the beginning of the INPUT chain where <NETWORK> is the network
that you'll be using:
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
-A
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
INPUT
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
-s
<NETWORK>
<NETWORK>
<NETWORK>
<NETWORK>
<NETWORK>
<NETWORK>
<NETWORK>
<NETWORK>
<NETWORK>
<NETWORK>
<NETWORK>
-m
-m
-m
-m
-m
-m
-m
-m
-m
-m
-m
state
state
state
state
state
state
state
state
state
state
state
--state
--state
--state
--state
--state
--state
--state
--state
--state
--state
--state
NEW
NEW
NEW
NEW
NEW
NEW
NEW
NEW
NEW
NEW
NEW
-p
-p
-p
-p
-p
-p
-p
-p
-p
-p
-p
udp
tcp
tcp
tcp
udp
tcp
udp
tcp
udp
tcp
udp
--dport
--dport
--dport
--dport
--dport
--dport
--dport
--dport
--dport
--dport
--dport
111 -j ACCEPT
111 -j ACCEPT
2049 -j ACCEPT
32803 -j ACCEPT
32769 -j ACCEPT
892 -j ACCEPT
892 -j ACCEPT
875 -j ACCEPT
875 -j ACCEPT
662 -j ACCEPT
662 -j ACCEPT
7. Run the following commands:
# service iptables restart
# service iptables save
8. If NFS v4 communication is used between client and server, add your domain to /etc/
idmapd.conf on both the hypervisor host and Management Server.
# vi /etc/idmapd.conf
Remove the character # from the beginning of the Domain line in idmapd.conf and replace the
value in the file with your own domain. In the example below, the domain is company.com.
Domain = company.com
9. Reboot the Management Server host.
Two NFS shares called /export/primary and /export/secondary are now set up.
10. It is recommended that you test to be sure the previous steps have been successful.
28
追加の管理サーバーの準備と起動
a. Log in to the hypervisor host.
b. Be sure NFS and rpcbind are running. The commands might be different depending on
your OS. For example:
#
#
#
#
#
service rpcbind start
service nfs start
chkconfig nfs on
chkconfig rpcbind on
reboot
c. Log back in to the hypervisor host and try to mount the /export directories. For example
(substitute your own management server name):
#
#
#
#
#
#
mkdir /primarymount
mount -t nfs <management-server-name>:/export/primary /primarymount
umount /primarymount
mkdir /secondarymount
mount -t nfs <management-server-name>:/export/secondary /secondarymount
umount /secondarymount
3.5.7. 追加の管理サーバーの準備と起動
2 台目以降の管理サーバーについて、管理サーバーのソフトウェアをインストールしてデータベースに接続し、
管理サーバーのオペレーティングシステムをセットアップします。
1. �� と �Building RPMs from Source� もしくは �DEB�� の手順を必要に応じて実施し
ます。
2. ハイパーバイザーホストとして XenServer をインストールしている場合は次の手順が必要となります。
3
vhd-util から vhd-utl をダウンロードします。
管理サーバーに RHEL や CentOS を利用している場合は vhd-utl を /usr/lib64/cloud/common/
scripts/vm/hypervisor/xenserver にコピーしてください。
管理サーバーに Ubuntu を利用している場合は vhd-util を /usr/lib/cloud/common/scripts/vm/
hypervisor/xenserver/vhd-util にコピーしてください。
3. 必要なサービスが起動中であり起動時に開始するよう設定されていることを確認します。
#
#
#
#
service rpcbind start
service nfs start
chkconfig nfs on
chkconfig rpcbind on
4. データベースクライアントを構成します。このケースでは --deploy-as オプションが付与されていないことに
注意してください。(このコマンドの引数に関する詳細は �Install the Database on a Separate Node� を参
照してください)。
# cloudstack-setup-databases cloud:dbpassword@dbhost -e encryption_type -m management_server_key k database_key -i management_server_ip
29
第3章インストール
5. オペレーティングシステムを構成し、管理サーバーを起動します。
# cloudstack-setup-management
このノード上の管理サーバーが起動します。
6. これらの手順をそれぞれの追加する管理サーバー上で実行します。
7. 管理サーバー用の負荷分散装置を構成します。�Management Server Load Balancing� を参照してくださ
い。
3.5.8. システム仮想マシンテンプレートの準備
CloudStack システム仮想マシンに使用するテンプレートをセカンダリストレージに配置する必要があります。
注記
コマンドをコピーして実行するときは、単一の行として貼り付けたことを確認してください。一
部のドキュメントビューアーでは、コピーしたテキストに不要な改行が含まれる可能性があり
ます。
1. 管理サーバーで次の cloud-install-sys-tmplt コマンドを実行して、システム仮想マシンテンプレート
を取得して展開します。このゾーンでエンドユーザーが実行することが予想される各ハイパーバイザーの種
類に対応するコマンドを実行します。
セカンダリストレージのマウントポイントが/mnt/secondary
置き換えます。
でない場合は、実際のマウントポイント名に
If you set the CloudStack database encryption type to "web" when you set up the database,
you must now add the parameter -s <management-server-secret-key>. See �About Password
and Key Encryption�.
この処理を実行するにはローカルファイルシステムに約 5 GB の空き領域が必要で、実行するたびに最長
で 30 分かかります。
• XenServer:
# /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u
http://download.cloud.com/templates/acton/acton-systemvm-02062012.vhd.bz2 -h xenserver -s <optionalmanagement-server-secret-key> -F
• vSphere:
# /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary u http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova -h vmware -s <optionalmanagement-server-secret-key> -F
• KVM:
# /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary
-u http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2 -h kvm -s <optionalmanagement-server-secret-key> -F
30
インストールが完了したら次の手順に進みます。
Ubuntu の場合は代わりに以下のパスを利用してください。
# /usr/lib/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt
2. もし別途 NFS サーバーを利用している場合は以下の手順を実施してください。もし管理サーバー上で
NFS サーバーを利用する場合は以下の手順は不要です。
スクリプトの完了後セカンダリストレージをアンマウントし作成したディレクトリを削除します。
# umount /mnt/secondary
# rmdir /mnt/secondary
3. これらの手順を各セカンダリストレージサーバーに対して行います。
3.5.9. インストールが完了したら次の手順に進みます。
これで、CloudStack
た。
管理サーバーとシステムデータの保持に使用するデータベースがインストールされまし
次の作業
• Even without adding any cloud infrastructure, you can run the UI to get a feel for what's offered
and how you will interact with CloudStack on an ongoing basis. See Log In to the UI.
• When you're ready, add the cloud infrastructure and try running some virtual machines on
it, so you can watch how CloudStack manages the infrastructure. See Provision Your Cloud
Infrastructure.
3.6. Building RPMs from Source
As mentioned previously in �Apache CloudStack ��, you will need to install several
prerequisites before you can build packages for CloudStack. Here we'll assume you're working with
a 64-bit build of CentOS or Red Hat Enterprise Linux.
# yum groupinstall "Development Tools"
31
第3章インストール
# yum install java-1.6.0-openjdk-devel.x86_64 genisoimage mysql mysql-server ws-commons-util MySQL-python tomcat6
createrepo
Next, you'll need to install build-time dependencies for CloudStack with Maven. We're using Maven
4
3, so you'll want to grab a Maven 3 tarball and uncompress it in your home directory (or whatever
location you prefer):
$ tar zxvf apache-maven-3.0.4-bin.tar.gz
$ export PATH=/usr/local/apache-maven-3.0.4//bin:$PATH
Maven also needs to know where Java is, and expects the JAVA_HOME environment variable to
be set:
$ export JAVA_HOME=/usr/lib/jvm/jre-1.6.0-openjdk.x86_64/
Verify that Maven is installed correctly:
$ mvn --version
You probably want to ensure that your environment variables will survive a logout/reboot. Be sure
to update ~/.bashrc with the PATH and JAVA_HOME variables.
Building RPMs for $PRODUCT; is fairly simple. Assuming you already have the source downloaded
and have uncompressed the tarball into a local directory, you're going to be able to generate
packages in just a few minutes.
Packaging has Changed
If you've created packages for $PRODUCT; previously, you should be aware that
the process has changed considerably since the project has moved to using
Apache Maven. Please be sure to follow the steps in this section closely.
3.6.1. Generating RPMS
Now that we have the prerequisites and source, you will cd to the packaging/centos63/ directory.
Generating RPMs is done using the package.sh script:
$./package.sh
That will run for a bit and then place the finished packages in dist/rpmbuild/RPMS/x86_64/.
You should see six RPMs in that directory:
• cloudstack-agent-4.1.0.el6.x86_64.rpm
• cloudstack-awsapi-4.1.0.el6.x86_64.rpm
• cloudstack-cli-4.1.0.el6.x86_64.rpm
4
http://maven.apache.org/download.cgi
32
DEBパッケージのビルド
• cloudstack-common-4.1.0.el6.x86_64.rpm
• cloudstack-management-4.1.0.el6.x86_64.rpm
• cloudstack-usage-4.1.0.el6.x86_64.rpm
Filename Variations
The file names may vary slightly. For instance, if you were to build the RPMs on a
Fedora 18 system, you'd see "fc18" instead of "el6" in the filename. (Fedora 18 isn't
a supported platform at this time, just providing an example.)
3.6.1.1. Creating a yum repo
While RPMs is a useful packaging format - it's most easily consumed from Yum repositories over a
network. The next step is to create a Yum Repo with the finished packages:
$ mkdir -p ~/tmp/repo
$ cp dist/rpmbuild/RPMS/x86_64/*rpm ~/tmp/repo/
$ createrepo ~/tmp/repo
The files and directories within ~/tmp/repo can now be uploaded to a web server and serve as a
yum repository.
3.6.1.2. Configuring your systems to use your new yum repository
Now that your yum repository is populated with RPMs and metadata we need to configure the
machines that need to install $PRODUCT;. Create a file named /etc/yum.repos.d/cloudstack.repo
with this information:
[apache-cloudstack]
name=Apache CloudStack
baseurl=http://webserver.tld/path/to/repo
enabled=1
gpgcheck=0
Completing this step will allow you to easily install $PRODUCT; on a number of machines across
the network.
3.7. DEBパッケージのビルド
In addition to the bootstrap dependencies, you'll also need to install several other dependencies.
Note that we recommend using Maven 3, which is not currently available in 12.04.1 LTS. So, you'll
also need to add a PPA repository that includes Maven 3. After running the command add-aptrepository, you will be prompted to continue and a GPG key will be added.
$ sudo apt-get update
$ sudo apt-get install python-software-properties
33
第3章インストール
$ sudo add-apt-repository ppa:natecarlson/maven3
$ sudo apt-get update
$ sudo apt-get install ant debhelper openjdk-6-jdk tomcat6 libws-commons-util-java genisoimage pythonmysqldb libcommons-codec-java libcommons-httpclient-java liblog4j1.2-java maven3
Now that we have resolved the dependencies we can move on to building CloudStack and
packaging them into DEBs.
mvn clean install -P developer,systemvm
$ dpkg-buildpackge -uc -us
This command will build seven Debian packages. You should have the following:
• cloudstack-agent_4.1.0_all.deb
• cloudstack-awsapi_4.1.0_all.deb
• cloudstack-cli_4.1.0_all.deb
• cloudstack-common_4.1.0_all.deb
• cloudstack-docs_4.1.0_all.deb
• cloudstack-management_4.1.0_all.deb
• cloudstack-usage_4.1.0_all.deb
3.7.1. APTリポジトリの設定
After you've created the packages, you'll want to copy them to a system where you can serve the
packages over HTTP. You'll create a directory for the packages and then use dpkg-scanpackages
to create Packages.gz, which holds information about the archive structure. Finally, you'll add the
repository to your system(s) so you can install the packages using APT.
The first step is to make sure that you have the dpkg-dev package installed. This should have
been installed when you pulled in the debhelper application previously, but if you're generating
Packages.gz on a different system, be sure that it's installed there as well.
$ sudo apt-get install dpkg-dev
The next step is to copy the DEBs to the directory where they can be served over HTTP. We'll use
/var/www/cloudstack/repo in the examples, but change the directory to whatever works for you.
sudo
sudo
sudo
sudo
mkdir -p /var/www/cloudstack/repo/binary
cp *.deb /var/www/cloudstack/repo/binary
cd /var/www/cloudstack/repo/binary
dpkg-scanpackages . /dev/null | tee Packages | gzip -9 > Packages.gz
注記: 上書きファイル
ファイルが存在しない旨のメッセージが表示されますが、ここでは無視して下さい。
34
APTリポジトリの設定
全てのDEBパッケージと Packages.gz は、HTTPサーバの binary ディレクトリに配置されているべきです。(次
の手順に進む前に、wget または curl コマンドでファイルがダウンロードできることを確認して下さい。)
3.7.2. APTリポジトリの設定
以上でリポジトリの作成は完了したので、マシン上に設定を追加してリポジトリを参照できるようにする必要が
あります。 /etc/apt/sources.list.d 配下にレポジトリの情報を追加することで実現できます。好きなエディタ
で以下の行を含むファイル /etc/apt/sources.list.d/cloudstack.list を作成してください。
deb http://server.url/cloudstack/repo binary ./
Now that you have the repository info in place, you'll want to run another update so that APT knows
where to find the CloudStack packages.
$ sudo apt-get update
以上で、Ubuntuにインストールする手順に進むことができます。
3.8. Apache CloudStack の構築に必要なもの
CloudStack を構築する上で、用意すべきものがいくつかあります。このドキュメントではRPMまたはDEBパッ
ケージを使うLinuxシステムについて説明します。
CloudStack をコンパイルするためには最低限以下が必要となります。
1. Maven (version 3)
2. Java (OpenJDK 1.6 or Java 7/OpenJDK 1.7)
3. Apache Web Services Common Utilities (ws-commons-util)
4. MySQL
5. MySQLdb (provides Python database API)
6. Tomcat 6 (not 6.0.35)
7. genisoimage
8. rpmbuild or dpkg-dev
35
36
ユーザーインターフェイス
4.1. UIへのログイン
CloudStack はWebベースのUIを管理者とエンドユーザーの両方に提供しています。ログインに使用したユー
ザーの権限に応じて適切なUIが表示されます。UIはIE7、IE8、IE9、Firefox 3.5以降、Firefox 4、Safari 4 そし
てSafari 5に対応しています。URLは(あなたの環境の管理サーバーのIPアドレスに置き換えてください)
http://<management-server-ip-address>:8080/client
未設定の管理サーバーにアクセスすると、ガイドツアーのスプラッシュスクリーンが表示されます。以降のアクセ
ス時には、ダッシュボードにアクセスするために下記の情報を入力するログイン画面が表示されます。
ユーザー名
あなたのアカウントのユーザーID。デフォルトのユーザー名はadminです。
パスワード
ユーザーIDに関連付けられたパスワード。デフォルトユーザーのパスワードはpasswordです。
ドメイン
もしもあなたがrootドメインのユーザーならば、フィールドは空白のままにします。
もしもあなたがサブドメインのユーザーならば、rootドメインを除いた、そのドメインへのフルパスを入力します。
例えばrootドメインの下にComp1/hrといった複数階層があると仮定します。Comp1ドメインのユーザーはド
メインフィールドにComp1と入力し、Comp1/salesドメインのユーザーはComp1/salesと入力します。
より詳細なUIへのログインのガイドラインに関しては「ルート管理者としてのログイン」を参照してください。
4.1.1. End User's UI Overview
CloudStack ユーザーインターフェイスはユーザーのクラウドインフラストラクチャにおいて閲覧や仮想マシン、
テンプレートと ISO、データボリュームとスナップショット、ゲストネットワーク、IP アドレスなどのクラウドリソース
の利用を手助けします。もしユーザーが1つ以上の CloudStack プロジェクトのメンバーもしくは管理者である
場合、ユーザーインターフェイスはプロジェクト向けのビューを提供します。
4.1.2. Root Administrator's UI Overview
CloudStack UI は CloudStack 管理者のプロビジョニングや確認、クラウドインフラストラクチャやドメイン、
ユーザーアカウント、プロジェクト、構成設定の管理を手助けします。初回の管理サーバーのインストール時、ク
ラウドインフラストラクチャのプロビジョニングのため、次のガイドツアーを利用できます。ログイン後、ユーザー
毎のダッシュボードが表示され、様々なリンクや、様々な管理者機能へのナビゲーションバーが左側に表示され
ます。Root 管理者はエンドユーザーに提供されている UI のように全てのタスクを UI から利用することができ
ます。
4.1.3. ルート管理者としてのログイン
管理サーバーをインストールして起動後、CloudStack のユーザーインターフェイスを起動させることができま
す。このユーザーインターフェイスはプロビジョニングやビュー、クラウドインフラストラクチャの管理を手助けしま
す。
37
第4章ユーザーインターフェイス
1. お好みのウェブブラウザーを開き URL を入力します。代わりに管理サーバーの IP アドレスを入力すること
もできます。
http://<management-server-ip-address>:8080/client
新しくインストールされた管理サーバーにログインするとガイドツアーのスプラッシュ画面が表示されます。
後にアクセスした場合は直接ダッシュボード画面が表示されます。
2. 初回スプラッシュ画面が表示され、次の項目が選択できます。
• Continue with basic setup. Choose this if you're just trying CloudStack, and you want a
guided walkthrough of the simplest possible configuration so that you can get started right
away. We'll help you set up a cloud with the following features: a single machine that runs
CloudStack software and uses NFS to provide storage; a single machine running VMs under
the XenServer or KVM hypervisor; and a shared public network.
ツアーガイドで表示される情報は全て必要な情報になります。しかしより詳細を知りたい場合は次の「ト
ライアルインストールガイド」を参照することもできます。
• I have used CloudStack before 既に高度な展開を設計、計画したことがある、もしくは基本セットアッ
プでセットアップしたトライアルクラウドをよりスケールアップさせたい場合はこちらを選びます。管理者イ
ンターフェイスからはより高度な VLAN ネットワーク、高可用性、負荷分散装置やファイアウォールなどの
追加のネットワーク要素、Citrix XenServer, KVM, VMware vSphere を含む様々なハイパーバイザー
のサポートといった機能を利用することができます。
ルート管理者のダッシュボードが表示されます。
3. 新しいルート管理者のパスワードを設定するべきです。もし基本セットアップを選択した場合、新しいパス
ワードの入力画面が表示されます。もし経験済みユーザーを選択した場合は �� の手順を参照し
てください。
警告
ルート管理者としてログインした場合、物理インフラストラクチャを含むCloudStack の展開
を管理します。ルート管理者は一般的な機能を変更するための設定変更や、ユーザーアカウ
ントの作成と削除、その他多くの権限を持つ行動を振る舞うことができます。そのためデフォ
ルトのパスワードは新しく一意なパスワードに変更してください。
4.1.4. ルートパスワードの変更
CloudStack のインストール中は、ルート管理者としてログオンしています。このアカウントを使用して、物理イン
フラストラクチャを含めて CloudStack 環境を管理します。ルート管理者は、構成設定を変更して基本機能を変
更したり、ユーザーアカウントを作成または削除したり、権限を持つ人物のみが実行する必要のある多くの措置
を取ることができます。初回の CloudStack インストールの際はデフォルトのパスワードである password を新
しい固有の値に変更してください。
1. お好みのウェブブラウザーを開き URL を入力します。代わりに管理サーバーの IP アドレスを入力すること
もできます。
http://<management-server-ip-address>:8080/client
38
Using SSH Keys for Authentication
2. 現在のルートユーザーの ID とパスワードで CloudStack ユーザーインターフェイスにログオンします。デ
フォルトは admin および password です。
3. [Accounts]をクリックします。
4. 管理者のアカウント名をクリックします。
5. [View Users]をクリックします。
6. 管理者のユーザー名をクリックします。
7.
Click the Change Password button.
8. 新しいパスワードを入力して[OK]をクリックします。
4.2. Using SSH Keys for Authentication
In addition to the username and password authentication, CloudStack supports using SSH keys to
log in to the cloud infrastructure for additional security. You can use the createSSHKeyPair API to
generate the SSH keys.
Because each cloud user has their own SSH key, one cloud user cannot log in to another cloud
user's instances unless they share their SSH key files. Using a single SSH key pair, you can manage
multiple instances.
4.2.1. Creating an Instance Template that Supports SSH Keys
Create a instance template that supports SSH Keys.
1. Create a new instance by using the template provided by cloudstack.
For more information on creating a new instance, see
1
2. Download the cloudstack script from The SSH Key Gen Script to the instance you have created.
wget http://downloads.sourceforge.net/project/cloudstack/SSH%20Key%20Gen%20Script/cloud-set-guestsshkey.in?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fcloudstack%2Ffiles%2FSSH%2520Key%2520Gen%2520Script
%2F&ts=1331225219&use_mirror=iweb
3. Copy the file to /etc/init.d.
cp cloud-set-guest-sshkey.in /etc/init.d/
4. Give the necessary permissions on the script:
chmod +x /etc/init.d/cloud-set-guest-sshkey.in
5. Run the script while starting up the operating system:
chkconfig --add cloud-set-guest-sshkey.in
6. Stop the instance.
39
第4章ユーザーインターフェイス
4.2.2. Creating the SSH Keypair
You must make a call to the createSSHKeyPair api method. You can either use the CloudStack
Python API library or the curl commands to make the call to the cloudstack api.
For example, make a call from the cloudstack server to create a SSH keypair called "keypair-doc"
for the admin account in the root domain:
注記
Ensure that you adjust these values to meet your needs. If you are making the API
call from a different server, your URL/PORT will be different, and you will need to
use the API keys.
1. Run the following curl command:
curl --globoff "http://localhost:8096/?command=createSSHKeyPair&name=keypairdoc&account=admin&domainid=5163440e-c44b-42b5-9109-ad75cae8e8a2"
The output is something similar to what is given below:
<?xml version="1.0" encoding="ISO-8859-1"?><createsshkeypairresponse
cloud-stack-version="3.0.0.20120228045507"><keypair><name>keypair-doc</
name><fingerprint>f6:77:39:d5:5e:77:02:22:6a:d8:7f:ce:ab:cd:b3:56</fingerprint><privatekey>-----BEGIN RSA
PRIVATE KEY----MIICXQIBAAKBgQCSydmnQ67jP6lNoXdX3noZjQdrMAWNQZ7y5SrEu4wDxplvhYci
dXYBeZVwakDVsU2MLGl/K+wefwefwefwefwefJyKJaogMKn7BperPD6n1wIDAQAB
AoGAdXaJ7uyZKeRDoy6wA0UmF0kSPbMZCR+UTIHNkS/E0/4U+6lhMokmFSHtu
mfDZ1kGGDYhMsdytjDBztljawfawfeawefawfawfawQQDCjEsoRdgkduTy
QpbSGDIa11Jsc+XNDx2fgRinDsxXI/zJYXTKRhSl/LIPHBw/brW8vzxhOlSOrwm7
VvemkkgpAkEAwSeEw394LYZiEVv395ar9MLRVTVLwpo54jC4tsOxQCBlloocK
lYaocpk0yBqqOUSBawfIiDCuLXSdvBo1Xz5ICTM19vgvEp/+kMuECQBzm
nVo8b2Gvyagqt/KEQo8wzH2THghZ1qQ1QRhIeJG2aissEacF6bGB2oZ7Igim5L14
4KR7OeEToyCLC2k+02UCQQCrniSnWKtDVoVqeK/zbB32JhW3Wullv5p5zUEcd
KfEEuzcCUIxtJYTahJ1pvlFkQ8anpuxjSEDp8x/18bq3
-----END RSA PRIVATE KEY----</privatekey></keypair></createsshkeypairresponse>
2. Copy the key data into a file. The file looks like this:
-----BEGIN RSA PRIVATE KEY----MIICXQIBAAKBgQCSydmnQ67jP6lNoXdX3noZjQdrMAWNQZ7y5SrEu4wDxplvhYci
dXYBeZVwakDVsU2MLGl/K+wefwefwefwefwefJyKJaogMKn7BperPD6n1wIDAQAB
AoGAdXaJ7uyZKeRDoy6wA0UmF0kSPbMZCR+UTIHNkS/E0/4U+6lhMokmFSHtu
mfDZ1kGGDYhMsdytjDBztljawfawfeawefawfawfawQQDCjEsoRdgkduTy
QpbSGDIa11Jsc+XNDx2fgRinDsxXI/zJYXTKRhSl/LIPHBw/brW8vzxhOlSOrwm7
VvemkkgpAkEAwSeEw394LYZiEVv395ar9MLRVTVLwpo54jC4tsOxQCBlloocK
lYaocpk0yBqqOUSBawfIiDCuLXSdvBo1Xz5ICTM19vgvEp/+kMuECQBzm
nVo8b2Gvyagqt/KEQo8wzH2THghZ1qQ1QRhIeJG2aissEacF6bGB2oZ7Igim5L14
4KR7OeEToyCLC2k+02UCQQCrniSnWKtDVoVqeK/zbB32JhW3Wullv5p5zUEcd
KfEEuzcCUIxtJYTahJ1pvlFkQ8anpuxjSEDp8x/18bq3
-----END RSA PRIVATE KEY-----
3. Save the file.
40
Creating an Instance
4.2.3. Creating an Instance
After you save the SSH keypair file, you must create an instance by using the template that you
created at � Creating an Instance Template that Supports SSH Keys�. Ensure that you use the same
SSH key name that you created at �Creating the SSH Keypair�.
注記
You cannot create the instance by using the GUI at this time and associate the
instance with the newly created SSH keypair.
A sample curl command to create a new instance is:
curl --globoff http://localhost:<port number>/?command=deployVirtualMachine
\&zoneId=1\&serviceOfferingId=18727021-7556-4110-9322-d625b52e0813\&templateId=e899c18ace13-4bbf-98a9-625c5026e0b5\&securitygroupids=ff03f02f-9e3b-48f8-834d-91b822da40c5\&account=admin
\&domainid=1\&keypair=keypair-doc
Substitute the template, service offering and security group IDs (if you are using the security group
feature) that are in your cloud environment.
4.2.4. Logging In Using the SSH Keypair
To test your SSH key generation is successful, check whether you can log in to the cloud setup.
For exaple, from a Linux OS, run:
ssh -i ~/.ssh/keypair-doc <ip address>
The -i parameter tells the ssh client to use a ssh key found at ~/.ssh/keypair-doc.
4.2.5. Resetting SSH Keys
With the API command resetSSHKeyForVirtualMachine, a user can set or reset the SSH keypair
assigned to a virtual machine. A lost or compromised SSH keypair can be changed, and the user
can access the VM by using the new keypair. Just create or register a new keypair, then call
resetSSHKeyForVirtualMachine.
41
42
Steps to Provisioning Your Cloud Infrastructure
This section tells how to add regions, zones, pods, clusters, hosts, storage, and networks to your
cloud. If you are unfamiliar with these entities, please begin by looking through 2��
��.
5.1. プロビジョニングの概要
管理サーバーのインストールや稼働後、新しいコンピューティングリソースを管理のために追加することができ
ます。CloudStack クラウドインストラクチャがどのように組織化されるかに関しては �� を参照し
てください。
クラウドインフラストラクチャを展開する、必要な時にスケールアップするには以下の手順に従ってください。
1. Define regions (optional). See �� (��)�.
2. Add a zone to the region. See ��.
3. Add more pods to the zone (optional). See ��.
4. Add more clusters to the pod (optional). See ��.
5. Add more hosts to the cluster (optional). See ��.
6. Add primary storage to the cluster. See ��.
7. Add secondary storage to the zone. See ��.
8. 新規クラウドの作成、テストに関しては �� を参照してください。
これらの手順が完了したら、以下の一般的な構成を参考に展開することができます。
43
第5章 Steps to Provisioning Your Cloud Infrastructure
5.2. リージョンの追加 (オプション)
オプションとして、クラウドリソースを地域的にグルーピングするリージョンを設定できます。リージョンについて
の概要は、 �� を参照して下さい。
5.2.1. 1つめのリージョン: デフォルトリージョン
リージョンを定義しない場合、全てのゾーンは自動的に1つのリージョンにまとめられます。この場合、リージョン
IDは1が設定されます。
updateRegion APIコマンドを使用して、デフォルトリージョンの名前またはURLを変更することができます。例
えば:
http://<IP_of_Management_Server>:8080/client/api?command=updateRegion&id=1&name=Northern&endpoint=http://
<region_1_IP_address_here>:8080/client&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXqjB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
5.2.2. リージョンの追加
これらは、デフォルトリージョンに加え2つめのリージョンを追加する手順です。
1. Each region has its own CloudStack instance. Therefore, the first step of creating a new region is
to install the Management Server software, on one or more nodes, in the geographic area where
you want to set up the new region. Use the steps in the Installation guide. When you come to
the step where you set up the database, use the additional command-line flag -r <region_id>
to set a region ID for the new region. The default region is automatically assigned a region ID
of 1, so your first additional region might be region 2.
44
3番めのリージョンの追加
cloudstack-setup-databases cloud:<dbpassword>@localhost --deploy-as=root:<password> -e <encryption_type> -m
<management_server_key> -k <database_key> -r <region_id>
2. インストール工程の終盤にさしかかる頃にはManagement Serverは既に立ち上がっているはずです。管
理サーバのインストールが問題なく完了していることを確認してください。
3. Add region 2 to region 1. Use the API command addRegion. (For information about how to
make an API call, see the Developer's Guide.)
http://<IP_of_region_1_Management_Server>:8080/client/api?
command=addRegion&id=2&name=Western&endpoint=http://<region_2_IP_address_here>:8080/
client&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXqjB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
4. リージョン2にリージョン1に追加する場合も、同じコマンドを使用します。
http://<IP_of_region_2_Management_Server>:8080/client/api?
command=addRegion&id=1&name=Northern&endpoint=http://<region_1_IP_address_here>:8080/
client&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXqjB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
5. リージョン1からリージョン2のデータベースに、アカウント、ユーザ、ドメインテーブルをコピーします。
次のコマンドでは、データベースのrootパスワードが設定済みであることを想定しており、これは、
CloudStack にて推奨されるベストプラクティスです。MySQLパスワードは、自身の環境のものに置き換え
て下さい。
a. 最初に、データベースのコンテンツをコピーするコマンドを実行します。
# mysqldump -u root -p<mysql_password> -h <region1_db_host> cloud account user domain > region1.sql
b. そのデータを、下記のコマンドでリージョン2のデータベースに格納します。
# mysql -u root -p<mysql_password> -h <region2_db_host> cloud < region1.sql
6. プロジェクトのアカウントを削除します。このコマンドをリージョン2のデータベースで実行します。
mysql> delete from account where type = 5;
7. デフォルトゾーンをnullにします。
mysql> update account set default_zone_id = null;
8. リージョン2の管理サーバーを再起動します。
5.2.3. 3番めのリージョンの追加
3つ目、またはそれ以降のリージョンを追加するには、2つ目のリージョンを追加するときの手順とほぼ同じで
す。しかし、追加するリージョンの数だけ同じ工程を実施する必要があります。
45
第5章 Steps to Provisioning Your Cloud Infrastructure
1. 追加リージョン毎に CloudStack をインストールします。データベースセットアップの工程でリージョンのID
を設定します。
cloudstack-setup-databases cloud:<dbpassword>@localhost --deploy-as=root:<password> -e <encryption_type> -m
<management_server_key> -k <database_key> -r <region_id>
2. 管理サーバーの起動後、addRegion APIコマンドを繰り返し実行することで既存のリージョンに新しいリー
ジョンを追加します。例えば、リージョン3を追加した場合は:
http://<IP_of_region_1_Management_Server>:8080/client/api?
command=addRegion&id=3&name=Eastern&endpoint=http://<region_3_IP_address_here>:8080/
client&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXqjB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
http://<IP_of_region_2_Management_Server>:8080/client/api?
command=addRegion&id=3&name=Eastern&endpoint=http://<region_3_IP_address_here>:8080/
client&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXqjB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
3. 新しいリージョンに既存の全てのリージョンを追加するには、逆の手順を繰り返します。例えば、リージョン3
に既存の2つのリージョンを追加する場合は:
http://<IP_of_region_3_Management_Server>:8080/client/api?
command=addRegion&id=1&name=Northern&endpoint=http://<region_1_IP_address_here>:8080/
client&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXqjB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
http://<IP_of_region_3_Management_Server>:8080/client/api?
command=addRegion&id=2&name=Western&endpoint=http://<region_2_IP_address_here>:8080/
client&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXqjB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
4. Copy the account, user, and domain tables from any existing region's database to the new
region's database.
次のコマンドでは、データベースのrootパスワードが設定済みであることを想定しており、これは、
CloudStack にて推奨されるベストプラクティスです。MySQLパスワードは、自身の環境のものに置き換え
て下さい。
a. 最初に、データベースのコンテンツをコピーするコマンドを実行します。
# mysqldump -u root -p<mysql_password> -h <region1_db_host> cloud account user domain > region1.sql
b. Then run this command to put the data onto the new region's database. For example, for
region 3:
# mysql -u root -p<mysql_password> -h <region3_db_host> cloud < region1.sql
5. プロジェクトのアカウントを削除します。このコマンドをリージョン2のデータベースで実行します。
mysql> delete from account where type = 5;
6. デフォルトゾーンをnullにします。
46
リージョンの削除
mysql> update account set default_zone_id = null;
7. 新しいリージョンで管理サーバーを再起動します。
5.2.4. リージョンの削除
リージョンを削除するには、removeRegion APIコマンドを使用します。全てのリージョンからリージョン情報を
削除するため、これを繰り返し実行します。例えば、3つのリージョンの3番めのリージョンを削除するには:
http://<IP_of_region_1_Management_Server>:8080/client/api?
command=removeRegion&id=3&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXqjB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
http://<IP_of_region_2_Management_Server>:8080/client/api?
command=removeRegion&id=3&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXqjB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
5.3. ゾーンの追加
次の手順は、CloudStack ユーザーインターフェイスにログオン済みであることを前提としています(�UI��を
参照)。
1. (オプション)クラウド全体のセカンダリストレージとして Swift を使用する場合は、ゾーンを追加する前に
Swift を追加する必要があります。
a. CloudStackユーザーインターフェイスに管理者としてログオンします。
b. 初めてユーザーインターフェイスを使用する場合は、ガイドツアーのスプラッシュページが開きま
す。\n[Experienced user]を選択します。ダッシュボードが開きます。
c. 左側のナビゲーションバーで[Global Settings]をクリックします。
d. 検索ボックスに「swift.enable」と入力して検索ボタンをクリックします。
e.
f.
[Edit]アイコンをクリックして swift.enable を true に設定します。
管理サーバーを再起動します。
# service cloudstack-management restart
g. CloudStack ユーザーインターフェイスが表示されている Web ブラウザータブを更新して再度ログオ
ンします。
2. 左側のナビゲーションバーで[Infrastructure]をクリックします。
3. [Zones]で[View More]をクリックします。
4. (オプション)Swift ストレージを使用する場合は、[Edit Swift]をクリックします。次の情報を指定します。
• URL : Swift URL です。
• Account : Swift アカウントです。
47
第5章 Steps to Provisioning Your Cloud Infrastructure
• Username : Swift アカウントのユーザー名です。
• Key : Swift キーです。
5. [Add Zone]をクリックします。ゾーンの作成ウィザードが開きます。
6. 次のどちらかのネットワークの種類を選択します。
• Basic : AWS スタイルのネットワークシステムに対応します。単一のネットワークを提供します。このネット
ワークにより、各仮想マシンインスタンスに直接 IP アドレスが割り当てられます。セキュリティグループ(発
信元 IP アドレスのフィルター)のようなレイヤー3 レベルの方法でゲストを分離できます。
• Advanced : より高度なネットワークトポロジに対応します。このネットワークモデルでは、最も柔軟に、ゲ
ストネットワークを定義し、ファイアウォール、VPN、負荷分散装置のサポートなどのカスタムネットワーク
オファリングを提供できます。
ネットワークの種類について詳しくは、�� を参照してください。
7. 以降の手順は、[Basic]または[Advanced]のどちらを選択したかによって異なります。該当する手順を続行
してください。
• ��
• ��
5.3.1. 基本ゾーンの構成
1. ゾーンの追加ウィザードで［Basic］を選択して［Next］をクリックすると、次の項目の入力を求められます。
入力後、［Next］をクリックします。
• Name: ゾーンの名前です。
• DNS1およびDNS2:
ゾーン内のゲスト仮想マシンで使用するDNSサーバーです。これらのDNSサー
バーには、後で追加するパブリックネットワーク経由でアクセスします。ゾーンのパブリックIPアドレスか
ら、ここで指定するDNSサーバーに通信できる必要があります。
• Internal DNS1およびInternal DNS2：これらのDNSサーバーは、ゾーン内のシステム仮想マシン(仮想
ルーター、コンソールプロキシ、およびセカンダリストレージ仮想マシンなど、CloudStackにより使用さ
れる仮想マシン)によって使用されます。これらのDNSサーバーは、システム仮想マシンの管理トラフィッ
クネットワークインターフェイスを介してアクセスされます。ポッドのプライベートIPアドレスから、ここで指
定する内部DNSサーバーに通信できる必要があります。
• Hypervisor： (Version 3.0.1より)ゾーンの最初のクラスターのハイパーバイザーを選択します。ゾーン
の追加後に、異なるハイパーバイザーを使用するクラスターを追加できます。
• Network Offering：ここでの選択により、ゲスト仮想マシンのネットワークで使用できるネットワークサー
ビスが決まります。
Network Offering
説明
DefaultSharedNetworkOfferingWithSGServiceゲストトラフィックの分離のためにセキュリティグ
ループを有効にする場合は、これを選択します
(「セキュリティグループによる仮想マシンに対する
トラフィックの制御」を参照)。
48
基本ゾーンの構成
Network Offering
説明
DefaultSharedNetworkOffering
セキュリティグループが必要ない場合は、これを
選択します。
DefaultSharedNetscalerEIPandELBNetworkOffering
ゾーンネットワークの一部としてCitrix NetScaler
アプライアンスを設置済みで、エラスティックIPお
よびエラスティック負荷分散の機能を使用する場
合は、これを選択します。エラスティックIPおよびエ
ラスティック負荷分散の機能を使用すると、セキュ
リティグループが有効な基本ゾーンで1対1の静
的NATおよび負荷分散を提供できます。
• Network
Domain：(オプション)ゲスト仮想マシンネットワークに特別なドメイン名を割り当てる場合
は、DNSサフィックスを指定します。
• Public：すべてのユーザーがパブリックゾーンを利用できます。パブリックではないゾーンは、特定のドメ
インに割り当てられます。そのドメイン内のユーザーだけが、このゾーンにゲスト仮想マシンを作成するこ
とを許可されます。
2. 物理ネットワークにより伝送されるトラフィックの種類を選択します。
トラフィックの種類は、管理、パブリック、ゲスト、およびストレージトラフィックです。種類について詳しくは、ア
イコンにマウスポインターを合わせてツールチップを表示するか、「基本ゾーンのネットワークトラフィックの
種類」を参照してください。この画面は、いくつかのトラフィックの種類が既に割り当てられた状態で開きま
す。さらに追加するには、トラフィックの種類をネットワークにドラッグアンドドロップしてください。また、必要
に応じてネットワーク名を変更することもできます。
3. (3.0.1 より)物理ネットワーク上の各トラフィックの種類にネットワークトラフィックラベルを割り当てます。こ
のラベルは、ハイパーバイザーホストに定義済みのラベルと一致する必要があります。各ラベルを割り当て
るには、トラフィックの種類のアイコンの下の[Edit]をクリックします。ラベルを入力するダイアログボックスが
開くので入力します。 [OK]をクリックします。
これらのトラフィックラベルは、最初のクラスターに選択したハイパーバイザーのためにのみ定義します。ほ
かのすべてのハイパーバイザーについては、ゾーンを作成してからラベルを構成できます。
4. ［Next］をクリックします。
5. (NetScalerのみ)NetScaler用のネットワークオファリングを選択する場合は、追加の表示画面がありま
す。NetScalerのセットアップに必要な項目を入力したら、［Next］をクリックします。
• IP address：NetScalerデバイスのNSIP(NetScaler IP)アドレスです。
• UsernameおよびPassword：デバイスにアクセスするための認証資格情報です。CloudStackは、この
資格情報を使用してデバイスにアクセスします。
• Type：追加するNetScalerデバイスの種類です。［NetScaler
VPX］、［NetScaler
MPX］、または
［NetScaler SDX］です。種類を比較するには、『CloudStack管理ガイド』を参照してください。
• Public interface：パブリックネットワークの一部として構成されるNetScalerのインターフェイスです。
• Private interface：プライベートネットワークの一部として構成されるNetScalerのインターフェイスです。
• Number of retries：操作が失敗したとみなす前にデバイスに対してコマンドを試行する回数です。デ
フォルトは2です。
49
第5章 Steps to Provisioning Your Cloud Infrastructure
• Capacity：このNetScalerデバイスを共有するゲストネットワーク/アカウントの数です。
• Dedicated：専用のデバイスは単一のアカウント専用になります。［Dedicated］チェックボックスをオン
にすると、［Capacity］ボックスの値は無視され、暗黙的に1であるとみなされます。
6. (NetScalerのみ)パブリックトラフィックのIPアドレスの範囲を構成します。この範囲内のIPアドレスは、EIP
およびELBが有効なNetScalerのネットワークオファリングを選択することによって有効にする、静的NAT機
能に使用されます。次の詳細情報を入力し、［Add］をクリックします。必要に応じてこの手順を繰り返し、さ
らにIPアドレスの範囲を追加できます。完了したら［Next］をクリックします。
• Gateway：これらのIPアドレスに使用するゲートウェイです。
• Netmask：このIPアドレスの範囲に関連付けるネットマスクです。
• VLAN：パブリックトラフィックに使用するVLANです。
• Start IPおよびEnd IP：インターネットからアクセスできるとみなされるIPアドレスの範囲で、ゲスト仮想マ
シンへのアクセスのために割り当てます。
7. 新しいゾーンでは、CloudStackにより最初のポッドが自動的に追加されます。後でさらにポッドを追加でき
ます。ポッドの概要については、「ポッドについて」を参照してください。
最初のポッドを構成するには、次の項目を入力して［Next］をクリックします。
• Pod Name：ポッドの名前です。
• Reserved system gateway：このポッド内のホストのゲートウェイです。
• Reserved system netmask. The network prefix that defines the pod's subnet. Use CIDR
notation.
• Start Reserved System IPおよびEnd Reserved System IP：セカンダリストレージ仮想マシン、コンソー
ルプロキシ仮想マシン、およびDHCPなどのさまざまなシステム仮想マシンを管理するため
に、CloudStackで使用する管理ネットワーク内のIPアドレスの範囲です。詳しくは、「システムにより予約
済みのIPアドレス」を参照してください。
8. ゲストトラフィック用のネットワークを構成します。次の情報を指定してから、［Next］をクリックします。
• Guest gateway：ゲストが使用するゲートウェイです。
• Guest netmask：ゲストの使用するサブネット上で使用されるネットマスクです。
• Guest start IPおよびGuest end IP：CloudStackがゲストに割り当てられるIPアドレスの範囲を定義す
る、最初と最後のIPアドレスを入力します。
• 複数のNICを使用することを強くお勧めします。複数のNICを使用する場合は、別のサブネットに存在
するIPアドレスを入力できます。
• NICを1つ使用する場合は、これらのIPアドレスは、ポッドのCIDRと同じCIDRに存在する必要があり
ます。
9. 新しいポッドでは、CloudStackにより最初のクラスターが自動的に追加されます。後でさらにクラスターを
追加できます。クラスターの概要については、「クラスターについて」を参照してください。
最初のクラスターを構成するには、次の項目を入力して［Next］をクリックします。
50
基本ゾーンの構成
• Hypervisor：(Version 3.0.0のみ。3.0.1では読み取り専用)このクラスター内のすべてのホストで実行
される、ハイパーバイザーソフトウェアの種類を選択します。VMwareを選択すると追加のフィールドが表
示され、vSphereクラスターに関する情報を指定できます。vSphereサーバーの場合は、vCenterでホス
トのクラスターを作成した後、クラスター全体をCloudStackに追加することをお勧めします。「クラスター
の追加：vSphere」を参照してください。
• Cluster name：クラスターの名前を入力します。任意の、CloudStackで使用されていないテキストを指
定します。
10. 新しいクラスターでは、CloudStackにより最初のホストが自動的に追加されます。後でさらにホストを追加
できます。ホストの概要については、「ホストについて」を参照してください。
注記
CloudStackを展開するときに、ハイパーバイザーに実行中の仮想マシンがあってはいけ
ません。
ホストを構成する前に、ハイパーバイザーソフトウェアをホストにインストールする必要がありま
す。CloudStackがサポートするハイパーバイザーソフトウェアのバージョン、およびホストをCloudStackと
連動させるために必要な追加構成を確認しておく必要があります。このインストールについて詳しくは、次
のセクションを参照してください。
• Citrix XenServerのインストールと構成
• VMware vSphereのインストールと構成
• KVMのインストールと構成
最初のホストを構成するには、次の項目を入力して［Next］をクリックします。
• Host Name：ホストのDNS名またはIPアドレスです。
• Username：通常はrootです。
• Password：上のユーザー名に対するパスワードです(XenServerまたはKVM側で指定したもの)。
• Host Tags. (Optional) Any labels that you use to categorize hosts for ease of maintenance.
For example, you can set this to the cloud's HA tag (set in the ha.tag global configuration
parameter) if you want this host to be used only for VMs with the "high availability" feature
enabled. For more information, see HA-Enabled Virtual Machines as well as HA for Hosts.
11. 新しいクラスターでは、CloudStack
により最初のプライマリストレージサーバーが自動的に追加されま
す。後でさらにサーバーを追加できます。プライマリストレージの概要については、「プライマリストレージに
ついて」を参照してください。
最初のプライマリストレージサーバーを構成するには、次の項目を入力して［Next］をクリックします。
• Name：ストレージデバイスの名前です。
• Protocol : XenServer の場合は、[NFS]、[iSCSI]、または[PreSetup]を選択します。KVM の場合は、
[NFS]、[SharedMountPoint]、[CLVM]または[RBD]を選択します。vSphere の場合は、[VMFS](iSCSI
またはファイバーチャネル)または [NFS]を選択します。画面のそのほかのフィールドは、ここで選択したも
のにより異なります。
51
第5章 Steps to Provisioning Your Cloud Infrastructure
5.3.2. 拡張ゾーンの構成
1. ゾーンの追加ウィザードで[Advanced]を選択して[Next]をクリックすると、次の詳細の入力を求められま
す。入力後、[Next]をクリックします。
• Name : ゾーンの名前です。
• DNS1およびDNS2 : ゾーン内のゲスト仮想マシンで使用するDNSサーバーです。これらのDNSサー
バーには、後で追加するパブリックネットワーク経由でアクセスします。ゾーンのパブリックIPアドレスか
ら、ここで指定するDNSサーバーに通信できる必要があります。
• Internal DNS1 および Internal DNS2 : これらの DNS サーバーは、ゾーン内のシステム仮想マシン
(仮想ルーター、コンソールプロキシ、およびセカンダリストレージ仮想マシンなど、CloudStack により使
用される仮想マシン)によって使用されます。これらの DNS サーバーは、システム仮想マシンの管理トラ
フィックネットワークインターフェイスを介してアクセスされます。ポッドのプライベート IP アドレスから、ここ
で指定する内部 DNS サーバーに通信できる必要があります。
• Network Domain : (オプション)ゲスト仮想マシンネットワークに特別なドメイン名を割り当てる場合
は、DNSサフィックスを指定します。
• Guest CIDR : このゾーンのゲスト仮想ネットワークで使用される IP アドレスを記述する CIDR です。これ
はたとえば、10.1.1.0/24 です。ゾーンごとに異なる CIDR を設定することをお勧めします。これにより、
異なるゾーンのネットワーク間で簡単に VPN をセットアップできるようになります。
• Hypervisor : (Version 3.0.1より) ゾーンの最初のクラスターのハイパーバイザーを選択します。ゾーン
の追加後に、異なるハイパーバイザーを使用するクラスターを追加できます。
• Public : すべてのユーザーがパブリックゾーンを利用できます。パブリックではないゾーンは、特定のドメ
インに割り当てられます。そのドメイン内のユーザーだけが、このゾーンにゲスト仮想マシンを作成するこ
とを許可されます。
2. 物理ネットワークにより伝送されるトラフィックの種類を選択します。
トラフィックの種類は、管理、パブリック、ゲスト、およびストレージトラフィックです。種類について詳しくは、ア
イコンにマウスポインターを合わせてツールチップを表示するか、�� を参照してください。
この画面が表示される時点で、1 つのネットワークが既に構成されています。複数の物理ネットワークがあ
る場合は、ネットワークを追加する必要があります。トラフィックの種類をドラッグして非アクティブなネット
ワークにドロップすると、ネットワークがアクティブになります。トラフィックアイコンをネットワーク間で移動で
きます。たとえば、Network 1 に表示されているデフォルトのトラフィックの種類が実際の設定と一致しな
い場合は、トラフィックの種類を移動できます。また、必要に応じてネットワーク名を変更することもできます。
3. (Version 3.0.1 より)各物理ネットワーク上の各トラフィックの種類にネットワークトラフィックラベルを割り
当てます。このラベルは、ハイパーバイザーホストに定義済みのラベルと一致する必要があります。各ラベ
ルを割り当てるには、各物理ネットワーク内のトラフィックの種類のアイコンの下の[Edit] をクリックします。
ラベルを入力するダイアログボックスが開くので入力します。[OK] をクリックします。
これらのトラフィックラベルは、最初のクラスターに選択したハイパーバイザーのためにのみ定義します。ほ
かのすべてのハイパーバイザーについては、ゾーンを作成してからラベルを構成できます。
4. ［Next］をクリックします。
5. パブリックインターネットトラフィックの IP アドレスの範囲を構成します。次の詳細情報を入力し、[Add]をク
リックします。必要に応じてこの手順を繰り返し、さらにパブリックインターネットの IP アドレスの範囲を追加
できます。完了したら[Next]をクリックします。
52
拡張ゾーンの構成
• Gateway : これらのIPアドレスに使用するゲートウェイです。
• Netmask : このIPアドレスの範囲に関連付けるネットマスクです。
• VLAN : パブリックトラフィックに使用するVLANです。
• Start IP および End IP : インターネットからアクセスできるとみなされる IP アドレスの範囲で、ゲストネッ
トワークへのアクセスのために割り当てます。
6. 新しいゾーンでは、CloudStackにより最初のポッドが自動的に追加されます。後でさらにポッドを追加でき
ます。ポッドの概要については、�� を参照してください。
最初のポッドを構成するには、次の項目を入力して［Next］をクリックします。
• Pod Name : ポッドの名前です。
• Reserved system gateway : このポッド内のホストのゲートウェイです。
• Reserved system netmask. The network prefix that defines the pod's subnet. Use CIDR
notation.
• Start Reserved System IP および End Reserved System IP : セカンダリストレージ仮想マシ
ン、コンソールプロキシ仮想マシン、および DHCP などのさまざまなシステム仮想マシンを管理するため
に、CloudStack で使用する管理ネットワーク内の IP アドレスの範囲です。詳しくは、�� IP ��
を参照してください。
7. 各物理ネットワークのゲストトラフィックを伝送する VLAN ID の範囲を指定して(「VLAN 割り当ての例」)、
[Next] をクリックします。
8. 新しいポッドでは、CloudStack により最初のクラスターが自動的に追加されます。後でさらにクラスターを
追加できます。クラスターの概要については、�� を参照してください。
最初のクラスターを構成するには、次の項目を入力して［Next］をクリックします。
• Hypervisor : (Version 3.0.0 のみ。3.0.1 では読み取り専用)このクラスター内のすべてのホストで実
行される、ハイパーバイザーソフトウェアの種類を選択します。VMware を選択すると追加のフィールドが
表示され、vSphere クラスターに関する情報を指定できます。vSphere サーバーの場合は、vCenter で
ホストのクラスターを作成した後、クラスター全体を CloudStack に追加することをお勧めします。「クラ
スターの追加:vSphere」参照してください。
• Cluster name : クラスターの名前を入力します。任意の、CloudStackで使用されていないテキストを指
定します。
9. 新しいクラスターでは、CloudStack により最初のホストが自動的に追加されます。後でさらにホストを追
加できます。\nホストの概要については、�� を参照してください。
注記
CloudStack を展開するときに、ハイパーバイザーに実行中の仮想マシンがあってはい
けません。
ホストを構成する前に、ハイパーバイザーソフトウェアをホストにインストールする必要がありま
す。CloudStackがサポートするハイパーバイザーソフトウェアのバージョン、およびホストをCloudStackと
53
第5章 Steps to Provisioning Your Cloud Infrastructure
連動させるために必要な追加構成を確認しておく必要があります。このインストールについて詳しくは、次
のセクションを参照してください。
• CloudStackのためのCitrix XenServerのインストール
• VMware vSphereのインストールと設定
• KVMのインストールと設定
最初のホストを構成するには、次の項目を入力して［Next］をクリックします。
• Host Name : ホストのDNS名またはIPアドレスです。
• Username : 通常は root です。
• Password : 上のユーザー名に対するパスワードです(XenServerまたはKVM側で指定したもの)。
• Host Tags. (Optional) Any labels that you use to categorize hosts for ease of maintenance. For
example, you can set to the cloud's HA tag (set in the ha.tag global configuration parameter)
if you want this host to be used only for VMs with the "high availability" feature enabled.
For more information, see HA-Enabled Virtual Machines as well as HA for Hosts, both in the
Administration Guide.
10. 新しいクラスターでは、CloudStack
により最初のプライマリストレージサーバーが自動的に追加されま
す。後でさらにサーバーを追加できます。プライマリストレージの概要については、�� を参照して
ください。
最初のプライマリストレージサーバーを構成するには、次の項目を入力して［Next］をクリックします。
• Name : ストレージデバイスの名前です。
• Protocol : XenServer の場合は、[NFS]、[iSCSI]、または[PreSetup]を選択します。KVM の場合は、
[NFS]、[SharedMountPoint]、[CLVM]または[RBD]を選択します。vSphere の場合は、[VMFS](iSCSI
またはファイバーチャネル)または [NFS]を選択します。画面のそのほかのフィールドは、ここで選択したも
のにより異なります。
NFS
• Server : ストレージデバイスの IP アドレスまた
は DNS 名です。
• Path : サーバーからエクスポートされたパス
です。
• Tags(オプション) : このストレージデバイス用
のタグをコンマで区切って指定します。ディスク
オファリングのタグと同等、またはそのスーパー
セットである必要があります。
プライマリストレージのタグセットは、ゾーン内のク
ラスター間で同一である必要があります。たとえ
ば、クラスターA でプライマリストレージのタグが
T1 および T2 の場合は、同じゾーン内のほかの
すべてのクラスターでもプライマリストレージのタ
グを T1 および T2 にする必要があります。
54
拡張ゾーンの構成
iSCSI
• Server : ストレージデバイスの IP アドレスまた
は DNS 名です。
• Target IQN : ターゲット
の IQN です。たとえば、
「iqn.1986-03.com.sun:02:01ec9bb549-1271378984
とします。
• LUN : LUN 番号です。たとえば、「3」としま
す。
• Tags(オプション) : このストレージデバイス用
のタグをコンマで区切って指定します。ディスク
オファリングのタグと同等、またはそのスーパー
セットである必要があります。
プライマリストレージのタグセットは、ゾーン内のク
ラスター間で同一である必要があります。たとえ
ば、クラスターA でプライマリストレージのタグが
T1 および T2 の場合は、同じゾーン内のほかの
すべてのクラスターでもプライマリストレージのタ
グを T1 および T2 にする必要があります。
事前セットアップ
• Server : ストレージデバイスの IP アドレスまた
は DNS 名です。
• SR Name-Label : CloudStack の外部に
セットアップしたストレージリポジトリの名前ラ
ベルを入力します。
• Tags(オプション) : このストレージデバイス用
のタグをコンマで区切って指定します。ディスク
オファリングのタグと同等、またはそのスーパー
セットである必要があります。
プライマリストレージのタグセットは、ゾーン内のク
ラスター間で同一である必要があります。たとえ
ば、クラスターA でプライマリストレージのタグが
T1 および T2 の場合は、同じゾーン内のほかの
すべてのクラスターでもプライマリストレージのタ
グを T1 および T2 にする必要があります。
共有マウントポイント
• Path. The path on each host that is where
this primary storage is mounted. For
example, "/mnt/primary".
• Tags(オプション) : このストレージデバイス用
のタグをコンマで区切って指定します。ディスク
オファリングのタグと同等、またはそのスーパー
セットである必要があります。
プライマリストレージのタグセットは、ゾーン内のク
ラスター間で同一である必要があります。たとえ
ば、クラスターA でプライマリストレージのタグが
55
第5章 Steps to Provisioning Your Cloud Infrastructure
T1 および T2 の場合は、同じゾーン内のほかの
すべてのクラスターでもプライマリストレージのタ
グを T1 および T2 にする必要があります。
VMFS
• Server : vCenter サーバーの IP アドレスまた
は DNS 名です。
• Path. A combination of the datacenter
name and the datastore name. The
format is "/" datacenter name "/"
datastore name. For example, "/
cloud.dc.VM/cluster1datastore".
• Tags(オプション) : このストレージデバイス用
のタグをコンマで区切って指定します。ディスク
オファリングのタグと同等、またはそのスーパー
セットである必要があります。
プライマリストレージのタグセットは、ゾーン内のク
ラスター間で同一である必要があります。たとえ
ば、クラスターA でプライマリストレージのタグが
T1 および T2 の場合は、同じゾーン内のほかの
すべてのクラスターでもプライマリストレージのタ
グを T1 および T2 にする必要があります。
11. 新しいゾーンでは、CloudStack により最初のセカンダリストレージサーバーが自動的に追加されます。セ
カンダリストレージの概要については、�� を参照してください。
この画面に入力する前に、NFS 共有をセットアップして最新の CloudStack システム仮想マシンテンプ
レートをインストールし、セカンダリストレージを準備する必要があります。「セカンダリストレージの追加」を
参照してください。
• NFS Server. The IP address of the server or fully qualified domain name of the server.
• Path : サーバーからエクスポートされたパスです。
12. [Launch] をクリックします。
5.4. ポッドの追加
新しいゾーンを作成すると、CloudStack により最初のポッドが自動的に追加されます。このセクションの手順
に従って、ポッドをいつでも追加できます。
1. CloudStack ユーザーインターフェイスにログインします。�UI�� を参照してください。
2. 左側のナビゲーションバーで[Infrastructure]をクリックします。[Zones]で[View More]をクリックし、ポッド
を追加するゾーンを選択します。
3. [Compute and Storage]タブをクリックします。ダイアグラムの[Pods]ノードの[View All]をクリックします。
4. [Add Pod]をクリックします。
5. ダイアログボックスに次の詳細情報を入力します。
• Name: ポッドの名前です。
56
クラスタの追加
• Gateway: このポッド内のホストのゲートウェイです。
• Netmask. The network prefix that defines the pod's subnet. Use CIDR notation.
• Start Reserved System IPおよびEnd Reserved System IP: セカンダリストレージ仮想マシン、コンソー
ルプロキシ仮想マシン、およびDHCPなどのさまざまなシステム仮想マシンを管理するため
に、CloudStack で使用する管理ネットワーク内のIPアドレスの範囲です。詳しくは、「システムにより予
約済みのIPアドレス」を参照してください。
6. [OK]をクリックします。
5.5. クラスタの追加
CloudStack に管理対象のホストを認識させる必要があります。ホストはクラスター内にあるため、ホストをクラ
ウドに追加するには少なくとも 1 つのクラスターを追加する必要があります。
5.5.1. クラスターの追加:KVM または XenServer
次の手順は、ハイパーバイザーをホストにインストール済みで CloudStack ユーザーインターフェイスにログイ
ン済みであることを前提としています。
1. 左側のナビゲーションバーで[Infrastructure]をクリックします。[Zones]で[View More]をクリックし、クラス
ターを追加するゾーンを選択します。
2. [Compute] タブをクリックします。
3. ダイアグラムの[Clusters]ノードの[View All]をクリックします。
4. [Add Cluster]をクリックします。
5. このクラスターのハイパーバイザーの種類を選択します。
6. クラスターを作成するポッドを選択します。
7. クラスターの名前を入力します。任意の、CloudStack で使用されていないテキストを指定します。
8. [OK]をクリックします。
5.5.2. クラスターの追加:vSphere
vSphere のホスト管理は、vCenter および CloudStack の管理者ユーザーインターフェイスを組み合わせて行
います。CloudStack では、すべてのホストが CloudStack クラスターにあることが必要ですが、クラスターを単
一のホストで構成することもできます。管理者はクラスターに 1 台のホストを使用するか、複数のホストを使用
するかを決定する必要があります。複数ホストのクラスターでは、ライブマイグレーションのような機能を使用で
きます。クラスターには、NFS または iSCSI のような共有ストレージも必要です。
vSphere サーバーの場合は、vCenter でホストのクラスターを作成した後、クラスター全体を CloudStack に
追加することをお勧めします。次の要件に従ってください。
• vSphere クラスターに配置するホストは 8 台までにしてください。
• ハイパーバイザーホストに実行中の仮想マシンがないことを確認してから、CloudStack
い。
に追加してくださ
57
第5章 Steps to Provisioning Your Cloud Infrastructure
vSphere クラスターを CloudStack に追加するには
1. vCenter でホストのクラスターを作成します。vCenter の指示に従って、これを実行します。クラスターを作
成すると、 vCenter には次のように表示されます。
2. ユーザーインターフェイスにログインします。
3. 左側のナビゲーションバーで[Infrastructure]をクリックします。[Zones]で[View More]をクリックし、クラス
ターを追加するゾーンを選択します。
4. [Compute]タブをクリックし、[Pods]の[View
す。
All]をクリックします。クラスターを追加するポッドを選択しま
5. [View Clusters]をクリックします。
6. [Add Cluster]をクリックします。
7. [Hypervisor]ボックスの一覧で、[VMware]を選択します。
8. ダイアログボックスに次の情報を入力します。次のフィールドによって、vCenter 側の値を参照できるように
なります。
• Cluster Name. Enter the name of the cluster you created in vCenter. For example,
"cloud.cluster.2.2.1"
• vCenter Host: vCenter サーバーのホスト名または IP アドレスを入力します。
58
ホストの追加
• vCenter Username: CloudStack が vCenter への接続に使用するユーザー名を入力します。このユー
ザーにはすべての管理特権が必要です。
• vCenter Password: 上記のユーザー名に対するパスワードを入力します。
• vCenter Datacenter. Enter the vCenter datacenter that the cluster is in. For example,
"cloud.dc.VM".
•
クラスターがプロビジョニングされる間、多少の遅延が発生する場合があります。ユーザーインターフェイ
スにクラスターが自動的に表示されます。
5.6. ホストの追加
1. CloudStack 構成としてホストを追加する前に選択したハイパーバイザーをホストにインストールする必要
があります。CloudStack ホストを様々なハイパーバイザー下で動作する仮想マシンとともに管理すること
ができます。
CloudStack インストールガイドではそれぞれのサポートされるハイパーバイザーを CloudStack からどの
ように利用するかインストール方法や設定方法を提供しています。どのバージョンのハイパーバイザーがサ
ポートされているか「インストールガイドの」適切なセクションを参照することは CloudStack でハイパーバ
イザーホストを構成するための重要なステップになります。
警告
それぞれのハイパーバイザーに対して「ハイパーバイザーのインストール」で述べられる
CloudStack 特有の構成手順を確認してください。
59
第5章 Steps to Provisioning Your Cloud Infrastructure
2. CloudStack に対しホストを追加します。関連する技術情報は利用するハイパーバイザーによって異なりま
す。
• ��(XenServer �� KVM)�
• �� (vSphere)�
5.6.1. ホストの追加(XenServer または KVM)
XenServer および KVM のホストは、いつでもクラスターに追加できます。
5.6.1.1. XenServer および KVM ホストの要件
警告
�ハイパーバイザーホストに実行中の仮想マ
に追加してください。
シンがないことを確認してから、CloudStack
構成要件
• 各クラスターには同一のハイパーバイザーを使用するホストのみを含める必要があります。
• XenServer の場合は、クラスターに配置するホストは 8 台までにしてください。
• KVM の場合は、クラスターに配置するホストは 16 台までにしてください。
ハードウェア要件については、CloudStack インストールガイドのハイパーバイザー毎のインストールセクション
を参照してください。
5.6.1.1.1. XenServer ホストの追加要件
ネットワークボンディングを使用する場合は、管理者はホストの配線を、クラスター内のほかのホストと完全に同
じにする必要があります。
クラスターに追加するすべてのホストに対して次のコマンドを実行します。これで、ホストが XenServer プール
のマスターに加わります。
# xe pool-join master-address=[master IP] master-username=root master-password=[your password]
注記
�コマンドをコピーして実行するときは、単一の行として貼り付けたことを確認してください。
一部のドキュメントビューアーでは、コピーしたテキストに不要な改行が含まれる可能性があ
ります。
XenServer プールにすべてのホストを追加したら、cloud-setup-bond スクリプトを実行します。このスクリプト
により、クラスター内の新しいホストのボンドの構成とセットアップを完了します。
1. /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/cloud-setup-bonding.sh スクリ
プトを管理サーバーからマスターホストにコピーし、スクリプトが実行可能であることを確認します。
60
ホストの追加(XenServer または KVM)
2. 次のスクリプトを実行します。
# ./cloud-setup-bonding.sh
5.6.1.1.2. KVM ホストの追加要件
• 共有マウントポイントストレージを使用する場合は、管理者は新しいホストのすべてのマウントポイントを(マウ
ントされたストレージも含めて)、クラスター内のほかのホストと完全に同じにする必要があります。
• 新しいホストのネットワーク構成(ゲスト、プライベート、およびパブリックネットワーク)が、クラスター内のほか
のホストと同じであることを確認してください。
• OpenVswitch のブリッジを利用している場合は CloudStack にホストを追加するまえに KVM ホストの
agent.properties を編集し network.bridge.type パラメーターを openvswitch に設定してください。
5.6.1.2. XenServer または KVM ホストの追加
• ホストにハイパーバイザーソフトウェアをまだインストールしていない場合はインストールします。CloudStack
がサポートするハイパーバイザーソフトウェアのバージョン、およびホストを CloudStack と連動させるため
に必要な追加構成を確認しておく必要があります。このインストールの詳細については、CloudStack インス
トールガイドからハイパーバイザー毎の適切なセクションを参照してください。
• CloudStackユーザーインターフェイスに管理者としてログオンします。
• 左側のナビゲーションバーで[Infrastructure]をクリックします。[Zones]で[View More]をクリックし、ホストを
追加するゾーンを選択します。
• [Compute]タブをクリックします。[Clusters]ノードの[View All]をクリックします。
• ホストを追加するクラスターを選択します。
• [View Hosts]をクリックします。
• [Add Host]をクリックします。
• 次の情報を指定します。
• Host Name: ホストの DNS 名または IP アドレスです。
• Username: 通常は root です。
• Password: XenServer または KVM 側で指定した、上のユーザー名に対するパスワードです。
• Host Tags (Optional). Any labels that you use to categorize hosts for ease of maintenance. For
example, you can set to the cloud's HA tag (set in the ha.tag global configuration parameter)
if you want this host to be used only for VMs with the "high availability" feature enabled. For
more information, see HA-Enabled Virtual Machines as well as HA for Hosts.
ホストがプロビジョニングされる間、多少の遅延が発生する場合があります。ユーザーインターフェイスにホス
トが自動的に表示されます。
• 追加のホストについて、この手順を繰り返します。
61
第5章 Steps to Provisioning Your Cloud Infrastructure
5.6.2. ホストの追加 (vSphere)
vSphereサーバーに対してはvCenterでクラスターを作成し、クラスター全体をCloudStack に対し追加するこ
とを推奨します。詳しくはクラスターの追加(vSphere)を参照してください。
5.7. プライマリストレージの追加
5.7.1. プライマリストレージのシステム要件
ハードウェア要件:
• 基になるハイパーバイザーでサポートされている標準準拠の任意の iSCSI または NFS サーバー。
• ストレージサーバーは、多数のディスクを備えたコンピューターである必要があります。ディスクは、ハードウェ
ア RAID コントローラーで管理するのが理想的です。
• 最小限必要な容量はニーズにより異なります。
プライマリストレージをセットアップするときには次の制限に従ってください。
• プライマリストレージは、ホストをクラスターに追加しなくては追加できません。
• 共有プライマリストレージを準備しない場合は、グローバル構成パラメーターの
system.vm.local.storage.required を true に設定する必要があります。設定しないと仮想マシンを起動で
きません。
5.7.2. プライマリストレージの追加
新しいゾーンを作成するとき、手順の一部として最初のプライマリスト
レージが追加されます。プライマリスト
レージサーバーは、新しいクラスターを追加するときや既存のクラスターにサーバーを追加するときなど、いつで
も追加できます。
警告
サーバーに何も格納されていないことを確認してください。CloudStack にサーバーを追加
すると、既存のデータはすべて破棄されます。
1. CloudStack ユーザーインターフェイスにログインします(�UI�� を参照)。
2. 左側のナビゲーションバーで [Infrastructure] をクリックします。[Zones] で [View More] をクリックし、プ
ライマリストレージを追加するゾーンを選択します。
3. [Compute] タブをクリックします。
4. ダイアグラムの [Primary Storage] ノードの [View All] をクリックします。
5. [Add Primary Storage] をクリックします。
6. ダイアログボックスに次の情報を入力します。必要な情報は、選択するプロトコルによって異なります。
• Pod: ストレージデバイスのポッドです。
• Cluster: ストレージデバイスのクラスターです。
62
セカンダリストレージの追加
• Name : ストレージデバイスの名前です。
• Protocol: XenServer の場合は、[NFS]、[iSCSI]、または[PreSetup]を選択します。KVM の場合は、
[NFS]または[SharedMountPoint]を選択します。vSphere の場合は、[VMFS](iSCSI またはファイバー
チャネル)または [NFS]を選択します。
• Server(NFS、iSCSI、または PreSetup の場合): ストレージデバイスの IP アドレスまたは DNS 名です。
• Server(VMFS の場合): vCenter サーバーの IP アドレスまたは DNS 名です。
• Path(NFS の場合): NFS の場合、これはサーバーからエクスポートされたパスです。
• Path (for VMFS). In vSphere this is a combination of the datacenter name and the datastore
name. The format is "/" datacenter name "/" datastore name. For example, "/cloud.dc.VM/
cluster1datastore".
• Path (for SharedMountPoint). With KVM this is the path on each host that is where this
primary storage is mounted. For example, "/mnt/primary".
• SR Name-Label(PreSetup の場合): CloudStack の外部にセットアップしたストレージリポジトリの名
前ラベルを入力します。
• Target
IQN(iSCSI
の場合):
iSCSI
の場合、ターゲットの
「iqn.1986-03.com.sun:02:01ec9bb549-1271378984」とします。
IQN
です。たとえば、
• Lun 番号(iSCSI の場合): iSCSI の場合、LUN 番号です。たとえば、「3」とします。
• Tags(オプション): このストレージデバイス用のタグをコンマで区切って指定します。ディスクオファリング
のタグ\nと同等、またはそのスーパーセットである必要があります。
プライマリストレージのタグセットは、ゾーン内のクラスター間で同一である必要があります。たとえば、クラ
スターA でプライマリストレージのタグが T1 および T2 の場合は、同じゾーン内のほかのすべてのクラス
ターでもプライマリストレージのタグを T1 および T2 にする必要があります。
7. [OK]をクリックします。
5.8. セカンダリストレージの追加
5.8.1. セカンダリストレージのシステム要件
• NFS ストレージアプライアンスまたは Linux NFS サーバー
• (オプション)OpenStack Object Storage(Swift) (http://swift.openstack.org を参照してください)
• 最小容量として 100GB
• セカンダリストレージデバイスは、そのストレージを使用するゲスト仮想マシンと同じゾーンに配置する必要
があります。
• 各セカンダリストレージサーバーは、ゾーン内のすべてのホストで使用できる必要があります。
63
第5章 Steps to Provisioning Your Cloud Infrastructure
5.8.2. セカンダリストレージの追加
新しいゾーンを作成するとき、手順の一部として最初のセカンダリストレージが追加されます。いつでもセカン
ダリストレージサーバーを追加して、既存のゾーンにサーバーを追加することができます。
警告
サーバーに何も格納されていないことを確認してください。CloudStack にサーバーを追加
すると、既存のデータはすべて破棄されます。
1. クラウド全体のセカンダリストレージとして Swift を使用する場合は、ゾーンに対してローカルなセカンダリ
ストレージサーバーを追加する前に、CloudStack に Swift ストレージを追加する必要があります。「ゾーン
の追加」を参照してください。
2. ゾーンに対してローカルなセカンダリストレージの準備のため、管理サーバーのインストール中に NFS 共
有を作成しマウントしておく必要があります。 �NFS�� を参照してください。
3. 管理サーバーのインストール中にシステム仮想マシンテンプレートを準備したことを確認します。See ��
��. を参照してください。
4. これでゾーン単位のストレージとしてセカンダリストレージサーバーの準備ができたので、CloudStack に
追加します。新しいゾーンの追加手順の一部として、セカンダリストレージが追加されます。�� を参照
してください。
5.9. 初期化とテスト
After everything is configured, CloudStack will perform its initialization. This can take 30 minutes or
more, depending on the speed of your network. When the initialization has completed successfully,
the administrator's Dashboard should be displayed in the CloudStack UI.
1. Verify that the system is ready. In the left navigation bar, select Templates. Click on the CentOS
5.5 (64bit) no Gui (KVM) template. Check to be sure that the status is "Download Complete."
Do not proceed to the next step until this status is displayed.
2. [Instances]タブで、[Filter By]ボックスの一覧で[My Instances]を選択します。
3. [Add Instance]をクリックして、ウィザードの指示に従います。
a. 追加したばかりのゾーンを選択します。
b. 仮想マシンで使用するテンプレートを選択します。これが新規インストールの場合は、おそらく組み込
みの CentOS テンプレートのみを使用できます。
c. サービスオファリングを選択します。使用するハードウェアで、選択したサービスオファリングを開始でき
ることを確認してください。
d. 必要に応じて、データディスクオファリングにもう 1 つデータディスクを追加します。これはゲストが使用
できる 2 番目のボリュームですが、マウントはされません。たとえば、XenServer 上の Linux では、仮
想マシンの再起動後にゲストで/dev/xvdb が認識されます。PV が有効なオペレーティングシステム
カーネルの場合は再起動が不要です。
e. デフォルトネットワークで、ゲストのプライマリネットワークを選択します。基本インストールでは、このオ
プションは 1 つしかありません。
64
初期化とテスト
f.
オプションで、仮想マシンに名前を付けてグループを割り当てます。仮想マシンを説明するお好みのテ
キストを使用します。
g. [Launch VM]をクリックします。仮想マシンが作成され起動します。テンプレートをダウンロードして仮
想マシンの起動が完了するまで、長時間がかかるかもしれません。仮想マシンの進行状況は
[Instances]画面で監視できます。
4.
仮想マシンを使用するには[View Console]をクリックします。
VMへの着信ネットワークトラフィックの許可、VMの開始、停止、削除、VMを別のホストに移動させる方法
など、VMの使用に関する情報を更に得るには、管理者ガイド内の仮想マシンの操作を参照すること。
これで、CloudStack のインストールが完了しました。
展開を拡張する場合は、さらにホスト、プライマリストレージ、ゾーン、ポッド、およびクラスターを追加できます。
65
66
Global Configuration Parameters
6.1. グローバル構成パラメーターの設定
CloudStack
には、クラウドのさまざまな側面を制御するために設定できるパラメーターが備わっていま
す。CloudStack を初めてインストールするとき、そしてその後で定期的に、これらの設定を変更する必要が出て
くる可能性があります。
1. ユーザーインターフェイスに管理者としてログインします。
2. 左側のナビゲーションバーで[Global Settings]をクリックします。
3. [Select view]ボックスの一覧で次のどちらかを選択します。
• Global Settings: パラメーターが、簡単な説明と現在の値と共に一覧表示されます。
• Hypervisor Capabilities: ハイパーバイザーのバージョンが、それぞれにサポートされるゲスト数の上
限と共に一覧表示されます。
4. 検索ボックスを使用して、関心のある項目のみが表示されるように一覧内容を絞り込みます。
5. 値を変更するには[Edit]アイコンをクリックします。ハイパーバイザーの機能を表示する場合は、編集画面を
開くためにまずハイパーバイザー名をクリックする必要があります。
6.2. About Global Configuration Parameters
CloudStack provides a variety of settings you can use to set limits, configure features, and enable or
disable features in the cloud. Once your Management Server is running, you might need to set some
of these global configuration parameters, depending on what optional features you are setting up.
To modify global configuration parameters, use the steps in "Setting Global Configuration
Parameters."
The documentation for each CloudStack feature should direct you to the names of the applicable
parameters. Many of them are discussed in the CloudStack Administration Guide. The following
table shows a few of the more useful parameters.
Field
値
management.network.cidr
A CIDR that describes the
network that the management
CIDRs reside on. This variable
must be set for deployments
that use vSphere. It is
recommended to be set for
other deployments as well.
Example: 192.168.3.0/24.
xen.setup.multipath
For XenServer nodes, this
is a true/false variable that
instructs CloudStack to
enable iSCSI multipath on
the XenServer Hosts when
they are added. This defaults
67
第6章 Global Configuration Parameters
Field
値
to false. Set it to true if you
would like CloudStack to
enable multipath.
If this is true for a NFS-based
deployment multipath will still
be enabled on the XenServer
host. However, this does not
impact NFS operation and is
harmless.
secstorage.allowed.internal.sites
This is used to protect
your internal network from
rogue attempts to download
arbitrary files using the
template download feature.
This is a comma-separated
list of CIDRs. If a requested
URL matches any of these
CIDRs the Secondary Storage
VM will use the private
network interface to fetch
the URL. Other URLs will go
through the public interface.
We suggest you set this to
1 or 2 hardened internal
machines where you keep
your templates. For example,
set it to 192.168.1.66/32.
use.local.storage
Determines whether
CloudStack will use storage
that is local to the Host
for data disks, templates,
and snapshots. By default
CloudStack will not use this
storage. You should change
this to true if you want to
use local storage and you
understand the reliability
and feature drawbacks to
choosing local storage.
host
This is the IP address of
the Management Server.
If you are using multiple
Management Servers you
should enter a load balanced
IP address that is reachable
via the private network.
default.page.size
Maximum number of items
per page that can be
68
About Global Configuration Parameters
Field
値
returned by a CloudStack
API command. The limit
applies at the cloud level
and can vary from cloud
to cloud. You can override
this with a lower value on a
particular API call by using
the page and pagesize API
command parameters. For
more information, see the
Developer's Guide. Default:
500.
ha.tag
The label you want to use
throughout the cloud to
designate certain hosts as
dedicated HA hosts. These
hosts will be used only for
HA-enabled VMs that are
restarting due to the failure
of another host. For example,
you could set this to ha_host.
Specify the ha.tag value as a
host tag when you add a new
host to the cloud.
69
70
Hypervisor Installation
7.1. KVM のインストールと構成
7.1.1. KVM ホストのシステム要件
KVM は、さまざまな Linux ベースのオペレーティングシステムに含まれています。以下のディストリビューション
は必須ではありませんが推奨となります。
• CentOS / RHEL: 6.3
• Ubuntu: 12.04(.1)
KVM ハイパーバイザーにおける主要な要件は libvirt と Qemu のバージョンになります。どの Linux ディストリ
ビューションを利用するかに関わらず\n以下の要件を満たしているか確認する必要があります。
• libvirt: 0.9.4以降
• Qemu/KVM: 1.0以降
CloudStack でのデフォルトのブリッジは Linux ネイティブのブリッジ実装(ブリッジモジュール) になりま
す。CloudStack はオプションとして OpenVswitch を動作させる仕組みを内包しており以下のような要件があ
ります。
• libvirt: 0.9.11以上のバージョン
• openvswitch: 1.7.1以上のバージョン
加えて以下のハードウェア要件が必要となります。
• 1つのクラスター内のホストではバージョンを統一する。
• 1つのクラスター内のホストは種類が同じである必要があります。つまり、CPUの種類と数が同じで、同じ機
能フラグである必要があります。
• HVM (Intel-VT or AMD-V が有効である) 必要があります。
• 64-bit x86 CPU(多くのコアを用意することでパフォーマンスの向上が見込まれます)。
• 4GBのメモリ。
• 最少1つ以上のNIC。
• CloudStack が展開された際、ハイパーバイザーホストに既に動作しているVMが存在していない。
7.1.2. KVM インストールの概要s
If you want to use the Linux Kernel Virtual Machine (KVM) hypervisor to run guest virtual machines,
install KVM on the host(s) in your cloud. The material in this section doesn't duplicate KVM
installation docs. It provides the CloudStack-specific steps that are needed to prepare a KVM host
to work with CloudStack.
71
第7章 Hypervisor Installation
警告
作業を続ける前に、ホストに対して最新のアップデートが適用されていることを確認してくだ
さい。
警告
CloudStack の制御下にないホスト上でサービスを動作させることは推奨されません。
KVM ハイパーバイザーをインストールする手順は次のとおりです。
1. オペレーティングシステムの準備
2. libvirt のインストールと設定
3. セキュリティポリシーの設定 (AppArmor と SELinux)
4. エージェントのインストールと設定
7.1.3. オペレーティングシステムの準備
ホストのOSは CloudStack エージェントと KVM インスタンスが動作するよう準備される必要があります。
1. オペレーティングシステムにルートユーザーとしてログオンします。
2. 完全修飾ホスト名を確認します。
$ hostname --fqdn
This should return a fully qualified hostname such as "kvm1.lab.example.org". If it does not,
edit /etc/hosts so that it does.
3. 管理サーバーからインターネットに接続できることを確認します。
$ ping www.cloudstack.org
4. 時刻を同期するために NTP を有効にします。
注記
クラウドのサーバーのクロックを同期するために NTP が必要です。時刻同期がされない
と予期しない問題が発生する可能性があります。
a. NTP のインストール
$ yum install ntp
$ apt-get install openntpd
72
エージェントのインストールと設定
5. これらの手順を全てのハイパーバイザーホストで実行します。
7.1.4. エージェントのインストールと設定
CloudStack ホスト上で KVM インスタンスを管理するにはエージェントを利用する必要があります。エージェン
トは管理サーバーと通信しホスト上の全てのインスタンスを制御します。
まず、エージェントをインストールします。
RHELもしくはCentOSの場合:
$ yum install cloudstack-agent
Ubuntuの場合:
$ apt-get install cloudstack-agent
これでホストをクラスターに追加する準備ができました。詳細に関しては後の項で説明されますのでこちら ��
�� を参照してください。ホストを追加する前に上記ドキュメントを参照することを推奨します。
7.1.5. libvirt の構成とインストール
CloudStack uses libvirt for managing virtual machines. Therefore it is vital that libvirt is configured
correctly. Libvirt is a dependency of cloudstack-agent and should already be installed.
1. libvirt を用いてライブマイグレーションを実施するにはセキュアでない TCP コネクションを開放する必要が
あります。また、libvirt がマルチキャストの DNS アドバタイズを試行しないよう無効化する必要があります。
これらの設定方法は /etc/libvirt/libvirtd.conf にて編集してください。
以下のパラメーターを設定してください。
listen_tls = 0
listen_tcp = 1
tcp_port = "16509"
auth_tcp = "none"
mdns_adv = 0
2. Turning on "listen_tcp" in libvirtd.conf is not enough, we have to change the parameters as well:
RHEL や CentOS を利用している場合は /etc/sysconfig/libvirtd を編集してください。
次の行のコメントを外してください。
#LIBVIRTD_ARGS="--listen"
Ubuntu を利用している場合は /etc/init/libvirt-bin.conf を編集してください。
以下の行を変更してください(ファイルの行末):
73
第7章 Hypervisor Installation
exec /usr/sbin/libvirtd -d
-l オプションをつける場合
exec /usr/sbin/libvirtd -d -l
3. libvirt を再起動します。
RHELもしくはCentOSの場合:
$ service libvirtd restart
Ubuntuの場合:
$ service libvirt-bin restart
7.1.6. Configure the Security Policies
CloudStack does various things which can be blocked by security mechanisms like AppArmor and
SELinux. These have to be disabled to ensure the Agent has all the required permissions.
1. Configure SELinux (RHEL and CentOS)
a. Check to see whether SELinux is installed on your machine. If not, you can skip this section.
In RHEL or CentOS, SELinux is installed and enabled by default. You can verify this with:
$ rpm -qa | grep selinux
b. Set the SELINUX variable in /etc/selinux/config to "permissive". This ensures that the
permissive setting will be maintained after a system reboot.
RHELもしくはCentOSの場合:
vi /etc/selinux/config
Change the following line
SELINUX=enforcing
to this
SELINUX=permissive
c. SELinuxをpermissiveにすると即座に適用され、システムの再起動は必要ありません。
$ setenforce permissive
2. Configure Apparmor (Ubuntu)
74
Configure the network bridges
a. Check to see whether AppArmor is installed on your machine. If not, you can skip this
section.
In Ubuntu AppArmor is installed and enabled by default. You can verify this with:
$ dpkg --list 'apparmor'
b. Disable the AppArmor profiles for libvirt
$ ln -s /etc/apparmor.d/usr.sbin.libvirtd /etc/apparmor.d/disable/
$ ln -s /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper /etc/apparmor.d/disable/
$ apparmor_parser -R /etc/apparmor.d/usr.sbin.libvirtd
$ apparmor_parser -R /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper
7.1.7. Configure the network bridges
警告
This is a very important section, please make sure you read this thoroughly.
注記
This section details how to configure bridges using the native implementation in
Linux. Please refer to the next section if you intend to use OpenVswitch
In order to forward traffic to your instances you will need at least two bridges: public and private.
By default these bridges are called cloudbr0 and cloudbr1, but you do have to make sure they are
available on each hypervisor.
The most important factor is that you keep the configuration consistent on all your hypervisors.
7.1.7.1. Network example
There are many ways to configure your network. In the Basic networking mode you should have
two (V)LAN's, one for your private network and one for the public network.
We assume that the hypervisor has one NIC (eth0) with three tagged VLAN's:
1. VLAN 100 for management of the hypervisor
2. VLAN 200 for public network of the instances (cloudbr0)
3. VLAN 300 for private network of the instances (cloudbr1)
75
第7章 Hypervisor Installation
On VLAN 100 we give the Hypervisor the IP-Address 192.168.42.11/24 with the gateway
192.168.42.1
注記
The Hypervisor and Management server don't have to be in the same subnet!
7.1.7.2. Configuring the network bridges
It depends on the distribution you are using how to configure these, below you'll find examples for
RHEL/CentOS and Ubuntu.
注記
The goal is to have two bridges called 'cloudbr0' and 'cloudbr1' after this section.
This should be used as a guideline only. The exact configuration will depend on
your network layout.
7.1.7.2.1. Configure in RHEL or CentOS
The required packages were installed when libvirt was installed, we can proceed to configuring
the network.
First we configure eth0
vi /etc/sysconfig/network-scripts/ifcfg-eth0
Make sure it looks similar to:
DEVICE=eth0
HWADDR=00:04:xx:xx:xx:xx
ONBOOT=yes
HOTPLUG=no
BOOTPROTO=none
TYPE=Ethernet
We now have to configure the three VLAN interfaces:
vi /etc/sysconfig/network-scripts/ifcfg-eth0.100
DEVICE=eth0.100
HWADDR=00:04:xx:xx:xx:xx
ONBOOT=yes
HOTPLUG=no
BOOTPROTO=none
TYPE=Ethernet
VLAN=yes
IPADDR=192.168.42.11
GATEWAY=192.168.42.1
NETMASK=255.255.255.0
vi /etc/sysconfig/network-scripts/ifcfg-eth0.200
76
Configure the network bridges
DEVICE=eth0.200
HWADDR=00:04:xx:xx:xx:xx
ONBOOT=yes
HOTPLUG=no
BOOTPROTO=none
TYPE=Ethernet
VLAN=yes
BRIDGE=cloudbr0
vi /etc/sysconfig/network-scripts/ifcfg-eth0.300
DEVICE=eth0.300
HWADDR=00:04:xx:xx:xx:xx
ONBOOT=yes
HOTPLUG=no
BOOTPROTO=none
TYPE=Ethernet
VLAN=yes
BRIDGE=cloudbr1
Now we have the VLAN interfaces configured we can add the bridges on top of them.
vi /etc/sysconfig/network-scripts/ifcfg-cloudbr0
Now we just configure it is a plain bridge without an IP-Address
DEVICE=cloudbr0
TYPE=Bridge
ONBOOT=yes
BOOTPROTO=none
IPV6INIT=no
IPV6_AUTOCONF=no
DELAY=5
STP=yes
We do the same for cloudbr1
vi /etc/sysconfig/network-scripts/ifcfg-cloudbr1
DEVICE=cloudbr1
TYPE=Bridge
ONBOOT=yes
BOOTPROTO=none
IPV6INIT=no
IPV6_AUTOCONF=no
DELAY=5
STP=yes
With this configuration you should be able to restart the network, although a reboot is
recommended to see if everything works properly.
警告
Make sure you have an alternative way like IPMI or ILO to reach the machine in
case you made a configuration error and the network stops functioning!
77
第7章 Hypervisor Installation
7.1.7.2.2. Configure in Ubuntu
All the required packages were installed when you installed libvirt, so we only have to configure
the network.
vi /etc/network/interfaces
Modify the interfaces file to look like this:
auto lo
iface lo inet loopback
# The primary network interface
auto eth0.100
iface eth0.100 inet static
address 192.168.42.11
netmask 255.255.255.240
gateway 192.168.42.1
dns-nameservers 8.8.8.8 8.8.4.4
dns-domain lab.example.org
# Public network
auto cloudbr0
iface cloudbr0 inet manual
bridge_ports eth0.200
bridge_fd 5
bridge_stp off
bridge_maxwait 1
# Private network
auto cloudbr1
iface cloudbr1 inet manual
bridge_ports eth0.300
bridge_fd 5
bridge_stp off
bridge_maxwait 1
With this configuration you should be able to restart the network, although a reboot is
recommended to see if everything works properly.
警告
Make sure you have an alternative way like IPMI or ILO to reach the machine in
case you made a configuration error and the network stops functioning!
7.1.8. Configure the network using OpenVswitch
警告
This is a very important section, please make sure you read this thoroughly.
In order to forward traffic to your instances you will need at least two bridges: public and private.
By default these bridges are called cloudbr0 and cloudbr1, but you do have to make sure they are
available on each hypervisor.
78
Configure the network using OpenVswitch
The most important factor is that you keep the configuration consistent on all your hypervisors.
7.1.8.1. Preparing
To make sure that the native bridge module will not interfere with openvswitch the bridge module
should be added to the blacklist. See the modprobe documentation for your distribution on where
to find the blacklist. Make sure the module is not loaded either by rebooting or executing rmmod
bridge before executing next steps.
The network configurations below depend on the ifup-ovs and ifdown-ovs scripts which are part of
the openvswitch installation. They should be installed in /etc/sysconfig/network-scripts/
7.1.8.2. Network example
There are many ways to configure your network. In the Basic networking mode you should have
two (V)LAN's, one for your private network and one for the public network.
We assume that the hypervisor has one NIC (eth0) with three tagged VLAN's:
1. VLAN 100 for management of the hypervisor
2. VLAN 200 for public network of the instances (cloudbr0)
3. VLAN 300 for private network of the instances (cloudbr1)
On VLAN 100 we give the Hypervisor the IP-Address 192.168.42.11/24 with the gateway
192.168.42.1
注記
The Hypervisor and Management server don't have to be in the same subnet!
7.1.8.3. Configuring the network bridges
It depends on the distribution you are using how to configure these, below you'll find examples
for RHEL/CentOS.
注記
The goal is to have three bridges called 'mgmt0', 'cloudbr0' and 'cloudbr1' after
this section. This should be used as a guideline only. The exact configuration will
depend on your network layout.
7.1.8.3.1. Configure OpenVswitch
The network interfaces using OpenVswitch are created using the ovs-vsctl command. This
command will configure the interfaces and persist them to the OpenVswitch database.
First we create a main bridge connected to the eth0 interface. Next we create three fake bridges,
each connected to a specific vlan tag.
79
第7章 Hypervisor Installation
#
#
#
#
#
#
ovs-vsctl
ovs-vsctl
ovs-vsctl
ovs-vsctl
ovs-vsctl
ovs-vsctl
add-br cloudbr
add-port cloudbr eth0
set port cloudbr trunks=100,200,300
add-br mgmt0 cloudbr 100
add-br cloudbr0 cloudbr 200
add-br cloudbr1 cloudbr 300
7.1.8.3.2. Configure in RHEL or CentOS
The required packages were installed when openvswitch and libvirt were installed, we can proceed
to configuring the network.
First we configure eth0
vi /etc/sysconfig/network-scripts/ifcfg-eth0
Make sure it looks similar to:
DEVICE=eth0
HWADDR=00:04:xx:xx:xx:xx
ONBOOT=yes
HOTPLUG=no
BOOTPROTO=none
TYPE=Ethernet
We have to configure the base bridge with the trunk.
vi /etc/sysconfig/network-scripts/ifcfg-cloudbr
DEVICE=cloudbr
ONBOOT=yes
HOTPLUG=no
BOOTPROTO=none
DEVICETYPE=ovs
TYPE=OVSBridge
We now have to configure the three VLAN bridges:
vi /etc/sysconfig/network-scripts/ifcfg-mgmt0
DEVICE=mgmt0
ONBOOT=yes
HOTPLUG=no
BOOTPROTO=static
DEVICETYPE=ovs
TYPE=OVSBridge
IPADDR=192.168.42.11
GATEWAY=192.168.42.1
NETMASK=255.255.255.0
vi /etc/sysconfig/network-scripts/ifcfg-cloudbr0
DEVICE=cloudbr0
ONBOOT=yes
80
Configuring the firewall
HOTPLUG=no
BOOTPROTO=none
DEVICETYPE=ovs
TYPE=OVSBridge
vi /etc/sysconfig/network-scripts/ifcfg-cloudbr1
DEVICE=cloudbr1
ONBOOT=yes
HOTPLUG=no
BOOTPROTO=none
TYPE=OVSBridge
DEVICETYPE=ovs
With this configuration you should be able to restart the network, although a reboot is
recommended to see if everything works properly.
警告
Make sure you have an alternative way like IPMI or ILO to reach the machine in
case you made a configuration error and the network stops functioning!
7.1.9. Configuring the firewall
The hypervisor needs to be able to communicate with other hypervisors and the management
server needs to be able to reach the hypervisor.
In order to do so we have to open the following TCP ports (if you are using a firewall):
1. 22 (SSH)
2. 1798
3. 16509 (libvirt)
4. 5900 - 6100 (VNC consoles)
5. 49152 - 49216 (libvirt live migration)
It depends on the firewall you are using how to open these ports. Below you'll find examples how
to open these ports in RHEL/CentOS and Ubuntu.
7.1.9.1. Open ports in RHEL/CentOS
RHEL and CentOS use iptables for firewalling the system, you can open extra ports by executing
the following iptable commands:
$ iptables -I INPUT -p tcp -m tcp --dport 22 -j ACCEPT
$ iptables -I INPUT -p tcp -m tcp --dport 1798 -j ACCEPT
$ iptables -I INPUT -p tcp -m tcp --dport 16509 -j ACCEPT
81
第7章 Hypervisor Installation
$ iptables -I INPUT -p tcp -m tcp --dport 5900:6100 -j ACCEPT
$ iptables -I INPUT -p tcp -m tcp --dport 49152:49216 -j ACCEPT
These iptable settings are not persistent accross reboots, we have to save them first.
$ iptables-save > /etc/sysconfig/iptables
7.1.9.2. Open ports in Ubuntu
The default firewall under Ubuntu is UFW (Uncomplicated FireWall), which is a Python wrapper
around iptables.
To open the required ports, execute the following commands:
$ ufw allow proto tcp from any to any port 22
$ ufw allow proto tcp from any to any port 1798
$ ufw allow proto tcp from any to any port 16509
$ ufw allow proto tcp from any to any port 5900:6100
$ ufw allow proto tcp from any to any port 49152:49216
注記
By default UFW is not enabled on Ubuntu. Executing these commands with the
firewall disabled does not enable the firewall.
7.1.10. CloudStack へのホスト追加
これでホストをクラスターに追加する準備ができました。詳細に関しては後の項で説明されますのでこちら ��
�� を参照してください。ホストを追加する前に上記ドキュメントを参照することを推奨します。
7.2. CloudStackのためのCitrix XenServerのインストール
Citrix XenServer ハイパーバイザーを使用してゲスト仮想マシンを実行する場合は、XenServer 6.0 もしくは
XenServer 6.0.2 をクラウド内のホストにインストールします。初回インストールの場合は、次の手順に従って
ください。XenServer をインストール済みで、別のバージョンにアップグレードする場合は、�XenServer ��
�� を参照してください。
7.2.1. XenServerホストのシステム要件
• ホストは次に示す互換性のいづれかを認定されている必要があります。
『Citrix Hardware Compatibility Guide』を参照してください。
• XenServer 5.6 SP2
82
http://hcl.xensource.com
の
XenServerのインストール手順
• XenServer 6.0
• XenServer 6.0.2
• 前にインストールしたホストを再使用する場合は、Citrix XenServer を再インストールする必要があります。
• ハードウェア仮想マシン(Intel-VTまたはAMD-Vが有効であること)をサポートする必要があります。
• ハイパーバイザーの製造元が提供するすべての Hotfix を適用したことを確認します。ハイパーバイザーの製
造元のサポートチャネルを通じてパッチのリリース状況を確認し、パッチがリリースされたらできるだけ早く適
用します。ハイパーバイザーの必須パッチについて CloudStack が自動的に通知することはありません。ホス
トにハイパーバイザーの最新パッチを適用することは非常に重要です。最新パッチが適用されていないシス
テムは、おそらくハイパーバイザーの製造元からサポートを受けられません。
• クラスター内にあるホストは全て同スペックでなければいけません。CPU の種類や数、機能フラグが同じでな
ければいけません。
• ハードウェア仮想マシン(Intel-VTまたはAMD-VがBIOSで有効であること)をサポートする必要があります。
• 64-bit x86 CPU(多くのコアを用意することでパフォーマンスの向上が見込まれます)
• 完全仮想化のサポートが必要。
• 4GBのメモリ
• 36 GBのローカルディスク
• 最少1つ以上のNIC
• 静的IPアドレス
• CloudStack が展開された際、ハイパーバイザーホストに既に動作しているVMが存在していない。
警告
最新の Hotfix を適用しないと、データの破損や仮想マシンの喪失が生じる可能性がありま
す。
7.2.2. XenServerのインストール手順
1. Citrix
社の
Web
サイト(https://www.citrix.com/English/ss/downloads/)から
あなたの
CloudStack のバージョンに合った XenServer をダウンロードし、『Citrix XenServer インストールガイド』
に従ってインストールします。
2. インストール後、次の手順に従い設定を行います。
必須
オプション
�XenServer ��0��
�CloudStack XenServer Support
Pakcage(CSP)��
��
iSCSIやローカルディスク、NFSを利用しない場合
SRをセットアップします。詳細は�XenServer ��
��を参照してください。
83
第7章 Hypervisor Installation
必須
オプション
��
�XenServer � iSCSI ��(��)�
��
�XenServer ��
7.2.3. XenServer ドメイン0のメモリ設定
XenServer
の
dom0
へのメモリ割り当てを増やすために、dom0
の設定を構成します。これによ
り、XenServer でより多くの仮想マシンを制御できるようになります。XenServer の dom0 に 2940MB
の
RAM
を割り当てることをお勧めします。この方法について詳しくは、http://support.citrix.com/article/
CTX126531 を参照してください。このアーティクルで言及されているのは XenServer 5.6 ですが、同じことが
XenServer 6.0 にも当てはまります。
7.2.4. ユーザー名とパスワード
クラスター内のすべての XenServer に、CloudStack に構成されたものと同じユーザー名およびパスワードが
必要です。
7.2.5. 時刻同期
ホストはNTPを使用する必要があります。ポッド内のすべてのホストは時刻が同期される必要があります。
1. NTPのインストール
# yum install ntp
2. 使用する NTP サーバーを参照するように、NTP 構成ファイルを編集します。
# vi /etc/ntp.conf
使用する NTP サーバーを参照するように、NTP 構成ファイルを編集します。例として Citrix が提供する次
の NTP サーバーを使用できます。
server
server
server
server
0.xenserver.pool.ntp.org
1.xenserver.pool.ntp.org
2.xenserver.pool.ntp.org
3.xenserver.pool.ntp.org
3. NTPクライアントの再起動
# service ntpd restart
4. 再起動時に NTP が再び開始されることを確認します。
# chkconfig ntpd on
7.2.6. ライセンス設定
無償版の Citrix XenServer は、ライセンスなしで 30 日間使用できます。30 日の試用期間を過ぎる
と、無償のライセンス認証が要求されます。ここでライセンスをインストールするか、この手順を省略するかを選
84
CloudStack XenServer Support Pakcage(CSP)のインストール
択できます。この手順を省略する場合は、XenServer をアクティブ化してライセンスを有効にするときに、ライセ
ンスをインストールする必要があります。
7.2.6.1. ライセンスの取得と展開
ここでライセンスをインストールする場合は、XenCenter を使用して、ライセンスをアクティブ化して取得する必
要があります。
1. In XenCenter, click Tools > License manager.
2. XenServer を選択し、[無償の XenServer のアクティブ化]を選択します。
3. ライセンスを要求します。
XenCenter または xe コマンドラインツールを使用して、ライセンスをインストールできます。
7.2.7. CloudStack XenServer Support Pakcage(CSP)のインストール
(オプション)
XenServer
でセキュリティグループ、エラスティック負荷分散、およびエラスティック
IP
を有効にするに
は、CloudStack XenServer Support Package(CSP)をダウンロードしてインストールします。XenServer をイ
ンストールしたら、各 XenServer ホストで次の追加手順を実行します。
1. 次のリンクのどちらかから XenServer ホストに CSP ソフトウェアをダウンロードします。
XenServer 6.0.2 の場合:
http://download.cloud.com/releases/3.0.1/XS-6.0.2/xenserver-cloud-supp.tgz
XenServer 5.6 SP2 の場合:
http://download.cloud.com/releases/2.2.0/xenserver-cloud-supp.tgz
XenServer 6.0 の場合:
http://download.cloud.com/releases/3.0/xenserver-cloud-supp.tgz
2. ファイルの展開:
# tar xf xenserver-cloud-supp.tgz
3. 以下スクリプトの実行:
# xe-install-supplemental-pack xenserver-cloud-supp.iso
4. XenServer ホストが基本ネットワーク設定を使用するゾーンの一部である場合は、Open vSwitch(OVS)
を無効にします。
# xe-switch-network-backend
bridge
再起動を促すメッセージが表示されたら、再起動を受け入れます。
これで、XenServer ホストを CloudStack に追加する準備ができました。
85
第7章 Hypervisor Installation
7.2.8. XenServer 用のプライマリストレージのセットアップ
CloudStack natively supports NFS, iSCSI and local storage. If you are using one of these storage
types, there is no need to create the XenServer Storage Repository ("SR").
ただし、ファイバーチャネルなどのほかの技術を介して接続されたストレージを使用する場合は、ストレージリポ
ジトリを自分でセットアップする必要があります。これを行うには、次の手順に従います。XenServer プールにホ
ストがある場合は、マスターノードで手順を実行します。クラスター化されていない単一の XenServer を使用す
る場合は、その XenServer で手順を実行します。
1. ファイバーチャネルケーブルをクラスター内のすべてのホストとファイバーチャネルストレージホストに接続
します。
2. SCSI バスを再スキャンします。次のコマンドまたは XenCenter を使用して、HBA 再スキャンを実行します。
# scsi-rescan
3. 2 の手順を各ホスト上で繰り返します。
4. 新しいSCSIディスクを確認します。
# ls /dev/disk/by-id/scsi-360a98000503365344e6f6177615a516b -l
The output should look like this, although the specific file name will be different (scsi-<scsiID>):
lrwxrwxrwx 1 root root 9 Mar 16 13:47
/dev/disk/by-id/scsi-360a98000503365344e6f6177615a516b -> ../../sdc
5. 4 の手順を各ホスト上で繰り返します。
6. ストレージサーバーで次のコマンドを実行し、新しいストレージリポジトリの固有の ID を取得します。
# uuidgen
出力は次のようになりますが、具体的な ID は異なります。
e6849e96-86c3-4f2c-8fcc-350cc711be3d
7. ファイバーチャネルのストレージリポジトリを作成します。名前ラベルには、生成した固有の ID を使用しま
す。
# xe sr-create type=lvmohba shared=true
device-config:SCSIid=360a98000503365344e6f6177615a516b
name-label="e6849e96-86c3-4f2c-8fcc-350cc711be3d"
このコマンドは、次の例のようにストレージリポジトリの固有の ID を戻します(実際の ID は異なります)。
7a143820-e893-6c6a-236e-472da6ee66bf
86
XenServer の iSCSI マルチパスのセットアップ(オプション)
8. ストレージリポジトリについて人間が読める説明を作成するには、次のコマンドを使用します。UUID には、
前のコマンドで戻されたストレージリポジトリ ID を使用します。名前の説明には、好みに合わせてわかりや
すいテキストを設定します。
# xe sr-param-set uuid=7a143820-e893-6c6a-236e-472da6ee66bf name-description="Fiber Channel storage
repository"
このストレージを後で CloudStack に追加するときに必要な値を控えておきます( ��を参照)。
[プライマリストレージの追加]ダイアログボックスの[プロトコル]ボックスの一覧で、[事前セットアップ]を選
択します。[ストレージレポジトリ名前ラベル]ボックスには、前に設定した名前ラベルを入力します(この例で
は、 e6849e96-86c3-4f2c-8fcc-350cc711be3d)。
9. (オプション)ファイバーチャネル SAN でマルチパス I/O を有効にする場合は、SAN の製造元が提供するド
キュメントを参照してください。
7.2.9. XenServer の iSCSI マルチパスのセットアップ(オプション)
Citrix XenServer でストレージリポジトリをセットアップするとき、マルチパス I/O を有効にできます。マルチパ
ス I/O を使用すると、冗長な物理コンポーネントを使用してサーバーと SAN の接続の信頼性を高めることがで
きます。マルチパスを有効にするには、Citrix サーバーでサポートされる SAN ソリューションを使用し、Citrix ド
キュメントに記載されている手順に従います。基本情報については、次のリンクを参照してください。
• http://support.citrix.com/article/CTX118791
• http://support.citrix.com/article/CTX125403
マルチパスを使用した Citrix リポジトリのセットアップについて、SAN の製造元に助言を求めることもできます。
このストレージを後で CloudStack に追加するときに必要な値を控えておきます( ��を参照)。[プライ
マリストレージの追加]ダイアログボックスの[プロトコル]ボックスの一覧で、[事前セットアップ]を選択します。[ス
トレージレポジトリ名前ラベル]ボックスには、ストレージリポジトリの作成に使用した名前と同じものを入力しま
す。
問題が発生した場合は、SAN の製造元のサポート部門に問い合わせてください。問題が解決できない場合は、
「サポートへの問い合わせ」を参照してください。
7.2.10. XenServer の物理ネットワーク設定
XenServer をインストールした後で、追加のネットワーク構成が必要な場合があります。この時点で、ホストの
NIC の種類と各 NIC が伝送するトラフィックについて、計画済みである必要があります。NIC は、計画に合わせ
て配線する必要があります。
NIC ボンディングを使用する場合は、クラスター内のすべてのホスト上の NIC を完全に同じ配線にする必要が
あります。例えば、eth0 がクラスター内のあるホスト上のプライベートボンドにある場合、eth0 はクラスター内
のすべてのホストでプライベートボンドに存在する必要があります。
管理ネットワークインターフェイス用に割り当てる IP アドレスは、静的である必要があります。この IP アドレスは
ホスト自体で設定したり、静的 DHCP 経由で取得したりできます。
CloudStack では、XenServer ホストでさまざまな NIC またはボンドを使用できるように、各種のネットワーク
トラフィックが構成されます。XenServer のネットワーク名ラベルを使用して、このプロセスを制御し、管理サー
バーに情報を提供できます。 CloudStack で名前ラベルを物理インターフェイスまたはボンドに付けて構成しま
す。簡単な構成の場合は、名前ラベルは必要ありません。
87
第7章 Hypervisor Installation
7.2.10.1. XenServer の専用 NIC を使用したパブリックネットワークの構成(オプ
ション)
CloudStack supports the use of a second NIC (or bonded pair of NICs, described in �XenServer �
NIC ��(��)�) for the public network. If bonding is not used, the public network can be on any
NIC and can be on different NICs on the hosts in a cluster. For example, the public network can be
on eth0 on node A and eth1 on node B. However, the XenServer name-label for the public network
must be identical across all hosts. The following examples set the network label to "cloud-public".
After the management server is installed and running you must configure it with the name of the
chosen network label (e.g. "cloud-public"); this is discussed in ��.
ボンドした 2 つの NIC を使用してパブリックネットワークを作成する場合は、�XenServer � NIC ��(��)�を
参照してください。
単一の専用 NIC を使用してパブリックネットワークアクセスを提供する場合は、この手順に従って CloudStack
に追加する各新規ホストを設定してから、ホストを追加します。
1. Run xe network-list and find the public network. This is usually attached to the NIC that is
public. Once you find the network make note of its UUID. Call this <UUID-Public>.
2. 次のコマンドを実行します。
# xe network-param-set name-label=cloud-public uuid=<UUID-Public>
7.2.10.2. XenServer の複数のゲストネットワークの構成(オプション)
CloudStack supports the use of multiple guest networks with the XenServer hypervisor. Each
network is assigned a name-label in XenServer. For example, you might have two networks with the
labels "cloud-guest" and "cloud-guest2". After the management server is installed and running, you
must add the networks and use these labels so that CloudStack is aware of the networks.
この手順に従って各新規ホストを設定してから、CloudStack にホストを追加します。
1. Run xe network-list and find one of the guest networks. Once you find the network make note
of its UUID. Call this <UUID-Guest>.
2. 次のコマンドを実行します。名前ラベルと UUID は実際の値で置き換えます。
# xe network-param-set name-label=<cloud-guestN> uuid=<UUID-Guest>
3. 追加する各ゲストネットワークに対して毎回異なる名前ラベルと UUID を使用して、この手順を繰り返しま
す。
7.2.10.3. XenServer 用の個別のストレージネットワーク(オプション)
You can optionally set up a separate storage network. This should be done first on the host, before
implementing the bonding steps below. This can be done using one or two available NICs. With
two NICs bonding may be done as above. It is the administrator's responsibility to set up a separate
storage network.
ストレージネットワークに、ほかのネットワークとは異なる名前ラベルを指定します。
For the separate storage network to work correctly, it must be the only interface that can ping the
primary storage device's IP address. For example, if eth0 is the management network NIC, ping -
88
XenServer の物理ネットワーク設定
I eth0 <primary storage device IP> must fail. In all deployments, secondary storage devices must
be pingable from the management network NIC or bond. If a secondary storage device has been
placed on the storage network, it must also be pingable via the storage network NIC or bond on
the hosts as well.
個別のストレージネットワークを 2 つセットアップすることもできます。たとえば、iSCSI マルチパスを実装する場
合は、ボンドしていない 2 つの NIC をマルチパス専用にします。2 つのネットワークのどちらにも、一意の名前ラ
ベルが必要です。
ボンドしない場合は、管理者はすべてのホスト(マスターとスレーブ)上に個別のストレージネットワークをセット
アップし、名前ラベルを割り当てる必要があります。
次に、172.16.0.0/24 上のストレージネットワークにアクセスするように、eth5 をセットアップする例を示しま
す。
# xe pif-list host-name-label='hostname' device=eth5
uuid(RO): ab0d3dd4-5744-8fae-9693-a022c7a3471d
device ( RO): eth5
#xe pif-reconfigure-ip DNS=172.16.3.3 gateway=172.16.0.1 IP=172.16.0.55 mode=static netmask=255.255.255.0
uuid=ab0d3dd4-5744-8fae-9693-a022c7a3471d
7.2.10.4. XenServer の NIC ボンディング(オプション)
XenServer では、SLB(Source Level Balancing)NIC ボンディングがサポートされます。パブリック、プライベー
ト、およびゲストのトラフィック、またはこれらを組み合わせたトラフィックを伝送するために 2 つの NIC をボン
ドできます。個別のストレージネットワークも同じようにできます。次に、サポートされる構成例をいくつか挙げま
す。
• プライベートに NIC を 2 つ、パブリックに NIC を 2 つ、ストレージに NIC を 2 つ
• プライベートに NIC を 2 つ、パブリックに NIC を 1 つ、ストレージは管理ネットワークの NIC を使用
• プライベートに NIC を 2 つ、パブリックに NIC を 2 つ、ストレージは管理ネットワークの NIC を使用
• プライベート、パブリック、およびストレージに NIC を 1 つ
NIC ボンディングはすべてオプションです。
XenServer では、クラスター内のすべてのノードに同じネットワーク配線と同じボンドが実装されることを想定し
ます。マスターになるのは、展開時に最初にクラスターに追加したホストです。それ以降にクラスターに追加する
ホストはすべてスレーブホストです。マスターにボンドが存在するということは、後でクラスターにホストが追加さ
れたことを想定させます。ボンドをセットアップする手順はマスターとスレーブで異なります。それぞれについて
次に説明します。これには次のような重要な意味合いがあります。
• ボンドは最初にクラスターに追加したホストで設定する必要があります。次に、後述する xe コマンドを使用し
て、クラスターに追加した 2 番目以降のホストで同じボンドを設定する必要があります。
• クラスター内のスレーブホストは、マスターと完全に同じに配線する必要があります。たとえば、eth0 がマス
ター上のプライベートボンドにある場合、追加するスレーブホストの管理ネットワークに eth0 が存在する必要
があります。
7.2.10.4.1. 管理ネットワークのボンディング
管理者は、CloudStack にホストを追加する前に、管理ネットワークの NIC をボンドする必要があります。
89
第7章 Hypervisor Installation
7.2.10.4.2. クラスターの最初のホストでのプライベートボンドの作成
次の手順に従って、XenServer でボンドを作成します。この手順は、クラスターの最初のホストのみで実行する
必要があります。この例では、2 つの物理 NIC(eth0 および eth1)をボンドした cloud-private ネットワークを
作成します。
1. ボンドする物理 NIC を検索します。
# xe pif-list host-name-label='hostname' device=eth0
# xe pif-list host-name-label='hostname' device=eth1
These command shows the eth0 and eth1 NICs and their UUIDs. Substitute the ethX devices of
your choice. Call the UUID's returned by the above command slave1-UUID and slave2-UUID.
2. Create a new network for the bond. For example, a new network with name "cloud-private".
このラベルは重要です。CloudStack は管理者が構成した名前を使用してネットワークを検索します。管理
ネット\nワークについてクラウド内のすべてのホストで同じ名前ラベルを使用する必要があります。
# xe network-create name-label=cloud-private
# xe bond-create network-uuid=[uuid of cloud-private created above]
pif-uuids=[slave1-uuid],[slave2-uuid]
これで、管理ネットワークとして CloudStack で認識できるボンドペアを用意できました。
7.2.10.4.3. パブリックネットワークのボンディング
ボンディングは、個別のパブリックネットワークで実装できます。パブリックネットワークでボンディングを使用し、
管理ネットワークから分離する場合は、管理者はパブリックネットワーク用のボンドを作成する必要があります。
7.2.10.4.4. クラスターの最初のホストでのパブリックボンドの作成
この手順は、クラスターの最初のホストのみで実行する必要があります。この例では、2 つの物理 NIC(eth2 お
よび eth3) をボンドした cloud-public ネットワークを作成します。
1. ボンドする物理 NIC を検索します。
#xe pif-list host-name-label='hostname' device=eth2
# xe pif-list host-name-label='hostname' device=eth3
These command shows the eth2 and eth3 NICs and their UUIDs. Substitute the ethX devices of
your choice. Call the UUID's returned by the above command slave1-UUID and slave2-UUID.
2. Create a new network for the bond. For example, a new network with name "cloud-public".
このラベルは重要です。CloudStack は管理者が構成した名前を使用してネットワークを検索します。パブ
リックネッ\nトワークについてクラウド内のすべてのホストで同じ名前ラベルを使用する必要があります。
# xe network-create name-label=cloud-public
# xe bond-create network-uuid=[uuid of cloud-public created above]
pif-uuids=[slave1-uuid],[slave2-uuid]
これで、パブリックネットワークとして CloudStack で認識できるボンドペアを用意できました。
90
XenServer バージョンのアップグレード
7.2.10.4.5. クラスターへのホストの追加
必要に応じてマスターにボンドを設定した場合は、スレーブホストを追加する必要があります。クラスターに追
加するすべてのホストで次のコマンドを実行します。これで、ホストが単一の XenServer プールのマスターに加
わります。
# xe pool-join master-address=[master IP] master-username=root
master-password=[your password]
7.2.10.4.6. クラスター全体でのボンドセットアップの完了
プールにすべてのホストを追加したら、cloud-setup-bond スクリプトを実行します。このスクリプトにより、クラ
スター内のすべてのホストのボンドの構成とセットアップを完了します。
1. /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/cloud-setup-bonding.sh スクリ
プトを管理サーバーからマスターホストにコピーし、スクリプトが実行可能であることを確認します。
2. 次のスクリプトを実行します。
# ./cloud-setup-bonding.sh
これで、ボンドがセットアップされ、クラスター全体で適切に構成されました。
7.2.11. XenServer バージョンのアップグレード
ここでは、CloudStack ホスト上の XenServer ソフトウェアをアップグレードする方法について説明します。実際
のアップグレードは XenServer のドキュメントで説明されていますが、アップグレードの前後に追加して実行す
る必要がある手順がいくつかあります。
注記
ハードウェアが新しいバージョンの XenServer との互換性を認定されていることを確認して
ください。
XenServer をアップグレードするには
1. データベースをアップグレードします。管理サーバーノードで次の手順を実行します。
a. データベースをバックアップします。
# mysqldump --user=root --databases cloud > cloud.backup.sql
# mysqldump --user=root --databases cloud_usage > cloud_usage.backup.sql
b. ここで、アップグレード対象のホスト上で動作している仮想マシンのOSタイプを変更する必要があるか
もしれません。
• もし、XenServer 5.6 GA から XenServer 5.6 SP2 、または仮想マシンのOSタイプをCentOS 5.5
(32-bit)、Oracle Enterprise Linux 5.5 (32-bit) もしくは Red Hat Enterprise Linux 5.5 (32bit) 、からその他のLinux (32-bit) にアップグレードする場合一度それらを同一のOSタイプからその
他のLinux (64-bit) に変換する必要があります。
• もし、XenServer 5.6 SP2 から XenServer 6.0.2 、または仮想マシンのOSタイプをCentOS 5.6
(32-bit)、CentOS 5.7 (32-bit)、Oracle Enterprise Linux 5.6 (32-bit)、Oracle Enterprise
91
第7章 Hypervisor Installation
Linux 5.7 (32-bit)、Red Hat Enterprise Linux 5.6 (32-bit) もしくは Red Hat Enterprise Linux
5.7 (32-bit) 、からその他のLinux (32-bit) にアップグレードする場合一度それらを同一のOSタイ
プからその他のLinux (64-bit) に変換する必要があります。
• もし、上記の通り XenServer を 5.6 から 6.0.2 にアップグレードした場合
c. 管理サーバーと使用状況サーバーを再起動します。これはクラスター毎に一度だけ実施します。
# service cloud-management start
# service cloudstack-usage start
2. CloudStack から XenServer クラスターの接続を外します。
a. root として CloudStack UI からログインします。
b. XenServer クラスターに移動し、[Actions]、[Unmanage]の順にクリックします。
c. クラスターの状態が[Unmanaged]になるまで監視します。
3. クラスター上のホストにログインし、VLAN をクリーンするコマンドを実行します。
# . /opt/xensource/bin/cloud-clean-vlan.sh
4. ホストへログインしたまま、アップグレードのためのスクリプトを実行します。
# /opt/xensource/bin/cloud-prepare-upgrade.sh
Troubleshooting: If you see the error "can't eject CD," log in to the VM and umount the CD,
then run the script again.
5. クラスター上の全てのホストの XenServer ソフトウェアをアップグレードし、最初のマスターとなるホストを
アップグレードしてください。
a. Live migrate all VMs on this host to other hosts. See the instructions for live migration in
the Administrator's Guide.
トラブルシューティング : 仮想マシンの移動時、以下のようなエラーメッセージを見るかもしれません。
[root@xenserver-qa-2-49-4 ~]# xe vm-migrate live=true host=xenserver-qa-2-49-5 vm=i-2-8-VM
You attempted an operation on a VM which requires PV drivers to be installed but the drivers were not
detected.
vm: b6cf79c8-02ee-050b-922f-49583d9f1a14 (i-2-8-VM)
この問題を解決するため、次を実行します。
# /opt/xensource/bin/make_migratable.sh
b6cf79c8-02ee-050b-922f-49583d9f1a14
b. ホストを再起動します。
c. XenServer のドキュメントを参考に XenServer を新しいバージョンにアップグレードします。
d. アップグレードの完了後、次に示される場所に示されるファイル群を管理サーバーからコピーします。
92
XenServer バージョンのアップグレード
管理サーバーの以下のファイルを
XenServer ホストにコピーします。
/usr/lib64/cloud/common/scripts/
vm/hypervisor/xenserver/xenserver60/
NFSSR.py
/opt/xensource/sm/NFSSR.py
/usr/lib64/cloud/common/scripts/vm/
hypervisor/xenserver/setupxenserver.sh
/opt/xensource/bin/setupxenserver.sh
/usr/lib64/cloud/common/scripts/vm/
hypervisor/xenserver/make_migratable.sh
/opt/xensource/bin/make_migratable.sh
/usr/lib64/cloud/common/scripts/vm/
hypervisor/xenserver/cloud-clean-vlan.sh
/opt/xensource/bin/cloud-clean-vlan.sh
e. 以下スクリプトの実行:
# /opt/xensource/bin/setupxenserver.sh
トラブルシューティング: 以下のエラーメッセージを確認した場合、安全にそれを無効化することができ
ます。
mv: cannot stat `/etc/cron.daily/logrotate': No such file or directory
f.
ストレージリポジトリ(物理ブロックデバイス)を XenServer ホストに接続します。
# for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug
uuid=$pbd ; done
注意: XenServer プールにホストを追加した際は全ての仮想マシンを別ホストに移行させ、このホスト
を XenServer プールから取り外す必要があります。
6. これらの手順をクラスター内の全てのホストを同じバージョンの XenServer にアップグレードするため実
施します。
7. XenServer クラスター内の 1 台のホストで次のコマンドを実行し、ホストタグをクリーンアップします。
# for host in $(xe host-list | grep ^uuid | awk '{print $NF}') ; do xe host-param-clear uuid=$host paramname=tags; done;
注記
コマンドをコピーして実行するときは、単一の行として貼り付けたことを確認してくださ
い。一部のドキュメントビューアーでは、コピーしたテキストに不要な改行が含まれる可
能性があります。
8. XenServer クラスターを CloudStack に再接続します。
a. root として CloudStack UI からログインします。
b. XenServer クラスターに移動し、[Actions]、[Manage]の順にクリックします。
c. 状態を監視し、すべてのホストが表示されるのを確認します。
93
第7章 Hypervisor Installation
9. すべてのホストが表示されたら、クラスター内の 1 台のホストで次のコマンドを実行します。
# /opt/xensource/bin/cloud-clean-vlan.sh
7.3. VMware vSphereのインストールと構成
VMware vSphere ハイパーバイザーを使用してゲスト仮想マシンを実行する場合は、クラウド内のホストに
vSphere をインストールします。
7.3.1. vSphere ホストのシステム要件
7.3.1.1. ソフトウェア要件
• Version 4.1 または 5.0 の vSphere および vCenter
vSphere Standard をお勧めします。ただし、vSphere ライセンスの CPU 制限を考慮する必要があることに
注意してください。http://www.vmware.com/files/jp/pdf/vsphere_pricing.pdf を参照し、VMware の販売担
当者と相談してください。
vCenter Server Standard をお勧めします。
• Be sure all the hotfixes provided by the hypervisor vendor are applied. Track the release of
hypervisor patches through your hypervisor vendor's support channel, and apply patches as soon
as possible after they are released. CloudStack will not track or notify you of required hypervisor
patches. It is essential that your hosts are completely up to date with the provided hypervisor
patches. The hypervisor vendor is likely to refuse to support any system that is not up to date
with patches.
全ての必要な Hotfix を適用します。
最新の Hotfix を適用しないと、データの破損や仮想マシンの喪失が生じる可能性がありま
す。
7.3.1.2. ハードウェア要件:
• ホストは vSphere との互換性を認定されている必要があります。 http://www.vmware.com/resources/
compatibility/search.php の『VMware Hardware Compatibility Guide』を参照してください。
• すべてのホストは64ビットマシンで、ハードウェア仮想マシン(Intel-VTまたはAMD-Vが有効であること)をサ
ポートする必要があります。
• 1つのクラスター内のホストは種類が同じである必要があります。つまり、CPUの種類と数が同じで、同じ機
能フラグである必要があります。
• 64-bit x86 CPU(多くのコアを用意することでパフォーマンスの向上が見込まれます)。
• 完全仮想化のサポートが必要。
• 4GBのメモリ。
• 36 GBのローカルディスク
94
vSphere ホストのシステム要件
• 最少1つ以上のNIC。
• 静的IPアドレス
7.3.1.3. vCenter Server の要件:
• プロセッサ: 2 つの CPU、2.0GHz 以上の Intel または AMD x86 プロセッサ。データベースを同じマシンで
実行する場合は、より高性能のプロセッサが必要です。
• メモリ: 3GB の RAM。データベースを同じマシンで実行する場合は、より多くの RAM が必要です。
• ディスクストレージ: 2GB。データベースを同じマシンで実行する場合は、より多くのストレージが必要です。
• Microsoft SQL Server 2005 Express のディスク要件。バンドルされているデータベースには、インストール
アーカイブを展開するための最大 2GB のディスク領域が必要です。
• ネットワークシステム: 1Gbit または 10Gbit。
For more information, see "vCenter Server and the vSphere Client Hardware Requirements" at http://
pubs.vmware.com/vsp40/wwhelp/wwhimpl/js/html/wwhelp.htm#href=install/c_vc_hw.html.
7.3.1.4. そのほかの要件:
• VMware vCenter Standard Edition 4.1 または 5.0 をインストールし、vSphere ホストの管理に使用する
必要があります。
• 標準ポート 443 を使用するように vCenter を構成し、CloudStack 管理サーバーと通信できるようにする必
要があります。
• 以前にインストールしたホストを再使用する場合は、VMware ESXi を再インストールする必要があります。
• CloudStack には VMware vSphere 4.1 または 5.0 が必要です。VMware vSphere 4.0 はサポートされ
ません。
• すべてのホストは64ビットマシンで、ハードウェア仮想マシン(Intel-VTまたはAMD-Vが有効であること)をサ
ポートする必要があります。1 つのクラスター内のホストは種類が同じである必要があります。つまり、CPU
の種類と数が同じで、同じ機能フラグである必要があります。
• CloudStack 管理ネットワークを別個の仮想ネットワークとして構成してはいけません。CloudStack 管理
ネットワークは、vCenter 管理ネットワークと同じであり、その構成を継承します。�vCenter �� を
参照してください。
• CloudStack には ESXi が必要です。ESX はサポートされません。
• CloudStack で使用するすべてのリソースは、CloudStack 専用にする必要があります。CloudStack で
は、ESXi のインスタンスまたはストレージをほかの管理コンソールと共有できません。CloudStack で使用す
るストレージボリュームを、CloudStack による管理対象外の別の ESXi サーバーセットと共有しないでくださ
い。
• クラスター内のすべての対象 ESXi ハイパーバイザーを、vCenter で別個のデータセンターに配置します。
• CloudStack で管理するクラスターに仮想マシンを含めないでください。CloudStack 専用のクラスターで、
管理サーバー、vCenter、およびそのほかの仮想マシンを実行しないでください。CloudStack で使用する別
個のクラスターを作成し、このクラスター内に仮想マシンがないことを確認してください。
95
第7章 Hypervisor Installation
• 必要なすべての VLAN は、すべての ESXi ハイパーバイザーホストにトランク接続する必要があります。こ
れには、管理、ストレージ、vMotion、およびゲスト VLAN のための VLAN が含まれます。ゲスト VLAN(拡
張ネットワーク設定で使用します。「ネットワークのセットアップ」を参照)は、CloudStack で管理する連続した
VLAN の範囲です。
7.3.2. VMware 向けチェックリストを用意します。
インストールをより円滑に進めるために以下の情報を収集します。
• �vCenter �� の情報を収集します。
• �VMware �� の情報を収集します。
7.3.2.1. vCenter チェックリスト
vCenter に関する以下の情報が必要になります。
vCenter 要件
値
注意
vCenter ユーザー
ユーザーには管理者権限が必要
となります。
vCenter ユーザーパスワード
上記ユーザーに対するパスワー
ド。
vCenter データセンター名
データセンターの名前
vCenter クラスター名
クラスターの名前
7.3.2.2. VMware ネットワークのチェックリスト
VLAN に関して以下の情報が必要になります。
VLAN 情報
値
注意
ESXi における VLAN
存在する全ての ESXi ハイパーバ
イザーの VLAN
ESXi の VLAN IP 範囲
ESXi VLAN 上の IP アドレスの範
囲。仮想ルーター毎のアドレスが
この範囲で利用されます。
ESXi の VLAN IP のゲートウェイ
ESXi の VLAN ネットマスク
管理サーバーの VLAN
インストールされている
CloudStack 管理サーバーの
VLAN 情報
パブリック VLAN
パブリックネットワークの VLAN
パブリック VLAN のゲートウェイ
パブリック VLAN のネットマスク
パブリックVLAN IPアドレスの範
囲
96
Range of Public IP Addresses
available for CloudStack
use. These addresses will
be used for virtual router on
vSphereのインストール手順
VLAN 情報
値
注意
CloudStack to route private
traffic to external networks.
顧客が使うVLANの範囲
A contiguous range of nonroutable VLANs. One VLAN
will be assigned for each
customer.
7.3.3. vSphereのインストール手順
1. If you haven't already, you'll need to download and purchase vSphere from the VMware
Website (https://www.vmware.com/tryvmware/index.php?p=vmware-vsphere&lp=1) and install it
by following the VMware vSphere Installation Guide.
2. Following installation, perform the following configuration, which are described in the next few
sections:
必須
オプション
ESXi ホストのSetup
ボンディングNIC
Configure host physical networking, virtual
switch, vCenter Management Network, and
extended port range
マルチパスストレージ
iSCSIのためのストレージを用意
Configure clusters in vCenter and add hosts
to them, or add hosts without clusters to
vCenter
7.3.4. ESXiホストセットアップ
All ESXi hosts should enable CPU hardware virtualization support in BIOS. Please note hardware
virtualization support is not enabled by default on most servers.
7.3.5. 物理ホストのネットワーク
You should have a plan for cabling the vSphere hosts. Proper network configuration is required
before adding a vSphere host to CloudStack. To configure an ESXi host, you can use vClient to add
it as standalone host to vCenter first. Once you see the host appearing in the vCenter inventory
tree, click the host node in the inventory tree, and navigate to the Configuration tab.
97
第7章 Hypervisor Installation
In the host configuration tab, click the "Hardware/Networking" link to bring up the networking
configuration page as above.
7.3.5.1. 仮想スイッチの設定
A default virtual switch vSwitch0 is created. CloudStack requires all ESXi hosts in the cloud to use
the same set of virtual switch names. If you change the default virtual switch name, you will need
to configure one or more CloudStack configuration variables as well.
7.3.5.1.1. トラフィックの分離
CloudStack allows you to use vCenter to configure three separate networks per ESXi host. These
networks are identified by the name of the vSwitch they are connected to. The allowed networks
for configuration are public (for traffic to/from the public internet), guest (for guest-guest traffic),
and private (for management and usually storage traffic). You can use the default virtual switch for
all three, or create one or two other vSwitches for those traffic types.
If you want to separate traffic in this way you should first create and configure vSwitches in vCenter
according to the vCenter instructions. Take note of the vSwitch names you have used for each
traffic type. You will configure CloudStack to use these vSwitches.
7.3.5.1.2. ポートの増加
By default a virtual switch on ESXi hosts is created with 56 ports. We recommend setting it to 4088,
the maximum number of ports allowed. To do that, click the "Properties..." link for virtual switch
(note this is not the Properties link for Networking).
98
物理ホストのネットワーク
In vSwitch properties dialog, select the vSwitch and click Edit. You should see the following dialog:
99
第7章 Hypervisor Installation
In this dialog, you can change the number of switch ports. After you've done that, ESXi hosts are
required to reboot in order for the setting to take effect.
7.3.5.2. vCenter マネージメントネットワークの設定
In the vSwitch properties dialog box, you may see a vCenter management network. This same
network will also be used as the CloudStack management network. CloudStack requires the
vCenter management network to be configured properly. Select the management network item in
the dialog, then click Edit.
100
物理ホストのネットワーク
下記の値が設定されたことを確認してください：
• VLAN ID set to the desired ID
• vMotion可能
• Management traffic enabled.
101
第7章 Hypervisor Installation
If the ESXi hosts have multiple VMKernel ports, and ESXi is not using the default value "Management
Network" as the management network name, you must follow these guidelines to configure the
management network port group so that CloudStack can find it:
• Use one label for the management network port across all ESXi hosts.
• In the CloudStack UI, go to Configuration - Global Settings and
vmware.management.portgroup to the management network label from the ESXi hosts.
set
7.3.5.3. Extend Port Range for CloudStack Console Proxy
(Applies only to VMware vSphere version 4.x)
You need to extend the range of firewall ports that the console proxy works with on the hosts. This
is to enable the console proxy to work with VMware-based VMs. The default additional port range
is 59000-60000. To extend the port range, log in to the VMware ESX service console on each host
and run the following commands:
esxcfg-firewall -o 59000-60000,tcp,in,vncextras
esxcfg-firewall -o 59000-60000,tcp,out,vncextras
7.3.5.4. vSphereのNICボンディングの設定
NIC bonding on vSphere hosts may be done according to the vSphere installation guide.
7.3.6. Storage Preparation for vSphere (iSCSI only)
Use of iSCSI requires preparatory work in vCenter. You must add an iSCSI target and create an
iSCSI datastore.
NFSを使う場合、この手順はスキップしてください。
7.3.6.1. Enable iSCSI initiator for ESXi hosts
1. In vCenter, go to hosts and Clusters/Configuration, and click Storage Adapters link. You will
see:
102
Storage Preparation for vSphere (iSCSI only)
2. Select iSCSI software adapter and click Properties.
103
第7章 Hypervisor Installation
3. Click the Configure... button.
104
Storage Preparation for vSphere (iSCSI only)
4. Check Enabled to enable the initiator.
5. 保存するために［OK］をクリックしてください。
7.3.6.2. iSCSI targetの追加
Under the properties dialog, add the iSCSI target info:
Repeat these steps for all ESXi hosts in the cluster.
105
第7章 Hypervisor Installation
7.3.6.3. iSCSIデータストアを作る
You should now create a VMFS datastore. Follow these steps to do so:
1. Select Home/Inventory/Datastores.
2. Right click on the datacenter node.
3. Choose Add Datastore... command.
4. Follow the wizard to create a iSCSI datastore.
This procedure should be done on one host in the cluster. It is not necessary to do this on all hosts.
7.3.6.4. Multipathing for vSphere (Optional)
Storage multipathing on vSphere nodes may be done according to the vSphere installation guide.
7.3.7. Add Hosts or Configure Clusters (vSphere)
Use vCenter to create a vCenter cluster and add your desired hosts to the cluster. You will later
add the entire cluster to CloudStack. (see ��:vSphere�).
7.3.8. Applying Hotfixes to a VMware vSphere Host
1. Disconnect the VMware vSphere cluster from CloudStack. It should remain disconnected long
enough to apply the hotfix on the host.
a. root として CloudStack UI からログインします。
See �UI��.
106
Applying Hotfixes to a VMware vSphere Host
b. Navigate to the VMware cluster, click Actions, and select Unmanage.
c. [Unmanaged] が表示されるまで状態を監視します。
2. Perform the following on each of the ESXi hosts in the cluster:
a. Move each of the ESXi hosts in the cluster to maintenance mode.
b. Ensure that all the VMs are migrated to other hosts in that cluster.
c. If there is only one host in that cluster, shutdown all the VMs and move the host into
maintenance mode.
d. Apply the patch on the ESXi host.
e. 表示されたら再起動します。
f.
ホストのメンテナンスモードをキャンセルします。
3. クラスタをCloudStack に再接続します。
a. root として CloudStack UI からログインします。
b. Navigate to the VMware cluster, click Actions, and select Manage.
c. Watch the status to see that all the hosts come up. It might take several minutes for the
hosts to come up.
Alternatively, verify the host state is properly synchronized and updated in the CloudStack
database.
107
108
Additional Installation Options
The next few sections describe CloudStack features above and beyond the basic deployment
options.
8.1. 使用状況測定サーバーのインストール(オプション)
管理サーバーを正しく構成したら、オプションで使用状況測定サーバーをインストールできます。使用状況測定
サーバーでシステム内のイベントからデータを取得して、使用状況に基づいてアカウントに課金することができ
ます。
複数の管理サーバーが存在する場合は、使用状況測定サーバーはそのいずれかにインストールできます。使
用状況測定サーバーによって使用状況データの処理が調整されます。可用性が懸念されるサイトでは、使用状
況測定サーバーを少なくとも 2 台の管理サーバーにインストールする必要があります。
8.1.1. 使用状況測定サーバーのインストール要件
• 使用状況測定サーバーをインストールするときには、管理サーバーが動作している必要があります。
• 使用状況測定サーバーは管理サーバーと同じサーバーにインストールする必要があります。
8.1.2. 使用状況測定サーバーのインストール手順
1. ./install.sh を実行します。
# ./install.sh
インストーラーの準備が進むにつれていくつかのメッセージが表示され、その後に選択項目の一覧が表示
されます。
2. Choose "S" to install the Usage Server.
> S
3. インストールが完了したら、次のコマンドを実行して使用状況測定サーバーを起動します。
# service cloudstack-usage start
使用状況測定サーバーの詳細な構成について詳しくは、『管理ガイド』を参照してください。
8.2. SSL (Optional)
CloudStack provides HTTP access in its default installation. There are a number of technologies
and sites which choose to implement SSL. As a result, we have left CloudStack to expose HTTP
under the assumption that a site will implement its typical practice.
CloudStack uses Tomcat as its servlet container. For sites that would like CloudStack to terminate
the SSL session, Tomcat’s SSL access may be enabled. Tomcat SSL configuration is described at
http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html.
109
第8章 Additional Installation Options
8.3. Database Replication (Optional)
CloudStack supports database replication from one MySQL node to another. This is achieved using
standard MySQL replication. You may want to do this as insurance against MySQL server or storage
loss. MySQL replication is implemented using a master/slave model. The master is the node that
the Management Servers are configured to use. The slave is a standby node that receives all write
operations from the master and applies them to a local, redundant copy of the database. The
following steps are a guide to implementing MySQL replication.
注記
Creating a replica is not a backup solution. You should develop a backup
procedure for the MySQL data that is distinct from replication.
1. Ensure that this is a fresh install with no data in the master.
2. Edit my.cnf on the master and add the following in the [mysqld] section below datadir.
log_bin=mysql-bin
server_id=1
The server_id must be unique with respect to other servers. The recommended way to achieve
this is to give the master an ID of 1 and each slave a sequential number greater than 1, so that
the servers are numbered 1, 2, 3, etc.
3. Restart the MySQL service:
# service mysqld restart
4. Create a replication account on the master and give it privileges. We will use the "cloudrepl" user with the password "password". This assumes that master and slave run on the
172.16.1.0/24 network.
# mysql -u root
mysql> create user 'cloud-repl'@'172.16.1.%' identified by 'password';
mysql> grant replication slave on *.* TO 'cloud-repl'@'172.16.1.%';
mysql> flush privileges;
mysql> flush tables with read lock;
5. Leave the current MySQL session running.
6. In a new shell start a second MySQL session.
7. Retrieve the current position of the database.
# mysql -u root
mysql> show master status;
+------------------+----------+--------------+------------------+
| File
| Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
110
Database Replication (Optional)
| mysql-bin.000001 |
412 |
|
|
+------------------+----------+--------------+------------------+
8. Note the file and the position that are returned by your instance.
9. Exit from this session.
10. Complete the master setup. Returning to your first session on the master, release the locks and
exit MySQL.
mysql> unlock tables;
11. Install and configure the slave. On the slave server, run the following commands.
# yum install mysql-server
# chkconfig mysqld on
12. Edit my.cnf and add the following lines in the [mysqld] section below datadir.
server_id=2
innodb_rollback_on_timeout=1
innodb_lock_wait_timeout=600
13. Restart MySQL.
# service mysqld restart
14. Instruct the slave to connect to and replicate from the master. Replace the IP address,
password, log file, and position with the values you have used in the previous steps.
mysql>
->
->
->
->
->
change master to
master_host='172.16.1.217',
master_user='cloud-repl',
master_password='password',
master_log_file='mysql-bin.000001',
master_log_pos=412;
15. Then start replication on the slave.
mysql> start slave;
16. Optionally, open port 3306 on the slave as was done on the master earlier.
This is not required for replication to work. But if you choose not to do this, you will need to
do it when failover to the replica occurs.
111
第8章 Additional Installation Options
8.3.1. Failover
This will provide for a replicated database that can be used to implement manual failover for the
Management Servers. CloudStack failover from one MySQL instance to another is performed by
the administrator. In the event of a database failure you should:
1. Stop the Management Servers (via service cloudstack-management stop).
2. Change the replica's configuration to be a master and restart it.
3. Ensure that the replica's port 3306 is open to the Management Servers.
4. Make a change so that the Management Server uses the new database. The simplest process
here is to put the IP address of the new database server into each Management Server's /etc/
cloud/management/db.properties.
5. Restart the Management Servers:
# service cloudstack-management start
112
展開アーキテクチャの選択
展開に使用するアーキテクチャは、展開の規模と目的によって異なります。ここでは、テストや試用展開に便利
な小規模の展開や、実稼働環境への展開に適した完全に冗長な大規模セットアップなど、展開アーキテクチャ
の例を示します。
9.1. 小規模な展開
この図は、CloudStack の小規模な展開のネットワークアーキテクチャを示しています。
• インターネットへの接続はファイアウォールを介して行われます。ファイアウォールは NAT モードで構成されま
す。ファイアウォールは、HTTP 要求および API 呼び出しをインターネットから管理サーバーに転送します。管
理サーバーは管理ネットワーク上に存在します。
• レイヤー2 スイッチが、すべての物理サーバーとストレージを接続します。
• 1 台の NFS サーバーが、プライマリストレージおよびセカンダリストレージの両方として機能します。
• 管理サーバーは管理ネットワークに接続されます。
113
第9章展開アーキテクチャの選択
9.2. 大規模な冗長セットアップ
この図は、CloudStack の大規模な展開のネットワークアーキテクチャを示しています。
• レイヤー3 スイッチレイヤーがデータセンターのコアにあります。VRRP のようなルーター冗長プロトコルを展
開する必要があります。通常は、ハイエンドコアスイッチにファイアウォールモジュールも含まれます。レイヤー3
スイッチにファイアウォール機能が統合されていない場合は、別のファイアウォールアプライアンスを使用する
こともできます。ファイアウォールは NAT モードで構成されます。ファイアウォールでは、次の機能が提供され
ます。
• HTTP 要求および API 呼び出しをインターネットから管理サーバーに転送します。管理サーバーは管理
ネットワーク上に存在します。
• クラウドに複数のゾーンが含まれる場合は、ファイアウォールでサイト間の VPN を許可して、異なるゾーン
のサーバーが相互に直接通信できるようにする必要があります。
• レイヤー2 アクセススイッチレイヤーをポッドごとに設定します。複数のスイッチをスタックして、ポート数を増や
すことができます。いずれの場合も、レイヤー2 スイッチの冗長ペアを展開する必要があります。
114
別個のストレージネットワーク
• 管理サーバークラスター(フロントエンド負荷分散装置、管理サーバーノード、MySQL データベースを含む)
は、負荷分散装置のペアを通して管理ネットワークに接続されます。
• セカンダリストレージサーバーは管理ネットワークに接続されます。
• 各ポッドには、ストレージサーバーとコンピューティングサーバーが含まれます。各ストレージサーバーおよび
コンピューティングサーバーには、異なるレイヤー2 アクセススイッチに接続する冗長な NIC が必要です。
9.3. 別個のストレージネットワーク
前のセクションで説明したような大規模な冗長セットアップでは、ストレージトラフィックによって管理ネットワー
クが過負荷状態になる可能性があります。このような展開では別個のストレージネットワークを使用できま
す。iSCSI のようなストレージプロトコルは、ネットワーク遅延によって大きな影響を受けます。ストレージネット
ワークを分離することにより、ゲストネットワークトラフィックの競合がストレージのパフォーマンスに影響を与え
ないようにすることができます。
9.4. 複数ノードの管理サーバー
CloudStack 管理サーバーは、単一の MySQL データベースに接続する 1 台以上のフロントエンドサーバーに
展開します。オプションで、ペアにしたハードウェア負荷分散装置によって Web からの要求を分散することがで
きます。リモートサイトに MySQL をレプリケートしてバックアップ管理サーバーのセットを展開し、障害回復機能
を追加できます。
管理者は次のことを決定する必要があります。
• 負荷分散装置を使用するかどうか
• 展開する管理サーバーの数
• MySQL をレプリケートして障害回復を有効にするかどうか
9.5. 複数サイトの展開
CloudStack は、ゾーンを使用することで複数のサイトに問題なく拡張できます。次の図は、複数サイトの展開
例を示しています。
115
第9章展開アーキテクチャの選択
データセンター1 には、プライマリ管理サーバーとゾーン 1 が含まれます。MySQL データベースは、データセン
ター2 のセカンダリ管理サーバーにリアルタイムでレプリケートされます。
116
複数サイトの展開
この図は、別個のストレージネットワークのセットアップを示しています。各サーバーには 4 つの NIC があり、2
つはポッドレベルのネットワークスイッチに接続され、2 つはストレージネットワークスイッチに接続されていま
す。
117
第9章展開アーキテクチャの選択
ストレージネットワークを構成するには、次の 2 つの方法があります。
• NFS の場合は、ボンドされた NIC と冗長なスイッチを展開できます。NFS 環境では、冗長なスイッチとボンド
された NIC により 1 つのネットワークを構成します(1 つの CIDR ブロックとデフォルトゲートウェイアドレス)。
• iSCSIの場合は、2つの独立したストレージネットワークを利用できます(2つのCIDRブロックとそれぞれに専
用のデフォルトゲートウェイ)。マルチパス iSCSI クライアントは、異なるストレージネットワークの間でフェール
オーバーと負荷分散を行うことができます。
この図は、NIC ボンディングとマルチパス I/O(MPIO)の違いを示しています。NIC ボンディングの構成に含まれ
るネットワークは 1 つだけです。MPIO には 2 つの異なるネットワークが含まれます。
118
アカウント
10.1. アカウント、ユーザー、およびドメイン
アカウント
アカウントは、通常、サービスプロバイダーの顧客や、大規模な組織の部門を表します。1 つのアカウントに複数
のユーザーを存在させることができます。
ドメイン
アカウントはドメインによってグループ化されます。ドメインには、通常、相互に何らかの論理的な関係がある複
数のアカウントと、ドメインおよびそのサブドメインに対して何らかの権限を持つ一連の委任管理者が含まれま
す。たとえば、複数の販売代理店を持つサービスプロバイダーでは、販売代理店ごとにドメインを作成すること
ができます。
各アカウントはクラウドのインストール時に3つの違う種類のユーザーアカウントとして作成されます: ルート管
理者、ドメイン管理者、ユーザー
ユーザー
ユーザーは、アカウント内のエイリアスのようなものです。同じアカウントのユーザーは互いに分離されません
が、ほかのアカウントのユーザーからは分離されます。ほとんどのインストールでは、1 つのアカウントで複数の
ユーザーを使用することはないため、ユーザーの概念が問題になることはありません。
ユーザー名はドメインをまたぐアカウント内で一意です。同じユーザー名はサブドメインを含め他のドメイン上で
存在することができます。ドメイン名はルートからのフルパス名が一意であれば繰り返す利用することができま
す。たとえば、root/foo/d1, root/sales/d1 と同様に root/d1 も利用することができます。
管理者はシステム上で特別な権限を持つアカウントです。システムには複数の管理者が存在することができま
す。管理者は他の管理者を作成、削除することができ、システム上のユーザーのパスワードを変更することがで
きます。
ドメイン管理者
ドメイン管理者はドメインに所属するユーザーに対しての管理権限を持つことができます。ドメイン管理者は物
理サーバーや他のドメインからは不可視です。
ルート管理者
ルート管理者はシステムに対してテンプレート操作、サービスオファリング、ユーザー管理、ドメインなど完全な
アクセス権限を持ちます。
アカウントが所有するリソースはアカウント内のユーザー独自のものではありません。たとえば、課金、リソース
制限などはアカウント単位で管理されユーザー単位ではありません。ユーザーはアカウントに割り当てられたあ
らゆるリソースを利用できその権限を持ちます。権限はその役割によって決定付けられます。
10.2. LDAP サーバーによるユーザー認証
Microsoft Active Directory や ApacheDS などの外部 LDAP サーバーを使用して CloudStack
のエンドユーザーを認証できます。クエリフィルターを使用して、CloudStack アカウントを対応する LDAP
119
第10章アカウント
アカウントにマップする以外に必要な作業はありません。クエリフィルターは使用する LDAP サーバーのクエ
リ構文で作成します。ユーザーの電子メールアドレスや名前などの共通の値を一致させる、CloudStack の特
別なワイルドカード文字を含めることができます。指定する基本ディレクトリから外部 LDAP ディレクトリツリー
が CloudStack によって検索され、一致するユーザーの識別名とパスワードが戻されます。この情報と実際に
入力されるパスワードを使用して、ユーザーを認証します。
CloudStack で LDAP 認証をセットアップするには、CloudStack API コマンドの「ldapConfig」を呼び出して
次の情報を指定します。
• LDAP サーバーのホスト名または IP アドレスとリッスンポート
• 基本ディレクトリとクエリフィルター
• 検索ユーザー識別名の資格情報(これにより、CloudStack が LDAP サーバーで検索を行えるようになりま
す)
• SSL キーストアとパスワード(SSL を使用する場合)
10.2.1. Example LDAP Configuration Commands
To understand the examples in this section, you need to know the basic concepts behind calling
the CloudStack API, which are explained in the Developer’s Guide.
The following shows an example invocation of ldapConfig with an ApacheDS LDAP server
http://127.0.0.1:8080/client/api?command=ldapConfig&hostname=127.0.0.1&searchbase=ou
%3Dtesting%2Co%3Dproject&queryfilter=%28%26%28uid%3D%25u%29%29&binddn=cn%3DJohn+Singh%2Cou
%3Dtesting%2Co%project&bindpass=secret&port=10389&ssl=true&truststore=C%3A%2Fcompany%2Finfo
%2Ftrusted.ks&truststorepass=secret&response=json&apiKey=YourAPIKey&signature=YourSignatureHash
The command must be URL-encoded. Here is the same example without the URL encoding:
http://127.0.0.1:8080/client/api?command=ldapConfig
&hostname=127.0.0.1
&searchbase=ou=testing,o=project
&queryfilter=(&(%uid=%u))
&binddn=cn=John+Singh,ou=testing,o=project
&bindpass=secret
&port=10389
&ssl=true
&truststore=C:/company/info/trusted.ks
&truststorepass=secret
&response=json
&apiKey=YourAPIKey&signature=YourSignatureHash
The following shows a similar command for Active Directory. Here, the search base is the testing
group within a company, and the users are matched up based on email address.
http://10.147.29.101:8080/client/api?command=ldapConfig&hostname=10.147.28.250&searchbase=OU%3Dtesting
%2CDC%3Dcompany&queryfilter=%28%26%28mail%3D%25e%29%29 &binddn=CN%3DAdministrator%2COU%3Dtesting%2CDC
%3Dcompany&bindpass=1111_aaaa&port=389&response=json&apiKey=YourAPIKey&signature=YourSignatureHash
The next few sections explain some of the concepts you will need to know when filling out the
ldapConfig parameters.
120
Search Base
10.2.2. Search Base
An LDAP query is relative to a given node of the LDAP directory tree, called the search base. The
search base is the distinguished name (DN) of a level of the directory tree below which all users can
be found. The users can be in the immediate base directory or in some subdirectory. The search
base may be equivalent to the organization, group, or domain name. The syntax for writing a DN
varies depending on which LDAP server you are using. A full discussion of distinguished names
is outside the scope of our documentation. The following table shows some examples of search
bases to find users in the testing department..
LDAP Server
Example Search Base DN
ApacheDS
ou=testing,o=project
Active Directory
OU=testing, DC=company
10.2.3. Query Filter
The query filter is used to find a mapped user in the external LDAP server. The query filter
should uniquely map the CloudStack user to LDAP user for a meaningful authentication. For more
information about query filter syntax, consult the documentation for your LDAP server.
The CloudStack query filter wildcards are:
Query Filter Wildcard
説明
%u
User name
%e
Email address
%n
First and last name
The following examples assume you are using Active Directory, and refer to user attributes from
the Active Directory schema.
If the CloudStack user name is the same as the LDAP user ID:
(uid=%u)
If the CloudStack user name is the LDAP display name:
(displayName=%u)
To find a user by email address:
(mail=%e)
10.2.4. Search User Bind DN
The bind DN is the user on the external LDAP server permitted to search the LDAP directory within
the defined search base. When the DN is returned, the DN and passed password are used to
authenticate the CloudStack user with an LDAP bind. A full discussion of bind DNs is outside the
scope of our documentation. The following table shows some examples of bind DNs.
LDAP Server
Example Bind DN
ApacheDS
cn=Administrator,dc=testing,ou=project,ou=org
121
第10章アカウント
LDAP Server
Example Bind DN
Active Directory
CN=Administrator, OU=testing, DC=company,
DC=com
10.2.5. SSL キーストアのパスとパスワード
LDAPサーバーがSSLを要求する場合、ldapConfigコマンドでssl、truststore、truststorepassを設定すること
で有効にする必要があります。SSLをldapConfigで有効にする前に、LDAPサーバーが使用している証明書を
取得し、信頼されたキーストアに追加します。キーストアのパスとパスワードを把握しておく必要があります。
122
User Services Overview
In addition to the physical and logical infrastructure of your cloud, and the CloudStack software
and servers, you also need a layer of user services so that people can actually make use of the
cloud. This means not just a user UI, but a set of options and resources that users can choose
from, such as templates for creating virtual machines, disk storage, and more. If you are running a
commercial service, you will be keeping track of what services and resources users are consuming
and charging them for that usage. Even if you do not charge anything for people to use your cloud –
say, if the users are strictly internal to your organization, or just friends who are sharing your cloud
– you can still keep track of what services they use and how much of them.
11.1. Service Offerings, Disk Offerings, Network Offerings,
and Templates
A user creating a new instance can make a variety of choices about its characteristics and
capabilities. CloudStack provides several ways to present users with choices when creating a new
instance:
• Service Offerings, defined by the CloudStack administrator, provide a choice of CPU speed,
number of CPUs, RAM size, tags on the root disk, and other choices. See Creating a New Compute
Offering.
• Disk Offerings, defined by the CloudStack administrator, provide a choice of disk size for primary
data storage. See Creating a New Disk Offering.
• Network Offerings, defined by the CloudStack administrator, describe the feature set that is
available to end users from the virtual router or external networking devices on a given guest
network. See Network Offerings.
• Templates, defined by the CloudStack administrator or by any CloudStack user, are the base OS
images that the user can choose from when creating a new instance. For example, CloudStack
includes CentOS as a template. See Working with Templates.
In addition to these choices that are provided for users, there is another type of service offering
which is available only to the CloudStack root administrator, and is used for configuring virtual
infrastructure resources. For more information, see Upgrading a Virtual Router with System Service
Offerings.
123
124
プロジェクトによるユーザーとリソースの組織化
12.1. プロジェクトの概要
CloudStackユーザーはプロジェクトチームを組織して協力し合い、仮想マシン、スナップショット、テンプレート、
データディスク、およびIPアドレスなどの仮想リソースを共有することができます。CloudStackによってプロジェ
クトおよびユーザーごとのリソース使用状況が追跡されるため、ユーザーアカウントまたはプロジェクト単位で
使用料を請求することができます。たとえば、ソフトウェア会社の品質保証部門のすべてのメンバーを、プライ
ベートクラウド内の1つのプロジェクトに割り当てます。プロジェクトメンバーは同じクラウドのほかのユーザーの
作業から自分たちの作業を簡単に分離できる一方で、会社はテストに使用されるリソースを追跡することがで
きます。
どのユーザーも新しいプロジェクトを作成できるように構成したり、この機能をCloudStack管理者のみに制限
したりすることができます。プロジェクトを作成すると、自身がそのプロジェクトの管理者になり、自分のドメイン
内のほかのユーザーをプロジェクトに追加できます。ユーザーをプロジェクトに直接追加できるようにするか、招
待状の送信を必須とするようにCloudStackをセットアップできます。招待状を必須とする場合は、受信者はこ
の招待状を承諾する必要があります。プロジェクトメンバーは、プロジェクト内のどのユーザーが作成した仮想
リソースも表示および管理できます(たとえば、共有仮想マシンなど)。ユーザーがメンバーになれるプロジェクト
の数に制限はありません。CloudStackユーザーインターフェイスのビューを切り替えれば、プロジェクト仮想マ
シン、仲間のプロジェクトメンバー、プロジェクト関連のアラートなど、プロジェクトに関する情報のみを表示する
ことができます。
プロジェクト管理者は、その役割を別のプロジェクトメンバーに委任できます。また、プロジェクト管理者は、さら
にメンバーを追加したり、メンバーをプロジェクトから削除したり、(CloudStack管理者が設定するグローバル
デフォルト以下であることが条件ですが)新しいリソース制限を設定したり、プロジェクトを削除したりすることも
できます。管理者がメンバーをプロジェクトから削除すると、そのユーザーが作成した仮想マシンインスタンスな
どのリソースはプロジェクトと共に残ります。これにより、リソースの所有権と、どのリソースをプロジェクトで使用
できるかという問題が生じます。
プロジェクト内で作成されたリソースは、特定のCloudStackアカウントではなく、プロジェクトによって所有さ
れ、プロジェクト内のみで使用できます。プロジェクトに属するユーザーは、プロジェクトの外にもリソースを作成
できます。そのようなリソースはユーザーのアカウントに属し、プロジェクトの使用状況やリソース制限の対象に
はなりません。プロジェクトレベルのネットワークを作成して、プロジェクト内のトラフィックを分離し、ポート転送、
負荷分散、VPN、静的NATなどのネットワークサービスを提供できます。プロジェクトでは、特定の種類のリソー
スが共有されている場合には、プロジェクトの外からそのリソースを利用することもできます。たとえば、共有ネッ
トワークまたはパブリックテンプレートは、ドメイン内のどのプロジェクトでも使用できます。テンプレートの所有
者が許可すれば、プロジェクトでプライベートテンプレートにアクセスできます。プロジェクトでは、そのドメインで
使用できるどのサービスオファリングまたはディスクオファリングも使用できますが、プロジェクトレベルではプラ
イベートサービスオファリングもディスクオファリングも作成できません。
12.2. プロジェクトの構成
CloudStack ユーザーがプロジェクトを使用する前に、CloudStack 管理者はプロジェクトをサポートするため
にさまざまなシステムをセットアップする必要があります。これには、プロジェクトメンバーになるための招待状、
プロジェクトのリソース制限、プロジェクトを作成できるユーザーの制御が含まれます。
12.2.1. 招待状のセットアップ
プロジェクト管理者がユーザーをプロジェクトに直接追加できるようにするか、招待状の送信を必須とするよう
に CloudStack をセットアップできます。招待状を必須とする場合は、受信者はこの招待状を承諾する必要があ
ります。招待状は電子メールまたはユーザーの CloudStack アカウントから送信できます。管理者が招待状を
125
第12章プロジェクトによるユーザーとリソースの組織化
使用してプロジェクトにメンバーを追加する設定にする場合は、CloudStack の招待状機能を有効にしてセット
アップします。
1. 管理者としてCloudStack ユーザーインターフェイスにログオンします。
2. 左側のナビゲーションバーで [Global Settings] をクリックします。
3.
検索ボックスに「project」と入力して検索ボタンをクリックします。
4. 検索結果には、招待状の動作を制御するために設定が必要なほかのパラメーターがいくつか含まれてい
ます。次の表に、プロジェクトの招待状に関連するグローバル構成パラメーターを示します。各パラメーター
を設定するには[Edit]アイコンをクリックします。
設定パラメーター
説明
project.invite.required
招待状機能を有効にするには true に設定します。
project.email.sender
招待状の電子メールの差出人フィールドに表示さ
れる電子メールアドレスです。
project.invite.timeout
新しいメンバーが招待状に返信するまでの猶予期
間です。
project.smtp.host
招待状を処理する電子メールサーバーとして機能
するホストの名前です。
project.smtp.password
(オプション)SMTP サーバーが要求するパス
ワードです。 project.smtp.username を指定し
て、project.smtp.useAuth を true に設定する必
要もあります。
project.smtp.port
SMTP サーバーのリッスンポートです。
project.smtp.useAuth
SMTP サーバーがユーザー名とパスワードを要求
する場合は true に設定します。
project.smtp.username
(オプション)SMTP サーバーが認証のために要求
するユーザー名です。 project.smtp.password を
指定して、project.smtp.useAuth を true に設定
する必要もあります。
5. 管理サーバーを再起動します:
service cloudstack-management restart
12.2.2. Setting Resource Limits for Projects
The CloudStack administrator can set global default limits to control the amount of resources
that can be owned by each project in the cloud. This serves to prevent uncontrolled usage of
resources such as snapshots, IP addresses, and virtual machine instances. Domain administrators
can override these resource limits for individual projects with their domains, as long as the new
limits are below the global defaults set by the CloudStack root administrator. The root administrator
can also set lower resource limits for any project in the cloud
126
Setting Resource Limits for Projects
12.2.2.1. プロジェクトごとのリソース制限の設定
CloudStack ルート管理者またはプロジェクトが存在するドメインのドメイン管理者は、個別のプロジェクトに新
しいリソース制限を設定できます。プロジェクト所有者は、ドメイン管理者またはルート管理者でもある場合にの
み、リソース制限を設定できます。
新しい制限は、CloudStack
管理者が設定するグローバルなデフォルト制限未満である必要があります
(�Setting Resource Limits for Projects�を参照)。特定の種類のリソースが新しい上限を既に超えているプロ
ジェクトについては、既存のリソースは影響を受けません。ただし、リソース量が上限値未満になるまで、そのプ
ロジェクトにはその種類のリソースを追加できなくなります。
1. 管理者としてCloudStack ユーザーインターフェイスにログオンします。
2. 左側のナビゲーションバーで [Projects] をクリックします。
3. [Select view] ボックスの一覧で [Projects] を選択します。
4. 設定するプロジェクトの名前をクリックします。
5. [Resources]タブをクリックします。このタブには、プロジェクトで所有を許可されている現在の最大数が、リ
ソースの種類ごとに一覧表示されます。
6. リソースの新しい値を入力します。
7. 「適用」をクリックします。
12.2.2.2. プロジェクトのグローバルなリソース制限の設定
1. 管理者としてCloudStack ユーザーインターフェイスにログインします。
2. 左側のナビゲーションバーで [Global Settings] をクリックします。
3. 検索ボックスに「max.project」と入力して検索ボタンをクリックします。
4. 検索結果には、クラウド内のすべてのプロジェクトに適用される、プロジェクトごとの最大リソース量を設定
するためのパラメーターが含まれています。どのプロジェクトでもこれらの設定を超えるリソースは使用でき
ませんが、個別のプロジェクトの制限をより低くすることはできます。各パラメーターを設定するには[Edit]ア
イコンをクリックします。
max.project.public.ips
クラウド内のどのプロジェクトでも所有できる、パブ
リック IP アドレス数の上限です。「パブリック IP ア
ドレスについて」を参照してください。
max.project.snapshots
クラウド内のどのプロジェクトでも所有できる、ス
ナップショット数の上限です。「スナップショットに
関わる作業」を参照してください。
max.project.templates
クラウド内のどのプロジェクトでも所有できる、テン
プレート数の上限です。「テンプレートに関わる作
業」を参照してください。
max.project.uservms
クラウド内のどのプロジェクトでも所有できる、ゲス
ト仮想マシン数の上限です。「仮想マシンの操作」
を参照してください。
127
第12章プロジェクトによるユーザーとリソースの組織化
max.project.volumes
クラウド内のどのプロジェクトでも所有できる、デー
タボリューム数の上限です。「ボリュームについて」
を参照してください。
5. 管理サーバーを再起動します。
# service cloudstack-management restart
12.2.3. プロジェクト作成者の権限の設定
どのユーザーも新しいプロジェクトを作成できる構成にすることも、この機能を CloudStack 管理者のみに制限
することもできます。
1. 管理者としてCloudStack ユーザーインターフェイスにログオンします。
2. 左側のナビゲーションバーで [Global Settings] をクリックします。
3. 検索ボックスに「allow.user.create.projects」と入力します。
4.
パラメーターを設定するには[Edit]アイコンをクリックします。
allow.user.create.projects
エンドユーザーがプロジェクトを作成できるように
するには true に設定します。 CloudStack ルート
管理者とドメイン管理者のみがプロジェクトを作成
できるようにするには false に設定します。
5. 管理サーバーを再起動します。
# service cloudstack-management restart
12.3. 新しいプロジェクトの作成
CloudStack 管理者とドメイン管理者はプロジェクトを作成することができます。グローバル構成パラメーター
の allow.user.create.projects が true に設定されている場合は、エンドユーザーもプロジェクトを作成できま
す。
1. CloudStack ユーザーインターフェイスにログオンします。
2. 左側のナビゲーションバーで［Projects］をクリックします。
3. [Select view] ボックスの一覧で [Projects] を選択します。
4. [New Project] をクリックします。
5. ユーザーに表示される名前と説明を入力して、[Create Project] をクリックします。
6. プロジェクトにメンバーを直ちに追加できる画面が開きます。これはオプションです。続行する準備ができた
ら [Next] をクリックします。
7. [Save] をクリックします。
128
プロジェクトへのメンバーの追加
12.4. プロジェクトへのメンバーの追加
新しいメンバーをプロジェクトに追加できるのは、プロジェクト管理者、プロジェクトの存在するドメインまたは親
ドメインのドメイン管理者、または CloudStack ルート管理者です。CloudStack にメンバーを追加する方法は
2 つありますが、一度に有効にできるのは 1 つの方法のみです。
• 招待状機能が有効な場合は、新しいメンバーに招待状を送信できます。
• 招待状機能が無効な場合は、ユーザーインターフェイスでメンバーを直接追加できます。
12.4.1. プロジェクトメンバーになるための招待状の送信
クラウドで招待状機能が有効になっている場合は（��）、次の手順に従ってプロジェクトに新しいメン
バーを追加します。招待状機能が無効な場合は、ユーザーインターフェイスでメンバーを追加します。
1. CloudStackユーザーインターフェイスにログオンします。
2. 左側のナビゲーションバーで［Projects］をクリックします。
3. ［Select view］ボックスの一覧で［Projects］を選択します。
4. 設定するプロジェクトの名前をクリックします。
5. ［Invitations］タブをクリックします。
6. ［Add by］で次のどちらかを選択します。
a. Account – ユーザーのプロジェクトビューの［Invitations］タブに招待状が表示されます。「プロジェク
トビューの使用方法」を参照してください。
b. Email – ユーザーの電子メールアドレス宛てに招待状が送信されます。この機能は、SMTPサーバー
関連のグローバルパラメーターが設定されている場合にのみ機能します。「招待状のセットアップ」を
参照してください。
7. 追加する新しいメンバーのCloudStackユーザー名または電子メールアドレスを入力して、［Invite］をク
リックします。前のステップでAccountを選択した場合にはCloudStackユーザー名を、Emailを選択した
場合は電子メールアドレスを入力します。このクラウドの、プロジェクトの存在するドメインにアカウントを持
つユーザーのみを招待できます。
8. 送信済みの招待状を表示し管理するには、このタブを開きます。招待状が承諾されると、新しいメンバーが
プロジェクトの［Accounts］タブに表示されます。
12.4.2. ユーザーインターフェイスでのメンバーの追加
クラウドで招待状機能が無効な場合は、次の手順に従ってプロジェクトに新しいメンバーを追加します。 ��
�� に記述されている方法によりクラウドで招待状機能が有効になっている場合は �� の手
順に従います。
1. CloudStackユーザーインターフェイスにログオンします。
2. 左側のナビゲーションバーで [Projects] をクリックします。
3. [Select view] ボックスの一覧で [Projects] を選択します。
4. 設定するプロジェクトの名前をクリックします。
129
第12章プロジェクトによるユーザーとリソースの組織化
5. [Accounts] タブをクリックします。現在のプロジェクトメンバーが一覧表示されます。
6. 追加する新しいメンバーのアカウント名を入力して、[Add Account] をクリックします。このクラウドの、プロ
ジェクトの\n存在するドメインにアカウントを持つユーザーのみを追加できます。
12.5. メンバー招待の受理
もし、CloudStack プロジェクトへの招待を受け取り、またそれを受理したい場合次の手順でおこないます。
1. CloudStackユーザーインターフェイスにログオンします。
2. 左側のナビゲーションバーで［Projects］をクリックします。
3. セレクトビューで招待を選択します。
4. 画面上に招待がリスト表示されたら、[Accept] をクリックします。
画面上にリスト表示された招待は利用している CloudStack のアカウント名に対して送られています。
5. 招待メールを受信した際は [Enter Token] をクリックし、メールからプロジェクト ID とユニークな ID コー
ド(トークン) を入力してください。
12.6. プロジェクトの一時停止または削除
プロジェクトを一時停止にすると、その所有するリソースは保持されますが使用できなくなります。一時停止の
プロジェクトに新しいリソースまたはメンバーを追加することはできません。
プロジェクトを削除すると、そのリソースは破棄され、プロジェクトからメンバーアカウントが削除されます。プロ
ジェクトの状態は「Disabled pending final deletion」と表示されます。
プロジェクトを一時停止または削除できるのは、プロジェクト管理者、プロジェクトの存在するドメインまたは親ド
メインのドメイン管理者、または CloudStack ルート管理者です。
1. CloudStackユーザーインターフェイスにログオンします。
2. 左側のナビゲーションバーで [Projects] をクリックします。
3. [Select view] ボックスの一覧で [Projects] を選択します。
4. プロジェクトの名前をクリックします。
5. 次のどちらかをクリックします。
削除するには [Delete project] をクリックしてください。
一時停止するには [Suspend project] をクリックしてください。
12.7. プロジェクトビューの使用方法
プロジェクトメンバーは CloudStack のプロジェクトビューを使用して、プロジェクトメンバーや消費リソースな
どを表示できます。プロジェクトビューには、1 つのプロジェクトに関連する情報のみが表示されます。ほかの情
報を除外できるので、1 つのプロジェクトの状態とリソースに集中することができます。
1. CloudStackユーザーインターフェイスにログオンします。
130
プロジェクトビューの使用方法
2. [Project View] をクリックします。
3. プロジェクトダッシュボードが開きます。ここには、プロジェクトの仮想マシン、ボリューム、ユーザー、イベン
ト、ネットワーク設定などが表示されます。ダッシュボードでは次のタスクを実行できます。
• [Accounts] タブをクリックして、プロジェクトメンバーを表示し管理する。プロジェクト管理者は、新しいメ
ンバーを追加し、メンバーを削除し、メンバーの役割をユーザーから管理者に変更できます。一度に管理
者になれるメンバーは 1 人であるため、ほかのユーザーを管理者に設定すると、設定したユーザーは通
常のユーザーに変わります。
• (招待状機能が有効な場合) [Invitations] タブをクリックして、新しいプロジェクトメンバーに送信済みか
つ未承諾の招待状を表示し管理する。保留の招待状は、新しいメンバーが承諾するか、招待状がタイム
アウトするか、管理者が招待状をキャンセルするまで、この一覧に表示されたままになります。
131
132
サービスオファリング
この章ではコンピュート、ディスク、システムサービスオファリングについて述べています。ネットワークオファリン
グに関してはユーザー向けの「ネットワークの設定」にて述べられています。
13.1. Compute and Disk Service Offerings
A service offering is a set of virtual hardware features such as CPU core count and speed, memory,
and disk size. The CloudStack administrator can set up various offerings, and then end users choose
from the available offerings when they create a new VM. A service offering includes the following
elements:
• CPU, memory, and network resource guarantees
• How resources are metered
• How the resource usage is charged
• How often the charges are generated
For example, one service offering might allow users to create a virtual machine instance that is
equivalent to a 1 GHz Intel® Core� 2 CPU, with 1 GB memory at $0.20/hour, with network traffic
metered at $0.10/GB. Based on the user’s selected offering, CloudStack emits usage records
that can be integrated with billing systems. CloudStack separates service offerings into compute
offerings and disk offerings. The computing service offering specifies:
• Guest CPU
• Guest RAM
• Guest Networking type (virtual or direct)
• Tags on the root disk
The disk offering specifies:
• Disk size (optional). An offering without a disk size will allow users to pick their own
• Tags on the data disk
13.1.1. 新しいコンピューティングオファリングの作成
新しいコンピューティングオファリングを作成するには
1. CloudStack ユーザーインターフェイスに管理者特権でログインします。
2. 左側のナビゲーションバーで[Service Offerings]をクリックします。
3. [Select Offering]ボックスの一覧で[Compute Offering]を選択します。
4. [Add Compute Offering]をクリックします。
5. ダイアログボックスで次の選択を行います。
• Name: サービスオファリングに指定する名前です。
133
第13章サービスオファリング
• Description: ユーザーに表示される、オファリングの短い説明です。
• Storage type: ゲストに割り当てるディスクの種類です。[Local]を選択すると、ハイパーバイザーホストに
直接アタッチされているストレージから割り当てます。[Shared]を選択すると、NFS 経由でアクセスできる
ストレージから割り当てます。
• # of CPU cores: このオファリングを使用するインスタンスに割り当てるコアの数です。
• CPU(in MHz): インスタンスに割り当てるコアの CPU 速度です。たとえば、2GHz クロックを提供する場
合は\n「2000」と指定します。
• Memory(in MB): インスタンスに割り当てるメモリの量(メガバイト単位)です。たとえば、2GB の RAM を
提供する場合は「2048」と指定します。
• Network Rate: 1 秒間に許可される MB 単位のデータ転送速度です。
• Offer HA: オンにする場合は、ユーザーは監視対象であり可能な限り可用性の高い仮想マシンを選択
できます。
• Storage Tags: このディスクのプライマリストレージに関連付けるタグです。
• Host Tags: (オプション)ホストの整理に使用するタグです。
• CPU cap: 使用率に余裕があっても、CPU 使用率に制限を設けるどうかを指定します。
• Public: Indicate whether the service offering should be available all domains or only some
domains. Choose Yes to make it available to all domains. Choose No to limit the scope to a
subdomain; CloudStack will then prompt for the subdomain's name.
6. [Add]をクリックします。
13.1.2. ディスクオファリングの作成
システムサービスオファリングを作成します。
1. CloudStack ユーザーインターフェイスに管理者としてログインします。
2. [Service Offerings]をクリックします。
3. [Select Offering]ボックスの一覧で[Disk Offerings]を選択します。
4. [Add Disk Offering]をクリックします。
5. ダイアログボックスで次の選択を行います。
• Name: システムオファリングに指定する名前です。
• Description: ユーザーに表示される、オファリングの短い説明です。
• Custom Disk Size: オンにした場合は、ユーザーは独自のディスクサイズを設定できます。オフにした場
合は、ルート管理者が[Disk Size]ボックスに値を定義する必要があります。
• Disk Size: [Custom Disk Size]チェックボックスがオフの場合にのみ表示されます。ボリュームサイズを
GB 単位で定義します。
134
Modifying or Deleting a Service Offering
• (Optional)Storage Tags. The tags that should be associated with the primary storage for this
disk. Tags are a comma separated list of attributes of the storage. For example "ssd,blue".
Tags are also added on Primary Storage. CloudStack matches tags on a disk offering to tags
on the storage. If a tag is present on a disk offering that tag (or tags) must also be present on
Primary Storage for the volume to be provisioned. If no such primary storage exists, allocation
from the disk offering will fail..
• Public. Indicate whether the service offering should be available all domains or only some
domains. Choose Yes to make it available to all domains. Choose No to limit the scope to a
subdomain; CloudStack will then prompt for the subdomain's name.
6. [Add]をクリックします。
13.1.3. Modifying or Deleting a Service Offering
Service offerings cannot be changed once created. This applies to both compute offerings and disk
offerings.
A service offering can be deleted. If it is no longer in use, it is deleted immediately and permanently.
If the service offering is still in use, it will remain in the database until all the virtual machines
referencing it have been deleted. After deletion by the administrator, a service offering will not be
available to end users that are creating new instances.
13.2. System Service Offerings
System service offerings provide a choice of CPU speed, number of CPUs, tags, and RAM size, just
as other service offerings do. But rather than being used for virtual machine instances and exposed
to users, system service offerings are used to change the default properties of virtual routers,
console proxies, and other system VMs. System service offerings are visible only to the CloudStack
root administrator. CloudStack provides default system service offerings. The CloudStack root
administrator can create additional custom system service offerings.
When CloudStack creates a virtual router for a guest network, it uses default settings which are
defined in the system service offering associated with the network offering. You can upgrade the
capabilities of the virtual router by applying a new network offering that contains a different system
service offering. All virtual routers in that network will begin using the settings from the new service
offering.
13.2.1. Creating a New System Service Offering
システムサービスオファリングを作成します。
1. CloudStack ユーザーインターフェイスに管理者としてログインします。
2. [Service Offerings]をクリックします。
3. In Select Offering, choose System Offering.
4. Click Add System Service Offering.
5. ダイアログボックスで次の選択を行います。
• Name: システムオファリングに指定する名前です。
135
第13章サービスオファリング
• Description: ユーザーに表示される、オファリングの短い説明です。
• System VM Type. Select the type of system virtual machine that this offering is intended to
support.
• Storage type. The type of disk that should be allocated. Local allocates from storage attached
directly to the host where the system VM is running. Shared allocates from storage accessible
via NFS.
• # of CPU cores. The number of cores which should be allocated to a system VM with this
offering
• CPU (in MHz). The CPU speed of the cores that the system VM is allocated. For example,
"2000" would provide for a 2 GHz clock.
• Memory (in MB). The amount of memory in megabytes that the system VM should be
allocated. For example, "2048" would provide for a 2 GB RAM allocation.
• Network Rate. Allowed data transfer rate in MB per second.
• Offer HA. If yes, the administrator can choose to have the system VM be monitored and as
highly available as possible.
• Storage Tags. The tags that should be associated with the primary storage used by the system
VM.
• Host Tags. (Optional) Any tags that you use to organize your hosts
• CPU cap. Whether to limit the level of CPU usage even if spare capacity is available.
• Public. Indicate whether the service offering should be available all domains or only some
domains. Choose Yes to make it available to all domains. Choose No to limit the scope to a
subdomain; CloudStack will then prompt for the subdomain's name.
6. [Add]をクリックします。
13.3. Network Throttling
Network throttling is the process of controlling the network access and bandwidth usage based
on certain rules. CloudStack controls this behaviour of the guest networks in the cloud by using
the network rate parameter. This parameter is defined as the default data transfer rate in Mbps
(Megabits Per Second) allowed in a guest network. It defines the upper limits for network utilization.
If the current utilization is below the allowed upper limits, access is granted, else revoked.
You can throttle the network bandwidth either to control the usage above a certain limit for some
accounts, or to control network congestion in a large cloud environment. The network rate for your
cloud can be configured on the following:
• Network Offering
• Service Offering
• Global parameter
136
Network Throttling
If network rate is set to NULL in service offering, the value provided in the vm.network.throttling.rate
global parameter is applied. If the value is set to NULL for network offering, the value provided in
the network.throttling.rate global parameter is considered.
For the default public, storage, and management networks, network rate is set to 0. This implies
that the public, storage, and management networks will have unlimited bandwidth by default. For
default guest networks, network rate is set to NULL. In this case, network rate is defaulted to the
global parameter value.
The following table gives you an overview of how network rate is applied on different types of
networks in CloudStack.
ネットワーク
Network Rate Is Taken from
Guest network of Virtual Router
Guest Network Offering
Public network of Virtual Router
Guest Network Offering
Storage network of Secondary Storage VM
System Network Offering
Management network of Secondary Storage
VM
System Network Offering
Storage network of Console Proxy VM
System Network Offering
Management network of Console Proxy VM
System Network Offering
Storage network of Virtual Router
System Network Offering
Management network of Virtual Router
System Network Offering
Public network of Secondary Storage VM
System Network Offering
Public network of Console Proxy VM
System Network Offering
Default network of a guest VM
Compute Offering
Additional networks of a guest VM
Corresponding Network Offerings
A guest VM must have a default network, and can also have many additional networks. Depending
on various parameters, such as the host and virtual switch used, you can observe a difference in the
network rate in your cloud. For example, on a VMware host the actual network rate varies based on
where they are configured (compute offering, network offering, or both); the network type (shared
or isolated); and traffic direction (ingress or egress).
The network rate set for a network offering used by a particular network in CloudStack is used for
the traffic shaping policy of a port group, for example: port group A, for that network: a particular
subnet or VLAN on the actual network. The virtual routers for that network connects to the port
group A, and by default instances in that network connects to this port group. However, if an
instance is deployed with a compute offering with the network rate set, and if this rate is used for
the traffic shaping policy of another port group for the network, for example port group B, then
instances using this compute offering are connected to the port group B, instead of connecting
to port group A.
The traffic shaping policy on standard port groups in VMware only applies to the egress traffic,
and the net effect depends on the type of network used in CloudStack. In shared networks, ingress
traffic is unlimited for CloudStack, and egress traffic is limited to the rate that applies to the port
group used by the instance if any. If the compute offering has a network rate configured, this rate
applies to the egress traffic, otherwise the network rate set for the network offering applies. For
isolated networks, the network rate set for the network offering, if any, effectively applies to the
ingress traffic. This is mainly because the network rate set for the network offering applies to the
137
第13章サービスオファリング
egress traffic from the virtual router to the instance. The egress traffic is limited by the rate that
applies to the port group used by the instance if any, similar to shared networks.
For example:
Network rate of network offering = 10 Mbps
Network rate of compute offering = 200 Mbps
In shared networks, ingress traffic will not be limited for CloudStack, while egress traffic will be
limited to 200 Mbps. In an isolated network, ingress traffic will be limited to 10 Mbps and egress
to 200 Mbps.
13.4. Changing the Default System Offering for System VMs
You can manually change the system offering for a particular System VM. Additionally, as a
CloudStack administrator, you can also change the default system offering used for System VMs.
1. Create a new system offering.
For more information, see �Creating a New System Service Offering� .
2. データベースをバックアップします。
mysqldump -u root -p cloud | bzip2 > cloud_backup.sql.bz2
3. Open an MySQL prompt:
mysql -u cloud -p cloud
4. Run the following queries on the cloud database.
a. In the disk_offering table, identify the original default offering and the new offering you
want to use by default.
Take a note of the ID of the new offering.
select id,name,unique_name,type from disk_offering;
b. For the original default offering, set the value of unique_name to NULL.
# update disk_offering set unique_name = NULL where id = 10;
Ensure that you use the correct value for the ID.
c. For the new offering that you want to use by default, set the value of unique_name as
follows:
For the default Console Proxy VM (CPVM) offering,set unique_name to 'Cloud.comConsoleProxy'. For the default Secondary Storage VM (SSVM) offering, set unique_name to
'Cloud.com-SecondaryStorage'. For example:
update disk_offering set unique_name = 'Cloud.com-ConsoleProxy' where id = 16;
138
Changing the Default System Offering for System VMs
5. Restart CloudStack Management Server. Restarting is required because the default offerings
are loaded into the memory at startup.
service cloudstack-management restart
6. Destroy the existing CPVM or SSVM offerings and wait for them to be recreated. The new CPVM
or SSVM are configured with the new offering.
139
140
Setting Up Networking for Users
14.1. Overview of Setting Up Networking for Users
People using cloud infrastructure have a variety of needs and preferences when it comes to the
networking services provided by the cloud. As a CloudStack administrator, you can do the following
things to set up networking for your users:
• Set up physical networks in zones
• Set up several different providers for the same service on a single physical network (for example,
both Cisco and Juniper firewalls)
• Bundle different types of network services into network offerings, so users can choose the desired
network services for any given virtual machine
• Add new network offerings as time goes on so end users can upgrade to a better class of service
on their network
• Provide more ways for a network to be accessed by a user, such as through a project of which
the user is a member
14.2. 仮想ネットワークについて
仮想ネットワークは、単一の物理ネットワーク上でマルチテナントを可能にする論理的な構成概念で
す。CloudStack では、仮想ネットワークを共有したり、分離したりできます。
14.2.1. 分離ネットワーク
分離ネットワークには単一アカウントの仮想マシンからのみアクセスできます。分離ネットワークには次の特性
があります。
• VLAN などのリソースは動的に割り当てられ、ガベージコレクション処理が行われます。
• ネットワーク全体に対してネットワークオファリングが 1 つ存在します。
• ネットワークオファリングはアップグレードしたりダウングレードしたりできますが、ネットワーク全体が対象で
す。
14.2.2. 共有ネットワーク
共有ネットワークには多くの異なるアカウントに属する仮想マシンからアクセスできます。共有ネットワーク上で
ネットワークを隔離するには、セキュリティグループ(基本ゾーンでのみサポート)などの技術を使用します。
• 共有ネットワークは、管理者によって作成されます。
• 共有ネットワークは、特定のドメインに対して指定できます。
• マップ先の VLAN や物理ネットワークなどの共有ネットワークリソースは、管理者によって指定されます。
• 共有ネットワークは、セキュリティグループによって分離されます。
• パブリックネットワークは、エンドユーザーに表示されない共有ネットワークです。
141
第14章 Setting Up Networking for Users
14.2.3. 仮想ネットワークリソースの実行時割り当て
When you define a new virtual network, all your settings for that network are stored in CloudStack.
The actual network resources are activated only when the first virtual machine starts in the network.
When all virtual machines have left the virtual network, the network resources are garbage collected
so they can be allocated again. This helps to conserve network resources.
14.3. ネットワークサービスプロバイダー
注記
CloudStack
がサポートするネットワークサービスプロバイダーの最新の一覧について
は、CloudStack ユーザーインターフェイスを参照するか、 listNetworkServiceProviders を
呼び出してください。
サービスプロバイダー(ネットワーク要素とも呼ばれます)は、ネットワークサービスを可能にするハードウェアま
たは仮想アプライアンスです。たとえば、ファイアウォールサービスを提供するために、ファイアウォールアプライ
アンスをクラウドに設置できます。単一ネットワーク上で、複数のプロバイダーが同じネットワークサービスを提
供できます。たとえば、同じ物理ネットワーク内で Cisco および Juniper のデバイスを使用して、ファイアウォール
サービスを提供できます。
同じサービスプロバイダーの複数のインスタンスを 1 つのネットワークに持たせることができます。たとえば、複
数の Juniper SRX デバイスです。
ネットワーク上で異なるプロバイダーが同じサービスを提供するようにセットアップする場合は、ユーザーが(そ
のほかの選択肢と共に)使用するネットワークサービスプロバイダーを指定できるように、管理者はネットワーク
オファリングを作成できます。作成しない場合は、サービスが要求されるときは常に、CloudStack によって使用
するプロバイダーが選択されます。
サポートされるネットワークサービスプロバイダー
CloudStack にはサポートされるサービスプロバイダーの内部一覧が同梱されます。ネットワークオファリングを
作成するときはこの一覧から選択することになります。
仮想ルーター
Citrix
NetScaler
Juniper SRX
F5 BigIP
Host based
(KVM/Xen)
Remote
Access VPN
Yes
No
No
No
No
DNS/DHCP/
User Data
Yes
No
No
No
No
ファイアウォール
Yes
No
Yes
No
No
負荷分散
Yes
Yes
No
Yes
No
Elastic IP
No
Yes
No
No
No
Elastic LB
No
Yes
No
No
No
送信元 NAT
Yes
No
Yes
No
No
静的 NAT
Yes
Yes
Yes
No
No
ポート転送
Yes
No
Yes
No
No
142
ネットワークオファリング
14.4. ネットワークオファリング
注記
サポートされるネットワークサービスのリストに関するアップデートは CloudStack ユーザー
インターフェイスか listNetworkServices の呼び出し結果を参照してください。
ネットワークオファリングは、次のようなネットワークサービスのセットに名前を付けたものです。
• DHCP
• DNS
• 送信元 NAT
• 静的 NAT
• ポート転送
• 負荷分散
• ファイアウォール
• VPN
• (オプション)ファイアウォール向けに Juniper など、特定のサービスに使用する、使用可能なプロバイダーの
いずれかの名前
• (オプション)使用する物理ネットワークを指定するネットワークタグ
新しい仮想マシンの作成時に、ユーザーは使用できるネットワークオファリングの中から 1 つ選択します。これで
仮想マシンで使用できるネットワークサービスが決定します。
CloudStack 管理者は、CloudStack によって提供されるデフォルトのネットワークオファリングのほかに、カス
タムネットワークオファリングをいくつでも作成できます。複数のカスタムネットワークオファリングを作成すること
によって、単一のマルチテナント物理ネットワーク上でさまざまなクラスのサービスを提供するようにクラウドを
セットアップできます。たとえば、基になる物理的な有線接続は同じであっても、テナント A には Web サイト用
に単純なファイアウォールの保護のみを提供し、テナント B にはデータベースのバックエンドにアクセスするため
に、Web サーバーファームを運用し、スケーラブルなファイアウォールソリューション、負荷分散ソリューション、
および代替ネットワークを提供することができます。
注記
もし、負荷分散ルールを作成する際 NetScaler のような外部デバイスを含んだネットワーク
サービスオファリングを利用していた場合、また後にネットワークサービスオファリングを
CloudStack の仮想ルーターを利用するよう変更を加える場合、継続して機能を利用するた
めには全ての負荷分散ルールに対しファイアウォールルールを追加しなければなりません。
新しい仮想ネットワークを作成するとき、CloudStack 管理者はそのネットワークに対して有効にするネットワー
クオファリングを選択します。各\n仮想ネットワークは、1 つのネットワークオファリングに関連付けられます。仮
想ネットワークは、その関連付けられたネットワークオファリングを変更することによって、アップグレードしたりダ
ウングレードしたりできます。そうする場合は、合致する物理ネットワークを再プログラミングしてください。
143
第14章 Setting Up Networking for Users
CloudStack には、CloudStack のシステム仮想マシンで使用する内部ネットワークオファリングもあります。こ
れらのネットワークオファリングはユーザーには表示されませんが、管理者が変更できます。
14.4.1. 新しいネットワークオファリングの作成
ネットワークオファリングを作成するには
1. CloudStack ユーザーインターフェイスに管理者特権でログオンします。
2. 左側のナビゲーションバーで[Service Offerings]をクリックします。
3. [Select Offering]ボックスの一覧で[Network Offering]を選択します。
4. [Add Network Offering]をクリックします。
5. ダイアログボックスで次の選択を行います。
• Name. Any desired name for the network offering.
• Description. A short description of the offering that can be displayed to users.
• Network Rate. Allowed data transfer rate in MB per second.
• Guest Type. Choose whether the guest network is isolated or shared.
For a description of this term, see the Administration Guide.
• Persistent. Indicate whether the guest network is persistent or not. The network that you
can provision without having to deploy a VM on it is termed persistent network. For more
information, see �Persistent Networks�.
• Specify VLAN. (Isolated guest networks only) Indicate whether a VLAN should be specified
when this offering is used.
• VPC. This option indicate whether the guest network is Virtual Private Cloud-enabled. A
Virtual Private Cloud (VPC) is a private, isolated part of CloudStack. A VPC can have its own
virtual network topology that resembles a traditional physical network. For more information
on VPCs, see �VPC(Virtual Private Cloud) ��.
• Supported Services. Select one or more of the possible network services. For some services,
you must also choose the service provider; for example, if you select Load Balancer, you can
choose the CloudStack virtual router or any other load balancers that have been configured
in the cloud. Depending on which services you choose, additional fields may appear in the
rest of the dialog box.
選択されたゲストネットワークタイプによって以下のサポートされるサービスが確認できます。
144
サポートされるサービ
ス
説明
分離
共有
DHCP
For more
information, see
�DNS�DHCP�.
サポートされている
サポートされている
新しいネットワークオファリングの作成
サポートされるサービ
ス
説明
分離
共有
DNS
For more
information, see
�DNS�DHCP�.
サポートされている
サポートされている
負荷分散
もし負荷分散を選択場サポートされている
合は CloudStack の
仮想ルーターかクラウ
ド上で設定された他の
負荷分散装置を選択す
ることができます。
サポートされている
ファイアウォール
For more
information, see ��
��.
サポートされている
サポートされている
送信元NAT
もし送信元NATを選択サポートされている
した場合、CloudStack
の仮想ルーターかクラ
ウド上で設定された他
の送信元NAT機能を
有したネットワーク機器
を選択することができま
す。
サポートされている
静的NAT
もし送信元NATを選択サポートされている
した場合、CloudStack
の仮想ルーターかクラ
ウド上で設定された他
の静的NAT機能を有し
たネットワーク機器を選
択することができます。
サポートされている
ポート転送
もし送信元NATを選択
した場合、CloudStack
の仮想ルーターかクラ
ウド上で設定された他
のポート転送機能を有
したネットワーク機器を
選択することができま
す。
サポートされている
サポートされていない
VPN
For more
information, see
�VPN�.
サポートされている
サポートされていない
ユーザーデータ
For more
information, see
the Administration
Guide.
サポートされていない
サポートされている
ネットワーク ACL
For more
information, see
サポートされている
サポートされていない
145
第14章 Setting Up Networking for Users
サポートされるサービ
ス
説明
分離
共有
サポートされていない
サポートされている
�Configuring Access
Control List�.
セキュリティグループ
For more
information, see ��
��.
• System Offering. If the service provider for any of the services selected in Supported Services
is a virtual router, the System Offering field appears. Choose the system service offering that
you want virtual routers to use in this network. For example, if you selected Load Balancer
in Supported Services and selected a virtual router to provide load balancing, the System
Offering field appears so you can choose between the CloudStack default system service
offering and any custom system service offerings that have been defined by the CloudStack
root administrator.
For more information, see the Administration Guide.
• Redundant router capability. Available only when Virtual Router is selected as the Source
NAT provider. Select this option if you want to use two virtual routers in the network for
uninterrupted connection: one operating as the master virtual router and the other as the
backup. The master virtual router receives requests from and sends responses to the user’s
VM. The backup virtual router is activated only when the master is down. After the failover,
the backup becomes the master virtual router. CloudStack deploys the routers on different
hosts to ensure reliability if one host is down.
• Conserve mode. Indicate whether to use conserve mode. In this mode, network resources
are allocated only when the first virtual machine starts in the network. When conservative
mode is off, the public IP can only be used for a single service. For example, a public IP used
for a port forwarding rule cannot be used for defining other services, such as StaticNAT or
load balancing. When the conserve mode is on, you can define more than one service on
the same public IP.
注記
If StaticNAT is enabled, irrespective of the status of the conserve mode, no
port forwarding or load balancing rule can be created for the IP. However,
you can add the firewall rules by using the createFirewallRule command.
• Tags. Network tag to specify which physical network to use.
6. [Add]をクリックします。
146
仮想マシンの操作
15.1. 仮想マシンの操作
CloudStackでは、クラウドで実行するすべてのゲスト仮想マシンのライフサイクルを管理者が完全に制御でき
ます。CloudStackには、エンドユーザー用および管理者用のゲスト管理操作が複数用意されています。仮想マ
シンは、停止、開始、再起動、および破棄することができます。
ゲストには名前とグループがあります。ゲスト名とグループはCloudStackにとって曖昧な情報で、エンドユー
ザーが自分の仮想マシンを整理するために使用できます。各仮想マシンには、異なるコンテキストで使用する3
つの名前があります。これらの名前のうち、ユーザーが制御できるのは2つだけです。
• Instance name – a unique, immutable ID that is generated by CloudStack, and can not be
modified by the user. This name conforms to the requirements in IETF RFC 1123.
• Display name – the name displayed in the CloudStack web UI. Can be set by the user. Defaults
to instance name.
• Name – host name that the DHCP server assigns to the VM. Can be set by the user. Defaults to
instance name
ゲストはHA（Highly Available：高可用性を持つ）に構成できます。HAが有効なゲストはシステムによって監視
されます。ゲストがダウン状態であることが検出されると、場合によっては別のホスト上でゲストの再起動が試
行されます。
新しく作成したVMには、各々1つのパブリックIPアドレスが割り当たります。VMを起動するとき、CloudStack は
自動的にパブリックIPアドレスとプライベートIPアドレスの間で静的NATを設定します。
エラスティックIPを（NetScaler負荷分散装置と共に）使用する場合、新たに作成するVMはエラスティックとし
て初期設定されません。ユーザーは自動設定されたIPを明示的に取得したエラスティックIPに置き換え、静的
NATのマッピングを新しいIPとVMのプライベートIPに対して行う必要があります。その際、VMの元のIPアドレス
は解放され、利用可能なパブリックIPのプールに返却されます。
CloudStackプラットフォームでは、予期せずに終了した仮想マシンと、ユーザーによって（たとえば、Linuxの
shutdownコマンドで）シャットダウンされたゲスト仮想マシンを区別できません。HAが有効なゲストが仮想マシ
ン内部でシャットダウンされた場合、CloudStackプラットフォームによってそのゲストが再起動されます。HAが
有効なゲストをシャットダウンするには、ユーザーはCloudStackユーザーインターフェイスまたはAPIを使用す
る必要があります。
15.2. Best Practices for Virtual Machines
The CloudStack administrator should monitor the total number of VM instances in each cluster,
and disable allocation to the cluster if the total is approaching the maximum that the hypervisor
can handle. Be sure to leave a safety margin to allow for the possibility of one or more hosts failing,
which would increase the VM load on the other hosts as the VMs are automatically redeployed.
Consult the documentation for your chosen hypervisor to find the maximum permitted number of
VMs per host, then use CloudStack global configuration settings to set this as the default limit.
Monitor the VM activity in each cluster at all times. Keep the total number of VMs below a safe
level that allows for the occasional host failure. For example, if there are N hosts in the cluster, and
you want to allow for one host in the cluster to be down at any given time, the total number of VM
instances you can permit in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches
this number of VMs, use the CloudStack UI to disable allocation of more VMs to the cluster.
147
第15章仮想マシンの操作
15.3. 仮想マシンのライフサイクル
仮想マシンがなる可能性のある状態は次のとおりです。
仮想マシンは、一度破棄すると復元できません。仮想マシンによって使用されたすべてのリソースは、システム
によって再利用されます。これには仮想マシンのIPアドレスが含まれます。
停止状態にすると、オペレーティングシステムの正常なシャットダウンが試行され、通常は実行中のすべてのア
プリケーションが終了されます。オペレーティングシステムを停止できない場合は、強制終了させます。これは、
物理マシンの電源コードを引き抜くのと同じ影響があります。
再起動とは、停止してから開始することです。
CloudStack では、仮想マシンのハードディスクの状態はマシンが破棄されるまで保存されます。
ハードウェアまたはネットワークの問題が原因で、実行中の仮想マシンに障害が発生することがあります。障害
が発生した仮想マシンはダウン状態になります。
システムがハイパーバイザーから3分間ハートビートを受信しない場合は、仮想マシンはダウン状態になりま
す。
仮想マシンはダウン状態から手動で再起動できます。
HAが有効であるとマークされている仮想マシンは、自動的にダウン状態から再起動されます。
15.4. VMの作成
仮想マシンは通常、テンプレートから作成されます。空の仮想マシンを作成することもできます。空の仮想マシン
とは、オペレーティングシステムのテンプレートを伴わない仮想マシンです。ユーザーはISOファイルをアタッチ
し、CD/DVD-ROMからオペレーティングシステムをインストールできます。
注記
You can create a VM without starting it. You can determine whether the VM needs
to be started as part of the VM deployment. A request parameter, startVM, in the
deployVm API provides this feature. For more information, see the Developer's
Guide
148
仮想マシンへのアクセス
テンプレートから仮想マシンを作成するには
1. 管理者またはユーザーとしてCloudStackユーザーインターフェイスにログオンします。
2. 左側のナビゲーションバーで［Instances］をクリックします。
3. ［Add Instance］をクリックします。
4. ゾーンの選択
5. テンプレートを選択して、ウィザードの手順に従います。テンプレートを一覧に表示する方法の詳細ついて
は、17��を参照してください。
6. 使用するハードウェアで、選択したサービスオファリングを開始できることを確認してください。
7. ［Submit］をクリックし、仮想マシンを作成して開始します。
注記
セキュリティ上の理由から、内部の仮想マシン名は root 管理者のみ閲覧できます。
ISOから仮想マシンを作成するには
注記
(XenServer) Windows 仮想マシンを XenServer 上で動作させるにはテンプレートとして提
供するか仮想マシンの作成後に追加する PV ドライバーが必要となります。管理サーバーで
の追加ボリュームやISOイメージのマウント、ライブマイグレーション、グレースフルシャットダウ
ンといった機能を利用するには PV ドライバーは必須となります。
1. 管理者またはユーザーとしてCloudStackユーザーインターフェイスにログオンします。
2. 左側のナビゲーションバーで［Instances］をクリックします。
3. ［Add Instance］をクリックします。
4. ゾーンの選択
5. ［ISO Boot］を選択し、ウィザードの手順に従います。
6. ［Submit］をクリックし、仮想マシンを作成して開始します。
15.5. 仮想マシンへのアクセス
各ユーザーはそれぞれの仮想マシンにアクセスすることができます。また、管理者はクラウド上の起動中の全て
の仮想マシンにアクセスすることができます。
CloudStack UIからの仮想マシンへのアクセス
1. ユーザーもしくは管理者として CloudStack UIからログインします。
2. インスタンスをクリックし、起動中の仮想マシンの名前をクリックします。
149
第15章仮想マシンの操作
3. [View
Console]アイコンをクリックします。
ネットワークを介した仮想マシンへの直接アクセス:
1. The VM must have some port open to incoming traffic. For example, in a basic zone, a new
VM might be assigned to a security group which allows incoming traffic. This depends on what
security group you picked when creating the VM. In other cases, you can open a port by setting
up a port forwarding policy. See �IP Forwarding and Firewalling�.
2. ポートを開放していても仮想マシンへのsshを有効化していない場合、仮想マシンに対してsshを除くアクセ
スを許可することができます。これは仮想マシンの作成時にsshを有効化したテンプレートを利用するかに
よって異なります。仮想マシンのオペレーティングシステムにおいてssh越しのコマンド実行を許可している
場合 CloudStack UIからのアクセスが可能となります。
3. If the network has an external firewall device, you will need to create a firewall rule to allow
access. See �IP Forwarding and Firewalling�.
15.6. 仮想マシンの停止と起動
Once a VM instance is created, you can stop, restart, or delete it as needed. In the CloudStack UI,
click Instances, select the VM, and use the Stop, Start, Reboot, and Destroy links.
15.7. 仮想マシン、OS、グループの名前変更
仮想マシンの作成後、表示名やオペレーティングシステム、グループの所属を変更することができます。
CloudStack UIからの仮想マシンへのアクセス
1. ユーザーもしくは管理者として CloudStack UIからログインします。
2. 左側のナビゲーションから「インスタンス」をクリックします。
3. 変更したい仮想マシンを選択します。
150
仮想マシンのサービスオファリングの変更
4.
5.
Click the Stop button to stop the VM.
Click Edit.
6. 変更したい以下項目の確認:
7. Display name: Enter a new display name if you want to change the name of the VM.
8. OS Type: Select the desired operating system.
9. Group: Enter the group name for the VM.
10. 「適用」をクリックします。
15.8. 仮想マシンのサービスオファリングの変更
To upgrade or downgrade the level of compute resources available to a virtual machine, you can
change the VM's compute offering.
1. ユーザーもしくは管理者として CloudStack UIからログインします。
2. 左側のナビゲーションから「インスタンス」をクリックします。
3. 削除したい仮想マシンを選択します。
4.
5.
Click the Stop button to stop the VM.
Click the Change Service button.
The Change service dialog box is displayed.
6. Select the offering you want to apply to the selected VM.
7. 「OK」をクリックします。
15.9. ホスト間の仮想マシンの移動（手動ライブマイグレーション）
CloudStack管理者は、ユーザーへのサービスを中断させることも、保守モードにすることもなく、実行中の仮想
マシンをあるホストから別のホストに移動できます。これを手動ライブマイグレーションと呼び、次の条件で実行
できます。
• ルート管理者がログオンしていること。ドメイン管理者およびユーザーは仮想マシンの手動ライブマイグレー
ションを実行できません。
• 仮想マシンが実行中であること。停止中の仮想マシンはライブマイグレーションできません。
• 移行先ホストが移行元のホストと同じクラスターに存在すること。
• 仮想マシンがローカルディスクストレージを使用していないこと。
• The destination host must have enough available capacity. If not, the VM will remain in the
"migrating" state until memory becomes available.
151
第15章仮想マシンの操作
仮想マシンを手動でライブマイグレーションするには
1. ユーザーもしくは管理者として CloudStack UIからログインします。
2. 左側のナビゲーションから「インスタンス」をクリックします。
3. 移行する仮想マシンを選択します。
4.
[Migrate Instance] ボタンをクリックします。
5. ホストの一覧から仮想マシンの移行先を選択します。
6. [OK]をクリックします。
15.10. 仮想マシンの削除
ユーザーは独自の仮想マシンを削除でき、起動中の仮想マシンの場合は削除前に停止されます。管理者は全
ての仮想マシンを削除することができます。
仮想マシンの削除方法:
1. ユーザーもしくは管理者として CloudStack UIからログインします。
2. 左側のナビゲーションから [Instances] をクリックします。
3. 削除したい仮想マシンを選択します。
4.
[Destroy Instance]アイコンをクリックします。
15.11. ISO に関わる作業
CloudStack は、ISO および ISO のゲスト仮想マシンへのアタッチをサポートします。ISO は、ISO/CD-ROM
形式のファイルシステムの読み取り専用ファイルです。ユーザーは自分の ISO をアップロードして、自分のゲス
ト仮想マシンにマウントできます。
ISO は、URL に基づいてアップロードされます。サポートされるプロトコルは HTTP です。ISO が HTTP 経由
で利用できるようになったら、http://my.web.server/filename.iso のようなアップロード用の URL を指定し
ます。
テンプレートのように、ISO をパブリックまたはプライベートにすることができます。ISO はハイパーバイザー固有
ではありません。つまり、vSphere のゲストは、KVM のゲストがマウントできるのとまったく同じイメージをマウン
トできます。
ISO イメージは、システムに格納して、テンプレートと同様のプライバシーレベルを指定して使用することができ
ます。ISO イメージは、起動可能または起動不可に分類されます。起動可能な ISO イメージは、オペレーティング
システムイメージを含むものです。CloudStack では、ユーザーが ISO イメージからゲスト仮想マシンを起動す
ることができます。また、ユーザーは ISO イメージをゲスト仮想マシンにアタッチすることもできます。たとえば、こ
れにより PV ドライバーを Windows にインストールできます。ISO イメージは、ハイパーバイザー固有ではあり
ません。
15.11.1. ISO の追加
追加のオペレーティングシステムやほかのソフトウェアをゲスト仮想マシンで使用できるようにするために、ISO
を追加できます。ISO は通常、オペレーティングシステムのイメージと考えられていますが、テンプレートの一部と
152
ISO の追加
してインストールするデスクトップアプリケーションなど、ほかの種類のソフトウェアの ISO を追加することもでき
ます。
1. 管理者またはユーザーとして CloudStack ユーザーインターフェイスにログオンします。
2. 左側のナビゲーションバーで[Templates]をクリックします。
3. [Select view]ボックスの一覧で[ISOs]を選択します。
4. [Add ISO]をクリックします。
5. [Add ISO]ダイアログボックスで、次の情報を入力します。
• Name : ISO イメージの短い名前です(例:CentOS 6.2 64 bit)。
• Description : ISO イメージの表示テキストです(例:CentOS 6.2 64 bit)。
• URL : ISO イメージをホストする URL です。管理サーバーは、HTTP 経由でこの場所にアクセスできる必
要があります。必要に応じて、ISO イメージを直接管理サーバー上に配置することができます。
• Zone : ISO を使用できるようにするゾーンを選択するか、[All Zones]を選択して CloudStack 全体で使
用できるようにします。
• Bootable : ゲストがこの ISO イメージから起動できるかどうかを指定します。たとえば、CentOS ISO は
起動できますが、Microsoft Office ISO は起動できません。
• OS Type : これは、CloudStack プラットフォームとハイパーバイザーで特定の処理を実行したり、想定
に基づいてゲストのパフォーマンスを向上したりするのに役立ちます。次のいずれかのオプションを選択
します。
• 使用する ISO イメージのオペレーティングシステムが一覧にある場合は、それを選択します。
• ISO のオペレーティングシステムの種類が一覧にない、または
[Other]を選択します。
ISO
が起動不可である場合は、
• (XenServer のみ)PV モードでこの ISO から起動する場合は、[Other PV(32-bit)]または[Other PV
(64-bit)]を選択します。
• (KVM のみ)PV に対応するオペレーティングシステムを選択する場合は、その ISO から作成する仮想
マシンのルートディスクは SCSI(virtio)になります。PV に対応しないオペレーティングシステムの場合
は、仮想マシンのルートディスクは IDE になります。PV に対応しているオペレーティングシステム:
Fedora 13
Fedora 12
Fedora 11
Fedora 10
Fedora 9
Other PV
Debian GNU/Linux
CentOS 5.3
CentOS 5.4
CentOS 5.5
Red Hat Enterprise Linux
5.3
Red Hat Enterprise Linux
5.4
Red Hat Enterprise Linux
5.5
Red Hat Enterprise Linux 6
153
第15章仮想マシンの操作
注記
注:通常は、イメージのオペレーティングシステムより古いバージョンを選択しないでく
ださい。たとえば、\nCentOS 6.2 イメージをサポートするために CentOS 5.4 を選択
すると、通常は動作しません。このような場合は、 [Other]を選択する必要があります。
• Extractable : ISO が抽出可能である必要がある場合は、このチェックボックスをオンにします。
• Public : この ISO をほかのユーザーが使用できる必要がある場合は、このチェックボックスをオンにしま
す。
• Featured : ユーザーが ISO を選択するときに「おすすめの ISO」としてこの ISO を目立たせるには、こ
のチェックボックスをオンにします。ISO が[Featured ISOs]の一覧に表示されます。ISO をおすすめに設
定できるのは管理者だけです。
6. 「OK」をクリックします。
管理サーバーが ISO をダウンロードします。ISO のサイズによっては、しばらく時間がかかることがあり
ます。ISO がセカンダリストレージに正常にダウンロードされると、ISO の状態が準備完了になります。
[Refresh]をクリックすると、ダウンロードの進捗率が更新されます。
7. 重要 : ISO のダウンロードが完了するまで次の操作をしないでください。次のタスクに進んで ISO をすぐ使
用しようとすると、失敗します。CloudStack で ISO 全体を利用できるようになってから、操作する必要があ
ります。
15.11.2. 仮想マシンへのISOのアタッチ
1. 左側のナビゲーションから「インスタンス」をクリックします。
2. アタッチする仮想マシンの選択
3.
[Attach ISO]ボタンをクリックします。
4. ISOアタッチのダイアログボックスで、アタッチしたいISOを選択します。
5. [OK]をクリックします。
154
ホストの操作
16.1. ホストの追加
ゲスト仮想マシンの処理能力を上げるため、いつでもホストを追加できます。要件と手順については、��を
参照してください。
16.2. ホストの計画保守と保守モード
ホストを保守モードにすることができます。保守モードがアクティブになると、ホストで新しいゲスト仮想マシンを
処理できなくなります。そのホストで実行中のゲスト仮想マシンは、保守モードでない別のホストにシームレス
に移行されます。この移行にはライブマイグレーション技術が使用され、ゲストの実行が中断されることはありま
せん。
16.2.1. vCenter と保守モード
vCenter ホストで保守モードを開始するには、vCenter と CloudStack が互いに連携して動作する必要があり
ます。 CloudStack と vCenter には、緊密に連携する別々の保守モードがあります。
1. Place the host into CloudStack's "scheduled maintenance" mode. This does not invoke the
vCenter maintenance mode, but only causes VMs to be migrated off the host
CloudStack の保守モードが要求されると、まずホストは保守準備状態になります。この状態のホストは、
新しいゲスト仮想マシンの起動対象になりません。次に、すべての仮想マシンがサーバーから移行されま
す。ライブマイグレーションを使用して、ホストから仮想マシンを移動します。これにより、ゲストの中断を伴
わずに、ほかのホストにゲストを移行できます。この移行の完了後、ホストは保守準備完了モードになりま
す。
2. Wait for the "Ready for Maintenance" indicator to appear in the UI.
3. ここで vCenter を使用して、ホストの保守に必要な操作を実行します。この間、ホストは新しいゲスト仮想
マシンの割り当て対象になりません。
4. 保守タスクを完了したら、次のようにホストの保守モードを解除します。
a. まず vCenter を使用して、vCenter の保守モードを終了します。
これにより、CloudStack による再アクティブ化の準備がホスト側で整います。
b. Then use CloudStack's administrator UI to cancel the CloudStack maintenance mode
ホストがオンラインに戻ると、ホストから移行されていた仮想マシンがホストに戻り、新しい仮想マシン
を追加できるようになります。
16.2.2. XenServer と保守モード
XenServer では XenCenter の保守モード機能を使うことで一時的にサーバーをオフラインにできます。サー
バーを保守モードにした場合、全ての稼働中仮想マシンは自動的に同じプール上の別ホストにマイグレーショ
ンされます。サーバーがプールのマスターである場合、プールから新しいマスターが選出されます。サーバーが
保守モード中は仮想マシンの作成や起動はできません。
サーバーを保守モードにするには:
155
第16章ホストの操作
1. [Resources]ペインからサーバーを選択し以下の作業を実施します。
• 右クリックしてショートカットメニューから[Enter Maintenance Mode]をクリックします。
• On the Server menu, click Enter Maintenance Mode.
2. Click Enter Maintenance Mode.
The server's status in the Resources pane shows when all running VMs have been successfully
migrated off the server.
サーバーを保守モードから戻すには:
1. [Resources]ペインからサーバーを選択し以下の作業を実施します。
• 右クリックしてショートカットメニューから[Exit Maintenance Mode]をクリックします。
• On the Server menu, click Exit Maintenance Mode.
2. Click Exit Maintenance Mode.
16.3. ゾーン、ポッド、およびクラスターの無効化と有効化
ゾーン、ポッド、またはクラスターは、クラウドから完全に削除することなく、有効または無効にできます。これは、
保守のため、または問題が発生してクラウドインフラストラクチャの一部が信頼できなくなった場合に便利で
す。状態が有効に戻るまで、無効のゾーン、ポッド、またはクラスターに新しい割り当ては行われません。最初に
ゾーン、ポッド、またはクラスターがクラウドに追加されたときはデフォルトで無効になっています。
ゾーン、ポッド、またはクラスターを無効または有効にするには
1. CloudStack ユーザーインターフェイスに管理者としてログオンします。
2. 左側のナビゲーションバーで [Infrastructure] をクリックします。
3. [Zones] で [View More]をクリックします。
4. ゾーンを有効化、無効化する場合はゾーンの名前をリストから探して [Enable/Disable] ボタンをクリックし
てください。
5. ポッドまたはクラスターを無効または有効にするには、そのポッドまたはクラスターを含むゾーンの名前をク
リックします。
6. [Compute] タブをクリックします。
7. ダイアグラムの [Pods] または [Clusters] ノードの [View All] をクリックします。
8. 一覧内のポッドまたはクラスターをクリックします。
9.
[Enable] または [Disable] アイコンをクリックします。
16.4. ホストの削除
ホストは必要に応じてクラウドから削除できます。ホストを削除する手順は、ハイパーバイザーの種類によって異
なります。
156
XenServer および KVM ホストの削除
16.4.1. XenServer および KVM ホストの削除
ノードは、保守モードになるまでクラスターから削除できません。これによって、ノード上のすべての仮想マシンが
ほかのホストに確実に移行されます。ホストをクラウドから削除するには、次の手順に従います。
1. ノードを保守モードにします。
�� を参照してください。
2. For KVM, stop the cloudstack-agent service.
3. ユーザーインターフェイスオプションを使用して、ノードを削除します。
これで、ホストの電源を切り、その IP アドレスを再使用したり再インストールしたりできるようになりました。
16.4.2. vSphere ホストの削除
この種類のホストを削除するには、�� で説明されているように、まずホストを保守モードにします。
次に、CloudStack を使用して、ホストを削除します。CloudStack を使用して削除されたホストに対して、
CloudStack はコマンドを実行しません。ただし、その場合でもホストは vCenter クラスター内に残しておくこと
ができます。
16.5. Re-Installing Hosts
You can re-install a host after placing it in maintenance mode and then removing it. If a host is
down and cannot be placed in maintenance mode, it should still be removed before the re-install.
16.6. ハイパーバイザーホストの維持
ハイパーバイザーソフトウェアをホスト上で動作させている場合、ハイパーバイザー製造元が提供するすべての
Hotfix を適用したことを確認します。ハイパーバイザーの製造元のサポートチャネルを通じてパッチのリリー
ス状況を確認し、パッチがリリースされたらできるだけ早く適用します。ハイパーバイザーの必須パッチについて
CloudStack が自動的に通知することはありません。ホストにハイパーバイザーの最新パッチを適用することは
非常に重要です。最新パッチが適用されていないシステムは、おそらくハイパーバイザーの製造元からサポート
を受けられません。
注記
最新の Hotfix を適用しないと、データの破損や仮想マシンの喪失が生じる可能性がありま
す。
(XenServer) For more information, see Highly Recommended Hotfixes for XenServer in the CloudStack
1
Knowledge Base .
16.7. Changing Host Password
The password for a XenServer Node, KVM Node, or vSphere Node may be changed in the database.
Note that all Nodes in a Cluster must have the same password.
To change a Node's password:
1
http://docs.cloudstack.org/Knowledge_Base/Possible_VM_corruption_if_XenServer_Hotfix_is_not_Applied/
Highly_Recommended_Hotfixes_for_XenServer_5.6_SP2
157
第16章ホストの操作
1. Identify all hosts in the cluster.
2. Change the password on all hosts in the cluster. Now the password for the host and the
password known to CloudStack will not match. Operations on the cluster will fail until the two
passwords match.
3. Get the list of host IDs for the host in the cluster where you are changing the password. You will
need to access the database to determine these host IDs. For each hostname "h" (or vSphere
cluster) that you are changing the password for, execute:
mysql> select id from cloud.host where name like '%h%';
4. This should return a single ID. Record the set of such IDs for these hosts.
5. Update the passwords for the host in the database. In this example, we change the passwords
for hosts with IDs 5, 10, and 12 to "password".
mysql> update cloud.host set password='password' where id=5 or id=10 or id=12;
16.8. ホストの割り当て
システムは仮想マシンを動作させるために最も適切なホストを自動的に選択します。エンドユーザーは仮想マ
シンを作成するゾーンを指定することができますが仮想マシンインスタンスがどのホストで動作するかは制御す
ることはできません。
CloudStack 管理者はゲストインスタンタイプに対しパフォーマンスを確保するため特定のホストを指定するこ
とができます。たとえば管理者は Windows ゲストを動作させるだけのパフォーマンスを確保するためにホスト
を指定することができます。デフォルトのホスト割り当ては OS タイプによりどのホストに配置するかを試み、動
作可能な処理能力を持つサーバー全てが対象になります。
垂直割り当てと水平割り当ての両方が可能です。垂直割り当てでは、特定のホストのリソースをすべて消費し
た後で、次のホストにゲストを割り当てます。これにより、クラウドの消費電力が抑えられます。水平割り当てで
は、ラウンドロビン方式で各ホストにゲストを配置します。これにより、ゲストのパフォーマンスが向上する場合が
あります。CloudStack では、管理者が構成するとおりに CPU オーバープロビジョニングの要素を許可すること
ができます。オーバープロビジョニングを使用すると、ハードウェアで実際に使用できるよりも高い CPU サイクル
をゲストに割り当てることができます。
また、CloudStack では、新しいアロケーターを追加するためのプラグ可能なインターフェイスも提供します。こ
れらのカスタムアロケーターを使用して、管理者が要求するどのようなポリシーにも対応できます。
16.8.1. オーバープロビジョニングとサービスオファリングの制限
CloudStack では、管理者の構成するオーバープロビジョニング比率に基づいて、CPU オーバープロビジョニ
ングを実行します。これは、「cpu.overprovisioning.factor」グローバル構成変数によって定義されます。
CloudStack では、管理者の構成するオーバープロビジョニング比率に基づいて、CPU オーバープロビジョニ
ングを実行します。これは、「cpu.overprovisioning.factor」グローバル構成変数によって定義されます。
サービスオファリングの制限(たとえば、1GHz、1 コアなど)は、コア数に厳密に適用されます。たとえば、1 コアを
提供するサービスオファリングを使用するゲストは、ホスト上のほかのアクティビティにかかわりなく、使用できる
コアは 1 つだけです。
動作周波数に対するサービスオファリングの制限は、CPU リソースが競合する場合にのみ適用されます。たと
えば、2GHz のコアを持つホスト上で 1GHz のサービスオファリングを使用するゲストを作成したとします。こ
158
VLAN プロビジョニング
のゲストは、ホスト上で実行される唯一のゲストです。この場合は、ゲストは 2GHz すべてを使用できます。複数
のゲストが CPU を使用しようとする場合は、重み係数を使用して CPU リソースをスケジュールします。重
みは、サービスオファリングのクロック速度に基づきます。ゲストは、サービスオファリングの動作周波数に比例
した CPU 割り当てを受けます。たとえば、2GHz のサービスオファリングで作成されたゲストは、1GHz のサー
ビスオファリングで作成されたゲストの 2 倍の CPU 割り当てを受けます。
16.9. VLAN プロビジョニング
CloudStack は、ホスト上に VLAN にブリッジするインターフェイスを自動的に作成し、破棄します。一般に、管理
者はこのプロセスを管理する必要はありません。
CloudStack は、ハイパーバイザーの種類に基づいて VLAN を別々に管理します。XenServer または KVM の
場合は、VLAN は使用されるホスト上のみに作成され、VLAN を必要とするすべてのゲストが終了または別の
ホストに移動したときに破棄されます。
vSphere の場合は、VLAN を必要とするゲストが特定のホストで実行されていなくても、VLAN がクラスター
内のすべてのホストにプロビジョニングされます。そのため、管理者は移行先のホストに VLAN を作成しなくて
も、vCenter でライブマイグレーションなどの機能を実行できます。さらに、VLAN は必要がなくなっても、ホスト
から削除されません。
スイッチのような L2 インフラストラクチャに接続された物理ネットワークが別である場合は同一 VLAN を利用
することができます。例えば、拡張ゾーンセットアップの物理ネットワークAとBの展開時に VLAN 範囲 500から
1000を指定することができます。これにより別 NIC 上に追加の L2 物理インフラストラクチャを作成し、 VLAN
を使い果たした場合に同一の VLAN を利用することができます。その他の利点として別ユーザーや別 NIC を利
用するルーター、ゲストネットワークに対し同一の IP セットを利用することができます。
159
160
テンプレートと動作
テンプレートは仮想マシンに対し再利用、再設定可能なものであり、ユーザーは仮想マシンを展開する際
CloudStack のテンプレートリストから選択できます。
あるテンプレートは様々なオペレーティングシステムと仮想ディスクイメージを含んでおり、オフィスアプリケー
ションのようなソフトウェアや誰がテンプレートを利用するかといったアクセスコントロール設定も追加で含まれ
ます。各々のテンプレートは特定のハイパーバイザーに割り当てられいつ CloudStack に追加されるかも決め
られています。
CloudStack
で提供されているデフォルトのテンプレートとは別に、ユーザーからの選択によっては
CloudStack 管理者やユーザーは新規のテンプレートを作成し新たに CloudStack に追加することができま
す。
17.1. テンプレートの作成:概要
CloudStack には、CentOS オペレーティングシステム用のデフォルトのテンプレートが同梱されています。テン
プレートを追加するにはさまざまな方法があります。管理者とエンドユーザーがテンプレートを追加できます。一
般的な手順は次のとおりです。
1. 必要なオペレーティングシステムが動作する仮想マシンインスタンスを起動します。ほかに仮想マシンの構
成を変更する必要がある場合は、変更します。
2. 仮想マシンを停止します。
3. ボリュームをテンプレートに変換します。
There are other ways to add templates to CloudStack. For example, you can take a snapshot of
the VM's volume and create a template from the snapshot, or import a VHD from another system
into CloudStack.
テンプレートを作成するさまざまな方法については、後続のいくつかのセクションで説明します。
17.2. テンプレートの要件
• XenServer では、作成する各テンプレートに PV ドライバー/XenServer Tools をインストールします。これに
より、ライブマイグレーションと正常なゲストのシャットダウンを行うことができます。
• vSphere では、作成する各テンプレートに VMware Tools をインストールします。これにより、コンソール
ビューが適切に動作します。
17.3. テンプレートのベストプラクティス
大きなテンプレート(100GB 以上)を使用する計画の場合は、大きなテンプレートをサポートするために、10 ギ
ガビットのネットワークを利用できることを確認してください。ネットワークの速度が遅いと、大きなテンプレートを
使用したときに、タイムアウトなどのエラーが発生する可能性があります。
17.4. デフォルトのテンプレート
CloudStack には、CentOS テンプレートが含まれています。このテンプレートは、プライマリストレージとセカン
ダリストレージを構成した後で、セカンダリストレージ仮想マシンでダウンロードします。このテンプレートを実稼
働環境で使用することも、削除してカスタムテンプレートを使用することもできます。
The root password for the default template is "password".
161
第17章テンプレートと動作
デフォルトのテンプレートは、XenServer、KVM、および vSphere のそれぞれに提供されます。ダウンロードする
テンプレートは、クラウドで利用できるハイパーバイザーの種類に応じて異なります。各テンプレートは、物理サ
イズで約 2.5GB です。
デフォルトのテンプレートには標準の iptables の規則が含まれ、ssh を除いてほとんどのアクセスがブロックさ
れます。
# iptables --list
Chain INPUT (policy ACCEPT)
target
prot opt source
RH-Firewall-1-INPUT all --
anywhere
destination
anywhere
Chain FORWARD (policy ACCEPT)
target
prot opt source
RH-Firewall-1-INPUT all -- anywhere
destination
anywhere
Chain OUTPUT (policy ACCEPT)
target
prot opt source
destination
Chain RH-Firewall-1-INPUT (2 references)
target
prot opt source
destination
ACCEPT
all -- anywhere
anywhere
ACCEPT
icmp -- anywhere
anywhere
icmp any
ACCEPT
esp -- anywhere
anywhere
ACCEPT
ah
-- anywhere
anywhere
ACCEPT
udp -- anywhere
224.0.0.251
udp dpt:mdns
ACCEPT
udp -- anywhere
anywhere
udp dpt:ipp
ACCEPT
tcp -- anywhere
anywhere
tcp dpt:ipp
ACCEPT
all -- anywhere
anywhere
state RELATED,ESTABLISHED
ACCEPT
tcp -- anywhere
anywhere
state NEW tcp dpt:ssh
REJECT
all -- anywhere
anywhere
reject-with icmp-host-
17.5. プライベートテンプレートとパブリックテンプレート
ユーザーがテンプレートを作成するとき、プライベートまたはパブリックに指定できます。
プライベートテンプレートは、作成したユーザーのみが使用できます。デフォルトで、アップロードされたテンプ
レートはプライベートになります。
When a user marks a template as “public,” the template becomes available to all users in all
accounts in the user's domain, as well as users in any other domains that have access to the Zone
where the template is stored. This depends on whether the Zone, in turn, was defined as private
or public. A private Zone is assigned to a single domain, and a public Zone is accessible to any
domain. If a public template is created in a private Zone, it is available only to users in the domain
assigned to that Zone. If a public template is created in a public Zone, it is available to all users
in all domains.
17.6. 既存の仮想マシンからのテンプレートの作成
少なくとも 1 台の仮想マシンを希望どおりにセットアップすれば、それをほかの仮想マシンのプロトタイプとして
使用できます。
1. �VM�� の方法のどちらかを使用して、仮想マシンを作成して起動します。
2. 実行中の仮想マシンで必要な構成変更を行い、[Stop]をクリックします。
3. 仮想マシンが停止するのを待ちます。状態が停止済みになったら、次の手順に進みます。
162
スナップショットからのテンプレートの作成
4. [Create Template]をクリックして、次の情報を入力します。
• Name および Display Text : これらはユーザーインターフェイスに表示されるため、わかりやすい言葉を
選択します。
• OS Type : これは、CloudStack プラットフォームとハイパーバイザーで特定の処理を実行したり、想定
に基づいてゲストのパフォーマンスを向上したりするのに役立ちます。次のいずれかのオプションを選択
します。
• 停止している仮想マシンのオペレーティングシステムが一覧にある場合は、それを選択します。
• 停止している仮想マシンのオペレーティングシステムの種類が一覧にない場合は、[Other]を選択しま
す。
• PV モードでこのテンプレートから起動する場合は、[Other PV(32-bit)]または[Other PV(64-bit)]を
選択します。この選択肢は、XenServer でのみ使用できます。
注記
注:通常は、イメージのオペレーティングシステムより古いバージョンを選択しないで
ください。たとえば、\nCentOS 6.2 イメージをサポートするために CentOS 5.4 を
選択すると、通常は動作しません。このような場合は、 [Other]を選択する必要があ
ります。
• Public : この CloudStack 環境のすべてのユーザーがこのテンプレートにアクセスできるようにするに
は、このチェックボックスをオンにします。テンプレートが [Community Templates] の一覧に表示されま
す。��を参照してください。
• Password Enabled: テンプレートに CloudStack プラットフォームのパスワード変更スクリプトがイン
ストールされている場合は、このチェックボックスをオンにします。詳細は �� を参照して
ください。
5. [Add]をクリックします。
テンプレートの作成プロセスが完了すると、新しいテンプレートが[Templates]セクションに表示されます。この
テンプレート\nは、新しい仮想マシンを作成するときに使用できます。
17.7. スナップショットからのテンプレートの作成
[Create Template]メニュー項目を使用するために仮想マシンを停止したくない場合は(��を
参照)、CloudStack ユーザーインターフェイスを使用して、スナップショットからテンプレートを直接作成できま
す。
17.8. テンプレートのアップロード
vSphere テンプレートと ISO
vSphere Client を使用して作成したテンプレートをアップロードする場合は、OVA ファイルに
ISO が含まれないことを確認してください。ISO が含まれていると、テンプレートから仮想マシ
ンを展開できません。
163
第17章テンプレートと動作
テンプレートは、URL に基づいてアップロードされます。サポートされるアクセスプロトコルは HTTP です。テンプ
レートは、大きなファイルである場合がよくあります。オプションとして gzip 形式で圧縮し、アップロード時間を削
減することができます。
テンプレートをアップロードするには
1. 左側のナビゲーションバーで[Templates]をクリックします。
2. Click Register Template.
3. 次の情報を指定します。
• Name and Description. These will be shown in the UI, so choose something descriptive.
• URL. The Management Server will download the file from the specified URL, such as http://
my.web.server/filename.vhd.gz.
• Zone. Choose the zone where you want the template to be available, or All Zones to make
it available throughout CloudStack.
• OS Type: This helps CloudStack and the hypervisor perform certain operations and make
assumptions that improve the performance of the guest. Select one of the following:
• 停止している仮想マシンのオペレーティングシステムが一覧にある場合は、それを選択します。
• 停止している仮想マシンのオペレーティングシステムの種類が一覧にない場合は、[Other]を選択しま
す。
注記
通常は、イメージのオペレーティングシステムより古いバージョンを選択しないでく
ださい。たとえば、\nCentOS 6.2 イメージをサポートするために CentOS 5.4 を
選択すると、通常は動作しません。このような場合は、 [Other]を選択する必要があ
ります。
• Hypervisor: The supported hypervisors are listed. Select the desired one.
• Format : VHD や OVA など、テンプレートのアップロードファイルの形式です。
• Password Enabled : テンプレートに CloudStackのパスワード変更スクリプトがインストールされてい
る場合は、このチェックボックスをオンにします。「テンプレートへのパスワード管理機能の追加」を参照し
てください。
• Extractable : テンプレートを抽出可能にする場合、このチェックボックスをオンにします。エンドユーザー
はテンプレートの全てのイメージをダウンロード可能になります。
• Public : この CloudStack 環境のすべてのユーザーがこのテンプレートにアクセスできるようにするに
は、このチェックボックスをオンにします。テンプレートが [Community Templates] の一覧に表示されま
す。��を参照してください。
• Featured : ユーザーがテンプレートを選択するときに「おすすめのテンプレート」としてこのテンプレート
を目立たせるには、このチェックボックスをオンにします。テンプレートが[Featured Templates]の一覧
に表示されます。テンプレートをおすすめに設定できるのは管理者だけです。
164
テンプレートのエクスポート
17.9. テンプレートのエクスポート
エンドユーザーと管理者はテンプレートを CloudStack からエクスポートすることができます。ユーザーインター
フェイスでテンプレートに移動して、操作メニューの[Download Template]をクリックします。
17.10. Windows テンプレートの作成
Windows テンプレートは、複数のコンピューターにプロビジョニングする前に、Sysprep を使用して準備する必
要があります。 Sysprep を使用すると、汎用の Windows テンプレートを作成して SID の競合を回避すること
ができます。
注記
(XenServer) Windows 仮想マシンを XenServer 上で動作させるにはテンプレートとして提
供するか仮想マシンの作成後に追加する PV ドライバーが必要となります。管理サーバーで
の追加ボリュームやISOイメージのマウント、ライブマイグレーション、グレースフルシャットダウ
ンといった機能を利用するには PV ドライバーは必須となります。
手順の概要は、次のとおりです。
1. Windows ISO をアップロードします。
詳しくは、�ISO ��を参照してください。
2. この ISO を使用して、仮想マシンインスタンスを作成します。
詳しくは、�VM��を参照してください。
3. Windows Server のバージョンに応じて、次の「Windows Server 2008 R2 の Sysprep」または
「Windows Server 2003 R2 の Sysprep」の手順に従います。
4. 準備の手順が完了しました。これで、「Windows テンプレートの作成」で説明するように、テンプレートを実
際に作成できます。
17.10.1. Windows Server 2008 R2 の Sysprep
Windows Server 2008 R2 では、Windows システムイメージマネージャーを実行してカスタムの sysprep
応答 XML ファイルを作成します。Windows システムイメージマネージャーは、Windows AIK(Automated
Installation Kit:自動インストールキット) の一部としてインストールされます。Windows AIK は、Microsoft
1
Download Center からダウンロードできます。
Windows Server 2008 R2 で sysprep を実行するには、次の手順に従います。
注記
ここで概要を示す手順は、Charity Shelbourne による優れたガイドに由来するものであり、
2
元は次の URL で公開されています。 Windows Server 2008 Sysprep Mini-Setup.
1. Windows AIK をダウンロードしてインストールします。
1
http://www.microsoft.com/en-us/download/details.aspx?id=9085
165
第17章テンプレートと動作
注記
注:Windows AIK は、今作成した Windows Server 2008 R2 仮想マシンにはイン
ストールしないでください。Windows AIK は、作成するテンプレートに含めないでくださ
い。sysprep 応答ファイルの作成のみに使用します。
2. Windows
Server
2008
R2
のインストール
DVD
の\sources
ディレクトリにある
install.wim ファイルをハードディスクにコピーします。これは非常に大きいファイルであり、コピーに長い時
間がかかる場合があります。Windows AIK を使用するには、WIM ファイルを書き込み可能にする必要があ
ります。
3. Windows AIK の一部である Windows システムイメージマネージャーを起動します。
4. [Windows イメージ]ペインで[Windows イメージまたはカタログファイルを指定してください]を右クリックし
て、今コピーした install.wim ファイルをロードします。
5. Windows 2008 R2 Edition を選択します。
カタログファイルを開くことができないと警告するダイアログボックスが表示されることがあります。新しいカ
タログファイルを作成するには、[はい]をクリックします。
6. [応答ファイル]ペインで、右クリックして新しい応答ファイルを作成します。
7. 次の手順に従って、Windows システムイメージマネージャーから応答ファイルを作成します。
a. 自動化する必要がある最初のページは、言語および国や地域を選択するページです。これを自動化す
るには、 [Windows イメージ]ペインで[Components]を展開し、右クリックして[Microsoft-WindowsInternational-Core] 設定を[7 oobeSystem]に追加します。[応答ファイル]ペインで、使用する言語と
国または地域に合わせて、 [InputLocale]、[SystemLocale]、[UILanguage]、および[UserLocale]を
適切に構成します。これらの設定でわからない点がある場合は、特定の設定を右クリックして[ヘルプ]
をクリックします。すると、構成しようとしている設定の例を含む詳細情報が記載された、適切な CHM
ヘルプファイルが開きます。
166
Windows Server 2008 R2 の Sysprep
b. ソフトウェアライセンス条項つまりエンドユーザー使用許諾契約書のページを自動化する必要があり
ます。これを行うには、[Components]の[Microsoft-Windows-Shell-Setup]を展開します。[OOBE]
を強調表示して、この設定を[7 oobeSystem]に追加します。[設定]で、[HideEULAPage]の横のボック
スの一覧から[true]を選択します。
167
第17章テンプレートと動作
c. ライセンスキーが適切に設定されていることを確認します。MAK
キーを使用する場合は、Windows
2008 R2 仮想マシンに MAK キーを入力するだけで済みます。MAK を Windows システムイメージ
マネージャーに入力する必要はありません。ライセンス認証に KMS ホストを使用する場合は、プロダ
クトキーを入力する必要はありません。Windows ボリュームライセンス認証について詳しくは、 http://
technet.microsoft.com/ja-jp/library/bb892849.aspx を参照してください。
d. 次に、管理者のパスワードの変更ページを自動化する必要があります。[Components]の
[Microsoft-Windows-Shell-Setup]を展開して(まだ展開していない場合)、[UserAccounts]を展開
し、 [AdministratorPassword]を右クリックして、設定を応答ファイルの oobeSystem 構成パスに追
加します。[設定] で、[Value]の横にパスワードを指定します。
168
Windows Server 2003 R2 用システム準備
AIK のドキュメントを参照して、環境に合うほかの多くのオプションを設定することができます。上の手
順は、Windows の無人セットアップを実行するための最小限の内容です。
8. 応答ファイルを unattend.xml という名前で保存します。検証ウィンドウに表示される警告メッセージは無
視できます。
9. unattend.xml ファイルを Windows Server 2008 R2 仮想マシンの c:\windows\system32\sysprep
フォルダーにコピーします。
10. unattend.xml ファイルを c:\windows\system32\sysprep ディレクトリに配置した後で、次のように
sysprep ツールを実行します。
cd c:\Windows\System32\sysprep
sysprep.exe /oobe /generalize /shutdown
Windows Server 2008 R2 仮想マシンは、sysprep が完了すると自動的にシャットダウンします。
17.10.2. Windows Server 2003 R2 用システム準備
以前のバージョンの Windows には、別の sysprep ツールを使用します。Windows Server 2003 R2 では、次
の手順に従います。
1. Windows のインストール CD の\support\tools\deploy.cab の内容を、Windows Server 2003 R2
仮想マシンの c:\sysprep ディレクトリに抽出します。
169
第17章テンプレートと動作
2. c:¥sysprep¥setupmgr.exe を実行して、sysprep.inf ファイルを作成します。
a. [新しい応答ファイルを作成する]をクリックして、新しい応答ファイルを作成します。
b. [セットアップの種類]ページで、[Sysprep セットアップ]をクリックします。
c. 適切なオペレーティングシステムのバージョンとエディションを選択します。
d. [使用許諾契約書]ページで、[はい、インストールを完全に自動化します]をクリックします。
e. 名前と組織を入力します。
f.
ディスプレイの設定はデフォルトのままにします。
g. 適切なタイムゾーンを設定します。
h. プロダクトキーを入力します。
i.
環境に合ったライセンスモードを選択します。
j.
[コンピュータ名を自動で生成する]をクリックします。
k.
デフォルトの管理者パスワードを入力します。パスワードのリセット機能を有効にした場合は、ユーザー
は実際にはこのパスワードを使用しません。このパスワードは、ゲストの起動後にインスタンスマネー
ジャーによってリセットされます。
l.
[ネットワークコンポーネント]ページの設定は、[標準的な設定]のままにします。
m. [ワークグループ]をクリックして設定します。
n. [テレフォニー]ページの設定はデフォルトのままにします。
o. 適切な地域設定を選択します。
p. 適切な言語設定を選択します。
q. プリンターをインストールしないでください。
r.
最初のログオン時に実行するコマンドは指定しないでください。
s.
ID 文字列を指定する必要はありません。
t.
応答ファイルを c:\sysprep\sysprep.inf という名前で保存します。
3. 次のコマンドを実行して、イメージに sysprep を実行します。
c:\sysprep\sysprep.exe -reseal -mini -activated
この手順の後で、マシンは自動的にシャットダウンします。
17.11. AMI のインポート
次の手順では、XenServer
ハイパーバイザーを使用する場合に、AMI(Amazon
CloudStackにインポートする方法を説明します。
170
Machine
Image)を
AMI のインポート
AMI ファイルがあり、そのファイルが CentOS_6.2_x64 という名前であることを前提としています。さら
に、CentOS ホストで作業することを前提としています。AMI が Fedora イメージである場合は、まず Fedora ホ
ストで作業する必要があります。
注:イメージファイルを Centos/Fedora ホストでカスタマイズした後に VHD に変換する場合は、ファイルベース
のストレージリポジトリ(ローカル ext3 または NFS のどちらか)を持つ XenServer ホストが必要です。
注記
コマンドをコピーして実行するときは、単一の行として貼り付けたことを確認してください。一
部のドキュメントビューアーでは、コピーしたテキストに不要な改行が含まれる可能性があり
ます。
AMI をインポートするには
1. イメージファイルでループバックをセットアップします。
# mkdir -p /mnt/loop/centos62
# mount -o loop CentOS_6.2_x64 /mnt/loop/centos54
2. kernel-xen パッケージをイメージにインストールします。これにより、PV カーネルおよび RAM ディスクがイ
メージにダウンロードされます。
# yum -c /mnt/loop/centos54/etc/yum.conf --installroot=/mnt/loop/centos62/ -y install kernel-xen
3. grub エントリを/boot/grub/grub.conf に作成します。
# mkdir -p /mnt/loop/centos62/boot/grub
# touch /mnt/loop/centos62/boot/grub/grub.conf
# echo "" > /mnt/loop/centos62/boot/grub/grub.conf
4. イメージにインストールされた PV カーネルの名前を確認します。
# cd /mnt/loop/centos62
# ls lib/modules/
2.6.16.33-xenU 2.6.16-xenU 2.6.18-164.15.1.el5xen 2.6.18-164.6.1.el5.centos.plus 2.6.18-xenU-ec2-v1.0
2.6.21.7-2.fc8xen 2.6.31-302-ec2
# ls boot/initrd*
boot/initrd-2.6.18-164.6.1.el5.centos.plus.img boot/initrd-2.6.18-164.15.1.el5xen.img
# ls boot/vmlinuz*
boot/vmlinuz-2.6.18-164.15.1.el5xen boot/vmlinuz-2.6.18-164.6.1.el5.centos.plus boot/vmlinuz-2.6.18-xenUec2-v1.0 boot/vmlinuz-2.6.21-2952.fc8xen
Xen kernels/ramdisk always end with "xen". For the kernel version you choose, there has to be
an entry for that version under lib/modules, there has to be an initrd and vmlinuz corresponding
to that. Above, the only kernel that satisfies this condition is 2.6.18-164.15.1.el5xen.
5. 調べた結果に基づいて、grub.conf ファイルにエントリを作成します。エントリの例を次に示します。
default=0
timeout=5
hiddenmenu
title CentOS (2.6.18-164.15.1.el5xen)
171
第17章テンプレートと動作
root (hd0,0)
kernel /boot/vmlinuz-2.6.18-164.15.1.el5xen ro root=/dev/xvda
initrd /boot/initrd-2.6.18-164.15.1.el5xen.img
6. etc/fstab を編集します。「sda1」を「xvda」に、「sdb」を「xvdb」に変更します。
# cat etc/fstab
/dev/xvda /
/dev/xvdb /mnt
none
/dev/pts
none
/proc
none
/sys
ext3
ext3
devpts
proc
sysfs
defaults
defaults
gid=5,mode=620
defaults
defaults
1
0
0
0
0
1
0
0
0
0
7. コンソール経由でのログオンを有効にします。XenServer システムのデフォルトのコンソールデバイスは
xvc0 です。 etc/inittab と etc/securetty に、それぞれ次の行があることを確認します。
# grep xvc0 etc/inittab
co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav
# grep xvc0 etc/securetty
xvc0
8. RAM ディスクが PV ディスクと PV ネットワークをサポートしていることを確認します。上の例で確認した
カーネルバージョンに合わせて、これをカスタマイズします。
#
#
#
#
chroot /mnt/loop/centos54
cd /boot/
mv initrd-2.6.18-164.15.1.el5xen.img initrd-2.6.18-164.15.1.el5xen.img.bak
mkinitrd -f /boot/initrd-2.6.18-164.15.1.el5xen.img --with=xennet --preload=xenblk --omit-scsi-modules
2.6.18-164.15.1.el5xen
9. パスワードを変更します。
# passwd
Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
10. chroot を終了します。
# exit
11. etc/ssh/sshd_config の、パスワードを使用して ssh ログオンを許可する行を確認します。
# egrep "PermitRootLogin|PasswordAuthentication" /mnt/loop/centos54/etc/ssh/sshd_config
PermitRootLogin yes
PasswordAuthentication yes
12. テンプレートのパスワードを CloudStack ユーザーインターフェイスまたは API からリセットできるようにす
る必要がある場合は、この時点でパスワード変更スクリプトをイメージにインストールします。��
��を参照してください。
13. ループバックマウントを解除して削除します。
172
Hyper-V 仮想マシンのテンプレートへの変換
# umount /mnt/loop/centos54
# losetup -d /dev/loop0
14. Copy the image file to your XenServer host's file-based storage repository. In the example
below, the Xenserver is "xenhost". This XenServer has an NFS repository whose uuid is
a9c5b8c8-536b-a193-a6dc-51af3e5ff799.
# scp CentOS_6.2_x64 xenhost:/var/run/sr-mount/a9c5b8c8-536b-a193-a6dc-51af3e5ff799/
15. Xenserver にログオンして、イメージと同じサイズの VDI を作成します。
[root@xenhost ~]# cd /var/run/sr-mount/a9c5b8c8-536b-a193-a6dc-51af3e5ff799
[root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# ls -lh CentOS_6.2_x64
-rw-r--r-- 1 root root 10G Mar 16 16:49 CentOS_6.2_x64
[root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# xe vdi-create virtual-size=10GiB sr-uuid=a9c5b8c8-536ba193-a6dc-51af3e5ff799 type=user name-label="Centos 6.2 x86_64"
cad7317c-258b-4ef7-b207-cdf0283a7923
16. イメージファイルを VDI にインポートします。これには 10~20 分かかる可能性があります。
[root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# xe vdi-import filename=CentOS_6.2_x64
uuid=cad7317c-258b-4ef7-b207-cdf0283a7923
17. VHD ファイルを見つけます。このファイルの名前には、VDI の UUID が含まれます。圧縮して Web サー
バーにアップロードします。
[root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# bzip2 -c cad7317c-258b-4ef7-b207-cdf0283a7923.vhd >
CentOS_6.2_x64.vhd.bz2
[root@xenhost a9c5b8c8-536b-a193-a6dc-51af3e5ff799]# scp CentOS_6.2_x64.vhd.bz2 webserver:/var/www/html/
templates/
17.12. Hyper-V 仮想マシンのテンプレートへの変換
Hyper-V 仮想マシンを XenServer 互換の CloudStack テンプレートに変換するには、NFS VHD ストレージ
リポジトリがアタッチされたスタンドアロンの XenServer ホストが必要です。CloudStack と組み合わせて使用
しているバージョンであれば XenServer のバージョンはどれでもかまいませんが、XenCenter 5.6 FP1 または
SP2(5.6 と後方互換性があります)を使用してください。また、NFS ISO ストレージリポジトリがアタッチされてい
ると役に立つ場合があります。
Linux 仮想マシンでは、仮想マシンを XenServer で使用する前に、Hyper-V で準備する必要がある場合
があります。 Hyper-V で引き続き仮想マシンを使用する場合は、仮想マシンを複製して、その複製で作業しま
す。Hyper-V 統合コンポーネントをアンインストールして、/etc/fstab でデバイス名を参照していないか確認し
ます。
1. From the linux_ic/drivers/dist directory, run make uninstall (where "linux_ic" is the path to the
copied Hyper-V Integration Components files).
2. 元の initrd を/boot/のバックアップから復元します(バックアップの名前は*.backup0 です)。
3. Remove the "hdX=noprobe" entries from /boot/grub/menu.lst.
173
第17章テンプレートと動作
4. デバイス名でマウントされているパーティションがないか/etc/fstab を確認します。そのようなエントリがあ
る場合は、 LABEL または UUID でマウントするよう変更します。この情報を取得するには blkid コマンドを
実行します。
次に、仮想マシンが Hyper-V で動作していないことを確認してから、VHD を XenServer に取り込みます。これ
を行うには、 2 つの方法があります。
オプション 1
1. Import the VHD using XenCenter. In XenCenter, go to Tools>Virtual Appliance Tools>Disk
Image Import.
2. [VHD]を選択し、[次へ]をクリックします。
3. Name the VM, choose the NFS VHD SR under Storage, enable "Run Operating System Fixups"
and choose the NFS ISO SR.
4. [次へ]をクリックし、[完了]をクリックします。これで、仮想マシンが作成されます。
オプション 2
1. XenConvert
を実行して、[変換元]ボックスの一覧で[VHD]を選択し、[変換先]ボックスの一覧で
[XenServer]を選択します。[次へ]をクリックします。
2. [VHD]を選択し、[次へ]をクリックします。
3. XenServer ホストの情報を入力し、[次へ]をクリックします。
4. 仮想マシンに名前を付け、[次へ]をクリックし、[変換]をクリックします。これで、仮想マシンが作成されます。
Hyper-V VHD から仮想マシンを作成したら、次の手順に従って、その仮想マシンを準備します。
1. 仮想マシンを起動して、Hyper-V 統合サービスをアンインストールし、再起動します。
2. XenServer Tools をインストールし、再起動します。
3. 必要に応じて仮想マシンを準備します。たとえば、Windows 仮想マシンで sysprep を実行します。詳細は
�Windows �� を参照してください。
上のオプションのどちらでも、HVM モードの仮想マシンが作成されます。Windows 仮想マシンの場合は問題
はありませんが、Linux 仮想マシンは適切に動作しない場合があります。Linux 仮想マシンを PV モードに変換
するには、追加の手順を実行する必要があり、その手順はディストリビューションごとに異なります。
1. 仮想マシンをシャットダウンして、VHD を NFS ストレージから Web サーバーにコピーします。たとえ
ば、NFS 共有を Web サーバーにマウントしてコピーするか、XenServer ホストから sftp または scp を使
用して、Web サーバーにアップロードします。
2. CloudStack で次の値を使用して、新しいテンプレートを作成します。
• URL : VHD の URL を指定します。
• OS Type : 適切なオペレーティングシステムを使用します。PV モードの CentOS の場合は、[Other
PV(32-bit)] または[Other PV(64-bit)]を選択します。この選択肢は、XenServer でのみ使用できます。
• Hypervisor : [XenServer]を選択します。
• Format : [VHD]を選択します。
174
テンプレートへのパスワード管理機能の追加
テンプレートが作成され、そのテンプレートからインスタンスを作成できます。
17.13. テンプレートへのパスワード管理機能の追加
CloudStack は、パスワードのリセット機能をオプションで提供します。ユーザーは CloudStack ユーザーイン
ターフェイスで一時的な管理者パスワードまたはルートパスワードを設定したり、既存の管理者パスワードまた
はルートパスワードをリセットしたりできます。
パスワードのリセット機能を有効にするには、追加のスクリプトをダウンロードしてテンプレートに適用する必要
があります。テンプレートを後で CloudStack にアップロードする場合は、このテンプレートで管理者/ルートパ
スワードのリセット機能を有効にするかどうかを指定できます。
パスワード管理機能により、インスタンスの起動時にアカウントのパスワードが常にリセットされます。スクリプト
により仮想ルーターに HTTP 呼び出しが行われ、設定する必要があるアカウントのパスワードが取得されます。
仮想ルーターにアクセスできる限り、ゲストは使用する必要があるアカウントのパスワードにアクセスできます。
ユーザーがパスワードのリセットを要求すると、管理サーバーにより新しいパスワードが生成され、そのアカウン
トの仮想ルーターに送信されます。このため、パスワードの変更を有効にするには、インスタンスの再起動が必
要です。
インスタンスの起動中にスクリプトが仮想ルーターと通信できない場合は、パスワードは設定されず、通常どお
り起動が続行されます。
17.13.1. Linux オペレーティングシステムのインストール
次の手順に従って、Linux オペレーティングシステムのインストールを開始します。
1. スクリプトファイルの cloud-set-guest-password をダウンロードします。
• Linux: http://cloudstack.org/dl/cloud-set-guest-password
• Windows:
http://sourceforge.net/projects/cloudstack/files/Password%20Management
%20Scripts/CloudInstanceManager.msi/download
2. このファイルを/etc/init.d にコピーします。
一部の Linux ディストリビューションでは、このファイルを/etc/rc.d/init.d にコピーします。
3. 次のコマンドを実行して、スクリプトを実行可能にします。
chmod +x /etc/init.d/cloud-set-guest-password
4. Linux ディストリビューションに応じて、適切な手順を続行します。
Fedora、CentOS/RHEL、および Debian:
chkconfig --add cloud-set-guest-password
17.13.2. Window オペレーティングシステムのインストール
3
インストーラーの CloudInstanceManager.msi を Download page からダウンロードして、新しく作成した
Windows 仮想マシンで実行します。
3
http://cloudstack.org/download.html
175
第17章テンプレートと動作
17.14. テンプレートの削除
テンプレートは削除することができます。通例、テンプレートが複数のゾーンにまたがって存在する場合は、削除
のために選択されたコピーのみが削除されます。ほかのゾーンの同じテンプレートは削除されませ
ん。CloudStack で提供する CentOS テンプレートは、これに当てはまりません。CloudStack で提供する
CentOS テンプレートを削除すると、すべてのゾーンから削除されます。
テンプレートを削除しても、そのテンプレートからインスタンス化された仮想マシンは引き続き動作します。ただ
し、削除されたテンプレートに基づいて新しい仮想マシンを作成することはできません。
176
Working With Storage
18.1. ストレージについて
CloudStack は2種類のストレージタイプを定義しています: プライマリとセカンダリ。プライマリストレージは
iSCSIやNFSを介してアクセスすることができます。加えて、直接接続されたストレージもプライマリストレージと
して利用することができます。セカンダリストレージはNFSを介して常にアクセスされます。
CloudStack には短期的なストレージは無く、全てのノード上の全てのボリュームは永続性を持ちます。
18.2. プライマリストレージ
ここでは、CloudStack のプライマリストレージの概念と技術の詳細について説明します。CloudStack ユー
ザーインターフェイスを使用してプライマリストレージをインストールおよび構成する方法については、『インス
トールガイド』を参照してください。
��
18.2.1. Best Practices for Primary Storage
• The speed of primary storage will impact guest performance. If possible, choose smaller, higher
RPM drives for primary storage.
• Ensure that nothing is stored on the server. Adding the server to CloudStack will destroy any
existing data
18.2.2. Runtime Behavior of Primary Storage
Root volumes are created automatically when a virtual machine is created. Root volumes are
deleted when the VM is destroyed. Data volumes can be created and dynamically attached to VMs.
Data volumes are not deleted when VMs are destroyed.
Administrators should monitor the capacity of primary storage devices and add additional primary
storage as needed. See the Advanced Installation Guide.
Administrators add primary storage to the system by creating a CloudStack storage pool. Each
storage pool is associated with a cluster.
18.2.3. ハイパーバイザーのプライマリストレージサポート
次の表は各ハイパーバイザー毎のストレージオプションとパラメーターです。
VMware
vSphere
Citrix
XenServer
KVM
Format for Disks, Templates と VMDK
Snapshots
VHD
QCOW2
iSCSI support
Clustered
LVM
Yes,
via
Shared
Mountpoint
VMFS
177
第18章 Working With Storage
VMware
vSphere
Citrix
XenServer
KVM
Fiber Channel support
VMFS
Yes,
via Yes,
via
Existing SR
Shared
Mountpoint
NFS support
Y
Y
Y
Local storage support
Y
Y
Y
Storage over-provisioning
NFS と iSCSI
NFS
NFS
XenServer は iSCSI への仮想マシンイメージの展開にクラスタ型 LVM を利用しており、ストレージ自体がシ
ン・プロビジョニングをサポートしていてもハイパーバイザーではオーバープロビジョニングをサポートしていま
せん。その結果、CloudStack ではシン・プロビジョニングが動作しているストレージボリュームを利用している
場合においてオーバープロビジョニングをサポートします。
KVM supports "Shared Mountpoint" storage. A shared mountpoint is a file system path local to each
server in a given cluster. The path must be the same across all Hosts in the cluster, for example /
mnt/primary1. This shared mountpoint is assumed to be a clustered filesystem such as OCFS2. In
this case the CloudStack does not attempt to mount or unmount the storage as is done with NFS.
The CloudStack requires that the administrator insure that the storage is available
NFS ストレージについては、CloudStack でオーバープロビジョニングが管理されます。この場合は、グローバ
ル構成パラメーターの storage.overprovisioning.factor によってオーバープロビジョニングの程度が制御さ
れます。これはハイパーバイザーの種類とは関係ありません。
ローカルストレージは、vSphere、XenServer、および KVM のプライマリストレージオプションとして選択できま
す。ローカルディスクオプションが有効になっていると、ローカルディスクストレージプールが各ホストに自動的
に作成されます。システム仮想マシン(仮想ルーターなど)にローカルストレージを使用するには、グローバル構
成で system.vm.use.local.storage を true に設定します。
CloudStack では、1 つのクラスターに複数のプライマリストレージプールを設定できます。たとえば、プライマリ
ストレージに 2 台の NFS サーバーを準備できます。または、最初に 1 つの iSCSI LUN を準備し、1 つ目の LUN
の容量に近づいたときに 2 つ目の iSCSI LUN を追加することもできます。
18.2.4. ストレージタグ
Storage may be "tagged". A tag is a text string attribute associated with primary storage, a Disk
Offering, or a Service Offering. Tags allow administrators to provide additional information about
the storage. For example, that is a "SSD" or it is "slow". Tags are not interpreted by CloudStack.
They are matched against tags placed on service and disk offerings. CloudStack requires all tags
on service and disk offerings to exist on the primary storage before it allocates root or data disks
on the primary storage. Service and disk offering tags are used to identify the requirements of the
storage that those offerings have. For example, the high end service offering may require "fast" for
its root disk volume.
タグ、割り当て、クラスターおよびポッドをまたがるボリュームコピーの相互処理は複雑になる可能性がありま
す。この状況を単純にするには、ポッド内のすべてのクラスターのプライマリストレージで同じタグセットを使用し
ます。さまざまなデバイスにタグ付けする場合でも、提示するタグセットは同じにすることができます。
18.2.5. プライマリストレージの保守モード
プライマリストレージは、保守モードにすることができます。たとえばこのモードは、ストレージデバイスの故障し
た RAM を交換するときに役立ちます。ストレージデバイスを保守モードにすると、まず新しいゲストがストレージ
178
セカンダリストレージ
デバイスにプロビジョニングされなくなります。続いて、そのストレージデバイスにボリュームを持つすべてのゲス
トが停止されます。そのようなゲストがすべて停止されると、ストレージデバイスは保守モードに入ったものとし
てシャットダウンできるようになります。
ストレージデバイスが再びオンラインになったときに、デバイスの保守
モードをキャンセルすることができます。CloudStack
によってデバイスがオンラインに戻され、保守モードに
入ったときに実行していたすべてのゲストの起動が試行されます。
18.3. セカンダリストレージ
ここでは、CloudStack のセカンダリストレージの概念と技術の詳細について説明します。CloudStack ユー
ザーインターフェイスを使用してセカンダリストレージをインストールおよび構成する方法については、『インス
トールガイド上級編』を参照してください。
��
18.4. Working With Volumes
ボリュームは仮想マシンに対するストレージを提供し、ルートディスクや追加のデータディスクとして仮想マシン
に提供されます。CloudStack は仮想マシンへの追加ボリュームをサポートしています。
Volumes are created for a specific hypervisor type. A volume that has been attached to guest using
one hypervisor type (e.g, XenServer) may not be attached to a guest that is using another hypervisor
type, for example:vSphere, KVM. This is because the different hypervisors use different disk image
formats.
CloudStack defines a volume as a unit of storage available to a guest VM. Volumes are either root
disks or data disks. The root disk has "/" in the file system and is usually the boot device. Data disks
provide for additional storage, for example: "/opt" or "D:". Every guest VM has a root disk, and VMs
can also optionally have a data disk. End users can mount multiple data disks to guest VMs. Users
choose data disks from the disk offerings created by administrators. The user can create a template
from a volume as well; this is the standard procedure for private template creation. Volumes are
hypervisor-specific: a volume from one hypervisor type may not be used on a guest of another
hypervisor type.
注記
CloudStack supports attaching up to 13 data disks to a VM on XenServer hypervisor
versions 6.0 and above. For the VMs on other hypervisor types, the data disk limit
is 6.
18.4.1. 新しいボリュームの作成
ストレージ容量の上限まで、いつでもゲスト仮想マシンにデータディスクボリュームを追加できま
す。CloudStack 管理者とユーザーの両方が、仮想マシンインスタンスにボリュームを追加できます。新しいボ
リュームを作成するとエンティティとして CloudStack に格納されますが、ボリュームをアタッチするまでは、実際
のストレージリソースは物理ストレージデバイスに割り当てられません。この最適化により、最初のアタッチが行
われるとき、ボリュームを使用するゲストに最も近い場所にボリュームが準備されます。
18.4.1.1. Using Local Storage for Data Volumes
You can create data volumes on local storage (supported with XenServer, KVM, and VMware). The
data volume is placed on the same host as the VM instance that is attached to the data volume.
179
第18章 Working With Storage
These local data volumes can be attached to virtual machines, detached, re-attached, and deleted
just as with the other types of data volume.
Local storage is ideal for scenarios where persistence of data volumes and HA is not required. Some
of the benefits include reduced disk I/O latency and cost reduction from using inexpensive local
disks.
In order for local volumes to be used, the feature must be enabled for the zone.
You can create a data disk offering for local storage. When a user creates a new VM, they can select
this disk offering in order to cause the data disk volume to be placed in local storage.
You can not migrate a VM that has a volume in local storage to a different host, nor migrate the
volume itself away to a different host. If you want to put a host into maintenance mode, you must
first stop any VMs with local data volumes on that host.
18.4.1.2. To Create a New Volume
1. ユーザーもしくは管理者として CloudStack ユーザーインターフェイスからログインします。
2. 左側のナビゲーションバーで[Storage]をクリックします。
3. [Select view]ボックスの一覧で[Volumes]を選択します。
4. 新しいボリュームを作成するには[Add Volume]をクリックして次の詳細情報を入力し、[OK]をクリックしま
す。
• Name: 後で見つけられるように、ボリュームに一意の名前を付けます。
• Availability Zone: ストレージの場所です。ボリュームを使用する仮想マシンに近い場所にする必要が
あります。
• Disk Offering: ストレージの特性を選択します。
新しいボリュームがボリューム一覧に表示され、割り当て済みの状態になります。ボリュームデータは
CloudStack に格納されましたが、実際には使用する準備はできていません。
5. ボリュームを使用するには、「ボリュームのアタッチ」に進みます。
18.4.2. Uploading an Existing Volume to a Virtual Machine
Existing data can be made accessible to a virtual machine. This is called uploading a volume to the
VM. For example, this is useful to upload data from a local file system and attach it to a VM. Root
administrators, domain administrators, and end users can all upload existing volumes to VMs.
The upload is performed using HTTP. The uploaded volume is placed in the zone's secondary
storage
You cannot upload a volume if the preconfigured volume limit has already been reached. The
default limit for the cloud is set in the global configuration parameter max.account.volumes, but
administrators can also set per-domain limits that are different from the global default. See Setting
Usage Limits
To upload a volume:
180
ボリュームのアタッチ
1. (Optional) Create an MD5 hash (checksum) of the disk image file that you are going to upload.
After uploading the data disk, CloudStack will use this value to verify that no data corruption
has occurred.
2. Log in to the CloudStack UI as an administrator or user
3. 左側のナビゲーションバーで[Storage]をクリックします。
4. Click Upload Volume.
5. 次の情報を指定します。
• Name and Description. Any desired name and a brief description that can be shown in the UI.
• Availability Zone. Choose the zone where you want to store the volume. VMs running on
hosts in this zone can attach the volume.
• Format. Choose one of the following to indicate the disk image format of the volume.
ハイパーバイザー
Disk Image Format
XenServer
VHD
VMware
OVA
KVM
QCOW2
• URL. The secure HTTP or HTTPS URL that CloudStack can use to access your disk. The type
of file at the URL must match the value chosen in Format. For example, if Format is VHD, the
URL might look like the following:
http://yourFileServerIP/userdata/myDataDisk.vhd
• MD5 checksum. (Optional) Use the hash that you created in step 1.
6. Wait until the status of the volume shows that the upload is complete. Click Instances - Volumes,
find the name you specified in step ???, and make sure the status is Uploaded.
18.4.3. ボリュームのアタッチ
追加のディスクストレージを提供するために、ゲスト仮想マシンにボリュームをアタッチできます。ボリュームをア
タッチするのは、新しいボリュームを初めて作成したとき、既存のボリュームをボリューム間で移動するとき、また
はストレージプール間でボリュームを移行した後です。
1. ユーザーもしくは管理者として CloudStack ユーザーインターフェイスからログインします。
2. 左側のナビゲーションバーで[Storage]をクリックします。
3. [Select view]ボックスの一覧で[Volumes]を選択します。
4.
ボリューム一覧のボリューム名をクリックして[Attach Disk]アイコンをクリックします。
5. ポップアップウィンドウの[Instance]ボックスの一覧で、ボリュームをアタッチする仮想マシンを選択します。
ボリュームのアタッチが許可されているインスタンスのみが表示されます。たとえば、ユーザーにはそのユー
ザーが作成したインスタンスのみが表示されますが、管理者にはより多くの選択肢があります。
181
第18章 Working With Storage
6. [Instances]、インスタンス名、[View Volumes]の順にクリックすると、ボリュームをアタッチ済みかどうかわ
かります。
18.4.4. Detaching and Moving Volumes
注記
�この手順は、ストレージプール間でディスクボリュームを移動する手順とは異なります。「仮
想マシンストレージの移行」を参照してください。
ボリュームは、ゲスト仮想マシンからデタッチして別のゲストにアタッチできます。CloudStack 管理者とユー
ザーの両方が、仮想マシンからボリュームをデタッチしてほかの仮想マシンに移動することができます。
2 つの仮想マシンが異なるクラスターに存在しボリュームが大きい場合は、新しい仮想マシンにボリュームを移
動するのに数分かかる可能性があります。
1. ユーザーもしくは管理者として CloudStack UIからログインします。
2. 左側のナビゲーションバーで[Storage]をクリックし、[Select View]ボックスの一覧で[Volumes]を選択しま
す。ボリュームのアタッチ先の仮想マシンがわかっている場合は、[Instances]、インスタンス名、[View
Volumes]の順にクリックします。
3.
Click the name of the volume you want to detach, then click the Detach Disk button.
4. To move the volume to another VM, follow the steps in ��.
18.4.5. VM Storage Migration
Supported in XenServer, KVM, and VMware.
注記
This procedure is different from moving disk volumes from one VM to another. See
Detaching and Moving Volumes �Detaching and Moving Volumes�.
You can migrate a virtual machine’s root disk volume or any additional data disk volume from one
storage pool to another in the same zone.
You can use the storage migration feature to achieve some commonly desired administration goals,
such as balancing the load on storage pools and increasing the reliability of virtual machines by
moving them away from any storage pool that is experiencing issues.
18.4.5.1. データディスクボリュームの新しいストレージプールへの移行
1. ユーザーもしくは管理者として CloudStack UIからログインします。
2. 仮想マシンからデータディスクをデタッチします。「ボリュームのデタッチと移動」�Detaching and Moving
Volumes�を参照してください(ただし、最後の「再アタッチ」の手順は飛ばして下さい。これは新しいスト
レージへの移行完了後に実施します)。
182
ボリュームのサイズ変更
3. CloudStack API コマンドの migrateVolume を呼び出して、ボリューム ID およびゾーン内の任意のスト
レージプール ID を渡します。
4. ボリュームの状態が移行中から準備完了になるのを待ちます。
5. 新しいストレージサーバーと同じクラスター内の、望ましい仮想マシンにボリュームをアタッチします。「ボ
リュームの\nアタッチ��」を参照してください。
18.4.5.2. 仮想マシンルートボリュームの新しいストレージプールへの移行
ルートディスクボリュームの移行時には、まず仮想マシンを停止して、ユーザーがアクセスできないようにする必
要があります。移行が完了したら、仮想マシンを再起動できます。
1. CloudStack ユーザーインターフェイスに管理者としてログインします。
2. 仮想マシンからデータディスクをデタッチします。「ボリュームのデタッチと移動」�Detaching and Moving
Volumes�を参照してください(ただし、最後の「再アタッチ」の手順は飛ばして下さい。これは新しいスト
レージへの移行完了後に実施します)。
3. 仮想マシンを停止します。
4. CloudStack API コマンドの migrateVirtualMachine を呼び出して、移行する仮想マシンの ID と、同じ
ゾーン内の移行先のホストおよびストレージプールの ID を渡します。
5. 仮想マシンの状態が移行中から停止済みになるのを待ちます。
6. 仮想マシンを再起動します。
18.4.6. ボリュームのサイズ変更
CloudStack provides the ability to resize data disks; CloudStack controls volume size by using disk
offerings. This provides CloudStack administrators with the flexibility to choose how much space
they want to make available to the end users. Volumes within the disk offerings with the same
storage tag can be resized. For example, if you only want to offer 10, 50, and 100 GB offerings,
the allowed resize should stay within those limits. That implies if you define a 10 GB, a 50 GB and
a 100 GB disk offerings, a user can upgrade from 10 GB to 50 GB, or 50 GB to 100 GB. If you
create a custom-sized disk offering, then you have the option to resize the volume by specifying
a new, larger size.
Additionally, using the resizeVolume API, a data volume can be moved from a static disk offering to
a custom disk offering with the size specified. This functionality allows those who might be billing
by certain volume sizes or disk offerings to stick to that model, while providing the flexibility to
migrate to whatever custom size necessary.
This feature is supported on KVM, XenServer, and VMware hosts. However, shrinking volumes is
not supported on VMware hosts.
Before you try to resize a volume, consider the following:
• The VMs associated with the volume are stopped.
• The data disks associated with the volume are removed.
183
第18章 Working With Storage
• When a volume is shrunk, the disk associated with it is simply truncated, and doing so would put
its content at risk of data loss. Therefore, resize any partitions or file systems before you shrink
a data disk so that all the data is moved off from that disk.
To resize a volume:
1. ユーザーもしくは管理者として CloudStack ユーザーインターフェイスからログインします。
2. 左側のナビゲーションバーで[Storage]をクリックします。
3. [Select view]ボックスの一覧で[Volumes]を選択します。
4.
Select the volume name in the Volumes list, then click the Resize Volume button
5. In the Resize Volume pop-up, choose desired characteristics for the storage.
a. If you select Custom Disk, specify a custom size.
b. Click Shrink OK to confirm that you are reducing the size of a volume.
This parameter protects against inadvertent shrinking of a disk, which might lead to the risk
of data loss. You must sign off that you know what you are doing.
6. [OK]をクリックします。
18.4.7. ボリュームの削除とガベージコレクション
ボリュームを削除しても、そのボリュームから作成されたスナップショットは削除されません。
仮想マシンが破棄されるとき、仮想マシンにアタッチされているデータディスクボリュームは削除されません。
ガベージコレクション処理を使用すると、ボリュームは完全に破棄されます。グローバル構成変数の
expunge.delay および expunge.interval を使用して、いつボリュームを物理的に削除するかを指定します。
• expunge.delay:ボリュームが破棄されるまでの経過期間を秒単位で指定します。
• expunge.interval:ガベージコレクションチェックを実行する頻度を指定します。
管理者は、データの保持に関するサイトポリシーに応じて、これらの値を調整する必要があります。
18.5. スナップショットに関わる作業
(サポートされるハイパーバイザー : XenServer、VMware vSphere、およびKVM)
184
Snapshot Job Throttling
CloudStack は、ディスクボリュームのスナップショットをサポートします。スナップショットは、仮想マシンディスク
の一時点でのキャプチャです。メモリと CPU の状態はキャプチャされません。
ルートディスクとデータディスクの両方を含むボリュームのスナップショットを作成することができます。管理者
は、ユーザーごとに格納されるスナップショットの数を制限します。ユーザーは、特定のファイルの復元のため
に、スナップショットから新しいボリュームを作成でき、復元したディスクから起動するために、スナップショットか
らテンプレートを作成できます。スナップショットを定期的に作成するように設定できます。完成したスナップ
ショットはプライマリストレージからセカンダリストレージにコピーされ、削除されるか新しいスナップショットに
よって消去されるまで格納されます。
ユーザーはスナップショットを手動で作成することも、自動定期スナップショットポリシーをセットアップすることも
できます。ユーザーはスナップショットからディスクボリュームを作成することもでき、そのディスクボリュームはほ
かのディスクボリュームのように仮想マシンにアタッチできます。ルートディスクとデータディスクの両方のスナッ
プショットがサポートされます。ただし現在は、復元されたルートディスクから仮想マシンを起動することはでき
ません。ルートディスクのスナップショットから復元したディスクは通常のデータディスクとして扱われ、復元ディ
スクのデータは、ディスクを仮想マシンにアタッチすることでアクセスできます。
完成したスナップショットはプライマリストレージからセカンダリストレージにコピーされ、削除されるか新しいス
ナップショットによって消去されるまで格納されます。
18.5.1. Snapshot Job Throttling
When a snapshot of a virtual machine is requested, the snapshot job runs on the same host where
the VM is running or, in the case of a stopped VM, the host where it ran last. If many snapshots
are requested for VMs on a single host, this can lead to problems with too many snapshot jobs
overwhelming the resources of the host.
To address this situation, the cloud's root administrator can throttle how many snapshot jobs
are executed simultaneously on the hosts in the cloud by using the global configuration setting
concurrent.snapshots.threshold.perhost. By using this setting, the administrator can better ensure
that snapshot jobs do not time out and hypervisor hosts do not experience performance issues due
to hosts being overloaded with too many snapshot requests.
Set concurrent.snapshots.threshold.perhost to a value that represents a best guess about how
many snapshot jobs the hypervisor hosts can execute at one time, given the current resources of
the hosts and the number of VMs running on the hosts. If a given host has more snapshot requests,
the additional requests are placed in a waiting queue. No new snapshot jobs will start until the
number of currently executing snapshot jobs falls below the configured limit.
The admin can also set job.expire.minutes to place a maximum on how long a snapshot request will
wait in the queue. If this limit is reached, the snapshot request fails and returns an error message.
18.5.2. スナップショットの自動作成と保持
(サポートされるハイパーバイザー : XenServer、VMware vSphere、および KVM)
ユーザーは、ディスクの複数のスナップショットを定期的に自動作成するように、定期スナップショットポリシーを
設定でき
ます。スナップショットは、時、日、週、または月単位の間隔で作成できます。スナップショットポリシー
は、ディスクボリュームごとに 1 つセットアップできます。たとえば、毎日 02:30 にスナップショットを作成するよう
にセットアップできます。
スナップショットのスケジュールごとに、保持するスナップショットの数を指定することもできます。保持期限を超
過した古いスナップショットは、自動的に削除されます。このユーザーによって定義された期限は CloudStack
185
第18章 Working With Storage
管理者が設定した値以下である必要があります。詳細は �Globally Configured Limits� を参照してください。制
限はスナップショットの自動作成と保持ポリシーによって作成されたスナップショットのみに適用され、追加で手
動によるスナップショットを作成、保持することができます。
18.5.3. 増分スナップショットとバックアップ
スナップショットは、ディスクがあるプライマリストレージ上に作成されます。作成されたスナップショットはすぐに
セカンダリストレージにバックアップされ、プライマリストレージの容量を有効活用するために、プライマリスト
レージから削除されます。
CloudStack では、一部のハイパーバイザーを対象に増分バックアップを行います。増分バックアップがサポー
トされる場合は、指定間隔で完全バックアップが実行されます。
増分バックアップのサ
ポート
VMware vSphere
Citrix XenServer
KVM
なし
あり
なし
18.5.4. ボリュームの状態
定期スナップショットポリシーによってスナップショットの作成処理を起動する場合は、最後にボリュームのス
ナップショットを作成した後そのボリュームが非アクティブなままであれば、スナップショットの作成処理はスキッ
プされます。ボリュームがデタッチされているか、実行していない仮想マシンにアタッチされている場合、そのボ
リュームは非アクティブとみなされます。CloudStack では、ボリュームが最後に非アクティブになってから、ス
ナップショットが少なくとも 1 つ必ず作成されます。
スナップショットを手動で作成する場合は、ボリュームがアクティブだったかどうかにかかわらず、常にスナップ
ショットが作成されます。
18.5.5. スナップショットの復元
スナップショットの復元には 2 つの方法があります。スナップショットからボリュームを作成できます。このボ
リュームを仮想マシンにマウントし、必要に応じてファイルを復元できます。ルートディスクのスナップショットから
テンプレートを作成できます。このテンプレートから仮想マシンを起動して、ルートディスクを復元できます。
186
ネットワークとトラフィックの管理
CloudStackクラウドでは、セキュリティの設定された共有インフラストラクチャを使用し、プライベートLANでゲ
ストを使用しているというユーザーの認識のもと、ゲスト仮想マシン間で相互に通信できます。\nCloudStack
の仮想ルーターは、ゲストトラフィックのネットワーク設定機能を提供する主要コンポーネントです。
19.1. ゲストトラフィック
A network can carry guest traffic only between VMs within one zone. Virtual machines in different
zones cannot communicate with each other using their IP addresses; they must communicate with
each other by routing through a public IP address.
This figure illustrates a typical guest traffic setup:
The Management Server automatically creates a virtual router for each network. A virtual router is
a special virtual machine that runs on the hosts. Each virtual router has three network interfaces.
Its eth0 interface serves as the gateway for the guest traffic and has the IP address of 10.1.1.1. Its
eth1 interface is used by the system to configure the virtual router. Its eth2 interface is assigned
a public IP address for public traffic.
The virtual router provides DHCP and will automatically assign an IP address for each guest VM
within the IP range assigned for the network. The user can manually reconfigure guest VMs to
assume different IP addresses.
Source NAT is automatically configured in the virtual router to forward outbound traffic for all guest
VMs
19.2. Networking in a Pod
The figure below illustrates network setup within a single pod. The hosts are connected to a podlevel switch. At a minimum, the hosts should have one physical uplink to each switch. Bonded NICs
are supported as well. The pod-level switch is a pair of redundant gigabit switches with 10 G uplinks.
187
第19章ネットワークとトラフィックの管理
Servers are connected as follows:
• Storage devices are connected to only the network that carries management traffic.
• Hosts are connected to networks for both management traffic and public traffic.
• Hosts are also connected to one or more networks carrying guest traffic.
We recommend the use of multiple physical Ethernet cards to implement each network interface
as well as redundant switch fabric in order to maximize throughput and improve reliability.
188
Networking in a Zone
19.3. Networking in a Zone
The following figure illustrates the network setup within a single zone.
A firewall for management traffic operates in the NAT mode. The network typically is assigned IP
addresses in the 192.168.0.0/16 Class B private address space. Each pod is assigned IP addresses
in the 192.168.*.0/24 Class C private address space.
Each zone has its own set of public IP addresses. Public IP addresses from different zones do not
overlap.
19.4. 基本ゾーンの物理ネットワーク構成
基本ネットワークの場合は、物理ネットワークの構成はごく簡単です。構成する必要があるのは、ゲスト仮想マシ
ンが生成するトラフィックを伝送するための1つのゲストネットワークだけです。CloudStackに初めてゾーンを追
加するときは、Add Zone の画面からゲストネットワークをセットアップします。
189
第19章ネットワークとトラフィックの管理
19.5. Advanced Zone Physical Network Configuration
Within a zone that uses advanced networking, you need to tell the Management Server how the
physical network is set up to carry different kinds of traffic in isolation.
19.5.1. 拡張ゾーンのゲストトラフィックの構成
次の手順は、CloudStack ユーザーインターフェイスにログオン済みであることを前提としています。基本ゲスト
ネットワークを構成するには、次の手順に従います。
1. 左側のナビゲーションバーで [Infrastructure] をクリックします。[Zones] で [View More] をクリックし、ネッ
トワークを追加するゾーンを選択します。
2. [Network] タブをクリックします。
3. [Add guest network]をクリックします。
ゲストネットワークの追加ウインドウが表示されます。
4. 次の情報を指定します。
• Name : ネットワークの名前です。これはユーザーに表示されます。
• Display Text : ネットワークの説明です。これはユーザーに表示されます。
• Zone : ゲストネットワークを構成したいゾーン名です。
• Network offering : もし管理者が複数のネットワークオファリングを設定している場合、利用したいネッ
トワークオファリングを選択します。
• Guest Gateway : ゲストが使用するゲートウェイです。
190
拡張ゾーンのパブリックトラフィックの構成
• Guest Netmask : ゲストの使用するサブネット上で使用されるネットマスクです。
5. 「OK」をクリックします。
19.5.2. 拡張ゾーンのパブリックトラフィックの構成
拡張ネットワーク設定を使用するゾーンでは、インターネットトラフィックの IP アドレスの範囲を少なくとも 1 つ構
成する必要があります。
19.6. Using Multiple Guest Networks
In zones that use advanced networking, additional networks for guest traffic may be added at any
time after the initial installation. You can also customize the domain name associated with the
network by specifying a DNS suffix for each network.
A VM's networks are defined at VM creation time. A VM cannot add or remove networks after it has
been created, although the user can go into the guest and remove the IP address from the NIC
on a particular network.
Each VM has just one default network. The virtual router's DHCP reply will set the guest's default
gateway as that for the default network. Multiple non-default networks may be added to a guest
in addition to the single, required default network. The administrator can control which networks
are available as the default network.
Additional networks can either be available to all accounts or be assigned to a specific account.
Networks that are available to all accounts are zone-wide. Any user with access to the zone can
create a VM with access to that network. These zone-wide networks provide little or no isolation
between guests.Networks that are assigned to a specific account provide strong isolation.
19.6.1. ゲストネットワークの追加
1. 管理者もしくはエンドユーザーとして CloudStack UI にログインします。
2. 左側のナビゲーションから [Network] を選択します。
3. [Add guest network] をクリックし、以下の情報を入力します。
• Name : ネットワークの名前です。この名前はユーザーから見ることができます。
• Display Text : ネットワークの詳細情報です。この情報はユーザーから見ることができます。
• Zone : ネットワークを適用するゾーンの名前です。各ゾーンはゲストネットワークに対し違うIPレンジを
持ったブロードキャストドメインに属します。管理者は各ゾーンに対しIPレンジを設定する必要がありま
す。
• Network offering : もし管理者によって複数のネットワークオファリングが設定されている場合、ここで
利用したいネットワークを1つ選択します。
• Guest Gateway : ゲストVMが利用するゲートウェイを設定します。
• Guest Netmask : ゲストVMが利用するサブネットのネットマスクを設定します。
4. [Create] をクリックします。
191
第19章ネットワークとトラフィックの管理
19.6.2. ゲストネットワーク上のネットワークオファリングの変更
ユーザーまたは管理者は、既存のゲストネットワークに関連付けられているネットワークオファリングを変更でき
ます。
• 管理者もしくはエンドユーザーとして CloudStack UI にログインします。
• If you are changing from a network offering that uses the CloudStack virtual router to one that
uses external devices as network service providers, you must first stop all the VMs on the network.
See "Stopping and Starting Virtual Machines" in the Administrator's Guide.
• 左側のナビゲーションから [Network] を選択します。
• Click the name of the network you want to modify.
•
In the Details tab, click Edit.
• [Network Offering]ボックスの一覧で新しいネットワークオファリングを選択して、[Apply]をクリックします。
• A prompt is displayed asking whether you want to keep the existing CIDR. This is to let you know
that if you change the network offering, the CIDR will be affected. Choose No to proceed with
the change.
• Wait for the update to complete. Don’t try to restart VMs until the network change is complete.
• If you stopped any VMs, restart them.
19.7. セキュリティグループ
19.7.1. セキュリティグループについて
セキュリティグループは仮想マシンに対するトラフィックを分離する方法を提供します。セキュリティグループは
仮想マシンのグループで、受信規則および送信規則と呼ばれる規則セットに基づいて、受信および送信トラ
フィックをフィルターします。仮想マシンとの通信を試行するIPアドレスに基づき、これらの規則によってネット
ワークトラフィックがフィルターされます。セキュリティグループは、基本ネットワーク設定を使用するゾーンで特
に便利です。基本ゾーンでは、すべてのゲスト仮想マシンに対して単一のゲストネットワーク提供されるからで
す。拡張ゾーンでは、KVMハイパーバイザーでのみセキュリティグループがサポートされます。
注記
拡張ネットワークを使用すゾーンでは、代わりに複数のゲストネットワークを作成することで、
仮想マシンへのトラフィックを隔離します。
各CloudStackアカウントには、すべての受信トラフィックを拒否し、すべての送信トラフィックを許可するデフォ
ルトのセキュリティグループが用意されています。すべての新しい仮想マシンが望ましい規則セットを継承する
ように、デフォルトのセキュリティグループを変更できます。
CloudStackのユーザーは、任意の数のセキュリティグループを追加できます。新しい仮想マシンには、ユー
ザー定義のセキュリティグループが別に指定されていない限り、デフォルトのセキュリティグループが起動時に
割り当てられます。仮想マシンは、任意の数のセキュリティグループのメンバーになることができます。仮想マシ
ンをセキュリティグループに割り当てると、仮想マシンは有効である限りずっとそのグループに属します。実行中
の仮想マシンを別のセキュリティグループに移動することはできません。
192
セキュリティグループの追加
セキュリティグループは、任意の数の受信規則および送信規則を削除または追加することで変更できます。変
更後の新しい規則は、実行中または停止中にかかわらず、グループ内のすべての仮想マシンに適用されます。
受信規則を指定しない場合は、送信規則によって送信が許可されているトラフィックへの応答を除いて、トラ
フィックの受信は許可されません。
19.7.2. セキュリティグループの追加
ユーザーもしくは管理者は新しいセキュリティグループを定義することができます。
1. 管理者もしくはエンドユーザーとして CloudStack UI にログインします。
2. 左側のナビゲーションバーで[Network]をクリックします。
3. [Select view]ボックスの一覧で[Security Groups]を選択します。
4. [Add Security Group]をクリックします。
5. 名前と説明を入力します。
6. [OK]をクリックします。
新しいセキュリティグループが[Security Groups Details]タブに表示されます。
7. セキュリティグループを使いやすくするには、「セキュリティグループへの受信規則と送信規則の追加」に進
みます。
19.7.3. Security Groups in Advanced Zones (KVM Only)
CloudStack provides the ability to use security groups to provide isolation between guests on a
single shared, zone-wide network in an advanced zone where KVM is the hypervisor. Using security
groups in advanced zones rather than multiple VLANs allows a greater range of options for setting
up guest isolation in a cloud.
Limitations
The following are not supported for this feature:
• Two IP ranges with the same VLAN and different gateway or netmask in security group-enabled
shared network.
• Two IP ranges with the same VLAN and different gateway or netmask in account-specific shared
networks.
• Multiple VLAN ranges in security group-enabled shared network.
• Multiple VLAN ranges in account-specific shared networks.
Security groups must be enabled in the zone in order for this feature to be used.
19.7.4. Enabling Security Groups
In order for security groups to function in a zone, the security groups feature must first be enabled
for the zone. The administrator can do this when creating a new zone, by selecting a network
193
第19章ネットワークとトラフィックの管理
offering that includes security groups. The procedure is described in Basic Zone Configuration in
the Advanced Installation Guide. The administrator can not enable security groups for an existing
zone, only when creating a new zone.
19.7.5. Adding Ingress and Egress Rules to a Security Group
1. 管理者もしくはエンドユーザーとして CloudStack UI にログインします。
2. 左側のナビゲーションバーで[Network]をクリックします。
3. In Select view, choose Security Groups, then click the security group you want .
4. To add an ingress rule, click the Ingress Rules tab and fill out the following fields to specify
what network traffic is allowed into VM instances in this security group. If no ingress rules are
specified, then no traffic will be allowed in, except for responses to any traffic that has been
allowed out through an egress rule.
• Add by CIDR/Account. Indicate whether the source of the traffic will be defined by IP address
(CIDR) or an existing security group in a CloudStack account (Account). Choose Account if
you want to allow incoming traffic from all VMs in another security group
• Protocol. The networking protocol that sources will use to send traffic to the security group.
TCP and UDP are typically used for data exchange and end-user communications. ICMP is
typically used to send error messages or network monitoring data.
• Start Port, End Port. (TCP, UDP only) A range of listening ports that are the destination for
the incoming traffic. If you are opening a single port, use the same number in both fields.
• ICMP Type, ICMP Code. (ICMP only) The type of message and error code that will be
accepted.
• CIDR. (Add by CIDR only) To accept only traffic from IP addresses within a particular address
block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of
the incoming traffic. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
• Account, Security Group. (Add by Account only) To accept only traffic from another security
group, enter the CloudStack account and name of a security group that has already been
defined in that account. To allow traffic between VMs within the security group you are
editing now, enter the same name you used in step 7.
The following example allows inbound HTTP access from anywhere:
194
External Firewalls and Load Balancers
5. To add an egress rule, click the Egress Rules tab and fill out the following fields to specify what
type of traffic is allowed to be sent out of VM instances in this security group. If no egress rules
are specified, then all traffic will be allowed out. Once egress rules are specified, the following
types of traffic are allowed out: traffic specified in egress rules; queries to DNS and DHCP
servers; and responses to any traffic that has been allowed in through an ingress rule
• Add by CIDR/Account. Indicate whether the destination of the traffic will be defined by IP
address (CIDR) or an existing security group in a CloudStack account (Account). Choose
Account if you want to allow outgoing traffic to all VMs in another security group.
• Protocol. The networking protocol that VMs will use to send outgoing traffic. TCP and UDP
are typically used for data exchange and end-user communications. ICMP is typically used
to send error messages or network monitoring data.
• Start Port, End Port. (TCP, UDP only) A range of listening ports that are the destination for
the outgoing traffic. If you are opening a single port, use the same number in both fields.
• ICMP Type, ICMP Code. (ICMP only) The type of message and error code that will be sent
• CIDR. (Add by CIDR only) To send traffic only to IP addresses within a particular address
block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of
the destination. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
• Account, Security Group. (Add by Account only) To allow traffic to be sent to another security
group, enter the CloudStack account and name of a security group that has already been
defined in that account. To allow traffic between VMs within the security group you are
editing now, enter its name.
6. [Add]をクリックします。
19.8. External Firewalls and Load Balancers
CloudStack is capable of replacing its Virtual Router with an external Juniper SRX device and an
optional external NetScaler or F5 load balancer for gateway and load balancing services. In this
case, the VMs use the SRX as their gateway.
19.8.1. About Using a NetScaler Load Balancer
Citrix NetScaler is supported as an external network element for load balancing in zones that use
advanced networking (also called advanced zones). Set up an external load balancer when you
want to provide load balancing through means other than CloudStack’s provided virtual router.
The NetScaler can be set up in direct (outside the firewall) mode. It must be added before any load
balancing rules are deployed on guest VMs in the zone.
The functional behavior of the NetScaler with CloudStack is the same as described in the
CloudStack documentation for using an F5 external load balancer. The only exception is that the
F5 supports routing domains, and NetScaler does not. NetScaler can not yet be used as a firewall.
The Citrix NetScaler comes in three varieties. The following table summarizes how these variants
are treated in CloudStack.
195
第19章ネットワークとトラフィックの管理
NetScaler ADC Type
Description of Capabilities
CloudStack Supported
Features
MPX
Physical appliance. Capable
of deep packet inspection.
Can act as application firewall
and load balancer
In advanced zones, load
balancer functionality fully
supported without limitation.
In basic zones, static NAT,
elastic IP (EIP), and elastic
load balancing (ELB) are also
provided
VPX
Virtual appliance. Can run as
VM on XenServer, ESXi, and
Hyper-V hypervisors. Same
functionality as MPX
Supported only on ESXi.
Same functional support as
for MPX. CloudStack will treat
VPX and MPX as the same
device type
SDX
Physical appliance. Can
create multiple fully isolated
VPX instances on a single
appliance to support multitenant usage
CloudStack will dynamically
provision, configure, and
manage the lifecycle of
VPX instances on the SDX.
Provisioned instances are
added into CloudStack
automatically – no manual
configuration by the
administrator is required.
Once a VPX instance is added
into CloudStack, it is treated
the same as a VPX on an ESXi
host.
19.8.2. Configuring SNMP Community String on a RHEL Server
The SNMP Community string is similar to a user id or password that provides access to a network
device, such as router. This string is sent along with all SNMP requests. If the community string is
correct, the device responds with the requested information. If the community string is incorrect,
the device discards the request and does not respond.
The NetScaler device uses SNMP to communicate with the VMs. You must install SNMP and
configure SNMP Community string for a secure communication between the NetScaler device and
the RHEL machine.
1. Ensure that you installed SNMP on RedHat. If not, run the following command:
yum install net-snmp-utils
2. Edit the /etc/snmp/snmpd.conf file to allow the SNMP polling from the NetScaler device.
a. Map the community name into a security name (local and mynetwork, depending on where
the request is coming from):
196
外部ファイアウォールとロードバランサーの初期セットアップ
注記
Use a strong password instead of public when you edit the following table.
#
com2sec
com2sec
sec.name
local
mynetwork
source
localhost
0.0.0.0
community
public
public
注記
Setting to 0.0.0.0 allows all IPs to poll the NetScaler server.
b. Map the security names into group names:
#
group
group
group
group
group.name
MyRWGroup
MyRWGroup
MyROGroup
MyROGroup
sec.model
v1
v2c
v1
v2c
sec.name
local
local
mynetwork
mynetwork
c. Create a view to allow the groups to have the permission to:
incl/excl subtree mask view all included .1
d. Grant access with different write permissions to the two groups to the view you created.
# context
access
access
sec.model
MyROGroup ""
MyRWGroup ""
sec.level
any noauth
any noauth
prefix
exact
exact
read
all
all
write
none
all
notif
none
all
3. Unblock SNMP in iptables.
iptables -A INPUT -p udp --dport 161 -j ACCEPT
4. Start the SNMP service:
service snmpd start
5. Ensure that the SNMP service is started automatically during the system startup:
chkconfig snmpd on
19.8.3. 外部ファイアウォールとロードバランサーの初期セットアップ
When the first VM is created for a new account, CloudStack programs the external firewall and load
balancer to work with the VM. The following objects are created on the firewall:
197
第19章ネットワークとトラフィックの管理
• A new logical interface to connect to the account's private VLAN. The interface IP is always the
first IP of the account's private subnet (e.g. 10.1.1.1).
• A source NAT rule that forwards all outgoing traffic from the account's private VLAN to the public
Internet, using the account's public IP address as the source address
• A firewall filter counter that measures the number of bytes of outgoing traffic for the account
The following objects are created on the load balancer:
• A new VLAN that matches the account's provisioned Zone VLAN
• A self IP for the VLAN. This is always the second IP of the account's private subnet (e.g. 10.1.1.2).
19.8.4. Ongoing Configuration of External Firewalls and Load
Balancers
Additional user actions (e.g. setting a port forward) will cause further programming of the firewall
and load balancer. A user may request additional public IP addresses and forward traffic received
at these IPs to specific VMs. This is accomplished by enabling static NAT for a public IP address,
assigning the IP to a VM, and specifying a set of protocols and port ranges to open. When a static
NAT rule is created, CloudStack programs the zone's external firewall with the following objects:
• A static NAT rule that maps the public IP address to the private IP address of a VM.
• A security policy that allows traffic within the set of protocols and port ranges that are specified.
• A firewall filter counter that measures the number of bytes of incoming traffic to the public IP.
The number of incoming and outgoing bytes through source NAT, static NAT, and load balancing
rules is measured and saved on each external element. This data is collected on a regular basis
and stored in the CloudStack database.
19.8.5. Configuring AutoScale
AutoScaling allows you to scale your back-end services or application VMs up or down seamlessly
and automatically according to the conditions you define. With AutoScaling enabled, you can
ensure that the number of VMs you are using seamlessly scale up when demand increases, and
automatically decreases when demand subsides. Using AutoScaling, you can automatically shut
down instances you don't need, or launch new instances, depending on demand.
NetScaler AutoScaling is designed to seamlessly launch or terminate VMs based on user-defined
conditions. Conditions for triggering a scaleup or scaledown action can vary from a simple use case
like monitoring the CPU usage of a server to a complex use case of monitoring a combination of
server's responsiveness and its CPU usage. For example, you can configure AutoScaling to launch
an additional VM whenever CPU usage exceeds 80 percent for 15 minutes, or to remove a VM
whenever CPU usage is less than 20 percent for 30 minutes.
CloudStack uses the NetScaler load balancer to monitor all aspects of a system's health and work
in unison with CloudStack to initiate scale-up or scale-down actions.
198
Configuring AutoScale
注記
AutoScale is supported on NetScaler Release 10 Build 73.e and beyond.
事前準備
Before you configure an AutoScale rule, consider the following:
• Ensure that the necessary template is prepared before configuring AutoScale. When a VM is
deployed by using a template and when it comes up, the application should be up and running.
注記
If the application is not running, the NetScaler device considers the VM
as ineffective and continues provisioning the VMs unconditionally until the
resource limit is exhausted.
• Deploy the templates you prepared. Ensure that the applications come up on the first boot and
is ready to take the traffic. Observe the time requires to deploy the template. Consider this time
when you specify the quiet time while configuring AutoScale.
• The AutoScale feature supports the SNMP counters that can be used to define conditions
for taking scale up or scale down actions. To monitor the SNMP-based counter, ensure that
the SNMP agent is installed in the template used for creating the AutoScale VMs, and the
SNMP operations work with the configured SNMP community and port by using standard SNMP
managers. For example, see �Configuring SNMP Community String on a RHEL Server� to configure
SNMP on a RHEL machine.
• Ensure that the endpointe.url parameter present in the Global Settings is set to the
Management Server API URL. For example, http://10.102.102.22:8080/client/api. In a multinode Management Server deployment, use the virtual IP address configured in the load balancer
for the management server’s cluster. Additionally, ensure that the NetScaler device has access
to this IP address to provide AutoScale support.
If you update the endpointe.url, disable the AutoScale functionality of the load balancer rules
in the system, then enable them back to reflect the changes. For more information see Updating
an AutoScale Configuration
• If the API Key and Secret Key are regenerated for an AutoScale user, ensure that the AutoScale
functionality of the load balancers that the user participates in are disabled and then enabled to
reflect the configuration changes in the NetScaler.
• In an advanced Zone, ensure that at least one VM should be present before configuring a load
balancer rule with AutoScale. Having one VM in the network ensures that the network is in
implemented state for configuring AutoScale.
構成
以下の要素を指定します。
199
第19章ネットワークとトラフィックの管理
• Template: A template consists of a base OS image and application. A template is used to provision
the new instance of an application on a scaleup action. When a VM is deployed from a template,
the VM can start taking the traffic from the load balancer without any admin intervention. For
example, if the VM is deployed for a Web service, it should have the Web server running, the
database connected, and so on.
• Compute offering: A predefined set of virtual hardware attributes, including CPU speed, number
of CPUs, and RAM size, that the user can select when creating a new virtual machine instance.
Choose one of the compute offerings to be used while provisioning a VM instance as part of
scaleup action.
• Min Instance: The minimum number of active VM instances that is assigned to a load balancing
rule. The active VM instances are the application instances that are up and serving the traffic,
and are being load balanced. This parameter ensures that a load balancing rule has at least the
configured number of active VM instances are available to serve the traffic.
200
Configuring AutoScale
注記
If an application, such as SAP, running on a VM instance is down for some reason,
the VM is then not counted as part of Min Instance parameter, and the AutoScale
feature initiates a scaleup action if the number of active VM instances is below
the configured value. Similarly, when an application instance comes up from
its earlier down state, this application instance is counted as part of the active
instance count and the AutoScale process initiates a scaledown action when the
active instance count breaches the Max instance value.
• Max Instance: Maximum number of active VM instances that should be assigned to a load
balancing rule. This parameter defines the upper limit of active VM instances that can be assigned
to a load balancing rule.
Specifying a large value for the maximum instance parameter might result in provisioning large
number of VM instances, which in turn leads to a single load balancing rule exhausting the VM
instances limit specified at the account or domain level.
注記
If an application, such as SAP, running on a VM instance is down for some reason,
the VM is not counted as part of Max Instance parameter. So there may be
scenarios where the number of VMs provisioned for a scaleup action might be
more than the configured Max Instance value. Once the application instances in
the VMs are up from an earlier down state, the AutoScale feature starts aligning
to the configured Max Instance value.
Specify the following scale-up and scale-down policies:
• Duration: The duration, in seconds, for which the conditions you specify must be true to trigger
a scaleup action. The conditions defined should hold true for the entire duration you specify for
an AutoScale action to be invoked.
• Counter: The performance counters expose the state of the monitored instances. By default,
CloudStack offers four performance counters: Three SNMP counters and one NetScaler counter.
The SNMP counters are Linux User CPU, Linux System CPU, and Linux CPU Idle. The NetScaler
counter is ResponseTime. The root administrator can add additional counters into CloudStack
by using the CloudStack API.
• Operator: The following five relational operators are supported in AutoScale feature: Greater
than, Less than, Less than or equal to, Greater than or equal to, and Equal to.
• Threshold: Threshold value to be used for the counter. Once the counter defined above breaches
the threshold value, the AutoScale feature initiates a scaleup or scaledown action.
• Add: Click Add to add the condition.
Additionally, if you want to configure the advanced settings, click Show advanced settings, and
specify the following:
201
第19章ネットワークとトラフィックの管理
• Polling interval: Frequency in which the conditions, combination of counter, operator and
threshold, are to be evaluated before taking a scale up or down action. The default polling interval
is 30 seconds.
• Quiet Time: This is the cool down period after an AutoScale action is initiated. The time includes
the time taken to complete provisioning a VM instance from its template and the time taken by
an application to be ready to serve traffic. This quiet time allows the fleet to come up to a stable
state before any action can take place. The default is 300 seconds.
• Destroy VM Grace Period: The duration in seconds, after a scaledown action is initiated, to wait
before the VM is destroyed as part of scaledown action. This is to ensure graceful close of any
pending sessions or transactions being served by the VM marked for destroy. The default is 120
seconds.
• Security Groups: Security groups provide a way to isolate traffic to the VM instances. A security
group is a group of VMs that filter their incoming and outgoing traffic according to a set of rules,
called ingress and egress rules. These rules filter network traffic according to the IP address that
is attempting to communicate with the VM.
• Disk Offerings: A predefined set of disk size for primary data storage.
• SNMP Community: The SNMP community string to be used by the NetScaler device to query the
configured counter value from the provisioned VM instances. Default is public.
• SNMP Port: The port number on which the SNMP agent that run on the provisioned VMs is
listening. Default port is 161.
• User: This is the user that the NetScaler device use to invoke scaleup and scaledown API calls
to the cloud. If no option is specified, the user who configures AutoScaling is applied. Specify
another user name to override.
• Apply: Click Apply to create the AutoScale configuration.
Disabling and Enabling an AutoScale Configuration
If you want to perform any maintenance operation on the AutoScale VM instances, disable the
AutoScale configuration. When the AutoScale configuration is disabled, no scaleup or scaledown
action is performed. You can use this downtime for the maintenance activities. To disable the
AutoScale configuration, click the Disable AutoScale
button.
The button toggles between enable and disable, depending on whether AutoScale is currently
enabled or not. After the maintenance operations are done, you can enable the AutoScale
configuration back. To enable, open the AutoScale configuration page again, then click the Enable
AutoScale
button.
Updating an AutoScale Configuration
You can update the various parameters and add or delete the conditions in a scaleup or scaledown
rule. Before you update an AutoScale configuration, ensure that you disable the AutoScale load
balancer rule by clicking the Disable AutoScale button.
After you modify the required AutoScale parameters, click Apply. To apply the new AutoScale
policies, open the AutoScale configuration page again, then click the Enable AutoScale button.
202
負荷分散のルール
Runtime Considerations
• An administrator should not assign a VM to a load balancing rule which is configured for
AutoScale.
• Before a VM provisioning is completed if NetScaler is shutdown or restarted, the provisioned VM
cannot be a part of the load balancing rule though the intent was to assign it to a load balancing
rule. To workaround, rename the AutoScale provisioned VMs based on the rule name or ID so at
any point of time the VMs can be reconciled to its load balancing rule.
• Making API calls outside the context of AutoScale, such as destroyVM, on an autoscaled VM
leaves the load balancing configuration in an inconsistent state. Though VM is destroyed from
the load balancer rule, NetScaler continues to show the VM as a service assigned to a rule.
19.9. 負荷分散のルール
CloudStack ユーザーもしくは管理者はパブリックIPから1つもしくは複数の仮想マシンへの受信トラフィックの
分散のため負荷分散ルールを作成するかもしれません。ユーザーは特定のアルゴリズムに基づきルールを作
成し仮想マシンのセットに対して割り当てます。
注記
もし、負荷分散ルールを作成する際 NetScaler のような外部デバイスを含んだネットワーク
サービスオファリングを利用していた場合、また後にネットワークサービスオファリングを
CloudStack の仮想ルーターを利用するよう変更を加える場合、継続して機能を利用するた
めには全ての負荷分散ルールに対しファイアウォールルールを追加しなければなりません。
19.9.1. ロードバランサールールの追加
1. 管理者もしくはエンドユーザーとして CloudStack UI にログインします。
2. 左側のナビゲーションから [Network] を選択します。
3. トラフィックの負荷分散をしたいしたいネットワークの名前をクリックします。
4. [View IP Addresses] をクリックします。
5. ルールを作成したい IP アドレスをクリックし、[Configuration] タブをクリックします。
6. 構成図のロードバランサーをクリックし、[View All] をクリックします。
基本ゾーンでは IP アドレスを選択せずに負荷分散ルールを作成することもできます。 CloudStack は負荷
分散ルールの作成時に内部的に IP を割り当て、ルール作成時に割り当てられた IP アドレスがリスト表示
されます。
ネットワークの名前を選択し、[Add Load Balancer] タブをクリックします。詳細は 7 を参照してください。
7. 次の項目を入力します。
• Name : 負荷分散ルールの名前です。
• Public Port : 負荷分散のための入力トラフィックを受信するポート番号です。
203
第19章ネットワークとトラフィックの管理
• Private Port : 仮想マシンがトラフィックを受信するポート番号です。
• Algorithm : CloudStack で利用したい負荷分散アルゴリズムを選択します。 CloudStack では様々な
アルゴリズムをサポートしています。これらのアルゴリズムに関して詳細を知りたい場合はインターネット
上でより多くの情報を取得できます。
• Stickiness :
(オプション) [Configure] をクリックし、スティックネスポリシーを選択します。詳細は
「Sticky Session Policies for Load Balancer Rules」を参照してください。
• AutoScale: [Configure] をクリックし �Configuring AutoScale� に従ってオートスケールの設定を完了
します。
8. [Add VMs] をクリックした後入力トラフィックの負荷を分散する2つ以上の仮想マシンを選択し、[Apply] を
クリックします。
新しい負荷分散ルールがリスト表示され、IP アドレスに対する負荷分散ルールを引き続き追加することが
できます。
19.9.2. Sticky Session Policies for Load Balancer Rules
Sticky sessions are used in Web-based applications to ensure continued availability of information
across the multiple requests in a user's session. For example, if a shopper is filling a cart, you need
to remember what has been purchased so far. The concept of "stickiness" is also referred to as
persistence or maintaining state.
Any load balancer rule defined in CloudStack can have a stickiness policy. The policy consists of
a name, stickiness method, and parameters. The parameters are name-value pairs or flags, which
are defined by the load balancer vendor. The stickiness method could be load balancer-generated
cookie, application-generated cookie, or source-based. In the source-based method, the source IP
address is used to identify the user and locate the user’s stored data. In the other methods, cookies
are used. The cookie generated by the load balancer or application is included in request and
response URLs to create persistence. The cookie name can be specified by the administrator or
automatically generated. A variety of options are provided to control the exact behavior of cookies,
such as how they are generated and whether they are cached.
For the most up to date list of available stickiness methods, see the CloudStack UI or call
listNetworks and check the SupportedStickinessMethods capability.
19.10. Guest IP Ranges
The IP ranges for guest network traffic are set on a per-account basis by the user. This allows
the users to configure their network in a fashion that will enable VPN linking between their guest
network and their clients.
19.11. 新しい IP アドレスの取得
1. 管理者もしくはエンドユーザーとして CloudStack UI にログインします。
2. 左側のナビゲーションから [Network] を選択します。
3. 変更したいネットワークの名前をクリックします。
4. [View IP Addresses] をクリックします。
204
IP アドレスの開放
5. [Acquire New IP] をクリックし、確認ダイアログで [Yes] をクリックします。
一般的に
IP
アドレスは有限のリソースであるため確認を求められます。しばらくするとステータスが
「Allocated」となり新しい IP アドレスが表示されます。これで新しい IP アドレスをポートフォワーディングや
スタティック NAT ルールに利用できます。
19.12. IP アドレスの開放
When the last rule for an IP address is removed, you can release that IP address. The IP address
still belongs to the VPC; however, it can be picked up for any guest network again.
1. 管理者またはユーザーとして CloudStack ユーザーインターフェイスにログオンします。
2. 左側のナビゲーションから [Network] を選択します。
3. 変更したいネットワークの名前をクリックします。
4. [View IP Addresses] をクリックします。
5. 開放したい IP アドレスをクリックします。
6.
Click the Release IP button.
19.13. 静的 NAT
A static NAT rule maps a public IP address to the private IP address of a VM in order to allow Internet
traffic into the VM. The public IP address always remains the same, which is why it is called “static”
NAT. This section tells how to enable or disable static NAT for a particular IP address.
19.13.1. スタティック NAT の有効化、無効化
もし、すでにポートフォワーディングのルールが IP アドレスに反映されている場合、IP に対してスタティック NAT
を有効化することができません。
仮想マシンがいくつかのネットワークに所属している場合、スタティック NAT のルールはデフォルトネットワーク
でしか機能しません。
1. 管理者もしくはエンドユーザーとして CloudStack UI にログインします。
2. 左側のナビゲーションから [Network] を選択します。
3. 変更したいネットワークの名前をクリックします。
4. [View IP Addresses] をクリックします。
5. 変更したい IP アドレスをクリックします。
6.
Click the Static NAT
button.
The button toggles between Enable and Disable, depending on whether static NAT is currently
enabled for the IP address.
7. If you are enabling static NAT, a dialog appears where you can choose the destination VM and
click Apply.
205
第19章ネットワークとトラフィックの管理
19.14. IP Forwarding and Firewalling
By default, all incoming traffic to the public IP address is rejected. All outgoing traffic from the
guests is also blocked by default.
To allow outgoing traffic, follow the procedure in �Creating Egress Firewall Rules in an Advanced
Zone�.
To allow incoming traffic, users may set up firewall rules and/or port forwarding rules. For example,
you can use a firewall rule to open a range of ports on the public IP address, such as 33 through 44.
Then use port forwarding rules to direct traffic from individual ports within that range to specific
ports on user VMs. For example, one port forwarding rule could route incoming traffic on the public
IP's port 33 to port 100 on one user VM's private IP. For more information, see �� and ��.
19.14.1. Creating Egress Firewall Rules in an Advanced Zone
注記
The egress firewall rules are supported only on virtual routers.
The egress traffic originates from a private network to a public network, such as the Internet. By
default, the egress traffic is blocked, so no outgoing traffic is allowed from a guest network to the
Internet. However, you can control the egress traffic in an Advanced zone by creating egress firewall
rules. When an egress firewall rule is applied, the traffic specific to the rule is allowed and the
remaining traffic is blocked. When all the firewall rules are removed the default policy, Block, is
applied.
Consider the following scenarios to apply egress firewall rules:
• Allow the egress traffic from specified source CIDR. The Source CIDR is part of guest network
CIDR.
• Allow the egress traffic with destination protocol TCP,UDP,ICMP, or ALL.
• Allow the egress traffic with destination protocol and port range. The port range is specified for
TCP, UDP or for ICMP type and code.
To configure an egress firewall rule:
1. 管理者またはユーザーとして CloudStack ユーザーインターフェイスにログオンします。
2. 左側のナビゲーションから [Network] を選択します。
3. In Select view, choose Guest networks, then click the Guest network you want.
4. To add an egress rule, click the Egress rules tab and fill out the following fields to specify what
type of traffic is allowed to be sent out of VM instances in this guest network:
206
ファイアウォールルール
• CIDR: (Add by CIDR only) To send traffic only to the IP addresses within a particular address
block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of
the destination. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
• Protocol: The networking protocol that VMs uses to send outgoing traffic. The TCP and UDP
protocols are typically used for data exchange and end-user communications. The ICMP
protocol is typically used to send error messages or network monitoring data.
• Start Port, End Port: (TCP, UDP only) A range of listening ports that are the destination for
the outgoing traffic. If you are opening a single port, use the same number in both fields.
• ICMP Type, ICMP Code: (ICMP only) The type of message and error code that are sent.
5. [Add]をクリックします。
19.14.2. ファイアウォールルール
デフォルトではパブリック IP に対する全ての入力トラフィックはファイアウォールで排除されます。外部からのトラ
フィックを許可するには特定のファイアウォールルールによりファイアウォールのポートを開放することができま
す。また、オプションとして接続元 IP をフィルタリングするため CIDR を指定することもできます。これは特定の
IP アドレスからの入力リクエストのみを許可する場合に有効です。
エラスティックな IP アドレスに対してポートを開放するためにファイアウォールルールを利用することはできませ
ん。エラスティック IP を使用している際は外部からのアクセスは代わりにセキュリティグループにより制御しま
す。詳細は �� を参照してください。
拡張ゾーンでは仮想ルーターを用いて出力用ファイアウォールルールを作成できます。詳細は
Egress Firewall Rules in an Advanced Zone� を参照してください。
�Creating
Firewall rules can be created using the Firewall tab in the Management Server UI. This tab is not
displayed by default when CloudStack is installed. To display the Firewall tab, the CloudStack
administrator must set the global configuration parameter firewall.rule.ui.enabled to "true."
ファイアウォールルールの作成方法
1. 管理者もしくはエンドユーザーとして CloudStack UI にログインします。
2. 左側のナビゲーションから [Network] を選択します。
3. 変更したいネットワークの名前をクリックします。
4. [View IP Addresses] をクリックします。
5. 変更したい IP アドレスをクリックします。
6. [Configuration] タブをクリクし次の値を入力します。
207
第19章ネットワークとトラフィックの管理
• Source CIDR : (オプション) 特定のアドレスブロックに含まれる IP アドレスのみを許可するには CIDR
かカンマで区切られた CIDR のリストを入力します。例として 192.168.0.0/22 などが挙げられます。ま
た、空欄にすると全ての CIDR を許可します。
• Protocol : 開放されたポートで利用される通信プロトコルです。
• Start Port と End Port : ファイアウォールで開放したいポート番号です。単一のポートを開放したい場
合、両方のフィールドに同一の番号を入力してください。
• ICMP Type と ICMP Code : プロトコルに ICMP を設定した場合のみ利用されます。ICMP プロトコ
ルにおいて必要な ICMP ヘッダーに埋め込まれるタイプとコードを入力してください。何を入力するべき
か詳細に関しては「ICMP ドキュメント」を参照してください。
7. [Add]をクリックします。
19.14.3. ポート転送
ポート転送サービスは、ポリシーを定義するポート転送規則のセットです。ポート転送サービスは、1 台または複
数のゲスト仮想マシンに適用されます。これにより、ゲスト仮想マシンに、ポート転送サービスで定義するポリ
シーに従って管理される受信ネットワークアクセス権が付与されます。オプションで、CIDR を指定して送信元 IP
アドレスをフィルターすることもできます。これは、特定の IP アドレスからの受信要求の転送のみを許可する場
合に役立ちます。
任意の数のポート転送サービスを、ゲスト仮想マシンに適用できます。ポート転送サービスは定義できますが、
メンバーを持つものではありません。
エラスティック IP に対してはポートを開放するためにポート転送を利用することができません。エラスティック
IP を使っている場合は代わりにセキュリティグループを使って外部からのアクセスをコントロールします。詳細
は「セキュリティグループ」を参照してください。
ポート転送を設定するには
1. 管理者もしくはエンドユーザーとして CloudStack UI にログインします。
2. もし、完了しない場合は CloudStack でパブリック IP アドレスの範囲をゾーンに追加します。詳細はインス
トールガイドの「ゾーンとポッドの追加」を参照してください。
3. 1 台または複数のゲスト仮想マシンを CloudStack に追加してください。
4. 左側のナビゲーションバーで[Network]をクリックします。
5. 仮想マシンを実行しているゲストネットワークの名前をクリックします。
6. 既存の IP アドレスを選択するか、新しい IP アドレスを取得します(�� IP �� を参照)。一覧内の IP ア
ドレスをクリックします。
7. [Configuration]タブをクリックします。
8. ダイアグラムの[Port Forwarding]ノードの[View All]をクリックします。
9. 次の項目を入力します。
• Public Port : パブリックトラフィックが送信される、前の手順で取得した IP アドレスのポートです。
• Private Port : 転送されたパブリックトラフィックをインスタンスがリッスンするポートです。
208
IP Load Balancing
• Protocol: 2 つのポートの間で使用される通信プロトコルです。
10. [Add]をクリックします。
19.15. IP Load Balancing
The user may choose to associate the same public IP for multiple guests. CloudStack implements
a TCP-level load balancer with the following policies.
• ラウンドロビン
• Least connection
• Source IP
This is similar to port forwarding but the destination may be multiple IP addresses.
19.16. DNSとDHCP
仮想ルータはゲストに DNS と DHCP サービスを提供します。有効なゾーンにある DNS サーバへ DNS リクエ
ストをプロクシします。
19.17. VPN
CloudStack アカウントの所有者は、仮想マシンにアクセスするためのVPN(Virtual Private Network:仮想プ
ライベートネットワーク)を作成できます。リモートアクセス VPN サービスを提供するネットワークオファリングから
ゲストネットワークのインスタンスを作成すると、システム仮想マシンに基づいて、仮想ルーターによってサービ
スが提供されます。\nCloudStack は、L2TP over IPsec ベースのリモートアクセス VPN サービスをゲスト仮
想ネットワークに提供します。各ネットワークに仮想ルー\nターがあるため、VPN はネットワーク間で共有されま
せん。Windows、Mac OS X、および iOS のネイティブ VPN クライアントを使用して、ゲストネットワークに接続
できます。アカウント所有者は VPN ユーザーを作成して管理することができます。このために、CloudStack の
アカウントデータベースではなく別のテーブルが使用されます。VPN ユーザーデータベースは、特定のアカウン
ト所有者が作成するすべての VPN で共有されます。すべての VPN ユーザーはそのアカウント所有者が作成す
るすべての VPN にアクセスできます。
注記
トラフィックのすべてが VPN を経由するわけはないことに注意してください。つまり、
VPN
によって構築されるルートはゲストネットワーク専用にする必要があり、すべてのトラ
フィックに使用できるわけではありません。
• モバイルユーザー/リモートアクセス : ユーザーは、自宅または事務所からクラウド内のプライベートネット
ワークに安全に接続することを望んでいます。通常、接続するクライアントの IP アドレスは動的であり、VPN
サーバーで事前構成することはできません。
• Site to Site. In this scenario, two private subnets are connected over the public Internet with
a secure VPN tunnel. The cloud user’s subnet (for example, an office network) is connected
through a gateway to the network in the cloud. The address of the user’s gateway must be
preconfigured on the VPN server in the cloud. Note that although L2TP-over-IPsec can be used
to set up Site-to-Site VPNs, this is not the primary intent of this feature. For more information,
see �Setting Up a Site-to-Site VPN Connection�
209
第19章ネットワークとトラフィックの管理
19.17.1. VPN の構成
クラウドの VPN をセットアップするには
1. 管理者もしくはエンドユーザーとして CloudStack UI にログインします。
2. 左側のナビゲーションバーで [Global Settings] をクリックします。
3. 次のグローバル構成パラメーターを設定します。
• remote.access.vpn.client.ip.range – リモートアクセス VPN クライアントに割り当てる IP アドレスの
範囲です。範囲内の最初の IP アドレスは VPN サーバーによって使用されます。
• remote.access.vpn.psk.length – IPSec キーの長さです。
• remote.access.vpn.user.limit – アカウントあたりの VPN ユーザーの最大数です。
特定のネットワークの VPN を有効にするには
1. ユーザーまたは管理者として CloudStack ユーザーインターフェイスにログオンします。
2. 左側のナビゲーションバーで[Network]をクリックします。
3. 設定するネットワークの名前をクリックします。
4. [View IP Addresses] をクリックします。
5. 表示される IP アドレスの 1 つをクリックします。
6.
[Enable VPN]アイコンをクリックします。
ポップアップウィンドウに IPsec キーが表示されます。
19.17.2. Windows での VPN の使用方法
VPN を使用する手順は、Windows のバージョンによって異なります。一般に、ユーザーは VPN プロパティを編
集し、デフォルトのルートが VPN ではないことを確認する必要があります。次の手順は Windows Vista 上の
Windows L2TP クライアントを対象にしています。ほかのバージョンの Windows でもコマンドは同様のはずで
す。
1. CloudStack
ユーザーインターフェイスにログオンして、アカウントの送信元
NAT
IP
アドレ
スをクリックします。[VPN]
タブに
IPsec
事前共有キーが表示されます。これと送信元
NAT
IP アドレスを記録します。ユーザーインターフェイスに、ユーザーとパスワードも表示されます。ユーザーを選
択するか、ユーザーが存在しない場合はユーザーとパスワードを追加します。
2. Windows
コンピューターでコントロールパネルの[ネットワークと共有センター]を開きます。[接続または
ネットワークのセットアップ]をクリックします。
3. 次に開くダイアログボックスで、[いいえ]をクリックして新しい接続を作成します。
4. 次に開くダイアログボックスで、[インターネット接続(VPN)を使用します]をクリックします。
5. In the next dialog, enter the source NAT IP from step 1 and give the connection a name. Check
Don't connect now.
6. In the next dialog, enter the user name and password selected in step 1.
210
Using VPN with Mac OS X
7. [Create] をクリックします。
8. コントロールパネルに戻り、[ネットワーク接続]をクリックして新しい接続を表示します。接続はまだアクティ
ブになっていません。
9. 新しい接続を右クリックし、[プロパティ]を選択します。[プロパティ]ダイアログボックスで[ネットワーク]タブを
クリックします。
10. In Type of VPN, choose L2TP IPsec VPN, then click IPsec settings. Select Use preshared key.
Enter the preshared key from Step 1.
11. The connection is ready for activation. Go back to Control Panel -> Network Connections and
double-click the created connection.
12. Enter the user name and password from Step 1.
19.17.3. Using VPN with Mac OS X
First, be sure you've configured the VPN settings in your CloudStack install. This section is only
concerned with connecting via Mac OS X to your VPN.
Note, these instructions were written on Mac OS X 10.7.5. They may differ slightly in older or newer
releases of Mac OS X.
1. On your Mac, open System Preferences and click Network.
2. Make sure Send all traffic over VPN connection is not checked.
3. If your preferences are locked, you'll need to click the lock in the bottom left-hand corner to
make any changes and provide your administrator credentials.
4. You will need to create a new network entry. Click the plus icon on the bottom left-hand side
and you'll see a dialog that says "Select the interface and enter a name for the new service."
Select VPN from the Interface drop-down menu, and "L2TP over IPSec" for the VPN Type. Enter
whatever you like within the "Service Name" field.
5. You'll now have a new network interface with the name of whatever you put in the "Service
Name" field. For the purposes of this example, we'll assume you've named it "CloudStack." Click
on that interface and provide the IP address of the interface for your VPN under the Server
Address field, and the user name for your VPN under Account Name.
6. Click Authentication Settings, and add the user's password under User Authentication and
enter the pre-shared IPSec key in the Shared Secret field under Machine Authentication. Click
OK.
7. You may also want to click the "Show VPN status in menu bar" but that's entirely optional.
8. Now click "Connect" and you will be connected to the CloudStack VPN.
19.17.4. Setting Up a Site-to-Site VPN Connection
A Site-to-Site VPN connection helps you establish a secure connection from an enterprise
datacenter to the cloud infrastructure. This allows users to access the guest VMs by establishing
a VPN connection to the virtual router of the account from a device in the datacenter of the
enterprise. Having this facility eliminates the need to establish VPN connections to individual VMs.
211
第19章ネットワークとトラフィックの管理
The supported endpoints on the remote datacenters are:
• Cisco ISR with IOS 12.4 or later
• Juniper J-Series routers with JunOS 9.5 or later
注記
In addition to the specific Cisco and Juniper devices listed above, the expectation
is that any Cisco or Juniper device running on the supported operating systems are
able to establish VPN connections.
To set up a Site-to-Site VPN connection, perform the following:
1. Create a Virtual Private Cloud (VPC).
See �VPC ��.
2. Create a VPN Customer Gateway.
3. Create a VPN gateway for the VPC that you created.
4. Create VPN connection from the VPC VPN gateway to the customer VPN gateway.
注記
Appropriate events are generated on the CloudStack UI when status of a Siteto-Site VPN connection changes from connected to disconnected, or vice versa.
Currently no events are generated when establishing a VPN connection fails or
pending.
19.17.4.1. Creating and Updating a VPN Customer Gateway
注記
A VPN customer gateway can be connected to only one VPN gateway at a time.
To add a VPN Customer Gateway:
1. 管理者もしくはエンドユーザーとして CloudStack UI にログインします。
2. 左側のナビゲーションから [Network] を選択します。
3. In the Select view, select VPN Customer Gateway.
4. Click Add site-to-site VPN.
212
Setting Up a Site-to-Site VPN Connection
次の情報を指定します。
• Name: A unique name for the VPN customer gateway you create.
• Gateway: The IP address for the remote gateway.
• CIDR list: The guest CIDR list of the remote subnets. Enter a CIDR or a comma-separated list
of CIDRs. Ensure that a guest CIDR list is not overlapped with the VPC’s CIDR, or another
guest CIDR. The CIDR must be RFC1918-compliant.
• IPsec Preshared Key: Preshared keying is a method where the endpoints of the VPN share
a secret key. This key value is used to authenticate the customer gateway and the VPC VPN
gateway to each other.
213
第19章ネットワークとトラフィックの管理
注記
The IKE peers (VPN end points) authenticate each other by computing and
sending a keyed hash of data that includes the Preshared key. If the receiving
peer is able to create the same hash independently by using its Preshared
key, it knows that both peers must share the same secret, thus authenticating
the customer gateway.
• IKE Encryption: The Internet Key Exchange (IKE) policy for phase-1. The supported
encryption algorithms are AES128, AES192, AES256, and 3DES. Authentication is
accomplished through the Preshared Keys.
注記
The phase-1 is the first phase in the IKE process. In this initial negotiation
phase, the two VPN endpoints agree on the methods to be used to provide
security for the underlying IP traffic. The phase-1 authenticates the two
VPN gateways to each other, by confirming that the remote gateway has a
matching Preshared Key.
• IKE Hash: The IKE hash for phase-1. The supported hash algorithms are SHA1 and MD5.
• IKE DH: A public-key cryptography protocol which allows two parties to establish a shared
secret over an insecure communications channel. The 1536-bit Diffie-Hellman group is used
within IKE to establish session keys. The supported options are None, Group-5 (1536-bit)
and Group-2 (1024-bit).
• ESP Encryption: Encapsulating Security Payload (ESP) algorithm within phase-2. The
supported encryption algorithms are AES128, AES192, AES256, and 3DES.
注記
The phase-2 is the second phase in the IKE process. The purpose of IKE
phase-2 is to negotiate IPSec security associations (SA) to set up the IPSec
tunnel. In phase-2, new keying material is extracted from the Diffie-Hellman
key exchange in phase-1, to provide session keys to use in protecting the
VPN data flow.
• ESP Hash: Encapsulating Security Payload (ESP) hash for phase-2. Supported hash
algorithms are SHA1 and MD5.
• Perfect Forward Secrecy: Perfect Forward Secrecy (or PFS) is the property that ensures that a
session key derived from a set of long-term public and private keys will not be compromised.
This property enforces a new Diffie-Hellman key exchange. It provides the keying material
that has greater key material life and thereby greater resistance to cryptographic attacks. The
available options are None, Group-5 (1536-bit) and Group-2 (1024-bit). The security of the
key exchanges increase as the DH groups grow larger, as does the time of the exchanges.
214
Setting Up a Site-to-Site VPN Connection
注記
When PFS is turned on, for every negotiation of a new phase-2 SA the two
gateways must generate a new set of phase-1 keys. This adds an extra layer of
protection that PFS adds, which ensures if the phase-2 SA’s have expired, the
keys used for new phase-2 SA’s have not been generated from the current
phase-1 keying material.
• IKE Lifetime (seconds): The phase-1 lifetime of the security association in seconds. Default is
86400 seconds (1 day). Whenever the time expires, a new phase-1 exchange is performed.
• ESP Lifetime (seconds): The phase-2 lifetime of the security association in seconds. Default
is 3600 seconds (1 hour). Whenever the value is exceeded, a re-key is initiated to provide a
new IPsec encryption and authentication session keys.
• Dead Peer Detection: A method to detect an unavailable Internet Key Exchange (IKE) peer.
Select this option if you want the virtual router to query the liveliness of its IKE peer at regular
intervals. It’s recommended to have the same configuration of DPD on both side of VPN
connection.
5. 「OK」をクリックします。
Updating and Removing a VPN Customer Gateway
You can update a customer gateway either with no VPN connection, or related VPN connection
is in error state.
1. 管理者もしくはエンドユーザーとして CloudStack UI にログインします。
2. 左側のナビゲーションから [Network] を選択します。
3. In the Select view, select VPN Customer Gateway.
4. Select the VPN customer gateway you want to work with.
5.
6.
To modify the required parameters, click the Edit VPN Customer Gateway button
To remove the VPN customer gateway, click the Delete VPN Customer Gateway button
7. 「OK」をクリックします。
19.17.4.2. VPC での VPN ゲートウェイの作成
1. 管理者もしくはエンドユーザーとして CloudStack UI にログインします。
2. 左側のナビゲーションから [Network] を選択します。
3. 選択ビューから VPC を選択します。
アカウントに対して作成された全ての VPC がページにリスト表示されます。
4. 仮想マシンを展開したい VPC の [Configure] ボタンをクリックします。
215
第19章ネットワークとトラフィックの管理
VPC ページではダイアグラム上にリストされる作成された全ての層が表示されます。
5. 設定アイコンをクリックします。
以下のオプションが表示されます。
• IP アドレス
• ゲートウェイ
• サイト間 VPN
• ネットワーク ACL
6. サイト間 VPN を選択します。
既に VPN ゲートウェイを作成している場合は表示された VPN ゲートウェイからサイト間 VPN を選択しま
す。
7. 確認ダイアログで [Yes] を選択します。
しばらく経つと VPN ゲートウェイが作成されます。その後、作成したVPN ゲートウェイの詳細が表示されま
す。次に [Yes] をクリックします。
VPN ゲートウェイ情報ページでは以下の詳細情報が表示されます。
• IP アドレス
• アカウント
• ドメイン
19.17.4.3. VPC 接続の作成
1. 管理者もしくはエンドユーザーとして CloudStack UI にログインします。
2. 左側のナビゲーションから [Network] を選択します。
3. 選択ビューから VPC を選択します。
アカウントに対し作成した全ての VPC がページに表示されます。
4. 仮想マシンを展開したい VPC の [Configure] ボタンをクリックします。
VPC ページではダイアグラム上にリストされる作成された全ての層が表示されます。
5. 設定アイコンをクリックします。
以下のオプションが表示されます。
• IP アドレス
• ゲートウェイ
• サイト間 VPN
216
Setting Up a Site-to-Site VPN Connection
• ネットワーク ACL
6. サイト間 VPN を選択します。
サイト間 VPN のページが表示されます。
7. セレクトビューのドロップダウンから VPN 接続を選択します。
8. [Create VPN Connection] をクリックします。
VPN 接続のダイアログが表示されます。
9. 必要なカスタマーゲートウェイを選択し、 [OK] をクリックします。
しばらくすると VPN 接続が表示されます。
VPN 接続に関して以下の情報が表示されます。
• IP アドレス
• ゲートウェイ
• 状態
• IPSec の事前共有鍵
• IKE 規則
• ESP 規則
19.17.4.4. VPN 接続の再起動と削除
1. 管理者もしくはエンドユーザーとして CloudStack UI にログインします。
2. 左側のナビゲーションから [Network] を選択します。
3. 選択ビューから VPC を選択します。
アカウントに対して作成された全ての VPC がページにリスト表示されます。
4. 仮想マシンを展開したい VPC の [Configure] ボタンをクリックします。
VPC ページではダイアグラム上にリストされる作成された全ての層が表示されます。
217
第19章ネットワークとトラフィックの管理
5. 設定アイコンをクリックします。
以下のオプションが表示されます。
• IP アドレス
• ゲートウェイ
• サイト間 VPN
• ネットワーク ACL
6. サイト間 VPN を選択します。
サイト間 VPN のページが表示されます。
7. セレクトビューのドロップダウンから VPN 接続を選択します。
作成した全ての VPN 接続が表示されます。
8. 対象となる VPN 接続を選択します。
[詳細] タブが表示されます。
9.
VPN 接続を削除するには [Delete VPN Connection] ボタンをクリックします。
VPN 接続を再起動するには [詳細] タブにある [Reset VPN Connection] ボタンをクリックします。
19.18. About Inter-VLAN Routing
Inter-VLAN Routing is the capability to route network traffic between VLANs. This feature enables
you to build Virtual Private Clouds (VPC), an isolated segment of your cloud, that can hold multi-tier
applications. These tiers are deployed on different VLANs that can communicate with each other.
You provision VLANs to the tiers your create, and VMs can be deployed on different tiers. The VLANs
are connected to a virtual router, which facilitates communication between the VMs. In effect, you
can segment VMs by means of VLANs into different networks that can host multi-tier applications,
such as Web, Application, or Database. Such segmentation by means of VLANs logically separate
application VMs for higher security and lower broadcasts, while remaining physically connected
to the same device.
This feature is supported on XenServer and VMware hypervisors.
The major advantages are:
• The administrator can deploy a set of VLANs and allow users to deploy VMs on these VLANs. A
guest VLAN is randomly alloted to an account from a pre-specified set of guest VLANs. All the
VMs of a certain tier of an account reside on the guest VLAN allotted to that account.
注記
A VLAN allocated for an account cannot be shared between multiple accounts.
218
About Inter-VLAN Routing
• The administrator can allow users create their own VPC and deploy the application. In this
scenario, the VMs that belong to the account are deployed on the VLANs allotted to that account.
• Both administrators and users can create multiple VPCs. The guest network NIC is plugged to
the VPC virtual router when the first VM is deployed in a tier.
• The administrator can create the following gateways to send to or receive traffic from the VMs:
• VPN Gateway: For more information, see �VPC �� VPN ��.
• Public Gateway: The public gateway for a VPC is added to the virtual router when the virtual
router is created for VPC. The public gateway is not exposed to the end users. You are not
allowed to list it, nor allowed to create any static routes.
• Private Gateway: For more information, see �VPC ��.
• Both administrators and users can create various possible destinations-gateway combinations.
However, only one gateway of each type can be used in a deployment.
For example:
• VLANs and Public Gateway: For example, an application is deployed in the cloud, and the Web
application VMs communicate with the Internet.
• VLANs, VPN Gateway, and Public Gateway: For example, an application is deployed in the
cloud; the Web application VMs communicate with the Internet; and the database VMs
communicate with the on-premise devices.
• The administrator can define Access Control List (ACL) on the virtual router to filter the traffic
among the VLANs or between the Internet and a VLAN. You can define ACL based on CIDR, port
range, protocol, type code (if ICMP protocol is selected) and Ingress/Egress type.
The following figure shows the possible deployment scenarios of a Inter-VLAN setup:
219
第19章ネットワークとトラフィックの管理
To set up a multi-tier Inter-VLAN deployment, see �VPC ��.
19.19. VPC の構成
19.19.1. VPC(Virtual Private Cloud) の概要
CloudStack 仮想プライベートクラウドは CloudStack の機能の一部です。 VPC は一般的な物理ネットワーク
に似た独自の仮想ネットワークトポロジを持ち、ユーザーはプライベードアドレスを持つ仮想マシンをその仮想
ネットワーク上で起動することができます。例: 10.0.0.0/16。 IP のアドレス範囲に準じた仮想マシングループに
対し VPC のネットワークを有効化し、層を定義することができます。
例として、VPC がプライベートなアドレス範囲である 10.0.0.0/16 を持っていした場合、ゲストネットワークは
10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24 といったアドレスを持つことができます。
VPC の主要コンポーネント。
VPC は以下のネットワークコンポーネントから構成されます。
• VPC: VPC は仮想ルーターを介し通信することができる、複数の独立したネットワークのコンテナとして動作
します。
• Network Tiers: 各層はそれぞれ独立したネットワークとして VLAN 情報やCIDR情報を持ち、VLAN によっ
てセグメント化されます。各層の NIC はゲートウェイとして動作します。
• Virtual Router: 仮想ルーターは自動的に作成され VPC 作成とともに起動します。仮想ルーターは各層とパ
ブリックなゲートウェイから受信する直接のトラフィック、VPN ゲートウェイ、NAT インスタンスに接しています。
各層は NIC や仮想ルーターの IP と連携しDNS や DHCP といったサービスを提供します。
• Public
Gateway:
インターネットと
VPC
との通信はパブリックゲートウェイを介して処理されま
す。VPC ではパブリックゲートウェイはエンドユーザーに対し不可視であるため静的ルーティングはパブリック
ゲートウェイではサポートされていません。
• Private Gateway: プライベートネットワークと VPC との通信は全てルーティングされます。詳細な情報は
�VPC �� を参照して下さい。
• VPN Gateway: VPC に付与される VPN 接続です。
• Site-to-Site VPN Connection: VPC とデータセンターやホームネットワーク、コロケーション環境とを接続
するハードウェアベースの VPN 接続です。詳細な情報は �Setting Up a Site-to-Site VPN Connection� を
参照して下さい。
• Customer Gateway: VPN 接続の利用者側ゲートウェイです。詳細な情報は �Creating and Updating a
VPN Customer Gateway� を参照して下さい。
• NAT Instance: インターネットからパブリックゲートウェイを介しての仮想マシンアクセスのためのポートアド
レス転送を提供するインスタンスです。詳細な情報は �VPC �� NAT �� を参照して下さい。
VPC のネットワークアーキテクチャ
VPC では次のネットワークアーキテクチャの基本的なオプションが提供されます。
• パブリックゲートウェイのみの VPC
220
VPC(Virtual Private Cloud) の概要
• パブリック、プライベートゲートウェイを持つ VPC
• パブリック、プライベートゲートウェイとサイト間 VPN アクセスを持つ VPC
• プライベートゲートウェイのみとサイト間 VPN アクセスを持つ VPC
VPC の接続オプション
次のように VPC に接続することができます。
• パブリックゲートウェイを介してインターネットから接続。
• VPN ゲートウェイを介しサイト間 VPN 接続を利用して会社のデータセンターから接続
• パブリックゲートウェイと VPN ゲートウェイを利用してインターネット、会社のデータセンター双方から接続
VPC ネットワークの考慮点
VPC を作成する前に次のことを考慮しておきます。
• VPC はデフォルトで作成された際に有効化されます。
• A VPC can be created in Advance zone only, and can't belong to more than one zone at a time.
• デフォルトの VPC の作成可能数はアカウント毎に20個です。しかし、グローバル設定の max.account.vpcs
を変更することでアカウント毎に作成可能な VPC の最大数を制御することができます。
• デフォルトの VPC 上の層の作成可能数はアカウント毎に3個です。vpc.max.networks を変更することで最
大数を制御することができます。
• Each tier should have an unique CIDR in the VPC. Ensure that the tier's CIDR should be within
the VPC CIDR range.
• 層は単一の VPC にのみ所属します。
• VPC 内の全てのネットワーク層は同一アカウントに紐付けられるべきです。
• デフォルトでは VPC が作成された際、送信元 NAT 用 IP が割り当てられます。送信元 NAT 用 IP は VPC
が削除された時のみ開放されます。
• パブリック IP は同時に1つだけ利用することができます。IP が送信元 NAT 用である場合静的 NAT やポー
ト転送用に割り当てることはできません。
• 展開された仮想マシンはプライベート IP のみ利用することができます。インターネットへの通信を行う場合、
展開した VPC で仮想マシンに対しての NAT を有効化する必要があります。
• 新しいネットワークのみが
VPC
に対して追加できます。VPC
vpc.max.networks によって制限されており、デフォルト値は3です。
毎のネットワークの最大値は
• 負荷分散サービスは VPC 内の単一の層に対してのみサポートされます。
• 層に IP アドレスが割り当てられた場合
• That IP can't be used by more than one tier at a time in the VPC. For example, if you have tiers
A and B, and a public IP1, you can create a port forwarding rule by using the IP either for A
or B, but not for both.
221
第19章ネットワークとトラフィックの管理
• That IP can't be used for StaticNAT, load balancing, or port forwarding rules for another guest
network inside the VPC.
• リモートアクセス VPN は VPCではサポートされていません。
19.19.2. VPC の追加
VPC を作成する場合、ゾーンと VPC 対しての IP アドレスが必要になります。この際、クラスレス内部ドメイン
ルーティングを CIDR のブロックとして指定する必要があります。
1. 管理者またはユーザーとして CloudStack ユーザーインターフェイスにログオンします。
2. 左側のナビゲーションから [Network] を選択します。
3. 選択ビューから VPC を選択します。
4. [Add VPC] をクリックすると VPC 追加ページでは以下の情報が表示されます。
次の情報を指定します。
• Name: 作成した VPC の名称です。
• Description: VPC の詳細情報です。
• Zone: VPC を利用可能にしたいゾーンを選択します。
• Super CIDR for Guest Networks: VPC における全ての層(ゲストネットワーク)に対する CIDR を
定義します。層を作成した際はそれが入力したスーパー CIDR の内部に所属することを確認します。ま
た、CIDR が RFC1918 を満たしていることを確認します。
• DNS domain for Guest Networks: 特別なドメイン名を割り当てたい場合には DNS サフィックスを指
定します。このパラメーターは VPC 上の全ての層に対し適用され、これは VPC 上に作成された全ての
層は同じ DNS ドメインに所属することを意味します。パラメーターを指定しない場合は DNS 名は自動
的に生成されます。
222
層の追加
19.19.3. 層の追加
層は VPC 上で明確に区別でき各ネットワークを分離しデフォルトで他の層とのアクセスを禁止します。層は異
なった VLAN 上に構成され仮想ルーターを介することで互いに通信することができます。層は VPC 上に他の
層に対し安価で低遅延のネットワーク接続を提供します。
1. 管理者もしくはエンドユーザーとして CloudStack UI にログインします。
2. 左側のナビゲーションから [Network] を選択します。
3. 選択ビューから VPC を選択します。
アカウントに対して作成された全ての VPC がページ上にリスト表示されます。
注記
エンドユーザーはそれぞれの VPC を確認することができ、ROOT管理者やドメイン管理
者は権限を許可されている全ての VPC を確認することができます。
4. セットアップしたい層を含む VPC の [Configure] ボタンをクリックします。
次のように層の追加ダイアログが表示されます。
既に層を作成済みの場合 VPC のダイアログが表示されるので新しい層を追加するため [Create Tier] を
クリックします。
5. 以下の要素を指定します。
全ての項目が必須となります。
• Name: 作成した層に対する唯一の名前です。
• Network
Offering:
以下のデフォルトのネットワークオファリングがリスト表示されま
す。DefaultIsolatedNetworkOfferingForVpcNetworksNoLB,
DefaultIsolatedNetworkOfferingForVpcNetworks。
VPC では LB-enabled ネットワークオファリングだけが作成されます。
223
第19章ネットワークとトラフィックの管理
• Gateway: 作成された層のゲートウェイです。VPC 作成時に指定したスーパー CIDR 内に収まり、VPC
内の他の層と重複しないことを確認します。
• Netmask: 作成された層のネットマスクです。
例として、もし VPC の CIDR を10.0.0.0/16とした場合、層の CIDR は10.0.1.0/24となり、ゲートウェ
イは10.0.1.1 となります。またその際のネットマスクは255.255.255.0となります。
6. 「OK」をクリックします。
7. 層のアクセス制御リストを設定する場合は引き続き設定を続けます。
19.19.4. Configuring Access Control List
Define Network Access Control List (ACL) on the VPC virtual router to control incoming (ingress)
and outgoing (egress) traffic between the VPC tiers, and the tiers and Internet. By default, all
incoming and outgoing traffic to the guest networks is blocked. To open the ports, you must create
a new network ACL. The network ACLs can be created for the tiers only if the NetworkACL service
is supported.
1. 管理者またはユーザーとして CloudStack ユーザーインターフェイスにログオンします。
2. 左側のナビゲーションから [Network] を選択します。
3. 選択ビューから VPC を選択します。
アカウントに対して作成された全ての VPC がページにリスト表示されます。
4. 設定アイコンをクリックします。
以下のオプションが表示されます。
• IP アドレス
• ゲートウェイ
• サイト間 VPN
• ネットワーク ACL
5. Select Network ACLs.
The Network ACLs page is displayed.
6. Click Add Network ACLs.
To add an ACL rule, fill in the following fields to specify what kind of network traffic is allowed
in this tier.
• CIDR: The CIDR acts as the Source CIDR for the Ingress rules, and Destination CIDR for the
Egress rules. To accept traffic only from or to the IP addresses within a particular address
block, enter a CIDR or a comma-separated list of CIDRs. The CIDR is the base IP address of
the incoming traffic. For example, 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.
224
Configuring Access Control List
• Protocol: The networking protocol that sources use to send traffic to the tier. The TCP and
UDP protocols are typically used for data exchange and end-user communications. The ICMP
protocol is typically used to send error messages or network monitoring data.
• Start Port, End Port (TCP, UDP only): A range of listening ports that are the destination for
the incoming traffic. If you are opening a single port, use the same number in both fields.
• Select Tier: Select the tier for which you want to add this ACL rule.
• ICMP Type, ICMP Code (ICMP only): The type of message and error code that will be sent.
• Traffic Type: Select the traffic type you want to apply.
• Egress: To add an egress rule, select Egress from the Traffic type drop-down box and click
Add. This specifies what type of traffic is allowed to be sent out of VM instances in this
tier. If no egress rules are specified, all traffic from the tier is allowed out at the VPC virtual
router. Once egress rules are specified, only the traffic specified in egress rules and the
responses to any traffic that has been allowed in through an ingress rule are allowed out.
No egress rule is required for the VMs in a tier to communicate with each other.
• Ingress: To add an ingress rule, select Ingress from the Traffic type drop-down box and
click Add. This specifies what network traffic is allowed into the VM instances in this tier.
If no ingress rules are specified, then no traffic will be allowed in, except for responses to
any traffic that has been allowed out through an egress rule.
注記
By default, all incoming and outgoing traffic to the guest networks is blocked.
To open the ports, create a new network ACL.
7. Click Add. The ACL rule is added.
To view the list of ACL rules you have added, click the desired tier from the Network ACLs page,
then select the Network ACL tab.
225
第19章ネットワークとトラフィックの管理
You can edit the tags assigned to the ACL rules and delete the ACL rules you have created.
Click the appropriate button in the Actions column.
19.19.5. VPC へのプライベートゲートウェイの追加
プライベートゲートウェイはルート管理者のみ追加することができます。VPCのプライベートネットワークは物理
ネットワークの NIC と1対1の関係があり、同一データセンター上でゲートウェイを持たない重複しない VLAN
や IP が許容されます。
1. 管理者もしくはエンドユーザーとして CloudStack UI にログインします。
2. 左側のナビゲーションから [Network] を選択します。
3. 選択ビューから VPC を選択します。
アカウントに対して作成された全ての VPC がページにリスト表示されます。
4. 負荷分散ルールを構成したい VPC の構成ボタンをクリックします。
VPC ページではダイアグラム上にリストされる作成された全ての層が表示されます。
5. 設定アイコンをクリックします。
以下のオプションが表示されます。
• IP アドレス
• プライベートゲートウェイ
• サイト間 VPN
• ネットワーク ACL
6. プライベートゲートウェイを選択します。
ゲートウェイのページに表示されます。
7. [Add new gateway]をクリックします。
226
層への仮想マシンの展開
8. 以下の要素を指定します。
• 物理ネットワーク: \nゾーンに作成された物理ネットワークです。
• IP アドレス: \nVPC ゲートウェイに割り当てられた IP アドレスです。
• ゲートウェイ: \nトラフィックが VPC に対し(もしくは VPC から)ルーティングされるゲートウェイです。
• ネットマスク: \nVPC ゲートウェイに割り当てられた IP に対してのネットマスクです。
• VLAN: \nVPC ゲートウェイに割り当てられた VLAN です。
新しいゲートウェイがリスト上に表示されます。VPC に対しゲートウェイを追加するためこれらの手順を繰り
返すこともできます。
19.19.6. 層への仮想マシンの展開
1. 管理者またはユーザーとして CloudStack ユーザーインターフェイスにログオンします。
2. 左側のナビゲーションから [Network] を選択します。
3. 選択ビューから VPC を選択します。
アカウントに対して作成された全ての VPC がページにリスト表示されます。
4. 仮想マシンを展開したい VPC の [Configure] ボタンをクリックします。
VPC のページが表示され作成済みの全ての層がリスト表示されます。
5. 仮想マシンを追加したい層で [Add VM] ボタンをクリックします。
インスタンスの追加ページが表示されます。
227
第19章ネットワークとトラフィックの管理
この場面でインスタンスを追加するにはページの指示に従います。インスタンスの追加に関してはインス
トールガイドの「インスタンスの追加」の章を参照して下さい。
19.19.7. VPC に対しての新しい IP アドレスの取得
When you acquire an IP address, all IP addresses are allocated to VPC, not to the guest networks
within the VPC. The IPs are associated to the guest network only when the first port-forwarding,
load balancing, or Static NAT rule is created for the IP or the network. IP can't be associated to
more than one network at a time.
1. 管理者またはユーザーとして CloudStack ユーザーインターフェイスにログオンします。
2. 左側のナビゲーションから [Network] を選択します。
3. 選択ビューから [VPC] を選択します。
アカウントに対して作成された全ての VPC がページにリスト表示されます。
4. 仮想マシンを展開したい VPC の [Configure] ボタンをクリックします。
VPC ページではダイアグラム上にリストされる作成された全ての層が表示されます。
5. 設定アイコンをクリックします。
以下のオプションが表示されます。
• IP アドレス
• ゲートウェイ
• サイト間 VPN
• ネットワーク ACL
6. IP アドレスを選択します。
IP アドレスのページが表示されます。
7. [Acquire New IP] をクリックし、確認ダイアログで [Yes] をクリックします。
一般的に IP アドレスは限りあるリソースであるため確認用ページが表示されます。しばらく経つと状態が
[Allocated] に変化し新しい IP アドレスが表示されます。これでポート転送や負荷分散、静的NATルール
に対し IP アドレスを利用することができます。
19.19.8. VPC に割り当てられた IP アドレスの開放
IP アドレスは限られたリソースであり、特定の IP をこれ以上利用することが無い場合は VPC から IP を開
放し利用可能アドレスのプールに返却することができます。IP アドレスに対し全てのネットワーク機能(ポート転
送、負荷分散、静的NATルール)を削除している場合には層から IP アドレスを開放することができます。ここで
開放された IP アドレスは同一の VPC に属し続けます。
1. 管理者またはユーザーとして CloudStack ユーザーインターフェイスにログオンします。
2. 左側のナビゲーションから [Network] を選択します。
228
VPC での静的 NAT の有効化、無効化
3. 選択ビューから VPC を選択します。
アカウントに対して作成された全ての VPC がページにリスト表示されます。
4. 開放したい IP を持つ VPC の [Configure] ボタンをクリックします。
VPC ページではダイアグラム上にリストされる作成された全ての層が表示されます。
5. 設定アイコンをクリックします。
以下のオプションが表示されます。
• IP アドレス
• ゲートウェイ
• サイト間 VPN
• ネットワーク ACL
6. IP アドレスを選択します。
IP アドレスのページが表示されます。
7. 開放したい IP をクリックします。
8.
詳細タブで [Release IP] ボタンをクリックします。
19.19.9. VPC での静的 NAT の有効化、無効化
静的 NAT ルールは VPC 内の仮想マシンに割り当てられたプライベート IP に対しインターネットからのトラ
フィックを渡すためパブリック IP と関連付けられます。この章では VPC 上の特定 IP アドレスに対してどのように
静的 NAT の有効化、無効化するか説明しています。
もし、すでにポートフォワーディングのルールが IP アドレスに反映されている場合、IP に対して静的 NAT を有効
化することができません。
仮想マシンがいくつかのネットワークに所属している場合、静的 NAT のルールはデフォルトネットワークでしか
機能しません。
1. 管理者またはユーザーとして CloudStack ユーザーインターフェイスにログオンします。
2. 左側のナビゲーションから [Network] を選択します。
3. 選択ビューから VPC を選択します。
アカウントに対して作成された全ての VPC がページにリスト表示されます。
4. 仮想マシンを展開したい VPC の [Configure] ボタンをクリックします。
VPC ページではダイアグラム上にリストされる作成された全ての層が表示されます。
5. 設定アイコンをクリックします。
以下のオプションが表示されます。
• IP アドレス
229
第19章ネットワークとトラフィックの管理
• ゲートウェイ
• サイト間 VPN
• ネットワーク ACL
6. IP アドレスを選択します。
IP アドレスのページが表示されます。
7. 設定したい IP をクリックします。
8.
詳細タブで [Static NAT] ボタンをクリックします。
ボタンは有効、無効のトグルボタンになっており、
表示される状態は IP アドレスに対して現在静的 NAT が有効化されているかどうかによって変化します。
9. 静的 NAT を有効化すると以下のようなダイアログが表示されます。
10. 層と対象となる仮想マシンを選択して [Apply] ボタンを押して下さい。
19.19.10. VPC への負荷分散ルールの追加
CloudStack のユーザーや管理者はパブリック IP で受信されたトラフィックを負荷分散サービスが提供されて
いるネットワーク層に所属する複数の仮想マシンに対して負荷分散するためのルールを作成することができま
す。ユーザーはアルゴリズムに基づいたルールを作成し、それらのルールを VPC 内の仮想マシンに割り当てる
ことができます。
1. 管理者またはユーザーとして CloudStack ユーザーインターフェイスにログオンします。
2. 左側のナビゲーションから [Network] を選択します。
3. 選択ビューから VPC を選択します。
アカウントに対して作成された全ての VPC がページにリスト表示されます。
4. 負荷分散ルールを構成したい VPC の構成ボタンをクリックします。
VPC ページではダイアグラム上にリストされる作成された全ての層が表示されます。
5. 設定アイコンをクリックします。
以下のオプションが表示されます。
• IP アドレス
230
VPC へのポート転送ルールの追加
• ゲートウェイ
• サイト間 VPN
• ネットワーク ACL
6. IP アドレスを選択します。
IP アドレスのページが表示されます。
7. ルールを作成したい IP アドレスをクリックし、[Configuration] タブをクリックします。
8. 構成図のロードバランサーをクリックし、[View All] をクリックします。
9. ルールを適用したい層を選択します。
注記
VPC 内では単一の層に対して負荷分散サービスがサポートされます。
10. 以下の要素を指定します。
• Name : 負荷分散ルールの名前です。
• Public Port: 負荷分散用に受信されるトラッフィク用ポート
• Private Port : 仮想マシンがトラフィックを受信するポート番号です。
• Algorighm\nCloudStack
サポートされます。
で利用したい負荷分散アルゴリズムを選択します。以下のアルゴリズムが
• ラウンドロビン
• 直近での接続
• 接続元
• Stickness. (オプション) Click Configure and choose the algorithm for the stickiness policy. See
Sticky Session Policies for Load Balancer Rules.\n[Configure] をクリックし、スティックネス規則用
のアルゴリズムを選択します。負荷分散ルール用スティッキーセッション規則を参照して下さい。
• Add VMs: Click Add VMs, then select two or more VMs that will divide the load of incoming
traffic, and click Apply.\n[Add VMs] をクリックし受信トラフィックを負荷分散したい2つ以上の仮想
マシンを選択します。その後、[Apply] をクリックします。
新しい負荷分散ルールがリスト表示され、さらに IP アドレスに対しての負荷分散ルールを追加することができ
ます。
19.19.11. VPC へのポート転送ルールの追加
1. 管理者またはユーザーとして CloudStack ユーザーインターフェイスにログオンします。
2. 左側のナビゲーションから [Network] を選択します。
231
第19章ネットワークとトラフィックの管理
3. 選択ビューから VPC を選択します。
アカウントに対して作成された全ての VPC がページにリスト表示されます。
4. 仮想マシンを展開したい VPC の [Configure] ボタンをクリックします。
VPC ページではダイアグラム上にリストされる作成された全ての層が表示されます。
5. 設定アイコンをクリックします。
以下のオプションが表示されます。
• IP アドレス
• ゲートウェイ
• サイト間 VPN
• ネットワーク ACL
6. 既存の IP アドレスを選択するか新しい IP アドレスを取得します。リスト表示された IP アドレス名をクリック
します。
IP アドレスのページが表示されます。
7. ルールを作成したい IP アドレスをクリックし、[Configuration] タブをクリックします。
8. ダイアグラムの[Port Forwarding]ノードの[View All]をクリックします。
9. ルールを適用したい層を選択します。
10. 以下の要素を指定します。
• Public Port: The port to which public traffic will be addressed on the IP address you acquired
in the previous step.以前の手順で取得したどの IP アドレスへのパブリックトラフィックを受信するポー
トを指定します。
• Private Port: 仮想マシンが転送されたパブリックトラッフィクをリッスンするポートを指定します。
• Protocol: それぞれのポートで利用する通信プロトコルを指定します。
• TCP
• UDP
• Add VM: [Add VM] をクリックします。その後、ルールを適用したい仮想マシン名を選択し [Apply] をク
リックします。
仮想マシンへの ssh セッションを作成することでルールをテストすることができます。
19.19.12. 層の削除
VPC から層を削除することができ、削除された層は無効化することができません。層を削除した場合、層に設定
したリソースのみ削除されます。全てのネットワークルール(ポート転送や負荷分散、静的 NAT など)と IP アドレ
スは削除された層に割り当てられたままになります。その際、IP アドレスは VPC に所属し続けます。
1. 管理者またはユーザーとして CloudStack ユーザーインターフェイスにログオンします。
232
VPC の編集と再起動、削除
2. 左側のナビゲーションから [Network] を選択します。
3. 選択ビューから VPC を選択します。
アカウントに対して作成された全ての VPC がページ上にリスト表示されます。
4. 層を設定したい VPC の [Configure] ボタンをクリックします。
VPC の設定画面が表示され、設定したい層の情報が表示されます。
5. [Remove VPC] ボタンをクリックします。
層を削除するにはしばらく待ちます。
19.19.13. VPC の編集と再起動、削除
注記
VPC 削除前の全ての層の確認
1. 管理者またはユーザーとして CloudStack ユーザーインターフェイスにログオンします。
2. 左側のナビゲーションから [Network] を選択します。
3. 選択ビューから VPC を選択します。
アカウントに対して作成された全ての VPC がページにリスト表示されます。
4. 対象の VPC を選択します。
5.
削除するには [Remove VPC] ボタンをクリックします。
VPCの名前と詳細情報を編集することができ、それには VPC を選択し [Edit] ボタンをクリックします。
VPC を再起動するには VPC を選択し [Restart] ボタンをクリックします。
19.20. Persistent Networks
The network that you can provision without having to deploy any VMs on it is called a persistent
network. A persistent network can be part of a VPC or a non-VPC environment.
233
第19章ネットワークとトラフィックの管理
When you create other types of network, a network is only a database entry until the first VM is
created on that network. When the first VM is created, a VLAN ID is assigned and the network
is provisioned. Also, when the last VM is destroyed, the VLAN ID is released and the network is
no longer available. With the addition of persistent network, you will have the ability to create a
network in CloudStack in which physical devices can be deployed without having to run any VMs.
Additionally, you can deploy physical devices on that network.
One of the advantages of having a persistent network is that you can create a VPC with a tier
consisting of only physical devices. For example, you might create a VPC for a three-tier application,
deploy VMs for Web and Application tier, and use physical machines for the Database tier. Another
use case is that if you are providing services by using physical hardware, you can define the network
as persistent and therefore even if all its VMs are destroyed the services will not be discontinued.
19.20.1. Persistent Network Considerations
• Persistent network is designed for isolated networks.
• All default network offerings are non-persistent.
• A network offering cannot be editable because changing it affects the behavior of the existing
networks that were created using this network offering.
• When you create a guest network, the network offering that you select defines the network
persistence. This in turn depends on whether persistent network is enabled in the selected
network offering.
• An existing network can be made persistent by changing its network offering to an offering that
has the Persistent option enabled. While setting this property, even if the network has no running
VMs, the network is provisioned.
• An existing network can be made non-persistent by changing its network offering to an offering
that has the Persistent option disabled. If the network has no running VMs, during the next
network garbage collection run the network is shut down.
• When the last VM on a network is destroyed, the network garbage collector checks if the network
offering associated with the network is persistent, and shuts down the network only if it is nonpersistent.
19.20.2. Creating a Persistent Guest Network
To create a persistent network, perform the following:
1. Create a network offering with the Persistent option enabled.
See the Administration Guide.
2. Select Network from the left navigation pane.
3. Select the guest network that you want to offer this network service to.
4. Click the Edit button.
5. From the Network Offering drop-down, select the persistent network offering you have just
created.
234
Creating a Persistent Guest Network
6. [OK]をクリックします。
235
236
システム仮想マシンの操作
CloudStack では、いくつかの種類のシステム仮想マシンを使用してクラウドでタスクを実行します。これらのシ
ステム仮想マシンは通常、環境の規模および緊急のニーズに基づいて、CloudStack により管理、作成、起動、
および停止されます。ただし、管理者はトラブルシューティングを円滑にするため、システム仮想マシンの存在と
その役割を理解しておく必要があります。
注記
You can configure the system.vm.random.password parameter to create a random
system VM password to ensure higher security. If you reset the value for
system.vm.random.password to true and restart the Management Server, a random
password is generated and stored encrypted in the database. You can view
the decrypted password under the system.vm.password global parameter on the
CloudStack UI or by calling the listConfigurations API.
20.1. システム仮想マシンテンプレート
システム仮想マシンは単一のテンプレートから作成されます。システム仮想マシンには、次の特性があります。
• Debian 6.0 ("Squeeze"), 2.6.32 kernel with the latest security patches from the Debian security
APT repository
• セキュリティ上脆弱な箇所を小さくするために、最小限のパッケージがインストールされています。
• Xen/VMWare 上のパフォーマンスを向上する 32 ビット版です。
• すべてのハイパーバイザー上で最適なパフォーマンスを実現する、Xen PV ドライバー、KVM virtio ドライ
バー、および VMware Tools を備えた pvops カーネルを使用します。
• Xen Tools が含まれ、パフォーマンスを監視できます。
• Debian リポジトリから入手する最新バージョンの HAProxy、iptables、IPsec、Apache により、セキュリティ
保護と速度の向上を保証します。
• Sun/Oracle の最新バージョンの JRE により、セキュリティ保護と速度の向上を保証します。
20.2. VMware のための複数のシステム仮想マシンのサポート
CloudStack の各ゾーンには単一のシステム仮想マシンが存在します。この仮想マシンによって、テンプレート
のダウンロードとアップロード、ISO のアップロードなどのテンプレート処理タスクが実行されます。VMware を
使用するゾーンでは追加のシステム仮想マシンを起動して、スナップショットやプライベートテンプレートの作成
などの
VMware
特有のタスクを処理できます。負荷が増加すると、VMware
特有のタスクのために
CloudStack 管理サーバーにより追加のシステム仮想マシンが起動されます。これらのシステム仮想マシンに
送信されるすべてのコマンドが管理サーバーにより監視および重み付けされ、追加のシステム仮想マシンの動
的な負荷分散と拡張が実行されます。
20.3. コンソールプロキシー
コンソールプロキシーはWeb UI経由でコンソールビューを表示するロールを持ったシステム仮想マシンの一
種です。ユーザーのブラウザーからハイパーバイザーのVNCポート経由でゲストのコンソールに接続します。管
理者とエンドユーザーのWeb UIの両方からコンソール接続が可能です。
237
第20章システム仮想マシンの操作
Clicking a console icon brings up a new window. The AJAX code downloaded into that window
refers to the public IP address of a console proxy VM. There is exactly one public IP address
allocated per console proxy VM. The AJAX application connects to this IP. The console proxy then
proxies the connection to the VNC port for the requested VM on the Host hosting the guest.
注記
ハイパーバイザーはVNCのためにたくさんのポートを割り当てます。それにより、複数のVNC
セッションを同時に行うことができます。
ゲストの仮想IPには何のトラフィックも発生しませんので、ゲスト内でVNCを有効にする必要はありません。
コンソールプロキシーVMはアクティブなセッションの数を管理サーバーに定期的にレポートします。デフォルト
のレポート間隔は5分です。これは管理サーバーのグローバル設定のパラメーターの
consoleproxy.loadscan.intervalにより変更可能です。
ゲストVMのコンソールプロキシーへの割り当てに際し、まず最初にゲストVMのコンソールプロキシーへの前回
セッションがあるかを確認します。もしある場合、管理サーバーはそのプロキシーVMの負荷に関わらず、ゲスト
VMをそのコンソールプロキシーVMに割り当てます。そうでない場合、新しいセッションを処理できるキャパシ
ティのあるコンソールプロキシーVMの中から最初に選ばれたものが使用されます。
コンソールプロキシーは管理者により再起動できます。しかし、それにより、ユーザーの既存のコンソールセッ
ションは中断されます。
20.3.1. Using a SSL Certificate for the Console Proxy
The console viewing functionality uses a dynamic DNS service under the domain name
realhostip.com to assist in providing SSL security to console sessions. The console proxy is assigned
a public IP address. In order to avoid browser warnings for mismatched SSL certificates, the URL for
the new console window is set to the form of https://aaa-bbb-ccc-ddd.realhostip.com. You will see
this URL during console session creation. CloudStack includes the realhostip.com SSL certificate
in the console proxy VM. Of course, CloudStack cannot know about the DNS A records for our
customers' public IPs prior to shipping the software. CloudStack therefore runs a dynamic DNS
server that is authoritative for the realhostip.com domain. It maps the aaa-bbb-ccc-ddd part of
the DNS name to the IP address aaa.bbb.ccc.ddd on lookups. This allows the browser to correctly
connect to the console proxy's public IP, where it then expects and receives a SSL certificate for
realhostip.com, and SSL is set up without browser warnings.
20.3.2. コンソールプロキシの SSL 証明書とドメインの変更
If the administrator prefers, it is possible for the URL of the customer's console session to show
a domain other than realhostip.com. The administrator can customize the displayed domain by
selecting a different domain and uploading a new SSL certificate and private key. The domain
must run a DNS service that is capable of resolving queries for addresses of the form aaa-bbb-cccddd.your.domain to an IPv4 IP address in the form aaa.bbb.ccc.ddd, for example, 202.8.44.1. To
change the console proxy domain, SSL certificate, and private key:
1. Set up dynamic name resolution or populate all possible DNS names in your public IP range into
your existing DNS server with the format aaa-bbb-ccc-ddd.company.com -> aaa.bbb.ccc.ddd.
2. 秘密鍵と CSR(Certificate Signing Request:証明書署名要求)を生成します。openssl を使用して秘密
鍵と公開鍵のペアおよび CSR を生成するときは、CloudStack ユーザーインターフェイスに貼り付ける秘
密鍵を PKCS#8 形式に変換してください。
238
仮想ルーター
a. 新しい 2048 ビットの秘密鍵を生成します。
openssl genrsa -des3 -out yourprivate.key 2048
b. 新しい証明書の CSR を生成します。
openssl req -new -key yourprivate.key -out yourcertificate.csr
c. 信頼できる証明機関の Web サイトを開き、SSL 証明書を購入し、CSR を送信します。その後、有効な
証明書を受け取ります。
d. 秘密鍵の形式を PKCS#8 暗号化形式に変換します。
openssl pkcs8 -topk8 -in yourprivate.key -out yourprivate.pkcs8.encrypted.key
e. 暗号化された PKCS#8 秘密鍵を CloudStack で使用できる PKCS#8 形式に変換します。
openssl pkcs8 -in yourprivate.pkcs8.encrypted.key -out yourprivate.pkcs8.key
3. In the Update SSL Certificate screen of the CloudStack UI, paste the following:
• The certificate you've just generated.
• The private key you've just generated.
• 適切な新しいドメイン名(たとえば、company.com)
4. 適切な新しいドメイン名(たとえば、company.com)
This stops all currently running console proxy VMs, then restarts them with the new certificate
and key. Users might notice a brief interruption in console availability.
The Management Server generates URLs of the form "aaa-bbb-ccc-ddd.company.com" after this
change is made. The new console requests will be served with the new DNS domain name,
certificate, and key.
20.4. 仮想ルーター
仮想ルーターはシステム VM の一つであり、CloudStack で良く利用されるサービスプロバイダーのです。エン
ドユーザーは仮想ルーターに直接アクセスすることはできず、ping を打つことやいくつかの設定(ポートフォワー
ディングなど)のみができます。しかし、ユーザーは仮想ルーターに対しての SSH アクセスはできません。
There is no mechanism for the administrator to log in to the virtual router. Virtual routers can be
restarted by administrators, but this will interrupt public network access and other services for end
users. A basic test in debugging networking issues is to attempt to ping the virtual router from a
guest VM. Some of the characteristics of the virtual router are determined by its associated system
service offering..
239
第20章システム仮想マシンの操作
20.4.1. 仮想ルーターの構成
次の項目を設定することができます。
• IP レンジ
• サポートされるネットワークサービス
• 仮想ルーターで提供されるネットワークサービスに対してのデフォルトのドメイン名
• ゲートウェイの IP アドレス
• CloudStack がどれくらいの頻度で CloudStack 仮想ルーターから使用状況を取得するか。もし仮想ルー
ターからトラフィックの計測データを収集したい場合、グローバル設定の [router.stats.interval] を設定して
ください。仮想ルーターからネットワークの使用状況を収集しない場合は 0 を設定してください。
20.4.2. システムサービスオファリングによる仮想ルーターのアップグレード
CloudStack が仮想ルーターを作成する際はデフォルトのシステムサービスオファリングで定義されたデフォル
ト設定を利用します。詳細は �System Service Offerings� を参照してください。単一ゲストネットワーク上の全
ての仮想ルーターは同じシステムサービスオファリングを利用します。カスタムのシステムサービスオファリング
を作成して適用することにより、仮想ルーターの機能をアップグレードすることができます。
1. カスタムのシステムサービスオファリングを定義します。詳細は �Creating a New System Service
Offering� を参照してください。[System VM Type] から [Domain Router] を選択します。
2. Associate the system service offering with a network offering. See "Creating Network Offerings"
in the Administrator's Guide.
3. 新しいシステムサービスオファリングを利用したい仮想ルーターが存在するネットワークに対しネットワーク
オファリングを適用します。もし新しいネットワークに対し適用したい場合は「追加のゲストネットワークの追
加」の手順を参照してください。既存の仮想ルーターのサービスオファリングを変更したい場合は ��
�� の手順を参照してください。
20.4.3. 仮想ルーターのベストプラクティス
• 注意: ハイパーバイザーコンソールからの仮想マシンの再起動は全ての iptables 規則を削除します。この
問題へのワークアラウンドは CloudStack インターフェイスから仮想ルーターの停止と起動を行なってくださ
い。
• WARNING: Do not use the destroyRouter API when only one router is available in the network,
because restartNetwork API with the cleanup=false parameter can't recreate it later. If you want
to destroy and recreate the single router available in the network, use the restartNetwork API
with the cleanup=true parameter.
20.5. セカンダリストレージ VM
追加ホスト上で CloudStack のセカンダリストレージ VM はセカンダリストレージをマウントし書き込みします。
セカンダリストレージ VM のもう一つの目的としてテンプレートや様々なプロトコル越しの URL からの ISO イ
メージの検索が挙げられます。
セカンダリストレージ VM は様々なセカンダリストレージの動作に対してのバックグラウンドタスクを提供し、
ゾーンに対しての新しいテンプレートのダウンロードやゾーン間のテンプレートのコピー、バックアップ用のス
ナップショットを行います。
240
セカンダリストレージ VM
必要に応じて管理者はセカンダリストレージ VM にログインすることもできます。
241
242
システムの信頼性と高可用性
21.1. HA for Management Server
The CloudStack Management Server should be deployed in a multi-node configuration such that
it is not susceptible to individual server failures. The Management Server itself (as distinct from the
MySQL database) is stateless and may be placed behind a load balancer.
Normal operation of Hosts is not impacted by an outage of all Management Serves. All guest VMs
will continue to work.
When the Management Server is down, no new VMs can be created, and the end user and admin
UI, API, dynamic load distribution, and HA will cease to work.
21.2. Management Server Load Balancing
CloudStack can use a load balancer to provide a virtual IP for multiple Management Servers. The
administrator is responsible for creating the load balancer rules for the Management Servers. The
application requires persistence or stickiness across multiple sessions. The following chart lists the
ports that should be load balanced and whether or not persistence is required.
Even if persistence is not required, enabling it is permitted.
Source Port
Destination Port
Protocol
Persistence Required?
80 or 443
8080 (or 20400 with
AJP)
HTTP (or AJP)
Yes
8250
8250
TCP
Yes
8096
8096
HTTP
No
In addition to above settings, the administrator is responsible for setting the 'host' global config
value from the management server IP to load balancer virtual IP address. If the 'host' value is not
set to the VIP for Port 8250 and one of your management servers crashes, the UI is still available
but the system VMs will not be able to contact the management server.
21.3. 高可用性が有効な仮想マシン
ユーザーは、仮想マシンで高可用性を有効に指定できます。デフォルトでは仮想ルーターの仮想マシンとシステ
ム仮想マシンはすべて、自動的に高可用性が有効なマシンに構成されます。高可用性が有効な仮想マシンが
クラッシュすると、CloudStack がクラッシュを検出し、同じ利用可能ゾーン内で仮想マシンを再起動します。異
なる利用可能ゾーンをまたがって高可用性を有効にすることはできません。CloudStack は、仮想マシンの再
起動について慎重なポリシーを備えており、同じ仮想マシンの 2 つのインスタンスは同時に実行されません。管
理サーバーにより、同じクラスター内の別のホストで仮想マシンの起動が試行されます。
高可用性機能は、iSCSI または NFS のプライマリストレージで機能します。ローカルストレージでの高可用性は
サポートされていません。
21.4. ホストの高可用性
ユーザーは、仮想マシンで高可用性を有効に指定できます。仮想ルーターの仮想マシンとシステム仮想マシン
はすべて、自動的に高可用性が有効なマシンに構成されます。高可用性が有効な仮想マシンがクラッシュする
と、CloudStack がクラッシュを検出し、同じ利用可能ゾーン内で仮想マシンを再起動します。異なる利用可能
243
第21章システムの信頼性と高可用性
ゾーンをまたがって高可用性を有効にすることはできません。CloudStack プラットフォームは、仮想マシンの再
起動について慎重なポリシーを備えており、同じ仮想マシンの 2 つのインスタンスは同時に実行されません。管
理サーバーにより、同じクラスター内の別のホストで仮想マシンの起動が試行されます。
高可用性機能は、iSCSI または NFS のプライマリストレージで機能します。ローカルストレージでの高可用性は
サポートされていません。
21.4.1. Dedicated HA Hosts
One or more hosts can be designated for use only by HA-enabled VMs that are restarting due to
a host failure. Setting up a pool of such dedicated HA hosts as the recovery destination for all HAenabled VMs is useful to:
• Make it easier to determine which VMs have been restarted as part of the CloudStack highavailability function. If a VM is running on a dedicated HA host, then it must be an HA-enabled
VM whose original host failed. (With one exception: It is possible for an administrator to manually
migrate any VM to a dedicated HA host.).
• Keep HA-enabled VMs from restarting on hosts which may be reserved for other purposes.
The dedicated HA option is set through a special host tag when the host is created. To allow
the administrator to dedicate hosts to only HA-enabled VMs, set the global configuration variable
ha.tag to the desired tag (for example, "ha_host"), and restart the Management Server. Enter the
value in the Host Tags field when adding the host(s) that you want to dedicate to HA-enabled VMs.
注記
If you set ha.tag, be sure to actually use that tag on at least one host in your cloud.
If the tag specified in ha.tag is not set for any host in the cloud, the HA-enabled
VMs will fail to restart after a crash.
21.5. プライマリストレージの停止とデータ損失
プライマリストレージが停止すると、そのストレージデバイスに格納されているすべての仮想マシンがハイパー
バイザーにより即座に停止されます。プライマリストレージがオンラインに戻ると、高可用性とマークされている
ゲストは実行可能になり次第再起動されます。NFS の場合は、問題の性質に応じて、ハイパーバイザーの許可
により仮想マシンが動作し続ける場合があります。たとえば NFS がハングすると、ストレージ接続が回復するま
で、ゲスト仮想マシンは一時停止になります。プライマリストレージはバックアップされる設計になっていません。
プライマリストレージの個々のボリュームは、スナップショットを使用してバックアップできます。
21.6. セカンダリストレージの停止とデータ損失
セカンダリストレージサーバーが 1 台のみのゾーンでは、セカンダリストレージが停止すると使用できなくなる
機能がありますが、動作中のゲスト仮想マシンは影響を受けません。ユーザーが選択したテンプレートを使用し
て仮想マシンを作成できなくなる可能性があります。ユーザーがスナップショットの保存や保存されたスナップ
ショットの調査および復元を実行できなくなる可能性もあります。セカンダリストレージがオンラインに戻ると、こ
れらの機能は自動的に使用できるようになります。
セカンダリストレージのデータ損失は、テンプレート、スナップショット、ISO イメージなどの、最近追加されたユー
ザーデータに影響を及ぼします。セカンダリストレージは定期的にバックアップする必要があります。各ゾーンに
複数のセカンダリストレージサーバーを準備し、システムのスケーラビリティを向上させることができます。
244
クラウドの管理
22.1. Using Tags to Organize Resources in the Cloud
A tag is a key-value pair that stores metadata about a resource in the cloud. Tags are useful for
categorizing resources. For example, you can tag a user VM with a value that indicates the user's
city of residence. In this case, the key would be "city" and the value might be "Toronto" or "Tokyo."
You can then request CloudStack to find all resources that have a given tag; for example, VMs for
users in a given city.
You can tag a user virtual machine, volume, snapshot, guest network, template, ISO, firewall rule,
port forwarding rule, public IP address, security group, load balancer rule, project, VPC, network
ACL, or static route. You can not tag a remote access VPN.
You can work with tags through the UI or through the API commands createTags, deleteTags, and
listTags. You can define multiple tags for each resource. There is no limit on the number of tags
you can define. Each tag can be up to 255 characters long. Users can define tags on the resources
they own, and administrators can define tags on any resources in the cloud.
An optional input parameter, "tags," exists on many of the list* API commands. The following
example shows how to use this new parameter to find all the volumes having tag region=canada
OR tag city=Toronto:
command=listVolumes
&listAll=true
&tags[0].key=region
&tags[0].value=canada
&tags[1].key=city
&tags[1].value=Toronto
The following API commands have the "tags" input parameter:
• listVirtualMachines
• ボリュームリスト
• スナップショットリスト
• listNetworks
• listTemplates
• listIsos
• listFirewallRules
• listPortForwardingRules
• listPublicIpAddresses
• listSecurityGroups
• listLoadBalancerRules
• listProjects
245
第22章クラウドの管理
• listVPCs
• listNetworkACLs
• listStaticRoutes
22.2. Changing the Database Configuration
The CloudStack Management Server stores database configuration information (e.g., hostname,
port, credentials) in the file /etc/cloud/management/db.properties. To effect a change, edit this file
on each Management Server, then restart the Management Server.
22.3. Changing the Database Password
You may need to change the password for the MySQL account used by CloudStack. If so, you'll
need to change the password in MySQL, and then add the encrypted password to /etc/cloud/
management/db.properties.
1. Before changing the password, you'll need to stop CloudStack's management server and the
usage engine if you've deployed that component.
# service cloudstack-management stop
# service cloudstack-usage stop
2. Next, you'll update the password for the CloudStack user on the MySQL server.
# mysql -u root -p
At the MySQL shell, you'll change the password and flush privileges:
update mysql.user set password=PASSWORD("newpassword123") where User='cloud';
flush privileges;
quit;
3. The next step is to encrypt the password and copy the encrypted password to CloudStack's
database configuration (/etc/cloud/management/db.properties).
# java -classpath /usr/share/java/cloud-jasypt-1.8.jar \ org.jasypt.intf.cli.JasyptPBEStringEncryptionCLI
encrypt.sh \ input="newpassword123" password="`cat /etc/cloud/management/key`" \ verbose=false
File encryption type
Note that this is for the file encryption type. If you're using the web encryption
type then you'll use password="management_server_secret_key"
4. Now, you'll update /etc/cloud/management/db.properties with the new ciphertext. Open /etc/
cloud/management/db.properties in a text editor, and update these parameters:
246
管理者アラート
db.cloud.password=ENC(encrypted_password_from_above)
db.usage.password=ENC(encrypted_password_from_above)
5. After copying the new password over, you can now start CloudStack (and the usage engine,
if necessary).
# service cloudstack-management start
# service cloudstack-usage start
22.4. 管理者アラート
システム生成のアラートとイベントは、クラウド管理に役立ちます。アラートは通常、電子メールで配信され、クラ
ウドでエラーが発生していることを管理者に通知します。アラートの動作は構成できます。
イベントは、クラウド内のすべてのユーザーおよび管理者の操作を追跡します。たとえば、ゲスト仮想マシンが起
動するたびに、関連するイベントが作成されます。イベントは、管理サーバーのデータベースに格納されます。
電子メールは、次のような場合に管理者に送信されます。
• 管理サーバークラスターで、CPU、メモリ、またはストレージリソースが不足している。
• 管理サーバーがホストからハートビートを 3 分以上受信していない。
• ホストクラスターで、CPU、メモリ、またはストレージリソースが不足している。
22.5. ネットワークドメイン名のカスタマイズ
ルート管理者は、ネットワーク、アカウント、ドメイン、ゾーン、または CloudStack 環境全体のレベルで、オプショ
ンでカスタム DNS サフィックスを割り当てることができます。カスタムドメイン名を指定して有効にするには、次
の手順に従います。
1. 望ましい範囲で DNS サフィックスを設定します。
• ネットワークレベルでは、ユーザーインターフェイスで新しいネットワークを作成するときに(��を
参照)、または、CloudStack API の updateNetwork コマンドを使用して DNS サフィックスを割り当て
ることができます。
• アカウント、ドメイン、またはゾーンのレベルでは、適切な
CloudStack
API
コマンド
(createAccount、editAccount、 createDomain、editDomain、createZone、または editZone)を使
用して DNS サフィックスを割り当てることができます。
• グローバルレベルでは、構成パラメーターの guest.domain.suffix を使用します。ユーザーインターフェ
イスからパラメーターにアクセスするには、管理者用ユーザーインターフェイスにログオンし、
[Configuration]、[Global
Settings]の順に選択します。CloudStack
API
コマンドの
updateConfiguration を使用することもできます。このグローバル構成を変更した後で管理サーバーを
再起動して、新しい設定を有効にします。
2. 既存のネットワークで新しい
DNS
サフィックスを有効にするには、CloudStack
API
コマンドの
updateNetwork を呼び出します。新しいネットワークを作成するときに DNS サフィックスを指定した場合
は、この手順は不要です。
247
第22章クラウドの管理
使用するネットワークドメインのソースは、次の規則によって決まります。
• For all networks, if a network domain is specified as part of a network's own configuration, that
value is used.
• アカウント固有のネットワークでは、アカウント用に指定されたネットワークドメインが使用されます。何も指定
されていない場合は、ドメイン、ゾーン、グローバル構成の順に値が検索されます。
• ドメイン固有のネットワークでは、ドメイン用に指定されたネットワークドメインが使用されます。何も指定され
ていない場合は、ゾーン、グローバル構成の順に値が検索されます。
• ゾーン固有のネットワークでは、ゾーン用に指定されたネットワークドメインが使用されます。何も指定されて
いない場合は、グローバル構成の値が検索されます。
22.6. Stopping and Restarting the Management Server
The root administrator will need to stop and restart the Management Server from time to time.
For example, after changing a global configuration parameter, a restart is required. If you have
multiple Management Server nodes, restart all of them to put the new parameter value into effect
consistently throughout the cloud..
To stop the Management Server, issue the following command at the operating system prompt on
the Management Server node:
# service cloudstack-management stop
To start the Management Server:
# service cloudstack-management start
To stop the Management Server:
# service cloudstack-management stop
248
CloudStack API
CloudStack API は低レベル API で、Web ユーザーインターフェイスの実装に使用されます。この API
は、EC2/S3 や新しい DMTF 標準などのそのほかの一般的な API の実装ベースにもなります。
多くの CloudStack API は非同期呼び出しを利用しています。これらの API を呼び出すと、即座にジョブ ID
が即座に戻されます。このジョブ ID を使用して、後でジョブの状態をクエリすることができます。また、影響を受
けたリソースに状態呼び出しを実行することで、その状態の一部が示されます。
この API は REST に類似したクエリ基盤を備えており、結果を XML または JSON で戻します。
1
2
See the Developer’s Guide and the API Reference .
23.1. プロビジョニングと認証 API
CloudStack では、顧客が独自のユーザープロビジョニングインフラストラクチャを持っていることが期待されま
す。したがって、そのような既存のシステムを統合する API が提供されます。これらのシステムから CloudStack
を呼び出し、ユーザーを追加および削除します。
CloudStack は、プラグ可能な認証子をサポートします。デフォルトでは、CloudStack は、この認証子がユー
ザーのパスワードと共にプロビジョニングされ、その結果、認証がローカルで行われることを前提としています。
ただし、外部で認証することもできます。例については、「LDAP サーバーによるユーザー認証」を参照してくだ
さい。
23.2. アロケーター
CloudStack では、管理者がカスタムアロケーターを開発し、新しいゲストを配置するホストとゲスト仮想ディス
クイメージを割り当てるストレージホストを選択することができます。
23.3. ユーザーデータとメタデータ
CloudStack は、展開された仮想マシンにユーザーデータをアタッチするための API アクセスを提供します。展
開された仮想マシンは、仮想ルーターを経由してインスタンスメタデータにもアクセスします。
仮想ルーターの IP アドレスがわかれば、ユーザーデータにアクセスできます。この IP アドレスがわかったら、次
の手順に従ってユーザーデータにアクセスします。
1. 次のコマンドを実行して、仮想ルーターを見つけます。
# cat /var/lib/dhclient/dhclient-eth0.leases | grep dhcp-server-identifier | tail -1
2. 上のコマンドの結果を使用して次のコマンドを実行し、ユーザーデータにアクセスします。
# curl http://10.1.1.1/latest/user-data
「http://10.1.1.1/latest/meta-data/{metadata type}」形式の URL を使用して、メタデータにも同様の方
法でアクセスできます(後方互換性を維持するため、以前の「http://10.1.1.1/latest/{metadata type}」形
式の URL もサポートされます)。メタデータについては、次のいずれか 1 つを使用します。
• service-offering : 仮想マシンサービスオファリングの説明です。
1
2
http://docs.cloudstack.org/CloudStack_Documentation/Developer's_Guide%3A_CloudStack
http://docs.cloudstack.org/CloudStack_Documentation/API_Reference%3A_CloudStack
249
第23章 CloudStack API
• availability-zone : ゾーン名です。
• local-ipv4 : 仮想マシンのゲスト IP アドレスです。
• local-hostname : 仮想マシンのホスト名です。
• public-ipv4 : ルーターの最初のパブリック IP アドレスです(例:eth2 の最初の IP アドレス)。
• public-hostname : public-ipv4 と同じです。
• instance-id : 仮想マシンのインスタンス名です。
250
チューニング
ここでは、クラウドのパフォーマンスを向上させるヒントについて説明します。
24.1. 性能監視
エンドユーザーおよび管理者は、ホストおよびゲストのパフォーマンス監視が可能です。これにより、ユーザーが
リソースの使用状況を監視し、より強力なサービスオファリングや、より大きなディスクをいつ選択するのが適切
であるかを決断させます。
24.2. 管理サーバーの最大メモリの増設
管理サーバーの負荷が高い場合は、デフォルトの最大 JVM メモリ割り当てでは不十分になる可能性がありま
す。メモリを増設するには、次の手順に従います。
1. Tomcat 構成ファイルを編集します。
/etc/cloud/management/tomcat6.conf
2. コマンドラインパラメーターの-XmxNNNm の NNN の数値を大きくします。
たとえば、現在の値が–Xmx128m の場合は、この値を–Xmx1024m 以上にします。
3. 新しい設定を有効にするには、管理サーバーを再起動します。
# service cloudstack-management restart
For more information about memory issues, see "FAQ: Memory" at Tomcat Wiki.
1
24.3. データベースのバッファープールサイズの設定
データとインデックスをキャッシュするために、MySQL データベースに十分なメモリ容量を提供することが重要
です。
1. Edit the MySQL configuration file:
/etc/my.cnf
2. datadir行の下の、[mysqld]セクション内の次の行に挿入します。状況に応じた値を使用してくださ
い。MySQLが管理サーバーとして同サーバー上にある場合、RAMの40% oを、MySQLに専用サーバーが
ある場合、RAMの70% oをバッファープールに設定しましょう。次の例では1024MBのRAMを持った専用
サーバーを想定しています。
innodb_buffer_pool_size=700M
3. MySQL サービスを再起動します。
# service mysqld restart
1
http://wiki.apache.org/tomcat/FAQ/Memory
251
第24章チューニング
For more information about the buffer pool, see "The InnoDB Buffer Pool" at MySQL Reference
2
Manual .
24.4. ホスト毎の仮想マシン数制限の設定と監視
$PRODUCT; 管理者は各クラスターの仮想マシンインスタンス数を監視し、ハイパーバイザーが処理できる最
大数に達した場合それ以上の割り当てを無効にする必要があります。1台ないしは2台のホストで障害が発生
した際の仮想マシンが他のホスト上で自動的に再展開することによる仮想マシンの負荷の増大に備えて十分
な余剰を持たせることに注意してください。ホスト毎の許容される仮想マシン数に関しては利用するハイパーバ
イザーのドキュメントを参照してください。また、その際 $PRODUCT; のグローバル設定からデフォルトの制限
値を設定します。各クラスターの仮想マシンの状況はいつでも確認することができます。ホスト障害時に安全な
レベル内に収まるよう仮想マシン数を維持してください。例として N 台のホストがクラスター内にあり、1台のホ
スト障害まで許容する場合は最大で (N-1) * (ホスト毎の許容制限) で算出されます。一度クラスター上の仮想
マシン数が制限に達したら $PRODOUCT; UI からクラスターへのそれ以上の仮想マシンの割り当てを無効化
します。
24.5. XenServer の dom0 メモリの構成
XenServer
の
dom0
へのメモリ割り当てを増やすために、dom0
の設定を構成します。これによ
り、XenServer でより多くの仮想マシンを制御できるようになります。XenServer の dom0 に 2940MB の
3
RAM を割り当てることをお勧めします。この方法について詳しくは、Citrix Knowledgebase Article を参照して
ください。このアーティクルで言及されているのは XenServer 5.6 ですが、同じことが XenServer 6.0 にも当
てはまります。
2
3
http://dev.mysql.com/doc/refman/5.5/en/innodb-buffer-pool.html
http://support.citrix.com/article/CTX126531
252
Troubleshooting
25.1. イベント
An event is essentially a significant or meaningful change in the state of both virtual and physical
resources associated with a cloud environment. Events are used by monitoring systems, usage and
billing systems, or any other event-driven workflow systems to discern a pattern and make the right
business decision. In CloudStack an event could be a state change of virtual or psychical resources,
an action performed by an user (action events), or policy based events (alerts).
25.1.1. イベントログ
2 種類のイベントが CloudStack イベントログに記録されます。標準的なイベントについてはイベントの成功ま
たは失敗が記録され、失敗したジョブまたはプロセスを特定するために使用することができます。長期間実行す
るジョブのイベントもあります。非同期ジョブのイベントは、ジョブがスケジュールされたとき、ジョブが開始され
たとき、およびジョブが完了したときに記録されます。そのほかの長期間実行する同期ジョブのイベントは、ジョ
ブが開始されたときと完了したときに記録されます。長期間実行する同期ジョブと非同期ジョブのイベントログ
を使用して、保留中のジョブの状態に関する詳細情報を取得したり、ハングしている、または開始されていない
ジョブを特定したりできます。次に、これらのイベントに関してさらに説明します。
25.1.2. Event Notification
Event notification framework provides a means for the Management Server components to
publish and subscribe to CloudStack events. Event notification is achieved by implementing the
concept of event bus abstraction in the Management Server. An event bus is introduced in the
Management Server that allows the CloudStackcomponents and extension plug-ins to subscribe
to the events by using the Advanced Message Queuing Protocol (AMQP) client. In CloudStack, a
default implementation of event bus is provided as a plug-in that uses the RabbitMQ AMQP client.
The AMQP client pushes the published events to a compatible AMQP server. Therefore all the
CloudStack events are published to an exchange in the AMQP server.
A new event for state change, resource state change, is introduced as part of Event notification
framework. Every resource, such as user VM, volume, NIC, network, public IP, snapshot, and
template, is associated with a state machine and generates events as part of the state change.
That implies that a change in the state of a resource results in a state change event, and the
event is published in the corresponding state machine on the event bus. All the CloudStack events
(alerts, action events, usage events) and the additional category of resource state change events,
are published on to the events bus.
Use Cases
The following are some of the use cases:
• Usage or Billing Engines: A third-party cloud usage solution can implement a plug-in that can
connects to CloudStack to subscribe to CloudStack events and generate usage data. The usage
data is consumed by their usage software.
• AMQP plug-in can place all the events on the a message queue, then a AMQP message broker
can provide topic-based notification to the subscribers.
• Publish and Subscribe notification service can be implemented as a pluggable service in
CloudStack that can provide rich set of APIs for event notification, such as topics-based
253
第25章 Troubleshooting
subscription and notification. Additionally, the pluggable service can deal with multi-tenancy,
authentication, and authorization issues.
Configuration
As a CloudStack administrator, perform the following one-time configuration to enable event
notification framework. At run time no changes can control the behaviour.
1. Open 'componentContext.xml.
2. Define a bean named eventNotificationBus as follows:
• name : Specify a name for the bean.
• server : The name or the IP address of the RabbitMQ AMQP server.
• port : The port on which RabbitMQ server is running.
• username : The username associated with the account to access the RabbitMQ server.
• password : The password associated with the username of the account to access the
RabbitMQ server.
• exchange : The exchange name on the RabbitMQ server where CloudStack events are
published.
A sample bean is given below:
<bean id="eventNotificationBus" class="org.apache.cloudstack.mom.rabbitmq.RabbitMQEventBus">
<property name="name" value="eventNotificationBus"/>
<property name="server" value="127.0.0.1"/>
<property name="port" value="5672"/>
<property name="username" value="guest"/>
<property name="password" value="guest"/>
<property name="exchange" value="cloudstack-events"/>
</bean>
The
eventNotificationBus
bean
org.apache.cloudstack.mom.rabbitmq.RabbitMQEventBus class.
represents
the
3. 管理サーバーを再起動します。
25.1.3. 標準イベント
イベントログには、3 種類の標準イベントが記録されます。
• INFO : 操作が正常に実行されたときに、このイベントが生成されます。
• WARN:このイベントは次の状況で生成されます。
• テンプレートダウンロードの監視中に、ネットワークが切断されたとき。
• テンプレートダウンロードが中止されたとき。
• ストレージサーバーの問題により、ミラーストレージサーバーにボリュームがフェールオーバーしたとき。
• ERROR : 操作が正常に実行されなかったときに、このイベントが生成されます。
254
長期間実行するジョブのイベント
25.1.4. 長期間実行するジョブのイベント
イベントログには、3 種類の標準イベントが記録されます。
• INFO : 操作が正常に実行されたときに、このイベントが生成されます。
• WARN : このイベントは次の状況で生成されます。
• テンプレートダウンロードの監視中に、ネットワークが切断されたとき。
• テンプレートダウンロードが中止されたとき。
• ストレージサーバーの問題により、ミラーストレージサーバーにボリュームがフェールオーバーしたとき。
• ERROR : 操作が正常に実行されなかったときに、このイベントが生成されます。
25.1.5. Event Log Queries
Database logs can be queried from the user interface. The list of events captured by the system
includes:
• Virtual machine creation, deletion, and on-going management operations
• Virtual router creation, deletion, and on-going management operations
• Template creation and deletion
• Network/load balancer rules creation and deletion
• Storage volume creation and deletion
• User login and logout
25.2. サーバーログに関わる作業
The CloudStack Management Server logs all web site, middle tier, and database activities for
diagnostics purposes in /var/log/cloudstack/management/. The CloudStack logs a variety of error
messages. We recommend this command to find the problematic output in the Management Server
log:.
注記
�コマンドをコピーして実行するときは、単一の行として貼り付けたことを確認してください。
一部のドキュメントビューアーでは、コピーしたテキストに不要な改行が含まれる可能性があ
ります。
grep -i -E 'exception|unable|fail|invalid|leak|warn|error' /var/log/cloudstack/management/managementserver.log
CloudStack では、ジョブ ID を使用して要求を処理します。ログでエラーを発見して問題をデバッグしたい場合
は、管理サーバーログ中のジョブ ID を grep で検索します。たとえば、次のエラーメッセージを発見したとしま
す。
255
第25章 Troubleshooting
2010-10-04 13:49:32,595 ERROR [cloud.vm.UserVmManagerImpl] (Job-Executor-11:job-1076) Unable to find any
host for [User|i-8-42-VM-untagged]
ジョブ ID が 1076 であることに注意してください。次の grep 検索によって、ジョブ 1076 に関連するイベント
を追跡することができます。
grep "job-1076)" management-server.log
The CloudStack Agent Server logs its activities in /var/log/cloudstack/agent/.
25.3. エクスポートしたプライマリストレージのデータ損失
症状
Linux NFS として提供されているプライマリストレージを iSCSI ボリュームとしてエクスポートすると既存データ
の損失が発生する。
原因
外部のクライアントから特定プールがマウントされている可能性があります。この場合、 LVM がデータを一掃
し、ボリューム上の全てのデータが失われます。
解決方法
LUN エクスポートの設定をした際、サブネットマスクを指定することでアクセスが許可されている IP アドレスレ
ンジを除外します。以下に例を示します。
echo “/export 192.168.1.0/24(rw,async,no_root_squash)” > /etc/exports
上記のコマンドをあなたの環境に合わせて修正します。
詳細情報
See the export procedure in the "Secondary Storage" section of the CloudStack Installation Guide
25.4. 喪失した仮想ルーターの復旧
症状
仮想ルーターが起動中だがホストが切断され、仮想ルーターが予期せず動作しなくなる。
原因
仮想ルーターがダウン状態にあるか通信が切断された。
解決方法
仮想ルーターが恒久的にダウンしている、もしくは予期せず動作していないといったことが確認できたら削除し
てください。バックアップルーターが動作している場合、再度新しいルーターを作成します。(これにはルーターの
冗長構成を組んでいる必要があります)
256
vCenter が動作しない際の保守モード
• 強制的にルーターを停止させるには「stopRouter」API に「forced=true」パラメーターを追加します。
• また、ルーターを削除する前に、バックアップのルーターが正常に動作していることを確認します。さもなけれ
ば、ネットワークの通信が喪失してしまします。
• 「destoryRouter」API を利用しルーターを削除します。
「restartNetwork」API に「cleanup=false」パラメーターを追加してルーターを再構築します。ルーターの冗
長構成に関する詳細情報は「Creating a New Network Offering」を参照してください。
1
また、API シンタックスのより詳細な情報は API Reference を参照してください。
25.5. vCenter が動作しない際の保守モード
症状
ホストが保守モードであるにも関わらず、vCenter で動作しているように表示される。
原因
The CloudStack administrator UI was used to place the host in scheduled maintenance mode. This
mode is separate from vCenter's maintenance mode.
解決方法
vCenter からホストをメンテナンスモードに設定します。
詳細情報
�� を参照してください。
25.6. アップロードした vSphere 用テンプレートが展開できない場
合
症状
仮想マシンを作成しようとしても、仮想マシンが展開できない。
原因
vSphere Client で利用していた OVA ファイルをアップロードしテンプレートを作成しており、OVA が ISO イ
メージを含んでいた場合、テンプレートからの仮想マシンの展開が失敗する可能性があります。
解決方法
ISO を削除した後、テンプレートを再アップロードしてください。
1
http://docs.cloudstack.org/CloudStack_Documentation/API_Reference%3A_CloudStack
257
第25章 Troubleshooting
25.7. VMware 上で仮想マシンの電源が入らない
症状
仮想マシンの電源が入らず、次のようなエラーが表示されます。
• Unable to open Swap File
• Unable to access a file since it is locked
• Unable to access Virtual machine configuration
原因
VMware のマシンでの既知の問題です。ESX ホストは重大な仮想マシンファイルと同時に変更のあったファイ
ルシステムをロックしますがこれらのファイルは仮想マシンがパワーオフされた際正常にアンロックされないこと
があります。その後、仮想マシンの電源を入れようとすると重大なファイルにアクセスすることができず、仮想マ
シンの電源を入れることができません。
解決方法
次を参照してください。
VMware Knowledge Base Article
2
25.8. 負荷分散ルールがネットワークオファリングを変更すると失敗
する
症状
あるネットワークのネットワークオファリングを変更した後で、負荷分散ルールが動かなくなります。
原因
NetScaler のような外部の負荷分散装置を含むネットワークサービスオファリングを使用しているときに負荷分
散規則を作成し、後で CloudStack 仮想ルーターを使用するネットワークサービスオファリングへとオファリング
を変更しました。
解決方法
仮想ルーターに既存の負荷分散ルールを再設定することで、再び機能するようになります。
2
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=10051/
258
Introduction to the CloudStack API
26.1. ロール
CloudStack API には 3 種類のロールがあります：
1. ルート管理者。仮想、物理両方のリソース管理といった、クラウドの全機能を扱う。
2. ドメイン管理者。管理者の所属するドメインにあるクラウドの仮想リソースのみを扱う。
3. ユーザ。ユーザ自身の仮想インスタンス、ストレージやネットワークの管理機能のみを扱う。
26.2. API リファレンス
全ての API リファレンスドキュメントは以下のサイトから入手できます。
http://cloudstack.apache.org/docs/api/
26.3. Getting Started
To get started using the CloudStack API, you should have the following:
• URL of the CloudStack server you wish to integrate with.
• Both the API Key and Secret Key for an account. This should have been generated by the
administrator of the cloud instance and given to you.
• Familiarity with HTTP GET/POST and query strings.
• Knowledge of either XML or JSON.
• Knowledge of a programming language that can generate HTTP requests; for example, Java or
PHP.
259
260
What's New in the API?
次で説明する CloudStack バージョンの新機能はAPIで実装されています。
27.1. What's New in the API for 4.1
27.1.1. Reconfiguring Physical Networks in VMs
CloudStack provides the ability to move VMs between networks and reconfigure a VM's network.
You can remove a VM from a physical network and add to a new physical network. You can
also change the default physical network of a virtual machine. With this functionality, hybrid or
traditional server loads can be accommodated with ease.
This feature is supported on XenServer and KVM hypervisors.
The following APIs have been added to support this feature. These API calls can function only while
the VM is in running or stopped state.
27.1.1.1. addNicToVirtualMachine
The addNicToVirtualMachine API adds a new NIC to the specified VM on a selected network.
parameter
description
値
virtualmachineid
The unique ID of the VM to
which the NIC is to be added.
true
networkid
The unique ID of the network
the NIC that you add should
apply to.
true
ipaddress
The IP address of the VM on
the network.
false
The network and VM must reside in the same zone. Two VMs with the same name cannot reside in
the same network. Therefore, adding a second VM that duplicates a name on a network will fail.
27.1.1.2. removeNicFromVirtualMachine
The removeNicFromVirtualMachine API removes a NIC from the specified VM on a selected
network.
parameter
description
値
virtualmachineid
The unique ID of the VM
from which the NIC is to be
removed.
true
nicid
The unique ID of the NIC that
you want to remove.
true
Removing the default NIC is not allowed.
27.1.1.3. updateDefaultNicForVirtualMachine
The updateDefaultNicForVirtualMachine API updates the specified NIC to be the default one for
a selected VM.
261
第27章 What's New in the API?
parameter
description
値
virtualmachineid
The unique ID of the VM for
which you want to specify the
default NIC.
true
nicid
The unique ID of the NIC that
you want to set as the default
one.
true
27.1.2. IPv6 Support in CloudStack
CloudStacksupports Internet Protocol version 6 (IPv6), the recent version of the Internet
Protocol (IP) that defines routing the network traffic. IPv6 uses a 128-bit address that
exponentially expands the current address space that is available to the users. IPv6 addresses
consist of eight groups of four hexadecimal digits separated by colons, for example,
5001:0dt8:83a3:1012:1000:8s2e:0870:7454. CloudStack supports IPv6 for public IPs in shared
networks. With IPv6 support, VMs in shared networks can obtain both IPv4 and IPv6 addresses
from the DHCP server. You can deploy VMs either in a IPv6 or IPv4 network, or in a dual network
environment. If IPv6 network is used, the VM generates a link-local IPv6 address by itself, and
receives a stateful IPv6 address from the DHCPv6 server.
IPv6 is supported only on KVM and XenServer hypervisors. The IPv6 support is only an experimental
feature.
Here's the sequence of events when IPv6 is used:
1. The administrator creates an IPv6 shared network in an advanced zone.
2. The user deploys a VM in an IPv6 shared network.
3. The user VM generates an IPv6 link local address by itself, and gets an IPv6 global or site local
address through DHCPv6.
For information on API changes, see �Changed API Commands in 4.1�.
27.1.2.1. Prerequisites and Guidelines
Consider the following:
• CIDR size must be 64 for IPv6 networks.
• The DHCP client of the guest VMs should support generating DUID based on Link-layer Address
(DUID- LL). DUID-LL derives from the MAC address of guest VMs, and therefore the user VM
1
can be identified by using DUID. See Dynamic Host Configuration Protocol for IPv6 for more
information.
• The gateway of the guest network generates Router Advisement and Response messages to
Router Solicitation. The M (Managed Address Configuration) flag of Router Advisement should
enable stateful IP address configuration. Set the M flag to where the end nodes receive their IPv6
addresses from the DHCPv6 server as opposed to the router or switch.
262
IPv6 Support in CloudStack
注記
The M flag is the 1-bit Managed Address Configuration flag for Router
Advisement. When set, Dynamic Host Configuration Protocol (DHCPv6) is
available for address configuration in addition to any IPs set by using stateless
address auto-configuration.
• Use the System VM template exclusively designed to support IPv6. Download the System VM
template from http://cloudstack.apt-get.eu/systemvm/.
• The concept of Default Network applies to IPv6 networks. However, unlike IPv4 CloudStack does
not control the routing information of IPv6 in shared network; the choice of Default Network will
not affect the routing in the user VM.
• In a multiple shared network, the default route is set by the rack router, rather than the DHCP
server, which is out of CloudStack control. Therefore, in order for the user VM to get only the
default route from the default NIC, modify the configuration of the user VM, and set non-default
NIC's accept_ra to 0 explicitly. The accept_ra parameter accepts Router Advertisements and autoconfigure /proc/sys/net/ipv6/conf/interface with received data.
27.1.2.2. Limitations of IPv6 in CloudStack
The following are not yet supported:
1. Security groups
2. Userdata and metadata
3. Passwords
27.1.2.3. Guest VM Configuration for DHCPv6
For the guest VMs to get IPv6 address, run dhclient command manually on each of the VMs. Use
DUID-LL to set up dhclient.
注記
The IPv6 address is lost when a VM is stopped and started. Therefore, use the same
procedure to get an IPv6 address when a VM is stopped and started.
1. Set up dhclient by using DUID-LL.
Perform the following for DHCP Client 4.2 and above:
a. Run the following command on the selected VM to get the dhcpv6 offer from VR:
dhclient -6 -D LL <dev>
Perform the following for DHCP Client 4.1:
a. Open the following to the dhclient configuration file:
263
第27章 What's New in the API?
vi /etc/dhcp/dhclient.conf
b. Add the following to the dhclient configuration file:
send dhcp6.client-id = concat(00:03:00, hardware);
2. Get IPv6 address from DHCP server as part of the system or network restart.
Based on the operating systems, perform the following:
On CentOS 6.2:
a. Open the Ethernet interface configuration file:
vi /etc/sysconfig/network-scripts/ifcfg-eth0
The ifcfg-eth0 file controls the first NIC in a system.
b. Make the necessary configuration changes, as given below:
DEVICE=eth0
HWADDR=06:A0:F0:00:00:38
NM_CONTROLLED=no
ONBOOT=yes
BOOTPROTO=dhcp6
TYPE=Ethernet
USERCTL=no
PEERDNS=yes
IPV6INIT=yes
DHCPV6C=yes
c. Open the following:
vi /etc/sysconfig/network
d. Make the necessary configuration changes, as given below:
NETWORKING=yes
HOSTNAME=centos62mgmt.lab.vmops.com
NETWORKING_IPV6=yes
IPV6_AUTOCONF=no
On Ubuntu 12.10
a. Open the following:
etc/network/interfaces:
b. Make the necessary configuration changes, as given below:
iface eth0 inet6 dhcp
autoconf 0
264
Additional VMX Settings
accept_ra 1
27.1.3. Additional VMX Settings
A VMX (.vmx) file is the primary configuration file for a virtual machine. When a new VM is created,
information on the operating system, disk sizes, and networking is stored in this file. The VM
actively writes to its .vmx file for all the configuration changes. The VMX file is typically located
in the directory where the VM is created. In Windows Vista / Windows 7 / Windows Server
2008, the default location is C:\Users\<your_user_name>\My Documents\Virtual Machines
\<virtual_machine_name>.vmx. In Linux, vmware-cmd -l lists the full path to all the registered VMX
files. Any manual additions to the .vmx file from ESX/ESXi are overwritten by the entries stored in
the vCenter Server database. Therefore, before you edit a .vmx file, first remove the VM from the
vCenter server's inventory and register the VM again after editing.
The CloudStack API that supports passing some of the VMX settings is registerTemplate. The
supported parameters are rootDiskController, nicAdapter, and keyboard. In addition to these
existing VMX parameters, you can now use the keyboard.typematicMinDelay parameter in
the registerTemplate API call. This parameter controls the amount of delay for the repeated
key strokes on remote consoles. For more information on keyboard.typematicMinDelay, see
2
keyboard.typematicMinDelay .
27.1.4. Resetting SSH Keys to Access VMs
Use the resetSSHKeyForVirtualMachine API to set or reset the SSH keypair assigned to a virtual
machine. With the addition of this feature, a lost or compromised SSH keypair can be changed,
and the user can access the VM by using the new keypair. Just create or register a new keypair,
then call resetSSHKeyForVirtualMachine.
27.1.5. Changed API Commands in 4.1
API Commands
Description
createNetworkOffering
The following request parameters have been
added:
• isPersistent
• startipv6
• endipv6
• ip6gateway
• ip6cidr
listNetworkOfferings
listNetworks
The following request parameters have been
added:
• isPersistent
This parameter determines if the network or
network offering listed are persistent or not.
2
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=196
265
第27章 What's New in the API?
API Commands
Description
• ip6gateway
• ip6cidr
createVlanIpRange
The following request parameters have been
added:
• startipv6
• endipv6
• ip6gateway
• ip6cidr
deployVirtualMachine
The following parameter has been added:
ip6Address.
The following parameter is updated to accept
the IPv6 address: iptonetworklist.
CreateZoneCmd
The following parameter have been added:
ip6dns1, ip6dns2.
listRouters
For nic responses, the following fields have
been added.
listVirtualMachines
• ip6address
• ip6gateway
• ip6cidr
listVlanIpRanges
For nic responses, the following fields have
been added.
• startipv6
• endipv6
• ip6gateway
• ip6cidr
listRouters
listZones
For DomainRouter and DataCenter response,
the following fields have been added.
• ip6dns1
• ip6dns2
addF5LoadBalancer
configureNetscalerLoadBalancer
addNetscalerLoadBalancer
listF5LoadBalancers
266
The following response parameter is removed:
inline.
Added API Commands in 4.1-incubating
API Commands
Description
configureF5LoadBalancer
listNetscalerLoadBalancers
listFirewallRules
createFirewallRule
The following request parameter is added:
traffictype (optional).
listUsageRecords
The following response parameter is added:
virtualsize.
deleteIso
The following request parameter is added:
forced (optional).
createStoragePool
The following request parameters are made
mandatory:
• podid
• clusterid
createAccount
The following new request parameters are
added: accountid, userid
createUser
The following new request parameter is
added: userid
createDomain
The following new request parameter is
added: domainid
listZones
The following request parameters is added:
securitygroupenabled
27.1.6. Added API Commands in 4.1-incubating
• createEgressFirewallRules (creates an egress firewall rule on the guest network.)
• deleteEgressFirewallRules (deletes a egress firewall rule on the guest network.)
• listEgressFirewallRules (lists the egress firewall rules configured for a guest network.)
• resetSSHKeyForVirtualMachine (Resets the SSHkey for virtual machine.)
• addBaremetalHost (Adds a new host.)
• addNicToVirtualMachine (Adds a new NIC to the specified VM on a selected network.)
• removeNicFromVirtualMachine (Removes the specified NIC from a selected VM.)
• updateDefaultNicForVirtualMachine (Updates the specified NIC to be the default one for a
selected VM.)
• addRegion (Registers a Region into another Region.)
• updateRegion (Updates Region details: ID, Name, Endpoint, User API Key, and User Secret Key.)
• removeRegion (Removes a Region from current Region.)
267
第27章 What's New in the API?
• listRegions (List all the Regions. Filter them by using the ID or Name.)
• getUser (This API can only be used by the Admin. Get user details by using the API Key.)
27.2. What's New in the API for 4.0
27.2.1. 4.0.0-incubating で変更された API コマンド
API コマンド
説明
copyTemplate
ここに記述されたコマンドは単一の新しいレスポンスパラメーターを持
ち、それ以外の変更点はありません。
prepareTemplate
registerTemplate
新しいレスポンスパラメーター: tags(*)
updateTemplate
注記
createProject
その他の多くのコマンドは新しい tags(*) パラメー
ターを持ちその他の変更点を含みます。これらのコマ
ンドを別途記述します。
activateProject
suspendProject
updateProject
listProjectAccounts
createVolume
migrateVolume
attachVolume
detachVolume
uploadVolume
createSecurityGroup
registerIso
copyIso
updateIso
createIpForwardingRule
listIpForwardingRules
createLoadBalancerRule
updateLoadBalancerRule
createSnapshot
268
4.0.0-incubating で変更された API コマンド
API コマンド
説明
rebootVirtualMachine
ここに記述されたコマンドは 2つの新しいレスポンスパラメーターを持
ち、それ以外の変更点はありません。
attachIso
detachIso
新しいレスポンスパラメーター: keypair, tags(*)
listLoadBalancerRuleInstances
resetPasswordForVirtualMachine
changeServiceForVirtualMachine
recoverVirtualMachine
startVirtualMachine
migrateVirtualMachine
deployVirtualMachine
assignVirtualMachine
updateVirtualMachine
restoreVirtualMachine
stopVirtualMachine
destroyVirtualMachine
listSecurityGroups
listFirewallRules
listPortForwardingRules
listSnapshots
ここに記述されたコマンドは以下の新しいパラメーターを持ち、それ以
外の変更点はありません。
新しいリクエストパラメーター: tags (オプション)
新しいレスポンスパラメーター: tags(*)
listIsos
listProjects
listTemplates
listLoadBalancerRules
listF5LoadBalancerNetworks
ここに記述されたコマンドは 3つの新しいレスポンスパラメーターを持
ち、それ以外の変更点はありません。
listNetscalerLoadBalancerNetworks
新しいレスポンスパラメーター: canusefordeploy, vpcid, tags(*)
listSrxFirewallNetworks
updateNetwork
createZone
updateZone
ここに記述されたコマンドは以下の新しいパラメーターを持ち、それ以
外の変更点はありません。
269
第27章 What's New in the API?
API コマンド
説明
新しいリクエストパラメーター: localstorageenabled (オプション)
新しいレスポンスパラメーター: localstorageenabled
listZones
新しいレスポンスパラメーター: localstorageenabled
rebootRouter
ここに記述されたコマンドは 2つの新しいレスポンスパラメーターを持
ち、それ以外の変更点はありません。
changeServiceForRouter
startRouter
新しいレスポンスパラメーター: vpcid, nic(*)
destroyRouter
stopRouter
updateAccount
disableAccount
listAccounts
ここに記述されたコマンドは 3つの新しいレスポンスパラメーターを持
ち、それ以外の変更点はありません。
新しいレスポンスパラメーター: vpcavailable, vpclimit, vpctotal
markDefaultZoneForAccount
enableAccount
listRouters
新しいリクエストパラメーター: forvpc (オプション), vpcid (オプション)
新しいレスポンスパラメーター: vpcid, nic(*)
listNetworkOfferings
新しいリクエストパラメーター: forvpc(オプション)
新しいレスポンスパラメーター: forvpc
listVolumes
新しいリクエストパラメーター: detais (オプション), tags (オプション)
新しいリクエストパラメーター: tags(*)
addTrafficMonitor
新しいリクエストパラメーター: excludezones (オプション),
includezones (オプション)
createNetwork
新しいリクエストパラメーター: vpcid (オプション)
新しいレスポンスパラメーター: canusefordeploy, vpcid, tags(*)
listPublicIpAddresses
新しいリクエストパラメーター: tags (オプション), vpcid (オプション)
新しいレスポンスパラメーター: vpcid, tags(*)
listNetworks
新しいリクエストパラメーター: canusefordeploy (オプション), forvpc
(オプション), tags (オプション), vpcid (オプション)
新しいレスポンスパラメーター: canusefordeploy, vpcid, tags(*)
restartNetwork
新しいレスポンスパラメーター: vpcid, tags(*)
enableStaticNat
新しいリクエストパラメーター: networkid (オプション)
createDiskOffering
新しいリクエストパラメーター: storagetype (オプション)
新しいレスポンスパラメーター: storagetype
270
Added API Commands in 4.0.0-incubating
API コマンド
説明
listDiskOfferings
新しいレスポンスパラメーター: storagetype
updateDiskOffering
新しいレスポンスパラメーター: storagetype
createFirewallRule
変更されたリクエストパラメーター: ipaddressid (古いバージョン - オ
プション, 新しいバージョン - 必須)
新しいレスポンスパラメーター: tags(*)
listVirtualMachines
新しいリクエストパラメーター: isoid (オプション), tags (オプション),
templateid (オプション)
新しいレスポンスパラメーター: keypair, tags(*)
updateStorageNetworkIpRange 新しいレスポンスパラメーター: id, endip, gateway, netmask,
networkid, podid, startip, vlan, zoneid
27.2.2. Added API Commands in 4.0.0-incubating
• createCounter (Adds metric counter)
• deleteCounter (Deletes a counter)
• listCounters (List the counters)
• createCondition (Creates a condition)
• deleteCondition (Removes a condition)
• listConditions (List Conditions for the specific user)
• createTags. Add tags to one or more resources. Example:
command=createTags
&resourceIds=1,10,12
&resourceType=userVm
&tags[0].key=region
&tags[0].value=canada
&tags[1].key=city
&tags[1].value=Toronto
• deleteTags. Remove tags from one or more resources. Example:
command=deleteTags
&resourceIds=1,12
&resourceType=Snapshot
&tags[0].key=city
• listTags (Show currently defined resource tags)
• createVPC (Creates a VPC)
• listVPCs (Lists VPCs)
• deleteVPC (Deletes a VPC)
• updateVPC (Updates a VPC)
271
第27章 What's New in the API?
• restartVPC (Restarts a VPC)
• createVPCOffering (Creates VPC offering)
• updateVPCOffering (Updates VPC offering)
• deleteVPCOffering (Deletes VPC offering)
• listVPCOfferings (Lists VPC offerings)
• createPrivateGateway (Creates a private gateway)
• listPrivateGateways (List private gateways)
• deletePrivateGateway (Deletes a Private gateway)
• createNetworkACL (Creates a ACL rule the given network (the network has to belong to VPC))
• deleteNetworkACL (Deletes a Network ACL)
• listNetworkACLs (Lists all network ACLs)
• createStaticRoute (Creates a static route)
• deleteStaticRoute (Deletes a static route)
• listStaticRoutes (Lists all static routes)
• createVpnCustomerGateway (Creates site to site vpn customer gateway)
• createVpnGateway (Creates site to site vpn local gateway)
• createVpnConnection (Create site to site vpn connection)
• deleteVpnCustomerGateway (Delete site to site vpn customer gateway)
• deleteVpnGateway (Delete site to site vpn gateway)
• deleteVpnConnection (Delete site to site vpn connection)
• updateVpnCustomerGateway (Update site to site vpn customer gateway)
• resetVpnConnection (Reset site to site vpn connection)
• listVpnCustomerGateways (Lists site to site vpn customer gateways)
• listVpnGateways (Lists site 2 site vpn gateways)
• listVpnConnections (Lists site to site vpn connection gateways)
• enableCiscoNexusVSM (Enables Nexus 1000v dvSwitch in CloudStack.)
• disableCiscoNexusVSM (Disables Nexus 1000v dvSwitch in CloudStack.)
• deleteCiscoNexusVSM (Deletes Nexus 1000v dvSwitch in CloudStack.)
• listCiscoNexusVSMs (Lists the control VLAN ID, packet VLAN ID, and data VLAN ID, as well as the
IP address of the Nexus 1000v dvSwitch.)
272
What's New in the API for 3.0
27.3. What's New in the API for 3.0
27.3.1. Enabling Port 8096
Port 8096, which allows API calls without authentication, is closed and disabled by default on any
fresh 3.0.1 installations. You can enable 8096 (or another port) for this purpose as follows:
1. Ensure that the first Management Server is installed and running.
2. Set the global configuration parameter integration.api.port to the desired port.
3. 管理サーバーを再起動します。
4. On the Management Server host machine, create an iptables rule allowing access to that port.
27.3.2. Stopped VM
CloudStack now supports creating a VM without starting it. You can determine whether the VM
needs to be started as part of the VM deployment. A VM can now be deployed in two ways: create
and start a VM (the default method); or create a VM and leave it in the stopped state.
A new request parameter, startVM, is introduced in the deployVm API to support the stopped VM
feature.
The possible values are:
• true - The VM starts as a part of the VM deployment.
• false - The VM is left in the stopped state at the end of the VM deployment.
The default value is true.
27.3.3. Change to Behavior of List Commands
There was a major change in how our List* API commands work in CloudStack 3.0 compared to
2.2.x. The rules below apply only for managed resources – those that belong to an account, domain,
or project. They are irrelevant for the List* commands displaying unmanaged (system) resources,
such as hosts, clusters, and external network resources.
When no parameters are passed in to the call, the caller sees only resources owned by the
caller (even when the caller is the administrator). Previously, the administrator saw everyone else's
resources by default.
When accountName and domainId are passed in:
• The caller sees the resources dedicated to the account specified.
• If the call is executed by a regular user, the user is authorized to specify only the user's own
account and domainId.
• If the caller is a domain administrator, CloudStack performs an authorization check to see
whether the caller is permitted to view resources for the given account and domainId.
When projectId is passed in, only resources belonging to that project are listed.
273
第27章 What's New in the API?
When domainId is passed in, the call returns only resources belonging to the domain specified.
To see the resources of subdomains, use the parameter isRecursive=true. Again, the regular
user can see only resources owned by that user, the root administrator can list anything, and a
domain administrator is authorized to see only resources of the administrator's own domain and
subdomains.
To see all resources the caller is authorized to see, except for Project resources, use the parameter
listAll=true.
To see all Project resources the caller is authorized to see, use the parameter projectId=-1.
There is one API command that doesn't fall under the rules above completely: the listTemplates
command. This command has its own flags defining the list rules:
listTemplates Flag
説明
featured
Returns templates that have been marked as
featured and public.
self
Returns templates that have been registered
or created by the calling user.
selfexecutable
Same as self, but only returns templates that
are ready to be deployed with.
sharedexecutable
Ready templates that have been granted to
the calling user by another user.
executable
Templates that are owned by the calling
user, or public templates, that can be used to
deploy a new VM.
community
Returns templates that have been marked as
public but not featured.
all
Returns all templates (only usable by admins).
The CloudStack UI on a general view will display all resources that the logged-in user is authorized
to see, except for project resources. To see the project resources, select the project view.
27.3.4. 削除された API コマンド
• createConfiguration (設置値の追加)
• configureSimulator (構成シュミレーター)
27.3.5. 3.0 にて追加された API コマンド
27.3.5.1. 3.0.2 にて追加
• changeServiceForSystemVm
Changes the service offering for a system VM (console proxy or secondary storage). The system
VM must be in a "Stopped" state for this command to take effect.
27.3.5.2. 3.0.1 にて追加
• changeServiceForSystemVm
274
3.0 にて追加された API コマンド
Changes the service offering for a system VM (console proxy or secondary storage). The system
VM must be in a "Stopped" state for this command to take effect.
27.3.5.3. 3.0.0 にて追加
assignVirtualMachine (ユー
ザーの仮想マシンを同一ドメイン
の他のユーザーに割り当てます)
restoreVirtualMachine (オリジ
ナルのテンプレートや特定のス
ナップショットから仮想マシンをリ
ストアします)
createLBStickinessPolicy (ス
ティックネスポリシーの負荷分散
装置を作成します)
deleteLBStickinessPolicy (ス
ティックネスポリシーの負荷分散
装置を削除します)
listLBStickinessPolicies (ス
ティックネスポリシーを持つ負荷
分散装置をリスト表示します)
ldapConfig (サイトにおける
LDAP コンテキストを変更します)
addSwift (Swift を追加します)
listSwifts (Swift をリスト表示しま migrateVolume (ボリュームを移
す)
行します)
updateStoragePool (ストレージ
プールを更新します)
authorizeSecurityGroupEgress revokeSecurityGroupEgress
(セキュリティグループに対し特定 (セキュリティグループに対し特定
の出力規則を認証します)
の出力規則を削除します)
createNetworkOffering (ネット
ワークオファリングを作成します)
deleteNetworkOffering (ネット
ワークオファリングを削除します)
deleteProject (プロジェクトを削
除します)
updateProject (プロジェクトを更 activateProject (プロジェクトを
新します)
始動させます)
suspendProject (プロジェクトを
一時停止させます)
listProjects (プロジェクトをリスト
表示し、各プロジェクトに関する詳
細情報を提示します)
createProject (プロジェクトを作
成します)
addAccountToProject (Adds
account to a project)
deleteAccountFromProject (プ listProjectAccounts (Lists
ロジェクトからアカウントを削除し project's accounts)
ます)
listProjectInvitations (Lists an
account's invitations to join
projects)
updateProjectInvitation (プロ
ジェクトの招待を受理もしくは拒
否します)
deleteProjectInvitation (プロ
ジェクトの招待を削除します)
updateHypervisorCapabilities
(ハイパーバイザーの性能情報を
更新します)
listHypervisorCapabilities (ハ
イパーバイザーの全ての性能情
報をリスト表示します)
createPhysicalNetwork (物理
ネットワークを作成します)
deletePhysicalNetwork (物理
ネットワークを削除します)
listPhysicalNetworks (物理ネッ
トワークをリスト表示します)
updatePhysicalNetwork (物理
ネットワークを更新します)
listSupportedNetworkServices
(全ての CloudStack もしくは特
定のプロバイダーによって提供さ
れるネットワークサービスをリスト
表示します)
addNetworkServiceProvider
(物理ネットワークにネットワーク
サービスプロバイダーを追加しま
す)
deleteNetworkServiceProvider listNetworkServiceProviders
(ネットワークサービスプロバイ
(物理ネットワークで提供される
ダーを削除します)
サービスプロバイダーをリスト表
示します)
updateNetworkServiceProvider addTrafficType (物理ネットワー
(物理ネットワークのネットワーク
クにトラフィックタイプを追加しま
サービスプロバイダーを更新します)
す)
deleteTrafficType (物理ネット
ワークのトラフィックタイプを削除
します)
275
第27章 What's New in the API?
listTrafficTypes (物理ネットワー
クで提供されるトラフィックタイプ
をリスト表示します)
updateTrafficType (物理ネット
ワークのトラフィックタイプを更新
します)
listTrafficTypeImplementors
(全てのネットワークトラフィック
タイプの提供者もしくは特定トラ
フィックタイプの提供者をリスト表
示します)
createStorageNetworkIpRange deleteStorageNetworkIpRange listStorageNetworkIpRange
(ストレージネットワークの IP 範囲 (ストレージネットワークの IP 範囲 (ストレージネットワークの IP 範囲
を作成します)
を削除します)
をリスト表示します)
updateStorageNetworkIpRange listUsageTypes (利用タイプをリ
(ストレージネットワークの IP 範囲スト表示します)
を更新します。範囲に対して IP が
使用中でない場合のみ利用でき
ます)
addF5LoadBalancer (F5 BigIP
負荷分散装置を追加します)
configureF5LoadBalancer (F5
負荷分散装置を設定します)
listF5LoadBalancers (F5 負荷
分散装置をリスト表示します)
deleteF5LoadBalancer (F5 負
荷分散装置を削除します)
listF5LoadBalancerNetworks
addSrxFirewall (SRX ファイア
(F5 負荷分散装置を利用しているウォールを追加します)
ネットワークをリスト表示します)
deleteSrxFirewall (SRX ファイア
ウォールを削除します)
listSrxFirewalls (物理ネットワー
ク上の SRX ファイアウォールをリ
スト表示します)
addNetscalerLoadBalancer
(NetScaler 負荷分散装置を追加
します)
listSrxFirewallNetworks (SRX
ファイアウォールを利用している
ネットワークをリスト表示します)
deleteNetscalerLoadBalancer configureNetscalerLoadBalancerlistNetscalerLoadBalancers
(NetScaler 負荷分散装置を削除 (NetScaler 負荷分散装置を設定 (NetScaler 負荷分散装置をリス
します)
します)
ト表示します)
listNetscalerLoadBalancerNetworks
createVirtualRouterElement
(NetScaler 負荷分散装置を利用 (仮想ルーターを作成します)
しているネットワークをリスト表示
します)
configureVirtualRouterElement
(仮想マシンを設定します)
listVirtualRouterElements (全
ての利用可能な仮想ルーターをリ
スト表示します)
27.3.6. Added CloudStack Error Codes
You can now find the CloudStack-specific error code in the exception response for each
type of exception. The following list of error codes is added to the new class named
CSExceptionErrorCode.
4250 :
4255 :
4260 :
"com.cloud.utils.exception.CloudRuntimeException"
"com.cloud.utils.exception.ExceptionUtil"
"com.cloud.utils.exception.ExecutionException"
4265 :
4270 :
4275 :
"com.cloud.utils.exception.HypervisorVersionChangedException"
"com.cloud.utils.exception.RuntimeCloudException"
"com.cloud.exception.CloudException"
4280 :
4285 :
4290 :
"com.cloud.exception.AccountLimitException"
"com.cloud.exception.AgentUnavailableException"
"com.cloud.exception.CloudAuthenticationExceptio
4295 :
4300 :
4305 :
"com.cloud.exception.CloudExecutionException"
"com.cloud.exception.ConcurrentOperationException"
"com.cloud.exception.ConflictingNetworkSettingsEx
276
Added CloudStack Error Codes
4310 :
4315 :
4320 :
"com.cloud.exception.DiscoveredWithErrorException"
"com.cloud.exception.HAStateException"
"com.cloud.exception.InsufficientAddressCa
4325 :
4330 :
4335 :
"com.cloud.exception.InsufficientCapacityException"
"com.cloud.exception.InsufficientNetworkCapacityException"
"com.cloud.exception.InsufficientServerCap
4340 :
4345 :
4350 :
"com.cloud.exception.InsufficientStorageCapacityException"
"com.cloud.exception.InternalErrorException"
"com.cloud.exception.InvalidParameterValu
4355 :
4360 :
4365 :
"com.cloud.exception.ManagementServerException"
"com.cloud.exception.NetworkRuleConflictException"
"com.cloud.exception.PermissionDeniedExc
4370 :
4375 :
4380 :
"com.cloud.exception.ResourceAllocationException"
"com.cloud.exception.ResourceInUseException"
"com.cloud.exception.ResourceUnavailableE
4385 :
4390 :
4395 :
"com.cloud.exception.StorageUnavailableException"
"com.cloud.exception.UnsupportedServiceException"
"com.cloud.exception.VirtualMachineMigrat
4400 :
4405 :
4410 :
"com.cloud.exception.AccountLimitException"
"com.cloud.exception.AgentUnavailableException"
"com.cloud.exception.CloudAuthenticationE
4415 :
4420 :
4425 :
"com.cloud.exception.CloudException"
"com.cloud.exception.CloudExecutionException"
"com.cloud.exception.ConcurrentOperation
4430 :
4435 :
4440 :
"com.cloud.exception.ConflictingNetworkSettingsException"
"com.cloud.exception.ConnectionException"
"com.cloud.exception.DiscoveredWithErrorE
4445 :
4450 :
4455 :
"com.cloud.exception.DiscoveryException"
"com.cloud.exception.HAStateException"
"com.cloud.exception.InsufficientAddressCa
4460 :
4465 :
4470 :
"com.cloud.exception.InsufficientCapacityException"
"com.cloud.exception.InsufficientNetworkCapacityException"
"com.cloud.exception.InsufficientServerCap
4475 :
4480 :
4485 :
"com.cloud.exception.InsufficientStorageCapacityException"
"com.cloud.exception.InsufficientVirtualNetworkCapcityException"
"com.cloud.exception.InternalErrorException
4490 :
4495 :
4500 :
"com.cloud.exception.InvalidParameterValueException"
"com.cloud.exception.ManagementServerException"
"com.cloud.exception.NetworkRuleConflictE
4505 :
4510 :
4515 :
"com.cloud.exception.PermissionDeniedException"
"com.cloud.exception.ResourceAllocationException"
"com.cloud.exception.ResourceInUseExcept
4520 :
4525 :
4530 :
"com.cloud.exception.ResourceUnavailableException"
"com.cloud.exception.StorageUnavailableException"
"com.cloud.exception.UnsupportedServiceE
4535 :
9999 :
"com.cloud.exception.VirtualMachineMigrationException"
"org.apache.cloudstack.api.ServerApiException"
277
278
CloudStack API の呼び出し
28.1. API リクエストを作成します。
All CloudStack API requests are submitted in the form of a HTTP GET/POST with an associated
command and any parameters. A request is composed of the following whether in HTTP or HTTPS:
• CloudStack API URL: This is the web services API entry point(for example, http://
www.cloud.com:8080/client/api)
• Command: The web services command you wish to execute, such as start a virtual machine or
create a disk volume
• Parameters: Any additional required or optional parameters for the command
A sample API GET request looks like the following:
http://localhost:8080/client/api?
command=deployVirtualMachine&serviceOfferingId=1&diskOfferingId=1&templateId=2&zoneId=4&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eX
jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
Or in a more readable format:
1.
2.
3.
4.
5.
6.
7.
8.
http://localhost:8080/client/api
?command=deployVirtualMachine
&serviceOfferingId=1
&diskOfferingId=1
&templateId=2
&zoneId=4
&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXqjB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ
&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
The first line is the CloudStack API URL. This is the Cloud instance you wish to interact with.
The second line refers to the command you wish to execute. In our example, we are attempting to
deploy a fresh new virtual machine. It is preceded by a (?) to separate itself from the CloudStack
API URL.
Lines 3-6 are the parameters for this given command. To see the command and its request
parameters, please refer to the appropriate section in the CloudStack API documentation. Each
parameter field-value pair (field=value) is preceded by an ampersand character (&).
Line 7 is the user API Key that uniquely identifies the account. See Signing API Requests on page 7.
Line 8 is the signature hash created to authenticate the user account executing the API command.
See Signing API Requests on page 7.
28.2. Signing API Requests
Whether you access the CloudStack API with HTTP or HTTPS, it must still be signed so that
CloudStack can verify the caller has been authenticated and authorized to execute the command.
Make sure that you have both the API Key and Secret Key provided by the CloudStack administrator
for your account before proceeding with the signing process.
To show how to sign a request, we will re-use the previous example.
279
第28章 CloudStack API の呼び出し
http://http://localhost:8080/client/api?
command=deployVirtualMachine&serviceOfferingId=1&diskOfferingId=1&templateId=2&zoneId=4&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXqjB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
Breaking this down, we have several distinct parts to this URL.
• Base URL: This is the base URL to the CloudStack Management Server.
http://localhost:8080
• API Path: This is the path to the API Servlet that processes the incoming requests.
/client/api?
• Command String: This part of the query string comprises of the command, its parameters, and
the API Key that identifies the account.
注記
As with all query string parameters of field-value pairs, the "field" component is
case insensitive while all "value" values are case sensitive.
command=deployVirtualMachine&serviceOfferingId=1&diskOfferingId=1&templateId=2&zoneId=4&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXqjB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ
• Signature: This is the hashed signature of the Base URL that is generated using a combination of
the user’s Secret Key and the HMAC SHA-1 hashing algorithm.
&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
Every API request has the format Base URL+API Path+Command String+Signature.
To generate the signature.
1. For each field-value pair (as separated by a '&') in the Command String, URL encode each value
so that it can be safely sent via HTTP GET.
注記
Make sure all spaces are encoded as "%20" rather than "+".
2. Lower case the entire Command String and sort it alphabetically via the field for each fieldvalue pair. The result of this step would look like the following.
apikey=mivr6x7u6bn_sdahobpjnejpgest35exqjb8cg20yi3yaxxcgpyuairmfi_ejtvwz0nukkjbpmy3y2bcikwfq&command=deployvirtualmachine&diskofferingid=1&serviceofferingid=1&templateid=2
3. Take the sorted Command String and run it through the HMAC SHA-1 hashing algorithm (most
programming languages offer a utility method to do this) with the user’s Secret Key. Base64
encode the resulting byte array in UTF-8 so that it can be safely transmitted via HTTP. The
280
How to sign an API call with Python
final string produced after Base64 encoding should be "Lxx1DM40AjcXU%2FcaiK8RAP0O1hU
%3D".
By reconstructing the final URL in the format Base URL+API Path+Command String+Signature,
the final URL should look like:
http://localhost:8080/client/api?
command=deployVirtualMachine&serviceOfferingId=1&diskOfferingId=1&templateId=2&zoneId=4&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT
jB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
28.2.1. How to sign an API call with Python
To illustrate the procedure used to sign API calls we present a step by step interactive session using
Python.
First import the required modules:
$python
Python 2.7.3 (default, Nov 17 2012, 19:54:34)
[GCC 4.2.1 Compatible Apple Clang 4.1 ((tags/Apple/clang-421.11.66))] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib2
>>> import urllib
>>> import hashlib
>>> import hmac
>>> import base64
Define the endpoint of the Cloud, the command that you want to execute and the keys of the user.
>>>
>>>
>>>
>>>
>>>
>>>
baseurl='http://localhost:8080/client/api?'
request={}
request['command']='listUsers'
request['response']='json'
request['apikey']='plgWJfZK4gyS3mOMTVmjUVg-X-jlWlnfaUJ9GAbBbf9EdM-kAYMmAiLqzzq1ElZLYq_u38zCm0bewzGUdP66mg'
secretkey='VDaACYb0LV9eNjTetIOElcVQkvJck_J_QljX_FcHRj87ZKiy0z0ty0ZsYBkoXkY9b7eq1EhwJaw7FF3akA3KBQ'
Build the request string:
>>> request_str='&'.join(['='.join([k,urllib.quote_plus(request[k])]) for k in request.keys()])
>>> request_str
'apikey=plgWJfZK4gyS3mOMTVmjUVg-X-jlWlnfaUJ9GAbBbf9EdMkAYMmAiLqzzq1ElZLYq_u38zCm0bewzGUdP66mg&command=listUsers&response=json'
Compute the signature with hmac, do a 64 bit encoding and a url encoding:
281
第28章 CloudStack API の呼び出し
>>> sig_str='&'.join(['='.join([k.lower(),urllib.quote_plus(request[k].lower().replace('+','%20'))])for k in
sorted(request.iterkeys())])
>>> sig_str
'apikey=plgwjfzk4gys3momtvmjuvg-x-jlwlnfauj9gabbbf9edmkaymmailqzzq1elzlyq_u38zcm0bewzgudp66mg&command=listusers&response=json'
>>> sig=hmac.new(secretkey,sig_str,hashlib.sha1)
>>> sig
<hmac.HMAC instance at 0x10d91d680>
>>> sig=hmac.new(secretkey,sig_str,hashlib.sha1).digest()
>>> sig
'M:]\x0e\xaf\xfb\x8f\xf2y\xf1p\x91\x1e\x89\x8a\xa1\x05\xc4A\xdb'
>>> sig=base64.encodestring(hmac.new(secretkey,sig_str,hashlib.sha1).digest())
>>> sig
'TTpdDq/7j/J58XCRHomKoQXEQds=\n'
>>> sig=base64.encodestring(hmac.new(secretkey,sig_str,hashlib.sha1).digest()).strip()
>>> sig
'TTpdDq/7j/J58XCRHomKoQXEQds='
>>> sig=urllib.quote_plus(base64.encodestring(hmac.new(secretkey,sig_str,hashlib.sha1).digest()).strip())
Finally, build the entire string and do an http GET:
>>> req=baseurl+request_str+'&signature='+sig
>>> req
'http://localhost:8080/client/api?apikey=plgWJfZK4gyS3mOMTVmjUVg-X-jlWlnfaUJ9GAbBbf9EdMkAYMmAiLqzzq1ElZLYq_u38zCm0bewzGUdP66mg&command=listUsers&response=json&signature=TTpdDq%2F7j%2FJ58XCRHomKoQXEQds
%3D'
>>> res=urllib2.urlopen(req)
>>> res.read()
'{ "listusersresponse" : { "count":3 ,"user" : [ {"id":"7ed6d5da-93b2-4545a502-23d20b48ef2a","username":"admin","firstname":"admin","lastname":"cloud","created":"2012-07-05T12:18:27-0700","state":"enabled","acc
e155-4482-93ce-84efff3c7c77","domain":"ROOT","apikey":"plgWJfZK4gyS3mOMTVmjUVg-X-jlWlnfaUJ9GAbBbf9EdMkAYMmAiLqzzq1ElZLYq_u38zCm0bewzGUdP66mg","secretkey":"VDaACYb0LV9eNjTetIOElcVQkvJck_J_QljX_FcHRj87ZKiy0z0ty0ZsYBkoXkY9b7eq1EhwJaw7FF3akA
af1d-4c1c-9064-2f3e2c0eda0d"}, {"id":"1fea6418-5576-4989a21e-4790787bbee3","username":"runseb","firstname":"foobar","lastname":"goa","email":"[email protected]","created":"2013-04-10T16:52:06-0700
e155-4482-93ce-84efff3c7c77","domain":"ROOT","apikey":"Xhsb3MewjJQaXXMszRcLvQI9_NPy_UcbDj1QXikkVbDC9MDSPwWdtZ1bUY1H7JBEYTtDDLY3yuchCeW77
i1ddQIHJLbLJDK9MRzsKk6xZ_w","accountid":"7548ac03-af1d-4c1c-9064-2f3e2c0eda0d"}, {"id":"52f65396-183c-4473-883fa37e7bb93967","username":"toto","firstname":"john","lastname":"smith","email":"[email protected]","created":"2013-04-23T04:27:22-0700","sta
e155-4482-93ce-84efff3c7c77","domain":"ROOT","apikey":"THaA6fFWS_OmvU8od201omxFC8yKNL_Hc5ZCS77LFCJsRzSx48JyZucbUul6XYbEgZyXMl_wuEpECzKwKnow","secretkey":"O5ywpqJorAsEBKR_5jEvrtGHfWL1Y_j1E4Z_iCr8OKCYcsPIOdVcfzjJQ8YqK0a5EzSpoRrjOFiLsG0hQrYnDA","accountid":"7548ac03af1d-4c1c-9064-2f3e2c0eda0d"} ] } }'
28.3. Enabling API Call Expiration
You can set an expiry timestamp on API calls to prevent replay attacks over non-secure channels,
such as HTTP. The server tracks the expiry timestamp you have specified and rejects all the
subsequent API requests that come in after this validity period.
To enable this feature, add the following parameters to the API request:
• signatureVersion=3: If the signatureVersion parameter is missing or is not equal to 3, the expires
parameter is ignored in the API request.
• expires=YYYY-MM-DDThh:mm:ssZ: Specifies the date and time at which the signature included
in the request is expired. The timestamp is expressed in the YYYY-MM-DDThh:mm:ssZ format,
as specified in the ISO 8601 standard.
282
Limiting the Rate of API Requests
For example:
expires=2011-10-10T12:00:00+0530
A sample API request with expiration is given below:
http://<IPAddress>:8080/client/api?
command=listZones&signatureVersion=3&expires=2011-10-10T12:00:00+0530&apiKey=miVr6X7u6bN_sdahOBpjNejPgEsT35eXqjB8CG20YI3yaxXcgpyuaIRmFI_EJTVwZ0nUkkJbPmY3y2bciKwFQ&signature=Lxx1DM40AjcXU%2FcaiK8RAP0O1hU%3D
28.4. Limiting the Rate of API Requests
You can limit the rate at which API requests can be placed for each account. This is useful to
avoid malicious attacks on the Management Server, prevent performance degradation, and provide
fairness to all accounts.
If the number of API calls exceeds the threshold, an error message is returned for any additional
API calls. The caller will have to retry these API calls at another time.
28.4.1. Configuring the API Request Rate
To control the API request rate, use the following global configuration settings:
• api.throttling.enabled - Enable/Disable API throttling. By default, this setting is false, so API
throttling is not enabled.
• api.throttling.interval (in seconds) - Time interval during which the number of API requests is to
be counted. When the interval has passed, the API count is reset to 0.
• api.throttling.max - Maximum number of APIs that can be placed within the api.throttling.interval
period.
• api.throttling.cachesize - Cache size for storing API counters. Use a value higher than the total
number of accounts managed by the cloud. One cache entry is needed for each account, to store
the running API total for that account.
28.4.2. Limitations on API Throttling
The following limitations exist in the current implementation of this feature.
注記
Even with these limitations, CloudStack is still able to effectively use API throttling
to avoid malicious attacks causing denial of service.
• In a deployment with multiple Management Servers, the cache is not synchronized across them.
In this case, CloudStack might not be able to ensure that only the exact desired number of API
requests are allowed. In the worst case, the number of API calls that might be allowed is (number
of Management Servers) * (api.throttling.max).
• The API commands resetApiLimit and getApiLimit are limited to the Management Server where
the API is invoked.
283
第28章 CloudStack API の呼び出し
28.5. Responses
28.5.1. Response Formats: XML and JSON
CloudStack supports two formats as the response to an API call. The default response is XML. If
you would like the response to be in JSON, add &response=json to the Command String.
The two response formats differ in how they handle blank fields. In JSON, if there is no value for
a response field, it will not appear in the response. If all the fields were empty, there might be no
response at all. In XML, even if there is no value to be returned, an empty field will be returned as
a placeholder XML element.
Sample XML Response:
<listipaddressesresponse>
<allocatedipaddress>
<ipaddress>192.168.10.141</ipaddress>
<allocated>2009-09-18T13:16:10-0700</allocated>
<zoneid>4</zoneid>
<zonename>WC</zonename>
<issourcenat>true</issourcenat>
</allocatedipaddress>
</listipaddressesresponse>
Sample JSON Response:
{ "listipaddressesresponse" :
{ "allocatedipaddress" :
[
{
"ipaddress" : "192.168.10.141",
"allocated" : "2009-09-18T13:16:10-0700",
"zoneid" : "4",
"zonename" : "WC",
"issourcenat" : "true"
}
]
}
}
28.5.2. Maximum Result Pages Returned
For each cloud, there is a default upper limit on the number of results that any API command will
return in a single page. This is to help prevent overloading the cloud servers and prevent DOS
attacks. For example, if the page size limit is 500 and a command returns 10,000 results, the
command will return 20 pages.
The default page size limit can be different for each cloud. It is set in the global configuration
parameter default.page.size. If your cloud has many users with lots of VMs, you might need to
increase the value of this parameter. At the same time, be careful not to set it so high that your site
can be taken down by an enormous return from an API call. For more information about how to set
global configuration parameters, see "Describe Your Deployment" in the Installation Guide.
284
Error Handling
To decrease the page size limit for an individual API command, override the global setting with
the page and pagesize parameters, which are available in any list* command (listCapabilities,
listDiskOfferings, etc.).
• Both parameters must be specified together.
• The value of the pagesize parameter must be smaller than the value of default.page.size. That is,
you can not increase the number of possible items in a result page, only decrease it.
For syntax information on the list* commands, see the API Reference.
28.5.3. Error Handling
If an error occurs while processing an API request, the appropriate response in the format specified
is returned. Each error response consists of an error code and an error text describing what possibly
can go wrong. For an example error response, see page 12.
An HTTP error code of 401 is always returned if API request was rejected due to bad signatures,
missing API Keys, or the user simply did not have the permissions to execute the command.
28.6. Asynchronous Commands
Asynchronous commands were introduced in CloudStack 2.x. Commands are designated as
asynchronous when they can potentially take a long period of time to complete such as creating a
snapshot or disk volume. They differ from synchronous commands by the following:
• They are identified in the API Reference by an (A).
• They will immediately return a job ID to refer to the job that will be responsible in processing
the command.
• If executed as a "create" resource command, it will return the resource ID as well as the job ID.
You can periodically check the status of the job by making a simple API call to the command,
queryAsyncJobResult and passing in the job ID.
28.6.1. ジョブの状態
非同期コマンドを利用する際の重要な点はコマンドを実行した際直ちに返ってくるジョブ ID です。ジョブ ID は
queryAsyncJobResult コマンドを生成することで定期的にジョブの状態をチェックすることができ、3つの整数
値でジョブの状態が返ってきます。
• 0 - ジョブは実行中です。続けて状態遷移を定期的にポーリングします。
• 1 - ジョブは正常に完了しました。ジョブはコマンド実行に紐づく成功値を返します。
• 2 - Job has failed to complete. Please check the "jobresultcode" tag for failure reason code and
"jobresult" for the failure reason.
28.6.2. 例
The following shows an example of using an asynchronous command. Assume the API command:
command=deployVirtualMachine&zoneId=1&serviceOfferingId=1&diskOfferingId=1&templateId=1
285
第28章 CloudStack API の呼び出し
CloudStack will immediately return a job ID and any other additional data.
<deployvirtualmachineresponse>
<jobid>1</jobid>
<id>100</id>
</deployvirtualmachineresponse>
Using the job ID, you can periodically poll for the results by using the queryAsyncJobResult
command.
command=queryAsyncJobResult&jobId=1
Three possible results could come from this query.
Job is still pending:
<queryasyncjobresult>
<jobid>1</jobid>
<jobstatus>0</jobstatus>
<jobprocstatus>1</jobprocstatus>
</queryasyncjobresult>
Job has succeeded:
<queryasyncjobresultresponse cloud-stack-version="3.0.1.6">
<jobid>1</jobid>
<jobstatus>1</jobstatus>
<jobprocstatus>0</jobprocstatus>
<jobresultcode>0</jobresultcode>
<jobresulttype>object</jobresulttype>
<jobresult>
<virtualmachine>
<id>450</id>
<name>i-2-450-VM</name>
<displayname>i-2-450-VM</displayname>
<account>admin</account>
<domainid>1</domainid>
<domain>ROOT</domain>
<created>2011-03-10T18:20:25-0800</created>
<state>Running</state>
<haenable>false</haenable>
<zoneid>1</zoneid>
<zonename>San Jose 1</zonename>
<hostid>2</hostid>
<hostname>905-13.sjc.lab.vmops.com</hostname>
<templateid>1</templateid>
<templatename>CentOS 5.3 64bit LAMP</templatename>
<templatedisplaytext>CentOS 5.3 64bit LAMP</templatedisplaytext>
<passwordenabled>false</passwordenabled>
<serviceofferingid>1</serviceofferingid>
<serviceofferingname>Small Instance</serviceofferingname>
<cpunumber>1</cpunumber>
<cpuspeed>500</cpuspeed>
<memory>512</memory>
<guestosid>12</guestosid>
<rootdeviceid>0</rootdeviceid>
<rootdevicetype>NetworkFilesystem</rootdevicetype>
286
例
<nic>
<id>561</id>
<networkid>205</networkid>
<netmask>255.255.255.0</netmask>
<gateway>10.1.1.1</gateway>
<ipaddress>10.1.1.225</ipaddress>
<isolationuri>vlan://295</isolationuri>
<broadcasturi>vlan://295</broadcasturi>
<traffictype>Guest</traffictype>
<type>Virtual</type>
<isdefault>true</isdefault>
</nic>
<hypervisor>XenServer</hypervisor>
</virtualmachine>
</jobresult>
</queryasyncjobresultresponse>
Job has failed:
<queryasyncjobresult>
<jobid>1</jobid>
<jobstatus>2</jobstatus>
<jobprocstatus>0</jobprocstatus>
<jobresultcode>551</jobresultcode>
<jobresulttype>text</jobresulttype>
<jobresult>Unable to deploy virtual machine id = 100 due to not enough capacity</jobresult>
</queryasyncjobresult>
287
288
Working With Usage Data
The Usage Server provides aggregated usage records which you can use to create billing integration
for the CloudStack platform. The Usage Server works by taking data from the events log and creating
summary usage records that you can access using the listUsageRecords API call.
The usage records show the amount of resources, such as VM run time or template storage space,
consumed by guest instances. In the special case of bare metal instances, no template storage
resources are consumed, but records showing zero usage are still included in the Usage Server's
output.
The Usage Server runs at least once per day. It can be configured to run multiple times per day.
Its behavior is controlled by configuration settings as described in the CloudStack Administration
Guide.
29.1. Usage Record Format
29.1.1. Virtual Machine Usage Record Format
For running and allocated virtual machine usage, the following fields exist in a usage record:
• account – name of the account
• accountid – ID of the account
• domainid – ID of the domain in which this account resides
• zoneid – Zone where the usage occurred
• description – A string describing what the usage record is tracking
• usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for VM running
time)
• usagetype – A number representing the usage type (see Usage Types)
• rawusage – A number representing the actual usage in hours
• virtualMachineId – The ID of the virtual machine
• name – The name of the virtual machine
• offeringid – The ID of the service offering
• templateid – The ID of the template or the ID of the parent template. The parent template value
is present when the current template was created from a volume.
• usageid – Virtual machine
• type – Hypervisor
• startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage
Record
289
第29章 Working With Usage Data
29.1.2. Network Usage Record Format
For network usage (bytes sent/received), the following fields exist in a usage record.
• account – name of the account
• accountid – ID of the account
• domainid – ID of the domain in which this account resides
• zoneid – Zone where the usage occurred
• description – A string describing what the usage record is tracking
• usagetype – A number representing the usage type (see Usage Types)
• rawusage – A number representing the actual usage in hours
• usageid – Device ID (virtual router ID or external device ID)
• type – Device type (domain router, external load balancer, etc.)
• startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage
Record
29.1.3. IP Address Usage Record Format
For IP address usage the following fields exist in a usage record.
• account - name of the account
• accountid - ID of the account
• domainid - ID of the domain in which this account resides
• zoneid - Zone where the usage occurred
• description - A string describing what the usage record is tracking
• usage - String representation of the usage, including the units of usage
• usagetype - A number representing the usage type (see Usage Types)
• rawusage - A number representing the actual usage in hours
• usageid - IP address ID
• startdate, enddate - The range of time for which the usage is aggregated; see Dates in the Usage
Record
• issourcenat - Whether source NAT is enabled for the IP address
• iselastic - True if the IP address is elastic.
29.1.4. Disk Volume Usage Record Format
For disk volumes, the following fields exist in a usage record.
290
Template, ISO, and Snapshot Usage Record Format
• account – name of the account
• accountid – ID of the account
• domainid – ID of the domain in which this account resides
• zoneid – Zone where the usage occurred
• description – A string describing what the usage record is tracking
• usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
• usagetype – A number representing the usage type (see Usage Types)
• rawusage – A number representing the actual usage in hours
• usageid – The volume ID
• offeringid – The ID of the disk offering
• type – Hypervisor
• templateid – ROOT template ID
• size – The amount of storage allocated
• startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage
Record
29.1.5. Template, ISO, and Snapshot Usage Record Format
• account – name of the account
• accountid – ID of the account
• domainid – ID of the domain in which this account resides
• zoneid – Zone where the usage occurred
• description – A string describing what the usage record is tracking
• usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
• usagetype – A number representing the usage type (see Usage Types)
• rawusage – A number representing the actual usage in hours
• usageid – The ID of the the template, ISO, or snapshot
• offeringid – The ID of the disk offering
• templateid – – Included only for templates (usage type 7). Source template ID.
• size – Size of the template, ISO, or snapshot
• startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage
Record
291
第29章 Working With Usage Data
29.1.6. Load Balancer Policy or Port Forwarding Rule Usage Record
Format
• account - name of the account
• accountid - ID of the account
• domainid - ID of the domain in which this account resides
• zoneid - Zone where the usage occurred
• description - A string describing what the usage record is tracking
• usage - String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
• usagetype - A number representing the usage type (see Usage Types)
• rawusage - A number representing the actual usage in hours
• usageid - ID of the load balancer policy or port forwarding rule
• usagetype - A number representing the usage type (see Usage Types)
• startdate, enddate - The range of time for which the usage is aggregated; see Dates in the Usage
Record
29.1.7. Network Offering Usage Record Format
• account – name of the account
• accountid – ID of the account
• domainid – ID of the domain in which this account resides
• zoneid – Zone where the usage occurred
• description – A string describing what the usage record is tracking
• usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
• usagetype – A number representing the usage type (see Usage Types)
• rawusage – A number representing the actual usage in hours
• usageid – ID of the network offering
• usagetype – A number representing the usage type (see Usage Types)
• offeringid – Network offering ID
• virtualMachineId – The ID of the virtual machine
• virtualMachineId – The ID of the virtual machine
• startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage
Record
292
VPN User Usage Record Format
29.1.8. VPN User Usage Record Format
• account – name of the account
• accountid – ID of the account
• domainid – ID of the domain in which this account resides
• zoneid – Zone where the usage occurred
• description – A string describing what the usage record is tracking
• usage – String representation of the usage, including the units of usage (e.g. 'Hrs' for hours)
• usagetype – A number representing the usage type (see Usage Types)
• rawusage – A number representing the actual usage in hours
• usageid – VPN user ID
• usagetype – A number representing the usage type (see Usage Types)
• startdate, enddate – The range of time for which the usage is aggregated; see Dates in the Usage
Record
29.2. 使用状況データの種類
次の表は使用状況データの種類を表しています。
Type ID
Type Name
説明
1
RUNNING_VM
使用状況レコードの期間におけ
る仮想マシンの総稼働時間を追
跡します。もし期間中に仮想マ
シンがアップグレードされた場
合は、新しいアップグレードされ
た仮想マシンに対し別の使用状
況レコードを取得します。
2
ALLOCATED_VM
仮想マシンが作成されてから削
除されるまでの総時間を追跡し
ます。この使用状況タイプは
Windows ベースのテンプレー
トのような特定テンプレートの
使用状況を確認するのに役立
ちます。
3
IP_ADDRESS
アカウントが所有するパブリック
IP を追跡します
4
NETWORK_BYTES_SENT
アカウントが所有している全て
の仮想マシンから送信したデー
タの総バイト数を追跡しま
す。Cloud.com は現在仮想マ
シン毎のネットワークトラフィック
は追跡しません。
293
第29章 Working With Usage Data
Type ID
Type Name
説明
5
NETWORK_BYTES_RECEIVED
アカウントが所有している全て
の仮想マシンで受信したデータ
の総バイト数を追跡しま
す。Cloud.com は現在仮想マ
シン毎のネットワークトラフィック
は追跡しません。
6
VOLUME
ディスクボリュームが作成されて
から削除されるまでの総時間を
追跡します。
7
TEMPLATE
テンプレート(スナップショットか
ら作成もしくはクラウド上にアッ
プロードされたもの)が作成され
てから削除されるまでの総時間
を追跡します。また、テンプレート
のサイズも返されます。
8
ISO
ISO がアップロードされてから
削除されるまでの総時間を追跡
します。また、ISO のサイズも返
されます。
9
SNAPSHOT
スナップショットが作成されてか
ら削除されるまでの総時間を追
跡します。
11
LOAD_BALANCER_POLICY
負荷分散ポリシーが作成されて
から削除されるまでの総時間を
追跡します。Cloud.com は規則
がいつ仮想マシンに割り当てら
れたかまでは追跡しません。
12
PORT_FORWARDING_RULE
ポートフォワーディング規則が作
成されてから削除されるまでの
総時間を追跡します。
13
NETWORK_OFFERING
ネットワークオファリングが仮想
マシンに割り当てられてから削
除されるまでの時間を追跡しま
す。
14
VPN_USERS
VPN ユーザーが作成されてか
ら削除されるまでの時間を追跡
します。
29.3. Example response from listUsageRecords
All CloudStack API requests are submitted in the form of a HTTP GET/POST with an associated
command and any parameters. A request is composed of the following whether in HTTP or HTTPS:
<listusagerecordsresponse>
<count>1816</count>
<usagerecord>
<account>user5</account>
294
Dates in the Usage Record
<accountid>10004</accountid>
<domainid>1</domainid>
<zoneid>1</zoneid>
<description>i-3-4-WC running time (ServiceOffering: 1) (Template: 3)</description>
<usage>2.95288 Hrs</usage>
<usagetype>1</usagetype>
<rawusage>2.95288</rawusage>
<virtualmachineid>4</virtualmachineid>
<name>i-3-4-WC</name>
<offeringid>1</offeringid>
<templateid>3</templateid>
<usageid>245554</usageid>
<type>XenServer</type>
<startdate>2009-09-15T00:00:00-0700</startdate>
<enddate>2009-09-18T16:14:26-0700</enddate>
</usagerecord>
… (1,815 more usage records)
</listusagerecordsresponse>
29.4. Dates in the Usage Record
Usage records include a start date and an end date. These dates define the period of time for which
the raw usage number was calculated. If daily aggregation is used, the start date is midnight on
the day in question and the end date is 23:59:59 on the day in question (with one exception; see
below). A virtual machine could have been deployed at noon on that day, stopped at 6pm on that
day, then started up again at 11pm. When usage is calculated on that day, there will be 7 hours of
running VM usage (usage type 1) and 12 hours of allocated VM usage (usage type 2). If the same
virtual machine runs for the entire next day, there will 24 hours of both running VM usage (type
1) and allocated VM usage (type 2).
Note: The start date is not the time a virtual machine was started, and the end date is not the time
when a virtual machine was stopped. The start and end dates give the time range within which
usage was calculated.
For network usage, the start date and end date again define the range in which the number of bytes
transferred was calculated. If a user downloads 10 MB and uploads 1 MB in one day, there will be
two records, one showing the 10 megabytes received and one showing the 1 megabyte sent.
There is one case where the start date and end date do not correspond to midnight and
11:59:59pm when daily aggregation is used. This occurs only for network usage records. When
the usage server has more than one day's worth of unprocessed data, the old data will be included
in the aggregation period. The start date in the usage record will show the date and time of the
earliest event. For other types of usage, such as IP addresses and VMs, the old unprocessed data
is not included in daily aggregation.
29.5. Globally Configured Limits
In a zone, the guest virtual network has a 24 bit CIDR by default. This limits the guest virtual network
to 254 running instances. It can be adjusted as needed, but this must be done before any instances
are created in the zone. For example, 10.1.1.0/22 would provide for ~1000 addresses.
The following table lists limits set in the Global Configuration:
295
第29章 Working With Usage Data
Parameter Name
Definition
max.account.public.ips
Number of public IP addresses that can be
owned by an account
max.account.snapshots
Number of snapshots that can exist for an
account
max.account.templates
Number of templates that can exist for an
account
max.account.user.vms
Number of virtual machine instances that can
exist for an account
max.account.volumes
Number of disk volumes that can exist for an
account
max.template.iso.size
Maximum size for a downloaded template or
ISO in GB
max.volume.size.gb
Maximum size for a volume in GB
network.throttling.rate
Default data transfer rate in megabits per
second allowed per user (supported on
XenServer)
snapshot.max.hourly
Maximum recurring hourly snapshots to be
retained for a volume. If the limit is reached,
early snapshots from the start of the hour are
deleted so that newer ones can be saved. This
limit does not apply to manual snapshots. If
set to 0, recurring hourly snapshots can not be
scheduled
snapshot.max.daily
Maximum recurring daily snapshots to be
retained for a volume. If the limit is reached,
snapshots from the start of the day are deleted
so that newer ones can be saved. This limit
does not apply to manual snapshots. If set to 0,
recurring daily snapshots can not be scheduled
snapshot.max.weekly
Maximum recurring weekly snapshots to be
retained for a volume. If the limit is reached,
snapshots from the beginning of the week are
deleted so that newer ones can be saved. This
limit does not apply to manual snapshots. If set
to 0, recurring weekly snapshots can not be
scheduled
snapshot.max.monthly
Maximum recurring monthly snapshots to be
retained for a volume. If the limit is reached,
snapshots from the beginning of the month are
deleted so that newer ones can be saved. This
limit does not apply to manual snapshots. If set
to 0, recurring monthly snapshots can not be
scheduled.
To modify global configuration parameters, use the global configuration screen in the CloudStack
UI. See Setting Global Configuration Parameters
296
付録A タイムゾーン
CloudStack では、次のタイムゾーン識別子を使用できます。設定の一部で、必須またはオプションのパラメー
ターとしてタイムゾーンを使用します。これには、構成テーブルにおける、定期スナップショットのスケジュール、
ユーザーの作成、および使用タイムゾーンの指定が含まれます。
Etc/GMT+12
Etc/GMT+11
Pacific/Samoa
Pacific/Honolulu
US/Alaska
America/Los_Angeles
Mexico/BajaNorte
US/Arizona
US/Mountain
America/Chihuahua
America/Chicago
America/Costa_Rica
America/Mexico_City
Canada/Saskatchewan
America/Bogota
America/New_York
America/Caracas
America/Asuncion
America/Cuiaba
America/Halifax
America/La_Paz
America/Santiago
America/St_Johns
America/Araguaina
America/Argentina/
Buenos_Aires
America/Cayenne
America/Godthab
America/Montevideo
Etc/GMT+2
Atlantic/Azores
Atlantic/Cape_Verde
Africa/Casablanca
Etc/UTC
Atlantic/Reykjavik
Europe/London
CET
Europe/Bucharest
Africa/Johannesburg
Asia/Beirut
Africa/Cairo
Asia/Jerusalem
Europe/Minsk
Europe/Moscow
Africa/Nairobi
Asia/Karachi
Asia/Kolkata
Asia/Bangkok
Asia/Shanghai
Asia/Kuala_Lumpur
Australia/Perth
Asia/Taipei
Asia/Tokyo
Asia/Seoul
Australia/Adelaide
Australia/Darwin
Australia/Brisbane
Australia/Canberra
Pacific/Guam
Pacific/Auckland
297
298
付録B イベントの種類
VM.CREATE
TEMPLATE.EXTRACT
SG.REVOKE.INGRESS
VM.DESTROY
TEMPLATE.UPLOAD
HOST.RECONNECT
VM.START
TEMPLATE.CLEANUP
MAINT.CANCEL
VM.STOP
VOLUME.CREATE
MAINT.CANCEL.PS
VM.REBOOT
VOLUME.DELETE
MAINT.PREPARE
VM.UPGRADE
VOLUME.ATTACH
MAINT.PREPARE.PS
VM.RESETPASSWORD
VOLUME.DETACH
VPN.REMOTE.ACCESS.CREATE
ROUTER.CREATE
VOLUME.UPLOAD
VPN.USER.ADD
ROUTER.DESTROY
SERVICEOFFERING.CREATE
VPN.USER.REMOVE
ROUTER.START
SERVICEOFFERING.UPDATE
NETWORK.RESTART
ROUTER.STOP
SERVICEOFFERING.DELETE
UPLOAD.CUSTOM.CERTIFICATE
ROUTER.REBOOT
DOMAIN.CREATE
UPLOAD.CUSTOM.CERTIFICATE
ROUTER.HA
DOMAIN.DELETE
STATICNAT.DISABLE
PROXY.CREATE
DOMAIN.UPDATE
SSVM.CREATE
PROXY.DESTROY
SNAPSHOT.CREATE
SSVM.DESTROY
PROXY.START
SNAPSHOT.DELETE
SSVM.START
PROXY.STOP
SNAPSHOTPOLICY.CREATE
SSVM.STOP
PROXY.REBOOT
SNAPSHOTPOLICY.UPDATE
SSVM.REBOOT
PROXY.HA
SNAPSHOTPOLICY.DELETE
SSVM.H
VNC.CONNECT
VNC.DISCONNECT
NET.IPASSIGN
NET.IPRELEASE
NET.RULEADD
NET.RULEDELETE
NET.RULEMODIFY
NETWORK.CREATE
NETWORK.DELETE
LB.ASSIGN.TO.RULE
LB.REMOVE.FROM.RULE
LB.CREATE
LB.DELETE
LB.UPDATE
USER.LOGIN
USER.LOGOUT
USER.CREATE
USER.DELETE
USER.UPDATE
USER.DISABLE
TEMPLATE.CREATE
TEMPLATE.DELETE
TEMPLATE.UPDATE
TEMPLATE.COPY
TEMPLATE.DOWNLOAD.START TEMPLATE.DOWNLOAD.SUCCESS
TEMPLATE.DOWNLOAD.FAILED
ISO.CREATE
ISO.DELETE
ISO.COPY
ISO.ATTACH
ISO.DETACH
ISO.EXTRACT
ISO.UPLOAD
SERVICE.OFFERING.CREATE
SERVICE.OFFERING.EDIT
SERVICE.OFFERING.DELETE
DISK.OFFERING.CREATE
DISK.OFFERING.EDIT
DISK.OFFERING.DELETE
NETWORK.OFFERING.CREATE NETWORK.OFFERING.EDIT
NETWORK.OFFERING.DELETE POD.CREATE
POD.EDIT
POD.DELETE
ZONE.CREATE
ZONE.EDIT
ZONE.DELETE
VLAN.IP.RANGE.CREATE
VLAN.IP.RANGE.DELETE
299
付録B イベントの種類
CONFIGURATION.VALUE.EDIT SG.AUTH.INGRESS
300
付録C Alerts
The following is the list of alert type numbers. The current alerts can be found by calling listAlerts.
MEMORY = 0
CPU = 1
STORAGE =2
STORAGE_ALLOCATED = 3
PUBLIC_IP = 4
PRIVATE_IP = 5
HOST = 6
USERVM = 7
DOMAIN_ROUTER = 8
CONSOLE_PROXY = 9
ROUTING = 10// lost connection to default route (to the gateway)
STORAGE_MISC = 11 // lost connection to default route (to the gateway)
USAGE_SERVER = 12 // lost connection to default route (to the gateway)
MANAGMENT_NODE = 13 // lost connection to default route (to the gateway)
DOMAIN_ROUTER_MIGRATE = 14
CONSOLE_PROXY_MIGRATE = 15
USERVM_MIGRATE = 16
VLAN = 17
SSVM = 18
USAGE_SERVER_RESULT = 19
STORAGE_DELETE = 20;
301
付録C Alerts
UPDATE_RESOURCE_COUNT = 21; //Generated when we fail to update the resource count
USAGE_SANITY_RESULT = 22;
DIRECT_ATTACHED_PUBLIC_IP = 23;
LOCAL_STORAGE = 24;
RESOURCE_LIMIT_EXCEEDED = 25; //Generated when the resource limit exceeds the limit. Currently used for recurring
snapshots only
302

Download Report