Remember that first time hearing about vMotion? The, how is that possible, disbelief moment. I had that again a few years ago while watching a presentation on how you could leverage the stateless capabilities of UCS. The presentation entailed converting a running compute blade into a completely different system and then back again. Now, I’m not talking (well writing) disk imaging, I’m talking manipulating a boot from SAN setup in such away that one minute it’s say a Linux box and the next (well 11 minutes later) it’s a Windows box. While this made for an entertaining presentation I didn’t really have a real world use for that sort of thing.
Mining for gold from VMware vCenter’s DB…
VMware vCenter as we all know has a wealth of information in it’s database. VMware has provided us a great tool in PowerCLI to pull this information out of that DB via the vCenter API. While this is great, one very annoying aspect is the amount of time it takes for PowerCLI to run certain commands (especially against a large VC). I find I only write PowerCLI scripts when A) I need to actually tell vCenter to do something (sVmotioning all VMs on one datastore to another for a random example) or B) the query data I want isn’t stored in the DB (realtime host NIC link status for example). When I want data quickly (ie realtime) for reports I connect and query the vCenter DB directly. **WARNING, THIS IS NOT SUPPORTED BY VMWARE**. Well not entirely true, it’s my understanding that it’s OK to use the DB views (but not actual tables). Since I’m writing the queries anyway, I don’t mind that I can’t call VMware when one of my queries doesn’t work or that a change they make to the table structure (schema) could break my query/report. I’ll live with that to have the speed and power of querying directly.
Your inventory, your faults and your motorcycle – give them to me NOW!
So along the way I’ve learned a lot about the UCS XML API. When I was first introduced my (meager) development background screamed ‘not a web service, weak!’. After the initial negative first impression I’ve come to appreciate the simplicity, speed, and wealth of information contained in the API. When I first started with it my goal was to get a handle on multi UCSM management for things like inventory and fault management.
Before I go much further for those getting started I’d suggest looking into the UCS Dashboard, GoUCS tools as well as the powershell modules and .NET module available for download on the Cisco Developer network. Unfortunately, being an early adopter I didn’t have that option as at the time these tools simply didn’t exist. SO, I wrote my own dashboard using open source technologies.
Our biggest issue was the fact that on day 1 we had multiple UCS pods. While I love the UCSM for all the reasons I already blogged about, having more than 1 UCS became a bit of a challenge to manage without some expensive 3rd party management tools. Simple things like a central location for all of our inventory data, fault data and a single interface to search and launch KVM consoles was something that didn’t exist (again UCS Dashboard does much of this now).
A day in the life with Cisco UCS…
So you’ve heard the marketing spiel, read the technical specs and read the vendor blogs. You still scratch your head and ponder, ‘is it worth it?’. So before we get there let me give a little background as to who I am and what I do. I’ve been working with Cisco UCS since 2009 and have implemented a number of different vendor’s server systems during my 17 year stint in the IT industry. By the year end I’ll have designed, implemented and managed over 40 UCS domains (or Pods as we like to call them). A pod in our world is typically a pair of FI’s (fabric interconnects), 10 chassis and 80 server blades spread across 3 racks.
Here are the pain points we eliminated by implementing Cisco UCS.
I. Servers
- Loosely coupled systems management (reliance on server mgmt tools talking to server mgmt agents) With Cisco UCS the reliance on management agents is removed entirely because the management platform is woven right into the hardware. The UCSM (UCS Manager) knows everything about the servers it manages at all times. From faults/failures, power, cooling, and bandwidth it simply doesn’t need an agent to report that data. Also you don’t have orphaned or unknown systems that show up as garbage in a MGMT tool. Below are some examples of the annoyance that is no longer:
First post…
I guess it’s not as cool when you are the site owner. Then again is that ever cool?
Posted in Uncategorized
Leave a comment