Deploying MOSS to a One-Server Production Environment
Hello, As I understand, a MOSS environment typically consists of at least two physical machines – a Web Server and a Database Server. From what I've read it is not recommended to deploy MOSS to a one-server production environment. However, I cannot find a defnitive answer (or answers) for this. Can someone please explain to me why it is bad to have the web server and database running on the same server? In may case I have a medium size farm running and currently have MOSS 2007 running on two servers: one for the web application and one for the MOSS databases (content, etc.). They want to offload the MOSS databases and put them on the same server as MOSS web server. I would like some hard facts to support my case for them not doing this. Any information would be greatly appreciated. Thanks, Bruce
June 22nd, 2010 10:44pm

If you will move DB on the same server where MOSS is installed the performance will drop dramatically. This configuration is Ok for DEV server or company with ~5 users. But this is really depends how users are using SharePoint. Oleg
Free Windows Admin Tool Kit Click here and download it now
June 22nd, 2010 10:56pm

Thank you Oleg. So it comes down to performance. Interesting.
June 22nd, 2010 11:55pm

Oleg, Sorry, but can you please explain why the performance drops dramatically? Thanks, Bruce
Free Windows Admin Tool Kit Click here and download it now
June 23rd, 2010 12:01am

SQL Server and SharePoint will share RAM and disk IO. Moreover if you use Windows Server 32 bits RAM will be limited by 4GB. Oleg
June 23rd, 2010 12:15am

I am pretty sure that you are NOT saying you want a Basic/Stand-alone Installation - A puppy DOES die each time that occurs. :-) Bruce, if I am understanding you, you want to know if it is possible and why it might be bad to install SharePoint and SQL on the same box. Provided you avoid the Basic/Stand-alone installation type, you can do this. There is some planning to do to allow this environment to be scalable and upgradeable. I am assuming that at some point, this farm may have at least two (SharePoint and SQL) servers. Right now, these two functions will be on the same box; the key to pulling this off is to ensure that you can: Successfully operate this farm, delivering decent performance. Deliver a farm that is eventually scalable beyond one physical server. Ensure that the farm you deliver will be upgradeable to 2010 when the time comes. I'd recommend that you have a 64-bit server with a reasonable amount of memory - think 4-8GB minimum, considering that you are placing SQL and SharePoint on the same physical box. This box will also be demanding some heavy disk I/O from both the SharePoint and SQL services; try and ensure that you can get several physical drives for this server, and carve them up according to best practices (I would try as much as possible to separate SQL Transaction Logs and Databases, and keep SharePoint 2007 on yet another set of spindles). If you can build these each on a RAID 1 (mirrored) or RAID 10 (striped/mirrored) set of drives, you should avoid considerable I/O contention. You were not specific about the OS or SQL version. I would strive to install Windows Server 2008 R2 and SQL 2008 R2 (only the 64 bit versions) - this will allow you the easiest upgrade when you eventually go to SharePoint 2010. If you are using WS 2008, understand that as soon as you branch out from single server to multiples, you will either have to drop the firewalls between these servers (much less secure) or open up the appropriate ports in Windows Advanced Firewall. But right now, the Firewall is not a concern as all services will be on the same server. Install SQL Server. When you get the opportunity to create a named instance (servername/instancename), do so. You should build a SQL alias this using cliconfig (on what would be the SharePoint server) to allow this SQL instance to be eventually moved to a separate box without the need for some rather awful backup/restore/configuration db procedures. Ensure that you tell SQL to separate the Transaction Logs and Database files to the correct drive sets you created previously. As stated in the other posts, the SharePoint installation should never be a Basic/Stand-alone installation. At the "Choose the installation you want" screen, ensure that you choose Advanced - NOT Basic. On the next screen, you will get another chance to choose the wrong install type again: Choose Complete - Install all components - NOT Web Front End OR Single Server. This will seem wierd, considering that this is only a single server, but choosing Complete will allow this single box to be scaled out into a farm at some point in the future. When you get ready to grow your environment, the SQL services are the first to go. Move the SQL instance associated with your farm to the new box, repoint your SQL alias to the (newservername/instancename) named instance, and you now have a small farm. Depending on your load (I am assuming intranet), you should be able to service into the low thousands of users. You can determine beforehand how many IOPS (http://www.microsoft.com/downloads/details.aspx?familyid=9a8b005b-84e4-4f24-8d65-cb53442d9e19&displaylang=en) your box will be able to handle on a per-drive-set basis. After you start having users on the box, watch your utilization on this box using PerfMon to see if you need more RAM or Drive Spindles. Good Luck! Troy Lanphier http://blog.sharepointcookbook.com
Free Windows Admin Tool Kit Click here and download it now
June 23rd, 2010 6:20am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics