Standardized or Certified Hardware

I used to be a fan of designing and constructing custom built systems, and for desktops that’s still fine, but servers I wouldn’t touch even if you paid me to! Even for desktops I think you still need some uniformity of hardware, Intel or AMD, mainboard manufacturer, and chipset selection. All these factors give you ease of deployment, and some standardization to roll out system images, offer easier replacements of newer parts when required, and they generally work together more.

Most of you know that I use Apple Macs for running my business (and there are plenty who do), the main reason for that is standardization. I know that my software will run on my new computer, and my old one, and that I don’t need to worry about drivers, or this not working with that model. I can tell you that my life in business, and out of business even more so is easier because of it, and I recommend them all the time, not because I’m an Apple evangelist, but because it means I don’t need to keep fixing the bloody things, or have to worry about something not working right (or as expected more to the point).

It’s recently become part of my business to design and implement systems. This is mostly because my clients have heard ‘thru the grapevine’ that when I design, or pull apart and rebuild their systems, their IT bill drops (I know most of you would bork at such a thought, but remember the companies hiring your IT services are wanting to you add value, and that I certainly do), it also means as a result of that little perk for my clients, that I’m not spending time fixing crap because it keeps breaking because this doesn’t work with that on so on. Some of the systems I’ve design or re-engineered have been Mac based, and I’ve used my systems to re-configure (or re-install) the system in a more standardized way which gives more uptime and less frustration (to my clients). The other systems I’ve previously blogged about have been server consolidation through virtualization using XenServer, which I have also standardized the process.

Standardizing Your Servers

The first part of creating a robust virtualized server environment (I made that up just now!), is making sure the hardware is compatible, now I know XenServer will run on lots of hardware, but part of adding value is making sure it’s working well for clients, and adding value. When looking to provision a new server, and what it will be doing will give you an idea of the specification of the hardware on which it will run (that’s the RAM, CPU, and storage), but the next part is how all that works together…

Making your Server parts work together

As I mentioned above it’s quite easy to standardize your desktops, but I wouldn’t consider doing that with a server for one simple reason… I want the damn thing to work, and save my client money (right?). So what I’ve been doing lately is using servers from IBM (they’re providing a competitive price point at present, and we’ve had our first faulty hard drive, we called them up, and a new one arrived the next day - AWESOME!), at present (and I’m not aiming to get flamed here) the other server manufacturer I’d contemplate using is HP, mostly because of their known name, and reliability.

The biggest benefit of using IBM, HP (and probably Dell, but I’ve not tried yet), is that they’re designing their own hardware, they guarantee it works (within reason), their support is available, and they stand behind their product. Oh, and the other benefit is, it’s often certified to work with particular systems software, or at least the software vendors support the hardware.

When you’re putting together a system for a client, in most cases if they understand the scope of what they’re asking for (or you’ve clearly explained to them how critical it is), the initial price bump is justifiable, mostly because the TCO (total cost of ownership) is reduced because they’re not paying a fortune in patching the holes left in a custom built system.

One more thing (RAID!)

One other important factor with servers from the “big boys” is how their system boards work. Those of you familiar with desktop systems know what a BIOS is, and that you hit F2 or delete before you system start to load, with proper servers, they don’t load the BIOS until well into the boot sequence, instead they run a bunch of check, and then load the BIOS (or other OS) prior to loading your destination OS. (This is what provides lights-out-management on ‘real servers’). Now how this relates to RAID is, the RAID is configured prior to loading the BIOS therefore it’s correctly controlling how the hard drive(s) show to the target OS. (Feel free to comment if I’ve stuffed up my explanation here). What happens with your onboard RAID controller on your cheaper/bitzer machine can get very interesting! I’ve seen cases where the person who set it up didn’t consider the onboard RAID controller might be a software driven beast (it can be hard to tell sometimes), and other times where they have used a hardware RAID controller (usually a card), but misconfigured it and the same problem occurs. I could go on about setting up RAID but that’s another story.

Basically… if you’re not using a server system, you can (and do) run into all sorts of problem, mostly small oversights.

Benefits of “The Big Boys” Hardware

• Supported Hardware (even for Unixes in most cases)
• Supported by the Vendor
• Extended Warranties (up to 5 years in most cases)
• Next Business Day Warranties
• Built really well (i.e. the case, redundancy for cooling and power)
• Lights out management