How Many Console Machines?
We're in the planning stage of organizing our BF installation.
Hypothetically, we've got 8 servers(agents) as follows:
A1, A2 and A3 work together interchangeably as a pool.
B1, B2 and B3 are also a pool, unrelated to pool "A".
C and D are independent agents.
We only have one management console machine right now, with one database. Disregarding performance issues, is it reasonable to manage the four sets of servers with one console? Can the complexities of trying to manage the pools make this impossible? How many console machines should we have? Please give reasons and details.
Thanks,
John Bobinyec
Hypothetically, we've got 8 servers(agents) as follows:
A1, A2 and A3 work together interchangeably as a pool.
B1, B2 and B3 are also a pool, unrelated to pool "A".
C and D are independent agents.
We only have one management console machine right now, with one database. Disregarding performance issues, is it reasonable to manage the four sets of servers with one console? Can the complexities of trying to manage the pools make this impossible? How many console machines should we have? Please give reasons and details.
Thanks,
John Bobinyec
One answer
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.
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.