Nutanix Tech Note - p · PDF file• VMware vSphere on Nutanix Best Practices White Paper...

©2014 All Rights Reserved, Nutanix Corporation

Nutanix Tech Note Virtualizing Microsoft SQL Server on Converged Infrastructure

The increase in virtualization of critical applications such as Microsoft SQL Server has given rise to the concept of hyperconvergence in the data center. This tech note reviews the performance advantages of and best practices for converged infrastructure for Microsoft SQL Server.


SQL Server on Converged Infrastructure

If there is one technology trend that is revolutionizing the enterprise datacenter as much as flash, it is hyperconvergence. This is where storage and compute (CPU and RAM) are provided in a single modular building block, connected together using standard Ethernet networks. This tech note will review key aspects of Microsoft SQL Server performance and the benefits of using the converged Nutanix Virtual Computing Platform for critical SQL Server workloads.

The Nutanix Virtual Computing Platform is a purpose-built infrastructure solution for virtualization and cloud environments. It brings together the many benefits and economics of web-scale architectures from companies such as Google, Facebook, and Amazon to the enterprise, through its Nutanix Distributed File System (NDFS). The Nutanix solution includes highly dense storage and server compute (CPU and memory) in a single platform building block. Each building block is based on industry-standard and high performing Intel processor/server technology, and delivers a unified, scale out, shared-nothing architecture with no single point of failure (SPOF). The Nutanix platform doesn’t rely on traditional SAN or NAS storage, or on expensive storage network interconnects. What sets Nutanix apart from other storage solutions is its uncompromising simplicity. This simplicity is not just demonstrated in ease of deployment (30 minutes) and operations, such as when dynamically increasing the system size, but also in the ease of designing and architecting successful solutions — even for business critical-applications such as Microsoft SQL Server.

The Nutanix platform doesn’t suffer from the problems or complications of traditional storage environments, eliminating the difficulties encountered when designing infrastructure for SQL in a traditional architecture. There are no LUNs to manage, no RAID to configure, no FC switches or zoning or masking to configure, no registered state change notifications (RSCN) to track, and no complicated storage multipathing to setup. All storage management is VM-centric, dealing with virtual disks. Storage IO from a virtual disk is seen as what it is, and optimized by NDFS. There is one shared pool of storage across a distributed Virtual Computing Platform that includes flash-based SSDs for high performance, and low-latency and high-capacity HDDs for affordable capacity. The different types of storage devices in the storage pool are automatically tiered using intelligent algorithms to make sure the most frequently used data is available in memory or in flash.

Figure 1 shows an overview of the Nutanix Virtual Computing Platform Architecture, including each hypervisor host (VMware ESXi or Microsoft Hyper-V), Microsoft SQL Server VMs (User VMs), Storage Controller VM (Nutanix Controller VM), and its local disks. Each Controller VM is directly connected to the local storage controller and its associated disks. By using local storage controllers on each ESXi host, access to data through NDFS is localized. It doesn’t always require data to be transferred over the network, thereby improving latency. NDFS ensures that writes are replicated, distributing data within the platform for resiliency. The local storage controller on each host ensures that storage performance


as well as storage capacity increases when additional nodes are added to the Nutanix Virtual Computing Platform.

Figure 1: The Nutanix Virtual Computing Platform easily scales without the constraints of traditional storage.

While the storage is local to each node in the distributed scale out architecture, it appears to the hypervisor as shared storage and therefore integrates perfectly with the virtualization layer. In the case of VMware vSphere, this includes VMware DRS, VMware High Availability, and VMware Fault Tolerance. The combination of SSD and HDD local storage in addition to intelligent automated tiering balances both cost and performance, while NDFS resiliency techniques eliminate the performance penalties associated with RAID. The localization of data allows for performance and QoS to be provided per host, so noisy VMs don’t greatly impact the performance of their neighbors. This allows for large mixed workload vSphere clusters that are more efficient from a capacity and performance standpoint and more resilient to failure.

At the time this report was published, the typical performance from the midrange model with four nodes occupying 2RU of space is up to a combined 100K 4K Random Read IOs, 50K 4K Random Write IOs, and 1.4GB/s sequential write and 3GB/s sequential read throughput.

Figure 2: Microsoft SQL Server on Nutanix Virtual Computing can run along side different virtualization workloads.

SCAL

E

SCAL

E

MSSQL VMs

Operational Intelligence

Data Integration

Service Interaction

UsersUsers

DesktopsDesktops Applications/DataApplications/Data ServersServers

External SourcesExternal Sources


The simplified nature of the Nutanix Virtual Computing Platform architecture and NDFS simplifies the storage layout. Figure 3 illustrates an example layout, which is standard in a Virtual Computing Platform environment. It is comprised of a single NFS datastore (or in the case of Hyper-V a single SMB 3.0 share) and single storage pool. There is no need to worry about multiple LUNs or associated queue depths. The next few steps are shown for VMware vSphere, but the equivalent can be applied for Microsoft Hyper-V.

Figure 3: SQL Server VM Disk Layout on the Nutanix Virtual Computing Platform

The simplified storage layout and localization of data to each node where the VM is executing provides a number of performance benefits to each type of SQL database.

Nutanix Features and Benefits

SQL OLTP Transactional Database

• Localized I/O for low latency operations • Flash for index and key database files • Handles both random and sequential workloads with ease

SQL OLAP Analytical Database

• High performance queries and reports with localized I/O • Abundant sequential read and write throughput • Scales with ease to accommodate growth

Table 1: Nutanix performance benefits for OLTP and OLAP SQL databases.

To demonstrate the performance of the Virtual Computing Platform for applications such as Microsoft SQL Server, a number of SQLIO benchmarks were performed as part of the SQL on Nutanix Best Practices White Paper. The following figures 4 through 8 show the results from the benchmark tests:


Figure 4: SQL Server SQLIO Single VM Random IOPS by Block Size

Figure 5: SQL Server SQLIO Single VM Throughput by Block Size

Figure 6: SQL Server SQLIO Multiple VM IOPS Scalability

Figure 7: SQL Server SQLIO Multiple VM Throughput Scalability


The Nutanix Virtual Computing Platform can co-exist with existing storage investments and offload workloads from existing storage platforms, freeing up both capacity and performance until the existing environment is due for refresh. It is easy to migrate into the Virtual Computing Platform. The performance capability and linear scalability, when combined with the uncompromising simplicity of the Nutanix platform, makes it a very good option for delivering on SQL Server Database as a Service initiatives.

Nutanix has created a series of documents on virtualizing Microsoft SQL Server. These reports can be found at www.nutanix.com under the resources section:

• VMware vSphere on Nutanix Best Practices White Paper • SQL Server Best Practices White Paper and Reference Architecture • Nutanix Bible: Technology Guide


Appendix: MS SQL Server on Nutanix Best Practice Checklist

MS SQL Server on Nutanix best practices can be summarized into the following high-level items. NOTE: The majority of best practice configuration and optimization benefits come at the MS SQL Server level.

General

o Perform a current state analysis to identify workloads and sizing

o Spend time upfront to architect a solution that meets both current and future needs

o Design to deliver consistent performance, reliability, and scale

o Don’t undersize, don’t oversize — right size

o Start with a PoC, test, optimize, iterate, and scale

Core Components

o MSSQL

▫ Performance and Scalability

o Utilize multiple drives for TempDB Log/Data and Database Log/Data

§ Start with a minimum of 2 drives for small environments or 4 for larger environments

§ Look for PAGEIOLATCH_XX contention and scale number of drives as necessary

o Utilize a 64KB NTFS allocation unit size for MSSQL drives

o Enabled locked pages in memory for MSSQL Server service account (NOTE: if this setting is used the VM’s memory must be locked, only applies with memory > 8GB)

o TempDB Data Files

§ Set TempDB size between 1 and 10% of instance database sizes

§ If number of cores < 8

• # of cores = # of data files

§ If number of cores > 8

• Use 8 data files to being with

• Look for contention for in-memory allocation (PAGELATCH_XX) and scale 4 files at a time until contention is eliminated

o Database Data files

§ Size appropriately and enable AUTOGROW respective to database growth

§ Do not AUTOSHRINK data and log files


§ At a maximum keep below 80% of disk capacity utilization

§ Use multiple data file and drives

