JP2002202952A - System and method for restricting data transfer and managing software components of distributed computers - Google Patents

Abstract

PROBLEM TO BE SOLVED: To improve the management of a computer system. SOLUTION: A BMonitor 250 situated on a computer includes a plurality of filters 258 that identify where data can be sent to and/or received from as a client computer coupled to a computer via another node set in a common location facility or the Internet. The BMonitor 250 further receives a request related to the management of a software component executed on the computer from an external source and executes it, whereby the external source can perform the start, termination, debug or the like of the software component. The BMonitor 250 also functions as a trusted third party for intermediating the interaction among a plurality of external sources for managing the computer.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to the management of computer systems. More particularly, the present invention relates to systems, methods, computer-readable media, and computer-readable memories for limiting data transfer and managing software components of distributed computers.

[0002]

BACKGROUND OF THE INVENTION The Internet and its use have expanded significantly in recent years and are expected to continue. One of the prominent uses of the Internet is the World Wide Web.
Web WWW. Also called "Web"),
A collection of documents that a user can view or otherwise provide (referred to as a "web page"), which includes links to one or more other pages that the user can access Is typical. Many businesses and individuals create their presence on the Web, describe themselves or themselves on one or more Web pages, describe their products and services, identify other targeted information, Typically, it is possible to purchase services and services.

[0003] Web pages "host" Web pages.
It is typically made available on the Web through one or more Web servers, a process also known as. These web pages may be freely available to anyone who requests to view them (for example, company advertisements), or if access to the web page is restricted. Yes (for example, accessing a web page may require a password). If a very large number of people are requesting to view a web page (especially in view of the web being accessible globally), a large number of servers will be needed to host the web page sufficiently. (For example, hosting the same web page on multiple servers will increase the number of people who can access the web page simultaneously). In addition, because the Web is geographically dispersed and access is not uniform, it is often desirable to distribute servers to different remote locations and minimize access times for people at different locations in the world. ing. In addition, people spend all day on We
Since they tend to look at page b (again, especially in W
eb is globally accessible),
The server that hosts the web page needs to be up and running 24 hours a day.

However, managing a very large number of servers can be difficult. In order to keep the server running, a highly reliable power supply is required. Physical security is needed to prevent theft and other malicious people from attempting to damage or squash the server. A reliable Internet connection is required to ensure that access requests reach the server. To ensure that the server operates properly, a correct operating environment (for example, temperature, humidity, etc.) is required. Therefore, co-location facilities (co-location facilities) can help businesses address these issues.
facilities) ”has developed.

[0005] Here, the shared location facility is a complex facility capable of accommodating a plurality of servers. Co-location facilities typically provide a reliable Internet connection, a reliable power source, and a suitable operating environment. In addition, co-location facilities may have multiple secure areas (eg,
e)), typically allowing different companies to keep their servers there. The collection of servers that a particular company keeps at a co-location facility is, in effect, any arbitrary co-location facility.
Even though only a single server is located, it is called a "server cluster". in this case,
That particular company will be responsible for managing the operation of the servers in its server cluster.

[0006]

However, problems also arise with such co-location facilities.
One problem is data security.
It is. Different companies (even competitors) have been able to place server clusters in the same co-location facility. In such a situation, data received from the Internet (or transmitted from a server in a server cluster) for one company is routed to another company's server located at the co-location facility. Care must be taken to prevent this from happening.

[0007] Another problem is that of managing servers after being placed in a co-location facility. Currently, a system administrator (system administrator) belonging to a company contacts a co-location facility administrator (typically by telephone) when a server failure (or other problem) occurs and calls a particular server. Reset the server (by pressing the server's hardware reset button or after powering off the server,
It is possible to request an administrator for a typical power-on method. With this limited reset-only function, the management functions available to the company are very poor. Alternatively, a system administrator belonging to a company may go to a co-location facility on its own,
It is now possible to witness a failed server. Unfortunately, a large amount of time is wasted when a system administrator goes to a co-location facility and attends a server. Accordingly, it would be advantageous to have an improved way of managing server computers at a co-location facility.

[0008] Furthermore, the number of personal user computers located in various countries around the world continues to increase, and in the form of personal computers (PC), personal digital assistants (personal digital assistants).
PDA), pocket computer, palm size (palm-siz
ed) Computers, handheld computers, digital cellular phones, etc. Managing the software on these user computers is a very tedious and time-consuming task, and the users of these machines are often non-professionals,
It is especially difficult for these users. The system administrator or technician can go to the remote location where the user's computer is located or walk through administrative operations over the telephone.
-through) is often done. It would be even more advantageous to improve the remote computer management at the user's location without user intervention.

The present invention has been made in view of the above problems, and has as its object to limit the data transfer and manage software components of a distributed computer, which can improve the management of a computer system. To provide a system and method.

[0010]

SUMMARY OF THE INVENTION In the following, it is described that data transfer is restricted and software components are managed in a cluster of server computers located in a co-location facility.

According to one aspect of the invention, the controller (named "BMonitor") is a computer (eg, each node located at a co-location facility).
Has been placed. BMonitor includes multiple filters that determine where data can be sent to and from, such as another node in a co-location facility or a client computer coupled to the computer via the Internet. It has become. These filters can be changed by one or more management devices coupled to the computer during operation of the computer.

According to another aspect, a controller (located on a computer) named "BMonitor" comprises:
Manages the software components that exist on the computer. When a request is received by BMonitor from an external source, the request is executed by BMonitor. The request can be made from a management console co-located with the computer or from a management console co-located with the computer.

According to another aspect, a controller named "BMonitor" (located on a computer)
Is acting as a trusted third party that mediates interactions between multiple managed devices. BMonitor maintains multiple ownership domains, each of which is associated with a managed device, and each domain instructs BMonitor to perform which type of management function. They have their own set of rights that show what they can do. Only one ownership domain is a top-level domain at any one time, and this top-level domain has a larger set of rights than lower-level domains. The top-level domain can create a new ownership domain that can be associated with other managed devices, and can delete the top-level domain and transfer the corresponding management device's management rights to the lower-level ownership domain. The corresponding management device allows it to be revoked at any time. Each time the ownership domain that changes to the top-level ownership domain changes, the computer's system memory can be erased, so sensitive information from one ownership domain is used by devices corresponding to other ownership domains. Is prevented.

[0014] According to another aspect, BMonitor is a software engine running on the node.
It runs at a higher privilege level than ngine), preventing other software engines from interfering with the limits set by BMonitor.

Hereinafter, the present invention will be described with reference to the accompanying drawings, but the present invention is not limited to the following description. Also, similar components and / or functions are denoted by the same reference numerals throughout the drawings.

[0016]

Embodiments of the present invention will be described below in detail with reference to the drawings. In the drawings, portions having the same functions are denoted by the same reference numerals, and overlapping description will be omitted.

FIG. 1 is a diagram illustrating a client / server network system and environment, such as may be used in some embodiments of the present invention. In general, the system
One or more (n) client computers 1
021-102n, each of which is a cluster of a plurality of server computers (server cluster) 1061-1, 1061
One or more (m) co-location facilities 1041-1 including -2, 106m-1, 106m-2
04m, one or more management devices 110, 1
And one or more separate (eg, not included in a co-location facility) server 112. These servers, client computers, and management devices are in communication with each other through a data communication network 108. The communication network of FIG. 1 includes a public network 108, such as the Internet. In addition to or as an alternative to the Internet, other types of communication networks may be used, including local area networks (local
area network LAN), wide area network (wide areanet
work WAN). The construction of the data communication network 108 can be accomplished in a variety of ways, including wired and / or wireless communication media.

A wide range of communication protocols can be used to perform communication using the network 108. In one implementation, the client computer 1021
〜１０102n and clusters 1061-2, 106m-1, 1
The server computer in 06m-2 is a Hypertext Transfer Protocol HTT
P) to communicate with each other, where web pages are hosted by server computers and are written in a markup language such as HTML (Hypertext Markup Language) or XML (eXtensible Markup Language). has been written.

The management device 110 serves to manage software components of one or more computing devices located at a location remote from the device 110. This management can include limiting data transfer to and from the managed computing device. In the example illustrated in FIG. 1, the management device 110 includes clients 1021 to 102n, a server cluster 1061-
1, 1061-2, 106m-1, 106m-2 or one or more of the servers 112 can be remotely managed. There is a wide range of computing devices that can be managed remotely, including personal computers.
PCs, network PCs, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, gaming consoles, Internet devices, personal digital assistants (pe
rsonal digital assistant PDA), pocket computer, palm-sized computer, handheld computer, digital cellular phone (digital
cellular phone). Remote management of a computing device is accomplished by communicating commands to the device over a network 108, as described in more detail below.

In the following description, embodiments of the present invention are described in the general sense of computer-executable instructions, such as program modules, being executed by one or more conventional personal computers. Generally, program modules include routines, programs, objects, components, or components that perform particular tasks or implement particular abstract data types.
The data structure is included. Further, as will be appreciated by those skilled in the art, various embodiments of the present invention may be implemented with other computer system configurations, including handheld devices, gaming consoles, and Internet devices. Appliance
(Internet appliances), multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, etc. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

Alternatively, embodiments of the present invention may be implemented in hardware or a combination of hardware, software, and / or firmware. For example, the present invention may incorporate, in whole or in part, one or more application-specific integrated circuits (appl).
Communication specific integrated circuit ASIC) or programmable logic device (programmable logic dev)
ice PLD).

FIG. 2 is a schematic diagram illustrating an example of a computer 142 that may be used in accordance with some embodiments of the present invention. As an example of the computer 142 shown, a computer having functions as the client computers 1021 to 102n in FIG. 1, a computer or node located in the co-location facility 1041 to 104m in FIG. There is a node 248) of FIG. 5 described, or a local or remote management console, which are described in detail below.

Computer 142 includes one or more processors or processing units 144, a system memory 146, and a bus 148 that couples various system components including the system memory 146 to the processor 144. Bus 148 represents any one or more of several types of bus structures, including a memory bus or memory controller employing any of a variety of bus architectures, and peripherals. Includes a bus, a high-speed graphics port, and a processor or local bus. Read-only memory (read only memory)
memory ROM) 150 and random access memory (rando
m access memory RAM) 152. The basic input / output system BIOS 154 is
It is comprised of basic routines that assist in transferring information between elements within computer 142, such as during startup, and is stored in ROM 150.

The computer 142 further reads and writes data from and to a hard disk (not shown) and a hard disk drive interface 157 (for example, SCSI,
Bus 14 via ATA, other types of interfaces)
8 for reading and writing between the hard disk drive 156 and the removable magnetic disk 160 connected to
The magnetic disk drive 15 connected to the bus 148 via the magnetic disk drive interface 161
8, and CD-ROM, DVD and other optical media,
Read and write with the removable optical disk 164,
An optical disk drive 162 connected to a bus 148 via an optical drive interface 165 is provided. These drives and their associated computer-readable media store, as non-volatile storage, computer readable instructions, data structures, program modules, and other data for computer 142. Although the example environment described herein employs a hard disk, removable magnetic disk 160 and removable optical disk 164, data accessible by a computer may be stored as will be appreciated by those skilled in the art. Other types of computer readable media that can be used in the exemplary operating environment may be used, such as magnetic cassettes, flash memory cards, digital video disks, random access memory (RAM), read only Memory (ROM), etc.

Some program modules include a hard disk, a magnetic disk 160, an optical disk 164,
It can be stored in ROM 150 or RAM 152, including operating system 170
a, 170b, one or more application programs 172a, 172b, other program modules 174a, 174b, and program data 176
a and 176b. The user has keyboard 1
Commands and information can be entered into the computer 142 through input devices, such as 78 and pointing device 180. Other input devices (not shown) include a microphone, joystick, game pad, satellite dish, scanner, and the like. These and other input devices are connected to the processing unit 144 via an interface 168 that is coupled to the system bus.
It is connected to the. A monitor 184 and other types of display devices are also connected to the system bus 148 via an interface, such as a video adapter 186. In addition to monitors, personal computers include other peripherals, such as speakers and printers.
Typically, an output device (not shown) is provided.

Computer 142 is optionally operating in a networking environment using logical connections with one or more remote computers, such as remote computer 188. Remote computer 188 can be another personal computer,
Server, router, network PC, peer device (peer
device) or other common network node, FIG.
Although only zeros are shown, they typically include many or all of the elements described above in connection with computer 142. The logical connections shown in FIG. 2 include a local area network (LAN) 192 and a wide area network (WAN) 194. Such networking environments include offices, enterprise-wide computer networks, intranets,
And is popular on the Internet. In the embodiment of the invention described here, the remote computer 18
8 is Microsoft Corporation (Redmond, Washington
Internet Explorer "manufactured and sold in
Runs an Internet Web browser program, such as a Web browser, which may optionally be built into the operating system.

When used in a LAN networking environment, computer 142 is connected to local network 192 through a network interface or adapter 196. When used in a WAN networking environment, computer 142 typically includes a modem 198 and other components for establishing communication over a wide area network 194, such as the Internet. The modem 198 has a built-in type and an external type, and both are connected to the system bus 148 via an interface (for example, a serial port interface 168). In a networking environment,
The program modules described above in connection with personal computer 142, or portions thereof, may be stored in a remote memory storage device. As can be appreciated, the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

Generally, the data processors of computer 142 are programmed with instructions stored at different times in the various computer-readable media of the computer. Programs and operating systems may include, for example, floppy disks or
It is typically distributed on a CD-ROM. These are installed from there or loaded into a secondary memory of the computer. At runtime, they are at least partially loaded into the computer's primary electronic memory. According to the invention described herein, the instructions or programs for implementing the steps described below in connection with a microprocessor or other data processor are described above and in other types of computer-readable storage media. It is stored in. Further, according to the present invention, the computer itself is programmed according to the method and method described later.
Further, certain sub-components of the computer are programmable to perform the functions and steps described below. According to the invention, such sub-components are to be programmed as described below. Further, in accordance with the invention described herein, the data structures are embodied on various types of memory media, as described below.

For convenience of explanation, other executable program components, such as programs and operating systems, are shown here as individual blocks, but it will be understood that such programs and components Are located in different storage components of the computer at different times and are executed by the data processor of the computer.

FIG. 3 is a detailed block diagram illustrating an exemplary co-location facility. Joint location facility 104
Represents a plurality of nodes 210-1 to 210-n
(Also called a server computer). The co-location facility 104 can accommodate any number of nodes, and can easily accommodate thousands of nodes.

The nodes are grouped into several clusters called server clusters (or node clusters). For simplicity of explanation and to avoid confusion in the drawing, only one cluster 212 is shown in FIG. Each server cluster is a co-location facility 1
04 includes nodes corresponding to specific customers. A node of one server cluster is physically isolated from a node of another server cluster. This physical isolation
Different configurations are possible, such as locked individual cages or individual rooms at the co-location facility 104. Physically isolating the server cluster ensures that only the co-location facility 104 customers have physical access to their nodes (other customers cannot). Alternatively, the server clusters may be logically isolated from each other, rather than physically, (eg, using cluster boundaries described in more detail below).

Land Road / Tenant Relationship (Lender / Lender
(also called a (lessor / lessee) relationship) can be set on a node basis. The owner (and / or operator) of the co-location facility 104 may:
Because it owns (or otherwise has its rights) the individual node, it can be viewed as a “land road”. The co-location facility 104 customer can be viewed as a "tenant" because it leases nodes from Land Road. Landloading is generally indifferent to what type of data or programs are stored on nodes by tenants, but demarcates clusters so that nodes from different clusters communicate with each other I try to prevent it. This is described in more detail below. In addition, the use of nodes provides tenants with the assurance that landlords cannot access sensitive information stored by tenants, even if the nodes are leased only to tenants.

Nodes of different clusters, even if physically isolated, can access network connection (s) 216 and, in some cases, access application operation management console 242, with the same transformer. Often it is physically coupled to the port medium (s) 211. This is described in more detail below. This transport medium can be wired or wireless.

Each node has a shared transport medium 21
1 so that each node can be configured to limit which other nodes can send and receive data. If it is possible for several different nodes to be included in the tenant's server cluster, the tenant wants to be able to pass data between different clusters within that cluster for purposes such as processing and storage. There are cases. However, tenants generally do not want data to be passed to other nodes that do not belong to the server cluster. By configuring each node in the cluster to limit which data can be sent to or received from any other node, you can set the boundaries of the server cluster,
It becomes possible to apply. When such a server cluster boundary is set and applied, it is prevented that tenant data is erroneously or illegally transferred to a node that does not belong to the cluster.

These initial boundaries, set by the land load, prevent communication between nodes of different customers, thus ensuring that each customer's data is passed to other nodes of that customer. . If the customer himself defines sub-boundaries within the cluster separately and sets up sub-clusters of nodes, data coming in and out of them is prevented from being passed to and from other nodes in the cluster. The customer is free to add, modify, delete, etc., such sub-cluster boundaries, but only within the boundaries defined by the land load (ie, the cluster boundaries). Is limited to Thus, the customer cannot change the boundaries in such a way that the communication made with a node extends to another node that does not belong to the same cluster.

The co-location facility 104 includes a trusted power source 214 and a trusted network connection (s) 216 (eg, network 108 of FIG. 1) for each of node nodes 210-1 through 210-n. ). The power supply 214 and the network connection 216 are connected to the node nodes 210-1 to 210-.
n, but alternatively, another power supply 214 and network connection 216 may be provided to node nodes 210-1 to 210-n or a group of nodes (eg, a cluster). A wide range of conventional mechanisms for providing reliable power supplies, all in combination with backup generators, redundant generators, batteries, fuel cells, or other storage mechanisms in the event of a power failure (outage) It can be used to provide a reliable power supply 214, such as power supplied by a company. Similarly, a wide range of conventional mechanisms for providing reliable network connections include redundant connection transport media, heterogeneous connection media, different access points (eg, different Internet access points, different Internet service providers ( Inte
rnet service provider (ISP), etc.).

In some embodiments, node 2
10-1 to 210-n are co-location facilities 104
Is leased or sold to customers along with the space and services of facility 104 (eg, trusted power source 214 and network connection 216). In another embodiment, the facility 10
Four spaces and services are leased to the customer, while one or more nodes are provided by the customer.

Each of the nodes 210-1 to 210-n is managed in a multilayer system. FIG. 4 is a block diagram illustrating an exemplary multi-tier management architecture. This multi-layer architecture consists of three layers. That is, the cluster operation management layer 230, the application operation management layer 232, and the application development layer 2
34. The cluster operation management layer 230
It is implemented locally at the same location (e.g., at a co-location facility) as the managed server (s)-and is responsible for managing the hardware operation of the server. In the illustrated example, the cluster operation management layer 230 determines which software components are node nodes 210-1 to 210-n.
Irrespective of whether it is running on a node cluster, it is only relevant to continue the hardware operation of node nodes 210-1 to 210-n and to set boundaries between node clusters.

In contrast, the application operation management layer 232 is located at a remote location (eg, separate from the co-location facility) where the managed server is located and is coupled to the server. Implemented at the location of the client computer that is still in communication. The application operation management layer 232 is responsible for managing server software operations and defining sub-boundaries within a server cluster. Clients can be coupled to the server in a variety of ways, such as via the Internet or a dedicated (eg, dial-up) connection. Also, the client may remain attached to the server or may be attached on an irregular basis (eg, only when needed for administrative purposes).

The application development layer 234 is implemented on another client computer located at a different location from the server (for example, a different location from the co-location facility), and is implemented by software executed on the server. Responsible for developing components or engines. Alternatively, node nodes 210-1 to 210- of co-location facility 104
It is also possible to develop additional software components and engines for the nodes by accessing the current software located at n. The client in which the application development layer 234 is implemented is generally a different client from the client in which the application operation management layer 232 is implemented. However, these two layers 232 and 234 are not It is also possible (at least partially) to implement.

Although only three layers are shown in FIG. 4, alternatively, a multi-layer architecture can be composed of a different number of layers. For example, splitting the application operations management layer into two layers, with each layer having different (or overlapping) responsibilities, would result in a four-tier architecture. Management at these tiers can be from the same location (eg, sharing a single application management console) or from different locations (eg, two different operations management consoles).

Returning to FIG. 3, co-location facility 104 includes a cluster operations management console for each server cluster. In the example of FIG. 3, the cluster operation management console 240 is associated with the cluster 212. The cluster operations management console 240 implements the cluster operations management layer 230 (FIG. 4) for the cluster 212 and is responsible for managing the hardware operations of the nodes in the cluster 212. The cluster operations management console 240 monitors the hardware in the cluster 212 and attempts to determine a hardware failure. It is possible to monitor any wide range of hardware faults, including processor faults, bus faults, memory faults, etc. The method of monitoring the hardware operation may be such that the cluster operation management console 240 sends a test message or control signal to the node requesting the use of specific hardware to respond (no response or an erroneous response indicates a failure). Has occurred, indicating that a test message or control signal requesting the use of specific hardware has been generated and periodically transmitted from the node to the cluster operations management console 240 (within a specific time period). Various methods are possible, such as not receiving a message or control signal indicating that a fault has occurred). Alternatively, rather than trying to determine what type of hardware failure has occurred, the cluster operations management console 240 may determine only that a failure has occurred.

When a hardware failure is detected, the cluster operations management console 240 acts to correct the failure. The actions taken by the cluster operations management console 240 may vary depending on the type of fault, as well as the hardware, and may differ for different server clusters. Corrective actions include notifying the administrator (eg, flashing lights, audio alarms, e-mail messages, cell phone or pager calls,
And trying to physically correct the problem (eg, rebooting the node, booting another backup node instead of the failed node, etc.).

Cluster operation management console 2
40 also sets cluster boundaries within the co-location facility 104. The cluster boundary set by the console 240 is a certain cluster (for example, the cluster 212).
Prevent the node 210-3 within the cluster from communicating with another cluster (e.g., a cluster that does not belong to the cluster 212).
0-3 should not interfere with the ability to communicate with other nodes in the cluster. These boundaries allow tenants to know that their data cannot be transmitted to other tenant nodes located at facility 104, even if network connection 216 is shared by tenants. Thus, security of tenant data can be obtained.

In the illustrated example, the co-location facility 10
Each cluster 4 includes a dedicated cluster operations management console. As another method, a single cluster operation management console can be associated with a plurality of server clusters to manage its hardware operation. According to another alternative, multiple cluster operations management consoles may be associated with a single server cluster to manage its hardware operations. Such a plurality of consoles can manage a single server cluster in a shared manner, or one console can operate as a backup for another console (for example,
With redundancy, reliability is improved and maintenance is facilitated.)

An application operations management console 242 is also coupled to the co-location facility 104 and is in communication. The application operations management console 242 is located at a location remote from the co-location facility 104 (ie, typically at the customer's office rather than within the co-location facility 104). A different application operations management console 242 for each server cluster of the co-location facility 104
Alternatively, a plurality of consoles 242 may be associated with a single server cluster, or a single console 24 may be associated with a plurality of server clusters.
2 can also be associated. The application operation management console 242 is connected to the cluster 212
Operation management layer 232 for
(FIG. 4), which not only manages software operations in the cluster 212 but also
12 is also responsible for securing sub-boundaries.

The application operation management console 242 monitors software in the cluster 212 and attempts to determine a software failure. A wide range of software faults can be monitored, for example, software faults such as "hanged" or unresponsive application processes or threads, runtime errors in application processes or threads, and the like. The method of monitoring the software operation can be various (similar to the monitoring of the hardware operation described above), for example, a test message in which the application operation management console 242 requests the use of a specific routine to respond. Or send a control signal to a specific process or thread running on the node (no response or wrong response indicates failure). Alternatively, a message or control signal requesting the use of a specific software routine is generated, and a process or thread running on the node is periodically transmitted to the application operation management console 242 (such a message or control signal is specified). If not received within a period of time, it indicates that a failure has occurred). Alternatively, rather than attempting to determine what type of software failure has occurred, the application operations management console 242 may determine only that a failure has occurred.

When a software fault is detected, the application operations management console 242 operates to correct the fault. The actions taken by the application operations management console 242 may differ not only by software, but also by the type of failure, and may differ for different server clusters. Corrective actions include notifying the administrator (eg, flashing lights, audio alarms, e-mail messages, cell phone or pager calls, etc.), attempting to correct the problem (eg, rebooting the node, software Reload the component or engine image,
And then re-execute after terminating the process).

Accordingly, the management of the nodes 210-1 to 210-n is distributed to a plurality of managers regardless of the number of other nodes (if any) located at the same location as the node. With this multi-tiered management, hardware operations management is separated from application operations management, so that administrative responsibility for a node can be divided between two different consoles, each under the control of a different entity. become.

FIG. 5 is a detailed block diagram illustrating an exemplary node managed remotely according to some embodiments of the present invention. Node 248 may be a node 210-1 to 210-n of a co-location facility, or may be a separate device (e.g., clients 102-1 to 102-1 of FIG. 1).
2-n or server 112).
Node 248 includes a monitor 250 called "BMonitor",
And a plurality of software components or engines 252 and is coupled to the mass storage device 262 (which may incorporate the mass storage device). In the depicted example, node 248 is a computing device with one or more processors that support multiple privilege levels (eg, rings in x86 architecture processors). In the illustrated example, these privilege levels are called rings, but other implementations employing different processor architectures may use different terms. According to the plurality of rings, a set of prioritized levels is prepared, and software is executed at the priority level. The priority level is 4 levels (ring 0,
1, 2, 3). Ring 0 is typically called the most privileged ring. A software process executed on ring 0 typically has more accessible functions (eg, instructions) than a process executed on a less privileged ring. Further, a processor running on a particular ring cannot change the code or data on the higher priority ring. In the illustrated example, BMonitor 250 runs on ring 0, while engine 252 runs on ring 1 (or rings 2 and / or 3). Therefore, BM
The code or data of the onitor 250 (running on ring 0) cannot be changed directly by the engine 252 (running on ring 1). Rather, such a change is caused by the engine 252
0 by asking for a change (eg, BMonitor2
(For example, by sending a message to BMonitor 50 or calling a function of BMonitor 250).
When BMonitor250 is implemented in ring 0, BMonitor25
0 will be protected from uncontrolled or malicious engines 252 trying to bypass the restrictions imposed by BMonitor 250.

[0051] Alternatively, BMonitor 250 sends BM from uncontrolled or malicious engine 252 to BM.
Other ways of protecting the onitor 250 can be implemented. For example, node 248 has one engine 2
Processor to execute 52, another is BMonitor
Multiple processors may be included, such as a processor to execute 250. BMonit on a different processor than the processor on which the engine 252 is running
If you run only or250, BMonitor25
0 can be effectively shielded from the engine 252.

BMonitor 250 is a basic control module of node 248. That is, it controls both the network interface card and the memory manager (optionally built-in). Network interface card (this is BM
Onitor 250 may be different, BMonit
or monitor may be built into the network interface card).
Can control data sent to and received from the node 248. When controlling the memory manager, BMonit
or250 is engine 2 running on node 248
Control over memory allocation to the BMonitor2
It can be prevented from interfering with the 50 operations.

The various aspects of node 248 are
0 (eg, a network interface card).
Makes at least some of its functions available to the engine 252 running on the node 248. The BMonitor 250 sends the data to another node 248 or the Internet,
2 is an interface from which access to functions can be requested (e.g., through a controller 254 described in detail below). These requests can take various forms, such as sending a message, calling a function, and so on.

BMonitor 250 includes a controller 254,
Network interface 256, one or more filters 258, one or more keys 259, and BM
onitor250 control protocol (BMonitor Control Proto
col BMCP) module 260 is included. The network interface 256 is an interface connecting the node 248 and a network (for example, the network 108 in FIG. 1). Any other nodes (and / or other sources) located at the co-location facility
Or a target (eg, the Internet 10 of FIG. 1).
8) is determined by a filter 258. To determine these nodes or other sources / targets, the network address (eg, Internet Protocol I
P) address), some kind of globally unique identifier (ID), and locally unique identifier (eg, owned by the co-location facility 104 or a unique numbering scheme). is there.

The filter 258 can completely restrict access to the node (for example, cannot transmit / receive data to / from the node), or can partially restrict access to the node. Partial access restrictions can take various forms. For example, a node can be restricted such that data can be received from the node but not transmitted to the node (or vice versa). As another example, certain types of data (eg, HTTP
Communications that conform to certain protocols).
Nodes can also be restricted to transmit and / or receive from nodes. There are many ways to implement filtering based on a particular type of data, such as putting the data in a packet and conveying the data along with header information that indicates the type of data contained in the packet. .

Filter 258 can be added by one or more management devices 110 of FIG. 1 or by either application operations management console 242 or cluster operations management console 240 of FIG. In the example shown, the filter added by the cluster operations management console 240 (to set the cluster boundaries) restricts full access to a node (eg, all access to another node is restricted). Are prohibited), filters added by the application operations management console 242 (to set sub-boundaries within the cluster) or by the management device 110 limit either full or partial access to the node. It has become possible.

The controller 254 also imposes some restrictions on which filters can be added to the filter 258. In the multi-tier management architecture shown in FIGS. 3 and 4, the controller 254 allows the cluster operations management console 240 to add any required filters (this defines the boundaries of the cluster). On the other hand, the controller 254 restricts the application operation management console 242 to adding only the filters whose degree of restriction is the same as the filter added by the console 240. Console 242 is console 2
If an attempt is made to add a less restrictive filter than the one added by 40 (in which case the sub-boundary will cross the cluster boundary), the controller 25
4 refuses to add the filter (alternatively, it is possible to modify the filter so that the limit is not reduced). With these restrictions,
The controller 254 can prevent a sub-boundary set at the application operation management level from exceeding a cluster boundary set at the cluster operation management level.

Controller 254 operates to limit data packets transmitted from and / or received by node 248 using one or more filters 258. A certain engine 2
Any data destined for 52 or sent from the engine 252 to another node is passed through the network interface 256 and the filter 258. The controller 254 applies a filter 258 to the data and determines the target of the data (e.g., typically specified in the header portion of the packet containing the data) as the allowed (specified in the filter 258). And / or restricted) nodes (and / or network addresses). If the filter 258 indicates that the target of the data is allowed, the controller 254 allows the data to be passed to the target (either fed into or out of node 248). On the other hand, filter 258 indicates that the data target is not acceptable.
Indicates, the controller 254 prohibits data from being passed to the target. Controller 254
May return a notification to the source of the data that the data cannot be passed to the target, or it may simply ignore or discard the data.

The filter 25 is controlled by the controller 254.
Applying 8 to the data makes it possible to place restrictions on the boundaries of the server cluster (FIG. 3). Filter 258
Can be programmed using the node addresses of all nodes in the server cluster (e.g., cluster 212) (e.g., by application operations management console 242 of FIG. 3). In this way, the controller 254 prevents data received from nodes that do not belong to the server cluster from being passed to the engine 252, and similarly, data that is sent to a node other than the nodes in the server cluster. To be sent. Similarly, because data received from the Internet 108 (FIG. 1) can identify the target node 248 (eg, by an IP address), the controller 254 of a node other than the target node can pass data to the engine 252. Will be prevented. In addition, because the filter 258 can be easily modified by the cluster operations management console 240, the server cluster boundaries can be easily changed to accept changes in the server cluster (e.g., changing a node to a server cluster). Adding and / or removing nodes from a server cluster).

[0060] The BMCP module 260 is a distributed host control protocol (DHCP).
Implements BMonitor 250 (and thus node 248) to obtain an IP address from a DHCP server (eg, cluster operations management console 240 of FIG. 3). During the initialization process of node 248, BMCP module 260 communicates with a DHCP server.
Requests an IP address, and in response to this request, the DHCP server
Give the IP address to module 260. More information about DHCP can be found at Microsoft Corporation (Redmond, Washin
gton).

The software engine 252 includes any of a wide variety of conventional software components. Examples of engine 252 include an operating system (eg, Windows NT), a load balancing server component (eg, to balance the processing load of multiple nodes 248), a caching server component (eg, a separate Caches data and / or instructions from node 248 or received over the Internet),
A storage manager component (e.g., to manage storage of data received from another node 248 or via the Internet). In some implementations, since each of the engines 252 is a protocol-based engine, the engine 252 and the BMonitor2
Even if 50 is not written in the same programming language,
BMonito through messages and / or function calls
Communicate with r250 and other engines 252.

The controller 254 is used together with the loader 264 to control the execution of the engine 252. This control can take various forms, such as starting or activating the engine 252, ending the execution of the engine 252, reloading the image of the engine 252 from the storage device, debugging the execution of the engine 252, and the like. . Controller 254 receives instructions from application operation management console 242 of FIG. 3 as to which of these control actions to take and when to take those control actions.
When activating the execution of engine 252 (including restarting the engine whose execution was recently aborted), controller 254 communicates with loader 264 to
The engine 252 image is loaded from a storage device (eg, device 262, ROM, etc.) into the memory (eg, RAM) of node 248. The loader 264 operates in a conventional manner, copying the image of the engine from the storage device to memory and initializing the required operating system parameters so that the engine 252 is running. Therefore, engine 2
The control of 52 is actually managed by a remote device rather than locally at the same location as the managed node 248.

The controller 254 is connected to the application operation management console 242 of FIG.
Which filters to add (and / or remove) from the filter set 258
Is also an interface that can be specified from there.

The controller 254 also has an interface through which the cluster operations management console 240 of FIG. 3 can pass commands to the controller 254. Various types, such as rebooting the node, shutting down the node, putting the node into a low power state (eg, suspend or standby state), changing the cluster boundary, changing the encryption key (if any), etc. Can be transmitted from the cluster operation management console 240 to the controller 254.

The controller 254 further includes a BMonitor
250, which provides encryption support (this is optional) so that data can be
62 (eg, a magnetic disk, optical disk, etc.) and the node 248 and an operations management console (eg, console 240 or 242 of FIG. 3) or other management device (eg, the management device of FIG. 1). 110) can be performed securely. The controller 254 stores a plurality of encryption keys, including a symmetric key (symm
Used to encrypt and / or decrypt data, such as etric keys) (private key used in private key encryption), public / private key pairs (for public key encryption purposes), etc. It is possible to include a variety of different keys that are

BMonitor 250 uses a public key encryption method (publ
ic key cryptography) and the nodes 248 and management consoles (eg, consoles 240 and 24 of FIG. 3).
2) Or secure communication is performed between management devices (for example, the management device 110 in FIG. 1). This public key encryption method uses a key pair that contains both a public key and a private key.
And an encryption algorithm. The encryption algorithm encrypts the data based on the public key so that without the private key, the data cannot be efficiently decrypted. Accordingly, since communication from the public key holder is encrypted using the public key, only the private key owner can decrypt the communication.
The public key encryption method is a well-known RSA (Rivest, Shamir, Ade
lman) Various methods are available, such as encryption methods. Bruce Schnei as a basic introduction to cryptography
r, “Applied Cryptography: Prot.
ocols, Algorithms, and Source Code in C), John W.
iley & Sons, first edition copyright 1994 (or second edition copyright 1996).

BMonitor 250 is used for land road and tenant
Initialized to include public / private key pairs for both
Have been. These key pairs are
Can be generated, but alternatively, other components
It can be generated and stored in BMonitor 250
(In this case, other components can destroy the key pair information.
Not trusted). In this specification, U
Indicates the public key and R is used to indicate the private key.
You. The public / private key pair for Landlord is (U_L, R _L) When
Public / private key pair for the tenant is (U_T, R_T) When
Called. BMonitor 250 uses public key U_LAnd U_TThe Landlo
The private key R_LAnd R_T Is
I keep it secret. In the illustrated example, BMonitor 250 is
Secret key R_LAnd R_TLand Road
Not only did tenants encrypt using public keys
Information (eg, each of the cluster operations of FIG. 3)
Management console 240 and application operations
(Through the application management console 242)
Not decrypted by any other entity other than 0
Is guaranteed.

[0068] When the public to land load key U _L and U _T is given, the landlord node to a specific tenant 210-1
Assign a to 210-n, it is possible to provide the public key U _T to the tenant. Use of the public key U _T, the tenant is only BMonitor 250 can decrypt (using the private key R _T), it is possible to encrypt communications to BMonitor 250. Although not necessary, a prudent initial step for the tenant is for BMonitor 250 to request BMonitor 250 to generate a new public / private key pair (U _T , R _T ). In response to this request, the key generator (ke
y generator) (not shown), to generate a new public / private key pairs in any of a variety of well-known method, stores the new key pair as a tenant key pair, send back the new public key U _T to the tenant. After generating a new key pair, the tenant
Including the land load, to any other entity, public key U _T of the tenant is guaranteed to go unnoticed. In addition, tenants can generate new key pairs at different times.

If BMonitor 250 stores the private key and there is a public / private key pair for informing the tenant of the public key, it becomes possible to transmit information from the tenant to BMonitor 250 securely. To ensure that information is passed securely from BMonitor 250 to the tenant, another public / private key pair is generated by the tenant and the public key portion is passed to BMonitor 250. Therefore, BMonit
Any communication from or250 to the tenant can be encrypted using this public key portion and can be decrypted only by the holder of the corresponding private key (ie, only by the tenant).

BMonitor 250 also maintains the disk key as one of keys 259, which is generated using one or more symmetric keys (where the symmetric key
(Symmetric keys are the secret keys used in secret key encryption.) The disk key, which is also a symmetric key, is used by BMonitor 250 to store information on mass storage device 262. BMonitor250
Keeps the disk key secure, which means that the node encrypts the data stored in the mass storage device 262 and that the node
It is only used to decrypt the data retrieved from 62 (so that the disk key does not need to be known to any other entity, including landlords and tenants).

The use of a disk key ensures that data stored in mass storage device 262 can be decrypted only by node 248 that encrypted it, and not by any other node or device. Thus, for example, if the mass storage device 262 has been removed and an attempt is made to read data on the device 262, the attempt will fail. The BMonitor 250 encrypts data stored in the mass storage device 262 using a disk key, regardless of the source of the data. For example, as data sources, client devices used by tenant customers (for example, clients 1021 to 102n in FIG. 1), management devices (for example, device 110 in FIG. 1 or console 24 in FIG. 3)
0 or 242).

