Documentation Center

Clustered mode planning

WorldServer was designed to run in a clustered mode with multiple application servers accessing a shared database. Clustering provides almost linear scalability on the application server side as long as the database power is sufficient. For scalability, SDL recommends running a clustered application server configuration with each system having less CPU power, rather than a single application server on a powerful CPU system. As the demand grows, you can add server systems to accommodate possible growth in application load.

Cluster setup provides many benefits over a standalone configuration:
  • Performance – Spreading the load across multiple machines can greatly improve the responsiveness of the system and the overall user experience.
  • Redundancy – A WorldServer cluster does not have any single point of failure (except for the database). If a node in the cluster goes down, the service continues uninterrupted, by switching requests to other nodes. WorldServer is a stateless application—the user state is kept either in the database or on the client—and if a node goes down, another node can continue the user session without a need to log in again and without any data loss.
  • High availability – Because taking down a node does not interrupt the service, hardware maintenance can be performed on one node at a time without service interruption.
  • Specialization – The cluster can be specialized, based on your particular needs. For example, if your process involves a lot of automatic processing, extra hardware can be allocated for automatic task processing. If you experience a lot of user interaction, then additional hardware can be used to boost user interface serving (front-end) machines.

Clustering can include multiple WorldServer instances on a single machine (vertical clustering) or multiple instances spread across different machines (horizontal clustering). A mix of vertical and horizontal clustering is possible. SDL recommends putting no more than two WorldServer instances per CPU. For example, a dual CPU box should not run more than four WorldServer instances, or performance might decrease.

SDL does not provide any software to implement a cluster. You can build a cluster using a Tomcat application server by simply installing multiple Tomcat instances and managing them separately. You can use the Apache Web server load balancer plug-in in this configuration. Commercial application servers have built-in facilities for creating and maintaining a cluster. You can stop and start nodes, upgrade them at the same time, and monitor their performance.

Clustered WorldServer deployments are designed to handle thousands of assets, translation memories of millions of words, and multiple projects going through WorldServer at the same time. They require more server and respository capacity and usually include load balancing capabilities and multiple machines.

In a cluster, certain configuration parameters must be shared across all the nodes, while others can be configured differently to allow for node specialization. Shared parameters include:
  • Database – All instances must connect to the same database instance using the same credentials (user/password).
  • Temporary directory – All instances must point to the same shared filesystem for temporary directory (the temp_file_path property in general.properties).
  • RCS directory – If built-in version control is in use, the RCS directory must also be located on a shared filesystem.
  • Additional configuration files (translation memory, terminology database, sentence breaking, and import/export properties files) must be the same across all instances.
Other configuration parameters can be configured differently between the nodes:
  • Log file location and log level – Each node can have a separate log file.
  • Number of workflow engines – Each node can run zero or more workflow engines, depending on its role in the cluster.
  • Whether the rules engine is on or off – Each node may or may not run a rules engine thread.
  • Notification engine – Each node may or may not run a notification engine.

Setting up clustered workflow and background processing engines

In a generic WorldServer setup, a single WorldServer instance is used for the following purposes:

  • It serves the application GUI that users interact with to create new projects, upload translation kits, modify new documents, or modify workflows.
  • It serves the workflow engine that executes the defined workflows.
  • It serves the background processing engine for any jobs that are submitted for background processing.

In a larger installation, to improve performance, we recommend that you separate these activities, assigning them to one or more machines. Specifically, we recommend that you create one or more dedicated WorldServer application machines, one or more dedicated business processing (workflow engine) machines, and one or more background processing machines.

The primary benefit of this split is that you can provide adequate response times for each of the WorldServer tasks. Workflows, for example, may consume large amounts of CPU power. If the workflow engine is on the same machine as the WorldServer application, it can result in a performance decrease on the application server. Similarly, if your organization submits large jobs for background processing, response time can degrade. Separating the WorldServer application, the workflow engine, and the background processing engine allows you to eliminate this sort of resource contention.

In addition, separating the activities allows you to independently scale the resources assigned to each. For example, you might start with three machines, each dedicated to one of the three main activity areas. As more background processing occurs, you might add more machines dedicated just to one area.

Controlling application access

There is no specific setting to turn off the application portion of WorldServer. In particular, you are likely to want the ability to log in to the WorldServer instances of worfklow and background-processing machines to monitor jobs, configure logging settings, and so on. The best way to ensure that these machines are not used as general-purpose WorldServer application machines is to simply not give your users access to them. For example, if you have inserted a load balancer in front of the WorldServer application machines, do not include the dedicated engines in the list of machines over which you balance end-user requests.