Bao,
That all sounds reasonable and it should be the normal way of preparing the clustered configuration for the F5 Management Pack solution, but there's a problem with correctly persisting the F5 Monitoring service state (related to device configuration) across the cluster nodes and I will briefly describe the issue here, with a more elaborate follow-up in our future article, about clustering the F5 Management Pack.
First of all, I should probably start by mentioning here that the current version (1.x) of the F5 Management Pack (F5MP) does not have a 'native' built-in support for clustering with MS Cluster Service (MSCS). While the SCOM-integrated modules of the F5MP (and the actual management pack), for the most part would follow the clustering pattern implemented by the SCOM-clustering infrastructure, there is a problem with the F5 devices discovered and the way the F5MP associates them with the actual host (RMS / MS) they have been discovered on. The association goes by MAC-address unfortunately, e.g. "server host with MAC-address 'foo' owns device 'bar'". As you would probably guess, if we discovered device "DEV-1" on RMS-host "RMS-1" the F5MP datasource will store the device configuration data associated with the MAC-address of RMS-1. In the Active / Passive clustering scenario supported by SCOM (clustering the RMS hosts), when RMS-1 goes down and RMS-2 takes over, the F5 Monitoring service will assume that DEV-1 is "owned" by RMS-1 and as a result there will be no F5 device configuration / hierarchy rendered within SCOM, to say the least.
At this point, a possible temporary workaround / solution we're looking at, would probably be to update the F5MP database on-the-fly (through some service-startup-scripting mechanism) with the current MAC-address of the RMS-host taking over, so that after the fail-over the whole device-configuration data would be associated with the appropriate MAC-address. But this may not work entirely, and we're still testing this approach. But again, at this time, we're not committed to support in any way the clustered configuration with the current release of the F5MP.
Native clustering support with the F5MP is definitely on our road-map, but it will be a future release of the F5MP addressing this capability and this will also depend on Microsoft's direction with the upcoming SCOM platform (OM10, to be out around 2010).