[0] GlusterFSによるDistributed-Replicatedボリューム構成についてその3。ボリュームの再構成について。-[Id of Radiance ver.5]





■ GlusterFSによるDistributed-Replicatedボリューム構成についてその3。ボリュームの再構成について。

 続き。

 Distributed-Replicatedでボリュームを構築した場合、後からフォルダを追加する際には初期構築時と同様全ての合計がreplicaで指定した数の倍数になるようにしないといけない。replicaの最小数である2とした場合、追加するフォルダも2の倍数ずつ、最小で2つaddする必要がある。

 この場合、先にreplicaとして登録されたフォルダ群は後から追加されたフォルダとは無関係に、そのままreplicaを構成する。なんのことかとゆーと初期に

  例:gluster volume create VOL replica 2 srv1:/fol1 srv2:/fol1 srv1:/fol2 srv2:fol2

として構築したglusterボリュームは、[srv1:/fol1] -[srv2:/fol1]を1ペア、[srv1:/fol2] -[srv2:/fol2]を1ペアとしてreplicaをするわけで、この上で

  例:gluster volume add-brick VOL srv3:/fol1 srv3:/fol2 ~

とかしてフォルダを追加しても[srv1:/fol1] -[srv2:/fol1]、[srv1:/fol2] -[srv2:/fol2]のペアはそのままに追加されたフォルダで[srv3:/fol1] -[srv3:/fol2]というペアが作られる事になる。追加するフォルダが物理的に別サーバ上にあるならば別に問題ないが、上の例のように1つのサーバ上の2フォルダを追加しただけでは同一サーバ上にreplicaを作成するだけなので冗長性がほぼ無意味になる。(RAID1的な挙動でいいならアリ)

 さてこの場合フォルダを追加した後に「replicaペアリングの再構成」をしたくなるわけだが、どうもそれに該当する操作は今のところ見当たらない。
 とりあえずスマートではないが一度「replace-brick」を行なってペアリングのフォルダを「移動」後、ペアリング可能なように空けたフォルダを再び「add-brick」で登録することで一応再構成することはできた。が、replaceはまんまフォルダの内容を移動することになるので容量が増えればそれだけ時間がかかるのが難点である。その分整合性にも気をつけなきゃいけないし。
 また、上記でreplaceを行った際に元フォルダ→新フォルダにデータのコピーが行われるわけだが、元フォルダに入っていたファイルはそのまま消されずに残る。なのでうっかりそのまま再利用しようとするとファイルの状況がめちゃくちゃになる場合があるようである。当初実験でreplace→addを行った後、分散ファイルの再構成を行う「rebalance」を行ったわけだが、なんか同名の空ファイルができたりと変な挙動をされてしまった。まあこの状況に限らず「createやaddする時は空フォルダをね」とゆーのを徹底したほうがよさそうだ。

 まーどっちにしろ私の例のように「1サーバ上の2フォルダを連結」なんて貧乏性的なマネをしなければ無問題な話ではある(苦笑)。

関連タグ:LinuxglusterFS
2012-04-18 [日記]

関連記事: