Comment puis-je obtenir des performances d'I/O maximales à partir de mes volumes EBS hébergés sur des instances EC2 Nitro ?

Dernière mise à jour : 14-06-2021

J'exécute ma charge de travail sur des instances Nitro Amazon Elastic Compute Cloud (Amazon EC2). Comment puis-je m'assurer d'obtenir les performances d'I/O maximales pour les volumes Amazon Elastic Block Store (Amazon EBS) hébergés sur mes instances ?

Solution

1.    Vérifiez que votre volume EBS n'atteint pas les limites IOPS. La latence augmente si votre volume atteint sa limite d'IOPS. Une latence accrue a un impact négatif sur les performances. Pour plus d'informations sur l'optimisation des performances des volumes, voir Comment optimiser les performances de mes volumes IOPS provisionnés Amazon EBS ?

Si vous utilisez un volume GP2, vérifiez qu'il n'a pas épuisé les crédits de rafales.

2.    Pour bénéficier des performances rendues possibles par le stockage NVMe, vous devez exécuter l'un des systèmes d'exploitation suivants. Vous pouvez également vérifier que la version du noyau prend en charge un planificateur d'I/O doté d'une capacité de plusieurs files d'attente. Les planificateurs d'I/O à plusieurs files d'attente les plus couramment utilisés sont kyber, mq-deadline et bfq (budget fair queue).

  • AMI Amazon Linux ou version supérieure et noyau 4.12 ou plus récent
  • CentOS 7.0 ou version supérieure et noyau 3.10 ou plus récent
  • Red Hat 7.0 ou version supérieure et noyau 3.10 ou plus récent
  • Les instances Ubuntu 19.10 avec noyau 5.0 ou Ubuntu 18.04.03 avec noyau à partir de 5.0 sont activées par défaut
  • Ubuntu 16.04 ou 16.10 : les planificateurs à plusieurs files d'attente ne sont pas compilés par noyau et nécessitent un chargement séparé du module
  • SUSE 12 ou SUSE 11 avec SP3 ou supérieur
  • Windows Server 2008 R2, 2012 R2 et 2016 ou plus récent

Remarque : pour les systèmes d'exploitation tels qu'Oracle, Linux, Debian, etc., assurez-vous d'utiliser une version de noyau qui inclut ou prend en charge un planificateur d'I/O à plusieurs files d'attente. Le système d'exploitation CentOS et sa version de noyau prennent en charge un planificateur d'I/O à plusieurs files d'attente.

Si vous utilisez un système d'exploitation plus ancien que ceux répertoriés, les performances d'I/O pourront être légèrement inférieures. En effet, le planificateur d'I/O sur CentOS 6 est un planificateur simple qui ne prend pas en charge les files d'attente multiples. Les instances Nitro incluent un traitement à plusieurs files d'attente au niveau de l'hôte. Cela crée une incompatibilité entre le planificateur au niveau du système d'exploitation et au niveau de l'hôte, et peut entraîner une dégradation des performances.

Les demandes d'I/O (en lecture ou écriture) soumises au volume EBS traversent plusieurs couches avant que le volume ne les intercepte. Ces couches incluent l'espace utilisateur, le système de fichiers virtuel, le cache de page, la couche de blocs, le planificateur et le pilote de périphérique. Les tests et les résultats des tests comparatifs à l'aide des outilsblktrace, blkparse etbtt indiquent un léger retard dans la couche du planificateur d'I/O (I2D) lorsque vous utilisez des versions antérieures du noyau avec des planificateurs qui ne prennent pas en charge les files d'attente multiples sur des instances Nitro.

Le planificateur d'I/O joue un rôle important dans la fusion, le traitement et la mise en file d'attente des I/O. Dans les systèmes Nitro, les volumes EBS sont exposés sous forme de périphériques de stockage en mode bloc NVMe. NVME prend en charge de manière native les files d'attente multiples de soumission et de fin de matériel. CentOS 7 inclut le mécanisme de mise en file d'attente d'I/O par blocs de plusieurs files d'attente (blk-mq) qui permet aux pilotes de périphériques de mapper les demandes d'I/O à plusieurs files d'attente matérielles ou logicielles. Les performances d'I/O sont ainsi améliorées sur les instances Nitro en raison des capacités de mise en files d'attente multiples du noyau. Les versions antérieures du noyau n'ont pas cette fonctionnalité. Il est donc recommandé d'utiliser un système d'exploitation moderne doté de la dernière version de noyau pour des performances maximales sur les systèmes Nitro.

Planificateur d'I/O sur CentOS 6

$cat /sys/block/xvdf/queue/scheduler noop anticipatory deadline [cfq]
$cat config-2.6.32-754.30.2.el6.x86_64 | grep -i blk_mq

Remarque : le fichier de configuration du noyau CentOS 6 ne renvoie pas l'attribut blk_mq car il utilise le planificateur noop.

Planificateur d'I/O sur CentOS 7, noyau 3.10 +

$cat /sys/block/nvme1n1/queue/scheduler [none] mq-deadline kyber

Remarque : Kyber et mq-deadline sont des planificateurs à plusieurs files d'attente présents uniquement dans les versions supérieures du noyau (3.10+ pour CentOS 7).

Pour mettre à jour le planificateur au niveau du système d'exploitation pendant l'exécution de l'instance EC2, utilisez la commande suivante :

#sudo echo 'kyber'> /sys/block/xvdf/queue/scheduler

Pour modifier définitivement le planificateur d'I/O, modifiez la configuration de grub et mettez à jour le paramètre elevator au format suivant :

Remarque : les étapes suivantes concernent CentOS et RHEL.

1.    Exécutez la commande suivante :

#sudo vim /etc/default/grub
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet elevator=kyber"

2.    Exécutez la commande suivante :

#sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Le planificateur d'I/O reste défini même si l'instance EC2 est redémarrée.


Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?