This document describes concerns and limitations to be considered when allocating resources for your a9s Redis plans.
It is possible to configure an a9s Redis service instance with RDB persistency enabled, which means that the Redis data on memory is written to the persistent disk.
Saving the content to the persistent storage is the approach used when backing up an a9s Redis
service instance, and for this reason, your persistent disk size must be higher than your memory
size. Keep in mind that
a9s-parachute will stop the processes when persistent disk usage reaches
a9s Redis configures the maximum amount of memory Redis can use on a service instance, leaving a reserved amount for side processes (a9s Logstash, a9s Consul, a9s Backup Agent, and the OS).
maxmemory is configured as follows:
system_reserved_memory = min[10% of memory, 2GB]
total_reserverd_memory = system_reserved_memory + 256MB for the consul agent +
256MB for the a9s Backup Agent + 512MB for a9s Logstash
maxmemory = total_memory - total_reserverd_memory
maxmemory = max[150MB, maxmemory]
Reserved Disk Space
a9s Redis can be configured to use snapshots to persist data on the disk. If this is the case, then some disk space needs to be reserved.
Snapshots usually require an amount of disk space following the formula
(1.2 * used memory) * 2.
(1.2 * used memory) formula part is directly linked with the relation between the amount of memory
used by Redis and the snapshot file size produced after the snapshot operation. And, the
second formula part is related to the way the Redis produce the snapshot file, It will keep the existing
old snapshot file and create temporarily another file during the process. Therefore, it requires double
of disk space available.
E.g. a9s Redis instance uses
1GB of Memory, so the snapshot functionality would allocate around
2.4GB of disk space.
The sentinel port is currently exposed in the service binding. The Sentinel
port is currently hardcoded to 6357 + 20000. The templates in
template-uploader-errand do not set the port based on the SPI value.
Cluster Deployment Update Strategy
When updating a cluster service instance, BOSH will update one node per time and only proceeds with updating the next node when the node that has been updated is UP, running, and synchronized with the cluster.
If the cluster service instance is healthy, and it means all nodes are UP, running, and synchronized, the process will proceed smoothly.
If the cluster service instance is not healthy, the process will fail because the update
waits until the cluster is healthy. If it does not happen within the configurable timeout
cluster-update-node-timeout), the deployment will behave like it's set in the property
stop-cluster-update-on-failure (default value:
true), configures if the
instance update should be aborted when the replication during the update does not work
correctly. Setting this property to
false causes that the replication error will be
ignored and the deployment will continue. This will most probably cause data loss.
cluster-update-node-timeout (default value:
10), configures the maximal
amount of time (in minutes) that a single Redis VM in a cluster instance update can take.
The post-start script takes this value and if the runtime is bigger than the configured
amount, it will take the above-described property and either fails or continues
(based on the configuration).
The BOSH property
use_dns_addresses should always be DISABLED when using a9s Redis. When
use_dns_addresses is set to true, BOSH will use DNS hostnames instead of IP addresses in
the service configuration. As we know, Redis Sentinel 3, 4, and 5 do not support this kind
of configuration and although Redis Sentinel 6.2 supports this type of configuration, it
will require further changes in the a9s Redis BOSH release. One of the side effects of using
use_dns_addresses: true is the downtime when updating the a9s Redis deployment, but we are
afraid that there may be more to that, so we recommend to disable this property when using a9s Redis.
User Credentials Management
The user access control is implemented via Redis Access Control List (ACL) to provide a unique set of credentials
(username and password) for each service binding/key, for both
Because Redis does not replicate ACL rules, the creation or deletion of service bindings/keys must be executed against all nodes of the cluster. To ensure consistency in the cluster, it is only possible to create or delete a service binding/key if all nodes in the deployment are healthy.
Note that user access control is not available for a9s Redis 7 RC and below.
Plan Upgrade Restrictions
Upgrades from single to cluster plans via the CF CLI
update-service command are not possible for a9s Redis 6 and
We recommend preventing users from attempting to upgrade any single instance to a cluster instance. This can be achieved by limiting the migration paths in your manifest. Our example manifest already takes this into consideration.
For more information on migration paths see our Service Plans documentation.
As a solution, we encourage using our migration feature.