Database Reference
In-Depth Information
One of the first places to start when considering physical server hardware to run your
SQL virtual machines is to take an inventory of the makes and models of hardware
present in the data center today and combine this with the future direction of the
organization. For example, is the organization moving away from rack mount servers
toward blade servers? Then try to determine whether the direction in which the
organization is moving will impose any constraints to your design. An example may be
that a Tier 1 database requires more RAM than is currently available in the blade make
and model that your organization procures.
CPU
Next, it is important to understand the proper amount of physical CPU power that will
be necessary to run the databases you are looking to virtualize. Remember, a virtual
environment pools and abstracts resources; therefore, we must adjust our vernacular to
reflect this change. For DBAs, it is important to change from “how many CPUs the
database requires” to “what the aggregate clock cycle is the database requires.” Let's
look at this in more detail.
Historically, from a CPU perspective, in the physical world DBAs look to procure as
many CPUs as possible in their systems because they are planning for three to five years
out and they want to get these resources upfront and not have to fight for them later.
When SQL Server is virtualized and the right versions of the Windows operating system
and SQL Server are running, virtual machines can have the memory size and virtual
CPU count increased while the systems are running. If the required versions of
Windows for an operating system or SQL Server are not available, the option still
remains; however, it may become a downtime operation. If AlwaysOn is used and
automated failover is available, you can update the configuration of the standby node,
let it catch up and then fail over, and then update the primary node, let it sync back up,
and then fail back—all with almost no disruption. The same could be said of a Failover
Cluster Instance environment: You only have as much downtime as it takes for two
failovers to occur.
Another point to understand in a virtual environment is how resources from virtual
machines are allocated time against physical components of the server. For vSphere,
this is handled by the Scheduler. The CPU Scheduler's main goal is to “assign execution
contexts to processors in a way that meets system objectives such as responsiveness,
throughput, and utilization” (
https://www.vmware.com/files/pdf/techpaper/VMware-
identify and execute the CPU instructions of a given virtual machine. The more virtual
machines that exist on a physical server, the more complex this operation becomes.
Complexity becomes further increased as virtual machines vary in virtual CPU
configurations because the hypervisor needs to schedule all the virtual CPUs to execute
