2012年7月12日木曜日

CloudStackの再インストール前提のアンインストール


CloudStackの再インストール前提のアンインストールの過去メモ。
(私の導入手順を行った人しか使えない。)


●パッケージのアンインストール(管理サーバとKVM計算機ノード)
# cd CloudStack-oss-3.0.2-1-rhel6.2
# ./install.sh
>R
# rm -rf /var/log/cloud /etc/cloud /var/cache/yum/x86_64/6/cloud-temp/ /usr/lib64/cloud/


●管理サーバ
# mysqladmin -u root -p drop cloud_usage
# mysqladmin -u root -p drop cloud

# reboot

●計算機ノード (KVM)

# mount
/mntにマウントされている全てのNFSマウントをアンマウントする。


# rm -rf /etc/libvirt/qemu/*.xml
# mv /etc/libvirt/storage/default.xml /root
# mv  /etc/libvirt/storage/autostart /root
# rm -rf /etc/libvirt/storage/*.xml
# mv /root/default.xml /etc/libvirt/storage/
# mv /root/autostart /etc/libvirt/storage/
# rm -rf /var/lib/libvirt/images/*
# rm -rf /mnt/*
# rm -rf /root/.ssh/id_rsa.pub.cloud
# rm -rf /root/.ssh/id_rsa.pub.cloud.pub
# rm -rf /etc/sysconfig/network-scripts/ifcfg-cloudbr0
# rpm -e qemu-kvm qemu-img libvirt
# rm -rf /etc/libvirt/qemu /etc/libvirt/storage/
# rm -rf /var/lib/libvirt/qemu/snapshot/*
<<オリジナルのifcfgをバックアップしてある場合>>
# cp -f /root/ifcfg-eth* /etc/sysconfig/network-scripts
<<オリジナルのiptablesをバックアップしてある場合>>
# cp /root/iptables /etc/sysconfig/
# reboot

●計算機ノード (XenServer)
XenServerを再インストール


●ストレージノード
# rm -rf /export/primary ; mkdir /export/primary
# rm -rf /export/secondary ; mkdir /export/secondary

2012年7月10日火曜日

間違いだらけのクラウド業者選び

ベンダーニュートラルで書いているので、特定のクラウド業者を非難、攻撃したりヨイショするわけでもない。以下は、完全に個人の意見である。また、なぜ私がクラウド業界に見切りをつけたのかの原因かもしれない。


ただ、もし、クラウド関連のプロジェクトで上手く行っていないことがあるのであれば、業者選定や業者とのつきあい方を見直すことも場合によって必要であるのではと思う。
自身の経験からして、以下のケースに複数あてはまるようであれば、かなりヤバいと思う。書いていてかなり非常識なケースだなと思ったが、麻痺をしてくると非常識が日常になることもありうる。

1. WEBページにプライバシーポリシーの記載などがない。
セミナーをやる会社で多い。新興系ベンチャーだから仕方がないかもしれないが、プライバシーポリシーの記載が無いのである。ベンチャーだから仕方ないのは、社内だけの事情なので、それを押し付けられてもどうにもならない。
なので、そのようなセミナーに行くと必ずすぐsalesforce.comらしきシステムを使って(クラウド系の企業だし。)営業メールが来る。毎度毎度来るので、スパムに入ってしまうので気がつかないかもしれないが。(メルマガの登録なんてもっての他)
それだけではなく、記載されている企業間で勝手に名刺や名簿をやりとりしてしまっている可能性がある。特に外国企業なので、日本の個人情報保護法やプライバシーポリシーなどの考えはもともと知らないので、不正に受け取った個人情報を受け入れてしまう可能性がある。怪しいと思ったら、本当の意味での個人情報のみをさらすべきかもしれない。彼らには、法人のアカウント以外は興味はない。

