Simulating a large network load

A SAN testing application may be provided to restrict the utilization of one or more SAN device resources. The restricted, or throttled, resource(s) enables a smaller load to stress a SAN switch to effectively emulate a larger load. Resource throttling may, for example, result in the rapid filling of switch buffers and corresponding computational stress. The emulated load allows for all ports of a SAN switch to be simultaneously tested without the need or expense of a large number computing devices stressing the SAN. The SAN device with throttled resource(s) may be located within a testing environment or may be located in a functioning SAN to determine SAN bottlenecks prior to critical loading.

FIELD OF THE INVENTION

Embodiments of the invention generally relate to computer systems and more particularly to simulating a large network load in a storage area network (SAN).

DESCRIPTION OF THE RELATED ART

As the throughput of today's SAN switches increase, it is becoming more difficult to produce an adequate load upon the switch or switches in a test environment. Testing loaded switches may be desirable to find switch problems that may be encountered in a SAN where hundreds or thousands of servers are loading the SAN switches. Testing loaded switches may also be desirable to produce a stressed switch which may result in altered timings and or unique errors that surface under higher load.

Altered timing may result when a fully loaded switch cannot send frames as fast as the switch receives them. The fully loaded switch is forced to buffer frames, which, alters the timing of frame delivery. Unique errors may be seen as a direct result of the load. For example, stressed switches may drop frames when they cannot be delivered within a threshold time. As a result, multiple end devices may be performing error recovery processes and the stress switch may corrupt frames.

One solution to test loaded SAN switches is to add a large number of servers and storage devices to a SAN to produce a large enough load. Another current solution to test a loaded SAN switch is to utilize dedicated testing equipment designed to produce load on a port by port basis, such as load test equipment manufactured by JDSU Corporation.

SUMMARY

In an embodiment of the present invention, a method of simulating a large storage area network (SAN) load includes receiving an instruction with a SAN switch that identifies a SAN switch resource and an utilization metric associated with the SAN switch resource, restricting the utilization of the SAN switch resource as enumerated by the utilization metric, receiving a plurality of frames upon a plurality of SAN switch ports, and emulating a large SAN load by buffering the received frames within the SAN switch.

In another embodiment of the present invention, a method of simulating a large storage area network (SAN) load includes receiving an instruction with a SAN switch chassis that identifies a SAN switch chassis resource and an utilization metric associated with the SAN switch chassis resource, restricting the utilization of the SAN switch chassis resource as enumerated by the utilization metric, receiving a plurality of frames upon a plurality of SAN switch ports of a SAN switch within the SAN switch chassis, and emulating a large SAN load by buffering the received frames within the SAN switch.

In yet another embodiment of the present invention, a computer program product for simulating a large storage area network (SAN) load includes a computer readable storage medium having program instructions embodied therewith readable by a SAN switch to cause the SAN switch to receive an instruction that identifies a SAN switch resource and an utilization metric associated with the SAN switch resource, restrict the utilization of the SAN switch resource as enumerated by the utilization metric, receive a plurality of frames upon a plurality of SAN switch ports, and emulate a large SAN load by buffering the received frames within the SAN switch.

These and other embodiments, features, aspects, and advantages will become better understood with reference to the following description, appended claims, and accompanying drawings.

DETAILED DESCRIPTION

Embodiments of the invention generally relate to computer systems and more particularly to simulating a large network load in a SAN. More particularly, a SAN testing application may be provided to restrict the utilization of one or more SAN device resources. The restricted, or throttled, resource(s) enables a smaller load to stress a SAN switch to effectively emulate a larger load. Resource throttling may, for example, result in the rapid filling of switch buffers and corresponding computational stress. The emulated load allows for all ports of a SAN switch to be simultaneously tested without the need or expense of a large number computing devices stressing the SAN. Further, the SAN device with throttled resource(s) may be located within a testing environment or may be located in a functioning SAN to determine SAN bottlenecks prior to critical loading.

Referring to the FIGs., wherein like numbers denote like parts throughout the several views,FIG. 1depicts a high-level block diagram representation of a computer100-A connected to another computer100-B via a network130, according to an embodiment of the present invention. The term “computer” is used herein for convenience only, and in various embodiments is a more general data handling system, such as a mobile phone, tablet, server computer, storage system, etc. The mechanisms and apparatus of embodiments of the present invention apply equally to any appropriate data handling system.

The major components of the computer100-A may comprise one or more processors101, a main memory102, a terminal interface111, a storage interface112, an I/O (Input/Output) device interface113, and a network adapter114, all of which are communicatively coupled, directly or indirectly, for inter-component communication via a memory bus103, an I/O bus104, and an I/O bus interface unit105. The computer100-A contains one or more general-purpose programmable central processing units (CPUs)101A,101B,101C, and101D, herein generically referred to as the processor101. In an embodiment, the computer100-A contains multiple processors typical of a relatively large system; however, in another embodiment the computer100-A may alternatively be a single CPU system. Each processor101executes instructions stored in the main memory102and may comprise one or more levels of on-board cache.

In an embodiment, the main memory102may comprise a random-access semiconductor memory, storage device, or storage medium for storing or encoding data and programs. In another embodiment, the main memory102represents the entire virtual memory of the computer100-A, and may also include the virtual memory of other computer systems coupled to the computer100-A or connected via the network130. The main memory102is conceptually a single monolithic entity, but in other embodiments the main memory102is a more complex arrangement, such as a hierarchy of caches and other memory devices. For example, memory may exist in multiple levels of caches, and these caches may be further divided by function, so that one cache holds instructions while another holds non-instruction data, which is used by the processor or processors. Memory may be further distributed and associated with different CPUs or sets of CPUs, as is known in any of various so-called non-uniform memory access (NUMA) computer architectures.

The main memory102stores or encodes an operating system150, an application160, and/or other program instructions. Although the operating system150, an application160, etc. are illustrated as being contained within the memory102in the computer100-A, in other embodiments some or all of them may be on different computer systems and may be accessed remotely, e.g., via the network130. The computer100-A may use virtual addressing mechanisms that allow the programs of the computer100-A to behave as if they only have access to a large, single storage entity instead of access to multiple, smaller storage entities. Thus, while operating system150, application160, or other program instructions are illustrated as being contained within the main memory102, these elements are not necessarily all completely contained in the same storage device at the same time. Further, although operating system150, application160, other program instructions, etc. are illustrated as being separate entities, in other embodiments some of them, portions of some of them, or all of them may be packaged together.

In an embodiment, operating system150, an application160, and/or other program instructions comprise instructions or statements that execute on the processor101or instructions or statements that are interpreted by instructions or statements that execute on the processor101, to carry out the functions as further described below with reference to FIGs. When such program instructions are able to be run by the processor101, such computer becomes a particular machine configured to carry out such instructions. For example, an application may restrict the utilization of one or more computer100-A resources and or computer100B resources may be loaded upon computer100-A. Further, a storage system application may be loaded upon one or more computers100-B that allows the computer100-A to storage data to computer100-B over the network130.

In some embodiments, one or more processors101may function as a general-purpose programmable graphics processor unit (GPU) that builds images (e.g. a GUI) for output to a display. The GPU, working in conjunction with one or more applications160, determines how to manipulate pixels on e.g. display, touch screen, etc. to create a display image or user interface. Ultimately, the image may be displayed to a user. The processor101and GPU may be discrete components or may be integrated into a single component.

The memory bus103provides a data communication path for transferring data among the processor101, the main memory102, and the I/O bus interface unit105. The I/O bus interface unit105is further coupled to the system I/O bus104for transferring data to and from the various I/O units. The I/O bus interface unit105communicates with multiple I/O interface units111,112,113, and114, which are also known as I/O processors (IOPs) or I/O adapters (IOAs), through the system I/O bus104. The I/O interface units support communication with a variety of storage and I/O devices. For example, the terminal interface unit111supports the attachment of one or more user I/O devices121, which may comprise user output devices (such as a video display device, speaker, and/or television set) and user input devices (such as a keyboard, mouse, keypad, touchpad, trackball, buttons, light pen, or other pointing device). A user may manipulate the user input devices using a user interface, in order to provide input data and commands to the user I/O device121and the computer100-A, and may receive output data via the user output devices. For example, a user interface may be presented via the user I/O device121, such as displayed on a display device, played via a speaker, or printed via a printer. The user interface may be a user interface that provides content to a user visually (e.g. via a screen), audibly (e.g. via a speaker), and/or via touch (e.g. vibrations, etc.).

