March 3, 2010 at 4:23 pm
I am currently running my reporting services on a seperate box from my SQL Server and now I'm asked to move it to a virtual server. So does anyone know of any potiential issues or current problems of running SQL Server Reporting Services 2005 on a Virtual Server?
March 4, 2010 at 7:42 am
Obviously, YMMV, but I'm been running a report server in a VMWare VM for about a year now and I've really not had any problems. here are a couple of recommendations/things to keep in mind.
1) If you are hosting your Report Server Databases on a machine separate from the reportserver itself, think about how any kind of VMotion might affect those connections and plan accordingly.
2) If the databases are on the same machine, think about how that might scale, plan accordingly.
3) give the VM it's own NIC, depending on how busy your report server is and how many disparate data sources you may use you may find there is contention for network IO with other busy VMs.
4) decide how you are going to handle vmotion (or whatever MS/Xen calls moving the VMs while they are running).
5) keep a close eye on your Disk/SAN IO.
6) test, test and test again.
VM's give you a lot of benefits, but like anything else you need to test and plan and review your performance to make sure you're getting out of it what you think you are.
-Luke
March 10, 2010 at 12:53 pm
hardware resources. we run a scale out version of SSRS and the main server has 32GB of RAM. Reason is our BI devs wrote a bad query one time and took down the web site. on physical hardware it's easy to add RAM, storage, faster CPU, etc. on VMWare or hyper-V you'll will be begging like in the old mainframe days since there are other VM's and they all need the resources.
March 10, 2010 at 1:39 pm
SQL Noob (3/10/2010)
hardware resources. we run a scale out version of SSRS and the main server has 32GB of RAM. Reason is our BI devs wrote a bad query one time and took down the web site. on physical hardware it's easy to add RAM, storage, faster CPU, etc. on VMWare or hyper-V you'll will be begging like in the old mainframe days since there are other VM's and they all need the resources.
I guess the point is however that your BI Devs could/should have been testing their stuff on a Dev server, not production? And/or there is always that trade off between right now reporting and waiting 15 minutes for replication to occur so that you're never reporting directly on your production database.
I'd actually posit that since you only needed the memory that 1 time and your VM's can be isolated and restricted to only use X resources it won't take down every thing else. Also they can be setup to use extra memory, CPu cycles etc on demand with a max value and the ability to automagically migrate to another host with more available resources if need be. At least VMware has these capabilities that is. I've no experience with Hyper-V or XEN, so I can't comment on their abilities though I would imagine that ability would be fairly standard. On a physical box you need to shut it down pull it out of the rack open the case install a matching pair blah blah. On a vm I change a value in a text box (or use a slider if I'm really feeling lazy) reboot the guest and have my extra memory before you can even get a physical machine shut down...
But that's just from my limited experience.
-Luke.
March 10, 2010 at 3:13 pm
ppreston (3/3/2010)
I am currently running my reporting services on a seperate box from my SQL Server and now I'm asked to move it to a virtual server. So does anyone know of any potiential issues or current problems of running SQL Server Reporting Services 2005 on a Virtual Server?
You wont have any problem running SSRS on Virtual servers, As your database is hosted on different box. We are running SSRS on Virtuals for nearly year and half no problem at all.
March 11, 2010 at 8:08 am
Luke L (3/10/2010)
SQL Noob (3/10/2010)
hardware resources. we run a scale out version of SSRS and the main server has 32GB of RAM. Reason is our BI devs wrote a bad query one time and took down the web site. on physical hardware it's easy to add RAM, storage, faster CPU, etc. on VMWare or hyper-V you'll will be begging like in the old mainframe days since there are other VM's and they all need the resources.I guess the point is however that your BI Devs could/should have been testing their stuff on a Dev server, not production? And/or there is always that trade off between right now reporting and waiting 15 minutes for replication to occur so that you're never reporting directly on your production database.
I'd actually posit that since you only needed the memory that 1 time and your VM's can be isolated and restricted to only use X resources it won't take down every thing else. Also they can be setup to use extra memory, CPu cycles etc on demand with a max value and the ability to automagically migrate to another host with more available resources if need be. At least VMware has these capabilities that is. I've no experience with Hyper-V or XEN, so I can't comment on their abilities though I would imagine that ability would be fairly standard. On a physical box you need to shut it down pull it out of the rack open the case install a matching pair blah blah. On a vm I change a value in a text box (or use a slider if I'm really feeling lazy) reboot the guest and have my extra memory before you can even get a physical machine shut down...
But that's just from my limited experience.
-Luke.
every time i asked our Windows guys for some VMWare space for something they said no more storage and no more RAM available. we run replication once a minute in some cases but what happened was the query overloaded the SSRS server which doesn't have any databases on it. Just IIS and SSRS. $1300 for 32GB RAM took a few days to get approved and ordered. no big deal. if your VMWare is full or close to full then it's going to be a major project to order another server, SAN storage and add it to the cluster.
we have our own SQL VMWare that we run the free version of ESX on it, but we only use it for testing. hardware is so cheap and even cheap 1U servers scale up to some insane configurations i don't see the point of virtualizing SQL. and it's usually easier moving SQL instances around if the server isn't virtualized. next month we'll probably order a few servers with the 6 core CPU's and 72GB of RAM and move a few cluster instances around
March 16, 2010 at 8:53 am
hardware is so cheap and even cheap 1U servers scale up to some insane configurations i don't see the point of virtualizing SQL.
At my last company we did it to make configuration management easier. All the boxes were the same, could be easily changed, and disaster recovery was *much* simpler. We could spin up test boxes or additional web servers in a jiffy, and it saved some floor space. It probably didn't save money the way it was promised early on, and there were some performance costs as well, but at the time were consolidating data centers and trying to make some choices between windows and linux so it was even more helpful. YMMV, but hardware costs are not usually the prime driver of a move to virtualization.
[font="Arial"]Are you lost daddy? I asked tenderly.
Shut up he explained.[/font]
- Ring Lardner
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply