A year ago when I joined Cisco’s Unified Computing team, HP had just released a web page full of fear, uncertainty and doubt about the just-launched UCS.

Quick note: I’m currently (should be) on holiday!  I drive down to Nurburgring tomorrow so I don’t have time to take the HP FUD apart piece by piece – this is a flavour, it’s all I have time for

In the mean time, Steve Kaplan wrote a well reasoned, objective and data-laden piece about comparing Cisco UCS to the mythical HP Matrix.

This has obviously sent a chilly wind down the comfy corridors at HP HQ because one year on they are playing the FUD game again with another web page full of fear, uncertainty and doubt about the one-year-old UCS.  There are some classic references in this:

• Referencing the HP funded Tolly Reports as if they are independent (bad science!)
• Referencing a BMC earnings call as a source of UCS customer experience! (more bad science!)

I can see that this latest marketing output is a typical mish-mash of half truths (yes, HP do sell more servers than Cisco!) and falsehoods (sorry, HP, but you really do need less components with UCS when you are honest) – but I have to thank HP for a fantastic opportunity: here’s what they’ve done for Cisco (cheers!):

• Free advertising to all HP customers that there is such a beast as UCS and it must be scary for HP to go on the attack (defense).
• This will get customers phoning Cisco up to ask if these claims are true (it’s nice when customers phone us up, thanks HP!).
• Cisco folks can take this document apart, piece by piece, with the customer and show the weakness in HP’s approach, the strengths of Cisco as a data center virtualization partner (yes, partner, not just providor).

So it seems that HP can’t fight Cisco fairly in the market with better product vision and delivery so they resort to handbags and name-calling, and their last line of defence is this kind of attack.  What do you think about it?

No related posts.

I see dead people

Chris Dancy, aka @ServiceSphere, kindly invited me to his weekly podcast so I could explain my anti-ITIL rants on this blog.

Empire Building, Love Children, Soylent Green, and Thoughtless Leadership

If you haven’t heard Chris talk, then you are missing out!  He’s the Vegas version of VMware’s John Troyer.  Fun times!

I make same bold statements about how ITIL is out of touch and how many companies are looking to remove people and process and replace them with tools.  More of my ITIL rants:

• ViewYonder » The ITIL believers are massing, Pink with embarrassment?
• ViewYonder » Is the ITIL make-over like putting lipstick on a pig?
• ViewYonder » ITIL Certification is an oxymoron
• ViewYonder » Is ITIL ‘Gerin Oil’ for IT?
• ViewYonder » ITIL is about Technology Adoption

Don’t shoot the messenger: I see dead people!

Related posts:

1. Making ITIL real: Change Management for Technology Adoption
2. ITIL is about Technology Adoption
3. The ITIL believers are massing, Pink with embarrassment?
4. Does your Desktop Service Strategy look a bit like this?
5. ITIL v3 Service Operations sullied by HP marketing?

Choice, Balance, Tradeoffs

I recently posted about how you can scale one UCS system to 122 blades, which means if you’re using it for virtual servers you could put over 5,000 on that one system and not buy any more networking hardware for a year.

There are four approaches to UCS scalability and I’ll explain each one and then moan a bit about how people are taking a Noah’s Ark approach to design, often seen applied (incorrectly) in the name of Availability (creating redundant redundancy!).

As you scale UCS you add more chassis and more blades to the Fabric Interconnects.  You don’t need to add any more network, storage or management infrastructure: JUST BLADES.

The Fabric Interconnects at the top of rack devices are the brains that do switching and so much more.  You connect cables from these Fabric Interconnects to ports on Fabric Extenders (FEX) that sit in each chassis.  Think of a FEX as a logical extension of the Fabric Interconnect: a FEX is not a switch, it doesn’t need individual management, it’s an extension of the fabric.

Everytime you add a chassis, then, you are filling up ports on the Fabric Interconnects and you have a finite amount of these – either 20 (if you have a 6120) or 40 (if you have a 6140).  There are also current limits (tested supportability limits that Cisco will guarantee for you) of 14 chassis per UCS (this gets bigger with each release).  These are the two scalability constraints: ports and supported chassis, leading to four scenarios:

