api REST d’objet Azure NetApp Files pour l’intégration des données et de l’IA

Azure NetApp Files
Microsoft Fabric
Recherche Azure AI
Microsoft Foundry
Azure Machine Learning

Idées de solution

Cet article présente une idée de solution. Votre architecte cloud peut s’appuyer sur ces conseils pour visualiser les principaux composants d’une implémentation typique de cette architecture. Utilisez cet article comme point de départ pour concevoir une solution bien conçue qui répond aux exigences spécifiques de votre charge de travail.

Cette idée de solution décrit comment l'API REST Object d'Azure NetApp Files permet aux organisations d'utiliser les données de fichiers d'entreprise existantes pour l'analytique et l'IA sans devoir au préalable les copier dans un magasin d'objets distinct. Les applications compatibles avec Amazon S3 peuvent prendre en charge la recherche de documents et l’analyse assistée par l’IA, tandis que les flux de travail NFS et SMB existants continuent d’accéder à ces données. Éviter de créer une copie distincte des données sources peut réduire le temps nécessaire pour déployer des charges de travail analytiques, réduire les coûts de stockage en double et supprimer les pipelines de synchronisation que les équipes créeraient, surveilleraient et dépanneraient. Moins de référentiels de données source signifient également moins de copies à gouverner et à protéger. Cette approche permet une modernisation incrémentielle sans obliger les organisations à remplacer leurs applications existantes fondées sur des fichiers.

Architecture

Cette architecture se concentre sur l’intégration Microsoft Fabric à Azure NetApp Files via l’API REST Object. Le diagramme montre également Azure Databricks en tant que consommateur d’analyse alternatif des mêmes données Azure NetApp Files. Vous n’avez pas besoin de déployer les deux plateformes. Les applications existantes continuent d’accéder aux données via NFS ou SMB, en fonction de la configuration du volume et des exigences du client.

Les ressources de calcul Azure Databricks accèdent au point de terminaison de l’API REST d’objet Azure NetApp Files via des requêtes compatibles avec S3 à l’aide du connecteur Hadoop S3A. Ce chemin d'analyse alternatif n'utilise pas la passerelle de données locale ou Microsoft OneLake.

Les services d’IA en aval représentés dans le schéma sont donnés à titre d’exemple. L’intégration de l’ingestion n’est pas affichée.

Diagramme montrant Microsoft Fabric et Azure Databricks lisant des données Azure NetApp Files par le biais d’un point de terminaison d’API REST Object, ainsi que les écritures d’applications NFS et SMB.

Téléchargez un fichier Visio de cette architecture.

Flux de données

