ConfigMan and MOM (Full Version)

All Forums >> [Management Products] >> System Center Products >> System Center Configuration Manager



Message

jbland -> ConfigMan and MOM (6/19/2008 10:33:44 AM)

I have asked the higher ups for a dedicated SQL server to run ConfigMan databases for two primary sites as part of my deployment of ConfigMan to the enterprise.

The higher ups now want to use this same box not only for my DBs, but MOM's DB and SolarWinds DB, and anything else they choose to dump on it.  I have asked that they keep MOM and SolarWinds off because of the resource hogs that they are. 

ConfigMan for two sites is a beast on its own.  My research says that MOM databases should not be on the same SQL server as ConfigMan DBs.  Can I have some feedback on this configuration and also, on just how robust would that SQL server need to be to support everything they want to put on it without bringing all those applications to a screeching halt

thanks



mreavis -> RE: ConfigMan and MOM (6/19/2008 10:44:12 AM)

Basically, I would put the SCOM database with SCOM, SCCM with SCCM. This minimizes the traffic for the servers to talk to the database. Even the your DBAs should be a little suspect of doing this. Basically, run some perf reports showing what your processor, disk and memory usage are now, and then explain that it would double if you add SQL traffic for either of these major apps. I do run minor DBs on my SCCM DB server, but they generate maybe 2-5% traffic.



jnelson993 -> RE: ConfigMan and MOM (6/19/2008 10:51:57 AM)

I would fight it like a sumunabeech!  OK, depending...how many clients are we talking?  How many machines managed by SCOM?

SCOM is very heavy even by itself, especially if you're doing the audit collection stuff.
SCCM is much more SQL intensive by itself now too (compared to SMS).

I guess if I were forced to have a dedicated SQL box to hold 2 SCCM primaries, SCOM and grandma's cookie recipes, I'd build it with a Dell 2950 (or equivalent) a 30 disk external disk array with a PercE SAS controller and configure the disks in a RAID 10 array for max throughput.  The disks I'd format with 64K allocation unit.  This will spread the SQL I/O across as many disks as possible.   Then I'd throw at least 32GB of RAM in the server (Server 2003 x64 or Server 2008 x64 with SQL 2005 or 2008 x64...the important part is x64 on Windows and SQL)

So, I'd say, fight it if you can, if not, let them know it's going to be 40-50K for a gynormous server to handle all of that.  (unless we're talking about 500 clients in SCCM and 10 machines managed with SCOM...then I'd say just deal with it cuz my laptop could almost handle that. :)



jbland -> RE: ConfigMan and MOM (6/19/2008 11:10:17 AM)

ok, we're small potatoes
1000 machines but growing, and also acquiring other small companies in the future
so, what would your answer be to that number (sorry i didn't provide it initially)




jnelson993 -> RE: ConfigMan and MOM (6/19/2008 11:16:24 AM)

Well, I'd still fight it if you can. 

But honestly, if your inventory and heartbeat intervals are at most daily (not hourly or something silly) then you'll probably be able to handle it just fine...I wouldn't want to but it would be fine.  The thing is you want to plan for growth and you don't want to have to ask someone's permission in case you have to reboot your SQL box.  Unless SCOM is also deployed to the same 1000 machines, that's going to require a fully dedicated server of it's own.



jbland -> RE: ConfigMan and MOM (6/19/2008 11:51:33 AM)

the plan is to deploy the unified client for ConfigMan/OpsMan to the 1000 machines so that SCOM can monitor them and SCCM can do what it does. 



gjones -> RE: ConfigMan and MOM (6/19/2008 12:06:28 PM)

You want to monitor 1000 PCs with OpsMgr???  If so then you will need one HUGE SQL Box!!!

Is ConfigMgr going to sit on it own box?



jbland -> RE: ConfigMan and MOM (6/19/2008 12:13:58 PM)

ok, sorry, i'm an idiot, we would put the unified client on 80 servers - we would not be monitoring PCs.  Configuration Manager would be on its own box, but would share a SQL server with MOM and all manner of whatnot



gjones -> RE: ConfigMan and MOM (6/19/2008 12:37:56 PM)

Trust me you are not an idiot, may you need more coffee. ( I know that I do) 

Personally I don't understand a company who want to move the SQL db to a share server for such a small # of PCs. It would not be until 15K or more PCs before I would recommend moving the db. Even then...

I question the cost vs the benefit of such a move.



jnelson993 -> RE: ConfigMan and MOM (6/19/2008 12:38:12 PM)

Good gravy!!!  SCOM absolutely MUST be separate.  SCCM will be fine though.

<edited>

Oh, I see.  Should have hit refresh...



jbland -> RE: ConfigMan and MOM (6/19/2008 12:52:04 PM)

thanks for your help, i'll consider everything before i wave the white flag in defeat



jbland -> RE: ConfigMan and MOM (6/19/2008 1:01:17 PM)

At MMS, a number of microsoft reps advised me against putting SQL2005 on the site servers, even in our small environment, so that's why I am scrounging for a separate dedicated SQL machine for my project.

My company would put the DBs on a share to keep from having to buy me my own SQL box to put both site DBs on it - more bang for the buck for them.  I want optimum performance and since the deployment has not occurred and I am in the "asking for equipment" phase, of course I will ask for the moon.

thanks for all your help and guidance



gjones -> RE: ConfigMan and MOM (6/19/2008 1:02:51 PM)


If you have to do this then insist that an Server Level Agreement SLA is setup and reviewed on a regular bases. If SLA levels are not met then ask for the SQL db to be moved.



jnelson993 -> RE: ConfigMan and MOM (6/19/2008 1:14:58 PM)

quote:

ORIGINAL: jbland

At MMS, a number of microsoft reps advised me against putting SQL2005 on the site servers, even in our small environment, so that's why I am scrounging for a separate dedicated SQL machine for my project.

My company would put the DBs on a share to keep from having to buy me my own SQL box to put both site DBs on it - more bang for the buck for them.  I want optimum performance and since the deployment has not occurred and I am in the "asking for equipment" phase, of course I will ask for the moon.

thanks for all your help and guidance


Ha!  I know many, many people who are going to flat out ignore that request, including us because it just adds one more level of failure and complexity.  I even know of people who manage SCCM within Microsoft who said they were going to try it with SQL on box after speaking to Brian Mason and I.  If you've got the RAM and the disks, you're going to be better off with SQL on box.  Especially when you go to upgrade to the next version of SCCM due out soon.  Makes that upgrade path much easier.  Don't let MS bully you into going SQL off box to gain a POSSIBLE few percent in performance on a server you're not going to max out anyway. 

Just my $0.02



Page: [1]

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
0.34375