Tirex is designed to run on a single host only. This made the design easier and should be enough in most cases. If one host is not enough for your needs there are several strategies possible.
Use a caching proxy in front of Tirex
You can use a caching http proxy such as Squid in front of your tile server. This can take some of the load of the tile server.
Separate database derver
Typically you need a large database for your map data that is accessed from the Mapnik rendering backend. You can install this database on a different host, taking part of the load off your tile server. But be aware that on a typical OSM tile server huge amounts of data flow between the database and the renderer, so you need a fast network connection between the two hosts.
If you run a setup like this, you might want to look at the PgBouncer, a lightweight PostgreSQL proxy .
Splitting the map
Using Tirex syncd
Tirex comes with a daemon called tirex-syncd. If configured properly, it will run in the background on your tile server and gets notified by the master whenever a metatile was newly rendered. It will then copy this metatile, or perhaps also a number of metatiles at once, to one or more other hosts. This can be used to have a hot spare in case your primary host fails, or just to distribute tiles among a larger number of servers. While standard directory replication methods (rsync etc) could be used, these usually perform badly when faced with millions of small files.
See the Config options in the mail file starting with sync for the configuration needed.
In the future Tirex might be changed to directly support multiple hosts, but there are no concrete plans yet.