2. Track 4: How to build trouble-free large SANs up to thousand(s) of ports Dragon Slayer Consulting Marc Staimer, President & CDS marcstaimer@earthlink.net 26 April 2004

3. Agenda SAN Definition 2004 Current Large SAN Architectures Issues w/current architectures Eliminating SAN Scaling pain Summary

4. 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

5. SAN Definition 2004

6. 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.

7. Large SAN Architectures Traditional (a.k.a. Victorian) Planned/Gated Communities Urban Sprawl

8. 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

9. Traditional: a.k.a. Victorian Mesh Switch-switch interconnect Core-to-edge Guaranteed hop count & latency Dual fabric typical for both

10. Issues with Traditional Approaches Change management Guaranteed bandwidth Fabric disruption propagation

11. 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

12. Guaranteed Bandwidth Lack of user definable QoS Some applications have higher priorities than others

13. Fabric Disruption Propagation Fabric disruptions anywhere… …propagate throughout the fabric everywhere RSCNs  Zone changes, add switches or HBAs

14. 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

15. Issues with SAN Islands Limits SAN benefits Storage consolidation limited by island Management touches expand

16. 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

17. Fabric Disruptions RSCNs Switch, HBA, Zoning Changes Market requirement < fabric disrupts

18. 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

19. SAN Database Bloat As fabrics get larger FSPF databases get larger…and slower Name services get larger…and slower Market requirement Keep databases small

20. QoS Policy based bandwidth matching Providing each application bandwidth based on User defined requirements and thresholds Market requirement Optimize bandwidth Not to waste it

21. 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

22. Correlating Storage Provisioning, SANs, & policies Efficient storage mgt = < SAN Market requirements include One interface for both storage &and SAN mgt Policy based Enforcement capable

23. Troubleshooting Market requirements include Make it brain-dead simple Make it quick Make it easy AND cheap

24. Audience Response By 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

25. 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

26. HBA RSCN Switch Suppression Stops unimportant HBA RSCN disruptions From disrupting other HBAs Significantly < zoning requirements Vendors include QLogic McDATA RSCN RSCN RSCN

27. 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

28. 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 B SAN Fabric A VSAN 2 VSAN 1

29. 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  8100 SAN Fabric C SAN Fabric B SAN Fabric A VSAN 2 VSAN 1

30. 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)

31. 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 OLTP100MB/s Migration25MB/s Warehouse35MB/s Email30MB/s

32. System Area Management: SAM SRM + 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

33. Easier Troubleshooting Tools Simplified Problem isolation Problem resolution Performance issues Vendors include Cisco  SPAN, rSPAN SANdial  Network Performance Analyzer

34. 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

35. Conclusion SAN Scaling today is painful New generation software & hardware Provides pain relief Test & verify

36. Thank you. Questions?

37. Mr. Staimer will be available in the Ask-the-Expert booth in the Exhibit Hall: Monday 5-6 PM