何をするかというと
RHS2.0Beta2のGeo Replicationの設定手順のメモです。中身は、GlusterFS 3.3.0qa38-1なので、コミュニティ版GlusterFSで試す方は、ここにあるRPMをご使用ください。
基本構成
[master01]----[master02] : GlusterFS Cluster(Replication Master) | | Geo Replication V [slave01]----[slave02] : GlusterFS Cluster(Replication Slave)
Masterのボリュームvol01をSlaveのボリュームvol01_slaveにGeo Replicationします。
Master側とSlave側のボリュームの構成は同一にする必要はありません。ここでは、Slave側だけ、あえて、Replication構成にしています。
[root@master01 ~]# gluster vol info vol01 Volume Name: vol01 Type: Distribute Volume ID: af843a2f-a952-4742-ba57-327569ff5615 Status: Started Number of Bricks: 2 Transport-type: tcp Bricks: Brick1: master01:/data/brick01 Brick2: master02:/data/brick01 [root@slave01 ~]# gluster vol info vol01_slave Volume Name: vol01_slave Type: Replicate Volume ID: 6c420a69-256a-4b29-b17e-487d02856b30 Status: Started Number of Bricks: 1 x 2 = 2 Transport-type: tcp Bricks: Brick1: slave01:/data/brick01 Brick2: slave02:/data/brick01
また、Geo Replicationは、任意に決めた、各クラスタの代表ノード(この例では、master01とslave01)の間で行われます。データ転送はSSHでトンネリングすることで暗号化されます。
Slave側のSSH接続先は、一般ユーザで構いません。Masterのrootから公開鍵でパスワード無しの接続を許可します。ただし、SSHの機能で、実行可能なリモートコマンドをGeo Replicationに必要なコマンド(gsyncd)だけに制限することは可能です。
以下の手順は、Master/Slaveの双方で、ボリューム(vol01/vol01_slave)は作成済みとして進めます。
Slave側の設定
以下はslave01で実施します。
実は・・・既知の問題のWork Aroundで、まずは、次のコマンドを叩く必要があります。
[root@slave01 ~]# setenforce 0 [root@slave01 ~]# sed -i 's/SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config [root@slave01 ~]# mkdir /usr/local/libexec/glusterfs [root@slave01 ~]# ln -s /usr/libexec/glusterfs/gsyncd /usr/local/libexec/glusterfs/gsyncd
ちょっといけてないのですが、Bugzillaを上げておいたので、GA版までには修正されると思います。
・The default location of gsyncd is invalid.
・geo-replication with an unprivileged user fails because of SELinux.
2012/05/21 追記
Symbolic Link作成の方は、以下で実施する、リモートコマンドを制限するためのauthorized_keysの設定があれば不要なようです。GA版では、authorized_keysの設定が必須になるため、基本的にSymbolic Link作成は不要ということになります。
ここからは正式な手順です。SSH接続を受けるユーザ/グループを作成します。後半のディレクトリは一般ユーザでマウントするための仕組み(mountbroker)で必要なものです。
[root@slave01 ~]# groupadd georep [root@slave01 ~]# useradd -G georep georep01 [root@slave01 ~]# passwd georep01 [root@slave01 ~]# mkdir /var/mountbroker-root [root@slave01 ~]# chmod 711 /var/mountbroker-root/
Slave用の設定ファイルを書きます。最後の3つのoptionが追加部分です。georep01/georep/vol01_slaveは環境に応じて変えてよい所です。
[root@slave01 ~]# cat /etc/glusterfs/glusterd.vol volume management type mgmt/glusterd option working-directory /var/lib/glusterd option transport-type socket,rdma option transport.socket.keepalive-time 10 option transport.socket.keepalive-interval 2 option transport.socket.read-fail-log off option mountbroker-root /var/mountbroker-root option mountbroker-geo-replication.georep01 vol01_slave option geo-replication-log-group georep end-volume
複数のボリュームを指定する場合は、次のように記載します。
option mountbroker-geo-replication.georep01 vol01_slave,vol02_slaveもしくは、ボリュームごとにスレーブ側のユーザを変える場合は、次のように複数のエントリを記載します。
option mountbroker-geo-replication.georep01 vol01_slave option mountbroker-geo-replication.georep02 vol02_slave
最後にglusterdサービスを再起動して、設定変更を反映します。
[root@slave01 ~]# service glusterd restart Stopping glusterd: [ OK ] Starting glusterd: [ OK ] [root@slave01 ~]# service glusterd status glusterd (pid 1590) is running...
この時、mountbroker-rootの下にディレクトリ /var/mountbroker-root/mb_hive が作成されます。これが無いとGeo-Replicationの開始に失敗するので、誤ってこのディレクトリを削除した際は、glusterdの再起動を行なって再作成してください。
Master側の設定
以下はmaster01で実施します。
georep01@slave01に公開鍵認証を仕込みます。
[root@master01 ~]# ssh-keygen -P "" [root@master01 ~]# ssh-copy-id georep01@slave01
リモートコマンドを制限するためにslave01側で下記の設定を仕込みます。
[root@slave01 ~]# cat /home/georep01/.ssh/authorized_keys command="/usr/libexec/glusterfs/gsyncd" ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAs5K71oRlcr+O+l7Okwgw・・・
ここで、おもむろにGeo Replicationを開始します。
[root@master01 ~]# gluster vol geo-replication vol01 georep01@slave01::vol01_slave start Starting geo-replication session between vol01 & georep01@slave01::vol01_slave has been successful [root@master01 ~]# gluster vol geo-replication vol01 status MASTER SLAVE STATUS -------------------------------------------------------------------------------- vol01 ssh://georep01@slave01::vol01_slave starting...
SLAVEに表示されている「ssh://georep01@slave01::vol01_slave」は、「georep01@slave01::vol01_slave」と同じ意味です。(後者が前者の省略表記)
しばらく待つとSTATUSがOKに変わります。
[root@master01 ~]# gluster vol geo-replication vol01 status MASTER SLAVE STATUS -------------------------------------------------------------------------------- vol01 ssh://georep01@slave01::vol01_slave OK
これでGeo Replicationが開始されました。vol01に書いたファイルがvol01_slaveにも非同期コピーされます。
[root@master01 ~]# mount -t glusterfs localhost:/vol01 /mnt [root@master01 ~]# for num in $(seq 0 9); do cp /boot/vmlinuz-2.6.32-220.13.1.el6.x86_64 /mnt/file$num;done [root@slave01 ~]# mount -t glusterfs localhost:/vol01_slave /mnt [root@slave01 ~]# ls -l /mnt 合計 38520 -rwxr-xr-x. 1 root georep01 3941136 5月 9 16:18 2012 file0 -rwxr-xr-x. 1 root georep01 3941136 5月 9 16:18 2012 file1 -rwxr-xr-x. 1 root georep01 3941136 5月 9 16:18 2012 file2 -rwxr-xr-x. 1 root georep01 3941136 5月 9 16:18 2012 file3 -rwxr-xr-x. 1 root georep01 3941136 5月 9 16:18 2012 file4 -rwxr-xr-x. 1 root georep01 3941136 5月 9 16:18 2012 file5 -rwxr-xr-x. 1 root georep01 3941136 5月 9 16:18 2012 file6 -rwxr-xr-x. 1 root georep01 3941136 5月 9 16:18 2012 file7 -rwxr-xr-x. 1 root georep01 3941136 5月 9 16:18 2012 file8 -rwxr-xr-x. 1 root georep01 3941136 5月 9 16:18 2012 file9
Slaveノード障害時の対応
Geo Replicationは特定ノード(代表ノード)間でのデータ転送が行われますが、Slave側の代表ノードが障害停止した場合は、手動で他のノード間でのGeo Replicationを再開することは可能です。
Master側の代表ノードが停止した場合には、代表ノードを復旧した後に、Geo Replicationを再開します。代表ノードが停止したままで、代表ノードを変更することはできません。詳細な理由は割愛しますが、これは、データの整合性を保証するために必要な制約となります。(なにか回避手順が見つかったら、追記するかも知れませんが・・・・)
例えば、master01-slave02間で、上述と同じ事前の仕込みをしておけば、slave01が停止した際は、次のように、master01-slave02間でGeo Replicationを再開することができます。
まず、既存のGeo Replicationの状態がfaultyになるので、これを停止します。
[root@master01 ~]# gluster vol geo-replication vol01 status MASTER SLAVE STATUS -------------------------------------------------------------------------------- vol01 ssh://georep01@slave01::vol01_slave faulty [root@master01 ~]# gluster vol geo-replication vol01 georep01@slave01::vol01_slave stop Stopping geo-replication session between vol01 & georep01@slave01::vol01_slave has been successful [root@master01 ~]# gluster vol geo-replication vol01 status MASTER SLAVE STATUS --------------------------------------------------------------------------------
次にslave02を指定して、Geo Replicationを開始します。
[root@master01 ~]# gluster vol geo-replication vol01 georep01@slave02::vol01_slave start Starting geo-replication session between vol01 & georep01@slave02::vol01_slave has been successful [root@master01 ~]# gluster vol geo-replication vol01 status MASTER SLAVE STATUS -------------------------------------------------------------------------------- vol01 ssh://georep01@slave02::vol01_slave starting... [root@master01 ~]# gluster vol geo-replication vol01 status MASTER SLAVE STATUS -------------------------------------------------------------------------------- vol01 ssh://georep01@slave02::vol01_slave OK
これでOK。slave01が復活したら、Proactive Self-healで、salve01-slave02間のReplicationは、自動的に回復します。Geo Replicationは、master01-slave02で継続するので、必要があれば、手動でmaster01-slave01間に戻します。
おまけ
Geo Replicationは、実装的には、rsyncがベースなのですが、普通のrsyncと異なり、毎回すべてのファイルの差分をチェックするわけではありません。ボリューム内の各ディレクトリの拡張属性として、そのディレクトリ配下のファイルの変更状況が記録されており、ファイル変更があったディレクトリの下だけを差分チェックしています。