Database Reference
In-Depth Information
Figure 6.15 The IO Blender Effect.
This is an important concept to understand because you will need to size your storage to
be able to handle the required number of IOPS with a completely random IO pattern.
Random IO has a higher overhead than sequential IO in most cases, with the exception
of some flash-based storage systems. Subsequent sections of this chapter will discuss
IO workload performance impacts of different physical storage systems in more detail.
SQL Virtual Machine Storage Layout
Now that we have covered the various storage IO controller and virtual disk device
choices, we can put it all together and discuss the design of a logical virtual machine
storage layout. This layout, in turn, supports our SQL Server and Windows design and
will drive the design of our underlying storage devices. We want to take our five key
principles and apply these so our virtual machine storage layout meets the requirements
of our database workloads in the simplest way possible, without compromising SLAs.
The example in Figure 6.16 shows a simple storage layout for a SQL Server VM that
has all of its VMDKs supported by a single underlying data store. You could also have
a number of SQL Server VMs and their VMDKs on the same data store. For
development and test VMs, and where SQL FCI is not used, this may be a suitable
design choice. It would also be suitable for the storage of your SQL Server template
VM. However, it is unlikely to be a suitable choice for high-performance business-
critical production SQL Server databases. The Windows C: drive, application binaries,
 
 
 
Search WWH ::




Custom Search