Skip to main content
Version: Latest

1. Prerequisites

New to the a9s Data Services Framework?

Before proceeding, it is recommended to read the Introduction page. It covers key concepts such as Service Instances, Service Plans, Service Bindings, and Templates that are referenced throughout this guide.

This document describes the prerequisites of an anynines-deployment installation.

Repository Access​

Access to the anynines-deployment repository is required. This repository contains all BOSH deployment manifests, Ops files, and configuration templates necessary for installing the a9s Data Services Framework.

BOSH Director​

The a9s Data Services Framework runs on Virtual Machines (VMs) provisioned by BOSH. Therefore, this guide assumes that a BOSH Director is available and running, configured with a BOSH 2.0 Cloud Config and a latest version of the BOSH CLI.

info

The Cloud Config defines what deployment-level primitives such as vm_type, disk_type and networks actually mean in terms of IaaS resources (CPU, RAM, disk size). For more information, please refer to the next step in the installation guide.

In addition, the following BOSH Director properties must be configured accordingly.

enable_post_deploy: true​

In a standard setup the BOSH Director does not run post deploy scripts by default. The director.enable_post_deploy property must be used to enable running post deploy scripts. For more information, see the BOSH post-deploy documentation.

use_dns_addresses: false​

The a9s Data Services Framework requires the BOSH Director property use_dns_addresses to be set to false. This property controls whether BOSH uses DNS names or IP addresses for inter-VM communication within deployments.

When use_dns_addresses is enabled (set to true), it may cause operational issues across the framework, including:

  • Update downtime during stemcell upgrades and configuration changes
  • Incompatibility with Consul-based service discovery and failover mechanisms
  • Disruption to Service Instance availability during routine maintenance operations

For service-specific examples of these issues, see the a9s KeyValue Concerns documentation.

BOSH DNS​

BOSH-DNS is widely used in deployments concerning a9s Data Services Framework and Cloud Foundry. It is recommended that some knowledge of BOSH's native DNS capabilities is acquired before proceeding with the installation.

Network Requirements​

The framework requires at least one network to be defined in the BOSH Cloud Config. Within the network definition, both a static IP range and a dynamic IP range may be specified.

The consul-dns deployment must be assigned static IPs. Consul DNS operates as the service discovery layer for all managed instances and must be reachable at stable, predictable addresses. Static IPs are assigned to a deployment by specifying them in the network's static range in the Cloud Config and referencing them in deployment manifest through the IaaS Configuration.

All other framework deployments and Service Instances may use dynamically assigned IPs from the network's available range.

If different network names are used, the names must be updated in the deployment manifests and in the Service Plan configuration accordingly. For diagrams and further detail, see Networks.

Minimum System Requirements​

Framework Deployment Footprint​

The total footprint depends on which data services are deployed. Not all data services need to be deployed; the framework requires at least one. The three framework deployments (a9s-pg, backup-service, and consul-dns) are always required regardless of which data services are selected. Optional components are marked with an asterisk (*).

The table below lists the minimum resource requirements per deployment, excluding Service Instances. This can be used as a starting point to estimate the baseline footprint for a specific combination of data services. For a visual overview of the framework's deployment topology, see Deployment architecture.

All resource columns below (vCPUs, RAM, Persistent Disk, Ephemeral Disk) are totals summed across every VM in the deployment; VMs is simply the VM count itself. See the footnote below each table for details on how these totals are computed and why per-VM distribution may be uneven.

warning

These are minimum requirements and may not reflect actual workload requirements.

DeploymentVMsIPsvCPUs (Total)RAM [GB]Persistent Disk [GB]Ephemeral Disk [GB]Root Disk [GB]
a9s-pg336143015IaaS default
backup-service112245IaaS default
consul-dns5510203225IaaS default
Total9918366645
All resource values (vCPUs, RAM, Persistent Disk, Ephemeral Disk) are totals summed across every VM in the deployment, computed approximately as VM count × the per-VM minimum. Deployments may include VMs with different roles and sizes, so actual per-VM distribution may be uneven, e.g., a RAM total of 5 GB across 4 VMs could be distributed as 2 GB, 1 GB, 1 GB, and 1 GB rather than split evenly.
Compilation VMs

BOSH provisions compilation VMs whenever a deployment compiles BOSH releases; this occurs on first deploy and on any update that introduces new or changed packages. Compilation VMs are transient and are not present during normal operation; the footprint table above therefore does not include them.

A minimum of 2 GB of RAM per compilation VM is required; 4 GB is recommended, as all packages from the deployed BOSH releases are compiled on these VMs. The ephemeral disk requirements are equivalent to those of a standard deployment VM of the same type.

Service Instance Footprint​

The resource footprint of a Service Instance is determined by three layers working together:

  1. Cloud Config: Defines specific vm_type and disk_type names that correspond to actual IaaS resources.
  2. Template: A BOSH deployment manifest that describes the topology of a Service Instance (number of nodes and colocated processes). Templates are provided by the a9s Template Uploader Errand. The available templates per service are listed in Available Templates.
  3. Service Plan: Glues a Template to specific vm_type and persistent_disk_type names. These names must match entries defined in the BOSH Cloud Config. Service Plan configuration is described in Service Plans.

The resource footprint of any Service Instance is ultimately determined by the Platform Operator through the Service Plan configuration, and the Cloud Config entries those plans reference. In the next step of the installation guide, the handling of such configurations by the Platform Operator is described.

Per-service minimum requirements, broken down by Template, are available through Available Templates, for each Data Service.

Further Requirements​

Before proceeding with the installation, the Resource Considerations page should be reviewed. It describes cross-cutting memory and disk constraints that apply to all a9s Data Services, including sidecar process overhead and disk exhaustion behavior.

Cloud Foundry Integration​

The a9s Data Services Framework is platform-agnostic in principle and can operate with any platform that supports BOSH. However, the default configuration assumes a Cloud Foundry installation, which facilitates (among other things) the following core capabilities:

  • Service catalog registration: each Data Service's Service Broker registers its service catalog with Cloud Foundry, making services available in the CF Marketplace.
  • Authentication: the a9s Service Dashboard and a9s Public API use an SSO Proxy component that integrates with UAA as its OAuth2 provider. UAA is a Cloud Foundry component.

CredHub Integration​

This guide assumes that the BOSH Director is already integrated with CredHub. All framework components retrieve credentials from CredHub during deployment via the ((variable-name)) interpolation syntax in BOSH manifests.

In addition, the CredHub CLI must be authenticated against the CredHub instance colocated with the BOSH Director, in order to create and manage credentials for the framework deployments. More information is available in the official BOSH CredHub documentation.