The local GT Block

[AltraMayor]

For rather small deployments, deployers are willing to compromise redundancy and have instances of the GT block on Gatekeeper servers, so the whole deployment is a single Gatekeeper server. Being able to do that requires a new local GT block that only receives mailbox messages from the SOL block instead of from the RSS queues of the NICs. Receiving messages from the SOL block requires changing the SOL block to send packets directly to the local GT block. Not only does this link between the SOL block and the local GT block naturally bind the number of instances of the local GT block to the number of instances of the SOL block, but it also naturally binds the instances of the local GT block to the same NUMA nodes of the instances of the SOL block. Finally, this local GT block should bypass the GGU block and send policy decisions directly to the instances of the GK block.

The local GT block could interfere with the performance of the GK block because both blocks will compete for the processor's cache. However, this could be a reasonable compromise for such a minimal deployment.

Given that the local GT block will increase the memory pressure on the machine, issue #637 should be implemented first, so LuaJIT has more options for memory allocation.

While the local GT block does not require changing anything in the GGU block, the GGU block becomes optional in this configuration. The only reason to maintain the GGU block running is to eventually expand this minimal deployment with Grantor servers.

While there are no foreseeable roadblocks to this approach, the implementation touches a lot of code, so the work is not quick and easy. In addition, due to all the added flexibility, this project requires a deployer willing to sponsor all the production tests to guarantee that everything is in place and no bugs are introduced to the other configurations of Gatekeeper.