Abstract: A new management node associated with a new rack sends at least a public key of the new management node to a first management node associated with a first rack and a plurality of autonomous management nodes. The first management node sends the new management node an access token trusted by at least a portion of the plurality of autonomous management nodes and a set of public keys corresponding to at least a portion of the plurality of autonomous management nodes. The new management node can send its public key and the access token to at least a portion of the plurality of autonomous management nodes. In response, the new management node can establish a mutual trust relationship with at least a portion of the plurality of autonomous management nodes.

Abstract: A construct having a plurality of distributed resources can include a portion of a second rack having a plurality of computing devices controlled by a second management node. The second management node can determine it contains insufficient construct data such as user data, group data, resource data, or authorization policy data to execute an operation associated with the construct. The second management node can synchronize at least a portion of construct data with a first management node. The first management node can be associated with the construct and a mutual trust relationship can exist between the first management node and the second management node. The first management node and the second management node can comprise autonomous management nodes capable of functioning independent of the network.

Abstract: A new management node associated with a new rack sends at least a public key of the new management node to a first management node associated with a first rack and a plurality of autonomous management nodes. The first management node sends the new management node an access token trusted by at least a portion of the plurality of autonomous management nodes and a set of public keys corresponding to at least a portion of the plurality of autonomous management nodes. The new management node can send its public key and the access token to at least a portion of the plurality of autonomous management nodes. In response, the new management node can establish a mutual trust relationship with at least a portion of the plurality of autonomous management nodes.

Abstract: A new management node associated with a new rack sends at least a public key of the new management node to a first management node associated with a first rack and a plurality of autonomous management nodes. The first management node sends the new management node an access token trusted by at least a portion of the plurality of autonomous management nodes and a set of public keys corresponding to at least a portion of the plurality of autonomous management nodes. The new management node can send its public key and the access token to at least a portion of the plurality of autonomous management nodes. In response, the new management node can establish a mutual trust relationship with at least a portion of the plurality of autonomous management nodes.

Abstract: A first management node of a first rack can be registered to a shared file storage system by establishing a mutual trust relationship between the first management node and the shared file storage system. The first management node can access a plurality of respective public keys and a plurality of respective certificates of authority that are stored in the shared file storage system and associated with a plurality of respective registered management nodes. The first management node can store a public key and a certificate of authority in the shared file storage system. The first management node can form mutual trust relationships with other registered management nodes. The first management node can validate authenticity of messages received from registered management nodes of the plurality of registered management nodes using a respective public key and a respective certificate of authority associated with a respective registered management node sending a message.

Abstract: A new management node associated with a new rack sends at least a public key of the new management node to a first management node associated with a first rack and a plurality of autonomous management nodes. The first management node sends the new management node an access token trusted by at least a portion of the plurality of autonomous management nodes and a set of public keys corresponding to at least a portion of the plurality of autonomous management nodes. The new management node can send its public key and the access token to at least a portion of the plurality of autonomous management nodes. In response, the new management node can establish a mutual trust relationship with at least a portion of the plurality of autonomous management nodes.

Abstract: A first management node of a first rack can be registered to a shared file storage system by establishing a mutual trust relationship between the first management node and the shared file storage system. The first management node can access a plurality of respective public keys and a plurality of respective certificates of authority that are stored in the shared file storage system and associated with a plurality of respective registered management nodes. The first management node can store a public key and a certificate of authority in the shared file storage system. The first management node can form mutual trust relationships with other registered management nodes. The first management node can validate authenticity of messages received from registered management nodes of the plurality of registered management nodes using a respective public key and a respective certificate of authority associated with a respective registered management node sending a message.

Abstract: A construct having a plurality of distributed resources can include a portion of a second rack having a plurality of computing devices controlled by a second management node. The second management node can determine it contains insufficient construct data such as user data, group data, resource data, or authorization policy data to execute an operation associated with the construct. The second management node can synchronize at least a portion of construct data with a first management node. The first management node can be associated with the construct and a mutual trust relationship can exist between the first management node and the second management node. The first management node and the second management node can comprise autonomous management nodes capable of functioning independent of the network.

Abstract: A cloud deployment appliance (or other platform-as-a-service (IPAS) infrastructure software) includes a mechanism to deploy a product as a “shared service” to the cloud, as well as to enable the product to establish a trust relationship between itself and the appliance or IPAS. The mechanism further enables multiple products deployed to the cloud to form trust relationships with each other (despite the fact that each deployment and each product typically, by the nature of the cloud deployment, are intended to be isolated from one another). In addition, once deployed and provisioned into the cloud, a shared service can become part of a single sign-on (SSO) domain automatically. SSO is facilitated using a token-based exchange. Once a product registers with a token service, it can participate in SSO. This approach enables enforcement of consistent access control policy across product boundaries, and without requiring a user to perform any configuration.

Abstract: A cloud deployment appliance (or other platform-as-a-service (IPAS) infrastructure software) includes a mechanism to deploy a product as a “shared service” to the cloud, as well as to enable the product to establish a trust relationship between itself and the appliance or IPAS. The mechanism further enables multiple products deployed to the cloud to form trust relationships with each other (despite the fact that each deployment and each product typically, by the nature of the cloud deployment, are intended to be isolated from one another). In addition, once deployed and provisioned into the cloud, a shared service can become part of a single sign-on (SSO) domain automatically. SSO is facilitated using a token-based exchange. Once a product registers with a token service, it can participate in SSO. This approach enables enforcement of consistent access control policy across product boundaries, and without requiring a user to perform any configuration.

Abstract: A cloud deployment appliance includes a mechanism to enable permitted users to move event records reliably from an internal event log of the appliance to a data store located external to the appliance while ensuring the integrity of event records. The mechanism ensures that the event records are not tampered with in storage or during download. Further, the approach ensures that no event records can be removed from the appliance internal storage before being successfully downloaded to the external data store.

Abstract: In a mechanism for supporting detection of a failure event, history information of a system including log information of the system including plural components and/or failure information output from each component upon occurrence of a failure in the system is collected. A detection rule for detecting an event included in a component related to the failure that has occurred is generated, and a symptom with additional information added to the generated detection rule is applied to detect the event that has caused the failure. System configuration information as configuration information of the system is acquired, and from the acquired system configuration information, partial configuration information as system configuration information related to the component that sent out the event the selection of which has been accepted is extracted. The extracted partial configuration information is added to the symptom to update the symptom.

Abstract: In a mechanism for supporting detection of a failure event, history information of a system including log information of the system including plural components and/or failure information output from each component upon occurrence of a failure in the system is collected. A detection rule for detecting an event included in a component related to the failure that has occurred is generated, and a symptom with additional information added to the generated detection rule is applied to detect the event that has caused the failure. System configuration information as configuration information of the system is acquired, and from the acquired system configuration information, partial configuration information as system configuration information related to the component that sent out the event the selection of which has been accepted is extracted. The extracted partial configuration information is added to the symptom to update the symptom.

Abstract: A cloud deployment appliance includes a mechanism to enable permitted users to move event records reliably from an internal event log of the appliance to a data store located external to the appliance while ensuring the integrity of event records. The mechanism ensures that the event records are not tampered with in storage or during download. Further, the approach ensures that no event records can be removed from the appliance internal storage before being successfully downloaded to the external data store.

Abstract: An apparatus for generating event detection rules in a multiple-component computer system in accordance with embodiments of the invention may include a configuration information-extracting section for acquiring system configuration information from a multiple-component computer system. The system configuration information may include related information that describes relationships among system components. The apparatus may further include a history information-collecting section for collecting history information from the multiple-component computer system, such as log information and/or failure information output from a component upon a system failure. A candidate event-identifying section may identify candidate events that may be selected by a user to generate a detection rule based on the system configuration information and the history information. Finally, a candidate event-presenting section may present the candidate events to a user for selection.

Abstract: In a mechanism for supporting detection of a failure event, history information of a system including log information of the system including plural components and/or failure information output from each component upon occurrence of a failure in the system is collected. A detection rule for detecting an event included in a component related to the failure that has occurred is generated, and a symptom with additional information added to the generated detection rule is applied to detect the event that has caused the failure. System configuration information as configuration information of the system is acquired, and from the acquired system configuration information, partial configuration information as system configuration information related to the component that sent out the event the selection of which has been accepted is extracted. The extracted partial configuration information is added to the symptom to update the symptom.

Abstract: An apparatus for generating event detection rules in a multiple-component computer system in accordance with embodiments of the invention may include a configuration information-extracting section for acquiring system configuration information from a multiple-component computer system. The system configuration information may include related information that describes relationships among system components. The apparatus may further include a history information-collecting section for collecting history information from the multiple-component computer system, such as log information and/or failure information output from a component upon a system failure. A candidate event-identifying section may identify candidate events that may be selected by a user to generate a detection rule based on the system configuration information and the history information. Finally, a candidate event-presenting section may present the candidate events to a user for selection.