Home > Storage > PowerScale (Isilon) > Product Documentation > Cloud > Introduction to APEX File Storage for Azure > OneFS protection level
A OneFS cluster is designed to withstand one or more simultaneous component failures while continuing to serve data. To achieve this, OneFS protects files with either erasure code-based protection, using Reed-Solomon error correction (N+M protection), or a mirroring system. Data protection is applied in software at the file level, enabling the system to focus on recovering only those files that are compromised by a failure, rather than having to check and repair an entire file set or volume. OneFS metadata and inodes are always protected by mirroring, rather than Reed-Solomon coding, and with at least the level of protection as the data they reference. For more technical details about OneFS protection levels, refer to OneFS Data Protection.
APEX File Storage for Microsoft Azure is set with a default protection level of +2n, capable of tolerating the failure of up to two drives or two nodes. We have chosen this +2n protection level for APEX File Storage for Microsoft Azure to ensure robust availability and reliability in the cloud environment. While the default setting prioritizes resilience, users have the option to adjust the protection level to +2d:1n for improved storage efficiency. However, it is essential to note that this configuration comes with certain capacity restrictions. The +2d:1n option can tolerate the failure of either two drives or one node.
For clarity on how different protection levels affect storage capacity, Table 2 outlines the maximum cluster raw capacity limits for utilizing the +2d:1n protection level with various Azure managed disk sizes. If these capacity limits are exceeded, users must revert to the default +2n protection level when expanding the cluster to accommodate additional capacity needs. For example, if you have a 14-node cluster with +2d:1n protection level and each node has 15 disks using P50 Azure managed disks, the cluster raw capacity is 840 TiB. If you add more P50 nodes into the cluster, the cluster raw capacity will exceed the limit that +2d:1n allows, as described in Table 2. Therefore, you must change the protection from +2d:1n to +2n.
Refer to Appendix A: supported cluster configuration details for comprehensive details on supported cluster configurations. It includes information about various combinations of cluster node count, disk size, and disk count per node. Additionally, the appendix specifies whether +2d:1n protection level is supported with specific configurations.
Azure managed disk type | Disk size (TiB) | Min cluster raw capacity (TiB) using +2n or +2d:1n | Max cluster raw capacity (TiB) using +2n | |
P20 | 0.5 | 10 | 270 | 270 |
P30 | 1 | 20 | 540 | 540 |
P40 | 2 | 40 | 840 | 1080 |
P50 | 4 | 80 | 840 | 2160 |
P60 | 8 | 160 | 1440 | 4320 |
P70 | 16 | 320 | 1440 | 5760 |
E20 | 0.5 | 10 | 240 | 270 |
E30 | 1 | 20 | 240 | 540 |
E40 | 2 | 40 | 240 | 1080 |
E50 | 4 | 80 | 240 | 2160 |
E60 | 8 | 160 | 800 | 4320 |
E70 | 16 | 320 | 1600 | 5760 |
S40 | 2 | 40 | 280 | 1080 |
S50 | 4 | 80 | 280 | 2160 |
S60 | 8 | 160 | 800 | 4320 |
S70 | 16 | 320 | 1120 | 5760 |
The protection overhead varies with cluster size. Table 3 shows the protection overhead of APEX File Storage for Microsoft Azure with different cluster sizes. File system efficiency increases as the cluster size grows, meanwhile the storage efficiency gap between +2n and +2d:1n is also smaller as cluster size grow. Therefore, if capacity is your primary requirement, opting for +2d:1n in a small cluster can yield a higher usable cluster capacity. Conversely, utilizing +2n in a large cluster ensures storage efficiency while maintaining superior resilience. Usable cluster capacity refers to the amount of storage capacity available for storing data after accounting for protection overhead. Reference Appendix B: Cluster raw capacity and usable capacity for the min and max usable capacity using different protection levels.
Cluster size | Requested protection level +2n | Requested protection level +2d:1n | ||
Data blocks + protection blocks | Protection overhead | Data blocks + protection blocks | Protection overhead | |
4 nodes | 2+2 | 50% | 6+2 | 25% |
5 nodes | 3+2 | 40% | 8+2 | 20% |
6 nodes | 4+2 | 33% | 10+2 | 17% |
7 nodes | 5+2 | 29% | 12+2 | 14% |
8 nodes | 6+2 | 25% | 14+2 | 13% |
9 nodes | 7+2 | 22% | 16+2 | 11% |
10 nodes | 8+2 | 20% | 16+2 | 11% |
11 nodes | 9+2 | 18% | 16+2 | 11% |
12 nodes | 10+2 | 17% | 16+2 | 11% |
13 nodes | 11+2 | 15% | 16+2 | 11% |
14 nodes | 12+2 | 14% | 16+2 | 11% |
15 nodes | 13+2 | 13% | 16+2 | 11% |
16 nodes | 14+2 | 13% | 16+2 | 11% |
17 nodes | 15+2 | 12% | 16+2 | 11% |
18 nodes | 16+2 | 11% | 16+2 | 11% |
Note: The final effective capacity of a OneFS cluster depends on the characteristics of the data and on file system features in use. For example, OneFS provides inline data reduction and small file efficiency features to help save storage capacity. Data capacity savings due to inline data reduction and small file efficiency are highly dependent on the data and can vary considerably. This variance means that accurate rates of savings are not predictable without comprehensive analysis of the dataset. The preceding usable cluster capacity estimation is for guidance only when implementing APEX File Storage for Microsoft Azure. For more details about storage efficiency, see the white paper Dell PowerScale OneFS: Data Reduction and Storage Efficiency.