D-7 <altijd in beweging>

Day to day life of a Perl/Go/C/C++/whatever hacker. May include anything from tech, food, and family.

2012年10月

お題: 弊社のgitレポジトリは 社内からなら git:// でcloneできるけど、 社外からはできない(当たり前)。だけどとある事情によりsubmoduleを登録する際にはssh:// ではなく、git://で登録したい。

無理かなー。
無理だろうなー。

と思っていたら。git config で insteadOfってのを定義できるッ・・・・

    [url "ssh://git@git.mycompany.com/"]
        insteadOf git://git.mycompany.com/

こうすると、なんと!git pull とかするときにgit:// で登録されていたsubmoduleが勝手にssh経由でpullされてくるッ・・・・!

gitのこういう隠し機能みたいの、すごいけどなんつーか・・・まぁともかくたすかった!
    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

息子がこの間初の寝返り(補助無し)を成功させて大変喜んでいる親ばかのアカウントがこちらになるわけですが、こういう節目節目で思うのは人間はこれだけ祝福をされるのにいつ自分がどれだけ愛されていたかを忘れてしまうのかなぁ。

もちろん親のほうも子供を愛おしく思わなくなるというのもありえるだろうけどねぇ。

寝返り成功した日

息子よ、僕らは君がよたよたと何回も失敗してから決めた寝返り、あとその後の満足げな表情、どれも全部愛しているぞ。
    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

現在STF は分散オブジェクトストアとしてピーク時にフロントのディスッパチャー1台につき最大80Mbpsを捌いています。この通常のオブジェクト配信するための動作に関しては裏で実際のオブジェクトを格納しているストレージサーバーもさくさくと動いていて特に問題はないのですが(本当の事を言うとアクセス量が増え続けているので、ストレージは増やし続けないとiowaitがじわじわとあがっていく、という問題はあるけど、それはあくまでも中長期的な問題なので今回の話からは除外)、運用しているとストレージサーバー側でオブジェクトの実体(エンティティ)を補充したり、ストレージサーバー間で移動させたりという処理が必要になります。
この際「このストレージにはいってるオブジェクトを全部なめて、正しい状態に戻す」(リペア)という処理を行う事があります。STFのインスタンスごとに規模が違うのですが、最大規模で1ストレージに付き3000万個程度のオブジェクトが格納されているのでこの「全てのオブジェクト」に対する操作は結構膨大なストレージサーバーへのアクセスを生みます。

例えばワーカーを100プロセス展開しておくと、リペアが起こるまでは平穏なわけですが一旦リペアが始まると突然それぞれのワーカーが一斉に唸りを上げながらストレージを痛めつけ始めるわけです。この際ストレージサーバー全台に対してアクセスがばらけていればこの処理もまだ対応できるのですが、同じストレージサーバーにアクセスが集中すればもちろん死亡フラグが立ちます。

STFに触りはじめて1年半、この間ストレージサーバーは当然壊れますので、リペアはたびたび行う必要がありました。その際アクセス負荷による障害を起こさないようにするのは運用者によるワーカー数の調整が必要になっていました。具体的にはワーカーの数などをちょこちょこ調節するわけです。

STFを触り始めた時からつい最近までこのワーカープロセス数の設定はファイルに記述されており、ファイルの編集→プロセスの再起動という処理を行う必要がありました。もちろん設定ファイルはレポジトリに格納されているのでレポジトリで編集→デプロイでもいいのですが、これはこれでまた面倒な話です。

というわけでこれを自動化していくべく何をしたか:

続きを読む
    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

このページのトップヘ