SharePoint Disaster Recovery with SQL AlwaysOn
0 likes1,425 views
The document outlines disaster recovery strategies for SharePoint using SQL Server AlwaysOn, including configurations for multi-subnet server clusters across datacenters. It details various DR methods such as log shipping, database mirroring, and the benefits of using AlwaysOn for real-time replication. A step-by-step guide for configuration, simulation of failover, and best practices for transfer data settings is also provided.
SharePoint Disaster Recovery with SQL AlwaysOn
- 1. SharePoint Disaster Recovery w/ AlwaysOn ZEDDY ISKANDAR http://zeddylabs.com @zeddyiskandar
- 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
- 3. Scripts to create VMs HTTP://ZEDDYLABS.COM/2015/03/BUILDING-ENTERPRISE-ENVIRONMENT- LAB-FOR-DEVELOPMENT-WITH-WINDOWS-8-HYPER-V/
- 5. Azure Cold and Warm DR https://technet.microsoft.com/en-us/library/cc263199.aspx
- 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. SQL Server AlwaysOn 2012, 2014, …
- 9. Create Multi-Subnet Windows Server FailOver Cluster (WSFC) SQL1 : 172.16.1.10 in Datacenter1 (Abu Dhabi) SQL2 : 192.168.1.10 in Datacenter2 (Singapore)
- 10. Create Multi-Subnet Windows Server FailOver Cluster (WSFC) Multi-Subnet Cluster
- 11. Separate StandAlone SQL Servers on each Datacenter Don’t select SQL Cluster Installation
- 12. Database Engine Feature is enough No need SQL Server Replication etc.
- 13. Enable ALWAYS ON from SQL Server Properties Do for both SQL1 and SQL2
- 14. High Availability vs Disaster Recovery http://technet.microsoft.com/en-us/library/jj841106.aspx 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. Warm-Standby Disaster Recovery 2 separate SharePoint Farms: SP1 uses SQL1 in Datacenter1 network (172.16.x.x) SP1 has a site-collection http://intranet.zed.com SP2 uses SQL2 in Datacenter2 network (192.168.x.x) SP2 has a site-collection http://intranet-DR.zed.com 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. Configure AlwaysOn from SQL1
- 17. Full Backup is required before replicating After Full Backup is performed…
- 18. Add Replica SQL2 from Datacenter2 Click Add Replica and connect to SQL2
- 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. 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. 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. Successful Confirmation of AlwaysOn Config
- 23. Behind-the-scene why WSFC was needed… AlwaysOn configured as Clustering Role AlwaysOn configured all Replica Nodes under WSFC Nodes
- 24. Making use of Readable Secondary
- 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. 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
- 28. One final AAM magic touch… This will allow us to browse the DR Farm as http://intranet.zed.com after DNS is redirected to DR Farm.
- 29. Disaster Recovery Simulation w/ Hyper-V across Datacenters
- 30. Demo… We will disconnect SP1 and SQL1 and failover database + SharePoint to DR Farm SQL2 + SP2
- 31. IP Table… VM Virtual Switch IP Gateway DNS DC1 Datacenter1 172.16.1.2 172.16.1.1 127.0.0.1 ROUTER1 Datacenter1 Datacenter2 GuestToLoopback 172.16.1.1 192.168.1.1 192.168.2.1 172.16.1.2 172.16.1.2 172.16.1.2 SQL1 Datacenter1 172.16.1.10 172.16.1.1 172.16.1.2 SQL2 Datacenter2 192.168.1.10 192.168.1.1 172.16.1.2 SP1 Datacenter1 172.16.1.20 172.16.1.1 172.16.1.2 SP2 Datacenter2 192.168.1.20 192.168.1.1 172.16.1.2
- 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. 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. 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. Confirm FailOver works… 3. Check WSFC again and make sure SPIntranetAG is now running on SQL2.
- 36. Change the DNS and browse from Host
- 37. Change the DNS and browse from Host
- 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. Thank you!