1. Maximum scalability/oversubscription with a 6120 and 1 uplink per FEX gives 14 chassis / 122 blades and 20Gbp/s aggregate bandwidth per chassis / 8 blades.
2. Medium scalability/oversubscription with a 6140 and 2 uplinks per FEX gives 14 chassis / 122 blades and 40Gbp/s aggregate bandwidth per chassis / 8 blades.
3. Minimum scalability/oversubscription with a 6140 and 4 uplinks per FEX gives 10 chassis / 80 blades and 80Gbp/s aggregate bandwidth per chassis / 8 blades.
4. Mixed scalability/oversubscription with a 6120 or 6140 with each chassis having a choice of 1, 2 or 4 uplinks from the FEX (e.g. chassis 1 has 1 uplink, chassis 2 has 2 uplinks).

Or in a picture:

Important note: at all times there are redundant uplinks from each chassis.  So when I say “1 FEX uplink” I mean _PER FABRIC_ and there are two fabrics, A and B.  Each chassis has two FEXs (one per fabric) that connects to their “own” 6120/6140 fabric interconnect.

A common problem with architecture is that people “double count for redundancy” or create “redundant redundancy” by deploying redundant components (e.g. RAID arrays) in already redundant containers (e.g. Web server that is one in a redundant farm).

The same thing tends to happen in UCS because people think that “two FEX uplinks is more redundant than one” which isn’t true at all.   Redundancy comes from two FEX devices per chassis, not two links per FEX.  More FEX ports means lower oversubscription (at a cost).  That’s all it does.  Think:

• Redundancy goes left-to-right (across FEXs), and;
• Oversubscription goes top-to-bottom (across FEX ports).

So, now we’re all over the confusion between redundancy and oversubscription, what’s the cost/benefit of these four scenarios as seen in the above diagram?

• Maximum scalability (122 blades) has a lower TCO because you are sharing one UCS between 14 chassis which means you shouldn’t have to buy another UCS until you’ve deployed over five thousand VMs.  It also means less cable costs (SFP+ from FEX to Fabric Interconnects).  You will need to buy and extra 12 ports licenses for the fabric interconnect (8 are bundled with 6120).
• Medium scalability (which should only be deployed if you need the aggregate bandwidth of 40Gbp/s per chassis!) means you can get 10 chassis out of one 6120, but you’ll need a 6140 to run 14 chassis because that’s 14 x 2 = 28 ports.
• Low scalability means you can only get 5 chassis out of a 6120, and only 10 with a 6140.  This uses all ports, using the maximum amount of cables, and you need extra port licenses to use all the ports on the fabric interconnects.  Most expensive option.
• Mixed scalability means you can deploy chassis with different oversubscription and this drives a different TCO.  If you had three chassis with Mixed Scalability, then Chassis 1 might be Maximum Oversubscribed (with 1 FEX link per fabric), Chassis 2 might be Medium (2 FEX links) and Chassis 3 might be Lowest (with 4 FEX links).

Money is finite and so are network ports.  Your job as a systems designer/architect is to make sure the system has adequate redundancy and oversubscription and in most cases that will only require one uplink per chassis per fabric.  The fabrics give you redundancy, and the FEX ports give you bandwidth.

Many people are deploying two FEX ports because they don’t know or can’t predict the profile of their unified traffic (ethernet and FC-over-Ethernet) and the middle ground feels safer (no science).

You can always change your mind later anyway, so you can ramp up (say from 1 uplink to 2 or 4) or ramp down (say from 2 uplinks to 1) should your data show that your workload has a bigger/smaller profile.

And perhaps that is the best point of all of this:  by all means work out the tradeoff between scalability and oversubscription but remember, most importantly of all, it’s really simple to change it later (add/remove cables and re-acknowledge the chassis – DONE!).

Related posts:

1. Cisco 6100XP aint Switches like VMware ESX aint Linux
2. With UCS you buy one set of switches every 112 blades
3. How real life became my worst nightmare
4. Over-commiting your infrastructure for multi-tenant DR with Cisco UCS

Before I finish work this week and get ready for the England World Cup game (yes, I’m playing in goal), I wanted to share an observation a customer made to me this week:

