MS250 physically stacked core upgrade without complete outage.

[Technomancer]

I've got a couple of MS250 switches which are physically stacked that act as my core.  Running off this core is my VMWare environment and SAN.  In order for everything to stay happy, my VMware environment needs to be in constant communication with my SAN.  If VMWare loses communication with the SAN, all the servers crash.  We want to avoid this situation, which is why I've got a stacked pair of switches with redundant connections to the VMWare environment and SAN.  This is great until you want to perform a firmware upgrade.  You upgrade the stack and the whole stack reboots at the same time causing the entire VMWare infrastructure to crash.  There has got to be a better way to upgrade a core that doesn't cause everything to crash.  I mean, isn't the whole point of having a stack redundancy?

[alemabrahao]

The Stack does not provide you with redundancy, but rather the possibility of configuring more than one switch in a logical way as if it were just one.

If you want to have redundancy the best way would be to use VRRP.

https://documentation.meraki.com/MS/Layer_3_Switching/MS_Warm_Spare_(VRRP)_Overview

https://meraki.cisco.com/blog/2014/06/high-availability-for-cisco-meraki-switches/

[Technomancer]

I'd argue that VRRP (Virtual Router Redundancy Protocol) is for routed redundancy, not physical port redundancy.  A stack is for physical port redundancy.  

[alemabrahao]

Yes, but with VRRP it allows you to update one switch at a time.

With stack there is nothing to do, the entire stack will be rebooted.

[Technomancer]

VRRP does nothing for me for port redundancy, only routed protocols.   It is not the solution.

[alemabrahao]

Switch Stacks

Switch stacks are treated as a single device when it comes to upgrades. That is, every switch in a particular switch stack must belong to the same upgrade group. Therefore, you assign the stack to the group rather than each switch. 

Switch stacks can be expanded in the group member list to see details about the switches that belong to that stack.

https://documentation.meraki.com/MS/Firmware/MS_Firmware_Upgrades

[Technomancer]

I understand that.  I disagree with the philosophy.  Frankly the whole statement of "switch stacks are treated as a single device" is sort of moot in Meraki.  In a cat env, sure, it's handy to go to 1 spot for configuration, but you still have etherchannel ports running from each switch back to it's distro layer so that if 1 switch in the stack fails, the other switches in the stack can continue to communicate without issue and when all the stacks are up, you get the best throughput to your upstream.  Point is, you're not going to win this argument.  VRRP is not the answer.  One should be given the option to either reboot a stack one device at a time or all at once.  Forcing an all at once upgrade will basically prevent me from updating my stacks.  

[alemabrahao]

I suggest you open a support case.

[Brash]

I agree with you that the stack upgrade limitation sucks.
That said, I'd also say that an MS250 isn't exactly a datacenter switch for connecting VMware hosts to a SAN.

It's unfortunately one of those things that you need to assess if it meets your requirements.

It's primarily for this reason (along with a few others) that I typically don't put Meraki in the core of any datacenter or large enterprise networks, especially now that Meraki monitored/managed Catalysts exist.

[cmr]

I agree with @Brash, we use stacks of MS355s as our cores, but don't run iSCSI server to SAN connections through them, as we don't want server crashing. 

We use a pair of 8-12 port 10Gb switches for the iSCSI and just manage them via the Meraki stack.  @Technomancer this would be the solution I'd recommend for you as I'm guessing you don't have many devices as the MS250s only have 4x SFP+ ports?

[Technomancer]

the SFP ports run primarily to the IDFs.  Mostly multiple G links to the SAN and VMWare.  As I said to Brash, it's a smallish remote site and putting something bigger in the core would be a waste.  When we redo our primary it will be the MS300's series for the Core.  You're idea is food for thought though. 

[Technomancer]

It's a small remote site (like 142 access layer ports total) so the MS250's as the core work fine.  Going for anything bigger would be overkill.  Heck as it is the MS250's barely even wake up to pass traffic.

[Brash]

From a bandwidth switching perspective, you're right a bigger switch would probably be overkill, but you still need to look at switches which fit the requirements of your design - which it seems here the Meraki switches don't meet.

I'd go with @cmr 's idea of breaking the VMware hosts and SAN into separate switches not reliant on the core stack.