Bladewatch.com

As a server engineer guy there are three main things that were driven into me by my great colleagues about server health/maintenance:

Ensure your drivers are up to date

Ensure your system firmware is up to date (array, disk and system)

Ensure your operating system is patched to the correct revisions

This is for several reasons, first of all everyone now and again we’d have situations where a fault would arise and we’d have to escalate to an external vendor and the first question we’d be asked are: “Can we have your firmware/driver revisions…. What operating system is installed and service pack?” Sometimes even to the “Have you got kb…. installed?” This is because the vendor wants to rule out any of the standard ‘issues’, that the early processors on a certain server on a Wednesday on a full moon under stress and if my newspaper was late could experience unexpected behaviour unless this firmware or hotfix was applied.

With this comes a request to the many vendors out there:

Can the firmware be independent of the drivers? or the driver be independent of the firmware?

I know, I know, I really should have all my drivers and firmware up to date and that there are situations where it can’t always be done for whatever reason. But please understand the issue caused by having dependencies either from driver to firmware or firmware to driver.

Let me explain it this way. The traditional understanding in the Windows world is that I apply an array controller or system firmware upgrade and reboot. But there are times when you do this with the best and Windows doesn’t come back. At this point the panic will set in, you’ll re-read the readme, or the support site, and the site will say “but you need to upgrade driver7 when applying firmware 6.3″.

But let’s step back for a minute. There are situations where I don’t want to upgrade the driver, where upgrading the driver might mean that I need to ratify that against all my different system combinations, that switching from array driver7 to 7.1 might take me weeks through the testing life cycle to load to production, it might also open me to issues where we have the “oh you’re using 6.3 no, that was a bad release, install 6.3.3.8″.

Of course as we move to a virtual world this will become less of an issue, but the difference is, it might become an increasingly important one, where as before having a fault with a server related to the drivers/firmware might be an issue with one server, in the virtual world it might be 4, 12 or 16.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.