May 14, 2007 at 5:58 am
Hello, our windows server people are interested in using VMware in our live environment. Currently we have about 15 separate SQL servers and according to them are all candidates for Virtualization using VMware. Does anyone use VMware in their live environment? How many database servers can be virtualized? Can you share any experience? What are the specific efficiencies or deficiencies?
thanks,
May 14, 2007 at 6:24 am
You shouldn't have many problems, but you should set up VMWare to use multiple physical disk drives so that you can still separate the databases onto different disk spindles as well as separating the log files from the data files.
There are many articles from MS and others about setting up SQL Server on a virtual PC.
See http://www.sql-server-performance.com/installing_sql_clustering_virtual_server1.asp, and the Aust SQL Server User Group had some articles on it recently (or at least my email newsletter spoke about it). Some people suggest that you can set up 2 SQL Servers in a cluster on a single physical machine for increased redundancy. It really depends on how much data you have, how busy the servers are, etc.
Could you consider putting all of the DBs on a single instance of MS SQL Server rather than run many instances of SQL Server? Alternatively, rather than run VMWare, could you run several instances of SQL Server on a single instance of Windows?
May 14, 2007 at 8:00 am
I tend to agree with Ian. While virtualization makes sense in some cases and gives you hardware independence (a problem with Windows), SQL is mostly hardware independent already. Multiple instances makes more sense.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
May 14, 2007 at 8:54 am
Is anyone using it in a LIVE enviroment?
I have read that since I have 3 different server collation sequences I would need to have at least 3 instances. I have one Latin_BIN, and case sensitive and case insensitive servers.
What about security issues when combining multiple servers into one. One user could have x rights (almost Sa) on one server but not have that on other systems they support.
How would security and collation be handled?
May 14, 2007 at 11:12 pm
The instances each have a seperate security environment - in all practical terms they are really no different from having three instances on three different boxes. I have two instances on my primary Prod box due to collation coflicts. I have some users with the same rights on each but only because I explictly made that so. Most users have different rights as required.
We looked at VMware as a SQL Server platform with a SAN disk array. IMHO, the real issue is that it shares a IO path (virtual switch) between many VM instances in exactly that same way that having multiple physical boxes share a single network switch can be an issue. Of course the management of this issue appears to be the same as for a physical switch but we decided not to introduce another layer to our IO path.
The other issue is that it does not offer any real advantages in that we don't wish to share the SQL boxes resources to be shared so our model is towards using the same type physical box for both a VMware server and a SQL Server server and run (the fewest possible number of) multiple instances.
May 15, 2007 at 7:50 am
What are the advantages for the DBA by combining 7 to 9 separate SQL 2000 database servers into one VMWare server? Currently each database server is a separate server with one SQL instance per server. The proposal is to have two Virtual servers that combine about 7 database servers on each VM server.
What are the disadvantages?
Has anyone loaded multiple purchased SQL databases on Live VMware servers?
I need a technical reason why a DBA would want to combine multiple SQL servers and a technical reason why we shouldn't.
May 16, 2007 at 3:51 am
I have seen posts from people saying that are running SQL under VMWARE in production with no issues.
However, you should be aware that the main thing any database needs to perform well is memory and fast disk I-O. At present, Windows virtualisation limits memory usage and gives poor disk I-O. If you get the performance you need to meet your SLAs, then virtualisation is not an issue for you. If you virtualise and things are too slow, you may need to make the most heavily instances real again to get the performance you need.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
May 16, 2007 at 7:45 am
Our shop is currently virtualizing most servers to reduce hardware support costs. So far we have not virtualized any SQL Server installations because of the performance hit they would take. This is a recommendation from our VMWARE expert. He recommends we only virtualize applications with low to moderate performance requirements. SQL Server loves grabbing as much CPU as it can. So we’ve taken the approach of one instance with many application databases.
The only benefit I can see with virtualization SQL Server is ability to back an instance and restoring it on another server. Since performance is much more important than portability we don’t use virtualization for SQL Server.
David Bird
May 17, 2007 at 9:27 am
We don't VM SQL Server for the reasons above (I/O, Grabbing CPU...) We did review and are discussing with our software vendors - PolyServe as a method of reducing our SQL Servers - particularly clusters. You many want to look at it as a better option than VM'ing.
June 28, 2007 at 3:10 pm
We used virtualization and consolidation in our environment. For the most part virtualization works as advertised. It is very nice for DR. The new technology basically permits the LAN team to replicate an entire environment without any downtime. I am in the process of consolidating SQL. I have consolidated 49 servers down to 4. These 4 environments are 2 test and 2 production, running SQL Server 2005. Intially I tried multiple instances, but I started running into resource issues. One gotch is, if you need to run Ananlysis Server, you must have it running in the default instance. So, stay away from named instances if you can help it
June 28, 2007 at 6:04 pm
DO NOT USE VMWARE FOR PRODUCTION SERVERS! It is great for reducing cost of development and qa servers but if you value your career you will not let them put you in this potentialy very unstable environment.
July 17, 2007 at 9:29 pm
As previously mentioned PolyServe has a MUCH better solution for SQL Consolidation, not only do you get 3-4:1 server consolidation but you get built-in HA. If you have SQL running on a VM and your database hangs what is VMware going to do about it? Nada.. PolyServe on the other hand will immediatley re-host your SQL instance on another server and clients can seamlessly reconnect. Check it out for yourself, good read.
http://www.polyserve.com/sql_server_consolidation.php
~LT
March 7, 2008 at 2:45 pm
I have 2 new HP DL380 G5, Dual Quad-Core Xeon 3.6GHz, 14GB RAM servers that are connected to an HP SAN with 4 TB of storage. The SAN provides Extremely Fast disk i/o. These servers will run VMware Infrastructure 3.
Our production server is SQL 2005 Ent running Great Plains accounting system. We constantly max out users at 144. I do not think I'll virtualize this server.
But I do want to virtualize the seperate SQL 2005 Ent server running Reporting Services that pulls data from the above. The Reporting server will be hit hard.
The VMware server with SQL Reporting Services will also host our Intranet server (databases on a seperate physical server), a Windows Software Update Server and a file & print server. The file & print server is hit by 350 users.
Anyone see any problems with this configuration?
Thanks,
Terry
A great day starts with a great attitude
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply