Out-of-band management

In computing, out-of-band management (sometimes called lights-out management or LOM) involves the use of a dedicated management channel for device maintenance. It allows a system administrator to monitor and manage servers and other network equipment by remote control regardless of whether the machine is powered on.

By contrast, in-band management is the use of regular data channels (usually through Ethernet) to manage devices. A significant limitation of in-band management is its vulnerability to problems from the very devices that are being managed. To manage network servers and routers remotely, IT administrators need network access when problems occur. However, the same problems that cause the network to go down also result in the loss of management access to those devices.

Out-of-band management addresses this limitation by employing a management channel that is physically isolated from the data channel.

History

In the early 1980s, the concept of out-of-band was adapted for its natural application across the emerging data transmission network structures being introduced with the onset of Ethernet and cost-effective wide area networks. Network architects recognized that this out-of-band alternative pathway was a key requirement in service availability, and they could readily apply many of the lessons learned within the telecoms industry for the previous 30 years. Some of the earliest implementations of a data network out-of-band structure included the attachment of a single modem to any given server—in essence creating a very small out-of-band infrastructure (OOBI). Vendors such as IBM, DEC, HP, and Data General made very lucrative service businesses by providing such out-of-band tools as subscription-based services products. The ability to interact remotely with servers that were otherwise compromised was a powerful one which gave rise to the growth of out-of-band as a more general tool for data networks.

In the mid-1980s, Encore Computer released the Annex terminal server, later purchased by Xylogics. The Annex was capable of serving one parallel printer and up to 16 serial printers, terminals, modems, or serial consoles to various equipment. Later models supported more serial lines, making it the first OOB management server. It also supported a "reverse telnet" (aka. rtelnet) feature that, through a daemon, created a character device file on the Unix host where it ran. Opening this device created a connection to the pre-configured port on the Annex, thus supporting remote kernel debugging, remote modems, etc.

Beginning in the year 2000, the concept was formalized by many early out-of-band infrastructure data pioneers. It was quite clear that this technology was quickly becoming a core IT requirement when dealing with service levels across hundreds or thousands of geographically dispersed IT assets. OOBI, uses many of the same concepts and provides similar features to the telecom industry's out-of-band infrastructures. Vendors of OOBI solutions began offering these cost-effective alternatives to local administration for data system and network management.

In its original conception, OOBI referred to the physical architecture and components that were used to construct an out-of-band network. A more accurate description would be a service port network since the OOBI connected to the service ports rather than the data ports on the target devices. This network provided the platform to implement out-of-band management (or service port management). Just as in the past, a data OOBI provides alternate paths into the production infrastructure for the purpose of allowing disconnected assets to be remotely reconnected and subsequently returned to normal operation, in most cases eliminating the need for costly local administration. Some OOBI implementations include inherent enterprise-class security while others are constrained to the attributes of limited or proprietary mechanisms. An OOBI can improve operational efficiencies, cut costs, improve productivity and, in many cases, improve service levels and asset availability. Conceptually, data OOB infrastructures virtually guarantee a data "dial tone."

An example of a modern, open remote management interface is IPMI, which in physical terms uses data ports but allows their use as service ports, with a low-level route to a baseboard management controller of some sort configured such that OOB services can be accessed separately over the same IP network. While IPMI does provide remote access to computers even when the OS is down, it actually does not provide completely out-of-band access, because it shares the Network Interface Controller with the data pathway. True out of band access is provided by using a dedicated NIC . This is accomplished by using a Remote Access Card (RAC), or, more recently, through a Soft Processor leveraging a highly integrated BMC (iBMC).

Types of management systems

A complete LOM system consists of a hardware component called the LOM module and a program that facilitates the continuous monitoring of variables such as microprocessor temperature and utilization. The program also allows for such remote operations as rebooting, shutdown, troubleshooting, alarm setting, fan speed control, and operating system reinstallation. The program often integrates into traditional infrastructure in-band management tools such as HP Openview, Computer Associates, BMC, and Tivoli.

The most common out-of-band management solution involves connecting each device's serial console port to a console server. This implementation allows the monitoring of hardware self-test information and console access that is not available using typical in-band management.

Another type of management solution, a Remote Access Card (RAC), involves an expansion card for a computer which has its own processor, memory, battery, network connection, and access to the system bus. This system is effective but costly, and is being progressively supplanted by the use of dedicated Sytems on Chip, also called Integrated Baseboard Management Controllers.

Some LOM systems function with more than one server, especially if combined with a KVM switch. When combined with a terminal server, administrators may access all serial console ports in a network or server farm from a single station. If the terminal server is also configured with network, Internet, and dial-up access, administrators will be able to manage network problems from any remote location, even if the network connection has been lost.

