Cisco acquires Whiptail

Opened up my work email this morning to be inundated with mails about Cisco acquiring the flash-array startupWhiptail – for $415m…

What makes this interesting was several years ago when I attended the launch of UCS blades, someone in the audience questioned whether Cisco would enter the storage arena…. the answer at that time was “No Way… Cisco won’t do storage!”
This has pretty much been their response for the past few years – even though the market has always been awash with rumours that they were on the prowl for a storage company (*cough* NetApp *cough*).

Cisco is one huge beast….. it has its paws in every part of the IT infrastructure…… and if I’m honest, they’ve probably pissed off a lot of people along the way….. =)
VMware – UCS Director (Cloupia)…… HP – UCS servers…… and now EMC/NetApp.

So it seems all the noise coming out of Cisco is that this acquisition is so that they can build a “flash tier within their UCS platform”….
Makes sense as the market view is that since storage is getting faster (flash/SSD), bringing it closer to the compute resources will help accelerate application/OS performance by using flash as some sort of caching tier.

It’s an clever acquisition by Cisco….. a flash-array start-up which already has products that could be pushed to market or integrated. Plus the arrays leverage a ‘scale-out’ approach to storage where a customer would start small and then just bolt on additional nodes when required – sound familiar?!? Isn’t that what blade servers are supposed to offer? The ability to scale out compute by just slotting in new stateless blades. So what UCS does for compute, Whiptail may offer Cisco for storage!

Cisco marketing bods have stated that they’re still 100% behind their involvement with VCE, so it will be interesting to see what they end up doing with the flash-arrays that Whiptail sells….. surely they won’t just kill all off the work that has gone into these arrays!
Yes, they’ll strip out some of the flash tech to build into UCS, but I still reckon that they’ll release some sort of flash-array to the market!
Afterall, that would be the smart (and logical) thing to do……
Imagine:
Compute – Cisco UCS
Storage – Cisco Whiptail
Network – Cisco Nexus
Cloud – Cisco UCS Director (formally Cloupia)

… all they need now is a hypervisor and they will pretty much OWN a cloud stack!!
Hmm… there’s probably some KVM-based hypervisor offering out there that could be gobbled up! Any suggestions?

So yes, while in the short term Cisco will still buddy up to EMC/NetApp for their vBlock/VSPEX/FlexPod offerings, in the long term I guess this will all be answered by how Cisco go to market with Whiptail….. whether they will continue offering it as a standalone storage array, or whether (like their other acquisitions) they roll it all in as part of a solution bundle.
And whether they push the Whiptail products as being a Direct Attached Storage to their UCS platform rather than NAS/SAN storage (which will directly challenge the likes of EMC/NetApp).

In fact…. I wouldn’t be surprised if they went the way of HP and offered a Cisco/Whiptail storage blade!! (Remember, you read that prediction here first…..) ;oP

Watch this space…… Interesting times ahead!

 

Edit: Just read a really good article by Jason Nash regarding Cisco’s acquisition of Whiptail…. he’s put forward some good points about why Whiptail and how it fits into Cisco’s view of SDDC!

Advertisements

Troubleshooting a vCloud Director Installation

The problem about working full time is it’s really hard to find time to blog, and also to find topics to blog about! =)

One of the great things about my job is we have a solution centre in the office which allows me to play around with kit! =)
Our solution centre is based around an EMC VSPEX architecture….. so EMC VNX storage, Cisco UCS blades and VMware virtualisation!!

I’ve been busy the last week or so putting together a vCloud solution for some of the engineers to play around with, as well as finally completing the detailed installation guide for deploying the vCloud Suite (one of these days I promise I will post it up).

Anyways, so I ended up installing two RHEL 6.2 VMs as my vCD cells on a MS SQL 2008 R2 DB, load-balanced using a vCNS edge….. but when I tried to start the vCD services on my linux VMs, they would say they’ve started (simple service vmware-vcd status command) but wouldn’t give me the vCD web console/UI….. all I got was a Blank Grey Webpage and after a while it would error out saying it couldn’t connect to the website!! Hmmmm……

Anyways, this gave me a good opportunity to test out my troubleshooting skills and offer a topic for my blog! =)

So here goes……

Troubleshooting vCD….

The Log files for vCloud Director are located at /opt/vmware/vcloud-director/logs. There are three main files to look at (well there’s more than 3 but these are the ones I usually use and 99% of the time I can work out what’s wrong):

1. cell.log

This log file provides information on the status of the vCloud Director cell services and the application as it starts up.
Use tail -f cell.log to view the live status when starting a vCloud Director Cell.
A successful start up will allow you to access the vCD web-console/UI and will display a started status for each service, plus 100% for Application Initialization.
Image

Usually if there is an issue with accessing the web-front end UI then it is more than likely that the services are still waiting to complete, as below:

Image

If you’re seeing lots of services showing a “WAITING” status, then check the other logs to determine what could be causing this issue.

2. vmware-vcd-watchdog.log

This log file shows any alerts, errors or information that the vCloud Director cell services maybe experiencing. A healthy vmware-vcd-watchdog.log looks similar to the below:

Image

If there’s an issue, then you could get an ‘Alert’ entry, similar to the one below:

Image

I believe vCloud Director will automatically try to re-start the services as I didn’t see a time stamp for an entry when I manually restarted the service. Also this log looks very similar to what you would get if you typed in ‘service vmware-vcd status‘ as that command reports on both the vmware-vcd-watchdog and vmware-vcd-cell services.

3. vcloud-container-info.log

This log file shows the status of the initial installation of vCloud Director and will log how the application is currently functioning. If you have any errors or failures during installation, this log file will provide you with the details required to troubleshoot the cause of the failure.
In addition, this log will also provide information on any errors that may cause the vCloud Director services to fail to start.
In my case, after doing a cat vcloud-container-info.log | more I discovered the following error:

Image

Turns out that the error shows that the vCloud Director cell could not resolve its hostname in DNS.

When I went through the pre-reqs before installation, I realised that I had only put in DNS entries for the two IPs used for the HTTP and the Remote Console access….. I forgot to put an entry into DNS that resolved the hostname of the Linux VM to the HTTP IP address.
A quick edit to DNS and then a restart of the vCD services fixed the problem I experienced.

4. vcloud-container-debug.log

This log file shows the debugging information. The detail in this log file will be dependant upon the level of debugging set. I didn’t actually end up looking at this log as the error was discovered in the -info.log…. However, it’s another port of call if you can’t work out what’s causing your vCD services to fail.

Rights….. blog entry over…… I’m off to eat my dinner! =)