Database Reference
In-Depth Information
they are being asked by Audit and Compliance whether their database server will meet
their particular industry's regulatory guidance. For a lot of customers, the answer is no.
What do we do about all of this? Reorganization. Because we are going down the path
of virtualizing our physical SQL Server environment, why not take the opportunity to
reorganize our database servers into compliant stacks. Identify and group databases
according to their operational level (production, QA, test, development), internal
development, third party, adherence to industry regulation (HIPPA, SOX, and so on),
and whether they play well with others. This last grouping of databases includes
recipients of bad up-level code, those that have unique performance requirements, those
that require special maintenance windows outside the other database, those that host
applications from a third party that does not always support the latest patches, and so
on. The design goals here are to group databases that will optimize security, stability,
and performance, thus leading to decreased operational overhead and producing a less
complex environment to manage with a smaller group of standard configurations.
Tip
Grouping databases according to function, operational level, compliance
requirement, and other factors can lead to improved operations, increased
security, and a more stable SQL Server environment.
As we have discussed in this section, the typical deployment we see in the physical
world within our customer base is a large physical server loaded with as much RAM as
the server can possibly hold. The SQL Server is configured with multiple instances and
many databases sitting behind each instance. What we see after customers begin their
journey down SQL Server virtualization is smaller virtual machines (“smaller” being
relative), with SQL Server being configured with only one instance. However, we do
have customers who carry over the same model of SQL Server running multiple
instances and supporting many databases.
It is important to remember the entire system when designing your architecture. Do not
forget about features within the vSphere platform, such as DRS, vMotion, Storage DRS,
Storage I/O Control, and Network I/O Control, just to cite a few, and how some of these
features work more efficiently with smaller virtual machines than larger virtual
machines. We are not saying these features do not work or work well with larger
systems. Instead, what we are trying to convey is that you need to make your design
agile, flexible, and highly available while delivering the necessary performance
requirements. There are more places for smaller virtual machines to fit and schedule
than there are for very large virtual machines.
The reason customers end up with a design featuring relatively smaller virtual machines
running only one instance and many databases behind it is to take advantage of the scale-
