Sizing the environment

While most areas of a System Center 2012 R2 Operations Manager environment can be scaled out later, there are several advantages to correctly sizing and implementing that design from the outset.

It will also certainly help mitigate the need to go back to the business and ask for more storage and compute resources further down the line.

Getting ready

This recipe will show you how make use of the SCOM Sizing Helper that can be downloaded from http://www.microsoft.com/en-us/download/details.aspx?id=29270.

This sizing helper should only be used as an indicative guide, as your final sizing and design will require further thought around your requirements, and this is discussed more at the end of the recipe.

How to do it...

The following steps will show you how to use the sizing calculator in order to gain an understanding of the hardware requirements for your environment:

1. Open Sizing Helper and enable editing and macro usage if prompted by your version of Excel. For this recipe, the screenshots show the Sizing Helper being used in Excel 2013.
2. Click the button under the 2. Standard Deployment heading:
   
3. Use the drop-down selectors to choose 500 Windows Computers, 100 Network Devices, and set the APM as Enabled and click Submit:
   
4. You will obtain a basic sizing output based on this scenario requiring 6 servers with 16 GB of memory and 4 cores each;
   • One Management Server to support the selected number of agents, plus one to add high availability
   • One Management Server to support the selected number of network devices, plus one to add high availability to create a resource pool dedicated to network monitoring
   • One SQL server for the operational database
   • One SQL server each for the data warehouse, SQL Reporting, and Web Console

     Tip

     The output will also calculate the disk space required for the SQL databases. What is important to note, however, is that as we choose to enable APM in this scenario, it defaults to calculating APM sizing for all of the 500 Windows computers that we chose.

     It is highly unlikely that you will monitor application performance across every server so adjust this accordingly.

   
5. For this recipe, adjust the number of APM-enabled computers down to 20 for both the DB Size and DW Size sections and notice the reduction in the disk space requirements:
   

How it works...

The Sizing Helper can be used to get a basic idea of the size of servers and disk space required for an environment of your size but must be used in conjunction with a more detailed plan of the infrastructure topology required for your environment.

For example, the preceding recipe includes no gateway servers, no resource pools dedicated to Unix or Linux monitoring, and no high availability across the SQL servers while also sharing the SQL server used for the data warehouse for the Web Console.

While there are no specific sizing fields to use to calculate for Unix or Linux, you can use the Network Devices fields as these will roughly calculate to the same values. It is worth exploring the other scenario tabs within the sizing calculator to see what other options you have and how they affect your sizing.

There's more...

While the sizing helper is useful and good as a quick reference guide, there are some things you need to consider.

Disk space requirements

One area you may have immediately zoomed in on is the disk space requirements for the SQL databases. While it is important to stress how critical it is to correctly size the databases and even more so to ensure there is enough free disk space always available for normal operation and maintenance tasks, the sizing helper can be a little on the generous side when calculating the requirements.

This is due to the complexity that would be involved in trying to model and account for every management pack you may wish to run, the rules and collections scoped for your devices, the overrides you may put in place, the distributed applications you may build, and so on.

We have seen some environments where the calculator has estimated 200 GB for the data warehouse, yet the environments haven't grown past 80 GB after a couple of years of full use.

However, this is not to say that you can simply ignore the recommendations, as your mileage may vary and the authors cannot stress just how important it is to ensure you have enough free disk space on the volumes used for your SQL databases.

Why maintain free space?

System Center 2012 R2 Operations Manager has its own set of internal SQL maintenance tasks for its SQL Databases. The main operational database, for example, has regular schedules to re-index and defragment the tables. This means there is a hard requirement to ensure there is always at least 40 percent free space within the database for these maintenance tasks to operate.

A contingency must also be in place for the possibility of an event storm. If a large influx of alerts were to occur within your environment, causing the database to dramatically grow in size in a short period of time, not having the free disk space to allow for this could potentially make your monitoring system go offline before you've had a chance to use it to identify the root cause.

Multiple management groups

Each management group can support up to 15,000 agents, so a single management group should be sufficient for most environments.

However, SCOM does allow for multiple management groups to be implemented within an environment, along with the ability for these separate management groups to share a single data warehouse.

Multiple management groups may need to be considered for a couple of reasons. The first is the fact that the number of supported agents, namely 15,000, reduces significantly in relation to the number of open console connections. For example, this number of supported agents is based on 25 open consoles. With 50 open consoles, this supported number drops to 6,000 agents.

Tip

This is not something to consider lightly. Implementations on this scale are likely to already have very large data warehouses and adding more management groups is just going to increase the size and performance strain further.

These are still relatively high numbers for supported agents when considering just server monitoring, but can be quickly reached when also monitoring workstation class devices and must therefore be taken into account.

Another reason would be political reasons where Role-based Access Control (RBAC) cannot cover scoping of the console or where highly rigorous change control processes are in place across different parts of the infrastructure, which would make the normal deployment of management packs, overrides, and changes more challenging.

In addition to being able to deploy multiple management groups so that they share a single data warehouse, you have the option of connecting the individual management groups together in a connected method. This allows you to view and interact with alerts and discovery data in a consolidated view from a single console while also being able to run tasks on the monitored devices from other management groups.

Connected groups are joined together in a peer-to-peer relationship with a top-level local group in the hierarchy that has data fed from the other management groups, while groups have no visibility of each other, thus maintaining separation.

This is ideal for test or pre-production scenarios where typically you don't need a shared data warehouse and for them to remain separate, but with easy access from the console.

See also

Detailed information for the recipes covered can be found here:

• Sizing Helper Download: http://www.microsoft.com/en-us/download/details.aspx?id=29270
• Kevin Holman's Blog: What SQL Maintenance Plans to use with SCOM? http://blogs.technet.com/b/kevinholman/archive/2008/04/12/what-sql-maintenance-should-i-perform-on-my-opsmgr-databases.aspx