This article can also be found in the Premium Editorial Download "Storage magazine: A look inside Hitachi's TagmaStor high-end arrays."
Download it now to read this article plus other related content.
Application owners often complain about the time the storage group needs to respond to requests for additional storage. Users may overstate storage requirements to ensure that their actual and potential needs are met. One dramatic example is a financial firm where 5TB of tier-1 storage was allocated for a data warehouse that was currently using less than 100GB. The allocation was based on projected capacity needs three years out!
Provisioning goes beyond carving out disk space and creating and presenting LUNs. It's a multilevel process that requires well-defined procedures. (See "
Let's examine some of the prerequisites for an effective provisioning operation.
Classes of service. The first prerequisite is a clear definition of each service level's attributes to provide a foundation of common understanding between business units and the storage group. Ideally, class of service is backed by a financial model, so business units can choose service levels that match their business needs. Defining a class of service is more than specifying a type of primary storage--other attributes may include availability, performance, scalability, backup, recovery, archiving, disaster recovery (DR) and security.
The request process. How business units request storage provisioning must be a documented process subject to organizational policy with explicit expectations of service. The procedure should define workflow and authorization along with performance metrics and completion artifacts.
Document the environment. Provisioning depends on discovering and measuring asset utilization of the entire environment. This includes arrays and controllers, storage network components, tape subsystems, media and management servers, links for replication and recovery site storage. This also includes documenting host initiators, multiple data paths, switches, routers, fan-out/fan-in ratios, interswitch linking, management LANs and associated firewalls, array controllers, etc.
Understanding capacity. Provisioning doesn't stop at primary storage. When a gigabyte is requested, five to 30 times that amount will be needed in secondary storage, depending on backup and archiving requirements. This may affect network traffic to backup servers, servers' processing loads and tape subsystems.
DR, particularly for top-tier applications, may mean additional requirements. The requested storage and its data change rate can affect synchronous and semi-synchronous links and may require storage at the recovery site.
Determine utilization. Another prerequisite is knowing the capacity that's actually available. This isn't just the storage requested, but also the fabric consequences of adding primary storage. Traffic, dual paths and fan-in/fan-out ratios can all be affected by provisioning new storage. Utilization must be carefully defined; databases and volume managers grab chunks of space that appear to be used, but aren't fully utilized.
Interoperability and standards. A number of standards have to be in place. To some extent, standards are required because heterogeneous storage and SANs aren't fully interoperable. They're also required to identify default LUN size and for mapping initiators to LUNs to protect the fabric's integrity. Depending on class of service, standards are required for dual-path capability, acceptable fan-out/fan-in ratios, use of interswitch links and port connectivity on the array.
This was first published in September 2004