In one implementation, a disk key is generated by combining storage keys corresponding to each management device. There are various ways to combine storage keys, some implementations use one of the keys to encrypt the other key and encrypt the resulting value with the other key of the key. Are combined in this way.

Further, the BMonitor 250
Acts as a trusted third party that mediates interactions between multiple, distrusted management agents that are responsible for managing the third party. For example, the land load and tenant of node 248 typically do not completely trust each other. Therefore, BMonitor2
50 acts as a trusted third party, and BMonitor2 is operated by a specific entity or agent.
Node 248 states that the information made available to 50 is accessible only to that entity or agent and not to other entities or agents.
The lessor and the lessee in the trust (eg, confidential information given by the lender cannot be accessed by the borrower, and vice versa). BMonit
or250 is a hierarchical ownership domain (ownership
A set of domain DO) is used to facilitate this trust. The ownership domain is the basic unit of authentication and rights in BMonitor 250, and each management entity or agent (eg, lender and borrower) is associated with a separate ownership domain (note that each management entity has multiple If you have a management device, you can exercise your management responsibilities from there.)

FIG. 6 is a block diagram illustrating an exemplary set of ownership domains according to some embodiments of the present invention. A plurality (x) of ownership domains 280, 282, and 284 are organized as an ownership domain stack 286. Each ownership domain 280-284 is associated with a particular management level and one or more management devices (eg, device 110 of FIG. 1, console 2 of FIG. 3).
40 and 242). The base or root ownership domain 280 corresponds to the actual owner of the node, such as the landlord described above. The next sub-ownership domain 282 corresponds to the entity that leases the hardware from the hardware owner (eg, the tenant described above). A managed device in a particular owner domain is designated for another managed device higher on the ownership domain stack 286,
You can set up another ownership domain.
For example, the entity whose nodes are leased may set up another ownership domain for another entity (eg, to set up a node cluster implementing a database cluster).

When a new ownership domain is created, the ownership domain is pushed to the top of the ownership domain stack 286. It remains a top-level ownership domain until you create another new ownership domain or its rights are revoked.
Ownership domain rights are transferred to the ownership domain stack 28
6, can be revoked by a device in any lower-level ownership domain, and upon revocation, that ownership domain is removed from stack 286 along with any other higher-level ownership domains. Popped (removed). For example, if the owner of node 248 (ownership domain 280) revokes the rights in ownership domain 282, ownership domain 28
2 and 284 will be popped from the ownership domain stack 286.

Each proprietary domain has a corresponding set of rights. In the illustrated example, the top-level ownership domain has one set of rights, which includes the following rights. That is, (1) the right to push the new ownership domain onto the ownership domain stack, (2) the right to access any system memory in the node, or (3) within the node or coupled to the node. (4) the right to modify (add, remove, or change) the packet filters placed on the node; and (5) the software engine (eg, engine 25 in FIG. 5) on the node.
2) right to start execution, (6) right to stop running software engine on the node, including resetting the node, (7) right to debug software engine on the node, (8) itself Authentication credentials (authen
tication credential) (eg, its public key or ID)
(9) the right to modify its own storage key, (10) engine events, machine events, and / or
Or the right to subscribe to events such as packet filter events (e.g., notifying a management console or other device when one of these events occurs). In addition, each of the lower level ownership domains has a different set of rights, including the following rights: That is, (1) the right to pop existing ownership domains, (2) the right to modify (add, delete, or change) packet filters placed on nodes, and (3) their own authentication credentials (eg, public (4) the right to subscribe to machine events and / or packet filter events. Alternatively, some of the above rights may be removed from the set (eg, in some situations, the right to debug the software engine on the node may not be necessary), and other rights may be included in the set. (E.g., the top-level node can include the right to pop itself off the ownership domain stack).

[0077] Ownership domains can be added to and removed from the ownership domain stack any number of times during operation. Which ownership domains are removed and / or added depends on the activity being performed. As one example,
If the owner of node 248 (corresponding to root ownership domain 280) wants to perform some operation on node 248, all higher-level ownership domains 282-284 are revoked and the desired operation is (The extended rights set becomes available as ownership domain 280 becomes the top-level domain) and a new ownership domain can be created and added to ownership domain stack 286 (eg, previously Will be returned to its previous location.)

Each time a BMonitor 250 receives a request from an entity corresponding to one of the ownership domains (eg, a management console controlled by that entity), it checks which rights the ownership domain has. If the ownership domain has the required rights to fulfill the request, BMonitor 250
Performs the request. However, if the ownership domain does not have the required rights set, the request is not performed (eg, a notification that the request cannot be performed can be returned to the requestor or the request can simply be ignored).

In the illustrated example, each ownership domain is an identifier.
(ID), public key, and storage key. The identifier is used as a unique identifier of the ownership domain, the public key is used to send secure communication to the management device corresponding to the ownership domain, and the storage key is stored on the mass storage device. Used (at least in part) to encrypt information. By including an additional private key for each ownership domain, the management device corresponding to the ownership domain will:
It is possible to send secure communication to BMonitor. When a root ownership domain 280 is created, it is initialized with its ID and public key (eg, by BMonitor 250). The root ownership domain 280 can be initialized to include the storage key (and the private key) or can be added later (eg, generated by BMonitor 250 or from the management console). Etc.). Similarly, each time a new ownership domain is created, the ownership domain that creates the new ownership domain will send the ID and public key to the new ownership domain's BMonitor 250
To communicate. The storage key (and private key) can be created for the new ownership domain either at the time of creation of the ownership domain or later.

The BMonitor 250 authenticates the management device corresponding to each of the ownership domains. Until the managed device is authenticated, BMonitor will not accept any commands from that managed device and can authenticate confidential information (encryption key) in a particular ownership domain as if it corresponded to that ownership domain Publish only to managed devices. This authentication process can be performed any number of times during the operation of the node, so that the management device of one or more ownership domains will change over time. Various methods are possible for authenticating the management device. In one implementation, the management device
Requesting a connection with BMonitor 250 and claiming that it corresponds to a specific ownership domain, BM
onitor 250 generates a token (eg, a random number), encrypts the token with the public key of the ownership domain,
Send the encryption token to the requesting management device.
Upon receiving the cryptographic token, the management device decrypts the token using its private key and replaces the decrypted token.
Return to BMonitor 250. The returned token is BMonitor2
A match with the token generated by 50 confirms the authenticity of the management device (since only the management device with the corresponding private key can decrypt the token). Using a similar process, BMonitor25
0 can authenticate itself to the management device.

Once authenticated, the management device makes a request to BMon
It can communicate to itor 250 and cause any of its requests to be performed, provided that it has the right to do so. Although not necessary, it is wise for the management console that for the first time
When authenticating against a public key, the public / private key pair must be changed.

When a new ownership domain is created,
The management device that creates the new ownership domain can optionally terminate the existing engine 252 and erase system memory and mass storage devices. In this way, the security level is enhanced in addition to encryption, thereby preventing one management device from accessing information stored on hardware by another management device. . In addition, each time the ownership domain is popped off the stack, BMonitor 250 will use the existing engine 252
And erase the system memory, and also erase the storage key of its ownership domain. Thus, information stored by that ownership domain is not accessed by the remaining ownership domains. That is, since the memory has been erased, the data is not in the memory and the information on the mass storage device cannot be decrypted without the storage key. Alternatively, BMonitor2
50 is also capable of erasing mass storage devices. However, if the key is erased and the data remains encrypted, BMonitor 250 can recover the data when the popped ownership domain is recreated (using the same storage key). become.

FIG. 7 is a flow diagram illustrating the overall operation of BMonitor 250 according to some embodiments of the present invention. Initially, BMonitor 250 monitors incoming input (block 290). Sources to which these inputs are sent include another node 248, a client computer (FIG. 3) via a network connection 216, a client operation management console 240, an application operation management console 242, an engine 252, and a management device 1.
10 (FIG. 1).

If the received request is a control request (eg, from one of the consoles 240 or 242 in FIG. 3 or from the management device in FIG. 1), the requesting device has the necessary rights for the request. Is checked (based on top-level ownership domain)
(Block 292). If the requesting device does not have the required rights, BMonitor 250 returns to monitoring inputs (block 290) without performing the request.
However, if the requesting device has the necessary rights,
The request is performed (block 294) and BMonitor 250 continues to monitor the received input (block 290). However, if the received request is a data request (eg, inbound from a client computer via another node 248 or network connection 216, outbound from engine 252, etc.), BMonitor 250 will accept or otherwise reject the request. (Block 296) and continues monitoring the incoming input (block 290). BMonitor25
Whether 0 accepts the request depends on the filter 258 (FIG. 5), as described above.

FIG. 8 is a flowchart illustrating an exemplary process when processing an outbound data request according to some embodiments of the present invention. The process of FIG.
It is implemented in the BMonitor 250 of FIG. 5 and can be executed by software. The process of FIG.
The following is a description in relation to the components shown in FIGS.

First, an outbound data request is received (step 300). Controller 254 places the request in an outbound request constraint (request restri
ctions) (step 302). This comparison is
Information corresponding to the data (eg, information in the header of the packet containing the data or information inherent in the data.
For example, accessing information such as how the data request was passed to BMonitor 250 (e.g., which of the multiple function calls was used) and comparing it to outbound request constraints maintained by filter 258. It is performed by By making this comparison, BMonitor 250
A determination may be made as to whether outbound data requests are allowed to be passed to the target (step 30).
4). For example, if the filter 258 indicates to which target the data cannot be sent, the outbound data request is allowed to pass to the target only when the target identifier (ID) is not specified in the filter 258.

If the outbound data request is allowed to pass to the target, BMonitor 250 sends the request to the target (step 306). For example, BM
The onitor 250 can send a request to the target via the transport medium 211 (which may go through the network connection 216) or to the network 108 via another connection. However, if it is not allowed to pass outbound data requests to the target, BMonitor 250
Rejects the request (step 308). BMonitor250
Will optionally notify you that your request has been denied,
It can be sent to the source of the request or just drop the request.

FIG. 9 is a flowchart illustrating an exemplary process when processing an inbound data request according to some embodiments of the present invention. The process of FIG.
Of the BMonitor 250, and can be executed by software. The process of FIG. 9 will be described below in relation to the components shown in FIG.

First, an inbound data request is received (step 310). Controller 254 compares the request to inbound request constraints (step 312). This comparison is made by accessing information corresponding to the data and comparing it with the inbound request constraints maintained by the filter 258. When this comparison is made, BMonitor 250
Can be determined to be allowed to receive the data request (step 314). For example, filter 2 from which sources can receive data
58 indicates that the engine 252 is allowed to receive the data request if the source of the data is the filter 25
8 only.

If the BMonitor 250 is authorized to receive the inbound data request, it forwards the request to the target engine 252 (step 316).
However, if an inbound data request is not allowed to be received from the source, BMonitor 250 rejects the request (step 318). The BMonitor 250 can optionally send a notification that the request has been rejected to the source of the request or simply drop the request.

Conclusions Although the description above uses terms specific to structural features and / or method steps, it should be understood that the invention as defined in the claims is intended to It is not limited to the specific features or steps that have been performed. Rather, the specific features and steps have been disclosed as example forms of implementing the invention.

[0092]

As described above, according to the present invention, a computer system is managed by restricting data transfer and managing software components in a cluster of server computers located in a co-location facility. Can be performed efficiently.

[Brief description of the drawings]

FIG. 1 illustrates a client / server network system and environment, such as may be used in some embodiments of the present invention.

FIG. 2 is a schematic diagram illustrating an example of a computer that can be used in accordance with some embodiments of the present invention.

FIG. 3 is a detailed block diagram illustrating an exemplary co-location facility.

FIG. 4 is a block diagram illustrating an exemplary multi-tier management architecture.

FIG. 5 is a detailed block diagram illustrating an exemplary node according to some embodiments of the invention.

FIG. 6 is a block diagram illustrating an exemplary set of ownership domains according to some embodiments of the present invention.

FIG. 7 is a flow diagram illustrating the overall operation of BMonitor according to some embodiments of the present invention.

FIG. 8 is a flowchart illustrating an exemplary process for processing an outbound data request according to some embodiments of the present invention.

FIG. 9 is a flowchart illustrating an exemplary process for processing an inbound data request according to some embodiments of the present invention.

[Explanation of symbols]

1021 to 102n Client 1041 to 104m Co-location facility 1061-1, 1061-2, 106m-1, 106m
-1 server cluster 108 Internet 110 management device 112 server 210-1 to 210-n node 230 cluster operation management layer 232 application operation management layer 234 application development layer 240 cluster operation management console 242 application operation management console 248 node 250 BMonitor 252 engine 256 Network interface 258 Filter 259 Key 260 BMCP module 262 Mass storage device 264 Loader 280, 282, 284 Ownership domain 286 Ownership domain stack

 ──────────────────────────────────────────────────の Continuation of front page (72) Inventor Galicy. Hunt United States of America 98008 Bellevue, Washington 162 Avenue Southeast 2967 (72) Inventor Armor Hydley United States 98033 Kirkland Northeast, Washington 107 Preyce 12511 (72) Inventor Stephen P. Levi United States 98052 Redmond, Washington Northeast 41 Street 16612 (72) Inventor David S.E. Stouts United States 98053 Redmond, Washington Northeast 116 19610 (72) Inventor Robert Buoy. Welland USA 98122 Seattle, WA 38 Avenue 1100 F-term (reference) 5B085 AC03 AE00 AE29 BG07 5B098 AA10 GA01 GC16 GD01 GD21

Claims (52)

[Claims] 1. One or more computer readable media having stored thereon a computer program, said computer program being executed by one or more processors of a node located at a co-location facility. One or more processors, in response to the received command, initiating and terminating the execution of the component on the node; and Between nodes
One or more computer-readable media for performing an operation comprising limiting whether data can be transmitted and received. 2. The one or more computer-readable media of claim 1, wherein a plurality of management devices share management responsibilities for the node, and start and end execution of components on the node. Is
One or more computer-readable media characterized by being restricted to only one of the plurality of management devices at any one time. 3. The one or more computer-readable media of claim 1, wherein the limiting step comprises: checking whether the received data is allowed to be transferred to the intended target. Transferring the received data to the intended target only when permitted to do so. 4. The one or more computer-readable media of claim 3, wherein the target of interest comprises another node located at a co-location facility. Computer readable media. 5. The one or more computer-readable media of claim 3, wherein the target of interest comprises at least one of the components running on the node. One or more computer readable media. 6. The one or more computer-readable media of claim 1, wherein the steps of starting and ending execution of the component are received from an operations console located at a location remote from the co-location facility. One or more computer-readable media comprising starting and ending execution of a component based on a command. 7. The one or more computer-readable media of claim 1, wherein one of the components comprises an operating system. 8. A system comprising a plurality of node clusters, each node cluster including a plurality of nodes, each individual node determining from which other node the individual node can receive data, and an individual node. A controller having constraints on which other nodes can send data. 9. The system according to claim 8, wherein each individual node further includes a plurality of filters for determining what kind of constraint condition is. 10. The system according to claim 8, wherein
A system wherein the constraint condition prohibits an individual node from transmitting and receiving data between the individual node and another node that does not belong to the same node cluster. 11. The system according to claim 8, wherein
The system wherein each individual node includes a network interface adapter including a controller. 12. The system according to claim 8, wherein
For each of the plurality of nodes, a plurality of management devices share management responsibilities for the node, one of the plurality of management devices being given an extended set of management rights for the node, and the remaining management devices for the node. A system wherein a more restricted set of administrative rights is granted. 13. The system according to claim 8, wherein
A system wherein the controller in each node is further adapted to terminate and start execution of an application on the node in response to a request from an external management device. 14. The system according to claim 8, wherein
The system wherein the plurality of node clusters are included in a co-location facility. 15. A method comprising: receiving a first request from a first control console located at a location within a co-location facility at a node located at a co-location facility; performing the first request. Receiving at a node a second request from a second control console located at a location remote from the co-location facility; and performing the second request. Features method. 16. The method of claim 15, wherein the first request comprises a hardware operation centric command. 17. The method of claim 15, wherein the second request comprises a software application control centric command. 18. The method of claim 15, wherein the first request corresponds to one of a first set of rights granted to a first control console, and wherein the second request Is
A method corresponding to one of a second set of rights granted to a second control console, wherein the first set of rights is more restricted than the second set of rights. . 19. One or more computer readable memories comprising a computer program executable by a processor for performing the method of claim 15. 20. A computer program storing a computer program.
One or more computer-readable media, wherein the computer program, when executed by one or more processors of a node located at the facility,
Setting, on one or more processors, a boundary of a server cluster located in the facility, the server cluster including a node, and a server cluster boundary being defined by a console located outside the server cluster. One or more computer-readable media for performing an operation comprising: modifying based on a received command. 21. The one or more computer-readable media of claim 20, wherein the setting step restricts access to another node located at the facility but not belonging to a server cluster. One or more computer-readable media comprising incorporating a filter. 22. The one or more computer-readable media of claim 20, wherein the step of setting comprises a plurality of filters identifying only other nodes included in the server cluster as being granted access. One or more computer-readable media comprising generating 23. The one or more computer-readable media of claim 20, wherein the computer program further comprises, upon execution, executing a software engine in response to a command received from a console. One or more computer-readable media, which causes one or more processors to execute. 24. The one or more computer-readable media of claim 20, wherein the computer program further comprises, upon execution, terminating execution of the software engine in response to a command received from the console. One or more computer-readable media for causing one or more processors to perform the performed operations. 25. The one or more computer-readable media as recited in claim 20, wherein the facility comprises a co-location facility. 26. An interface for permitting a management device corresponding to a plurality of management agents in charge of management of the system to access the system, and connecting each of the plurality of management agents to a separate one of a plurality of ownership domains. And a controller acting as a trusted third party to mediate interaction between the plurality of management agents by assigning rights to each ownership domain in the system. 27. The system of claim 26, wherein the controller is further responsive to a request from a management device corresponding to one of the plurality of management agents.
A system for terminating execution of a software engine in the system. 28. The system according to claim 26, wherein the controller is further responsive to a request from a management device corresponding to one of the plurality of management agents.
A system adapted to initiate execution of a software engine in the system. 29. The system of claim 26, wherein one of the plurality of ownership domains is a top-level ownership domain having a first set of rights and another ownership in the plurality of ownership domains. The system characterized in that each of the domains includes having a second set of rights. 30. The system of claim 29, wherein the second set of rights is more restrictive than the first set of rights. 31. The system of claim 29, wherein the first set of rights comprises: a right to create a new ownership domain; a right to access system memory; and a right to access mass storage devices of the system. Own the right to make changes to the filters in the system, to start running the software engine in the system, to stop running the software engine in the system, and to debug the software engine in the system. Includes the right to change authentication credentials for the rights domain, the right to make changes to the storage keys in the ownership domain, and the right to subscribe to events on the system, such as engine events, machine events, and packet filter events. Features system. 32. The system of claim 29, wherein the second set of rights includes a right to revoke an existing ownership domain, a right to make changes to filters in the system, and an authentication credential for the ownership domain. A system comprising: a right to change; and a right to subscribe to machine events and packet filter events in the system. 33. The system of claim 29, wherein the first set of rights comprises: a right to create a new ownership domain; a right to access system memory; and a right to access mass storage devices of the system. , And the right to make changes to the filters in the system. 34. The system of claim 29, wherein the second set of rights includes a right to revoke an existing ownership domain and a right to make a change to a filter in the system, wherein the right to make a change to the filter is , A right to add a filter that is not broken by a management agent assigned to the top-level ownership domain. 35. The system according to claim 29, wherein the controller has one of the other ownership domains.
A system, wherein a corresponding device allows revoking the top-level ownership domain, and the controller erases system memory during the revocation process. 36. The system of claim 26, wherein only one of the plurality of management agents can correspond to a top-level ownership domain at a time, and none of the other management agents has a top-level ownership. A system characterized in that a domain can be revoked. 37. The system of claim 26, wherein only one of a plurality of management agents can correspond to a top-level ownership domain at a time.
A system wherein one management agent can create a new ownership domain for a new management agent, and the new ownership domain becomes a new top-level ownership domain. 38. The system of claim 26, wherein only one of the plurality of management agents can correspond to a top-level ownership domain at a time, and which of the plurality of management agents The mapping to the top-level ownership domain can change over time, and the controller will change each of the multiple management agents to correspond to the top-level ownership domain, A system for erasing system memory. 39. The system of claim 26, wherein the system comprises a node located at a co-location facility. 40. Associating each of the plurality of management agents with one of the plurality of ownership domains, wherein each of the plurality of management agents is responsible for managing at least a portion of the computer and is external to the computer. And assigning a more restricted rights set to the remaining managed devices, wherein only one of the plurality of management agents is allowed to have an extended rights set on the computer at a time. And limiting which requests from the management device corresponding to the plurality of management agents are performed, at least in part, based on the rights of the management agent. 41. The method of claim 40, wherein each of the plurality of management agents is associated with one or more management devices coupled to the computer. 42. The method of claim 40, wherein the extended set of rights comprises a right to create a new ownership domain, a right to access system memory, and a right to access mass storage devices of the system. Own the right to make changes to the filters in the system, to start running the software engine in the system, to stop running the software engine in the system, and to debug the software engine in the system. Includes the right to change authentication credentials for the rights domain, the right to make changes to the storage keys in the ownership domain, and the right to subscribe to events on the system, such as engine events, machine events, and packet filter events. Features method. 43. The method of claim 40, wherein the more restricted set of rights includes a right to revoke an existing ownership domain, a right to modify a filter in the system, and an authentication credential for the ownership domain. And the right to subscribe to machine events and packet filter events in the system. 44. The method of claim 40, wherein the extended set of rights comprises a right to create a new ownership domain, a right to access system memory, and a right to access mass storage devices of the system. The right to make changes to the filters in the system. 45. The method of claim 40, wherein the more restricted set of rights includes a right to revoke an existing ownership domain and a right to make a change to a filter in the system, the right to make a change to the filter. Wherein the method includes the right to add a filter that is not broken by a management agent assigned to the top-level ownership domain. 46. The method according to claim 40, wherein 1
One management agent corresponds to the top-level ownership domain, and all other management agents
A method characterized in that the rights of one management agent can be revoked. 47. The method of claim 40, wherein assigning the extended rights set to a new management agent by one management agent having the extended rights set; and further restricting the one management agent. Assigning the assigned set of rights. 48. The method of claim 40, wherein allowing which of the plurality of management agents has the extended rights set to change over time; and which of the plurality of management agents Erasing system memory each time it is changed whether it has extended rights. 49. The method of claim 40, comprising terminating execution of the software engine on the computer in response to a request from a management device corresponding to one management agent having an extended rights set. , Further comprising: 50. The method of claim 40, wherein initiating execution of the software engine on the computer in response to a request from a management device corresponding to one management agent having an extended rights set. , Further comprising: 51. The method of claim 40, wherein the computer comprises a node located at a co-location facility. 52. One or more computer-readable media comprising a computer program executable by a processor for performing the method of claim 40.