本を読む

読書やコンピュータなどに関するメモ

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

第2回コンテナ型仮想化の情報交換会に行ってきた

 第2回コンテナ型仮想化の情報交換会に行ってきました。第1回が1ケタ人、今回が3ケタ人の参加ということで、すごい注目度ですね。会場では、「ちょっと前まで、サービスでVirtuozzoを使っているとdisられてたんだけど」という戸惑いの声も。

 以下、ほぼメモそのまま。

Linuxコンテナ入門(加藤泰文)

  • (emasaka遅刻により途中から)
  • 今後
  • いまのcgroupはまともじゃない、という議論
    • 標準のAPIではない
    • カーネルにクリティカルなことができてしまう
    • サブシステムごとに微妙に違う
    • 複数マウントすると微妙な動作に
  • 再設計しよう
  • 単一階層構造
  • 今後これが標準に
  • XFS対応
  • device namespace
    • /devを分ける
    • androidでのコンテナの実装
  • syslog namaspace
  • freeで親環境のリソースが表示されるのを対応
  • lxc開発
  • 元はIBMフランスの人
  • 今はUbuntuの人2人に
  • lxc 1.0
  • よせあつめから、APIを整理
  • overlay
  • zfs対応
  • android
  • 日本語マニュアル
  • lxc-jp ML
  • ドキュメント翻訳
  • チェックする人募集
  • Q: zfsではスナップショットは?
  • A: 実装されていると思うが、確認する

OpenVZ(パラレルス @ebiken)

  • コンテナ仮想化の実現方法
  • OpenVZ
  • リソース空間の分離とリソースの管理
  • namespaceとcgroup
  • Linuxカーネルの機能を使って実装
  • そのほか
  • vzctlに入っているコンテナ操作のためのコマンド群
  • ploop
    • 2年ぐらい前に出た
    • それまではchrootでファイルシステム
      • inode数、quota、マイグレーションはファイルコピーで大変
    • ループバックマウントのように1ファイルの中にファイルシステム
    • write trackerでスナップショット
  • CRIU
    • checkpoint/restore in userspace
    • メモリやプロセスのスナップショット
    • ライブマイグレーション
    • OpenVZ以外でも使える
  • 作っているのは
  • Parallels + Contributer
  • Virtuozzo = OpenVZ + ツール + サポート
  • 仮想化を作る部分はコモディティ化されてお金はとれない
  • メインラインにマージしていいんじゃないか
  • James Bottomleyをひきいれる
  • メインラインにコミット
  • Parallelsはロシアの会社
  • 8割がロシア人
  • vzctlがメインラインカーネルで動くように
  • OpenVZカーネルでなくてもコンテナが作れる
  • VirtuozzoだけでなくOpenVZの有償サポートも開始
  • Parallels Cloud Server
  • コンテナ+ハイパーバイザ
  • OpenVZをさわってみる
  • インストール
  • リポジトリを追加
  • # yum install vzkernel
  • # yum install vzctrl vzquota plooop
  • # reboot
  • コンテナの作成
  • テンプレートをダウンロード
  • vzctl create CID --ostemplate TEMPLATE
  • vzctl set ID --ipaddr IPADDRESS
  • vzctl enter CID
  • vzctrl stop CID
  • vzctrl start CID
  • vzctrl exec CID COMMAND …
  • namespace・cgroup
  • /vz/root/
  • PIDはコンテナごとに別に
  • コンテナごとにネットワークのloopbakを持つ
  • プロセスのnamespace
    • グルーピングしただけだと、ほかのノードにマイグレーションしたときにぶつかる可能性があるため
  • /proc/vz/contnainer
  • ネットワークタイプ
  • LXCとだいぶ違う
  • veth(L2)とvenet(L3)の2種類
  • venet:vzctrlで設定
  • veth:ホスト側でブリッジを作る
  • 性能
  • veth:15%おちる
  • venet:3割近くおちる
  • OpenVZ Wikiにいろいろなパターンでのベンチマーク結果がある
  • OpenVZの中の人は、「テスト結果は場合しだいだ」と注意

OpenStack環境で、FreeBSD Jail + VIMAGEを使った疑似インターネット実験環境の構築(IIJ 山本茂)

  • FreeBSD Jail
  • chrootの発展形
  • プロセスを分離
  • jail外からはすべてのプロセスが見える
  • VIMAGE
  • jailごとに異なるネットワークスタックを作れる
  • 9.0 Releaseから対応
  • カーネルリビルド必要
  • 対応していないドライバ等をまぜるとすぐカーネルパニック
  • ホストからはコンテナのNICは見えない
  • 使ってみる
  • 必要なもの
  • FreeBSD Release
  • jail、jls、jexec
  • ネットワーク:espair、if_bridge
  • ifconfigのNameオプション
  • tmpfs
  • nullfs
  • VIMAGEつきのFreeBSD環境を作る
    • option VIMAGEを追加してカーネルを再構築
  • jail用のファイルシステムを作る
    • cp -rなどでコピー
    • zfsでクローニング
    • nullfsを使って必要なディレクトリをmount
  • vnetオプションつきでjailを作成
    • vnet、persist
  • jailにインタフェースを作成
    • 仮想インタフェースepair
      • ethernetケーブルのイメージ
    • ホスト側とjail側
    • bridgeインタフェース
      • ハブのイメージ
  • jailのネットワーク設定
    • jexec:jailでコマンドを実行
  • FreeBSDコア開発者の佐藤さんの資料がよい
  • NICTの委託研究
  • NTTの局舎にコンピュータリソースを置いてサービスする想定
  • かなりの数のノードを実験する必要
  • ハイパーバイザ等ではリソースがいっぱい必要
    • StarBet?
  • jailとVIMAGEで
  • IIJのコンテナデータセンターのKVM上のFreeBSDで
    • コンテナ in コンテナ
  • コアルータ + 局舎ルータ + … でjailが243個
  • OpenStackを使う場合
  • ディスクイメージはできるだけ小さい方がいい
    • VMを起動するときにディスクイメージがコピーされる
    • 必要なものはあとからpkgで入れるように設定を作る
  • 使う必要がないメモリは使わない
    • 親環境は最小限に
    • 経路制御もできればstaticで
    • ZFSでなくUFS
      • jailの変更しない部分はnullfsでmount
      • unionfsを使う方法っも
  • 各VMのIDを伝えるには
    • ホスト名に入れてしまう
    • 本当はOpenStackのAPIを使うのがいいのだろうが、FreeBSDを改良する必要がある
  • ほしいもの
  • ブラウザでネットワーク図を描くとjailの設定を作ってくれるもの
  • OpenStack対応
    • LXCは対応
  • arm64 linux emurator対応
    • jailでCentOS 64bit環境を動かす
  • Q: 大規模jailで、カーネルのパラメータのチューニングは必要なかったか
  • A: 今回はそこが目的ではなかったので、必要なメモリを与えるなどした
  • Q: 243 jailでどのぐらいのメモリ
  • A: マシンに2Gとか4Gとかそのぐらい
  • Q: ZFSの問題。jail側で問題?
  • A: ホスト側
  • Q: nullfsでメモリは減る? 1つのOS上でハードリンクされたものを実行した場合はコードのメモリは1つ
  • A: 調べていないのでよくわからないが、chrootで見えなくなるので
  • Q: Linuxにはbind mountがある。BSDは?
  • A: 外は見えない? 要確認

Squaleでcgroupsにfork bomb対策を入れた話(ペパボ MIZZY)

  • serverspecで最近名前が知られているかも
  • LL界隈で活動
  • ペパボ テクニカルマネージャー
  • Squale
  • PaaS
    • HerokuやdotCloudのような
  • LXC
    • 集積度
    • AWS上での仮想化
    • HerokuやdotCloudが使っているので
  • 5/18クローズドベータリリース
  • いきなりfork bomb攻撃をくらう
  • どう対策?
  • ulimit?
    • ユーザーが区別できないので使えない
  • cgroups?
  • folkを制御するサブシステムがない
  • cgroup controller forkパッチというのはあった
  • 採用してみた
  • fork.remainingを設定してforkできる回数をグループごとに制限
  • maxに達するとforkできないと困る
  • やりたいのは、同時プロセスの制限
  • 同時のプロセスを制限するように改造
  • 改造したものをGitHubでパブリック公開
  • 実装
  • cgroup_fork.[ch]は新規で追加
  • それ以外は既存のコードへのパッチ
  • fork.cへのパッチ
  • プロセスをforkするときにcgroup_fork_pre_fork()を呼んでforkしてOKかどうかチェック
  • cgroup.et_remaining()でfork.remainingの値を変更しつつ取得
  • struct cgroup_subsysの.forkで、forkするときの関数cgroup_fork_fork()
  • 改造
  • remainingを--している箇所をコメントアウト
  • チェックのほうでは、task_count()とremainingを比較
  • ほか
  • CGROUP_CONFIG_FORK

