Developing a Plan for Storage

team lib

Storage provisioning begins with a sound capacity plan to establish a reasonable configuration that supports the business applications and constituency of usersboth end users and data-center users. Thus begins a chicken-and-egg scenario. It also provides the justification for things like beta installations prior to committing new technology platforms like SAN and NAS configurations to production environments.

To calculate and commit to availability metrics, the following guidelines should be considered in establishing a reasonable plan to support SAN or NAS configurations.

Analyzing End- User , Application, and Internal Systems Requirements

  • Develop a method of communications with end users, applications designers and developers, operations, and systems infrastructure colleagues.

  • Define a capacity storage metric and level of precision. This could be capacities in number of bytes with a precision to the nearest megabyte, or it could be a more esoteric work unit such as an application work unit calculated as 1 gigabyte per unit, or a relational database unit such as 1 megabyte per unit. Whatever you use, keep consistent with the metric and level of precision. Keep in mind that you should allow for incongruities in media, which may be reflected in disk and tape densities , sector sizes, and blocking architectures.

  • When collecting storage capacity requirements, remember to calculate both end-user aggregate data and the necessary overhead to support the data. For example, if end-user data for a database is 100GB, then the total data requirement will be 100GB plus the necessary overhead of database system, index, and temporary tables. Depending on the type of application, this could go as high as 50 percent of the aggregate user data storage requirement, rendering our example to 150GB required for current database physical storage. Other application systems such as e-mail, ERP, and CRM all have additional storage overhead requirements that are important to consider along with the aggregate user data.

Planning and Establishing Adequate Capacity Based Upon I/O Workload Estimates

  • An important consideration to storage capacity is the processing requirements that together with capacity requirements drive the configuration elements necessary to meet end-user demand. In order to accurately estimate these requirements, its necessary to translate user requirements into I/O workload estimates (see Chapter 17).

  • Using I/O workload identification recommendations (again, see Chapter 17) the application workload types begin to distinguish themselves . Consider size versus access as the applications demonstrate their workload characteristics such as OLTP, batch, messaging, and combinations of these. The size factor, as depicted in our discussion about capacity, must be considered along with the calculation of the I/O workload factors. This allows for the initial elements of the configuration to start to take shape.

  • Recovery factors also influence the configuration elements. My I/O workload guidelines provide a recovery factor for calculating the configuration elements (see Chapter 17). However, this calculation should reflect the necessary insurance required for particular data-center business continuity requirements (see Chapter 21).

  • Although a subset of recovery, the redundancy factor must not only be taken into account for recovery factors, but also for security and individual failover. Largely driven by system failover requirements, the redundancy in both NAS and SAN can be implemented within themselves, and thus can be a substantial factor in configuring redundant systems. Therefore, they should be considered as separate items even though theyre related to recovery and business continuity at a macro level.

Establishing an External Capacity Driver Matrix

  • Application requirements drive most of the capacity requirements; however, they provide little if any insight into the storage configuration to support the business application. By developing an external capacity driver, you have identified the major influences that drive both capacity and performance.

  • System requirements drive the rest of the capacity requirements with overhead to OS, subsystems, and network requirements. However, these spheres of technology also exert influence on the configuration they feel are most appropriate to the processing of the business applications. By developing the external capacity driver, you have also identified the influences on the storage infrastructure.

Establishing a Reporting Mechanism

  • Once the end user, application, and systems requirements are translated and calculated into requirements for a storage configuration, develop a reporting mechanism on the activity of their storage usage. The system must be able to be as proactive as possible in order to show trends that are outside the requirements, and to compare them against the storage capacity plan.

Managing to Storage Capacity Plans and Established Service Levels

  • The establishment of the reporting mechanism begins the management of the plan. Given the translation of requirements to real storage resources, the users must be held accountable for their estimates. However, given the volatility of the technologies and the changes in business climates, things will change. Therefore, its important to also establish an effective communication system track requirements to actual usage without retribution (see establishing a non-aggression pact).

  • The User Non-Aggression Pact: It is always helpful to reach an agreement with a user community that accounts for the unexpected. This allows both parties to agree that the unexpected does happen, and should it occur, it should be resolved with both mutual understanding and changes to the existing plan. This can be critical given the volatility of SAN installations and NAS data volume requirements.

    • Unexpected Requirements The most common set of unexpected circumstances is the unforeseen application that requires support but which has not been planned for. In terms of affecting the SAN installation, this can be costly as well as disruptive, given the scope of the new application storage requirements. Within the NAS environment, this is one of the strengths NAS brings to the data center. If the requirements can be handled through file access, NAS performance, and capacities, then the NAS solution can be used effectively during these circumstances.

    • Unforeseen Technology Enhancements This is the most common circumstance when initial SAN design proves insufficient to handle the workload. The outcome of retrofitting the SAN configuration with enhanced components is additional cost and disruption.

    • Mid- term Corrections Its likely that any enterprise storage installation will experience either one or both of the preceding conditions. Consequently, its extremely important to build into the user agreements the ability to provide mid-term corrections that are an evaluation of the current services and corrections to requirements in order to continue to meet the committed services.

team lib

Storage Networks
Storage Networks: The Complete Reference
ISBN: 0072224762
EAN: 2147483647
Year: 2003
Pages: 192 © 2008-2017.
If you may any questions please contact us: