Requirements for Windows iSCSI configuration

Windows iSCSI configuration requirements are split into two types. These requirements are needed on both staging and target servers.

iSCSI configuration required for operational stability.
Optional iSCSI parameters for performance improvement.

When target environments are discovered, Delphix will configure the Microsoft iSCSI Initiator Service for Automatic startup.

iSCSI configuration required for operational stability

The following Microsoft iSCSI Initiator configuration parameters are required for the target and staging Hosts. For details about configuring registry settings, see How to modify the Windows registry

You must reboot the Windows server reboot after changing the iSCSI configuration parameters.

Registry key	Registry value	Type	Data
`HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\iSCSI\Discovery`	MaxRequestHoldTime	REG_DWORD	0x384 (900)
`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Disk`	TimeOutValue	REG_DWORD	0x384 (900)
`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E97B-E325-11CE-BFC1-08002BE10318}\<Instance Number>\Parameters`	MaxRequestHoldTime	REG_DWORD	0x12C (300)

These settings will improve operational stability for VDBs and staging databases. If these settings are not adjusted, SQL Server may raise errors if VDBs are accessed during a temporary infrastructure outage. Affected VDBs may need to be manually restarted using the Continuous Data Engine.

Delphix Knowledge Base article KB1251 includes scripts to validate or set registry parameters so that they meet current Delphix recommendations.

Optional iSCSI parameters for performance improvement

The following iSCSI Registry setting may improve the performance of SQL Server dSource and VDB on the staging and target hosts.

Registry Key	Registry Value	Type	Data
`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<Interface GUID>`	TcpAckFrequency	REG_DWORD	0x1 (1)

This setting is recommended for storage networks in Microsoft's TechNet article iSCSI and the Nagle algorithm, described in Microsoft's document TcpAckFrequency to control the TCP ACK behaviour

In some environments, adjusting this setting may not improve performance compared to Windows defaults. Modifications to this registry parameter should be tested in each environment, to confirm that this provides a performance improvement.

Delphix engine validation for Windows iSCSI configuration

Delphix Engine validates the Windows iSCSI Configurations that are set on any supported windows staging and target host with the Delphix recommended configurations while performing the following operations:

Add environment operation
Refresh environment operation
Enable environment operation

Prerequisites

Supported if you are using Powershell 3.0 or above - If you are on Powershell version below 3.0, then the job will be updated with a warning that the Powershell version on your host is not supported for validating iSCSI parameters.
The below alerts are applicable only for staging or target Windows hosts.

Additional information

Delphix Engine will only validate and will not alter any configuration in the user environment.
On update of registry values on the target host to match Delphix recommendations, the faults from the Delphix engine will only be resolved if any of the operations (environment add, refresh or enable) is performed. Delphix engine will not monitor the state of the target host in the background and hence any change will not be picked up unless an operation is triggered. So, the user needs to take action for the change to reflect in faults.
On a successful Delphix Engine upgrade, the latest default iSCSI recommendations will be used for validations.

Troubleshooting

Severity	Type	Description
Warning	iSCSI configuration parameter values on environment <env-name> do not match Delphix Engine required values.	This single fault and/or job warning is thrown for all mismatched parameters.
Warning	Failed to fetch some iSCSI configuration parameters for the environment <env-name>.	This single fault and/or job warning is thrown for all parameters where Delphix Engine fails to fetch the value at the target host.
Warning	Failed to fetch some iSCSI configuration parameters for host <env-name> due to time out.	This job warning is raised, if Delphix Engine is unable to get the iSCSI parameters on the host within 5 minutes. No fault thrown at this point.
Warning	PowerShell version 3 (or above) is required for fetching iSCSI configuration parameters.	This job warning is raised if the PowerShell version is below 3 on the host during the validation of the iSCSI parameters. No fault thrown at this point. The validation is skipped.

Identifying the instance number for iSCSI control class initiator drivers

From the Windows toolbar, click Start and select Run from the menu.
Type regedit in the Open field and click OK.
Go to the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E97B-E325-11CE-BFC1-08002BE10318}\<Instance Number> where the value of <Instance Number> is the one that shows a DriverDesc value of Microsoft iSCSI Initiator. Under the registry key, locate and expand the plus (+) sign next to the instance number. In the example below, the value of the instance number is 0002.

1 Value of Instance Number

Windows iSCSI configuration and limits for target and staging hosts

Windows limitation

Windows supports up to 255 iSCSI LUNs maximum. This creates a hard limit on the number of VDBs that can be created because each VDB requires one or more iSCSI connections.

iSCSI connections: staging

dSource linked with Logsync disabled = 1 LUN (DATA).
dSource linked with Logsync enabled = 2 LUNs (DATA and ARCHIVE).
dSource linked with Logsync disabled and SnapShot started (new COPY ONLY FULL BACKUP) = 2 LUNs (DATA and TEMP).
1. Once the SnapShot is completed the TEMP LUN will be destroyed and 1 LUN used.
dSource linked with Logsync enabled and SnapShot started (new COPY ONLY FULL BACKUP) = 3 LUNs (DATA, ARCHIVE and TEMP).
1. Once the SnapShot is completed the TEMP LUN will be destroyed and 2 LUNs used.
Microsoft’s physical limitation of 255 iSCSI LUNs could be breached by deploying more than 120 dSources to a single staging target (leaving room for other non-Delphix LUNs). Despite physically supporting this many iSCSI LUNs, Delphix does not recommend deploying so many staging databases to a single target, due to other performance considerations.
1. The proposed scenario would leave 13 additional iSCSI connections available for COPY ONLY FULL BACKUPS.
2. For dedicated staging hosts, a PowerShell process for monitoring is not used.

iSCSI connections: targets

VDB normal operations = 1 LUN (DATA).
1. No extra mounts required for SnapShot restore or refresh from source Snapsync.
VDB point-in-time log actions (such as restore, refresh or provision from logs) = 2 LUNS (DATA and SOURCE_ARCHIVE).
1. An extra LUN is not required for Snapsync operations, only Logsync.
2. Most users do not require enablement of the Logsync feature for MSSQL Sources, because sources in FULL RECOVERY mode create a Snapsync for each log file, providing a significant number of restore points even without retaining the logs.
3. Once recovery is completed the SOURCE_ARCHIVE LUN will be destroyed and 1 LUN used.
A maximum of ~120 VDB's per Target is recommended.
1. In 4.x, target host iSCSI connections are less likely to be a limitation while processing charges for PowerShell threads may become prohibitive, because each target VDB requires a PowerShell process for monitoring.
2. In 5.x, this has been alleviated with a hard limit on PowerShell processes.

iSCSI connections: V2P

V2P normal operation = 1 LUN (DATA).
1. Once the V2P operation is completed, the DATA LUN will be destroyed leaving no LUNs used.
V2P point in time log actions (provision from logs) = 2 LUNS (DATA and SOURCE_ARCHIVE).
1. Once the V2P operation is completed, both the DATA and SOURCE_ARCHIVE LUNs will be destroyed leaving no LUNs used.