Edward de Bono

I was listening to a great radio show this morning that featured Ed de Bono.  If you don’t know of him, then please look him up.  His many ideas include Lateral Thinking and Provocative Operators.  In the car this morning the “de Bono” neuron in my brain bumped into one of the ITIL ones, and the ITIL Tragic Quadrant was born.

As usual I thought I had been innovative but in reality someone had already beaten me to it when it comes to Tragic Quadrants.  But nobody has done an ITIL version, so here goes.

I think the reality of ITIL is not what you hear from the mouths of ITIL consultants and vendors.  For example, one reality aspect is the cost of “doing” ITIL is like an iceberg: we know it’s big, but how big is it really?  The consultants and vendors either don’t know or won’t tell.  The number is probably much larger than we think, but I already talked about that.

Is the reality of ITIL a good or bad thing?  Can you even call ITIL good or bad?  Perhaps it is intended for good, but it’s results are bad?  Who knows, because nobody, despite decades of existence, seems to have any data (except for the Consultants and Vendors, and who’s going to believe them?).

So what about measuring if ITIL reality measures up to the hype?  Could these be our X and Y axis?  Not living up to hype, well that’s like not getting something you really want and that could fairly be called tragic depending on how far off the mark it is.

So how far off the mark (tragic) is ITIL?  That’s a tough one, but a simple measure might be (and I emphasise might) comparing the hype to the reality: who’s doing the talking, and who’s doing the doing?

I tried to picture this in my first attempt at an ITIL Tragic Quadrant.  In de Bono’s words, this is a Provocative Operator: I don’t necessarily believe in the truth of this, but I do believe in it as a way of provoking debate to find…something?

ViewYonder ITIL Tragic Quadrant

Related posts:

1. Is ITIL ‘Gerin Oil’ for IT?
2. The ITIL believers are massing, Pink with embarrassment?
3. ITIL v3 Service Operations sullied by HP marketing?
4. ITIL Certification is an oxymoron
5. ITIL is about Technology Adoption

It's the Wrong Trousers, Gromit!

A recent discussion inside Cisco which overflowed onto Twitter makes me wonder just how much money is being wasted out there in the name of Best Practice (meh).

This particular “Best Practice” (meh) is security-, architecture- and networking-related and it’s about the use or non-use of VLANs.  See the note at the end about VLANs if you are in marketing or have lived in a cave in Afghanistan for the past ten years

First let me get my beef out of the way:  I detest the phrase Best Practice, though I’m a huge fan of building a living library of repeatable practices.  Minor lexical gripe?  Non, monsieur. Best Practices are like Listed Building status: once granted, it’s a bitch-if-not-impossible to remove.  People believe in them: they become Gods.  Their meme propagates around the industry and becomes Fact.  People stop applying reason and instead blindly apply best practices producing architectures that make me want to cry out (in a Yorkshire accent): “It’s the Wrong Trousers, Gromit!”

Twitter quote of @tostaypuft: @jonisick In ref to best practices, Dr Neil Gunther said : http://perfdynamics.blogspot.com/search?q=best+practice

My beef is not technology religious: I don’t advocate VLANs in all cases (just most), and I certainly don’t wish to birch nor burn anyone who hasn’t or won’t deploy VLANs: I advocate reason, and reason includes understanding the thinking behind VLANs (which is the rest of this post) and the cost of not using VLANs, which is:

• Physically separate switches and cables for your single, flat, broadcast network costs tens of thousands of pounds per LAN if it is in a data center just for the CapEx.  Add on the cost of managing it (management agent licenses, design/deployment/testing/maintenance/power/space etc).  It’s serious money.
• Today, right now, everyone is consolidating, unifying and virtualizing.  They are doing that for many reasons including money and the fact that things like VLAN technology has been around for a long time.  Not using VLANs flies in the face of this industry movement, so you need a good reason to stick out like a sore thumb.

Possible reasons you MUST NOT use VLANs:

• Industry or governmental regulation where the cost of not complying exceeds the cost of complying, or you cannot change the regulation (or it isn’t due to change anytime soon).
• If you let any old dude breeze in to your data center where directions to your switches are posted on the wall, next to the admin passwords and a spare laptop with serial cable and pre-configured Putty session.

So, how do you find out more about VLANs in the data center?

1. Read the 2002 @Stake paper on their penetration tests, analysis and recommendations.  Here’s a snippet of what they tested:

@Stake Testing

2. Read the Cisco SAFE LAYER 2 SECURITY IN-DEPTH— VERSION 2 paper.  This describes eight attacks (• CAM table overflow • VLAN hopping • Spanning-Tree Protocol manipulation • Media Access Control (MAC) Address spoofing • Private VLAN • DHCP “starvation”)  in detail and the actual switch configurations to mitigate these risks.

3.Read the Cisco SAFE for Medium Enterprise Networks paper.  This describes a security framework and practices for deploying and securing networks.

4. Buy my team-mate’s book on LAN Switch Security: What Hackers Know About Your Switches.  This book uniquely approaches the whole subject from the hackers point of view, showing tools to use.

What the hell is a VLAN (in layman’s terms)?

If you don’t know what a VLAN is then consider that life without VLANs means that all the physical bits connected together, switches and hosts via cables, are one big flat network.  Sounds simple in theory, but in practice it’s awful (and the bad reasons are the causes of the development of VLANs).

This big flat physical network is bad because it’s a broadcast domain, which means all devices can see each other and after put up with loudmouths on the LAN.  More devices means more noisy broadcast traffic which impacts network performance.  It also means dodgy devices on the network can do naughty things like impersonate other devices. Tsk tsk.

What a VLAN does is allow you transform (improve performance and security) the physical bunch of stuff, switches and hosts via cables, by dividing the one LAN into multiple VLANs in the switch software (a.k.a. logically) so that one cable is on one LAN and another cable is on another LAN – ONE THE SAME SWITCH!  So you divide one physical LAN to multiple virtual LANs and reduce the size of the broadcast domain, addressing the scalability and security issues.

Related posts:

1. Cisco 6100XP aint Switches like VMware ESX aint Linux

I

One shot for every uncommitted snapshot!

It’s that time of the month again where creaking data center doors open to the sound of escaping foul air and out stumble the pasty, blinking virtualization zombies!

This time they will be descending on The Cittie of Yorke (pronounced with a ‘shhh’) pub, so vMotion yourself there, and your wallet, for 6pm sharp!

This venue serves a fine of selection of English beers along with fresh blood and dead fingers.

Location: The ‘Cittie of Yorke’, London

Address: 22 High Holborn, London, WC1V 6BS

Nearest Tube: Chancery Lane

Date: First Thursday of every month

Time: 6:00pm

Ye Olde Map: (click to enlarge)

No related posts.

Following on from Brad Hedlund’s awesome efforts in producing ten – that’s TEN – great short video’s on UCS networking, like all good plagiarists I thought I’d try and do something similar but in a whiteboard format.

The idea is that I show you how I would draw similar concepts to Brad’s videos on a whiteboard during something like a workshop.  You can then copy it, improve it, or take the jovial out of it: the choice is yours!

The first one is just a sub-three minute overview of UCS networking.  It’s real simple, like me.

If you think this format is useful, please let me know.  If you think it’s rubbish, keep it to yourself (no, only kidding, just be gentle with me – I bruise easily!)

Seriously, if you think it’s useful I’ll do more on a whole range of topics.

Check it out on Vimeo – plus here are links to the actual slides (.key) (.ppt)

For iPad users, and those who can’t play flash, there’s a HTML5 player link at the bottom of the video:

Switch to HTML5 Player

Related posts:

1. Brad Hedlund’s Cisco UCS Networking Series

While I was on holiday last week, my Cisco UCS colleague Brad Hedlund released some awesome training information. Bear in mind that Brad did this on his own initiative, in his own time, to help the community of UCS practitioners and just check the quality of content and presentation. A W E S O M E

Cisco UCS Networking Best Practices (in HD)

There’s not just ONE video but TEN!

• Part 1 – Cisco UCS Networking Overview
• Part 2 – Switch Mode vs. End Host Mode
• Part 3 – End Host Mode – Individual Uplinks
• Part 4 – Port Channel Uplinks
• Part 5 – Virtual Port Channel Uplinks (vPC)
• Part 6 – Connecting Cisco UCS to separate networks
• Part 7 – Inter Fabric Traffic Examples
• Part 8 – Don’t: Connect Cisco UCS to vPC domains without vPC uplinks
• Part 9 – Do: Connect Cisco UCS to vPC domains with vPC uplinks
• Part 10 – Connecting Cisco UCS without vPC

Related posts:

1. UCS Networking Overview in a whiteboard stylee
2. Cisco 6100XP aint Switches like VMware ESX aint Linux
3. Tradeoffs between scalability and performance in UCS
4. Over-commiting your infrastructure for multi-tenant DR with Cisco UCS
5. 25 ways that Cisco UCS frees you to do other things

Need to interconnect those data centers? Then OTV might be just for you. Not sure what it is? Got seven minutes to spare? Then watch this!

No related posts.

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. Brad Hedlund’s Cisco UCS Networking Series
4. How real life became my worst nightmare
5. 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
4. vSphere VMM execution modes and Cisco UCS blades