topic Re: SZ-100 Hardware redundancy in SmartZone and Virtual SmartZone

SZ-100 Hardware redundancy

matthew_kopishk — Wed, 28 Jul 2021 15:28:18 GMT

Hi Everyone,

I asked this question earlier but now I have some more details and need some guidance.

I have an SZ-100 (a SZ-104 to be exact). I have not had good luck RMAing equipment recently with Ruckus, slow response, and slow shipping. If our SZ-100 went down for some reason I simply can't wait a week plus for Ruckus to get me a new controller.

Our setup is very simple, a single cluster serving a small campus of 70 APs with 2 wireless lans.

My initial plan was to get another SZ-100 and do an active-active setup with the second controller being in another building. I had an open case with a Ruckus Support Engineer for an unrelated issue and ran this plan by him and he said it would be easy to implement.

In the meantime, I went to source another SZ-100, and of course, they're NLA. The vendor I was suggested an SZ-144 as that's what they had listed as replacing the SZ-100. I OKed it, took a quick look at the specs, and noticed the SZ-144 had quite a bit more capacity but figured that couldn't hurt. I did ask the Support Tech and he assured me that the 144 would work, I just couldn't mix SZs and vSZs.

That brings us to today, I was talking to another Ruckus Support Engineer (same unrelated issue as above but I think we resolved it this time) and mentioned my plan and he said I could NOT add my SZ-144 to my SZ-100 cluster in an active-active setup. So now I'm sitting here with what looks like a very expensive paperweight.

I honestly wish I had pumped the brakes on the the SZ-144 as it was also a considerable price increase as well. We were rushing to close out the budget year so things happen quickly.

What are my options? I feel like I'm stuck between a rock and a hard place at the moment.

Thanks,

Matt

Re: SZ-100 Hardware redundancy

DarrelRhodes — Wed, 28 Jul 2021 16:20:43 GMT

Hi Matt,

Thanks for your detailed explanation of the difficult situation you find yourself in.

I'm pleased to hear you've had solid advice from the Ruckus support engineer but, of course, disappointed to hear you were given incorrect information (by a partner support tech?) regarding inter-mixing of SZ100 with SZ144. There is a Ruckus support advisory confirming it is not possible to inter-mix the two controller platforms: https://support.ruckuswireless.com/articles/000010857

We had to EOS SZ100 at relatively short notice due to the EOL of a component used in the hardware by a 3rd party supplier. It also gave us the opportunity to increase the performance and resilience of the replacement SZ144 platform.

I would always recommend a customer has at least 2x on-prem clustered controllers (whether hardware appliances or VMs), however I appreciate that's not helpful right now!

I believe the speed of RMA replacements are challenged with the current global silicon shortage that is affecting all products, apologies for this.

In my view it would be best to aspire to ultimately have 2x SZ144 controllers in a cluster (active-active redundancy). However I understand until budget is available for this, you need a 'Plan B'.

It is possible to migrate the configuration from SZ104 to an SZ144. Therefore you could theoretically run an active > cold-standby scenario, with the SZ-144 being a 'cold-standby' and having the same IP address and (migrated) config as the SZ104. Please note this is not an officially-supported solution, will be at your own risk and will likely be service-interrupting whilst the APs deal with the SZ100 heartbeat loss and SZ144 reconnection and reconfigure (even if it's with an identical config).

The main commercial downside to the above (at best, interim) solution is the issue with AP licensing. In an active-active cluster, licenses are shared between the SZ controllers but in the interim soution described above, each controller would need to be indvidually licensed for all APs.

I don't believe SZ144 configs can be reverse-migrated to SZ100, so in the interim solution, the SZ100 will always need to be the 'primary' controller/configuration.

I would recommend reaching out to your Ruckus Partner to liaise with your local Ruckus SE to see if they have any further help or suggestions. Please let me know your location, if you'd prefer for me to do this directly within Ruckus.

Good luck and best regards,
Darrel.

Re: SZ-100 Hardware redundancy

david_black_594 — Wed, 28 Jul 2021 16:48:03 GMT

You need a better Ruckus Partner. Unlike ZoneDirectors that included a free limited-lifetime warranty, SmartZones come with only a one-year standard warranty. After one year, there is zero coverage. So with SmartZone hardware, it is highly recommended to always buy and maintain an active support plan. Purchasing and maintaining a Ruckus Support plan provides you with advance NBD replacement, firmware updates, TAC, etc.

You were told correct on clustering by the second ruckus guy - all nodes must be the same model and running the same version of code. If you need 100% high availability, then a multi-node cluster is recommended. However, depending on the details of your configuration, you can probably get close to high-availability on a single SZ. A little more info is needed before wading into that.

- authentication method is use for each wlan?

- using dpsk?

- what ap models?

PS- the 144 is a much better box than the 104 or especially the 124, so don't feel bad about buying it.

Re: SZ-100 Hardware redundancy

matthew_kopishk — Wed, 28 Jul 2021 17:04:08 GMT

@darrel_rhodes

Hi Darrel,

You confirmed what I had feared. I would suggest updating your "SmartZone Cluster Redundancy Deployment" docs to reflect these nuances as that's what I was using as my initial guide.

I have to say I'm pretty frustrated with the situation at the moment. I can't simply keep throwing money at the situation as we're a public school with limited funds. Our SZ-104 is also less than 2 years old and should be more than adequate to manage our network.

I should have done more research on my part BUT point-blank asking one of your Technical Support Engineers if it will work and getting misleading info kind of mitigates that.

The only option that seems remotely viable at the moment is the cold backup scenario BUT I think you are saying I would need to purchase AP licenses for both controllers to make this work? If so that makes this option even less viable.

I'm in Maine, I'm hoping you can put me in contact with someone who can help resolve this issue.

Thanks,

Matt

Re: SZ-100 Hardware redundancy

matthew_kopishk — Wed, 28 Jul 2021 17:22:11 GMT

@david_black_5940365

I agree on the partner end of things. That being said my vendor has had a hard time getting info from Ruckus when trying to quote me prices so I think that's a two-way street.

Anyway, to answer you questions:

WPA2 on one wlan, the other is open

No on the dpsk

R610

It's nice to hear that the SZ-144 is a better unit but from the sounds of it, I can't transfer my AP licensing from the SZ-100 so that is just another roadblock for me. We also purchased 3 years of support for the SZ-100 and for our new SZ-144.

Thanks,

Matt

Re: SZ-100 Hardware redundancy

DarrelRhodes — Wed, 28 Jul 2021 17:35:06 GMT

Hi Matt,

David asked some very pertinent questions, ones I thought to ask but my response was already at risk of TL;DR!

The (positive outcome) is that your network doesn't appear to be reliant on the SmartZone for operation. WPA2 (assuming PSK? If it's WPA2-Enterprise then this is more complex) and open networks (providing there's no controller-based captive portal) will continue to operate even if the SZ 'disappears'.

Also backing-up David's comment about the SZ144 - it's a FAR superior unit for sure. Higher capacity APs and ICX, dual PSU, replaceable fans, 4x 1Gb + 4x10Gb data plane and will be supported with new firmware and updates for a long time to come.

Regarding licensing, there can be some flexibilty here but I suspect not enough to initially give you a resilient controller solution.

I have sent a link to this page to our global head of Education for his thoughts.

I'll respond with an update as quickly as possible.

Best,

Darrel.

Re: SZ-100 Hardware redundancy

matthew_kopishk — Wed, 28 Jul 2021 17:50:38 GMT

@darrel_rhodes

Yes, I am using WPA2-PSK.

So it sounds the APs would just keep trucking with the last known config if the SZ went down?

If that's the case that does change things a bit. I've had a ZD1200 go down in the past and it took out the whole wireless network with it, I just assumed that the same would happen with the SZ100.

If this is the case then that makes me feel quite a bit better, though I still have the whole SZ100/144 issue to deal with. If the AP licenses were transferable I would consider moving from the SZ100 to the SZ144 and calling it an upgrade.

Maybe some light at the end of the tunnel?

Matt

Re: SZ-100 Hardware redundancy

david_black_594 — Wed, 28 Jul 2021 18:29:00 GMT

Matthew,

You don't need to purchase any licenses. Unlike with ZoneDirectors, SmartZone licenses do not belong to a piece of hardware - they belong to the school and you can move them from controller to controller as see fit. Using the LiMan tab on the support portal, you can assign the licenses (some or all) to any controller the school owns (eg: the 104). You can also revoke some/all and reassign them to a new asset (the 144). There is never license obsolescence with SmartZone.

You're not using radius or dpsk, so you can achieve 99% high availability with only one SZ. The only thing you'll lose is the ability to manage (add new wlans, change a psk, status reports, etc). There's a couple of default setting you need to modify and I'll add more later.

Re: SZ-100 Hardware redundancy

david_black_594 — Wed, 28 Jul 2021 18:59:28 GMT

Missed your earlier post regarding the 1200 which touches on another major difference between ZD and SZ architectures. In the case of a ZD managed network, if you only have one ZD and it goes down, the whole network is down until you get it back up. You can add a standby ZD and enable SmartRedundancy which will allow you to recover, but it not a hitless failover. All AP tunnels have to be estabilished to the surviving controller, and all wlan sessions are terminated and have to be re-established with the clients. There's sort of a minute or two where things are messed up and afterwards everything is back to normal. I think you said you had 70 APs and one ZD1200, so the partner should have sold you 65 licenses since the controller already includes 5 free ones, so a total of 70. Add a second ZD1200 and enable smart redundancy and the licenses pool together - 70 from zd1 + 5 from zd2 = 75 total licenses on both controllers.

Anyway, with ZD, the controller provided a lot or the services (control, management, mesh, dpsk, captive portal, keeping track of end user sessions, roaming etc...). With SZ, the APs have grown up - they take care of themselves now. There's still a few things that require the mother ship, but you're not using them.

Re: SZ-100 Hardware redundancy

matthew_kopishk — Wed, 28 Jul 2021 19:10:27 GMT

@david_black_5940365

Thanks for the clarification on the licenses. That should make things really simple. Up until 2020 I had only worked with ZD1200s so I'm quite familiar with their licensing.

As far as the ZD1200 I mentioned it is at a separate site unrelated to the one we've been talking about. At some point, I would like to roll the APs that are on the ZD over to the SZ but I know that's a bit of a process on all ends (hardware, management, and licenses) and one that I'll tackle at a later date.

Thank you so much for your help,

Matt

Re: SZ-100 Hardware redundancy

DarrelRhodes — Thu, 29 Jul 2021 11:22:11 GMT

@matthew_kopishke

Hi Matt,

At the risk of swamping you with information, I just wanted to confirm some of the points you've raised:

i) "The APs will just keep trucking" (I love how you phrased this!) - absolutely! SZ-controlled APs don't need for the SZ to be present for most of their day-to-day operations.

ii) ZD vs SZ architecture: as David mentioned, the two platforms couldn't be more different. Losing ZD means your entire Wi-Fi is down, with SZ we removed the AP's dependence on the controller for most functions.

iii) Licenses: I'm cautious about commenting on licenses on a public forum as there are lots of variables. However if, as David suggested, you are able to transfer them from the SZ104 to SZ144 using LiMan or via a Ruckus support ticket, then your suggestion of "calling it an upgrade" is definitely the way to go! However I would still recommend you budget for a second SZ144 when possible. Hopefully then you can retire your ZD and host all your APs on the single SZ-pair?

Finally; I'm looking to get your local Ruckus SE to contact you to ensure you're looked after from here on!

Best regards,
Darrel.

Re: SZ-100 Hardware redundancy

matthew_kopishk — Thu, 29 Jul 2021 15:05:35 GMT

@darrel_rhodes

Thank you for your help.

I'm looking forward to talking to an SE as I have a few other questions I would love to get cleared up. I'll also take a look at the licensing in LiMAN and see if can make some sense of things on my own.

Matt

Re: SZ-100 Hardware redundancy

david_black_594 — Thu, 29 Jul 2021 15:16:40 GMT

@matthew_kopishke you're welcome to contact me if I can be of assistance. We're a Ruckus Elite partner, but we're in Houston. So, you do need to follow Darrel's advice and get some qualified local help. I can also help you with any technical or configuration questions, or a second opinion. I think my email is listed on my profile. If not, post a message here and I'll reply.

Re: SZ-100 Hardware redundancy

david_black_594 — Thu, 29 Jul 2021 15:30:29 GMT

@matthew_kopishke BTW, I meant to ask about the open network... Does it have a traffic policy that denies access to the school's internal network (ie, is it internet only)?

Re: SZ-100 Hardware redundancy

matthew_kopishk — Thu, 29 Jul 2021 15:42:56 GMT

@david_black_5940365

Yes, it's a separate private network that we maintain for Student/Parent access on personal devices. Zero access to our primary network. We also use QoS to throttle the public network.

Re: SZ-100 Hardware redundancy

eizens_putnins — Fri, 30 Jul 2021 10:23:22 GMT

It is really the exact reason, why I always use vSZ, and never appliances. With vSZ you don't have any issues with hardware replacement or future compatibility. I have never recommended any customer to use SZ-1xx, as I haven't yet customer, which isn't already running some hypervisor. And even if you need to buy a server to run vSZ, it still makes sense to go for vSZ, as support is cheaper and easier this way.

You most probably have to look for a new Ruckus partner to work with, as you got bad advice more than once.

For a solution I would say you have to think about opportunity to migrate to vSZ and sell your SZ-100/144. You always could use vSZ to have a cold backup in case of disaster with SZ, as you just need to reassign AP licenses to vSZ to get everything running, but it is not the best way to do things.

To get reliable redundant system migrating to vSZ the only new costs would be VM RTU licenses and they support, plus you need some space on your virtualisation equipment. Main part of costs (AP licenses and they support) can be simply moved from SZ to vSZ in LIMAN very easy.

I definitely recommend to move to virtual solution and sell your both SZ-1xx.

In the worst case, if you have no hypervisor available, and no real budget, you always can buy 3 identical HP DL360/380 G8 servers on EBAY, they typically cost about 400-500 Eur with 2x Xeons and 128 GB RAM, and run vSZ over free VmWare ESXI (with one spare server on shelf you'll be fully covered for any hardware fault). Many SMB businesses use them, they are built as tanks, and very cheap to source.

Re: SZ-100 Hardware redundancy

david_black_594 — Fri, 30 Jul 2021 10:57:15 GMT

@eizens_putnins Matthew is with a school, and schools in the US procure the vast majority of their technology using ERate. If that's the case here, Matthew is forbidden from selling anything for 5 years.

There are also plenty of reasons why a hardware smartzone could be a better solution than virtual. For one, an enhanced feature set. Before recommending hw or virtual, it's best to thoroughly understand the client's situation, capabilities, and requirements before recommending one path over the other.

Lastly, I would never recommend "free" VmWare ESXi for anything other than a lab, eval, or home. I would never put it in a production environment, especially a school. It is not an officially supported environment - if there's a problem and the client needs TAC, the case may be rejected due to an unsupported configuration.

Re: SZ-100 Hardware redundancy

eizens_putnins — Sun, 01 Aug 2021 21:03:10 GMT

There are no additional features in hardware smartzone (which is in fact SZ-E + SZ-D installed directly on hardware server). Actually, vSZ-H has much more features (by the way, I never understood why some people install vSZ-E, license and hardware requirements are the same, why limit yourself?).

The only reason to use hardware SZ I see when customer doesn't have virtualization infrastructure or specifically don't want it. Or is stuck with already bought hardware.

It is easy to sell SZ-1xx to customers without experience, as most other vendors have the most preferred version hardware controller. But there are compatibility risks as we see well in this case, and in case of hardware fault replacement will take more time... Virtual machine can be recovered very fast and even on different hardware.

Of cause, in some cases hardware SZ is a good solution, but in typical situation vSZ has just too many benefits. It is the same situation as with servers -- sometimes dedicated server is a good choice, but in 90% - virtualization is much better...

In this case, to get full redundancy is eather to get second SZ1xx (old or new), or put both SZ-1xx on shelf and buy 2 licenses for vSZ VM, I don't see other way. Second route is a way cheaper (if you have virtual infrastructure)...

But may be this all effort was just because of previous experience with ZD1200?

As David mentioned, with vSZ APs there are 2 distinct differences from ZD1200:

1) in SZ/vSZ system AP service customers, even if SZ is unavailable. Of cause, there is no management, monitoring, and services, which need SZ (such as RADIUS authentication, using SZ as a proxy, or guest portals) will not work.

2) AP capacity licenses are attached to customer account, and can be freely moved between SZ/vSZ devices on same account. For each vSZ node you need also RTU license (which licenses vSZ VM with 1 AP capacity license).

If you have system with just 1x ZS/vSZ, and it becomes unavailable, WPA2-PSK networks will work (both existing and new connections). If you use Radius authentication, you in principle may configure direct authentication from APs (which is a pain, as you need to configure 70 APs as clients on your RADIUS server than, and if it is MS NPS, it will be over 50 client - limit for NPS, so there will be need for additional Radius proxy).

So much better to have redundant setup. And really the difference is 1 RTU license and hypervisor resources to run it.

