Modifier

Partager via

Architecture de SAS sur Azure

Machines virtuelles Azure
Réseau virtuel Azure
Azure Files

Cette solution exécute des charges de travail d’analytique SAS sur Azure. Les directives couvrent différents scénarios de déploiement. Par exemple, plusieurs versions de SAS sont disponibles. Vous pouvez exécuter un logiciel SAS sur des machines virtuelles auto-gérées. Vous pouvez également déployer des versions basées sur des conteneurs à l’aide d’Azure Kubernetes service (AKS).

Architecture

Diagramme d’architecture montrant comment déployer des produits SAS sur Azure.

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

Workflow

Les déploiements Azure de SAS contiennent généralement trois couches :

  • Un niveau d’API ou de visualisation. Dans cette couche :

    • Le niveau métadonnées permet à des applications clientes d’accéder aux métadonnées sur des sources de données, des ressources, des serveurs et des utilisateurs.
    • Les applications web donnent un accès aux données d’intelligence au niveau intermédiaire.

  • Une plateforme de calcul où les serveurs SAS traitent les données.

  • Un niveau de stockage que SAS utilise pour le stockage permanent. Les choix populaires sur Azure sont les suivants :

    • Lustre
    • IBM Spectrum Scale
    • NFS (Network File System)

Un réseau virtuel Azure isole le système dans le cloud. Au sein de ce réseau :

  • Un groupe de placement de proximité réduit la latence entre les machines virtuelles.
  • Des groupes de sécurité réseau protègent les ressources SAS contre le trafic indésirable.

Prérequis

Avant de déployer une charge de travail SAS, assurez-vous que les composants suivants sont en place :

  • Une recommandation de dimensionnement d’une équipe de dimensionnement SAS
  • Un fichier de licence SAS
  • Accès à un groupe de ressources pour le déploiement de vos ressources
  • Un quota d’abonnement de processeur virtuel (vCPU) prenant en compte votre document de dimensionnement et votre choix de machines virtuelles
  • Accès à un serveur LDAP (Lightweight Directory Access Protocol) sécurisé

Détails du scénario

Parallèlement à la description des différentes implémentations, ce guide s’aligne sur les principes du Microsoft Azure Well-Architected Framework pour atteindre l’excellence dans les domaines du coût, du DevOps, de la résilience, de la scalabilité et de la sécurité. Toutefois, en plus de ce guide, consultez une équipe SAS pour une validation supplémentaire de votre cas d’usage particulier.

En tant que partenaires, Microsoft et SAS œuvrent au développement d’une feuille de route pour les organisations qui innovent dans le cloud. Les deux entreprises s’engagent à garantir des déploiements de haute qualité des produits et solutions SAS sur Azure.

Présentation de SAS

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 plateformes de SAS prennent entièrement en charge leurs solutions pour des domaines tels que la gestion des données, la détection des fraudes, l’analyse des risques et la visualisation. SAS offre les principales plateformes suivantes, que Microsoft a validées :

  • SAS Grid 9.4
  • SAS Viya

Les architectures suivantes ont été testées :

  • SAS Grid 9.4 sur Linux
  • SAS 9 Foundation
  • SAS Viya 3.5 avec architectures de traitement multiprocesseur symétrique (SMP) et de traitement massivement parallèle (MPP) sur Linux
  • SAS Viya 2020 et au-dessus avec une architecture MPP sur AKS

Ce guide fournit des informations générales sur l’exécution de SAS sur Azure, et non des informations spécifiques de la plateforme. Ces directives partent du principe que vous hébergez votre propre solution SAS sur Azure dans votre propre locataire. SAS n’héberge pas de solution pour vous sur Azure. Pour plus d’informations sur les services d’hébergement et de gestion Azure fournis par SAS, consultez Services d’application managés de SAS.

Recommandations

Prenez en compte les points des sections suivantes lors de la conception de votre implémentation.

