Perle Systems White Paper
Perle Systems takes a look at how the network used to be managed and explains its solution for the future.
In today’s business world, many organizations would find it almost impossible to work without access to their network computers or enterprise-wide systems. The ability to monitor and manage these networks and keep them up and running is pivotal to their business. The responsibility to ensure that these organizations have faultless access to their systems is continuously placed on system administrators. Not only must these system administrators ensure that servers supplying mission critical applications are functioning, it is also their responsibility to ensure that the entire network connecting the data to a multitude of users remains functional. When networks crash, productivity and profits do too and the longer a network is down, the greater the impact on the enterprise.
System administrators are continuously challenged by organizations that use wide area networks spanning many remote sites. These networks support a magnitude of remote users dialing in from numerous locations worldwide and are deploying connections to the Internet for access to enterprise data.
The stakes are high to maintain both availability and performance of the organization’s network, regardless of how widely dispersed the network infrastructure is. Generally, it is becoming harder to find technical expertise with the necessary skills and resources to administer such systems. The issue becomes how to expand the capabilities of network management personnel within an organization to better maintain the variety of network infrastructures presently being deployed and to minimize and possibly avoid network downtime and performance loss.
In The Quest of a Management Connectivity Solution
There are multiple methods of connecting to an organization’s network infrastructure in order to perform system management tasks. The most common of these techniques is to manage the system via the network itself. However, managing from the network can have its drawbacks. For example, what happens when, due to system failure or network failure, the system is suddenly not visible via the network? Most computer systems and network devices provide a serial console port for such management and maintenance purposes. The functions that can be performed via these ports vary from one manufacturer’s product to another and can also be influenced by which operating system is used. If we refer to a single system, the administrator may have a monitor and keyboard directly and permanently connected to it, or will connect with a laptop. But, what happens if there are many systems and devices to manage?
Connecting a dumb terminal or a monitor-keyboard combination to every system would require space, hardware, cabling and power supplies for each one. In addition, the heat generated by all of the screens would require additional air conditioning to maintain a safe room temperature for the computer hardware to function properly. Even with a laptop, it’s time-consuming for an administrator to connect, perform service, disconnect and move on to the next server, leaving the staff unavailable for other activities.
The Early Days
One of the early network management connectivity tools used to help system administrators maintain both availability and performance of an organization’s network was the Terminal Server. By reversing the role of the traditional Terminal Server application of connecting terminals to host systems, the Terminal Server could act as a serial port switch to connect one console terminal to many hosts. It could also be accessed from any Telnet client anywhere on the LAN for day to day maintenance tasks. By using Telnet on their administration PC, they could access the Terminal Server and subsequently the attached devices or the host.
This management connectivity solution immediately eliminated the need for separate screens for every device and allowed the administrator to connect from a fixed location. In the case of a WAN, the administrator could even connect to remote sites. However, management connectivity through the use of Terminal Servers could be costly over time, since they were not specifically designed for remote management functions and required a fair amount of set up before they could be deployed. Terminal Servers also present a problem to the large community of users that use Sun servers or Solaris for their computing needs as they can cause systems to shutdown unexpectedly.
Out-of-Band Management of Windows Server Operating Systems
The Emergency Management Services (EMS), available in Windows Servers, provides “headless” support for today's enterprise servers. It enables management services without the need for a keyboard, mouse, local monitor, and video adapter. A server administrator interacts with EMS through a Special Administration Console (SAC) to perform management and recovery tasks, even when the system’s operational status is questionable.
In this scenario, a Windows server can be managed through the server’s console port using a text-based command-line interface. Microsoft recommends using a “terminal server” or “console server” to connect multiple servers to a single point of contact for remote management. The benefits include:
This “Out-of- Band” operation provides the best method for recovery of Windows Servers in remote locations today.
As stated by Microsoft some scenarios where access to SAC is the best way to recovery are;
Now Enters the Console Server Solution
A solution for remote system management is to deploy a Console Server to provide network access to local system consoles. As such, Console Servers provide access to all of an organization’s network infrastructure devices that are managed via a console port over a networked connection. With a Console Server, administrators have access to a system’s console from anywhere on the local network, or via dialup connections, as if they were locally connected through a direct serial console port connection.
Although Console Servers perform similar functions to Terminal Servers as a system management tool, they offer several differences to system administrators.
The main difference between Console and Terminal Servers is that Console Servers are designed specifically to be deployed as a system management solution.
Console Servers provide a solution that helps to maximize system administrators’ productivity. Generally, a single interface provides them with multiple connectivity to multiple appliances and system consoles from any location and is easier to install and set up, saving administrators’ valuable time and costs.
Console Servers generally offer higher level of security features to provide secure access to critical network devices.
“No Break” feature*
Some Console Servers currently on the market address ‘break’ issue making them safe and ideal for use in a Solaris environment.
Most Console Servers offer Port Buffers of varying sizes to ensure data from attached devices is not lost. Without Port Buffers any data sent from a device, while an administrator is not attached, is lost. With Port Buffers this data is captured and can be viewed later to aid in problem diagnosis.
The Present and Future
As organizations’ needs to branch out over wide area networks increases, the Console Server has become a staple among network devices – guaranteeing a system administrator the means to manage network devices regardless of proximity to that device. With dial-in remote access, the Console Server allows an administrator to deploy a modem (some Console Servers have built-in modems) to connect to the unit remotely under any conditions.
In the event of a total network failure, remote access is pivotal. Prior to remote access, the alternative was for system administrators to physically travel to the location of the failing device, gain access to the console port and ascertain the nature of the failure. Remote access now gives the administrators the freedom to travel anywhere, virtually secure with the knowledge that in an emergency they can still connect into their vital systems.
Console Servers are ideally suited for Unix systems, where the actual operating system can be controlled via a serial port with a character based system (refer to Diagram 1). Microsoft™ systems, however, require full GUI control, which can be achieved through a serial console port with specialized software (refer to Diagram 2).
DIAGRAM 1 Connecting Unix Systems and other network Devices In- and Out-of-Band
In the above diagram the Console Server is used as the sole backup connection to the network.
DIAGRAM 2 Connecting to Microsoft Systems
The Console Server could also be connected to ports such as the IRC ports on Windows servers. With this solution, the administrator has the ability to monitor the status of the hardware (hard disks, fans, temperatures etc) virtually from anywhere in the world at anytime. This means the day-to-day management can be performed via the LAN or KVM but, in the event of a failure of either of these, access can still be gained via the COM port. This allows an administrator to diagnose and possibly fix problems and avoid a costly reboot.
Of course, system administrators are not limited to the use of Terminal Servers or Console Servers as system management tools. It is possible to have a costly individual monitor and keyboard for every system, but this solution takes up valuable space and creates unnecessary heat within the system rooms.
KVM (Keyboard,Video,Mouse) systems allow a number of systems to be connected to a single display and keyboard. The cost of deploying this solution can be particularly high if the system administrator is connecting Unix workstations such as Sun or SGI.The option of a KVM solution is generally limited by distance due to signal strength limitations. An added consideration to deploying such a solution is that most KVM switches are large and utilize much rack space and some are unable to handle more than 8-12 device connections. Although they can be cascaded, this is not typically a viable solution for large data centers.
Another network management solution is to connect dumb terminals to a switch box and then to console management ports. While it is good to have this serial switch independent of the corporate LAN, in emergencies, when perhaps it is the LAN itself that is a problem, it is very limiting in day-to-day operations of maintenance and service. This solution restricts the system administrator by the distance limitations imposed by serial connections. By providing the console access over the corporate LAN these functions can be achieved from anywhere where the company infrastructure extends. With a modem attached, the Console Server combines both of these highly desirable attributes.
A Viable Total Management Solution
As organizations continue to expand networks, the need for management of those networks will become increasingly important to the success of those organizations. By using Console Servers, such as the Perle IOLAN Console Servers to manage their critical systems and device consoles, system administrators can deploy a simple and flexible solution to address multiple management problems.
The Perle IOLAN Console Servers (with 1-48 ports) allows system administrators to securely and efficiently run network console ports and server farms remotely. This cost-effective network management tool delivers console port access from any location using In-Band or Out-of-Band via a corporate LAN/WAN. In addition, system administrators can use a highly reliable dial-in connection via integrated modems in the Perle IOLAN SCS range.
For large data centers the Perle IOLAN SCS range also provides unique redundancy with Dual Ethernet used alternate paths or as a hot back-up.This is also ideal for data centers with multiple locations (diagram 2). Additionally, integrated hardware encryption ensures outstanding performance during SSH and SSL/TSL sessions that are very CPU intensive.
Simple SAC Web Interface
Using Microsoft’s EMS - SAC tool can be a daunting task for some Windows administrators who are more comfortable with a graphical interface.
Perle has addressed this issue on its IOLAN Terminal Servers by providing a simple browser-based graphical user interface tool that speeds up system recovery time specifically for Windows Servers administrators. All of the EMS/SAC functions are available to the user such as;
The Perle IOLAN Console Servers also go the extra mile to ensure long term network compatibility and investment protection with support for 10/100/1000 Ethernet networks and full IPv6 compliance.
Available in 1, 2, 4, 8, 16, 24, 32 or 48 ports with RS232/422/485 interface, RJ45, DB9M, DB25M, DB25F connector, 1U high rackmount units with up to a 230Kbps throughout per port, the IOLAN Console Servers offer system administrators additional benefits:
Flexibility of Multiple Connections
High Security features
Making System Administrators’ Job Easier
Keeping Costs Down
“No Break” Feature* for Solaris Platforms
Peace of Mind
Essential Network Connectivity
For more information on Perle’s IOLAN Console Server contact Perle.
Glossary of Terms
A Solaris™ operating environment has a unique feature on the serial management port. If a Solaris Server is powered up without a monitor or keyboard connected, it automatically configures the serial port into a console port. The entire system can be managed from this port.
When the need arises the administrator has the ability to shut the system down to the “Open Boot Prompt” (OBP). The shut down takes the systems down to a engineering level and shuts all other services down. This happens when a ‘break’ signal is sent to the port, which the Solaris Server reads as the command to shut down. Most serial systems such as Terminal Servers (and even serial cards) send a ‘break’ signal when they are powered on and off. This does not pose a problem in an environment where the Terminal Server is deployed to function only as a Terminal Server. However, it is fatal when connected to a Solaris system as a management connectivity solution. This signal will automatically shut down all attached Sun servers. The result is disastrous to any organization whose mission critical applications are running on those servers.
Sun tried to combat the “break” signal problem for organizations deploying Terminal Servers as their primary management connectivity solution by providing configuration patches for Solaris systems. Although these patches do minimize the event of a total network crash from “break” signals, they add additional administration problems for system administrators. In addition, this solution blocks the sending of the ‘break’ signal manually, which an administrator may wish to do, in the event of a hung system, or for other maintenance purposes.