Communication between the controller and the remote servers sometimes takes place through an independent dial-up connection. More commonly nowadays, the LOM modules are connected by serial links to a separate management host; or the LOM module accepts telnet connections over an Ethernet connection. Either way, the LOM can then be remotely accessed over the Internet (through SSH to the management host, and/or a VPN). The LOM module keeps a record of all the operations (known as the event log), allowing the administrator to check instantly any or all of several hundred systems.

SoC based service Processors

Modern systems based on System-on-Chip , or i BMCs, usually have separate Ethernet connection that can be implemented either through dedicated or shared Ethernet port. This connection has its own IP address and other network settings. It remains functional also if the server is powered down and can power it up when required. Systems provide remote screen view (both graphical and text modes), remote mouse and keyboard and remote virtual media (including media that exists only as .iso images on the administrator machine). This access is not dependent from the operating system on the server and also works when managing remotely BIOS settings, for instance. IPMI connection is normally encrypted. Recent server boards have all this functionality built-in and do not require any additional extension cards. IPMI system can also be accessed from inside the server if required (for instance, to read the hardware sensor values). Interaction with the system on remote side can be implemented through web browser (including Java applets or JNLP) or specialized tools that may be cross platform. Open source software like FreeIpmi is also available. The most commonly used iBMCs include ASPEED AST 2050, Nuvoton WC450 (Hermon), Renesas 2164,Server Engines Pilot II and Pilot III.

Console redirection

Embedded firmware of most server motherboards support (BIOS) serial console redirection. And boot parameters of modern operating systems can be changed through the boot loader console which supports redirection as well (in Linux this is LILO, GRUB, or SYSLINUX). A Microsoft Windows feature is EMS. Furthermore, Unix-like systems can be configured to log kernel messages to their (serial) console too. The Linux kernel for example logs all messages to all its configured consoles, which can be a combination of virtual terminals (graphics card/keyboard combination), serial ports, parallel ports, etc. Management software such as the Conserver automatically captures this data, and can replay it if needed. When using serial console servers care should be taken not to send any unsolicited BREAK over the line (especially with Sun hardware, and also Linux if SysRq is enabled) as it can put the machine in "LOM mode" otherwise.. Some solutions use a Java applet to display remote console view to the administrator.

Limitations

Servicing and managing computer servers in a remote data center can require the physical presence of a system administrator. For example, the loading or removal of media, or direct interaction with the server through a console and keyboard (which should only ever be needed if the CMOS NVRAM becomes corrupted). Such access requirements depend on a system administrator being co-located with the data center, often an additional business expense.

Specific implementations

• Advanced Lights Out Management (ALOM), Sun Microsystems-specific and comes standard on newer Sun servers (SunFire V125/V210/V215/V240/V245/V250/V440/T1000, Sun Netra 210/240/440)
• Integrated Lights Out Management (ILOM), Sun Microsystems's ALOM replacement on Sun x64 server SunFire X4100(M2)/X4200(M2)/X4600(M2)/X4140/X4240/X4440/X4150/X4250/X4450/X4170/X4270/X2250/X2270, Sun Blade 6000 Chassis Management Module/Blade Module(X6220/X6420/X6240/X6440/X6250/X6450/X6270/X6275), Sun CMT servers/blades (Sun T5120, T5220, T5240, T6340, T6320)
• Apple Computer's Xserve, which provides lights-out management through the Ethernet network interface.
• Dell DRAC, the Dell-specific "Dell Remote Access Controller;" also called "Dell Remote Assistance Card" or "Dell Remote Access Card" depending on to which version one is referring
• Fujitsu Integrated Remote Management Controller (iRMC) (manual)
• HP Integrated Lights-Out (HP/Compaq specific)
• IBM Remote supervisor adapter (IBM specific)
• Intel Active Management Technology (iAMT)
• Intelligent Platform Management Interface
• LOM port, Sun Microsystems specific used on their older products (Netras)
• Open Platform Management Architecture (Generic interface)
• PC Weasel 2000 (Personal Computer hardware)
• Remote System Control (RSC) on Sun Microsystems SunFire 280R/V480/V490/V880/V890/VSP servers.[1]
• [[Winbond Hermon[2]
• Network Console on Acid (Unix tty redirection over SSH)

See also

• Desktop and mobile Architecture for System Hardware (DASH)
• Systems Management Architecture for Server Hardware (SMASH)
• Alert Standard Format (ASF)
• Console Server
• Terminal Server
• IPMI
• Opengear
• Avocent
• Power distribution unit (for remote powercycling)
• Watchdog timer
• Baseboard management controller (BMC)

References

• "Console Management". datacomideas.com. ASP. Archived from the original on 2004-08-03. Retrieved 2007-05-20.
• "Terminal Server". datacomideas.com. ASP. Archived from the original on 2004-08-03. Retrieved 2007-05-20.

External links

• Lights Out Management by hcoyote on Thu, 2006-11-09
• ILOM Infos
• Lights Out Management - Apple Computer December 08, 2006