Skip to content
/ f5gs Public

F5 Graceful Scaling helper daemon

License

Unknown, Unknown licenses found

Licenses found

Unknown
LICENSE.txt
Unknown
COPYING
Notifications You must be signed in to change notification settings

kerolasa/f5gs

Folders and files

NameName
Last commit message
Last commit date

Latest commit

4e6668c · Dec 24, 2020
Oct 13, 2013
Feb 17, 2018
Jan 17, 2015
Apr 11, 2014
Oct 13, 2013
Oct 9, 2013
Mar 20, 2015
May 25, 2014
Mar 20, 2015
Dec 10, 2016
Sep 5, 2015
Mar 20, 2015
Sep 5, 2015
Mar 20, 2015
Feb 10, 2015
Dec 10, 2016
Jul 23, 2018
Dec 24, 2020
Jan 14, 2019
May 29, 2017
Jan 14, 2019
Jul 23, 2018

Repository files navigation

F5 Graceful Scaling

This program was originally intended to be an F5 health check for services that other vice are difficult to make announce they should not receive traffic. When load balancing is done to services such as DNS, LDAP, or SMTP, the case is valid. That is also where the three states, 'enable', 'maintenance', and 'disable' come from. The maintenance is meant to be the state in which a system will serve existing requests while new requests are sent to other members of load balanced group. Most often the f5gs is additional health check aside of the actual service healt check.

After use of this program it is increasingly clear states can be used as generic declaration of intended system state. When an operator switches state from enabled to maintenance not only incoming traffic should stop coming, but application monitoring will need pause as well. The disabled state can be used to declare incoming decommissioning of the system, which makes even basic monitoring such as disk space alarming to halt

Same is true for various automation pieces. When system is not enabled configuration management tasks (puppet runs) or scheduled jobs (cron scripts) should not happen. That is why Testing a f5gs state is made easy, see contrib/crontab.txt for an example.

Nothing forbids servers to self declare their state using f5gs instrumentation. Depending on environment that can be good or bad. Where servers declare their state automatically one is trusting automatic decision making in such cases to be solid. Author of this program thinks automatic state changes can be quite challenging to get right. Primary reason is that it is hard to predicting what sort of error states should forbid or cause automatic state changes, and how to avoid flapping.

Conservative approach to take this utility in use is to leave state changes to be solely human expressions of will. Extending human activity by automating partially is good approach. For example if automatic system upgrade could set state to maintenance, due a reboot that follows it, leaving post upgrade success check to be human task along with f5gs enabling.

See also NEWS file for a blog like information about the command, and rationality why something was implemented including what was a thought to be use of it.

Sami Kerola

About

F5 Graceful Scaling helper daemon

Resources

License

Unknown, Unknown licenses found

Licenses found

Unknown
LICENSE.txt
Unknown
COPYING

Stars

Watchers

Forks

Packages

No packages published