Resource Considerations
This document describes resource considerations and limitations to be taken into account when provisioning and operating a9s KeyValue Service Instances.
The resource requirements of a Service Instance depend on the Template selected for its Service Plan. Each Template defines the topology (number of nodes) and the set of colocated processes. Templates that provide logging require a higher-memory VM type and more ephemeral disk than Templates without logging.
The Platform Operator must define matching vm_type and persistent_disk_type entries in the BOSH Cloud Config and
reference them from the Service Plan configuration. For guidance on Service Plans and Templates, see Service Plans
and Available Templates.
For guidance on Service Plans and Templates, see Service Plans and Available Templates.
Template Requirements
The resource requirements of a Service Instance depend on the Template selected for its Service Plan. The small,
medium, and large labels used for VM type and persistent disk type in the tables below refer to the example Cloud
Config entries defined in Update the Cloud Config.
Templates that provide logging require a higher-memory VM type than Templates without logging.
Templates that provide logging reserve at least 512 MB of RAM for the logging process, in addition to the memory required by the data service process itself. Provisioning 512 MB of additional headroom above this minimum is recommended, to comfortably absorb the logging overhead.
The following table lists resource requirements per VM, as well as totals across all nodes of a Service Instance.
- Per VM
- Totals
| Template name | Nodes | vCPUs | Logging | SSL | Min. RAM | Min. Persistent Disk | Min. Ephemeral Disk | Example VM Type | Example Persistent Disk Type |
|---|---|---|---|---|---|---|---|---|---|
keyvalue8-single-ssl | 1 | 4 | Yes | Yes | ≥ 4.5 GB † | 10 GB if persistence is used | 5 GB | large | optional; medium |
keyvalue8-single-no-logging-ssl | 1 | 2 | No | Yes | ≥ 4 GB | 10 GB if persistence is used | 5 GB | small | optional; medium |
keyvalue8-replica-ssl | 3 | 4 | Yes | Yes | ≥ 4.5 GB † | 10 GB if persistence is used | 5 GB | large | optional; medium |
| † Includes the RAM reserved for the logging process. See the note above. | |||||||||
| Template name | Nodes | vCPUs | Logging | SSL | Min. RAM | Min. Persistent Disk | Min. Ephemeral Disk |
|---|---|---|---|---|---|---|---|
keyvalue8-single-ssl | 1 | 4 | Yes | Yes | ≥ 4.5 GB † | optional; up to 10 GB if persistence is used | 5 GB |
keyvalue8-single-no-logging-ssl | 1 | 2 | No | Yes | ≥ 4 GB | optional; up to 10 GB if persistence is used | 5 GB |
keyvalue8-replica-ssl | 3 | 12 | Yes | Yes | ≥ 13.5 GB † | optional; up to 30 GB if persistence is used | 15 GB |
| † Includes the RAM reserved for the logging process. See the note above. | |||||||
a9s KeyValue operates primarily in memory; persistent disk is not required by default. It is only needed when RDB
snapshots persistence is enabled via Service Plan configuration, in which case a medium disk type (10 GB) is
recommended as a minimum.
Persistence
RDB persistence may be enabled for a9s KeyValue Service Instances, which causes Valkey data in memory to be written to persistent disk. Saving content to persistent storage is also the approach used when backing up a Service Instance. The persistent disk size must therefore be larger than the memory size. a9s Parachute will stop all processes when persistent disk usage reaches 80% (default).
Reserved Memory
a9s KeyValue configures the maximum amount of memory Valkey may use on a Service Instance, reserving a portion for side
processes (a9s Logstash, a9s Consul, a9s Backup Agent, and the OS). maxmemory is calculated as follows:
system_reserved_memory = min[10% of memory, 2 GB]
total_reserved_memory = system_reserved_memory + 256 MB (consul) + 256 MB (backup agent) + 512 MB (logstash)
maxmemory = total_memory - total_reserved_memory
maxmemory = max[150 MB, maxmemory]
Reserved Disk Space
When snapshots are configured, the disk space required follows the formula (1.2 × used memory) × 2. The factor of 1.2
reflects the ratio between memory usage and the resulting snapshot file size. The factor of 2 is required because Valkey
retains the existing snapshot file while creating a new one during the snapshot process.
For example, a Service Instance using 4 GB of memory would require approximately 9.6 GB of disk space for snapshots.
Even for non-persistent Service Instances, a portion of disk space is reserved. A temporary snapshot is written to disk during backup operations, and Valkey also uses disk for replication operations.
Sentinel Port
The sentinel port is exposed in the service binding. The sentinel port is 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 a cluster Service Instance is updated, BOSH updates one node at a time and waits for each node to be operational and synchronized with the cluster before proceeding to the next.
If the cluster is healthy when the update begins, the process completes smoothly. If the cluster is not healthy, the
update waits for the cluster to recover. If recovery does not occur within the configurable timeout
(cluster-update-node-timeout), the deployment behavior is governed by the stop-cluster-update-on-failure property.
The property stop-cluster-update-on-failure (default: true) controls whether the instance update is aborted when
replication fails during the update. Setting this property to false causes replication errors to be ignored and the
deployment to continue. This will most probably cause data loss.
The property cluster-update-node-timeout (default: 10 minutes) configures the maximum time a single Valkey VM may
take during a cluster instance update.
Disable use_dns_addresses
The BOSH property use_dns_addresses must be disabled when using a9s KeyValue. When use_dns_addresses is set to
true, BOSH uses DNS hostnames instead of IP addresses in the service configuration, which causes downtime during
updates to the a9s KeyValue deployment.
User Credentials Management
User access control is implemented via the Valkey Access Control List (ACL), providing a unique set of credentials
(username and password) for each service binding and key, for both valkey and sentinel users.
Because Valkey does not replicate ACL rules, the creation or deletion of service bindings and keys must be executed against all nodes of the cluster. A service binding or key can only be created or deleted when all nodes in the deployment are healthy.
Plan Upgrade Restrictions
Upgrading a single-instance Service Instance to a cluster instance is not recommended and migration paths in the manifest should be configured to prevent this. The provided example manifest already enforces this restriction.
For more information on migration paths, see Service Plans. As an alternative, the migration feature is available.