CN101079736A - Modeled network resource positioning method - Google Patents

Abstract

The modeled grid resource location method belongs to the technical field of grid resource location in grid systems, and is characterized in that it is based on a grid resource model composed of logical entities and modeling relationships. In this model, based on logical entities and grid The mapping relationship between resources and between modeling relationships and grid resource attributes transforms a resource traversal thread rooted at the logical entity corresponding to the grid resource required by the user in the resource model into a resource traversal thread that uses the grid resource as a resource The location entry is the resource location clue used to replace the selected logical entity as the root node. The user node only needs to obtain the resource location clue registered by the grid node in advance from the registration node, and then obtain it from the corresponding grid node. For grid resources that have been located, at this time, the grid node should replace the non-root nodes in the traversal thread with the corresponding grid resource attributes. The method has good scalability and flexibility, and also simplifies the problem of maintaining the consistency of the registration information on the registration node.

Description

Model-Based Grid Resource Locating Method

technical field

The model-based grid resource location method belongs to the field of distributed technology and systems, especially in the field of high-performance grid computing technology

Background technique

In modern scientific research, the field for people to solve problems is constantly expanding, and the problems they encounter are becoming more and more complex, and the scale is getting larger and larger. Unable to meet demand. With the rapid development of computer and network technology, many organizations and scientific research units have supercomputers with strong computing power, but these machines often do not fully function because they only serve their own units in isolation, and are idle most of the time . Therefore, it has become a necessary requirement to break the geographical restrictions and use various resources widely distributed on the network in coordination.

The proposal and development of grid technology is to meet the above-mentioned requirements, and its goal is to realize the sharing and collaborative work of heterogeneous resources across regions, and eliminate information islands and resource islands. Its related technologies include network technology, XML technology, Web service technology (web service), high-performance computing, etc. With the gradual maturity of grid technology, the Open Grid Services Architecture (OGSA) combined with the service-oriented concept has become the de facto standard in the grid world, and the Web Service Resource Framework (WS-Resource Framework, WSRF) is the latest implementation specification of OGSA. A grid system (also known as a grid environment) that complies with the OGSA architecture usually includes the following three types of entities:

● Shared resources. Objects that really provide computing power and can run independently, such as computers with operating systems installed, networks, storage systems, etc., are the material basis on which the grid system operates. The shared resources in the grid are contributed by individuals/organizations (referred to as "resource owners" or "administrators"), and appear as autonomous units to the outside world. Resource owners can impose restrictions on the shared resources they contribute, such as "only when the machine load does not exceed 50% can be used by the grid system", which is used to limit the use of the shared resources by the grid system. Shared resources added to the grid system are usually also called grid nodes, and each grid node has a globally unique identifier in the grid environment (for example, an IP address is used to identify the grid node).

● Grid services. Based on the local operating environment of shared resources (such as the operating system), in order to achieve certain functional purposes, the program code is developed in accordance with specific grid standards/standards (such as WSRF). Grid services are deployed on grid nodes and use the computing power of shared resources to process user requests. The process of publishing the functions of software and existing programs on shared resources as grid services is called service packaging. Multiple grid services can be combined according to a certain process and published as a workflow grid service to provide users with more powerful functions. There is no difference between workflow service and general grid service for users, both are grid services conforming to specific grid standards/standards.

● Users. Entities that invoke grid services are also called user nodes.

In the grid environment, users obtain the computing power contributed by shared resources by accessing grid services. Every time a grid service implemented according to the WSRF specification receives an access request, it will generate a service resource in real time or select a service resource that has been instantiated in advance to process the request; the characteristics generated during the processing of the user request are passed through properties of the service resource. For example, a batch processing service is deployed on a certain grid node. After receiving a batch processing task request submitted by a user, it will generate a batch processing service resource to be responsible for the execution of the user task; the batch processing service resource has " The resource attribute of "task status", the value of this attribute (such as "in queue", "executing", "end", etc.) indicates the execution status of the corresponding user task. Therefore, service resources reflect the situation that shared resources provide computing power to users, and such service resources are called grid resources. Specifically, grid resources are a logical concept on top of shared resources, and they provide users with functions corresponding to grid services by virtualizing and aggregating the computing power of shared resources. The access address (that is, location information) of a grid resource is globally unique in the entire grid environment.

Grid services and grid resources correspond to each other. Different grid services have different corresponding grid resources. According to the WSRF specification, this correspondence has two modes: "General" and "Singleton". A grid service in Singleton mode can only correspond to one grid resource during operation, and all requests are completed by this grid resource; a grid service in general mode can correspond to multiple grid resources during operation, and these resources can be It can be dynamically instantiated after receiving user requests, or it can be pre-generated during initialization. Generally speaking, the Singleton mode is used less, and the general mode is more common. In view of the differences in the functions of grid services, their corresponding grid resources also have great differences in structure, content, and implementation. This phenomenon is called the heterogeneity of grid resources.

For grid services implemented in a general mode, how to manage their corresponding grid resources is entirely up to the resource owner. When grid nodes have a certain limit on the number of tasks that can be processed at the same time, the method of "generating a set of grid resources for grid service selection in advance" is generally adopted, and the number of user requests is limited by the number of grid resources. The two methods of "pre-generation" and "dynamic instantiation" can also be mixed: first, a set of grid resources is generated for use; After the processing is completed, the grid resource returns to the idle state; if there is no idle grid resource, a new grid resource will be dynamically instantiated, and the grid resource will be destroyed after the request is processed. Either way, grid resources on grid nodes are dynamically changing: first, the value of resource attributes changes with the execution of user requests, and second, grid resources can be updated in real time with the arrival of user requests Spawns, dies as the user request is processed.

When a user accesses a grid system, he first needs to know the information of grid nodes, grid services and grid resources in the system in order to judge whether the grid system can meet his computing needs. To achieve this purpose, some grid nodes are usually selected as registration nodes, responsible for maintaining all or part of the grid nodes, grid services, and grid resource information in the system. The registration node is a logical concept, and the user can always know the access method of the registration node. By registering a node, users can query any information maintained by the registered node. There can be one or more registration nodes in a grid system. Each entity that needs to be registered can register on any registration node. The registered content is called the metadata of the registration entity, such as CPU type, operating system, current state, Disk capacity, deployed application software, access addresses and protocols, etc. Metadata is the data that describes the data, which is used to give the structure and meaning of the data, and is an abstract concept. The metadata here shows users the status, characteristics and functions of registered entities in the grid system.

To sum up, in a grid environment that complies with the OGSA framework and WSRF specifications, the autonomous grid nodes package the local externally shared resources according to their determined resource models according to certain standards and protocols, and according to the actual situation to dynamically generate or use pre-initialized grid resources. Grid resources on different grid nodes may be different in syntax and semantics (structure and content), showing heterogeneity, and their organization and management methods may also be different. Users must first locate the grid resources before using the computing power presented by the grid resources.

Most of the current grid resource positioning schemes adopt the form of "hierarchical registration-direct indexing", such as the Monitoring and Discovery System (MDS) in Globus Toolkit, which can organize registration nodes into any hierarchy, and multiple registration nodes can register with each other , and even form a ring-shaped index relationship; the information of grid resources can reach other registration nodes layer by layer through its directly registered registration nodes. Although this "hierarchical registration-direct index" method has good organization, its working object is grid resources, and the granularity is too fine, which mainly has the following disadvantages:

●When the scale of the system increases, the number of grid resources also increases accordingly, and the registration information that needs to be maintained by the registration nodes at the upper level in the hierarchical structure increases sharply, which is likely to cause single point failure and poor scalability;

●Because of the dynamic nature of grid resources, it is necessary to ensure the consistency of the grid resources themselves and the information stored on multiple registration nodes. When the information of grid resources changes frequently, consistency maintenance will generate a lot of overhead;

●Because the registered nodes are all isomorphic, this requires that the grid resources on all grid nodes in the system must be implemented according to the same specification/standard (or even the same tool), and the flexibility is poor.

In the context of "hierarchical registration-direct indexing", the modeled grid resource location method is based on the characteristics of grid node autonomy, and the work object of the registered node is changed from the dynamic grid resource on the grid node to the relatively static resource model , relaxes the restrictions on the norms/tools adopted by grid nodes to implement grid resources, which not only increases flexibility, but also simplifies the consistency maintenance and scalability of registration information on registration nodes.

Contents of the invention

The purpose of the present invention is to provide a modeled grid resource positioning method, so as to lay the foundation for realizing resource sharing in the grid environment. This method takes the autonomy of grid nodes as a starting point, associates heterogeneous and dynamic grid resources on it through a relatively static grid node resource model, and registers the grid resource location clues corresponding to the resource model as metadata to the registration node. Due to the static nature of the grid node resource model, this method can effectively solve the problem of maintaining registration information consistency caused by the dynamic nature of grid resources, and at the same time improve scalability; on the other hand, grid nodes can use any The favorite way to package local shared resources as a grid service not only reflects the autonomy of grid nodes, but also enhances the flexibility of the system.

For better illustrating content of the present invention, at first carry out following explanation and term explanation:

1. Resource model. A grid node appears as an autonomous unit to the outside, but it may contain multiple sub-individuals. The resource model is the result of abstracting grid nodes, mainly including two parts: logical entities (LogicEntities) and relations between logical entities (Relations): logical entities represent the internal elements of grid nodes; relations represent the relationship between two internal elements Relationships, also known as modeling relationships, have quantitative description attributes such as one-to-one (1:1), one-to-many (1:N), and many-to-many (N:N). For example, a cluster-type grid node can be abstracted into two elements: "internal node" and "process"; a process runs on an internal node, so there is a relationship of "running in" between these two elements; a Multiple processes can run on an internal node, but a process can only run on one internal node, so there is a one-to-many relationship between "internal node" and "process"; therefore, the resource model modeled in the above way includes The two logical entities of "internal node" and "process", and the modeling relationship of "running in (one-to-many)". For the sake of simplicity, the quantity description attributes of modeling relations are only mentioned where necessary, and others are omitted. For a resource model containing N logical entities, the mathematical definition looks like this:

ResourceModel = {LogicEntities, Relations}

LogicEntites={LogicEntity _i |i=1, 2, ..., N}

Relations={R(i, j)=<log icEntity _i , log icEntity _j >|i≠j, i∈{1,...,N}, j∈{1,...,N}}

R(i,j)(1:N-1)=R(j,i)(N-1:1)

2. Connected resource model. The process of modeling grid nodes is artificial, so the results of abstracting according to different purposes are often different. For example, from the perspective of distributed system composition, the cluster can be modeled as a resource model that includes three logical entities of "internal node", "process", and "inter-cluster network", as well as the relationship of "running on" . In a resource model, two logical entities are said to be connected if there is a direct relationship between them, or they can be indirectly linked through a relationship with one or more other logical entities. If any two logical entities can be connected, the resource model is said to be connected. A set of modeling relationship sequences connecting two logical entities is called a path between these two logical entities, such as <R(i,k ₁ ), R(k ₂ ,k ₃ ),…,R(k _a , j)> is a path between LogicEntity _i and LogicEntity _j , where i∈{1,…,N}, j∈{1,…,N}, k _x ∈{1,…,N}, i≠j , k _x ≠ i, k _x ≠ j, and k _x ≠ k _y , x, y=1, 2, ..., a, a≤N-2. For the above example, because there is only one "running in" relationship, only the two logical entities "internal node" and "process" can be connected, while the "inter-cluster network" has no relationship with other logical entities and is isolated state, so the resource model is disconnected.

3. The traversal clue of the resource model and the resource location clue of the grid node. Resource location cues are defined for grid nodes with connected resource models. In the process of grid node's service packaging, each logical entity in the resource model is realized as a grid service, and the modeling relationship is realized as an attribute of the grid resource. Grid services and grid resources correspond to each other, so there is also a mapping relationship between grid resources and logical entities; each modeling relationship that a logical entity participates in will be the grid resource corresponding to the logical entity an attribute on .

[1] The resource model can be regarded as a graph with logical entities as vertices and modeling relationships as edges, so it can have a spanning tree. In a connected resource model, any other logical entity can be reached from the logical entity LE; according to the idea of spanning tree, the set of paths from LE to any other logical entity is organized into a tree with LE as the root and the modeling relationship as non- The tree of the root node is called a traversal thread of the resource model;

[2] All grid resources on a grid node correspond to a logical entity in the resource model, so starting from any grid resource GR, through the sequence of grid resource attributes corresponding to the modeling relationship, one can reach other arbitrary grid resources;

[3] Assuming that the logical entity corresponding to GR is LE, for a traversal thread with LE as the root, replace the root node LE with the location information of GR, and replace the non-root node (that is, the modeling relationship) with the corresponding grid resource attribute , the tree after the replacement is called a resource location clue of the grid node.

[4] Since there may be more than one path between two logical entities, there may be multiple traversal clues rooted at the same logical entity. Correspondingly, there may be multiple resource location clues that take the same grid resource as the root.

4. The index path of the grid resource. In the resource model, a logical entity can reach another logical entity through a path, and by replacing the modeling relationship in this path with the corresponding grid resource attribute, an index path between grid resources can be obtained. Assume that <R(LE _k1 , LE _k2 ), R(LE _k2 , LE _k3 ), ..., R(LE _k(i-1) , LE _ki )> is the logical resource LE _ki to logical resource LE _i in the resource model A path of , and the grid resource attribute corresponding to R(LE _i , LE _j ) is RP(LE _i , LE _j ), then the index path corresponding to this path is <RP(LE _k1 , LE _k2 ), RP (LE _k2 , LE _k3 ), . . . , RP(LE _k(i-1) , LE _ki )>.

5. Each grid resource can be uniquely identified by its access address (location information) in the grid environment, so the location information of the grid resource can also be directly identified by the grid resource where there is no ambiguity. replace.

The main features of the present invention are: under the support of OGSA architecture and WSRF specification, the grid node adopts the idea of model-oriented, and constructs the metadata registered with the registration node according to its resource model, so that the user node can query the network information from the registration node. The resource location clue of the grid node is used to search and locate the dynamic grid resource on the grid node. First, carry out resource modeling on the grid nodes to ensure that the resource model is a connected logical entity relationship network; determine the mapping relationship between logical entities and grid resources, modeling relationships and grid resource attributes, and implement and initialize accordingly Grid services and grid resources on grid nodes; any grid resource is selected as the resource location entry, and a resource location clue is constructed according to the traversal clues in the resource model, and it is used as the metadata of the grid node to Register node registration. After the user node understands the connection between grid resources on the grid node through the resource model, it can effectively locate the dynamic grid resource on the grid node from the resource location entrance according to the resource location clue.

Based on the above characteristics, the invention content of the modeling grid resource positioning method includes:

1. Resource modeling and service packaging implementation of grid nodes. The resource owner or administrator of the grid node first models the local physical resources to ensure the full connectivity of the resource model, and determines the mapping relationship between the logical entity and the grid resource, the modeling relationship and the grid resource attribute. Grid nodes are implemented as grid resource relational networks corresponding to resource models. Specifically include:

1) According to the actual situation, an initial resource model InitRM (with N logical entities) of the grid node is given, and it is judged whether the model is connected. If not, the following operations are performed:

[1] Treat InitRM as a graph with logical entities as vertices and modeling relationships as edges, and find disjoint connected subgraphs in the resource model, so that InitRM=P1∪P2∪…∪Pm, m≤n

[2] Randomly select a logical entity LE _Pi from each connected subgraph Pi (i=1,...,m)

[3] Add an auxiliary logical entity LE _n+1 and m auxiliary modeling relations <LE _n+1 , LE _pi >, i=1,...,m in InitRM

Note: The purpose of step [3] is to make m disjoint connected subgraphs connected to each other. The easiest way is to add m-1 modeling relationships directly; it can also be to add k auxiliary logical entities LE _n+1 , ..., LE _n+k and m+k-1 auxiliary modeling relations. Which approach to choose is entirely up to the resource owner. InitRM becomes a connected resource model FCRM after adding auxiliary logical entities and modeling relations.

2) The mapping relationship between logical entity and grid resource, modeling relationship and grid resource attribute. The service packaging of grid nodes is based on FCRM, and each logical entity in FCRM is implemented as a grid service, and each modeling relationship is implemented as an attribute of grid resources. Because grid services and grid resources correspond to each other, grid resources and logical entities are also mapped to each other, and the modeling relationship between logical entities is also used to represent the relationship between grid resources; a logical entity participates in Each modeling relationship will be an attribute on all grid resources mapped to that logical entity. Specifically include:

