Book Excerpt: Building SANs with Brocade Fabric Switches Page 8 -

Book Excerpt: Building SANs with Brocade Fabric Switches Page 8

By Josh Judd, Chris Beauchamp, Alex Neefus and Benjamin F. Kuo

Establishing Port Requirements

Now you will determine how many switch ports you will need to purchase. (This is a general estimate for calculating ROI; it might be a bit more or less than your final estimate.)

Take the ports you found out about during the interview process. Make sure that you account for all ports on each node. Some RAID arrays have many ports, and many hosts have at least two HBAs. Add up these ports to get the total number of exposed ports your SAN will require. You will then divide this by the number of different fabrics you will be using. If you have dual-redundant fabrics, you will divide by two. If you have triple-redundant fabrics, divide by three, and so on. This will give you the number of required exposed ports per fabric. The number of "overhead" ports you must allocate for ISLs and for unused ports will depend on several factors:

  • The total number of required ports per fabric.

  • The amount of known locality.

  • Your need to manage all switches as a single entity.

  • The physical layout of your SANany MAN/WAN connections, or intra-building campus connections, or intra-floor building connectionsmight dictate use of additional ISLs and less than perfect utilization of the ports on each switch.

  • Your applications' expected performance characteristics.

  • The rate of expected growth in port count of the fabric.

  • Your maintenance policies regarding port usages on network devices. For example, you might require that a certain number of ports be left available for expansion or troubleshooting during the course of normal operation.

  • Simple Case

    If the number of required exposed ports is less than the number of ports on a single switch, you will generally need zero ports for ISLs. In this case, you will require one switch per fabric. However, as larger switches utilize more hardware internally to connect the higher number of user ports, a decision might need to be made between using a larger switch versus utilizing a network of smaller ones. The appropriate decision will depend on performance requirements, budget, and design factors. In addition, if you have made small performance groups that have no components in common, you might be able to localize traffic 100 percent, and require no ISLs. You would have many small, unconnected SAN islands if you follow this approach. One reason not to use isolated islands is that requirements change. Someday you might need access between islands at a moment's notice. A robust architecture can achieve your immediate connectivity requirements, and give you the flexibility to handle change as well.

    You will require each fabric to be a network if this is not the case, or if you wish to design in flexibility to your configuration. You will have to reserve port count for these. Simple case requirements include the following:

  • Fewer ports required than exist on a single switch, or

  • Each performance group is well defined and smaller than the number of ports on a single switch.

  • Future requirements for growth and change are minimal.

  • Assume that you have two 16-port arrays (32 storage ports total), 10 dual-HBA servers (20 ports), and two single-port tape libraries (two ports). Your total port count is 54. However, assume further that you are using a dual-redundant SAN architecture. Your port count per fabric is 27. You are building the fabric out of 16-port switches. It is possible that some ISLs are required. You will need to determine how many are needed.

    Variant A

    With a relatively small fabric like this and relatively high locality, you can assume that you will have about 14 free ports per switch. Two switches with two ISLs between them will yield 28 ports per fabric. You are using a dual-redundant architecture, so there will be two fabrics, for a total of four switches. Your grouping diagram will look like Figure 5.7.

    Figure 5.7 Determining ISL Requirements for Variant A

    This grouping would result in an actual implementation resembling Figure 5.8.

    Figure 5.8 Variant A Implementation

    Variant B

    If you decide that you cannot guarantee the localization of traffic for some reason, grouping will not help. Assuming also that you have a requirement for high performance between the switches, you would add two ISLs per switch to the estimate, for a total of about four ISLs per switch. Your architecture might look Figure 5.9.

    Figure 5.9 Adding ISLs for High Performance in Variant B

    The same technique can be applied to any SAN, no matter how complex. In fact, the larger the SAN, the greater the benefits will be from grouping traffic.

    Moderate Case

    If the required exposed port count is about double or triple the per-switch port count, and some locality is known, you will be able to use very few ISLs. In this case, estimate two ISLs per switch. Let us say that you need 26 ports, and you are using 16-port switches. Two ISLs per switch means that you actually get 14 ports per switch. Two switches will give you 28 ports, so you would budget for two switches per fabric, or four switches total.

    Moderate case requirements include the following:

  • No more than three times as many ports are required than are present on a single switch.

  • Performance groups are reasonably well defined. Some locality is known.

  • Future requirements for growth and change are minimal.

  • Note: The low port count/high locality/low ISL count configurations work well for either two or three switches. Two switches would be cascaded together with two ISLs, with 16-port switches yielding 28 ports. Three switches would be connected in a ring, supporting about 40 devices. If you are over that limit, a four-switch full mesh can support about 50 devices. The full-mesh architecture does not scale well beyond that point, and none of these work well if you have performance groups with more than 13 or 14 members. It is feasible to build ring or partial-mesh topology fabrics with higher port counts, but it is generally better to use a core/edge topology for higher port count solutions. These topologies are explained in detail in Chapter 7.>

    Click here to buy book

    Building SANs with Brocade Fabric Switches

    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.

    Page 8 of 10

    Previous Page
    1 2 3 4 5 6 7 8 9 10
    Next Page

    Comment and Contribute


    (Maximum characters: 1200). You have characters left.



    Storage Daily
    Don't miss an article. Subscribe to our newsletter below.

    Thanks for your registration, follow us on our social networks to keep up-to-date