Glossary

access keys

A Buckit deployment or tenant user account with limited account typically used with API calls. Access Keys were previously referred to as “Service Accounts”

active-active

A method of replication that provides bidirectional mirroring of data. With active-active configuration, changing the data at at any storage location also changes the data at the other storage location(s).

See also: active-passive.

active-passive

A method of replication that provides one-way mirroring of data. With the active-passive configuration, changing data at the originating location also changes the data at the destination. However, changing data at the destination does not affect the data on the origin.

See also: active-active.

alias

A locally defined reference to a Buckit Deployment used in most command line interface operations. See bm alias set.

audit logs

Granular descriptions of each operation on a Buckit deployment. Audit logs support security standards and regulations which require detailed tracking of operations.

See also: server logs.

bit rot

Data corruption that occurs without the user’s knowledge.

Buckit combats bit rot with hashing and erasure coding.

bit rot healing

Objects corrupted due to bit rot are automatically healed during any GET or HEAD operation. Buckit captures and heals corrupted objects on the fly with its hashing implementation.

bucket

buckets

A grouping of objects and associated configurations.

cluster

A group of drives and one or more buckit server processes pooled into a single storage resource.

See also: tenant.

cluster registration

Cluster registration links a Buckit deployment to a license and account context used by Buckit management tooling. An organization may have more than one Buckit cluster registered to the same account.

Console

Buckit Console

Graphical User Interface (GUI) for interacting with a Buckit deployment or tenant.

data

One of the two types of blocks Buckit writes when doing erasure coding. Data blocks contain the contents of a file.

Parity blocks support data reconstruction should data blocks become corrupt or go missing.

decommission

Process of removing a pool of drives from a distributed deployment. When initiated, the objects on the decommission pool drain by moving to other pools on the deployment.

The process is not reversible.

deployment

A specific instance of Buckit containing a set of buckets and objects.

disk encryption

The conversion of all of the contents written to a disk to values that cannot be easily deciphered by an unauthorized entity. Disk encryption can be used in conjunction with other encryption technologies to create a robust data security system.

enclave

A description of an isolated area within a stateful Key Encryption Service (KES) server. A KES server may have one enclave or multiple enclaves. Each enclave within a KES server holds separate keys, policies, and administration identity. An enclave cannot see or make use of any other enclave on the server.

For example, you might use multiple enclaves to hold completely separate key stores for multiple Buckit tenants within a single stateful KES server.

encryption at rest

A method of encryption that stores an object in an encrypted state. The object remains encrypted while not moving from one location to another.

Objects can be encrypted by the the server using one of key management methods: SSE-KMS, SSE-S3, or SSE-C.

encryption in transit

A method of encryption that protects an object when moving it from one location to another, such as during a GET request. The object may or may not be encrypted on the origin or destination storage devices.

erasure coding

A technology that splits objects into multiple shards and writes the shards to multiple, separate drives.

Depending on the topology used, erasure coding allows for loss of drives or nodes within a Buckit deployment without losing read or write access.

erasure set

A group of drives within Buckit that support erasure coding. Buckit divides the number of drives in a deployment’s server pool into groups of 4 to 16 drives that make up each erasure set. When writing objects, data and parity blocks write randomly to the drives in the erasure set.

hashing

The use of an algorithm to create a unique, fixed-length string (a value) to identify a piece of data.

healing

Restoration of data from partial loss due to bit rot, drive failure, or site failure.

health diagnostics

A suite of Buckit API endpoints available to check whether a server is

• online

• available for writing data

• available for reading data

• available for maintenance without affecting the cluster’s read and write operations

host bus adapter

HBA

A circuit board or integrated circuit adapter that connects a host system to a storage device. The HBA handles processing to reduce load on the host system’s processor.

IAM integration

Buckit only allows access to data for authenticated users. Buckit provides a built-in identity management solution to create authorized credentials. Optionally, Buckit users can authenticate with credentials from a 3rd party identify provider (IDP), including either OpenID or LDAP providers.

JBOD

Initialism for “Just A Bunch of Drives”. JBOD is a storage device enclosure that holds many hard drives. These drives can combine into one logical drive unit.

See also: RAID

lifecycle management

ILM

Rules to determine when objects should move or expire.

locking

A rule that prevents removal or deletion of an object until an authorized agent removes the rule or it expires.

monitoring

The act of reviewing the status, activity, and availability of a Buckit cluster, deployment, tenant, or server. Buckit provides the following tools:

• Prometheus compatible metrics and alerts

• Audit logs

• server logs

• Healthcheck API endpoints

• Bucket notifications

multi-node multi-drive

MNMD

distributed

A system topology that uses more than one server and more than one drive per server to host a Buckit instance. Buckit recommends Kubernetes for distributed deployments.

multipart upload

Multipart upload is a client-initiated S3 function that splits a single object into multiple parts for moving from one location to another. The client uploads each part independently to Buckit, and Buckit manages reconstructing those received parts into the original object.

Multipart uploads provide benefits such as improved throughput and resiliency to network errors. Use multipart uploads for objects greater than 100MB in actual or estimated size for best results.

See Amazon AWS documentation for more details.

network encryption

A method of securing data during transit from one location to another, such as server-server or client-server. Buckit supports Transport Layer Security (TLS), version 1.2 and later, for both incoming and outgoing traffic.

