- Simplify deployment by:
- Eliminating “automatic inclusion” of Talaria into production server group due to service discovery.
- Eliminating re-sharding events that impact CPEs connected to Talaria nodes not pulled from service.
- Enabling specific Talaria nodes that are being pulled from service to be drained before being pulled from service.
- Enable stronger Geo affinity by providing automatic fail-over in a DC with minimal impact to CPEs attached to unaffected Talaria.
- Enable a deployment that moves the minimal amount of CPEs, yet does so under very controlled conditions.
- Retain complete DC failover support.
Change from consistent hashing and service discovery for determining the Talaria cluster count to rendezvous hashing & a fixed list of Talarias per DC. The list will be stored/shared via Consul’s key-value service per DC.
In addition to the simple rendezvous hashing, the fan-out pattern will be limited by a
xxx_hash_k parameter that limits the fan-out permitted by talaria, petasos and scytale. This feature is designed to enable highly optimal fan-out rates (normally
2 valid talaria per DC) vs the need to either progressively go through all talaria nodes or need to fan out to all talaria nodes in a DC to find the CPE.
Petasos will have a new feature where it will randomize from
[0 to petasos_hash_k) and return only that talaria URL. By making petasos randomize, failures are automatically routed around without the need to determine if a node has failed. This feature also prevents the need for clients to alter their existing behavior.
Talaria will also have a new management function that forces talaria to re-read the
/kv/talaria_list value as well as the
/kv/talaria_hash_k value and apply a “pruning process” where CPEs that are no longer eligible to be attached to that talaria will be disconnected. The API call will return when the process has completed & return the combination of
/kv/talaria_hash_k in the response to inform the caller of the state achieved. This allows automation to ensure talaria is behaving correctly prior to changing the
/kv/scytale_hash_k value to a more restrictive value.
Finally, this feature will require some new tools to be developed to perform parts of the upgrade process automatically. These tools will need to interact with Consul & it’s kv store as well as the service discovery.
Consul key list:
/kv/talaria_list = "talaria-0000-v010203-xyz.xmidt.comcast.net, talaria-0001-v010203-aad.xmidt.comcast.net, ..." /kv/talaria_hash_k = 1 /kv/scytale_hash_k = 1 /kv/petasos_hash_k = 1