OSC2011 Nagoyaでの「LXC入門」の発表資料です。

1. Linuxの標準機能「LXC」を用いた
仮想化 - 入門編 -
株式会社Joe'sウェブホスティング
山本 政秀

2. 株式会社Joe'sウェブホスティング 概要
● 設立 2002年7月 資本金 1000万円
● 大阪本社 Joe’s ITサロン 梅田, Joe’sビジネスセンター 梅田
● 〒530-0001 大阪府大阪市北区梅田1丁目11番4-923号 大阪駅前第4ビル9階
● 銀座オフィス Joe’s ITサロン 銀座, Joe’sビジネスセンター 銀座
● 〒104-0061 東京都中央区銀座1-3-3 G1 ビル 7階
● 南青山オフィス Joe’sビジネスセンター 青山
● 〒107-0062 東京都港区南青山2-11-13 南青山ビル4階
● 役員 代表取締役 CEO 鈴木禎子、取締役 CTO 山本政秀
●
取締役 海外部 鈴木拓人、執行役員 緒方俊輔
● 従業員数 17名
●
事業内容
– クラウド/ウェブホスティング事業
– 情報セキュリティ事業
– 経営支援事業 2
2

3. 事業内容紹介
● ウェブホスティング事業
– フルマネージド専用サーバ、root権限付き専用サーバ、
VPS、共用サーバ
– ハウジングサービス、HAクラスタサービス、ドメイン取得
– コントロールパネル (cPanel/Plesk)
– cPanelを日本で最初に提供を開始した会社 cPanelと
言えばJoe's
3
3

4. 事業内容紹介
● 情報セキュリティ事業
– SSL証明書は主要ブランドを網羅、国内最安値で提供
– ベリサイン、ジオトラスト、グローバルサイン、サイバートラス
ト、アルファSSL、セコム、コモド
– 独自の仕入れルート ベリサインなら39,900円～（他社は倍
以上がほとんど）
– 創業から、証明書の発行・設置業務を行っている。
4
4

5. 事業内容紹介
● 経営支援事業
– Joe'sビジネスセンター – バーチャルオフィス
– 東京は銀座・青山、大阪は梅田の一等地を登記住所として利
用可能
– 東京駅、大阪駅から徒歩10分以内の距離
– 会議室貸出し、電話転送、郵便物転送、東京/大阪間テレビ
会議
5
5

6. 講師自己紹介
● 山本 政秀（やまもと まさひで）
● 出身地： 兵庫県姫路市
● 生年月日： 昭和51年12月9日 34歳
● 2003年5月 入社
● 2007年1月 Joe'sウェブホスティング取締役CTO
● 弊社LXC-VPSの開発を担当
● 写真は米出張の際cPanelという
会社のCEOと 6
6

7. Contact us
● URL
– joeswebhosting.net（ウェブホスティング/レンタルサーバ）
– jwh.jp（会社ブログ）、joes-ssl.com（SSL証明書）
– joes-office.com（バーチャルオフィス）
– ec-cube.org（EC-CUBE標準サーバ）
– cpanel-plesk.net（コントロールパネル/VPS）
● Twitter/Facebook
– @JoesWebHosting、@Joes_office
– http://www.facebook.com/JoesWebHosting
– http://www.facebook.com/JoesOffice
7
7

8. 本日のアジェンダ
● LXCのご紹介
– LXCの概要
– 仮想化のおさらい
– LXCの詳細
● デモ
– コンテナの設定
– LXCのセキュリティ
– LXCのパフォーマンス
– HAクラスタ化
8
8

9. LXCの概要
● LinuXContainer
● OSレベルの仮想化
● Namespace+cgroup+ユーザランド
● IBM Daniel Lezcano氏(仏)、他数名でプロ
ジェクトを創始（2008年8月頃）
● 弊社も開発に参加している
9
9

10. 仮想化 - 主な方式
完全仮想 ハードウェアをエミュレート Bochs,
オーバーヘッドが大
QEMU,
(CPU 支援で、若干改善)
KVM
任意のOS が利用可
準仮想 ゲストOS がホストOS の Xen,
API を利用 ESX/ESXi,
(ハイパーコール) Hyper-V
オーバーヘッドは中
OS仮想化（コンテナ） 異なる仮想サーバーを、プ OpenVZ,
ロセスの権限で制御
Virtuozzo,
(OS 仮想化)
オーバーヘッドが小 LXC
カーネルは固定、OS は
10
選べない
10

11. LXCの詳細
● LXC=Namespace+cgroup+ユーザランド
ツール
● Namespace（名前空間）
– 対象となる名前、識別子の集合を他と分離する事を
可能とする概念
– 別の名前空間には干渉できない
● cgroup（ControlGroup）
– Namespaceと協調して機能し、グループ化された対
象に対してリソース制御をする為のもの
11
11 – メモリ、CPU負荷、ブロックI/Oの量を管理/制限

12. LXCの詳細 - Namespace
● 別の名前空間 名前空間1 名前空間2
名前空間2
には干渉できない プロ プロ プロ プロ プロ プロ ...
セス セス セス セス セス セス
名前空間1
ホストOS/カーネル
マウント状態
コンテナ2
マウント状態
IPアドレス ホスト名
IPアドレス ホスト名
プロセス
プロセス プロセス 名前空間2
プロセス
プロセス
プロセス
コンテナ1 12
12

13. LXCの詳細 – Namespace(続き)
● Namespace（名前空間） カーネル内部では
グループを形成
struct uts
プロセス Namespace Proxy ホスト名等 これらは今までは
struct nsproxy ホスト名等 直接task_struct
task_struct
から参照されていた
親 uts_namespace
namespace mnt_namespace struct vfs_mount
pid_namespace マウント状態
新設 task_struct net_namespace マウント状態
新設
struct pid
task_struct struct nsproxy プロセスID
uts_namespace プロセスID
mnt_namespace
pid_namespace ・グローバルPIDと所属名前
・一部簡略化 net_namespace 空間内でしか通用しないPID
・子は親と同じ名前空間 ・/proc（ps等が参照）は名前
13
・同じ名前空間であれば 空間毎に独自PIDでプロセス
13
干渉できる 情報をエクスポート

14. LXCの詳細 - cgroup
● cgroup（ControlGroup）
コア数
同一名前空間
CPU：1コア System Resource 優先度
VPS1 Memory：1G
Disk: 20%,sda/rw 実メモリ
cpu
process Network: 10Mbps cgroup SWAP
process memory I/O時間
パーミッション
process
disk
cgroup 帯域
VPS2
CPU：4コア
process network
Memory：4G
Disk: 50%,sdb/rw
process
Network: 50Mbps 14
14

15. LXCの詳細 - ユーザランド
●
ユーザランドツール
– lxc-create：コンテナの作成
– lxc-destroy：コンテナの削除
– lxc-start：コンテナの開始
– lxc-stop：コンテナの停止
– lxc-ps：コンテナ内のプロセスの表示（ps）
... etc
※ デモで実演
15
15

16. LXCの詳細 - 利点
● Linux Kernelの標準
●
最新ディストリに採用
– RHEL6
– Ubuntu OpenVZ⇒LXC
●
高い性能
16
16

17. LXCの詳細 - Linuxの標準
● Kernelは頻繁に再設計される
– OpenVZは非標準
⇒追いつけない
⇒古いKernelを引きずる
⇒性能改善の恩恵を逃す
– KVM/LXCは標準
⇒自動追従 17
17

18. デモ
●
コンテナの設定
● LXCのセキュリティ
● LXCのパフォーマンス
● HAクラスタ化
※ ここからは、デモを交えながらLXCの商品化には何が必要で
どう解決したのか、どの様に活用できるのか、私の経験をお話しします。
18
18

19. デモ - コンテナの設定
●
ここでお見せしたい事
→ OSSを活用した
手軽なシンプロビジョニング
→ 他OSSとの組み合わせ例
– OpenQRM
– COW-FS： ZFS, Btrfs等
※デモで使用するOpenQRM, ZFSは一部弊社で改良したものとなります。 19
19

20. デモ - コンテナの設定
● OpenQRM（http://www.openqrm.com/）
– データセンタマネジメントプラットフォーム
– カスタマイズが容易
– リソース（VMやコンテナ）＋イメージ
-> アプライアンス（ホストノード）
● ZFS（http://zfsonlinux.org/）
– Solaris 10/OpenSolarisのCOW(Copy On Write)
ファイルシステムのLinux版
– 手軽なシン・プロビジョニング（仮想ブロックデバイスによ
20
20 る設定済みファイルシステムの無コピー複製）

21. デモ - コンテナの設定
LXC-コン
テナの新
規生成
21
21

22. デモ - コンテナの設定
生成完了後の画面
22
22

23. デモ - コンテナの設定
生成直後の
設定内容
23
23

24. デモ - コンテナの設定
生成直後のプロセス
24
24

25. デモ - コンテナの設定
コンテナに割り当てる「イメージ」の作成
Clone元ZFSボリューム名
（後述）
ボリュームの
ファイルシステムタイプ
25
25

26. デモ - コンテナの設定
イメージ作成完了画面
26
26

27. デモ - コンテナの設定
「アプライアンス」作成（リソース選択）画面
生成したコンテナは「idleリソース」としてアプライアンスの対象リソースに選択できる様になる
（「アプライアンス」はOpenQRMにおける管理ホストノードの単位）
27
27

28. デモ - コンテナの設定
「アプライアンス」作成（イメージ選択）画面
作成したイメージはアプライアンスのベースイメージとして選択できる
28
28

29. デモ - コンテナの設定
「アプライアンス」作成（詳細設定）画面
29
29

30. デモ - コンテナの設定
アプライアンス作成完了画面
ここで「start」をクリックすると、
事前に作成/設定済みのベース
ボリューム（ec-base）が実際の
データコピー無し（COW）で複製
され、コンテナがその複製された
ファイルシステム下で起動する
（詳細は後述）
30
30

31. デモ - コンテナの設定
アプライアンス
開始直後の
設定内容
「idle」から「root」へ
切り替わっている
31
31

32. デモ - コンテナの設定
アプライアンス
開始直後の
プロセス
32
32

33. デモ - コンテナの設定
コンテナの稼働状況の確認
33
33

34. デモ - コンテナの設定
シン・プロビジョニングの
「からくり」
● ZFSによるブロックデバ
イス（HDD）の仮想化
●
事前に設定済みのベー
スボリューム（ec-base）
● ZFSによるCOW 実際にはまだ150Mしか
クローン ディスクを使っていない
コンテナからは20Gのext4
ファイルシステムに見える 34
34

35. LXCのセキュリティ
●
解決されている課題
– 柔軟なリソース制御 - cgroup
– コンテナ間、コンテナ/ホスト間の干渉排除-NameSpace
– /dev/以下のデバイスへのアクセス制御 – cgroup
– init 0/6時のコンテナの安全な halt と reboot
35
35

36. LXCのセキュリティ
● LXC界隈で知られている主要な懸念事項
– /proc/sysrq-triggerでのホスト強制reboot
– /proc、/sys経由でのシステムワイド設定の更新
– ほとんど不要なmount、umount、mknod、insmod
– システムコールによるsysctl設定の更新
– syslog出力がホストや他コンテナと干渉
– /proc/kcoreやptrace+/proc/[pid]/mem参照による漏洩
※ これらに対応しなければ商用利用できない
36
36 ※ 弊社は対応済みでメインストリーム化を目指している

37. デモ - LXCのセキュリティ
●
ここでお見せしたい事
→ 如何にLXCを（実用的に）
セキュアにするか
37
37

38. デモ - LXCのセキュリティ
● /dev/以下のデバイスへのアクセス制御 – cgroup
38
38

39. デモ - LXCのセキュリティ
● Init 0/6 時のコンテナの安全な halt （rebootも同様）
ホスト側からping
ホストは落ちない 39
39

40. デモ - LXCのセキュリティ
● コンテナ毎にiptablesが可能（network namespace）
40
40

41. デモ - LXCのセキュリティ
● LXCホストカーネル
用パッチによる防御
– コンテナに不要な危険
操作（下記）をカーネル
レベルで禁止
mount, umount,
mknod, dmesg 等
41
41

42. デモ - LXCのセキュリティ
● /proc/sysrq-triggerでのホスト強制reboot問題
通常のカーネル：
r/w remountができる
これでホストもreboot
パッチ適用カーネル：
mountを禁止しているため
r/w remountができず、
エラーで書き込めない
※なお、sysrqそのものも
Kernel内で無効化している
42
42

43. デモ - LXCのセキュリティ
● /proc、/sys経由でのシステムワイド設定の更新問題
通常のカーネル：
rw remountができるの
でホスト強制reboot
問題同様危険
パッチ適用カーネル：
mountを禁止しているため
r/w remountができず、
エラーで書き込めない
43
43

44. デモ - LXCのセキュリティ
パッチ適用カーネル：
システムコール経由でも
sysctl設定の更新を禁止 システムコールによる
sysctl設定の更新問題
44
44 sysctl システムコール時のホスト側 dmesg log

45. デモ - LXCのセキュリティ
● syslog出力がホストや他コンテナと干渉する問題
通常のカーネル：
syslog出力が
ホストと混ざっている
dmesgが見れてしまう。
パッチ適用カーネル：
syslog出力には
コンテナの分しか出ない
dmesgが見れない。
45
45

46. デモ - LXCのセキュリティ
/proc/kcoreやptrace
+/proc/[pid]/mem参照に
よる漏洩問題
通常のカーネル：
/proc/kcore（カーネル
メモリ）が見れてしまう
他プロセスのメモリが
見れてしまう。
パッチ適用カーネル：
/proc/kcore、他プロセスの
メモリ内容が見れない。
※他プロセスメモリについて
はコンテナ毎に許可可能
46
46

47. LXCのパフォーマンス
● 同じコンテナ型であるOpenVZとの比較
– 基本は同じ
– VirtuozzoはOpenVZがベース
– LXCの方が20%以上性能が高い(弊社調べ)
UnixBench結果： LXC:5101.8
OpenVZ：4028.1 ※
※ 7月6日時点の最新のVirtuozzo安定版Kernelで実施
47
47

48. LXCのパフォーマンス
● KVMとの比較
– KVMはLinux標準の優れた完全仮想化方式
– LXCの方が33%以上性能が高い(弊社調べ)
UnixBench結果： LXC:5101.8
KVM：3411.2 ※
※ KVMにおいては、ハードウェアによる支援（Intel-VT、VT-d）の有効
化、ゲストカーネルのKVM最適化（カーネルビルドオプションで最適化を
指定）、virtioを用いてI/O処理において極力オーバヘッドを低減して計測
同ハードウェア（CPU数,メモリ）、同コマンドでの計測 48
48

49. デモ - LXCのパフォーマンス
●
ここでお見せしたい事
→ LXCの性能
cgroupでのリソース制御
– Kernelビルドの実演
※ UnixBench結果については末尾の付録を参照してください。
49
49

50. デモ - LXCのパフォーマンス
●
デモ内容の概要
– 無制限状態でのKernelビルド
– cgroupでCPUを制限した上でのKernelビルド
50
50

51. デモ - LXCのパフォーマンス
● ビルドタイム: defconfigで1分8秒
51
51

52. ● 無制限状態でのKernelビルド - ビルド中のプロセス
52
52

53. ● Cgroupによる
CPUの制限
（3CPU）
●
ビルド
タイム:
2分46秒
53
53

54. ● 制限状態でのKernelビルド - ビルド中のプロセス
54
54

55. HAクラスタ化
●
デモ環境の構成 ・同一ハードウェアスペック
初期アクティブノード スタンバイノード CPU： 6 cores 12 threads
lxcbase10 障害時 lxcbase11 Memory： DDR3 24GB
フェイルオーバ 障害時に起動 HDD： 2T x 2
Network: eth0（100Mbps）
LXCコンテナ LXCコンテナ eth1（1Gbps）
・クラスタインターコネクトと
監視 DRBDリンクは共にeth1
相互監視
Pacemker Pacemker ・STONITH（Shoot The Other
eth1
監視 監視 Node In The Head）（ピア側の
障害検出時IPMI（後述）等を経
DRBD リアルタイム同期 DRBD 由して強制シャットダウンさせる
eth1 操作） は未設定
55
55

56. HAクラスタ化
●
デモ環境の構成（続き） ・STONITHの役割： 両方が
Standaloneだと思い込むSplit
初期アクティブノード スタンバイノード Brainと呼ばれる状態で、データ
lxcbase10 障害時 lxcbase11 の破損等が起らない様にするた
フェイルオーバ 障害時に起動 めのもの。
LXCコンテナ LXCコンテナ ・DRBDの構成（2台共同一）
DRBD /dev/drbd0
監視 MD
相互監視
Pacemker Pacemker (RAID0) /dev/md2(50+50=100G)
eth1
監視 監視 LV drbd-bk1 drbd-bk1
LVM
DRBD リアルタイム同期 DRBD VG /dev/vg1 /dev/vg2
eth1 物理HDD /dev/sda2
/dev/sda /dev/sdb2 56
56

