Related topics

Microsoft's cloud leaves manual transmission behind

Get to grips with autodeploy

Common Topics

When you write technology blogs for a living you end up sitting through a lot of WebExes, watching a lot of training videos and going to a lot of conferences.

A growing trend that emerges from all these presentations is the importance of autodeployment, something that has far bigger implications than a mere installation method for our operating systems.

There is a comparison I cannot get out of my head: the difference between pets and cattle. The reference was eventually traced back to Microsoft man Bill Baker and it perfectly describes how today's top technology vendors are approaching IT.

What drove this home for me was a VMware video I was perusing in the hopes of figuring out how some widget or other worked.

At one point the presenter asked the audience: "I trust everyone here is using autodeployment?" All 500 people murmured their assent. The presenter continued: "Good. I can't imagine why anyone would use anything else."

This sums up the view of every major technology company, working group, standards body and what-have-you in our industry. We are living in an age of software-defined everything.

IPv6 is based on the concept that you have a series of bulletproof services on your network to make everything work in a dynamic fashion. We build entire private clouds with autodeployed widgetry and profiles of various sorts. Our servers, switches, storage and everything else are defined by dynamic configurations and are utterly interdependent.

Shoot the servers

One of the slides in that pets versus cattle article discusses the differences between the old and the new.

The old way is to treat our infrastructure as pets: you name your equipment and when it gets sick you nurse it back to health. The new way is to treat your infrastructure as cattle: you number your equipment and when it gets sick you shoot it. I am not entirely comfortable with this.

Servers are pets in the SME world I inhabit simply because we don't have the resources to shoot one when it becomes inconvenient. For my clients every software licence matters, ever dollar spent must be accounted for.

At a high level the pets versus cattle debate makes perfect business sense. But the concept has become so pervasive that most of these vendors take the same approach to end-users, with SMEs biting the fateful bullet.

The rebellious part of me that gets all uppity and writes articles about trustworthy computing or questions the legality of cloud computing wants to stand up to this trend and make loud noises until I convince the world to change.

The pragmatic part of me says that I must learn the bits underpinning what appears to be the unstoppable future of computing if I want to be able to pay the mortgage and buy food for my fish.

Modern machinery

I have used forms of autodeployment for ages. I think it would be safe to say that most sysadmins reading this article have as well. The concept is generally synonymous with Preboot eXecution Environment (PXE) servers.

I have used it for everything from keeping my Wyse clients updated to deploying CentOS to more than 5,000 nodes in a render farm to my trusty old Ghostcast servers from the beforetime. I have even been a victim of WDS once or twice.

In an effort to learn modern server farming techniques I have taken a poke at Microsoft's System Center Virtual Machine Manager (SCVMM) and the autodeployment features it has for building a Hyper-V factory farm of interchangeable server cattle. Assuming you have the infrastructure set up properly then farming servers with SCVMM can be pretty easy.

In SCVMM go Fabric --> Add resources --> Hyper-v clusters --> Physical computers to be provisioned as a hyper-v host. Add a run-as account (a domain admin in most environments, but you can do delegation-based security stuff if you care to.) Select protocol --> [next], enter IP address of target cattleserver --> [next] and if you get to the next screen, you have successfully taken control of the target server.

Now that you "own" the target server, select a host group and host profile (something you had to have preconfigured and which contains the operating system image you want to deploy) and hit [next]. You will get a final screen where you can customise host name, logical networks, IP addresses and so on.

After that, hey presto, you have branded your servercattle with Hyper-V. There is a far more detailed walkthrough on that process here.

Of course this can go horribly sideways if the IMPI SMBiosGUIDs presented as part of discovery by the Lights Out Management (LOM) card and that of the target server itself do not match.

This is common in older HP servers, but known to happen in some Dells as well. Fortunately, neither my Supermicro FatTwin nor the miniserver has given me grief, but that doesn't rule out issues elsewhere in Supermicro's range.

Mikael Nystrom has a truly excellent presentation on SCVMM's autodeployment with a lot of focus on the SMBiosGUID issue. It is lengthy (over an hour) but contains the PowerShell I needed to get the old HP servers to behave.