• Look for contention for in-memory allocation (PAGELATCH_XX), if contention increase number of files

• Look for I/O subsystem contention (PAGEIOLATCH_XX), if contention, spread the data files across multiple drives

o Trace flags

§ Implement trace flag 1118 at startup to remove single page allocations

§ Implement trace flag 834 to enable large pages (for tier-1 performance)

o Utilize the MSSQL Server Best Practices Analyzer (BPA) to identify potential issues

o Utilize fast file initialization

o Scale number of MSSQL VMs vs. number of MSSQL instances per VM

o More memory = higher performance, if seeing memory pressures, increase VM memory

o Utilize a dedicated disk for Microsoft Page File

▫ Availability

o In most cases vSphere HA will provide an adequate level of availability and uptime for non-mission critical/tier-1 applications

o For mission critical/tier-1 applications:

§ MSSQL 2012: utilize AlwaysOn availability groups (preferred)

§ MSSQL 2008 and prior: utilize log shipping or clustered MSSQL using MSCS clusters

o Take consistent database snapshots/backups, frequency should be derived from required RPOs

o Leverage native or third-party tools to manage backups (example: Microsoft System Center Data Protection Manager (DPM), etc.)

▫ Manageability

o Standardize, monitor and maintain

o Leverage a MSSQL application monitoring solution (example: System Center, etc.)

o Create standardized MSSQL VM Templates

o Utilize consistent disk quantities and layout schemes for MSSQL VMs

o Join the MSSQL Server to the domain and use Active Directory for authentication

o Leverage Contained Database Authentication (MSSQL 2012)

o Use named instances for MSSQL database instances, even when only planning a single instance per VM


o For named instances, ensure application compatibility with dynamic ports, otherwise set instance to use a fixed port

o VMware vSphere (leverage equivalent best practices in case of Hyper-V)

▫ Follow VMware performance best practices

▫ Avoid CPU core oversubscription (for tier-1 workloads)

▫ For small MSSQL VMs keep vCPUs <= to the number of cores per each physical NUMA node

▫ For wide MSSQL VMs size vCPUs to align with physical NUMA boundaries and leverage vNUMA

▫ Keep vCPU numbers easily divisible by NUMA node sizes for easy scheduling

▫ Leave Hyperthreading sharing at the default policy (Any)

▫ Enable ‘High Performance’ host power policy

▫ Lock MSSQL VM memory (for tier-1 workloads)

▫ Size MSSQL VM memory using the following calculation:

o VM Memory = SQL Server Max Memory + ThreadStack + OS Memory + VM Overhead

o Threadstack = SQL Max Worker Threads * 2MB (for x64)

▫ Use paravirtual SCSI Controllers and VMXNET3 NICs

▫ Use resource pools with correct share allocation

▫ Use DRS anti-affinity rules to keep MSSQL VMs apart

o Nutanix Virtual Computing Platform

▫ Use a single container for SQL Server

▫ Utilize appropriate model based upon compute and storage requirements

o Ideally keep working set in SSD and database size within node capacity

o Choose a model that can ideally fit the full database on a single node. NOTE: for larger databases which cannot fit on a node, ensure there is ample bandwidth between nodes

o Utilize higher memory node models for I/O heavy MSSQL workloads

▫ Create a dedicated consistency group with the MSSQL VMs and applications

▫ Leverage ‘Application Consistent Snapshots’ on the consistency group to invoke VSS when snapshotting

Supporting Components

o Network

▫ Utilize and optimize QoS for NDFS and database traffic


▫ Use low-latency 10GbE switches

▫ Utilize redundant 10GbE uplinks from each Nutanix node

▫ Ensure adequate throughput between Nutanix nodes and MSSQL VMs

▫ Check for any pause frames which could impact replication and VM communication

o Active Directory

▫ Utilize AD based authentication for MS SQL Server VMs

o OS and Application Updates

▫ Schedule updates to be applied outside business hours to avoid performance impacts

▫ Stagger updates in phases

Nutanix Tech Note - p · PDF file• VMware vSphere on Nutanix Best Practices White Paper...

Documents

Transcript of Nutanix Tech Note - p · PDF file• VMware vSphere on Nutanix Best Practices White Paper...