virtual instrument webinar 062311 1

8/6/2019 Virtual Instrument Webinar 062311 1

1/32


2/32

2

Agenda

SAN Maturity Model Overview

SMM and Business Value

SMM Levels

Description

Management Characteristics

Steps to SAN Maturity

Measuring SAN Maturity Progress

Q & A


3/32

3

SMM Overview


4/32

4

SAN Maturity Model (SMM) - Introduction

The SAN Maturity Model is a management frameworkdesignedto

systematically improve SAN business valuethroughthe

continuous improvement of people, processes,andtechnology.

The objectives ofthe frameworkareto:

1. Increase the availability and reliability of business applications

2. Drive down the overall number of SAN-related problems3. Optimize the use of SAN capacity and minimize over-provisioning

4. Ensure that the design and capacity of the SAN infrastructure is cost-

effectively aligned with the needs of the business by leveraging

performance-based metrics

Developed by Virtual Instruments and the Enterprise Strategy Group and derived from ESGs

Data Center Efficiency Maturity Model

http://www.virtualinstruments.com/docs/WP_ESG_Brief_Virtual_Instruments_SAN_Maturity_Model.pdf


5/32

5

Background of Maturity Models

Maturity models have been around for over 20 years

Initially develop by the Software Engineering Institute (SEI) in

the late 1980s to address the complexity of large software

development projects

This first model was called the Capability Maturity Model (CMM)

CMM was later revised in the 1990s to CMMI (CMM Integrated)

to reflect the changes in software development

Other more IT-focused maturity models have been developed

over time including: Gartners IT Infrastructure Operations andMaturity Modeland ESGs Data Center Efficiency Maturity Model

In these maturity models, the key elements that must be

developed are: People, Process and Technology


6/32

6

44

QuantitativelyQuantitatively

ManagedManaged

State ofthe SANat Each SMM Level

Business ImpactMeasured

and

IT Optimized

Operational

Excellence

SAN is cleaned

up for a

point-in-timeHELP! You

dont want to

be here

55

OptimizingOptimizing

33

DefinedDefined

22ManagedManaged

11InitialInitial

CHAOS

Point-in-time

stability

Reactive toproblems

Physical layer

issues

addressed

Continuous

stability

Baseline

measured

Monitoring andalerting

Proactively avoid

problems

Applicationsinstrumented and

well-understood

Recurring

application

baselines

Current

infrastructureoptimized

Performance-

based SLAs

Business-

aligned design

and architecture

Infrastructure

optimization

Technology

assessments

Optimized

spending on

future purchases Unmanaged

Many risks

Unsustainable

REACTIVE PROACTIVE TACTICAL

OPTIMIZATION

STRATEGIC

OPTIMIZATION


7/32

7

Things to Considerabout SMM Levels

SMM is an operational framework

Most SANs span multiple levels of SMM

Determining where you are requires measurement

Progress is measured by defining specific KPIs and

measuring and reporting on those KPIs

SMM aligns with ITILs IT Service Management which

focuses on fit for purpose and fit for use IT services

This is not rocket science! Most SAN/storage managers

will recognize these SMM steps and activities.


8/32

8

SMM andBusiness Value


9/32


10/32

10

MaximizingBusiness Valueateach SMM Level

Level 3 Most OpEx savings

Stable, proactively managed SAN; business risksminimized

Personnel efficiency, reduced outages and downtime

Level 4 Defer CapEx by optimizing existing SAN/storage

capacity

Balance existing servers, ISLs and storage targetconnectivity

Performance and response time metrics integrated intoprovisioning processes

Level 5 Performance-based SLAs

Minimize CapEx through optimized infrastructure design

Performance-based tiered storage

Server consolidation and virtualization

Storage consolidation and virtualization

44


ManagedManaged

33

DefinedDefined

55



11/32

11

SMM Levels


12/32

12

Level 1 - Description

SAN is not managed as an important IT asset

High risk during moves/adds/changes

Inconsistent performance and reliability

Time-consuming/costly troubleshooting

Over-provisioned and areas of congestions

Frequent performance and availability issues

11InitialInitial


13/32


14/32

14


Point-in-time SAN stability

Unpredictable behavior during moves/adds changes

Performance and reliability inconsistent

Time-consuming/costly troubleshooting

Over-provisioned and areas of congestion

Performance and availability issues occur regularly

Eventually slips back to Level 1

22ManagedManaged


15/32

15

Level 2 - Management Characteristics

Periodically the SAN is cleaned up

SAN management style is reactive

Problem resolution is hit or miss

Snapshot of SAN workload

No management tools

No workload or performance monitoring

No error monitoring

No alerting of critical SAN events and conditions

22ManagedManaged


16/32

16


Managed as critical IT infrastructure

Storage transaction performance consistent and reliable

Move/adds/changes are low risk and predictable

Reduced problems and downtime

Tool-based troubleshooting and root cause analysis

Less re-work is required

