Our environment contains two instances on SQL 2008 that host Reporting Services. They are not in a scale-out architecture, rather each SSRS instance points to two separate data centers. However the reports on both instances are identical.
Both instances are being hosted as virtual servers using VMWare. Recently we began testing a disaster recovery scenario where one server would become unavailable for some reason. In this case the plan is to make a clone of the remaining SSRS server and reconfigure it to be the unavailable server.
From a SQL standpoint our tasks are fairly simple; we just need to insure that the backup of a single user database (small file, about 30 MB) is available from anywhere on the network as well as the encryption key from Reporting Services. The report catalog and Agent jobs are identical on both servers and don’t need to be restored.
These are the steps we took to configure the VM clone as the unavailable SSRS server. I just copied from the document I wrote for our internal use so some of it is pretty basic. But I hope it will help you if you need to perform something similar.
1. Verify that the drive configurations are correct and that all databases are present and in their correct locations.
2. Open the SQL Server Configuration Manager and select SQL Server Network Configuration > Protocols for <Instance Name>. Right click TCP/IP and chose the IP Addresses tab. Look for the IP of the old server (it’s probably under IP1) and change the IP address to the new IP. Close the Configuration Manager.
3. Start the SQL service for the instance. Leave the Agent, Browser, and Reporting Server services off. Turn them off if they’re running.
4. Open Management Studio and log into the new server. Use .\InstanceName as that may be the only way you will be able to connect until after you change the name.
5. Run tests against the data to verify that you have the right databases. Confirm the server name is still the old name
SELECT @@SERVERNAME
6. Change the name of the SQL server. NOTE: You can only change the computer name, not the name of the instance. Also note that the host name of the full instance name is limited to 16 characters including the (\): so 1234567890123DR\Reporting is legal whereas 1234567890123-DR\Reporting is not.
1: USE master;
2: GO
3:
4: EXEC sp_dropserver 'OldServerName\InstanceName';
5: GO
6:
7: EXEC sp_addserver 'NewServerName\InstanceName', local;
8: GO
7. Turn off the SQL service. Restart just the SQL service and connect via SSMS. Verify that you can connect. Run SELECT @@SERVERNAME again to verify the server name is correct inside the database.
8. Start the Reporting Server services and open the Reporting Services Configuration Manager. Connect to the local instance.
9. Go the Databases in the left frame. Click Change Database, then select Choose an existing report server database and click Next.
10. Enter the new Database Server name (the new name of the instance) and click Next.
11. Choose “ReportServer” from the drop down list for Report Server Database then click Next. Continue to click next until you finish the wizard.
12. Back on the main screen of the Reporting Services Configuration Manager select Encryption Keys and then click Restore.
13. Point to the location of the encryption key, enter the password, then click OK.
14. Open RSReportServer.config (the default path is C:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services). Change the URL path from the old server to the new server. Use the new IP and not the server name.
After this the Report Catalog is ready to go. All I have to do is restore the small user database and reset any needed logins and we’re good to go.
We have another approach for this type of “hot spare” scenario. The basic concept is to use DNS C Names for any application that needs to reference the SSRS. The C Name points to the active/healthy server. If we need to fail over to the stand by, we change the DNS C Name to point to the ip for that server.
Your thoughts?