Things to Consider When Planning your OpsMgr Design
The following are best practices in designing and planning your OpsMgr 2007 R2 rollout:
► Always create a design and plan when deploying Operations Manager, even if it is a simple one.
► Take future expansion and relevance of hardware into account when sizing servers for OpsMgr deployment.
► Keep the installation of OpsMgr on a separate server or set of separate dedicated member servers that do not run any other separate applications.
► Start with a single management group and add on additional management groups only if they are absolutely necessary.
► Deploy Operations Manager components on Windows 64-bit and SQL 64-bit for optimal performance.
► Use SQL Enterprise when combining components on the same server.
► Use SQL Enterprise when scaling up Operations Manager.
► Deploy ACS on separate servers if possible.
► Allocate adequate space for the databases depending on the length of time needed to store events and the number of managed systems.
► Leverage the reporting database to store and report on data over a long period.
► Always create disaster recovery processes to restore in the event of a failure.
► Deploy fault tolerance (that is, clusters) only when needed.
► Always keep the RMS component on a separate cluster.
► Size the disk subsystems to provide sufficient IOps to support the anticipated data flows.
► Use SANs where possible for the improved throughput.
► Configure OpsMgr to monitor itself.
This posting is 1 of a monthlong series of postings on the Microsoft System Center family of products. This is an excerpt from my book “System Center Enterprise Unleashed” with more postings on the System Center family of products up at http://www.networkworld.com/community/morimoto
