In a perfect world, every server in the enterprise would run with optimum efficiency and could be reconfigured to accommodate moves, adds, and changes at the drop of hat. Needless to say, the world of servers doesn't work like that. Such efficiencies oftentimes are not possible or can be the least attractive option.
The job of loading servers (and server-based software) and of tuning servers to run properly is the task of remote server configuration software. This is a loose category, and products vary widely in functionality and feature set. They cover tasks as diverse as software change management, license management, inventory control, and performance monitoring. Moreover, this working definition does not include remote client configuration (desktop or mobile), although this is sometimes part of the feature package for this type of software.
The job of configuring a large number of servers can be daunting. There are three main steps:
- Deployment and installation of software be it new, an update, or a fix (occasionally, this step is not part of the process)
- The actual configuration of the server settings, rules, levels, and actions for events
- Testing of changes to ensure they actually work
The obvious benefit of configuration management software derives from centralization and remote management. It rids an administrator (or small army of administrators) of the need to physically visit each server requiring configuration. It also makes it possible to synchronize at levels difficult to achieve manually. An important secondary benefit is the automatic logs that record what was done, when, by whom, and to what.
The conditions for failure in configuration management are greater because it is 1) an active form of management that is actually doing things to a server and its software, and 2) it usually involves making critical, simultaneous, and often sequential changes.
Deployment, configuration, and testing on remote equipment is rather tricky. Configuration processes have more places where things can go awry than other server management areas. For example, a server may be down or unplugged from the network, a piece of software that works on one server may not even start on another server, or a change that takes place on all servers from one manufacturer could fail to take place on machines from another manufacturer. The conditions for failure in configuration management are greater because it is 1) an active form of management that is actually doing things to a server and its software, and 2) it usually involves making critical, simultaneous, and often sequential changes.
The moral of this story is that although configuration management promises substantial and immediate benefits, such products are among the most difficult to choose and implement. Perhaps because it is difficult to do everything well, products in this category are often very targeted. There are configuration managers for specific operating systems, specific types of applications (most commonly database), and for specific hardware.
As is always the case with server infrastructure software, suites (e.g., IBM Tivoli or Netopia netOctopus) often include server (and server-based software) configuration tools. Although the suites are usually more general in their approach, there is currently is no such thing as a universal configuration manager. Thus, when choosing this kind of software, there is often a trade-off between the range of possible configurations and the software needed fulfill the functionality.
To illustrate this, the ServerWatch Functionality Matrix for Configuration Tools provided below is one where rather than checking and comparing two or three products that compete across many of the features, enterprises will more likely be selecting from a grid of products that complement each other on the features provided.
|Product 1||Product 2||Product 3|
|Server Architecture||Cluster Support|
|User-Defined Server Groups|
|Homogeneous Platform Deployment|
|Configuration Types Supported||Operating System|
|Application Servers (Middleware)|
|- If Yes, Indicate Whether on All Servers or Specified Servers|
|Links to Asset/Inventory Management|
|Mass Migration Support|
|Enterprise Directory Support|
|Server Configuration Testing||Testing Suite|
|Links to Monitoring Software|
|Change Management||Version Changes|
|Administrative Session Logs|
An often overlooked aspect of configuration management is that it must work with and sometimes around system security measures. The presence of firewalls, port sniffers, spyware and antivirus software, and even things like unexpected password changes, can interrupt or derail a multiserver configuration process. Therefore, features in configuration management software that help with security issues should be paramount.
Once a change is deployed and configured, it should be part of the routine to ensure the changes are working and delivering the expected improvements. This usually involves analyzing logs, event reports, and performance tests. Some configuration management software includes testing capabilities, although the minimum should be support for third-party testing and performance monitoring.
When done, it's crucial to set standards for a "successful" configuration and measure the results against those standards.
Coincidentally, note that "rollback" is not a common feature in this type of software. These products assume that the organization unleashing a new configuration on, for example, 1,000 servers, has tested those changes before doing so. To paraphrase an old adage, the chain of configuration is no stronger than its weakest link.