Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

9.3. Configurer le sous-système RDMA de base

9.3.1. L'installation du package RDMA

Le paquet rdma ne fait pas partie de l'ensemble de packages à installer par défaut. Si le groupe de packages InfiniBand n'a pas été sélectionné pendant l'installation, le paquet rdma (ainsi que quelques autres énumérés dans la section précédente) peuvent être installés après que l'installation initiale soit terminée. S'il n'a pas été installé au moment de l'installation de la machine et a été installé manuellement par la suite, alors il convient de reconstruire les images initramfs avec dracut afin qu'il fonctionne parfaitement, comme prévu. Exécutez les commandes suivantes en tant qu'utilisateur root :
~]# yum install rdma
dracut -f
Le démarrage du service rdma est automatique. Quand du matériel compatible RDMA, InfiniBand, iWARP ou RoCE/IBoE est détecté, udev charge systemd de démarrer le service rdma. Les utilisateurs n'ont pas besoin d'activer le service rdma, mais ils peuvent le forcer à tout moment s'ils le souhaitent. Pour ce faire, exécutez la commande suivante :
~]# systemctl enable rdma

9.3.2. Configuration du fichier rdma-conf

Le service rdma lit /etc/rdma/rdma.conf pour trouver quels protocoles RDMA niveau utilisateur ou niveau noyau, l'administrateur veut charger par défaut. Les utilisateurs doivent éditer ce fichier pour démarrer ou stopper les différents pilotes.
Voici un certain nombre de pilotes qui peuvent être activés ou désactivés :
  • IPoIB — Il s'agit d'une couche d'émulation de réseaux IP qui permet aux applications IP d'exécuter sur les réseaux InfiniBand.
  • SRP — Il s'agit du protocole de demandes SCSI Request Protocol. Ce protocole permet à une machine de monter un lecteur ou un groupe de lecteurs distants exportés sur la machine, via le protocole SRP, comme s'il s'agissait d'un disque dur local.
  • SRPT — c'est le mode cible ou serveur du protocole SRP. Ceci charge le support noyau nécessaire pour pouvoir exporter un lecteur ou un groupe de lecteurs pour que d'autres machines puissent être montées, comme s'il était local sur leur machine. Vous devrez effectuer une configuration plus poussée en mode cible avant de pouvoir exporter un périphérique. Consultez la documentation dans les paquets targetd et targetcli pour de plus amples informations.
  • ISER — Il s'agit d'un pilote de bas niveau de la couche générale iSCSI du noyau Linux qui fournit un transport sur les réseaux InfiniBand pour les périphériques iSCSI.
  • RDS — Reliable Datagram Service du noyau Linux. Non actif dans les noyaux Red Hat Enterprise Linux 7 et ne peut donc pas être téléchargé.

9.3.3. Utilisation de 70-persistent-ipoib.rules

Le paquet de rdma fournit le fichier /etc/udev.d/rules.d/70-persistent-ipoib.rules. Ce fichier de règles udev est utilisé pour renommer des dispositifs IPoIB de leurs noms par défaut (par exemple, ib0 et ib1) à des noms plus descriptifs. Les utilisateurs doivent modifier ce fichier pour changer comment nommer leurs périphériques. Tout d'abord, trouver l'adresse GUID pour le périphérique qui doit être renommé :
~]$ ip link show ib0
8: ib0: >BROADCAST,MULTICAST,UP,LOWER_UP< mtu 65520 qdisc pfifo_fast state UP mode DEFAULT qlen 256
    link/infiniband 80:00:02:00:fe:80:00:00:00:00:00:00:f4:52:14:03:00:7b:cb:a1 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
Immédiatement après lien/infiniband se trouve l'adresse de matériel de 20 octets pour l'interface IPoIB. Les 8 octets finaux de l'adresse, marqué en gras ci-dessus, est tout ce qu'il faut pour créer un nouveau nom. Les utilisateurs peuvent créer un schéma de nommage qui leur convient. Par exemple, utiliser une convention d'affectation de noms device_fabric comme mlx4_ib0, si un périphérique mlx4 est connecté à une fibre de sous-réseau ib0. La seule chose qui n'est pas recommandée est d'utiliser les noms standards, comme ib0 ou ib1, car ceux-ci peuvent entrer en conflit avec les noms assignés automtiquement par le noyau. Ensuite, ajoutez une entrée dans le fichier de règles. Copiez l'exemple existant dans le fichier de règles, remplacez les 8 octets dans l'entrée ATTR {address} avec les 8 octets en surbrillance du périphérique qui doit être renommé, et entrez le nouveau nom à utiliser dans le champ NAME.

9.3.4. Relaxation des restrictions memlock pour les utilisateurs

Les communications RDMA exigent que la mémoire physique de l'ordinateur soit épinglée (ce qui signifie que le noyau ne doit pas être autorisé à échanger cette mémoire dans un fichier d'échange dans le cas où l'ordinateur, dans son ensemble, commence à être à court de mémoire disponible). Normalement, l'épinglage de la mémoire est une opération très privilégiée. Pour permettre aux utilisateurs autres que root d'exécuter des applications RDMA de grande envergure, il va probablement falloir augmenter la quantité de mémoire que les utilisateurs non - root sont autorisés à épingler dans le système. Cela se fait en ajoutant un fichier dans le répertoire /etc/security/limits.d/ avec des contenus semblables à ceci :
~]$ more /etc/security/limits.d/rdma.conf
# configuration for rdma tuning
*       soft    memlock         unlimited
*       hard    memlock         unlimited
# rdma tuning end

9.3.5. Configurer des cartes Mellanox pour l'opération Ethernet

Certains matériels de Mellanox sont capables d'exécuter en mode Ethernet ou InfiniBand. Ces cartes ont généralement InfiniBand comme valeur par défaut. Les utilisateurs peuvent définir les cartes en mode Ethernet. Il y a actuellement un support pour définir le mode sur matériel ConnectX family uniquement (qui utilise le pilote mlx4). Pour définir le mode, les utilisateurs doivent suivre les instructions dans le fichier /etc/rdma/mlx4.conf pour trouver l'ID de périphérique PCI pour leur matériel. Ils doivent ensuite créer une ligne dans le fichier à l'aide de cet ID de périphérique et le type de port requis, puis reconstruire leur initramfs pour s'assurer que les paramètres de port mis à jour sont copiés dans initramfs.
Une fois que le type de port a été défini, si un ou deux ports sont définis sur Ethernet, les utilisateurs peuvent apercevoir ce message dans leurs journaux : mlx4_core 0000:05:00.0: Requested port type for port 1 is not supported on this HCA. C'est normal et n'affectera pas le fonctionnement. Le script chargé de définir le type de port n'a aucun moyen de savoir quand le pilote a fini de passer du port 2 au type demandé en interne, et le temps que le script émette une requête de changement au port 2 et que le changement soit terminé, les tentatives de régler le port 1 à un autre type sont rejetées. Le script tente à nouveau jusqu'à ce que la commande réussisse, ou jusqu'à ce qu'un délai d'attente soit écoulé, indiquant que le changement de port n'a pas réussi.