夜行録 - 酔歩.net

gfarm をガリガリに使うと、 syslog が gfarm のログで埋まってどうしようもなくなるので、ログレベルを変更。
デフォルトでこんなに何もかもログ出力しないでいいと思うけどね。

/etc/gfmd.conf で

log_level warning

hadoop もログうるさすぎる系だよなぁ…。あっちもいずれどうにかしないと

gfarm の gfrep が、リンク先のない symlink などにぶつかるとあっさり死ぬので、深いサブディレクトリを持つディレクトリをまとめて move できない。 symlink 何てそんなもんじゃんよもー

しょうがないので、こんな場当たりコードで再帰して無理やり move 。/work/MYNAME/Gfarm/に一旦全体をマウントしておいて、そこを辿りながら、パスの前の方をぶった切って Gfarm のパスにする。それも echo と sed で。２０年ぐらい前からずっとこんなやり方だな

#! /bin/bash

GFREP="gfrep -m -N 2 -H $HOME/gfarmdst -h $HOME/gfarmsrc"
GFMON="/work/MYNAME/Gfarm"
function rec () {
        GFPATH=`echo $1 | sed -e "s@${GFMON}@@"`
        ${GFREP} $GFPATH
        if [ $? -ne 0 ];
        then
                if [ -d $1 ];
                then
                        cd $1
                        for i in *;
                        do
                                rec $1/$i
                        done
                fi
        fi
}

rec $@

サーバ放置してたら大変酷い目にあった。トラブル３連発。しかもまだ未解決

その１：gfarm のメタデータサーバのバックエンドを、ldapにして放置していたら、

> sudo du -sh /var/gfarm-ldap
77G /var/gfarm-ldap

とかなっていて、/ に 100G とか割り当ててあったのに 95% くらい使い切っていて焦る。

一応この件の問題は、/var/gfarm-ldap/DB_CONFIG に

set_flags DB_LOG_AUTOREMOVE

と指定するのみならず、/etc/gfarm-ldap/slapd.conf で

checkpoint  512  15

としておいてやらないと bdb のトランザクションログがちゃんと消えてくれないよ、ということで、ちゃんとそこまで書いておいて欲しいものである。
AUTOREMOVE だけは設定しておいたんだけどなー、これでいいのかどうか判らないから放置して様子みようとほったらかしにしたんだった。

[read more]

こっちに貼ろうと思って放置されてた件

"STFは分散オブジェクトストレージです。Perlメインの似たようなシステムとしてはMogileFSが有名ですが、STFは後発のメリットを生かしてPSGI互換にしたり、使用するプロトコルを基本的にHTTPというオープンで枯れた技術を採用したりとメンテナンス・運用の利便性があがっていると考えています。 歴史 STFは元々ApacheモジュールといくつかのPerlワーカーで書かれていましたが、ひょんなことから自分がPSGIに移行させてそれ以降面倒を見ています。基本的にはすでに動作していたCベースのコードがあったのでそれをふむふむと読んでガリガリポーティングしました。 結果、アプリ部分はPerlになり拡張・修正しやすくなり、それ以外はApache(or nginx)、MySQL、Q4M (or TheSchwartz)、Memcached等のミドルウェアを駆使して動作する現在の形になりました。 この改良版は2011年中盤くらいに本番適用され、ロケタッチやライブドアブログ宇の画像アップロード等に使われています。2011年末の時点でオブジェクト数4億個、13億エンティティ、70TB程度のデータを管理しています。データ転送量もピーク時に400Mbpsを特になんの問題なくさばいています。 なお、PSGI移行以前のSTFについてはこちらの資料が詳しいです。実装が変わっていますが、やっていることはかわりません。"

って、perlってまだ生きてたんだつーか

そして、奇しくもlivedoorと楽天

"　楽天は2012年7月4日、自社開発した分散ファイルシステム「LeoFS」を、オープンソースソフトウエア（OSS）として公開した。「Amazon S3」互換のAPI（アプリケーション・プログラミング・インタフェース）を備えたオブジェクトストレージを構築するためのソフトであり、複数台のPCサーバーをピア・ツー・ピア（P2P）構成にすることで、数ペタバイトの容量を実現できる。楽天の技術開発部門である楽天技術研究所が開発した。 　楽天は2011年夏に、Webサイトで使用するデジタル写真のストレージとして「ARIA」を自社開発し、実際のサービスで運用を開始している。今回開発したLeoFSは、このARIAの後継バージョンである。Web用写真に多い数十?数百Kバイトのファイルを高速に読み書きできるように、キャッシュアルゴリズムなどを工夫した。 　LeoFSは、データを保存するストレージクラスターがP2P構成であり、ストレージクラスターを管理するノードが複数台存在する構成となっているため、可用性は高い。プログラミング言語には関数型言語の「Erlang」を主に採用。全体の98％をErlangで、残りの2％で主にキャッシュに関わる部分を「C」で開発している。 "

あーらん！あーらん！

クラウドと、dropboxなんぞのおかげで、分散FSすっかり耳にしなくなったなー。grid filesystemどこ行ったのかなー。みんなhadoopですかそーですか

最近、会社のサーバが busy なので、手近な計算機で計算していたが、いずれにせよ1次データは大きすぎて邪魔だし回線も細いので、解析後のデータだけ手元に持ってきて、さらにフォーマット変換したり報告書にまとめたりしてるが、ディレクトリ構成だけは合わせてあるけどファイル自体は複数のサーバやPCに分散しだしてしまっている。いかにもダサい

昔はそれに対する答えとして、 AFS などの分散ファイルシステムでなんとかなってくれるだろうと期待していたけれど、今の状況だと AFS でも coda でも解決にはならなそう。 AFS だとストレージは分散するしファイルシステムは unified だけど、1ディレクトリを複数サイトで share するというのには向いてない。今欲しいのは、ファイル単位でどこかに置かれていながらディレクトリではそれを集約している、いうなれば union mount されてるようなヤツだな。

もちろん書き込まれたファイルはローカルサイトに落ちてくれて、よそのファイルを読んだらキャッシュされて、ディレクトリエントリだけ常時最新を保持してればいいんじゃないかと。

分散fs なんてもう作る人いないだろうなぁ…。

玄箱/NetBSD 5.1R パッチが出ていたので、久し振りで build world
とはいえ、 src tree は lfs 上で、その lfs が tar の書き戻しにすら耐えられないんで ffs で backup やらせてるくらいなんでどうしたものか。

と思っていたんだが、調べてみたら非常に安定していた 4.99.33 kernel なんてのが残っていた…。ひょっとしてこれがあったら lfs の backup 領域回復させられてたんじゃね？
とりあえず、 4.99.33 で起動して、リポジトリを rsync で取得、既存の src tree 上に cvs update して頑張って手動 revert。さすがに今使うと cvs めんどいな。パッチを当てて cvs diff してパッチと比較、当たり損いを手動修正(存在しないファイルとか、逆に前回に作っちゃってたものとか)。

あとは、 build.sh で tools と kernel 作って(conf ファイルも適宜 merge)、 releasekernel して玄箱の linux 領域の /boot/ に objcopy して kuro_boot.conf 修正して、 distribution して install して postinstall して

リブート。したら起動しなくなったでござるの巻（負け）
よくログを確認すると kernel conf の symbol table 小さいって文句が出ていた罠。…正常終了してんだから気づかねーよorz

で、ここからが罠で、 user land が 5.1R になっている所為でか、安定していた 4.99.33 で起動しなくなってるんですけど……………ｏｒｚ
とりあえず、 5.0R と 4.99.73 で起動はするんだが、 lfs に大量に書くと刺さるんで、 kernel 作り直せないんですけど……。どうすんだよ…、これ……。

[read more]

なんでか、どうやっても newfs した lfs 領域に書き戻す途中で刺さって駄目なので、諦めて /backup を WAPBL の ffs で用意して暫定運用。 backup とれない訳にいかんもんなぁ…。

しかしどうしたものかな…。省電力・省スペースPCで 3.5" HDD 入って bsd 動くのを別に探すかなぁ…。

また lfs の調子が悪化して、 rsync で backup とってると途中で切れる……

newfs してやり直しかなぁと。そのためには現在のバックアップ内容をどこかにどかさなきゃならないのだが…
何故か十分収まるだけのパーティションが残ってる。しかも FFS。(じつは coda用に確保してそれっきりになっていた)

ついでに、バックアップの外部 HDD (USB1) の EXT2 にも rsync で同期して準備万全。

で、for で回して tar かけると超遅い。寝て起きてもまだやってるくらい遅い。てゆーかうっかり z つけちゃって、ただでさえ非力な玄箱の ppc に負荷かけすぎで超遅い。このあと更に半日くらい進んだところで刺さってた(ぎりぎり全部終わるかどうかってあたりだったけど、尻尾付近で切れてて、どこからやり直さなきゃいけないか判らなくない)。
残りもう半分くらいも for と tar で回して一日くらいかかってて、結局退避だけで週末終わる。

で、あとは newfs して書き戻すだけなんだが……刺さりまくって全然駄目なんですけど？

じゃあ、外部 hdd から rsync で戻せば…っていうと、そっちも刺さる。なんだ？昔はどうやってた？

OS version の問題か、 tar or rsync か、うまく負荷をかけたり外したりしないと駄目なのか？と試行錯誤したが駄目。ここまででもう1週末潰す。

[read more]

玄箱の、バックアップに使っている領域がもう何書いても、書かないで読んでるだけ (rsync の dry-run)でも刺さりまくってひどい。
1回 linux のバックアップとるのに、 rsync -> reset -> umount -> fsck -fy -> mount -> rsync というの3回くらいは繰替えさないと終わらない。とてもやってられないので……newfs したところに書き戻して clean な状態を作ることに。

このバックアップ領域の更にバックアップは、 USB HDD に EXT2 でとってある。から、まあなんとなかるんだが、玄箱の USB は USB1 で遅い………。最後の状態を HDD の方に sync して、 newfs して、そこから全部書き戻すのに半日以上かかったわ……。うっかり tar で書き戻したら owner/permission 忘れるし…。結局また rsync で微調整。

しかし、この結果、驚くほど安定するようになった。上書きが繰り返されて dirty な構造になったの、ちゃんと repack できないでいたんだな…。

しかし zfs にしたいなぁ………。 QNAP で opensolaris 動かねーかなー。

とりあえず SugarSync の Free 版を試用してみる。

[read more]