🥇Comment utiliser fio pour vérifier que les disques offrent des performances suffisantes pour etcd

Note de traduction.: cet article est le bilan d'une mini-recherche menée par les ingénieurs d'IBM Cloud à la recherche d'une solution à un problème réel lié à l'exploitation de la base de données etcd. Nous avons rencontré une tâche similaire, mais le raisonnement et les actions des auteurs peuvent également être intéressants dans un contexte plus large.

Résumé de l'article : fio et etcd

Les performances du cluster etcd dépendent fortement de la vitesse du stockage sous-jacent. Pour surveiller les performances, etcd exporte diverses métriques Prometheus. L'une d'entre elles est wal_fsync_duration_seconds. Dans la documentation d'etcd il est mentionné, un stockage peut être considéré comme suffisamment rapide si le 99ème percentile de cette métrique ne dépasse pas 10 ms…

Si vous envisagez de mettre en place un cluster etcd sur des machines sous Linux et que vous souhaitez vérifier si vos disques (par exemple, SSD) sont suffisamment rapides, nous vous recommandons d'utiliser le testeur I/O populaire appelé fio. Il suffit d'exécuter la commande suivante (le répertoire test-data doit être situé dans la partition montée du disque testé) :

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

Il ne vous reste plus qu'à regarder la sortie et à vérifier si le 99ème percentile est fdatasync dans 10 ms. Si c'est le cas, cela signifie que votre disque fonctionne suffisamment vite. Voici un exemple de sortie :

fsync/fdatasync/sync_file_range:
  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  percentiles de synchronisation (usec):
   | 1.00e=[ 553], 5.00e=[ 578], 10.00e=[ 594], 20.00e=[ 627],
   | 30.00e=[ 709], 40.00e=[ 750], 50.00e=[ 783], 60.00e=[ 1549],
   | 70.00e=[ 1729], 80.00e=[ 1991], 90.00e=[ 2180], 95.00e=[ 2278],
   | 99.00e=[ 2376], 99.50e=[ 9634], 99.90e=[15795], 99.95e=[15795],
   | 99.99e=[15795]

Quelques remarques :

Dans l'exemple ci-dessus, nous avons ajusté les paramètres --size et --bs pour un cas particulier. Pour obtenir un résultat significatif de fio, fournissez des valeurs adaptées à votre scénario d'utilisation. Nous expliquerons comment les choisir ci-dessous.
Pendant le test, seulement fio charge le sous-système de disque. Dans la vie réelle, il est fort probable que d'autres processus (autres que ceux associés à wal_fsync_duration_seconds) écrivent sur le disque. Ce type de charge supplémentaire peut entraîner une augmentation de wal_fsync_duration_seconds. En d'autres termes, si le 99ème percentile obtenu lors d'un test avec fio, est seulement légèrement inférieur à 10 ms, il est probable que les performances de stockage ne soient pas suffisantes.
Pour le test, vous aurez besoin de la version fio pas inférieure à 3.5, car les versions plus anciennes n'agrègent pas les résultats fdatasync sous forme de percentiles.
La sortie ci-dessus n'est qu'un petit extrait de la sortie générale fio.

Détails sur fio et etcd

Quelques mots sur les WAL d'etcd

En général, les bases de données utilisent la journalisation anticipée (write-ahead logging, WAL). Cela s'applique également à etcd. La discussion sur les WAL dépasse le cadre de cet article, mais pour nos objectifs, il est important de savoir que chaque membre du cluster etcd stocke le WAL dans un stockage permanent. etcd enregistre certaines opérations sur le magasin key-value (comme les mises à jour) dans le WAL avant de les exécuter. Si un nœud s'arrête et redémarre entre les snapshots, etcd sera en mesure de restaurer les transactions effectuées depuis le dernier snapshot en se basant sur le contenu du WAL.

