LXC入門 - Osc2011 nagoya

13,458 views

Published on

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

Published in: Technology, Travel, Business
0 Comments
35 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
13,458
On SlideShare
0
From Embeds
0
Number of Embeds
55
Actions
Shares
0
Downloads
0
Comments
0
Likes
35
Embeds 0
No embeds

No notes for slide

LXC入門 - Osc2011 nagoya

  1. 1. Linuxの標準機能「LXC」を用いた 仮想化 - 入門編 - 株式会社Joesウェブホスティング 山本 政秀
  2. 2. 株式会社Joesウェブホスティング 概要 ● 設立 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名 ● 事業内容 – クラウド/ウェブホスティング事業 – 情報セキュリティ事業 – 経営支援事業 22
  3. 3. 事業内容紹介 ● ウェブホスティング事業 – フルマネージド専用サーバ、root権限付き専用サーバ、 VPS、共用サーバ – ハウジングサービス、HAクラスタサービス、ドメイン取得 – コントロールパネル (cPanel/Plesk) – cPanelを日本で最初に提供を開始した会社 cPanelと 言えばJoes 33
  4. 4. 事業内容紹介 ● 情報セキュリティ事業 – SSL証明書は主要ブランドを網羅、国内最安値で提供 – ベリサイン、ジオトラスト、グローバルサイン、サイバートラス ト、アルファSSL、セコム、コモド – 独自の仕入れルート ベリサインなら39,900円~(他社は倍 以上がほとんど) – 創業から、証明書の発行・設置業務を行っている。 44
  5. 5. 事業内容紹介 ● 経営支援事業 – Joesビジネスセンター – バーチャルオフィス – 東京は銀座・青山、大阪は梅田の一等地を登記住所として利 用可能 – 東京駅、大阪駅から徒歩10分以内の距離 – 会議室貸出し、電話転送、郵便物転送、東京/大阪間テレビ 会議 55
  6. 6. 講師自己紹介 ● 山本 政秀(やまもと まさひで) ● 出身地: 兵庫県姫路市 ● 生年月日: 昭和51年12月9日 34歳 ● 2003年5月 入社 ● 2007年1月 Joesウェブホスティング取締役CTO ● 弊社LXC-VPSの開発を担当 ● 写真は米出張の際cPanelという 会社のCEOと 66
  7. 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 77
  8. 8. 本日のアジェンダ ● LXCのご紹介 – LXCの概要 – 仮想化のおさらい – LXCの詳細 ● デモ – コンテナの設定 – LXCのセキュリティ – LXCのパフォーマンス – HAクラスタ化 88
  9. 9. LXCの概要 ● LinuXContainer ● OSレベルの仮想化 ● Namespace+cgroup+ユーザランド ● IBM Daniel Lezcano氏(仏)、他数名でプロ ジェクトを創始(2008年8月頃) ● 弊社も開発に参加している 99
  10. 10. 仮想化 - 主な方式 完全仮想 ハードウェアをエミュレート Bochs, オーバーヘッドが大 QEMU, (CPU 支援で、若干改善) KVM 任意のOS が利用可 準仮想 ゲストOS がホストOS の Xen, API を利用 ESX/ESXi, (ハイパーコール) Hyper-V オーバーヘッドは中 OS仮想化(コンテナ) 異なる仮想サーバーを、プ OpenVZ, ロセスの権限で制御 Virtuozzo, (OS 仮想化) オーバーヘッドが小 LXC カーネルは固定、OS は 10 選べない10
  11. 11. LXCの詳細 ● LXC=Namespace+cgroup+ユーザランド ツール ● Namespace(名前空間) – 対象となる名前、識別子の集合を他と分離する事を 可能とする概念 – 別の名前空間には干渉できない ● cgroup(ControlGroup) – Namespaceと協調して機能し、グループ化された対 象に対してリソース制御をする為のもの 1111 – メモリ、CPU負荷、ブロックI/Oの量を管理/制限
  12. 12. LXCの詳細 - Namespace ● 別の名前空間 名前空間1 名前空間2 名前空間2 には干渉できない プロ プロ プロ プロ プロ プロ ... セス セス セス セス セス セス 名前空間1 ホストOS/カーネル マウント状態 コンテナ2 マウント状態 IPアドレス ホスト名 IPアドレス ホスト名 プロセス プロセス プロセス 名前空間2 プロセス プロセス プロセス コンテナ1 1212
  13. 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. 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 1414
  15. 15. LXCの詳細 - ユーザランド ● ユーザランドツール – lxc-create:コンテナの作成 – lxc-destroy:コンテナの削除 – lxc-start:コンテナの開始 – lxc-stop:コンテナの停止 – lxc-ps:コンテナ内のプロセスの表示(ps)  ... etc ※ デモで実演 1515
  16. 16. LXCの詳細 - 利点 ● Linux Kernelの標準 ● 最新ディストリに採用 – RHEL6 – Ubuntu OpenVZ⇒LXC ● 高い性能 1616
  17. 17. LXCの詳細 - Linuxの標準 ● Kernelは頻繁に再設計される – OpenVZは非標準 ⇒追いつけない ⇒古いKernelを引きずる ⇒性能改善の恩恵を逃す – KVM/LXCは標準 ⇒自動追従 1717
  18. 18. デモ ● コンテナの設定 ● LXCのセキュリティ ● LXCのパフォーマンス ● HAクラスタ化 ※ ここからは、デモを交えながらLXCの商品化には何が必要で どう解決したのか、どの様に活用できるのか、私の経験をお話しします。 1818
  19. 19. デモ - コンテナの設定 ● ここでお見せしたい事 → OSSを活用した   手軽なシンプロビジョニング → 他OSSとの組み合わせ例 – OpenQRM – COW-FS: ZFS, Btrfs等     ※デモで使用するOpenQRM, ZFSは一部弊社で改良したものとなります。 1919
  20. 20. デモ - コンテナの設定 ● OpenQRM(http://www.openqrm.com/) – データセンタマネジメントプラットフォーム – カスタマイズが容易 – リソース(VMやコンテナ)+イメージ -> アプライアンス(ホストノード) ● ZFS(http://zfsonlinux.org/) – Solaris 10/OpenSolarisのCOW(Copy On Write) ファイルシステムのLinux版 – 手軽なシン・プロビジョニング(仮想ブロックデバイスによ 2020 る設定済みファイルシステムの無コピー複製)
  21. 21. デモ - コンテナの設定LXC-コンテナの新規生成 2121
  22. 22. デモ - コンテナの設定生成完了後の画面 2222
  23. 23. デモ - コンテナの設定生成直後の設定内容 2323
  24. 24. デモ - コンテナの設定 生成直後のプロセス 2424
  25. 25. デモ - コンテナの設定コンテナに割り当てる「イメージ」の作成 Clone元ZFSボリューム名 (後述) ボリュームの ファイルシステムタイプ 2525
  26. 26. デモ - コンテナの設定イメージ作成完了画面 2626
  27. 27. デモ - コンテナの設定 「アプライアンス」作成(リソース選択)画面 生成したコンテナは「idleリソース」としてアプライアンスの対象リソースに選択できる様になる (「アプライアンス」はOpenQRMにおける管理ホストノードの単位) 2727
  28. 28. デモ - コンテナの設定 「アプライアンス」作成(イメージ選択)画面 作成したイメージはアプライアンスのベースイメージとして選択できる 2828
  29. 29. デモ - コンテナの設定 「アプライアンス」作成(詳細設定)画面 2929
  30. 30. デモ - コンテナの設定アプライアンス作成完了画面 ここで「start」をクリックすると、 事前に作成/設定済みのベース ボリューム(ec-base)が実際の データコピー無し(COW)で複製 され、コンテナがその複製された ファイルシステム下で起動する (詳細は後述) 3030
  31. 31. デモ - コンテナの設定アプライアンス開始直後の設定内容「idle」から「root」へ 切り替わっている 3131
  32. 32. デモ - コンテナの設定アプライアンス開始直後のプロセス 3232
  33. 33. デモ - コンテナの設定 コンテナの稼働状況の確認 3333
  34. 34. デモ - コンテナの設定シン・プロビジョニングの「からくり」 ● ZFSによるブロックデバ イス(HDD)の仮想化 ● 事前に設定済みのベー スボリューム(ec-base) ● ZFSによるCOW 実際にはまだ150Mしか クローン ディスクを使っていない コンテナからは20Gのext4 ファイルシステムに見える 3434
  35. 35. LXCのセキュリティ ● 解決されている課題 – 柔軟なリソース制御 - cgroup – コンテナ間、コンテナ/ホスト間の干渉排除-NameSpace – /dev/以下のデバイスへのアクセス制御 – cgroup – init 0/6時のコンテナの安全な halt と reboot    3535
  36. 36. LXCのセキュリティ ● LXC界隈で知られている主要な懸念事項 – /proc/sysrq-triggerでのホスト強制reboot – /proc、/sys経由でのシステムワイド設定の更新 – ほとんど不要なmount、umount、mknod、insmod – システムコールによるsysctl設定の更新 – syslog出力がホストや他コンテナと干渉 – /proc/kcoreやptrace+/proc/[pid]/mem参照による漏洩 ※ これらに対応しなければ商用利用できない 3636 ※ 弊社は対応済みでメインストリーム化を目指している
  37. 37. デモ - LXCのセキュリティ ● ここでお見せしたい事 → 如何にLXCを(実用的に)   セキュアにするか    3737
  38. 38. デモ - LXCのセキュリティ ● /dev/以下のデバイスへのアクセス制御 – cgroup   3838
  39. 39. デモ - LXCのセキュリティ ● Init 0/6 時のコンテナの安全な halt (rebootも同様)   ホスト側からping ホストは落ちない 3939
  40. 40. デモ - LXCのセキュリティ ● コンテナ毎にiptablesが可能(network namespace)   4040
  41. 41. デモ - LXCのセキュリティ● LXCホストカーネル 用パッチによる防御 – コンテナに不要な危険 操作(下記)をカーネル レベルで禁止 mount, umount, mknod, dmesg 等   4141
  42. 42. デモ - LXCのセキュリティ ● /proc/sysrq-triggerでのホスト強制reboot問題   通常のカーネル: r/w remountができる これでホストもreboot パッチ適用カーネル:mountを禁止しているため r/w remountができず、 エラーで書き込めない ※なお、sysrqそのものもKernel内で無効化している 4242
  43. 43. デモ - LXCのセキュリティ ● /proc、/sys経由でのシステムワイド設定の更新問題   通常のカーネル: rw remountができるの でホスト強制reboot 問題同様危険 パッチ適用カーネル: mountを禁止しているため r/w remountができず、 エラーで書き込めない 4343
  44. 44. デモ - LXCのセキュリティ パッチ適用カーネル:システムコール経由でもsysctl設定の更新を禁止 システムコールによる sysctl設定の更新問題 4444 sysctl システムコール時のホスト側 dmesg log
  45. 45. デモ - LXCのセキュリティ ● syslog出力がホストや他コンテナと干渉する問題   通常のカーネル: syslog出力が ホストと混ざっている dmesgが見れてしまう。 パッチ適用カーネル: syslog出力には コンテナの分しか出ない dmesgが見れない。 4545
  46. 46. デモ - LXCのセキュリティ/proc/kcoreやptrace +/proc/[pid]/mem参照による漏洩問題   通常のカーネル: /proc/kcore(カーネル メモリ)が見れてしまう 他プロセスのメモリが 見れてしまう。 パッチ適用カーネル: /proc/kcore、他プロセスの メモリ内容が見れない。 ※他プロセスメモリについて はコンテナ毎に許可可能 4646
  47. 47. LXCのパフォーマンス ● 同じコンテナ型であるOpenVZとの比較 – 基本は同じ – VirtuozzoはOpenVZがベース – LXCの方が20%以上性能が高い(弊社調べ) UnixBench結果: LXC:5101.8           OpenVZ:4028.1 ※ ※ 7月6日時点の最新のVirtuozzo安定版Kernelで実施 4747
  48. 48. LXCのパフォーマンス ● KVMとの比較 – KVMはLinux標準の優れた完全仮想化方式 – LXCの方が33%以上性能が高い(弊社調べ) UnixBench結果: LXC:5101.8              KVM:3411.2 ※ ※ KVMにおいては、ハードウェアによる支援(Intel-VT、VT-d)の有効 化、ゲストカーネルのKVM最適化(カーネルビルドオプションで最適化を 指定)、virtioを用いてI/O処理において極力オーバヘッドを低減して計測 同ハードウェア(CPU数,メモリ)、同コマンドでの計測 4848
  49. 49. デモ - LXCのパフォーマンス ● ここでお見せしたい事 → LXCの性能   cgroupでのリソース制御 – Kernelビルドの実演 ※ UnixBench結果については末尾の付録を参照してください。   4949
  50. 50. デモ - LXCのパフォーマンス ● デモ内容の概要 – 無制限状態でのKernelビルド – cgroupでCPUを制限した上でのKernelビルド 5050
  51. 51. デモ - LXCのパフォーマンス ● ビルドタイム: defconfigで1分8秒 5151
  52. 52. ● 無制限状態でのKernelビルド - ビルド中のプロセス 5252
  53. 53. ● Cgroupによる CPUの制限 (3CPU)● ビルド タイム: 2分46秒 5353
  54. 54. ● 制限状態でのKernelビルド - ビルド中のプロセス 5454
  55. 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 操作) は未設定 5555
  56. 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 5656
  57. 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. 58. デモ - HAクラスタ化 ● デモ内容の概要 – 手動リロケーション(LXCコンテナの移動) – フェイルオーバ(kexec版) – フェイルオーバ(IPMI power-reset版) – 自動フェイルバック抑止 – フェイルオーバ/フェイルバック後、 PHPセッションが維持されている事を確認 (最初にEC-CUBEで買い物をしておく) 5858
  59. 59. crm_mon 出力 /proc/drbd 出力● 初期状態 初期はlxcbase10がアクティブ側 図中の黄色はアクティブ側を示す 初期はlxcbase10 はプライマリ /proc/drbd 出力 初期はlxcbase11 はセカンダリ lxcbase10の lxcbase11の コンテナプロセス コンテナプロセス 5959
  60. 60. デモ - HAクラスタ化 ● 手動リロケーション 6060
  61. 61. ● 手動リロケーション(リソースの移動中) 6161
  62. 62. ● 手動リロケーション(移動完了後) ここで再度lxcbase10へ 手動リロケーションをする 6262
  63. 63. デモ - HAクラスタ化 ● kexec/IPMIによるフェイルオーバ Kexec版 IPMI power-reset版 6363
  64. 64. ● kexec/IPMIによるフェイルオーバ(実施後) 6464
  65. 65. デモ - HAクラスタ化 ● 旧アクティブ側を復旧 ※ これにより自動フェイルバックが発生 6565
  66. 66. ● 復旧後の自動フェイルバック(実施直後) この後初期と同じ状態になる。 (lxcbase10がアクティブ) 6666
  67. 67. ● 自動フェイルバックの無効化 6767
  68. 68. ● 再度フェイルオーバ、旧アクティブ側復旧を行い、自動フェイルバックが発生 しない事を確認 この後手動リロケーション実施後 と同じ状態になる。(lxcbase11が アクティブ) ※ 最後に買い物カゴを確認 6868
  69. 69. Joesの取り組み ● LXC + cPanel – 軽量VPS – 「使いやすく多機能なcPanelを安く」   for EC-CUBEユーザ 否 for All – HAクラスタの価格破壊 – Joes クラウド (VPSの素)構想 6969
  70. 70. Question? 7070
  71. 71. ご清聴ありがとうございました。 追加のご質問がございましたら、弊社(協賛企業) ブースまでお気軽にお立ち寄りください! 7171
  72. 72. 付録 - UnixBench ● 比較表 7272
  73. 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 RAID173
  74. 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" 7474

×