Storage Networking Design and Management - Session 2

Storage Networking
Design and Management
Section 1: Business Value & Requirements Analysis
2007 EMC Corporation. All rights reserved.
Overview
Module 1.1: Application Classes &
Drivers for Storage demand
Application classes
Storage growth trends by class of
application
Storage purchase drivers
Module 1.2: Business Value Analysis

Direct & indirect costs
TCO & ROI
Definition of business value metrics and
Key performance indicators
Section 1:
Business Value &
Requirements Analysis
Application Classes &

Drivers for Storage Demand
Business Value Analysis
Module 1.3: Requirements Analysis

Requirements Analysis & Methodology
Basic metrics that define the
requirements
Module 1.4: Case Study

Case Study
Business Value & Requirements Analysis

Upon completion of this section, you will be able to:
Define Application Classes and their Characteristics
Explain the direct and indirect costs associated with the deployment
and operation of Storage Networks
Articulate the elements of service targets for applications in
technical and business terms
Develop business value justifications for Storage Networks
deployment
Gather business requirements with a structured methodology in
terms of availability, reliability, performance, manageability, security,
continuity, etc.
Define and develop quantifiable metrics for the requirements in a
Storage Networking environments
Module 1.1
Application Classes and Storage Demands
Application Classes and Storage Demand

Upon completion of this module, you will be able to:
Classify the application based on capacity and
performance requirements
Detail factors that contribute to the Storage needs in each
class of application
Application Classification
Data Storage is a means to an end.

Not an end in itself!
Applications generate the need for Storage

and recall of data.
Storage Trends
Overall, Storage budgets for
2006 will average approximately
$3.4 million, 5.2% higher than
last year. 56% percent of the
surveyed companies say they're
increasing Storage budgets at
16% vs. the same time last year
Source: searchstorage.com
Demand for Storage Capacity

Reasons for
Storage
purchase
Data growth in
New application
existing applications and
Implementations
architectures
Demand for
Storage Capacity
Retrofit of Storage
Systems with different
architecture
Purchasing
Process
Selection of vendor comes

after consideration of
application performance
requirements and economics
of alternatives
Source: Customer interviews; McKinsey and Merrill Lynch

Replacement
of old units within existing
architecture
Existing vendors offerings

are evaluated first
Application Classes
A classification to understand Storage needs
Classification based on:
Capacity
Performance
Need for availability
Degree of connectedness
Application Classes
Externally networked
Examples ?
Enterprise
Workgroup
Performance & Throughput
Externally Networked
Degree of
Enterprise
Connectedness
Workgroup
Availability
Application Classes that Determine Storage

Demand
Application Class
Externally
Networked
* Email
* Web Page delivery
* E-commerce
* Rich Media on demand
* Cross enterprise
applications
* Credit Card processing
* Multi user applications

networked beyond
enterprise
* Visible to customers and
suppliers
Enterprise
* Internet
* Document
management
* ERP,OLTP
* CRM,SCM
* Datawarehousing, BI
* Workflow Management
* Core legacy systems
* Industry Specific
applications
* CAD CAM
* Multi user applications

networked within the
enterprise
* Often critical to core
business process
Workgroup
* Word processing
* Spread sheet
* Desktop/PC backup
Degree of
Connectedness
Low
High
Need for Availability
* Research Databases
* Animation
* CAD/CAE/CAM
* Applications used by
Single users or small groups
* Shared on Common
servers
* Distributed over networks
Growth Trends for Application Classes

Due to their relative maturity and ubiquity, most workgroup applications are
generating comparatively slow increases in demand for Storage capacity
Enterprise applications drive strong demand for Storage capacity
Externally networked applications will, over time, become the primary
drivers of capacity growth
30-90
300 Peta bytes shipped in 2000
20-40
75-300
Source Customer interviews: Merill Lynchs reality Check survey of 110 CIOs
Infrastructure Software
Infrastructure Software supports applications
Infrastructure Software drives Storage demand
Applications
Infrastructure Software
Operating system
Monitoring and management
Messaging system
Storage resources
Workload scheduling and

balancing
Applications
Network
System
Application development
Replication and availability
Management of reusable
Back-up/restore
objects and data

Test creation and execution
Infrastructure Software Multiplies Data Growth

Example
How data growth is

Infrastructure
fueled
Software Functionality
Makes Copies of
data
Generates data
about data
Replication
Mirroring
Back-up
Caching
Storage resource
Management
Capacity
Multiplier
1X 10X
0.1X 6.0X
0.1X 1.0X
1X 42X
0.1X 1X
Storage Software Addresses Performance Needs

Functionality in
Performance Need:
Storage SW Stack:
Heterogeneous device
interoperability
Interoperability
Heterogeneous network
protocol interoperability
Block and file data
interoperability
Intelligent caching
Throughput
Load balancing and

performance tuning
Clustering
Availability
Automated failover
Real time replication
Automated back-up and
recovery
Ease of Management
Virtualization
Device discovery and
management
Security
Storage OS
Primary Driver for Storage Purchasing Decision

Performance Characteristics
Ease of Management
Availability
Throughput
Interoperability
Reliability
Scalability
Throughput
d
e
Ne
fo
h
T
r
h
g
u
o
r
t
u
p
Operational Requirements for Application Classes

