Résolution des problèmes de configuration NAS et des cibles de stockage NFS

  • Article

Cet article apporte des solutions à certaines erreurs de configuration courantes ainsi qu’à d’autres problèmes susceptibles d’empêcher Azure HPC Cache d’ajouter un système de stockage NFS comme cible de stockage.

Cet article explique comment vérifier les ports et autoriser l’accès nécessaire à un système NAS. Il contient également des informations détaillées sur des problèmes moins courants susceptibles de provoquer l’échec de la création de cibles de stockage NFS.

Conseil

Avant de suivre ce guide, consultez Prérequis des cibles de stockage NFS.

Si la solution à votre problème n’est pas indiquée ici, veuillez ouvrir un ticket de support pour que le Support technique et Service Microsoft puisse examiner et résoudre le problème avec vous.

Fournir un nombre suffisant de threads de connexion

Les systèmes HPC Cache volumineux effectuent plusieurs demandes de connexion à une cible de stockage. Par exemple, si votre cible de stockage utilise le module Ubuntu Linux nfs-kernel-server, le nombre par défaut de threads démons NFS peut descendre jusqu’à huit. Augmentez le nombre de threads à 128 ou 256, ce qui est plus raisonnable pour prendre en charge un cache HPC moyen ou grand.

Vous pouvez vérifier ou définir le nombre de threads dans Ubuntu à l’aide de la valeur RPCNFSDCOUNT dans /etc/init.d/nfs-kernel-server.

Vérification des paramètres de port

Azure HPC Cache a besoin d’un accès en lecture/écriture à plusieurs ports UDP/TCP sur le système de stockage NAS back-end. Vérifiez que ces ports sont accessibles sur le système NAS et que le trafic vers ces ports est autorisé à travers n’importe quel pare-feu entre le système de stockage et le sous-réseau de cache. Vous devrez peut-être vous rapprocher des administrateurs réseau et pare-feu de votre centre de données pour vérifier cette configuration.

Les ports des systèmes de stockage sont différents selon les fournisseurs. Vérifiez les exigences de votre système lorsque vous configurez une cible de stockage.

En général, le cache a besoin d’accéder à ces ports :

Protocole Port Service
TCP/UDP 111 rpcbind
TCP/UDP 2049 NFS
TCP/UDP 4045 nlockmgr
TCP/UDP 4046 mountd
TCP/UDP 4047 statut

Pour connaître les ports nécessaires à votre système, utilisez la commande rpcinfo suivante. Elle permet de lister les ports en présentant les résultats pertinents sous forme de tableau. (Utilisez l’adresse IP de votre système à la place du terme <storage_IP>.)

Vous pouvez lancer cette commande à partir de tout client Linux doté d’une infrastructure NFS. Si vous utilisez un client à l’intérieur du sous-réseau du cluster, il peut également vous aider à vérifier la connectivité entre le sous-réseau et le système de stockage.

rpcinfo -p <storage_IP> |egrep "100000\s+4\s+tcp|100005\s+3\s+tcp|100003\s+3\s+tcp|100024\s+1\s+tcp|100021\s+4\s+tcp"| awk '{print $4 "/" $3 " " $5}'|column -t

Assurez-vous que tous les ports renvoyés par la requête rpcinfo permettent un trafic illimité à partir du sous-réseau d’Azure HPC Cache.

Vérifiez ces paramètres sur le NAS lui-même et sur tous les pare-feu entre le système de stockage et le sous-réseau de cache.

Vérifier les paramètres de squash racine

Les paramètres de squash racine peuvent perturber l’accès aux fichiers s’ils ne sont pas configurés correctement. Vous devez vérifier que les paramètres sont corrects sur chaque exportation de stockage et sur les stratégies d’accès client HPC Cache correspondantes.

Le squash racine empêche les demandes envoyées par une racine de superutilisateur local sur le client d’être envoyées à un système de stockage back-end en tant que racine. Il réaffecte les demandes provenant de la racine à un ID d’utilisateur non privilégié (UID) comme « nobody ».

