Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Le stockage Blob Azure prend désormais en charge le protocole NFS (Network File System) 3.0. Cette prise en charge assure la compatibilité du système de fichiers Linux au niveau du stockage des objets, et permet aux clients Linux de monter un conteneur dans Stockage Blob à partir d’une machine virtuelle Azure ou d’un ordinateur local.
Il a toujours été difficile d’exécuter des charges de travail héritées à grande échelle, telles que HPC (High Performance Computing), dans le cloud. L’une des raisons est que les applications utilisent souvent des protocoles de fichiers traditionnels tels que le système de fichiers réseau (NFS) pour accéder aux données. En outre, les services de stockage cloud natifs sont axés sur le stockage d’objets qui ont un espace de noms plat et des métadonnées étendues, plutôt que des systèmes de fichiers qui fournissent un espace de noms hiérarchique et des opérations de métadonnées efficaces.
Le Stockage Blob prend désormais en charge un espace de noms hiérarchique et, lorsqu’il est associé à la prise en charge du protocole NFS 3.0, Azure facilite grandement l’exécution d’applications héritées par-dessus le stockage d’objets cloud à grande échelle.
Applications et charges de travail adaptées à l’utilisation de NFS 3.0 avec Stockage Blob
La fonctionnalité de protocole NFS 3.0 est optimisée pour les charges de travail à haut débit, à grande échelle et lourdes en lecture avec des E/S séquentielles. Il est idéal pour les scénarios impliquant plusieurs lecteurs et de nombreux threads où le débit est plus critique que la faible latence. Voici quelques exemples courants :
High-Performance Computing (HPC) : les travaux HPC impliquent souvent des milliers de cœurs lisant simultanément les mêmes jeux de données volumineux. La fonctionnalité de protocole NFS 3.0 utilise le débit de stockage d’objets pour éliminer les goulots d’étranglement traditionnels du serveur de fichiers. Exemples :
Séquençage génomique : traitement de jeux de données massifs d'ADN.
Modélisation des risques financiers : simulations Monte Carlo sur les données historiques.
Analyse sismique : données géologiques pour l’exploration du pétrole et du gaz.
Prévisions météorologiques : modélisation des données atmosphériques pour la prévision du climat et des tempêtes.
Big Data &Analytics (Data Lakes) : de nombreux outils d’analyse nécessitent des répertoires hiérarchiques. BlobNFS (via Azure Data Lake Storage Gen2) fournit cette structure tout en prenant en charge les protocoles de fichiers standard. Exemples :
Machine Learning : Alimentation des données d’apprentissage sur des clusters GPU à l’aide d’E/S de fichiers standard.
Log Analytics : Agrégation des logs à partir de milliers de sources.
Advanced Driver Assistance Systems (ADAS) : les flux de travail ADAS produisent des pétaoctets de données de capteur séquentiel( telles que les nuages de point LiDAR et les flux de caméra haute résolution) qui doivent être ingérés efficacement et analysés à grande échelle pour la simulation et l’entraînement du modèle. Exemple :
- Stockage des analyses LiDAR brutes et des flux vidéo à plusieurs caméras à partir de véhicules de test autonomes à l’aide de NFS 3.0, puis exécution de simulations de relecture à grande échelle sur des milliers de nœuds de calcul pour valider les algorithmes de perception.
Media & Entertainment - Les batteries de serveurs de rendu ont besoin d’un accès efficace aux bibliothèques de ressources volumineuses. NFS 3.0 sur blob fournit une interface de fichiers pour les outils de rendu legacy qui attendent des chemins de fichier. Exemples :
Rendu vidéo : nœuds distribués lisant les éléments d'origine.
Transcodage : conversion de fichiers vidéo bruts volumineux en formats de streaming.
Sauvegarde de base de données - cette fonctionnalité offre une cible NFS 3.0 économique et haute performance sans connecteurs complexes ni captures instantanées coûteuses. Exemples :
- Oracle RMAN peut écrire des pièces de sauvegarde volumineuses directement pour l’archivage à long terme et activer la restauration directe à partir de n’importe quelle machine virtuelle Linux montée sur NFS.
Quand ne pas utiliser NFS 3.0 avec le stockage Blob
Évitez les partages de fichiers à usage général ou les charges de travail transactionnelles en raison des caractéristiques de stockage d’objets :
| Type de charge de travail | Raison | Meilleure alternative |
|---|---|---|
| Bases de données transactionnelles | Nécessite un verrouillage granulaire, une latence de sous-milliseconde et des écritures aléatoires fréquentes. | Disques managés ou Azure NetApp Files ou Azure Files |
| Modification de fichier sur place | La modification de fichiers force la réécriture complète des blobs de données, rendant les opérations moins efficaces. | Azure Files |
NFS 3.0 et l’espace de noms hiérarchique
La prise en charge du protocole NFS 3.0 nécessite que les objets blobs soient organisés dans un espace de noms hiérarchique. Vous pouvez activer un espace de noms hiérarchique lorsque vous créez un compte de stockage. La possibilité d’utiliser un espace de noms hiérarchique a été introduite par Azure Data Lake Storage. Il organise les objets (fichiers) selon une hiérarchie de répertoires et sous-répertoires, de la même façon que le système de fichiers sur votre ordinateur. L’espace de noms hiérarchique est mis à l’échelle de façon linéaire, et ne dégrade pas la capacité ou les performances des données. Différents protocoles s’étendent à partir de l’espace de noms hiérarchique. Le protocole NFS 3.0 est l’un des protocoles disponibles.
Données stockées en tant qu’objets blob de blocs
Lorsque votre application effectue une requête à l’aide du protocole NFS 3.0, cette requête est traduite en une combinaison d’opérations d’objets blob de blocs. Par exemple, les requêtes NFS 3.0 de lecture RPC (Remote Procedure Call) sont traduites en opérations Get Blob. Les requêtes d’écriture RPC NFS 3.0 sont traduites en une combinaison d’opérations Get Block List, Put Block et Put Block List.
Les objets blob de blocs sont optimisés pour traiter efficacement de grandes quantités de données à lecture intensive. Les objets blob de blocs sont composés de blocs. Chaque bloc est identifié par un ID de bloc. Un objet blob de blocs peut inclure jusqu’à 50 000 blocs. Chaque bloc dans un objet blob de blocs peut avoir une taille différente, jusqu’à la taille maximale autorisée pour la version de service utilisée par votre compte.
Workflow général : Monter un conteneur de compte de stockage
Vos clients Linux peuvent monter un conteneur dans le Stockage Blob à partir d’une machine virtuelle Azure ou d’un ordinateur local. Pour monter un conteneur de stockage, vous devez suivre les étapes suivantes.
Créez un réseau virtuel Azure (Vnet).
Configurez la sécurité du réseau.
Créez et configurez un compte de stockage qui accepte le trafic uniquement à partir du réseau virtuel.
Créez un conteneur dans le compte de stockage.
Montez le conteneur.
Pour obtenir des instructions pas à pas, consultez Monter le stockage Blob à l’aide du protocole NFS (Network File System) 3.0.
Sécurité du réseau
Le trafic doit provenir d’un réseau virtuel. Un réseau virtuel permet aux clients de se connecter en toute sécurité à votre compte de stockage. La seule façon de sécuriser les données dans votre compte consiste à utiliser un réseau virtuel et d’autres paramètres de sécurité réseau. Tout autre outil utilisé pour sécuriser les données, y compris l’autorisation de clé de compte, la sécurité Microsoft Entra et les listes de contrôle d’accès (ACL) ne peut pas être utilisé pour autoriser une demande NFS 3.0.
Pour en savoir plus, consultez les recommandations de sécurité réseau pour le stockage Blob.
Connexions réseau prises en charge
Un client peut se connecter via un point de terminaison public ou un point de terminaison privé à partir de l’un des emplacements réseau suivants :
Le réseau virtuel que vous configurez pour votre compte de stockage.
Dans cet article, nous ferons référence à ce réseau virtuel en tant que réseau virtuel principal. Pour en savoir plus, consultez Autoriser l'accès à partir d'un réseau virtuel.
Un réseau virtuel associé qui se trouve dans la même région que le réseau virtuel principal.
Vous devrez configurer votre compte de stockage pour autoriser l’accès à ce réseau virtuel associé. Pour en savoir plus, consultez Autoriser l'accès à partir d'un réseau virtuel.
Un réseau local connecté à votre réseau virtuel principal à l’aide d'une passerelle VPN ou d’une passerelle ExpressRoute.
Pour en savoir plus, consultez Configuration de l’accès à partir de réseaux locaux.
Un réseau local connecté à un réseau associé.
Cette opération peut être effectuée avec une passerelle VPN ou une passerelle ExpressRoute ainsi qu’avec le transit de la passerelle.
Important
Le protocole NFS 3.0 utilise les ports 111 et 2048. Si vous vous connectez à partir d’un réseau local, assurez-vous que votre client autorise les communications sortantes via ces ports. Si vous avez accordé l’accès à des réseaux virtuels spécifiques, assurez-vous que tous les groupes de sécurité réseau associés à ces réseaux virtuels ne contiennent pas de règles de sécurité qui bloquent les communications entrantes via ces ports.
Problèmes connus et limitations
Consultez l’article Problèmes connus pour obtenir une liste complète des problèmes et limitations avec la version actuelle du support NFS 3.0.
Tarifs
Consultez la page Tarifs du stockage Blob Azure pour connaitre le coût du stockage et de la transaction des données.