Sp2010 high availlability_sql


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • The recommended number of databases used on a single mirroring session is no more than 10. Every database mirroring session creates at least two threads for each database. As more databases are added to the session, performance can get progressively worse until the system is unable to respond.
  • 10 second timeout, can be adjustedWhere to place witness?
  • SQL perspective for availability for SharePoint – 3 oob solutions – clustering, log shipping and db mirroringProven tehchnology used by many applicationsShared cluster name which consequently means no added configuration for sharepointSingle point of failure should the redundancy of the shared disk array fail.
  • SQL perspective for availability for SharePoint – 3 oob solutions – clustering, log shipping and db mirroringProven tehchnology used by many applicationsShared cluster name which consequently means no added configuration for sharepointSingle point of failure should the redundancy of the shared disk array fail.
  • CPU-Z
  • http://technet.microsoft.com/en-us/library/cc298801.aspx
  • http://technet.microsoft.com/en-us/library/cc298801.aspx
  • Sp2010 high availlability_sql

    1. 1. SharePoint 2010 – High AvailabilityConsiderations for SQL Server BackendRoger BreuTechnical Specialist Data Platformroger.breu@microsoft.com
    2. 2. Why Do You Need HA/DR?Availability during planned downtime Patching and service pack installations Hardware and software upgrades/migrations System reconfiguration Database maintenance Application upgradeProtection against unplanned downtime Human error is the number one cause of failure Site disasters Hardware malfunction Data corruption Software crash
    3. 3. Agenda Why care about SQL Server? SQL Server High Availability and Disaster Recovery Configuration Best Practices Optimizing Performance Q&A
    4. 4. Why care about SQL Server?
    5. 5. SharePoint and SQL Server SharePoint Admins and SQL DBA’s #! SharePoint heavily dependent upon SQL SQL DBA’s want control of DB’s DBA’s think SharePoint = DB sprawl SharePoint Admins want control of Farms Yet, storage architecture and SQL Server availability/scalability is critical to success
    6. 6. SharePoint and SQL Server You 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 DR DBA’s pre-construct and pre-size DB’s, monitor via SQL SharePoint Admin connects to DB’s, monitor via CA Coordinate backup and restore
    7. 7. SQL Server High Availability andDisaster Recovery
    8. 8. SQL Server 2008 R2 HA/DR technologiesFor SharePoint 2010 Database mirroring Failover clustering Transactional and peer-to-peer replication Log shipping Backup and restore
    9. 9. SQL Server Database Mirroring Implemented on a per-database level Transactions sent from Principal to Mirror Principal and Mirror must be separate SQL servers Optional “witness” server for automatic failover Provides a “warm” standby in case of failure
    10. 10. SQL Server Database Mirroring 3 Witness Server Principal Down! 2 4 I’m OK! 1 2 Encrypted Channel 5 5 Principal New Mirror Principal
    11. 11. SQL Server Database Mirroring Three operation modes: Operation Modes Transfer Mode Safety Level Failover Mechanism High Full (no witness) Synchronous Manual Safety/Protection Full (with Manual and High Availability Synchronous witness) AutomaticHigh Performance Off Asynchronous Forced
    12. 12. SQL Server Failover Clustering Implemented at the SQL Server Instance level Shared cluster name and automatic failover Disk subsystem is shared meaning single point of failure SharePoint Web Front Ends SQL Failover Server Cluster Heartbeat Node A Node B Shared Disk Array
    13. 13. SQL Server Failover Clustering /2 datacenters Disk subsystem can be replicated, no single point of failure Replication, especially synchronous will affect performance SharePoint Web Front Ends SQL Failover Server Cluster Heartbeat Node A Node B Shared Shared Disk Disk Array Array
    14. 14. SQL Server Failover SQL Server High- Clustering Availability Mirroring Mirror takes over immediately upon failure. Cluster member takes over immediatelyTime to failover (faster than failover clustering, no move of upon failure. disks) Failure is automatically detected by the Failure is automatically detected by database; SharePoint Server 2010 is aware database nodes; SharePoint Server 2010Steps required for failover? of the mirror location, if it has been references the cluster so that failover is configured correctly, so that failover is seamless and automatic. automatic. Does not protect against failed storage, Protects against failed storage becauseProtection against failed storage? because storage is shared between nodes both the principal and mirror database in the cluster. servers write to local disks.Storage types supported Shared storage direct-attached storage (DAS) possible Principal, mirror, and witness servers must Members of the cluster must be on theLocation requirements be on the same LAN (up to 1 millisecond same subnet. latency round trip). SQL Server full recovery model recommended. You can use the SQL ServerRecovery model simple recovery model, but the only Requires SQL Server full recovery model. available recovery point if the cluster is lost will be the last full/diff backup. High-availability mirroring introduces Some decrease in performance may occur transactional latency because it isPerformance overhead while a failover is occurring. synchronous. It also requires additional memory and processor overhead. The operational burden is larger thanOperational burden Set up and maintained at the server level. clustering. Must be set up and maintained for all databases.
    15. 15. HA Configuration
    16. 16. 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
    17. 17. DR Configuration
    18. 18. SharePoint 2010 – High AvailabilityConsiderations for SQL Server BackendDEMOFailover Clustering +Database Mirroring
    19. 19. HA Configuration Verbier Samnaun DavosMirror TDCoreDavos ISCHGLLenzerheide
    20. 20. Configuration Best PracticesSizing & Co.
    21. 21. Server Config AntiVirus Config Exclude SQL Server Data/Tlog/Backup Files High Performance mode for database Server Default Setting: «Balanced Mode» Recommendation: «High Performance» no Energy Saving anymore
    22. 22. Storage Recommended I/O Capacities Type RAID level IOPS SAN Optimizationtempdb RAID-10 2 IOPS/GB Write optimizedTransaction Logs RAID-10 2 IOPS/GB Write optimizedSearch Database RAID-10 2 IOPS/GB Read/Write optimizedContent RAID-10* 0.75 IOPS/GB Read optimizedDatabases * Raid-5 can be used for static web content
    23. 23. 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 Size 64K best; default (4K) can result in a 30% perf hit To 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 hit 64K most common. Windows 2008 aligns sectors by default Whitepaper SQL CAT – Disk alignment Best Practices http://msdn.microsoft.com/en-us/library/dd758814.aspx
    24. 24. Prioritizing Database Volumes Separate database volumes into unique logical unit numbers (LUNs) consisting of unique physical disk spindles Prioritize data among faster disks with ranking: SQL TempDB data files and transaction log files Database transaction log files Search databases Content databases In a heavily read-oriented portal site, prioritize data over logs Separate out Search database transaction log from content database transaction logs Physical Storage Recommendations: http://technet.microsoft.com/en-us/library/cc298801.aspx
    25. 25. SQL Server Setup Use newest SQL Server version and Service Pack Use the Sharepoint Collation Latin1_General_CI_AS_KS_WS Setup SQL Server with Scripts Install only needed components and features Use SQL Aliases on WFE Servers to connect to SQL Server Instance for easier migrations in future Ensure that SQL Server Service Account has following privileges Lock Pages in Memory Perform Volume Maintenance Tasks
    26. 26. 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 default Set MAXDOP = 1
    27. 27. TempDB Configuration Number of Data files = number of cores (min 4/max 8) Data file sizes consistent across all data files Pregrow data and tlog files Configure meaningful growth increments Data files spread across unique LUNs Separated from Content DB, Search DB, etc.
    28. 28. Content DB Configuration Choose 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 logs Use a High Availability configuration, such as Log Shipping or Database Mirroring There 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 manageability Configure 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 = FALSE AUTO UPDATE STATISTICS = FALSE
    29. 29. Content Databases - Continued Pre-construct and pre-size Deploy using DBA-created databases http://technet.microsoft.com/en- us/library/cc262869.aspx “Autogrow” feature on for safety Use RAID 5 or RAID 10 LUNs depending on your performance needs Number 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)
    30. 30. SharePoint 2010 – High AvailabilityConsiderations for SQL Server BackendDEMOSQL Server ConfigurationDatabase Growth
    31. 31. Optimizing Performance
    32. 32. Optimize your existingenvironments Check at least for initial file sizes and growth increments Check for large transactionlog files Use 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
    33. 33. 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=246DBCA 0-F03C-4DFF-A1B9-F510F7FC8A6A&amp;amp;displaylang=e
    34. 34. Databases Maintenance Do’s Have reliable backups for all databases before implementing maintenance operations Check for and repair consistency errors by using DBCC CHECKDB Defragment indexes by either reorganizing them or rebuilding them (Maintenance Plan or custom scripts), or use the dbo.proc_DefragmentIndices procedure Update statistics In a managed environment use standardized scripts for all databases and disable Database Maintenance Health Analyzer Rules
    35. 35. Databases Maintenance Donts Drop and re-create indexes Rebuild indexes or run consistency checks during business hours Set fill factor for individual tables or indexes Auto-shrink databases Shrink databases manually unless you really need to DBCC Checkdb REPAIR_ALLOW_DATA_LOSS not supported (REPAIR_REBUILD supported, but not always possible)
    36. 36. SharePoint 2010 – High AvailabilityConsiderations for SQL Server BackendDEMOHow to check ifeverything is healthy andoptimized?
    37. 37. Use SQL Server Enterprise Edition SQL 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 DR Hot Add CPU/RAM (important for dynamic virtual environments) Unlimited Virtualization (with SA) and Application License Mobility Compression for Search DB Transparent Database Encryption Resource Governor Business Intelligence Remote Blob Storage More than 2 Cluster Nodes
    38. 38. Q&A
    39. 39. Additional Resources High 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.aspx SQL Server and storage (SharePoint Server 2010): http://technet.microsoft.com/en-us/library/cc263420.aspx HP SharePoint Sizer: http://sizers.houston.hp.com/sb/installs/SharePoint2010Size r.zip
    40. 40. © 2010 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.