Install ARTESCA+ for Production

Requirements

Refer to these guidelines outlining the standard ARTESCA Software Appliance requirements.

For the ARTESCA+ Veeam Unified Software Appliance, note the following specifics:

• The server density ranges from 4 to 24 LFF drives and provides a maximum of 420 TB of usable storage capacity.

• The CPU, RAM, and NVMe service drives requirements are adjusted to account for Windows and Veeam resource consumption.

Server Density	Physical CPU Cores	Memory	NVMe
Up to 4LFF	24	192 GB	Low: 2 x 960GB
Up to 12LFF	36	256 GB	Low: 2 x 1.92 TB High: 2 x 3.84 TB
Up to 24LFF	51	384 GB	Low: 2 x 3.84 TB High: 2 x 3.84 TB

Network Considerations

When deploying the ARTESCA+ Veeam Unified Software Appliance, the following network settings are applied:

• For single-node deployments, the control plane and workload plane are set to the 1.1.1.1/32 subnet.

• The Data Network Interface is configured in bridge mode.

• The Veeam Virtual Machine gets a dedicated IP in the Data Network.

Refer to these guidelines for more information.

Important

The Veeam Virtual Machine is exposed directly on the Data Network without any firewall rules, so make sure it is secured.

Note

• In the context of Veeam VBR 12, the Veeam Virtual Machine refers to the Windows Virtual Machine on which the Veeam VBR packages will be deployed.

• In the context of Veeam VSA 13, the Veeam Virtual Machine refers to the Linux Veeam Software Appliance (VSA).

Hardware Node Preparation

Refer to these guidelines.

Deployment

The ARTESCA+ Veeam Unified Software Appliance deployment is a two-step process:

1. Install the operating system on the hardware node.

2. Install the software components on top of the operating system.

ARTESCA Operating System Installation

Refer to these guidelines.

Preparation

Artifacts Preparation

Make sure you have uploaded all artifacts for this ARTESCA release to the bootstrap node server. The bootstrap node is the server from which you will launch the ARTESCA installer.

Important

For a multi-node install, you only need to upload the artifacts to the bootstrap node server.

Download Artifacts

You can download artifacts from the Internet or from an offline server.

Note

With or without Internet access refers to the ARTESCA that you are running the installation or upgrade from.

With Internet Access

1. Download the ARTESCA installer to the /home/artesca-os directory.

   [artesca-os@bootstrap ~]$
   

   rm -rf artesca-installer SHA256SUM \
      && curl -s --fail -Lo artesca-installer \
      https://downloads.scality.com/artesca-installer/Artesca-4.3.4/artesca-installer \
      && curl -s --fail -Lo SHA256SUM \
      https://downloads.scality.com/artesca-installer/Artesca-4.3.4/SHA256SUM \
      && sha256sum -c SHA256SUM \
      && chmod +x artesca-installer
   

   artesca-installer: OK
   

2. Download the component artifacts using your Scality credentials (username and password).

   [artesca-os@bootstrap ~]$
   

   sudo ./artesca-installer get --ask-password --username <username>
   

   If you are based in the Asia-Pacific region, you may want to use this command instead to download them.

   [artesca-os@bootstrap ~]$
   

   sudo ./artesca-installer get --ask-password --username <username> --url https://apac.packages.scality.com/Artesca/4.3.4/artifacts
   

   Note

   Go to your OneLogin Scality profile to access your credentials. They are found next to your email address, for example: holly.day@email.com | holly.day.

Without Internet Access

1. On a machine with an Internet access, download all the resources from https://packages.scality.com/Artesca/4.3.4/artifacts. (If you are based in the Asia-Pacific region, you may want to use this link instead to download them).

2. Copy all these files to the /home/artesca-os/ directory on your target machine.

   Note

   Overwrite any existing copies of the files.

   Tip

   scp is the recommended tool for this task.

   From this step forward, run all commands on the target machine.

3. Check that the installer was correctly copied.

   [artesca-os@bootstrap ~]$
   

   sha256sum -c SHA256SUM
   

4. Make the ARTESCA installer executable.

   [artesca-os@bootstrap ~]$
   

   chmod +x artesca-installer
   

5. Provide the component artifacts to the ARTESCA installer.

   [artesca-os@bootstrap ~]$
   

   sudo ./artesca-installer get --url .
   

   Note

   You can provide any local path or HTTP(s) URL to the installer if the resources are not located in the installer directory.

6. Delete the installation artifacts from the /home/artesca-os directory.

   [artesca-os@bootstrap ~]$
   

   rm -f artesca-base-repo.iso artesca-base.iso metalk8s.iso xcore.iso zenko-base.iso zenko.iso
   

Installer Configuration

Deploying ARTESCA is automated with an installer, but this tool requires configuration before running.

1. Generate a functional configuration file.

   [artesca-os@bootstrap ~]$
   

   sudo ./artesca-installer config generate --output config.yaml --enable-artesca-plus
   

   Important

   You will be asked to provide the interface to be used by the Veeam Virtual Machine. If several interfaces are available, select the Data Network Interface.

   console output

   Choose the interface to use for VM networking, between the following interfaces,
   this interface will be used for all Veeam communication (enter the ID or interface
   name):
   [1] data-network: 3c:ec:ef:a4:52:80 UP  Aliases: enp6s0  IPs: 10.200.4.63/24
   [2] management-network: 3c:ec:ef:a4:51:22 UP  Aliases: enp3s0  IPs: 10.200.5.63/24
   : 1
   

2. Enter the required options as prompted by the tool.

   • -a/--architecture

   A platform architecture, with preset configuration, which depends on the number of nodes that your cluster will be composed of.

   For now, only three architectures exist, single-node, 3-nodes, and 6-nodes. On 6-nodes architecture the 3 last nodes are pure data and storage nodes and do not host any management services.

   • -p/--profile

     A hardware density profile, which matches one of the Scality Validated Hardware Platforms data storage bays size. The profiles are, as for now, the followings:

     • 4 bay HDD drives (profile is only available for single-node architecture)

     • 8 bay HDD drives (profile is only available for single-node architecture)

     • 12 bay HDD drives

     • 16 bay HDD drives

     • 24 bay HDD drives

     • Virtual Machine

     • demo (demo/test environment, should not be used in production)

   • --control-plane-cidr and --workload-plane-cidr

     IP ranges for control plane and workload plane networks, written in CIDR notation. It’s only needed for multi-node architectures.

     Tip

     If you are using the same networks for both planes, skip the second prompt, which defaults to your first entry.

   • --density

     The allowable densities are:

     • Low (Disks up to 16TB included)

     • High (Disks above 16TB)

   • --base-domain

     Base domain name that will be used as suffix for all DNS names as described in Configure DNS for ARTESCA.

     Note

     The --base-domain is set to artesca-plus.local by default.

3. Enter these optional settings.

   --username

   Name of the first user to log in to ARTESCA UI post-installation.

   --email

   Email of the first user.

   --firstname

   First name of the first user.

   --lastname

   Last name of the first user.

   --ipip-always

   In a multi-node context, if your network enforces source and destination fields of IP packets to match the MAC address(es), you must enable IP-in-IP encapsulation to allow communications between Pods of different Nodes.

   --workload-plane-mtu

   (default: 1460)

   The Maximum Transmission Unit (MTU) <https://en.wikipedia.org/wiki/Maximum_transmission_unit> is the size in bytes of the largest data frame which can be handled by the network adapter.

   The values we can set are restricted by a minimum acceptable of 68 bytes and a maximum of bytes physically supported by your network adapters.

   A typical value is 1500 bytes. Values higher than 1500 are called Jumbo Frames, This is a non-standard feature and is not supported by all models of network adapters and switches.

   Tip

   It is a good practice to set the MTU to a common value used by all the devices in your network. If it is not possible, consider to find a common value for all the devices that will communicate with the ARTESCA cluster.

   --data-management-allow-from

   (default: 0.0.0.0/0)

   One or more source IP ranges to allow access to the ARTESCA Data Services management API.

   This argument can be used multiple times:

   [artesca-os@bootstrap ~]$
   

   sudo ./artesca-installer config generate --output config.yaml \
         --data-management-allow-from 192.168.0.0/16 \
         --data-management-allow-from 127.0.0.0/8
   
   --pods-cidr

   (default: 10.233.0.0/16)

   IP range reserved for Kubernetes pods network, written in CIDR notation. No other devices or services must be in this range.

   The range must be a /20 or larger, that is at least 4096 addresses. The config generate command rejects a smaller range.

   --services-cidr

   (default: 10.96.0.0/12)

   IP range reserved for Kubernetes services network, written in CIDR notation. No other devices or services must be in this range.

   The range must be a /20 or larger, that is at least 4096 addresses. The config generate command rejects a smaller range.

   --data-disks

   (default: 12)

   Number of disks to use for storage services data. The minimum is 10 disks, except for lff4 (minimum 4) and lff8 (minimum 8) profiles.

   --wipe-data-disks / --no-wipe-data-disks

   Enable/disable the wiping of all the storage services data disks after detection. (enabled by default).

   --disable-strict-disk-selection

   By default, the installer will refuse to use data disks that do not have the same size or type (HDD/SSD). This option allows to disable this check and use different types of disks and a size toleration of 5%.

   -n/--node

   One or more nodes information to allow connection to it/them for deployment, from the current node. This argument must only be used when --architecture is set to multi-node architectures (so it cannot be used for single-node architectures).

   This argument can be passed multiple times and its format is the following:

   [artesca-os@bootstrap ~]$
   

   sudo ./artesca-installer config generate \
         --architecture 3-nodes \
         --node '{host: 10.10.1.2}' \
         --node '{host: 10.10.1.3}'
   

   Note

   The host key corresponds to the IP or hostname of the Node. This key is the only mandatory one. If you omit some fields, the installer will use the default values.

   Refer to the following documentation, for more information on node’s options.

   --local-node-name

   (default: hostname)

   Name that will be attributed to the local Node.

   --managed-management-vip / --no-managed-management-vip

   Enable/disable the administration of the management virtual IP.

   On multi-node environments, a management IP is needed, ideally using a virtual IP. If all your control plane nodes have layer 2 access between them (i.e. every machine receives ARP requests from others), then this management virtual IP can be managed by the product.

   --management-ip

   IP address to use for the management, this IP could be a real node IP, a Load Balancer IP, a Floating IP, or a Virtual IP managed or not by ARTESCA.

   --data-vip

   Virtual IP address managed by ARTESCA to expose the data. You can define multiple Virtual IPs that will be spread on every node.

   --no-data-vip

   Do not set up any data Virtual IP.

   Note

   If you have a Load Balancer, it is recommended to not configure any Virtual IPs and instead configure your Load Balancer to balance the traffic on the node workload plane real IPs.

   --data-cidr

   Expose the data on some extras CIDRs. By default, it is exposed on the workload plane CIDR and data Virtual IPs (if any).

   --disable-firewall

   Disable the default firewall rules, which restricts network traffic on the control and workload plane host interfaces to a minimum.

   --no-dns-host-forward

   Disable the cluster DNS host forward feature, which restricts the pods from resolving names outside the Kubernetes cluster.

   Important

   Adding this flag during the configuration generation allows you to deploy ARTESCA without any nameservers configured on the host machine. This removes any DNS requirements.

   However, you will not be able to resolve names outside the Kubernetes cluster from the pods. Hence, using Fully Qualified Domain Names (FQDNs) to resolve names like NTP, STMP, or any other components outside the Kubernetes cluster is not possible.

   --enable-dummy-backend-networks

   This flag is specific to single-node architectures and exposes the control plane and workload plane on a dummy interface.

   --artesca-plus-bridge-interface-name

   This flag specifies the name of the bridge interface to use for the Virtual Machine.

Tip

You can enter all options from the command line, if you do not want input prompts.

For advanced use cases or tests on non-supported hardware, refer to Advanced ARTESCA Installer Configuration.

Pre-checks

Before installing ARTESCA, the installer automatically runs pre-checks to ensure your system configuration meets all requirements and is ready for installation.

These pre-checks validate critical configurations, including RAID setup, DNS resolution, CPU flags, user permissions, NTP synchronization, and artifact availability, preventing potential installation failures.

If you want to manually run these pre-checks to ensure the system readiness independently of the full installation process, use the following command:

[artesca-os@bootstrap ~]$

sudo ./artesca-installer deploy -c config.yaml --only-pre-check

Refer to RAID Configuration Validation and Troubleshooting for more information.

Prepare nodes for ARTESCA+

Prepare the nodes for the installation.

Important

During this step, you receive a warning informing you that the Data Network Interface will be reconfigured to bridge mode, and that you may lose server connectivity during the process.

Console Output

If you are connected to the local node using the interface that will be used for the bridge
interface for KubeVirt VMs, you might be disconnected from the local node and will need to
reconnect to continue the installation.
Press any key to continue

Proceed by pressing a key and reconnect to the server.

[artesca-os@bootstrap ~]$

sudo ./artesca-installer deploy -c config.yaml prepare

Installation

Once the system is prepared and configured, install ARTESCA:

Tip

Installation logs are located in /var/log/artesca/.

[artesca-os@bootstrap ~]$

sudo ./artesca-installer deploy -c config.yaml

Note

Each part of ARTESCA can also be deployed specifically, by providing an argument to the command above, in the following order platform, volumes, base, storage and data. You can provide one or more arguments at a time, for example:

[artesca-os@bootstrap ~]$

sudo ./artesca-installer deploy -c config.yaml platform volumes base

Take away points

For the ARTESCA+ Veeam Unified Software Appliance, note the following specifics:

• The ARTESCA+ Veeam Unified Software Appliance supports both Veeam Backup & Replication (VBR) version 12 and Veeam Software Appliance (VSA) version 13.

• KubeVirt virtualization engine is deployed on the hardware node to run the Veeam Virtual Machine as part of the ARTESCA+ installation. No manual intervention is required.

• Additional logical Volumes are provisioned for the Veeam Virtual Machine.

• For single-node deployments, the control plane and workload plane are set to the 1.1.1.1/32 subnet to make the appliance portable, like for the Hardware Appliance.

• The base domain is set to artesca-plus.local.

Next Step

Continue the installation with Install the Windows Virtual Machine.