Database Reference
In-Depth Information
Figure 6.2
is loosely based on the eighteenth-century quote “The bitterness of poor
quality remains long after the sweetness of low price is forgotten,” by Benjamin
Franklin. Both quotes are extremely relevant to SQL Server database and storage
performance.
Figure 6.2
Quote from Michael Webster, VMworld 2013
This brings us to the next key principle. In order to prevent poor performance from
being a factor in your SQL Server virtualization project (refer to
Figure 6.2
)
, you should
design storage for performance first (IOPS and latency), then capacity will take care of
itself. Capacity is the easy part. We will show you later in this chapter how
compromising on certain storage configurations on the surface can actually cost you a
lot more by causing unusable capacity due to poor performance.
Caution
A lesson from the field: We were working with a customer, and they wanted to
design and run a database on vSphere that could support sustained 20,000 IOPS.
After we worked with the customer's vSphere, SAN, Network, and DBA teams,
the customer decided to move forward with the project. The customer then called
in a panic saying, “In our load test, we achieved 1,000 IOPS. We are 19,000
short of where we need to be.” Trust me, this is a phone call you don't want to
get. Playing the odds, we started with the disk subsystem. We quickly identified
some issues. The main issue was the customer purchased for
capacity
, not
performance
. They had to reorder the right disk. Once the new (right) disk
arrived and was configured, the customer exceeded the 20,000 IOPS requirement.
Tip
When it comes to storage devices, HDDs are cents per GB but dollars per IOP,
whereas SSDs are cents per IOP and dollars per GB. SSDs should be considered
cheap memory, rather than expensive disks, especially when it comes to
enterprise SSDs and PCIe flash devices.
Principle 4: Virtualize, but without compromise
The next principle is that virtualizing business-critical SQL Server databases is all
