PHP application server (like thin or mongrel)

Regarding MySQL,

1. mysqltuner is a must for any prod box.
2. Slow Query Log will get you a long way down the road to a more performant app.
3. Turning on the General log (BRIEFLY) can be a good thing, then go run EXPLAIN on all your queries to make sure you have proper indexing (no coverage, good cardinality, etc.)
4. Are you keeping session in the database? Don't do it if you can avoid it, but if not, consider a MEMORY table.
5. While on the subject of table types, consider the actual usage of each table. Transactional tables with high read/write needs might be better in the InnoDB storage engine. Tables that are predominately write or read might best be served as MyISAM. Are you logging to the database too? Consider the ARCHIVE engine for those tables.

A few general things that I've learned over the years:

• See this question for a list of good books on the subject of performance, scaling and high availability sites.
• "Cluster" is the correct term. You're using multiple machines to serve one site in an attempt to increase availability. You can also use cluster to refer to specific portions of your setup: for example servers 2+3+4 would be your application cluster.
• Is there any reasons why you only have redundancy on the application level? What about MySQL and static content? Especially since your static content is relatively large look at how much bandwidth you can serve to N concurrent users if needed. What happens if the MySQL server fails or if server #4 has a bad disk?
• If you're moving everything from one machine start off small unless you don't mind spending more than you need. For example, I found a larger than expected performance gain in a similar situation moving from 1 to 3 servers. After you split into multiple servers you may find the new bottleneck is in a different area.
• As you plan for scaling now don't completely forget about possible future scaling. A little forward thought and design now can save you time in the future. For example, you have one static server now but what you want multiple in a year, or several servers spread out geographically.
• Consider creating scripts to help setup specific types of servers...doing it manually each gets old and you always forget one step. I did this recently and wish I had done it from the start. Running one script that does 50 install steps automatically in a few minutes saves you much time in the long run.
• As you get more servers the likely-hood of experiencing some sort of hardware failure becomes higher. Plan for this and play the what-if game: What if the hard drive failed on server X? What would we lose? How long would the site be out? How long would it take to fix it? etc...