By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
| They may not be as slick as GUIs, but CLIs are powerful and flexible tools for managing storage.
command-line interfaces (CLIs) are often considered a necessary evil in a lot of storage management environments. But it's not surprising to find storage teams using GUI tools for end-to-end management of their environment. When asked about the use of CLI, those same users often refer to it as a complex, counterproductive interface best left to the "pros who need it."
Thanks to the advance of Java and faster computers, there seems to be a natural gravitation toward the use of GUI or Web-based tools to manage storage and SAN devices. It's easier to like something that has pretty pictures than something that's mundane, tedious and, even worse, requires opening a command-line window.
But administrators aren't doing themselves any favors by distancing themselves from CLIs. When you examine the potential benefits CLI tools offer, they quickly become compelling.
While command-line tools may have their roots in Unix environments, they've come a long way and can be used in the same manner on multiple platforms, including Microsoft Windows. Vendors take pride in advertising the platform-neutral aspects of their tools, and much credit goes to their efforts in making sure that no matter which platform you prefer, the experience stays the same. What does vary is the installation location for these tools. Vendors may choose to create a directory or folder that's specific to their product or toolset rather than install them in a common directory or folder. These variations can generally be minimized by tweaking or customizing the installer packages wherever possible. This is more of a software discipline than a CLI-specific issue. Here are some good reasons to take a closer look at CLI.
CLI can be managed without draining resources. Like any software, command-line software can be good or bad. But to say that all command-line software is complicated is like saying all Web interfaces are the same. I agree that remembering various commands, flags and options can become a bit difficult. However, that learning curve is the same when you adapt to any new tool or utility. Most vendors have recognized this and restrict the number of commands and flags. Most of them also support quick help where you can get help on all of the flags, options and, in some cases, quick examples. Unlike some Java-based tools that can drain precious CPU and memory cycles from your laptop or desktop computer, CLI tools generally function in a lightweight environment. Whether you run it locally on your desktop, on a server or even on the device itself, these tools don't consume a lot of precious resources. That makes CLI a very viable option for remote execution via a VPN, slow links and even dial-up connections.
The power of shell. What command-line tools do give you is the power of a shell. Even a company such as Microsoft (which pioneered an all-GUI approach to an operating platform) has acknowledged the power of a user shell interface. Unix and Linux administrators will gladly tell you how powerful a shell environment can be for executing storage and systems tasks. For one, a shell means regular expression search. The output produced by a command can be captured in a log file or buffer and then processed using utilities such as sed, awk, grep and so on to produce a formatted output of relevant data points. On the same note, one can capture the results of executing commands.
Then consider scripting. The term "shell scripting" says it all. There's a plethora of shell scripting environments, including structured languages such as Perl, that can be used to run a command or set of commands against one or multiple devices, aggregate and process the output, and then use that output to execute a follow-on set of commands. This is of immense value for a variety of reasons. It allows easier integration with third-party applications such as backup and recovery software, databases, virtual machines (like VMware) and other applications that need to interact with storage and SAN environments. Also, scripts can be run at regular intervals from a scheduler such as cron without any additional overhead. Cron is generally available in all Unix variants and is accepted as a robust way of scheduling tasks in Unix variants. In addition, scripts can be used to create raw data files that are later fed into data processing software such as Excel to create dashboard-focused metrics such as pie charts, graphs and so on. Finally, scripts can be used to email the output of the execution or its status to users, notifying them of the operation's success or failure.
Shells also help with role-based access. By using programs such as "sudo" and RBAC-capable shells, you can easily allow multiple storage administrators to execute the same scripts while logging the tasks executed by each user. This is immensely helpful in secure environments that undergo regular audits. Indeed, command-line tools can play a variety of watchdog roles. Take daemons and logging. By running commands through scripts as daemons or processes, command-line tools can monitor and log activities to a central reporting server. If this task is performed through a GUI-based tool, it generally requires the use of a dedicated server to accomplish the same task.
What's your vendor's strategy?
There are two basic kinds of CLI tools: in-band and out-of-band. In-band generally means that you communicate using a serial or Fibre Channel interface directly to the device in question. Out-of-band generally means you connect to the device over a network of some kind (an IP network in most cases). This is if the device has a network interface, can be configured with an address, and can be accessed via an Ethernet or IP network. In each case, the CLI can be "off-host" or "on-host." On-host means that no matter how you connect to the device (in-band or out-of-band), the command-line tools run on the device itself. Off-host generally means that you run the tools on another box (a bastion host, for example) and the tools use an access mechanism to connect to the device. Access mechanisms can be an API, a network port, a SCSI pass-through device and so on. When deploying on-host, the execution environment is created on the device itself; as a result, the limitations of that environment come with it. In the case of an off-host environment, you create the environment on the platform where you choose to run the tools. For example, a vendor may decide to make its tools available on Unix, Linux and Windows platforms. If you install them on Unix or Linux, you can use Bourne or Korn shells to create scripts, use Perl and then run them through cron. If you install them on Windows, you may have to create Visual Basic or Perl scripts and then run them through Windows Task Scheduler.
Most switch vendors (like Brocade and Cisco Systems) provide an "on-host" CLI environment for their devices. This can be accessed via in-band or out-of-band mechanisms such as serial RS-232 ports, Telnet or SSH. Storage array vendors have different strategies. EMC, for example, uses in-band, off-host for its DMX arrays using its "Solutions Enabler" tool suite. For its Clariion line, it uses an out-of-band, off-host package called Navisphere CLI. NetApp's simplicity and ease of management for its filers was made famous by its on-host, in-band or out-of-band CLI toolset. On the other hand, EMC uses a Linux-based control station (that's an off-host, out-of-band mechanism) to manage its Celerra environment. Until recently, Hitachi Data Systems didn't have any CLI tools available to manage its enterprise arrays. It now provides CLI tools as a part of its Hitachi HiCommand Suite. It does, however, have a CLI package that's off-host, out-of-band for its modular arrays.
If you have a mixed-vendor environment, using various CLI tools with their wide syntactical variations may pose a challenge. For homogeneous environments, however, they can provide some very compelling economies of scale.
At the end of the day, I'm not making a case to get rid of GUI tools and replace them with an all-CLI approach. But seeing CLI in a whole new light can help you in ways you might not have imagined.