VNX and Microsoft Best Practice

VNX and Microsoft Best practice
Niko Duki
Technology Consultant | MidTier Specialist niko.dukic@emc.com
Copyright 2012 EMC Corporation. All rights reserved.
Agenda
EMC and Microsoft Alliance VNX general best practice
VNX and Microsoft integrations

VNX best practice for Microsoft applications
Exchange Server SQL Server Sharepoint Server
Top 5 Reasons Why EMC for Microsoft

1) EMC and Microsoft have been engaged as strategic partners for over 16 years 2) EMC has over 300 published technical solutions and another 100 data sheets on Microsoft technologies 3) EMC is Microsofts #3 Enterprise Partner (out of 32) for total revenue involving Microsoft products 4) EMC has over 2500 Microsoft Certified Professionals (MCPs) 5) Microsoft is EMCs 5th largest customer with over 400 CLARiiONs and 40 Symmetrix installed worldwide
VNX General Best practice
VNX General Best Practice

Distribute load over available hardware resources
Design for 70 percent utilization (activity level) for hardware resources
Avoid mixing response time sensitive I/O with large block I/O and high load sequential I/O Best practices target 80% of customer solutions
Understanding workloads is key

Not just IOPS; what kind of IOPS?
VNX General Best Practice: Memory

Install software and enablers before setting read and write cache sizes
Set read cache to roughly 10% and give remaining memory to write c ache Leave cache page size at 8 KiB for majority of configurations. Only adjust if predominant workload I/O size fits 2, 4, or 16 KiB Start with low watermark of 60% and high watermark of 80%. Lowering watermarks might help reduce frequent forced flushing
VNX General Best Practice: Drive placement

Spread drives across all available buses
Avoid placing drives in the DPE/DAEOS enclosure that will participate in a RAID group outside the DPEDAEOS The guideline is to prevent a RG rebuild or verify process in the event of a rare power outage. This is one area where guidelines will be broken; not following the gui deline does not effect support in any way Avoid placing more than 8 flash drives per bus, when used for FAST C ache
Resource Limits
Frontend Host Port Limits
Module 8 Gb FC Single Port 760 MiB/s All Ports (Single Card) 1600 MiB/s (VNX51005500) 3000 MiB/s (VNX57007500) 1500 MiB/s 1600 MiB/s (VNX51005500) 2400 MiB/s (VNX57007500) 1300 MiB/s
10 Gb iSCSI NEW 10 Gb iSCSI

(303164104D)
1000 MiB/s 1200 MiB/s

920 MiB/s
10Gb FCoE
Resource Limits
VNX File Limits
Module 1 GbE 10 GbE Optical NEW 10 GbE Optical
(303195101B)
Single Port 110 MiB/s 1100 MiB/s 1200 MiB/s 1200 MiB/s
All Ports (Single Card) 440 MiB/s 1500 MiB/s 2400 MiB/s 2400 MiB/s
NEW 10 GbE Copper

(303164104D)
Data Mover bandwidth limited to dual 8 Gb FC attach

Per Data Mover ~1500 MiB/s Scale environment by adding active Data Movers, or use VG2/VG8 with 4x FC ports via RPQ
Drive Type
Match the appropriate drive type to the expected workload:
Drive Type Flash SAS
Workload Examples Extreme performance; best performance for transactional random workloads
General performance tier

Wellbehaved streaming, aging data and archive purposes, and backups
NLSAS
10
Drive Type and IOPS

Rules of thumb
These are a conservative starting point for sizing, not the absolute maximums IOPS assumes small block random with good response time Drives are capable of a sustained IOPS workload based on drive type, as follows:
Drive Type NLSAS SAS 10K SAS 15K Flash
IOPS 90 150 180 3500
11
RAID Level
For best performance from the least number of drives, match the appropriate RAID level with the expected workload:
RAID Level
Workload Examples
RAID 1/0
RAID 5
Heavy transactional with high (greater than 25 percent) random write component, and you plan to stay on HDD Mediumhigh performance, generalpurpose workloads, and sequential NLSAS, readbiased workloads, archiving; additional RAID protection
RAID 6
12
Traditional RAID Drive Count

Traditional RGs might be selected for specific data placement and/or full stripe writes Certain drive counts are more likely to enable this behavior, though these optimizations can also occur with nonpreferred drive counts With a predominance of largeblock sequential operations the following applies:
RAID Level
RAID 5 RAID 6 RAID 1/0
RAID group count

4+1 (256 KiB fullstripe) 8+1 (512 KiB fullstripe) 8+2 (512 KiB fullstripe)
4+4 (256 KiB fullstripe, no parity calculations) 1+1 1 for VNX File volumes, and stripe 4 volumes
13
Storage Configuration
Use the default horizontal positioning method
With current architecture, there are now almost no advantages to using vertical positioning Storage pools do not use vertical provisioning and should not be forced to do so
Use large element size only when workload is largeblock random read
Only 4+1 RAID 5 supported 512 KiB element = 2 MiB fullstripe write
Fullstripe writes are not expected; informational only
14
Storage Pool Failure Domains

Minimize failure domains
Dont t mix primary and replica, table spaces and redo logs
DB1 Tables
DB1 Logs
DB2 Tables
HomeDirs/Users
DB2 Logs
Home Dir/User Backup
15
Storage Pool Tiers

Use RAID 5 with a preferred count of 4+1 for the best performance versus capacity balance
Using 8+1 improves capacity utilization at the expense of slightly lower availability
Use RAID 6 for NLSAS tier

Options for preferred drive count are 6+2 and 14+2 where 14+2 provides the highest capacity utilization option for a pool, at the expense of slightly lower availability
Consider the following rule of thumb for tier construction:
Tier Name Extreme Performance Performance Capacity
Drive Type Flash SAS NLSAS
RAID Level 4+1, RAID 5 4+1 or 8+1, RAID 5 6+2 or 14+2, RAID 6
Avoid a drive count that results in a small remainder when divided by the preferred drive count specified
16
Single Storage Pool

Single Pool?
Modest bandwidth loads can cohabitate if working sets dont overlap on the same drives Thats hard to determine; so if in doubt, separate
This design can work with a 3tier design if the DB has a well-defined working set that inhabits primarily top two tiers. Typically used in smaller systems. Note: if backup is hitting high rates during busy DB hours, NLSAS drives on the same bus as SAS can slow down access.
5/20/75 Mix
DB1 Tables
DB: 8 KiB Random
DB2 Tables Backup

Backup: 256 KiB sequential
17
Storage Pool Virtual LUN Type

Storage Pool LUNs can be created as either thick (fully allocated) or thin (virtually provisioned)
LUN Type Thin Usage Maximize easeofuse and capacity utilization Planning to implement VNX Snapshots and/or block compression Storage efficiency requirements outweigh performance requirements Considerations 8 KiB tracking granularity increases metadata workload overhead; not all tracking is 8 KiB; contiguous space allocations are tracked as single entry in table Adding a Flash tier to the pool can improve performance as Thin LUN metadata is promoted to the Flash tier Thick LUN performance is comparable to traditional LUN performance 1 GiB tracking granularity
Thick
Highest level of poolbased performance Use only Thick LUNs for VNX File; instead use a thinenabled file system for virtual provisioning
18
VNX and SQL Best practice
19
Key Perfmon Counters

Perfmon Counter
Disk Reads/sec Disk Writes/sec Disk Transfers/sec Measures:
Description
Number of IOPs (Read, Write, Total)
Average Disk Bytes/Read Average Disk Bytes/Write
Measures:
Size of I/Os
Average Disk sec/Read Average Disk sec/Write
Measures: Disk latency 1 - 5 milliseconds (ms) for Log (ideally 1 ms or less on average) 5 - 20 ms for Database Files (OLTP) (Ideally 10 ms or less on average)
Current Disk Queue Length
Measures: # of outstanding I/Os waiting to be serviced High queue depths + high latencies = performance problem! High queue depth + low latencies = active and efficient system.
Disk Read Bytes/sec Disk Write Bytes/sec
Measures storage: bandwidth
20
A Day in the life of SQL Server

SQL Server Storage I/O
Plan for user load peaks, not systematic peaks
21
VNX and SQL Best Practice

Understand the applications using SQL Server
SQL Server is just the database!
Plan for performance and capacity

Choose the appropriate disk type and RAID protection Size first for performance, than capacity
Isolate files for maximum performance

Database Files: RAID 5 Log Files: RAID 1/0 Data Warehouse: RAID 5 or 6 Group workloads of similar I/O together
Use SQLIOsim.exe to validate all changes to storage

No need for SQL server to be installed
22

Consider log performance
Sequential workload and can cause contention if put on the same drives as user db Creating another log file will not help as it writes in single file only Consider recovery scenarios plan for recovery, not backup
Consider tempdb performance

Global resource to all tables in instance and can be very io intensive Can cause disk contention if put on the same drives as user db Start with reasonable size, 1 to 10 % of total size Set auto increment to a minimum of 10 % to reduce fragmentation
Divide filegroups among different spindles

Filegroups can be accessed in parallel
23

Balance database and log LUNs between SPs
Enable FAST cache only on highly active databases with OLTP workloads
Disable FAST cache for logs Disable FAST cache for sequential workloads if possible
Consider FAST VP on large databases

Control when FAST VP will move data not to interfere with high usage time
Align disk windows partitions
24
Microsoft SQL Server

VNX 5700
(20) SAS drives in pool (4) Flash drives in FAST Cache
>2x performance improvement in TPS with no increase in response time

~ 4x performance improvement in TPS with only x2 increase in response time
SAS Only
1448 TPS, 0.8s Ravg 5778 TPS, 1.95s Ravg
SAS + FAST Cache

Recommendation Pools FAST Cache FAST VP
YES YES YES
http://powerlink.emc.com/km/live1/en_US/Offering_Basics/White_Paper/h8188-virtualizing-sql-vnxvsphere-psg.pdf
Virtualizing SQL Server 2008 Using EMC VNX Series and VMware vSphere 4.1
Flash in Cache and SAS in Pool
25
VNX and Exchange Best practice
26
VNX and Exchange Best Practice

New storage schema to reduce disk requests
Io size is larger
Messages per day Exch2007 IOPS Exch2010 IOPS (standalone database) Exch2010 IOPS for protected database
25
0.11
0.040
0.030
50
100
0.18
0.32
0.060
0.120
0.050
0.100
Version
IO Size
Exchange 2003 Exchange 2007 Exchange 2010
4 kB 8 kB 32 kB (BDM is 256 kB)
27

Background Database Maintenance (BDM) is online defragmentation and online database scanning BDM produces a large sequential 256 KB read IO
BDM is enabled by default and runs 24x7 on both active and passive database copies
28
Disk type selection

The types of disks that are appropriate for your Exchange Server 2010 deployment depend on a number of factors, including your users mailbox size limit and IOPS requirements.
SAS disks provide high capacity with moderate IO speed, which makes them highly suitable for Exchange Server 2010 environments with high IOPS per user requirements. NL SAS disks are a good fit for the less demanding IO requirements of Exchange Server 2010. NL SAS disks are typically the best choice for larger mailbox sizes and average to heavy IO profiles.
Flash drives are not the best choice for Exchange data, but they can be appropriate when using FAST Cache
29
RAID Type selection

Any RAID type can be used, provided there are enough disks to handle the IO and storage capacity requirements. RAID 1/0 is the best choice for Exchange Server 2010, especially if NL/SAS drives are used. RAID 5 is most appropriate in environments with low IO requirements and where large mailboxes are being deployed. RAID 6 can be used but has much more impact on write requests
30

isolate the Microsoft Exchange Server database and log workload from other IO-intensive applications and workloads always calculate disk IO requirements before calculating capacity requirements. Select appropriate disk types that meet your IO and capacity requirements. do not place both database and log files for the same database on the same physical disks Deploy each DAG copy on its own set of physical disks
Spread the load as evenly as possible across storage array resources
31

Format Windows NTFS volumes used for Exchange databases and logs with an allocation unit size of 64 KB The use of FAST Cache on VNX systems neither benefits nor detracts from Exchange performance because of the Exchange IO pattern If FAST Cache is used segregate database volumes from log volumes
Enable FAST Cache only for database volumes
It is not recommended to use FAST Cache for logs

The use of FAST VP with Exchange Server 2010 on VNX is not recommended (BDM activity affects storage tiering priorities)
32

FAST Cache does not particularly benefit Exchange 2010
Exchange has little to no data locality
FAST VP is not presently a good choice for Exchange 2010

BDM skews the data movement, which is on a 24 hour cycle Exchange allocates data space in a way that works against the FAST VP algorithms
Use the SOAPTool utility to evenly distribute data on Pool LUNs

Improves Jetstress performance
Recommendation Pools YES, with SOAP Tool Utility FAST Cache Neutral FAST VP NO, BDM causes non-optimized relocations
33

Either RAID groups or storage pools can be used for Exchange Server 2010 on VNX.
With RAID 5 do not stripe metaLUNs across multiple RAID groups (reduces Exchange performance)
Use homogeneous Pools or RAID Groups
When using storage pools, the following guidelines apply:

Design and grow storage pools by using the appropriate multiplier for best performance (R1/0 4+4, R5 4+1, R6 6+2).
Use Thick LUNs only for mission-critical jobs; avoid Thin LUNs for > 100 users
Set the storage array page size parameter to 16 KB (only if Exchange is the only or mosst important application).
34

Key requirements for Exchange Server 2010 include the following:
Total number of users (mailboxes) in the Exchange environment Number of users per mailbox server User IO profile (number of messages sent/received per day) Mailbox size limit Read/write ratio Average message size Outlook mode Log protection buffer Deleted items retention policy User concurrency requirements If replication is needed, the number of DAGs and database copies required Backup and restore requirements (RTO/RPO) Third-party software that affects space or IO (for example, Blackberry)
Technet: Exchange 2010 Mailbox Server Role Requirements Calculator
35
VNX and Sharepoint Best practice
36
VNX and Sharepoint

Cost effective Tiered Storage Block, file, object Externalize BLOBs
Virtual Server Virtual Server Virtual Server
Exchange
SQL Server
SharePoint
95% shrinkage of SQL database size Integrated data protection provides peace of mind without the complexity
37
SharePoint Performance Considerations

Performance for SharePoint highly use case dependent
SharePoint workload for content management
Can be characterized by 60/20/10/10 for Browse/Modify/Search/Upload File size, distribution, and concurrent access impact performance
Symptoms vs. Remedy

Symptoms often occur during individual tasks (e.g. file upload by user) Sizing however needs to factor in system level workloads for the entire farm
The storage subsystem is rarely the bottleneck

Generally web front end (WFE) CPU represents the bottleneck VNX FAST Suite enables very efficient configurations (majority NL-SAS, 2-5% SSDs) Search functions are the workloads that happen to benefit the most
38
SharePoint Performance Considerations

SQL Database not efficient at handling files IO
Each write represents an update of the table and the log Non-externalized storage formats use the SQL buffer pool when the data pages are accessed Large files and high concurrency can lead to buffer overruns compounding the issue Other processes such as index rebuilds can also compete for the same server resources RBS: Remote BLOB storage supported by VNX and Metalogix
39
VNX and Sharepoint Best Practice

SharePoint Component FAST VP FAST Cache Workload
R:W Ratio of 90:10; 32K block read, 64K write; Small working set. Search Index re-uses the same blocks on disk as working space to process list items during indexing. Storage IO quiet between crawls. Highly changing, throw-away data. R:W Ratio of 70:30; 32K read, 64K write; Small working set. Query improves due to random large block reads/writes being serviced by FAST Cache, but Query storage is large and costly in FAST Cache. Highly-read data with small burst write changes. R:W Ratio of 50:50; 8K read, 32K write. TempDB (database page reuse) is ideally suited to FAST Cache algorithms. Same blocks are re-used on disk and performance of TEMPDB directly affects SharePoint performance request.
Search Index
++
Search Query
tempdb
Content DB
+ -
+ -
R:W Ratio of 95:5; 16K (read and write); Working set reduced via RBS. Low IOPs requirements does not require FAST Cache. DB Index operations see an improvement.
Low IOPs requirements, large-block I/O.
BLOB Store
40
FAST Cache for SharePoint 2010

Enabling Fast Cache on system and search databases (Crawl, Property and tempdb) improves Search and Index performance
Crawl operations improved by 90%
User search response time improved by 27% Maximum user capacity increased by 10%
Powerful
41

VNX and Microsoft Best Practice

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

VNX and Microsoft Best Practice

Загружено:

Авторское право:

Доступные форматы

VNX and Microsoft Best practice

Copyright 2012 EMC Corporation. All rights reserved.

VNX and Microsoft integrations

Copyright 2012 EMC Corporation. All rights reserved.

Top 5 Reasons Why EMC for Microsoft

Copyright 2012 EMC Corporation. All rights reserved.

VNX General Best practice

Copyright 2012 EMC Corporation. All rights reserved.

VNX General Best Practice

Understanding workloads is key

Copyright 2012 EMC Corporation. All rights reserved.

VNX General Best Practice: Memory

Copyright 2012 EMC Corporation. All rights reserved.

VNX General Best Practice: Drive placement

Copyright 2012 EMC Corporation. All rights reserved.

10 Gb iSCSI NEW 10 Gb iSCSI

1000 MiB/s 1200 MiB/s

Copyright 2012 EMC Corporation. All rights reserved.

NEW 10 GbE Copper

Data Mover bandwidth limited to dual 8 Gb FC attach

Copyright 2012 EMC Corporation. All rights reserved.

Drive Type Flash SAS

General performance tier

Copyright 2012 EMC Corporation. All rights reserved.

Drive Type and IOPS

Drive Type NLSAS SAS 10K SAS 15K Flash

IOPS 90 150 180 3500

Copyright 2012 EMC Corporation. All rights reserved.

Copyright 2012 EMC Corporation. All rights reserved.

Traditional RAID Drive Count

RAID group count

Copyright 2012 EMC Corporation. All rights reserved.

Copyright 2012 EMC Corporation. All rights reserved.

Storage Pool Failure Domains

Home Dir/User Backup

Copyright 2012 EMC Corporation. All rights reserved.

Storage Pool Tiers

Use RAID 6 for NLSAS tier

Consider the following rule of thumb for tier construction:

Tier Name Extreme Performance Performance Capacity

Drive Type Flash SAS NLSAS

Copyright 2012 EMC Corporation. All rights reserved.

Single Storage Pool

DB2 Tables Backup

Copyright 2012 EMC Corporation. All rights reserved.

Storage Pool Virtual LUN Type

Copyright 2012 EMC Corporation. All rights reserved.

VNX and SQL Best practice

Copyright 2012 EMC Corporation. All rights reserved.

Key Perfmon Counters

Average Disk Bytes/Read Average Disk Bytes/Write

Average Disk sec/Read Average Disk sec/Write

Current Disk Queue Length

Disk Read Bytes/sec Disk Write Bytes/sec

Measures storage: bandwidth

Copyright 2012 EMC Corporation. All rights reserved.

A Day in the life of SQL Server

Copyright 2012 EMC Corporation. All rights reserved.

VNX and SQL Best Practice

Plan for performance and capacity

Isolate files for maximum performance

Use SQLIOsim.exe to validate all changes to storage

Copyright 2012 EMC Corporation. All rights reserved.

VNX and SQL Best Practice