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).