Book Excerpt: Building SANs with Brocade Fabric Switches Page 9


Want the latest storage insights?

Download the authoritative guide: Enterprise Data Storage 2018: Optimizing Your Storage Infrastructure

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

Complex Case

If you need more ports than one of these configurations will handle, you will need to allocate about four ISLs per switch. You might use fewer than four ISLs on some switches, and perhaps nothing but ISLs will be present on other switches. In the complex case for port count estimates, the intent is to average the ISL requirements.

Until a detailed architecture is developed, you will have to make general estimates for a few things. If you have any distance requirements, add two ISLs per switch. If you have very high-performance requirements, and very little known locality, add two ISLs per switch.

Take the estimated number of ISLs per switch (I) and subtract it from the number of ports per switch (PS). Divide the total required ports per fabric (P) by this number and round up. This is the estimated number of switches (S) that you need to budget for. For estimating complex SAN switch counts, S=P/(PS I).

For example, if you have a need for 30 ports per fabric (P=30), are using 16-port switches (PS=16), and each switch will use about two ISLs (I=2), then the number of switches you estimate needing per fabric is 30/(162). This is 2.14, which rounds up to 3. If you have a single fabric, this is the number of switches you should budget for. If you have a dual-fabric SAN, you should budget for six switches. Complex case requirements include the following:

  • Any number of exposed ports might be required.

  • Performance groups might or might not be defined.

  • Future requirements for growth and change are significant.

  • Preparing an ROI Analysis

    In any business transaction, it is important to understand the economic benefits or the Return On Investment (ROI) that your company will receive. Preparing an ROI analysis for your SAN project will show how your company will not only return the capital investment, but also save additional money as well in time, management, and other efficiencies.

    During the interview process, you made a list of all of the equipment that you would need to purchase. To begin the ROI analysis of your SAN, determine which components are specific to the SAN project. For example, if your company will need to buy additional storage arrays whether or not a SAN is used, these would not be included on the expense side of the analysis. If the SAN is expected to prevent you from having to buy an array, this cost savings would go onto the benefit side of the analysis. You should include any hardware you intend to buy for testing that will not be used elsewhere.

    When accounting for staff time spent on the project, make sure that you only charge the project for time spent beyond what would be spent by not building the SAN. If you are expected to save staff time in the long run, apply this to the benefit side. Your ROI analysis will be a living document, and will be updated as the SAN project develops.

    The Return On Investment Proposition

    Technical justifications for SAN infrastructure deployments can often be made more credible by adding an ROI analysis for the proposed implementation. Follow the guide in the following sections to produce an ROI analysis based on SAN solutions to particular problems.

    Step One: Pick a Theme or Scenario

    Most implementations have a purpose. That purpose could be a server or storage consolidation to improve infrastructure usage and gain economies of scale, ensuring storage and server resources are utilized in the most cost-effective manner. High-availability clustering can improve the availability of mission-critical applications, thus ensuring business continuance and the cost saving associated with it. SAN-based backup deployments improve data integrity by performing backups and restores more efficiently and quickly, again saving in business continuance time and effort.

    Step Two: Identify the Affected Infrastructure Components

    Most SAN deployments will focus on affected servers. Servers can be grouped according to the applications they run or the functional areas they support. Examples of application groupings include Web servers, file and print servers, messaging servers, database servers, and application servers. Functional support servers might include financial and personnel systems or engineering applications. Once the server groups are known, get the characteristics of servers in each group. For example, if your solution fits into a storage consolidation theme, you should consider factors such as:

  • Amount of attached disk storage

  • Storage growth rates

  • Storage space reserved for growth (headroom)

  • Availability requirements

  • Server downtime and an associated downtime cost

  • Server hardware and software costs

  • Maintenance costs

  • The administration effort required to keep the servers up and running

  • Step Three: Identify the SAN-Enabled Benefits

    The scenario approach allows you to focus more closely on the benefits. Server and storage consolidation, for example, will concentrate on benefits accrued from more efficient use of server and storage resources, improved staff productivity, lower platform costs, and better use of the infrastructure. Simply take the list of characteristics you developed in step two, and show how a SAN can provide benefits in those areas. Establishing specific cost savings is one of the two key elements in the ROI process, so be sure to look hard for every area of benefit.

    Step Four: Identify the SAN-Related Costs

    Determining the costs associated with the scenario involves identifying the new components specifically required to build and maintain the SAN. These can include software licenses, switches, Fibre Channel HBAs, optical cables, and any service costs associated with the deployment. Be careful to include only those items that relate directly to the SAN implementation. This is the second key element in the ROI process: if you do not correctly estimate expenses, the ROI might be substantially better or worse than your estimate.

    Step Five: Calculate the ROI

    There are several standard ROI calculations in common use, such as net present value (in dollars), internal rate of return (as a percentage), and payback period (in months). Briefly, these can be defined as:

  • Net Present Value (NPV) A method used in evaluating investments where the net present value of all cash flows is calculated using a given discount rate.

  • Internal Rate of Return (IRR) A discount rate at which the present value of the future cash flows of an investment equal the costs of the investment.

  • Payback Period The length of time needed to recoup the cost of a capital investment on a nondiscount basis.

  • Detailed explanations of these techniques and how to use them can be found in most accounting textbooks. It is likely that your company has a preferred method for calculating ROI. You should determine which method this is, and if there are standard forms for presenting your analysis. Asking your accounting department might be a good first step.

    This approach to calculating ROI allows you to focus on a particular project or infrastructure-based problem. It allows you to reduce deployment risk by deploying SANs in phases by scenario. Deploying by scenario will keep investments limited to the solution at hand and create an investment base for future deployments. The initial investment will improve the ROI on other scenarios by reducing some of the investment required to deploy them.

    The Rest of the Process and the Repetition of the Cycle

    Now you have the following documents:

  • Detailed results from the interview process, which define what the SAN project needs to accomplish. This includes:

  • --A technical requirements document
    --A timeline for accomplishing the tasks associated with implementing the SAN
    --A list of everything that you will need to buy to make the project work

  • A rough idea of how the SAN will be designed.

  • An ROI analysis to justify continuing with the project.

  • These will be used and maintained throughout the life of the SAN. The timeline will be the framework in which all activities in the SAN's lifecycle will reside. In later chapters, you enter the architecture development phase and will use these documents to develop a detailed architecture for your SAN. This will in turn be used to develop a test plan. These documents will be used in the approval process for implementation, and will be kept up to date during the maintenance phase as part of the SAN's documentation set. If any major changes to the SAN are needed, the lifecycle will be repeated and another set of documentation will be produced.

    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.

    Submit a Comment


    People are discussing this article with 0 comment(s)