Dedicated IP addresses
This topic describes how to obtain and view dedicated IP addresses for cloud-based load generators, or for LRC (OpenText Core Performance Engineering) runtime components when using on-premises load generators or other LRC agents that are behind a firewall.
Runtime control components
Runtime control components (RTC) are a set of components dynamically created for each load test that manage the scheduling, results (aggregation and storage), and communication between all the components involved in the load test.
Use cases
Dedicated IP addresses are required for the following use cases:
-
Dedicated IP Addresses for CLGs (cloud load generators): You are using cloud load generators and your application under test (AUT) is behind a firewall. For details, see Dedicated IPs for CLGs - AUT behind a firewall.
-
Dedicated IP Addresses for LRC Run Time Components (RTC): - You are using on-premises load generators or other OpenText Core Performance Engineering agents that are behind a firewall. For details, see Dedicated IPs OPLGs behind a firewall.
Note: 10 Freemium dedicated IPs are provided at no cost. To request access to them, submit a service request. You can purchase additional dedicated IPs from OpenText through your account manager or sales representative.
Dedicated IPs for CLGs - AUT behind a firewall
If your AUT is behind a firewall, you can add the dedicated IP addresses of the CLGs (cloud load generators) to your firewall, in order to allow OpenText Core Performance Engineering to access the AUT. OpenText can provide the dedicated IPs that you need to add to the firewall as described below.
Expand the graphic to see how dedicated IP addresses enable cloud-based load generators to communicate with an AUT behind a firewall.
You can allow IP addresses for OpenText Core Performance Engineering cloud-based load generators on your firewall, through one of the following methods:
-
Dedicated IPs (recommended)
- IP ranges
- Elastic IPs
OpenText can dedicate IP addresses for you in the supported AWS, Azure, or GCP cloud locations. To determine the required number of IP addresses to be dedicated, submit a request that includes the information described in step 1 below.
The number of IP addresses required for each region depends on your testing requirements. It is primarily dependent on the maximum number of Vusers configured to run on a single cloud load generator per protocol.
To help the Operations team determine the number of IPs that need to be dedicated, it is highly recommended to include the following information your request:
-
Define the parameters of your test:
Parameter Description Vusers type Type of Vusers (API, UI). Vuser number The maximum number of Vusers for the test. Distribution The regions to which you want to distribute Vusers. Example Request:
Expiry Date (optional) Location Vusers Vuser Type April 17 Virginia 500 UI April 17 Virginia 1000 API April 17 The Netherlands 6000 API April 17 Singapore 2000 API -
You can request an expiry date for the dedicated IPs, or request that they be dedicated for the duration of your contract.
-
In your service request, state whether these IP addresses are required to enable communication between LRC on-premises load generators or agents with LRC runtime control components.
-
You can also submit a request for the specific number of IP addresses that you want allocated to your tenant in specific regions. We recommend that you only do this if you are sure of the amount of IPs you need in each region. We strongly recommended that in any case, you provide the information about your test requirements so that we can verify that the appropriate amount of IP addresses are allocated in the requested regions. For details, see Vuser load distribution.
-
If you plan to generate single user performance data, request an additional IP address. This IP address should be in the same region in which the majority of Vusers for the test are run.
-
-
Submit a service request (select New Ticket > Tenant management > Assign and/or release Dedicated IP addresses):
-
Send your request for dedicated cloud-based load generator IP addresses at least one week before the planned test run.
-
In the request, include the test parameters you defined above.
After the cloud-based load generator IP addresses are assigned to your account, support updates the ticket with these addresses.
-
-
Use the dedicated cloud-based load generators in your load tests.
After dedicated IP addresses have been assigned to your tenant, by default OpenText Core Performance Engineering only uses the cloud-based load generators on the dedicated IPs. If you want to use non-dedicated cloud-based load generators for a specific test, you must deactivate Dedicated IPs for that test. To do this, go to the load test's Test settings tab and select Do not use dedicated IPs for cloud load generators. For details, see Load generator settings.
Note:
- The option in the Test settings tab is only available if dedicated IPs have been assigned to your tenant.
- When you deactivate the Do not use dedicated IPs option, it is only unavailable for that current test.
Another way to allow IPs of CLGs on your firewall, is to obtain ranges of IPs for the respective regions from the cloud provider, such as AWS, Azure, or GCP. Through the cloud provider, you get a range of IP addresses for the regions you are using in your load test distribution. You can then allow entire ranges of IP addresses on your firewall. This allows incoming data from any IP address in that range to pass through your firewall. With this method, you are not using the IP addresses which were dedicated by OpenText for your account, but rather public IP addresses provided by the cloud provider.
Caution: This method is less secure than obtaining specific dedicated IP addresses from OpenText, as you are opening your firewall to a much larger number of public IP addresses, many of which are not used in your load test.
An additional option is to use obtain elastic IPs for cloud load generators, that are dynamically provisioned by OpenText Core Performance Engineering for load tests. Using this method, you apply a delayed start to your test, allowing you to obtain and allow elastic IPs for cloud-based load generators in your firewall.
To use the elastic IPs:
- Create a load test with a delayed start. In the Load tests > Load profile section of your test definition, define the start time of all your scripts to give you enough time to add the IP addresses to your firewall. For details, see Create a load test.
-
Get the elastic LG IPs:
- Open the Dashboard or Report pane.
- Select the More options button in the pane's toolbar and choose Export / Download > LG IPs.
- Manually allow these IPs in your firewall.
- Run the load test.
Dedicated IPs OPLGs behind a firewall
This section describes how to use dedicated IPs for OpenText Core Performance Engineering runtime control components when using on-premises load generators and LRC agents behind a firewall.
On-premises load generators or other OpenText Core Performance Engineering agents behind a firewall, or a proxy that requires SSL validation, must be able to communicate with the LRC application (see note below) and the LRC runtime control components in the cloud. LRC uses self-signed certificates and two-way TLS for communicating with the LRC runtime control components, which is made over https through port 443.
Note: You can copy the OpenText Core Performance Engineering server URL from the address bar of the browser in which you opened the LRC application. For example, if the URL in the address bar of the browser is https://loadrunner-cloud.saas.microfocus.com/home/?TENANTID=208294383&projectId=1
, copy the address https://loadrunner-cloud.saas.microfocus.com
.
Expand the graphic to see a typical setup of OPLGs behind a firewall.
Enable access to the OpenText Core Performance Engineering application
On-premises load generators and other agents communicate with OpenText Core Performance Engineering on a regular basis. You can check the connection to the OpenText Core Performance Engineering from the machine on which the on-premises load generator or agent is installed, using one of the following methods:
-
Run
curl <server URL>
-
In a browser, go to the server URL.
If the communication check is unsuccessful, you may need to add the LRC application URL to the allowed URLs.
Enable access to the runtime control components
OpenText Core Performance Engineering dynamically provisions an IP address for each concurrent test that you want to run. By default, the IP addresses for LRC runtime control components are allocated from the cloud provider's public IP range.
OpenText Core Performance Engineering hosts an LRC runtime component host with the domain name oplg-test.loadrunner-cloud.com which is always available (https://oplg-test.loadrunner-cloud.com), enabling you to perform a communication test from an on-premises load generator or agent host. To perform such a test, from the on-premises load generator configuration tool, click Save & Test. For details on the on-premises load generator configuration tool, see OPLG configuration tool.
If the communication test is unsuccessful, you may need to open outbound communications to the LRC control components using dedicated IP addresses provided for OpenText Core Performance Engineering runtime control components.
If the Save & Test operation succeeds, an actual test run may fail due to firewall constraints. In this case, you may need to use dedicated IP addresses and allow these IPs on your firewall.
To request dedicated IP addresses, submit a service request specifying the number of requested IP addresses and the number of concurrent tests you want to run. Each test requires a dedicated IP for each run time component. If you intend to run three concurrent tests, you should request three dedicated IPs for the runtime control components.
Note: By default, LRC provisions runtime control components for tests with OPLGs in the AWS N. Virginia region. This means that dedicated IPs are also allocated from this region. In the event of an AWS incident that may impact LRC operations from the N. Virginia region, the default region may temporarily be changed to AWS Oregon. You can request additional dedicated IPs for AWS Oregon to ensure service is not impacted should such an incident occur.
After dedicated IPs are allocated for runtime control components, you have the option of using a dedicated sub-domain of LRC runtime control components, specifically for your tenant. This enables you to open your firewall or proxy to any control component address included in the dedicated sub-domain, eliminating the need to configure and maintain specific IP addresses.
The sub-domain format is *.t-<your tenantId>.loadrunner-cloud.com. Below is an example of a typical control component address:
ip-52-86-68-134.t-123454321.loadrunner-cloud.com
To enable this option for your tenant, submit a service request.
View the dedicated IP addresses
You can view a list of IPs that were dedicated for your cloud-based load generator or OpenText Core Performance Engineering control components.
To view the list of dedicated IPs:
- In the navigation menu in the banner, click the Settings button and then select Dedicated IPs when enabled. If your IPs are due to expire soon, there is an indication in the menu adjacent to Dedicated IPs.
-
Click the Cloud LGs or Control Components tab, and expand the regions to see the dedicated IP addresses.
- To save a list of the dedicated IPs, click Export to CSV.
Tip: Admins can view the number of dedicated IPs entitled to the tenant, in the Tenant management > License > Summary tab. For details, see License consumption.
Troubleshooting
This section provides information for troubleshooting dedicated IP address issues.
-
When your test is configured to use dedicated IPs for cloud-based load generators, if there are not enough dedicated IPs to support the test configuration, the test fails. You receive an error that indicates the number of dedicated IPs needed to run the test in each configured region, and the number of available dedicated IPs available in each of those regions.
-
You can use a maximum of 300 dedicated IP addresses for a single cloud-based load test.
See also: