1 / 33

STORAGE ARCHITECTURE/ MASTER: SAN Math for Core/Edge SANs

STORAGE ARCHITECTURE/ MASTER: SAN Math for Core/Edge SANs. Spicing it Right! Norman Owens Independent Storage Consultant. SAN Math for Core/Edge SANs. Preview Distinctions between topologies 5 critical variables for sizing: S.P.I.C.E. Comparative sizing.

jennelle
Download Presentation

STORAGE ARCHITECTURE/ MASTER: SAN Math for Core/Edge SANs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. STORAGE ARCHITECTURE/MASTER:SAN Math for Core/Edge SANs Spicing it Right! Norman Owens Independent Storage Consultant

  2. SAN Math for Core/Edge SANs • Preview • Distinctions between topologies • 5 critical variables for sizing: S.P.I.C.E. • Comparative sizing Spicing it Right!

  3. Distinctions among topologies:3 topology types • Starting point: Island(s) of SAN • A scaling design: Collocated SAN or “CoLo SAN” • A scaling design: Core/Edge SAN

  4. A SAN entry point Island(s) of SAN A starting point. Buy edge switches and disk as needed.

  5. A scaling design: CoLo SAN A CoLo SAN Cluster servers and their storage in functional units on edge switches. Same as Islands but with Director added for the “any-to-any” connections.

  6. A scaling design: Core/Edge SAN A Core/Edge SAN Place storage and critical servers on Director class switches and put all regular servers on edge switches.

  7. 0/0 Topology types: Which best describes your SAN plans? • Mostly Islands of SANs • Moving to Core/Edge with some Islands remaining • Moving to CoLo with some Islands remaining • Plan to link islands with tools outside of simple fibre channel connectivity • Meshing Directors together with few edge switches

  8. 0/0 Why do you have Islands? • It just happened • Department/Organizational structure encourages it • Islands bring stability by limiting scope of SAN impacts • Haven’t found an ROI for consolidation • We balance consolidation and islands depending on tiers of service

  9. Core/Edge is better for disk • The edge switch is not as highly available as a director-class switch, so why put the most expensive component, the disk frame, on an edge switch? • The CoLo SAN isolates disk frames within functional groupings of servers. This is akin to the limitation of direct-attached storage, except, in this case, a group of servers rather than a single server “owns” the storage. • The CoLo SAN presents other scalability issues such as the limitation of the number of ports in the edge switch.

  10. 5 Critical variables for sizing: SPICE

  11. The “SPICE” variables for sizing Core/Edge SANs S : How many SAN servers are needed? P : How many regular servers will share a storage port? I : How many regular servers will share an ISL between the edge switch and the director? C : How many ports are on a director/core switch? E : How many ports are on an edge switch? P&I are most dependent upon your applications.

  12. The SPICE variables P How servers share a storage port? I How servers share an ISL? C How ports are on the director/core switch? E How ports are on the edge switch? S How many SAN servers are needed? SPICE S = 28 P = 7 I = 7 C = 140 E = 16

  13. The finer spicing “P” = “I” Why? The goal is to fully utilize a storage port; therefore, the total bandwidth coming across the ISLs to that storage port will be equal to the bandwidth between the storage port and the director class switch. So, if 10 servers can fill a storage port pipe then they will also fill 1 ISL.

  14. SPICE math for sizing* S = Number of servers P = I , or “PI” Number of ISLs = ( S / PI ) Number of storage ports = ( S / PI ) Number of edge switches = (S + (S/PI) ) / E Server capacity of core switch = ( C / 2 ) * PI * Round up for each division

  15. SPICEWhat is the practical effect of “PI”? Helps with charge-back. Provides a metric for separating the hog servers from the regulars, and perhaps charging more for hogs. It can be set higher than your Islands of SANs’ value but lower than what will probably be achieved. Thus, the migration can be properly budgeted and reports a moderately easy success. Following migration the production team can further refine the figure to a higher value.

  16. SPICE for new Core/Edge SANWhat is your S and P/I? • “S” is easy: How many servers do you want to have on the Core/Edge SAN when you declare a migration milestone? A question of project scope! • “PI” is harder • Use existing SAN Island as a baseline but you can probably do better • Use storage utilization metrics from critical non-SAN servers that will migrate • Rely on vendor’s experience • LOW estimates are easier to achieve

  17. Comparative sizing

  18. SPICE and 3 vendor comparisons • Brocade • Cisco • McData

  19. SPICE for new Core/Edge SAN What is your start point? Let’s assume: PI = 7

  20. Core/Edge SAN Building Block Brocade Brocade 3900 E = 32 ports per edge switch Brocade 24000 C = 128 ports per Core/Director switch

  21. How many servers are supported by 1 Brocade edge switch? Answer: = ( (E / ( I + 1 ) ) * I = ( (32 / ( 7 + 1 ) ) * 7 = 28 Servers (see next slide)

  22. How many servers are supported by 1 Brocade edge switch? Answer = E - ( E / ( PI + 1 ) ) Answer = 32 – ( 32 / ( 7 + 1 ) ) Answer = 28

  23. How many servers could 1 Brocade Director support with this SPICE? Answer = ( C /2 ) * PI Answer = ( 128 /2 ) * 7 Answer = 448

  24. Core/Edge SAN building block CISCO Cisco 9140 E = 40 ports per edge switch Cisco 9509 C = 112 ports per Core/Director switch

  25. Core/Edge SAN building block CISCO C = 112 ports per Core/Director switch A caveat Fully-populated, the 9509 can hold 224 ports if 32-port blades are placed in all 7 slots. An assumption in my Core/Edge model is that you want to drive ISLs and storage points to maximum bandwidths which requires a non-blocking architecture. The 32-port blades can be very useful for attaching lesser performing devices directly into the core, but in this case the core switch takes on roles that the Core/Edge model would delegate to the Edge switches.

  26. How many servers are supported by 1 Cisco edge switch? Answer: = ( (E / ( I + 1 ) ) * I = ( (40 / ( 7 + 1 ) ) * 7 = 35 Servers (see next slide)

  27. How many servers are supported by 1 Cisco edge switch? Answer = E - ( E / ( PI + 1 ) ) Answer = 40 – ( 40 / ( 7 + 1 ) ) Answer = 35

  28. How many servers could 1 Cisco Director support with this SPICE? Answer = ( C /2 ) * PI Answer = ( 112 /2 ) * 7 Answer = 392

  29. Core/Edge SAN building block McDATA McData 4500 E = 24 ports per edge switch McData 6140 C = 140 ports per Core/Director switch

  30. How many servers are supported by 1 McData edge switch? Answer: = ( (E / ( I + 1 ) ) * I = ( (24 / ( 7 + 1 ) ) * 7 = 21 Servers (see next slide)

  31. How many servers are supported by 1 McData edge switch? Answer = E - ( E / ( PI + 1 ) ) Answer = 24 – ( 24 / ( 7 + 1 ) ) Answer = 21

  32. How many servers could 1 McData Director support with this SPICE? Answer = ( C /2 ) * PI Answer = ( 140 /2 ) * 7 Answer = 490

  33. SAN math for a Core/Edge SANs • Conclusions • A Core/Edge SAN has advantages for disk SANs • Sizing for a Core/Edge SAN is dependent on only 2 variables under your control ( # of servers and PI or the fan-out ratio ) • Once you have determined your SAN goals and set these 2 variables, then you can work up a bill of materials from your switch vendors rather than relying on their design/sales team

More Related