× NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Orbi WiFi 7 RBE973
Reply

M4300 stack vs non stack, VMware and iSCSI setup

maindriver
Star

M4300 stack vs non stack, VMware and iSCSI setup

Hi,

 

We have

3x HP servers, each with a 2x 10GB NIC. (VMware hosts)

2x Synology servers, one is SSD, one is HDD, each with 2x 10GB NIC.

 

I'm not sure of the best way of setting this up.  The stacking failover is way too slow in my opinion.  Also adds a problem that you can't upgrade the firmware idependantly on them, the whole lot needs to be taken down for firmware upgrades.

 

Switches we have are all M4300 series.

 

-----

 

First is how I had planned to set them up.

LAG from core switch (24X24F) at a different location with 2x10GB uplinks which feed a stack of 8X8F switches

Stack is linked via 2x 1M SFP+ cables

LAG not set on VMware hosts as it's not advised.

LACP set on Synology boxes and LAG created on corresponding switch ports on the 8X8F switches.

Each ESXI host and storage box to be connected to either side of the stack.

 

In theory, surviving single switch reboots etc.  However the pings during failover etc worry me (drops a couple of pings when picking a new stack master)

 

vmware-stack.png

 

 

 

---

 

Second option is to have 2x 8X8F set up independantly, is this a safer option? Removing the LACP / LAG groups completely. 

 

 

 

vmware-non-stack (1).png

 

 

 

Model: XSM4316S|M4300-8X8F - Stackable Managed Switch with 16x10G including 8x10GBASE-T and 8xSFP+ Layer 3
Message 1 of 2
msi
Luminary
Luminary

Re: M4300 stack vs non stack, VMware and iSCSI setup

Hi

 

You "sort of" can upgrade the firmware independently within a M4300 stack as @LaurentMa discussed in this thread here: Reboot all stack members, then the standby master, and finally the old master. However I have come to realize that during such an update you will have a temporary firmware code mismatch until you have rebooted the stack master AND all the ports of the rebooted stack member remain down until you reboot the stack master. When the old master reboots, a new stack master quickly gets elected and the ports of the new stack master and the other (rebooted) stack members ever so quickly change to UP status. (During a code mismatch I could not initiate a failover of the stack master to a backup standby switch.)

 

I have to say that I was also surprised to learn that many other stackable switches from other vendors don't support staged updates of stack members but only certain product lines that are usually in an even higher price segment or focus on datacenter switching.

 

TL;DR: Since you use iSCSI where I/O timeouts can lead to host or VM crashes I'd rather consider the second option. For the iSCSI part, consider making 2 VLANs and 2 Subnets where 1 subnet/VLAN is only on first switch and the other on the second switch. Then you can configure multipathing on the VMware side. With Linux and Windows you can often configure round-robin mode where both connections are used in active-active mode. However I suggest you read up on how to properly do this by reading both Synology and VMware manuals on that topic and figure out a way how to get this configured properly. I'd discourage combining LACP and Multipathing together.

Message 2 of 2
Top Contributors
Discussion stats
  • 1 reply
  • 1443 views
  • 0 kudos
  • 2 in conversation
Announcements