4 things every storage admin should know

The evolution of tech is all about replacing manual tasks with automation, which enables you to perform tasks that were impossible or impractical before. You’re suddenly freed from mind-numbing manual configuration — only to face a fresh load of complexity, as you confront shiny new buttons to push.

That’s what has happened to storage. Today we have a vast array of options for host-to-storage connectivity — each with their own pro/con list and constantly changing best practices — and an equally wide number of on-array performance and capacity optimization software features. While deploying new storage may take a fraction of the time, knowing how best to deploy it in the first place often requires a lot more thought.

To get the most out of modern enterprise storage, at a minimum you need to stay on top of four areas: monitoring, benchmarking, application characteristics, and a shortlist of general best practices. Some of them are as old as storage itself, while others come courtesy of the increasing complexity to be found in modern enterprise storage tech.

Monitoring The No. 1 item any storage admin absolutely needs to know is how to monitor storage. Monitoring both capacity and performance will allow you to foresee impending problems before they rise to the level that anyone will notice — and give you a chance to make necessary configuration changes or put more hardware on order before it’s too late. Likewise, monitoring also gives you the data to determine whether or not storage is the cause of an application performance problem.

Most enterprise storage hardware ships with comprehensive monitoring capability, but simply having it set up and running isn’t enough. You need to know what you’re looking at. Understanding the relationships between throughput, transactional load, transaction size, and read/write mix is critical — so you can stop problems before you need to diagnose them.

Benchmarking Benchmarking is the only way to get a feel for a planned workload and determine how the storage you’re deploying to meet that load will hold up. That might involve learning to use general storage performance-testing tools like IOMeter, as well as application-specific tools such as JetStress and SQLIO.

Experimenting with benchmarking tools will also give you a much better understanding of how to interpret storage array monitoring data. By creating loads of varying characteristics and observing the impact on your storage, you can also concretely evaluate the impact of various array-side configuration changes.

Knowing your applications Storage admins can’t afford to ignore the application layer. For example, database workloads are among the most demanding you’ll encounter. Recently I was faced with a mission-critical database application that had chronic performance issues. At first glance, the problem seemed to be entirely storage-based, with much of the database engine’s time spent waiting for storage to cough up data — but closer examination uncovered design deficiencies within the database itself. Adding a few indices to the database schema to service several frequently used queries cut the storage load by more than 50 percent, and expensive changes to the storage hardware were completely avoided.

Storage admins don’t need to become DBAs or experts in any other type of application. But sooner or later, ignorance of application storage characteristics will cost you. At the very least, before you throw hardware at the problem, have a serious talk with the apps guys to find out how the application in question uses storage.

Staying on top of best practices Believe it or not, among the multitude of ways to configure hosts and storage to work together, there is almost always a right way to do things. Unfortunately, best practices vary widely depending on what you’re trying to achieve. This goes double for implementing storage in virtualized environments, especially in situations where your storage supports more than one storage protocol and/or where you’re replicating storage to a remote site for failover.

For example, let’s say your storage platform supports NFS, iSCSI, and Fibre Channel or FCoE and you’re attaching to virtualization hosts that can also support all three of those protocols. Which do you use? Is there an advantage to mixing and matching for different workloads? Will one type of workload benefit from running on a capacity-efficient file-level protocol, while another might benefit from running on a block-level protocol? Will configuring a certain application with a block-level protocol allow you to use application-aware snapshotting software from your storage vendor while a file-level protocol may not?

If you’re replicating to a remote site, will the choice of block- vs. file-level protocols have an impact on your ability to fail over or fail back? Are there caveats in the version of the hypervisor, replication software, SAN firmware, or failover automation software that would make one better than another?

It can take a lot of research to figure out the right answers to these questions and set everything up in the most bulletproof way possible. Worse, once you do, a version upgrade of any single component may suddenly change the answer or simply break something. That makes finding accurate sources of information very important — whether from documentation or human experts.

Becoming a storage ninja Thriving as a storage administrator in the modern data center requires a wide array of skills. Not only must you know how your storage works inside and out, but also how it integrates with the hardware and software. That’s why today’s storage administrators are discovering they need to diversify their skill sets to encompass more of what’s happening in the rest of the data center.

This article, “4 things every storage admin should know,” originally appeared at InfoWorld.com. Read more of Matt Prigge’s Information Overload blog and follow the latest developments in storage at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.