Quel débit disque avec SAS 9 ?

C'est sans doute la question au cœur de toutes les préoccupations lors du démarrage d'un projet SAS ou lorsque vous rencontrez des problèmes de performances sur vos environnements existants.

Quel débit disque ai-je besoin pour travailler avec SAS 9 ?

Une fois n'est pas coutume je vous propose un article pour répondre à cette question. Bien-sûr je n'ai rien inventé et cet article a été rédigé à partir des informations disponibles sur le site du support SAS. Je vous invite à lire la section "Allez plus loin" à la fin de cet article si justement vous souhaitez aller plus loin.

Maintenant avant de répondre à cette question du débit disque avec SAS 9, posons-nous en une autre : qu'est-ce que le débit ? Il s'agit simplement de la quantité de données que votre application envoie aux disques dans un intervalle spécifié.

Aussi, si avez lu attentivement le document System Requirements for SAS® 9.4 Foundation for Linux for x64 vous tomberez sur l'information ci-dessous concernant les prérequis en terme de débit I/O :

I/O Throughput of at least 100 MB/second/core

La documentation répond donc à notre question :

Pour faire simple, si votre serveur a 4 cœurs , vos disques doivent être en mesure d'attendre un débit de 400 Mo/s, avec 8 cœurs, 800 Mo/s ...

Avant de commencer

De nombreuses applications logicielles et bases de données sont orienté d'IO par seconde (IOP). Pour décrire de manière significative les caractéristiques de performances de tout périphérique de stockage, il est nécessaire de spécifier au moins trois métriques simultanément : IOPS, temps de réponse et charge de travail. En l'absence de spécifications simultanées de temps de réponse et de charge de travail, les IOPS n'ont pratiquement aucun sens. Isolément, les IOPS peuvent être considérés comme analogues aux « tours par minute » d'un moteur d'automobile, c'est-à-dire qu'un moteur capable de tourner à 10 000 tr/min avec sa transmission au point mort ne transmet rien, cependant un moteur capable de développer un couple et une puissance spécifiés à un nombre donné de tours par minute décrit pleinement les capacités du moteur.

Je ferme la parenthèse car ce n'est pas les IOPS qui nous intéresse. En effet, gardez en tête que SAS Foundation crée un volume élevé d'I/O à accès séquentiel principalement sur des gros blocs( généralement de 64K, 128K ou 256K) et les interactions avec le stockage de données sont très différentes de applications interactives typiques ou SGBD :

• SAS a tendance à effectuer de grandes lectures et écritures séquentielles.
• SAS ne pré-alloue pas de stockage lors de l'initialisation ou lors de l'exécution d'écritures dans un fichier.
• La lecture et l'écriture des données s'effectuent via le cache de fichiers du système d'exploitation (OS).
• Un grand nombre de fichiers temporaires peuvent être créés dans la SAS WORK.
• Lors de l'exécution des écritures, il existe un seul thread d'écriture par session SAS.

Aussi, il es recommandé de provisionner au moins 3 types de filesystem pour prendre en charge SAS. Selon les charges et les tailles, il peut être nécessaire d'avoir plusieurs instances de chacun d'entre eux.

Voici les 3 types de filesystem :

• SASDATA stocke les données persistantes pour l'exploitation SAS et les fichiers de sortie SAS. Ce répertoire est massivement lu, mais la charge en écriture est moindre. Il est recommandé de prévoir une bande passante minimale de 100 Mo/s pour une utilisation de SAS normale et jusqu'à 150 Mo/s pour les opérations statistiques et analytiques lourdes.

• La WORK est l'espace de travail temporaire utilisé par les procédures SAS. Comme pour SASDATA, il est recommandé de prévoir une bande passante minimale 100 Mo/s et 150 Mo/s.

• UTILLOC est l'espace de travail utilisé par les procédure multi-thread. Par défaut, ce répertoire est sous-répertoire de la WORK.

Si un système de fichiers SASWORK ou UTILLOC donné devient surchargé et fonctionne mal, il peut être nécessaire de créer plusieurs systèmes de fichiers physiques pour SASWORK et UTILLOC. Enfin , SAS recommande les systèmes de fichiers suivants par système d'exploitation si la charge en lecture/écriture est important :

