Indicate how the Ansible Control node should authenticate with the remote hosts:

ansible_ssh_user: root
ansible_become_password: <PASSWORD>

Particularly for production environments, do not store passwords in plain text. Instead, use Ansible Vault (see Encrypting content with Ansible Vault) or the --ask-become-pass option when running the playbook. If the ansible_ssh_user is already root, then you can optionally omit the ansible_become_password.

If you are configuring static IPs on ethernet or InfiniBand interfaces (for example cluster IPs) and multiple interfaces are in the same IP subnet (for example if ib0 is using 192.168.1.10/24 and ib1 is using 192.168.1.11/24), additional IP routing tables and rules must be setup for multi-homed support to work properly. Simply enable the provided network interface configuration hook as follows:

eseries_ip_default_hook_templates:
  - 99-multihoming.j2

When deploying the cluster, depending on the storage protocol it may be necessary for nodes to be rebooted to facilitate discovering remote block devices (E-Series volumes) or apply other aspects of the configuration. By default nodes will prompt before rebooting, but you can allow nodes to restart automatically by specifying the following:

eseries_common_allow_host_reboot: true

A number of firewall ports are required for BeeGFS and HA cluster services to communicate. Unless you wish to configure the firwewall manually (not recommended), specify the following to have required firewall zones created and ports opened automatically:

beegfs_ha_firewall_configure: True

At this time SELinux is not supported, and it is is recommended the state be set to disabled to avoid conflicts (especially when RDMA is in use). Set the following to ensure SELinux is disabled:

eseries_beegfs_ha_disable_selinux: True
eseries_selinux_state: disabled

Configure authentication so file nodes are able to communicate, adjusting the defaults as needed based on your organizations policies:

beegfs_ha_cluster_name: hacluster                  # BeeGFS HA cluster name.
beegfs_ha_cluster_username: hacluster              # BeeGFS HA cluster username.
beegfs_ha_cluster_password: hapassword             # BeeGFS HA cluster username's password.
beegfs_ha_cluster_password_sha512_salt: randomSalt # BeeGFS HA cluster username's password salt.

Based on the Plan the File System section specify the BeeGFS management IP for this file system:

beegfs_ha_mgmtd_floating_ip: <IP ADDRESS>

While seemingly redundant, beegfs_ha_mgmtd_floating_ip is important when you scale the BeeGFS file system beyond a single HA cluster. Subsequent HA clusters are deployed without an additional BeeGFS management service and point at the management service provided by the first cluster.

Enable email alerts if desired:

beegfs_ha_enable_alerts: True
# E-mail recipient list for notifications when BeeGFS HA resources change or fail.
beegfs_ha_alert_email_list: ["<EMAIL>"]
# This dictionary is used to configure postfix service (/etc/postfix/main.cf) which is required to set email alerts.
beegfs_ha_alert_conf_ha_group_options:
      # This parameter specifies the local internet domain name. This is optional when the cluster nodes have fully qualified hostnames (i.e. host.example.com)
      mydomain: <MY_DOMAIN>
beegfs_ha_alert_verbosity: 3
#  1) high-level node activity
#  3) high-level node activity + fencing action information + resources (filter on X-monitor)
#  5) high-level node activity + fencing action information + resources

Enabling fencing is strongly recommended, otherwise services can be blocked from starting on secondary nodes when the primary node fails.

The BeeGFS HA role can apply many different tuning parameters to help further optimize performance. These include optimizing kernel memory utilization and block device I/O, among other parameters. The role ships with a reasonable set of defaults based on testing with NetApp E-Series block nodes, but by default these aren't applied unless you specify:

beegfs_ha_enable_performance_tuning: True

To ensure floating IP addresses (sometimes known as logical interfaces) used for BeeGFS services can fail over between file nodes, all network interfaces must be named consistently. By default network interface names are generated by the kernel, which is not guaranteed to generate consistent names, even across identical server models with network adapters installed in the same PCIe slots. This is also useful when creating inventories before the equipment is deployed and generated interface names are known. To ensure consistent device names, based on a block diagram of the server or lshw -class network -businfo output, specify the desired PCIe address-to-logical interface mapping as follows:

Optionally specify configuration that should apply to all BeeGFS services in the cluster. Default configuration values can be found here, and per-service configuration is specified elsewhere:

As of BeeGFS 7.2.7 and 7.3.1 connection authentication must be configured or explicitly disabled. There are a few ways this can be configured using the Ansible based deployment: