putex/README.md

putex

Process Mutex

Used to manage a lock and timing components of an at-most-once execution system.

NATS

This currently uses NATS exclusively for locking but there is the possibility to extend this to using other locks.

NATS is used via optimistic locking of a kv bucket entry. If it's able to write the lock with its own value before it's changed by the current owner through renewal or by another agent becoming the owner, it gets to be the owner. The agents follow a set of rules and a common execution plan which ensures they will always elect a single leader and never accidentally overlap execution (as long as the operator also follows the rules!)

The Variables

R - Lock Renewal Interval

How often the active agent will run its health check and assert its activeness.

F - Failure Threshold

How many R must pass without the lock being updated before an agent may take the lock. This is the maximum timeout of a health check as well because returning after this time will result in an expected failover anyway.

C - Confirmation Count

How many R must pass between a new agent becomes active and when it is allowed to fence other nodes and activate its service.

The Rules

Operator (YOU)

• healthcheck
  • The healthcheck will be given an argument of active or standby indicating whether the lock is currently held by this agent. If it is active, a more thorough check should be performed, if possible. If it is standby, the healthcheck should indicate whether we believe that healthcheck active would pass after the confirmation cycles
  • The health check should not take more than R in normal circumstances but may run over R in exceptional circumstances which do not require a failover such as a switch power cycling somewhere causing a 2 second outage where you have R=1000 and F=3 (so you have allotted 3 seconds and the health check takes 2 seconds to return a result because of the packet loss -- this is greater than R but less than R*F so a warning will be produced but failover will not occur.
  • The health check MUST NOT take more than RF to run or else it will have lost its lock to another agent. If the health check might take more than RF in circumstances where failover would not be appropriate, R, F, or both should be increased, with F increasing the overall failover window and R slowing the system down overall to allow the health check to keep up.
• activation
  • The activation script should first fence the other hosts, if possible and necessary for the use case. The activation script will have been called after at least C*R so this should happen immediately followed immediately by the service being started.
• deactivation
  • Deactivation must take place within C*R. If deactivation will need more time than is allotted, increasing C or R will accomplish this with R affecting all aspects of the system and slowing it down in general.

Agent Operation Theory

Uses a specific key in a specific bucket in a NATS cluster to lock a runner for a specific process.

my-hostname:~$ natslock nats.cluster.local locks spof-service my-hostname

Each token should be unique, generally the hostname. These will also be in the kv store and can serve to document the current state of the system.

The implementation should ensure that time skew does not affect synchronization.

R = lock renewal interval F = lock renewal failures before taking the lock C = lock renewals to wait before starting after takeover T = lock timeout = R * F consider the example of F=1 to ensure the logic makes sense. if R = 1s and F=1 then a renewal needs to happen within a 1s period from when we check first to when we want to take the lock. With these parameters, after 1s with no updates, we would expect to take the lock immediately and so T=R*F.

A client has the lock and should run the service when its token is present in the key for C full renewal interval(s) or immediately if this is the first revision or if the current token is empty.

• When done after takeover, this gives the former system time to shutdown, if necessary. C should generally be 1 and the shutdown/fencing mechanism should be instantaneous (iptables/kill -9).

A client obtains the lock by writing its token to the key.

A client may write to the key when there have been no writes for T seconds or when the key does not exist.

A client may only write to the key if it does not exist or if it has not been updated since the last read (in addition to other rules of the protocol). Does not exist: use create which will fail if the key has been created Exists: use update with revision to ensure the revision that was read is also the one being replaced.

Both may be attempted in parallel since only one may possibly succeed.

Any failure to write to the key must result in the underlying application being killed or otherwise fenced immediately (within R from the last interval).

A client renews its lock after running its health check. The health check should take less than R but MUST take less than T or else the client will lose its lock. Since it must lose its lock and must recognize that this has happened, the health check will always timeout after T and the lock will be given up immediately.

Not init

This solution is intended to signal services to start or stop, not act as an init system in its own right. Thus, you should be doing something like systemctl start database.service, not redis-server. Fencing should be handled via the systemd unit DAG as well.

Pump

Runs in an explicit, stateless trampoline executor (in addition to the tokio async executor), with an action of "pump" in the code. Each run builds its state at the start and may loop a finite number of times but must return to the outer loop occasionally to allow it to do housekeeping as well as to clear the stack depth for when tail call optimization fails (reportedly unreliable in rust currently). Stated differently, the pump action is also a DAG with a single entry and single exit.

A single pumping stroke happens from Start to End in the diagram.

Each stroke lasts at least R. This is accomplished by awaiting a timer running in parallel to pump at the end of the pump stroke (i.e., it is not part of the pump function but is an important implementation detail of pump).

State Machine

flowchart TD
Start(((Start))) --> GetLock

GetLock[lk = Lock Value\nrev = Revision] --> Empty{"lk empty or mine?\n(or failed to retrieve\ntimeout = 1R)"}
Empty -- yes --> HCSunnyLoop
Empty -- no --> WaitKill
WaitKill[Kill Process] --> HCWait

HCWrite[Run Healthcheck] --> HCWriteSuccess{Success?}
HCWriteSuccess -- yes --> Write
HCWriteSuccess -- no --> WaitR
Write[Write Lock] --> WriteSuccess{Success?}
WriteSuccess -- yes --> WriteWaitCR
WriteSuccess -- no ---> WaitR
WriteWaitCR[["Wait R\n(C-1 times):\n->Write Lock\n->Wait R"]] --> WaitR
style WriteWaitCR text-align:left

HCWait[Run Healthcheck] --> HCWaitSuccess{Success?}
HCWaitSuccess -- yes --> WaitFR
HCWaitSuccess -- no --> WaitR
WaitR[Wait remainder of R, if any]

WaitFR[Wait F*R for takeover] --> HCWrite

HCSunnyLoop[Run Healthcheck] --> HCSunnyLoopSuccess{Success?}
HCSunnyLoopSuccess -- yes --> SunnyLoopWrite
SunnyLoopWrite[Renew lock\nMay attempt for\nup to F*R seconds] --> SunnyLoopWriteSuccess{Success?}
SunnyLoopWriteSuccess -- yes --> SunnyStartProcess
SunnyLoopWriteSuccess -- no --> SunnyLoopAbort
SunnyStartProcess[Unfence Self\nFence Others\nEnable Process] --> WaitR
HCSunnyLoopSuccess -- no --> SunnyLoopAbort
SunnyLoopAbort[Attempt to write blank to lock\nOne attempt only.] --> SunnyKill
SunnyKill[Kill Process] --> WaitR
WaitR --> End((End)) --> ToStart[Back to start]