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 is powerful enough.
For scalability, you should run 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.
- 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 needing to log in again and without losing data.
- High availability – Because taking down a node does not interrupt the service, you can perform hardware maintenance 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, you can allocate extra hardware for automatic task processing. Also, you expect considerable user interaction, use additional hardware to boost 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). You can also have a mix of vertical and horizontal clustering. You should not put more than two WorldServer instances per CPU. For example, a dual CPU box should not run more than four WorldServer instances; otherwise, performance might decrease.
WorldServer does not come with any separate software to implement a cluster. You can build a cluster using a Tomcat application server by installing multiple Tomcat instances and managing them separately. In such a configuration, you can use the Apache web server load balancer plug-in. 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.
- Database – All instances must connect to the same database instance using the same credentials (user name and password).
- Temporary directory – All instances must point to the same shared file system for the temporary directory (the
temp_file_pathproperty in the general.properties file). - Revision control system (RCS) directory – If you are using built-in version control, the RCS directory must also be located on a shared file system.
- Any additional configuration files (.properties files that include configurations for translation memories, terminology databases, sentence breaking, and import/export) must be the same across all instances.
- The log file location and log level – Each node can have a separate log file.
- The 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.
- The 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, you use a single WorldServer instance for the following purposes:
- For the user interface that users interact with to create new projects, upload offline work, or modify workflows.
- For the workflow engine that executes the defined workflows.
- For the background processing engine for any jobs that are submitted for background processing.
In a larger installation, to improve performance, you should separate these activities, assigning them to one or more machines. Specifically, you should 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. By separating the WorldServer application, the workflow engine, and the background processing engine, you can eliminate this sort of resource contention.
In addition, by separating these activities, you can also 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 to log in to the WorldServer instances of workflow 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.