It sounds like you want to run your service from one box and use the other one in case the primary server fails. In this case, you would either need a small third box as a router with fail-over service or you should use a DNS provider who does this for you. In case your primary server is not available for some time, all requests get automatically redirected to the secondary server.
Depending on your budget, you should seriously consider buying more hardware. With only two servers, you put all your bets on just one server including all software and hardware working fine. And in this case you depend on database replication which for Postgres isn't quite up to the task yet according to others here in this forum (regarding replication, I am only familiar with Oracle).
You should also take into consideration that not only the data has to be the same on both servers but also the code of your .LRN installation. This sounds trivial but depending on how many developers are updating code and who can update the code on the production servers, this can be a bit tricky sometimes. We use CVS with different tags for staging and production and if new code was tagged for production by the project manager, the production servers of our load-balanced web services get updated automatically by a cron script.
In general, not only for performance reasons but also for downtimes due to maintenance of a server, I strongly recommend separating database and webserver and then run two webservers with a load balancer, maybe even even have a backup server for your database (which might even be one of the webservers in case you are on a tight budget).
There are many more things to think about. The higher the uptime that you require at all times, the more time and money you need to put into planning and hardware. And don't forget to think about peformance. We will probably be able to help you a bit more specific if you give us more information about your hardware setup, how many users you expect, and if you can afford some more hardware.
