Difference between revisions of "Adding Additional Application Servers"

From AgileApps Support Wiki
imported>Aeric
imported>Aeric
Line 1: Line 1:
=== Adding Additional LongJump Servers ===
=== Adding Additional Application Servers ===


Adding additional instances of LongJump can help to load balance traffic and improve performance.
Adding additional instances of the platform 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.  
::* Any backend service settings specified in the [[installation.properties]] file are ignored.  
::* 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.
::* 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 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.
:* '''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.


====Overview of the Process====
====Overview of the Process====

Revision as of 17:48, 7 June 2011

Adding Additional Application Servers

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.
  • Any backend service settings specified in the installation.properties file are ignored.
  • Since it's not possible to enable selected backend services during the install, they will need to be Manually Configured after the install.
    Note: 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. Download the installable file on the new server.
  3. Extract the Installable file.
    The longjump_app_server folder is created.
  4. 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 JAVA_HOME points to the JVM.
    • Make sure mysql_host 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.
  5. By default, all services are disabled in the installation.properties file, except quartz. Unless quartz will be running on the new server, make sure it is disabled.
  6. 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.
  7. Run ./configure.pl to start the installation.
  8. Manually Configure Backend Services that will be running on the new server:
  9. Manually Configure Backend Services on the original instances, as needed, and bring them back up.