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.

Configurer des nœuds de fichiers individuels

Contributeurs
PDF

Spécifiez la configuration des nœuds de fichiers individuels à l'aide de variables hôte (Host_var).

Présentation

Cette section décrit le remplissage d'un host_vars/<FILE_NODE_HOSTNAME>.yml fichier pour chaque nœud de fichiers du cluster. Ces fichiers ne doivent contenir qu'une configuration unique à un nœud de fichier particulier. Les points suivants sont généralement utilisés :

  • Définition de l'IP ou du nom d'hôte Ansible doit utiliser pour se connecter au nœud.

  • Configuration d'interfaces supplémentaires et d'adresses IP de cluster utilisées pour les services de cluster HA (Pacemaker et Corosync) pour communiquer avec d'autres nœuds de fichiers. Par défaut, ces services utilisent le même réseau que l'interface de gestion, mais des interfaces supplémentaires doivent être disponibles pour la redondance. La pratique courante consiste à définir des adresses IP supplémentaires sur le réseau de stockage, ce qui évite d'avoir recours à un cluster ou à un réseau de gestion supplémentaire.

    • Les performances des réseaux utilisés pour la communication en cluster ne sont pas critiques pour les performances du système de fichiers. Avec la configuration de cluster par défaut, un réseau d'au moins 1 Gbit/s fournit généralement des performances suffisantes pour les opérations de cluster telles que la synchronisation des États de nœud et la coordination des modifications de l'état des ressources du cluster. Les réseaux lents/occupés peuvent entraîner des changements d'état des ressources qui prennent plus de temps que d'habitude. Dans des cas extrêmes, les nœuds risquent d'être supprimés du cluster s'ils ne peuvent pas envoyer des signaux cardiaques dans des délais raisonnables.

  • Configuration des interfaces utilisées pour la connexion aux nœuds de bloc via le protocole souhaité (par exemple : iSCSI/iser, NVMe/IB, NVMe/RoCE, FCP, etc.)

Étapes

En faisant référence au schéma d'adressage IP défini dans la "Planifiez le système de fichiers" section, pour chaque nœud de fichier du cluster, créez un fichier host_vars/<FILE_NODE_HOSTNAME>/yml et remplissez-le comme suit :

  1. En haut de la page, indiquez l'IP ou le nom d'hôte Ansible doit utiliser pour SSH sur le nœud et le gérer :

    ansible_host: "<MANAGEMENT_IP>"

  2. Configurez des adresses IP supplémentaires qui peuvent être utilisées pour le trafic du cluster :

    1. Si le type de réseau est "InfiniBand (avec IPoib)":

      eseries_ipoib_interfaces:
- name: <INTERFACE>  # Example: ib0 or i1b
  address: <IP/SUBNET> # Example: 100.127.100.1/16
- name: <INTERFACE>  # Additional interfaces as needed.
  address: <IP/SUBNET>

    2. Si le type de réseau est "RDMA over Converged Ethernet (RoCE)":

      eseries_roce_interfaces:
- name: <INTERFACE>  # Example: eth0.
  address: <IP/SUBNET> # Example: 100.127.100.1/16
- name: <INTERFACE>  # Additional interfaces as needed.
  address: <IP/SUBNET>

    3. Si le type de réseau est "Ethernet (TCP uniquement, pas de RDMA)":

      eseries_ip_interfaces:
- name: <INTERFACE>  # Example: eth0.
  address: <IP/SUBNET> # Example: 100.127.100.1/16
- name: <INTERFACE>  # Additional interfaces as needed.
  address: <IP/SUBNET>

  3. Indiquez quelles adresses IP doivent être utilisées pour le trafic du cluster, avec des adresses IP préférées répertoriées plus haut :

    beegfs_ha_cluster_node_ips:
- <MANAGEMENT_IP> # Including the management IP is typically but not required.
- <IP_ADDRESS>    # Ex: 100.127.100.1
- <IP_ADDRESS>    # Additional IPs as needed.
    Remarque IPS configuré à l'étape deux ne sera pas utilisé comme adresses IP de cluster à moins qu'elles ne soient incluses dans le beegfs_ha_cluster_node_ips liste. Cela vous permet de configurer des adresses IP/interfaces supplémentaires à l'aide d'Ansible, qui peuvent être utilisées à d'autres fins si nécessaire.

  4. Si le nœud de fichiers doit communiquer pour bloquer les nœuds via un protocole IP, les adresses IP doivent être configurées sur l'interface appropriée, ainsi que tous les packages requis pour ce protocole installés/configurés.

    1. En cas d'utilisation "ISCSI":

      eseries_iscsi_interfaces:
