SFSS VM network requirements
SFSS VM network requirements
-
A storage area network (SAN) is a group of interconnected hosts and storage. For resiliency, SANs must be deployed in pairs. Dell Technologies recommends that SFSS VMs are also deployed in pairs for full end-to-end operational resiliency and administrative separation. Each CDC instance maps to one SAN, which can consist of one or more VLANs.
Similar to Fibre Channel switch behavior, SFSS VMs work independently in Active/Active mode. They are not aware of each other and do not failover to each other. Configuration is not synchronized across SFSS VMs. Neither SFSS is redundant. This prevents administrative error from propagating across the SAN pair. For high availability, tools such as HA, DRS, FT on ESXI, and OpenNebula on Linux should be used to protect the virtual machines. SFSS VM pairs can reside on a single management host, but using different hosts for each SFSS VM is preferable.
When planning the SFSS deployment, consider the following prerequisites:
- Optionally, SFSS VM interfaces can leverage teaming with link aggregation.
- An SFSS VM should not be installed on endpoints which are controlled by that SFSS. For example, it is best practice to run it on a separate management host/cluster from the NVMe/TCP endpoints.
- By default, the SFSS OVA file comes with 10 preconfigured NIC. The Linux Qcow2 image comes with one adapter pre-configured. Adapters can be added or removed as required.
Figure 6. Example of two SFSS VMs, each with one CDC instance 
In the above example deployment, best practices have been used. As it is a dual SAN solution, there are two independent SFSS VMs, one for SAN A and one for SAN B.
Figure 7. Example of a single SFSS VM with two CDC instances 
It might be preferable to have a single SFSS instance managing the SAN. This is suitable for a smaller, less critical environment. Each SAN should map to one CDC for administrative resiliency.
Figure 8. Example of Dual SAN with multiple VLANs in each instance. 
A SAN may consist of multiple VLANs. For example, hosts might be on one VLAN, and Storage might be on another. By giving the CDC an interface in all the necessary VLANs, auto-discovery of these endpoints will work. The hosts and storage will need to route to each other directly for I/O connectivity.
Figure 9. Example of non-best practice use of SAN A and SAN B in the same CDC 
To avoid human error impacting an entire solution, we recommend avoiding the use of a single CDC to manage more than one SAN. As in the previous example, a SAN can consist of multiple VLANs, but a CDC should only manage one SAN.
Figure 10. Example of non best-practice use of two CDCs in one broadcast domain. 
The deployment of two CDCs with interfaces in the same VLAN is not supported. Resiliency is created by having SAN pairs, each with their own CDC. Endpoints would register with both, and could receive conflicting information. The above configuration results in unnecessary administration and more complex operations.
If a host learns about a storage endpoint from any source, it will attempt to connect to it, whether it’s from multiple CDCs or even direct discovery. For simplicity, each host endpoint should have a single source of truth.
SFSS ESXi host network requirements
For auto-discovery to work, CDCs require an IP address and interface on the same VLAN as the endpoints they will control. If this is not possible, the endpoints can still register from a different subnet, but some additional configuration is required. Teaming can be used on the SFSS host.
For the configuration steps, see the Deploy SFSS on ESXi chapter.
Figure 11. Example ESXi management host - dual SFSS. 
Figure 12. Example ESXi management host - single SFSS. 
SFSS Linux host network requirements
There are many ways to configure the networking on the SFSS virtual machine’s host. Here are two examples; one with dual-SFSS VMs, and one with a single SFSS VM:
Figure 13. Example Linux management host - dual SFSS. 
Figure 14. Example Linux management host - single SFSS. 
Table 3. Verified scalability limits for SAN topologies Parameter Verified limit Maximum number of CDC instances per SFSS 16 Maximum number of endpoints (initiators and targets) per SFSS 2048 Maximum number of endpoints per CDC instance 20481 Maximum number of subsystems a host can access 16 Maximum number of hosts that can access a single subsystem interface 64 Maximum number of zone groups 500 Maximum number of zones per zone group 64 Maximum number of members per zone 65 1 Only one CDC instance is supported if the maximum endpoint limit is reached.