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

1
STORAGE ARCHITECTURE/MASTERSAN Math for
Core/Edge SANs

• Spicing it Right!
• Norman Owens
• Independent Storage Consultant

2
SAN Math for Core/Edge SANs

• Spicing it Right!

• Preview
• Distinctions between topologies
• 5 critical variables for sizing
  S.P.I.C.E.
• Comparative sizing

3
Distinctions among topologies3 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
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
Why do you have Islands?

• It just happened
• Department/Organizational structure encourages it
• Islands bring stability by limiting scope of SAN
  impacts
• Havent 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?
• PI 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 SAN What 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 vendors 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? Lets 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