On 2/7/11 1:01 PM, Willy Tarreau wrote:
On Mon, Feb 07, 2011 at 09:45:21AM +0100, Bedis 9 wrote:
Do you have an example of what purpose it would serve ? I'm asking
because it's not very easy to implement with table-based algorithms,
since the size of the table is determined by the GCD of all active
servers' weights. Thus adding a new server will change the size of
the table.
It's also a feature I've never seen on other products either, which
makes be doubt about its usefulness.
Hey Willy,
It's really useful in big organizations, when you have to manage tens
and tens of LBs and you want to ease the management.
An API available remotely allows you to write your own centralized
management tools:
- configuration backup
- configuration edit and push
- collection of statistics
etc...
I'm well aware of the usefulness of the API, I was meaning that switching
a server's role between active and backup did not seem useful to me ;-)
What was your original intent of the "Backup Server" feature?
Our organization uses backup servers to assist with new code rollout and
easy rollback. (I'm not fond of it, just looking to automate it with APIs)
example use case:
Four Servers A,B,C,D
All Running The Same Code Rev
A & B are primary
C & D are in backup
The Upgrade:
C & D upgrade to new code rev.
The Flip: (as quickly as possible to try to stay atomic)
C & D taken out of Backup State
A & B put in to Backup State
Sanity Checking Phase:
Make sure new live roll is performing as expected.
Hold on to older rev A & B boxes until you feel C & D are solid.
(typically 15-30 minutes)
If the new push is terrible, you can revert "The Flip" above.
Steady State:
Upgrade A & B to match C & D's code revs.
Now A & B can be thought of as emergency backup for if/when C/D fall over.
Lather, rise repeat (swapping AB/CD above)....
Does the above use case make sense to you?
Known limitations:
Ideally it would be much easier to downgrade a single system's code.
(working on that)
Also this clearly doesn't well scale to larger deployments -- 50 active
and 50 standby. (working on that too.)
--Joel