Performance Segments
Externally
Networked
Throughput
Enterpris
e
Availability
Degree of Connectedness
Workgroup
Ease of management
Low
Need for Availability
High
Performance Segment Application Requirements

Performance Segment
Ease of Management
Availability
Throughput
Heterogeneous network protocol interoperability

Block and file data interoperability
Intelligent caching
Load balancing and
performance tuning

recovery
Virtualization
management
Security
interoperability
Clustering
Automated failover
Clustering
Automated failover

recovery
Virtualization
management
Security
interoperability

recovery
Virtualization
management
Security
interoperability
Storage Network OS
Primary Focus

Optimal Storage for Performance Segment

Ease of management
Traditional NAS
Availability
SAN, High-end NAS Converging with SAN
Throughput
Custom designed Storage Networking architecture
Higher performance segments require successively

smarter Storage software
Architecting a Solution
Storage service requirements are typically expressed in
terms of:
Availability, Recoverability, Ease of Management, etc.
Storage service requirements are expressed in quantities

or metrics (that we can measure), which validates the
level of service provided
Solutions are recommended to support target service
goals
Check Your Knowledge

Application Classification Mini-Lab
For each of the scenarios described below:
Classify the application(s)
AND
Create 5 questions to help determine the exact requirements
R-LABS Stem cell therapy research team uses a mouse model to validate the
effectiveness of a transplantation treatment. They generate large volumes of data
that must be stored and analyzed for subsequent research. The research team
requested 1TB of Storage to be used by the 6 researchers in the team.
The online auctioning site, hosted by i-trade, started experiencing 100 fold increase
in hits on their site after an advertisement blitz on the national network. Their
application demands an additional 20TB of capacity.
Z-Banks recent misadventure in a loan scam in an emerging market economy has
prompted them to implement a new credit risk analysis system with capabilities of
deep data mining and to provide enhanced business intelligence to their loan
officers. The application development team has determined 10TB of Storage
requirements.
Module Summary
Key points covered in this module:
Applications can be classified into three classes:
Externally networked, Enterprise, and workgroup
Classification is based on degree of connectedness and

performance requirements
Operational requirements of the applications determine the
performance segment to which the application belong
Applications and infrastructure software drive Storage growth
Storage software typically addresses performance needs
Architecting a Storage solution is based on the performance
segment, and the degree of connectedness with the appropriate
software components
Quantifying the requirements in technical and business terms are
the first step towards successful Storage deployment
Module 1.2
Economics of Storage Networks

Detail the direct and indirect cost to implement a Storage
solution
Define TCO, ROI, and related terminology
Develop a financial model for different Storage
architectures
Develop business value justification for implementing
Storage Networking solution
Cost Components of Storage

Price Cost
Total Cost
Direct Costs
Indirect Costs
Capital Expenditure
Operating Expenditure
Down Time
Disappointing User
Hardware
Maintenance
Software
Environmental
Lost Data
Installation
Support & Staffing
Shortage of people
Capital write-off
Bandwidth provisioning
Switching Costs
Experience
Delay to Market
Lets Do a Simple TCO Calculation

Customer ABC has an existing CX600 Storage array that
was deployed three years ago which has just come out of
warranty and new maintenance contract is to be initiated
The CX600 is used by the Orders Department, which
requires an additional 500GB of capacity each year for
the next three years
You have two choices:
Upgrade the existing CX600 with the required additional capacity
each year
Roll in a new CX700 on lease to meet the current demands and
future requirements
Compute the TCO based on two components of direct

costs, asset acquisition and maintenance
TCO for Upgrade of Existing Assets

CUSTOMER ABC
Detail Behind the Total Cost of Ownership Analysis
Current Environment no Maintenance Pre-payment
Year 1
4/1/05 5/1/05
CX600 HW Maint
1,550
1,550
CX600 SW Maint
2,128
2,128
Future Storage Consuption
10,000
MONTHLY COST OF INFRASTRUC.
13,678
Year 2
CX600 HW Maint
CX600 SW Maint
4/1/06 5/1/06
1,705
1,705
2,340
2,340
10,000
14,045
Year 3
CX600 HW Maint
CX600 SW Maint
4/1/07 5/1/07
1,875
1,875
2,575
2,575
10,000
14,450
Rate X Term of Current Environment TCO
Assumptions:
3,678
4,045
4,450
6/1/05
7/1/05 8/1/05 9/1/05 10/1/05 11/1/05 12/1/05 1/1/06 2/1/06 3/1/06
1,550
1,550
1,550
1,550
1,550
1,550
1,550
1,550
1,550
1,550
2,128
2,128
2,128
2,128
2,128
2,128
2,128
2,128
2,128
2,128
3,678
54,136
6/1/06
7/1/06 8/1/06 9/1/06 10/1/06 11/1/06 12/1/06 1/1/07 2/1/07 3/1/07
1,705
1,705
1,705
1,705
1,705
1,705
1,705
1,705
1,705
1,705
2,340
2,340
2,340
2,340
2,340
2,340
2,340
2,340
2,340
2,340
Total
20,460
28,080
3,678
3,678
3,678
3,678
3,678
3,678
3,678
3,678
3,678
4,045
58,540
6/1/07
7/1/07 8/1/07 9/1/07 10/1/07 11/1/07 12/1/07 1/1/08 2/1/08 3/1/08
1,875
1,875
1,875
1,875
1,875
1,875
1,875
1,875
1,875
1,875
2,575
2,575
2,575
2,575
2,575
2,575
2,575
2,575
2,575
2,575
Total
22,500
30,900
4,045
4,450
4,045
4,450
4,045
4,450
4,045
4,450
4,045
4,450
4,045
4,450
176,076
10% increase in maintenance costs year over year.

Upgrade each year to address growing storage needs
Total
18,600
25,536
4,045
4,450
4,045
4,450
4,045
4,450
4,450
63,400
Replace with a New Infrastructure
Rapid decline in Disk price
TCO for Leasing New Equipment

CUSTOMER ABC
Detail Behind the Total Cost of Ownership Analysis
Current Environment with Maintenance Pre-payment
Year 1
4/1/05 5/1/05 6/1/05
CX600 HW Maint
CX600 SW Maint
CX700 Lease
Year 2
CX600 HW Maint
CX600 SW Maint
3,683
3,683
4/1/06
CX700 Lease
Year 3
CX600 HW Maint
CX600 SW Maint
3,683
3,683
4/1/07
CX700 Lease
3,683
3,683
Rate X Term of Current Environment TCO
Note:
3,683
3,683
5/1/06
3,683
3,683
5/1/07
3,683
3,683
3,683
3,683
6/1/06
3,683
3,683
6/1/07
3,683
3,683
7/1/05
3,683
3,683
7/1/06
3,683
3,683
7/1/07
3,683
3,683
8/1/05
3,683
3,683
8/1/06
3,683
3,683
8/1/07
3,683
3,683
9/1/05 10/1/05 11/1/05 12/1/05 1/1/06
3,683
3,683
3,683
3,683
3,683
3,683
3,683
3,683
9/1/06 10/1/06 11/1/06 12/1/06 1/1/07
3,683
3,683
3,683
3,683
3,683
3,683
3,683
3,683
3,683
3,683
9/1/07 10/1/07 11/1/07 12/1/07 1/1/08
3,683
3,683
3,683
3,683
3,683
3,683
3,683
3,683
132,588
3 yrs HW/SW Maint included in monthly payments.
3,683
3,683
3,683
3,683
2/1/06
3,683
3,683
2/1/07
3,683
3,683
2/1/08
3,683
3,683
3/1/06
3,683
3,683
3/1/07
3,683
3,683
3/1/08
3,683
3,683
Total
44,196
44,196
Total
44,196
44,196
Total
44,196
44,196
TCO Comparison
Year 1
Existing Cost Obligations $54,136
Proposed Cost Obligations $44,196
Cost Savings $9,940
Year 2
$58,540
$44,196
$14,344
Year 3
$63,400
$44,196
$19,204
70,000
60,000
50,000
40,000
Keep Equipment
30,000
Replace Equipment
20,000
10,000
0
Year 1
Year 2
Year 3
$43,488
Total Cost of Ownership (TCO)

Total Cost of Ownership
One time Costs
Hardware, Software, Installation, Decommissioning
Recurring Costs
Maintenance, Upgrades, Annual License Fees, Support
Project Duration
Expected Lifespan of Investment
t=end of Project
One time costs + recurring costs (t)
TCO =
t=1
Project Duration
Return on Investment (ROI)

TCO represents investments
Investments are expected generate gains
ROI is measured as:
(Gain from investment Cost of investment)
ROI =
Cost of Investment
Companies that more carefully consider how much they spend on IT and
more diligently manage their IT projects performed better in terms of revenue
growth, ROI and cash flow over a 3 year period than those of their
competitors.
Yankee Group 2002
Payback Period
asset
Purchase &
deployment
costs
liability
Deployment
BEP
time
Time Value of Money

A dollar today is worth more than a dollar in the future
What is the interest rate we should use?
How can I make my calculation more risk tolerant?
NPV =
C
t
(1+r)
t=0
Relative Cost Components of Storage Architectures

Cost breakdown of Storage Architectures*
Percent
100% = $0.84/MB
$0.35/MB
$0.38/MB
Installation
Network HW
Software
Back-up HW & Media
Storage Subsystem
People
* Based on 2TB of user data and 10 servers; as of March 2001; see Appendix E for assumptions
Source: Customer interviews; expert interviews; McKinsey and Merrill Lynch
TCO Over Time
TCO over Time

$/MB
10 server DAS
At time of purchase, SAN

TCO is not compelling
Other Hidden Costs:
30 server SAN
10 server SAN
Removing existing DAS

Risk of migration
Length of Ownership
* Based on 2TB of user data; as of March 2001

Source: Customer interviews; expert interviews; McKinsey and Merrill
Lynch
ROI Elements
What are the full
costs to deploy,
manage and support
the Solution?
What savings can be

captured in CAPEX by
deploying the
Solution?
What are the specific

business processes
that have a
measurable financial
impact when the
availability of the
infrastructure is
improved?
What are the

operational savings
that can be delivered
by the infrastructure
Implemented?
Business Value Analysis Methodology

