Book Excerpt: Building SANs with Brocade Fabric Switches Page 7

---

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	Related Articles Buying Guide: All-Flash Storage Dell EMC Debuts SCv3000 Midrange Storage Arrays with High-End Features Top 10 Tips for Software-Defined Storage Deployment Vexata Raises $54 Million, Launches Active Data Fabric 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.

Click here to buy book

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.