JP2007506157A - Hierarchical management of dynamic resource allocation in multi-node systems - Google Patents

Abstract

  A technique for efficiently and effectively managing the dynamic allocation of resources of the multi-node database system among services provided by the multi-node database server is used. A service is a category of work hosted on a database server. These approaches manage resource allocation at different levels. For services that use a particular database, the performance achieved by this service is monitored. Resources allocated to the database are allocated among these services to ensure that performance goals for each of these services are achieved. Resources allocated to a cluster of nodes are allocated between databases to ensure that performance goals for all services that use the database are achieved. Resources allocated to clusters in one farm are allocated between clusters based on service level agreements and back-end policies. This approach uses a director hierarchy to manage resources at different levels.

Description

RELATED APPLICATIONS This application claims priority to US Provisional Application No. 60 / 495,368, filed Aug. 14, 2003, “Computer Resource Provisioning”, incorporated herein by reference. To do. This application is hereby incorporated by reference, US Provisional Application No. 60 / 500,096, filed Sep. 3, 2003, “Service Based Workload Management and Measurement in Distributed Systems. Claims the priority of “Workload Management and Measurement in a Distributed System”. This application is hereby incorporated by reference, US Provisional Application No. 60 / 500,050, filed September 3, 2003, “Automatic And Dynamic Provisioning Of Databases”. ”Claim priority.

This application is based on the following US applications:
US application XX / XXX, XXX filed by Benny Souder et al. On Aug. 12, 2004, incorporated herein by reference, “Dynamic Resource Allocation Hierarchy in Multi-Node Systems (Hierarchical Management of the Dynamic Allocation of Resources in a Multi-Node System) (Attorney Docket No. 50277-2382) "
US application Ser. No. 10 / 718,747, filed Nov. 21, 2003, “Automatic and Dynamic Supply of Database (Attorney Docket No. 50277-2343),” filed Nov. 21, 2003, incorporated herein by reference. When,
US application XX / XXX, XXX filed by Sanjay Kaluskar et al. On August 12, 2004, incorporated herein by reference, “Transparent Session Migration across Servers. Across Servers) (Attorney Docket No. 50277-2383) "
U.S. Application No. XX / XXX, XXX, filed August 12, 2004 by Lakshminarayanan Chidambaran et al., “In a multi-node environment hosting services, Calculation of Service Performance Grades in a Multi-Node Environment That
Hosts the Services) (Attorney Docket No. 50277-2410) "
U.S. Application No. XX / XXX, XXX, filed Aug. 12, 2004, filed by Lacsimina Rayanan Chidambalan et al., “Incremental Runtime Session Averaging in Multi-Node Systems ( Incremental Run-Time Session Balancing in a Multi-Node System (Attorney Docket No. 50277-2411) "
U.S. Application No. XX / XXX, XXX, filed August 12, 2004 by Lacsimina Rayanan Chidambalan et al., "To implement performance and availability levels in multi-node systems. Service Placement for Enforcing Performance and Availability Levels in a Multi-Node System (Representative reference number 50277-2412) "
U.S. Application No. XX / XXX, XXX, filed August 12, 2004 by Lacsimina Rayanan Chidambalan et al., “On-demand allocation and deallocation of nodes and server instances ( On Demand Node and Server Instance Allocation and De-Allocation) (Attorney Docket Number 50277-2413) "
U.S. Application No. XX / XXX, XXX, filed August 12, 2004 by Lacsimina Rayanan Chidambalan et al., “Recoverable Asynchronous Message-Driven in Multi-Node Systems. Processing (Recoverable Asynchronous Message
Driven Processing in a Multi-Node System) (Attorney Docket No. 50277-2414) "
US Application XX / XXX, XXX, filed August 12, 2004, by Carol Colrain et al., “Managing Workload by Service,” incorporated herein by reference. (Attorney Docket No. 50277-2337) ”.

This application consists of the following international applications:
Incorporated herein by reference, filed on August 9, 2004 by Oracle International Corporation at the United States Receiving Office, and “Automatic and Dynamic Supply of Databases” International application No. PCT / XXXX / XXXX, entitled “
International Application No. PCT / XXXX / XXXX, filed August 13, 2004 by Oracle International Corporation in the United States Receiving Office, "Transparent Session Movement Through Servers (Representative Organisation) No. 50277-2593),
International Application No. PCT / XXXX / XXXX, filed August 13, 2004 by Oracle International Corporation in the United States Receiving Office, "Transparent movement of stateless sessions across servers ( Transparent Migration of Stateless Sessions Across Servers) (Attorney Docket No. 50277-2594)
International Application No. PCT / XXXX / XXXX, filed Aug. 13, 2004, by Oracle International Corporation in the US Receiving Office, “On-Demand Allocation and Unallocation of Nodes and Server Instances” (Attorney Docket No. 50277-2595) ".

The present invention relates to workload management, and more particularly to workload management within a multi-node computer system.

BACKGROUND OF THE INVENTION Companies are looking for ways to reduce the cost and increase efficiency of data processing systems. A typical enterprise data processing system allocates a separate resource for each enterprise application. Each application is pre-assigned sufficient load to handle the estimated peak load of the application. Each application has different load characteristics. That is, some applications are busy during the day and some are busy at night, and some reports are run once a week or once a month. As a result, a lot of resource capacity in an unused state is generated. Grid calculations allow this unused capacity to be used or eliminated. In fact, grid calculations are poised to radically change the economic aspects of calculations.

A grid is a collection of computing elements that provide processing and some degree of shared storage. That is, the resources of the grid are dynamically allocated to meet the client's computational needs and priorities. Grid computation can dramatically reduce the cost of computation, increase the availability of computing resources, and result in higher productivity and higher quality. The basic idea of grid calculation is the concept of calculation as a utility, similar to a power grid or telephone network. Grid clients are not interested in where the data exists or where calculations are performed. The client simply wants the computation to be performed and that information be delivered to the client when the client needs it.

  This is similar to the manner in which the electrical utility operates. That is, the customer does not know where the generator is located or how the electrical grid is wired. The customer simply wants electricity and gets it. The goal is to make the calculation a utility, i.e., a household item that exists everywhere. So it has the name Grid.

  This viewpoint of grid calculation as a utility is, of course, a client side viewpoint. From the server side, that is, from the back side, the grid relates to resource allocation, information sharing, and high availability. Allocating resources ensures that everything that needs or requests resources gets what it needs. While resources are not placed in an idle state, requests are placed in an unacknowledged state. Information sharing ensures that the information needed by clients and applications is available where and when this information is needed. High availability ensures that all data and calculations are always present there, just as utility companies always provide power.

Grid computing for databases One area of computer technology that can benefit from grid computing is database technology. The grid can support multiple databases and dynamically allocate and reallocate resources as needed to support the current demand for each database. As demand for a database increases, more resources are allocated to that database, and other resources are deallocated from another database. For example, in an enterprise grid, the database is provided by one database server running on one server blade on the grid. The number of users requesting data from the database increases. In response to this increase, a database server for another database is removed from a server blade and the server blade is provided with a database server for a database that has received increased user requests.

  Grid calculations for databases require the allocation and management of resources at different levels. At the level corresponding to one database, the performance provided to the users of that database must be monitored, and the database resources allocated among the users ensure that the performance goals for each user are met. Must be monitored. Between databases, the allocation of grid resources between databases must be managed to ensure that performance goals for all database users are met. The task of managing the allocation of resources at these different levels and managing the information required to perform such management is extremely complex. Therefore, grid computing systems not only for database systems, but also for other types of systems that allocate resources at different levels within the grid, need a mechanism that simplifies resource management and efficiently addresses resource management. It is said.

  The approaches described in this section are approaches that can be pursued, but not necessarily approaches that have been previously devised or pursued. Accordingly, unless otherwise indicated, any approach described in this section should not be considered as being limited solely to the prior art because it is included in this section.

  The present invention is illustrated by way of example and not limitation in the accompanying drawings, in which like reference numerals refer to like elements, and in which:

DETAILED DESCRIPTION OF THE INVENTION A method and apparatus for managing resource allocation in a multi-node environment is described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent that the invention may be practiced without these specific details. In some cases, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

  Here, a technique used for efficiently and effectively managing the dynamic allocation of resources of the multi-node database system between services provided by the multi-node database system will be described. A service is a specific type or category of work performed for the convenience of one or more clients. Services include, for example, CPU processing time, storing and accessing data in volatile memory, reading from and writing to persistent storage (i.e. disk storage), and Includes any use or consumption of computer resources, including use of network bandwidth or bus bandwidth. A service can be, for example, work performed on a specific application on a database server client.

  These approaches manage resource allocation at different levels. For services that use specific databases, the performance achieved by these services is monitored. Resources allocated to the database are allocated between services to ensure that performance goals for each are achieved. Resources allocated to the nodes of a cluster are allocated between databases to ensure that performance goals for all services that use those databases are achieved.

  This approach uses a director hierarchy to manage resources at different levels. A database director, which is a kind of director, manages resources allocated to a database between the database and the service that uses the database instance. The database director manages the allocation of database instances between services. The cluster director manages the resources of the nodes of one cluster among the databases whose database servers are hosted on the cluster. Still another director, a farm director, manages resources allocated between clusters.

  FIG. 1 illustrates a multi-node computer system that can be used to implement one embodiment of the present invention. Referring to FIG. 1, FIG. 1 shows a cluster farm 101. A cluster farm is a set of nodes organized into a group of nodes called a cluster. A cluster provides some degree of shared storage (such as shared access to a set of disk drives) between nodes in the cluster.

  Nodes in a cluster farm can take the form of computers (workstations, personal computers, etc.) interconnected via a network. Alternatively, the node may be a grid node. The grid is composed of nodes in the form of server blades interconnected with other server blades on the rack. Each server blade is a comprehensive computer system with a processor, memory, network connection and associated electronics on a single motherboard. In general, server blades do not include on-board storage devices (other than volatile memory) and share storage devices (such as shared disks) in addition to the power supply, cooling system, and wiring in the rack.

A critical feature of clusters in a cluster farm is that the nodes of the cluster automatically go through software control between the clusters in the farm without having to physically reconnect the nodes from one cluster to another. It can be transferred. The cluster is controlled and managed by a software utility called here clusterware. Clusterware can be executed to remove nodes from the cluster and to provide nodes to the cluster. The clusterware provides a command line interface that receives requests from a human administrator so that the administrator can provide nodes to the cluster and enter commands to remove nodes from the cluster. These interfaces can also take the form of application program interfaces (“APIs”), which can be invoked by other software running in the cluster farm. Clusterware uses and stores metadata that defines the configuration of the clusters in the farm. This metadata includes cluster configuration metadata that defines the topology of the clusters in the farm, including which specific nodes are present in the cluster. The metadata is changed to reflect changes made by the clusterware to the clusters in the cluster farm. An example of clusterware is software developed by Oracle (registered trademark), for example, Oracle 9i Real Application Cluster (Oracle9i Real Application Cluster) or Oracle Real Application Cluster 10g (Oracle Real Application Cluster 10g). Oracle 9i Real Application Clusters are Mike Ault and Madhu Touma
Tumma), described in Oracle 9iRAC: Configuration and Essence of Oracle Real Application Cluster, Second Edition (August 2, 2003).

  The cluster farm 101 includes clusters 110, 120, and 130. Each cluster hosts one or more multi-node database servers that provide and manage access to the database.

Cluster and Multi-Node Database Server FIG. 2 shows a cluster 110 according to one embodiment of the present invention. A critical feature of a cluster is that the cluster is treated as a single unit or entity by clients of the cluster. This is because, as will be described in more detail, the client issues a request for a service hosted by the cluster without specifying which particular node or nodes will execute the request.

  Cluster 110 includes multi-node database servers 222, 232, and 242. Multi-node database servers 222, 232, and 242 reside on one or more nodes of cluster 110. A server, such as a multi-node server, is a combination of integrated software components and allocation of computing resources such as memory, nodes, and processes on the nodes to execute the integrated software components on the processor The combination of software and computing resources performs a specific function exclusively for one or more clients. The multi-node server regulates and facilitates access to a particular database, among other functions of database management, and processes requests by clients to access the database. Multi-node servers 222, 232, and 242 govern and provide access to databases 220, 230, and 240, respectively. Another example of a server is a web server.

Resources from multiple nodes in a multi-node computing system can be allocated to run server software. Each combination of software and resource allocation from a node is a server referred to herein as a “server instance” or “instance”. Thus, a multi-node database server includes multiple server instances that can run on multiple nodes. Several instances of a multi-node database server can actually run on the same node. A multi-node database server includes a plurality of “database instances”, each database instance running on a node to regulate and facilitate access to a particular database. Thus, each instance can be referred to herein as a database instance for a particular database. Clusters are often used to host multi-node database servers.

  In addition to cluster 110, clients of multi-node database servers 222, 232, and 242 include clients 203 and 205. Clients 203 and 205 execute applications on computers interconnected to cluster 110 via, for example, a network. An application, as the term is used herein, is a unit of software that is configured to interact with a server and to use server functionality. In general, an application consists of integrated functions and software modules (programs composed of machine-executable code or interpretable code, dynamically linked libraries, etc.) that perform a set of related functions. Composed.

  The client 203 includes, for example, a computer process that executes a FIN application and a PAY application. FIN applications include software that generates and analyzes corporate accounting and financial information. The PAY application generates and tracks information about the salaries of company employees.

  Clients of database servers 222, 232, and 242 are not limited to computers interconnected to cluster 110 via a network. For example, the database server 222 can be a client of the database server 232.

  Databases, such as databases 220, 230, and 240, are collections of database objects. Database objects include any form of structured data. Structured data is data structured according to a metadata description that defines the structure. Structured data includes a relational table, an object table, an object-relational table, a body of data structured according to Extensible Markup Language (XML), such as an XML document.

Session In order for a client to interact with a database server on cluster 110, a session is established for that client. A session, for example a database session, is a specific connection established for a client to a server, such as a database instance, through which the client issues a series of requests (requests to execute database statements) To do. For each database session established on the database instance, session state data reflecting the current state of the database session is stored. Such information includes, for example, the identity of the client with which the session was established, and temporary numeric variables generated by the process executing the software within the database session.

  The client establishes a database session by sending a database connection request to the cluster 110.

Clients of cluster 110, such as clients 203 and 205, can interact with cluster 110 through client-side interface components that reside on the same computer as the client. The client-side interface components include API functions that are called by applications executed by the clients 203 and 205. When a connection to the database server is allocated, connection information identifying the node is received and used by the client-side interface component to send subsequent requests by the client to the node.

  Database sessions allocated to clients can be moved to another database instance. Moving a database session entails creating a new database session on another node. While information about movement and connection is being sent to the client-side interface component, the application cannot access this information and the application is “not aware” of this movement. In this way, the movement is performed transparently for the application. Requests associated with the previous database session are executed within the new database session. Techniques for moving database sessions in this way are described in “Transparent Session Movement Across Servers (50277-2383)”.

