Book Excerpt: Building SANs with Brocade Fabric Switches Page 4 - EnterpriseStorageForum.com

Book Excerpt: Building SANs with Brocade Fabric Switches Page 4


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

Moving from Business Requirements to Technical Requirements

Which SAN-Enabled Applications Do You Have in Mind?

Will the SAN use a serverless backup application? How about clustering software? How about volume management? This category of software requires special attention because of its close ties to the SAN hardware you choose to build the solution. For example, if you plan to use vendor X serverless backup software, you must make sure that your backup hardware (tape libraries, Fibre Channel/SCSI gateways, etc.) is supported.

Which Components of the Solution Already Exist?

Any hardware or software that is already in place and that must be included in the solution will create points for you to build around. You must find out as many details as possible about everything in this category. When you are finished with the interviews, and conduct the physical assessment, you should personally inspect every piece of hardware. This will prevent surprises later in the process. Make sure that you find out exactly where all hardware is located, and how to access it.

You must pay special attention to devices that already exist and already have Fibre Channel interfaces. Find out which kinds of HBAs are installed in hosts, and which driver revisions are installed on them. Find out code levels for RAID arrays and Fibre Channel tape libraries. Find out if upgrades to driver/code levels are planned or at least allowed.

Note: You must know if each device is public loop, private loop, or full fabric. Some devices might even be SCSI and require additional hardware to bridge between SCSI and Fibre Channel.

If possible, you should not use private loop drivers on initiators unless the device does not support fabric drivers or is not easy to upgrade. Private loop hosts require special licenses, typically Brocade QuickLoop and Zoning. Find out if the existing devices are configured as full-fabric devices. If not, find out if their drivers support full fabric, or if they can be upgraded to full fabric. This is not intended to discourage incorporation of private loop devices into a fabric: QuickLoop and Fabric Assist exist specifically to enable this to occur. However, if a device can support full fabric, then integration into the SAN will be easier if it does so.

Which Components Are Already in Production?

Components that are in production require special attention in two areas:

  • Duplicate equipment might be desired for testing.


  • The transition phase is more complex.


  • It is vital to know as much as possible about production systems that are going to transition onto the SAN. Therefore, somebody intimately familiar with and responsible for every such system should be included on the core team.

    Which Elements of the Solution Need to Be Prototyped and Tested?

    For relatively simple solutions that involve only components already certified to work together, it might be that you do not have to do any testing at all. For example, if you are implementing a SAN-based solution on a Brocade SOLUTIONware document, you might feel that you need only to do minimal validation. This is opposed to a solution where no documentation or testing information exists, which generally requires extensive validation.

    For more complex solutions involving a large number of devices that might be from many different vendors, you might feel that every single element needs to be tested in combination before release to production can occur. You should get input on this from every member of the core team. If any team member feels that you should conduct inhouse testing on a component, you should strongly consider doing so.

    What Equipment Will Be Available for Testing?

    Any existing equipment that is not in production, and any equipment that is going to be purchased specifically for this project might be good material with which to build a test bed. Existing equipment that is in production is not good to test with. If existing equipment already in production will be transitioned onto the SAN, it might be beneficial to budget for a representative sample of duplicate, nonproduction systems with which to prototype the solution. It is generally a good idea to have such systems available for testing in any case. It may also be possible to borrow systems to test with. In any case, it's probably worth asking your vendors for such loans.

    Whether or not test equipment is available, you should research what testing third-party vendors or third-party organizations have already done. In this way, you will avoid duplicating their efforts. If you cannot get representative test equipment for an element that needs to be prototyped, it might be acceptableand necessaryto rely entirely upon the work done by others to validate the solution.

    Again, with many solutions, this is a perfectly acceptable way to go. If you do not feel that inhouse testing is warranted, then you can save time and money by skipping the prototype and test phase. Just make sure that you have documentation certifying the solution before you make this decision.

    How and When Are Backups to Be Done?

    You need to get a list of everything that relates to the system's backups:

  • What backup hardware will be used?


  • What backup software will be used for each host?


  • Which storage arrays will be backed up by which tape libraries?


  • When will these backups occur?


  • How long can they take?


  • How much data needs to be backed up?


  • Will snapshots be used? How do they work?


  • Will split mirrors be used? How do they work?


  • What Will Be the Traffic Patterns in the Solution?

    You should produce a matrix showing every initiator-to-target communication expected in the SAN. This is necessary to determine performance characteristics, and to set up zoning on the fabric:

  • Which hosts will use a specific storage array?


  • Which hosts in a cluster will talk directly to each other over the SAN?


  • Which backup devices will be performing serverless backups?


  • Which arrays will they be backing up?


  • Create a table listing every device on the SAN that can act as an initiator in one column. This will include every host, every storage virtualization product, and every serverless backup server. It might include storage arrays, if they have data replication capabilities. Then put a second column next to it with all of the targets that each initiator will communicate with (Table 5.1).

    Table 5.1 Initiator-to-Target Mapping

    SAN Traffic Patterns

     

    Initiators

    Targets

    host1

    array3

    host2

    array1

    array2

    tape1

    host3

    array1

    host4

    array1

    array2

    tape1

    array1

    array3

    array3

    array4

    array3

    array4

    Note: that some devices on a SAN can act as both an initiator and a target. If so, they will appear in both columns. See array3 and array4 in Table 5.1. This is how you would indicate that array3 and array4 perform data replication between them.

    You will not necessarily be able to build this table by interviewing one person; it will likely be developed over the course of the interview process, changed as the implementation takes place, and maintained for the life of the SAN.

    What Do We Know about Current Performance Characteristics?

    Any devices that currently exist, and will be transitioned onto the SAN, are candidates for empirical performance testing.

    Create a second set of columns next to the traffic pattern columns, as shown in Table 5.2. You will need entries for peak utilization and sustained utilization. Obviously, you will only be able to enter current data for initiators that already exist, and already communicate with the same targets they will talk to after the SAN is complete.

    Table 5.2 Current Traffic

    SAN Traffic Patterns

    Current Peak

    Current Sustain

    Initiators

    Targets

    MB/sec

    MB/sec

    host1

    array3

    10

    5

    host2

    array1

    array2

    tape1

     

     

    host3

    array1

    50

    10

    host4

    array1

    array2

     

     

    tape1

    array1

    array3

     

     

    array3

    array4

     

     

    array4

    array3

     

     

    In this example, host1 and host3 already exist, and are already talking to array3 and array1, respectively. All of the other devices are to be added, are not talking to the same targets that they will be after the SAN is up, or performance data might simply be unavailable.

    If the owner of a system has already done this kind of analysis, you will simply transfer the numbers to your table. If not, you should work with the owner to get the performance information, as this might have a substantial impact on your SAN design.

    Click here to buy book

    Building SANs with Brocade Fabric Switches

    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.


    Page 4 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