The storage interface unit112supports the attachment of one or more local disk drives or secondary storage devices125. In an embodiment, the secondary storage devices125are rotating magnetic disk drive storage devices, but in other embodiments they are arrays of disk drives configured to appear as a single large storage device to a host computer, or any other type of storage device such as solid state drives (SSDs) or optical disk drives. The contents of the main memory102, or any portion thereof, may be stored to and retrieved from the secondary storage devices125, as needed. The local secondary storage devices125have a slower access time than does the memory102, meaning that the time needed to read and/or write data from/to the memory102is less than the time needed to read and/or write data from/to for the local secondary storage devices125.

The I/O device interface113provides an interface to any of various other input/output devices. The network adapter114provides one or more communications paths from the computer100-A to other data handling devices such as numerous other computers; such paths may comprise, e.g., one or more networks130. For example, network adapter114may be a SAN adapter that communicatively connects one or more storage devices125of computer system100-B.

Although the memory bus103is shown inFIG. 1as a relatively simple, single bus structure providing a direct communication path among the processors101, the main memory102, and the I/O bus interface105, in fact the memory bus103may comprise multiple different buses or communication paths, which may be arranged in any of various forms, such as point-to-point links in hierarchical, star or web configurations, multiple hierarchical buses, parallel and redundant paths, or any other appropriate type of configuration. Furthermore, while the I/O bus interface105and the I/O bus104are shown as single respective units, the computer100-A may, in fact, contain multiple I/O bus interface units105and/or multiple I/O buses104. While multiple I/O interface units are shown, which separate the system I/O bus104from various communications paths running to the various I/O devices, in other embodiments some or all of the I/O devices are connected directly to one or more system I/O buses.

Network interface114may contain electronic components and logic to adapt or convert data of one protocol on I/O bus104to another protocol on another bus. Therefore, network interface114may connect a wide variety of devices to computer100-A and to each other such as, but not limited to, tape drives, a SAN network (e.g. switches, storage systems, etc.), optical drives, printers, disk controllers, other bus adapters, PCI adapters, workstations using one or more protocols including, but not limited to, Token Ring, Gigabit Ethernet (GbEN), Ethernet, Fibre Channel, Fibre Channel over Ethernet (FCoE), SSA, Fiber Channel Arbitrated Loop (FCAL), Serial SCSI, Ultra3 SCSI, iSCSI, Infiniband, FDDI, ATM, 1394, ESCON, wireless relays, Twinax, LAN connections, WAN connections, high performance graphics, etc. In embodiments, network130is a SAN or other storage network.

Though shown as distinct entities, the multiple I/O interface units111,112,113, and114or the functionality of the I/O interface units111,112,113, and114may be integrated into a similar device.

In embodiments, network130may be one or more suitable networks or combination of networks and may support any appropriate protocol suitable for communication of data and/or code to/from the computer100-A and at least the computer100-B. For example, network130may include a communication network (e.g., internet) and network130may include a storage network (e.g., SAN). In various embodiments, the network130may represent a data handling device or a combination of data handling devices, either connected directly or indirectly to the computer100-A. In another embodiment, the network130may support wireless communications. In another embodiment, the network130may support hard-wired communications, such as a telephone line or cable. In another embodiment, the network130may be the Internet and may support IP (Internet Protocol). In another embodiment, the network130is implemented as a local area network (LAN) or a wide area network (WAN). In another embodiment, the network130is implemented as a hotspot service provider network. In another embodiment, the network130is implemented an intranet. In another embodiment, the network130is implemented as any appropriate cellular data network, cell-based radio network technology, or wireless network. In another embodiment, the network130is implemented as any suitable network or combination of networks. Although one network130is shown, in other embodiments any number of networks (of the same or different types) may be present.

FIG. 1is intended to depict the representative major components of the computer100-A. But, individual components may have greater complexity than represented inFIG. 1, components other than or in addition to those shown inFIG. 1may be present, and the number, type, and configuration of such components may vary. Several particular examples of such additional complexity or additional variations are disclosed herein; these are by way of example only and are not necessarily the only such variations. The various program instructions implementing e.g. upon computer system100according to various embodiments of the invention may be implemented in a number of manners, including using various computer applications, routines, components, programs, objects, modules, data structures, etc. Computer100-B may include similar, less, or additional components as compared with computer100-A. In specific embodiments, computer100-A may be a server, computer100-B may be a storage system that may store data from computer100-A, and network130includes a SAN to provide for the storage of data from server100-A upon storage system100-B.

FIG. 2illustrates a SAN environment200including a SAN network130that generally provides access to consolidated, block level data storage. SAN environment200may be used to enhance the storage capabilities of numerous computers. For example, storage devices, e.g., disk arrays, tape libraries, and optical jukeboxes, etc. within computer100-B may appear like locally attached devices125to the operating system150of computer100-A. SAN environment200may be used to increase storage capacity utilization, since multiple computers may consolidate storage space onto SAN storage devices125. Common uses of a SAN environment200include provision of transactional accessed data that require high-speed block-level access to the hard drives such as email servers, databases, and high usage file servers.

SAN environment200may also provide the sharing of storage space to simplify storage administration. The SAN environment200could span a distant physical distance between the computer100-A and the SAN storage devices125attached via the SAN network130. This enables storage replication either implemented by disk array controllers, by server software, or by specialized SAN devices, such as a Fibre Channel switch. Some SANs130use the SCSI protocol for communication between computers100and SAN attached devices125. A mapping layer to other protocols may be used to form SAN specific network130, such as ATA over Ethernet (AoE), SCSI over Fibre Channel, Fibre Channel over Ethernet (FCoE), ESCON over Fibre Channel (FICON), HyperSCSI, iFCP, SANoIP' iSCSI, etc.

SAN environment200often includes a fabric topology which is an infrastructure specially designed to route storage communications. A typical SAN fabric is made up of one or more switches220.

In a particular embodiment, the SAN network130includes SAN storage devices125attached to one or more computers via one or more switches220. Computer100-A, and100-B may include a controller208such as a storage controller that may manage or control the loading of data to SAN attached storage devices125. The controller208may be connected to I/O bus104, be included within e.g., storage interface112, I/O interface113, network interface114, implemented by processor101, etc. In certain embodiments, controller208is an application160. In other embodiments, controller208is processing unit such as CPU101, programmable array, etc.

In embodiments, the network interface114may further include a buffer204to store data to be transmitted by a transmit module204A or to store data received from receive module204B. Similarly, controller208may further include a buffer209to temporarily store data that will be loaded upon SAN storage devices125as directed by controller208or to temporarily store data from SAN storage devices125for further processing (e.g., provide data from SAN storage device125to a requesting computer100-A via SAN130, etc.). Likewise, switch220may include a buffer210for temporarily storing received data that is to be stored upon one or more SAN storage devices125or for temporarily storing data received from SAN storage devices125that is to be provided to a requesting device. The data that moves though the switch220may be managed by controller212. Controller212may be an application160or a processing unit such as CPU101, programmable array, etc. Switch220may further include a plurality of ports222that provide for a communication interface with other SAN environment200devices. In addition to processor101and memory102, switch220may include similar components as e.g., computer100-A.

FIG. 3illustrates an exterior view of SAN switch220. In an embodiment, the SAN testing application is provided to restrict the utilization of one or more SAN switch220resources or components. For example, if a 20% load is being implemented upon a switch220using all of its capabilities the load may not be sufficient to sufficient stress the switch220to expose possible defects. However, if we were to drive that same 20% load while limiting the switch to use only 28.57% of its total resource capacity, the 20% actual-load becomes an emulated 70% equivalent-load (20/28.54=70%). A non exhaustive list of potential switch220resources that may be throttled are CPU101, memory102, buffer210, number of buffer credits per port222, capacity per port on demand (POD), etc.

FIG. 4illustrates an exterior view of a chassis300including multiple SAN switches200-A,200-B, and200C. The chassis300may include numerous slots305that which respective switches220may be inserted. In some implementations, multiple switches220may be connected by a backplane310that includes a connector312. In these implementations respective switches220may engage with respective connectors312. In another embodiment, the SAN testing application is provided to restrict one or more resources within a chassis300. A non exhaustive list of potential chassis300resources that may be throttled are capacity per slot305(e.g., capacity per connector312, capacity per switch220, etc.), overall capacity per chassis300, etc.

Generally, the SAN testing application may control the accessibility and usability of one or more resources within a SAN environment200. The application allows an administrator to indicate one or more resources and to specify the applicable amount, space, quantity, speed, proportion, or other applicable performance metric of the specified resources for utilization. Once the utilization metric of the specified resource is received, the SAN testing application may hold, block, or otherwise restrict the applicable remaining amount, increase or decreases the latency of the resource, etc. of the specified resource for a duration of a SAN testing period. For example, the size of buffer210may be reduced, the clock speed of the CPU101may be increased, the number of buffer credits may be reduced, etc. The altered utilizations of the resource(s) enable a smaller load to stress the SAN switch220to effectively emulate a larger load. In a particular example, the size of buffer210may be limited and such resource throttling would result in the rapid filling of the remaining buffer210and cause a corresponding computational stress. This emulated effectively larger load allows for all ports222of the SAN switch220to be simultaneously tested without the need or expense of a large number computing devices stressing the SAN environment200.

