Kyoto Tycoon と GreenBuckets を組み合わせて使う - blog.nomadscafe.jp
分散Object Storageの GreenBuckets ではストレージノードの実装を問わないので、こういうこともできると言う例 Kyoto Cabinet の Directry Hash DataBase を使うと、ファイルシステム上の1ファイルが1レコードとなるデータベースを作成することができます。通常のDBMでは数KBまでの小さいデータに性能が最適化されているのに対して、Directry Hash DataBaseでは数十KB〜のデータを扱いやすくなるということらしいです。 もちろん、Kyoto Tycoon からも使うことができるので、GreenBucketsのストレージノードとしても利用できます。 まず、ktserver でノードを立ち上げます。今回は試しに1つのktserverで複数のデータベースを担当させ、それぞれ1ノードとして扱います。 $ ktserver -li -
GreenBuckets ノード障害時の書き込み可用性を向上させた - blog.nomadscafe.jp
これまで GreenBuckets では、オブジェクトの読み込み時はノードがダウンした場合でも可用性が保たれていましたが、書き込みはオンライン状態にあるノード数がレプリカ数分ないと新規オブジェクトの追加ができませんでした。そのため可用性を保とうと思うと、レプリカ数が2では最低4台、レプリカ数3では最低6台のノードがないと1台でもノードがダウンした場合に書き込みができない状態になっていました。 これでは初期投資が大きくなりすぎるということで、最低2台(レプリカ数2)でも書き込みの冗長性が確保できるようにしてみた。 左の図が、ノード1が障害でオフラインの状態。これまでだとノード1に書き込もうとして失敗するとすぐに保存エラーとクライアントに返していましたが、GreenBucketsを変更して右の図のように、ノード2と3に仮に保存して(1)、新しく設けた Recovery Queue に登録します
GreenBuckets ノード障害時の動作と復旧方法 - blog.nomadscafe.jp
/* カラム名を変更しています 20110524 */ @kamipo さんが正座して待っているのを思いだした。 GreenBucketsで、ノードがダウンした時の動作と復旧方法です。GreenBuckets自体の動作実績はないのであくまで想定です。ただ、mixiの画像クラスタの構成をまねているので復旧方法もほぼ同じかもです まず、障害が起きて、復旧するまでの間を次の3段階にわけて対応を考えます 障害が発生し、アラート検知、運用者が対応するまで 運用者が対応を行い、一時復旧 データの整合性がとれ、完全復旧 ■ 障害が発生し、アラート検知、運用者が対応するまで さて、HDDが破損するなどしてサーバがダウンした場合、運用者が対応を行うまで、GreenBucketsは障害の影響をなるべく表に出さないよう、動作します 上の2つの図はノード1がダウンした状態を示しています。オブジェクトを取得する際(
GreenBuckets という Object Storage を作りました - blog.nomadscafe.jp
GreenBuckets という Object Storage を作りました Object Storage とは何かというと、OSSではOpenStack Object StorageとかMogileFS 、Webサービスで使われているところでは mixi の ImageCluster とか livedoor の STF とか、比較にならないけどAmazon S3とかそういったたぐいのものです。しばしば画像のストレージなんかに使われていると思います。今回作ったのは GreenBuckets というもので、mixiのImageClusterの構成をまねしつつ、stfと同じようにバケット単位での操作を可能としています。なんですでにあるのに作ったのかというと、主に「つくってみかったから」ですね。一応目標として シンプルだけど使える cpanm でインストールが完了する できるだけ少ない依存関係
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
