Posts Tagged ‘Strategic Direction’

My Friend Needs a Product From VCE

Disclosure: I work for VCE so make of it what you will.

I had lunch this weekend with a friend of mine that manages the server infrastructure for a local government entity.  During the usual banter regarding business, he mentioned that a recent storage project (1+yr and still going) had suffered a series of setbacks due to outages, product compatibility issues, and other minor odds & ends.

The entity he worked at released an RFP that detailed quite a bit of what they were looking to accomplish, which in retrospect may have to been too ambitious given the budget available.  After going through all the proposals, the list was narrowed down to two.  On paper, both were excellent.  All vendors were either Tier1 or Tier2 (defined by sales).  Both proposals were heavily vetted with on-site visits to existing customers, reference phone calls, etc.  Both proposals consisted of a storage back-end with copious amounts of software for replication, snapshotting, provisioning, heterogeneous storage virtualization, and more.

While each component vendor of the winning proposal was highly respected, the two together did not have a large installed base that mimicked the proposed configuration (combo of hardware & software).  In hindsight, this should have been a big RED flag.  What looked good on paper did not pan out in reality.

Procurement went smoothly and the equipment arrived on time.   Installation went smoothly.  It was during integration with the existing environment that things started to break down.   The heterogeneous virtualization layer wasn’t quite as transparent as listed on paper.  Turns out all the servers needed to have the storage unpresented and presented back.  (Hmmm…first outage, albeit not a crash.)

Then servers starting having BSODs.  A review by the vendors determined that new HBAs were needed.  This was quite the surprise to my friend since the he provided all the tech info on the server & storage environment as part of the proposal and was told that all existing equipment was compatible with the proposal.  (2nd, 3rd, 4th+ outages…crashes this time).

So HBAs were updated, drivers installed, and hopefully goodness would ensue. (planned outages galore).

Unfortunately, goodness would not last.  Performance issues, random outages, and more.  This is where it started to get nasty and the finger pointing began.  My friend runs servers from Cisco (UCS) and HP.  The storage software vendor started pointing at the server vendors.  Then problems were attributed to both VMware and Microsoft. (more unplanned outages).

Then the two component vendors started pointing fingers at each other.  Talk about partnership breakdown.

So what is my friend’s shop doing?  They are buying some EMC and NetApp storage for their Tier 1 apps.  Tier 2 and Tier 3 apps will remain on the problematic storage.  They are also scaling back their ambitious goals since they can’t afford all the bells & whistles from either vendor.  The reason they didn’t purchase EMC or NetApp in the first place was due to fiscal constraints.  Those constraints still exist.

As I listened to the details, I realized that he really needed one of the Vblock ™ Infrastructure Platforms from VCE.

First, his shop already has the constituent products that make up the majority of a Vblock – Cisco UCS, EMC Storage (small amount), and vSphere. This makes transitioning to a Vblock ™ easier since less training is needed and a comfort level already exists for those products.

Second, the hardware and software components in the winning proposal were not widely deployed in the proposed configuration.  At the time my friend’s shop put out the RFP, there were more Vblocks in production use in the United States than there were of the winning proposal’s configuration world-wide.

Third, at VCE, all the hardware/software components in a Vblock ™ are thoroughly tested together.  It’s VCE’s job to find any problems so a customer doesn’t.  People think that if you take three items listed on an HCL somewhere and put them together, then everything will work fine.  It just isn’t true.   In fact, a number of patches put out by the parent companies are the result of testing by VCE’s engineering and quality assurance teams.

And finally, probably the biggest reason why my friend needs a product from VCE is to get rid of all the finger pointing.  When VCE sells a product, every component is supported by VCE.  There is no saying “It’s not our problem, call the server vendor”, or “call the storage vendor”, or “call the software vendor”.  I’m not saying that all vendors finger point. Also, your mileage with a set of particular vendors will vary, but if you are CIO/Manager/whatever, you have to admit that “one call, that’s all” is quite compelling.  You can either have your staff spend time managing vendors or you can have your staff spend time moving your business forward.

I’ve put the bug in the ear of my friend about going Vblock in the future.  It won’t happen any time soon since his procurement cycle isn’t conducive to purchasing all his infrastructure components in one fiscal year.  It usually takes five years to get through all three major components.  But who knows?  Maybe his recent experiences will accelerate the cycle.



What about Tintri?

August 2, 2011 3 comments

I attended the Phoenix VMUG meeting this week.  The two main sessions were about vSphere5 and Tintri’s VMstore.  While vSphere5 is interesting, I have been working with it for over 5 months now so it wasn’t a “must see” presentation for me.  I was actually at the event to see Tintri and I have to say that the Tintri VMstore product intrigues me quite a bit.  For those who haven’t heard of this product, think of it as a purpose built storage appliance for your VMware environment.   This “appliance” is roughly 8.5TB (usable) and is only accessed via NFS.  The entire device presents itself as one large datastore to your hosts.  If you think about it, this really does simplify things quite a bit.  There is no zoning, no LUN creation, no disk grouping, etc.  Basically, all of your standard storage creation tasks have been removed.  Time to add capacity? Just add another appliance and add it to your vCenter as another datastore.  It’s that simple.

Management of the appliance is performed through a web interface and via a vCenter Plug-in.  The bulk of what you expect in a management tool is there with a few notable exceptions (discussed later in this post).

One of the VMstore design goals is performance.  To that end, Tintri has equipped the VMstore with 1TB of SSD storage.  Through their own internally developed magic, the bulk of “hot” data is kept in SSD.  The rest is stored on SATA disks.  You can imagine the kind of IOPS possible given the heavy use of SSD.  BTW, the SSD is deduped so you get more bang for your buck.

The folks at Tintri gave the standard “who we are” and “why we are different” presentation that we all expect at open events like this.  After talking about the product and walking us through the mgmt. interface the Tintri folks took questions from the audience.  All-in-all, a good showing.

There were no hard questions asked at the VMUG, but the after meeting was completely different.  I am also a member of Advanced Technology Networking Group (ATNG) and we met up with the Tintri folks a few hours later.  ATNG consist of hardcore techies and since many of our members are responsible for acquisitions and managing data centers, our meeting with vendors tend to be “No holds barred”, but in a friendly way.  Our goal is to get to know the product (warts and all) as much as we can during our meetings.

We questioned a lot of design choices and where the product is going.  One are of particular interest to me was the use of SATA drives.  Yes, the appliance uses RAID6 and has hot spares, but that did not alleviate my concern.  Drive quality continues to improve so only time will tell if this was a good design choice or not.

Another area questioned was the use of a single controller.  The general rule of enterprise storage is to have two controllers.  VMstore currently has one.  Notice that I say “currently”.  Future product will have two controllers.

There were a few questions and suggestions regarding the management interface.  One suggestion was to rename the VMStore snapshot function.  It is not the same snapshot feature as in vCenter.  vCenter has no visibility into VMstore native snapshots and vice-versa.  This can be a source of confusion if you consider that the target audience for this product is VM admin.

The lack of some enterprise features also came up in our discussions.  Notably, the lack of SNMP support and the lack of replication support.  The only way to get notified of something going wrong with the appliance is to either receive an email alert or see something in vCenter.    As for replication, the only option available is to perform a standard vm backup and restore the data to another appliance or storage device of your choice.

However, all is not doom and gloom.  Tintri is working on updates and improvements.  SNMP support, replication capabilities, and more are coming soon.   Keep in mind that Tintri recently came out of stealth mode and is on 1.0 of their product.   For a 1.0 product, it’s pretty good.  Just to give an idea of the performance and quality of VMstore, Tintri has a reference customer that will attest that they have been running a beta version since November 2010 without any issues.  In fact, that customer is still on the beta code and has not upgraded.  That’s a pretty good reference if you ask me.

So what do I think of VMStore?  I think Tintri is on the right track.  Purpose built storage for VMware is a great concept.  It shows a laser like focus on a particular market and it lets the company focus on capabilities and features that are specific to that market.  Generic storage has to cater to many masters and sometimes gets lost in the process.

I am going to predict that Tintri will either be copied by other storage vendors or that they will be acquired by one of them.  The product/concept is just too unique and spot-on that it can’t be ignored.

Links of interest:

Why VCE?

February 9, 2011 1 comment

I was recently asked why I went to VCE.  Not why I left the City, but why I went to VCE, specifically.  After all, there are plenty of other companies out there looking for infrastructure types like me.  It’s a good question and here is my answer.

Before I can say “why VCE”, I need to provide some insight into my personality.  I have many traits associated with the stereotypical “computer guy”.  For starters, I am not the most socially adept.  Very few people would say that they would be friends with me based on first impressions.  I’m more like a fungus in that I grow on you.  It’s not that I have a bad personality, it’s just that it takes a while for people to “see me” (ala Avatar).

The second reason I’m that “computer guy” is that I like order.  While I don’t claim to be a neat freak, I do believe that most things in my house have a place, and when not in use, they should be in that place.  Even dust has a place in my house; on top of everything. 🙂   First comes Step A then comes Step B.  Order brings peace and harmony.

I also like the illusion of having control.  At the City, I was responsible for determining work assignments for my team, determining our server technology roadmap, and more.  While I truly didn’t have control, there was enough semblance of it to provide me a sense of serenity.

While on the topic of serenity, one word NOT used to describe me is excitable.  My wife will attest to the fact that I don’t get excited.  Now get your mind out of the gutter.  I am referring to high-energy when I say excitable.  I am pretty much on an even keel all the time.  I have my moments of emotion, but they are short lived.  You will see me smiling and laughing during conversation, but don’t expect me to yell at a bad call during a football game or scream out at a concert.

Do the words order, peace, harmony, and serenity describe VCE?  No, it is the exact opposite.  When my manager was recruiting me, I don’t think he realized his description of the position and company scared me.  He aptly described VCE as a startup.  And common to most startups is confusion, high-energy, and a bit of chaos.  Pretty much the exact opposite of my personality.

So why VCE?

If you read my last post, you’ll remember that I felt like I was becoming a “Day Tech”, something intolerable to me.  Due to the City’s high tolerance level for mediocrity, it became difficult to avoid becoming complacent at doing work that was “good enough”.  I don’t think that the City realizes that it doesn’t have high expectations of its employees.  Too many people get by on work that I would call subpar.

In my previous post, I also said that three areas of interest were virtualization, Cisco UCS, and storage.  When I was approached about joining VCE, I realized that I would be involved with those three technologies and I would also be thrust into an environment that was completely outside my norm.

So “Why VCE?”  After all I have said above, I am expecting VCE to “recharge my battery”.  By being in an environment that is constantly changing due to growth, has high expectations of its employees, and plays in the areas of my three interests, I figure I’ll find my motivation and passion again.  Either that or have a nervous breakdown  🙂

So “Why VCE?”  VCE also appealed to me to as an agent of change, a provider of the future, a blah blah blah (you get the idea).  Think about what VCE does.  It doesn’t just provide a hardware/software package.  VCE provides the next generation of computing, aka the cloud.  Even at the City, we talked a lot about the cloud and the future it holds.  I figured that if I was going to join a startup, I wanted it to be in an area where I thought the chances of success would be extremely high.  And of all the cloud computing companies out there, only one has the best servers, the best storage, and the best software.  That’s VCE.



Guest Post on “Define the Cloud”

December 8, 2010 Leave a comment

I haven’t posted anything in a while, but not because I have been lazy…well, maybe a little bit, but the main reason is that I have been working on a guest post over at   It’s a good site with a lot of great technical info.  A direct link to my post can be had here. Enjoy the read.


Categories: cisco Tags: ,

Does the Storage Tecchnology Really Matter?

November 15, 2010 4 comments

This article is really more of a rant.  Take it for what it is.  I’m just a frustrated infrastructure admin trying to choose a storage product.

I am not a storage admin (and I don’t play one on TV), but I am on our storage replacement project representing the server infrastructure area.  In preparation for this project, I started reading a number of the more popular blogs and following some of the storage Tweeters.  One thing I noticed is that all the banter seems to be about speeds and feeds as opposed to solving business problems.  In the case of Twitter, I am guessing it’s due to the 140 character limit, but I would expect to see more in the blogs.  Some of the back & forth reminds me of the old elementary school bravado along the lines of “My dad can beat up your dad”.

