Ensure HA for servers on stacked Cisco 3750g Switches?

[mezzanine237]

Please bear with me. I'm fairly new to the sys admin world. Though I have a grasp on Cisco Switch technology, the grasp is certainly not solid. I've been tasked by my IT director with finding a device-level redundancy plan for our critical systems. We have four stacked 3750g switches. How would I setup the technology so if the switch with the servers connected were to fail, the downtime would be minimized? Should I deploy a RPS2300? What about the supervisor engine? From what I understand, the supervisor engine is virtual when using stacked 3750s. Is server NIC teaming neceassary? Does the LACP protocol need to be considered? As you can see, I've got a lot of catching up to do. Ultimately, I need guidance so I'm not this plan in the wrong direction by confusing appropriate technologies.

Thanks in advance.

[Joseph W. Doherty · Accepted solution]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

You've already correctly identified some methods for HA with 3750s.

As you note, the stack provides "supervisor" redundancy, i.e. if stack master fails, another stack member will take over.  One thing to watch for, if your stack master is running IP Services, you'll want at least one other stack member to have that IOS installed (and licensed).

Regarding hosts, ideally if they support Etherchannel/Portchannel to the stack, you can have critical hosts connected to two different stack members, so if one path fails, connectivity isn't lost to the host.  For hosts that don't support that, or are not critical, you might have some "spare" VLAN ports in other stack members.  I.e. if a stack member fails, manually repatch such hosts to another stack member port.  (If fact, ideally, you might have one additional stack member already in the stack, so for such single connected hosts, downtime is the time it takes to repatch [then you work about replacing the failed stack member].)

On the power issue, the RPS would allow usage of a secondary power circuit and it also covers, I believe, failure of a stack member's A/C power supply (those don't fail too often, and if it does on a 3750G, you might need to replace the whole unit[?]).  However, the RPS doesn't handle loss of A/C power on both paths (and when it takes over, I also recall, you need to reload the stack to revert off it).  So, you might also want to consider UPS too (if other parts of the network might still be operational).  Depending how you implement UPS, you might not need an RPS, for example if each stack member had its own UPS and each UPS could be reconnected to another power line.

PS:

For additional stability, if not already running it, 12.2(55)SE8 is considered, by many, as being very stable.

[Leo Laohoo]

We have four stacked 3750g switches. How would I setup the technology so if the switch with the servers connected were to fail, the downtime would be minimized?

Be aware that 3750-series switches are not designed for servers. 

The reason being is because the 3750 is designed for desktop machine.  And because of this, the buffer of Catalyst switches are low. 

For high-speed, continuous traffic servers, Nexus is the way to go. 

For additional stability, if not already running it, 12.2(55)SE8 is considered, by many, as being very stable.

Wholeheartedly agree.  12.2(55)SE8 is the way to go.  This version is the most stable.

[Joseph W. Doherty]

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

Be aware that 3750-series switches are not designed for servers.  
The reason being is because the 3750 is designed for desktop machine.  And because of this, the buffer of Catalyst switches are low.  

To (somewhat) mitigate lack of buffer resources on the 3750 series, if you don't need QoS, disable it.  If you do need it, you may need to tune your buffer resource allocations.

The 3750 series (well the 3750X series does -  see http://www.cisco.com/en/US/products/hw/switches/ps5023/products_qanda_item09186a0080c13273.shtml  - although note is attached to original 3750 series) may provide more buffers resources for the "uplink" ports, so if you have a non-uplink port that's showing lots of egress drops, and if you have "extra" egress ports, try using it (remember there's also copper SFPs).

From the buffer memory note, if applicable to original 3750 series, you might also try distributing ports showing egress drops across the different banks of switches that might be sharing buffers.

Lastly, where possible, Etherchannel might help too, as it might "drain" traffic faster.

[mezzanine237]

I appreciate the guideance, Joseph. It was a big help.