Linux Serial Consoles for Servers and Clusters
Managing large numbers of Linux and UNIX systems takes a lot of organization, automation and careful use of technology. A significant chunk of one's time as a system administrator is spent building infrastructure to make managing those systems easier. Doing so improves flexibility, recoverability and reduces downtime. All of this hopefully results in less stress and longer vacations. This article discusses one of those simple technologies that helps accomplish all of the above, serial consoles.
Serial consoles always have been a standard feature of enterprise UNIX hardware. Modern high-density server and cluster configurations sometimes can squeeze more than 50 servers in a 19" rack, so having monitors and keyboards for each one is unthinkable. Although KVM (keyboard/video/mouse) switches can connect many servers to a small number of monitors and keyboards, they are expensive and even more so with remote access features. Serial consoles allow you to take racks or shelves of servers and have all their consoles available all the time, from anywhere.
The console is a simple I/O device, initialized early in the kernel boot process to convey informational messages as the system comes up. Once the operating system starts running startup scripts, the console can be used to recover an ailing system or to get input from the system administrator interactively, like Red Hat's Kudzu does. One compelling feature of serial consoles is never having to drive in to work because a system is hung up at reboot asking for input for fsck. After the system is up completely, the console usually becomes a login terminal, sometimes a graphical one. The console also can be used as a last resort method of reporting problems inside the kernel. Under these panic conditions it is not possible always to write to log files or network log servers, so messages are reported to the console. For this reason and many more, consoles on servers should be a simple device, and a serial port is the simplest device included on standard system configurations. For those last-minute panic messages, one could add a console device that supports buffering and logging, so you never miss a moment of the excitement.
What we are talking about here is booting up a system without using an attached keyboard, mouse or video monitor. Some motherboards may complain without a directly attached keyboard, but this requirement usually can be changed in the BIOS configuration. In fact, with the recent popularity of USB keyboards, most BIOS versions do not care about missing keyboards. If you are using a system that was designed to be a server, you may be even more fortunate. Several vendors have started adding extra functionality to their BIOS versions to better support serial consoles from power-on. These features sometimes include power-on system test (POST) output and BIOS configuration access over the serial port. Depending on your needs, you can select your hardware accordingly by checking the vendor specifications. Even without BIOS support, you still can use serial consoles quite effectively on almost any PC system.
This is not a perfect solution, though, and your average PC hardware does not provide all of the features available in typical enterprise-class UNIX hardware. PC BIOS versions do not have the concept of a boot monitor (see the “What Is a Boot Monitor?” sidebar), nor can you perform a hardware halt of the OS as you can in enterprise UNIX hardware. For many applications this is okay, but when more functionality is needed add-on hardware options are available, and I discuss them later.
What Is a Boot Monitor?
Classic UNIX hardware (Sun, HP, SGI and so on) usually has a feature called a boot monitor. Think of it as a tiny operating system built into Flash memory on the motherboard of a server or workstation. Sometimes called a boot console or prom console, they function as a PC BIOS and a bootloader in one. They are responsible for understanding all manner of boot devices and getting the kernel image into RAM and running. Most boot monitors can boot from the network for diskless operation or recovery from a failed boot device. One key feature of boot monitors is they stand between the console and the kernel, so it often is possible to suspend or halt the running OS and drop to the boot monitor with a magic keystroke. Then, even better, the OS resumes where it left off. This allows you to diagnose hardware problems or forcibly reboot the system even if the kernel has died. In a PC system, only a skeletal set of hardware support exists in the BIOS, and the rest must be provided by small chunks of code provided in Flash memory on the hardware itself.
Most PC hardware BIOS versions can be configured only with a directly attached keyboard and video monitor. Luckily most come with usable default settings, so this is not normally an issue. If it is, you may need to have the system initially configured with direct attached video and keyboard and then switch to serial console. In my experience, I have rarely needed to do this; it needs to be done only once during initial hardware setup.
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
- Concerning Containers' Connections: on Docker Networking
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- A Project to Guarantee Better Security for Open-Source Projects
- Where's That Pesky Hidden Word?
- Firefox Security Exploit Targets Linux Users and Web Developers
- My Network Go-Bag
- Doing Astronomy with Python
- Three More Lessons
- Build a “Virtual SuperComputer” with Process Virtualization
- diff -u: What's New in Kernel Development