Rendez-Vous : a consistent hashing policy

Setup a list of servers for a given URL using a hash function and the request is assigned to the first available server of the list

An implementation of consistent hashing with minimal disruption when a server is added or removed

Server weight and distance can be taken into consideration

📘

NOTE

In the cloud when traffic between availability zone is billed, or in multi-PoPs settings, upstream servers are naturally split into two or more groups. The HPC should obviously prefer servers from the local or closest group to minimize network egress costs. In the HPC, this constraint is fully compatible with consistent hashing. By using distances, the HPC can be instructed to perform consistent hashing locally, and switch to remote servers if and only if all local upstream servers are down denylisted.

Iterative

Requests are sent to the first available server in the list

Least-loaded

A request is sent to the server with the least number of pending HTTP request.

Server weight and distance can be taken into consideration

Round-robin

Requests are distributed evenly across the servers.

Server weight and distance can be taken into consideration

Retry and ban policies

Additional properties are available to describe the retry and ban policies.

config.upstreams["origins1"] = {.load_balancing = rendez_vous,
                                .next_on_status = {404},
                                .ban_on_status = {500, network_error},
                                .max_redirect = 1,
                                .max_retries_per_origin = 1,
                                .retry_sleep_ms = 500ms,
                                .endpoints = {{.host = "https://172.16.0.1"},
                                              {.host = "https://172.16.0.2"},
                                              {.host = "https://172.16.0.3"}};