I think you should check out Syncthing too.
Karl Kleinpaste 于 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.
> 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
Community Meeting Calendar:
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
Gluster-users mailing list