• Solaris 10 ZFS
• AIX JFS2
• HP-UX JFS
• Linux RHEL XFS
• Windows NTFS

En résumé, la charge de travail SAS peut être caractérisés comme des demandes d'I/O séquentielles principalement volumineuses avec des volumes de données élevés. C'est très important de prédéterminer les modèles d'utilisation de SAS car cela guidera l'architecture et la configuration optimales des systèmes de fichiers individuels sous-jacents.

Garder en tête que les programmes SAS lisent souvent les mêmes données plusieurs fois. Aussi le programme peut effectuer des lectures logiques à partir du cache de fichiers local beaucoup plus rapidement et plus efficacement que de le relire à partir du périphérique physique.

Les opérations qui accèdent à de petits fichiers ont tendance à tirer un avantage substantiel des performances du cache de fichiers local. N'oubliez pas que des fichiers plus grands que la taille du cache de fichiers du système hôte ne peuvent pas être mis en cache dans leur intégralité et peuvent ne pas être mis en cache du tout.

SAS ne pré-alloue pas de stockage lors de l'initialisation ou lors de l'exécution d'écritures dans un fichier. SAS alloue une petite quantité de stockage lorsqu'il crée un fichier dans un système de fichiers basé sur une extension. Comme le fichier augmente au cours d'une tâche SAS, SAS demande des extensions pour la quantité de stockage nécessaire.

Maintenant que vous avez toutes les cartes en mains, nous pouvons maintenant passer à la pratique.

Testez votre débit disque

Vous l'avez compris en lisant ce long préambule ( si vous ne l'avez pas lu, foncez le lire ) SAS imposent des exigences différentes en termes de file systems et de débit d'I/O que les bases de données traditionnelles ou les processus de requête simples. Pour cette raison, vous devez être en mesure de déterminer les débits de tout système de fichiers utilisé par SAS.

Pour cette raison SAS fournit deux outils pour déterminer ce débit : iotest et rhel_iostest.

Ce sont ces deux outils que je vais maintenant vous présenter en détail.

Présentation de iotest et rhel_iostest

Vous trouvez ces deux outils en vous rendant à l'adresse ci-dessous:

SAS usage note 53876 : Dépannage des problèmes de performances du système : Test du débit d'E/S

Le script iotest.sh utilise les commandes UNIX/Linux dd pour mesurer le débit I/O. Ce script est facile à utiliser et peut être utilisé pour lancer des tests d'I/O en simultané pour surcharger le système de fichiers et déterminer ses performances brutes.

Le script iotest.sh crée des fichiers et les écrit dans le système de fichiers testé. Il les relit ensuite pour tester les performances d'écriture et de lecture du système de fichiers. La sortie principale de cet outil est constituée des mégaoctets écrits par seconde (Mo/s) et des mégaoctets lus par seconde . Ces métriques peuvent vous aider à analyser et à régler les I/O pour les systèmes de fichiers prenant en charge SAS.

Avant de commencer les tests de débit d'I/O, il est important de prendre en compte les concepts suivants :

SAS effectue toutes les opérations d'écriture et de lecture via le cache du filesystem . Aussi, les tailles de fichiers utilisées pour les tests d'écriture et de lecture doivent être supérieures au cache de fichiers de votre système hôte. (Il est prudent de les rendre supérieures à la RAM de votre système hôte.) Par exemple, si vous exécutez votre test avec une taille de fichier de 1 Go et que votre système dispose de 5 Go de cache, les tests en lecture seront limités. Le fichier créé lors du test de débit en écriture restera dans le cache filesystem et le test de lecture se fera à partir du cache au lieu du disque. Si les tests de lecture sont réalisé via le cache au lieu de provenir des disques, vous vous doutez que les métriques de performances de lecture seront trompeuses et vous ne pourrez pas générer de résultats cohérents et reproductibles.

Exemple de fonctionnement

Pour lancer iotest.sh, j'utilise la commande ci-dessous :

Ce qui donne, dans mon cas, un débit de 150 Mo/s en lecture et de 180 Mo/s en écriture :

Avant de continuer, voici une explication des paramètres :

-i 1 exécute 1 itérations concurrentes Write, puis Read, du test.
-t /opt/VIODISK/ indique que les écritures vont se faire dans /opt/VIODISK/
-b (nombre de blocs) est défini sur 380000, qui, multiplié par le
-s (taille de bloc) de 64 Ko entraînera une taille de fichier de 36 Go, ce qui est supérieur aux 32 Go de RAM sur la machine utilisée dans cet exemple.

• il est possible de lancer plusieurs itération (via l'option -i ) afin de simuler ce que SAS pourrait subir avec une charge de travail plus importante.

• La commande ci-dessus lance d'abord 5 tests d'écriture simultanés. Chaque test d'écriture crée un fichier unique de 36Go dans /opt/VIODISK/. Une fois les 5 tests d'écriture terminés, 5 tests de lecture simultanés sont lancés pour lire ces fichiers. Le script collecte ensuite les temps de lecture et d'écriture, ainsi que le débit en Mo/s pour chaque exécution; Le script fait ensuite la moyenne des écritures et des lectures pour obtenir les statistiques finales. Simple et efficace.

• Il semble donc judicieux d'effectuer plusieurs de ces tests à différents moments de la journée et sur plusieurs jours pour obtenir un profil complet des caractéristiques d'I/O.

• Cela va de soi, mais cela ne coute rien de le préciser; exécutez les tests sur le filesystem que vous souhaitez analyser.

rhel_iostest.sh

Regardons maintenant le script rhel_iotest.sh. Il s'agit d'outil développé SAS qui automatise, à l'instar de iotest.sh, les commandes UNIX/Linux dd pour mesurer le débit d'un filesystem dans un environnement Red Hat Enterprise Linux (RHEL). Cette méthode imite le comportement de SAS. Les résultats doivent vous donner une estimation raisonnable du débit d'I/O, mais peuvent ne pas refléter les performances réelles des applications SAS.

Dans un premier temps, rhel_iotest.sh évalue votre environnement Red Hat, calcule tous les paramètres requis en fonction des spécifications de votre système et lance une série de tests d'écriture et de lecture.

Il est important d'exécuter le script de test à partir d'un système de fichiers distinct du système de fichiers cible que vous testez. Pour des résultats précis, votre système de fichiers cible doit disposer d'un espace libre supérieur à (le nombre de cœurs physiques de votre système) * (la quantité de RAM physique dans votre système).

Voici un exemple de résultat :

Test rapide avec dd

Il est également possible d'exécuter un test rapide avec l'utilitaire dd. Ce test sera tout de même moins précis que celui réalisé avec l'outil iotest.sh

Monitorer l'activité des disques

Pour les suivre l'activité d'I/O de vos disques, il existe plusieurs possibilité options. Ma préférée est la commande sar de sysstat. Par défaut, il donne une sortie comme celle-ci :

Le %iowait correspond au temps d’attente du système pour l’écriture ou la lecture de données. Un « iowait » de 10% signifie que 1 % de l’activité du processeur n’est pas destinée à faire des calculs mais à attendre l’exécution d’une opération de lecture/écriture.

Pour voir l'utilisation actuelle ventilée par périphérique, vous pouvez utiliser la commande iostat, également à partir du package sysstat :

Tests sur Azure

Pour illustrer l'utilisation de ses deux outils SAS , j'ai réalisé une série de tests sur différents type de machines Azure. J'ai utilisé des disques Premium ( débit max de 900 Mo/seconde). Lorsque vous attachez un disque de stockage premium à une machine virtuelle, Azure provisionne le débit conformément à cette spécification de disque. Par exemple, un disque P50 fournit un débit de disque de 250 Mo par seconde. A noter toutefois que chaque taille de machine virtuelle e a également une limite de débit spécifique qu'elle peut supporter.

Azure propose également les ultra disk Azure (UltraSSD_LRS ) qui offrent un débit élevé (2,000 Mo/s) , des IOPS élevées et un stockage sur disque à faible latence pour les machines virtuelles Azure IaaS. Certains avantages supplémentaires des disques ultra incluent, par exemple, la possibilité de modifier dynamiquement les performances du disque sans avoir besoin de redémarrer vos machines virtuelles. Vous l'avez compris les Ultra Disk sont adaptés aux charges de travail gourmandes en données.

Pour ces tests, je n'ai pas choisi mes machines virtuelles au hasard. Il est important de consulter la section Max uncached disk throughput IOPS/MBps pour connaitre le débit d'E/S maximum en Mo par seconde disponible entre l'instance et le stockage Premium. Pour une instance Standard_E32s_v3 (l'une des instances MS Azure les plus populaires utilisée pour les systèmes de calcul SAS), le débit maximal (total de l'instance, pas par cœur physique) est de 768 Mo par seconde. Pour un système à 16 cœurs physiques, cela signifie une bande passante de 48 Mo/s/cœur physique pour toutes les données qui seront stockées sur ce stockage Premium . Si vous avez besoin d'un débit par cœur physique plus important, il est possible de limiter le nombre de cœurs dans l'instance.

C'est hors-sujet, mais j'ai également consulté la section Max NICs/Expected network bandwidth (Mbps) pour voir quelle est la bande passante de sortie réseau maximale. Pour une instance Standard_E32s_v3, la bande passante de sortie réseau maximale est limitée à 16 Gigabit/s, tandis que l'entrée est limitée par la vitesse de la carte réseau et le nombre de connexions réseau uniquement. Reportez-vous à cette page pour plus de détails, où les 4 premiers paragraphes sont à lire absolument. Veuillez noter que SAS recommande une bande passante réseau d'au moins 10 Gigabit entre les systèmes SAS au sein d'une infrastructure SAS. 

Enfin, si vous avez plusieurs machines et pour obtenir des I/O et un débit en cohérents, assurez-vous que toutes vos instances sont dans la même Azure Proximity Placement Group

Test débit I/o avec une machine Azure Standard_E32s_v3

Comme je vous l'ai indiqué dans le chapitre précèdent cette instance est l'instance la plus souvent utilisé pour SAS. Les instances de la série Esv3 s'exécutent sur le processeur Intel® Xeon® Platinum 8272CL (
Cascade Lake), Intel® Xeon® 8171M 2,1 GHz (Skylake) ou le processeur Intel® Xeon® E5-2673 v4 2,3 GHz (Broadwell), doté de la technologie Intel Turbo Boost 2.0 et utilisez un stockage premium. Les instances de la série Esv3 sont idéales pour les applications d'entreprise gourmandes en mémoire. L'instance Standard_E32s_v3 offr un débit maximal (total de l'instance, pas par cœur physique) de 768 Mo par seconde. Pour un système à 16 cœurs physiques, cela signifie une bande passante de 48 Mo/s/cœur physique pour toutes les données qui seront stockées sur un stockage Premium externe. Si vous avez besoin de plus de débit par cœur physique vers le stockage Premium externe, vous pouvez limiter le nombre de cœurs dans l'instance.

Test débit I/o avec une machine Azure Standard_DS1_v2

Les machines de la série DSv2 fonctionnent sur Intel® Xeon® Platinum 8272CL (Cascade Lake), Intel® Xeon® 8171M 2,1 GHz (Skylake) ou Intel® Xeon® E5-2673 v4 2,3 GHz (Broadwell) ou Intel® Xeon® E5 -2673 processeurs v3 2,4 GHz (Haswell) avec la technologie Intel Turbo Boost 2.0 et utilisent un stockage premium. La DS1 V2 utilise 1 vcpu et 3.5 GO de ram.

Pour ce test, j'ai donc monté un disque premium sur /opt/VIODISK.

Ce qui donne :

Test débit I/o avec une machine Azure Standard_L8s_v2

Pour ce dernier test, j'ai utilisé une machine Standard_L8s_v2 . La série Lsv2 offre un stockage NVMe local , à faible latence et fonctionnant sur le processeur AMD EPYCTM 7551 avec une augmentation de tous les cœurs de 2,55 GHz et une augmentation maximale de 3,0 GHz. Les machines virtuelles de la série Lsv2 sont disponibles dans des tailles allant de 8 à 80 vCPU dans une configuration multithreading simultanée. Il y a 8 Gio de mémoire par processeur virtuel et un périphérique SSD M.2 NVMe de 1,92 To pour 8 processeurs virtuels, avec jusqu'à 19,2 To (10 x 1,92 To) disponibles sur le L80s v2.

Maintenant que les présentations sont faites, voyons ce que donne un rhel_iotest.sh sur le disque nvme :

Si vous travaillez sur Azure, en plus des informations sur les types d'instances Azure, le stockage et la mise en réseau, veuillez suivre les bonnes pratiques du document Optimizing SAS on Red Hat Enterprise Linux (RHEL) 6 & 7. Les informations de la section « 2.4.4.4 Réglage des pages modifiées de la mémoire virtuelle pour SAS 9 » à la page 17 sont essentielles.

Et en dehors d'Azure ça donne quoi ?

En plus des tests sur Azure j'ai effectué deux tests sur deux machines que j'utilise au quotidien. D'abord une machine hébergée chez Online (Pro-4-M), un serveur Xeon E3 1245v5 de 4 cœurs, 64 Go de ram et 3 disques SSD de 500 Go.

Voici le résultat d'un test sur ce serveur :

Ce résultat est plus que convenable d'autant plus que mes 3 disques SSD ne sont pas montés en RAID.

Le dernier test a été effectué sur un serveur AMD Ryzen 9 3900x, 12 cœurs, 64 Go de ram dur lequel j'ai monté une machine virtuel 4 cœurs, 16 Go de Ram et un disque Nvme Crucial P2 M.2 2280SS SSD.

Ce qui donne ( 4 itérations) :

Ces performances pourrait être améliorer. En effet, je dois bientôt changer de disque pour un WD_BLACK SN850 qui est donné pour des performances 7 Mo/s en lecture et 5 Mo/s en écriture.

Comparatif final

Je ne pouvais pas terminer cet article sans un petit tableau récapitulatif. Bien sur les résultats ne tiennent compte que des performances disques et lorsque vous montez un environnement SAS il ne s'agit pas uniquement du seul critère à prendre en compte. Mais j'ai trouvé que faire cet exercice était interessant.

Maintenant le tableau :

Conclusion

Vous l'avez compris en lisant cette article, il est fortement recommandé d'effectuer une évaluation détaillée du fonctionnement de SAS, du volumes de données qui seront traitées, analysées et manipulées, et le nombre simultané de session SAS sessions qui seront exécutées pour évaluer les débits d'I/O nécessaires.

Durant cette étape (ou lorsque vous rencontrez des problèmes de performances) je vous conseille de travailler en étroite collaboration avec les équipes systèmes afin de vérifier que vous serez en mesure d'atteindre les débit I/O requis durant votre évaluation.
L'objectif est de s'assurer que SAS puisse obtenir la bande passante nécessaire pour terminer les travaux SAS dans les délais requis par les utilisateurs SAS.

Pour aller plus loin

Il existe de nombreux documents disponibles pour vous aider à comprendre comment SAS effectue les I/O, ainsi que des recommandations d'I/O minimales pour les systèmes de fichiers SAS.

Ces documents décrivent les métriques d'E/S recommandées pour les systèmes de fichiers qui prennent en charge les déploiements SAS, et ils identifient des directives qui peuvent aider à l'approvisionnement et au réglage des caractéristiques d'E/S pour des performances SAS optimales. Vous pouvez accéder à ces documents via la note Usage Note 42197: A list of papers useful for troubleshooting system performance problems

Je vous encourage également à lire le papier Best Practices for Configuring Your I/O Subsystem for SAS®9 Applications

Best practices pour la configuration de votre sous-système IO pour les applications SAS 9

Foire aux questions concernant les configurations de stockage

Informations générales - Une liste de documents utiles pour la résolution de problèmes de performances du système

Réglage du système d'exploitation

SAS Usage Note 53875: Dépannage des problèmes de performances du système : systèmes de fichiers partagés/en cluster

SAS Usage Note 53874: Dépannage des problèmes de performances du système : sous-système d'E/S et stockage

SAS Usage Note 53878: Dépannage des problèmes de performances du système dans les environnements SAS Grid

Usage Note 62239: SAS on the Public Cloud

SAS sur une infrastructure virtualisée

Haute disponibilité et reprise après sinistre

Surveillance des performances et dépannage