To fully understand the best approach to a deployment, it is important to understand how the product uses resources and under what use conditions.
Ops Center provides such a wide range of potential use cases that it is difficult to provide an accurate and simple answer about how far a particular product deployment can scale.
Ops Center is designed around two key design models:
A distributed state machine. Maintains the information about all of the managed assets and what can be done to the assets under Enterprise Manager Ops Center's control. This state machine is incremented by discovering new assets, adding new services or metrics to the machine or creating new logical groups of assets. The state machine size is decreased by deleting assets. Each modification of a variable, for example a CPU utilization measure, causes a change in the state machine.
An asynchronous job dispatch system. All actions that are requested through the Ops Center console are dispatched asynchronously through the system. The job system has a throttle that prevents the overloading of the system and manages queues of pending jobs.
Enterprise Manager Ops Center's state machine is maintained in a combination of memory and database. As the managed environment of assets increase, so will the resource utilization (mostly in terms of memory required) of the system.
The diagram above shows a simple deployment of Enterprise Manager Ops Center. Each component of Enterprise Manager Ops Center manages part of the state machine. A basic Agent will add the asset information for the operating system being managed and insert all of the relevant metrics, data, and operations that are supported as part of a discovery action. This part of the state machine is then pushed up to the Proxy Controller, which manages the part of the state machine for all of the assets it is managing and ultimately up to the Enterprise Controller, which can see the entire state machine.
The state machine imparts the highest load on the managed systems during discovery actions. Every part of the system is involved, beginning with the initial location of the asset by way of network requests to the addition of the asset into the state machine, through to the propagation and automated correlation of the new asset in the Enterprise Controller.
Steady state operation of the state machine involves the changing of metrics on the assets themselves. For example, an operating system's asset will have metrics showing network I/O utilization; these are sampled periodically by the Agent from the operating system and updated into the state machine on the Agent. The Agent caches to the state machine, per policy updates, and then sends the updates up to the Proxy Controller. The Proxy Controller follows a similar process up to the Enterprise Controller. The network load in steady state is very low because only changes to metrics are sent and connection management caching is in place to reduce the SSL handshake overhead between the tiers.
The browser user interface reflects a view of the state machine. Assets and their relationships as they exist in the state machine are displayed in the navigation panels, details of the assets are displayed in the center panels and actions associated with the assets are displayed in the Action panel. The Enterprise Controller manages the translation of data from the state machine into a form the browser can display. Viewing different assets or asset groups can place a processing load on the Enterprise Controller. Each user performing these actions in parallel will increase the processing load on the Enterprise Controller. In addition, a small amount of memory is dedicated to each user session.
The job management system performs actions that are requested by the user. The job management system is completely asynchronous and active jobs are capped and queued to manage resource utilization by the entire Ops Center system.
Depending on the particular action, job actions can run on the agent, the Proxy Controller, or the Enterprise Controller, or a combination of all three. For example, an OS provisioning job is managed from the Proxy Controller that is managing the system that is the target of the action. The Proxy Controller will run the majority of the processes during such an action and will impart the majority of the CPU load that is used during such an action.
The Agent Controller on the hosting operating system executes the software patch install on the operating system. The agent performs all of the requests required to fulfill the required action and imparts a minor CPU load on the host through job completion.