La documentation de SAS fournit des exigences par cœur, c’est-à-dire par cœur de processeur physique. Mais Azure fournit des listes de processeurs virtuels. Sur les machines virtuelles que nous recommandons d’utiliser avec SAS, il existe deux processeurs virtuels pour chaque cœur physique. Par conséquent, pour calculer la valeur d’une exigence de processeur virtuel, utilisez la moitié de la valeur de l’exigence de cœur. Par exemple, une exigence de cœur physique de 150 Mbits/s se traduit par 75 Mbits/s par processeur virtuel. Pour plus d’informations sur les performances de calcul d’Azure, consultez Unité compute (ACU).

Notes

Si vous faites un scale-up et que vous conservez des données dans un déploiement SAS mononœud (et non vers un système de fichiers externalisé), la documentation SAS recommande une bande passante d’au moins 150 Mo/s. Pour obtenir cette bande passante, vous devez franger plusieurs disques P30 Premium (ou plus).

Systèmes d’exploitation

Linux fonctionne au mieux pour l’exécution des charges de travail SAS. SAS prend en charge les versions 64 bits des systèmes d’exploitation suivants :

  • Red Hat 7 ou version ultérieure
  • SUSE Linux Enterprise Server (SLES) 12.2
  • Oracle Linux 6 ou version ultérieure

Pour plus d’informations sur des versions de SAS spécifiques, consultez la matrice de prise en charge du système d’exploitation SAS. Dans les environnements qui utilisent plusieurs ordinateurs, il est préférable d’exécuter la même version de Linux sur tous les ordinateurs. Azure ne prend pas en charge les déploiements Linux 32 bits.

Pour optimiser la compatibilité et l’intégration avec Azure, commencez par une image du système d’exploitation de la Place de marché Azure. Si vous utilisez une image personnalisée sans configuration supplémentaire, cela peut nuire aux performances de SAS.

Problèmes de noyau

Lors du choix d’un système d’exploitation, tenez compte d’un problème de blocage logiciel qui affecte l’intégralité de la série Red Hat 7.x. Ce problème se produit dans les noyaux suivants :

  • Noyaux Linux 3.x
  • Versions antérieures à 4.4

Il est dû à un problème avec la gestion de la mémoire et des E/S de Linux et de Hyper-V. Quand le problème se produit, les journaux système contiennent des entrées telles que la suivant qui mentionne une interruption non masquable (NMI) :

Message from syslogd@ronieuwe-sas-e48-2 at Sep 13 08:26:08
kernel:NMI watchdog: BUG: soft lockup - CPU#12 stuck for 22s! [swapper/12:0]

Un autre problème affecte des versions plus anciennes de Red Hat. Il peut en particulier se produire dans des versions qui remplissent les conditions suivantes :

  • Ont des noyaux Linux antérieurs à 3.10.0-957.27.2
  • Utilisent des lecteurs NVMe (Non-Volatile Memory Express)

Quand la mémoire du système est fortement sollicité, il se peut que le pilote NVMe Linux générique n’alloue suffisamment de mémoire pour une opération d’écriture. Par conséquent, le système signale un blocage réversible résultant d’un blocage réel.

Mettez à niveau votre noyau pour éviter les deux problèmes. Vous pouvez également essayer cette solution de contournement :

  • Définissez /sys/block/nvme0n1/queue/max_sectors_kb sur 128 au lieu d’utiliser la valeur par défaut, 512.
  • Modifiez ce paramètre sur chaque appareil NVMe de la machine virtuelle et sur chaque démarrage de la machine virtuelle.

Exécutez les commandes suivantes pour régler ce paramètre :

# cat /sys/block/nvme0n1/queue/max_sectors_kb
512
# echo 128 >/sys/block/nvme0n1/queue/max_sectors_kb
# cat /sys/block/nvme0n1/queue/max_sectors_kb
128

Recommandations relatives au dimensionnement des machines virtuelles

Les déploiements SAS utilisent souvent les références (SKU) de machine virtuelle suivantes :

Série Edsv5

Les machines virtuelles de la série Edsv5 sont les machines SAP par défaut pour Viya et Grid. Elles présentent les caractéristiques suivantes :

  • Cœurs limités. Avec de nombreux ordinateurs de cette série, vous pouvez limiter le nombre de processeurs virtuels de la machine virtuelle.
  • Bon ratio processeur/mémoire.
  • Débit élevé du disque connecté localement. La vitesse d’E/S est importante pour des dossiers tels que SASWORK, et le cache des services d’analyse du cloud (CAS), CAS_CACHE, que SAS utilise pour les fichiers temporaires.

Si les machines virtuelles de la série Edsv5 ne sont pas disponibles, il est recommandé d’utiliser la génération précédente. Les machines virtuelles de la série Edsv4 ont été testées et bien effectuées sur les charges de travail SAP.

Série Ebsv5

Dans certains cas, le disque attaché localement n’a pas suffisamment d’espace de stockage pour SASWORK ou CAS_CACHE. Pour obtenir un répertoire de travail plus grand, utilisez la série Ebsv5 de machines virtuelles avec des disques attachés Premium. Ces machines virtuelles présentent les caractéristiques suivantes :

  • Mêmes spécifications que les machines virtuelles Edsv5 et Esv5
  • Débit élevé par rapport au disque attaché distant, jusqu’à 4 Go/s, ce qui vous donne une taille SASWORK ou CAS_CACHE si nécessaire aux besoins d’E/S de SAS.

Si les machines virtuelles de la série Edsv5 offrent suffisamment de stockage, il est préférable de les utiliser car elles sont plus rentables.

Série M

De nombreuses charges de travail utilisent des machines virtuelles de la série M, notamment :

  • Implémentations de l’environnement d’exécution de la programmation de SAS (SPRE) qui utilisent une approche Viya de l’architecture logicielle.
  • Certaines charges de travail SAS Grid.

Les machines virtuelles de la série M présentent les caractéristiques suivantes :

  • Cœurs limités
  • Jusqu’à 3,8 Tio de mémoire, ce qui convient pour les charges de travail qui utilisent une grande quantité de mémoire
  • Débit élevé pour les disques distants, ce qui fonctionne bien pour le dossier SASWORK quand le disque disponible localement est insuffisant

Série Ls

Certains environnements lourds d’E/S doivent utiliser des machines virtuelles de série Lsv2 ou Lsv3. En particulier, les implémentations qui nécessitent une vitesse d’E/S élevée et à faible latence et une grande quantité de mémoire bénéficient de ce type d’ordinateur. Les exemples incluent des systèmes qui font un usage intensif du dossier SASWORK ou du CAS_CACHE.

Notes

SAS optimise ses services pour une utilisation avec la bibliothèque MKL (Intel Math Kernel Library).

  • Avec des charges de travail lourdes en calcul, évitez les machines virtuelles qui n’utilisent pas de processeurs Intel : Lsv2 et Lasv3.
  • Lors de la sélection d’un processeur AMD, vérifiez la manière dont la bibliothèque MKL fonctionne sur celui-ci.

Avertissement

Dans la mesure du possible, évitez d’utiliser des machines virtuelles Lsv2. Utilisez plutôt les machines virtuelles Lsv3 avec des puces Intel.

Avec Azure, vous pouvez mettre à l’échelle des systèmes SAS Viya à la demande pour respecter des échéances :

  • En renforçant la capacité de calcul du pool de nœuds.
  • En utilisant l’Autoscaler de cluster AKS pour ajouter des nœuds et mettre à l’échelle horizontalement.
  • En effectuant un scale-up temporaire de l’infrastructure pour accélérer une charge de travail SAS.

Notes

Lors de la mise à l’échelle des composants de calcul, pensez également à effectuer un scale-up du stockage pour éviter des goulots d’étranglement d’E/S de stockage.

Avec des charges de travail Viya 3.5 et Grid, Azure ne prend pas actuellement en charge la mise à l’échelle horizontale ou verticale. Viya 2022 prend en charge la mise à l’échelle horizontale.

