Déployer SAS Grid 9.4 sur Azure NetApp Files

Les logiciels d’analyse SAS fournissent une suite de services et d’outils permettant d’extraire des insights à partir de données afin de prendre des décisions intelligentes. Les solutions SAS couvrent plusieurs domaines : l’analytique, l’intelligence artificielle, le décisionnel, l’intelligence client, la gestion des données ainsi que le renseignement sur la fraude et la sécurité.

Si vous déployez SAS Grid sur Azure, Azure NetApp Files constitue une option de stockage principal viable. Quand vous utilisez les services scalables d’Azure NetApp Files, vous pouvez augmenter ou réduire les allocations de stockage à tout moment sans interrompre les services. Vous pouvez également ajuster dynamiquement le niveau du service de stockage en fonction des performances requises.

SAS offre les principales plateformes suivantes, que Microsoft a validées :

• SAS Grid 9.4
• SAS Viya

SAS Grid 9.4 a été validé sur Linux.

Cet article fournit des informations générales sur l’exécution de SAS Grid 9.4 sur Azure, avec Azure NetApp Files pour le stockage SASDATA. Il fournit également des conseils sur les options de stockage pour SASWORK. Ces directives partent du principe que vous hébergez votre propre solution SAS sur Azure, dans votre propre locataire. SAS ne fournit pas d’hébergement pour SAS Grid sur Azure.

Architecture

Téléchargez un fichier PowerPoint avec tous les diagrammes relatifs à cet article.

Dataflow

Le niveau de calcul utilise des volumes SASDATA (et éventuellement SASWORK) pour partager des données sur la grille. SASDATA est un volume connecté à NFS sur Azure NetApp Files.

• Un nœud de calcul lit les données d’entrée et écrit les résultats dans SASDATA.
• Une partie subséquente du travail d’analytique peut être exécutée par un autre nœud dans le niveau de calcul. Il utilise la même procédure pour obtenir et stocker les informations qu’il doit traiter.

Cas d’usage potentiels

Un déploiement SAS Grid scalable qui utilise Azure NetApp Files prend en charge les cas d’usage suivants :

• Analytique financière
• Détection des fraudes
• Suivi et protection des espèces menacées
• Science et médecine
• Analytique et IA

Exigences liées aux performances du stockage

Pour les déploiements SAS 9.4 (SAS Grid ou SAS Analytics Pro) sur Azure, Azure NetApp Files constitue une option de stockage principal viable pour les clusters SAS Grid de taille limitée. SAS recommande un débit de 100 Mio/s par cœur physique. Compte tenu de cette recommandation, les clusters SAS Grid utilisant un volume Azure NetApp Files pour SASDATA (fichiers de données SAS persistants) sont scalables jusqu’à 32-48 cœurs physiques sur deux machines virtuelles Azure ou plus. Les tailles de cluster SAS sont basées sur la contrainte architecturale d’un seul espace de noms SASDATA par cluster SAS et sur la bande passante disponible d’un volume Azure NetApp Files unique. Les instructions sur le nombre de cœurs seront revisitées à mesure que l’infrastructure Azure (calcul, réseau et bande passante de stockage par système de fichiers) augmente au fil du temps.

Attentes en matière de performances d’un volume Azure NetApp Files

Un volume Azure NetApp Files unique peut gérer jusqu’à 4 500 Mio/s de lectures et 1 500 Mio/s d’écritures. Pour un type d’instance Azure avec une bande passante de sortie suffisante, une seule machine virtuelle peut consommer toute la bande passante en écriture d’un volume Azure NetApp Files unique. Toutefois, seule la plus grande machine virtuelle unique peut consommer toute la bande passante de lecture d’un volume unique.

SASDATA, la principale charge de travail partagée de SAS 9.4, a un rapport lecture/écriture de 80:20. Voici les chiffres importants par volume pour une charge de travail 80:20 avec des lectures/écritures de 64 Kio :

