Creating a New Test Bed
Assign a Test Bed name so you can easily identify your Test Bed. You can optionally add a Description to the new Test Bed.
Optionally, add one or more Tags to describe the Test Bed. Test bed tags and names are searchable in WorkloadWisdom.
Using Test Bed Groups
A Test Bed Group is a logical grouping of one or more Workload Generator client Test Ports to SUT Services.
While the Test Bed Group itself does not provide any tangible functionality, in a Test Bed with a large number of Links, or in a Test Bed with multiple storage arrays allocated to different workloads, Test Bed Groups are useful in logically separating the different parts of the test environment.
In the example below, two test bed groups are used to separate the SUT services that are allocated to two different workloads.
Workload Generator Port to SUT Service Links
At a minimum, a functional test bed contains one Workload Generator client port, one SUT service, and one link to connect the Workload Generator client port to the SUT service.
Generator Client Test Port. Test Port from a Workload Generator.
SUT Service. Storage Service that is provided by the SUT, along with additional access information that is required for the selected storage protocol.
Link. Connection between one Workload Generator Client Port and one SUT Service. The exact content of the Link varies depending on the Test Port and the SUT service that it is connecting. In most cases, the Link defines the addresses used by the Test Port for the selected protocol.
Workload Generator Client Test Port
The following Workload Generator Client Test Ports are available:
FC Port: FC-SCSI Test Port on a Workload Generator that supports 4, 8, 16, and 32GFC
FCoE 10GE Port: FCoE Test Port on a Workload Generator that supports 10GbE
10GE Port: 10 GbE Test Port on a Workload Generator
25GE Port: 25GbE Test Port on a Workload Generator
40GE Port: 40 GbE Test Port on a Workload Generator
1GE Port: 1 GbE Test Port on a Workload Generator
Virtual Port: Virtual Test Port on a Virtual Workload Generator
The following SANBlaze Workload Generator Client Test Ports are available:
SB FC-NVMe Port: FC-NVMe Test Port on a SANBlaze Workload Generator that supports 16 and 32GFC
Ethernet Ports
MTU can be set for all Ethernet Ports. The default is 1,500 bytes, and the maximum is 16,128 bytes for Workload Generators with 10GbE or higher speed test ports. A common “jumbo frame” used in the industry, in particular with iSCSI, is 9,000 bytes.
FC Ports
When MPIO is enabled on the FC Port, certain logics are implemented to provide better usability by reducing the amount of manual configuration required. When MPIO is enabled, the following MPIO Group options are available:
Single: One Workload Generator port is used to generate I/Os to the destination target/LUNs over multiple Paths
Pair: Two Workload Generator ports are hardcoded into a single MPIO Group used to generate I/Os to the destination target/LUNs over multiple paths, in which the following pair options are supported:
MPIO Group 0: FC port 0 and FC port 1
MPIO Group 1: FC port 2 and FC port 3
MPIO Group 2: FC port 4 and FC port 5
MPIO Group 3: FC port 6 and FC port 7
Quad: This option appears only for Workload Generators with more than four ports. Ports are hardcoded into one MPIO group used to generate I/Os to the destination target/LUNs over multiple paths.
All Ports: All ports on a Workload Generator are hardcoded into one MPIO group used to generate I/Os to the destination target/LUNs over multiple paths.
Port Pairs: Number of sets of pair mode.
Two pairs: Two sets of pair mode
Four pairs: Four sets of pair mode
Each MPIO group has a primary port and a secondary port. The notion of primary port and secondary port becomes important in MPIO failover/failback scenarios. When MPIO is enabled, the port you select as the Workload Generator client port assumes the primary port role. The other port in the same MPIO group automatically assumes the secondary port role.
Note
All Test Ports inside an MPIO Group share the Group's performance resources. Each MPIO Group has a performance limit that is less than the total Generator limit. As the number of Test Ports inside the same MPIO Group increases, the maximum output does not increase linearly. Using multiple Port Pairs enables you to maximize the load potential of the Generator, as there are multiple MPIO Groups being used. For example, if you have an 8-port Generator, you would be able to generate more load by using Four Pairs (a Port Pairs option) than using All Ports. The disadvantage is that in Port Pairs mode, each MPIO Group has only two Test Ports, which means there is only one backup port in case one port fails. Whereas in All Ports mode, you have seven backup ports.
Tip
If you are primarily running a load balancing test in which you want to maximize the generated load, and if you want to use more than two Test Ports, use Port Pairs. If you are running a failover test in which you will intentionally tear down the primary link during the test run, and if you want traffic to run only on the primary link before the tear down, use Quad or All Ports.
In the following example, for FC Port 0 on the FC Workload Generator, 172.17.3.1 is the primary port in an MPIO Group, and FC Port 1 is automatically designated as the secondary port in the same MPIO Group.
System Under Test (SUT) Service
The following SUT Services are available:
FC LUN Service: Enhanced FC Service or FC MPIO Service designed for multipathing. This service allows all possible paths to one or more LUNs sharing the same WWID to be automatically configured, without requiring the user to specify the exact path between each Initiator and Target.
SB FC-NVMe Service: SUT that supports FC-NVMe Service designed for multipathing that allows all possible paths to one or more namespaces to be automatically configured.
iSCSI Service-Tabular Entry: Enhanced iSCSI Service that supports auto-discovery of iSCSI Targets and LUNs. Also supports entering iSCSI Targets and LUNs in tabular format or by importing a CSV file.
NFS Service: SUT that supports NFS. One IP address with at least one valid share must be properly configured and accessible by the Workload Generator’s NFS Clients. Optional configurations include Authentication methods.
SMB Service: SUT that supports SMB. One IP address with at least one valid share and at least one valid username and password, and optional domain, must be properly configured and accessible by the Workload Generator’s SMB clients. Optional configurations include Authentication methods and Packet Signing.
Amazon™ S3 Service: SUT that supports S3 API over HTTP or HTTPS. One IP address, authentication method, authentication keys, and AWS Region must be properly configured and accessible by the Workload Generator’s S3 Clients. Optional configurations include custom HTTP Request Headers. If HTTPS is used, optional configurations include Client certificate, and Server certificate.
Op-ST Swift Service: SUT that supports OpenStack-Swift API. One IP address, authentication method, authentication keys and base request URI must be properly configured and accessible by the Workload Generator’s OpenStack Swift Clients. Optional configurations include custom HTTP Request Headers.
More: less commonly used or obsolete Test Beds. Obsolete Test Beds are maintained for at least one additional release, but will be removed eventually.
FC Service: SUT that supports Fibre Channel. One target WWPN with at least one valid LUN must be properly configured and accessible by the Workload Generator’s FC initiators.
Notice
While supported for backward compatibility reasons, this functionality is largely made obsolete by the FC LUN Service. It is recommended to use the FC LUN Service by default, unless you require the ability to specify the exact path between an Initiator and a Target.
FC MPIO Service: SUT that supports Fibre Channel with MPIO enabled. Two target WWPNs with at least one valid LUN per Target WWPN must be properly configured and accessible by the Workload Generator’s FC initiators. When ALUA is also enabled in the Fibre Channel Workload, the LUNs must be configured to hold the same WWID.
Notice
While supported for backward compatibility reasons, this functionality is largely made obsolete by the FC LUN Service. It is recommended to use the FC LUN Service by default, unless you require the ability to specify the exact path between an Initiator and a Target.
iSCSI Service: SUT that supports iSCSI. One Target IQN with an IP address and at least one valid LUN must be properly configured and accessible by the Workload Generator’s iSCSI initiators.
Notice
While supported for backward compatibility reasons, this functionality is largely made obsolete by the iSCSI Service-Tabular Entry. It is recommended to use the iSCSI Service-Tabular Entry by default, unless you need to create an iSCSI test environment in which the Initiator IP addresses are not contiguous or masked to different subnets.
HTTP Service: SUT that supports HTTP or HTTPS. One IP address must be properly configured and accessible by the Workload Generator’s HTTP Clients.
Amazon™ S3 Service (obsolete): SUT that supports S3 API. One IP address, authentication method, authentication keys, and AWS Region must be properly configured and accessible by the Workload Generator’s S3 Clients. Optional configurations include custom HTTP Request Headers.
Block Storage Services
Configure Test Beds that provide block storage services: FC-SCSI, FC-NVMe, and iSCSI
FC LUN Service
Use the FC LUN service to automatically configure and use all available paths from a WorkloadWisdom initiator to one or more LUNs.
Add an FC LUN service, connect a link from the Workload Generator FC Port to the FC LUN Service. Click on the LUNs: 0 of n link to open the drop-down menu with LUNs that are accessible to the selected Workload Generator FC Port.
Click the LUNs drop-down menu to see a list of discovered WWIDs, that is, a collection of LUNs with the same WWID, the number of ITLs available to the WWID, and the reported WWID associated with the LUNs. Select a WWID to use in the test bed
You are not able to select the exact path or exact target WWPN to use to reach a LUN. In the FC LUN Service, it is by design that all available paths to the selected LUN may be used. Use the FC Service or the FC MPIO Service if you want to select the exact path and / or exact target WWPN.
Note
When using the MPIO Two Pairs and MPIO Four Pairs mode, which are available for the FC LUN Service Test Bed, the FC Workload's Load Properties values you specified are divided by two and four for each Pair, respectively. For example, if you specify 100 concurrent workers in the FC Workload, and apply it on an FC LUN Service Test Bed with the MPIO Four Pairs mode set, 25 concurrent workers are assigned to each pair.
SB FC-NVMe Service
Use the SB FC-NVMe Service to automatically configure and use all available paths from a SANBlaze FC-NVMe Host to one or more FC-NVMe Namespaces.
Add an FC-NVMe service, connect a link from the SB FC-NVMe Port to the FC-NVMe Service. Click on the Namespaces: 0 of n link to open the drop-down menu with Namespaces that are accessible to the selected SB FC-NVMe Port.
Note
All physical SB FC ports set to NVMe mode are represented under one logical SB FC-NVMe port in Test Bed. So the one logical SB FC-NVMe port may contain one or more physical SB FC ports that are set to NVMe mode, even though they are not separately identified in the test bed.
Click the Namespaces drop-down menu to see a list of discovered namespace GUIDs, that is, a collection of namespaces with the same GUID, the number of paths available to the GUID, and the reported ID associated with the namespace. Select a Namespace GUID to use in the test bed.
Optionally enable MPIO to enable MPIO failover and load balancing functionalities. The specific MPIO policy is specified when configuring the FC-NVMe Workload Test.
iSCSI Service-Tabular Entry
You can create an iSCSI service automatically using iSCSI Auto-Discovery, or you can add initiators and targets using iSCSI Service-Tabular Entry either individually or by importing a properly formatted CSV file.
Using iSCSI Service-Tabular Entry by Auto-Discovery
Select Create Test Bed from the quick access
menu at the top of the screen.Enter the following information on the New Test Bed screen:
Test bed name, Description, and Tags for your test bed.
Group Name for your test bed.
For Client 0, click Select a Generator Port and choose a port.
Optional: If you need additional clients, click the
drop-down menu and click Client, then select a generator port for the client.Click the
drop-down menu and select iSCSI Service-Tabular Entry.
You can add one or multiple Services from the drop-down menu.
Click the '+' button on the right edge of each Client box and select the service or services to link to.
An arrow between the two boxes appears. You can create a single or multiple links to one or more services.
Optional: Set the Target Port in the iSCSI-Service-Tabular Entry box, if necessary.
Note
The default port is the default iSCSI port, 3260. Thesetting is applied to all targets configured in the service. Change the default port setting if your lab configuration requires it.
In the iSCSI-Service-Tabular Entry box, click Add Targets/LUNs and then click Discovery on the LUN selection page.
In the iSCSI Discovery window, enter the following information that is required to initiate the discovery process:
Portal Info
Address: IP address of a destination iSCSI Target Portal that can return information about the iSCSI Targets that are accessible to the iSCSI Initiator that is doing the discovery using standard iSCSI requests and responses. The iSCSI Target Portal may or may not be an accessible iSCSI Target itself.
Port: TCP port that the iSCSI Target Portal is listening on for iSCSI requests and responses.
Timeout: The maximum amount of time the iSCSI Discovery process will last.
Authentication: Enable the use of one or more supported AuthMethods defined by the iSCSI RFC such as CHAP.
Initiator Info
Name: Enter an iSCSI Initiator Name (loosely referred to as the IQN) that you want to use to perform the iSCSI Discovery. You should use a Name that you intend to use for the iSCSI Workload Test itself, not only for the Discovery, as the accessible Targets may vary based on the iSCSI Initiator Name depending on your lab configuration.
Network Info
Enter the common IP address parameters (address, netmask, gateway) for the iSCSI Initiator that is doing the discovery. If you already have these configured in the Test Bed Link, simply click Load from link to apply those settings automatically.
Enable Trace
Optionally download a capture of the iSCSI Discovery process to be viewed using PCAP readers such as WireShark.
Previous Results
If you have performed iSCSI Discovery before, you can click on the entry to view a summary of the most recent iSCSI Discovery results, and optionally apply these Targets and LUNs by clicking the Load discovered LUNs button.
Click Start to initiate the iSCSI Discovery process. The Discovery Results page loads.
When the iSCSI Discovery completes, a numerical summary of the discovered Targets and LUNs is shown.
If you selected Enable Trace, you can now download the .pcap capture by clicking Download PCAP.
A log is also available that tracks the timestamps of various key stages of the iSCSI Discovery process.
If iSCSI errors are encountered during the discovery process, these errors are shown in the Errors section.
Click Previous Results and then Load discovered LUNs to apply the previously discovered Targets and LUNs that are accessible to the iSCSI Initiator used to perform the previous discovery.
The discovered information is applied to the iSCSI Service-Tabular Entry table. By default all discovered Targets and LUNs are selected. You can select or deselect one or more Targets to specify which Targets and LUNs are used in the Test Bed. If an entry is not selected, then that Target/LUN is not used in the Test Bed.
You can also customize the discovered information or export the table to a CSV file for additional modification, and then import it back into WorkloadWisdom.
Click Save to save the Targets/LUNs selections and settings.
Perform any other optional task needed, such as enabling/disabling CHAP, or adding more Client Ports or Services or Links.
When ready to save the Test Bed, click Create Test Bed.
Using iSCSI Service-Tabular Entry by Adding Individual Entries in Tabular Format
Follow the steps described in the section iSCSI Service-Tabular Entry until you reach the Discovery step.
Click + Add Row to add one entry at a time to the test bed. You can add multiple rows by clicking +Add Row for as many entries as you need. Click the X at the end of each row to delete the corresponding entry.
When you add an entry, the entry is populated with its Initiator Name and Target Name. By default, when an entry is added, the checkbox in the first column is checked. The checkbox indicates that it is selected as part of the test bed.
For each entry, complete the information associated by the other columns:
Target Address. IP address or hostname of the location of the iSCSI target on the network.
LUN. LUN being tested
Logical Unit Size. Size of the iSCSI target. You can specify this in GB, bytes, KB, or MB. GB is the default.
CHAP Username. Username for iSCSI access. This is an optional field that is disabled by default.
CHAP Password. Password for iSCSI access. This is an optional field that is disabled by default.
Use the checkbox in the
column to select or deselect the entries to include in the Test BedUse the search boxes associated with Target Address, Target Name, and Logical Unit Size columns to filter entries to include in the test.
Click Save to save the Targets/LUNs selections and settings.
Perform any other optional task needed, such as enabling/disabling CHAP, or adding more Client Ports or Services or Links.
When ready to save the Test Bed, click Create Test Bed.
Using iSCSI Service-Tabular Entry by Uploading a File
Follow the steps described in the section iSCSI Service-Tabular Entry until you reach the Discovery step.
Click Export to download a WorkloadWisdom-formatted CSV file.
Click select a file to upload or drag and drop a CSV file into the box to upload a CSV file.
Use the checkbox in the
column to select or deselect the entries to include in the Test Bed
Use the search boxes associated with Target Address, Target Name, and Logical Unit Size columns to filter entries to include in the test.
Click Save to save the Targets/LUNs selections and settings.
Perform any other optional task needed, such as enabling/disabling CHAP, or adding more Client Ports or Services or Links.
When ready to save the Test Bed, click Create Test Bed.
File and Object Storage Services
Configure Test Beds that provide File storage services (NFS, SMB) and Object storage services (Amazon S3, OpenStack Swift).
Common File and Object Storage Parameters
These settings apply to all File and Object Storage services.
Service Address: IPv4 address or hostname of the server and the TCP Port associated with the service. If you enter a hostname, you need to enter DNS information in the Link settings.
Port: TCP Port associated with the service. Unless you have specific requirements (for example, Port 8080), you can leave the Port field blank, and WorkloadWisdom automatically selects the standard-defined TCP Port.
NFS and SMB Service Parameters
Shares: Path and name of the shares or mount points on the server where the workload will create files and folders. You do not need to include a slash at the end.
Syntax example for NFS:
/rpool/fs13Syntax example for SMB:
vol_cifsTo specify a large number of Shares, you can either use the Autofill function to create linearly incrementing Share names, or you can export a blank .csv template and modify it outside of WorkloadWisdom and then import it back in.
A maximum number of 2,000 Shares is allowed per Service. You can create multiple Services per Test Bed, up to a maximum of 10,000 per Test Bed.
Kerberos: Enables the use of a Kerberos service for user authentication. Available for NFS and SMB Services.
NFS
Mode: Select one of the following three standard Kerberos authentication options:
krb5: Uses Kerberos v5 to authenticate users
krb5i: Uses Kerberos v5 with integrity checksum
krb5p: uses Kerberos v5 with integrity checksum and encryption
Kerberos Address: Address of the Kerberos service, and optionally a non-standard port. If not specified, the realm specified in the NFS User menu is used as the Kerberos address.
SMB
Kerberos Address: Address of the Kerberos service, and optionally a non-standard port. If not specified, the domain name specified in the SMB User menu is used as the Kerberos address.
Users: List of usernames, passwords, and optionally domains or realms.
To specify a large number of Users, either use the Autofill function to create linearly incrementing User names, Passwords, and Domains or Realms, or you can export a blank .csv template and modify it outside of WorkloadWisdom and then import it back in.
For NFS, the Users menu is only available when you enable Kerberos.
Object Service Parameters
Amazon S3
Protocol: HTTP or HTTPS
HTTPS: Optionally configure Client and Server certificates. If Enabled, upload a valid Server certificate.
Authentication method: Disabled, AWS2, or AWS4
It is rare that no authentication method is used, except in a lab environment. AWS4 is the common default authentication method for Amazon S3.
AWS Region: AWS Region, selected from the list.
Authentication Keys: If you use selected AWS2 or AWS4 for the Authentication Method, you need to enter the Access Key ID and the Secret Access Key. To specify a large number of S3 clients, you can export a blank .csv template and modify it outside of WorkloadWisdom and then import it back in.
Add request headers: Many request header key value pairs exist, and different applications tend to include different key value pairs in the request header. Optionally use this field to define additional HTTP request headers to include in every HTTP request sent by WorkloadWisdom HTTP clients. Only use this field if you are familiar with the key value pairs required.
Caution
The request headers you define here will be included in all requests.
Openstack Swift
Protocol: HTTP or HTTPS
Authentication method: TempAuth or Keystone (OpenStack).
Auth Address: Available only if you select Keystone. Enter the IPv4 address (or hostname) and port of the keystone authentication server.
Base Request URI: Base URI used for OpenStack-Swift authentication. If you are not sure, you might be able to leave it blank and use the default of /auth/v1.0, which is automatically used if the field is blank.
Authentication: If you selected TempAuth, enter the X-Auth-User value and X-Auth-Key value. If you selected Keystone, enter the username, password, and tenant.
Add request headers: Many request header key value pairs exist, and different applications tend to include different key value pairs in the request header. Optionally use this field to define additional HTTP request headers to include in every HTTP request sent by WorkloadWisdom HTTP clients. Only use this field if you are familiar with the key value pairs required.
Caution
The request headers you define here will be included in all requests.
Less Common or Obsolete Services: Additional Information
Caution
The Obsolete Services documented in this section are still supported. However, there will not be new functionalities developed for these Services. In a future release, one or more of these Services will either be rolled in to other Services and / or be removed.
FC Service
If you want to create an FC test bed and precisely define the ITL connection, it is recommended that you use the FC Service or FC MPIO Service.
If you want to create an FC test bed where all available paths to a set of LUNs (grouped by WWID) are used and automatically configured, it is recommended that you use the FC LUN Service.
Caution
When using Auto-Discover Services, a list of discovered targets is not generated on-demand. The list is generated when you click Rediscover Targets on the FC Workload Generator. To do this, go to Generators, select the FC Workload Generator, and click Rediscover Targets.
You can use the FC Service to define a one-to-one ITL connection between the Workload Generator’s FC initiator, the SUT’s FC target WWPN, and the SUT target’s LUNs.
The number of available targets and LUNs can be high, and WWPN values are not easily readable or memorized. It is strongly recommended that you use Auto-Discover Services to automatically discover available targets.
After you select Auto-Discover Services, a list of discovered targets displays. You can manually select a target WWPN from the list.
After you click Create Selected Services, a functional FC test bed is created.
You can continue to expand this test bed by adding more links to more targets, and/or modifying the LUNs list by selecting from the LUNs drop-down menu.
From the list of LUNs, you can remove LUNs that you do not want to generate IOs, when running a workload test. You need at least one LUN to have a functional FC test bed.
If you do not want to use auto-discover to create the FC Service, you can enter the Target WWPN and LUNs manually. Be sure that the manually configured WWPNs and LUNs are accessible by the Workload Generator’s FC Initiator.
FC MPIO Service
Use the FC MPIO Service to configure specific M:M multipath connections for WorkloadWisdom’s MPIO-enabled initiators to MPIO-enabled targets with access to a common set of LUNs.
In the FC MPIO Service, there is a one-to-one relationship between WorkloadWisdom initiators to FC Targets. If you want to define four specific paths, that is, four unique Target WWPNs with access to the same LUNs, you must use four Workload Generator FC Ports (each Port is one Initiator) by enabling MPIO and selecting the Quad option under MPIO Mode.
Similar to the FC Service, it is recommended that you use Auto-Discover Services to automatically retrieve a list of available MPIO-enabled targets and LUNs.
A list is displayed of discovered MPIO-enabled Targets, and the Target WWPNs/LUNs that are accessible to all selected WorkloadWisdom MPIO-enabled Initiators are grouped together.
Select one or more groups and click Create Selected Services. A functional M:M MPIO test bed is created.
Similar to the FC Service, you can opt out of creating the FC MPIO test bed using Auto-Discover, and manually define exactly how each initiator connects to each target WWPN.
iSCSI Service (Obsolete)
The iSCSI Service is a single Target service for iSCSI that was introduced before the iSCSI Service – Tabular Entry service, and offers limited functionality in comparison. It may be preferred if you are working with a very small iSCSI test environment with only one iSCSI Target. See the iSCSI Service-Tabular Entry section for information on the available parameters.
Amazon S3 Service (Obsolete)
The Amazon S3 Service found under this menu is made obsolete by the new Amazon S3 Service described earlier. The functionalities provided by this obsolete Service is a subset of the new Service. See the Amazon S3 section for information on the available parameters.
Links
The following Link parameters are available.
FC Services
NPIV Enabled. Enables or disables the creation of NPIV interfaces. This option is not currently available for the FC MPIO Client. The time it takes to create and/or clear NPIVs is usually several seconds for each NPIV, and also depends on how many Targets and LUNs visible to each NPIV in the fabric. If you are applying hundreds of NPIVs, it can take over an hour. An NPIV progress bar is displayed when NPIV configuration is applied.
Range. Specifies the starting and ending NPIV WWPN. The ending NPIV WWPN value must be numerically greater than the starting NPIV WWPN.
Reconnect. The following two reconnect parameters are available:
Reconnection Attempts. Number of times the initiators attempt to reconnect to the FC Service before terminating the connection. When a connection is terminated, no further actions are performed for the terminated connection.
Polling Interval. Time interval between two consecutive Reconnection Attempts.
If NPIVs are enabled, after defining the WWPN range for the NPIVs, you must click Create Test Bed & Create WWPNs to apply the NPIV configuration. A real-time NPIV Configuration Progress pop-up dialog display the current status of NPIV configuration.
SB FC-NVMe Service
NPIV Enabled. Enables or disables the creation of NPIV interfaces.
NPIVs per port. Specifies the total number of NPIV interfaces to create per physical port.
IP Storage Services
The following Link parameters are available to all Services that run over IP.
IP Range. Starting IP address and ending IP address for the WorkloadWisdom clients. The ending IP address value must be numerically greater than the starting IP address.
IP Configuration. (both IPv4 & IPv6)
Gateway Address. IP address the protocol client uses to reach the destination when the route to the protocol Service IP address is unknown.
Allowed Port Numbers. TCP source port range used by the protocol clients.
Gratuitous ARP. If enabled, the protocol client broadcasts a gratuitous ARP message that identifies the new binding of a source IP address and a source MAC address.
DNS
DNS Server IP. IP address of the DNS Server to which clients send DNS queries to resolve the IP addresses for the hostname entered in the test bed service.
DNS Resolution Timeout (seconds). Amount of time the clients wait for a response to the query before concluding that the DNS query has timed out.
DNS Query Retry Interval. Amount of time the clients wait before retrying a query if it is set to issue a retry.
Maximum Time to Live. Amount of time a positive DNS response is cached by the client for a query.
Negative Response Expiration Interval. Amount of time a negative DNS response are cached by the client for a query.
Advanced DNS settings
DNS Cache Locality. Specifies whether the information provided by the DNS server is applicable on a:
Per Linkbasis. All clients associated with the same test bed link can use the hostname – IP address information provided in the DNS server’s response addressed to any client sharing the same test bed link. Clients on a different test bed link in which no client from that link has received a DNS server response needs to issue a query to resolve the IP address to a hostname, even if another client from another test bed link has received the response.
Per Port basis. All clients associated with the same Workload Generator port can use the hostname. IP address information provided in the DNS server’s response addressed to any client sharing the same Workload Generator port, whether or not that response was received by a client from the same test bed link.
Per Source basis. Each unique client issues its own query to resolve the IP address to a hostname, even if other clients on the same test bed link or Workload Generator port have received responses to the same hostname IP address query.
Resource Record Set Ordering. Specifies how the Client uses the information provided by the DNS Server when multiple IP addresses are available for the same hostname.
DNS Transport Protocol. Uses either TCP or UDP to transmit DNS messages.
VLAN
Generate VLANs. Number of unique VLAN IDs available for use by the protocol clients.
Starting from VLAN ID. Lowest numerical VLAN ID available for use and the first VLAN ID that is used.
Increment by. Incremental value that is added to the previous value.
MAC
Generate MAC addresses. Number of unique MAC addresses available for use by the protocol Clients.
Start from address. Lowest numerical MAC address available for use and the first MAC address that is used.
Increment by. Incremental value that is added to the previous value.
The following Link parameters are only available to the obsolete iSCSI Service (Obsolete), and do not apply to the iSCSI Service-Tabular Entry.
Initiator. Define the Initiator IQN.
Per IETF RFC3720, the format of the IQN should be iqn.{yyyy-mm}.{reversed domain name}:{string}. For example: iqn.2015-09.com.loaddynamix:initiator.i001.port0.appl0 is a valid IQN that conforms to the specified structure
Number of IQNs:
One IQN. Use one IQN for all Initiator IP addresses
One IQN per IP. Use one unique IQN for each Initiator IP address
Specify number of IQNs. Use the specified number of IQNs across the Initiator IP addresses
Custom Number of IQNs. Specifies the number of IQNs when Number of IQNs is set to Specify number of IQNs.
IQNs name. Read-only preview of the range of Initiator IQNs that can be used.
Simulated Storage Services on Test Ports
In addition to defining an SUT Service, the Workload Generator Test Port can also provide protocol server emulation, thereby providing a Workload Generator port service. This is useful in testing devices between the client and server. For example, a WAN optimization appliance, which optimizes the bandwidth usage between the protocol client and the protocol server. In the example below, a Workload Generator port service is used instead of an SUT Service, as the SUT is the device in between (not identified in the test bed).
The following types of Workload Generator port services are available:
NFS Service on Workload Generator. NFS Server emulation running on a Workload Generator port. One IP address with at least one valid share must be properly configured and accessible by the Workload Generator’s NFS clients. In addition, one Workload Generator server port must be specified. A Workload Generator port cannot be used as both a client port and a server port in the same test bed.
SMB Service on Workload Generator. SMB Server emulation running on a Workload Generator port. One IP address with at least one valid share and at least one valid username and password, and optional domain, must be properly configured and accessible by the Workload Generator’s SMB clients. In addition, one Workload Generator server port must be specified. A Workload Generator port cannot be used as both a client port and a server port in the same test bed.
HTTP Service on Workload Generator. HTTP Server emulation running on a Workload Generator port. One IP address must be properly configured and accessible by the Workload Generator’s HTTP clients. In addition, one Workload Generator Server Port must be specified. A Workload Generator port cannot be used as both a client port and a server port in the same test bed.