So if there are virtualization resources available, even if there is no way to sell hardware SZs, it still will be probably a best solution to just reuse AP capacity licenses from SZ-1xx, get 2x RTU licenses extra and go virtual. 70 AP capacity licenses are major part of the cost of SZ-1xx, but as it can be reused, losses are minimized.

In opposite case - if no virtualization resources available, there is unfortunately no solution other than to get second SZ-1xx to have a pair of 2 identical devices...

But first of all you need to get better reseller for future -- who knows the solution (such problems as your's are common with sales guys which just work with price-lists and in the best case have read datasheet).

I have recently got to fix project where some Ruckus reseller designed a project to add vSZ to existing network with ZD3000 and 100x APs-- for redundancy. It took some time to make customer understand that it doesn't work that way -- that moving APs from ZD3000 to vSZ is possible, but it can't be used as standby backup feature - as this process involves firmware replacement and 2x factory resets for each AP... It was surprise for them, that redundant vSZ system actually required only 1 additional RTU license with support, + resources to run the second vSZ VM, and that EOL ZD3000 can be just safely retired...

Re: SZ-100 Hardware redundancy

david_black_594 — Mon, 02 Aug 2021 05:55:48 GMT

@eizens_putnins Out of the box, all hardware smartzones include the ability to tunnel the data plane. You don't have to buy anything else. With vSZ you have to buy either the hardware or virtual data plane to match what a hardware SZ has right out of the box. Virtual Data Plane is rarely used because it requires direct IO. That is precisely the reason why Ruckus quickly developed the hardware data plane appliance for use with the vSZ.

As for essentials vs high-scale there are good reasons to choose one over the other based on the client's requirements. WIthout adding anything, Essentials will provide 14 days of history - High Scale provides only 24 hours. High Scale adds a layer of complexity (multi-tenancy) that's not needed in smaller deployments where it would never be used. In such cases it clutters up the system with unnecessary complexity.

Re: SZ-100 Hardware redundancy

eizens_putnins — Mon, 02 Aug 2021 10:44:45 GMT

This is correct ( but I mentioned both things), and still, hardware SZ doesn't provide any additional features, as it is basically same software on specific server.

1. Yes, hardware SZ includes Dataplane (as I mentioned), but in most cases it is not needed/used --as distributed forwarding is usually more efficient design. There are good use-cases (such as replacing VPN in multi-brunch design), but in simple setups, as schools, in my experience, dataplane usually is used when Ruckus is used in design directly replacing Cisco setups -- without redesigning a network.

2. About history, you are right, graphs will show only shorter period. Of cause, there is no good looking on 2 weeks old graphics, and if you configure scheduled reports, you can look on them later. What is much more important for any troubleshooting, that outside of time-limit of statistics, there is a limited capacity for events, (10k for vSZ-E and 300k for vSZ-H). So normally you just use external syslog server to store logs (or use Ruckus Analytics, which is much better).

3. High Scale isn't different in hardware requirements and isn't more difficult to manage, you just have more options, which you are free to use or not to use. If you look on the history of Essentials feature set, you'll see that in the very beginning it was very basic (or "uncluttered" if you prefer), but later it got back many features from High Scale (including Zones) - as requested by users.

4. Multi-tenancy is just additional feature of vSZ-H, and if you don't use it, there is no additional complexity... But it is really nice and useful to be able to give access to administration of some part of the network to somebody.

5. One of the biggest drawbacks of vSZ Essentials was the fact that when you upgrade the vSZ-E controller, all APs are upgraded -- exactly as with ZoneDirector. This is a very inconvenient "feature" in most setups, bigger than just a few APs. I am not sure if this limitation is still there in the latest version - as I very rarely use vSZ-E. But of cause, you can always look on that in opposite way -- "you have to do nothing else to upgrade firmware on all APs when you upgrade a vSZ-E". And this can be correct for some setups.

But in most big systems you prefer to work on upgrade in daytime, but reboot all APs ar night...

So this is about what customer wants from networks and how he design them.

For people using legacy, Cisco-like setups, dataplane is necessary in each setup, otherwise, it is rarely used.

If the administrator is used to have all APs in the same domain and zone, he doesn't need any additional domains, basically -- if he is used to leaving without advanced features, he doesn't need them, doesn't have to learn how to use them, and obviously will prefer "uncluttered" setup.

And it's OK, there are a lot of people that think that all WiFi systems are the same as Cisco, just different brand, and they prefer to use different gear in "Cisco" way, as they don't think there can be any different way -- but there is and more than one!

It is how I see it, anyway...