JP2010515121A - Method and system for identifying storage resources of an application system - Google Patents

Abstract

  The present invention enables mapping from application sets to storage elements used within a digital storage environment within a digital processing environment, and more particularly within a digital storage environment, and any storage within the digital storage environment. Methods, apparatus, systems, and computer program code (software) products are provided that are operable to provide a hierarchical image of an application set (other software programs) that is loading an element.

Description

CROSS REFERENCE TO RELATED APPLICATIONS This patent application is filed on Dec. 21, 2006, and is a US provisional patent application entitled “Methods and Systems for Identifying Application System Storage Resources”. No. 60/871444 (Attorney Docket Number: AKR-114-PR), which claims the benefit of priority, the provisional patent application is hereby incorporated by reference as if set forth in its entirety. Incorporate.

  This patent application is filed on Jul. 5, 2007, US patent application Ser. No. 11 / 773,825 (Attorney Docket No. AKR-110-US) entitled “Managing Application System Load”. , A continuation-in-part application (CIP), which is also incorporated herein by reference, and whose detailed description and drawings are described herein. US patent application Ser. No. 11 / 773,825 (AKR-110-US) is the priority of US Provisional Patent Application No. 60 / 806,699 (AKR-110-PR) filed on July 6, 2006. This provisional patent application is hereby incorporated by reference as if set forth in its entirety.

The present invention relates generally to digital processing systems, devices, and networks, and more particularly to the field of application performance and self-management systems. Even more particularly, the present invention relates to a method, system, and apparatus for re-mapping performance problems caused by system resources to application servers, applications, and application tasks that are creating a load on performance-constrained system resources. .

Background of the Invention Many storage platforms allow storage administrators to allocate and allocate storage resources to different hardware servers. A single hardware server can execute multiple applications in parallel. A single application can embody several concurrent tasks. A single application typically uses several system resources. Application performance can potentially be accelerated if the application's access to system resources can be optimized.

  Unfortunately, with conventional storage platforms, the user or system administrator has little guidance on how individual applications use the system resource set. Two applications running in parallel on the same hardware server may stall due to contention for common system resources. System lease contention can be identified, but without fully knowing the cause of the problem, unless the mapping from the application to the system resources using the application and vice versa cannot be identified You can try to repair the bottleneck.

  More specifically, applications are often hosted on servers that share a common storage system through a storage area network (SAN). An imbalance between application demands and central storage capabilities can degrade the overall performance of applications sharing central storage resources. This imbalance can affect the use by applications of several different system elements including servers (CPU and memory), bus adapters, switches, disk controllers, and disk arrays.

  Individual applications can be affected by performance if they place too much load on any particular system element in the path between the server and the supporting storage subsystem. In addition, multiple applications running on the same or independent servers can affect each other's performance when the network and storage are shared between the application and server, often deployed as a shared resource by the SAN Is done.

  The performance of any application can be reduced if the application generates too much load for a single device, or if multiple applications flood the system with many requests, thereby consolidating storage systems Unable to service the load.

  Interference caused by one application to another application when accessing the storage system can lead to large variations in performance. Attempts to provide more predictable application performance often lead to over-provisioning of system resources (eg, CPU, memory, network, disk).

  One known way of addressing some of the problems associated with storage platform resources is Storage Resource Management (SRM), which typically discovers the topology of an allocated resource set and determines its performance. Provides a measurement function to evaluate health status. System performance health can be measured in terms of response time and storage bandwidth. The SRM can detect storage resources with limited performance and report this to the storage administrator.

  To enable identification of application sets that use a particular networked storage resource set, a complete mapping between storage systems and applications is required. Mapping includes (1) information about all system resources used by the application (eg, individual disks, disk controllers, bus adapters) and (2) paths from the storage system to the application server (volume LUN mapping and network). Must include both).

As an example, US Pat. No. 7,058,545 (“the '545 patent”), which is incorporated herein by reference, identifies logical and physical data paths between storage devices and applications. Describes a method that does not have the ability to identify all system resources that make up a path. The '545 patent is directed to managing data paths to increase data path performance, reliability, or security, and does not address contention between multiple applications.
US Pat. No. 7,058,545

  Accordingly, it is useful to provide a method and system operable to efficiently map system resources to applications, particularly in a real world environment where multiple applications are running.

  It would also be useful to provide improved storage platforms and architectures that utilize such methods and systems.

  The present invention that meets these needs and provides other technical advantages and features will now be described in detail with reference to the accompanying drawings.

SUMMARY OF THE INVENTION The present invention is operable within a digital processing environment, and more particularly within a digital storage environment, and enables mapping between application sets to storage elements used within the digital storage environment, and Methods, apparatus, systems, and computer program code (software) products are provided that provide a hierarchical image of a set of applications (other software programs) that are creating a load on any storage element in a digital storage environment.

By way of example, one aspect of the invention provides: (A) at least one application server, bus adapter, network switch, disk controller, and disk array that are collectively storage elements in a digital storage environment; and (B) at least Provided is such a method, apparatus, system, and computer program code (software) product operable in a digital storage environment comprising two applications, the at least one application server, bus adapter, network switch, disk Collectively, controllers and disk arrays are storage elements within a digital storage environment. This aspect of the invention provides (A) an application resource group (ARG) operable to provide a mapping from an application set to storage elements used in a digital storage environment;
(B) defining subgroups operable to improve the granularity of the relationship between a single storage element and an application;
ARG includes ARG abstraction, which is
An application server group (ASerG) operable to identify applications that are loading the server,
An application adapter group (AAG) operable to identify applications that are loading the bus adapter,
An application switch group (ASwG) operable to identify applications that are loading the network switch;
An application controller group (ACG) operable to identify applications that are loading the disk controller, and an application storage group (ASG) operable to identify applications that are loading the disk array
Including at least one of
Each ARG abstraction contains at least one subgroup,
ARG and subgroups collectively provide a mapping from application sets to storage elements used within a digital storage environment, and a hierarchical image of the application set that is loading any storage element within the digital storage environment Is operable to provide

  In another aspect of the invention, ARGs and subgroups are collectively operable to provide a substantially complete mapping from application sets to storage elements used within a digital storage environment.

  In another aspect of the invention, the ARG and subgroup collectively collect the application set where multiple applications are competing for a single storage element and creating a bottleneck, where the ARG can be the cause of the bottleneck. Is operable to identify.

  In yet another aspect of the invention, the ASG abstraction is configured such that a single subgroup can be presented only within a single ASG abstraction.

  Further details, examples, and embodiments are described in the following detailed description that should be read in conjunction with the accompanying drawings.

  As noted above, the present invention is based on US patent application Ser. No. 11 / 773,825 (“Attorney Docket Number: AKR”) filed July 5, 2007, entitled “Managing Application System Load”. -110-US), the following detailed description first describes the invention of US patent application Ser. No. 11 / 773,825 (AKR-110-US) (Section A below). ~ D) and then follows the description of the invention (sections E and F below). Those skilled in the art will recognize that the digital processing, computing, or storage environment described in US patent application Ser. No. 11 / 773,825 (AKR-110-US) is among the examples of processing environments in which the present invention can be implemented. It will be understood that there are only a few and that the present invention may be practiced outside of the environment described in US patent application Ser. No. 11 / 773,825 (AKR-110-US).

  Those skilled in the art will readily understand the present invention based on the following detailed description taken in conjunction with the accompanying drawings.

1 is a schematic diagram of a conventional workstation or PC (personal computer) digital computing system that can implement the invention or form part of a networked digital computing system that can implement the invention. (Prior art). 1 is a schematic diagram of a networked digital computing system in which the present invention can be implemented (prior art). FIG. 2 is a schematic diagram of components of a conventional workstation environment or PC environment as shown in FIG. 1 (prior art). 1 is a schematic diagram of one embodiment of the present invention. 1 is a schematic diagram of a digital computing system in which the present invention can be implemented. FIG. 3 is a schematic diagram illustrating an application program having adjustable application parameters. FIG. 2 is a schematic diagram of an application running on a digital computing system and generating a system load. 1 is a schematic diagram illustrating a computing system and information resource manager (IRM) constructed in accordance with the present invention. FIG. FIG. 2 is a schematic diagram illustrating a database of performance statistics, configuration data, and application parameters for applications running on a computing system. FIG. 6 is a schematic diagram illustrating how performance information can be obtained from a computing system according to the present invention. FIG. 3 is a schematic diagram illustrating how configuration information can be obtained from each element of a computing system according to the present invention. It is the schematic which shows the aspect of the analysis model of IRM by one Embodiment of this invention. FIG. 6 is a schematic diagram illustrating how an analysis model can be constructed using configuration data, CPU statistics, network statistics, and SAN statistics in accordance with the present invention. FIG. 6 is a schematic diagram illustrating how an analysis model generates an updated application parameter set according to one implementation of the present invention. FIG. 6 is a schematic diagram illustrating how an application parameter set used by an application is updated using an updated application parameter according to an embodiment of the present invention. FIG. 6 is a schematic diagram illustrating how an Information Resource Manager (IRM) can maintain some CPU statistics, network statistics, and SAN statistics. FIG. 6 is a schematic diagram illustrating how multiple update statistics sets can be applied to an analysis model according to the present invention, where the analysis model then updates application data running on the computing system. FIG. 2 is a schematic block diagram of the main components of an ELM architecture according to an embodiment of the present invention. It is a figure which shows the timing of the statistics collection of ELM architecture. FIG. 5 is a table that provides a summary of the frequency of collection and calculation of ELM statistics. Fig. 6 is a table providing a summary of ELM statistics. Fig. 6 is a table providing a summary of ELM statistics. Fig. 6 is a table providing a summary of ELM statistics. Fig. 6 is a table providing a summary of ELM statistics. Fig. 6 is a table providing a summary of ELM statistics. Fig. 6 is a table providing a summary of ELM statistics. Fig. 6 is a table providing a summary of ELM statistics. Fig. 6 is a table providing a summary of ELM statistics. It is the schematic which shows the various connectors contained in the EDaC service by one implementation of this invention. 2 is a flowchart illustrating a method according to the present invention for optimizing the execution of multiple applications running on a digital computing system. 2 is a flowchart illustrating a method according to the present invention for optimizing the execution of multiple applications running on a digital computing system. 2 is a flowchart illustrating a method according to the present invention for optimizing the execution of multiple applications running on a digital computing system. FIG. 5 is a table in which levels, groups, and infrastructure elements according to further aspects of the present invention that provide multi-level mapping of application system storage resources are listed in columns. FIG. 3 is an illustration of an example computer infrastructure architecture suitable for implementing the described systems and techniques for multi-level mapping application system storage resources. FIG. 33 is a diagram showing groups formed from a subset of elements described in the architecture of FIG. 32; FIG. 33 is a diagram showing groups formed from a subset of elements described in the architecture of FIG. 32; FIG. 33 is a diagram showing groups formed from a subset of elements described in the architecture of FIG. 32; FIG. 33 is a diagram showing groups formed from a subset of elements described in the architecture of FIG. 32; FIG. 33 is a diagram showing groups formed from a subset of elements described in the architecture of FIG. 32; FIG. 4 is an alternative exemplary computer infrastructure architecture. It is a figure which shows the subgroup formed from the subset of the element described in the architecture of FIG. It is a figure which shows the subgroup formed from the subset of the element described in the architecture of FIG. FIG. 5 is a flowchart of a general technique according to a further aspect of the invention for multi-level mapping application system storage resources.

DETAILED DESCRIPTION OF THE INVENTION In the following description, numerous specific details are set forth in order to provide an understanding of the present invention. However, one skilled in the art will understand that the invention may be practiced without these specific details. In some instances, well known methods, procedures, components, protocols, algorithms, and circuits have not been described in detail so as not to obscure the present invention. The following discussion describes various aspects of the present invention, including aspects related to addressing the load on storage resources by appropriately adjusting application parameters and aspects related to balancing CPU, network, and SAN resources. The

  As noted above, the present invention is based on US patent application Ser. No. 11 / 773,825, filed Jul. 5, 2007, entitled “Managing Application System Load”. 110-US), the following detailed description first describes the invention of US patent application Ser. No. 11 / 773,825 (AKR-110-US) (see Sections A- D) and then the description of the invention (sections E and F below). Those skilled in the art will recognize that the digital processing, computing, or storage environment described in US patent application Ser. No. 11 / 773,825 (AKR-110-US) is among the examples of processing environments in which the present invention can be implemented. It will be understood that there are only a few and that the present invention may be practiced outside of the environment described in US patent application Ser. No. 11 / 773,825 (AKR-110-US).

This detailed description is organized in the following sections.
A. A digital processing environment in which the present invention can be implemented. Application system load management Application System Load Management-Further Details / Examples of Implementation C1. System architecture C2. External discovery subsystem C3. Discovery engine Application System Load Management-General Method E. Multi-level mapping of application system storage resources Multi-level mapping embodiment Knot

A. Prior to describing specific examples and embodiments of the present invention, the following is a description of the underlying digital processing structure and environment in which the present invention may be implemented and implemented. This should be read in conjunction with FIGS. 1, 2A, and 2B.

  One skilled in the art will appreciate that the present invention provides methods, systems, apparatus, and computer program products that allow more efficient application execution with applications commonly found in computer server class systems. . These applications include database applications, web server applications, and email server applications. These applications are typically used to support media simultaneously for a large group of computer users. These applications provide consistent and organized access and sharing by multiple users to a shared dataset. Applications can be hosted on multiple or a single shared set of digital computing systems. The task set executed in each application indicates the patterns and loads generated by the digital computing system, and the patterns and loads can be managed through configurable application parameter sets.

  Thus, the present invention can be implemented as a separate software application, part of a computer system containing system software, or dedicated computer hardware of a computer that forms part of a digital computing system. The present invention may be implemented as a separate stand-alone software-based or hardware-based system. Implementations may include user interface elements such as a keyboard and / or mouse, memory, storage, and other conventional user interface components. Conventional components of this type are well known to those skilled in the art and need not be described in further detail herein, and the following overview describes the present invention within such a digital computer system. Show how it can be implemented in conjunction with the element.

  In particular, those skilled in the art will appreciate that the present invention can be used for profiling and analysis of digital computer system performance and application tuning. The techniques described herein can be implemented as part of a digital computer system, and performance data is collected periodically and analyzed adaptively. The data can further be used as an input to an analytical model that can be used to estimate the impact of changing the current system. In this case, performance can be improved by reconfiguring the application running on the digital computer system.

  The following detailed description provides examples of methods, structures, systems, and computer software products according to these techniques. The described methods and systems operate according to (or emulate) a conventional operating system, such as Microsoft Windows®, Linux, or Unix®, either independently or over a network. Those skilled in the art will appreciate that conventional computer devices such as computers (PCs) or equivalent devices can be used to implement software, hardware, or a combination of software and hardware. Accordingly, the various processing aspects and means described herein can be implemented by software elements and / or hardware elements of an appropriately configured digital processing device or network of devices. Processing may be performed serially or in parallel and may be performed using dedicated hardware or reconfigurable hardware.

  As an example, FIG. 1 attached to this specification shows an exemplary computer system 10 capable of executing server class applications such as databases and mail servers. Referring to FIG. 1, in one embodiment, a computer system 10 is identified as a processor module 11 and a keyboard 12A and / or mouse 12B (or a digitizing tablet or other analog element, generically an operator input element 12). ) And operator interface elements including operator output elements such as video display 13. The exemplary computer system 10 can be of a conventional built-in program computer architecture. The processor module 11 can include, for example, one or more processors, memory, and mass storage devices such as disk and / or tape storage elements (not shown separately), in conjunction with the provided digital data. Perform processing and storage operations. An operator input element 12 can be provided to allow an operator to enter information to be processed. The video display device 13 receives information generated by the processor module 11 including data that can be input by the operator for processing, information that can be input by the operator for processing control, and information generated during processing. It can be provided for display on the screen 14 to the operator. The processor module 11 can generate information to be displayed by the video display device 13 using a so-called “graphical user interface” (“GUI”), and the video display device 13 has information about various application programs. It is displayed using various “windows”.

  The terms “memory”, “storage”, and “disk storage device” encode a computer hard disk, a computer floppy disk, a computer readable flash drive, a computer readable RAM element, a computer readable ROM element, or digital information. Any computer readable medium may be included such as any other known means. The terms “application program”, “application”, “program”, “computer program product”, or “computer software product” refer to whether a computer readable medium is fixed, removable, permanent, or erasable, etc. Rather, any computer program product consisting of computer readable program instructions encoded and / or stored on a computer readable medium may be included. As described above, for example, in block 122 of the schematic block diagram of FIG. 2B, applications and data are stored on disk, RAM, ROM, other removable storage, fixed storage according to implementations and techniques well known in the art. Regardless of whether they are internal or external, they can be stored and downloaded or uploaded. As described herein, the present invention may take the form of software or a computer program product stored on a computer-readable medium, which may be uploaded, downloaded, in an FPGA, ROM, or other electronic structure. It may be in the form of computer program code that may be fixed, or it may take the form of a method or a system that performs such a method. The computer system 10 is shown with certain components, such as a keyboard 12A and mouse 12B for receiving input information from an operator, and a video display 13 for displaying output information to the operator. It will be understood that various components may be included in addition to or in place of the components shown in FIG.

  In addition, the processor module 11 can include one or more network ports, identified generally by reference numeral 14, that are connected to a communication link that connects the computer system 10 to the computer network. The network port allows the computer system 10 to send information to and receive information from other computer systems and other devices in the network. For example, in a typical network organized according to a client-server paradigm, a particular computer system in the network is shown as a server and data and programs (generally “information”) that are processed by other client computer systems. Store so that client computer systems can conveniently share information. Client computer systems that need to access information held by a particular server allow the server to download information over the network. After processing the data, the client computer system can also return the processed data to the server for storage there. In addition to the computer system (including the server and client described above), the network may include, for example, a printer and a facsimile apparatus, a digital audio or digital video storage / distribution apparatus, and the like, and these are connected to the network. Can be shared on Communication links interconnecting computer systems in a network may include any convenient information carrying medium, including wires, optical fibers, or other media that carry signals between computer systems, as is conventional. The computer system transfers information over the network by messages transferred over the communication link, each message including an identifier identifying the information and the device receiving the message.

  In addition to the computer system 10 shown in the drawings, the method, apparatus, or software product according to the present invention includes a conventional PC 102, laptop 104, handheld or mobile computer 106, or over the Internet or other network 108, As shown by way of example in FIGS. 2A and 2B, which may include a server 110 and storage 112, whether stand-alone, networked, portable, or fixed (eg, network system 100 ) And any other wide range of conventional computing devices and systems.

  Alongside implementations in conventional computer software and hardware, a software application constructed in accordance with the present invention can also run in a PC 102 as shown, for example, in FIGS. 1, 2A, and 2B. If so, the program instructions can be read from ROM, CD-ROM 116 (FIG. 2B), magnetic disk, or other storage 120, loaded into RAM 114, and executed by CPU 118. Data can be entered into the system via any known device or means including a conventional keyboard, scanner, mouse, digitizing tablet, or other element 103. As shown in FIG. 2B, the illustrated storage 120 includes removable storage. As further shown in FIG. 2B, applications and data 122 may be located in some or all of fixed storage, removable storage, or ROM, or downloaded.

  The method aspects of the invention described herein are field programmable gate arrays (FPGAs) specifically constructed to perform the processes described herein using ASIC construction techniques known to ASIC manufacturers. Or a hardware element such as an application specific integrated circuit (ASIC). The actual semiconductor elements of a conventional ASIC, equivalent integrated circuit, or other conventional hardware element that can be used in the practice of the present invention are not part of the present invention and are not discussed in detail herein.

  Using the teachings of the present invention described in more detail herein, an ASIC or other conventional integrated circuit, or the like, to perform the method of the present invention described below in further detail, eg, shown in FIG. Those skilled in the art will also understand that semiconductor devices can be implemented.

  The method aspects of the present invention can be carried out in commercially available digital processing systems such as workstations and PCs operating under a workstation or personal computer (PC) operating system and a computer program product constructed in accordance with the present invention. Those skilled in the art will also understand. The term “computer program product” can encompass any set of computer readable program instructions encoded on a computer readable medium. The computer readable medium may be local or remote from a workstation, PC, or other digital processing device or system, computer hard disk, computer floppy disk, computer readable flash drive, computer readable RAM element, computer. It can include any form of computer readable elements including, but not limited to, readable ROM elements or any other known means of encoding, storing or providing digital information. Various forms of computer readable elements and media are well known in the computing arts and the choice is left to the implementer.

B. Application System Load Management Next, examples and embodiments of systems and techniques for managing application system load according to various aspects of the present invention described in US patent application Ser. No. 11 / 773,825 (AKR-110-US) will be described. . This application is a continuation-in-part (CIP) of US patent application Ser. No. 11 / 773,825.

  Applications are typically hosted on servers that share a common network and storage system through a storage area network (SAN). The imbalance between application demands and CPU, network, and SAN capabilities leads to a decrease in the overall performance of applications sharing central resources. However, an individual application can be affected by performance if it imposes too much load on any single element in the subsystem, especially the SAN. Furthermore, the CPU, network, and storage array are often used as shared resources. Multiple applications running on independent servers can affect each other's performance when subsystem elements are shared between applications.

  Many applications have internal parameters, which can be set by a user or system administrator and can dramatically affect the performance and throughput of the application. Users typically do not consider the bandwidth that can be maintained in a computing system configuration or the existing parallelism when an application is initialized for execution. A default value set is generally used to set the system load. These default values may include, for example, the number of threads, individual application priority, storage space, and log buffer configuration. These values can also be adjusted during runtime. These values can be adjusted by the user, application programmer, or system administrator, but no guidance is provided to adjust the application load to better match the characteristics of the underlying computing system resources.

  The performance of any application is when the application generates too much traffic for a single device, or when multiple applications flood the system with many requests that the system cannot service the collective load. Can be reduced. When any element in the system is overloaded, the interference that one application creates with respect to another application can cause large variations in performance. Attempts to provide more predictable application performance often lead to over-provisioning of the capacity of specific elements within the subsystem.

  In an attempt to solve or at least minimize these issues, the system administrator can require that each application have a fixed priority. The priority setting is used to “suppress” application requests for system resources. Unfortunately, fixed priority assignments can waste resources and can lead to application starvation. An alternative to throttling can manage the quality of service (“QoS”) that each application is experiencing. The allocation of storage resources can be based on various criteria, such as storage access bandwidth. US Patent Application Publication No. 2005/0089054 describes an apparatus that provides resource allocation based on QoS, which is incorporated herein by reference in its entirety.

  Conventional solutions to the above concerns have typically presented their own performance constraints and concerns. Accordingly, it would be desirable to provide improved methods, apparatus, software, and systems that more efficiently and flexibly manage system loads generated by one or more applications.

  Rather than allocating disk or bandwidth to individual servers or applications, the systems and techniques described herein take advantage of the internal tuning facility provided by the application and the storage subsystem provided. A parameter set adjusted based on the characteristics of Furthermore, the present invention also considers the resources of a fully digital computer system, such as a networked digital computing system. The described systems and techniques utilize existing performance monitoring systems and techniques developed in commercial operating systems such as Microsoft Windows®, Linux, and Unix®. The described systems and techniques that allow applications to be adaptively tuned through runtime parameter sets utilize existing interfaces to tune database and email applications. The present invention further provides QoS guarantees through careful provisioning of available system resources to manage multiple applications in parallel.

  Conventional methods used to configure application parameters to determine system performance have several significant drawbacks. That is, (1) the adjustment methods that have been used to date are not based on trial and error iterative adjustments, and (2) the user has the underlying CPU, network, and storage subsystem to guide the selection of adjustments (3) Little consideration is given to managing multiple applications or multiple servers using a shared digital computing system in parallel, and (4) the characteristics of the digital computing system now There is no generally accepted way to convert the to individual application parameter changes.

  Some applications are sensitive to the latency of storage access operations, while others are not. Database and mail server applications often access data in non-sequential mode, and sometimes it may be necessary to wait for an access or series of accesses to complete before issuing another command It is particularly susceptible to latency related to storage access operations.

  Many latency sensitive applications such as database systems, mail servers, etc. have the ability to perform self-tuning. For example, Oracle 10g provides a query optimizer that can accelerate the performance of future queries based on recent query behavior. Oracle 10g also has over 250 tunable parameters that can affect database performance. These parameters affect the utilization of memory resources, such as caches and buffers, and can define parallel accessible amounts, such as threading.

  The described systems and techniques target the proper setting of these internal parameters by utilizing information about the underlying CPU subsystem, network subsystem, and storage subsystem. As described herein, the CPU subsystem information includes both the type and number of processors in use and the associated memory hierarchy, and the network subsystem information includes the speed and configuration of the network switch being used and Including the speed of the adapters connected to the switch, the storage subsystem information includes the characteristics of the physical disk devices, the grouping of these devices into RAID groups, the mapping of logical addresses to RAID groups, and the individual passing through this system Includes path throughput. A further aspect of the invention provides the ability to obtain storage subsystem information by capturing the runtime characteristics of the system. This information can be obtained by running a customized exerciser or observing the normal execution of the system.

  Adjustment of application parameters can be done at application initialization or dynamically. The method used to capture the different characteristics of the underlying subsystem performance is static, i.e. a predetermined method, which may be shipped with the storage system or acquired dynamically through profiling. Good. The presently described invention includes both a method for statically specifying this information and a method for obtaining this information through profiling. According to a further aspect of the invention, this information is provided as feedback to the application so that system parameters can be adjusted automatically or by a system / application administrator.

  In the above discussion, we have discussed the need to adjust the parameters of applications that are sensitive to performance to make the best use of digital computing resources. One embodiment of an apparatus and system for adjusting such parameters is shown in FIG.

  As shown in FIG. 3, the application server 290 may be connected directly to the server 260 or may be connected to the server via the storage area network 270 using the switch fabric 250. Access an element. This is just one possible organization of servers and storage systems. The present invention does not require a specific organization.

  Accordingly, the presently described aspects of the present invention introduce elements that can communicate to both servers and storage systems. This element is referred to herein as Storage System Aware Application Coordination System (SSAATS) 280. This element and similar structures and functions are also described, and are referred to below as information resource management (IRM) systems. As described below, further aspects of the invention provide other named elements that perform some or all of the functions of the SSAATS element.

The SSAATS embodiment shown in FIG. 3 includes three sub-elements. That is,
(1) Storage network profiling system 210,
(2) analysis model 220, and (3) application parameter determination subsystem 230
It is.

  The SSAATS element 280 may be implemented as a stand-alone subsystem or may be integrated as part of the server subsystem 290 or the network fabric subsystem 240.

  Profiling subsystem element 100 has the ability to determine the degree of parallelism in the storage network and can estimate the bandwidth and latency values of the underlying storage systems 260 and 270 as described above. The profiling subsystem element 210 can also determine the bandwidth value and latency value of the existing network fabric element 250.

  The profiling subsystem element 210 obtains performance related information that is not always available from the storage system manufacturer. When a storage system is installed, the available storage can be organized in many different organizations. As such, even if some performance-related information is provided by the manufacturer, most of the required information is only relevant after the storage system is installed and configured.

As necessary performance-related information, for example,
(1) CPU, network, and parallelism available within the SAN,
(2) Speed of various devices,
(3) The bandwidth of the path between the application server, the network, and each storage device, and (4) the configuration of the storage device viewed from the server, but is not limited thereto.

  A series of input / output commands can be issued to the storage subsystem in order to obtain the necessary performance related information. Necessary performance-related information can be obtained based on the response time and throughput of a particular command sequence. This information is then provided to the analytical model element 220.

  The analysis model element 220 acquires profile information from the profiling storage network 210. Profiling data is used by the analytical performance model 220, which is used to establish the proper load that the application server 290 CPU subsystem, network subsystem 250, and storage subsystems 260 and 270 can sustain. . The output of the analysis model element 220 is fed to an element that determines the parameter value 230, which then communicates these values to the application server 290, which in turn passes the internal parameters of the application. Set.

  In one optional embodiment, the profiling system continues to profile the performance of the storage system through the profiling network 210, provides a dynamic profile to the analytical performance model 220, and communicates a new set of application parameters from the parameter determination system 230 to the application server 290. can do. The key features of this optional embodiment include: (a) the profiling system cannot introduce significant overhead into the digital computing system that could reduce the benefits gained through parameter changes; and (b) the system It includes that the system must ensure that adequate control is provided to reduce the frequency of parameter changes so that they do not continuously adapt to performance transitions.

  In one optional embodiment, the profiling system 210 can communicate directly with the storage resources 260 and 270 through the network interface to further improve the use of available system configurations, which is referred to herein as “ It is called “Discovery”.

  The analytical model 220 described herein uses standard queuing theory techniques to establish the amount of load that the storage subsystem can sustain. In particular, analytic model 220 can apply known queuing theory equations, algorithms, and techniques to determine the storage load that can be supported. Such equations, algorithms, and techniques are, for example, Kleinrock, L., Queueing Systems: Volume I-Theory (Wiley Interscience, New York, 1975), Kleinrock, L., Queueing Systems: Volume II-Computer Applications ( Wiley Interscience, New York, 1976), both of which are incorporated herein by reference as if set forth in their entirety. The parameter determination element then converts these load values into specific parameter values for the target application. According to a further aspect of the invention, SSAATS 280 includes a plurality of parameter determination elements 230, one for each application software.

  The determination of the application parameter unit 230 takes into account several application specific parameters. One particular parameter set includes, for example, cost-based optimization (CBO) parameters provided within Oracle 10g. These parameters can control how indexing and scanning are performed within Oracle and the degree of parallelism expected by the application. For example, the multi-block read count can be set to adjust the access size, or parallel auto-adjustment can be set to perform a parallel table scan.

  In many situations, it may be beneficial for the storage administrator to distinguish applications by latency sensitivity. While the currently described mechanism aims to reduce system resource requirements for individual applications, the network and storage are generally shared by different applications, so multiple applications can be managed using the same system. it can.

  If the network and storage are shared by different applications, the analysis model 220 can be adjusted to capture the impact of competing application workloads. Two typical workloads are an online transaction processing workload and a competing storage backup workload. While the backup application is performing critical operations, execution of online transaction processing applications should be prioritized.

  If multiple applications are sharing the same set of IO storage resources 260 and 270, the determination of the application parameter unit 230 will need to adjust multiple parameter value sets to aid in sharing.

  If multiple applications share the same set of IO storage resources 260 and 270, and the system administrator user wants to prioritize the throughput of each application, the application parameter unit 230 determines the IO request of one application. Can be further adjusted to prioritize the IO request of the other application.

  A further embodiment of the system according to the invention will now be described, and the above-described elements and others will be described in further detail.

  FIG. 4 is a diagram illustrating elements of an exemplary computing system 300 that includes a central processing unit (CPU) 301, 302, 303, a network element 310, and a storage array network 320. The configuration shown is typical of many server class computing systems currently available. As described herein, aspects of the present invention are directed to systems and techniques that improve the performance of the system 300 by building an analytical model of the system 300. The analysis model is first constructed by acquiring system configuration information and runtime performance statistics for different elements. The analysis model is provided with knowledge about a particular application set running on the system 300. The output of the analysis model includes recommendations on how to adjust the performance parameters as well as application parameters related to the application running on the computing system 300. The output of the analysis model can then be used to improve the future performance of the application.

  FIG. 5 shows a diagram of an application 350 that includes program code 360 and an application parameter set 370 that are used to configure how the application 350 is executed in the computing system 300.

  FIG. 6 shows a diagram of an application 350 running on the CPU1 301, which is supplied with an application parameter set 370 and creates a load on the system.

  FIG. 7 shows a diagram illustrating a computing system 300 and an information resource manager 400. The information resource manager 400 includes an analysis model 410 and is executed on a number of computing system performance statistics 430, including CPU statistics 440, network statistics 450, and SAN statistics 460, computing system configuration data 470, and computing system 370. It maintains a database 420 with application parameter sets 370 for the application sets that are present.

  FIG. 8 shows a database 420 of CPU statistics 440, network statistics 450, SAN statistics 460, configuration data 470, and application parameters 370 for applications running on the computing system 300.

  FIG. 9 shows a diagram illustrating an example of how performance statistics can be obtained from the computing system 300. CPU statistics 440 can be obtained from CPU1 301 using standard software utilities such as iostat 510 and perfmon 520. Network statistics 450 can be obtained using the SNMP interface 530 provided in most network switch devices. The SAN statistics 460 can be obtained via the SMIS 540 provided for many SAN systems 120. The interface shown in FIG. 9 represents one particular set of interfaces that obtain performance statistics from different elements, but does not exclude that the information resource management unit 400 has access to additional interfaces of the available computing system.

  FIG. 10 shows how the configuration data 410 is obtained from each element of the computing system 100. Each vendor of a different computing system element 100 typically provides an interface for reporting this information.

  FIG. 11 shows a diagram of an analysis model 410 that is part of the information resource management unit 400. The purpose of the analytical model 410 is both to generate a performance indicator and to generate an updated application parameter set 372 (FIGS. 13 and 14) to improve the performance of applications running on the computing system 300. It is.

  FIG. 12 shows how the configuration data 470 and CPU statistics 430, network statistics 430, and SAN statistics 440 are used to build the analysis model 410. FIG. The analysis model includes models of CPU 411, network 412, and SAN 413, and may include additional computing system elements.

  FIG. 13 shows how the analysis model 410 generates the updated application parameter set 372. This new parameter set is supplied to the computing system to reconfigure how the application 350 running on the system uses the elements of the computing system. The goal is to improve system performance.

  FIG. 14 shows how the update application parameters 372 are used to update the application parameter set 370 used by the application 350. Although FIG. 14 shows an application running on CPU 1 301, the application may run on any CPU in systems 302, 303 or any other element in system network 310 or SAN 320.

  FIG. 15 illustrates that the information resource management unit can maintain several CPU statistics 442, network statistics 452, and SAN statistics 462. These records are usually arranged in chronological order, providing a longer term behavior of the system. This record set may also represent performance statistics generated for multiple applications running on the computing system. The analytical model 410 is again applied to this richer set of statistics, and the analytical model 410 then updates the application data 372 running on the computing system. This technique is further illustrated in FIG.

C. Application System Load Management-Further Details / Examples The following discussion provides further details regarding one or more examples of implementations according to various aspects of the invention. The following is presented by way of example only, and it will be understood by those skilled in the art that the present invention can be implemented and implemented in different configurations and embodiments without necessarily requiring the specific structure described below. . The following discussion is organized into the following subsections.
C1. System architecture C2. External discovery subsystem C3. Discovery engine

C1. System Architecture The currently described architecture is generically referred to herein as an event level monitor (ELM). The ELM architecture supports the following ELM product features: That is, (1) data center visibility, (2) hot spot detection, and (3) analysis.

  To support these functions, the ELM architecture provides the following features: Configuration / topology discovery, statistics collection, statistics calculation, application specific storage topology and statistics, analysis, and alarm event generation.

  FIG. 17 shows a block diagram of the major components of an exemplary embodiment of ELM architecture 600. Each illustrated component will be described in turn.

  Platform 610: Platform 610 provides the foundation and basic environment in which IRM 400 is executed.

  Linux 620: Linux OS 620 provides low level functionality to the platform.

  Component Task Framework (CTF) 630: Component Task Framework 630 provides a useful set of common primitives and services, messaging, events, memory management, logging and tracing, debug shells, timers, synchronization, and data manipulation Including a hash table, a list, and the like.

  MySQL 640: A data store (DS) 650, which is a repository of system data, is stored in a central database built on top of MySQL 640.

  Data Store (DS) 650: The DS 650 includes discovered elements, their relationships or topology, and their statistics.

  Information Resource Manager (IRM) 400: The information resource manager (IRM) 400 is responsible for collecting all information, topology, and statistics about the data center, as described above.

  External Discovery and Collection (EDaC) 700: External Discovery and Collection (EDaC) 700 is a component that provides the system with connections to elements such as servers and storage arrays in the data center, as further described below. Know how to communicate with a particular element, eg CLARiiON storage array, discover the topology of that particular element, or collect statistics from that particular element. Thus, having a separate module or collector for a particular array or server. For various elements, there is a standard API that is defined in XML and that every collector conforms to.

  Discovery engine 660: Discovery engine 660 performs topology discovery of data center elements, particularly servers and storage arrays. The user enters the server or storage array that he wants to discover. The discovery engine 660 accesses the data store 650 to obtain a list of servers, networks, and storage arrays entered by the user. For each one, the discovery engine 660 requests the EDaC 700 to obtain a topology. The EDaC 700 queries the element and returns all found information, eg, storage array disks. The discovery engine 660 then places this information in the data store 650 and connects these relationships. At the first discovery of a server, discovery engine 660 also notifies statistics manager 670 to start collecting statistics from that server. In addition, the discovery engine 660 periodically wakes up and “rediscovers” elements of the digital computing system 300. Thereby, an arbitrary topology change can be found.

  Statistics manager 670: Statistics manager 670 collects statistics from computer system elements, particularly servers. In current products, statistics are collected only from the server, but using these statistics, statistics for other data center elements are derived as well. The statistics manager 670 is notified by the discovery engine 660 when a new server is discovered. The statistics manager 670 then adds the server to the collection list. The statistics manager 670 periodically wakes up and looks through the collection list. For each server in the collection list, statistics manager 670 requests EDaC 700 to collect statistics. When the EDaC 700 collects server statistics, it sends these statistics to the statistics manager 670. The statistics manager 670 processes these statistics and inserts them into the data store 650. Some statistics are added to the data store 650 without change, others are added after some simple processing such as averaging, and more sophisticated algorithms that derive completely new statistics Some are processed by.

  Statistics monitor 680: New statistics are always collected and calculated. This means that the user can go back in time to see what was happening in the system. All statistics are stored in a data store (DS) 650. Stored statistics include calculated statistics as well as collected statistics. This makes it possible to always use the statistics immediately for display.

  The statistics monitor 680 monitors and manages the deployed statistics as the statistics are entered into the data store 650 by the statistics manager 670. Within statistics monitor 680 are a number of daemons that wake up periodically and perform different tasks on the statistics in data store 650. These tasks include the creation of summary statistics, for example, the aggregation of collected statistics into time statistics, the calculation of a moving average of a statistic, the comparison with a statistic threshold and the generation of an event, and finally Alarm generation is included when the threshold is exceeded.

  There are different types of statistics that are calculated and analyzed. Some of these include:

  Calculated statistics: Calculated statistics are created by performing calculations on collected statistics or other calculated statistics. The calculation may be as simple as an addition or as complex as performing a non-linear curve fit. The calculated statistics are stored in the DS 650 in the same manner and format as the collected statistics.

  Calculated storage statistics: It is important to note that all storage statistics are derived from statistics collected from the server LUN. The discovered server and storage array topology is then used to derive statistics for other storage objects: server volumes, storage array LUNs, ASGs, and subgroups.

  Collection and calculation frequency: Statistics collection is performed so that the utilization can be calculated when the system is statistically stable. Statistical stability does not mean that the statistics do not change, but rather that the system is performing the same type of work or set of work over time. Utilization calculations require a series of samples. Therefore, a series of samples must be collected in a short period of time to calculate utilization over a statistically stable period. However, collecting statistics on a significant number of servers frequently and continuously places too much strain on the system. The above requirements / constraints are met by collecting statistics in bursts as shown in FIG.

The parameters have the following meanings:
Major Period Time between sample bursts. The range is 5-60 minutes.
Minor Period Time between each sample in the burst. The range is 1-10 seconds.
The number of samples taken in each major period at the burst minor period rate. The range is 1-50 samples.
These parameters are variable for each server. Therefore, statistics for one server are collected with a major period of 30 minutes, a minor period of 10 seconds, and a burst size of 10, and statistics for another server are collected with a major period of 15 minutes, a minor period of 1 second, and a burst size of 25. It is possible to collect. Statistics that are not used to calculate utilization are collected at a frequency of once every major period. The statistics collected in bursts are used immediately in the utilization calculation. The result of the usage rate calculation is stored in the DS, and unprocessed data is discarded. Therefore, the statistics are inserted into the DS once every major period for each server.

  Server statistics calculation frequency: All statistics for the server: CPU, memory, LUN, and volume are collected and calculated simultaneously. This is done at the server's major sample rate.

  Application storage group / storage group statistics calculation frequency: A particular problem is the calculation period of the application storage group (ASG) and storage group (SG). ASG and SG statistics are calculated from server LUN statistics that may have been sent from different servers. In general, these server LUN statistics are collected at different times and potentially at different rates. This means that ASG / SG statistics cannot be calculated in major sample periods. ASG / SG statistics must be calculated at a rate lower than that so that multiple samples from each server LUN can be used.

  Current state update frequency: Many objects have a current state, a history state, and a trend state. The current state is calculated relatively frequently but is lower than the major sample rate.

  History state and trend update frequency: History state and trend are longer term indicators and are calculated less frequently.

  Summary calculation frequency: Summary is a mechanism that saves space in the database. The summary operates on the theory that older data is less valuable and does not need to be viewed at the same granularity as newer data.

  Discovery frequency: Discovery collects relatively static data about the environment. Therefore, it is not necessary to execute it very frequently. However, this needs to be balanced with the desire to quickly reveal any changes.

  Collection and Calculation Frequency Summary: The table shown in FIG. 19 provides a summary of collection and calculation frequency. Note that all acquisition and calculation parameters should be parameterized so that they can be changed.

Statistical Summary: The tables shown in FIGS. 20-27 provide a statistical summary of the ELM system described herein.
Figure 20-Collected Server Statistics Server statistics are collected from the server. These are dynamic statistics that are frequently collected at major sample period rates.
Figure 21-Collected Server Attributes Server attributes are collected from the server. These are relatively static parameters that are not collected very often at the discovery rate.
FIG. 22-Stored Server Attributes Server attributes are collected from the server. These are relatively static parameters that are not collected very often at the discovery rate.
FIG. 23-Stored Server Current Statistics Server statistics are generated from the collected server statistics and stored in the database. One of these should be generated every major sample period per server.
FIG. 24-Server Summary Statistics Summary server statistics are a summary of server statistics from a shorter period to a longer period. For example, major period statistics can be combined into daily or weekly statistics.
FIG. 25-Stored Storage Statistics There is a common storage statistic that is used to store various storage object statistics. The frequency with which storage statistics are generated depends on the object for which the statistics are being generated. Server volume-once every major sample period, server LUN-once every major sample period, once per application storage group-application storage group / storage group calculation period, subgroup-application storage group / storage group calculation period Once every time.
Figure 26-Stored Storage Statistics Not all statistics are valid for every object. The table in FIG. 26 shows which statistics are valid for which objects.
FIG. 27-Stored Summary Storage Statistics Summary storage statistics are a summary of storage statistics from shorter to longer periods. For example, major period statistics can be combined into daily or weekly statistics.

Analysis: Analysis uses data stored in the data store, primarily topology and statistics, to inform the user about what is happening in the system or make recommendations about the system. The analysis can be implemented as a ruleset that is executed by the rules engine on the data in the data store or as an analysis model used to adjust application parameters. There are several different types of analysis that can be performed. These include:
Application point-in-time analysis Analyzes how an application is performing at a point in time and resource usage.
Application Delta Time Analysis Analyzes what has changed in application performance between two time points and resource usage.
Application Storage Group Analysis Analyzes a path between an application and storage at a certain point in time to determine whether the path is a hot spot and whether there is an application conflict with the path.
Storage provisioning recommendations Make recommendations on where to provision more physical storage for applications.
Application recommendation Make changes to application parameters

  In addition to the above, various APIs (application programming interfaces) built according to known API implementations may be provided to various points and layers to provide the interface as desired by the system designer, administrator, or others. Those skilled in the art will understand that.

C2. External Discovery and Collection Service The above described external discovery and collection (EDaC) service that provides access to all configuration and statistics for resources external to the device will now be described in further detail. The EDaC service is responsible for dispatching requests to any external resource. FIG. 28 is a diagram illustrating various connectors included in an exemplary embodiment of an EDaC service 700. Each connector 730 provides access to specific resources.

  The charge list includes: (1) listen for and forward statistics request events to the appropriate connector; (2) listen for discovery request events and forward to the appropriate connector; and (3) send discovery requests on any schedule Run on the connector to generate a discovery event. According to a further aspect of the invention, the function of item (3) may be transferred to an information resource manager (IRM).

There are two parts to the discovery process. That is, (1) “find” a device, and (2) grasp the most static configuration of the device. The discovery algorithm must be robust enough to handle thousands of devices. The complete discovery process can take several hours. Regarding configuration, the following data is needed to achieve discovery and collection in the object model.
Server: IP address, login / password, SSH / telnet, Solaris, polling interval and persistent connection Storage array: Management server, login / password, path to CLI, polling interval, persistent connection Application: IP address, Login / password, service name, port, polling interval, persistent connection

  Various well-known data access tools can be utilized in conjunction with this aspect of the present invention, and multiple access methods can be utilized, including configurable access methods. These may include telnet access to the server, database data access via ODBC (available from the DataDirect Technologies (Bedford, MA) commercial OBBC library), SSH techniques, and other conventional techniques.

  A sequence event broker 710 provides an interface to the EDaC core 720 and includes the connector 730 described.

  The Oracle database connector 730a is responsible for database configuration and database statistics collection. The Oracle database connector 730a uses the ODBC library 740.

  The Windows (registered trademark) server connector 730b and the Solaris server connector 730c are responsible for memory usage and collection of OS level data such as volume / LUN mapping and statistics. In order to calculate volume / LUN mapping, it may be necessary to keep track of both the installed volume manager as well as the multipath product. Even if it is not necessary to know the details, ie striping characteristics or path information, it is likely that information will be needed from each product just to calculate which LUN is associated with the volume. A specific product targeting the ELM can be selected. The Solaris server connector 730c uses SSH. The Solaris volume manager is Veritas and native. The Windows (registered trademark) server connector 730 b uses the WMI library 750. The Windows® volume manager is native and is Veritas.

  Storage connectors 730d, 730e, and 730f are responsible for collecting LUN utilization, performance, and mapping to RAID sets / disks and other data that is comprehensively represented in box 760. Array performance statistics are not required for ELM.

  For CLARiiON storage connector 730d, Navi CLI is a rich CLI interface to CLARiiON. This can return the data in xml. Performance statistics are enabled for CLARiiON and can be retrieved through the CLI. It is also possible to install CLI on ASC. It is likely that the CLI will be accessed through SSH 780 from one of the customer servers. Some data is also provided directly to CLARiiON by telnet.

  For Dothill storage connector 730e, Dothill also has a host-based CLI. Data can be returned in xml. Dothill does not provide access to performance statistics. The access problem is the same as in CLARiiON CLI. Some data is also provided directly to Dothill by telnet.

  A suitable HP storage connector 730f is also provided.

  As represented by box 730g, the currently described system changes the following elements: CIM / WBEM / SMI-S access, SNMP access, fabric connector, external SRM connector, remote proxy / agent, configuration Can be modified and expanded to include events. In addition, a single Windows agent can act as a gateway to the “Windows world” and integrates more seamlessly with WMI and ODBC. These future access tools are represented by box 770.

C3. Discovery Engine The discovery engine mentioned above is described in more detail below. The discovery engine (DE) resides in an information resource manager (IRM). The discovery engine is responsible for initiating periodic topology discovery of servers and storage arrays entered into the data store (DS) by the user. This is done in conjunction with the external discovery and collection (EDaC) module described above.

The DE is built around the main loop that processes messages from the message queue. These messages include the following:
Discovery timer event This event initiates a complete discovery process.
Discovery Complete Events These were originally sent by EDaC to DEaC and are now storage array topology discovery events and server topology discovery events returned by EDaC after EDaC has generated all discovery events for the server or storage array. is there. These events indicate that topology discovery is complete for the server or storage array.
Object Discovery Event EDaC generates a discovery event for each object found in the process of determining the server or storage array topology. For example, when EDaC is requested to determine the topology of a server, it generates discovery events for a server, a server FC port, a server volume, and a server LUN.

  The main loop can simply wait for the next message to process on the message queue.

  Discovery timer event: The DE uses the component task framework (CTF) to set the discovery interval timer. If the timer expires, the CTF generates a message and sends it to the DE message queue. This notifies the DE that it is time to start the discovery process.

  The discovery timer event causes the DE to initiate N initial discovery server topology events or discovery storage array topology events in parallel. N is an arbitrary number. There will always be N outstanding discovery topology events until there are no servers or storage arrays to discover the topology.

  Server or storage array discovery completion event: A server or server array discovery completion event is actually a server topology discovery event or storage array topology discovery event returned to the DE after EDAC has completed discovery for that object.

Discovery completion event processing: This processing step is as follows.
1. The DE queries the DS to find out if there is any existing record that was not found during the object topology discovery, eg, server LUN. The DS does this by creating a query for all records where the discovery timestamp is not the same as that of the current record.
2. For each record that does not match the time stamp, a lost event, eg, a server volume lost event, is generated and transmitted.
3. If there are more servers or storage arrays to discover, the next one is retrieved from the DS and a topology discovery event for it is sent to EDaC.
4). If there are no more servers or storage arrays to discover, discovery is complete and the discovery interval timer is restarted.

  Object Discovery Event: Upon receiving a topology discovery event, EDaC queries the server or storage array for topology. The topology consists of a record set. EDaC generates a discovery event set for the current event. It is important that discovery events occur in a specific order.

  Server topology discovery event: Server discovery event, server FC port discovery event, server volume discovery event, server LUN discovery event.

  Storage array topology discovery event: storage array discovery event, storage array FC port discovery event, storage array disk discovery event, storage array LUN discovery event.

  Each discovery event includes a time stamp of the discovery. The time stamp is inserted by EDaC. Each discovery event for a particular storage array or server has the same timestamp value.

Discovery process: This process step is as follows.
1. The DE queries the data store to determine whether a record already exists.
2. If the record already exists, the record relationship is verified and the discovery timestamp is updated.
3. If a record does not exist in the DS, a record is created with a relationship to other records. Therefore, the processing at this step is especially for the record under discovery.
4). A “record found” event is created and stored in the log.

D. Application System Load Management—General Method FIG. 29A is a flowchart of a general method 800 for optimizing the execution of multiple applications running on a digital computing system. The method advantageously includes at least one central processing unit (CPU), a network operable to allow the CPU to communicate with other elements of the digital computing system, and at least one storage device. Can be implemented in a networked digital computing system including a storage area network (SAN) operable to communicate with at least one CPU. The computing system is operable to execute at least one application program, the at least one application program having application parameters that are adjustable to control execution of the application program.

  An exemplary method according to the present invention is shown in boxes 801-803.

  Box 801: Utilizing an Information Resource Manager (IRM) operable to communicate with elements of a digital computing system, obtain performance information regarding the operation of the computing system and resources available within the computing system, and at least one Communicate with the CPU, network, and SAN to obtain performance information and configuration information therefrom. As noted elsewhere in this document, the performance information and configuration information may be from any CPU, network, or storage device in the digital computing system. Information can be obtained by issuing I / O or other commands to at least one element of the digital computing system. The IRM may be a discrete module in a digital computing system or may be implemented as a module in a computing system subsystem or a storage network fabric subsystem in a SAN.

  Box 802: Utilizing performance information and configuration information to generate an analysis model output, where the analysis model output includes any of performance statistics and updated application parameters. As noted elsewhere in this document, the present invention can utilize queuing theory to determine the degree of load that a storage system or subsystem can support.

  Box 803: Utilizing the analysis model output to determine an updated application parameter value and sending the updated application parameter value to at least one application running on the digital computing system, where the application uses the updated application parameter value. Application parameters, thereby using update runtime parameters to optimize the execution of multiple applications running on the digital computing system. As noted elsewhere in this document, this method can use load values, eg, load values determined using queuing theory, to determine parameter values for a given application. . The method may also include taking into account a number of application specific parameters, such as cost based optimization (CBO) parameters, in determining the updated application parameter value.

  FIG. 29B shows how the method 800 of FIG. 29A can be repeated or otherwise performed in a continuous manner to continue profiling storage system performance during operation, thereby providing a sequence of time Collecting a sample of a base (804), generating an update profile in response to a time-based sample (805), and an update application when a given application is executed in response to the update profile Including by sending (806) the parameter set. As noted elsewhere in this document, this method provides a selected degree of control over the frequency of application parameter updates so that the system does not continuously adapt to performance transitions in performance states. Can be included. The method may also include communicating directly with the individual elements of the digital computing system via the discovery interface (the exemplary correspondence between FIG. 29B and FIG. 29A is the points “A” and “B” in each figure. ”).

  FIG. 30 illustrates how, in consideration of other parts of this document, the method 810 according to the present invention can be further implemented in an environment where multiple applications share a network, storage, or other resource; Determining the impact of competing application workloads and adjusting the analysis model to take them into account (811), adjusting multiple parameter value sets to help improve resource sharing (812), And optionally by adjusting parameter values to prioritize one application, its I / O requests, or other aspects over another application, its I / O requests, or other aspects.

E. Multi-level mapping of application system storage resources While one or more digital storage environments similar to those discussed in US patent application Ser. No. 11 / 773,825 (AKR-110-US) have been described above, the present invention will now be described. Proceed to a more detailed description of the aspects, embodiments, and examples. This application is a continuation-in-part (CIP) of US patent application Ser. No. 11 / 773,825. The digital processing, computing, or storage environment described in US patent application Ser. No. 11 / 773,825 (AKR-110-US) is only some of the examples of processing environments in which the present invention can be implemented. Those skilled in the art will appreciate that the present invention may be practiced in environments other than those described above and described in US patent application Ser. No. 11 / 773,825 (AKR-110-US). I will.

  In particular, aspects of the present invention provide methods, systems, apparatus, and computer program code (software) products operable to efficiently map system resources to applications, and improved storage utilizing such methods and systems. Provide platform and architecture. The basis for this mapping is the definition of an application resource group (ARG), which is a complete set of applications, servers, bus adapters, volumes, logical unit numbers (LUNs), network switches, disk controllers, and disks. Provide information.

  The presently described aspects of the present invention will be described with respect to a storage area network (SAN) infrastructure architecture. However, it will be appreciated that aspects of the described systems and techniques may be implemented in other computing environments.

  A storage area network (SAN) is an architecture that allows a remote computer storage device, such as a disk drive array, to be attached to a host server so that the operating system appears to be attached locally.

FIG. 31 is a table 1000 illustrating an example mapping of a SAN infrastructure at several different levels. The following definition levels are listed in the first column 1001 of the table.
1001a-server level 1001b-bus adapter level 1001c-network switch level 1001d-disk controller level 1001e-disk level

The second column 1002 of the table lists the following definition groups corresponding to each definition level.
1002a—Application server group (ASerG) corresponding to server level
1002b-Application adapter group (AAG) corresponding to the bus adapter level
1002c—Application switch group (ASwG) corresponding to network switch level
1002d-Application Controller Group (ACG) corresponding to disk controller level
1002e—Application Storage Group (ASG) corresponding to disk level

As shown in table column 1003, each level 1001a-e and group 1002a-e correspond to one or more subsets of each element of the exemplary infrastructure architecture.
1003a-Application (APP)
1003b-Server (SERV)
1003c-Bus adapter (BA)
1003d-Volume (VOL)
1003e-Logical unit number (LUN)
1003f-switch (SW)
1003g-Controller (CTLR)
1003h-Disk array (DISK)

  Generally speaking, each group 1002a-e includes its named element and all “upstream” elements up to the application 1003a. Thus, for example, the application switch group (ASwG) includes a switch (SW) and elements upstream of the switch, that is, a logical unit number (LUN), a volume (VOL), a bus adapter (BA), a server (SERV), And application (APP). The selection of specific infrastructure elements for each group described below is shown in FIGS.

  Furthermore, the presently described aspects of the invention further provide a definition of subgroup 1002f. In table 1000, an exemplary subgroup 1002 is defined as providing more detailed information about individual LUNs in an application storage group (ASG), including LUNs, SAN switches 1003f, controllers 1003g, and disk arrays. And “downstream” elements including 1003h. The selection of specific infrastructure elements for the subgroups described below is shown in FIGS. 38, 39A, and 39B.

  Based on this more complete knowledge of application-storage system mapping, system resources associated with the application can be remapped or reconfigured to less constrained system resources to eliminate performance bottlenecks in the system. . Each of these features and elements is described in further detail below.

  The present invention uses data to identify other resources (ie, servers, network switches, disk controllers, disks) that can affect the performance of an application when accessing data stored in a storage system. Take advantage of the ability to find paths. The present invention allows a user to clearly identify when multiple applications share elements in the storage system.

  The present invention uses a combination of agentless methods to discover the ARG topology. These methods include capturing topology mapping information at server, switch, adapter, and disk interfaces utilizing existing APIs and operating system utilities.

  In contrast, one early technique uses an agent-based approach that relies on connecting to an application so that the topology can be discovered. This technique introduces significant overhead to the system and can potentially affect the behavior of running applications.

  The present invention substantially avoids these problems. The present invention can also be easily extended to improve application reliability or security by taking full knowledge of both storage system mapping and data paths between applications and storage systems.

Conventional methods used to manage storage system performance focus only on either the application or the storage system and do not consider these two relationships. Some issues with using a limited view of the system include:
(1) problems can often be misdiagnosed and can be due to either or both of application bottlenecks, such as server memory usage, or storage system bottlenecks, such as disk controller connections,
(2) Little consideration is given to managing multiple applications or servers using shared application servers, network switches, or storage subsystems simultaneously; and (3) Storage, network, and server It can be mentioned that virtualization techniques can add a further level of abstraction between applications and system resources, making performance attribution more difficult.

  The present invention defines a model that links all system resources and paths to individual applications. The present invention defines a mapping to the original individual application from the perspective of the storage device (ie, individual disk spindle). A key element of the present invention is the ability to easily identify the application set associated with any contention point in the storage system.

  The present invention includes the ability to obtain storage subsystem information by capturing dynamically changing mappings between applications and supporting storage systems. This information can be obtained by periodically probing the storage system and application to track any changes to the mapping.

F. Multi-level Mapping Embodiments The following discussion provides a number of specific details that provide an understanding of the present disclosure and enable the present disclosure. Those skilled in the art will appreciate that the invention may be practiced without these specific details. In some instances, well known methods, procedures, components, protocols, algorithms, and circuits have not been described in detail so as not to obscure the present invention.

  The above discussion described the need to map storage resources to applications that use these resources. The following discussion describes embodiments of the present invention that are operable to efficiently map system resources to applications in conjunction with the accompanying drawings.

Referring now to FIG. 32, FIG. 32 illustrates an example computer system infrastructure 1010 that includes the following elements. That is,
Two application servers 1011 and 1012,
Three applications 1100, 1110, and 1120,
Two bus adapters 1200 and 1210,
Four storage volumes 1300, 1310, 1320 and 1330,
Five server LUNs 1301, 1311, 1321, 1322, and 1331,
One network switch 1400,
Three disk controllers 1500, 1510 and 1520, and three disk groups 1501, 1511 and 1521
It is.

  The hardware elements (eg, underlying server, bus adapter, storage volume, server LUN, network switch, disk controller, and disk group) and applications that form the basis of the illustrated system are generally of a conventional nature. Well, it can be performed by one skilled in the art using commercially available products.

  Note that FIG. 32 is exemplary and is provided for the purposes of this description. For example, as described above, an actual SAN can have hundreds or even thousands of LUNs. A particular network may be configured differently, or a particular network may include different elements. It will be appreciated that aspects of the presently described systems and techniques may be applied within those contexts as well.

  For example, according to the present invention implemented in a digital computing environment or platform as shown in FIG. 32, an application resource group (ARG) is defined. ARG includes a common set of system resources and is defined as a complete or near-complete mapping from application sets to system elements (eg, servers, host adapters, network switches, disk controllers, and disks) used in the system. Is done.

  Furthermore, according to the present invention, the ARG includes definitions of an application server group (ASerG), an application adapter group (AAG), an application switch group (ASwG), an application controller group (ACG), and an application storage group (ASG). . ARG provides a complete mapping at any point in the path between the application and the storage system.

  ARG provides a hierarchical diagram of application sets that are creating a load on any element in the storage system. If multiple applications are competing for a single storage element and a performance bottleneck is occurring, the ARG can identify an application set that may be the cause of the bottleneck.

  FIG. 33 shows an application server group (ASerG) of the server 1011 according to the present invention. The AserG identifies the applications 1100 and 1110 as applications that are loading the server 1011.

  FIG. 34 shows an application adapter group (AAG) of the bus adapter 1210 according to the present invention. The AAG identifies the application 1120 as an application that is loading the bus adapter 1210. The AAG also identifies that the bus adapter 1210 is connected to the server 1012.

  FIG. 35 shows an application switch group (ASwG) of the network switch 400 according to the present invention. ASwG identifies applications 1100, 1110, and 1120 as applications that are loading network switch 400. In the ASwG, the switch 1400 is connected to the LUNs 1301, 1311, 1321, 1322, 1331, and the LUNs 1301, 1311, 1321, 1322, 1331 are used for mapping the volumes 1300, 1310, 1320, and 1330, and the volumes 1300, 1310, 1320 and 1330 are also connected to bus adapters 1200 and 1210, which also identifies that bus adapters 1200 and 1210 are connected to servers 1011 and 1012.

  FIG. 36 shows an application controller group (ACG) of the disk controller 1510 according to the present invention. The ACG identifies the application 1120 as an application that is loading the disk controller 1510. In the ACG, the controller 1510 is connected to the network switch 400, the network switch 400 is connected to the LUNs 1321 and 1322, the LUNs 1321 and 1322 are used for mapping the volume 1320, the volume 1320 is connected to the bus adapter 1210, and the bus adapter 1210 It is also identified that it is connected to the server 1012.

  FIG. 37 shows an application storage group (ASG) of the disk array 1501 according to the present invention. The ASG identifies applications 1100 and 1110 as applications that are loading the disk array 1501. In the ASG, an array 1501 is connected by a disk controller 1500, a disk controller 1500 is connected to a network switch 400, a network switch 400 is connected to LUNs 1301 and 1311, and LUNs 1301 and 1311 are used for mapping volumes 1300 and 1310. 1300 and 1310 are connected to the bus adapter 1200, and the bus adapter 1200 is connected to the server 1300.

  The present invention also defines subgroups that further decompose any ARG abstraction into LUNs associated with a single application. Each ARG abstraction (ASerG, ASwG, AserG, ACG, and ASG) will contain at least one, and possibly multiple subgroups. A single subgroup can only be presented within a single ASG abstraction. Subgroups further improve the granularity of the relationship between a single storage element and an application.

  38, 39A and 39B provide detailed views of subgroups according to the present invention. The subgroup provides a more detailed view of the LUN associated with the application that is causing the load on the storage element.

  FIG. 38 illustrates an alternative infrastructure architecture that includes a host server 1013 running a single application 1130 that uses a single bus adapter 1230. A single application 1130 may be mapped to multiple volumes 1350 and 1360, and each of these volumes may be mapped to multiple LUNs. Volume 1350 is mapped to LUNs 1351 and 1352, and volume 1360 is mapped to LUN. Each LUN can be mapped to a different RAID group. The LUN 1351 is mapped to the disk array 1531, and the LUNs 1352 and 1361 are mapped to the disk array 1541.

  FIG. 39A shows a first subgroup A1600 that includes a LUN 1351, a switch 1410, a controller 1530, and a disk array 1531. FIG. 39B shows a second subgroup B that includes LUNs 1352 and 1361, switch 1410, controller 1540, and disk array 1541.

  Subgroups can help identify LUNs associated with a single application that can cause performance problems within the storage element. For example, as shown in FIG. 39A, subgroup A 1600 can be used to identify which particular process within application 1130 is responsible for the load being experienced by disk array 1531.

  The information needed to fully describe the application's ARG mapping can be obtained through several methods. Discover this information through existing operating system interfaces (eg, WMI for Windows®) or using operating system utilities and volume managers (eg, Solaris Volume Manager for Solaris) Can do. Switch level discovery uses the Simple Network Management Protocol (SNMP) API defined by the switch manufacturer. Disk array level discovery uses the Storage Management Initiative Specification (SMI-S) API as well as the Command Line Interface (CLI) defined by the Storage Network Industry Association. Local-to-physical LUN mapping is defined by the network and can be obtained using an operating system utility on Unix® or a Windows® registry on Windows® (WWN or WWID). Is obtained using

  In one implementation of the invention, the ARG topology can be obscured by the virtualization technology running on either the server or the storage system. The discovery elements of the system can make use of available APIs provided by virtualization technologies (eg, VMWare's ESX collector works with virtualized host tools). The user can then be presented with an ARG topology that shows either the virtualized system elements or the actual physical elements present.

  Examples of operating system interfaces (WMI, Solaris Volume Manager), API examples (SMI-S, CLI, etc.), and VMWare ESX collectors, etc. refer to commercially available products or services. Those skilled in the art will appreciate that the present invention can be implemented to be interoperable.

FIG. 40 provides a flowchart illustrating one implementation 2000 of the method and system of the present invention, including:
Box 2001—Discover topology first by querying server, network and storage services Box 2002—Discover any virtual-physical mappings present if virtualization is used Box 2003-ASerG, AAG, Identify ASwG, ACG, and ASG groups and subgroups Box 2004-Collect execution statistics at all points in topology and store in statistics repository Box 2005-Collected based on specific group view of topology Box 2006-report performance information to system users

G. CONCLUSION While the above description includes details that enable those skilled in the art to practice the invention, the description is of an exemplary nature and many variations and modifications will become apparent to those skilled in the art having the benefit of this teaching. It should be appreciated that such changes and modifications are within the spirit and scope of the present invention. Accordingly, the invention herein is defined only by the appended claims, which are intended to be construed as broadly as permitted by the prior art.

Claims (17)

In a digital storage environment comprising (A) at least one application server, bus adapter, network switch, disk controller, and disk array, and (B) at least two applications, said at least one application server, bus adapter, network switch , Disk controllers, and disk arrays are collectively storage elements within the digital storage environment,
(A) providing an application resource group (ARG) operable to provide a mapping from application sets to storage elements used in the digital storage environment;
(B) defining subgroups operable to improve the granularity of the relationship between a single storage element and an application,
The ARG includes an ARG abstraction, and the ARG abstraction is
An application server group (ASerG) operable to identify applications that are loading the server,
An application adapter group (AAG) operable to identify applications that are loading the bus adapter,
An application switch group (ASwG) operable to identify applications that are loading the network switch;
An application controller group (ACG) operable to identify applications that are loading the disk controller, and an application storage group (ASG) operable to identify applications that are loading the disk array
Including at least one of
Each ARG abstraction contains at least one subgroup,
The ARG and the subgroup collectively provide a mapping from an application set to a storage element used in a digital storage environment, causing the load on any storage element in the digital storage environment An improvement that is operable to provide a hierarchical image.   The improvement of claim 1, further wherein the ARG and the subgroup are collectively operable to provide a substantially complete mapping from an application set to storage elements used in the digital storage environment. .   The ARG and the subgroup collectively allow the ARG to identify a set of applications that can cause the bottleneck when multiple applications compete for a single storage element and create a bottleneck. The improvement of claim 1, wherein the improvement is operable.   The improvement of claim 1, further wherein the ASG abstraction is configured to allow a single subgroup to be presented only within a single ASG abstraction. In a digital storage environment comprising (A) at least one application server, bus adapter, network switch, disk controller, and disk array, and (B) at least two applications, said at least one application server, bus adapter, network switch , Disk controllers, and disk arrays are collectively storage elements within the digital storage environment,
(A) means for providing an application resource group (ARG) operable to provide a mapping from an application set to storage elements used within the digital storage environment;
(B) means for defining subgroups operable to improve the granularity of a single storage element and application relationship, wherein each ARG abstraction includes at least one subgroup;
The ARG includes an ARG abstraction, and the ARG abstraction is
An application server group (ASerG) operable to identify applications that are loading the server,
An application adapter group (AAG) operable to identify applications that are loading the bus adapter,
An application switch group (ASwG) operable to identify applications that are loading the network switch;
An application controller group (ACG) operable to identify applications that are loading the disk controller, and an application storage group (ASG) operable to identify applications that are loading the disk array
Including at least one of
The ARG and the subgroup collectively provide a mapping from an application set to storage elements used in the digital storage environment, causing an application to load any storage element in the digital storage environment An improvement that is operable to provide a hierarchical image of a set.   6. The improvement of claim 5, wherein the ARG and the subgroup are collectively operable to provide a substantially complete mapping from application sets to storage elements used within the digital storage environment.   The ARG and the subgroup collectively allow the ARG to identify a set of applications that can cause the bottleneck when multiple applications compete for a single storage element and create a bottleneck. 6. The improvement of claim 5, wherein the improvement is operable.   6. The improvement of claim 5, wherein the ASG abstraction is configured such that a single subgroup can be presented only within a single ASG abstraction. A computer program product stored in a computer readable medium and operable in a digital storage environment comprising (A) at least one application server, bus adapter, network switch, disk controller, and disk array; and (B) at least two applications. The at least one application server, bus adapter, network switch, disk controller, and disk array are collectively storage elements in the digital storage environment, the computer program product comprising:
(A) Computer program code executable in the digital storage environment that provides an application resource group (ARG) operable to provide a mapping from application sets to storage elements used in the digital storage environment. Means,
(B) computer program code means defining subgroups operable to improve the granularity of the relationship between a single storage element and an application;
The ARG includes an ARG abstraction, and the ARG abstraction is
An application server group (ASerG) operable to identify applications that are loading the server,
An application adapter group (AAG) operable to identify applications that are loading the bus adapter,
An application switch group (ASwG) operable to identify applications that are loading the network switch;
An application controller group (ACG) operable to identify applications that are loading the disk controller, and an application storage group (ASG) operable to identify applications that are loading the disk array
Including at least one of
Each ARG abstraction contains at least one subgroup,
The ARG and the subgroup collectively provide a mapping from an application set to storage elements used in the digital storage environment, causing an application to load any storage element in the digital storage environment A computer program product that is operable to provide a hierarchical image of a set.   The computer program product of claim 9, wherein the ARG and the subgroup are collectively operable to provide a substantially complete mapping from an application set to storage elements used in a digital storage environment.   The ARG and the subgroup collectively allow the ARG to identify a set of applications that can cause the bottleneck when multiple applications compete for a single storage element and create a bottleneck. The computer program product of claim 9, wherein the computer program product is operable.   The computer program product of claim 9, wherein the ASG abstraction is configured to allow a single subgroup to be presented only within a single ASG abstraction. A method that enables mapping from application sets to storage elements used in a digital storage environment, comprising: (A) at least one application server, bus adapter, network switch, disk controller, and disk array; ) Executable in the digital storage environment comprising at least two applications, wherein the at least one application server, bus adapter, network switch, disk controller, and disk array are collectively storage in the digital storage environment Element, the method comprising:
(A) providing an application resource group (ARG) operable to provide a mapping from application sets to storage elements used in the digital storage environment;
(B) defining subgroups operable to improve the granularity of the relationship between a single storage element and an application,
The ARG includes an ARG abstraction, and the ARG abstraction is
An application server group (ASerG) operable to identify applications that are loading the server,
An application adapter group (AAG) operable to identify applications that are loading the bus adapter,
An application switch group (ASwG) operable to identify applications that are loading the network switch;
An application controller group (ACG) operable to identify applications that are loading the disk controller, and an application storage group (ASG) operable to identify applications that are loading the disk array
Including at least one of
Each ARG abstraction contains at least one subgroup,
The ARG and the subgroup collectively provide a mapping from an application set to a storage element used in a digital storage environment, causing the load on any storage element in the digital storage environment A method operable to provide a hierarchical image.   The method of claim 1, further wherein the ARG and the subgroup are collectively operable to provide a substantially complete mapping from application sets to storage elements used in the digital storage environment. .   The ARG and the subgroup collectively allow the ARG to identify a set of applications that can cause the bottleneck when multiple applications compete for a single storage element and create a bottleneck. The method of claim 1, wherein the method is operable.   The method of claim 1, further wherein the ASG abstraction is configured such that a single subgroup can only be presented within a single ASG abstraction. A system that enables mapping from an application set to storage elements used in a digital storage environment, comprising: (A) at least one application server, bus adapter, network switch, disk controller, and disk array; A storage element within the digital storage environment, wherein the at least one application server, bus adapter, network switch, disk controller, and disk array are collectively And the system is
(A) means for providing an application resource group (ARG) operable to provide a mapping from an application set to storage elements used within the digital storage environment;
(B) means for defining subgroups operable to improve the granularity of a single storage element and application relationship;
The ARG includes an ARG abstraction, and the ARG abstraction is
An application server group (ASerG) operable to identify applications that are loading the server,
An application adapter group (AAG) operable to identify applications that are loading the bus adapter,
An application switch group (ASwG) operable to identify applications that are loading the network switch;
An application controller group (ACG) operable to identify applications that are loading the disk controller, and an application storage group (ASG) operable to identify applications that are loading the disk array
Including at least one of
Each ARG abstraction contains at least one subgroup,
The ARG and the subgroup collectively provide a mapping from an application set to storage elements used in the digital storage environment, causing an application to load any storage element in the digital storage environment A system that is operable to provide a hierarchical image of a set.

Images