Balanced workload across infrastructure resources

33

DefinedDefined


17/32

17

Appropriate staffing

Culture of continuous improvement

Proactive monitoring and alerting

Performance monitoring of critical applications

Moves/add/changes de-risked

Rapid root and efficient cause analysis

Problem remediation is data-driven

Level 3 Management Characteristics33

DefinedDefined


18/32

18


Focus on workload measurement and optimization

Over-provisioning of infrastructure capacity is reduced

Server virtualization and tiered storage optimization

Regular baselines of utilization

Performance-based service level agreements (SLAs)

Data-driven technology decisions

44


ManagedManaged


19/32

19

Level 4 Management Characteristics

Continuous operational improvement

Data-driven move/adds/changes

Regular workload reporting

Proactive re-balancing of workload

Proactive performance mgmt and capacity planning

44


ManagedManaged


20/32

20


Focus is on SAN capacity and technology alignment

Business-aligned infrastructure

Technology benchmarking

Measurement for consolidation and virtualization projects

Wide-spread adoption of performance-based SLAs

55



21/32

21

Level 5 Management Characteristics

Customized workload and performance data collection

Broad use of response time monitoring and alerting based onSLAs

DesignBuildOperate integration

55



22/32

22

Steps to SAN Maturity


23/32

23

Maturity Steps: Level 1 Level 2

Update inventory of SAN components

Update firmware

Decommission obsolete components

Identify and resolve: physical errors, C3Ds and SCSI errors

Develop a baseline analysis

Remediate areas of congestions

Identify areas of poor performance and remediate

Improve definition of personnel roles and responsibilities


24/32

24


Deploy monitoring and alerting tools

Integrate with Operations mgmt console

Monitor and alert ISL utilization

Define staff roles and responsibilities and train

Develop KPIs to measure progress

Create key periodic reports

Integrate workload metrics in storage provisioning process

Proactively remediate areas of potential congestion

Develop a process for proactive SAN maintenance

Integrate workload metrics in moves/adds/changes processes


25/32

25


Develop repeatable process to avoid congestion

Develop repeatable process to load-balance workload

Develop performance baselines for key applications

Define SLAs for key applications

Develop periodic SLA reports

Develop additional KPIs to track baselines and SLAs


26/32

26


Broaden the use of performance-based SLAs

Develop additional reporting based on business needs

Support technology and benchmarking assessments

Data-based technology and solution design process


27/32

27

Measuring SAN Maturity

Progress


28/32


29/32

29

Key Process Areas

Item KPA Processes Description

1Incident Resolution and Prevention Processes that begin problem

identification, root cause analysis,

resolution and evolve to predicting and

preventing incidents.

2 Performance, Capacity, and

Availability Management

Processes that start with the physical

infrastructure of the SAN up through

performance-utilization tradeoff

management, including availability and

reliability.

3 Measurement and Analysis Processes to measure, monitor and

track the SAN infrastructure, provide

cross functional transparency, and

perform internal and external

benchmarking.

4 Acquisition and Provisioning Processes for acquiring and deploying

assets. Evolve to incorporate better

information on performance, usage,

utilization, and business requirements

to optimize cost QoS tradeoffs.

5 Business Alignment and Financial

Optimization

Processes that ensure SAN optimization

to business requirements, SLAs, and

costs.


30/32

30

Key Performance Indicators

Key Process Area Key Performance

Indicator

Required at SMM

LevelIncident Resolution and

Prevention

KPI Total Number of Trouble Tickets 3

KPI Average Time to Problem

Resolution

3

KPI Average Cost Per Resolved Problem 3

Performance, Capacity,

and Availability

Management

KPI Application downtime/availability 3

KPI Average Application I/O Response

Time

3

KPI Average Utilization per Storage

Target Port

3

Measurement and

Analysis

KPI Number of Servers with a Defined

Baseline SCSI ECT

4


Baseline IOPs Workload

4


Baseline Bandwidth Workload

4

KPI Number of Storage Target Ports

with a Defined Baseline IOPs Workload

4

KPI Number of Storage Target Portswith a Defined Baseline Bandwidth

Workload

4

Acquisition and

Provisioning

KPI Growth Rate of Usable Tier 1 Disk

Capacity

4

KPI Growth Rate of Fibre Channel Ports

Deployed

4

KPI Virtual Machine Density 4

Business Alignment and

Financial Optimization

KPI Number of Applications with

Performance-based SLAs

4


31/32

31

UsingKPIs to Measure Performance

Are the tools in place to measure and track the KPIs? Does a problem management system exist?

How are problems categorized?

How are problem handoffs managed?

Is time-to-resolution accurately tracked?

Is cost-of-resolution accurately tracked?

Is root cause accurately defined?

Are outages properly tracked?

Do before metrics exist?

Can problem tickets be modified to support KPIs?

How is non-problem ticket level-of-effort tracked?


32/32

32

Q & A

virtual instrument webinar 062311 1

Documents