Utiliser le stockage d’objets blob monté sur NFS avec Azure HPC Cache

Vous pouvez utiliser des conteneurs blob montés sur NFS avec Azure HPC Cache. En savoir plus sur la prise en charge du protocole NFS 3.0 dans le stockage Blob Azure sur le site de documentation du stockage Blob.

Azure HPC Cache utilise le stockage blob compatible NFS dans son type de cible de stockage ADLS-NFS. Ces cibles de stockage ressemblent aux cibles de stockage NFS standard, mais présentent également un certain chevauchement avec les cibles Blob Azure standard.

Cet article explique les stratégies et limitations que vous devez comprendre quand vous utilisez des cibles de stockage ADLS-NFS.

Vous devez également lire la documentation sur le blob NFS, notamment les sections qui décrivent des scénarios compatibles et incompatibles, et fournir des conseils de dépannage :

• Vue d’ensemble des fonctionnalités
• Considérations relatives aux performances
• Problèmes connus et limitations
• Guide de procédure et de résolution des problèmes

Comprendre les exigences de cohérence

HPC Cache nécessite une cohérence forte pour les cibles de stockage ADLS-NFS. Par défaut, le stockage d’objets blob compatible NFS ne met pas à jour strictement les métadonnées de fichier, ce qui empêche HPC Cache de comparer avec précision les versions de fichiers.

Pour contourner cette différence, Azure HPC Cache désactive automatiquement la mise en cache des attributs NFS sur n’importe quel conteneur d’objets blob compatible NFS utilisé comme cible de stockage.

Ce paramètre persiste pendant la durée de vie du conteneur, même si vous le supprimez du cache.

Précharger des données avec le protocole NFS

Sur un conteneur d’objets blob compatible NFS, un fichier ne peut être modifié que par le même protocole utilisé lors de sa création. Autrement dit, si vous utilisez l’API REST Azure pour remplir un conteneur, vous ne pouvez pas utiliser NFS pour mettre à jour ces fichiers. Étant donné qu’Azure HPC Cache utilise uniquement NFS, il ne peut modifier aucun fichier créé avec l’API REST Azure. (En savoir plus sur les problèmes connus liés aux API de stockage d’objets blob)

Ce n’est pas un problème pour le cache si votre conteneur est vide ou si les fichiers ont été créés à l’aide de NFS.

Si les fichiers de votre conteneur ont été créés avec l’API REST Blob Azure au lieu de NFS, Azure HPC Cache est limité à ces actions sur les fichiers d’origine :

• Répertoriez le fichier dans un répertoire.
• Lisez le fichier (et maintenez-le dans le cache pour les lectures suivantes).
• Supprimer les fichiers.
• Videz le fichier (tronquez-le sur 0).
• Enregistrez une copie du fichier. La copie est marquée comme un fichier NFS créé et peut être modifiée à l’aide de NFS.

Azure HPC Cache ne peut pas modifier le contenu d’un fichier créé à l’aide de REST. Cela signifie que le cache ne peut pas enregistrer un fichier modifié d’un client vers la cible de stockage.

Il est important de comprendre cette limitation, car elle peut entraîner des problèmes d’intégrité des données si vous utilisez des modèles d’utilisation de mise en cache en lecture/écriture sur des fichiers qui n’ont pas été créés avec NFS.

Écrire des scénarios de mise en cache

Ces modèles d’utilisation du cache incluent la mise en cache en écriture :

• Plus de 15 % d'écritures
• Supérieur à 15% d'opérations d'écriture, avec une vérification du serveur de support pour les modifications toutes les 30 secondes
• Plus de 15 % d'écritures, vérifie le serveur de sauvegarde pour les changements toutes les 60 secondes
• Plus de 15% d'écritures, écrire sur le serveur toutes les 30 secondes

Les modèles d’utilisation de la mise en cache en écriture doivent être utilisés uniquement sur les fichiers créés avec NFS.

Si vous essayez d’utiliser la mise en cache en écriture sur les fichiers créés par REST, vos modifications de fichier peuvent être perdues. Cela est dû au fait que le cache n’essaie pas d’enregistrer immédiatement les modifications de fichier dans le conteneur de stockage.

Voici comment essayer de mettre en cache les écritures dans les fichiers créés par REST met en danger les données :

1. Le cache accepte les modifications des clients et retourne un message de réussite sur chaque modification.

2. Le cache conserve le fichier modifié dans son stockage et attend des modifications supplémentaires.

3. Après un certain temps, le cache tente d’enregistrer le fichier modifié dans le conteneur back-end. À ce stade, il obtient un message d’erreur, car il tente d’écrire dans un fichier créé par REST avec NFS.

   Il est trop tard pour indiquer à l’ordinateur client que ses modifications n’ont pas été acceptées et que le cache n’a aucun moyen de mettre à jour le fichier d’origine. Ainsi, les changements des clients seront perdus.

Lire les scénarios de mise en cache

Les scénarios de mise en cache en lecture sont appropriés pour les fichiers créés avec NFS ou l’API REST d’objets blob Azure.

Ces modèles d’utilisation utilisent uniquement la mise en cache en lecture :

• Lire des écritures intensives et peu fréquentes
• Les clients écrivent dans la cible NFS, en contournant le cache
• Lecture intensive, vérification du serveur de soutien toutes les 3 heures

Vous pouvez utiliser ces modèles d’utilisation avec des fichiers créés par l’API REST ou par NFS. Toutes les écritures NFS envoyées à partir d’un client vers le conteneur principal échouent toujours, mais elles échouent immédiatement et retournent un message d’erreur au client.

Un flux de travail de mise en cache de lecture peut toujours impliquer des modifications de fichier, tant qu’elles ne sont pas mises en cache. Par exemple, les clients peuvent accéder aux fichiers à partir du conteneur, mais réécrire leurs modifications en tant que nouveau fichier, ou enregistrer des fichiers modifiés dans un autre emplacement.

Limitations du Gestionnaire de verrous réseau (NLM)

Les conteneurs d’objets blob compatibles NFS ne prennent pas en charge le Gestionnaire de verrous réseau (NLM), qui est un protocole NFS couramment utilisé pour protéger les fichiers contre les conflits.

Si votre flux de travail NFS a été initialement écrit pour les systèmes de stockage matériels, vos applications clientes peuvent inclure des requêtes NLM. Pour contourner cette limitation lors du déplacement de votre processus vers le stockage d’objets blob avec NFS, assurez-vous que vos clients désactivent NLM lorsqu’ils montent le cache.

Pour désactiver NLM, utilisez l’option -o nolock dans la commande de mount vos clients. Cette option empêche les clients de demander des verrous NLM et de recevoir des erreurs en réponse. L’option nolock est implémentée différemment dans différents systèmes d’exploitation ; consultez la documentation de votre système d’exploitation client (man 5 nfs) pour plus d’informations.

Simplifier les écritures dans des conteneurs compatibles NFS avec HPC Cache

Azure HPC Cache peut aider à améliorer les performances d’une charge de travail qui inclut l’écriture de modifications dans une cible de stockage ADLS-NFS.

L’une des limitations décrites dans l’article sur les performances des objets blob compatibles NFS est que ADLS-NFS stockage n’est pas très efficace pour remplacer les fichiers existants. Si vous utilisez Azure HPC Cache avec le stockage d’objets blob monté sur NFS, le cache gère les réécritures intermittentes lorsque les clients modifient un fichier actif. La latence d’écriture d’un fichier dans le conteneur principal est masquée des clients.

Gardez à l’esprit les limitations expliquées ci-dessus dans les données de préchargement avec le protocole NFS.

Étapes suivantes

• Découvrir les prérequis de la cible de stockage ADLS-NFS
• Créer un compte de stockage d’objets blob compatible NFS