sp2010 high availlability_sql
DESCRIPTION
TRANSCRIPT
SharePoint 2010 – High AvailabilityConsiderations for SQL Server
Backend
Roger BreuTechnical Specialist Data [email protected]
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;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.