Considérations relatives au placement des machines virtuelles et du réseau

Les charges de travail SAS sont souvent « bavardes ». Par conséquent, elles peuvent transférer une quantité importante de données. Avec toutes les plateformes SAS, suivez les recommandations ci-après pour réduire les effets du bavardage :

  • Déployez les plateformes SAS et de stockage sur le même réseau virtuel. Cette approche évite également des coûts de peering.
  • Placez les machines SAS dans un groupe de placement de proximité pour réduire la latence entre les nœuds.
  • Autant que possible, déployez les ordinateurs SAS et les plateformes de stockage de données basées sur des machines virtuelles dans le même groupe de placement de proximité.
  • Déployez des appliances SAS et de stockage dans la même zone de disponibilité pour éviter la latence inter-zone. Si vous ne pouvez pas vérifier que les composants de votre solution sont déployés dans la même zone, contactez le support Azure.

SAS a des exigences spécifiques en matière de nom de domaine complet (FQDN) pour les machines virtuelles. Définissez les noms de domaine complets des machines correctement et assurez-vous que les services DNS (Domain Name System) fonctionnent. Vous pouvez définir les noms avec Azure DNS. Vous pouvez également modifier le fichier hosts dans le dossier Configuration etc.

Notes

Activez la mise en réseau accélérée sur tous les nœuds du déploiement SAS. Lorsque vous désactivez cette fonctionnalité, les performances en souffrent considérablement.

Pour activer la mise en réseau accélérée sur une machine virtuelle, procédez comme suit :

  1. Exécutez cette commande dans Azure CLI pour libérer la machine virtuelle :

    az vm deallocate --resource-group <resource_group_name> --name <VM_name>

  2. Désactivez la machine virtuelle.

  3. Exécutez cette commande dans l’interface de ligne de commande :

    az network nic update -n <network_interface_name> -g <resource_group_name> --accelerated-networking true

Lorsque vous migrez des données ou interagissez avec SAS dans Azure, nous vous recommandons d’utiliser l’une des solutions suivantes pour connecter des ressources locales à Azure :

Pour des charges de travail SAS de production dans Azure, ExpressRoute fournit une connexion privée, dédiée et fiable qui offre les avantages suivant par rapport à un VPN site à site :

  • Vitesse supérieure
  • Latence plus faible
  • Sécurité plus rigoureuse

Tenez compte des interfaces sensibles à la latence entre les applications SAS et non-SAS. Envisagez de déplacer des sources de données et des récepteurs proches de SAS.

Gestion des identités

Les plateformes SAS peuvent utiliser des comptes d’utilisateur locaux. Ils peuvent également utiliser un serveur LDAP sécurisé pour valider les utilisateurs. Nous vous recommandons d’exécuter un contrôleur de domaine dans Azure. Utilisez ensuite la fonctionnalité de jonction de domaine pour gérer correctement l’accès de sécurité. Si vous n’avez pas configuré de contrôleurs de domaine, envisagez de déployer Microsoft Entra Domain Services. Lorsque vous utilisez la fonctionnalité de jonction de domaine, assurez-vous que les noms de machine ne compte pas plus de 15 caractères.

Notes

Dans certains environnements, il est indispensable de disposer d’une connectivité locale ou de jeux de données partagés entre les environnements SAS locaux et hébergés par Azure. Dans ces situations, nous recommandons fortement de déployer un contrôleur de domaine dans Azure.

La forêt Microsoft Entra Domain Services crée des utilisateurs qui peuvent s’authentifier auprès des appareils Microsoft Entra, mais pas des ressources locales et inversement.

Sources de données

Les solutions SAS accèdent souvent aux données de plusieurs systèmes. Ces sources de données s’inscrivent dans deux catégories :

  • Jeux de données SAS, que SAS stocke dans le dossier SASDATA
  • Bases de données auxquelles SAS impose souvent une charge importante

Pour un résultat optimal :

  • Positionnez les sources de données le plus près possible de l’infrastructure SAS.
  • Limitez le nombre de tronçons et d’appliances réseau entre les sources de données et l’infrastructure SAS.

