White Paper   White Paper:   7 Steps to Network Lab   Automation   How to automate the physical layer of a network   syste...
7 Steps to Network Lab Automation | 2                                          Table of ContentsIntroduction ................
7 Steps to Network Lab Automation | 3IntroductionAs IP networks are becoming ever more pervasive, networking equipment is ...
7 Steps to Network Lab Automation | 4Step 1. Assessing the NeedAutomating a test lab begins with a thorough assessment of ...
7 Steps to Network Lab Automation | 5     A lab assessment can measure the business case for automation through factors su...
7 Steps to Network Lab Automation | 6Most labs will want to take a phased approach to the automation process, starting whe...
7 Steps to Network Lab Automation | 7Step 4. Lab Management: Choosing the Right SolutionChoosing a lab OS software solutio...
7 Steps to Network Lab Automation | 8    Seamless integration with the lab’s existing scripts and script managers is an im...
7 Steps to Network Lab Automation | 9So, if the number of ports under test is larger than the number of ports on the large...
7 Steps to Network Lab Automation | 10dynamically set up the appropriate test topology before the script or scripts are la...
Upcoming SlideShare
Loading in...5
×

Gale Technologies - A Leading Innovative Software Solutions Provider Explains Seven Steps To Network Lab Automation

1,112

Published on

In this document, Gale Technologies explains how to automate a network lab in seven steps. It further elaborates on how recent developments in technology has led to an increased interest in lab automation and lab management. Gale Technologies talks about how a lab automation system increases ROI.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,112
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Gale Technologies - A Leading Innovative Software Solutions Provider Explains Seven Steps To Network Lab Automation

  1. 1. White Paper White Paper: 7 Steps to Network Lab Automation How to automate the physical layer of a network system’s test lab resulting in dynamic test beds, shorter test cycles, and higher quality testing© 2008-2010 Gale Technologies, Inc. All rights reserved.
  2. 2. 7 Steps to Network Lab Automation | 2 Table of ContentsIntroduction ....................................................................................................... 3Step 1. Assessing the Need .............................................................................. 4Step 2. Deciding What to Automate .................................................................. 5Step 3. Choosing the Infrastructure................................................................... 6Step 4. Lab Management: Choosing the Right Solution.................................... 7Step 5. The Architecture of the Solution............................................................ 8Step 6. The Administrative Framework ............................................................. 9Step 7. Integration ............................................................................................. 9Conclusion ...................................................................................................... 10About Gale Technologies ................................................................................ 10 © 2008-2010 Gale Technologies, Inc. All rights reserved.
  3. 3. 7 Steps to Network Lab Automation | 3IntroductionAs IP networks are becoming ever more pervasive, networking equipment is becoming moresophisticated and must be tested for operation in more heterogeneous environments. Testing is timesensitive, and labs are affected by a host of factors that impact performance – collaborative work with off-site colleagues, partners or customers, changes in network topologies to support growth, and emergingvoice, storage, and video data services to name a few.Technology advancements, new higher speed interfaces, and the corresponding increase in testequipment complexity and cost have put pressure on testing departments and test lab managers to domore with less. This has spawned an increased interest in test automation using test scripts. While manytest labs have evolved to embrace some form of test script automation where appropriate, labs of allkinds are now eyeing the next logical step in this evolution: lab automation at the physical layer.At its very basic element, this involves deploying physical-layer switches that serve as interconnects inconjunction with what might be called a "lab operating system" (lab OS) – a software-based solution thatmanages dynamically configurable test topologies. In this new generation test environment, it is commonfor test gear, devices, and systems under test to be permanently connected to physical-layer switches,typically OEO (Optical-Electrical-Optical) matrix switches, OOO (all-optical) switches, or other copper orfiber cross-connect devices. In this scenario, the lab OS software provides a front-end graphical userinterface (GUI) and/or application programming interface (API) for scheduling and controlling theconnections between devices. Ideally, it integrates seamlessly with the lab’s existing scripts and test toolsas well as provides features for managing user access and tracking the usage of the lab resources it isinterconnecting.This new lab infrastructure provides many benefits, including remote access for off-premises developersand partners, the ability to run multiple tests in parallel, and the elimination of manual reconfigurations,resulting in dramatically shortened test cycles. In addition, when used in conjunction with testautomation, dynamic physical configurations have dramatically increased the speed in which tests can berun.This white paper offers a practical how-to approach for moving to the new generation test lab usingphysical-layer automation. © 2008-2010 Gale Technologies, Inc. All rights reserved.
  4. 4. 7 Steps to Network Lab Automation | 4Step 1. Assessing the NeedAutomating a test lab begins with a thorough assessment of the labs environment. This assessmentshould meet two key criteria: one strategic, the second tactical.On a strategic level, first prove a business case for automating the physical layer of your lab. This is acritical analytical step for managers of both large and small test labs. Consider, for instance, a lab with afinite set of equipment whose configuration never changes or changes only once every six months or so.In this situation, an assessment may show there is no case for automating the physical layer of the lab.In a large or more complex test lab, where the return-on-investment (ROI) benefits of physical-layerautomation are readily understandable, the assessment is more a tactical issue.One critical early step in the assessment process is developing an inventory of the labs resources, whichmay be geographically dispersed in the hands of engineers at remote offices. This will pinpoint how manydevices – routers, switches, gateways, Fiber Channel directors, servers, PCs, traffic generators,analyzers, and the like – the lab contains, along with their port counts.Another area to explore is the cabling infrastructure. Is it a well-organized plant, or a morass of wires?How much time do lab personnel spend re-cabling equipment in preparation for a given test and what isthe impact of that time on the project backlog of the lab? The complete assessment should also includeinformation detailing where each device is located, which devices it typically connects to and whether it isavailable for use by both remote and local personnel.Just as importantly, the assessment should contain a breakdown of the types of tests normally run in thelab and on each piece of equipment, their frequency, their goal, and the additional equipment required foreach type of test. This part of the assessment can be eye opening as it often fully reveals the processesand organization of the lab, which can differ dramatically from management’s perspective as to howefficient the lab processes have been.Oftentimes, an assessment will uncover policies that are detrimental to the labs efficiencies. Forinstance, many labs allow engineers to check out test equipment for months at a time without trackinggranular information about whether the equipment is being used regularly or sitting idle. This phase mayuncover significantly underutilized resources.The format of the assessment depends on the nature of the lab and its personnel. For small groups, aninformal visual assessment, with an inventory written on paper, can suffice. For larger labs, a morestructured process is needed. Most vendors of physical-layer automation tool sets provide customizablesurveys that facilitate this process. The most sophisticated of these survey tools, which offer a variety ofoperations simulations, allow lab managers to perform an appropriate business-case analysis they canpresent to executive management to justify the implementation of lab automation. © 2008-2010 Gale Technologies, Inc. All rights reserved.
  5. 5. 7 Steps to Network Lab Automation | 5 A lab assessment can measure the business case for automation through factors such as increased capital utilization and efficient use of labor. In additionto proving the business case for physical-layer automation, the information collected in the assessment isneeded to support several other steps in the evaluation and implementation phases.Step 2. Deciding What to AutomateThe next step is to determine exactly which sections of a lab will benefit most from physical-layerautomation. Seldom does it make sense to connect every single port in a test lab to a physical-layerswitching infrastructure, especially early in the automation process. Therefore, lab managers must spenda fair amount of time during the assessment process to pinpoint which areas of their labs undergo themost reconfiguration or can be better utilized or shared. The goal here is to understand where dynamicconfiguration of the lab’s physical infrastructure can deliver the most benefits.For some labs, it will be most beneficial to put the most expensive pieces of equipment -- trafficgenerators, for example -- on the switched environment. Doing so makes it easier to share thoseresources among multiple users or across multiple functions, as well as give the organization the bestreturn on investment on these devices.For others, the best action to take may be to consolidate multiple patch panels and cabling systems thatusually take hours to move between each test. Alternatively, it could be to interconnect dedicated testequipment –used by individual engineers at their workstations – to a set of shared equipment within thelab. © 2008-2010 Gale Technologies, Inc. All rights reserved.
  6. 6. 7 Steps to Network Lab Automation | 6Most labs will want to take a phased approach to the automation process, starting where they need helpthe most, and adding resources to the infrastructure over time. As such, the lab OS software should allowall devices, whether connected to the switching infrastructure or not, to be designed into test topologiesand reserved and tracked equally.Step 3. Choosing the InfrastructureThe capabilities of physical-layer switches vary, so a careful analysis is important to get the bestinfrastructure fit for a particular lab environment. Making this decision will involve examining a wide rangeof factors, ranging from form factor to interfaces and technologies supported by the various vendors’switches to the conditions in the particular lab being automated.So, what exactly is a physical-layer switch? In basic terms, a physical-layer switch operates similarly to amanual patch panel, except that patching is controlled electronically through software. A physical-layerswitch patches physical circuits, essentially simulating the actual plugging/unplugging of cables in/out of amanual patch panel.A physical-layer switch, or Layer 1 switch, operates at Layer 1 of the Open System Interconnection (OSI)model. A physical-layer switch merely establishes a physical connection between two ports, and canprovide media conversion. It does not read, modify or route data based on packet or frame headers.Data traversing the circuit is unimpeded by the overhead of packet processing. In addition, physical-layerswitches are non-blocking (to a point), protocol-independent devices that operate at full line speed.Contrast this with a typical Ethernet switch, which operates at Layer 2 or 3 in the OSI model and switchespackets by reading packet or frame headers and routing data to the destination ports designated in thepacket header.Some labs use Layer 2/3 switches rather than Layer 1 switches for interconnecting devices into aphysical topology, but doing so is not appropriate for many labs. First of all, Layer 2/3 switches can affectthe results of tests. A Layer 2/3 switch, for instance, will filter bad packets or fragments, or determinewhere to send a packet based on IP address, for example, which are behaviors that may not beappropriate in a test environment. Additionally, Layer 2/3 switches may be costly to scale, and do notprovide the flexibility of Layer 1 switches to support a mix of media types and media conversion.When assessing which physical-layer switches to deploy, lab managers should consider these factors: • the performance characteristics required by their lab • the OSI layer at which they are testing • the number of ports they need to interconnect • data rates and interfaces in use • the any-to-any capabilities their lab requires • the copper and fiber cabling requirements of the lab • the requirements for inserting test, analysis, or impairment equipment into connections between devicesMost labs today deploy a mix of physical-layer switches from different manufacturers. This allows the labto better support a variety of data and interface types and the various characteristics of the technologiesthat need to be tested. In addition, feature and function differences of otherwise similar switches maydictate deploying several different switches for addressing a variety of needs within a lab. Economicfactors may also come into play here. Certain types of ports may be available in many types of switches,but may be more cost-effective in a particular type or brand depending on scale and other factors. © 2008-2010 Gale Technologies, Inc. All rights reserved.
  7. 7. 7 Steps to Network Lab Automation | 7Step 4. Lab Management: Choosing the Right SolutionChoosing a lab OS software solution is a critical decision, because it provides the support structure formanaging and automating the infrastructure of your lab.Many labs use home-grown solutions for managing various lab processes. For the most part, the use ofhome-grown solutions has been perpetuated by a lack of commercially available solutions for labmanagement. Disparate solutions for managing individual devices, test scripts, or specific test gear havenot been designed with the holistic lab in mind, requiring front-end interfaces to be designed by labpersonnel. But with the addition of physical-layer automation and the solutions available today, choosingand deploying an off-the-shelf lab-management solution has become a viable and cost-effective solution.Thoroughly investigate your options, and focus on the features that are important for your uniqueenvironment. Here are some key features and capabilities to look for when choosing a lab-managementsolution: An open solution that manages multiple vendors physical-layer switches: As mentioned in Step 3, most labs today are heterogeneous and require a mix of switch technologies accommodating different media types or special features provided by different switches. Proprietary solutions from switch vendors themselves or other customized solutions will lock the lab into a single hardware vendor, which restricts lab management’s choice of switches. A hardware independent solution allows the lab manager to select switches based on features, performance, port density, quality, and value rather than on a limitation of the lab’s deployed management software. And because this hardware-independence forces competition among the switch vendors, it also helps to commoditize the switches and compel vendors to provide additional value to their customers. Further, a common front end or set of commands that masks the particulars of the switching infrastructure is a key factor in the efficiency, reusability, and portability of test scripts. While hardware-independence is important, feature integration is also important, ensuring the software provides intuitive access to hard-to-use switch features such as connection tapping, multicasting, rate and framing settings, and SFP (small form-factor pluggable) diagnostics. A GUI that allows users to easily design, save, organize, and recall an infinite number of test topologies: Look for a drag-and-drop interface that masks the underlying switching infrastructure, while providing troubleshooting capabilities that expose the infrastructure when necessary. Any subset of a device or set of devices and the interconnections between them should be able to be configured. A scheduler that manages multiple users contending for lab resources: The software should allow reservation of lab resources at specific dates and times, as well as prioritized queuing of automated tests so that tests are run as soon as the appropriate equipment becomes available. The scheduler should also automate the process of identifying available devices and assigning them to tests as required. For example, you may want to define a test topology by describing the types of devices involved and required characteristics of the devices, and have the system find and assign matching and available devices at reservation time. Control over user permissions: You should be able to control who can access which devices and test topologies, when, and for how long. If you have multiple departments sharing a lab, or local or remote user communities for whom limited access is appropriate, you should look for a solution that provides fine-tunable permissions and priorities on devices, topologies, and scheduling. This is discussed further in Step 6. An API that enables automated test scripts to incorporate control of the physical infrastructure: © 2008-2010 Gale Technologies, Inc. All rights reserved.
  8. 8. 7 Steps to Network Lab Automation | 8 Seamless integration with the lab’s existing scripts and script managers is an important success factor that will keep engineers from having to re-create existing automation processes. This is discussed further in Step 7. An extensible database that allows the assignment of customizable device attributes: Every lab is different, and the software should accommodate user-customizable device information that may be important for your lab to track or for engineers or managers to use for search criteria – technical data, asset data, geographic data, and the like. You should, for example, be able to search for an available traffic generator that supports a particular type of test on a specified protocol.There are a few additional capabilities discussed in the remaining steps, and many others that you maywant to look for, such as built-in reporting on activity and resource utilization, appropriate platform supportfor the platforms use in your organization, and integrated access to devices’ management consoles,power control, and software configurations. A lab OS designed specifically for lab environments shouldprovide these capabilities. The new paradigm for dynamically creating test beds remotely through lab-management software.Step 5. The Architecture of the SolutionPlanning the lab architecture is a critical deployment step. As noted in Step 1, it requires a carefulassessment of a lab’s existing infrastructure to determine where and how devices are generally used andconnected to each other. This requires understanding, for instance, that there may be communities ofinterest or devices that are typically connected to each other for specific types of tests or logical reasons;a traffic generator is typically not connected directly to another traffic generator, for instance, but to somedevice or system under test.In developing this architecture, a lab manager should consider what needs to be achieved and what doesnot because all decisions have ramifications. For instance, one major mistake would be to connect all ofthe test equipment to one switch, and all devices under test to a separate switch. That would essentiallyforce a situation in which most connections, which are typically between the test gear and the devicesunder test, are forced to cross to a different switch. This is costly, because it eats up switch ports forunnecessary inter-switch linking, and it is an inefficient way to run a test environment. © 2008-2010 Gale Technologies, Inc. All rights reserved.
  9. 9. 7 Steps to Network Lab Automation | 9So, if the number of ports under test is larger than the number of ports on the largest switch available – inthe case of Ethernet, this is probably around 288 ports – care must be taken to consider the connectionpatterns expected and to distribute the equipment among multiple switches so as to minimize the need touse inter-switch links to connect devices. Divide the devices so most typical or common ports that adevice needs to connect to can be found on same switch. This minimizes having to cross switches tomake a typical connection, which not only minimizes the number of switch ports that are required, butalso reduces potential signal degradation factors that may result from many hops through the switchinginfrastructure.In many labs, however, in order to achieve the required connectivity of devices across the lab, daisy-chaining or otherwise interconnecting physical-layer switches cannot be avoided. Transparent set-up,management, use, and optimization of such links is another key component of a lab-managementsoftware solution.Understanding how the devices need to be interconnected to each other, planning how to connect themappropriately to the switching infrastructure and interconnecting the switches to each other in such a wayas to allow required connections to be made is a very important step in the lab automation process.Step 6. The Administrative FrameworkThe next step in automating the physical layer of a lab is developing an administrative framework. Thisframework will determine user access rights to ensure that all users and groups have expected andappropriate access to lab resources.Before deploying the physical-layer automation solution, it is essential to clearly understand who will haveaccess to lab resources, and establish clear access and permission parameters for different usercommunities within and outside of the organization. This also involves naming and grouping labresources in such a way that those user communities can easily identify and use the resources availableto them. All of this requires that the software solution selected to facilitate this process should be able toassign various “see,” “use,” “read/write” permissions to any device, group of devices, topology, or similarresource.An administrative framework should also accommodate special projects or ad hoc situations. That is, itshould permit giving specific users or groups exclusive or prioritized access to domains of equipment forcritical or special situations.Flexibility is key for developing an automated physical-layer lab infrastructure that supports operationalefficiency. By eliminating a pre-defined set of generic permission sets, lab management can respondmore quickly to changing business needs that require new or special projects.Step 7. IntegrationIntegrating a lab-management solution into an existing test environment is the last major step inautomating the lab’s physical layer. To deliver the most value, the lab-management system must fitseamlessly into the existing test environment and integrate with any test-automation tool platforms in use.The areas of integration driven by the lab-management software may include system-under-testconfiguration, including loading a particular firmware version or disk image on a device under test, scriptintegration with automated test logic, and discrete device control, including direct console access orscripted control of devices in the lab.To streamline test processes for greater productivity, integrate the features provided by the lab-management software with existing tools in the lab. For example, you may have a test managementsolution that launches a test script or series of scripts. The software managing your physical layerinfrastructure should be controllable from that test management system so that engineers can © 2008-2010 Gale Technologies, Inc. All rights reserved.
  10. 10. 7 Steps to Network Lab Automation | 10dynamically set up the appropriate test topology before the script or scripts are launched. Likewise, if thelab OS includes a sophisticated scheduler, use it as a launch pad for activity on script managers or testequipment to trigger scripts at the time scheduled reservations begin or end. Through this integration, labmanagement and test engineers can significantly improve their productivity in both automated andmanual test modes.ConclusionA variety of market forces are driving the move to increased lab automation. Cutthroat competition thatdemands fast time-to-market and shorter lifecycles are forcing networking device manufacturers to domore – and manage resources more cost effectively and efficiently – in their test labs.An emerging solution is a standard for the automatic control of traffic generation and analysis devices.With this standard in place, lab personnel could use a single script on test equipment from multiplevendors, dramatically reducing the number of different test scripts and greatly facilitating the sharing andreuse of test scripts across a large organization.Efficiencies and cost savings gained in the lab can translate to enterprise-wide operational benefits andreduced capital expenditures. For example, test automation can help dramatically shorten developmentlifecycles and time-to-market. The ability to share remote resources gives lab managers the power tocreate globally distributed teams, which further bring speed and efficiency to test processes.In much the same way that implementing test automation is not a short-term project, automating a lab is along-term commitment that requires an upfront investment in time and resources, but promises an ROI interms of both capital utilization and lab personnel productivity.For More InformationTo learn more about Gale Technologies and its products, please call us at +1 866-450-3366 toll free inNorth America or +1 408-213-4922 worldwide, visit us at www.galetechnologies.com , or emailinfo@galetechnologies.com .About Gale TechnologiesGale Technologies provides advanced software solutions to automate, orchestrate, and optimizeresources – transforming the process of infrastructure service delivery. As a pioneer of innovativesolutions for provisioning and workflow automation across networking, server, storage, and virtualizationtechnologies, Gale enables the automated and self-service provisioning of private and public cloudenvironments. The company’s end-to-end solutions enable organizations to reduce capital andoperational expenditures, set up any dynamic lab, demo, data center, or cloud in just minutes, andprovide secure access to resources 24x7 from anywhere in the world. Gale Technologies is based inSanta Clara, CA, and serves a global customer base with offices in North America and Asia.Gale Technologies, Inc.2350 Mission College Blvd, Suite 825Santa Clara, CA 95054+1 408-213-4900info@galetechnologies.com © 2008-2010 Gale Technologies, Inc. All rights reserved.

×