“So what you’re saying, Steve, is if I go with UCS then I only have one management point and one set of top of rack switches for 112 blades?”

Yes!  That’s right!  You can run 14 chassis, each capable of holding 8 blades each, that’s 112.  Run 50 virtual wotsits (desktop, server, anything you like) per blade and that’s 5,600 virtual machines you can deploy without ever raising another purchase order for more “switches” or having to configure more “switches”.

The reason you can do this is because each chassis has logically invisible fabric extender that, as the name suggests, extends the (top of rack) fabric interconnects.  These aren’t switches; they are extensions of the fabric interconnect.  That means no management.  Simple extension.  Cloudy.

Think about it: 112 blades.  5,600 virtual machines.  If you could deploy 100 virtual machines per week, that would be more than a year without any network infrastructure required.  No network guy required.

Get it?

Related posts:

1. Cisco 6100XP aint Switches like VMware ESX aint Linux
2. Tradeoffs between scalability and performance in UCS
3. How real life became my worst nightmare

It's all about End User Experience, right?

If you are deploying a VDI solution into your portfolio of desktop services, then you will be migrating users from their legacy devices to their new virtual desktops – but how do you do that?

I talked with a senior exec recently who had experience of building out trading floors and moving individual traders, and in his opinion each move was a project on its own.  Maybe migrating a thousand call-center users is a little bit different than a trading floor, and in fact there’s a wide spectrum of users with different migration needs, but I think there are important lessons and practices that could be learned from the trading floor example and apply to the rest of the spectrum.

Take, for example, two simple considerations when you focus on the end user: scheduling, so you don’t impact them, and communication, so you keep them informed and listen to their requirements.  Neither of those are technical activities, but how common are they in VDI projects?

Scheduling isn’t as simple as it seems.  It’s not just about the milestone when you “flick the switch” and the user is migrated over a weekend to their new device.  VDI projects always have ROI targets that equate to “migrate X users per month, and complete Y migrations by the end of the year”.  This is a back-office IT constraint that can over-ride the most important part of VDI: the end user.  Everyone talks about “end user experience” as the most important aspect of VDI, but they really mean “protocol performance”.  It’s my humble opinion that end user experience starts with the migration, so get that wrong and you are looking bad before you start and giving end users a reason to complain.  Some key things to do in the schedule:

• The schedule is a compromise between ROI and end-user satisfaction
• Be prepared to bend the schedule to fit around the end-users work.
• Make the schedule transparent with lots of detail about the leading up to the Big Switch and what happens afterwards.
• Make it easy for the end user to communicate with you about the schedule.
• Bundle the end user schedules up into a big VDI deployment schedule and have it colourfully displayed on a wall for everyone to see.  Honestly.

Communication is about two ears and one mouth.  Consulting with end users does not mean you telling them what is happening, though that is important; it means you listen to them intently because what they are telling you is how to make the migration successful.  This might be hard for techies to swallow, but this is marketing and PR.  Yes: you have to market your VDI solution, and VDI is such a visible solution that you must do internal PR.  That means understanding your market (end users), modifying your product to market requirements and getting success stories to communicate, and much much more.  If you don’t have a communication (marketing and PR) section in your VDI plan, then you should.

Much of what you find on the web about VDI is technical and mostly on the important pieces of desktop and application virtualization.  Often the underlying, back-office aspects of compute, network and storage and operations are diminished although storage is more talked about because of the IOPS challenges.

What is missing from the web when looking at VDI are the non-technical delivery considerations: just how do you do VDI?  Not the architecture, that’s the easy bit!  How do I define my strategy, understand my market?  How do I deploy it to schedule whilst making it a good experience for end users?  How do I operate all twenty layers?  How do I even know the solution was successful?  How do I merge my End User Computing and Data Center teams?  What do the help desk need to know?

It’s a big topic and I just don’t see anyone talking about these issues on the web, or am I missing something?

Related posts:

1. The 20-layer VDI model

Vote with your fingers

Shameless plug, but it has to be done!  Voting is now open to the public to choose VMworld sessions!  Awesome idea by the VMware team: well done!

As one of the people who worked at VMware on several previous VMworlds I know that choosing sessions is incredibly hard and people are often disappointed.  The problem is, what we often *think* is a good session is sometimes rated *poor* by the attendees, and previous scores are a key part of the next VMworld decision process.  There’s a balance to be achieved that has so many pressures: it’s a tough job and you have to respect the VMworld organisers even if the decision doesn’t go your way.

I think VMware are doing something awesome in they are extending this scoring system to a public voting system so they have more data on which to make the final decision.

I’m hoping you, Dear Reader, will take some time out of your busy day to vote for my session if you think it would be of interest.  Here’s the link and the description of my proposal:

Private Cloud Management – A7792 - Turning VMs into job queues for maximum ROI

Most vSphere implementations have excess capacity that could be used by the business instead of just burning money without return. To get these two benefits (business agility and increased ROI) you need two operational abilities: 1) Understanding what excess capacity is available and when. 2) A method for scheduling workloads to use that excess capacity. An example of using the excess capacity is bringing up a database system to do more business data crunching, or deploying a Hadoop cluster to run scheduled jobs against large datasets. This session will demonstrate these two operational capabilities and how they deliver the two benefits of getting IT to do more for the business.

This session is all about using the Stranded Capacity that is so ubiquitous in enterprise computing (unlike Amazon Cloud which has a more even distribution): so this session describes one method of exploiting that capacity to run other workloads.

Think: VDI running on ESX is *mostly* busy between 6am and 10pm.  That means eight hours a day, fifty-six hours a week and nearly three thousand hours a year there is some measure of excess capacity.

If you could exploit that with minimal risk, would you?  Could you?  I think so, and so do others… vote for me and find out why and how!  This will be a practical demo followed by a discussion.  More detail and data, less theory.

No related posts.

IT Rock'n'Roll Band

Having just watched an awesome four hour documentary on the legendary Tom Petty and the Heartbreakers, it finally struck me:  Tom Petty is like a passionate IT sysadmin, and his record producers are the ITSM guys.

The way that Tom Petty describes his art: the way he writes songs, on his own and with teams, how much effort and passion he puts in, how it takes over his life but how it’s quite freestyle and comes from somewhere that isn’t his conscience and certainly isn’t to a plan (that he knows of) reminds me of IT.

Whether an app dev, app admin, infrastructure engineer or operations: a technical role is a mixture of technique and art just like guitar playing.  But, being a good guitar player doesn’t make you a recording artist that can produce a profitable product on time: you need a producer and engineer.  ITSM claims to offer these production and engineering quality and efficiency services to IT artists.

This is a much more positive view than the prevailing view that ITIListas have been trying to push their process onto non-ITIL people, because apparently non-ITIL people are broken and Just Don’t Get It, for the longest time.  Time to heal the rift with techies valuing ITIL for its production values, and ITIListas like Rob England valuing IT experts for their skills.

Tom Petty worked well with producers and engineers who knew how to make a good record efficiently.  Without a good producer, Tom struggled to produce output: his Mean Time To Repair (MTTR) was horrible.

Here’s where I think Tom and his producers become a good metaphor for IT:

• Every IT org needs a rock’n'roll band who play their role.  This means they need to be awesome and need to be awesome together.  Rewarded for results, not for mediocrity, not for bad rock’n'roll behaviour that produces no value and just broken TVs.
• Every IT rock’n'roll band needs a producer/engineer team to make them efficient.  This means the producers need to know a lot about their trade, and not just superficial criticizers.

I have several projects this year to bring IT Rock Stars together with the ITSM Producers: it’s going to be a rock’n'roll tour!

No related posts.

I’m not a VDI expert but I do know a little bit about it so I get a chance to talk to customers on the topic.  One of the things I share with them is how complex VDI really is and I wanted to share my thoughts with you in the hope that something good emerges out of the discussion.

First of all, I think of VDI as a service not a solution.  That service has customers and end-users, and it is comprised of technology layers like “Desktop” and “LAN” and it also should contain service elements such as “Monitoring” and “Availability”.

I jokingly call this the “20-layer VDI model” and it’s not a serious attempt at a reference model, it’s just for illustration.

The 20-layer VDI Model

On the left you have the teams who own the different layers.  Each layer is components like “product” or “process” or something, it doesn’t have to be a specific product.  At the top the service starts with end users, at the bottom you get the back end infrastructure and operations.

