Database Reference
In-Depth Information
double-check firmware versions for HBA drivers with your hardware vendors.
Another purpose of the CoE is for it to be leveraged during a database-migration
project. Where we have seen this work successfully is when a migration plan has been
put in place and the CoE is used to work through the migration plan. For example, as the
DBAs complete their analysis of a database and determine its requirements for the
virtual world, they bring these requirements to a CoE meeting. The network
administrators will verify the network is configured correctly (that is, that the necessary
VLANs are presented to the ESXi hosts). The vSphere administrators will determine if
CPU and RAM capacity is sufficient. The SAN team will review the IOPS and capacity
requirements to determine if they are able to satisfy the database requirements. If at any
point a team raises its hand and says, “Stop, we can't move forward because we do not
have the < insert requirement here > available to meet the database's requirement,” the
migration is put on hold until the issue is resolved. The CoE provides the means for
anticipating and dealing with problems that can delay progress on your projects.
Yes, this does sound simple, even basic, but so many times these simple, basic steps are
bypassed in order to get projects completed. And in the end, they end up costing more
than just the time—often one's reputation takes a hit. Remember, you get one shot to
virtualize these workloads, so slow down, get it right, and become an asset to your
organization, not an expense.
Deployment Design
Now that we have a team in place and everyone is speaking the same language, let's
start looking at the technical aspects of virtualizing SQL Server. We will begin this
section with gaining an understanding of the current environment and then discuss
deployment options. Most of the customers we meet with have existing databases on
physical servers that they want to migrate into their VMware environment.
We are going to start with a simple exercise—understanding the SQL Server workload
types. We will then move on to deployment considerations. We are talking about
deployment considerations in this chapter because if we standardize our deployment
process so that we have a consistent, repeatable process, then we can better predict the
impact of additional SQL workloads on the existing infrastructure. This makes capacity
planning easier. Consistent and repeatable deployments make management and
monitoring of systems easier. When something goes wrong, having a consistent,
repeatable deployment makes troubleshooting easier.
SQL Workload Characterization
When architecting for performance, it's important you first understand the different SQL
Server workload types you may encounter in your environment and the characteristics
 
 
 
Search WWH ::




Custom Search