Skip to main content
Version: 67.0.0

a9s Parachute v2

a9s Parachute v2 uses Data Service specific actions to stop data ingestion as a measure to avoid exposing the a9s Data Services to a full disk.

a9s Parachute v2 uses monit to watch the ephemeral and persistent disk usage of an a9s Data Service instance. When the disk usage threshold hits a configured limit, it executes a lock script to lock the a9s Data Service Instance. During pre-start of the a9s Parachute v2 process, an unlock script is executed to revert the actions that have been taken to prevent further data ingestion.

a9s Parachute v2

The following a9s Data Services are using a9s Parachute v2:

  • a9s KeyValue 8
  • a9s LogMe2
  • a9s MariaDB
  • a9s Messaging 4
  • a9s MongoDB 7.0
  • a9s PostgreSQL 15
  • a9s PostgreSQL 17
  • a9s Search

Configuration

The a9s Parachute v2 can be configured via the following BOSH properties:

PropertyDefault ValueDescription
pluginsA list of plugins that can be used by a9s Parachute. For each plugin the following settings must be set: name, plugins_path, username, password
ephemeral.usage_limit80Limit in percent for the ephemeral disk usage. 0 deactivates the check.
ephemeral.fault_tolerance.times5The number of test failures for the ephemeral disk before an error event is triggered.
ephemeral.fault_tolerance.cycles10The amount of cycles in which test failures are counted for the ephemeral disk.
persistent.usage_limit80Limit in percent for the persistent disk usage. 0 deactivates the check.
persistent.fault_tolerance.times5The number of test failures for the persistent disk before an error event is triggered.
persistent.fault_tolerance.cycles10The amount of cycles in which test failures are counted for the ephemeral disk.

Observability

There are multiple option to monitor a9s Parachute. Below, you can find a list of the different options:

Unlock a Service Instance Manually

To manually unlock a Service Instance, the following steps are necessary:

  1. SSH into one node of the affected Service Instance via bosh -d <deployment_name> ssh <instance_name>/<index>
  2. Become root via sudo -i
  3. Remove the a9s Parachute lock file via rm -f /var/vcap/sys/run/a9s-parachute/a9s-parachute-activated
  4. Unlock the Service Instance via /var/vcap/jobs/a9s-parachute/bin/unlock
caution

Keep in mind that the a9s Parachute doesn't clear up disk space, so you have to free up the affected disk manually.

a9s Data Service Specifics

a9s Parachute stops selected Monit processes to prevent further data ingestion, while keeping certain processes alive to ensure the VM remains accessible. The table below lists which processes are stopped and which remain running when a9s Parachute 2 is active.

Data ServiceMonit Processes StoppedMonit Processes Kept Alive
a9s KeyValuevalkey, backup-agentconsul, nginx, logstash, a9s-bee
a9s LogMe2opensearch, backup-agentconsul, nginx, logstash, a9s-bee
a9s Messagingrabbitmq, backup-agentconsul, nginx, logstash, a9s-bee
a9s MongoDBmongodb, backup-agentconsul, nginx, logstash, a9s-bee
a9s PostgreSQLpostgresql-ha, postgresql-info-webservice, backup-agentconsul, nginx, logstash, a9s-bee
a9s Searchopensearch, backup-agentconsul, nginx, logstash, a9s-bee

Depending on the Data Service, other service-specific actions may be applied. Below, you can find a brief overview of these actions.

a9s MariaDB

When the disk usage threshold hits a configured limit, a lock script is executed and sets the whole database server to read-only mode. This is done via the command SET GLOBAL read_only = ON;. Additionally, a9s Parachute creates its lock file /var/vcap/sys/run/a9s-parachute/a9s-parachute-activated to indicate that a9s Parachute was activated.

When the a9s Parachute process starts, the lock file is deleted and the read-only mode of the database server is reverted via the command SET GLOBAL read_only = OFF;.

Resource Considerations

For more information, see a9s Parachute Resource Considerations.