Hi folks, hope I am in the right forum and you guys have ideas or at least pointers.
We are in the process of rolling out a multi-branch-tree-setup.
Top level we have one instance that is hosted on a root server (you could call it trunk or centre-node). Then there are multiple branches (in the end can be hundreds) that consist of groups (units) that have a couple of laptops (1-12) and a NAS that runs a node (let’s call it master-node allthough SC does not know something like that). Each Laptop also runs a node. Each of these branches is deployed on a mobile unit (vehicle) that has sometimes internet connection.
On the trunk we have one folder (let’s call it library) that is deployed read only that shal push the latest version of templates, maps and policy documents to the mobile units in the field.
Then there is a folder for each unit to sync data internal to the unit (let’s call it unit-folder).
Then there are ad-hoc folders for unit to unit sync once the meet in the field (let’s call them mission-folders).
Now, the main idea is that the laptops of each unit are not visible to the other units. They should just be visible inside the unit itself. The master nodes should be visible to the trunk and to other master nodes. This is simply to keep the list of devices you share data with smaller. Otherwise you have to accept hundreds of devices once you share a folder. The master nodes should see each other and also the centre-node.
Also, in the end, allthough we don’t want to see all those laptops, the goal is especially for the libraryl to sync ideally from as many visible machines at the time to make max use of p2p technology. It seems though that we would have to live with that basically only the unit node gets updates and then forwards them to inside the unit. Not so nice; in Resilio Connect this is much smoother.
The problem is that we have not yet figured out how we can prevent for example the Unit04-node to present it’s known laptops to the other unit-nodes. This can become very anoying when you have hundreds of devices in the field.
So how to prevent this? Does our concept even work?
In your shoes my first step would be a design document incdicating the use cases, with diagrams and tables. Ideally your documentation could be used by someone who is not you to maintain the infrastructure.
With that said, I’m not entirely sure what you’re trying to accomplish here.
You want to use Syncthing on what you refer to a “root server” (note, Syncthing is peer-to-peer), some “branches”, and each connected to some laptops. Your intention, I think, is to have one or more shared Folders from the “root server” to the “branches” and then to the laptops, along with other Folders that are only synced between the “branches” and the laptops. Is that right?
My recommendation would be to manually configure the Folders and peers on the “root server” to connect only to the “branches” with those Folders that need to be shared out, and do the same for each “branch” to the laptops. Use Send-Only and Receive-Only folders as appropriate.
Thanks, actually I have a design document but since it is in the area of incient response / catastrophy releif I would not want to make that public. However, we can just concentrate on the first use case which is the onway replication of the “library”.
When I said “root server” I was indicating that this node is in a datacenter and hence available 24/7 while other nodes can be online/offline depending on connectivity and also if the unit is active or not. Some units are active multiple days a week, some are actvie 2 days a month to give you a bit background.
Yes, you are right in your interpretation. The flow would be centre=>branch=>laptop (or technically: node on server in datacenter => mobile NAS => Unit Laptop).
This goes back to the issue of how peer2peer sync setup is modeled in Syncthing: as I understand, you basically have to accept incoming requests to sync a folder client by client individually. As I understand, you can set up auto-accept, but that means that you accept everything from the introducer. That would mean that everly Laptop sees in the end every NAS and every other Laptop. This is just a bit much to handle, if you think about a rollout of 100 units (total in the end would be about 2.500 untis with about 6.000 devices).
Allthoug this would be best from the p2p benefits point of view, it would just be not usable for the IT person of a unit. Instead of seeing the devices of his unit he would se hundreds and hundreds of devices. This is why I was thinking to link all branches (NAS) P2P and then link inside the branch P2P (latops to laptops and to NAS).
Now my main question is: how do I make use of introducers so that a branch introduce other branches to a new branch but they don’t introduce the devices of their branch to this new branch other branches? Is this even possible? Or would I have to basically have to create 2 sync shares on the same folder, one for internal sync and one for external sync?
a branch introducer (on a branch NAS) does not introduce it’s devices to other branches (NAS’s and centre) but that new folders
I don’t see a way to configure Introducers that way.
My recommendation would be to script the deployment of the laptops, by either customizing the config.xml file for each deployed Device, or using command-line/API.
Another option would be to use some other method of syncing files from the “root” to the “branches.”