This Question is Not Answered
1 "correct" answer available (10 pts)
kjb007 wrote:
Typical FC SAN config would have one NIC to one fabric switch, and second NIC to second fabric switch. Both HBAs to one switch means storage loss to the server. It's nice to have the switches crossed to each storage device, but typically you would not do this in a SAN environment. One controller would have multiple PATHS from one switch, and the other controller would have multiple paths to a 2nd switch. You want to split your connections over the switches, and have the switches connecting directly to one controller or the other. In this case, if you lose a switch, you lose a path, but the server can get to the other storage controller. If you lose a NIC, then you have a 2nd nic to a 2nd switch. Both nics/hba's into one switch creates a single point of failure, the switch. Nothing to failover to here.
-KjB
VMware vExpert
Ok I understand now - it's obvious that if both cables from Server A go to the same switch, and that switch dies, = no storage for Server A. Attached is the revised diagram, does it look better? At this point, I'm not sure why there needs to be 2 subnets on the iSCSI network...
Typical FC SAN config would have one NIC to one fabric switch, and second NIC to second fabric switch. Both HBAs to one switch means storage loss to the server. It's nice to have the switches crossed to each storage device, but typically you would not do this in a SAN environment. One controller would have multiple PATHS from one switch, and the other controller would have multiple paths to a 2nd switch. You want to split your connections over the switches, and have the switches connecting directly to one controller or the other. In this case, if you lose a switch, you lose a path, but the server can get to the other storage controller. If you lose a NIC, then you have a 2nd nic to a 2nd switch. Both nics/hba's into one switch creates a single point of failure, the switch. Nothing to failover to here.
-KjB
VMware vExpert
Attachments:
-
Advanced_VI3_Setup.jpg (81.6 K)
Wow, I think we'll need to send you a consulting fee after this one.
I guess some points will have to do.Since you are using 2 NICs in the same vSwitch, you can team or bond them together. They can either be teamed to provide active/passive redundancy, or they can be active/active. To make the best active/active use, the connections should go to the same switch and be configured in a trunk or ether channel. That way, a vm can use both NICs at the same time. But, that's a story for another day, I think.
-KjB
VMware vExpert
I don't understand the vmotion network, or the management network. In another thread, Dave Mishchenko said the following about them:
Let's say your managemnet network is 172.16.1.0/24. The vcenter server could be at 172.16.1.1, ESX1 at .2 , ESX2 at .3, etc. For the ESXi hosts that would be the managemnent IP addresses. For the vmotion subnet, you can pick any subnet that you don't currently use and only the ESXi hosts would have an IP address on that subnet. The vCenter server doesn't have to have an IP on that subnet.
I'm sorry Dave, but I still don't get it.
If the management address for the host is in the 172.16 range, how will it also have an IP on the VMotion subnet? And for that matter, how would I connect to the VCenter Server from my workstation, when it is on a separate subnet? Do I have to put a second NIC in my workstation or something?
Agreed, but since he's going to the same switch, would it not be beneficial to use the capabilities he has? I've never been in an environment where a vm only spoke to one other IP address.
-KjB
VMware vExpert
-KjB
VMware vExpert
kjb007 wrote:Agreed, but since he's going to the same switch, would it not be beneficial to use the capabilities he has? I've never been in an environment where a vm only spoke to one other IP address.
-KjB
VMware vExpert
Thank you both for the replies, but like you said, that is for another day. -KjB
VMware vExpert
