My take on this:

You didn't mention if this was a write intensive or read intensive clustered application.. For a read intensive cluster app (such as a search engine, maybe), small localized dbs might be just the trick..

I've done a similar thing, although that was because the client couldn't afford the Oracle licensing fees for a big machine.. put in small local mysql databases on each cluster machine, and then updated through cron every night..

Another somewhat unrelated solution to this is the venerable Squid, working in reverse proxy (httpd acceleration) mode.. again, in a read-intensive environment, serving cached content is far far more effective than multiple servers..

For a write intensive environment though, I might think about partitioning the tables after a careful analysis of the write patterns.. ie: the table x and table y get most of the writes, so put them on separate HDs, or even separate DB servers... My opinion though, NFS is probably not such a good idea if you really want good write performance.. haven't really seen stunningly fast NFS drives (of course, I'm sure I haven't seen really good NFS configs, so this hardly counts)
HTH

Here's suspecting that either your DBMS supplies a load-balancing / mirroring utility, or you're better of switching your DBMS than trying to write one from scratch.

In the realm of free DBMSen, MySQL now does DB replication. This should not be taken as an endorsement thereof. But poke around on your candidate DB sites.