I was mainly basing the 500 GB on that drives don't come much smaller these days. If I am not mistaken, a RAID 10 array of four 250 GB drives gives me about 500 GB of usable space. I would end up housing the content either on a separate server or on a separate drive on the same server.
Those of you who have virtualized SCCM, do you have a separate VM running SQL on the same host hardware or run it on the same VM? Should I split some of the SCCM server roles into separate VMs? I do plan on having Software Update Point on a separate server. Nick Gailfus Computer Technician p. 602.953.2933 f. 602.953.0831 [email protected] <[email protected]>| www.leonagroup.com On Thu, Oct 8, 2015 at 6:08 AM, Sherry Kissinger <[email protected]> wrote: > > "At least 500 GB for database on a RAID 10 array" > > I *think* what you mean is something like using that 500gb sort of like > this (note I'm not saying this is exactly what you'd do... just something > sort of like this -ish): > > 200GB on Partition 1 for D: drive for the <installed location> of CM, > where the inboxes will be. > 200GB on Partition 2 for the E: drive for the Database (mdf file) > 100gb on Partition 3 for the F: drive for tempdb and tx files. > > (and you'll still have a separate partition of 500gb or 1 TB or whatever, > depending upon how much you have in content that will be devoted to the > contentlib). This is ASSUMING that the actual source files for your > content are over on <ThisOtherServer>\WhereWeKeepContentSourceFiles. If > the source files for your content (images, packages, apps) will be on the > same server, then you might need another partition to house the source > files. > > fyi, on a primary w/ just about 100k clients, the actual db size here is > 377gb (our disks that hold mdf/ndf/log files are configured to grow to > about double that, jic). And I have a lot of custom inventory things > turned on. but we ARE truncating all the history tables daily, to keep db > size down, too. So the _HIST tables are cleared every night. > http://www.mnscug.org/blogs/sherry-kissinger/357-configmgr-2012-truncate-history-tables > > > > > > > On Thursday, October 8, 2015 7:32 AM, Jimmy Martin <[email protected]> > wrote: > > > I have ~20k clients and db size around 60gb and I have a LOT turned on in > inventory, primary=8 cores, 32gb ram, sql local, tuned to have 5 procs and > half the mem, all virtualized on hyperv. > > > Jimmy Martin > (901) 227-8209 > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Marcum, John > *Sent:* Thursday, October 08, 2015 7:15 AM > *To:* [email protected] > *Subject:* RE: [mssms] New SCCM 2012 R2 Primary Site Hardware Specs > > 500 GB for the database is a bit much. J > > *------------------------------* > * John Marcum* > MCITP, MCTS, MCSA > * Desktop Architect* > * Bradley Arant Boult Cummings LLP* > *------------------------------* > > [image: H_Logo] > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Jason Sandys > *Sent:* Wednesday, October 7, 2015 2:34 PM > *To:* [email protected] > *Subject:* RE: [mssms] New SCCM 2012 R2 Primary Site Hardware Specs > > Physical vs. Virtual = IO, IO, IO. Over-subscription of hardware is very > common in virtualization. If “they” can guarantee high IO levels (storage > and network primarily) and dedicated RAM, then it’s somewhat moot and > virtual will work fine and has the advantage of being hardware independent. > Using virtual though is sometimes more expensive for ConfigMgr because many > orgs only have high-speed disks available for their VMs. This is great for > many things, but the large amounts of space ConfigMgr uses for the content > library do not need to be on high-speed disks and thus it’s a waste of > money to use high-speed disks for this. > > J > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Gailfus, Nick > *Sent:* Wednesday, October 7, 2015 2:24 PM > *To:* [email protected] > *Subject:* [mssms] New SCCM 2012 R2 Primary Site Hardware Specs > > I have been tasked with migrating our two stand alone primary SCCM 2012 > sites into one site to manage the whole company. Right now our two IT > teams in different parts of the country built and operate our own SCCM. I > have pushed to merge into one primary for the whole company. What I am > inquiring on is the hardware. While looking at this page here > https://technet.microsoft.com/en-us/library/hh846235.aspx I have > considered a physical server, much like what we are currently running with > each addtional RAM. At our last count for our volume licensing we have > about 7500 clients and servers. I would like to build this site to handle > at least 10,000 for growth. The specs I proposed was > > - 8 cores > - 32 GB of RAM > - At least 500 GB for database on a RAID 10 array > - Addition RAID array for content. > > I planned on having SQL run on the server as well. My boss chimed back > asking why am I considering physical over virtual. We would have about 80 > distribution points as well under this primary. I did propose that the > software update point run on a separate server and that server can be a > VM. So my questions are. > > - Are these specs enough or too much? > - Would virtualizing work with 10,000 clients? > - Are there any good methods of calculating hardware needs? > > > Nick > > > ------------------------------ > > Confidentiality Notice: This e-mail is from a law firm and may be > protected by the attorney-client or work product privileges. If you have > received this message in error, please notify the sender by replying to > this e-mail and then delete it from your computer. > > This message and any files transmitted with it may contain legally > privileged, confidential, or proprietary information. If you are not the > intended recipient of this message, you are not permitted to use, copy, or > forward it, in whole or in part without the express consent of the sender. > Please notify the sender of the error by reply email, disregard the > foregoing messages, and delete it immediately. > > > P *Please consider the environment before printing this email...* > > > > > >