2.御社だけに特別価格で提供するやビジネスプランを一緒に考えましょうというフレーズ
海外企業は、日本での市場を開拓したいので日本に代理店を設置しているのだが、その代理店の業界スキルやエンジニアスキルが無い場合、どこに売っていいか分からないなので、自分たちのアカウントに対して手当たり次第ということになる。どのような製品で、どこにバリューがあるか説明ができないために、価格を特別価格に設定することになる。(営業の最終兵器の値下げがいきなり登場。。。)
さらに、ビジネスプランを一緒に考えましょうもおかしい。まずは、代理店側が市場調査をして、適切な市場で展開をするのだが、その業務を一緒にやるということは、顧客が代理店の作業をただ働きをしているのではと思う。また、ビジネスプランは、あくまでも顧客内部で揉む必要があるとおもうのだが、その顧客の事情を知らない状態でビジネスプランを一緒にはできないし、そもそも頼んでいない。

3.製品説明が出来ない。宿題ばかり。
代理店に、エンジニアが居ない、居てもフルタイムのエンジニアがいない、エンジニアスキルが無い会社に多い。そもそもエンジニアスキルが誰もないから、ホワイトペーパーの丸写しあるいは、あまり製品に関係ない持論を出してくる。なので、ミーティングが終わった後も、「何の製品で何に使うのだろう???」という感じを受ける。さらに、「我々も知らないことなんだろうな、勉強しなきゃ」と思うかもしれない。これは巧みな心理テクニックとも言える。向こうが分かったフリをして自身でも分からないことを話として聞いた場合、あくまでもミーティングの場内では、聞き手のみが分からないという状態になる。(実際はそのミーティングの場では誰も何が何だかわからない)そこで、聞き手は、「理解していない相手」の話を信用してしまう。また、話を社内で進めていく上で、いぜん何が何だか分からないので、余計に相手を信用せざる得ない。(もう何も分かっていない代理店を信用せざる得なくなる。)
ここまで行くと、上手くいくかどうか、完全に「運」である。社運は別のところでしかるべきところで使うべき。負け戦にしょっぱなから突っ込むべきではない。
外部と交流が薄い企業は、客観的な判断する能力が弱っているので気をつけるべき。なので今からでも遅くはないので、情報収集をすべき。

4. 日本の代理店でデモができない。
これは実は大問題かもしれない。
日本の代理店でデモができないので資料だけもってくる。ひどい時はWebから入手できるであろう英文のブローシャー。もし、デモを見たいというと外国のベンダーにある本社デモ環境を見せてくる。
日本で唯一の代理店が自分の所で環境が作れないということは、その製品を理解していない。(どのような製品なのかを理解していないから当然なのだが)さらに日本語環境で動作するかは「購入者責任」。多分、動作検証も購入者責任になる。つまり、導入には、製品検証も加わるので、サービスインにはかなりの時間がかかる。製品の品質がもともと悪ければさらに時間がかかる。たまに「アジャイルで」というフレーズを聞くが、これだと、購入した本人たちがアジャイルの開発を強いられてしまう。さらにサービスインをした後も日本語(日本語で問い合わせができる、日本語での動作環境をサポートできるという意味で)も全く期待できない。
今、エンジニアを採用中と言ってもどういうスキルセットが必要なのかも分かっていないので永遠に期待はできない。

注:代理店がデモをできないケースは全てが悪いとは言わない。代理店によっては、単純にブリッジだけしますというケースもあるからだ。その場合は、こちらも覚悟をしている(こちらは逆に覚悟をすべき)ので問題はあまり生じない。

5.海外とのコネクションを強調することを超えて、本国の人間が登場してくる
そのベンダーの日本法人ならば仕方ないが、代理店レベルで外国人が出てくる。そのやり取りを代理店が行うのではと思うのだが。面倒くさい契約を顧客にやらせて名声を取ろうとしているのかもしれない。実作業やエンジニア的な事はやらないが、我々(代理店)が仕事したといいたいのかもしれない。見分けかたは、外国とGoToMeetingやWebEX、Skypeを多様する代理店は要注意。今は、グローバルにこういったシステムをつかわなければと言うが、たしかにそう思う。でも海外ベンダーとのやり取りを押し付けるのと話は違う。もし、あなたが英語をしゃべれるのであれば、そもそも代理店は不要以上に余計だ。
似たようなケースで、これからは英語が必要なので、英語で会議しますと言い出すとき。
実際、英語は必要だが、本当に確認しなければならないときは、それぞれの母国語で理解をして話すべき。不得意な言語で話をまとめようとするのは、代理店側が早く適当に契約をとりたいからだと思う。普通は確実を要する契約は、それぞれ母国語でやる。
総理大臣は海外で英語は話せても使わないと思う。
http://okwave.jp/qa/q5760816_2.html
No.12 の人の回答がそれ。


6.必要な環境要件やら資材があやふや。
だーれも作ったことが無いのだから、仕方ないのだが、用意するこちらとしては、予算と採算を考えなければならない。どこの企業も予算外の捻出はできない。ビジネスコンサルをすると代理店は言ってくるかもしれないが、彼らは予算も採算もコンサルどころかサンプルも出ない。そもそも、IaaS的な先行投資が必要な環境は、サービス用環境の他に最低でも1つ(本当は2つ欲しいが)必要なのを理解していない。その根本原因は、業務知識がないということに他ならない。


上記の6項目は、私が数々のクラウド商材の提案を受けたときに感じたことだ。
当時は、「あー、とりあえず何か新しいおもちゃを見つけたんだな。箱から出さないで大切にしているんだなぁ」と思っていただけだけど。話を進めるとドツボになるケース。
幸い今は、クラウド業界から離れて、こんな心配もないのだが、もし、何かの役にたつのであればという思いで書いた。


まとめると、代理店の見極めするポイントは以下である。
1. 企業としてしっかりしているかどうか(当たり前だが)
まず、日本だけで簡潔できる提案をしてくるか。日本企業間で取引して、日本人の勤める日本企業に対して営業するのであれば、「楽天」以外許されない。楽天を否定する訳ではない。楽天は、会社としてちゃんと声明をしているのだから。
2.こちらの業界、業種についての知識がある。それに対応した商談をちゃんとできる。
業界常識や前提条件、習慣、トレンド、キーワード、用語がお互いで正しく理解ができれば、それぞれの役割分担がしっかりする。
3.製品の説明やデモが日本の代理店レベルで正しくできる。
商材をしっかり、「輸入した」証でもある。

今思えば、もっといい代理店にあっていればなぁと思う

2012年7月5日木曜日

CloudStackテンプレートの作成方法(2012年9月修正)

CloudStackのインストール方法はチラチラみかけるようになったが、テンプレートの作成まで書かれているページは少ない。(私の導入方法も全て書いてあるわけではないが)

こういったソフトで一番ありがちなのが、環境を作ったで終わってしまう系。昔のLinux系の雑誌やブログもインストールする方法は書かれていたが、利用する方法(TeXやらコンパイラーの利用方法)は一切書かれていなかった。
唯一書かれていた本は、『Linux入門 アジソン・ウェスレイ・ジャパン 小山裕司 斎藤靖 佐々木裕 中込知之』(多分絶版。以前までdviファイルが入手できたような気がするが。)

ありがちのクラウド業者でインストールについては語るが、運用までは語れないという会社が多い。(間違いだらけのクラウド業者選びは別記事で。)
志村けんがたまに言う「子づくりは好きだけど、子育ては嫌い」というネタ状態である。

なので、子づくりだけではなく、子育てをしなければならない。

閑話休題

テンプレートの作成の仕方
まず、ISOイメージからインスタンスを作り、普通に起動させる。(自分が使う感覚で構わない。)
ただし、ホスト名、ユーザ名、パスワードは、一時的なもので作成する。
やっている作業は、
 sshサーバのインストール --- コンソールだけではなくsshで入れるようにする
 ntpのインストール  --- 仮想環境では必ずntpを動かさないと時刻がずれるので致命的
 acpidのインストール --- virshから停止ができないときがあるから。
 sshのホストキーの削除 --- これ忘れがち。
 mac address関連の削除 --- これも忘れがち。起動してもネットワークつかえねぇ。だと話にならない。


以下にOS毎に記載する。(2012年9月修正)
※CloudStackでインスタンス名をつけると、ホスト名に反映されるように修正。

CentOS6.3/CentOS5.8

インスタンスサイズ Small
ボリュームサイズ 10GB
選択パッケージ Baseのみ
rootパスワード password

インストーラーが再起動して、ログインプロンプトが出てきたらISOをデタッチする。
CentOS 5.8は、ISOで再起動してしまうので、インスタンスをStopさせて、ISOをデタッチし、その後インスタンスを起動させる。
●最低限必要なサービスのインストール、設定、パッケージの更新
yum install acpid ntp wget openssh-server
chkconfig acpid on
chkconfig ntpd on
chkconfig sshd on
yum -y update

●パスワードリセットデーモンの導入(オプション)
cd
wget http://cloudstack.org/dl/cloud-set-guest-password
chmod +x cloud-set-guest-password
mv cloud-set-guest-password /etc/init.d/
chkconfig --add cloud-set-guest-password

●CloudStackのインスタンス名をホスト名にする設定
/etc/sysconfig/networkのHOSTNAMEの修正
HOSTNAME=localhost.localdomain

/etc/sysconfig/network-scripts/ifcfg-eth0のMAC Addressの削除
HWADDR=の行を削除
/etc/hostsの確認 ->ループバックアドレスしかないはず

<<<テンプレートを修正した後はここからやればよい。>>>
●SSHホストキーの削除
rm -rf /etc/ssh/ssh_host_*
●eth0を認識させるための設定
rm -rf /etc/udev/rules.d/70-persistent-net.rules <--CentOS 6.3のみ
●ヒストリの削除、その他
yum clean all
history -c
halt
テンプレートをコントロールパネルで作成


Ubuntu 10.04/12.04

インスタンスサイズ Small
ボリュームサイズ 10GB
選択サービス OpenSSH-Serverのみ
初期ユーザ名/パスワード user/password
インストーラーが再起動して、ログインプロンプトが出てきたらISOをデタッチする。

sudo -i
●最低限必要なサービスのインストール、設定、パッケージの更新
aptitude -y install acpid ntp openssh-server
aptitude update
aptitude -y upgrade
●CloudStackのインスタンス名をホスト名にする設定
rm -rf /etc/hostname
●SSHホストキーを再作成させるための設定
vi /etc/rc.local
# Generate new host keys if they don't exist.
# This will also restart the server if necessary.
if [ ! -e /etc/ssh/ssh_host_rsa_key ]; then
  dpkg-reconfigure openssh-server
fi

●パスワードリセットデーモンの導入(オプション)
cd
wget http://cloudstack.org/dl/cloud-set-guest-password
chmod +x cloud-set-guest-password
mkdir -p /var/lib/dhcp3 (Ubuntu 11.04 以降のOSのみ)
mv cloud-set-guest-password /etc/init.d/
update-rc.d cloud-set-guest-password defaults 98
aptitude install whois (Ubuntu 12.04 LTS)
あるいは
apt-get install mkpasswd (Ubuntu 10.04 LTS)

<<<テンプレートを修正した後はここからやればよい。>>>
●SSHホストキーの削除
rm -rf /etc/ssh/ssh_host*
●ヒストリの削除、その他
aptitude clean
history -c
exit
ログアウト直前で history -c を実行
CloudStack側でインスタンスを停止
テンプレートをコントロールパネルで作成


CloudStack 3.0.2 考察

