Defining Capacity Limits

As with any system, OpsMgr includes limits that should be taken into account before deployment begins. Surpassing these limits might be cause for the creation of new management groups and should subsequently be included in a design plan. These limits are as follows:

• Operations Database—OpsMgr operates through a principle of centralized, rather than distributed, collection of data. All event logs, performance counters, and alerts are sent to a single centralized database, and there can subsequently be only a single operations database per management group. Considering the use of a backup and high-availability strategy for the OpsMgr database is, therefore, highly recommended to protect it from outage. It is recommended to keep this database with a 50 GB limit to improve efficiency and reduce alert latency.

• Management servers—OpsMgr does not have a hard-coded limit of management servers per management group. However, it is recommended to keep the environment between three to five management servers. Each management server can support approximately 2,000 managed agents.

• Gateway servers—OpsMgr does not have a hard-coded limit of gateway servers per management group. However, it is recommended to deploy a gateway server for every 200 nontrusted domain members.

• Agents—Each management server can theoretically support up to 2,000 monitored agents. In most configurations, however, it is wise to limit the number of agents per management server, although the levels can be scaled upward with more robust hardware, if necessary.

• Administrative Consoles—OpsMgr does not limit the number of instances of the Web and Operations Console; however, going beyond the suggested limit might introduce performance and scalability problems.