13

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.

ewwhite
  • 194,921
  • 91
  • 434
  • 799
  • 1
    I'd like to point out that most if not all management units out there allow access to the serial port via the IMU's command line interface accessible via ssh or telnet. Often if there's an "advanced" license required for a graphics console via the IMU, it's not necessary for serial port access this way. Thus, what you usually want to be asking is, "why do I want to use a separate box connected to the physical serial port connector rather than using the IMU's access to the serial port? – cjs Apr 25 '16 at 05:01

6 Answers6

8

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.

Community
  • 1
Stefan Lasiewski
  • 22,949
  • 38
  • 129
  • 184
  • 2
    One additional benefit: consistency of access. Having worked in an environment where we had ILO, Drac, ILOM, and IPMI, plus real serial console access servers, there was something to be said about being able to use one tool to access every system the same way, every time, no matter what the system actually was. – Travis Campbell Jan 20 '12 at 22:17
4

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.

Matt Simmons
  • 20,218
  • 10
  • 67
  • 114
  • I usually purchase hardware with full ILO or DRAC licenses, so I can get the necessary separation between networks by leveraging the dedicated management NIC. All else equal, would you choose a dedicated DRAC NIC over a serial console? – ewwhite Jan 09 '12 at 01:44
  • 1
    All other things being equal, probably so. Aside from the benefits I mentioned, the ability to remotely powercycle is great. Remote KVM is very handy as well, plus a lot of the DRACs support remote virtual media presentation (presenting the remote server an ISO as a CD-ROM). You can't get that with a serial connection. – Matt Simmons Jan 09 '12 at 13:22
  • 1
    Most of these cards also give good status reports of the server they live in, which is also quite nice. I even scripted up something to SSH into all of our Dell chassis management controllers and dump the status (to find dead drives in RAID arrays, bad PS, etc), until we get a real central management tool. – mfinni Jan 09 '12 at 13:45
  • mfinni: Have you looked into OpenManage? – Matt Simmons Jan 10 '12 at 01:14
  • @MattSimmons - Dell Management Console looks like an immature ungainly beast right now, and overlaps too much with SCOM and the Dell VMware plugin, both of which are in our near future. I'm investigating OME as a decent stopgap for firmware patching and light management. – mfinni Jan 11 '12 at 16:43
4

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.

mfinni
  • 35,711
  • 3
  • 50
  • 86
  • Although according to one of my Windows Consultant friends, it is possible to run Windows without a GUI interface and have only a command line interface. I haven't seen this in person so it's just hearsay to me, but I think it if wasn't for the the ubiquity of Linux this would have never happened. – Red Tux Jan 09 '12 at 15:30
  • It's called Windows Server Core. It probably is a response to Linux; but because so few Windows components can be configured using plain text files, it's a PITA to get a lot of things done. It encourages remote config and management (generally a good thing) but it reduces the number of things you can do easily at the console (not a great thing, to my mind.) It reminds me of old Netware, in some ways. – mfinni Jan 09 '12 at 15:52
  • 1
    And Core is *STILL* a GUI - it's a graphical desktop with nothing but two CMD windows. It's not like you can connect to Core over serial and do shit - so my point stands, AFAIK. – mfinni Jan 09 '12 at 15:53
  • Seriously? Wow, that's a fail... – Red Tux Jan 09 '12 at 16:38
3

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.

Paweł Brodacki
  • 6,451
  • 19
  • 23
  • 1
    The ILO can perform console replay, I believe. Or if it's an ugly crash that doesn't trigger the watchdog timer reboot, the remnants are usually displayed on-screen when you connect. – ewwhite Jan 08 '12 at 18:06
  • You are right, ewwhite, but I think that you have to specifically configure it that way. – gWaldo Jan 08 '12 at 18:29
  • @ewwhite That's my point "the remnants" :). And I did not know about the replay functionality, thanks for the information. – Paweł Brodacki Jan 08 '12 at 19:41
  • 1
    Okay, that's one situation. Are you suggesting serial consoles used in conjunction with ILO technology? I guess I'm not used to crashes that leave traces that can only be retrieved by console output (versus an IML log, system logs, etc.) – ewwhite Jan 08 '12 at 22:10
  • I am not used to systems crashing at all, but I like to be prepared. I like bell & suspenders approach. Of course, if a single solution works and you are comfortable with it, and there are so many systems, that shaving 20 minutes of configuration off one is a tangible benefit, then it can be reasonable to choose one. Otherwise I would go for both. For some people/uses one approach/tool will be more convenient than the other. – Paweł Brodacki Jan 09 '12 at 07:38
2

I think your need to evaluate the problme you're trying to solve with eaither a serial console, KVM over IP, or the iLO.

  1. Serial Console: basically good if you need out of band access to the iLO's command line. In my six years as a sys engineer, I've never needed it. To a degree this is even less useful in a virtual environment. Since you can SSH into the iLO device, this is only useful in a situation where you need access to the iLO and the network connection might be down, or the iLO is not responding.
  2. KVM over IP: basically good if you don't have the iLO advanced, or if you don't want to proxy through a KVMoIP to access your servers. I like the idea of having one place where i can go to have console access to all my servers, as opposed to needing to make individual connections to each server. This solution is great when you have a ton of physical servers. Another bonus is you don't have to pay for an advanced iLO everytime you get a new server.
  3. iLO Avanced: Provides all the features you need to access your server remotely. The real disadvantage is simply the lack of central managment (at least by its self). You of course get access to things like failed HW as well.

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

Eric C. Singer
  • 2,319
  • 15
  • 17
  • Okay, so use the serial functionality for your network devices and the IP-KVM functionality for the servers? Is there any need to still use serial for the server side of things? – ewwhite Jan 08 '12 at 23:19
  • I'm sorry, are you saying that the serial port on your iLO is plugged into the serial console? I was sort of assuming you had a slightly newer serial console / KVM. Meaning avocent for example, makes a serial console and KVM in the same switch. – Eric C. Singer Jan 09 '12 at 02:08
  • The company is using serial-only console devices that use the serial ports on the server. There's no GUI or ILO functionality. – ewwhite Jan 09 '12 at 02:15
  • For HP users: the serial console can be used after boot even if you don't have iLO Advanced, which may be useful in certain situations. Of course, you have to set it up in advance. – GreenReaper Oct 08 '18 at 12:18
0

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.

Red Tux
  • 2,074
  • 13
  • 14
  • All ILO systems that I'm aware of provide access to the serial port over the network; you can simply ssh into a system on the management network and from there ssh/telnet/whatever in to the management unit and type something along the lines of "console 1" to get access to the serial port. – cjs Apr 25 '16 at 04:57