Difference between revisions of "Adding Additional Application Servers"

From AgileApps Support Wiki
imported>Aeric
imported>Aeric
 
(10 intermediate revisions by the same user not shown)
Line 1: Line 1:
=== Adding Additional LongJump Servers ===
<includeonly>=== Adding Additional Application Servers ===</includeonly>
 
Adding additional instances of the platform can help to load balance traffic and improve performance.
Adding additional instances of LongJump can help to load balance traffic and improve performance.


====Considerations====
====Considerations====
:*'''Paths:''' It’s a good practice to use the same paths for LongJump installation folders and files on each server.
:*'''Paths:''' It's a good practice to use the same paths for platform installation folders and files on each server.
:*'''Distribution of backend services:''' Running backend services on different servers can help to balance the load. For example, the Report, Bounce, and Import services can run on one server, while and the rest of the services run elsewhere.
:*'''Distribution of backend services:''' Running backend services on different servers can help to balance the load. For example, the Report, Bounce, and Import services can run on one server, while and the rest of the services run elsewhere.
::''Learn More:'' [[Enabling and Disabling Backend Services]]
::''Learn More:'' [[Enabling and Disabling Backend Services]]
:*'''Single-instance services:''' Each backend service should run on only one server. It is therefore important to ensure that no service is enabled on more than one server.  
:*'''Single-instance services:''' Each backend service should run on only one server. It is therefore important to ensure that no service is enabled on more than one server.  
:*'''An additional install behaves like an upgrade:''' When the installation process finds that the database already exists, it does an "upgrade", rather than a "fresh install". That consideration has several implications:
:*'''An additional install behaves like an upgrade:''' When the installation process finds that the database already exists, it does an "upgrade", rather than a "fresh install". That consideration has several implications:
::* The version of LongJump installed on the new server must match the version installed on the existing servers. Otherwise, the database will be automatically upgraded, and the existing instances will find that they can no longer access the database.
::* The version of the platform installed on the new server must match the version installed on the existing servers. Otherwise, the database will be automatically upgraded, and the existing instances will find that they can no longer access the database.
::* Any backend service settings specified in the [[installation.properties]] file are ignored.
::* It is necessary to [[Configure Backend Services]] after the install.<br/>(If the service is already running on an another server, you should [[Enabling and Disabling Backend Services#To Disable a service|Disable the Backend Service]] first.)
::* Since it's not possible to enable selected backend services during the install, they will need to be [[Manually Configuring Backend Services|Manually Configured]] after the install.<br/>''Note:'' If the service is already running on an another server, you should [[Enabling and Disabling Backend Services#To Disable a service|Disable the Backend Service]] first.
:* '''Quartz is enabled on every install:''' The Scheduler service is required for platform operations, so it is enabled on every install, whether it is a fresh install or an upgrade. In consequence, you should [[Enabling and Disabling Backend Services#To Disable a service|Disable the Service]] on the existing server, before doing the new install.
:* '''Quartz is enabled on every install:''' The Scheduler service is required for LongJump to run, so it is enabled on every install, whether it is a fresh install or an upgrade. In consequence, you should [[Enabling and Disabling Backend Services#To Disable a service|Disable the Service]] on the existing server, before doing the new install.


====Overview of the Process====
====Overview of the Process====
Line 22: Line 20:
====To Install an Additional Instance====
====To Install an Additional Instance====
# Disable all services on the original server(s).
# Disable all services on the original server(s).
# Download the installable file on the new server.
# [[Installing a New Application Server|Install the platform]] on the additional servers.
# Extract the Installable file.<br/> The <tt>longjump_app_server</tt> folder is created.
# Refer to the existing [[installation.properties]] file and use the same environment-variable values in the new server. (Do not use the same values for backend services.) For example:
#* Make sure <tt>JAVA_HOME</tt> points to the JVM.
#* Make sure <tt>mysql_host</tt> points to the database server IP-address.
#* If there are multiple memcached servers, the list of servers should be identical, and in the same order, on all of the LongJump servers.
# By default, all services are disabled in the <tt>installation.properties</tt> file, except quartz. Unless quartz will be running on the new server, make sure it is disabled.
# Verify database connections:
# Verify database connections:
#* Make sure the database server can be accessed from the new server.
#* Make sure the database server can be accessed from the new server.
#* Verify the login credentials to the database server from the new instance.
#* Verify the login credentials to the database server from the new instance.
# Run <tt>./configure.pl</tt> to start the installation.
# [[Configure Backend Services]] that will be running on the new server.
# [[Manually Configuring Backend Services|Manually Configure Backend Services]] that will be running on the new server:
# Make the corresponding adjustments to the backend-services configuration on the original instances.
# [[Manually Configuring Backend Services|Manually Configure Backend Services]] on the original instances, as needed, and bring them back up.
# Start/restart all servers.
<noinclude>
 
[[Category:Installation]]
</noinclude>

Latest revision as of 23:01, 21 September 2015

Adding additional instances of the platform can help to load balance traffic and improve performance.

Considerations

  • Paths: It's a good practice to use the same paths for platform installation folders and files on each server.
  • Distribution of backend services: Running backend services on different servers can help to balance the load. For example, the Report, Bounce, and Import services can run on one server, while and the rest of the services run elsewhere.
Learn More: Enabling and Disabling Backend Services
  • Single-instance services: Each backend service should run on only one server. It is therefore important to ensure that no service is enabled on more than one server.
  • An additional install behaves like an upgrade: When the installation process finds that the database already exists, it does an "upgrade", rather than a "fresh install". That consideration has several implications:
  • The version of the platform installed on the new server must match the version installed on the existing servers. Otherwise, the database will be automatically upgraded, and the existing instances will find that they can no longer access the database.
  • It is necessary to Configure Backend Services after the install.
    (If the service is already running on an another server, you should Disable the Backend Service first.)
  • Quartz is enabled on every install: The Scheduler service is required for platform operations, so it is enabled on every install, whether it is a fresh install or an upgrade. In consequence, you should Disable the Service on the existing server, before doing the new install.

Overview of the Process

  1. Disable conflicting services on the original server(s). (In particular, Quartz which will always be in "conflict".)
  2. Install the new server.
  3. Manually configure backend services it will be hosting.
  4. Manual configure changes to the original server(s), as needed, and restart them.

To Install an Additional Instance

  1. Disable all services on the original server(s).
  2. Install the platform on the additional servers.
  3. Verify database connections:
    • Make sure the database server can be accessed from the new server.
    • Verify the login credentials to the database server from the new instance.
  4. Configure Backend Services that will be running on the new server.
  5. Make the corresponding adjustments to the backend-services configuration on the original instances.
  6. Start/restart all servers.