Book Excerpt: Building SANs with Brocade Fabric Switches Page 7
Download the authoritative guide: Enterprise Data Storage 2018: Optimizing Your Storage Infrastructure
By Josh Judd, Chris Beauchamp, Alex Neefus and Benjamin F. Kuo
Analyzing the Collected Data
Now that you have collected information from all key stakeholders in the project, and verified the accuracy of this information, you will analyze it to determine the characteristics of the required solution. When you have completed this process, you will have a list of technical requirements, and an ROI analysis to justify the project.
Processing What You Have Collected
You have a matrix detailing communication between nodes. Attempt to group the nodes by communication patterns. The purpose of this is to determine the amount of known locality in the SAN. Locality of reference is a concept prevalent in many areas of computer science, from disk drive construction to LAN design. Locality is important in SAN design because if you can localize traffic into specific areas of a SAN, you directly improve the SAN's performance and reliability. This will allow a more cost-effective SAN design as well, preventing over-designing the network to handle nonexistent cross traffic. Locality is discussed in greater detail in Chapter 7.
A SAN with a great deal of known locality might be constructed out of many separate fabrics, with no ISLs whatsoever. A SAN with little or no known locality might require a high-performance ISL architecture (Table 5.4).
Table 5.4
Initiatorto-Target Mapping for Locality Example
SAN Traffic Patterns
Initiators
Targets
host1
array3
host2
array1
array2
tape1
host3
array1
host4
array1
array2
tape1
array1
array3
array3
array4
array4
array3
In Table 5.4, array3 would be grouped with host1,
tape1, and array4. None of those devices will need to communicate with any of
the other devices. They could be grouped onto a single switch, or even put onto
a totally separate fabric. You might find it helpful to do the grouping in a diagram.
For another example, look at Figure 5.2.
Figure 5.2 SAN
Diagram without Grouping Nothing is known about the communication patterns in
this SAN. Consequently, there is no way to optimize ISLs for performance. After
grouping the initiators with their targets, the SAN diagram could look
something like Figure 5.3. If you look carefully, you will notice that there
are only 12 connections into this SAN. If there are fewer connections than
there are ports in your switches, you do not really need to go through the
grouping exercise because localization of traffic will happen automatically. It
is only useful if you will be using ISLs; however, as most systems scale well
past the size of the largest switches available, it will be a frequent
exercise. For the purposes of making the examples more readable, we will just
assume that they are all dealing with a subset of the devices that the SAN will
support.
Figure 5.3 SAN
Diagram with Simple Grouping Making a diagram such as this will allow you to see
at a glance what the communication patterns for your SAN are.
This example is simplistic, and in large SANs, there
will likely be conflicts. When you cannot effectively group all of the
communication patterns, you should focus on grouping faster performing devices.
For example, if you find that the bulk of traffic will be between host1,
array3, and array4, these could be grouped separately from tape1 and host2 if
necessary. This could happen if you find that there are so many
interrelationships that you end up with very many devices, but very few very
large groups. The grouping technique does not help for performance if you only
have one big group. It could also happen if you have a few devices that are
shared by a great many devices, such as a large RAID array in a storage
consolidation solution.
Another way to combat this "group growth" problem is
to account for multiple interfaces on storage arrays. Let us say that you have
a redundant fabric architecture. Your RAID array has eight interfaces, and each
host will access only two of themone interface on each fabric. List each
interface on the array separately in your traffic pattern table. Then, you
associate servers or groups of servers with specific interfaces. With the array
listed as a single entity, a diagram of the communication could look something
like Figure 5.4.
Figure 5.4 SAN
Grouping Diagram with Single-Entity Arrays If, however, you separate the interfaces, your
diagram could look more like Figure 5.5.
Figure 5.5 SAN
Grouping Diagram with Separated Interfaces
You can indicate that a device crosses groups but
does not need much in the way of performance by varying the line color, weight,
or pattern. Figure 5.6 shows that the tape robot crosses all groups, but does not
need much bandwidth.
Figure 5.6 SAN
Grouping Diagram with Tape Robot Addition If you are able to make relatively small performance
groups, your SAN will benefit greatly from applying the principal of locality.
For now, you simply need to be able to determine the category of architecture
you will require: one that has lots of known locality (has well-defined
performance groups), or one that does not. This will affect how many switch
ports you need to allot for ISLs. If traffic is localized within an area of the
SAN, it will obviously not need to make use of ISLs leaving that area. In this
case, you will be able to get superior performance even with far fewer ISLs,
resulting in more ports available for servers and storage.
Authors
Josh Judd is a Senior SAN Architect with Brocade Communications Systems, Inc. In addition to writing technical literature, he provides senior-level strategic support for major OEMs and end-users of Brocade storage network products worldwide. Chris Beauchamp (Brocade CFP, CSD) is a Senior SAN Architect for Brocade Communication Systems, Inc. Chris focuses on SAN design and architecture, with an emphasis on scalability and troubleshooting. Alex Neefus is the Lead Interoperability Test Engineer at Lamprey Networks, Inc. Alex has worked on developing testing tools for the SANmark program hosted by the FCIA. Benjamin F. Kuo is a Software Development Manager at TROIKA Networks. Headquartered in Westlake Village, CA, TROIKA Networks is a developer of Fibre Channel Host Bus Adapters, dynamic multipathing, and management software for Storage Area Networks.
Comment and Contribute