Notes

Si vous ne pouvez pas déplacer des sources de données proches de l’infrastructure SAS, évitez d’exécuter des analyses sur celles-ci. Au lieu de cela, exécutez des processus ETL avant les analyses. Adoptez la même approche avec les sources de données surchargées.

Stockage distant permanent pour données SAS

SAP et Microsoft ont testé une série de plateformes de données que vous pouvez utiliser pour héberger des jeux de données SAS. Les blogs SAS documentent les résultats en détail, y compris les performances. Les tests incluent les plateformes suivantes :

SAS offre des scripts de test de performances pour les architectures Viya et GRID. Les Forums SAS fournissent de la documentation sur les tests avec des scripts sur ces plateformes.

Sycomp Storage Fueled by IBM Spectrum Scale (GPFS)

Pour plus d’informations sur la façon dont Sycomp Storage Fueled by IBM Spectrum Scale est conforme aux attentes en matière de performances, consultez SAS review of Sycomp for SAS Grid.

Pour le dimensionnement, Sycomp formule les recommandations suivantes :

  • Fournissez un nœud de mise à l’échelle GPFS pour huit cœurs avec une configuration de 150 Mbits/s par cœur.
  • Utilisez au minimum cinq lecteurs P30 par instance.
Azure Managed Lustre

Azure Managed Lustre est un système de fichiers partagé créé pour les charges de travail HPC (High-Performance Computing) et IA. Managed Lustre peut exécuter des charges de travail SAS 9 et Viya en parallèle. Pour optimiser les performances de votre système de fichiers, suivez les recommandations ci-dessous :

  • Lorsque vous déployez Managed Lustre, effectuez des réglages sur tous les nœuds clients afin d’augmenter la lecture anticipée du client Lustre et d’optimiser la concurrence pour les modèles d’E/S SAS. Pour ce faire, exécutez la commande suivante :

    lctl set_param mdc.*.max_rpcs_in_flight=128 osc.*.max_pages_per_rpc=16M osc.*.max_rpcs_in_flight=16 osc.*.max_dirty_mb=1024 llite.*.max_read_ahead_mb=2048 osc.*.checksums=0  llite.*.max_read_ahead_per_file_mb=256

  • Activez les performances réseau accélérées sur toutes les machines virtuelles SAS.

  • Pour réduire la latence du réseau, placez les machines virtuelles SAS dans la même zone de disponibilité que celle dans laquelle Managed Lustre est déployé.

Niveau premium d’Azure Files

Le niveau premium d’Azure Files est un service managé qui prend en charge le protocole NFS 4.1. Il fournit un système de fichiers rentable, élastique, performant et conforme à la norme POSIX. Les IOPS et le débit des partages NFS sont mis à l’échelle avec la capacité provisionnée. SAS a testé de manière approfondie le niveau premium d’Azure Files et a constaté que les performances sont plus que suffisantes pour alimenter les installations SAS.

Pour améliorer les performances, vous pouvez utiliser nconnect. Cette option de montage répartit les demandes d’E/S sur plusieurs canaux. Pour en savoir plus, consultez Performances NFS.

Lorsque vous utilisez un partage de fichiers NFS Azure dans Azure Files, tenez compte des points suivants :

  • Ajustez la capacité provisionnée pour répondre aux exigences en termes de performances. Les IOPS et le débit des partages NFS sont mis à l’échelle avec la capacité provisionnée. Pour en savoir plus, consultez Performances NFS.
  • Utilisez nConnect dans vos montages avec un paramètre nconnect=4 pour une utilisation optimale des canaux parallèles.
  • Optimisez les paramètres de lecture anticipée pour qu’ils soient 15 fois supérieurs aux paramètres rsize et wsize. Pour la plupart des charges de travail, nous vous recommandons d’utiliser un rsize et un wsize de 1 Mo et un paramètre read-ahead de 15 Mo. Pour en savoir plus, consultez Augmenter la taille de la lecture anticipée.
