SZ-100 Hardware redundancy

[matthew_kopishk]

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

[eizens_putnins]

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.

[david_black_594]

@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.   

[eizens_putnins]

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...

[david_black_594]

@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.     

[eizens_putnins]

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...