hbstudy#9に行ってきた。

= Packaged VM - yum install RHEL consultant, Red Hat Japan 佐藤 暁 (さとる)

  • 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
  • Augeas
  • 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
  • ノードの追加はとてもスムース。
タグ ：
#VM