Kenneth at 20:30, 26 August 2014

2014-08-26T20:30:07Z

New page

== Virtualizing Databases and Doing It Right ==

<img src="http://3.bp.blogspot.com/-2QgceLKK5vk/U_znId0UcgI/AAAAAAAACzE/GKNBOP9Ou6I/s1600/IMG_20140826_113947.jpg" width="400" />

Book:
* Virtualizing SQL Server with VMware: Doing IT Right - by Michael Corey, Jeff Szastak, Michael Webster

(There was also a book mentioned about Oracle virtualization, but didn't get the name)

Presentation covers Microsoft SQL and Oracle

Microsoft SQL people don't want to talk to Oracle people, and vice a versa - we are going to do it anyway

DBAs shouldn't care about the infrastructure. You don't care about the Cell Phone towers, you just expect them to work.

Number #1 issue that causes BSOD - drivers. With Virtualization, the driver depth is minimized

Virtualization is an incredible return on investment

Able to adjust resources with a click of the button (assuming there are additional shared virtual resources available to add)

If you adjust memory, you will need to restart the database to take advantage

"Any Resource, Any Server, At Any Time" in the (Pool)

Is your database too "Big" to virtualize? - doubt it

Virtualization has about a 5% overhead, but if your setup doesn't have at least 5% wiggle room, you are doing something wrong anyway

Management expectations - need to set correctly, and explain the costs and what it actually will take

If asked to meet an SLA, make sure it can be meet, and set the expectations. If you can't meet it, let management know as soon as possible.

Optimize optimize optimize - the defaults on servers, applications, etc are not tuned for performance

Read the documentation from all vendors!

Professional Association of SQL Server - join it if you are doing SQL Server - http://virtualization.sqlpass.org/

Oracle VMware users group - http://ioug.org/VMware/

http://longwhiteclouds.com/ - good blog

SLAs:
* two nines - 99%
* three nines - 99.9%
* four nines - 99.99%
* five nines - 99.999%

If it doesn't perform will in physical, don't expect it to perform will in virtualized - garbage in, garbage out

Baseline, baseline, baseline - "there are no silver bullets"

slow storage array equates to slow database

When baselining, make sure your sample set is reasonable (seconds). A lot can happen in minutes.

SLOB (Silly Little Oracle Benchmark) - good free tool to look at

"Check It Before You Wreck It" -- Jeff Szastak

"Build New" - when migrating from Physical to Virtual, take the opportunity to "Build New"

VMware http://tsanet.org/ - hardware or software - VMware can setup support calls that can include Oracle

If your OS and database don't know they are virtualized, don't tell them

Understand your workload types - if you don't know, how can you tune and configure??
* Also allows you to combine VMs that may have offset time workloads (gaining more for my investment)

Seperate development from test from production environments

Trivia:
* First use of the word "Nerd" - Doctor Seusse (If I ran to the zoo)
* Americans eat the most food on Super Bowl Sunday

Have more VMs than less. Giant VMs with everything in it are harder to manage then smaller VMs. Better resource management and tuning options.

Storage - Spindle count and RAID configurations still rule

Know where your bottlenecks are at

VMFS vs RDM - perform about the same, valid reasons for using either
* VMware recommends VMFS unless you have a really good reason

Thin Provision - first write penalty - use Thick Eager Zeroed for performance

Microosft recommends 1 datafile per CPU

PVSCSI adapters are high-performance - use them

80% of issues are performance or storage misconfiguration

#1 issue is not enough spindles to support the app

vCPUs - count hyper threading as only .2 of a CPU (nearly nothing) when doing your calculations

Recommendation: 1-1 Ratio physical cores to vCPUs

Ntirety Rule - for SQL server

NUMA - Non-Uniform memory Access - size VMs to fit within a socket realm (ex. 128GB with 4 sockets would be <32GB optimal performance)

vNUMA (exposed to OS) is better than yNUMA (interleaving)

Swapping:
* Guest VM
* ESXi host level

Ballooning abd memory compression slows things down
* Ballooning is good, don't shut it off, but there is a performance hit when it kicks in

How many VMs can fit on a host? As many as fit within active memory

Memory Reservations can lock out memory for critical VMs

Jumbo Frames are good, if you use them correctly
* Have to configure on ESX, network switch, and application
* If there is a constriction point, breaks down. Don't set Jumbo Frames larger than smallest bottleneck in the network path

* Use VMXNET3 - reduces physical CPU overhead)

WSFC - Cluster Validation Wizard - should run before you call Microsoft Support

blog:
* http://michaelcorey.ntirety.com/
* http://www.dbtablog.com

VMworld 2014/Virtualizing Databases and Doing It Right - Revision history

Kenneth at 20:30, 26 August 2014