I must admit that I am learning a lot, but does it really matter if it supports iSCSI, FC, FCoE, NFS, or other acronyms?  As long as it fits into my existing infrastructure with minimal disruption and provides me options for growth (capacity and features), should I care?   If so, why should I care? We recently moved the bulk of our data center to Cisco UCS so you would think that FCoE would be a highly valued feature of our new solution.  But it’s not.  We don’t run Cisco networking gear and our current gear provider has no short term plans for FCoE.  Given that we just finished a network upgrade project, I don’t forsee FCoE in our environment for at least three years unless funding magically appears.  It doesn’t mean that it isn’t on our radar; it just means that it won’t be here for at least three years.  So stop trying to sell me on FCoE support.

So who has the better solution?  I am going to use EMC and NetApp in my example just because they blog/tweet a lot.

I think if one were to put a chart together, both EMC and NetApp could be at the heading of any column.  Their products look the same to me.  Both have replication software, both support snapshots, both support multiple protocols, and so on and so on and so on.  The features list is pages long and each vendor seems to match the other.

There are technical differences in how these features are implemented and in how the back-end arrays work, but should I care?  Tell me how these features will help my business grow.  Tell me how these features will protect my business.  Tell me how these features will save my business money. Tell me how they can integrate into my existing infrastructure without having to change my infrastructure.  And when I say “tell me”, don’t just say “it can do this”, or “it can do that”.  Give me case studies more than six pages long, give me processes and procedures, and give me REAL metrics that I can replicate/validate (assuming I had the equipment and time) in a real-world scenario which information telling me how they affect my apps and customers.

This is an area where companies need to do a better job of marketing.  EMC started down this path with the vBlock.  Techies aren’t really interested because the specs are blasé.  C-level folks love it because it marketed towards them and the marketing focuses on the solution from a business perspective.   NetApp is starting to do the same with their recently announced FlexPod.  The main downside to these new initiatives is that they seem to forget about the SMB.  I think it’s great from a techie POV that a FlexPod can handle 50,000 VDI sessions.  But as an IT Architect for my organization, so what?  We only have 4200 employees or so.

Right now, I’m sort of in-between in what type of information I need: technical vs business.  I am technical at heart, but have been looking at things from a business perspective the last few yrs.  I am in the process of trying to map what our mgmt team wants to accomplish over the next few years to the storage feature sets out there in the market.  This is where both types come together.  Now if I can just get past the FUD.

VMworld voting has begun

The folks who run the VMworld tradeshow have taken a new path to deciding session content this year.  Instead of a panel making all the choices, the powers-that-be have decided to open it up to the public to vote on those topics that interest them.  I’ve submitted a proposal to speak about our soon-to-be UCS implementation and how it is going to transform our business.  If interested, please go here: and vote for my session.  My session is entitled:

Session ID: TA7081, Session Title: Case Study: vSphere on Cisco UCS – How the City of Mesa changed strategic direction


Battle of the Blades – Part III

April 27, 2010 Leave a comment

So earlier on I posted that I would list our strategic initiatives and how they led us down the path of choosing Cisco UCS as our new server platform as opposed to HP or IBM blades.  Before I begin, let me state that all three vendors have good, reliable equipment and that all three will meet our needs to some degree.  Another item of note is that some of our strategies/strategic direction may really be tactical in nature.  We just sort of lumped both together as one item in our decision matrix (really a fancy spreadsheet).  The last item to note is that all facts and figures (numbers) are based on our proposed configurations (vendor provided) so don’t get hung up on all the specifics.  With that out of the way, let’s begin…

If we go way back, our initial plan was just to purchase more HP rack-mount servers.  I have to say that DL380 server is amazing.  Rock solid.  But given our change in strategic direction, which was to move from rack-mounts to blades, we were given the option of going “pie-in-the-sky” and develop a wish list.  It’s this wish list, plus some specific initiatives,  that started us down the path at looking at Cisco UCS (hereafter referred to as UCS).

