My favorite way of thinking about data management is to focus on how storage administrators spend their time. If you are a storage admin, then all day long you respond to requests from people who want more storage, or want you to make some change to their storage. Sometimes they telephone and sometimes they e-mail, but the requests are always the same: "I'm installing a new Exchange server and I need a one terabyte LUN." "I've got a one terabyte LUN, and I need you to grow it to two terabytes." "I need a copy of my primary database so that I can experiment with a new app that I'm developing." What a bunch of busy work! (Some people call this the "storage help desk".)
Think about this from the application administrator's point of view. They can't do their job until the storage admin gets back to them. It reminds me of how people used to get cash at the bank, before Automatic Teller Machines were invented. You would wait in a long line and eventually talk with a live person who handed you your money. What a pain! ATM machines are better for everyone. Less work for the bank, but also better for me as a customer. I don't have to drive to the bank, and I don't have to wait for the bank to open. I can get my money at 3am in a liquor store.
NetApp's goal is to do the same for data management—to let application administrators manage data themselves, without any help from the storage administrator. Of course, storage administrators will never allow this unless they retain control. Let's return to the ATM analogy. When you walk up to the ATM, you should be under no illusion about who is in control of how much cash you can take. The bank is in control, it's just that they control your withdrawals through policies that are programmed into the system. Likewise, the storage administrator will never let application admins directly manage their data, unless there are policies to let the storage administrator maintain control.
This isn't just future vision. As of today, server administrators can do self-service storage provisioning without contacting the storage admin. In addition, we have products that allow application administrators to control snapshots, trigger remote copies for disaster recovery, recover lost data from snapshots or backups, and even create clones for test and development.
Here's an example that shows the extent of our application integration. Suppose an Exchange database gets corrupted. That happens sometimes. With most storage systems, the Exchange administrator would need to work closely with the backup admin, who in turn would need to work with the storage storage admin to keep restoring old versions of the database until they find one that's valid, then restore the valid one, replay the logs, and restart Exchange. SnapManager for Exchange lets the Exchange admin do it all himself, all automatically. Or if you just want to restore a single mailbox, it can do that. The SnapManager tools for Oracle and SQL Server have similar capabilities.
Never mind the details. Here is the big picture.
We are giving application administrators self-service access to a whole variety of data management services, and we're doing it in a way that gives storage administrators enough control to keep them happy as well. Data administrators can get what they need right away, without hunting down and waiting for a storage administrator. Storage administrators can stop wasting time on a steady stream of individual requests, and focus on the stuff that matters—stuff like storage optimization, business continuance, and performance management. Who knows, maybe they can even introduce themselves to their children.
Bookmark/Search this post with:
[5] | [6] | [7] | [8] | [9] | [10] | [11] | [12] | [13]