You are most of the way there.

Let me restate your requirement and then then configs that can handle that.

You have databases that you need to have high availability on. You have two sites that can host the underlying SQL server(s). You need the data to be current on the alternate site in case of a failure of the primary.

That pretty much the requirement?

You can accomplish this with a multi-site cluster, following the instructions in the link I provided. Using clustering in that case does not use SQL replication at all, instead it is storage replication. The downside is this is the single most complex kind of clustering and is done by a VERY small fraction of people doing clustering.

Provided the links are fast enough between sites either of these two are possible.

For a limited number of databases you could use synchronous database mirroring with a witness, this would write the data to both the local and remote server at the same moment and failover is automatic. Failback is more challenging.

If you could tolerate minor levels of data-loss, say <3 minutes worth you could consider log-shipping. Failovers would be manual and there are challenges related to logins and the failover itself but the fail back is fairly straightforward.

The multi-site thing really makes this a challenge, the cross subnet failover won't be supported until SQL 2011 is released, which I would expect toward the end of the year.

Are the clients of these databases largely internal or external, is there a web server sitting in front or what?

CEWII