Service As previously mentioned, a service is a specific type or category of work performed for the convenience of one or more clients. The cluster 110 provides the clients 203 and 205 with a database service for accessing the database 220, a database service for accessing the database 230, and a database service for accessing the database 240. In general, a database service is the work performed by a database server on behalf of a client, and this work typically includes the work of processing and / or computing queries that require access to the database. As used herein, the term query refers to a database statement that conforms to a database language, eg, SQL, and specifies operations to add, delete, or modify data, or tables, object views, and executions. Contains database statements that create and modify database objects such as possible routines.

  Database services, like any service, can be further divided or categorized into subcategories. The database service for the database 220 is further divided into a FIN service and a PAY service. The FIN service is a database service executed by the database server 222 for the FIN application. In general, this service involves accessing a database object on database 220 that stores database data for the FIN application. The PAY service is a database service executed by the database server 222 for the PAY application. In general, this service involves accessing a database object on database 220 that stores database data for the PAY application.

  There are various ways in which work by clusters can be divided or categorized into service categories and subcategories, and the invention is not limited to any particular aspect. For example, work may be divided into services based on the user or group of users (company, department within the company) on which the work is performed.

Participants Offering Services FIG. 3 shows the components of cluster 110 and multi-node database server 222 that are involved in providing various services for database 220. Referring to FIG. 3, multi-node database server 222 includes database instances 322, 332, 342, 352, and 362, which reside on nodes 320, 330, 340, 350, and 360, respectively. Thus, access to the database 220 is managed. A database instance can be provisioned to or removed from a particular node using an instance management application. The instance management application can be used as a part of the Oracle 9i real application cluster or the Oracle real application cluster 10g, for example. The instance management application provides a command line interface or API that can be invoked by an administrator or client to supply a database instance to a node or remove a data instance from a node.

  A database instance of the multi-node database server 222 is assigned to a specific service. Database instances 322 and 332 are assigned to service FIN. Database instances 342 and 352 are assigned to service PAY. Instance 362 is not assigned to any service. A service is running, residing on an instance, node, or cluster when an instance, node, or cluster is assigned to perform this service, or an instance, It is said to be hosted by a node or cluster. Thus, the FIN service is said to run or reside on database instances 322, 332 and nodes 320, 330.

  The listener 390 is a process that runs on the cluster 110 and receives client database connection requests and directs those requests to database instances in the cluster 110. The received client connection request relates to a service (service FIN, PAY, etc.). Client requests are directed to the database instance that hosts the service, where a database session is established to the client. As previously mentioned, the session can be moved to another database instance. The listener 390 directs requests to specific database instances and / or nodes in a manner that is transparent to the application. The listener 390 can run on any node on the cluster 110. Once a database session has been established for the client, the client can issue another request, which can be in the form of a function or a remote procedure call to initiate the execution of a transaction, query Includes requests to execute, update and perform other types of transaction operations, commit or end transactions, and end database sessions.

Workload monitoring Resources are allocated and reallocated to meet performance levels and cardinality constraints on resources. The level of performance and resource availability established for a particular service is referred to herein as a service level agreement. The cardinality constraints on performance levels and resources that are generally applicable to multi-node systems and not necessarily specific services are referred to herein as policies. For example, service level agreements for service FIN require that the average transaction time for service FIN not exceed a predetermined threshold as a level of performance, and that at least two instances be serviced as availability requirements. It may be required to host the FIN. The policy may require that the CPU utilization of any node does not exceed 80%.

The policy may also be referred to herein as a backend policy. Because these policies are used by back-end administrators to manage overall system performance and resources are considered insufficient to meet service level agreements for all sets of services. This is because resources are allocated between the set of services. For example, a policy assigns one database a higher priority than another database. When there are not enough resources to meet service level agreements for both database services, databases with higher priorities and services that use those databases are favored when allocating resources. The

  In order to meet service level agreements, a mechanism is needed to monitor and measure the workload placed on various resources. These measurements of workload are used to determine whether a service level agreement is met and, if necessary, adjust the resource allocation to meet this service level agreement.

  A workload monitor, such as workload monitor 388, is a distributed set of processes that run on the nodes of the cluster to monitor and measure the workload of the cluster to generate “performance metrics”. The workload monitor 388 operates on the cluster 110. Performance metrics are data indicating the level of performance for one or more resources or services based on performance measurements. Techniques for performing these functions are described in “Work Load Measurement by Services (50277-2337)”. As described in more detail below, various components within the multi-node database server 222 that are responsible for managing the allocation of resources to meet service level agreements may access this generated information. it can.

  A particular type of performance metric that can be used to measure a characteristic or condition indicative of a level of performance or workload is referred to herein as a performance measurement. The performance measurement value includes, for example, a transaction execution time or a CPU usage rate. In general, service level agreements that require a level of performance may be defined by thresholds and criteria based on performance measurements.

  For example, transaction execution time is a performance measurement. A service level agreement based on this measurement is that a transaction for service FIN should be executed within 300 milliseconds. Yet another performance measurement is the CPU utilization of the node. A back-end policy based on this measurement is one that prevents the node from generating utilization above 80%.

  Performance metrics may indicate the performance of the cluster and the performance of a service running on the cluster, a node in the cluster, or a particular database instance. Service specific performance metrics or measurements are herein referred to as service performance metrics or measurements. For example, the service performance measurement for service FIN is the transaction time for a transaction executed for service FIN.

Hierarchical Resource Allocation Grid calculations require the dynamic allocation of computer resources to meet service level agreements. In one embodiment, computer resources are averaged or adjusted in a hierarchy of one or more levels of resource allocation. Each level of the hierarchy has a set of different resource pools that are allocated between uses (services, etc.). A resource pool is a group of a particular type of resource, for example, a node and database instance available to a service, a node available to a database, or a node available to a cluster. The three levels of resource allocation are the database level, the cluster level, and the farm level.

Database level At the database level, the allocated resource pool is the one currently used for a particular database and includes the database instances of the database and the nodes that host these database instances. Database level resource pools (ie, resources that can be allocated at that database level) are allocated among the services of the database to satisfy service level agreements. In general, this requires placing a service on the instance and placing a session on the instance.

  Sessions can be arranged in several ways. The first aspect is herein referred to as connection time averaging. The listener 390 averages the workload between service instances by directing database connection requests that request a particular service to instances of the database 220 during connection time averaging. For example, assume that a service FIN on database instance 322 provides better service performance than other instances. In response, the listener 390 directs a larger portion of the database connection request for the FIN service to the database instance 322.

  The second aspect of placing sessions is called runtime session averaging. Database sessions are moved from one database instance to another during the runtime session averaging. Database sessions are moved using transparent session movement. As mentioned earlier, techniques for doing this are described in “Transparent Session Movement Throughout the Server”.

  Service deployment entails service expansion and contraction. Database instances are either assigned to hosted services or unassigned from hosted services upon service expansion and contraction. When a database instance is assigned to host a service, more database sessions can be created for that service on that instance, so it is associated with and utilized for that service The number of database sessions that can be increased. For example, to satisfy the service level agreement for service FIN, instances 322 and 332 are assigned to run service FIN. As demand for services increases, service level agreements will not be met. A service level agreement is said to have been violated when the service level agreement is not met. In response to this service level violation, the FIN service is assigned another instance, instance 342. An instance can run more than one service. For illustration purposes, one instance is running only one service. Thus, when FIN is added to instance 342, service PAY is “hibernated” from instance 342, ie, instance 342 is deallocated as a resource used for PAY service and service on the instance Is canceled.

Cluster level At the cluster level, the resources currently allocated to the cluster are averaged between databases (ie, database services) to satisfy service level agreements. Resource pools averaged at this level are database instances and the nodes that host these database instances. In general, averaging resources at this level requires provisioning and dormancy between existing nodes in the cluster. For example, to satisfy service level agreements in response to service level violations, instances 362 are provided to nodes 360, ie, nodes that already exist in the cluster for multi-node database server 222.

Farm level At this level, resources that can be allocated between services are nodes in the cluster. The pool of nodes for the cluster is dynamic. For example, in response to a service level violation, node 370 is added to the cluster of multi-node database server 222.

Hierarchy of Actions for Adjusting Resource Allocation In general, resource adjustments at lower levels of the resource allocation hierarchy are less disruptive than resource adjustments at higher levels. Moving database sessions and services between running instances at the database level is less confusing and less expensive than providing a new database instance or putting it dormant at the cluster level. Replacing allocated resources between entities that have already been allocated resources is less expensive than a request to allocate more resources from a higher level. Service placement and session movement at the database level is less expensive than changing the number of database instances for the database at the cluster level. Within the database level, moving sessions and swapping them between instances that are already hosting services is less expensive than expanding and contracting services. This is because the latter affects the service topology and can have a greater overall impact on load distribution.

  To correct service level violations, resource allocation is adjusted from the lowest level of the resource allocation hierarchy. In this way, service level violations are generally rectified in a less disruptive and less expensive manner. If service level violations can be resolved by adjusting resource allocation at the database level, do not rely on higher level resource allocation. Some service level violations require adjustment at all levels or at several levels.

  In response to a service level violation, FIN is provided to instance 352 and PAY is hibernated from the same instance only if the dormant service PAY does not violate the service level agreement for PAY. The Otherwise, the service FIN is extended to another database instance. However, if no instance is available to supply the service FIN, a new instance is supplied. This is done by making an assignment at the cluster level, i.e. supplying a new instance 362 to node 360, i.e. to a node that already exists in the cluster. The assignment can then be made by extending the service FIN to the instance 362 at the database level. The instance 362 is an instance that has already been assigned to the database 220 when the service is supplied.

Director Hierarchy According to one embodiment, the components of a distributed system, called a distributed director, are responsible for managing the resource workload and resource allocation at each level. A system component, as the term is used herein, is one or more processes that execute software, data, the software, and use and store the data to perform specific functions. In combination. The components of the distributed system are executed on a plurality of nodes. Preferably, but not necessarily, the director is a system component of the database instance and operates under the control of the database instance. The distributed director includes directors that are executed on a plurality of nodes of the cluster farm 101.

According to one embodiment, the director is responsible for managing resource assignments at one or more levels of the resource assignment hierarchy. Specifically, the director functions as a database director that manages resource allocation at the database level for each database. Other database instances of the database may have a director that acts as a standby database director, and the standby database director plays this role, for example, due to a system failure. We are ready to take over this active database director if we are unable to do so.

  The director functions as a cluster director for each cluster. The cluster director is responsible for managing the allocation of resources at the cluster level for the cluster. Other directors in the cluster function as standby cluster directors.

  Finally, the director functions as a farm director. The farm director is responsible for managing resource allocation at the farm level. The other directors in the cluster function as standby farm directors.

  The director receives, stores, and generates the information needed to manage the workload at the corresponding level of the director.

  Referring to FIG. 3, the director 380 runs on the database instance 342. The director 380 functions as a database director for the database 220, a cluster director for the cluster 110, and a farm director for the cluster farm 101. The other directors function as database directors for databases 230 and 240, respectively, and as cluster directors for clusters 120 and 130, respectively.

  In general, to resolve service level violations, directors at all levels of the resource allocation hierarchy may be involved in correcting this violation. The database director attempts to correct service level violations by adjusting the allocation of resources at the database level. If a service level violation requires adjustment at the next higher level of the resource allocation hierarchy, ie the cluster level, the database director raises the resolution of this service level violation to the cluster director. If a service level violation requires adjustment at the highest level of the resource allocation hierarchy, ie the farm level, the cluster director raises the resolution of this service level violation to the farm director. Correcting service level violations may require adjustment of resource allocation by all directors.

  Directors communicate with each other using message queues. According to one embodiment, the message queue is a table stored in the database of the database instance that hosts the director. A record or row in the table corresponds to a message queue. This record indicates the status of any action taken in response to the message by the director responsible for responding to that type of message. For example, the database director may request a database instance from the cluster director. This request is added to the queue. The cluster director scans this message queue, detects the request, works according to the request, and updates its record to reflect the actions undertaken to respond to the request. The cluster director sends a message to the database director, which is placed in the database director's message queue.

The advantage of using the tables in database 220 is that the message queue can be stored persistently and recoverably using the power and functionality of a transaction-oriented database system, such as multi-node database server 222. is there. If an active database director, cluster director, or farm director fails, the waiting director that intervenes in that position accesses the message queue in a manner consistent with the manner in which the director left a message at the time of the failure. be able to. Such message queues and their use are described in "Recoverable Asynchronous Message Driven Processing in Multi-Node Systems (50277-2414)".

Database Director The Database Director monitors service performance of services to ensure that service level agreements are met, expands or contracts services from the database instances of the database 220, and moves database sessions between database instances of the database 220. Take responsible. The database director also has access to and stores service performance metrics and service level agreements for each service that uses the database. Based on the performance metrics and service level agreements of these services, the database director ensures that the service level agreements are satisfied in the following two ways: That is, (1) by generating and transmitting information that enables the listener to average the workload among service instances by the listener, to maintain that the service performance conforms to the agreement regarding the service level, (2) Ensure that service level agreements are met in a manner that corrects service level violations by detecting service level violations and initiating adjustments to resource allocation to correct service level violations. To do.

  Connection time averaging is used to keep service performance compliant with service level agreements. Specifically, director 380 generates and provides information, referred to herein as performance grade, to listener 390. The performance grade guides the listener 390 when averaging the workload to maintain service performance compliance. A performance grade indicates the relative service performance of a service on an instance relative to other instances. Based on this performance grade, the listener 390 changes the distribution of connected user requests for services to database instances that provide better service performance. Techniques for generating performance grades and techniques for distributing user requests in this manner based on performance grades are described in "Calculating Service Performance Grades in a Multi-Node Environment Hosting Services (50277-2410)". "It is described in.

  Correcting service level violations requires detecting service level violations. Director 380 detects service level violations for a service by comparing service performance metrics and service level agreements. For example, the director 380 receives service performance metrics from the workload monitor 388 indicating that the average transaction time for the service FIN is greater than 30 milliseconds. Service level agreements for service FIN require that the average transaction time not exceed 20 milliseconds. The director 380 detects service level violations by comparing the actual average transaction time with the service level agreement.

