Consolidate SQL servers? and Windows F&P server specs.

[LSUJeff]

I'm getting ready to virtualize a whole rack of about 10 servers. Most

are small, random app/DB servers that are utilized by a handful of

users (5-30 depending on the app), the others are Windows File and

Print servers for 180 users that will be consolidated into a single VM.

Since we're an academic institution on the Microsoft Campus

Agreement MS SQL server is dirt cheap so, over the years whenever we've

rolled out an app server that needed MS SQL server we just bought an

unlimited seat license for it (IIRC around $90). So, I'm running 6 SQL

servers for 6 different apps/web front ends on 6 separate physical

machines now.

As I'm migrating to VMs I was wondering if I'd be better served

(pun intended) by setting up one MS SQL server and putting all of the

DBs on it while still maintaining separate VMs for each application or

if I should keep doing what I'm doing and leave each with its own SQL

server. Some of these SQL servers never see more than 3-5 concurrent

users, others might see 10 concurrent users.

Also, is there any way to calculate what specs would be recomended

for a simple windows file and print server based on the number of

possible concurrent users? I've never been in a position where I

really thought much about the specs I've just bought hardware with

decent specs and shared out the data from it and got acceptable

performance. Now that I'm having to set these parameters consciously

I'm not sure how to proceed. Should a file and print server for 150

concurrent users and ~3 TB of data need 1 proc? 2 Procs? More? 2 GB of

RAM? More?

My main file and print server right now has a quad core Opteron and it

never uses much more than a few percent of CPU even when large amounts

of data are being moved to and from its shares so I assume that CPU

isn't that important in my case. Is there any benefit to running a 64

bit OS for a VM that's just doing Windows File and Print sharing?

Also, I may go 2008 Server Core for the file server VM since it

doesn't waste resources on a GUI and other unused functionality.

Thanks,

Jeff

[mcowger]

The nice thing about VMs is that you dont have to be as careful about that. Start with a 1vCPU VM w/ (say) 2GB RAM and see if you get acceptable performance. If you dont, just give it some more vCPUs or memory, as needed.

--Matt

[vmroyale]

Jeff,

I personally would avoid the SQL consolidation effort as part of the VMware consolidation project. A big part of virtualizing your infrastructure is the PR and "selling" of it to your customers. You want the VMware implementation to go well and your users to be happy with the results. If you consolidate the SQL Servers, virtualize them and the performance ultimately suffers then it is likely that your customers will associate the virtualization with the problems. Simplify things by just taking what you have (and you know works well) and virtualizing it. If it still works well (or possibly better) then start focusing on the SQL consolidation piece later on.

The key to calculating what you need in a virtual machine is to know what your physical machines are currently doing. It will be difficult to formulate specs based on users for a file server, as there are a lot of other factors involved. You hit on it already with your observations of the processing. Check the memory usage as well, and see what the server is really using. If you discover that you really need more than 4Gb RAM, then 64-bit may be worth considering. I doubt you will find this though. Like Matt said, start small and then add as is necessary. With virtualization, the hardware approach changes from the "throw something big at it and watch it work well" to needing to know a bit more about what the servers are really doing and then allocating resources appropriately. Unless, you have money to burn - Having worked at an academic institution before, I somehow doubt that this is the case!

With file (and many other) servers, it will likely be the disk IOPS that will be the biggest issue involved, which means we may need to talk about your storage plans as well. Can you elaborate on the storage piece of this equation?

Good Luck!

[LSUJeff]

The storage is going to be iSCSI on an EqualLogic PS5000X. 16x400 GB, 10k RPM SAS drives and it has dual controllers. I'll have them connected in a high availability, high bandwidth configuration with 2 gig-e switches. So, each controller will have 3 gig-e ports to work with for a total of 6 ports.

It better kick anus 'cause I spent $40k on it. I'm actually in the LSU Athletic department so even though we are an "Academic" institution money isn't usually hard to come by.

[vmroyale]

Sounds like you probably in great shape. Your storage is on the HCL, and money isn't hard to come by! That's two big check marks in the + column.

Seriously though, it is probably worth monitoring the disk, mem and processor usage on those servers that you wish to convert. I typically try to get at least 30 days worth of data to make sure that I cover the typical usage cycles. From there you can size your virtual machines with a good sense of knowing that they will not be resource constrained.