Cluster Deployment

The following diagram shows the kind of architecture that is typical for a production system pre-10.11 release and post 10.11 release. With the 10.11 release, AgileApps uses the common Tomcat that comes along with the IS installation and does not use the stand-alone Tomcat anymore. This allows AgileApps access to the flow services on the co-hosted IS. The following images allow you to identify the difference in the architecture for pre and post 10.3 release.

Architecture for pre-10.16 Release

Architecture for post-10.16 Release

The architecture is explained as follows:

• Node 1 and Node 2 are the AgileApps server instances available in the front-end.
• Node 3 serves as the backend AgileApps Server instance. The critical backend processes shown here (import, export, and scheduling, which uses quartz) are all run from a single platform instance. However, you can employ additional servers, as load demands.
  Learn more: Managing Backend Services.
• Document storage (which includes pictures and image files) is managed separately from the database. In the example above, it is housed as part of the backend server instance. The Document storage communicates with all the nodes.
  Learn more: See the Document Server section in Service Provider Settings.
• The user logs into AgileApps and the request comes to the Load Balancer which distributes the traffic across the web servers.
• The web server can be an Apache server or an Nginx server.
  Learn more: Installing and Configuring Apache for Use with the Platform.
• A Memcached server reduces response time by caching data in memory. Memcached servers are accessed by all Application servers, backend as well as front-end.
  Learn more: Configuring memcached
• All the nodes are connected to the primary database server. The primary database is running on its own server for better performance. It can also reside within one of the nodes VM1 or VM2 along with the AgileApps server. The database could be MySQL, Amazon RDS, or so on.
  Learn more: Configuring MySQL to Run on a Separate Server
• The replicated database is running separately on its own server. This ensures more reliability and for performing read-intensive operations like taking backups, generating reports, and exporting data.
  Learn more: Running Reports and Storage Checks On a Replicated Database Server.
• Requests that access and update the database, whether coming from a user or a backend process, go to the primary database server.