Les interactions numérotées suivantes décrivent le diagramme d’architecture. Les étapes 1 à 5 décrivent le parcours principal de Microsoft Fabric. L’étape 6 correspond à l’enrichissement facultatif des données en aval. L’étape 7 est un chemin d’analyse alternatif, et non une continuation du flux Fabric. Les flèches étiquetées HTTPS read indiquent les requêtes vers le point de terminaison de l’API REST Object ; les données demandées sont renvoyées au consommateur.

  1. Les applications écrivent les données de fichiers. Dans le sous-réseau Workload, la machine virtuelle d’application Linux écrit sur le partage de fichiers NFS, et la machine virtuelle d’application Windows écrit sur le partage de fichiers SMB. Azure NetApp Files héberge les deux partages dans le sous-réseau délégué.

  2. L’API REST de l’objet expose les données du fichier. Le point de terminaison du sous-réseau ANF délégué fournit un accès compatible S3 aux répertoires configurés sur les volumes Azure NetApp Files. Les connexions du point de terminaison aux partages NFS et SMB représentent l’accès aux données existantes, et non une copie dans un magasin d’objets distinct.

  3. Fabric accède aux données via un raccourci OneLake. Le raccourci référence les données Azure NetApp Files par l'intermédiaire d'une connexion qui utilise la machine virtuelle Windows exécutant la passerelle de données locale dans le sous-réseau OPDG (passerelle de données locale). Le raccourci OneLake est connecté à cette passerelle.

  4. La passerelle lit à partir de l’API REST Object. La passerelle utilise le peering entre le réseau virtuel OPDG et le réseau virtuel de charge de travail pour atteindre le point de terminaison. Le chemin de lecture HTTPS compatible S3 connecte la passerelle au point de terminaison, qui accède aux données de fichier référencées pour Fabric. Pour connaître les exigences de connexion, consultez Connecter OneLake à un volume Azure NetApp Files.

  5. Fabric traite et analyse les données. Les charges de travail Fabric prises en charge consomment les données par l'intermédiaire du raccourci. Par exemple, les notebooks lisent les fichiers référencés et écrivent des résultats dérivés dans des tables lakehouse pour l’analyse et la création de rapports dans Power BI. La boîte Fabric dans le diagramme montre ces fonctionnalités de traitement et d’analytique.

  6. Les services aval optionnels enrichissent les données. La flèche située sous Fabric conduit au groupe d’enrichissement des données, qui contient Microsoft Foundry, Azure Machine Learning et Recherche Azure AI. Cette étape représente le traitement en aval facultatif. Le diagramme ne montre pas l’ingestion ou l’orchestration nécessaires pour connecter ces services, et le raccourci OneLake n’établit pas ces intégrations.

  7. Sinon, Azure Databricks lit directement les données du fichier. Les nœuds de calcul du sous-réseau Databricks utilisent le connecteur Hadoop S3A pour envoyer des requêtes de lecture HTTPS au même point de terminaison de l’API REST d’objet via les réseaux virtuels appairés. Ce chemin remplace le chemin d’accès et de traitement de Fabric aux étapes 3 à 5. Il ne passe pas par la passerelle de données locale ou OneLake.

Choisissez l’emplacement du raccourci en fonction de la façon dont vous envisagez d’utiliser les données :

  • Tables Delta compatibles existantes. Créez un raccourci de table dans la section Tables de lakehouse, ciblant la table Delta complète, y compris son journal des transactions. Fabric reconnaît la cible en tant que table que vous pouvez interroger via Spark et le point de terminaison d’analytique SQL, tandis que les données sources restent sur Azure NetApp Files.
  • Fichiers pour l’accès direct ou le traitement. Créez des raccourcis dans la section Fichiers du lakehouse. Les charges de travail compatibles peuvent lire des fichiers Parquet, CSV et JSON autonomes, en plus des documents, sans d’abord copier les fichiers sources dans OneLake. Lorsque l’analytique en aval nécessite des tables lakehouse, transformez ou chargez les données sources dans des tables Delta dérivées dans OneLake.

Les fichiers Parquet autonomes ne sont pas automatiquement des tables Delta. Un raccourci dans Fichiers n'inscrit pas automatiquement sa cible en tant que table. Pour plus d’informations, voir Où placer des raccourcis dans une lakehouse.

Components

Les composants suivants prennent en charge l’architecture axée sur Fabric et l’alternative facultative Azure Databricks.

  • Azure NetApp Files est un service de stockage de fichiers entièrement géré basé sur la technologie NetApp. Dans cette architecture, il stocke le jeu de données d'entreprise et fournit un accès aux objets compatible avec NFS, SMB et S3 via l'API REST Object. Il fournit également des fonctionnalités d’instantané et de réplication.

  • Azure NetApp Files Object REST API expose les données de fichier existantes via une interface compatible S3. Dans cette architecture, cela permet aux applications d’analyse et d’IA compatibles d’accéder aux données sans créer d’abord une copie de stockage d’objets distincte. L’interface prend en charge un sous-ensemble d’opérations Amazon S3. Vérifiez que les opérations prises en charge répondent aux exigences de votre application avant de choisir cette intégration.

  • Microsoft Fabric est une plateforme d’analytique qui unifie le déplacement des données, le traitement des données, l’ingestion, la transformation, le traitement de flux via Real-Time Intelligence et la création de rapports. Dans cette architecture, il fournit la plateforme analytique permettant de traiter et d'analyser les données Azure NetApp Files via des raccourcis OneLake.

  • OneLake est le lac de données logique unifié pour Fabric. Dans cette architecture, les raccourcis OneLake rendent les données Azure NetApp Files référencées disponibles pour les charges de travail Fabric prises en charge.

  • Réseau virtuel Azure fournit une connectivité privée entre les ressources Azure dans cette architecture. Le peering de réseaux virtuels permet à la machine virtuelle de passerelle et aux ressources de calcul Azure Databricks facultatives d’atteindre le point de terminaison de l’API REST d’objet Azure NetApp Files.

  • Une passerelle de données locale connecte les raccourcis OneLake au point de terminaison du compartiment Azure NetApp Files. Malgré son nom, dans cette architecture, la passerelle s’exécute en mode standard sur une machine virtuelle Azure avec un système d’exploitation Windows pris en charge. Choisissez une image qui répond aux exigences d’installation de la passerelle. Les installations server Core et les conteneurs Windows ne sont pas pris en charge. La passerelle lance des connexions sortantes via Azure Relay pour communiquer avec Fabric. Aucune connexion entrante de Fabric n’est requise. Configurez votre pare-feu ou votre proxy pour autoriser les points de terminaison sortants décrits dans Ajuster les paramètres de communication pour la passerelle de données locale.

  • Azure Databricks est une plateforme d’analytique alternative facultative pour l’ingénierie des données et les charges de travail Machine Learning. Ses tâches Spark utilisent le connecteur Hadoop S3A configuré pour le point de terminaison de l’API REST Object pour accéder au jeu de données Azure NetApp Files au lieu d’utiliser le chemin d’intégration Fabric.

Alternatives

Cette architecture inclut plusieurs composants que vous pouvez remplacer par d'autres services ou approches Azure, en fonction des exigences fonctionnelles et non fonctionnelles de votre charge de travail. Considérez les alternatives suivantes et leurs compromis.

Storage

Tenez compte des exigences de protocole des applications et des performances mesurées lorsque vous choisissez entre Stockage Blob Azure et Azure NetApp Files :

  • Choisissez Stockage Blob quand les clients peuvent utiliser l'API REST Stockage Blob ou NFS 3.0 et ne nécessitent pas SMB ou NFS 4.1. Les deux interfaces peuvent accéder aux mêmes données. Le chemin d’accès NFS 3.0 du Stockage Blob est optimisé pour les charges de travail séquentielles à débit élevé et lourdes en lecture, où le débit importe plus que la faible latence.

  • Choisissez Azure NetApp Files quand les applications et les charges de travail d’analytique doivent accéder aux mêmes fichiers via SMB ou NFS 4.1 et l’API REST d’objet compatible S3, ou lorsque les applications de fichiers nécessitent des E/S aléatoires à faible latence. Pour les données déjà stockées dans Azure NetApp Files, l'API REST Object ajoute un accès analytique sans nécessiter la migration des applications sources ni des données.

Pour les deux options, mesurez la latence et le débit de bout en bout sous la charge d’application source et d’analytique simultanées. Les performances NFS ou SMB ne permettent pas de déterminer celles de l'API REST Object ou de Fabric. Testez donc le chemin d'accès prévu en fonction des exigences de la charge de travail. Comparez les coûts totaux, notamment les modifications d’application, la migration et toute duplication et synchronisation en cours. Pour une comparaison des protocoles et des charges de travail, consultez Comparer les services de stockage Azure.

Integration

Les travaux Azure Databricks peuvent utiliser le connecteur Hadoop S3A pour lire les données Azure NetApp Files via l'API REST Object, sans OneLake ni passerelle de données locale. Configurez la confiance TLS et stockez les informations d'identification de manière sécurisée. Validez également les opérations d'écriture requises avant de vous fier à la réécriture des données. Si vous avez besoin de scripts d’initialisation, utilisez des scripts au niveau du cluster stockés dans des volumes Unity Catalog sur des ressources de calcul prises en charge, en suivant les instructions actuelles Azure Databricks init-script.

Détails du scénario

Utilisez ce modèle lorsque le même jeu de données doit servir des applications qui attendent un système de fichiers monté et des services d’analyse ou d’IA qui s’attendent à une interface objet compatible S3.

Les applications exécutées sur des machines virtuelles ou dans des conteneurs peuvent continuer à utiliser Azure NetApp Files via NFS ou SMB. Par exemple, ils peuvent utiliser du code existant d’accès aux fichiers, des partages montés existants et des structures de répertoire existantes. L'API REST d'objet Azure NetApp Files mappe le répertoire racine d'un volume ou un sous-répertoire à un compartiment compatible S3 afin que les clients d'objets compatibles puissent accéder aux mêmes fichiers sous-jacents.

Cette approche est utile lorsque vous souhaitez ajouter des fonctionnalités d’analytique ou d’IA à des charges de travail basées sur des fichiers existantes sans modifier les applications sources pour utiliser le stockage d’objets. Les traitements en aval peuvent toujours créer des données dérivées, comme des jeux de données transformés, des index, des représentations vectorielles et des caches, selon les besoins.

Lorsque les clients de fichiers et d’objets accèdent aux mêmes données, tenez compte des différences en matière d’identité, d’autorisations, de verrouillage et d’exigences de cohérence applicative. Définissez la façon dont les producteurs signalent qu’un fichier ou un lot est terminé avant que les consommateurs d’objets le traitent. Les producteurs doivent finir d’écrire et fermer les fichiers avant de signaler qu’ils sont prêts, et laisser ces fichiers inchangés tant que les consommateurs les traitent. Testez ce transfert pour les écritures interrompues et les nouvelles tentatives de traitement.

Les modèles d'identité et d'autorisation diffèrent également selon les méthodes d'accès. Les autorisations de fichier par utilisateur d'origine ne sont pas automatiquement conservées dans Fabric. Configurez les autorisations Fabric pour les consommateurs prévus et assurez-vous que l’identité utilisée par l’API REST Object n’a accès qu’aux données sources requises. Pour plus d’informations, voir la section Sécurité.

Associez des répertoires à des compartiments distincts lorsque les consommateurs ont besoin de différents niveaux d'accès. La classification des données, leur conservation, les autorisations en aval et la gouvernance des données dérivées restent de la responsabilité de la charge de travail. Pour plus d’informations, consultez Créer un bucket.

Cas d’usage potentiels

Cette architecture peut prendre en charge les charges de travail qui doivent analyser des données structurées ou non structurées déjà stockées dans Azure NetApp Files. Les exemples suivants illustrent différentes façons dont Fabric peut consommer ces données.

Traitement du document

Les applications peuvent enregistrer des documents, des images ou d’autres fichiers non structurés dans Azure NetApp Files à l’aide de NFS ou de SMB. Un bloc-notes Fabric peut lire des fichiers finalisés à l’aide d’un raccourci OneLake et envoyer leur contenu à un service de traitement de documents, tel que Azure Document Intelligence, pour l’extraction. Stockez les données structurées résultantes dans des tables Lakehouse pour la validation, l’analyse et la création de rapports.

Pour obtenir des conseils sur l’intégration, consultez l’intégration de Document Intelligence via SynapseML.

Analytique des données

Les applications peuvent écrire des données structurées, telles que des fichiers CSV ou Parquet, dans un partage Azure NetApp Files. Les notebooks Fabric peuvent lire des fichiers finalisés à l’aide du raccourci OneLake, les combiner avec d’autres données du lakehouse et écrire les résultats dérivés dans des tables du lakehouse.

Ce modèle peut prendre en charge des scénarios tels que l’ingénierie et l’analyse de la qualité, l’analyse des données de capteur et les rapports opérationnels sans exiger que les applications sources modifient la façon dont elles stockent leurs fichiers.

Pour les jeux de données Delta compatibles existants, créez un raccourci OneLake dans la section Tables de lakehouse qui cible la table Delta complète, y compris son journal des transactions. Fabric peut ensuite reconnaître la cible en tant que table et les données sources peuvent rester sur Azure NetApp Files. Pour plus d'informations, consultez Où placer les raccourcis dans un lakehouse.

Recherche et récupération par IA

Les documents stockés sur Azure NetApp Files peuvent également servir de contenu source pour les charges de travail d’IA. Par exemple, un flux de travail de traitement peut lire des documents via le raccourci OneLake et les utiliser pour créer un index Recherche Azure AI pour la génération augmentée par récupération (RAG).

L’index de recherche et toutes les représentations vectorielles sont des données dérivées et sont stockés séparément des fichiers sources. Concevez le flux de travail pour conserver le contenu indexé synchronisé avec les mises à jour sources, les renommages et les suppressions. Appliquez également les contrôles d’accès appropriés lors de la récupération du contenu indexé, car les autorisations SMB et NFS d’origine ne deviennent pas automatiquement des autorisations de recherche par utilisateur.

Le même modèle peut être étendu à d’autres charges de travail IA. Par exemple, Fabric notebooks peuvent préparer des jeux de données à partir de fichiers sources et stocker les données préparées dans OneLake pour leur consommation par Azure Machine Learning. Pour connaître les options d’intégration et les limitations, consultez Intégrer OneLake à Azure Machine Learning.

Considerations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework. Pour obtenir des conseils supplémentaires, consultez les recommandations du Well-Architected Framework pour Azure NetApp Files.

Reliability

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour plus d'informations, veuillez consulter la liste de vérification de la conception pour la fiabilité.

Azure NetApp Files s’exécute sur une infrastructure bare metal à tolérance de pannes basée sur ONTAP et fournit un SLA de haute disponibilité. Pour une protection supplémentaire contre les pannes régionales ou de zone de disponibilité, vous pouvez éventuellement configurer la réplication interzone ou interrégion. Cette réplication est asynchrone et nécessite un basculement initié par le client vers le volume de destination. Choisissez l’option de réplication et la planification en fonction des objectifs de récupération de votre charge de travail. Pour plus d’informations, consultez Fiabilité d’Azure NetApp Files.

Le partage d'un même jeu de données fait également de la disponibilité du stockage une dépendance commune aux applications de fichiers et à l'analytique. Ces fonctionnalités de stockage ne garantissent pas la disponibilité de bout en bout de la passerelle, du pipeline d'indexation ou des applications consommatrices. Aligner les objectifs de récupération avec la charge de travail complète, notamment la passerelle, le traitement en aval et les données dérivées.

Une machine virtuelle de passerelle unique est un point de défaillance unique pour le chemin d’intégration Fabric. Pour les charges de travail critiques pour l’entreprise, déployez au moins deux membres de passerelle sur des machines virtuelles distinctes dans un cluster de passerelle. Vérifiez que chaque membre peut accéder au point de terminaison de l’Object REST API et établir les connexions sortantes requises. Testez le comportement de la charge de travail lorsqu’un membre de la passerelle devient indisponible.

  • La récupération des fichiers et des volumes est prise en charge grâce à des instantanés économes en espace et à un instant donné. Les équipes peuvent restaurer un fichier individuel, rétablir un volume complet ou créer un nouveau volume à partir d'un point de récupération après une suppression accidentelle, une corruption ou l'échec d'un processus analytique. Pour connaître les opérations de récupération disponibles, consultez la protection des données basée sur des instantanés d’Azure NetApp Files.

Sécurité

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour plus d’informations, consultez liste de vérification pour la révision de conception concernant la sécurité.

La gestion de moins de copies de données sources peut réduire le nombre de dépôts à protéger. Azure NetApp Files chiffre les données au repos et l’API REST objet utilise TLS pour protéger les données en transit. Les autorisations d’accès aux fichiers dépendent du protocole :

  • Les clients SMB et NFS continuent d’utiliser leurs modèles d’authentification et d’autorisation existants. Les listes de contrôle d’accès NTFS existantes, les autorisations NFS et les règles de mappage d’identité restent en vigueur pour ces clients.

  • Les clients d’API REST objet s’authentifient à l’aide d’une clé d’accès S3. Les autorisations du bucket définissent si le client dispose d’un accès en lecture seule ou en lecture-écriture dans le répertoire mappé. Les requêtes sur les objets ne comprennent pas l'identité de l'utilisateur SMB, NFS ou en aval. Azure NetApp Files exécute chaque opération sur un objet en utilisant l'identité du système de fichiers usurpée configurée pour le compartiment. Les autorisations de fichier existantes et les listes de contrôle d’accès sont évaluées uniquement par rapport à cette identité.

    L’identité de système de fichiers usurpée est un ID d’utilisateur (UID) et un ID de groupe (GID) pour les volumes NFS, ou un compte d’utilisateur pour les volumes SMB. Les volumes à double protocole utilisent le type d’identité qui correspond à leur style de sécurité configuré. Cette identité détermine les autorisations d’accès aux fichiers. La clé d’accès S3 authentifie le client d’objet. Pour plus d’informations, consultez La sécurité et les autorisations de l’API REST objet.

  • Un raccourci compatible OneLake S3 s’authentifie auprès du bucket à l’aide d’un ID de clé d’accès et d’une clé d’accès secrète. Les listes de contrôle d’accès NTFS sources, les autorisations NFS et les identités de propriétaire de fichiers individuelles ne sont pas copiées ou mappées dans OneLake. Les utilisateurs Fabric sont autorisés via les autorisations OneLake et Fabric. Ils ne peuvent accéder qu'au contenu exposé par le raccourci via le compartiment et l'identité usurpée de celui-ci, mais OneLake n'applique pas les autorisations de fichiers d'origine propres à chaque utilisateur. OAuth basé sur Microsoft Entra, les principaux du service et RoleArn ne sont pas pris en charge pour ce type de raccourci.

    Par exemple, un utilisateur Fabric peut être en mesure de lire un document via le raccourci même si son compte SMB personnel ne peut pas le lire directement, à condition que les autorisations Fabric autorisent cet accès et que l'identité usurpée du compartiment puisse lire le document. Avant d’exposer un répertoire, vérifiez que l’audience Fabric prévue est autorisée à accéder à son contenu.

Configurez l'identité usurpée du compartiment en lui accordant uniquement les autorisations sur la source requises par la charge de travail. Limitez l'accès au raccourci et au lakehouse. Utilisez le flux de travail des certificats et le stockage d’informations d’identification basés sur Azure Key Vault pour gérer les certificats TLS et les clés d’accès S3. Définissez et testez une procédure de rotation coordonnant les modifications des certificats et des informations d'identification avec les mises à jour des connexions Fabric et des autres consommateurs. La génération de nouvelles informations d’identification de bucket invalide immédiatement la paire existante. Prévoyez donc une interruption pendant que vous mettez à jour les consommateurs et vérifiez l’accès après la rotation.

Si vous utilisez un certificat TLS auto-signé, vérifiez que chaque hôte de passerelle lui fait confiance. Pour plus d’informations, consultez les prérequis de la passerelle OneLake.

La sécurité et la conformité dépendent de la configuration du stockage, de l’accès et des services en aval. Incluez le traitement en aval et les données dérivées dans votre étendue de gouvernance et de conformité. Les exigences telles que RGPD et HIPAA s’appliquent à la charge de travail complète, le cas échéant. Pour plus d’informations, consultez Sécurité et autorisations de l’API REST d’objet et Créer un raccourci compatible Avec Amazon S3 dans OneLake.

Optimisation des coûts

L’optimisation des coûts se concentre sur les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez la liste de vérification de conception pour l’optimisation des coûts.

Éviter une copie distincte des données sources peut réduire les coûts de stockage en double et de synchronisation. Équilibrez ces économies par rapport aux coûts de capacité et de performances de Azure NetApp Files, au calcul de passerelle, à la capacité de Fabric et au traitement et au stockage en aval.

Cet exemple d’estimation de la tarification comprend un pool de capacités standard Azure NetApp Files 1 Tio, une machine virtuelle Windows D8s_v5 pour la passerelle de données locale, deux disques managés P10 128 Gio, une passerelle NAT avec une adresse IP publique et un traitement des données sortantes, une capacité Fabric F2 et 100 Go de stockage OneLake natif.

La configuration à passerelle unique n’est pas hautement disponible. Les coûts facultatifs liés à Azure AI Search, aux services de génération d'incorporations et à Azure Databricks ne sont pas inclus. Ajustez les ressources pour la capacité, la mise en réseau et les exigences de disponibilité de votre charge de travail.

  • Accès à froid : Déplacez les blocs de données inactifs, y compris ceux des instantanés, vers un stockage moins coûteux tout en conservant l'accès aux fichiers et aux objets. Évaluez les frais de récupération, la latence et les modifications du débit de traitement spécifiques au niveau de service par rapport au modèle d’accès de la charge de travail.

  • Niveaux de service et dimensionnement appropriés : Choisissez un niveau de service Azure NetApp Files qui correspond aux exigences de capacité et de débit du jeu de données. Le niveau de service flexible vous permet de provisionner la capacité et le débit du pool indépendamment. Examinez la capacité facturable du pool et le débit à mesure que la demande évolue afin d'éviter un surdimensionnement persistant.

Excellence opérationnelle

L’excellence opérationnelle couvre les processus opérationnels qui déploient une application et la maintiennent en production. Pour plus d’informations, consultez Liste de vérification de la conception pour l'excellence opérationnelle.

Les raccourcis OneLake réduisent la complexité opérationnelle en évitant un pipeline qui gère une copie distincte des données sources pour l’analytique. Sans pipeline de copie distinct, les équipes n’ont pas besoin de planifier des travaux de copie, de récupérer à partir d’échecs de transfert ou de rapprocher les données sources et copiées dans le cadre des opérations de routine.

Les équipes de l’application source et d’analyse doivent coordonner les modifications et la gestion des incidents pour le jeu de données partagé Azure NetApp Files. Définissez les responsabilités en matière de surveillance, de gestion des échecs de traitement et de gestion des informations d'identification et des certificats de l'API REST Object.

Surveillez les performances de stockage, de passerelle et de Fabric pour identifier les contraintes et ajuster la capacité ou le débit :

  • Utilisez Azure Monitor pour suivre le débit de lecture et d’écriture du volume, les E/S par seconde de lecture et d’écriture, d’autres E/S par seconde, la latence moyenne de lecture et d’écriture, la consommation de capacité et l’indicateur de limite de débit atteinte. Alertez sur les augmentations soutenues de latence, la limitation répétée de QoS et les seuils de capacité plutôt que les pics isolés ; les métriques d’Azure NetApp Files sont agrégées sur des intervalles et la latence de stockage n'inclut pas chaque composant REST côté client.

  • Mettre en corrélation les métriques de stockage avec des mesures côté client telles que les percentiles de latence des requêtes, la taille des objets, la concurrence, les tentatives de relance, les codes d’état HTTP, le processeur, la mémoire et le débit réseau. Cela permet de distinguer une limite de débit du volume d'un client de calcul sous-dimensionné, de paramètres de kit de développement logiciel (SDK) inefficaces, de la surcharge liée aux petits objets ou de la distance réseau.

  • Surveillez le processeur, la mémoire, l’espace disque disponible et le débit réseau de chaque machine virtuelle de passerelle, ainsi que les erreurs de passerelle et les temps d’exécution des charges de travail. Configurez des alertes pour une pression soutenue des ressources et un espace disque faible, à l’aide de seuils établis pendant les tests de charge de travail représentatifs. Utilisez les journaux de diagnostic de passerelle lors de la résolution des erreurs ou de l’accès lent. Surveillez la machine virtuelle et le réseau séparément, car les diagnostics de passerelle ne fournissent pas une couverture complète de l’infrastructure.

  • Surveillez l’utilisation de la capacité Fabric et le throttling avec l’application Fabric Capacity Metrics app. Configurez des notifications d'utilisation de la capacité pour les administrateurs responsables. Mettre en corrélation l’utilisation de la capacité avec les mesures de passerelle et de stockage pour déterminer si les retards proviennent de l’accès source ou du traitement Fabric avant de changer de capacité.

Efficacité des performances

L’efficacité des performances fait référence à la capacité de votre charge de travail à mettre à l’échelle pour répondre efficacement aux demandes des utilisateurs. Pour en savoir plus, consultez Liste de vérification de l'examen de la conception pour l'efficacité des performances

Azure NetApp Files peut prendre en charge à la fois les applications NFS ou SMB sensibles à la latence et les consommateurs analytiques ou d'IA compatibles avec S3 utilisant le même jeu de données. Conserver les données sources sur un volume peut supprimer l’étape de copie qui retarderait sinon l’indexation, l’entraînement ou le traitement par lots et consommerait la bande passante client, réseau et de stockage de destination.

La latence de stockage inférieure à la milliseconde sur les niveaux de service pris en charge d’Azure NetApp Files concerne plus particulièrement les charges de travail NFS et SMB. Cela ne garantit pas une latence de bout en bout pour les requêtes HTTPS adressées à l'API REST Object. Testez le chemin d’accès compatible S3 avec des objets représentatifs et une concurrence avant de définir un objectif de latence.

  • Dimensionnement du stockage : Dimensionnez le débit en fonction de la demande combinée des applications de fichiers et des consommateurs d'objets. La QoS automatique lie le débit du volume au quota de volume. La qualité de service (QoS) manuelle permet une allocation distincte dans les limites du budget de débit du pool.. Évaluez les performances à l'aide de charges de travail représentatives avant de les ajuster.

  • Dimensionnement de la passerelle : Dimensionner les machines virtuelles de passerelle pour la demande combinée de charges de travail qui accèdent à Azure NetApp Files via des raccourcis OneLake. Utilisez des conseils de dimensionnement et de mise à l’échelle de passerelle comme point de départ. Validez le dimensionnement avec des volumes de données représentatifs et des accès simultanés via les raccourcis. Mesurez le processeur de passerelle, la mémoire et le débit réseau en même temps que les temps d’achèvement de la charge de travail pour déterminer s’il faut augmenter les ressources de machine virtuelle ou ajouter des membres de passerelle.

  • Dimensionnement de la capacité Fabric : Dimensionnez la capacité Fabric pour la charge de travail combinée de traitement et de création de rapports, y compris Power BI. Suivez les recommandations du Guide de planification de la capacité Fabric pour estimer la capacité initiale, effectuer des tests avec un projet pilote représentatif et ajuster la capacité en fonction de l'utilisation mesurée et de la limitation du débit.

  • Placez les ressources de calcul à proximité du volume, dimensionnez correctement le réseau client et effectuez des tests avec la charge de travail réelle. Augmentez le parallélisme et utilisez des requêtes suffisamment volumineuses pour l'analytique séquentielle, mais limitez la concurrence lorsque la latence ou le nombre d'erreurs augmente. Pour NFS ou SMB, vérifiez les paramètres de montage, du protocole et de l’application. Pour REST, vérifiez que les opérations d'API requises par le client sont prises en charge et testez la réutilisation des connexions, le comportement des chargements, les nouvelles tentatives et l'énumération des objets.

Validez le débit et la latence de bout en bout sous charge concurrente et équilibrez la demande d’analyse avec les exigences de performances de l’application source.

Contributors

Microsoft maintient cet article. Les contributeurs suivants ont écrit cet article.

Auteurs principaux :

Autres contributeurs :

  • Heather Grandy | Ingénieur de solution senior, plateformes de données, Microsoft

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes