One of the most pervasive shifts in IT has been the transition from hardware mastery to systems management. The demands of deploying and setting up a server have been dwarfed by the need to understand and control that server and its computing resources.
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
There are a range of systems management tools, from simple and limited point tools all the way up to sophisticated frameworks that can ride roughshod over enterprise-scale environments. But selecting the right tool often starts with setting appropriate goals.
Systems management initiatives that encounter roadblocks — or fail entirely — often stumble at the outset because organizations set unrealistic expectations of the tools and their capabilities. Start with a careful consideration of the factors that you need to manage — the information that you absolutely need to know — before evaluating potential management tools.
Potential for vendor lock-in
As a minimum, systems management tools should provide meaningful information for the hardware platforms that you need to manage in a way that enhances productivity for your IT organization. But a single tool may not provide the same suite of information across a number of heterogeneous platforms, especially if the tool is native to a particular vendor’s system. The potential for vendor lock-in with point tools is a serious concern for data center administrators.
Many organizations try to avoid potential lock-in by using several different tools or by selecting a broader more versatile open architecture tool. But using a variety of tools or putting an open architecture operation in place leave an IT shop in an even worse state.
“For every tool you purchase and implement, somebody has to maintain, patch it, configure it, operate it, be trained on it and so on,” said Bob Plankers, technology consultant and blogger for The Lone Sysadmin. “So a tool should help you more than it hurts you.”
Most tools do an adequate job compiling hardware inventories, tracking and monitoring hardware environmental conditions, such as CPU temperatures and fan speeds, and even support common “lights out” capabilities like remote configuration and system reboot. And now virtualization is pushing management tool design forward as vendors strive to integrate with overarching products like VMware Inc.'s vSphere, Plankers said.
But one place where tools can fall short is in the use of Web interfaces, resulting in Java or ActiveX issues.
“Remote consoles are typically some sort of Java runtime-based thing, which puts you at the mercy of the Java runtime version,” said Ian Parker, senior Web services administrator for Thomson Reuters, a business media organization in Ann Arbor, Mich. “You’d like to see a more standardized interface approach.”
Lagging mouse pointers and improperly sized interface dialogs are just two of the most common issues that often ruin the user experience with plug-in Web-based management interfaces, Parker said. That’s why testing and evaluation are essential before making a purchase.
In addition, many systems management tools are designed for Windows environments, leaving many Linux shops to contend with command-line point tools. The availability of Linux-based tools will be important as Linux use becomes more widespread in data centers.
And what about the proverbial “single pane of glass” — that semi-mythical state where a single tool or group of tools can be managed through a ubiquitous interface? Although there are no glaring technological obstacles preventing the “single pane” concept, vendors often use their tools as another method of lock-in rather than as an opportunity for open management between varied systems and tools.
Third-party management tools generally sacrifice detail to gain interoperability. But the importance of hardware interoperability has kept third-party tools relevant in the industry.
“A single pane of glass is neat as long as you have the proper functionality,” Plankers said. “If it’s a choice between a crappy display in a single pane of glass versus a full-featured client run separately, I think people would rather have the full-featured, easier-to-use client.”
The challenges of interoperability between tools and systems can actually impair an organization’s long-term growth — especially as virtualization use takes hold in an enterprise. Tools should go further, showing trends and capacity that administrators need to gather greater insights into their environments.
Identifying the criteria
Once you have established a reasonable set of goals for a systems management tool, it’s time to consider some of the criteria used to select a product. The tool must support the scope of hardware that is in place, but the tool’s roadmap must also be consistent with the hardware roadmap planned for your data center.
If you’re planning a shift to a different server vendor or processor platform or other significant change during the next technology refresh cycle, the management tool should be able to accommodate those changes. If not, you may be faced with a difficult — and expensive — tool upgrade.
Another critical criterion is the tool’s features and functionality. In fact, responses from TechTarget’s 2010 Data Center Survey (see Figure 1) reported that almost 82% of the IT professionals polled considered features and functions as a priority in management tool selection.
At the same time, respondents did not show the same type of interest for extraneous capabilities. For example, a dedicated x86 shop doesn’t need a tool that supports Sparc processors unless it’s part of a long-term technology roadmap.
Figure 1: Primary criteria in selecting systems management tools
And there are other factors as well. More than 51% of respondents cited price as a principal selection criteria. About 22% of the IT professionals surveyed reported that an integrated management suite is important, 18% wanted ease of installation and use, and 15% said that an existing relationship with a vendor was a primary criterion for making a purchase decision.
In any decision, IT administrators must weigh the requirements of prospective tools carefully. For example, most management tools require some sort of a database, but committing to a management tool that demands a four-node SQL cluster may not be the right choice for a small organization that has no expertise with SQL. A management tool with low back-end requirements can make integration and support much easier.
Still another consideration is a review of the tool vendor themselves. A vendor should closely map to other underlying products emerging in the industry and respond quickly to changes. So if Microsoft is planning a new version of System Center or VMwware plans a new version of vSphere, expect a tool vendor to be planning a patch or update immediately following that. A vendor that drags its feet or fails to keep pace with the evolution of underlying platforms risks losing market share.
Third-party tool vs. vendor-specific tool
Choosing between a third-party and vendor-specific management tool can also be a challenge when organizations need to find the right balance of detail or control versus heterogeneity. Generally speaking, vendor tools can provide high levels of detail and can sometimes be acquired with servers for little or no cost.
Homogeneous data centers can typically use the vendor’s tool economically. Heterogeneous environments may opt for a third-party tool that can support a greater scope of products. But those products generally cost more than vendors’ tools, and the level of detail and control is not as deep.
A final thought is the scope of management tools. Management frameworks are highly customizable and can tackle a range of complex tasks that would be almost impossible for point tools.
But frameworks require a serious commitment in terms of investment, time and effort.
“You’re going to have to embrace this application and its way of doing things,” Parker said. “When you’re spending that kind of money on those products, you’re looking to integrate into a workflow.”
The goal is to find use cases where the benefits of a management framework outweigh the challenges involved in handling and managing it.
Upgrading or replacing tools
Even after a systems management tool is selected and deployed, it’s rarely a static entity. Tools are routinely upgraded over time and may need to be replaced outright as an organization’s needs change.
Although the tool may not recognize or support a new server or other device added to the environment, a timely tool upgrade or a new plug-in may accommodate the change easily. Similarly, a patch can fix a software bug or other functional problem.
“Keeping those tools updated should be a no-brainer, but version updates usually comes with features and support for new hardware or software platforms,” Plankers said.
Changing tools can be a more complex endeavor. The new platform must be installed and configured — a process that can take days or even weeks. Once a new platform is working productively, the old tool must be uninstalled along with previous drivers and agents. The biggest challenge when installing new tools is proper configuration.
Many tools are customized—sometimes extensively—and the steps taken to customize a plug-in or tool may be confusing, difficult or even impossible to re-create. This may result in an actual loss of some functionality.
A tool that provides utilities to migrate settings from older versions can make the process go more smoothly. Once again, advance testing in a lab environment can help to identify upgrade problems.
ABOUT THE AUTHOR: Stephen J. Bigelow, Senior Technology Editor in the Data Center and Virtualization Media Group at TechTarget Inc., has more than 20 years of technical writing experience in the PC/technology industry. He holds a bachelor of science in electrical engineering, along with CompTIA A+, Network+, Security+ and Server+ certifications and has written hundreds of articles and more than 15 feature books on computer troubleshooting, including Bigelow’s PC Hardware Desk Reference and Bigelow’s PC Hardware Annoyances. Contact him at firstname.lastname@example.org.
This was first published in February 2012