| |||
|
|
||
|
|||
| |
|
Home > Self-service storage -- do-it-yourself provisioning gains ground |
| |
|
|
|
|
| Feature: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
Self-service storage allows the storage administrator to take advantage of all the capabilities of virtualized storage and respond to user needs for storage volumes more rapidly than ever, while not being burdened with the eventual outcome of easy storage distribution or virtual volume sprawl. Virtual domains provide the ability to push down the day-to-day administration of storage volumes, increase the security of the storage environment and leverage all the capabilities of the storage arrays across all of those domains.
One of the biggest burdens for storage administrators today is provisioning storage. The amount of time it takes to get storage provisioned to an application continues to grow, with wait times of 30 days and longer becoming more common. Provisioning storage on most systems is complicated, although less complicated than a few years ago, when making changes on some systems required professional services! The act of provisioning storage today is driven by the storage administrator. In addition, companies like 3PAR, Compellent Technologies and LeftHand Networks are making the process even easier through the use of virtualized storage systems. Through a capability called thin provisioning, companies like these have made the process of assigning storage simpler. A storage administrator can now create a volume and assign it without going through the complex process of determining how much storage the requesting application will require. The storage can be provisioned and capacity assigned on-the-fly as needed.
A virtualized storage system makes these choices easier and even obviates the need for some of them. For instance, in a virtualized system, RAID 6, which protects against prolonged RAID rebuild times of large drives, may not be necessary. Virtualized arrays will scatter data blocks across all available drives, so when a rebuild is needed, many more drives participate in the process. This will reduce rebuild times. Virtualizing storage is a critical step in rapid storage deployment because it breaks the monolithic model of large (and even modular) storage arrays. Virtualization also allows volumes to be created across all the available storage resources, by aggregating "virtual array" workloads across all physical components (controllers, cache, drives, etc.). The advent of virtual storage has not resulted in a ballooning of storage volumes. Built-in technologies such as automatic wide striping and thin provisioning result in fewer and larger volumes, as opposed to traditional volumes which much be grown or added to, or concatenated. All this technology makes the job of storage administrators easier and helps them respond quickly when a user needs additional storage capacity. However, storage administrators are still very much in the loop for every provisioning activity. Not only are they involved in the process, they are the process. This effect is similar to the hypervisor technology used by server virtualization solutions in that they provision server-processing power but the server administrator still has to create the particular server instances. In short, even though storage provisioning tools are becoming more automated, a human storage administrator is still required. And that human is usually the bottleneck.
Self-service storage needed Like hypervisors, virtual domains provide a level of separation and safety between server instances but add the ability for these storage partitions to be subdivided and the management of them to be delegated. In a hypervisor, this would be like assigning a certain amount of processing capacity to a business unit and then letting the business unit create and manage any number of servers within that capacity limitation. A secure and simple process is needed to make virtual domains effective. With virtual domains, a master storage administrator assigns a virtual "slice" of storage (a "virtual array") to a community (a department, line of business or application group) in the organization. This could be an IT manager for a particular line of business or even just a sub-group within the IT infrastructure, such as the Exchange group. The master administrator can pool these users from a simple LDAP directory. The user creates the logical elements within the domain (capacity limits, QoS level(s), assigned hosts, etc.). Once the users of this domain are assigned, they can manage and provision the storage among their group without interfering with other departments' or applications' storage. In fact, they don't even see that the other storage exists, reporting is just on their domain. Without the abilities of self-service storage, the only choices are array partitioning or dedicating entire array systems on a application-by-application basis. Array partitions, often called storage domains, essentially hard-zones an array. While an administrator can be assigned to each partition and a master administrator can oversee the entire array, no further granularity is available. Since these traditional platforms are not highly virtualized, their inherent complexity means that turning over a partition to a user doesn't make provisioning from that partition simple enough for "self-serve." Furthermore, the domains do not leverage all the components of the array; some partitions can become bandwidth-starved, while others have extra bandwidth. Reassigning resources within these partitions is as difficult to redeploying resources within two physically separate arrays. This hard-zoning of the resources within the array also limits the amount of storage available.
About the author: George Crump is founder of Storage Switzerland, an analyst firm focused on the virtualization and storage marketplaces. It provides strategic consulting and analysis to storage users, suppliers, and integrators. An industry veteran of more than 25 years, Crump has held engineering and executive management positions at various IT industry manufacturers and integrators. Prior to Storage Switzerland, he was CTO at one of the nation's largest integrators.
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|||||||||||||||||||||||||
|
|||||||||||||||||||||||||||
| |||||||||||||||||||||||||||
|
|
|
|||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
