Cisco WCS HA and WCS Navigator HA

A few gotcha's I have noticed regarding WCS High Availability and WCS Navigator High Availability, in no particular order.

WCS

• During installation, you specify that the instance of WCS you are installing is the primary.

• Likewise, you specify the secondary WCS instance during installation on the second box / VM or blade.

• You cannot browse to the secondary WCS web interface until you have failed-over to it. In other words, during normal operation, you cannot browse to the secondary instance.

• You can however browse to the WCS Health Monitor on the default port of 8082 on the secondary WCS, even when the primary WCS is active (non-failover state) - e.g. https://wcs02.deadbeef.com.au:8082/

• The WCS v7 configuration guide states that you must purchase a HA license. This is not required if you are using the Enterprise version of WCS. If you buy WCS with a 1000 AP (or greater) license, you are using the Enterprise license and so automatically get the HA capability.

• Consequently, only a single WCS Enterprise license is required for HA - you do not have to split your license in two (e.g., a 1000 x AP license can remain that way and does not need to be split into 2 x 500 AP licenses).

• In Windows, you cannot test failover by using the GUI tool to shutdown the primary instance. You either need to use the CLI command "nmsadmin.bat -switchover stop" or simulate it through more realistic means (shutdown the primary WCS, yank the cable or shutdown the switchport, etc). Personally I prefer a closer-to-the-real-world test by shutting down the server or switchport but the CLI command method is useful if these methods are not practical. More details at http://www.cisco.com/en/US/docs/wireless/wcs/7.0/configuration/guide/7_0main.html#wp1072955.

• One secondary WCS instance can provide HA for multiple primary WCS instances. This point does not seem to be particularly well-known. The box / VM or blade providing your secondary HA instance may need to be beefier than the primary WCS boxes if you want to allow for multiple primary failover's. That is, two primary's requiring 4 GB of RAM each may need 8 GB in the secondary in the case of both primary's failing.

• You must either manually point (your browser) to the secondary in a failover scenario, employ some DNS redirection tricks or similar redirection bizness.

• When you first log in to the WCS Health Monitor, the authentication key requested as your login credential is not the key you have specified during HA configuration but in fact the root password for WCS. Later you can use the key to login.

• Do not have the WCS directory or WCS log files open when testing failover. This will prevent failover from... failing over, presumably due to database file access issues. This is stated in the doco but is easy to forget when trouble-shooting. Ironically, I had log files open to troubleshoot a separate failover issue, which caused this (second) failover issue. Doh!

WCS Navigator

• WCS Navigator is not available in a HA configuration. I don't see this as a major issue as it is really just a WNMS of WNMS's. Your WLCs and WCS instances will not be affected if Navigator goes down.

• In the case of a WCS failover from primary to secondary, the WCS v7 configuration guide states that Any Navigators in the network start monitoring the secondary WCS - this is not the case. WCS Navigator does not support WCS HA. In a failover scenario, the primary WCS is shown as down and WCS Navigator has no knowledge of the secondary WCS. If you add the secondary WCS to Navigator, it shows as a completely separate WCS instance and therefore it appears that you have double the number of WLCs and APs. Apparently a feature request is in.