SharePoint 2010 – High AvailabilityConsiderations for SQL Server

Backend

Roger BreuTechnical Specialist Data Platformroger.breu@microsoft.com

Patching and service pack installationsHardware and software upgrades/migrationsSystem reconfigurationDatabase maintenanceApplication upgrade

Human error is the number one cause of failureSite disastersHardware malfunctionData corruptionSoftware crash

Availability during planned downtime

Protection against unplanned downtime

Why Do You Need HA/DR?

Agenda

Why care about SQL Server?SQL Server High Availability and Disaster RecoveryConfiguration Best PracticesOptimizing PerformanceQ&A

Why care about SQL Server?

SharePoint and SQL ServerSharePoint Admins and SQL DBA’s #!

SharePoint heavily dependent upon SQL

SQL DBA’s want control of DB’sDBA’s think SharePoint = DB sprawl

SharePoint Admins want control of FarmsYet, storage architecture and SQL Server availability/scalability is critical to success

SharePoint and SQL ServerYou need coordination to make it work!

SharePoint Admin and SQL DBA synchronize on DB’s required, sizing, growth, capacity, distribution, usage profiles, backup and restore, HA and DRDBA’s pre-construct and pre-size DB’s, monitor via SQLSharePoint Admin connects to DB’s, monitor via CACoordinate backup and restore

SQL Server High Availability and Disaster Recovery

SQL Server 2008 R2 HA/DR technologies

Database mirroring

Failover clustering

Transactional and peer-to-peer replication

Log shipping

Backup and restore

HA

HA

/DR

DR

DR

For SharePoint 2010

SQL Server Database Mirroring

Implemented on a per-database levelTransactions sent from Principal to MirrorPrincipal and Mirror must be separate SQL serversOptional “witness” server for automatic failoverProvides a “warm” standby in case of failure

SQL Server Database Mirroring Witness Server

Principal Mirror

Encrypted Channel

Everything OK?

I’m OK!Every

thing O

K?

Principal

Down!

3

4

21

2

5New

Principal

5

SQL Server Database Mirroring

Three operation modes:

Operation Modes

Mode Safety Level Transfer Mechanism Failover

High Safety/Protection

Full (no witness) Synchronous Manual

High Availability Full (with witness) Synchronous Manual and

Automatic

High Performance Off Asynchronous Forced

SQL Server Failover Clustering

Implemented at the SQL Server Instance levelShared cluster name and automatic failoverDisk subsystem is shared meaning single point of failure

SQL Failover Server Cluster

SharePoint Web Front Ends

Shared Disk Array

Node A Node B

Heartbeat

SQL Server Failover Clustering /2 datacenters

Disk subsystem can be replicated, no single point of failureReplication, especially synchronous will affect performance

SQL Failover Server Cluster

SharePoint Web Front Ends

Shared Disk Array

Node A Node B

Heartbeat

Shared Disk Array

SQL Server Failover Clustering

SQL Server High-Availability Mirroring

Time to failoverCluster member takes over immediately upon failure.

Mirror takes over immediately upon failure. (faster than failover clustering, no move of disks)

Steps required for failover?

Failure is automatically detected by database nodes; SharePoint Server 2010 references the cluster so that failover is seamless and automatic.

Failure is automatically detected by the database; SharePoint Server 2010 is aware of the mirror location, if it has been configured correctly, so that failover is automatic.

Protection against failed storage?Does not protect against failed storage, because storage is shared between nodes in the cluster.

Protects against failed storage because both the principal and mirror database servers write to local disks.

Storage types supported Shared storagedirect-attached storage (DAS) possible

Location requirementsMembers of the cluster must be on the same subnet.

Principal, mirror, and witness servers must be on the same LAN (up to 1 millisecond latency round trip).

Recovery model

SQL Server full recovery model recommended. You can use the SQL Server simple recovery model, but the only available recovery point if the cluster is lost will be the last full/diff backup.

Requires SQL Server full recovery model.

Performance overheadSome decrease in performance may occur while a failover is occurring.

High-availability mirroring introduces transactional latency because it is synchronous. It also requires additional memory and processor overhead.

Operational burdenSet up and maintained at the server level.

The operational burden is larger than clustering. Must be set up and maintained for all databases.

HA Configuration

SQL Server Log Shipping

Backup-Restore based technology that relies on transaction log files

Configurable frequency of shipping

No automatic failover

Allows you to replicate data to several instances of SQL

DR Configuration

Failover Clustering + Database Mirroring

DEMO

SharePoint 2010 – High AvailabilityConsiderations for SQL Server Backend

HA Configuration

Davos

Lenzerheide ISCHGL

Samnaun

Davos\Mirror

TDCore

Verbier

Sizing & Co.

Configuration Best Practices

Server Config

AntiVirus ConfigExclude SQL Server Data/Tlog/Backup Files

High Performance mode for database Server

Default Setting: «Balanced Mode»Recommendation: «High Performance»

no Energy Saving anymore

Storage

Recommended I/O Capacities

TypeRAID level IOPS SAN Optimization

tempdb RAID-10 2 IOPS/GB Write optimized

Transaction Logs RAID-10 2 IOPS/GB Write optimized

Search Database RAID-10  2 IOPS/GB

Read/Write optimized

Content Databases RAID-10*

0.75 IOPS/GB Read optimized

* Raid-5 can be used for static web content

Storage

Optimizing SQL Server I/O Subsystem

Ensure correct HBA driver and firmware versions

Use SQLIO.exe to measure I/O performance

Configure correct NTFS Allocation Unit Size64K best; default (4K) can result in a 30% perf hitTo view: chkdsk <drive_letter>To set: format E: /Q /FS:NTFS /A:64K /V:Data1 /Y

Ensure correct Windows “Sector Alignment”Incorrect setting can result in up to 50% perf hit64K most common. Windows 2008 aligns sectors by defaultWhitepaper SQL CAT – Disk alignment Best Practices

http://msdn.microsoft.com/en-us/library/dd758814.aspx

Prioritizing Database VolumesSeparate database volumes into unique logical

unit numbers (LUNs) consisting of unique physical disk spindlesPrioritize data among faster disks with ranking:

SQL TempDB data files and transaction log filesDatabase transaction log filesSearch databasesContent databases

In a heavily read-oriented portal site, prioritize data over logsSeparate out Search database transaction log from content database transaction logsPhysical Storage Recommendations:

http://technet.microsoft.com/en-us/library/cc298801.aspx

SQL Server SetupUse newest SQL Server version and Service PackUse the Sharepoint Collation Latin1_General_CI_AS_KS_WS

Setup SQL Server with ScriptsInstall only needed components and featuresUse SQL Aliases on WFE Servers to connect to SQL Server Instance for easier migrations in futureEnsure that SQL Server Service Account has following privileges

Lock Pages in MemoryPerform Volume Maintenance Tasks

SQL Server Configuration

Use Traceflag 1117 (when using autogrow and multiple datafiles)

Max Server Memory (leave at least 2-3GB to the OS)Set default index fill factor = 80%Enable Backup Compression defaultSet MAXDOP = 1

TempDB Configuration

Number of Data files = number of cores (min 4/max 8)Data file sizes consistent across all data filesPregrow data and tlog filesConfigure meaningful growth incrementsData files spread across unique LUNs

Separated from Content DB, Search DB, etc.

Content DB ConfigurationChoose the appropriate recovery model

Only use Full recovery model if you:Implement a backup strategy that includes regular (e.g. hourly) backups of the transaction logsUse a High Availability configuration, such as Log Shipping or Database MirroringThere is no point in using Bulk-Logged as SharePoint code does not contain any BULK INSERT or SELECT INTO statements

Otherwise use Simple to facilitate manageabilityConfigure the model database accordingly to avoid having to change the options of each new database after it was created

Do not change any Auto Setting!AUTO CREATE STATISTICS = FALSEAUTO UPDATE STATISTICS = FALSE

Content Databases - ContinuedPre-construct and pre-sizeDeploy using DBA-created databases

http://technet.microsoft.com/en-us/library/cc262869.aspx

“Autogrow” feature on for safetyUse RAID 5 or RAID 10 LUNs depending on your performance needsNumber of Data files = number of cores (in primary filegroup)

General SQL Server Best Practice would be to have only master data file (mdf) in primary filegroup and add additional files with a secondary filegroup

Tlog File = 1 (one is enough as it is sequentially written)

SQL Server ConfigurationDatabase Growth

DEMO

SharePoint 2010 – High AvailabilityConsiderations for SQL Server Backend

Optimizing Performance

Optimize your existing environments

Check at least for initial file sizes and growth incrementsCheck for large transactionlog filesUse DBCC Loginfo to get an idea on the internal fragmentation level of your transactionlog files

Lower fragmentation leads to more performacne, faster failover, faster restores

Maintenance in General

Physical Volume File Fragmentation:IS NOT NEEDED If you work with best practices like presizing and good growth increments

Absolutely recommended reading: Database Maintenance for Microsoft SharePoint 2010 Products

http://www.microsoft.com/downloads/details.aspx?FamilyID=246DBCA0-F03C-4DFF-A1B9-F510F7FC8A6A&amp;amp;displaylang=e

Databases MaintenanceDo’s

Have reliable backups for all databases before implementing maintenance operationsCheck for and repair consistency errors by using DBCC CHECKDBDefragment indexes by either reorganizing them or rebuilding them (Maintenance Plan or custom scripts), or use the dbo.proc_DefragmentIndices procedureUpdate statisticsIn a managed environment use standardized scripts for all databases and disable Database Maintenance Health Analyzer Rules

Databases Maintenance

Don'tsDrop and re-create indexesRebuild indexes or run consistency checks during business hoursSet fill factor for individual tables or indexesAuto-shrink databasesShrink databases manually unless you really need toDBCC Checkdb REPAIR_ALLOW_DATA_LOSS not supported (REPAIR_REBUILD supported, but not always possible)

How to check if everything is healthy and optimized?

DEMO

SharePoint 2010 – High AvailabilityConsiderations for SQL Server Backend

Use SQL Server Enterprise EditionSQL Server 2008 R2 and SharePoint 2010 Better together

WP: http://technet.microsoft.com/en-us/library/cc990273.aspx

Online Operations (Index Rebuilds, Page/File Restore)Faster Recovery/Failover (more redo threads, partial database availability)Asynchronous Database Mirroring for DRHot Add CPU/RAM (important for dynamic virtual environments)Unlimited Virtualization (with SA) and Application License MobilityCompression for Search DBTransparent Database EncryptionResource GovernorBusiness IntelligenceRemote Blob StorageMore than 2 Cluster Nodes

Q&A

Additional ResourcesHigh Availability and Disaster Recovery for SharePoint Server 2010: http://technet.microsoft.com/en-us/sharepoint/ff601831.aspx Boundaries and Limits Document: http://technet.microsoft.com/en-us/library/cc262787.aspx Performance and capacity management (SharePoint Server 2010):http://technet.microsoft.com/en-us/library/cc262971.aspxSQL Server and storage (SharePoint Server 2010): http://technet.microsoft.com/en-us/library/cc263420.aspxHP SharePoint Sizer: http://sizers.houston.hp.com/sb/installs/SharePoint2010Sizer.zip

© 2010 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.