Windows iSCSI Configuration and Limits for Target and Staging Hosts
Datasets / SQL Server Environments and Data Sources / SQL Server Support and Requirements / Requirements for Windows iSCSI Configuration / 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

  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) = 3 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

Related Topics