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:
- Copy the virtual server disk image to a different
folder.
- 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).
- 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.
- Create a new virtual server guest on the host.
- When prompted for the disk information, select
the virtual server disk image you just copied and
renamed.
- Start the virtual server guest.
- Set the IP address on the server to a static address.
- Rename the virtual server guest to its permanent
name.
- 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 
