For those of you that didn’t get to attend the conference(s), didn’t get to take any Hands-On-Labs at either show, or have been living under a rock, the big news of the show this year was that Diamond partners/sponsors (Cisco, EMC, & NetApp) were given the opportunity to create their own lab for users to take, alongside the other 24 that VMware themselves created.

This was HUGE and we jumped right on board!

(In case you missed it in my last post, there is an in-depth interview with the man, the myth, the legend, Irish Spring, telling the story of the evolution of the HOL, and how they got to where they are today, and where they are going in the future!)

Hat’s off to my two main cohorts throughout this process.  If you took any of the Hands On Labs, you likely met one of them if you were escorted to your seat by a NetApp shirt.  For those of you that I met in Copenhagen while proctoring, it was a pleasure!

Julian Cates (aka @vSkeptic) is a fellow Solutions Architect teammate.  While I threw in some input in the design process, he was almost single-handedly responsible for making the Lab a living, breathing entity inside of VMware’s HOL vCloud Director environment, and deserves some serious recognition!  If you took the lab, send him a tweet and tell him about your experience!

For my part, I was mostly responsible for the development of the lab guide initially.  But once I was done with my handywork in the initial technical drafts, it was handed over to Jim Weingarten for spit & polish.  And boy did he deliver!

Several others deserve honorable mentions for their participation and contributions:

Scott Baker (aka @lilbaker83), Peter Learmonth, Brian Schofer, Lisa Crewe (aka @ljcrewe), and Rob Strechay.

Hat’s off to all of you!

I got a chance to take the lab in Copenhagen, and thought it was a wonderful experience.  Even though I was intimately involved in the creation process, it was still amazing to see it come to life inside the lab screens!

NOW!  All the pleasantries out of the way, let’s get to a little bragging…

NetApp was the #1 partner lab at both Vegas AND Copenhagen shows!

 

To break it down a bit further, I wanted to share some more detailed stats with you…

 

Vegas

The VMworld US show had some interesting twists and kinks and turns, but turned out great…well, not so much for Cisco.  Unfortunately, something went screwy with the cloud provisioning of their lab, and it was pulled on Sunday before the show.  It reappeared on Monday, but was still not working properly.  It was pulled again on Tuesday, and was finally fixed and re-enabled on Wednesday where students could take it.  I feel terrible that they did not have the same experience we did, and please understand that their numbers are skewed accordingly.  Better luck next year, guys!

Of the 27 labs available, NetApp’s lab finished 12th in a ranking of number of times selected/taken. The EMC and Cisco labs were ranked 16 and 17, respectively.  The NetApp lab was chosen 496 times; 159 more times than EMC and 257 more times than Cisco.

But perhaps the stat we would like to highlight most (and that we are MOST proud of) was the satisfaction survey results!  NetApp tied for FIRST PLACE among attendees with an Average score of 4.55 out of 5!  Thanks to all of you that attended, participated, and filled out the survey!  This is the kind of feedback that empowers us!

Another issue I’d like to highlight is a shortsighted error in provisioning of one of the many vCenter servers running the HOL, and how one small thing such as this can bring an environment to a crawl. Remember that Akorri acquisition from earlier this year for their BalancePoint product?   It kinda saved the day! <–No seriously, go read this!  Super deep-dive into tech details of vCenter!

 

As a little bit of an aside, there was also a little bit (OK, a lot…) of FUD-slinging happening during the show.  Aside from the typical stuff we’ve become accustomed (and somewhat immune/numb) to, Chris Mellor from The Register posted an article highlighting Nexenta, and essentially saying us big arrays weren’t necessary anymore.  Chris, I will respectfully disagree vehemently.

Allow me to clear the air a bit…

Chris originally received an (we know who it was) “anonymous tip” that one of our FAS3270 systems failed (not truein the Hands On Labs during the first day of VMworld Vegas, and that it was out for most of the day (not true). The alleged reason was that it needed to be upgraded with more FlashCache to match the performance needs of the lab environment.  Meanwhile, he states that he was informed that two EMC VNX and four Nexenta storage arrays essentially carried the entire burden of the HOL until the failing FAS3270 was upgraded and switched back on.  And also asked what the list price of the investments.  Basically, somehow, through feats of journalism, Chris got wind of a late-night FlashCache install that we performed, and assumed/implied that this was somehow “required” to improve the performance, and that our storage couldn’t keep up because of it.  He also mentioned that these were running (144) 15k FC drives.

What really happened?

First, for accuracy, they were FAS3240’s, not 3270’s.  The core difference is the speed of processors and on-board system memory.

Second, one of the controllers had a mixup in the shipping BoM and the single FlashCache card that was ordered did not arrive with the initial shipment of gear.  So, the late-night install I referred to above was after we received the card, we needed to get it installed.  All other systems were shipped properly with FlashCache installed.

Third, there was no mention of the fact that there were three datacenters, Las Vegas, Miami, and Amsterdam.  There were TWO FAS3240 HA pairs at each of these sites, but almost ALL of the load ran from the first pair in Vegas.  An additional note, all systems were running SAS shelves/drives, not the legacy DS-14/FC ones.

OH! Know what else we didn’t have?  SSD.  Didn’t need them.

Ultimately, none of this story detail got published.  We countered his facts and asks with sources on-site that could corroborate the facts, but no response was ever provided, and nothing was published.

At the end of the day, the story that was posted was an attempt to try and show that server-hosted storage can compete with large enterprise storage arrays, and that’s simply not true, and was a sad attempt at stirring up trouble among the industry, ultimately doing more harm than good, and getting more information wrong than right.  Obviously, Chris is a journalist, has an agenda, and is trying to rake up muck on both NetApp and EMC (even if only to pit us against one another for some good tweet-fights), but at the end of the day, all you do Chris, is subvert the value received from the major storage vendors.

 

Copenhagen

At the VMworld Europe show in Copenhagen, of the 27 labs available, NetApp’s lab finished in the top ten, achieving a ranking of number 9; up three points from the 12th position we achieved in Las Vegas. The EMC and Cisco labs were ranked 13 and 17, respectively.  The NetApp lab was chosen 187 times; 48 more times than EMC and 81 more times than Cisco.

Copenhagen was a much smaller show, as most of you know, seeing attendance numbers of ~7,000 as opposed to the ~20,000 in Las Vegas.  The lab numbers are in-line with that as well.  Overall, Copenhagen went off without much of a hitch.  The pace seemed much more manageable, and I cannot recall any users running into any real problems.

To wrap up this post, I wanted to tell you that this isn’t the last post you’ll see.  We had all of the call-home features enabled on the storage arrays, which gave us some extreme detail on data served, housed, dedupe savings, etc.  I’ll be sharing that with you in a followup post very soon (likely next week!), as well as some more extreme detail about how all of the virtual EMC VNX machines in each of the labs were misaligned.

Stay tuned, and as always, thanks for reading, and any questions, post in the comments!

-Nick

Leave a Reply

Discover more from DatacenterDude

Subscribe now to keep reading and get access to the full archive.

Continue reading