Ainsi, chaque fois qu'un client ajoute une clé au magasin KV ou met à jour la valeur d'une clé existante, etcd ajoute une description de l'opération dans le WAL, qui est un fichier normal dans un stockage permanent. Avant de continuer, etcd DOIT être 100% sûr que l'enregistrement dans le WAL a été effectivement sauvegardé. Pour ce faire sous Linux, il ne suffit pas d'utiliser l'appel système write, car l'opération d'écriture sur le support physique peut être différée. Par exemple, Linux peut conserver l'enregistrement WAL en cache dans la mémoire (par exemple, dans le cache de pages) pendant un certain temps. Pour garantir que les données sont écrites sur le support, il est nécessaire d'effectuer l'appel système fdatasync — c'est ainsi qu'etcd procède (comme indiqué dans l'exemple de sortie suivante strace; ici 8 — un descripteur de fichier WAL):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 
21:23:09.894911 write(8, ".      20210220361223255266632$10 20103026"34"rn3fo"..., 2296) = 2296 
21:23:09.895041 fdatasync(8)            = 0

Malheureusement, l'écriture dans le stockage permanent prend du temps. Un appel fdatasync long peut affecter les performances d'etcd. La documentation du stockage indique qui sont spécifiés, que pour de bonnes performances, le 99e percentile de la durée de tous les appels fdatasync lors de l'écriture dans le fichier WAL doit être inférieur à 10 ms. Il existe d'autres métriques liées au stockage, mais cet article traitera spécifiquement de ce point.

Évaluer le stockage avec fio

Il est possible d'évaluer si un stockage est adapté à une utilisation avec etcd à l'aide de l'outil fio — un testeur I/O populaire. Gardez à l'esprit que les opérations d'entrée/sortie des disques peuvent se faire de différentes manières : sync/async, de nombreuses classes d'appels système, etc. L'autre côté de la médaille est que fio il est extrêmement difficile à utiliser. L'outil a de nombreux paramètres, et différentes combinaisons de ces valeurs aboutissent à des résultats totalement différents. Pour obtenir une évaluation acceptable dans le cas d'etcd, vous devez vous assurer que la charge d'écriture générée par fio ressemble le plus possible à la charge d'écriture d'etcd dans les fichiers WAL :

