Comprendre l’API REST d’objet Azure NetApp Files

Azure NetApp Files API REST d’objet permet d’accéder aux données stockées dans des volumes Azure NetApp Files. Cette fonctionnalité permet aux applications d’accéder au même jeu de données à l’aide de protocoles basés sur des fichiers (NFS/SMB) et d’API d’objet (compatibles S3) sans dupliquer ou migrer des données.

Ce modèle d’accès unifié permet aux données existantes basées sur des fichiers d’être utilisées directement dans les workflows d’analyse, d’IA et d’application modernes sans nécessiter de systèmes de stockage distincts, de solutions de traduction de données ou de copies de données.

Concepts clés

Buckets

Un compartiment représente une vue mappée d’un répertoire au sein d’un volume et sert de point d’entrée pour l’accès en fonction de l’objet.

• Les compartiments sont associés à des volumes.
• La suppression d’un volume supprime définitivement les compartiments qui lui sont associés.

Objets

Chaque fichier de la hiérarchie de répertoires mappé est représenté en tant qu’objet.

• Les noms d’objets sont dérivés de chemins d’accès de fichiers par rapport au répertoire mappé.
• Les opérations d’objet agissent directement sur le contenu du fichier.

Fonctionnement de l’API REST d’objet

Azure NetApp Files mappe un répertoire au sein d’un volume à un compartiment d’objets, ce qui permet aux applications et aux services qui utilisent des modèles d’accès basés sur des objets d’interagir avec les données basées sur des fichiers.

• Un chemin de répertoire, y compris la racine du volume, peut être exposé comme un compartiment.
• Les répertoires sont représentés sous forme de préfixes logiques dans un compartiment.
• Chaque fichier est représenté en tant qu’objet.
• Les chemins d’accès aux objets correspondent directement aux chemins du système de fichiers.
• Les limites de répertoire sont représentées à l’aide du / délimiteur.
• Les opérations d’objet peuvent lire, écrire et énumérer des données.
• Les opérations d’objet sont traduites en opérations de système de fichiers équivalentes.

Ce mappage permet aux applications d’utiliser des API objet pour interagir avec les données qui restent stockées en tant que fichiers.

Vue d’ensemble de l’architecture

Le diagramme suivant illustre l’accès simultané des fichiers et des objets au même jeu de données Azure NetApp Files :

Dans ce modèle :

• Les clients nas et les applications accèdent aux données à l’aide de NFS ou de SMB.
• Les clients d’objets accèdent aux mêmes données via l’API REST d’objet.
• Les services d’analytique et d’IA (tels que Azure Databricks, Microsoft Fabric et Azure AI services) s’intègrent à Azure NetApp Files à l’aide d’un accès basé sur l’objet.
• Les données restent stockées dans des volumes Azure NetApp Files.

Flux de travail d’accès aux objets

À un niveau élevé, l’accès à l’API REST d’objet suit ce flux :

• Un compartiment est créé à partir d’un répertoire dans un volume Azure NetApp Files.
• Les applications et services se connectent à l’aide d’API basées sur des objets.
• Les opérations d’objet (telles que la lecture, l’écriture et la liste) sont traduites en opérations de système de fichiers.
• L’API REST objet authentifie les demandes à l’aide de clés d’accès et évalue l’accès aux fichiers à l’aide de l’identité empruntée configurée.
• Les données sont retournées au client sans être dupliquées ou déplacées.

Ce flux de travail permet aux applications d’accéder aux données à l’aide d’API objet tandis que le stockage sous-jacent continue à fonctionner en tant que système de fichiers.

Sécurité et autorisations

L’API REST objet introduit des autorisations au niveau du compartiment, qui sont les contrôles d’accès principaux spécifiques à l’API REST d’objet. La configuration du compartiment définit également l’identité du système de fichiers qui est empruntée lors de l’accès aux données à l’aide de l’API REST d’objet. Les autorisations des fichiers NAS existantes continuent d’être appliquées en fonction de cette identité usurpée.

• Les autorisations de compartiment définissent si les clients d’API REST d’objet disposent d’un accès en lecture seule ou en lecture-écriture au compartiment.
• L’identité d’authentification et l’identité d’autorisation du système de fichiers sont des concepts distincts :
  • Les clés d’accès S3 servent à authentifier le client auprès du bucket.
  • L’identité impersonée configurée du compartiment détermine les fichiers et répertoires accessibles.
• Chaque compartiment est configuré avec une identité de système de fichiers d’emprunt :
  • Les volumes NFS utilisent un ID utilisateur (UID) et un ID de groupe (GID).
  • Les volumes SMB utilisent un compte d’utilisateur.
  • Les volumes à double protocole utilisent des comptes UID/GID ou utilisateur en fonction du style de sécurité configuré.
• L’API REST objet demande des données d’accès à l’aide de l’identité empruntée configurée. Les autorisations de fichier standard et les listes de contrôle d’accès sur le volume Azure NetApp Files continuent d’être appliquées pour cette identité.
• Les utilisateurs peuvent accéder uniquement aux fichiers et répertoires auxquels l’identité empruntée configurée dispose déjà de l’autorisation d’accéder via des autorisations NFS ou SMB standard. L’accès au compartiment n’accorde pas automatiquement l’accès à tous les objets du répertoire ou du volume mappé.
• Les listes de contrôle d’accès NAS existantes et les autorisations de fichier font autorité pour l’accès aux API REST d’objet. L’API REST d’objet ne contourne pas ou ne remplace pas les contrôles d’accès NAS existants.
• L’accès aux fichiers via les protocoles SMB et NFS continue d’utiliser leurs modèles d’authentification et d’autorisation existants sans modification.
• La communication sécurisée avec l’API REST objet nécessite des certificats TLS configurés pour le point de terminaison de l’API REST d’objet.

Opérations prises en charge

• ListBucket
• ListObjects / ListObjectsV2
• GetObject
• PutObject
• SupprimerObjet
• HeadObject

Scénarios courants

L’API REST objet active les nouveaux modèles de charge de travail pour Azure NetApp Files.

Analytique des données et IA

Une équipe d’ingénierie des données doit analyser un jeu de données volumineux déjà stocké dans un volume Azure NetApp Files. Au lieu de copier le jeu de données dans un service de stockage d’objets distinct, l’équipe se connecte directement à l’aide d’outils basés sur des objets et commence à traiter les données en place. Cette approche permet une intégration plus rapide des flux de travail d’analyse tout en réduisant la duplication du stockage.

Applications hybrides et modernisées

Les applications qui nécessitent à la fois un accès basé sur des fichiers et des objets peuvent fonctionner sur le même jeu de données sans conserver plusieurs copies. Cela permet la coexistence entre les applications héritées et les services modernes, ce qui permet une modernisation progressive sans perturber les charges de travail existantes.

Pipelines de traitement des données

Les pipelines de données peuvent ingérer, transformer et traiter des jeux de données à l’aide d’outils basés sur des objets pendant que les données restent stockées dans Azure NetApp Files. Cela prend en charge l’intégration à un large écosystème d’outils et de services qui s’appuient sur des modèles d’accès basés sur des objets.

Conditions requises et éléments à prendre en compte

Tenez compte des exigences et limitations suivantes lors de l’utilisation de l’API REST de l’objet Azure NetApp Files :

• Les compartiments sont liés aux volumes et sont supprimés lorsque le volume est supprimé.
• Les compartiments sont pris en charge avec l’accès sporadique activé ainsi que sur les volumes de grande taille.
• Les Buckets ne sont pas pris en charge sur les volumes de cache Azure NetApp Files.
• Les compartiments nécessitent un volume contenant déjà des données ; les volumes vides ne sont pas pris en charge.
• La gestion du cycle de vie des certificats est nécessaire pour maintenir un accès sécurisé au point de terminaison de l’API REST objet.
• Vous êtes responsable de la gestion du cycle de vie des certificats des compartiments.
• Activez la journalisation des diagnostics sur toutes les Azure Coffres de clés pour vous assurer que les pistes d’audit sont disponibles pour les enquêtes de sécurité.
• Configurez les listes de contrôle d’accès réseau (ACL) pour restreindre l’accès Azure Key Vault aux réseaux autorisés, y compris le réseau virtuel NetApp et les réseaux virtuels clients autorisés.
• Envisagez d’utiliser des Azure Key Vault distincts pour les certificats et les identifiants S3 afin de respecter les bonnes pratiques de sécurité fondées sur le principe du moindre privilège.
• Séparez, si possible, les stratégies d’accès d’Azure Key Vault pour les certificats et les identifiants S3 afin de maintenir des limites opérationnelles et de sécurité claires.

Étapes suivantes

• Configurer l’accès à l’API REST d’objet
• Se connecter à Azure Databricks
• Se connecter à OneLake
• Se connecter à un navigateur S3