Database Reference
In-Depth Information
The storage layer is not configured properly.
The storage layer is not sized properly.
The storage layer is not used properly.
Our friends at VMware Support provide facts and figures that show the actual number is
much higher than 80%, which further supports our real-world experience. Now that you
know this fact, do not let this problem happen to you. Break out your storage array
vendor documentation and do a little light reading at the breakfast table.
Beyond reading the vendors' documentation and this topic, there is a whole world of
additional resources out there for you, ranging from industry user groups and technology
conference to websites and blogs. We have identified some of the more relevant sources
of additional information in
Appendix A
,
“
Additional Resources
.
”
The Implementation Plan
Experience has taught us the best way to start down the path of database virtualization is
to have a plan. The development of the plan forces you to connect the many dots needed
to successfully virtualize your production SQL Server databases. When you are
virtualizing a database, it is a whole new infrastructure on which you will be running
your business. There are a number of things you need to consider:
Service-level agreements
Recover point objectives
Recovery time objectives
Maximum time to recover
Maximum tolerable downtime
Baselining the current workload
Baselining the existing vSphere implementation
Estimating growth rates
I/O requirements (I/O per sec, throughput, latency)
Storage options (disk type/speed, RAID, flash cache)
Software versions (vSphere, Windows, SQL Server)
Licensing (may determine architecture)
Workload types (OLTP, Batch, DSS, and so on)
The accounts needed for installation and service accounts
How you will migrate the database
Backup and recovery options
This list is not meant to be a substitute for a real implementation plan. Instead, it is
