Difference between revisions of "Cluster Deployment"

From AgileApps Support Wiki
imported>Aeric
 
(28 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<includeonly>===Prototype Deployment===</includeonly>
<includeonly>===Prototype Deployment===</includeonly>
The following diagram shows the kind of architecture that is typical for a production system:
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.


[[File:prototype_deployment.png]]
::::::::'''Architecture for pre-10.16 Release'''
:[[File:PrototypeProductionInstallation.png]]
 
<br>
:::::::::'''Architecture for post-10.16 Release'''<br>
[[File:agileapps_clustersetup.png|800px]]
 
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. <br/>''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. <br/>''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.<br/>''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.<br/>''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.<br/>''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.<br/>''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.


The key points depicted in the diagram are:
:* The platform is deployed across multiple servers.
:* A Load Balancer distributes traffic across the web servers.
:* Apache <tt>httpd</tt> is an optional front-end web server for the application server.<br/>''Learn more:'' [[Installing and Configuring Apache for Use with the Platform]]
:* The Messaging server handles all social media interactions (e.g. Facebook and Twitter).
:*: Messages are exchanged between it and the application server, to manage those interactions.
:*: HornetQ maintains the store-and-forward message queue, for those communications.
:*: ''Learn more:'' [[Configuring the Messaging Server]]
:* Memcached servers reduce response time by caching data in memory.<br/>''Learn more:'' [[Configuring memcached]]
:* The suite of memcached servers are accessed by all application servers, backend as well as front end.
:* The critical backend processes shown here (<tt>import</tt>, <tt>export</tt>, and <tt>scheduling</tt>, which uses <tt>quartz</tt>) are all being run from a single platform instance. But additional servers can be employed, as load demands.<br/>''Learn more:'' [[Managing Backend Services]]
:* Document storage (which includes pictures and image files) is managed separately from the database.
:* The database is running on its own server, for added performance.<br/>''Learn more:'' [[Configuring MySQL to Run on a Separate Server]]
:* The primary database instance and the replication instance are each running on separate servers, both for reliability and for performance of read-intensive operations.<br/>''Learn more:'' [http://dev.mysql.com/doc/refman/5.1/en/replication-solutions-diffengines.html Using Replication with Different Master and Slave Storage Engines]
:* Requests that access and update, whether coming from a user or a backend process, go to the primary database, while read-intensive operations (backups, reports, exports) are executed on the replicated database.<br/>''Learn more:'' [[Running Reports and Storage Checks On a Replicated Database Server]].
<noinclude>
<noinclude>


[[Category:Installation]]
[[Category:Installation]]
</noinclude>
</noinclude>

Latest revision as of 09:22, 9 May 2024

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
PrototypeProductionInstallation.png


Architecture for post-10.16 Release

Agileapps clustersetup.png

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.