Azure NetApp Files (NFS)

Les tests SAS ont validé les performances de NetApp pour SAS Grid. Plus précisément, les tests indiquent qu’Azure NetApp Files est une option de stockage principal viable pour des clusters SAS Grid allant jusqu’à 32 cœurs physiques sur plusieurs machines. Quand NetApp a fourni des optimisations et des fonctionnalités Linux, Azure NetApp Files peut être la principale option pour les clusters jusqu’à 48 cœurs physiques sur plusieurs machines.

Tenez compte des points suivants quand vous utilisez ce service :

  • Azure NetApp Files fonctionne bien avec des déploiements Viya . N’utilisez pas Azure NetApp Files pour le cache CAS dans Viya, car le débit d’écriture n’est pas adapté. Si possible, utilisez plutôt le disque éphémère local de votre machine virtuelle.
  • Sur SAS 9 Foundation avec Grid 9.4, les performances d’Azure NetApp Files avec SAS pour les fichiers SASDATA sont bonnes pour les clusters jusqu’à 32 cœurs physiques. Cette valeur peut atteindre 48 cœurs quand le réglage est appliqué.
  • Pour garantir de bonnes performances, sélectionnez au minimum un niveau de service de stockage Premium ou Ultra lors du déploiement d’Azure NetApp Files. Vous pouvez choisir le niveau de service Standard pour les volumes très importants. Envisagez de commencer par le niveau Premium et de basculer vers Ultra ou Standard par la suite. Les changements de niveau de service peuvent être effectués en ligne, sans interruption ou migrations de données.
  • Les performances de lecture et d’écriture sont différentes pour Azure NetApp Files. Le débit d’écriture pour SAS atteint ses limites à environ 1 600 Mio/s, tandis que le débit de lecture va jusqu’à environ 4 500 Mio/s. Si vous avez besoin d’un débit d’écriture élevé en continu, il se peut qu’Azure NetApp Files ne soit pas adapté.
Réglage de la lecture anticipée NFS

Pour améliorer les performances de votre charge de travail SAS, il est important de régler le paramètre du noyau read-ahead, ce qui affecte la façon dont les partages NFS sont montés. Lorsque la lecture anticipée est activée, le noyau Linux peut demander des blocs avant toute E/S effective par l’application. Le résultat est une amélioration du débit de lecture séquentiel. La plupart des charges de travail SAS lisent de nombreux fichiers volumineux en vue d’un traitement ultérieur, de sorte que SAS bénéficie énormément de tampons de lecture importants.

Avec les noyaux Linux 5.4 ou ultérieurs, la lecture anticipée par défaut est passée de 15 Mo à 128 Ko. La nouvelle valeur par défaut réduit les performances de lecture pour SAS. Pour optimiser vos performances, augmentez le paramètre de lecture anticipée sur vos machines virtuelles Linux SAS. SAS et Microsoft vous recommandent de définir la lecture anticipée sur 15 fois la valeur de rsize et wsize. Dans l’idéal, rsize et wsize sont de 1 Mo et la read-ahead de 15 Mo.

Le réglage de la lecture anticipée sur une machine virtuelle est simple. Il nécessite l’ajout d’une règle udev.

Pour Kubernetes, ce processus est plus complexe, car il doit être effectué sur l’hôte et non sur le pod. SAS fournit des scripts pour Viya sur AKS qui définissent automatiquement la valeur de la lecture anticipé sur le post. Pour en savoir plus, consultez Utilisation de partages NFS Premium dans Azure Files pour SAS Viya sur Kubernetes.

Autres sources de données

Les plateformes SAS prennent en charge différentes sources de données :

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

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é.

La sortie de vos charges de travail SAS peut être l’une des ressources critiques de votre organisation. La sortie de SAS donne un aperçu de l’efficacité interne, et peut jouer un rôle critique dans votre stratégie de création de rapports. Il est donc important de sécuriser l’accès à votre architecture SAS. Pour atteindre cet objectif, utilisez une authentification sécurisée et résolvez les vulnérabilités du réseau. Utilisez un chiffrement pour contribuer à la protection de toutes les données qui se déplacent tant à l’intérieur qu’à l’extérieur de votre architecture.

