Distributed network management using a logical multi-dimensional label-based policy model

Distributed network management using a principle model based on logical multi-dimensional tags

DISTRIBUTED NETWORK MANAGEMENT USING A LOGICAL MULTI-DIMENSIONAL LABEL-BASED POLICY MODEL

<b>Related applications</b>

This application claims the rights and interests of U.S. Provisional Application No. 61/810,480 filed on April 10, 2013, the full text of which is incorporated herein by reference. This application also claims the rights and interests of U.S. Provisional Application No. 61/899,468 filed on November 4, 2013, the full text of which is incorporated herein by reference.

The subject matter described in this article is generally about the domain of servers (physical or virtual) that manages a management domain, and more specifically, is about full management according to a principle model based on logical multi-dimensional tags. Domain policy management server.

Manage a server (physical or virtual) in a management domain according to a principle. For example, a security policy may specify access control and/or secure connectivity, and a resource usage policy may specify the use of computing resources (for example, disks and/or peripheral devices) in the management domain. Conventional principles refer to physical devices and are expressed in low-level structures (such as Internet Protocol (IP) addresses, IP address ranges, subnets, and network interfaces). These low-level constructions make it difficult to write a fine-grained principle in an abstract and natural way.

The above questions and other questions are generated for a specific managed server in a management domain based on a set of one or more rules. One method of management commands, non-transitory computer-readable storage media and systems. The management domain contains a plurality of managed servers. An embodiment of the method includes determining which rules in the rule set are related to the specific managed server. The method further includes generating function-level instructions based on the rules determined to be relevant. The method further includes determining which of the plurality of managed servers are related to the specific managed server. The method further includes sending the function-level commands and information about the managed servers determined to be related to the specific managed server. The specific managed server uses the function-level commands and information about the managed servers to configure a management module, so that the configured management module implements the management principle of the entire management domain.

An embodiment of the medium stores computer program modules that can be executed to implement several steps. These steps include determining which rules in the rule set are related to the particular managed server. These steps further include generating function-level instructions based on the rules determined to be relevant. The steps further include determining which of the plurality of managed servers are related to the specific managed server. These steps further include sending the function-level commands and information about the managed servers determined to be relevant to the specific managed server. The specific managed server uses the function level commands and the information about the managed servers to configure a management module so that the configured management module implements the management principle of the entire management domain.

An embodiment of the system includes a non-transitory computer-readable storage medium storing a computer program module executable to perform several steps. These steps include determining which rules in the rule set are related to the particular managed server. These steps further include generating function-level instructions based on the rules determined to be relevant. The steps further include determining which of the plurality of managed servers are related to the specific managed server. These steps further include sending the function-level commands and information about the managed servers determined to be relevant to the specific managed server. The specific managed server uses the function-level commands and information about the managed servers to A management module is configured so that the configured management module implements the management principle of the entire management domain.

The above problems and other problems are solved by a method, a non-transitory computer-readable storage medium and a system for handling a change of a state of a specific managed server in a management domain. The management domain includes a plurality of managed servers, and the plurality of managed servers use management commands to configure management modules so that the configured management modules implement one of a set including one or more rules The principle of full management domain management. An embodiment of the method includes modifying a first description of the specific managed server to indicate the changed state of the specific managed server, thereby specifying a second description of the specific managed server. The method further includes comparing the unmodified first description with the second description, thereby specifying a description change. The method further includes determining whether to update a management command previously sent to the specific managed server based on the description change. The method further includes, in response to determining the management instruction to update the specific managed server: determining which rules in the rule set are currently related to the specific managed server based on the second description, thereby specifying the current related rules; Determine whether the current related rules are different from the previous related rules, where the previous related rules are determined based on the unmodified first description; and in response to determining that the current related rules are the same as the previous related rules, do not adopt Take further action.

An embodiment of the medium stores computer program modules that can be executed to implement several steps. The steps include modifying a first description of the specific managed server to indicate the changed state of the specific managed server, thereby specifying a second description of the specific managed server. The steps further include comparing the unmodified first description with the second description, thereby specifying a description change. The steps further include determining whether to update the management command previously sent to the specific managed server based on the description change. The steps further include, in response to determining the management command to update the specific managed server: determining which rules in the rule set are currently related to the specific managed server based on the second description, thereby specifying the current relevant rules ; Determine whether the current relevant rules are different from the previous Related rules, where the previous related rules are determined based on the unmodified first description; and in response to determining that the current related rules are the same as the previous related rules, no further action is taken.

An embodiment of the system includes a non-transitory computer-readable storage medium storing a computer program module executable to perform several steps. The steps include modifying a first description of the specific managed server to indicate the changed state of the specific managed server, thereby specifying a second description of the specific managed server. The steps further include comparing the unmodified first description with the second description, thereby specifying a description change. The steps further include determining whether to update the management command previously sent to the specific managed server based on the description change. The steps further include, in response to determining the management instruction to update the specific managed server: determining which rules in the rule set are currently related to the specific managed server based on the second description, thereby specifying the current relevant rules ; Determining whether the current related rules are different from the previous related rules, wherein the previous related rules are determined based on the unmodified first description; and in response to determining that the current related rules are the same as the previous related rules, no Take further action.

<p>100Environment</p><p>110Internet</p><p>120Global Manager</p><p>132Management Module</p><p>134Management module configuration/configuration</p><p>136Principle Implementation Module</p><p>150Management Domain</p><p>200Computer/Computer System</p><p>202Processor</p><p>204chipset</p><p>206Memory</p><p>208Storage Device</p><p>210Keyboard</p><p>212Graphics Adapter</p><p>214Pointing device</p><p>216Network Adapter</p><p>218Display device</p><p>220Memory Controller Hub</p><p>222Input/Output Controller Hub</p><p>300Repository</p><p>310Processing server</p><p>320Management domain computer network infrastructure status/management domain status/status</p><p>330Full management domain management principles/management principles/previous management principles/new management principles</p><p>340Principle Engine Module</p><p>350Related Rules Module</p><p>360Function level command generation module</p><p>370Actor Enumeration Module/Enumeration Module</p><p>380Related Actor Module</p><p>385Management domain status update module</p><p>400Local State Repository</p><p>410Policy Compilation Module</p><p>420Local Status Update Module</p>

FIG. 1 illustrates a high-level block diagram of an environment of a server (physical or virtual) for managing a management domain according to an embodiment.

FIG. 2 is a high-level block diagram illustrating an example of a computer used as one of one or more of the entities illustrated in FIG. 1 according to an embodiment.

Figure 3 illustrates a high-level block diagram of a detailed view of a global manager according to an embodiment.

4 is a high-level block diagram illustrating a detailed view of a principle implementation module of a managed server according to an embodiment.

FIG. 5 is a flowchart illustrating a method of generating management commands for a specific managed server according to an embodiment.

6 is a flowchart illustrating a method of generating a configuration for a management module of a managed server according to an embodiment.

FIG. 7 is a flowchart illustrating a method of monitoring the local status of a managed server and sending local status information to a global manager according to an embodiment.

FIG. 8 is a flowchart illustrating a method of handling a change in the state of a computer network infrastructure of a management domain according to an embodiment.

The figures and the following description describe specific embodiments by way of illustration only. Those skilled in the art will readily recognize from the following description that alternative embodiments of the structure and method illustrated in this article can be used without departing from the principles described in this article. Reference will now be made to several embodiments, examples of which are illustrated in the drawings. It should be noted that wherever feasible, similar or identical element symbols may be used in the figures and they may indicate similar or identical functionality.

FIG. 1 illustrates a high-level block diagram of an environment 100 of a server (physical or virtual) 130 for managing a management domain 150 according to an embodiment. The management domain 150 may correspond to an enterprise (such as, for example, a service provider, a company, a university, or a government agency). The environment 100 may be maintained by the enterprise itself or by a third party (for example, a second enterprise) that helps the enterprise manage its server 130. As shown, the environment 100 includes a network 110, a global manager 120, a plurality of managed servers 130, and a plurality of unmanaged devices 140. A plurality of managed servers 130 and a plurality of unmanaged devices 140 are associated with the management domain 150. For example, it is operated by the enterprise or by a third party on behalf of the enterprise (for example, a public cloud service provider). Although for clarity, one global manager 120, two managed servers 130, and two unmanaged devices 140 are shown in the embodiment shown in FIG. 1, other embodiments may have a different number of global managers 120. The managed server 130 and/or the unmanaged device 140.

Network 110 represents global manager 120, managed server 130, and unmanaged devices 140 communication path between. In one embodiment, the network 110 uses standard communication technologies and/or protocols and may include the Internet. In another embodiment, entities on the network 110 may use customized and/or dedicated data communication technologies.

A managed server 130 is a machine (physical or virtual) that implements a full management domain management principle 330 (shown in FIG. 3). In one embodiment, based on operating system-level virtualization (which is a server virtualization method in which the core of one operating system achieves multiple isolated user space instances instead of just one instance), a server It is a user space instance of a virtual server (sometimes called a container, virtualization engine, virtual private server, or jail). If a managed server 130 is a physical machine, then the managed server 130 is a computer or a group of computers. If a managed server 130 is a virtual machine, the managed server 130 runs on a computer or a group of computers. The full management domain management principle 330 specifies whether and/or how to allow entities associated with the management domain 150 to access other entities (or be accessed by other entities) or consume (or provide) services in other ways. For example, the global management domain management principle 330 specifies security or resource usage. A security policy may specify access control, secure connectivity, disk encryption, and/or control of executable processes, and a resource usage policy may specify computing resources in the management domain (such as disks, peripheral devices, and/or frequency Wide).

A managed server 130 includes a management module 132, a management module configuration 134, and a policy implementation module 136. The management module 132 implements the full management domain management principle 330. For example, in the case of security, the management module 132 may be a low-level network or security engine, such as an operating system-level firewall, an Internet Protocol Security (IPsec) engine, or a network traffic filter Engine (for example, based on Windows Filtering Platform (WFP) development platform). In the case of resource usage, the management module 132 can be a disk usage engine or a peripheral device usage engine.

The management module configuration 134 affects the operation of the management module 132. For example, in the case of security, the management module configuration 134 can be controlled by an access control rule applied by a firewall. Then, a secure connection principle applied by an IPsec engine (e.g., embodied as an iptables entity and an ipset entity in a Linux operating system) or a filtering rule applied by a filtering engine. In the case of resource usage, the management module configuration 134 can be a disk using the engine application's disk usage policy or a peripheral device using the engine application's peripheral device usage policy.

The principle implementation module 136 generates the management module configuration 134 based on the following: a) the management command received from the global manager 120; and b) the status of the managed server 130. The management command is generated based in part on the management domain management principle 330 of the whole management domain. The management module configuration 134 generated by the principle implementation module 136 implements the entire management domain management principle 330 (to the extent that the principle focuses on the managed server 130). This two-step process (generating management commands and generating management module configuration 134) is called "instantiating" a management principle. The policy implementation module 136 also monitors the local status of the managed server 130 and sends the local status information to the global manager 120.

In one embodiment, the principle implementation module 136 is part of a larger dedicated module (not shown). The dedicated module is loaded on a device that already has a management module 132 and a management module configuration 134, thereby transforming the device from an unmanaged device 140 to a managed server 130. Hereinafter, the principle implementation module 136 will be further described with reference to FIGS. 4, 6 and 7.

An unmanaged device 140 is a computer (or a group of computers) that does not include a policy implementation module 136. An unmanaged device 140 does not implement the full management domain management principle 330. However, the interaction between a managed server 130 and an unmanaged device 140 can be subject to the global management domain management principle 330 (as implemented by the managed server 130). An example of an unmanaged device 140 is a network circuit used by a managed domain 150. Another example of an unmanaged device 140 is a device used by a person to authenticate to the management domain 150 (for example, a laptop or desktop computer, a tablet computer, or a mobile phone).

The global manager 120 generates management commands for the managed server 130 and sends the generated management commands to a computer (or a group of computers) of the server. The management command is generated based on the following items: a) the state 320 of the computer network infrastructure of the management domain; and b) a principle 330 of the management of the entire management domain. The status 320 of the computer network infrastructure of the management domain includes managed The description of the server 130 and (as the case may be) the description of the unmanaged device 140. The global manager 120 also processes the local status information received from the managed server 130.

The full management domain management principle 330 is based on a logical management model of the managed server 130 that does not refer to the use of low-level structures (such as IP addresses, IP address ranges, subnets, and network interfaces). Alternatively, the logical management model refers to the managed server 130 based on its high-level characteristics (referred to herein as "tags"). A label includes a pair of a "dimension" (a higher-order characteristic) and a "value" (the value of the higher-order characteristic). Constructing a management principle in this multi-dimensional space is more expressive than constructing a management principle based on a principle model based on a single characteristic network/IP address. In particular, the use of higher-level abstract expressions of "labels" to express management principles enables people to better understand, visualize and modify management principles.

The logical management model (for example, the number and types of available dimensions and the possible values of their dimensions) is configurable. In one embodiment, the logical management model includes the following dimensions and values, as shown in Table 1:<tables><img he="1356" wi="2235" file="tw201445461a_d0001.tif" img-content="drawing" img-format="tif" orientation="portrait" inline="no" /></tables>

The logical management model describes one of all managed servers 130 in the group by specifying Or multiple tags (referred to as a "tag set" in this document) so that multiple managed servers 130 can be grouped together. A label set contains a value of 0 or 1 of a dimension in the logical management model. A label set need not include labels for all dimensions in the logical management model. In this way, the logical management model achieves the segmentation and separation of managed servers 130 of a management domain and the creation of arbitrary groups of managed servers 130. The logical management model also allows a single managed server 130 to exist in multiple overlapping sets (ie, multiple overlapping groups of managed servers). The logical management model does not limit a single managed server 130 to exist in a nested collection hierarchy.

For example, in the context of security, segmentation can be used with access control policies to define groups of managed servers 130 that are subject to specific policies. Similarly, segmentation can be used in conjunction with secure connectivity principles to define groups of managed servers 130 and principles applicable to intra-group communication and inter-group communication. Therefore, communication in a first group (defined by a first tag set) of the managed server 130 can be restricted to a first secure connection setting (for example, no secure connection is required), and the managed servers The communication between the first group and a second group (specified by a second set of tags) of the managed server can be restricted to a second secure connection setting (for example, IPsec Encapsulation Security Payload (ESP)/Authentication). Recognized header (AH) Advanced Encryption Standard (AES)/Security Hash Algorithm 2 (SHA-2)).

Each managed server 130 in the environment 100 implements the full management domain management principle 330 (to the extent that the principle focuses on the managed server 130). Therefore, the entire management domain management principle 330 is applied in a distributed manner throughout the management domain 150 and there is no blocking point. In addition, the physical network topology and network addressing scheme independent of the management domain applies the full management domain management principle 330 at a logical level.

The following further describes the global manager 120, the status 320 of the computer network infrastructure of the management domain, and the management principle 330 of the global management domain with reference to FIG. 3, FIG. 5, and FIG.

FIG. 2 illustrates a high-level block diagram of an example of a computer 200 used as one or more of the entities illustrated in FIG. 1 according to an embodiment. Illustrate coupling At least one processor 202 to a chip set 204. The chip set 204 includes a memory controller hub 220 and an input/output (I/O) controller hub 222. A memory 206 and a graphics adapter 212 are coupled to the memory controller hub 220, and a display device 218 is coupled to the graphics adapter 212. A storage device 208, a keyboard 210, a pointing device 214, and a network adapter 216 are coupled to the I/O controller hub 222. Other embodiments of the computer 200 have different architectures. For example, in some embodiments, the memory 206 is directly coupled to the processor 202.

The storage device 208 includes one or more non-transitory computer-readable storage media, such as a hard disk drive, CD-ROM, DVD, or a solid-state memory device. The memory 206 retains instructions and data used by the processor 202. The pointing device 214 combined with the keyboard 210 is used to input data into the computer system 200. The graphics adapter 212 displays images and other information on the display device 218. In some embodiments, the display device 218 includes a touch screen capability for receiving user input and selecting one of them. The network adapter 216 couples the computer system 200 to the network 110. Certain embodiments of the computer 200 have different components and/or other components from those shown in FIG. 2. For example, the global manager 120 and/or the managed server 130 can be formed by multiple blade servers and lack a display device, keyboard and other components, while the unmanaged device 140 can be a laptop or desktop A computer, a tablet or a mobile phone.

The computer 200 is adapted to execute computer program modules for providing the functionality described herein. As used herein, the term "module" refers to computer program instructions and/or other logic used to provide specified functionality. Therefore, a module can be implemented in hardware, firmware, and/or software. In one embodiment, a program module formed by executable computer program instructions is stored on the storage device 208, loaded into the memory 206, and executed by the processor 202.

Figure 3 illustrates a high-level block diagram of a detailed view of a global manager 120 according to an embodiment. The global manager 120 includes a repository 300 and a processing server 310. The repository 300 is a computer (or a group of computers) that stores the state 320 of the computer network infrastructure of the management domain and the management principle 330 of the entire management domain. In one embodiment, the repository 300 includes a server that provides access to the processing server 310 of the management domain status 320 and the management policy 330 in response to the request.

The status 320 of the computer network infrastructure of the management domain includes the description of the managed server 130 and (as the case may be) the description of the unmanaged device 140. A description of a managed server 130 includes, for example, a unique identifier (UID), an online/offline indicator, one or more configured features (optional), network exposure information, and service information And describe one or more tags (a tag set) of the managed server 130.

The UID uniquely identifies the managed server 130. The online/offline indicator indicates whether the managed server 130 is online or offline. A "configured feature" stores a value associated with the managed server 130 and can be any type of information (for example, an indication of which operating system is running on the managed server). Once the configured feature is used in conjunction with the condition part of the same rule (described below).

Network exposure information focuses on the network interface of the managed server. In one embodiment, for each of the network interfaces of the managed server, the network exposure information includes the identifier of the network interface attached to one of the "bidirectionally reachable networks (BRN)" And zero or more IP addresses (and its subnets) used to operate within the BRN. In another embodiment, the network exposure information includes routing information and/or whether the managed server is behind a network address translator (NAT) (and if it is behind a NAT, what type of NAT-1: 1 or 1:N behind). A BRN is a set of subnets within an organization or across several organizations, wherein any node in the BRN can establish communication with any other node in the BRN. For example, all nodes in a BRN have unique IP addresses. In other words, a BRN does not contain any NAT. Network exposure information (for example, the BRN identifier of a network interface) can be used in conjunction with the condition part of the same rule.

The service information includes, for example, processing procedure information and/or packaging information. Process The sequence information includes, for example, the names of the processes running on the managed server 130, which network ports and network interfaces their processes are listening to, which users have initiated their processes, and their The configuration of the processing programs and the command line transmission parameters of their processing programs. (Their processing procedures correspond to the managed server 130 that provides or uses a service.) Package information includes, for example, which packages (executable files, libraries, or other components) are installed on the managed server 130 , The version of their package, the configuration of their package, and the hash value of their package.

A description of an unmanaged device 140 includes, for example, network exposure information (for example, the IP address of the unmanaged device and an identifier of the BRN to which the unmanaged device is connected). An unmanaged device 140 is part of an "unmanaged device group" (UDG). A UDG includes one or more unmanaged devices 140. For example, "HQ UDG" may include primary circuits and backup circuits used by the headquarters of a management domain, where each circuit is associated with an IP address. A UDG is associated with a unique identifier (UID). The information about a UDG stored in the management domain state 320 includes the UID of the UDG and information about the unmanaged device 140 in the UDG (for example, its network exposure information).

The description of the managed server 130 and the unmanaged device 140 can be loaded into the management domain in various ways (such as by interacting with the global manager 120 via a graphical user interface (GUI) or an application programming interface (API)) State 320. The description of the managed server 130 can also be loaded into the management domain state 320 (described below) based on the local state information received from the managed server.

With regard to the label (and the configured characteristic, if any) of the managed server, the assignment (or reassignment) of a value of one dimension (or the setting of the value of a configured characteristic) can be performed in even more ways. For example, a deployment and configuration tool can be used to perform assignment/configuration as part of deploying a managed server 130. Any of these tools can be used, including off-the-shelf third-party tools (for example, Puppet software from Puppet Labs, Chef software from Opscode, or CFEngine software from CFEngine AS) and custom tools that a management domain 150 may have Tool.

As another example, the assignment/setting can be performed by calculating one of the label and/or configured characteristic ("CC") value "tag/configured characteristic engine" (not shown). In one embodiment, the tag/CC engine calculates the tag/CC value based on the tag/CC assignment rule. A label/CC assignment rule is to access data from the management domain state 320 and assign (or suggest assigning) a function of a label or a CC value. A label/CC assignment rule can be preset or user-configurable. For example, the global manager 120 includes a set of predefined rules, but the end user can modify and/or delete these rules and add new rules based on the user's own customization needs. The tag/CC assignment rules can be evaluated against a managed server 130 during the initialization process. Then, tag/CC value suggestions can be made for any dimension/CC, and the end user can accept or reject those suggestions. For example, if a managed server 130 is running a Postgres database or a MySQL database, the suggested tag may be &lt;Role, Database&gt;. If a managed server is running a Linux operating system, the recommended value of the operating system CC can be "Linux".

In another embodiment, the tag/CC engine calculates the tag/CC value based on cluster analysis. For example, the tag/CC engine uses a combination of minimum cut and K-means algorithm, where an additional heuristic of connected graphics is used to automatically identify a cluster of highly connected managed servers 130. The cluster of managed servers 130 may correspond to one of the "applications" in the management domain 150 (see Table 1). The end user can choose to apply one value of the application dimension (or any other dimension) to all of their managed servers 130.

The global management domain management principle 330 includes one or more rules. Broadly speaking, a "rule" defines a relationship between one or more providers of a service and one or more consumers of that service.

Rule function-the relationship is subjected to a "rule function", which is the actual effect of the rule. For example, in the context of security, the rule function can be access control, secure connectivity, disk encryption, or control of executable processing programs. With an access control function A rule stipulates whether a consumer can use the services of a provider. In one embodiment, the access control function uses a pure "white list" model, which means that only allowable relationships are expressed and all other relationships are blocked by default. A rule with a secure connectivity function specifies which secure channel a consumer can use (for example, an encrypted network session that uses peer-to-peer data encryption) to use a provider's service. For example, a rule with a secure connectivity function may stipulate that when the provider is located in the United States and the consumer is located in the European Union, the use of a provider's service must be encrypted. A rule with a disk encryption function specifies whether a provider must store its data on an encrypted file system. A rule with an executable process control function specifies whether a provider must execute on an encrypted file system.

In the case of resource use, the rule function can be used by disks or peripheral devices. A rule with a disk usage function stipulates that a consumer can store a certain amount of data on a provider. Note that a rule can also stipulate that other rule functions are far more than just access control, secure connectivity, disk encryption, control of executable processes, disk usage, and peripheral device usage. For example, a rule function can specify which open systems interconnection (OSI) model layer-7 services are applied to network traffic, the amount of metadata collected for security analysis, or used to retrieve a complete Trigger procedure of network packet. The management principle model supports any number of rule functions that can be applied.

A rule function can be associated with one or more settings (referred to herein as a "function profile") that specifies the details of the actual effect of the rule. For example, the setting associated with a secure connectivity rule function can be a list of encryption algorithms used to encrypt network traffic. In one embodiment, a rule function is associated with multiple function profiles, and a function profile includes a priority. This priority is used by the function level command generation module 360, as described below.

Service-Generally speaking, a "service" is to execute an arbitrary process on a specific network port using a specific network protocol. One of the rules of the management principle 330 one service The service is provided by a port/protocol pair and (as the case may be) additional qualifications (such as processing information and/or package information (described above in the description of a managed server 130 in the management domain status 320)). If a managed server 130 has multiple network interfaces, a service can be exposed to all networks or only a subset of their networks. The end user specifies which networks the service will be exposed to.

Provider/Consumer-One or more providers of services and one or more consumers of services (ie, users) are managed servers 130 and/or unmanaged devices 140.

In one embodiment, an information set is used to represent a rule in the global management domain management principle 330, and the information set includes a rule function part, a service part, a provided part, a used part, and a selection rule condition part. The rule function part describes the actual effect of the rule and can be associated with one or more settings (function profile). The service section describes the rules that apply to its services. If the service section indicates "All", the rules apply to all services.

The provided (PB) part describes which managed servers 130 and/or unmanaged devices 140 can provide services (that is, who is the "provider"). If the PB part indicates "anyone", then any one (for example, any managed server 130 or unmanaged device 140) can provide the service. If the PB part indicates "any managed server", then any managed server 130 can provide services. ("Any managed server" is equivalent to stipulating a label set containing a wildcard character to match all managed servers 130.) The used (UB) part describes which managed servers 130 and/ Or the unmanaged device 140 can use the service (that is, who is the "consumer"). Similar to the PB part, the UB part can also indicate "anyone" or "any managed server".

In the PB part and the UB part, a managed server 130 is specified by using a label set (that is, describing one or more labels of the managed server) or a UID. Using the tag set to specify the ability of the managed server 130 to originate from the logical management model, and the logical management model refers to the managed server based on its dimensions and values (tags). Unmanaged A UID of a device group (UDG) defines an unmanaged device 140. If a rule specifies a UDG, the rule includes additional information about the unmanaged devices 140 in that group (for example, the device's network exposure information). The PB part of a rule and/or the UB part of a rule may include multiple items, including a tag set (used to specify the managed server 130), a managed server UID and/or UDG UID.

The rule condition part (which is optional) specifies whether the rule is applicable to a specific managed server 130 and/or a specific network interface of that managed server. The rule condition part is a Boolean expression that includes one or more configured characteristics ("CC"; part of the description of one of the managed servers in the management domain status 320) and/ Or network exposure information (for example, the BRN identifier of a network interface; it is also part of the description of a managed server in the management domain status 320). The CC part of the expression specifies whether the rule applies to a specific managed server, and the network exposure information part of the expression specifies whether the rule applies to a specific network interface of that managed server. If the configured characteristic of a specific managed server (specifically, the value of the configured characteristic of that managed server) and the information expression of a specific network interface evaluate to "true", then the rule It is applicable to the related network interface of the managed server and the managed server. If the expression evaluates to "false", the rule does not apply to the relevant network interface of the managed server and the managed server. For example, if a configured feature stores an indication of which operating system is running on the managed server, the condition part of a rule that includes that configured feature can be based on the operating system control rules of a specific managed server Whether it is applicable to that server.

The rules in the principle of global management domain management 330 are organized into a list of rules. Specifically, the management principle 330 includes one or more rule lists, and a rule list includes one or more rules and (as appropriate) one or more categories. A "category" restricts where a rule is applied (that is, which managed servers 130 are applied to). One category contains one of the provided (PB) part and one used (UB) part of the application of the rules in the restriction rule list. The PB part of the category restricts the PB part of the rules, and the UB part of the category restricts the UB part of the rules. one The PB part and the UB part of the category can define a group of managed servers 130 by using a label set. If the tag set does not contain a tag for a specific dimension, there is no category restriction on the other dimension of the group obtained by the managed server 130. If a list of rules does not contain any category, its rules are applied globally.

Different categories can be applied to a single list of rules. For example, an end user can create a set of rules that express how the web service level consumes services from the database level, how the load balancing level consumes services from the web service level, and so on. Then, if the end user wants to apply this rule list to his production environment and its preparation environment, he does not need to copy or repeat the rule list. Instead, it applies multiple categories to a single list of rules. The category is abstracted from a usability perspective and a calculation perspective to make a rule list scale.

Now that the global management domain management principle 330 has been described, it is helpful to take some examples. Consider a management domain 150 with one two-level application (where a user device accesses a web server (first level) and the web server accesses a database server (second level)). In the first level, the user device is the consumer, and the web server is the provider. In the second level, web servers are consumers, and database servers are providers. The management domain 150 contains two instances of this application: one instance in a production environment and one instance in a preliminary environment.

The web server and the database server are managed by the management server 130, and their descriptions (for example, tag set) exist in the management domain state 320. For example, the label set is: web server in production: &lt;Role,Web&gt; and &lt;Environment,Production&gt;

Database server in production: &lt;Role,Database&gt; and &lt;Environment,Production&gt;

Web server in preparation: &lt;Role,Web&gt; and &lt;Environment,Staging&gt;

Database server in preparation: &lt;Role,Database&gt; and &lt;Environment, Staging&gt;

(The application dimension, business operation dimension, and location dimension are not related to this instance, so their labels are omitted.)

Now consider the following global management domain management principle 330, which is one of the security principles stipulating access control and secure connectivity:

Rule list #1

category

o&lt;Environment,Production&gt;

o&lt;Environment,Staging&gt;

rule

o #1

Function: Access control

Service: Apache

PB: &lt;Role,Web&gt;

UB: either

o #2

Function: Access control

Service: PostgreSQL

PB: &lt;Role,Database&gt;

UB: &lt;Role,Web&gt;

Rule list #2

˙Category: None

rule

o #1

Function: secure connectivity

Service: All

PB: &lt;Role,Database&gt;

UB: Any managed server

Note that the above rules simply refer to the services as "Apache" and "PostgreSQL" for clarity. Remember, a service is a process and consists of a port/protocol pair and (as the case may be) additional qualifications (such as process information and/or package information (above regarding the management domain status 320 to a managed server 130) A description described)) provisions.

The rule list #1/rule #1 allows any device (for example, a user device) to connect to a web server and use Apache services. Specifically, allowing a connection is specified by the "access control" in the function section. "Any device" is defined by "Any one" in the UB section. "Web server" is specified by "&lt;Role,Web&gt;" (including only one tag and one tag set) in the PB part. The Apache service is specified by "Apache" in the service section.

Rule list #1/rule #2 allows a web server to connect to PostgreSQL on a database server. Specifically, allowing a connection is specified by "Access Control" in the function section. "Web server" is specified by "&lt;Role,Web&gt;" in the UB section. "PostgreSQL" is specified by "PostgreSQL" in the service section. "Database server" is specified by "&lt;Role,Database&gt;" (including only one tag and one tag set) in the PB section.

Rule list #1 also prevents connections between environments. For example, if a web server and a database server are both in the same environment (for example, both are in the production environment or both are in the preparation environment), then the web server is allowed to connect to the PostgreSQL on the database server. The two servers in the production environment are defined by the "&lt;Environment,Production&gt;" (including only one label and one label set) in the category part, while the two servers in the preparation environment are defined by the "&lt; Environment, Staging&gt;" (including only one label and one label set) stipulates. Therefore, if a web server and a database server are in different environments (for example, if the web server is in a preparation environment and the database server is in a production environment), the web server is not allowed to connect to the data PostgreSQL on the library server.

Rule #2 states that whenever any managed server connects to a database server, it must be connected through an encrypted channel. Specifically, the "database server" is specified by the "&lt;Role,Database&gt;" in the PB section. The "encrypted channel" is specified by the "secure connectivity" in the function section. "Any managed server" is specified by "Any managed server" in the UB section. "Whenever" is specified by "All" in the service section.

Apart from the above example, consider the following two managed servers 130: Server 1 is a web server, which is part of the production (part of app1) and is owned by California Engineering. It will be marked as: &lt;Role,Web&gt;

&lt;Environment,Production&gt;

&lt;Application,app1&gt;

&lt;LB,Engineering&gt;

&lt;Location,US&gt;

Server 2 is a database server, which is part of production (also part of app1) and is also owned by engineering (but in Germany). It will be marked as: &lt;Role,Database Server&gt;

&lt;Environment,Production&gt;

&lt;Application,app1&gt;

&lt;LB,Engineering&gt;

&lt;Location,EU&gt;

Assume that an access control rule allows all access to all managed servers 130 that are part of app1. This rule will allow server 1 and server 2 to communicate with each other and will not allow the managed server 130 that is part of app2 in Germany to communicate with server 1 or server 2. Now suppose that a secure connectivity rule stipulates that all between EU and US must be Network traffic encryption. The rule function is applied independently. In other words, secure connectivity rules are a separate principle that is independent of the application of access control rules. Therefore, network traffic from Server 1 to Server 2 will be allowed (in view of the access control rules) and encrypted (in view of the secure connection rules).

Returning to FIG. 3, the processing server 310 generates a management command for the managed server 130 and sends the generated management command to the server. The processing server 310 also processes the local status information received from the managed server 130. The processing server 310 includes various modules, such as a policy engine module 340, a related rule module 350, a function-level command generation module 360, an actor enumeration module 370, a related actor module 380, and a Management domain status update module 385. In one embodiment, the processing server 310 includes communicating with the repository 300 and processing data (for example, by executing the policy engine module 340, the related rule module 350, the function level command generation module 360, and the actor enumeration module One of the computers (or a group of computers) in the group 370, the related actor module 380, and the management domain status update module 385).

The related rule module 350 takes the global management domain management principle 330 as input, and an instruction of a specific managed server 130 (for example, the UID of that server) generates a set of rules related to that server and outputs the rule gather. This is the related rule module 350 through its review of the management principle 330 and extracts one of the related rules only for a given managed server 130 screening process. The relevant rule module 350 performs filtering by repeatedly passing through all the rule lists in the management principle 330, analyzing the scope of each rule list to determine whether the scope is applicable to the managed server 130 and (if these The category is indeed applicable to this managed server 130) Analyze the rules of each rule list to determine whether their rules are applicable to this managed server 130. A rule applies to a managed server 130 under the following circumstances: a) the PB part of the rule and/or the UB part of the rule specifies the managed server; and b) the conditional part (if any) of the rule is for The managed server (specifically, the value of the configured characteristic and the network exposure information for the managed server) is evaluated as "true". The final result (referred to as a "management principle perspective" in this article) is two sets of rules A combined set: a rule where the managed server 130 provides a service and a rule where the managed server 130 consumes a service.

The function-level command generation module 360 takes a rule set (for example, a management principle perspective generated by the relevant rule module 350) as input, generates function-level commands, and outputs function-level commands. The function level command is later sent to a managed server 130 as part of the management command. A function level command is similar to a rule in that each includes a rule function part, a service part, a PB part, and a UB part. However, although a rule can include multiple items (including tag set, managed server UID and/or UDG UID) in its PB part and/or UB part, a function level command is included only in its PB part One item and only one item in its UB part. In addition, although a rule can specify a managed server (including its multiple network interfaces) in its PB part and/or UB part, a function level command includes only one network in its PB part and UB part. Road interface.

The function-level command generation module 360 analyzes a rule and generates one or more function-level commands based on the rule. If the PB part of the rule contains multiple items, the UB part of the rule contains multiple items, or the rule (in the PB part or the UB part) refers to a managed server with multiple network interfaces, the function level command is generated The module 360 generates multiple function-level commands (for example, a function-level command for each possible combination of a PB project, a UB project, and a specific network interface).

Consider one of the two items (A and B) included in the PB part and one of the two items (C and D) in the UB part. The function-level command generation module 360 will generate four function-level commands with the following PB part and UB part: 1) PB=A, UB=C; 2) PB=A, UB=D; 3) PB=B, UB =C; 4) PB=B, UB=D. It is now considered to cover one of the managed servers in its PB part or UB part (for example, by specifying a UID or a label set) and that the managed server has a rule of multiple network interfaces. The function-level command generation module 360 will generate multiple function-level commands (for example, a function-level command). Level commands are used for each network interface of the managed server).

The function-level command generation module 360 analyzes the rules, the functions in their rules, and the function configuration files referenced by their rules. If a rule list includes multiple categories, the function-level command generation module 360 repeatedly applies those categories to the rule list (thereby generating a complete set of function-level commands for each category). Recall that a rule function can be associated with multiple function profiles, and a function profile can include a priority. The function level command generation module 360 sorts the rules based on the priority of various function profile so that the function profile with the highest priority is used. The function-level command generation module 360 translates the sorting rules into function-level commands to be executed by the managed server 130. The function level command refers to the appropriate managed server 130 and/or unmanaged device 140 (for example, the managed server 130 and/or unmanaged device 140 referenced in the input rule), so as to consider the service associated with the rule The details of online exposure.

Note that the function-level command generation module 360 can generate a function-level command for a specific managed server 130 that is proven to be irrelevant to that server. For example, the managed server is covered by the provided (PB) part of a rule, so the function-level command generation module 360 generates a corresponding function-level command. However, the rule also includes a part that specifies the local state of the managed server (for example, describing a service part of the provided service). Since the global manager 120 does not know the local state of the managed server (for example, whether the managed server actually provides the service), the generated function level command is sent to the managed server. The managed server checks its local state (for example, whether it provides that service) and processes function-level commands accordingly, as explained below with reference to the principle compilation module 410.

The actor enumeration module 370 takes a set of descriptions of the managed server 130 and the unmanaged device group (UDG) (for example, the status 320 of the computer network infrastructure of the management domain) as input, and generates an enumeration form The representation of the server and UDG's description (referred to as the "action set") and output the set of actors. For example, the actor enumeration module 370 List the managed servers 130 and UDGs and possible tag sets in the management domain state 320 and assign a unique identifier (UID) to each. Then, this set of actors can be used together with the UB part and the PB part of the rules and scope of the actors that specify the use of the managed server UID, UDG UID, and/or tag set.

Consideration includes<i>N</i>Dimensions<i>D</i>_<i>i</i>(<i>i</i>=1、...、<i>N</i>) One set and each dimension<i>D</i>_<i>i</i>Contains possible values<i>V</i>_<i>j</i>(<i>j</i>=1、...、<i>M</i>_<i>i</i>) (Where the wildcard character "*" is one of the possible values) one set<i>S</i>_<i>i</i>One of the logical management model. In one embodiment, the actor enumeration module 370 enumerates all possible label sets based on the logical management model, which is equivalent to<i>S</i>₁×<i>S</i>₂×...×<i>S</i>_<i>N</i>Give the Cartesian product. The size of this collection is<i>M</i>₁×<i>M</i>₂×...×<i>M</i>_<i>N</i>. The enumeration processing program folds the multi-dimensional label space of the managed server 130 into a single enumeration form.

In another embodiment, the actor enumeration module 370 enumerates the possible tag sets based only on the management domain status 320 (for example, based on the description of the managed servers in the management domain 150). For example, consider a logical management model that includes 2 dimensions (X and Y) and each dimension includes 3 possible values (A, B, and *). A managed server with a label set "&lt;X=A&gt;, &lt;Y=B&gt;" can be a member of 4 possible label sets: 1) "&lt;X=A&gt;, &lt;Y=B&gt;"; 2 ) "&lt;X=A&gt;,&lt;Y=*&gt;"; 3) "&lt;X=*&gt;,&lt;Y=B&gt;"; and 4) "&lt;X=*&gt;,&lt;Y=*&gt;". Note that the label set of the managed server exists in a two-dimensional space (X and Y), and it is possible that the label sets 2, 3, and 4 are the label sets of the managed servers to the sub-dimensional space (the label set 2 is a one-dimensional space). (X), the label set 3 is a projection in a one-dimensional space (Y), and the label set 4 is a projection in a 0-dimensional space. Therefore, the actor enumeration module 370 enumerates the 4 possible tag sets. The managed server with the tag set "&lt;X=A&gt;, &lt;Y=B&gt;" cannot be a member of the tag set "&lt;X=A&gt;, &lt;Y=A&gt;", so the actor enumeration module 370 does not List the set of tags.

An actor set includes a UID and zero or more actor set records. An actor collection record includes a UID (a managed server UID or a UDG UID), the actors An identifier of the operating system and the IP address of the actor (managed server 130 or unmanaged device 140) in view of the specific BRN. For example, a set of actors may include a set of actors whose IP addresses correspond to all the managed servers 130 covered by the tag set of &lt;Role,Database&gt; and &lt;Environment,Production&gt;. As another example, a set of actors may include a set of actors whose IP addresses correspond to all unmanaged devices 140 in the headquarters UDG. A single actor (for example, the managed server 130 or the unmanaged device 140) may appear in multiple actor sets.

Another factor in the calculation of the set of actors is the actors with multiple network interfaces plus network topology, such as network address translation (NAT). Therefore, there may be two sets of actors in the tag sets of &lt;Role,Database&gt; and &lt;Environment,Production&gt;: Internet-opposite IP addresses with their managed servers 130 (that is, with a first A set of actors associated with a BRN, and one of their private network counter-IP addresses of the same managed server (that is, associated with a second BRN) is different Actor collection.

In one embodiment, the actor enumeration module 370 may also update the actor set based on the change of the state 320 of the management domain. For example, the actor enumeration module 370 takes as input a set of actors (previously output by the actor enumeration module) and a change in the description of a managed server (in the management domain state 320) to generate an updated action The set of actors (which is consistent with the changed server description) and the updated set of actors are output. The actor enumeration module 370 generates the updated actor set in different ways depending on the type of change in the description of the managed server.

Offline/Online Change-If the description change indicates that the server changes from online to offline, the actor enumeration module 370 is generated by removing the actor collection record of the server from all input actor collections of a member of the server The updated collection of actors. If the description change indicates that the server changes from offline to online, the actor enumeration module 370 generates an updated actor set by adding the server's actor set record to any related input actor set combine. (If necessary, the actor enumeration module 370 creates a new actor set and adds the server's actor set record to the new actor set.)

Tag set change-if the description change indicates that the tag set of the server is changed, then the actor enumeration module 370 becomes offline as a first server (with old tag set) and a second server (with new tag set) Treat this situation as online.

Network exposure information change-If the description change instructs to remove a server from a network interface, the actor enumeration module 370 uses the set of all input actors from a member of the server (with the BRN of that network interface) Associated) The actor set record of the server is removed to generate an updated actor set. If the description change instructs to add a server to a network interface, the actor enumeration module 370 adds the servers actor set record to any related input actor set (associated with the BRN of that network interface) ) To generate a set of updated actors. (If necessary, the actor enumeration module 370 creates a new actor set (associated with the BRN of the network interface) and adds the server's actor set record to the new actor set.) If the description changes Instruct the server to change the BRN of a network interface, the mobile enumeration module 370 treats this as if removing a first network interface (with the old BRN) and adding a second network interface (with a new BRN) condition. If the description change instructs the server to change the IP address of a network interface (instead of BRN), the actor enumeration module 370 modifies the set of all input actors of a member of the server (with that network interface). BRN associated with) the actor set record of the server in the server to generate an updated actor set.

The relevant actor module 380 takes one or more sets of actors (for example, the managed server 130 and UDG in the management domain state 320 in the form of enumeration) and a set of rules (for example, a management principle perspective) as input , Determine which set of actors are related to their rules and output only their set of actors. The related actor module 380 examines the actor set and extracts only one of the related actor sets for a given rule set to filter processing. The related actor module 380 performs filtering by the following operations: iteratively go through all the input actors set, analyze the PB part and UB part of the input rule to determine a specific action Whether the set of persons is referenced by either the PB part or the UB part of the rule. The final result (referred to as an "actor's perspective" in this article) is a collection of actors. The actor's perspective is later sent to a managed server 130 as part of the management command.

In one embodiment, the relevant actor module 380 uses the input rule set to generate an "actor set screening process". The actor set screening program selects only the actor set related to the input rule from the input actor set. In other words, the related actor module 380 uses the actor set screening process to filter the input actor set into a related actor set.

The policy engine module 340 generates management commands for the managed server 130 and sends the generated management commands to the server. The principle engine module 340 generates management commands based on the following items (using the relevant rule module 350, the function level command generation module 360, the actor enumeration module 370, and the relevant actor module 380): a) the computer network of the management domain State 320 of the road infrastructure; and b) Principles of full management domain management 330.

For example, the policy engine module 340 executes the related rule module 350 to provide the global management domain management policy 330 and the UID of a specific managed server 130 as input. The related rule module 350 outputs a set of rules related to the server (a "management principle perspective"). The policy engine module 340 executes the actor enumeration module 370 to provide the management domain status 320 as input. The actor enumeration module 370 outputs one of the descriptions of the managed server 130 and the unmanaged device group (UDG) in the management domain state 320 in a form of enumeration ("action set"). The principle engine module 340 executes the function-level command generation module 360 to provide the management principle perspective (output by the relevant rule module 350) as an input. The function-level command generation module 360 outputs function-level commands. The policy engine module 340 executes the related actor module 380, thereby providing a collection of actors (output by the enumeration module 370) and a management principle perspective (output by the related rules module 350) as input. The related actor module 380 outputs their set of actors that are only related to their rules ("related actor set"). The principle engine module 340 converts function-level commands (from the function-level command generation module 360 output) and the set of related actors (output by the related actor module 380) are sent to the specific managed server 130.

In one embodiment, the policy engine module 340 caches the information generated during the above processing procedure. For example, the policy engine module 340 is associated with a specific managed server 130 to cache management policy perspectives, function level commands, actor set screening procedures, and/or related actor sets. As another example, the policy engine module 340 caches a set of actors (which is not unique to a particular managed server 130).

Since the set of actors in a management domain is based on the management domain state 320, a change in the management domain state 320 may require a change in one of the set of actors in the management domain. Similarly, since the management command of a managed server is based on the management domain status 320 and the management domain management principle 330, a change in one of the management domain status 320 and/or a change in one of the management domain management principles 330 may require the managed server One of the management commands of the device has changed. In one embodiment, the policy engine module 340 can update a set of actors in a management domain and/or update a management command of a managed server and then distribute these changes (if necessary) to the managed server 130 . The above-mentioned cached information helps the policy engine module 340 to more efficiently update the set of actors in the management domain and/or the management commands of the managed server and decentralize the changes.

In one embodiment, the policy engine module 340 updates a set of actors in a management domain (based on one of the management domain status 320 changes) and distributes the changes to the managed server 130 as follows: The policy engine module 340 executes the actors The enumeration module 370 thus provides the cached agent set (previously output by the actor enumeration module) and the changed part of the management domain state 320 (that is, the changed server description) as input. The actor enumeration module 370 outputs the updated actor set. In one embodiment, the policy engine module 340 then sends all the updated actor sets to all the managed servers 130 in the management domain 150. However, this embodiment is inefficient, because not all managed servers are affected by changes in the set of all actors.

In another embodiment, only the set of selected actors is sent to the selected server. Lift For example, sending to a specific managed server only a) previously sent to that server and b) their changed set of actors. Cached related actor sets indicate which actor sets were previously sent to that server (see (a) above). The principle engine module 340 compares the set of cached actors with the set of updated actors to determine which sets of actors have changed (see (b) above). The principle engine module 340 then calculates the intersection of (a) and (b). The set of actors in that group is sent to a specific managed server. In one embodiment, for even greater efficiency, the set of actors is sent in a "difference" format. For example, the differential format specifies an actor set identifier, an actor identifier (for example, a managed server UID or a UDG UID), and an indication of whether the other actor should be added, removed, or modified.

In another embodiment, two tables are maintained and used to improve efficiency. A first table associates a managed server 130 with a set of actors of which the managed server is a member. A second table associates a managed server 130 with a set of actors related to that managed server (for example, as determined by the relevant actor module 380). In these tables, a managed server 130 is represented by, for example, the UID of that managed server, and a set of actors is represented by, for example, the UID of that set of actors. The policy engine module 340 uses the changed part of the management domain status 320 (that is, the changed server description) to determine which managed server description is changed. The policy engine module 340 uses the first table to determine which actor set the managed server is a member of. The set of actors may change due to changes in the server description. Therefore, the policy engine module 340 uses the second table to determine which managed servers their set of actors are related to. The policy engine module 340 performs the intersection calculation described above for only their managed servers.

In one embodiment, the policy engine module 340 updates the management command of a managed server (based on one of the management domain status 320 changes) and sends the updated management command to the managed server as follows: policy engine module 340 The relevant rule module 350 is executed, thereby providing the full management domain management principle 330 and the UID of the managed server 130 as input. The related rules module 350 outputs a set of rules related to the server (a "management principle perspective"). The principle engine module 340 compares the management principle perspective just output with the cached management principle perspective to determine whether they are different. If the management principle perspective just output is the same as the cached management principle perspective, the policy engine module 340 does not take further action. In this case, the previously generated management commands of the managed server (specifically, the function level commands and related actors set) are consistent with the change of the management domain state 320 and do not need to be regenerated and re-sent to the managed server.

If the management principle perspective just output is different from the cached management principle perspective, the policy engine module 340 determines which rules should be added to the cached perspective and which rules should be removed from the cached perspective. The policy engine module 340 executes the function-level command generation module 360 to provide the rules to be added and the rules to be removed as input. The function-level command generation module 360 outputs the function-level commands to be added and the function-level commands to be removed (as opposed to the cached function-level commands, which were previously sent to the managed server). The policy engine module 340 instructs the managed server to add or remove various function level commands as appropriate. In one embodiment, for greater efficiency, function level commands are sent in a "difference" format. For example, the differential format specifies a function-level command identifier and an indication that the function-level command should be added to the previously sent function-level command or removed from the previously sent function-level command.

The policy engine module 340 also executes the actor enumeration module 370 to provide the changed part of the cached actor set and management domain state 320 (ie, the changed server description) as input. The actor enumeration module 370 outputs the updated actor set. The policy engine module 340 executes the relevant actor module 380 to provide the updated actor set and the management principle perspective just output as input. The related actors module 380 outputs their updated set of actors that are only related to their rules ("updated related actors set").

The policy engine module 340 compares the updated set of related actors with the cached set of related actors to determine whether they are different. If the updated set of related actors is the same as the set of cached related actors, the policy engine module 340 does not send the set of actors to the managed server. Server. In this case, the previously generated set of related actors is consistent with the change of the management domain status 320 and does not need to be re-sent to the managed server. If the updated set of related actors is different from the set of cached related actors, the principle engine module 340 determines which sets of actors should be added, removed, or modified relative to the set of cached related actors. The policy engine module 340 instructs the managed server to add, remove or modify various sets of actors as appropriate. In one embodiment, for greater efficiency, the set of actors is sent in a "difference" format. For example, the difference format specifies an actor set identifier and an indication of whether another actor set should be added, removed, or modified relative to the previously sent actor set.

The recall policy engine module 340 can update a management command of a managed server (a change based on one of the global management domain management principles 330) and send the updated management command to the managed server. One of the changes in the management principle 330 is, for example, the addition, removal or modification of a rule or a set of rules. In one embodiment, a change in the management policy 330 is generated by interaction with the global manager 120 via a GUI or API. In another embodiment, a change in the management policy 330 is generated by an automated process in the global manager 120 (for example, in response to a security threat detected by the global manager). The policy engine module 340 updates the management command of the managed server and sends the updated management command to the managed server in a similar manner, regardless of whether there is a change in one of the management policies 330 or one of the management domain status 320. However, there are several differences.

In a situation where one of the management principles 330 is changed, the policy engine module 340 does not need to update the management commands for all managed servers 130. Alternatively, the principle engine module 340 compares the previous management principle 330 with the new management principle 330 to determine which rules should be added, removed or modified relative to the previous management principle 330. The policy engine module 340 determines which managed servers 130 are affected by the changed rule (for example, which managed servers are affected by a) the rule and/or the PB part and/or the UB part of the category and b) the condition part of the rule (if Exists) covers). The policy engine module 340 executes the relevant rule module 350 to provide the changed rules (rather than the completely new management policy 330) and the managed server 130 (for those servers that are only affected by the changed rules). Server) UID as input.

The management domain status update (ADSU) module 385 receives the changes of the management domain status 320 and processes them. A change in the management domain status 320 is, for example, the addition, removal, or modification of a description of a managed server 130 (including a set of tags of a managed server or modification of a configuration feature) or a Add, remove, or modify the description of an unmanaged device or one of the unmanaged device groups. In one embodiment, a change in the management domain status 320 originates in the local status information received from a particular managed server 130. In another embodiment, a change in the management domain status 320 is generated by interacting with the global manager 120 via a GUI or API. In another embodiment, a change in the management domain status 320 is generated by an automated process in the global manager 120 (for example, in response to a security threat detected by the global manager).

For example, the ADSU module 385 receives a change regarding a particular managed server 130. The ADSU module 385 stores the new information as part of the description of the specific managed server 130 in the management domain state 320. The ADSU module 385 then (as appropriate) analyzes the description of the managed server to determine additional information about the server and stores that information in the description. The ADSU module 385 then determines whether to update the set of actors of the management domain and/or the management command of the managed server based on one of the descriptions of the managed server. If the ADSU module 385 determines to update the set of actors in the management domain, the ADSU module 385 instructs the policy engine module 340 to update the set of actors in the management domain. In one embodiment, the ADSU module 385 waits for an event to occur before instructing the policy engine module 340 to update the set of actors in the management domain. If the ADSU module 385 determines to update the management command of the managed server, the ADSU module 385 instructs the policy engine module 340 to update the management command of the managed server. In one embodiment, the ADSU module 385 waits for an event to occur before instructing the policy engine module 340 to update the management commands of the managed server. The aforementioned event may be, for example, the receipt of a user command or the occurrence of a prescribed maintenance window.

The ADSU module 385 determines whether to update the set of actors in the management domain and/or the managed server Server management commands depend on the type of change in the description of the managed server. In one embodiment, the ADSU module 385 makes this determination, as determined in Table 2:<tables><img he="1570" wi="2086" file="tw201445461a_d0002.tif" img-content="drawing" img-format="tif" orientation="portrait" inline="no" /></tables>

In one embodiment, the ADSU module 385 determines additional information about the server by executing the tag/configured feature engine and providing the description of the server as input. The tag/CC engine calculates the tag/CC value of the server based on the description of the server and the tag/CC assignment rules.

In another embodiment, the ADSU module 385 determines whether the server is behind a network address translator (NAT) (and if it is behind a NAT, what type of NAT-1: 1 or 1 : Behind N). For example, the ADSU module 385 determines whether there is a NAT between the global manager 120 and the managed server 130 by comparing the following items: (a) According to the TCP connection between the global manager and the server The IP address of the server; and (b) the IP address of the server based on the local status information received from the server. If (a) and (b) are different, then There is a NAT between the global manager 120 and the managed server 130. If a NAT does exist, the ADSU module 385 determines the type of NAT (1:1 or 1:N) by performing data center detection. For example, the ADSU module 385 identifies the data center of the server by its public IP address. (Another option is that the managed server performs data center detection by querying information outside the server but inside the data center. The server then sends that information to the global manager as part of the local state.) The configuration information indicates which types of NAT are used by which data centers. If no NAT information is associated with a specific data center, the ADSU module 385 assumes that the NAT type is 1:N.

4 is a high-level block diagram illustrating a detailed view of a principle implementation module 136 of a managed server 130 according to an embodiment. The policy implementation module 136 includes a local state storage 400, a policy compilation module 410, and a local state update module 420. The local state storage 400 stores information about the local state of the managed server 130. In one embodiment, the local state repository 400 stores information about the operating system (OS), network exposure, and services of the managed server. The OS information includes, for example, an indication of which OS is running. The network exposure information and service information are described above with reference to one of the descriptions of a managed server 130 in the management domain state 320.

The principle compilation module 410 takes a management command and status of a managed server 130 as input and generates a management module configuration 134. For example, the management command is received from the global manager 120 and includes a function-level command (generated by the function-level command generation module 360) and a related actor set (output by the related actor module 380). The status of the managed server 130 is retrieved from the local status repository 400. In one embodiment, the execution of the policy compilation module 410 is triggered by the following operations: a) the managed server is powered on or becomes online; b) the managed server receives function-level commands; and/or c) the local machine The content of the state repository 400 changes.

The principle compilation module 410 maps function-level commands and related actors sets to a management module configuration 134. For example, the policy compilation module 410 integrates an access control function layer Level commands (which contain a port and an actor set reference) are mapped to an iptables entry and an ipset entry in the Linux operating system or a Windows Filtering Platform (WFP) rule in the Windows operating system.

The application of the management policy at a managed server 130 may be affected by the local state of the other server. In one embodiment, the principle compilation module 410 evaluates a condition associated with a received function level command and generates the management module configuration 134 based on the result of the evaluation. For example, the policy compilation module 410 evaluates a condition of the operating system with reference to the peer of the managed server (that is, other actors in the relationship) and selects the function profile attribute based on the result of the evaluation, where The attributes of the selected function profile are expressed in the management module configuration 134.

As another example, recall that a managed server 130 may receive a function level command that proves to be unrelated to that server. For example, a rule includes a part that specifies the local state of a managed server (for example, a service part that describes a service provided). Since the global manager 120 does not know the local state of the managed server (for example, whether the managed server actually provides the service), the generated function level command is sent to the managed server. The policy compilation module 410 checks the local state of the managed server (for example, determines whether the managed server provides the service). This determination is equivalent to evaluating a condition of the local state of the reference managed server. The principle compilation module 410 processes the function level instructions accordingly. If the policy compilation module 410 determines that the condition is evaluated as "true" (for example, the managed server is providing the service), the policy compilation module 410 incorporates the function level command into the management module configuration 134. Specifically, the principle compilation module 410 only incorporates the function-level commands into the management module configuration 134 after evaluating the associated conditions (which focus on the local state of the other server). If the evaluation of the condition is false, the principle compilation module 410 does not express function level commands in the management module configuration 134. Specific conditions (for example, their nature and specific values) are extensible. In one embodiment, the condition is related to the definition of a "service" and includes processing information and/or package information (above regarding the pairing of a managed server in the management domain status 320) As described in one of the descriptions of the device 130).

For example, consider allowing access to one of the functional level commands of the Apache service that is only incoming on port 80 (that is, where the managed server 130 is the "provider" or endpoint). The managed server 130 expresses this function-level command in the management module configuration 134 to allow access on port 80 only after evaluating the associated conditions. Run on the server) is it actually Apache and not some other application (rogue application or other). The managed server 130 expresses this function level command in the management module configuration 134 only after determining that the associated condition is evaluated as "true". If the associated condition is evaluated as "false", the managed server 130 does not express this function level command in the management module configuration 134. Therefore, Internet traffic is blocked.

In one embodiment, a managed server 130 monitors its outgoing connections. The managed server 130 compares the outgoing network traffic with its internal processing procedure table to determine which processing procedures in the table are establishing their outgoing connections. The managed server 130 can enforce a rule that allows only certain processing procedures (in view of the one mentioned above that requires a collection) to establish an outgoing connection.

In one embodiment (not shown), the policy compilation module 410 is located at the global manager 120 instead of the managed server 130. In that embodiment, the global manager 120 does not send management instructions to the managed server 130. Alternatively, the managed server 130 sends its local status to the global manager 120. After the principle compilation module 410 generates the management module configuration 134 (at the global manager 120), the management module configuration 134 is sent from the global manager 120 to the managed server 130.

The local status update (LSU) module 420 monitors the local status of the managed server 130 and sends the local status information to the global manager 120. In one embodiment, the LSU module 420 determines an initial local state of the managed server 130, stores appropriate local state information in the local state repository 400, and sends the local state information to the global managementDevice120. The LSU module 420 views each of the operating system (OS) and/or file system of the server This part determines the local status of the managed server 130. For example, the LSU module 420 obtains service information from the core table of the OS (network connection information), the system table (package information) of the OS, and the file system (file and hash value). The LSU module 420 obtains network exposure information from the core and/or OS-level data structure of the OS.

