-
- いいね！1
Guutara mmmmm (⁰⊖⁰) くぁwせdrftgy ふじこlp
@Guutara
@kzk_mover そう、全対全、見事な、stupid な、P2P. 全部が、メッシュで、交信してた。ま、管理は、楽だわな。www 今日、行けたら、色々、話したり、見せたり出来たかも。残念でしたぁ～。簡単に、テストした、だけだから、鵜呑みには、しないでね～。:P
2011-07-20 18:24:56
Shinpei Ohtani
@shot6
ファイルのメタデータを持たないつくりは非常に良いと思ってます。メタデータもっちゃうとその管理で負われるし、実際その容量が爆発的に増えだすとなかなか厳しくなる。とはいえ動的に増やすとかGlusterできるのかな・・・
2011-07-20 18:21:10
Guutara mmmmm (⁰⊖⁰) くぁwせdrftgy ふじこlp
@Guutara
@shot6 できたよ。増やすのは。ディスクも、ノードも。難しい管理、してないからさぁ。www
2011-07-20 18:49:55
Guutara mmmmm (⁰⊖⁰) くぁwせdrftgy ふじこlp
@Guutara
@frsyuki ドキュメントは、取り寄せられる、ペーパー位しかないなぁ。あとは、ソース読むか、テストするか。^^;
2011-07-20 18:46:23
K.H
@range2010
@frsyuki v3.2.1だと，volumeを止めずにディスク(brick)を足したり，取り除いたり，データのリバランスしたりできます．
2011-07-20 18:26:00
Sadayuki Furuhashi
@frsyuki
"Gluster 3.2: Rebalancing Volumes" http://www.gluster.com/community/documentation/index.php/Gluster_3.2:_Rebalancing_Volumes
2011-07-20 18:24:40
Keisuke Takahashi / KT
@kske_t
メタデータはxattrで振られています。EHAは確かに偏りますが、rebalanceでテーブルの再生成とデータの再配置ができます。 RT @frsyuki: メタデータは無いらしい。ハッシュベースの分散か。E"lastic Hash" がポイントらしいが…まぁ普通のハッシュでしょ
2011-07-20 18:25:00
Guutara mmmmm (⁰⊖⁰) くぁwせdrftgy ふじこlp
@Guutara
@frsyuki うん、追加は、まだ、良いんだが、変な風に、ノードが死んじゃうと、大変、めんどくさい。全部のデーターを、治さんといかんし。><
2011-07-20 18:26:43
K.H
@range2010
@frsyuki すみません，リバランス中の読み書きは試してないです．ただ，リバランスは(1)レイアウトのfix(2)データの移動と二段階で行われるみたいで，(1)が終われば読み書きできるようになるんじゃないかと思っています．
2011-07-20 18:29:52
K.H
@range2010
大きなファイルをmvでrenameした場合も同様で，いきなりデータを動かすのではなく，移動先にポインタのようなものができて，あとから実データを動かしているようです．
2011-07-20 18:31:26
中村 実
@nminoru_jp
@range2010 ソースを読んでいるけどあまり真面目に解析していませんが。GlusterFSのハッシュはディレクトリ抜きのファイル名を32ビット値のハッシュ化します。これをDFSの範囲に分けます。4台なら0-3FFFFFF,4000000～7FFFFFFF,…みたいに。
2011-07-20 19:13:51
中村 実
@nminoru_jp
@range2010 このハッシュとbrickの担当範囲はローテーションパターンがあり、ディレクトリが生成される度に別パターンが割り当てられるようです。この情報はxattrのtrusted.glusterfs.dhtに記録されます。
2011-07-20 19:16:02
中村 実
@nminoru_jp
@nminoru_jp @range2010 xattrはbrick直下をgetfattr -dm - /expとかすれば見えます。trusted.glusterfs.dht=0sAAAAAQAAAAAAAAAAVVVVVA==いうように入っています。
2011-07-20 19:18:14
中村 実
@nminoru_jp
@nminoru_jp @range2010 GlusterFSはディレクトリのrenameはコストがかかりません。ディレクトリのtrusted.glusterfs.dhtが保存されるため、ファイルの分散方法が変わらないからです。
2011-07-20 19:21:29
SODA Noriyuki
@n_soda
@nminoru_jp @range2010 ディレクトリ単位で位置情報を管理しているのでしょうか？1万個のサブ・ディレクトリを含むツリー全体をmvした場合、コストはO(1)なんでしょうか？それともO(10000)なんでしょうか？
2011-07-20 19:27:07
中村 実
@nminoru_jp
@range2010 ファイルはディレクトリのtrusted.glusterfs.dhtに従って、配置されるbrickが決まります。もしリネームした結果brickが変わるなら移動先に空ファイルを作ってtrusted.glusterfs.dht.linktoを設定します。
2011-07-20 19:26:11
中村 実
@nminoru_jp
@range2010 いろいろ書きましたが http://t.co/GfvvqeM が参考になります。ここをを読んだ方が早いです。
2011-07-20 19:28:32
中村 実
@nminoru_jp
@range2010 @frsyuki GlusterFSはオンライン状態(volumeを止めない)でbrickを足すことはできますが、減らすことはできません。宣伝文句では減らすこともできると書いてあるのですが orz
2011-07-20 19:30:42
中村 実
@nminoru_jp
ディレクトリの移動はO(1)になります。ファイルのmvも、実体の移動せず「リンク」を作るので重い処理ではありません。 @n_soda @range2010 ディレクトリのmvは大丈夫で、basenameの改名がヤバいんですね。
2011-07-20 19:39:07
K.H
@range2010
@nminoru_jp ありがとうございます．確かに，ディレクトリの拡張属性に色々メタデータが埋めこまれていました．これの一貫性を維持すのは結構コスト掛かりそうですね．
2011-07-20 19:39:24