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.
In the case of network gear. sometimes a serial console is the only way to remotely manage the appliance.
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.
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.
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.
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.
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.
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.
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.
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.
For me the primary benefit would be capturing of oops/crash logs. With the likes of ILO you are loosing whatever rolls out of the screen. Serial console allows you to collect the whole thing and record it without using a camera.
I think your need to evaluate the problme you're trying to solve with eaither a serial console, KVM over IP, or the iLO.
With that said, all of these can be combined into a massive solution, or you can pick and choose. Most modern KVMoIP or Serial console are actually combined as one unit now, so you could in theory have a KVMoIP and Serial console hooked into the same switch. It will eat two console ports though (one for the serial port and the other for the KVM). IMHO, tapping in to the serial port isn't a huge win. You'd be better off with eaither the iLO advanced, KVMoIP or both
One thing not mentioned by anyone so far but rather implied is the ability to directly SSH from one system into the console of a host without the need for a special application (often written in Java) to show the remote console. Thus it is easier to put a system in a colo behind an ssh jump box and ssh into the system via the serial console. This is done because often various TCP ports on the serial console server can be associated with physical serial ports on the box. In addition some serial console servers allow for you to install SSH keys and only allow connections using those pre-installed ssh keys. This is most useful when you need to place an ssh console server on the Internet directly for situations where you need an external (to your network) way to gain access to edge routers and other equipment/systems.
SSH-Serial console servers are not the final word in systems administration just as iDRAC and other similar tools are not the final word, rather they are tools which address a specific need and often can compliment each other.