Indiquez comment le nœud Ansible Control doit s'authentifier auprès des hôtes distants :

ansible_ssh_user: root
ansible_become_password: <PASSWORD>

En particulier pour les environnements de production, ne stockez pas de mots de passe en texte brut. Utilisez plutôt Ansible Vault (voir "Cryptage de contenu avec Ansible Vault") ou le --ask-become-pass option lors de l'exécution du manuel de vente. Si le ansible_ssh_user est déjà root, alors vous pouvez éventuellement omettre le ansible_become_password.

Si vous configurez des adresses IP statiques sur des interfaces ethernet ou InfiniBand (par exemple, des adresses IP de cluster) et que plusieurs interfaces se trouvent dans le même sous-réseau IP (par exemple si ib0 utilise 192.168.1.10/24 et ib1 utilise 192.168.1.11/24), Des tables et des règles de routage IP supplémentaires doivent être configurées pour que le support multihomé fonctionne correctement. Activez simplement le crochet de configuration de l'interface réseau fourni comme suit :

eseries_ip_default_hook_templates:
  - 99-multihoming.j2

Lors du déploiement du cluster, en fonction du protocole de stockage, les nœuds doivent être redémarrés pour faciliter la détection des dispositifs de blocs distants (volumes E-Series) ou l'application d'autres aspects de la configuration. Par défaut, les nœuds vous demandent avant de redémarrer, mais vous pouvez autoriser les nœuds à redémarrer automatiquement en spécifiant ce qui suit :

eseries_common_allow_host_reboot: true

Plusieurs ports de pare-feu sont nécessaires pour que les services de cluster BeeGFS et HA communiquent. Sauf si vous souhaitez configurer le firwewall manuellement (non recommandé), spécifiez les zones de pare-feu requises et les ports ouverts automatiquement :

beegfs_ha_firewall_configure: True

SELinux n'est pas encore pris en charge et il est recommandé de définir l'état sur Désactivé pour éviter les conflits (en particulier lorsque RDMA est en cours d'utilisation). Définissez ce qui suit pour vous assurer que SELinux est désactivé :

eseries_beegfs_ha_disable_selinux: True
eseries_selinux_state: disabled

Configurez l'authentification pour que les nœuds de fichiers puissent communiquer, en ajustant les valeurs par défaut en fonction des règles de votre entreprise :

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.

Basé sur "Planifiez le système de fichiers" Spécifiez l'IP de gestion BeeGFS pour ce système de fichiers :

beegfs_ha_mgmtd_floating_ip: <IP ADDRESS>

Tout en apparence redondant, beegfs_ha_mgmtd_floating_ip Est important lorsque vous faites évoluer le système de fichiers BeeGFS au-delà d'un seul cluster HA. Les clusters HA suivants sont déployés sans service de gestion BeeGFS et point supplémentaires sur le service de gestion fourni par le premier cluster.

Activez les alertes par e-mail si vous le souhaitez :

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

L'activation de l'escrime est fortement recommandée, sinon les services peuvent être bloqués afin de démarrer sur les nœuds secondaires lorsque le nœud principal tombe en panne.

Le rôle BeeGFS HA peut appliquer de nombreux paramètres de réglage différents pour optimiser davantage les performances. Ces paramètres incluent notamment l'optimisation de l'utilisation de la mémoire du noyau et le blocage des E/S du périphérique. Le rôle est livré avec un ensemble raisonnable de "valeurs par défaut" Selon les tests réalisés avec des nœuds de blocs NetApp E-Series, les applications suivantes ne sont par défaut pas appliquées sauf si vous spécifiez :

beegfs_ha_enable_performance_tuning: True

Pour garantir que les adresses IP flottantes (parfois appelées interfaces logiques) utilisées pour les services BeeGFS peuvent basculer entre les nœuds de fichiers, toutes les interfaces réseau doivent être nommées de façon cohérente. Par défaut, les noms d'interface réseau sont générés par le noyau, qui n'est pas garanti de générer des noms cohérents, même sur des modèles de serveurs identiques avec des cartes réseau installées dans les mêmes slots PCIe. Cela est également utile lors de la création d'inventaires avant le déploiement de l'équipement et la génération de noms d'interfaces connus. Pour garantir des noms de périphériques cohérents, en fonction d'un schéma fonctionnel du serveur ou lshw -class network -businfo Sortie, spécifiez le mappage adresse PCIe vers interface logique souhaité comme suit :

Si vous utilisez un modèle de nœud de fichier vérifié, cliquez sur "ici" Exemples de mappages de port adresse PCIe vers port logique.

Spécifiez éventuellement la configuration qui doit s'appliquer à tous les services BeeGFS dans le cluster. Des valeurs de configuration par défaut sont disponibles "ici", et la configuration par service est spécifiée ailleurs :

Depuis BeeGFS 7.2.7 et 7.3.1 "authentification de la connexion" doit être configuré ou explicitement désactivé. Il existe quelques façons de configurer ce système à l'aide du déploiement Ansible :