I am tasked with planning out a Hyper-V cluster for my employer. My boss wants to avoid using a switch on the iSCSI network, as he feels the potential latency introduced by the switch will impact the performance. He would like to use a setup along these lines (two node Hyper-V, iSCSI device):
Each Hyper-V server has a gigabit capable crossover cable connected to a dedicated NIC port on the iSCSI device.
I feel that any potential latency from the switch will be minimal. I am also concerned as to whether the cluster failover, and cluster shared volumes, will work correctly in such a configuration.
Also, how many networks are required for the setup above? Two (one for data traffic to the network, one for the iSCSI) or three (one for data traffic to network, one for iSCSI traffic, one for cluster traffic)?
Are we assuming that Fiber Channel is out of the question due to cost? iSCSI needs a target and an initiator to function properly, are you using some form of network NAS that also functions as the iSCSI target? A network switch will not add any noticeable latency to an iSCSI setup provided there is no other traffic going over that VLAN, a dedicated switch is the preferred method.
MS clusters require two things to work properly, one a low latency method of monitoring each others heartbeat and a centrally accessible storage device that holds the quorum and shared storage pool. The heartbeat is suggested to be in its own VLAN if not its own physical network, this is the method that each cluster knows when to assume primary control of which resource. The storage method is traditionally a FC SAN network on enterprise solutions, on small scale or lab solutions you can use iSCSI over existing infrastructure or by creating a separate physical iSCSI network. So to answer your questions,
1). A switch should not create any noticeable network latency provided no other data is exchanged across the switch.
2). You can use cross over cables from target to initiator, if the target has multiple iSCSI ports then you can connect multiple initiators, this really depends on the capabilities of the target device and how it handles multipathing and LUN access control. Ensure our target device can assign the same LUN to both iSCSI ports so that each cluster device can ~see~ the target LUN.
3). Ideally three networks should be used. One physically dedicated for iSCSI traffic and another physically separate for network data traffic. The heartbeat should be its own VLAN but may be part of the same physical data network. If a cluster member has had its network connection removed, then chances are it shouldn't be controlling cluster resources and there is no problem with the heartbeat signal being down and the other cluster member taking control of those resources.