Virtualizing SQL Server with Vmware®: Doing IT Right

Chapter 6
Architecting for Performance:
Storage
All aspects of architecting your SQL Server Database for performance are important.
Storage is more important than most when compared to the other members of the IT
Food Group family we introduced in Chapter 5, “Architecting for Performance: Design,”
which consists of Disk, CPU, Memory, and Network. Our experience has shown us, and
data from VMware Support validates this belief, that more than 80% of performance
problems in database environments, and especially virtualized environments, are directly
related to storage. Understanding the storage architecture in a virtualized environment
and getting your storage architecture right will have a major impact on your database
performance and the success of your SQL Server virtualization project. Bear in mind as
you work through your storage architecture and this chapter that virtualization is bound
by the laws of physics—it won’t fix bad code or bad database queries. However, if you have
bad code and bad queries, we will make them run as fast as possible.
TIP
Greater than 80% of all problems in a virtualized environment are caused by the storage
in some way, shape, or form.
This chapter first covers the key aspects of storage architecture relevant to both physical
and virtual environments as well as the differences you need to understand when architecting storage, specifically for virtualized SQL Server Databases. Many of the concepts
we discuss will be valid for past versions of SQL Server and even the newest release, SQL
Server 2014.
106
CHAPTER 6
Architecting for Performance: Storage
We provide guidance on what our experience has taught us are important database storage
design principles. We present a top-down approach covering SQL Server Database and
Guest OS Design, Virtual Machine Template Design, followed by VMware vSphere
Hypervisor Storage Design and then down to the physical storage layers, including using
server-side flash acceleration technology to increase performance and provide greater
return on investment. We conclude the chapter by covering one of the biggest IT
trends and its impact on SQL Server. Throughout this chapter, we give you architecture
examples based on real-world projects that you can adapt for your purposes.
When designing your storage architecture for SQL Server, you need to clearly understand
the requirements and have quantitative rather than subjective metrics. Our experience has
taught us to make decisions based on fact and not gut feeling. You will need to benchmark
and baseline your storage performance to clearly understand what is achievable from your
design. Benchmarking and baselining performance are critical to your success, so we’ve
dedicated an entire chapter (Chapter 10, “How to Baseline Your Physical SQL Server
System”) to those topics. In this chapter, we discuss some of the important storage system
component performance aspects that will feed into your benchmarking and baselining
activities.
The Five Key Principles of Database Storage Design
When architecting storage for SQL Server, it’s important to understand a few important
principles. These will help guide your design decisions and help you achieve acceptable
performance both now and in the future. These principles are important because over the
past decade, CPU performance has increased at a much faster pace than storage performance, even while capacity has exploded.
Principle 1: Your database is just an extension of your storage
“Your database is just an extension
of your storage”
Figure 6.1 Quote from Michael Webster, VMworld 2012
The first principle is highlighted in Figure 6.1: that your database is just an extension
of your storage. A database is designed to efficiently and quickly organize, retrieve, and
process large quantities of data to and from storage. So increasing the parallelism of access
The Five Key Principles of Database Storage Design
107
to storage resources at low latency will be an important goal. Later in this chapter, we
cover how to optimize the architecture of your database to maximize its storage performance and parallelism. When you understand this principle, it’s easy to understand why
getting your storage design and performance is so critical to the success of your SQL
Server Database virtualization project.
Principle 2: Performance is more than underlying storage devices
The next key principle is that storage performance is more than just about underlying
storage devices and spindles, although they are very important too. SQL Server storage
performance is multidimensional and is tightly coupled with a number of different system
components, such as the number of data files allocated to the database, the number of
allocated vCPUs, and the amount of memory allocated to the database. This is why we like
to use the term “IT Food Groups,” because it is so important to feed your database the
right balance of these critical resources. This interplay between resources such as CPU,
Memory, and Network and their impact on storage architecture and performance will be
covered in subsequent sections of this chapter.
Principle 3: Size for performance before capacity
“The bitterness of poor performance
lasts long after the sweetness of a cheap
price is forgotten”
Figure 6.2 Quote from Michael Webster, VMworld 2013
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.
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.
108
CHAPTER 6
Architecting for Performance: Storage
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 about
reducing risk and not compromising on SLAs. Virtualize, but without compromise. There
is no need to compromise on predictability of performance, quality of service, availability,
manageability, or response times. Your storage architecture plays a big part in ensuring
your SQL databases will perform as expected. As we said earlier, your database is just an
extension of your storage. We will show you how to optimize your storage design for
manageability without compromising its performance.
Believe it or not, as big of advocates as we are about virtualizing SQL Server, we have told
customers in meetings that now is not the right time for this database to be virtualized.
This has nothing to do with the capability of vSphere or virtualization, but more to do
with the ability of the organization to properly operate critical SQL systems and virtualize
them successfully, or because they are not able or willing to invest appropriately to make
the project a success. If you aren’t willing to take a methodical and careful approach to
virtualization projects for business-critical applications, in a way that increases the chances
of success, then it’s not worth doing. Understand, document, and ensure requirements can
SQL Server Database and Guest OS Storage Design
109
be met through good design and followed by testing and validation. It is worth doing, and
it is worth “Doing It Right!”
Principle 5: Keep it standardized and simple (KISS)
This brings us to the final principle. Having a standardized and simplified design will
allow your environment and databases to be more manageable as the numbers scale
while maintaining acceptable performance (see Principle 4). If you have a small number
of standardized templates that fit the majority of your database requirements and follow
a building-block approach, this is very easy to scale and easy for your database administrators to manage. We’ll use the KISS principle (Keep It Standardized and Simple)
throughout this chapter, even as we dive into the details. Once you’ve made a design
decision, you should standardize on that decision across all your VM templates. Then
when you build from those templates, you’ll know that the settings will always be applied.
SQL Server Database and Guest OS Storage Design
Database and OS
Virtual Machine
Hypervisor
The starting point for any storage architecture for SQL Server Databases is actually with
our last design principle: KISS (Keep It Standardized and Simple). But all of the principles
apply. We will determine the smallest number of templates that are required to virtualize
the majority (95%) of database systems, and anything that falls outside this will be handled
as an exception.
Your first step is to analyze the inventory of the SQL Server Databases that will be virtualized as part of your project (refer to Chapter 4, “Virtualizing SQL Server 2012: Doing
It Right”). From this inventory, you will now put each database and server into a group
with similar-sized databases that have similar requirements. The storage requirements for
all of these existing and new databases, based on their grouping, will be used to define the
storage layouts and architecture for each of the SQL Server Databases, Guest OS, and VM
template.
110
CHAPTER 6
Architecting for Performance: Storage
TIP
If you are virtualizing existing databases, you might consider using a tool such as VMware
Capacity Planner, VMware Application Dependency Planner, Microsoft System Center,
or Microsoft Assessment and Planning Toolkit to produce the inventory. VMware
Capacity Planner and Application Dependency Planner are available from VMware
Professional Services or your preferred VMware partner. When you’re baselining a SQL
Server database, a lot can happen in a minute. We recommend your sample period for
CPU, Memory, and Disk be 15 seconds or less. We recommend you sample T-SQL
every minute.
SQL Server Database File Layout
Database file layout provides an important component of database storage performance.
If you have existing databases that will be virtualized, you or your DBAs will likely have
already developed some practices around the number of database files, the size of database
files, and the database file layout on the file system. If you don’t have these practices
already in place, here we provide you with some guidelines to start with that have proven
successful.
Your SQL Server database has three primary types of files you need to consider when
architecting your storage to ensure optimal performance: data files, transaction log files,
and Temp DB files. Temp DB is a special system database used in certain key operations,
and has a big performance impact on your overall system. The file extensions you’ll see are
.mdf (master data file), .ndf (for secondary data files), and .ldf for transaction log files. We
will go over all of these different file types later in this chapter.
Number of Database Files
First, we need to determine the number of database files. There are two main drivers for
the number of files you will specify. The first driver is the number of vCPUs allocated to
the database, and the second is the total capacity required for the database now and in the
future.
Two design principles come into play here: The parallelism of access to storage should be
maximized by having multiple database files, and storage performance is more than just
the underlying devices. In the case of data files and Temp DB files, they are related to the
number of CPU cores allocated to your database. Table 6.1 provides recommendations
from Microsoft and the authors in relation to file type.
SQL Server Database and Guest OS Storage Design
111
NOTE
It is extremely unlikely you will ever reach the maximum storage capacity limits of
a SQL Server 2012 database system. We will not be covering the maximums here.
We recommend you refer to Microsoft (http://technet.microsoft.com/en-us/library/
ms143432.aspx).
Table 6.1 Number of Data Files and Temp DB Files Per CPU
File Type
Microsoft
Recommended Setting
Author Recommended Setting
Temp DB Data File
1 per CPU core
< 8 vCPU, 1 per vCPU
> 8 vCPU, 8 total (increase
number of files in increments of
four at a time if required)
Max 32
Database Data File
0.25 to 1.0 per file group,
per CPU core
Min 1 per vCPU, max 32
Database Transaction Log File 1
1*
Temp DB Transaction Log File 1
1*
*If Temp DB and Transaction Log are deployed on local SSD or flash storage, especially when using AlwaysOn
Availability Groups, then it is recommended to have an additional copy on SAN.
Microsoft recommends as a best practice that you should configure one Temp DB data
file per CPU core and 0.25 to 1 data file (per file group) per CPU core. Based on our
experience, our recommendation is slightly different.
If your database is allocated eight or fewer vCPUs as a starting point, we recommend you
should configure at least one Temp DB file per vCPU. If your database is allocated more
than eight vCPUs, we recommend you start with eight Temp DB files and increase by lots
of four in the case of performance bottlenecks or capacity dictates.
TIP
Temp DB is very important because it’s extensively utilized by OLTP databases during
index reorg operations, sorts, and joins, as well as for OLAP, DSS, and batch operations,
which often include large sorts and join activity.
112
CHAPTER 6
Architecting for Performance: Storage
We recommend in all cases you configure at least one data file (per file group) per vCPU.
We recommend a maximum of 32 files for Temp DB or per file group for database files
because you’ll start to see diminishing performance returns with large numbers of database
files over and above 16 files. Insufficient number of data files can lead to many writer
processes queuing to update GAM pages. This is known as GAM page contention. The
Global Allocation Map (GAM) tracks which extents have been allocated in each file. GAM
contention would manifest in high PageLatch wait times. For extremely large databases
into the many tens of TB, 32 files of each type should be sufficient.
Updates to GAM pages must be serialized to preserve consistency; therefore, the optimal
way to scale and avoid GAM page contention is to design sufficient data files and ensure
all data files are the same size and have the same amount of data. This ensures that GAM
page updates are equally balanced across data files. Generally, 16 data files for tempdb
and user databases is sufficient. For Very Large Database (VLDB) scenarios, up to 32 can
be considered. See http://blogs.msdn.com/b/sqlserverstorageengine/archive/2009/01/04/
what-is-allocation-bottleneck.aspx.
If you expect your database to grow significantly long term, we would recommend that
you consider configuring more data files up front. The reason we specify at least one file
per CPU is to increase the parallelism of access from CPU to data files, which will reduce
any unnecessary data access bottlenecks and lower latency. This also allows for even data
growth, which will reduce IO hotspots.
CAUTION
Having too few or too many Temp DB files can impact the overall performance of your
database. Our guidance is conservative and aimed to meet the requirements for the
majority of SQL systems. If you start to see performance problems such as higher than
normal query response times or excessive database waits in PAGELATCH_XX, then
you have contention in memory and may need to increase the number of Temp DB
files further and/or implement trace flag 1118 (which we recommend), which prevents
single page allocations. If you see waits in PAGEIOLATCH_XX, then the contention is at
the IO subsystem level. Refer to http://www.sqlskills.com/blogs/paul/a-sql-server-dbamyth-a-day-1230-Temp DB-should-always-have-one-data-file-per-processor-core/ and
Microsoft KB 328551 (http://support.microsoft.com/kb/328551).
SQL Server Database and Guest OS Storage Design
113
TIP
The number of data files and Temp DB files is important enough that Microsoft has two
spots in the Top 10 SQL Server Storage best practices highlighting the number of data
files per CPU. Refer to http://technet.microsoft.com/en-us/library/cc966534.aspx.
NOTE
When you’re determining the number of database files, a vCPU is logically analogous to
a CPU core in a native physical deployment. However, in a native physical environment
without virtualization, each CPU core may also have a hyper-thread. In a virtual environment, each vCPU is a single thread. There is no virtual equivalent of a hyper-thread.
Figure 6.3 shows an example of data files, Temp DB files, and transaction log files
allocated to a SQL Server 2012 Database on a sample system with four vCPU and 32GB
RAM.
SQL Server
datafile1.mdf
datafile2.ndf
datafile3.ndf
datafile4.ndf
4 vCPU, 32 GB RAM
(an example)
tempfile1.mdf
tempfile2.ndf
tempfile3.ndf
tempfile4.ndf
logfile.Idf
templog.Idf
Figure 6.3 SQL Database data file allocation.
NOTE
As Figure 6.3 illustrates, there is only one transaction log file per database and per Temp
DB. Log files are written to sequentially, so there is no benefit in having multiples of
them, unless you exceed the maximum log file size (2TB) between backups. There is a
benefit of having them on very fast and reliable storage, which will be covered later.
This page intentionally left blank
Index
Numbers
virtual network adapters, 100
choosing, 250-251
10Gb Ethernet NICs, 269
traffic types, 101-102
tuning, 252-254
A
addresses (IP), 341-342
ABRTS/s counter, 326
ACID (Atomicity, Consistency,
Isolation, and Durability), 302-303
ActivePerl, 407
ActiveState ActivePerl, 407
adapter count, 95
adapters
CAN (Converged Network Adapter),
276
iSCSI, 276
LSI Logic SAS, 95
physical network adapters, 267-269
PVSCSI, 95
Admission Control, 88
affi nity rules, 358
AGs (Availability Groups), 306-308
alignment of partitions, 128-129
AlwaysOn Availability Groups
configuring, 387-391
creating, 399-405
AlwaysOn Failover Cluster Instance,
125
anti-affi nity rules, 358
Application Dependency Planner, 110
AQLEN, 168
arrays, 98-99
448
atomicity
atomicity, 302-303
vMotion, 296-297
ATS (Atomic Test Set), 99
vSphere App HA, 299-300
Auto Grow, 114-115
vSphere HA, 298-299
availability, 135
vSphere Replication, 300-301
ACID (Atomicity, Consistency,
Isolation, and Durability), 302-303
X-vMotion, 298
Availability Groups (AGs), 306-308
business continuity, 291
Available Mbytes metrics, 321
determining availability
requirements, 287-288
Average Latch Wait Time(ms) metric,
324
disaster recovery, 291-294
Average Wait Time(ms) metric, 324
high availability, 14-16
providing a menu of options, 288-289
RPOs (recovery point objectives), 290
B
RTOs (recovery time objectives), 290
background noise, lack of, 334
sample high availability chart,
308-309
backing up networks, 103
SLAs (service-level agreements), 290
bandwidth, vMotion traffic, 276
SQL Server AlwaysOn Failover
Cluster Instance (FCI), 304-306
baselines
SQL Server Availability Groups
(AGs), 306-308
vSphere high availability
DRS (Distributed Resource
Scheduler), 297
hypervisor availability features,
294-296
Storage DRS, 297
Storage vMotion, 297
vCenter SRM (Site Recovery
Manager), 301
vCHS (vCloud Hybrid Service),
302
vDP (vSphere Data Protection),
300
ballooning, 230-232
baseline performance reports, 332-333
benchmarks, 315-316
developing, 317-318
industry-standard benchmarks,
316
validating performance with, 318
vendor benchmarks, 316-317
common performance traps
blended peaks of multiple
systems, 335
failure to consider SCU (Single
Compute Unit) performance,
335
invalid assumptions, 334
lack of background noise, 334
business case for virtualization
shared core infrastructure
between production and nonproduction, 333-334
vMotion slot sizes of monster
database virtual machines,
336-337
comparing
different processor generations,
330-331
different processor types, 328-330
customer deployments, 71
database workload, 48-50
explained, 311-314
metrics
ESXTOP counters, 325-327
SQL Server baseline
infrastructure metrics, 321-322
SQL Server Perfmon counters,
323-324
SQL Server Profiler counters,
324-325
non-production workload influences
on performance, 331-332
reasons for, 319-320
benchmark model based
on system nonfunctional
requirements, 317
industry-standard benchmarks, 316
validating performance with, 318
vendor benchmarks, 316-317
BIOS settings, 12-13
blended peaks of multiple systems, 335
blocks, Pointer Block Eviction Process,
163-164
blogs, 444
Thomas LaRock’s blog, 445
vLaunchPad, 444-445
breaking down large pages, 238-239
buffer
Buffer Cache, 49
Buffer Cache Hit Ratio, 50, 323
Buffer Manager, 323
Buffer Pool, 129-130, 219-220
built-in in-memory, 246-247
business case for virtualization, 9
BIOS settings, 12-13
validating performance with, 318
DBA (database administrator)
advantages, 10-11
vSphere infrastructure, 46-48
hardware refresh, 20-22
when to record, 320
high availability, 14-16
Batch Requests/sec metric, 324
large databases, 22-23
Batch/ETL (Extract Transform Load)
workloads, 64
performance, 16-17
benchmarks, 315-316
developing
benchmark model based
on recorded production
performance, 318
449
provisioning/DBaaS, 17-20
database tiering, 19-20
shared environments, 20
reduced expenses, 9-10
SLAs (service level agreements), 11-12
business continuity
450
business continuity, 291
business transparency, 73
Bytes Total/sec metric, 322
WSFC (Windows Server Failover
Clustering), 304
CMDS/s counter, 326
CoE (Center of Excellence), 61-63
Column Storage, 134-135
C
commands, SP_Configure, 246
communication, 58-59
cache
Buffer Cache, 49
communication responsiveness, 253
Buffer Cache Hit Ratio, 50, 323
mutual understanding, 59-60
CACHEUSED counter, 326
responsibility domains, 60-61
Fusion-io ioTurbine, 201-203
vRFC (vSphere Flash Read Cache),
199-201
CACHEUSED counter, 326
comparing performance baselines, 328
different processor generations,
330-331
different processor types, 328-330
CAN (Converged Network Adapter),
276
Complete page (SQL Server
installation), 387
capacity, one-to-one relationships and
unused capacity, 38-40
compression, 133
Center of Excellence (CoE), 61-63
charge back, 73
“check it before you wreck it” rule, 36
choosing virtual network adapters,
250-251
cloud, vCHS (vCloud Hybrid Service),
302
compromise, virtualization without,
108-109
computer names, requirements for
performance testing, 341-342
configuration
AlwaysOn Availability Groups,
387-391
Cluster Validation Wizard, 363-364
Hot-Add Memory and Hot-Add
CPU, 356-358
clusters
jumbo frames, 259-262, 393-394
failover cluster instance storage
layout, 157
max/min memory, 392
vSphere 5.5 failover clustering
environments, 185-186
performance test labs, 342
Windows Failover Clustering
configuring, 359-368
quorum mode, 369-374
validating, 368
Max Server Memory, 236-237
performance tests, 339-340
affi nity and anti-affi nity rules,
358
AlwaysOn Availability Groups
configuration, 387-391
database availability
AlwaysOn Availability Groups
creation, 399-405
consistency, 302-303
computer name/IP address
requirements, 341-342
continuity (business), 291
Dell DVD Store installation and
configuration, 406-430
Dell DVD Store load test,
430-436
Hot-Add Memory and Hot-Add
CPU, 356-358
consolidations, 53, 68
controllers, virtual storage, 138-143
Converged Network Adapter (CAN),
276
Cores per Socket, 83
counters
ESXTOP, 325-327
Perfmon, 50, 323-324
jumbo frame configuration,
393-394
max/min memory configuration,
392
Profiler, 324-325
CPUs, 74-76
CPU Scheduler, 86
memory reservations, 355
hot-add CPUs, 3-4
multiple tempdb files, 394-395
CPU Scheduler, 86
network connection validation,
359
Create Cluster Wizard, 366
performance test lab setup,
342-345
CrossSubnetThreshold, 255
software requirements, 341
SQL Server 2012 installation,
374-387
CrossSubnetDelay, 255
%CSTP counter, 326
customer deployment baselines, 71
test database creation, 396-398
D
VMDK file configuration,
345-354
DaaS (Database as a Service), 73
Windows Failover Clustering
configuration, 359-368
and database virtualization, 17-20
Darwin, Charles, 1-3
Windows Failover Clustering
quorum mode, 369-374
database administrators. See DBAs
Windows Failover Clustering
validation, 368
database availability, 287
trace flags, 215
Configure Cluster Quorum Wizard,
370-374
451
Database as a Service. See DaaS
ACID (Atomicity, Consistency,
Isolation, and Durability), 302-303
business continuity, 291
determining availability
requirements, 287-288
452
database availability
disaster recovery, 291-294
database files
providing a menu of options, 288-289
file system layout, 110-122
RPOs (recovery point objectives), 290
data files, 123-126
RTOs (recovery time objectives), 290
log files, 123-126
sample high availability chart,
308-309
NTFS file system allocation unit
size, 126-127
SLAs (service-level agreements), 290
OS, application binaries, and page
file, 122
SQL Server AlwaysOn Availability
Groups (AGs), 306-308
SQL Server AlwaysOn Failover
Cluster Instance (FCI), 304-306
vSphere high availability
DRS (Distributed Resource
Scheduler), 297
hypervisor availability features,
294-296
Storage DRS, 297
Storage vMotion, 297
vCenter SRM (Site Recovery
Manager), 301
vCHS (vCloud Hybrid Service),
302
vDP (vSphere Data Protection),
300
vMotion, 296-297
partition alignment, 128-129
Temp DB files, 123-126
Instant File Initialization (IFI),
120-122
number of, 110-113
size of, 114-116
data files, 116
Temp DB files, 116
transaction log file sizing, 117-120
database indexes, 222-225
database installation guidelines, 32-36
database instances, number of, 244-245
database metrics, 324
database pages
explained, 219-220
large pages
vSphere HA, 298-299
breaking down into default page
size, 238-239
vSphere Replication, 300-301
explained, 237-238
X-vMotion, 298
locking pages in memory, 239-241
vSphere App HA, 299-300
database availability design, 135
paging, 220-221
database buffer pool, 219-220
swapping, 220-221
database consolidations, 53
TPS (transparent page sharing),
228-229
Database Engine Configuration page
(SQL Server installation), 382
design
database statistics, updating, 130-132
with maintenance plan, 131-132
with trace flag 2371, 131
database storage. See storage
database tiering, 19-20
database virtualization. See
virtualization
default queue depth (QLogic HBA), 166
Dell DVD Store, 327
installing and configuring, 406-430
load test, 430-436
Dell DVD Store Custom Install
Wizard, 408
Denneman, Frank, 444
database workload, baselining, 48-50
deployment, 54, 63
Data Compression, 133
design
data files
453
deployment, 54, 63
file system layout, 123-126
networks. See network design
sizing, 116
server-side flash acceleration, 198-199
data protection (vDP), 300
Fusion-io ioTurbine, 201-203
data stores
PernixData FVP, 204-206
number of, 165-169
virtual disks per data store, 170-173
DAVG/cmd counter, 326
DAVG/cmd metric, 48
DBA Guide to Databases on VMware
(white paper), 439
DBAs (database administrators)
business case for virtualization, 10-11
BIOS settings, 12-13
hardware refresh, 20-22
high availability, 14-16
large databases, 22-23
performance, 16-17
provisioning/DBaaS, 17-20
SLAs (service level agreements),
11-12
SLAs (service level agreements), 11-12
Decision Support System. See DSS
workload
vSphere Flash Read Cache
(vFRC), 199-201
SQL Server database and guest OS
storage, 109
Buffer Pool, 129-130
Column Storage, 134-135
database availability, 135
database statistics, updating,
130-132
Data Compression, 133
file system layout, 110, 122-129
Instant File Initialization (IFI),
120-122
number of database files, 110-113
size of database fi les, 114-120
Storage Spaces, 136
Volume Managers, 136
SQL Server on hyperconverged
infrastructure, 207-213
454
design
SQL Server virtual machine storage,
136
expanding, 158-159
Jumbo VMDKs, 159-164
layout, 152-157
virtual disk devices, 143-152
determining availability requirements,
287-288
developing benchmarks
benchmark model based on recorded
production performance, 318
benchmark model based on system
nonfunctional requirements, 317
virtual storage controllers,
138-143
disaster recovery, 291-294
VM hardware version, 137
discovery, 53
storage design principles
Disk Management utility, 352
database as extension of storage,
106
Disk Space Requirements page (SQL
Server installation), 382
KISS principle (Keep It
Standardized and Simple), 109
disks
disk layout, 95
performance and underlying
storage devices, 107
Disk Management utility, 352
sizing for performance before
capacity, 107-108
RAID (Redundant Array of
Independent Disks)
virtualization without
compromise, 108-109
vSphere storage, 164
multipathing, 184-185
number of data stores and data
store queues, 165-169
number of virtual disks per data
store, 170-173
RAID (Redundant Array of
Independent Disks), 187-197
storage DRS, 177-183
Storage IO Control (SIOC),
173-177
storage policies, 177-183
vSphere 5.5 failover clustering
environments, 185-186
enterprise flash disks (EFDs), 195-197
economics of RAID performance,
194-197
IO penalties, 189-194
randomness of IO pattern,
187-188
read/write bias, 188
virtual disk devices, 143
IO blender effect, 151-152
Raw Device Map (RDM),
149-151
Thick Eager Zero disks, 147-148
Thin versus Thick Lazy Zero
disks, 144-146
Distributed Resource Scheduler (DRS),
297
distributed switches, 263
distributed virtual switches, 100
file system layout
documentation
455
ESXTOP counters, 325-327
online resources, 437-440
ETL (Extract Transform Load), 64
reading, 43-44
dozing, 13
expanding SQL virtual machine storage
layout, 158-159
DQLEN, 168
expenses, reducing, 9-10
DRaaS, 293-294
drivers (PVSCSI), 31
F
%DRPPX counter, 327
%DRPTX counter, 327
DRS (Distributed Resource Scheduler),
297
DSS (Decision Support System)
workload, 64
Facebook groups, 443
Failover Cluster Instance (FCI), 98,
304-306
Failover Cluster Manager, 362
Failover Clustering
durability, 302-303
configuring, 359-368
dynamic threshold for automatic
statistics update, 131
Failover Cluster Instance (FCI), 98,
304-306
Failover Cluster Manager, 362
E
failover clustering environments,
185-186
E1000 adapters, 250-252
network settings, 254-256
E1000E adapters, 250-252
network teaming, 270-273
economics of RAID performance,
194-197
quorum mode, 369-374
education, 60
validating, 368
EFDs (enterprise flash disks), 195-197
Effects of Min and Max Server Memory
(article), 235
storage layout, 157
FCI (Failover Cluster Instance), 98,
304-306
enabling. See configuration
Feature Selection page (SQL Server
installation), 379
encapsulation, 28
file system layout, 110-122
enterprise flash disks (EFDs), 195-197
data files, 123-126
Epping, Duncan, 444
log files, 123-126
Error Reporting page (SQL Server
installation), 385
NTFS file system allocation unit size,
126-127
ESXi host swap fi le location, 78
456
file system layout
OS, application binaries, and page
file, 122
Flash Virtualization Platform (FVP),
204-206
partition alignment, 128-129
frames
Temp DB files, 123-126
jumbo frames, 256-259
files
configuring, 259-262, 393-394
database files
Instant File Initialization (IFI),
120-122
testing, 262-264
pause frames, 268
number of, 110-113
Free System Page Table Entries metric,
321
size of, 114-120
full virtualization, importance of, 36-38
file system layout, 110-122
Fusion-io ioTurbine, 201-203
data files, 123-126
Fusion-io ioTurbine Profiler, 203
log files, 123-126
FVP (Flash Virtualization Platform),
204-206
NTFS file system allocation unit
size, 126-127
OS, application binaries, and page
file, 122
G
partition alignment, 128-129
Gage, John, 281
Temp DB files, 123-126
multiple tempdb files, 394-395
GAVG/cmd for NFS Datastores
counter, 326
VLFs (Virtual Log Files), 118-120
General Statistics, 324
VMDK files, configuring
GPT (GUID Partition Table), 136
inside guest operating system,
352-354
on virtual machines, 345-351
vswap, memory reservations and,
233-234
vswp files, 88
flash, server-side flash acceleration,
198-199
Fusion-io ioTurbine, 201-203
PernixData FVP, 204-206
vSphere Flash Read Cache (vFRC),
199-201
Gray, Jim, 302-303
groups
AlwaysOn Availability Groups
configuring, 387-391
creating, 399-405
database groups, 69
user groups
Facebook groups, 443
PASS (Professional Association of
SQL Server), 441-442
help
VMUG (VMware Users Group),
440
H
VMWare Community, 442-443
HA (high availability)
guest OS storage, 27, 109
Buffer Pool, 129-130
Column Storage, 134-135
database availability, 135
database statistics, updating, 130-132
with maintenance plan, 131-132
with trace flag 2371, 131
Data Compression, 133
file system layout, 110, 122
data files, 123-126
log files, 123-126
457
ACID (Atomicity, Consistency,
Isolation, and Durability), 302-303
DRS (Distributed Resource
Scheduler), 297
hypervisor availability features,
294-296
sample high availability chart,
308-309
SQL Server AlwaysOn Availability
Groups (AGs), 306-308
SQL Server AlwaysOn Failover
Cluster Instance (FCI), 304-306
NTFS file system allocation unit
size, 126-127
Storage DRS, 297
OS, application binaries, and page
file, 122
vCenter SRM (Site Recovery
Manager), 301
partition alignment, 128-129
vCHS (vCloud Hybrid Service), 302
Temp DB files, 123-126
vDP (vSphere Data Protection), 300
Storage vMotion, 297
Instant File Initialization (IFI),
120-122
vMotion, 296-297
number of database files, 110-112
vSphere HA, 298-299
size of database fi les, 114-116
vSphere Replication, 300-301
data file sizing, 116
vSphere App HA, 299-300
X-vMotion, 298
Temp DB file sizing, 116
hardware. See physical hardware
transaction log file sizing, 117-120
hardware independence, 28
Storage Spaces, 136
VMDK file configuration in, 352-354
hardware refresh and database
virtualization, 20-22
Volume Managers, 136
Heap size, 160-162
GUID Partition Table (GPT), 136
heartbeat vNICs, 256
help. See resources
458
high availability
high availability. See HA (high
availability)
one-to-many relationships, 40
one-to-one relationships and unused
capacity, 38-40
high-level virtualization implementation
plan, 50-51
paravirtualization, 29
phase 1: requirements gathering,
51-52
PVSCSI (paravirtual SCSI driver), 31
Type-1 hypervisors, 30
phase 2: discovery, 53
Type-2 hypervisors, 31
phase 2.1: database consolidations, 53
virtualized database installation
guidelines, 32-36
phase 3: infrastructure adjustments,
53
VMs (virtual machines), 28
phase 4: validation and testing, 54
VMware ESXi versions, 40-41
phase 5: migration and deployment,
54
phase 6: monitoring and
management, 54
Hirt, Allan, 445
Hogan, Cormac, 445
host-local swap, 78
host memory, 225-226
host <servername> CPU% value, 434
Hot-Add CPU, 3-4, 356-358
Hot-Add Memory, 4-5, 356-358
HTT (Hyper-Threading Technology),
85-87
hyperconverged infrastructure, 207-213,
280
Hyper-Threading Technology (HTT),
85-87
Hyperic, 343-345
hypervisor, 25
availability features, 294-296
compared to OS, 26-27
explained, 25-27
importance of full virtualization,
36-38
VMXNET3, 32
I
IFI (Instant File Initialization), 120-122
ILM (information life cycle
management), 207
implementation plans
database workload baselines, 48-50
high-level plan, 50-51
items to consider, 44-45
phase 1: requirements gathering,
51-52
phase 2: discovery, 53
phase 2.1: database consolidations, 53
phase 3: infrastructure adjustments,
53
phase 4: validation and testing, 54
phase 5: migration and deployment,
54
phase 6: monitoring and
management, 54
Jumbo VMDKs
RPOs (recovery point objectives),
45-46
459
Server Configuration page, 382
Setup Role page, 379
RTOs (recovery time objectives),
45-46
virtualized database installation
guidelines, 32-36
SLAs (service-level agreements),
45-46
Installation Configuration Rules page
(SQL Server installation), 385
vSphere infrastructure baselines,
46-48
Installation Rules page (SQL Server
installation), 380
Independent Persistent (SQL FCI), 157
indexes (database), 222-225
Instance Configuration page (SQL
Server installation), 380
industry-standard benchmarks, 316
Instant File Initialization (IFI), 120-122
information life cycle management
(ILM), 207
invalid assumptions, 334
Infrastructure Navigator, 343-344
IOBlazer, 327
initialization, Instant File Initialization
(IFI), 120-122
IOMeter, 142-143, 327
installation. See also configuration
Dell DVD Store, 406-430
SQL Server 2012, 374-377, 384-387
Complete page, 387
IO blender effect, 151-152
ioTurbine (Fusion-io), 201-203
ioTurbine Profiler (Fusion-io), 203
IP addresses, requirements for
performance testing, 342
iSCSI
Database Engine Configuration
page, 382
Disk Space Requirements page,
382
adapters, 276
port binding, 281
isolation, 28, 302-303
Feature Selection page, 379
Installation Configuration Rules
page, 385
Installation Rules page, 380
Instance Configuration page, 380
License Terms page, 377
prefl ight check, 375
Product Key page, 375
Ready to Install page, 385
J
jumbo frames, 256-259
configuring, 259-262, 393-394
testing, 262-264
Jumbo VMDKs, 159
Pointer Block Eviction Process,
163-164
VMFS Heap size considerations,
160-162
460
KAVG/cmd counter
Leaf-Spine network architecture, 273
K
licenses
KAVG/cmd counter, 326
Keep It Standardized and Simple
(KISS), 109
KISS principle (Keep It Standardized
and Simple), 109
Klee, David, 445
License Terms page (SQL Server
installation), 377
VMware vCloud Suite licenses, 285
load test (Dell DVD Store), 430-436
locking pages in memory, 92, 239-241
locks, 324
log files
L
file system layout, 123-126
LACP, 273
Lam, William, 444
large databases and database
virtualization, 22-23
large pages, 79
breaking down into default page size,
238-239
sizing, 117-120
Log Flush Wait Time, 324
Log Flush Waits/sec, 324
LogicalDisk(*): Avg Disk Sec/Read, 322
LogicalDisk(*): Avg. Disk Sec/Write,
322
LogicalDisk Disk Bytes/sec, 321
explained, 237-238
Logins/sec, 324
locking pages in memory, 239-241
Logout/sec, 324
LaRock, Thomas, 445
Lowe, Scott, 445
latches, 324
LSI Logic SAS, 95, 137-142
layout
LUN queue depth, 167
file system layout, 110
data files, 123-126
M
log files, 123-126
NTFS file system allocation unit
size, 126-127
OS, application binaries, and page
file, 122
maintenance plans, updating database
statistics with, 131-132
Maintenance Plan Wizard, 420-422
management, 54
partition alignment, 128-129
Max Server Memory, 234-236
Temp DB files, 123-126
MaxAddressableSpaceTB, 163-164
virtual machine storage layout,
152-157
maximum memory, configuring, 392
maximum storage capacity limits, 111
MbRX/s counter, 327
metrics
MbTx/s counter, 327
paging, 220-221
MCTLSZ (MB) counter, 47-48, 326
swapping, 220-221
memory
Buffer Pool, 129-130
cache
Buffer Cache, 49
Buffer Cache Hit Ratio, 50, 323
CACHEUSED counter, 326
Fusion-io ioTurbine, 201-203
vRFC (vSphere Flash Read
Cache), 199-201
461
min/max memory, configuring, 392
mixed workload environment with
memory reservations, 226-228
NUMA (Non-uniform Memory
Access)
explained, 241-243
vNUMA, 243
overview, 76, 217-218
RAM, 87
host memory, 225-226
shared-resource world, 246
hot-add memory, 4-5
SQL Server 2014 in-memory, 246-247
large pages
SQL Server Max Server Memory,
234-236
breaking down into default page
size, 238-239
SQL Server Min Server Memory, 235
explained, 237-238
TPS (transparent page sharing), 228
locking pages in memory, 239-241
VMs (virtual machines), 225-226
memory ballooning, 230-232
number of, 244-245
Memory Grants Pending, 324
sizing, 244
Memory Manager, 324
memory overcommitment, 87
memory reservation, 355
explained, 232-233
mixed workload environment
with memory reservations,
226-228
VMware HA strict admission
control, 233
vswap file, 233-234
memory trends and the stack, 218
database buffer pool, 219-220
database indexes, 222-225
database pages, 219-221
vRFC (vSphere Flash Read Cache),
199-201
xVelocity memory, 134
Memory Grants Pending, 324
Memory Manager, 324
metrics
baseline metrics
ESXTOP counters, 325-327
SQL Server baseline
infrastructure metrics, 321-322
SQL Server Perfmon counters,
323-324
SQL Server Profiler counters,
324-325
462
metrics
Buffer Cache Hit Ratio, 50
N
Cache Hit Ratio, 50
DAVG/cmd, 48
MCTLSZ, 47-48
%MLMTD, 47-48
%RDY, 47
READs/s, 47-48
storage-specific metrics, 94
Microsoft Assessment and Planning
Toolkit, 110
“Microsoft Clustering on VMware
vSphere: Guidelines for Supported
Configurations,” 345
National Institute of Standards and
Technology (NIST), 291
n_browse_overall value, 433
NDFS (Nutanix Distributed File
System), 207
network connections, validating, 359
network design, 264
Multi-NIC vMotion, 276-278
NIOC (Network IO Control), 101,
274-276
physical network adapters, 267-269
Microsoft System Center, 110
storage, 279-280
migration, 54
teaming and failover, 270-273
Min Server Memory, 235
virtual switches, 265-267
minimum memory, configuring, 392
mixed workload environment with
memory reservations, 226-228
Network IO Control (NIOC), 101,
274-276
network paths, verifying, 262
MLAG (Multi-Link Aggregation
Group), 273
network security, 103, 281-284
%MLMTD metric, 47-48
network virtualization, 281-284
models (benchmark workload)
New Availability Group Wizard,
399-405
based on recorded production
performance, 318
based on system nonfunctional
requirements, 317
monitoring, 54
network teaming, 270-273
NIOC (Network IO Control), 101,
274-276
NIST (National Institute of Standards
and Technology), 291
Multi-Link Aggregation Group
(MLAG), 273
N%L counter, 326
Multi-NIC vMotion, 276-278
non-production workload influences on
performance, 331-332
multipathing of storage paths, 184-185,
280
multiple tempdb files, creating, 394-395
n_newcust_overall value, 433
non-shared disks, 345
non-uniform memory architecture.
See NUMA
penalties (RAID IO)
n_overall value, 432
463
OSs (operating systems)
n_purchase_from_start value, 434
application binaries, and page file, 122
n_purchase_overall value, 433
compared to hypervisor, 26-27
n_rollbacks_from_start value, 434
guest operating systems, 27
n_rollbacks_overall value, 434
NTFS allocation unit size, 126-127
NUMA (non-uniform memory
architecture), 79-85
P
PAGEIOLATCH, 124
explained, 241-243
PAGELATCH_XX, 112
NUMA Scheduler, 81
Page Life Expectancy metric, 323
vNUMA, 82, 243
pages
Wide NUMA, 81
NUMA Scheduler, 81
Nutanix Bible (Poitras), 210
Nutanix Distributed File System
(NDFS), 207
Nutanix Virtual Computing Platform,
207-213
explained, 219-220
large pages
breaking down into default page
size, 238-239
explained, 237-238
locking pages in memory, 239-241
paging, 78, 220-221
swapping, 78, 220-221
O
TPS (transparent page sharing),
228-229
OLAP (Online Analytical Processing),
64
Pages/Sec metrics, 321
OLTP (Online Transaction Processing),
64
Paging File(_Total): %Usage metric, 321
one-to-many relationships, 40
one-to-one relationships and unused
capacity, 38-40
Online Analytical Processing (OLAP),
64
paging, 78, 220-221
parallelism of storage design, 106
paravirtualization, 29
Paravirtualized SCSI (PVSCI), 31, 95,
137-141
partition alignment, 128-129
Online Transaction Processing (OLTP),
64
partitioning, 28
operating systems. See OSs
pause frames, 268
opm value, 432
penalties (RAID IO), 189-194
patches, 68
464
Perfmon counters
Perfmon counters, 50, 323-324
performance baselines, 311-315
baseline performance reports, 332-333
benchmarks, 315
developing, 317-318
industry-standard benchmarks,
316
validating performance with, 318
vendor benchmarks, 316-317
comparing, 319-327
different processor generations,
330-331
different processor types, 328-330
common performance traps
blended peaks of multiple
systems, 335
failure to consider SCU (Single
Compute Unit) performance,
335
invalid assumptions, 334
lack of background noise, 334
shared core infrastructure
between production and nonproduction, 333-334
vMotion slot sizes of monster
database virtual machines,
336-337
SQL Server Profiler counters,
324-325
non-production workload influences
on performance, 331-332
server-side flash acceleration, 198-199
Fusion-io ioTurbine, 201-203
PernixData FVP, 204-206
vSphere Flash Read Cache
(vFRC), 199-201
storage
KISS principle (Keep It
Standardized and Simple), 109
performance and underlying
storage devices, 107
sizing for performance before
capacity, 107-108
virtualization without
compromise, 108-109
validating performance with, 318
vSphere storage design, 164
multipathing, 184-185
number of data stores and data
store queues, 165-169
number of virtual disks per data
store, 170-173
RAID (Redundant Array of
Independent Disks), 187-197
and database virtualization, 16-17
storage DRS, 177-183
metrics
Storage IO Control (SIOC),
173-177
ESXTOP counters, 325-327
SQL Server baseline
infrastructure metrics, 321-322
SQL Server Perfmon counters,
323-324
storage policies, 177-183
vSphere 5.5 failover clustering
environments, 185-186
when to record, 320
PernixData FVP Datasheet
performance tests, 339
465
Installation Rules page, 380
affi nity and anti-affi nity rules, 358
Instance Configuration page, 380
AlwaysOn Availability Groups
configuration, 387-391
License Terms page, 377
AlwaysOn Availability Groups
creation, 399-405
Product Key page, 375
Dell DVD Store installation and
configuration, 406-430
Server Configuration page, 382
Dell DVD Store load test, 430-436
Hot-Add Memory and Hot-Add
CPU, 356-358
jumbo frame configuration, 393-394
lab configuration, 342-345
max/min memory configuration, 392
memory reservations, 355
multiple tempdb files, 394-395
prefl ight check, 375
Ready to Install page, 385
Setup Role page, 379
test database creation, 396-398
VMDK file configuration
inside guest operating system,
352-354
on virtual machines, 345-351
Windows Failover Clustering
configuration, 359-368
network connection validation, 359
Windows Failover Clustering
quorum mode, 369-374
reasons for performance testing,
339-340
Windows Failover Clustering
validation, 368
requirements
performance traps
computer names and IP
addresses, 341-342
blended peaks of multiple systems,
335
resources, 342
failure to consider SCU (Single
Compute Unit) performance, 335
software, 341
SQL Server 2012 installation,
374-377, 384-387
Complete page, 387
invalid assumptions, 334
lack of background noise, 334
Database Engine Configuration
page, 382
shared core infrastructure between
production and non-production,
333-334
Disk Space Requirements page,
382
vMotion slot sizes of monster
database virtual machines, 336-337
Error Reporting page, 385
PernixData FVP, 204-206
Feature Selection page, 379
PernixData FVP Datasheet, 205
Installation Configuration Rules
page, 385
466
phases of virtualization implementation
phases of virtualization implementation
file size, 100
database consolidations, 53
provisioning types, 96-98
discovery, 53
versus RDM, 96
infrastructure adjustments, 53
Physical Mode RDMs (pRDM), 159
migration and deployment, 54
physical network adapters, 267-269
monitoring and management, 54
PKTRX/s counter, 327
requirements gathering, 51-52
PKTTX/s counter, 327
validation and testing, 54
plans. See implementation plans
physical hardware, 73
Pointer Block Eviction Process, 163-164
adapter count, 95
Poitras, Steven, 210
CPUs, 74-76
policies (storage), 177-183
data stores, 99
pool, database buffer, 219-220
disk layout, 95
port groups, 265
hardware compatibility, 62
power management policies, 253
HTT (Hyper-Threading
Technology), 85-87
pRDM (Physical Mode RDMs), 159
large pages, 79
LSI Logic SAS adapters, 95
memory, 76
memory overcommitment, 87
processors baseline comparisons
between different processor
generations, 330
between different processor types,
328-330
NUMA (non-uniform memory
architecture), 79-85
Processor(_Total):Privileged Time
metric, 321
PVSCSI adapters, 95
Processor(_Total)[metric] Processor
Time metric, 321
reservations, 87-89
SQL Server Lock Pages in Memory,
92
SQL Server Min Server Memory/
Max Server Memory, 90-91
storage, 93
storage-specific metrics, 94
Product Key page (SQL Server
installation), 375
Product Updates page (SQL Server
installation), 377
Professional Association of SQL Server
(PASS)
swapping files, 78
PASS—Virtualization Virtual
Chapter, 441
Thin Provisioning, 98-99
PASS SQLSaturday, 441-442
virtualization overhead, 76-77
VMDKs, 99
reservation (memory)
Profiler counters, 324-325
reading documentation, 43-44
protocols, 279-280
READs/s counter, 47-48, 326
provisioning
read/write bias, 188
and database virtualization, 17-20
VMDK, 96-98
PVSCSI (Paravirtualized SCSI), 31, 95,
137-141
467
Ready to Install page (SQL Server
installation), 385
recovery
disaster recovery, 291-294
recovery point objectives (RPOs),
45-46, 290
Q
QFULL SCSI sense code, 166
QLogic HBA, 166
QoS, 102-103
Query Plan Optimizer, 130
queues, data store, 165-169
quorum mode (Failover Clustering),
369-374
recovery time objectives (RTOs),
45-46, 290
vCenter SRM (Site Recovery
Manager), 301
recovery point objectives (RPOs), 45-46,
290
recovery time objectives (RTOs), 45-46,
290
reducing expenses, 9-10
Redundant Array of Independent Disks.
See RAID
R
relationships
RAID (Redundant Array of
Independent Disks), 187
one-to-many relationships, 40
one-to-one relationships, 38-40
economics of RAID performance,
194-197
reorganizing SQL workloads, 68-69
IO penalties, 189-194
replication (vSphere), 300-301
randomness of IO pattern, 187-188
reports (performance), 332-333
read/write bias, 188
requirements gathering, 51-52
RAM, 87
reservation (memory), 87-89, 355
randomness of IO pattern, 187-188
explained, 232-233
Raw Device Map (RDM), 149-151
mixed workload environment with
memory reservations, 226-228
RDM (Raw Device Map), 149-151
versus VMDK, 96
%RDY counter, 47, 325
VMware HA strict admission control,
233
vswap file, 233-234
RESETS/s counter
468
RESETS/s counter, 327
S
resource pools, Network IO Control,
275
SameSubnetDelay, 255
resources
SameSubnetThreshold, 255
blogs
Thomas LaRockTs blog, 445
vLaunchPad, 444-445
documentation and white papers,
437-440
Twitter, 445-446
user groups, 440
Facebook groups, 443
PASS (Professional Association of
SQL Server), 441-442
sample high availability chart, 308-309
SAP
benchmark examples between
different processor generations,
330-331
benchmark examples between
different processor types, 328-330
Data Compression with, 133
SCU (Single Compute Unit), 335
security, 281-284
VMUG (VMware Users Group),
440
Server Configuration page (SQL Server
installation), 382
VMWare Community, 442-443
server-side flash acceleration, 198-199
responsibility domains, 60-61
Fusion-io ioTurbine, 201-203
rollback_rate value, 434
PernixData FVP, 204-206
Route Based on Physical NIC Load, 271
vSphere Flash Read Cache (vFRC),
199-201
RPOs (recovery point objectives), 45-46,
290
rt_browse_avg_msec value, 433
rt_login_avg_msec value, 433
rt_newcust_avg_msec value, 433
RTOs (recovery time objectives), 45-46,
290
rt_purchase_avg_msec value, 433
rt_tot_avg, 433
service-level agreements (SLAs), 11-12,
45-46, 100, 290
settings (BIOS), 12-13
“Setup for Failover Clustering and
Microsoft Cluster Service” (white
paper), 439
Setup Role page (SQL Server
installation), 379
rt_tot_lastn_max value, 432
shared core infrastructure between
production and non-production,
333-334
rules, affinity/anti-affi nity, 358
shared disks, 345
rt_tot_avg value, 433
shared environments, 20, 35
shared-resource world, 246
stack, memory trends and
SIOC (Storage IO Control), 157, 173-177
Ready to Install page, 385
Site Recovery Manager (SRM), 16, 301
Server Configuration page, 382
sizing
Setup Role page, 379
Heap size, 160-162
database files, 114-116
data file sizing, 116
Temp DB file sizing, 116
transaction log files, 117-120
databases, 22-23
performance before capacity, 107-108
VMs (virtual machines), 244
SQL Server 2014 & The Data Platform
(data sheet), 247
“SQL Server Best Practices” (white
paper), 210
SQL Server Max Server Memory, 90-91
SQL Server Min Server Memory, 90-91
“SQL Server on VMware—Availability
and Recovery Options” (white paper),
439
SLAs (service-level agreements), 11-12,
45-46, 100, 290
“SQL Server on VMware—Best
Practices Guide” (white paper), 439
software requirements for performance
testing, 341
SQL Server SysPrep, 71
SP_Configure command, 246
SQL AlwaysOn Failover Cluster
Instances, 157
SQL Compilations/sec metric, 324
SQL Re-Compilations/sec metric, 324
SQL Server 2012 installation, 374-387
Complete page, 387
469
SQL Statistics, 324
SQL workloads, 64-67
Batch/ETL workloads, 64
DSS workloads, 64
OLAP workloads, 64
OLTP workloads, 64
reorganization, 68-69
tiered database offering, 70-73
Database Engine Configuration page,
382
SQLIOsim, 327
Disk Space Requirements page, 382
SQLSaturday, 441-442
Feature Selection page, 379
SRM (Site Recovery Manager), 16, 301
Installation Configuration Rules
page, 385
stack, memory trends and, 79, 218
database buffer pool, 219-220
Installation Rules page, 380
database indexes, 222-225
Instance Configuration page, 380
database pages, 219-220
License Terms page, 377
paging, 220-221
prefl ight check, 375
swapping, 220-221
Product Key page, 375
storage
470
storage
design principles
SQL Server virtual machine storage,
136
database as extension of storage,
106
expanding, 158-159
KISS principle (Keep It
Standardized and Simple), 109
layout, 152-157
performance and underlying
storage devices, 107
virtual storage controllers,
138-143
sizing for performance before
capacity, 107-108
VM hardware version, 137
virtualization without
compromise, 108-109
overview, 93, 105-106
server-side flash acceleration, 198-199
Fusion-io ioTurbine, 201-203
PernixData FVP, 204-206
vSphere Flash Read Cache
(vFRC), 199-201
SQL Server database and guest OS
storage, 109
Buffer Pool, 129-130
Column Storage, 134-135
database availability, 135
database statistics, updating,
130-132
Data Compression, 133
Jumbo VMDKs, 159-164
virtual disk devices, 143-152
Storage Acceleration, 96
storage arrays, 98
Storage DRS, 177-183, 297
Storage IO Control (SIOC), 157,
173-176
storage networks, 279-280
storage policies, 177-183
storage protocols, 279-280
Storage Spaces, 136
storage-specific metrics, 94vSphere
storage design, 164
multipathing, 184-185
number of data stores and data
store queues, 165-169
number of virtual disks per data
store, 170-173
file system layout, 110, 122-129
RAID (Redundant Array of
Independent Disks), 187-197
Instant File Initialization (IFI),
120-122
storage DRS, 177-183
number of database files, 110-113
Storage IO Control (SIOC),
173-177
size of database fi les, 114-120
storage policies, 177-183
Storage Spaces, 136
vSphere 5.5 failover clustering
environments, 185-186
Volume Managers, 136
SQL Server on hyperconverged
infrastructure, 207-213
Storage Acceleration, 96
Storage DRS, 177-183, 297
testing
Storage IO Control (SIOC), 157, 173-176
test databases, creating, 396-398
Storage Spaces, 136
testing, 54
471
Storage vMotion, 297
baseline. See performance baselines
Strawberry Perl, 406
benchmarks, 315
swap files, 78
developing, 317-318
Swapin counter, 326
Swapout counter, 326
industry-standard benchmarks,
316
swapping, 78, 220-221
vendor benchmarks, 316-317
switches
virtual switches, 265-267
distributed virtual switch, 100
port groups, 265
teaming methods, 270
vSphere distributed switches, 263
vSS, 265
%SWPWT counter, 326
%SYS counter, 325
jumbo frames, 262-264
performance tests, 339
affi nity and anti-affi nity rules,
358
AlwaysOn Availability Groups
configuration, 387-391
AlwaysOn Availability Groups
creation, 399-405
Dell DVD Store installation and
configuration, 406-430
Szastak, Jeff, 311
Dell DVD Store load test,
430-436
T
Hot-Add Memory and Hot-Add
CPU, 356-358
Target Server Memory (KB) metric, 324
jumbo frame configuration,
393-394
TDE (Transparent Data Encryption),
122
teams
Center of Excellence (CoE), 61-63
communication, 58
mutual understanding, 59-60
responsibility domains, 60-61
Temp DB files
lab configuration, 342-345
max/min memory configuration,
392
memory reservations, 355
multiple tempdb files, 394-395
network connection validation,
359
file system layout, 123-126
reasons for performance testing,
339-340
multiple tempdb files, creating,
394-395
requirements, 341-342
sizing, 116
472
testing
SQL Server 2012 installation,
374-387
Transaction Processing Performance
Council (TPC), 316
test database creation, 396-398
translation lookaside buffer (TLB), 79
VMDK file configuration,
345-354
Transactions/sec metric, 324
Windows Failover Clustering
configuration, 359-368
Windows Failover Clustering
quorum mode, 369-374
Windows Failover Clustering
validation, 368
Transparent Data Encryption (TDE),
122
transparent page sharing (TPS), 79,
228-229
troubleshooting common performance
traps
blended peaks of multiple systems,
335
Thick Eager Zero disks, 147-148
Thick Lazy Zero disks, 144-146
Thick Provisioned Eager Zeroed, 97
failure to consider SCU (Single
Compute Unit) performance, 335
Thick Provisioned Lazy Zeroed, 97
invalid assumptions, 334
Thick Provisioned LUNs, 98
lack of background noise, 334
Thin disks, 144-146
shared core infrastructure between
production and non-production,
333-334
Think Provisioned LUNs, 98
Thin Provisioned VMDK, 97-99
vMotion slot sizes of monster
database virtual machines, 336-337
Thin Provisioning, 98-99
tiered database offering, 70-73
tuning virtual network adapters, 252-254
tiers (database), 19-20
Twitter, 445-446
TLB (translation lookaside buffer), 79
Type-1 hypervisors, 30
TPC (Transaction Processing
Performance Council), 316
Type-2 hypervisors, 31
TPS (transparent page sharing), 79,
228-229
U
trace flags
enabling, 215
list of, 215
trace flag 2371, 131
traffic types, 101-102
transaction log files, sizing, 117-120
Understanding Memory Resource
Management in VMware vSphere 5.0
(study), 229-230
“Understanding VMware vSphere 5.1
Storage DRS” (white paper), 182
unused capacity and one-to-one
relationships, 38-40
Virtual Mode RDMs (vRDM)
updating database statistics, 130-132
with maintenance plan, 131-132
with trace flag 2371, 131
473
vDP (vSphere Data Protection), 266, 300
Multi-NIC vMotion, 277
vDS (vSphere distributed switch), 262
%USED counter, 325
vendor benchmarks, 316-317
User Connections metric, 324
verifying network paths, 262
user groups, 440
Virtual Computing Platform (Nutanix),
207-213
Facebook groups, 443
PASS (Professional Association of
SQL Server)
PASS—Virtualization Virtual
Chapter, 441
PASS SQLSaturday, 441-442
VMUG (VMware Users Group), 440
VMWare Community, 442-443
virtual CPUs (vCPUs), 4
virtual disks, number per data store,
170-173
Virtual Log Files (VLFs), 118-120
virtuallyGhetto, 444
virtual machine storage, 136
expanding, 158-159
Jumbo VMDKs, 159
V
Pointer Block Eviction Process,
163-164
VAAI (vStorage APIs for Array
Integration), 96
VMFS Heap size considerations,
160-162
Validate a Configuration Wizard, 364
layout, 152-157
validation, 54
number of VMs, 244-245
cluster network configuration, 368
sizing, 244
network connections, 359
virtual disk devices, 143
performance with baselines/
benchmarks, 318
vCenter Hyperic, 343-345
vCenter Infrastructure Navigator,
343-344
vCenter Operations Manager, 87
IO blender effect, 151-152
Raw Device Map (RDM),
149-151
Thick Eager Zero disks, 147-148
Thin versus Thick Lazy Zero
disks, 144-146
vCenter SRM (Site Recovery Manager),
301
virtual storage controllers, 138-143
vCHS (vCloud Hybrid Service), 302
VM memory, 225-226
vCloud Hybrid Service (vCHS), 302
vCPUs (virtual CPUs), 4
VM hardware version, 137
Virtual Mode RDMs (vRDM), 159
474
virtual network adapters
virtual network adapters, 100
choosing, 250-251
one-to-many relationships, 40
traffic types, 101-102
one-to-one relationships and
unused capacity, 38-40
turning, 252-254
paravirtualization, 29
virtual server access ports, 281
virtual switches, 265-267
distributed virtual switch, 100
port groups, 265
teaming methods, 270
virtualization, 93
advantages of, 3
hot-add CPUs, 3-4
hot-add memory, 4-5
business case for, 9
PVSCSI (paravirtual SCSI
driver), 31
Type-1 hypervisors, 30
Type-2 hypervisors, 31
virtualized database installation
guidelines, 32-36
VMs (virtual machines), 28
VMware ESXi versions, 40-41
VMXNET3, 32
implementation plan
BIOS settings, 12-13
database workload baselines,
48-50
DBA (database administrator)
advantages, 10-11
high-level plan, 50-51
hardware refresh, 20-22
items to consider, 44-45
high availability, 14-16
phase 1: requirements gathering,
51-52
large databases, 22-23
phase 2: discovery, 53
performance, 16-17
phase 2.1: database consolidations,
53
provisioning/DBaaS, 17-20
reduced expenses, 9-10
SLAs (service level agreements),
11-12
and compromise, 108-109
documentation, 43-44
explained, 1-2
hypervisor, 25
compared to OS, 26-27
explained, 25-27
importance of full virtualization,
36-38
phase 3: infrastructure
adjustments, 53
phase 4: validation and testing, 54
phase 5: migration and
deployment, 54
phase 6: monitoring and
management, 54
RPOs (recovery point objectives),
45-46
RTOs (recovery time objectives),
45-46
VMware Site Recovery Manager (SRM)
SLAs (service-level agreements),
45-46
vSphere infrastructure baselines,
46-48
importance of full virtualization,
36-38
overhead, 76-77
performance baselines
baseline performance reports,
332-333
benchmarks, 315-318
common performance traps,
333-337
comparing, 328-331
explained, 311-315
475
VMDKs, 99
files, configuring
file size, 100
inside guest operating system,
352-354
on virtual machines, 345-351
Jumbo VMDKs, 159-160
Pointer Block Eviction Process,
163-164
VMFS Heap size considerations,
160-162
provisioning types, 96-98
versus RDM, 96
virtual machine storage layout,
152-157
metrics, 321-327
VMFS heap size considerations, 160-162
non-production workload
influences on performance,
331-332
vMotion, 296-297
reasons for, 319-320
validating performance with, 318
when to record, 320
slot sizes of monster database virtual
machines, 336-337
traffic, 276
VMs (virtual machines). See virtual
machine storage
power company example, 6
VMUG (VMware Users Group), 440
world before database virtualization,
5-6
%VMWait counter, 326
“Virtualization Overview” (white
paper), 21
virtualized database installation
guidelines, 32-36
virtualized security zones, 283
vLaunchPad, 444-445
VLFs (Virtual Log Files), 118-120
VMware App Director, 70
VMware Capacity Planner, 110
VMWare Community, 442-443
VMware ESXi versions, 40-41
VMware HA strict admission control,
233
VMware NSX, 283
VMware PowerCLI, 253
VMware Site Recovery Manager (SRM),
16
476
VMware vCloud Suite licenses
VMware vCloud Suite licenses, 285
VMware vSphere on Nutanix Best
Practices (white paper), 210
VMXNET 3, 100
VMXNET3, 32, 251, 257
vNIC, 256
vNUMA, 82, 243
Volume Managers, 136
vRAM, 87
vRDM (Virtual Mode RDMs), 159
vRFC (vSphere Flash Read Cache),
199-201
vSphere, 98-99
baselining, 46-48
storage design, 164
multipathing, 184-185
number of data stores and data
store queues, 165-169
number of virtual disks per data
store, 170-173
RAID (Redundant Array of
Independent Disks), 187-197
storage DRS, 177-183
Storage IO Control (SIOC),
173-177
storage policies, 177-183
vSphere 5.5 failover clustering
environments, 185-186
ESXTOP counters, 325-327
vDS (vSphere distributed switch),
262-263
failover clustering environments,
185-186
vFRC (vSphere Flash Read Cache),
199-201
high availability
vNUMA, 243
DRS (Distributed Resource
Scheduler), 297
vSphere App HA, 299-300
hypervisor availability features,
294-296
vSphere Hot Plug Memory, 91
Storage DRS, 297
Storage vMotion, 297
vCenter SRM (Site Recovery
Manager), 301
vCHS (vCloud Hybrid Service),
302
vDP (vSphere Data Protection),
300
vMotion, 296-297
vSphere App HA, 299-300
vSphere HA, 298-299
vSphere Replication, 300-301
X-vMotion, 298
vSphere HA, 298-299
vSphere Replication, 300-301
vSphere Web Client, 260
vSS (vSphere standard switch), 265,
271
“vSphere Monitoring & Performance”
(white paper), 440
“vSphere Resource Management” (white
paper), 440
“vSphere Storage” (white paper), 440
vSphere Web Client, 260
vSS (vSphere standard switch), 265, 271
worlds (VMs)
vStorage APIs for Array Integration
(VAAI), 96
vswap file, memory reservations and,
233-234
477
quorum mode, 369-374
validating, 368
Windows Server Failover Clustering
(WSFC), 304
Windows vNIC properties page, 261
W
wizards
Cluster Validation Wizard, 363-364
Webster, Michael, 106, 170
white papers
“DBA Guide to Databases on
VMware,” 439
“Setup for Failover Clustering and
Microsoft Cluster Service,” 439
“SQL Server Best Practices,” 210
“SQL Server on VMware—
Availability and Recovery Options,”
439
“SQL Server on VMware—Best
Practices Guide,” 439
“Understanding VMware vSphere 5.1
Storage DRS,” 182
“VMware vSphere on Nutanix Best
Practices,” 210
“vSphere Monitoring &
Performance,” 440
“vSphere Resource Management,”
440
“vSphere Storage,” 440
Wide NUMA, 81
Windows Failover Cluster Heartbeat
settings, 255
Windows Failover Clustering
configuring, 359-368
network settings, 254-256
Configure Cluster Quorum Wizard,
370-374
Create Cluster Wizard, 366
Dell DVD Store Custom Install
Wizard, 408
Maintenance Plan Wizard, 420-422
New Availability Group Wizard,
399-405
Validate a Configuration Wizard, 364
Workload Driver Configuration
Wizard, 409
Workload Driver Configuration
Wizard, 409
workloads
based on recorded production
performance, 318
based on system nonfunctional
requirements, 317
baselining, 48-50
mixed workload environment with
memory reservations, 226-228
SQL workloads, 64-67
reorganization, 68-69
tiered database offering, 70-73
worlds (VMs), 86
478
Writes/s counter
Writes/s counter, 326
WSFC (Windows Server Failover
Clustering), 304
X-Y-Z
xVelocity memory, 134
X-vMotion, 298
Yellow-Bricks, 444