Cela signifie que la charge générée fio doit au minimum représenter une série d'écritures séquentielles dans un fichier, où chaque opération d'écriture consiste en un appel système write, suivi de fdatasync.
Pour activer l'écriture séquentielle, il est nécessaire de spécifier le drapeau --rw=write.
Pour que fio qui a été écrite en utilisant des appels write (et non d'autres appels système — par exemple, pwrite), utilisez le drapeau --ioengine=sync.
Enfin, le drapeau --fdatasync=1 garantit que chaque write il convient fdatasync.
Deux autres paramètres dans notre exemple : --size et --bs — peuvent varier en fonction du scénario d'utilisation particulier. Leur configuration sera décrite dans la section suivante.

Pourquoi avons-nous choisi fio et comment avons-nous appris à le configurer

Cette note est née d'un cas réel auquel nous avons été confrontés. Nous avions un cluster sur Kubernetes v1.13 avec une surveillance sur Prometheus. Les disques durs à état solide servaient de stockage pour etcd v3.2.24. Les métriques d'etcd indiquaient des latences trop élevées fdatasync, même lorsque le cluster était au repos. Ces métriques nous paraissaient très douteuses, et nous n'étions pas sûrs de ce qu'elles représentaient vraiment. De plus, le cluster se composait de machines virtuelles, donc nous ne pouvions pas dire si la latence était liée à la virtualisation ou si c'étaient les SSD qui en étaient responsables.

De plus, nous avons envisagé diverses modifications de la configuration matérielle et logicielle, donc un moyen d'évaluation était nécessaire. Bien sûr, il aurait été possible de lancer etcd dans chaque configuration et de regarder les métriques correspondantes dans Prometheus, mais cela aurait demandé un effort considérable. Nous avions besoin d'un moyen simple pour évaluer une configuration particulière. Nous voulions vérifier notre compréhension des métriques Prometheus provenant d'etcd.

Pour cela, il fallait résoudre deux problèmes :

Tout d'abord, comment se manifeste la charge I/O générée par etcd lors de l'écriture dans les fichiers WAL ? Quels appels système sont utilisés ? Quelle est la taille des blocs d'écriture ?
Deuxièmement, supposons que nous avons les réponses aux questions précédentes. Comment reproduire la charge correspondante avec fio? Ведь fio — un utilitaire extrêmement flexible avec une multitude d'options (ce qui est facile à vérifier, par exemple, ici — note du traducteur).

Nous avons résolu les deux problèmes en utilisant la même approche, qui repose sur des commandes lsof et strace:

Avec lsof vous pouvez consulter tous les descripteurs de fichiers utilisés par le processus, ainsi que les fichiers auxquels ils se rapportent.
Avec strace vous pouvez analyser un processus déjà en cours ou lancer un processus et l'observer. La commande affiche tous les appels système effectués par ce processus et, si nécessaire, ses descendants. Cela est important pour les processus qui forkent, et etcd est l'un de ces processus.

La première chose que nous avons faite a été d'utiliser strace pour examiner le serveur etcd dans le cluster Kubernetes pendant qu'il était au repos.

Il a été découvert que les blocs d'écriture dans le WAL étaient très fortement groupés, la taille de la plupart se situant entre 2200 et 2400 octets. C'est pourquoi dans la commande en début de cet article, le drapeau --bs=2300 (bs — la taille en octets de chaque bloc d'écriture dans fio).

Notez que la taille des blocs d'écriture de etcd peut varier en fonction de la version, du déploiement, des valeurs des paramètres, etc. — cela affecte la durée fdatasync. Si vous avez un scénario d'utilisation similaire, analysez avec strace vos processus etcd pour obtenir des valeurs actuelles.

Ensuite, pour obtenir une vue claire et complète du fonctionnement de etcd avec le système de fichiers, nous l'avons exécuté sous strace avec les drapeaux -ffttT. Cela a permis de couvrir les processus enfants et d'enregistrer la sortie de chacun dans un fichier séparé. De plus, des informations détaillées ont été obtenues sur le moment du démarrage et la durée de chaque appel système.

Nous avons également utilisé la commande lsof, pour confirmer notre compréhension de la sortie strace en ce qui concerne quel descripteur de fichier était utilisé à quelle fin. Nous avons obtenu une sortie strace, similaire à celle ci-dessus. Les manipulations statistiques des temps de synchronisation ont confirmé que la métrique wal_fsync_duration_seconds de etcd correspond aux appels fdatasync aux descripteurs de fichiers WAL.

Pour générer avec fio La charge de travail, similaire à celle d'etcd, a été étudiée à travers la documentation de l'outil et les paramètres appropriés à notre tâche ont été sélectionnés. Nous avons vérifié que les appels système requis étaient impliqués et confirmé leur durée en exécutant fio de strace (comme cela a été fait dans le cas d'etcd).

Une attention particulière a été accordée à la détermination de la valeur du paramètre --size. Il représente la charge I/O totale générée par l'outil fio. Dans notre cas, il s'agit du nombre total d'octets écrits sur le support. Il est directement proportionnel au nombre d'appels write (et fdatasync). Pour un certain bs nombre d'appels fdatasync est égal à size / bs.

Comme nous étions intéressés par le percentile, nous avons veillé à ce que le nombre d'échantillons soit suffisamment grand pour être statistiquement significatif. Nous avons décidé que 10^4 (ce qui correspond à une taille de 22 Mo) serait suffisant. Des valeurs inférieures pour le paramètre --size généraient un bruit plus prononcé (par exemple, des appels fdatasync, qui prennent beaucoup plus de temps que d'habitude, et affectent le 99ème percentile).

À vous de jouer

L'article montre comment utiliser fio pour évaluer si un support est suffisamment rapide pour être utilisé avec etcd. Maintenant, c'est à vous de jouer ! Vous pouvez explorer les machines virtuelles avec un stockage basé sur SSD dans le service IBM Cloud.

P.S. de l'auteur

Avec des exemples d'utilisation prêts à l'emploi fio pour résoudre d'autres tâches, vous pouvez consulter documentation ou directement dans le référentiel du projet (il y en a beaucoup plus que celles mentionnées dans la documentation).

P.P.S. du traducteur

Lisez aussi dans notre blog :

Source : habr.com

Comment tester les disques avec fio pour vérifier s'ils ont des performances suffisantes pour etcd