The main talking points about this model:

1. There may be fewer or more layers, but there are always many.  Many layers means complexity.  Many layers means many teams which means tribes which means communication challenges and an increased probability of the Somebody Else’s Problem field appearing along with a reduced Mean Time Between Cockup (MTBC).
2. Different end users have different requirements and therefore different routes through the layers where more than one option is available.  The same end user might use a different path (e.g. internal LAN vs. external WAN) depending on their location: will they get the same SLA?
3. Shared infrastructure is inherent in this model, and that means mature operations are critical.  The network teams are pretty good at this as they’ve been doing shared infrastructure for years and therefore have highly redundant and available systems and methods.  But it counts for nothing that the network team are 99.999% available if the broker is only available 80% of the time.
4. There is a tendency to ignore the layers you don’t understand or don’t control.  This is a common and fatal mistake, mostly perpetrated by vendors who specialize in a niche area.  You’ll see this where important, complex pieces are abstracted away into a “cloud” or a big box with “data center” written on it.  Somebody has to do the tough stuff, it doesn’t disappear.
5. An action at one layer can impact the behaviour of another layer, sometimes unintentionally, with catastrophic impact on the service.  SMS update to 1000 desktops bringing down the SAN?  No, surely that can’t happen…can it?

What I strongly advocate for VDI is the creation of a standalone VDI Service Team that is involved with VDI from strategic inception all the way through to operations.  They write the VDI PID/Charter.  They have budget that they spend on Technology Providers.  They own the governance, standards and metrics for the service.  Technology providers own the people, tools and technology of individual layers.  The VDI Service Team reports to the CIO, or equivalent.  They do things like measuring and reporting on availability and capacity.  They host the bride calls when a Sev 1 outage occurs.

One shocking finding that I come across consistently is the common VDI refrain “End user experience is #1 focus” is always technology focused (e.g. best protocol for bandwidth, latency, features etc) and never, ever IMHE focused on mature operations and “boring” stuff like Availability measuring, analysis and reporting.   If you can’t tell me the availability metrics for each component for each layer for each team and for the VDI service as a whole, then why waste time evaluating protocols for “great end user experience” when you don’t have control nor understanding of the service?

Well, that’s what I think anyway and that thinking is based on quite a bit of involvement in VDI projects and observations and analysis of countless more VDI projects.  Customers get it, especially the people who will be ultimately on the hook for VDI.  However, there are much better VDI experts than me out there and I’m curious to hear what they think…

Related posts:

1. Five nines availability for VDI: no way!
2. VDI and The Missing Art of End User Migration
3. Feeding the IT Shriekometer: 5 VDI anti-patterns
4. Plink. Plonk. Splunk.

Finished Chicken

“Eggs in one basket” is a meme, it is not a tangible real thing.  It’s an irrational but real fear.  Let’s kill it, people!  Eggs are laid by chickens.  Right?

Applications in virtual machine are not like eggs, and hosts are not baskets.  An egg is easy to break, and when it gets broken it’s finished for good.  You can’t put an egg back together.

A modern computer application, unlike an egg, can be resilient to breaking and even when it does break it can be restored back to normal in minutes.

Don’t be scared of something going wrong: embrace it, for it will happen, my friend.  When you face this eventuality you are set free.  You will build resilient, automated and highly available systems.  If you think of applications as eggs, where any failure is a catastrophe, you’re screwed.

What about the basket?  The biggest fear in virtualization is that multiple applications running on one host means that any outage to the host means a big impact on service because multiple hits happen at the same time.

The pressure is on the host to be as “up” as possible, with five-9′s desired.  This is wrong. Plain.  Wrong.  The Host is not the problem, it’s our thinking that is wrong.  Here’s why:

• All applications can fail at any time for many reasons.  Applications should be resilient to failure through human techniques such as Electrify The Fence and protective  redundancy.  If one node dies, the service keeps running at reduced capacity.  If your service can’t afford this kind of resiliency and it has Single Points of Failure (SPoF), then your availability might be in the 80% range:  that’s a fact of life, like buying a Ferrari kit car with a Toyota engine means – guess what? – IT AINT A FERRARI.

• Face up to the main cause of outages: me and you; us dopey humans.  Our success is measure by the Mean Time Between Cock-Up (MTBCU).  For those unfamliar with my English vernacular, a “Cock-Up” is pulling the wrong cable, rebooting the wrong server, and eating bacon with jam.

• If you think a Host = Basket, then you’re wrong.  Your face is so close up to the paper you can see a word but not a sentence, and certainly not the whole story.  At last week’s London VMUG I heard two people refer to the Basket as the platform/vendor or a stack of blades.  That’s more like it.  I prefer to think of the basket as The System, a top-to-bottom layer of technology stacks (compute, network, storage) with resilience and recovery built in, where you can measure availability from the view of the service consumer.  In The System I expect apps to break, servers to be rebooted incorrectly, networks to flap, disks to break: and because of this, I build in resilience and recovery to cope.

• Until Administrators are rewarded for higher ROI through higher consolidation ratios, instead of being severely penalised for the impact of failure, then virtualization will stay at 30% and people will equate Eggs in one Basket to “How to get fired”.

• Nobody, not you or me, knows when Too Many is Too Many.  Is one egg in a basket too many?  What about two?  What about thirty-two?  What about three hundred?  How do you calculate the line-that-must-not-be-crossed?  Yes, this is a risk calculation, but you show me an Admin who has set Maximum VMs Per Host because of a Probability and Impact calculation…

So there you have it: applications are not eggs and hosts are not baskets.  The fear of “Eggs in one basket” is irrational and unfounded IF YOU ACCEPT FAILURE HAPPENS AND BUILD RESILIENCE AND RECOVERY INTO THE SYSTEM.  Note those important words:

1. ACCEPT FAILURE

2. BUILD RESILIENCE AND RECOVERY

3. THE SYSTEM

Related posts:

1. Don’t be a chicken, cram your eggs into vSphere on UCS

VDI, or Shared Desktop Services, has a critical Key Performance Indicator: Availability, which has a direct impact on end-user experience.  If the desktop service is unavailable because of a failure of any single VDI technology layer, then user experience suffers.  So how do you measure VDI availability and what are typical values?

I saw a great slide yesterday by one of our Tidal Software guys (you did know that Cisco has it’s own enterprise service management software suite, right?).  It showed how a service made up of different apps can have a poor 80% service availability score even if some of the technology components are up 100% of the time.

What is VDI if it isn’t a multi-application service?  In fact, VDI is the gorilla of shared, multi-layer services with expectations of zero downtime and severe consequences against business productivity when availability is poor.  So why isn’t everyone talking about VDI availability?

1. Redundant components only mean higher availability within a layer.  More layers means lower availability.
2. What’s the point of one layer being 100% available if others are at 80%?  This has cultural complications, as you can well imagine.
3. Measure availability for VDI at three points: layers, Service Desk, and end user.
4. Give the end user the SLA, no more no less.  More costs money.  Are you competitive, though?
5. Cheat a bit and only focus availability on an operational window that isn’t 24×7.  If you provide 24×7 availability, see (4).

Overall Availability

If you look at any VDI solution it’s made up of multiple technology layers managed by multiple teams.  Here’s a generic list from the front (end user) to the back (storage), but your mileage may vary so don’t argue about the list items as they are not important by themselves, it’s the cumulative effect of downtime on each layer that matters.

You can work out the effect of combined downtime by multiplying the (real or predicted) availability of each layer: the more layers the less aggregate availability.  Why is this so?  Imagine a simple example of just two layers:

1. If one layer has a one hour outage in 24 hours, that leaves 23 hours uptime (about 95.8%).
2. If the next layer has another one hour outage then its availability is also 23 hours / 95.8%.
3. The combined availability, if the layer outages occur at different times, is 2 / 24 = 91.7%.
4. You can get the same availability by multiplying the two layers’ : 95.8% x 95.8% = 91.7%.
5. The caveat is in the case that the two outages occur at the same time and so more sophisticated calculations are required (Google is your friend).

Point 1: Multiple layers can lower availability of the service, while multiple components can increase availability of the layer

You can calculate the availability at each layer by finding the downtime for each component in that layer, multiplying their downtime and subtracting from one:  A = 1 – f^2 (this assumes all components have the same MTBF)

For example, if you have two redundant web servers that have 99.9% availability each, then you calculate the availability of that Web Layer (two web servers) as 1 – 0.1% x 0.1% = 99.99% (an improvement of .09%).

However, where having multiple redundant components increases availability within a layer we know that having multiple layers only increases the probability of lower availability for the service.

If more layers decreases availability then there is more bad news for VDI:  the fact that these technology layers are managed by different teams.  If these teams don’t work cohesively, characterised by disconnected tribal knowledge, different toolsets and unawareness of things beyond their silo, then your MTBF is likely to shrink as uncoordinated actions cause outages, and (double whammy!) the MTTR and deliver fixes becomes longer because it’s hard to find the root cause and fix it.

Point 2: Even if a layer has 100% availability, other poor performing layers will reduce the service quality and everyone gets blamed.

But what does the end user actually see?  Even if you can calculate the probability of availability for layers and the service, and analyse the real results against those calculations, the most important data points to collect are at the front-end of the VDI solution.  A couple of common approaches to working out availability and quality of service from the end user perspective.

1. If you’ve got a good Service Desk, then you should be able to calculate approximate availability based on incidents raised.
2. If you’re more scientific, then put automated monitors at the end user locations.

An automated monitor can be something as simple as a PC with automation software simulating a user and recording bad experiences and feeding that data up to a central system.  What would be more awesome would be individual monitors on each end point that can record the availability and send to a centralized system automatically.

Point 3: Measure availability across the solution at component and layers, verify with Service Desk, and measure at end-user points with simulation monitors.

So, now that you know how hard it is to get great uptime on VDI and how you can calculate, predict and monitor it: what can you do to improve it?  I would suggest the following essential three steps:

1. Treat VDI solutions as a Shared Desktop Service. I’ve written about this before and can’t stress it enough: if you don’t actively manage VDI holistically with service management front and foremost of mind, then you will be at the mercy of rogue silos.  You Have  Been Warned.
2. Make sure every silo understands the impact of their actions: (1) their availability has a direct impact on 5,000 users, and (2) if they impact another silo’s availability (SMS update to all desktops crashing the SAN?) this has a direct impact on 5,000 users.
3. Communicate the cost of availability and visibly punish those that affect it. What does four hours out of a business day cost to the mortgage application team?  When it happens because people break the service management rules, then it’s three steps to the door: (1) name and shame, (2) warning, (3) re-assignment (including to the unemployment line).

Still think your VDI solution has 99% uptime?  You are saying that for all technology components and facilities that, combined, there is only 87.6 hours downtime per year.  However, that might be acceptable, in fact you may be exceeding your SLA!

Point 4: Know your availability SLA and only give the business what they pay for

What if your VDI solution is only required to run between the hours of 8am and 6pm from Monday to Friday, then you have a better focus on availability and increase chance of high availability because more than half the week can be spent on planned maintenance.  In this case, you are looking at a total of 2600 hours per year instead of 8760, leaving you a whopping 6160 (70%) hours of the year for maintenance.

In that kind of smaller, focused window you still can’t prevent unplanned outages but by eliminating planned outages your availability should increase significantly.

Point 5: If you can focus on a smaller service availability window your availability should improve.

Lastly, what’s the best possible availability for VDI?  Check out this table that shows, cumulatively, even if all of your layers are at five nines availability that’s still calculated at just four nines for the service.  However, of course, you can exceed this if some of your technology layers have 100% uptime.  I have seen this happen only in reduced operational windows (8am-6pm) with absolute focus on uptime at the expense of change.

In summary, it is possible but unlikely to hit five nines availability for VDI unless you have a reduced operational window AND keen operational focus on uptime.  But, if the customer hasn’t asked for or isn’t paying for this kind of uptime, then so what?  Oh, you don’t know what the customer expects?  Right, well I’m sure you’ll know when the next incident happens and he or she is calling your desk with a few choice words in explanation of what an hour’s downtime costs.  HAVE FUN!

Related posts:

1. The 20-layer VDI model
2. Plink. Plonk. Splunk.