6

In GlusterFS, lets say i have 2 Nodes (Servers) on a Volume. Lets say the volume info is something like this:

Volume Name: volume-www

Brick1: gluster-server-01:/volume-www/brick
Brick2: gluster-server-02:/volume-www/brick

From the Client, as we know, we have to mount the volume volume-www by mounting from one Server. Like:

mount -t glusterfs  gluster-server-01:/volume-www  /var/www

I still feel there's a choke point since i am connecting to that gluster-server-01 only.

  • What if it is FAILED?

Ofcourse I can manually mount from another healthy Server again. But is there a smarter way (industrial approach) to solve this?

Vincent
  • 25
  • 2
夏期劇場
  • 1,571
  • 9
  • 22
  • 35

3 Answers3

10

When you are doing this:

mount -t glusterfs  gluster-server-01:/volume-www  /var/www

You are initially connecting to one of the nodes that make up the Gluster volume, but the Gluster Native Client (which is FUSE-based) receives information about the other nodes from gluster-server-01. Since the client now knows about the other nodes it can gracefully handle a failover scenario.

OpenUserX03
  • 216
  • 3
  • 4
3

OpenUserX03's answer is not quite accurate.

When a client connects to a Gluster server node, it receives information about all the nodes. After that, it starts communicating with multiple nodes simultaneously. So when one node dies, it does not "failover", it just lose that node but keep the communication going on with the others:

In their documented note:

The server specified in the mount command is only used to fetch the gluster configuration volfile describing the volume name. Subsequently, the client will communicate directly with the servers mentioned in the volfile (which might not even include the one used for mount).

Yuhao Zhang
  • 131
  • 2
  • So in simpler words, the Client will automatically connect to another online/available Node (from the Pool), which is the great solution by itself? Which is the good thing, we shall say? – 夏期劇場 Apr 06 '18 at 08:39
  • @夏期劇場 Yes. I think this logic is the foundation of GlusterFS's design. But it also depends on how the Gluster volume is setup. For example, if volume is simply a "distributed" type, then the live node won't have the file you need, which is on the failing node only. OP implies the file is wholly replicated on the second node. – Yuhao Zhang Apr 10 '18 at 20:55
  • My experiments don't agree with this. I have a replica:3 volume in a cluster with 6 nodes. When I mount with FUSE, the moment just one of those nodes dies (a random, but specific one) I get an error: Transport endpoint not connected. It sounds exactly as if the client is connected to one node and one only and then when it dies, the client dies as well. Maybe I'm missing some kind of option or...? – Tony Bogdanov Jul 15 '22 at 20:58
-2

You can use two way below:

  1. Use backupvolfile options fstab

server1_name:/media /media glusterfs defaults,_netdev,backupvolfile-server=server2_name,log-level=WARNING,log-file=/var/log/gluster.log 0 0

  1. create data file /etc/datastore.vol example

volume mymedia-client-0 type protocol/client option clnt-lk-version 1 option volfile-checksum 0 option volfile-key /mymedia option client-version 3.8.12 option process-uuid server01.vn-7565-2017/10/03-02 option fops-version 1298437 option ping-timeout 42 option remote-host 192.168.10.79 option remote-subvolume /data01/brick option transport-type socket option transport.address-family inet option send-gids true end-volume volume mymedia-client-1 type protocol/client option clnt-lk-version 1 option volfile-checksum 0 option volfile-key /mymedia option client-version 3.8.12 option process-uuid server01.vn-7565-2017/10/03-02 option fops-version 1298437 option ping-timeout 42 option remote-host 192.168.10.80 option remote-subvolume /data01/brick option transport-type socket option transport.address-family inet option send-gids true end-volume volume mymedia-replicate-0 type cluster/replicate subvolumes mymedia-client-0 mymedia-client-1 end-volume volume mymedia-client-2 type protocol/client option ping-timeout 42 option remote-host 192.168.10.81 option remote-subvolume /data01/brick option transport-type socket option transport.address-family inet option send-gids true end-volume volume mymedia-client-3 type protocol/client option ping-timeout 42 option remote-host 192.168.10.82 option remote-subvolume /data01/brick option transport-type socket option transport.address-family inet option send-gids true end-volume volume mymedia-replicate-1 type cluster/replicate subvolumes mymedia-client-2 mymedia-client-3 end-volume volume mymedia-dht type cluster/distribute option lock-migration off subvolumes mymedia-replicate-0 mymedia-replicate-1 end-volume volume mymedia-write-behind type performance/write-behind subvolumes mymedia-dht end-volume volume mymedia-read-ahead type performance/read-ahead subvolumes mymedia-write-behind end-volume volume mymedia-readdir-ahead type performance/readdir-ahead subvolumes mymedia-read-ahead end-volume volume mymedia-io-cache type performance/io-cache subvolumes mymedia-readdir-ahead end-volume volume mymedia-quick-read type performance/quick-read subvolumes mymedia-io-cache end-volume volume mymedia-open-behind type performance/open-behind subvolumes mymedia-quick-read end-volume volume mymedia-md-cache type performance/md-cache subvolumes mymedia-open-behind end-volume volume mymedia type debug/io-stats option log-level INFO option latency-measurement off option count-fop-hits off subvolumes mymedia-md-cache end-volume volume meta-autoload type meta subvolumes mymedia end-volume vs fstab content:

/etc/datastore.vol /media glusterfs defaults,_netdev,log-level=WARNING,log-file=/var/log/gluster.log 0 0
F10
  • 1
  • 1