LXCで学ぶコンテナ入門 -軽量仮想化環境を実現する技術

第5回 Linuxカーネルのコンテナ機能[4] ─cgroupとは?(その3)

この記事を読むのに必要な時間:およそ 6.5 分

cgroup の今後

今回を合わせると3回に渡ってLinuxカーネルに実装されているcgroupの解説をしてきました。ここまで解説したようにかなり広範囲に渡る機能が実装されている一方で,現時点でもcgroupの改良,実装は続いています。実は,今後cgroupは大きな変更がされる予定で,この連載で説明した機能や特徴が大きく変わることになりそうです。

このような時期に,この連載を書くにあたってcgroupの説明をどうすべきか少し悩みました。しかし,長期にサポートされるRHEL 7やUbuntu 14.04 LTSがリリースされたばかりであり,RHEL/CentOS 6もまだまだ現役ですので,現時点のcgroupを説明する意味はあると考えました。

一方でcgroupの大きな変更がかなり進んできており,改良が続けられているサブシステムも存在します。筆者から見ると,次にリリースされる3.16カーネルはcgroupにとって一つの大きな変化の節目にも思えますので,ここで今後のcgroupの変化についても簡単に触れておきたいと思います。

memoryサブシステム

今回説明したmemoryサブシステムの機能はユーザメモリの制限でした。一方でカーネルが内部的に使用するカーネルメモリの制限機能も実装が進んでいます。現時点でもカーネルメモリの制限を行う機能は実装されておりmemory.kmem.で始まるファイルがカーネルメモリを制限するためのファイルです。

しかし,このカーネルメモリの制限機能は現在かなり激しく機能の追加や変更がされており,実用に必要な重要な機能の実装が済んでいないことから,3.16カーネルでは一旦「開発目的以外では使うべきではない」機能であるとされるようです。

また,システム全体でメモリ不足に陥った時でも,cgroupに対して最低限確保するメモリ量を保証するLow-limit機能の提案がされており,実装が進んでいます。

このようにまだまだ激しく変化している発展途上のサブシステムであり,しばらくは目が離せません。

cgroupの再設計と変更

これまで説明したようにcgroupの開発が進み多数のサブシステムが実装され,さまざまなリソースの制限ができるように実装が進んできました。しかし,一定の機能が実装された所でいろいろな問題点が指摘されるようになってきました。

今後cgroupで一番大きく変わるのが前回cgroupの特徴としてあげた 複数階層構造のサポート がなくなり,単一階層構造 になることでしょう。

複数階層構造のサポートは一見柔軟性を持っているようにみえます。しかし現在のcgroupの仕様を考えるとあまり役に立つことがないようです。

たとえば,複数の階層構造(=cgroupfs)を持てるといってもサブシステムは同時にはひとつの階層構造にしか所属できません。さらに,一度どこかの階層に所属してしまうと移動はできません。

freezerのようなグループのタスクに対して同時に何かを行うサブシステムを考えた場合,複数のcgroupfsがあると,ひとつのcgroupfsにしか所属できないため,他のcgroupfsのcgroupに対して処理が行えなくなります。

このような場合,まとめて処理を行いたいサブシステムを同じマウントポイントに同時にマウントすれば解決できます。しかし,cgroupはディレクトリによって表されますし,あるプロセスは同じcgroupfsの中では同時にはひとつのグループにしか所属できません。つまり複数のサブシステムを同じcgroupfsにマウントしてしまうと,cgroupfsの中の構造は全く同じになってしまいますし,あるプロセスは同じcgroupに属さなければなりません。異なるサブシステムで特定のプロセスに対して違う扱いをしたいと思ってもできません。

このように,複数階層構造をサポートするために内部の実装が複雑になるわりには自由度は低く,柔軟にcgroupを構成できなくなっています。

cgroupの実際のユースケースでは,複数階層構造で複雑な制御が必要なケースはあまりないため,ある程度の柔軟な設定が可能で,サブシステム間の動きの一貫性が取れるように,単一階層構造へ変更することになったようです。

これに伴い,プロセスのcgroupへの登録方法や登録の際の制約が大きく変わります。どのように変わるかは,変更が実装された時点のカーネルの付属文書に記載されますので,そちらをご覧ください。

ただし,あるバージョンのカーネルからいきなり単一階層構造にがらっと変わることはありません。後方互換性を保ちながら変更が可能なように実装されていきます。

この他にもcgroupに現在実装されているeventfdによる通知の仕組みも変わる予定のようです。また,既にリリースされている3.15カーネルではcgroupfsの内部構造が変更されています。

cgroupの管理

ここまで説明したように,cgroupはcgroupfsというディレクトリ構造の中のファイルでいろいろな制御パラメータを簡単に設定できます。これは逆にいうとカーネルの内部の重要なパラメータをアクセス権さえあれば自由に変えたり見たりできるということで,問題がある言われています。

ただ,これだけcgroupの実装が進んで,現在のcgroupの仕様での利用が広がっているので,cgroupfsという仕組みを変えるわけにはいきません。

そこで,将来的にはcgroupを管理するエージェントが単一階層構造になったcgroup全体を管理し,cgroupを使ってリソース制御を行いたい場合は,そのエージェントに依頼するといった流れになるようです。

このエージェントへの名乗りをあげているのが,最近いろいろなディストリビューションで採用が進んでいるsystemdです。initとしてsystemdを採用していないUbuntuでも14.04 LTSからはcgmanagerというソフトウェアが存在しており,LXCもcgmanager経由でcgroupを操作するようになっています。

まとめ

第3回から3回にわけてcgroupの説明を行いました。例で説明したようにcgroupfsを直接触ってcgroupの設定を行うことはあまりないと思いますが,どのような値を設定してどのような制限がされるのかを理解しておくのは,実際にcgroupを使用してリソース制限を行う場合には重要なことだと思います。それぞれのサブシステムが持っている機能の一部しか説明できませんでしたが,これをきっかけにcgroupの理解を深めていってください。

さて,LXCの連載なのになかなかLXCの解説に入れませんが,次回もまだカーネルの機能の説明が続きます。次回はLXCで使う事の多いネットワーク関連の機能を説明したいと思います。

LXC-JPグループ

LXCに限らず,日本語でコンテナの話題を扱う場としてLXC-JPを紹介しておきます。最近ではコンテナの話題を扱ったコンテンツも多くなりましたが,そういうところでは解決できない問題や疑問を解決するのに使えるかもしれません。

名前はLXC-JPという名前ですが,LXCに限らずコンテナの話題なら何でもOKです。ご覧いただくと分かるのですが,実はそれほど活発に議論がされているわけでもありません(^_^;)。ここに相談したからと言って疑問や問題が解決するとは限りませんが,コンテナの話を扱う場の一つとして参加してみてはいかがでしょうか。もちろん筆者も参加しています。

著者プロフィール

加藤泰文(かとうやすふみ)

2009年頃にLinuxカーネルのcgroup機能に興味を持って以来,Linuxのコンテナ関連の最新情報を追っかけたり,コンテナの勉強会を開いたりして勉強しています。英語力のない自分用にLXCのmanページを日本語訳していたところ,あっさり本家にマージされてしまい,それ以来日本語訳のパッチを送り続けています。

Plamo Linuxメンテナ。ファーストサーバ株式会社所属。

Twitter:@ten_forward
技術系のブログ:http://tenforward.hatenablog.com/

コメント

コメントの記入