読者です 読者をやめる 読者になる 読者になる

めもめも

このブログに記載の内容は個人の見解であり、必ずしも所属組織の立場、戦略、意見を代表するものではありません。

RHS2.0Beta2/glusterfs-3.3.0qa38-1のGeo Replication設定手順

何をするかというと

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と異なり、毎回すべてのファイルの差分をチェックするわけではありません。ボリューム内の各ディレクトリの拡張属性として、そのディレクトリ配下のファイルの変更状況が記録されており、ファイル変更があったディレクトリの下だけを差分チェックしています。