Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

SharePoint Disaster Recovery with SQL AlwaysOn

A talk I gave for SharePoint Saturday about doing warm disaster recovery using SQL AlwaysOn and how to use the secondary replica as read-only browse-able SharePoint site.

  • Login to see the comments

  • Be the first to like this

SharePoint Disaster Recovery with SQL AlwaysOn

  1. 1. SharePoint Disaster Recovery w/ AlwaysOn ZEDDY ISKANDAR @zeddyiskandar
  2. 2. Agenda  DR Strategies:  Azure Cold and Warm.  Log shipping.  Database Mirroring.  AlwaysOn:  Visual Overview.  Step-by-step Config.  DR Simulation w/ Hyper-V across Datacenters
  4. 4. DR Strategies…
  5. 5. Azure Cold and Warm DR
  6. 6. Database Mirroring
  7. 7. Log Shipping, Database Mirroring, SQL AlwaysOn (new)  Log-shipping:  requires good understanding of LSN (Log Sequence Number).  if logs are shipped hourly, there is a window of 1-hour data loss if primary server fails.  Database-mirroring:  1 DB can only be mirrored to 1 mirror server.  mirrored DB is not readable.  SQL AlwaysOn:  simply right-click Failover, no need to debug LSN why Restore failed.  real-time delta replication to replicas.  max 4 replicas.  secondary DB is readable.
  8. 8. SQL Server AlwaysOn 2012, 2014, …
  9. 9. Create Multi-Subnet Windows Server FailOver Cluster (WSFC) SQL1 : in Datacenter1 (Abu Dhabi) SQL2 : in Datacenter2 (Singapore)
  10. 10. Create Multi-Subnet Windows Server FailOver Cluster (WSFC) Multi-Subnet Cluster
  11. 11. Separate StandAlone SQL Servers on each Datacenter Don’t select SQL Cluster Installation
  12. 12. Database Engine Feature is enough No need SQL Server Replication etc.
  13. 13. Enable ALWAYS ON from SQL Server Properties Do for both SQL1 and SQL2
  14. 14. High Availability vs Disaster Recovery   When you transfer data over WAN:  Choose Asynchronous-Commit in AlwaysOn Config.  Only Content Database, Secure Store, UserProfile, Managed Metadata and other non-farm-specific databases can be replicated.  When you transfer data locally with less than 10ms latency:  Choose Synchronous-Commit in AlwaysOn Config.  All SharePoint databases (including Config_DB) can be replicated.
  15. 15. Warm-Standby Disaster Recovery  2 separate SharePoint Farms:  SP1 uses SQL1 in Datacenter1 network (172.16.x.x)  SP1 has a site-collection  SP2 uses SQL2 in Datacenter2 network (192.168.x.x)  SP2 has a site-collection  Content Database of SP1 http://intranet will be replicated to SQL2 via Asynchronous AlwaysOn.  SQL2 will have this as read-only replica.  This will be mounted to http://intranet-DR2 and browse-able as read-only data (to verify replication + maintain warmness).
  16. 16. Configure AlwaysOn from SQL1
  17. 17. Full Backup is required before replicating After Full Backup is performed…
  18. 18. Add Replica SQL2 from Datacenter2 Click Add Replica and connect to SQL2
  19. 19. Make Replica #2 Readable This allows us to mount replicated database to Portal http://intranet-DR in Datacenter2 as read-only site-collection for DR verification.
  20. 20. Make Replica #2 Readable This allows us to mount replicated database to Portal http://intranet-DR in Datacenter2 as read-only site-collection for DR verification.
  21. 21. Data Initialization: pull via FileShare For real-world usage, we may copy backups to portable drive, ship it, and re-mount it. Apply daily incremental until SQL1 and SQL2 are in the same state. Then choose Join-only.
  22. 22. Successful Confirmation of AlwaysOn Config
  23. 23. Behind-the-scene why WSFC was needed… AlwaysOn configured as Clustering Role AlwaysOn configured all Replica Nodes under WSFC Nodes
  24. 24. Making use of Readable Secondary
  25. 25. Create new Web Application in DR Farm 1. Create new WebApp, giving a temporary database name 2. After site-collection is created, go to “Manage Content Databases” and remove the “_Init” DB from Content Database
  26. 26. Mounting Read-Only Content_Intranet to DR Farm 3. Click Add content database and type the name of the replicated database in AlwaysOn Availability Group 4. Content_Intranet is now the only Content DB for http://intranet-DR
  27. 27. http://intranet-DR now browse-able
  28. 28. One final AAM magic touch… This will allow us to browse the DR Farm as after DNS is redirected to DR Farm.
  29. 29. Disaster Recovery Simulation w/ Hyper-V across Datacenters
  30. 30. Demo… We will disconnect SP1 and SQL1 and failover database + SharePoint to DR Farm SQL2 + SP2
  31. 31. IP Table… VM Virtual Switch IP Gateway DNS DC1 Datacenter1 ROUTER1 Datacenter1 Datacenter2 GuestToLoopback SQL1 Datacenter1 SQL2 Datacenter2 SP1 Datacenter1 SP2 Datacenter2
  32. 32. ROUTER1 running Routing & Remote Access Role This allows the VMs to get Internet via the Host Internet, the Host browser to access SharePoint inside VM, and communication between Datacenter1 and Datacenter2.
  33. 33. Check WSFC before Failing Over Database Make sure Windows Server FailOver Cluster is running on DR Farm with IP 192.168.x.x , otherwise run Move-ClusterGroup “Cluster Group”
  34. 34. Failover AlwaysOn Availability Group 1. On SQL2, we right- click the SPIntranetAG and Failover… 2. Confirm because of asynchronous-commit, data loss needs to be acknowledged…
  35. 35. Confirm FailOver works… 3. Check WSFC again and make sure SPIntranetAG is now running on SQL2.
  36. 36. Change the DNS and browse from Host
  37. 37. Change the DNS and browse from Host
  38. 38. Failback Strategy (back to SQL1 + SP1)  Upload something on current http://intranet (SP2).  Check if the file appears on current http://intranet-DR (SP1).  Once confirmed, do a SQL Failover from SQL2 back to SQL1.  Verify in WSFC that SQL1 is now the owner of SPIntranetAG Availability Group.  Finally switch DNS back for intranet (to SP1) and intranet-DR (to SP2).
  39. 39. Thank you!