Real benefits of serial console servers (with modern server hardware)?

I'm working in a new environment that makes heavy use of serial console servers for server management. They are augmented with switched PDUs for power management. They are not using the DRAC capabilities of the existing servers.

I'm adding new HP ProLiant equipment to the site, and am curious as to the benefits of serial consoles versus the ILO/ILOM/DRAC technologies available on modern servers. This is a Linux environment that will grow to include more Windows systems. I'll be running a mixture of blades and DL380's. Assume fully-licensed/enabled versions of ILO/DRAC on any future equipment.

I've configured serial consoles in the past, and have found them particularly useful for network gear. I'm confused as to their advantage or usefulness in an environment where the servers will have onboard lights-out management.

Solution 1:

I've configured serial consoles in the past, and have found them particularly useful for network gear.

In the case of network gear. sometimes a serial console is the only way to remotely manage the appliance.

am curious as to the benefits of serial consoles versus the ILO/ILOM/DRAC technologies available on modern servers.

I'm having this exact debate with my coworkers. I'm leaning towards the iLO/DRAC technologies, while others want to stick with the older Serial Consoles.

Here are some advantages of Serial Consoles vs the newer iLO/DRAC/IPMI technologies.

1. It's true that iLO, DRAC and some IPMI implementations support KVM-over-LAN. However in every case that I've seen, the KVM-over-lan requires that download a Java software package through my browser, which then opens up a VNC-like client to the remote server. This software tends to be buggy, slow and is unreliable. Some of this software ignores my browser and system network settings (like the PROXY setting).

   a. Some vendors may use one of several different IPMI implementations for different models of hardware, and each has it's own funky quirks (I'm talking about YOU, Supermicro). So you might have 100 servers all from the same vendor, but there are 3-4 different IPMI/BMC chips.

2. Some people like the simplicity of Serial Consoles. Learning how to configure the serial consoles can be a steep learning curve, but once you get them working they are generally pretty solid and consistant.

3. If your organization already has an existing serial console infrastructure (e.g. with all the cables, DB9 adapters with the correct pinouts, etc.) then using serial consoles on new hardware may be simpler then configuring the iLO/DRAC on new servers.

4. FreeBSD and Linux can only have one primary console, and will only print certain messages (Like the FSCK prompt) to the primary console. You must chose either the Serial Console or on the VGA console (e.g. the attached keyboard/video/mouse, and by extension the KVM-over-LAN); not both.

5. IPMI exposes some powerful information to the network, so placing IPMI on your network should be done carefully. Many shops put IPMI on a separate, non-routable, secure network. A VPN or SSH tunnel can be used to securely access the IPMI services, but just look at some of the wonky solutions that some of us need to do just to access the IPMI console.

Solution 2:

Belt and suspenders? The iLo/DRAC/SupII card (as useful as they are!) is still another bloody computing device with its own firmware and bugs; it can crap out on you. Serial access, especially for console-oriented OSes like U*x, can still be useful especially in an emergency.

Now for Windows though, it's almost useless for most sysadmin purposes.

Solution 3:

I'm contracting for a company right now that uses DRAC in conjunction with serial consoles.

The company in question did not expend the money to get Enterprise-level DRAC hardware with remote console, but iDRAC6 Express still offers some benefits, the strongest being the ability to remotely monitor the status of the hardware and to perform firmware installation.

As I understand it, the iDRAC Express uses a shared ethernet port (eth0 on the motherboard). If you're in the situation where you need this for production use, you have no chance of moving your DRAC access to an Out of Band (OOB) network, which is best-practice. With the aid of a console server, you can at least have access in an OOB network, even though there are still security implications from having that shared port on the common network.