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
- ノードの追加はとてもスムース。