• 2 400 Mio/s de débit de lecture et 600 Mio/s de débit d’écriture simultanément (environ 3 000 Mio/s en mode combiné).

Pour plus d’informations, consultez Benchmarks de performances Azure NetApp Files pour Linux.

Recommandations de capacité

La calculatrice de performances Azure NetApp Files peut fournir des conseils sur le dimensionnement des volumes SASDATA.

Il est important de choisir un niveau de service approprié pour les raisons suivantes :

• La bande passante du volume est basée sur la capacité du volume.
• Le coût de la capacité est basé sur le niveau de service.
• Votre choix du niveau de service est basé sur les besoins en capacité et en bande passante.

Dans la calculatrice, sélectionnez Avancé, sélectionnez une région, puis entrez les valeurs suivantes.

• Taille du volume : capacité souhaitée
• Débit : débit souhaité, la recommandation étant de 100 Mio/s par cœur
• Pourcentage de lecture : 80 %
• IOPS : 0
• Taille d’E/S : 64 Kio (mode séquentiel)

La sortie en bas de l’écran fournit les exigences de capacité recommandées à chaque niveau de service et le coût par mois en fonction du prix établi pour la région sélectionnée :

• Débit. Bande passante du volume, en fonction de la combinaison des charges de travail. Pour une charge de travail de lecture séquentielle de 80 % et 64 Kio, 3 096 Mio/s est le maximum attendu.
• E/S. Nombre d’IOPS que le volume fournit au débit spécifié.
• Taille du volume. Capacité dont a besoin le volume aux niveaux de service donnés pour atteindre le débit requis. La capacité de volume (signalée en Gio) peut être égale ou inférieure à la taille du pool de capacité. Cette recommandation repose sur l’hypothèse que vous utilisez des types de pools de capacité QoS automatiques. Pour optimiser davantage la capacité par rapport à la distribution du débit sur les volumes au sein d’un pool de capacité, envisagez d’utiliser des types de pools de capacité QoS manuels.
• Taille du pool de capacité. Taille du pool. La capacité d’un volume est issue d’un pool de capacité. Les pools de capacité sont dimensionnés par incréments de 1 Tio.
• Coût du pool de capacité (USD/mois). Coût mensuel du pool de capacité pour une taille et un niveau de service donnés.
• Coût indicatif du volume (USD/mois). Coût mensuel de la capacité du volume à la capacité spécifiée. Les frais sont basés sur les tailles de pool de capacité allouées. Le mémo (« showback ») du volume indique la quantité de volume.

Contrôlez les coûts selon vos besoins en utilisant la mise en forme du volume dans Azure NetApp Files. Deux options dynamiques sont disponibles pour influencer les performances et les coûts :

• Redimensionner dynamiquement un volume et un pool de capacité
• Changer dynamiquement le niveau de service d’un volume

Découvrez-en plus sur le modèle de coût Azure NetApp Files.

Protection des données

Azure NetApp Files utilise des instantanés pour vous aider à protéger vos données. Les instantanés fournissent des images peu encombrantes, cohérentes et quasi immédiates de vos volumes Azure NetApp Files. Vous pouvez créer des instantanés manuellement à tout moment ou les planifier à l’aide d’une stratégie d’instantané sur le volume.

Utilisez une stratégie d’instantané pour ajouter une protection des données automatisée à vos volumes. Vous pouvez restaurer rapidement des instantanés sur place en utilisant la restauration d’instantané. Vous pouvez aussi restaurer un instantané sur un nouveau volume pour récupérer rapidement des données. Vous pouvez également utiliser la fonctionnalité de restauration sur un nouveau volume pour fournir aux environnements de test/développement des données actuelles.

Pour bénéficier de niveaux supplémentaires de protection des données, vous pouvez recourir à des solutions qui utilisent la sauvegarde Azure NetApp Files ou un logiciel de sauvegarde partenaire.

Composants

