Obligatory rubric - MSST Conferencestorageconference.us/2001/presentations/SNIA.pdf · (dbms) File...

1Copyright © 2000 & 2001, Storage Networking Industry Association [work in progress]

Obligatory rubric

• Copyright © 2000 & 2001, Storage Networking Industry Association.

• SNIA-TC members may use this material freely; all others require permission from the SNIA-TC.

Copyright © 2000 & 2001, Storage Networking Industry Association [work in progress]

SNIA shared-storage modelA work in progress …

An architectural overviewApril 2001


Contents

• SNIA Introduction

• The SNIA storage model! Purpose and benefits! Layers, functions, and services

• Applying the SNIA storage model! Common storage architectures

• Conclusions


SNIA Overview

• Open forum! Work Groups open to all members! Public intellectual property policy

• Volunteer organization! Agenda determined by industry and member

interests and participation! 200+ members and growing

• Technical and market development efforts! Technical efforts: primarily a “feeder”

organization to accredited standards organizations


Standards Development Examples

• Fibre Channel HBA-API

• MIBs and CIM extensions for storage! CIM Schemas for Disk Arrays, Media Libraries,

NAS, and Fibre Channel Interconnect Components

• SCSI-3 Extended Copy command! Has been picked up by T10

• NDMP version 4! Work in progress


Interoperability Efforts

• Sponsored Interoperability Demonstrations! HBA-API, Third party copy, FC Switches, etc.! Multiple venues, Multiple vendors

• CIFS initiative! Conference and interoperability

demonstrations

• SNIA Technology Center! Permanent lab and test facilities, fixtures


Contents

• SNIA Introduction

• The SNIA storage model! Purpose and Benefits! Layers, functions, and services

• Applying the SNIA storage model! Common storage architectures

• Conclusions


Shared Storage Model: Purpose

• Present a simple model for shared storage architectures

• Use it to describe common examples graphically

• Expose, for each one:! What services are provided, where! Where interoperability is required! [future] Pros and cons of the architecture


Shared Storage Model: Benefits

• A common “architecture vocabulary”

• Reference comparisons between common solutions

• Help to align the industry! Customers can better structure their choices! Vendors can better explain their differences


What the model is, and what it is not

It is:! A framework that captures the functional

layers and properties of a storage system

It is not:! A specification, an architecture, a design, a

product, a recommendation, or an installation


Classic storage model

Application

Storage domain:“anything goes!”

Network?Appliance?

Data mover?Array?

NAS?

JBOD?


File/record subsystemFile/record subsystem

Database(dbms)

File system(FS)

The SNIA shared storage modelSt

orag

e do

mai

nApplication

Serv

ices

sub

syst

emSe

rvic

es s

ubsy

stem

Dis

cove

ry, m

onito

ring

Dis

cove

ry, m

onito

ring

Res

ourc

e m

gmt,

conf

igur

atio

nR

esou

rce

mgm

t, co

nfig

urat

ion

Secu

rity,

billi

ngSe

curit

y, b

illing

Red

unda

ncy

mgm

t (ba

ckup

, …)

Red

unda

ncy

mgm

t (ba

ckup

, …)

Hig

h av

aila

bilit

y (fa

il-ov

er, …

)H

igh

avai

labi

lity

(fail-

over

, …)

Cap

acity

pla

nnin

gC

apac

ity p

lann

ing

Block subsystemBlock subsystem

Storage devices (disks, …)Storage devices (disks, …)

Block aggregationBlock aggregation

Device-basedblock-aggregation

SN-basedblock-aggregation

Host-basedblock-aggregation


File/record subsystemWhat can be done

• Database management systems! tuples → tables! tables → table-spaces! table-spaces → volume

• File systems! files → volume

• New types! http caches: a kind of distributed file system?


device

File/record subsystemWhere it can be done

• Host-side! file systems and databases! NFS, CIFS, etc. are client-server

splits inside the file system

• SN-based! NAS head

• Device-based! NAS functions in array box

NAS

Hos

t with

NFS

/CIF

Scl

ient

Hos

t with

loca

lFS

/dbm

s


Block subsystemWhat can be done

• Space management! making a large store from many small ones! packing many small stores into one large one

• Striping! for performance (load balancing, throughput)

• Redundancy! full (local & remote mirroring, RAID-1, -10, …)! partial (RAID-3, -4, -5, …)! point-in-time copy


Block subsystemWhere it can be done

• Host-side! logical volume managers! device drivers, HBAs

• SN-based! HBAs, specialized SN appliances

• Device-based! array controllers (e.g., RAID)! disk controllers (e.g., sparing)

Storage devicesStorage devices


SN-based

Host

Device



Database(dbms)

File system(FS)


The SNIA shared storage model:Access path examples



Note: all 8 possible paths can be used!

Note: all 8 possible paths can be used!

Application




The SNIA shared storage modelServices subsystem

Serv

ices

sub

syst

emSe

rvic

es s

ubsy

stem

Application

Dis

cove

ry, m

onito

ring

Dis

cove

ry, m

onito

ring

Res

ourc

e m

gmt,

conf

igur

atio

nR

esou

rce

mgm

t, co

nfig

urat

ion

Secu

rity,

billi

ngSe

curit

y, b

illing

Red

unda

ncy

mgm

t (ba

ckup

, …)

Red

unda

ncy

mgm

t (ba

ckup

, …)

Hig

h av

aila

bilit

y (fa

il-ov

er, …

)H

igh

avai

labi

lity

(fail-

over

, …)

Cap

acity

pla

nnin

gC

apac

ity p

lann

ing



Database(dbms)

File system(fs)


Caching… can be added to almost any layer

Host

. with

LVM

and

softw

are R

AID

File

/reco

rdsu

bsys

tem

Blo

cksu

bsys

tem

Device block-aggregation

SN block-aggregation

Host block-aggregation

Host

NAS head

Host

Host

. with

LVM

Disk array

SN

NAS head

LAN

Ideally, caching only affects performance. But: coherency implications do affect management (protocols, interfaces)

Ideally, caching only affects performance. But: coherency implications do affect management (protocols, interfaces)

Application

Cache

Cache

Cache

Cache

Cacheappliance

Cache


ClusteringIntra-box aggregation

Host

. with

LVM

and

softw

are R

AID

File

/reco

rdsu

bsys

tem

Blo

cksu

bsys

tem




Host

NAS head

Host

Host

. with

LVM

Disk array

SN

NAS head

LAN

Cluster FS

Multi-node LVM

Purposes:• load spreading across peers (scalability)• alternate paths (high availability, scalability)

Purposes:• load spreading across peers (scalability)• alternate paths (high availability, scalability)

Application


SharingContent sharing and resource sharing

Host

with

LVM

File

/reco

rdsu

bsys

tem

Blo

cksu

bsys

tem




Host

with

LVM

Disk array

SN

NAS system

HostHost

LAN

Application

Resource sharing

Array is shared,but LUs are disjoint

Resource sharing

Array is shared,but LUs are disjoint

Data sharing

NAS system is shared – and so are the files

Data sharing

NAS system is shared – and so are the files


? NAS

Q: “SAN” versus “NAS”?A: a poorly-formed question

• Q: hardware: FibreChannel vs Ethernet vs InfiniBand?

• Q: API: blocks vs files (aka “NAS”)vs objects (OSD)?

• Q: protocol: FCP vs TCP/IP vs … ?

• A: (to all the above) it depends …

• Storage network (SN):! any (mostly) dedicated network,

installed (mostly) for storage traffic! whatever the hardware, API, or protocol

“SAN”

FC E’net

iSCSI

File

s B

lock

s

FC E’net

File

s B

lock

s FS/block combo


Some common storage architectures

Mapping the SNIA model onto some current implementations


Direct-attached block storage

Disk array

Host

,no

LVM

File

/reco

rdsu

bsys

tem

Blo

cksu

bsys

tem

Host

. with

LVM

and

softw

are R

AID

Host

wi

th L

VM

Application• Local-attachE.g., SCSI

• Multi-attach box

• Local-attachE.g., SCSI

• Multi-attach box





SN-attached block storage

Disk array

Host

,no

LVM

File

/reco

rdsu

bsys

tem

Blo

cksu

bsys

tem SN

“SN” = any networkused for storage access.E.g., Fibre Channel,Ethernet, …

“SN” = any networkused for storage access.E.g., Fibre Channel,Ethernet, …

Host

with

LVM

Application





SN-attached block storagewith metadata server

Disk array

Host

with

LVM

File

/reco

rdsu

bsys

tem

Blo

cksu

bsys

tem SN

Block-aggregationmetadata server

Host

,no

LVM

Aggregation map(metadata) issupplied by anexternal server

Aggregation map(metadata) issupplied by anexternal server

Application





Block storage aggregation in a SN appliance

Disk array

SN

File

/reco

rdsu

bsys

tem

Blo

cksu

bsys

tem

Aggregationappliance

Host

with

LVM Ho

st,

no L

VM

Application aka “SNvirtualization”Functions: LVM, caching

aka “SNvirtualization”Functions: LVM, caching





Multi-site block storage

Disk array

SNAggregation

appliance

Host

. with

LVM

Application

Disk array


Host

. with

LVM

Application

SN applianceSN appliance

WAN

WAN

Host-to-hostHost-to-host

Functions: point-in-timecopy, caching, local & remote mirroring, …

Functions: point-in-timecopy, caching, local & remote mirroring, …

WAN

Device-to-deviceDevice-to-device





File server

NAS system

HostHost

File

/reco

rdsu

bsys

tem

Blo

cksu

bsys

tem

LAN-attached“NAS” systemMay have SN, blockaggregation, etc,hidden inside the NASsystem box

LAN-attached“NAS” systemMay have SN, blockaggregation, etc,hidden inside the NASsystem box

Application

LAN




privateSN?


File server controller(“NAS head”)

NAS head

Disk array

File

/reco

rdsu

bsys

tem

Blo

cksu

bsys

tem

No storage in thefile server controller box

No storage in thefile server controller box

HostHost

LAN

Application

SN





NAS/file server metadata manager (“asymmetric”)

Disk array

File

/reco

rdsu

bsys

tem

Blo

cksu

bsys

tem

Hosts get file meta-data from FS/NAS controller, thenaccess the data directly

Hosts get file meta-data from FS/NAS controller, thenaccess the data directly

Host

. with

LVM

Filemetadata

Blockaccesses

FS controller canalso be NAS serverFS controller canalso be NAS server

HostLAN

SN

Application




File system metadata


Object-based Storage Device (OSD), CMU NASD

OSDdevice

File

/reco

rdsu

bsys

tem

Blo

cksu

bsys

tem

Host

Object metadata

Host

Application

LAN

Securitymetadata

Filemetadata





Summary & conclusions



Database(dbms)

File system(FS)

The SNIA storage modelSt

orag

e do

mai

n

Serv

ices

sub

syst

emSe

rvic

es s

ubsy

stem

Dis

cove

ry, m

onito

ring

Dis

cove

ry, m

onito

ring

Res

ourc

e m

gmt,

conf

igur

atio

nR

esou

rce

mgm

t, co

nfig

urat

ion

Secu

rity,

billi

ngSe

curit

y, b

illing

Red

unda

ncy

mgm

t (ba

ckup

, …)

Red

unda

ncy

mgm

t (ba

ckup

, …)

Hig

h av

aila

bilit

y (fa

il-ov

er, …

)H

igh

avai

labi

lity

(fail-

over

, …)

Cap

acity

pla

nnin

gC

apac

ity p

lann

ing




Device-basedblock-aggregation

SN-basedblock-aggregation

Host-basedblock-aggregation

Application


Block subsystemSample architectures

Host

. with

LVM

and

softw

are R

AID

1. Direct-attach

Host

. with

LVM

Disk array

SN

2. SN-attach3. SN aggregation


Host

,no

LVM

File

/reco

rdsu

bsys

tem

Blo

cksu

bsys

tem




Application


File/record subsystemSample architectures

Host

. with

LVM

and

softw

are R

AID

1. Direct-attach

File

/reco

rdsu

bsys

tem

Blo

cksu

bsys

tem




NASserver

4. NAS serverHost3. NAS head

NAS head

Host

LANHo

st. w

ith L

VM

Disk array

SN

2. SN-attachApplication


Uses for the model

• Vendors! place products in the space of architectures! clarify product differences

• Customers! understand vendor offerings better

• The industry! basis for common definitions, communication,

understanding, interoperability


Conclusions

• The SNIA shared storage model is both simple and useful! to highlight similarities and differences! as a basis for comparisons

• Still a work in progress! data movers, tape drives, …! better comparisons …! suggestions?

• The SNIA-TC welcomes input:! <[email protected]>


Acknowledgementsand co-conspirators

• John Wilkes, Hewlett-Packard Laboratories! Lead conspirator and tamer of PowerPoint

• Harald Skardal, Network Appliance

• David L. Black, EMC Corporation

• The rest of the SNIA Technical Council! Wayne Rickard (SNIA TC chairperson), Gadzoox! Dave Anderson, Seagate Technology! Jim Carlson, IBM! Garth Gibson, CMU! Kevin Phaup, HighGround Systems! David Thiel, Compaq

Obligatory rubric - MSST Conferencestorageconference.us/2001/presentations/SNIA.pdf · (dbms) File...

Documents

Transcript of Obligatory rubric - MSST Conferencestorageconference.us/2001/presentations/SNIA.pdf · (dbms) File...