Analyze current environment to identify and define costs that can be
applied in the TCO / ROI calculation
List all operational expenditures and investigate potential savings
Detail a future state environment that meets business
requirements and provides operational savings
Perform analysis for different technology options / vendor solutions
for comparison
Critical Success Factors Include:
Should be conducted with the Finance department and all other key
business stake holders
All ROI savings should be substantiated credibly within the organization
Consideration of all risks involved with the investment must be detailed and
documented
Economic Value of Storage Initiatives

The Four Elements of the Business Value Analysis:
Benefits
Value delivered to the business by proposed project
Costs
Investment necessary to capture the value or benefits (TCO)
Flexibility
Investing in additional capacity that could be turned into a business

benefits for future additional benefits
Risk
Risk factors that impact benefits and costs
Capital Cost Savings
Capital
Cost
Savings
Improved Asset Utilization
Recovery of Stranded Assets
Improve Disk Utilization

Average raw capacity installed for 20 TB of data
Terabytes
Improved disk
utilization in
Storage Networks
results in a 40%
reduction in
installed capacity

Operational Cost Savings

Cost of floor space and power
FTE/managed TB of Storage
Operational
Cost
Savings
Back-up costs
Enhance availability
Rationalization of servers
Better utilization of Storage
Ability to perform additional operational
services
Storage Networks Provide Better TCO than DAS

3-year TCO by Storage Architecture*
$ per megabyte of user data
Cost saving of SAN and NAS

driven by:
Improved disk utilization
Centralized management
Tape drive consolidation
NAS does not have SAN
network and installation
charges
* Based on 2TB of user data; as of March 2001
Source: Customer interviews; expert interviews; McKinsey and Merrill Lynch
People Cost Savings of Storage Networks

People savings from Storage
Networks
DAS cost breakdown*

Percent
Percent
7
92-83
Working Council for CIOs
15
Enterprise Storage Group
73
7
Gartner
31
* 2TB DAS environment; not including environment costs

Source: Working Council for Chief Information Officers; Enterprise Storage Group; Gartner Group; McKinsey and Merrill Lynch
66
Storage Management Consolidation

Storage Management
consolidation yields greater
benefits than just Storage
consolidation
Storage per FTE Benchmark for comparison
Management consolidations
should bring Storage
Management function into a
single accountable group
Storage Management
consolidation should be based
on Storage Administration
stack
Policy (Conceptual)
Infrastructure (Physical)
Operations (Operational)
Business Impact:
IT organizations that deploy an
organization based on the Storage
Administration stack can manage 2x
Storage per person versus those that do
not. Meta Group
Business Cost Savings

Revenue Retention
Customer Loyalty
Revenue From New Services
Business
Cost
Savings
Increased Productivity of Staff

Reduction in Regulatory Penalties
Reduction In SLA Penalties
Faster Response to Business
Conditions (time to market)
Avoiding Downtime Costs

Example Downtime Costs by Company
$ Millions per hour
Example Downtime Costs by Industry

$ Millions per hour
Financial brokerage
6.45
Credit card authorization
2.60
Home shopping
0.11
Catalog sales
0.09
Airline reservations
0.09
Tele-ticket sales
0.07
Package shopping
0.03
Enhanced Availability with Storage Networks

Source: Contingency Planning Research; Forrester Research; USA Today 2/11/00
Other Indirect Costs

High Cost
Cost Component
Down time
DAS
NAS
SAN
Disappointing User
Low Cost
Description
Lost sales and damaged brand for external system, and lost
productivity for enterprise systems
User frustration with system performance
experience
Lost data
Angry customers and government fines due to missing or damaged

data
Shortage of People
Lack of skilled Storage Administrators
Switching costs
Risk of new system not working and pain of learning new system;
replacement of still-useful legacy systems
Delay to market
Delays in changing Storage capacity and functionality to meet new

user requests


Define TCO & ROI
Define Payback period
What factors drive the cost savings for Storage
Networks?
List five means of business cost savings with Storage
Networks
Module Summary
Elements that constitute the Total Cost of Ownership in a
Storage investment
Return on Investment (ROI)
A structured methodology to develop business value
justification
Module 1.3
Define functional (FR) and non-functional requirements (NFR)
Define the system environment and stakeholders of the system
designed
Explain how use cases are documented for functional
requirements and how the NFRs are typically defined
List types of NFRs and their classification
Describe the SMART methodology of requirement specification
Describe basic metrics for Storage and how they are inter-related
Describe Performance stack layers
Project Lifecycle
Determine Customer needs (What)
Specification
Document Customer needs (What)
Design
Design a Solution (How)
Implementation
Show Solution meets specification
Keep Solution Working
Implement a Solution (How)
Verification
Maintenance
Lesson 1: Requirements Analysis Overview

Upon completion of this lesson, you will be able to:
Describe the Requirements Analysis process for Storage
Networking
Identify and describe Functional & Non-Functional
Requirements
Define the system environment and stakeholders of the
system designed
Identify SMART Requirements
Requirements Analysis for Storage Networking

Storage Networking changes environment
Rapidly
Provides greater flexibility
Users learn the potential
Hence, requirements change

During Requirements analysis
All other phases of lifecycle
Most influential phase of Lifecycle

