[Gluster-users] need input on configuration

[Karl Kleinpaste]

Apologies for the previous incomplete message. It seems an unintended 
Alt-Ret told Thunderbird to send prematurely.  So this time I'm 
composing outside Tbird so that it doesn't get that opportunity.

I'm new to this world and trying to find my way around; I could use a 
bit of advice on how not to bump into corners.  I'm working a contract 
in which the client has one main office plus a remote office with 
inconsistent net.connectivity.  There will also be some very mobile 
laptops, sometimes a long way off and entirely disconnected, but when in 
the office it would be good if the results of whatever they were doing 
while elsewhere would be readily (automatically) imparted to storage 
there.  They have interest in gluster in a probable configuration based 
on a set of 3 servers at the main office and 1 at the remote.  Questions 
arise around how to involve the remote laptops (all Linux).  There is 
not a huge amount of data involved here at the moment, on the order of a 
few Tbytes, but it will surely grow; local concern in the main office is 
redundancy, plus making data available to the remote office + laptops.

The data generation and usage model tends to be that a good amount of 
material is generated, but very local to each user, so that a lot of 
locality is present for who writes where.  But then everybody tends to 
read from everybody else's area.  It's almost like users have a $HOME 
within the volume, and people peruse others $HOMEs frequently.

So far, I'm just playing with configuration, to see what's possible.  At 
the moment, I've defined a 1x3 at the mains plus a 1-node volume at the 
remote. geo-replication is active mains -> remote, but I decided to see 
what would happen if I also set it up in the other direction, remote -> 
mains.  This has had surprisingly good effect, in that anybody using 
either volume gets their content replicated to the other, and everyone 
gets volume access on a local fast network.  An odd downside is that 
geo-rep apparently induces the target volume to go read-only, but I am 
able to turn features.read-only off, it seems persistent, and geo-rep 
continues.

The laptops are a stickier problem especially in being often 
disconnected.  A straightforward-but-dumb solution is to define a 1-node 
volume on a laptop, just to get it involved in the mechanism, and then 
again geo-rep to the mains...and possibly geo-rep the mains back to the 
laptop as well.

Am I taking a wrong turn, or going off a deep end?  Is gluster overkill 
for the entire question?  The choices seem obvious so far, but I'm so 
new that such a level of obviousness also seems to look as much like 
naïvèté.  If anyone might have a sentence or three of observation or 
suggestion about this sort of situation, I'd appreciate it.

--karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20220824/abe5cd0f/attachment.html>