Home > Storage > PowerScale (Isilon) > Product Documentation > Cloud > APEX File Storage for Microsoft Azure: Deployment Guide > Plan your deployment
When setting up a new cluster, it is important to consider the type of storage configuration that is supported. Different configurations fulfill different requirements, depending on the intended use and the amount of data that needs to be stored. In general, a supported cluster configuration should be reliable, performant, and offer enough storage capacity to meet your needs.
For a single cluster of APEX File Storage for Microsoft Azure, all nodes in the cluster must use the same configuration, including Azure VM size, Azure managed disk type, and Azure managed disk size.
Table 2 shows the supported configuration for a OneFS cluster in Azure.
Supported options | |
Cluster size | 4 to 18 nodes |
Azure VM size | All nodes in a cluster must use the same VM size. The supported VM sizes are:
|
Azure managed disk type | All nodes in a cluster must use the same disk type. The supported disk types are:
Note: Premium SSDs are only supported with Ddsv5-series and Edsv5-series. |
Azure managed disk size | All nodes in a cluster must use the same disk size. The supported disk sizes are:
|
Disk count per node | All nodes in a cluster must use the same disk count. The supported disk counts are:
|
Total raw capacity | Minimum: 10 TiB, maximum: 5760 TiB |
Default protection level | The default protection level is +2n. We also support +2d:1n with additional capacity restrictions. See the section OneFS protection level. |
Note: all criteria in this table must be met. Therefore, when using 16 TiB disk size, not all combinations of cluster size, disk count, and disk size are supported. For some combinations of cluster size, disk count, and disk size, the total cluster raw capacity may fall outside the maximum supported cluster raw capacity. For example, for an 18-node cluster, if each node contains 25 disks, and each disk size is P70 (16 TiB), the final total cluster raw capacity is 7200 TiB, which exceeds the maximum supported raw capacity. Therefore, this combination is not supported.
See Appendix A: supported cluster configuration details for all supported combinations.
OneFS file system journal, which stores information about changes to the file system, is designed to enable fast consistent recoveries after system failures or crashes. The file system replays the journal entries after a node or cluster recovers from an outage.
Each Azure VM node contains local SSD storage, which is also known as a temporary disk. OneFS leverages one of the local SSDs as the journal storage for protecting uncommitted writes to the file system. When a node boots up, it checks its journal and selectively replays transactions to disk when the logic in the journaling system requires it.
The 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, see 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 3 outlines the maximum cluster raw capacity limits for using 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 Prem SSD disks, the cluster raw capacity is 840 TiB. When you add more nodes into the cluster, the cluster raw capacity exceeds the limit of P50 using +2d:1n shown in Table 3. You must change to the default +2n protection level.
On deployment of a new cluster, the default protection scheme is set to +2n. All the files on the cluster inherit this level of protection. If the cluster only has a minimum number of nodes - 4, +2n protection means that the data on the cluster will remain protected even when two nodes of the cluster fail simultaneously. In a hyperscaler's environment, each of the OneFS virtual nodes within a cluster resides on different underlying physical hardware. Therefore, the chances of two nodes failing simultaneously are slim.
In the very unlikely event of two of the four nodes failing simultaneously, the cluster will only have two functional nodes and it loses quorum. Regardless of the cluster protection level, a cluster loses quorum when at least half the number of nodes in the cluster are unavailable. To protect the data, the cluster becomes un-responsive to client I/O. When at least one of the two failed nodes are back online in the cluster, the cluster will automatically become writeable. There will be data unavailability until at least one node is back online to bring back the quorum but there will not be data loss. If needed, some data will be re-built automatically. If there is a need for the cluster to remain available and writeable even if two nodes fail with +2n protection, increase the cluster size to five nodes.
Alternatively, deploying a new cluster that has only four nodes in it, one can change the protection level to +2d:1n, which will protect the data on the cluster against a one-node failure or a two-disk failure. If the protection scheme is set to +2d:1n, the cluster will remain writeable when one node in the cluster fails.
For comprehensive details about supported cluster configurations, see Appendix A: supported cluster configuration details. This includes information about various combinations of cluster node count, disk size, and disk count per node. The appendix also specifies whether the +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 4 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 also gets smaller as the cluster size grows. Therefore, if capacity is your primary requirement, opting for +2d:1n in a small cluster can yield a higher usable cluster capacity. Conversely, using +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. For the min and max usable capacity using different protection levels, see Appendix B: Cluster raw capacity and usable capacity.
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 the 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 greatly depend on the data and can vary considerably. This variance means that accurate rates of savings are not predictable without a 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.
APEX File Storage for Microsoft Azure is available in the following Azure regions:
After you have understood the supported cluster configurations and have analyzed your business requirements, you can start to plan your deployment details. Write down the configuration, including your OneFS cluster settings and Azure infrastructure information.
The following table contains an example. For this example, we will deploy a 4-node cluster with Azure Premier SSD disk type and D48ds_v5 instance type.
Configuration items | Example used in this guide | Note |
Cluster name | vonefs-azure |
|
Azure VM instance type | D48ds_v5 |
|
Data disk type | Premium SSD |
|
Cluster size (number of nodes) | 4 | If you are deploying a 4-node or 5-node cluster, and you need to expand the cluster size in the future, you must ensure that you are using a correct combination of disk count per node and single disk size, which allows you to expand to a maximum of 18 nodes. See Appendix A: supported cluster configuration details for all supported combinations. |
Data disk counts per node | 6 | |
Single disk size | 1TiB | |
Cluster raw capacity | 24TiB | Ensure that your cluster raw capacity is within the supported range. See Supported cluster configuration for the capacity limitation. |