Fresh Content on SharePointJoel.com SharePoint Ads
Subscribe in a reader
Got this question a couple of days ago in relation to the capacity planning tool and the self imposed limit of 2 TB which is NOT a SharePoint limit... Note the answer does not refer to size of database, it's talking about the total disk storage of all of the databases together on a single node.
Question: ... I’m looking for some information regarding the size of the corpus and the number (and sizing) of the servers – specifically SQL servers.
Beside the user profile and the overall actions estimated, are there any guidelines for the number of SQL boxes needed to “hold” a certain amount of MOSS storage?
I’m asking this, because for example, when I use the MOSS HP Sizing tool it recommends deploying a large number of SQL servers due to the large content planned to be stored in MOSS regardless how many users will access it …
Answer: No tool will be able to give you a decent answer because the inputs aren't going to be the traditional ones. The answer is it depends. I'd say it depends on your operational efficacy along with your SLAs. For example there are some massive 30 TB SQL servers out there that exist. Sure it's scaled up hardware with multiple processors and tons of RAM, but with a single SQL node. It really depends on your SLAs. If you're trying to do tape backup from SQL with even 3 TB of storage (which may sound small) it's going to take more than 12 hours to backup. It might realistically take you up to 24 hours. If you've got a backup process that's running all day and night you have bigger problems. How long is it going to take to restore. If it takes 24 hours to back it up, I'd suggest it takes twice to three times as long to restore it. So how can you support a 5 TB or larger environment? You can do multi threaded backups to Fiber Attached storage or use SQL logshipping, snapshots, differentials, or maybe DPM? What you need to really look at is how long does it take to backup, how long does it take to restore, what are your SLAs.
There are interesting things like number of users hence number of connections, and disk I/O and so on that affect how many SQL servers, but you'll be tough pressed to find someone to pin point the number of connections per GB of RAM since there are so many other factors.
At Microsoft, the operational efficiency of our SQL support team and the SharePoint team support SANs and DAS, with SQL Clusters, SQL Mirroring and SQL Logshipping with back up strategies supported by another team for DPM. It takes some ramp up for everyone, so you don't want to shoot for the moon the first go around. Having 2 TB in disk group for a single SQL node has been validated and is comfortable for the support team, so chewing off a 5 TB node is a bit of a stretch, but with new hardware standards, faster disks, and faster more efficient backup processes make it more of a possibility.
Without a SharePoint Engineer/Architect and/or SQL resources I wouldn't recommend people go beyond 400-500 GB because of the complexities associated with simply getting those databases online and implementing a decent backup strategy that can complete and be validated. Now there are some technicians who have skills don't get me wrong, but I do suggest that people know where they're going and not just expect the book to tell them the correct answer.
So the moral of the story, the amount of disk online coming out of a tool with an unknown number of users can't be correct since it can't determine the operational efficiency of your team. It also doesn't understand how good your SLAs (service level agreements) backup and DR strategies are.
PingBack from http://geeklectures.info/2008/01/02/how-many-sql-servers-for-my-x-tbs/
We found that MOSS scales to about 20 content databases at about 30 GB each on a 4 way 32 bit SQL 2000 box with lots of spindles, etc. After that you're out of luck. Of interest is that SP 2003 supported twice that on a single box. I see that MS has now added that to the guidance in the SP1 stuff. I think SQL 2005 will scale the same.
Bob your test sounds very arbitrary. Twenty 30GB databases? I know IT has more than 60 databases on their WSS Team farm, and at least that on their MOSS "SharePoint" farm with databases around 100GB. Maybe we can get more info from MS IT. I'd also be interested in hearing from Dell, HP, EMC, Hitachi, etc... on this topic.
I do totally agree with this post - No Deus Ex Machina here.
I've checked both of the sizing tools released (see below) with our CTO which is also a skilled DBA - the results are really incredible... No matter how many concurrent users you have, the tools will recommend 16GB of RAM servers + tons of disks. Besides, you need tons of storage because of the index, logs etc. The HP tool seems to be a bit more reliable, but yet - can't be trusted.
Bottom line - You do need a SharePoint/SQL architect to plan your architecture. And don't forget it's not only the SQL but also the Front-Ends, Index and Search servers, and of course high/low availability, RAID config and more.
Sizing tools (posted before):
* HP - Microsoft Office SharePoint Server Sizing and Configuration Tool" - http://blogs.msdn.com/sharepoint/archive/2007/09/25/microsoft-office-sharepoint-2007-sizing-and-configuration-tool-by-hp-new.aspx
*Microsoft - "Beta SharePoint 2007 model for System Center Capacity Planner Tool (SCCP)" - http://blogs.msdn.com/sharepoint/archive/2007/12/17/hardware-recommendations-and-sccp-sharepoint-capacity-planning-tool-beta-models.aspx
I just wanted to add that the post I made was a real life migration scenario, not an arbitrary test. The same number of SP 2003 databases that used to run at 35 % CPU, pegged our CPUs after the upgrade and forced us to another server. The fact is that MOSS has a huge SQL footprint compared to SP 2003. For anyone planning an upgrade, double SQL. This is alluded to in the SP documentation, which was a little late for us.
MOSS is best run on 64 bit even if it complicates dev a bit (no WSSeVS for 64 bit)
The SCCP SharePoint Models were just released via the SharePoint team blog about an hour ago. Let me