SharePoint High Availability & Disaster Recovery

high availability & disaster recovery for sharepointplanning & technology thomas vochten

13.03.2012

about me

Thomas Vochten

@thomasvochtenthomasvochten.comlinkedin.com/in/thomasvochten

consultantplatform architectlousy developeraccidental dba

SharePoint

SQL Server

#sphelp to the rescuehttps://twitter.com/search/%23sphelp

setting the sceneha & dr overview

high availability & disaster recoverycritical factor in any SharePoint deployment

however…

false expectations

fuzzy requirements

technicalmisconceptions

project failure

high availabilityprotecting against component failures

• server hardware• operating system• service applications• application pools• custom development• …

number of nines

3 days, 15 hours

• often an important part of a service level agreement (SLA)• usually only unplanned downtime

8 hours, 45 mins

52 mins, 34 secs5 mins, 15 secs

99%

99,9%

99,99%

99,999%

downtime per year

disaster recoveryprotecting against catastrophes

• network outages• storage problems• power problems• loss of datacenters• …

protect yourself

systems

components

dataoperations & procedures

build redundancy into the architecture

infrastructure

the bigger pictureplanning for ha & dr

it’s all about the business• involve all stakeholders when planning• don’t neglect the business impact• analyze data & systems• consider non-technical elements

business continuity planning

key concepts of bcp• Risk assessment• Business Impact Analysis• Business Continuity Plan• Disaster Recovery Plan

requirementsarchitecting a solution

key parametersRecovery Time Objective (RTO)When will my system be available again?

Recovery Point Objective (RPO)How much data can I afford to lose?

Recovery Level Objective (RLO)To what level am I able to restore?

time

RPO RTO

last backup at 20:00 full recovery at 12:00outage at 08:00

12h 4h

reality check• What are acceptable RTO & RPO times?

• Is RTO and RPO 0 possible at all?• What about the costs?

time

RPO RTO

last backup at 07:55 full recovery at 08:15

outage at 08:00

5m 15m

context is kingpitfalls when designing a SharePoint HA/DR solution

• enterprise infrastructure• technical skills• operational readiness• backup/restore• documentation• dependencies on other systems• 3d party tools• …

additional considerationsestablish recovery targets

• What should be restored and what not?• What can be restored and what not?• Is some data more important than other?• How must the restored system behave?• Balance costs & risks when designing a solution

the most crucial step• Test, test, test!

technical solutionsSharePoint & SQL Server

SharePoint optionshow can you make SharePoint highly available?

• adding servers for redundancy• splitting services across servers• using load balancing techniques• highly available SQL Server

load balancing SharePoint

APP2service instance

APP1service instance

WEB2IIS

WEB1IIS

Web Requests

Service Apps

WEBnIIS

APPnservice instance

service applicationshow to distribute service applications throughout your farm?

SharePoint takes care of the load balancing for you

important considerations• user profile synchronization service only on 1 server• search service application can be made fully

redundant now

what about disaster recovery?

SharePoint disaster protectionwhat are your options?

rebuild

cold standby

warm standby

hot standby

stretched farm

rebuild farm

RTO

RPO

documentscript

• never simply dismiss this option• serious drawbacks however• backup/restore data• documentation is essential• script your install

?

standby farms

cold standby

hotstandby

warmstandby

RTOhrs/days

RTOhrs/mins

RTOmins/secs RPO config!?

warm / hot standby farms• completely separate farm• near identical configuration• same customizations• separate datastores• involves some kind of data

replication• replicating service app data has

its limits• manual failover & client

redirection

service applicationsthese don’t support copying to another farm

configcentral admin bcs

search admin

search crawl

search property

user profile

stretched farma special case…a lot of dependencies…some complexity involved…

major design constraints• network throughput• network latency• redundant access infrastructure• data replication

SQL Server

clusteringtwo flavors

• high availability• same datacenter• 2 or more nodes• shared storage• automatic failover• SharePoint is unaware

classic cluster

• high availability or disaster recovery• multiple datacenters• 2 or more nodes• no shared storage• automatic failover• SharePoint is unaware• data replication needed

geo cluster

clustering summary

RPOdepends

RTO secs/mins

RLOfarm

how does it satisfy requirements?

failoverauto

mirroring

essentials• high availability scenarios• no shared storage• SharePoint is aware !

nice to know• full recovery model• configured per database• only one secondary possible• secondary cannot be accessed• automatic failover possible• network constraints• sync or async

native mirroring support

PowerShell

$db = Get-SPDatabase [UglyGuidGoesHere]

$db.AddFailoverServiceInstance(“servername”)

$db.Update()

User Interface

mirroring summarysynchronous mirroring

asynchronous mirroring

RPO0

RTOsecs

RLOdepends

RPOseconds

RTOmins

RLOdepends

failoverauto

failovermanual

log shipping

essentials• disaster recovery scenarios• no shared storage• backup/restore based

nice to know• full recovery model• configured per database• multiple secondary's possible• secondary can be read from• no automatic failover possible• rpo will generally not be 0

log shipping summaryhow does it satisfy requirements?

RPOmins

RTOmins/hrs

RLOdepends

failovermanual

SQL 2012 Availability Group

essentials• clustering & mirroring evolved• at the instance level• no shared storage• for ha & dr• simple configuration

nice to know• automatic failover across single or multiple datacenters• multiple databases fail over together• no need for aliases or AddFailoverServiceInstance in SharePoint• multiple (readable) secondaries possible• full recovery model• RBS support

the newest kid on the block

SQL 2012 Availability Group

SQL 2012 Availability Group summaryhow does it satisfy requirements?

RPO0

RTOsecs

RLOfarm

failoverauto HA & DR

Putting it all together

single farm / one datacenter• multiple web servers with load balancing• multiple application servers• clustering or mirroring for ha or dr• consider SQL 2012 availability groups!

single farm / two datacenters• fully redundant network infrastructure• <1ms latency between datacenters• load balancing across datacenters• multiple web servers• multiple application servers• mirroring or geo cluster with data replication for ha &

dr• consider SQL 2012 availability groups!

two farms / two datacenters• fully redundant network infrastructure• log shipping between data centers for dr• manual failover• manual client redirect (network routing, dns)• sometimes DR farm is read-only• warm / hot standby• consider SQL 2012 availability groups!

questionsthank you for your attendance

@thomasvochten