You can set up a cluster of Parasoft Virtualize servers to achieve horizontal scaling and fault tolerance. Horizontal scaling is commonly used to optimize performance testing and cloud-based infrastructures for continuous integration and continuous delivery. Fault tolerance is commonly used to increase uptime and/or facilitate disaster recovery for business-critical backend systems.
In this section
Configure your load balancer to route loads to each Virtualize server. If you are using Parasoft CTP or any other tool that interacts with assets through the Virtualize REST API, you will need to perform the additional configuration outlined in the following sections.
The following instructions apply to any load balancer, but we are using F5 Local Traffic Manager (LTM) as an example in order to provide general guidelines on load balancer configuration.
This section describes how to configure source affinity persistence for Parasoft CTP. The same principles can also be applied to configure any other tool that interacts with assets through the Virtualize REST API.
Source address affinity persistence ensures that all calls from CTP are routed to the same node. Session affinity is sometimes called "sticky sessions."
Enable source address affinity persistence for the following ports:
With F5 Local Traffic Manager (LTM), source address affinity persistence is configured by enabling the Match Across Services and Match Across Virtual Servers options. You could, for example, use the default source_addr profile or create a custom profile to enable source address affinity persistence. The following table shows the settings and values for the default source_addr profile.
| Setting | Description | Default Value |
|---|---|---|
| Name | Defines a unique name for the profile. Required. | No default value |
| Persistence Type | Defines the type of persistence profile. Required. | Source Address Affinity |
| Match Across Services | Indicates that all persistent connections from a client IP address which go to the same virtual IP address should also go to the same node. | Enabled |
| Match Across Virtual Servers | Indicates that all persistent connections from the same client IP address should go to the same node. | Enabled |
| Match Across Pools | Indicates that the LTM system can use any pool that contains this persistence entry. | Disabled |
| Timeout | Indicates the number of seconds at which a persistence entry times out. | 180 |
| Mask | Defines the mask the LTM system should use before matching with an existing persistence entry. | 0.0.0.0 |
| Map Proxies | Enables or disables proxy mapping. | Enabled |
Priority-based member activation ensures that all calls from any origin will go to the main machine first (if possible). To configure this, set the first machine as the highest priority. For example, the following is a sample pool configuration file from F5 documentation for Local Traffic Manager:
pool my_pool {
lb_mode fastest
min active members 2
member 10.12.10.7:80 priority 3
member 10.12.10.8:80 priority 3
member 10.12.10.9:80 priority 3
member 10.12.10.4:80 priority 2
member 10.12.10.5:80 priority 2
member 10.12.10.6:80 priority 2
member 10.12.10.1:80 priority 1
member 10.12.10.2:80 priority 1
member 10.12.10.3:80 priority 1
} |
Ensure that the load balancer is configured so that changes are propagated to only one node before configuring Virtualize for load balancing.
git fetch command as a post commit trigger to synchronize sharing.
Add the refresh.enabled=true property, e.g.:
eclipse.preferences.version=1 version=1 refresh.enabled=true |
Restart the server.
-J-Dparasoft.auto.deploy.new=falseDeployments in the Virtualize cluster will eventually synchronize. When a request deploy is sent, a single server processes the request and then returns a response. The file system will notify the other servers in the cluster to make the changes required for consistency. In some cases, this may take several seconds. As a result, there may be a brief time when some servers are not yet aware of a deployment that happened on another server.
Parasoft Data Repositories, which are based on MongoDB, should be configured for clustering by identifying a primary Data Repository (the one that has the data you want replicated) and creating a replicate set. To do this, follow this procedure (taken and modified from the MongoDB documentation):
Start the primary repository server:
./bin/mongod --port 2424 --dbpath repositories |
If the "repositories" directory does not exist, you should create it.
Connect to the mongo shell and create the admin database.
./bin/mongo --port 2424 use admin |
Run the following command to create admin users:
db.createUser({user:"<username>",pwd:"<password>",roles:[{role:"root",db:"admin"}]}); |
If the command fails because the user already exists, run the following command:
db.grantRolesToUser('admin',[{role:"<role>"}]) |
Create your key file. The following example shows the basic commands:
openssl rand -base64 741 > mongodb-keyfile chmod 600 mongodb-keyfile |
Copy the key file to each member of the replica set.
Start each member of the replica set with the following command:
./bin/mongod --replSet "rs0" --dbpath repositories --port 2424 --auth --keyFile <mongodb-keyfile> |
On the primary server, connect to the mongo shell and provide the password when prompted:
./bin/mongo localhost:2424/admin -u <admin_user> -p |
Run the following commands to verify authentication:
use admin
db.auth("<siteRootAdmin>", "<password>"); |
The shell should return 1.
Initiate the replica set with the following command:
rs.initiate() |
Verify your replica set configuration with the following command:
rs.conf() |
If the host for your primary server is incorrect, use the following commands to change the host:
cfg = rs.conf() cfg.members[0].host = "mongodb1.example.net:27017" rs.reconfig(cfg) |
For each secondary server, run the following command in the primary server's mongo shell:
rs.add("<secondary>:<port>") |