Abstract: A system for managing a deployment of a software application is disclosed. The system includes a telemetry component that collects data values of state metrics associated with the deployment, an application model that represents the deployment, a repository of encoded knowledge describing known problems associated with the software application, and an analysis subsystem that programmatically maps logical combinations of features associated with the deployment to known problems. The application model includes a representation of physical and logical objects in a domain of the deployment, and configuration data about the objects. The analysis subsystem is adapted to query the application model for information about the deployment. The application model can implement a discovery process to construct itself by using an abstract model of a generalized deployment of the software application, the discovery process including obtaining information from the managed deployment.

Abstract: A system for monitoring and analyzing a deployment of a software application is disclosed. The system includes a monitoring component that collects streams of data values of time-variant state metrics associated with the deployment, and a feature detector that analyzes the streams to identify features known to be associated with potential problems. Detected features can include deviations of a signal from a normalcy band, a rising or descending trend in signal behavior, deviations from seasonal or cyclical normalcy bands, and the like.

Abstract: Computer-implemented systems and methods for managing a deployment of a software application are disclosed. A method includes identifying problems with the deployment, each problem having a severity rating. For each identified problem, one or more associated remedies are identified, each remedy having a severity rating based on the severity rating of the problem with which the remedy is associated. The method further includes ranking the remedies based on the remedies' severity ratings. The remedies can be executed in order of rank. Also disclosed are systems and methods of preventing simultaneous execution of certain types of remedies, either on the deployment in general or on a set of components of the deployment. Also disclosed are methods for logging the results of executed remedies and their effect on deployment health.

Abstract: Systems and methods for managing a deployment of a software application are disclosed. One system comprises a machine-readable repository of rules describing problems associated with the software application, a monitoring component that collects state metrics from the deployment, and a problem detector that programmatically uses the rules to map combinations of the collected state metrics to problems.

Abstract: Systems and methods for obtaining information about a deployment of a software application are disclosed. One system comprises a plurality of deployment servers running components of the software application deployment, a plurality of monitors associated with the deployment servers, and an analysis subsystem that generates requests for state metrics from the deployment, based on rules describing known problems with the software application. The analysis subsystem transmits each request for state metrics to a monitor associated with a deployment server that is associated with the request. The monitors are configured to receive the requests for state metrics from the analysis subsystem and collect the state metrics from one of the components of the software application deployment. The monitors, which can reside on the deployment servers or locally with respect to the analysis subsystem, can transmit the collected state metrics back to the analysis subsystem.

Abstract: A system for monitoring and analyzing the operation of a deployment of a software application is disclosed. The system includes a monitoring component, a repository that stores a plurality of rules, and an analysis engine. The monitoring component collects data values of each of a plurality of state metrics associated with the deployment of the software application. At least some of the rules in the repository map respective combinations of states associated with the state metrics to corresponding problems. The analysis engine programmatically detects instances of said problems, at least in-part, by using the rules to analyze the state metric data values collected by the monitoring component. The rules can also include remedies associated with the detected problems, and the system may include remedy selection and execution modules.

Abstract: A method of encoding knowledge is disclosed, which can be used to automatically detect problems in software application deployments. The method includes accessing a source of knowledge describing a problem known to occur in deployments of a particular software application, and which identifies a plurality of conditions associated with the problem. An encoded representation of the knowledge source is generated according to a predefined knowledge encoding methodology. The encoded representation is adapted to be applied automatically by a computer to analyze data representing a current state of a monitored deployment of the software application to detect whether the conditions and the problem exist therein.

Abstract: According to one embodiment, a storage system (400) may include a gateway service (402), metadata service (404) and storage service (406) that each provide different storage system functions. Each service (402, 404 and 406) may include a plurality of servers that are functionally de-coupled from one another. De-coupled servers may service requests without regard to the operation of other servers of the same service. Such a de-coupled arrangement can allow a storage system (400) to be scaled to meet increasing demands, as servers may be added to a system, on a service by service basis, without necessarily re-indexing stored information or reconfiguring multiple instances of a server application. Further, backup servers may be easily added to the system to enable fault tolerance. Servers of a particular service (402, 404 and 406) may be accessed according to a quality of service policy.

Abstract: According to one embodiment, a metadata management system (MDS) may include partitioned migratable metadata. Metadata may be stored in multiple metadata partitions (102-0 to 102-11). Each metadata partition may be assigned to a particular system resource (104-0 to 104-5). According to predetermined policies, such as metadata aging, metadata stored in one metadata partition may be migrated to a different metadata partition. A forwarding object can be placed in the old metadata partition to indicate the new location of the migrated metadata. Metadata partitions (102-0 to 102-11) may be reassigned to different resources, split and/or merged allowing a high degree of scalability, as well as flexibility in meeting storage system needs.

Abstract: According to one embodiment, a storage system (100) may include an interface component (106) having a number of gateway servers (114), a metadata service component (108) having a number of metadata servers (116), and a content service component (110) that includes a number of storage servers (118). Scalability may be improved by enabling servers to be added to each different component (106, 108 and 110) separately. Availability may be improved as software and/or hardware can be changed for host machine in a component (106, 108 and 110) while the remaining host machines of the component continue to function.

Abstract: According to one embodiment, a dynamic server directory (DSD) (300) may include a number of relational tables (302 to 314) having a number of entries. Entries of selected tables (304 to 306) may include information for a server in a distributed computing system. Such information may include a server identification, host machine identification, and server status information. Entries of another table (308) may include host route information. According to one embodiment, dynamic server directory agents (DSDAs), residing on the same machine as a client process, may cache tables of a DSD (300). For a given client request, a client may query a local DSDA to determine which server(s) may service the client request. The local DSDA may then return the route to one or more servers that are available to service the request. Server information in a DSD (300) may be changed in response to changes in server status. Such changes may then be forwarded to DSDAs.