Swarms quickstart

Create your first Swarm

Starting from the Swarm list click one of the Create new Swarm button to open the creation form. Fill the form with the required information about the selected name and description then move forward to complete the swarm configuration. The next step is the Nexus configuration.

Create your first Nexus

Ensure you are inside the Swarm you want and select Nexus in the sidebar. We can consider Nexus as an equivalent of an availability zone. We also suggest including in the same Nexus server with the same topology and performances. That will simplify the creation of the Redundancy classes in the next step.

Creating a Nexus is basic and can be performed by clicking the button Create your Nexus from the Nexus List. A few details are required:

• Name
• Description
• Location

info

Location is currently a simple label, but in the future will be used as the position of the Nexus, and all the servers into it, to better evaluate data protection strategy.

You can create and configure one Nexus at a time or do it all together.

Once you have created your Nexus, it is now time to configure the servers inside it. If not already visible, open the node list by clicking over the Nexus.

note

We suggest grouping the servers by topology and configuring them in bulk. If not possible you can configure each of them one by one using the same flow or one node at a time. In the current implementation, every Node is mapped over a disk.

Press Create nodes in bulk to start the bulk procedure. That flow is composed of 3 steps. In the first one we insert generic information about the topology of the servers we are going to configure. In the details, we must specify the number of servers and the number of disks they have.

warning

If the servers are not sharing the same disk number, configure them at different times.

The provider is the user in charge of the physical machine, which will be notified in case of detected issues. You can use the default one (Swarm owner email) or configure a custom provider in the Provider section.

In the second step, we are required to specify the disk configuration and the network information of each server. The disk configurations are expected to be the same on every server. The final result is autogenerated starting from the provided prefix and the first identifier.

info

If the automatic generation does not match the reality, you can move forward and manually edit the exact value in the files generated by the procedure.

For the network configuration, each server requires the following information:

• Public IP
• Private IP - optional, if configured, prioritize infra-network operation saving bandwidth costs
• Server ID - identifies the server and allows to mapping the Nodes that are located on the same machine
• Ports - used by the Nodes to expose themselves. Every node is assigned to a different port.

note

The ports input accepts the following option:

• A list of comma-separated ports
• The first port. In this case, all the other ports will be sequentially generated from the first one

The third step is optional and allows you to configure an SSH key for every user you want to authorize to connect to the server using the SSH protocol. If desired, specify a name and the public part of the SSH keypair in the form.

Once all the steps have been completed, the recap automatically downloads and shows a preview of the generated tar file containing all the Ansible recipes. Please remember to download it before you leave the page.

Create your first Redundancy Class

warning

It's not possible to create a Redundancy Class if at least one Nexus and one Node inside it have not been fully configured. Return to the steps before if you have not completed them.

In the sidebar of the Swarm section, click Redundancy Class to open the dedicated section. Then, in the list, select the dedicated button to start the creation flow.

The creation is divided into three parts. The first focuses on defining the RC details, while the others are centered around the Rings creations.

To create an RC we need:

• Name - RC name
• Geographical N+K - Number of availability zones (Nexus) used by the RC. Data are available for download until at least N availability zones are reachable
• Local N+K - Number of disks used for every Nexus. Data can be retrieved from the availability zone until at least N disks are reachable
• Anti Affinity Group (AAG) - It represents the number of disks we can use on the same machine. Machines are identified by the Server ID. The more the machines are paired, the more the RC is vulnerable to the issue of the single machine.

Once you confirm the RC is created the next step to create the Rings for it is immediately visible. First is required to select N+K (geographical) Nexus, where only the Nexus with at least N+K (local) nodes are eligible for the selections. Once enough Nexuses are selected the next step will be reachable and the system will display the maximum number of Rings we may generate for the combination of RC and selected Nexuses. You may change the number of Rings you decide to create and confirm.

note

The size overhead introduced by the redundancy class is called ratio and is equal to $\frac{n_{geo} + k_{geo}}{n_{geo}} \times \frac{n_{local} + k_{local}}{n_{local}}$.

info

At this stage, we always suggest creating the maximum number of rings.

The redundancy class is now created and Rings are available in it. The RC can now be connected and used by a Tenant.

note

Redundancy classes with 0 Rings cannot be connected to a Tenant.