AnsweredAssumed Answered

Using SugarCRM with a distributed file system (GlusterFS)

Question asked by Piotr G on Apr 30, 2018
Latest reply on May 2, 2018 by Piotr G
We are preparing an infrastructure upgrade for one of our clients, currently on SugarCRM 7.9 that will include using two SugarCRM instances with isolated responsibilities.  One of them will be used solely by the end users (via UI) and the other is supposed to handle any API traffic to Sugar REST API which we use with our integrations.  Both instances share the same MySQL database as the data source.  
To guarantee consistency and ease future deployments we intend to employ a distributed file system to host the application files across both of those instances. This will cover the case when the end users would introduce changes to the "UI" instance, which would get seamlessly synced to the "API" instance keeping the functionality consistent across both instances.
Currently we are exploring options with using GlusterFS as the underlaying solution and its 'Replicated Volume' to keep files in sync between the two aforementioned nodes. I am aware of the split-brain hazard, however the "API" instance will not modify any files, changes might come only via a deployment of new code to the "UI" instance or via Studio changes therein. 
Has anyone used Sugar with GlusterFS ? I will very much appreciate anyone sharing their experiences with Sugar on a distributed file system and GlusterFS in particular. Any specific pitfalls to look out for ? Some tips&tricks regarding performance optimization ?
We'd like to prevent cache and uploads from getting replicated from "UI" to the "API" instance, which is easily achievable by changing their path in Sugar config.  However, it's not possible in relation to any other folder or file in the Sugar directory which results in the config.php and config_override.php files getting replicated as well.  As, to my knowledge, GlusterFS does not allow excluding files/folders from replication and ideally we'd want both instances to run on different hostnames.
For now we intend to use test the solution with both of the instances using the same config file ie the same hostname and just re-route the traffic to the appropriate instance by attaching the hostname to a different IP on one of the nodes. Another solution is to just replicate few of the folders within Sugar app directory, so that only the files that might be subject to change will actually get replicated, leaving the core Sugar code, config etc. local to the given instance - but that does not seem like a reasonable solution.
Any help or insight will be greatly appreciated, thanks!
Best regards,
Piotr

Outcomes