1. ...your options for ‘High Availability’ with SQL

2. About JT..  I’m a SharePoint Admin. Working a contract with FaHCSIA  I am a SharePoint Technical engineer with Extelligent Design  With SharePoint since 2006.  10+ years in Infrastructure, DR, Networking  I blog about SharePoint (IT Pro stuff). www.jeremytaylor.net

3. Take-away for today..  Learn some DR concepts  Learn to set up SQL database mirroring  Know more about Log Shipping and SQL Clustering  Have something to take back to your manager / team leader

4. What is HA?  A redundant system that provides a service when the primary system fails.  When this happens automatically, its called Failover What is DR?  Disaster Recovery – process, policies and procedures related to preparing and undergoing a recovery from a disaster

5. Some DR concepts  RTO – Recovery time objective. The time you have to get the system up and running after a disaster.  RPO – Recovery point objective. The maximum amount of data loss that’s deemed acceptable in a disaster.

6. Data Centres DR solutions…  Hot standby - A second data center that can provide availability within seconds or minutes.  Warm standby - A second data center that can provide availability within minutes or hours.  Cold standby - A second data center that can provide availability within hours or days.

7. SharePoint DR ‘Pointers’  Know your environment  Selecting the right tools for your environment  Know what to backup in SharePoint/SQL  Communicate with Management  Highlight the risks  Budget for your DR

8. SharePoint DR -Key areas for Disaster Recovery  Physical architecture  Logical architecture  Configuration data  Business data

9. Physical architecture  Storage: SAN, NAS  Networking and Comms equipment  Load balancers / Reverse Proxies  Physical servers – SharePoint & SQL  Essential AD and DNS services

10. Logical Architecture  IIS Application pools  Web Applications  Zones and AAMs  Web application policies  Site Collections & security  Mysites  Third party tools

11. Configuration Data  Service Application databases  Web.config files for SharePoint Web Applications  IIS configuration files (IIS metabase)

12. Business Data  Content in SQL databases  BLOB storage  RBS provider

13. But what about HA?  Multiple data centres..  Load balancing..  SAN replication..  Virtual Storage..  Stretched farm..  Separate Standby farm..  Mirroring..  Log shipping..  Clustering..  All of the above?  It depends on your environment, budget, policies  There is no ‘One size fits all’ solution to this.. Recommended: http://technet.microsoft.com/en-us/library/ff628971.aspx

14. Lets explore some more.. Stretched Farm Link between Data centres! Database ‘layer’ could be: Mirrored Clustered Source: http://technet.microsoft.com/en-us/library/cc748824.aspx

15. Separate Standby Farm Link between Data centres! Database ‘layer’ could be: Async Mirrored Log Shipped

16. HA Options with SQL  Database Mirroring  Log Shipping  SQL clustering

17. SQL Mirroring  SQL ‘pushing’ instantaneous updates to its mirrored server.  Databases are duplicated and can be automatically failed over to the mirror.  Unlike MOSS 2007, SharePoint 2010 is ‘mirroring-aware’

18. How to set up mirroring?  2 servers Principal Mirror  1 server for witness (optional)  Backup and restore in Full mode to mirror server with NO RECOVERY option.  Backup and restore Transaction logs to mirror server.  Go to the ‘Configure Database Mirroring Security’ wizard to create endpoints.  Choose your options  Start mirroring  Enable SharePoint databases to be ‘mirroring-aware’. PowerShell for Service applications and Content databases. Central Admin for Content databases.

19. Some considerations  Latency less than 1 millisecond  Database recovery model: Full  Database permissions: same rights  Network bandwidth  More mirrored databases consume more threads = more logical processors

20. What SharePoint Databases can be mirrored?  Config Db – Yes  Admin Db – Yes.  Usage Db – not recommended. Can be recreated.  Business Connectivity Service (BCS) – yes  Subscriptions setting db – yes  Search Admin – yes  Search Crawl – yes  Search Property – yes  User Profile Application (UPA) Profile – no, not supported  User Profile Application (UPA) Sync – no, not supported  User Profile Application (UPA) Social – no, not supported  Web Analytics (WAN ) Staging – not supported  Web Analytics (WAN ) Reporting – yes  Word Automation Service (WAS) – yes  State – no  Managed Metadata Services (MMS) – yes  Secure Store Service (SSS) – yes  PerformancePoint Service (PPS) – yes  Application Registry Service – not recommended

21. What’s on Technet… The supported topologies include:  All content databases  Configuration database  Central Administration content database  Service application databases  Except for the Web Analytics Staging database and the User Profile Synchronization database.  Source: http://technet.microsoft.com/en-us/library/dd207314.aspxhttp://technet.microsoft.com/en-us/library/dd207314.aspx

22. Configuring Failover.. New Web Applications.. Existing Content databases..

23. Configuring Failover with PowerShell.. $db = get-spdatabase | where {$_.Name -eq "DEMOSP2010_Config"} $db.AddFailoverServiceInstance("MIRROR") $db.Update() Get-Help New-SP……ServiceApplication -full

24. Demo: How to configure mirroring

25. SQL Mirroring Pros  Automatic failover option  Independent  Highly configurable  Immediate replication  Responsive  Redundancy

26. SQL Mirroring Cons  One mirror per database  No easy read-only option  Performance impact (push)  Dependence on latency  Geographical limitation  Inability to configure failover criteria

27. Log Shipping  Utilises backup and restore jobs of SQL  It’s a ‘Pull’ approach.  Transaction logs are replicated as per your desired schedule  Primary, Secondary & Monitor (optional)  4 SQL server agent jobs – Backup on primary server Copy on secondary server Restore on secondary server Alert on secondary/monitor server

28. How to configure SQL Log Shipping  2+1 Servers  File Share  Recovery Model – FULL or Bulk Logged  SQL Server Agent – must be started!

29. How to configure Log Shipping:

30. Log Shipping - Job scheduling

31. Log Shipping - Monitor settings

32. Log Shipping – Secondary server

33. Secondary Db settings

35. Set up monitor and grab your script..

36. What SharePoint Databases can be logged shipped?  Config db – no  Search – no  Service Applications – yes, except some  Content databases - yes Read more: http://technet.microsoft.com/en-us/library/ff628971.aspx

37. Log Shipping Pros  Uses a pull strategy – little impact to performance  Independent jobs – not tied to SharePoint.  Cost effective HA solution when compared to using clustering in HA.  Read-only availability – no load on primary farm  Multiple destinations (pull approach)  Geographic redundancy – not like database mirroring or failover clustering  FILESTREAM compatibility – to a standby db

38. Log Shipping Cons  No automatic failover  Latency  Monitoring – may need to use SCOM  Not a complete solution  Errors and data loss – are replicated.

39. SQL Failover Clustering  Works on Windows Server 2008 clustering capabilities (Enterprise & Datacenter editions).  Minimum two servers for failover  Intended to be used as a HA solution but not completely fault tolerant.  Run the Cluster Validation Tool (CVT).

40. SQL Clustering Pros  True automatic failover  No interruption for maintenance  Rapid failover  Scalable – up to 16 server nodes  Log shipping friendly

41. SQL Clustering Cons  Network requirements  Storage requirements  High Costs  No Fault tolerance with shared storage

42. Management needs to know…  SharePoint DR is an extensive topic!  HA requires planning and expertise  Capacity Planning must be done from project start and factor in HA options  Schedule (& budget) DR and HA tests every 6- 12 months  Document and communicate the limitations of your DR Procedures  Consult Microsoft for licensing  Remind the Managemrnt of Murphy’s law.. Anything that can go wrong, will go wrong!  Some JT advice: Be paranoid! Be prepared!

43. Thank you! Questions? Happy to chat with you individually after the session…  Email: jeremy@jeremytaylor.net  Twitter.com/jeremytaylor