SideBar    Creating a Virtual Server Base Image

Server virtualization is a hot topic. Most of the new server installations I perform for my consulting clients have some type of virtualization. SQL Server is unique because of the potential processor, disk, and memory demands it can place on hardware. SQL Server is one of the few Microsoft server applications that has the potential to place a significant load on the processor, especially if your application deals with large tables or high transaction volume. Therefore, running SQL Server in a virtual environment is an option many enterprises will want to consider.

Physical vs. Virtual
Most SQL Server installations don’t use 100 percent of a server’s resources all the time. In fact, many SQL Server applications use only a percentage of a server’s processing potential. SQL Server processor utilization tends to be high for short periods of time. The current version of servers that are available with quad-core processors and significantly faster Serial Attached SCSI (SAS) drives capable of 3Gbps transfer rates represent a quantum leap in server performance. Virtualization can take advantage of the processing power of this new generation of servers, providing significant leverage for your hardware dollar.

Physical server advantages. Traditionally, SQL Servers run on dedicated hardware. This gives the server full access to all the processing power on the server. Running SQL Server on a physical server means that the server doesn’t need to compete with other virtual servers for resources, and a physical server will perform approximately 10 percent to 25 percent faster than a virtualized server on the same hardware. SQL Server 2005 Standard and Enterprise versions can address the maximum amount of memory that the server and OS will support. Also, a hardware failure on the server will affect only one SQL Server installation.

Physical server disadvantages. A physical server can waste resources because the server’s processing power often goes unused. Using one physical server per SQL Server installation significantly increases your hardware costs, and if each physical server is placed on a service contract, your maintenance costs are also higher. And the greater number of physical servers consumes more electricity and requires more physical space than a virtual server setup does.

Virtual server advantages. By consolidating several virtual server guests onto a single physical server, you can save a significant amount of hardware cost and provide better utilization of hardware resources. When determining where a virtual guest should reside, pick a physical server that hosts complementary guests. For example, if a SQL Server installation will place a significant amount of I/O stress on the processor, run it on a physical server that hosts other virtual guests that don’t require the same type of I/O processing.

Virtual servers can lower your hardware maintenance costs because you’ll have fewer physical servers to maintain, as well as lower electric bills and power requirements. With the cost savings, you might be able to place all your host servers on a 24x7 support contract compared with a 8x5 support contract if you’re not using virtual servers. Even with this increased service level, you’ll likely have a net savings for hardware maintenance. Virtual servers also make bare metal restores easier. Every virtual server hardware configuration is consistent regardless of the host’s physical hardware configuration. Therefore, you simply copy the virtual server guest files to another physical host.

Virtual server disadvantages. With VMware’s VMware Server and Microsoft Virtual Server 2005, you can allocate a maximum of approximately 3.8GB of memory to each virtual server guest. With VMware ESX Server, you can allocate a maximum of 16GB of memory to a virtual server guest. If your SQL Server deployment requires more memory than these limitations, the server is probably not a good candidate for virtualization. Because all virtual server guests must share the host server’s physical hardware resources, if too many guests are running on a host server, performance will suffer. Avoid placing too many guests on one host or guests that require concurrent hardware resources.

Fault tolerance is another virtual server disadvantage. A hardware failure will take down all guests running on the host. However, if you use VMware Server or Virtual Server 2005 and you have a backup of each virtual server’s guest file, you can restore these files onto a different host and quickly bring up the failed guests.

Virtual Guest Placement
When planning the placement of your virtual servers, try to select virtual server guests that have hardware resource requirements that are complementary to each other. For example, a SQL Server application that contains a large number of stored procedures and triggers with a relatively small database with light transaction volume will have higher processor requirements, but relatively light disk requirements. This SQL Server instance could be run in the same host as a file and print server that stresses the processor very little but may require high disk performance to serve files. Take into consideration how many users will access each virtual server and how these servers are stressed during the day. For fault tolerance, don’t place all of your most important servers on a single host. If your server environment is complex (1000+ servers) you might want to consider one of the server metric and design tools such as CiRBA (www.cirba.com/product/product-overview.htm). This tool helps automate the process of server placement, host design, and performance tuning of virtual server guests and hosts.

Creating Virtual Server Guests
I suggest that you create a base image for each type of server guest you plan to use. The “Creating a Virtual Server Base Image,” checklist shows the basic guidelines I follow when building a virtual server base image. After you create the base image, you can create a new virtual server guest by following these steps:

  1. Copy the virtual server disk image to a different folder.
  2. Rename the virtual server disk file to a different name than the base image disk file (e.g., “SQL1 C Drive.vmdk” if you’re using VMware Server; “SQL1 C Drive.vhd” if you’re using the Microsoft product).
  3. Create other virtual server disk files as necessary. Often you want the server to have a D drive or other drives to store data, depending on the server’s role.
  4. Create a new virtual server guest on the host.
  5. When prompted for the disk information, select the virtual server disk image you just copied and renamed.
  6. Start the virtual server guest.
  7. Set the IP address on the server to a static address.
  8. Rename the virtual server guest to its permanent name.
  9. Join the virtual server guest to the domain.

If you’ve properly created your base images, it should take you about 15 minutes to bring up a new server. You can then install SQL Server or other applications you might need. Ideally, you should place these images on a SAN or other file server share so that all new hosts have convenient access to them. Consider using ISO images of the installation CD-ROMs of SQL Server (and other applications) to speed up the installation of new servers. Properly configured base images can save you an hour or more of set up time per server—and much more if you consider any required hardware installation.

Continued on page 2.

   Prev. page   [1] 2     next page



You must log on before posting a comment.

If you don't have a username & password, please register now.

Reader Comments

Thanks for this article Al. I have been using Virtual SQL servers in production for four years now and received a good deal of flake from DBAs for doing it. This article vindicates the decision that has seemed so obvious for a long time.

SCG- December 02, 2007

Article Rating 5 out of 5

Hi, good to have some info on this, but I miss good information on the biggest bottleneck on SQL Server, Disk I/O, which is in Microsoft Virtual Server a big problem for performance. I have some experience in VMWare ESX, and the difference is smaller there, but be sure to test a real life load on a virtual server before stepping over to virtualization.

ge@familie-brander.nl- December 06, 2007

Article Rating 3 out of 5

I guess I need to be enlightened... the article ends with "...but the benefits are tremendous". What exactly are the benefits? I understand that if you needed to run different OS's, virtualization is a great way to save on hardware, but why do I want to run the SAME os multiple times? Since when did it become practice to have one app per os? If I need to run SQL, Exchange and IIS, why is it better to run 3 copies of the OS (each needing updating and configuration) versus running them all on a single instance of Windows Server?

If the answer is the ease of backing up the image files, the author even states that he's doing a regular backup of his sql data every 15 minutes anyway. And we have to assume that backup hardware is available in case the server crashes... why not log ship or mirror to the backup hardware?

If you really need seperate instances of sql server for all your apps, why not run new instances of sql? Doesn't that simplify maintenance, not to mention licensing?

Please point out the benefits to me.

Wavel- December 07, 2007

Article Rating 1 out of 5

ge:

If you're experiencing heavy disk I/O, you could move to the x64 platform, load up the server with a lot of memory and cache everything. This will take a siginficant load off of the disk subsystem. Of course you have to use ESX which supports an x64 guest, and now supports up to 64GB of memory on a x64 guest. This is the same strategy that Microsoft is using for Exchange 2007. Run x64, load the server with a lot of memory and cache everything.

Thanks!

Alan Sugano

asugano@adscon.com- December 12, 2007

Article Rating 5 out of 5

Wavel:

Probably the biggest advantage in your situation is security. Assuming you need to run Outlook Web Access or Sharepoint, you can install a virtual server and only have that front end Web Server exposed to the outside. If you have everything installed on one machine and it gets hacked all of the data that resides on that server is vulnerable.

Since virtualization creates a consistent platform, it makes recovery much easier. If you have the virtual server images backed up, all you have to do is restore the image onto a new server and you're done. If you're not virtualizaed, you have to load the OS, install the backup software, install SQL Server and then restore the databases.

We've also found that running separate applications per server, reduces the possibility of conflict between applications. We've seen instances where corruptions in certain components can cause other items to fail on the server when they're all installed on the same server. For example, if the metabase in IIS is corrupted it can cause Exchange to crash.

If you're doing anytype of testing, it's very easy to create a virtual test environment, and take it down without messing up your production environment. Once you have your base images installed, you can create a new server in 15 minutes, that's fully patched and ready to go. That's pretty difficult to do with a physical server.

Even in small shops virtualization may have a place, espeically if you have to run 32 and 64 bit servers. I suggest playing around with the technology and start slow. If you're not sold on technology I think you will be after you've had a chance to experience it first hand.

Hope that helps!

Alan Sugano

asugano@adscon.com- December 12, 2007

Article Rating 5 out of 5

Alan: Your statement that the biggest advantage is security is interesting. Assume that the Sharepoint server is compromised. What assures you that there is no possible way of getting to the files on one of the other virtual servers? Or even better: DOWNLOADING the virtual image for those servers!

You also said that you could create a fully patched instance in 15 minutes once you had your base image. But MS is patching monthly, so do you end up with new vm's that still need patching? Or are you updating the base file each month? And once your new vm is running, it needs to be patched seperately from all the other vm's right?

As for testing in a vm that's running on a production machine.... really?? Are you 100% sure that you can't crash the hardware inside the vm? Seems pretty risky to me.

The point I'm trying to make is that so far, I'm not seeing a good reason to run a vm. We are a very small company - every server we buy affects our bottom-line, so it's not an issue of us being a fortune 1000 that can buy as much hardware as we desire :) Every point you've made as a reason why you'd want to run virtualization, seems to have a valid counter-arguement against it. I'm looking for the one big reason that makes me slap my head and say "Duh!".

Wavel- December 13, 2007

Article Rating 1 out of 5

Wavel,

Let's say you're really small company that only has a budget for a single server, but you need to run a SQL server 2005 x64, Exchange 2007 (requires x64), Terminal Server and a File Server. SQL and Exchange need x64, but you need the Terminal Server and File Server to run 32 bit for compatibility. One option is to purchase four servers (or maybe two but you would have to combine SQL and Exchange, File and Terminal Server. Possible, but not the ideal situation especially for the File and Terminal Server), but if you don't have the budget for that, you could get a larger server and run four virutal guests on it. You might have some money left over to put the host server on a 24x7 4 hour service contract.

To answer your patching questions, Blue Lane makes a in-line security product that works with VMware ESX. It will essentially "patch" all of the virtual guest running on a host running the Blue Lane product. Check out this link http://www.bladewatch.com/2007/03/15/blue-lanes-vmware-security-product/ for more info.

But, it sounds like you're already made up your mind, so probably running everything on dedicated hardware is your best bet.

asugano@adscon.com- December 17, 2007

Article Rating 5 out of 5

Be sure to watch for our product showdown on virtualization software ii mid-2008. We'll show you how the products stack up against each other. Diana May SQL Mag

DianaMay- December 21, 2007

Article Rating 4 out of 5

 
 

ADS BY GOOGLE