This article is about designing a tiered storage solution for final implementation. It is written for IT executives responsible for storage infrastructure, IT professionals involved in infrastructure planning and design, finance professionals concerned about IT, and IT architects interested in storage infrastructure.
The article is a practical guide to performing a storage design and is organized as follows:
- What is a tiered storage design?
- How does a tiered storage design process work?
- What is the impact of using a tiered storage design plan?
- How to develop a tiered storage design plan
Designing tiered storage is a low to medium risk project requiring between 400-600 person hours. The degree of certainty over the final design is assessed as moderate, as it cannot be tested as a working system.
In general, tiered storage technologies, software, processes and procedures are still immature. The industry has yet to define a common definition of tiered storage. As well, the current storage management software that monitors service level agreements at the application level can best be described as inadequate.
A design project for tiered storage is likely to confirm that a full implementation will have a good business case (ROI and IRR>150%), while the IT only business case is likely to be deemed acceptable (ROI & IRR ~100%). In addition, organizations should align spending on storage services with the business value of supported applications.
The major risks to a tiered storage design project are the difficulty deciding the number of tiers, designing the service level capabilities for each tier, being able to analyze storage on an application basis, and getting the user community to accept change. The following factors will improve the opportunity of success:
- Storage virtualization has been planned and/or implemented
- IT is held in good regard by the user community
- Application service level agreements are in place
- The primary storage vendors for the storage pools analyzed have solid tiered storage offerings
- An experienced tiered storage designer has been identified and committed to the project
- An effective sponsor of the project is identified.
Tiered storage refers to the assignment of different types of storage media based on application requirements. Storage types (or classes) allocated are based on many factors including the level of protection needed, performance required, speed of recovery required, availability needs and many other considerations. A fuller definition can be found at Tiered storage.
Tiered storage has the potential to significantly reduce the costs of storage in many environments by allocating more expensive storage to those applications requiring robustness and less expensive storage to less mission-critical applications. As application requirements or data characteristics change, data can be migrated to different tiers optimizing storage efficiencies.
Tiered storage is likely to have initial costs of software to manage the environment, the cost of implementation, and possibly write-down costs for hardware that will no longer be used.
What is a tiered storage design?
A good tiered storage design provides a well defined, distinctive, and manageable number of tiers that allows applications to choose the level of storage service appropriate to their business needs. The number of tiers should probably be between 4 and 8, and unlikely to be less than 2 or greater than 10. The services, availability, and performance of each tier are distinctive, and fit the major applications in the organization well. The costs of each tier are also clearly defined, distinctive, and offer a clear incentive for users to save money by choosing lower cost storage when appropriate.
A tiered storage design should take a period of months to complete, with ongoing and periodic improvements to the plan as warranted. Specifically, the design should be updated as the tiered storage effort moves from the design phase to subsequent phases, including build, implement, operate and exit.
A tiered storage design has three major components to it:
- Deciding the number of tiers that should be included-- the more tiers the more granularity but also the more complexity
- Deciding the capability of each tier to that it allows key applications to align the cost of storage with the functionality of storage required
- Ensuring sign off from the departments that own and use the applications for any changes in storage provisioning, and agreement from IT to invest in the next stage of a tiered storage strategy.
Tools and technology dependencies
There are a number of useful tools that can be helpful in constructing a tiered storage design, including:
- Infrastructure assessment tools specific to tiered storage - these may include vendor tools, in-house design tools, risk assessment frameworks, disaster planning checklists and other diagnostics useful to the constructing the design
- Graphics tools to construct and communicate the design
- Project management and other collaborative tools
- Infrastructure and application 'agents' to identify and locate assets
- Storage management tools that can identify the resources used by applications together with the storage service levels delivered to the applications
- Evaluation tools that help determine the business impact on an application when storage service levels are increased or decreased.
Key skills needed to perform a successful tiered storage design include:
- Staff knowledgeable about storage infrastructure
- A financial professional to ensure financial best practice and adherence to organizational prerequisites
- An interface to and/or direct participation from application owners
- Vendor input or in-house expertise to provide different design options for the proposed solution
Often, organizations will solicit assistance from outside consultants to perform design work, drawing on best practice industry expertise.
As with most projects, a tiered storage design should include champions empowered to marshal the resources necessary to complete an assessment. Access to reasonably accurate financial/cost data, configuration data and proposed costs by application are compulsory. It is important to stress that the tiered storage design is iterative and should be approached in a manner that provides an initial 'first pass' view that can be made more granular, detailed and accurate over time, as acceptance of the concepts is achieved by the users and IT.
Key stakeholders including storage staff, enterprise architects, financial representatives and application owners should provide input to the process in order to ensure its adoption and backing. An executive sponsor might include a Chief Technical Officer (CTO) at a larger organization or CIO in smaller settings.
What is the impact of designing tiered storage?
A detailed and well documented design increases the chances of a successful project by specifying the design prior to build and implementation. This allows key issues to be resolved in plenty of time to perform proper research and build consensus. A tiered storage design provides the foundation for building and implementing tiered storage and helps reduce rework and errors.
A tiered storage design also sets clear and measurable output into the build and implementation phases of an overall tiered storage strategy.
How to develop a tiered storage design
A tiered storage design starts with a planning phase that involves:
- Establishing goals
- Sizing the work effort
- Drafting work plans
- Setting time scales
- Budgeting resources
The key goals of a tiered storage design project include:
- Construct a tiered storage blueprint that reflects the benefits and costs articulated in the business case, specifically related to dollars of cost savings, percent productivity improved, percent speed improved, percent improvement in client satisfaction.
- Provide a roadmap to the build team that can be executed with ease as measured by time to build.
- Confirm/deny/adjust any assumptions made in the assessment phase of the lifecycle, including the cost of the project and likely benefits.
- Resolve foreseen conflicts and rationalize tradeoffs prior to the build and implement phases.
Sizing the effort
The scope and size of a tiered storage design will generally depend on five key factors, including:
- Size and diversity of infrastructure targeted for tiered storage
- Diversity of applications and supporting storage pools
- Degree of decentralization (i.e. the number of storage pools being consolidated into tiered storage)
- Complexity of environment (e.g. workloads, disaster recovery services, copy services, etc.)
- Desired level of depth and accuracy of the design.
Drafting work plans
The main tasks individuals perform during a tiered storage design include the following:
- Determine the number of storage tiers required
- Define the characteristics of the storage, storage management and other storage services required for each tier, and the storage service levels that can be achieved
- Allocate each of the major applications to the appropriate tier
- Agree a cost structure and charge-back mechanism for each of the tiers
- Create an outline specification of the key processes and procedures required to create the tiers, migrate the data to the tiers, manage the tiers, and migrate data between the tiers.
- Update the business case with more accurate costs and benefits as a result of the design
- Obtain agreement from the departments that fund and use the applications to the storage tiers and storage service levels
- Communicate and obtain feedback on the tiered storage design
- Document the design, the trade-offs that drove key decisions in the design and the expected processes and procedures so that the build, implement, and operate phases of the project can be accomplished.
- Obtain final communication & sign-off from the stakeholders
Setting time frames
Generally, a credible design can be achieved in an elapsed time of fifteen weeks.
This design section assumes that the following data has already been established:
- Analyzing the need for tiered storage has been completed.
- An analysis of the impact of outages and disasters has been completed, and the required RTO & RPO metrics for the major applications have been agreed (or compliance mandates known).
- The business cost of an outage for the major applications has been established ($/hour).
- The expected annual cost of a disaster taking out the major applications for an extended period of time has been established.
- Compliance and data retention policies for the major applications have been established and documented.
The following rough schedule can be used as a guideline:
- Week 1: Kickoff meeting with stakeholders
- Weeks 2-3: Collect and review data on current environment (and make assumptions if necessary)
- Weeks 3-4: Establish the number of storage tiers required
- Weeks 4-5: Establish the technical and SLA specifications for each tier
- Weeks 5-6: Allocate applications to an appropriate tier
- Weeks 6-8: Obtain agreement from the departments that fund and use the applications to the storage tiers and Storage Service levels
- Weeks 7-9: Create an outline specification of the key processes and procedures
- Weeks 9-10: Update the business case
- Weeks 11: Communicate and obtain feedback on the tiered storage design
- Weeks 11-12 Incorporate feedback and refine design
- Weeks 12-14 Fully document the design
- Weeks 15: Final communication & sign-off from the stakeholders
Generally, a tiered storage design can be constructed by a project lead and a team of a few individuals committed to the process. The team will likely consist of the following individuals:
- An executive sponsor
- A project lead
- One to two individuals with current infrastructure expertise and general knowledge about application requirements
- An IT person experienced in designing tiered storage
- Application or line of business staff with the authority to establish storage service levels
In general the development of a typical tiered storage design will consume between 400-600 person hours to complete. An outside consultant will typically charge between $40,000 - $60,000 to construct a complete tiered storage design. The following can serve as guidelines of the amount of time required by key participants and other expenses.
- Kickoff meeting prep - Project lead 1 day + 1 hour review with sponsor
- Kickoff meeting - 1 - 1.5 hours for project lead, infrastructure manager, application manager, design analyst, and line-of-business manager.
- Data collection & data review: Series of one hour meetings with design analyst and one to two individuals knowledgeable about infrastructure requirements, application requirements and recovery/disaster recovery requirements/justification.
- One week - construct basic tiered storage design for number of tiers
- Three days – define tiered storage service levels for each level
- One week - allocate applications to storage levels and agree with departments
- One week - Create an outline specification of the key processes and procedures
- Two days - update the business case
- One to 4 hours to present design to the team and capture comments
- One half day to revise assumptions, incorporate feedback
- Two days to construct final report / presentation to management committee
- One hour to present design to leadership team
- Four days to fully document design, assumptions, revised business case and procedures
- One half day per quarter throughout the project to realign the design based on the build, implementation and operations feedback
If the outage and compliance data is not available, allow additional time in the schedule to perform either a complete analysis of these areas, or establish assumptions about each of the required metrics.
This section details the activities related to preparing for the design. Main activities include:
- Choosing the lead
- Selecting the team
- Delegating authorities
- Negotiating work plans
- Delegating work
- Installing escalation channels
- Establishing performance incentives
- Releasing resources
Choosing the lead
The main activities managed by the team lead include setting goals, scheduling resources, quality control (to include capturing missing information and ensuring communicability of results), keeping the project on schedule and within scope, approving and communicating changes. The team lead will also participate directly in key team meetings and often present to decision making bodies.
Experienced project management capabilities are necessary along with a basic understanding of the organization, its overall organizational objectives, general infrastructure and application knowledge, an ability to write and good communications skills. Consultative capabilities are extremely useful, particularly to establish clear goals, identify and close information gaps, ensure a quality design and communicate results.
Selecting the team
As indicated, a tiered storage design can be accomplished by a relatively small core project team comprised of approximately three-five individuals with limited support from one to five other contributors, depending on the size and scope of the project. Organizations with complex environments will often require more supporting team members to provide details of IT infrastructure and application/business requirements.
The team will likely consist of the following individuals:
- An executive sponsor with a stake in enterprise infrastructure. Direct access to or participation on the leadership team
- A project lead to provide impetus, manage resource, establish timescales and govern the project
- One to two individuals with infrastructure expertise and general knowledge about application requirements. A good rule-of-thumb is one infrastructure expert for each large storage pool.
- An experienced tiered storage designer
- A line of business client knowledgeable in business requirements for applications and able to provide input into the trade-offs between changed storage service levels and the cost of storage
Key actions for delegation include:
- An executive sponsor empowers the team and approves escalation processes
- A project lead delegates important functions to include: 1) data collection; 2) the construction of a proposed design with approximate costing; 3) design of the processes & procedures; 4) agreement with user/funding departments; 5) construction of the interim presentation; 6) construction of the final report to management; 7) Final documentation
Negotiating work plans and delegating work
As indicated, a typical tiered storage assessment will consume between 400-600 person hours to complete.
Installing escalation channels
The main points of escalation in a tiered storage assessment typically arise from lack of commitment to the process, lack of quality information and/or disputes over assumptions used to determine costs and benefits.
The following escalation levels can be used as guidelines:
- Level 0 - team members resolve issues with no need for escalation
- Level 1 - issues brought to team lead who constructs an adjudication process within the team
- Level 2 - team lead constructs adjudication plan using resources outside the team (e.g. internal experts or external consultants)
- Level 3 - team lead is unable to resolve conflict and escalates to executive sponsor
Establishing performance incentives
Performance incentives should align constituents but at the same time reflect the roles of the players. The executive sponsor and senior infrastructure managers should receive incentives related to achieving the financial and strategic goals of the overall tiered storage project. Direct project incentives should be constructed for the team lead and the financial/business analyst constructing the case. These incentives should be tied to the project's timely delivery and quality of design as judged by the executive sponsor.
Management by objectives (MBO's) are appropriate for other team members with notation in performance reviews for participation and a 'black mark' for not supporting the project in earnest.
Once the tiered storage design project has been approved, an executive sponsor assigned, a team lead freed up and commitments secured from major participants, resources for project execution should be released.
This section discusses the performance aspects of a tiered storage design.
Executing work plans
The following guidelines can be helpful in executing work plans:
- Preparing for kickoff meeting:
The project lead must prepare for the kickoff by setting the agenda, inviting in proper constituents, organizing meeting logistics and preparing the kickoff presentation. The kickoff presentation should introduce the team, describe roles and responsibilities, establish project goals and measurements for success, establish a process and time line, articulate escalation procedures and delegate actions. This presentation should be reviewed with the executive prior to the meeting.
- Kickoff meeting:
The kickoff meeting is a one to one and one half hour meeting between the project lead, infrastructure manager(s), application manager(s), financial representative and line-of-business manager. Players should be prepared to commit resources to the completion of the project and briefly discuss infrastructure goals, challenges, current approach and application requirements. The outcome of the kickoff meeting is an agreed-upon project plan, time line, escalation process and time for the next meeting.
Taking the right steps in the right order can make a tiered storage architecture that meets your business needs. The exact order for these steps will vary from one organization to another. The strategy is to address the business requirements first, then the management and operations, and only then the technology.
- Collect and review data on current environment (and make assumptions if necessary)
- Look at the storage usage and storage services used by the major applications, and project over a reasonable period of time.
- Allocate the current storage costs to the major applications, and to other application “suites”. Include all storage costs, including environments (if possible) and support costs.
- This will be the base line that you will use to compare the storage costs (higher or lower) to the tiered storage solution
- Establish the number of storage tiers required
There is a trade-off between the number of storage tiers provided, and the overhead of managing and migrating data between the different tiers. In practice, the number of tiers can be determined by
- Taking the key applications that support the business (e.g., CRM, Email, Finance, Reporting, etc.). Create a table like figure one below with the characteristics required for each of the major key applications. The figures in the table are not what is currently provided, but a judgment on what the most appropriate storage service level is to support the efficiency of the users.
- Group the applications into similar tiers, trying to reduce the number of tiers
- Usually, the number of tiers will be between three and six. In smaller installations it may be as low as 2, but should not be above 10 under almost any circumstances.
- Analyze the storage network implications and compute the costs/savings of additional/reduced ports, switches, and other network costs
Figure 1 is an example of a small number of tiers
- Establish the technical and SLA specifications for each tier
Define the service level requirement of each tier by looking at the major application with the most users and value to the organization within each tier. In figure 1 is a list of the major metrics that should be considered. List in detail the storage services required for each tier. A non-exhaustive list might include:-
- RAID level
- Cache size
- Dedicated cache
- Rotation speed of device
- Snap copies
- Asynchronous remote replication
- Synchronous remote replication
- Three data node synchronous/asynchronous replication with delta recovery
- Automatic data migration of volumes between tiers (without service interruption)
- Single console management of volumes
- Thin provisioning
- Allocate applications to an appropriate tier
- Allocate all applications and projected applications to the most appropriate tier, putting them in a lower tier if in doubt.
- Calculate the storage requirements for each application over an appropriate time period (3-5 years).
- Calculate the total storage, controller function, storage network requirements, storage management function and software, and storage administration costs for each tier over the time period.
- Calculate a cost/GB charge-back for each tier
- Calculate a business case for the major applications with the change in costs to the end user, and the business line items. An example of a business case for a specific application is shown in Figure 2.
- Look to see if there is a case for changing the storage tiers up or down. Do the business line items support a change? Decide on the final allocation of the application data to a tier.
Figure 2 - Example of Business case for Tiered Storage for a Specific application
- Obtain agreement from the departments that fund and use the applications to the storage tiers and Storage Service levels
- If required, show the specific application business case to the business executives responsible for funding the applications. Included in the business case should be the cost of storage before and after the change to tiered storage.
- For each of the major applications, include the business line item changes to productivity from changes to availability, performance, etc.
- If required be prepared to show the impact of changing the tier on the overall return
- Create an outline specification of the key processes and procedures
- Update the business case (if necessary)
The methodology for building a business case was covered in the article Analyzing the need for tiered storage
- Communicate and obtain feedback on the tiered storage design
Collect all the information from the user sessions, and present back an application view and a “tier” view of the proposed tiered storage design
- Incorporate feedback and refine design
- Fully document the design
- Final communication & sign-off from the stakeholders
- Key risk impacts of designing a tiered storage solution
The key risks that should be identified:
- Failures to understand the real storage requirements of applications
- The over-complexity of the solution leading to higher management costs and possibly decreased availability
- Failure of the technologies and/or combinations of technologies to work together as envisioned.
The business case in the analysis phase of the project included a worst case scenario. This case should be updated. At a minimum it should include a doesn’t work worst case scenario (e.g., fall back to current storage philosophy), a worst case scenario (increase the costs and decrease the benefits to a (say) 90% confidence level that they will be achieved), and a best case scenario (potential benefits is project exceeds expectations).
- Business case presented to team:
The business case should be presented to the team to solicit feedback and refine prior to the final presentation to the decision making body. This can be accomplished in a one to one and one half hour meeting to review assumptions and capture comments
- Final report written, delivered and presented:
Feedback from the team meeting should be incorporated into the process in less than one day to revise assumptions and rerun data. An additional four days will be required to construct the final report / presentation to the management committee.
It is advisable to spend approximately one day per quarter throughout the project to realign the plan based on feedback from the design, build, and implement and operations phases.
Team members should be advised to track their time so a post project evaluation can be performed. This will allow the accurate accounting for project costs and act as a feeder source for future design projects.
Scanning contingencies and solving problems
Contingencies should be considered constantly to include technology and price dislocations, market shifts and execution challenges. Some typical project-oriented hurdles follow with possible causes and advised contingency steps:
- Issue: Major changes in technology or pricing discredit fundamental assumptions. Cause: Original assumptions were flawed or team is not current. Action: Revisit assumptions and perhaps install a more experienced team member.
- Issue: Market conditions change necessitating a change in strategy. Cause: Outside forces. Action: Place the project on hold and reevaluate.
- Issue: Infrastructure or application team is unable or unwilling to provide the necessary levels of detail and accuracy for an effective design. Cause: Team does not have proper participation incentives in place or data collection team is inexperienced. Action: Adjust incentives, escalate or install more experienced staff.
- Issue: Disputes arise over the proposed number of tiers and definition of those tiers. Cause: Miscommunication about objectives, technical assumptions or business requirements or inexperienced professional building models. Action: Revisit assumptions and requirements, solicit vendor assistance, install new expert on the team.
- Issue: Disputes arise over the change in storage SLAs for some applications and the suggested impact on productivity. Cause: Political tensions (e.g. manager does not want to commit to level of benefits), dubious projections, lack of credible case examples. Actions: Negotiate targets within a range, obtain best practice metrics of likely achievement.
- Issue: Project falls behind schedule. Cause: Unrealistic expectations, other priorities, lack of credible data, lack of resource. Action: Reset expectations, escalate to determine priority, perform additional research to improve data sets, realign schedule and work plans, reevaluate incentive structure.
Upon successful project completion, incentive targets should be reviewed expeditiously and performance incentives delivered where appropriate. This can be accomplished only with incentives related to project performance. Project result incentives will need to wait until enough experience is gathered in the customer base to audit results.
The promoting phase involves testing and auditing results, transferring knowledge gained and distributing operational responsibilities. Tiered storage will be a new concept to both IT and business staff, and will require “thought leaders” to embrace it.
The ability to test or audit results is dependent upon: 1) the initial setting of clearly communicated goals that are measurable; 2) the commitment to measure and agree on results; 3) the expertise and credibility to measure results. Key measurements for a tiered storage design include:
- The accuracy of the existing installation cost data on a relative scale (e.g. 1 to 10). Are the results deemed credible by finance? Are hidden costs exposed? Are charge-backs defensible? Can the systems used to track results be transferred to other projects?
- The quality of the tiered storage design: are the number of tiers reasonable compared with other installations of similar size and complexity? Do the tiers offer distinct business choices to the application providers? Is the cost/Gigabyte for each tier different by a factor of 100% to 150% from the adjoining tiers?
- The perceived accuracy of the proposed tiered storage costs-- are the estimates accurate within a degree of comfort defined by management?
- The time scale required to complete the project - was it reasonable? Was the project on schedule and on budget within acceptable levels determined by management?
- Did the departments accept the proposed changes in storage SLAs for the applications? We the departments enthusiastic about the overall strategy?
- Potential business impact - does the proposed project demonstrate the financial and non-financial attributes that make it desirable? How desirable (e.g. what percentile relative to other projects)?
- All Risks Identified – are all the risks to a tiered storage implementation been identified? Have the risks been included in the worst case scenario?
These attributes should evolve as the tiered storage project evolves, specifically tracking the proposed costs and benefits over the life of the project and into post-implementation phase.
Training a wider team on the process of designing tiered storage can be accomplished by:
- Documenting the process and results
- Communicating results in public
- Publishing the process and results for peer review
- Performing formal training
- Publishing a case study
- Making available artifacts used in the assessment (tools, templates, etc.).
Distributing operational responsibilities
Once completed and made procedure, the assessment process and results can be transferred to a day-to-day stakeholder to maintain and keep the design up-to-date. The recipient of the process should have appropriate incentives in place to maintain the design and extend its usefulness. Incentives may include job descriptions, MBO's or other incentives for ongoing improvement.
This section addresses exit strategies. It is important to note the useful life of an assessment can be many years and professionals should be encouraged to innovate and improve the process to extend its useful life.
Reconciling plans with actuals
Systems should be in place to track expectations with actual performance. Ideally, these are automated as part of the day-to-day metrics captured by an organization.
Finalizing incentive payments
The tracking of actual versus plan is the basis for paying incentives on performance-based objectives, as well as ongoing incentives that are in place.
Dissolving the effort
Dissolution should occur when the cost of maintaining the process exceeds its business value, or when the tiered storage technology selected is no longer the most appropriate and/or the technology is so longer supported by vendors.