PaaSの作り方 Squaleの場合(ペパボ @hiboma)

  • パパボ 技術基盤チーム
  • PaaS
  • ここでは「herokuっぽいの」といった意味で
  • Squaleアイコン
    • GitHubのアイコンの作者に依頼した
  • Ruby、PHP、MySSQL、独自ドメインSSL
  • gitでアップロード
  • 管理画面
  • 裏側でLXCのコンテナがセットアップされる
  • AWSを全面利用
  • EC2
  • EBS
    • pushしたコードなど
  • Route53
    • ドメイン管理
  • ERB
    • リバースプロキシの前段
    • SSL
  • RDS
    • 共用MySQLサーバー
  • EC2 Amazon Linux
  • CentOS 6にだいたい相当
  • Ubuntuにしないの?
    • 社内でRH系メインなので
    • いろいろ大変でした
  • パッチ
    • grsequrity path
    • restrict bind patch
    • fork bomb対策パッチ
  • Rubyコンテナ
  • NginxとRackアプリを動かせる
  • Ruby 1.9.3系、2.0系
  • supervisordでプロセスをあげる
  • sshやcronも使用可
  • git pushすると、bundle installやassetsprecommpileなどを実行
  • Nginxはport 8000 + nでlisten
  • sshdはport 2000 + nでlisten
  • network namespaceは使用していない
    • 管理が煩雑になるため
    • TCP portのbindを制限するパッチ
  • PHPコンテナ
  • APache 2.4 + php-fpm
  • PHP 5.3/5.4
  • rootfs
  • コンテナ用のファイルツリーをそう呼んでいる
  • yum --installroot
  • rubyやchef-soloも入れる
  • chrootとしてchef-soloで構築
  • 環境構築にlxcのテンプレートは使っていない
    • 作り方の参考にはした
  • mount --bindでroでマウント
  • その中にさらにユーザーが読み書きできるファイルシステムをmount --bind
  • rootfsの共有
  • 長所:管理の一元化、ディスクスペースの節約
  • 短所:個別のカスタマイズが難しい
    • aufsを使えば解決できる?
    • ユーザーにサーバーサイドを意識させないつくりなので、許容
  • コンテナ作成
  • lxcの設定ファイルやディレクトリを作成
  • Resque(ジョブキュー)がchef-soloを流してコンテナを起動
  • UIDはすべてのコンテナのユーザーで共通
  • ulimitのプロセス数の制限は全コンテナにかかるので使えない
    • cgroupにパッチ
  • クォータ
    • XFSのプロジェクトクォータ
    • パスごとにクォータ
  • コンテナのCPUやメモリの制限は通常どおりcgroupsで
  • lxc-startの監視:monnitで監視
  • いまのところ止まったことはない
  • supervisordでlxc-startを管理するとorphanedになってしまう
  • コンテナへのアクセス(ルーティング)
  • ドメイン管理
  • Route 53にCNAMEを登録
    • ELBに向ける
  • HTTPのリバースプロキシ
  • Nginx
  • アプリを作るたびにNginxの設定に追加?
  • NginxのLuaでDBを参照する
  • Redis
  • OpenResty:いろいろ入ったNginx
  • 内部DNSでルーティング?
    • コンテナがlistenしているポート番号が違うので
  • rewrite_by_lua
  • 内部リダイレクト
  • SSHのリバースプロキシ
  • OpenSSHにパッチ
  • AuthorizedKeysScriptという設定を追加
  • 公開鍵認証をスクリプトに委譲
  • git push:フックで反映
  • 独自ドメインSSL
  • 1ユーザーに専用ELB
  • Squaleで遭遇したカーネルのバグ
  • (1) コンテナ内のOOM Killer連発でホストダウン
    • KVMだと発生しない。EC2だけ
    • kerneloops取得
    • Xenのttyドライバのバグらしい
    • コンソールへのprintk出力を無効にして回避
  • (2) OOM Killerでcgroupsに属しているプロセスが全部死ぬ
    • CPUコア割り当てとCPUの実行時間制限をかけた場合
    • psでプロセスの状態が変わらない
  • Q: grsecurityパッチを当てた理由
  • A: dotCloudの実装をいろいろまねた
  • コンテナのセキュリティがよくわからなかった
  • dotCloudがあてているのでやっておこう、と
  • 内容は精査した
  • /procや/sysの情報へのアクセスの分離
  • Q: Xenのバグ。AWSの何か? Amazonに問い合わせてみては
  • A: それがよくわからない。問い合わせてみる
  • Q: ローカルのXen環境で再現を切り分けられるのでは
  • A: 検証環境を用意できていなくて

libccgrupとmrubyを使ったwebサーバのリソース制御アーキテクチャ(松本亮介)

  • ミドルウェアやアプリでコンテナ
  • 研究発表
  • 概要
  • Webサーバーへのアクセス数の増加
  • サービスの低価格化と安定性
  • 高集積なマルチテナント環境
  • Webサーバーのリソース制御
  • 既存のアーキテクチャ:閾値処理
  • ユーザーの満足度低下
  • 後手にまわる、柔軟に設定できない
  • 新しいリソース制御
  • テナント・ホスト・リクエスト単位でリソースを分離
  • DSLで制御ルールを記述してリソースを分離
  • サーバーのリソースコントローラがルールにより制御
  • リクエストのときに分離されたリソース領域にattach
  • オーバーヘッドの少ないスクリプト言語
  • Apache httpd + mod_mruby
  • mrubyのmrbgemとして実装
  • cgroupでリソースを分離
  • 各機能が密結合にならないように実装
  • mod_mruby
  • Apacheのmruby binding
  • DSLでWebサーバーを制御
  • リバースプロキシ、仮想ホスト、認証などの例
  • mruby-cgroup
  • libcgroupのmrubyバインディンング
  • mrbgem
  • CPU、CPUコア、ディスクI/Oの制限
  • 稼働中のプロセスの設定を変更するツールも開発中
  • ngx_mrubyは動作モデルの違いがあるのでそのままでは動かない
  • 実験
  • abで
  • 32915req/sec -> 32322req/sec
  • 毎回DSLが実行されるオーバーヘッド
  • 2%ぐらい
  • ビジーループCGIをCPU 50%に制限しているときのリクエスト処理
  • ループ回数を変えて実験
  • 実行時間が短いと、50%に制御すると、40%ぐらいに
  • 実行時間が長いと50%に近づく
  • 仮想リソースに分離する処理がオーバーヘッド
  • Q: ロジックを変更。再起動?
  • A: 2つの方法
  • 再起動したくない場合は、都度ファイルを読み込み
  • 再読込のロジックを作成
  • Q: ほかのhttpd
  • A: 考えたが、実装がそれなりに大変
  • まずは論文がw
  • Q: オーバーヘッド。mod_rubyかcgroup処理か
  • A: CPU制限の例はcgroupの処理。libcgroupの呼び出しの処理ではないかと予想
  • 単純なアクセスの例ではmod_rubyの処理
  • Q: コア数制限は
  • A: そこまで評価が追いついていない。課題
  • Q: libcgroupではなくcgroupfsを直接操作する方法は
  • A: やってみたら、かなり遅かった

vagrantとdockerでの開発環境 / hot patchingで遊ぼう(@masahide7)

  • Docker
  • dotCloud
  • LXCをより便利にするツール
  • デモ
  • Linux 3.9とGoとDockerを自前でビルドした環境
  • デーモン起動
  • docker help
  • docker ps
  • docker ps -a
  • docker images
  • docker run
  • パブリックリポジトリでイメージを検索
  • 自分の作ったイメージをパブリックリポジトリに上げる
  • gitに似たコミットグラフ
  • Vagrant用のDocker動作環境
  • 特定のバージョンのPHPを別の環境にもっていく
  • LD_DEBUG
  • Linuxのローダーがデバッグ情報を出力
  • ldd相当の情報
  • PHPが使っているライブラリを取得
  • rsyncでライブラリをコピー
  • PHPの実行バイナリもコピー
  • ldもコピー
  • ldでライブラリを指定してPHPを起動
  • Dockerのコンテナの最小限構成に持っていく
  • SNATでコンテナから外に行けるように
  • hot-patching
    • ksplice(オラクルに買収された)が有名
    • 実行中のカーネルの書きかえ
  • pid_revalidate()関数をすげかえる
    • psで見えなくする
  • カーネルモジュールをビルドしてinsmod
  • /sys/module/の下にcommandとargs
  • モジュールのみで可能
  • symbol_hijack()関数
  • GitHubにあるtpe-lkmを参考に
  • すげかえる関数のシンボルネームから関数のアドレスを探す
  • 新しいメモリを確保
  • kernel_insn_init()から機械語命令を1つずつコピー
  • 関数の先頭をJMPで上書き
  • Q: 絶対ジャンプが書かれていると
  • A: それは対応していない

コメント

コメントの投稿

管理者にだけ表示を許可する

トラックバック

http://emasaka.blog65.fc2.com/tb.php/1169-93a0ee3c

 | HOME | 

Categories

Recent Entries

Recent Comments

Recent Trackbacks

Appendix

emasaka

emasaka

フリーター。
連絡先はこのへん

Monthly


FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。