• Machines virtuelles Azure : SAS Grid nécessite une mémoire, une bande passante en E/S et un stockage élevés, dans des proportions appropriées au nombre de cœurs. Azure offre des tailles de machines virtuelles prédéfinies avec moins de processeurs virtuels, ce qui peut vous aider à équilibrer le nombre de cœurs requis avec la quantité de mémoire, de stockage et de bande passante en E/S.

  Pour plus d’informations, consultez Tailles de machine virtuelle compatibles avec des processeurs virtuels restreints. Il est important de bien comprendre les ressources de calcul disponibles avec chaque instance. Pour exécuter SAS Grid sur Azure avec Azure NetApp Files, nous recommandons ces types d’instance :

  • Standard_E64-16ds_v4 ou Standard_E64-16ds_v5
  • Standard_E64-32ds_v4 ou Standard_E64-32ds_v5

  Veillez à passer en revue les bonnes pratiques d’utilisation de SAS sur Azure, y compris les mises à jour dans les commentaires.

• Azure NetApp Files : vous pouvez stocker SASDATA sur un volume Azure NetApp Files partagé sur le cluster de calcul.

  Par ailleurs, vous pouvez éventuellement utiliser des volumes NFS Azure NetApp Files pour SASWORK.

  Azure NetApp Files offre trois niveaux de service de performances :

  • standard
  • Premium
  • Ultra

  Les performances de votre volume sont principalement définies par le niveau de service. La taille de votre volume joue également un rôle, car le débit réalisable est déterminé par le niveau de service et la taille du volume.

Options de stockage pour SASDATA

Dans la mesure où Azure NetApp Files peut fournir un accès à haut débit et à faible latence au stockage, il constitue une alternative viable et plus rapide au disque Premium. Le stockage attaché au réseau n’est pas limité au niveau de la machine virtuelle, comme c’est le cas avec les disques managés, ce qui vous permet d’avoir un débit plus élevé vers le stockage.

Pour estimer le niveau requis pour votre capacité SASDATA, utilisez la calculatrice de performances Azure NetApp Files. (Veillez à sélectionner Avancé.)

Les volumes NFS Azure NetApp Files étant partagés, ils conviennent bien à l’hébergement de SASDATA, à condition que vous utilisiez des instances de machine virtuelle correctement dimensionnées et la distribution Red Hat Enterprise Linux (RHEL). Nous verrons cela plus loin dans cet article.

Options de stockage pour SASWORK

Le tableau suivant présente les options de stockage les plus courantes pour déployer SASWORK sur Azure. En fonction de vos exigences en termes de taille (capacité) et de vitesse (bande passante), vous avez trois options : stockage temporaire, disque managé et Azure NetApp Files.

Tenez compte de ces considérations quand vous choisissez une option :

• Le stockage temporaire (ou stockage éphémère) fournit la bande passante la plus élevée, mais il n’est disponible que dans des tailles plus petites. (La taille dépend de la référence SKU de la machine virtuelle.) Selon les capacités disponibles et requises, cette option peut être la meilleure.
• Si la capacité SASWORK requise dépasse la taille de stockage temporaire de la référence SKU de machine virtuelle que vous avez sélectionnée, envisagez d’utiliser un disque managé Azure pour héberger SASWORK. Gardez toutefois à l’esprit que le débit vers un disque managé est limité par l’architecture de machine virtuelle, du fait de sa conception, et qu’il varie en fonction de la référence SKU de machine virtuelle. Cette option de stockage n’est donc viable que pour les environnements avec des exigences moindres en termes de performances SASWORK.
• Pour répondre aux exigences de capacité SASWORK les plus élevées et à des exigences de performances moyennes qui excèdent ce que les disques managés Azure peuvent fournir, envisagez d’utiliser Azure NetApp Files pour SASWORK. Il offre une grande taille ainsi qu’un débit rapide.

Dans le tableau précédent, pour déterminer si vos besoins sont petits, grands, moyens ou très grands, prenez en compte l’échelle du déploiement, le nombre de machines virtuelles et de cœurs ainsi que les exigences associées en termes de capacité et de performances. Vous devez effectuer ces évaluations pour chaque déploiement.

Les options du tableau correspondent aux déploiements décrits dans les architectures suivantes. Dans tous les scénarios, SASDATA est hébergé sur un volume NFS Azure NetApp Files et partagé entre les nœuds de calcul. Pour certaines distributions RHEL, nous vous recommandons d’utiliser l’option NFS nconnect pour créer plusieurs flux réseau vers le volume. Pour plus d’informations, consultez la section Options de montage NFS de cet article.

Architecture de stockage temporaire

Pour les besoins en capacité SASWORK moins importants, le stockage temporaire des machines virtuelles Azure est une solution rapide et économique. Dans cette architecture, chaque machine virtuelle au niveau du calcul est équipée d’un stockage temporaire. Pour déterminer les tailles de stockage temporaire des machines virtuelles que vous utilisez, consultez la documentation sur les machines virtuelles Azure.

Dataflow

• Un nœud de calcul lit les données d’entrée et écrit les résultats dans SASDATA.
• Une partie subséquente du travail d’analytique peut être exécutée par un autre nœud dans le niveau de calcul. Il utilise la même procédure pour obtenir et stocker les informations qu’il doit traiter.
• Le répertoire de travail temporaire SASWORK n’est pas partagé. Il est stocké dans un stockage temporaire sur chaque nœud de calcul.

Architecture de disque managé

Si vos besoins en capacité pour SASWORK dépassent les capacités disponibles dans le stockage temporaire, les disques managés Azure constituent une bonne alternative. Les disques managés sont disponibles dans différentes tailles et avec différents niveaux de performances. Pour plus d’informations, consultez Objectifs de scalabilité et de performance pour les disques de machine virtuelle.

Dataflow

• Un nœud de calcul lit les données d’entrée et écrit les résultats dans SASDATA.
• Une partie subséquente du travail d’analytique peut être exécutée par un autre nœud dans le niveau de calcul. Il utilise la même procédure pour obtenir et stocker les informations qu’il doit traiter.
• Le répertoire de travail temporaire SASWORK n’est pas partagé. Il est stocké sur des disques managés attachés à chaque nœud de calcul.

Architecture Azure NetApp Files

Pour des exigences de capacité SASWORK plus élevées et/ou de performances moyennes, envisagez d’utiliser Azure NetApp Files. Azure NetApp Files offre des capacités de volume allant jusqu’à 100 Tio. Chaque nœud du niveau de calcul doit avoir son propre volume SASWORK. Les volumes ne doivent pas être partagés.

Dataflow

• Un nœud de calcul lit les données d’entrée et écrit les résultats dans SASDATA.
• Une partie subséquente du travail d’analytique peut être exécutée par un autre nœud dans le niveau de calcul. Il utilise la même procédure pour obtenir et stocker les informations qu’il doit traiter.
• Le répertoire de travail temporaire SASWORK n’est pas partagé. Il est stocké sur des volumes Azure NetApp Files individuels qui sont attachés à chaque nœud de calcul.

Recommandations relatives à la mise à l’échelle et à la configuration

• Pour bénéficier d’un trafic de données offrant la latence la meilleure et la plus cohérente entre les instances du cluster SAS, vérifiez que toutes les machines virtuelles sont créées dans le même groupe de placement de proximité.
• Consultez la section Conseils généraux de réglage dans les bonnes pratiques d’utilisation de SAS sur Azure.
• Pour obtenir une bande passante réseau optimale, activez les performances réseau accélérées.

Distributions RHEL et paramètres NFS

Distributions RHEL

RHEL est la distribution recommandée pour exécuter SAS 9 sur Linux. Chaque noyau pris en charge par Red Hat a ses propres contraintes en matière de bande passante NFS.

Pour plus d’informations sur l’exécution de SAS sur Azure, consultez les bonnes pratiques d’utilisation de SAS sur Azure.

Les machines virtuelles Azure Standard_E64-16ds_v4 et Standard_E64-32ds_v4, ou leurs équivalents v5, sont recommandées pour SAS. Compte tenu de ces recommandations, cette section fournit des instructions concernant l’utilisation de SAS avec Azure NetApp Files.

• Si vous utilisez RHEL 7, Standard_E64-16ds_v4 ou Standard_E64-16ds_v5 est le meilleur choix, en fonction de l’objectif de 100 Mio/s par cœur physique pour SASDATA.

  • Standard_E64-16ds_v4 : 90-100 Mio/s par cœur
  • Standard_E64-32ds_v4: 45-50 Mio/s par cœur

• Si vous utilisez RHEL 8.2, Standard_E64-16ds_v4 et Standard_E64-32ds_v4, ou leurs équivalents v5, sont des options possibles. Standard_E64-16ds_v4 est préférable compte tenu de l’objectif de 100 Mio/s par cœur pour SASDATA.

  • Standard_E64-16ds_v4 : 150-160 Mio/s par cœur
  • Standard_E64-32ds_v4: 75-80 Mio/s par cœur

• Si vous utilisez RHEL 8.3, Standard_E64-16ds_v4 et Standard_E64-32ds_v4, ou leurs équivalents v5, sont tout à fait acceptables compte tenu de l’objectif de débit par cœur :

  • La validation indique 3 200 Mio/s de lectures.
  • Ces résultats sont obtenus avec l’option de montage NFS nconnect.

Les tests montrent qu’une seule instance RHEL 7 n’atteint pas plus de 750-800 Mio/s environ en débit de lecture sur un seul point de terminaison de stockage Azure NetApp Files (c’est-à-dire sur un socket réseau). Il est possible d’obtenir 1 500 Mio/s d’écritures sur le même point de terminaison si vous définissez les options de montage NFS rsize et wsize sur 64 Kio. Certaines études suggèrent que le plafond de débit de lecture précédemment noté est un artefact du noyau 3.10. Pour plus d’informations, consultez RHEL CVE-2019-11477.

Les tests montrent qu’une seule instance RHEL 8.2, avec son noyau 4.18, est exempte des limitations notées dans le noyau 3.10. Il est donc possible d’atteindre un trafic de lecture de 1 200-1 300 Mio/s si vous définissez les options de montage NFS rsize et wsize sur 64 Kio. Pour les écritures séquentielles volumineuses, vous pouvez vous attendre à obtenir le même débit de 1 500 Mio/s qu’avec RHEL 7.

Avec une seule instance RHEL 8.3, avec l’option de montage nconnect (introduite dans la distribution RHEL 8.3), il est possible d’obtenir un débit de lecture d’environ 3 200 Mio/s à partir d’un seul volume Azure NetApp Files. Ne vous attendez pas à dépasser 1 500 Mio/s d’écritures sur un seul volume Azure NetApp Files, même si vous appliquez nconnect.

Réglages du noyau

Entrées de la table d’emplacements

NFSv3 ne dispose pas d’un mécanisme pour négocier la concurrence entre le client et le serveur. Le client et le serveur définissent chacun leurs limites sans se connaître l’un l’autre. Pour des performances optimales, vous devez aligner le nombre maximal d’entrées de table d’emplacements sunrpc côté client avec celui pris en charge sans résistance sur le serveur. Quand un client dépasse la capacité de la pile réseau du serveur à traiter une charge de travail, le serveur répond en diminuant la taille de la fenêtre pour la connexion, ce qui n’est pas un scénario idéal pour les performances.

Par défaut, les noyaux Linux modernes définissent la taille de l’entrée de table d’emplacements sunrpc par connexion sunrpc.max_tcp_slot_table_entries pour prendre en charge 65 536 opérations en suspens. Ces entrées de table d’emplacements définissent les limites de la concurrence. Des valeurs aussi élevées sont inutiles, car Azure NetApp Files utilise par défaut 128 opérations en suspens.

Nous vous recommandons de régler le client sur le même nombre :

• Réglages du noyau (par le biais de /etc/sysctl.conf)
  • sunrpc.tcp_max_slot_table_entries=128

Réglages du cache du système de fichiers

Vous devez également comprendre les facteurs suivants concernant les réglages du cache du système de fichiers :

• Le vidage d’un tampon compromis laisse les données dans un état propre utilisable pour de futures lectures jusqu’à ce que la pression de la mémoire conduise à une éviction.
• Il existe trois déclencheurs pour une opération de vidage asynchrone :
  • Basée sur l’heure : quand une mémoire tampon atteint l’âge défini par le réglage vm.dirty_expire_centisecs ou vm.dirty_writeback_centisecs, elle doit être marquée pour le nettoyage (autrement dit, le vidage ou l’écriture dans le stockage).
  • Sollicitation de la mémoire : pour plus d’informations, consultez vm.dirty_ratio | vm.dirty_bytes.
  • Fermeture : lorsqu’un descripteur de fichier est fermé, toutes les mémoires tampons compromises sont vidées de façon asynchrone dans le stockage.

Ces facteurs sont contrôlés par quatre éléments réglables. Vous pouvez modifier chaque réglage de manière dynamique et persistante en utilisant tuned ou sysctl dans le fichier /etc/sysctl.conf. Le réglage de ces variables améliore les performances de SAS Grid :

• Réglages du noyau (par le biais d’un profil réglé personnalisé)
  • include = throughput-performance
  • vm.dirty_bytes = 31457280
  • vm.dirty_expire_centisecs = 100
  • vm.dirty_writeback_centisecs = 300

Options de montage NFS

Nous recommandons les options de montage NFS suivantes pour les systèmes de fichiers partagés NFS utilisés pour les fichiers SASDATA permanents :

RHEL 7 et 8.2

bg,rw,hard,rsize=65536,wsize=65536,vers=3,noatime,nodiratime,rdirplus,acdirmin=0,tcp,_netdev

RHEL 8.3

bg,rw,hard,rsize=65536,wsize=65536,vers=3,noatime,nodiratime,rdirplus,acdirmin=0,tcp,_netdev,nconnect=8

Nous recommandons les options de montage suivantes pour les volumes SASWORK, où les volumes respectifs sont utilisés exclusivement pour SASWORK et ne sont pas partagés entre les nœuds :

RHEL 7 et 8.2

bg,rw,hard,rsize=65536,wsize=65536,vers=3,noatime,nodiratime,rdirplus,acdirmin=0,tcp,_netdev,nocto

RHEL 8.3

bg,rw,hard,rsize=65536,wsize=65536,vers=3,noatime,nodiratime,rdirplus,acdirmin=0,tcp,_netdev,nocto,nconnect=8

Pour plus d’informations sur les avantages et le coût de l’option de montage nocto, consultez Cohérence de bout en bout et minuteurs d’attribut de cache.

Pensez également à passer en revue Azure NetApp Files : un système de fichiers partagé à utiliser avec SAS Grid sur MS Azure, notamment toutes les mises à jour dans les commentaires.

Paramètres de lecture anticipée NFS

Nous vous recommandons de définir le réglage de lecture anticipée NFS pour toutes les distributions RHEL sur 15 360 Kio. Pour plus d’informations, consultez le guide pratique pour définir de manière permanente la lecture anticipée pour les montages NFS.

Autres solutions

La solution de stockage dans les architectures précédentes est hautement disponible, conformément aux spécifications du contrat de niveau de service Azure NetApp Files. Pour une protection et une disponibilité supplémentaires, vous pouvez répliquer les volumes de stockage dans une autre région Azure à l’aide de la réplication inter-région d’Azure NetApp Files.

