UCS Performance Manager 2.0

[jasonsha]

UCS Performance Manager 2.0 is now available

Built with technology from ZENOSS, Cisco UCS Performance Manager (UCSPM) is a Performance Monitoring and Capacity Planning tool custom built for UCS Administrators.  UCSPM provides visibility into UCS Hardware, LAN/SAN Switching, Storage Arrays, Hypervisors and Server Operating Systems - all from a single console.

UCS Performance Manager 2.0 features a new underlying platform built for High Availability and Scalability. This new release will allow deployment of multiple virtual appliances that can be pooled together, with the ability to scale the UCS Performance Manager application  requirements across these pooled resources.

New Software Features include:

- Central Authentication using LDAP

- HTML5 User Interface

- Scalability to 2500 UCS Servers

- Configurable data collection interval (default = 5 minutes)

- Northbound JSON API for integration and automation

- Capacity forecasting (forecast and alert on future thresholds)

- Dependency Views (pivot on a resource and identify relevant dependents/dependencies)

- Support for UCS Central and UCS Mini

UCS Performance Manager 2.0 is a free upgrade for existing customers (UCSPM 1.1.x license files are supported in UCSPM 2.0).   Existing Performance, Modeling and Event data can be migrated from UCSPM 1.x deployments to a UCSPM 2.0 instance.

UCSPM 2.0 contains a built-in 30-day eval - Download from Cisco.com today:

Download UCSPM Software today:

- Software

Documentation:

- Release Notes

- Install and Getting Started Guides

- Migration Guide

- Admin Guide

- User Guide

Deployment Calculator:

UCSPM 2.0 Deployment Calculator

UCS Performance Manager 2.0 API Documentation

[thomsonac]

It appears that DNS resolution is not working inside the docker application.  I've verified that DNS works correctly on the VM itself.  If I add a UCS domain via hostname inside UCSPM the process fails.  Replacing it with the IP works successfully.

[thomsonac]

I opened a TAC case and was told this is a known issue.  Is there a timeline for a fix?  Unfortunately this bug makes version 2.0 useless for us.

I'd also like to comment on the decision to move to a docker application.  I've struggled to come up with an actual reason to do this except for "Docker is the cool new thing."  Further, to add insult to injury, you must add a local host file entry in order to actually access UCSPM.  That is insane.  It's clear that whoever decided this was a good idea has not worked in a corporate environment with many people accessing an application.  Luckily, as I have access to our corporate DNS setup, I was able to create a CNAME record for the subdomain to point back to the host itself but in many, many environments this is not feasible.

I'm disappointed that the product manager for UCSPM let this happen.

[jasonsha]

Hi Alex,

What is the TAC Case number?  I will be happy to investigate.

The PC where the client browser is bring launched must be able to resolve the Virtual Host Name of the UCSPM Application (as seen in Control Center). This Virtual Host Name should be:

https://ucspm.<hostname_of_master_applianceVM>/

If you can ping the Virtual Host Name  (from the client PC) and resolve to the Master Appliance VM IP, I would expect success pointing the browser to the UCSPM URL (the concept is similar to a web server running multiple virtual hosts).

I appreciate your feedback regarding the new platform.  We are actively working on changes that will simplify the initial deployment (specifically targeting the issues encountered regarding the name resolution requirements).  The new underlying platform leveraging Docker and Control Center will not be going away, as it provides HA and the ability to scale the UCSPM application across multiple VM resources.  We will be focusing on changes that will make this new platform more transparent to the user.

I do feel that once you have name resolution working, you will be pleased with the new features.  Looking forward to following up - I sent a "friend request" in Jive, so we can communicate directly on this.

Thanks,

Jason

[thomsonac]

Thanks for the response.  TAC Case 637477703 is open for DNS resolution.

I apologize if I muddled multiple issues in my post.

1) DNS resolution to UCSPM is not an issue, it's just a poor design.  AFAIK any of the major browsers/OSes will not append a DNS search suffix to a URL that already includes a dot (".")   E.g. if the docker host has an A record of "docker.domain.com" and a search suffix is enabled for "domain.com" you can enter "docker" as a URL and ".domain.com" will be appended.  Great.

Entering "ucspm.docker" into the URL bar will not resolve as the OS sees this as a FQDN and will not append any search suffixes (again, AFAIK).  However entering the FQDN for the UCSPM instance will also not resolve by default as this is seen as a sub-domain of the host and DNS will look for the "docker" domain.  Fortunately I have the ability to create DNS records so I had to create a CNAME of "ucspm.docker" to point that to docker.domain.com

Or you can edit the local hosts file for the full FQDN (ucspm.docker.domain.com).

2) As for using docker, ok.  I'm not very familiar with docker so if it provides a whole host of other features then that can be a good thing.

3) The real issue is that DNS resolution inside the UCSPM instance is broken.  This to me is the major oversight.  While #1 and #2 above are somewhat of a matter of opinion, not having functional DNS in the app is a huge bug.  We can add infrastructure resources using their IPs but not their hostnames.  Who wants to look through a huge list of IPs without any friendly names let alone actually update an IP of a switch and have to update all of the hard-coded monitoring locations?

-Alex

[jasonsha]

Hi Alex,

I jumped the gun on my reply.  I sent you a note through Jive with my contact info.

- please send me an email, and we can investigate over Webex.

Sorry for the confusion.

Thanks,

Jason

[marty.booth]

I agree...Deploying this "upgrade" has been a woeful experience for me so far...

But, as sad as it is, this is a typical experience for me when it comes to anything to do with Cisco software!

[jasonsha]

Hi Alex,

Thanks for your time last week - I wanted to summarize the outcome of our testing.

The symptom was that the UCSPM Application could not resolve host names (attempts to register any device via hostname resulted in a failure).  Isolating the issue was a challenge as we found all nslookup attempts from the CLI of the UCSPM Host, or from the UCSPM application context to work properly - to any of your defined DNS server IPs.

We have learned that the Docker networking implementation will instantiate a docker0 interface on the 172.17.0.0/16 network by default.  The firewall rules supporting this internal networking appeared to prevent the DNS lookups requested by the UCSPM Application from being forwarded out to the defined DNS servers (one of which happened to be using the 172.17.0.0/16 IP space).

For the short term, we identified a workaround by editing the network configuration of the host and removing any entry pointing to a DNS server on the 172.17.0.0/16 network.  Fortunately, you had additional DNS servers we could point to that were running on a different network.  For longer term, I am told that there is a Docker configuration we can leverage to define a desired network space for this internal networking, and avoid any potential conflicts with the customer environment.

Once we have this procedure (and test it), we will update you and post updated product documentation.

Thanks again for your assistance and patience on this.  I hope you will now have an opportunity to evaluate UCSPM 2.0

- Jason

[Paul O'Leary]

Add my voice to the displeasure with the upgrade, and the nonsensical DNS design. now I have to setup the new alias and a forwarder on another site to direct my users to a completely new URL.

Pointless.

[jasonsha]

Hi Paul/Alex,

Feedback fully understood - this was a hot topic after the release of UCSPM 2.0.

We plan to release a maintenance release (v2.0.1) within the next couple of weeks, changing the name resolution requirement. Control Center will now listen on a new port, and the UCSPM Application will default to listening on port 443 of the VM Host IP. 

- You will also have the ability to set a different port if desired.

Thanks for your patience, and we appreciate your feedback!