Dell EMC PowerStore: Microsoft SQL Server Best Practices - Abstract
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Best Practices
Dell EMC PowerStore: Microsoft SQL Server
Best Practices
Abstract
This document includes architecture, deployment, and perf ormance guidance f or
Microsof t® SQL Server® with Dell EMC™ PowerStore™.
May 2021
H18250.4
Revisions
Revisions
Date Description
April 2020 Initial release: PowerStoreOS 1.0
July 2020 Updated AppsON host conf iguration and sizing guidance
February 2021 Legal disclaimer update
April 2021 PowerStoreOS 2.0
May 2021 Clarif ication on PowerStore X and T
Acknowledgments
Author: Doug Bernhardt
This document may contain certain words that are not consistent with Dell's current language guidelines. Dell plans to update the document over
subsequent future releases to revise these words accordingly.
This document may contain language from third party content that is not under Dell's control and is not consistent with Dell's current guidelines for Dell's
own content. When such third party content is updated by the relevant third parties, this document will be revised accordingly.
The information in this publication is provided “as is.” Dell Inc. makes no representations or warranties of any kind with respect to the information in this
publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose.
Use, copying, and distribution of any software described in this publication requires an applicable software license.
Copyright © 2020-2021 Dell Inc. or its subsidiaries. All Rights Reserved. Dell Technologies, Dell, EMC, Dell EMC and other trademarks are trademarks
of Dell Inc. or its subsidiaries. Other trademarks may be trademarks of their respective owners. [5/11/2021] [Best Practices] [H18250.4]
2 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4
Table of contents
Table of contents
Revisions .............................................................................................................................................................. 2
Acknowledgments.................................................................................................................................................. 2
Table of contents ................................................................................................................................................... 3
Executive summary................................................................................................................................................ 6
Audience............................................................................................................................................................... 6
1 Introduction ..................................................................................................................................................... 7
1.1 PowerStore product overview .................................................................................................................. 7
1.2 Microsoft SQL Server product overview.................................................................................................... 7
1.3 Prerequisite reading ................................................................................................................................ 7
1.4 Terminology ........................................................................................................................................... 7
2 Scale-up and scale-out architecture .................................................................................................................. 9
2.1 SQL Server scale-up ............................................................................................................................... 9
2.2 SQL Server scale-out .............................................................................................................................. 9
2.3 PowerStore scale-up ............................................................................................................................... 9
2.4 PowerStore scale-out .............................................................................................................................. 9
3 Host conf iguration...........................................................................................................................................10
3.1 External SQL Server hosts .....................................................................................................................10
3.1.1 Boot f rom SAN ......................................................................................................................................10
3.2 AppsON ................................................................................................................................................10
4 Sizing and performance optimization................................................................................................................12
4.1 SQL Server design considerations ..........................................................................................................12
4.1.1 Database design....................................................................................................................................12
4.1.2 OLTP workloads ....................................................................................................................................12
4.1.3 Analytic workloads .................................................................................................................................12
4.1.4 Mixed workloads ....................................................................................................................................13
4.2 SQL Server deployment platf orms ..........................................................................................................13
4.2.1 Windows ...............................................................................................................................................13
4.2.2 SQL Server on Windows deployment ......................................................................................................13
4.2.3 Linux .....................................................................................................................................................13
4.2.4 SQL Server on Linux deployment ...........................................................................................................14
4.2.5 Containers ............................................................................................................................................15
4.2.6 SQL Server container deployment ..........................................................................................................15
4.2.7 Kubernet es............................................................................................................................................15
4.2.8 SQL Server Kubernetes deployment .......................................................................................................16
3 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4
Table of contents
4.3 RAID conf igurations and storage pools....................................................................................................19
4.4 Validating the I/O path............................................................................................................................19
4.5 MPIO ....................................................................................................................................................20
5 Perf ormance...................................................................................................................................................21
5.1 PowerStore Node Affinity .......................................................................................................................21
5.2 Virtualization..........................................................................................................................................23
5.3 AppsON ................................................................................................................................................23
5.3.1 Resource reservation .............................................................................................................................23
5.3.2 SQL Server virtual machines ..................................................................................................................24
5.3.3 Multi-appliance virtual machine migrations...............................................................................................24
5.3.4 SQL Server Big Data Clusters ................................................................................................................25
5.4 Reducing SQL Server I/O .......................................................................................................................26
5.4.1 Memory.................................................................................................................................................26
5.4.2 Buff er pool extension .............................................................................................................................26
5.4.3 Persistent memory .................................................................................................................................26
5.4.4 Instant File Initialization ..........................................................................................................................27
5.4.5 Resource Governor................................................................................................................................27
5.4.6 Database design considerations .............................................................................................................27
5.4.7 Database design....................................................................................................................................27
5.4.8 Query design.........................................................................................................................................27
5.4.9 Application design..................................................................................................................................28
5.4.10 Maintenance......................................................................................................................................28
6 Management and monitoring ...........................................................................................................................29
6.1 Mapping or unmapping best practices .....................................................................................................29
6.2 SQL Server f ailover cluster instances ......................................................................................................29
6.3 Creating volumes...................................................................................................................................29
6.4 Allocation unit size .................................................................................................................................30
6.5 Disk-f ormat wait time .............................................................................................................................30
6.6 Thin clones............................................................................................................................................31
6.7 Data encryption .....................................................................................................................................31
6.8 Data reduction .......................................................................................................................................31
6.9 Scripting and automation........................................................................................................................32
6.9.1 RES T API .............................................................................................................................................32
6.9.2 PowerStore CLI .....................................................................................................................................32
6.9.3 Ansible..................................................................................................................................................32
7 Data protection and disaster recovery ..............................................................................................................33
4 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4
Table of contents
7.1 Snapshots and recoveries ......................................................................................................................33
7.2 Snapshots and application backup and restore ........................................................................................33
7.3 Cras h consistency and application consistency........................................................................................34
7.4 Replication and remote recovery.............................................................................................................34
7.5 Integrated copy data management ..........................................................................................................34
A Technical support and resources .....................................................................................................................36
A.1 Relat ed resources..................................................................................................................................36
5 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4
Executive summary
Executive summary
This paper provides best practices f or using Dell EMC™ PowerStore™ in a Microsof t ® SQL Server®
environment. SQL Server is a robust product that can be used in various solutions. The relative priorities of
critical design goals such as perf ormance, manageability, and f lexibility depend on the environment. This
paper provides considerations and recommendations to help meet design goals. For general best practices
f or using PowerStore systems, see the Dell EMC PowerStore: Best Practices Guide on
Dell.com/StorageResources.
These guidelines are intended to cover most use cases. They are recommended by Dell Technologies™, but
they are not strictly required. For questions about the applicability of these guidelines in your environment,
contact your Dell Technologies representative to discuss the appropriateness of the recommendations.
Audience
This document is intended f or IT administrators, storage architects, partners, and Dell Technologies
employees. This audience also includes any individuals who may evaluate, acquire, manage, operate, or
design a Dell EMC networked storage environment using PowerStore systems.
6 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4Introduction
1 Introduction
Dell EMC PowerStore is a robust and f lexible storage and comp ute option that is well suited to SQL Server.
The capabilities of the PowerStore platf orm provide some unique benef its and exciting architecture options for
SQL Server workloads.
1.1 PowerStore product overview
PowerStore achieves new levels of operational simplicity and agility. It uses a container-based microservices
architecture, advanced storage technologies, and integrated machine learning to unlock the power of your
data. PowerStore is a versatile platf orm with a perf ormance-centric design that delivers multidimensional
scale, always-on data reduction, and support f or next-generation media.
PowerStore brings the simplicity of public cloud to on-premises inf rastructure, streamlining operations with an
integrated machine-learning engine and seamless automation. It also of fers predictive analytics to easily
monitor, analyze, and troubleshoot the environment. PowerStore is highly adaptable, providing the f lexibility to
host specialized workloads directly on the appliance and modernize inf rastruc ture without disruption. It also
of f ers investment protection through f lexible payment solutions and data-in-place upgrades.
1.2 Microsoft SQL Server product overview
Microsof t SQL Server is the industry-leading data platf orm. A product which once started as a database
engine on Microsof t Windows has evolved into an entire data platf orm. This platf orm enables cloud, hybrid,
and on-premises deployments in several dif f erent environments including Windows, Linux, containers, and
Kubernetes. In addition to the wide number of environments that SQL Server can be deployed in, the use
cases have expanded. These uses now range f rom typical online transactional processing (OLTP) to various
analytics options such as data warehousing, artif icial intelligence (AI), machine l earning (ML), and big data.
The adaptable and f lexible nature of SQL Server makes PowerStore a perf ect f it f or SQL Server.
1.3 Prerequisite reading
The best practices explained in this document require knowledge f rom the f ollowing resources:
• PowerStore documentation on the PowerStore Inf o Hub
• Dell EMC PowerStore Host Configuration Guide on the PowerStore Inf o Hub
• Microsof t SQL Server documentation library
1.4 Terminology
The f ollowing terms are used with PowerStore.
PowerStore Manager: The web-based user interf ace (UI) f or storage management.
Appliance: Term used f or solution containing a base enclosure and any attached expansion enclosures. The
size of an appliance could be only the base enclosure or the base enclosure plus expansion enclosures.
Node: The component within the base enclosure that contains processors and memory. Each appliance
consists of two nodes.
Cluster: Multiple PowerStore appliances in a single grouping. Clusters can consist of one appliance or more.
Clusters are expandable by adding more appliances . A cluster supports up to f our appliances.
7 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4Introduction
Base enclosure: Used to ref erence the enclosure containing both nodes (node A and node B) and the NVMe
drive slots.
Expansion enclosure: Enclosures that can be attached to a base enclosure to provide 25 additional SAS-
based drive slots.
Virtual Volumes (vVols): PowerStore X model volumes support VMware® vSphere® Virtual Volumes™
(vVols). These volumes are displayed in the Virtualization area of PowerStore Manager.
Storage volumes (Volumes): PowerStore volumes using block storage. These volumes are displayed in the
Block area of the PowerStore dashboard.
8 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4Scale-up and scale-out architecture
2 Scale-up and scale-out architecture
Scale-up and scale-out are common architecture models used when accommodating a growing data f ootprint.
Microsof t SQL Server has supported both scale-up and scale-out architecture models f or several years. Dell
EMC PowerStore aligns with the SQL Server by also providing both scale-up and scale-out architecture
options. When designing data architectures, there are tradeof f s in design, f unctionality and scalability that
must be considered.
2.1 SQL Server scale-up
When you scale up an instance of SQL Server, the amount of memory, compute, and storage can all be
increased by upgrading to a higher sof tware version or increasing the hardware capabilities. You get the
same or more f unctionality and retain the same logical data design and theref ore the data architecture is
unaf f ected. This is a common approach because it is low impact.
2.2 SQL Server scale-out
Scale-out architectures on SQL Server enable a data f ootprint to scale past what can be achieved by a single
instance. The trade-of f is that these architectures require considerably more planning and consideration and
of ten require applications to be designed accordingly. Concepts such as data placement, load balancing, and
data sharding may need to be addressed as well as the impact on f eatures such as replication, availability
groups, etc.
2.3 PowerStore scale-up
PowerStore models can scale up with several dif f erent upgrade paths, by adding additional drives or drive
expansion shelves to an existing appliance, adding additional storage network paths, upgrading to the next
generation hardware as it becomes available, or upgrading to more powerf ul models within the same f amily.
Like SQL Server scale-up, this is also a low impact approach. PowerStore redundancy f eatures and the
Anytime Upgrades program of f ered by Dell Technologies ensure a f rictionless upgrade experien ce.
2.4 PowerStore scale-out
PowerStore can also scale-out by adding additional nodes to the PowerStore cluster. PowerStore can add up
to 4 appliances in a cluster to provide additional capacity and perf ormance. Much like scale-up vs. scale-out
architecture decisions f or SQL Server, there are similar considerations f or PowerStore as well. Theref ore,
consult the Dell EMC PowerStore: Clustering and High Availability Guide on PowerStore Inf o Hub f or
complete details.
9 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4Host conf iguration
3 Host configuration
PowerStore provides the option of running workloads directly on the PowerStore Appliance as virtual
machines or running workloads on external hosts and presenting storage through block or f ile interf aces.
Prior to creating objects or deploying workloads on PowerStore it is recommended to review the f ollowing
guides f or best practices and tuning recommendations. It is recommended to apply these changes prior to
deploying workloads since some change require a reboot of the PowerSt ore appliance nodes. For resiliency,
it is recommended that external hosts are connected via multiple paths, or multipath, to the PowerStore
appliance.
3.1 External SQL Server hosts
PowerStore presents storage to external hosts through either block or f ile int erf aces. Block storage is
commonly used f or SQL Server workloads due to the various speeds and protocols that are of f ered which
make it ideal f or perf ormance. With PowerStoreOS 2.0, PowerStore supports 25 GbE and 32 Gb Fibre
Channel (FC) as well as NVMe over Fibre Channel (NVMe-FC) which are recommended f or SQL Server high-
bandwidth storage workloads such as analytics that can generate a large amount of large block I/O.
Instructions and best practices f or conf iguring hosts can be f ound in the Dell EMC PowerStore Host
Configuration Guide on the PowerStore Inf o Hub. File storage (SMB) can also be used in environments
running SQL Server on Windows.
For PowerStore T model appliances f ollow recommendations f or conf iguring external hosts in the Dell EMC
PowerStore Host Conf iguration Guide. In addition, when running SQL Server on virtual machines with
VMware ESXi™ hosts, review the additional guidance in the Dell EMC PowerStore Virtualization Guide and
Dell EMC PowerStore: VMware vSphere Best Practices papers.
3.1.1 Boot from SAN
PowerStore supports boot-from-SAN f or environments that want to f urther virtualize storage resources. In
addition to the storage virtualization benef its, Boot-from-SAN can also be used to protect the operating-
system conf iguration and allow f or quick recovery. This conf iguration can be benef icial in environments where
the recovery time objective (RTO) is strict.
3.2 AppsON
Integration of the PowerStore container-based architecture with integrated VMware ESXi results in a new
level of consolidation f or enterprise storage. This integration combines the benef its of a local on-array
application environment with unmatched integration with the vSphere management environment and server
resources. This ability allows users to bring applications closer to storage, by running ap plications as virtual
machines directly on PowerStore.
Benef its of the AppsON capability include a new level of agility f or application deployments, with seamless
movement between the PowerStore appliances and VMware ESXi servers . AppsON also provides the ability
to shrink the stack by eliminating server and networking f ootprint f or space-ef ficient edge and remote
deployments. AppsON is ideal f or data-intensive applications that require low latency or a storage-heavy
imbalance of compute and storage.
AppsON can be an attractive option whether the goal is to optimize I/O perf ormance by reducing components
in the data path, add perf ormance to an existing vSphere cluster, of f load a noisy neighbor, or various other
reasons.
10 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4Host conf iguration
For PowerStore X model appliances the PowerStore X Perf ormance Best Practice Tuning paper provides
several tips that increase perf ormance f or SQL Server workloads, esp ecially when running workloads that use
block sizes greater than 128k such as analytic workloads and backup/restore operations. In addition to the
recommendations in this paper, when running workloads larger than 128k, additional perf ormance gains may
be f ound by increasing the iSCSI maximum IO size, which is 128k by def ault. This can be achieved by
running the f ollowing command on each host:
esxcli system settings advanced set -o /ISCSI/MaxIoSizeKB -i 512
Instructions f or running esxcli commands on PowerStore X nodes are f ound in the PowerStore X
Perf ormance Best Practice Tuning paper.
11 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4Sizing and perf ormance optimization
4 Sizing and performance optimization
There are several best practices f or provisioning compute and storage to SQL Server. The size of power and
f lexibility of SQL Server allow it to be used in several dif ferent deployment scenarios. This section covers
some considerations f or optimizing PowerStore.
4.1 SQL Server design considerations
The I/O storage system is a critical component of any SQL Server environment. Sizing and conf iguring a
storage system without understanding the I/O requirements can have unf avorable results. Analyzing
perf ormance in an existing environment using a tool like Live Optics can help def ine the I/O requirements. For
best results, capture perf ormance statistics f or a period of at least 24 hours that includes the system peak
workload.
Demanding SQL Server workloads that require low latency, high bandwidth, or both can benef it f rom moving
the compute to PowerStore X model arrays. Moving these intensive workloads onto the storage platf orm
where compute and storage are located together can d eliver higher IO perf ormance f or perf ormance sensitive
applications. Also, virtual machines running other application components can be on PowerStore X models for
f urther perf ormance gains. Using PowerStore X models in a larger vSphere cluster and taking advantage of
VMware vSphere vMotion® capabilities can be a powerf ul tool in balancing not only SQL Server workloads but
also application workloads across the entire environment.
4.1.1 Database design
When creating SQL Server databases, the def ault is to have one database f ile, one f ilegroup, and one log f ile.
If at any point the database will have high perf ormance requirements, it is recommended to use at least two
data f iles per f ile group. SQL Server will write data evenly across all f iles in the f ilegroup and theref ore the
underlying f iles. Using multiple f iles allows the database workload to be spread across multiple volumes or
vVols. Even if they are placed on the same volume in the beginning, it is advantageous to create this f rom the
start. Additional f iles can be added later, but the data must be restriped to achieve balanced access through
re-indexing or some other technique. This is because SQL Server uses a proportional f ill strategy when
writing to data f iles such that it will write more data to f iles that have a greater amount of f ree space.
Additional f ilegroups can be created and may be benef icial to leverage some SQL Server f eatures. However,
the number of f ilegroups has no impact on perf ormance f rom a storage perspective.
SQL Server log f iles are accessed sequentially and do not use proportional f ill. Theref ore, there is no
perf ormance benef it to creating additional log f iles.
4.1.2 OLTP workloads
While every environment is unique, an online transaction processing (OLTP) workload typically consists of
small, random reads and writes. A storage system that services this type of workload is primarily sized based
on capacity and the number of IOPS required. PowerStore models allow the f lexibility to be configured f or
block-optimized, unif ied (block and f ile), or AppsON to meet unique OLTP requirements.
4.1.3 Analytic workloads
An online analytic processing (OLAP), decision support system (DSS), or big data workload is typically
dominated by large, sequential reads. A storage system services this type of workl oad is primarily sized
based on throughput. When designing f or throughput, the perf ormance of the entire path between the server
and the drives in PowerStore needs consideration. This is handled automatically when using virtual volumes
12 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4Sizing and perf ormance optimization
on PowerStore X models. When mapping volumes to hosts, consider using 32 Gb Fibre Channel (FC) or 25
Gbps iSCSI connectivity to the array. For high-throughput requirements to be met, multiple HBAs may also be
used in the server, the array, or both.
SQL Server 2019 introduced Big Data Clusters as a brand-new environment f or analytics. Combining the
power of SQL Server along with Apache® Hadoop ® Distributed File System (HDFS), Spark, and other
technologies to provide a data analytics or data lake platf orm and easily deploy that platf orm on Kubernetes is
revolutionary. The f lexibility and compute capabilities of PowerStore X models make a great deployment
platf orm f or SQL Server Big Data Clusters. For more inf ormation, see the document Dell EMC PowerStore:
SQL Server 2019 Big Data Clusters on Dell.com/StorageResources.
4.1.4 Mixed workloads
The most common scenario is a mixed workload environment. Typically, SQL Server I/O patterns do not
strictly f all into an OLTP or analytics pattern. This is what can make SQL Server workloads challenging
because no two workloads behave the same. In addition, the same SQL Server host or instance may be
servicing multiple applications or transaction workloads. Mixed workload can also i mply that multiple
applications (in addition to SQL Server) are residing on the same host or accessing the same storage. The
combined workload of these applications invalidates any typical application I/O usage pattern. For these
reasons, it is important to gather perf ormance metrics f or best sizing results.
4.2 SQL Server deployment platforms
SQL Server is now available and supported on several dif ferent platf orms. PowerStore presents several
f lexible options f or various SQL Server deployments.
4.2.1 Windows
When deploying SQL Server on Windows on PowerStore, virtual volumes (vVols) and storage volumes
(volumes) are available on PowerStore X models. In addition to vVols and volumes, PowerStore T also
contains f ile support through SMB. All of these options are acceptable f or use with SQL Server and rely on
the conf iguration of the volumes through Windows. When using SMB storage f or SQL Server, ensure the
Sync Writes Enabled and Oplocks Enabled are turned on f or the f ile system. See the Windows section of the
PowerStore Host Configuration Guide on the PowerStore Inf o Hub f or instructions about conf iguring host
access on Windows.
4.2.2 SQL Server on Windows deployment
SQL Server on Windows is deployed with an executable (exe) f ile which can be f ound on the Microsof t SQL
Server website. Deployment is done by downloading the SQL Server exe f ile f or the intended version and
running the executable. The SQL Server deployment wizard will walk through several available options.
Storage layout can either be customized during the install or af ter install once the SQL Server instance is
running. When perf orming large enterprise deployments there is an unintended install option available to
automate the installation.
4.2.3 Linux
When deploying SQL Server on Linux on PowerStore, vVols and volumes are available on both PowerStore
models. Although PowerStore T models contain f ile capabilities, they do not support NFS v 4.2 which is the
minimum that is required f or SQL Server on Linux. Theref ore, NFS is not supported.
13 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4Sizing and perf ormance optimization
Be sure to f ollow Microsoft Installation guidance f or deploying SQL Server on Linux f or supported Linux
versions, minimum requirements, and general recommendations. Currently RHEL, SUSE, and Ubuntu Linux
distributions are supported. The partnership of Dell Technologies, Microsof t, and RedHat provides a platf orm
will f ull end-to-end enterprise support and theref ore RHEL has quickly become a platf orm of choi ce for
deploying SQL Server on Linux.
4.2.4 SQL Server on Linux deployment
Once the Linux host is presented to the array, storage volumes can be presented to the host. Since Linux is
a relatively new platf orm f or SQL Server, an example is provided below f or conf iguring a RHEL host to
consume PowerStore block volumes. This example uses multipath, which is a best practice f or resiliency. For
completed instructions on conf iguring Linux hosts and multipath consult the PowerStore Host Configuration
Guide on the PowerStore Inf o Hub.
Af ter the storage volume have been provisioned to the host, run the f ollowing command to make the volumes
visible to the host:
#/usr/bin/rescan-scsi-bus.sh –a
Identif y the volume name in the mapper f older by listing the multipath volumes and searching f or the volume
WWN f rom PowerStore. The volume WWN is visible in the PowerStore volumes list under Storage ->
Volumes. For example, if the WWN f or the new volume is “68ccf 0980018e6c92364df 1970e08d33” then the
f ollowing command will identif y the mapper f older to use:
# multipath -ll | grep 68ccf0980018e6c92364df1970e08d33
The volume will need to be f ormatted prior to use. Consult the Microsof t SQL Server documentation f or
supported f ile systems. Currently XFS and EXT4 are supported. In this example, XFS is being used. For XFS
the mkf s.xfs command is used to f ormat the volume passing the correct mapper f older as the parameter.
# mkfs.xfs /dev/mapper/mpathdb
A mount f older needs to be created to represent the new volume. Create a f older to represent the mount:
# mkdir /var/opt/mssql/data5
To make the mount persistent, the mapping needs to be stored in /etc/fstab so it will be created at boot
time. The entry in the f ile will consist of six f ields contained on a single line separated by a space: device,
mount point, f ile system type, options, backup operation, and f ile system check order. When mounting
volumes f or SQL Server it is a Microsof t best practice to add the noatime attribute to the list of options to
disable updates to the volume timestamp f or better perf ormance. The f ields backup operation and file system
check order will be lef t at the def ault of 0 and can be changed as needed. Based on our example, the new
entry in the /etc/fstab f ile would look like this:
/dev/mapper/mpathdb /var/opt/mssql/data5 xfs defaults,noatime 0 0
Once the entry f or the new mount is created, running the mount command will read the f ile and ref resh the
mounted devices. Even if the mount was manually created, it is a good idea to run the mount command af ter
updating /etc/f stab to ensure there are no errors. If there are errors in the f ile, it could prevent Linux f rom
booting properly.
# mount -a
14 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4Sizing and perf ormance optimization
Finally, bef ore SQL Server can access the new mount, permissions need to be set. In a production
environment, f ollow the security best practices f or your organization when assigning permissions and
ownerships to mount points. This example uses the same def ault permissions and ownership f rom the SQL
Server installation by copying the permissions f rom the /var/opt/mssql/data f older and applyi ng them to the
new mount point:
# chmod --reference /var/opt/mssql/data /var/opt/mssql/data5
At this point the new volume is ready f or SQL Server to use. See the Linux section of the PowerStore Host
Configuration Guide on the PowerStore Inf o Hub f or f urther instructions on conf iguring storage volume access
on Linux.
4.2.5 Containers
Running SQL Server inside Docker® containers is a deployment option that was introduced with SQL Server
2017. By def ault, the database storage is inside of the container and is ephemeral in nature. If databases
need to be persisted beyond the lif etime of the container, external storage must be presented. External
storage is presented to a container through a bind mount which is a local f ile system f older or mount f rom the
operating system that is presented to the container at startup. Follow the storage guidance above f or either
Windows or Linux to create f ile system f olders or mount points to present as a volume bind mounts to
containers.
4.2.6 SQL Server container deployment
Deploying SQL Server inside Docker containers is extremely simple. Below is an example of running SQL
Server inside a container f ollowed by a brief explanation of the parameters:
# sudo docker run -e "ACCEPT_EULA=Y" -e "SA_PASSWORD=P@ssword1" -p
1401:1433 -v /root/sql1/tpcc_data:/var/opt/mssql/data2 -v
/root/sql1/tpcc_log:/var/opt/mssql/log2 --name sql1 -d
mcr.microsoft.com/mssql/server:2019-latest
Table 1 Docker run parameters
Parameter Description
-e Sets environment variables, in this case options f or licensing and the SA password are set
-p Publishes the SQL Server port 1433 inside the container as 1401 on the host
-v Bind mount f or a volume. In this example three are specif ied. The f ormat is local
mount:container mount
--name Name of the container, otherwise it will be assigned a random identif ier
-d Container image to run. If it does not exist, it will try to locate it f rom any conf igured
repositories and download it
4.2.7 Kubernetes
Due to the clustered architecture of Kubernetes, there are special storage considerations when running SQL
Server instances or SQL Server Big Data Clusters on Kubernetes. Kubernetes has created its own method of
dealing with persistent storage in a Kubernetes cluster using persistent volumes. PowerStore storage
integrates with Kubernetes through the PowerStore CSI driver. The PowerStore CSI driver supports storage
volumes only. Kubernetes clusters running on PowerStore X models can either use the vSphere Cloud
15 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4Sizing and perf ormance optimization
Provider f or virtual volumes or the PowerStore CSI driver f or storage volumes. Detailed inf ormation about
running SQL Server Big Data Clusters on PowerStore is available in the document Dell EMC PowerStore:
SQL Server 2019 Big Data Clusters on Dell.com/StorageResources. The PowerStore CSI driver and CSI
drivers f or other Dell Technologies products can be f ound on GitHub.
Whenever possible make sure to perf orm sto rage operations through Kubernetes. In some cases, modif ying
CSI volumes directly on the PowerStore appliance can cause CSI operations to f ail or volumes to be
orphaned. For example, CSI volumes added to a volume group need to be removed f rom the volume group
bef ore the CSI driver can delete them.
The capabilities of the Kubernetes CSI specif ication are constantly evolving to support additional enterprise
storage f eatures, so make sure to use the latest Dell Technologies PowerStore CSI driver and keep up to
date on new releases. The latest documentation f or Dell Technologies CSI drivers f or all Dell EMC storage
products can be f ound at dell.github.io/storage-plugin-docs.
4.2.8 SQL Server Kubernetes deployment
Dell EMC PowerStore storage f or SQL Server running on Kubernetes is deployed and managed almost
entirely through Kubernetes. The PowerStore CSI driver translates Kubernetes storage provisioning
commands into PowerStore storage provisioning commands that are orchestrated on the storage appliance.
Since common storage provisioning tasks such as creating, deleting, and expanding volumes are done
through Kubernetes, the DBA or Kubernetes administrator can provision storage without knowing the details
of PowerStore or requiring direct access. This enables self -service of common storage provisioning tasks.
Once the Dell EMC PowerStore CSI driver is deployed, one or more Kubernetes storage classes will be
created. These storage classes describe the details of the CSI driver, encapsulate the connectivity and
protocol options of the storage, and contain def aults f or common storage provisioning values. Below is an
example of powerstore-xf s storage class def inition:
allowVolumeExpansion: true
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
annotations:
meta.helm.sh/release-name: powerstore
meta.helm.sh/release-namespace: csi-powerstore
creationTimestamp: "2020-10-07T13:33:14Z"
labels:
app.kubernetes.io/managed-by: Helm
name: powerstore-xfs
resourceVersion: "221004"
selfLink: /apis/storage.k8s.io/v1/storageclasses/powerstore-xfs
uid: cd013881-522e-4e16-bbd0-1f3c31315c94
parameters:
FsType: xfs
provisioner: csi-powerstore.dellemc.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
Kubernetes storage is provisioned as Persistent Volumes and Persistent Volume Claims. More inf ormation on
Persistent Volumes and Persistent Volume Claims can be f ound at Kubernetes.io. For example, to create
three volumes f or a SQL Server pod running on Kubernetes, the def initions are stored in a YAML f ile:
16 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4Sizing and perf ormance optimization
# cat pvc.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: mssql-data
annotations:
volume.beta.kubernetes.io/storage-class: powerstore-xfs
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 8Gi
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: mssql-data2
annotations:
volume.beta.kubernetes.io/storage-class: powerstore-xfs
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: mssql-log2
annotations:
volume.beta.kubernetes.io/storage-class: powerstore-xfs
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 2Gi
To create the persistent volume claims, the YAML f ile above is used as input. Running the f ollowing
command will create the volumes on PowerStore and create a volume alias that can be used when creating
the SQL Server pod.
#kubectl create -f pvc.yaml
Next, to deploy SQL Server a def inition f ile is also used. The persistentVolumeClaim attributes in the
def inition f ile ref er to the Persistent Volume Claims created in the previous step.
#cat sql.yaml
apiVersion: apps/v1
17 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4Sizing and perf ormance optimization
kind: Deployment
metadata:
name: mssql-deployment
spec:
replicas: 1
selector:
matchLabels:
app: mssql
template:
metadata:
labels:
app: mssql
spec:
terminationGracePeriodSeconds: 30
hostname: mssqlinst
securityContext:
fsGroup: 10001
containers:
- name: mssql
image: mcr.microsoft.com/mssql/server:2019-latest
ports:
- containerPort: 1433
env:
- name: MSSQL_PID
value: "Developer"
- name: ACCEPT_EULA
value: "Y"
- name: SA_PASSWORD
valueFrom:
secretKeyRef:
name: mssql
key: SA_PASSWORD
volumeMounts:
- name: mssqldb
mountPath: /var/opt/mssql
- name: mssqldata
mountPath: /var/opt/mssql/data2
- name: mssqllog
mountPath: /var/opt/mssql/log2
volumes:
- name: mssqldb
persistentVolumeClaim:
claimName: mssql-data
- name: mssqldata
persistentVolumeClaim:
claimName: mssql-data2
- name: mssqllog
persistentVolumeClaim:
claimName: mssql-log2
---
18 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4Sizing and perf ormance optimization
apiVersion: v1
kind: Service
metadata:
name: mssql-deployment
spec:
selector:
app: mssql
ports:
- protocol: TCP
port: 1433
targetPort: 1433
type: NodePort
To deploy SQL Server inside of a Kubernetes pod, f irst a secret is created to store the password:
#kubectl create secret generic mssql --from-literal=SA_PASSWORD="P@ssword1"
Next, using the YAML f ile above as input, kubectl create will deploy the SQL Server instance on Kubernetes :
# kubectl create -f sql.yaml
4.3 RAID configurations and storage pools
Since the inception of storage devices that used multiple drives f or a single volume, the topic of RAID
conf iguration and storage pools has been highly debated. Designing and maintaining the proper design could
be time consuming and the wrong decisions could have a negative impact on perf ormance. In addition,
reconf iguring the storage layout of ten required considerable planning.
PowerStore OS leverages the capabilities of f lash-based storage f or maximum perf ormance and capacity,
eliminating the need f or administrators to conf igure RAID or storage pools. Most existing SQL Server
publications that discuss RAID levels and conf iguration were written based on older technology and apply to
spinning drives. Theref ore, these concepts do not apply to PowerStore. Dell Technologies recommends
f ollowing the guidance in this paper and associated publications f or best perf ormance and availability. For
f urther questions, contact a Dell Technologies representative.
4.4 Validating the I/O path
Bef ore deploying workloads on PowerStore, it is a good idea to validate the I/O path between the server and
the array. Running a large block sequential read test using small f iles should saturate the path between the
server and the array. This test verif ies that all paths are f ully f unctional and can be used f or I/O traf f ic. Run
this test on an isolated server and PowerStore. Running this test in a production environment could cause
signif icant perf ormance issues f or active workloads. To validate the I/O path, run a large block sequential read
test using the f ollowing guidelines:
• Create one volume per node.
• Format the volumes using a 64 KB allocation unit.
• Use a block size of 512 KB f or the test.
• Conf igure the test f or 32 outstanding I/Os.
• Use multiple threads; eight is the recommended starting point .
19 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4Sizing and perf ormance optimization
If the displayed throughput matches the expected throughput f or the number of HBA ports in t he server, the
paths between the server and PowerStore are set up correctly.
4.5 MPIO
A best practice f or SQL Server hosts is to provide multiple paths to the storage f or resiliency and
perf ormance. This protects against possible data loss or downtime, should a physical component f ail. In
scenarios where multiple paths to the storage are used, MPIO must be enabled and conf igured. See the
document Dell EMC PowerStore Host Configuration Guide on the PowerStore Inf o Hub f or recommendations.
20 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4Perf ormance
5 Performance
Managing storage perf ormance with PowerStore is simple and intuitive. The perf ormance policy can be
adjusted at the volume or vVol level by selecting high, medium, or low. Perf ormance policies are relative in
PowerStore, so leaving all volumes at the def ault of medium provides equal perf ormance to all volumes. The
volumes all perf orm at the highest level until a PowerStore volume is s et to a dif f erent perf ormance policy.
Selecting a perf ormance policy sets a relative priority f or the volume using a share-based system such that
when resources are constrained, the resource with the higher perf ormance policy will receive priority. If there
is no PowerStore resource constraint, the volumes will perf orm equally.
5.1 PowerStore Node Affinity
In some cases, SQL Server can be very storage resource intensive. For I/O intensive SQL Server databases
multiple volumes are recommended. This allows the f lexibility to balance the workload across both nodes in a
PowerStore appliance. The “ownership” of a volume by a node is known as Node Af f inity.
PowerStore perf orms best when the system perf ormance is balanced across both nodes in the appliance.
The Node Af f inity is set when the volumes are mapped to a host. By def ault, volume Node Af f inity alternates
between the two nodes in the appliance when mapping volumes to a host to balance the workload. In most
cases this suf f iciently balances the load across both nodes in the appliances. Since every SQL Server
workload is unique, and storage access patterns depend on database layout across one or more f iles, Node
Af f inity adjustments may be necessary to maximize overall system perf ormance.
Overall system and individual appliance perf ormance can be viewed in the Hardware section on the
Perf ormance tab. Scrolling down in the view will reveal perf ormance by node.
Figure 1 PowerStore hardware perf ormance
21 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4Perf ormance
Ideally, each node in the appliance will have equal perf ormance. If the workload is unbalanced between the
nodes you can evaluate the Node Af f inity of the workload and adjust.
Volume node af f inity is shown in the Volumes list under Storage. By def ault, this column is not displayed. To
add it to the view, click on the Columns selection icon next to the f ilter icon. Scroll down the list and select
Node Af f inity.
Figure 2 Selecting additional columns in the Volumes list
Figure 3 Volumes list with Node Af f inity added
“System select node A” and “System select Node B” are the system assigned values. Node Af f inity can be set
using the PowerStore CLI (CLI) or PowerStore REST API. This example uses the CLI.
The f ollowing command will display the details of a volume named “SQLData2-007’:
pstcli -destination -u -p
/volume -name "SQLData2-007" show
22 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4Perf ormance
In order to make changes the volume id is needed. You can either f ind the volume ID f rom the above
command or append “ -select id” to return only the volume id:
pstcli -destination -u -p
/volume -name “SQLData2-007” show -select id
Note: The “id” used here is not displayed in the PowerStore Manager and theref ore needs to be discovered .
Once the volume ID is discovered it can be used in the f ollowing command to set the Node Af f inity . The
f ollowing command sets the Node Af f inity for volume “a5edf f 43-e9a7-48bd-9b19-e46c7d87d7d2” to
“Pref erred_Node_A”. Valid values are “Pref erred_Node_A”, “Pref erred_Node_B”, and
“System_Select_At_Attach”.
pstcli - destination -u -p
/volume a5edff43-e9a7-48bd-9b19-e46c7d87d7d2 set -node_affinity
“Preferred_Node_A”
Note: Once Node Af f inity is set to “Pref erred_Node_A” or Pref erred_Node_B”, it will no longer be managed by
PowerStore unless it is set to “System_Select_At_Attach”.
5.2 Virtualization
When running SQL Server inside virtual machines (VMs), it is recommended to f ollow the VMware document
SQL Server on VMware Best Practices Guide f or perf ormance and scalability. This guide provides guidance
f or conf iguring SQL Server, the operating system, and virtual machines f or best perf ormance on VMware.
For tuning recommendations and best practices regarding VMware vSphere, VMware ESX, and PowerStore
T or PowerStore X (AppsOn), f ollow the recommendations in the documents Dell EMC PowerStore:
Virtualization Integration and Dell EMC PowerStore Virtualization Infrastructure Guide on
Dell.com/StorageResources.
5.3 AppsON
When running workloads on virtual machines on the PowerStore X appliance, or AppsON mode there are
some important considerations when sizing workloads.
General VMware tuning and resource allocation principles apply, consult the VMware article About vSphere
Resource Management f or general tuning guidelines. If resources in the vSphere cluster become a
bottleneck, guest storage perf ormance will suf f er, reducing the ef f ectiveness of running workloads in AppsON
mode.
5.3.1 Resource reservation
PowerStore X appliances reserve approximately half the CPU and memory resources f or running PowerStore
appliance tasks. When sizing workloads to run on the appliance, this needs to be considered. This reservation
is visible in vSphere as the CPU and memory will be displayed as consumed by the PowerStore X controller
virtual machines. In addition, the ESXi cluster can’t be run at 100% capacity without incurring degraded
perf ormance. A minimal amount of resources are required f or ESXi overhead. Consult the VMware articles
Conf iguring Resource Allocation Settings and Administering Memory Resources f or resource reservation and
sizing guidance.
23 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4Perf ormance
For production applications where guaranteed perf ormance is necessary, make sure to size f or possible node
f ailover in the PowerStore cluster.
5.3.2 SQL Server virtual machines
General best practices apply when running SQL Server virtual machines in AppsOn mode with a couple of
items of note. First, VMware vVols will typically be used as storage f or VMDKs. While other storage options
are still available, PowerStore X is optimized f or vVols storage so this should be the f irst choice. Also, use the
VMware Paravirtualized SCSI (PVSCSI) Controller as the virtual SCSI Controller. The PVSCSI controller
improves perf ormance and reduces CPU overhead.
For additional best practices on running SQL Server virtual machines consult the VMware guide Architecting
Microsof t SQL Server on VMware vSphere.
5.3.3 Multi-appliance virtual machine migrations
Starting with PowerStoreOS 2.0, up to f our PowerStore X appliances can be added to a PowerStore X
cluster. AppsOn workloads can then be moved among appliances in the PowerStore X cluster leveraging
VMware vMotion. When moving virtual machines among appliances in an AppsOn cluster, the storage will not
migrate since PowerStore Storage Containers are presented as a vVols Datastore across all appliances in the
cluster. However, the vVols do reside on a single appliance. Theref ore, this needs to be considered when
migrating VMs between clustered appliances. For a VM, running the compute on one appliance when the
vVols reside on another appliance will result in degraded perf ormance.
In the Compute-> Virtual Machines view below is a VM running on “PS-9-appliance-1-node-B”
Figure 4 Virtual Machine residence
Examining the vVols that belong to this VM shows that they are on PS-9-appliance-2. These vVols should be
migrated to PS-9-appliance-1. This is done by selecting a volume and then selecting “Migrate”. This can also
be done in the PSTCLI using the “migration_session create” command.
24 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4Perf ormance
Figure 5 vVol residence
Once the migration has been started, it can be viewed in the Migration section.
Figure 6 vVol migration
5.3.4 SQL Server Big Data Clusters
The Kubernetes platf orm perf orms resource balancing and scheduling within the Big Data Cluster and is not
aware of the virtualization layer. When optimizing f or perf ormance, it is recommended to balance the
workload across all nodes in the AppsON environment. In a simple scenario this means an even number of
worker nodes in the Big Data Cluster. In more complex scenarios, this may mean placing certain nodes in the
AppsON environment and leveraging Kubernetes scheduling f eatures to place targeted workloads on
AppsON nodes. These concepts are covered in the Kubernetes documentation Assign Pods to Nodes.
25 Dell EMC PowerStore: Microsoft SQL Server Best Practices | H18250.4You can also read
