We just upgraded ours two weeks ago. The database and archive servers were on the same physical machine and the archive was running out of space. So, our reason for the upgrade was two fold; split the two servers to two physical machines and to add more disk space on the current archive server. You definitely want a lot of horsepower on the database server because SQL is a processor hog. After splitting the servers (which was the hard part) we discovered Windows server 2008 has utilities to expand the drives on the fly without messing with the data.
We planned and tested for several weeks for the upgrade and when it came down to it we still ran into issues. The hardest part about the split was configuring all the replicated servers and client machines to point to the new database server.
But I will say one thing, ever since we performed the upgrade and worked out all the bugs that took 3 days), my phone immediately stopped ringing from engineering.
Not sure if that answered your question.
Thanks Lucas for your answer,
We ended up using our old server for it, but we do see the slowdown... as it handles everything, from public drive to EPDM.
What I plan for the future:
Mounting a cheap speedy file server under opensolaris, for the ZFS file system, it will incorporate a bunch of SATA drive as a huge vault, and a bunch of SSD for their L2ARC technology, it's like the MAxIQ technology from Adaptec but all software. I am discussing with my IT guy to see if he can handle that. ZFS offers RAIDZ/Z2 very similar to RAID5/6, so I save myself hard drive failure, but with better write performance, and as I can use the SSD as cache, it will automatically be a great value for the database handling. I did not go through all the documentation but it should be able to handle the hot swap and adding a extra disk.
Then, I'll have it connected through multiple teamed ethernet connection to a single physical server, will have a linux based host running a virtualized windows server or we will run it off a hypervisor. Software will be run from it and data will be on the file server pouring data towards my network.
I do that because I can salvage my old server as a fileserver only and experiment ZFS. (adaptec with MaxIQ+SAS drive is expensive and we think that we can end up with a smaller price tag going SATA+SSD+ZFS)
We virtualized the application server for disaster prevention, we clone the VM on the day that we figured out all the bugs and all, then, if one day it crashed we mount it somewhere else for the time being. I looked at some benchmarks results, very old ones though, a VM has approx 90% of the cpu power of a standalone machine on which it seats. Then, we will need to see how well it handles file transfer as all the files will be on a separate machine.
Thanks for your input. I now know what I need to focus my money into
I did not see anything in your plan about the processor. This is what I found in terms of speed: on the archive server side; fast hard drives and Ethernet connection for I/O of data, on the database side; fast processor(s) for SQL queries.
I forgot to tell you the specs of our database server. We were running a single dual core processor with 8GB of RAM for both the archive and DB server. We saw system lock ups while performing multiple SQL queries with this set up. When we split the DB, we went with a dual quad core processor with 12GB of ram. Like I said, SQL is a processor hog so make sure the processor can handle all the SQL queries from your users, it is money well spent.
Yup, I think we'll start out with a single quad E5xxxx from the last batch of nehalem xeon, and then if we really feel it sloppy, we'll move to two.
Thanks for your valuable input definitively.
From our experience I don't think the previous answers adequately noted the importance of system memory (RAM).
You should take a look at Windows Task Manager on the server you are currently using for EPDM to see why it is slow.
If you are running Windows Server 2003 Standard then you are limited to 4 Gb memory. SQL Server is more of a memory hog than processor, our EPDM database server consistently uses over 4 GB RAM so we are running it on the 64 bit version of Windows Server 2003 which raises the limit to 32 Gb RAM.
If you have enough disk space on your current server it would probably work well as the archive server, this will reduce the changes you need to make to the clients. The archive server uses very little processor or memory.