Sticky cookies load balancing

[krizhanovsky]

Sticky cookie scheduler (#593) and the whole http_sess must be extended by the following:

• sticky cookie must be configurable per vhost and/or server group to be able to set different sticky cookies for different serviced domain;

• sticky cookie must set configurable expire values;

• we should be able to use upstream native session cookies, so the cookie name should be specified with some new configuration argument (Nginx uses "learn" for the option), see more info at http://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html#stickyness_implementation

• the sessions must be stored in persistent TDB table, just like we did this for client accounting in Temporal client accounting #1178

Notes on persistent data structures

I add the notes here since I added the last bullet about TDB usage as the sessions storage with several doubts, at least that currently TDB is unfinished and buggy. There are two main reasons to use TDB instead of plain hash tables:

1. performance - HTries is significantly faster than hash and will be optimized further

2. data persistency (in normal conditions, not crash safety) - we need to dynamically deploy (Continuous delivery #786) crucial security fixes for the kernel and system reboot is required, so it makes sense not to lose sessions and client accounting as well as the web cache. During one of the pilot projects we've discussed that typically there are monthly security updates.

The notes about persistent data structures are good to add to the Wiki, like High avaliability section, when the issues is completed.

[vankoven]

There was a discussion, that locks in sticky sessions scheduler might be reworked in a better way. #713 (comment)

[vankoven]

Sticky cookie module should process a request before it's assigned to any vhost, see #1043, #899 (this behaviour is implemented in #1067 ). With per-vhost cookie it means that we don't know in advance which cookie must be stored in the request. So the fast string matching algorithm should be used to search among all possible sticky cookie names.

[vankoven]

There was a discussion in the chat about #685 and #1075 implementation. According to it there is no reasons to introduce new data structures, it's better to reuse/update existing ones. We can also put vhost name into cookie name, like: __tfw_<vhost> instead just __tfw. As soon sticky cookies can assign vhost to the request, they're close to the http_chain, so code used for http_chains can be reused. Please, revise the notes in the chat on implementing the issue.

[vankoven]

Almost forgot. JS challenge must be also configured per-vhost, but JS challenge web page is composed from templates at Tempesta start:

tempesta/scripts/tempesta.sh

Line 187 in 56e0889

update_js_challenge_template

As cookie name is different between vhosts, JS challenge web page can also be per-vhost.

[vankoven]

it makes sense not to lose sessions and client accounting as well as the web cache.

Requirement was removed after discussion in the chat. Http session structure stores state, the state contains information from other modules. The information - is data structure pointers. On cold reboot pointers can't be used as is, it's necessary to update pointers to actual values.

It complicates task a lot:

• need to store vhost name with the TfwHttpSess to restore vhost pointer, so the structure can't be fixed size and short enough to fit tdb requirements;
• server ip address to restore pinned TfwServer;
• Tempesta's boot id to spot that the entry was outdated from the last run, and pointer are no more valid.

It even looks like generic TDB feature and doesn't contain a lot to session-related questions.