for starters, go read

https://jazz.net/library/article/584
and
https://jazz.net/library/article/617

the first one is about planning and deploying your BF console. it touches a little on sizing, I'll expand below.

the second one is on how servers get selected for a job. since you're using pools (smart) you'll want to understand how servers get selected out of pools and how to take advantage of them based on load and available resources.



on sizing:
What is important when considering the number of management consoles, is how many jobs will be running concurrently, and how busy each job is going to make the console.

You can estimate the number of concurrent jobs based on how frequently you'll be starting jobs, and how often they run. if your management console is also your DB server you lose some of your capacity (roughly half depending on your DB vendor). If your management console is also a file server for your build servers, you'll lose more capacity (not quite the other half, but close).

Start with a rule of thumb of 3 concurrent jobs per processor core. If those jobs are going to really busy the management console (that comes next) then reduce that number. If they're not, then you can increase that number.

Making the console busy means transferring output from the build servers to the database. Lots of output per step (thousands of lines) means lots of data transfer and lots of DB inserts. That translates to lots of work for the console.


I'll let you read on the selection process, but to cut to the chase, managing 8 servers in 4 pools (2 pools of 1) is not impossibly complex.