You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To mitigate these issues, i.e., to prevent them from impacting the SLA and reduce the chance of happening, let's split the Redis instances in our "halfstack" so that we could apply different levels of HA configuration depending on the purpose.
Since we already split the connection pools for each Redis database by different purposes as follows, it is easy to just change the initialization routine of those connection pools to use different connection parameters.
I do not plan to pre-define how to group these Redis databases but leave it to the our solution architect team to determine the desired setup per site.
Though, here are some references to understand the background:
Data persistency requirements
Needed:* STAT (statistics): if lost, it impacts the usage accounting critical for billing and etc.
LIVE (agent liveness, idle checkers): if lost, it impacts the scheduler performance and mis-terminate the running sessions depending on the idle-checker config
Not much needed:* RLIM (rate limit): volatile information, effective only for up to 15 minutes, no need to enforce it strictly on failover
STREAM (event bus): events are transient and often they are retried periodically or have another mean of synchronization.
IMAGE (per-agent image availability map): if lost, automatically reconstructed from agent heartbeats
Main load patterns
STAT, LIVE: proportional to the number of sessions
RLIM: proportional to the volume of client API requests
IMAGE: proportional to the number of cluster nodes
STREAM: proportional to the number of cluster nodes & the number of sessions
Current Implementation
The configuration of Redis connection parameters are stored in etcd and shared across the entire cluster nodes including Manager, Agent, Storage Proxy, and App Proxy.
Currently, the Redis configuration can specify only one Redis instance (either a single host:port address or a list of sentinel host:port addresses).
Let's extend the configuration format to additionally specify per-db instance addresses (either a single host:port address or a list of sentinel host:port addresses).
We could just allow configuring optional, additional mappings from DB index to address settings (either single or sentinels), while non-specified ones falling back to the base address settings. This way, we could keep backward compatibility with existing setups.
An example split:
Instance 1 for STAT, LIVE: persistence with AOF for HA
Instance 2 for STREAM, IMAGE: no persistence with HA
Instance 3 for RLIM: no persistence with HA
The text was updated successfully, but these errors were encountered:
Synopsis
In some customer sites, we have experienced:
To mitigate these issues, i.e., to prevent them from impacting the SLA and reduce the chance of happening, let's split the Redis instances in our "halfstack" so that we could apply different levels of HA configuration depending on the purpose.
Since we already split the connection pools for each Redis database by different purposes as follows, it is easy to just change the initialization routine of those connection pools to use different connection parameters.
Redis databases
I do not plan to pre-define how to group these Redis databases but leave it to the our solution architect team to determine the desired setup per site.
Though, here are some references to understand the background:
Data persistency requirements
Needed:*
STAT
(statistics): if lost, it impacts the usage accounting critical for billing and etc.LIVE
(agent liveness, idle checkers): if lost, it impacts the scheduler performance and mis-terminate the running sessions depending on the idle-checker configNot much needed:*
RLIM
(rate limit): volatile information, effective only for up to 15 minutes, no need to enforce it strictly on failoverSTREAM
(event bus): events are transient and often they are retried periodically or have another mean of synchronization.IMAGE
(per-agent image availability map): if lost, automatically reconstructed from agent heartbeatsMain load patterns
STAT
,LIVE
: proportional to the number of sessionsRLIM
: proportional to the volume of client API requestsIMAGE
: proportional to the number of cluster nodesSTREAM
: proportional to the number of cluster nodes & the number of sessionsCurrent Implementation
The configuration of Redis connection parameters are stored in etcd and shared across the entire cluster nodes including Manager, Agent, Storage Proxy, and App Proxy.
Currently, the Redis configuration can specify only one Redis instance (either a single
host:port
address or a list of sentinelhost:port
addresses).Proposed Addition
Let's extend the configuration format to additionally specify per-db instance addresses (either a single
host:port
address or a list of sentinelhost:port
addresses).We could just allow configuring optional, additional mappings from DB index to address settings (either single or sentinels), while non-specified ones falling back to the base address settings. This way, we could keep backward compatibility with existing setups.
An example split:
STAT
,LIVE
: persistence with AOF for HASTREAM
,IMAGE
: no persistence with HARLIM
: no persistence with HAThe text was updated successfully, but these errors were encountered: