The following topic outlines Parasoft's recommendations for a production-grade deployment of Parasoft Virtualize alongside Parasoft Data Repository and Parasoft Continuous Testing Platform (CTP). Sections in this topic include:
This document assumes that the deployment will include:
There are two deployment approaches: dynamic infrastructure (Docker image or Azure VM) or physical static infrastructure.
Dynamic infrastructures are designed for enabling dynamic, disposable test environments. This means that a test environment can be instantly provisioned from a golden template, used and dirtied, then simply destroyed. There is no need to share test environments or resources across teams or test phases; the exact environment you need is instantly spun up whenever you want it, then destroyed as soon as you’re done with it. Dynamic infrastructures provide advanced flexibility for extreme automation. Moreover, when you need to scale (e.g., for performance testing), you can do that on demand.
With a physical static infrastructure, you have permanent (dedicated) servers. This is useful when long-term scaling is anticipated and hardware is designated ahead of time for heavy usage. Such an approach is designed for high availability and fault tolerance requirements. If you have such requirements and plan to configure a cluster of Parasoft Virtualize servers behind a load balancer, also see the recommendations at Setting Up a Cluster of Virtualize Servers Behind a Load Balancer.
Dynamic infrastructures use either Docker Images or Microsoft Azure VMs.
For Docker, we recommend:
For Azure, we recommend:
For AWS, we recommend:
The following diagram shows the recommended architecture for a deployment with 3 Virtualize servers and CTP; note that the "Server n" icons in the lower right corner represent any number of additional servers (as appropriate for your environment).
We recommend the following hardware for the Virtualize, Data Repository, and CTP server machines...
It is recommended to minimize the network latency between a Virtualize server and a Data Repository server as much as possible. Network latency between the processes can negatively impact the performance of the Virtualize server under load, and the most common way users accomplish this is by installing them on the same machine, or two machines that are co-located as much as possible (e.g. same data center region). The Data Repository server can consume a large amount of memory, so when installing it on the same machine as a Virtualize server, it is advised that the machine have at least 32GB RAM. |
We recommend Linux over Windows for Parasoft deployments because:
CTP supports Oracle, HyperSQL, and MySQL, but we strongly recommend Oracle or HyperSQL over MySQL; in a nutshell, our recommendation is
Oracle >= HyperSQL > MySQL |
Oracle and HSQLDB perform equally well, but MySQL is difficult and challenging to troubleshoot. If you do not plan on clustering the CTP database and you have sufficient space, we recommend HyperSQL.
When VMs are deployed in the cloud through cloud service providers, such as Microsoft Azure and Amazon AWS, machine IDs may change as the VM is shut down and restarted. Use the following flag when starting Parasoft products to ensure that the machine ID remains stable when VMs are restarted on cloud platforms:
-Dparasoft.cloudvm=true |