Configure Quiver

Quiver is a critical component of GoodData.CN. It provides caching and durable storage for analytical workloads, enabling high-performance queries and reliable raw exports. Correct configuration of Quiver ensures that deployments are stable, performant, and integrated with the required cloud storage backends.

This guide explains how to configure Quiver in GoodData.CN, with emphasis on supported storage backends (AWS S3 and Azure Blob Storage), authentication, prefixes, and integration with the exportController.

Before configuring Quiver, ensure you have:

• etcd set up (for clustered deployments).
• Durable storage (S3 bucket or Azure Blob container) provisioned.
• Identity access configured (IAM, IRSA, or Managed Identity in AKS).

Quick Start Example

A minimal configuration with S3 durable storage:

modules = ["quiver_shard", "quiver_policy"]

[storages.s3_raw]
type = "s3"
bucket = "my-quiver-bucket"
prefix = "raw/"
region = "us-east-1"
auth_type = "aws_default"

[storclasses.raw]
prefix = "/raw/exports/"
durability = "strong"
upload_to_tier = "memory"
tiers.memory = { type = "memory", max_size = "1G" }
tiers.disk = { type = "disk", max_size = "50G", spill_to = "memory" }

This configuration loads the shard and policy modules, connects to an S3 bucket, and sets up a strongly durable storage class for raw exports.

The following sections explain the configuration in more detail.

Quiver Components

Quiver is modular and runs inside one or more Quiver nodes. Each node can load modules:

• Shard module – quiver_shard: stores cache replicas and manages data placement between memory, disk, and durable storage.
• Cache policy module – quiver_policy: enforces storage class policies (e.g., TTL, flight count limits).
• Dataframe module – quiver_dataframe: enables dataframe operations on cached data.

Nodes coordinate through etcd in clustered setups. Each node exposes gRPC Flight RPC endpoints and readiness/liveness checks for Kubernetes probes.

Storage Configuration

Quiver organizes data into storage classes, defined by path prefixes. Storage classes determine:

• Which durable storage is used (S3 or Azure Blob).
• Which cache tiers are used (memory, disk, disk_mapped).
• Durability guarantees.

Choose from the two durability options:

Prefixes

Prefixes are required. Each storage class matches flight path prefixes (for example, /raw/exports/).
If you forget to define a prefix, Quiver will reject writes because it cannot match data to any storage class.

Prefixes allow multiple datasets to share the same bucket or container, while still being logically isolated. They are also used by policy modules for reporting and by administrators for fine-grained management.

Supported Durable Storage Backends

Quiver supports both AWS S3 and Azure Blob Storage (ABS).

AWS S3

You can authenticate in two ways:

• Static credentials

  [storages.s3_raw]
  type = "s3"
  bucket = "my-quiver-bucket"
  prefix = "raw/"
  region = "us-east-1"
  auth_type = "aws_tokens"

  Environment variables (preferred over files):

  export AWS_ACCESS_KEY_ID=...
  export AWS_SECRET_ACCESS_KEY=...

• IAM Roles for Service Accounts (IRSA)

  For EKS and IRSA integration:

  [storages.s3_raw]
  type = "s3"
  bucket = "my-quiver-bucket"
  prefix = "raw/"
  region = "us-east-1"
  auth_type = "aws_default"

  With aws_default, credentials are automatically resolved from the pod’s service account.

Azure Blob Storage

Two auth types are supported:

• azure_default – uses environment defaults, suitable for Managed Identity in AKS.
• azure_storage_tokens – static tokens via secrets.

Example:

[storages.abs_raw]
type = "abs"
container = "my-quiver-container"
prefix = "raw/"
auth_type = "azure_storage_tokens"

Secrets Management

Quiver does not store secrets directly. Instead, it uses providers:

• Env provider – reads credentials from environment variables.
• Vault provider – retrieves credentials dynamically from HashiCorp Vault.
• Default provider – loads from configuration files or environment variables.

Best practice:

• Use Vault or IRSA/Managed Identity for production.
• Use static tokens only for development or testing.

Export Controller

The exportController depends on Quiver for raw exports. A dedicated durable storage must be configured for this purpose:

• Create a storage class (e.g., /raw/exports/) pointing to S3 or Blob.
• Ensure this class has strong durability to guarantee export persistence.
• Configure the export controller to write to the same bucket/container.

The export controller does not create buckets/containers, they must exist already. The prefix must match what export controller uses. A mismatch may result in “export succeeded” but Quiver will not find it where you expect.

Node Settings

• Modules: at minimum, include quiver_shard. For policy enforcement, add quiver_policy.
• Flight RPC security: set flight_secret_token if endpoints are accessible from outside.
• Health checks: expose /live and /ready (default port 8877) for Kubernetes probes.
• Memory tuning: set GLIBC_TUNABLES="glibc.malloc.trim_threshold=131072:glibc.malloc.arena_max=2" to avoid memory bloat in Kubernetes.