STFで気づいたら8ヶ月間に及んだオペレーションがいつのまにか終わってた件 : D-7 <altijd in beweging>
本当に手前味噌な話ですけど、STFさん。今回も「あー、俺いいソフトウェア書いた」と満足できたので、この記事を書きます。ちなみにSTFとはみんな大好きPerlで書かれた分散オブジェクトストレージです。(github) tl;dr; ああ、俺いいコード書いた8ヶ月間最初のスクリプトをキックする以外何もしてないけど、18億個のデータを無事格納しおえた去年の夏くらいに「お、そろそろ今ある物理ストレージサーバーのディスク容量一杯になるぞ」という状態が観測されたので 追加のストレージを導入していただいて、そこから「現在格納されているオブジェクト群を新しいストレージにまた均等に均す」というオペレーションを開始しました。もちろんシステムを停止させることができればあっという間に終わる仕事なんですが、ユーザーのデータがのっているので当然止めるわけにはいかないです。そこで システムはオンラインのまま、遅延等を発
STF 1年後。 : D-7 <altijd in beweging>
ほぼ一年前に「STFワーカーの自律分散と適応スロットリング」という記事を書いた。 STFというAmazon S3っぽいツールの裏方のワーカーをどう「サービスの邪魔をせずに」「しかし可能な限り大量のデータを速やかに処理するか」という命題をどう解消した、と言う話。 あれからほぼ1年たって「そういえばもう大分STFなにもしてねぇな」と気づいたのでこのエントリを書き始めた。 あれ以来ワーカーの過負荷によるアラートが来たことない。あれ？と思ったらワーカーが止まっててキューがいっぱいいっぱいになっちゃった、というのもない。足りないワーカーは勝手に補充されるし、ストレージの負荷が高い時は勝手に自動的にスロットリングされる。要はもうこの1年近く俺は管理画面でフラグをちょいと変えたりグラフを見たりする意外ほぼなんにもしてない。勝手に動いている。 この協調メカニズムを作るのにMySQLだけを使って書いたのが自
STFワーカーの自律分散と適応スロットリング - D-6 [相変わらず根無し]
現在STF は分散オブジェクトストアとしてピーク時にフロントのディスッパチャー１台につき80Mbpsを捌いています。この通常のオブジェクト配信するための動作に関しては裏で実際のオブジェクトを格納しているストレージサーバーもさくさくと動いていて特に問題はないのですが（本当の事を言うとアクセス量が増え続けているので、ストレージは増やし続けないとiowaitがじわじわとあがっていく、という問題はあるけど、それはあくまでも中長期的な問題なので今回の話からは除外）、運用しているとストレージサーバー側でオブジェクトの実体（エンティティ）を補充したり、ストレージサーバー間で移動させたりという処理が必要になります。 この際「このストレージにはいってるオブジェクトを全部なめて、正しい状態に戻す」（リペア）という処理を行う事があります。STFのインスタンスごとに規模が違うのですが、最大規模で１ストレージに付き
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
