We need to implement a new MS-SQL/IIS server serving intranet pages internally. At the moment we are on average seeing 22 hits per second, but each request is quite small.
What would be your recommended server configuration?
a) single server with both applications
b) two physical servers, one per application
c) two VMware servers, one per application
d) other
Also, which version of Windows and MS-SQL would you opt for, at this moment in time, and why?
You don't say what load you expect from the Intranet app. I'm guessing that unless yours is a huge company the Intranet app won't be that big a load. In that case the key target is managability. If so, I would use two Hyper-V VMs. You can put them on the same physical server to start with, and if the load becomes too great put each VM on it's own server.
The advantage of having IIS and SQL on separate servers is simplicity. You don't have to worry about changes you make to one service affecting the other.
The advantage of using VMs instead of real servers is that you can back up VMs just by (shadow) copying the folder they're in. This makes things like SQL Server service packs much less scary. If you have two physical servers you can even keep copies of the same VM on both servers, then if you lose a physical server you can quickly bring up the VM on the other physical server. It also makes hardware upgrades much easier.
I would use W2k8 for IIS. Whether it's worth using x64 is debatable. I did use x64 on my most recent IIS server, but I ended up having to run IIS in 32 bit mode because many of the COM servers it needs are only available in x86 versions. For the SQL server using x64 will future proof it if you think you may need >4GB RAM, and to be honest you can never have too much memory for a SQL Server. I would probably choose SQL 2008 on the grounds that you'll have to eventually, and it's a lot easier to do it now than have to upgrade later.
Having a SQL Server on a virtual disk might raise some eyebrows (or will it be on a SAN?) but my testing of our middle size databases suggest that the performance hit is barely noticable. In fact when I recently moved one of our SQL Servers to a VM it ran about 50% faster, simply because of the massive increase in disk speed of the new host server compared to one two years old.
John Rennie
I manage our IIS and SQL server instances in a very active manufacturing environment. In the past we always had our "cookie cutter" sql/iis server and placed them in each of the different areas. There were too many time when developers made changes or installed software that caused server issues that obviously effect your sql server as well. Having said that I would definitely recommend splitting the applications onto separate servers. I don't know the performance implications to having sql in a VM environment or not. We have a test sql cluster build in VM and it runs just fine with many other VM instances on it as well.
We just recently began consolidating our sql servers into a sql 2005 failover cluster running on Windows Server 2003. They exist on 2 physical servers in an active/passive configuration with a SAN backend. If I could do it over I would have used SQL 2008 so I don't have to worry about upgrading for a while and would consider putting them in VM as well.
Our IIS servers exist in a web cluster on Windows Server 2003 in VM.
The thing I really like about VM is that as stated above, the VM instances can be snapped off and moved around without much notice to the end users. For example, where a physical server may come off lease, the VM instance doesn't come off of lease. And for the real hardware, you can just move your VM instances to another piece of hardware while you do your swap.
D) Other
Not enough information. What is your budget? Do you already have a virtual infrastructure? How much load do you expect on the server?
If you have an unlimited budget and significant load then the obvious answer is to separate AND virtualize everything.
To all virtualized SQL naysayers: show me the evidence that virtualizing SQL should be any different than virtualizing anything else. ; )
I'd go with either option B or C. Splitting the 2 would be best. If you have a good Virtual Server setup, then I don't see any reason why they couldn't be virtual servers. You just might want to be aware of how many page requests and SQL Requests you'll get for performance.
Unless you have heavy full-text searching on your SQL box, I'd go with SQL2008. Otherwise, I'd go with SQL2005. Server 2008 and SQL2008 integrate nicely with each other, so I'd go with them.
-JFV
My £0.02 worth:
Put the DB server on a separate box. This lets you optimise it for a database server. One or more clustered web servers can be run on cheap 1U boxes. Scaling a database server is much easier on a single box.
Don't use VM's unless you have a specific application for them. They really only give you a benefit if you have a large number of separate applications that you want to sandbox.
SQL Server 2008 gives you an extra three years of lifespan for your system for free. SQL Server 2005 will go to EOL 3 years before 2008 will, so using SQL Server 2008 gives your application more time before it needs to be migrated.
Not option A, certainly not within the same INSTANCE of Windows.
SQL Server really doesn't play too nice with other applications on the same server as it gents to get very grabby with RAM and can page out other applications / services. (I also recommend FIXING the amount of RAM SQL Server uses, switch off the "automatic" parameter)
You could have a single server, running vmware and hosting the two virtual instances of Windows 2008. If you've not started working with vmware (or any other virtualisation environment) then get on it.
Once you find that your single vm server is running nicely then you can look into investing in the higher end vmware products: esx, virtual centre etc. and you can build up your DR / HA and capacity with clustering.
