Recommend me an HP Server

[jim]

Just wondering what the good folks at Hexus would recommend.

I'm looking at pricing on a good value server. The intention is that it would replace two old HP servers, one with a single 2.8 GHz (P4 era) Xeon, the other with a pair of them. Will need to be a floor stander.

Would be running virtual machines (not sure how many) for DNS, DHCP, AD, KMS, WSUS, Symantec AV, Websense, 3-user SQL database, Intranet, basic fileserver, software deployment for 60 machines. Probably something else I've forgotten.

Not looking for blistering performance, so I was thinking that something along the lines of Yorkfield, with 8GB RAM and standard SATA drives would probably do the trick? In server form, obviously.

Obviously though it's nice to have room to manoeuvre and upgrade in the future, so I'm not too sure. What do you reckon?

[Moby-Dick]

dual socket nahalem with plenty of RAM - assuming you are using ESX ?

think the killer there is going to be I/O rather than anything else. ( consider external storage ? )

if you are feeling really flush then use an SSD to host VM OS disks.

if budget is an issue then somethign like an ML150G6 ?

[Jiff Lemon]

Err, first thing I'd say is got nuts on Memory - 8Gb could soon vanish if you're running multiple virtual machines. CPU doesn't really get a hammering these days, however memory and drive I/O do.

How many users you looking after? 60 ish? (based on your software deployment plans). You got any other NAS/Storage pools lying around?

[jim]

dual socket nahalem with plenty of RAM - assuming you are using ESX ?

think the killer there is going to be I/O rather than anything else. ( consider external storage ? )

if you are feeling really flush then use an SSD to host VM OS disks.

if budget is an issue then somethign like an ML150G6 ?

Not sure what kind of virtualisation we're going with yet, but yeah could well be ESX.

Maybe something like this then:

http://h10010.www1.hp.com/wwpc/uk/en...5-3918507.html

And then if we need to, we can drop in an extra CPU at a later date.

Err, first thing I'd say is got nuts on Memory - 8Gb could soon vanish if you're running multiple virtual machines. CPU doesn't really get a hammering these days, however memory and drive I/O do.

How many users you looking after? 60 ish? (based on your software deployment plans). You got any other NAS/Storage pools lying around?

No storage to speak of... just a load of old 15k SCSI drives that need to go.

How much memory do you reckon would be good then? 12-16GB?

And out of interest, both of you are talking about external storage. Surely that would be worse? Or is the idea that a NAS unit's processor takes care of the I/O and takes the load off the server? And since everything's limited by ethernet, it won't make a difference to the end-user anyway?

[Moby-Dick]

its more about spindles - you can usually fit more spindles into an external NAS to try and keep the iops up. Also if you wanted to make use of virtual machine high availablilty / live migration , you'll need to be using storage thats shared between your hosts ( again this is more of a consideration should you expand )

[jim]

Ahh, I see where you're coming from. Might consider that actually. Storage needs aren't great so we could probably use a large number of low capacity disks and go about the problem that way.

[Moby-Dick]

althought as previously mentioned the best way to get very high performance from the Os part of your VM's at least would be to use an SSD

[jim]

*drools*

[Jiff Lemon]

How much memory do you reckon would be good then? 12-16GB?

Well, again, how many VM's are you looking at? 10 VM's with 3GB of memory each? 2 VM's with 8GB each? Memory is still (relatively) cheap; We were ordering Virtual servers with 128GB of ram and hooking them into the SAN for storage. Now I realise that you've not got the same budget, so you've a slightly tougher task ahead.

As Moby said, it's all about the I/O; Just because you're virtualising something, doesn't mean the I/O requirements change. Memory usage doesn't suddenly just vanish because you've virtualised it.

I'd be tempted to look at perfmon on your existing solution, log it, analyse it, see how it's performing. Once you've got a handle on what your servers are using in terms of I/O, CPU, network utilisation, and Memory, it'll be easier to plan your new server.

Alternatively, I could go into "consultant" mode, lick a finger, pick a server spec at random and declare it fit for X number of virtual machines supporting Y number of clients; Submit a huge bill and leaving you with the headache of the underperforming server.

[scaryjim]

Alternatively, I could go into "consultant" mode, lick a finger, pick a server spec at random and declare it fit for X number of virtual machines supporting Y number of clients; Submit a huge bill and leaving you with the headache of the underperforming server.

It's always a temptation when people ask these kinds of questions, isn't it

Is there any good reason why you want to put everything onto one server? Sounds like a single point of failure waiting to happen to me... perhaps your better bet might be to work out what you want each VM / server to do, then work out what specification you need to acheive that. Then you can spec either a single server that's powerful enough to virtualise all those tasks, or individual servers to perform each task, depending on which option provides the better value...

[jim]

Well, again, how many VM's are you looking at? 10 VM's with 3GB of memory each? 2 VM's with 8GB each? Memory is still (relatively) cheap; We were ordering Virtual servers with 128GB of ram and hooking them into the SAN for storage. Now I realise that you've not got the same budget, so you've a slightly tougher task ahead.

As Moby said, it's all about the I/O; Just because you're virtualising something, doesn't mean the I/O requirements change. Memory usage doesn't suddenly just vanish because you've virtualised it.

I'd be tempted to look at perfmon on your existing solution, log it, analyse it, see how it's performing. Once you've got a handle on what your servers are using in terms of I/O, CPU, network utilisation, and Memory, it'll be easier to plan your new server.

Alternatively, I could go into "consultant" mode, lick a finger, pick a server spec at random and declare it fit for X number of virtual machines supporting Y number of clients; Submit a huge bill and leaving you with the headache of the underperforming server.

Kind offer, but I'll pass

We've got someone coming in to do what you're intending, have a look at everything and make a recommendation based on what we will need in the future - I wanted to get an idea about what *sort* of equipment we're looking at first, so that I've got a baseline to work from and a vague idea about what would be in order.

Otherwise I'd probably just have to sit there and nod for an hour, with absolutely no idea whether they're being sensible or going a bit overboard.

It's always a temptation when people ask these kinds of questions, isn't it

Is there any good reason why you want to put everything onto one server? Sounds like a single point of failure waiting to happen to me... perhaps your better bet might be to work out what you want each VM / server to do, then work out what specification you need to acheive that. Then you can spec either a single server that's powerful enough to virtualise all those tasks, or individual servers to perform each task, depending on which option provides the better value...

Yeah, I did wonder about that. A single-server solution is currently being advocated, so I'll see what happens. I think the theory is that we keep the old servers running something very basic as a fail-over, although I don't know the specifics of that.




Anyway, thanks for all the help everybody

Feel a bit happier about it now that I know roughly where we stand!

[scaryjim]

... I think the theory is that we keep the old servers running something very basic as a fail-over ...

That'd make more sense. I've just bought in two new servers to run some web applications we've just launched, but when I deploy them I'll be keeping the older server to run automated backups and as a last-ditch failover in the very unlikely event that both new servers went down at the same time...