CloudStackを構築をしてみたが、辛口評価をしてみた。(ウソやヨイショしてもしかたないし。)

ハイパーバイザー関連

●KVM
Agentのインストールが必要。(たいした事ないが)

CPU
   SpeedStepが作動する
   リソース変更はlibvirtがcgroupを使って制御している。
   KSMが使える。動作させるイメージの数を制限すれば、オーバーコミットも可能?

I/O
  仕様的に期待できない。(えっというほどではないが。)
    ボリュームのイメージフォーマットはqcow2なので、I/Oは期待できない。
    さらにvhost-netは、DHCPのアドレス取得などに問題があるため利用できない。

●XenServer
Agentのインストールが不要。
CPU
  SpeedStepが作動しない。これは大変まずい。
  リソース変更は、xeコマンドのVCPUs-paramsを使って制御している。
  稼働中のインスタンスのSteal値の監視が必要となる。
Paravirtual kernelが廃れてしまったので面倒だなぁ。。。

I/O
  イメージフォーマットがLVMダイレクトなので、ディスクパフォーマンスは速い。
  ネットワークも普通にパフォーマンスは出るはず。

ハイパーバイザー関連コメント

KVMは、データセンターでホスティングするような事業者向き。少ないハードウェアリソースで沢山のサービスを行う。ある程度OSのイメージが限定されているケースでは、KSMでパワーを発するかと思う。

XenServerは、ハードウェアの販売や、リソースで価格付けをするようなSIの業者に向いている。オーバーコミットが出来ない分、ハードが販売できるし、各インスタンスのリソース制御もKVMようにトリックを使っていないからリソースのパワーが正しく保証できる。
さらに、CloudStackのサブスクリプションを購入すると、XenServerのサブスクリプションも付いてくる。これ注目!

普通に利用するならば、どちらでも構わないが、私はKVM推し。Xenのテクノロジーは、XenSourceが買収されてからパッとしないし、KVMやVMwareで普通に実装されている機能が未だ実装されていない。(気分の問題と捉えるならばそれでも構わないが。)あと、SpeedStepが利用できなく、ParaVirtual Kernelを今更使うというのはちょっと。。。


●構成全般
・計算機サーバにある程度ローカルディスクの容量があると、インスタンスのイメージをNFSではなく、ローカルに置ける。

・利用するテンプレートタイプの数を少なくし、1インスタンス以上動作していると起動が速い。(気がする。)

・CPUの総クロック周波数がインスタンスで利用できる最大リソース。
例えば、Xeon 2GHz (6core/12thread)のCPUの場合、2GHzx12=24GHzのリソースが利用できる。
AMDのCPUは安いが、HTが使えないため思った以上にインスタンスの稼働はできないかもしれない。結局台数が増えるだけ。(Atomで大量のサーバをさばくよりもCore i7で集約したほうがユニット数、オーバーヘッド数、電源容量の現象につながる。)
 ただ、AMDでそろえたほうが、全部物理CPUなのでパフォーマンスはいいかもしれない。
(AMD推しの気持ちもわかる。)

・オーバーヘッド計算
ハイパーバイザーのオーバーヘッド以外に、system vmのリソースが必要なのに注意
 sec strg/console/routerで CPU 1.5GHz/Mem 1.5GB。


ちなみに、Eucalyptusとの比較
Amazon AWSとかなり互換をもっているが、CloudStackと大きな違いがあった。
それは、インスタンスが物理CPUに依存してしまう。
例えば、ハイパーバイザーが載っているハードウェアが4coreの場合、そのハイパーバイザーが稼働できる1 vcpuのインスタンスは4インスタンスまで。クロック周波数の総和が効かない。よって、CloudStackと比較すると、膨大な量の計算機ノードが必要となる。構築費用もかさみ、コスト高。動かすだけなら構わないが、サービスとなると採算がかなり厳しい。(ならばAmazon AWSを使うほうがいい。絶対。)