La réplication des volumes par le biais de la solution de stockage présente deux avantages clés :

• Il n’y a pas de charge supplémentaire sur les machines virtuelles de l’application.
• Cette solution élimine la nécessité d’exécuter des machines virtuelles dans la région de destination en période de fonctionnement normal.

Le contenu du stockage est répliqué sans faire appel à des ressources d’infrastructure de calcul, et la région de destination n’a pas besoin d’exécuter le logiciel SAS. Les machines virtuelles de destination n’ont pas besoin d’être en cours d’exécution pour prendre en charge ce scénario.

L’architecture suivante montre comment le contenu du stockage sur Azure NetApp Files est répliqué dans une deuxième région, où le stockage est rempli avec un réplica des données de production. En cas de basculement, la région secondaire est mise en ligne et les machines virtuelles sont démarrées afin que la production puisse reprendre dans la deuxième région. Vous devez rediriger le trafic vers la deuxième région en reconfigurant les équilibreurs de charge qui ne figurent pas dans le diagramme.

Le RPO standard pour cette solution est inférieur à 20 minutes quand l’intervalle de mise à jour de la réplication inter-région est défini sur 10 minutes.

Dataflow

• Un nœud de calcul lit les données d’entrée et écrit les résultats dans SASDATA.
• Une partie subséquente du travail d’analytique peut être exécutée par un autre nœud dans le niveau de calcul. Il utilise la même procédure pour obtenir et stocker les informations qu’il doit traiter.
• Le répertoire de travail temporaire SASWORK n’est pas partagé. Il est stocké sur des volumes Azure NetApp Files individuels qui sont attachés à chaque nœud de calcul.
• La réplication inter-région d’Azure NetApp Files réplique de façon asynchrone le volume SASDATA, y compris tous les instantanés, vers une région DR pour faciliter le basculement en cas de sinistre régional.

Considérations

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 Microsoft Azure Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

Azure NetApp Files fournit un Contrat de niveau de service standard avec une disponibilité de 99,99 % pour tous les niveaux et toutes les régions prises en charge. Azure NetApp Files prend également en charge le provisionnement des volumes dans les zones de disponibilité que vous choisissez, ainsi que les déploiements haute disponibilité entre zones.

Pour les contrats SLA avec des RPO/RTO améliorés, la protection des données intégrée avec instantanés et sauvegardes est incluse dans le service. La réplication inter-région offre les mêmes avantages dans toutes les régions Azure.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

Azure NetApp Files offre un niveau de sécurité, car les volumes sont provisionnés et le trafic de données reste dans vos réseaux virtuels. Aucun point de terminaison n’est adressable publiquement. Toutes les données sont chiffrées au repos à tout moment. Vous pouvez éventuellement chiffrer les données en transit.

Azure Policy peut vous aider à appliquer des normes organisationnelles et à évaluer la conformité à grande échelle. Azure NetApp Files prend en charge Azure Policy par le biais de définitions de stratégie personnalisées et intégrées.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.

Performances

En fonction de vos besoins en matière de débit et de capacité, gardez à l’esprit les considérations suivantes :

• les considérations relatives aux performances pour Azure NetApp Files ;
• les niveaux de capacité et de service Azure NetApp Files requis pour SASDATA ;
• les conseils fournis dans cet article pour choisir un type de stockage pour SASWORK.

Extensibilité

Vous pouvez facilement mettre à l’échelle les performances de calcul en ajoutant des machines virtuelles aux groupes identiques qui exécutent les trois niveaux de la solution SAS.

Vous pouvez mettre à l’échelle dynamiquement le stockage des volumes Azure NetApp Files. Si vous utilisez une qualité de service (QoS) automatique, les performances sont mises à l’échelle en même temps. Pour un contrôle plus précis de chaque volume, vous pouvez également contrôler les performances de chaque volume séparément en utilisant une qualité de service manuelle pour vos pools de capacité.

Les volumes Azure NetApp Files se déclinent en trois niveaux de performances : Ultra, Premium et Standard. Choisissez le niveau qui correspond le mieux à vos besoins en matière de performances, en tenant compte du fait que la bande passante disponible évolue avec la taille d’un volume. Vous pouvez modifier le niveau de service d’un volume à tout moment. Pour plus d’informations sur le modèle de coût d’Azure NetApp Files, consultez ces exemples de prix.

Vous pouvez utiliser la calculatrice de performances Azure NetApp Files pour commencer.

Optimisation des coûts

L’optimisation des coûts consiste à réduire les dépenses inutiles et à améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Modèle de coût

Une bonne compréhension du modèle de coût d’Azure NetApp Files peut vous aider à gérer vos dépenses.

La facturation d’Azure NetApp Files est basée sur la capacité de stockage provisionnée, que vous allouez en créant des pools de capacité. Les pools de capacité sont facturés tous les mois selon un coût défini par Gio alloué par heure.

Si vos exigences en termes de taille de pool de capacité fluctuent (par exemple, en raison de besoins variables en termes de capacité ou de performances), envisagez de redimensionner dynamiquement vos volumes et pools de capacité pour équilibrer les coûts en fonction de vos besoins en termes de capacité et de performances.

Si vos exigences en matière de taille de pool de capacité restent les mêmes, mais que les exigences en matière de performances fluctuent, envisagez de modifier dynamiquement le niveau de service d’un volume. Vous pouvez provisionner et déprovisionner des pools de capacité de différents types tout au long du mois, ce qui vous permet de bénéficier de performances juste-à-temps et de réduire les coûts pendant les périodes durant lesquelles vous n’avez pas besoin d’un haut niveau de performance.

Tarifs

En fonction de vos exigences en termes de capacité et de performances, déterminez le niveau de service Azure NetApp Files dont vous avez besoin (Standard, Premium ou Ultra). Utilisez ensuite la calculatrice de prix Azure pour évaluer les coûts de ces composants :

• Composants SAS sur Azure
• Azure NetApp Files
• Disque managé (facultatif)
• Réseau virtuel

Excellence opérationnelle

L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.

SAS Grid sur Azure combine flexibilité et déploiement rapide. Voici quelques avantages :

• Répondre aux besoins changeants de l’entreprise grâce à l’équilibrage dynamique des charges de travail
• Créer un environnement de calcul SAS hautement disponible
• Obtenir des résultats plus rapides à partir de votre infrastructure informatique existante
• Augmenter les ressources de calcul de manière incrémentielle et rentable
• Gérer toutes vos charges de travail analytiques
• Passer facilement d’un serveur en silo ou d’un environnement multi-PC à un environnement de grille SAS

Déployer ce scénario

L’idéal est de déployer les charges de travail à l’aide d’un processus IaC (infrastructure as code). Les charges de travail SAS peuvent être sensibles aux mauvaises configurations fréquentes dans des déploiements manuels, qui réduisent la productivité.

Pour commencer à concevoir votre solution SAS Grid sur Azure, consultez Architecture de SAS sur Azure et Automatisation d’un déploiement SAS sur Azure avec GitHub Actions.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

• Geert van Teylingen | Responsable groupe de produits
• Arnt de Gier | Technical Marketing Engineer

Autres contributeurs :

• Mick Alberts | Rédacteur technique

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

Étapes suivantes

• Webinaire rapide pour bien démarrer avec Azure
• Azure NetApp Files : un système de fichiers partagé à utiliser avec SAS Grid sur Azure
• Calculatrice des performances de Azure NetApp Files
• Documentation Azure NetApp Files
• Formation : Présentation d’Azure NetApp Files

Ressources associées

• SAS sur Azure, recommandations concernant le dimensionnement des machines virtuelles
• SAS sur Azure, Azure NetApp Files
• SAS sur Azure, considérations relatives au placement des machines virtuelles et du réseau
• SAS sur Azure, considérations relatives à la sécurité