In the Weka system, it is possible to expand and shrink a cluster as follows:
Add or delete backend hosts
Add or delete SSDs from an existing backend host
Change the number of cores assigned to the Weka system in existing backend hosts
Change the amount of memory allocated to the Weka system in existing backend hosts
Change the network resources assigned to the Weka system in existing backend hosts
Expansion procedures are similar to the Bare Metal Weka system Installation Procedure. Similar to planning a new cluster, the objectives of the expansion, in terms of space and performance, need to be translated to the actual cluster resources. This process is practically a repeat of the planning process for new clusters, with the following options and limitations:
Addition of new backend hosts.
Addition of new failure domains, as long the system was installed with failure domains.
Addition of new SSDs to existing backend hosts.
Assignment of additional cores to Weka in existing backend hosts.
Assignment of more memory to Weka in existing backend hosts.
Assignment of additional network resources to Weka in existing backend hosts.
Reconfiguration of hot spares.
It is not possible to change the defined Weka system protection scheme.
It is not possible to define failure domains on a system that was installed without failure domains.
A Weka system configured with failure domains cannot be configured to be without failure domains.
Only the same network technology can be implemented i.e., it is not possible to mix between Ethernet and InfiniBand.
To plan the capacity of the Weka system after expansion, refer to SSD Capacity Management.
Once an expansion of more SSDs or backend hosts has been planned and executed, the Weka system starts a redistribution process. This involves the redistribution of all the existing data to be perfectly balanced between the original hosts or SSDs and newly added resources. This process can take from minutes to hours, depending on the capacity and the networking CPU resources. However, the capacity increase is instant, and therefore it is possible to define more filesystems immediately, without waiting for the completion of the redistribution process.
Once the expansion of more cores or backend hosts has been implemented, the added CPU resources are operational in less than a minute. Write performance improves almost immediately, while read performance only improves on completion of the redistribution of the data.