- name: <INTERFACE>  # Example: eth0.
  address: <IP/SUBNET> # Example: 100.127.100.1/16

    2. En cas d'utilisation "Iser":

      eseries_ib_iser_interfaces:
- name: <INTERFACE>  # Example: ib0.
  address: <IP/SUBNET> # Example: 100.127.100.1/16
  configure: true # If the file node is directly connected to the block node set to true to setup OpenSM.

    3. En cas d'utilisation "NVMe/IB":

      eseries_nvme_ib_interfaces:
- name: <INTERFACE>  # Example: ib0.
  address: <IP/SUBNET> # Example: 100.127.100.1/16
  configure: true # If the file node is directly connected to the block node set to true to setup OpenSM.

    4. En cas d'utilisation "NVMe/RoCE":

      eseries_nvme_roce_interfaces:
- name: <INTERFACE>  # Example: eth0.
  address: <IP/SUBNET> # Example: 100.127.100.1/16

    5. Autres protocoles :

      1. En cas d'utilisation "NVMe/FC", il n'est pas nécessaire de configurer des interfaces individuelles. Le déploiement du cluster BeeGFS détecte automatiquement le protocole et installe/configure les exigences selon les besoins. Si vous utilisez une structure pour connecter des nœuds de fichiers et de blocs, assurez-vous que les commutateurs sont correctement zonés en suivant les meilleures pratiques de NetApp et de votre fournisseur de commutateurs.

      2. L'utilisation de FCP ou de SAS ne nécessite pas l'installation ou la configuration de logiciels supplémentaires. Si vous utilisez FCP, assurez-vous que les commutateurs sont correctement zonés suivant "NetApp" et les meilleures pratiques de votre fournisseur de commutateurs.

      3. L'utilisation du SRP IB n'est pas recommandée pour le moment. Utilisez les technologies NVMe/IB ou iser selon les systèmes que prennent en charge les nœuds bloc E-Series.

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

Avancé : basculement des adaptateurs VPI NVIDIA ConnectX entre Ethernet et InfiniBand

Les adaptateurs NVIDIA ConnectX-Virtual Protocol Interconnect&reg (VPI) prennent en charge les protocoles InfiniBand et Ethernet comme couche de transport. Le passage d'un mode à l'autre n'est pas négocié automatiquement et doit être configuré à l'aide de mstconfig l'outil inclus dans mstflint, un package open source qui fait partie du "Outils de fermeté NVIDIA (MFT)". La modification du mode des adaptateurs ne doit être effectuée qu'une seule fois. Cette opération peut être effectuée manuellement ou incluse dans l'inventaire Ansible dans le cadre de toute interface configurée à l'aide de la eseries-[ib|ib_iser|ipoib|nvme_ib|nvme_roce|roce]_interfaces: section de l'inventaire pour que cette opération soit vérifiée/appliquée automatiquement.

Par exemple, pour modifier le courant d'une interface en mode InfiniBand en Ethernet et pouvoir l'utiliser pour RoCE :

  1. Pour chaque interface que vous souhaitez configurer, spécifiez mstconfig en tant que mappage (ou dictionnaire) spécifié LINK_TYPE_P<N> où <N> Est déterminé par le numéro de port HCA de l'interface. Le <N> la valeur peut être déterminée en cours d'exécution grep PCI_SLOT_NAME /sys/class/net/<INTERFACE_NAME>/device/uevent Et ajout de 1 au dernier numéro à partir du nom du slot PCI et conversion en décimal.

    1. Par exemple donné PCI_SLOT_NAME=0000:2f:00.2 (2 + 1 → port HCA 3) → LINK_TYPE_P3: eth:

      eseries_roce_interfaces:
- name: <INTERFACE>
  address: <IP/SUBNET>
  mstconfig:
    LINK_TYPE_P3: eth

Pour plus de détails, reportez-vous au "Documentation de la collection d'hôtes NetApp E-Series" pour le type/protocole d'interface que vous utilisez.