When the database director detects a service level violation for a service, the database director follows the resource allocation hierarchy and tries to adjust the allocation of the more confusing and expensive resources, and the least disruptive and least expensive. Try to adjust the allocation of resources that do not cost. For this reason, the database director first averages the workload among the instances already hosting the service by moving the database session assigned to the service to another database instance with better service performance. To determine whether service level violations can be corrected. The number of database sessions moved is selected in a manner that aims to obtain an averaged load between service instances.

  If the database director determines that the service level violation is not resolved by rebalancing the load among the existing service instances, the director 380 extends the service, i.e. referred to herein as the target database instance. Attempt to correct service level violations by assigning another existing database instance to host the service. If the target database instance does not host a service, the service is extended by assigning a target database instance to host in the service. If the target database instance hosts another service, the database director may put that service into a dormant state if it determines that doing so does not cause a service level violation for the other service. it can.

  FIG. 4 shows the database director for database 220 when the service on that target database instance must first be dormant to extend the service to yet another database instance (“target database instance”). A flow diagram of the process followed by the director 380 is shown. For purposes of illustration, service PAY is hosted by database instances 342, 352, and 362, which reside on node 360. Service FIN is extended to database instance 342. The service instance of the service PAY that operates on the instance 342 is in a dormant state.

  Referring to FIG. 4, at step 410, director 380 sends a blocking message to listener 390. This blocking message instructs listener 390 to stop distributing user requests for service PAY to target database instance 342.

  In step 420, the database director 380 moves the database session on the target database instance to another database instance that hosts the service FIN. These database sessions are distributed among the other database instances in a manner that averages the workload among the other database instances.

  In step 430, the director 380 sends a service activation message to the listener 390. The service activation message notifies the listener 390 that the service FIN is operating on the instance 362.

  In step 440, director 380 averages the workload among the instances where service FIN is running (ie, instances 322, 332, and 342) using runtime averaging.

In some cases, director 380 may determine that there is no service that can provide a place to scale and expand another service without violating service level agreements for the target instance. In this case, the director 380 may choose to extend this service to a database instance that has not yet hosted any service. If no database instance is available, the director 380 requests one database instance from the cluster director. In response, the cluster director provides another requested database instance and notifies the director 380. Director 380 extends the service to this new database instance.

  Service level agreements may limit service cardinality. For example, service level agreements for service FIN require that at least one but no more than three database instances host service FIN and that service PAY be hosted by at least three database instances. To do.

  A service may be hibernated for reasons other than making a database instance available to extend another service. For example, the cardinality constraints for service FIN may change based on the time of day. During normal business hours, the cardinality of the service FIN may be a magnitude of 3, but during non-business hours, the cardinality may not be greater than 1. At the start of non-business hours, three database instances host the service FIN. The database director 380 reduces the service FIN by putting services on two of the database instances into a dormant state.

  It is conceivable that the database director must respond to requests made by the cluster director. Such actions include, in response to a request by the cluster director, putting the database instance into a dormant state, i.e. putting a service currently hosted by the database instance into a dormant state. This step is required when the cluster director wants to replace a database instance for one database with a database instance for another database.

Cluster Director The cluster director is responsible for supplying database instances to existing nodes in the cluster and removing database instances from these existing nodes. The cluster director also enforces database level policies. Database level policies, for example, require that the cardinality of the database instance for the database be within the minimum and / or maximum values, or there are not enough resources to satisfy all of the service level agreements Sometimes, the cluster director requests to change the database instance assignment to the database designated as having a higher priority for resource assignment. Changes in this manner between databases also change the resource allocation to services that use databases with higher priorities. The cluster director has access to data that specifies priorities for the allocation of resources between databases and stores that data. Such data can be configured by a cluster administrator.

  The cluster director supplies the database instance in response to the database director request for the database instance ("NEED-INSTANCE" request) and removes the database instance. If a node that does not host a database instance ("free node") exists in the cluster, the cluster director assigns another node to the database by providing the database instance to that free node.

If there are no free nodes in the cluster, the cluster director can request a single node from the farm director by issuing a “NEED-NODE” request to the farm director. If the farm director cannot provide one node, the cluster director arbitrates database instance allocation among the databases hosted by the cluster. This arbitration entails removing the database instance of the database from the nodes in the cluster and providing a database instance for the database from which the NEED-INSTANCE request was generated.

  FIG. 5 is a flow diagram illustrating a process for arbitrating the allocation of database instances between databases. The database director for database 220 determines that another database instance is required for the service, and generates a NEED-INSTANCE request to the cluster director, director 380. Director 380, in its function as a cluster director, uses that node to supply another database instance for database 220 by removing the database instance for the other database from the node in cluster 110. Judge that you can.

  Referring to FIG. 5, in step 510, director 380 as a cluster director sends a “VOLUNTEER-TO-QUIESCE” request to a database director other than the database director making the request (ie, the director issuing the NEED-INSTANCE request). Send. The purpose of the VOLUNTEER-TO-QUIESCE request is to ask the database director if the database director can put the database instance into a dormant state, that is, can reduce the cardinality of the database instance for the director's database. It is. The database director of the database can respond by sending a message indicating that the database instance for the database can be hibernated. The database director may refuse to put the database instance in a dormant state, i.e. reduce the cardinality of the database instance. One reason a database director may send a message that declines that request is because all of the director's database instances are required to meet the availability requirements for the service.

  If the database director 380 receives from the database director at least one message affirming that the database instance can be hibernated, i.e., if more than one database director has offered, in step 520 the director 380 , Select a database from among the databases offered. In order to favor a database with a higher priority of resource allocation, a database with a lower priority of resource allocation may be selected. For illustration, director 380 selects database 240. The cluster director 384 sends a message to the database director of the database 240 and puts this database instance into a dormant state from the node hosting the database instance of the database 240.

  If the database director 380 does not receive a message from the database director affirming that the database instance cannot be hibernated, i.e., no database director offers, then in step 530, the director 380 determines the allocation of resources. Select a database with a lower priority. Director 380 then sends a message to the database director for the selected database to put the database instance in a dormant state. Techniques for selecting a database instance to be dormant are described in more detail in “On-demand node and server allocation and deallocation (50277-2413)”.

In step 540, the database director of database 240 puts the database instance on the node into a dormant state and notifies the cluster director, ie, director 380, that the database instance has been put into a dormant state ("INSTANCE-IDLE" notification). Send. In step 550, director 380 receives a notification.

  In step 560, the cluster director 380 removes the database instance from the node and provides the database instance for the database 230 to the node using, for example, an instance that provides the clusterware API.

  As a result of arbitrating the allocation of database instances between databases, the service provided by the database that abandons the node may suffer a service level violation. As will be described in more detail, free nodes may be available because the cardinality of nodes in the cluster may increase, and these free nodes can be used to correct such service level violations. Director 380 as a cluster director can monitor cluster configuration metadata to detect when more free nodes become available and assign those free nodes to a database that is subject to service level violations. it can. For example, in the current example, the database director for database 220 continues to detect service level violations after abandoning the database instance, and in response, sends a NEED-INSTANCE request to its cluster director, director 380. As a result, director 380 can respond to one of the requests by providing a database instance to the free node after detecting that more free nodes have been added to cluster 110.

Farm Director A farm director is responsible for reorganizing nodes between clusters by assigning nodes between clusters in a cluster farm, that is, removing a node from one cluster and feeding it to another cluster. Bear. The cluster director also enforces cluster-wide policies. A cluster-wide policy may require, for example, that the cardinality of nodes in the cluster be within a minimum and / or maximum value.

  In response to the NEED-NODE request from the cluster director, the farm director supplies the node to the cluster and removes the free node from another cluster that is subject to the agreement on the service level of the cluster. The farm director communicates with the cluster director in the cluster farm to arbitrate node assignment. This process entails sending a “RELINQUISH-NODE” request to the cluster director, which responds to indicate whether the node can be relinquished. The farm director selects a cluster based on these responses, interacts with the cluster director of the selected cluster, and removes the node from the cluster. Removing a node from the cluster may entail bringing the database instance into a dormant state. Once the database instance has been hibernated, the farm director removes the node from the selected cluster and calls this clusterware with the API provided for this purpose into the cluster that requires this node. Supply the node.

  In addition, the farm director monitors the performance of the clusters in the cluster farm using performance metrics received from the workload monitor running on each cluster. A farm director works better if the performance metrics indicate that the cluster is operating in violation of service level agreements for that cluster, or not as well as other clusters. Shift one or more nodes from the cluster to the least active cluster.

