[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
コンピュートノードを増設したのだが、どうもコントローラノードの方で認識してくれない。
コンピュートノードを調べてみたら以下のようなログがコンピュートノードの nova-compute.log および neutron-plugin-linuxbridge-agent.log に出ていた。
INFO oslo.messaging._drivers.impl_rabbit [req-1c4cf9af-6e25-419c-87e9-e3e815f9973b - - - - -] Connecting to AMQP server on openstack.sheeprogramming.iku4.com:5672 INFO oslo.messaging._drivers.impl_rabbit [req-1c4cf9af-6e25-419c-87e9-e3e815f9973b - - - - -] Connected to AMQP server on openstack.sheeprogramming.iku4.com:5672 oslo.messaging._drivers.impl_rabbit [req-1c4cf9af-6e25-419c-87e9-e3e815f9973b - - - - -] Connecting to AMQP server on openstack.sheeprogramming.iku4.com:5672
なんか AMQP を送ったは良いが反応がない、という感じである。
受信側の rabbitMQ のログを確認してみる。以下のようなログが出ていた。
=WARNING REPORT======= file descriptor limit alarm set. New connections will not be accepted until this alarm clears.
どうも扱える接続数の限界に達していたらしい。
設定を変更してやれば、接続数の限界を変えられる。Ubuntu 14 なら /etc/default/rabbitmq-server に設定ファイルがある。これを編集し、ulimit -n 1024 の値を書き換えてやればよい。書き換えたら rabbitMQ を再起動すること。
オーバーコミットというのをやると本来あるはずよりも多くメモリとか CPU とかを使えるよ、という話。
OpenStack に限った話ではないけど。インスタンスを立てていると、物理マシンのメモリ限界を超えてインスタンスを立てることができる。例えば 8GB メモリを積んだ物理マシン上に 2GB メモリを使うインスタンスが5つ立つとか。なぜ本来ないはずのメモリがあるかのように振る舞えるのか。
パソコンを使っていてもそうだが、常にメモリを100%使っている、というわけではない。これは物理マシン上で動いているインスタンスも同じである。常に大体メモリは余っているのだ。また、 CPU 等も同様である
オーバーコミットは「常に大体メモリや CPU は余っている」という仮定の下「常にメモリや CPU 等は余っているんだからちょっとくらい多く配っても平気だよね」と多く割り当ててしまうという機能だ。
上述の仕組みである関係上「8GB メモリを積んだ物理マシン上に 10GB メモリを使うインスタンスを立てる」とかはできない。また、どれだけ大きく見せかけるかはよくよく考えて設定しなければならない。
ちなみに、OpenStack はデフォルトで「メモリは 1.5 倍オーバーコミット」「CPU は 16 倍オーバーコミット」しているようだ。
request をどう使えばよいのか分からなかったのでメモ。
const REQUEST = require('request');
const PROMISE = require('promise');
function getToken(user, password, tenant) {
return new PROMISE(function(resolve, reject){
REQUEST({
method: 'post',
uri: 'http://keystone.hiyoko.example.com:5000/v2.0/tokens',
headers: {'Content-Type': 'application/json'},
body: JSON.stringify({auth:{tenantName:tenant ,passwordCredentials:{username: user,password: tenant}}})
},
function(err, httpResponse, body) {
if(err) {
reject(JSON.parse(err));
} else {
body = JSON.parse(body);
if(body.error) {reject(body.error);} else {resolve(body);}
}
}
);
});
};
// 他の keystone へのリクエストは以下の感じで行けた
// REQUEST({uri: url, headers: {'X-Auth-Token': token}}, function(err, res, body){});
社内勉強会で話したことを再度まとめ直してみた話。
私のいる会社はパブリッククラウドのコストがかさんできた結果、プライベートクラウドがもてはやされてきた。それまではあまり注目されてなかったともいえる。
でも、実際のところプライベートクラウドって本当に安いの？
パブリッククラウド側は東京リージョンにおける Amazon EC2 のオンデマンド料金を採る。リザーブドインスタンスも考えたが、会社で相談してみたところ「あれは条件厳しいから現実的じゃないと思う」というコメントを頂いたのでやめといた。通信量は無視する代わりに、徐々に値段が下がっているのは無視することにした。このインスタンスに [400GB / 後述の条件で立つインスタンス数] の EBS をつなぐ。稼働時間は1日あたり1,4,8,16,24 時間稼働させた結果で計算。平日のみ稼働とするために [1時間あたりの料金]×[1日あたりの稼働時間]×365×5/7 とする。
プライベートクラウド側は以下の合計値とする。稼働時間は365日24時間。
※ ちょっと割き過ぎなきがする。私は1～2割くらいだった。
| プライベートクラウド 365日24時間 (4台) | 74,000円 |
|---|---|
| パブリッククラウド 平日のみ1時間 | 11725円 |
| パブリッククラウド 平日のみ4時間 | 22924円 |
| パブリッククラウド 平日のみ8時間 | 37857円 |
| パブリッククラウド 平日のみ16時間 | 67722円 |
| パブリッククラウド 平日のみ24時間 | 97588円 |
パブリッククラウドで1日18時間くらい動かしていると逆転するらしい。こまめに止めていればパブリックラウドの方が安い。
| プライベートクラウド 365日24時間 (64台) | 6,425円 |
|---|---|
| パブリッククラウド 平日のみ1時間 | 471円 |
| パブリッククラウド 平日のみ4時間 | 1165円 |
| パブリッククラウド 平日のみ8時間 | 2091円 |
| パブリッククラウド 平日のみ16時間 | 3943円 |
| パブリッククラウド 平日のみ24時間 | 5796円 |
やはり同じような結果になった。
「いやいや、この設定おかしいだろ」というツッコミはあると思うが、上述の条件をマネして計算して頂ければ大体どっちがお得かが計算できると思う。ただ、可用性の差とかもあるので一概には言えない……
やらかした。Horizon からインスタンスを作ったが、なかなかできないので Horizon から削除したら仮想マシンはできていないのに Nova はインスタンスを削除しようとしている状態になってしまい、いつまで経っても削除が終わらない、という悲劇。
解決方法。該当の仮想マシンが立つはずだったコンピュートノードの nova-compute を再起動する。するとインスタンスの削除がエラーで止まる。その後、再度削除することでインスタンスを消せる。
ただ、該当の仮想マシンが立つ予定だったノードは管理者じゃないと分からないので管理者がやること。
なお、この操作で同じノードで動いている他のインスタンスが停止したりすることはない。