Cost of repairing a defect is highest if the requirement specification is
incorrect
Storage Networking implementation requires a disciplined

approach to requirements analysis
Functional & Non-Functional Requirements

Requirements definition
Customer-oriented descriptions of the system's functions and constraints on
its operation
Requirements Specifications
Precise and detailed descriptions of the system's functionality and
constraints
Intended to communicate what is required to system developers and serve
as the basis of a contract for the system development
Functional Requirements (FR)

Describes the behaviors (functions or services) of the system that supports
user goals, tasks or activities
Non-functional Requirements (NFR)

Details Constraints and Qualities
Storage Networking design should focus on NFR supporting the application
designed
Understanding the System Environment

The Wider Environment
The Containing System
Customers
The SYSTEM
being developed
Operator The
s Equipment
Our
What they want Scenarios

the SYSTEM
(how to use the
to do for them equipment)
(desired results)
Neighbouring
Systems
Interfaces
(how they use the
equipment)
Regulators
Constraints
(standards,
regulations)
Stakeholders
Line of business and their users
SW developers
System administrators
Database administrators
Network administrators
Data center operations
External Vendors
Regulators
Stakeholder Viewpoints
Our
Customers
Operators of the
Equipment: we make it
work, on behalf of our
customers
Operators
The
Equipment
Direct
Beneficiaries
of the system:
its for them
Incidentally, which
of these would you
call Users?
Neighbouring
Systems
Regulators care about safe

and effective running of
system, from outside, on
behalf of the public
Regulators
Owners of
neighbouring
systems care about
the results they can
get through their
interfaces to our
system
Specification of the Requirements

Functional Requirements are specified as Use cases
Actor/
Role
Special
Cases
(exception
scenarios)
The basic functional

requirements form
the steps of the story
here
Supporting
requirements
are added here
Desired
Outcome
From the
System
(What
defines a
successful
behaviour)
Any other
details
needed:
preconditions,
triggers,
constraints,
stakeholders,
guarantees
Alternative
Paths
(other possible
scenarios)
If these or other parts of

the story are complicated,
we can treat them as
included Use Cases
in their own right
End result: system behaviour is described in a clear, readable, well-organized way

Typical Use-case Document Structure

Introduction
Business Objectives
Stakeholders (Operational/Non-operational)
References
Conventions Used
Use Cases
Group1 (Cases in Use Case Diagram1)
Use Case1
Primary Scenario (steps 1, 2, 3)
Alternative Paths
Exceptions
Local NFRs
Next Use Case...
Next Use Case Group
Global NFRs
Sources of NFR Run-time Qualities

Run-time qualities
How well the functional requirements defines the expected service
qualities
Judged by the user in terms of some characteristic that the user
values or is concerned about
Provide value to the user and has more to do with short-term
competitive differentiation
Run-time non-functional requirements arise from the operating
environment, user(s), and competitive products
Often expressed in Fuzzy terms subject to wide ranging

interpretation
Critical success factor involves appropriate quantification
of the run time qualities
NFR Classification
Product requirements
Requirements which specify that the delivered product must behave
in a particular way
execution speed, reliability, etc.
Organizational requirements
Requirements which are a consequence of organisational policies
and procedures
process standards used, implementation requirements, etc.
External requirements
Requirements which arise from factors which are external to the
system and its development process
interoperability requirements, legislative requirements, etc.
NFR Types
Nonfunctional
requir ements
Product
requir ements
Ef ficiency
requir ements
Reliability
requir ements
Usability
requirements
Performance
requirements
Or ganizational
requir ements
Portability
requirements
Delivery
requirements
Space
requir ements
External
requirements
Interoperability
requirements
Implementation
requir ements
Ethical
requirements
Standards
requirements
Legislative
requirements
Privacy
requirements
Safety
requirements
NFR Examples
Product requirement
4.C.8: Database should be backed up without impacting online
availability for web users
Organizational requirement
9.3.2: Storage utilization report shall conform to the process and
deliverables defined in XYZCo-ST-STAN-06
External requirement
7.6.5: Migration to the new Storage infrastructure should be nondisruptive to existing operating environment
Goals and Requirements

Non-functional requirements may be very difficult to
state precisely and imprecise requirements may be
difficult to verify
Goal
A general intention of the user, such as ease of use
Verifiable non-functional requirement

A statement using some measure that can be objectively tested
Goals are helpful to Storage Architects as they convey

the intentions of the system users
Examples
Availability Goal
Data availability should be maintained during the online hours
Verifiable Non-functional Requirement

The system should be available 99.999% during 9am to 6 pm
Requirements Document Aims to Achieve

Readability (requirements in narrative scenarios)
Simplicity in use
Traceability to individual items
Accuracy of representing relationships between items
Freedom to work in style appropriate to situation
Compliance with industry standard tools & methods
SMART Requirements
Specific
Measurable
Attainable
Realizable
Traceable
Projects without clear goals

will not achieve their goals
clearly
You cant hit a bulls eye if

you dont know where the
target is
Requirements Measure Example

What does a use case specify?
What are NFRs?
List 5 typical NFRs
What does SMART refer to?
Lesson 2: Basic Metrics in Storage Networking

Upon completion of this lesson, you will be able to:
Describe NFR Specification for Storage Networking
environment
Identify Service Level Inter-dependencies
Apply SMART requirements to NFR
Describe basic metrics for Storage and Storage
Interconnect infrastructure
NFR Specification for Storage

Capacity (maximum Storage requirement & growth
trends)
Performance
I/O throughput
Application response time
Batch process completion times
Availability
Disaster Recovery
Back-up & Archival requirements
Characterization of application workloads
Is Storage Important in an Application?

Everything starts from the disk
Disks must be reliable and fast
All physical disks are only capable of doing approximately
200 operations per second
Server Storage Performance Gap
Service Level Inter-dependencies

Array
APPs
data
data
Applications Layer
Host
/ O.S.
Host
/ O.S.
Host
/ O.S.
Volumes
STORAGE/IP
NETWORK
Array
Storage Networks
Layer
Host & HBA

Layer
Volumes
Storage
Layer
Application Database Vol.Mgr Dev. Driver

Host Bus
Disk Cache Disk Bus Disk Drive
Defining Performance via the Performance Stack
Application
File System
Volume Manager
Virtual Memory
HBA/Driver
Storage Controller
Cache
Back-end
Host
Throughput
Storage & IP networks
Bandwidth
Storage
Response Time
Components of a Disk Access Time (A Recap)

Seek time: Time for head to settle on proper track
Arm acceleration, coasting, deceleration, head positioning
Typical average seek time: 5-10 msec on modern disks
Rotational delay: Time for block to rotate under head
On average, half a rotation

Typical rotational speed: 7200 RPM, 10K RPM, 15K RPM
Transfer time: Time to transfer data to/from disk surface

Depends on request size and track density
Full rotation required to transfer contents of entire track

Typical bytes per track: 64KB -256KB
Tracks not all the same size (increase going outwards)
Response Time
Littles Law Derivative (Random I/O)
Response Time = queueDepth * service time
Drives only read/write one I/O at a time!
Disk service time is key
This is the same for all arrays using the same drives in the same
manner!
What is Wrong in this Conversation?

DBA
I need Storage for a new
database
Well around 200GB
Storage Admin
How big is your database?
Ok, give me a couple of
minutes to create a new file
system for you
Or
There is room on file system
xyz, just create a new directory
for your database
IOPS vs. Response Time

Biggest Mistake: I/O subsystems are sized by Storage
requirements and not by IOPS
Source: Dave
Patterson
Actually: Max(disks for Storage, disks for IOPS)

I/O in a System
Planning for IOPS

Rules of thumb: how to plan for IOPS
Compute disk load from your host workload
RAID effects, read/write ratio
Compute disk potential

Compare the two to get Disk Utilization
Host
Loads
RAID
Effects
Disk
Load
Disk
Potential
Disk
Utilization
Computing Disk Load from Host Load

Host
Loads
RAID
Effects
Disk
Load
Read Percentage, write percentage, RAID multiplier used

RAID 1 or 1/0
RAID Multiplier = 2 (Mirroring, so all host writes are doubled)
RAID 5
RAID Multiplier = 4 (Parity write operations require 4 disk I/O)
RAID 5: Total I/O = Host Reads + 4 * Host Writes

RAID 1 and RAID 1/0: Total I/O = Host Reads + 2 * Host Writes
See example in notes section below
Computing Disk Potential - 1

Disk Potential = IOPS/drive * Disk Count
Drive
IOPS
MB/Sec
10K RPM
140
10
15K RPM
180
13
Example: 60 10K rpm drives 60 * 140 = 8,400 IOPS

This is a good estimation of max disk potential
Numbers above are rule of thumb
They assume the system is not perfectly tuned
They assume near perfect randomness
Computing Disk Potential - 2

Disk
Load
Disk
Potential
Disk
Utilization
Disk Utilization = Disk Load / Disk Potential

A total load of 4200 IOPS results in:
4200 / 8400 = 50%
How is this important?

Disk Utilization tells us where we land on the curve
Estimate disk queue from Disk Utilization: q = u/(1-u)
Use Disk Service time rule of thumb of 6 ms
Optimizing Use of Disk Bandwidth

Use all available disks
Data must be spread across many disks
Avoid disks that are hotter than other disks
Hot disks become bottlenecks
Workload should be the SAME on all the

disks
Make full bandwidth of all disks available

to any operation
Maximize Single disk performance

Two prevailing access patterns
Sequential Access
Random Access
SEQUENTIAL: optimize by using large

I/Os
RANDOM: optimize by minimizing length
of head movement
NFR to SMART for Storage Networking

Defining and understanding the NFR
Developing measurable metrics for NFR
Understanding the potential Components in the high level
design:
Hosts, SAN, LAN, HBA, Storage
Classification of the Service using a goal-oriented

approach
Specific ; Measurable; Attainable; Realizable; Traceable
SAN Quality of Connection (QoC)

Three metrics that Characterize how well a SAN will
service the Enterprise:
Availability
Presence or absence of a service
Performance
Operation of Service under normal and adverse failure conditions
Scalability
How effectively it scales in bandwidth and connectivity
Classification of Service based on the metrics

For easier identification of Topology & Architecture
Type of backbone interconnect
Design Considerations: High Availability

Eliminate SAN points of Failure
Guard against path fail-over malfunction
Select path fail-over software
QoC and Architecture: Define Metrics

SAN Availability
availability %
downtime per year
downtime per month* downtime per week
98
7.30 days
14.4 hours
3.36 hours
99
3.65 days
7.20 hours
1.68 hours
99.5
1.83 days
3.60 hours
50.4 min
99.9
8.76 hours
43.2 min
10.1 min
99.99
52.6 min
4.32 min
1.01 min
99.999
5.26 min
25.9 s
6.05 s
99.9999
31.5 s
2.59 s
0.605 s
Performance
Measured in bandwidth and response time for given number of I/Os
per second
Eliminate SAN Points of Failure
HBA
Storage Adaptors
Fiber optic cables
Interconnect devices
Path failover SW
Guard Against Path Fail-over Malfunction

Path fail-over implemented on the server
Implications in a switched SAN environment
16 port Switch motherboard failure could trigger path fail-over for 12
or more servers
Selection of interconnect devices with fault tolerant

features
Change management challenges for path failover SW
addressed early in the design
Test and certify the path failover SW for the hosts, HBA and
interconnect devices in the design
QoC Metric 1: SAN Availability of Connection

Annual % of time an application has access to its data
through the SAN
Design Considerations: High Performance

Performance as perceived by the end users
Multipathing
Directly linked to the number of paths available in the SAN
architecture - Multipathing enhances performance
Multipathing SW ensures load balancing and path fail-over
Path fail-over impacts performance
Appropriate choice of interconnect technologies

Fault tolerant interconnect devices
QoC Metric 2: Path Minute of SAN Performance Degradation
Equivalent to a port on the interconnect device that is

unavailable for one minute
Used to specify the upper limit in application
requirements specification
Switched Fabric Scaling of Connectivity (MB/S)
Design Considerations: High Bandwidth Scalability

Bandwidth
Scaled with number of ports
connected to backplane of Switch
or director
Inter-switch links scales the

number of ports available
Each ISL link consumes 2 ports
ISLs create additional latency
Reduces bandwidth scalability
Interconnecting Switches and Directors - 1
Interconnecting Switches and Directors - 2
QoC Metric 3: SAN Bandwidth Scalability

Classified according to the topology of SAN
Fabric Switches and Directors

Feature
All critical components except ports are
redundant with automatic internal failover
Director Fabric Switch

Yes
No
(maybe power
and cooling)
All critical components are hot replaceable
Yes
No
(maybe power,
cooling, and
GBICs)
Non-disruptive code loads
Yes
No
Non-disruptive upgrades
Yes
No
Component-level fault isolation
Yes
No
Maximum ports
512
48
SAN QoC Scope

Concise definition to focus exclusively on the network
portion of SAN
Excluded
SAN QoC Classes

QoC
Class
Service
Level
Description
Architecture
Description
Availability of
Connection
(annual uptime)
Performance
Degradation
(annual
path-minutes)
Unspecified
Failure sensitive
(no guarantee) - no redundancy
Variable
(statistical)
Failure resilient
- partially redundant paths
- partially redundant
interconnects
Bandwidth
Scalability
Single point-topoint or single

loop
50,000 annual pathminutes average
Multiple loops,
EPL, and/or
switched fabric
Variable
Failure resilient
99.9% .05%
5000 annual path(deterministic) - fully redundant paths
(8.8 hours average annual
minutes average,
- fully redundant or fault tolerant downtime, cannot exceed cannot exceed 5250
interconnects
13.1 hrs)
Switched fabric
Constant
(deterministic)
Failure tolerant
- fully redundant paths
- fully redundant interconnects
- backbone interconnects fault
tolerant
99.99% minimum
(maximum annual
downtime under 53
minutes)
Switched fabric
with maximum
ports per
backplane
Constant
(deterministic)
Fault tolerant
- fully redundant paths
- fully redundant interconnects
- all interconnects fault tolerant
99.999% minimum
(maximum annual
downtime under 5
minutes)
99% average
(3.7 days average annual
downtime)
500 annual pathminutes maximum
50 annual path-minutes Switched fabric

maximum
with maximum
ports per
backplane
Class 1
Lowest level of SAN service
No Quantitative metrics or Guarantees
Implemented with a point-to-point connection
Scalability
Shared 100MB/Sec path
Class 2
Variable Service level
Metrics defined by statistical averages
Failure resilient
Redundant paths
Availability
99%; 3.7 days of annual down time
Performance degradation
50000 path minutes
Scalability
Multiple 100MB/S paths
Appropriate path failover SW
Implemented with Switches
Class 3
Metrics specified as statistical average with limits
Availability
99.85 to 99.95%; 13.1 hrs to 8.8 hrs of down time
5000 path minutes +/- 5% variation
Scalability
Could be achieved with switched fabric
Redundant fabric switches for the backbone
Redundant peripheral interconnect devices
Complete path redundancy
Director with primary and alternate path on the same director
Class 4
Metrics with tightly defined limits
Availability
99.99%; 53 minutes of annual down time
less than 500 path minutes
Scalability
Large number of ports per backplane
Redundant peripheral interconnect devices
Complete path redundancy
Directors
Class 5
Highest and most consistent level of service
Availability
99.999%; less than 5 min down time per year
Less than 50 path minutes
Scalability
Similar to Class 4
Implemented with redundant directors
SAN Backbone Device QoC
Source: Strategic Research Corporation

