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!

Flash Storage

So Duncan Epping (http://www.yellow-bricks.com) has put together 3 short blog posts about the numerous Flash Storage start-ups that are springing up…… seems every man and his dog wants to start up a flash storage company these days or get in on the high IO/Performance that can be gained by using flash memory or SSDs! =P

Anyways, whilst he hasn’t covered every start-up yet (Notable absences: Nimble, Whiptail, Pure and Tintri)…. it still makes very interesting reading!

http://www.yellow-bricks.com/2013/08/08/startup-news-flash-part-1/
http://www.yellow-bricks.com/2013/08/13/startup-news-flash-part-2/
http://www.yellow-bricks.com/2013/08/20/startup-news-flash-part-3/

Will be very interesting to see what happens in this market over the next few years…. especially with the likes of Fusion IO looking to enter the market with their NexGen acquisition, and the big vendors – EMC (XtremeIO), HP (3Par Flash array), NetApp (EF540) – all looking to jump on the flash/hybrid bandwagon……
The market’s gonna get saturated by arrays, and it’ll be the software and application integration that separates the winners from the losers!

Link

10 most influential bosses in the storage arena

Quite interesting article on The Reg regarding the 10 most influential bosses in the storage arena…..

Surprised at seeing the CEO of Dropbox in the top 10….. as well as the CEO of Amazon and Facebook’s Open Compute Project at 7 & 8….. I guess cloud computing and cloud storage is really coming into the fore now!

Dropbox is pretty much used by most people in the IT industry to share large presentations and software…. great handy tool!

Amazon have pretty much commercialised the aspects of ‘cloud computing’ which explains why they’re there…..

And Facebook are pretty much leading the way with non-vendor specific hardware (although quite surprised Google aren’t listed as I’m sure they’re in the same boat as Facebook with building their own piece-meal hardware and they have vast storage requirements).

Violin Memory’s inclusion over the likes of more established storage vendors like IBM and NetApp is really interesting – especially since they mainly sell all-flash arrays. Then again, I supposed they’re currently one of the ‘innovators’ in the flash-array market and have been making big waves in flash-array tech…..

Not surprised that NetApp aren’t on there as frankly they haven’t innovated for a long time and in my opinion haven’t really impressed the market with some of their OnTap products (ie Clustered OnTap), but really surprised at seeing HP at No. 6 given how they let their EVAs and StorageWork portfolio decline over the years (although I believe they’re trying to rescue the division with the acquisition of 3Par). Again, I would have thought IBM would be on there considering their new Storwize V7000 arrays have been receiving decent praise (then again we don’t go up against IBM much as if a client is pretty much a ‘Big Blue’ house, they tend to be pretty closed off to other vendors!).

No surprise to see Joe Tucci – CEO of EMC – as No. 1….. no other CEO has overseen the recovery of such a big giant and gone on to make such clever acquisitions (DataDomain, Avamar, VMware, Isilon, XtremIO, Greenplum). I wonder what the future holds for EMC… they’re already No 1 in so many different product areas (data dedupe, storage, virtualisation, etc)… You have to wonder who’s next on their acquisition trail!

Another name missing from this list is probably Samsung…… Aren’t they the leading manufacturer of flash memory and SDRAM? Pretty sure I read that they are looking at entering the PCIe Flash-storage cards soon!

 

Anyways, interesting times ahead in the storage arena……. I guess the next big move would be to link server-based PCIe flash storage with back-end flash-based storage arrays!

Using PowerCLi to run a ESXCli command to find storage info

So recently I had to use VMware Health Analyzer in order to run a health check on a clients’ virtual environment alongside a colleague who was running Navisphere Analyzer against the clients’ EMC storage array.

We notice a slight problem where we couldn’t match up the LUN IDs from the storage (ie Channel:Target:Lun – which VMware refers to as Runtime name) and the UUIDs that are used in VMware (ie naa.xxxxxxx).

The Health Analyzer outputs only datastore/LUN information referencing the appropriate UUID. The EMC nar file generated outputs only LUN information referencing the appropriate LUN ID (well that’s what my colleague says – if anyone knows how to generate data using the VMware UUID then please let me know!).

So we pretty much had no reference to match up VMware Health Analyzer LUN data to the EMC Navisphere Analyzer LUN data…….

So a quick google sent me looking here:

http://www.geekmungus.co.uk/vmware/matchvmwarelunidtoemcsanlunid

But that would only be useful if you are able to sit on site and look at the vSphere Client/Navisphere GUI, plus it would be quite a tedious process to go through all the LUNs.

Sooooo…. after a lot of trial and error, and googling PowerCLI commands, I ended up writing the following script (with a little help from Luke’s scripts at http://thephuck.com/):

param([string[]]$vmhosts = $null)
#By default, PowerShells execution policy is set to Restricted; that means that scripts will not run.
#RemoteSigned allows PowerShell to run any scripts you write, but only run scripts from the Internet if they have been signed by a trusted publisher.
Set-ExecutionPolicy RemoteSigned
Add-PSSnapin VMware.VimAutomation.Core -ErrorAction SilentlyContinue #required if running from normal Windows PowerShell and not VMware Powershell

function usage()
{
Write-host "This script is used to pull Storage information for all hosts provided."
Write-host "You can specify -vmhosts as an array:"
write-host "Get-LUN.ps1 -vmhosts (`"host1`",`"host2`",`"host3`")"
}

if ($vmhosts -eq $null)
#Checks to see if vmhosts parameter has been supplied when script is run
{
usage
break
}

if ($vmhosts -ne $null)
{
#Credentials required for ESX hosts - assuming credentials will be same for all ESX hosts
$vmhost_creds = $host.ui.PromptForCredential("ESX/ESXi Credentials Required", "Please enter credentials to log into the ESX/ESXi host.", "", "")
foreach ($vmhost in $vmhosts)
{
connect-viserver $vmhost -credential $vmhost_creds > $NULL 2>&1
$esxcli = Get-EsxCli -VMHost $vmhost
#Outputs the data into a text file located in C:\ and will name the file using the host name
$esxcli.storage.core.path.list() | Out-File c:\$vmhost.txt
disconnect-viserver -confirm:$false
}
}

#garbage collection
$vmhost_creds = $null
$vmhosts = $null
$esxcli = $null

 

So basically cut and paste the code into notepad and save it as Get_LUN.ps1 and run from a PowerShell console…….

The output will list all Adapters, UUIDs, Runtime Names, Identifiers, etc for the host.

 

If you want to limit the data obtained, then you could always pipe the data through a select filter before piping it to the output file….. so a bit like: $esxcli.storage.core.path.list() | Select Adapter,Device,RuntimeName,Transport | Out-File c:\$vmhost.txt