これらのサービスはどのように相互作用しますか？
GlusterFS
公式サイトからダウンロードしたバージョン3.3.1、rpm-kiを使用します。 ボリュームを作成した後、クライアントはいくつかの方法でそれにアクセスできます。
# mount.glusterfs
-
# mount -o mountproto=tcp,async -t nfs
-
# mount.cifs
最初のオプションを使用します。この場合、クライアントはすべてのサーバーとの接続を確立し、マウントされたサーバーに障害が発生すると、実稼働サーバーからデータを受信するためです。
CTDB
この投稿では、優れたメカニズムについて説明しています。 ドキュメンテーションのLVSを使用したクラスターの負荷分散はNATネットワークに対してのみ規定されているため、ラウンドロビンDNSを使用します。 SMB、NFSと同様に、標準のリポジトリがあります。
# yum install ctdb samba nfs-utils cifs-utils
さあ始めましょう
2つのノードがあるとします。
gluster1, 192.168.122.100
gluster2, 192.168.122.101
フォールトトレランスを実装するIPがまだ必要です-サーバー間で移行します。
192.168.122.200
192.168.122.201
データドメインのRR DNSは次のようになります。
; zone file fragment
data. 86400 IN A 192.168.122.200
data. 86400 IN A 192.168.122.201
GlusterFS用のボリュームの作成は行いません。 分散レプリケーションパーティション（分散+複製ボリューム）が必要だと言います。 それをsmbと呼びましょう。 開始するには、 各ノードでローカルにマウントします。
# mount.glusterfs gluster1:smb /mnt/glustersmb
各サーバーは、独自のホスト名をオプションとして使用します。 / etc / fstabにエントリを書くことを忘れないでください。
（各サーバーの） Samba構成を編集します 。
# vim /etc/samba/smb.conf
...
[global]
＃主なパラメーターは、クラスタリングを担当します。
clustering = yes
＃ユーザーリクエストを保存するデータベースとの通信（作業の仕組みに関するリンクを参照）
idmap backend = tdb2
＃構成ファイルのあるフォルダー
private dir = /mnt/glustersmb/lock
そして、ボール自体のセクションを追加します。
[pub]
path = /mnt/glustersmb/lock
browseable = YES
force user = smbcli
force group = smbcli
writable = yes
guest ok = yes
guest account = smbcli
guest only = yes
このフォルダーは、一般的な使用、許可なしのsmbcliユーザーからのアクセス用です。 後で作成し、権利を割り当てます。
サーバーの1つに、いくつかのCTDB構成ファイルを配置するフォルダーを作成します
# mkdir /mnt/glustersmb/lock
そして、ファイルを追加します。
# touch /mnt/glustersmb/lock/lockfile
各サーバーのCTDB構成ファイルは、次のように縮小されます。
# vim /etc/sysconfig/ctdb
CTDB_RECOVERY_LOCK=/mnt/glustersmb/lock/lockfile
CTDB_PUBLIC_ADDRESSES=/etc/ctdb/public_addresses
CTDB_MANAGES_SAMBA=yes
CTDB_NODES=/etc/ctdb/nodes
CTDB_MANAGES_NFS=yes
＃CTDBクラスターノードのステータスが変更されるたびに実行されるファイル（レターの送信など）
CTDB_NOTIFY_SCRIPT=/etc/ctdb/notify.sh
パブリックアドレスを示します（各サーバー上） ：
# vim /etc/ctdb/public_addesses
192.168.122.200/24 eth0
192.168.122.201/24 eth0
CTDBクラスターのノード（各サーバー上）を指定します 。
# vim /etc/ctdb/nodes
192.168.122.100
192.168.122.101
SElinuxを無効にすると、IPtablesは次のようになります（もちろん、サーバーごとに ）。
# vim /etc/sysconfig/iptables
-A INPUT -p tcp --dport 4379 -j ctdb
-A INPUT -p udp --dport 4379 -j ctdb
-A INPUT -p tcp -m multiport --ports 137:139,445 -m comment --comment "SAMBA" -j SMB
-A INPUT -p udp -m multiport --ports 137:139,445 -m comment --comment "SAMBA" -j SMB
-A INPUT -p tcp -m multiport --ports 111,2049,595:599 -j NFS
-A INPUT -p udp -m multiport --ports 111,2049,595:599 -j NFS
-A INPUT -p tcp -m tcp --dport 24007:24220 -m comment --comment "Gluster daemon" -j ACCEPT
-A INPUT -p tcp -m tcp --dport 38465:38667 -m comment --comment "Gluster daemon(nfs ports)" -j ACCEPT
＃チェーンの名前の代わりに、単にACCEPTを指定できます。
Sambaとsmbcliユーザー（各サーバー）に戻ります。
# useradd smbcli
# chown -R smbcli.smbcli /mnt/glustersmb/pub
最後から2番目のタッチ：
# chkconfig smbd off
# chkconfig ctdb on
# service ctdb start
今、あなたは観察することができます
# ctdb status
Number of nodes:2
pnn:0 192.168.122.100 OK (THIS NODE)
pnn:1 192.168.122.101 OK
Generation:1112747960
Size:2
hash:0 lmaster:0
hash:1 lmaster:1
Recovery mode:NORMAL (0)
Recovery master:0
パブリック移行IPとサーバーに属するIPのリストは、次のコマンドによって取得されます
# ctdb ip
Public IPs on node 0
192.168.122.200 node[1] active[] available[eth0] configured[eth0]
192.168.122.201 node[0] active[eth0] available[eth0] configured[eth0]
SMBまたはNFSプロトコルを使用して、次のコマンドでクライアントをマウントします。
# mount.cifs data:smb /mnt
# mount -o mountproto=tcp,async -t nfs data:smb /mnt
個人的な経験から、私はまだネットワークのドロップをテストしていると言いますが、結果は非常に許容範囲です。 接続の切断はほとんど目立ちません。 すべてがアンドレイキロフを説明する
教育プログラム
別のIPアドレスを引き継いだノードは、古いTCP接続に関する情報のみを知っており、接続の「TCPシーケンス番号」を知りません。 したがって、継続できません。 クライアントと同様に、接続が別のノードに確立されたことを知りません。
接続の切り替えに関連する遅延を回避するために、次の手法が使用されます。 この手法を理解するには、TCPプロトコルの機能の基本原則を理解する必要があります。
IPアドレスを受信すると、新しいノードはACKフラグと明らかに間違った「シーケンス番号」がゼロに等しいパケットをクライアントに送信します。 応答として、クライアントは、TCPプロトコルの規則に従って、正しい「シーケンス番号」でACK応答パケットを送り返します。 正しい「シーケンス番号」を受信すると、ノードはRSTフラグとこの「シーケンス番号」でパケットを形成します。 受信すると、クライアントはすぐに接続を再開します。
素敵なコーディングを！