Windows iSCSI Configuration and Limits for Target and Staging Hosts

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.

For Delphix versions 4.3.5.0 and 5.0.2.0 or newer (note that 5.0 to 5.0.1.x have different limitations)

iSCSI connections - Staging

1. dSource linked with Logsync disabled = 1 LUN (DATA)
2. dSource linked with Logsync enabled = 2 LUNs (DATA and ARCHIVE)
3. 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
4. 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
5. A maximum of ~120 dSources per Staging Target is recommended, assuming an average of 2 LUNs per source, which would mean 240 LUNS would be consumed for normal operation.
   1. The proposed scenario would leave 13 additional iSCSI connections available for COPY ONLY FULL BACKUPS
   2. For dedicated staging hosts, we do NOT use a Powershell process for monitoring.

iSCSI connections - Targets

1. VDB normal operations = 1 LUN (DATA) 
   1. No extra mounts required for SnapShot restore or refresh from source Snapsync
2. 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

3. 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 costs 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

1. V2P normal operation = 1 LUN (DATA)
   1. Once the V2P operation is completed the DATA LUN will be destroyed leaving no LUNs used
2. 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

For Delphix versions from 3.2.7 to 4.3.4.0 or 5.0.1.0 (Older versions consumed more iSCSI connections)

iSCSI connections - Staging

1. dSource linked regardless of Logsync setting = 2 LUNs (DATA and ARCHIVE)
2. dSource linked with 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
3. A maximum of ~120 dSources per Staging Target is recommended, assuming an average of 2 LUNs per source, which would mean 240 LUNS would be consumed for normal operation.
   1. The proposed scenario would leave 13 additional iSCSI connections available for COPY ONLY FULL BACKUPS
   2. For dedicated staging hosts, we do NOT use a Powershell process for monitoring.

iSCSI connections - Targets

1. VDB normal operations = 1 LUN (DATA) 
   1. No extra mounts required for SnapShot restore or refresh from source Snapsync
2. 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

3. 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 costs 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

1. V2P normal operation = 1 LUN (DATA)
   1. Once the V2P operation is completed the DATA LUN will be destroyed leaving no LUNs used
2. 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

Related Links

• Recommendations for Windows iSCSI Configuration