Conseil

Les versions précédentes d’Azure HPC Cache nécessitaient des systèmes de stockage NAS pour autoriser l’accès de la racine depuis HPC Cache. À présent, vous n’avez pas besoin d’autoriser l’accès de la racine sur une exportation cible de stockage, sauf si vous voulez que les clients HPC Cache aient un accès racine à l’exportation.

Le squash racine peut être configuré dans un système HPC Cache à ces emplacements :

  • Dans Azure HPC Cache : Utilisez des stratégies d’accès client pour configurer le squash racine pour les clients qui correspondent à des règles de filtre spécifiques. Une stratégie d’accès client fait partie de chaque chemin d’espace de noms cible de stockage NFS.

    La stratégie d’accès client par défaut n’effectue pas de squash racine.

  • À l’exportation de stockage : Vous pouvez configurer votre système de stockage pour réaffecter les demandes entrantes à partir de la racine vers un ID d’utilisateur non privilégié (UID).

Si votre exportation de système de stockage effectue un squash racine, vous devez mettre à jour la règle d’accès client HPC Cache pour cette cible de stockage afin qu’elle effectue aussi un squash racine. Si vous ne le faites pas, vous pouvez rencontrer des problèmes d’accès quand vous essayez de lire ou d’écrire dans le système de stockage back-end par le biais de HPC Cache.

Ce tableau illustre le comportement des différents scénarios de squash racine quand une demande client est envoyée en tant qu’UID 0 (racine). Le scénario marqué avec un * n’est pas recommandé car il peut entraîner des problèmes d’accès.

Paramètre UID envoyé à partir du client UID envoyé à partir de HPC Cache UID effectif sur le stockage back-end
aucun squash racine 0 (racine) 0 (racine) 0 (racine)
squash racine sur HPC Cache uniquement 0 (racine) 65534 (personne) 65534 (personne)
*squash racine sur stockage NAS uniquement 0 (racine) 0 (racine) 65534 (personne)
squash racine sur HPC Cache et NAS 0 (racine) 65534 (personne) 65534 (personne)

(UID 65534 constitue un exemple. Quand vous activez le squash racine dans une stratégie d’accès client, vous pouvez personnaliser l’UID.)

Vérifier l’accès sur les chemins des répertoires

Pour les systèmes NAS qui exportent des répertoires hiérarchiques, vérifiez qu’Azure HPC Cache dispose d’un accès approprié à chaque niveau d’exportation dans le chemin des fichiers que vous utilisez.

Prenons par exemple un système qui affiche trois exportations :

  • /ifs
  • /ifs/accounting
  • /ifs/accounting/payroll

L’exportation /ifs/accounting/payroll est un enfant de /ifs/accounting, et /ifs/accounting un enfant de /ifs.

Si vous ajoutez l’exportation payroll en tant que cible de stockage de HPC Cache, le cache monte en fait /ifs/ et accède au répertoire payroll à partir de là. Azure HPC Cache a donc besoin d’un accès suffisant à /ifs pour accéder à l’exportation /ifs/accounting/payroll.

Cette exigence est liée à la façon dont le cache indexe les fichiers et évite les collisions de fichiers, à l’aide des descripteurs de fichiers fournis par le système de stockage.

Un système NAS qui effectue des exportations hiérarchiques peut fournir différents descripteurs pour le même fichier si ce dernier est récupéré à partir de différentes exportations. Supposons par exemple qu’un client monte /ifs/accounting et accède au fichier payroll/2011.txt. Un autre client monte /ifs/accounting/payroll et accède au fichier 2011.txt. Selon la façon dont le système de stockage attribue les descripteurs de fichiers, ces deux clients peuvent recevoir le même fichier avec des descripteurs différents (un pour <mount2>/payroll/2011.txt et un pour <mount3>/2011.txt).

Le système de stockage back-end conserve les alias internes des descripteurs de fichiers, mais Azure HPC Cache ne peut pas déterminer quels descripteurs de fichiers de son index font référence au même élément. Il est donc possible que le cache comporte différentes écritures pour le même fichier et applique mal les modifications, ne sachant pas qu’il s’agit du même fichier.

Pour éviter cette éventuelle collision de fichiers dans plusieurs exportations, Azure HPC Cache monte automatiquement l’exportation la plus superficielle dans le chemin (/ifs dans l’exemple) et utilise le descripteur de fichier fourni à partir de cette exportation. Si plusieurs exportations ont recours au même chemin de base, Azure HPC Cache a besoin d’un accès à ce chemin.

Ajustement des restrictions de taille des paquets VPN

Si un VPN se trouve entre le cache et votre appareil NAS, il risque de bloquer les paquets Ethernet de 1 500 octets de taille complète. Vous rencontrez peut-être ce problème si les gros échanges entre le NAS et l’instance Azure HPC Cache n’aboutissent pas, mais que des mises à jour plus petites fonctionnent correctement.

Il n’existe pas de moyen simple de savoir si votre système est confronté à ce problème, sauf si vous connaissez les détails de votre configuration VPN. Voici quelques méthodes qui peuvent vous aider à vérifier ce problème.

  • Utilisez des renifleurs de paquets des deux côtés du VPN pour détecter les paquets qui ont été transférés avec succès.

  • Si votre VPN autorise les commandes ping, vous pouvez tester l’envoi d’un paquet de taille complète.

    Exécutez une commande ping sur le VPN vers le NAS avec ces options. (Utilisez l’adresse IP de votre système de stockage à la place de la valeur <storage_IP>.)

    ping -M do -s 1472 -c 1 <storage_IP>

    Voici les options de la commande :

    • -M do : ne pas fragmenter.
    • -c 1 : envoyer un seul paquet.
    • -s 1472 : définir la taille de la charge utile sur 1 472 octets. Il s’agit de la taille maximale pour un paquet de 1 500 octets en tenant compte de la surcharge Ethernet.

    Une réponse réussie ressemble à ceci :

    PING 10.54.54.11 (10.54.54.11) 1472(1500) bytes of data.
1480 bytes from 10.54.54.11: icmp_seq=1 ttl=64 time=2.06 ms

    Si la commande ping échoue avec 1472 octets, il existe probablement un problème de taille des paquets.

Pour corriger le problème, vous devrez peut-être configurer le verrouillage MSS sur le VPN pour que le système distant détecte correctement la taille de trame maximale. Pour plus d’informations, consultez la documentation sur les paramètres IPsec/IKE des passerelles VPN.

Dans certains cas, la modification du paramètre MTU du cache HPC Azure sur 1400 peut être utile. Toutefois, si vous limitez la valeur MTU sur le cache, vous devez également limiter les paramètres MTU pour les clients et les systèmes de stockage principaux qui interagissent avec le cache. Pour plus d’informations, consultez Configurer des paramètres supplémentaires de cache HPC Azure.

Vérification du style de sécurité ACL

Certains systèmes NAS appliquent un style de sécurité hybride qui associe les listes de contrôle d’accès (ACL) à la sécurité POSIX ou UNIX traditionnelle.

Si votre système signale le style de sécurité UNIX ou POSIX sans inclure le sigle « ACL », ce problème ne vous concerne pas.

Dans le cas des systèmes qui utilisent des listes de contrôle d’accès, Azure HPC Cache doit effectuer un suivi de valeurs supplémentaires propres à l’utilisateur pour contrôler l’accès aux fichiers. Pour cela, il active un cache d’accès. Il n’existe pas de contrôle accessible à l’utilisateur permettant d’activer le cache d’accès, mais vous pouvez ouvrir un ticket de support pour demander qu’il soit activé pour les cibles de stockage concernées sur votre système de cache.

Étapes suivantes

Si vous rencontrez un problème non traité dans cet article, contactez le support pour obtenir l’aide d’experts.