After the LSU module 420 sends the initial local state information to the global manager 120, the LSU module monitors the change of the local state. The LSU module monitors changes by (for example) polling (for example, periodically performing viewing) or listening (for example, subscribing to an event stream). The LSU module 420 compares the newly acquired local state information with the information stored in the local state storage 400. If the information matches, the LSU module 420 does not take any further action (until the local state information is obtained again). If they are different, the LSU module 420 stores the latest information in the local state storage 400, executes the principle compilation module 410 to regenerate the management module configuration 134 (and reconfigure the management module 132 accordingly) ) And notify the global manager 120 of the change. In one embodiment, the LSU module 420 sends the change of the local state information to the global manager 120 in a "difference" format. For example, the difference format specifies a type of local state information (for example, operating system) and a new value of that type of information. In another embodiment, the LSU module 420 sends the complete content of the local state repository 400 to the global manager 120.

FIG. 5 is a flowchart illustrating a method 500 of generating management commands for a specific managed server 130 according to an embodiment. Other embodiments may perform the steps in a different order and may include different and/or additional steps. In addition, some or all of the steps can be performed by entities other than those shown in FIG. 1. In one embodiment, the method 500 is executed multiple times (for example, once for each managed server 130 in a management domain 150).

When the method 500 is started, the status 320 of the computer network infrastructure of the management domain and a global management domain management policy 330 have been stored in the repository 300 of the global manager 120. At this point, method 500 begins.

In step 510, the management domain status 320 and the full management domain management principle 330 are accessed. For example, the policy engine module 340 sends a request to the repository 300 and receives the management domain status 320 and the full management domain management policy 330 in response.

In step 520, one or more related rules are determined. For example, the policy engine module 340 executes the related rule module 350, so as to provide the global management domain management policy 330 and the UID of the specific managed server 130 as input. The related rule module 350 outputs a set of rules related to the server (from the perspective of management principles).

In step 530, the actors are listed. For example, the policy engine module 340 executes the actor enumeration module 370 to provide the management domain status 320 as input. The actor enumeration module 370 generates a representation (action group) for the managed server 130 and the unmanaged device group (UDG) in the management domain state 320 in an enumeration form.

In step 540, one or more function level commands are generated. For example, the policy engine module 340 executes the function-level command generation module 360 to provide the management principle perspective (generated in step 520) as an input. The function-level command generation module 360 generates function-level commands.

In step 550, one or more relevant actors are determined. For example, the policy engine module 340 executes the related actor module 380 to provide a collection of actors (generated in step 530) and a management principle perspective (generated in step 520) as input. The related actors module 380 outputs their set of actors only related to their rules (related actors set).

In step 560, the management instruction is sent to the specific managed server 130. For example, the policy engine module 340 sends the function level command (generated in step 540) and the set of related actors (generated in step 550) to the specific managed server 130.

Note that steps 520 and 540 focus on generating a management principle perspective (and the resulting functional level commands) for a particular managed server 130, while steps 530 and 550 focus on generating an actor perspective for that managed server. The generation of the management principle perspective and the generation of the actor perspective depend on each other to a minimum. This is because step 520 is generated by a rule used in step 550. Then the collection. Even so, keeping the management principle calculation (that is, steps 520 and 540) separate from the actor set calculation (that is, steps 530 and 550) still enhances the scalability of the principle engine module 340. Since the management principle calculation is largely separated from the actor set calculation, it can be executed in parallel (for example, even for the same managed server 130). In addition, the viewing angle calculations for different managed servers 130 can also be executed in parallel. In addition, if an actor changes, only the set of actors needs to be recalculated. (There is no need to recalculate the function level instructions.) If a rule is changed, only the function level instructions and the set of related actors need to be recalculated. (There is no need to re-enumerate the actors.)

FIG. 6 illustrates a flowchart of a method 600 for generating a configuration 134 of a management module 132 of a managed server 130 according to an embodiment. Other embodiments may perform the steps in a different order and may include different and/or additional steps. In addition, some or all of the steps may be performed by entities other than those shown in FIG. 1.

When the method 600 starts, the information about the local state of the managed server 130 has been stored in the local state repository 400 of the policy implementation module 136 in the managed server 130. At this point, method 600 begins.

In step 610, a management instruction is received from the global manager 120. For example, the policy compilation module 410 receives function-level commands and related sets of actors from the global manager 120.

In step 620, the local state is accessed. For example, the policy compilation module 410 accesses information about the local state of the managed server 130 stored in the local state repository 400.

In step 630, a management module configuration 134 is generated. For example, the policy compilation module 410 takes the management command (received in step 610) and the local state (accessed in step 620) as input and generates a management module configuration 134.

In step 640, a management module 132 is configured. For example, the principle compilation module 410 configures the management module 132 to operate according to the management module configuration 134 (generated in step 630). do.

FIG. 7 illustrates a flowchart of a method 700 of monitoring the local status of a managed server 130 and sending local status information to a global manager 120 according to an embodiment. Other embodiments may perform the steps in a different order and may include different and/or additional steps. In addition, some or all of the steps may be performed by entities other than those shown in FIG. 1.

When the method 700 starts, information about the local state of the managed server 130 has been stored in the local state repository 400 of the managed server 130. At this point, the method 700 begins.

In step 710, information about the current local state of the managed server 130 is determined. For example, the LSU module 420 determines the local status of the managed server 130 by viewing various parts of the operating system (OS) and/or file system of the server 130.

In step 720, a determination is performed as to whether the information about the current local state is different from the information stored in the local state storage 400. For example, the LSU module 420 performs this determination. If the information is not different, the method proceeds to step 730 and ends. If the information is indeed different, the method proceeds to step 740.

In step 740, different information is stored in the local state repository 400. For example, the LSU module 420 performs this step.

In step 750, the management module configuration 134 is regenerated (this is because the content of the local state repository 400 has changed) and the management module 132 is reconfigured accordingly. For example, the LSU module 420 executes the principle compilation module 410, which regenerates the management module configuration 134.

In step 760, different information is sent to the global manager 120. For example, the LSU module 420 performs this step.

FIG. 8 is a flowchart illustrating a method 800 of handling a change in the status 320 of a computer network infrastructure of a management domain according to an embodiment. Other embodiments may perform the steps in a different order and may include different and/or additional steps. In addition, some of the steps Or all steps can be performed by entities other than those shown in FIG. 1.

In step 810, a change regarding one of a specific managed server 130 is received. For example, the management domain status update (ADSU) module 385 receives an online/offline indicator, an operating system indicator, network exposure information and/or service information from the managed server 130 as part of the local status information .

In step 820, the received information is stored. For example, the ADSU module 385 stores the received online/offline indicator, network exposure information, and/or service information in the management domain status 320 (specifically, in the description of the managed server 130 to which the information belongs ).

In step 830, the server description is analyzed to determine additional information about the server. For example, the ADSU module 385 uses a tag/configured feature engine to calculate the tag/CC value of the server and/or determine whether the server is behind a network address translator (NAT) (and if it is in Behind a NAT, what type of NAT-1:1 or 1:N it is behind) and store that information in the server description. Step 830 is optional.

In step 840, a determination is made as to whether to update one of the set of actors in the management domain. For example, the ADSU module 385 determines whether to update the set of actors in the management domain based on a change in one of the descriptions of the managed server. If a determination is made to update one of the set of actors in the management domain, the method proceeds to step 850. If a determination is made not to update one of the set of actors in the management domain, the method proceeds to step 860.

In step 850, the set of actors in the management domain is updated. For example, the ADSU module 385 instructs the policy engine module 340 to update the set of actors in the management domain. In one embodiment (not shown), the ADSU module 385 waits for an event to occur before instructing the policy engine module 340 to update the set of actors in the management domain.

In step 860, a determination is made as to whether to update one of the management commands of the managed server. For example, the ADSU module 385 determines whether to update the management command of the managed server based on a change in one of the descriptions of the managed server. If one of the management commands for updating the managed server is determined, the method proceeds to step 870. If you do not update the management domain If one of the set of actors is determined, the method proceeds to step 880.

In step 870, the management command of the managed server is updated. For example, the ADSU module 385 instructs the policy engine module 340 to update the management commands of the managed server. In one embodiment (not shown), the ADSU module 385 waits for an event to occur before instructing the policy engine module 340 to update the management command of the managed server.

In step 880, the method ends.

The above description is included to illustrate the operation of specific embodiments and is not intended to limit the scope of the present invention. The scope of the present invention is only limited by the scope of the following patent applications. From the above discussion, it will be obvious to those who are familiar with the relevant technology that many variations will still be covered by the spirit and scope of the present invention.