Skip to main content
BeeGFS on NetApp with E-Series Storage
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Spécifiez la configuration de nœud de fichier commun

Contributeurs

Spécifiez une configuration de nœud de fichier commune à l'aide de variables de groupe (Group_var).

Présentation

La configuration qui doit pommier à tous les noeuds de fichiers est définie à group_vars/ha_cluster.yml. Elle comprend généralement :

  • Détails sur la connexion et la connexion à chaque noeud de fichier.

  • Configuration commune de réseau.

  • Indique si les redémarrages automatiques sont autorisés.

  • Configuration des États pare-feu et selinux.

  • Configuration du cluster, y compris alertes et clôtures.

  • Réglage des performances.

  • Configuration du service Common BeeGFS.

Remarque Les options définies dans ce fichier peuvent également être définies sur des nœuds de fichiers individuels, par exemple si des modèles de matériel mixtes sont utilisés, ou si vous avez des mots de passe différents pour chaque nœud. La configuration des nœuds de fichiers individuels est prioritaire sur la configuration dans ce fichier.

Étapes

Créez le fichier group_vars/ha_cluster.yml et remplir comme suit :

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

    ansible_ssh_user: root
    ansible_become_password: <PASSWORD>
    Avertissement 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.
  2. 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
  3. 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
    1. Par défaut après un redémarrage, pour vous assurer que les périphériques de bloc et les autres services sont prêts, Ansible attend jusqu'à ce que le système default.target est atteinte avant de poursuivre le déploiement. Dans certains cas, lorsque la technologie NVMe/IB est utilisée, il peut s'avérer insuffisant pour initialiser, détecter et se connecter aux périphériques distants. Cela peut entraîner une poursuite prématurée et une défaillance du déploiement automatisé. Pour éviter ce problème lors de l'utilisation de NVMe/IB, définissez également les éléments suivants :

      eseries_common_reboot_test_command: "! systemctl status eseries_nvme_ib.service || systemctl --state=exited | grep eseries_nvme_ib.service"
  4. 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
  5. 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
  6. 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.
  7. Sur la base de "Planifiez le système de fichiers"cette section, spécifiez l'IP de gestion BeeGFS pour ce système de fichiers :

    beegfs_ha_mgmtd_floating_ip: <IP ADDRESS>
    Remarque 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.
  8. 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
  9. 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.

    1. Activer globalement l'escrime en spécifiant les éléments suivants :

      beegfs_ha_cluster_crm_config_options:
        stonith-enabled: True
      1. Remarque tout support "propriété du cluster" peut également être spécifié ici si nécessaire. Ils ne sont généralement pas nécessaires, car le rôle haute disponibilité BeeGFS est livré avec un certain nombre de composants bien testés "valeurs par défaut".

    2. Sélectionnez et configurez ensuite un agent d'escrime :

      1. OPTION 1 : pour activer l'escrime à l'aide des unités de distribution d'alimentation APC :

        beegfs_ha_fencing_agents:
          fence_apc:
            - ipaddr: <PDU_IP_ADDRESS>
              login: <PDU_USERNAME>
              passwd: <PDU_PASSWORD>
              pcmk_host_map: "<HOSTNAME>:<PDU_PORT>,<PDU_PORT>;<HOSTNAME>:<PDU_PORT>,<PDU_PORT>"
      2. OPTION 2 : pour activer l'escrime à l'aide des API Redfish fournies par le XCC Lenovo (et d'autres CVM) :

        redfish: &redfish
          username: <BMC_USERNAME>
          password: <BMC_PASSWORD>
          ssl_insecure: 1 # If a valid SSL certificate is not available specify “1”.
        
        beegfs_ha_fencing_agents:
          fence_redfish:
            - pcmk_host_list: <HOSTNAME>
              ip: <BMC_IP>
              <<: *redfish
            - pcmk_host_list: <HOSTNAME>
              ip: <BMC_IP>
              <<: *redfish
      3. Pour plus de détails sur la configuration d'autres agents de clôture, reportez-vous au "Documentation Red Hat".

  10. 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 fourni avec un ensemble raisonnable de "valeurs par défaut" tests basés sur des tests avec des nœuds de bloc NetApp E-Series, mais par défaut, ces tests ne sont pas appliqués sauf si vous spécifiez :

    beegfs_ha_enable_performance_tuning: True
    1. Si nécessaire, spécifiez également les modifications apportées au réglage de performance par défaut ici. Pour plus d'informations, reportez-vous à la documentation complète "paramètres d'ajustement des performances" .

  11. 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 :

    1. Pour les interfaces réseau InfiniBand (IPoIB) :

      eseries_ipoib_udev_rules:
        "<PCIe ADDRESS>": <NAME> # Ex: 0000:01:00.0: i1a
    2. Pour les interfaces réseau Ethernet :

      eseries_ip_udev_rules:
        "<PCIe ADDRESS>": <NAME> # Ex: 0000:01:00.0: e1a
      Important Pour éviter les conflits lorsque les interfaces sont renommées (les empêchant d'être renommées), vous ne devez pas utiliser de noms par défaut potentiels tels que eth0, en9 f0, ib0 ou ibs4f0. la convention de nom la plus courante consiste à utiliser « e » ou « i » pour Ethernet ou InfiniBand, suivi du numéro de connecteur PCIe, ainsi qu'une lettre indiquant le port. Par exemple, le deuxième port d'un adaptateur InfiniBand installé dans le logement 3 est : i3b.
    Remarque 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.
  12. Spécifiez éventuellement la configuration qui doit s'appliquer à tous les services BeeGFS dans le cluster. Les valeurs de configuration par défaut sont disponibles "ici"et la configuration par service est spécifiée ailleurs :

    1. Service de gestion BeeGFS :

      beegfs_ha_beegfs_mgmtd_conf_ha_group_options:
        <OPTION>: <VALUE>
    2. Les services de métadonnées BeeGFS :

      beegfs_ha_beegfs_meta_conf_ha_group_options:
        <OPTION>: <VALUE>
    3. BeeGFS Services de stockage :

      beegfs_ha_beegfs_storage_conf_ha_group_options:
        <OPTION>: <VALUE>
  13. 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 :

    1. Par défaut, le déploiement configure automatiquement l'authentification de connexion et génère un connauthfile Qui sera distribué à tous les nœuds de fichiers et utilisé avec les services BeeGFS. Ce fichier sera également placé/conservé sur le nœud de contrôle Ansible à <INVENTORY>/files/beegfs/<sysMgmtdHost>_connAuthFile où il doit être conservé (sécurisé) pour être réutilisé avec les clients qui doivent accéder à ce système de fichiers.

      1. Pour générer une nouvelle clé spécifiez -e "beegfs_ha_conn_auth_force_new=True Lors de l'exécution du manuel de vente Ansible. Remarque cette opération est ignorée si une beegfs_ha_conn_auth_secret est défini.

      2. Pour les options avancées, reportez-vous à la liste complète des valeurs par défaut incluses avec le "Rôle BeeGFS HA".

    2. Un secret personnalisé peut être utilisé en définissant les éléments suivants dans ha_cluster.yml:

      beegfs_ha_conn_auth_secret: <SECRET>
    3. L'authentification de la connexion peut être entièrement désactivée (NON recommandée) :

      beegfs_ha_conn_auth_enabled: false

Cliquez sur "ici" par exemple, un fichier d'inventaire complet représentant la configuration de nœud de fichier commune.

Utilisation de la technologie InfiniBand HDR (200 Go) avec des nœuds de bloc NetApp EF600 :

Pour utiliser l'InfiniBand HDR (200 Go) avec l'EF600, le gestionnaire de sous-réseau doit prendre en charge la virtualisation. Si les nœuds de fichiers et de blocs sont connectés à l'aide d'un commutateur, celui-ci doit être activé sur le gestionnaire de sous-réseau pour la structure globale.

Si les nœuds de blocs et de fichiers sont directement connectés via InfiniBand, une instance de opensm doit être configurée sur chaque nœud de fichiers pour chaque interface directement connectée à un nœud de bloc. Pour ce faire, spécifiez configure: true quand "configuration des interfaces de stockage de nœud de fichiers".

Actuellement, la version intégrée de opensm fournie avec les distributions Linux prises en charge ne prend pas en charge la virtualisation. Il est nécessaire d'installer et de configurer la version de opensm à partir de NVIDIA OpenFabrics Enterprise distribution (OFED). Même si le déploiement avec Ansible est toujours pris en charge, quelques étapes supplémentaires sont requises :

  1. À l'aide de curl ou de l'outil de votre choix, téléchargez les packages de la version d'OpenSM répertoriée dans la "exigences technologiques" section du site Web de NVIDIA vers le <INVENTORY>/packages/ répertoire. Par exemple :

    curl -o packages/opensm-libs-5.17.2.MLNX20240610.dc7c2998-0.1.2310322.x86_64.rpm https://linux.mellanox.com/public/repo/mlnx_ofed/23.10-3.2.2.0/rhel9.3/x86_64/opensm-libs-5.17.2.MLNX20240610.dc7c2998-0.1.2310322.x86_64.rpm
    
    curl -o packages/opensm-5.17.2.MLNX20240610.dc7c2998-0.1.2310322.x86_64.rpm https://linux.mellanox.com/public/repo/mlnx_ofed/23.10-3.2.2.0/rhel9.3/x86_64/opensm-5.17.2.MLNX20240610.dc7c2998-0.1.2310322.x86_64.rpm
  2. Sous group_vars/ha_cluster.yml définissez la configuration suivante :

    ### OpenSM package and configuration information
    eseries_ib_opensm_allow_upgrades: true
    eseries_ib_opensm_skip_package_validation: true
    eseries_ib_opensm_rhel_packages: []
    eseries_ib_opensm_custom_packages:
      install:
        - files:
            add:
              "packages/opensm-libs-5.17.2.MLNX20240610.dc7c2998-0.1.2310322.x86_64.rpm": "/tmp/"
              "packages/opensm-5.17.2.MLNX20240610.dc7c2998-0.1.2310322.x86_64.rpm": "/tmp/"
        - packages:
            add:
              - /tmp/opensm-5.17.2.MLNX20240610.dc7c2998-0.1.2310322.x86_64.rpm
              - /tmp/opensm-libs-5.17.2.MLNX20240610.dc7c2998-0.1.2310322.x86_64.rpm
      uninstall:
        - packages:
            remove:
              - opensm
              - opensm-libs
          files:
            remove:
              - /tmp/opensm-5.17.2.MLNX20240610.dc7c2998-0.1.2310322.x86_64.rpm
              - /tmp/opensm-libs-5.17.2.MLNX20240610.dc7c2998-0.1.2310322.x86_64.rpm
    
    eseries_ib_opensm_options:
      virt_enabled: "2"