Item one:  Cabling.  Now all blade systems have the potential to reduce the number of cables needed when compared to rack-mount systems.  Overall, UCS requires the least amount of cables outside of the equipment rack due to the fact that the only cables to leave the rack are the uplinks from the fabric interconnect.  With HP and IBM, each chassis is cabled back to your switch of choice.  That’s roughly 16 cables per chassis leaving the rack.  With UCS, we have a TOTAL of 16 cables leaving the rack.  Now you might say that a difference of 32 cables per rack (assume 3 HP or IBM chassis in a rack) might not be much, but for us it is.  Cable management is a nightmare for us.  Not because we are bad at it, we just don’t like doing it so less cabling is a plus for us.  We could mitigate the cable issue by adding top of rack switches (which what a fabric interconnect sort of is), but we would need a lot more of them and they would add more management points, which leads us to item two.

Item two:  Number of management points.  Unless you have some really stringent, bizarre, outlandish requirements the chances are that you will spend your time managing the UCS system at the fabric interconnect level.  I know we will.  If we went with HP or IBM, we would have to manage down to the chassis level and then some.  Not only is each chassis managed separately, think of all the networking/storage gear that installed into each chassis.  Each of those is a separate item to manage.  Great, let’s just add in X more network switches and X more SAN switches that need to be managed, updated, secured, audited, etc.  Not the best way to make friends with other operational teams.

Item 3:  Complexity.  This was a major item for us.  Our goal is to simplify where possible. We had a lot of back&forth getting a VALID configuration for HP and IBM blade systems.  This was primarily the fault of the very large VAR representing both HP and IBM.  We would receive a config, question it, get a white-paper from VAR in rebuttal, point VAR to same white-paper showing that we were correct, and then finally get a corrected config.  If the “experts” were having trouble configuring the systems, what could we look forward to as “non-experts”?

Talking specifically about HP,  let’s add in HP SIM as the management tool.  As our HP rep is fond of stating, he has thousands of references that use SIM.  Of course he does, it’s free!   We use it too because we can’t afford Openview or Tivoli.  And for basic monitoring functions, it works fine albeit with a few quirks.  Add in Blade System Matrix on top of it, and you have a fairly complex management tool set.  We spent a few hours in a demo of the Matrix in which the demoer, who does this every day, had trouble showing certain basic tasks.  The demoer had to do the old tech standby: click around until you find what you are looking for.

Item 4: Multi-tenancy.  We plan on becoming a service provider, of sorts.  If you read my brief bio, you would remember that I work for a municipal government.  We want to enter into various relationships with other municipalities and school districts in which we will host their hardware, apps, DR, etc and vice-versa.   So we need a system that easily handles multiple organizations in the management tool set.   Since we are an HP shop, we gave a very strong looksy to how HP SIM would handle this.  It’s not pretty.  Add in the Matrix software and it’s even uglier.  Now don’t get me wrong.  HP’s product offerings can do what they claim, but it not drag-and-drop to setup for multi-tenancy.

Item 5: Converged Architecture. When we made our initial decision to go with UCS, it was the only converged architecture in town.  I know we are not going to be totally converged end-to-end for a few years, but UCS gets us moving in the right direction starting with item 1: cabling.    All the other vendors seemed to think it was the wrong way to go and once they saw the interest out there, they decided to change direction and move toward convergence too.

Item 6: Abstraction:  You could also call this identity, configuration, or in UCS parlance, service profiles.  We really like the idea of a blade just being a compute node and all the properties that give it an identity (MAC, WWN, etc) are abstracted and portable.  It’s virtualization to the next level.   Yes, HP and IBM have this capability to but it’s more elegant with UCS.  It’s this abstraction that will open up a number of possibilities in the high-availability and DR realms for us further down the road.  We have plans….

So there you have it.  Nothing earth shattering as for as tactics and strategy go.  UCS happened to come out ahead because Cisco got to start with a clean slate when developing the product.  They also didn’t design it for today, but for tomorrow.

Questions, comments?