[1] For the auxiliary logical entity, that is, the logical entity in the non-initial resource model InitRM, it is implemented as a grid service in Singleton mode, with only one grid resource; while the logical entity in InitRM can be implemented as a general mode or Singleton schema for grid services.

[2] If there is a modeling relationship R(i, j) between the logical entity LE _i and LE _j , and the resource attribute corresponding to R(i, j) is RP(i, j), then whether it corresponds to LE _i or LE _j The grid resources of all have the resource attribute RP(i, j);

[3] The value of RP(i, j) is a list type, and each item stores the access addresses (that is, location information) of other grid resources that have a modeling relationship R(i, j) with this grid resource;

[4] If the modeling relationship between the logical entity LE _i and LE _j is R(i, j)(1:N), then there is only one value of RP(i, j) on the grid resource corresponding to LE _i , However, there may be multiple values of R(i, j) on the grid resource corresponding to LE _j .

3) The connected resource model of grid nodes, the mapping between logical entities and grid resources, and the mapping between modeling relationships and grid resource attributes are expressed in XML language, and stored locally in grid nodes in the form of files.

2. The objects involved in the grid resource positioning process are logically divided into registration nodes, grid nodes and user nodes. The overall relationship and interaction flow charts among the three are shown in Figure 1 and Figure 2. in,

1) The user node is a grid entity that initiates grid resource location.

2) Grid nodes provide computing power to user nodes through grid resources. As shown in Figure 3, the grid node has a real-time storage space, and its modules for grid resource location include:

■ Initialize the service module InitResources. It is used for the initialization operation of grid nodes. It is mainly responsible for the initialization of the grid node operating environment. The workflow is as follows:

[1] Load the resource model saved in the form of XML file, the mapping between logical entity and grid resource, and the mapping between modeling relationship and grid resource attribute in the real-time storage space. For convenience of description, ModelDescription is used to represent the content of the XML file.

[2] According to the ModelDescription and the resource owner's settings on local computing capacity sharing (such as the number of various grid resources pre-initialized when the grid node starts, the maximum number of various grid resources, etc., usually use the configuration file save these settings), instantiate grid services and grid resources, and save their information in the real-time storage space in the form of XML.

[3] Build resource location clues. There may be multiple connection paths between two logical entities in the resource model, so there may be multiple index paths between two grid resources, and there may be multiple resource location clues on grid nodes. Select one of them as the registration metadata. The operation steps are as follows:

a) Randomly select a grid resource GR from the instantiated grid resources as the resource location entry;

b) According to the mapping between logical entities and grid resources, find out the logical entity LE corresponding to GR in the resource model;

c) Randomly select a traversal thread TGlue with LE as the root in the resource model;

d) Replace the root of TGlue with the location information of GR, and replace the non-root nodes in TGlue with the corresponding grid resource attributes according to the mapping between modeling relationships and grid resource attributes. In this way, a resource location clue using GR as the resource location entry is obtained.

[4] Register the resource location clue as the registration information of the grid node to the registration node.

■ Model metadata service module ModelMetadata. In terms of function, it provides users with resource modeling of grid nodes and readable descriptions of grid resource implementation schemes in the form of XML, that is, grid node resource models, mapping between logical entities and grid resources, and modeling An XML description of the mapping between relationships and grid resource attributes. Methods provided by this module include:

Resource model output interface XMLObject GetResourceModel()

Function: called by the user node to obtain the resource model of the grid node

input: none

Output: Return an XML description of the resource model (including logical entities and modeling relationships) to the user node

Operation: Access the real-time storage space and extract the XML description part of the resource model in ModelDescription

Mapping relationship output interface XMLObject GetModelMapping()

Function: Called by user nodes to obtain the implementation scheme of grid resources on grid nodes, that is, the mapping between logical entities and grid resources, and the mapping between modeling relationships and grid resource attributes

input: none

Output: Return the mapping relationship described in XML to the user, including the mapping between logical entities and grid resources, and the mapping between modeling relationships and grid resource attributes

Operation: Access the real-time storage space, and obtain the part used to describe the above mapping in the ModelDescription

Content description output interface XMLObject GetAll( )

Function: Called by the user node to obtain the ModelDescription of the grid node

input: none

Output: Return the ModelDescription expressed in XML to the user

Operation: Access the real-time storage space and get the ModelDescription

■ Direct query service module RelationService. Through this module, users query the location information of grid resources that have a specific modeling relationship with specific grid resources. The query interface provided is:

XMLObject Query( )

Function: Called by the user node, returns the location information of the grid resource that has the specified modeling relationship with the specified grid resource

Input: specified by the user node, including

●A grid resource (initResource) location information, represented by a character string;

● A grid resource attribute relationship, the grid resource attribute must be able to correspond to a modeling relationship, and it is owned by initResource, expressed as a string.

Output: Return grid resource location information expressed in a list type to the user, each item in the list is an XML description of grid resource location information

Operation: access the real-time storage space, and extract the value of the resource attribute relationship from the current initResource information

■ Location service module LocationService. Provide complex grid resource location services, through which users can obtain the location information of grid resources that have a specified direct or indirect relationship with specified grid resources. The positioning interface provided is:

XMLObject Query( )

Function: Called by the user node, returns the location information of the grid resource that has the specified direct or indirect connection with the specified grid resource

Input: specified by the user node, including

●The location information of a grid resource (GR), represented by a character string;

● An index path LocationChain of a grid resource=<RP(LE _k1 , LE _k2 ), RP(LE _k2 , LE _k3 ),..., RP(LE _ki , LE _kj )>;

● A set of filtering rules filterRule, specifying whether to return the location information of the grid resource that has a certain modeling relationship with GR.

Output: Return grid resource location information represented by a list to the user, and each item in the list is grid resource location information described in XML.

operate:

(a) Set the grid resource location information list that needs to be returned to the user as Results, and another two lists Temp1 and Temp2 are used for temporary storage, set Results to empty, and add GR to Temp1;

(b) If Temp1 is empty, directly return Results; otherwise:

i. Take out the first grid resource attribute RP of LocationChain, and then delete RP from LocationChain;

ii. For each grid resource crg in Temp1, if the crg has the resource attribute of RP, call RelationService to add the location information of each grid resource contained in its RP to Temp2;

iii. If filterRule specifies to return the location information of these grid resources, copy the elements in Temp2 to Results;

(c) If there are grid resource attributes in the LocationChain, first clear Temp1, copy all elements of Temp2 to Temp1, then clear Temp2, and repeat step (b),

(d) If there are no remaining grid resource attributes in the LocationChain, return Results to the user.

3) The registration node provides registration/deregistration service and query service of resource location clues. As shown in Figure 4, it is configured with two storage parts, real-time storage space and backup storage space, and includes the following modules:

■Registration service module RegisterService is used to register resource location clues of grid nodes, and the registration interface provided is:

boolean register( )

Function: Called by the grid node, used to register the resource location clue of the grid node

Input: given by grid nodes, including

● grid node ID gridSiteID;

A resource location clue LG of the grid node gridSiteID;

Output: Return a boolean value to the grid node indicating whether the registration was successful or not

Operation: First check whether the resource location clue of gridSiteID LG has been saved in the real-time storage space, if not, add gridSiteID and LG to the real-time storage space in the form of XML. If the operation is successful, return true, otherwise return false.

■The unregister service module UnregisterService is used to unregister resource location clues of grid nodes, and the accessible unregister interface is:

boolean unregister( )

Function: Called by the grid node to log out the resource location clue of the grid node

Input: given by grid nodes, including

● grid node ID gridSiteID;

A resource location clue LG of the grid node gridSiteID;

Output: Return a Boolean value to the grid node indicating whether the logout was successful or not

Action: Delete the resource location clue LG of gridSiteID from the real-time storage space. Returns true if the deletion was successful, otherwise returns false. If there is no resource location clue LG of the gridSiteID in the real-time storage space, no delete operation is required, and true is returned directly.

■The index service module IndexService provides the index service of grid node resource location clues, and the search interface provided is:

XMLObject find()

Function: Called by user nodes to query resource location clues of grid nodes

Input: given by the user node, the ID of the target grid node gridSite

Output: send all resource location clues registered on the registration node to the user node gridSite in the form of a list, and each resource location clue is expressed in XML

Operation: Retrieve the real-time storage space, if there are one or more gridSite resource location clues, organize them into a list and return them to the user node

3. The grid resources on the grid nodes are dynamic. The premise that they can be located is that the grid nodes are initialized and enter the normal operation state. Before locating grid resources, users first need to obtain grid nodes and their resource location clues, which means that the initialization of registration nodes is completed and the registration/retrieval services work normally.

1) The overall workflow of the grid node is shown in Figure 5, including two parts, the initialization and the operation process of the grid node.

■Initialization of the grid node is completed by the initialization service InitResource, after which the grid node enters the normal working state.

■When the grid node is working normally, it will always monitor whether there is a resource location request from the user node, and if so, perform the following processing operations:

[1] Receive and judge user requests, and extract input parameters;

[2] If the request of ModelMetadata is served for the model metadata, the called interface (GetResourceModel, GetModelMapping, or GetAll) returns the grid node resource model and/or the XML description of the mapping relationship to the user node, then turn to [5];

[3] If it is a direct query service RelationService request, return the location information of all grid resources that have a specified modeling relationship with the specified grid resource according to the input parameters - this process is completed by the query interface of RelationService, go to [5] ];

[4] If it is a LocationService request, extract the query starting grid resources, resource index clues, and result filtering rules from the request input, call the RelationService interface to query in turn, and return to the user according to the filtering rules Result - this process is completed by the location interface of LocationService, go to [5];

[5] After returning the request result to the user, return to the waiting state.

2) The overall workflow of the registration node is shown in Figure 5, including initialization, request listening processing and data backup.

■Main steps of registration node initialization

[1] Reset the operating environment of the registered node;

[2] According to the registration information backup file in the backup storage space, load the previously registered grid nodes and their resource location clues and other information;

[3] Start the request listening process and data backup process.

■ After the start of the request listening process, always listen to whether there is a request from the user node or grid node, and if so, perform the following operations:

[1] Receive and judge user requests, and extract input parameters;

[2] If it is a request for the registration service RegisterService, first judge whether it is a repeated registration, if not, save it to the real-time storage space-this process is completed by its register interface;

[3] If it is a request to unregister the service UnregisterService, delete the registration information specified by the request parameter from the real-time storage space - the process is completed by its unregister interface;

[4] If it is the request of the index service IndexService, then search the real-time storage space according to the index key specified by the input parameter - this process is completed by its find interface;

[5] Return the result of the request to the user and return to the waiting state.

■The data backup process is the maintenance process of the registration information, which runs in parallel with the request listening process, and regularly saves the registration information in the real-time storage space (that is, the resource location clues of the grid nodes) to the backup storage space, which is convenient for the next registration node Load registration information during initialization. Its workflow is:

[1] Start the timer for data backup;

[2] Judging whether it is the backup time, if so, extract all registration information from the real-time storage space, and save it to the backup storage space in the form of an XML file, which will overwrite the last saved backup file;

[3] Wait for the arrival of the next backup time.

4. The positioning operation of the grid resource is initiated by the user node. The user node first queries the registration node to obtain the resource location clue of the selected grid node, and then through one or more interactions with the selected grid node, it obtains the location information of all the grid resources it cares about on the selected grid node. positioning information. The specific process is shown in Figure 7, and the main steps are:

[1] The user node judges whether it has the resource location clue of the target grid node TGS, if not, accesses the index service of the registration node to obtain the resource location clue GRLG of the TGS;

[2] The user node judges whether it understands the resource model of TGS, and if not, obtains one or more of the following content expressed in XML through the model metadata service of TGS: XML description of resource model, grid resource Mapping between logical entities, grid resource attributes and modeling relationships. In this way, user nodes can fully understand the connection between all grid resources on TGS;

[3] Based on the understanding of the relationship between all grid resources on the TGS, for any grid resource GR that the user cares about on the grid node, the index path between the GR and the resource location entry Entry is extracted from the GRLG LPath;

[4] If there is a direct modeling relationship between GR and Entry, that is, LPath contains only one element, then use Entry and LPath as request parameters, send a request to the direct query service of TGS, and turn to [6];

[5] If there is no direct modeling relationship between GR and Entry, set the result filtering rule filterRule, use Entry, LPath and filterRule as request parameters, and send a request to the location service of TGS;

[6] Determine whether there are grid resources that need to be located on the TGS, and if so, repeat steps [3]~[5] until all grid resources that the user cares about on the TGS have been located.

The test environment includes 8 PCs with 256M memory, 2×1300MHz, Linux (Redhat 9.0) operating system, and two servers with 1G memory, Pentium(R) 42.4GHz, and Windows XP SP2 operating system. 100Mbps network for interconnection.

Run a registry node on one Windows server and a grid node on another Windows server. The height of the grid node resource location thread used for the test is 3 (including the resource location entry), and the resource location entry is called the first layer grid resource; the grid resource that has a direct modeling relationship with the resource location entry is the second layer network grid resources; the grid resources that have a direct modeling relationship with the second-level grid resources and indirectly relate to the first-level grid resources are the third-level grid resources.

Run user nodes on 8 Linux machines (multiple user nodes can be simulated on each Linux machine). Considering that user nodes can locate grid resources through location services or direct query services, and location services process requests by invoking direct query services, and do not need to return intermediate results to users, so a network location is located through location services. The time required to locate the grid resource is always less than the time consumed to gradually locate the target grid resource through multiple visits to the direct query service. Therefore, in this test, the user nodes gradually locate the grid resources of each level on the grid nodes through direct query services: firstly, access the registration node to obtain the resource location clues of the grid nodes, and at the same time obtain the location of the resource location entry information (the time consumed in this stage is called the positioning time of the first-level grid resource); then by accessing the grid resource positioning entry, the positioning information of the second-level grid resource on the grid node is obtained; and then by accessing The grid resource of the second layer obtains the location information of the grid resource of the third layer. The time from the moment of accessing the registration node to the location information of the second-level grid resource and the third-level grid resource is respectively called the location time of the second-level grid resource and the location time of the third-level grid resource.

By controlling the number of simulated user nodes on the Linux machine, different access rates on the grid nodes can be realized, that is, the number of grid resource location requests received by the grid nodes per second. Measure the CPU usage consumed by grid nodes to process grid resource location requests, and the average time required for user nodes to locate grid resources at each level. The results are shown in Figures 12 and 13.

It can be seen from the test data that grid nodes can process more than 120 grid resource location requests per second, and the time for user nodes to locate grid resources on grid nodes is at the millisecond level (in this test range within 500 milliseconds), which shows that the system has a certain degree of scalability, and verifies the effectiveness of the modeled grid resource location method.

Description of drawings

Figure 1. Overall relationship diagram of grid resource location.

Figure 2. Overall flowchart of grid resource location.

Figure 3. Schematic diagram of resource model, traversal clues and resource location clues of grid nodes.

Figure 4. Module and data storage distribution diagram of grid nodes regarding resource location.

Figure 5. Module and data storage distribution diagram of the registration node.

Figure 6. Workflow of grid nodes regarding resource location.

Figure 7. Workflow for registering nodes.

Fig. 8. Flowchart of user nodes locating grid resources on a grid node.

Figure 9. Schematic diagram of cluster resource model and its corresponding grid resource implementation.

Figure 10. Schematic diagram of different registration schemes for the cluster:

●EPR(X) is the access address of X, that is, the location information of X.

Figure 11. Schematic diagram of user nodes locating grid resources on the cluster:

●EPR(X) is the access address of X, that is, the location information of X;

●EPRs(X, Y) is a list of positioning information of X and Y;

●{Process} indicates that only the location information of the grid resource corresponding to the process is returned;

●{*} means to return the positioning information of all related grid resources.

Figure 12. The CPU usage consumed by grid nodes processing grid resource location requests.

Fig. 13. The average time required for user nodes to locate grid resources on each level of grid nodes.

Detailed ways

WSRF (WS Resource Framework) is the latest implementation specification of OGSA (Open Grid Services Architecture). Its basic idea is "stateful resources, stateless services", including WS-ResourceProperties, WS-ResourceLifetime, WS-RenewableReferences , WS-ServiceGroup and WS-BaseFaults five technical specifications. For details about WSRF, please refer to http://www.oasis-open.org/committees/wsrf.

Web Services Distributed Management WSDM (Web Services Distributed Management) includes two parts: MUWS (Management Using Web Services) and MOWS (Management Of Web Services). The former defines how to represent and access manageability interfaces as Web service resources, and the latter defines Shows how to manage Web services as resources and how to describe and access manageability using MUWS. For details, please refer to http://www.oasis-open.org/committees/tc home.php?s wg_abbrev=wsdm.

