Patent Application
20080270971
The present invention relates to application-requirement based configuration planning for distributed computing systems and, more particularly, to techniques for automatically generating distributed computing system configurations that comply with the application-level requirements of one or more applications to be run on the distributed computing system.
Planning and building a distributed computing system is a challenging task due to the scale and complexity involved with the problem. For example, planning a company-wide network infrastructure requires the designers to first understand the types of applications that will be connected over the network and the impact of having different types of applications on the same network. In a more specific example, designing an enterprise-scale storage infrastructure requires an understanding of how various applications will access the storage systems (e.g., data rate, security requirement, and desired availability level). Each application may have specific system requirements and those requirements may conflict with other applications running on the same network. In reality, applications are constantly being added and removed from the network. This requires a constant re-planning and re-building of the network infrastructure.
Conventional techniques utilize a hands-on approach to handle this process. Using the networked storage design process as a concrete example, the typical task of a storage system designer is a continuous cycle of the following: (a) planning new infrastructure or extensions to the existing infrastructure in order to satisfy increasing storage demand; and (b) monitoring the data being stored as it goes through a lifecycle of allocation, backups, migration, and disposal. This process has become increasingly tedious and time consuming because network applications have become more complex and resource driven.
Outside of the storage infrastructure context, there has been a general need for an automated network planning method. Unfortunately, existing network tools have provided inflexible and limited solutions. For example, existing tools fail to fully address application requirements in their planning methodology. Therefore, these tools still require first level human analysis. In addition, existing network tools are customized to only handle certain types of limited infrastructures. As a result, it is very difficult to use these network planning tools in conjunction with each other. For example, one cannot easily generate a plan which includes both a communications network infrastructure and a storage network infrastructure. It is also difficult to generate a plan of computer servers which will serve applications, and further plan the storage network infrastructure necessary to connect the servers to enterprise storage systems. The only two solutions are to plan each infrastructure independently or to find planners that plan for specific infrastructure combinations.
Therefore, there is a need for a flexible, automated method of network resource planning capable of addressing various infrastructures and application requirements.
Principles of the present invention provide techniques for automatically designing an application-requirement based configuration for a distributed computing system and, more particularly, techniques for generating one or more system-level configuration plans for a distributed computing system that comply with the application-level requirements of one or more applications to be run on the distributed computing system.
In accordance with one aspect of the invention, a technique for automatically designing an application-requirement based configuration for a distributed computing system is provided. One or more application-level templates are obtained, wherein the one or more templates are representative of one or more requirements associated with one or more applications. Using the one or more application-level templates, one or more logical flows are created. The one or more logical flows are then used to generate one or more system-level configuration plans of the distributed computing system.
The one or more system-level configuration plans may be in accordance with at least one of one or more distributed computing system requirements and one or more distributed computing system policies. Furthermore, the step of generating one or more system-level configuration plans may include the steps of host planning, storage planning, physical flow planning, zone planning, and network planning.
These and other objects, features, and advantages of the present invention will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings.
As will be illustrated in detail below, principles of the present invention provide techniques for automatically designing application-requirement based configurations for distributed computing systems. More specifically, an embodiment of the present invention includes techniques for generating one or more system-level configuration plans for a distributed computing system, wherein the one or more system-level configurations comply with application-level requirements of one or more applications running on the distributed computing system. The principles of the present invention will be illustrated herein in conjunction with an exemplary technique for automatically designing application-requirement based configurations for distributed computing systems.
The term “distributed computing system” as used herein is intended to be construed broadly so as to encompass, by way of example and without limitation, any networked system (e.g., communications networks, storage networks, etc.).
The term “application-requirement” as used herein is intended to be construed broadly so as to encompass, by way of example and without limitation, any hardware, software or other related requirements of an application that are necessary for operation.
The term “application-level” as used herein is intended to be construed broadly so as to encompass, by way of example and without limitation, any specifications of hardware, software or the like that are designed to be recognized by an application.
The term “system-level” as used herein is intended to be construed broadly so as to encompass, by way of example and without limitation, any specifications of hardware, software or the like that are designed to be recognized by a distributed computing system.
A key challenge in creating system-level configurations of distributed computing systems is to coordinate and integrate various application-level and system-level design plans. Since each design plan is created for a unique purpose and specifically designed using a distinct set of requirements, integration is complex and tedious. Conventional methods require a distributed computing systems designer to manually combine the application-level and system-level design plans into one overall architectural plan. This is a key issue because any software, hardware or like changes in the distributed computing system will require constant re-construction of the architectural plans, which is time consuming and costly. Therefore, an automated method of designing architectural plans would make better use of network resources and personnel.
Referring initially to
Referring now to
During the execution of the master planner and sub-planner system, specifications are added to the data structures of the logical flows 204 and system-level configuration plans are written into the architectural model 206. At completion, the architectural model will contain a plan that conforms to the various requirements of the logical flows. Furthermore, the architectural model will document one or more implementations of the configuration plans. The architectural model is the output of the entire master planner and sub-planner system.
Within the master planner and sub-planner system, the sub-planners 210a to 210n, when executed, refer to the logical flows and develop one or more configuration plans. The sub-planners interact with the logical flows via the flow and model interface 212. Typical sub-planners include a host planner, a storage planner, a physical flow planner, a network planner, and a zone planner. Each individual plan is incorporated into the architectural model via the flow and model interface. In whole, the architectural models are configured to satisfy the requirements specified by the logical flows.
Logical flows are well understood to those skilled in the art of distributed system planning. A schematic diagram illustrating an example of a logical flow can be found in
In an embodiment of the present invention, both the logical flows and architectural models are stored within CIM (Common Information Model) data structures, and the flow and model interface is a CIMOM (Common Information Model Object Manager). In addition, the sub-planners perform a SAN (Storage Area Network) planning function and the architectural model describes a SAN architecture using the CIM data structures defined in SNIA standards.
The master planner and sub-planner system can be used in conjunction with software installation planners (e.g., planners that plan operating system and application software installs on computers), server physical configuration planners (e.g., planners that generate hardware and memory plans), application configuration and distribution planners (e.g., planners that generate plans indicating how applications are configured for use in clustered application servers), intranet network planners, and wide-area-network planners.
Referring now to
In block 402, the first step is the selection of logical application-level templates. Typically, storage designers have access to a list of prepackaged logical application level templates 404. Each template characterizes the typical workload for an application and provides information about data containers and their associated storage service classes. A data container is an abstract storage unit that aggregates storage volumes that have been logically carved out of storage pools. A storage service class is an aggregation of performance, availability, backup/restore, future growth, and security attributes. A system designer can associate a storage service class to a data container. The system designer may work with already existing storage service classes or can optionally create new storage service classes. Alternatively, the system designer may profile the behavior of an application or a group of applications with the help of monitoring tools that determine an appropriate template for the applications or assist in the creation of new application templates. The logical templates are then stored in a centralized repository and the number of available templates will grow over time as more solutions are designed.
Typically, application-level templates contain: (1) a text description of the application being characterized; (2) information about host-level requirements (e.g., number and availability of host servers, number of storage network adapters); (3) a list of one or more data containers used by the application, and an association that maps each data container to a service class; and (4) information about possible inter-data container concurrency (e.g., data containers that can be accessed simultaneously).
In block 406, a system designer can choose application-level templates via a logical application-level template selector. In an embodiment of the present invention, the local application-level template selector is a graphical user interface. In alternate embodiments, the user input is passed into an application-level template selector via a text file or programming interface. The output of the local application-level templates selector is one or more application-level templates.
In block 408, the logical flow constructor constructs logical flows 410 for each planned data container. Each logical flow describes the intended use of a data container by a given application. They indicate the service class and host bus adapter (HBA) requirements of each host involved in the interaction between the application and its data container.
In block 400, the master planner and sub-planner system reads the logical flows and generates system-level storage plans (also known as an architectural model) 412 of a SAN which meets the requirements of the logical flows; therefore, the storage plans also meet the application-level requirements specified within the application-level templates. The architectural model is the output of the entire system.
In an embodiment of the present invention, the following sub-planners are employed: a host planner 418a; a storage planner 418b; a physical flow planner 418c; a zone planner 418d, and a network planner 418e. A sub-planner invocation workflow 414 is used to direct the invocations of sub-planners 418a-418e via the master planner 416. The sub-planners utilize the constructed logical flows via the flow and model interface 420. Additional distributed computing system requirements and policies can be introduced into the system by consulting the policy engine 422.
In an additional embodiment of the present invention, a future growth planner (not expressly shown) can be incorporated into the sub-planner system. A future growth planner plans for expected growth in terms of data traffic and capacity. This type of planning is important for networked storage systems. Future growth requirements can be estimated by extrapolating historical growth data, or can be obtained as an input from a human expert or storage designer. The future requirements can be used to modify the bandwidth and capacity parameters of an application template. For example, if the bandwidth is expected to grow by 50% over the next three years, the bandwidth parameter in the template must be modified accordingly. Future growth information can also be incorporated during device planning. In particular, device expansion capability in terms of number of slots, ports, and power.
Note that during the process of planning, the sub-planners may also take online/offline resources into consideration. For instance, an inventory manager and a catalog manager are in the planning loop to feed current inventory data to the sub-planners. A system designer has the ability to select existing resources and/or choose new types of resources from the device catalog, which contains device information necessary for planning.
Referring now to
In block 506, the master planner invokes a sleep instruction until both the host planner and storage planner have completed their planning operations. Once a storage infrastructure has been planned, each logical flow is associated with one or more physical flows. In block 508, physical flow sub-planner 418c is serially invoked. Each physical flow connects the end-points of an actual data path through the storage infrastructure. A host will use this data path to access the storage associated with the data containers of applications. Each physical flow corresponds to a particular host machine, a particular port on the host, a storage controller, and a port on the controller.
In an embodiment of the present invention, physical flow construction can be accomplished in four sub-steps. The first sub-step is the planning of host bus adaptors (HBAs)/ports of the host. Given the number of hosts that will be in the design, the planner will decide how many HBAs/ports are necessary to carry out the requested throughput; the planner maps the logical throughput requirements to multiple host ports. In addition to the throughput requirement, the need to sustain failures without performance degradation will necessitate additional redundancy. Appropriate service class attributes express these redundancy characteristics. The redundancy requirement to hide failure may be categorized as follows: (1) tolerate up to a single failure without performance degradation; (2) tolerate up to a single failure without data unavailability, but with possible performance degradation; and (3) resource failure may lead to data unavailability, i.e., no redundancy.
The second sub-step in the physical flow construction process is the planning of storage controller ports. Based on the results of the first sub-step, the planner will decide which controller ports should be utilized. Similar to the host HBAs/ports planning, this sub-step will select the appropriate number of redundant controller ports based on throughput and redundancy requirements. After this step, physical flows are constructed by matching host ports to storage controller ports.
The third sub-step is used to decide which storage volume can be accessed by which physical flow. Each host planner port instance in a physical flow maps to a volume container, which may potentially break into multiple LUN (logical unit number) on more than one controller; therefore, multiple physical paths.
The forth sub-step is the allocation of storage resources. An embodiment of the present invention uses the physical flow information together with service class specifications found in each logical application-level template, to allocate suitable physical resources (e.g., HBA, switch, storage sub-system, etc.) into the plans.
In block 510, zone planner 418d is invoked. The zone planner constructs the storage mapping, LUN masking, and fabric zoning plans within the architectural model. Storage mapping involves plotting the sections of the storage infrastructure for the purposes of access. Zoning is a network-layer access control mechanism that dictates which storage subsystems are visible to hosts. This access control mechanism is useful in scenarios where the storage area network is shared across multiple administrative or functional domains, and secure access is a concern. Zoning is predominantly a function that is provided by the switch hardware. The concept of LUN masking is an additional fine-grained security layer above zoning that provides servers with the ability to segment the LUNs that are not required by the server, LUN masking is primarily accomplished at the HBA driver level as well as at the storage controller level. As a result, masking can be done once at the storage subsystem level or every time a host accesses a storage subsystem.
System designers can implement a variety of different zoning policies via a policy engine. These policies can be tailored to specific applications so that the storage access boundaries between applications are not crossed. Zoning guidance policies include: (1) granularity of zones: one zone per application; one zone per host; one zone per storage array; one zone per data container; one zone per data path between a server and a storage array; (2) device type: one zone per device type; one zone per specific device; and (3) groups of devices: one zone per group of devices; one zone per cluster of servers associated with an application. In addition to guidance policies, it is also possible to have validation policies such as: (1) size: a minimum of M elements and a maximum of N elements per zone; any element can be a member of at most N zones; a maximum of N zones per fabric; and (2) exceptions: disallow server X and storage array Y from being in the same zone; disallow tape and disk devices from being in the same zone. LUN mapping/masking can also have guidance policies such as, hosts in shared-disk applications have identical mapping/masking views. LUN mapping/masking validation policies include: (1) LUN numbers are contiguous, starting from zero; and (2) a maximum of M LUNs can be assigned to a host.
In block 512, the master planner invokes network planner 418e. The network planner is a sub-planner which inserts network equipment and device interconnection specifications into the architectural model. The network planner generates a plan that meets the specifications of the logical flows and requirements placed in the architectural model by the physical flow planner. In block 514, the master planner waits until the zone planner and network planner complete their respective executions. When the zone planner and network planner processes have been completed, the master planner stops reading the sub-planner invocation workflow and terminates.
Referring now to
In block 616, the master planner determines the execution status of previously invoked sub-planners. In an embodiment of the present invention, sub-planners are invoked serially through a call-return mechanism and both the sleep and determine sub-planner operating status steps are omitted. In block 618, the master planner examines the workflow for additional steps. If there are additional steps, the process repeats. When the workflow steps are exhausted, the master planner ends 620.
Referring now to
As shown, the techniques for automatically designing an application-requirement based configuration for a distributed computing system may be implemented in accordance with a processor 710, a memory 712, I/O devices 714, and a network interface 716, coupled via a computer bus 718 or alternate connection arrangement.
It is to be appreciated that the term “processor” as used herein is intended to include any processing device, such as, for example, one that includes a CPU (central processing unit) and/or other processing circuitry. It is also to be understood that the term “processor” may refer to more than one processing device and that various elements associated with a processing device may be shared by other processing devices.
The term “memory” as used herein is intended to include memory associated with a processor or CPU, such as, for example, RAM, ROM, a fixed memory device (e.g., hard drive), a removable memory device (e.g., diskette), flash memory, etc.
In addition, the phrase “input/output devices” or “I/O devices” as used herein is intended to include, for example, one or more input devices (e.g., keyboard, mouse, scanner, etc.) for entering data to the processing unit, and/or one or more output devices (e.g., speaker, display, printer, etc.) for presenting results associated with the processing unit.
Still further, the phrase “network interface” as used herein is intended to include, for example, one or more transceivers to permit the computer system to communicate with another computer system via an appropriate communications protocol.
Software components including instructions or code for performing the methodologies described herein may be stored in one or more of the associated memory devices (e.g., ROM, fixed or removable memory) and, when ready to be utilized, loaded in part or in whole (e.g., into RAM) and executed by a CPU.
Although illustrative embodiments of the present invention have been described herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various other changes and modifications may be made by one skilled in the art without departing from the scope or spirit of the invention.
