The protection level determines how strictly to distribute erasure-coded segments across hardware groupings. Valid values are
subcluster. The default value is
node protection, which suffices for most use cases.
Regardless of the protection level you set, Netmail Store always makes a best effort to distribute segments as broadly as possible across your hardware, to protect your data. The protection level lets you control how Netmail Store enforces the segment distribution policy on write, which it does by failing the write and returning an error response to the writing application if the policy is not met (
412 Precondition Failed).
'm' segments: Erasure coding breaks the object into data segments (
k) and computes parity segments (
p) based on the content of the data segments. This results in
m total segments (
k + p = m), distributed to
m different nodes (or subclusters) in the cluster.
Node-level protection (the default) makes Netmail Store write and validate that each node in the cluster has no more than one EC segment for a given object. If there are not enough nodes to accept the total number of segments (
k + p = m), the write fails. If a node with a segment fails and there are no longer
m nodes available, the cluster logs a warning but degrades gracefully to volume distribution, ensuring that each volume has only one segment.
Important: At node-level protection, there must be at least
m nodes for the write to succeed.
Subcluster distribution: When using node-level protection, Netmail Store tries to distribute segments across configured subclusters, but it does not fail a write if it cannot. When the health processor checks the validity of each erasure-coded object, it will try to redistribute across subclusters, if needed.
Subcluster-level protection is enabled if the
ec.protectionLevel parameter is set to
subcluster. This protection level determines the required segment distribution for a successful EC write. Use this protection level to protect your erasure-coded data from the loss of one or more subclusters.
Subcluster-level protection includes two protection levels, which you set with the
- More: Setting
-1(default) lets you survive the loss of
p(parity) subclusters without any data loss. It makes Netmail Store write and validate that each subcluster in the cluster has no more than one EC segment for a given object. If there are not enough subclusters to accept
msegments, the write fails. That is, 5:2 erasure coding needs 7 subclusters (7 chassis) to write the object; if one of those chassis fails for any reason, writes will fail. If a subcluster storing a segment fails and there are no longer
msubclusters available, the cluster logs a warning but degrades gracefully to node distribution, ensuring that each node has only one segment.
Tip: This configuration is most useful for multi-server chassis in which each chassis is a subcluster by default.
- Less: Setting
1lets you survive the loss of one subcluster without any data loss. It lets Netmail Store distribute up to
psegments per subcluster such that loss of one subcluster will still keep the object is still accessible, without requiring as many subclusters (
mor more). That is, 5:2 erasure coding needs 4 (not 7) subclusters, each with two segments.
With this setting, loss of a subcluster can let you read but not write EC objects. For instance with 9:6 erasure coding and 3 configured subclusters, each subcluster would get 6 or fewer segments. Losing any one of the three subclusters, Netmail Store could read an EC object via the segments remaining in the other 2 subclusters, but it could not write an EC object because of failing the precondition. That is, the cluster would have written 8 segments to one subcluster and 7 to the other, resulting in inadequate protection: loss of one of the remaining subclusters would make the object inaccessible.
After Netmail Store writes an object to the cluster, the health processor tries to maintain the requested protection level. If cluster resources become unavailable, it will degrade gracefully. When this occurs, the health processor logs errors, alerting you that the requested subcluster protection cannot be maintained and that your data may be at risk of subcluster loss.