Apache MUSE is an open source project of WSRF and WSDM, which provides a working platform for programmers to further develop Web services and grid applications that follow WSRF and WSDM specifications. The modeled grid resource location method is realized based on ApacheMUSE 1.0 (http://ws.apache.org/muse).

1. The realization of the mapping between the resource model of grid nodes and grid resources/resource attributes

Model grid nodes as a connected resource model. When the grid node is packaged for service, the logical entities in the resource model are respectively implemented as a grid service that complies with the WSRF specification. According to the WSRF specification, a grid service management has multiple dynamically generated grid resources, which also points out the mapping between grid resources and logical entities; at the same time, each modeling relationship that logical entities participate in uses WSDM These relationships will be used as the resource properties (ResourceProperty of WSRF) of the grid resources corresponding to the logical entities.

2. Examples

The following takes the cluster as an example to illustrate the modeling of grid nodes and the realization and positioning of grid resources. A resource model of a cluster and the corresponding grid resource implementation are shown in Fig. 9 . The hosts in the cluster, the processes on the hosts, and the network paths between the clusters correspond to the logical entities LE_host, LE_process, and LE_network respectively, and there is a one-to-many "host" relationship between hosts and processes, so LE_ There is a one-to-many relationship of "R_RunningHas" between the host and the LE_process. To make the resource model connected, attach the logical entity LE_Fleet and two one-to-many relationships "R_for frontend" and "R_connected to". When implemented, the above four logical entities correspond to WSRF services, which are cluster services (Singleton mode), host services, network services, and process services; the three modeling relationships are implemented as WSDM Relationships, which are "for the front end", " connected to" and "running with", they will be added accordingly as resource properties of the above WSRF service.

Grid nodes have many different resource location clues, so there are many schemes when registering with registration nodes. Figure 10 illustrates two cluster resource location clues:

1) Use the Singleton resource of the cluster service as the resource location entry, and start from this resource through the two resource attributes of "for the front end" and "connected to" to locate all the resources of the host service and network service, and through the host service resource, The resources of all process services can be located by the resource attribute of "running with";

2) Use the resource "path 1" of the network service as the resource location entry, start from "path 1" and use the resource attribute "connected to" to locate the Singleton resource of the cluster service, and then use "for the front end" and The two resource attributes "running with" gradually reach all host service resources and process service resources.

After the cluster initialization is completed and enters the normal working state, the grid resource sets of the three services of host, network and process change dynamically with the user's request. Although grid resources are dynamically generated, they can always be retrieved through resource location cues. FIG. 11 is a schematic flow chart of user nodes locating grid resources on a cluster. After the user node obtains the cluster's first resource location clue from the registration node A, it can understand the relationship between all grid resources on the cluster through the results returned by the cluster's model metadata service ModelMetadata.

1) If the user node needs to locate the grid resources of all hosts and processes, first extract the index clues between them and the Singleton resources of the cluster service (indicated as "for the front-end---running" in Figure 11), Set the result filtering rule to return all the location information of all grid resources (represented as {*} in Figure 11), and then send a request to the location service of the cluster. See 4~5 in accompanying drawing 11.

2) If the user node only needs to locate the grid resources of all processes, similarly, first extract the index clues between them and the Singleton resources of the cluster service ("for the front-end---running"), and set the result at this time The filtering rule is to return only the location information of the grid resource of the process (represented as {Process} in Figure 11), and then send a request to the location service of the cluster, as shown in 6-7 in Figure 11.

3) If the user node needs to locate the grid resources of the network service, extract the index thread ("connected to") between them and the Singleton resource of the cluster service, because the index thread only contains one element, so the direct query to the cluster For the service sending request, see 8~9 in Figure 11.

Required hardware environment: CPU1GHz or above, memory 256M or above. Grid nodes, registration nodes and user nodes can operate within a local area network or within a wide area network composed of multiple subnets.

The software environment required for grid nodes and registration nodes: operating system supporting JDK4.2, Java4.2 runtime environment, Apache Tomcat 5.0.28, Apache Muse 1.0

The software environment required by the user node: an operating system that supports JDK4.2, and a Java4.2 runtime environment.

Claims (1)

