* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Title
Entity–attribute–value model wikipedia , lookup
Oracle Database wikipedia , lookup
Team Foundation Server wikipedia , lookup
Tandem Computers wikipedia , lookup
Microsoft Access wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Ingres (database) wikipedia , lookup
Concurrency control wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Database model wikipedia , lookup
Clusterpoint wikipedia , lookup
Relational model wikipedia , lookup
Open Database Connectivity wikipedia , lookup
SQL Server AlwaysOn – SharePoint 2013 High Availability and Disaster Recovery Sal Bawany, Solutions Architect www.bawanyconsulting.com 0 Introduction Sal Bawany, Solutions Architect Specialties: SharePoint, Office 365, Cloud Computing • Independent Consultant • Previously Senior Consultant at Microsoft Contact: • [email protected] • LinkedIn: Sal Bawany • Twitter: @fbawany • Blog: blogs.technet.com/b/salbawany (moving to salbawany.wordpress.com) 1 Welcome to SharePoint Saturday Houston Thank you for being a part of the 5th Annual SharePoint Saturday for the greater Houston area! • Please turn off all electronic devices or set them to vibrate • If you must take a phone call, please do so in the hall so as not to disturb others • Special thanks to our Title Sponsor, ProSymmetry 2 Thanks to all our Sponsors! 3 Information • Speaker presentation slides should be available from the SPSHOU website within a week or so • The Houston SharePoint User Group will be having it’s next meeting Wednesday April 15th. Please join us at www.h-spug.org 4 Agenda • • • • • • Concepts Overview Benefits Requirements Setup and Configuration Failover and Failback Scenarios 5 Concepts High Availability and Disaster Recovery 6 System Outages: Planned vs. Unplanned Planned outage • Used for maintenance • A time window is pre-announced and coordinated for these activities Unplanned outage • The result of system-level, infrastructure, or process failures • Can be unplanned and uncontrollable 7 Disaster Recovery and High Availability High Availability The ability to continue operations when a component fails in primary data centre Disaster Recovery The process to restore operations after primary data centre becomes unavailable 8 Service Level Agreement (SLA) Recovery Point Objective (RPO) • The maximum period in which data might be tolerably lost due to some major incident Recovery Time Objective (RTO) • The time within which the business service must be restored after a disruption Example: • RPO of 1 hour • RTO of 6 hours 9 High Availability concepts • Redundancy across switches, routers, load balancer, AD/DNS, SMTP, power, cooling • Redundant web, application, and DB servers • Redundant VM hosts • Backup and Restore 10 Disaster Recovery Concepts Hot standby • A second data centre that can provide availability within seconds or minutes • Highly dependent on network bandwidth and latency Warm standby • A second data centre that can provide availability within minutes or hours • Duplicated VMs, refreshed frequently Cold standby • A second data centre that can provide availability within hours or days 11 Disaster Recovery dependencies Remote site with reliable WAN connection Failover farm should match production farm: • • • • • • • • VM hosts and their clusters Number of servers Operating system, Patch/updates SQL server version and updates SharePoint version and updates Configuration, and Central admin content database Web applications and service applications and their databases Any customizations deployed in the production farm Infrastructure: HA/DR for switches, routers, load balancer, Active Directory domains DNS, Exchange Server, SQL Servers, and power and cooling. 12 SQL Server AlwaysOn Availability Groups 13 SQL Server HA Solutions • • • • AlwaysOn Failover Cluster Instances AlwaysOn Availability Groups Database mirroring Log shipping 14 What is AlwaysOn Availability Group? • Enterprise-level high-availability and disaster recovery solution introduced in SQL Server 2012 – – – – – – Listener, DNS name Databases Replicas Replica roles Replica Availability Mode Replica Failover Mode Sync AG1 AG1 AG1 Async AG2 SQL Node1 Primary Replica Automatic failover AG2 SQL Node2 Secondary Replica Automatic failover WAN AG2 SQL Node3 Secondary Replica Manual failover Listner Windows Cluster SharePoint Farm Backup 15 High level Planning AlwaysOn Availability Groups Availability Group Listeners Availability Databases Availability Replicas Replica Role Replica Availability Mode Replica Failover Mode Readable Secondary AG for Content Databases SP-AG1 Content Databases PROD SQL 1 Primary Sync commit Automatic No PROD SQL 2 Secondary Sync commit Automatic No DR SQL 1 Secondary Async commit Manual No PROD SQL 1 Primary Sync commit Automatic No PROD SQL 2 Secondary Sync commit Automatic No AG for Service Application Databases SP-AG2 Service Apps Databases 16 Benefits • • • • • • No need to setup SQL Instance Cluster No need for SAN storage Failover multiple databases in seconds Up to eight secondary replicas Compression and Encryption Automatic and Manual Failover • Easy setup using the configuration wizard • AlwaysOn health dashboard 17 SharePoint Databases not supported in Async • Configuration database (Farm specific) • Central Administration content database (Farm specific) • Search Administration database (copy and re-create) • Analytics Reporting database • Crawl database • Link database • Usage and Health Data Collection database (Farm specific) • User Profile Synchronization database • State Service database 18 Requirements • SQL Server 2012 Enterprise Edition • Windows Server Failover Cluster (WSFC) – Failover processing and management – Heartbeat detection – Keeps track of changes in the replica roles • At least three nodes – two at the local site to provide high availability – third node at the remote site to provide disaster recovery • Replica Availability Mode – Sync = local high availability – Async = remote, disaster recovery 19 Additional considerations • All cluster members must belong to the same domain or trusted domain • Cluster Quorum – For odd number of votes, use “Node Majority” – For even number of votes, use either “Node Majority” or add file share and use “Node and File Majority” • Follow the best practices for setting up the Clustering Service • New databases need to be added manually to the Availability Group • Do not use the Failover Cluster Manager to manipulate Availability Group 20 Setup 21 Steps 1. 2. 3. 4. 5. 6. 7. 8. Setup Windows Failover Clustering and make each SQL instance from local and remote disaster recovery site member of that cluster Enable AlwaysOn on each node Create the Availability Group(s) Add Replicas to each Availability Group Verify Endpoints, open inbound port 5022 (default) on each SQL node Verify backup preferences Create DNS A record for the “Listener” Create Availability Group Listener, provide port 1433(default), and an IP address from each of the local and remote DR subnets. These IPs should map to an A record for the Listener. Note: Make sure that the same farm service accounts to each of the Prod and DR SQL Instances login and server roles have been added, otherwise the AlwaysOn synchronization process will Fail. 22 Steps (Cont.) 9. Create a shared folder for data synchronization for the Availability Group 10. Install SharePoint 11. After SharePoint has been installed and configured, change Recovery Model for each of its databases to Full. This is a requirement before a database can be added to the Availability Group 12. Backup all of the databases. This is a requirement before a database can be added to the Availability Group 13. Add databases to their Availability Group(s) 14. Test failover and failback on each Availability Group 23 Failover and Failback Scenarios 24 High Availability Scenarios • Manual Failover and Failback from primary to secondary replica and vice versa • Automatic Failover due to primary replica outage and manual Failback from the secondary replica Sync AG1 PRIMARY AG2 AG1 Async Secondary AG2 SQL Node1 Primary Replica Automatic failover SQL Node2 Secondary Replica Automatic failover Listner Windows Cluster 25 AG1 WAN Secondary AG2 SQL Node3 Secondary Replica Manual failover Disaster Recovery Scenarios • Manual Failover and Failback from primary to DR replica and vice versa • Forcing Quorum and Force Failover due to primary datacenter outage and manual Failback from the secondary replica. Data loss possible. Be aware of the Spilt Brain quorum. Sync AG1 PRIMARY AG1 Async Secondary AG2 AG2 SQL Node1 Primary Replica Automatic failover SQL Node2 Secondary Replica Automatic failover AG1 WAN Secondary AG2 SQL Node3 Secondary Replica Manual failover Listner Windows Cluster DR SP Farm 26 Demos 27 Demos • • • • • Availability Group walkthrough Creating Availability Group Dashboard Adding Database to the Availability Group Failover and Failback process 28 Summary • Maintain a Service Level Agreement (SLA) that meets your business goal • Time is Money! • Maintain redundancy at all levels, software and hardware • AlwaysOn Availability Group is easy to setup and maintain • Run scheduled dry runs to make sure Disaster Recovery is working • Happy Servers, Happy Admins 29 Q&A 30 Please Leave Feedback During Q&A Please fill out the session survey with your feedback. You can scan the QR Code to launch the survey or use the following link: www.WhatsYourAnswer.com?S20154715202 31