2012年12月16日日曜日

知っておくと便利なCloudStackのグローバル設定

CloudStack Advent Calendar jp: 2012


の一環として、CloudStackのグローバル設定について書きます。


 


 CloudStackを入れてみて、皆さんは何を試していますか?



  • インスタンスを作ってみたり

  • サービスオファリングを設定してみたり

  • アカウントを設定してみたり


このあたりはとりあえずGUIで出来て、取っつきやすいと思います。


 


ところで、下のほうに、グローバル設定という箇所がありますよね。


CloudStackの管理者UIにおいて、これほど文字ばかりが並んでいる場所は
他になかなかないと思いますが、けっこう大事そうな設定があるので、
時間があれば目を通してみてはいかがでしょう。


f:id:smzksts:20121216164252p:plain


 


Apache CloudStack 4.0のグローバル設定は238項目あります。
それぞれの項目については[説明]という項目はありますが、残念ながら個々の設定項目を詳細に説明したドキュメントは特にありません。
しかし、CloudStackの基本的な概念や動きを理解した上で、項目名と[説明]を読めば、大体の項目は何のためのものか、わかると思います。


 


以下は、検証環境で使うと便利なグローバル設定の紹介です。


 


1.インスタンスの完全削除


CloudStackでは、インスタンスの削除操作をしても、実際にはなかなか削除が行われません。(インスタンスがゴミ箱に捨てられて、ゴミ箱をきれいにする操作は一定間隔ごとに行われるため、なかなか完全削除してもらえないようなイメージ)


完全削除の処理間隔を定義しているのが以下のパラメータです。


●expunge.interval


破棄されたインスタンスを削除する処理を行う間隔。
デフォルトは86400秒(1日)。


●expunge.delay
破棄されたインスタンスを削除せずに保持する時間。この時間が経過するまでは、削除する処理の実行間隔が訪れても、削除が行われない。
デフォルトは86400秒(1日)。


 


2.リソースのオーバープロビジョニング


こちらの設定は、仮想化の世界でいうところの、いわゆるオーバーコミットの倍率です。CloudStackはIaaSサービス提供を前提としているため、各ユーザーの展開したインスタンスが、オファリングの設定値どおりにリソースを確実に得られるように、リソースはオーバーコミットされず、リソース不足時にはそれ以上インスタンスが起動されなくなります。インスタンスを高集約で動かしたい場合などには、以下の設定が便利です。


●cpu.overprovisioning.factor
CPUのオーバープロビジョニングの倍率


●storage.overprovisioning.factor
プライマリストレージのオーバープロビジョニングの倍率


 


なお、これらの設定を反映させるには、CloudStack管理サーバーのサービス(cloud-management)再起動が必要です。


 


また、蛇足(?)ですがCloudStackのグローバル設定は、CloudStackのデータベースのconfigurationテーブルに格納されています。一覧は下記のコマンドで出力できます。


# mysql cloud --user="root" --password="パスワード" -e "select * from configuration"


 f:id:smzksts:20121216164110p:plain


configurationのうち、すべてがグローバル設定なわけではなく、24個ほどHiddenカテゴリに分類されたものがあり、グローバル設定には表示されていません。これらはシステム側で自動的にセットされたり、CloudStack管理UIの別の個所で設定可能な項目のようです。


 


ちなみにHiddenカテゴリの皆さんはこちら…


cloud.identifier
init
kvm.guest.network.device
kvm.private.network.device
kvm.public.network.device
ovm.guest.network.device
ovm.private.network.device
ovm.public.network.device
router.ram.size
secondary.storage.vm
secstorage.copy.password
security.hash.key
ssh.privatekey
ssh.publickey
ssl.keystore
vmware.guest.vswitch
vmware.private.vswitch
vmware.public.vswitch
xen.create.pools.in.pod
xen.guest.network.device
xen.private.network.device
xen.public.network.device
xen.storage.network.device1
xen.storage.network.device2


トラフィックと物理ネットワークの紐づけをしている辺りなどは、CloudStackをインストールしたことがある人なら、なんとなく見覚えのあるパラメーターですね。


 


CloudStackデータベース(MySQL)のほかのテーブルは、
# mysql cloud --user="root" --password="パスワード" -e "show tables"


で一覧表示できますので、CloudStackの内側の覗いてみるヒントになるかと思います。


 


OSC.cloudで力尽きましたので、今日はここまで…。


2012年6月27日水曜日

CloudStackのドキュメント

CloudStack関連の資料は下記リンク先から探すと便利です。
インストールガイドや管理ガイドは日本語資料もあるのがよいです:)


CloudStack Documentation


2012年6月2日土曜日

はてなダイアリーからはてなブログへ移行しました

5/31にはてなダイアリーからのインポート機能が実装されたということで、ようやくはてなブログへ移行しました。


 


記事の編集がWYSIWYGになったので、ものぐさな私には大変ありがたいです:)


2012年4月30日月曜日

OpenFlow勉強会(#sdnstudy)第2回に参加しました

ゴールデンウィーク2日目はOpenFlow勉強会その2に参加しました。

当日のセッションや各種資料はATNDに掲載されています。










        • -




今回、個人的に興味深かったのはTremaのハンズオン。

なんと、自分でOpenFlow Controllerを作れてしまいます。

当日はいくつかのサンプルコードをもとにOpenFlowコントローラを設定し、OpenFlowスイッチおよび接続するホストはTremaの持つシミュレータを使って動作をチェックする、といった内容でした。

ここで試したくなるのが、シミュレータではないOpenFlowスイッチでの動作。現在個人で用意できそうなOpenFlowスイッチと言えば、Open vSwitchかSRCHACK.orgさんのBuffalo無線LANルータのファーム差し替えによるものの、どちらか2択。

自宅ラック勉強会のおかげで私は後者も持っているのですが、中の人としてはCitrix XenServer 6.0から標準となった、Open vSwitchを使いたい!

もちろん、OSS XenKVMが使えるLinuxディストリビューションで、Open vSwitchを導入可能なものもありますが、インストール?初期セットアップが10分ちょっとで終わるXenServerのほうが遥かに楽です。

なお、本来Citrix XenServerには有償版の機能として vSwitch ControllerというNOXベースのOpenFlowコントローラが用意されていますが、無償版でもOpen vSwitchそのものは動いているので、これをTremaに接続してみよう…ということで、要するにCitrix XenServerの機能というよりも、純粋にOpen vSwitchの機能を使ってみました。



実際どうやるのかというと、とりあえず接続のチェック方法は以下のとおり

【前提】

1.ATNDからリンクされているOpenFlow勉強会で使ったハンズオンのサンプルを参考に、OpenFlowスイッチを作成

2.XenServerをインストールし、XenServerのローカルCLIを開く

【方法】

・XenServerをControllerに接続する

1.仮想スイッチの名前を確認

# ovs-vsctl list-br
xenbr0※XenServerに標準で作成される仮想スイッチ名



2.仮想スイッチをコントローラに接続

# ovs-vsctl set-controller xenbr0 tcp:



成功すると、Tremaハンズオン資料11ページのswitch_readyメソッドによって、Trema側のコンソールに↓が表示されました。

ifswitch_ready => 0x3aa9528617d6

3.仮想スイッチをコントローラから切断

switch_disconnected => 0x3aa9528617d6

注意点として、Flowを全然設定していないControllerにxenbr0をつないでしまうと、SSHやXenCenterでの接続ができなくなってしまいます。最低限Tremaハンズオン24ページに掲載されているリピータHUBとして動作する機能をコントローラに持たせるか、XenServerをローカルコンソールで操作するか、いずれかの対応をできる状態にしておくと良いでしょう。

ちゃんとした制御をするにはまだまだ勉強が必要ですが、こつこつ試してみたいと思います。