1. A modeling method for locating grid resources, characterized in that it comprises the following steps in sequence: Step (1). In a grid system that complies with the open grid service architecture OGSA and supports the Web service resource framework WSRF specification, the nodes involved in the grid resource location process are divided into grid nodes and user nodes and register nodes, where: The user node is the grid entity that initiates grid resource location; Grid nodes provide computing power to users through grid resources, which refer to shared resources that resource owners join the grid system; The registration node is one or more grid nodes designated by the administrator, and is responsible for maintaining all or part of the grid nodes, grid services, and grid resource information called logical entities in the grid system. The grid service deployment On the grid node, it is a program code with a setting function developed according to the WSRF specification, so that the grid service can use the computing power of the shared resource to process the user's request; the grid resource is a Service resource, whose attribute is the current execution state of the task submitted by the user request, this attribute is a feature generated by the grid service when processing the user request, thus forming a mapping between the logical entity and the grid resource; Step (2). The following initialization steps are executed in turn by the grid node initialization module: Step (2.1). Load an XML file in the real-time storage space. The content of the file, ModelDescription, contains: a fully connected resource model, a mapping between a logical entity and a grid resource, and a mapping between a modeling relationship and a grid resource attribute, wherein: Resource Model ResourceModel={Logic Entity Group LogicEntities, Modeling Relationships}, LogicEntities={logic entity logicEntity _i , i=1, 2,..., N, N represents the number of logical entities}, Relations=R(i, j)=<logicEntity _i , logicEntity _j >, j∈{1,2 ,...,N}, i≠j, R(i,j)(1:N-1)=R(j,i)(N-1:1), R(i, j)(1:N-1) represents the relationship that one logical entity i can correspond to multiple logical entities j, and R(j, i)(N-1:1) is vice versa; the logical entity represents the Intrinsic elements of a grid node, the modeling relationship represents the relationship between two intrinsic elements, thus forming a mapping between the modeling relationship and grid resource attributes; To establish a fully connected resource model, proceed as follows: First, according to the reality of the grid nodes, an initial resource model consisting of N logical entities and modeling relationships is given, represented by InitRM. If the resource model is not connected, the InitRM is regarded as the logical entity as the vertex , with the modeling relationship as the edge graph, find out the disjoint connected subgraphs on the way, a total of m; Secondly, a logical entity is arbitrarily selected from each connected subgraph, and then an auxiliary logical entity and m one-to-one auxiliary modeling relationships are added to the InitRM, so that m disjoint connected subgraphs communicate with each other through the auxiliary logical entity; Step (2.2). According to the ModelDescription and the number of various grid resources pre-initialized when the grid node starts and the maximum number of various grid resources set by the resource owner in the configuration file, instantiate the grid service and network grid resources, and save the information in the form of XML files in the real-time storage space; Step (2.3). Construct resource location clues according to the following steps: Step (2.3.1). Randomly select a grid resource GR from the instantiated grid resources as the resource location entry; Step (2.3.2). Find out the logical entity LE corresponding to the grid resource GR in the resource model according to the mapping between the logical entity and the grid resource; Step (2.3.3). Randomly select a resource model traversal thread whose root is the logical entity LF described in step (2.3.2) in the resource model, represented by TGlue; Step (2.3.4). Replace the root LE selected in step (2.3.3) with the positioning information of the grid resource, and according to the mapping between the modeling relationship and the attribute of the grid resource, put the traversal clue TGlue The non-root node of is also replaced with the corresponding grid resource attribute, so as to obtain a resource location clue with the grid resource GR as the resource location entry; Step (2.4). Set the following modules in the grid node: Model metadata service module ModelMetadata: grid nodes access real-time storage space to extract content description XML description part in ModelDescription, where: The mapping relationship output interface XMLObject GetModelMapping outputs to the user the mapping relationship between logical entities and grid resources described in XML form, as well as between modeling relationships and grid resource attributes; The content description ModelDescription output interface XMLObject GetAll accesses the real-time storage space and outputs the content description ModelDescription expressed in XML form to the user; Direct query service module RelationService: input a grid resource location information represented by a character string and a grid resource attribute represented by a character string issued by the user node, and output the grid resource location information represented by a list type to the user, the list Each item in is an XML description of grid resource location information; Location service module LocationService: input the location information of the selected grid resource GR sent by the user node and an index path of the grid resource LocationChain=<RP(k ₁ ,k ₂ ), RP(k ₂ ,k ₃ ),… , RP(k _i , k _j )>, where RP(k ₁ , k _j ) is the grid resource attribute corresponding to the modeling relationship R(k _i , k _j ), and the logic entity logicEntity _k1 is the logic corresponding to GR entity; in addition, a set of filtering rules filterRule is used to specify whether to return the location information of those grid resources that have a specific modeling relationship with the grid resource GR; this module returns the network specified by the user and represented by the list type grid resource location information; Step (3). Set up the following modules on the registration node: Registration service module RegisterService: Input the grid node identifier gridSiteID extracted from the real-time storage space by the grid node and sent by the grid node and a resource location clue LG of the identifier; the output is to return the registration represented by a Boolean value to the grid node success or failure information; Unregister service module UnregisterService: input the grid node ID issued by the grid node and then deleted from the real-time storage space and a resource location clue LG corresponding to the ID, and return to the grid node whether the unregister is successful or not represented by a Boolean value information; Index Service Module IndexService: Input the grid node identifier gridSiteID issued by the user node, query the real-time storage space, and output the resource location clue information of the grid node represented by the list type to the user node, each item in the list is a XML description of grid resource location clue; Step (4). Execute the modeled grid resource location method initiated by the user node according to the following steps: Step (4.1). The grid node registers resource behavior clues with the registration node; Step (4.2). The user node asks the registration node for the resource location clue GRLG of many target grid nodes TGS that it cares about; Step (4.3). The registration node sends the resource location clue GRLG of the target grid node described in step (4.2) to the user node; Step (4.4). The user asks the target grid node for one or more of the following content expressed in XML files according to their own needs: the XML description of the resource model, the mapping between the grid resource and the logical entity, and the attribute of the grid resource Mapping with modeling relationships; Step (4.5). The user selects a grid node from many grid nodes, and extracts the difference between the grid resource GR he cares about and the resource location entry Entry from the resource location clue GRLG to which the grid resource GR he cares about belongs. The index path LPath between; Step (4.6). The user judges whether there is a direct modeling relationship between the grid resource GR described in step (4.5) and the resource location entry Entry: If there is: then use the Entry and LPath as request parameters, send a request to the direct query service module of the selected target grid node, and turn to step (4.7); If not: then filter rule filterRule is set, and this Entry, LPath and this filterRule are used as request parameters to send a request to the location service module of the selected target grid node, and turn to step (4.7); Step (4.7). If there are grid resources that need to be located, repeat steps (4.3) to (4.6) until all the grid resources that the user cares about on the selected target grid node TGS have been carried out. position.

Images