FIG. 5illustrates an exemplary SAN testing application interface400to simulate a large network load, according to various embodiments of the present invention. Interface400may be provided upon user I/O device121and may include a hardware image of a chassis300. Further, interface400may include navigation objects402,404, and or406. Interface400may also include receiving fields410that which an administrator may input various utilization metrics. Interface400may also include a utilization icon420that provides an indication of the utilization of an associated resource. The user interface400may be a graphic user interface displayed upon a display or touch screen. Interface400may display chassis300level resources and may allow for the administrator to provide one or more utilization metrics to associated resources.

In a particular implementation, the administrator may indicate that a first slot305is to be utilized at 50% utilization capacity in order to simulate a larger network load in a SAN environment200. In other words, 50% of the capacity (e.g., Gb/slot, etc.) of the first slot305is blocked from being utilized during the SAN testing period. In this manner, a similar network load adds twice the amount of computational stress to the throttled first slot305. Likewise, the administrator may indicate that a second slot305is to be utilized at 35% utilization capacity in order to simulate a larger network load in a SAN environment200, a third slot305is to be utilized at 5% utilization capacity in order to simulate a larger network load in a SAN environment200, and a fourth slot305is to be utilized at 10% utilization capacity in order to simulate a larger network load in a SAN environment200.

In another implementation, the administrator may indicate that the overall chassis300is to be utilized at 25% utilization capacity (e.g., Tb/chassis, etc.) in order to simulate a larger network load in a SAN environment200. In other words, 75% of the capacity of chassis300is blocked from being utilized during the SAN testing period.

FIG. 6illustrates an exemplary SAN testing application interface500to simulate a large network load, according to various embodiments of the present invention. Interface500may be provided upon user I/O device121and may include a hardware image of a SAN switch220. Interface500may include navigation objects402,404, and or406and may also include receiving fields410that which an administrator may input various utilization metrics. Interface500may also include one or more utilization icons420to provide an indication of the utilization of an associated resource. The user interface500may be a graphic user interface displayed upon a display or touch screen. Interface500may display SAN switch220level resources and may allow for the administrator to provide one or more utilization metrics to an associated resource.

In a particular implementation, the administrator may indicate that a first port222is to be utilized at 30% utilization capacity (e.g., receive port, transmit port may be throttled, buffer210partition assigned to the first port may be limited, etc.) in order to simulate a larger network load in a SAN environment200. In other words, 70% of the capacity of the first port222is blocked from being utilized during the SAN testing period. Likewise, the administrator may indicate that an n port222is to be utilized at 35% utilization capacity in order to simulate a larger network load in a SAN environment200.

In another implementation, the administrator may indicate that SAN switch220memory120is to be utilized at a 5% capacity in order to simulate a larger network load in a SAN environment200. For instance, 95% of memory120space may be blocked, unutilized, etc. In another implementation, the administrator may indicate that a SAN switch220CPU101is to be utilized at a 10% capacity. Because the utilizations of e.g., CPU101and memory120are limited, a similar network load adds a greater the amount of computational stress to the switch220and effectively emulates a larger load at full utilizations.

In another implementation, the administrator may indicate a limited number of buffer credits are to be utilized to simulate a larger network load in a SAN environment200. A buffer credit generally allows data communication in a Fibre Channel SAN. Latency may impose a distance limitation of a few kilometers between the source and the destination in the network. If the length of the fiber optic cable span exceeds this threshold, the throughput drops sharply. The buffer credit method allows the use of offsite storage facilities hundreds of kilometers away. In typically buffer credit flow control, a SAN200source and SAN200destination set the number of unacknowledged frames (buffer credits) allowed accumulating before the SAN200source stops sending data. A counter at the SAN200source keeps track of the number of buffer credits. Each time a frame is sent by the SAN200source, the counter increments by 1. Each time the SAN200destination receives a frame, it sends an acknowledgment back to the SAN200source, which decrements the counter by 1. If the number of buffer credits reaches the maximum, the SAN200source stops transmission until it receives the next acknowledgement from the SAN200destination. In embodiments, buffer credit starvation occurs when the transmitting port222runs out of buffer credits and isn't allowed to send frames. As such, the frames will be stored within the switch220, buffer210and eventually have to be dropped if they can't be sent for a certain time. By limiting the number of available buffer credits, the administrator may cause the filling of buffer210and may effectively simulate a larger network load. For example, the administrator may indicate that only 20% of the recommended, maximum, minimum, etc. number of buffer credits may be utilized by switch220to process network traffic within the SAN test period.

In another implementation the administrator may limit the number of PODs to simulate a larger network load in a SAN environment200. Some switches220may utilize POD wherein a certain number of ports222(e.g., 8 ports) are typically used and additional ports222(e.g. 16 ports, etc.) are dynamically activated and may be used to process increasing network loads. By limiting the number of available PODs, the administrator may cause a minimal number of ports222to process traffic and therefore may simulate a larger network load. For example, the administrator may indicate that a maximum number (e.g., 20% of the ports222, etc.) may be utilized to process network traffic.

FIG. 7illustrates an exemplary process700for simulating a large network load. Process700may be utilized to, for example, stimulate a large network load upon a SAN switch220by restricting usage of switch220resources to process a network load. For example, the size of buffer210may be limited to enable a smaller load to stress the SAN switch220to mimic a relatively larger load with a full side buffer. The restricted buffer may inhibit the SAN switch220from delivering frames, resulting in the filling of the buffer and corresponding computational stress. The emulated load allows for an all ports222of the SAN switch220to be simultaneously tested without the need or expense of a large number computing devices within the SAN environment200.

Process700begins at block702and continues with a SAN switch220, a group of SAN switches220, a chassis300, etc. receiving an instruction from a SAN test application to restrict one or more resources (block704). For example, the SAN test application may be implemented upon computer100-A that is communicatively connected to the SAN switch220and may instruct the switch220to restrict it's, e.g., number of ports222that may be utilized, the size of buffer210, the available memory120space, the capacity of CPU101, the number of buffer credits, etc. In another example, a SAN user may invoke a test environment by inputting a key code, authorization, license, etc. received by a SAN device to display the SAN test application that allows the throttling of resources prior to the SAN device receiving the instruction from the SAN test application to restrict one or more resources. In this way, the SAN test application may be enable by an entity with proper authorization to limit resources within the SAN environment200.

Process700may continue with the SAN device restricting the utilization of the specified resource as identified by the received instruction (block706). For example, the SAN test application may hold, block, decrease, etc. a portion of the resource in a not available or reserve mode for the duration of the test period and allowing the utilization of the remaining portion of the indicated resource. For example, 5% of the buffer210may be utilized and 95% of the buffer210may be blocked from being utilized. The enforcement of such resource throttling may be achieved by local controllers (e.g. controller212, etc.), CPU101, resource management or control applications, etc.

Method700may continue by emulating a relatively larger load by buffering or otherwise storing subsequent frames received from a source device within the SAN environment200within the restricted SAN device and/or buffering or otherwise storing subsequent frames retrieved from a destination device within the SAN environment200within the restricted SAN device (block708). For example, a Fibre Channel frame may be sent from respective transmit modules204A from one or more source computers and received upon a plurality of ports222of switch220that includes a resource having it's utilization restricted. The frames may be temporarily stored within buffer210space and delivered via one or more ports222to a receive module204B of one or more destination computers. The restricted resource causes relatively increased computational stress. In this manner, a relatively smaller load may produce a stress normally achieved with much larger loads. Method700ends at block710.

FIG. 8illustrates an exemplary process750for a SAN device to generate an instruction to simulate a large network load. Process750may be utilized by a SAN device, such as computer100-A to instruct a SAN switch220to limit or restrict one or more switch220resources. Process750begins at block752and continues with a SAN device providing a SAN test application wherein an administrator may identify one or more resources and may indicate a utilization metric to restrict the utilization of the identified resource (block754). For example, computer100-A may display an interface400,500upon I/O device121.

Process750may continue with the SAN device receiving the utilization metric to restrict the utilization of the identified resource (block756). For example, the application may receive the metric to restrict the availability of buffer210to 20% of its overall size. Process750may continue with the application generating an instruction that identifies the resource to be restricted and the extent of the restriction (block758). Process750ends at block760.