Expand or shrink the cluster
Add or remove building blocks from the cluster.
This section documents various considerations and options to adjust the size of your BeeGFS HA cluster. Typically cluster size is adjusted by adding or removing building blocks, which are typically two file nodes setup as an HA pair. It is also possible to add or remove individual file nodes (or other types of cluster nodes) if needed.
Adding a Building Block to the Cluster
Growing the cluster by adding additional building blocks is a straightforward process. Before you begin keep in mind restrictions around the minimum and maximum number of cluster nodes in each individual HA cluster, and determine if you should add nodes to the existing HA cluster, or create a new HA cluster. Typically each building block consists of two file nodes, but three nodes is the minimum number of nodes per cluster (to establish quorum), and ten is the recommended (tested) maximum. For advanced scenarios it is possible to add a single "tiebreaker" node that does not run any BeeGFS services when deploying a two node cluster. Please contact NetApp support if you are considering such a deployment.
Keep in mind these restrictions and any anticipated future cluster growth when deciding how to expand the cluster. For example if you have a six node cluster and need to add four more nodes, it would be recommended to just start a new HA cluster.
|Remember, a single BeeGFS file system can consist of multiple independent HA clusters. This allows file systems to continue scaling far past the recommended/hard limits of the underlying HA cluster components.
When adding a building block to your cluster, you will need to create the
host_vars files for each of the new file nodes and block nodes (E-Series arrays). The names of these hosts need to be added to the inventory, along with the new resources that are to be created. The corresponding
group_vars files will need to be created for each new resource. See the Use custom architectures section for details.
After creating the correct files, all that is needed is to rerun the automation using the command:
ansible-playbook -i <inventory>.yml <playbook>.yml
Removing a Building Block from the Cluster
There are a number of considerations to keep in mind when you need to retire a building block, for example:
What BeeGFS services are running in this building block?
Are just the file nodes retiring and the block nodes should be attached to new file nodes?
If the entire building block is being retired, should the data be moved to a new building block, dispersed into existing nodes in the cluster, or moved to a new BeeGFS file system or other storage system?
Can this happen during an outage or should it be done non-disruptively?
Is the building block actively in use, or does it primarily contain data that is no-longer active?
Because of the diverse possible starting points and desired end states, please contact NetApp support so we can identify and help implement the best strategy based on your environment and requirements.