Director Selection As previously mentioned, there are multiple directors within a database instance of a database that can act as active or standby directors. Therefore, a mechanism is needed to determine which director is the active director. Furthermore, when an active director fails, it is necessary to select a database director that is waiting to become an active database director. A similar need exists for cluster directors and farm directors. The process of selecting an active director is referred to herein as director selection.

  There are various ways in which a database director can be selected. The first aspect requires the use of a database global lock. Database global locks are used to synchronize processes running under the control of all database instances of a database. The database director requests an exclusive lock at startup. If no database director holds the lock, the database director is given a lock, and this database director takes the position of the database director. Other directors that subsequently request the lock are not granted the lock, and if a lock is granted, they take the position of a director that is waiting until the lock is granted. These requests are placed on hold until given by the requestor or invalidated.

  The multi-node database server detects when the database global lock holder suffers a system failure. In this case, the failed holder's database global lock is either canceled or released and a pending request for the database global lock is given to the waiting database director. The waiting database director granted the lock then acts as the database director.

  Another technique for director selection requires the use of process groups. A process group is a group to which processes running on any node in the cluster can participate. The members of the group are informed when another member stops working (eg due to a system failure) or when to leave the process group. In addition, members are assigned ids when joining a group.

  When the director starts, the director joins the process group for that database. If the director has the highest member id at the time of participation, the director assumes the database director position for the database. When an active director stops working, members of the process group are notified and one member with the highest member id assumes the role of database director.

  A similar technique can be used to select the cluster director. A cluster-wide lock can be used for director selection, or a process group for the cluster can be used.

  With such a technique, a director acting as a cluster director can also be a director for a database different from the database of the previously active cluster director. As a result, message queues may exist on different databases. A table on a database can be accessed by a process that resides on a database instance for that database more efficiently than a process that resides on a database instance of another database.

  A technique that can be used to ensure that a waiting director acting as an active director is hosted by a database instance for the same database is a static data specification technique. With this technique, a database is designated as one database that hosts the cluster director for the cluster (ie, that database instance hosts). Only the director for that database serves as the cluster director for the cluster. Director selection between these directors may be performed by using either a global database lock or a process group for the database.

  The database can be specified by an administrator using an interface provided by the clusterware for this purpose. To increase the availability of waiting cluster directors, a database with high priority and high minimum / maximum cardinality requirements can be specified, ensuring a relatively large number of waiting directors. An active farm director can be selected using a static database specification technique.

  Organizing the management of resources in a farm cluster using a director hierarchy facilitates the generation and exchange of information required for resource management. In general, a process running in a particular database (ie, the process of a database instance for a particular database) communicates with other processes in that database more efficiently than processes that do not exist in this database Can do. Thus, a director that acts as a database director for a database and obtains service performance metrics from one or more workload monitors running in that database is more efficient than a director running in other databases, That data can be acquired. In addition, since there is only one active database director in the database, it acquires and generates information about the services that run the database, such as service performance metrics, service level agreements, message queue data, etc. The work needs to be performed by only one director.

  Similarly for cluster directors, only one director in the cluster has access to the message queue to keep track of which nodes are in the cluster and which database instances of which databases are hosted. The task of obtaining the information needed to do so and the agreement on the service level of the cluster must be performed.

  The manner in which information and the exchange of information are distributed is used to specify what actions the director itself must take to manage service performance, and what actions the director should raise or delegate to another director. The For example, the reassignment of database instances between databases requires knowledge of which nodes are available in the cluster and which nodes have which database instances. Thus, if a database director that is not aware of such information detects a service level violation that requires an action in the form of a reassignment of database instances between databases, the database director recognizes such information. Raise this action to the cluster director.

Alternative Embodiment Example One embodiment of the present invention has been shown by dynamically allocating multi-node system resources between database services and database service subcategories. However, the present invention is not limited to this.

For example, one embodiment of the present invention can be used to allocate computer resources of a multi-node system that hosts an application server between services provided by the application server. The application server is, for example, part of a three-tier architecture where the application server is located between the client and the database server. This application server is mainly used to store application code, provide access to the application code, and execute the application code, the database server stores the database for the application server, and the database for the application server Mainly used to provide access to. The application server sends a request for data to the database server. The request may be generated by the application server in response to executing application code stored on the application server. An example of an application server is an Oracle 9i application server or an Oracle 10g application server. Similar to the multi-node server example described here, an application server can be distributed as multiple server instances running on multiple nodes, and the server instance hosts multiple sessions that can be moved between server instances. To do.

  The present invention is also not limited to the same type of multi-node server consisting of only server instances that execute copies of the same software product or the same version of the software product. For example, a multi-node database server may consist of several groups of server instances, each group running different database server software from different vendors, or running different versions of database server software from the same vendor To do.

Transparent session movement Transparent session movement allows a client to switch from a session on one server to a session on another server in a manner that is transparent to the application in which the initial session was established. The term move refers to the behavior in which a client of an existing session on the server is switched from an existing session to another session, the existing session is terminated, and the client Allows you to use a session. An existing session is referred to herein as moved. The term “transparent” refers to performing an operation within a unit in a manner that does not require execution of instructions adapted to perform the operation within the unit. Thus, the client is switched between sessions under transparent session movement, without executing application instructions adapted to perform the movement. Instead, the client-side interface component through which the application interacts with the server handles the details of the move and changes the internal state of the client-side interface component to perform the move. There is no need to change legacy applications to start the technology described here.

  To move the session, the session state is collected and restored. The collection of session state entails generating a stream of bytes as a true replica of the session state of the session, which can be stored in an object, file, or other type of data structure; It can be accessed later to restore the session. Under transparent session movement, the client session is collected on the source server and generates a stream of bytes that are stored in a data structure and transported to the destination server. The destination server then restores the session by loading a stream of bytes into the session on the destination server established for the client.

Session Movement A database session is considered “stateful” when future application calls depend on the session state generated by the previous application call. Because future application invocations have a potential dependency on the session state of a stateful session, the movement of a stateful database session will cause a portion of the session state stored in the source instance to be transferred to another database instance. It entails determining whether it can be transferred, and if so, it entails transferring a session state replica between the source database instance and the destination instance. In one embodiment, various movement checks are performed to determine whether a portion of the session state stored in the source instance can be transferred to another database instance, so that the session state is transferred to another database instance. Determine if it can be transferred. Confirmation of these moves includes determining whether the database session exists at a transaction boundary, a call boundary, or a component boundary.

  If there is currently no active transaction being executed for the session, the database session is at a transaction boundary. A transaction is a logical unit of work executed as an atomic unit. In the case of a database system, the database must reflect all of the changes made by the transaction, or reflect any of the changes made by the transaction, and must ensure the integrity of the database. As a result, the changes made by the transaction are not permanently applied to the database until the transaction is completely executed. A transaction is said to "commit" when changes made by the transaction become permanent. A transaction is active if the transaction is not committed, aborted, or terminated.

  If the database instance has finished executing the client call, the session is at the call boundary, not in the intermediate stage of the call processing. For example, a database instance passes through stages that each correspond to a particular type of operation in order to process the call and execute the database statement. These stages consist of (1) creating a cursor, (2) parsing database statements and combining variables, (3) executing database statements, (4) fetching rows to return to a query, and (5) cursors. Is closed. These stages are described in “Oracle8 Server Concepts”, Release 8.0, Volume 3 (the contents of which are incorporated herein by reference), Chapter 23. Are described in more detail. The intermediate stage is an operation executed before the calling process is completed. The intermediate stages are stages (1) to (5). After the instance performs step (5) in response to the call, the source session exists at the call boundary.

A session exists at a component boundary if each of the “database components” of the session is present at the boundary of its respective component. A database component is a set of software modules on a database server that provide specialized and related functions. The session state of the component is specifically generated and used by the database component. According to one embodiment, session state can be viewed as a merge or combination of component session states. The following content is an example of a database component. The cursor component manages the cursor in the database instance. A cursor is an area of memory used to store information about the parsed database statement and other information related to the processing of the database statement. A PL / SQL component is a database component that is responsible for executing PL / SQL, code (procedures, etc.) written in a procedural database language published by Oracle Corporation. A session parameter component is a database component that is responsible for managing attributes that comprehensively control how calls and requests associated with a session are processed. These attributes are stored in the session state of the component. For example, session parameters may include attributes that control a particular human language with respect to results returned by executing a query. A Java (registered trademark) component is a database component responsible for executing code (classes, object methods, etc.) written in Java (registered trademark). The Java component uses the session state of the component to store information related to the execution of Java code.

  A database session exists at the component boundary for a particular database component if the session state of the component of the database component can be moved to another session. The database component provides a function that returns a value indicating whether the session state of each component of the database component can be moved. The reason that the component session state of the database session may not be moved is because the component session state includes a file descriptor for an open file. The file descriptor contains information that is valid only for the instance that hosts the database session.

  The function is part of the callback function interface supported by each database component. These functions are called not only to collect and restore the session state of the component, but also to determine whether the session state of the component allows for session movement.

Generation of Performance Metrics Performance metrics are data indicating the quality of service realized by a service with respect to one or more resources. The background process generates performance metrics from performance statistics generated for each session and service hosted on the database instance. Performance statistics may indicate quality of performance, as well as performance metrics. However, performance measurements generally include more detailed information about a particular use of a particular resource. Performance statistics include, for example, how much time, CPU time was used by the session, the speed of the call, the number of calls made by the session, and the response time required to complete the call with respect to the session How much CPU processing time was used to parse the query for the session, how much CPU processing time was used to execute the query, how many logical reads and physical It includes whether a read has been performed, as well as latency for I / O operations to various resources, such as latency for reading or writing a particular set of data blocks. The performance statistics generated for the session are aggregated by the service associated with the session.

  For each session established on the database instance, a session object is created as part of the operation of establishing a session on the database instance. The session object contains items of information used by the database instance to manage the session. Among these items of information is a service identifier defined for the session. In one example, the service id is a hash value generated from the service name of the service.

Performance statistics are generated and aggregated by a process that performs the requested work within the session. For example, a database session is established for a client that sends a request to execute a query. The process for that session executes the database server software, parses the query, and devise an execution plan for computing the query in parallel. Database server software that parses database queries, devise execution plans, and computes queries also generates and aggregates performance statistics. The database server software aggregates performance statistics by session and the services of that session. This performance statistic is stored in a performance statistic repository, which is, for example, an in-memory fixed table associated with a session or associated with a service disconnected from any session. possible. Performance statistics for a session are aggregated and stored in an in-memory table for that session. Performance statistics for a service are aggregated and stored in an in-memory table for that service.

  The session is associated with the service PAY, for example. The database process assigned to the session uses 0.4 seconds of CPU time to calculate the query. This process adds 0.4 to the subtotal in the in-memory table for service PAY.

  The workload monitor periodically (such as every 5 seconds) accesses the performance statistics repository, generates performance metrics, and stores the generated performance metrics in the performance metrics repository. The repository of performance metrics is preferably an in-memory database table. The workload monitor can access the performance statistics repository every 5 seconds and generate performance metrics including performance grades. The performance grade is sent to the listener for connection time averaging. The listener uses this performance grade to perform connection time averaging and establish a session for a connection request for a service on a database instance that provides better performance for the service.

  The workload monitor can also compare the generated performance metrics to detect violations of service level agreements. When a service performance violation is detected, the workload monitor sends a message to alert a director (such as a database director) responsible for responding to the service level violation.

  The service and its various attributes and the quality of service (such as agreement on service level) need to be specified. According to one embodiment, the database server provides a command line interface that receives commands from a human administrator and creates and modifies definitions for the services of the database server. These definitions are stored as database configuration data in a dictionary in the database as a “service profile”.

Hardware Overview FIG. 6 is a block diagram that illustrates a computer system 600 upon which an embodiment of the invention may be implemented. Computer system 600 includes a bus 602 or other communication mechanism for communicating information, and a processor 604 coupled with bus 602 for processing information. Computer system 600 also includes a main memory 606, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 602 for storing instructions and information for execution by processor 604. Main memory 606 may also be used to store temporary numeric variables or other intermediate information during execution of instructions executed by processor 604. Computer system 600 further includes a read only memory (ROM) 608 or other static storage device coupled to bus 602 for storing static information and instructions for processor 604. A storage device 610 such as a magnetic disk or optical disk is provided and coupled to the bus 602 for storing information and instructions.

Computer system 600 may be coupled via bus 602 to a display 612 for displaying information to a computer user, such as a cathode ray tube (CRT). An input device 614 including alphanumeric keys and other keys is coupled to bus 602 to communicate information and command selections to processor 604. Another type of user input device is a cursor controller 616, such as a mouse, trackball, or cursor direction key, for communicating direction information and command selections to the processor 604 to control the movement of the cursor on the display 612. . The input device generally has two degrees of freedom in two axes, a first axis (such as x) and a second axis (such as y), which allows the input device to locate on a plane. it can.

  The invention is related to the use of computer system 600 for implementing the techniques described herein. According to one embodiment of the invention, these techniques are performed by computer system 600 in response to processor 604 executing one or more sequences of one or more instructions contained in main memory 606. . Such instructions can be read into main memory 606 from another computer-readable medium, such as storage device 610. By executing the sequence of instructions contained in main memory 606, processor 604 performs the steps of the processes described herein. In an alternative embodiment, the present invention can be implemented using a connection circuit instead of or in combination with software instructions. Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.

  The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to processor 604 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks such as storage device 610. Volatile media includes dynamic memory, such as main memory 606. Transmission media includes coaxial cables, copper wire, and optical fiber, and includes wires having a bus 602. Transmission media can take the form of acoustic or light waves, such as those generated during radio wave data communication and infrared data communication.

  Common forms of computer readable media include, for example, floppy disk, flexible disk, hard disk, magnetic tape, any other magnetic medium, CD-ROM, any other optical medium, punch Card, paper tape, any other physical medium with a hole pattern, RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or cartridge, carrier wave described below, or computer-readable Any other media that can be included.

  Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 604 for execution. For example, the instructions may be initially carried on a remote computer magnetic disk. The remote computer can load the instructions into its own dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 600 can receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. Data carried by the infrared signal can be received by an infrared detector, and appropriate circuitry can output the data on bus 602. Bus 602 carries the data to main memory 606 from which processor 604 retrieves and executes the instructions. The instructions received by main memory 606 may be stored in storage device 610 depending on the situation, either before or after execution by processor 604.

Computer system 600 also includes a communication interface 618 coupled to bus 602. Communication interface 618 provides a two-way data communication coupling to a network link 620 that is connected to a local network 622. For example, communication interface 618 may be an integrated services digital network (ISDN) card or modem to provide a data communication connection for a corresponding type of telephone line. As another example, communication interface 618 may be a LAN card for providing a data communication connection to a compatible local area network (LAN). A wireless link can also be realized. In any such implementation, communication interface 618 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

  Network link 620 typically provides data communication to other data devices via one or more networks. For example, the network link 620 can provide a connection via a local network 622 to a host computer 624 or a data device operated by an Internet Service Provider (ISP) 626. ISP 626 then provides data communication services through a worldwide packet data communication network now commonly referred to as the “Internet” 628. Local network 622 and Internet 628 both use electrical, electromagnetic or optical signals that carry digital data streams. Signals over various networks and over communication link 618 on network link 620 are exemplary forms of carrier waves that carry digital data to and from computer system 600 and carry information.

  Computer system 600 can send messages over network, network link 620, and communication interface 618 to receive data including program code. In the Internet example, the server 630 can send the requested code to the application program via the Internet 628, ISP 626, local network 622, and communication interface 618.

  The received code may be executed by processor 604 when received and / or stored in storage device 610 or other non-volatile storage for later execution. In this manner, computer system 600 can obtain application code in the form of a carrier wave.

  In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. Therefore, the only thing that shows exclusively what this invention is and what the applicant intends for this invention is a set of claims derived from this application, such as As a result of the claims, it becomes a specific expression format and includes any future corrections. Any definitions expressly set forth herein for terms contained in such claims shall govern the meaning of such terms as used in the claims. Hence, no limitation, element, property, feature, advantage or attribute that is not expressly recited in a claim should limit the scope of such claim in any way. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.

1 is a block diagram illustrating a multi-node computer system in which one embodiment of the present invention may be implemented. It is a block diagram which shows the node of 1 cluster according to one Example of this invention. FIG. 2 is a block diagram illustrating components of a cluster of nodes and a multi-node database server engaged in providing various services to a database according to one embodiment of the present invention. It is a flowchart which shows the procedure for extending a service to a target database instance and putting the service on a target database instance into a dormant state. It is a flowchart which shows the procedure for performing a two-step rest. 1 is a block diagram of a computer system that can be used in one embodiment of the present invention.

Claims (21)

A method for dynamically allocating computer resources of a multi-node computer system comprising:
A computer-implemented step of monitoring performance implemented by a plurality of services running on the multi-node computer system, wherein the plurality of services includes a first service and a second service; Furthermore,
Based on the step of monitoring the performance of a plurality of services, generating a performance metric indicating the performance realized by each service of the plurality of services;
A computer-implemented step in which, based on the performance metrics, the multi-node computer system detects a violation of a service level agreement for the first service;
Responsive to the multi-node computer system detecting the violation of the agreement regarding the service level, the computer resource allocation of the multi-node system is adjusted between the first service and the second service. And a computer-implemented step.   The method of claim 1, wherein the step of adjusting resource allocation comprises allocating another node of the multi-node system to host the first service.   The first server runs on a first node of the multi-node system, and the step of adjusting resource allocation includes extending the first service to the first server. The method according to 1.   Adjusting resource allocation includes providing the first server to the first node to perform the step of extending the first service to the first server. Item 4. The method according to Item 3. The multi-node system includes a first node and a second node;
A first group of sessions is established for the first service on the first node;
A second group of sessions is established for the first service on the second node;
The method of claim 1, wherein allocating resources comprises moving at least one session from the second group to the first node. The computer resource includes a pool of resources;
The step of adjusting the allocation of computer resources includes a lower level in the hierarchy before attempting to adjust the allocation of a second pool of resources higher in the hierarchy for the first service. Attempting to resolve the performance violation by adjusting the allocation of the first pool of resources,
The method of claim 1, wherein the pool of resources includes a first pool of resources and a second pool of resources. The pool of resources includes a first pool of servers as the first pool of resources and a second pool of nodes as the second pool of resources;
The step of attempting to resolve the performance violation hosts the first service before attempting to add another node from the second pool to host the first service. The method of claim 6, comprising attempting to allocate another server from the first pool for the purpose.   8. The method of claim 7, wherein the step further comprises providing another server to the another node in response to adding the other node. The first multi-node server includes a first server, a second server, and a third server;
The first server hosts a plurality of sessions for the first service;
The step of attempting to resolve the performance violation moves at least one of the plurality of sessions to the second server before assigning the third server to host the first service. 7. The method of claim 6, comprising the step of attempting to do so. Each service of the plurality of services is a category of work executed by the multi-node system,
The method of claim 1, wherein the step of adjusting the allocation of computer resources of the multi-node system includes adjusting the allocation of computer resources for each category of the plurality of categories of work. Multiple units of software run on a set of client computers interconnected to the multi-node system;
The method of claim 10, wherein each category of work corresponds to a particular unit of software among the plurality of units.   The method of claim 11, wherein each category of work corresponds to work performed in response to a request generated by a particular unit of software in the plurality of units. A method for dynamically allocating computer resources of a multi-node computer system comprising a first set of nodes and a second set of nodes, comprising:
Monitoring the performance of a plurality of services hosted on the multi-node system to generate performance metrics;
Generating a performance metric indicating the performance realized by each service of the plurality of services based on the step of monitoring the performance of a plurality of services;
The multi-node system includes a first set of nodes and a second set of nodes, the method further comprising:
Running a first multi-node server and a second multi-node server on the first set of nodes;
The plurality of services includes a first service and a second service hosted by the first multi-node server, and the method further includes:
The first multi-node server resources between the first service and the second service based on the performance metrics, wherein the first system component operating on the first set of nodes is Adjusting the allocation of
A second system component operating on the first set of nodes, the first set between the first multi-node server and the second multi-node server based on the performance metrics; Adjusting the resource allocation of the nodes. The step further comprises:
The first system component detecting a service level violation for the first service;
In response to detecting a violation of the service level for the first service,
Said second system for said first system component to coordinate resource allocation of said first set of nodes between said first multi-node server and said second multi-node server; And sending a first request to the component.   Said step of said second system component adjusting resource allocation of said first set of nodes between said first multi-node server and said second multi-node server comprises said second system The method of claim 13, wherein a component includes assigning a node between the first multi-node server and the second multi-node server. The step further comprises:
The first system component detecting a service level violation for the first service;
In response to detecting a violation of the service level for the first service, the first system component is configured to cause the first multiplicity between the first service and the second service. Adjusting the resource allocation of the node server. The first multi-node server includes a first server instance and a second server instance;
The method of claim 16, wherein the step of adjusting resource allocation of the first multi-node server comprises causing the second server to host the first service. The first multi-node server includes a first server instance and a second server instance;
The first server instance hosts at least one session for the first service;
The second server instance hosts at least one session for the first service;
The step of adjusting resource allocation of the first multi-node server includes adjusting a balance of sessions for the first service between the first server instance and the second server instance. The method of claim 16.   The method of claim 14, wherein in response to receiving the first request, the second system component provides another server instance of the first multi-node server to another node. The first set of nodes is a first cluster of nodes sharing access to at least one persistent storage;
The second system component sends a second request to a third system component running on the multi-node system to request another node;
The method of claim 19, wherein the third system component assigns a node between the first cluster and another cluster in the multi-node system based on the performance metrics.   Providing another server instance causes the first system component to send a message to the second system component to indicate that the other server instance is available. 19. The method according to 19.

Images