Configure Storage Spaces

When setting up an System, a storage cluster represents a set of Foundation Nodes in the system. A storage space is a set of parameters within a storage cluster that defines how the system administers data and fault tolerance.

Creating a storage space is an important step for launching an Ocient System that must be done after installing hardware and bootstrapping nodes but before you start loading and querying data. To see how creating a storage space fits into the Ocient installation process, see Ocient Application Configuration.

This tutorial explains how to set up and configure storage spaces to meet the needs of your Ocient System.

For storage other than metadata, you must create one or more separate storage spaces. The creation of storage spaces is necessary before loading data or performing other operations. User-defined storage spaces are configurable for extra resiliency or storage based on your system needs.

A storage space represents how the storage cluster spreads data across Foundation Nodes to balance storage and fault tolerance. In general terms, the storage cluster configuration defines how the storage cluster behaves for these attributes:

You can configure a storage space to assign nodes to these job roles by using DDL statements (see CREATE STORAGESPACE).

Planning out your storage space carefully is important because you cannot change a storage space configuration after creation.

Storage space parameter: WIDTH

The Segment Group Width determines the number of segments that comprise a segment group. Functionally, this setting defines how many Foundation Nodes perform read and write operations for a segment group.

Within a Segment Group, the system assigns each segment to a different node. Hence, the Segment Group Width cannot exceed the number of nodes in your system.

In most circumstances, Segment Group Width should comprise most of your Foundation Nodes. On system startup, the default Segment Group Width is three, which is the minimum number of nodes required for an Ocient System.

Storage space parameter: PARITY_WIDTH

You can assign a subset of the Segment Group Width to Parity Width.

The Parity Width of a storage space determines its fault tolerance, defining the number of parity coding bits to use for each segment group. This number determines how many nodes can fail before the cluster is disabled.

Parity Width protects system querying capabilities. If any nodes fail, the system can execute and complete queries as long as the number of failed nodes is less than or equal to the Parity Width. When deployed in conjunction with overprovisioned nodes, Parity Width also provides fault tolerance for loading operations.

The PARITY WIDTH requires additional storage overhead, which is calculated by the formula (PARITY WIDTH) / (SEGMENT GROUP WIDTH - PARITY WIDTH).

The Ocient System overprovisions any Foundation Nodes in the cluster in excess of the Segment Group Width by default. These nodes can include any nodes not configured in the storage space or any nodes added later.

Overprovisioned nodes protect loading operations from node failure, although they must be used in conjunction with Parity Width. In the event of node failures, loading operations can continue as long as the number of failed nodes does not exceed the Parity Width nodes or the number of overprovisioned nodes. For this reason, providing fault tolerance for loading requires a balance of Parity Width and overprovisioned nodes.

Unlike Segment Group Width and Parity Width, you do not explicitly define a value for overprovisioning. Instead, any Foundation Nodes in the cluster in excess of the number allocated toward Segment Group Width or Parity Width become overprovisioned by default.

This section demonstrates different configurations for storage spaces. The examples each go through different scenarios for node failures to show the fault tolerance of each setup.

For information on the syntax for storage spaces, see CREATE STORAGESPACE.

This example assumes you have a storage cluster of 10 Foundation Nodes.

Tolerance Scenarios

This storage space setup has no overprovisioning, making loading operations less resilient. This setup results in these outcomes if nodes become disabled:

This example assumes a storage cluster of 12 Foundation Nodes.

Note that this DDL statement is the same as the 10-Node Cluster Example, but the cluster in this example has two additional nodes.

Tolerance Scenarios

This setup provides a level of resiliency for both querying and loading. The setup results in these outcomes if nodes become disabled:

This example assumes a storage cluster of 12 Foundation Nodes with more nodes allocated to parity.

Tolerance Scenarios

This setup provides resiliency for loading and especially for querying. The setup results in these outcomes if nodes become disabled:

This example assumes a cluster of 15 Foundation Nodes. The configuration in this setup includes five overprovisioned nodes, exceeding the Parity Width nodes. This number of overprovisioned nodes would be inefficient and unable to provide the full benefit in a real system, but this example demonstrates what happens if you added extra nodes at a later time to a cluster, which the storage space would recognize as overprovisioned.

Tolerance Scenarios

This setup provides resiliency for both querying and loading, but having more than three overprovisioned nodes provides no benefit because it exceeds three Parity Width nodes.

This setup results in these outcomes if nodes become disabled:

Core Elements of an Ocient System

Cluster and Node Management