object

objects

An item of data Buckit interacts with using an S3-compatible API. Objects can be grouped into buckets.

Operator

Operator Console

The Graphical User Interface (GUI) to deploy and manage the Buckit tenants in a distributed deployment environment.

parity

The portion of blocks written for an object by Buckit to support data reconstruction due to missing or corrupt data blocks. The number of parity blocks indicates the number of drives in the erasure set that a deployment can lose while still retaining read and write operations.

prefix

Prefixes organize the objects in a bucket by assigning the same string of characters to objects that should share a similar hierarchy or structure. Use a delimiter character, typically a / to add layers to the hierarchy. While prefixed objects may resemble a directory structure in some file systems, prefixes are not directories.

Buckit itself does not limit the number of objects that any specific prefix can contain. However, hardware and network conditions may show performance impacts with large prefixes.

• Deployments with modest or budget-focused hardware should architect their workloads to target 10,000 objects per prefix as a baseline. Increase this target based on benchmarking and monitoring of real world workloads up to what the hardware can meaningfully handle.

• Deployments with high-performance or enterprise-grade hardware can typically handle prefixes with millions of objects or more.

RAID

Initialism for “Redundant Array of Independent Disks”. The technology merges multiple separate physical disks into a single storage unit or array. Some RAID levels provide data redundancy or fault tolerance by duplicating data, striping data, or mirroring data across physical disks.

See also: JBOD.

read quorum

The minimum number of object shards necessary to reconstruct the full object for read operations. See Erasure Coding Basics for more information.

replication

mirror

The replication of a bucket or entire site to another location.

scanner

Buckit Scanner

One of several low-priority processes Buckit runs to check:

• lifecycle management rules requiring object transition

• bucket or site replication status

• object bit rot and healing

• usage data

For more, see Object Scanner.

self signed certificates

A self-signed certificate is one created by, issued by, and signed by the company or developer responsible for the content the certificate secures. Self-signed certificates are not issued by or signed by a publicly trusted, third-party Certificate Authority (CA). These types of certificates do not expire or require periodic review, and they cannot be revoked.

server logs

Records the buckit server operations logged to the system console. Server logs support general monitoring and troubleshooting of operations.

For more detailed logging information, see audit logs.

server pool

pool

A set of buckit server nodes which combine their drives and resources to support object storage and retrieval requests.

For more information, see How does Buckit manage multiple virtual or physical servers?.

service account

Renamed to access keys. A Buckit deployment or tenant user account with limited account typically used with API calls.

shard

shards

A portion of an object after being erasure coded by Buckit. Each “shard” represents either data or parity for Buckit to use for reconstructing objects on read requests.

Exclusive access to drives

Buckit requires exclusive access to the drives or volumes provided for object storage. No other processes, software, scripts, or persons should perform any actions directly on the drives or volumes provided to Buckit or the objects or files Buckit places on them.

Do not use scripts or tools to directly modify, delete, or move any of the data shards, parity shards, or metadata files on the provided drives, including from one drive or node to another. Such operations are very likely to result in widespread corruption and data loss beyond Buckit’s ability to heal.

For more detailed information, see Erasure Coding.

single-node multi-drive

SNMD

A system topology that deploys Buckit on one compute resource with more than one attached volume.

single-node single-drive

SNSD

filesystem

A system topology that deploys Buckit on a single compute resource with a single drive. This adds S3-type functionality to an otherwise standard filesystem.

SSE-C

A method of encryption at rest that encrypts an object at the time of writing with an encryption key included with the write request. To retrieve the object, you must provide the same encryption key provided when originally writing the object. Additionally, you must self-manage the encryption key(s) used.

See also: SSE-KMS, SSE-S3, encryption at rest, network encryption.

SSE-KMS

A method of encryption at rest that encrypts each object at the time of writing with separate keys managed by a service provider. Use keys at either the bucket level (default) or at the object level. Buckit recommends the SSE-KMS method for key management of encryption.

See also: SSE-S3, SSE-C, encryption at rest, network encryption.

SSE-S3

A method of encryption at rest that encrypts each object at the time of writing with a single key for all objects on a deployment. A deployment uses a single external key to decrypt any object throughout the deployment.

See also: SSE-KMS, SSE-C, encryption at rest, network encryption.

standalone deployment

A single-node single-drive (SNSD) Buckit deployment. This term previously referred to the deprecated Gateway or Filesystem Mode deployment types.

tenant

tenants

In a distributed mode, a specific Buckit deployment. One instance of the Buckit Operator may have multiple tenants.

topology

The hardware configuration used for a deployment. Buckit works with three topologies:

• multi-node multi-drive

• single-node multi-drive

• single-node single-drive

versioning

The retention of multiple iterations of an object as it changes over time.

webhook

A webhook is a method for altering the behavior of a web page or web application with a custom callback. The format is typically JSON sent as an HTTP POST request.

WORM

Write Once Read Many (WORM) is a data retention methodology that functions as part of object locking. Many requests can retrieve can view a WORM-locked object (read many), but no write requests can change the object (write once).

write quorum

The minimum number of object shards Buckit must successfully write to an erasure set for write operations. See Erasure Coding Basics for more information