GlusterFSによるDistributed-Replicatedボリューム構成についてその3。ボリュームの再構成について。Distributed-Replicatedでボリュームを構築した場合、後からフォルダを追加する際には初期構築時と同様全ての合計がreplicaで指定した数の倍数になるようにしないといけない。replicaの最小数である2とした場合、追加するフォルダも2の倍数ずつ、最小で2つaddする必要がある。この場合、先にreplicaとして登録されたフォルダ群は後から追加されたフォルダとは無関係に、そのままreplicaを構成する。-[srv3:/fol2]というペアが作られる事になる。追加するフォルダが物理的に別サーバ上にあるならば別に問題ないが、上の例のように1つのサーバ上の2フォルダを追加しただけでは同一サーバ上にreplicaを作成するだけなので冗長性がほぼ無意味になる。(RAID1的な挙動でいいならアリ)さてこの場合フォルダを追加した後に「replicaペアリングの再構成」をしたくなるわけだが、どうもそれに該当する操作は今のところ見当たらない。スマートではないが一度「replace-brick」を行なってペアリングのフォルダを「移動」後、ペアリング可能なように空けたフォルダを再び「add-brick」で登録することで一応再構成することはできた。replaceはまんまフォルダの内容を移動することになるので容量が増えればそれだけ時間がかかるのが難点である。その分整合性にも気をつけなきゃいけないし。上記でreplaceを行った際に元フォルダ→新フォルダにデータのコピーが行われるわけだが、元フォルダに入っていたファイルはそのまま消されずに残る。うっかりそのまま再利用しようとするとファイルの状況がめちゃくちゃになる場合があるようである。当初実験でreplace→addを行った後、分散ファイルの再構成を行う「rebalance」を行ったわけだが、なんか同名の空ファイルができたりと変な挙動をされてしまった。この状況に限らず「createやaddする時は空フォルダをね」とゆーのを徹底したほうがよさそうだ。まーどっちにしろ私の例のように「1サーバ上の2フォルダを連結」なんて貧乏性的なマネをしなければ無問題な話ではある(苦笑)。GlusterFSによるDistributed-Replicatedボリューム構成についてその2。svr2:/home/brick2その後の検証の結果、上記の場合まず「svr1:/home/brick1」と「svr2:/home/brick1」、及び「svr1:/home/brick2」と「svr2:/home/brick2」でそれぞれReplicaを構成し「ひとかたまり」とした上で、そのカタマリ毎にDistribute的にファイルを分散する、という動きをするようです。大雑把に言えばRAID1+0的な。同一ノード上の別フォルダを使って分散複製ボリュームを構築しても、設定時に離して書けば複製が同一ノード上に集中する=冗長性がなくなるという事態は防げるようです。して当たり前?(苦笑)但しこの場合、後から構成対象のノードを追加する時にはノードの再構成する必要が出てくるでしょうけれども。備忘:GlusterFSによるDistributed-Replicatedボリューム構成について。複数サーバによるファイル分散、しかもある程度の冗長性を持った分散を実現する必要に迫られた。最初は自分で管理システムでも作って適度に分散ーとか思ってたのだが、いちいち整合性とか考えるのめんどくさい。今ならきっとお手軽なファイル分散管理システムがあるに違いない!と探して最も要件にマッチしたのが「GlusterFS」。去年辺りRedHatの傘下に入ったらしく将来性と安定性にも一定の評価ができる点もポイント。Glusterのバージョンは3.2.6。OSはCentOS6.2でインストールはオフィシャルサイトにあったrpmから。これまでのバージョンだと連携した複数サーバに順繰りでファイルを保存していく「Distribute」、ファイルを全てのサーバに複製する「Replica」、ファイルを分割して並行保存する「Stripe」の3パターンからしか挙動を選べなかったらしいが、3.2.5以降辺りから基本の「Distribute」と、「Replica」もしくは「Stripe」を連携させた動きが取れるようになったらしい。今回は安全性重視なので「Distributed-Replicated」構成で構築することに。以降は環境構築時における微妙な実験結果を含む備忘録です。ちなみに間違ってる可能性も否定できないのでご注意を。rpmでインストールする場合今のところx86_64環境しかないっぽい。今回別機能のために32bit環境も必要だったのだが、64bit環境で構築したホストのKVM上に32bit仮想環境をインストすることで対応した。gluster関係をインストールしたのはホストとなる4台の64bit環境。ゲストからはNFSでのアクセスで対応することに(後述)。HOSTNAME」コマンドで関連するサーバの登録を行うのだが、コレは複数台のうちどれで実行しても問題ない。最初に実行したサーバとは別のサーバで後から実行しても問題ない。→「管理サーバ」を特定する必要はないということ。実際に連携することになるボリュームは他のファイルシステム(extなど)でフォーマットしてあって構わない。いうかしといたほうが何かと便利かな。1つのサーバ、というかノード上の異なるフォルダを指定することが可能。svr1:/home/brick2ただし「Replica」系の設定をした場合、「同一ノードを避ける」事は行なわないようなので、状況によっては冗長化のためのReplicaが全くのムダに終わる恐れがある。「Distribute」の場合、基本的にボリューム作成時のノードの順序でコピーを行うらしい。容量によるバランシングはその後。「Distributed-Replicated」の場合も同様。各ノードの「複数ボリューム」を連結する場合、同一ノード上のフォルダを離して記述することである程度同一ノード上に複製されるリスクを減らす事ができるだろう。※完全に無くせるかは未検証。←svr1の間を開けているその前の話だが、「Distributed-Replicated」を構築する場合、連結するノードの数はreplicaで設定する複製の数の倍数になってないといけないらしい、というか倍数になってないとコマンドが通らない。上記でわざわざ同一ノードの2フォルダを連結しようとしたそもそもの発端は、当初奇数であるサーバ3台で構成しようとしたためである。replica=2の2フォルダx3ノードで6フォルダ、と。一応これで構築は可能。当然のように後からノードを追加する場合もreplicaの倍数ずつ追加しなければならない。構築したボリュームは何らかの方法でマウントすることで利用可能になる。構築したサーバ、というかglusterがインストールされているサーバ上ならばマウントタイプ「glusterfs」でマウントできる。/mntそうでない場合NFSマウントがてっとり早いか。/mnt「KVMで32bit仮想環境を構築」と上述したが、そのゲスト環境からはこのnfsマウントを行なっている。マウントさえ済めば後はフツーにコピーなりでファイルを置け、かつ自動的に分散・複製を行なってくれる。その性質上DBとかも置けるとは思うが、レスポンス的にどーだかは未検証。やらない方が良いとおもわれる。「Distributed-Replicated」で、「ノード数未満のreplica数を指定した」≒「全てのサーバには複製されない」設定でも、フォルダについては全てのサーバに作成される。「フォルダ作成時、条件に基づき特定ノードに分散して作成され、以降そのフォルダにコピーしたファイルはそのノードに集中してしまうのではないか」とゆー懸念は不要。...今のところこんなところ。追加情報があったら記事追加します。名前から想像されるもの。