記事検索
月別アーカイブ
アクセスカウンター

    タグ絞り込み検索
    2010年03月23日23:45hbstudy#9に行ってきた

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


    このエントリーをはてなブックマークに追加

    トラックバックURL

    コメントする

    名前
     
      絵文字