These requirements are not completely unusual, but it looks headed for trouble.
For most meaningful business web apps, high-available load-balancing proxies should be almost everywhere. This means using whatever is appropriate: dns round-robin, haproxy, ipvs, pfsense, f5's, netscalers, cisco ace, etc.
Web servers serving static content should be stateless. Other than dropping connections, there should be little to no impact on users if any one web server goes away. So, there is no need to have disk replication between machines. Use LB mentioned above to accomplish the same thing with less effort. Replication creates fragile dependencies and a support nightmare that could bring everything down. Pushing with git or rsync over ssh as mentioned previously from an internal deployment server is better idea. If pushing content to thousands of nodes, the murder gem from twitter is awesome.
Application servers, anything producing a web page based on data that changes, should be relatively stateless as well. Definitely use something like Nginx to do clean, rolling, exponential deployments of the app. Data should be kept in a database (sql/nosql) or RESTful data provider.
Exhaustively-tested failover should be reserved for protecting databases and other crucial components. For performance, if the application is measured to have a concurrent write bottleneck at the database beyond what throwing hardware at it (scale-up) can handle, consider a reliable nosql which uses a log-structured storage engine such as riak's bitcask.
If this is not a web app but processing a large amount of data, evaluate a MapReduce framework like Hadoop which uses their HDFS.