57. デモ - HAクラスタ化
●
ここでお見せしたい事
→ LXCでのHAクラスタ例
手軽に軽い高可用性クラスタを実現
– Linux-HA Japan(http://linux-ha.sourceforge.jp/wp/)
– Pacemaker（http://www.clusterlabs.org/）
– DRBD（http://www.drbd.org/）
※デモで使用するPacemaker LXC-RA(Resource Agent)は 57
弊社で開発したものとなります。
57

58. デモ - HAクラスタ化
●
デモ内容の概要
– 手動リロケーション（LXCコンテナの移動）
– フェイルオーバ（kexec版）
– フェイルオーバ（IPMI power-reset版）
– 自動フェイルバック抑止
– フェイルオーバ/フェイルバック後、
PHPセッションが維持されている事を確認
（最初にEC-CUBEで買い物をしておく）
58
58

59. crm_mon 出力 /proc/drbd 出力
●
初期状態 初期はlxcbase10がアクティブ側
図中の黄色はアクティブ側を示す
初期はlxcbase10
はプライマリ
/proc/drbd 出力
初期はlxcbase11
はセカンダリ
lxcbase10の lxcbase11の
コンテナプロセス コンテナプロセス 59
59

60. デモ - HAクラスタ化
●
手動リロケーション
60
60

61. ●
手動リロケーション（リソースの移動中）
61
61

62. ●
手動リロケーション（移動完了後）
ここで再度lxcbase10へ
手動リロケーションをする
62
62

63. デモ - HAクラスタ化
● kexec/IPMIによるフェイルオーバ
Kexec版
IPMI power-reset版
63
63

64. ● kexec/IPMIによるフェイルオーバ（実施後）
64
64

65. デモ - HAクラスタ化
●
旧アクティブ側を復旧
※ これにより自動フェイルバックが発生
65
65

66. ●
復旧後の自動フェイルバック（実施直後）
この後初期と同じ状態になる。
（lxcbase10がアクティブ）
66
66

67. ●
自動フェイルバックの無効化
67
67

68. ●
再度フェイルオーバ、旧アクティブ側復旧を行い、自動フェイルバックが発生
しない事を確認
この後手動リロケーション実施後
と同じ状態になる。（lxcbase11が
アクティブ）
※ 最後に買い物カゴを確認
68
68

69. Joe'sの取り組み
● LXC + cPanel
– 軽量VPS
– 「使いやすく多機能なcPanelを安く」
for EC-CUBEユーザ 否 for All
– HAクラスタの価格破壊
– Joe's クラウド (VPSの素)構想
69
69

70. Question?
70
70

71. ご清聴ありがとうございました。
追加のご質問がございましたら、弊社（協賛企業）
ブースまでお気軽にお立ち寄りください！ 71
71

72. 付録 - UnixBench
● 比較表
72
72

73. 付録 - UnixBench
●
実施条件
※ 上記はUnix Bench 5.1.3 において ./Run を引数無しで実行した結果である。
※ VirtuozzoはPararrelsが提供している2011/7/6 時点で利用可能な最新のカーネルを用いた。
※ LXC, Virtuozzo共にCPU、メモリ、I/Oにおいてnolimitにて試行
※ KVMはKVMゲスト最適化を有効とし、Block Deviceはvirtioを用いて極力オーバヘッドの低減に努め
た。(ゲストからは/dev/vdaとして見える)
KVM(qemu)起動コマンドは以下の通り。
# qemu-system-x86_64 -drive file=/mnt/kvm/kvm1/kvmimage,if=virtio,boot=on -m 2048 -vnc :1
-net nic,model=virtio,vlan=1,macaddr=00:00:00:00:00:01
-net tap,vlan=1,ifname=tap1,script=/etc/qemu-ifup -enable-kvm -daemonize -cpu host
-smp 8 -clock hpet
※ KVMイメージファイルとLXC-VEの設置先ファイルシステムはどちらもext4とし同じ条件とした。
※ 全てのテストは全く同じハードウェア構成のマシン上で実施した。ハードウェア構成は以下の通り。
Machine: x86_64 (x86_64) 4コア8スレッド
CPU * 8: Intel(R) Xeon(R) CPU X3440 @ 2.53GHz (5066.9 bogomips)
Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT,
SYSCALL/SYSRET, Intel virtualization
メモリ 8GB DDR3
73
HDD 2T(7200RPM) * 2 RAID1
73

74. 付録 - Pacemakerの設定内容
[root@lxcbase10 ~]# crm configure show
node lxcbase10.joeswebhosting.net attributes standby="off"
node lxcbase11.joeswebhosting.net attributes standby="off"
primitive drbd_demo ocf:linbit:drbd params drbd_resource="r0"
op monitor interval="10s" role="Master" timeout="60s"
op monitor interval="11s" role="Slave" timeout="60s"
primitive fs_demo ocf:heartbeat:Filesystem params device="/dev/drbd0"
directory="/var/lib/lxc/demo/root" fstype="ext4"
options="defaults,noatime,nobh,user_xattr" op monitor interval="17s" timeout="30s"
primitive ip_demo ocf:heartbeat:IPaddr2 params ip="192.168.100.200" cidr_netmask="24" nic="br1:10"
op monitor interval="7s" meta target-role="Started"
primitive lxc_demo ocf:heartbeat:LXC params vmname="demo" op monitor interval="17s" timeout="100s"
op start interval="0" timeout="100s" op stop interval="0" timeout="100s"
ms ms_drbd_demo drbd_demo meta master-max="1" master-node-max="1" clone-max="2"
clone-node-max="1" notify="true"
colocation drbd_with_ip inf: ip_demo ms_drbd_demo:Master
colocation fs_with_drbd inf: ms_drbd_demo:Master fs_demo
colocation lxc_with_fs inf: fs_demo lxc_demo
order fs_after_drbd inf: ms_drbd_demo:promote fs_demo:start
order lxc_After_fs inf: fs_demo lxc_demo
property $id="cib-bootstrap-options" dc-version="1.1.5-e872eeb39a5f" cluster-infrastructure="openais"
expected-quorum-votes="2" no-quorum-policy="ignore" stonith-enabled="false"
last-lrm-refresh="1313415864"
rsc_defaults $id="rsc-options" resource-stickiness="100"
74
74