VNX and Microsoft Best Practice

1 © Copyright 2012 EMC Corporation. All rights reserved.

VNX and Microsoft Best practice

Niko Dukić Technology Consultant | MidTier Specialist [email protected]


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 Microsoft’s #3 Enterprise Partner (out of 32) for total revenue involving Microsoft products

4) EMC has over 2500 Microsoft Certified Professionals (MCPs)

5) Microsoft is EMC’s 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 cache

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/DAE‐OS enclosure that will participate in a RAID group outside the DPE‐DAE‐OS

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 guideline does not effect support in any way

Avoid placing more than 8 flash drives per bus, when used for FAST Cache


Resource Limits • Front‐end Host Port Limits

Single Port 760 MiB/s 1000 MiB/s 1200 MiB/s 920 MiB/s

All Ports (Single Card) 1600 MiB/s (VNX5100‐5500) 3000 MiB/s (VNX5700‐7500) 1500 MiB/s 1600 MiB/s (VNX5100‐5500) 2400 MiB/s (VNX5700‐7500) 1300 MiB/s

Module 8 Gb FC 10 Gb iSCSI NEW 10 Gb iSCSI (303‐164‐104D) 10Gb FCoE


Resource Limits • VNX File Limits

Module 1 GbE 10 GbE Optical NEW 10 GbE Optical (303‐195‐101B)

NEW 10 GbE Copper

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

(303‐164‐104D) 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:

Workload Examples Extreme performance; best performance for transactional random workloads

General performance tier

Well‐behaved streaming, aging data and archive purposes, and backups

Drive Type Flash SAS NL‐SAS


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:

IOPS 90 150 180 3500

Drive Type NL‐SAS SAS 10K SAS 15K Flash


RAID Level • For best performance from the least number of drives, match the appropriate RAID level with the expected workload:

Workload Examples Heavy transactional with high (greater than 25 percent) random write component, and you plan to stay on HDD Medium‐high performance, general‐purpose workloads, and sequential NL‐SAS, read‐biased workloads, archiving; additional RAID protection

RAID Level RAID 1/0 RAID 5 RAID 6


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 non‐preferred drive counts • With a predominance of large‐block sequential operations the following applies:

RAID Level RAID 5 RAID 6 RAID 1/0

RAID group count 4+1 (256 KiB full‐stripe) 8+1 (512 KiB full‐stripe) 8+2 (512 KiB full‐stripe) 4+4 (256 KiB full‐stripe, no parity calculations) 1+1 1 for VNX File volumes, and stripe 4 volumes


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 large‐block random read – Only 4+1 RAID 5 supported – 512 KiB element = 2 MiB full‐stripe write • Full‐stripe writes are not expected; informational only


Storage Pool Failure Domains • Minimize failure domains – Don’t t mix primary and replica, table spaces and redo logs DB1 Tables DB1 Logs

DB2 Logs Home Dir/User Backup

DB2 Tables HomeDirs/Users


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 NL‐SAS 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 NL‐SAS

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


Single Storage Pool • Single Pool? – Modest bandwidth loads can cohabitate if working sets don’t overlap on the same drives – That’s hard to determine; so if in doubt, separate

5/20/75 Mix This design can work with a 3 tier design if the DB has a welldefined working set that

DB1 Tables DB2 Tables Backup

DB: 8 KiB Random Backup: 256 KiB sequential

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.


Storage Pool Virtual LUN Type • Storage Pool LUNs can be created as either thick (fully allocated) or thin (virtually provisioned)

LUN Type Usage Considerations

Thin • Maximize ease‐of‐use and capacity utilization

• 8 KiB tracking granularity increases metadata workload

• •

Planning to implement VNX Snapshots and/or block compression Storage efficiency requirements outweigh performance requirements

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 • •

Highest level of pool‐based performance Use only Thick LUNs for VNX File;

• Thick LUN performance is comparable to traditional LUN

instead use a thin‐enabled file system performance • 1 GiB tracking granularity for virtual provisioning


VNX and SQL Best practice


Key Perfmon Counters

Perfmon Counter Description

Disk Reads/sec

Disk Writes/sec

Disk Transfers/sec

Measures: 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


A Day in the life of SQL Server… SQL Server Storage I/O

Plan for user load peaks, not systematic peaks…


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



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



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


Flash in Cache and SAS in Pool

• VNX 5700 – (20) SAS drives in

pool – (4) Flash drives in

FAST Cache

• SAS Only – 1448 TPS, 0.8s Ravg

• SAS + FAST Cache – 5778 TPS, 1.95s Ravg

Recommendation – Pools YES – FAST Cache YES – FAST VP YES

Virtualizing SQL Server 2008 Using EMC VNX Series and VMware vSphere 4.1 http://powerlink.emc.com/km/live1/en_US/Offering_Basics/White_Paper/h8188-virtualizing-sql-vnx-

vsphere-psg.pdf

~ 4x performance improvement in TPS with only x2 increase in response time

Microsoft SQL Server

>2x performance improvement in TPS with no increase in response time

http://powerlink.emc.com/km/live1/en_US/Offering_Basics/White_Paper/h8188-virtualizing-sql-vnx-vsphere-psg.pdf












VNX and Exchange Best practice


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 0.18 0.060 0.050

100 0.32 0.120 0.100

Version IO Size

Exchange 2003 4 kB

Exchange 2007 8 kB

Exchange 2010 32 kB (BDM is 256 kB)



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


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


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



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



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)


• 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




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).



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


VNX and Sharepoint Best practice


VNX and Sharepoint

• Cost effective Tiered Storage

– Block, file, object

– Externalize BLOBs

• 95% shrinkage of SQL database size

• Integrated data protection provides peace of mind without the complexity

Exchange SQL Server SharePoint

Virtual Server Virtual Server Virtual Server


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


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


SharePoint Component

FAST VP FAST Cache

Workload

Search Index - ++

• 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.

Search Query + +

• 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.

tempdb + +

• 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.

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.

BLOB Store - - • Low IOPs requirements, large-block I/O.

VNX and Sharepoint Best Practice


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

Documents

VNX and Microsoft Best Practice