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).
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).
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.
The proposed scenario would leave 13 additional iSCSI connections available for COPY ONLY FULL BACKUPS.
For dedicated staging hosts, a PowerShell process for monitoring is not used.
iSCSI connections: targets
VDB normal operations = 1 LUN (DATA).
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).
An extra LUN is not required for Snapsync operations, only Logsync.
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.
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.
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.
In 5.x, this has been alleviated with a hard limit on PowerShell processes.
iSCSI connections: V2P
V2P normal operation = 1 LUN (DATA).
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).
Once the V2P operation is completed, both the DATA and SOURCE_ARCHIVE LUNs will be destroyed leaving no LUNs used.