This is the PASS DW/BI Webinar for SQL Server Reporting Services (SSRS) Disaster Recovery webinar. You can find the video at: http://www.youtube.com/watch?v=gfT9ETyLRlA
Transcript: New from BookNet Canada for 2024: BNC CataList - Tech Forum 2024
SQL Server Reporting Services Disaster Recovery Webinar
1. SSRS Disaster Recovery
PASS DW|BI Webinar
Ayad Shammout (@aashammout) and Denny Lee (@dennylee)
Hosted by Julie Koesmarno (@mssqlgirl)
2. 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
3. Reporting Services Architecture
Typical One-Box Deployment
Report Server
NLB
Clients
RSDB
Flat Files,
OLE DB,
ODBC
SQL, AS,
DB2, Oracle,
Teradata, etc.
Clients
Data Sources (to report against)
RS Server
Report Catalog
Clients
4. Reporting Services Architecture
Remote Report Catalog = Higher Availability
Report Server
NLB
Clients
RSDB
Flat Files,
OLE DB,
ODBC
SQL, AS,
DB2, Oracle,
Teradata, etc.
Clients
Data Sources (to report against)
RS Server
Report Catalog
Clients
5. Reporting Services Architecture
Scale Out and High Availability Infrastructure
Clients
Clients
RS Server
RSDB
Flat Files,
OLE DB,
ODBC
SQL, AS,
DB2, Oracle,
Teradata, etc.
RS Server
Data Sources (to report against)
NLB
RS Server
Report Catalog
Clients
Reporting Scale Out Deployment
Report Server Cluster
6. Report Catalog
Architecture
Report Catalog
RSDB
Report Server Catalog (RSDB)
Stores all report metadata including report definitions,
report / history snapshots, scheduling, etc.
Report Server TempDB
Stores 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
7. Report Catalog
Best 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
8. Report Catalog
Best 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
9. Report Catalog
Best 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
10. Report Catalog
Best 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
12. Disaster Recovery Environment
Primary Data
Center
- SSRS servers
- Separate Report
Catalog
Content
Content Switch
- With own Failover Switch
cluster
Overall Infrastructure
Primary Data Center
SSRS
SSRS
SSRS
Failover Cluster
Disaster Recovery Site
- Closely duplicates primary
- Separate Geographic location
- Non-critical can utilize fewer
resources
- But Mission Critical ssytems
shoul dhave 1:1 duplication
RSDB
Montréalsql4
RSDB
Bostonsql4
RSDB
SSRS
SSRS
13. Disaster Recovery Environment
Network Configuration
Primary Data Center
SSRS
SSRS
SSRS
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
RSDB
Montréalsql4
Failover Cluster
SSRS
SSRS
Bostonsql4
RSDB
RSDB
Content Switch
Content Switch
14. Disaster Recovery Environment
Database Configuration
Primary Data Center
SSRS
SSRS
SSRS
Database Config
- Bostonsql4 is primary
RSDB instance w/
active/passive cluster
in PDC
- Content switch points
to sql4 alias
- Mirrored Montréalsql4
on DR site
RSDB
Montréalsql4
Failover Cluster
SSRS
SSRS
Bostonsql4
RSDB
RSDB
Content Switch
Content Switch
15. Disaster Recovery Environment
Database Configuration: Active / Active vs. Active /
Passive
Primary Data Center
SSRS
SSRS
SSRS
Advantages of Active/Passive Failover
Cluster
SSRS
- Allows other Active database instances
SSRS
to be located on Passive node
- Works well if passive node is not overutilized
RSDB
Montréalsql4
Failover Cluster
Bostonsql4
RSDB
RSDB
Content Switch
Content Switch
Not good if passive node has a lot of
traffic, concurrent users, etc. Then should
go with Active/Active cluster
16. Disaster Recovery Environment
Database Configuration: Asynchronous Mirroring
Async Mirroring
Content Switch
All RS Operations must connect
Content Switch
to RSDB for its metadata
Primary Data Center
Async Mirroring has minimal to
no impact on response time
performance
SSRS
SSRS
SSRS
SSRS
SSRS
OK to be async as report
metadata is not frequently
updated
Failover Cluster
RSDB
Montréalsql4
RSDB
Bostonsql4
RSDB
17. Disaster Recovery Environment
Database Configuration > Initializing Database Mirror
A 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.
18. 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
19. Failover Scenario
Automatic Failover
Primary Data Center Reporting Servers go offline
Primary Data Center
SSRS
SSRS
SSRS
RSDB
Montréalsql4
Failover Cluster
SSRS
SSRS
Bostonsql4
RSDB
RSDB
Content Switch
Content Switch
20. Failover Scenario
Primary Data Center RSDB Active server goes offline
Primary Data Center
SSRS
SSRS
SSRS
RSDB
Automatic Failover
Montréalsql4
Failover Cluster
SSRS
SSRS
Bostonsql4
RSDB
RSDB
Content Switch
Content Switch
21. Failover Scenario
Primary Data Center RSDB Active server goes offline
Primary Data Center
SSRS
SSRS
Content Switch
Content Switch
SSRS
RSDB
RSDB
Manual Failover
Failover Cluster
Montréalsql4
Bostonsql4
RSDB
SSRS
SSRS
22. Failover Scenario
Primary Data Center Outage
Primary Data Center
SSRS
SSRS
SSRS
Content Switch suspends
primary IP addresses and
activates DR site IP
address so all connections
are redirected to DR site
RSDB
Montréalsql4
Failover Cluster
SSRS
SSRS
Bostonsql4
RSDB
RSDB
Content Switch
Content Switch
23. Failover Scenario
Primary Data Center Outage: Planned Outage
Primary Data Center
SSRS
SSRS
SSRS
Manually execute script to
manually switch to partner
database.
RSDB
Montréalsql4
Failover Cluster
SSRS
SSRS
Bostonsql4
RSDB
RSDB
Content Switch
Content Switch
24. Failover Scenario
Primary Data Center Outage: Unplanned Outage
Primary Data Center
SSRS
SSRS
SSRS
Manually failover script to
force service to switch with
possible data loss
RSDB
Montréalsql4
Failover Cluster
SSRS
SSRS
Bostonsql4
RSDB
RSDB
Content Switch
Content Switch
25. Disaster Recovery Environment
Database Configuration: Always On
Primary Data Center
SSRS
SSRS
Content Switch
Content Switch
SSRS
SSRS
AG Listener VNN
SSRS - Always On Availability Group
RSDB
Secondary Replica
Primary Replica
RSDB
SSRS
To ensure connectivity from the clients to the primary data center and the disaster recovery site, a common technique is to use a content switch to load-balance traffic within the individual sites as well as between the global sites. In the case of CareGroup Healthcare, a Cisco GSS is used as the content switch. As well, there is direct fiber network connectivity between the primary data center and the disaster recovery site to ensure minimal latencies for any communication between the two centers. If the primary site goes down for any reason, the content switch transparently redirects all client traffic to the disaster recovery set of Reporting Services servers. If the content switch is unavailable, the IP address can be changed at the DNS level. This latter change is a manual switch with a slightly longer network outage, which is due to the DNS cache clearing the old IP address and pointing to the new one.
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.
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.