SugarCRM files and cache shared by multiple instances

Hello,

As a starting point, I would recommend a review of our Sizing Guide documentation. While this won't answer the exact questions or scenario you've presented, it does provide an overview and information that is helpful to ensure that an on-premise deployment will be successful and performant.

Without going too deep into specifics, I can confirm how some things work behind the scenes in Sugar's cloud for '*.sugarondemand.com' and '*.sugaropencloud.eu' instances:

A file system exists on the servers for each version and flavor, such as 8.0.0 Enterprise. This file system acts as a template. Each instance of Sugar hosted in our cloud also has what we sometimes refer to as a 'front-end' file system. This includes and is limited too only those directories and files that are unique to each instance. Here are a few examples of files we expect to see in the 'front-end' file system:

config_override.php

config.php

sugarcrm.log

custom/

cache/

The cache/ directory is unique to each instance because any customizations, both Module Loader packages and Studio created, can modify files that are rolled up into the cache/ directory.

With this information in mind, let's revisit your outlined configuration:

For our client we are building a solution that will consist of 2 SugarCRM nodes. We intend to share the full Sugar application folder from one instance to the other via NFS, so that they use a consistent file base.

This is close enough to what we do in the cloud environment that I felt it made sense to explain how we do things, from a high level, before continuing. So far so good.

This will involve sharing the CACHE folder as well. Can this be a problem ? 

Yes, each instance does need to have a unique cache/ directory to ensure proper operation, especially if the instance will have slightly different customizations, modules, etc.

Only one of the two instances will be available for doing Studio changes or Quick Repair & Rebuild. The other instance will only be interacted with via the REST API. Both instances will share the same database.

With these items in mind, I don't think you actually need two separate instances. Studio operations would not have a direct impact on web service requests, aside from which fields are available.

If both instances would be sharing a database, User Interface and web service requests will essentially be the same, because we use the REST API to perform all operations in the UI. Utilizing the web services to perform CRUD operations (Create, Retrieve, Update, Delete) on the same database as an instance where Users login and interact with the Sugar UI eliminates the need for a wholly separate 'instance'.

Sugar's User Interface can be modified on a per-User basis to restrict access to modules and operations via Role Management and Team Management. Web Service operations also adhere to the Roles and Teams settings.

If you have any additional details you can share, that may be helpful for providing a more comprehensive Pros/Cons list for deploying multiple 'instances'.

Regards,

Dan Kallish

Advanced Support Engineer

SUGARCRM

Learning Resources: http://support.sugarcrm.com | http://university.sugarcrm.com | http://community.sugarcrm.com

Hey there Dan Kallish 

Thanks a lot for a very detailed answer,  especially the part where you outline "how things are done" on Sugar On Demand.

For the brevity of things I tried asking a very specific question and I have the impression that I missed some of the important context, hence your answer is a little bit off side in regards to what we anticipated to find out. My bad.

Let me quickly recap some of the most important aspects of the situation on our end. 

1. Currently we have a single Sugar instance (7.9) hosted in the client's infrastructure. 
2. The instance is live in production, has quite a lot of customizations and we often deploy new features. 
3. The instance is governed by the client so they do use Studio to further tailor the system to their needs.
4. The instance is a part of a larger ecosystem and there are some integrations in place that interact with Sugar via the REST API. That happens every few minutes (CRON) and often is read/write intensive. 
5. During the time when the integrations are consuming the REST API a performance impact "slows down" the instance looking from the perspective of end-users interacting with the instance via the UI - at least that is what the client is worried about.
6. The client requested that we clone the instance so that we will have two copies of Sugar, one for the end-users to interact with via UI (let's call it the UI instance), the other solely for the purpose of API integrations (let's call it the API instance). Both instances will be IDENTICAL in regards to installed modules, customizations etc.  
7. The client rejected our suggestion to use a standard load-balanced setup, the isolation is supposed to be "static". 

Now let's review what basic challenges does such an isolation of instances introduce if we do not somehow "sync" the codebase - please correct me if I'm wrong here: 

1. Regular deployments would need to be done "off line" and twice, so that both of the instances have the same updated codebase and there are no inconsistencies introduced between the first and second deployment. 
2. Transmitting Studio customizations from one instance to the other would be cumbersome. 
3. Sugar version upgrades would also become more complex.

This brings us to the final concept of dealing with the three problems mentioned above - the one that I described in my original post. 

1. Configuring logging so that the sugarcrm.log file is put outside of the Sugar application folder 
2. Sharing the whole Sugar application folder from the UI instance to the API instance via NFS.
3. We don't mind having the config files shared as both of the instances use the same database and having the same siteurl is not a problem as we would just route the hostname to a proper IP on one of the nodes.

Taking all of the above into account - is it safe to share the WHOLE Sugar application folder in such fashion? Can having a shared CACHE folder between both of the instances cause problems at runtime ? 

I'm looking forward to your reply to the above CACHE question and any additional comments, remarks or advise is most highly welcome and appreciated! 

Best regards,

Piotr 

cc: Matt Marum Joseph Arruda André Lopes

Sharing the whole Sugar application directory between web servers is the usual approach. I've also seen separation of front-end web servers from those that drive APIs. Our biggest on-site deployments do this.

Keep in mind that you'll only want CRON running on one web server at a time. Sometimes this is deployed on it's own dedicated web server too.

You want to have the cache directory shared across those servers. You can't allow it to be out of sync between web servers.

This question recently came up again. My recommendation hasn't changed since the way Sugar interacts with the filesystem hasn't really changed much in 7 years. It's safest to share the filesystem including the cache directory across the multiple web servers for on-premise Sugar deployments.

This question recently came up again. My recommendation hasn't changed since the way Sugar interacts with the filesystem hasn't really changed much in 7 years. It's safest to share the filesystem including the cache directory across the multiple web servers for on-premise Sugar deployments.