Recommended SAN QoC for Common Applications

Define Littles Law?
What is the relationship between IOPS and Response time?
What are the three basic metrics that impact performance of a disk
storage?
What are the layers in the performance stack?
Provide reasons why Storage is an important consideration in
applications
What are the key metrics that define QoC in a SAN?
Define path minutes of SAN performance degradation?
What are the deficiencies of a switch to meet QoC 4 and QoC 5
requirements?
Module Summary
Requirements analysis process
Functional & non-functional requirements
NFR for Storage
Basic metrics for Storage and Storage Interconnect
SMART specification of requirements for Storage
networking
SAN QoC and Class of service
Module 1.4: Case Study
Case Study: Business Value Analysis

Develop a ROI/Business case for Storage networking
with a structured methodology
R-LABS Company Profile

Leading Pharmaceutical company
10 percent annual growth in sales revenues
New product to market every six months versus the industry average
of 27 months
Reducing the time and cost for a drug to travel from the lab to
patients (typically 12 to 15 years)
R-Labs IT organization
Function 1: Responsible for the development, deployment and
support of business applications
Function 2: Responsible for the installation, operation, and
maintenance of the technology infrastructure the applications use
R-Labs Application Roll-out Plan
IT Operation Challenges
Multiple data centers
Many database and Storage administrators
ERP upgrades and new system roll out not meeting the
timeliness requirements of R-Labs
Multiple disaster recovery service subscriptions
Storage Implementation Costs: Proposed Solution

Replace an existing DAS infrastructure (60TB)
Consumption rate 40%
Overall new requirement 200TB

Additional costs
Training
Migration from DAS to SAN
Elimination of maintenance cost for old DAS

infrastructure
See details in Notes section below
IT Operations Savings
Business Impact: ERP Upgrade
Business Impact: CRM Roll-out
Business Impact: SCM Roll-out

Business Value Analysis Case Study
Develop a Business value analysis for the Storage
Networks implementation you have proposed to meet the
requirements
Use the ROI template and determine:
ROI (5 years)
Pay back period
Make a presentation to the board of directors for the

Storage expenditure (10 min), based on your business
value analysis
Module Summary
How to develop an ROI/Business case for Storage
networking with a structured methodology
Section Summary
Key points covered in this section:
Application classification based on degree of connectedness and
performance requirements and how they drive Storage growth
Elements that constitute the TCO in an investment for Storage and
how to compute ROI
Perform Business Value Analysis
Identify functional, non-functional requirements, and stakeholders
for Storage Networking implementation
Quantify requirements in technical and business terms as a first
step towards successful Storage deployment and in the design of an
appropriate solution
Use SMART way to represent requirements for Storage Networking
environment

Storage Networking Design and Management - Session 2

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Storage Networking Design and Management - Session 2

Hochgeladen von

Copyright:

Verfügbare Formate

Storage Networking

Design and Management

Section 1: Business Value & Requirements Analysis

2007 EMC Corporation. All rights reserved.

Module 1.2: Business Value Analysis

Application Classes &

Business Value Analysis

Module 1.3: Requirements Analysis

Module 1.4: Case Study

Business Value & Requirements Analysis

Application Classes and Storage Demands

2007 EMC Corporation. All rights reserved.

Application Classes and Storage Demand

2007 EMC Corporation. All rights reserved.

Data Storage is a means to an end.

Applications generate the need for Storage

2007 EMC Corporation. All rights reserved.

2007 EMC Corporation. All rights reserved.

Demand for Storage Capacity

existing applications and

Selection of vendor comes

Source: Customer interviews; McKinsey and Merrill Lynch

Existing vendors offerings

2007 EMC Corporation. All rights reserved.

Performance & Throughput

Application Classes that Determine Storage

* Multi user applications

* Multi user applications

2007 EMC Corporation. All rights reserved.

Growth Trends for Application Classes

Monitoring and management

Workload scheduling and

Replication and availability

objects and data

2007 EMC Corporation. All rights reserved.

Infrastructure Software Multiplies Data Growth

How data growth is

2007 EMC Corporation. All rights reserved.

Storage Software Addresses Performance Needs

Load balancing and

2007 EMC Corporation. All rights reserved.

Primary Driver for Storage Purchasing Decision

2007 EMC Corporation. All rights reserved.

2007 EMC Corporation. All rights reserved.

Operational Requirements for Application Classes

2007 EMC Corporation. All rights reserved.

Need for Availability

Performance Segment Application Requirements

Heterogeneous network protocol interoperability

Automated back-up and

Automated back-up and

Automated back-up and

Source: Customer interviews; McKinsey and Merrill Lynch

Optimal Storage for Performance Segment

Higher performance segments require successively

2007 EMC Corporation. All rights reserved.

Storage service requirements are expressed in quantities

2007 EMC Corporation. All rights reserved.

Check Your Knowledge

Classification is based on degree of connectedness and

Business Value Analysis

2007 EMC Corporation. All rights reserved.

Economics of Storage Networks

2007 EMC Corporation. All rights reserved.