VM
2010年03月23日23:45hbstudy#9に行ってきた
hbstudy#9に行ってきた。
= Packaged VM - yum install
- packaged data centerがもと
- kvm
- ssh host keyからつくりはじめる
- virt manager
- RAM 256MBに抑えている
- HDD とりあえず5GB IDE(古いOSにあわせて; KVMでscsiをつかうと高確率で壊れる)
- NIC 4本 実機で4本はおおい NAT*2 hostlocal(isolatedlocal)*2
- yum install一発にしたい。いろいろ編集したりchmodしたくない。
- libvirt XML file; virtsh define foo.xml
- rpm -ql
- qcow2
- インスオール直後は1.3GBくらい
- delta image と base image
- RPMは別にしていてdependency
- RPM post install script; virtsh defineを実行したり
- pre uninstall script;
- 1つのテンプレートを複数インストールできるか
- ホスト名FQDNが決められているので衝突してしまう
- クラスタ用にはFQDNを予約しておいてパッケージをつくっている
- libvirt(network)
- dnsmasq (ISC dhcp + bindはおもいので)
- static IPがふられる (for ssh)
- KVMべたべた (中立
- libguestfs
- hostからguestのfsにアクセスするしかけ
- http://libguestfs.org
- Augeas
- configをeditするのにつかっている
- http://augeas.net
- RPM
- ref; Fedora RPM Guide
- rpm2json.py
- autotools
- すごくべんりです
- future plans
- NICのMAC addrは静的設定
- DNS dynamic updateを使う方法もあるが
- 静的の方が簡単だった
- uniqになるのもあやしい
= 分散ファイルシステムMogileFSの活用 Tokuhiro Matsunoさん hatena github cpan
- FiciaではMogileFSはつかってない
- mogile: Mow-guy-I もがいる
- L7 のWebアプリ向け分散ファイルシステム。
- mountしてつかうのではない
- fuseでmountできないことはないが安定しない
- livejournal(SNS+blog;OSS)向けにつくったもの by brandfitz(memcachedの作者)
- 基本的に実用本位 for web app
- パッケージソリューションではない
- ユーザー
- digg
- last.fm(SSD)
- livejournal
- sixapart
- mobile factory
- pper boy &co.
- はてな
- CPANでインストールできる
- 構成
- application
- tracker node
- tcp server; job queueもある; replicationも自動でやる; ストレージノードの管理
- store node (httpd)
- Perlbalが標準
- WebDAVがつかえればokのはず
- database (mysql;innodb)
- L7 load barancer
- 基本perlで書かれている
- client libraryはいろいろなバインディングある
- python
- ruby
- php
- nginxのGWもある
- プロトコル
- 登場人物: application, tracker, DB, storage
- application sends key to tracker
- tracker gets url-list from DB
- tracker replys url-list to application
- application send requets to storage[i]
- storage[i] replys data.
- 信頼できるコンポーネントをつかっているので壊れる心配がない
- L7 load barancerをとおすばあい
- X-Reproxy-URL:
- データのながれが特徴
- L7 barancerをつかわないとメリットなし
- perlbalはcacheするのでapp serverの負荷が軽くなる
- application levelなのでOSごと落ちることはない
- tracker nodeがstore nodeをさわって自動レプリカ作成
- SPOFなし
- trackerとstorageは同居させることがおおい; storageはcpuをつかわないので
- 古くなったアプリケーションサーバにディスクをたくさんつんでストレージノードに
- storage nodeをついかするとre-baranceもやってくれる
- webサービスはある程度の確率で外れるので、ストレージサーバを買うのはやだ。
- LDくらいになれば自前でつくれるが、メンテなんてしたくないし。
- clientがstoregeにファイルを置きおわったらtrackerに報告するプロトコル。
- webDAVのいっぱいになったら? 監視はしているので、いっぱいになれば書かれなくなる。
- ルールベース(ポリシ)で選択しているらしい (空き容量とか)
- 止めたいときは、勇気をもって止める。レプリカがあるはずなので。
- 差し替えはやったことはある。
- 同一ファイルにリクエストが同時に来たら?
- mysqlのレベルで一貫性制御されているはず
- ブログサービスを想定しているので更新系はあまりないはず
- 上書きされても困らない場合がおおいし
- 開発は、収束してきている。新機能を追加する方向はない。
- シンプル命
- memcachedは別...
- 枯れている (無理してつかわなくてもいいよ)
- 最近 google group / code.google に移ったかも。
- バックアップはしてなかった。
- ふつうのファイルシステムに書くので復旧もなんとかなるはず。
- podcastingだとでかいのでバックアップたいへん
- メタデータは
- ファイルサイズもとれないかも。実はあまり必要なかったり。
- 更新日時もない
- fuseのためにpluginで保存できるようになっているらしい。
- ストレージサーバが落ちても自動感知せず admin コマンドをたたくと記録される。
- trackerはclientにURLのリストを返しているので、2番目が応答すればok
- ノードの追加はとてもスムース。
2010年03月22日23:53仮想化とかカーネルとかのお話
SIProp勉強会で@oza_x86氏による『仮想化とかカーネルとかのお話』を聞いてきた。
子供たちがいっぱい。つぼみのはなみ。
場所は東工大の西8号館 W棟 10階 W1008号室。
周囲に高層建築がないのでとても見晴らしがいい。
- 仮想化はクラウドとからめて話されることが多いが、実は方向が逆:
- 仮想化はできるだけハードウェアの利用効率を上げるためにつかわれるのに
- クラウドはスケールアウトで並列化で性能を上げる
- 仮想化されると別のノードだとおもっていた通信相手が実は同じHWに載っているということがあるので通信が高速化されるケースあり。
- VM間通信はCPUがボトルネックになる。
- 基本的に実機で遅いものは仮想化しても遅い。一部例外:通信がethernetからlocal pipeになるようなケース。
- periodic tickは重要な機能になっている:
- ageing memory
- accounting process
- fire timer
- でも1/HZごとに割り込み処理が入るのはたいへん。
- もし100台のゲストOSが動いていたとすると、とんでもない負荷になる。
- 特にやることがなくても割り込み処理だけで deep sleep が妨げられてしまう。
- もし100台のゲストOSが動いていたとすると、とんでもない負荷になる。
- Timekeeping in VMware Virtual Machines: http://www.vmware.com/pdf/vmware_timekeeping.pdf
- guest OSがidle 100%のとき
- periodic tickだとhost OSはCPU 20%消費しているとろ
- dyntickにすると5%まで落ちる!
- 今はcallout queueが空のときでもring一周分(128tick)したらタイマ割り込みするようにしている。
- 現状、local APICのドライバの中からcallout queueを参照しているのでレイヤバイオレーション。
- linuxではそのあたりがフレームワークとして規定されている。
- powerTOP
- つくば方面でPlan9がはやりだした理由は、これといったきっかけはない。なんとなくブーム。
ウタゴエの話
- デモ動画が水のせせらぎなのは、この配信が商業利用に耐えるかことを示している。
- sharecastはtree型
- UGはmesh型
MyCloudの話
- 性能がいい
- apache WebDAVではなくてC#で実装されている。
- SkyDriveR(スカイドライバー)とかも
構造化オーバーレイの話
- 超大規模向けのアルゴリズムは100台程度の規模でも使えるか?
- つまり小規模なら1ホップで通信したい。
- ちなみに1ホップなのか0ホップなのか、直接通信は0ホップ。1ホップ = 1 forwardingと考える。
- 既存の経路表はきちっとしていて(表の管理が簡単にするため)、物理的な距離を導入しにくい。
- 経路長がO(log N)に抑えらえるのが構造化オーバーレイの特徴。
2010年02月24日14:48第三回カーネル/VM探検隊 にいってきました
http://groups.google.co.jp/group/kernelvm
仕事はいそがしくても15時に抜けて、懇親会直前まで参加した。場所はIIJ神保町。低レベルレイヤの知識不足を痛感。
- npppd/pipexの話
- IPのハンドリングをカーネル内に入れてppp daemon と tun device の無駄をなくそうという話。→ 代わりにpipex
- IIJはISPなのでpppはつくりつづけいている。npppdは4代目。
- とりあえずopenbsdにマージされた。
- 128MBのMIPSマシン(SEIL)で5000クライアントを相手にできる。1セッションあたり4〜10KBしか消費しないのが特徴。
- FreeBSDにもmpdというのがあるが、これはnpppdよりも複雑な作り。
- IPパケットだけをカーネル内に閉じて処理してLCPなどの制御パケットはユーザ空間のnpppdで処理するので、GREのシーケンス番号どおりに処理されない問題があって、それはpipexでゴニョゴニョすることで解決しているそう。細いことは分からなかった。(前提知識がないのでたぶん理解できない orz)
- もっともemobileなんかはパケット順序がよく入れ替るので、そんなに順序に神経質になる必要はないが
- 遅れてきたパケットは単純に破棄するppp実装が多いので、毎回LCP ECHOが遅れてくるようだと、相手がtimeoutしてしまうので、そのくらいは注意する必要がある。
- 軽快なplan9
- 特権命令: 実行をトラップできる命令
- センシティブ命令: 実行をトラップできないと「まずい」命令
- vmcall: non-root modeからroot modeになる。
- VMRPC: ゲストOSからホストOSを呼べる。ホストOSのカーネルモードもいける。
- iperfで測ってみると、10GbEを使い切れている。これはすごい。完全仮想化や準仮想化では20%くらいしかでていない。
- [Q]VMRPCをつかうとゲストOSのアンチウィルスソフトを回避できてしまうが?→[A]ホストOSでやってください。
- 脆弱性に関する技術的な何か
- キジャクセイ ではなくて ゼイジャクセイ
- でも cat は カット
- 3大防御方法
- ASLR: address space layout randomization (ただしheap splayでコードをあちこちに置くことで回避可能)
- DEP: data execution prevention
- UAC (役に立ってないけど)
- plan9にはこれらのどれもない。
- plan9はユーザ毎が独立していて、スーパーユーザというのもないので、被害は最小限に留められる(はず)
- もちろんカーネルがやられればダメだけど
- SEXYHOOK
- たとえば時刻に関するテストをしたいときにシステム時計をいじるのはイヤだ。
- 一時的に time() の実装をテスト用の関数に置き換えたらいい
- でも、ふつうは time() 関数は直に呼んでるので置き換えは大変。
- YUREX
- びんぼうゆすりカウンターがある。
- openbsdに実装してみた。
- USBプロトコルアナライザで解析して、なんとなくプロトコルがわかった。
- すでにsensorsフレームワークがあるので、それを利用。
- 今後の展開
- ゆれがとまったのを検出してPCを止める
- テンションがあがりすぎたのを検出して rm できないようにとかメールで知らせてくれるとか。
- UNIX/32V on SIMH
- 昔のコードを動く状態で保存することが大事 (動態保存)
- ブートローダが動かない
- 原因はテープデバイスにコマンド投入したあとにDMAが終わるのをhaltして待つところで、haltするとVAXシミュレータが止まってしまいDMAが行われない...
- ほかにもマイクロコードのバグもエミュレーションしなければいけないなどたいへん。
