Hardware capability for FIM Reporting

Question

I am doing some capacity planning for a FIM 2010 R2 deployment and trying to understand the hardware requirements for the Reporting feature. Based on the diagarm below, it looks like the performance is primarily driven by two factors: System
Center and SQL. Even the performance of System Center depends on SQL. So it all comes down to SQL horsepower. The rest of the servers (FIM, SCSM, SCDW) may not need much muscle power (I might be wrong though). What is your experience when planning
for Reporting? What kind of challenges one can experience? Btw, I have a userbase of 100K and the change rate (# of requests per day) I am expecting is about 6%. What kind of hardware capacity would you recommend?
Thanks!

Answer 1

To start with, the picture is indeed really great … but it’s missing (or not emphasizing enough) one important component – SCSM’s Service Manager database.
As for the capacity question, we've seen the biggest impact/load on the SCCM databases, both Service Manager and Data Warehouse (mainly DWStagingAndConfig) – so yes, SQL is what
drives all that. Also, we haven’t tried SP1 yet, so what we observed was still on SCCM 2010.
Anyway, here are few pointers from our experience:
1. SCSM Service Manager DBs and Data Warehouse DBs should be installed on different SQL instances (has to do with the nature of the DBs) and preferably on different SQL servers.
And ideally separately from other FIM component DBs.
2. SCSM Service Manager DB can easily grow over twice the size of your FIMService DB (with indexes taking a lot of space), and it’s transaction log can quickly reach crazy sizes
especially during initial load. This is the experience from running it just for few months, it might change after longer usage.
3. From SCSM Data Warehouse DBs the only one you need to worry about is the DWStagingAndConfig. In our environment size wise it was comparable to FIM Service DB, but the observed
IO during ETL jobs was just crazy – I’ve seen graphs of it generating 300-400MB/s read IO on a 150GB DB for over 10h straight (with plenty of RAM on the SQL box).
4. Overall it seems like latency to the DB files is one of the main factors driving performance of FIM Reporting (not to mention IO) – even to a point where SAN storage might
not be the best option here. Like Tomasz wrote, we were looking at setting up both SCSM components on two dedicated physical servers with local SQL and DBs on SSD drives … but didn’t get that far yet.
When I’m writing about FIM Reporting performance I’m referring to a number of individual changes (queued in the ExportLog table in the FIM Service DB) that can be extracted from
FIM Service to Service Manager in an hour – initially we were able to process below 200k records per hour, and after several tweaks, SAN reconfiguration, etc, we were almost able to double it. There isn’t any average correlation between number of requests
and number of entries in the ExportLog table, it all depends on type of changes and how many are a part of individual requests. To just to give you an idea, we observed 20M records that were added over a 7 day period (avg 120k per hour), during which the only
activity on FIM Service were approximately 20k SSPR registrations – highly customized (with confirmation emails flying around and some custom attributes being set), but still just SSPR. As you can imagine, with that level of activity we needed to push the
processing rate way over what we were seeing as FIM Reporting was barely being able to catch up in real time.
I hope this will be at least a bit helpful
J.
Piotr
P.S. Oh, and by "we" I mean my previous company, I recently moved to Microsoft.