Track 4: How to build trouble-free large SANs up to thousand(s) of ports
Dragon Slayer ConsultingMarc Staimer, President & CDS [email protected] 26 April 2004
Agenda
SAN Definition 2004
Current Large SAN Architectures
Issues w/current architectures
Eliminating SAN Scaling pain
Summary
Dragon Slayer Background
7 yrs sales
7 yrs sales mgt
10 yrs marketing & bus dev
• Storage & SANs
• 6 years consulting
Launched or participated
• 20 products
Paid Consulting
• > 70 vendors
Unpaid Consulting
• > 200 end users
Known Industry Expert
• Speak ~ 5 events/yr
• Write ~ 3 trade
articles/yr
SAN Definition 2004
T he interconnection of multiple server initiators across ahigh speed switched fabric to one or more target storagedevices.
Audience Response
Raise your hand if you now have or plan to have
within 12 months an all-encompassing SAN
infrastructure into the thousands of ports.
Large SAN Architectures
Traditional (a.k.a. Victorian)
Planned/Gated Communities
Urban Sprawl
Audience Response
By a show of hands, what SAN architecture have you
implemented?
1. Core-to-edge
2. Mesh
3. SAN Islands
4. Not sure
Traditional: a.k.a. VictorianMesh
• Switch-switch interconnect
Core-to-edge
• Guaranteed hop count & latency
Dual fabric typical for both
Issues with Traditional Approaches
Change management
Guaranteed bandwidth
Fabric disruption propagation
Change Management
Change “No” management
• Lot of coordination
Servers, storage, SAN, cables & facilities
• Re-architecting
Switch ports have to be reallocated for ISLs
Zones, cabling, and LUN masking must be redone
• Followed up with shakedown & troubleshooting
Sometimes requiring back out of the change
Guaranteed Bandwidth
Lack of user definable QoS
• Some applications have higher priorities than others
Fabric Disruption PropagationFabric disruptions anywhere…
• …propagate throughout the fabric everywhere
• RSCNs
Zone changes, add switches or HBAs
Traditional Approaches have led to Urban Sprawl: a.k.a SAN Islands
IT is dynamic
• Most organizations do not plan well
Minimizes disruption effects of change
• Doesn’t eliminate disruptions
This becomes…
…this
Issues with SAN Islands
Limits SAN benefits
• Storage consolidation limited by island
• Management touches expand
Eliminating SAN Scaling Pain: The Market Requirements
Fabric disruptions
Large fabric latency
• Intra-fabric switch ASIC hops
Database bloat
QoS
Change management
Correlating storage provisioning, SANs, & policies
Troubleshooting
Fabric Disruptions
RSCNs
• Switch, HBA, Zoning
Changes
Market requirement
• < fabric disrupts
Intra-Fabric Switch ASIC hops
Hop number affects latency
• Latency is cumulative
• Affects end user response times
Users demand predictability
• Mesh and/or SAN islands = unpredictable Locality = predictability again
• Core-edge = predictable
Market requirement
• Minimize latency
SAN Database BloatAs fabrics get larger
• FSPF databases get larger…and slower
• Name services get larger…and slower
Market requirement
• Keep databases small
QoS
Policy based bandwidth matching
• Providing each application bandwidth based on
• User defined requirements and thresholds
Market requirement
• Optimize bandwidth
• Not to waste it
Change Management
Market requirements include
• Automation
• Negative impact minimization
• Audit trail
• Change simulation, planning, & validation
• Correlation of LUN maps, zones, pathing policies
• Work plans for all of the departments involved
• Simple, “brain dead” trouble shooting
Correlating Storage Provisioning, SANs, & policies
Efficient storage mgt = < SAN
Market requirements include
• One interface for both storage &and SAN mgt
• Policy based
• Enforcement capable
Troubleshooting
Market requirements include
• Make it brain-dead simple
• Make it quick
• Make it easy AND cheap
Audience ResponseBy a show of hands, which is your worst SAN scaling pain?
1. Fabric disruptions
2. Large fabric latency
3. Database bloat
4. QoS
5. Change management
6. Storage, SANs, policies correlation
7. Troubleshooting
Solutions that Eliminate SAN Scaling Pain
HBA RSCN switch suppression
Automated change mgt software
SAN Masking-a.k.a. SAN routing
SAN segmentation
• Planned communities
QoS
SAM
Troubleshooting tools
HBA RSCN Switch SuppressionStops unimportant HBA RSCN disruptions
• From disrupting other HBAs
• Significantly < zoning requirements
Vendors include
• QLogic
• McDATA RSCNRSCNRSCNRSCN
RSCNRSCN
Automated Change Management Software
Plan Change
Predicts Impact
Implements Change
Validates Change
Logs Change History
Correlates
• Storage & SAN
changes
• LUNs
• Zones
• Pathing Policies
Vendors include
• Onaro
SAN Masking-a.k.a. SAN Routing Analogous to LUN masking
Routes specific data
• Between SAN islands
• Visibility between specific WWNs
Eliminates disruptions
• Between SAN islands
Increases SAN scalability
• > switches from 239 to 57,121
Simplifies management
• Both ongoing & change mgt.
• Heterogeneous SANs
• Address translation (domain & WWN)
• Eliminates ATL forced fabric merges
• Increases availability SAN Fabric C
SAN Fabric BSAN Fabric A
VSA
N 2
VS
AN
1
SAN Masking continued Works over FC
• And IP networks
• iFCP and FCIP
Vendors include
• McDATA
Eclipse/IPS
• Cisco
MDS:VSAN Routing
• Brocade
Multiprotocol Router
• LightSand
8100SAN Fabric C
SAN Fabric BSAN Fabric A
VSA
N 2
VS
AN
1
SAN Segmentation: a.k.a. Planned Communities
Analogous to large storage controller
• Start large & subdivide
One physical fabric
• Many logical ones
Vendors include
• Cisco MDS:VSANs
• McDATA Dynamic Partitioning
• CNT (04)
Quality of Service: QoS SAN throughput allocation
Based on IT priorities
Policy based
Recognizes App performance
• Requirements differ
• OLTP > than data migration, etc.
Vendors include
• SANdial: Shadow 1400 Inter & intra-switch
• Cisco: MDS Intra-switch
• McDATA (04)
• CNT (04)
QoS
OLTP 100MB/s
Migration 25MB/s
Warehouse 35MB/s
Email 30MB/s
System Area Management: SAMSRM + SAN mgt
• Storage Provisioning
• Block & File
• Heterogeneous
• Policy based mgt
• Policy enforcement tools
• One look & feel
App performance mgt
Optimizes ecosystem
Vendors include
• EMC
• Softek
• AppIQ
• HP
• IBM
• Creekpath
• VERITAS
• Storability
• TekTools
• CA
Easier Troubleshooting ToolsSimplified
• Problem isolation
• Problem resolution
• Performance issues
Vendors include
• Cisco
SPAN, rSPAN
• SANdial
Network Performance
Analyzer
How Big Can SANs Grow? Switches
• Currently up to 256 ports
Up to 1024 2H 2004
Fabrics
• Traditional
239 switches
• 239 x 256 = > 61K ports
• Theoretical (new technologies)
239 switch domains
239 switches/domain
256 ports/switch
= > 14M ports
Conclusion
SAN Scaling today is painful
New generation software & hardware
• Provides pain relief
Test & verify
Thank you. Questions?
Mr. Staimer will be available in the
Ask-the-Expert booth in the Exhibit Hall:
Monday 5-6 PM
Top Related