Hi Karl,

I think you should check out Syncthing too.

Karl Kleinpaste <k...@kleinpaste.org> 于 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@gluster.org
> 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@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users

Reply via email to