とりあえずコンテナにプロセスを突っ込んでみるということをまずは試しておきましょう。

ということでlxcのツール類をインストールしているのであれば、lxc-executeというコマンドが出てきます。これ以外にも”lxc”で始まるツール類がいくつか用意されているのですが、とりあえずこれだけ。

lxcのサンプル設定ファイルが/usr/share/doc/lxc/examples以下に入っていることもあるかもしれませんが、ここではとりあえずネットワーク無しの設定をちょっと持ってきます。

$ cat lxc-empty-netns.conf
# Container with new network withtout network devices
lxc.utsname = omega
lxc.network.type = empty
lxc.network.flags = up

utsnameはコンテナに割り当てるホスト名、その他、ネットワークの設定として”empty”(空)を設定しています。これによりネットワーク的には外に出られない、閉じ込められた環境になります。上記の設定ファイルをコピーしてくるなり、書き込んだファイルを作るなりしてます。

# lxc-empty-netns.confとして先の内容を保持しています
$ sudo lxc-execute -n omega -f ./lxc-empty-netns.conf /bin/bash
omega:/home/densuke# ifconfig
lo        Link encap:ローカルループバック
          inetアドレス:127.0.0.1 マスク:255.0.0.0
          inet6アドレス: ::1/128 範囲:ホスト
          UP LOOPBACK RUNNING  MTU:16436  メトリック:1
          RXパケット:0 エラー:0 損失:0 オーバラン:0 フレーム:0
          TXパケット:0 エラー:0 損失:0 オーバラン:0 キャリア:0
      衝突(Collisions):0 TXキュー長:0
          RXバイト:0 (0.0 B)  TXバイト:0 (0.0 B)

"-n omega"がコンテナの名称です。ifconfigを直後に走らせてますが、eth0が見えていません。閉じ込めに成功してます。

ではちょっと制約を、メモリに上限を割り当ててみましょう。その前にちょっとしたテストツールを自作してみます。

#include 
#include 

int main()
{
    int n;
    for (n = 1; n <= 8; n++) {
        char *s;
        int size;
        int i;
        size = 1 << n;
        printf("check memory: %dMB...", size);
        s = (char *) malloc(sizeof(char) * size * 1024 * 1024);
        if (!s) {
            perror("unable to allocate memory!");
            return 1;
        }
        for (i = 0; i < size * 1024 * 1024; i++) {
            *(s + i) = '\0';
        }
        free(s);
        printf("OK\n");
    }
    return 0;
}

なんてコードにしてみました。ベタすぎますが、2～256MBまでmalloc()して、実際に書き込みをしてメモリを利用するというものです。あたりまえですが、通常空間では成功します。

check memory: 2MB...OK
check memory: 4MB...OK
check memory: 8MB...OK
check memory: 16MB...OK
check memory: 32MB...OK
check memory: 64MB...OK
check memory: 128MB...OK
check memory: 256MB...OK

制約かけに行きましょう。ディレクトリ/cgroup/omegaに移動して、設定を行います。

# cd /cgroup/omega
# echo $[64*1024*1024] > memory.memsw.limit_in_bytes
# echo $[64*1024*1024] > memory.limit_in_bytes

名前の通りでバイト単位でサイズを設定しておきます。"memsw"のほうは、マニュアルを見る限り、スワップ込みの量だそうです。64MB分を設定したので、さてどうなるか…

# ./mem
check memory: 2MB...OK
check memory: 4MB...OK
check memory: 8MB...OK
check memory: 16MB...OK
check memory: 32MB...OK
強制終了

という感じで終了してます。64MB処理の最中で落ちているのがわかりますが、これはコンテナ内で64MBまでしか使えないという制約になっている(ulimitだと各プロセスでという縛りの模様)ため、すでにシェルなどがメモリを取っていることから、実際に使えるのは64MB未満になっているのですね。

コンテナの中で動いているプロセス状態は、lxc-psで確認することができます。岩場外からコンテナ上のプロセスをpsで取得するようなイメージ。

# lxc-ps -n omega --lxc ax
CONTAINER    PID TTY      STAT   TIME COMMAND
omega      25795 pts/6    S      0:00 /usr/lib/lxc/lxc/lxc-init -- /bin/bash
omega      25797 pts/6    S+     0:00 /bin/bash

複数コンテナが動いているときは、コンテナ名を指定することで絞り込むことができます(-n コンテナ)。

今回のエントリでは、同一ファイルシステムでコンテナで囲っていることになります。メモリとネットワークの制約をかけてみたわけですがその他のことはまた今度。

これはブログのネタとして残せそうな感じになってきたので、何回かに分けて書いてみたいと思います。まずはlxcの紹介ですね。

lxc(Linux Container)は、いわゆる仮想化技術のひとつです。といってもハードウェアの仮想化というものではなく、OSの仮想化に近いものです。

• OS部分(Linux)は共有
• 実行空間は共有もできるしchrootによる分離も可能
• CPUやメモリを(やんわりと)制限できる
• ネットワークは切り分け可能

というのがここまでの感想。いずれにしても自分でいじったり、調べた結果に基づいての判断なので、知らないことだらけだったりします。

カーネルコードは共有なので、レイヤー構造が複雑になってパフォーマンスに影響するということはほとんどなさそうです。ファイルシステムツリーはそのまま使うこともできるし、chrootを併用して、特定のツリーいかしか見えないようにすることもできます。

lxcを使用する際に、空間(コンテナ)に名前をつけるのですが、その空間および、空間内で呼び出されたプロセスは、コンテナの名前空間に紐づけられた制約を適用することができるようになっていて、結果としてCPUやメモリに関して制限をかけることができます。触っていませんが、ディスクデバイス(ブロックデバイス)などにも制約を加えられるみたいです。また、いくつかの手法で仮想的なイーサネットを提供できるため、NAT的運用を伴えばネットワークを閉じ込めたりすることも可能です。

コンテナの名前空間は、cgroupと呼ばれるもので制御されます。カーネルの機能でcgroupを有効にしていれば、とりあえず見ることができます。使えるかどうかに関しては、`/proc/filesystems`を`grep`するのが手っ取り早いかな。

densuke@yuzu% grep cgroup /proc/filesystems
nodev   cgroup

使えることがわかったら、マウントしてみましょう。

densuke@yuzu% sudo mkdir /cgroup
densuke@yuzu% sudo mount -t cgroup cgroup /cgroup

常用しそうなら、後ほど`/etc/fstab`に入れておきましょう。あとで消せなくなるなる恐れもありますが(再起動すれば消える)、試しにこの/cgroupディレクトリに適当な名前のディレクトリを掘ってみると、自動的に中にエントリができます。この作ったディレクトリ名がコンテナ名となります。

densuke@yuzu% cd /cgroup
densuke@yuzu% ls
18977                   cpuset.memory_pressure_enabled
blkio.io_merged         cpuset.memory_spread_page
blkio.io_queued         cpuset.memory_spread_slab
blkio.io_service_bytes  cpuset.mems
 …中略…
cpuset.memory_migrate   release_agent
cpuset.memory_pressure  tasks
densuke@yuzu% sudo mkdir FUGAHOGE  # コンテナFUGAHOGEを作成
densuke@yuzu% ls FUGAHOGE
blkio.io_merged         cpuset.memory_spread_page
blkio.io_queued         cpuset.memory_spread_slab
blkio.io_service_bytes  cpuset.mems
blkio.io_service_time   cpuset.sched_load_balance
 …中略…
densuke@yuzu% sudo rm -rf FUGAHOGE # だからって簡単にrmdirできないみたいorz
rm: cannot remove `FUGAHOGE/cpuset.memory_spread_slab': 許可されていない操作です
rm: cannot remove `FUGAHOGE/cpuset.memory_spread_page': 許可されていない操作です
rm: cannot remove `FUGAHOGE/cpuset.memory_pressure': 許可されていない操作です

ということで、適切なツールでcgroup空間は操作しましょう。lxcパッケージを使えばいいのですが、0.7.3にはバグがあるというお話なので、最新版(0.7.4のrc1?)を開発元から落としてきて入れておくのがいいかもしれません。

• http://lxc.sourceforge.net/

ということでまずはここまで。次回は実際に起動させてみましょうか。

すべてわかる仮想化大全2011 (日経BPムック)
	ITpro/日経コンピュータ/日経コミュニケーション/日経SYSTEMS/日経NETWORK 日経BP社 2010-10-12 売り上げランキング : 2047 Amazonで詳しく見る by G-Tools

• http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.37.1 (ChangeLog)
• http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.37.1.tar.bz2 (カーネルコードダウンロード)

ChangeLogをざっと眺める限り、やはり細かいところの修正が多いようです。特に私みたいにサーバ用途での運用においてはそれほどの御利益はなさそうです。とはいえ、カーネルの落ちる原因をいくつかつぶしてくれてるわけで、利用しているなら使わない理由もないでしょう。という感じで、昨日の夜に差し替えました。

私が手元で書き換えてるのは、毎度毎度のことですが、p4-clockmod.cです。Atom 330のクロック動的変更をさせてくれない原因となっているパラメータを書き換えるというものです。

まぁ、Atomはもともと省電力なので、クロックの変更処理を行うレイテンシの問題(そこそこクロックを要する)からか無効にしているという状況を解除するというダメ行為なんですけどね。

   ファイル: arch/x86/kernel/cpu/cpufreq/p4-clockmod.c
        /* the transition latency is set to be 1 higher than the maximum
         * transition latency of the ondemand governor */
        policy->cpuinfo.transition_latency = 10000001; → 10000000に変更
        policy->cur = stock_freq;

ということで元気に動いております。クロック変更もちゃんと機能してます。

$ ~/bin/cpuwatch
-------------CPU 0-------------------
Clock: 399999
Count: 1776

-------------CPU 1-------------------
Clock: 199999
Count: 1910

-------------CPU 2-------------------
Clock: 399999
Count: 1776

-------------CPU 3-------------------
Clock: 199999
Count: 1910

rc取れてるけどstableでもない、こいつをどう評価するんだ?

例によって例のごとく参考資料を、と。

• カーネルソースダウンロード
• ChangeLog
• ChangeLogダイジェスト版(拙作)

本サーバのカーネルは今朝時点で「ほんのりカスタム版」(AtomのCPUクロック変更を有効にしたモノ)2.6.36に更新済みとなっております。

例によってのoldconfig時に気になったのは…

• メモリ上では圧縮されているRAMディスク(ZRAM)の追加、以前のramzswapの応用ですね
• squashfsにLZO圧縮サポートが追加されたり拡張属性がサポートされたり
• うちのCPUには関係ないけど、新しめのIntelチップで持ってるコア単位での電圧操作機構をサポートしたり
• CIFSのクライアント側キャッシング機構をサポートしたり
• ChangeLogによると、TTYまわりの遅延低減策(EXTPROCフラグ)とやらが入ってるという話ですが、どうもこれはライブラリやアプリ側のサポートが必要という話なので、今すぐどうなるという話でもないみたい

とまぁ現場的意見。

いつものようにKernelNewbiesは2.6.36向け記事をだしてくれてます。こちらを読むとまた別の視点で面白い。

• fanotify機構の追加(この手のnotify機構はずいぶん聞くけど、分散しすぎてないか?)
• Workqueueが複数CPUに分散できるようになった(と見たらいいのか?)
• AppArmorが追加された(LSMのおかげでいくつかのセキュリティ機構を後付けできるようになってますね)
• Device MapperでSSD(メモリ素子を使ったディスクね)で使われているdiscardコマンドに対応できるようになった
• KVMの改良

なんてのもあるみたい。あいかわらずいっぱい組み込んでくれる…

実用Git
	Jon Loeliger 吉藤 英明 (監訳) オライリージャパン 2010-02-19 売り上げランキング : 134215 おすすめ平均 Gitを本当に使えるようになる本 翻訳の質が低くて残念 Amazonで詳しく見る by G-Tools

カーネル開発といったらやっぱりgitだよねー

たとえばいわゆるHelloWorldとして、

println("Hello")

に対して、

$ scala HelloWorld.scala
Could not connect to compilation daemon.
Exception in thread "main" java.lang.Exception: fsc failure
        at scala.tools.nsc.CompileSocket.fatal(CompileSocket.scala:50)
        at scala.tools.nsc.CompileSocket.getPort(CompileSocket.scala:122)
        at scala.tools.nsc.CompileSocket.getsock$1(CompileSocket.scala:152)
        at scala.tools.nsc.CompileSocket.getOrCreateSocket(CompileSocket.scala:170)
        at scala.tools.nsc.ScriptRunner$.compileWithDaemon(ScriptRunner.scala:145)
        at scala.tools.nsc.ScriptRunner$.compile$1(ScriptRunner.scala:197)
        at scala.tools.nsc.ScriptRunner$.withCompiledScript(ScriptRunner.scala:225)
        at scala.tools.nsc.ScriptRunner$.runScript(ScriptRunner.scala:265)
        at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:91)
        at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)

という具合。なぜに”Could not connect to compilation daemon.”なのかというのが疑問で仕方ないのですが…

で、netstatの挙動を見ながら確認していくと、なんか見に行こうとしているポート番号にてfscが待機してないような感じです。IPv4でなくIPv6を見に行ってるような感じ。

結局、カーネルのIPv6を切って解決するという後ろ向きなものとなってしまいました。

(in /etc/modprobe.d/local-alias.conf)
alias net-pf-10 off # この内部名がIPv6なので無効(off)に

これで無事に動いてくれてるみたい。

このことをつぶやいてみたところ、似たような手法で解決しているというツイートをいただきました。うーん、ちょっと困るところです。

• ダイジェスト(拙作)
• 本来のChangeLog
• カーネルソース本体

ダイジェストコードをテロテロと眺めてみる限り、細かい虫取りというところでしょうか。まぁ4桁目ですからしょうがない。

記録を見る限り、細かいところがいろいろと。でもあまり自分の環境には関係ないというものでした。細かいバグの修正もありそうだったので、昨日の朝のうちに再構築を行い、差し替え(再起動)を行っております。別にこれといった不具合も発生せず。

あ、一部追加モジュールのコンパイルを忘れてる。やっておかないと…

• 2.6.35.4 ChangeLogダイジェスト
• カーネルソース

細かいバグがてんこ盛り、ACPIのプリエンプション処理におかしい部分があったり、一部makeが動かなくなる部分があった模様。 気が向いたら更新しましょうかね。

例によって、カーネルの変更履歴は膨大なことこのうえなしです。

• Kernel 2.6.35 ソースコード(bzip2)
• ChangeLog
• ChangeLogダイジェスト(拙作)

現在カーネルをコンパイル中です。ダイジェストが1万行を超えるというアレすぎる中、KernelNewbiesにて(現時点では正式公開ではありませんが)解説が出ております。個人的には(用途がいまいちアレですが)iptables関連で”TEE”ターゲットなるものが追加されたことでしょうか。ええ、あの"TEE"です。

• btrfsでキャッシュを経由しないダイレクトI/Oをサポート(DB周りでは重要になることが多いみたいです)
• メモリコンパクション機能の追加、コンパクションといってもデフラグっぽいのでしょうか(参考記事)
• L2TP Version3サポートが追加

なんてことが個人的に気になるところです。

なお、KernelNewbiesの記事によると、MD層の改良から、takeover機構がいくつかサポートされたようですね。

詳解 Linuxカーネル 第3版
	Daniel P. Bovet Marco Cesati 高橋 浩和 オライリー・ジャパン 2007-02-26 売り上げランキング : 32610 おすすめ平均 Linuxのカーネルの理解が ごめんなさい。積読派です。 Linux Communityへの入口 Amazonで詳しく見る by G-Tools