SugarCRM Diagram: Multiple Server Deployment (Basic)

A few weeks ago we looked at an example of a very basic topography one can use to deploy Sugar 7. Along the way we also looked at the advantages and disadvantages of such configurations. Today we will look at a slightly more complicated setup.

The diagram below illustrates a deployment implemented across multiple servers. While there are many variations to this concept, the one illustrated in this diagram is the most basic.

Sugar 7.x Multiserver Deployment

You will notice there are three different servers in use by this model. Despite this fact, all SugarCRM users only directly access one of those servers, the web server.

This is an important point, as it directly affects the security of the system. Using a multiserver configuration similar to that depicted in the image above allows us to limit access to the Elasticsearch and MySQL servers to only the web server. Those restrictions can be easily implemented through firewall rules.

Because Elasticsearch is completely open -- does not require any sort of authentication -- limiting access to the server and its contents is crucial, or you may accidentally expose a portion of your SugarCRM data to anyone that happens to know the address of your Elasticsearch server.

In addition, distributing the load across multiple servers helps improve performance and scalability, especially when compared to a single server topology.

To summarize, lets look at both sides of the coin on using this type of configuration.

PROS:

Enhanced security. As described above, the ability to limit access to the Elasticsearch and MySQL servers provides us an additional measure of protection against would be snoops and hackers. 

Performance and scalability. The Sugar application requires three functioning components: web server, database server and search server. Distributing the work each of these components has to perform across multiple servers allows us to support larger user loads and offer improved response times.

Distributed failure points. Unlike a single server deployment, a failure at one server does not necessarily mean the entire system goes down. For example, if Elasticsearch goes down, Sugar will continue to operate. It also opens the door to compensate for other possibilities, such as the web server going down, which can be easily addressed by using multiple web servers.

CONS:

Cost. More servers means more money. Given the importance of data held in CRM systems such as Sugar, the costs are easily justified, but nevertheless, it is perhaps the most often discussed obstacle.

Complexity. While not difficult, defining firewall rules to properly configure connectivity between the various servers may prove to be a bit complex for those without expertise in the matters of network security. This may in turn require you to hire someone to assist with the configuration.

Limited fault tolerance. Although this model distributes the load across multiple servers, it is not ideal for high availability needs as it lacks redundancy. 

Summary:

With a few changes to the single server model we are able to introduce greater scalability enhance the security of Sugar. However, for more demanding environments, we need to adopt redundancy, which we will discuss in a future post.