Azure fournit SAS en utilisant un modèle cloud d’IaaS (infrastructure as a service). Microsoft crée des protections de sécurité dans le service aux niveaux suivants :

  • Centre de données physique
  • Réseau physique
  • Hôte physique
  • Hyperviseur

Évaluez avec soin les services et les technologies que vous sélectionnez pour les niveaux au-dessus de l’hyperviseur, tel le système d’exploitation invité pour SAS. Veillez à fournir les contrôles de sécurité appropriés pour votre architecture.

Actuellement, SAS ne prend pas entièrement en charge Microsoft Entra ID. Pour l’authentification dans la couche de visualisation pour SAS, vous pouvez utiliser Microsoft Entra ID. En revanche, pour l’autorisation principale, utilisez une stratégie similaire à l’authentification locale. Lorsque vous gérez des ressources IaaS, vous pouvez utiliser Microsoft Entra ID pour l’authentification et l’autorisation auprès du portail Azure. Lorsque vous utilisez Microsoft Entra Domain Services, vous ne pouvez pas authentifier les comptes invités. Toute tentative de connexion d’invité échouera.

Utilisez des groupes de sécurité réseau (NSG) pour filtrer le trafic réseau échangé avec des ressources au sein de votre réseau virtuel. Avec ces groupes, vous pouvez définir des règles qui accordent ou refusent l’accès à vos services SAS. Voici quelques exemples :

  • Octroi de l’accès aux ports de travail CAS à partir des plages d’adresses IP locales.
  • Blocage de l’accès aux services SAS à partir d’Internet.

Vous pouvez utiliser Azure Disk Encryption pour le chiffrement au sein du système d’exploitation. Cette solution utilise la fonctionnalité DM-Crypt de Linux. Nous ne recommandons cependant pas actuellement l’utilisation d’Azure Disk Encryption. Cela peut considérablement dégrader les performances, en particulier si vous utilisez des fichiers SASWORK localement.

Le chiffrement côté serveur (SSE) de Stockage sur disque Azure protège vos données. Il vous aide également à respecter les engagements de votre organisation en matière de sécurité et de conformité. Avec des disques managés Azure, SSE chiffre les données au repos conservées dans le cloud. Ce comportement s’applique par défaut tant au système d’exploitation qu’aux disques de données. Vous pouvez utiliser des clés gérées par la plateforme ou vos propres clés pour chiffrer votre disque managé.

Protéger votre infrastructure

Contrôlez l’accès aux ressources Azure que vous déployez. Chaque abonnement Azure entretient une relation d’approbation avec un locataire Microsoft Entra. Utilisez le contrôle d’accès en fonction du rôle Azure (RBAC Azure) pour accorder aux utilisateurs de votre organisation les autorisations d’accès appropriées sur les ressources Azure. Accordez l’accès en assignant des rôles Azure à des utilisateurs ou à des groupes jusqu’à une certaine étendue. L’étendue peut être appliquée à un abonnement, à un groupe de ressources ou à une ressource unique. Veillez à auditer tous les changements apportés à l’infrastructure.

Gérer l’accès distant à vos machines virtuelles par le biais d’Azure Bastion. N’exposez aucun de ces composants à Internet :

  • Machines virtuelles
  • Ports SSH (Secure Shell Protocol)
  • Ports RDP (Remote Desktop Protocol)

Déployer ce scénario

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

Pendant la création de votre environnement, consultez le matériel de référence de démarrage rapide sur CCoreCompete SAS 9 or Viya on Azure.

Contributeurs

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

Principaux auteurs :

Autres contributeurs :

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

Étapes suivantes

Pour vous aider à commencer, consultez les ressources suivantes :

Pour obtenir de l’aide sur le processus d’automatisation, consultez les modèles suivants fournis par SAS :