Overview
This chapter describes the VMAX3 storage configuration used in this solution. Design considerations must be understood, including front-end connectivity for the VMAX3 storage array, to ensure the best availability and performance for your hosts. EMC recommends that you check the latest best practice and design considerations before building your solution.
Storage design considerations
To achieve the optimized performance for your deployment of SQL Server 2014 on VMAX3, follow these general storage design best practices:
Configure enough resources to handle the workload and use those resources as uniformly as possible.
Connect storage ports across different directors instead of using all the ports on a single director.
Balance the load as evenly as possible across VMAX3 resources, including front-end directors, front-end ports, and so on. The VMAX3 back-end is preconfigured in the bin file, therefore, the SLO-based provisioning handles which disks the data resides on.
In a storage area network (SAN) environment, use redundant host bus adapters (HBAs) to connect to redundant fabrics for load balancing and resilience across HBA and switching paths.
Install PowerPath for optimal path management and maximum I/O performance.
Avoid multiple storage resource pools on VMAX3 and do not overcomplicate the configuration.
Front-end design considerations
The front-end configuration and connectivity of the VMAX3 array must follow the latest best practices and consideration:
Spread front-end ports evenly across all available directors.
Connect each host to ports on different directors before using additional ports on the same director.
Use the same logical port number on each director for ease of administration and troubleshooting.
Use more front-end ports to get maximum throughput for large block, high-throughput workloads.
As shown in Figure 3, we configured 32 front-end ports evenly across the eight directors (four engines) in this solution. Each host HBA port is mapped to two front-end ports on different directors for redundancy and load balancing. To balance the
Chapter 4: Storage Design and Configuration
load across VMAX3 storage array resources, all ESXi hosts are segregated to use different VMAX3 front-end ports, using SAN zoning and the masking view feature in VMAX3.
In this solution, two HBA ports are enabled on each of the three hosts for OLTP testing. To achieve optimized throughput, the other two hosts each used four HBA ports for DSS testing.
Figure 3. Front-end port connectivity
Chapter 4: Storage Design and Configuration
VMAX3 SLO design
A VMAX3 SLO defines the ideal performance operating range of an application. The SLO contains different service levels, as shown in Figure 4. All devices not explicitly associated with an SLO are managed by the system-optimized SLO by default.
Figure 4. VMAX3 service levels
We defined four different types of resource requirements for the database to reflect realworld customer needs:
Diamond: To host databases that require the lowest response levels to support the business-critical operations
Platinum: To host databases that support business applications that continue to require low levels of response time
Gold: To host databases that are appropriate for test and development requirements
Silver: To host roles that are appropriate for lower levels of performance and latency expectations, such as virtual machine boot images, disk-based backup targets, file shares, and so on
We designed four different size databases for the OLTP SQL Server instances that reside on the Diamond, Platinum, and Gold service levels, and another two databases for the DSS SQL Server instance that resides on the Gold service level.
Chapter 4: Storage Design and Configuration
Table 6 describes the SLOs used in this solution.
Table 6. SLOs used in this solution
Storage group name SLO Workload
type Capacity (GB)
SQL_DB1_Dia Diamond
OLTP OLTP 1,536
SQL_LOG1_Dia N/A 300
SQL_DB2_Dia OLTP 750
SQL_LOG2_Dia N/A 150
SQL_DB3_Dia OLTP 400
SQL_LOG3_Dia N/A 100
SQL_DB4_Dia OLTP 100
SQL_LOG4_Dia N/A 50
SQL_Tempdb_OLTP_Dia N/A 100
SQL_Templog_OLTP_Dia N/A 100
SQL_DB1_Plat Platinum
OLTP
OLTP 1,536
SQL_LOG1_Plat N/A 300
SQL_DB2_Plat OLTP 750
SQL_LOG2_Plat N/A 150
SQL_DB3_Plat OLTP 400
SQL_LOG3_Plat N/A 100
SQL_DB4_Plat OLTP 100
SQL_LOG4_Plat N/A 50
SQL_Tempdb_OLTP_Plat N/A 100
SQL_Templog_OLTP_Plat N/A 100
SQL_DB1_Gold Gold
OLTP
OLTP 1536
SQL_LOG1_Gold N/A 300
SQL_DB2_Gold OLTP 750
SQL_LOG2_Gold N/A 150
SQL_DB3_Gold OLTP 400
SQL_LOG3_Gold N/A 100
SQL_DB4_Gold OLTP 100
SQL_LOG4_Gold N/A 50
SQL_Tempdb_OLTP_Gold N/A 100
Chapter 4: Storage Design and Configuration
Storage group name SLO Workload
type Capacity (GB)
SQL_Templog_OLTP_Gold N/A 100
SQL_DB5_DSS Gold
DSS 1
DSS 2,048
SQL_LOG5_DSS N/A 400
SQL_Tempdb5_DSS N/A 250
SQL_Templog5_DSS N/A 200
SQL_DB6_DSS Gold
DSS 2
DSS 2,048
SQL_LOG6_DSS N/A 400
SQL_Tempdb6_DSS N/A 250
SQL_Templog6_DSS N/A 200
SQL_Sys Silver N/A 100
SQL_DB_Backup N/A 10,240
VM_OS N/A 2,048
Chapter 4: Storage Design and Configuration
VMAX3 storage provisioning with SLO
To create SLOs for SQL Server 2014:
1. Log in to Unisphere. Under Storage > Storage Group Management > Manage, click Provision Storage to Host, as shown in Figure 5, to access the SLO creation window.
Figure 5. Opening the SLO creation window
2. Create a cascaded storage group with parent and child storage groups, each with their own SLO and optional Workload Type, as shown in Figure 6.
Creating SLOs
Chapter 4: Storage Design and Configuration
Figure 6. Creating the storage group a. Type the Storage Group Name.
Storage group names must be on the storage system and cannot exceed 64 characters. Only alphanumeric characters, underscores (_), and hyphens (-) are allowed. Storage group names are not case sensitive.
b. To select a Storage Resource Pool other than the default, click Edit and select the pool. In this solution, we used SRP_1.
c. Type the child Storage Group Name as defined in Table 6 on page 24.
d. Select the service level for each Storage Group.
The SLO specifies the characteristics of the provisioned storage, including maximum response time, workload type, and priority.
e. Refine the SLO by selecting the Workload Type to assign to it.
f. Type the number of Volumes and select the Capacity of each volume.
g. Click Add Service Level to create another child storage group SLO set.
3. Select the host group, as shown in Figure 7, and click Next.
Chapter 4: Storage Design and Configuration
Figure 7. Select Host/Host Group
4. Select either a new or existing port group, as shown in Figure 8, and click Next.
Figure 8. Select Port Group
Chapter 4: Storage Design and Configuration 5. Type the name for Masking View. Verify the rest of your selections. Click Add
to Job List, as shown in Figure 9. Choose Run Now to perform the operation immediately.
Figure 9. Reviewing and finishing storage provision
The SLO feature provides the ability to change the service level when the storage performance of the SQL Server databases cannot meet business needs or an adjustment needs to be made on the resource level.
With SLOs, you can complete the data migration directly by changing the SLO without interrupting the system and application. Figure 10 shows an example of how to change the SLO. In this example, the current SLO of SQL_DB1_Gold is Gold. We changed it to Platinum.
Changing the SLO
Chapter 4: Storage Design and Configuration
Figure 10. Example of changing an SLO
To change the SLO, we clicked Modify and chose Platinum for the Service Level, as shown in Figure 11.
Figure 11. Example of modifying the selected SLO
Chapter 5: VMware Design and Configuration
Chapter 5 VMware Design and Configuration
This chapter presents the following topics:
Overview ... 32 Virtual machine configuration ... 32 VMware vSphere cluster configuration ... 33 Virtual network design ... 33 Storage I/O queue optimization for VMware vSphere ... 34
Chapter 5: VMware Design and Configuration
Overview
In this solution, we deployed virtualized SQL Server instances for both OLTP and DSS environments using the VMware vSphere 5.5 platform.
In this chapter, we describe virtual design and configuration for the solution.
Virtual machine configuration
We deployed virtualized SQL Server instances across three physical machines for the OLTP environment, to fully utilize the storage resources from the VMAX3 storage array.
We also deployed two virtualized standalone SQL Server instances on separate physical machines for the DSS environment.
Table 7 shows the detailed configuration for the SQL Server virtual machines deployed in this solution.
Table 7. SQL Server virtual machine configuration Virtual machine
role
Quantity vCPU Memory OS VMDK size
Mapped SLO from VMAX3
OLTP 3 24 32 GB 100 GB Diamond, Platinum, Gold
DSS 2 32 128 GB 100 GB Gold x 2
When allocating the CPU and memory resource for the SQL Server virtual machines in vSphere, EMC recommends that you implement the following best practices to achieve better performance:
Enable non-uniform memory access (NUMA) nodes on each ESXi server to fully utilize the scalability of the compute and memory resources.
Do not exceed the maximum NUMA node count of the physical server when sizing for each virtual machine. Run the following command to check the NUMA node settings on your ESXi Server:
esxcli hardware memory get | grep NUMA
Allocate enough memory reservations on each virtual machine for both SQL Server and OS overhead.
Install the latest version of VMware Tools in the guest OS to improve the ability to manage the virtual machine.
VMAX3 provides unprecedented performance and scale for a wide range of SQL Server workloads, including typical OLTP and DSS workloads. To support very high levels of I/O throughput, configure multiple VMware Paravirtual SCSI (PVSCSI) controllers inside the virtual machine to drive the execution of some parallel I/O operations. The PVSCSI controllers would benefit overall performance and lower CPU utilization for the guest OS. EMC recommends that you evenly distribute database LUNs across each PVSCSI controller to achieve optimal performance.
Chapter 5: VMware Design and Configuration
VMware vSphere cluster configuration
In this solution, we deployed a vSphere cluster for high availability and flexible administration of both OLTP and DSS systems. EMC recommends that you configure both VMware vSphere High Availability (HA) and VMware vSphere Disaster Recovery System (DRS) for each SQL Server virtual machine.
Figure 12 shows the DRS anti-affinity rule created for this solution. We enabled the anti-affinity rule for all SQL Server virtual machines. This rule helps place each virtual machine on different physical hosts, to achieve both performance isolation and efficient resource utilization.
Figure 12. Anti-affinity rule configuration
Virtual network design
We created two standard virtual switches for each ESXi server:
vSwitch0: 1 Gb Ethernet for management network
vSwitch1: 10 Gb Ethernet for virtual machine connectivity
To ensure optimal performance and stability, EMC recommends selecting VMXNET3 as the virtual network adapter type when connecting the virtual machine to vSwitch1.
Chapter 5: VMware Design and Configuration
Storage I/O queue optimization for VMware vSphere
In the virtualized environment, the default settings for the storage I/O queue depth are not necessarily optimal for the I/O-intensive workloads that VMAX3 can support.
By using storage I/O queues, vSphere enables multiple virtual machines to share a single resource. Figure 13 shows the main types of queues in vSphere:
World Queue: per virtual machine queue
Adapter Queue: per HBA queue
Device Queue: per LUN queue
Figure 13. Storage I/O queue flow in VMware vSphere 5.5
The I/O request flows into the World Queue, which then flows into the Adapter Queue and, finally, into the Device Queue for the LUN that the I/O is going to.
Chapter 5: VMware Design and Configuration To achieve extreme high performance for SQL Server 2014 on VMAX3, EMC
recommends that you follow the instructions in Appendix A: Optimizing the Storage I/O Queue to optimize the storage queues in your vSphere environment.
For more details, refer to the VMware blog post Troubleshooting Storage Performance in vSphere – Storage Queues.