| ENGLISH | JAPANESE |
ViSLAB で、private cloud システムを作って運用しようという事になり、 cloud 基盤システムとしては、次の二つ、仮想化技術としては、次の三つを検討しました。
結局、オープンな物が良いということになり、cloud 基盤としては、 OpenNebula を、 仮想化技術としては、ちょっと、議論があったのですが、 CJ が普段から使い慣れている vmware 社の ESXi を利用する事にしました。 理由は、性能でした。 始めからなんとなく、ベースシステムとして ubuntu を利用する事になっていて、Linux では KVM のサポートがされているので、KVM でどうかという 検討をしたのですが、今回 Cloud の為に利用しようと思っている CPU が、 あまり新しくなく、最近の CPU による、仮想技術サポート機能である Intel VT-x (Intel 社の資料 ) や、 AMD-V (AMD 社の資料) などの機能をもたないため、それらを要求する KVM では性能が十分に出ないだろうという事からでした。 そこで、安定して動き、性能もある程度定評がある vmware にしようということになったわけです。 フロントエンドとなる、cloud-core は、ubuntu server 10.04 に、OpenNebula のパッケージを 入れるだけで、一緒に作業しました。 次に、計算を行うのノードを登録を行うわけですが、 どうも、vmware の方は、専用のドライバーを組込む必要があり、 そちらは、CJ に少し専念してもらうとして、 僕の方は、日本に戻ってからの事も考え、 また、障害時の切り分けに利用できるかなと思い、 KVM のノードを試しに作る事になったわけです。
以下は、KVM ノードを作成した時の作業記録です。
まず、KVM Node を入れる、ベースシステムとなる Ubuntu を入れます。 インストールの時には、特記する内容はなく (2) 、 標準インストールで最後の時だけ ssh サーバのパッケージを撰択します。 あと、update は proxy 設定が必要なので、インストール時は自動的には、アップデートしないように指定しました。
Network : DHCP
ネットワーク環境は、すでに cloud-core に DHCP サーバー ( and NAT 機能 ) を実現しているので、それを利用します。 また、インストールは、 PXEBoot という仕組を使い、CD-ROM が無くても、インストールができる (3) ようになっているという所が少し自慢です。 また、この仕組を使えば、そもそも、インストール自身を自動化したり、更に、インストールなしのディスクレスで 運用するという可能性もあり、それは是非、抑えておきたいなと思って、この方法を撰択しました。
さて、これから Install 後の作業を始めるのですが、http proxy の設定や、 典型的なファイルの変更を行うのに、一々エディタで行うのは、 間違い易いし、面倒なので、変更に必要なファイルは cloud-core の NFS で 公開する場所 ( cloud-core:/var/nfs_share/wrapper ) に集めておいて、 それを、CPU Node で NFS Mount し、 そこから cp して利用するようにします。 実は、最初に作成した、資料でも、scp を利用していたのですが、こちらの方がもっと便利 (4) でしょう。
NFS client になるには、次のパッケージ ( nfs-common ) をインストールする必要があります。
cloud-node-006:~# apt-get install nfs-common
ローカルのファイルシステム ( /mnt ) に、リモートのボリューム ( cloud-core:/var/nfs_share ) を Mount する。
cloud-node-006:~# mount cloud-core:/var/nfs_share /mnt
これで、/mnt/warpper 以下 ( オリジナルでは /var/nfs_share/warpper 以下 ) に、 変更した結果のファイルがあるので、それを cp するだけで、設定が変更できる。
ViSLAB から、ubuntu の update サイトをアクセスするのに http が使われますが、 Sydney 大学では、学内から学外への http アクセスは、すべて、proxy を経由するようになっています。 apt-get も、パッケージファイルである .deb を入手するのに、http (ftp などでもよいのだが..) を使いますので、 proxy の設定が必要です。 apt-get の http-proxy を設定する方法も色々あるようですが、今回は、~/.bashrc に、環境変数 http_proxy に http porxy server の情報を設定するという安易な方法をとりました。 ということで、root の ~/.bashrc を書き換え、それを読み込む事で、環境に反映してしまいます。
cloud-node-006:~# mv /root/.bashrc /root/.bashrc.ORIG cloud-node-006:~# cp /mnt/wrapper/.bashrc /root/.bashrc cloud-node-006:~# . /root/.bashrc
なお、単なる習慣ですが、書き換える前には、元のファイルを .ORIG の拡張子をつけて保存します。 ただ、そうすると、cp で、様々なファイル属性が書かわるので、本当はその調整をしなければなりません。 fedora では、selinux の関係で、そのトラブルにあったのですが、ubuntu ではそれが大きく問題にならないのかもしれません。
Ubuntu ファイルの配布先として、mirror.aarnet.edu.au を使うようにします。 その内容は、/mnt/wrapper/sources.list にあります。 ちなみに、これをしないと、PXEBoot インストールで参照した、cloud-core をミラーサイトとして利用します。 そこには、CD-ROM のイメージが展開されており (そこから、インストールした.. )、 あまり利用されていないパッケージ (5) はありませんし、あっても古い版のもの (6) しかありませんので、やはり、最新版で試すという意味でも、mirror site の設定はしておくと良いでしょう。
cloud-node-006:~# mv /etc/apt/sources.list /etc/apt/sources.list.ORIG cloud-node-006:~# cp /mnt/wrapper/sources.list /etc/apt
apt-get の設定が済めは、最初に行う事は、全てのパッケージを最新にする事で、 これは、ubuntu の何時もの手順で行います。
cloud-node-006:~# apt-get update cloud-node-006:~# apt-get upgrade
CPU が仮想技術をサポートしているかどうか確認作業です。KVM 関連のサイトには、必ずといってよい程 記載されているので、まあ、顰みに習おうというわけです。
cloud-node-006:~# egrep '(vmx|svm)' /proc/cpuinfo
もし、今、作成している KVM Box が、仮想技術をサポートしている CPU であれば、ここで何が表示される はずなのですが、もちろん、そんな筈はないことは予め解っており、予想通り、何も表示されません。 ただ、後で述べるように、CPU の仮想技術サポートがないからといって KVM が動かないわけでも、 また、(パッチこそ必要ですが..) OpenNebula 下でも動かないわけではないという事です。
cloud-node-006:~# apt-get install kvm libvirt-bin
KVM と、libvirt-bin パッケージをインストールします。 KVM 本体 ( qemu も入っている ) だけあれば、仮想 CPU の作成は可能です。 ただ、libvirt-bin をフロントエンドにおき、どうやら、KVM と Xen の操作の インターフェースを統合しているようです (7) 。 何れにせよ、OpenNebula は、この libvirt-bin を利用しますので、 このパッケージのインストールは必須です。
OpenNebula は、cloud をまとめる、一つのフロントエンド (今回の場合は cloud-core) PC と CPU Power を提供する、複数の計算 Node からなっています。 opennebula というパッケージは、フロントエンド用で、計算 Node 用は、opennebula-node という 名前でパッケージ化されており、共通するパッケージが opennebula-common という名前の様です。 もちろん、ここでは、計算 Node 用の opennebula-node をインストールします。
cloud-node-006:~# apt-get install opennebula-node
apparmor パッケージを削除します。
cloud-node-006:~# apt-get remove apparmor
apparmor というのは、ubuntu 版 SELinux と言いますか、 ようするにファイルパーミッションより細かい、アクセス制御を行うための セキュリティパッケージです。 予想が付くかもしれませんが、「適切な設定がなされないと、」安全度を重視する余り、 やりたい事ができなくなるという事が起きる典型的なパッケージです。 デフォルトの設定では、どうも、この apparmor が、libvirt-bin の振舞いを 適切に判断してくれないようで、VM の作成時に、失敗してしまいます。 本来ならば、apparmor の適切な設定を行う事によって、問題を回避すべきですが、今回は、 apparmor そのものを削除して対処します。
KVM で作られた vm が、KVM Box の外のネットワークから見れるようにするために、 KVM Box 自身のネットワーク設定に、ブリッジの設定を行う必要があります。 この設定の結果、vm の仮想ネットワークインターフェースは、あたかも、 この KVM Box が接続しているネットワーク (192.168.0.0/16) に参加している ように振舞います。 つまり、vm に対して、KVM Box の外からネットワーク経由で直接、その vm に アクセスできるという事です。 これは、vm を server として利用する場合には、必須な設定と言えます。 これは、KVM への設定ではなく、KVM が動く ubuntu BOX にその設定を行う事に 注意してください。 もちろん、KVM を利用して vm を作成する時にも、このブリッジネットワークを利用する ように、vm の設定ファイルにその記述を行う必要があります。 更に、複数の計算 Node に跨がる、複数の vm に、矛盾なく IP Address を割 り振るために、OpenNebula のフロントエンドが、個々の vm の生成指示を KVM に渡す時に、その生成される vm の IP Address を指定するようになって います。
ブリッジ設定するには、/etc/network/interface を変更する必要があります。 Web によっては、ブリッジ設定をする場合に必要なパッケージがあるとの事ですが、 どうやら、opennebula-node か、あるいは、kvm のパッケージをインストールすると、 同時にその関係のパッケージもインストールされる様です。
行う作業は、
cloud-node-006:~# vi /etc/network/interface.
または
cloud-node-006:~# cp /mnt/wraper/interface /etc/network/interface
です。
auto eth0 iface eth0 inet dhcp
# auto eth0 # iface eth0 inet dhcp auto br0 iface br0 inet dhcp pre-up ifconfig eth0 down pre-up ifconfig eth0 0.0.0.0 promisc up pre-up brctl addbr br0 pre-up brctl addif br0 eth0 pre-up ifconfig eth0 up post-down ifconfig eth0 down post-down brctl delif br0 eth0
変更内容ですが、 まずは、eth0 の設定を削除し、代わりに ブリッジインターフェース (br0) を作成し、 それを、eth0 に関連させます。 このインターフェースが up する前 ( pre-up ) に、これが関連つけられた eth0 を promisc ( 自分の mac address と事なるフレームであっても受け付けるようにする ) に 設定するのがポイントの様です。
/etc/network/interface に行った変更を、実際に反映させるために、 この node のネットワークを再立ち上げします。
cloud-node-006:~# /etc/init.d/networking restart
ネットワークの再起動により、コネクションが切れる事に注意してください。 もし。ssh でリモート作業をしているのであれば、もう一度、login しなおす必要があります。
OpenNebula のフロントエンドの指示に従って、計算 Node が、vm を作り、サービスを開始するわけですが、 vm その物の設定や vm が使うディスクイメージなどを保持する場所が必要になります。 その場所が、/usr/local/opennebula となるので、その Directory を作成し、オーナーを oneamdin にします。 oneamdin は、openebula-node (openebula でも) をインストールすると自動的に作成されるアカウントで、 OpenNebula のフロントエンドの、このアカントから、ssh 経由で、計算 Node のこのアカウントに命令を おくり、libvirt で、kvm/qemu に指令を出すという形になっています。 したがって、OpenNebula 関係のファイルは、この oneadmin が所有者になるようにしておくわけです。
cloud-node-006:~# mkdir -p /usr/local/opennebula cloud-node-006:~# chown oneadmin /usr/local/opennebula
この Directory が利用される理由は、フロントエンド ( cloud-core ) の oneadmin の環境変数 が、「ONE_LOCATION=/usr/local/opennebula 」と設定されているからです。 これは CJ が、標準の配布パッケージに満足せず、新しい版を手動で、インストールし、その時に この値 ( OpenNebula のインストール先 ) を利用したからです。 標準パッケージの場合は、パッケージが作る /usr/lib/one が使わえるらしく、この作業は不要です。
以下の作業は、これまで作成してきた計算 node の root@cloud-node-006 での作業ではなく、 フロントエンドの oneadmin@cloud-core での作業である事に注意してください。
新しい Node を追加するには、onehost というコマンドで、その node の 名前(IP Address) と、 それと通信するための手段を指定して作成します。
oneadmin@cloud-core:~$ onehost add cloud-node-006 im_kvm vmm_kvm tm_ssh
cloud-node-006 は、KVM であり、それとの通信は ssh を利用するので、 "im_kvm" と "vmm_kvm" と、それから "tm_ssh" を指定しています。 この他に nfs を利用する方法もあるようです。
フロントエンドと、KVM Node は、tm_ssh という手段を利用して通信を行う、 すなわち、ssh で、通信を行う事をきめたので、フロントエンド から、KVM Node へには、 パスワード無しで通信できるようにしなければなりません。 その為には、フロントエンドの oneadmin の public key を、Node の oneadmin の authorized_keys に登録する必要があります。 あと、同時に、host key も登録する必要がありますが、それには ssh コネクションを一度行い、 キーの登録を行えばよいことになります。
oneadmin@cloud-core:~$ cp .ssh/id_rsa.pub /var/nfs_share/wrapper
そこで、まず、oneadmin@cloud-core のキーを NFS で公開しているディレクトリコピーする 必要があるわけですが、これは一度やれば済むので、毎回する必要はありません。
この作業は、今度は、oneadmin@cloud-node-006 で行う事に注意してください。
oneadmin@cloud-node-006:~$ cat /mnt/warpper/id_rsa.pub >> ~/.ssh/authorized_keys
この作業によって、 oneadmin@cloud-core から oneadmin@cloud-node-006 に、パスワード なしで、ssh login できるようになります。 確認しておきましょう。
以下の作業は再び、最初の状態、すなわち、root@cloud-node-006 での作業であることに
注意してください。
なぜ、ラッパーが必要かというと、次の二つに理由によります。
フロントエンドがKVM Nodeに渡す、vm定義ファイルのdomain指定が"kvm"固定になっていて、どうも、この定義ファイルでは、CPUの仮想化技術が対応していなKVMノードでは、vmが作れないらしい。 domainを"qemu"にすればよいのだが、フロントエンド側ではそうしてくれない。 そこで、その定義ファイル利用する/usr/bin/virshにラッパーをはさみ、定義ファイル中のdomain指定の"kvm"を強制的に"qemu"に書換える事で対処した。 libvirt経由で、/usr/bin/kvmや/usr/bin/qemuが呼ばれる場合、vmにディスクイメージを指定する方法が二つ( -device= ..と-hda= .. )あるのだが、どうゆうわけだか、後者は上手く行くのに、同じ意味の前者の指定が上手くゆかず、かつ、libvirtは、前者の形式しか利用してくれない。 そこで、その引数を伴って実行される/usr/lib/kvm, /usr/lib/qemuにラッパーをはさみ、引数を強制的に-hda=の形に書き換える事で対処した。
この対処方法が適切かどうかは解らないが、これらの対処をすれば、動くようになります。
cloud-node-006:~# mv /usr/bin/virsh to /usr/bin/virsh.ORIG cloud-node-006:~# cp /mnt/wrapper/virsh /usr/bin cloud-node-006:~# chmod a+x /usr/bin/virsh
このラッパーを挟む事により、/tmp/virsh.log を作る(削除しないので肥大する)ようになります。 運用時は、その事に気を付けてください。
cloud-node-006:~# mv /usr/bin/virsh to /usr/bin/kvm.ORIG cloud-node-006:~# cp /mnt/wrapper/kvm /usr/bin cloud-node-006:~# chmod a+x /usr/bin/kvm
このラッパーを挟む事により、/tmp/vm.log を作る(削除しないので肥大する)ようになります。 運用時は、その事に気を付けてください。
cloud-node-006:~# mv /usr/bin/virsh to /usr/bin/qemu.ORIG cloud-node-006:~# ln /usr/bin/kvm /usr/bin/qemu
qemu と kvm は、同じ内容なので、link しておきます。 そうすれば一方を vi で変更した時に、他方にもその変更が反映されます。
virsh は、libvirt-bin サービスで開始される libvirtd 経由で vm のコントロールを するのですが、どうゆうわけだか libvirt-bin サービスは、起動時には、エラーメッセージ を出力して、開始されません。 理由はバグ らしいのですが、対処方法も判りません。 ただ、起動後であれば、service コマンドを利用して、手動でサービスを開始できるので、 今のところはそれで対応しています。
cloud-node-006:~# service libvirt-bin start