SSRS Disaster Recovery

PASS DW|BI Webinar

Ayad Shammout (@aashammout) and Denny Lee (@dennylee)Hosted by Julie Koesmarno (@mssqlgirl)

Agenda

• Review of Scale Out Architectures• It’s all about the Catalog• SSRS Disaster Recovery Infrastructure• Optimizing the Catalog with SQL Server 2012 Always On

RSDB

Clients

Flat Files,OLE DB,ODBC

SQL, AS,DB2, Oracle,

Teradata, etc.

RS Server

NLB

Clients

Clients

Reporting Services ArchitectureTypical One-Box Deployment

Report Server

Report C

ata

log

Data

Source

s (to re

port a

gain

st)

RSDB

Clients

Flat Files,OLE DB,ODBC

SQL, AS,DB2, Oracle,

Teradata, etc.

RS Server

NLB

Clients

Clients

Reporting Services ArchitectureRemote Report Catalog = Higher Availability

Report Server

Report C

ata

log

Data

Source

s (to re

port a

gain

st)

RSDB

Clients

Flat Files,OLE DB,ODBC

SQL, AS,DB2, Oracle,

Teradata, etc.

RS Server

RS Server

RS Server

NLB

Clients

Clients

Reporting Services ArchitectureScale Out and High Availability Infrastructure

Report

ing S

cale

Out

Deplo

ym

en

t

Report Server Cluster

Report C

ata

log

Data

Source

s (to re

port a

gain

st)

Report CatalogArchitecture

Report Server Catalog (RSDB)Stores all report metadata including report definitions, report / history snapshots, scheduling, etc.

Report Server TempDBStores temporary snapshots while running reports

These databases can be a bottleneck Optimize by applying standard SQL DB techniques Catalog has a lot of I/O and transactions

–RS2005: Many inserts to ChunkData, SnapshotData, and SessionData tables–RS2008: Many inserts Segment; takes majority of transactions of RSTempDB

RSDB

Report C

ata

log

Report CatalogBest Practices > Use a dedicated server

• Same server as SSRS Server• Great for small environments• In enterprise environments, too much resource contention

• Same server as data source database• SQL resource contention (TempDB, plan cache, memory buffer

pool) between data source and RS catalogs• As load increases need to monitor CPU, I/O, network resources,

and buffer pool

• Reduce resource contention by having a dedicated RS catalog server you can tune.

• Apply high availability and disaster recovery procedures (e.g. clustering, mirroring, log shipping) to protect the RSDB

Report CatalogBest Practices > High Performance Disk

• Check out Predeployment I/O Best Practices

• Have more smaller size disks with faster rotation speeds (e.g. 15K RPM) vs. fewer larger disks with slower rotations

• Maximize/balance I/O across ALL available spindles

• Separate disks between RSDB and RSTempDB• RSDB a lot of small transactions (report metadata)• RSTempDB has more (not as many) larger transactions

• Pre-grow your databases

• Stripe dB files to number of cores (0.25 – 1.0)• Minimize allocation contention• Easier to rebalance database when new LUNs are available

• Use RAID 10, not RAID 5

Report CatalogBest Practices > Operations Best Practices

• Data in RSTempDB is highly volatile• Report lifetime policy of data = SessionTimeout value (10min)• CleanupCycleMinutes guides background cleanup thread• Once session timeout reached, cleanup temporary snapshot from tempDB• This is done every CleanupCycleMinutes

• Data is RSDB is long lived; should be backed up• Backing Up and Restore Databases in SQL Server• Optimizing Backup and Restore Performance in SQL Server• Backing Up and Restore Encryption Keys

• Maintain your RS catalogs• Remember, these are SQL databses• E.g. Re-indexing catalog tables or updating stats may improve query

performance

Report CatalogBest Practices > Report Catalog Sizing

• RSDB database size• Varies by number of reports published and number of history snapshots• General rule of thumb:

• Moderate size report definition takes 100-200KB of disk space • This is larger than the actual RDL as SSRS persists both RDL and

compiled binary • Assume 5:1 compression ratio (e.g. 10MB of data, snapshot is 2MB in

size)

• RSTempDB database size• Varies by number of users whom are concurrently using the Report Servers• Each live report execution generates report snapshot persisted in the

RSTempDB• General rule of thumb:

• 10-20% concurrency of user base, e.g. 1000 users, then max 200 concurrent users.

• If most users are accessing 10MB reports, then you will need 400MB of storage • 200 users x 10MB reports / 5:1 compression ratio= 400MB

• Want to calculate for the maximum number of concurrent users

Scale Out ≠ Disaster Recovery

Disaster Recovery EnvironmentOverall Infrastructure

RSDB

Content Switch

RSDB

Passive

RSDB

Primary Data Center

DR Site

SSRSSSRS

Content Switch

SSRS SSRS SSRS

Failover Cluster

Bosto

n\sq

l4

Mon

tréal\sq

l4

Disaster Recovery Site - Closely duplicates primary- Separate Geographic

location- Non-critical can utilize

fewer resources- But Mission Critical

ssytems shoul dhave 1:1 duplication

Primary Data Center- SSRS servers- Separate

Report Catalog - With own

Failover cluster

Disaster Recovery EnvironmentNetwork Configuration

RSDB

Content Switch

RSDB

Passive

RSDB

Primary Data Center

DR Site

SSRSSSRS

Content Switch

SSRS SSRS SSRS

Failover Cluster

Bosto

n\sq

l4

Mon

tréal\sq

l4

Network Config- Ensure network

connectivity for clients

- Use content switch to load balance and redirect traffic

- Direct fiber between PDC and DR to minimize latencies

Disaster Recovery EnvironmentDatabase Configuration

RSDB

Content Switch

RSDB

Passive

RSDB

Primary Data Center

DR Site

SSRSSSRS

Content Switch

SSRS SSRS SSRS

Failover Cluster

Bosto

n\sq

l4

Mon

tréal\sq

l4

Database Config- Boston\sql4 is

primary RSDB instance w/ active/passive cluster in PDC

- Content switch points to sql4 alias

- Mirrored Montréal\sql4 on DR site

Disaster Recovery EnvironmentDatabase Configuration: Active / Active vs. Active / Passive

Content Switch

RSDB

Primary Data Center

DR Site

SSRSSSRS

Content Switch

SSRS SSRS SSRS

Mon

tréal\sq

l4RSDB

Passive

RSDB

Failover Cluster

Bosto

n\sq

l4

Advantages of Active/Passive Failover Cluster- Allows other Active database

instances to be located on Passive node

- Works well if passive node is not over-utilized

Not good if passive node has a lot of traffic, concurrent users, etc. Then should go with Active/Active cluster

Disaster Recovery EnvironmentDatabase Configuration: Asynchronous Mirroring

Content Switch

RSDB

Primary Data Center

DR Site

SSRSSSRS

Content Switch

SSRS SSRS SSRS

Mon

tréal\sq

l4RSDB

Passive

RSDB

Failover Cluster

Bosto

n\sq

l4

Async MirroringAll RS Operations must connect to RSDB for its metadata

Async Mirroring has minimal to no impact on response time performance

OK to be async as report metadata is not frequently updated

Disaster Recovery EnvironmentDatabase Configuration > Initializing Database MirrorA relatively easy way to initialize a database mirroring setup is to:

1. Make full and transaction log backups of the Reporting Services databases on the principal server.

2. Copy the backups over to the disaster recovery site, restoring each Reporting Services database in no-recovery mode.

3. Set up the failover partner on the mirror (that is, the DR site) before you set up the failover partner on the principal server.

Failover Scenarios

• Primary Data Center Reporting Servers go offline• Primary Data Center RSDB Active server goes offline• Primary Data Center RSDB cluster goes offline• Primary Data Center Outage

Failover ScenarioPrimary Data Center Reporting Servers go offline

RSDB

Content Switch

RSDB

Passive

RSDB

Primary Data Center

DR Site

SSRSSSRS

Content Switch

SSRS SSRS SSRS

Failover Cluster

Bosto

n\sq

l4

Mon

tréal\sq

l4

Automatic Failover

Failover ScenarioPrimary Data Center RSDB Active server goes offline

RSDB

Content Switch

RSDB

Passive

RSDB

Primary Data Center

DR Site

SSRSSSRS

Content Switch

SSRS SSRS SSRS

Failover Cluster

Bosto

n\sq

l4

Mon

tréal\sq

l4

Automatic Failover

Failover ScenarioPrimary Data Center RSDB Active server goes offline

RSDB

Content Switch

RSDB

Passive

RSDB

Primary Data Center

DR Site

SSRSSSRS

Content Switch

SSRS SSRS SSRS

Failover Cluster

Bosto

n\sq

l4

Mon

tréal\sq

l4

Manual Failover

Failover ScenarioPrimary Data Center Outage

RSDB

Content Switch

RSDB

Passive

RSDB

Primary Data Center

DR Site

SSRSSSRS

Content Switch

SSRS SSRS SSRS

Failover Cluster

Bosto

n\sq

l4

Mon

tréal\sq

l4

Content Switch suspends primary IP

addresses and activates DR site IP address so all

connections are redirected to DR site

Failover ScenarioPrimary Data Center Outage: Planned Outage

RSDB

Content Switch

RSDB

Passive

RSDB

Primary Data Center

DR Site

SSRSSSRS

Content Switch

SSRS SSRS SSRS

Failover Cluster

Bosto

n\sq

l4

Mon

tréal\sq

l4

Manually execute script to manually switch to

partner database.

Failover ScenarioPrimary Data Center Outage: Unplanned Outage

RSDB

Content Switch

RSDB

Passive

RSDB

Primary Data Center

DR Site

SSRSSSRS

Content Switch

SSRS SSRS SSRS

Failover Cluster

Bosto

n\sq

l4

Mon

tréal\sq

l4

Manually failover script to force service to

switch with possible data loss

Disaster Recovery EnvironmentDatabase Configuration: Always On

Content SwitchPrimary Data Center

DR Site

SSRSSSRS

Content Switch

SSRS SSRS SSRS

SSRS - Always On Availability Group

RSDB

Seco

ndary

Replica

RSDB

Prim

ary

Replica

AG Listener VNN

Q&AHope you enjoyed the session!