The thing I didn't realize yesterday is that DATABASE also resolves to the currently active node, not only CLUSTER:
Say DATABASE is the cluster name and NODE1 and NODE2 are the nodes, then
DATABASE resolves to the currently active node, so if NODE1 is the active
node, then DATABASE resolves to NODE1.
So, the thing to do is install reporting services in both nodes having them both pointing to the same ReportServer database in the database cluster.
Let's assume you already have the cluster and have SQL Server installed in
clustered mode already (requirements.) Always use the same version (same SP
between reporting services in every node.)
Then, these are the steps to follow:
Connect to the active node (NODE1) and install and
configure reporting services on it, creating a ReportServer database on
DATABASE (via the Database Setup, provide proper credentials to the DB),
you then initialize the database in the configuration as well.
Then connect to, install and configure reporting services on the
passive node (NODE2), set up the database to the existing database on
DATABASE (the one you already created, providing the same credentials to
connect to the DB), but DO NOT INITIALIZE IT NOW (ON THE PASSIVE NODE).
Connect back to the active node and run the reporting services
configuration again, now in the initialization you'll see the passive node
appearing, you can then initialize it from there.
Then you'll have two instances of Reporting services, one on each node,
and pointing to the same database. And now, when the nodes failover
you'll have the other instance working.
The only pain I've found so far is that if you don't expose the logs nor
have them accessible via \DATABASE\C$\Program
have to remember which one's the active node to go see the logs there.
This is called "scaling out Reporting Services" and is supported only on
Enterprise edition (plus developer and evaluation)
To upgrade both report servers: