Hi Karl,
I think you should check out Syncthing too.
Karl Kleinpaste <karl@xxxxxxxxxxxxxx> 于 2022年8月24日周三 20:21写道：
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
Community Meeting Calendar:
Schedule -
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
Bridge: https://meet.google.com/cpu-eiue-hvk
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-users
________ Community Meeting Calendar: Schedule - Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC Bridge: https://meet.google.com/cpu-eiue-hvk Gluster-users mailing list Gluster-users@xxxxxxxxxxx https://lists.gluster.org/mailman/listinfo/gluster-users
